From kuninori.morimoto.gx at renesas.com  Mon Jul  1 00:11:39 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Sun, 30 Jun 2013 21:11:39 -0700 (PDT)
Subject: [PATCH 1/3] ARM: shmobile: use common platform header for HPB-DMAC
In-Reply-To: <201306300245.58486.sergei.shtylyov@cogentembedded.com>
References: <201306300243.57180.sergei.shtylyov@cogentembedded.com>
 <201306300245.58486.sergei.shtylyov@cogentembedded.com>
Message-ID: <87ehbij4wc.wl%kuninori.morimoto.gx@renesas.com>


Hi

> From: Max Filippov <max.filippov at cogentembedded.com>
> 
> Use previously empty <mach/dma.h> to declare HPB-DMA slave IDs.
> 
> Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
> [Sergei: changed the guard macro name, fixed comment, extended copyright.]
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---
>  arch/arm/mach-shmobile/include/mach/dma.h |   25 ++++++++++++++++++++++++-
>  1 file changed, 24 insertions(+), 1 deletion(-)
> 
> Index: renesas/arch/arm/mach-shmobile/include/mach/dma.h
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/include/mach/dma.h
> +++ renesas/arch/arm/mach-shmobile/include/mach/dma.h
> @@ -1 +1,24 @@
> -/* empty */
> +/*
> + * Copyright (C) 2011-2013 Renesas Electronics Corporation
> + * Copyright (C) 2013 Cogent Embedded, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation.
> + */
> +
> +#ifndef __MACH_DMA_H
> +#define __MACH_DMA_H
> +
> +/* HPB-DMA slave IDs */
> +enum {
> +	HPBDMA_SLAVE_DUMMY,
> +	HPBDMA_SLAVE_SDHI0_TX,
> +	HPBDMA_SLAVE_SDHI0_RX,
> +	HPBDMA_SLAVE_SSI0_TX_ST,
> +	HPBDMA_SLAVE_SSI0_TX_MN,
> +	HPBDMA_SLAVE_SSI1_RX_ST,
> +	HPBDMA_SLAVE_SSI1_RX_MN,
> +};

it should be in r8a7778.h


Best regards
---
Kuninori Morimoto


From kuninori.morimoto.gx at renesas.com  Mon Jul  1 00:12:25 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Sun, 30 Jun 2013 21:12:25 -0700 (PDT)
Subject: [PATCH 2/3] ARM: shmobile: r8a7778: add HPB-DMAC support
In-Reply-To: <201306300248.57898.sergei.shtylyov@cogentembedded.com>
References: <201306300243.57180.sergei.shtylyov@cogentembedded.com>
 <201306300248.57898.sergei.shtylyov@cogentembedded.com>
Message-ID: <87d2r2j4uy.wl%kuninori.morimoto.gx@renesas.com>


Hi

> From: Max Filippov <max.filippov at cogentembedded.com>
> 
> Add HPB-DMAC platform device on R8A7778 SoC along with its slave and channel
> configurations.
> 
> Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---
(snip)
> +static const struct hpb_dmae_slave_config hpb_dmae_slaves[] = {
> +	{
> +		.id	= HPBDMA_SLAVE_SDHI0_TX,
> +		.addr	= 0xffe4c000 + 0x30,
> +		.dcr	= DCR_SPDS_16BIT | DCR_DMDL | DCR_DPDS_16BIT,
> +		.rstr	= ASYNCRSTR_ASRST21 | ASYNCRSTR_ASRST22 |
> +			  ASYNCRSTR_ASRST23,
> +		.mdr	= ASYNCMDR_ASMD21_SINGLE,
> +		.mdm	= ASYNCMDR_ASMD21_MASK,
> +		.port	= 0x0D0C,
> +		.flags	= HPB_DMAE_SET_ASYNC_RESET | HPB_DMAE_SET_ASYNC_MODE,
> +		.dma_ch	= 21,
> +	}, {
> +		.id	= HPBDMA_SLAVE_SDHI0_RX,
> +		.addr	= 0xffe4c000 + 0x30,
> +		.dcr	= DCR_SMDL | DCR_SPDS_16BIT | DCR_DPDS_16BIT,
> +		.rstr	= ASYNCRSTR_ASRST21 | ASYNCRSTR_ASRST22 |
> +			  ASYNCRSTR_ASRST23,
> +		.mdr	= ASYNCMDR_ASMD22_SINGLE,
> +		.mdm	= ASYNCMDR_ASMD22_MASK,
> +		.port	= 0x0D0C,
> +		.flags	= HPB_DMAE_SET_ASYNC_RESET | HPB_DMAE_SET_ASYNC_MODE,
> +		.dma_ch	= 22,
> +	}, {
> +		.id	= HPBDMA_SLAVE_SSI0_TX_ST,
> +		.addr	= 0xffd90000 + 0x1008,
> +		.dcr	= DCR_CT | DCR_DIP | DCR_SPDS_32BIT | DCR_DMDL |
> +			  DCR_DPDS_32BIT,
> +		.port	= 0x0000,
> +		.dma_ch	= 28,
> +	}, {
> +		.id	= HPBDMA_SLAVE_SSI0_TX_MN,
> +		.addr	= 0xffd90000 + 0x1008,
> +		.dcr	= DCR_CT | DCR_DIP | DCR_SPDS_16BIT | DCR_DMDL |
> +			  DCR_DPDS_16BIT,
> +		.port	= 0x0000,
> +		.dma_ch	= 28,
> +	}, {
> +		.id	= HPBDMA_SLAVE_SSI1_RX_ST,
> +		.addr	= 0xffd90000 + 0x104c,
> +		.dcr	= DCR_CT | DCR_DIP | DCR_SMDL | DCR_SPDS_32BIT |
> +			  DCR_DPDAM | DCR_DPDS_32BIT,
> +		.port	= 0x0101,
> +		.dma_ch	= 29,
> +	}, {
> +		.id	= HPBDMA_SLAVE_SSI1_RX_MN,
> +		.addr	= 0xffd90000 + 0x104c,
> +		.dcr	= DCR_CT | DCR_DIP | DCR_SMDL | DCR_SPDS_16BIT |
> +			  DCR_DPDAM | DCR_DPDS_16BIT,
> +		.port	= 0x0101,
> +		.dma_ch	= 29,
> +	},
> +};

How did you test SSI ?
remove these

Best regards
---
Kuninori Morimoto


From horms+renesas at verge.net.au  Mon Jul  1 00:25:52 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon,  1 Jul 2013 13:25:52 +0900
Subject: [PATCH v3 0/3] ARM: shmobile: lager: enable Ether
Message-ID: <1372652755-16948-1-git-send-email-horms+renesas@verge.net.au>

Hi,

this short series enables the on-board ethernet
of the r8a7790 SoC for on lager baord.

It is based on the renesas-next-20130509 tag of my renesas tree.

It has a run-time dependency on
"sh_eth: add support for r8a7790 SoC"

It has been built on top of renesas-next-20130701.

Simon Horman (3):
  ARM: shmobile: r8a7790: add Ether support
  ARM: shmobile: lager: enable Ether
  ARM: shmobile: lager: enable nfsroot in DTS

 arch/arm/boot/dts/r8a7790-lager.dts           |  2 +-
 arch/arm/mach-shmobile/board-lager.c          | 24 ++++++++++++++++++++++++
 arch/arm/mach-shmobile/clock-r8a7790.c        |  4 ++++
 arch/arm/mach-shmobile/include/mach/r8a7790.h |  3 +++
 arch/arm/mach-shmobile/setup-r8a7790.c        | 14 ++++++++++++++
 5 files changed, 46 insertions(+), 1 deletion(-)

-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul  1 00:25:55 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon,  1 Jul 2013 13:25:55 +0900
Subject: [PATCH v3 3/3] ARM: shmobile: lager: enable nfsroot in DTS
In-Reply-To: <1372652755-16948-1-git-send-email-horms+renesas@verge.net.au>
References: <1372652755-16948-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1372652755-16948-4-git-send-email-horms+renesas@verge.net.au>

Now that Ether support has been added to the lager board
it is possible to use nfsroot. This configuration is
in line with that of other shmobile boards.

Cc: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

This patch has a run-time dependency on "ARM: shmobile: lager: enable Ether"

v2
* Split out as a new patch from "ARM: shmobile: lager: enable Ether"
---
 arch/arm/boot/dts/r8a7790-lager.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 09a84fc..b2f61f0 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -16,7 +16,7 @@
 	compatible = "renesas,lager", "renesas,r8a7790";
 
 	chosen {
-		bootargs = "console=ttySC6,115200 ignore_loglevel";
+		bootargs = "console=ttySC6,115200 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096 rw";
 	};
 
 	memory at 40000000 {
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul  1 00:25:54 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon,  1 Jul 2013 13:25:54 +0900
Subject: [PATCH v3 2/3] ARM: shmobile: lager: enable Ether
In-Reply-To: <1372652755-16948-1-git-send-email-horms+renesas@verge.net.au>
References: <1372652755-16948-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1372652755-16948-3-git-send-email-horms+renesas@verge.net.au>

Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Cc: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

This patch has a build-time dependency on "sh_eth: add support for gpio reset".
This patch has a run-time dependency on "sh_eth: add support for r8a7790 SoC".

v3
* Rebase

v2
* As suggested by Laurent Pinchart
  - Do not manipilate sh_eth reset GPIO directly,
    rather, do so through newly proposed support for this in
    the sh_eth driver.
* A suggested by Sergei Shtylyov
  - Move DTS portion into a separate patch
---
 arch/arm/mach-shmobile/board-lager.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index 0b4a1f9..4fecaf6 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -71,6 +71,17 @@ static __initdata struct gpio_keys_platform_data lager_keys_pdata = {
 	.nbuttons	= ARRAY_SIZE(gpio_buttons),
 };
 
+/* Ether */
+static struct sh_eth_plat_data ether_platdata = {
+	.phy			= 0x1,
+	.edmac_endian		= EDMAC_LITTLE_ENDIAN,
+	.register_type		= SH_ETH_REG_FAST_RCAR,
+	.phy_interface		= PHY_INTERFACE_MODE_RMII,
+	.ether_link_active_low	= 1,
+	.needs_gpio_reset	= 1,
+	.reset_gpio		= RCAR_GP_PIN(5, 31),
+};
+
 static const struct pinctrl_map lager_pinctrl_map[] = {
 	/* SCIF0 (CN19: DEBUG SERIAL0) */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7790",
@@ -78,6 +89,17 @@ static const struct pinctrl_map lager_pinctrl_map[] = {
 	/* SCIF1 (CN20: DEBUG SERIAL1) */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.7", "pfc-r8a7790",
 				  "scif1_data", "scif1"),
+	/* Ether */
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
+				  "eth_link", "eth"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
+				  "eth_magic", "eth"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
+				  "eth_mdio", "eth"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
+				  "eth_rmii", "eth"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
+				  "intc_irq0", "intc"),
 };
 
 static void __init lager_add_standard_devices(void)
@@ -89,6 +111,8 @@ static void __init lager_add_standard_devices(void)
 	r8a7790_pinmux_init();
 
 	r8a7790_add_standard_devices();
+	r8a7790_add_ether_device(&ether_platdata);
+
 	platform_device_register_data(&platform_bus, "leds-gpio", -1,
 				      &lager_leds_pdata,
 				      sizeof(lager_leds_pdata));
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul  1 00:25:53 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon,  1 Jul 2013 13:25:53 +0900
Subject: [PATCH v3 1/3] ARM: shmobile: r8a7790: add Ether support
In-Reply-To: <1372652755-16948-1-git-send-email-horms+renesas@verge.net.au>
References: <1372652755-16948-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1372652755-16948-2-git-send-email-horms+renesas@verge.net.au>

Add Ether clock and platform device for R8A7779 SoC; add a function to
register this device with board-specific platform data.

Based on a similar change for the r8a7779 by Sergei Shtylyov.

Cc: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

This patch has a run-time dependency on "sh_eth: add support for r8a7790 SoC".

v3
* Use newly added "r8a7790-ether" instead of "sh-eth"

v2
* Do not add MSTP812, EtherAVB. It is not used.
* As suggested by Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
  - Move Ethernet element of MSTP enum to a separate line
  - Move declaration of r8a7790_add_ether_device() to immediately
    after that of r8a7790_add_standard_devices()
  - Add __initdata annotation to ether_resource.
---
 arch/arm/mach-shmobile/clock-r8a7790.c        |  4 ++++
 arch/arm/mach-shmobile/include/mach/r8a7790.h |  3 +++
 arch/arm/mach-shmobile/setup-r8a7790.c        | 14 ++++++++++++++
 3 files changed, 21 insertions(+)

diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c b/arch/arm/mach-shmobile/clock-r8a7790.c
index 62d8162..2f52c0f 100644
--- a/arch/arm/mach-shmobile/clock-r8a7790.c
+++ b/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -52,6 +52,7 @@
 #define SMSTPCR3 0xe615013c
 #define SMSTPCR5 0xe6150144
 #define SMSTPCR7 0xe615014c
+#define SMSTPCR8 0xe6150990
 
 #define MODEMR		0xE6160060
 #define SDCKCR		0xE6150074
@@ -182,6 +183,7 @@ static struct clk div6_clks[DIV6_NR] = {
 
 /* MSTP */
 enum {
+	MSTP813,
 	MSTP721, MSTP720,
 	MSTP717, MSTP716,
 	MSTP522,
@@ -192,6 +194,7 @@ enum {
 };
 
 static struct clk mstp_clks[MSTP_NR] = {
+	[MSTP813] = SH_CLK_MSTP32(&p_clk, SMSTPCR8, 13, 0), /* Ether */
 	[MSTP721] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 21, 0), /* SCIF0 */
 	[MSTP720] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 20, 0), /* SCIF1 */
 	[MSTP717] = SH_CLK_MSTP32(&zs_clk, SMSTPCR7, 17, 0), /* HSCIF0 */
@@ -260,6 +263,7 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh-sci.7", &mstp_clks[MSTP720]),
 	CLKDEV_DEV_ID("sh-sci.8", &mstp_clks[MSTP717]),
 	CLKDEV_DEV_ID("sh-sci.9", &mstp_clks[MSTP716]),
+	CLKDEV_DEV_ID("r8a7790-ether", &mstp_clks[MSTP813]),
 	CLKDEV_DEV_ID("rcar_thermal", &mstp_clks[MSTP522]),
 	CLKDEV_DEV_ID("ee200000.mmcif", &mstp_clks[MSTP315]),
 	CLKDEV_DEV_ID("sh_mmcif.0", &mstp_clks[MSTP315]),
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h b/arch/arm/mach-shmobile/include/mach/r8a7790.h
index 7851cc1..b827b49 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7790.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7790.h
@@ -1,7 +1,10 @@
 #ifndef __ASM_R8A7790_H__
 #define __ASM_R8A7790_H__
 
+#include <linux/sh_eth.h>
+
 void r8a7790_add_standard_devices(void);
+void r8a7790_add_ether_device(struct sh_eth_plat_data *pdata);
 void r8a7790_clock_init(void);
 void r8a7790_pinmux_init(void);
 void r8a7790_init_delay(void);
diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index d89cd83..fad4251 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -31,6 +31,20 @@
 #include <mach/r8a7790.h>
 #include <asm/mach/arch.h>
 
+/* Ether */
+static struct resource ether_resources[] __initdata = {
+	DEFINE_RES_MEM(0xee700000, 0x400),
+	DEFINE_RES_IRQ(gic_spi(162)), /* IRQ0 */
+};
+
+void __init r8a7790_add_ether_device(struct sh_eth_plat_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "r8a7790-ether", -1,
+					  ether_resources,
+					  ARRAY_SIZE(ether_resources),
+					  pdata, sizeof(*pdata));
+}
+
 static struct resource pfc_resources[] __initdata = {
 	DEFINE_RES_MEM(0xe6060000, 0x250),
 };
-- 
1.8.2.1



From B37400 at freescale.com  Mon Jul  1 00:59:18 2013
From: B37400 at freescale.com (Singh Sandeep-B37400)
Date: Mon, 1 Jul 2013 04:59:18 +0000
Subject: [1/4] Device tree entry for Freescale TDM controller
In-Reply-To: <20130628221545.GA9357@home.buserror.net>
References: <1362655668-26721-1-git-send-email-Sandeep@freescale.com>
 <20130628221545.GA9357@home.buserror.net>
Message-ID: <3F1D9DCAAB49B94D88DBE05911FA4E6E070D48EC@039-SN1MPN1-001.039d.mgd.msft.net>

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: 29 June 2013 03:46
> To: Singh Sandeep-B37400
> Cc: linuxppc-dev at lists.ozlabs.org; linux-arm-kernel at lists.infradead.org;
> Aggrwal Poonam-B10812
> Subject: Re: [1/4] Device tree entry for Freescale TDM controller
> 
> On Thu, Mar 07, 2013 at 04:57:45PM +0530, Sandeep Singh wrote:
> > +tdm at 16000 {
> > +	compatible = "fsl,tdm1.0";
> > +	reg = <0x16000 0x200 0x2c000 0x2000>;
> > +	clock-frequency = <0>;
> > +	tdm_tx_clk = <2048000>;
> > +	interrupts = <62 8 0 0>;
> > +	fsl,max-time-slots = <128>;
> > +};
> 
> tdm_tx_clk isn't in the binding (and should be named fsl,tdm-tx-clk if it
> is meant to be here at all).

I will add it in the binding.

Thanks,
Sandeep
> 
> -Scott



From jg1.han at samsung.com  Mon Jul  1 01:22:04 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Mon, 01 Jul 2013 14:22:04 +0900
Subject: [PATCH V3 0/3] Generic PHY driver for the Exynos SoC DP PHY
Message-ID: <005101ce761a$ec7d6070$c5782150$@samsung.com>

This patch series adds a simple driver for the Samsung Exynos SoC
series DP transmitter PHY, using the generic PHY framework [1].
Previously the DP PHY used a platform callback or internal DT node
to control the PHY power enable bit.
The platform callback and internal DT node can be dropped and this
driver does not need any calls back to the platform code.

These patches was tested on Exynos5250.

This PATCH v3 follows:
 * PATCH v2, sent on June, 28th 2013
 * PATCH v1, sent on June, 28th 2013

Changes between v2 and v3:
  * Removed redundant spinlock
  * Removed 'struct phy' from 'struct exynos_dp_video_phy'
  * Updated 'samsung-phy.txt', instead of creating
    'samsung,exynos5250-dp-video-phy.txt'.
  * Removed unnecessary additional specifier from 'phys'
    DT property.
  * Added 'phys', 'phy-names' properties to 'exynos_dp.txt' file.
  * Added Felipe Balbi's Acked-by.

Changes between v1 and v2:
  * Replaced exynos_dp_video_phy_xlate() with of_phy_simple_xlate(),
    as Kishon Vijay Abraham I guided.
  * Set the value of phy-cells as 0, because the phy_provider implements
    only one PHY.
  * Removed unnecessary header include.
  * Added '#ifdef CONFIG_OF' and of_match_ptr macro.

This series depends on the generic PHY framework [1]. These patches
refer to Sylwester Nawrocki's patches about Exynos MIPI [2].

[1] https://lkml.org/lkml/2013/6/26/259
[2] http://www.spinics.net/lists/linux-samsung-soc/msg20098.html

Jingoo Han (3):
  ARM: dts: Add DP PHY node to exynos5250.dtsi
  phy: Add driver for Exynos DP PHY
  video: exynos_dp: Use the generic PHY driver

 .../devicetree/bindings/phy/samsung-phy.txt        |    8 ++
 .../devicetree/bindings/video/exynos_dp.txt        |   23 +---
 arch/arm/boot/dts/exynos5250.dtsi                  |   13 ++++++++-----
 drivers/phy/Kconfig                                |    5 +
 drivers/phy/Makefile                               |    1 +
 drivers/phy/phy-exynos-dp-video.c                  |  118 ++++++++++++++++++++
 drivers/video/exynos/exynos_dp_core.c              |  118 ++------------------
 drivers/video/exynos/exynos_dp_core.h              |    2 +
 include/video/exynos_dp.h                          |    6 +-
 9 files changed, 161 insertions(+), 133 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
 create mode 100644 drivers/phy/phy-exynos-dp-video.c

--
1.7.10.4



From jg1.han at samsung.com  Mon Jul  1 01:23:19 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Mon, 01 Jul 2013 14:23:19 +0900
Subject: [PATCH V3 1/3] ARM: dts: Add DP PHY node to exynos5250.dtsi
Message-ID: <005201ce761b$1903ff50$4b0bfdf0$@samsung.com>

Add PHY provider node for the DP PHY.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/boot/dts/exynos5250.dtsi |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 41cd625..7e397c6 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -614,6 +614,12 @@
 		interrupts = <0 94 0>;
 	};
 
+	dp_phy: video-phy at 10040720 {
+		compatible = "samsung,exynos5250-dp-video-phy";
+		reg = <0x10040720 4>;
+		#phy-cells = <0>;
+	};
+
 	dp-controller {
 		compatible = "samsung,exynos5-dp";
 		reg = <0x145b0000 0x1000>;
@@ -623,11 +629,8 @@
 		clock-names = "dp";
 		#address-cells = <1>;
 		#size-cells = <0>;
-
-		dptx-phy {
-			reg = <0x10040720>;
-			samsung,enable-mask = <1>;
-		};
+		phys = <&dp_phy>;
+		phy-names = "dp";
 	};
 
 	fimd {
-- 
1.7.10.4




From jg1.han at samsung.com  Mon Jul  1 01:24:02 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Mon, 01 Jul 2013 14:24:02 +0900
Subject: [PATCH V3 2/3] phy: Add driver for Exynos DP PHY
Message-ID: <005301ce761b$32adf960$9809ec20$@samsung.com>

Add a PHY provider driver for the Samsung Exynos SoC DP PHY.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 .../devicetree/bindings/phy/samsung-phy.txt        |    8 ++
 drivers/phy/Kconfig                                |    5 +
 drivers/phy/Makefile                               |    1 +
 drivers/phy/phy-exynos-dp-video.c                  |  118 ++++++++++++++++++++
 4 files changed, 132 insertions(+)
 create mode 100644 drivers/phy/phy-exynos-dp-video.c

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 5ff208c..3fb656a 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -12,3 +12,11 @@ the PHY specifier identifies the PHY and its meaning is as follows:
   1 - MIPI DSIM 0,
   2 - MIPI CSIS 1,
   3 - MIPI DSIM 1.
+
+Samsung EXYNOS SoC series DP PHY
+-------------------------------------------------
+
+Required properties:
+- compatible : should be "samsung,exynos5250-dp-video-phy";
+- reg : offset and length of the DP PHY register set;
+- #phy-cells : from the generic phy bindings, must be 0;
\ No newline at end of file
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 6f446d0..760f55a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -19,4 +19,9 @@ config PHY_EXYNOS_MIPI_VIDEO
 	help
 	  Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
 	  S5P and EXYNOS SoCs.
+
+config PHY_EXYNOS_DP_VIDEO
+	tristate "EXYNOS SoC series DP PHY driver"
+	help
+	  Support for DP PHY found on Samsung EXYNOS SoCs.
 endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 71d8841..0fd1340 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_GENERIC_PHY)		+= phy-core.o
 obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)	+= phy-exynos-mipi-video.o
+obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)	+= phy-exynos-dp-video.o
diff --git a/drivers/phy/phy-exynos-dp-video.c b/drivers/phy/phy-exynos-dp-video.c
new file mode 100644
index 0000000..75e1d11
--- /dev/null
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -0,0 +1,118 @@
+/*
+ * Samsung EXYNOS SoC series DP PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Jingoo Han <jg1.han at samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+
+/* DPTX_PHY_CONTROL register */
+#define EXYNOS_DPTX_PHY_ENABLE		(1 << 0)
+
+struct exynos_dp_video_phy {
+	void __iomem *regs;
+};
+
+static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int on)
+{
+	void __iomem *addr;
+	u32 reg;
+
+	addr = state->regs;
+
+	reg = readl(addr);
+	if (on)
+		reg |= EXYNOS_DPTX_PHY_ENABLE;
+	else
+		reg &= ~EXYNOS_DPTX_PHY_ENABLE;
+	writel(reg, addr);
+
+	return 0;
+}
+
+static int exynos_dp_video_phy_power_on(struct phy *phy)
+{
+	struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+	return __set_phy_state(state, 1);
+}
+
+static int exynos_dp_video_phy_power_off(struct phy *phy)
+{
+	struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+	return __set_phy_state(state, 0);
+}
+
+static struct phy_ops exynos_dp_video_phy_ops = {
+	.power_on	= exynos_dp_video_phy_power_on,
+	.power_off	= exynos_dp_video_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
+static int exynos_dp_video_phy_probe(struct platform_device *pdev)
+{
+	struct exynos_dp_video_phy *state;
+	struct device *dev = &pdev->dev;
+	struct resource *res;
+	struct phy_provider *phy_provider;
+	struct phy *phy;
+
+	state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
+	if (!state)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+	state->regs = devm_ioremap_resource(dev, res);
+	if (IS_ERR(state->regs))
+		return PTR_ERR(state->regs);
+
+	dev_set_drvdata(dev, state);
+
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	phy = devm_phy_create(dev, 0, &exynos_dp_video_phy_ops, "dp");
+	if (IS_ERR(phy)) {
+		dev_err(dev, "failed to create DP PHY\n");
+		return PTR_ERR(phy);
+	}
+	phy_set_drvdata(phy, state);
+
+	return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_dp_video_phy_of_match[] = {
+	{ .compatible = "samsung,exynos5250-dp-video-phy" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, exynos_dp_video_phy_of_match);
+#endif
+
+static struct platform_driver exynos_dp_video_phy_driver = {
+	.probe	= exynos_dp_video_phy_probe,
+	.driver = {
+		.name	= "exynos-dp-video-phy",
+		.owner	= THIS_MODULE,
+		.of_match_table	= exynos_dp_video_phy_of_match,
+	}
+};
+module_platform_driver(exynos_dp_video_phy_driver);
+
+MODULE_AUTHOR("Jingoo Han <jg1.han at samsung.com>");
+MODULE_DESCRIPTION("Samsung EXYNOS SoC DP PHY driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.10.4




From kishon at ti.com  Mon Jul  1 01:24:28 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 1 Jul 2013 10:54:28 +0530
Subject: [PATCH v3 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
In-Reply-To: <51CF36AB.4010300@gmail.com>
References: <1372258946-15607-1-git-send-email-s.nawrocki@samsung.com>
 <1372258946-15607-2-git-send-email-s.nawrocki@samsung.com>
 <51CD4698.3070409@gmail.com> <51CD6153.5050406@samsung.com>
 <51CEA197.8070207@ti.com> <51CF36AB.4010300@gmail.com>
Message-ID: <51D1128C.90009@ti.com>

Hi,

On Sunday 30 June 2013 01:04 AM, Sylwester Nawrocki wrote:
> Hi,
>
> On 06/29/2013 10:57 AM, Kishon Vijay Abraham I wrote:
>> On Friday 28 June 2013 03:41 PM, Sylwester Nawrocki wrote:
>>> On 06/28/2013 10:17 AM, Hui Wang wrote:
>>>> On 06/26/2013 11:02 PM, Sylwester Nawrocki wrote:
>>>>> Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2
>>>>> receiver and MIPI DSI transmitter DPHYs.
>>>>>
>>>>> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
>>>>> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
>>>>> ---
>>>>> Changes since v2:
>>>>> - adapted to the generic PHY API v9: use phy_set/get_drvdata(),
>>>>> - fixed of_xlate callback to return ERR_PTR() instead of NULL,
>>>>> - namespace cleanup, put "GPL v2" as MODULE_LICENSE, removed pr_debug,
>>>>> - removed phy id check in __set_phy_state().
>>>>> ---
>>>> [...]
>>>>> +
>>>>> + if (IS_EXYNOS_MIPI_DSIM_PHY_ID(id))
>>>>> + reset = EXYNOS_MIPI_PHY_MRESETN;
>>>>> + else
>>>>> + reset = EXYNOS_MIPI_PHY_SRESETN;
>>>>> +
>>>>> + spin_lock_irqsave(&state->slock, flags);
>>>>
>>>> Sorry for one stupid question here, why do you use spin_lock_irqsave()
>>>> rather than spin_lock(),
>>>> I don't see the irq handler will use this spinlock anywhere in this c
>>>> file.
>>>
>>> Yes, there is no chance the PHY users could call the phy ops from within
>>> an interrupt context. Especially now when there is a per phy object
>>> mutex used in the PHY operation helpers. So I'll replace it with plain
>>> spin_lock/unlock. Thank you for the review.
>>
>> Now that PHY ops is already protected, do you really need a spin_lock here?
>
> It is still needed, to synchronize access to the control register from
> two separate PHY objects. The mutex is per PHY object, while the spinlock
> is per PHY provider.

Ok. Makes sense.

Thanks
Kishon


From jg1.han at samsung.com  Mon Jul  1 01:24:52 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Mon, 01 Jul 2013 14:24:52 +0900
Subject: [PATCH V3 3/3] video: exynos_dp: Use the generic PHY driver
Message-ID: <005401ce761b$504d7090$f0e851b0$@samsung.com>

Use the generic PHY API instead of the platform callback to control
the DP PHY. The 'phy_label' field is added to the platform data
structure to allow PHY lookup on non-dt platforms.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 .../devicetree/bindings/video/exynos_dp.txt        |   23 +---
 drivers/video/exynos/exynos_dp_core.c              |  118 ++------------------
 drivers/video/exynos/exynos_dp_core.h              |    2 +
 include/video/exynos_dp.h                          |    6 +-
 4 files changed, 21 insertions(+), 128 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 84f10c1..71645dc 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -1,17 +1,6 @@
 The Exynos display port interface should be configured based on
 the type of panel connected to it.
 
-We use two nodes:
-	-dp-controller node
-	-dptx-phy node(defined inside dp-controller node)
-
-For the DP-PHY initialization, we use the dptx-phy node.
-Required properties for dptx-phy:
-	-reg:
-		Base address of DP PHY register.
-	-samsung,enable-mask:
-		The bit-mask used to enable/disable DP PHY.
-
 For the Panel initialization, we read data from dp-controller node.
 Required properties for dp-controller:
 	-compatible:
@@ -25,6 +14,10 @@ Required properties for dp-controller:
 		from common clock binding: handle to dp clock.
 	-clock-names:
 		from common clock binding: Shall be "dp".
+	-phys:
+		from general phy binding: the phandle for the PHY device.
+	-phy-names:
+		from general phy binding: Should be "dp".
 	-interrupt-parent:
 		phandle to Interrupt combiner node.
 	-samsung,color-space:
@@ -67,12 +60,8 @@ SOC specific portion:
 		interrupt-parent = <&combiner>;
 		clocks = <&clock 342>;
 		clock-names = "dp";
-
-		dptx-phy {
-			reg = <0x10040720>;
-			samsung,enable-mask = <1>;
-		};
-
+		phys = <&dp_phy>;
+		phy-names = "dp";
 	};
 
 Board Specific portion:
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index 12bbede..bac515b 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -19,6 +19,7 @@
 #include <linux/interrupt.h>
 #include <linux/delay.h>
 #include <linux/of.h>
+#include <linux/phy/phy.h>
 
 #include <video/exynos_dp.h>
 
@@ -960,84 +961,15 @@ static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
 		return ERR_PTR(-EINVAL);
 	}
 
-	return pd;
-}
-
-static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
-{
-	struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
-	u32 phy_base;
-	int ret = 0;
-
-	dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
-	if (!dp_phy_node) {
-		dev_err(dp->dev, "could not find dptx-phy node\n");
-		return -ENODEV;
-	}
-
-	if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
-		dev_err(dp->dev, "failed to get reg for dptx-phy\n");
-		ret = -EINVAL;
-		goto err;
-	}
-
-	if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
-				&dp->enable_mask)) {
-		dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
-		ret = -EINVAL;
-		goto err;
-	}
-
-	dp->phy_addr = ioremap(phy_base, SZ_4);
-	if (!dp->phy_addr) {
-		dev_err(dp->dev, "failed to ioremap dp-phy\n");
-		ret = -ENOMEM;
-		goto err;
-	}
-
-err:
-	of_node_put(dp_phy_node);
-
-	return ret;
-}
-
-static void exynos_dp_phy_init(struct exynos_dp_device *dp)
-{
-	u32 reg;
-
-	reg = __raw_readl(dp->phy_addr);
-	reg |= dp->enable_mask;
-	__raw_writel(reg, dp->phy_addr);
-}
-
-static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
-{
-	u32 reg;
+	pd->phy_label = "dp";
 
-	reg = __raw_readl(dp->phy_addr);
-	reg &= ~(dp->enable_mask);
-	__raw_writel(reg, dp->phy_addr);
+	return pd;
 }
 #else
 static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
 {
 	return NULL;
 }
-
-static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
-{
-	return -EINVAL;
-}
-
-static void exynos_dp_phy_init(struct exynos_dp_device *dp)
-{
-	return;
-}
-
-static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
-{
-	return;
-}
 #endif /* CONFIG_OF */
 
 static int exynos_dp_probe(struct platform_device *pdev)
@@ -1061,10 +993,6 @@ static int exynos_dp_probe(struct platform_device *pdev)
 		pdata = exynos_dp_dt_parse_pdata(&pdev->dev);
 		if (IS_ERR(pdata))
 			return PTR_ERR(pdata);
-
-		ret = exynos_dp_dt_parse_phydata(dp);
-		if (ret)
-			return ret;
 	} else {
 		pdata = pdev->dev.platform_data;
 		if (!pdata) {
@@ -1073,6 +1001,10 @@ static int exynos_dp_probe(struct platform_device *pdev)
 		}
 	}
 
+	dp->phy = devm_phy_get(&pdev->dev, pdata->phy_label);
+	if (IS_ERR(dp->phy))
+		return PTR_ERR(dp->phy);
+
 	dp->clock = devm_clk_get(&pdev->dev, "dp");
 	if (IS_ERR(dp->clock)) {
 		dev_err(&pdev->dev, "failed to get clock\n");
@@ -1097,13 +1029,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
 
 	dp->video_info = pdata->video_info;
 
-	if (pdev->dev.of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_init(dp);
-	} else {
-		if (pdata->phy_init)
-			pdata->phy_init();
-	}
+	phy_power_on(dp->phy);
 
 	exynos_dp_init_dp(dp);
 
@@ -1121,42 +1047,27 @@ static int exynos_dp_probe(struct platform_device *pdev)
 
 static int exynos_dp_remove(struct platform_device *pdev)
 {
-	struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
 	struct exynos_dp_device *dp = platform_get_drvdata(pdev);
 
 	flush_work(&dp->hotplug_work);
 
-	if (pdev->dev.of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_exit(dp);
-	} else {
-		if (pdata->phy_exit)
-			pdata->phy_exit();
-	}
+	phy_power_off(dp->phy);
 
 	clk_disable_unprepare(dp->clock);
 
-
 	return 0;
 }
 
 #ifdef CONFIG_PM_SLEEP
 static int exynos_dp_suspend(struct device *dev)
 {
-	struct exynos_dp_platdata *pdata = dev->platform_data;
 	struct exynos_dp_device *dp = dev_get_drvdata(dev);
 
 	disable_irq(dp->irq);
 
 	flush_work(&dp->hotplug_work);
 
-	if (dev->of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_exit(dp);
-	} else {
-		if (pdata->phy_exit)
-			pdata->phy_exit();
-	}
+	phy_power_off(dp->phy);
 
 	clk_disable_unprepare(dp->clock);
 
@@ -1165,16 +1076,9 @@ static int exynos_dp_suspend(struct device *dev)
 
 static int exynos_dp_resume(struct device *dev)
 {
-	struct exynos_dp_platdata *pdata = dev->platform_data;
 	struct exynos_dp_device *dp = dev_get_drvdata(dev);
 
-	if (dev->of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_init(dp);
-	} else {
-		if (pdata->phy_init)
-			pdata->phy_init();
-	}
+	phy_power_on(dp->phy);
 
 	clk_prepare_enable(dp->clock);
 
diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
index 6c567bbf..b3d0328 100644
--- a/drivers/video/exynos/exynos_dp_core.h
+++ b/drivers/video/exynos/exynos_dp_core.h
@@ -42,6 +42,8 @@ struct exynos_dp_device {
 	struct video_info	*video_info;
 	struct link_train	link_train;
 	struct work_struct	hotplug_work;
+
+	struct phy		*phy;
 };
 
 /* exynos_dp_reg.c */
diff --git a/include/video/exynos_dp.h b/include/video/exynos_dp.h
index bd8cabd..f38c9af 100644
--- a/include/video/exynos_dp.h
+++ b/include/video/exynos_dp.h
@@ -122,10 +122,8 @@ struct video_info {
 };
 
 struct exynos_dp_platdata {
-	struct video_info *video_info;
-
-	void (*phy_init)(void);
-	void (*phy_exit)(void);
+	struct video_info	*video_info;
+	const char		*phy_label;
 };
 
 #endif /* _EXYNOS_DP_H */
-- 
1.7.10.4




From magnus.damm at gmail.com  Mon Jul  1 01:41:06 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 14:41:06 +0900
Subject: [PATCH v2 00/07] ARM: shmobile: Remove unused auxdata and callbacks
Message-ID: <20130701054106.19319.46845.sendpatchset@w520>

ARM: shmobile: Remove unused auxdata and callbacks

[PATCH 01/07] ARM: shmobile: Remove unused EMEV2 auxdata and callback
[PATCH 02/07] ARM: shmobile: Remove unused r8a7740 auxdata table
[PATCH 03/07] ARM: shmobile: Remove unused r8a7778 auxdata and callback
[PATCH 04/07] ARM: shmobile: Remove unused r8a7779 auxdata table
[PATCH 05/07] ARM: shmobile: Remove unused sh7372 auxdata table
[PATCH 06/07] ARM: shmobile: Remove unused sh73a0 auxdata table
[PATCH 07/07] ARM: shmobile: Remove redundant r8a7790 callback

Rework the mach-shmobile code to pass NULL to of_platform_populate()
instead of empty lists. This cleans up the code and reduces the
number of lines. New in V2: Remove init_machine() callbacks that
only call of_platform_populate(), thanks to Arnd for his advice!

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Written against renesas.git renesas-next-20130701

 arch/arm/mach-shmobile/setup-emev2.c   |   10 ----------
 arch/arm/mach-shmobile/setup-r8a7740.c |    7 +------
 arch/arm/mach-shmobile/setup-r8a7778.c |   11 -----------
 arch/arm/mach-shmobile/setup-r8a7779.c |    7 +------
 arch/arm/mach-shmobile/setup-r8a7790.c |    5 -----
 arch/arm/mach-shmobile/setup-sh7372.c  |    7 +------
 arch/arm/mach-shmobile/setup-sh73a0.c  |    7 +------
 7 files changed, 4 insertions(+), 50 deletions(-)



From magnus.damm at gmail.com  Mon Jul  1 01:41:15 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 14:41:15 +0900
Subject: [PATCH 01/07] ARM: shmobile: Remove unused EMEV2 auxdata and callback
In-Reply-To: <20130701054106.19319.46845.sendpatchset@w520>
References: <20130701054106.19319.46845.sendpatchset@w520>
Message-ID: <20130701054115.19319.64158.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Replace the SoC-specific callback init_machine() with 
a NULL to use the default code. This cleans up the code
and reduces the number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-emev2.c |   10 ----------
 1 file changed, 10 deletions(-)

--- 0001/arch/arm/mach-shmobile/setup-emev2.c
+++ work/arch/arm/mach-shmobile/setup-emev2.c	2013-07-01 13:19:32.000000000 +0900
@@ -435,15 +435,6 @@ void __init emev2_init_irq(void)
 }
 
 #ifdef CONFIG_USE_OF
-static const struct of_dev_auxdata emev2_auxdata_lookup[] __initconst = {
-	{ }
-};
-
-static void __init emev2_add_standard_devices_dt(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table,
-			     emev2_auxdata_lookup, NULL);
-}
 
 static const char *emev2_boards_compat_dt[] __initdata = {
 	"renesas,emev2",
@@ -455,7 +446,6 @@ DT_MACHINE_START(EMEV2_DT, "Generic Emma
 	.init_early	= emev2_init_delay,
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= irqchip_init,
-	.init_machine	= emev2_add_standard_devices_dt,
 	.dt_compat	= emev2_boards_compat_dt,
 MACHINE_END
 


From magnus.damm at gmail.com  Mon Jul  1 01:41:24 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 14:41:24 +0900
Subject: [PATCH 02/07] ARM: shmobile: Remove unused r8a7740 auxdata table
In-Reply-To: <20130701054106.19319.46845.sendpatchset@w520>
References: <20130701054106.19319.46845.sendpatchset@w520>
Message-ID: <20130701054124.19319.75931.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Pass NULL to of_platform_populate instead of passing
an empty list. This cleans up the code and reduces the
number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-r8a7740.c |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

--- 0001/arch/arm/mach-shmobile/setup-r8a7740.c
+++ work/arch/arm/mach-shmobile/setup-r8a7740.c	2013-06-28 15:43:04.000000000 +0900
@@ -986,16 +986,11 @@ void __init r8a7740_add_early_devices(vo
 
 #ifdef CONFIG_USE_OF
 
-static const struct of_dev_auxdata r8a7740_auxdata_lookup[] __initconst = {
-	{ }
-};
-
 void __init r8a7740_add_standard_devices_dt(void)
 {
 	platform_add_devices(r8a7740_devices_dt,
 			    ARRAY_SIZE(r8a7740_devices_dt));
-	of_platform_populate(NULL, of_default_bus_match_table,
-			     r8a7740_auxdata_lookup, NULL);
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
 void __init r8a7740_init_delay(void)


From magnus.damm at gmail.com  Mon Jul  1 01:41:33 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 14:41:33 +0900
Subject: [PATCH 03/07] ARM: shmobile: Remove unused r8a7778 auxdata and
 callback
In-Reply-To: <20130701054106.19319.46845.sendpatchset@w520>
References: <20130701054106.19319.46845.sendpatchset@w520>
Message-ID: <20130701054133.19319.79856.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Replace the SoC-specific callback init_machine() with 
a NULL to use the default code. This cleans up the code
and reduces the number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-r8a7778.c |   11 -----------
 1 file changed, 11 deletions(-)

--- 0001/arch/arm/mach-shmobile/setup-r8a7778.c
+++ work/arch/arm/mach-shmobile/setup-r8a7778.c	2013-07-01 13:21:05.000000000 +0900
@@ -457,16 +457,6 @@ void __init r8a7778_init_irq_dt(void)
 	r8a7778_init_irq_common();
 }
 
-static const struct of_dev_auxdata r8a7778_auxdata_lookup[] __initconst = {
-	{},
-};
-
-void __init r8a7778_add_standard_devices_dt(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table,
-			     r8a7778_auxdata_lookup, NULL);
-}
-
 static const char *r8a7778_compat_dt[] __initdata = {
 	"renesas,r8a7778",
 	NULL,
@@ -475,7 +465,6 @@ static const char *r8a7778_compat_dt[] _
 DT_MACHINE_START(R8A7778_DT, "Generic R8A7778 (Flattened Device Tree)")
 	.init_early	= r8a7778_init_delay,
 	.init_irq	= r8a7778_init_irq_dt,
-	.init_machine	= r8a7778_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a7778_compat_dt,
 	.init_late      = r8a7778_init_late,


From magnus.damm at gmail.com  Mon Jul  1 01:41:46 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 14:41:46 +0900
Subject: [PATCH 04/07] ARM: shmobile: Remove unused r8a7779 auxdata table
In-Reply-To: <20130701054106.19319.46845.sendpatchset@w520>
References: <20130701054106.19319.46845.sendpatchset@w520>
Message-ID: <20130701054146.19319.86285.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Pass NULL to of_platform_populate instead of passing
an empty list. This cleans up the code and reduces the
number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-r8a7779.c |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

--- 0001/arch/arm/mach-shmobile/setup-r8a7779.c
+++ work/arch/arm/mach-shmobile/setup-r8a7779.c	2013-06-28 15:49:50.000000000 +0900
@@ -665,10 +665,6 @@ void __init r8a7779_init_delay(void)
 	shmobile_setup_delay(1000, 2, 4); /* Cortex-A9 @ 1000MHz */
 }
 
-static const struct of_dev_auxdata r8a7779_auxdata_lookup[] __initconst = {
-	{},
-};
-
 void __init r8a7779_add_standard_devices_dt(void)
 {
 	/* clocks are setup late during boot in the case of DT */
@@ -676,8 +672,7 @@ void __init r8a7779_add_standard_devices
 
 	platform_add_devices(r8a7779_devices_dt,
 			     ARRAY_SIZE(r8a7779_devices_dt));
-	of_platform_populate(NULL, of_default_bus_match_table,
-			     r8a7779_auxdata_lookup, NULL);
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
 static const char *r8a7779_compat_dt[] __initdata = {


From magnus.damm at gmail.com  Mon Jul  1 01:41:55 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 14:41:55 +0900
Subject: [PATCH 05/07] ARM: shmobile: Remove unused sh7372 auxdata table
In-Reply-To: <20130701054106.19319.46845.sendpatchset@w520>
References: <20130701054106.19319.46845.sendpatchset@w520>
Message-ID: <20130701054155.19319.19762.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Pass NULL to of_platform_populate instead of passing
an empty list. This cleans up the code and reduces the
number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-sh7372.c |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

--- 0001/arch/arm/mach-shmobile/setup-sh7372.c
+++ work/arch/arm/mach-shmobile/setup-sh7372.c	2013-06-28 15:41:15.000000000 +0900
@@ -1147,10 +1147,6 @@ void __init sh7372_add_early_devices_dt(
 	shmobile_setup_console();
 }
 
-static const struct of_dev_auxdata sh7372_auxdata_lookup[] __initconst = {
-	{ }
-};
-
 void __init sh7372_add_standard_devices_dt(void)
 {
 	/* clocks are setup late during boot in the case of DT */
@@ -1159,8 +1155,7 @@ void __init sh7372_add_standard_devices_
 	platform_add_devices(sh7372_early_devices,
 			    ARRAY_SIZE(sh7372_early_devices));
 
-	of_platform_populate(NULL, of_default_bus_match_table,
-			     sh7372_auxdata_lookup, NULL);
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
 static const char *sh7372_boards_compat_dt[] __initdata = {


From magnus.damm at gmail.com  Mon Jul  1 01:42:04 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 14:42:04 +0900
Subject: [PATCH 06/07] ARM: shmobile: Remove unused sh73a0 auxdata table
In-Reply-To: <20130701054106.19319.46845.sendpatchset@w520>
References: <20130701054106.19319.46845.sendpatchset@w520>
Message-ID: <20130701054204.19319.68354.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Pass NULL to of_platform_populate instead of passing
an empty list. This cleans up the code and reduces the
number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-sh73a0.c |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

--- 0001/arch/arm/mach-shmobile/setup-sh73a0.c
+++ work/arch/arm/mach-shmobile/setup-sh73a0.c	2013-06-28 19:16:07.000000000 +0900
@@ -958,10 +958,6 @@ void __init sh73a0_add_early_devices(voi
 
 #ifdef CONFIG_USE_OF
 
-static const struct of_dev_auxdata sh73a0_auxdata_lookup[] __initconst = {
-	{},
-};
-
 void __init sh73a0_add_standard_devices_dt(void)
 {
 	struct platform_device_info devinfo = { .name = "cpufreq-cpu0", .id = -1, };
@@ -971,8 +967,7 @@ void __init sh73a0_add_standard_devices_
 
 	platform_add_devices(sh73a0_devices_dt,
 			     ARRAY_SIZE(sh73a0_devices_dt));
-	of_platform_populate(NULL, of_default_bus_match_table,
-			     sh73a0_auxdata_lookup, NULL);
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 
 	/* Instantiate cpufreq-cpu0 */
 	platform_device_register_full(&devinfo);


From magnus.damm at gmail.com  Mon Jul  1 01:42:13 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 14:42:13 +0900
Subject: [PATCH 07/07] ARM: shmobile: Remove redundant r8a7790 callback
In-Reply-To: <20130701054106.19319.46845.sendpatchset@w520>
References: <20130701054106.19319.46845.sendpatchset@w520>
Message-ID: <20130701054213.19319.40704.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Replace the SoC-specific callback init_machine() with 
a NULL to use the default code. This cleans up the code
and reduces the number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-r8a7790.c |    5 -----
 1 file changed, 5 deletions(-)

--- 0001/arch/arm/mach-shmobile/setup-r8a7790.c
+++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-07-01 13:24:33.000000000 +0900
@@ -217,10 +217,6 @@ void __init r8a7790_init_delay(void)
 }
 
 #ifdef CONFIG_USE_OF
-void __init r8a7790_add_standard_devices_dt(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-}
 
 static const char *r8a7790_boards_compat_dt[] __initdata = {
 	"renesas,r8a7790",
@@ -230,7 +226,6 @@ static const char *r8a7790_boards_compat
 DT_MACHINE_START(R8A7790_DT, "Generic R8A7790 (Flattened Device Tree)")
 	.init_early	= r8a7790_init_delay,
 	.init_irq	= irqchip_init,
-	.init_machine	= r8a7790_add_standard_devices_dt,
 	.init_time	= r8a7790_timer_init,
 	.dt_compat	= r8a7790_boards_compat_dt,
 MACHINE_END


From wsa at the-dreams.de  Mon Jul  1 01:50:51 2013
From: wsa at the-dreams.de (Wolfram Sang)
Date: Mon, 1 Jul 2013 07:50:51 +0200
Subject: [PATCH] i2c: iop3xxx: fix build failure after waitqueue changes
In-Reply-To: <1372455352-26260-1-git-send-email-khilman@linaro.org>
References: <1372455352-26260-1-git-send-email-khilman@linaro.org>
Message-ID: <20130701055051.GA2976@katana>

On Fri, Jun 28, 2013 at 02:35:52PM -0700, Kevin Hilman wrote:
> There has long been a syntax problem in iop3xx_i2c_wait_event() which
> has been somehow hidden by the macros in <linux/wait.h>.  After some
> recent cleanup/rework of the wait_event_* helpers, the bug has come
> out from hiding and now results in build failure:
> 
> /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c: In function 'iop3xx_i2c_wait_event':
> /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:143: error: expected ')' before ';' token
> /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:157: error: expected ')' before ';' token
> /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:213: error: expected ')' before ';' token
> /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:291: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
> /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:551: error: expected ')' before ';' token
> /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:565: error: expected ')' before ';' token
> /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:764: error: expected ')' before ';' token
> /work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:778: error: expected ')' b
> 
> Fix by removing stray ';'
> 
> Signed-off-by: Kevin Hilman <khilman at linaro.org>

Applied to for-next, thanks! (Geez, that original code looks ugly...)

-------------- 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/20130701/27ff2488/attachment.sig>

From magnus.damm at gmail.com  Mon Jul  1 02:01:03 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 15:01:03 +0900
Subject: [PATCH 00/04] ARM: shmobile: Use default ->init_irq()
Message-ID: <20130701060103.21728.83833.sendpatchset@w520>

ARM: shmobile: Use default ->init_irq()

[PATCH 01/04] ARM: shmobile: Use default ->init_irq() on EMEV2
[PATCH 02/04] ARM: shmobile: Use default ->init_irq() on r8a73a4
[PATCH 03/04] ARM: shmobile: Use default ->init_irq() on r8a7790
[PATCH 04/04] ARM: shmobile: Use default ->init_irq() on sh73a0

Rework the mach-shmobile code to provide NULL as ->init_irq() callback
instead of irqchip_init(). This cleans up the code and reduces the
number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Written against renesas.git renesas-next-20130701 and
 [PATCH v2 00/07] ARM: shmobile: Remove unused auxdata and callbacks

 arch/arm/mach-shmobile/board-ape6evm.c         |    2 --
 arch/arm/mach-shmobile/board-kzm9g-reference.c |    2 --
 arch/arm/mach-shmobile/board-lager.c           |    2 --
 arch/arm/mach-shmobile/setup-emev2.c           |    2 --
 arch/arm/mach-shmobile/setup-r8a73a4.c         |    2 --
 arch/arm/mach-shmobile/setup-r8a7790.c         |    2 --
 arch/arm/mach-shmobile/setup-sh73a0.c          |    2 --
 7 files changed, 14 deletions(-)


From magnus.damm at gmail.com  Mon Jul  1 02:01:12 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 15:01:12 +0900
Subject: [PATCH 01/04] ARM: shmobile: Use default ->init_irq() on EMEV2
In-Reply-To: <20130701060103.21728.83833.sendpatchset@w520>
References: <20130701060103.21728.83833.sendpatchset@w520>
Message-ID: <20130701060112.21728.37189.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove redundant irqchip_init() callback. The default case
of NULL will result in invoking irqchip_init() anyway.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-emev2.c |    2 --
 1 file changed, 2 deletions(-)

--- 0005/arch/arm/mach-shmobile/setup-emev2.c
+++ work/arch/arm/mach-shmobile/setup-emev2.c	2013-07-01 13:33:39.000000000 +0900
@@ -20,7 +20,6 @@
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
-#include <linux/irqchip.h>
 #include <linux/platform_device.h>
 #include <linux/platform_data/gpio-em.h>
 #include <linux/of_platform.h>
@@ -445,7 +444,6 @@ DT_MACHINE_START(EMEV2_DT, "Generic Emma
 	.smp		= smp_ops(emev2_smp_ops),
 	.init_early	= emev2_init_delay,
 	.nr_irqs	= NR_IRQS_LEGACY,
-	.init_irq	= irqchip_init,
 	.dt_compat	= emev2_boards_compat_dt,
 MACHINE_END
 


From magnus.damm at gmail.com  Mon Jul  1 02:01:21 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 15:01:21 +0900
Subject: [PATCH 02/04] ARM: shmobile: Use default ->init_irq() on r8a73a4
In-Reply-To: <20130701060103.21728.83833.sendpatchset@w520>
References: <20130701060103.21728.83833.sendpatchset@w520>
Message-ID: <20130701060121.21728.18844.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove redundant irqchip_init() callback. The default case
of NULL will result in invoking irqchip_init() anyway.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-ape6evm.c |    2 --
 arch/arm/mach-shmobile/setup-r8a73a4.c |    2 --
 2 files changed, 4 deletions(-)

--- 0001/arch/arm/mach-shmobile/board-ape6evm.c
+++ work/arch/arm/mach-shmobile/board-ape6evm.c	2013-07-01 13:29:37.000000000 +0900
@@ -20,7 +20,6 @@
 
 #include <linux/gpio.h>
 #include <linux/interrupt.h>
-#include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/platform_device.h>
@@ -103,7 +102,6 @@ static const char *ape6evm_boards_compat
 
 DT_MACHINE_START(APE6EVM_DT, "ape6evm")
 	.init_early	= r8a73a4_init_delay,
-	.init_irq	= irqchip_init,
 	.init_time	= shmobile_timer_init,
 	.init_machine	= ape6evm_add_standard_devices,
 	.dt_compat	= ape6evm_boards_compat_dt,
--- 0001/arch/arm/mach-shmobile/setup-r8a73a4.c
+++ work/arch/arm/mach-shmobile/setup-r8a73a4.c	2013-07-01 13:29:53.000000000 +0900
@@ -18,7 +18,6 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  */
 #include <linux/irq.h>
-#include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/of_platform.h>
 #include <linux/platform_data/irq-renesas-irqc.h>
@@ -224,7 +223,6 @@ static const char *r8a73a4_boards_compat
 
 DT_MACHINE_START(R8A73A4_DT, "Generic R8A73A4 (Flattened Device Tree)")
 	.init_early	= r8a73a4_init_delay,
-	.init_irq	= irqchip_init,
 	.init_machine	= r8a73a4_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a73a4_boards_compat_dt,


From magnus.damm at gmail.com  Mon Jul  1 02:01:31 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 15:01:31 +0900
Subject: [PATCH 03/04] ARM: shmobile: Use default ->init_irq() on r8a7790
In-Reply-To: <20130701060103.21728.83833.sendpatchset@w520>
References: <20130701060103.21728.83833.sendpatchset@w520>
Message-ID: <20130701060131.21728.85765.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove redundant irqchip_init() callback. The default case
of NULL will result in invoking irqchip_init() anyway.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-lager.c   |    2 --
 arch/arm/mach-shmobile/setup-r8a7790.c |    2 --
 2 files changed, 4 deletions(-)

--- 0001/arch/arm/mach-shmobile/board-lager.c
+++ work/arch/arm/mach-shmobile/board-lager.c	2013-07-01 13:27:30.000000000 +0900
@@ -22,7 +22,6 @@
 #include <linux/gpio_keys.h>
 #include <linux/input.h>
 #include <linux/interrupt.h>
-#include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/leds.h>
 #include <linux/pinctrl/machine.h>
@@ -104,7 +103,6 @@ static const char *lager_boards_compat_d
 
 DT_MACHINE_START(LAGER_DT, "lager")
 	.init_early	= r8a7790_init_delay,
-	.init_irq	= irqchip_init,
 	.init_time	= r8a7790_timer_init,
 	.init_machine	= lager_add_standard_devices,
 	.dt_compat	= lager_boards_compat_dt,
--- 0008/arch/arm/mach-shmobile/setup-r8a7790.c
+++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-07-01 13:27:52.000000000 +0900
@@ -19,7 +19,6 @@
  */
 
 #include <linux/irq.h>
-#include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/of_platform.h>
 #include <linux/platform_data/gpio-rcar.h>
@@ -225,7 +224,6 @@ static const char *r8a7790_boards_compat
 
 DT_MACHINE_START(R8A7790_DT, "Generic R8A7790 (Flattened Device Tree)")
 	.init_early	= r8a7790_init_delay,
-	.init_irq	= irqchip_init,
 	.init_time	= r8a7790_timer_init,
 	.dt_compat	= r8a7790_boards_compat_dt,
 MACHINE_END


From magnus.damm at gmail.com  Mon Jul  1 02:01:40 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 15:01:40 +0900
Subject: [PATCH 04/04] ARM: shmobile: Use default ->init_irq() on sh73a0
In-Reply-To: <20130701060103.21728.83833.sendpatchset@w520>
References: <20130701060103.21728.83833.sendpatchset@w520>
Message-ID: <20130701060140.21728.27213.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove redundant irqchip_init() callback. The default case
of NULL will result in invoking irqchip_init() anyway.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-kzm9g-reference.c |    2 --
 arch/arm/mach-shmobile/setup-sh73a0.c          |    2 --
 2 files changed, 4 deletions(-)

--- 0001/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ work/arch/arm/mach-shmobile/board-kzm9g-reference.c	2013-06-28 16:04:39.000000000 +0900
@@ -24,7 +24,6 @@
 #include <linux/gpio.h>
 #include <linux/io.h>
 #include <linux/irq.h>
-#include <linux/irqchip.h>
 #include <linux/input.h>
 #include <linux/of_platform.h>
 #include <linux/pinctrl/machine.h>
@@ -99,7 +98,6 @@ DT_MACHINE_START(KZM9G_DT, "kzm9g-refere
 	.map_io		= sh73a0_map_io,
 	.init_early	= sh73a0_init_delay,
 	.nr_irqs	= NR_IRQS_LEGACY,
-	.init_irq	= irqchip_init,
 	.init_machine	= kzm_init,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= kzm9g_boards_compat_dt,
--- 0007/arch/arm/mach-shmobile/setup-sh73a0.c
+++ work/arch/arm/mach-shmobile/setup-sh73a0.c	2013-06-28 16:04:47.000000000 +0900
@@ -22,7 +22,6 @@
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
-#include <linux/irqchip.h>
 #include <linux/platform_device.h>
 #include <linux/of_platform.h>
 #include <linux/delay.h>
@@ -983,7 +982,6 @@ DT_MACHINE_START(SH73A0_DT, "Generic SH7
 	.map_io		= sh73a0_map_io,
 	.init_early	= sh73a0_init_delay,
 	.nr_irqs	= NR_IRQS_LEGACY,
-	.init_irq	= irqchip_init,
 	.init_machine	= sh73a0_add_standard_devices_dt,
 	.dt_compat	= sh73a0_boards_compat_dt,
 MACHINE_END


From magnus.damm at gmail.com  Mon Jul  1 02:13:40 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 15:13:40 +0900
Subject: [PATCH] ARM: shmobile: r8a7790 SMP prototype v3
Message-ID: <20130701061340.22064.93012.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Add SMP prototype support for r8a7790 by enabling
one cluster of either 4 x Cortex-A7 or 4 x Cortex-A15.

This patch only adds support for booting, at this point
no CPU Hotplug is included. Both the big and the LITTLE
cluster are working at this point, but in case of LITTLE
broadcast timer and CMT are known to work while CA7 arch
timer support needs more work.

On r8a7790 the MD6 pin control boot processor, and on the
Lager board SW8.7 can be used to select big or LITTLE.

In big boot mode the CPU cores will be configured as:
 - CPU0, CPU1, CPU2, CPU3: enabled (CA15)
 - CPU4, CPU5, CPU6, CPU7: disabled (CA7)

In LITTLE boot mode the CPU cores will be configured as:
 - CPU0, CPU5, CPU6, CPU7: enabled (CA7)
 - CPU1, CPU2, CPU3, CPU4: disabled (CA15)

In case of LITTLE boot mode make sure to disable arch timer
support in the kernel config with CONFIG_HAVE_ARM_ARCH_TIMER=n.

Signed-off-by: Magnus Damm <damm at opensource.se>
---
 Written against renesas.git renesas-next-20130701 and
 [PATCH v2 00/07] ARM: shmobile: Remove unused auxdata and callbacks
 [PATCH 00/04] ARM: shmobile: Use default ->init_irq()

 arch/arm/boot/dts/r8a7790.dtsi                |   49 ++++++
 arch/arm/mach-shmobile/Makefile               |    1 
 arch/arm/mach-shmobile/board-lager.c          |    1 
 arch/arm/mach-shmobile/include/mach/common.h  |    1 
 arch/arm/mach-shmobile/include/mach/r8a7790.h |    1 
 arch/arm/mach-shmobile/setup-r8a7790.c        |    1 
 arch/arm/mach-shmobile/smp-r8a7790.c          |  187 +++++++++++++++++++++++++
 7 files changed, 241 insertions(+)

--- 0001/arch/arm/boot/dts/r8a7790.dtsi
+++ work/arch/arm/boot/dts/r8a7790.dtsi	2013-07-01 13:41:31.000000000 +0900
@@ -24,6 +24,55 @@
 			reg = <0>;
 			clock-frequency = <1300000000>;
 		};
+
+		cpu1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <1>;
+			clock-frequency = <1300000000>;
+		};
+
+		cpu2: cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <2>;
+			clock-frequency = <1300000000>;
+		};
+
+		cpu3: cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <3>;
+			clock-frequency = <1300000000>;
+		};
+
+		cpu4: cpu at 4 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x100>;
+			clock-frequency = <780000000>;
+		};
+
+		cpu5: cpu at 5 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x101>;
+			clock-frequency = <780000000>;
+		};
+
+		cpu6: cpu at 6 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x102>;
+			clock-frequency = <780000000>;
+		};
+
+		cpu7: cpu at 7 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x103>;
+			clock-frequency = <780000000>;
+		};
 	};
 
 	gic: interrupt-controller at f1001000 {
--- 0001/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-07-01 13:41:31.000000000 +0900
@@ -19,6 +19,7 @@ obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.
 smp-y				:= platsmp.o headsmp.o
 smp-$(CONFIG_ARCH_SH73A0)	+= smp-sh73a0.o headsmp-scu.o
 smp-$(CONFIG_ARCH_R8A7779)	+= smp-r8a7779.o headsmp-scu.o
+smp-$(CONFIG_ARCH_R8A7790)	+= smp-r8a7790.o
 smp-$(CONFIG_ARCH_EMEV2)	+= smp-emev2.o headsmp-scu.o
 
 # IRQ objects
--- 0009/arch/arm/mach-shmobile/board-lager.c
+++ work/arch/arm/mach-shmobile/board-lager.c	2013-07-01 13:41:31.000000000 +0900
@@ -102,6 +102,7 @@ static const char *lager_boards_compat_d
 };
 
 DT_MACHINE_START(LAGER_DT, "lager")
+	.smp		= smp_ops(r8a7790_smp_ops),
 	.init_early	= r8a7790_init_delay,
 	.init_time	= r8a7790_timer_init,
 	.init_machine	= lager_add_standard_devices,
--- 0001/arch/arm/mach-shmobile/include/mach/common.h
+++ work/arch/arm/mach-shmobile/include/mach/common.h	2013-07-01 13:41:31.000000000 +0900
@@ -11,6 +11,7 @@ extern void shmobile_boot_vector(void);
 extern unsigned long shmobile_boot_fn;
 extern unsigned long shmobile_boot_arg;
 extern void shmobile_boot_scu(void);
+extern void shmobile_invalidate_start(void);
 struct clk;
 extern int shmobile_clk_init(void);
 extern void shmobile_handle_irq_intc(struct pt_regs *);
--- 0001/arch/arm/mach-shmobile/include/mach/r8a7790.h
+++ work/arch/arm/mach-shmobile/include/mach/r8a7790.h	2013-07-01 13:41:31.000000000 +0900
@@ -6,5 +6,6 @@ void r8a7790_clock_init(void);
 void r8a7790_pinmux_init(void);
 void r8a7790_init_delay(void);
 void r8a7790_timer_init(void);
+extern struct smp_operations r8a7790_smp_ops;
 
 #endif /* __ASM_R8A7790_H__ */
--- 0009/arch/arm/mach-shmobile/setup-r8a7790.c
+++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-07-01 13:41:31.000000000 +0900
@@ -223,6 +223,7 @@ static const char *r8a7790_boards_compat
 };
 
 DT_MACHINE_START(R8A7790_DT, "Generic R8A7790 (Flattened Device Tree)")
+	.smp		= smp_ops(r8a7790_smp_ops),
 	.init_early	= r8a7790_init_delay,
 	.init_time	= r8a7790_timer_init,
 	.dt_compat	= r8a7790_boards_compat_dt,
--- /dev/null
+++ work/arch/arm/mach-shmobile/smp-r8a7790.c	2013-07-01 13:41:32.000000000 +0900
@@ -0,0 +1,187 @@
+/*
+ * SMP support for r8a7790
+ *
+ * Copyright (C) 2012-2013 Renesas Solutions Corp.
+ * Copyright (C) 2012 Takashi Yoshii <takashi.yoshii.ze at renesas.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/delay.h>
+#include <linux/jiffies.h>
+#include <linux/smp.h>
+#include <linux/irqchip/arm-gic.h>
+#include <asm/cacheflush.h>
+#include <asm/io.h>
+#include <asm/smp_plat.h>
+#include <asm/suspend.h>
+#include <mach/common.h>
+#include <mach/hardware.h>
+
+#include <asm/cacheflush.h>
+#include <asm/cp15.h>
+#include <asm/smp_plat.h>
+
+#define SYSC	0xe6180000
+#define SYSCSR  0x0000
+
+#define RST	0xe6160000
+#define CA15BAR	0x6020
+#define CA15RESCNT 0x0040
+#define CA7BAR	0x4030
+#define CA7RESCNT 0x0044
+#define RESCNT	0x0050
+
+#define APMU	0xe6150000
+#define CA15WUPCR 0x2010
+#define CA7WUPCR 0x1010
+
+#define MERAM	0xe8080000
+
+enum { R8A7790_CLST_CA15, R8A7790_CLST_CA7, R8A7790_CLST_NR };
+
+static struct {
+	unsigned int cabar;
+	unsigned int carescnt;
+	unsigned int carescnt_magic;
+	unsigned int rescnt_bit;
+	unsigned int use_count;
+} r8a7790_clst[R8A7790_CLST_NR] = {
+	[R8A7790_CLST_CA15] = {
+		.cabar = CA15BAR,
+		.carescnt = CA15RESCNT,
+		.carescnt_magic = 0xa5a50000,
+		.rescnt_bit = 1,
+	},
+	[R8A7790_CLST_CA7] = {
+		.cabar = CA7BAR,
+		.carescnt = CA7RESCNT,
+		.carescnt_magic = 0x5a5a0000,
+		.rescnt_bit = 0,
+	},
+};
+
+#define r8a7790_clst_id(cpu) (cpu_logical_map((cpu)) >> 8)
+#define r8a7790_cpu_id(cpu) (cpu_logical_map((cpu)) & 0xff)
+
+static void r8a7790_deassert_reset(unsigned int cpu)
+{
+	void __iomem *p, *carescnt;
+	u32 bar, mask, magic;
+	unsigned int clst_id = r8a7790_clst_id(cpu);
+
+	/* setup reset vectors */
+	p = ioremap_nocache(RST, 0x7000);
+	bar = (MERAM >> 8) & 0xfffffc00;
+	__raw_writel(bar, p + r8a7790_clst[clst_id].cabar);
+	__raw_writel(bar | 0x10, p + r8a7790_clst[clst_id].cabar);
+
+	/* enable clocks for cluster */
+	if (r8a7790_clst[clst_id].use_count++ == 0) {
+		mask = 1 << r8a7790_clst[clst_id].rescnt_bit;
+		__raw_writel(__raw_readl(p + RESCNT) & ~mask, p + RESCNT);
+	}
+
+	/* enable per-core clocks */
+	mask = BIT(3 - r8a7790_cpu_id(cpu));
+	magic = r8a7790_clst[clst_id].carescnt_magic;
+	carescnt = p + r8a7790_clst[clst_id].carescnt;
+	__raw_writel((__raw_readl(carescnt) & ~mask) | magic, carescnt);
+
+	iounmap(p);
+}
+
+static void r8a7790_assert_reset(unsigned int cpu)
+{
+	void __iomem *p, *carescnt;
+	u32 mask, magic;
+	unsigned int clst_id = r8a7790_clst_id(cpu);
+
+	p = ioremap_nocache(RST, 0x7000);
+
+	/* disable per-core clocks */
+	mask = BIT(3 - r8a7790_cpu_id(cpu));
+	magic = r8a7790_clst[clst_id].carescnt_magic;
+	carescnt = p + r8a7790_clst[clst_id].carescnt;
+	__raw_writel((__raw_readl(carescnt) | mask) | magic, carescnt);
+
+	/* disable clocks for cluster */
+	if (r8a7790_clst[clst_id].use_count == 1) {
+		mask = 1 << r8a7790_clst[clst_id].rescnt_bit;
+		__raw_writel(__raw_readl(p + RESCNT) | mask, p + RESCNT);
+	}
+
+	if (r8a7790_clst[clst_id].use_count > 0)
+		r8a7790_clst[clst_id].use_count--;
+
+	iounmap(p);
+}
+
+static void r8a7790_power_on(unsigned int cpu)
+{
+	void __iomem *p, *p2, *cawupcr;
+
+	/* wake up CPU core via APMU */
+	p = ioremap_nocache(APMU, 0x3000);
+	cawupcr = p + (r8a7790_clst_id(cpu) ? CA7WUPCR : CA15WUPCR);
+	__raw_writel(BIT(r8a7790_cpu_id(cpu)), cawupcr);
+
+	/* wait for SYSC to finish wake up sequence */
+	p2 = ioremap_nocache(SYSC, 0x1000);
+	while ((__raw_readl(p2 + SYSCSR) & 0x3) != 0x3)
+		;
+
+	/* wait for APMU to finish */
+	while (__raw_readl(cawupcr) != 0)
+		;
+
+	iounmap(p2);
+	iounmap(p);
+}
+
+static void __init r8a7790_smp_prepare_cpus(unsigned int max_cpus)
+{
+	void __iomem *p;
+	unsigned int k;
+
+	shmobile_boot_fn = virt_to_phys(shmobile_invalidate_start);
+
+	/* MERAM for jump stub, because BAR requires 256KB aligned address */
+	p = ioremap_nocache(MERAM, 16);
+	memcpy(p, shmobile_boot_vector, 16);
+	iounmap(p);
+
+	flush_cache_louis();
+
+	/* keep secondary CPU cores in reset, but powered on */
+	for (k = 1; k < 8; k++) {
+		r8a7790_assert_reset(k);
+		r8a7790_power_on(k);
+	}
+
+	r8a7790_deassert_reset(0);
+}
+
+static int __cpuinit r8a7790_boot_secondary(unsigned int cpu,
+					    struct task_struct *idle)
+{
+	/* only allow a single cluster for now */
+	if (r8a7790_clst_id(cpu) != r8a7790_clst_id(0))
+		return -ENOTSUPP;
+
+	r8a7790_deassert_reset(cpu);
+	return 0;
+}
+
+struct smp_operations r8a7790_smp_ops __initdata = {
+	.smp_prepare_cpus	= r8a7790_smp_prepare_cpus,
+	.smp_boot_secondary	= r8a7790_boot_secondary,
+};


From wsa at the-dreams.de  Mon Jul  1 02:17:22 2013
From: wsa at the-dreams.de (Wolfram Sang)
Date: Mon, 1 Jul 2013 08:17:22 +0200
Subject: [PATCH v10] i2c: exynos5: add High Speed I2C controller driver
In-Reply-To: <1371638905-30633-1-git-send-email-ch.naveen@samsung.com>
References: <1354021236-28596-2-git-send-email-ch.naveen@samsung.com>
 <1371638905-30633-1-git-send-email-ch.naveen@samsung.com>
Message-ID: <20130701061722.GB2976@katana>

On Wed, Jun 19, 2013 at 04:18:25PM +0530, Naveen Krishna Chatradhi wrote:
> Adds support for High Speed I2C driver found in Exynos5 and
> later SoCs from Samsung.
> 
> Driver only supports Device Tree method.
> 
> Changes since v1:
> 1. Added FIFO functionality
> 2. Added High speed mode functionality
> 3. Remove SMBUS_QUICK
> 4. Remove the debugfs functionality
> 5. Use devm_* functions where ever possible
> 6. Driver is free from GPIO configs
> 7. Use OF data string "clock-frequency" to get the bus operating frequencies
> 8. Split the clock divisor calculation function
> 9. Add resets for the failed transacton cases
> 10. Removed retries as core does retries if -EAGAIN is returned
> 11. Removed mode from device tree info (use speed to distinguish
>     the mode of operation)
> 12. Use wait_for_completion_timeout as the interruptible case is not tested well
> 13. few other bug fixes and cosmetic changes
> 
> Signed-off-by: Taekgyun Ko <taeggyun.ko at samsung.com>
> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen at samsung.com>
> Reviewed-by: Simon Glass <sjg at google.com>
> Tested-by: Andrew Bresticker <abrestic at google.com>
> Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd at samsung.com>
> Signed-off-by: Andrew Bresticker <abrestic at google.com>
> ---
> 
> +Optional properties:
> +  - clock-frequency: Desired operating frequency in Hz of the bus.
> +    -> If not specified, the default value is 100khz in fast-speed mode and
> +       1Mhz in high-speed mode.

? If not specified, the default is 100kHz. There is no way to get 1MHz,
or?

...

> +static int exynos5_i2c_probe(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct exynos5_i2c *i2c;
> +	struct resource *mem;
> +	unsigned int op_clock;

My compiler says:

drivers/i2c/busses/i2c-exynos5.c: In function ?exynos5_i2c_probe?:
drivers/i2c/busses/i2c-exynos5.c:687:5: warning: ?op_clock? may be used uninitialized in this function [-Wuninitialized]

so...

> +	int ret;
> +
> +	if (!np) {
> +		dev_err(&pdev->dev, "no device node\n");
> +		return -ENOENT;
> +	}
> +
> +	i2c = devm_kzalloc(&pdev->dev, sizeof(struct exynos5_i2c), GFP_KERNEL);
> +	if (!i2c) {
> +		dev_err(&pdev->dev, "no memory for state\n");
> +		return -ENOMEM;
> +	}
> +
> +	if (of_property_read_u32(np, "clock-frequency", &op_clock)) {
> +		i2c->speed_mode = HSI2C_FAST_SPD;
> +		i2c->fs_clock = HSI2C_FS_TX_CLOCK;
> +	}
> +
> +	if (op_clock >= HSI2C_HS_TX_CLOCK) {

... this should be 'else if'

> +		i2c->speed_mode = HSI2C_HIGH_SPD;
> +		i2c->fs_clock = HSI2C_FS_TX_CLOCK;
> +		i2c->hs_clock = op_clock;
> +	} else {
> +		i2c->speed_mode = HSI2C_FAST_SPD;
> +		i2c->fs_clock = op_clock;
> +	}

...

> +	i2c->bus_id = of_alias_get_id(i2c->adap.dev.of_node, "hsi2c");

Huh, the core already gets an alias for you. Can't you use 'adap.nr'?

Rest looks good.

Thanks!
-------------- 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/20130701/5b228867/attachment.sig>

From dedekind1 at gmail.com  Mon Jul  1 02:25:30 2013
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Mon, 01 Jul 2013 09:25:30 +0300
Subject: [PATCH 0/2] atmel_nand: remove cpu_is_xxx() in nand driver
In-Reply-To: <1368084895-18266-1-git-send-email-josh.wu@atmel.com>
References: <1368084895-18266-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1372659930.22014.15.camel@sauron.fi.intel.com>

On Thu, 2013-05-09 at 15:34 +0800, Josh Wu wrote:
> avoid to use cpu_is_xxx() macro in driver, we use platform data and dts
> for the different cpu.
> 
> Josh Wu (2):
>   atmel_nand: at91/avr32/: Replace cpu_is_at32ap7000() with a nand
>     platform data
>   mtd: atmel_nand: add a new dt binding item for nand dma support

Pushed these 2 to l2-mtd.git, thanks!

-- 
Best Regards,
Artem Bityutskiy



From kishon at ti.com  Mon Jul  1 02:27:48 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 1 Jul 2013 11:57:48 +0530
Subject: [PATCH V3 3/3] video: exynos_dp: Use the generic PHY driver
In-Reply-To: <005401ce761b$504d7090$f0e851b0$@samsung.com>
References: <005401ce761b$504d7090$f0e851b0$@samsung.com>
Message-ID: <51D12164.6030507@ti.com>

Hi,

On Monday 01 July 2013 10:54 AM, Jingoo Han wrote:
> Use the generic PHY API instead of the platform callback to control
> the DP PHY. The 'phy_label' field is added to the platform data
> structure to allow PHY lookup on non-dt platforms.
>
> Signed-off-by: Jingoo Han <jg1.han at samsung.com>
> Acked-by: Felipe Balbi <balbi at ti.com>
> ---
>   .../devicetree/bindings/video/exynos_dp.txt        |   23 +---
>   drivers/video/exynos/exynos_dp_core.c              |  118 ++------------------
>   drivers/video/exynos/exynos_dp_core.h              |    2 +
>   include/video/exynos_dp.h                          |    6 +-
>   4 files changed, 21 insertions(+), 128 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
> index 84f10c1..71645dc 100644
> --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> @@ -1,17 +1,6 @@
>   The Exynos display port interface should be configured based on
>   the type of panel connected to it.
>
> -We use two nodes:
> -	-dp-controller node
> -	-dptx-phy node(defined inside dp-controller node)
> -
> -For the DP-PHY initialization, we use the dptx-phy node.
> -Required properties for dptx-phy:
> -	-reg:
> -		Base address of DP PHY register.
> -	-samsung,enable-mask:
> -		The bit-mask used to enable/disable DP PHY.
> -
>   For the Panel initialization, we read data from dp-controller node.
>   Required properties for dp-controller:
>   	-compatible:
> @@ -25,6 +14,10 @@ Required properties for dp-controller:
>   		from common clock binding: handle to dp clock.
>   	-clock-names:
>   		from common clock binding: Shall be "dp".
> +	-phys:
> +		from general phy binding: the phandle for the PHY device.
> +	-phy-names:
> +		from general phy binding: Should be "dp".
>   	-interrupt-parent:
>   		phandle to Interrupt combiner node.
>   	-samsung,color-space:
> @@ -67,12 +60,8 @@ SOC specific portion:
>   		interrupt-parent = <&combiner>;
>   		clocks = <&clock 342>;
>   		clock-names = "dp";
> -
> -		dptx-phy {
> -			reg = <0x10040720>;
> -			samsung,enable-mask = <1>;
> -		};
> -
> +		phys = <&dp_phy>;
> +		phy-names = "dp";
>   	};
>
>   Board Specific portion:
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index 12bbede..bac515b 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -19,6 +19,7 @@
>   #include <linux/interrupt.h>
>   #include <linux/delay.h>
>   #include <linux/of.h>
> +#include <linux/phy/phy.h>
>
>   #include <video/exynos_dp.h>
>
> @@ -960,84 +961,15 @@ static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
>   		return ERR_PTR(-EINVAL);
>   	}
>
> -	return pd;
> -}
> -
> -static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
> -{
> -	struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
> -	u32 phy_base;
> -	int ret = 0;
> -
> -	dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
> -	if (!dp_phy_node) {
> -		dev_err(dp->dev, "could not find dptx-phy node\n");
> -		return -ENODEV;
> -	}
> -
> -	if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
> -		dev_err(dp->dev, "failed to get reg for dptx-phy\n");
> -		ret = -EINVAL;
> -		goto err;
> -	}
> -
> -	if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
> -				&dp->enable_mask)) {
> -		dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
> -		ret = -EINVAL;
> -		goto err;
> -	}
> -
> -	dp->phy_addr = ioremap(phy_base, SZ_4);
> -	if (!dp->phy_addr) {
> -		dev_err(dp->dev, "failed to ioremap dp-phy\n");
> -		ret = -ENOMEM;
> -		goto err;
> -	}
> -
> -err:
> -	of_node_put(dp_phy_node);
> -
> -	return ret;
> -}
> -
> -static void exynos_dp_phy_init(struct exynos_dp_device *dp)
> -{
> -	u32 reg;
> -
> -	reg = __raw_readl(dp->phy_addr);
> -	reg |= dp->enable_mask;
> -	__raw_writel(reg, dp->phy_addr);
> -}
> -
> -static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
> -{
> -	u32 reg;
> +	pd->phy_label = "dp";

Felipe had a comment to change the label to *display-port* no?

Thanks
Kishon


From sfr at canb.auug.org.au  Mon Jul  1 02:28:12 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Mon, 1 Jul 2013 16:28:12 +1000
Subject: linux-next: manual merge of the arm-soc tree with the net-next tree
Message-ID: <20130701162812.def47813e7d94c27950f3e82@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-mxs/mach-mxs.c between commit b7c4114b07bb ("can: flexcan:
Use a regulator to control the CAN transceiver") from the net-next tree
and commit 2046338dcbc6 ("ARM: mxs: Use soc bus infrastructure") from the
arm-soc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc arch/arm/mach-mxs/mach-mxs.c
index 97b8a44,7fa611c..0000000
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@@ -323,13 -477,14 +432,14 @@@ static void __init mxs_machine_init(voi
  		imx28_evk_init();
  	else if (of_machine_is_compatible("bluegiga,apx4devkit"))
  		apx4devkit_init();
- 	else if (of_machine_is_compatible("crystalfontz,cfa10037"))
- 		cfa10037_init();
- 	else if (of_machine_is_compatible("crystalfontz,cfa10049"))
- 		cfa10049_init();
+ 	else if (of_machine_is_compatible("crystalfontz,cfa10037") ||
+ 		 of_machine_is_compatible("crystalfontz,cfa10049") ||
+ 		 of_machine_is_compatible("crystalfontz,cfa10055") ||
+ 		 of_machine_is_compatible("crystalfontz,cfa10057"))
+ 		crystalfontz_init();
  
  	of_platform_populate(NULL, of_default_bus_match_table,
- 			     NULL, NULL);
 -			     mxs_auxdata_lookup, parent);
++			     NULL, parent);
  
  	if (of_machine_is_compatible("karo,tx28"))
  		tx28_post_init();
-------------- 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/20130701/20d169de/attachment.sig>

From jg1.han at samsung.com  Mon Jul  1 03:07:24 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Mon, 01 Jul 2013 16:07:24 +0900
Subject: [PATCH V3 3/3] video: exynos_dp: Use the generic PHY driver
In-Reply-To: <51D12164.6030507@ti.com>
References: <005401ce761b$504d7090$f0e851b0$@samsung.com>
 <51D12164.6030507@ti.com>
Message-ID: <005d01ce7629$a3801520$ea803f60$@samsung.com>

On Monday, July 01, 2013 3:28 PM, Kishon Vijay Abraham I wrote:
> 
> Hi,
> 
> On Monday 01 July 2013 10:54 AM, Jingoo Han wrote:
> > Use the generic PHY API instead of the platform callback to control
> > the DP PHY. The 'phy_label' field is added to the platform data
> > structure to allow PHY lookup on non-dt platforms.
> >
> > Signed-off-by: Jingoo Han <jg1.han at samsung.com>
> > Acked-by: Felipe Balbi <balbi at ti.com>
> > ---
> >   .../devicetree/bindings/video/exynos_dp.txt        |   23 +---
> >   drivers/video/exynos/exynos_dp_core.c              |  118 ++------------------
> >   drivers/video/exynos/exynos_dp_core.h              |    2 +
> >   include/video/exynos_dp.h                          |    6 +-
> >   4 files changed, 21 insertions(+), 128 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
> b/Documentation/devicetree/bindings/video/exynos_dp.txt
> > index 84f10c1..71645dc 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> > @@ -1,17 +1,6 @@
> >   The Exynos display port interface should be configured based on
> >   the type of panel connected to it.
> >
> > -We use two nodes:
> > -	-dp-controller node
> > -	-dptx-phy node(defined inside dp-controller node)
> > -
> > -For the DP-PHY initialization, we use the dptx-phy node.
> > -Required properties for dptx-phy:
> > -	-reg:
> > -		Base address of DP PHY register.
> > -	-samsung,enable-mask:
> > -		The bit-mask used to enable/disable DP PHY.
> > -
> >   For the Panel initialization, we read data from dp-controller node.
> >   Required properties for dp-controller:
> >   	-compatible:
> > @@ -25,6 +14,10 @@ Required properties for dp-controller:
> >   		from common clock binding: handle to dp clock.
> >   	-clock-names:
> >   		from common clock binding: Shall be "dp".
> > +	-phys:
> > +		from general phy binding: the phandle for the PHY device.
> > +	-phy-names:
> > +		from general phy binding: Should be "dp".
> >   	-interrupt-parent:
> >   		phandle to Interrupt combiner node.
> >   	-samsung,color-space:
> > @@ -67,12 +60,8 @@ SOC specific portion:
> >   		interrupt-parent = <&combiner>;
> >   		clocks = <&clock 342>;
> >   		clock-names = "dp";
> > -
> > -		dptx-phy {
> > -			reg = <0x10040720>;
> > -			samsung,enable-mask = <1>;
> > -		};
> > -
> > +		phys = <&dp_phy>;
> > +		phy-names = "dp";
> >   	};
> >
> >   Board Specific portion:
> > diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> > index 12bbede..bac515b 100644
> > --- a/drivers/video/exynos/exynos_dp_core.c
> > +++ b/drivers/video/exynos/exynos_dp_core.c
> > @@ -19,6 +19,7 @@
> >   #include <linux/interrupt.h>
> >   #include <linux/delay.h>
> >   #include <linux/of.h>
> > +#include <linux/phy/phy.h>
> >
> >   #include <video/exynos_dp.h>
> >
> > @@ -960,84 +961,15 @@ static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
> >   		return ERR_PTR(-EINVAL);
> >   	}
> >
> > -	return pd;
> > -}
> > -
> > -static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
> > -{
> > -	struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
> > -	u32 phy_base;
> > -	int ret = 0;
> > -
> > -	dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
> > -	if (!dp_phy_node) {
> > -		dev_err(dp->dev, "could not find dptx-phy node\n");
> > -		return -ENODEV;
> > -	}
> > -
> > -	if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
> > -		dev_err(dp->dev, "failed to get reg for dptx-phy\n");
> > -		ret = -EINVAL;
> > -		goto err;
> > -	}
> > -
> > -	if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
> > -				&dp->enable_mask)) {
> > -		dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
> > -		ret = -EINVAL;
> > -		goto err;
> > -	}
> > -
> > -	dp->phy_addr = ioremap(phy_base, SZ_4);
> > -	if (!dp->phy_addr) {
> > -		dev_err(dp->dev, "failed to ioremap dp-phy\n");
> > -		ret = -ENOMEM;
> > -		goto err;
> > -	}
> > -
> > -err:
> > -	of_node_put(dp_phy_node);
> > -
> > -	return ret;
> > -}
> > -
> > -static void exynos_dp_phy_init(struct exynos_dp_device *dp)
> > -{
> > -	u32 reg;
> > -
> > -	reg = __raw_readl(dp->phy_addr);
> > -	reg |= dp->enable_mask;
> > -	__raw_writel(reg, dp->phy_addr);
> > -}
> > -
> > -static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
> > -{
> > -	u32 reg;
> > +	pd->phy_label = "dp";
> 
> Felipe had a comment to change the label to *display-port* no?

No, I don't think so. :)
I would like to use 'dp'.

Best regards,
Jingoo Han

> 
> Thanks
> Kishon



From p.zabel at pengutronix.de  Mon Jul  1 03:07:20 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon, 01 Jul 2013 09:07:20 +0200
Subject: [PATCH 1/2] ARM: dts: mx53qsb: Enable VPU support
In-Reply-To: <CAHCPf3s6_+aNs=LycgJzcOajmFuWy-mp66-BX+OMCLYDApS9cg@mail.gmail.com>
References: <1372459759-10488-1-git-send-email-festevam@gmail.com>
 <CAHCPf3s6_+aNs=LycgJzcOajmFuWy-mp66-BX+OMCLYDApS9cg@mail.gmail.com>
Message-ID: <1372662440.4971.15.camel@pizza.hi.pengutronix.de>

Hi Matt,

[Cc: devicetree-discuss at lists.ozlabs.org]

Am Freitag, den 28.06.2013, 23:49 -0500 schrieb Matt Sealey:
> On Fri, Jun 28, 2013 at 5:49 PM, Fabio Estevam <festevam at gmail.com> wrote:
> > From: Fabio Estevam <fabio.estevam at freescale.com>
> >
> > Enable Video Processing Unit (VPU) support.
> >
> > Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> > ---
> > Depends on Philipp Zabel's patch:
> > [PATCH] ARM: dts: add sram for imx53 and imx6q
> >
> > Philipp,
> >
> > I tried using the original mx53 vpu firmware that comes with the FSL BSP, but it
> > failed to load:
> >
> > coda 63ff4000.vpu: firmware get command error
> > coda 63ff4000.vpu: HW initialization failed
> >
> > Any suggestions?
> >
> > Thanks!
> >
> >  arch/arm/boot/dts/imx53-qsb.dts |  4 ++++
> >  arch/arm/boot/dts/imx53.dtsi    | 10 ++++++++++
> >  2 files changed, 14 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
> > index 512a1f6..eedd27e 100644
> > --- a/arch/arm/boot/dts/imx53-qsb.dts
> > +++ b/arch/arm/boot/dts/imx53-qsb.dts
> > @@ -297,6 +297,10 @@
> >         status = "okay";
> >  };
> >
> > +&vpu {
> > +       status = "okay";
> > +};
> > +
> >  &usbh1 {
> >         status = "okay";
> >  };
> > diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> > index 3def46f..f94d4e5 100644
> > --- a/arch/arm/boot/dts/imx53.dtsi
> > +++ b/arch/arm/boot/dts/imx53.dtsi
> > @@ -1086,6 +1086,16 @@
> >                                 crtcs = <&ipu 1>;
> >                                 status = "disabled";
> >                         };
> > +
> > +                       vpu: vpu at 63ff4000 {
> > +                               compatible = "fsl,imx53-vpu";
> > +                               reg = <0x63ff4000 0x1000>;
> > +                               interrupts = <9>;
> > +                               clocks = <&clks 63>, <&clks 63>;
> > +                               clock-names = "per", "ahb";
> > +                               iram = <&ocram>;
> > +                               status = "disabled";
> > +                       };
> >                 };
> >
> >                 ocram: ocram at f8000000 {
> 
> Nitpick: what I see here around enabling the VPU driver is;
> 
> * A property called iram
> * ... that references a node called ocram
> * ... which is coincidentally driven by a driver called sram
> 
> Could we make up our minds as to what to call it? Something generic
> that's potentially not i.MX-specific (since it does change over the
> models, and it may not be technically SRAM..) that gets used
> everywhere and belies it's purpose rather than naming a particular
> technology, or particular IP core documentation if it changes a lot?

I'd be in favor of changing
-                 ocram: ocram at f8000000 {
+                 ocram: sram at f8000000 {
but it is very convenient to have the IP vendor's creative name in
there, too, if I have to look it up in the reference manual.

>From point of view of the VPU, the SRAM is a more local memory, in most
implementations connected via a dedicated AXI bus to avoid load on the
main memory bus.

regards
Philipp



From horms at verge.net.au  Mon Jul  1 03:18:48 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 1 Jul 2013 16:18:48 +0900
Subject: [PATCH v3 2/3] ARM: shmobile: lager: enable Ether
In-Reply-To: <1372652755-16948-3-git-send-email-horms+renesas@verge.net.au>
References: <1372652755-16948-1-git-send-email-horms+renesas@verge.net.au>
 <1372652755-16948-3-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130701071848.GT14567@verge.net.au>

On Mon, Jul 01, 2013 at 01:25:54PM +0900, Simon Horman wrote:
> Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Cc: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> ---
> 
> This patch has a build-time dependency on "sh_eth: add support for gpio reset".
> This patch has a run-time dependency on "sh_eth: add support for r8a7790 SoC".
> 
> v3
> * Rebase
> 
> v2
> * As suggested by Laurent Pinchart
>   - Do not manipilate sh_eth reset GPIO directly,
>     rather, do so through newly proposed support for this in
>     the sh_eth driver.
> * A suggested by Sergei Shtylyov
>   - Move DTS portion into a separate patch
> ---
>  arch/arm/mach-shmobile/board-lager.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
> index 0b4a1f9..4fecaf6 100644
> --- a/arch/arm/mach-shmobile/board-lager.c
> +++ b/arch/arm/mach-shmobile/board-lager.c
> @@ -71,6 +71,17 @@ static __initdata struct gpio_keys_platform_data lager_keys_pdata = {
>  	.nbuttons	= ARRAY_SIZE(gpio_buttons),
>  };
>  
> +/* Ether */
> +static struct sh_eth_plat_data ether_platdata = {

This should be annotated as __initdata, I will re-post.

> +	.phy			= 0x1,
> +	.edmac_endian		= EDMAC_LITTLE_ENDIAN,
> +	.register_type		= SH_ETH_REG_FAST_RCAR,
> +	.phy_interface		= PHY_INTERFACE_MODE_RMII,
> +	.ether_link_active_low	= 1,
> +	.needs_gpio_reset	= 1,
> +	.reset_gpio		= RCAR_GP_PIN(5, 31),
> +};
> +
>  static const struct pinctrl_map lager_pinctrl_map[] = {
>  	/* SCIF0 (CN19: DEBUG SERIAL0) */
>  	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7790",
> @@ -78,6 +89,17 @@ static const struct pinctrl_map lager_pinctrl_map[] = {
>  	/* SCIF1 (CN20: DEBUG SERIAL1) */
>  	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.7", "pfc-r8a7790",
>  				  "scif1_data", "scif1"),
> +	/* Ether */
> +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> +				  "eth_link", "eth"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> +				  "eth_magic", "eth"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> +				  "eth_mdio", "eth"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> +				  "eth_rmii", "eth"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> +				  "intc_irq0", "intc"),
>  };
>  
>  static void __init lager_add_standard_devices(void)
> @@ -89,6 +111,8 @@ static void __init lager_add_standard_devices(void)
>  	r8a7790_pinmux_init();
>  
>  	r8a7790_add_standard_devices();
> +	r8a7790_add_ether_device(&ether_platdata);
> +
>  	platform_device_register_data(&platform_bus, "leds-gpio", -1,
>  				      &lager_leds_pdata,
>  				      sizeof(lager_leds_pdata));
> -- 
> 1.8.2.1
> 


From horms+renesas at verge.net.au  Mon Jul  1 03:20:31 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon,  1 Jul 2013 16:20:31 +0900
Subject: [PATCH v4 0/3]  ARM: shmobile: lager: enable Ether
Message-ID: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>

Hi,

this short series enables the on-board ethernet
of the r8a7790 SoC for on lager board.

It has a run-time dependency on
"sh_eth: add support for r8a7790 SoC"

It has been built on top of renesas-next-20130701.

Simon Horman (3):
  ARM: shmobile: r8a7790: add Ether support
  ARM: shmobile: lager: enable Ether
  ARM: shmobile: lager: enable nfsroot in DTS

 arch/arm/boot/dts/r8a7790-lager.dts           |  2 +-
 arch/arm/mach-shmobile/board-lager.c          | 24 ++++++++++++++++++++++++
 arch/arm/mach-shmobile/clock-r8a7790.c        |  4 ++++
 arch/arm/mach-shmobile/include/mach/r8a7790.h |  3 +++
 arch/arm/mach-shmobile/setup-r8a7790.c        | 14 ++++++++++++++
 5 files changed, 46 insertions(+), 1 deletion(-)

-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul  1 03:20:34 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon,  1 Jul 2013 16:20:34 +0900
Subject: [PATCH v4 3/3] ARM: shmobile: lager: enable nfsroot in DTS
In-Reply-To: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
References: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1372663234-13486-4-git-send-email-horms+renesas@verge.net.au>

Now that Ether support has been added to the lager board
it is possible to use nfsroot. This configuration is
in line with that of other shmobile boards.

Cc: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

This patch has a run-time dependency on "ARM: shmobile: lager: enable Ether"

v2
* Split out as a new patch from "ARM: shmobile: lager: enable Ether"
---
 arch/arm/boot/dts/r8a7790-lager.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 09a84fc..b2f61f0 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -16,7 +16,7 @@
 	compatible = "renesas,lager", "renesas,r8a7790";
 
 	chosen {
-		bootargs = "console=ttySC6,115200 ignore_loglevel";
+		bootargs = "console=ttySC6,115200 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096 rw";
 	};
 
 	memory at 40000000 {
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul  1 03:20:33 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon,  1 Jul 2013 16:20:33 +0900
Subject: [PATCH v4 2/3] ARM: shmobile: lager: enable Ether
In-Reply-To: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
References: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1372663234-13486-3-git-send-email-horms+renesas@verge.net.au>

Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Cc: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

This patch has a build-time dependency on "sh_eth: add support for gpio reset".
This patch has a run-time dependency on "sh_eth: add support for r8a7790 SoC".

v4
* Annotate ether_platdata as __initdata

v3
* Rebase

v2
* As suggested by Laurent Pinchart
  - Do not manipilate sh_eth reset GPIO directly,
    rather, do so through newly proposed support for this in
    the sh_eth driver.
* A suggested by Sergei Shtylyov
  - Move DTS portion into a separate patch
---
 arch/arm/mach-shmobile/board-lager.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index 0b4a1f9..7d5db20 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -71,6 +71,17 @@ static __initdata struct gpio_keys_platform_data lager_keys_pdata = {
 	.nbuttons	= ARRAY_SIZE(gpio_buttons),
 };
 
+/* Ether */
+static struct sh_eth_plat_data ether_platdata __initdata = {
+	.phy			= 0x1,
+	.edmac_endian		= EDMAC_LITTLE_ENDIAN,
+	.register_type		= SH_ETH_REG_FAST_RCAR,
+	.phy_interface		= PHY_INTERFACE_MODE_RMII,
+	.ether_link_active_low	= 1,
+	.needs_gpio_reset	= 1,
+	.reset_gpio		= RCAR_GP_PIN(5, 31),
+};
+
 static const struct pinctrl_map lager_pinctrl_map[] = {
 	/* SCIF0 (CN19: DEBUG SERIAL0) */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7790",
@@ -78,6 +89,17 @@ static const struct pinctrl_map lager_pinctrl_map[] = {
 	/* SCIF1 (CN20: DEBUG SERIAL1) */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.7", "pfc-r8a7790",
 				  "scif1_data", "scif1"),
+	/* Ether */
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
+				  "eth_link", "eth"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
+				  "eth_magic", "eth"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
+				  "eth_mdio", "eth"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
+				  "eth_rmii", "eth"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
+				  "intc_irq0", "intc"),
 };
 
 static void __init lager_add_standard_devices(void)
@@ -89,6 +111,8 @@ static void __init lager_add_standard_devices(void)
 	r8a7790_pinmux_init();
 
 	r8a7790_add_standard_devices();
+	r8a7790_add_ether_device(&ether_platdata);
+
 	platform_device_register_data(&platform_bus, "leds-gpio", -1,
 				      &lager_leds_pdata,
 				      sizeof(lager_leds_pdata));
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul  1 03:20:32 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon,  1 Jul 2013 16:20:32 +0900
Subject: [PATCH v4 1/3] ARM: shmobile: r8a7790: add Ether support
In-Reply-To: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
References: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1372663234-13486-2-git-send-email-horms+renesas@verge.net.au>

Add Ether clock and platform device for R8A7779 SoC; add a function to
register this device with board-specific platform data.

Based on a similar change for the r8a7779 by Sergei Shtylyov.

Cc: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

This patch has a run-time dependency on "sh_eth: add support for r8a7790 SoC".

v3
* Use newly added "r8a7790-ether" instead of "sh-eth"

v2
* Do not add MSTP812, EtherAVB. It is not used.
* As suggested by Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
  - Move Ethernet element of MSTP enum to a separate line
  - Move declaration of r8a7790_add_ether_device() to immediately
    after that of r8a7790_add_standard_devices()
  - Add __initdata annotation to ether_resource.
---
 arch/arm/mach-shmobile/clock-r8a7790.c        |  4 ++++
 arch/arm/mach-shmobile/include/mach/r8a7790.h |  3 +++
 arch/arm/mach-shmobile/setup-r8a7790.c        | 14 ++++++++++++++
 3 files changed, 21 insertions(+)

diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c b/arch/arm/mach-shmobile/clock-r8a7790.c
index 62d8162..2f52c0f 100644
--- a/arch/arm/mach-shmobile/clock-r8a7790.c
+++ b/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -52,6 +52,7 @@
 #define SMSTPCR3 0xe615013c
 #define SMSTPCR5 0xe6150144
 #define SMSTPCR7 0xe615014c
+#define SMSTPCR8 0xe6150990
 
 #define MODEMR		0xE6160060
 #define SDCKCR		0xE6150074
@@ -182,6 +183,7 @@ static struct clk div6_clks[DIV6_NR] = {
 
 /* MSTP */
 enum {
+	MSTP813,
 	MSTP721, MSTP720,
 	MSTP717, MSTP716,
 	MSTP522,
@@ -192,6 +194,7 @@ enum {
 };
 
 static struct clk mstp_clks[MSTP_NR] = {
+	[MSTP813] = SH_CLK_MSTP32(&p_clk, SMSTPCR8, 13, 0), /* Ether */
 	[MSTP721] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 21, 0), /* SCIF0 */
 	[MSTP720] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 20, 0), /* SCIF1 */
 	[MSTP717] = SH_CLK_MSTP32(&zs_clk, SMSTPCR7, 17, 0), /* HSCIF0 */
@@ -260,6 +263,7 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh-sci.7", &mstp_clks[MSTP720]),
 	CLKDEV_DEV_ID("sh-sci.8", &mstp_clks[MSTP717]),
 	CLKDEV_DEV_ID("sh-sci.9", &mstp_clks[MSTP716]),
+	CLKDEV_DEV_ID("r8a7790-ether", &mstp_clks[MSTP813]),
 	CLKDEV_DEV_ID("rcar_thermal", &mstp_clks[MSTP522]),
 	CLKDEV_DEV_ID("ee200000.mmcif", &mstp_clks[MSTP315]),
 	CLKDEV_DEV_ID("sh_mmcif.0", &mstp_clks[MSTP315]),
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h b/arch/arm/mach-shmobile/include/mach/r8a7790.h
index 7851cc1..b827b49 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7790.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7790.h
@@ -1,7 +1,10 @@
 #ifndef __ASM_R8A7790_H__
 #define __ASM_R8A7790_H__
 
+#include <linux/sh_eth.h>
+
 void r8a7790_add_standard_devices(void);
+void r8a7790_add_ether_device(struct sh_eth_plat_data *pdata);
 void r8a7790_clock_init(void);
 void r8a7790_pinmux_init(void);
 void r8a7790_init_delay(void);
diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index d89cd83..fad4251 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -31,6 +31,20 @@
 #include <mach/r8a7790.h>
 #include <asm/mach/arch.h>
 
+/* Ether */
+static struct resource ether_resources[] __initdata = {
+	DEFINE_RES_MEM(0xee700000, 0x400),
+	DEFINE_RES_IRQ(gic_spi(162)), /* IRQ0 */
+};
+
+void __init r8a7790_add_ether_device(struct sh_eth_plat_data *pdata)
+{
+	platform_device_register_resndata(&platform_bus, "r8a7790-ether", -1,
+					  ether_resources,
+					  ARRAY_SIZE(ether_resources),
+					  pdata, sizeof(*pdata));
+}
+
 static struct resource pfc_resources[] __initdata = {
 	DEFINE_RES_MEM(0xe6060000, 0x250),
 };
-- 
1.8.2.1



From horms at verge.net.au  Mon Jul  1 03:32:38 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 1 Jul 2013 16:32:38 +0900
Subject: [PATCH 01/04] ARM: shmobile: Use default ->init_irq() on EMEV2
In-Reply-To: <20130701060112.21728.37189.sendpatchset@w520>
References: <20130701060103.21728.83833.sendpatchset@w520>
 <20130701060112.21728.37189.sendpatchset@w520>
Message-ID: <20130701073237.GU14567@verge.net.au>

On Mon, Jul 01, 2013 at 03:01:12PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Remove redundant irqchip_init() callback. The default case
> of NULL will result in invoking irqchip_init() anyway.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  arch/arm/mach-shmobile/setup-emev2.c |    2 --
>  1 file changed, 2 deletions(-)
> 
> --- 0005/arch/arm/mach-shmobile/setup-emev2.c
> +++ work/arch/arm/mach-shmobile/setup-emev2.c	2013-07-01 13:33:39.000000000 +0900
> @@ -20,7 +20,6 @@
>  #include <linux/init.h>
>  #include <linux/interrupt.h>
>  #include <linux/irq.h>
> -#include <linux/irqchip.h>
>  #include <linux/platform_device.h>
>  #include <linux/platform_data/gpio-em.h>
>  #include <linux/of_platform.h>
> @@ -445,7 +444,6 @@ DT_MACHINE_START(EMEV2_DT, "Generic Emma
>  	.smp		= smp_ops(emev2_smp_ops),
>  	.init_early	= emev2_init_delay,
>  	.nr_irqs	= NR_IRQS_LEGACY,
> -	.init_irq	= irqchip_init,
>  	.dt_compat	= emev2_boards_compat_dt,
>  MACHINE_END

Hi Magnus,

I mistakenly dropped the following patch from Maxime Ripard from
v3.11. I have re-queued it up, for v3.12, in the cleanup branch:

commit 4042de1229ecf083890d8ad5c9327e03b648c1a2
Author: Maxime Ripard <maxime.ripard at free-electrons.com>
Date:   Sun May 26 22:05:23 2013 +0900

    ARM: shmobile: emev2: Remove init_irq declaration in machine description
    
    Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
    specified") removed the need to explictly setup the init_irq field in
    the machine description when using only irqchip_init. Remove that
    declaration for shmobile as well.
    
    Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
    Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
index 899a86c..66694e0 100644
--- a/arch/arm/mach-shmobile/setup-emev2.c
+++ b/arch/arm/mach-shmobile/setup-emev2.c
@@ -20,7 +20,6 @@
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
-#include <linux/irqchip.h>
 #include <linux/platform_device.h>
 #include <linux/platform_data/gpio-em.h>
 #include <linux/of_platform.h>
@@ -454,7 +453,6 @@ DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
 	.smp		= smp_ops(emev2_smp_ops),
 	.init_early	= emev2_init_delay,
 	.nr_irqs	= NR_IRQS_LEGACY,
-	.init_irq	= irqchip_init,
 	.init_machine	= emev2_add_standard_devices_dt,
 	.dt_compat	= emev2_boards_compat_dt,
 MACHINE_END


From xobs at kosagi.com  Mon Jul  1 03:15:43 2013
From: xobs at kosagi.com (Sean Cross)
Date: Mon,  1 Jul 2013 07:15:43 +0000
Subject: [PATCH 0/4] Add PCI Express to i.MX6
Message-ID: <1372662947-27160-1-git-send-email-xobs@kosagi.com>

This patchset adds a PCI Express driver for the Freescale i.MX6 series of 
SoCs.  It is based on the BSP driver, available from Freescale
athttp://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git

This patchset does the following:

    1) Add general-purpose LVDS clocks to drive the bus
    2) Enable PCI Express on ARM
    3) Add the pcie-imx driver
    4) Add device tree bindings for imx6qdl.dtsi

Sean Cross (4):
  ARM i.MX6q: Add descriptors for LVDS clocks
  ARM: Enable PCI Express on ARM
  PCI: Add driver for i.MX6 PCI Express
  ARM i.MX6: Add PCI Express to device tree

 .../devicetree/bindings/clock/imx6q-clock.txt      |    4 +
 .../devicetree/bindings/pci/imx6q-pcie.txt         |   20 +
 arch/arm/Kconfig                                   |    2 +
 arch/arm/boot/dts/imx6qdl.dtsi                     |   12 +
 arch/arm/mach-imx/Kconfig                          |    1 +
 arch/arm/mach-imx/clk-imx6q.c                      |   13 +-
 drivers/pci/pcie/Kconfig                           |   10 +
 drivers/pci/pcie/Makefile                          |    2 +
 drivers/pci/pcie/pcie-imx.c                        | 1049 ++++++++++++++++++++
 9 files changed, 1111 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/imx6q-pcie.txt
 create mode 100644 drivers/pci/pcie/pcie-imx.c

-- 
1.7.9.5



From xobs at kosagi.com  Mon Jul  1 03:15:44 2013
From: xobs at kosagi.com (Sean Cross)
Date: Mon,  1 Jul 2013 07:15:44 +0000
Subject: [PATCH 1/4] ARM i.MX6q: Add descriptors for LVDS clocks
In-Reply-To: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
References: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
Message-ID: <1372662947-27160-2-git-send-email-xobs@kosagi.com>

There are two general-purpose LVDS clocks available on the i.MX6.  Add
clock descriptors for both of these clocks, as well as selectors to be
able to generate various external signals.

Signed-off-by: Sean Cross <xobs at kosagi.com>
---
 .../devicetree/bindings/clock/imx6q-clock.txt      |    4 ++++
 arch/arm/mach-imx/clk-imx6q.c                      |   13 +++++++++++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 6deb6fd..b2b4acb 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -208,6 +208,10 @@ clocks and IDs.
 	pll4_post_div		193
 	pll5_post_div		194
 	pll5_video_div		195
+	lvds1_sel		196
+	lvds2_sel		197
+	lvds1			198
+	lvds2			199
 
 Examples:
 
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 4e3148c..f0c0591 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -204,7 +204,9 @@ static const char *vdo_axi_sels[]	= { "axi", "ahb", };
 static const char *vpu_axi_sels[]	= { "axi", "pll2_pfd2_396m", "pll2_pfd0_352m", };
 static const char *cko1_sels[]	= { "pll3_usb_otg", "pll2_bus", "pll1_sys", "pll5_video_div",
 				    "dummy", "axi", "enfc", "ipu1_di0", "ipu1_di1", "ipu2_di0",
-				    "ipu2_di1", "ahb", "ipg", "ipg_per", "ckil", "pll4_post_div", };
+				    "ipu2_di1", "ahb", "ipg", "ipg_per", "ckil", "pll4_audio", };
+static const char *lvds1_sels[] = { "dummy", "dummy", "dummy", "dummy", "dummy", "dummy", "pll4_audio", "pll5_video", "pll8_mlb", "enet_ref", "pcie_ref", "sata_ref", "dummy", "dummy", "dummy", "dummy", "dummy", "dummy", "dummy", "lvds1", "lvds2", };
+static const char *lvds2_sels[] = { "dummy", "dummy", "dummy", "dummy", "dummy", "dummy", "pll4_audio", "pll5_video", "pll8_mlb", "enet_ref", "pcie_ref", "sata_ref", "dummy", "dummy", "dummy", "dummy", "dummy", "dummy", "dummy", "lvds1", "lvds2", };
 
 enum mx6q_clks {
 	dummy, ckil, ckih, osc, pll2_pfd0_352m, pll2_pfd1_594m, pll2_pfd2_396m,
@@ -238,7 +240,8 @@ enum mx6q_clks {
 	pll4_audio, pll5_video, pll8_mlb, pll7_usb_host, pll6_enet, ssi1_ipg,
 	ssi2_ipg, ssi3_ipg, rom, usbphy1, usbphy2, ldb_di0_div_3_5, ldb_di1_div_3_5,
 	sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref, usbphy1_gate,
-	usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, clk_max
+	usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div,
+	lvds1_sel, lvds2_sel, lvds1, lvds2, clk_max
 };
 
 static struct clk *clk[clk_max];
@@ -360,6 +363,12 @@ int __init mx6q_clocks_init(void)
 	clk[pll5_post_div] = clk_register_divider_table(NULL, "pll5_post_div", "pll5_video", CLK_SET_RATE_PARENT, base + 0xa0, 19, 2, 0, post_div_table, &imx_ccm_lock);
 	clk[pll5_video_div] = clk_register_divider_table(NULL, "pll5_video_div", "pll5_post_div", CLK_SET_RATE_PARENT, base + 0x170, 30, 2, 0, video_div_table, &imx_ccm_lock);
 
+	clk[lvds1_sel]        = imx_clk_mux("lvds1_sel",	base + 0x160, 0, 5, lvds1_sels,		ARRAY_SIZE(lvds1_sels));
+	clk[lvds2_sel]        = imx_clk_mux("lvds2_sel",	base + 0x160, 0, 5, lvds2_sels,		ARRAY_SIZE(lvds2_sels));
+
+	clk[lvds1] = imx_clk_gate("lvds1", "dummy", base + 0x160, 10);
+	clk[lvds2] = imx_clk_gate("lvds2", "dummy", base + 0x160, 11);
+
 	np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-ccm");
 	base = of_iomap(np, 0);
 	WARN_ON(!base);
-- 
1.7.9.5



From xobs at kosagi.com  Mon Jul  1 03:15:45 2013
From: xobs at kosagi.com (Sean Cross)
Date: Mon,  1 Jul 2013 07:15:45 +0000
Subject: [PATCH 2/4] ARM: Enable PCI Express on ARM
In-Reply-To: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
References: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
Message-ID: <1372662947-27160-3-git-send-email-xobs@kosagi.com>

Some ARM devices have PCI Express hardware, and should be able to take
advantage of PCI Express code present in the common driver files.  Enable
PCI Express on ARM, when PCI is available.

Signed-off-by: Sean Cross <xobs at kosagi.com>
---
 arch/arm/Kconfig |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 136f263..2f51f13 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1418,6 +1418,8 @@ config PCI_HOST_ITE8152
 
 source "drivers/pci/Kconfig"
 
+source "drivers/pci/pcie/Kconfig"
+
 source "drivers/pcmcia/Kconfig"
 
 endmenu
-- 
1.7.9.5



From xobs at kosagi.com  Mon Jul  1 03:15:47 2013
From: xobs at kosagi.com (Sean Cross)
Date: Mon,  1 Jul 2013 07:15:47 +0000
Subject: [PATCH 4/4] ARM i.MX6: Add PCI Express to device tree
In-Reply-To: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
References: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
Message-ID: <1372662947-27160-5-git-send-email-xobs@kosagi.com>

Add a PCI Express port to the i.MX6 device tree using interrupts, clocks,
and memory ranges appropriate for the device.

Signed-off-by: Sean Cross <xobs at kosagi.com>
---
 arch/arm/boot/dts/imx6qdl.dtsi |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 9e8296e..4b5facb 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -654,6 +654,18 @@
 				status = "disabled";
 			};
 
+			pcie: pcie at 01ffc000 {
+				compatible = "fsl,imx6q-pcie";
+				reg = <0x01ffc000 0x4000>,
+				      <0x01000000 0x100000>,
+				      <0x01100000 0xe00000>,
+				      <0x01f00000 0xfc000>;
+				interrupts = <0 122 0x04>;
+				clocks = <&clks 186>, <&clks 189>, <&clks 196>, <&clks 198>, <&clks 144>;
+				clock-names = "sata_ref", "pcie_ref_125m", "lvds1_sel", "lvds1", "pcie_axi";
+				status = "disabled";
+			};
+
 			mlb at 0218c000 {
 				reg = <0x0218c000 0x4000>;
 				interrupts = <0 53 0x04 0 117 0x04 0 126 0x04>;
-- 
1.7.9.5



From xobs at kosagi.com  Mon Jul  1 03:15:46 2013
From: xobs at kosagi.com (Sean Cross)
Date: Mon,  1 Jul 2013 07:15:46 +0000
Subject: [PATCH 3/4] PCI: Add driver for i.MX6 PCI Express
In-Reply-To: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
References: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
Message-ID: <1372662947-27160-4-git-send-email-xobs@kosagi.com>

This adds a PCI Express port driver for the on-chip PCI Express port
present on the i.MX6 SoC.  It is based on the PCI Express driver available
in the Freescale BSP.

Signed-off-by: Sean Cross <xobs at kosagi.com>
---
 .../devicetree/bindings/pci/imx6q-pcie.txt         |   20 +
 arch/arm/mach-imx/Kconfig                          |    1 +
 drivers/pci/pcie/Kconfig                           |   10 +
 drivers/pci/pcie/Makefile                          |    2 +
 drivers/pci/pcie/pcie-imx.c                        | 1049 ++++++++++++++++++++
 5 files changed, 1082 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/imx6q-pcie.txt
 create mode 100644 drivers/pci/pcie/pcie-imx.c

diff --git a/Documentation/devicetree/bindings/pci/imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/imx6q-pcie.txt
new file mode 100644
index 0000000..2dc9eae
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/imx6q-pcie.txt
@@ -0,0 +1,20 @@
+* Freescale i.MX6Q PCI Express bridge
+
+Example (i.MX6Q)
+	pcie: pcie at 01ffc000 {
+		compatible = "fsl,imx6q-pcie";
+		reg = <0x01ffc000 0x4000>,
+		      <0x01000000 0x100000>,
+		      <0x01100000 0xe00000>,
+		      <0x01f00000 0xfc000>;
+		interrupts = <0 122 0x04>;
+		clocks = <&clks 186>, <&clks 189>, <&clks 196>,
+			 <&clks 198>, <&clks 144>;
+		clock-names = "sata_ref", "pcie_ref_125m", "lvds1_sel",
+			      "lvds1", "pcie_axi";
+		power-enable = <&gpio7 12 0>;
+		pcie-reset = <&gpio3 29 0>;
+		wake-up = <&gpio3 22 0>;
+		disable-endpoint = <&gpio2 16 0>;
+	};
+
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index ba44328..cad4e5a 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -811,6 +811,7 @@ config SOC_IMX6Q
 	select PL310_ERRATA_588369 if CACHE_PL310
 	select PL310_ERRATA_727915 if CACHE_PL310
 	select PL310_ERRATA_769419 if CACHE_PL310
+	select MIGHT_HAVE_PCI
 	select PM_OPP if PM
 
 	help
diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
index 569f82f..d1d70db 100644
--- a/drivers/pci/pcie/Kconfig
+++ b/drivers/pci/pcie/Kconfig
@@ -83,3 +83,13 @@ endchoice
 config PCIE_PME
 	def_bool y
 	depends on PCIEPORTBUS && PM_RUNTIME
+
+#
+# Platform driver for i.MX6
+#
+config PCIE_IMX
+        bool "Support for i.MX6"
+        depends on SOC_IMX6Q
+        help
+          Enable support for the 1x PCI Express bus on the Freescale i.MX6
+        depends on PCIEPORTBUS && PM_RUNTIME
diff --git a/drivers/pci/pcie/Makefile b/drivers/pci/pcie/Makefile
index 00c62df..5393d21 100644
--- a/drivers/pci/pcie/Makefile
+++ b/drivers/pci/pcie/Makefile
@@ -14,3 +14,5 @@ obj-$(CONFIG_PCIEPORTBUS)	+= pcieportdrv.o
 obj-$(CONFIG_PCIEAER)		+= aer/
 
 obj-$(CONFIG_PCIE_PME) += pme.o
+
+obj-$(CONFIG_PCIE_IMX)		+= pcie-imx.o
diff --git a/drivers/pci/pcie/pcie-imx.c b/drivers/pci/pcie/pcie-imx.c
new file mode 100644
index 0000000..664679e
--- /dev/null
+++ b/drivers/pci/pcie/pcie-imx.c
@@ -0,0 +1,1049 @@
+/*
+ * drivers/pci/pcie/pcie-imx.c
+ *
+ * PCIe host controller driver for IMX6 SOCs
+ *
+ * Copyright (C) 2012 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Code originally taken from Freescale linux-2.6.35 BSP.
+ *
+ * Other bits taken from arch/arm/mach-dove/pcie.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This 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.
+
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/pci.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/irq.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of_device.h>
+#include <linux/clk-provider.h>
+#include <linux/regmap.h>
+#include <linux/rfkill.h>
+
+#include <asm/sizes.h>
+#include <asm/io.h>
+
+
+/* IOMUXC */
+#define IOMUXC_GPR0                     (0x00)
+#define IOMUXC_GPR1                     (0x04)
+#define IOMUXC_GPR2                     (0x08)
+#define IOMUXC_GPR3                     (0x0C)
+#define IOMUXC_GPR4                     (0x10)
+#define IOMUXC_GPR5                     (0x14)
+#define IOMUXC_GPR6                     (0x18)
+#define IOMUXC_GPR7                     (0x1C)
+#define IOMUXC_GPR8                     (0x20)
+#define IOMUXC_GPR9                     (0x24)
+#define IOMUXC_GPR10                    (0x28)
+#define IOMUXC_GPR11                    (0x2C)
+#define IOMUXC_GPR12                    (0x30)
+#define IOMUXC_GPR13                    (0x34)
+
+
+/* Register Definitions */
+#define PRT_LOG_R_BaseAddress 0x700
+
+/* Register DEBUG_R0 */
+/* Debug Register 0 */
+#define DEBUG_R0 (PRT_LOG_R_BaseAddress + 0x28)
+#define DEBUG_R0_RegisterSize 32
+#define DEBUG_R0_RegisterResetValue 0x0
+#define DEBUG_R0_RegisterResetMask 0xFFFFFFFF
+/* End of Register Definition for DEBUG_R0 */
+
+/* Register DEBUG_R1 */
+/* Debug Register 1 */
+#define DEBUG_R1 (PRT_LOG_R_BaseAddress + 0x2c)
+#define DEBUG_R1_RegisterSize 32
+#define DEBUG_R1_RegisterResetValue 0x0
+#define DEBUG_R1_RegisterResetMask 0xFFFFFFFF
+/* End of Register Definition for DEBUG_R1 */
+
+#define ATU_R_BaseAddress 0x900
+#define PCIE_PL_iATUVR (ATU_R_BaseAddress + 0x0)
+#define PCIE_PL_iATURC1 (ATU_R_BaseAddress + 0x4)
+#define PCIE_PL_iATURC2 (ATU_R_BaseAddress + 0x8)
+#define PCIE_PL_iATURLBA (ATU_R_BaseAddress + 0xC)
+#define PCIE_PL_iATURUBA (ATU_R_BaseAddress + 0x10)
+#define PCIE_PL_iATURLA (ATU_R_BaseAddress + 0x14)
+#define PCIE_PL_iATURLTA (ATU_R_BaseAddress + 0x18)
+#define PCIE_PL_iATURUTA (ATU_R_BaseAddress + 0x1C)
+
+/* GPR1: iomuxc_gpr1_pcie_ref_clk_en(iomuxc_gpr1[16]) */
+#define iomuxc_gpr1_pcie_ref_clk_en		(1 << 16)
+/* GPR1: iomuxc_gpr1_test_powerdown(iomuxc_gpr1_18) */
+#define iomuxc_gpr1_test_powerdown		(1 << 18)
+
+/* GPR12: iomuxc_gpr12_los_level(iomuxc_gpr12[8:4]) */
+#define iomuxc_gpr12_los_level			(0x1F << 4)
+/* GPR12: iomuxc_gpr12_app_ltssm_enable(iomuxc_gpr12[10]) */
+#define iomuxc_gpr12_app_ltssm_enable		(1 << 10)
+/* GPR12: iomuxc_gpr12_device_type(iomuxc_gpr12[15:12]) */
+#define iomuxc_gpr12_device_type		(0xF << 12)
+
+/* GPR8: iomuxc_gpr8_tx_deemph_gen1(iomuxc_gpr8[5:0]) */
+#define iomuxc_gpr8_tx_deemph_gen1		(0x3F << 0)
+/* GPR8: iomuxc_gpr8_tx_deemph_gen2_3p5db(iomuxc_gpr8[11:6]) */
+#define iomuxc_gpr8_tx_deemph_gen2_3p5db	(0x3F << 6)
+/* GPR8: iomuxc_gpr8_tx_deemph_gen2_6db(iomuxc_gpr8[17:12]) */
+#define iomuxc_gpr8_tx_deemph_gen2_6db		(0x3F << 12)
+/* GPR8: iomuxc_gpr8_tx_swing_full(iomuxc_gpr8[24:18]) */
+#define iomuxc_gpr8_tx_swing_full		(0x7F << 18)
+/* GPR8: iomuxc_gpr8_tx_swing_low(iomuxc_gpr8[31:25]) */
+#define iomuxc_gpr8_tx_swing_low		(0x7F << 25)
+
+/* Registers of PHY */
+/* Register PHY_STS_R */
+/* PHY Status Register */
+#define PHY_STS_R (PRT_LOG_R_BaseAddress + 0x110)
+
+/* Register PHY_CTRL_R */
+/* PHY Control Register */
+#define PHY_CTRL_R (PRT_LOG_R_BaseAddress + 0x114)
+
+#define SSP_CR_SUP_DIG_MPLL_OVRD_IN_LO 0x0011
+/* FIELD: RES_ACK_IN_OVRD [15:15]
+// FIELD: RES_ACK_IN [14:14]
+// FIELD: RES_REQ_IN_OVRD [13:13]
+// FIELD: RES_REQ_IN [12:12]
+// FIELD: RTUNE_REQ_OVRD [11:11]
+// FIELD: RTUNE_REQ [10:10]
+// FIELD: MPLL_MULTIPLIER_OVRD [9:9]
+// FIELD: MPLL_MULTIPLIER [8:2]
+// FIELD: MPLL_EN_OVRD [1:1]
+// FIELD: MPLL_EN [0:0]
+*/
+
+#define SSP_CR_SUP_DIG_ATEOVRD 0x0010
+/* FIELD: ateovrd_en [2:2]
+// FIELD: ref_usb2_en [1:1]
+// FIELD: ref_clkdiv2 [0:0]
+*/
+
+#define SSP_CR_LANE0_DIG_RX_OVRD_IN_LO 0x1005
+/* FIELD: RX_LOS_EN_OVRD [13:13]
+// FIELD: RX_LOS_EN [12:12]
+// FIELD: RX_TERM_EN_OVRD [11:11]
+// FIELD: RX_TERM_EN [10:10]
+// FIELD: RX_BIT_SHIFT_OVRD [9:9]
+// FIELD: RX_BIT_SHIFT [8:8]
+// FIELD: RX_ALIGN_EN_OVRD [7:7]
+// FIELD: RX_ALIGN_EN [6:6]
+// FIELD: RX_DATA_EN_OVRD [5:5]
+// FIELD: RX_DATA_EN [4:4]
+// FIELD: RX_PLL_EN_OVRD [3:3]
+// FIELD: RX_PLL_EN [2:2]
+// FIELD: RX_INVERT_OVRD [1:1]
+// FIELD: RX_INVERT [0:0]
+*/
+
+#define SSP_CR_LANE0_DIG_RX_ASIC_OUT 0x100D
+/* FIELD: LOS [2:2]
+// FIELD: PLL_STATE [1:1]
+// FIELD: VALID [0:0]
+*/
+
+/* control bus bit definition */
+#define PCIE_CR_CTL_DATA_LOC 0
+#define PCIE_CR_CTL_CAP_ADR_LOC 16
+#define PCIE_CR_CTL_CAP_DAT_LOC 17
+#define PCIE_CR_CTL_WR_LOC 18
+#define PCIE_CR_CTL_RD_LOC 19
+#define PCIE_CR_STAT_DATA_LOC 0
+#define PCIE_CR_STAT_ACK_LOC 16
+
+/* End of Register Definitions */
+
+#define  PCIE_CONF_BUS(b)		(((b) & 0xFF) << 16)
+#define  PCIE_CONF_DEV(d)		(((d) & 0x1F) << 11)
+#define  PCIE_CONF_FUNC(f)		(((f) & 0x7) << 8)
+#define  PCIE_CONF_REG(r)		((r) & ~0x3)
+
+
+/* Taken from PCI specs */
+enum {
+	MemRdWr = 0,
+	MemRdLk = 1,
+	IORdWr = 2,
+	CfgRdWr0 = 4,
+	CfgRdWr1 = 5
+};
+
+
+struct imx_pcie_port {
+	struct device		*dev;
+	u8			index;
+	u8			root_bus_nr;
+	int			interrupt;
+
+	struct resource		*dbi;
+	struct resource		*io;
+	struct resource 	*mem;
+	struct resource 	*root;
+
+	struct regmap		*iomuxc_gpr;
+
+	void __iomem		*root_base;
+	void __iomem		*dbi_base;
+	void __iomem		*io_base;
+	void __iomem		*mem_base;
+	spinlock_t		conf_lock;
+
+	char			io_space_name[16];
+	char			mem_space_name[16];
+
+	struct list_head	next;
+
+	struct clk		*lvds1_sel;
+	struct clk		*lvds1;
+	struct clk		*pcie_ref_125m;
+	struct clk		*pcie_axi;
+	struct clk		*sata_ref;
+
+        unsigned int		pcie_pwr_en;
+        unsigned int		pcie_rst;
+        unsigned int		pcie_wake_up;
+
+	struct rfkill		*rfkill;
+};
+
+static const struct of_device_id pcie_of_match[] = {
+	{
+		.compatible	= "fsl,imx6q-pcie",
+		.data		= NULL,
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, pcie_of_match);
+
+static struct list_head pcie_port_list;
+static struct hw_pci imx_pcie;
+
+static int pcie_phy_cr_read(void __iomem *dbi_base, int addr, int *data);
+static int pcie_phy_cr_write(void __iomem *dbi_base, int addr, int data);
+
+
+/* IMX PCIE GPR configure routines */
+static void imx_pcie_clrset(struct imx_pcie_port *pp,
+			    u32 mask, u32 val, u32 reg)
+{
+	u32 tmp;
+	regmap_read(pp->iomuxc_gpr, reg, &tmp);
+	tmp &= ~mask;
+	tmp |= (val & mask);
+	regmap_write(pp->iomuxc_gpr, reg, tmp);
+}
+
+static void change_field(int *in, int start, int end, int val)
+{
+	int mask;
+	mask = ((0xFFFFFFFF << start) ^ (0xFFFFFFFF << (end + 1))) & 0xFFFFFFFF;
+	*in = (*in & ~mask) | (val << start);
+}
+
+
+static struct imx_pcie_port *controller_to_port(int index)
+{
+	struct imx_pcie_port *pp;
+
+	if (index >= imx_pcie.nr_controllers) {
+		pr_err("%d exceeded number of controllers %d\n",
+			index, imx_pcie.nr_controllers);
+		return NULL;
+	}
+
+	list_for_each_entry(pp, &pcie_port_list, next) {
+		if (pp->index == index)
+			return pp;
+	}
+	return NULL;
+}
+
+static struct imx_pcie_port *bus_to_port(int bus)
+{
+	int i;
+	int rbus;
+	struct imx_pcie_port *pp;
+
+	for (i = imx_pcie.nr_controllers - 1 ; i >= 0; i--) {
+		pp = controller_to_port(i);
+		rbus = pp->root_bus_nr;
+		if (rbus != -1 && rbus <= bus)
+			break;
+	}
+
+	return i >= 0 ? pp : NULL;
+}
+
+static int __init imx_pcie_setup(int nr, struct pci_sys_data *sys)
+{
+	struct imx_pcie_port *pp;
+	int ret;
+
+	pp = controller_to_port(nr);
+	if (!pp) {
+		pr_err("unable to find port %d\n", nr);
+		return 0;
+	}
+
+	pp->root_bus_nr = sys->busnr;
+
+	/*
+	 * IORESOURCE_MEM
+	 */
+	snprintf(pp->mem_space_name, sizeof(pp->mem_space_name),
+			"PCIe %d MEM", pp->index);
+
+	pp->mem_space_name[sizeof(pp->mem_space_name) - 1] = 0;
+	pp->mem->name = pp->mem_space_name;
+	pp->mem->flags = IORESOURCE_MEM;
+	ret = request_resource(&iomem_resource, pp->mem);
+	if (ret)
+		dev_err(pp->dev, "Request PCIe Memory resource failed\n");
+	pci_add_resource_offset(&sys->resources, pp->mem, sys->mem_offset);
+
+
+	snprintf(pp->io_space_name, sizeof(pp->io_space_name),
+		 "PCIe %d I/O", pp->index);
+	pp->io_space_name[sizeof(pp->io_space_name) - 1] = 0;
+	pp->io->name = pp->io_space_name;
+	pp->io->flags = IORESOURCE_IO;
+
+	ret = request_resource(&iomem_resource, pp->io);
+	if (ret)
+		dev_err(pp->dev, "Request PCIe IO resource failed\n");
+	pci_add_resource_offset(&sys->resources, pp->io, sys->io_offset);
+
+	/*
+	 * IORESOURCE_IO
+	 */
+	ret = pci_ioremap_io(PCIBIOS_MIN_IO, pp->io->start);
+	if (ret)
+		dev_err(pp->dev, "Request PCIe IO resource failed\n");
+
+	return 1;
+}
+
+static int imx_pcie_link_up(struct platform_device *pdev)
+{
+	struct imx_pcie_port *pp = platform_get_drvdata(pdev);
+	int iterations = 200;
+	u32 rc, ltssm, rx_valid, temp;
+
+	rc = 0;
+	for (iterations = 200; iterations > 0 && !rc; iterations--) {
+		/* link is debug bit 36, debug register 1 starts at bit 32 */
+		rc = readl(pp->dbi_base + DEBUG_R1) & (0x1 << (36 - 32)) ;
+		usleep_range(2000, 3000);
+
+		/* From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
+		 * Wait 2ms (LTSSM timeout is 24ms, PHY lock is ~5us in gen2).
+		 * If (MAC/LTSSM.state == Recovery.RcvrLock)
+		 * && (PHY/rx_valid==0) then pulse PHY/rx_reset. Transition
+		 * to gen2 is stuck
+		 */
+		pcie_phy_cr_read(pp->dbi_base, SSP_CR_LANE0_DIG_RX_ASIC_OUT, &rx_valid);
+		ltssm = readl(pp->dbi_base + DEBUG_R0) & 0x3F;
+		if ((ltssm == 0x0D) && ((rx_valid & 0x01) == 0)) {
+			dev_err(&pdev->dev,
+				"transition to gen2 is stuck, reset PHY!\n");
+			pcie_phy_cr_read(pp->dbi_base, SSP_CR_LANE0_DIG_RX_OVRD_IN_LO, &temp);
+			change_field(&temp, 3, 3, 0x1);
+			change_field(&temp, 5, 5, 0x1);
+			pcie_phy_cr_write(pp->dbi_base, SSP_CR_LANE0_DIG_RX_OVRD_IN_LO,
+					0x0028);
+			usleep_range(2000, 3000);
+			pcie_phy_cr_read(pp->dbi_base, SSP_CR_LANE0_DIG_RX_OVRD_IN_LO, &temp);
+			change_field(&temp, 3, 3, 0x0);
+			change_field(&temp, 5, 5, 0x0);
+			pcie_phy_cr_write(pp->dbi_base, SSP_CR_LANE0_DIG_RX_OVRD_IN_LO,
+					0x0000);
+		}
+
+	}
+
+	if (!rc) {
+		if (iterations <= 0) {
+			dev_err(&pdev->dev,
+				"link up failed, DEBUG_R0:0x%08x, DEBUG_R1:0x%08x  RX_VALID:0x%x!\n",
+				readl(pp->dbi_base + DEBUG_R0),
+				readl(pp->dbi_base + DEBUG_R1),
+				rx_valid);
+			return -ETIMEDOUT;
+		}
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+static int imx_pcie_regions_setup(struct platform_device *pdev,
+					struct imx_pcie_port *pp)
+{
+	void __iomem *dbi_base = pp->dbi_base;
+	/*
+	 * i.MX6 defines 16MB in the AXI address map for PCIe.
+	 *
+	 * That address space excepted the pcie registers is
+	 * split and defined into different regions by iATU,
+	 * with sizes and offsets as follows:
+	 *
+	 * 0x0100_0000 --- 0x010F_FFFF 1MB IORESOURCE_IO
+	 * 0x0110_0000 --- 0x01EF_FFFF 14MB IORESOURCE_MEM
+	 * 0x01F0_0000 --- 0x01FF_FFFF 1MB Cfg + Registers
+	 */
+
+	/* CMD reg:I/O space, MEM space, and Bus Master Enable */
+	writel(readl(dbi_base + PCI_COMMAND)
+			| PCI_COMMAND_IO
+			| PCI_COMMAND_MEMORY
+			| PCI_COMMAND_MASTER,
+			dbi_base + PCI_COMMAND);
+
+	/* Set the CLASS_REV of RC CFG header to PCI_CLASS_BRIDGE_PCI */
+	writel(readl(dbi_base + PCI_CLASS_REVISION)
+			| (PCI_CLASS_BRIDGE_PCI << 16),
+			dbi_base + PCI_CLASS_REVISION);
+
+	/*
+	 * region0 outbound used to access target cfg
+	 */
+	writel(0, dbi_base + PCIE_PL_iATUVR);
+	writel(pp->root->start, dbi_base + PCIE_PL_iATURLBA);
+	writel(pp->dbi->end, dbi_base + PCIE_PL_iATURLA);
+	writel(0, dbi_base + PCIE_PL_iATURUBA);
+
+	writel(0, dbi_base + PCIE_PL_iATURLTA);
+	writel(0, dbi_base + PCIE_PL_iATURUTA);
+	writel(CfgRdWr0, dbi_base + PCIE_PL_iATURC1);
+	writel((1<<31), dbi_base + PCIE_PL_iATURC2);
+
+	return 0;
+}
+
+
+static int imx_pcie_valid_config(struct imx_pcie_port *pp,
+				struct pci_bus *bus, int devfn)
+{
+	if (bus->number >= 2)
+		return 0;
+
+	if (devfn != 0)
+		return 0;
+
+	return 1;
+}
+
+
+static u32 get_bus_address(struct imx_pcie_port *pp,
+			   struct pci_bus *bus, u32 devfn, int where)
+{
+	u32 va_address;
+	if (bus->number == 0) {
+		va_address = (u32)pp->dbi_base + (where & ~0x3);
+	}
+	else {
+		va_address = (u32)pp->root_base +
+					(PCIE_CONF_BUS(bus->number - 1) +
+					PCIE_CONF_DEV(PCI_SLOT(devfn)) +
+					PCIE_CONF_FUNC(PCI_FUNC(devfn)) +
+					PCIE_CONF_REG(where));
+	}
+	return va_address;
+}
+
+static int imx_pcie_read_config(struct pci_bus *bus, u32 devfn, int where,
+			int size, u32 *val)
+{
+	struct imx_pcie_port *pp = bus_to_port(bus->number);
+	u32 va_address;
+
+	if (!pp) {
+		BUG();
+		return -EINVAL;
+	}
+
+	if (imx_pcie_valid_config(pp, bus, PCI_SLOT(devfn)) == 0) {
+		*val = 0xffffffff;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	va_address = get_bus_address(pp, bus, devfn, where);
+
+	*val = readl((u32 *)va_address);
+
+	if (size == 1)
+		*val = (*val >> (8 * (where & 3))) & 0xFF;
+	else if (size == 2)
+		*val = (*val >> (8 * (where & 3))) & 0xFFFF;
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static int imx_pcie_write_config(struct pci_bus *bus, u32 devfn,
+			int where, int size, u32 val)
+{
+	struct imx_pcie_port *pp = bus_to_port(bus->number);
+	u32 va_address = 0, mask = 0, tmp = 0;
+	int ret = PCIBIOS_SUCCESSFUL;
+
+	if (!pp) {
+		BUG();
+		return -EINVAL;
+	}
+
+	if (imx_pcie_valid_config(pp, bus, PCI_SLOT(devfn)) == 0)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	va_address = get_bus_address(pp, bus, devfn, where);
+
+	if (size == 4) {
+		writel(val, (u32 *)va_address);
+		goto exit;
+	}
+
+	if (size == 2)
+		mask = ~(0xFFFF << ((where & 0x3) * 8));
+	else if (size == 1)
+		mask = ~(0xFF << ((where & 0x3) * 8));
+	else
+		ret = PCIBIOS_BAD_REGISTER_NUMBER;
+
+	tmp = readl((u32 *)va_address) & mask;
+	tmp |= val << ((where & 0x3) * 8);
+	writel(tmp, (u32 *)va_address);
+exit:
+
+	return ret;
+}
+
+
+
+static struct pci_ops imx_pcie_ops = {
+	.read = imx_pcie_read_config,
+	.write = imx_pcie_write_config,
+};
+
+static struct pci_bus __init *
+imx_pcie_scan_bus(int nr, struct pci_sys_data *sys)
+{
+	struct imx_pcie_port *pp = controller_to_port(nr);
+	if (nr > 1)
+		return NULL;
+        pp->root_bus_nr = sys->busnr;
+
+        return pci_scan_root_bus(NULL, sys->busnr, &imx_pcie_ops, sys,
+                                 &sys->resources);
+}
+
+static int __init imx_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+{
+	struct imx_pcie_port *pp = controller_to_port(0);
+	return pp->interrupt;
+}
+
+static struct hw_pci imx_pci __initdata = {
+	.nr_controllers	= 1,
+	.setup		= imx_pcie_setup,
+	.scan		= imx_pcie_scan_bus,
+	.map_irq	= imx_pcie_map_irq,
+};
+
+/* PHY CR bus acess routines */
+static int pcie_phy_cr_ack_polling(void __iomem *dbi_base, int max_iterations, int exp_val)
+{
+	u32 temp_rd_data, wait_counter = 0;
+
+	do {
+		temp_rd_data = readl(dbi_base + PHY_STS_R);
+		temp_rd_data = (temp_rd_data >> PCIE_CR_STAT_ACK_LOC) & 0x1;
+		wait_counter++;
+	} while ((wait_counter < max_iterations) && (temp_rd_data != exp_val));
+
+	if (temp_rd_data != exp_val)
+		return 0 ;
+	return 1 ;
+}
+
+static int pcie_phy_cr_cap_addr(void __iomem *dbi_base, int addr)
+{
+	u32 temp_wr_data;
+
+	/* write addr */
+	temp_wr_data = addr << PCIE_CR_CTL_DATA_LOC ;
+	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
+
+	/* capture addr */
+	temp_wr_data |= (0x1 << PCIE_CR_CTL_CAP_ADR_LOC);
+	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
+
+	/* wait for ack */
+	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 1))
+		return 0;
+
+	/* deassert cap addr */
+	temp_wr_data = addr << PCIE_CR_CTL_DATA_LOC;
+	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
+
+	/* wait for ack de-assetion */
+	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 0))
+		return 0 ;
+
+	return 1 ;
+}
+
+static int pcie_phy_cr_read(void __iomem *dbi_base, int addr , int *data)
+{
+	u32 temp_rd_data, temp_wr_data;
+
+	/*  write addr */
+	/* cap addr */
+	if (!pcie_phy_cr_cap_addr(dbi_base, addr))
+		return 0;
+
+	/* assert rd signal */
+	temp_wr_data = 0x1 << PCIE_CR_CTL_RD_LOC;
+	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
+
+	/* wait for ack */
+	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 1))
+		return 0;
+
+	/* after got ack return data */
+	temp_rd_data = readl(dbi_base + PHY_STS_R);
+	*data = (temp_rd_data & (0xffff << PCIE_CR_STAT_DATA_LOC)) ;
+
+	/* deassert rd signal */
+	temp_wr_data = 0x0;
+	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
+
+	/* wait for ack de-assetion */
+	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 0))
+		return 0 ;
+
+	return 1 ;
+
+}
+
+static int pcie_phy_cr_write(void __iomem *dbi_base, int addr, int data)
+{
+	u32 temp_wr_data;
+
+	/* write addr */
+	/* cap addr */
+	if (!pcie_phy_cr_cap_addr(dbi_base, addr))
+		return 0 ;
+
+	temp_wr_data = data << PCIE_CR_CTL_DATA_LOC;
+	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
+
+	/* capture data */
+	temp_wr_data |= (0x1 << PCIE_CR_CTL_CAP_DAT_LOC);
+	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
+
+	/* wait for ack */
+	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 1))
+		return 0 ;
+
+	/* deassert cap data */
+	temp_wr_data = data << PCIE_CR_CTL_DATA_LOC;
+	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
+
+	/* wait for ack de-assetion */
+	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 0))
+		return 0;
+
+	/* assert wr signal */
+	temp_wr_data = 0x1 << PCIE_CR_CTL_WR_LOC;
+	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
+
+	/* wait for ack */
+	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 1))
+		return 0;
+
+	/* deassert wr signal */
+	temp_wr_data = data << PCIE_CR_CTL_DATA_LOC;
+	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
+
+	/* wait for ack de-assetion */
+	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 0))
+		return 0;
+
+	temp_wr_data = 0x0 ;
+	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
+
+	return 1;
+}
+
+static int imx_pcie_enable_controller(struct platform_device *pdev)
+{
+	struct imx_pcie_port *pp = platform_get_drvdata(pdev);
+	int ret;
+
+	/* Enable PCIE power */
+	gpio_set_value(pp->pcie_pwr_en, 1);
+
+	imx_pcie_clrset(pp, iomuxc_gpr1_test_powerdown, 0 << 18, IOMUXC_GPR1);
+	imx_pcie_clrset(pp, iomuxc_gpr1_pcie_ref_clk_en, 1 << 16, IOMUXC_GPR1);
+
+	/* Enable clocks */
+	ret = clk_set_parent(pp->lvds1_sel, pp->sata_ref);
+	if (ret) {
+		dev_err(&pdev->dev, "unable to set lvds1 parent: %d\n", ret);
+		return -EINVAL;
+	}
+
+	ret = clk_prepare_enable(pp->pcie_ref_125m);
+	if (ret) {
+		dev_err(&pdev->dev, "unable to enable pcie_ref_125m: %d\n", ret);
+		return -EINVAL;
+	}
+
+	ret = clk_prepare_enable(pp->lvds1);
+	if (ret) {
+		dev_err(&pdev->dev, "unable to enable lvds1: %d\n", ret);
+		return -EINVAL;
+	}
+
+	ret = clk_prepare_enable(pp->pcie_axi);
+	if (ret) {
+		dev_err(&pdev->dev, "unable to enable pcie_axi: %d\n", ret);
+		return -EINVAL;
+	}
+
+
+	return 0;
+}
+
+static void card_reset(struct platform_device *pdev)
+{
+	struct imx_pcie_port *pp = platform_get_drvdata(pdev);
+
+	imx_pcie_clrset(pp, iomuxc_gpr1_test_powerdown, 1 << 18, IOMUXC_GPR1);
+	imx_pcie_clrset(pp, iomuxc_gpr12_app_ltssm_enable, 1 << 10, IOMUXC_GPR12);
+	imx_pcie_clrset(pp, iomuxc_gpr1_pcie_ref_clk_en, 0 << 16, IOMUXC_GPR1);
+
+	gpio_set_value(pp->pcie_rst, 0);
+	msleep(100);
+	gpio_set_value(pp->pcie_rst, 1);
+}
+
+static int __init add_pcie_port(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct imx_pcie_port *pp = platform_get_drvdata(pdev);
+	int ret;
+
+	ret = imx_pcie_link_up(pdev);
+	if (ret) {
+		dev_info(dev, "IMX PCIe port: link down!\n");
+		/* Release the clocks, and disable the power */
+
+		clk_disable(pp->pcie_axi);
+		clk_put(pp->pcie_axi);
+
+		clk_disable(pp->lvds1);
+		clk_put(pp->lvds1);
+
+		clk_put(pp->pcie_ref_125m);
+		clk_put(pp->sata_ref);
+
+		imx_pcie_clrset(pp, iomuxc_gpr1_pcie_ref_clk_en, 0 << 16,
+				IOMUXC_GPR1);
+
+		/* Disable PCIE power */
+		gpio_set_value(pp->pcie_pwr_en, 0);
+
+		imx_pcie_clrset(pp, iomuxc_gpr1_test_powerdown, 1 << 18,
+				IOMUXC_GPR1);
+
+		return ret;
+	}
+
+	dev_info(dev, "IMX PCIe port: link up.\n");
+	pp->index = 0;
+	pp->root_bus_nr = -1;
+	spin_lock_init(&pp->conf_lock);
+	return 0;
+}
+
+
+static int set_pcie_clock_tunings(struct platform_device *pdev)
+{
+	struct imx_pcie_port *pp = platform_get_drvdata(pdev);
+	/* FIXME the field name should be aligned to RM */
+	imx_pcie_clrset(pp, iomuxc_gpr12_app_ltssm_enable, 0 << 10, IOMUXC_GPR12);
+
+	/* configure constant input signal to the pcie ctrl and phy */
+	imx_pcie_clrset(pp, iomuxc_gpr12_device_type, PCI_EXP_TYPE_ROOT_PORT << 12,
+			IOMUXC_GPR12);
+	imx_pcie_clrset(pp, iomuxc_gpr12_los_level, 9 << 4, IOMUXC_GPR12);
+
+	imx_pcie_clrset(pp, iomuxc_gpr8_tx_deemph_gen1, 0 << 0, IOMUXC_GPR8);
+	imx_pcie_clrset(pp, iomuxc_gpr8_tx_deemph_gen2_3p5db, 0 << 6, IOMUXC_GPR8);
+	imx_pcie_clrset(pp, iomuxc_gpr8_tx_deemph_gen2_6db, 20 << 12, IOMUXC_GPR8);
+	imx_pcie_clrset(pp, iomuxc_gpr8_tx_swing_full, 127 << 18, IOMUXC_GPR8);
+	imx_pcie_clrset(pp, iomuxc_gpr8_tx_swing_low, 127 << 25, IOMUXC_GPR8);
+	return 0;
+}
+
+
+static int __init imx_pcie_pltfm_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct imx_pcie_port *pp = devm_kzalloc(dev, sizeof(*pp), GFP_KERNEL);
+	int ret;
+
+	platform_set_drvdata(pdev, pp);
+	pp->dev = &pdev->dev;
+
+        pp->pcie_pwr_en = of_get_named_gpio(pdev->dev.of_node,
+                                "power-enable", 0);
+        if (gpio_is_valid(pp->pcie_pwr_en))
+                devm_gpio_request_one(dev, pp->pcie_pwr_en,
+                                    GPIOF_OUT_INIT_LOW,
+                                    "PCIe power enable");
+
+        pp->pcie_rst = of_get_named_gpio(pdev->dev.of_node,
+                                "pcie-reset", 0);
+        if (gpio_is_valid(pp->pcie_rst))
+                devm_gpio_request_one(dev, pp->pcie_rst,
+                                    GPIOF_OUT_INIT_LOW,
+                                    "PCIe reset");
+
+        pp->pcie_wake_up = of_get_named_gpio(pdev->dev.of_node,
+                                "wake-up", 0);
+        if (gpio_is_valid(pp->pcie_wake_up))
+                devm_gpio_request_one(dev, pp->pcie_wake_up,
+                                    GPIOF_IN,
+                                    "PCIe wake up");
+
+	pp->dbi = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!pp->dbi) {
+		dev_err(dev, "no mmio space\n");
+		return -EINVAL;
+	}
+
+	pp->dbi_base = devm_request_and_ioremap(&pdev->dev, pp->dbi);
+	if (!pp->dbi_base) {
+		pr_err("unable to remap dbi\n");
+		return -ENOMEM;
+	}
+
+
+	pp->io = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	if (!pp->io) {
+		dev_err(dev, "no mmio space\n");
+		return -EINVAL;
+	}
+
+	pp->mem = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+	if (!pp->mem) {
+		dev_err(dev, "no mmio space\n");
+		return -EINVAL;
+	}
+
+	pp->root = platform_get_resource(pdev, IORESOURCE_MEM, 3);
+	if (!pp->root) {
+		dev_err(dev, "no root memory space\n");
+		return -EINVAL;
+	}
+
+	pp->root_base = devm_request_and_ioremap(&pdev->dev, pp->root);
+	if (!pp->root_base) {
+		dev_err(&pdev->dev, "unable to remap root mem\n");
+		return -ENOMEM;
+	}
+
+
+	pp->interrupt = platform_get_irq(pdev, 0);
+
+
+        /* Setup clocks */
+	pp->lvds1_sel = clk_get(dev, "lvds1_sel");
+	if (IS_ERR(pp->lvds1_sel)) {
+		dev_err(dev,
+			"lvds1_sel clock missing or invalid\n");
+		ret = -EINVAL;
+		goto err_out;
+	}
+
+	pp->lvds1 = clk_get(dev, "lvds1");
+	if (IS_ERR(pp->lvds1)) {
+		dev_err(dev,
+			"lvds1 clock select missing or invalid\n");
+		ret = -EINVAL;
+		goto err_out;
+	}
+
+	pp->pcie_ref_125m = clk_get(dev, "pcie_ref_125m");
+	if (IS_ERR(pp->pcie_ref_125m)) {
+		dev_err(dev,
+			"pcie_ref_125m clock source missing or invalid\n");
+		ret = -EINVAL;
+		goto err_out;
+	}
+
+	pp->pcie_axi = clk_get(dev, "pcie_axi");
+	if (IS_ERR(pp->pcie_axi)) {
+		dev_err(dev, "pcie_axi clock source missing or invalid\n");
+		ret = -EINVAL;
+		goto err_out;
+	}
+
+	pp->sata_ref = clk_get(dev, "sata_ref");
+	if (IS_ERR(pp->sata_ref)) {
+		dev_err(dev, "sata_ref clock source missing or invalid\n");
+		ret = -EINVAL;
+		goto err_out;
+	}
+
+	pp->iomuxc_gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
+	if (IS_ERR(pp->iomuxc_gpr)) {
+		dev_err(dev, "unable to find iomuxc registers\n");
+		ret = -EINVAL;
+		goto err_out;
+	}
+
+	/* togle the external card's reset */
+	card_reset(pdev);
+
+	/* Enable the pwr, clks and so on */
+	set_pcie_clock_tunings(pdev);
+	ret = imx_pcie_enable_controller(pdev);
+	if (ret)
+		goto err_out;
+
+	usleep_range(3000, 4000);
+	imx_pcie_regions_setup(pdev, pp);
+	usleep_range(3000, 4000);
+
+	/* start link up */
+	imx_pcie_clrset(pp, iomuxc_gpr12_app_ltssm_enable, 1 << 10, IOMUXC_GPR12);
+
+	/* add the pcie port */
+	ret = add_pcie_port(pdev);
+	if (ret)
+		goto err_out;
+
+	pp->index = imx_pcie.nr_controllers;
+	imx_pcie.nr_controllers++;
+	list_add_tail(&pp->next, &pcie_port_list);
+
+	pci_common_init(&imx_pci);
+
+	return 0;
+
+err_out:
+	if (pp->lvds1_sel)
+		clk_put(pp->lvds1_sel);
+	if (pp->lvds1)
+		clk_put(pp->lvds1);
+	if (pp->pcie_ref_125m)
+		clk_put(pp->pcie_ref_125m);
+	if (pp->pcie_axi)
+		clk_put(pp->pcie_axi);
+	if (pp->sata_ref)
+		clk_put(pp->sata_ref);
+	return ret;
+}
+
+static int __exit imx_pcie_pltfm_remove(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct imx_pcie_port *pp = platform_get_drvdata(pdev);
+
+	if (pp->rfkill) {
+		rfkill_unregister(pp->rfkill);
+		rfkill_destroy(pp->rfkill);
+		pp->rfkill = NULL;
+	}
+
+	imx_pcie_clrset(pp, iomuxc_gpr1_pcie_ref_clk_en, 0 << 16, IOMUXC_GPR1);
+	imx_pcie_clrset(pp, iomuxc_gpr1_test_powerdown, 1 << 18, IOMUXC_GPR1);
+	imx_pcie_clrset(pp, iomuxc_gpr12_app_ltssm_enable, 1 << 10, IOMUXC_GPR12);
+
+	/* Release clocks, and disable power  */
+	if (pp->pcie_axi) {
+		clk_disable(pp->pcie_axi);
+		clk_put(pp->pcie_axi);
+	}
+
+	if (pp->lvds1) {
+		clk_disable(pp->lvds1);
+		clk_put(pp->lvds1);
+	}
+
+	if (pp->pcie_ref_125m)
+		clk_put(pp->pcie_ref_125m);
+
+	if (pp->sata_ref)
+		clk_put(pp->sata_ref);
+
+	gpio_set_value(pp->pcie_rst, 0);
+	gpio_set_value(pp->pcie_pwr_en, 0);
+
+	dev_err(dev, "disabled everything\n");
+	msleep(500);
+
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static struct platform_driver imx_pcie_pltfm_driver = {
+	.driver = {
+		.name		= "imx-pcie",
+		.owner		= THIS_MODULE,
+		.of_match_table = pcie_of_match,
+	},
+	.probe		= imx_pcie_pltfm_probe,
+	.remove		= __exit_p(imx_pcie_pltfm_remove),
+};
+
+/*****************************************************************************\
+ *                                                                           *
+ * Driver init/exit                                                          *
+ *                                                                           *
+\*****************************************************************************/
+
+static int __init imx_pcie_drv_init(void)
+{
+	INIT_LIST_HEAD(&pcie_port_list);
+	return platform_driver_register(&imx_pcie_pltfm_driver);
+}
+
+static void __exit imx_pcie_drv_exit(void)
+{
+	platform_driver_unregister(&imx_pcie_pltfm_driver);
+}
+
+module_init(imx_pcie_drv_init);
+module_exit(imx_pcie_drv_exit);
+
+MODULE_DESCRIPTION("i.MX PCIE platform driver");
+MODULE_AUTHOR("Sean Cross <xobs at kosagi.com>");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5



From taki at igel.co.jp  Mon Jul  1 03:38:53 2013
From: taki at igel.co.jp (Takanari Hayama)
Date: Mon, 01 Jul 2013 16:38:53 +0900
Subject: [PATCH] ARM: shmobile: r8a73a4: Fix resources for SCIFB0
Message-ID: <51D1320D.4010709@igel.co.jp>

From: Takanari Hayama <taki at igel.co.jp>

Fix base address and IRQ resources associated with SCIFB0.

Signed-off-by: Takanari Hayama <taki at igel.co.jp>
---
 arch/arm/mach-shmobile/setup-r8a73a4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c
b/arch/arm/mach-shmobile/setup-r8a73a4.c
index c5a75a7..7f45c2e 100644
--- a/arch/arm/mach-shmobile/setup-r8a73a4.c
+++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
@@ -62,7 +62,7 @@ enum { SCIFA0, SCIFA1, SCIFB0, SCIFB1, SCIFB2, SCIFB3 };
 static const struct plat_sci_port scif[] = {
 	SCIFA_DATA(SCIFA0, 0xe6c40000, gic_spi(144)), /* SCIFA0 */
 	SCIFA_DATA(SCIFA1, 0xe6c50000, gic_spi(145)), /* SCIFA1 */
-	SCIFB_DATA(SCIFB0, 0xe6c50000, gic_spi(145)), /* SCIFB0 */
+	SCIFB_DATA(SCIFB0, 0xe6c20000, gic_spi(148)), /* SCIFB0 */
 	SCIFB_DATA(SCIFB1, 0xe6c30000, gic_spi(149)), /* SCIFB1 */
 	SCIFB_DATA(SCIFB2, 0xe6ce0000, gic_spi(150)), /* SCIFB2 */
 	SCIFB_DATA(SCIFB3, 0xe6cf0000, gic_spi(151)), /* SCIFB3 */
-- 
1.8.0

-- 
Takanari Hayama, Ph.D. (taki at igel.co.jp)
IGEL Co.,Ltd.
http://www.igel.co.jp/


From horms at verge.net.au  Mon Jul  1 03:47:08 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 1 Jul 2013 16:47:08 +0900
Subject: [PATCH 02/04] ARM: shmobile: Use default ->init_irq() on r8a73a4
In-Reply-To: <20130701060121.21728.18844.sendpatchset@w520>
References: <20130701060103.21728.83833.sendpatchset@w520>
 <20130701060121.21728.18844.sendpatchset@w520>
Message-ID: <20130701074707.GV14567@verge.net.au>

On Mon, Jul 01, 2013 at 03:01:21PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Remove redundant irqchip_init() callback. The default case
> of NULL will result in invoking irqchip_init() anyway.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  arch/arm/mach-shmobile/board-ape6evm.c |    2 --
>  arch/arm/mach-shmobile/setup-r8a73a4.c |    2 --
>  2 files changed, 4 deletions(-)
> 
> --- 0001/arch/arm/mach-shmobile/board-ape6evm.c
> +++ work/arch/arm/mach-shmobile/board-ape6evm.c	2013-07-01 13:29:37.000000000 +0900
> @@ -20,7 +20,6 @@
>  
>  #include <linux/gpio.h>
>  #include <linux/interrupt.h>
> -#include <linux/irqchip.h>
>  #include <linux/kernel.h>
>  #include <linux/pinctrl/machine.h>
>  #include <linux/platform_device.h>
> @@ -103,7 +102,6 @@ static const char *ape6evm_boards_compat
>  
>  DT_MACHINE_START(APE6EVM_DT, "ape6evm")
>  	.init_early	= r8a73a4_init_delay,
> -	.init_irq	= irqchip_init,
>  	.init_time	= shmobile_timer_init,
>  	.init_machine	= ape6evm_add_standard_devices,
>  	.dt_compat	= ape6evm_boards_compat_dt,
> --- 0001/arch/arm/mach-shmobile/setup-r8a73a4.c
> +++ work/arch/arm/mach-shmobile/setup-r8a73a4.c	2013-07-01 13:29:53.000000000 +0900
> @@ -18,7 +18,6 @@
>   * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
>   */
>  #include <linux/irq.h>
> -#include <linux/irqchip.h>
>  #include <linux/kernel.h>
>  #include <linux/of_platform.h>
>  #include <linux/platform_data/irq-renesas-irqc.h>
> @@ -224,7 +223,6 @@ static const char *r8a73a4_boards_compat
>  
>  DT_MACHINE_START(R8A73A4_DT, "Generic R8A73A4 (Flattened Device Tree)")
>  	.init_early	= r8a73a4_init_delay,
> -	.init_irq	= irqchip_init,
>  	.init_machine	= r8a73a4_add_standard_devices_dt,
>  	.init_time	= shmobile_timer_init,
>  	.dt_compat	= r8a73a4_boards_compat_dt,

Hi Magnus,

as per my remark about the emev2, I accidently dropped a patch
from Maxime Ripard which corresponds to the setup-r8a73a4.c portion of
your above patch. Accordingly I have re-queued up Maxime's patch for v3.12
and applied the board-ape6evm.c portion of your patch as follows.
I have altered the title, partially so it uses the same scheme
used by Maxime's patches and partially to reflect that it
now only covers the ape6evm board.

The result will be in the cleanup branch the next time that I push my tree,
most likely later this afternoon.

commit eec81df7727a23e0da6a46b63aec1210fba884cf
Author: Magnus Damm <damm at opensource.se>
Date:   Mon Jul 1 15:01:21 2013 +0900

    ARM: shmobile: ape6evm: Remove init_irq declaration in machine description
    
    Remove redundant irqchip_init() callback. The default case
    of NULL will result in invoking irqchip_init() anyway.
    
    Signed-off-by: Magnus Damm <damm at opensource.se>
    [ horms+renesas at verge.net.au: Trimmed patch to remove portion
      that updates the r8a73a4 SoC and altered the subject to
      use the same format as the patch that updates the r8a73a4. ]
    Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
index 5eb0caa..1fbc39a 100644
--- a/arch/arm/mach-shmobile/board-ape6evm.c
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -20,7 +20,6 @@
 
 #include <linux/gpio.h>
 #include <linux/interrupt.h>
-#include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/platform_device.h>
@@ -102,7 +101,6 @@ static const char *ape6evm_boards_compat_dt[] __initdata = {
 };
 
 DT_MACHINE_START(APE6EVM_DT, "ape6evm")
-	.init_irq	= irqchip_init,
 	.init_time	= shmobile_timer_init,
 	.init_machine	= ape6evm_add_standard_devices,
 	.dt_compat	= ape6evm_boards_compat_dt,




From magnus.damm at gmail.com  Mon Jul  1 03:48:53 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 1 Jul 2013 16:48:53 +0900
Subject: [PATCH 01/04] ARM: shmobile: Use default ->init_irq() on EMEV2
In-Reply-To: <20130701073237.GU14567@verge.net.au>
References: <20130701060103.21728.83833.sendpatchset@w520>
 <20130701060112.21728.37189.sendpatchset@w520>
 <20130701073237.GU14567@verge.net.au>
Message-ID: <CANqRtoSJ=Vmvz9OdJQzgMZ8y2qyVUh3PivXhUVVGaxaurZNu2Q@mail.gmail.com>

Hi Simon, Maxime, everyone,

On Mon, Jul 1, 2013 at 4:32 PM, Simon Horman <horms at verge.net.au> wrote:
> On Mon, Jul 01, 2013 at 03:01:12PM +0900, Magnus Damm wrote:
>> From: Magnus Damm <damm at opensource.se>
>>
>> Remove redundant irqchip_init() callback. The default case
>> of NULL will result in invoking irqchip_init() anyway.
>>
>> Signed-off-by: Magnus Damm <damm at opensource.se>
>> ---
>>
>>  arch/arm/mach-shmobile/setup-emev2.c |    2 --
>>  1 file changed, 2 deletions(-)
>>
>> --- 0005/arch/arm/mach-shmobile/setup-emev2.c
>> +++ work/arch/arm/mach-shmobile/setup-emev2.c 2013-07-01 13:33:39.000000000 +0900
>> @@ -20,7 +20,6 @@
>>  #include <linux/init.h>
>>  #include <linux/interrupt.h>
>>  #include <linux/irq.h>
>> -#include <linux/irqchip.h>
>>  #include <linux/platform_device.h>
>>  #include <linux/platform_data/gpio-em.h>
>>  #include <linux/of_platform.h>
>> @@ -445,7 +444,6 @@ DT_MACHINE_START(EMEV2_DT, "Generic Emma
>>       .smp            = smp_ops(emev2_smp_ops),
>>       .init_early     = emev2_init_delay,
>>       .nr_irqs        = NR_IRQS_LEGACY,
>> -     .init_irq       = irqchip_init,
>>       .dt_compat      = emev2_boards_compat_dt,
>>  MACHINE_END
>
> Hi Magnus,
>
> I mistakenly dropped the following patch from Maxime Ripard from
> v3.11. I have re-queued it up, for v3.12, in the cleanup branch:
>
> commit 4042de1229ecf083890d8ad5c9327e03b648c1a2
> Author: Maxime Ripard <maxime.ripard at free-electrons.com>
> Date:   Sun May 26 22:05:23 2013 +0900
>
>     ARM: shmobile: emev2: Remove init_irq declaration in machine description

Thanks for going through earlier submitted patches and picking them
up. Of course I welcome the contribution by Maxime so please use his
code over mine wherever possible.

Cheers,

/ magnus


From bigeasy at linutronix.de  Mon Jul  1 03:48:43 2013
From: bigeasy at linutronix.de (Sebastian Andrzej Siewior)
Date: Mon, 01 Jul 2013 09:48:43 +0200
Subject: [PATCH] of: Specify initrd location using 64-bit
In-Reply-To: <51CE1F92.3070802@ti.com>
References: <1371775956-16453-1-git-send-email-santosh.shilimkar@ti.com>
 <51C4171C.9050908@linutronix.de> <51C48B5A.2040404@ti.com>
 <51CCA67C.2010803@gmail.com>
 <CACxGe6vOH0sCFVVXrYqD3dbYdOvithVu7-d1cvy5885i8x_Myw@mail.gmail.com>
 <20130628134931.GD21034@game.jcrosoft.org> <51CE1F92.3070802@ti.com>
Message-ID: <51D1345B.8020509@linutronix.de>

On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
> 
> Sebastian,
> 
> Apart from waste of 32bit, what is the other concern you
> have ?

You pass a u64 as a physical address which is represented in other
parts of the kernel (for a good reason) by phys_addr_t.

> I really want to converge on this patch because it
> has been a open ended discussion for quite some time. Does
> that really break any thing on x86 or your concern is more
> from semantics of the physical address.
You want to have your code in so you can continue with your work, that
is okay. The other two arguments why u64 here is a good thing was "due
to what I said earlier" and "+1" and I don't have the time to look
that up.

There should be no problems on x86 if this goes in as it is now.

But think about this: What happens if you boot your ARM device without
PAE and your initrd is in the upper region? If you are lucky the kernel
looks at a different place where it also has a read permission, notices
nothing sane is there, writes a message and continues. And if it is not
allowed to read? It is clearly the user's fault for booting a non-PAE
kernel.

> 
> Thanks for help.
> 
> Regards,
> Santosh

Sebastian


From shc_work at mail.ru  Mon Jul  1 03:51:01 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Mon, 01 Jul 2013 11:51:01 +0400
Subject: =?UTF-8?B?UmU6IFtQQVRDSCAzLzRdIFBDSTogQWRkIGRyaXZlciBmb3IgaS5NWDYgUENJ?=
 =?UTF-8?B?IEV4cHJlc3M=?=
In-Reply-To: <1372662947-27160-4-git-send-email-xobs@kosagi.com>
References: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
 <1372662947-27160-4-git-send-email-xobs@kosagi.com>
Message-ID: <1372665061.36667486@f35.mail.ru>

> This adds a PCI Express port driver for the on-chip PCI Express port
> present on the i.MX6 SoC.  It is based on the PCI Express driver available
> in the Freescale BSP.
> 
> Signed-off-by: Sean Cross <xobs at kosagi.com>
...
> +++ b/Documentation/devicetree/bindings/pci/imx6q-pcie.txt
> @@ -0,0 +1,20 @@
> +* Freescale i.MX6Q PCI Express bridge
> +
> +Example (i.MX6Q)
> +	pcie: pcie at 01ffc000 {
> +		compatible = "fsl,imx6q-pcie";
> +		reg = <0x01ffc000 0x4000>,
> +		      <0x01000000 0x100000>,
> +		      <0x01100000 0xe00000>,
> +		      <0x01f00000 0xfc000>;
> +		interrupts = <0 122 0x04>;
> +		clocks = <&clks 186>, <&clks 189>, <&clks 196>,
> +			 <&clks 198>, <&clks 144>;
> +		clock-names = "sata_ref", "pcie_ref_125m", "lvds1_sel",
> +			      "lvds1", "pcie_axi";
> +		power-enable = <&gpio7 12 0>;
> +		pcie-reset = <&gpio3 29 0>;

Can this be replaced with regulator/reset API?

> +		wake-up = <&gpio3 22 0>;
> +		disable-endpoint = <&gpio2 16 0>;
> +	};

---

From horms at verge.net.au  Mon Jul  1 03:52:09 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 1 Jul 2013 16:52:09 +0900
Subject: [PATCH 03/04] ARM: shmobile: Use default ->init_irq() on r8a7790
In-Reply-To: <20130701060131.21728.85765.sendpatchset@w520>
References: <20130701060103.21728.83833.sendpatchset@w520>
 <20130701060131.21728.85765.sendpatchset@w520>
Message-ID: <20130701075208.GW14567@verge.net.au>

On Mon, Jul 01, 2013 at 03:01:31PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Remove redundant irqchip_init() callback. The default case
> of NULL will result in invoking irqchip_init() anyway.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  arch/arm/mach-shmobile/board-lager.c   |    2 --
>  arch/arm/mach-shmobile/setup-r8a7790.c |    2 --
>  2 files changed, 4 deletions(-)
> 
> --- 0001/arch/arm/mach-shmobile/board-lager.c
> +++ work/arch/arm/mach-shmobile/board-lager.c	2013-07-01 13:27:30.000000000 +0900
> @@ -22,7 +22,6 @@
>  #include <linux/gpio_keys.h>
>  #include <linux/input.h>
>  #include <linux/interrupt.h>
> -#include <linux/irqchip.h>
>  #include <linux/kernel.h>
>  #include <linux/leds.h>
>  #include <linux/pinctrl/machine.h>
> @@ -104,7 +103,6 @@ static const char *lager_boards_compat_d
>  
>  DT_MACHINE_START(LAGER_DT, "lager")
>  	.init_early	= r8a7790_init_delay,
> -	.init_irq	= irqchip_init,
>  	.init_time	= r8a7790_timer_init,
>  	.init_machine	= lager_add_standard_devices,
>  	.dt_compat	= lager_boards_compat_dt,
> --- 0008/arch/arm/mach-shmobile/setup-r8a7790.c
> +++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-07-01 13:27:52.000000000 +0900
> @@ -19,7 +19,6 @@
>   */
>  
>  #include <linux/irq.h>
> -#include <linux/irqchip.h>
>  #include <linux/kernel.h>
>  #include <linux/of_platform.h>
>  #include <linux/platform_data/gpio-rcar.h>
> @@ -225,7 +224,6 @@ static const char *r8a7790_boards_compat
>  
>  DT_MACHINE_START(R8A7790_DT, "Generic R8A7790 (Flattened Device Tree)")
>  	.init_early	= r8a7790_init_delay,
> -	.init_irq	= irqchip_init,
>  	.init_time	= r8a7790_timer_init,
>  	.dt_compat	= r8a7790_boards_compat_dt,
>  MACHINE_END

Hi Magnus,

as per my remark about the emev2, I accidently dropped a patch
from Maxime Ripard which corresponds to the setup-r8a7790.c portion of
your above patch. Accordingly I have re-queued up Maxime's patch for v3.12
and applied the board-lager.c portion of your patch as follows.
I have altered the title, partially so it uses the same scheme
used by Maxime's patches and partially to reflect that it
now only covers the lager board.

The result will be in the cleanup branch the next time that I push my tree,
most likely later this afternoon.

commit 4a94ed71a7b3e17c46a23b89039cfa113fbfaa43
Author: Magnus Damm <damm at opensource.se>
Date:   Mon Jul 1 15:01:31 2013 +0900

    ARM: shmobile: lager: Remove init_irq declaration in machine description
    
    Remove redundant irqchip_init() callback. The default case
    of NULL will result in invoking irqchip_init() anyway.
    
    Signed-off-by: Magnus Damm <damm at opensource.se>
    [ horms+renesas at verge.net.au: Trimmed patch to remove portion
      that updates the r8a7790 SoC and altered the subject to
      use the same format as the patch that updates the r8a7790. ]
    Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index d73e21d..1e99b17 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -22,7 +22,6 @@
 #include <linux/gpio_keys.h>
 #include <linux/input.h>
 #include <linux/interrupt.h>
-#include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/leds.h>
 #include <linux/pinctrl/machine.h>
@@ -103,7 +102,6 @@ static const char *lager_boards_compat_dt[] __initdata = {
 };
 
 DT_MACHINE_START(LAGER_DT, "lager")
-	.init_irq	= irqchip_init,
 	.init_time	= r8a7790_timer_init,
 	.init_machine	= lager_add_standard_devices,
 	.dt_compat	= lager_boards_compat_dt,


From magnus.damm at gmail.com  Mon Jul  1 03:55:24 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 1 Jul 2013 16:55:24 +0900
Subject: [PATCH] ARM: shmobile: r8a73a4: Fix resources for SCIFB0
In-Reply-To: <51D1320D.4010709@igel.co.jp>
References: <51D1320D.4010709@igel.co.jp>
Message-ID: <CANqRtoSq12g-+CC9g9Kz2VpXhGKd=s_ZyHpJ2KDwgV1Lh5t41g@mail.gmail.com>

Hi Hayama-san,

On Mon, Jul 1, 2013 at 4:38 PM, Takanari Hayama <taki at igel.co.jp> wrote:
> From: Takanari Hayama <taki at igel.co.jp>
>
> Fix base address and IRQ resources associated with SCIFB0.
>
> Signed-off-by: Takanari Hayama <taki at igel.co.jp>
> ---
>  arch/arm/mach-shmobile/setup-r8a73a4.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c
> b/arch/arm/mach-shmobile/setup-r8a73a4.c
> index c5a75a7..7f45c2e 100644
> --- a/arch/arm/mach-shmobile/setup-r8a73a4.c
> +++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
> @@ -62,7 +62,7 @@ enum { SCIFA0, SCIFA1, SCIFB0, SCIFB1, SCIFB2, SCIFB3 };
>  static const struct plat_sci_port scif[] = {
>         SCIFA_DATA(SCIFA0, 0xe6c40000, gic_spi(144)), /* SCIFA0 */
>         SCIFA_DATA(SCIFA1, 0xe6c50000, gic_spi(145)), /* SCIFA1 */
> -       SCIFB_DATA(SCIFB0, 0xe6c50000, gic_spi(145)), /* SCIFB0 */
> +       SCIFB_DATA(SCIFB0, 0xe6c20000, gic_spi(148)), /* SCIFB0 */
>         SCIFB_DATA(SCIFB1, 0xe6c30000, gic_spi(149)), /* SCIFB1 */
>         SCIFB_DATA(SCIFB2, 0xe6ce0000, gic_spi(150)), /* SCIFB2 */
>         SCIFB_DATA(SCIFB3, 0xe6cf0000, gic_spi(151)), /* SCIFB3 */
> --
> 1.8.0

Thanks for catching this and submitting a fix. I've verified the
proposed change using the APE6 rev0.7 hardware manual and it looks
good to me.

Acked-by: Magnus Damm <damm at opensource.se>


From horms at verge.net.au  Mon Jul  1 03:55:44 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 1 Jul 2013 16:55:44 +0900
Subject: [PATCH 04/04] ARM: shmobile: Use default ->init_irq() on sh73a0
In-Reply-To: <20130701060140.21728.27213.sendpatchset@w520>
References: <20130701060103.21728.83833.sendpatchset@w520>
 <20130701060140.21728.27213.sendpatchset@w520>
Message-ID: <20130701075543.GX14567@verge.net.au>

On Mon, Jul 01, 2013 at 03:01:40PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Remove redundant irqchip_init() callback. The default case
> of NULL will result in invoking irqchip_init() anyway.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  arch/arm/mach-shmobile/board-kzm9g-reference.c |    2 --
>  arch/arm/mach-shmobile/setup-sh73a0.c          |    2 --
>  2 files changed, 4 deletions(-)
> 
> --- 0001/arch/arm/mach-shmobile/board-kzm9g-reference.c
> +++ work/arch/arm/mach-shmobile/board-kzm9g-reference.c	2013-06-28 16:04:39.000000000 +0900
> @@ -24,7 +24,6 @@
>  #include <linux/gpio.h>
>  #include <linux/io.h>
>  #include <linux/irq.h>
> -#include <linux/irqchip.h>
>  #include <linux/input.h>
>  #include <linux/of_platform.h>
>  #include <linux/pinctrl/machine.h>
> @@ -99,7 +98,6 @@ DT_MACHINE_START(KZM9G_DT, "kzm9g-refere
>  	.map_io		= sh73a0_map_io,
>  	.init_early	= sh73a0_init_delay,
>  	.nr_irqs	= NR_IRQS_LEGACY,
> -	.init_irq	= irqchip_init,
>  	.init_machine	= kzm_init,
>  	.init_time	= shmobile_timer_init,
>  	.dt_compat	= kzm9g_boards_compat_dt,
> --- 0007/arch/arm/mach-shmobile/setup-sh73a0.c
> +++ work/arch/arm/mach-shmobile/setup-sh73a0.c	2013-06-28 16:04:47.000000000 +0900
> @@ -22,7 +22,6 @@
>  #include <linux/init.h>
>  #include <linux/interrupt.h>
>  #include <linux/irq.h>
> -#include <linux/irqchip.h>
>  #include <linux/platform_device.h>
>  #include <linux/of_platform.h>
>  #include <linux/delay.h>
> @@ -983,7 +982,6 @@ DT_MACHINE_START(SH73A0_DT, "Generic SH7
>  	.map_io		= sh73a0_map_io,
>  	.init_early	= sh73a0_init_delay,
>  	.nr_irqs	= NR_IRQS_LEGACY,
> -	.init_irq	= irqchip_init,
>  	.init_machine	= sh73a0_add_standard_devices_dt,
>  	.dt_compat	= sh73a0_boards_compat_dt,
>  MACHINE_END

Hi Magnus,

as per my remark about the emev2, I accidently dropped a patch
from Maxime Ripard which corresponds to the setup-sh73a0.c portion of
your above patch. Accordingly I have re-queued up Maxime's patch for v3.12
and applied the board-kzm9g-reference.c portion of your patch as follows.
I have altered the title, partially so it uses the same scheme
used by Maxime's patches and partially to reflect that it
now only covers the kzm9g board.

The result will be in the cleanup branch the next time that I push my tree,
most likely later this afternoon.

commit 083c11c998f17c3ef4f2fc066424d6762254344b
Author: Magnus Damm <damm at opensource.se>
Date:   Mon Jul 1 15:01:40 2013 +0900

    ARM: shmobile: kzm9g: Remove init_irq declaration in machine description
    
    Remove redundant irqchip_init() callback. The default case
    of NULL will result in invoking irqchip_init() anyway.
    
    Signed-off-by: Magnus Damm <damm at opensource.se>
    [ horms+renesas at verge.net.au: Trimmed patch to remove portion
      that updates the sh73a0 SoC and altered the subject to
      use the same format as the patch that updates the sh73a0. ]
    Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index 44055fe..41092bb 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -24,7 +24,6 @@
 #include <linux/gpio.h>
 #include <linux/io.h>
 #include <linux/irq.h>
-#include <linux/irqchip.h>
 #include <linux/input.h>
 #include <linux/of_platform.h>
 #include <linux/pinctrl/machine.h>
@@ -99,7 +98,6 @@ DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
 	.map_io		= sh73a0_map_io,
 	.init_early	= sh73a0_init_delay,
 	.nr_irqs	= NR_IRQS_LEGACY,
-	.init_irq	= irqchip_init,
 	.init_machine	= kzm_init,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= kzm9g_boards_compat_dt,


From geert at linux-m68k.org  Mon Jul  1 03:59:33 2013
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 1 Jul 2013 09:59:33 +0200
Subject: [PATCH] of: Specify initrd location using 64-bit
In-Reply-To: <51D1345B.8020509@linutronix.de>
References: <1371775956-16453-1-git-send-email-santosh.shilimkar@ti.com>
 <51C4171C.9050908@linutronix.de> <51C48B5A.2040404@ti.com>
 <51CCA67C.2010803@gmail.com>
 <CACxGe6vOH0sCFVVXrYqD3dbYdOvithVu7-d1cvy5885i8x_Myw@mail.gmail.com>
 <20130628134931.GD21034@game.jcrosoft.org>
 <51CE1F92.3070802@ti.com> <51D1345B.8020509@linutronix.de>
Message-ID: <CAMuHMdV6YM3-hASqjxkguEukZjnjK80gBjDNiabxjfQtC=c8ag@mail.gmail.com>

On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
<bigeasy at linutronix.de> wrote:
> On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
>> Apart from waste of 32bit, what is the other concern you
>> have ?
>
> You pass a u64 as a physical address which is represented in other
> parts of the kernel (for a good reason) by phys_addr_t.
>
>> I really want to converge on this patch because it
>> has been a open ended discussion for quite some time. Does
>> that really break any thing on x86 or your concern is more
>> from semantics of the physical address.
> You want to have your code in so you can continue with your work, that
> is okay. The other two arguments why u64 here is a good thing was "due
> to what I said earlier" and "+1" and I don't have the time to look
> that up.
>
> There should be no problems on x86 if this goes in as it is now.
>
> But think about this: What happens if you boot your ARM device without
> PAE and your initrd is in the upper region? If you are lucky the kernel
> looks at a different place where it also has a read permission, notices
> nothing sane is there, writes a message and continues. And if it is not
> allowed to read? It is clearly the user's fault for booting a non-PAE
> kernel.

That's actual the original reason: DT has it as 64 bit, and passes it to a
32 bit kernel when running in 32 bit mode without PAE.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From bigeasy at linutronix.de  Mon Jul  1 04:09:34 2013
From: bigeasy at linutronix.de (Sebastian Andrzej Siewior)
Date: Mon, 01 Jul 2013 10:09:34 +0200
Subject: [PATCH] of: Specify initrd location using 64-bit
In-Reply-To: <CAMuHMdV6YM3-hASqjxkguEukZjnjK80gBjDNiabxjfQtC=c8ag@mail.gmail.com>
References: <1371775956-16453-1-git-send-email-santosh.shilimkar@ti.com>
 <51C4171C.9050908@linutronix.de> <51C48B5A.2040404@ti.com>
 <51CCA67C.2010803@gmail.com>
 <CACxGe6vOH0sCFVVXrYqD3dbYdOvithVu7-d1cvy5885i8x_Myw@mail.gmail.com>
 <20130628134931.GD21034@game.jcrosoft.org> <51CE1F92.3070802@ti.com>
 <51D1345B.8020509@linutronix.de>
 <CAMuHMdV6YM3-hASqjxkguEukZjnjK80gBjDNiabxjfQtC=c8ag@mail.gmail.com>
Message-ID: <51D1393E.6060001@linutronix.de>

On 07/01/2013 09:59 AM, Geert Uytterhoeven wrote:
> That's actual the original reason: DT has it as 64 bit, and passes it to a
> 32 bit kernel when running in 32 bit mode without PAE.

And I think the DT code should check if the u64 fits in phys_addr_t and
if does not it should write an error message and act like no initrd was
specified (instead of passing "something" to the architecture).

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

Sebastian


From naresh.kamboju at linaro.org  Mon Jul  1 04:14:49 2013
From: naresh.kamboju at linaro.org (Naresh Kamboju)
Date: Mon, 1 Jul 2013 13:44:49 +0530
Subject: linux-next: panda build failed at
 arch/arm/mach-omap2/omap4-restart.c
In-Reply-To: <874ncluatb.fsf@linaro.org>
References: <CA+G9fYv_9EQUmpRNPUwioSwJVXnXJC5odEKiMd=vKHNWYRT8xw@mail.gmail.com>
 <CA+G9fYupw8Gi=5p2nKVJ9GqfhwBcTw7hyzGA8+K+gHmdL96mJg@mail.gmail.com>
 <874ncluatb.fsf@linaro.org>
Message-ID: <CA+G9fYtYV6htwVP9aTM+Pc0jFyowDoTdiykxF0cY8RAwcpmKVQ@mail.gmail.com>

Hi Kevin,

On 26 June 2013 03:12, Kevin Hilman <khilman at linaro.org> wrote:
> Naresh Kamboju <naresh.kamboju at linaro.org> writes:
>
>> ping
>
> This is a known issue[1] and already has some proposed fixes, they are just
> not merged yet.
>
> Kevin
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/178209.html
>

Now the panda builds are back to work on linux-next.
https://ci.linaro.org/jenkins/job/linux-next/
-Naresh Kamboju


From tglx at linutronix.de  Mon Jul  1 04:15:51 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 1 Jul 2013 10:15:51 +0200 (CEST)
Subject: [PATCHv2 4/8] clocksource: sun4i: Fix the next event code
In-Reply-To: <20130629064815.GA2593@lukather>
References: <1372449386-1334-1-git-send-email-maxime.ripard@free-electrons.com>
 <1372449386-1334-5-git-send-email-maxime.ripard@free-electrons.com>
 <alpine.DEB.2.02.1306282204220.4013@ionos.tec.linutronix.de>
 <20130628210853.GB2756@lukather>
 <alpine.DEB.2.02.1306282322480.4013@ionos.tec.linutronix.de>
 <20130629064815.GA2593@lukather>
Message-ID: <alpine.DEB.2.02.1307011014430.4013@ionos.tec.linutronix.de>

On Sat, 29 Jun 2013, Maxime Ripard wrote:
> On Fri, Jun 28, 2013 at 11:27:25PM +0200, Thomas Gleixner wrote:
> > On Fri, 28 Jun 2013, Maxime Ripard wrote:
> > > On Fri, Jun 28, 2013 at 10:13:08PM +0200, Thomas Gleixner wrote:
> > > > On Fri, 28 Jun 2013, Maxime Ripard wrote:
> > > > > @@ -61,9 +62,14 @@ static void sun4i_clkevt_mode(enum clock_event_mode mode,
> > > > >  static int sun4i_clkevt_next_event(unsigned long evt,
> > > > >  				   struct clock_event_device *unused)
> > > > >  {
> > > > > -	u32 u = readl(timer_base + TIMER_CTL_REG(0));
> > > > > -	writel(evt, timer_base + TIMER_CNTVAL_REG(0));
> > > > > -	writel(u | TIMER_CTL_ENABLE | TIMER_CTL_AUTORELOAD,
> > > > > +	u32 val = readl(timer_base + TIMER_CTL_REG(0));
> > > > > +	writel(val & ~TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(0));
> > > > > +	udelay(1);
> > > > 
> > > > That udelay() is more than suspicious. Is there really no other way to
> > > > deal with that hardware?
> > > > 
> > > > If no, you really need to put a proper explanation for that into the code.
> > > 
> > > The datasheet states that you have to wait for two ticks of the timer
> > > clock source (in that case, 24MHz, which makes it around 80-85ns) before
> > > you can actually enable it back.
> > > 
> > > I didn't came up with a better solution.
> > 
> > 80-85ns is definitely way less than 1us.
> > 
> > Why not reading the counter register and wait for 2 or 3 cycles to
> > elapse instead of wasting a full microsecond evertime ?
> 
> Yes, but then we fall back to the discussion we had in the v1 about the
> latch needed to read the counter, which would already take more time
> than what we have to wait for.
> 
> Maybe we can use the second timer that we use for the clocksource
> though: it's always running, already set up, work at the same rate and
> we will only read it, so we won't change its monotonic nature.

Right. That will give you exact the information you need and make for
the shortest waiting time.

Thanks,

	tglx


From shawn.guo at linaro.org  Mon Jul  1 04:16:09 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 16:16:09 +0800
Subject: [PATCH 2/4] ASoC: sgtl5000: defer the probe if clock is not found
In-Reply-To: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1372666571-17276-3-git-send-email-shawn.guo@linaro.org>

It's not always the case that clock is already available when sgtl5000
get probed at the first time, e.g. the clock is provided by CPU DAI
which may be probed after sgtl5000.  So let's defer the probe when
devm_clk_get() call fails and give it chance to try later.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 sound/soc/codecs/sgtl5000.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
index 20bca03..1b7003c 100644
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -1527,7 +1527,8 @@ static int sgtl5000_i2c_probe(struct i2c_client *client,
 	if (IS_ERR(sgtl5000->mclk)) {
 		ret = PTR_ERR(sgtl5000->mclk);
 		dev_err(&client->dev, "Failed to get mclock: %d\n", ret);
-		return ret;
+		/* Defer the probe to see if the clk will be provided later */
+		return ret == -ENOENT ? -EPROBE_DEFER : ret;
 	}
 
 	ret = clk_prepare_enable(sgtl5000->mclk);
-- 
1.7.9.5




From shawn.guo at linaro.org  Mon Jul  1 04:16:11 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 16:16:11 +0800
Subject: [PATCH 4/4] ARM: mxs: saif0 is the clock provider to sgtl5000
In-Reply-To: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1372666571-17276-5-git-send-email-shawn.guo@linaro.org>

These systems all use saif0 as the mclock provider to codec sgtl5000.
Reflect that in device tree source, so that sgtl5000 can find the clock
by calling clk_get().

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx28-apx4devkit.dts |    2 +-
 arch/arm/boot/dts/imx28-evk.dts        |    2 +-
 arch/arm/boot/dts/imx28-m28evk.dts     |    2 +-
 arch/arm/boot/dts/imx28.dtsi           |    1 +
 4 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-apx4devkit.dts b/arch/arm/boot/dts/imx28-apx4devkit.dts
index 43bf3c7..0e7fed4 100644
--- a/arch/arm/boot/dts/imx28-apx4devkit.dts
+++ b/arch/arm/boot/dts/imx28-apx4devkit.dts
@@ -147,7 +147,7 @@
 					reg = <0x0a>;
 					VDDA-supply = <&reg_3p3v>;
 					VDDIO-supply = <&reg_3p3v>;
-
+					clocks = <&saif0>;
 				};
 
 				pcf8563: rtc at 51 {
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 3637bf3..dccb223 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -193,7 +193,7 @@
 					reg = <0x0a>;
 					VDDA-supply = <&reg_3p3v>;
 					VDDIO-supply = <&reg_3p3v>;
-
+					clocks = <&saif0>;
 				};
 
 				at24 at 51 {
diff --git a/arch/arm/boot/dts/imx28-m28evk.dts b/arch/arm/boot/dts/imx28-m28evk.dts
index 880df2f..44d9da5 100644
--- a/arch/arm/boot/dts/imx28-m28evk.dts
+++ b/arch/arm/boot/dts/imx28-m28evk.dts
@@ -184,7 +184,7 @@
 					reg = <0x0a>;
 					VDDA-supply = <&reg_3p3v>;
 					VDDIO-supply = <&reg_3p3v>;
-
+					clocks = <&saif0>;
 				};
 
 				eeprom: eeprom at 51 {
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 6a8acb0..9524a05 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -837,6 +837,7 @@
 				compatible = "fsl,imx28-saif";
 				reg = <0x80042000 0x2000>;
 				interrupts = <59 80>;
+				#clock-cells = <0>;
 				clocks = <&clks 53>;
 				dmas = <&dma_apbx 4>;
 				dma-names = "rx-tx";
-- 
1.7.9.5




From shawn.guo at linaro.org  Mon Jul  1 04:16:10 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 16:16:10 +0800
Subject: [PATCH 3/4] ASoC: mxs: register saif mclk to clock framework
In-Reply-To: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1372666571-17276-4-git-send-email-shawn.guo@linaro.org>

Mostly the mxs system design uses saif0 mclk output as the clock source
of codec.  Since the mclk is implemented as a general divider with the
saif clk as the parent clock, let's register the mclk as a basic
clk-divider to common clock framework.  Then with it being a clock
provdier, clk_get() call in codec driver probe function will just work.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 sound/soc/mxs/mxs-saif.c |   35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c
index 49d8700..54511c5 100644
--- a/sound/soc/mxs/mxs-saif.c
+++ b/sound/soc/mxs/mxs-saif.c
@@ -24,6 +24,7 @@
 #include <linux/slab.h>
 #include <linux/dma-mapping.h>
 #include <linux/clk.h>
+#include <linux/clk-provider.h>
 #include <linux/delay.h>
 #include <linux/time.h>
 #include <sound/core.h>
@@ -658,6 +659,33 @@ static irqreturn_t mxs_saif_irq(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static int mxs_saif_mclk_init(struct platform_device *pdev)
+{
+	struct mxs_saif *saif = platform_get_drvdata(pdev);
+	struct device_node *np = pdev->dev.of_node;
+	struct clk *clk;
+	int ret;
+
+	clk = clk_register_divider(&pdev->dev, "mxs_saif_mclk",
+				   __clk_get_name(saif->clk), 0,
+				   saif->base + SAIF_CTRL,
+				   BP_SAIF_CTRL_BITCLK_MULT_RATE, 3,
+				   0, NULL);
+	if (IS_ERR(clk)) {
+		ret = PTR_ERR(clk);
+		if (ret == -EEXIST)
+			return 0;
+		dev_err(&pdev->dev, "failed to register mclk: %d\n", ret);
+		return PTR_ERR(clk);
+	}
+
+	ret = of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
 static int mxs_saif_probe(struct platform_device *pdev)
 {
 	struct device_node *np = pdev->dev.of_node;
@@ -734,6 +762,13 @@ static int mxs_saif_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, saif);
 
+	/* We only support saif0 being tx and clock master */
+	if (saif->id == 0) {
+		ret = mxs_saif_mclk_init(pdev);
+		if (ret)
+			dev_warn(&pdev->dev, "failed to init clocks\n");
+	}
+
 	ret = snd_soc_register_component(&pdev->dev, &mxs_saif_component,
 					 &mxs_saif_dai, 1);
 	if (ret) {
-- 
1.7.9.5




From shawn.guo at linaro.org  Mon Jul  1 04:16:07 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 16:16:07 +0800
Subject: [PATCH 0/4] Fix mxs audio regressions
Message-ID: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>

The mxs audio got terribly broken during 3.11 development cycle due to
the following two commits.

  af8ee11 ASoC: sgtl5000: Fix driver probe after reset
  9e13f34 ASoC: sgtl5000: Let the codec acquire its clock

The series fixes the regressions and bring mxs audio back to work.

Mark,

Please consider to take the whole series as fixes through your tree
during 3.11-rc, so that we do not get a regression in the final v3.11
release.

Shawn

Shawn Guo (4):
  ASoC: sgtl5000: give it a ramping time before writting
  ASoC: sgtl5000: defer the probe if clock is not found
  ASoC: mxs: register saif mclk to clock framework
  ARM: mxs: saif0 is the clock provider to sgtl5000

 arch/arm/boot/dts/imx28-apx4devkit.dts |    2 +-
 arch/arm/boot/dts/imx28-evk.dts        |    2 +-
 arch/arm/boot/dts/imx28-m28evk.dts     |    2 +-
 arch/arm/boot/dts/imx28.dtsi           |    1 +
 sound/soc/codecs/sgtl5000.c            |   10 ++++++++-
 sound/soc/mxs/mxs-saif.c               |   35 ++++++++++++++++++++++++++++++++
 6 files changed, 48 insertions(+), 4 deletions(-)

-- 
1.7.9.5




From shawn.guo at linaro.org  Mon Jul  1 04:16:08 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 16:16:08 +0800
Subject: [PATCH 1/4] ASoC: sgtl5000: give it a ramping time before writting
In-Reply-To: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>

Since commit af8ee11 (ASoC: sgtl5000: Fix driver probe after reset),
it's very ofen to run into the following probe error on imx28. It is
caused by the regmap_write() failure in sgtl5000_fill_defaults().
However, the regmap_read() before this has already been working.  It
seems that sgtl5000 takes a longer ramping time to get the registers
ready for write than read.

[    1.991579] sgtl5000 0-000a: sgtl5000 revision 0x11
[    2.021655] mxs-sgtl5000 sound.12: ASoC: CODEC (null) not registered
[    2.039087] mxs-sgtl5000 sound.12: snd_soc_register_card failed (-517)
[    2.046299] platform sound.12: Driver mxs-sgtl5000 requests probe deferral

Fix the regression by giving it a ramping time before the first write.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 sound/soc/codecs/sgtl5000.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
index d441559..20bca03 100644
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -1552,6 +1552,13 @@ static int sgtl5000_i2c_probe(struct i2c_client *client,
 
 	i2c_set_clientdata(client, sgtl5000);
 
+	/*
+	 * It seems that sgtl5000 takes a longer time to get the registers
+	 * ready for write than bread.  Let's give it a ramping time before
+	 * the first write goes.
+	 */
+	msleep(50);
+
 	/* Ensure sgtl5000 will start with sane register values */
 	ret = sgtl5000_fill_defaults(sgtl5000);
 	if (ret)
-- 
1.7.9.5




From rogerq at ti.com  Mon Jul  1 04:16:45 2013
From: rogerq at ti.com (Roger Quadros)
Date: Mon, 1 Jul 2013 11:16:45 +0300
Subject: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during
 bus suspend
In-Reply-To: <Pine.LNX.4.44L0.1306281346430.1047-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1306281346430.1047-100000@iolanthe.rowland.org>
Message-ID: <51D13AED.4010307@ti.com>

On 06/28/2013 10:06 PM, Alan Stern wrote:
> On Fri, 28 Jun 2013, Roger Quadros wrote:
> 
>>> That's not what I meant.  Never mind the pinctrl; I was asking about
>>> the EHCI controller itself.  Under what circumstances does the
>>> controller assert its wakeup signal?  And how do you tell it to stop
>>> asserting that signal?
>>
>> I believe this would be through the EHCI Interrupt enable register (USBINTR).
>> I'm not aware of any other mechanism.
> 
> That's strange, because ehci_suspend() sets the intr_enable register to 
> 0.  So how do you ever get any wakeup interrupts at all?

Because after ehci_suspend() for OMAP, we solely rely on the out of band wake up
mechanism. i.e. Pad wakeup.
> 
>> Right. It seems the external hub has signaled remote wakeup but the kernel doesn't
>> resume the root hub's port it is connected to.
>>
>> By observing the detailed logs below you can see that the root hub does not generate
>> an INTerrupt transaction to notify the port status change event. I've captured the pstatus
>> and GetPortStatus info as well.
> 
> We don't need an interrupt.  The driver is supposed to detect the
> remote wakeup sent by the external hub all by itself.

OK. Then it could point to a bug in our stack.
> 
>> Failing case
>> ------------
>>
>> [   16.108032] usb usb1: usb auto-resume
>> [   16.108062] ehci-omap 48064800.ehci: resume root hub
>> [   16.108154] hub 1-0:1.0: hub_resume
>> [   16.108398] ehci_hub_control GetPortStatus, port 1 temp = 0x1000
>> [   16.108459] ehci_hub_control GetPortStatus, port 2 temp = 0x14c5
> 
> Here's where we should detect it.  Look at the GetPortStatus case in
> ehci_hub_control(); the PORT_RESUME bit (0x0040) is set in temp, so the
> "Remote Wakeup received?" code should run.  In particular, these lines
> should run:
> 
> 			/* resume signaling for 20 msec */
> 			ehci->reset_done[wIndex] = jiffies
> 					+ msecs_to_jiffies(20);
> 			usb_hcd_start_port_resume(&hcd->self, wIndex);
> 			/* check the port again */
> 			mod_timer(&ehci_to_hcd(ehci)->rh_timer,
> 					ehci->reset_done[wIndex]);
> 
> Therefore 20 ms later, around timestamp 16.128459,
> ehci_hub_status_data() should have been called.  At that time, the
> root-hub port should have been fully resumed.

OK. right.
> 
>> [   16.108551] hub 1-0:1.0: port 2: status 0507 change 0000
>> [   16.108612] ehci_hub_control GetPortStatus, port 3 temp = 0x1000
>> [   16.108642] hub 1-0:1.0: hub_activate submitting urb
>> [   16.109222] ehci_irq port 3 pstatus 0x1000
>> [   16.109222] ehci_irq port 2 pstatus 0x14c5
>> [   16.109252] ehci_irq port 1 pstatus 0x1000
>> [   16.109374] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> 
> But apparently nothing happened.  Why not?  Did the rh_timer get reset?  
> Maybe you can find out what went wrong.
> 

Sure. I'll investigate.

> (Hmmm, we seem to be missing a
> 
> 			set_bit(wIndex, &ehci->resuming_ports);
> 
> line in there...)
> 
>>> Also, why do you need omap->initialized?  Do you think you might get a 
>>> wakeup interrupt before the controller has been fully set up?  I don't 
>>> see how you could, given the pm_runtime_get_sync() call in the probe 
>>> routine.
>>>
>>
>> During probe we need to runtime_resume the device before usb_add_hcd() since the
>> controller clocks must be enabled before any registers are accessed.
>> However, we cannot call ehci_resume() before usb_add_hcd(). So to prevent this
>> chicken & egg situation, I've used the omap->initialized flag. It only indicates that
>> the ehci structures are initialized and we can call ehci_resume/suspend().
> 
> Ah, yes.  Other subsystems, such as PCI, face exactly the same problem.
> 
> You probably shouldn't call it "initialized", though, because the same
> issue arises in ehci_hcd_omap_remove() -- the pm_runtime_put_sync()  
> there would end up calling ehci_suspend() after usb_remove_hcd().  
> "bound" or "started" would be better names.
> 
OK. Started seems fine.

cheers,
-roger


From hdoyu at nvidia.com  Mon Jul  1 04:18:32 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Mon, 1 Jul 2013 10:18:32 +0200
Subject: [PATCH 03/23] ARM: dt: tegra30: iommu: Add "nvidia,memory-clients"
In-Reply-To: <1372244646.2986.17.camel@jlo-ubuntu-64.nvidia.com>
References: <20130626101028.GD27083@manwe><20130626.133314.1520719774895092173.hdoyu@nvidia.com><1372244646.2986.17.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <20130701.111832.2076981043593380845.hdoyu@nvidia.com>

Joseph Lo <josephl at nvidia.com> wrote @ Wed, 26 Jun 2013 13:04:06 +0200:

> On Wed, 2013-06-26 at 18:33 +0800, Hiroshi Doyu wrote:
> > Thierry Reding <thierry.reding at gmail.com> wrote @ Wed, 26 Jun 2013 12:10:30 +0200:
> > 
> > > * PGP Signed by an unknown key
> > > 
> > > On Wed, Jun 26, 2013 at 12:28:06PM +0300, Hiroshi Doyu wrote:
> > > > Add "nvidia,memory-clients" to identify which swgroup ID a device
> > > > belongs to.
> > > 
> > > Why not call the property "nvidia,swgid" instead? That seems a lot more
> > > intuitive.
> > 
> > Tegra powerdomain also needs this info. Joseph?
> 
> Ah, yes. We need some kind of this information to know the relation in
> the power domain when we wants to power down it.  But it didn't upstream
> yet and still in very early stage of the design. I believe you can
> ignore that and do the good design here for your usage. We can re-use
> the binding if it point to the same HW behind that.

Ok, at least, I'll move this "tegra-swgid.h" to under "include/dt-bindings/memory/".
This look to suite better than "include/dt-bindings/iommu/" since this
isn't specific to iommu but others needs from memory client POV.


From horms at verge.net.au  Mon Jul  1 04:23:05 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 1 Jul 2013 17:23:05 +0900
Subject: [PATCH] ARM: shmobile: r8a73a4: Fix resources for SCIFB0
In-Reply-To: <CANqRtoSq12g-+CC9g9Kz2VpXhGKd=s_ZyHpJ2KDwgV1Lh5t41g@mail.gmail.com>
References: <51D1320D.4010709@igel.co.jp>
 <CANqRtoSq12g-+CC9g9Kz2VpXhGKd=s_ZyHpJ2KDwgV1Lh5t41g@mail.gmail.com>
Message-ID: <20130701082304.GZ14567@verge.net.au>

On Mon, Jul 01, 2013 at 04:55:24PM +0900, Magnus Damm wrote:
> Hi Hayama-san,
> 
> On Mon, Jul 1, 2013 at 4:38 PM, Takanari Hayama <taki at igel.co.jp> wrote:
> > From: Takanari Hayama <taki at igel.co.jp>
> >
> > Fix base address and IRQ resources associated with SCIFB0.
> >
> > Signed-off-by: Takanari Hayama <taki at igel.co.jp>
> > ---
> >  arch/arm/mach-shmobile/setup-r8a73a4.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c
> > b/arch/arm/mach-shmobile/setup-r8a73a4.c
> > index c5a75a7..7f45c2e 100644
> > --- a/arch/arm/mach-shmobile/setup-r8a73a4.c
> > +++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
> > @@ -62,7 +62,7 @@ enum { SCIFA0, SCIFA1, SCIFB0, SCIFB1, SCIFB2, SCIFB3 };
> >  static const struct plat_sci_port scif[] = {
> >         SCIFA_DATA(SCIFA0, 0xe6c40000, gic_spi(144)), /* SCIFA0 */
> >         SCIFA_DATA(SCIFA1, 0xe6c50000, gic_spi(145)), /* SCIFA1 */
> > -       SCIFB_DATA(SCIFB0, 0xe6c50000, gic_spi(145)), /* SCIFB0 */
> > +       SCIFB_DATA(SCIFB0, 0xe6c20000, gic_spi(148)), /* SCIFB0 */
> >         SCIFB_DATA(SCIFB1, 0xe6c30000, gic_spi(149)), /* SCIFB1 */
> >         SCIFB_DATA(SCIFB2, 0xe6ce0000, gic_spi(150)), /* SCIFB2 */
> >         SCIFB_DATA(SCIFB3, 0xe6cf0000, gic_spi(151)), /* SCIFB3 */
> > --
> > 1.8.0
> 
> Thanks for catching this and submitting a fix. I've verified the
> proposed change using the APE6 rev0.7 hardware manual and it looks
> good to me.
> 
> Acked-by: Magnus Damm <damm at opensource.se>

Thanks, I will try and get this included in v3.11 as a fix
and then added to v3.10 stable.


From b32955 at freescale.com  Mon Jul  1 03:57:14 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 1 Jul 2013 15:57:14 +0800
Subject: [PATCH] ARM: dts: imx6: add #dma-cells property for sdma
Message-ID: <1372665434-2515-1-git-send-email-b32955@freescale.com>

Add the #dma-cells property for imx6 sdma.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6qdl.dtsi |    1 +
 arch/arm/boot/dts/imx6sl.dtsi  |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b381c85..ec5552b 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -581,6 +581,7 @@
 				interrupts = <0 2 0x04>;
 				clocks = <&clks 155>, <&clks 155>;
 				clock-names = "ipg", "ahb";
+				#dma-cells = <3>;
 				fsl,sdma-ram-script-name = "imx/sdma/sdma-imx6q.bin";
 			};
 		};
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index c5e5da0..9138c67 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -594,6 +594,7 @@
 				clocks = <&clks IMX6SL_CLK_SDMA>,
 					 <&clks IMX6SL_CLK_SDMA>;
 				clock-names = "ipg", "ahb";
+				#dma-cells = <3>;
 				fsl,sdma-ram-script-name = "imx/sdma/sdma-imx6sl.bin";
 			};
 
-- 
1.7.1




From hdoyu at nvidia.com  Mon Jul  1 04:24:46 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Mon, 1 Jul 2013 10:24:46 +0200
Subject: [PATCH 06/23] ARM: dt: tegra114: iommu: Add "nvidia,swgroups"
In-Reply-To: <20130626105216.GL27083@manwe>
References: <1372238906-9346-7-git-send-email-hdoyu@nvidia.com><20130626105216.GL27083@manwe>
Message-ID: <20130701.112446.119298599375396428.hdoyu@nvidia.com>

Thierry Reding <thierry.reding at gmail.com> wrote @ Wed, 26 Jun 2013 12:52:17 +0200:

> * PGP Signed by an unknown key
> 
> On Wed, Jun 26, 2013 at 12:28:09PM +0300, Hiroshi Doyu wrote:
> > This is a bitmap that indicates which HardWare Accelerators(HWA) are
> > supported on Tegra114 SoC.
> > 
> > Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
> > ---
> >  arch/arm/boot/dts/tegra114.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
> > index 1f45cf5..715b5d6 100644
> > --- a/arch/arm/boot/dts/tegra114.dtsi
> > +++ b/arch/arm/boot/dts/tegra114.dtsi
> > @@ -323,7 +323,7 @@
> >  		       0x70019228 0x074>;
> >  		nvidia,#asids = <4>;
> >  		dma-window = <0 0x40000000>;
> > -		nvidia,swgroups = <0x18659fe>;
> > +		nvidia,swgroups = <0x00000000 0x01b659fe>;
> >  		nvidia,ahb = <&ahb>;
> >  	};
> 
> It seems like an nvidia,tegra114-smmu.txt file is missing from the
> Documentation/devicetree/bindings/iommu directory.

All difference between T30 and T114 is now provided from DT. They have
all same entries but only those values are different.

Do we still need a copy of nvidia,tegra30-smmu.txt for t114 or is just
tweaking nvidia,tegra30-smmu.txt for t114 enough?


From shawn.guo at linaro.org  Mon Jul  1 04:32:14 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 16:32:14 +0800
Subject: [PATCH] ARM: imx_v6_v7_defconfig: Enable LVDS Display Bridge
In-Reply-To: <1372390087-7362-1-git-send-email-festevam@gmail.com>
References: <1372390087-7362-1-git-send-email-festevam@gmail.com>
Message-ID: <20130701083211.GA13206@S2101-09.ap.freescale.net>

On Fri, Jun 28, 2013 at 12:28:07AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Let IMX_LDB driver be built by default.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Applied, thanks.



From hdoyu at nvidia.com  Mon Jul  1 04:32:59 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Mon, 1 Jul 2013 10:32:59 +0200
Subject: [PATCH 19/23] iommu/tegra: smmu: Unfied driver for Tegra SoCs
In-Reply-To: <20130626110747.GP27083@manwe>
References: <1372238906-9346-20-git-send-email-hdoyu@nvidia.com><20130626110747.GP27083@manwe>
Message-ID: <20130701.113259.1041478084393668638.hdoyu@nvidia.com>

Thierry Reding <thierry.reding at gmail.com> wrote @ Wed, 26 Jun 2013 13:07:47 +0200:

> * PGP Signed by an unknown key
> 
> On Wed, Jun 26, 2013 at 12:28:22PM +0300, Hiroshi Doyu wrote:
> > Support multiple generation of Tegra SoCs with this unified
> > SMMU driver. Necessary info is expected to be passed from DT.
> > 
> > Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
> > ---
> >  drivers/iommu/tegra-smmu.c | 80 ++--------------------------------------------
> >  1 file changed, 3 insertions(+), 77 deletions(-)
> > 
> > diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> > index 6e82df3..ae71721 100644
> > --- a/drivers/iommu/tegra-smmu.c
> > +++ b/drivers/iommu/tegra-smmu.c
> > @@ -1,5 +1,5 @@
> >  /*
> > - * IOMMU API for SMMU in Tegra30
> > + * IOMMU API for SMMU in Tegra SoC
> 
> Maybe "Tegra30 and later SoCs" given that Tegra20 has no compatible
> IOMMU?
> 
> > -MODULE_DESCRIPTION("IOMMU API for SMMU in Tegra30");
> > +MODULE_DESCRIPTION("IOMMU API for SMMU in Tegra SoC");
> 
> Same here.

Currently most of Tegra SoC has SMMU, and which doesn't have can be
identified from DT. IMHO, we don't have to be so strict on this
decritpions. Otherwise, we would need to list up which one (doesn't)
has whenever a new one comes?


From rogerq at ti.com  Mon Jul  1 04:33:52 2013
From: rogerq at ti.com (Roger Quadros)
Date: Mon, 1 Jul 2013 11:33:52 +0300
Subject: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during
 bus suspend
In-Reply-To: <Pine.LNX.4.44L0.1306281507020.1047-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1306281507020.1047-100000@iolanthe.rowland.org>
Message-ID: <51D13EF0.6030702@ti.com>

On 06/28/2013 10:18 PM, Alan Stern wrote:
> On Fri, 28 Jun 2013, Roger Quadros wrote:
> 
>> Just found the problem. It seems that enabling the ehci_irq _after_ the root hub is resumed
>> is the root cause of the problem. Doing so will miss events from the root hub.
> 
> This sounds like a bug in the IRQ setup.  It's the sort of thing you 
> see when a level-triggered IRQ is treated as though it were 
> edge-triggered.
> 
> In any case, the wakeup should have worked whether the IRQ was issued 
> or not.
> 
OK.
> 
> I appreciate the symmetry of putting the enable_irq call in ehci-hcd, 
> seeing as how the disable_irq is there too.  On the other hand, every 
> HCD using this mechanism is going to have to do the same thing, which 
> argues for putting the enable call in the core.  Perhaps at the start 

OK.

> of hcd_resume_work() instead of the end.
> 

We can't enable_irq at the start as the controller will only be resumed
after usb_remote_wakeup().

cheers,
-roger


From shawn.guo at linaro.org  Mon Jul  1 04:37:48 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 16:37:48 +0800
Subject: [PATCH] ARM: dts: imx: remove the unused property
In-Reply-To: <1372410454-14628-1-git-send-email-b32955@freescale.com>
References: <1372410454-14628-1-git-send-email-b32955@freescale.com>
Message-ID: <20130701083746.GB13206@S2101-09.ap.freescale.net>

On Fri, Jun 28, 2013 at 05:07:34PM +0800, Huang Shijie wrote:
> The "fsl,gpmi-dma-channel" is not used any more, just remove it
> from all the dts file.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>

I already had a patch [1] to clean them up more globally.  And I'm
waiting for all existing users to move to new API. I see this can go
into 3.12.

Shawn

[1] http://www.spinics.net/lists/arm-kernel/msg227839.html



From b32955 at freescale.com  Mon Jul  1 04:42:48 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 1 Jul 2013 16:42:48 +0800
Subject: [PATCH] ARM: dts: imx: remove the unused property
In-Reply-To: <20130701083746.GB13206@S2101-09.ap.freescale.net>
References: <1372410454-14628-1-git-send-email-b32955@freescale.com>
 <20130701083746.GB13206@S2101-09.ap.freescale.net>
Message-ID: <51D14108.3090603@freescale.com>

? 2013?07?01? 16:37, Shawn Guo ??:
> I already had a patch [1] to clean them up more globally.  And I'm
ok. got it.

thanks
Huang Shijie



From richard.genoud at gmail.com  Mon Jul  1 04:39:25 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  1 Jul 2013 10:39:25 +0200
Subject: [RFC PATCH 00/13] audio support for at91sam9x5ek board
Message-ID: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>

Hi,

Here is some work I've done to make the sound work on sam9x5ek.
It's based on Nicolas Ferre's and Uwe Kleine-K?nig's work.
(Atmel patch on 2.6.39 if I recall)

I'd like to have some advice, mainly on the 1st patch
 "misc: atmel_ssc: add device tree DMA support".
I do not clearly see what is the right way to add DMA DT support for
this device, since it doesn't request a channel directly.


patches applies on next-20130701

[I let the original signed-off from Nicolas and Uwe in place, I don't
know if I should replace them by something like "originaly-signed-off-by"
since the code has been changed.]

Best regards,
Richard.


Nicolas Ferre (3):
  sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards
  sound: atmel_ssc_dai: PM: actually stopping clock on suspend/resume
  sound: wm8731: rework power management

Richard Genoud (10):
  misc: atmel_ssc: add device tree DMA support
  misc: atmel_ssc: keep the count of pdev->id
  ARM: at91: DTS: sam9x5: add clock for SSC DT entry
  ARM: at91: DTS: sam9x5: add SSC DMA parameters
  ARM: AT91: DTS: sam9x5ek: add WM8731 codec
  ARM: AT91: DTS: sam9x5ek: add sound configuration
  ARM: AT91: DTS: sam9x5ek: enable SSC
  sound: atmel-pcm: don't return ok if pcm-dma is not implemented
  sound: atmel-pcm-dma: check pointer before dereference
  sound: codec: wm8371: correct capture line/mic

 arch/arm/boot/dts/at91sam9x5.dtsi       |    3 +
 arch/arm/boot/dts/at91sam9x5ek.dtsi     |   27 ++++
 arch/arm/mach-at91/at91sam9x5.c         |    1 +
 drivers/misc/atmel-ssc.c                |   63 +++++++++
 include/linux/atmel-ssc.h               |    2 +
 include/linux/platform_data/dma-atmel.h |    2 +
 sound/soc/atmel/Kconfig                 |   12 ++
 sound/soc/atmel/Makefile                |    2 +
 sound/soc/atmel/atmel-pcm-dma.c         |    3 +
 sound/soc/atmel/atmel-pcm.h             |    2 +-
 sound/soc/atmel/atmel_ssc_dai.c         |   20 ++-
 sound/soc/atmel/sam9x5_wm8731.c         |  232 +++++++++++++++++++++++++++++++
 sound/soc/codecs/wm8731.c               |   10 +-
 13 files changed, 368 insertions(+), 11 deletions(-)
 create mode 100644 sound/soc/atmel/sam9x5_wm8731.c

-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  1 04:39:28 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  1 Jul 2013 10:39:28 +0200
Subject: [RFC PATCH 03/13] ARM: at91: DTS: sam9x5: add clock for SSC DT entry
In-Reply-To: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1372667978-4718-4-git-send-email-richard.genoud@gmail.com>

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/mach-at91/at91sam9x5.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
index 2abee66..191eb4b 100644
--- a/arch/arm/mach-at91/at91sam9x5.c
+++ b/arch/arm/mach-at91/at91sam9x5.c
@@ -233,6 +233,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
 	CLKDEV_CON_DEV_ID("mci_clk", "f000c000.mmc", &mmc1_clk),
 	CLKDEV_CON_DEV_ID("dma_clk", "ffffec00.dma-controller", &dma0_clk),
 	CLKDEV_CON_DEV_ID("dma_clk", "ffffee00.dma-controller", &dma1_clk),
+	CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", &ssc_clk),
 	CLKDEV_CON_DEV_ID("pclk", "f0010000.ssc", &ssc_clk),
 	CLKDEV_CON_DEV_ID(NULL, "f8010000.i2c", &twi0_clk),
 	CLKDEV_CON_DEV_ID(NULL, "f8014000.i2c", &twi1_clk),
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  1 04:39:27 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  1 Jul 2013 10:39:27 +0200
Subject: [RFC PATCH 02/13] misc: atmel_ssc: keep the count of pdev->id
In-Reply-To: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1372667978-4718-3-git-send-email-richard.genoud@gmail.com>

With device tree, pdev->id is always -1, so we introduce a local
counter.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 drivers/misc/atmel-ssc.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index 3afbd82..d1ec5ab 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -173,6 +173,12 @@ out:
 	return err;
 }
 
+/* counter of ssc devive instances.
+ * With device tree pdev->id is always -1, so we have to keep the
+ * count ourselves
+ */
+static int ssc_device_id;
+
 static int ssc_probe(struct platform_device *pdev)
 {
 	struct resource *regs;
@@ -235,6 +241,7 @@ static int ssc_probe(struct platform_device *pdev)
 	}
 
 	spin_lock(&user_lock);
+	pdev->id = ssc_device_id++;
 	list_add_tail(&ssc->list, &ssc_list);
 	spin_unlock(&user_lock);
 
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  1 04:39:26 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  1 Jul 2013 10:39:26 +0200
Subject: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
In-Reply-To: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1372667978-4718-2-git-send-email-richard.genoud@gmail.com>

The ssc device has to fill the at_dma_slave structure with the
device tree informations.
Doing a of_dma_request_slave_channel()+dma_release_channel() for that
seems wrong (or at least not very clean).

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 drivers/misc/atmel-ssc.c                |   56 +++++++++++++++++++++++++++++++
 include/linux/atmel-ssc.h               |    2 ++
 include/linux/platform_data/dma-atmel.h |    2 ++
 3 files changed, 60 insertions(+)

diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index f7b90661..3afbd82 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -19,7 +19,9 @@
 #include <linux/module.h>
 
 #include <linux/of.h>
+#include <linux/of_dma.h>
 #include <linux/pinctrl/consumer.h>
+#include <linux/platform_data/dma-atmel.h>
 
 /* Serialize access to ssc_list and user count */
 static DEFINE_SPINLOCK(user_lock);
@@ -127,12 +129,57 @@ static inline const struct atmel_ssc_platform_data * __init
 		platform_get_device_id(pdev)->driver_data;
 }
 
+static int atmel_ssc_get_dma_data(struct device_node *np,
+				  struct at_dma_slave *sdata)
+{
+	struct dma_chan *chan;
+	struct at_dma_slave *rx_data;
+	int err = -1;
+
+	/*
+	 * FIXME: this is clearly not the right way to do it.
+	 * In order to fill struct at_dma_slave with both rx and tx data,
+	 * we request and release both channels.
+	 * Et voila ! We've got all the whole structure !
+	 * upside: it works(R)
+	 * downside: feels wrong, dirty, not optimized...
+	 */
+	chan = of_dma_request_slave_channel(np, "tx");
+	if (!chan)
+		return err;
+
+	if (chan->private)
+		memcpy(sdata, chan->private, sizeof(*sdata));
+	else
+		goto out;
+
+	dma_release_channel(chan);
+
+	chan = of_dma_request_slave_channel(np, "rx");
+	if (!chan)
+		goto out;
+
+	if (chan->private) {
+		rx_data = chan->private;
+		sdata->cfg &= ~(ATC_SRC_PER_MSB(0xff) | ATC_SRC_PER(0xff));
+		sdata->cfg |= ATC_GET_SRC_ID(rx_data->cfg);
+		err = 0;
+	}
+
+out:
+	if (chan)
+		dma_release_channel(chan);
+
+	return err;
+}
+
 static int ssc_probe(struct platform_device *pdev)
 {
 	struct resource *regs;
 	struct ssc_device *ssc;
 	const struct atmel_ssc_platform_data *plat_dat;
 	struct pinctrl *pinctrl;
+	struct device_node *of = pdev->dev.of_node;
 
 	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
 	if (IS_ERR(pinctrl)) {
@@ -166,6 +213,15 @@ static int ssc_probe(struct platform_device *pdev)
 		return -ENXIO;
 	}
 
+	/* populate platform_data from device tree */
+	if (ssc->pdata && ssc->pdata->use_dma && of) {
+		if (atmel_ssc_get_dma_data(of, &ssc->pdata->dma_slave)) {
+			dev_err(&pdev->dev, "could not get DMA\n");
+			return -EINVAL;
+		}
+	}
+	ssc->pdev->dev.platform_data = &ssc->pdata->dma_slave;
+
 	/* disable all interrupts */
 	clk_prepare_enable(ssc->clk);
 	ssc_writel(ssc->regs, IDR, -1);
diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h
index deb0ae5..80c83ee 100644
--- a/include/linux/atmel-ssc.h
+++ b/include/linux/atmel-ssc.h
@@ -1,12 +1,14 @@
 #ifndef __INCLUDE_ATMEL_SSC_H
 #define __INCLUDE_ATMEL_SSC_H
 
+#include <linux/platform_data/dma-atmel.h>
 #include <linux/platform_device.h>
 #include <linux/list.h>
 #include <linux/io.h>
 
 struct atmel_ssc_platform_data {
 	int			use_dma;
+	struct at_dma_slave	dma_slave;
 };
 
 struct ssc_device {
diff --git a/include/linux/platform_data/dma-atmel.h b/include/linux/platform_data/dma-atmel.h
index e95f19c..0d8b9d6 100644
--- a/include/linux/platform_data/dma-atmel.h
+++ b/include/linux/platform_data/dma-atmel.h
@@ -44,11 +44,13 @@ struct at_dma_slave {
 #define		ATC_SRC_H2SEL_SW	(0x0 <<  9)
 #define		ATC_SRC_H2SEL_HW	(0x1 <<  9)
 #define	ATC_SRC_PER_MSB(h)	(ATC_PER_MSB(h) << 10)	/* Channel src rq (most significant bits) */
+#define ATC_GET_SRC_ID(h) ((((h) >> 6) & 0x3U) | ((h) & 0xFU)) /* Retrieve channel src id */
 #define	ATC_DST_REP		(0x1 << 12)	/* Destination Replay Mod */
 #define	ATC_DST_H2SEL		(0x1 << 13)	/* Destination Handshaking Mod */
 #define		ATC_DST_H2SEL_SW	(0x0 << 13)
 #define		ATC_DST_H2SEL_HW	(0x1 << 13)
 #define	ATC_DST_PER_MSB(h)	(ATC_PER_MSB(h) << 14)	/* Channel dst rq (most significant bits) */
+#define ATC_GET_DST_ID(h) ((((h) >> 10) & 0x3U) | (((h) >> 4) & 0xFU)) /* Retrieve channel dst id */
 #define	ATC_SOD			(0x1 << 16)	/* Stop On Done */
 #define	ATC_LOCK_IF		(0x1 << 20)	/* Interface Lock */
 #define	ATC_LOCK_B		(0x1 << 21)	/* AHB Bus Lock */
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  1 04:39:29 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  1 Jul 2013 10:39:29 +0200
Subject: [RFC PATCH 04/13] ARM: at91: DTS: sam9x5: add SSC DMA parameters
In-Reply-To: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1372667978-4718-5-git-send-email-richard.genoud@gmail.com>

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5.dtsi |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 57d45f5..cf78ac0 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -542,6 +542,9 @@
 				compatible = "atmel,at91sam9g45-ssc";
 				reg = <0xf0010000 0x4000>;
 				interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
+				dmas = <&dma0 1 AT91_DMA_CFG_PER_ID(13)>,
+				       <&dma0 1 AT91_DMA_CFG_PER_ID(14)>;
+				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
 				status = "disabled";
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  1 04:39:30 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  1 Jul 2013 10:39:30 +0200
Subject: [RFC PATCH 05/13] ARM: AT91: DTS: sam9x5ek: add WM8731 codec
In-Reply-To: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1372667978-4718-6-git-send-email-richard.genoud@gmail.com>

The WM8731 codec on sam9x5ek board is on i2c, address 1A

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index b753855..a81a1a6 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -59,6 +59,11 @@
 
 			i2c0: i2c at f8010000 {
 				status = "okay";
+
+				wm8731: wm8731 at 1a {
+					compatible = "wm8731";
+					reg = <0x1a>;
+				};
 			};
 
 			pinctrl at fffff400 {
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  1 04:39:31 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  1 Jul 2013 10:39:31 +0200
Subject: [RFC PATCH 06/13] ARM: AT91: DTS: sam9x5ek: add sound configuration
In-Reply-To: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1372667978-4718-7-git-send-email-richard.genoud@gmail.com>

The sam9x5ek board has 2 jacks:
headphone wired on RHPOUT/LHPOUT of the wm8731
line in wired on LLINEIN/RLINEIN of the wm8731

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index a81a1a6..77e4073 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -109,4 +109,22 @@
 			status = "okay";
 		};
 	};
+
+	sound {
+		compatible = "atmel,sam9x5-audio-wm8731";
+
+		atmel,model = "wm8731 @ AT91SAM9X5EK";
+
+		atmel,audio-routing =
+			"Headphone Jack", "RHPOUT",
+			"Headphone Jack", "LHPOUT",
+			"LLINEIN", "Line In Jack",
+			"RLINEIN", "Line In Jack";
+
+		atmel,ssc-controller = <&ssc0>;
+		atmel,audio-codec = <&wm8731>;
+		atmel,format = "i2s";
+		atmel,bitclock-master;
+		atmel,frame-master;
+	};
 };
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  1 04:39:32 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  1 Jul 2013 10:39:32 +0200
Subject: [RFC PATCH 07/13] ARM: AT91: DTS: sam9x5ek: enable SSC
In-Reply-To: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1372667978-4718-8-git-send-email-richard.genoud@gmail.com>

Enable the SSC needed for the WM8731 codec

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index 77e4073..4f3584c 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -95,6 +95,10 @@
 			watchdog at fffffe40 {
 				status = "okay";
 			};
+
+			ssc0: ssc at f0010000 {
+				status = "okay";
+			};
 		};
 
 		usb0: ohci at 00600000 {
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  1 04:39:33 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  1 Jul 2013 10:39:33 +0200
Subject: [RFC PATCH 08/13] sound: sam9x5_wm8731: machine driver for at91sam9x5
 wm8731 boards
In-Reply-To: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1372667978-4718-9-git-send-email-richard.genoud@gmail.com>

From: Nicolas Ferre <nicolas.ferre at atmel.com>

Description of the Asoc machine driver for an at91sam9x5 based board
with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
master on the SSC/I2S interface. Its connections are a headphone jack
and an Line input jack.

[Richard: this is based on an old patch from Nicolas that I forward
ported and reworked to use only device tree]

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 sound/soc/atmel/Kconfig         |   12 ++
 sound/soc/atmel/Makefile        |    2 +
 sound/soc/atmel/sam9x5_wm8731.c |  232 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 246 insertions(+)
 create mode 100644 sound/soc/atmel/sam9x5_wm8731.c

diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 3fdd87f..f24d601 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -13,6 +13,7 @@ config SND_ATMEL_SOC_PDC
 config SND_ATMEL_SOC_DMA
 	tristate
 	depends on SND_ATMEL_SOC
+	select SND_SOC_DMAENGINE_PCM
 
 config SND_ATMEL_SOC_SSC
 	tristate
@@ -32,6 +33,17 @@ config SND_AT91_SOC_SAM9G20_WM8731
 	  Say Y if you want to add support for SoC audio on WM8731-based
 	  AT91sam9g20 evaluation board.
 
+config SND_AT91_SOC_SAM9X5_WM8731
+	tristate "SoC Audio support for WM8731-based at91sam9x5 board"
+	depends on ATMEL_SSC && SND_ATMEL_SOC && SOC_AT91SAM9X5
+	select SND_ATMEL_SOC_SSC
+	select SND_ATMEL_SOC_DMA
+	select SND_ATMEL_SOC_PDC
+	select SND_SOC_WM8731
+	help
+	  Say Y if you want to add support for audio SoC on an
+	  at91sam9x5 based board that is using WM8731 codec.
+
 config SND_AT91_SOC_AFEB9260
 	tristate "SoC Audio support for AFEB9260 board"
 	depends on ARCH_AT91 && ATMEL_SSC && ARCH_AT91 && MACH_AFEB9260 && SND_ATMEL_SOC
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index 41967cc..7784c09 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -11,6 +11,8 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
 
 # AT91 Machine Support
 snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
+snd-soc-sam9x5-wm8731-objs := sam9x5_wm8731.o
 
 obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
+obj-$(CONFIG_SND_AT91_SOC_SAM9X5_WM8731) += snd-soc-sam9x5-wm8731.o
 obj-$(CONFIG_SND_AT91_SOC_AFEB9260) += snd-soc-afeb9260.o
diff --git a/sound/soc/atmel/sam9x5_wm8731.c b/sound/soc/atmel/sam9x5_wm8731.c
new file mode 100644
index 0000000..83ca457
--- /dev/null
+++ b/sound/soc/atmel/sam9x5_wm8731.c
@@ -0,0 +1,232 @@
+/*
+ * sam9x5_wm8731   --	SoC audio for AT91SAM9X5-based boards
+ *			that are using WM8731 as codec.
+ *
+ *  Copyright (C) 2011 Atmel,
+ *		  Nicolas Ferre <nicolas.ferre at atmel.com>
+ *
+ * Based on sam9g20_wm8731.c by:
+ * Sedji Gaouaou <sedji.gaouaou at atmel.com>
+ *
+ * GPL
+ */
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/kernel.h>
+#include <linux/clk.h>
+#include <linux/timer.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/i2c.h>
+
+#include <linux/atmel-ssc.h>
+
+#include <sound/core.h>
+#include <sound/pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+
+#include <asm/mach-types.h>
+#include <mach/hardware.h>
+#include <mach/gpio.h>
+
+#include "../codecs/wm8731.h"
+#include "atmel-pcm.h"
+#include "atmel_ssc_dai.h"
+
+#define MCLK_RATE 12288000
+
+#define DRV_NAME "sam9x5-snd-wm8731"
+
+/*
+ * Audio paths on at91sam9x5ek board:
+ *
+ *  |A| ------------> |      | ---R----> Headphone Jack
+ *  |T| <----\        |  WM  | ---L--/
+ *  |9| ---> CLK <--> | 8751 | <--R----- Line In Jack
+ *  |1| <------------ |      | <--L--/
+ */
+static const struct snd_soc_dapm_widget at91sam9x5ek_dapm_widgets[] = {
+	SND_SOC_DAPM_HP("Headphone Jack", NULL),
+	SND_SOC_DAPM_LINE("Line In Jack", NULL),
+};
+
+/*
+ * Logic for a wm8731 as connected on a at91sam9x5 based board.
+ */
+static int at91sam9x5ek_wm8731_init(struct snd_soc_pcm_runtime *rtd)
+{
+	struct snd_soc_codec *codec = rtd->codec;
+	struct snd_soc_dai *codec_dai = rtd->codec_dai;
+	struct snd_soc_dapm_context *dapm = &codec->dapm;
+	struct device *dev = rtd->dev;
+	int ret;
+
+	dev_dbg(dev, "ASoC: at91sam9x5ek_wm8731_init() called\n");
+
+	/*
+	 * remove some not supported rates in relation with clock
+	 * provided to the wm8731 codec
+	 */
+	switch (MCLK_RATE) {
+	case 12288000:
+		codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 |
+						     SNDRV_PCM_RATE_32000 |
+						     SNDRV_PCM_RATE_48000 |
+						     SNDRV_PCM_RATE_96000;
+		codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 |
+						    SNDRV_PCM_RATE_32000 |
+						    SNDRV_PCM_RATE_48000 |
+						    SNDRV_PCM_RATE_96000;
+		break;
+	case 12000000:
+		/* all wm8731 rates supported */
+		break;
+	default:
+		dev_err(dev, "ASoC: Codec Master clock rate not defined\n");
+		return -EINVAL;
+	}
+
+	/* set not connected pins */
+	snd_soc_dapm_nc_pin(dapm, "Mic Bias");
+	snd_soc_dapm_nc_pin(dapm, "MICIN");
+	snd_soc_dapm_nc_pin(dapm, "LOUT");
+	snd_soc_dapm_nc_pin(dapm, "ROUT");
+
+	/* always connected */
+	snd_soc_dapm_enable_pin(dapm, "Headphone Jack");
+	snd_soc_dapm_enable_pin(dapm, "Line In Jack");
+
+	/* set the codec system clock for DAC and ADC */
+	ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
+				     MCLK_RATE, SND_SOC_CLOCK_IN);
+	if (ret < 0) {
+		dev_err(dev, "ASoC: Failed to set WM8731 SYSCLK: %d\n", ret);
+		return ret;
+	}
+
+	/* signal a DAPM event */
+	snd_soc_dapm_sync(dapm);
+	return 0;
+}
+
+static int sam9x5_wm8731_driver_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *codec_np, *cpu_np;
+	struct snd_soc_card *card;
+	struct snd_soc_dai_link *dai;
+	int ret;
+
+	if (!np) {
+		dev_err(&pdev->dev, "No device node supplied\n");
+		return -EINVAL;
+	}
+
+	ret = atmel_ssc_set_audio(0);
+	if (ret != 0) {
+		dev_err(&pdev->dev,
+			"ASoC: Failed to set SSC 0 for audio: %d\n", ret);
+		return ret;
+	}
+
+	card = devm_kzalloc(&pdev->dev, sizeof(*card), GFP_KERNEL);
+	dai = devm_kzalloc(&pdev->dev, sizeof(*dai), GFP_KERNEL);
+	if (!dai || !card) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	card->dev = &pdev->dev;
+	card->owner = THIS_MODULE;
+	card->dai_link = dai;
+	card->num_links = 1;
+	dai->name = "WM8731";
+	dai->stream_name = "WM8731 PCM";
+	dai->codec_dai_name = "wm8731-hifi";
+	dai->init = at91sam9x5ek_wm8731_init;
+	card->dapm_widgets = at91sam9x5ek_dapm_widgets;
+	card->num_dapm_widgets = ARRAY_SIZE(at91sam9x5ek_dapm_widgets);
+
+	ret = snd_soc_of_parse_card_name(card, "atmel,model");
+	if (ret)
+		goto out;
+
+	ret = snd_soc_of_parse_audio_routing(card, "atmel,audio-routing");
+	if (ret)
+		goto out;
+
+	codec_np = of_parse_phandle(np, "atmel,audio-codec", 0);
+	if (!codec_np) {
+		dev_err(&pdev->dev, "codec info missing\n");
+		ret = -EINVAL;
+		goto out;
+	}
+
+	dai->codec_of_node = codec_np;
+
+	cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
+	if (!cpu_np) {
+		dev_err(&pdev->dev, "ssc controller node missing\n");
+		ret = -EINVAL;
+		goto out;
+	}
+	dai->cpu_of_node = cpu_np;
+	dai->platform_of_node = cpu_np;
+
+	of_node_put(codec_np);
+	of_node_put(cpu_np);
+
+	dai->dai_fmt = snd_soc_of_parse_daifmt(np, "atmel,");
+
+	ret = snd_soc_register_card(card);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"ASoC: Platform device allocation failed\n");
+		goto out;
+	}
+
+	platform_set_drvdata(pdev, card);
+
+	dev_info(&pdev->dev, "ASoC: at91sam9x5ek_init ok\n");
+
+	return ret;
+
+out:
+	atmel_ssc_put_audio(0);
+	return ret;
+}
+
+static int sam9x5_wm8731_driver_remove(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = platform_get_drvdata(pdev);
+
+	snd_soc_unregister_card(card);
+	atmel_ssc_put_audio(0);
+
+	return 0;
+}
+
+static const struct of_device_id sam9x5_wm8731_of_match[] = {
+	{ .compatible = "atmel,sam9x5-audio-wm8731", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sam9x5_wm8731_of_match);
+
+static struct platform_driver sam9x5_wm8731_driver = {
+	.driver = {
+		.name = DRV_NAME,
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(sam9x5_wm8731_of_match),
+	},
+	.probe = sam9x5_wm8731_driver_probe,
+	.remove = sam9x5_wm8731_driver_remove,
+};
+module_platform_driver(sam9x5_wm8731_driver);
+
+/* Module information */
+MODULE_AUTHOR("Nicolas Ferre <nicolas.ferre at atmel.com>");
+MODULE_AUTHOR("Richard Genoud <richard.genoud at gmail.com>");
+MODULE_DESCRIPTION("ALSA SoC machine driver for AT91SAM9x5 - WM8731");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:" DRV_NAME);
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  1 04:39:34 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  1 Jul 2013 10:39:34 +0200
Subject: [RFC PATCH 09/13] sound: atmel-pcm: don't return ok if pcm-dma is not
 implemented
In-Reply-To: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1372667978-4718-10-git-send-email-richard.genoud@gmail.com>

If DMA is not selected, atmel_pcm_dma_platform_register() should fail.
Like that, the driver knows it can't use it.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 sound/soc/atmel/atmel-pcm.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/atmel/atmel-pcm.h b/sound/soc/atmel/atmel-pcm.h
index 12ae814..c0a01fa 100644
--- a/sound/soc/atmel/atmel-pcm.h
+++ b/sound/soc/atmel/atmel-pcm.h
@@ -109,7 +109,7 @@ void atmel_pcm_dma_platform_unregister(struct device *dev);
 #else
 static inline int atmel_pcm_dma_platform_register(struct device *dev)
 {
-	return 0;
+	return -1;
 }
 static inline void atmel_pcm_dma_platform_unregister(struct device *dev)
 {
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  1 04:39:35 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  1 Jul 2013 10:39:35 +0200
Subject: [RFC PATCH 10/13] sound: atmel_ssc_dai: PM: actually stopping clock
 on suspend/resume
In-Reply-To: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1372667978-4718-11-git-send-email-richard.genoud@gmail.com>

From: Nicolas Ferre <nicolas.ferre at atmel.com>

Stop SSC clock on suspend/resume cycle checking if the controller is actually
initialized. This will save power while sleeping.

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 sound/soc/atmel/atmel_ssc_dai.c |   20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index f3fdfa0..14da27a 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -659,12 +659,10 @@ static int atmel_ssc_prepare(struct snd_pcm_substream *substream,
 #ifdef CONFIG_PM
 static int atmel_ssc_suspend(struct snd_soc_dai *cpu_dai)
 {
-	struct atmel_ssc_info *ssc_p;
+	struct atmel_ssc_info *ssc_p = &ssc_info[cpu_dai->id];
 
 	if (!cpu_dai->active)
-		return 0;
-
-	ssc_p = &ssc_info[cpu_dai->id];
+		goto out;
 
 	/* Save the status register before disabling transmit and receive */
 	ssc_p->ssc_state.ssc_sr = ssc_readl(ssc_p->ssc->regs, SR);
@@ -680,6 +678,11 @@ static int atmel_ssc_suspend(struct snd_soc_dai *cpu_dai)
 	ssc_p->ssc_state.ssc_tcmr = ssc_readl(ssc_p->ssc->regs, TCMR);
 	ssc_p->ssc_state.ssc_tfmr = ssc_readl(ssc_p->ssc->regs, TFMR);
 
+out:
+	if (ssc_p->initialized) {
+		pr_debug("atmel_ssc_dai: suspend - stop clock\n");
+		clk_disable(ssc_p->ssc->clk);
+	}
 	return 0;
 }
 
@@ -687,14 +690,17 @@ static int atmel_ssc_suspend(struct snd_soc_dai *cpu_dai)
 
 static int atmel_ssc_resume(struct snd_soc_dai *cpu_dai)
 {
-	struct atmel_ssc_info *ssc_p;
+	struct atmel_ssc_info *ssc_p = &ssc_info[cpu_dai->id];
 	u32 cr;
 
+	if (ssc_p->initialized) {
+		pr_debug("atmel_ssc_dai: resume - restart clock\n");
+		clk_enable(ssc_p->ssc->clk);
+	}
+
 	if (!cpu_dai->active)
 		return 0;
 
-	ssc_p = &ssc_info[cpu_dai->id];
-
 	/* restore SSC register settings */
 	ssc_writel(ssc_p->ssc->regs, TFMR, ssc_p->ssc_state.ssc_tfmr);
 	ssc_writel(ssc_p->ssc->regs, TCMR, ssc_p->ssc_state.ssc_tcmr);
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  1 04:39:37 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  1 Jul 2013 10:39:37 +0200
Subject: [RFC PATCH 12/13] sound: wm8731: rework power management
In-Reply-To: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1372667978-4718-13-git-send-email-richard.genoud@gmail.com>

From: Nicolas Ferre <nicolas.ferre at atmel.com>

- preserve crystal oscillator across suspend/resume sequence:
  enabled by default,it should be kept enabled on resume.
- if codec is in active state: set the active bit at resume time.

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 sound/soc/codecs/wm8731.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm8731.c b/sound/soc/codecs/wm8731.c
index 5276062..3cf6b20 100644
--- a/sound/soc/codecs/wm8731.c
+++ b/sound/soc/codecs/wm8731.c
@@ -465,7 +465,9 @@ static int wm8731_set_bias_level(struct snd_soc_codec *codec,
 		snd_soc_write(codec, WM8731_PWR, reg | 0x0040);
 		break;
 	case SND_SOC_BIAS_OFF:
-		snd_soc_write(codec, WM8731_PWR, 0xffff);
+		snd_soc_write(codec, WM8731_ACTIVE, 0x0);
+		/* standby: keep crystal oscillator enabled */
+		snd_soc_write(codec, WM8731_PWR, 0x00df);
 		regulator_bulk_disable(ARRAY_SIZE(wm8731->supplies),
 				       wm8731->supplies);
 		regcache_mark_dirty(wm8731->regmap);
@@ -516,6 +518,8 @@ static int wm8731_suspend(struct snd_soc_codec *codec)
 static int wm8731_resume(struct snd_soc_codec *codec)
 {
 	wm8731_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
+	if (codec->active)
+		snd_soc_write(codec, WM8731_ACTIVE, 0x0001);
 
 	return 0;
 }
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  1 04:39:38 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  1 Jul 2013 10:39:38 +0200
Subject: [RFC PATCH 13/13] sound: codec: wm8371: correct capture line/mic
In-Reply-To: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1372667978-4718-14-git-send-email-richard.genoud@gmail.com>

With the "switch" text, we can't enable the line and mic capture in
alsamixer.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 sound/soc/codecs/wm8731.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/wm8731.c b/sound/soc/codecs/wm8731.c
index 3cf6b20..dae1403 100644
--- a/sound/soc/codecs/wm8731.c
+++ b/sound/soc/codecs/wm8731.c
@@ -164,10 +164,10 @@ SOC_DOUBLE_R("Master Playback ZC Switch", WM8731_LOUT1V, WM8731_ROUT1V,
 
 SOC_DOUBLE_R_TLV("Capture Volume", WM8731_LINVOL, WM8731_RINVOL, 0, 31, 0,
 		 in_tlv),
-SOC_DOUBLE_R("Line Capture Switch", WM8731_LINVOL, WM8731_RINVOL, 7, 1, 1),
+SOC_DOUBLE_R("Line Capture", WM8731_LINVOL, WM8731_RINVOL, 7, 1, 1),
 
 SOC_SINGLE_TLV("Mic Boost Volume", WM8731_APANA, 0, 1, 0, mic_tlv),
-SOC_SINGLE("Mic Capture Switch", WM8731_APANA, 1, 1, 1),
+SOC_SINGLE("Mic Capture", WM8731_APANA, 1, 1, 1),
 
 SOC_SINGLE_TLV("Sidetone Playback Volume", WM8731_APANA, 6, 3, 1,
 	       sidetone_tlv),
-- 
1.7.10.4



From shawn.guo at linaro.org  Mon Jul  1 04:43:25 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 16:43:25 +0800
Subject: [PATCH] ARM: dts: add sram for imx53 and imx6q
In-Reply-To: <1372416798-2828-1-git-send-email-p.zabel@pengutronix.de>
References: <1372416798-2828-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20130701084323.GC13206@S2101-09.ap.freescale.net>

On Fri, Jun 28, 2013 at 12:53:18PM +0200, Philipp Zabel wrote:
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> Reviewed-by: Shawn Guo <shawn.guo at linaro.org>
> ---
>  arch/arm/boot/dts/imx53.dtsi   | 5 +++++
>  arch/arm/boot/dts/imx6qdl.dtsi | 6 ++++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> index d437bfb..3def46f 100644
> --- a/arch/arm/boot/dts/imx53.dtsi
> +++ b/arch/arm/boot/dts/imx53.dtsi
> @@ -1087,5 +1087,10 @@
>  				status = "disabled";
>  			};
>  		};
> +
> +		ocram: ocram at f8000000 {
> +			compatible = "fsl,imx-ocram", "mmio-sram";

I think we agreed to drop this custom compatible "fsl,imx-ocram" for
now [1]?

Shawn

[1] http://thread.gmane.org/gmane.linux.kernel/1460369/focus=1465840

> +			reg = <0xf8000000 0x20000>;
> +		};
>  	};
>  };
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index 2d73f83..e1fe8a4 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -100,6 +100,12 @@
>  			status = "disabled";
>  		};
>  
> +		ocram: ocram at 00900000 {
> +			compatible = "fsl,imx-ocram", "mmio-sram";
> +			reg = <0x00900000 0x3f000>;
> +			clocks = <&clks 142>;
> +		};
> +
>  		timer at 00a00600 {
>  			compatible = "arm,cortex-a9-twd-timer";
>  			reg = <0x00a00600 0x20>;
> -- 
> 1.8.3.1
> 



From shawn.guo at linaro.org  Mon Jul  1 04:45:10 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 16:45:10 +0800
Subject: [PATCH 1/2] ARM i.MX6DL: parent LDB DI clocks to PLL5 on i.MX6S/DL
In-Reply-To: <1372422256-22037-1-git-send-email-p.zabel@pengutronix.de>
References: <1372422256-22037-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20130701084508.GD13206@S2101-09.ap.freescale.net>

On Fri, Jun 28, 2013 at 02:24:15PM +0200, Philipp Zabel wrote:
> i.MX6S/DL have the Video PLL post dividers fixed already in revision 1.0
> 
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>

Applied, thanks.

Shawn



From richard.genoud at gmail.com  Mon Jul  1 04:39:36 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  1 Jul 2013 10:39:36 +0200
Subject: [RFC PATCH 11/13] sound: atmel-pcm-dma: check pointer before
 dereference
In-Reply-To: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1372667978-4718-12-git-send-email-richard.genoud@gmail.com>

If platform_data is NULL, filter() is called with a NULL slave
parameter.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 sound/soc/atmel/atmel-pcm-dma.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/soc/atmel/atmel-pcm-dma.c b/sound/soc/atmel/atmel-pcm-dma.c
index 1d38fd0..b20dbba 100644
--- a/sound/soc/atmel/atmel-pcm-dma.c
+++ b/sound/soc/atmel/atmel-pcm-dma.c
@@ -96,6 +96,9 @@ static bool filter(struct dma_chan *chan, void *slave)
 {
 	struct at_dma_slave *sl = slave;
 
+	if (!sl)
+		return false;
+
 	if (sl->dma_dev == chan->device->dev) {
 		chan->private = sl;
 		return true;
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Mon Jul  1 04:52:03 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 01 Jul 2013 10:52:03 +0200
Subject: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver
In-Reply-To: <CAPM=9tydcpP2-A6fnnHB873Nekj4HnxjraZ3TtRG3UF-Bqa6OQ@mail.gmail.com>
References: <20130629225210.GF3353@n2100.arm.linux.org.uk>
 <E1Ut41C-0000wl-Ff@rmk-PC.arm.linux.org.uk>
 <20130630115941.GG18285@phenom.ffwll.local>
 <20130630125238.GH3353@n2100.arm.linux.org.uk>
 <CAPM=9tydcpP2-A6fnnHB873Nekj4HnxjraZ3TtRG3UF-Bqa6OQ@mail.gmail.com>
Message-ID: <51D14333.40307@gmail.com>

On 07/01/13 02:01, Dave Airlie wrote:
> how about instead of writing:
> "However, at least I've taken the time to_think_  about what I'm doing
> and realise that there_is_  scope here for the DRM core to improve,
> rather than burying this stuff deep inside my driver like everyone else
> has.  That's no reason to penalise patches from the "good guys" who think"
>
> you go with
> "I noticed this piece of functionality could be refactored, here is a
> patch adding them to
> the core, does anyone think its a good idea?"

Dave,

at least on this point I do share Russell's impression. I've sent
bunch of patches improving TDA998x and DRM+DT:
- TDA998x irq handling - ignored
- TDA998x sync fix - ignored
- Fix drm I2C slave encoder probing

I am aware that this is not an easy job nor one you get much
appreciation for. But, back when TDA998x driver was published,
all my comments were basically answered with "Oh, I know. Maybe
someday somebody will fix it".

I am not being paid for any of this, but have a strong intrinsic
motivation here. But I am loosing interest in sending fixes for
DRM stuff because my (personal) impression is the same Russell
has: Depending on who sends patches, they get merged independent
of how broken they are - others are discussed to death.

Sebastian


From shawn.guo at linaro.org  Mon Jul  1 04:52:57 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 16:52:57 +0800
Subject: [PATCH 2/2] ARM i.MX6DL: dts: add clock and mux configuration
 for LDB
In-Reply-To: <1372422256-22037-2-git-send-email-p.zabel@pengutronix.de>
References: <1372422256-22037-1-git-send-email-p.zabel@pengutronix.de>
 <1372422256-22037-2-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20130701085255.GE13206@S2101-09.ap.freescale.net>

On Fri, Jun 28, 2013 at 02:24:16PM +0200, Philipp Zabel wrote:
> i.MX6DL does not have the second IPU, but the LVDS multiplexers can connect
> either LVDS channel of the LDB to IPU1 DI0 or IPU1 DI1.
> 
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> ---
>  arch/arm/boot/dts/imx6dl.dtsi | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index 80155fde..5ec89eb 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boot/dts/imx6dl.dtsi
> @@ -417,3 +417,20 @@
>  		};
>  	};
>  };
> +
> +&ldb {
> +	clocks = <&clks 33>, <&clks 34>,
> +		 <&clks 39>, <&clks 40>,
> +		 <&clks 135>, <&clks 136>;
> +	clock-names = "di0_pll", "di1_pll",
> +		      "di0_sel", "di1_sel",
> +		      "di0", "di1";
> +
> +	lvds-channel at 0 {
> +		crtcs = <&ipu1 0>, <&ipu1 1>;
> +	};
> +
> +	lvds-channel at 1 {
> +		crtcs = <&ipu1 0>, <&ipu1 1>;
> +	};

So now we have both imx6q.dtsi and imx6dl.dtsi overwrite the "crtcs"
defined in imx6qdl.dtsi.  Should we remove it from imx6qdl.dtsi, or
define a sane one in imx6qdl.dtsi to save one overwrite?

Shawn

> +};
> -- 
> 1.8.3.1
> 



From p.zabel at pengutronix.de  Mon Jul  1 04:59:15 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon, 01 Jul 2013 10:59:15 +0200
Subject: [PATCH] ARM: dts: add sram for imx53 and imx6q
In-Reply-To: <20130701084323.GC13206@S2101-09.ap.freescale.net>
References: <1372416798-2828-1-git-send-email-p.zabel@pengutronix.de>
 <20130701084323.GC13206@S2101-09.ap.freescale.net>
Message-ID: <1372669155.4971.23.camel@pizza.hi.pengutronix.de>

Am Montag, den 01.07.2013, 16:43 +0800 schrieb Shawn Guo:
> On Fri, Jun 28, 2013 at 12:53:18PM +0200, Philipp Zabel wrote:
> > Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> > Reviewed-by: Shawn Guo <shawn.guo at linaro.org>
> > ---
> >  arch/arm/boot/dts/imx53.dtsi   | 5 +++++
> >  arch/arm/boot/dts/imx6qdl.dtsi | 6 ++++++
> >  2 files changed, 11 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> > index d437bfb..3def46f 100644
> > --- a/arch/arm/boot/dts/imx53.dtsi
> > +++ b/arch/arm/boot/dts/imx53.dtsi
> > @@ -1087,5 +1087,10 @@
> >  				status = "disabled";
> >  			};
> >  		};
> > +
> > +		ocram: ocram at f8000000 {
> > +			compatible = "fsl,imx-ocram", "mmio-sram";
> 
> I think we agreed to drop this custom compatible "fsl,imx-ocram" for
> now [1]?
> 
> Shawn
> 
> [1] http://thread.gmane.org/gmane.linux.kernel/1460369/focus=1465840

Sorry, my bad. I'll also rename the ocram node to sram.

regards
Philipp



From p.zabel at pengutronix.de  Mon Jul  1 04:59:05 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon, 01 Jul 2013 10:59:05 +0200
Subject: [PATCH 2/2] ARM i.MX6DL: dts: add clock and mux configuration
 for LDB
In-Reply-To: <20130701085255.GE13206@S2101-09.ap.freescale.net>
References: <1372422256-22037-1-git-send-email-p.zabel@pengutronix.de>
 <1372422256-22037-2-git-send-email-p.zabel@pengutronix.de>
 <20130701085255.GE13206@S2101-09.ap.freescale.net>
Message-ID: <1372669145.4971.22.camel@pizza.hi.pengutronix.de>

Hi Shawn,

Am Montag, den 01.07.2013, 16:52 +0800 schrieb Shawn Guo:
> On Fri, Jun 28, 2013 at 02:24:16PM +0200, Philipp Zabel wrote:
> > i.MX6DL does not have the second IPU, but the LVDS multiplexers can connect
> > either LVDS channel of the LDB to IPU1 DI0 or IPU1 DI1.
> > 
> > Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> > ---
> >  arch/arm/boot/dts/imx6dl.dtsi | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> > index 80155fde..5ec89eb 100644
> > --- a/arch/arm/boot/dts/imx6dl.dtsi
> > +++ b/arch/arm/boot/dts/imx6dl.dtsi
> > @@ -417,3 +417,20 @@
> >  		};
> >  	};
> >  };
> > +
> > +&ldb {
> > +	clocks = <&clks 33>, <&clks 34>,
> > +		 <&clks 39>, <&clks 40>,
> > +		 <&clks 135>, <&clks 136>;
> > +	clock-names = "di0_pll", "di1_pll",
> > +		      "di0_sel", "di1_sel",
> > +		      "di0", "di1";
> > +
> > +	lvds-channel at 0 {
> > +		crtcs = <&ipu1 0>, <&ipu1 1>;
> > +	};
> > +
> > +	lvds-channel at 1 {
> > +		crtcs = <&ipu1 0>, <&ipu1 1>;
> > +	};
> 
> So now we have both imx6q.dtsi and imx6dl.dtsi overwrite the "crtcs"
> defined in imx6qdl.dtsi.  Should we remove it from imx6qdl.dtsi, or
> define a sane one in imx6qdl.dtsi to save one overwrite?
> 
> Shawn

I'd rather remove it from imx6qdl.dtsi completely.

regards
Philipp



From shawn.guo at linaro.org  Mon Jul  1 05:06:32 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 17:06:32 +0800
Subject: [PATCHv3 5/8] ARM: mxs: dt: cfa10037: make hogpins grabbed by
 respective drivers
In-Reply-To: <51D058A4.7020101@free-electrons.com>
References: <1372424577-8279-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1372424577-8279-6-git-send-email-alexandre.belloni@free-electrons.com>
 <20130629070529.GD2593@lukather>
 <51D058A4.7020101@free-electrons.com>
Message-ID: <20130701090630.GF13206@S2101-09.ap.freescale.net>

On Sun, Jun 30, 2013 at 06:11:16PM +0200, Alexandre Belloni wrote:
> Do you want me to send a reordered serie or will you do it when applying
> the patches ? You can just apply patch 4/8 last.

Please resend, since you have some comments from Maxime on patch #2
unresolved? 

Shawn



From daniel.lezcano at linaro.org  Mon Jul  1 05:09:03 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 01 Jul 2013 11:09:03 +0200
Subject: [PATCH 1/3] ARM: EXYNOS: remove non-working AFTR mode support
In-Reply-To: <2055030.cNBSJEZ4PB@flatron>
References: <1372241627-22695-1-git-send-email-b.zolnierkie@samsung.com>
 <2484012.IH9WOi4iIR@amdc1032> <51CE0485.8020109@linaro.org>
 <2055030.cNBSJEZ4PB@flatron>
Message-ID: <51D1472F.2010103@linaro.org>

On 06/29/2013 12:47 AM, Tomasz Figa wrote:
> On Friday 28 of June 2013 23:47:49 Daniel Lezcano wrote:
>> On 06/28/2013 06:27 PM, Bartlomiej Zolnierkiewicz wrote:
>>> On Friday, June 28, 2013 01:20:09 PM Daniel Lezcano wrote:
>>>> On 06/28/2013 12:11 PM, Tomasz Figa wrote:
>>>>> Hi Daniel,
>>>>>
>>>>> I've been fighting with this whole AFTR state as well, before
>>>>> Bartlomiej. Let me share my thoughts on this.
>>
>> [ ... ]
>>
>>>>> If you don't unplug all the CPUs >0 the state is obviously never
>>>>> reached. Otherwise the whole system hangs after it tries to enter
>>>>> this mode without any reaction for external events, other than
>>>>> reset.
>>>>
>>>> Need investigation.
>>>>
>>>> What is the exynos board version where that occurs ?
>>>
>>> Could you please tell me what exactly do you mean by that?
>>>
>>> I already wrote that we can reproduce the problem on EXYNOS4210 rev0
>>> and rev1.1 (we don't have rev1.0). Tomek has also reproduced the
>>> problem on some later SoCs (I hope that he can give you exact
>>> revisions).
>>>
>>> In our testing we didn't encounter the board on which the problem
>>> doesn't occur. Our current working theory is that the problem may be
>>> u-boot (or first stage bootloader) related.
>>
>> Ok, the status for what I know:
>>
>> Origen Exynos4210, board ver A: works for me
>> Arndale Exynos5250: works for me but only if u-boot does not enable the
>> hypervisor mode.
>> Chromebook Exynos5250: works for me
>>
>> I found the following drivers:
>>
>> https://github.com/AndreiLux/Perseus-UNIVERSAL5410/blob/samsung/arch/arm
>> /mach-exynos/cpuidle.c
>>
>> https://github.com/CyanogenMod/hardkernel-kernel-4412/blob/cm-10.1/arch/
>> arm/mach-exynos/cpuidle-exynos4.c
>>
>> Sounds like the num cpus > 1 is still there.
> 
> As far as I know (and I can read from the documentation), AFTR is a state 
> in which program execution context (e.g. PC, CPU registers, etc.) is lost. 
> This is like sleep mode, but with much more state saved (all the 
> peripherals and L2 cache), which lets you resume much faster.
> 
> Based on that, the execution flow is as following:
>  - kernel stops all secondary cores,
>  - kernel configures PMU to enter AFTR mode,
>  - WFI is executed on boot CPU, which lets PMU enter the requested low 
> power mode,
>  - the system stays with all CPU cores powered off until a wake-up event 
> happens,
>  - a wake-up event causes a wake-up reset of the boot CPU, which resumes 
> operation from reset vector (usually IROM),
>  - here exactly the same procedure is used as on wake-up from sleep mode, 
> with the exception that some assumptions can be made about kept state, 
> like BL1 being still in IRAM/SYSRAM, without the need to reload it from 
> boot device,
>  - after going through all the boot code, it finally jumps to the resume 
> handler saved by kernel in one of those INFORM registers or somewhere in 
> SYSRAM,
>  - resume handler reinitializes boot CPU, restores things like MMU, 
> coprocessors, etc. and finally boots secondary cores again,
>  - the system is operating normally again.
> 
> This is simplified a lot, with all things happened internally in PMU and 
> boot code skipped, but should give the general picture. See all the 
> analogies to normal sleep mode, which (IMHO) makes it understandable that 
> this mode can't be entered with more than one core active. 
> 
> However, with something like coupled cpuidle, when possible, this mode can 
> be entered by powering down remaining cores automatically, so this is not 
> a problem with this mode itself, but rather with current approach of 
> entering it.

Are you saying only CPU0 can program the PMU to enter the AFTR mode ?
And only CPU0 can be woken up ?

Is it possible to have CPU0 to enter the AFTR idle state (without
switching to this mode), save its context and go to WFI. And then when
CPU1 goes to this state also, it saves its context and set the PMU to
enter the AFTR mode ?



-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From p.zabel at pengutronix.de  Mon Jul  1 05:06:09 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon,  1 Jul 2013 11:06:09 +0200
Subject: [PATCH v2] ARM: dts: add sram for imx53 and imx6q
Message-ID: <1372669569-12446-1-git-send-email-p.zabel@pengutronix.de>

This patch enables the On-Chip SRAM (OCRAM) on i.MX53 and i.MX6 SoCs.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
Reviewed-by: Shawn Guo <shawn.guo at linaro.org>
---
Changes since v1:
 - Fixed compatible property to only include "mmio-sram"
 - Renamed device nodes to "sram"
---
 arch/arm/boot/dts/imx53.dtsi   | 5 +++++
 arch/arm/boot/dts/imx6qdl.dtsi | 6 ++++++
 2 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index d437bfb..cec6cdd 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -1087,5 +1087,10 @@
 				status = "disabled";
 			};
 		};
+
+		ocram: sram at f8000000 {
+			compatible = "mmio-sram";
+			reg = <0xf8000000 0x20000>;
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 2d73f83..4033ad4 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -100,6 +100,12 @@
 			status = "disabled";
 		};
 
+		ocram: sram at 00900000 {
+			compatible = "mmio-sram";
+			reg = <0x00900000 0x3f000>;
+			clocks = <&clks 142>;
+		};
+
 		timer at 00a00600 {
 			compatible = "arm,cortex-a9-twd-timer";
 			reg = <0x00a00600 0x20>;
-- 
1.8.3.1



From daniel.lezcano at linaro.org  Mon Jul  1 05:23:43 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 01 Jul 2013 11:23:43 +0200
Subject: [PATCH 1/3] ARM: EXYNOS: remove non-working AFTR mode support
In-Reply-To: <23262498.GmEHQP5Xlz@flatron>
References: <1372241627-22695-1-git-send-email-b.zolnierkie@samsung.com>
 <1721255.XMYjiW81jp@amdc1227> <51CE0DB8.5040407@linaro.org>
 <23262498.GmEHQP5Xlz@flatron>
Message-ID: <51D14A9F.6000407@linaro.org>

On 06/29/2013 01:07 AM, Tomasz Figa wrote:
> On Saturday 29 of June 2013 00:27:04 Daniel Lezcano wrote:
>> On 06/28/2013 07:31 PM, Tomasz Figa wrote:
>>> On Friday 28 of June 2013 13:20:09 Daniel Lezcano wrote:
>> [ ... ]
>>
>>>> The kernel is not a playground where you can upstream code and then
>>>> remove it because a feature seems broken and you don't have an idea
>>>> of
>>>> why.
>>>
>>> Well, first of all, it has not been upstreamed correctly: a) without
>>> any given rationale (or at least without any I could find) and b)
>>> without enough testing.
>>
>> +1
>>
>>>> I asked several times the reasons of why the AFTR state couldn't work
>>>> with multiple CPUs and I had no answer.
>>>>
>>>> Frankly speaking I have a couple of hypothesis:
>>>>
>>>> 1. something is not correctly setup and the PMU does not wake up the
>>>> CPU1 2. there is a silicon bug and no one wants to tell it is the
>>>> case
>>>>
>>>> In any case, this must be investigated and identified. And then we
>>>> can
>>>> take a decision about this state.
>>>
>>> Well, everything you're saying is correct, assuming that this feature
>>> is useful, which needs confirmation. I'd still want any evidence of
>>> this feature being of any use first, to not waste time on something
>>> that is useless.
>>
>> IMHO, it is useful. That's sure a highly integrated hardware with a lot
>> of peripherals, the power saving is lost in the noise but with a small
>> embedded device, the power saving is significant.
> 
> Be aware that we might be talking here about savings of single 
> milliamperes, because the highest, dynamic, power consumption is already 
> bypassed in WFI idle mode, with stopped core clock.
> 
> Our measurements have shown that static leakage is pretty low on SoCs we 
> checked, that is Exynos 4210 and Exynos 4412. I don't remember exactly 
> ATM, because it was some time ago, but it was something around 2 mA per 
> core.

Ok I don't know exactly the values but I am a bit surprised by this
small value. When I measured the power consumption with a core offline
it saved roughly 100mA (AFAIR). Of course, there is no dynamic with the
hotplugging but there is really a big difference here.

With another board with similar hardware (but a different SoC), just
putting the cores in retention mode in the cpuidle drivers saved 13mA.

Is it possible for the exynos board, the target residency is too large
for AFTR mode ? Is this value really resulting from a measurement or
just put there arbitrarily ? And, may be, it does not enter enough in
this state to have a significant power saving.

> Now it depends on overall power consumption of given system, whether such 
> saving is significant or ignorable - in our case it is the latter, because 
> consumption caused by rest of the system (think of display, wireless 
> radios, etc.) is much higher.
> 
>> What I am worried about is the different SoCs being introduced in this
>> driver without investigating this cpu1 restriction and it sounds like
>> the AFTR seems to work (I have an odroid-u2 with a 4412 I will test to
>> check if the AFTR works on it) and nobody seems to be hurt by this and,
>> as you stated, there is no rational about it. That means the Exynos will
>> become really more and more power aggressive with 4/A15 or 8/A15 based
>> boards if the AFTR state is not correctly supported.
> 
> See my other reply, for a bit more information about this state and CPU1 
> restriction.
> 
>> AFAICT, there is also the LPA state and the DEEPSLEEP, right ? If the
>> AFTR does not work, I don't see these states working too.
> 
> Yes, there are other states as well. With similar execution flow, but 
> different set of preserved and lost context, requiring more or less save 
> and restore on kernel side.
> 
>> The cpuidle driver is critical for the new b.L architecture. If we
>> aren't able to put a cluster of big cpus in a power down state, we lose
>> the benefit of all the work made up-front at the scheduler level (eg.
>> small task packing, workqueue/timer migration) and more generally we
>> lose the benefit of the b.L architecture (except if we do some hacks
>> which are orthogonal to the generic approach).
> 
> In this case just simple power down of CPU cores is enough, which doesn't 
> require entering system-wide low power state, such as AFTR and friends. 
> Such low power mode is needed only when you want to power off all the 
> cores, which makes you lose program execution state.
> 
> When at least one of the cores is still active, the whole system is in 
> control of kernel and no special care must be taken to bring up cores that 
> are down and back, just standard SMP/hotplug ops.

Yes but unfortunately this approach has been nacked by the community
last year with the OMAP4.


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

  * English - detected
  * English
  * French

  * English
  * French

 <javascript:void(0);>


From xobs at kosagi.com  Mon Jul  1 05:24:00 2013
From: xobs at kosagi.com (Sean Cross)
Date: Mon, 1 Jul 2013 17:24:00 +0800
Subject: [PATCH 3/4] PCI: Add driver for i.MX6 PCI Express
In-Reply-To: <1372665061.36667486@f35.mail.ru>
References: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
 <1372662947-27160-4-git-send-email-xobs@kosagi.com>
 <1372665061.36667486@f35.mail.ru>
Message-ID: <C89FF158E3384F0E90A288AE1A712972@kosagi.com>

On Monday, July 1, 2013 at 3:51 PM, Alexander Shiyan wrote:
> > This adds a PCI Express port driver for the on-chip PCI Express port
> > present on the i.MX6 SoC. It is based on the PCI Express driver available
> > in the Freescale BSP.
> > 
> > Signed-off-by: Sean Cross <xobs at kosagi.com (mailto:xobs at kosagi.com)>
> ...
> > +++ b/Documentation/devicetree/bindings/pci/imx6q-pcie.txt
> > @@ -0,0 +1,20 @@
> > +* Freescale i.MX6Q PCI Express bridge
> > +
> > +Example (i.MX6Q)
> > + pcie: pcie at 01ffc000 {
> > + compatible = "fsl,imx6q-pcie";
> > + reg = <0x01ffc000 0x4000>,
> > + <0x01000000 0x100000>,
> > + <0x01100000 0xe00000>,
> > + <0x01f00000 0xfc000>;
> > + interrupts = <0 122 0x04>;
> > + clocks = <&clks 186>, <&clks 189>, <&clks 196>,
> > + <&clks 198>, <&clks 144>;
> > + clock-names = "sata_ref", "pcie_ref_125m", "lvds1_sel",
> > + "lvds1", "pcie_axi";
> > + power-enable = <&gpio7 12 0>;
> > + pcie-reset = <&gpio3 29 0>;
> 
> 
> 
> Can this be replaced with regulator/reset API?
I agree that power-enable might be better replaced with regulator API calls, and I'll rework this patch to incorporate a regulator.

I hadn't heard of the reset API before, and I note in the documentation that it says:

    Reset signals for whole standalone chips are most likely better represented as
    GPIOs, although there are likely to be exceptions to this rule.

This is a reset line going directly to a PCIe slot, which I think counts as a "standalone chip".

> > + wake-up = <&gpio3 22 0>;
> > + disable-endpoint = <&gpio2 16 0>;
> > + };
> 
> 
> 
> --- 




From will.deacon at arm.com  Mon Jul  1 05:27:24 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 1 Jul 2013 10:27:24 +0100
Subject: question about iotable_init( )  function
In-Reply-To: <35FD53F367049845BC99AC72306C23D19441BF586F@CNBJMBX05.corpusers.net>
References: <35FD53F367049845BC99AC72306C23D19441BF586F@CNBJMBX05.corpusers.net>
Message-ID: <20130701092723.GE14027@mudshark.cambridge.arm.com>

On Mon, Jul 01, 2013 at 08:31:38AM +0100, Wang, Yalin wrote:
> Hi  Will,
> 
> I have a question about iotable_init()  function (arch/arm/mm/mmu.c)
> I found  in this function it only allocate a vm_struct and insert it into vmlist ,
> But it didn?t allocate a vmap_area  to insert it  into vmap_area_root tree (mm/vmalloc.c).
> 
> So this means that the virtual address reserverd by iotable_init is not declared
> In vmap_area_root  ,  this is not safe ,  maybe some driver will use this virtual address as vmalloc again,
> I think it ?s not safe in this condition ,  should also add a vmap_area   node into vmap_area_root to
> Hold this virtual address not used by others .

The vmap_area structures are allocated and inserted later on by vmalloc_init
(iotable init is for static mappings early during boot).

Will


From shawn.guo at linaro.org  Mon Jul  1 05:30:34 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 17:30:34 +0800
Subject: [PATCH v3 2/5] ARM: dts: imx27: Add imx framebuffer device
In-Reply-To: <1372432206.785926201@f326.mail.ru>
References: <1372431037-13519-1-git-send-email-mpa@pengutronix.de>
 <1372431037-13519-3-git-send-email-mpa@pengutronix.de>
 <1372432206.785926201@f326.mail.ru>
Message-ID: <20130701093032.GG13206@S2101-09.ap.freescale.net>

On Fri, Jun 28, 2013 at 07:10:06PM +0400, Alexander Shiyan wrote:
> > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > ---
> >  arch/arm/boot/dts/imx27.dtsi | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
> > index 8603886..10dcbd3 100644
> > --- a/arch/arm/boot/dts/imx27.dtsi
> > +++ b/arch/arm/boot/dts/imx27.dtsi
> > @@ -342,6 +342,15 @@
> >  			reg = <0x10020000 0x20000>;
> >  			ranges;
> >  
> > +			imxfb: fb at 10021000 {
> 
> If it can be fixed while applying, it would be right to use just "fb" here.
> We now use a lot of devices without "imx"-prefix, so I do not see any need to use it here.

I actually prefer to use the block name if it's not a thing defined by
ePAPR.  In this case, it's "lcdc".  But since "fb" is already used in
compatible.  Okay, I fixed it up by dropping "imx" prefix.

Applied the whole series, thanks.

Shawn



From Yalin.Wang at sonymobile.com  Mon Jul  1 05:30:34 2013
From: Yalin.Wang at sonymobile.com (Wang, Yalin)
Date: Mon, 1 Jul 2013 17:30:34 +0800
Subject: question about iotable_init( )  function
In-Reply-To: <20130701092723.GE14027@mudshark.cambridge.arm.com>
References: <35FD53F367049845BC99AC72306C23D19441BF586F@CNBJMBX05.corpusers.net>
 <20130701092723.GE14027@mudshark.cambridge.arm.com>
Message-ID: <35FD53F367049845BC99AC72306C23D19441BF5871@CNBJMBX05.corpusers.net>

Hi  Will, 

Oh,  I  see,

Thanks for your clarification very much !

-----Original Message-----
From: Will Deacon [mailto:will.deacon at arm.com] 
Sent: Monday, July 01, 2013 5:27 PM
To: Wang, Yalin
Cc: 'Russell King - ARM Linux'; 'linux-arm-kernel at lists.infradead.org'; 'linux-arch at vger.kernel.org'
Subject: Re: question about iotable_init( ) function

On Mon, Jul 01, 2013 at 08:31:38AM +0100, Wang, Yalin wrote:
> Hi  Will,
> 
> I have a question about iotable_init()  function (arch/arm/mm/mmu.c) I 
> found  in this function it only allocate a vm_struct and insert it 
> into vmlist , But it didn?t allocate a vmap_area  to insert it  into vmap_area_root tree (mm/vmalloc.c).
> 
> So this means that the virtual address reserverd by iotable_init is 
> not declared In vmap_area_root  ,  this is not safe ,  maybe some driver will use this virtual address as vmalloc again,
> I think it ?s not safe in this condition ,  should also add a vmap_area   node into vmap_area_root to
> Hold this virtual address not used by others .

The vmap_area structures are allocated and inserted later on by vmalloc_init (iotable init is for static mappings early during boot).

Will

From broonie at kernel.org  Mon Jul  1 05:45:25 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 1 Jul 2013 10:45:25 +0100
Subject: [PATCH 2/4] ASoC: sgtl5000: defer the probe if clock is not found
In-Reply-To: <1372666571-17276-3-git-send-email-shawn.guo@linaro.org>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-3-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130701094525.GY27646@sirena.org.uk>

On Mon, Jul 01, 2013 at 04:16:09PM +0800, Shawn Guo wrote:
> It's not always the case that clock is already available when sgtl5000
> get probed at the first time, e.g. the clock is provided by CPU DAI
> which may be probed after sgtl5000.  So let's defer the probe when
> devm_clk_get() call fails and give it chance to try later.

Why not fix this in the clock API - the same logic is going to apply to
a great proportion of clocks?
-------------- 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/20130701/6fdf4c7b/attachment.sig>

From daniel at ffwll.ch  Mon Jul  1 05:42:58 2013
From: daniel at ffwll.ch (Daniel Vetter)
Date: Mon, 1 Jul 2013 11:42:58 +0200
Subject: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver
In-Reply-To: <51D14333.40307@gmail.com>
References: <20130629225210.GF3353@n2100.arm.linux.org.uk>
 <E1Ut41C-0000wl-Ff@rmk-PC.arm.linux.org.uk>
 <20130630115941.GG18285@phenom.ffwll.local>
 <20130630125238.GH3353@n2100.arm.linux.org.uk>
 <CAPM=9tydcpP2-A6fnnHB873Nekj4HnxjraZ3TtRG3UF-Bqa6OQ@mail.gmail.com>
 <51D14333.40307@gmail.com>
Message-ID: <20130701094258.GT18285@phenom.ffwll.local>

On Mon, Jul 01, 2013 at 10:52:03AM +0200, Sebastian Hesselbarth wrote:
> On 07/01/13 02:01, Dave Airlie wrote:
> >how about instead of writing:
> >"However, at least I've taken the time to_think_  about what I'm doing
> >and realise that there_is_  scope here for the DRM core to improve,
> >rather than burying this stuff deep inside my driver like everyone else
> >has.  That's no reason to penalise patches from the "good guys" who think"
> >
> >you go with
> >"I noticed this piece of functionality could be refactored, here is a
> >patch adding them to
> >the core, does anyone think its a good idea?"
> 
> Dave,
> 
> at least on this point I do share Russell's impression. I've sent
> bunch of patches improving TDA998x and DRM+DT:
> - TDA998x irq handling - ignored
> - TDA998x sync fix - ignored
> - Fix drm I2C slave encoder probing
> 
> I am aware that this is not an easy job nor one you get much
> appreciation for. But, back when TDA998x driver was published,
> all my comments were basically answered with "Oh, I know. Maybe
> someday somebody will fix it".

I guess part of the problem here is that in the arm world we don't (yet)
have many full-blown drivers and not many people to fix up stuff or chime
in with good review. And sometimes that just means that someone puts down
his foot and says "this is how we do it" - at least for drm/i915 I
sometimes have to do that to unblock a massive bikeshed-fest.

> I am not being paid for any of this, but have a strong intrinsic
> motivation here. But I am loosing interest in sending fixes for
> DRM stuff because my (personal) impression is the same Russell
> has: Depending on who sends patches, they get merged independent
> of how broken they are - others are discussed to death.

Hm, we run fairly extensive QA for drm/i915, and thus far the drm core
stuff hasn't really blown up badly for us. So can you please point at
examples where crap was merged and shouldn't have been?

Wrt to bikeshed to death I know that drm folks are a bit prone to that (me
included), but recently I haven't spotted a case where this happened. ARM
stuff excluded ofc since I don't follow that too closely. There's also
that Dave is sometimes a bit swamped, but pinging him on irc about lost
patches works well (at least for stuff I care about).

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


From pratyush.anand at st.com  Mon Jul  1 05:57:41 2013
From: pratyush.anand at st.com (Pratyush Anand)
Date: Mon, 1 Jul 2013 15:27:41 +0530
Subject: [PATCH 2/4] ARM: Enable PCI Express on ARM
In-Reply-To: <1372662947-27160-3-git-send-email-xobs@kosagi.com>
References: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
 <1372662947-27160-3-git-send-email-xobs@kosagi.com>
Message-ID: <51D15295.2000601@st.com>

On 7/1/2013 12:45 PM, Sean Cross wrote:
> Some ARM devices have PCI Express hardware, and should be able to take
> advantage of PCI Express code present in the common driver files.  Enable
> PCI Express on ARM, when PCI is available.
>
> Signed-off-by: Sean Cross <xobs at kosagi.com>
> ---
>   arch/arm/Kconfig |    2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 136f263..2f51f13 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1418,6 +1418,8 @@ config PCI_HOST_ITE8152
>
>   source "drivers/pci/Kconfig"
>
> +source "drivers/pci/pcie/Kconfig"
> +
>

[PATCH V10 2/4] ARM: EXYNOS: Enable PCIe support for Exynos5440 does the 
same thing.

  source "drivers/pcmcia/Kconfig"
>
>   endmenu
>




From richard.zhuhongxing at gmail.com  Mon Jul  1 06:02:51 2013
From: richard.zhuhongxing at gmail.com (Richard Zhu)
Date: Mon,  1 Jul 2013 18:02:51 +0800
Subject: [PATCH v2 0/4] ahci: enable ahci sata support on imx6q
Message-ID: <1372672975-2997-1-git-send-email-r65037@freescale.com>

v2: add imx6q specific ahci sata support
 - Setup standalone imx ahci sata driver, because of
 the misalignments of the bits definition of the HBA register.
 - Replace the node by the label in the board dts.
 - 

v1: http://www.spinics.net/lists/linux-ide/msg45581.html
 - add imx6q specific ahci sata support to arch/arm/mach-imx/mach-imx6q.c

These patches is based on imx/dt branch of
"http://git.linaro.org/git-ro/people/shawnguo/linux-2.6.git"



[v2 1/4] ARM: dtsi: enable ahci sata on imx6q platforms
[v2 2/4] imx: ahci: enable ahci sata on imx6q platforms
[v2 3/4] ARM: imx6q: update the sata bits definitions of gpr13
[v2 4/4] sata: imx: add ahci sata support on imx platforms

.../devicetree/bindings/ata/ahci-platform.txt      |    2 +-
arch/arm/mach-imx/mach-imx6q.c                     |   85 +++++-
drivers/ata/Kconfig                                |    8 +
drivers/ata/Makefile                               |    1 +
drivers/ata/sata_imx.c                             |  349 ++++++++++++++++++++
include/linux/mfd/syscon/imx6q-iomuxc-gpr.h        |  121 +++++--
6 files changed, 527 insertions(+), 39 deletions(-)


From broonie at kernel.org  Mon Jul  1 06:07:10 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 1 Jul 2013 11:07:10 +0100
Subject: [PATCH 1/4] ASoC: sgtl5000: give it a ramping time before writting
In-Reply-To: <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130701100710.GB27646@sirena.org.uk>

On Mon, Jul 01, 2013 at 04:16:08PM +0800, Shawn Guo wrote:

> +	/*
> +	 * It seems that sgtl5000 takes a longer time to get the registers
> +	 * ready for write than bread.  Let's give it a ramping time before
> +	 * the first write goes.
> +	 */
> +	msleep(50);
> +
>  	/* Ensure sgtl5000 will start with sane register values */
>  	ret = sgtl5000_fill_defaults(sgtl5000);
>  	if (ret)

This seems like a really odd place to add the sleep - I'd have expected
this to be a part of or just after the reset operation.  It's a *really*
long sleep too, though if that's what you need that's what you need.

Also "bread" :)
-------------- 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/20130701/38567814/attachment.sig>

From pratyush.anand at st.com  Mon Jul  1 06:08:19 2013
From: pratyush.anand at st.com (Pratyush Anand)
Date: Mon, 1 Jul 2013 15:38:19 +0530
Subject: [PATCH 3/4] PCI: Add driver for i.MX6 PCI Express
In-Reply-To: <1372662947-27160-4-git-send-email-xobs@kosagi.com>
References: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
 <1372662947-27160-4-git-send-email-xobs@kosagi.com>
Message-ID: <51D15513.7020101@st.com>

On 7/1/2013 12:45 PM, Sean Cross wrote:
> This adds a PCI Express port driver for the on-chip PCI Express port
> present on the i.MX6 SoC.  It is based on the PCI Express driver available
> in the Freescale BSP.
>
> Signed-off-by: Sean Cross <xobs at kosagi.com>
> ---

...

> diff --git a/drivers/pci/pcie/pcie-imx.c b/drivers/pci/pcie/pcie-imx.c
> new file mode 100644
> index 0000000..664679e
> --- /dev/null
> +++ b/drivers/pci/pcie/pcie-imx.c

Should go to drivers/pci/host/

> @@ -0,0 +1,1049 @@
> +/*
> + * drivers/pci/pcie/pcie-imx.c
> + *

...


> +#define ATU_R_BaseAddress 0x900
> +#define PCIE_PL_iATUVR (ATU_R_BaseAddress + 0x0)
> +#define PCIE_PL_iATURC1 (ATU_R_BaseAddress + 0x4)
> +#define PCIE_PL_iATURC2 (ATU_R_BaseAddress + 0x8)
> +#define PCIE_PL_iATURLBA (ATU_R_BaseAddress + 0xC)
> +#define PCIE_PL_iATURUBA (ATU_R_BaseAddress + 0x10)
> +#define PCIE_PL_iATURLA (ATU_R_BaseAddress + 0x14)
> +#define PCIE_PL_iATURLTA (ATU_R_BaseAddress + 0x18)
> +#define PCIE_PL_iATURUTA (ATU_R_BaseAddress + 0x1C)

I may be wrong, but from these offset it seems to me that it is SNPS 
controller. If yes, then please go through comments of
"[PATCH V1-10 0/4] PCIe support for Samsung Exynos5440 SoC"

Regards
Pratyush


From broonie at kernel.org  Mon Jul  1 06:11:40 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 1 Jul 2013 11:11:40 +0100
Subject: [PATCH 3/4] ASoC: mxs: register saif mclk to clock framework
In-Reply-To: <1372666571-17276-4-git-send-email-shawn.guo@linaro.org>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-4-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130701101140.GC27646@sirena.org.uk>

On Mon, Jul 01, 2013 at 04:16:10PM +0800, Shawn Guo wrote:
> Mostly the mxs system design uses saif0 mclk output as the clock source
> of codec.  Since the mclk is implemented as a general divider with the
> saif clk as the parent clock, let's register the mclk as a basic
> clk-divider to common clock framework.  Then with it being a clock
> provdier, clk_get() call in codec driver probe function will just work.

Applied, thanks.
-------------- 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/20130701/353cc584/attachment.sig>

From t.figa at samsung.com  Mon Jul  1 06:25:19 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Mon, 01 Jul 2013 12:25:19 +0200
Subject: [PATCH v10] i2c: exynos5: add High Speed I2C controller driver
In-Reply-To: <1371638905-30633-1-git-send-email-ch.naveen@samsung.com>
References: <1354021236-28596-2-git-send-email-ch.naveen@samsung.com>
 <1371638905-30633-1-git-send-email-ch.naveen@samsung.com>
Message-ID: <3925484.kHD24rQYyy@amdc1227>

Hi Naveen,

Looks mostly good, but see some comments inline.

On Wednesday 19 of June 2013 16:18:25 Naveen Krishna Chatradhi wrote:
> Adds support for High Speed I2C driver found in Exynos5 and
> later SoCs from Samsung.
> 
> Driver only supports Device Tree method.
> 
> Changes since v1:
> 1. Added FIFO functionality
> 2. Added High speed mode functionality
> 3. Remove SMBUS_QUICK
> 4. Remove the debugfs functionality
> 5. Use devm_* functions where ever possible
> 6. Driver is free from GPIO configs
> 7. Use OF data string "clock-frequency" to get the bus operating
> frequencies 8. Split the clock divisor calculation function
> 9. Add resets for the failed transacton cases
> 10. Removed retries as core does retries if -EAGAIN is returned
> 11. Removed mode from device tree info (use speed to distinguish
>     the mode of operation)
> 12. Use wait_for_completion_timeout as the interruptible case is not
> tested well 13. few other bug fixes and cosmetic changes
> 
> Signed-off-by: Taekgyun Ko <taeggyun.ko at samsung.com>
> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen at samsung.com>
> Reviewed-by: Simon Glass <sjg at google.com>
> Tested-by: Andrew Bresticker <abrestic at google.com>
> Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd at samsung.com>
> Signed-off-by: Andrew Bresticker <abrestic at google.com>
> ---
> 
> Changes since v9:
> Fixed below comments given by Wolfram, Thanks for the reivew.
> 1. Removed retries as core does retries if -EAGAIN is returned
> 2. Removed mode from device tree info (use speed to distinguish
>    the mode of operation)
> 3. Use module_platform_driver macro instead of init and exit
> 4. Use wait_for_completion_timeout as the interruptible case is not
> tested well
> 
>  .../devicetree/bindings/i2c/i2c-exynos5.txt        |   44 +
>  drivers/i2c/busses/Kconfig                         |    7 +
>  drivers/i2c/busses/Makefile                        |    1 +
>  drivers/i2c/busses/i2c-exynos5.c                   |  861
> ++++++++++++++++++++ 4 files changed, 913 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> create mode 100644 drivers/i2c/busses/i2c-exynos5.c
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt new file mode
> 100644
> index 0000000..805e018
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> @@ -0,0 +1,44 @@
> +* Samsung's High Speed I2C controller
> +
> +The Samsung's High Speed I2C controller is used to interface with I2C
> devices +at various speeds ranging from 100khz to 3.4Mhz.
> +
> +Required properties:
> +  - compatible: value should be.
> +      -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.

IMHO this compatible value is too wide. You might end up with new Exynos 5 
SoC that has a high speed I2C controller as well, but slightly different, 
requiring some extra quirks.  Now exynos5 in compatible would suggest that 
it covers all Exynos 5 SoCs, but such SoC would require new one.

Basically, my suggestion is to use a compatible value with name of first SoC 
in which given IP appeared, as it is already done in most bindings.

> +  - reg: physical base address of the controller and length of memory
> mapped +    region.
> +  - interrupts: interrupt number to the cpu.
> +  - #address-cells: always 1 (for i2c addresses)
> +  - #size-cells: always 0
> +
> +  - Pinctrl:
> +    - pinctrl-0: Pin control group to be used for this controller.
> +    - pinctrl-names: Should contain only one value - "default".
> +
> +Optional properties:
> +  - clock-frequency: Desired operating frequency in Hz of the bus.
> +    -> If not specified, the default value is 100khz in fast-speed mode
> and +       1Mhz in high-speed mode.
> +    -> If specified, The bus operates in high-speed mode only if the
> +       clock-frequency is >= 1Mhz.
> +
> +Example:
> +
> +hsi2c at 12ca0000 {
> +	compatible = "samsung,exynos5-hsi2c";
> +	reg = <0x12ca0000 0x100>;
> +	interrupts = <56>;
> +	clock-frequency = <100000>;
> +
> +	pinctrl-0 = <&i2c4_bus>;
> +	pinctrl-names = "default";
> +
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	s2mps11_pmic at 66 {
> +		compatible = "samsung,s2mps11-pmic";
> +		reg = <0x66>;
> +	};
> +};
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 96c6d82..fecbe66 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -434,6 +434,13 @@ config I2C_EG20T
>  	  ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
>  	  ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
> 
> +config I2C_EXYNOS5
> +	tristate "Exynos5 high-speed I2C driver"
> +	depends on ARCH_EXYNOS5 && OF
> +	help
> +	  Say Y here to include support for high-speed I2C controller in the
> +	  Exynos5 based Samsung SoCs.
> +
>  config I2C_GPIO
>  	tristate "GPIO-based bitbanging I2C"
>  	depends on GPIOLIB
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 385f99d..af6fa37 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -42,6 +42,7 @@ i2c-designware-platform-objs :=
> i2c-designware-platdrv.o obj-$(CONFIG_I2C_DESIGNWARE_PCI)	+=
> i2c-designware-pci.o
>  i2c-designware-pci-objs := i2c-designware-pcidrv.o
>  obj-$(CONFIG_I2C_EG20T)		+= i2c-eg20t.o
> +obj-$(CONFIG_I2C_EXYNOS5)	+= i2c-exynos5.o
>  obj-$(CONFIG_I2C_GPIO)		+= i2c-gpio.o
>  obj-$(CONFIG_I2C_HIGHLANDER)	+= i2c-highlander.o
>  obj-$(CONFIG_I2C_IBM_IIC)	+= i2c-ibm_iic.o
> diff --git a/drivers/i2c/busses/i2c-exynos5.c
> b/drivers/i2c/busses/i2c-exynos5.c new file mode 100644
> index 0000000..696d16f
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -0,0 +1,861 @@
> +/**
> + * i2c-exynos5.c - Samsung Exynos5 I2C Controller Driver
> + *
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/time.h>
> +#include <linux/interrupt.h>
> +#include <linux/delay.h>
> +#include <linux/errno.h>
> +#include <linux/err.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/clk.h>
> +#include <linux/slab.h>
> +#include <linux/io.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_i2c.h>
> +
> +/*
> + * HSI2C controller from Samsung supports 2 modes of operation
> + * 1. Auto mode: Where in master automatically controls the whole
> transaction + * 2. Manual mode: Software controls the transaction by
> issuing commands + *    START, READ, WRITE, STOP, RESTART in
> I2C_MANUAL_CMD register. + *
> + * Operation mode can be selected by setting AUTO_MODE bit in I2C_CONF
> register + *

I think a comment about mode used in this driver would be good.

> + * Special bits are available for both modes of operation to set
> commands + * and for checking transfer status
> + */
> +
> +/* Register Map */
> +#define HSI2C_CTL		0x00
> +#define HSI2C_FIFO_CTL		0x04
> +#define HSI2C_TRAILIG_CTL	0x08
> +#define HSI2C_CLK_CTL		0x0C
> +#define HSI2C_CLK_SLOT		0x10
> +#define HSI2C_INT_ENABLE	0x20
> +#define HSI2C_INT_STATUS	0x24
> +#define HSI2C_ERR_STATUS	0x2C
> +#define HSI2C_FIFO_STATUS	0x30
> +#define HSI2C_TX_DATA		0x34
> +#define HSI2C_RX_DATA		0x38
> +#define HSI2C_CONF		0x40
> +#define HSI2C_AUTO_CONF		0x44
> +#define HSI2C_TIMEOUT		0x48
> +#define HSI2C_MANUAL_CMD	0x4C
> +#define HSI2C_TRANS_STATUS	0x50
> +#define HSI2C_TIMING_HS1	0x54
> +#define HSI2C_TIMING_HS2	0x58
> +#define HSI2C_TIMING_HS3	0x5C
> +#define HSI2C_TIMING_FS1	0x60
> +#define HSI2C_TIMING_FS2	0x64
> +#define HSI2C_TIMING_FS3	0x68
> +#define HSI2C_TIMING_SLA	0x6C
> +#define HSI2C_ADDR		0x70

nit: AFAIK lower case characters are preferred in hexadecimal numbers in 
kernel coding style.

> +/* I2C_CTL Register bits */
> +#define HSI2C_FUNC_MODE_I2C			(1u << 0)
> +#define HSI2C_MASTER				(1u << 3)
> +#define HSI2C_RXCHON				(1u << 6)
> +#define HSI2C_TXCHON				(1u << 7)
> +#define HSI2C_SW_RST				(1u << 31)
> +
> +/* I2C_FIFO_CTL Register bits */
> +#define HSI2C_RXFIFO_EN				(1u << 0)
> +#define HSI2C_TXFIFO_EN				(1u << 1)
> +#define HSI2C_FIFO_MAX				(0x40)

nit: You don't need parentheses in case of simple numbers.

> +#define HSI2C_RXFIFO_TRIGGER_LEVEL(x)		((x) << 4)
> +#define HSI2C_TXFIFO_TRIGGER_LEVEL(x)		((x) << 16)
> +/* I2C_TRAILING_CTL Register bits */
> +#define HSI2C_TRAILING_COUNT			(0xf)
> +
> +/* I2C_INT_EN Register bits */
> +#define HSI2C_INT_TX_ALMOSTEMPTY_EN		(1u << 0)
> +#define HSI2C_INT_RX_ALMOSTFULL_EN		(1u << 1)
> +#define HSI2C_INT_TRAILING_EN			(1u << 6)
> +#define HSI2C_INT_I2C_EN			(1u << 9)
> +
> +/* I2C_INT_STAT Register bits */
> +#define HSI2C_INT_TX_ALMOSTEMPTY		(1u << 0)
> +#define HSI2C_INT_RX_ALMOSTFULL			(1u << 1)
> +#define HSI2C_INT_TX_UNDERRUN			(1u << 2)
> +#define HSI2C_INT_TX_OVERRUN			(1u << 3)
> +#define HSI2C_INT_RX_UNDERRUN			(1u << 4)
> +#define HSI2C_INT_RX_OVERRUN			(1u << 5)
> +#define HSI2C_INT_TRAILING			(1u << 6)
> +#define HSI2C_INT_I2C				(1u << 9)
> +#define HSI2C_RX_INT				(HSI2C_INT_RX_ALMOSTFULL | \
> +						 HSI2C_INT_RX_UNDERRUN | \
> +						 HSI2C_INT_RX_OVERRUN | \
> +						 HSI2C_INT_TRAILING)
> +
> +/* I2C_FIFO_STAT Register bits */
> +#define HSI2C_RX_FIFO_EMPTY			(1u << 24)
> +#define HSI2C_RX_FIFO_FULL			(1u << 23)
> +#define HSI2C_RX_FIFO_LVL(x)			((x >> 16) & 0x7f)
> +#define HSI2C_TX_FIFO_EMPTY			(1u << 8)
> +#define HSI2C_TX_FIFO_FULL			(1u << 7)
> +#define HSI2C_TX_FIFO_LVL(x)			((x >> 0) & 0x7f)
> +#define HSI2C_FIFO_EMPTY			(HSI2C_RX_FIFO_EMPTY |	\
> +						HSI2C_TX_FIFO_EMPTY)
> +
> +/* I2C_CONF Register bits */
> +#define HSI2C_AUTO_MODE				(1u << 31)
> +#define HSI2C_10BIT_ADDR_MODE			(1u << 30)
> +#define HSI2C_HS_MODE				(1u << 29)
> +
> +/* I2C_AUTO_CONF Register bits */
> +#define HSI2C_READ_WRITE			(1u << 16)
> +#define HSI2C_STOP_AFTER_TRANS			(1u << 17)
> +#define HSI2C_MASTER_RUN			(1u << 31)
> +
> +/* I2C_TIMEOUT Register bits */
> +#define HSI2C_TIMEOUT_EN			(1u << 31)
> +
> +/* I2C_TRANS_STATUS register bits */
> +#define HSI2C_MASTER_BUSY			(1u << 17)
> +#define HSI2C_SLAVE_BUSY			(1u << 16)
> +#define HSI2C_TIMEOUT_AUTO			(1u << 4)
> +#define HSI2C_NO_DEV				(1u << 3)
> +#define HSI2C_NO_DEV_ACK			(1u << 2)
> +#define HSI2C_TRANS_ABORT			(1u << 1)
> +#define HSI2C_TRANS_DONE			(1u << 0)
> +
> +/* I2C_ADDR register bits */
> +#define HSI2C_SLV_ADDR_SLV(x)			((x & 0x3ff) << 0)
> +#define HSI2C_SLV_ADDR_MAS(x)			((x & 0x3ff) << 10)
> +#define HSI2C_MASTER_ID(x)			((x & 0xff) << 24)
> +#define MASTER_ID(x)				((x & 0x7) + 0x08)
> +
> +/*
> + * Controller operating frequency, timing values for operation
> + * are calculated against this frequency
> + */
> +#define HSI2C_HS_TX_CLOCK	1000000
> +#define HSI2C_FS_TX_CLOCK	100000
> +#define HSI2C_HIGH_SPD		1
> +#define HSI2C_FAST_SPD		0
> +
> +#define EXYNOS5_I2C_TIMEOUT (msecs_to_jiffies(1000))
> +
> +/* timeout for pm runtime autosuspend */
> +#define EXYNOS5_I2C_PM_TIMEOUT		1000	/* ms */

1 second seems a lot, but I guess such block don't use too much power.

> +struct exynos5_i2c {
> +	struct i2c_adapter	adap;
> +	unsigned int		suspended:1;
> +
> +	struct i2c_msg		*msg;
> +	struct completion	msg_complete;
> +	unsigned int		msg_ptr;
> +	unsigned int		msg_len;
> +
> +	unsigned int		irq;
> +
> +	void __iomem		*regs;
> +	struct clk		*clk;
> +	struct device		*dev;
> +	int			state;
> +
> +	/*
> +	 * Since the TRANS_DONE bit is cleared on read, and we may read it
> +	 * either during an IRQ or after a transaction, keep track of its
> +	 * state here.
> +	 */
> +	int			trans_done;
> +
> +	/* Controller operating frequency */
> +	unsigned int		fs_clock;
> +	unsigned int		hs_clock;
> +
> +	/*
> +	 * HSI2C Controller can operate in
> +	 * 1. High speed upto 3.4Mbps
> +	 * 2. Fast speed upto 1Mbps
> +	 */
> +	int			speed_mode;
> +	int			bus_id;
> +};
> +
> +static const struct of_device_id exynos5_i2c_match[] = {
> +	{ .compatible = "samsung,exynos5-hsi2c" },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, exynos5_i2c_match);
> +
> +static void exynos5_i2c_clr_pend_irq(struct exynos5_i2c *i2c)
> +{
> +	writel(readl(i2c->regs + HSI2C_INT_STATUS),
> +				i2c->regs + HSI2C_INT_STATUS);
> +}
> +
> +/*
> + * exynos5_i2c_set_timing: updates the registers with appropriate
> + * timing values calculated
> + *
> + * Returns 0 on success, -EINVAL if the cycle length cannot
> + * be calculated.
> + */
> +static int exynos5_i2c_set_timing(struct exynos5_i2c *i2c, int mode)
> +{
> +	u32 i2c_timing_s1;
> +	u32 i2c_timing_s2;
> +	u32 i2c_timing_s3;
> +	u32 i2c_timing_sla;
> +	unsigned int t_start_su, t_start_hd;
> +	unsigned int t_stop_su;
> +	unsigned int t_data_su, t_data_hd;
> +	unsigned int t_scl_l, t_scl_h;
> +	unsigned int t_sr_release;
> +	unsigned int t_ftl_cycle;
> +	unsigned int clkin = clk_get_rate(i2c->clk);
> +	unsigned int div, utemp0 = 0, utemp1 = 0, clk_cycle;
> +	unsigned int op_clk = (mode == HSI2C_HIGH_SPD) ?
> +				i2c->hs_clock : i2c->fs_clock;
> +
> +	/*
> +	 * FPCLK / FI2C =
> +	 * (CLK_DIV + 1) * (TSCLK_L + TSCLK_H + 2) + 8 + 2 * FLT_CYCLE
> +	 * utemp0 = (CLK_DIV + 1) * (TSCLK_L + TSCLK_H + 2)
> +	 * utemp1 = (TSCLK_L + TSCLK_H + 2)
> +	 */
> +	t_ftl_cycle = (readl(i2c->regs + HSI2C_CONF) >> 16) & 0x7;
> +	utemp0 = (clkin / op_clk) - 8 - 2 * t_ftl_cycle;
> +
> +	/* CLK_DIV max is 256 */
> +	for (div = 0; div < 256; div++) {
> +		utemp1 = utemp0 / (div + 1);
> +
> +		/*
> +		 * SCL_L and SCL_H each has max value of 255
> +		 * Hence, For the clk_cycle to the have right value
> +		 * utemp1 has to be less then 512 and more than 4.
> +		 */
> +		if ((utemp1 < 512) && (utemp1 > 4)) {
> +			clk_cycle = utemp1 - 2;
> +			break;
> +		} else if (div == 255) {
> +			dev_warn(i2c->dev, "Failed to calculate divisor");
> +			return -EINVAL;
> +		}
> +	}
> +
> +	t_scl_l = clk_cycle / 2;
> +	t_scl_h = clk_cycle / 2;
> +	t_start_su = t_scl_l;
> +	t_start_hd = t_scl_l;
> +	t_stop_su = t_scl_l;
> +	t_data_su = t_scl_l / 2;
> +	t_data_hd = t_scl_l / 2;
> +	t_sr_release = clk_cycle;
> +
> +	i2c_timing_s1 = t_start_su << 24 | t_start_hd << 16 | t_stop_su << 8;
> +	i2c_timing_s2 = t_data_su << 24 | t_scl_l << 8 | t_scl_h << 0;
> +	i2c_timing_s3 = div << 16 | t_sr_release << 0;
> +	i2c_timing_sla = t_data_hd << 0;
> +
> +	dev_dbg(i2c->dev, "tSTART_SU: %X, tSTART_HD: %X, tSTOP_SU: %X\n",
> +		t_start_su, t_start_hd, t_stop_su);
> +	dev_dbg(i2c->dev, "tDATA_SU: %X, tSCL_L: %X, tSCL_H: %X\n",
> +		t_data_su, t_scl_l, t_scl_h);
> +	dev_dbg(i2c->dev, "nClkDiv: %X, tSR_RELEASE: %X\n",
> +		div, t_sr_release);
> +	dev_dbg(i2c->dev, "tDATA_HD: %X\n", t_data_hd);
> +
> +	if (mode == HSI2C_HIGH_SPD) {
> +		writel(i2c_timing_s1, i2c->regs + HSI2C_TIMING_HS1);
> +		writel(i2c_timing_s2, i2c->regs + HSI2C_TIMING_HS2);
> +		writel(i2c_timing_s3, i2c->regs + HSI2C_TIMING_HS3);
> +	} else {
> +		writel(i2c_timing_s1, i2c->regs + HSI2C_TIMING_FS1);
> +		writel(i2c_timing_s2, i2c->regs + HSI2C_TIMING_FS2);
> +		writel(i2c_timing_s3, i2c->regs + HSI2C_TIMING_FS3);
> +	}
> +	writel(i2c_timing_sla, i2c->regs + HSI2C_TIMING_SLA);
> +
> +	return 0;
> +}
> +
> +static int exynos5_hsi2c_clock_setup(struct exynos5_i2c *i2c)
> +{
> +	/*
> +	 * Configure the Fast speed timing values
> +	 * Even the High Speed mode initially starts with Fast mode
> +	 */
> +	if (exynos5_i2c_set_timing(i2c, HSI2C_FAST_SPD)) {
> +		dev_err(i2c->dev, "HSI2C FS Clock set up failed\n");
> +		return -EINVAL;
> +	}
> +
> +	/* configure the High speed timing values */
> +	if (i2c->speed_mode == HSI2C_HIGH_SPD) {
> +		if (exynos5_i2c_set_timing(i2c, HSI2C_HIGH_SPD)) {
> +			dev_err(i2c->dev, "HSI2C HS Clock set up failed\n");
> +			return -EINVAL;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +/*
> + * exynos5_i2c_init: configures the controller for I2C functionality
> + * Programs I2C controller for Master mode operation
> + */
> +static void exynos5_i2c_init(struct exynos5_i2c *i2c)
> +{
> +	u32 i2c_conf = readl(i2c->regs + HSI2C_CONF);
> +
> +	writel((HSI2C_FUNC_MODE_I2C | HSI2C_MASTER),
> +					i2c->regs + HSI2C_CTL);
> +	writel(HSI2C_TRAILING_COUNT, i2c->regs + HSI2C_TRAILIG_CTL);
> +
> +	if (i2c->speed_mode == HSI2C_HIGH_SPD) {
> +		writel(HSI2C_MASTER_ID(MASTER_ID(i2c->bus_id)),
> +					i2c->regs + HSI2C_ADDR);
> +		i2c_conf |= HSI2C_HS_MODE;
> +	}
> +
> +	writel(i2c_conf | HSI2C_AUTO_MODE, i2c->regs + HSI2C_CONF);
> +}
> +
> +static void exynos5_i2c_reset(struct exynos5_i2c *i2c)
> +{
> +	u32 i2c_ctl;
> +
> +	/* Set and clear the bit for reset */
> +	i2c_ctl = readl(i2c->regs + HSI2C_CTL);
> +	i2c_ctl |= HSI2C_SW_RST;
> +	writel(i2c_ctl, i2c->regs + HSI2C_CTL);
> +
> +	i2c_ctl = readl(i2c->regs + HSI2C_CTL);
> +	i2c_ctl &= ~HSI2C_SW_RST;
> +	writel(i2c_ctl, i2c->regs + HSI2C_CTL);
> +
> +	/* We don't expect calculations to fail during the run */
> +	exynos5_hsi2c_clock_setup(i2c);
> +	/* Initialize the configure registers */
> +	exynos5_i2c_init(i2c);
> +}
> +
> +/*
> + * exynos5_i2c_irq: top level IRQ servicing routine
> + *
> + * INT_STATUS registers gives the interrupt details. Further,
> + * FIFO_STATUS or TRANS_STATUS registers are to be check for detailed
> + * state of the bus.
> + */
> +static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id)
> +{
> +	struct exynos5_i2c *i2c = dev_id;
> +	u32 fifo_level, int_status, fifo_status, trans_status;
> +	unsigned char byte;
> +	int len = 0;
> +
> +	i2c->state = -EINVAL;
> +
> +	int_status = readl(i2c->regs + HSI2C_INT_STATUS);
> +	fifo_status = readl(i2c->regs + HSI2C_FIFO_STATUS);
> +
> +	if (int_status & HSI2C_INT_I2C) {
> +		trans_status = readl(i2c->regs + HSI2C_TRANS_STATUS);
> +		if (trans_status & HSI2C_NO_DEV_ACK) {
> +			dev_dbg(i2c->dev, "No ACK from device\n");
> +			i2c->state = -ENXIO;
> +		} else if (trans_status & HSI2C_NO_DEV) {
> +			dev_dbg(i2c->dev, "No device\n");
> +			i2c->state = -ENXIO;
> +		} else if (trans_status & HSI2C_TRANS_ABORT) {
> +			dev_dbg(i2c->dev, "Deal with arbitration lose\n");
> +			i2c->state = -EAGAIN;
> +		} else if (trans_status & HSI2C_TIMEOUT_AUTO) {
> +			dev_dbg(i2c->dev, "Accessing device timed out\n");
> +			i2c->state = -EAGAIN;
> +		} else if (trans_status & HSI2C_TRANS_DONE) {
> +			i2c->trans_done = 1;
> +			i2c->state = 0;
> +		}
> +	}
> +	/* TX_ALMOSTEMPTY can happen along with HSI2C_INT_I2C */

The comment says that both can happen, while your code assumes they are 
exlusive.

> +	else if (int_status &
> +			(HSI2C_INT_TX_UNDERRUN | HSI2C_INT_TX_ALMOSTEMPTY)) {
> +		fifo_level = HSI2C_TX_FIFO_LVL(fifo_status);
> +
> +		/* To support probing the devices for detection */
> +		if (i2c->msg->len == 0) {
> +			i2c->state = -ENXIO;
> +			goto stop;
> +		}
> +
> +		len = HSI2C_FIFO_MAX - fifo_level;
> +		if (len > i2c->msg->len)
> +			len = i2c->msg->len;
> +
> +		i2c->msg_len += len;
> +		while (len > 0) {
> +			byte = i2c->msg->buf[i2c->msg_ptr++];
> +			writel(byte, i2c->regs + HSI2C_TX_DATA);
> +			len--;
> +		}
> +		i2c->state = 0;
> +		goto stop;
> +	}
> +	/* If TX FIFO is full (give chance to clear) */
> +	else if (int_status & HSI2C_INT_TX_OVERRUN)

Is this even possible? The only reason for TX overrun I can see would be 
the driver trying to put data in FIFO when it doesn't have enough space, 
which shouldn't happen.

> +		i2c->state = 0;
> +
> +	if (int_status & (HSI2C_INT_RX_OVERRUN | HSI2C_INT_TRAILING |
> +		HSI2C_INT_RX_UNDERRUN | HSI2C_INT_RX_ALMOSTFULL)) {
> +		fifo_level = HSI2C_RX_FIFO_LVL(fifo_status);
> +
> +		if (fifo_level >= i2c->msg->len)
> +			len = i2c->msg->len;
> +		else
> +			len = fifo_level;
> +
> +		i2c->msg_len += len;
> +		while (len > 0) {
> +			byte = (unsigned char)
> +				readl(i2c->regs + HSI2C_RX_DATA);
> +			i2c->msg->buf[i2c->msg_ptr++] = byte;
> +			len--;
> +		}
> +		i2c->state = 0;
> +	}
> +
> +
> + stop:
> +	if ((i2c->msg_len == i2c->msg->len) || (i2c->state < 0)) {
> +		writel(0, i2c->regs + HSI2C_INT_ENABLE);
> +		complete(&i2c->msg_complete);
> +	}
> +
> +	exynos5_i2c_clr_pend_irq(i2c);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +/*
> + * exynos5_i2c_wait_bus_idle
> + *
> + * Wait for the transaction to complete (indicated by the TRANS_DONE bit
> + * being set), and, if this is the last message in a transfer, wait for
> the + * MASTER_BUSY bit to be cleared.
> + *
> + * Returns -EBUSY if the bus cannot be brought to idle
> + */
> +static int exynos5_i2c_wait_bus_idle(struct exynos5_i2c *i2c, int stop)
> +{
> +	unsigned long stop_time;
> +	u32 trans_status;
> +
> +	/* wait for 100 milli seconds for the bus to be idle */
> +	stop_time = jiffies + msecs_to_jiffies(100) + 1;
> +	do {
> +		trans_status = readl(i2c->regs + HSI2C_TRANS_STATUS);
> +		if (trans_status & HSI2C_TRANS_DONE)
> +			i2c->trans_done = 1;
> +		/*
> +		 * Only wait for MASTER_BUSY to be cleared if this is the last
> +		 * message.
> +		 */
> +		if ((!stop || !(trans_status & HSI2C_MASTER_BUSY)) &&
> +		    i2c->trans_done)
> +			return 0;
> +
> +		usleep_range(50, 200);
> +	} while (time_before(jiffies, stop_time));
> +
> +	return -EBUSY;
> +}
> +
> +/*
> + * exynos5_i2c_message_start: Configures the bus and starts the xfer
> + * i2c: struct exynos5_i2c pointer for the current bus
> + * stop: Enables stop after transfer if set. Set for last transfer of
> + *       in the list of messages.
> + *
> + * Configures the bus for read/write function
> + * Sets chip address to talk to, message length to be sent.
> + * Enables appropriate interrupts and sends start xfer command.
> + */
> +static void exynos5_i2c_message_start(struct exynos5_i2c *i2c, int stop)
> +{
> +	u32 i2c_ctl;
> +	u32 int_en = HSI2C_INT_I2C_EN;
> +	u32 i2c_auto_conf = 0;
> +	u32 fifo_ctl;
> +	u32 i2c_timeout;
> +
> +	/*
> +	 * When the message length is > FIFO depth, set the FIFO trigger
> +	 * at FIFO_MAX - 4. Just for ease of handling.
> +	 */
> +	unsigned short len = (i2c->msg->len > HSI2C_FIFO_MAX) ?
> +					(HSI2C_FIFO_MAX - 4) : i2c->msg->len;
> +
> +	/* Clear to enable Timeout */
> +	i2c_timeout = readl(i2c->regs + HSI2C_TIMEOUT);
> +	i2c_timeout &= ~HSI2C_TIMEOUT_EN;
> +	writel(i2c_timeout, i2c->regs + HSI2C_TIMEOUT);
> +
> +	fifo_ctl = HSI2C_RXFIFO_EN | HSI2C_TXFIFO_EN;
> +	writel(fifo_ctl, i2c->regs + HSI2C_FIFO_CTL);
> +
> +	i2c_ctl = readl(i2c->regs + HSI2C_CTL);
> +	i2c_ctl &= ~(HSI2C_TXCHON | HSI2C_RXCHON);
> +	if (i2c->msg->flags & I2C_M_RD) {
> +		i2c_ctl |= HSI2C_RXCHON;
> +
> +		i2c_auto_conf |= HSI2C_READ_WRITE;
> +
> +		fifo_ctl |= HSI2C_RXFIFO_TRIGGER_LEVEL(len);
> +		int_en |= (HSI2C_INT_RX_ALMOSTFULL_EN |
> +			HSI2C_INT_TRAILING_EN);
> +	} else {
> +		i2c_ctl |= HSI2C_TXCHON;
> +
> +		fifo_ctl |= HSI2C_TXFIFO_TRIGGER_LEVEL(len);
> +		int_en |= HSI2C_INT_TX_ALMOSTEMPTY_EN;
> +	}
> +
> +	if (stop == 1)
> +		i2c_auto_conf |= HSI2C_STOP_AFTER_TRANS;
> +
> +	writel(HSI2C_SLV_ADDR_MAS(i2c->msg->addr), i2c->regs + HSI2C_ADDR);
> +
> +	writel(fifo_ctl, i2c->regs + HSI2C_FIFO_CTL);
> +	writel(i2c_ctl, i2c->regs + HSI2C_CTL);
> +
> +	/* In auto mode the length of xfer cannot be 0 */
> +	if (i2c->msg->len == 0)
> +		i2c_auto_conf |= 0x1;
> +	else
> +		i2c_auto_conf |= i2c->msg->len;
> +
> +	writel(i2c_auto_conf, i2c->regs + HSI2C_AUTO_CONF);
> +
> +	/* Start data transfer in Master mode */
> +	i2c_auto_conf = readl(i2c->regs + HSI2C_AUTO_CONF);
> +	i2c_auto_conf |= HSI2C_MASTER_RUN;
> +	writel(i2c_auto_conf, i2c->regs + HSI2C_AUTO_CONF);
> +
> +	writel(int_en, i2c->regs + HSI2C_INT_ENABLE);
> +}
> +
> +static int exynos5_i2c_xfer_msg(struct exynos5_i2c *i2c,
> +			      struct i2c_msg *msgs, int stop)
> +{
> +	unsigned long timeout;
> +	int ret;
> +
> +	i2c->msg = msgs;
> +	i2c->msg_ptr = 0;
> +	i2c->msg_len = 0;
> +	i2c->trans_done = 0;
> +
> +	INIT_COMPLETION(i2c->msg_complete);
> +
> +	exynos5_i2c_message_start(i2c, stop);
> +
> +	timeout = wait_for_completion_timeout
> +		(&i2c->msg_complete, EXYNOS5_I2C_TIMEOUT);
> +	if (timeout == 0) {
> +		exynos5_i2c_reset(i2c);
> +		dev_warn(i2c->dev, "%s timeout\n",
> +			 (msgs->flags & I2C_M_RD) ? "rx" : "tx");
> +		return timeout;
> +	}
> +
> +	ret = i2c->state;
> +
> +	if (ret == -EAGAIN) {
> +		exynos5_i2c_reset(i2c);
> +		return ret;
> +	}
> +
> +	/*
> +	 * If this is the last message to be transfered (stop == 1)
> +	 * Then check if the bus can be brought back to idle.
> +	 *
> +	 * Return -EBUSY if the bus still busy.
> +	 */
> +	if (exynos5_i2c_wait_bus_idle(i2c, stop))
> +		return -EBUSY;
> +
> +	/* Return the state as in interrupt routine */
> +	return ret;
> +}
> +
> +static int exynos5_i2c_xfer(struct i2c_adapter *adap,
> +			struct i2c_msg *msgs, int num)
> +{
> +	struct exynos5_i2c *i2c = (struct exynos5_i2c *)adap->algo_data;
> +	struct i2c_msg *msgs_ptr = msgs;
> +	int i = 0;
> +	int ret = 0, ret_pm;
> +	int stop = 0;
> +
> +	if (i2c->suspended) {
> +		dev_err(i2c->dev, "HS-I2C is not initialzed.\n");
> +		return -EIO;
> +	}
> +
> +	ret_pm = pm_runtime_get_sync(i2c->dev);
> +	if (IS_ERR_VALUE(ret_pm)) {

This looks wrong to me.

#define MAX_ERRNO       4095
#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)

This makes it:

if (unlikely((ret_pm) >= 0xFFFFF001)

which is obviously impossible for a signed value, such as ret_pm, which can 
be at most 0x7FFFFFFF.

Just check for ret_pm < 0 here and in other occurencies of IS_ERR_VALUE() 
in this driver.

> +		ret = -EIO;
> +		goto out;
> +	}
> +
> +	clk_prepare_enable(i2c->clk);

Shouldn't this (and any other clock gating/ungating) be inside a runtime PM 
callback? (Also this driver enables runtime PM, but lacks any callbacks. Is 
it really correct?)

> +
> +	for (i = 0; i < num; i++) {
> +		stop = (i == num - 1);
> +
> +		ret = exynos5_i2c_xfer_msg(i2c, msgs_ptr, stop);
> +		msgs_ptr++;
> +
> +		if (ret < 0)
> +			goto out;
> +	}
> +
> +	if (i == num) {
> +		ret = num;
> +	} else {
> +		/* Only one message, cannot access the device */
> +		if (i == 1)
> +			ret = -EREMOTEIO;
> +		else
> +			ret = i;
> +
> +		dev_warn(i2c->dev, "xfer message failed\n");
> +	}
> +
> + out:
> +	clk_disable_unprepare(i2c->clk);
> +	pm_runtime_mark_last_busy(i2c->dev);
> +	pm_runtime_put_autosuspend(i2c->dev);
> +	return ret;
> +}
> +
> +static u32 exynos5_i2c_func(struct i2c_adapter *adap)
> +{
> +	return I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
> +}
> +
> +static const struct i2c_algorithm exynos5_i2c_algorithm = {
> +	.master_xfer		= exynos5_i2c_xfer,
> +	.functionality		= exynos5_i2c_func,
> +};
> +
> +static int exynos5_i2c_probe(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct exynos5_i2c *i2c;
> +	struct resource *mem;
> +	unsigned int op_clock;
> +	int ret;
> +
> +	if (!np) {
> +		dev_err(&pdev->dev, "no device node\n");
> +		return -ENOENT;
> +	}
> +
> +	i2c = devm_kzalloc(&pdev->dev, sizeof(struct exynos5_i2c), GFP_KERNEL);
> +	if (!i2c) {
> +		dev_err(&pdev->dev, "no memory for state\n");
> +		return -ENOMEM;
> +	}
> +
> +	if (of_property_read_u32(np, "clock-frequency", &op_clock)) {
> +		i2c->speed_mode = HSI2C_FAST_SPD;
> +		i2c->fs_clock = HSI2C_FS_TX_CLOCK;
> +	}
> +
> +	if (op_clock >= HSI2C_HS_TX_CLOCK) {
> +		i2c->speed_mode = HSI2C_HIGH_SPD;
> +		i2c->fs_clock = HSI2C_FS_TX_CLOCK;
> +		i2c->hs_clock = op_clock;
> +	} else {
> +		i2c->speed_mode = HSI2C_FAST_SPD;
> +		i2c->fs_clock = op_clock;
> +	}
> +
> +	strlcpy(i2c->adap.name, "exynos5-i2c", sizeof(i2c->adap.name));
> +	i2c->adap.owner   = THIS_MODULE;
> +	i2c->adap.algo    = &exynos5_i2c_algorithm;
> +	i2c->adap.retries = 2;
> +
> +	i2c->dev = &pdev->dev;
> +	i2c->clk = devm_clk_get(&pdev->dev, "hsi2c");
> +	if (IS_ERR(i2c->clk)) {
> +		dev_err(&pdev->dev, "cannot get clock\n");
> +		return -ENOENT;
> +	}
> +
> +	clk_prepare_enable(i2c->clk);
> +
> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	i2c->regs = devm_ioremap_resource(&pdev->dev, mem);
> +	if (IS_ERR(i2c->regs)) {
> +		ret = PTR_ERR(i2c->regs);
> +		goto err_clk;
> +	}
> +
> +	i2c->adap.dev.of_node = np;
> +	i2c->adap.algo_data = i2c;
> +	i2c->adap.dev.parent = &pdev->dev;
> +
> +	/* Clear pending interrupts from u-boot or misc causes */
> +	exynos5_i2c_clr_pend_irq(i2c);
> +
> +	init_completion(&i2c->msg_complete);
> +
> +	i2c->irq = ret = irq_of_parse_and_map(np, 0);
> +	if (ret <= 0) {
> +		dev_err(&pdev->dev, "cannot find HS-I2C IRQ\n");
> +		ret = -EINVAL;
> +		goto err_clk;
> +	}

Please use platform_get_irq(pdev, 0) here. Don't waste the effort that is 
put into creating all those resources by of_platform_populate() early in 
boot process.

> +
> +	ret = devm_request_irq(&pdev->dev, i2c->irq, exynos5_i2c_irq,
> +				0, dev_name(&pdev->dev), i2c);
> +
> +	if (ret != 0) {
> +		dev_err(&pdev->dev, "cannot request HS-I2C IRQ %d\n", i2c->irq);
> +		goto err_clk;
> +	}
> +
> +	/*
> +	 * TODO: Use private lock to avoid race conditions as
> +	 * mentioned in pm_runtime.txt
> +	 */
> +	pm_runtime_enable(i2c->dev);
> +	pm_runtime_set_autosuspend_delay(i2c->dev, EXYNOS5_I2C_PM_TIMEOUT);
> +	pm_runtime_use_autosuspend(i2c->dev);
> +
> +	ret = pm_runtime_get_sync(i2c->dev);
> +	if (IS_ERR_VALUE(ret))
> +		goto err_clk;
> +
> +	ret = exynos5_hsi2c_clock_setup(i2c);
> +	if (ret)
> +		goto err_pm;
> +
> +	i2c->bus_id = of_alias_get_id(i2c->adap.dev.of_node, "hsi2c");

AFAIK it's responsibility of i2c core to handle this.

> +
> +	exynos5_i2c_init(i2c);
> +
> +	ret = i2c_add_adapter(&i2c->adap);

You can call i2c_add_numbered_adapter() here to make i2c core assign a 
number to your adapter, either automatically or using device tree alias.

Best regards,
Tomasz

> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to add bus to i2c core\n");
> +		goto err_pm;
> +	}
> +
> +	of_i2c_register_devices(&i2c->adap);
> +	platform_set_drvdata(pdev, i2c);
> +
> +	clk_disable_unprepare(i2c->clk);
> +	pm_runtime_mark_last_busy(i2c->dev);
> +	pm_runtime_put_autosuspend(i2c->dev);
> +
> +	return 0;
> +
> + err_pm:
> +	pm_runtime_put(i2c->dev);
> +	pm_runtime_disable(&pdev->dev);
> + err_clk:
> +	clk_disable_unprepare(i2c->clk);
> +	return ret;
> +}
> +
> +static int exynos5_i2c_remove(struct platform_device *pdev)
> +{
> +	struct exynos5_i2c *i2c = platform_get_drvdata(pdev);
> +	int ret;
> +
> +	ret = pm_runtime_get_sync(&pdev->dev);
> +	if (IS_ERR_VALUE(ret))
> +		return ret;
> +
> +	i2c_del_adapter(&i2c->adap);
> +
> +	pm_runtime_put(&pdev->dev);
> +	pm_runtime_disable(&pdev->dev);
> +
> +	clk_disable_unprepare(i2c->clk);
> +
> +	return 0;
> +}
> +
> +#ifdef CONFIG_PM
> +static int exynos5_i2c_suspend_noirq(struct device *dev)
> +{
> +	struct platform_device *pdev = to_platform_device(dev);
> +	struct exynos5_i2c *i2c = platform_get_drvdata(pdev);
> +
> +	i2c->suspended = 1;
> +
> +	return 0;
> +}
> +
> +static int exynos5_i2c_resume_noirq(struct device *dev)
> +{
> +	struct platform_device *pdev = to_platform_device(dev);
> +	struct exynos5_i2c *i2c = platform_get_drvdata(pdev);
> +	int ret = 0;
> +
> +	clk_prepare_enable(i2c->clk);
> +
> +	ret = exynos5_hsi2c_clock_setup(i2c);
> +	if (ret) {
> +		clk_disable_unprepare(i2c->clk);
> +		return ret;
> +	}
> +
> +	exynos5_i2c_init(i2c);
> +	clk_disable_unprepare(i2c->clk);
> +	i2c->suspended = 0;
> +
> +	return 0;
> +}
> +
> +static const struct dev_pm_ops exynos5_i2c_dev_pm_ops = {
> +	.suspend_noirq = exynos5_i2c_suspend_noirq,
> +	.resume_noirq	= exynos5_i2c_resume_noirq,
> +};
> +
> +#define EXYNOS5_DEV_PM_OPS (&exynos5_i2c_dev_pm_ops)
> +#else
> +#define EXYNOS5_DEV_PM_OPS NULL
> +#endif
> +
> +static struct platform_driver exynos5_i2c_driver = {
> +	.probe		= exynos5_i2c_probe,
> +	.remove		= exynos5_i2c_remove,
> +	.driver		= {
> +		.owner	= THIS_MODULE,
> +		.name	= "exynos5-hsi2c",
> +		.pm	= EXYNOS5_DEV_PM_OPS,
> +		.of_match_table = exynos5_i2c_match,
> +	},
> +};
> +
> +module_platform_driver(exynos5_i2c_driver);
> +
> +MODULE_DESCRIPTION("Exynos5 HS-I2C Bus driver");
> +MODULE_AUTHOR("Naveen Krishna Chatradhi, <ch.naveen at samsung.com>");
> +MODULE_AUTHOR("Taekgyun Ko, <taeggyun.ko at samsung.com>");
> +MODULE_LICENSE("GPL v2");


From r64343 at freescale.com  Mon Jul  1 06:37:12 2013
From: r64343 at freescale.com (Liu Hui-R64343)
Date: Mon, 1 Jul 2013 10:37:12 +0000
Subject: [PATCH] ARM: smp_twd: twd_update_frequency need be run on all
 online CPUs
In-Reply-To: <51CADE8A.7010008@de.bosch.com>
References: <1371079180-22344-1-git-send-email-r64343@freescale.com>
 <20130617073120.GA4537@S2101-09.ap.freescale.net>
 <AD13664F485EE54694E29A7F9D5BE1AF84939C@039-SN2MPN1-022.039d.mgd.msft.net>
 <51CADE8A.7010008@de.bosch.com>
Message-ID: <AD13664F485EE54694E29A7F9D5BE1AF8729B7@039-SN2MPN1-022.039d.mgd.msft.net>

>-----Original Message-----
>From: Dirk Behme [mailto:dirk.behme at de.bosch.com]
>Sent: Wednesday, June 26, 2013 8:29 PM
>To: Liu Hui-R64343; Mike Turquette
>Cc: Shawn Guo; Linus Walleij; rob.herring at calxeda.com; Russell King -
>ARM Linux; linux-arm-kernel at lists.infradead.org
>Subject: Re: [PATCH] ARM: smp_twd: twd_update_frequency need be run on
>all online CPUs
>
>On 17.06.2013 10:11, Liu Hui-R64343 wrote:
>>> -----Original Message-----
>>> From: Shawn Guo [mailto:shawn.guo at linaro.org]
>>> Sent: Monday, June 17, 2013 3:31 PM
>>> To: Liu Hui-R64343
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Subject: Re: [PATCH] ARM: smp_twd: twd_update_frequency need be run
>>> on all online CPUs
>>>
>>> On Thu, Jun 13, 2013 at 07:19:40AM +0800, Jason Liu wrote:
>>>> When the local timer freq changed, the twd_update_frequency function
>>>> should be run all the CPUs include itself, otherwise, the twd freq
>>>> will not get updated and the local timer will not run correcttly.
>>>>
>>>> smp_call_function will run functions on all other CPUs, but not
>>>> include himself, this is not correct,use on_each_cpu instead to fix
>>> this issue.
>>>>
>>>> Signed-off-by: Jason Liu <r64343 at freescale.com>
>>>> Cc: Russell King <linux at arm.linux.org.uk>
>>>> Cc: Linus Walleij <linus.walleij at linaro.org>
>>>> Cc: Rob Herring <rob.herring at calxeda.com>
>>>> Cc: Shawn Guo <shawn.guo at linaro.org>
>>>
>>> Acked-by: Shawn Guo <shawn.guo at linaro.org>
>>
>> Thanks Shawn.
>>
>>>
>>> BTW, is there anything wrong with your mailer (git send-email command
>>> line)?  I do not see people you put on Cc tag here show up in Cc of
>>> the email.  And that might the be reason why people are not
>>> responding so far.
>>
>> Yes, there is one issue in my script and get fixed. I will put the
>> patch Into Russell's patch tracking system after Mike and Russell
>> reviewed it And also Cc stable kernel as Linus W. said.
>
>Any news on this?

I have put the patch into Russell's patch tracking system. 

>
>Thanks
>



From user at jinso.co.jp  Mon Jul  1 06:00:07 2013
From: user at jinso.co.jp (Nguyen Viet Dung)
Date: Mon,  1 Jul 2013 19:00:07 +0900
Subject: [PATCH 0/4] ARM: shmobile: r8a7790: add I2C support
Message-ID: <1372672810-20609-1-git-send-email-user@jinso.co.jp>

From: Nguyen Viet Dung <nv-dung at jinso.co.jp>

Hello,
CC Morimoto

Please consider the following patches for the r8a7790 Soc.
These patches add I2C support for the r8a7790 Soc.
These patches was developed base on the renesas-next-20130528 branch.
Input clock of I2C is peripheral module clock.
It is named peripheral_clk in clock code. 
These patches have tested on the lager board.

Thanks,
Nguyen viet Dung

Nguyen Viet Dung (4):
  i2c: rcar: modify I2C driver
  ARM: shmobile: r8a7790: add I2C setup
  ARM: shmobile: r8a7790: add I2C clock
  ARM: shmobile: lager: register channels of I2C

 arch/arm/mach-shmobile/board-lager.c          |   11 ++++++++++
 arch/arm/mach-shmobile/clock-r8a7790.c        |   11 ++++++++++
 arch/arm/mach-shmobile/include/mach/r8a7790.h |    3 +++
 arch/arm/mach-shmobile/setup-r8a7790.c        |   28 +++++++++++++++++++++++++
 drivers/i2c/busses/i2c-rcar.c                 |   17 +++++++++++++--
 include/linux/i2c/i2c-rcar.h                  |    4 ++++
 6 files changed, 72 insertions(+), 2 deletions(-)

-- 
1.7.9.5



From user at jinso.co.jp  Mon Jul  1 06:00:08 2013
From: user at jinso.co.jp (Nguyen Viet Dung)
Date: Mon,  1 Jul 2013 19:00:08 +0900
Subject: [PATCH 1/4] i2c: rcar: modify I2C driver
In-Reply-To: <1372672810-20609-1-git-send-email-user@jinso.co.jp>
References: <1372672810-20609-1-git-send-email-user@jinso.co.jp>
Message-ID: <1372672810-20609-2-git-send-email-user@jinso.co.jp>

From: Nguyen Viet Dung <nv-dung at jinso.co.jp>

This patch modify calculate for clock in I2C driver.

Signed-off-by: Nguyen Viet Dung <nv-dung at jinso.co.jp>
---
 drivers/i2c/busses/i2c-rcar.c |   17 +++++++++++++++--
 include/linux/i2c/i2c-rcar.h  |    4 ++++
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 4ba4a95..85987c1 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -221,15 +221,28 @@ static int rcar_i2c_clock_calculate(struct rcar_i2c_priv *priv,
 				    struct device *dev)
 {
 	struct clk *clkp = clk_get(NULL, "peripheral_clk");
+	struct i2c_rcar_platform_data *pdata = dev->platform_data;
 	u32 scgd, cdf;
 	u32 round, ick;
 	u32 scl;
+	u32 cdf_width;
+	u32 flags = pdata ? pdata->flags : 0;
 
 	if (!clkp) {
 		dev_err(dev, "there is no peripheral_clk\n");
 		return -EIO;
 	}
 
+	switch (flags & I2C_RCAR_FLAGS_ICCCR_MASK) {
+	default:
+	case I2C_RCAR_FLAGS_ICCCR_IS_2BIT:
+		cdf_width = 2;
+		break;
+	case I2C_RCAR_FLAGS_ICCCR_IS_3BIT:
+		cdf_width = 3;
+		break;
+	}
+
 	/*
 	 * calculate SCL clock
 	 * see
@@ -245,7 +258,7 @@ static int rcar_i2c_clock_calculate(struct rcar_i2c_priv *priv,
 	 * clkp : peripheral_clk
 	 * F[]  : integer up-valuation
 	 */
-	for (cdf = 0; cdf < 4; cdf++) {
+	for (cdf = 0; cdf < (1 << cdf_width); cdf++) {
 		ick = clk_get_rate(clkp) / (1 + cdf);
 		if (ick < 20000000)
 			goto ick_find;
@@ -287,7 +300,7 @@ scgd_find:
 	/*
 	 * keep icccr value
 	 */
-	priv->icccr = (scgd << 2 | cdf);
+	priv->icccr = (scgd << (cdf_width) | cdf);
 
 	return 0;
 }
diff --git a/include/linux/i2c/i2c-rcar.h b/include/linux/i2c/i2c-rcar.h
index 496f5c2..572a6e5 100644
--- a/include/linux/i2c/i2c-rcar.h
+++ b/include/linux/i2c/i2c-rcar.h
@@ -5,6 +5,10 @@
 
 struct i2c_rcar_platform_data {
 	u32 bus_speed;
+	u32 flags;
+#define I2C_RCAR_FLAGS_ICCCR_MASK	(0xF << 0)
+#define I2C_RCAR_FLAGS_ICCCR_IS_2BIT	(0 << 0) /* default */
+#define I2C_RCAR_FLAGS_ICCCR_IS_3BIT	(1 << 0)
 };
 
 #endif /* __I2C_R_CAR_H__ */
-- 
1.7.9.5



From user at jinso.co.jp  Mon Jul  1 06:00:10 2013
From: user at jinso.co.jp (Nguyen Viet Dung)
Date: Mon,  1 Jul 2013 19:00:10 +0900
Subject: [PATCH 3/4] ARM: shmobile: r8a7790: add I2C clock
In-Reply-To: <1372672810-20609-1-git-send-email-user@jinso.co.jp>
References: <1372672810-20609-1-git-send-email-user@jinso.co.jp>
Message-ID: <1372672810-20609-4-git-send-email-user@jinso.co.jp>

From: Nguyen Viet Dung <nv-dung at jinso.co.jp>

This patch add clock for I2C bus.

Signed-off-by: Nguyen Viet Dung <nv-dung at jinso.co.jp>
---
 arch/arm/mach-shmobile/clock-r8a7790.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c b/arch/arm/mach-shmobile/clock-r8a7790.c
index b393592..f4b0f2b 100644
--- a/arch/arm/mach-shmobile/clock-r8a7790.c
+++ b/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -50,6 +50,7 @@
 #define SMSTPCR2 0xe6150138
 #define SMSTPCR3 0xe615013c
 #define SMSTPCR7 0xe615014c
+#define SMSTPCR9 0xE6150994
 
 #define MODEMR		0xE6160060
 #define SDCKCR		0xE6150074
@@ -180,6 +181,7 @@ static struct clk div6_clks[DIV6_NR] = {
 
 /* MSTP */
 enum {
+	MSTP931, MSTP930, MSTP929, MSTP928,
 	MSTP721, MSTP720,
 	MSTP304,
 	MSTP216, MSTP207, MSTP206, MSTP204, MSTP203, MSTP202,
@@ -187,6 +189,10 @@ enum {
 };
 
 static struct clk mstp_clks[MSTP_NR] = {
+	[MSTP931] = SH_CLK_MSTP32(&hp_clk, SMSTPCR9, 31, 0), /* I2C0 */
+	[MSTP930] = SH_CLK_MSTP32(&hp_clk, SMSTPCR9, 30, 0), /* I2C1 */
+	[MSTP929] = SH_CLK_MSTP32(&hp_clk, SMSTPCR9, 29, 0), /* I2C2 */
+	[MSTP928] = SH_CLK_MSTP32(&hp_clk, SMSTPCR9, 28, 0), /* I2C3 */
 	[MSTP721] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 21, 0), /* SCIF0 */
 	[MSTP720] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 20, 0), /* SCIF1 */
 	[MSTP304] = SH_CLK_MSTP32(&cp_clk, SMSTPCR3, 4, 0), /* TPU0 */
@@ -226,6 +232,7 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_CON_ID("mp",		&mp_clk),
 	CLKDEV_CON_ID("qspi",		&qspi_clk),
 	CLKDEV_CON_ID("cp",		&cp_clk),
+	CLKDEV_CON_ID("peripheral_clk",	&hp_clk),
 
 	/* DIV4 */
 	CLKDEV_CON_ID("sdh",		&div4_clks[DIV4_SDH]),
@@ -249,6 +256,10 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh-sci.5", &mstp_clks[MSTP202]),
 	CLKDEV_DEV_ID("sh-sci.6", &mstp_clks[MSTP721]),
 	CLKDEV_DEV_ID("sh-sci.7", &mstp_clks[MSTP720]),
+	CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP931]),
+	CLKDEV_DEV_ID("i2c-rcar.1", &mstp_clks[MSTP930]),
+	CLKDEV_DEV_ID("i2c-rcar.2", &mstp_clks[MSTP929]),
+	CLKDEV_DEV_ID("i2c-rcar.3", &mstp_clks[MSTP928]),
 };
 
 #define R8A7790_CLOCK_ROOT(e, m, p0, p1, p30, p31)		\
-- 
1.7.9.5



From user at jinso.co.jp  Mon Jul  1 06:00:09 2013
From: user at jinso.co.jp (Nguyen Viet Dung)
Date: Mon,  1 Jul 2013 19:00:09 +0900
Subject: [PATCH 2/4] ARM: shmobile: r8a7790: add I2C setup
In-Reply-To: <1372672810-20609-1-git-send-email-user@jinso.co.jp>
References: <1372672810-20609-1-git-send-email-user@jinso.co.jp>
Message-ID: <1372672810-20609-3-git-send-email-user@jinso.co.jp>

From: Nguyen Viet Dung <nv-dung at jinso.co.jp>

This patch add setup for I2C bus.

Signed-off-by: Nguyen Viet Dung <nv-dung at jinso.co.jp>
---
 arch/arm/mach-shmobile/include/mach/r8a7790.h |    3 +++
 arch/arm/mach-shmobile/setup-r8a7790.c        |   28 +++++++++++++++++++++++++
 2 files changed, 31 insertions(+)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h b/arch/arm/mach-shmobile/include/mach/r8a7790.h
index 2e919e6..85d3567 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7790.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7790.h
@@ -1,7 +1,10 @@
 #ifndef __ASM_R8A7790_H__
 #define __ASM_R8A7790_H__
 
+#include <linux/i2c/i2c-rcar.h>
+
 void r8a7790_add_standard_devices(void);
+void r8a7790_add_i2c_device(int idx, struct i2c_rcar_platform_data *pdata);
 void r8a7790_clock_init(void);
 void r8a7790_pinmux_init(void);
 void r8a7790_timer_init(void);
diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index ed7ee24..0ab912b 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -24,6 +24,7 @@
 #include <linux/serial_sci.h>
 #include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_data/irq-renesas-irqc.h>
+#include <linux/i2c/i2c-rcar.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a7790.h>
@@ -137,6 +138,33 @@ static struct resource irqc0_resources[] = {
 					  &irqc##idx##_data,		\
 					  sizeof(struct renesas_irqc_config))
 
+/* I2C */
+static struct resource rcar_i2c_res[] __initdata = {
+	/* I2C0 */
+	DEFINE_RES_MEM(0xe6508000, 0x10000),
+	DEFINE_RES_IRQ(gic_spi(287)),
+	/* I2C1 */
+	DEFINE_RES_MEM(0xe6518000, 0x10000),
+	DEFINE_RES_IRQ(gic_spi(288)),
+	/* I2C2 */
+	DEFINE_RES_MEM(0xe6530000, 0x10000),
+	DEFINE_RES_IRQ(gic_spi(286)),
+	/* I2C3 */
+	DEFINE_RES_MEM(0xe6540000, 0x10000),
+	DEFINE_RES_IRQ(gic_spi(290)),
+};
+
+void __init r8a7790_add_i2c_device(int idx,
+				   struct i2c_rcar_platform_data *pdata)
+{
+	BUG_ON(idx < 0 || idx > 3);
+
+	platform_device_register_resndata(
+			&platform_bus, "i2c-rcar", idx,
+			rcar_i2c_res + (2*idx), 2,
+			pdata, sizeof(*pdata));
+}
+
 void __init r8a7790_add_standard_devices(void)
 {
 	r8a7790_register_scif(SCIFA0);
-- 
1.7.9.5



From sebastian.hesselbarth at gmail.com  Mon Jul  1 06:50:59 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 01 Jul 2013 12:50:59 +0200
Subject: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver
In-Reply-To: <20130701094258.GT18285@phenom.ffwll.local>
References: <20130629225210.GF3353@n2100.arm.linux.org.uk>
 <E1Ut41C-0000wl-Ff@rmk-PC.arm.linux.org.uk>
 <20130630115941.GG18285@phenom.ffwll.local>
 <20130630125238.GH3353@n2100.arm.linux.org.uk>
 <CAPM=9tydcpP2-A6fnnHB873Nekj4HnxjraZ3TtRG3UF-Bqa6OQ@mail.gmail.com>
 <51D14333.40307@gmail.com> <20130701094258.GT18285@phenom.ffwll.local>
Message-ID: <51D15F13.7040408@gmail.com>

On 07/01/13 11:42, Daniel Vetter wrote:
> On Mon, Jul 01, 2013 at 10:52:03AM +0200, Sebastian Hesselbarth wrote:
>> at least on this point I do share Russell's impression. I've sent
>> bunch of patches improving TDA998x and DRM+DT:
>> - TDA998x irq handling - ignored
>> - TDA998x sync fix - ignored
>> - Fix drm I2C slave encoder probing
>>
>> I am aware that this is not an easy job nor one you get much
>> appreciation for. But, back when TDA998x driver was published,
>> all my comments were basically answered with "Oh, I know. Maybe
>> someday somebody will fix it".
>
> I guess part of the problem here is that in the arm world we don't (yet)
> have many full-blown drivers and not many people to fix up stuff or chime
> in with good review. And sometimes that just means that someone puts down
> his foot and says "this is how we do it" - at least for drm/i915 I
> sometimes have to do that to unblock a massive bikeshed-fest.
>
>> I am not being paid for any of this, but have a strong intrinsic
>> motivation here. But I am loosing interest in sending fixes for
>> DRM stuff because my (personal) impression is the same Russell
>> has: Depending on who sends patches, they get merged independent
>> of how broken they are - others are discussed to death.
>
> Hm, we run fairly extensive QA for drm/i915, and thus far the drm core
> stuff hasn't really blown up badly for us. So can you please point at
> examples where crap was merged and shouldn't have been?

Don't get me wrong, "broken" above didn't mean it doesn't work at all,
but with SoC graphic drivers arising, requirements shift from "some
known implementations" to "you never know what will be combined with
e.g. a specific CRTC". So from that latter point-of-view, I consider
TDA998x for example as broken. It may work with tilcdc in some modes,
but as Darren Etheridge stated, it breaks as soon as you touch TDA998x
driver. At least for that, I confirmed the timings of Russell's driver
and the fixes posted with a scope and a bunch of modes and monitors/tv.

For the timing fix of TDA998x, Darren now is trying to also confirm
every single sync line of tilcdc and I really like to see his Tested-by
on the patch - just because Russell's driver and the CuBox are the only
testbeds I have on this.

> Wrt to bikeshed to death I know that drm folks are a bit prone to that (me
> included), but recently I haven't spotted a case where this happened. ARM
> stuff excluded ofc since I don't follow that too closely. There's also
> that Dave is sometimes a bit swamped, but pinging him on irc about lost
> patches works well (at least for stuff I care about).

Hmm, I understand that it is _very_ time consuming work on your side.
But for me - with limited insight of DRM core - it is not a good starter
to make the API DT aware. The DRM API documentation _is_ limited wrt
intentions of the way it is done.

Of course, I share the idea of true, full-blown of_drm_something
helpers. But the DT patch, is not an improvement but a real fix as in
"make DRM not break on some platforms". From that on, I can start
digging into DRM API and improve DT support here and there.

So for the three patches I mentioned above, they are all minor
improvements of the API. Minor, because I cannot ever sent _the_ single
perfect patch just because I don't know the API well enough, yet.

Just based on my personal experience: TDA998x driver got merged the way 
it is _although_ I addressed some concerns - the fixes are not merged
_although_ I provided experimental results. This is of course
disappointing for me, but I am sure it will work out soon and I will
get back to happily send improvements for the platforms I can test on.

Sebastian


From marex at denx.de  Mon Jul  1 06:54:18 2013
From: marex at denx.de (Marek Vasut)
Date: Mon, 1 Jul 2013 12:54:18 +0200
Subject: [PATCH 1/4] ASoC: sgtl5000: give it a ramping time before writting
In-Reply-To: <20130701100710.GB27646@sirena.org.uk>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>
 <20130701100710.GB27646@sirena.org.uk>
Message-ID: <201307011254.18952.marex@denx.de>

Dear Mark Brown,

> On Mon, Jul 01, 2013 at 04:16:08PM +0800, Shawn Guo wrote:
> > +	/*
> > +	 * It seems that sgtl5000 takes a longer time to get the registers
> > +	 * ready for write than bread.  Let's give it a ramping time before
> > +	 * the first write goes.
> > +	 */
> > +	msleep(50);
> > +
> > 
> >  	/* Ensure sgtl5000 will start with sane register values */
> >  	ret = sgtl5000_fill_defaults(sgtl5000);
> >  	if (ret)
> 
> This seems like a really odd place to add the sleep - I'd have expected
> this to be a part of or just after the reset operation.  It's a *really*
> long sleep too, though if that's what you need that's what you need.

The delay might also be caused by the I2C driver, I have this in my ToDo to 
check, but I didn't get to it yet. On the other hand, if subsequent IO does 
work, then it's unlikely to be the case.

> Also "bread" :)

Of course, sometimes you want to put a lot of things on it, like bacon and such.

Best regards,
Marek Vasut


From LW at KARO-electronics.de  Mon Jul  1 06:57:44 2013
From: LW at KARO-electronics.de (=?utf-8?Q?Lothar_Wa=C3=9Fmann?=)
Date: Mon, 1 Jul 2013 12:57:44 +0200
Subject: [PATCH 1/4] ASoC: sgtl5000: give it a ramping time before writting
In-Reply-To: <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>
Message-ID: <20945.24744.908437.551717@ipc1.ka-ro>

Shawn Guo writes:
> Since commit af8ee11 (ASoC: sgtl5000: Fix driver probe after reset),
> it's very ofen to run into the following probe error on imx28. It is
> caused by the regmap_write() failure in sgtl5000_fill_defaults().
> However, the regmap_read() before this has already been working.  It
> seems that sgtl5000 takes a longer ramping time to get the registers
> ready for write than read.
> 
> [    1.991579] sgtl5000 0-000a: sgtl5000 revision 0x11
> [    2.021655] mxs-sgtl5000 sound.12: ASoC: CODEC (null) not registered
> [    2.039087] mxs-sgtl5000 sound.12: snd_soc_register_card failed (-517)
> [    2.046299] platform sound.12: Driver mxs-sgtl5000 requests probe deferral
> 
> Fix the regression by giving it a ramping time before the first write.
> 
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> ---
>  sound/soc/codecs/sgtl5000.c |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
> index d441559..20bca03 100644
> --- a/sound/soc/codecs/sgtl5000.c
> +++ b/sound/soc/codecs/sgtl5000.c
> @@ -1552,6 +1552,13 @@ static int sgtl5000_i2c_probe(struct i2c_client *client,
>  
>  	i2c_set_clientdata(client, sgtl5000);
>  
> +	/*
> +	 * It seems that sgtl5000 takes a longer time to get the registers
> +	 * ready for write than bread.  Let's give it a ramping time before
                                ^^^^^
>
What sort of bread? ;-)


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________


From alexandre.belloni at free-electrons.com  Mon Jul  1 07:00:23 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Mon, 01 Jul 2013 13:00:23 +0200
Subject: [PATCHv3 5/8] ARM: mxs: dt: cfa10037: make hogpins grabbed by
 respective drivers
In-Reply-To: <20130701090630.GF13206@S2101-09.ap.freescale.net>
References: <1372424577-8279-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1372424577-8279-6-git-send-email-alexandre.belloni@free-electrons.com>
 <20130629070529.GD2593@lukather> <51D058A4.7020101@free-electrons.com>
 <20130701090630.GF13206@S2101-09.ap.freescale.net>
Message-ID: <51D16147.7040509@free-electrons.com>

On 01/07/2013 11:06, Shawn Guo wrote:
> On Sun, Jun 30, 2013 at 06:11:16PM +0200, Alexandre Belloni wrote:
>> Do you want me to send a reordered serie or will you do it when applying
>> the patches ? You can just apply patch 4/8 last.
> 
> Please resend, since you have some comments from Maxime on patch #2
> unresolved? 
> 

Oh right, forgot about that one, sorry. I will send v4.

> Shawn
> 


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From ben.dooks at codethink.co.uk  Mon Jul  1 07:03:59 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon,  1 Jul 2013 12:03:59 +0100
Subject: [PATCH 01/10] ARM: fix ARCH_IXP4xx usage of ARCH_SUPPORTS_BIG_ENDIAN
In-Reply-To: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1372676648-9254-2-git-send-email-ben.dooks@codethink.co.uk>

The Kconfig for arch/arm/mach-ixp4xx has a local definition
of ARCH_SUPPORTS_BIG_ENDIAN which could be used elsewhere.
This means that if IXP4xx is selected and this symbol is
selected eleswhere then an warning is produced.

Clean the following error up by making the symbol be
selected by the main ARCH_IXP4XX definition and have a
common definition in arch/arm/mm/Kconfig

warning: (ARCH_xxx) selects ARCH_SUPPORTS_BIG_ENDIAN which has unmet direct dependencies (ARCH_IXP4XX)
warning: (ARCH_xxx) selects ARCH_SUPPORTS_BIG_ENDIAN which has unmet direct dependencies (ARCH_IXP4XX)

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/Kconfig             |    1 +
 arch/arm/mach-ixp4xx/Kconfig |    4 ----
 arch/arm/mm/Kconfig          |    6 ++++++
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 136f263..0e60b0e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -474,6 +474,7 @@ config ARCH_IXP4XX
 	bool "IXP4xx-based"
 	depends on MMU
 	select ARCH_HAS_DMA_SET_COHERENT_MASK
+	select ARCH_SUPPORTS_BIG_ENDIAN
 	select ARCH_REQUIRE_GPIOLIB
 	select CLKSRC_MMIO
 	select CPU_XSCALE
diff --git a/arch/arm/mach-ixp4xx/Kconfig b/arch/arm/mach-ixp4xx/Kconfig
index 73a2d90..72de05f 100644
--- a/arch/arm/mach-ixp4xx/Kconfig
+++ b/arch/arm/mach-ixp4xx/Kconfig
@@ -1,9 +1,5 @@
 if ARCH_IXP4XX
 
-config ARCH_SUPPORTS_BIG_ENDIAN
-	bool
-	default y
-
 menu "Intel IXP4xx Implementation Options"
 
 comment "IXP4xx Platforms"
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 35955b5..b83782e 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -895,3 +895,9 @@ config ARCH_HAS_BARRIERS
 	help
 	  This option allows the use of custom mandatory barriers
 	  included via the mach/barriers.h file.
+
+config ARCH_SUPPORTS_BIG_ENDIAN
+	bool
+	help
+	  This option specifies the architecture can support big endian
+	  operation.
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Mon Jul  1 07:03:58 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon,  1 Jul 2013 12:03:58 +0100
Subject: v3.10 - big endian core support
Message-ID: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>

The latest big-endian changes, now on:

	git://git.baserock.org/delta/linux baserock/311/be/core

This has a minor fix from the last version where a rebase missed a change
in the smp_scu code.



From ben.dooks at codethink.co.uk  Mon Jul  1 07:04:00 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon,  1 Jul 2013 12:04:00 +0100
Subject: [PATCH 02/10] ARM: asm: Add ARM_BE8() assembly helper
In-Reply-To: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1372676648-9254-3-git-send-email-ben.dooks@codethink.co.uk>

Add ARM_BE8() helper to wrap any code conditional on being
compile when CONFIG_ARM_ENDIAN_BE8 is selected and convert
existing places where this is to use it.

Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/boot/compressed/head.S  |    8 ++------
 arch/arm/include/asm/assembler.h |    7 +++++++
 arch/arm/kernel/entry-armv.S     |    5 ++---
 arch/arm/kernel/entry-common.S   |    4 +---
 arch/arm/mm/abort-ev6.S          |    5 ++---
 arch/arm/mm/proc-v6.S            |    4 +---
 arch/arm/mm/proc-v7.S            |    4 +---
 7 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 032a8d9..4eb8364 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -679,9 +679,7 @@ __armv4_mmu_cache_on:
 		mrc	p15, 0, r0, c1, c0, 0	@ read control reg
 		orr	r0, r0, #0x5000		@ I-cache enable, RR cache replacement
 		orr	r0, r0, #0x0030
-#ifdef CONFIG_CPU_ENDIAN_BE8
-		orr	r0, r0, #1 << 25	@ big-endian page tables
-#endif
+ ARM_BE8(	orr	r0, r0, #1 << 25 )	@ big-endian page tables
 		bl	__common_mmu_cache_on
 		mov	r0, #0
 		mcr	p15, 0, r0, c8, c7, 0	@ flush I,D TLBs
@@ -708,9 +706,7 @@ __armv7_mmu_cache_on:
 		orr	r0, r0, #1 << 22	@ U (v6 unaligned access model)
 						@ (needed for ARM1176)
 #ifdef CONFIG_MMU
-#ifdef CONFIG_CPU_ENDIAN_BE8
-		orr	r0, r0, #1 << 25	@ big-endian page tables
-#endif
+ ARM_BE8(	orr	r0, r0, #1 << 25 )	@ big-endian page tables
 		mrcne   p15, 0, r6, c2, c0, 2   @ read ttb control reg
 		orrne	r0, r0, #1		@ MMU enabled
 		movne	r1, #0xfffffffd		@ domain 0 = client
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 05ee9ee..e780afb 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -53,6 +53,13 @@
 #define put_byte_3      lsl #0
 #endif
 
+/* Select code for any configuration running in BE8 mode */
+#ifdef CONFIG_CPU_ENDIAN_BE8
+#define ARM_BE8(code...) code
+#else
+#define ARM_BE8(code...)
+#endif
+
 /*
  * Data preload for architectures that support it
  */
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 582b405..09130e2 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -415,9 +415,8 @@ __und_usr:
 	bne	__und_usr_thumb
 	sub	r4, r2, #4			@ ARM instr at LR - 4
 1:	ldrt	r0, [r4]
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	rev	r0, r0				@ little endian instruction
-#endif
+ ARM_BE8(rev	r0, r0)				@ little endian instruction
+
 	@ r0 = 32-bit ARM instruction which caused the exception
 	@ r2 = PC value for the following instruction (:= regs->ARM_pc)
 	@ r4 = PC value for the faulting instruction
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index bc5bc0a..8c79344 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -379,9 +379,7 @@ ENTRY(vector_swi)
 #else
 	ldr	r10, [lr, #-4]			@ get SWI instruction
 #endif
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	rev	r10, r10			@ little endian instruction
-#endif
+ ARM_BE8(rev	r10, r10)			@ little endian instruction
 
 #elif defined(CONFIG_AEABI)
 
diff --git a/arch/arm/mm/abort-ev6.S b/arch/arm/mm/abort-ev6.S
index 8074199..3815a82 100644
--- a/arch/arm/mm/abort-ev6.S
+++ b/arch/arm/mm/abort-ev6.S
@@ -38,9 +38,8 @@ ENTRY(v6_early_abort)
 	bne	do_DataAbort
 	bic	r1, r1, #1 << 11		@ clear bit 11 of FSR
 	ldr	r3, [r4]			@ read aborted ARM instruction
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	rev	r3, r3
-#endif
+ ARM_BE8(rev	r3, r3)
+
 	do_ldrd_abort tmp=ip, insn=r3
 	tst	r3, #1 << 20			@ L = 0 -> write
 	orreq	r1, r1, #1 << 11		@ yes.
diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
index 919405e..f2e43e8 100644
--- a/arch/arm/mm/proc-v6.S
+++ b/arch/arm/mm/proc-v6.S
@@ -218,9 +218,7 @@ __v6_setup:
 #endif /* CONFIG_MMU */
 	adr	r5, v6_crval
 	ldmia	r5, {r5, r6}
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	orr	r6, r6, #1 << 25		@ big-endian page tables
-#endif
+ ARM_BE8(orr	r6, r6, #1 << 25)		@ big-endian page tables
 	mrc	p15, 0, r0, c1, c0, 0		@ read control register
 	bic	r0, r0, r5			@ clear bits them
 	orr	r0, r0, r6			@ set them
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index e35fec3..8338ba4 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -351,9 +351,7 @@ __v7_setup:
 #endif
 	adr	r5, v7_crval
 	ldmia	r5, {r5, r6}
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	orr	r6, r6, #1 << 25		@ big-endian page tables
-#endif
+ ARM_BE8(orr	r6, r6, #1 << 25)		@ big-endian page tables
 #ifdef CONFIG_SWP_EMULATE
 	orr     r5, r5, #(1 << 10)              @ set SW bit in "clear"
 	bic     r6, r6, #(1 << 10)              @ clear it in "mmuset"
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Mon Jul  1 07:04:02 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon,  1 Jul 2013 12:04:02 +0100
Subject: [PATCH 04/10] ARM: set BE8 if LE in head code
In-Reply-To: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1372676648-9254-5-git-send-email-ben.dooks@codethink.co.uk>

If we are booting in LE and compiled for BE8, then add code to
set the state to bE8. Since the instruction stream is always LE,
we do not need to do anything special to the instruction.

Also ensure that the secondary processors are started in the same mode.

Note, we do add about 20 bytes to the kernel image, but it seems easier
to do this than adding another configuration to change.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/boot/compressed/head.S |    1 +
 arch/arm/kernel/head.S          |    4 ++++
 arch/arm/kernel/sleep.S         |    1 +
 3 files changed, 6 insertions(+)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 4eb8364..4d83bfd 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -135,6 +135,7 @@ start:
 		.word	_edata			@ zImage end address
  THUMB(		.thumb			)
 1:
+ ARM_BE8(	setend	be )			@ go BE8 if LE, no-op if BE8
 		mrs	r9, cpsr
 #ifdef CONFIG_ARM_VIRT_EXT
 		bl	__hyp_stub_install	@ get into SVC mode, reversibly
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 56ddd47..da09dc0 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -77,6 +77,7 @@
 
 	__HEAD
 ENTRY(stext)
+ ARM_BE8(setend	be )			@ ensure we are in BE8 mode
 
  THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is always entered in ARM.
  THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
@@ -351,6 +352,9 @@ ENTRY(secondary_startup)
 	 * the processor type - there is no need to check the machine type
 	 * as it has already been validated by the primary processor.
 	 */
+
+ ARM_BE8(setend	be)				@ if system starts LE, go BE8
+
 #ifdef CONFIG_ARM_VIRT_EXT
 	bl	__hyp_stub_install_secondary
 #endif
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 987dcf3..954c28a 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -81,6 +81,7 @@ ENDPROC(cpu_resume_after_mmu)
 	.data
 	.align
 ENTRY(cpu_resume)
+ARM_BE8(setend be)			@ ensure we are in BE mode
 #ifdef CONFIG_SMP
 	adr	r0, sleep_save_sp
 	ALT_SMP(mrc p15, 0, r1, c0, c0, 5)
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Mon Jul  1 07:04:01 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon,  1 Jul 2013 12:04:01 +0100
Subject: [PATCH 03/10] ARM: fixup_pv_table bug when CPU_ENDIAN_BE8
In-Reply-To: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1372676648-9254-4-git-send-email-ben.dooks@codethink.co.uk>

The fixup_pv_table assumes that the instructions are in the same
endian configuration as the data, but when the CPU is running in
BE8 the instructions stay in little-endian format.

Make sure if CONFIG_CPU_ENDIAN_BE8 is set that we do all the
alterations to the instructions taking in to account the LDR/STR
will be swapping the data endian-ness.

Since the code is only modifying a byte, we avoid dual-swapping
the data, and just change the bits we clear and ORR in.

Note, not tested against an actual bug, it looked wrong.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/kernel/head.S |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 8bac553..56ddd47 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -594,8 +594,14 @@ __fixup_a_pv_table:
 #else
 	b	2f
 1:	ldr	ip, [r7, r3]
+#ifdef CONFIG_CPU_ENDIAN_BE8
+	@ in BE8, we load data in BE, but instructions still in LE
+	bic	ip, ip, #0xff000000
+	orr	ip, ip, r6, lsl#24
+#else
 	bic	ip, ip, #0x000000ff
 	orr	ip, ip, r6	@ mask in offset bits 31-24
+#endif
 	str	ip, [r7, r3]
 2:	cmp	r4, r5
 	ldrcc	r7, [r4], #4	@ use branch for delay slot
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Mon Jul  1 07:04:06 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon,  1 Jul 2013 12:04:06 +0100
Subject: [PATCH 08/10] highbank: enable big-endian
In-Reply-To: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1372676648-9254-9-git-send-email-ben.dooks@codethink.co.uk>

Apart from a xgmac driver issue, the highbank seems to work correctly in
big-endian mode. Allow the selection of big-endian in the system.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/mach-highbank/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
index cd9fcb1..4f57554 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -18,3 +18,4 @@ config ARCH_HIGHBANK
 	select PL320_MBOX
 	select SPARSE_IRQ
 	select USE_OF
+	select ARCH_SUPPORTS_BIG_ENDIAN
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Mon Jul  1 07:04:03 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon,  1 Jul 2013 12:04:03 +0100
Subject: [PATCH 05/10] ARM: pl01x debug code endian fix
In-Reply-To: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1372676648-9254-6-git-send-email-ben.dooks@codethink.co.uk>

The PL01X debug code needs to take into account which endian mode the
processor is running in. If it is big-endian, ensure the data is swapped
appropriately.

Note, we could do this slightly more efficiently if we have an macro to
do the necessary swap for the bits used by test.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/include/asm/hardware/debug-pl01x.S |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/hardware/debug-pl01x.S b/arch/arm/include/asm/hardware/debug-pl01x.S
index f9fd083..6489d1f 100644
--- a/arch/arm/include/asm/hardware/debug-pl01x.S
+++ b/arch/arm/include/asm/hardware/debug-pl01x.S
@@ -18,12 +18,14 @@
 
 		.macro	waituart,rd,rx
 1001:		ldr	\rd, [\rx, #UART01x_FR]
+ ARM_BE8(	rev	\rd, \rd )
 		tst	\rd, #UART01x_FR_TXFF
 		bne	1001b
 		.endm
 
 		.macro	busyuart,rd,rx
 1001:		ldr	\rd, [\rx, #UART01x_FR]
+ ARM_BE8(	rev	\rd, \rd )
 		tst	\rd, #UART01x_FR_BUSY
 		bne	1001b
 		.endm
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Mon Jul  1 07:04:08 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon,  1 Jul 2013 12:04:08 +0100
Subject: [PATCH 10/10] vexpress: add big endian support
In-Reply-To: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1372676648-9254-11-git-send-email-ben.dooks@codethink.co.uk>

Add support for the versatile express systems to boot big-endian.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/mach-vexpress/Kconfig    |    1 +
 arch/arm/plat-versatile/headsmp.S |    2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 5907e10..fa69d4e 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -1,6 +1,7 @@
 config ARCH_VEXPRESS
 	bool "ARM Ltd. Versatile Express family" if ARCH_MULTI_V7
 	select ARCH_REQUIRE_GPIOLIB
+	select ARCH_SUPPORTS_BIG_ENDIAN
 	select ARM_AMBA
 	select ARM_GIC
 	select ARM_TIMER_SP804
diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S
index b178d44..4c5c8ca 100644
--- a/arch/arm/plat-versatile/headsmp.S
+++ b/arch/arm/plat-versatile/headsmp.S
@@ -10,6 +10,7 @@
  */
 #include <linux/linkage.h>
 #include <linux/init.h>
+#include <asm/assembler.h>
 
 	__INIT
 
@@ -19,6 +20,7 @@
  * until we're ready for them to initialise.
  */
 ENTRY(versatile_secondary_startup)
+ ARM_BE8(setend	be)
 	mrc	p15, 0, r0, c0, c0, 5
 	bic	r0, #0xff000000
 	adr	r4, 1f
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Mon Jul  1 07:04:05 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon,  1 Jul 2013 12:04:05 +0100
Subject: [PATCH 07/10] ARM: smp_scu: data endian fixes
In-Reply-To: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1372676648-9254-8-git-send-email-ben.dooks@codethink.co.uk>

The smp_scu driver needs to use the relaxed readl/write accessors
to avoid any issues with the endian mode the processor core is in.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/kernel/smp_scu.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
index 5bc1a63..1aafa0d 100644
--- a/arch/arm/kernel/smp_scu.c
+++ b/arch/arm/kernel/smp_scu.c
@@ -28,7 +28,7 @@
  */
 unsigned int __init scu_get_core_count(void __iomem *scu_base)
 {
-	unsigned int ncores = __raw_readl(scu_base + SCU_CONFIG);
+	unsigned int ncores = readl_relaxed(scu_base + SCU_CONFIG);
 	return (ncores & 0x03) + 1;
 }
 
@@ -42,19 +42,19 @@ void scu_enable(void __iomem *scu_base)
 #ifdef CONFIG_ARM_ERRATA_764369
 	/* Cortex-A9 only */
 	if ((read_cpuid_id() & 0xff0ffff0) == 0x410fc090) {
-		scu_ctrl = __raw_readl(scu_base + 0x30);
+		scu_ctrl = readl_relaxed(scu_base + 0x30);
 		if (!(scu_ctrl & 1))
-			__raw_writel(scu_ctrl | 0x1, scu_base + 0x30);
+			writel_relaxed(scu_ctrl | 0x1, scu_base + 0x30);
 	}
 #endif
 
-	scu_ctrl = __raw_readl(scu_base + SCU_CTRL);
+	scu_ctrl = readl_relaxed(scu_base + SCU_CTRL);
 	/* already enabled? */
 	if (scu_ctrl & 1)
 		return;
 
 	scu_ctrl |= 1;
-	__raw_writel(scu_ctrl, scu_base + SCU_CTRL);
+	writel_relaxed(scu_ctrl, scu_base + SCU_CTRL);
 
 	/*
 	 * Ensure that the data accessed by CPU0 before the SCU was
@@ -80,9 +80,9 @@ int scu_power_mode(void __iomem *scu_base, unsigned int mode)
 	if (mode > 3 || mode == 1 || cpu > 3)
 		return -EINVAL;
 
-	val = __raw_readb(scu_base + SCU_CPU_STATUS + cpu) & ~0x03;
+	val = readb_relaxed(scu_base + SCU_CPU_STATUS + cpu) & ~0x03;
 	val |= mode;
-	__raw_writeb(val, scu_base + SCU_CPU_STATUS + cpu);
+	writeb_relaxed(val, scu_base + SCU_CPU_STATUS + cpu);
 
 	return 0;
 }
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Mon Jul  1 07:04:07 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon,  1 Jul 2013 12:04:07 +0100
Subject: [PATCH 09/10] mvebu: support running big-endian
In-Reply-To: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1372676648-9254-10-git-send-email-ben.dooks@codethink.co.uk>

Add indication we can run these cores in BE mode, and ensure that the
secondary CPU is set to big-endian mode in the initialisation code as
the initial code runs little-endian.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/mach-mvebu/Kconfig        |    1 +
 arch/arm/mach-mvebu/coherency_ll.S |    3 +++
 arch/arm/mach-mvebu/headsmp.S      |    4 ++++
 3 files changed, 8 insertions(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 80a8bca..317cdb8 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -1,5 +1,6 @@
 config ARCH_MVEBU
 	bool "Marvell SOCs with Device Tree support" if ARCH_MULTI_V7
+	select ARCH_SUPPORTS_BIG_ENDIAN
 	select CLKSRC_MMIO
 	select COMMON_CLK
 	select GENERIC_CLOCKEVENTS
diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
index 5476669..ee7598f 100644
--- a/arch/arm/mach-mvebu/coherency_ll.S
+++ b/arch/arm/mach-mvebu/coherency_ll.S
@@ -20,6 +20,8 @@
 #define ARMADA_XP_CFB_CTL_REG_OFFSET 0x0
 #define ARMADA_XP_CFB_CFG_REG_OFFSET 0x4
 
+#include <asm/assembler.h>
+
 	.text
 /*
  * r0: Coherency fabric base register address
@@ -29,6 +31,7 @@ ENTRY(ll_set_cpu_coherent)
 	/* Create bit by cpu index */
 	mov	r3, #(1 << 24)
 	lsl	r1, r3, r1
+ARM_BE8(rev	r1, r1)
 
 	/* Add CPU to SMP group - Atomic */
 	add	r3, r0, #ARMADA_XP_CFB_CTL_REG_OFFSET
diff --git a/arch/arm/mach-mvebu/headsmp.S b/arch/arm/mach-mvebu/headsmp.S
index a06e0ed..a4f995d 100644
--- a/arch/arm/mach-mvebu/headsmp.S
+++ b/arch/arm/mach-mvebu/headsmp.S
@@ -21,6 +21,8 @@
 #include <linux/linkage.h>
 #include <linux/init.h>
 
+#include <asm/assembler.h>
+
 /*
  * At this stage the secondary CPUs don't have acces yet to the MMU, so
  * we have to provide physical addresses
@@ -36,6 +38,8 @@
  */
 ENTRY(armada_xp_secondary_startup)
 
+ ARM_BE8(setend	be )			@ go BE8 if booted LE
+
 	/* Read CPU id */
 	mrc     p15, 0, r1, c0, c0, 5
 	and     r1, r1, #0xF
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Mon Jul  1 07:04:04 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon,  1 Jul 2013 12:04:04 +0100
Subject: [PATCH 06/10] ARM: twd: data endian fix
In-Reply-To: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1372676648-9254-7-git-send-email-ben.dooks@codethink.co.uk>

Ensure the twd driver uses the correct calls to access the hardware
to ensure that we do not end up with data in the wrong endian format.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/kernel/smp_twd.c |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 90525d9..804d3f8 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -45,7 +45,7 @@ static void twd_set_mode(enum clock_event_mode mode,
 	case CLOCK_EVT_MODE_PERIODIC:
 		ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE
 			| TWD_TIMER_CONTROL_PERIODIC;
-		__raw_writel(DIV_ROUND_CLOSEST(twd_timer_rate, HZ),
+		writel_relaxed(DIV_ROUND_CLOSEST(twd_timer_rate, HZ),
 			twd_base + TWD_TIMER_LOAD);
 		break;
 	case CLOCK_EVT_MODE_ONESHOT:
@@ -58,18 +58,18 @@ static void twd_set_mode(enum clock_event_mode mode,
 		ctrl = 0;
 	}
 
-	__raw_writel(ctrl, twd_base + TWD_TIMER_CONTROL);
+	writel_relaxed(ctrl, twd_base + TWD_TIMER_CONTROL);
 }
 
 static int twd_set_next_event(unsigned long evt,
 			struct clock_event_device *unused)
 {
-	unsigned long ctrl = __raw_readl(twd_base + TWD_TIMER_CONTROL);
+	unsigned long ctrl = readl_relaxed(twd_base + TWD_TIMER_CONTROL);
 
 	ctrl |= TWD_TIMER_CONTROL_ENABLE;
 
-	__raw_writel(evt, twd_base + TWD_TIMER_COUNTER);
-	__raw_writel(ctrl, twd_base + TWD_TIMER_CONTROL);
+	writel_relaxed(evt, twd_base + TWD_TIMER_COUNTER);
+	writel_relaxed(ctrl, twd_base + TWD_TIMER_CONTROL);
 
 	return 0;
 }
@@ -82,8 +82,8 @@ static int twd_set_next_event(unsigned long evt,
  */
 static int twd_timer_ack(void)
 {
-	if (__raw_readl(twd_base + TWD_TIMER_INTSTAT)) {
-		__raw_writel(1, twd_base + TWD_TIMER_INTSTAT);
+	if (readl_relaxed(twd_base + TWD_TIMER_INTSTAT)) {
+		writel_relaxed(1, twd_base + TWD_TIMER_INTSTAT);
 		return 1;
 	}
 
@@ -209,15 +209,15 @@ static void __cpuinit twd_calibrate_rate(void)
 		waitjiffies += 5;
 
 				 /* enable, no interrupt or reload */
-		__raw_writel(0x1, twd_base + TWD_TIMER_CONTROL);
+		writel_relaxed(0x1, twd_base + TWD_TIMER_CONTROL);
 
 				 /* maximum value */
-		__raw_writel(0xFFFFFFFFU, twd_base + TWD_TIMER_COUNTER);
+		writel_relaxed(0xFFFFFFFFU, twd_base + TWD_TIMER_COUNTER);
 
 		while (get_jiffies_64() < waitjiffies)
 			udelay(10);
 
-		count = __raw_readl(twd_base + TWD_TIMER_COUNTER);
+		count = readl_relaxed(twd_base + TWD_TIMER_COUNTER);
 
 		twd_timer_rate = (0xFFFFFFFFU - count) * (HZ / 5);
 
@@ -275,7 +275,7 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
 	 * bother with the below.
 	 */
 	if (per_cpu(percpu_setup_called, cpu)) {
-		__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
+		writel_relaxed(0, twd_base + TWD_TIMER_CONTROL);
 		clockevents_register_device(*__this_cpu_ptr(twd_evt));
 		enable_percpu_irq(clk->irq, 0);
 		return 0;
@@ -288,7 +288,7 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
 	 * The following is done once per CPU the first time .setup() is
 	 * called.
 	 */
-	__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
+	writel_relaxed(0, twd_base + TWD_TIMER_CONTROL);
 
 	clk->name = "local_timer";
 	clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT |
-- 
1.7.10.4



From girish.shivananjappa at linaro.org  Mon Jul  1 07:27:35 2013
From: girish.shivananjappa at linaro.org (Girish K S)
Date: Mon, 1 Jul 2013 16:57:35 +0530
Subject: [v2 4/4] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <1372672975-2997-5-git-send-email-r65037@freescale.com>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-5-git-send-email-r65037@freescale.com>
Message-ID: <CAGxe1ZEHWQUXmjgmGGkpy3wgxoS8ti0-eYZPHkQKzjD9pWqZ0Q@mail.gmail.com>

Hello Richard,

Instead of writing a separate driver for the changes you mentioned in
the commit message. you can just add those changes to
the platform data (pdata-> init).

On 1 July 2013 15:32, Richard Zhu <richard.zhuhongxing at gmail.com> wrote:
> imx6q contains one Synopsys AHCI SATA controller,
> But it can't shares ahci_platform driver with other
> controllers.
> Because there are some misalignments of the bits
> definitions of the HBA registers and the Vendor
> Specific registers
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>  value is '0', should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the
>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>  should be configured regarding to the frequency of AHB
>  bus clock.
>
> Setup its own ahci sata driver, enable the imx6q ahci
> sata support, and update the ahci sata binding document.
>
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  .../devicetree/bindings/ata/ahci-platform.txt      |    2 +-
>  drivers/ata/Kconfig                                |    8 +
>  drivers/ata/Makefile                               |    1 +
>  drivers/ata/sata_imx.c                             |  349 ++++++++++++++++++++
>  4 files changed, 359 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/ata/sata_imx.c
>
> diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
> index b519f9b..e252620 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
> +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
> @@ -4,7 +4,7 @@ SATA nodes are defined to describe on-chip Serial ATA controllers.
>  Each SATA controller should have its own node.
>
>  Required properties:
> -- compatible        : compatible list, contains "calxeda,hb-ahci" or "snps,spear-ahci"
> +- compatible        : compatible list, contains "calxeda,hb-ahci", "snps,spear-ahci" or "snps, imx-ahci"
>  - interrupts        : <interrupt mapping for SATA IRQ>
>  - reg               : <registers mapping>
>
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index a5a3ebc..893fa0b 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -236,6 +236,14 @@ config SATA_HIGHBANK
>
>           If unsure, say N.
>
> +config SATA_IMX
> +       tristate "Freescale iMX AHCI SATA support"
> +       help
> +         This option enables support for the Freescale iMX SoC's
> +         onboard AHCI SATA.
> +
> +         If unsure, say N.
> +
>  config SATA_MV
>         tristate "Marvell SATA support"
>         help
> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
> index c04d0fd..c40b328 100644
> --- a/drivers/ata/Makefile
> +++ b/drivers/ata/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_SATA_INIC162X)   += sata_inic162x.o
>  obj-$(CONFIG_SATA_SIL24)       += sata_sil24.o
>  obj-$(CONFIG_SATA_DWC)         += sata_dwc_460ex.o
>  obj-$(CONFIG_SATA_HIGHBANK)    += sata_highbank.o libahci.o
> +obj-$(CONFIG_SATA_IMX)         += sata_imx.o libahci.o
>
>  # SFF w/ custom DMA
>  obj-$(CONFIG_PDC_ADMA)         += pdc_adma.o
> diff --git a/drivers/ata/sata_imx.c b/drivers/ata/sata_imx.c
> new file mode 100644
> index 0000000..2be92e8
> --- /dev/null
> +++ b/drivers/ata/sata_imx.c
> @@ -0,0 +1,349 @@
> +/*
> + * Freescale IMX AHCI SATA platform driver
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * based on the AHCI SATA platform driver by Jeff Garzik and Anton Vorontsov
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/kernel.h>
> +#include <linux/gfp.h>
> +#include <linux/module.h>
> +#include <linux/pm.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/device.h>
> +#include <linux/platform_device.h>
> +#include <linux/libata.h>
> +#include <linux/ahci_platform.h>
> +#include "ahci.h"
> +
> +enum {
> +       HOST_TIMER1MS = 0xe0, /* Timer 1-ms */
> +};
> +
> +static void ahci_imx_host_stop(struct ata_host *host);
> +
> +static struct ata_port_operations ahci_imx_platform_ops = {
> +       .inherits       = &ahci_ops,
> +       .host_stop      = ahci_imx_host_stop,
> +};
> +
> +static const struct ata_port_info ahci_imx_port_info = {
> +       .flags          = AHCI_FLAG_COMMON,
> +       .pio_mask       = ATA_PIO4,
> +       .udma_mask      = ATA_UDMA6,
> +       .port_ops       = &ahci_imx_platform_ops,
> +};
> +
> +static struct scsi_host_template ahci_imx_platform_sht = {
> +       AHCI_SHT("sata_imx"),
> +};
> +
> +/*
> + * Configure the HWINIT bits of the HOST_CAP and HOST_PORTS_IMPL,
> + * and IP vendor specific register HOST_TIMER1MS.
> + *
> + * Configure CAP_SSS (support stagered spin up).
> + * Implement the port0.
> + * Get the ahb clock rate, and configure the TIMER1MS register.
> + */
> +static int imx_sata_init(void __iomem *mmio)
> +{
> +       int ret;
> +       struct clk *ahb_clk;
> +
> +       ret = readl(mmio + HOST_CAP);
> +       if (!(ret & HOST_CAP_SSS))
> +               writel(ret |= HOST_CAP_SSS, mmio + HOST_CAP);
> +       ret = readl(mmio + HOST_PORTS_IMPL);
> +       if (!(ret & 0x1))
> +               writel((ret | 0x1), mmio + HOST_PORTS_IMPL);
> +       ahb_clk = clk_get_sys(NULL, "ahb");
> +       if (IS_ERR(ahb_clk)) {
> +               pr_err("no ahb clock.\n");
> +               ret = PTR_ERR(ahb_clk);
> +               return ret;
> +       }
> +       ret = clk_get_rate(ahb_clk) / 1000;
> +       clk_put(ahb_clk);
> +       writel(ret, mmio + HOST_TIMER1MS);
> +
> +       return ret;
> +}
> +
> +static int ahci_imx_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct ahci_platform_data *pdata = dev_get_platdata(dev);
> +       struct ata_port_info pi = ahci_imx_port_info;
> +       const struct ata_port_info *ppi[] = { &pi, NULL };
> +       struct ahci_host_priv *hpriv;
> +       struct ata_host *host;
> +       struct resource *mem;
> +       int irq;
> +       int n_ports;
> +       int i;
> +       int rc;
> +
> +       mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       if (!mem) {
> +               dev_err(dev, "no mmio space\n");
> +               return -EINVAL;
> +       }
> +
> +       irq = platform_get_irq(pdev, 0);
> +       if (irq <= 0) {
> +               dev_err(dev, "no irq\n");
> +               return -EINVAL;
> +       }
> +
> +       if (pdata && pdata->ata_port_info)
> +               pi = *pdata->ata_port_info;
> +
> +       hpriv = devm_kzalloc(dev, sizeof(*hpriv), GFP_KERNEL);
> +       if (!hpriv) {
> +               dev_err(dev, "can't alloc ahci_host_priv\n");
> +               return -ENOMEM;
> +       }
> +
> +       hpriv->flags |= (unsigned long)pi.private_data;
> +
> +       hpriv->mmio = devm_ioremap(dev, mem->start, resource_size(mem));
> +       if (!hpriv->mmio) {
> +               dev_err(dev, "can't map %pR\n", mem);
> +               return -ENOMEM;
> +       }
> +
> +       hpriv->clk = clk_get(dev, NULL);
> +       if (IS_ERR(hpriv->clk)) {
> +               dev_err(dev, "can't get clock\n");
> +       } else {
> +               rc = clk_prepare_enable(hpriv->clk);
> +               if (rc) {
> +                       dev_err(dev, "clock prepare enable failed");
> +                       goto free_clk;
> +               }
> +       }
> +
> +       /*
> +        * Some platforms might need to prepare for mmio region access,
> +        * which could be done in the following init call. So, the mmio
> +        * region shouldn't be accessed before init (if provided) has
> +        * returned successfully.
> +        */
> +       if (pdata && pdata->init) {
> +               rc = pdata->init(dev, hpriv->mmio);
> +               if (rc)
> +                       goto disable_unprepare_clk;
> +       }
> +
> +       rc = imx_sata_init(hpriv->mmio);
> +       if (rc < 0)
> +               goto pdata_exit;
> +
> +       ahci_save_initial_config(dev, hpriv,
> +               pdata ? pdata->force_port_map : 0,
> +               pdata ? pdata->mask_port_map  : 0);
> +
> +       /* prepare host */
> +       if (hpriv->cap & HOST_CAP_NCQ)
> +               pi.flags |= ATA_FLAG_NCQ;
> +
> +       if (hpriv->cap & HOST_CAP_PMP)
> +               pi.flags |= ATA_FLAG_PMP;
> +
> +       ahci_set_em_messages(hpriv, &pi);
> +
> +       /* CAP.NP sometimes indicate the index of the last enabled
> +        * port, at other times, that of the last possible port, so
> +        * determining the maximum port number requires looking at
> +        * both CAP.NP and port_map.
> +        */
> +       n_ports = max(ahci_nr_ports(hpriv->cap), fls(hpriv->port_map));
> +
> +       host = ata_host_alloc_pinfo(dev, ppi, n_ports);
> +       if (!host) {
> +               rc = -ENOMEM;
> +               goto pdata_exit;
> +       }
> +
> +       host->private_data = hpriv;
> +
> +       if (!(hpriv->cap & HOST_CAP_SSS) || ahci_ignore_sss)
> +               host->flags |= ATA_HOST_PARALLEL_SCAN;
> +       else
> +               dev_info(dev, "ahci: SSS flag set, parallel bus scan disabled\n");
> +
> +       if (pi.flags & ATA_FLAG_EM)
> +               ahci_reset_em(host);
> +
> +       for (i = 0; i < host->n_ports; i++) {
> +               struct ata_port *ap = host->ports[i];
> +
> +               ata_port_desc(ap, "mmio %pR", mem);
> +               ata_port_desc(ap, "port 0x%x", 0x100 + ap->port_no * 0x80);
> +
> +               /* set enclosure management message type */
> +               if (ap->flags & ATA_FLAG_EM)
> +                       ap->em_message_type = hpriv->em_msg_type;
> +
> +               /* disabled/not-implemented port */
> +               if (!(hpriv->port_map & (1 << i)))
> +                       ap->ops = &ata_dummy_port_ops;
> +       }
> +
> +       rc = ahci_reset_controller(host);
> +       if (rc)
> +               goto pdata_exit;
> +
> +       ahci_init_controller(host);
> +       ahci_print_info(host, "platform");
> +
> +       rc = ata_host_activate(host, irq, ahci_interrupt, IRQF_SHARED,
> +                              &ahci_imx_platform_sht);
> +       if (rc)
> +               goto pdata_exit;
> +
> +       return 0;
> +pdata_exit:
> +       if (pdata && pdata->exit)
> +               pdata->exit(dev);
> +disable_unprepare_clk:
> +       if (!IS_ERR(hpriv->clk))
> +               clk_disable_unprepare(hpriv->clk);
> +free_clk:
> +       if (!IS_ERR(hpriv->clk))
> +               clk_put(hpriv->clk);
> +       return rc;
> +}
> +
> +static void ahci_imx_host_stop(struct ata_host *host)
> +{
> +       struct device *dev = host->dev;
> +       struct ahci_platform_data *pdata = dev_get_platdata(dev);
> +       struct ahci_host_priv *hpriv = host->private_data;
> +
> +       if (pdata && pdata->exit)
> +               pdata->exit(dev);
> +
> +       if (!IS_ERR(hpriv->clk)) {
> +               clk_disable_unprepare(hpriv->clk);
> +               clk_put(hpriv->clk);
> +       }
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int ahci_imx_suspend(struct device *dev)
> +{
> +       struct ahci_platform_data *pdata = dev_get_platdata(dev);
> +       struct ata_host *host = dev_get_drvdata(dev);
> +       struct ahci_host_priv *hpriv = host->private_data;
> +       void __iomem *mmio = hpriv->mmio;
> +       u32 ctl;
> +       int rc;
> +
> +       if (hpriv->flags & AHCI_HFLAG_NO_SUSPEND) {
> +               dev_err(dev, "firmware update required for suspend/resume\n");
> +               return -EIO;
> +       }
> +
> +       /*
> +        * AHCI spec rev1.1 section 8.3.3:
> +        * Software must disable interrupts prior to requesting a
> +        * transition of the HBA to D3 state.
> +        */
> +       ctl = readl(mmio + HOST_CTL);
> +       ctl &= ~HOST_IRQ_EN;
> +       writel(ctl, mmio + HOST_CTL);
> +       readl(mmio + HOST_CTL); /* flush */
> +
> +       rc = ata_host_suspend(host, PMSG_SUSPEND);
> +       if (rc)
> +               return rc;
> +
> +       if (pdata && pdata->suspend)
> +               return pdata->suspend(dev);
> +
> +       if (!IS_ERR(hpriv->clk))
> +               clk_disable_unprepare(hpriv->clk);
> +
> +       return 0;
> +}
> +
> +static int ahci_imx_resume(struct device *dev)
> +{
> +       struct ahci_platform_data *pdata = dev_get_platdata(dev);
> +       struct ata_host *host = dev_get_drvdata(dev);
> +       struct ahci_host_priv *hpriv = host->private_data;
> +       int rc;
> +
> +       if (!IS_ERR(hpriv->clk)) {
> +               rc = clk_prepare_enable(hpriv->clk);
> +               if (rc) {
> +                       dev_err(dev, "clock prepare enable failed");
> +                       return rc;
> +               }
> +       }
> +
> +       if (pdata && pdata->resume) {
> +               rc = pdata->resume(dev);
> +               if (rc)
> +                       goto disable_unprepare_clk;
> +       }
> +
> +       if (dev->power.power_state.event == PM_EVENT_SUSPEND) {
> +               rc = ahci_reset_controller(host);
> +               if (rc)
> +                       goto disable_unprepare_clk;
> +
> +               ahci_init_controller(host);
> +       }
> +
> +       ata_host_resume(host);
> +
> +       return 0;
> +
> +disable_unprepare_clk:
> +       if (!IS_ERR(hpriv->clk))
> +               clk_disable_unprepare(hpriv->clk);
> +
> +       return rc;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(ahci_imx_pm_ops, ahci_imx_suspend, ahci_imx_resume);
> +
> +static const struct of_device_id ahci_of_match[] = {
> +       { .compatible = "snps,imx-ahci", },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(of, ahci_of_match);
> +
> +static struct platform_driver ahci_imx_driver = {
> +       .probe = ahci_imx_probe,
> +       .remove = ata_platform_remove_one,
> +       .driver = {
> +               .name = "imx-ahci",
> +               .owner = THIS_MODULE,
> +               .of_match_table = ahci_of_match,
> +               .pm = &ahci_imx_pm_ops,
> +       },
> +};
> +module_platform_driver(ahci_imx_driver);
> +
> +MODULE_DESCRIPTION("FREESCALE IMX AHCI SATA platform driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("sata:imx");
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From linux at arm.linux.org.uk  Mon Jul  1 07:33:10 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 1 Jul 2013 12:33:10 +0100
Subject: [PATCH 2/4] ASoC: sgtl5000: defer the probe if clock is not found
In-Reply-To: <20130701094525.GY27646@sirena.org.uk>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-3-git-send-email-shawn.guo@linaro.org>
 <20130701094525.GY27646@sirena.org.uk>
Message-ID: <20130701113310.GA24642@n2100.arm.linux.org.uk>

On Mon, Jul 01, 2013 at 10:45:25AM +0100, Mark Brown wrote:
> On Mon, Jul 01, 2013 at 04:16:09PM +0800, Shawn Guo wrote:
> > It's not always the case that clock is already available when sgtl5000
> > get probed at the first time, e.g. the clock is provided by CPU DAI
> > which may be probed after sgtl5000.  So let's defer the probe when
> > devm_clk_get() call fails and give it chance to try later.
> 
> Why not fix this in the clock API - the same logic is going to apply to
> a great proportion of clocks?

It's not ever clear whether a missing clock is because it's just not
provided or whether it's because it hasn't been registered yet.  The
decision to defer on missing resources is something which a _driver_
using the resource should make, not the subsystem providing the
resource - because the driver should know better whether that resource
is optional, whether it can continue to initialise without it and maybe
try again later, or whether it does need to defer.

Take for instance a video driver. :)  It may be that it can't do all
resolutions, but it can do some without an external clock, so it may
decide that it can initialise without the external clock and allow one
of the possible modes to be set - and when the external clock does
appear, it can then allow the other modes.

That kind of information is unknown at the subsystem level, and so the
subsystem level should only ever return "I don't know about this" not
"defer probe".


From marex at denx.de  Mon Jul  1 07:36:30 2013
From: marex at denx.de (Marek Vasut)
Date: Mon,  1 Jul 2013 13:36:30 +0200
Subject: [PATCH] ARM: mxs: Fix mxs_pm_init if CONFIG_PM undefined
Message-ID: <1372678590-8765-1-git-send-email-marex@denx.de>

In case the CONFIG_PM is not defined, the mxs_pm_init() from pm.c
is not compiled and therefore mxs_pm_init() is not available. Make
sure that the kernel builds even if CONFIG_PM is not defined.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/mach-mxs/pm.h |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-mxs/pm.h b/arch/arm/mach-mxs/pm.h
index f57e7cd..9f1dcf0 100644
--- a/arch/arm/mach-mxs/pm.h
+++ b/arch/arm/mach-mxs/pm.h
@@ -9,6 +9,10 @@
 #ifndef __ARCH_MXS_PM_H
 #define __ARCH_MXS_PM_H
 
+#ifdef CONFIG_PM
 void mxs_pm_init(void);
+#else
+static inline void mxs_pm_init(void) {}
+#endif
 
 #endif
-- 
1.7.10.4



From festevam at gmail.com  Mon Jul  1 07:42:17 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 1 Jul 2013 08:42:17 -0300
Subject: [PATCH] ARM: mxs: Fix mxs_pm_init if CONFIG_PM undefined
In-Reply-To: <1372678590-8765-1-git-send-email-marex@denx.de>
References: <1372678590-8765-1-git-send-email-marex@denx.de>
Message-ID: <CAOMZO5Bk6ZCtK61p+qhmedFQ8gy6K2jHGCn-e5YTLhPC4nJ78Q@mail.gmail.com>

On Mon, Jul 1, 2013 at 8:36 AM, Marek Vasut <marex at denx.de> wrote:
> In case the CONFIG_PM is not defined, the mxs_pm_init() from pm.c
> is not compiled and therefore mxs_pm_init() is not available. Make
> sure that the kernel builds even if CONFIG_PM is not defined.
>
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Shawn Guo <shawn.guo at linaro.org>

Arnd has already sent a fix for this:
http://www.spinics.net/lists/arm-kernel/msg254288.html


From marex at denx.de  Mon Jul  1 07:45:33 2013
From: marex at denx.de (Marek Vasut)
Date: Mon, 1 Jul 2013 13:45:33 +0200
Subject: [PATCH] ARM: mxs: Fix mxs_pm_init if CONFIG_PM undefined
In-Reply-To: <CAOMZO5Bk6ZCtK61p+qhmedFQ8gy6K2jHGCn-e5YTLhPC4nJ78Q@mail.gmail.com>
References: <1372678590-8765-1-git-send-email-marex@denx.de>
 <CAOMZO5Bk6ZCtK61p+qhmedFQ8gy6K2jHGCn-e5YTLhPC4nJ78Q@mail.gmail.com>
Message-ID: <201307011345.33911.marex@denx.de>

Dear Fabio Estevam,

> On Mon, Jul 1, 2013 at 8:36 AM, Marek Vasut <marex at denx.de> wrote:
> > In case the CONFIG_PM is not defined, the mxs_pm_init() from pm.c
> > is not compiled and therefore mxs_pm_init() is not available. Make
> > sure that the kernel builds even if CONFIG_PM is not defined.
> > 
> > Signed-off-by: Marek Vasut <marex at denx.de>
> > Cc: Shawn Guo <shawn.guo at linaro.org>
> 
> Arnd has already sent a fix for this:
> http://www.spinics.net/lists/arm-kernel/msg254288.html

Ok, thanks. Will this hit 3.10 in any subsequent update?

Best regards,
Marek Vasut


From magnus.damm at gmail.com  Mon Jul  1 07:48:07 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 01 Jul 2013 20:48:07 +0900
Subject: [PATCH] ARM: shmobile: emev2 GIO3 resource fix
Message-ID: <20130701114807.29137.43972.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Fix GIO3 base addresses for EMEV2.

This bug was introduced by 088efd9273b5076a0aead479aa31f1066d182b3e
("mach-shmobile: Emma Mobile EV2 GPIO support V3") which was included in v3.5.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-emev2.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- 0015/arch/arm/mach-shmobile/setup-emev2.c
+++ work/arch/arm/mach-shmobile/setup-emev2.c	2013-07-01 20:21:29.000000000 +0900
@@ -286,14 +286,14 @@ static struct gpio_em_config gio3_config
 static struct resource gio3_resources[] = {
 	[0] = {
 		.name	= "GIO_096",
-		.start	= 0xe0050100,
-		.end	= 0xe005012b,
+		.start	= 0xe0050180,
+		.end	= 0xe00501ab,
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
 		.name	= "GIO_096",
-		.start	= 0xe0050140,
-		.end	= 0xe005015f,
+		.start	= 0xe00501c0,
+		.end	= 0xe00501df,
 		.flags	= IORESOURCE_MEM,
 	},
 	[2] = {


From sergei.shtylyov at cogentembedded.com  Mon Jul  1 08:11:16 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 01 Jul 2013 16:11:16 +0400
Subject: [PATCH 1/3] ARM: shmobile: use common platform header for HPB-DMAC
In-Reply-To: <87ehbij4wc.wl%kuninori.morimoto.gx@renesas.com>
References: <201306300243.57180.sergei.shtylyov@cogentembedded.com>
 <201306300245.58486.sergei.shtylyov@cogentembedded.com>
 <87ehbij4wc.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <51D171E4.3080108@cogentembedded.com>

Hello.

On 01-07-2013 8:11, Kuninori Morimoto wrote:

>> From: Max Filippov <max.filippov at cogentembedded.com>

>> Use previously empty <mach/dma.h> to declare HPB-DMA slave IDs.

>> Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
>> [Sergei: changed the guard macro name, fixed comment, extended copyright.]
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

>> ---
>>   arch/arm/mach-shmobile/include/mach/dma.h |   25 ++++++++++++++++++++++++-
>>   1 file changed, 24 insertions(+), 1 deletion(-)

>> Index: renesas/arch/arm/mach-shmobile/include/mach/dma.h
>> ===================================================================
>> --- renesas.orig/arch/arm/mach-shmobile/include/mach/dma.h
>> +++ renesas/arch/arm/mach-shmobile/include/mach/dma.h
>> @@ -1 +1,24 @@
>> -/* empty */
>> +/*
>> + * Copyright (C) 2011-2013 Renesas Electronics Corporation
>> + * Copyright (C) 2013 Cogent Embedded, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2
>> + * as published by the Free Software Foundation.
>> + */
>> +
>> +#ifndef __MACH_DMA_H
>> +#define __MACH_DMA_H
>> +
>> +/* HPB-DMA slave IDs */
>> +enum {
>> +	HPBDMA_SLAVE_DUMMY,
>> +	HPBDMA_SLAVE_SDHI0_TX,
>> +	HPBDMA_SLAVE_SDHI0_RX,
>> +	HPBDMA_SLAVE_SSI0_TX_ST,
>> +	HPBDMA_SLAVE_SSI0_TX_MN,
>> +	HPBDMA_SLAVE_SSI1_RX_ST,
>> +	HPBDMA_SLAVE_SSI1_RX_MN,
>> +};

> it should be in r8a7778.h

    It will be shared with R8A7779.

WBR, Sergei



From shawn.guo at linaro.org  Mon Jul  1 08:18:05 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 20:18:05 +0800
Subject: [PATCH v2] ARM: dts: add sram for imx53 and imx6q
In-Reply-To: <1372669569-12446-1-git-send-email-p.zabel@pengutronix.de>
References: <1372669569-12446-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20130701121803.GH13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 11:06:09AM +0200, Philipp Zabel wrote:
> This patch enables the On-Chip SRAM (OCRAM) on i.MX53 and i.MX6 SoCs.
> 
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> Reviewed-by: Shawn Guo <shawn.guo at linaro.org>

Applied, thanks.

Shawn



From shawn.guo at linaro.org  Mon Jul  1 08:24:37 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 20:24:37 +0800
Subject: [PATCH v4 1/5] drivers: bus: imx-weim: Remove private driver data
In-Reply-To: <1372480074-24740-1-git-send-email-shc_work@mail.ru>
References: <1372480074-24740-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130701122436.GI13206@S2101-09.ap.freescale.net>

On Sat, Jun 29, 2013 at 08:27:50AM +0400, Alexander Shiyan wrote:
> Driver uses only probe function so no reason to keep variables
> in private driver data.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>

Applied the series, thanks.

Shawn



From coelho at ti.com  Mon Jul  1 08:39:30 2013
From: coelho at ti.com (Luciano Coelho)
Date: Mon, 1 Jul 2013 15:39:30 +0300
Subject: [PATCH] Documentation: dt: bindings: TI WiLink modules
In-Reply-To: <1372425670.21065.61.camel@cumari.coelho.fi>
References: <1372149330-24335-1-git-send-email-coelho@ti.com>
 <20130628093848.GA2139@e106331-lin.cambridge.arm.com>
 <1372413215.21065.41.camel@cumari.coelho.fi>
 <20130628102145.GB2139@e106331-lin.cambridge.arm.com>
 <1372415514.21065.50.camel@cumari.coelho.fi>
 <1372418531.21065.53.camel@cumari.coelho.fi>
 <20130628114129.GO11297@arwen.pp.htv.fi>
 <1372421632.21065.60.camel@cumari.coelho.fi>
 <20130628121859.GP11297@arwen.pp.htv.fi>
 <1372425670.21065.61.camel@cumari.coelho.fi>
Message-ID: <1372682370.21065.68.camel@cumari.coelho.fi>

On Fri, 2013-06-28 at 16:21 +0300, Luciano Coelho wrote:
> On Fri, 2013-06-28 at 15:18 +0300, Felipe Balbi wrote:
> > On Fri, Jun 28, 2013 at 03:13:52PM +0300, Luciano Coelho wrote:
> > > On Fri, 2013-06-28 at 14:41 +0300, Felipe Balbi wrote:
> > > > On Fri, Jun 28, 2013 at 02:22:11PM +0300, Luciano Coelho wrote:
> > > > > On Fri, 2013-06-28 at 13:31 +0300, Luciano Coelho wrote:
> > > > > > (fixed Mike's address)
> > > > > > 
> > > > > > On Fri, 2013-06-28 at 11:21 +0100, Mark Rutland wrote:
> > > > > > > On Fri, Jun 28, 2013 at 10:53:35AM +0100, Luciano Coelho wrote:
> > > > > > > > On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
> > > > > > > > > On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho wrote:
> > > > > > > > > > +Optional properties:
> > > > > > > > > > +--------------------
> > > > > > > > > > +
> > > > > > > > > > +- refclock: the internal WLAN reference clock frequency (required for
> > > > > > > > > > +  WiLink6 and WiLink7; not used for WiLink8).  Must be one of the
> > > > > > > > > > +  following:
> > > > > > > > > > +	0 = 19.2 MHz
> > > > > > > > > > +	1 = 26.0 MHz
> > > > > > > > > > +	2 = 38.4 MHz
> > > > > > > > > > +	3 = 52.0 MHz
> > > > > > > > > > +	4 = 38.4 MHz, XTAL
> > > > > > > > > > +	5 = 26.0 MHz, XTAL
> > > > > > > > > > +
> > > > > > > > > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for
> > > > > > > > > > +  WiLink7 not used for WiLink6 and WiLink8).  Must be one of the
> > > > > > > > > > +  following:
> > > > > > > > > > +	0 = 19.200 MHz
> > > > > > > > > > +	1 = 26.000 MHz
> > > > > > > > > > +	2 = 38.400 MHz
> > > > > > > > > > +	3 = 52.000 MHz
> > > > > > > > > > +	4 = 16.368 MHz
> > > > > > > > > > +	5 = 32.736 MHz
> > > > > > > > > > +	6 = 16.800 MHz
> > > > > > > > > > +	7 = 33.600 MHz
> > > > > > > > > 
> > > > > > > > > This looks suspiciously like what we have the common clock bindings for:
> > > > > > > > > 
> > > > > > > > > refclk {
> > > > > > > > > 	compatible = "fixed-clock";
> > > > > > > > > 	#clock-cells = <0>;
> > > > > > > > > 	clock-frequency = <19200000>;
> > > > > > > > > }
> > > > > > > > > 
> > > > > > > > > wilink {
> > > > > > > > > 	compatible = "ti,wilink7";
> > > > > > > > > 	interrupt-parent = <&some_interrupt_controller>;
> > > > > > > > > 	interrupts = <0 1 1>;
> > > > > > > > > 	clocks = <&refclk>, <&refclk>;
> > > > > > > > > 	clock-names = "refclk", "txoclk";
> > > > > > > > > };
> > > > > > > > > 
> > > > > > > > > Could you not use them?
> > > > > > > > 
> > > > > > > > Hmmm... this actually does look good.  But these are internal clocks in
> > > > > > > > the modules, they cannot be accessed from outside.  Does it make sense
> > > > > > > > to register them with the clock framework?
> > > > > > > 
> > > > > > > Given we already have a common way of describing clocks, I think it
> > > > > > > makes sense to use it -- people already understand the common bindings,
> > > > > > > and it's less code to add add to the kernel. I don't think the fact
> > > > > > > these clocks are internal should prevent us from describing them as we
> > > > > > > would an external clock.
> > > > > > 
> > > > > > Yes, I agree with you.  Thanks for the suggestion! I think it will look
> > > > > > much better.  And now that I dug a bit more into the code, I can see
> > > > > > that there are only structs being populated, so there shouldn't be any
> > > > > > other side-effects.
> > > > > 
> > > > > Hmmm, one thing that escaped me.  Besides the frequency, I also need a
> > > > > boolean that tells if the clock is XTAL or not.  I can't figure out how
> > > > > to pass this if I use the generic clock framework.  Any suggestions?
> > > > 
> > > > Could you use clock-output-names for that ?
> > > > 
> > > > XTAL clock:
> > > > 
> > > > refclk {
> > > > 	compatible = "fixed-clock";
> > > > 	#clock cells = <0>;
> > > > 	clock-frequency = <19200000>;
> > > > 	clock-output-names = "xtal";
> > > > };
> > > > 
> > > > non-XTAL clock:
> > > > 
> > > > refclk {
> > > > 	compatible = "fixed-clock";
> > > > 	#clock cells = <0>;
> > > > 	clock-frequency = <19200000>;
> > > > 	clock-output-names = "osc"; /* any better name ? */
> > > > };
> > > 
> > > This starts looking a bit hacky.  Using the output name as a flag is not
> > > very pretty.
> > > 
> > > I think it would be better to have a separate flag for it in the wlan
> > > node.  Like an optional "refclock-xtal" boolean or something.  The
> > > downside of this is that we would be adding information about the clock
> > > details in the wilink node. :(
> > > 
> > > OTOH, we could add a flag to the generic clock binding? A new optional
> > > boolean that tells whether the clock is XTAL or not:
> > > 
> > > refclk {
> > > 	compatible = "fixed-clock";
> > > 	#clock cells = <0>;
> > > 	clock-frequency = <19200000>;
> > > 	clock-xtal;
> > > };
> > > 
> > > Do you think that would make sense?
> > 
> > sure, that looks alright to me. Surely there are other devices out there
> > who want to know if the clock comes from a crystal or not ?!?
> 
> Mike, what do you think about this idea? If it sounds okay to you, I can
> cook up a patch adding this flag.

Hmmm... I started implementing this whole thing, but using these clocks
as "fixed-clock"s is not so straightforward.  The problem is that I
would need to register my driver as a clock provider and add the OF
match for "fixed-clock".

If I do that, all the other "fixed-clock" nodes would be passed to my
driver too, which is wrong.  Or, the platform should register the
"fixed-clock" match, but this would be wrong too, since it would find
*my* fixed-clocks.

The only thing I can come up with is to make a small clock driver (maybe
even inside the WiLink module itself) that registers a new type of
clock, "ti,wilink-clock" or something.  But this would really be
overkill, wouldn't it?

Any other ideas?

--
Luca.



From s.hauer at pengutronix.de  Mon Jul  1 08:44:45 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 1 Jul 2013 14:44:45 +0200
Subject: [v2 4/4] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <1372672975-2997-5-git-send-email-r65037@freescale.com>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-5-git-send-email-r65037@freescale.com>
Message-ID: <20130701124445.GW516@pengutronix.de>

On Mon, Jul 01, 2013 at 06:02:55PM +0800, Richard Zhu wrote:
> imx6q contains one Synopsys AHCI SATA controller,
> But it can't shares ahci_platform driver with other
> controllers.
> Because there are some misalignments of the bits
> definitions of the HBA registers and the Vendor
> Specific registers
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>  value is '0', should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the
>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>  should be configured regarding to the frequency of AHB
>  bus clock.
> 
> Setup its own ahci sata driver, enable the imx6q ahci
> sata support, and update the ahci sata binding document.
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>

Wait a minute. We suggested to add a i.MX specific ahci driver to put
the i.MX speicific setup in there. Now you really post a separate i.MX
driver, but instead of putting the setup in there, it's a nearly
identical copy of the generic driver *without* the setup and the setup
is still in arch/arm/. That doesn't make sense to me.

> + */
> +static int imx_sata_init(void __iomem *mmio)
> +{
> +	int ret;
> +	struct clk *ahb_clk;
> +
> +	ret = readl(mmio + HOST_CAP);
> +	if (!(ret & HOST_CAP_SSS))
> +		writel(ret |= HOST_CAP_SSS, mmio + HOST_CAP);
> +	ret = readl(mmio + HOST_PORTS_IMPL);
> +	if (!(ret & 0x1))
> +		writel((ret | 0x1), mmio + HOST_PORTS_IMPL);
> +	ahb_clk = clk_get_sys(NULL, "ahb");

use devm_clk_get

> +
> +	if (pdata && pdata->ata_port_info)
> +		pi = *pdata->ata_port_info;
> +
> +	hpriv = devm_kzalloc(dev, sizeof(*hpriv), GFP_KERNEL);
> +	if (!hpriv) {
> +		dev_err(dev, "can't alloc ahci_host_priv\n");
> +		return -ENOMEM;
> +	}
> +
> +	hpriv->flags |= (unsigned long)pi.private_data;
> +
> +	hpriv->mmio = devm_ioremap(dev, mem->start, resource_size(mem));
> +	if (!hpriv->mmio) {
> +		dev_err(dev, "can't map %pR\n", mem);
> +		return -ENOMEM;
> +	}
> +
> +	hpriv->clk = clk_get(dev, NULL);

devm_clk_get.

> +	if (IS_ERR(hpriv->clk)) {
> +		dev_err(dev, "can't get clock\n");

That's an error. You should react to it.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From robherring2 at gmail.com  Mon Jul  1 08:49:53 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 01 Jul 2013 07:49:53 -0500
Subject: [v2 4/4] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <1372672975-2997-5-git-send-email-r65037@freescale.com>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-5-git-send-email-r65037@freescale.com>
Message-ID: <51D17AF1.2060504@gmail.com>

On 07/01/2013 05:02 AM, Richard Zhu wrote:
> imx6q contains one Synopsys AHCI SATA controller,
> But it can't shares ahci_platform driver with other
> controllers.
> Because there are some misalignments of the bits
> definitions of the HBA registers and the Vendor
> Specific registers
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>  value is '0', should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the
>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>  should be configured regarding to the frequency of AHB
>  bus clock.

All this really belongs in the bootloader. Wouldn't you most likely be
booting the kernel from SATA as well? The first 2 are write once bits so
setting them a 2nd time would have no effect.

I also agree that if this added, it should be added to the existing driver.

Rob

> 
> Setup its own ahci sata driver, enable the imx6q ahci
> sata support, and update the ahci sata binding document.
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  .../devicetree/bindings/ata/ahci-platform.txt      |    2 +-
>  drivers/ata/Kconfig                                |    8 +
>  drivers/ata/Makefile                               |    1 +
>  drivers/ata/sata_imx.c                             |  349 ++++++++++++++++++++
>  4 files changed, 359 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/ata/sata_imx.c
> 
> diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
> index b519f9b..e252620 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
> +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
> @@ -4,7 +4,7 @@ SATA nodes are defined to describe on-chip Serial ATA controllers.
>  Each SATA controller should have its own node.
>  
>  Required properties:
> -- compatible        : compatible list, contains "calxeda,hb-ahci" or "snps,spear-ahci"
> +- compatible        : compatible list, contains "calxeda,hb-ahci", "snps,spear-ahci" or "snps, imx-ahci"
>  - interrupts        : <interrupt mapping for SATA IRQ>
>  - reg               : <registers mapping>
>  
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index a5a3ebc..893fa0b 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -236,6 +236,14 @@ config SATA_HIGHBANK
>  
>  	  If unsure, say N.
>  
> +config SATA_IMX
> +	tristate "Freescale iMX AHCI SATA support"
> +	help
> +	  This option enables support for the Freescale iMX SoC's
> +	  onboard AHCI SATA.
> +
> +	  If unsure, say N.
> +
>  config SATA_MV
>  	tristate "Marvell SATA support"
>  	help
> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
> index c04d0fd..c40b328 100644
> --- a/drivers/ata/Makefile
> +++ b/drivers/ata/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_SATA_INIC162X)	+= sata_inic162x.o
>  obj-$(CONFIG_SATA_SIL24)	+= sata_sil24.o
>  obj-$(CONFIG_SATA_DWC)		+= sata_dwc_460ex.o
>  obj-$(CONFIG_SATA_HIGHBANK)	+= sata_highbank.o libahci.o
> +obj-$(CONFIG_SATA_IMX)		+= sata_imx.o libahci.o
>  
>  # SFF w/ custom DMA
>  obj-$(CONFIG_PDC_ADMA)		+= pdc_adma.o
> diff --git a/drivers/ata/sata_imx.c b/drivers/ata/sata_imx.c
> new file mode 100644
> index 0000000..2be92e8
> --- /dev/null
> +++ b/drivers/ata/sata_imx.c
> @@ -0,0 +1,349 @@
> +/*
> + * Freescale IMX AHCI SATA platform driver
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * based on the AHCI SATA platform driver by Jeff Garzik and Anton Vorontsov
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/kernel.h>
> +#include <linux/gfp.h>
> +#include <linux/module.h>
> +#include <linux/pm.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/device.h>
> +#include <linux/platform_device.h>
> +#include <linux/libata.h>
> +#include <linux/ahci_platform.h>
> +#include "ahci.h"
> +
> +enum {
> +	HOST_TIMER1MS = 0xe0, /* Timer 1-ms */
> +};
> +
> +static void ahci_imx_host_stop(struct ata_host *host);
> +
> +static struct ata_port_operations ahci_imx_platform_ops = {
> +	.inherits	= &ahci_ops,
> +	.host_stop	= ahci_imx_host_stop,
> +};
> +
> +static const struct ata_port_info ahci_imx_port_info = {
> +	.flags		= AHCI_FLAG_COMMON,
> +	.pio_mask	= ATA_PIO4,
> +	.udma_mask	= ATA_UDMA6,
> +	.port_ops	= &ahci_imx_platform_ops,
> +};
> +
> +static struct scsi_host_template ahci_imx_platform_sht = {
> +	AHCI_SHT("sata_imx"),
> +};
> +
> +/*
> + * Configure the HWINIT bits of the HOST_CAP and HOST_PORTS_IMPL,
> + * and IP vendor specific register HOST_TIMER1MS.
> + *
> + * Configure CAP_SSS (support stagered spin up).
> + * Implement the port0.
> + * Get the ahb clock rate, and configure the TIMER1MS register.
> + */
> +static int imx_sata_init(void __iomem *mmio)
> +{
> +	int ret;
> +	struct clk *ahb_clk;
> +
> +	ret = readl(mmio + HOST_CAP);
> +	if (!(ret & HOST_CAP_SSS))
> +		writel(ret |= HOST_CAP_SSS, mmio + HOST_CAP);
> +	ret = readl(mmio + HOST_PORTS_IMPL);
> +	if (!(ret & 0x1))
> +		writel((ret | 0x1), mmio + HOST_PORTS_IMPL);
> +	ahb_clk = clk_get_sys(NULL, "ahb");
> +	if (IS_ERR(ahb_clk)) {
> +		pr_err("no ahb clock.\n");
> +		ret = PTR_ERR(ahb_clk);
> +		return ret;
> +	}
> +	ret = clk_get_rate(ahb_clk) / 1000;
> +	clk_put(ahb_clk);
> +	writel(ret, mmio + HOST_TIMER1MS);
> +
> +	return ret;
> +}
> +
> +static int ahci_imx_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct ahci_platform_data *pdata = dev_get_platdata(dev);
> +	struct ata_port_info pi = ahci_imx_port_info;
> +	const struct ata_port_info *ppi[] = { &pi, NULL };
> +	struct ahci_host_priv *hpriv;
> +	struct ata_host *host;
> +	struct resource *mem;
> +	int irq;
> +	int n_ports;
> +	int i;
> +	int rc;
> +
> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!mem) {
> +		dev_err(dev, "no mmio space\n");
> +		return -EINVAL;
> +	}
> +
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq <= 0) {
> +		dev_err(dev, "no irq\n");
> +		return -EINVAL;
> +	}
> +
> +	if (pdata && pdata->ata_port_info)
> +		pi = *pdata->ata_port_info;
> +
> +	hpriv = devm_kzalloc(dev, sizeof(*hpriv), GFP_KERNEL);
> +	if (!hpriv) {
> +		dev_err(dev, "can't alloc ahci_host_priv\n");
> +		return -ENOMEM;
> +	}
> +
> +	hpriv->flags |= (unsigned long)pi.private_data;
> +
> +	hpriv->mmio = devm_ioremap(dev, mem->start, resource_size(mem));
> +	if (!hpriv->mmio) {
> +		dev_err(dev, "can't map %pR\n", mem);
> +		return -ENOMEM;
> +	}
> +
> +	hpriv->clk = clk_get(dev, NULL);
> +	if (IS_ERR(hpriv->clk)) {
> +		dev_err(dev, "can't get clock\n");
> +	} else {
> +		rc = clk_prepare_enable(hpriv->clk);
> +		if (rc) {
> +			dev_err(dev, "clock prepare enable failed");
> +			goto free_clk;
> +		}
> +	}
> +
> +	/*
> +	 * Some platforms might need to prepare for mmio region access,
> +	 * which could be done in the following init call. So, the mmio
> +	 * region shouldn't be accessed before init (if provided) has
> +	 * returned successfully.
> +	 */
> +	if (pdata && pdata->init) {
> +		rc = pdata->init(dev, hpriv->mmio);
> +		if (rc)
> +			goto disable_unprepare_clk;
> +	}
> +
> +	rc = imx_sata_init(hpriv->mmio);
> +	if (rc < 0)
> +		goto pdata_exit;
> +
> +	ahci_save_initial_config(dev, hpriv,
> +		pdata ? pdata->force_port_map : 0,
> +		pdata ? pdata->mask_port_map  : 0);
> +
> +	/* prepare host */
> +	if (hpriv->cap & HOST_CAP_NCQ)
> +		pi.flags |= ATA_FLAG_NCQ;
> +
> +	if (hpriv->cap & HOST_CAP_PMP)
> +		pi.flags |= ATA_FLAG_PMP;
> +
> +	ahci_set_em_messages(hpriv, &pi);
> +
> +	/* CAP.NP sometimes indicate the index of the last enabled
> +	 * port, at other times, that of the last possible port, so
> +	 * determining the maximum port number requires looking at
> +	 * both CAP.NP and port_map.
> +	 */
> +	n_ports = max(ahci_nr_ports(hpriv->cap), fls(hpriv->port_map));
> +
> +	host = ata_host_alloc_pinfo(dev, ppi, n_ports);
> +	if (!host) {
> +		rc = -ENOMEM;
> +		goto pdata_exit;
> +	}
> +
> +	host->private_data = hpriv;
> +
> +	if (!(hpriv->cap & HOST_CAP_SSS) || ahci_ignore_sss)
> +		host->flags |= ATA_HOST_PARALLEL_SCAN;
> +	else
> +		dev_info(dev, "ahci: SSS flag set, parallel bus scan disabled\n");
> +
> +	if (pi.flags & ATA_FLAG_EM)
> +		ahci_reset_em(host);
> +
> +	for (i = 0; i < host->n_ports; i++) {
> +		struct ata_port *ap = host->ports[i];
> +
> +		ata_port_desc(ap, "mmio %pR", mem);
> +		ata_port_desc(ap, "port 0x%x", 0x100 + ap->port_no * 0x80);
> +
> +		/* set enclosure management message type */
> +		if (ap->flags & ATA_FLAG_EM)
> +			ap->em_message_type = hpriv->em_msg_type;
> +
> +		/* disabled/not-implemented port */
> +		if (!(hpriv->port_map & (1 << i)))
> +			ap->ops = &ata_dummy_port_ops;
> +	}
> +
> +	rc = ahci_reset_controller(host);
> +	if (rc)
> +		goto pdata_exit;
> +
> +	ahci_init_controller(host);
> +	ahci_print_info(host, "platform");
> +
> +	rc = ata_host_activate(host, irq, ahci_interrupt, IRQF_SHARED,
> +			       &ahci_imx_platform_sht);
> +	if (rc)
> +		goto pdata_exit;
> +
> +	return 0;
> +pdata_exit:
> +	if (pdata && pdata->exit)
> +		pdata->exit(dev);
> +disable_unprepare_clk:
> +	if (!IS_ERR(hpriv->clk))
> +		clk_disable_unprepare(hpriv->clk);
> +free_clk:
> +	if (!IS_ERR(hpriv->clk))
> +		clk_put(hpriv->clk);
> +	return rc;
> +}
> +
> +static void ahci_imx_host_stop(struct ata_host *host)
> +{
> +	struct device *dev = host->dev;
> +	struct ahci_platform_data *pdata = dev_get_platdata(dev);
> +	struct ahci_host_priv *hpriv = host->private_data;
> +
> +	if (pdata && pdata->exit)
> +		pdata->exit(dev);
> +
> +	if (!IS_ERR(hpriv->clk)) {
> +		clk_disable_unprepare(hpriv->clk);
> +		clk_put(hpriv->clk);
> +	}
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int ahci_imx_suspend(struct device *dev)
> +{
> +	struct ahci_platform_data *pdata = dev_get_platdata(dev);
> +	struct ata_host *host = dev_get_drvdata(dev);
> +	struct ahci_host_priv *hpriv = host->private_data;
> +	void __iomem *mmio = hpriv->mmio;
> +	u32 ctl;
> +	int rc;
> +
> +	if (hpriv->flags & AHCI_HFLAG_NO_SUSPEND) {
> +		dev_err(dev, "firmware update required for suspend/resume\n");
> +		return -EIO;
> +	}
> +
> +	/*
> +	 * AHCI spec rev1.1 section 8.3.3:
> +	 * Software must disable interrupts prior to requesting a
> +	 * transition of the HBA to D3 state.
> +	 */
> +	ctl = readl(mmio + HOST_CTL);
> +	ctl &= ~HOST_IRQ_EN;
> +	writel(ctl, mmio + HOST_CTL);
> +	readl(mmio + HOST_CTL); /* flush */
> +
> +	rc = ata_host_suspend(host, PMSG_SUSPEND);
> +	if (rc)
> +		return rc;
> +
> +	if (pdata && pdata->suspend)
> +		return pdata->suspend(dev);
> +
> +	if (!IS_ERR(hpriv->clk))
> +		clk_disable_unprepare(hpriv->clk);
> +
> +	return 0;
> +}
> +
> +static int ahci_imx_resume(struct device *dev)
> +{
> +	struct ahci_platform_data *pdata = dev_get_platdata(dev);
> +	struct ata_host *host = dev_get_drvdata(dev);
> +	struct ahci_host_priv *hpriv = host->private_data;
> +	int rc;
> +
> +	if (!IS_ERR(hpriv->clk)) {
> +		rc = clk_prepare_enable(hpriv->clk);
> +		if (rc) {
> +			dev_err(dev, "clock prepare enable failed");
> +			return rc;
> +		}
> +	}
> +
> +	if (pdata && pdata->resume) {
> +		rc = pdata->resume(dev);
> +		if (rc)
> +			goto disable_unprepare_clk;
> +	}
> +
> +	if (dev->power.power_state.event == PM_EVENT_SUSPEND) {
> +		rc = ahci_reset_controller(host);
> +		if (rc)
> +			goto disable_unprepare_clk;
> +
> +		ahci_init_controller(host);
> +	}
> +
> +	ata_host_resume(host);
> +
> +	return 0;
> +
> +disable_unprepare_clk:
> +	if (!IS_ERR(hpriv->clk))
> +		clk_disable_unprepare(hpriv->clk);
> +
> +	return rc;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(ahci_imx_pm_ops, ahci_imx_suspend, ahci_imx_resume);
> +
> +static const struct of_device_id ahci_of_match[] = {
> +	{ .compatible = "snps,imx-ahci", },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, ahci_of_match);
> +
> +static struct platform_driver ahci_imx_driver = {
> +	.probe = ahci_imx_probe,
> +	.remove = ata_platform_remove_one,
> +	.driver = {
> +		.name = "imx-ahci",
> +		.owner = THIS_MODULE,
> +		.of_match_table = ahci_of_match,
> +		.pm = &ahci_imx_pm_ops,
> +	},
> +};
> +module_platform_driver(ahci_imx_driver);
> +
> +MODULE_DESCRIPTION("FREESCALE IMX AHCI SATA platform driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("sata:imx");
> 



From broonie at kernel.org  Mon Jul  1 08:51:13 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 1 Jul 2013 13:51:13 +0100
Subject: [PATCH 2/4] ASoC: sgtl5000: defer the probe if clock is not found
In-Reply-To: <20130701113310.GA24642@n2100.arm.linux.org.uk>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-3-git-send-email-shawn.guo@linaro.org>
 <20130701094525.GY27646@sirena.org.uk>
 <20130701113310.GA24642@n2100.arm.linux.org.uk>
Message-ID: <20130701125113.GK27646@sirena.org.uk>

On Mon, Jul 01, 2013 at 12:33:10PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 01, 2013 at 10:45:25AM +0100, Mark Brown wrote:

> > Why not fix this in the clock API - the same logic is going to apply to
> > a great proportion of clocks?

> It's not ever clear whether a missing clock is because it's just not
> provided or whether it's because it hasn't been registered yet.  The
> decision to defer on missing resources is something which a _driver_
> using the resource should make, not the subsystem providing the
> resource - because the driver should know better whether that resource
> is optional, whether it can continue to initialise without it and maybe
> try again later, or whether it does need to defer.

Given how common it is to have a hard requirement for a clock I think we
should at least have a helper which implements deferral, even if it's
not part of the default request function, since so many drivers ought to
be using it.  Doing this in by default doesn't prevent the driver
overriding, though - the driver can choose to squash down the PROBE_DEFER
into a fatal error.

One nice thing you can sometimes do here in the DT case is to have the
subsystem tell the driver the difference between "this clock is mapped
but not yet registered" and "this clock is not physically present"
though there's never any guarantee that the provided resource will
actually load.  I don't think the idiom for the clock API is to provide
every single clock in DT though so that might not be doable.

> Take for instance a video driver. :)  It may be that it can't do all
> resolutions, but it can do some without an external clock, so it may
> decide that it can initialise without the external clock and allow one
> of the possible modes to be set - and when the external clock does
> appear, it can then allow the other modes.

Yes, that's the sort of case where you do definitely want to just carry
on (though there is then some vulnerability to changes in init ordering
with things like modular kernels).
-------------- 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/20130701/34be7eea/attachment.sig>

From s.hauer at pengutronix.de  Mon Jul  1 08:55:08 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 1 Jul 2013 14:55:08 +0200
Subject: [v2 2/4] imx: ahci: enable ahci sata on imx6q platforms
In-Reply-To: <1372672975-2997-3-git-send-email-r65037@freescale.com>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-3-git-send-email-r65037@freescale.com>
Message-ID: <20130701125508.GX516@pengutronix.de>

On Mon, Jul 01, 2013 at 06:02:53PM +0800, Richard Zhu wrote:
> Only the imx6q contains the ahci sata controller,
> other imx6 SoCs don't have it.
> 
> Enable the ahci sata only on imx6q platforms
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  arch/arm/mach-imx/mach-imx6q.c |   85 +++++++++++++++++++++++++++++++++++++++-
> +/* imx6q ahci module initialization. */
> +static int imx6q_sata_phy_clk(struct device *dev, int enable)
> +{
> +	int ret = 0;
> +	struct clk *sata_ref_clk;
> +
> +	sata_ref_clk = devm_clk_get(dev, "sata_ref_100m");
> +	if (IS_ERR(sata_ref_clk)) {
> +		dev_err(dev, "can't get sata_ref clock.\n");
> +		return PTR_ERR(sata_ref_clk);
> +	}

devm_clk_get takes a reference to the clock. That's not something you
want to do each time you enable/disable a clock.

> +	if (enable) {
> +		/* Enable PHY clock */
> +		ret = clk_prepare_enable(sata_ref_clk);
> +		if (ret < 0) {
> +			dev_err(dev, "can't prepare-enable sata_ref clock\n");
> +			clk_put(sata_ref_clk);
> +			ret = PTR_ERR(sata_ref_clk);

What are you intending by converting a valid pointer to an error code?

> +		}
> +	} else {
> +		/* Disable PHY clock */
> +		clk_disable_unprepare(sata_ref_clk);
> +	}
> +
> +	return ret;
> +}
> +
> +static int imx6q_sata_init(struct device *dev, void __iomem *addr)
> +{
> +	int ret = 0;
> +	struct regmap *gpr;
> +
> +	ret = imx6q_sata_phy_clk(dev, true);
> +	if (ret < 0)
> +		return ret;
> +
> +	gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +	if (IS_ERR(gpr)) {
> +		pr_err("failed to find fsl,imx6q-iomux-gpr regmap\n");
> +		return PTR_ERR(gpr);
> +	}
> +
> +	/*
> +	 * set PHY Paremeters, two steps to configure the GPR13,
> +	 * one write for rest of parameters, mask of first write
> +	 * is 0x07fffffd, and the other one write for setting
> +	 * the mpll_clk_en.
> +	 */
> +	regmap_update_bits(gpr, 0x34, 0x07fffffd, 0x0593e4c4);

You are adding the register defines in the next patch. Wouldn't it make
sense to use them?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From broonie at kernel.org  Mon Jul  1 08:55:55 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon,  1 Jul 2013 13:55:55 +0100
Subject: [PATCH] drm/exynos: Add missing includes
Message-ID: <1372683355-27460-1-git-send-email-broonie@kernel.org>

From: Mark Brown <broonie at linaro.org>

Ensure that all externally accessed functions are correctly prototyped
when defined in each file by making sure the headers with the protoypes
are included in the file with the definition.

Signed-off-by: Mark Brown <broonie at linaro.org>
---
 drivers/gpu/drm/exynos/exynos_drm_connector.c | 1 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c      | 1 +
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c    | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c     | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fimc.c      | 1 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c       | 1 +
 drivers/gpu/drm/exynos/exynos_drm_gsc.c       | 1 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c     | 1 +
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   | 1 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c      | 1 +
 10 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 8bcc13a..ec80293 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -17,6 +17,7 @@
 #include <drm/exynos_drm.h>
 #include "exynos_drm_drv.h"
 #include "exynos_drm_encoder.h"
+#include "exynos_drm_connector.h"
 
 #define to_exynos_connector(x)	container_of(x, struct exynos_drm_connector,\
 				drm_connector)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 073c10a..6933ee9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -15,6 +15,7 @@
 #include <drm/drmP.h>
 #include <drm/drm_crtc_helper.h>
 
+#include "exynos_drm_crtc.h"
 #include "exynos_drm_drv.h"
 #include "exynos_drm_encoder.h"
 #include "exynos_drm_plane.h"
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index ff7f2a8..8adafde 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -11,6 +11,7 @@
 
 #include <drm/drmP.h>
 #include <drm/exynos_drm.h>
+#include "exynos_drm_dmabuf.h"
 #include "exynos_drm_drv.h"
 #include "exynos_drm_gem.h"
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 8f007aa..45b6cb3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -19,6 +19,7 @@
 
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fb.h"
+#include "exynos_drm_fbdev.h"
 #include "exynos_drm_gem.h"
 #include "exynos_drm_iommu.h"
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 4a1616a..a83e664 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -22,6 +22,7 @@
 #include <drm/drmP.h>
 #include <drm/exynos_drm.h>
 #include "regs-fimc.h"
+#include "exynos_drm_drv.h"
 #include "exynos_drm_ipp.h"
 #include "exynos_drm_fimc.h"
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index af75434..03ba897 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -24,6 +24,7 @@
 #include <drm/drmP.h>
 #include <drm/exynos_drm.h>
 #include "exynos_drm_drv.h"
+#include "exynos_drm_g2d.h"
 #include "exynos_drm_gem.h"
 #include "exynos_drm_iommu.h"
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 762f40d..4683251 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -21,6 +21,7 @@
 #include <drm/drmP.h>
 #include <drm/exynos_drm.h>
 #include "regs-gsc.h"
+#include "exynos_drm_drv.h"
 #include "exynos_drm_ipp.h"
 #include "exynos_drm_gsc.h"
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 83efc66..63ebeeb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -16,6 +16,7 @@
 #include "exynos_drm_encoder.h"
 #include "exynos_drm_fb.h"
 #include "exynos_drm_gem.h"
+#include "exynos_drm_plane.h"
 
 #define to_exynos_plane(x)	container_of(x, struct exynos_plane, base)
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 9b6c709..2e9eee2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -22,6 +22,7 @@
 #include <drm/exynos_drm.h>
 #include "regs-rotator.h"
 #include "exynos_drm.h"
+#include "exynos_drm_drv.h"
 #include "exynos_drm_ipp.h"
 
 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 24376c1..498647a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -24,6 +24,7 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_crtc.h"
 #include "exynos_drm_encoder.h"
+#include "exynos_drm_vidi.h"
 
 /* vidi has totally three virtual windows. */
 #define WINDOWS_NR		3
-- 
1.8.3.1



From p.zabel at pengutronix.de  Mon Jul  1 08:56:36 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon, 01 Jul 2013 14:56:36 +0200
Subject: [PATCH 1/2] ARM: dts: mx53qsb: Enable VPU support
In-Reply-To: <1372459759-10488-1-git-send-email-festevam@gmail.com>
References: <1372459759-10488-1-git-send-email-festevam@gmail.com>
Message-ID: <1372683396.4971.35.camel@pizza.hi.pengutronix.de>

Hi Fabio,

Am Freitag, den 28.06.2013, 19:49 -0300 schrieb Fabio Estevam:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Enable Video Processing Unit (VPU) support.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
> Depends on Philipp Zabel's patch:
> [PATCH] ARM: dts: add sram for imx53 and imx6q
> 
> Philipp,
> 
> I tried using the original mx53 vpu firmware that comes with the FSL BSP, but it
> failed to load:
> 
> coda 63ff4000.vpu: firmware get command error                                   
> coda 63ff4000.vpu: HW initialization failed  
> 
> Any suggestions?
> 
> Thanks!

/*
 * The CODA driver needs the raw firmware without header in memory order.
 * This is how I converted vpu_fw_imx53.bin from the Freescale BSP into
 * v4l2-coda7541-imx53.bin:
 */

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>

struct fw_header_info {
	u_int8_t  platform[12];
	u_int32_t size;
};

int main(int argc, char *argv[])
{
	int fd, i, n, size;
	struct fw_header_info header;
	u_int32_t *buf;

	if (argc < 3) {
		fprintf(stderr, "usage: %s <infile> <outfile>\n", argv[0]);
		fprintf(stderr, "example: %s vpu_fw_imx53.bin v4l2-coda7541-imx53.bin\n", argv[0]);
		return 0;
	}

	fd = open(argv[1], O_RDONLY);
	if (fd < 0) {
		fprintf(stderr, "Failed to open source file '%s'.\n", argv[1]);
		return EXIT_FAILURE;
	}

	n = read(fd, &header, sizeof(header));
	if (n != sizeof(header)) {
		fprintf(stderr, "Failed to read header.\n");
		return EXIT_FAILURE;
	}

	size = header.size * sizeof(u_int16_t);
	buf = malloc(size);
	if (buf == NULL)
		return EXIT_FAILURE;

	n = read(fd, buf, size);
	if (n != size) {
		fprintf(stderr, "Failed to read firmware.\n");
		return EXIT_FAILURE;
	}

	close(fd);

	for (i = 0; i < size / 4; i += 2) {
		u_int32_t tmp = buf[i + 1] << 16 | buf[i + 1] >> 16;
		buf[i + 1] = buf[i] << 16 | buf[i] >> 16;
		buf[i] = tmp;
	}

	fd = open(argv[2], O_RDWR | O_CREAT, 0644);
	if (fd < 0)
		error("Failed to open target file '%s'.\n", argv[2]);

	n = write(fd, buf, size);
	if (n != size)
		error("Failed to write reordered firmware\n");

	close(fd);

	return 0;
}

/*
 * regards
 * Philipp
 */



From shawn.guo at linaro.org  Mon Jul  1 08:58:21 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 20:58:21 +0800
Subject: [PATCH] ARM: dts: i.MX27: Add Secondary AHB Port definitions
In-Reply-To: <1372487325-14405-1-git-send-email-shc_work@mail.ru>
References: <1372487325-14405-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130701125819.GJ13206@S2101-09.ap.freescale.net>

On Sat, Jun 29, 2013 at 10:28:45AM +0400, Alexander Shiyan wrote:
> Patch adds Secondary AHB Port definitions for i.MX27 SOC and
> moves NAND Flash Controller (NFC) under AHB Slave Port 1.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  arch/arm/boot/dts/imx27.dtsi | 28 ++++++++++++++++++++++------
>  1 file changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
> index 86b6f5f..7c0179e 100644
> --- a/arch/arm/boot/dts/imx27.dtsi
> +++ b/arch/arm/boot/dts/imx27.dtsi
> @@ -399,14 +399,30 @@
>  			};
>  		};
>  
> -		nfc: nand at d8000000 {
> +		ahb1: ahb at 80000000 { /* Secondary AHB Slave Port 1 */

We do not have the top level of AHB bus topology represented in device
tree.  Your patch introduces it, partially - all about Secondary AHB
Slave but nothing about Primary AHB.

I'm not really fond of the change, since it's not extremely useful to
me.  Do you have a real reason for the change?

Shawn

> +			compatible = "fsl,ahb-bus", "simple-bus";
>  			#address-cells = <1>;
>  			#size-cells = <1>;
> -			compatible = "fsl,imx27-nand";
> -			reg = <0xd8000000 0x1000>;
> -			interrupts = <29>;
> -			clocks = <&clks 54>;
> -			status = "disabled";
> +			reg = <0x80000000 0x20000000>;
> +			ranges;
> +		};
> +
> +		ahb2: ahb at a0000000 { /* Secondary AHB Slave Port 2 */
> +			compatible = "fsl,ahb-bus", "simple-bus";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			reg = <0xa0000000 0x40000000>;
> +			ranges;
> +
> +			nfc: nand at d8000000 {
> +				#address-cells = <1>;
> +				#size-cells = <1>;
> +				compatible = "fsl,imx27-nand";
> +				reg = <0xd8000000 0x1000>;
> +				interrupts = <29>;
> +				clocks = <&clks 54>;
> +				status = "disabled";
> +			};
>  		};
>  
>  		iram: iram at ffff4c00 {
> -- 
> 1.8.1.5
> 



From s.hauer at pengutronix.de  Mon Jul  1 09:03:43 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 1 Jul 2013 15:03:43 +0200
Subject: [v2 4/4] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <51D17AF1.2060504@gmail.com>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-5-git-send-email-r65037@freescale.com>
 <51D17AF1.2060504@gmail.com>
Message-ID: <20130701130343.GY516@pengutronix.de>

On Mon, Jul 01, 2013 at 07:49:53AM -0500, Rob Herring wrote:
> On 07/01/2013 05:02 AM, Richard Zhu wrote:
> > imx6q contains one Synopsys AHCI SATA controller,
> > But it can't shares ahci_platform driver with other
> > controllers.
> > Because there are some misalignments of the bits
> > definitions of the HBA registers and the Vendor
> > Specific registers
> >  - CAP_SSS(bit20) of the HOST_CAP is writable, default
> >  value is '0', should be configured to be '1'
> >  - bit0 (only one AHCI SATA port on imx6q) of the
> >  HOST_PORTS_IMPL should be set to be '1'.(default 0)
> >  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
> >  should be configured regarding to the frequency of AHB
> >  bus clock.
> 
> All this really belongs in the bootloader.

I beg to differ. Normally we do not write the kernel that it depends on
setup being done by the bootloader.

> Wouldn't you most likely be
> booting the kernel from SATA as well?

Having a SATA disk attached doesn't mean you boot from it.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From shawn.guo at linaro.org  Mon Jul  1 09:05:17 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 21:05:17 +0800
Subject: [PATCH 1/2] ARM: dts: mx53qsb: Enable VPU support
In-Reply-To: <1372459759-10488-1-git-send-email-festevam@gmail.com>
References: <1372459759-10488-1-git-send-email-festevam@gmail.com>
Message-ID: <20130701130516.GK13206@S2101-09.ap.freescale.net>

On Fri, Jun 28, 2013 at 07:49:18PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Enable Video Processing Unit (VPU) support.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Both applied, thanks.

Shawn



From trini at ti.com  Mon Jul  1 09:13:13 2013
From: trini at ti.com (Tom Rini)
Date: Mon,  1 Jul 2013 09:13:13 -0400
Subject: [PATCH] ARM: OMAP2+: omap2plus_defconfig: Enable appended DTB support
Message-ID: <1372684393-19025-1-git-send-email-trini@ti.com>

As this config must support boards which cannot support separate device
trees, enable support for appended ones.

Cc: Tony Lindgren <tony at atomide.com>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Tom Rini <trini at ti.com>
---
 arch/arm/configs/omap2plus_defconfig |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index abbe319..ec4deb9 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -34,6 +34,8 @@ CONFIG_NR_CPUS=2
 CONFIG_LEDS=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
 CONFIG_KEXEC=y
 CONFIG_FPE_NWFPE=y
-- 
1.7.9.5



From shawn.guo at linaro.org  Mon Jul  1 09:16:50 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 21:16:50 +0800
Subject: [PATCH] ARM: dts: imx6: add #dma-cells property for sdma
In-Reply-To: <1372665434-2515-1-git-send-email-b32955@freescale.com>
References: <1372665434-2515-1-git-send-email-b32955@freescale.com>
Message-ID: <20130701131648.GL13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 03:57:14PM +0800, Huang Shijie wrote:
> Add the #dma-cells property for imx6 sdma.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>
> ---
>  arch/arm/boot/dts/imx6qdl.dtsi |    1 +
>  arch/arm/boot/dts/imx6sl.dtsi  |    1 +

Can you please also update imx51.dtsi and imx53.dtsi?

Shawn

>  2 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index b381c85..ec5552b 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -581,6 +581,7 @@
>  				interrupts = <0 2 0x04>;
>  				clocks = <&clks 155>, <&clks 155>;
>  				clock-names = "ipg", "ahb";
> +				#dma-cells = <3>;
>  				fsl,sdma-ram-script-name = "imx/sdma/sdma-imx6q.bin";
>  			};
>  		};
> diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
> index c5e5da0..9138c67 100644
> --- a/arch/arm/boot/dts/imx6sl.dtsi
> +++ b/arch/arm/boot/dts/imx6sl.dtsi
> @@ -594,6 +594,7 @@
>  				clocks = <&clks IMX6SL_CLK_SDMA>,
>  					 <&clks IMX6SL_CLK_SDMA>;
>  				clock-names = "ipg", "ahb";
> +				#dma-cells = <3>;
>  				fsl,sdma-ram-script-name = "imx/sdma/sdma-imx6sl.bin";
>  			};
>  
> -- 
> 1.7.1
> 
> 



From girish.shivananjappa at linaro.org  Mon Jul  1 09:22:42 2013
From: girish.shivananjappa at linaro.org (Girish K S)
Date: Mon, 1 Jul 2013 18:52:42 +0530
Subject: [v2 4/4] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <51D17AF1.2060504@gmail.com>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-5-git-send-email-r65037@freescale.com>
 <51D17AF1.2060504@gmail.com>
Message-ID: <CAGxe1ZFb6TJyfSfSpRURu7tM8_h2sHQ5-qyQGSX5yQYFZrFX6A@mail.gmail.com>

On 1 July 2013 18:19, Rob Herring <robherring2 at gmail.com> wrote:
> On 07/01/2013 05:02 AM, Richard Zhu wrote:
>> imx6q contains one Synopsys AHCI SATA controller,
>> But it can't shares ahci_platform driver with other
>> controllers.
>> Because there are some misalignments of the bits
>> definitions of the HBA registers and the Vendor
>> Specific registers
>>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>>  value is '0', should be configured to be '1'
>>  - bit0 (only one AHCI SATA port on imx6q) of the
>>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>>  should be configured regarding to the frequency of AHB
>>  bus clock.
>
> All this really belongs in the bootloader. Wouldn't you most likely be
> booting the kernel from SATA as well? The first 2 are write once bits so
> setting them a 2nd time would have no effect.

Even though its done in bootloader. It should be initialized in
kernel. For a "suspend to disk" use case. If power to SATA controller
is cut during suspend. Then this init sequence should be used
>
> I also agree that if this added, it should be added to the existing driver.
>
> Rob
>
>>
>> Setup its own ahci sata driver, enable the imx6q ahci
>> sata support, and update the ahci sata binding document.
>>
>> Signed-off-by: Richard Zhu <r65037 at freescale.com>
>> ---
>>  .../devicetree/bindings/ata/ahci-platform.txt      |    2 +-
>>  drivers/ata/Kconfig                                |    8 +
>>  drivers/ata/Makefile                               |    1 +
>>  drivers/ata/sata_imx.c                             |  349 ++++++++++++++++++++
>>  4 files changed, 359 insertions(+), 1 deletions(-)
>>  create mode 100644 drivers/ata/sata_imx.c
>>
>> diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
>> index b519f9b..e252620 100644
>> --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
>> +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
>> @@ -4,7 +4,7 @@ SATA nodes are defined to describe on-chip Serial ATA controllers.
>>  Each SATA controller should have its own node.
>>
>>  Required properties:
>> -- compatible        : compatible list, contains "calxeda,hb-ahci" or "snps,spear-ahci"
>> +- compatible        : compatible list, contains "calxeda,hb-ahci", "snps,spear-ahci" or "snps, imx-ahci"
>>  - interrupts        : <interrupt mapping for SATA IRQ>
>>  - reg               : <registers mapping>
>>
>> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
>> index a5a3ebc..893fa0b 100644
>> --- a/drivers/ata/Kconfig
>> +++ b/drivers/ata/Kconfig
>> @@ -236,6 +236,14 @@ config SATA_HIGHBANK
>>
>>         If unsure, say N.
>>
>> +config SATA_IMX
>> +     tristate "Freescale iMX AHCI SATA support"
>> +     help
>> +       This option enables support for the Freescale iMX SoC's
>> +       onboard AHCI SATA.
>> +
>> +       If unsure, say N.
>> +
>>  config SATA_MV
>>       tristate "Marvell SATA support"
>>       help
>> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
>> index c04d0fd..c40b328 100644
>> --- a/drivers/ata/Makefile
>> +++ b/drivers/ata/Makefile
>> @@ -10,6 +10,7 @@ obj-$(CONFIG_SATA_INIC162X) += sata_inic162x.o
>>  obj-$(CONFIG_SATA_SIL24)     += sata_sil24.o
>>  obj-$(CONFIG_SATA_DWC)               += sata_dwc_460ex.o
>>  obj-$(CONFIG_SATA_HIGHBANK)  += sata_highbank.o libahci.o
>> +obj-$(CONFIG_SATA_IMX)               += sata_imx.o libahci.o
>>
>>  # SFF w/ custom DMA
>>  obj-$(CONFIG_PDC_ADMA)               += pdc_adma.o
>> diff --git a/drivers/ata/sata_imx.c b/drivers/ata/sata_imx.c
>> new file mode 100644
>> index 0000000..2be92e8
>> --- /dev/null
>> +++ b/drivers/ata/sata_imx.c
>> @@ -0,0 +1,349 @@
>> +/*
>> + * Freescale IMX AHCI SATA platform driver
>> + * Copyright 2013 Freescale Semiconductor, Inc.
>> + *
>> + * based on the AHCI SATA platform driver by Jeff Garzik and Anton Vorontsov
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope 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.
>> + *
>> + * You should have received a copy of the GNU General Public License along with
>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/kernel.h>
>> +#include <linux/gfp.h>
>> +#include <linux/module.h>
>> +#include <linux/pm.h>
>> +#include <linux/init.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/libata.h>
>> +#include <linux/ahci_platform.h>
>> +#include "ahci.h"
>> +
>> +enum {
>> +     HOST_TIMER1MS = 0xe0, /* Timer 1-ms */
>> +};
>> +
>> +static void ahci_imx_host_stop(struct ata_host *host);
>> +
>> +static struct ata_port_operations ahci_imx_platform_ops = {
>> +     .inherits       = &ahci_ops,
>> +     .host_stop      = ahci_imx_host_stop,
>> +};
>> +
>> +static const struct ata_port_info ahci_imx_port_info = {
>> +     .flags          = AHCI_FLAG_COMMON,
>> +     .pio_mask       = ATA_PIO4,
>> +     .udma_mask      = ATA_UDMA6,
>> +     .port_ops       = &ahci_imx_platform_ops,
>> +};
>> +
>> +static struct scsi_host_template ahci_imx_platform_sht = {
>> +     AHCI_SHT("sata_imx"),
>> +};
>> +
>> +/*
>> + * Configure the HWINIT bits of the HOST_CAP and HOST_PORTS_IMPL,
>> + * and IP vendor specific register HOST_TIMER1MS.
>> + *
>> + * Configure CAP_SSS (support stagered spin up).
>> + * Implement the port0.
>> + * Get the ahb clock rate, and configure the TIMER1MS register.
>> + */
>> +static int imx_sata_init(void __iomem *mmio)
>> +{
>> +     int ret;
>> +     struct clk *ahb_clk;
>> +
>> +     ret = readl(mmio + HOST_CAP);
>> +     if (!(ret & HOST_CAP_SSS))
>> +             writel(ret |= HOST_CAP_SSS, mmio + HOST_CAP);
>> +     ret = readl(mmio + HOST_PORTS_IMPL);
>> +     if (!(ret & 0x1))
>> +             writel((ret | 0x1), mmio + HOST_PORTS_IMPL);
>> +     ahb_clk = clk_get_sys(NULL, "ahb");
>> +     if (IS_ERR(ahb_clk)) {
>> +             pr_err("no ahb clock.\n");
>> +             ret = PTR_ERR(ahb_clk);
>> +             return ret;
>> +     }
>> +     ret = clk_get_rate(ahb_clk) / 1000;
>> +     clk_put(ahb_clk);
>> +     writel(ret, mmio + HOST_TIMER1MS);
>> +
>> +     return ret;
>> +}
>> +
>> +static int ahci_imx_probe(struct platform_device *pdev)
>> +{
>> +     struct device *dev = &pdev->dev;
>> +     struct ahci_platform_data *pdata = dev_get_platdata(dev);
>> +     struct ata_port_info pi = ahci_imx_port_info;
>> +     const struct ata_port_info *ppi[] = { &pi, NULL };
>> +     struct ahci_host_priv *hpriv;
>> +     struct ata_host *host;
>> +     struct resource *mem;
>> +     int irq;
>> +     int n_ports;
>> +     int i;
>> +     int rc;
>> +
>> +     mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +     if (!mem) {
>> +             dev_err(dev, "no mmio space\n");
>> +             return -EINVAL;
>> +     }
>> +
>> +     irq = platform_get_irq(pdev, 0);
>> +     if (irq <= 0) {
>> +             dev_err(dev, "no irq\n");
>> +             return -EINVAL;
>> +     }
>> +
>> +     if (pdata && pdata->ata_port_info)
>> +             pi = *pdata->ata_port_info;
>> +
>> +     hpriv = devm_kzalloc(dev, sizeof(*hpriv), GFP_KERNEL);
>> +     if (!hpriv) {
>> +             dev_err(dev, "can't alloc ahci_host_priv\n");
>> +             return -ENOMEM;
>> +     }
>> +
>> +     hpriv->flags |= (unsigned long)pi.private_data;
>> +
>> +     hpriv->mmio = devm_ioremap(dev, mem->start, resource_size(mem));
>> +     if (!hpriv->mmio) {
>> +             dev_err(dev, "can't map %pR\n", mem);
>> +             return -ENOMEM;
>> +     }
>> +
>> +     hpriv->clk = clk_get(dev, NULL);
>> +     if (IS_ERR(hpriv->clk)) {
>> +             dev_err(dev, "can't get clock\n");
>> +     } else {
>> +             rc = clk_prepare_enable(hpriv->clk);
>> +             if (rc) {
>> +                     dev_err(dev, "clock prepare enable failed");
>> +                     goto free_clk;
>> +             }
>> +     }
>> +
>> +     /*
>> +      * Some platforms might need to prepare for mmio region access,
>> +      * which could be done in the following init call. So, the mmio
>> +      * region shouldn't be accessed before init (if provided) has
>> +      * returned successfully.
>> +      */
>> +     if (pdata && pdata->init) {
>> +             rc = pdata->init(dev, hpriv->mmio);
>> +             if (rc)
>> +                     goto disable_unprepare_clk;
>> +     }
>> +
>> +     rc = imx_sata_init(hpriv->mmio);
>> +     if (rc < 0)
>> +             goto pdata_exit;
>> +
>> +     ahci_save_initial_config(dev, hpriv,
>> +             pdata ? pdata->force_port_map : 0,
>> +             pdata ? pdata->mask_port_map  : 0);
>> +
>> +     /* prepare host */
>> +     if (hpriv->cap & HOST_CAP_NCQ)
>> +             pi.flags |= ATA_FLAG_NCQ;
>> +
>> +     if (hpriv->cap & HOST_CAP_PMP)
>> +             pi.flags |= ATA_FLAG_PMP;
>> +
>> +     ahci_set_em_messages(hpriv, &pi);
>> +
>> +     /* CAP.NP sometimes indicate the index of the last enabled
>> +      * port, at other times, that of the last possible port, so
>> +      * determining the maximum port number requires looking at
>> +      * both CAP.NP and port_map.
>> +      */
>> +     n_ports = max(ahci_nr_ports(hpriv->cap), fls(hpriv->port_map));
>> +
>> +     host = ata_host_alloc_pinfo(dev, ppi, n_ports);
>> +     if (!host) {
>> +             rc = -ENOMEM;
>> +             goto pdata_exit;
>> +     }
>> +
>> +     host->private_data = hpriv;
>> +
>> +     if (!(hpriv->cap & HOST_CAP_SSS) || ahci_ignore_sss)
>> +             host->flags |= ATA_HOST_PARALLEL_SCAN;
>> +     else
>> +             dev_info(dev, "ahci: SSS flag set, parallel bus scan disabled\n");
>> +
>> +     if (pi.flags & ATA_FLAG_EM)
>> +             ahci_reset_em(host);
>> +
>> +     for (i = 0; i < host->n_ports; i++) {
>> +             struct ata_port *ap = host->ports[i];
>> +
>> +             ata_port_desc(ap, "mmio %pR", mem);
>> +             ata_port_desc(ap, "port 0x%x", 0x100 + ap->port_no * 0x80);
>> +
>> +             /* set enclosure management message type */
>> +             if (ap->flags & ATA_FLAG_EM)
>> +                     ap->em_message_type = hpriv->em_msg_type;
>> +
>> +             /* disabled/not-implemented port */
>> +             if (!(hpriv->port_map & (1 << i)))
>> +                     ap->ops = &ata_dummy_port_ops;
>> +     }
>> +
>> +     rc = ahci_reset_controller(host);
>> +     if (rc)
>> +             goto pdata_exit;
>> +
>> +     ahci_init_controller(host);
>> +     ahci_print_info(host, "platform");
>> +
>> +     rc = ata_host_activate(host, irq, ahci_interrupt, IRQF_SHARED,
>> +                            &ahci_imx_platform_sht);
>> +     if (rc)
>> +             goto pdata_exit;
>> +
>> +     return 0;
>> +pdata_exit:
>> +     if (pdata && pdata->exit)
>> +             pdata->exit(dev);
>> +disable_unprepare_clk:
>> +     if (!IS_ERR(hpriv->clk))
>> +             clk_disable_unprepare(hpriv->clk);
>> +free_clk:
>> +     if (!IS_ERR(hpriv->clk))
>> +             clk_put(hpriv->clk);
>> +     return rc;
>> +}
>> +
>> +static void ahci_imx_host_stop(struct ata_host *host)
>> +{
>> +     struct device *dev = host->dev;
>> +     struct ahci_platform_data *pdata = dev_get_platdata(dev);
>> +     struct ahci_host_priv *hpriv = host->private_data;
>> +
>> +     if (pdata && pdata->exit)
>> +             pdata->exit(dev);
>> +
>> +     if (!IS_ERR(hpriv->clk)) {
>> +             clk_disable_unprepare(hpriv->clk);
>> +             clk_put(hpriv->clk);
>> +     }
>> +}
>> +
>> +#ifdef CONFIG_PM_SLEEP
>> +static int ahci_imx_suspend(struct device *dev)
>> +{
>> +     struct ahci_platform_data *pdata = dev_get_platdata(dev);
>> +     struct ata_host *host = dev_get_drvdata(dev);
>> +     struct ahci_host_priv *hpriv = host->private_data;
>> +     void __iomem *mmio = hpriv->mmio;
>> +     u32 ctl;
>> +     int rc;
>> +
>> +     if (hpriv->flags & AHCI_HFLAG_NO_SUSPEND) {
>> +             dev_err(dev, "firmware update required for suspend/resume\n");
>> +             return -EIO;
>> +     }
>> +
>> +     /*
>> +      * AHCI spec rev1.1 section 8.3.3:
>> +      * Software must disable interrupts prior to requesting a
>> +      * transition of the HBA to D3 state.
>> +      */
>> +     ctl = readl(mmio + HOST_CTL);
>> +     ctl &= ~HOST_IRQ_EN;
>> +     writel(ctl, mmio + HOST_CTL);
>> +     readl(mmio + HOST_CTL); /* flush */
>> +
>> +     rc = ata_host_suspend(host, PMSG_SUSPEND);
>> +     if (rc)
>> +             return rc;
>> +
>> +     if (pdata && pdata->suspend)
>> +             return pdata->suspend(dev);
>> +
>> +     if (!IS_ERR(hpriv->clk))
>> +             clk_disable_unprepare(hpriv->clk);
>> +
>> +     return 0;
>> +}
>> +
>> +static int ahci_imx_resume(struct device *dev)
>> +{
>> +     struct ahci_platform_data *pdata = dev_get_platdata(dev);
>> +     struct ata_host *host = dev_get_drvdata(dev);
>> +     struct ahci_host_priv *hpriv = host->private_data;
>> +     int rc;
>> +
>> +     if (!IS_ERR(hpriv->clk)) {
>> +             rc = clk_prepare_enable(hpriv->clk);
>> +             if (rc) {
>> +                     dev_err(dev, "clock prepare enable failed");
>> +                     return rc;
>> +             }
>> +     }
>> +
>> +     if (pdata && pdata->resume) {
>> +             rc = pdata->resume(dev);
>> +             if (rc)
>> +                     goto disable_unprepare_clk;
>> +     }
>> +
>> +     if (dev->power.power_state.event == PM_EVENT_SUSPEND) {
>> +             rc = ahci_reset_controller(host);
>> +             if (rc)
>> +                     goto disable_unprepare_clk;
>> +
>> +             ahci_init_controller(host);
>> +     }
>> +
>> +     ata_host_resume(host);
>> +
>> +     return 0;
>> +
>> +disable_unprepare_clk:
>> +     if (!IS_ERR(hpriv->clk))
>> +             clk_disable_unprepare(hpriv->clk);
>> +
>> +     return rc;
>> +}
>> +#endif
>> +
>> +static SIMPLE_DEV_PM_OPS(ahci_imx_pm_ops, ahci_imx_suspend, ahci_imx_resume);
>> +
>> +static const struct of_device_id ahci_of_match[] = {
>> +     { .compatible = "snps,imx-ahci", },
>> +     {},
>> +};
>> +MODULE_DEVICE_TABLE(of, ahci_of_match);
>> +
>> +static struct platform_driver ahci_imx_driver = {
>> +     .probe = ahci_imx_probe,
>> +     .remove = ata_platform_remove_one,
>> +     .driver = {
>> +             .name = "imx-ahci",
>> +             .owner = THIS_MODULE,
>> +             .of_match_table = ahci_of_match,
>> +             .pm = &ahci_imx_pm_ops,
>> +     },
>> +};
>> +module_platform_driver(ahci_imx_driver);
>> +
>> +MODULE_DESCRIPTION("FREESCALE IMX AHCI SATA platform driver");
>> +MODULE_LICENSE("GPL");
>> +MODULE_ALIAS("sata:imx");
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From alexandre.belloni at free-electrons.com  Mon Jul  1 09:23:22 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Mon,  1 Jul 2013 15:23:22 +0200
Subject: [PATCHv4 1/8] ARM: mxs: Simplify detection of CrystalFontz boards
In-Reply-To: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
References: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <1372685009-15564-2-git-send-email-alexandre.belloni@free-electrons.com>

As all CrystalFontz boards are compatible with "crystalfontz,cfa10036", make it
easier to add future boards.

Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/mach-mxs/mach-mxs.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
index 6298adb..1b8c274 100644
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@ -478,10 +478,7 @@ static void __init mxs_machine_init(void)
 		imx28_evk_init();
 	else if (of_machine_is_compatible("bluegiga,apx4devkit"))
 		apx4devkit_init();
-	else if (of_machine_is_compatible("crystalfontz,cfa10037") ||
-		 of_machine_is_compatible("crystalfontz,cfa10049") ||
-		 of_machine_is_compatible("crystalfontz,cfa10055") ||
-		 of_machine_is_compatible("crystalfontz,cfa10057"))
+	else if (of_machine_is_compatible("crystalfontz,cfa10036"))
 		crystalfontz_init();
 
 	of_platform_populate(NULL, of_default_bus_match_table,
-- 
1.8.1.2



From alexandre.belloni at free-electrons.com  Mon Jul  1 09:23:25 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Mon,  1 Jul 2013 15:23:25 +0200
Subject: [PATCHv4 4/8] ARM: mxs: dt: cfa10037: make hogpins grabbed by
 respective drivers
In-Reply-To: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
References: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <1372685009-15564-5-git-send-email-alexandre.belloni@free-electrons.com>

Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/imx28-cfa10037.dts | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-cfa10037.dts b/arch/arm/boot/dts/imx28-cfa10037.dts
index c2ef3a3..182b99f 100644
--- a/arch/arm/boot/dts/imx28-cfa10037.dts
+++ b/arch/arm/boot/dts/imx28-cfa10037.dts
@@ -22,13 +22,19 @@
 	apb at 80000000 {
 		apbh at 80000000 {
 			pinctrl at 80018000 {
-				pinctrl-names = "default", "default";
-				pinctrl-1 = <&hog_pins_cfa10037>;
-
-				hog_pins_cfa10037: hog-10037 at 0 {
+				usb_pins_cfa10037: usb-10037 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
 						0x0073 /* MX28_PAD_GPMI_D7__GPIO_0_7 */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+
+				mac0_pins_cfa10037: mac0-10037 at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
 						0x2153 /* MX28_PAD_SSP2_D5__GPIO_2_21 */
 					>;
 					fsl,drive-strength = <0>;
@@ -56,7 +62,8 @@
 		mac0: ethernet at 800f0000 {
 			phy-mode = "rmii";
 			pinctrl-names = "default";
-			pinctrl-0 = <&mac0_pins_a>;
+			pinctrl-0 = <&mac0_pins_a
+				&mac0_pins_cfa10037>;
 			phy-reset-gpios = <&gpio2 21 0>;
 			phy-reset-duration = <100>;
 			status = "okay";
@@ -68,6 +75,8 @@
 
 		reg_usb1_vbus: usb1_vbus {
 			compatible = "regulator-fixed";
+			pinctrl-names = "default";
+			pinctrl-0 = <&usb_pins_cfa10037>;
 			regulator-name = "usb1_vbus";
 			regulator-min-microvolt = <5000000>;
 			regulator-max-microvolt = <5000000>;
-- 
1.8.1.2



From alexandre.belloni at free-electrons.com  Mon Jul  1 09:23:21 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Mon,  1 Jul 2013 15:23:21 +0200
Subject: [PATCHv4 0/8] ARM: mxs: Various Crystalfontz DT additions
Message-ID: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>

Hi,

This patch series add DT for the Crystalfontz CFA-10056 and Crystalfontz
CFA-10058.

The first patch simplifies board detection in mach-mxs.c as suggested by Thomas
Petazzoni in his review of the precedent DT additions.

The next two patches are adding the DTs.

The last patches are cleaning up the remaining boards DTs.

Changes in v4
 - corrected comment for cfa-10056 and made it cfa-10037 compatible
 - reordered patches

Changes in v3
 - Cleaned up all the DTs for crystalfontz boards.

Changes in v2:
 - took into account the review from Maxime Ripard

Thanks,

Alexandre Belloni (6):
  ARM: mxs: Simplify detection of CrystalFontz boards
  ARM: mxs: dt: cfa10037: make hogpins grabbed by respective drivers
  ARM: mxs: dt: cfa10049: make hogpins grabbed by respective drivers
  ARM: mxs: dt: cfa10055: make hogpins grabbed by respective drivers
  ARM: mxs: dt: cfa10057: remove hogpins
  ARM: mxs: dt: cfa10036: make hogpins grabbed by respective drivers

Brian Lilly (2):
  ARM: mxs: dt: Add Crystalfontz CFA-10056 device tree
  ARM: mxs: dt: Add Crystalfontz CFA-10058 device tree

 arch/arm/boot/dts/Makefile           |   2 +
 arch/arm/boot/dts/imx28-cfa10036.dts |   7 +-
 arch/arm/boot/dts/imx28-cfa10037.dts |  19 +++--
 arch/arm/boot/dts/imx28-cfa10049.dts |  73 +++++++++++++++---
 arch/arm/boot/dts/imx28-cfa10055.dts |  38 ++++------
 arch/arm/boot/dts/imx28-cfa10056.dts | 119 +++++++++++++++++++++++++++++
 arch/arm/boot/dts/imx28-cfa10057.dts |  23 +-----
 arch/arm/boot/dts/imx28-cfa10058.dts | 141 +++++++++++++++++++++++++++++++++++
 arch/arm/mach-mxs/mach-mxs.c         |   5 +-
 9 files changed, 359 insertions(+), 68 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx28-cfa10056.dts
 create mode 100644 arch/arm/boot/dts/imx28-cfa10058.dts

-- 
1.8.1.2



From alexandre.belloni at free-electrons.com  Mon Jul  1 09:23:24 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Mon,  1 Jul 2013 15:23:24 +0200
Subject: [PATCHv4 3/8] ARM: mxs: dt: Add Crystalfontz CFA-10058 device tree
In-Reply-To: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
References: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <1372685009-15564-4-git-send-email-alexandre.belloni@free-electrons.com>

From: Brian Lilly <brian at crystalfontz.com>

The CFA-10058 is a breakout board for the CFA-10036 that has Ethernet, USB and a
5" LCD screen on it.

Signed-off-by: Brian Lilly <brian at crystalfontz.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/Makefile           |   1 +
 arch/arm/boot/dts/imx28-cfa10058.dts | 141 +++++++++++++++++++++++++++++++++++
 2 files changed, 142 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx28-cfa10058.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index da75139..92d66cf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -145,6 +145,7 @@ dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
 	imx28-cfa10055.dtb \
 	imx28-cfa10056.dtb \
 	imx28-cfa10057.dtb \
+	imx28-cfa10058.dtb \
 	imx28-evk.dtb \
 	imx28-m28evk.dtb \
 	imx28-sps1.dtb \
diff --git a/arch/arm/boot/dts/imx28-cfa10058.dts b/arch/arm/boot/dts/imx28-cfa10058.dts
new file mode 100644
index 0000000..64c64c5
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-cfa10058.dts
@@ -0,0 +1,141 @@
+/*
+ * Copyright 2013 Crystalfontz America, Inc.
+ * Copyright 2013 Free Electrons
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/*
+ * The CFA-10058 is an expansion board for the CFA-10036 module, thus we
+ * need to include the CFA-10036 DTS.
+ */
+/include/ "imx28-cfa10036.dts"
+
+/ {
+	model = "Crystalfontz CFA-10058 Board";
+	compatible = "crystalfontz,cfa10058", "crystalfontz,cfa10036", "fsl,imx28";
+
+	apb at 80000000 {
+		apbh at 80000000 {
+			pinctrl at 80018000 {
+				usb_pins_cfa10058: usb-10058 at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x0073 /* MX28_PAD_GPMI_D7__GPIO_0_7 */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+
+				lcdif_pins_cfa10058: lcdif-10058 at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x1181 /* MX28_PAD_LCD_RD_E__LCD_VSYNC */
+						0x1191 /* MX28_PAD_LCD_WR_RWN__LCD_HSYNC */
+						0x11a1 /* MX28_PAD_LCD_RS__LCD_DOTCLK */
+						0x11b1 /* MX28_PAD_LCD_CS__LCD_ENABLE */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+			};
+
+			lcdif at 80030000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&lcdif_24bit_pins_a
+						 &lcdif_pins_cfa10058>;
+				display = <&display>;
+				status = "okay";
+
+				display: display {
+					bits-per-pixel = <32>;
+					bus-width = <24>;
+
+					display-timings {
+						native-mode = <&timing0>;
+						timing0: timing0 {
+							clock-frequency = <30000000>;
+							hactive = <800>;
+							vactive = <480>;
+							hback-porch = <40>;
+							hfront-porch = <40>;
+							vback-porch = <13>;
+							vfront-porch = <29>;
+							hsync-len = <8>;
+							vsync-len = <8>;
+							hsync-active = <0>;
+							vsync-active = <0>;
+							de-active = <1>;
+							pixelclk-active = <1>;
+						};
+					};
+				};
+			};
+		};
+
+		apbx at 80040000 {
+			lradc at 80050000 {
+				fsl,lradc-touchscreen-wires = <4>;
+				status = "okay";
+			};
+
+			pwm: pwm at 80064000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&pwm3_pins_b>;
+				status = "okay";
+			};
+
+			usbphy1: usbphy at 8007e000 {
+				status = "okay";
+			};
+		};
+	};
+
+	ahb at 80080000 {
+		usb1: usb at 80090000 {
+			vbus-supply = <&reg_usb1_vbus>;
+			pinctrl-0 = <&usbphy1_pins_a>;
+			pinctrl-names = "default";
+			status = "okay";
+		};
+	};
+
+	regulators {
+		compatible = "simple-bus";
+
+		reg_usb1_vbus: usb1_vbus {
+			pinctrl-names = "default";
+			pinctrl-0 = <&usb_pins_cfa10058>;
+			compatible = "regulator-fixed";
+			regulator-name = "usb1_vbus";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			gpio = <&gpio0 7 1>;
+		};
+	};
+
+	ahb at 80080000 {
+		mac0: ethernet at 800f0000 {
+			phy-mode = "rmii";
+			pinctrl-names = "default";
+			pinctrl-0 = <&mac0_pins_a>;
+			phy-reset-gpios = <&gpio2 21 0>;
+			phy-reset-duration = <100>;
+			status = "okay";
+		};
+	};
+
+	backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm 3 5000000>;
+		brightness-levels = <0 4 8 16 32 64 128 255>;
+		default-brightness-level = <6>;
+	};
+};
-- 
1.8.1.2



From alexandre.belloni at free-electrons.com  Mon Jul  1 09:23:23 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Mon,  1 Jul 2013 15:23:23 +0200
Subject: [PATCHv4 2/8] ARM: mxs: dt: Add Crystalfontz CFA-10056 device tree
In-Reply-To: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
References: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <1372685009-15564-3-git-send-email-alexandre.belloni@free-electrons.com>

From: Brian Lilly <brian at crystalfontz.com>

The CFA-10056 is a breakout board for the CFA-10036, and is
basically a CFA-10037, with a 4.3" screen.

Signed-off-by: Brian Lilly <brian at crystalfontz.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
---
 arch/arm/boot/dts/Makefile           |   1 +
 arch/arm/boot/dts/imx28-cfa10056.dts | 119 +++++++++++++++++++++++++++++++++++
 2 files changed, 120 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx28-cfa10056.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..da75139 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -143,6 +143,7 @@ dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
 	imx28-cfa10037.dtb \
 	imx28-cfa10049.dtb \
 	imx28-cfa10055.dtb \
+	imx28-cfa10056.dtb \
 	imx28-cfa10057.dtb \
 	imx28-evk.dtb \
 	imx28-m28evk.dtb \
diff --git a/arch/arm/boot/dts/imx28-cfa10056.dts b/arch/arm/boot/dts/imx28-cfa10056.dts
new file mode 100644
index 0000000..b45dd0e
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-cfa10056.dts
@@ -0,0 +1,119 @@
+/*
+ * Copyright 2013 Free Electrons
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/*
+ * The CFA-10055 is an expansion board for the CFA-10036 module and
+ * CFA-10037, thus we need to include the CFA-10037 DTS.
+ */
+/include/ "imx28-cfa10037.dts"
+
+/ {
+	model = "Crystalfontz CFA-10056 Board";
+	compatible = "crystalfontz,cfa10056", "crystalfontz,cfa10037", "crystalfontz,cfa10036", "fsl,imx28";
+
+	apb at 80000000 {
+		apbh at 80000000 {
+			pinctrl at 80018000 {
+				spi2_pins_cfa10056: spi2-cfa10056 at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x2103 /* MX28_PAD_SSP2_SCK__GPIO_2_16 */
+						0x2113 /* MX28_PAD_SSP2_CMD__GPIO_2_17 */
+						0x2123 /* MX28_PAD_SSP2_D0__GPIO_2_18 */
+						0x3053 /* MX28_PAD_AUART1_TX__GPIO_3_5 */
+					>;
+					fsl,drive-strength = <1>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <1>;
+				};
+
+				lcdif_pins_cfa10056: lcdif-10056 at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x1181 /* MX28_PAD_LCD_RD_E__LCD_VSYNC */
+						0x1191 /* MX28_PAD_LCD_WR_RWN__LCD_HSYNC */
+						0x11a1 /* MX28_PAD_LCD_RS__LCD_DOTCLK */
+						0x11b1 /* MX28_PAD_LCD_CS__LCD_ENABLE */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+
+				lcdif_pins_cfa10056_pullup: lcdif-10056-pullup at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x31e3 /* MX28_PAD_LCD_RESET__GPIO_3_30 */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <1>;
+				};
+			};
+
+			lcdif at 80030000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&lcdif_24bit_pins_a
+						&lcdif_pins_cfa10056
+						&lcdif_pins_cfa10056_pullup >;
+				display = <&display>;
+				status = "okay";
+
+				display: display {
+					bits-per-pixel = <32>;
+					bus-width = <24>;
+
+					display-timings {
+						native-mode = <&timing0>;
+						timing0: timing0 {
+							clock-frequency = <32000000>;
+							hactive = <480>;
+							vactive = <800>;
+							hback-porch = <2>;
+							hfront-porch = <2>;
+							vback-porch = <2>;
+							vfront-porch = <2>;
+							hsync-len = <5>;
+							vsync-len = <5>;
+							hsync-active = <0>;
+							vsync-active = <0>;
+							de-active = <1>;
+							pixelclk-active = <1>;
+						};
+					};
+				};
+			};
+		};
+	};
+
+	spi2 {
+		compatible = "spi-gpio";
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi2_pins_cfa10056>;
+		status = "okay";
+		gpio-sck = <&gpio2 16 0>;
+		gpio-mosi = <&gpio2 17 0>;
+		gpio-miso = <&gpio2 18 0>;
+		cs-gpios = <&gpio3 5 0>;
+		num-chipselects = <1>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		hx8369: hx8369 at 0 {
+			compatible = "himax,hx8369a", "himax,hx8369";
+			reg = <0>;
+			spi-max-frequency = <100000>;
+			spi-cpol;
+			spi-cpha;
+			gpios-reset = <&gpio3 30 0>;
+		};
+	};
+};
-- 
1.8.1.2



From alexandre.belloni at free-electrons.com  Mon Jul  1 09:23:28 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Mon,  1 Jul 2013 15:23:28 +0200
Subject: [PATCHv4 7/8] ARM: mxs: dt: cfa10057: remove hogpins
In-Reply-To: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
References: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <1372685009-15564-8-git-send-email-alexandre.belloni@free-electrons.com>

Necessary pins are now grabbed by respective drivers. Unecessary hogpins are
simply removed.

Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/imx28-cfa10057.dts | 23 +++--------------------
 1 file changed, 3 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-cfa10057.dts b/arch/arm/boot/dts/imx28-cfa10057.dts
index 2da713c..0333c05 100644
--- a/arch/arm/boot/dts/imx28-cfa10057.dts
+++ b/arch/arm/boot/dts/imx28-cfa10057.dts
@@ -23,35 +23,16 @@
 	apb at 80000000 {
 		apbh at 80000000 {
 			pinctrl at 80018000 {
-				pinctrl-names = "default", "default";
-				pinctrl-1 = <&hog_pins_cfa10057
-					&hog_pins_cfa10057_pullup>;
-
-				hog_pins_cfa10057: hog-10057 at 0 {
+				usb_pins_cfa10057: usb-10057 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
 						0x0073 /* MX28_PAD_GPMI_D7__GPIO_0_7 */
-						0x3053 /* MX28_PAD_AUART1_TX__GPIO_3_5 */
 					>;
 					fsl,drive-strength = <0>;
 					fsl,voltage = <1>;
 					fsl,pull-up = <0>;
 				};
 
-				hog_pins_cfa10057_pullup: hog-10057-pullup at 0 {
-					reg = <0>;
-					fsl,pinmux-ids = <
-						0x2133 /* MX28_PAD_SSP2_D3__GPIO_2_19 */
-						0x3183 /* MX28_PAD_I2C0_SCL__GPIO_3_24 */
-						0x3193 /* MX28_PAD_I2C0_SDA__GPIO_3_25 */
-						0x31a3 /* MX28_PAD_SAIF_SDATA0__GPIO_3_26 */
-						0x31e3 /* MX28_PAD_LCD_RESET__GPIO_3_30 */
-					>;
-					fsl,drive-strength = <0>;
-					fsl,voltage = <1>;
-					fsl,pull-up = <1>;
-				};
-
 				lcdif_18bit_pins_cfa10057: lcdif-18bit at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
@@ -164,6 +145,8 @@
 
 		reg_usb1_vbus: usb1_vbus {
 			compatible = "regulator-fixed";
+			pinctrl-names = "default";
+			pinctrl-0 = <&usb_pins_cfa10057>;
 			regulator-name = "usb1_vbus";
 			regulator-min-microvolt = <5000000>;
 			regulator-max-microvolt = <5000000>;
-- 
1.8.1.2



From alexandre.belloni at free-electrons.com  Mon Jul  1 09:23:29 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Mon,  1 Jul 2013 15:23:29 +0200
Subject: [PATCHv4 8/8] ARM: mxs: dt: cfa10036: make hogpins grabbed by
 respective drivers
In-Reply-To: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
References: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <1372685009-15564-9-git-send-email-alexandre.belloni@free-electrons.com>

Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/imx28-cfa10036.dts | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-cfa10036.dts b/arch/arm/boot/dts/imx28-cfa10036.dts
index 94c4476..1ec8c94 100644
--- a/arch/arm/boot/dts/imx28-cfa10036.dts
+++ b/arch/arm/boot/dts/imx28-cfa10036.dts
@@ -23,10 +23,7 @@
 	apb at 80000000 {
 		apbh at 80000000 {
 			pinctrl at 80018000 {
-				pinctrl-names = "default";
-				pinctrl-0 = <&hog_pins_cfa10036>;
-
-				hog_pins_cfa10036: hog-10036 at 0 {
+				ssd1306_cfa10036: ssd1306-10036 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
 						0x2073 /* MX28_PAD_SSP0_D7__GPIO_2_7 */
@@ -83,6 +80,8 @@
 
 				ssd1306: oled at 3c {
 					compatible = "solomon,ssd1306fb-i2c";
+					pinctrl-names = "default";
+					pinctrl-0 = <&ssd1306_cfa10036>;
 					reg = <0x3c>;
 					reset-gpios = <&gpio2 7 0>;
 					solomon,height = <32>;
-- 
1.8.1.2



From alexandre.belloni at free-electrons.com  Mon Jul  1 09:23:27 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Mon,  1 Jul 2013 15:23:27 +0200
Subject: [PATCHv4 6/8] ARM: mxs: dt: cfa10055: make hogpins grabbed by
 respective drivers
In-Reply-To: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
References: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <1372685009-15564-7-git-send-email-alexandre.belloni@free-electrons.com>

Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/imx28-cfa10055.dts | 38 ++++++++++++------------------------
 1 file changed, 13 insertions(+), 25 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-cfa10055.dts b/arch/arm/boot/dts/imx28-cfa10055.dts
index 1581112..171bcbe 100644
--- a/arch/arm/boot/dts/imx28-cfa10055.dts
+++ b/arch/arm/boot/dts/imx28-cfa10055.dts
@@ -23,36 +23,13 @@
 	apb at 80000000 {
 		apbh at 80000000 {
 			pinctrl at 80018000 {
-				pinctrl-names = "default", "default";
-				pinctrl-1 = <&hog_pins_cfa10055
-					&hog_pins_cfa10055_pullup>;
-
-				hog_pins_cfa10055: hog-10055 at 0 {
-					reg = <0>;
-					fsl,pinmux-ids = <
-						0x3053 /* MX28_PAD_AUART1_TX__GPIO_3_5 */
-					>;
-					fsl,drive-strength = <0>;
-					fsl,voltage = <1>;
-					fsl,pull-up = <0>;
-				};
-
-				hog_pins_cfa10055_pullup: hog-10055-pullup at 0 {
-					reg = <0>;
-					fsl,pinmux-ids = <
-						0x31e3 /* MX28_PAD_LCD_RESET__GPIO_3_30 */
-					>;
-					fsl,drive-strength = <0>;
-					fsl,voltage = <1>;
-					fsl,pull-up = <1>;
-				};
-
 				spi2_pins_cfa10055: spi2-cfa10055 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
 						0x2103 /* MX28_PAD_SSP2_SCK__GPIO_2_16 */
 						0x2113 /* MX28_PAD_SSP2_CMD__GPIO_2_17 */
 						0x2123 /* MX28_PAD_SSP2_D0__GPIO_2_18 */
+						0x3053 /* MX28_PAD_AUART1_TX__GPIO_3_5 */
 					>;
 					fsl,drive-strength = <1>;
 					fsl,voltage = <1>;
@@ -98,12 +75,23 @@
 					fsl,voltage = <1>;
 					fsl,pull-up = <0>;
 				};
+
+				lcdif_pins_cfa10055_pullup: lcdif-10055-pullup at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x31e3 /* MX28_PAD_LCD_RESET__GPIO_3_30 */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <1>;
+				};
 			};
 
 			lcdif at 80030000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&lcdif_18bit_pins_cfa10055
-					     &lcdif_pins_cfa10055>;
+					     &lcdif_pins_cfa10055
+					     &lcdif_pins_cfa10055_pullup>;
 				display = <&display>;
 				status = "okay";
 
-- 
1.8.1.2



From alexandre.belloni at free-electrons.com  Mon Jul  1 09:23:26 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Mon,  1 Jul 2013 15:23:26 +0200
Subject: [PATCHv4 5/8] ARM: mxs: dt: cfa10049: make hogpins grabbed by
 respective drivers
In-Reply-To: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
References: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <1372685009-15564-6-git-send-email-alexandre.belloni@free-electrons.com>

Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/imx28-cfa10049.dts | 73 +++++++++++++++++++++++++++++++-----
 1 file changed, 63 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index 04b2f76..06e4cfa 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -22,32 +22,62 @@
 	apb at 80000000 {
 		apbh at 80000000 {
 			pinctrl at 80018000 {
-				pinctrl-names = "default", "default";
-				pinctrl-1 = <&hog_pins_cfa10049
-					&hog_pins_cfa10049_pullup>;
-
-				hog_pins_cfa10049: hog-10049 at 0 {
+				usb_pins_cfa10049: usb-10049 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
 						0x0073 /* MX28_PAD_GPMI_D7__GPIO_0_7 */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+
+				i2cmux_pins_cfa10049: i2cmux-10049 at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
 						0x1163 /* MX28_PAD_LCD_D22__GPIO_1_22 */
 						0x1173 /* MX28_PAD_LCD_D22__GPIO_1_23 */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+
+				mac0_pins_cfa10049: mac0-10049 at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
 						0x2153 /* MX28_PAD_SSP2_D5__GPIO_2_21 */
-						0x3053 /* MX28_PAD_AUART1_TX__GPIO_3_5 */
 					>;
 					fsl,drive-strength = <0>;
 					fsl,voltage = <1>;
 					fsl,pull-up = <0>;
 				};
 
-				hog_pins_cfa10049_pullup: hog-10049-pullup at 0 {
+				pca_pins_cfa10049: pca-10049 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
 						0x2133 /* MX28_PAD_SSP2_D3__GPIO_2_19 */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <1>;
+				};
+
+				rotary_pins_cfa10049: rotary-10049 at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
 						0x3183 /* MX28_PAD_I2C0_SCL__GPIO_3_24 */
 						0x3193 /* MX28_PAD_I2C0_SDA__GPIO_3_25 */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <1>;
+				};
+
+				rotary_btn_pins_cfa10049: rotary-btn-10049 at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
 						0x31a3 /* MX28_PAD_SAIF_SDATA0__GPIO_3_26 */
-						0x31e3 /* MX28_PAD_LCD_RESET__GPIO_3_30 */
 					>;
 					fsl,drive-strength = <0>;
 					fsl,voltage = <1>;
@@ -60,6 +90,7 @@
 						0x2103 /* MX28_PAD_SSP2_SCK__GPIO_2_16 */
 						0x2113 /* MX28_PAD_SSP2_CMD__GPIO_2_17 */
 						0x2123 /* MX28_PAD_SSP2_D0__GPIO_2_18 */
+						0x3053 /* MX28_PAD_AUART1_TX__GPIO_3_5 */
 					>;
 					fsl,drive-strength = <1>;
 					fsl,voltage = <1>;
@@ -120,6 +151,16 @@
 					fsl,pull-up = <0>;
 				};
 
+				lcdif_pins_cfa10049_pullup: lcdif-10049-pullup at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x31e3 /* MX28_PAD_LCD_RESET__GPIO_3_30 */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <1>;
+				};
+
 				w1_gpio_pins: w1-gpio at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
@@ -134,7 +175,8 @@
 			lcdif at 80030000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&lcdif_18bit_pins_cfa10049
-					     &lcdif_pins_cfa10049>;
+					     &lcdif_pins_cfa10049
+					     &lcdif_pins_cfa10049_pullup>;
 				display = <&display>;
 				status = "okay";
 
@@ -181,6 +223,8 @@
 				compatible = "i2c-mux-gpio";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&i2cmux_pins_cfa10049>;
 				mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
 				i2c-parent = <&i2c1>;
 
@@ -203,6 +247,8 @@
 
 					pca9555: pca9555 at 20 {
 						compatible = "nxp,pca9555";
+						pinctrl-names = "default";
+						pinctrl-0 = <&pca_pins_cfa10049>;
 						interrupt-parent = <&gpio2>;
 						interrupts = <19 0x2>;
 						gpio-controller;
@@ -239,6 +285,8 @@
 
 		reg_usb1_vbus: usb1_vbus {
 			compatible = "regulator-fixed";
+			pinctrl-names = "default";
+			pinctrl-0 = <&usb_pins_cfa10049>;
 			regulator-name = "usb1_vbus";
 			regulator-min-microvolt = <5000000>;
 			regulator-max-microvolt = <5000000>;
@@ -250,7 +298,8 @@
 		mac0: ethernet at 800f0000 {
 			phy-mode = "rmii";
 			pinctrl-names = "default";
-			pinctrl-0 = <&mac0_pins_a>;
+			pinctrl-0 = <&mac0_pins_a
+				&mac0_pins_cfa10049>;
 			phy-reset-gpios = <&gpio2 21 0>;
 			phy-reset-duration = <100>;
 			status = "okay";
@@ -320,6 +369,8 @@
 
 	gpio_keys {
 		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&rotary_btn_pins_cfa10049>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 
@@ -333,6 +384,8 @@
 
 	rotary {
 		compatible = "rotary-encoder";
+		pinctrl-names = "default";
+		pinctrl-0 = <&rotary_pins_cfa10049>;
 		gpios = <&gpio3 24 1>, <&gpio3 25 1>;
 		linux,axis = <1>; /* REL_Y */
 		rotary-encoder,relative-axis;
-- 
1.8.1.2



From laurent.pinchart at ideasonboard.com  Mon Jul  1 09:29:21 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 01 Jul 2013 15:29:21 +0200
Subject: [PATCH v4 2/3] ARM: shmobile: lager: enable Ether
In-Reply-To: <1372663234-13486-3-git-send-email-horms+renesas@verge.net.au>
References: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
 <1372663234-13486-3-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1870016.uXUUSHgrj5@avalon>

Hi Simon,

On Monday 01 July 2013 16:20:33 Simon Horman wrote:
> Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Cc: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> ---
> 
> This patch has a build-time dependency on "sh_eth: add support for gpio
> reset". This patch has a run-time dependency on "sh_eth: add support for
> r8a7790 SoC".
> 
> v4
> * Annotate ether_platdata as __initdata
> 
> v3
> * Rebase
> 
> v2
> * As suggested by Laurent Pinchart
>   - Do not manipilate sh_eth reset GPIO directly,
>     rather, do so through newly proposed support for this in
>     the sh_eth driver.
> * A suggested by Sergei Shtylyov
>   - Move DTS portion into a separate patch
> ---
>  arch/arm/mach-shmobile/board-lager.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/mach-shmobile/board-lager.c
> b/arch/arm/mach-shmobile/board-lager.c index 0b4a1f9..7d5db20 100644
> --- a/arch/arm/mach-shmobile/board-lager.c
> +++ b/arch/arm/mach-shmobile/board-lager.c
> @@ -71,6 +71,17 @@ static __initdata struct gpio_keys_platform_data
> lager_keys_pdata = { .nbuttons	= ARRAY_SIZE(gpio_buttons),
>  };
> 
> +/* Ether */
> +static struct sh_eth_plat_data ether_platdata __initdata = {
> +	.phy			= 0x1,
> +	.edmac_endian		= EDMAC_LITTLE_ENDIAN,
> +	.register_type		= SH_ETH_REG_FAST_RCAR,
> +	.phy_interface		= PHY_INTERFACE_MODE_RMII,
> +	.ether_link_active_low	= 1,
> +	.needs_gpio_reset	= 1,
> +	.reset_gpio		= RCAR_GP_PIN(5, 31),
> +};
> +
>  static const struct pinctrl_map lager_pinctrl_map[] = {
>  	/* SCIF0 (CN19: DEBUG SERIAL0) */
>  	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7790",
> @@ -78,6 +89,17 @@ static const struct pinctrl_map lager_pinctrl_map[] = {
>  	/* SCIF1 (CN20: DEBUG SERIAL1) */
>  	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.7", "pfc-r8a7790",
>  				  "scif1_data", "scif1"),
> +	/* Ether */
> +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> +				  "eth_link", "eth"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> +				  "eth_magic", "eth"),

That pin isn't used on Lager, you can drop it.

By the way, the latest R8A7790 datasheet errata renamed the eth_magic pin to 
eth_wol. What would you think about renaming it to eth_wol in 
drivers/pinctrl/sh-pfc/pfc-r8a7790.c ?

> +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> +				  "eth_mdio", "eth"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> +				  "eth_rmii", "eth"),
> +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> +				  "intc_irq0", "intc"),
>  };
> 
>  static void __init lager_add_standard_devices(void)
> @@ -89,6 +111,8 @@ static void __init lager_add_standard_devices(void)
>  	r8a7790_pinmux_init();
> 
>  	r8a7790_add_standard_devices();
> +	r8a7790_add_ether_device(&ether_platdata);
> +
>  	platform_device_register_data(&platform_bus, "leds-gpio", -1,
>  				      &lager_leds_pdata,
>  				      sizeof(lager_leds_pdata));
-- 
Regards,

Laurent Pinchart



From maxime.ripard at free-electrons.com  Mon Jul  1 09:32:42 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 1 Jul 2013 15:32:42 +0200
Subject: [PATCHv4 2/8] ARM: mxs: dt: Add Crystalfontz CFA-10056 device tree
In-Reply-To: <1372685009-15564-3-git-send-email-alexandre.belloni@free-electrons.com>
References: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1372685009-15564-3-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <20130701133242.GA3154@lukather>

On Mon, Jul 01, 2013 at 03:23:23PM +0200, Alexandre Belloni wrote:
> From: Brian Lilly <brian at crystalfontz.com>
> 
> The CFA-10056 is a breakout board for the CFA-10036, and is
> basically a CFA-10037, with a 4.3" screen.
> 
> Signed-off-by: Brian Lilly <brian at crystalfontz.com>
> Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>

Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130701/042dafb4/attachment.sig>

From tj at kernel.org  Mon Jul  1 09:36:11 2013
From: tj at kernel.org (Tejun Heo)
Date: Mon, 1 Jul 2013 06:36:11 -0700
Subject: [v2 4/4] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <1372672975-2997-5-git-send-email-r65037@freescale.com>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-5-git-send-email-r65037@freescale.com>
Message-ID: <20130701133611.GB11408@mtj.dyndns.org>

On Mon, Jul 01, 2013 at 06:02:55PM +0800, Richard Zhu wrote:
> imx6q contains one Synopsys AHCI SATA controller,
> But it can't shares ahci_platform driver with other
> controllers.
> Because there are some misalignments of the bits
> definitions of the HBA registers and the Vendor
> Specific registers
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>  value is '0', should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the
>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>  should be configured regarding to the frequency of AHB
>  bus clock.

If these are the only differences, can't you make ahci_platform deal
with different variants?  That's how we deal with subtly different
variants of about the same controllers.

Thanks.

-- 
tejun


From shawn.guo at linaro.org  Mon Jul  1 09:42:06 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 21:42:06 +0800
Subject: [PATCH 2/2] ARM i.MX6DL: dts: add clock and mux configuration
 for LDB
In-Reply-To: <1372669145.4971.22.camel@pizza.hi.pengutronix.de>
References: <1372422256-22037-1-git-send-email-p.zabel@pengutronix.de>
 <1372422256-22037-2-git-send-email-p.zabel@pengutronix.de>
 <20130701085255.GE13206@S2101-09.ap.freescale.net>
 <1372669145.4971.22.camel@pizza.hi.pengutronix.de>
Message-ID: <20130701134205.GM13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 10:59:05AM +0200, Philipp Zabel wrote:
> 
> I'd rather remove it from imx6qdl.dtsi completely.
> 
Ok, I removed it and applied the patch.

Shawn



From thomas.petazzoni at free-electrons.com  Mon Jul  1 09:42:06 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon,  1 Jul 2013 15:42:06 +0200
Subject: [PATCHv4 01/11] irqdomain: add irq_alloc_mapping() function
In-Reply-To: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1372686136-1370-2-git-send-email-thomas.petazzoni@free-electrons.com>

This commit extends the irqdomain subsystem with an
irq_alloc_mapping() function which allows to let the irqdomain code
find an available hwirq number in the range [ 0 ; domain size ] for
the given domain, and create a virq mapping for it.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 include/linux/irqdomain.h |  2 ++
 kernel/irq/irqdomain.c    | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 02f7658..5f9c3ff 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -195,6 +195,8 @@ static inline unsigned int irq_linear_revmap(struct irq_domain *domain,
 extern unsigned int irq_find_mapping(struct irq_domain *host,
 				     irq_hw_number_t hwirq);
 extern unsigned int irq_create_direct_mapping(struct irq_domain *host);
+extern unsigned int irq_alloc_mapping(struct irq_domain *host,
+				      irq_hw_number_t *hwirq);
 extern int irq_create_strict_mappings(struct irq_domain *domain,
 				      unsigned int irq_base,
 				      irq_hw_number_t hwirq_base, int count);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 836a0f7..be82d2e 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -375,6 +375,38 @@ unsigned int irq_create_direct_mapping(struct irq_domain *domain)
 EXPORT_SYMBOL_GPL(irq_create_direct_mapping);
 
 /**
+ * irq_alloc_mapping() - Allocate an irq for mapping
+ * @domain: domain to allocate the irq for or NULL for default domain
+ * @hwirq:  reference to the returned hwirq
+ *
+ * This routine are used for irq controllers which can choose the
+ * hardware interrupt number from a range [ 0 ; domain size ], such as
+ * is often the case with PCI MSI controllers. The function will
+ * returned the allocated hwirq number in the hwirq pointer, and the
+ * corresponding virq number as the return value.
+ */
+unsigned int irq_alloc_mapping(struct irq_domain *domain,
+			       irq_hw_number_t *out_hwirq)
+{
+	irq_hw_number_t hwirq;
+
+	pr_debug("irq_alloc_mapping(0x%p)\n", domain);
+
+	for (hwirq = 0; hwirq < domain->hwirq_max; hwirq++)
+		if (!irq_find_mapping(domain, hwirq))
+			break;
+
+	if (hwirq == domain->hwirq_max) {
+		pr_debug("-> no available hwirq found\n");
+		return 0;
+	}
+
+	*out_hwirq = hwirq;
+	return irq_create_mapping(domain, hwirq);
+}
+EXPORT_SYMBOL_GPL(irq_alloc_mapping);
+
+/**
  * irq_create_mapping() - Map a hardware interrupt into linux irq space
  * @domain: domain owning this hardware interrupt or NULL for default domain
  * @hwirq: hardware irq number in that domain space
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul  1 09:42:05 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon,  1 Jul 2013 15:42:05 +0200
Subject: [PATCHv4 00/11] MSI support for Marvell EBU PCIe driver
Message-ID: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello,

This set of patches introduces Message Signaled Interrupt support in
the Marvell EBU PCIe driver. It has been successfully tested on the
Armada XP GP platform with an Intel e1000e PCIe network card that
supports MSI.

The patches do the following:

 * Patch 1 adds an IRQ domain function that allows to allocate
   dynamically a free hwirq number from an IRQ domain, and create a
   virq mapping to it. It was suggested by Grant Likely in order to
   remove the hwirq allocation code from the IRQ driver itself.

   This patch needs the Ack of Grant Likely.

 * Patch 2 reworks how the architecture-specific MSI functions can be
   overriden by architecture-specific code, by using weak
   functions. It was suggested by Bjorn Helgaas.

   This patch needs the Ack from Bjorn Helgaas, and the relevant
   architecture maintainers.

 * Patch 3 removes the ARCH_SUPPORTS_MSI hidden kconfig boolean which
   is no longer needed now that we have weak functions for all MSI
   architecture-specific hooks.

   This patch needs the Ack from Bjorn Helgaas, and the relevant
   architecture maintainers.

 * Patch 4 adds a minimal msi_chip infrastructure, that allows a
   pci_bus to be connected to a msi_chip, and that provides default
   implementations of the architecture-specific MSI functions to use
   msi_chip.

   This patch needs the Ack from Bjorn Helgaas.

 * Patch 5 adds a small registry of msi_chip <-> of_node in the OF
   code. It was originally located in drivers/pci/msi.c, but Bjorn
   Helgaas suggested that it probably belongs to drivers/of/.

   This patch needs the Ack from Grant Likely or Rob Herring, and
   probably Bjorn Helgaas as well.

 * Patch 6 makes some not very interesting preparation in the Armada
   370/XP IRQ controller driver.

   This patch needs the Ack from Thomas Gleixner.

 * Patch 7 implements the MSI support in the Armada 370/XP IRQ
   controller driver. It registers an msi_chip using the
   msi_chip_add() function added in PATCH 3.

   This patch needs the Ack from Thomas Gleixner.

 * Patch 8 extends the ARM PCI core to expose ->add_bus() and
   ->remove_bus() hooks to PCI drivers. This was suggested by Bjorn
   Helgaas to allow the PCI driver to connected the PCI busses with
   the corresponding MSI chip.

   This patch needs the Ack from Russell King.

 * Patch 9 adjust the Armada 370/XP Device Tree to indicate that the
   MPIC is not only an interrupt-controller, but also an
   msi-controller.

   This patch needs the Ack from Jason Cooper, Gregory Clement
   and/or Andrew Lunn, the Marvell Maintainers.

 * Patch 10 adds MSI support in the Marvell PCIe host controller
   driver. The work to do here is minimal: get a reference to the
   msi-parent controller thanks to msi_chip_find_by_of_node(), and
   link it to the pci_bus structure before the bus gets enumerated.

   This patch needs the Ack from Bjorn Helgaas.

 * Patch 11 adjusts the Armada 370/XP Device Tree to add the msi-parent
   properties in the PCIe controller nodes.

   This patch needs the Ack from Jason Cooper, Gregory Clement
   and/or Andrew Lunn, the Marvell Maintainers.

This version 4 follows:
 * PATCH version 3 sent on June, 19th 2013
 * PATCH version 2 sent on June, 6th 2013
 * RFC version 1 sent on March, 26th 2013

Changes since v3:

 * Keep only a default_teardown_msi_irqs() function needed for the Xen
   PCI x86 code, and remove all other default_*() function and put the
   default behavior directly in the weak functions. Suggested by
   Thierry Redding and Bjorn Helgaas.

 * Misc small improvements the MSI chip registry code: compiled only
   under CONFIG_PCI_MSI, functions exported to modules, addition of an
   of_msi_chip_remove() function, renaming of
   of_msi_chip_find_by_node() to of_find_msi_chip_by_node(), move the
   test of the "msi-controller" property to the of_msi_chip_add()
   function, renamed the list_head field from link to list, added
   dummy functions in the header files when !CONFIG_PCI_MSI &&
   !CONFIG_OF. All suggested by Thierry Redding.

 * Add a patch that entirely removes the ARCH_SUPPORTS_MSI, as we now
   have weak functions, so even if an arch doesn't actually
   use/support MSI, the code will build properly. Suggested by Thierry
   Redding.

 * Added Device Tree binding documentation updates for the IRQ
   controller and the PCIe controller.

Changes since v2:

 * Add an IRQ domain function that allows to allocate dynamically a
   free hwirq number from an IRQ domain, and create a virq mapping to
   it. It was suggested by Grant Likely in order to remove the hwirq
   allocation code from the IRQ driver itself. (PATCH 1)

 * Separate the use of weak functions from the introduction of the
   msi_chip infrastructure, and use weak functions for all
   architecture-specific MSI hooks. Suggested by Bjorn Helgaas (PATCH
   2).

 * Move the msi_chip registry to drivers/of. Suggested by Bjorn
   Helgaas (PATCH 4).

 * Use pcibios_add_bus() and pcibios_remove_bus() to connect the PCI
   busses to their msi_chip, as suggested by Bjorn Helgaas. Requires
   some ARM PCI core changes (PATCH 7), and then changes to the PCI
   driver itself (PATCH 9).

This set of patches currently applies on top of the current "for-next"
branch of Jason Cooper's repository + the irqdomain/test branch of
Grant Likely's tree. I will rebase them on top of 3.11-rc1 when it
lands, but I'd like to start collecting Acked-by from maintainers in
the mean time.

Thanks,

Thomas

Thierry Reding (1):
  PCI: Introduce new MSI chip infrastructure

Thomas Petazzoni (10):
  irqdomain: add irq_alloc_mapping() function
  pci: use weak functions for MSI arch-specific functions
  pci: remove ARCH_SUPPORTS_MSI kconfig option
  of: pci: add registry of MSI chips
  irqchip: armada-370-xp: properly request resources
  irqchip: armada-370-xp: implement MSI support
  arm: pci: add ->add_bus() and ->remove_bus() hooks to hw_pci
  arm: mvebu: the MPIC now provides MSI controller features
  pci: mvebu: add support for MSI
  arm: mvebu: link PCIe controllers to the MSI controller

 .../devicetree/bindings/arm/armada-370-xp-mpic.txt |   3 +
 .../devicetree/bindings/pci/mvebu-pci.txt          |   3 +
 arch/arm/Kconfig                                   |   1 -
 arch/arm/boot/dts/armada-370-xp.dtsi               |   1 +
 arch/arm/boot/dts/armada-370.dtsi                  |   1 +
 arch/arm/boot/dts/armada-xp-mv78230.dtsi           |   1 +
 arch/arm/boot/dts/armada-xp-mv78260.dtsi           |   1 +
 arch/arm/boot/dts/armada-xp-mv78460.dtsi           |   1 +
 arch/arm/include/asm/mach/pci.h                    |   4 +
 arch/arm/kernel/bios32.c                           |  16 ++
 arch/ia64/Kconfig                                  |   1 -
 arch/mips/Kconfig                                  |   2 -
 arch/mips/include/asm/pci.h                        |   5 -
 arch/powerpc/Kconfig                               |   1 -
 arch/powerpc/include/asm/pci.h                     |   5 -
 arch/s390/Kconfig                                  |   1 -
 arch/s390/include/asm/pci.h                        |   4 -
 arch/sparc/Kconfig                                 |   1 -
 arch/tile/Kconfig                                  |   1 -
 arch/x86/Kconfig                                   |   1 -
 arch/x86/include/asm/pci.h                         |  28 ----
 arch/x86/kernel/x86_init.c                         |  21 +++
 drivers/irqchip/irq-armada-370-xp.c                | 161 ++++++++++++++++++++-
 drivers/of/of_pci.c                                |  40 +++++
 drivers/pci/Kconfig                                |   4 -
 drivers/pci/host/pci-mvebu.c                       |  26 ++++
 drivers/pci/msi.c                                  |  67 +++++----
 drivers/pci/probe.c                                |   1 +
 include/linux/irqdomain.h                          |   2 +
 include/linux/msi.h                                |  20 ++-
 include/linux/of_pci.h                             |  12 ++
 include/linux/pci.h                                |   1 +
 kernel/irq/irqdomain.c                             |  32 ++++
 33 files changed, 383 insertions(+), 86 deletions(-)

-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul  1 09:42:07 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon,  1 Jul 2013 15:42:07 +0200
Subject: [PATCHv4 02/11] pci: use weak functions for MSI arch-specific
 functions
In-Reply-To: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1372686136-1370-3-git-send-email-thomas.petazzoni@free-electrons.com>

Until now, the MSI architecture-specific functions could be overloaded
using a fairly complex set of #define and compile-time
conditionals. In order to prepare for the introduction of the msi_chip
infrastructure, it is desirable to switch all those functions to use
the 'weak' mechanism. This commit converts all the architectures that
were overidding those MSI functions to use the new strategy.

Note that we keep a separate, non-weak, function
default_teardown_msi_irqs() for the default behavior of the
arch_teardown_msi_irqs(), as the default behavior is needed by the Xen
x86 PCI code.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: linuxppc-dev at lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky at de.ibm.com>
Cc: Heiko Carstens <heiko.carstens at de.ibm.com>
Cc: linux390 at de.ibm.com
Cc: linux-s390 at vger.kernel.org
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: H. Peter Anvin <hpa at zytor.com>
Cc: x86 at kernel.org
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Tony Luck <tony.luck at intel.com>
Cc: Fenghua Yu <fenghua.yu at intel.com>
Cc: linux-ia64 at vger.kernel.org
Cc: Ralf Baechle <ralf at linux-mips.org>
Cc: linux-mips at linux-mips.org
Cc: David S. Miller <davem at davemloft.net>
Cc: sparclinux at vger.kernel.org
Cc: Chris Metcalf <cmetcalf at tilera.com>
---
 arch/mips/include/asm/pci.h    |  5 -----
 arch/powerpc/include/asm/pci.h |  5 -----
 arch/s390/include/asm/pci.h    |  4 ----
 arch/x86/include/asm/pci.h     | 28 --------------------------
 arch/x86/kernel/x86_init.c     | 21 ++++++++++++++++++++
 drivers/pci/msi.c              | 45 +++++++++++++++++++-----------------------
 include/linux/msi.h            |  7 ++++++-
 7 files changed, 47 insertions(+), 68 deletions(-)

diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
index b8e24fd..031f4c1 100644
--- a/arch/mips/include/asm/pci.h
+++ b/arch/mips/include/asm/pci.h
@@ -137,11 +137,6 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
 	return channel ? 15 : 14;
 }
 
-#ifdef CONFIG_CPU_CAVIUM_OCTEON
-/* MSI arch hook for OCTEON */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#endif
-
 extern char * (*pcibios_plat_setup)(char *str);
 
 #ifdef CONFIG_OF
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 6653f27..95145a1 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -113,11 +113,6 @@ extern int pci_domain_nr(struct pci_bus *bus);
 /* Decide whether to display the domain number in /proc */
 extern int pci_proc_domain(struct pci_bus *bus);
 
-/* MSI arch hooks */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#define arch_teardown_msi_irqs arch_teardown_msi_irqs
-#define arch_msi_check_device arch_msi_check_device
-
 struct vm_area_struct;
 /* Map a range of PCI memory or I/O space for a device into user space */
 int pci_mmap_page_range(struct pci_dev *pdev, struct vm_area_struct *vma,
diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
index 6c18012..8641e8d 100644
--- a/arch/s390/include/asm/pci.h
+++ b/arch/s390/include/asm/pci.h
@@ -21,10 +21,6 @@ void pci_iounmap(struct pci_dev *, void __iomem *);
 int pci_domain_nr(struct pci_bus *);
 int pci_proc_domain(struct pci_bus *);
 
-/* MSI arch hooks */
-#define arch_setup_msi_irqs	arch_setup_msi_irqs
-#define arch_teardown_msi_irqs	arch_teardown_msi_irqs
-
 #define ZPCI_BUS_NR			0	/* default bus number */
 #define ZPCI_DEVFN			0	/* default device number */
 
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index d9e9e6c..8c61de0 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -100,29 +100,6 @@ static inline void early_quirks(void) { }
 extern void pci_iommu_alloc(void);
 
 #ifdef CONFIG_PCI_MSI
-/* MSI arch specific hooks */
-static inline int x86_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
-{
-	return x86_msi.setup_msi_irqs(dev, nvec, type);
-}
-
-static inline void x86_teardown_msi_irqs(struct pci_dev *dev)
-{
-	x86_msi.teardown_msi_irqs(dev);
-}
-
-static inline void x86_teardown_msi_irq(unsigned int irq)
-{
-	x86_msi.teardown_msi_irq(irq);
-}
-static inline void x86_restore_msi_irqs(struct pci_dev *dev, int irq)
-{
-	x86_msi.restore_msi_irqs(dev, irq);
-}
-#define arch_setup_msi_irqs x86_setup_msi_irqs
-#define arch_teardown_msi_irqs x86_teardown_msi_irqs
-#define arch_teardown_msi_irq x86_teardown_msi_irq
-#define arch_restore_msi_irqs x86_restore_msi_irqs
 /* implemented in arch/x86/kernel/apic/io_apic. */
 struct msi_desc;
 int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
@@ -130,11 +107,6 @@ void native_teardown_msi_irq(unsigned int irq);
 void native_restore_msi_irqs(struct pci_dev *dev, int irq);
 int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
 		  unsigned int irq_base, unsigned int irq_offset);
-/* default to the implementation in drivers/lib/msi.c */
-#define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
-#define HAVE_DEFAULT_MSI_RESTORE_IRQS
-void default_teardown_msi_irqs(struct pci_dev *dev);
-void default_restore_msi_irqs(struct pci_dev *dev, int irq);
 #else
 #define native_setup_msi_irqs		NULL
 #define native_teardown_msi_irq		NULL
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 45a14db..a2b189c 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -116,6 +116,27 @@ struct x86_msi_ops x86_msi = {
 	.setup_hpet_msi		= default_setup_hpet_msi,
 };
 
+/* MSI arch specific hooks */
+int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+	return x86_msi.setup_msi_irqs(dev, nvec, type);
+}
+
+void arch_teardown_msi_irqs(struct pci_dev *dev)
+{
+	x86_msi.teardown_msi_irqs(dev);
+}
+
+void arch_teardown_msi_irq(unsigned int irq)
+{
+	x86_msi.teardown_msi_irq(irq);
+}
+
+void arch_restore_msi_irqs(struct pci_dev *dev, int irq)
+{
+	x86_msi.restore_msi_irqs(dev, irq);
+}
+
 struct x86_io_apic_ops x86_io_apic_ops = {
 	.init			= native_io_apic_init_mappings,
 	.read			= native_io_apic_read,
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 2c10752..289fbfd 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -30,20 +30,21 @@ static int pci_msi_enable = 1;
 
 /* Arch hooks */
 
-#ifndef arch_msi_check_device
-int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
 {
-	return 0;
+	return -EINVAL;
 }
-#endif
 
-#ifndef arch_setup_msi_irqs
-# define arch_setup_msi_irqs default_setup_msi_irqs
-# define HAVE_DEFAULT_MSI_SETUP_IRQS
-#endif
+void __weak arch_teardown_msi_irq(unsigned int irq)
+{
+}
 
-#ifdef HAVE_DEFAULT_MSI_SETUP_IRQS
-int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+{
+	return 0;
+}
+
+int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 {
 	struct msi_desc *entry;
 	int ret;
@@ -65,14 +66,11 @@ int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 
 	return 0;
 }
-#endif
 
-#ifndef arch_teardown_msi_irqs
-# define arch_teardown_msi_irqs default_teardown_msi_irqs
-# define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
-#endif
-
-#ifdef HAVE_DEFAULT_MSI_TEARDOWN_IRQS
+/*
+ * We have a default implementation available as a separate non-weak
+ * function, as it is used by the Xen x86 PCI code
+ */
 void default_teardown_msi_irqs(struct pci_dev *dev)
 {
 	struct msi_desc *entry;
@@ -86,15 +84,13 @@ void default_teardown_msi_irqs(struct pci_dev *dev)
 			arch_teardown_msi_irq(entry->irq + i);
 	}
 }
-#endif
 
-#ifndef arch_restore_msi_irqs
-# define arch_restore_msi_irqs default_restore_msi_irqs
-# define HAVE_DEFAULT_MSI_RESTORE_IRQS
-#endif
+void __weak arch_teardown_msi_irqs(struct pci_dev *dev)
+{
+	return default_teardown_msi_irqs(dev);
+}
 
-#ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS
-void default_restore_msi_irqs(struct pci_dev *dev, int irq)
+void __weak arch_restore_msi_irqs(struct pci_dev *dev, int irq)
 {
 	struct msi_desc *entry;
 
@@ -111,7 +107,6 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)
 	if (entry)
 		write_msi_msg(irq, &entry->msg);
 }
-#endif
 
 static void msi_set_enable(struct pci_dev *dev, int enable)
 {
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 20c2d6d..c82ff8d 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -50,12 +50,17 @@ struct msi_desc {
 };
 
 /*
- * The arch hook for setup up msi irqs
+ * The arch hooks to setup up msi irqs. Those functions are
+ * implemented as weak symbols so that they /can/ be overriden by
+ * architecture specific code if needed.
  */
 int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc);
 void arch_teardown_msi_irq(unsigned int irq);
 int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
 void arch_teardown_msi_irqs(struct pci_dev *dev);
 int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
+void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
+
+void default_teardown_msi_irqs(struct pci_dev *dev);
 
 #endif /* LINUX_MSI_H */
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul  1 09:42:09 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon,  1 Jul 2013 15:42:09 +0200
Subject: [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1372686136-1370-5-git-send-email-thomas.petazzoni@free-electrons.com>

From: Thierry Reding <thierry.reding at avionic-design.de>

The new struct msi_chip is used to associated an MSI controller with a
PCI bus. It is automatically handed down from the root to its children
during bus enumeration.

This patch provides default (weak) implementations for the architecture-
specific MSI functions (arch_setup_msi_irq(), arch_teardown_msi_irq()
and arch_msi_check_device()) which check if a PCI device's bus has an
attached MSI chip and forward the call appropriately.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/pci/msi.c   | 22 ++++++++++++++++++++++
 drivers/pci/probe.c |  1 +
 include/linux/msi.h | 11 +++++++++++
 include/linux/pci.h |  1 +
 4 files changed, 35 insertions(+)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 289fbfd..62eb3d5 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -32,15 +32,37 @@ static int pci_msi_enable = 1;
 
 int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
 {
+	struct msi_chip *chip = dev->bus->msi;
+
+	if (chip && chip->setup_irq) {
+		int err;
+
+		err = chip->setup_irq(chip, dev, desc);
+		if (err < 0)
+			return err;
+
+		irq_set_chip_data(desc->irq, chip);
+		return err;
+	}
+
 	return -EINVAL;
 }
 
 void __weak arch_teardown_msi_irq(unsigned int irq)
 {
+	struct msi_chip *chip = irq_get_chip_data(irq);
+
+	if (chip && chip->teardown_irq)
+		chip->teardown_irq(chip, irq);
 }
 
 int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
 {
+	struct msi_chip *chip = dev->bus->msi;
+
+	if (chip && chip->check_device)
+		return chip->check_device(chip, dev, nvec, type);
+
 	return 0;
 }
 
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 70f10fa..c8591e4 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -634,6 +634,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
 
 	child->parent = parent;
 	child->ops = parent->ops;
+	child->msi = parent->msi;
 	child->sysdata = parent->sysdata;
 	child->bus_flags = parent->bus_flags;
 
diff --git a/include/linux/msi.h b/include/linux/msi.h
index c82ff8d..5b357d92 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -63,4 +63,15 @@ void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
 
 void default_teardown_msi_irqs(struct pci_dev *dev);
 
+struct msi_chip {
+	struct module *owner;
+	struct device *dev;
+
+	int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
+			 struct msi_desc *desc);
+	void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
+	int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
+			    int nvec, int type);
+};
+
 #endif /* LINUX_MSI_H */
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 3a24e4f..7ffc012 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -432,6 +432,7 @@ struct pci_bus {
 	struct resource busn_res;	/* bus numbers routed to this bus */
 
 	struct pci_ops	*ops;		/* configuration access functions */
+	struct msi_chip	*msi;		/* MSI controller */
 	void		*sysdata;	/* hook for sys-specific extension */
 	struct proc_dir_entry *procdir;	/* directory entry in /proc/bus/pci */
 
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul  1 09:42:08 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon,  1 Jul 2013 15:42:08 +0200
Subject: [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
In-Reply-To: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1372686136-1370-4-git-send-email-thomas.petazzoni@free-electrons.com>

Now that we have weak versions for each of the PCI MSI architecture
functions, we can actually build the MSI support for all platforms,
regardless of whether they provide or not architecture-specific
versions of those functions. For this reason, the ARCH_SUPPORTS_MSI
hidden kconfig boolean becomes useless, and this patch gets rid of it.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: linuxppc-dev at lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky at de.ibm.com>
Cc: Heiko Carstens <heiko.carstens at de.ibm.com>
Cc: linux390 at de.ibm.com
Cc: linux-s390 at vger.kernel.org
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: H. Peter Anvin <hpa at zytor.com>
Cc: x86 at kernel.org
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Tony Luck <tony.luck at intel.com>
Cc: Fenghua Yu <fenghua.yu at intel.com>
Cc: linux-ia64 at vger.kernel.org
Cc: Ralf Baechle <ralf at linux-mips.org>
Cc: linux-mips at linux-mips.org
Cc: David S. Miller <davem at davemloft.net>
Cc: sparclinux at vger.kernel.org
Cc: Chris Metcalf <cmetcalf at tilera.com>
---
 arch/arm/Kconfig     | 1 -
 arch/ia64/Kconfig    | 1 -
 arch/mips/Kconfig    | 2 --
 arch/powerpc/Kconfig | 1 -
 arch/s390/Kconfig    | 1 -
 arch/sparc/Kconfig   | 1 -
 arch/tile/Kconfig    | 1 -
 arch/x86/Kconfig     | 1 -
 drivers/pci/Kconfig  | 4 ----
 9 files changed, 13 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 8ab5962..3413679 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -435,7 +435,6 @@ config ARCH_NETX
 config ARCH_IOP13XX
 	bool "IOP13xx-based"
 	depends on MMU
-	select ARCH_SUPPORTS_MSI
 	select CPU_XSC3
 	select NEED_MACH_MEMORY_H
 	select NEED_RET_TO_USER
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 1a2b774..943d425 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -9,7 +9,6 @@ config IA64
 	select PCI if (!IA64_HP_SIM)
 	select ACPI if (!IA64_HP_SIM)
 	select PM if (!IA64_HP_SIM)
-	select ARCH_SUPPORTS_MSI
 	select HAVE_UNSTABLE_SCHED_CLOCK
 	select HAVE_IDE
 	select HAVE_OPROFILE
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 7a58ab9..96c1225 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -763,7 +763,6 @@ config CAVIUM_OCTEON_REFERENCE_BOARD
 	select SYS_HAS_CPU_CAVIUM_OCTEON
 	select SWAP_IO_SPACE
 	select HW_HAS_PCI
-	select ARCH_SUPPORTS_MSI
 	select ZONE_DMA32
 	select USB_ARCH_HAS_OHCI
 	select USB_ARCH_HAS_EHCI
@@ -799,7 +798,6 @@ config NLM_XLR_BOARD
 	select CEVT_R4K
 	select CSRC_R4K
 	select IRQ_CPU
-	select ARCH_SUPPORTS_MSI
 	select ZONE_DMA32 if 64BIT
 	select SYNC_R4K
 	select SYS_HAS_EARLY_PRINTK
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..f9d9d8e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -734,7 +734,6 @@ config PCI
 	default y if !40x && !CPM2 && !8xx && !PPC_83xx \
 		&& !PPC_85xx && !PPC_86xx && !GAMECUBE_COMMON
 	default PCI_QSPAN if !4xx && !CPM2 && 8xx
-	select ARCH_SUPPORTS_MSI
 	select GENERIC_PCI_IOMAP
 	help
 	  Find out whether your system includes a PCI bus. PCI is the name of
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index da183c5..9a6225b 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -429,7 +429,6 @@ menuconfig PCI
 	bool "PCI support"
 	default n
 	depends on 64BIT
-	select ARCH_SUPPORTS_MSI
 	select PCI_MSI
 	help
 	  Enable PCI support.
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 9ac9f16..822e1a1 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -52,7 +52,6 @@ config SPARC32
 
 config SPARC64
 	def_bool 64BIT
-	select ARCH_SUPPORTS_MSI
 	select HAVE_FUNCTION_TRACER
 	select HAVE_FUNCTION_GRAPH_TRACER
 	select HAVE_FUNCTION_GRAPH_FP_TEST
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 3aa3766..d2d519c 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -379,7 +379,6 @@ config PCI
 	select PCI_DOMAINS
 	select GENERIC_PCI_IOMAP
 	select TILE_GXIO_TRIO if TILEGX
-	select ARCH_SUPPORTS_MSI if TILEGX
 	select PCI_MSI if TILEGX
 	---help---
 	  Enable PCI root complex support, so PCIe endpoint devices can
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 685692c..4229ce0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1999,7 +1999,6 @@ menu "Bus options (PCI etc.)"
 config PCI
 	bool "PCI support"
 	default y
-	select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC)
 	---help---
 	  Find out whether you have a PCI motherboard. PCI is the name of a
 	  bus system, i.e. the way the CPU talks to the other stuff inside
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index ac45398..3d4c061 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -1,13 +1,9 @@
 #
 # PCI configuration
 #
-config ARCH_SUPPORTS_MSI
-	bool
-
 config PCI_MSI
 	bool "Message Signaled Interrupts (MSI and MSI-X)"
 	depends on PCI
-	depends on ARCH_SUPPORTS_MSI
 	help
 	   This allows device drivers to enable MSI (Message Signaled
 	   Interrupts).  Message Signaled Interrupts enable a device to
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul  1 09:42:11 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon,  1 Jul 2013 15:42:11 +0200
Subject: [PATCHv4 06/11] irqchip: armada-370-xp: properly request resources
In-Reply-To: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1372686136-1370-7-git-send-email-thomas.petazzoni@free-electrons.com>

Instead of using of_iomap(), we now use of_address_to_resource(),
request_mem_region() and ioremap(). This allows the corresponding I/O
regions to be properly requested and visible in /proc/iomem.

The main motivation for this change is that the introduction of the
MSI support requires us to get the physical address of the main
interrupt controller registers, so we will need the corresponding
'struct resource' anyway.

We also take this opportunity to change a panic() to BUG_ON(), in
order to be consistent with the rest of the driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/irqchip/irq-armada-370-xp.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index bb328a3..26adc74 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -248,12 +248,25 @@ armada_370_xp_handle_irq(struct pt_regs *regs)
 static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 					     struct device_node *parent)
 {
+	struct resource main_int_res, per_cpu_int_res;
 	u32 control;
 
-	main_int_base = of_iomap(node, 0);
-	per_cpu_int_base = of_iomap(node, 1);
+	BUG_ON(of_address_to_resource(node, 0, &main_int_res));
+	BUG_ON(of_address_to_resource(node, 1, &per_cpu_int_res));
 
+	BUG_ON(!request_mem_region(main_int_res.start,
+				   resource_size(&main_int_res),
+				   node->full_name));
+	BUG_ON(!request_mem_region(per_cpu_int_res.start,
+				   resource_size(&per_cpu_int_res),
+				   node->full_name));
+
+	main_int_base = ioremap(main_int_res.start,
+				resource_size(&main_int_res));
 	BUG_ON(!main_int_base);
+
+	per_cpu_int_base = ioremap(per_cpu_int_res.start,
+				   resource_size(&per_cpu_int_res));
 	BUG_ON(!per_cpu_int_base);
 
 	control = readl(main_int_base + ARMADA_370_XP_INT_CONTROL);
@@ -262,8 +275,7 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 		irq_domain_add_linear(node, (control >> 2) & 0x3ff,
 				&armada_370_xp_mpic_irq_ops, NULL);
 
-	if (!armada_370_xp_mpic_domain)
-		panic("Unable to add Armada_370_Xp MPIC irq domain (DT)\n");
+	BUG_ON(!armada_370_xp_mpic_domain);
 
 	irq_set_default_host(armada_370_xp_mpic_domain);
 
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul  1 09:42:13 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon,  1 Jul 2013 15:42:13 +0200
Subject: [PATCHv4 08/11] arm: pci: add ->add_bus() and ->remove_bus() hooks to
 hw_pci
In-Reply-To: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1372686136-1370-9-git-send-email-thomas.petazzoni@free-electrons.com>

Some PCI drivers may need to adjust the pci_bus structure after it has
been allocated by the Linux PCI core. The PCI core allows
architectures to implement the pcibios_add_bus() and
pcibios_remove_bus() for this purpose. This commit therefore extends
the hw_pci and pci_sys_data structures of the ARM PCI core to allow
PCI drivers to register ->add_bus() and ->remove_bus() in hw_pci,
which will get called when a bus is added or removed from the system.

This will be used for example by the Marvell PCIe driver to connect a
particular PCI bus with its corresponding MSI chip to handle Message
Signaled Interrupts.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Reviewed-by: Thierry Reding <thierry.reding at gmail.com>
---
 arch/arm/include/asm/mach/pci.h |  4 ++++
 arch/arm/kernel/bios32.c        | 16 ++++++++++++++++
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 7d2c3c8..b71cc9d 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -35,6 +35,8 @@ struct hw_pci {
 					  resource_size_t start,
 					  resource_size_t size,
 					  resource_size_t align);
+	void            (*add_bus)(struct pci_bus *bus);
+	void            (*remove_bus)(struct pci_bus *bus);
 };
 
 /*
@@ -62,6 +64,8 @@ struct pci_sys_data {
 					  resource_size_t start,
 					  resource_size_t size,
 					  resource_size_t align);
+	void            (*add_bus)(struct pci_bus *bus);
+	void            (*remove_bus)(struct pci_bus *bus);
 	void		*private_data;	/* platform controller private data	*/
 };
 
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index b2ed73c..0a441f8 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -363,6 +363,20 @@ void pcibios_fixup_bus(struct pci_bus *bus)
 }
 EXPORT_SYMBOL(pcibios_fixup_bus);
 
+void pcibios_add_bus(struct pci_bus *bus)
+{
+	struct pci_sys_data *sys = bus->sysdata;
+	if (sys->add_bus)
+		sys->add_bus(bus);
+}
+
+void pcibios_remove_bus(struct pci_bus *bus)
+{
+	struct pci_sys_data *sys = bus->sysdata;
+	if (sys->remove_bus)
+		sys->remove_bus(bus);
+}
+
 /*
  * Swizzle the device pin each time we cross a bridge.  If a platform does
  * not provide a swizzle function, we perform the standard PCI swizzling.
@@ -463,6 +477,8 @@ static void pcibios_init_hw(struct hw_pci *hw, struct list_head *head)
 		sys->swizzle = hw->swizzle;
 		sys->map_irq = hw->map_irq;
 		sys->align_resource = hw->align_resource;
+		sys->add_bus        = hw->add_bus;
+		sys->remove_bus     = hw->remove_bus;
 		INIT_LIST_HEAD(&sys->resources);
 
 		if (hw->private_data)
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul  1 09:42:10 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon,  1 Jul 2013 15:42:10 +0200
Subject: [PATCHv4 05/11] of: pci: add registry of MSI chips
In-Reply-To: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1372686136-1370-6-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds a very basic registry of msi_chip structures, so that
an IRQ controller driver can register an msi_chip, and a PCIe host
controller can find it, based on a 'struct device_node'.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/of/of_pci.c    | 40 ++++++++++++++++++++++++++++++++++++++++
 include/linux/msi.h    |  2 ++
 include/linux/of_pci.h | 12 ++++++++++++
 3 files changed, 54 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 42c687a..f516632 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -89,3 +89,43 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
+
+#ifdef CONFIG_PCI_MSI
+
+static LIST_HEAD(msi_chip_list);
+static DEFINE_MUTEX(msi_chip_mutex);
+
+int of_msi_chip_add(struct msi_chip *chip)
+{
+	if (! of_property_read_bool(chip->of_node, "msi-controller"))
+		return -EINVAL;
+
+	mutex_lock(&msi_chip_mutex);
+	list_add(&chip->list, &msi_chip_list);
+	mutex_unlock(&msi_chip_mutex);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_msi_chip_add);
+
+void of_msi_chip_remove(struct msi_chip *chip)
+{
+	mutex_lock(&msi_chip_mutex);
+	list_del(&chip->list);
+	mutex_unlock(&msi_chip_mutex);
+}
+EXPORT_SYMBOL_GPL(of_msi_chip_remove);
+
+struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node)
+{
+	struct msi_chip *c;
+	list_for_each_entry(c, &msi_chip_list, list) {
+		if (c->of_node == of_node)
+			return c;
+	}
+
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(of_find_msi_chip_by_node);
+
+#endif /* CONFIG_PCI_MSI */
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 5b357d92..9e1a44b 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -66,6 +66,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);
 struct msi_chip {
 	struct module *owner;
 	struct device *dev;
+	struct device_node *of_node;
+	struct list_head list;
 
 	int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
 			 struct msi_desc *desc);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 7a04826..99e4361 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -2,6 +2,7 @@
 #define __OF_PCI_H
 
 #include <linux/pci.h>
+#include <linux/msi.h>
 
 struct pci_dev;
 struct of_irq;
@@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 int of_pci_get_devfn(struct device_node *np);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 
+#if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
+int of_msi_chip_add(struct msi_chip *chip);
+void of_msi_chip_remove(struct msi_chip *chip);
+struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node);
+#else
+static inline int of_msi_chip_add(struct msi_chip *chip) { return -EINVAL; }
+static inline void of_msi_chip_remove(struct msi_chip *chip) { }
+static inline struct msi_chip *
+of_find_msi_chip_by_node(struct device_node *of_node) { return NULL };
+#endif
+
 #endif
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul  1 09:42:14 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon,  1 Jul 2013 15:42:14 +0200
Subject: [PATCHv4 09/11] arm: mvebu: the MPIC now provides MSI controller
 features
In-Reply-To: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1372686136-1370-10-git-send-email-thomas.petazzoni@free-electrons.com>

Adds the 'msi-controller' property to the main interrupt controller
Device Tree node, to indicate that it can now behave as a MSI
controller.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Reviewed-by: Thierry Reding <thierry.reding at gmail.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index bb6224c..9020478 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -52,6 +52,7 @@
 				#interrupt-cells = <1>;
 				#size-cells = <1>;
 				interrupt-controller;
+				msi-controller;
 			};
 
 			coherency-fabric at 20200 {
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul  1 09:42:12 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon,  1 Jul 2013 15:42:12 +0200
Subject: [PATCHv4 07/11] irqchip: armada-370-xp: implement MSI support
In-Reply-To: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1372686136-1370-8-git-send-email-thomas.petazzoni@free-electrons.com>

This commit introduces the support for the MSI interrupts in the
armada-370-xp interrupt controller driver. It registers an MSI chip to
the MSI chip registry, which will be used by the Marvell PCIe host
controller driver.

The MSI interrupts use the 16 high doorbells, and are therefore
notified using IRQ1 of the main interrupt controller.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../devicetree/bindings/arm/armada-370-xp-mpic.txt |   3 +
 drivers/irqchip/irq-armada-370-xp.c                | 141 ++++++++++++++++++++-
 2 files changed, 143 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
index 61df564..d74091a 100644
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
@@ -4,6 +4,8 @@ Marvell Armada 370 and Armada XP Interrupt Controller
 Required properties:
 - compatible: Should be "marvell,mpic"
 - interrupt-controller: Identifies the node as an interrupt controller.
+- msi-controller: Identifies the node as an PCI Message Signaled
+  Interrupt controller.
 - #interrupt-cells: The number of cells to define the interrupts. Should be 1.
   The cell is the IRQ number
 
@@ -24,6 +26,7 @@ Example:
               #address-cells = <1>;
               #size-cells = <1>;
               interrupt-controller;
+              msi-controller;
               reg = <0xd0020a00 0x1d0>,
                     <0xd0021070 0x58>;
         };
diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index 26adc74..04efe64 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -21,7 +21,10 @@
 #include <linux/io.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <linux/of_pci.h>
 #include <linux/irqdomain.h>
+#include <linux/slab.h>
+#include <linux/msi.h>
 #include <asm/mach/arch.h>
 #include <asm/exception.h>
 #include <asm/smp_plat.h>
@@ -51,12 +54,20 @@
 #define IPI_DOORBELL_START                      (0)
 #define IPI_DOORBELL_END                        (8)
 #define IPI_DOORBELL_MASK                       0xFF
+#define PCI_MSI_DOORBELL_START                  (16)
+#define PCI_MSI_DOORBELL_NR                     (16)
+#define PCI_MSI_DOORBELL_END                    (32)
+#define PCI_MSI_DOORBELL_MASK                   0xFFFF0000
 
 static DEFINE_RAW_SPINLOCK(irq_controller_lock);
 
 static void __iomem *per_cpu_int_base;
 static void __iomem *main_int_base;
 static struct irq_domain *armada_370_xp_mpic_domain;
+#ifdef CONFIG_PCI_MSI
+static struct irq_domain *armada_370_xp_msi_domain;
+static phys_addr_t msi_doorbell_addr;
+#endif
 
 /*
  * In SMP mode:
@@ -87,6 +98,102 @@ static void armada_370_xp_irq_unmask(struct irq_data *d)
 				ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
 }
 
+#ifdef CONFIG_PCI_MSI
+
+static int armada_370_xp_setup_msi_irq(struct msi_chip *chip,
+				       struct pci_dev *pdev,
+				       struct msi_desc *desc)
+{
+	struct msi_msg msg;
+	irq_hw_number_t hwirq;
+	int virq;
+
+	virq = irq_alloc_mapping(armada_370_xp_msi_domain, &hwirq);
+	if (!virq)
+		return -EINVAL;
+
+	irq_set_msi_desc(virq, desc);
+
+	msg.address_lo = msi_doorbell_addr;
+	msg.address_hi = 0;
+	msg.data = 0xf00 | (hwirq + 16);
+
+	write_msi_msg(virq, &msg);
+	return 0;
+}
+
+static void armada_370_xp_teardown_msi_irq(struct msi_chip *chip,
+					   unsigned int irq)
+{
+	irq_dispose_mapping(irq);
+}
+
+static struct irq_chip armada_370_xp_msi_irq_chip = {
+	.name = "armada_370_xp_msi_irq",
+	.irq_enable = unmask_msi_irq,
+	.irq_disable = mask_msi_irq,
+	.irq_mask = mask_msi_irq,
+	.irq_unmask = unmask_msi_irq,
+};
+
+static int armada_370_xp_msi_map(struct irq_domain *domain, unsigned int virq,
+				 irq_hw_number_t hw)
+{
+	irq_set_chip_and_handler(virq, &armada_370_xp_msi_irq_chip,
+				 handle_simple_irq);
+	set_irq_flags(virq, IRQF_VALID);
+
+	return 0;
+}
+
+static const struct irq_domain_ops armada_370_xp_msi_irq_ops = {
+	.map = armada_370_xp_msi_map,
+};
+
+static int armada_370_xp_msi_init(struct device_node *node)
+{
+	struct msi_chip *msi_chip;
+	int ret;
+	u32 reg;
+
+	msi_chip = kzalloc(sizeof(*msi_chip), GFP_KERNEL);
+	if (!msi_chip)
+		return -ENOMEM;
+
+	armada_370_xp_msi_domain =
+		irq_domain_add_linear(NULL, PCI_MSI_DOORBELL_NR,
+				      &armada_370_xp_msi_irq_ops, NULL);
+	if (!armada_370_xp_msi_domain) {
+		kfree(msi_chip);
+		return -ENOMEM;
+	}
+
+	msi_chip->of_node = node;
+	msi_chip->setup_irq = armada_370_xp_setup_msi_irq;
+	msi_chip->teardown_irq = armada_370_xp_teardown_msi_irq;
+
+	ret = of_msi_chip_add(msi_chip);
+	if (ret < 0) {
+		irq_domain_remove(armada_370_xp_msi_domain);
+		kfree(msi_chip);
+		return ret;
+	}
+
+	reg = readl(per_cpu_int_base + ARMADA_370_XP_IN_DRBEL_MSK_OFFS)
+		| PCI_MSI_DOORBELL_MASK;
+
+	writel(reg, per_cpu_int_base +
+	       ARMADA_370_XP_IN_DRBEL_MSK_OFFS);
+
+	/* Unmask IPI interrupt */
+	writel(1, per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+
+	return 0;
+}
+#else
+static inline int armada_370_xp_msi_init(struct device_node *node) { return 0; }
+#endif
+
 #ifdef CONFIG_SMP
 static int armada_xp_set_affinity(struct irq_data *d,
 				  const struct cpumask *mask_val, bool force)
@@ -214,12 +321,39 @@ armada_370_xp_handle_irq(struct pt_regs *regs)
 		if (irqnr > 1022)
 			break;
 
-		if (irqnr > 0) {
+		if (irqnr > 1) {
 			irqnr =	irq_find_mapping(armada_370_xp_mpic_domain,
 					irqnr);
 			handle_IRQ(irqnr, regs);
 			continue;
 		}
+
+#ifdef CONFIG_PCI_MSI
+		/* MSI handling */
+		if (irqnr == 1) {
+			u32 msimask, msinr;
+
+			msimask = readl_relaxed(per_cpu_int_base +
+						ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS)
+				& PCI_MSI_DOORBELL_MASK;
+
+			writel(~PCI_MSI_DOORBELL_MASK, per_cpu_int_base +
+			       ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS);
+
+			for (msinr = PCI_MSI_DOORBELL_START;
+			     msinr < PCI_MSI_DOORBELL_END; msinr++) {
+				int irq;
+
+				if (!(msimask & BIT(msinr)))
+					continue;
+
+				irq = irq_find_mapping(armada_370_xp_msi_domain,
+						       msinr - 16);
+				handle_IRQ(irq, regs);
+			}
+		}
+#endif
+
 #ifdef CONFIG_SMP
 		/* IPI Handling */
 		if (irqnr == 0) {
@@ -269,6 +403,9 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 				   resource_size(&per_cpu_int_res));
 	BUG_ON(!per_cpu_int_base);
 
+	msi_doorbell_addr = main_int_res.start +
+		ARMADA_370_XP_SW_TRIG_INT_OFFS;
+
 	control = readl(main_int_base + ARMADA_370_XP_INT_CONTROL);
 
 	armada_370_xp_mpic_domain =
@@ -292,6 +429,8 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 
 #endif
 
+	armada_370_xp_msi_init(node);
+
 	set_handle_irq(armada_370_xp_handle_irq);
 
 	return 0;
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul  1 09:42:15 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon,  1 Jul 2013 15:42:15 +0200
Subject: [PATCHv4 10/11] pci: mvebu: add support for MSI
In-Reply-To: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1372686136-1370-11-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds support for Message Signaled Interrupts in the
Marvell PCIe host controller. The work is very simple: it simply gets
a reference to the msi_chip associated to the PCIe controller thanks
to the msi-parent DT property, and stores this reference in the
pci_bus structure. This is enough to let the Linux PCI core use the
functions of msi_chip to setup and teardown MSIs.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Reviewed-by: Thierry Reding <thierry.reding at gmail.com>
Acked-by: Bjorn Helgaas <bhelgaas at google.com>
---
 .../devicetree/bindings/pci/mvebu-pci.txt          |  3 +++
 drivers/pci/host/pci-mvebu.c                       | 26 ++++++++++++++++++++++
 2 files changed, 29 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index f8d4058..77e0ffe 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -12,6 +12,8 @@ Mandatory properties:
 - device_type, set to "pci"
 - ranges: ranges for the PCI memory and I/O regions, as well as the
   MMIO registers to control the PCIe interfaces.
+- msi-parent: Link to the hardware entity that serves as the Message
+  Signaled Interrupt controller for this PCI controller.
 
 In addition, the Device Tree node must have sub-nodes describing each
 PCIe interface, having the following mandatory properties:
@@ -46,6 +48,7 @@ pcie-controller {
 	#size-cells = <2>;
 
 	bus-range = <0x00 0xff>;
+	msi-parent = <&mpic>;
 
 	ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
 		  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 13a633b..396f578 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -11,6 +11,7 @@
 #include <linux/clk.h>
 #include <linux/module.h>
 #include <linux/mbus.h>
+#include <linux/msi.h>
 #include <linux/slab.h>
 #include <linux/platform_device.h>
 #include <linux/of_address.h>
@@ -107,6 +108,7 @@ struct mvebu_pcie_port;
 struct mvebu_pcie {
 	struct platform_device *pdev;
 	struct mvebu_pcie_port *ports;
+	struct msi_chip *msi;
 	struct resource io;
 	struct resource realio;
 	struct resource mem;
@@ -695,6 +697,12 @@ static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 	return bus;
 }
 
+void mvebu_pcie_add_bus(struct pci_bus *bus)
+{
+	struct mvebu_pcie *pcie = sys_to_pcie(bus->sysdata);
+	bus->msi = pcie->msi;
+}
+
 resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev,
 					  const struct resource *res,
 					  resource_size_t start,
@@ -731,6 +739,7 @@ static void __init mvebu_pcie_enable(struct mvebu_pcie *pcie)
 	hw.map_irq        = mvebu_pcie_map_irq;
 	hw.ops            = &mvebu_pcie_ops;
 	hw.align_resource = mvebu_pcie_align_resource;
+	hw.add_bus        = mvebu_pcie_add_bus;
 
 	pci_common_init(&hw);
 }
@@ -755,6 +764,21 @@ mvebu_pcie_map_registers(struct platform_device *pdev,
 	return devm_request_and_ioremap(&pdev->dev, &regs);
 }
 
+static void __init mvebu_pcie_msi_enable(struct mvebu_pcie *pcie)
+{
+	struct device_node *msi_node;
+
+	msi_node = of_parse_phandle(pcie->pdev->dev.of_node,
+				    "msi-parent", 0);
+	if (!msi_node)
+		return;
+
+	pcie->msi = of_find_msi_chip_by_node(msi_node);
+
+	if (pcie->msi)
+		pcie->msi->dev = &pcie->pdev->dev;
+}
+
 static int __init mvebu_pcie_probe(struct platform_device *pdev)
 {
 	struct mvebu_pcie *pcie;
@@ -879,6 +903,8 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
 		i++;
 	}
 
+	mvebu_pcie_msi_enable(pcie);
+
 	mvebu_pcie_enable(pcie);
 
 	return 0;
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul  1 09:42:16 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon,  1 Jul 2013 15:42:16 +0200
Subject: [PATCHv4 11/11] arm: mvebu: link PCIe controllers to the MSI
 controller
In-Reply-To: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1372686136-1370-12-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adjusts the Armada 370 and Armada XP PCIe controllers
Device Tree informations to reference their MSI controller. In the
case of this platform, the MSI controller is implemented by the MPIC.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-370.dtsi        | 1 +
 arch/arm/boot/dts/armada-xp-mv78230.dtsi | 1 +
 arch/arm/boot/dts/armada-xp-mv78260.dtsi | 1 +
 arch/arm/boot/dts/armada-xp-mv78460.dtsi | 1 +
 4 files changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..a60018d 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -178,6 +178,7 @@
 				#address-cells = <3>;
 				#size-cells = <2>;
 
+				msi-parent = <&mpic>;
 				bus-range = <0x00 0xff>;
 
 				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f8eaa38..4a9a305 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -91,6 +91,7 @@
 #address-cells = <3>;
 #size-cells = <2>;
 
+				msi-parent = <&mpic>;
 				bus-range = <0x00 0xff>;
 
 				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index f4029f0..bc63783 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -111,6 +111,7 @@
 				#address-cells = <3>;
 				#size-cells = <2>;
 
+				msi-parent = <&mpic>;
 				bus-range = <0x00 0xff>;
 
 				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index c7b1f4d..77db2bc 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -127,6 +127,7 @@
 				#address-cells = <3>;
 				#size-cells = <2>;
 
+				msi-parent = <&mpic>;
 				bus-range = <0x00 0xff>;
 
 				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-- 
1.8.1.2



From festevam at gmail.com  Mon Jul  1 09:46:37 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 1 Jul 2013 10:46:37 -0300
Subject: [PATCH 1/2] ARM: dts: mx53qsb: Enable VPU support
In-Reply-To: <1372683396.4971.35.camel@pizza.hi.pengutronix.de>
References: <1372459759-10488-1-git-send-email-festevam@gmail.com>
 <1372683396.4971.35.camel@pizza.hi.pengutronix.de>
Message-ID: <CAOMZO5Chnn72t12rf6tkrWNSnDreKsh57nagKc5_Vhi0j_mSWw@mail.gmail.com>

On Mon, Jul 1, 2013 at 9:56 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> Hi Fabio,
>
> Am Freitag, den 28.06.2013, 19:49 -0300 schrieb Fabio Estevam:
>> From: Fabio Estevam <fabio.estevam at freescale.com>
>>
>> Enable Video Processing Unit (VPU) support.
>>
>> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
>> ---
>> Depends on Philipp Zabel's patch:
>> [PATCH] ARM: dts: add sram for imx53 and imx6q
>>
>> Philipp,
>>
>> I tried using the original mx53 vpu firmware that comes with the FSL BSP, but it
>> failed to load:
>>
>> coda 63ff4000.vpu: firmware get command error
>> coda 63ff4000.vpu: HW initialization failed
>>
>> Any suggestions?
>>
>> Thanks!
>
> /*
>  * The CODA driver needs the raw firmware without header in memory order.
>  * This is how I converted vpu_fw_imx53.bin from the Freescale BSP into
>  * v4l2-coda7541-imx53.bin:
>  */

Thanks for your C code, Philipp.

Now I get:

coda 63ff4000.vpu: Initialized CODA7541.
coda 63ff4000.vpu: Unsupported firmware version: 13.4.41
coda 63ff4000.vpu: codec registered as /dev/video0

As input file I am using the vpu_fw_imx53.bin from FSL BSP version 11.09.

Where should I get the vpu_fw_imx53.bin file so that I do not get the
unsupported warning?

Thanks,

Fabio Estevam


From shawn.guo at linaro.org  Mon Jul  1 09:51:27 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 21:51:27 +0800
Subject: [PATCHv4 0/8] ARM: mxs: Various Crystalfontz DT additions
In-Reply-To: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
References: <1372685009-15564-1-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <20130701135125.GN13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 03:23:21PM +0200, Alexandre Belloni wrote:
> Alexandre Belloni (6):
>   ARM: mxs: Simplify detection of CrystalFontz boards
>   ARM: mxs: dt: cfa10037: make hogpins grabbed by respective drivers
>   ARM: mxs: dt: cfa10049: make hogpins grabbed by respective drivers
>   ARM: mxs: dt: cfa10055: make hogpins grabbed by respective drivers
>   ARM: mxs: dt: cfa10057: remove hogpins
>   ARM: mxs: dt: cfa10036: make hogpins grabbed by respective drivers
> 
> Brian Lilly (2):
>   ARM: mxs: dt: Add Crystalfontz CFA-10056 device tree
>   ARM: mxs: dt: Add Crystalfontz CFA-10058 device tree

All applied, thanks.

Shawn



From shawn.guo at linaro.org  Mon Jul  1 09:55:24 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 21:55:24 +0800
Subject: [PATCH 1/4] ASoC: sgtl5000: give it a ramping time before writting
In-Reply-To: <201307011254.18952.marex@denx.de>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>
 <20130701100710.GB27646@sirena.org.uk>
 <201307011254.18952.marex@denx.de>
Message-ID: <20130701135522.GO13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 12:54:18PM +0200, Marek Vasut wrote:
> Dear Mark Brown,
> 
> > On Mon, Jul 01, 2013 at 04:16:08PM +0800, Shawn Guo wrote:
> > > +	/*
> > > +	 * It seems that sgtl5000 takes a longer time to get the registers
> > > +	 * ready for write than bread.  Let's give it a ramping time before
> > > +	 * the first write goes.
> > > +	 */
> > > +	msleep(50);
> > > +
> > > 
> > >  	/* Ensure sgtl5000 will start with sane register values */
> > >  	ret = sgtl5000_fill_defaults(sgtl5000);
> > >  	if (ret)
> > 
> > This seems like a really odd place to add the sleep - I'd have expected
> > this to be a part of or just after the reset operation.  It's a *really*
> > long sleep too, though if that's what you need that's what you need.
> 
> The delay might also be caused by the I2C driver, I have this in my ToDo to 
> check, but I didn't get to it yet. On the other hand, if subsequent IO does 
> work, then it's unlikely to be the case.

Right, since read is already working there.

Shawn



From santosh.shilimkar at ti.com  Mon Jul  1 09:58:35 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 1 Jul 2013 09:58:35 -0400
Subject: [PATCH] of: Specify initrd location using 64-bit
In-Reply-To: <CAMuHMdV6YM3-hASqjxkguEukZjnjK80gBjDNiabxjfQtC=c8ag@mail.gmail.com>
References: <1371775956-16453-1-git-send-email-santosh.shilimkar@ti.com>
 <51C4171C.9050908@linutronix.de> <51C48B5A.2040404@ti.com>
 <51CCA67C.2010803@gmail.com>
 <CACxGe6vOH0sCFVVXrYqD3dbYdOvithVu7-d1cvy5885i8x_Myw@mail.gmail.com>
 <20130628134931.GD21034@game.jcrosoft.org> <51CE1F92.3070802@ti.com>
 <51D1345B.8020509@linutronix.de>
 <CAMuHMdV6YM3-hASqjxkguEukZjnjK80gBjDNiabxjfQtC=c8ag@mail.gmail.com>
Message-ID: <51D18B0B.1060906@ti.com>

On Monday 01 July 2013 03:59 AM, Geert Uytterhoeven wrote:
> On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
> <bigeasy at linutronix.de> wrote:
>> On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
>>> Apart from waste of 32bit, what is the other concern you
>>> have ?
>>
>> You pass a u64 as a physical address which is represented in other
>> parts of the kernel (for a good reason) by phys_addr_t.
>>
>>> I really want to converge on this patch because it
>>> has been a open ended discussion for quite some time. Does
>>> that really break any thing on x86 or your concern is more
>>> from semantics of the physical address.
>> You want to have your code in so you can continue with your work, that
>> is okay. The other two arguments why u64 here is a good thing was "due
>> to what I said earlier" and "+1" and I don't have the time to look
>> that up.
>>
>> There should be no problems on x86 if this goes in as it is now.
>>
>> But think about this: What happens if you boot your ARM device without
>> PAE and your initrd is in the upper region? If you are lucky the kernel
>> looks at a different place where it also has a read permission, notices
>> nothing sane is there, writes a message and continues. And if it is not
>> allowed to read? It is clearly the user's fault for booting a non-PAE
>> kernel.
> 
> That's actual the original reason: DT has it as 64 bit, and passes it to a
> 32 bit kernel when running in 32 bit mode without PAE.
> 
Thanks all for comments and useful discussion. I will resubmit the
patch with update to fix the printk warnings reported by Vineet and
James post the $subject change.

Am assuming the patch will go via Grant Likely's tree.

Regards,
Santosh



From festevam at gmail.com  Mon Jul  1 09:59:20 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 1 Jul 2013 10:59:20 -0300
Subject: [PATCH 1/2] ARM: dts: mx53qsb: Enable VPU support
In-Reply-To: <CAOMZO5Chnn72t12rf6tkrWNSnDreKsh57nagKc5_Vhi0j_mSWw@mail.gmail.com>
References: <1372459759-10488-1-git-send-email-festevam@gmail.com>
 <1372683396.4971.35.camel@pizza.hi.pengutronix.de>
 <CAOMZO5Chnn72t12rf6tkrWNSnDreKsh57nagKc5_Vhi0j_mSWw@mail.gmail.com>
Message-ID: <CAOMZO5DGcrB-mGMODJFY2fXxNKt9dDPc5i5KUMJ_bwbBFQJMxQ@mail.gmail.com>

Hi Philipp,

On Mon, Jul 1, 2013 at 10:46 AM, Fabio Estevam <festevam at gmail.com> wrote:

> Thanks for your C code, Philipp.
>
> Now I get:
>
> coda 63ff4000.vpu: Initialized CODA7541.
> coda 63ff4000.vpu: Unsupported firmware version: 13.4.41
> coda 63ff4000.vpu: codec registered as /dev/video0
>
> As input file I am using the vpu_fw_imx53.bin from FSL BSP version 11.09.
>
> Where should I get the vpu_fw_imx53.bin file so that I do not get the
> unsupported warning?

Ok, now I used the mx53 firmware from the latest FSL 4.0.0 BSP and I get:

coda 63ff4000.vpu: Initialized CODA7541.
coda 63ff4000.vpu: Unsupported firmware version: 1.4.50
coda 63ff4000.vpu: codec registered as /dev/video0

and it seems that the version warning appears because your patch:
https://linuxtv.org/patch/19020/ is not applied in the tree linux-next
tree I am using.

Thanks,

Fabio Estevam


From jonas.jensen at gmail.com  Mon Jul  1 10:02:39 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Mon,  1 Jul 2013 16:02:39 +0200
Subject: [PATCH v4] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <1372332203-30228-1-git-send-email-jonas.jensen@gmail.com>
References: <1372332203-30228-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1372687359-18235-1-git-send-email-jonas.jensen@gmail.com>

This patch adds an clocksource driver for the main timer(s)
found on MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    This should hopefully address most of the issues pointed out by Thomas.
    
    Preventing the counter from passing match, TIMER1 is now stopped before
    count is read, I leave it up to you to comment.
    
    I think REG_MATCH1 triggers on ==, or rather, I have no reason to believe
    otherwise. Documentation does not seem to be publicly available, at least
    my searches have come up empty.
    
    The old 2.6.9 sources which this is loosely derived from, rely entirely on
    setting load with periodic timer_tick. REG_MATCH1 was never used there.
    
    Applies to next-20130619
    
    Changes since v3:
    
    1. fix indentation
    2. stop TIMER1 before reading count in moxart_clkevt_next_event
    3. use tabs to align assigned values
    4. handle errors and use more consistent messages
    5. change max_delta from 0xf0000000 to 0xfffffffe (and add comment)

 drivers/clocksource/Makefile       |   1 +
 drivers/clocksource/moxart_timer.c | 165 +++++++++++++++++++++++++++++++++++++
 2 files changed, 166 insertions(+)
 create mode 100644 drivers/clocksource/moxart_timer.c

diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 8d979c7..c93e1a8 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_CLKSRC_SAMSUNG_PWM)	+= samsung_pwm_timer.o
 
 obj-$(CONFIG_ARM_ARCH_TIMER)		+= arm_arch_timer.o
 obj-$(CONFIG_CLKSRC_METAG_GENERIC)	+= metag_generic.o
+obj-$(CONFIG_ARCH_MOXART)	+= moxart_timer.o
diff --git a/drivers/clocksource/moxart_timer.c b/drivers/clocksource/moxart_timer.c
new file mode 100644
index 0000000..ae95a11
--- /dev/null
+++ b/drivers/clocksource/moxart_timer.c
@@ -0,0 +1,165 @@
+/*
+ * MOXA ART SoCs timer handling.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqreturn.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/io.h>
+#include <linux/clocksource.h>
+
+#define TIMER1_BASE		0x00
+#define TIMER2_BASE		0x10
+#define TIMER3_BASE		0x20
+
+#define REG_COUNT		0x0 /* writable */
+#define REG_LOAD		0x4
+#define REG_MATCH1		0x8
+#define REG_MATCH2		0xC
+
+#define TIMER_CR		0x30
+#define TIMER_INTR_STATE	0x34
+#define TIMER_INTR_MASK		0x38
+
+/*
+ * TIMER_CR flags:
+ *
+ * TIMEREG_CR_*_CLOCK	0: PCLK, 1: EXT1CLK
+ * TIMEREG_CR_*_INT	overflow interrupt enable bit
+ */
+#define TIMEREG_CR_1_ENABLE	(1 << 0)
+#define TIMEREG_CR_1_CLOCK	(1 << 1)
+#define TIMEREG_CR_1_INT	(1 << 2)
+#define TIMEREG_CR_2_ENABLE	(1 << 3)
+#define TIMEREG_CR_2_CLOCK	(1 << 4)
+#define TIMEREG_CR_2_INT	(1 << 5)
+#define TIMEREG_CR_3_ENABLE	(1 << 6)
+#define TIMEREG_CR_3_CLOCK	(1 << 7)
+#define TIMEREG_CR_3_INT	(1 << 8)
+#define TIMEREG_CR_COUNT_UP	(1 << 9)
+#define TIMEREG_CR_COUNT_DOWN	(0 << 9)
+
+static void __iomem *base;
+static unsigned int clock_count_per_tick;
+
+static void moxart_clkevt_mode(enum clock_event_mode mode,
+			       struct clock_event_device *clk)
+{
+	u32 u = readl(base + TIMER_CR);
+
+	switch (mode) {
+	case CLOCK_EVT_MODE_RESUME:
+	case CLOCK_EVT_MODE_ONESHOT:
+		u &= ~TIMEREG_CR_1_ENABLE;
+		writel(u, base + TIMER_CR);
+		writel(~0, base + TIMER1_BASE + REG_LOAD);
+		break;
+	case CLOCK_EVT_MODE_PERIODIC:
+		writel(clock_count_per_tick, base + TIMER1_BASE + REG_LOAD);
+		u |= TIMEREG_CR_1_ENABLE;
+		writel(u, base + TIMER_CR);
+		break;
+	case CLOCK_EVT_MODE_UNUSED:
+	case CLOCK_EVT_MODE_SHUTDOWN:
+	default:
+		u &= ~TIMEREG_CR_1_ENABLE;
+		writel(u, base + TIMER_CR);
+		break;
+	}
+}
+
+static int moxart_clkevt_next_event(unsigned long cycles,
+				    struct clock_event_device *unused)
+{
+	u32 u;
+
+	u = readl(base + TIMER_CR) & ~TIMEREG_CR_1_ENABLE;
+	writel(u, base + TIMER_CR);
+	u = readl(base + TIMER1_BASE + REG_COUNT) - cycles;
+	writel(u, base + TIMER1_BASE + REG_MATCH1);
+	u = readl(base + TIMER_CR) | TIMEREG_CR_1_ENABLE;
+	writel(u, base + TIMER_CR);
+	return 0;
+}
+
+static struct clock_event_device moxart_clockevent = {
+	.name		= "moxart_timer",
+	.rating		= 200,
+	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
+	.set_mode	= moxart_clkevt_mode,
+	.set_next_event	= moxart_clkevt_next_event,
+};
+
+static irqreturn_t moxart_timer_interrupt(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+	evt->event_handler(evt);
+	return IRQ_HANDLED;
+}
+
+static struct irqaction moxart_timer_irq = {
+	.name		= "moxart-timer",
+	.flags		= IRQF_TIMER,
+	.handler	= moxart_timer_interrupt,
+	.dev_id		= &moxart_clockevent,
+};
+
+static void __init moxart_timer_init(struct device_node *node)
+{
+	int ret, irq;
+	unsigned long pclk;
+	struct clk *clk;
+
+	base = of_iomap(node, 0);
+	if (!base)
+		panic("%s: of_iomap failed\n", node->full_name);
+
+	irq = irq_of_parse_and_map(node, 0);
+	if (irq <= 0)
+		panic("%s: irq_of_parse_and_map failed\n", node->full_name);
+
+	ret = setup_irq(irq, &moxart_timer_irq);
+	if (ret)
+		panic("%s: setup_irq failed\n", node->full_name);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk))
+		panic("%s: of_clk_get failed\n", node->full_name);
+
+	pclk = clk_get_rate(clk);
+
+	if (clocksource_mmio_init(base + TIMER2_BASE + REG_COUNT,
+				  "moxart_timer", pclk, 200, 32,
+				  clocksource_mmio_readl_down))
+		panic("%s: clocksource_mmio_init failed\n", node->full_name);
+
+	clock_count_per_tick = DIV_ROUND_CLOSEST(pclk, HZ);
+
+	writel(~0, base + TIMER2_BASE + REG_LOAD);
+	writel(TIMEREG_CR_2_ENABLE, base + TIMER_CR);
+
+	moxart_clockevent.cpumask = cpumask_of(0);
+
+	/*
+	 * documentation is not publicly available:
+	 * min_delta / max_delta obtained by trial-and-error,
+	 * max_delta 0xfffffffe should be ok because count
+	 * register size is u32
+	 */
+	clockevents_config_and_register(&moxart_clockevent, pclk,
+					0x4, 0xfffffffe);
+}
+CLOCKSOURCE_OF_DECLARE(moxart, "moxa,moxart-timer", moxart_timer_init);
-- 
1.8.2.1



From pavel at ucw.cz  Mon Jul  1 10:03:20 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Mon, 1 Jul 2013 16:03:20 +0200
Subject: [PATCH] N900: fix operation on emulator
In-Reply-To: <20130617111031.GQ20992@atomide.com>
References: <20130613132624.GA3464@amd.pavel.ucw.cz>
 <20130613141001.GF8164@atomide.com>
 <20130613142809.GA3775@amd.pavel.ucw.cz>
 <20130613145724.GH8164@atomide.com>
 <20130613155240.GB3775@amd.pavel.ucw.cz>
 <20130613161418.GJ8164@atomide.com>
 <20130613230808.GA14876@amd.pavel.ucw.cz>
 <20130614055629.GM8164@atomide.com>
 <20130614212816.GA31768@atrey.karlin.mff.cuni.cz>
 <20130617111031.GQ20992@atomide.com>
Message-ID: <20130701140315.GA15318@amd.pavel.ucw.cz>

Errata workarounds for N900 hardware actually break operation on
emulator. Fix it.

This approach was suggested by Pali Roh?r <pali.rohar at gmail.com>
(thanks!).

(Also explain what "sleep_ind" led actually does).

Signed-off-by: Pavel Machek <pavel at ucw.cz>

diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 74f83a5..81f7b9f 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -33,9 +33,12 @@
 #include "pm.h"
 #include "sdram-nokia.h"
 #include "board-rx51-secure.h"
+#include "soc.h"
 
 #define RX51_GPIO_SLEEP_IND 162
 
+/* This lights up left part of keyboard */
+
 static struct gpio_led gpio_leds[] = {
 	{
 		.name	= "sleep_ind",
@@ -107,9 +110,11 @@ static void __init rx51_init(void)
 	rx51_camera_init();
 
 #ifdef CONFIG_ARM_ERRATA_430973
-	printk(KERN_INFO "RX-51: Enabling ARM errata 430973 workaround.\n");
-	/* set IBE to 1 */
-	rx51_secure_update_aux_cr(1 << 6, 0);
+	if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
+		printk(KERN_INFO "RX-51: Enabling ARM errata 430973 workaround.\n");
+		/* set IBE to 1 */
+		rx51_secure_update_aux_cr(1 << 6, 0);
+	}
 #endif
 
 	/* Ensure SDRC pins are mux'd for self-refresh */

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From shawn.guo at linaro.org  Mon Jul  1 10:04:55 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 22:04:55 +0800
Subject: [PATCH 1/4] ASoC: sgtl5000: give it a ramping time before writting
In-Reply-To: <20130701100710.GB27646@sirena.org.uk>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>
 <20130701100710.GB27646@sirena.org.uk>
Message-ID: <20130701140454.GP13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 11:07:10AM +0100, Mark Brown wrote:
> On Mon, Jul 01, 2013 at 04:16:08PM +0800, Shawn Guo wrote:
> 
> > +	/*
> > +	 * It seems that sgtl5000 takes a longer time to get the registers
> > +	 * ready for write than bread.  Let's give it a ramping time before
> > +	 * the first write goes.
> > +	 */
> > +	msleep(50);
> > +
> >  	/* Ensure sgtl5000 will start with sane register values */
> >  	ret = sgtl5000_fill_defaults(sgtl5000);
> >  	if (ret)
> 
> This seems like a really odd place to add the sleep - I'd have expected
> this to be a part of or just after the reset operation.

Since I do not see any reset operation between clk_prepare_enable()
and sgtl5000_fill_defaults(), so I will move the sleep into
sgtl5000_fill_defaults() call.

> It's a *really*
> long sleep too, though if that's what you need that's what you need.
> 
Yeah, from my testing it's what we need.


> Also "bread" :)

Yeah, I was really hungry when writing the comment.

Shawn



From p.zabel at pengutronix.de  Mon Jul  1 10:06:00 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon, 01 Jul 2013 16:06:00 +0200
Subject: [PATCH 1/2] ARM: dts: mx53qsb: Enable VPU support
In-Reply-To: <CAOMZO5Chnn72t12rf6tkrWNSnDreKsh57nagKc5_Vhi0j_mSWw@mail.gmail.com>
References: <1372459759-10488-1-git-send-email-festevam@gmail.com>
 <1372683396.4971.35.camel@pizza.hi.pengutronix.de>
 <CAOMZO5Chnn72t12rf6tkrWNSnDreKsh57nagKc5_Vhi0j_mSWw@mail.gmail.com>
Message-ID: <1372687560.4971.40.camel@pizza.hi.pengutronix.de>

Hi Fabio,

Am Montag, den 01.07.2013, 10:46 -0300 schrieb Fabio Estevam:
> On Mon, Jul 1, 2013 at 9:56 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> > Hi Fabio,
> >
> > Am Freitag, den 28.06.2013, 19:49 -0300 schrieb Fabio Estevam:
> >> From: Fabio Estevam <fabio.estevam at freescale.com>
> >>
> >> Enable Video Processing Unit (VPU) support.
> >>
> >> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> >> ---
> >> Depends on Philipp Zabel's patch:
> >> [PATCH] ARM: dts: add sram for imx53 and imx6q
> >>
> >> Philipp,
> >>
> >> I tried using the original mx53 vpu firmware that comes with the FSL BSP, but it
> >> failed to load:
> >>
> >> coda 63ff4000.vpu: firmware get command error
> >> coda 63ff4000.vpu: HW initialization failed
> >>
> >> Any suggestions?
> >>
> >> Thanks!
> >
> > /*
> >  * The CODA driver needs the raw firmware without header in memory order.
> >  * This is how I converted vpu_fw_imx53.bin from the Freescale BSP into
> >  * v4l2-coda7541-imx53.bin:
> >  */
> 
> Thanks for your C code, Philipp.
> 
> Now I get:
> 
> coda 63ff4000.vpu: Initialized CODA7541.
> coda 63ff4000.vpu: Unsupported firmware version: 13.4.41
> coda 63ff4000.vpu: codec registered as /dev/video0
> 
> As input file I am using the vpu_fw_imx53.bin from FSL BSP version 11.09.
> 
> Where should I get the vpu_fw_imx53.bin file so that I do not get the
> unsupported warning?

The current firmware version is 1.4.50 (yes, 1.4.50 > 13.4.41). It is
contained in the L3.0.35_12.09.01 or L3.0.35_4.0.0 (20130424) BSP
releases.

regards
Philipp



From shc_work at mail.ru  Mon Jul  1 10:08:10 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Mon, 01 Jul 2013 18:08:10 +0400
Subject: =?UTF-8?B?UmVbMl06IFtQQVRDSF0gQVJNOiBkdHM6IGkuTVgyNzogQWRkIFNlY29uZGFy?=
 =?UTF-8?B?eSBBSEIgUG9ydCBkZWZpbml0aW9ucw==?=
In-Reply-To: <20130701125819.GJ13206@S2101-09.ap.freescale.net>
References: <1372487325-14405-1-git-send-email-shc_work@mail.ru>
 <20130701125819.GJ13206@S2101-09.ap.freescale.net>
Message-ID: <1372687690.31793480@f308.mail.ru>

> On Sat, Jun 29, 2013 at 10:28:45AM +0400, Alexander Shiyan wrote:
> > Patch adds Secondary AHB Port definitions for i.MX27 SOC and
> > moves NAND Flash Controller (NFC) under AHB Slave Port 1.
> > 
> > Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> > ---
> >  arch/arm/boot/dts/imx27.dtsi | 28 ++++++++++++++++++++++------
> >  1 file changed, 22 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
> > index 86b6f5f..7c0179e 100644
> > --- a/arch/arm/boot/dts/imx27.dtsi
> > +++ b/arch/arm/boot/dts/imx27.dtsi
> > @@ -399,14 +399,30 @@
> >  			};
> >  		};
> >  
> > -		nfc: nand at d8000000 {
> > +		ahb1: ahb at 80000000 { /* Secondary AHB Slave Port 1 */
> 
> We do not have the top level of AHB bus topology represented in device
> tree.  Your patch introduces it, partially - all about Secondary AHB
> Slave but nothing about Primary AHB.
> 
> I'm not really fond of the change, since it's not extremely useful to
> me.  Do you have a real reason for the change?

Introducing primary bus will produce a completely different i.MX27 DTS,
since it contain AIPI1,2 and iram.
Introduction of buses has no effect, other than the possibility of using labels
and minimal validation of nodes to the correct address.
In this case, I define the bus here for the subsequent addition of WEIM,
for a better understanding of what and where is.
Of course we can do without it. Think is it unnecessary?
Thanks.

---

From santosh.shilimkar at ti.com  Mon Jul  1 10:10:02 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 1 Jul 2013 10:10:02 -0400
Subject: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM
In-Reply-To: <CAE9FiQUoVNvWmmTV2+ZkU_nMxFToTHw6QLwp_Z_EjwMzqdLwuA@mail.gmail.com>
References: <1372467663-31425-1-git-send-email-santosh.shilimkar@ti.com>
 <20130629152959.GB31339@mtj.dyndns.org>
 <20130629172123.GA3353@n2100.arm.linux.org.uk>
 <20130629175743.GA382@mtj.dyndns.org>
 <CAE9FiQXHuP-n0eZ9wN73V4nSvE+XEExDsx1t50_=YaW+V=LGLg@mail.gmail.com>
 <20130629195549.GE3353@n2100.arm.linux.org.uk>
 <CAE9FiQUoVNvWmmTV2+ZkU_nMxFToTHw6QLwp_Z_EjwMzqdLwuA@mail.gmail.com>
Message-ID: <51D18DBA.6090608@ti.com>

On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>> system to boot without the MMU being on, as they may have more than
>>>>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>>>>> suitable for use as a "lowmem" mapping.
>>>
>>> is that 32bit ARM or 64bit ARM?
>>
>> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.
> 
Thanks Russell for clarifying the issue on the thread. Another major
reason of not being to use 32 bit alias address space for lowmem
is that address space isn't coherent on the SOC am dealing with.

> 32bit ARM does not support NO_BOOTMEM yet.
> 
> arch/arc/Kconfig:       select NO_BOOTMEM
> arch/arm64/Kconfig:     select NO_BOOTMEM
> arch/sparc/Kconfig:     select NO_BOOTMEM
> arch/x86/Kconfig:config NO_BOOTMEM
> 
> 
> so may need to
> 1. make 32bit ARM to use NO_BOOTMEM at first.
> 
Sorry. I should have mentioned that in the change-log. 
I have been carrying some WIP patches for ARM. Will post them
on ARM list after finishing remainder of the testing.

> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
> 
> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
> 
> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
> 
Great that we all agree to see back of nobootmem.c and have a direct
memblock API. Will be happy to help in conversion to proposed new interfaces
if I can get the alloc_memblock API and core related changes.

Will be good to know who is going to create proposed memblock API
so that we all can collaborate in conversion.

Regards,
Santosh 


From festevam at gmail.com  Mon Jul  1 10:12:48 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 1 Jul 2013 11:12:48 -0300
Subject: [alsa-devel] [PATCH 1/4] ASoC: sgtl5000: give it a ramping time
 before writting
In-Reply-To: <201307011254.18952.marex@denx.de>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>
 <20130701100710.GB27646@sirena.org.uk>
 <201307011254.18952.marex@denx.de>
Message-ID: <CAOMZO5BAs5-Tf_O0TVLFAuCchVuukV+bH2MpjqMU83tTw2GD=Q@mail.gmail.com>

On Mon, Jul 1, 2013 at 7:54 AM, Marek Vasut <marex at denx.de> wrote:

> The delay might also be caused by the I2C driver, I have this in my ToDo to

Yes, this extra delay could be related to the mxs i2c driver, as we do
not need to add this delay when using sgtl5000 on other i.mx devices.

Other people have also reported mxs i2c issues currently:
http://marc.info/?l=linux-i2c&m=137241339917261&w=2

,so this may be related some how.

Regards,

Fabio Estevam


From santosh.shilimkar at ti.com  Mon Jul  1 10:14:45 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 1 Jul 2013 10:14:45 -0400
Subject: [RFC PATCH 5/6] ARM, mm: change meaning of max_low_pfn to maximum
 pfn for nobootmem
In-Reply-To: <1364184674-13798-6-git-send-email-iamjoonsoo.kim@lge.com>
References: <1364184674-13798-1-git-send-email-iamjoonsoo.kim@lge.com>
 <1364184674-13798-6-git-send-email-iamjoonsoo.kim@lge.com>
Message-ID: <51D18ED5.50103@ti.com>

Joonsoo,

On Monday 25 March 2013 12:11 AM, Joonsoo Kim wrote:
> nobootmem use max_low_pfn for computing boundary in free_all_bootmem()
> So we need proper value to max_low_pfn.
> 
> But, there is some difficulty related to max_low_pfn. max_low_pfn is used
> for two meanings in various architectures. One is for number of pages
> in lowmem and the other is for maximum lowmem pfn. Now, in ARM, it is used
> as number of pages in lowmem. You can get more information in below link.
> http://lwn.net/Articles/543408/
> http://lwn.net/Articles/543424/
> 
> As I investigated, architectures which use max_low_pfn as maximum pfn are
> more than others, so to change meaning of max_low_pfn to maximum pfn
> is preferable solution to me. This patch change max_low_pfn as maximum
> lowmem pfn in ARM. In addition, min_low_pfn, max_pfn is assigned according
> to this criteria.
> 
> There is no real user for max_low_pfn except block/blk-setting.c and
> blk-setting.c assume that max_low_pfn is maximum lowmem pfn,
> so this patch may not harm anything.
> 
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim at lge.com>
>
I have been also carrying similar patch as yours in an attempt
to make LPAE kernel work on ARM. Your patch carries better
description, so will your version and include in my series
which I plan to post on the list after some more testing.
Will copy you. The changes are very similar to your series.

Regards,
Santosh
 



From shawn.guo at linaro.org  Mon Jul  1 10:17:12 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 22:17:12 +0800
Subject: [PATCH] ARM: dts: i.MX27: Add Secondary AHB Port definitions
In-Reply-To: <1372687690.31793480@f308.mail.ru>
References: <1372487325-14405-1-git-send-email-shc_work@mail.ru>
 <20130701125819.GJ13206@S2101-09.ap.freescale.net>
 <1372687690.31793480@f308.mail.ru>
Message-ID: <20130701141710.GQ13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 06:08:10PM +0400, Alexander Shiyan wrote:
> Introducing primary bus will produce a completely different i.MX27 DTS,
> since it contain AIPI1,2 and iram.

That's one reason I would stay away from the change, because if the
addition of Secondary AHB is accepted, it will be a little more
difficult for us to say NO to people who love to have Primary AHB added.

> Introduction of buses has no effect, other than the possibility of using labels
> and minimal validation of nodes to the correct address.

Only if there is no code in the kernel searching a node via node path.

> In this case, I define the bus here for the subsequent addition of WEIM,
> for a better understanding of what and where is.
> Of course we can do without it. Think is it unnecessary?

Great, please do without it then, thanks.

Shawn



From shawn.guo at linaro.org  Mon Jul  1 10:26:12 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 22:26:12 +0800
Subject: [alsa-devel] [PATCH 1/4] ASoC: sgtl5000: give it a ramping time
 before writting
In-Reply-To: <CAOMZO5BAs5-Tf_O0TVLFAuCchVuukV+bH2MpjqMU83tTw2GD=Q@mail.gmail.com>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>
 <20130701100710.GB27646@sirena.org.uk>
 <201307011254.18952.marex@denx.de>
 <CAOMZO5BAs5-Tf_O0TVLFAuCchVuukV+bH2MpjqMU83tTw2GD=Q@mail.gmail.com>
Message-ID: <20130701142610.GR13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 11:12:48AM -0300, Fabio Estevam wrote:
> On Mon, Jul 1, 2013 at 7:54 AM, Marek Vasut <marex at denx.de> wrote:
> 
> > The delay might also be caused by the I2C driver, I have this in my ToDo to
> 
> Yes, this extra delay could be related to the mxs i2c driver, as we do
> not need to add this delay when using sgtl5000 on other i.mx devices.
> 
> Other people have also reported mxs i2c issues currently:
> http://marc.info/?l=linux-i2c&m=137241339917261&w=2
> 
> ,so this may be related some how.

How does it explain the fact that sgtl5000 read has been working there?
The sgtl5000 revision has been successfully read out at that point.

Shawn



From thomas.petazzoni at free-electrons.com  Mon Jul  1 10:33:01 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 1 Jul 2013 16:33:01 +0200
Subject: v3.10 - big endian core support
In-Reply-To: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130701163301.7c1228df@skate>

Dear Ben Dooks,

On Mon,  1 Jul 2013 12:03:58 +0100, Ben Dooks wrote:
> The latest big-endian changes, now on:
> 
> 	git://git.baserock.org/delta/linux baserock/311/be/core
> 
> This has a minor fix from the last version where a rebase missed a change
> in the smp_scu code.

Patches 1, 2, 3, 4 and 9:

Tested-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

on an Armada XP GP board. The other patches are not exercised by this
particular testing.

I'm interested in seeing this series merged.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From jonas.jensen at gmail.com  Mon Jul  1 10:34:01 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Mon,  1 Jul 2013 16:34:01 +0200
Subject: [PATCH v4] ARM: irqchip: add support for MOXA ART SoCs
In-Reply-To: <1372339773-4974-1-git-send-email-jonas.jensen@gmail.com>
References: <1372339773-4974-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1372689241-18758-1-git-send-email-jonas.jensen@gmail.com>

This patch adds an irqchip driver for the main interrupt controller found
on MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130619
    
    Changes since v3:
    
    1. pack global variables in struct
    2. make handle_irq function static
    3. call irq_linear_revmap instead of irq_find_mapping
    4. fix indentation
    5. add error handling after irq_domain_add_linear
    6. free the domain if irq_alloc_domain_generic_chips fails
    7. use node->full_name instead of __func__ in messages
    8. remove debug messages
    9. make messages more consistent

 drivers/irqchip/Makefile     |   1 +
 drivers/irqchip/irq-moxart.c | 118 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 119 insertions(+)
 create mode 100644 drivers/irqchip/irq-moxart.c

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index cda4cb5..956d129 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_RENESAS_INTC_IRQPIN)	+= irq-renesas-intc-irqpin.o
 obj-$(CONFIG_RENESAS_IRQC)		+= irq-renesas-irqc.o
 obj-$(CONFIG_VERSATILE_FPGA_IRQ)	+= irq-versatile-fpga.o
 obj-$(CONFIG_ARCH_VT8500)		+= irq-vt8500.o
+obj-$(CONFIG_ARCH_MOXART)		+= irq-moxart.o
diff --git a/drivers/irqchip/irq-moxart.c b/drivers/irqchip/irq-moxart.c
new file mode 100644
index 0000000..a84b001
--- /dev/null
+++ b/drivers/irqchip/irq-moxart.c
@@ -0,0 +1,118 @@
+/*
+ * MOXA ART SoCs IRQ chip driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/irqdomain.h>
+
+#include <asm/exception.h>
+
+#include "irqchip.h"
+
+#define IRQ_SOURCE_REG		0
+#define IRQ_MASK_REG		0x04
+#define IRQ_CLEAR_REG		0x08
+#define IRQ_MODE_REG		0x0c
+#define IRQ_LEVEL_REG		0x10
+#define IRQ_STATUS_REG		0x14
+
+#define FIQ_SOURCE_REG		0x20
+#define FIQ_MASK_REG		0x24
+#define FIQ_CLEAR_REG		0x28
+#define FIQ_MODE_REG		0x2c
+#define FIQ_LEVEL_REG		0x30
+#define FIQ_STATUS_REG		0x34
+
+
+struct moxart_irq_data {
+	void __iomem *base;
+	struct irq_domain *domain;
+	unsigned int interrupt_mask;
+};
+
+static struct moxart_irq_data intc;
+
+static asmlinkage void __exception_irq_entry handle_irq(struct pt_regs *regs)
+{
+	u32 irqstat;
+	int hwirq;
+
+	irqstat = readl(intc.base + IRQ_STATUS_REG);
+
+	while (irqstat) {
+		hwirq = ffs(irqstat) - 1;
+		handle_IRQ(irq_linear_revmap(intc.domain, hwirq), regs);
+		irqstat &= ~(1 << hwirq);
+	}
+}
+
+static int __init moxart_of_intc_init(struct device_node *node,
+				      struct device_node *parent)
+{
+	unsigned int clr = IRQ_NOREQUEST | IRQ_NOPROBE | IRQ_NOAUTOEN;
+	int ret;
+	struct irq_chip_generic *gc;
+
+	intc.base = of_iomap(node, 0);
+	if (!intc.base) {
+		pr_err("%s: unable to map IC registers\n",
+		       node->full_name);
+		return -EINVAL;
+	}
+
+	intc.domain = irq_domain_add_linear(node, 32, &irq_generic_chip_ops,
+					    intc.base);
+	if (!intc.domain) {
+		pr_err("%s: unable to create IRQ domain\n", node->full_name);
+		return -EINVAL;
+	}
+
+	ret = irq_alloc_domain_generic_chips(intc.domain, 32, 1,
+					     "MOXARTINTC", handle_edge_irq,
+					     clr, 0, IRQ_GC_INIT_MASK_CACHE);
+	if (ret) {
+		pr_err("%s: could not allocate generic chip\n",
+		       node->full_name);
+		irq_domain_remove(intc.domain);
+		return -EINVAL;
+	}
+
+	ret = of_property_read_u32(node, "interrupt-mask",
+				   &intc.interrupt_mask);
+	if (ret)
+		pr_err("%s: could not read interrupt-mask DT property\n",
+		       node->full_name);
+
+	gc = irq_get_domain_generic_chip(intc.domain, 0);
+
+	gc->reg_base = intc.base;
+	gc->chip_types[0].regs.mask = IRQ_MASK_REG;
+	gc->chip_types[0].regs.ack = IRQ_CLEAR_REG;
+	gc->chip_types[0].chip.irq_ack = irq_gc_ack_set_bit;
+	gc->chip_types[0].chip.irq_mask = irq_gc_mask_clr_bit;
+	gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit;
+
+	writel(0, intc.base + IRQ_MASK_REG);
+	writel(0xffffffff, intc.base + IRQ_CLEAR_REG);
+
+	writel(intc.interrupt_mask, intc.base + IRQ_MODE_REG);
+	writel(intc.interrupt_mask, intc.base + IRQ_LEVEL_REG);
+
+	set_handle_irq(handle_irq);
+
+	return 0;
+}
+IRQCHIP_DECLARE(moxa_moxart_ic, "moxa,moxart-interrupt-controller",
+		moxart_of_intc_init);
-- 
1.8.2.1



From shawn.guo at linaro.org  Mon Jul  1 10:34:19 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 22:34:19 +0800
Subject: [alsa-devel] [PATCH 1/4] ASoC: sgtl5000: give it a ramping time
 before writting
In-Reply-To: <20130701142610.GR13206@S2101-09.ap.freescale.net>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>
 <20130701100710.GB27646@sirena.org.uk>
 <201307011254.18952.marex@denx.de>
 <CAOMZO5BAs5-Tf_O0TVLFAuCchVuukV+bH2MpjqMU83tTw2GD=Q@mail.gmail.com>
 <20130701142610.GR13206@S2101-09.ap.freescale.net>
Message-ID: <20130701143415.GA14172@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 10:26:12PM +0800, Shawn Guo wrote:
> On Mon, Jul 01, 2013 at 11:12:48AM -0300, Fabio Estevam wrote:
> > On Mon, Jul 1, 2013 at 7:54 AM, Marek Vasut <marex at denx.de> wrote:
> > 
> > > The delay might also be caused by the I2C driver, I have this in my ToDo to
> > 
> > Yes, this extra delay could be related to the mxs i2c driver, as we do
> > not need to add this delay when using sgtl5000 on other i.mx devices.
> > 
> > Other people have also reported mxs i2c issues currently:
> > http://marc.info/?l=linux-i2c&m=137241339917261&w=2
> > 
> > ,so this may be related some how.
> 
> How does it explain the fact that sgtl5000 read has been working there?
> The sgtl5000 revision has been successfully read out at that point.

And also why we do not see the impact of i2c issue on sgtl5000 before
the offending commit af8ee11 (ASoC: sgtl5000: Fix driver probe after
reset)?

Shawn



From l.stach at pengutronix.de  Mon Jul  1 10:33:49 2013
From: l.stach at pengutronix.de (Lucas Stach)
Date: Mon, 01 Jul 2013 16:33:49 +0200
Subject: [PATCH] arm: allow all architectures to change max zone order
In-Reply-To: <1370019744-7588-1-git-send-email-l.stach@pengutronix.de>
References: <1370019744-7588-1-git-send-email-l.stach@pengutronix.de>
Message-ID: <1372689229.4277.4.camel@weser.hi.pengutronix.de>

Am Freitag, den 31.05.2013, 19:02 +0200 schrieb Lucas Stach:
> Many multimedia applications on architectures without an
> IOMMU need large physically contiguous buffers and so need
> to adjust the max zone order of the page allocator.
> 
> There is zero reason to not allow this adjustment on arches
> other than SHMOBILE.
> 
> Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
> ---
>  arch/arm/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 49d993c..6ceace8 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1710,7 +1710,7 @@ config HW_PERF_EVENTS
>  source "mm/Kconfig"
>  
>  config FORCE_MAX_ZONEORDER
> -	int "Maximum zone order" if ARCH_SHMOBILE
> +	int "Maximum zone order"
>  	range 11 64 if ARCH_SHMOBILE
>  	default "12" if SOC_AM33XX
>  	default "9" if SA1111

Ping. This is really straight forward and low risk.
-- 
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



From shawn.guo at linaro.org  Mon Jul  1 10:37:09 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 22:37:09 +0800
Subject: [v2 1/4] ARM: dtsi: enable ahci sata on imx6q platforms
In-Reply-To: <1372672975-2997-2-git-send-email-r65037@freescale.com>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-2-git-send-email-r65037@freescale.com>
Message-ID: <20130701143708.GS13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 06:02:52PM +0800, Richard Zhu wrote:
> Only imx6q has the ahci sata controller, enable
> it on imx6q platforms.
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  arch/arm/boot/dts/imx6q-sabreauto.dts |    4 ++++
>  arch/arm/boot/dts/imx6q-sabrelite.dts |    4 ++++
>  arch/arm/boot/dts/imx6q-sabresd.dts   |    4 ++++
>  arch/arm/boot/dts/imx6q.dtsi          |    9 +++++++++
>  4 files changed, 21 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6q-sabreauto.dts b/arch/arm/boot/dts/imx6q-sabreauto.dts
> index 09a7580..dd40f00 100644
> --- a/arch/arm/boot/dts/imx6q-sabreauto.dts
> +++ b/arch/arm/boot/dts/imx6q-sabreauto.dts
> @@ -20,6 +20,10 @@
>  	compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
>  };
>  
> +&ahci { /* AHCI SATA */

All these "AHCI SATA" comments are not so useful.  Please just drop
them.

Shawn

> +	status = "okay";
> +};
> +
>  &iomuxc {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_hog>;
> diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts b/arch/arm/boot/dts/imx6q-sabrelite.dts
> index 6a00066..fde2afd 100644
> --- a/arch/arm/boot/dts/imx6q-sabrelite.dts
> +++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
> @@ -65,6 +65,10 @@
>  	};
>  };
>  
> +&ahci { /* AHCI SATA */
> +	status = "okay";
> +};
> +
>  &ecspi1 {
>  	fsl,spi-num-chipselects = <1>;
>  	cs-gpios = <&gpio3 19 0>;
> diff --git a/arch/arm/boot/dts/imx6q-sabresd.dts b/arch/arm/boot/dts/imx6q-sabresd.dts
> index 0038228..e9b6825 100644
> --- a/arch/arm/boot/dts/imx6q-sabresd.dts
> +++ b/arch/arm/boot/dts/imx6q-sabresd.dts
> @@ -20,6 +20,10 @@
>  	compatible = "fsl,imx6q-sabresd", "fsl,imx6q";
>  };
>  
> +&ahci { /* AHCI SATA */
> +	status = "okay";
> +};
> +
>  &iomuxc {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_hog>;
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index e7dd2c4..7c1af2b 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -424,6 +424,15 @@
>  			};
>  		};
>  
> +		ahci: ahci at 02200000 { /* AHCI SATA */
> +			compatible = "snps,imx-ahci";
> +			reg = <0x02200000 0x4000>;
> +			interrupts = <0 39 0x04>;
> +			clocks = <&clks 154>, <&clks 187>;
> +			clock-names = "sata", "sata_ref_100m";
> +			status = "disabled";
> +		};
> +
>  		ipu2: ipu at 02800000 {
>  			#crtc-cells = <1>;
>  			compatible = "fsl,imx6q-ipu";
> -- 
> 1.7.5.4
> 



From r65037 at freescale.com  Mon Jul  1 10:48:03 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Mon, 1 Jul 2013 14:48:03 +0000
Subject: [v2 2/4] imx: ahci: enable ahci sata on imx6q platforms
In-Reply-To: <20130701125508.GX516@pengutronix.de>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-3-git-send-email-r65037@freescale.com>,
 <20130701125508.GX516@pengutronix.de>
Message-ID: <0E83723C55F66F43A6041464FE31119D30C2E5@039-SN2MPN1-013.039d.mgd.msft.net>

Hi Sascha;
Thanks for your comments.

Best Regards
Richard Zhu
________________________________________
From: Sascha Hauer [s.hauer at pengutronix.de]
Sent: Monday, July 01, 2013 8:55 PM
To: Richard Zhu
Cc: shawn.guo at linaro.org; linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; avorontsov at ru.mvista.com; rob.herring at calxeda.com; linux-ide at vger.kernel.org; Zhu Richard-R65037
Subject: Re: [v2 2/4] imx: ahci: enable ahci sata on imx6q platforms

On Mon, Jul 01, 2013 at 06:02:53PM +0800, Richard Zhu wrote:
> Only the imx6q contains the ahci sata controller,
> other imx6 SoCs don't have it.
>
> Enable the ahci sata only on imx6q platforms
>
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  arch/arm/mach-imx/mach-imx6q.c |   85 +++++++++++++++++++++++++++++++++++++++-
> +/* imx6q ahci module initialization. */
> +static int imx6q_sata_phy_clk(struct device *dev, int enable)
> +{
> +     int ret = 0;
> +     struct clk *sata_ref_clk;
> +
> +     sata_ref_clk = devm_clk_get(dev, "sata_ref_100m");
> +     if (IS_ERR(sata_ref_clk)) {
> +             dev_err(dev, "can't get sata_ref clock.\n");
> +             return PTR_ERR(sata_ref_clk);
> +     }

devm_clk_get takes a reference to the clock. That's not something you
want to do each time you enable/disable a clock.
[Richard] Accepted.

> +     if (enable) {
> +             /* Enable PHY clock */
> +             ret = clk_prepare_enable(sata_ref_clk);
> +             if (ret < 0) {
> +                     dev_err(dev, "can't prepare-enable sata_ref clock\n");
> +                     clk_put(sata_ref_clk);
> +                     ret = PTR_ERR(sata_ref_clk);

What are you intending by converting a valid pointer to an error code?
[Richard] Typo-mistake, would be corrected.

> +             }
> +     } else {
> +             /* Disable PHY clock */
> +             clk_disable_unprepare(sata_ref_clk);
> +     }
> +
> +     return ret;
> +}
> +
> +static int imx6q_sata_init(struct device *dev, void __iomem *addr)
> +{
> +     int ret = 0;
> +     struct regmap *gpr;
> +
> +     ret = imx6q_sata_phy_clk(dev, true);
> +     if (ret < 0)
> +             return ret;
> +
> +     gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +     if (IS_ERR(gpr)) {
> +             pr_err("failed to find fsl,imx6q-iomux-gpr regmap\n");
> +             return PTR_ERR(gpr);
> +     }
> +
> +     /*
> +      * set PHY Paremeters, two steps to configure the GPR13,
> +      * one write for rest of parameters, mask of first write
> +      * is 0x07fffffd, and the other one write for setting
> +      * the mpll_clk_en.
> +      */
> +     regmap_update_bits(gpr, 0x34, 0x07fffffd, 0x0593e4c4);

You are adding the register defines in the next patch. Wouldn't it make
sense to use them?
[Richard] Ok, would be replaced by the register's definitions.

Sascha

--
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |




From shawn.guo at linaro.org  Mon Jul  1 10:48:19 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 22:48:19 +0800
Subject: [v2 4/4] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <CAGxe1ZEHWQUXmjgmGGkpy3wgxoS8ti0-eYZPHkQKzjD9pWqZ0Q@mail.gmail.com>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-5-git-send-email-r65037@freescale.com>
 <CAGxe1ZEHWQUXmjgmGGkpy3wgxoS8ti0-eYZPHkQKzjD9pWqZ0Q@mail.gmail.com>
Message-ID: <20130701144817.GT13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 04:57:35PM +0530, Girish K S wrote:
> Hello Richard,
> 
> Instead of writing a separate driver for the changes you mentioned in
> the commit message. you can just add those changes to
> the platform data (pdata-> init).

No. The platform init hook is not used to do IP block related setup.
If we're mapping ahci block and setting up ahci registers in platform
code, we are generally not doing the right thing.

Shawn



From r65037 at freescale.com  Mon Jul  1 10:48:54 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Mon, 1 Jul 2013 14:48:54 +0000
Subject: [v2 1/4] ARM: dtsi: enable ahci sata on imx6q platforms
In-Reply-To: <20130701143708.GS13206@S2101-09.ap.freescale.net>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-2-git-send-email-r65037@freescale.com>,
 <20130701143708.GS13206@S2101-09.ap.freescale.net>
Message-ID: <0E83723C55F66F43A6041464FE31119D30C2FE@039-SN2MPN1-013.039d.mgd.msft.net>

Hi Shawn:
Thanks for your comments.

Best Regards
Richard Zhu
________________________________________
From: Shawn Guo [shawn.guo at linaro.org]
Sent: Monday, July 01, 2013 10:37 PM
To: Richard Zhu
Cc: linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; avorontsov at ru.mvista.com; rob.herring at calxeda.com; s.hauer at pengutronix.de; linux-ide at vger.kernel.org; Zhu Richard-R65037
Subject: Re: [v2 1/4] ARM: dtsi: enable ahci sata on imx6q platforms

On Mon, Jul 01, 2013 at 06:02:52PM +0800, Richard Zhu wrote:
> Only imx6q has the ahci sata controller, enable
> it on imx6q platforms.
>
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  arch/arm/boot/dts/imx6q-sabreauto.dts |    4 ++++
>  arch/arm/boot/dts/imx6q-sabrelite.dts |    4 ++++
>  arch/arm/boot/dts/imx6q-sabresd.dts   |    4 ++++
>  arch/arm/boot/dts/imx6q.dtsi          |    9 +++++++++
>  4 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6q-sabreauto.dts b/arch/arm/boot/dts/imx6q-sabreauto.dts
> index 09a7580..dd40f00 100644
> --- a/arch/arm/boot/dts/imx6q-sabreauto.dts
> +++ b/arch/arm/boot/dts/imx6q-sabreauto.dts
> @@ -20,6 +20,10 @@
>       compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
>  };
>
> +&ahci { /* AHCI SATA */

All these "AHCI SATA" comments are not so useful.  Please just drop
them.
[Richard] Ok, they would be removed in next version.

Shawn

> +     status = "okay";
> +};
> +
>  &iomuxc {
>       pinctrl-names = "default";
>       pinctrl-0 = <&pinctrl_hog>;
> diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts b/arch/arm/boot/dts/imx6q-sabrelite.dts
> index 6a00066..fde2afd 100644
> --- a/arch/arm/boot/dts/imx6q-sabrelite.dts
> +++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
> @@ -65,6 +65,10 @@
>       };
>  };
>
> +&ahci { /* AHCI SATA */
> +     status = "okay";
> +};
> +
>  &ecspi1 {
>       fsl,spi-num-chipselects = <1>;
>       cs-gpios = <&gpio3 19 0>;
> diff --git a/arch/arm/boot/dts/imx6q-sabresd.dts b/arch/arm/boot/dts/imx6q-sabresd.dts
> index 0038228..e9b6825 100644
> --- a/arch/arm/boot/dts/imx6q-sabresd.dts
> +++ b/arch/arm/boot/dts/imx6q-sabresd.dts
> @@ -20,6 +20,10 @@
>       compatible = "fsl,imx6q-sabresd", "fsl,imx6q";
>  };
>
> +&ahci { /* AHCI SATA */
> +     status = "okay";
> +};
> +
>  &iomuxc {
>       pinctrl-names = "default";
>       pinctrl-0 = <&pinctrl_hog>;
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index e7dd2c4..7c1af2b 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -424,6 +424,15 @@
>                       };
>               };
>
> +             ahci: ahci at 02200000 { /* AHCI SATA */
> +                     compatible = "snps,imx-ahci";
> +                     reg = <0x02200000 0x4000>;
> +                     interrupts = <0 39 0x04>;
> +                     clocks = <&clks 154>, <&clks 187>;
> +                     clock-names = "sata", "sata_ref_100m";
> +                     status = "disabled";
> +             };
> +
>               ipu2: ipu at 02800000 {
>                       #crtc-cells = <1>;
>                       compatible = "fsl,imx6q-ipu";
> --
> 1.7.5.4
>



From shawn.guo at linaro.org  Mon Jul  1 10:53:58 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 22:53:58 +0800
Subject: [v2 2/4] imx: ahci: enable ahci sata on imx6q platforms
In-Reply-To: <1372672975-2997-3-git-send-email-r65037@freescale.com>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-3-git-send-email-r65037@freescale.com>
Message-ID: <20130701145356.GU13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 06:02:53PM +0800, Richard Zhu wrote:
> Only the imx6q contains the ahci sata controller,
> other imx6 SoCs don't have it.
> 
> Enable the ahci sata only on imx6q platforms
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  arch/arm/mach-imx/mach-imx6q.c |   85 +++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 84 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> index 045e5e3..ab81fa3 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -30,6 +30,7 @@
>  #include <linux/regmap.h>
>  #include <linux/micrel_phy.h>
>  #include <linux/mfd/syscon.h>
> +#include <linux/ahci_platform.h>
>  #include <asm/hardware/cache-l2x0.h>
>  #include <asm/mach/arch.h>
>  #include <asm/mach/map.h>
> @@ -39,6 +40,8 @@
>  #include "cpuidle.h"
>  #include "hardware.h"
>  
> +#define MX6Q_SATA_BASE_ADDR	0x02200000
> +
>  static u32 chip_revision;
>  
>  int imx6q_revision(void)
> @@ -162,12 +165,92 @@ static void __init imx6q_usb_init(void)
>  	imx_anatop_usb_chrg_detect_disable();
>  }
>  
> +/* imx6q ahci module initialization. */
> +static int imx6q_sata_phy_clk(struct device *dev, int enable)
> +{
> +	int ret = 0;
> +	struct clk *sata_ref_clk;
> +
> +	sata_ref_clk = devm_clk_get(dev, "sata_ref_100m");
> +	if (IS_ERR(sata_ref_clk)) {
> +		dev_err(dev, "can't get sata_ref clock.\n");
> +		return PTR_ERR(sata_ref_clk);
> +	}
> +	if (enable) {
> +		/* Enable PHY clock */
> +		ret = clk_prepare_enable(sata_ref_clk);
> +		if (ret < 0) {
> +			dev_err(dev, "can't prepare-enable sata_ref clock\n");
> +			clk_put(sata_ref_clk);
> +			ret = PTR_ERR(sata_ref_clk);
> +		}
> +	} else {
> +		/* Disable PHY clock */
> +		clk_disable_unprepare(sata_ref_clk);
> +	}
> +
> +	return ret;
> +}
> +
> +static int imx6q_sata_init(struct device *dev, void __iomem *addr)
> +{
> +	int ret = 0;
> +	struct regmap *gpr;
> +
> +	ret = imx6q_sata_phy_clk(dev, true);
> +	if (ret < 0)
> +		return ret;
> +
> +	gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +	if (IS_ERR(gpr)) {
> +		pr_err("failed to find fsl,imx6q-iomux-gpr regmap\n");
> +		return PTR_ERR(gpr);
> +	}
> +
> +	/*
> +	 * set PHY Paremeters, two steps to configure the GPR13,
> +	 * one write for rest of parameters, mask of first write
> +	 * is 0x07fffffd, and the other one write for setting
> +	 * the mpll_clk_en.
> +	 */
> +	regmap_update_bits(gpr, 0x34, 0x07fffffd, 0x0593e4c4);
> +	regmap_update_bits(gpr, 0x34, 0x2, 0x2);
> +	usleep_range(100, 200);
> +
> +	return 0;
> +}
> +
> +static void imx6q_sata_exit(struct device *dev)
> +{
> +	struct regmap *gpr;
> +
> +	gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +	if (IS_ERR(gpr))
> +		pr_err("failed to find fsl,imx6q-iomux-gpr regmap\n");
> +
> +	regmap_update_bits(gpr, 0x34, 0x2, 0x0);
> +
> +	imx6q_sata_phy_clk(dev, false);
> +}
> +
> +static struct ahci_platform_data imx6q_sata_pdata = {
> +	.init = imx6q_sata_init,
> +	.exit = imx6q_sata_exit,
> +};
> +
> +static const struct of_dev_auxdata imx6q_auxdata_lookup[] __initconst = {
> +	OF_DEV_AUXDATA("snps,imx-ahci", MX6Q_SATA_BASE_ADDR, "imx-ahci",
> +			&imx6q_sata_pdata),
> +	{ /* sentinel */ }
> +};
> +

This is wrong.  The whole point of having an imx specific ahci platform
driver is to have all these setup done in that driver instead of
platform code.  Using auxdata is generally a sign of
not-doing-the-right-thing on a recent platform with a new created
driver.

Shawn

>  static void __init imx6q_init_machine(void)
>  {
>  	if (of_machine_is_compatible("fsl,imx6q-sabrelite"))
>  		imx6q_sabrelite_init();
>  
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +	of_platform_populate(NULL, of_default_bus_match_table,
> +			imx6q_auxdata_lookup, NULL);
>  
>  	imx_anatop_init();
>  	imx6q_pm_init();
> -- 
> 1.7.5.4
> 



From sebastian.hesselbarth at gmail.com  Mon Jul  1 10:56:12 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon,  1 Jul 2013 16:56:12 +0200
Subject: [PATCH] ARM: dove: fix missing __init section of dove_mpp_gpio_mode
Message-ID: <1372690572-2184-1-git-send-email-sebastian.hesselbarth@gmail.com>

Legacy dove_mpp_gpio_mode calls orion_gpio_set_valid which is in
__init section. Offending function is not, so this causes a section
mismatch. To fix the mismatch, also move dove_mpp_gpio_mode to
__init section.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/mach-dove/mpp.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-dove/mpp.c b/arch/arm/mach-dove/mpp.c
index 60bd729..8a433a5 100644
--- a/arch/arm/mach-dove/mpp.c
+++ b/arch/arm/mach-dove/mpp.c
@@ -47,7 +47,7 @@ static const struct dove_mpp_grp dove_mpp_grp[] = {
 
 /* Enable gpio for a range of pins. mode should be a combination of
    GPIO_OUTPUT_OK | GPIO_INPUT_OK */
-static void dove_mpp_gpio_mode(int start, int end, int gpio_mode)
+static void __init dove_mpp_gpio_mode(int start, int end, int gpio_mode)
 {
 	int i;
 
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Mon Jul  1 10:56:29 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon,  1 Jul 2013 16:56:29 +0200
Subject: [PATCH] DMA: Fix Marvell Orion and mv_xor after MEMSET removal
Message-ID: <1372690589-2218-1-git-send-email-sebastian.hesselbarth@gmail.com>

Commit 834cbfe966bece50afded79da8e975d255bf0772
 ("drivers/dma: remove unused support for MEMSET operations")
removes MEMSET from dmaengine but does not completely removes it from
Marvell Orion (arch/arm/plat-orion) and XOR (drivers/dma/mv_xor).
This also fixes some compiler warnings about now obsolete functions by
removing those.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
Cc: Kyungmin Park <kyungmin.park at samsung.com>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/plat-orion/common.c |    6 ------
 drivers/dma/mv_xor.c         |   25 +------------------------
 2 files changed, 1 insertions(+), 30 deletions(-)

diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index 797f284..dd2cbd3 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -727,14 +727,8 @@ void __init orion_xor1_init(unsigned long mapbase_low,
 	orion_xor1_shared_resources[3].start = irq_1;
 	orion_xor1_shared_resources[3].end = irq_1;
 
-	/*
-	 * two engines can't do memset simultaneously, this limitation
-	 * satisfied by removing memset support from one of the engines.
-	 */
 	dma_cap_set(DMA_MEMCPY, orion_xor1_channels_data[0].cap_mask);
 	dma_cap_set(DMA_XOR, orion_xor1_channels_data[0].cap_mask);
-
-	dma_cap_set(DMA_MEMSET, orion_xor1_channels_data[1].cap_mask);
 	dma_cap_set(DMA_MEMCPY, orion_xor1_channels_data[1].cap_mask);
 	dma_cap_set(DMA_XOR, orion_xor1_channels_data[1].cap_mask);
 
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index c434fe6..200f1a3 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -89,11 +89,6 @@ static void mv_desc_clear_next_desc(struct mv_xor_desc_slot *desc)
 	hw_desc->phy_next_desc = 0;
 }
 
-static void mv_desc_set_block_fill_val(struct mv_xor_desc_slot *desc, u32 val)
-{
-	desc->value = val;
-}
-
 static void mv_desc_set_dest_addr(struct mv_xor_desc_slot *desc,
 				  dma_addr_t addr)
 {
@@ -128,22 +123,6 @@ static void mv_chan_set_next_descriptor(struct mv_xor_chan *chan,
 	__raw_writel(next_desc_addr, XOR_NEXT_DESC(chan));
 }
 
-static void mv_chan_set_dest_pointer(struct mv_xor_chan *chan, u32 desc_addr)
-{
-	__raw_writel(desc_addr, XOR_DEST_POINTER(chan));
-}
-
-static void mv_chan_set_block_size(struct mv_xor_chan *chan, u32 block_size)
-{
-	__raw_writel(block_size, XOR_BLOCK_SIZE(chan));
-}
-
-static void mv_chan_set_value(struct mv_xor_chan *chan, u32 value)
-{
-	__raw_writel(value, XOR_INIT_VALUE_LOW(chan));
-	__raw_writel(value, XOR_INIT_VALUE_HIGH(chan));
-}
-
 static void mv_chan_unmask_interrupts(struct mv_xor_chan *chan)
 {
 	u32 val = __raw_readl(XOR_INTR_MASK(chan));
@@ -1134,7 +1113,7 @@ mv_xor_channel_add(struct mv_xor_device *xordev,
 			goto err_free_irq;
 	}
 
-	dev_info(&pdev->dev, "Marvell XOR: ( %s%s%s%s)\n",
+	dev_info(&pdev->dev, "Marvell XOR: ( %s%s%s)\n",
 		 dma_has_cap(DMA_XOR, dma_dev->cap_mask) ? "xor " : "",
 		 dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask) ? "cpy " : "",
 		 dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask) ? "intr " : "");
@@ -1244,8 +1223,6 @@ static int mv_xor_probe(struct platform_device *pdev)
 				dma_cap_set(DMA_MEMCPY, cap_mask);
 			if (of_property_read_bool(np, "dmacap,xor"))
 				dma_cap_set(DMA_XOR, cap_mask);
-			if (of_property_read_bool(np, "dmacap,memset"))
-				dma_cap_set(DMA_MEMSET, cap_mask);
 			if (of_property_read_bool(np, "dmacap,interrupt"))
 				dma_cap_set(DMA_INTERRUPT, cap_mask);
 
-- 
1.7.2.5



From r65037 at freescale.com  Mon Jul  1 10:58:52 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Mon, 1 Jul 2013 14:58:52 +0000
Subject: [v2 4/4] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <20130701133611.GB11408@mtj.dyndns.org>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-5-git-send-email-r65037@freescale.com>,
 <20130701133611.GB11408@mtj.dyndns.org>
Message-ID: <0E83723C55F66F43A6041464FE31119D30C323@039-SN2MPN1-013.039d.mgd.msft.net>

Hi Tejun, Girish and all:
Yes, I understand what you said.
In the first version, based on the ahci_platform driver, I used to put the imx ahci differrence into
 the platform level, and re-use ahci_platform driver.

Shawn has some concerns about that, just like he said.
So I re-orgnized imx ahci driver, and re-send it in the version2 around.

Let's have the discussions here, and figure out a most proper method to do the right thing.
Any comments and suggetsions are apppreciated.
thanks again.

Best Regards
Richard Zhu
________________________________________
From: Tejun Heo [htejun at gmail.com] on behalf of Tejun Heo [tj at kernel.org]
Sent: Monday, July 01, 2013 9:36 PM
To: Richard Zhu
Cc: shawn.guo at linaro.org; linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; avorontsov at ru.mvista.com; rob.herring at calxeda.com; s.hauer at pengutronix.de; linux-ide at vger.kernel.org; Zhu Richard-R65037
Subject: Re: [v2 4/4] sata: imx: add ahci sata support on imx platforms

On Mon, Jul 01, 2013 at 06:02:55PM +0800, Richard Zhu wrote:
> imx6q contains one Synopsys AHCI SATA controller,
> But it can't shares ahci_platform driver with other
> controllers.
> Because there are some misalignments of the bits
> definitions of the HBA registers and the Vendor
> Specific registers
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>  value is '0', should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the
>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>  should be configured regarding to the frequency of AHB
>  bus clock.

If these are the only differences, can't you make ahci_platform deal
with different variants?  That's how we deal with subtly different
variants of about the same controllers.

Thanks.

--
tejun




From jason at lakedaemon.net  Mon Jul  1 11:04:07 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 1 Jul 2013 11:04:07 -0400
Subject: [PATCH] DMA: Fix Marvell Orion and mv_xor after MEMSET removal
In-Reply-To: <1372690589-2218-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372690589-2218-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130701150407.GB19937@titan.lakedaemon.net>

On Mon, Jul 01, 2013 at 04:56:29PM +0200, Sebastian Hesselbarth wrote:
> Commit 834cbfe966bece50afded79da8e975d255bf0772
>  ("drivers/dma: remove unused support for MEMSET operations")
> removes MEMSET from dmaengine but does not completely removes it from
> Marvell Orion (arch/arm/plat-orion) and XOR (drivers/dma/mv_xor).
> This also fixes some compiler warnings about now obsolete functions by
> removing those.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
> Cc: Kyungmin Park <kyungmin.park at samsung.com>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  arch/arm/plat-orion/common.c |    6 ------
>  drivers/dma/mv_xor.c         |   25 +------------------------
>  2 files changed, 1 insertions(+), 30 deletions(-)

Please take a look at the email from lkml I just forwarded to you.  I
believe this solves your problem, but I don't have time to look closely
atm.

thx,

Jason.

> 
> diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
> index 797f284..dd2cbd3 100644
> --- a/arch/arm/plat-orion/common.c
> +++ b/arch/arm/plat-orion/common.c
> @@ -727,14 +727,8 @@ void __init orion_xor1_init(unsigned long mapbase_low,
>  	orion_xor1_shared_resources[3].start = irq_1;
>  	orion_xor1_shared_resources[3].end = irq_1;
>  
> -	/*
> -	 * two engines can't do memset simultaneously, this limitation
> -	 * satisfied by removing memset support from one of the engines.
> -	 */
>  	dma_cap_set(DMA_MEMCPY, orion_xor1_channels_data[0].cap_mask);
>  	dma_cap_set(DMA_XOR, orion_xor1_channels_data[0].cap_mask);
> -
> -	dma_cap_set(DMA_MEMSET, orion_xor1_channels_data[1].cap_mask);
>  	dma_cap_set(DMA_MEMCPY, orion_xor1_channels_data[1].cap_mask);
>  	dma_cap_set(DMA_XOR, orion_xor1_channels_data[1].cap_mask);
>  
> diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
> index c434fe6..200f1a3 100644
> --- a/drivers/dma/mv_xor.c
> +++ b/drivers/dma/mv_xor.c
> @@ -89,11 +89,6 @@ static void mv_desc_clear_next_desc(struct mv_xor_desc_slot *desc)
>  	hw_desc->phy_next_desc = 0;
>  }
>  
> -static void mv_desc_set_block_fill_val(struct mv_xor_desc_slot *desc, u32 val)
> -{
> -	desc->value = val;
> -}
> -
>  static void mv_desc_set_dest_addr(struct mv_xor_desc_slot *desc,
>  				  dma_addr_t addr)
>  {
> @@ -128,22 +123,6 @@ static void mv_chan_set_next_descriptor(struct mv_xor_chan *chan,
>  	__raw_writel(next_desc_addr, XOR_NEXT_DESC(chan));
>  }
>  
> -static void mv_chan_set_dest_pointer(struct mv_xor_chan *chan, u32 desc_addr)
> -{
> -	__raw_writel(desc_addr, XOR_DEST_POINTER(chan));
> -}
> -
> -static void mv_chan_set_block_size(struct mv_xor_chan *chan, u32 block_size)
> -{
> -	__raw_writel(block_size, XOR_BLOCK_SIZE(chan));
> -}
> -
> -static void mv_chan_set_value(struct mv_xor_chan *chan, u32 value)
> -{
> -	__raw_writel(value, XOR_INIT_VALUE_LOW(chan));
> -	__raw_writel(value, XOR_INIT_VALUE_HIGH(chan));
> -}
> -
>  static void mv_chan_unmask_interrupts(struct mv_xor_chan *chan)
>  {
>  	u32 val = __raw_readl(XOR_INTR_MASK(chan));
> @@ -1134,7 +1113,7 @@ mv_xor_channel_add(struct mv_xor_device *xordev,
>  			goto err_free_irq;
>  	}
>  
> -	dev_info(&pdev->dev, "Marvell XOR: ( %s%s%s%s)\n",
> +	dev_info(&pdev->dev, "Marvell XOR: ( %s%s%s)\n",
>  		 dma_has_cap(DMA_XOR, dma_dev->cap_mask) ? "xor " : "",
>  		 dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask) ? "cpy " : "",
>  		 dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask) ? "intr " : "");
> @@ -1244,8 +1223,6 @@ static int mv_xor_probe(struct platform_device *pdev)
>  				dma_cap_set(DMA_MEMCPY, cap_mask);
>  			if (of_property_read_bool(np, "dmacap,xor"))
>  				dma_cap_set(DMA_XOR, cap_mask);
> -			if (of_property_read_bool(np, "dmacap,memset"))
> -				dma_cap_set(DMA_MEMSET, cap_mask);
>  			if (of_property_read_bool(np, "dmacap,interrupt"))
>  				dma_cap_set(DMA_INTERRUPT, cap_mask);
>  
> -- 
> 1.7.2.5
> 


From girish.shivananjappa at linaro.org  Mon Jul  1 11:04:38 2013
From: girish.shivananjappa at linaro.org (Girish K S)
Date: Mon, 1 Jul 2013 20:34:38 +0530
Subject: [v2 4/4] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <20130701144817.GT13206@S2101-09.ap.freescale.net>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-5-git-send-email-r65037@freescale.com>
 <CAGxe1ZEHWQUXmjgmGGkpy3wgxoS8ti0-eYZPHkQKzjD9pWqZ0Q@mail.gmail.com>
 <20130701144817.GT13206@S2101-09.ap.freescale.net>
Message-ID: <CAGxe1ZEhTumWC5mpirjSqg2fogFz5VuLKLtxUpA=ctxdwU-i6w@mail.gmail.com>

On 1 July 2013 20:18, Shawn Guo <shawn.guo at linaro.org> wrote:
> On Mon, Jul 01, 2013 at 04:57:35PM +0530, Girish K S wrote:
>> Hello Richard,
>>
>> Instead of writing a separate driver for the changes you mentioned in
>> the commit message. you can just add those changes to
>> the platform data (pdata-> init).
>
> No. The platform init hook is not used to do IP block related setup.
> If we're mapping ahci block and setting up ahci registers in platform
> code, we are generally not doing the right thing.

Yes I understand (anything specific to driver should be part of
driver). I need to touch few platforms that are already doing this.
Then how about keeping setup as part of driver data for the specific controller.


>
> Shawn
>


From festevam at gmail.com  Mon Jul  1 11:11:58 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 1 Jul 2013 12:11:58 -0300
Subject: [alsa-devel] [PATCH 1/4] ASoC: sgtl5000: give it a ramping time
 before writting
In-Reply-To: <20130701143415.GA14172@S2101-09.ap.freescale.net>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>
 <20130701100710.GB27646@sirena.org.uk>
 <201307011254.18952.marex@denx.de>
 <CAOMZO5BAs5-Tf_O0TVLFAuCchVuukV+bH2MpjqMU83tTw2GD=Q@mail.gmail.com>
 <20130701142610.GR13206@S2101-09.ap.freescale.net>
 <20130701143415.GA14172@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5Bh5CZLBO-epVA9Vivo-mqmBJZhy7iA6HiMy+xLzDj40w@mail.gmail.com>

On Mon, Jul 1, 2013 at 11:34 AM, Shawn Guo <shawn.guo at linaro.org> wrote:

> And also why we do not see the impact of i2c issue on sgtl5000 before
> the offending commit af8ee11 (ASoC: sgtl5000: Fix driver probe after
> reset)?

Probably because the mxs i2c was working before this commit.

Commit af8ee11 does fix the reset probe on mx51/mx53/mx6.

It's only on mx28 that we have this issue.

Also, please see this patch from Alexandre Belloni:
https://lkml.org/lkml/2013/6/24/430

He can only connect the ADC chip if he uses I2C bitbang mode on mx28.


From sebastian.hesselbarth at gmail.com  Mon Jul  1 11:14:25 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 01 Jul 2013 17:14:25 +0200
Subject: [PATCH] DMA: Fix Marvell Orion and mv_xor after MEMSET removal
In-Reply-To: <20130701150407.GB19937@titan.lakedaemon.net>
References: <1372690589-2218-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130701150407.GB19937@titan.lakedaemon.net>
Message-ID: <51D19CD1.3030900@gmail.com>

On 07/01/13 17:04, Jason Cooper wrote:
> On Mon, Jul 01, 2013 at 04:56:29PM +0200, Sebastian Hesselbarth wrote:
>> Commit 834cbfe966bece50afded79da8e975d255bf0772
>>   ("drivers/dma: remove unused support for MEMSET operations")
>> removes MEMSET from dmaengine but does not completely removes it from
>> Marvell Orion (arch/arm/plat-orion) and XOR (drivers/dma/mv_xor).
>> This also fixes some compiler warnings about now obsolete functions by
>> removing those.
>>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
>> ---
>> Cc: Jason Cooper <jason at lakedaemon.net>
>> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
>> Cc: Kyungmin Park <kyungmin.park at samsung.com>
>> Cc: Andrew Morton <akpm at linux-foundation.org>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> ---
>>   arch/arm/plat-orion/common.c |    6 ------
>>   drivers/dma/mv_xor.c         |   25 +------------------------
>>   2 files changed, 1 insertions(+), 30 deletions(-)
>
> Please take a look at the email from lkml I just forwarded to you.  I
> believe this solves your problem, but I don't have time to look closely
> atm.

Jason,

I have seen the forwarded patch before. I don't know what version this
is based on. Some of the modifications are in next-20130701, some are
not. I have stripped the Marvell modifications from the patch you
forwarded and fixed all remaining issues.

Also, I will sent a follow-up patch to remove memset references from
Marvell SoC dts/dtsi and the binding documentation soon.

I guess, Bartolomiej should pick them up and resend his patch set, or
leave Marvell alone and you pick them up.

Sebastian



From jason at lakedaemon.net  Mon Jul  1 11:17:20 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 1 Jul 2013 11:17:20 -0400
Subject: [PATCH] DMA: Fix Marvell Orion and mv_xor after MEMSET removal
In-Reply-To: <51D19CD1.3030900@gmail.com>
References: <1372690589-2218-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130701150407.GB19937@titan.lakedaemon.net>
 <51D19CD1.3030900@gmail.com>
Message-ID: <20130701151720.GC19937@titan.lakedaemon.net>

On Mon, Jul 01, 2013 at 05:14:25PM +0200, Sebastian Hesselbarth wrote:
> On 07/01/13 17:04, Jason Cooper wrote:
> >On Mon, Jul 01, 2013 at 04:56:29PM +0200, Sebastian Hesselbarth wrote:
> >>Commit 834cbfe966bece50afded79da8e975d255bf0772
> >>  ("drivers/dma: remove unused support for MEMSET operations")
> >>removes MEMSET from dmaengine but does not completely removes it from
> >>Marvell Orion (arch/arm/plat-orion) and XOR (drivers/dma/mv_xor).
> >>This also fixes some compiler warnings about now obsolete functions by
> >>removing those.
> >>
> >>Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> >>---
> >>Cc: Jason Cooper <jason at lakedaemon.net>
> >>Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
> >>Cc: Kyungmin Park <kyungmin.park at samsung.com>
> >>Cc: Andrew Morton <akpm at linux-foundation.org>
> >>Cc: linux-arm-kernel at lists.infradead.org
> >>Cc: linux-kernel at vger.kernel.org
> >>---
> >>  arch/arm/plat-orion/common.c |    6 ------
> >>  drivers/dma/mv_xor.c         |   25 +------------------------
> >>  2 files changed, 1 insertions(+), 30 deletions(-)
> >
> >Please take a look at the email from lkml I just forwarded to you.  I
> >believe this solves your problem, but I don't have time to look closely
> >atm.
> 
> Jason,
> 
> I have seen the forwarded patch before. I don't know what version this
> is based on. Some of the modifications are in next-20130701, some are
> not. I have stripped the Marvell modifications from the patch you
> forwarded and fixed all remaining issues.
> 
> Also, I will sent a follow-up patch to remove memset references from
> Marvell SoC dts/dtsi and the binding documentation soon.
> 
> I guess, Bartolomiej should pick them up and resend his patch set, or
> leave Marvell alone and you pick them up.

If Bartolomiej doesn't take it, please split your changes into two
patches, one for plat-orion, and one for drivers.

thx,

Jason.


From shawn.guo at linaro.org  Mon Jul  1 11:17:40 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 23:17:40 +0800
Subject: [v2 4/4] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <CAGxe1ZEhTumWC5mpirjSqg2fogFz5VuLKLtxUpA=ctxdwU-i6w@mail.gmail.com>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-5-git-send-email-r65037@freescale.com>
 <CAGxe1ZEHWQUXmjgmGGkpy3wgxoS8ti0-eYZPHkQKzjD9pWqZ0Q@mail.gmail.com>
 <20130701144817.GT13206@S2101-09.ap.freescale.net>
 <CAGxe1ZEhTumWC5mpirjSqg2fogFz5VuLKLtxUpA=ctxdwU-i6w@mail.gmail.com>
Message-ID: <20130701151737.GB14172@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 08:34:38PM +0530, Girish K S wrote:
> On 1 July 2013 20:18, Shawn Guo <shawn.guo at linaro.org> wrote:
> > On Mon, Jul 01, 2013 at 04:57:35PM +0530, Girish K S wrote:
> >> Hello Richard,
> >>
> >> Instead of writing a separate driver for the changes you mentioned in
> >> the commit message. you can just add those changes to
> >> the platform data (pdata-> init).
> >
> > No. The platform init hook is not used to do IP block related setup.
> > If we're mapping ahci block and setting up ahci registers in platform
> > code, we are generally not doing the right thing.
> 
> Yes I understand (anything specific to driver should be part of
> driver). I need to touch few platforms that are already doing this.
> Then how about keeping setup as part of driver data for the specific controller.

I was too rush in writing the reply.  Here is what I meant.

We should reuse the generic ahci_platform driver. And that means we
have to use pdata->init() hook to do vendor specific setup.  But the
hook shouldn't be implemented in arch code (e.g.
arch/arm/mach-imx/mach-imx6q.c), and it should be implemented in
a vendor specific driver like sata_imx.c.  IOW, we reuse everything
implemented in the generic ahci_platform driver, and handle differences
in vendor specific ahci driver via pdata->init() hook.

Does that make the most sense?

Shawn 



From ben.dooks at codethink.co.uk  Mon Jul  1 11:20:47 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 01 Jul 2013 16:20:47 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <20130701163301.7c1228df@skate>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <20130701163301.7c1228df@skate>
Message-ID: <51D19E4F.1060806@codethink.co.uk>

On 01/07/13 15:33, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Mon,  1 Jul 2013 12:03:58 +0100, Ben Dooks wrote:
>> The latest big-endian changes, now on:
>>
>> 	git://git.baserock.org/delta/linux baserock/311/be/core
>>
>> This has a minor fix from the last version where a rebase missed a change
>> in the smp_scu code.
>
> Patches 1, 2, 3, 4 and 9:
>
> Tested-by: Thomas Petazzoni<thomas.petazzoni at free-electrons.com>

Thanks.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From shawn.guo at linaro.org  Mon Jul  1 11:21:37 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 23:21:37 +0800
Subject: [v2 4/4] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <20130701133611.GB11408@mtj.dyndns.org>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-5-git-send-email-r65037@freescale.com>
 <20130701133611.GB11408@mtj.dyndns.org>
Message-ID: <20130701152135.GV13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 06:36:11AM -0700, Tejun Heo wrote:
> On Mon, Jul 01, 2013 at 06:02:55PM +0800, Richard Zhu wrote:
> > imx6q contains one Synopsys AHCI SATA controller,
> > But it can't shares ahci_platform driver with other
> > controllers.
> > Because there are some misalignments of the bits
> > definitions of the HBA registers and the Vendor
> > Specific registers
> >  - CAP_SSS(bit20) of the HOST_CAP is writable, default
> >  value is '0', should be configured to be '1'
> >  - bit0 (only one AHCI SATA port on imx6q) of the
> >  HOST_PORTS_IMPL should be set to be '1'.(default 0)
> >  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
> >  should be configured regarding to the frequency of AHB
> >  bus clock.
> 
> If these are the only differences, can't you make ahci_platform deal
> with different variants?  That's how we deal with subtly different
> variants of about the same controllers.

There are more:

 - There is an additional phy clock to manage
 - There are some i.MX SoC integration level registers to set up

I prefer to that we reuse the generic ahci_platform stuff, and handle
the differences in a sata_imx.c via pdata->init() interface.

Shawn



From s.nawrocki at samsung.com  Mon Jul  1 11:22:22 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 17:22:22 +0200
Subject: [PATCH v3 00/13] ARM: dts: Add camera and magnetometer support for
 TRATS(2) board
Message-ID: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>

This patch series includes some fixes and extensions to the Exynos dts
files to add the camera and magnetometer sensor support for the TRATS
and TRATS2 board. It depends on a patch from Tomasz adding initial
TRATS2 board dts file [1].

Comparing to the previous version of this patch set I've added a few
more patches, for the Exynos4210 based TRATS board and a patch adding
MIPI CSIS/DSIM PHY provider nodes and related properties to the PHY
consumer nodes.

This series has been tested with the S5K6A3/FIMC-IS and S5K5BAFX
(front facing) cameras on top of next-20130627 tag. It can be found
also at:
http://git.linuxtv.org/snawrocki/samsung.git/next-20130627-dts-trats-v3

Detailed changes since v2 are listed in each patch.

Changes since v1:
 - enabled pull down in cam-port-{a, b}-clk-idle nodes (1/8)
 - added node alias for i2c-gpio at 0 I2C controller node (7/8).

[1] http://www.spinics.net/lists/arm-kernel/msg253184.html

Andrzej Hajda (2):
  ARM: dts: Add Exynos4210 SoC camera port pinctrl nodes
  ARM: dts: Add S5K5BA sensor regulator definitions for Trats board

Jacek Anaszewski (1):
  ARM: dts: Add AK8975 device node for Exynos4412 TRATS2 board

Sylwester Nawrocki (10):
  ARM: dts: Correct camera pinctrl nodes for Exynos4x12 SoCs
  ARM: dts: Add pinctrl entries for Exynos4x12 FIMC-IS peripherals
  ARM: dts: Add ISP power domain node for Exynos4x12
  ARM: dts: Use generic DMA bindings for Exynos4 SPI devices
  ARM: dts: Add camera subsystem device nodes to exynos4.dtsi
  ARM: dts: Add camera subsystem nodes to exynos4x12.dtsi
  ARM: dts: Add camera device nodes for Exynos4412 TRATS2 board
  ARM: dts: Add camera device nodes for Exynos4210 SoCs
  ARM: dts: Add FIMC nodes for Exynos4210 Trats board
  ARM: dts: Add MIPI PHY node to exynos4.dtsi

 arch/arm/boot/dts/exynos4.dtsi            |  102 ++++++++++++++++++++++++--
 arch/arm/boot/dts/exynos4210-pinctrl.dtsi |   23 ++++++
 arch/arm/boot/dts/exynos4210-trats.dts    |  103 ++++++++++++++++++++++-----
 arch/arm/boot/dts/exynos4210.dtsi         |   30 ++++++++
 arch/arm/boot/dts/exynos4412-trats2.dts   |  110 +++++++++++++++++++++++++++++
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |   61 ++++++++++++++--
 arch/arm/boot/dts/exynos4x12.dtsi         |  103 +++++++++++++++++++++++++++
 7 files changed, 503 insertions(+), 29 deletions(-)

--
1.7.9.5



From s.nawrocki at samsung.com  Mon Jul  1 11:22:23 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 17:22:23 +0200
Subject: [PATCH v3 01/13] ARM: dts: Correct camera pinctrl nodes for Exynos4x12
 SoCs
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1372692155-17653-2-git-send-email-s.nawrocki@samsung.com>

Add separate nodes for the CAMCLK pin and turn off pull-up on camera
ports A, B. The video bus pins and the clock output (CAMCLK) pin need
separate nodes since full camera port is not used in some configurations,
e.g. for MIPI CSI-2 bus only CAMCLK is required and data/clock signal
use separate dedicated pins.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |   40 ++++++++++++++++++++++++-----
 1 file changed, 33 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index 704290f..55ff73b 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -401,13 +401,26 @@
 			samsung,pin-drv = <0>;
 		};
 
-		cam_port_a: cam-port-a {
+		cam_port_a_io: cam-port-a-io {
 			samsung,pins = "gpj0-0", "gpj0-1", "gpj0-2", "gpj0-3",
 					"gpj0-4", "gpj0-5", "gpj0-6", "gpj0-7",
-					"gpj1-0", "gpj1-1", "gpj1-2", "gpj1-3",
-					"gpj1-4";
+					"gpj1-0", "gpj1-1", "gpj1-2", "gpj1-4";
 			samsung,pin-function = <2>;
-			samsung,pin-pud = <3>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <0>;
+		};
+
+		cam_port_a_clk_active: cam-port-a-clk-active {
+			samsung,pins = "gpj1-3";
+			samsung,pin-function = <2>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <3>;
+		};
+
+		cam_port_a_clk_idle: cam-port-a-clk-idle {
+			samsung,pins = "gpj1-3";
+			samsung,pin-function = <0>;
+			samsung,pin-pud = <1>;
 			samsung,pin-drv = <0>;
 		};
 	};
@@ -778,16 +791,29 @@
 			samsung,pin-drv = <3>;
 		};
 
-		cam_port_b: cam-port-b {
+		cam_port_b_io: cam-port-b-io {
 			samsung,pins = "gpm0-0", "gpm0-1", "gpm0-2", "gpm0-3",
 					"gpm0-4", "gpm0-5", "gpm0-6", "gpm0-7",
-					"gpm1-0", "gpm1-1", "gpm2-0", "gpm2-1",
-					"gpm2-2";
+					"gpm1-0", "gpm1-1", "gpm2-0", "gpm2-1";
 			samsung,pin-function = <3>;
 			samsung,pin-pud = <3>;
 			samsung,pin-drv = <0>;
 		};
 
+		cam_port_b_clk_active: cam-port-b-clk-active {
+			samsung,pins = "gpm2-2";
+			samsung,pin-function = <3>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <3>;
+		};
+
+		cam_port_b_clk_idle: cam-port-b-clk-idle {
+			samsung,pins = "gpm2-2";
+			samsung,pin-function = <0>;
+			samsung,pin-pud = <1>;
+			samsung,pin-drv = <0>;
+		};
+
 		eint0: ext-int0 {
 			samsung,pins = "gpx0-0";
 			samsung,pin-function = <0xf>;
-- 
1.7.9.5



From s.nawrocki at samsung.com  Mon Jul  1 11:22:25 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 17:22:25 +0200
Subject: [PATCH v3 03/13] ARM: dts: Add ISP power domain node for Exynos4x12
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1372692155-17653-4-git-send-email-s.nawrocki@samsung.com>

The ISP power domain is a common power domain for FIMC-LITE
and FIMC-IS (camera ISP) devices.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/exynos4x12.dtsi |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index 01da194..0e24d85 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -28,6 +28,11 @@
 		pinctrl3 = &pinctrl_3;
 	};
 
+	pd_isp: isp-power-domain at 10023CA0 {
+		compatible = "samsung,exynos4210-pd";
+		reg = <0x10023CA0 0x20>;
+	};
+
 	clock: clock-controller at 0x10030000 {
 		compatible = "samsung,exynos4412-clock";
 		reg = <0x10030000 0x20000>;
-- 
1.7.9.5



From s.nawrocki at samsung.com  Mon Jul  1 11:22:26 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 17:22:26 +0200
Subject: [PATCH v3 04/13] ARM: dts: Use generic DMA bindings for Exynos4 SPI
 devices
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1372692155-17653-5-git-send-email-s.nawrocki@samsung.com>

The Exynos4 SPI controller has migrated to the generic DMA bindings
since commit b5be04d35dbb2e00
"spi: s3c64xx: Modify SPI driver to use generic DMA DT support".
Use the generic bindings to specify the corresponding DMA to make
the SPI usable again on Exynos4x12 SoCs.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
Changes since v2:
 - edited commit description.
---
 arch/arm/boot/dts/exynos4.dtsi |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 3f94fe8..bce2254 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -297,8 +297,8 @@
 		compatible = "samsung,exynos4210-spi";
 		reg = <0x13920000 0x100>;
 		interrupts = <0 66 0>;
-		tx-dma-channel = <&pdma0 7>; /* preliminary */
-		rx-dma-channel = <&pdma0 6>; /* preliminary */
+		dmas = <&pdma0 7>, <&pdma0 6>;
+		dma-names = "tx", "rx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&clock 327>, <&clock 159>;
@@ -312,8 +312,8 @@
 		compatible = "samsung,exynos4210-spi";
 		reg = <0x13930000 0x100>;
 		interrupts = <0 67 0>;
-		tx-dma-channel = <&pdma1 7>; /* preliminary */
-		rx-dma-channel = <&pdma1 6>; /* preliminary */
+		dmas = <&pdma1 7>, <&pdma1 6>;
+		dma-names = "tx", "rx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&clock 328>, <&clock 160>;
@@ -327,8 +327,8 @@
 		compatible = "samsung,exynos4210-spi";
 		reg = <0x13940000 0x100>;
 		interrupts = <0 68 0>;
-		tx-dma-channel = <&pdma0 9>; /* preliminary */
-		rx-dma-channel = <&pdma0 8>; /* preliminary */
+		dmas = <&pdma0 9>, <&pdma0 8>;
+		dma-names = "tx", "rx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&clock 329>, <&clock 161>;
-- 
1.7.9.5



From s.nawrocki at samsung.com  Mon Jul  1 11:22:27 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 17:22:27 +0200
Subject: [PATCH v3 05/13] ARM: dts: Add camera subsystem device nodes to
 exynos4.dtsi
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1372692155-17653-6-git-send-email-s.nawrocki@samsung.com>

This patch adds the FIMC and MIPI CSIS device nodes common to the Exynos4
SoC series.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
Changes since v2:
 - added fimc/csis clock properties common for exynos4210 and exynos4x12
---
 arch/arm/boot/dts/exynos4.dtsi |   80 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 80 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index bce2254..752624f 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -36,6 +36,12 @@
 		i2c5 = &i2c_5;
 		i2c6 = &i2c_6;
 		i2c7 = &i2c_7;
+		csis0 = &csis_0;
+		csis1 = &csis_1;
+		fimc0 = &fimc_0;
+		fimc1 = &fimc_1;
+		fimc2 = &fimc_2;
+		fimc3 = &fimc_3;
 	};

 	chipid at 10000000 {
@@ -92,6 +98,80 @@
 		reg = <0x10010000 0x400>;
 	};

+	camera {
+		compatible = "samsung,fimc", "simple-bus";
+		status = "disabled";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		fimc_0: fimc at 11800000 {
+			compatible = "samsung,exynos4210-fimc";
+			reg = <0x11800000 0x1000>;
+			interrupts = <0 84 0>;
+			clocks = <&clock 256>, <&clock 128>;
+			clock-names = "fimc", "sclk_fimc";
+			samsung,power-domain = <&pd_cam>;
+			samsung,sysreg = <&sys_reg>;
+			status = "disabled";
+		};
+
+		fimc_1: fimc at 11810000 {
+			compatible = "samsung,exynos4210-fimc";
+			reg = <0x11810000 0x1000>;
+			interrupts = <0 85 0>;
+			clocks = <&clock 257>, <&clock 129>;
+			clock-names = "fimc", "sclk_fimc";
+			samsung,power-domain = <&pd_cam>;
+			samsung,sysreg = <&sys_reg>;
+			status = "disabled";
+		};
+
+		fimc_2: fimc at 11820000 {
+			compatible = "samsung,exynos4210-fimc";
+			reg = <0x11820000 0x1000>;
+			interrupts = <0 86 0>;
+			clocks = <&clock 258>, <&clock 130>;
+			clock-names = "fimc", "sclk_fimc";
+			samsung,power-domain = <&pd_cam>;
+			samsung,sysreg = <&sys_reg>;
+			status = "disabled";
+		};
+
+		fimc_3: fimc at 11830000 {
+			compatible = "samsung,exynos4210-fimc";
+			reg = <0x11830000 0x1000>;
+			interrupts = <0 87 0>;
+			clocks = <&clock 259>, <&clock 131>;
+			clock-names = "fimc", "sclk_fimc";
+			samsung,power-domain = <&pd_cam>;
+			samsung,sysreg = <&sys_reg>;
+			status = "disabled";
+		};
+
+		csis_0: csis at 11880000 {
+			compatible = "samsung,exynos4210-csis";
+			reg = <0x11880000 0x4000>;
+			interrupts = <0 78 0>;
+			clocks = <&clock 260>, <&clock 134>;
+			clock-names = "csis", "sclk_csis";
+			bus-width = <4>;
+			samsung,power-domain = <&pd_cam>;
+			status = "disabled";
+		};
+
+		csis_1: csis at 11890000 {
+			compatible = "samsung,exynos4210-csis";
+			reg = <0x11890000 0x4000>;
+			interrupts = <0 80 0>;
+			clocks = <&clock 261>, <&clock 135>;
+			clock-names = "csis", "sclk_csis";
+			bus-width = <2>;
+			samsung,power-domain = <&pd_cam>;
+			status = "disabled";
+		};
+	};
+
 	watchdog at 10060000 {
 		compatible = "samsung,s3c2410-wdt";
 		reg = <0x10060000 0x100>;
--
1.7.9.5



From s.nawrocki at samsung.com  Mon Jul  1 11:22:28 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 17:22:28 +0200
Subject: [PATCH v3 06/13] ARM: dts: Add camera subsystem nodes to
 exynos4x12.dtsi
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1372692155-17653-7-git-send-email-s.nawrocki@samsung.com>

Add common camera node and Exynos4212/4412 specific nodes for
FIMC, MIPI-CSIS, FIMC-LITE and FIMC-IS devices.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
Changes since v2:
 - fixed typo in exynos4x12 i2c_isp node reg property,
 - removed the clock properties which are now moved to exynos4.dtsi,
   "mux" and "parent" clock entries are dropped.
---
 arch/arm/boot/dts/exynos4x12.dtsi |   98 +++++++++++++++++++++++++++++++++++++
 1 file changed, 98 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index 0e24d85..954628c 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -26,6 +26,8 @@
 		pinctrl1 = &pinctrl_1;
 		pinctrl2 = &pinctrl_2;
 		pinctrl3 = &pinctrl_3;
+		fimc-lite0 = &fimc_lite_0;
+		fimc-lite1 = &fimc_lite_1;
 	};
 
 	pd_isp: isp-power-domain at 10023CA0 {
@@ -78,4 +80,100 @@
 		clock-names = "sclk_fimg2d", "fimg2d";
 		status = "disabled";
 	};
+
+	camera {
+		clocks = <&clock 132>, <&clock 133>, <&clock 351>, <&clock 352>;
+		clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0", "pxl_async1";
+
+		fimc_0: fimc at 11800000 {
+			compatible = "samsung,exynos4212-fimc";
+			samsung,pix-limits = <4224 8192 1920 4224>;
+			samsung,mainscaler-ext;
+			samsung,isp-wb;
+			samsung,cam-if;
+		};
+
+		fimc_1: fimc at 11810000 {
+			compatible = "samsung,exynos4212-fimc";
+			samsung,pix-limits = <4224 8192 1920 4224>;
+			samsung,mainscaler-ext;
+			samsung,isp-wb;
+			samsung,cam-if;
+		};
+
+		fimc_2: fimc at 11820000 {
+			compatible = "samsung,exynos4212-fimc";
+			samsung,pix-limits = <4224 8192 1920 4224>;
+			samsung,mainscaler-ext;
+			samsung,isp-wb;
+			samsung,lcd-wb;
+			samsung,cam-if;
+		};
+
+		fimc_3: fimc at 11830000 {
+			compatible = "samsung,exynos4212-fimc";
+			samsung,pix-limits = <1920 8192 1366 1920>;
+			samsung,rotators = <0>;
+			samsung,mainscaler-ext;
+			samsung,isp-wb;
+			samsung,lcd-wb;
+		};
+
+		fimc_lite_0: fimc-lite at 12390000 {
+			compatible = "samsung,exynos4212-fimc-lite";
+			reg = <0x12390000 0x1000>;
+			interrupts = <0 105 0>;
+			samsung,power-domain = <&pd_isp>;
+			clocks = <&clock 353>;
+			clock-names = "flite";
+			status = "disabled";
+		};
+
+		fimc_lite_1: fimc-lite at 123A0000 {
+			compatible = "samsung,exynos4212-fimc-lite";
+			reg = <0x123A0000 0x1000>;
+			interrupts = <0 106 0>;
+			samsung,power-domain = <&pd_isp>;
+			clocks = <&clock 354>;
+			clock-names = "flite";
+			status = "disabled";
+		};
+
+		fimc_is: fimc-is at 12000000 {
+			compatible = "samsung,exynos4212-fimc-is", "simple-bus";
+			reg = <0x12000000 0x260000>;
+			interrupts = <0 90 0>, <0 95 0>;
+			samsung,power-domain = <&pd_isp>;
+			clocks = <&clock 353>, <&clock 354>, <&clock 355>,
+				<&clock 356>, <&clock 17>, <&clock 357>,
+				<&clock 358>, <&clock 359>, <&clock 360>,
+				<&clock 450>,<&clock 451>, <&clock 452>,
+				<&clock 453>, <&clock 176>, <&clock 13>,
+				<&clock 454>, <&clock 395>, <&clock 455>;
+			clock-names = "lite0", "lite1", "ppmuispx",
+				      "ppmuispmx", "mpll", "isp",
+				      "drc", "fd", "mcuisp",
+				      "ispdiv0", "ispdiv1", "mcuispdiv0",
+				      "mcuispdiv1", "uart", "aclk200",
+				      "div_aclk200", "aclk400mcuisp",
+				      "div_aclk400mcuisp";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+			status = "disabled";
+
+			pmu {
+				reg = <0x10020000 0x3000>;
+			};
+
+			i2c1_isp: i2c-isp at 12140000 {
+				compatible = "samsung,exynos4212-i2c-isp";
+				reg = <0x12140000 0x100>;
+				clocks = <&clock 370>;
+				clock-names = "i2c_isp";
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
+		};
+	};
 };
-- 
1.7.9.5



From s.nawrocki at samsung.com  Mon Jul  1 11:22:24 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 17:22:24 +0200
Subject: [PATCH v3 02/13] ARM: dts: Add pinctrl entries for Exynos4x12 FIMC-IS
 peripherals
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1372692155-17653-3-git-send-email-s.nawrocki@samsung.com>

Add pinctrl nodes for the ISP I2C0, ISP I2C1 and ISP UART devices.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index 55ff73b..99b26df 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -848,6 +848,27 @@
 			samsung,pin-pud = <0>;
 			samsung,pin-drv = <0>;
 		};
+
+		fimc_is_i2c0: fimc-is-i2c0 {
+			samsung,pins = "gpm4-0", "gpm4-1";
+			samsung,pin-function = <2>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <0>;
+		};
+
+		fimc_is_i2c1: fimc-is-i2c1 {
+			samsung,pins = "gpm4-2", "gpm4-3";
+			samsung,pin-function = <2>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <0>;
+		};
+
+		fimc_is_uart: fimc-is-uart {
+			samsung,pins = "gpm3-5", "gpm3-7";
+			samsung,pin-function = <3>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <0>;
+		};
 	};
 
 	pinctrl at 03860000 {
-- 
1.7.9.5



From s.nawrocki at samsung.com  Mon Jul  1 11:22:29 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 17:22:29 +0200
Subject: [PATCH v3 07/13] ARM: dts: Add AK8975 device node for Exynos4412
 TRATS2 board
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1372692155-17653-8-git-send-email-s.nawrocki@samsung.com>

From: Jacek Anaszewski <j.anaszewski at samsung.com>

This patch adds AK8975 magnetometer node and corresponding
i2c-gpio bus node for TRATS2 board.

Signed-off-by: Jacek Anaszewski <j.anaszewski at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
index 056b835..b9de3b5 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -19,6 +19,10 @@
 	model = "Samsung Trats 2 based on Exynos4412";
 	compatible = "samsung,trats2", "samsung,exynos4412";
 
+	aliases {
+		i2c8 = &i2c_ak8975;
+	};
+
 	memory {
 		reg =  <0x40000000 0x40000000>;
 	};
@@ -453,4 +457,19 @@
 	serial at 13830000 {
 		status = "okay";
 	};
+
+	i2c_ak8975: i2c-gpio at 0 {
+		compatible = "i2c-gpio";
+		gpios = <&gpy2 4 0>, <&gpy2 5 0>;
+		i2c-gpio,delay-us = <2>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "okay";
+
+		ak8975 at 0c {
+			compatible = "asahi-kasei,ak8975";
+			reg = <0x0c>;
+			gpios = <&gpj0 7 0>;
+		};
+	};
 };
-- 
1.7.9.5



From s.nawrocki at samsung.com  Mon Jul  1 11:22:30 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 17:22:30 +0200
Subject: [PATCH v3 08/13] ARM: dts: Add camera device nodes for Exynos4412
 TRATS2 board
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1372692155-17653-9-git-send-email-s.nawrocki@samsung.com>

This patch enables the front camera using the internal
camera ISP (FIMC-IS).

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   91 +++++++++++++++++++++++++++++++
 1 file changed, 91 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
index b9de3b5..e9fb3de 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -62,6 +62,15 @@
 			enable-active-high;
 		};
 
+		cam_io_reg: voltage-regulator at 3 {
+			compatible = "regulator-fixed";
+			regulator-name = "CAM_SENSOR_A";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			gpio = <&gpm0 2 0>;
+			enable-active-high;
+		};
+
 		/* More to come */
 	};
 
@@ -472,4 +481,86 @@
 			gpios = <&gpj0 7 0>;
 		};
 	};
+
+	camera {
+		pinctrl-names = "default";
+		pinctrl-0 = <&cam_port_b_clk_active>;
+		status = "okay";
+
+		fimc_0: fimc at 11800000 {
+			clock-frequency = <160000000>;
+			status = "okay";
+		};
+
+		fimc_1: fimc at 11810000 {
+			clock-frequency = <160000000>;
+			status = "okay";
+		};
+
+		fimc_2: fimc at 11820000 {
+			clock-frequency = <160000000>;
+			status = "okay";
+		};
+
+		fimc_3: fimc at 11830000 {
+			clock-frequency = <160000000>;
+			status = "okay";
+		};
+
+		csis_1: csis at 11890000 {
+			vddcore-supply = <&ldo8_reg>;
+			vddio-supply = <&ldo10_reg>;
+			clock-frequency = <160000000>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "okay";
+
+			/* Camera D (4) MIPI CSI-2 (CSIS1) */
+			port at 4 {
+				reg = <4>;
+				csis1_ep: endpoint {
+					remote-endpoint = <&is_s5k6a3_ep>;
+					data-lanes = <1>;
+					samsung,csis-hs-settle = <18>;
+					samsung,csis-wclk;
+				};
+			};
+		};
+
+		fimc_lite_0: fimc-lite at 12390000 {
+			status = "okay";
+		};
+
+		fimc_lite_1: fimc-lite at 123A0000 {
+			status = "okay";
+		};
+
+		fimc-is at 12000000 {
+			pinctrl-0 = <&fimc_is_uart>;
+			pinctrl-names = "default";
+			status = "okay";
+
+			i2c1_isp: i2c-isp at 12140000 {
+				pinctrl-0 = <&fimc_is_i2c1>;
+				pinctrl-names = "default";
+
+				s5k6a3 at 10 {
+					compatible = "samsung,s5k6a3";
+					reg = <0x10>;
+					svdda-supply = <&cam_io_reg>;
+					svddio-supply = <&ldo19_reg>;
+					clock-frequency = <24000000>;
+					samsung,camclk-out = <1>;
+					gpios = <&gpm1 6 0>;
+
+					port {
+						is_s5k6a3_ep: endpoint {
+							remote-endpoint = <&csis1_ep>;
+							data-lanes = <1>;
+						};
+					};
+				};
+			};
+		};
+	};
 };
-- 
1.7.9.5



From s.nawrocki at samsung.com  Mon Jul  1 11:22:31 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 17:22:31 +0200
Subject: [PATCH v3 09/13] ARM: dts: Add camera device nodes for Exynos4210 SoCs
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1372692155-17653-10-git-send-email-s.nawrocki@samsung.com>

Add common camera node and detailed properties for
the Exynos4210 FIMC devices.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/exynos4210.dtsi |   30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index b7f358a..ef8c2a5 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -125,4 +125,34 @@
 		clock-names = "sclk_fimg2d", "fimg2d";
 		status = "disabled";
 	};
+
+	camera {
+		clocks = <&clock 132>, <&clock 133>, <&clock 351>, <&clock 352>;
+		clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0", "pxl_async1";
+
+		fimc_0: fimc at 11800000 {
+			samsung,pix-limits = <4224 8192 1920 4224>;
+			samsung,mainscaler-ext;
+			samsung,cam-if;
+		};
+
+		fimc_1: fimc at 11810000 {
+			samsung,pix-limits = <4224 8192 1920 4224>;
+			samsung,mainscaler-ext;
+			samsung,cam-if;
+		};
+
+		fimc_2: fimc at 11820000 {
+			samsung,pix-limits = <4224 8192 1920 4224>;
+			samsung,mainscaler-ext;
+			samsung,lcd-wb;
+		};
+
+		fimc_3: fimc at 11830000 {
+			samsung,pix-limits = <1920 8192 1366 1920>;
+			samsung,rotators = <0>;
+			samsung,mainscaler-ext;
+			samsung,lcd-wb;
+		};
+	};
 };
-- 
1.7.9.5



From s.nawrocki at samsung.com  Mon Jul  1 11:22:32 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 17:22:32 +0200
Subject: [PATCH v3 10/13] ARM: dts: Add FIMC nodes for Exynos4210 Trats board
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1372692155-17653-11-git-send-email-s.nawrocki@samsung.com>

Enable FIMC devices on the Trats board. This allows using the
device in memory-to-memory mode only. The camera port pinctrl
property is now empty and will be updated while support for the
camera sensors is added.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/exynos4210-trats.dts |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts
index 94eebff..6b1568e 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -301,4 +301,27 @@
 			clock-frequency = <24000000>;
 		};
 	};
+
+	camera {
+		status = "okay";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <>;
+
+		fimc_0: fimc at 11800000 {
+			status = "okay";
+		};
+
+		fimc_1: fimc at 11810000 {
+			status = "okay";
+		};
+
+		fimc_2: fimc at 11820000 {
+			status = "okay";
+		};
+
+		fimc_3: fimc at 11830000 {
+			status = "okay";
+		};
+	};
 };
-- 
1.7.9.5



From s.nawrocki at samsung.com  Mon Jul  1 11:22:33 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 17:22:33 +0200
Subject: [PATCH v3 11/13] ARM: dts: Add Exynos4210 SoC camera port pinctrl
 nodes
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1372692155-17653-12-git-send-email-s.nawrocki@samsung.com>

From: Andrzej Hajda <a.hajda at samsung.com>

Add pinctrl nodes for the camera parallel port CAM_A data bus
and the CAM_A_CLKOUT clock output pin.

Signed-off-by: Andrzej Hajda <a.hajda at samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/exynos4210-pinctrl.dtsi |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
index 553bcea..a7c2128 100644
--- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
@@ -797,6 +797,29 @@
 			samsung,pin-pud = <0>;
 			samsung,pin-drv = <0>;
 		};
+
+		cam_port_a_io: cam-port-a-io {
+			samsung,pins = "gpj0-0", "gpj0-1", "gpj0-2", "gpj0-3",
+					"gpj0-4", "gpj0-5", "gpj0-6", "gpj0-7",
+					"gpj1-0", "gpj1-1", "gpj1-2", "gpj1-4";
+			samsung,pin-function = <2>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <0>;
+		};
+
+		cam_port_a_clk_active: cam-port-a-clk-active {
+			samsung,pins = "gpj1-3";
+			samsung,pin-function = <2>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <3>;
+		};
+
+		cam_port_a_clk_idle: cam-port-a-clk-idle {
+			samsung,pins = "gpj1-3";
+			samsung,pin-function = <0>;
+			samsung,pin-pud = <1>;
+			samsung,pin-drv = <0>;
+		};
 	};
 
 	pinctrl at 03860000 {
-- 
1.7.9.5



From s.nawrocki at samsung.com  Mon Jul  1 11:22:34 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 17:22:34 +0200
Subject: [PATCH v3 12/13] ARM: dts: Add S5K5BA sensor regulator definitions for
 Trats board
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1372692155-17653-13-git-send-email-s.nawrocki@samsung.com>

From: Andrzej Hajda <a.hajda at samsung.com>

Add MAX8998 LDO12 and fixed voltage regulator nodes. While at it,
all fixed voltage regulator nodes are grouped in a 'regulators' node.

Signed-off-by: Andrzej Hajda <a.hajda at samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/exynos4210-trats.dts |   80 +++++++++++++++++++++++++-------
 1 file changed, 64 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts
index 6b1568e..f62e299 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -30,13 +30,64 @@
 		bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rootwait earlyprintk panic=5";
 	};
 
-	vemmc_reg: voltage-regulator at 0 {
-	        compatible = "regulator-fixed";
-		regulator-name = "VMEM_VDD_2.8V";
-		regulator-min-microvolt = <2800000>;
-		regulator-max-microvolt = <2800000>;
-		gpio = <&gpk0 2 0>;
-		enable-active-high;
+	regulators {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		vemmc_reg: regulator at 0 {
+			compatible = "regulator-fixed";
+			regulator-name = "VMEM_VDD_2.8V";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			gpio = <&gpk0 2 0>;
+			enable-active-high;
+		};
+
+		tsp_reg: regulator at 1 {
+			compatible = "regulator-fixed";
+			regulator-name = "TSP_FIXED_VOLTAGES";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			gpio = <&gpl0 3 0>;
+			enable-active-high;
+		};
+
+		cam_af_28v_reg: regulator at 2 {
+			compatible = "regulator-fixed";
+			regulator-name = "8M_AF_2.8V_EN";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			gpio = <&gpk1 1 0>;
+			enable-active-high;
+		};
+
+		cam_io_en_reg: regulator at 3 {
+			compatible = "regulator-fixed";
+			regulator-name = "CAM_IO_EN";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			gpio = <&gpe2 1 0>;
+			enable-active-high;
+		};
+
+		cam_io_12v_reg: regulator at 4 {
+			compatible = "regulator-fixed";
+			regulator-name = "8M_1.2V_EN";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			gpio = <&gpe2 5 0>;
+			enable-active-high;
+		};
+
+		vt_core_15v_reg: regulator at 5 {
+			compatible = "regulator-fixed";
+			regulator-name = "VT_CORE_1.5V";
+			regulator-min-microvolt = <1500000>;
+			regulator-max-microvolt = <1500000>;
+			gpio = <&gpe2 2 0>;
+			enable-active-high;
+		};
 	};
 
 	sdhci_emmc: sdhci at 12510000 {
@@ -97,15 +148,6 @@
 		};
 	};
 
-	tsp_reg: voltage-regulator {
-		compatible = "regulator-fixed";
-		regulator-name = "TSP_FIXED_VOLTAGES";
-		regulator-min-microvolt = <2800000>;
-		regulator-max-microvolt = <2800000>;
-		gpio = <&gpl0 3 0>;
-		enable-active-high;
-	};
-
 	i2c at 13890000 {
 		samsung,i2c-sda-delay = <100>;
 		samsung,i2c-slave-addr = <0x10>;
@@ -218,6 +260,12 @@
 				     regulator-always-on;
 				};
 
+				vtcam_reg: LDO12 {
+				     regulator-name = "VT_CAM_1.8V";
+				     regulator-min-microvolt = <1800000>;
+				     regulator-max-microvolt = <1800000>;
+				};
+
 				vcclcd_reg: LDO13 {
 				     regulator-name = "VCC_3.3V_LCD";
 				     regulator-min-microvolt = <3300000>;
-- 
1.7.9.5



From s.nawrocki at samsung.com  Mon Jul  1 11:22:35 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 17:22:35 +0200
Subject: [PATCH v3 13/13] ARM: dts: Add MIPI PHY node to exynos4.dtsi
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1372692155-17653-14-git-send-email-s.nawrocki@samsung.com>

Add PHY provider node for the MIPI CSIS and MIPI DSIM PHYs.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/boot/dts/exynos4.dtsi |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 752624f..e27eba8 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -49,6 +49,12 @@
 		reg = <0x10000000 0x100>;
 	};
 
+	mipi_phy: video-phy at 10020710 {
+		compatible = "samsung,s5pv210-mipi-video-phy";
+		reg = <0x10020710 8>;
+		#phy-cells = <1>;
+	};
+
 	pd_mfc: mfc-power-domain at 10023C40 {
 		compatible = "samsung,exynos4210-pd";
 		reg = <0x10023C40 0x20>;
@@ -157,6 +163,8 @@
 			clock-names = "csis", "sclk_csis";
 			bus-width = <4>;
 			samsung,power-domain = <&pd_cam>;
+			phys = <&mipi_phy 0>;
+			phy-names = "csis";
 			status = "disabled";
 		};
 
@@ -168,6 +176,8 @@
 			clock-names = "csis", "sclk_csis";
 			bus-width = <2>;
 			samsung,power-domain = <&pd_cam>;
+			phys = <&mipi_phy 2>;
+			phy-names = "csis";
 			status = "disabled";
 		};
 	};
-- 
1.7.9.5



From shawn.guo at linaro.org  Mon Jul  1 11:29:56 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 23:29:56 +0800
Subject: [v2 4/4] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <20130701124445.GW516@pengutronix.de>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-5-git-send-email-r65037@freescale.com>
 <20130701124445.GW516@pengutronix.de>
Message-ID: <20130701152955.GW13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 02:44:45PM +0200, Sascha Hauer wrote:
> On Mon, Jul 01, 2013 at 06:02:55PM +0800, Richard Zhu wrote:
> > imx6q contains one Synopsys AHCI SATA controller,
> > But it can't shares ahci_platform driver with other
> > controllers.
> > Because there are some misalignments of the bits
> > definitions of the HBA registers and the Vendor
> > Specific registers
> >  - CAP_SSS(bit20) of the HOST_CAP is writable, default
> >  value is '0', should be configured to be '1'
> >  - bit0 (only one AHCI SATA port on imx6q) of the
> >  HOST_PORTS_IMPL should be set to be '1'.(default 0)
> >  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
> >  should be configured regarding to the frequency of AHB
> >  bus clock.
> > 
> > Setup its own ahci sata driver, enable the imx6q ahci
> > sata support, and update the ahci sata binding document.
> > 
> > Signed-off-by: Richard Zhu <r65037 at freescale.com>
> 
> Wait a minute. We suggested to add a i.MX specific ahci driver to put
> the i.MX speicific setup in there. Now you really post a separate i.MX
> driver, but instead of putting the setup in there, it's a nearly
> identical copy of the generic driver *without* the setup and the setup
> is still in arch/arm/. That doesn't make sense to me.

+1

Richard,

You could have confused by me with pointing you to the sata_highbank
driver.  Sorry.  But Sascha posted his work [1] later in the same
thread.  That's obviously the way we should go, and I thought you
knew you should start your v2 based on that.  You missed that?

Shawn

[1] http://thread.gmane.org/gmane.linux.ide/54410/focus=54434



From shawn.guo at linaro.org  Mon Jul  1 11:33:29 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 1 Jul 2013 23:33:29 +0800
Subject: [alsa-devel] [PATCH 1/4] ASoC: sgtl5000: give it a ramping time
 before writting
In-Reply-To: <CAOMZO5Bh5CZLBO-epVA9Vivo-mqmBJZhy7iA6HiMy+xLzDj40w@mail.gmail.com>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>
 <20130701100710.GB27646@sirena.org.uk>
 <201307011254.18952.marex@denx.de>
 <CAOMZO5BAs5-Tf_O0TVLFAuCchVuukV+bH2MpjqMU83tTw2GD=Q@mail.gmail.com>
 <20130701142610.GR13206@S2101-09.ap.freescale.net>
 <20130701143415.GA14172@S2101-09.ap.freescale.net>
 <CAOMZO5Bh5CZLBO-epVA9Vivo-mqmBJZhy7iA6HiMy+xLzDj40w@mail.gmail.com>
Message-ID: <20130701153327.GX13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 12:11:58PM -0300, Fabio Estevam wrote:
> On Mon, Jul 1, 2013 at 11:34 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> 
> > And also why we do not see the impact of i2c issue on sgtl5000 before
> > the offending commit af8ee11 (ASoC: sgtl5000: Fix driver probe after
> > reset)?
> 
> Probably because the mxs i2c was working before this commit.

Do you have a commit id at which mxs i2c is known good?  I would like to
find out it's a mxs i2c issue or sgtl5000 problem.

> 
> Commit af8ee11 does fix the reset probe on mx51/mx53/mx6.
> 
> It's only on mx28 that we have this issue.
> 
> Also, please see this patch from Alexandre Belloni:
> https://lkml.org/lkml/2013/6/24/430
> 
> He can only connect the ADC chip if he uses I2C bitbang mode on mx28.

Does I2C bitbang mode help fix the sgtl5000 issue here?

Shawn



From tixy at linaro.org  Mon Jul  1 11:34:22 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Mon, 01 Jul 2013 16:34:22 +0100
Subject: [PATCH] ARM: vexpress_defconfig: Enable voltage regulators
In-Reply-To: <1370901015-4159-1-git-send-email-christoffer.dall@linaro.org>
References: <1370901015-4159-1-git-send-email-christoffer.dall@linaro.org>
Message-ID: <1372692862.3716.57.camel@linaro1.home>

On Mon, 2013-06-10 at 14:50 -0700, Christoffer Dall wrote:
> Enable the Versatile Express voltage regulators by default.
> 
> This should work on all verstatile express platforms and not enabling it
> prevents a defconfig'ed kernel from using the SD card controller on the
> qemu emulated platform, which is unfortunate for first-time casual
> users.
> 
> Cc: Peter Maydell <peter.maydell at linaro.org>
> Signed-off-by: Christoffer Dall <christoffer.dall at linaro.org>
> ---
>  arch/arm/configs/vexpress_defconfig |    3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/configs/vexpress_defconfig b/arch/arm/configs/vexpress_defconfig
> index f2de51f..17104d9 100644
> --- a/arch/arm/configs/vexpress_defconfig
> +++ b/arch/arm/configs/vexpress_defconfig
> @@ -138,3 +138,6 @@ CONFIG_DEBUG_LL=y
>  CONFIG_EARLY_PRINTK=y
>  # CONFIG_CRYPTO_ANSI_CPRNG is not set
>  # CONFIG_CRYPTO_HW is not set
> +CONFIG_REGULATOR=y
> +CONFIG_REGULATOR_FIXED_VOLTAGE=y
> +CONFIG_REGULATOR_VEXPRESS=y

>From my testing, only the CONFIG_REGULATOR=y is required to get MMC
working on real hardware with Linux 3.10. Is CONFIG_REGULATOR_VEXPRESS
actually required to get QEMU working properly?

We definitely don't need CONFIG_REGULATOR_FIXED_VOLTAGE because config
ARCH_VEXPRESS has "select REGULATOR_FIXED_VOLTAGE if REGULATOR".

-- 
Tixy




From nm at ti.com  Mon Jul  1 11:34:21 2013
From: nm at ti.com (Nishanth Menon)
Date: Mon, 1 Jul 2013 10:34:21 -0500
Subject: [-next PATCH 0/2] ARM: OMAP5: fix build breakage due to SCU usage
In-Reply-To: <1372257587-21720-1-git-send-email-nm@ti.com>
References: <1372257587-21720-1-git-send-email-nm@ti.com>
Message-ID: <51D1A17D.9070701@ti.com>

Tony,

Any chance of picking these up?

I see that next-20130701 is broke as well in an OMAP5 only build. beyond 
the fixes already merged in - the missing series seems to be the 
$subject series to allow an OMAP5 only build.

On 06/26/2013 09:39 AM, Nishanth Menon wrote:
> Hi,
>
> Cortex-A15 based OMAP5 does not use Snoop Control Unit(SCU)[1].
> However, there is lot of code that is shared between Cortex-A9 based
> OMAP4 and OMAP5, hence functionality code is shared with runtime usage
> of SCU based on SoC worked on. However on building with OMAP5 only
> generates the following errors:
> arch/arm/mach-omap2/built-in.o: In function `scu_gp_set':
> arch/arm/mach-omap2/sleep44xx.S:132: undefined reference to `scu_power_mode'
> arch/arm/mach-omap2/built-in.o: In function `scu_gp_clear':
> arch/arm/mach-omap2/sleep44xx.S:229: undefined reference to `scu_power_mode'
> arch/arm/mach-omap2/built-in.o: In function `omap4_smp_init_cpus':
> arch/arm/mach-omap2/omap-smp.c:185: undefined reference to `scu_get_core_count'
> arch/arm/mach-omap2/built-in.o: In function `omap4_smp_prepare_cpus':
> arch/arm/mach-omap2/omap-smp.c:211: undefined reference to `scu_enable'
>
> This was attempted to be "fixed" in various attempts in the past [2] [3].
>
> This series applies on top of the other fixes in discussion for linux-next [4] [5].
>
> Based on:
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git  next-20130626
>
> Nishanth Menon (2):
>    ARM: OMAP4: sleep: build OMAP4 specific functions only for OMAP4
>    ARM: scu: provide inline dummy functions when SCU is not present
>
>   arch/arm/include/asm/smp_scu.h  |   13 ++++++++++++-
>   arch/arm/mach-omap2/sleep44xx.S |    6 +++++-
>   2 files changed, 17 insertions(+), 2 deletions(-)
>
> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407e/CHDFJICC.html
> [2] https://patchwork.kernel.org/patch/2568091/
> [3] http://marc.info/?t=137120115400001&r=1&w=2
> [4] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/178209.html
> [5] https://patchwork.kernel.org/patch/2781471/
>
> Regards,
> Nishanth Menon
>


-- 
Regards,
Nishanth Menon


From festevam at gmail.com  Mon Jul  1 11:42:38 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 1 Jul 2013 12:42:38 -0300
Subject: [alsa-devel] [PATCH 1/4] ASoC: sgtl5000: give it a ramping time
 before writting
In-Reply-To: <20130701153327.GX13206@S2101-09.ap.freescale.net>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>
 <20130701100710.GB27646@sirena.org.uk>
 <201307011254.18952.marex@denx.de>
 <CAOMZO5BAs5-Tf_O0TVLFAuCchVuukV+bH2MpjqMU83tTw2GD=Q@mail.gmail.com>
 <20130701142610.GR13206@S2101-09.ap.freescale.net>
 <20130701143415.GA14172@S2101-09.ap.freescale.net>
 <CAOMZO5Bh5CZLBO-epVA9Vivo-mqmBJZhy7iA6HiMy+xLzDj40w@mail.gmail.com>
 <20130701153327.GX13206@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5B5jh1XciO4K1u3yBcHHDAgi8hA3GcywnJd11M7=aOPxA@mail.gmail.com>

On Mon, Jul 1, 2013 at 12:33 PM, Shawn Guo <shawn.guo at linaro.org> wrote:
> On Mon, Jul 01, 2013 at 12:11:58PM -0300, Fabio Estevam wrote:
>> On Mon, Jul 1, 2013 at 11:34 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
>>
>> > And also why we do not see the impact of i2c issue on sgtl5000 before
>> > the offending commit af8ee11 (ASoC: sgtl5000: Fix driver probe after
>> > reset)?
>>
>> Probably because the mxs i2c was working before this commit.
>
> Do you have a commit id at which mxs i2c is known good?  I would like to
> find out it's a mxs i2c issue or sgtl5000 problem.

I don't have it, but I am adding Alexandre in case he knows.

Alexandre,

Do you happen to know a commit id which does not show the mxs i2c
timeouts you have been observing?

>
>>
>> Commit af8ee11 does fix the reset probe on mx51/mx53/mx6.
>>
>> It's only on mx28 that we have this issue.
>>
>> Also, please see this patch from Alexandre Belloni:
>> https://lkml.org/lkml/2013/6/24/430
>>
>> He can only connect the ADC chip if he uses I2C bitbang mode on mx28.
>
> Does I2C bitbang mode help fix the sgtl5000 issue here?

I haven't made this test.


From shawn.guo at linaro.org  Mon Jul  1 12:08:36 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Jul 2013 00:08:36 +0800
Subject: [PATCH v2] serial: imx: remove the uart_console() check
In-Reply-To: <1372397982-19017-1-git-send-email-b32955@freescale.com>
References: <1372397982-19017-1-git-send-email-b32955@freescale.com>
Message-ID: <20130701160833.GC14172@S2101-09.ap.freescale.net>

On Fri, Jun 28, 2013 at 01:39:42PM +0800, Huang Shijie wrote:
> The uart_console() check makes the clocks(clk_per and clk_ipg) opened
> even when we close the console uart.
> 
> This patch enable/disable the clocks in imx_console_write(),
> so we can keep the clocks closed when the console uart is closed.
> 
> Also remove the clock enable/disable oprations in the probe, we do not
> need them any more.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>

Acked-by: Shawn Guo <shawn.guo at linaro.org>



From rklein at nvidia.com  Mon Jul  1 12:13:18 2013
From: rklein at nvidia.com (Rhyland Klein)
Date: Mon, 1 Jul 2013 12:13:18 -0400
Subject: [PATCH 1/4] power_supply: Add of_node_put to fix refcount
In-Reply-To: <20130629012255.GA20924@lizard>
References: <1370899602-22123-1-git-send-email-rklein@nvidia.com>
 <1370899602-22123-2-git-send-email-rklein@nvidia.com>
 <20130629012255.GA20924@lizard>
Message-ID: <51D1AA9E.2000909@nvidia.com>

On 6/28/2013 9:22 PM, Anton Vorontsov wrote:
> On Mon, Jun 10, 2013 at 05:26:39PM -0400, Rhyland Klein wrote:
>> of_parse_phandle increments the refcount for a dt node before returning
>> it. Add of_node_put where needed to properly decrement the refcount
>> when we are done using a given node.
>>
>> Signed-off-by: Rhyland Klein <rklein at nvidia.com>
>> ---
> 
> With CONFIG_OF=n I got this:
> 
>   CC      drivers/power/sbs-battery.o
>   drivers/power/sbs-battery.c: In function ?sbs_probe?:
>   drivers/power/sbs-battery.c:707:20: error: ?struct power_supply? has no
>   member named ?of_node?
>   make[1]: *** [drivers/power/sbs-battery.o] Error 1
> 
> I fixed this by the patch below and applied your 1-3 series.
> 
> Thanks!
> 
> Anton
> 
> commit b50df95c8f0703c95625181d2eaf53855c5ebee5
> Author: Anton Vorontsov <anton at enomsg.org>
> Date:   Fri Jun 28 18:17:22 2013 -0700
> 
>     power_supply: Move of_node out of the #ifdef CONFIG_OF
>     
>     Similar to linux/device.h, move of_node struct member out of the #ifdef
>     CONFIG_OF so that the drivers won't have to mess with #ifdefs in .c files.
>     
>     Signed-off-by: Anton Vorontsov <anton at enomsg.org>
> 
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 3828cef..804b906 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -162,6 +162,8 @@ union power_supply_propval {
>  	const char *strval;
>  };
>  
> +struct device_node;
> +
>  struct power_supply {
>  	const char *name;
>  	enum power_supply_type type;
> @@ -173,9 +175,7 @@ struct power_supply {
>  
>  	char **supplied_from;
>  	size_t num_supplies;
> -#ifdef CONFIG_OF
>  	struct device_node *of_node;
> -#endif
>  
>  	int (*get_property)(struct power_supply *psy,
>  			    enum power_supply_property psp,
> 

Thanks!

-rhyland

-- 
nvpublic


From stern at rowland.harvard.edu  Mon Jul  1 12:24:07 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Mon, 1 Jul 2013 12:24:07 -0400 (EDT)
Subject: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during
 bus suspend
In-Reply-To: <51D13AED.4010307@ti.com>
Message-ID: <Pine.LNX.4.44L0.1307011209440.1547-100000@iolanthe.rowland.org>

On Mon, 1 Jul 2013, Roger Quadros wrote:

> On 06/28/2013 10:06 PM, Alan Stern wrote:
> > On Fri, 28 Jun 2013, Roger Quadros wrote:
> > 
> >>> That's not what I meant.  Never mind the pinctrl; I was asking about
> >>> the EHCI controller itself.  Under what circumstances does the
> >>> controller assert its wakeup signal?  And how do you tell it to stop
> >>> asserting that signal?
> >>
> >> I believe this would be through the EHCI Interrupt enable register (USBINTR).
> >> I'm not aware of any other mechanism.
> > 
> > That's strange, because ehci_suspend() sets the intr_enable register to 
> > 0.  So how do you ever get any wakeup interrupts at all?
> 
> Because after ehci_suspend() for OMAP, we solely rely on the out of band wake up
> mechanism. i.e. Pad wakeup.

I don't know what Pad wakeup is.  The wakeup signal has to originate 
from the EHCI controller, doesn't it?  If not, how does the Pad know 
when a wakeup is needed?


> We can't enable_irq at the start as the controller will only be resumed
> after usb_remote_wakeup().

Hmmm, yes, I had realized that at one point and then forgot it.  You
don't want an IRQ to arrive before you're prepared to handle it.

This suggests that you really want to call enable_irq() call at the end
of ehci_resume() instead of the beginning.  (Convert the "return 0" to
a jump to the end of the routine.)

Alan Stern



From balbi at ti.com  Mon Jul  1 12:49:20 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 1 Jul 2013 19:49:20 +0300
Subject: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during
 bus suspend
In-Reply-To: <Pine.LNX.4.44L0.1307011209440.1547-100000@iolanthe.rowland.org>
References: <51D13AED.4010307@ti.com>
 <Pine.LNX.4.44L0.1307011209440.1547-100000@iolanthe.rowland.org>
Message-ID: <20130701164920.GA31370@arwen.pp.htv.fi>

On Mon, Jul 01, 2013 at 12:24:07PM -0400, Alan Stern wrote:
> On Mon, 1 Jul 2013, Roger Quadros wrote:
> 
> > On 06/28/2013 10:06 PM, Alan Stern wrote:
> > > On Fri, 28 Jun 2013, Roger Quadros wrote:
> > > 
> > >>> That's not what I meant.  Never mind the pinctrl; I was asking about
> > >>> the EHCI controller itself.  Under what circumstances does the
> > >>> controller assert its wakeup signal?  And how do you tell it to stop
> > >>> asserting that signal?
> > >>
> > >> I believe this would be through the EHCI Interrupt enable register (USBINTR).
> > >> I'm not aware of any other mechanism.
> > > 
> > > That's strange, because ehci_suspend() sets the intr_enable register to 
> > > 0.  So how do you ever get any wakeup interrupts at all?
> > 
> > Because after ehci_suspend() for OMAP, we solely rely on the out of band wake up
> > mechanism. i.e. Pad wakeup.
> 
> I don't know what Pad wakeup is.  The wakeup signal has to originate 
> from the EHCI controller, doesn't it?  If not, how does the Pad know 
> when a wakeup is needed?

That's really an OMAP thing, I guess. Pad wakeup sits in the PRCM (IIRC)
inside and always on power domain. EHCI sits in another power domain
which be turned off. When it's turned off (power gated and clock gated)
the EHCI block has no means to wakeup whatsoever. That's when pad wakeup
comes into play. It is generated when PRCM sees a change in the actual
pad of the die. To check who should 'own' the wakeup, it checks the
muxing settings to verify whose pad is that.

-- 
balbi
-------------- 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/20130701/b515cd6c/attachment.sig>

From linux at arm.linux.org.uk  Mon Jul  1 13:09:41 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 1 Jul 2013 18:09:41 +0100
Subject: [RFC PATCH 5/6] ARM, mm: change meaning of max_low_pfn to
 maximum pfn for nobootmem
In-Reply-To: <51D18ED5.50103@ti.com>
References: <1364184674-13798-1-git-send-email-iamjoonsoo.kim@lge.com>
 <1364184674-13798-6-git-send-email-iamjoonsoo.kim@lge.com>
 <51D18ED5.50103@ti.com>
Message-ID: <20130701170941.GC24642@n2100.arm.linux.org.uk>

On Mon, Jul 01, 2013 at 10:14:45AM -0400, Santosh Shilimkar wrote:
> I have been also carrying similar patch as yours in an attempt
> to make LPAE kernel work on ARM. Your patch carries better
> description, so will your version and include in my series
> which I plan to post on the list after some more testing.
> Will copy you. The changes are very similar to your series.

And will you try to investigate and/or address my concerns with this
change?

Consider this code in the block layer:

static int __init blk_settings_init(void)
{
        blk_max_low_pfn = max_low_pfn - 1;
        blk_max_pfn = max_pfn - 1;
        return 0;
}

void blk_queue_bounce_limit(struct request_queue *q, u64 dma_mask)
{
        unsigned long b_pfn = dma_mask >> PAGE_SHIFT;
...
        if (b_pfn < blk_max_low_pfn)
                dma = 1;
        q->limits.bounce_pfn = b_pfn;
        if (dma) {
                init_emergency_isa_pool();
                q->bounce_gfp = GFP_NOIO | GFP_DMA;
                q->limits.bounce_pfn = b_pfn;
        }
}

and this in SCSI:

u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
{
        struct device *host_dev;
        u64 bounce_limit = 0xffffffff;
...
        host_dev = scsi_get_device(shost);
        if (host_dev && host_dev->dma_mask)
                bounce_limit = *host_dev->dma_mask;

        return bounce_limit;
}

struct request_queue *__scsi_alloc_queue(struct Scsi_Host *shost,
                                         request_fn_proc *request_fn)
{
...
        blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));

Now, what happens when you have a device which can only address the first
64MB of system memory, which is at 3GB(physical), but you have 1GB of
system memory available both before changing max_low_pfn, and after
changing max_low_pfn.

Bear in mind that you will find that virtually all places in the kernel
set the device DMA mask to be "DMA_BIT_MASK(number_of_bits_driven)" and
not offset by the base of physical memory.  In the above case, consider
what happens with a 24 bit DMA mask.

So... if we make this change, I would much prefer to also see a number
of other patches preceding this one:

(a) blk_queue_bounce_limit()'s parameter renamed from "dma_mask" to
   "max_addr" or indeed just taking b_pfn directly.
(b) a helper: dma_max_pfn(dev) which converts a DMA bitmask of bits
   to a b_pfn number which is just "dev->dma_mask >> PAGE_SHIFT" in the
   generic case, but ARM can override this later.
(c) a patch changing max_low_pfn/max_pfn to include the physical offset
   of memory, and providing an ARM version of this which adds in the
   appropriate offset.

Here's an example dma_max_pfn() helper for the generic case:

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 48ef6f5..a083724 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -153,6 +153,13 @@ static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask)
 		return -EIO;
 }
 
+#ifndef dma_max_pfn
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+	return dev->dma_mask ? (*dev->dma_mask >> PAGE_SHIFT) : 0;
+}
+#endif
+
 static inline void *dma_zalloc_coherent(struct device *dev, size_t size,
 					dma_addr_t *dma_handle, gfp_t flag)
 {

Arches can then override this with:

static inline unsigned long dma_max_pfn(struct device *dev)
{
	...
}
#define dma_max_pfn dma_max_pfn


From catalin.marinas at arm.com  Mon Jul  1 13:23:15 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 1 Jul 2013 18:23:15 +0100
Subject: [GIT PULL] arm64 patches for 3.11
Message-ID: <20130701172309.GA12256@arm.com>

Hi Linus,

Please pull the arm64-upstream tag as below.

For arm64 huge pages support, there are x86 changes moving part of
arch/x86/mm/hugetlbpage.c into mm/hugetlb.c to be re-used by arm64. They
have been acked by akpm
(http://marc.info/?l=linux-mm&m=137115843813005&w=2) and I'm merging
them through the arm64 tree to avoid dependency issues.

There is also a trivial merge conflict with 3.10 in
include/uapi/linux/kvm.h (with the KVM_REG_MIPS define).

Thanks.


The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e:

  Linux 3.10-rc4 (2013-06-02 17:11:17 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git tags/arm64-upstream

for you to fetch changes up to aa729dccb5e8dfbc78e2e235b8754d6acccee731:

  Merge branch 'for-next/hugepages' of git://git.linaro.org/people/stevecapper/linux into upstream-hugepages (2013-07-01 11:20:58 +0100)

----------------------------------------------------------------

Main features:
- KVM and Xen ports to AArch64
- Hugetlbfs and transparent huge pages support for arm64
- Applied Micro X-Gene Kconfig entry and dts file
- Cache flushing improvements

----------------------------------------------------------------
Catalin Marinas (7):
      arm64: Avoid cache flushing in flush_dcache_page()
      arm64: Do not flush the D-cache for anonymous pages
      arm64: Remove __flush_dcache_page()
      arm64: spinlock: retry trylock operation if strex fails on free lock
      Merge tag 'xen-arm64-3.1-tag' of git://git.kernel.org/.../sstabellini/xen into upstream
      Merge branch 'kvm-arm64/kvm-for-3.11' of git://git.kernel.org/.../maz/arm-platforms into upstream
      Merge branch 'for-next/hugepages' of git://git.linaro.org/people/stevecapper/linux into upstream-hugepages

Chen Gang (1):
      arm64: kernel: compiling issue, need delete read_current_timer()

Damian Hobson-Garcia (1):
      arm64: Provide default implementation for dma_{alloc,free}_attrs

Kyle McMartin (1):
      arm64/Makefile: provide vdso_install target

Marc Zyngier (33):
      arm64: KVM: define HYP and Stage-2 translation page flags
      arm64: KVM: HYP mode idmap support
      arm64: KVM: EL2 register definitions
      arm64: KVM: system register definitions for 64bit guests
      arm64: KVM: Basic ESR_EL2 helpers and vcpu register access
      arm64: KVM: fault injection into a guest
      arm64: KVM: architecture specific MMU backend
      arm64: KVM: user space interface
      arm64: KVM: system register handling
      arm64: KVM: CPU specific system registers handling
      arm64: KVM: virtual CPU reset
      arm64: KVM: kvm_arch and kvm_vcpu_arch definitions
      arm64: KVM: MMIO access backend
      arm64: KVM: guest one-reg interface
      arm64: KVM: hypervisor initialization code
      arm64: KVM: HYP mode world switch implementation
      arm64: KVM: Exit handling
      arm64: KVM: Plug the VGIC
      ARM: KVM: timer: allow DT matching for ARMv8 cores
      arm64: KVM: Plug the arch timer
      arm64: KVM: PSCI implementation
      arm64: KVM: Build system integration
      arm64: KVM: define 32bit specific registers
      arm64: KVM: 32bit GP register access
      arm64: KVM: 32bit conditional execution emulation
      arm64: KVM: 32bit handling of coprocessor traps
      arm64: KVM: CPU specific 32bit coprocessor access
      arm64: KVM: 32bit specific register world switch
      arm64: KVM: 32bit guest fault injection
      arm64: KVM: enable initialization of a 32bit vcpu
      arm64: KVM: userspace API documentation
      arm64: KVM: MAINTAINERS update
      arm64: KVM: document kernel object mappings in HYP

Stefano Stabellini (6):
      arm/xen: define xen_remap as ioremap_cached
      arm64/xen: introduce asm/xen header files on arm64
      arm64/xen: implement ioremap_cached on arm64
      arm64/xen: use XEN_IO_PROTO_ABI_ARM on ARM64
      arm64/xen: introduce CONFIG_XEN and hypercall.S on ARM64
      MAINTAINERS: add myself as arm64/xen maintainer

Steve Capper (11):
      mm: hugetlb: Copy huge_pmd_share from x86 to mm.
      x86: mm: Remove x86 version of huge_pmd_share.
      mm: hugetlb: Copy general hugetlb code from x86 to mm.
      x86: mm: Remove general hugetlb code from x86.
      mm: thp: Correct the HPAGE_PMD_ORDER check.
      ARM64: mm: Restore memblock limit when map_mem finished.
      ARM64: mm: Make PAGE_NONE pages read only and no-execute.
      ARM64: mm: Move PTE_PROT_NONE bit.
      ARM64: mm: HugeTLB support.
      ARM64: mm: Raise MAX_ORDER for 64KB pages and THP.
      ARM64: mm: THP support.

Vinayak Kale (4):
      arm64: Add Kconfig option for APM X-Gene SOC family
      arm64: Enable APM X-Gene SOC family in the defconfig
      arm64: Add defines for APM ARMv8 implementation
      arm64: Add initial DTS for APM X-Gene Storm SOC and APM Mustang board

Will Deacon (5):
      arm64: mm: don't bother invalidating the icache in switch_mm
      arm64: pgtable: use pte_index instead of __pte_index
      arm64: device: add iommu pointer to device archdata
      arm64: extable: sort the exception table at build time
      arm64: debug: consolidate software breakpoint handlers

 Documentation/arm64/memory.txt          |    7 +
 Documentation/virtual/kvm/api.txt       |   58 +-
 MAINTAINERS                             |   16 +
 arch/arm/include/asm/xen/page.h         |    3 +-
 arch/arm/kvm/arch_timer.c               |    1 +
 arch/arm64/Kconfig                      |   35 ++
 arch/arm64/Makefile                     |    6 +
 arch/arm64/boot/dts/Makefile            |    1 +
 arch/arm64/boot/dts/apm-mustang.dts     |   26 +
 arch/arm64/boot/dts/apm-storm.dtsi      |  116 ++++
 arch/arm64/configs/defconfig            |    4 +
 arch/arm64/include/asm/cacheflush.h     |    3 -
 arch/arm64/include/asm/cputype.h        |    3 +
 arch/arm64/include/asm/debug-monitors.h |    9 +
 arch/arm64/include/asm/device.h         |    3 +
 arch/arm64/include/asm/dma-mapping.h    |   17 +-
 arch/arm64/include/asm/hugetlb.h        |  117 ++++
 arch/arm64/include/asm/hypervisor.h     |    6 +
 arch/arm64/include/asm/io.h             |    2 +
 arch/arm64/include/asm/kvm_arm.h        |  245 ++++++++
 arch/arm64/include/asm/kvm_asm.h        |  104 +++
 arch/arm64/include/asm/kvm_coproc.h     |   56 ++
 arch/arm64/include/asm/kvm_emulate.h    |  180 ++++++
 arch/arm64/include/asm/kvm_host.h       |  202 ++++++
 arch/arm64/include/asm/kvm_mmio.h       |   59 ++
 arch/arm64/include/asm/kvm_mmu.h        |  135 ++++
 arch/arm64/include/asm/kvm_psci.h       |   23 +
 arch/arm64/include/asm/memory.h         |    6 +
 arch/arm64/include/asm/mmu_context.h    |    6 -
 arch/arm64/include/asm/pgtable-hwdef.h  |   30 +
 arch/arm64/include/asm/pgtable.h        |  112 +++-
 arch/arm64/include/asm/ptrace.h         |    2 -
 arch/arm64/include/asm/spinlock.h       |    3 +-
 arch/arm64/include/asm/sync_bitops.h    |   26 +
 arch/arm64/include/asm/timex.h          |    6 +-
 arch/arm64/include/asm/tlb.h            |    6 +
 arch/arm64/include/asm/tlbflush.h       |    2 +
 arch/arm64/include/asm/xen/events.h     |   21 +
 arch/arm64/include/asm/xen/hypercall.h  |    1 +
 arch/arm64/include/asm/xen/hypervisor.h |    1 +
 arch/arm64/include/asm/xen/interface.h  |    1 +
 arch/arm64/include/asm/xen/page.h       |    1 +
 arch/arm64/include/uapi/asm/kvm.h       |  168 +++++
 arch/arm64/kernel/asm-offsets.c         |   33 +
 arch/arm64/kernel/debug-monitors.c      |   66 +-
 arch/arm64/kernel/ptrace.c              |   59 --
 arch/arm64/kernel/time.c                |    6 -
 arch/arm64/kernel/traps.c               |    5 +-
 arch/arm64/kernel/vmlinux.lds.S         |   30 +-
 arch/arm64/kvm/Makefile                 |   23 +
 arch/arm64/kvm/emulate.c                |  158 +++++
 arch/arm64/kvm/guest.c                  |  265 ++++++++
 arch/arm64/kvm/handle_exit.c            |  124 ++++
 arch/arm64/kvm/hyp-init.S               |  107 ++++
 arch/arm64/kvm/hyp.S                    |  831 ++++++++++++++++++++++++
 arch/arm64/kvm/inject_fault.c           |  203 ++++++
 arch/arm64/kvm/regmap.c                 |  168 +++++
 arch/arm64/kvm/reset.c                  |  112 ++++
 arch/arm64/kvm/sys_regs.c               | 1050 +++++++++++++++++++++++++++++++
 arch/arm64/kvm/sys_regs.h               |  138 ++++
 arch/arm64/kvm/sys_regs_generic_v8.c    |   95 +++
 arch/arm64/mm/Makefile                  |    1 +
 arch/arm64/mm/fault.c                   |   19 +-
 arch/arm64/mm/flush.c                   |   37 +-
 arch/arm64/mm/hugetlbpage.c             |   70 +++
 arch/arm64/mm/mm.h                      |    1 -
 arch/arm64/mm/mmu.c                     |   20 +-
 arch/arm64/xen/Makefile                 |    2 +
 arch/arm64/xen/hypercall.S              |   92 +++
 arch/x86/Kconfig                        |    6 +
 arch/x86/mm/hugetlbpage.c               |  187 ------
 include/linux/huge_mm.h                 |    2 +-
 include/linux/hugetlb.h                 |    4 +
 include/uapi/linux/kvm.h                |    2 +
 include/xen/interface/io/protocols.h    |    2 +-
 mm/hugetlb.c                            |  219 ++++++-
 scripts/sortextable.c                   |    5 +
 77 files changed, 5582 insertions(+), 389 deletions(-)
 create mode 100644 arch/arm64/boot/dts/apm-mustang.dts
 create mode 100644 arch/arm64/boot/dts/apm-storm.dtsi
 create mode 100644 arch/arm64/include/asm/hugetlb.h
 create mode 100644 arch/arm64/include/asm/hypervisor.h
 create mode 100644 arch/arm64/include/asm/kvm_arm.h
 create mode 100644 arch/arm64/include/asm/kvm_asm.h
 create mode 100644 arch/arm64/include/asm/kvm_coproc.h
 create mode 100644 arch/arm64/include/asm/kvm_emulate.h
 create mode 100644 arch/arm64/include/asm/kvm_host.h
 create mode 100644 arch/arm64/include/asm/kvm_mmio.h
 create mode 100644 arch/arm64/include/asm/kvm_mmu.h
 create mode 100644 arch/arm64/include/asm/kvm_psci.h
 create mode 100644 arch/arm64/include/asm/sync_bitops.h
 create mode 100644 arch/arm64/include/asm/xen/events.h
 create mode 100644 arch/arm64/include/asm/xen/hypercall.h
 create mode 100644 arch/arm64/include/asm/xen/hypervisor.h
 create mode 100644 arch/arm64/include/asm/xen/interface.h
 create mode 100644 arch/arm64/include/asm/xen/page.h
 create mode 100644 arch/arm64/include/uapi/asm/kvm.h
 create mode 100644 arch/arm64/kvm/Makefile
 create mode 100644 arch/arm64/kvm/emulate.c
 create mode 100644 arch/arm64/kvm/guest.c
 create mode 100644 arch/arm64/kvm/handle_exit.c
 create mode 100644 arch/arm64/kvm/hyp-init.S
 create mode 100644 arch/arm64/kvm/hyp.S
 create mode 100644 arch/arm64/kvm/inject_fault.c
 create mode 100644 arch/arm64/kvm/regmap.c
 create mode 100644 arch/arm64/kvm/reset.c
 create mode 100644 arch/arm64/kvm/sys_regs.c
 create mode 100644 arch/arm64/kvm/sys_regs.h
 create mode 100644 arch/arm64/kvm/sys_regs_generic_v8.c
 create mode 100644 arch/arm64/mm/hugetlbpage.c
 create mode 100644 arch/arm64/xen/Makefile
 create mode 100644 arch/arm64/xen/hypercall.S

-- 
Catalin


From b.zolnierkie at samsung.com  Mon Jul  1 13:24:16 2013
From: b.zolnierkie at samsung.com (Bartlomiej Zolnierkiewicz)
Date: Mon, 01 Jul 2013 19:24:16 +0200
Subject: [PATCH] DMA: Fix Marvell Orion and mv_xor after MEMSET removal
In-Reply-To: <20130701151720.GC19937@titan.lakedaemon.net>
References: <1372690589-2218-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <51D19CD1.3030900@gmail.com> <20130701151720.GC19937@titan.lakedaemon.net>
Message-ID: <6583540.4QCOENPlIG@amdc1032>


Hi,

On Monday, July 01, 2013 11:17:20 AM Jason Cooper wrote:
> On Mon, Jul 01, 2013 at 05:14:25PM +0200, Sebastian Hesselbarth wrote:
> > On 07/01/13 17:04, Jason Cooper wrote:
> > >On Mon, Jul 01, 2013 at 04:56:29PM +0200, Sebastian Hesselbarth wrote:
> > >>Commit 834cbfe966bece50afded79da8e975d255bf0772
> > >>  ("drivers/dma: remove unused support for MEMSET operations")
> > >>removes MEMSET from dmaengine but does not completely removes it from
> > >>Marvell Orion (arch/arm/plat-orion) and XOR (drivers/dma/mv_xor).
> > >>This also fixes some compiler warnings about now obsolete functions by
> > >>removing those.
> > >>
> > >>Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> > >>---
> > >>Cc: Jason Cooper <jason at lakedaemon.net>
> > >>Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
> > >>Cc: Kyungmin Park <kyungmin.park at samsung.com>
> > >>Cc: Andrew Morton <akpm at linux-foundation.org>
> > >>Cc: linux-arm-kernel at lists.infradead.org
> > >>Cc: linux-kernel at vger.kernel.org
> > >>---
> > >>  arch/arm/plat-orion/common.c |    6 ------
> > >>  drivers/dma/mv_xor.c         |   25 +------------------------
> > >>  2 files changed, 1 insertions(+), 30 deletions(-)
> > >
> > >Please take a look at the email from lkml I just forwarded to you.  I
> > >believe this solves your problem, but I don't have time to look closely
> > >atm.
> > 
> > Jason,
> > 
> > I have seen the forwarded patch before. I don't know what version this
> > is based on. Some of the modifications are in next-20130701, some are
> > not. I have stripped the Marvell modifications from the patch you
> > forwarded and fixed all remaining issues.
> > 
> > Also, I will sent a follow-up patch to remove memset references from
> > Marvell SoC dts/dtsi and the binding documentation soon.
> > 
> > I guess, Bartolomiej should pick them up and resend his patch set, or
> > leave Marvell alone and you pick them up.
> 
> If Bartolomiej doesn't take it, please split your changes into two
> patches, one for plat-orion, and one for drivers.

Andrew has already applied incremental patch fixing build problems to his
tree (though it is not yet in linux-next):

	http://www.ozlabs.org/~akpm/mmots/broken-out/drivers-dma-remove-unused-support-for-memset-operations-v3.patch

The rest of changes from Sebastian are contained in another incremental
patch which I've attached to this mail. They can be also folded into
the first patch (which is what Andrew will probably do before sending them
to Linus).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics


From: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
Subject: [PATCH] DMA: Fix mv_xor after MEMSET removal

Commit 834cbfe ("drivers/dma: remove unused support for MEMSET operations")
removes MEMSET from dmaengine but does not completely removes it from
drivers/dma/mv_xor.

This also fixes some compiler warnings about now obsolete functions by
removing those.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
[bzolnier: splitted off changes from bigger patch]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Kyungmin Park <kyungmin.park at samsung.com>
Cc: Andrew Morton <akpm at linux-foundation.org>
---
 drivers/dma/mv_xor.c |   23 +----------------------
 1 file changed, 1 insertion(+), 22 deletions(-)

Index: b/drivers/dma/mv_xor.c
===================================================================
--- a/drivers/dma/mv_xor.c	2013-07-01 18:53:12.113317468 +0200
+++ b/drivers/dma/mv_xor.c	2013-07-01 18:56:07.273317119 +0200
@@ -89,11 +89,6 @@ static void mv_desc_clear_next_desc(stru
 	hw_desc->phy_next_desc = 0;
 }
 
-static void mv_desc_set_block_fill_val(struct mv_xor_desc_slot *desc, u32 val)
-{
-	desc->value = val;
-}
-
 static void mv_desc_set_dest_addr(struct mv_xor_desc_slot *desc,
 				  dma_addr_t addr)
 {
@@ -128,22 +123,6 @@ static void mv_chan_set_next_descriptor(
 	__raw_writel(next_desc_addr, XOR_NEXT_DESC(chan));
 }
 
-static void mv_chan_set_dest_pointer(struct mv_xor_chan *chan, u32 desc_addr)
-{
-	__raw_writel(desc_addr, XOR_DEST_POINTER(chan));
-}
-
-static void mv_chan_set_block_size(struct mv_xor_chan *chan, u32 block_size)
-{
-	__raw_writel(block_size, XOR_BLOCK_SIZE(chan));
-}
-
-static void mv_chan_set_value(struct mv_xor_chan *chan, u32 value)
-{
-	__raw_writel(value, XOR_INIT_VALUE_LOW(chan));
-	__raw_writel(value, XOR_INIT_VALUE_HIGH(chan));
-}
-
 static void mv_chan_unmask_interrupts(struct mv_xor_chan *chan)
 {
 	u32 val = __raw_readl(XOR_INTR_MASK(chan));
@@ -1134,7 +1113,7 @@ mv_xor_channel_add(struct mv_xor_device
 			goto err_free_irq;
 	}
 
-	dev_info(&pdev->dev, "Marvell XOR: ( %s%s%s%s)\n",
+	dev_info(&pdev->dev, "Marvell XOR: ( %s%s%s)\n",
 		 dma_has_cap(DMA_XOR, dma_dev->cap_mask) ? "xor " : "",
 		 dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask) ? "cpy " : "",
 		 dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask) ? "intr " : "");



From sebastian.hesselbarth at gmail.com  Mon Jul  1 13:29:50 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 01 Jul 2013 19:29:50 +0200
Subject: [PATCH] DMA: Fix Marvell Orion and mv_xor after MEMSET removal
In-Reply-To: <6583540.4QCOENPlIG@amdc1032>
References: <1372690589-2218-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <51D19CD1.3030900@gmail.com> <20130701151720.GC19937@titan.lakedaemon.net>
 <6583540.4QCOENPlIG@amdc1032>
Message-ID: <51D1BC8E.6000204@gmail.com>

On 07/01/13 19:24, Bartlomiej Zolnierkiewicz wrote:
> On Monday, July 01, 2013 11:17:20 AM Jason Cooper wrote:
>> On Mon, Jul 01, 2013 at 05:14:25PM +0200, Sebastian Hesselbarth wrote:
>>> On 07/01/13 17:04, Jason Cooper wrote:
>>>> On Mon, Jul 01, 2013 at 04:56:29PM +0200, Sebastian Hesselbarth wrote:
>>> Also, I will sent a follow-up patch to remove memset references from
>>> Marvell SoC dts/dtsi and the binding documentation soon.
>>>
>>> I guess, Bartolomiej should pick them up and resend his patch set, or
>>> leave Marvell alone and you pick them up.
>>
>> If Bartolomiej doesn't take it, please split your changes into two
>> patches, one for plat-orion, and one for drivers.
>
> Andrew has already applied incremental patch fixing build problems to his
> tree (though it is not yet in linux-next):
>
> 	http://www.ozlabs.org/~akpm/mmots/broken-out/drivers-dma-remove-unused-support-for-memset-operations-v3.patch
>
> The rest of changes from Sebastian are contained in another incremental
> patch which I've attached to this mail. They can be also folded into
> the first patch (which is what Andrew will probably do before sending them
> to Linus).

Ok, great! Then I will sent the DT clean-up patches to be taken through
Jason's tree with the other stuff I have for v3.11-rc1.

Sebastian


From marex at denx.de  Mon Jul  1 13:43:27 2013
From: marex at denx.de (Marek Vasut)
Date: Mon, 1 Jul 2013 19:43:27 +0200
Subject: [alsa-devel] [PATCH 1/4] ASoC: sgtl5000: give it a ramping time
 before writting
In-Reply-To: <CAOMZO5B5jh1XciO4K1u3yBcHHDAgi8hA3GcywnJd11M7=aOPxA@mail.gmail.com>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <20130701153327.GX13206@S2101-09.ap.freescale.net>
 <CAOMZO5B5jh1XciO4K1u3yBcHHDAgi8hA3GcywnJd11M7=aOPxA@mail.gmail.com>
Message-ID: <201307011943.27489.marex@denx.de>

Dear Fabio Estevam,

> On Mon, Jul 1, 2013 at 12:33 PM, Shawn Guo <shawn.guo at linaro.org> wrote:
> > On Mon, Jul 01, 2013 at 12:11:58PM -0300, Fabio Estevam wrote:
> >> On Mon, Jul 1, 2013 at 11:34 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> >> > And also why we do not see the impact of i2c issue on sgtl5000 before
> >> > the offending commit af8ee11 (ASoC: sgtl5000: Fix driver probe after
> >> > reset)?
> >> 
> >> Probably because the mxs i2c was working before this commit.
> > 
> > Do you have a commit id at which mxs i2c is known good?  I would like to
> > find out it's a mxs i2c issue or sgtl5000 problem.
> 
> I don't have it, but I am adding Alexandre in case he knows.
> 
> Alexandre,
> 
> Do you happen to know a commit id which does not show the mxs i2c
> timeouts you have been observing?

I think you can just disable the PIO mode altogether (around line 500 ... if 
(msg->len < 8) ... replace this with if (0) ) and then the problem should not be 
there (if it's a PIO problem).

Best regards,
Marek Vasut


From swarren at wwwdotorg.org  Mon Jul  1 13:38:53 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 01 Jul 2013 11:38:53 -0600
Subject: [PATCH V3 0/3] ARM: tegra114: cpuidle: add power down state
In-Reply-To: <1372152242-16373-1-git-send-email-josephl@nvidia.com>
References: <1372152242-16373-1-git-send-email-josephl@nvidia.com>
Message-ID: <51D1BEAD.6060003@wwwdotorg.org>

On 06/25/2013 03:23 AM, Joseph Lo wrote:
> This series introduce CPU core power down state for CPU idle. When CPU go
> into this state, it saves it's context and needs a proper configuration
> in flow controller to power gate the CPU when CPU runs into WFI
> instruction. And the CPU also needs to set the IRQ as CPU power down idle
> wake up event in flow controller.
> 
> To prevent race conditions and ensure proper interrupt routing on
> Cortex-A15 CPUs when they are power-gated, add a CPU PM notifier
> call-back to reprogram the GIC CPU interface on PM entry. The
> GIC CPU interface will be reset back to its normal state by
> the common GIC CPU PM exit callback when the CPU wakes up.
> 
> This series depends on the patch of "tick:  Fix
> tick_broadcast_pending_mask not cleared".

Joseph, I applied all 3 of your patches/series on top of next-20130701,
which does include dependency "tick:  Fix tick_broadcast_pending_mask
not cleared":

* ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
* This series
* ARM: tegra114: add support for system suspend

I find that at least on on Tegra114/Dalmore, CPU hotplug doesn't work
correctly.

If I unplug CPU0, I get an immediate system hang:

root at localhost:~# ./cpuonline.py
echo 0 > /sys/devices/system/cpu/cpu0/online
[   73.555696] IRQ73 no longer affine to CPU0
[   73.561965] CPU0: shutdown

If I adjust my script not to hotplug CPU0, I get a hang when plugging a
CPU back in:

root at localhost:~# ./cpuonline.py
echo 0 > /sys/devices/system/cpu/cpu2/online
[   87.141128] CPU2: shutdown
echo 0 > /sys/devices/system/cpu/cpu1/online
[   89.227597] CPU1: shutdown
echo 0 > /sys/devices/system/cpu/cpu3/online
[   91.253870] CPU3: shutdown
echo 1 > /sys/devices/system/cpu/cpu1/online

or simpler:

root at localhost:~# echo 0 > /sys/devices/system/cpu/cpu1/online
[   80.767825] CPU1: shutdown
root at localhost:~# echo 1 > /sys/devices/system/cpu/cpu1/online

Finally, if I boot afresh and enter system suspend, I see the system
suspend OK, but pressing the power button on either the board itself or
the attached PM342 debug board will not wake the system from sleep.


From tglx at linutronix.de  Mon Jul  1 13:55:15 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 1 Jul 2013 19:55:15 +0200 (CEST)
Subject: [PATCH v4] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <1372687359-18235-1-git-send-email-jonas.jensen@gmail.com>
References: <1372332203-30228-1-git-send-email-jonas.jensen@gmail.com>
 <1372687359-18235-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <alpine.DEB.2.02.1307011953390.4013@ionos.tec.linutronix.de>

On Mon, 1 Jul 2013, Jonas Jensen wrote:
> +static int moxart_clkevt_next_event(unsigned long cycles,
> +				    struct clock_event_device *unused)
> +{
> +	u32 u;
> +
> +	u = readl(base + TIMER_CR) & ~TIMEREG_CR_1_ENABLE;

You should cache that value and avoid another readout below. You could
even cache it in general so you avoid all readouts.

> +	writel(u, base + TIMER_CR);
> +	u = readl(base + TIMER1_BASE + REG_COUNT) - cycles;
> +	writel(u, base + TIMER1_BASE + REG_MATCH1);
> +	u = readl(base + TIMER_CR) | TIMEREG_CR_1_ENABLE;
> +	writel(u, base + TIMER_CR);
> +	return 0;
> +}

Thanks,

	tglx


From santosh.shilimkar at ti.com  Mon Jul  1 14:20:35 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 1 Jul 2013 14:20:35 -0400
Subject: [PATCH v2] of: Specify initrd location using 64-bit
Message-ID: <1372702835-5333-1-git-send-email-santosh.shilimkar@ti.com>

On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit.  These systems need the ability to specify the
initrd location using 64-bit numbers.

This patch globally modifies the early_init_dt_setup_initrd_arch() function to
use 64-bit numbers instead of the current unsigned long.

There has been quite a bit of debate about whether to use u64 or phys_addr_t.
It was concluded to stick to u64 to be consistent with rest of the device
tree code. As summarized by Geert, "The address to load the initrd is decided
by the bootloader/user and set at that point later in time. The dtb should not
be tied to the kernel you are booting"

More details on the discussion can be found here:
https://lkml.org/lkml/2013/6/20/690
https://lkml.org/lkml/2012/9/13/544

Cc: Grant Likely <grant.likely at linaro.org>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Geert Uytterhoeven <geert at linux-m68k.org>
Cc: Sebastian Andrzej Siewior <bigeasy at linutronix.de>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: Vineet Gupta <vgupta at synopsys.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Mark Salter <msalter at redhat.com>
Cc: Aurelien Jacquiot <a-jacquiot at ti.com>
Cc: James Hogan <james.hogan at imgtec.com>
Cc: Michal Simek <monstr at monstr.eu>
Cc: Ralf Baechle <ralf at linux-mips.org>
Cc: Jonas Bonn <jonas at southpole.se>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: x86 at kernel.org
Cc: arm at kernel.org
Cc: Chris Zankel <chris at zankel.net>
Cc: Max Filippov <jcmvbkbc at gmail.com>
Cc: bigeasy at linutronix.de
Cc: robherring2 at gmail.com
Cc: Nicolas Pitre <nicolas.pitre at linaro.org>

Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-c6x-dev at linux-c6x.org
Cc: linux-mips at linux-mips.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-xtensa at linux-xtensa.org
Cc: devicetree-discuss at lists.ozlabs.org

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arc/mm/init.c            |    5 ++---
 arch/arm/mm/init.c            |    2 +-
 arch/arm64/mm/init.c          |    3 +--
 arch/c6x/kernel/devicetree.c  |    3 +--
 arch/metag/mm/init.c          |    5 ++---
 arch/microblaze/kernel/prom.c |    3 +--
 arch/mips/kernel/prom.c       |    3 +--
 arch/openrisc/kernel/prom.c   |    3 +--
 arch/powerpc/kernel/prom.c    |    3 +--
 arch/x86/kernel/devicetree.c  |    3 +--
 arch/xtensa/kernel/setup.c    |    3 +--
 drivers/of/fdt.c              |   10 ++++++----
 include/linux/of_fdt.h        |    3 +--
 13 files changed, 20 insertions(+), 29 deletions(-)

diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
index 4a17736..7991e08 100644
--- a/arch/arc/mm/init.c
+++ b/arch/arc/mm/init.c
@@ -157,9 +157,8 @@ void __init free_initrd_mem(unsigned long start, unsigned long end)
 #endif
 
 #ifdef CONFIG_OF_FLATTREE
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
-					    unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
 {
-	pr_err("%s(%lx, %lx)\n", __func__, start, end);
+	pr_err("%s(%llx, %llx)\n", __func__, start, end);
 }
 #endif /* CONFIG_OF_FLATTREE */
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 9a5cdc0..afeaef7 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -76,7 +76,7 @@ static int __init parse_tag_initrd2(const struct tag *tag)
 __tagtable(ATAG_INITRD2, parse_tag_initrd2);
 
 #ifdef CONFIG_OF_FLATTREE
-void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
 {
 	phys_initrd_start = start;
 	phys_initrd_size = end - start;
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f497ca7..7047708 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -44,8 +44,7 @@ static unsigned long phys_initrd_size __initdata = 0;
 
 phys_addr_t memstart_addr __read_mostly = 0;
 
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
-					    unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
 {
 	phys_initrd_start = start;
 	phys_initrd_size = end - start;
diff --git a/arch/c6x/kernel/devicetree.c b/arch/c6x/kernel/devicetree.c
index bdb56f0..287d0e6 100644
--- a/arch/c6x/kernel/devicetree.c
+++ b/arch/c6x/kernel/devicetree.c
@@ -33,8 +33,7 @@ void __init early_init_devtree(void *params)
 
 
 #ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
-		unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
 {
 	initrd_start = (unsigned long)__va(start);
 	initrd_end = (unsigned long)__va(end);
diff --git a/arch/metag/mm/init.c b/arch/metag/mm/init.c
index d05b845..bdc4811 100644
--- a/arch/metag/mm/init.c
+++ b/arch/metag/mm/init.c
@@ -419,10 +419,9 @@ void free_initrd_mem(unsigned long start, unsigned long end)
 #endif
 
 #ifdef CONFIG_OF_FLATTREE
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
-					    unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
 {
-	pr_err("%s(%lx, %lx)\n",
+	pr_err("%s(%llx, %llx)\n",
 	       __func__, start, end);
 }
 #endif /* CONFIG_OF_FLATTREE */
diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
index 0a2c68f..62e2e8f 100644
--- a/arch/microblaze/kernel/prom.c
+++ b/arch/microblaze/kernel/prom.c
@@ -136,8 +136,7 @@ void __init early_init_devtree(void *params)
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
-		unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
 {
 	initrd_start = (unsigned long)__va(start);
 	initrd_end = (unsigned long)__va(end);
diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
index 5712bb5..32b8788 100644
--- a/arch/mips/kernel/prom.c
+++ b/arch/mips/kernel/prom.c
@@ -58,8 +58,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
-					    unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
 {
 	initrd_start = (unsigned long)__va(start);
 	initrd_end = (unsigned long)__va(end);
diff --git a/arch/openrisc/kernel/prom.c b/arch/openrisc/kernel/prom.c
index 5869e3f..150215a 100644
--- a/arch/openrisc/kernel/prom.c
+++ b/arch/openrisc/kernel/prom.c
@@ -96,8 +96,7 @@ void __init early_init_devtree(void *params)
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
-		unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
 {
 	initrd_start = (unsigned long)__va(start);
 	initrd_end = (unsigned long)__va(end);
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 8b6f7a9..2f3e252 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -550,8 +550,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
-		unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
 {
 	initrd_start = (unsigned long)__va(start);
 	initrd_end = (unsigned long)__va(end);
diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index b158152..2fbad6b 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -52,8 +52,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
-					    unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
 {
 	initrd_start = (unsigned long)__va(start);
 	initrd_end = (unsigned long)__va(end);
diff --git a/arch/xtensa/kernel/setup.c b/arch/xtensa/kernel/setup.c
index 6dd25ec..d45e602 100644
--- a/arch/xtensa/kernel/setup.c
+++ b/arch/xtensa/kernel/setup.c
@@ -170,8 +170,7 @@ static int __init parse_tag_fdt(const bp_tag_t *tag)
 
 __tagtable(BP_TAG_FDT, parse_tag_fdt);
 
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
-		unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
 {
 	initrd_start = (void *)__va(start);
 	initrd_end = (void *)__va(end);
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 808be06..21123b8 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -550,7 +550,8 @@ int __init of_flat_dt_match(unsigned long node, const char *const *compat)
  */
 void __init early_init_dt_check_for_initrd(unsigned long node)
 {
-	unsigned long start, end, len;
+	u64 start, end;
+	unsigned long len;
 	__be32 *prop;
 
 	pr_debug("Looking for initrd properties... ");
@@ -558,15 +559,16 @@ void __init early_init_dt_check_for_initrd(unsigned long node)
 	prop = of_get_flat_dt_prop(node, "linux,initrd-start", &len);
 	if (!prop)
 		return;
-	start = of_read_ulong(prop, len/4);
+	start = of_read_number(prop, len/4);
 
 	prop = of_get_flat_dt_prop(node, "linux,initrd-end", &len);
 	if (!prop)
 		return;
-	end = of_read_ulong(prop, len/4);
+	end = of_read_number(prop, len/4);
 
 	early_init_dt_setup_initrd_arch(start, end);
-	pr_debug("initrd_start=0x%lx  initrd_end=0x%lx\n", start, end);
+	pr_debug("initrd_start=0x%llx  initrd_end=0x%llx\n",
+		 (unsigned long long)start, (unsigned long long)end);
 }
 #else
 inline void early_init_dt_check_for_initrd(unsigned long node)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index ed136ad..4a17939 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -106,8 +106,7 @@ extern u64 dt_mem_next_cell(int s, __be32 **cellp);
  * physical addresses.
  */
 #ifdef CONFIG_BLK_DEV_INITRD
-extern void early_init_dt_setup_initrd_arch(unsigned long start,
-					    unsigned long end);
+extern void early_init_dt_setup_initrd_arch(u64 start, u64 end);
 #endif
 
 /* Early flat tree scan hooks */
-- 
1.7.9.5



From sergei.shtylyov at cogentembedded.com  Mon Jul  1 14:22:21 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 01 Jul 2013 22:22:21 +0400
Subject: [PATCH] N900: fix operation on emulator
In-Reply-To: <20130701140315.GA15318@amd.pavel.ucw.cz>
References: <20130613132624.GA3464@amd.pavel.ucw.cz>
 <20130613141001.GF8164@atomide.com> <20130613142809.GA3775@amd.pavel.ucw.cz>
 <20130613145724.GH8164@atomide.com> <20130613155240.GB3775@amd.pavel.ucw.cz>
 <20130613161418.GJ8164@atomide.com> <20130613230808.GA14876@amd.pavel.ucw.cz>
 <20130614055629.GM8164@atomide.com>
 <20130614212816.GA31768@atrey.karlin.mff.cuni.cz>
 <20130617111031.GQ20992@atomide.com>
 <20130701140315.GA15318@amd.pavel.ucw.cz>
Message-ID: <51D1C8DD.6040409@cogentembedded.com>

Hello.

On 07/01/2013 06:03 PM, Pavel Machek wrote:

> Errata workarounds for N900 hardware actually break operation on
> emulator. Fix it.

> This approach was suggested by Pali Roh?r <pali.rohar at gmail.com>
> (thanks!).

> (Also explain what "sleep_ind" led actually does).

    Looks like unrelated change and probably worth another patch?

> Signed-off-by: Pavel Machek <pavel at ucw.cz>

> diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
> index 74f83a5..81f7b9f 100644
> --- a/arch/arm/mach-omap2/board-rx51.c
> +++ b/arch/arm/mach-omap2/board-rx51.c
> @@ -33,9 +33,12 @@
>   #include "pm.h"
>   #include "sdram-nokia.h"
>   #include "board-rx51-secure.h"
> +#include "soc.h"
>
>   #define RX51_GPIO_SLEEP_IND 162
>
> +/* This lights up left part of keyboard */
> +
>   static struct gpio_led gpio_leds[] = {
>   	{
>   		.name	= "sleep_ind",
> @@ -107,9 +110,11 @@ static void __init rx51_init(void)
>   	rx51_camera_init();
>
>   #ifdef CONFIG_ARM_ERRATA_430973
> -	printk(KERN_INFO "RX-51: Enabling ARM errata 430973 workaround.\n");
> -	/* set IBE to 1 */
> -	rx51_secure_update_aux_cr(1 << 6, 0);
> +	if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
> +		printk(KERN_INFO "RX-51: Enabling ARM errata 430973 workaround.\n");

    How about pr_info() instead?

WBR, Sergei



From broonie at kernel.org  Mon Jul  1 15:06:26 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 1 Jul 2013 20:06:26 +0100
Subject: [PATCH v5 1/4] clk: hi3xxx: add clock support
In-Reply-To: <20130617215039.GM28497@quad.lixom.net>
References: <1371459376-25438-1-git-send-email-haojian.zhuang@linaro.org>
 <1371459376-25438-2-git-send-email-haojian.zhuang@linaro.org>
 <20130617215039.GM28497@quad.lixom.net>
Message-ID: <20130701190626.GM27646@sirena.org.uk>

On Mon, Jun 17, 2013 at 02:50:39PM -0700, Olof Johansson wrote:

> > +   hisilicon,clkdiv-table property.
> > + - hisilicon,clkdiv-table : list of value that are used to configure clock

> For a binding that is your own, you don't need to prefix the properties.
> Prefixes are mostly used when adding new vendor-specific attributes to a common
> binding.

People seem to be *very* keen on adding them for all bindings for some
reason.
-------------- 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/20130701/d8c039f1/attachment.sig>

From festevam at gmail.com  Mon Jul  1 15:14:14 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 1 Jul 2013 16:14:14 -0300
Subject: [alsa-devel] [PATCH 1/4] ASoC: sgtl5000: give it a ramping time
 before writting
In-Reply-To: <201307011943.27489.marex@denx.de>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <20130701153327.GX13206@S2101-09.ap.freescale.net>
 <CAOMZO5B5jh1XciO4K1u3yBcHHDAgi8hA3GcywnJd11M7=aOPxA@mail.gmail.com>
 <201307011943.27489.marex@denx.de>
Message-ID: <CAOMZO5DtgahX3WLdM-P9=ODhJVMTRHFuS9=6zHQiS9-3wCJcmA@mail.gmail.com>

Hi Marek,

On Mon, Jul 1, 2013 at 2:43 PM, Marek Vasut <marex at denx.de> wrote:

> I think you can just disable the PIO mode altogether (around line 500 ... if
> (msg->len < 8) ... replace this with if (0) ) and then the problem should not be
> there (if it's a PIO problem).

Yes, this is a good suggestion.

This is what I did on 3.10 kernel:

- Booted a 3.10 kernel, audio is probed correctly

- Enabled touchscreen:

--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -181,6 +181,7 @@

                        lradc at 80050000 {
                                status = "okay";
+                               fsl,lradc-touchscreen-wires = <4>;
                        };


Then audio fails to probe:

[    3.854263] sgtl5000 0-000a: Device with ID register 0 is not a sgtl5000
[    5.875286] sgtl5000 0-000a: ASoC: failed to probe CODEC -19
[    5.881522] mxs-sgtl5000 sound.12: ASoC: failed to instantiate card -19
[    5.891010] mxs-sgtl5000 sound.12: snd_soc_register_card failed (-19)

- Removed PIO from i2c, then audio probes again

--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -494,7 +494,7 @@ static int mxs_i2c_xfer_msg(struct i2c_adapter
*adap, struct i2c_msg *msg,
         * based on this empirical measurement and a lot of previous frobbing.
         */
        i2c->cmd_err = 0;
-       if (msg->len < 8) {
+       if (0) {
                ret = mxs_i2c_pio_setup_xfer(adap, msg, flags);
                if (ret)
                        mxs_i2c_reset(i2c);

Really don't know why enabling the touchscreen triggers the i2c error
during the codec reading though.


From alexandre.belloni at free-electrons.com  Mon Jul  1 15:23:22 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Mon, 01 Jul 2013 21:23:22 +0200
Subject: [alsa-devel] [PATCH 1/4] ASoC: sgtl5000: give it a ramping time
 before writting
In-Reply-To: <CAOMZO5B5jh1XciO4K1u3yBcHHDAgi8hA3GcywnJd11M7=aOPxA@mail.gmail.com>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <1372666571-17276-2-git-send-email-shawn.guo@linaro.org>
 <20130701100710.GB27646@sirena.org.uk> <201307011254.18952.marex@denx.de>
 <CAOMZO5BAs5-Tf_O0TVLFAuCchVuukV+bH2MpjqMU83tTw2GD=Q@mail.gmail.com>
 <20130701142610.GR13206@S2101-09.ap.freescale.net>
 <20130701143415.GA14172@S2101-09.ap.freescale.net>
 <CAOMZO5Bh5CZLBO-epVA9Vivo-mqmBJZhy7iA6HiMy+xLzDj40w@mail.gmail.com>
 <20130701153327.GX13206@S2101-09.ap.freescale.net>
 <CAOMZO5B5jh1XciO4K1u3yBcHHDAgi8hA3GcywnJd11M7=aOPxA@mail.gmail.com>
Message-ID: <51D1D72A.4090004@free-electrons.com>

On 01/07/2013 17:42, Fabio Estevam wrote:
> On Mon, Jul 1, 2013 at 12:33 PM, Shawn Guo <shawn.guo at linaro.org> wrote:
>> On Mon, Jul 01, 2013 at 12:11:58PM -0300, Fabio Estevam wrote:
>>> On Mon, Jul 1, 2013 at 11:34 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
>>>
>>>> And also why we do not see the impact of i2c issue on sgtl5000 before
>>>> the offending commit af8ee11 (ASoC: sgtl5000: Fix driver probe after
>>>> reset)?
>>>
>>> Probably because the mxs i2c was working before this commit.
>>
>> Do you have a commit id at which mxs i2c is known good?  I would like to
>> find out it's a mxs i2c issue or sgtl5000 problem.
> 
> I don't have it, but I am adding Alexandre in case he knows.
> 
> Alexandre,
> 
> Do you happen to know a commit id which does not show the mxs i2c
> timeouts you have been observing?
> 

the closest I have is that 3.7 was ok but 3.9 is broken. In the meant
time, Marek did rewrite the whole stuff ;)

>>
>>>
>>> Commit af8ee11 does fix the reset probe on mx51/mx53/mx6.
>>>
>>> It's only on mx28 that we have this issue.
>>>
>>> Also, please see this patch from Alexandre Belloni:
>>> https://lkml.org/lkml/2013/6/24/430
>>>
>>> He can only connect the ADC chip if he uses I2C bitbang mode on mx28.
>>
>> Does I2C bitbang mode help fix the sgtl5000 issue here?
> 
> I haven't made this test.
> 


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From alexandre.belloni at free-electrons.com  Mon Jul  1 15:28:26 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Mon, 01 Jul 2013 21:28:26 +0200
Subject: [alsa-devel] [PATCH 1/4] ASoC: sgtl5000: give it a ramping time
 before writting
In-Reply-To: <CAOMZO5DtgahX3WLdM-P9=ODhJVMTRHFuS9=6zHQiS9-3wCJcmA@mail.gmail.com>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <20130701153327.GX13206@S2101-09.ap.freescale.net>
 <CAOMZO5B5jh1XciO4K1u3yBcHHDAgi8hA3GcywnJd11M7=aOPxA@mail.gmail.com>
 <201307011943.27489.marex@denx.de>
 <CAOMZO5DtgahX3WLdM-P9=ODhJVMTRHFuS9=6zHQiS9-3wCJcmA@mail.gmail.com>
Message-ID: <51D1D85A.8060807@free-electrons.com>

Hi,

On 01/07/2013 21:14, Fabio Estevam wrote:
> Hi Marek,
> 
> On Mon, Jul 1, 2013 at 2:43 PM, Marek Vasut <marex at denx.de> wrote:
> 
>> I think you can just disable the PIO mode altogether (around line 500 ... if
>> (msg->len < 8) ... replace this with if (0) ) and then the problem should not be
>> there (if it's a PIO problem).
> 
> Yes, this is a good suggestion.
> 
> This is what I did on 3.10 kernel:
> 
> - Booted a 3.10 kernel, audio is probed correctly
> 
> - Enabled touchscreen:
> 

It definitely seems to be an issue with PIO mode as the investigation
from Torsten Fleischer showed. I'll test that on my boards tonight. I'll
also try to remove the touchscreen support to see if I observe the same
thing as you do.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From coelho at ti.com  Mon Jul  1 15:34:10 2013
From: coelho at ti.com (Luciano Coelho)
Date: Mon, 1 Jul 2013 22:34:10 +0300
Subject: [RFC] wlcore: sdio: add wilink clock providers
Message-ID: <1372707250-11998-1-git-send-email-coelho@ti.com>

Add refclock and tcxoclock as clock providers in WiLink.  These clocks
are not accesible outside the WiLink module, but they are registered
in the clock framework anyway.  Only the WiLink chip consumes these
clocks.

In theory, the WiLink chip could be connected to external clocks
instead of using these internal clocks, so make the clock consumer
code generic enough.  If external clocks are used, then the internal
clock device tree nodes are not necessary, but the external ones must
be specified.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---

Hi,

I came up with this code, trying to make the WiLink clocks definitions
as generic as possible and use existing fixed-clock bindings.  This
looks relatively clean to me, even though it adds some complexity.
But I think it's better than the original bindings I had defined.

I still need to take care of the XTAL/not-XTAl boolean, but I will do
that separately.

This patch will be split (to take away the Panda DTS part) and
squashed in other patches in my series.

Please let me know what you think.

--
Cheers,
Luca.

 arch/arm/boot/dts/omap4-panda-common.dtsi |   16 ++++++++---
 drivers/net/wireless/ti/wlcore/sdio.c     |   43 ++++++++++++++++++++++++++---
 2 files changed, 51 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 670c3ce..7f061b8 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -65,11 +65,19 @@
 		enable-active-high;
 	};
 
+
 	wlan {
-	     compatible = "ti,wilink6";
-	     interrupt-parent = <&gpio2>;
-	     interrupts = <21 0x4>;	/* gpio line 53, high level triggered */
-	     refclock = <2>;		/* 38.4 MHz */
+		compatible = "ti,wilink6";
+		interrupt-parent = <&gpio2>;
+		interrupts = <21 0x4>;	/* gpio line 53, high level triggered */
+		clocks = <&refclock>;
+		clock-names = "refclock";
+
+		refclock: refclock {
+			compatible = "ti,wilink-clock";
+			#clock-cells = <0>;
+			clock-frequency = <38400000>;
+		};
 	 };
 };
 
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 5b08620..60fce49 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,7 @@
 #include <linux/wl12xx.h>
 #include <linux/pm_runtime.h>
 #include <linux/printk.h>
+#include <linux/clk-provider.h>
 
 #include "wlcore.h"
 #include "wl12xx_80211.h"
@@ -52,6 +53,7 @@ static bool dump = false;
 struct wl12xx_sdio_glue {
 	struct device *dev;
 	struct platform_device *core;
+	struct clk *refclock, *tcxoclock;
 };
 
 static const struct sdio_device_id wl1271_devices[] = {
@@ -214,10 +216,16 @@ static struct wl1271_if_operations sdio_ops = {
 	.set_block_size = wl1271_sdio_set_block_size,
 };
 
+static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
+	{ .compatible = "ti,wilink-clock" },
+};
+
 static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 {
 	struct wl12xx_platform_data *pdata;
 	struct device_node *np = dev->of_node;
+	struct device_node *clock_node;
+	struct wl12xx_sdio_glue *glue = sdio_get_drvdata(dev_to_sdio_func(dev));
 
 	if (!np) {
 		np = of_find_matching_node(NULL, dev->driver->of_match_table);
@@ -241,11 +249,28 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 		goto out_free;
 	}
 
+	for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
+		of_fixed_clk_setup(clock_node);
+
 	/* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
-	of_property_read_u32(np, "refclock", &pdata->ref_clock_freq);
+	glue->refclock = of_clk_get_by_name(np, "refclock");
+	if (IS_ERR(glue->refclock)) {
+		dev_err(dev, "couldn't find refclock on the device tree\n");
+		glue->refclock = NULL;
+	} else {
+		clk_prepare_enable(glue->refclock);
+		pdata->ref_clock_freq = clk_get_rate(glue->refclock);
+	}
 
 	/* TODO: make sure we have this when needed (ie. for WL7) */
-	of_property_read_u32(np, "tcxoclock", &pdata->tcxo_clock_freq);
+	glue->tcxoclock = of_clk_get_by_name(np, "tcxoclock");
+	if (IS_ERR(glue->tcxoclock)) {
+		dev_err(dev, "couldn't find tcxoclock on the device tree\n");
+		glue->tcxoclock = NULL;
+	} else {
+		clk_prepare_enable(glue->tcxoclock);
+		pdata->ref_clock_freq = clk_get_rate(glue->tcxoclock);
+	}
 
 	goto out;
 
@@ -291,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func,
 	/* Use block mode for transferring over one block size of data */
 	func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
+	sdio_set_drvdata(func, glue);
+
 	/* The pdata allocated here is freed when the device is freed,
 	 * so we don't need an additional out label to free it in case
 	 * of error further on.
@@ -316,8 +343,6 @@ static int wl1271_probe(struct sdio_func *func,
 	if (mmcflags & MMC_PM_KEEP_POWER)
 		pdev_data->pwr_in_suspend = true;
 
-	sdio_set_drvdata(func, glue);
-
 	/* Tell PM core that we don't need the card to be powered now */
 	pm_runtime_put_noidle(&func->dev);
 
@@ -384,6 +409,16 @@ static void wl1271_remove(struct sdio_func *func)
 {
 	struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
 
+	if (glue->refclock) {
+		clk_disable_unprepare(glue->refclock);
+		clk_put(glue->refclock);
+	}
+
+	if (glue->tcxoclock) {
+		clk_disable_unprepare(glue->tcxoclock);
+		clk_put(glue->tcxoclock);
+	}
+
 	/* Undo decrement done above in wl1271_probe */
 	pm_runtime_get_noresume(&func->dev);
 
-- 
1.7.10.4



From sylvester.nawrocki at gmail.com  Mon Jul  1 15:35:35 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 21:35:35 +0200
Subject: [PATCH V3 3/3] video: exynos_dp: Use the generic PHY driver
In-Reply-To: <005401ce761b$504d7090$f0e851b0$@samsung.com>
References: <005401ce761b$504d7090$f0e851b0$@samsung.com>
Message-ID: <51D1DA07.3010803@gmail.com>

Hi Jingoo,

On 07/01/2013 07:24 AM, Jingoo Han wrote:
> Use the generic PHY API instead of the platform callback to control
> the DP PHY. The 'phy_label' field is added to the platform data
> structure to allow PHY lookup on non-dt platforms.

Since Exynos is currently a dt-only platform upstream, how about
first making a pre-requisite patch that would remove support for
non-dt platforms from this driver ? I think you could now move the
content of file include/video/exynos_dp.h to e.g. drivers/video/
exynos/exynos_dp_core.h and remove the public exynos_dp.h file.
pdata->phy_init/exit could also be dropped and you wouldn't need
to care about non-dt support with the generic PHY API.

> Signed-off-by: Jingoo Han<jg1.han at samsung.com>
> Acked-by: Felipe Balbi<balbi at ti.com>
> ---
>   .../devicetree/bindings/video/exynos_dp.txt        |   23 +---
>   drivers/video/exynos/exynos_dp_core.c              |  118 ++------------------
>   drivers/video/exynos/exynos_dp_core.h              |    2 +
>   include/video/exynos_dp.h                          |    6 +-
>   4 files changed, 21 insertions(+), 128 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
> index 84f10c1..71645dc 100644
> --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> @@ -1,17 +1,6 @@
>   The Exynos display port interface should be configured based on
>   the type of panel connected to it.
>
> -We use two nodes:
> -	-dp-controller node
> -	-dptx-phy node(defined inside dp-controller node)
> -
> -For the DP-PHY initialization, we use the dptx-phy node.
> -Required properties for dptx-phy:
> -	-reg:
> -		Base address of DP PHY register.
> -	-samsung,enable-mask:
> -		The bit-mask used to enable/disable DP PHY.
> -
>   For the Panel initialization, we read data from dp-controller node.
>   Required properties for dp-controller:
>   	-compatible:
> @@ -25,6 +14,10 @@ Required properties for dp-controller:
>   		from common clock binding: handle to dp clock.
>   	-clock-names:
>   		from common clock binding: Shall be "dp".
> +	-phys:
> +		from general phy binding: the phandle for the PHY device.
> +	-phy-names:
> +		from general phy binding: Should be "dp".
>   	-interrupt-parent:
>   		phandle to Interrupt combiner node.
>   	-samsung,color-space:
> @@ -67,12 +60,8 @@ SOC specific portion:
>   		interrupt-parent =<&combiner>;
>   		clocks =<&clock 342>;
>   		clock-names = "dp";
> -
> -		dptx-phy {
> -			reg =<0x10040720>;
> -			samsung,enable-mask =<1>;
> -		};
> -
> +		phys =<&dp_phy>;
> +		phy-names = "dp";
>   	};
>
>   Board Specific portion:
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index 12bbede..bac515b 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -19,6 +19,7 @@
>   #include<linux/interrupt.h>
>   #include<linux/delay.h>
>   #include<linux/of.h>
> +#include<linux/phy/phy.h>
>
>   #include<video/exynos_dp.h>
>
> @@ -960,84 +961,15 @@ static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
>   		return ERR_PTR(-EINVAL);
>   	}
>
> -	return pd;
> -}
> -
> -static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
> -{
> -	struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
> -	u32 phy_base;
> -	int ret = 0;
> -
> -	dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
> -	if (!dp_phy_node) {
> -		dev_err(dp->dev, "could not find dptx-phy node\n");
> -		return -ENODEV;
> -	}
> -
> -	if (of_property_read_u32(dp_phy_node, "reg",&phy_base)) {
> -		dev_err(dp->dev, "failed to get reg for dptx-phy\n");
> -		ret = -EINVAL;
> -		goto err;
> -	}
> -
> -	if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
> -				&dp->enable_mask)) {
> -		dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
> -		ret = -EINVAL;
> -		goto err;
> -	}
> -
> -	dp->phy_addr = ioremap(phy_base, SZ_4);
> -	if (!dp->phy_addr) {
> -		dev_err(dp->dev, "failed to ioremap dp-phy\n");
> -		ret = -ENOMEM;
> -		goto err;
> -	}
> -
> -err:
> -	of_node_put(dp_phy_node);
> -
> -	return ret;
> -}
> -
> -static void exynos_dp_phy_init(struct exynos_dp_device *dp)
> -{
> -	u32 reg;
> -
> -	reg = __raw_readl(dp->phy_addr);
> -	reg |= dp->enable_mask;
> -	__raw_writel(reg, dp->phy_addr);
> -}
> -
> -static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
> -{
> -	u32 reg;
> +	pd->phy_label = "dp";
>
> -	reg = __raw_readl(dp->phy_addr);
> -	reg&= ~(dp->enable_mask);
> -	__raw_writel(reg, dp->phy_addr);
> +	return pd;
>   }

I'm afraid you cannot simply remove the above code, the original binding
still needs to be supported. As far as I can see Arndale and smdk5250 are
already users of that binding in mainline now.

Thus the benefits of adding the generic PHY support to this Display Port
controller driver are starting to be a bit questionable.

>   #else
>   static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
>   {
>   	return NULL;
>   }
> -
> -static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
> -{
> -	return -EINVAL;
> -}
> -
> -static void exynos_dp_phy_init(struct exynos_dp_device *dp)
> -{
> -	return;
> -}
> -
> -static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
> -{
> -	return;
> -}
>   #endif /* CONFIG_OF */

I think you could make the driver dependent on CONFIG_OF now and
related #ifdefs and !CONFIG_OF function stubs could be removed.

>   static int exynos_dp_probe(struct platform_device *pdev)
> @@ -1061,10 +993,6 @@ static int exynos_dp_probe(struct platform_device *pdev)
>   		pdata = exynos_dp_dt_parse_pdata(&pdev->dev);
>   		if (IS_ERR(pdata))
>   			return PTR_ERR(pdata);
> -
> -		ret = exynos_dp_dt_parse_phydata(dp);
> -		if (ret)
> -			return ret;
>   	} else {
>   		pdata = pdev->dev.platform_data;
>   		if (!pdata) {
> @@ -1073,6 +1001,10 @@ static int exynos_dp_probe(struct platform_device *pdev)
>   		}
>   	}
>
> +	dp->phy = devm_phy_get(&pdev->dev, pdata->phy_label);
> +	if (IS_ERR(dp->phy))
> +		return PTR_ERR(dp->phy);
> +
>   	dp->clock = devm_clk_get(&pdev->dev, "dp");
>   	if (IS_ERR(dp->clock)) {
>   		dev_err(&pdev->dev, "failed to get clock\n");
> @@ -1097,13 +1029,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
>
>   	dp->video_info = pdata->video_info;
>
> -	if (pdev->dev.of_node) {
> -		if (dp->phy_addr)
> -			exynos_dp_phy_init(dp);
> -	} else {
> -		if (pdata->phy_init)
> -			pdata->phy_init();
> -	}
> +	phy_power_on(dp->phy);
>
>   	exynos_dp_init_dp(dp);
>
> @@ -1121,42 +1047,27 @@ static int exynos_dp_probe(struct platform_device *pdev)
>
>   static int exynos_dp_remove(struct platform_device *pdev)
>   {
> -	struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
>   	struct exynos_dp_device *dp = platform_get_drvdata(pdev);
>
>   	flush_work(&dp->hotplug_work);
>
> -	if (pdev->dev.of_node) {
> -		if (dp->phy_addr)
> -			exynos_dp_phy_exit(dp);
> -	} else {
> -		if (pdata->phy_exit)
> -			pdata->phy_exit();
> -	}
> +	phy_power_off(dp->phy);
>
>   	clk_disable_unprepare(dp->clock);
>
> -
>   	return 0;
>   }
>
>   #ifdef CONFIG_PM_SLEEP
>   static int exynos_dp_suspend(struct device *dev)
>   {
> -	struct exynos_dp_platdata *pdata = dev->platform_data;
>   	struct exynos_dp_device *dp = dev_get_drvdata(dev);
>
>   	disable_irq(dp->irq);
>
>   	flush_work(&dp->hotplug_work);
>
> -	if (dev->of_node) {
> -		if (dp->phy_addr)
> -			exynos_dp_phy_exit(dp);
> -	} else {
> -		if (pdata->phy_exit)
> -			pdata->phy_exit();
> -	}
> +	phy_power_off(dp->phy);
>
>   	clk_disable_unprepare(dp->clock);
>
> @@ -1165,16 +1076,9 @@ static int exynos_dp_suspend(struct device *dev)
>
>   static int exynos_dp_resume(struct device *dev)
>   {
> -	struct exynos_dp_platdata *pdata = dev->platform_data;
>   	struct exynos_dp_device *dp = dev_get_drvdata(dev);
>
> -	if (dev->of_node) {
> -		if (dp->phy_addr)
> -			exynos_dp_phy_init(dp);
> -	} else {
> -		if (pdata->phy_init)
> -			pdata->phy_init();
> -	}
> +	phy_power_on(dp->phy);
>
>   	clk_prepare_enable(dp->clock);
>
> diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
> index 6c567bbf..b3d0328 100644
> --- a/drivers/video/exynos/exynos_dp_core.h
> +++ b/drivers/video/exynos/exynos_dp_core.h
> @@ -42,6 +42,8 @@ struct exynos_dp_device {
>   	struct video_info	*video_info;
>   	struct link_train	link_train;
>   	struct work_struct	hotplug_work;
> +
> +	struct phy		*phy;
>   };
>
>   /* exynos_dp_reg.c */
> diff --git a/include/video/exynos_dp.h b/include/video/exynos_dp.h
> index bd8cabd..f38c9af 100644
> --- a/include/video/exynos_dp.h
> +++ b/include/video/exynos_dp.h
> @@ -122,10 +122,8 @@ struct video_info {
>   };
>
>   struct exynos_dp_platdata {

Since Exynos doesn't support non-dt boot now this platform data structure
is not used, is it ?

> -	struct video_info *video_info;
> -
> -	void (*phy_init)(void);
> -	void (*phy_exit)(void);
> +	struct video_info	*video_info;
> +	const char		*phy_label;
>   };
>
>   #endif /* _EXYNOS_DP_H */

Regards,
Sylwester


From akpm at linux-foundation.org  Mon Jul  1 15:42:05 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Mon, 1 Jul 2013 12:42:05 -0700
Subject: [PATCH] DMA: Fix Marvell Orion and mv_xor after MEMSET removal
In-Reply-To: <20130701150407.GB19937@titan.lakedaemon.net>
References: <1372690589-2218-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130701150407.GB19937@titan.lakedaemon.net>
Message-ID: <20130701124205.9571b26975c1910ce5afa896@linux-foundation.org>

On Mon, 1 Jul 2013 11:04:07 -0400 Jason Cooper <jason at lakedaemon.net> wrote:

> On Mon, Jul 01, 2013 at 04:56:29PM +0200, Sebastian Hesselbarth wrote:
> > Commit 834cbfe966bece50afded79da8e975d255bf0772
> >  ("drivers/dma: remove unused support for MEMSET operations")
> > removes MEMSET from dmaengine but does not completely removes it from
> > Marvell Orion (arch/arm/plat-orion) and XOR (drivers/dma/mv_xor).
> > This also fixes some compiler warnings about now obsolete functions by
> > removing those.
> > 
> > Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> > ---
> > Cc: Jason Cooper <jason at lakedaemon.net>
> > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
> > Cc: Kyungmin Park <kyungmin.park at samsung.com>
> > Cc: Andrew Morton <akpm at linux-foundation.org>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: linux-kernel at vger.kernel.org
> > ---
> >  arch/arm/plat-orion/common.c |    6 ------
> >  drivers/dma/mv_xor.c         |   25 +------------------------
> >  2 files changed, 1 insertions(+), 30 deletions(-)
> 
> Please take a look at the email from lkml I just forwarded to you.  I
> believe this solves your problem, but I don't have time to look closely
> atm.

Unhelpful.  Can the rest of us see this email as well please?


From sylvester.nawrocki at gmail.com  Mon Jul  1 15:48:00 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Mon, 01 Jul 2013 21:48:00 +0200
Subject: [PATCH V3 2/3] phy: Add driver for Exynos DP PHY
In-Reply-To: <005301ce761b$32adf960$9809ec20$@samsung.com>
References: <005301ce761b$32adf960$9809ec20$@samsung.com>
Message-ID: <51D1DCF0.50803@gmail.com>

On 07/01/2013 07:24 AM, Jingoo Han wrote:
> Add a PHY provider driver for the Samsung Exynos SoC DP PHY.
>
> Signed-off-by: Jingoo Han<jg1.han at samsung.com>
> Cc: Sylwester Nawrocki<s.nawrocki at samsung.com>
> Acked-by: Felipe Balbi<balbi at ti.com>
> ---
>   .../devicetree/bindings/phy/samsung-phy.txt        |    8 ++
>   drivers/phy/Kconfig                                |    5 +
>   drivers/phy/Makefile                               |    1 +
>   drivers/phy/phy-exynos-dp-video.c                  |  118 ++++++++++++++++++++
>   4 files changed, 132 insertions(+)
>   create mode 100644 drivers/phy/phy-exynos-dp-video.c
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index 5ff208c..3fb656a 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -12,3 +12,11 @@ the PHY specifier identifies the PHY and its meaning is as follows:
>     1 - MIPI DSIM 0,
>     2 - MIPI CSIS 1,
>     3 - MIPI DSIM 1.
> +
> +Samsung EXYNOS SoC series DP PHY

I would make it "Samsung EXYNOS SoC series Display Port PHY"

> +-------------------------------------------------
> +
> +Required properties:
> +- compatible : should be "samsung,exynos5250-dp-video-phy";
> +- reg : offset and length of the DP PHY register set;
> +- #phy-cells : from the generic phy bindings, must be 0;

s/phy/PHY ?

> \ No newline at end of file

Missing new line character.

> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 6f446d0..760f55a 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -19,4 +19,9 @@ config PHY_EXYNOS_MIPI_VIDEO
>   	help
>   	  Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
>   	  S5P and EXYNOS SoCs.
> +
> +config PHY_EXYNOS_DP_VIDEO
> +	tristate "EXYNOS SoC series DP PHY driver"

"EXYNOS SoC series Display Port PHY driver" ?

> +	help
> +	  Support for DP PHY found on Samsung EXYNOS SoCs.

s/DP/Display Port ?

>   endif
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 71d8841..0fd1340 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -4,3 +4,4 @@
>
>   obj-$(CONFIG_GENERIC_PHY)		+= phy-core.o
>   obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)	+= phy-exynos-mipi-video.o
> +obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)	+= phy-exynos-dp-video.o
> diff --git a/drivers/phy/phy-exynos-dp-video.c b/drivers/phy/phy-exynos-dp-video.c
> new file mode 100644
> index 0000000..75e1d11
> --- /dev/null
> +++ b/drivers/phy/phy-exynos-dp-video.c
> @@ -0,0 +1,118 @@
> +/*
> + * Samsung EXYNOS SoC series DP PHY driver

s/DP/Display Port ?

> + *
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + * Author: Jingoo Han<jg1.han at samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include<linux/io.h>
> +#include<linux/kernel.h>
> +#include<linux/module.h>
> +#include<linux/of.h>
> +#include<linux/of_address.h>
> +#include<linux/phy/phy.h>
> +#include<linux/platform_device.h>
> +
> +/* DPTX_PHY_CONTROL register */
> +#define EXYNOS_DPTX_PHY_ENABLE		(1<<  0)
> +
> +struct exynos_dp_video_phy {
> +	void __iomem *regs;
> +};
> +
> +static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int on)
> +{
> +	void __iomem *addr;

How about just dropping this local variable ?

> +	u32 reg;
> +
> +	addr = state->regs;
> +
> +	reg = readl(addr);
> +	if (on)
> +		reg |= EXYNOS_DPTX_PHY_ENABLE;
> +	else
> +		reg&= ~EXYNOS_DPTX_PHY_ENABLE;
> +	writel(reg, addr);
> +
> +	return 0;
> +}
> +
> +static int exynos_dp_video_phy_power_on(struct phy *phy)
> +{
> +	struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
> +
> +	return __set_phy_state(state, 1);
> +}
> +
> +static int exynos_dp_video_phy_power_off(struct phy *phy)
> +{
> +	struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
> +
> +	return __set_phy_state(state, 0);
> +}
> +
> +static struct phy_ops exynos_dp_video_phy_ops = {
> +	.power_on	= exynos_dp_video_phy_power_on,
> +	.power_off	= exynos_dp_video_phy_power_off,
> +	.owner		= THIS_MODULE,
> +};
> +
> +static int exynos_dp_video_phy_probe(struct platform_device *pdev)
> +{
> +	struct exynos_dp_video_phy *state;
> +	struct device *dev =&pdev->dev;
> +	struct resource *res;
> +	struct phy_provider *phy_provider;
> +	struct phy *phy;
> +
> +	state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
> +	if (!state)
> +		return -ENOMEM;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +
> +	state->regs = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(state->regs))
> +		return PTR_ERR(state->regs);
> +
> +	dev_set_drvdata(dev, state);

I can't see any corresponding dev_get_drvdata(), it should be safe
to remove this assignment.

> +	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> +	if (IS_ERR(phy_provider))
> +		return PTR_ERR(phy_provider);
> +
> +	phy = devm_phy_create(dev, 0,&exynos_dp_video_phy_ops, "dp");

The label could be NULL, since there is no need to support non-dt config.

> +	if (IS_ERR(phy)) {
> +		dev_err(dev, "failed to create DP PHY\n");
> +		return PTR_ERR(phy);
> +	}
> +	phy_set_drvdata(phy, state);
> +
> +	return 0;
> +}
> +
> +#ifdef CONFIG_OF

You don't use of_match_ptr() macro to assign of_match_table to the driver
structure below. This means build with CONFIG_OF disabled is broken now.
I would just remove that #ifdef and would make the driver depends on
CONFIG_OF.

> +static const struct of_device_id exynos_dp_video_phy_of_match[] = {
> +	{ .compatible = "samsung,exynos5250-dp-video-phy" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, exynos_dp_video_phy_of_match);
> +#endif
> +
> +static struct platform_driver exynos_dp_video_phy_driver = {
> +	.probe	= exynos_dp_video_phy_probe,
> +	.driver = {
> +		.name	= "exynos-dp-video-phy",
> +		.owner	= THIS_MODULE,
> +		.of_match_table	= exynos_dp_video_phy_of_match,
> +	}
> +};
> +module_platform_driver(exynos_dp_video_phy_driver);
> +
> +MODULE_AUTHOR("Jingoo Han<jg1.han at samsung.com>");
> +MODULE_DESCRIPTION("Samsung EXYNOS SoC DP PHY driver");
> +MODULE_LICENSE("GPL v2");

Thanks,
Sylwester


From paul at pwsan.com  Mon Jul  1 15:48:50 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 1 Jul 2013 19:48:50 +0000 (UTC)
Subject: OMAP baseline test results for v3.10-rc7
Message-ID: <alpine.DEB.2.02.1307011946180.4358@utopia.booyaka.com>


Here are some basic OMAP test results for Linux v3.10-rc7.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v3.10-rc7/20130630191558/

Special thanks to Lokesh Vutla, Vaibhav Hiremath, Kevin Hilman, and 
Rajendra Nayak for helping unravel the Beaglebone-White test problems.


Test summary
------------

Build: uImage:
    Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a,
                  omap1_defconfig, omap1_defconfig_1510innovator_only, 
                  omap1_defconfig_5912osk_only, omap2plus_defconfig, 
                  omap2plus_defconfig_2430sdp_only
                  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, 
                  omap2plus_defconfig_omap2_4_only, 
                  omap2plus_defconfig_omap3_4_only, 
                  rmk_omap3430_ldp_allnoconfig, 
                  rmk_omap3430_ldp_oldconfig, 
                  rmk_omap4430_sdp_allnoconfig, 
                  rmk_omap4430_sdp_oldconfig

Build: zImage:
    Pass ( 1/ 1): omap2plus_defconfig

Boot to userspace:
    FAIL ( 2/12): 37xxevm, am335xbonelt
    Pass (10/12): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
                  3730beaglexm, 4430es2panda, 4460pandaes, 5912osk,
                  am335xbone, cmt3517

PM: chip retention via suspend:
    FAIL ( 3/ 6): 2430sdp, 37xxevm, 4430es2panda
    Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 4460pandaes

PM: chip retention via dynamic idle:
    FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 6): 3530es3beagle, 3730beaglexm

PM: chip off except CORE via suspend:
    Pass ( 1/ 1): 3730beaglexm

PM: chip off except CORE via dynamic idle:
    Pass ( 1/ 1): 3730beaglexm

PM: chip off via suspend:
    FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 1/ 4): 3530es3beagle

PM: chip off via dynamic idle:
    FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 1/ 4): 3530es3beagle


Failing tests: fixed by posted patches
--------------------------------------

* 37xx EVM: boot fails
  - as of v3.10-rc1
  - Fixed by http://marc.info/?l=linux-arm-kernel&m=137112093431021&w=2
  

Failing tests: needing investigation
------------------------------------

Boot tests:

* 3517EVM & CM-T3517: boot hangs with NFS root
  - Likely some Kconfig, board file, and PM issues with EMAC
  - Longstanding bug
  - Not currently part of the automated test suite

Boot warnings:

* 2420N800, 2430sdp: failed to get counter_32k resource
  - "omap2_sync32k_clocksource_init: failed to get counter_32k resource"
  - Cause unknown

* CM-T3517: L3 in-band error with IPSS during boot
  - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
  - Longstanding issue; does not occur on the 3517EVM

* 3730 Beagle XM, 3517EVM, CM-T3517: uart4_rx.uart4_rx mux failure
  - Cause unknown
  - May be related to the OMAP serial driver and/or DT mux data
  - http://marc.info/?l=linux-arm-kernel&m=137121357528854&w=2

PM tests:

* 2430sdp: power domains not entering retention
  - Cause unknown

* 3730 Beagle XM: does not serial wake from off-idle suspend when console
  UART doesn't clock-gate ("debug ignore_loglevel")
  - Cause unknown
  - Not yet part of the automated test suite
  - Re-tested at v3.7; still failing:
    http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt

* 4430es2panda: pwrdm state mismatch on CAM, DSS

* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
  - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
    per discussion with Tero Kristo
  - Likely dependent on the bootloader version
    - fails with 2012.07-00136-g755de79
  - http://marc.info/?l=linux-arm-kernel&m=136432340618226&w=2

* 4430es2panda: MPU, ABE didn't enter target state
  - New for v3.10-rc

* 4460pandaes: pwrdm state mismatch on DSS, ABE, IVAHD, TESLA

* 4460pandaes: chip not entering retention in dynamic idle
  - Presumably 4430es2panda also fails this
  - Suspend-to-RAM enters full chip retention

Other:

* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
  - Unknown cause; could be due to the lack of hierarchical enable/disable
    in hwmod code
  - Jon Hunter and Santosh Shilimkar report this does not appear with
    the same X-loader/bootloader on his 4430ES2.3 Panda, so could be
    ES-level dependent


Failing tests: reported by others 
---------------------------------

- RTC wakeup from suspend broken on 3730beaglexm
  - as of v3.10-rc1
  - discussion here: http://marc.info/?l=linux-omap&m=136915841625434&w=2


vmlinux object size
(delta in bytes from test_v3.10-rc6 
(7d132055814ef17a6c7b69f342244c410a5e000f)):
   text     data      bss    total  kernel
   +969     +600        0    +1569  am33xx_only
   +813        0        0     +813  n800_multi_omap2xxx
   +813        0        0     +813  n800_only_a
   +861       -8        0     +853  omap1_defconfig
   +861        0        0     +861  omap1_defconfig_1510innovator_only
   +861      +24        0     +885  omap1_defconfig_5912osk_only
   +925        0        0     +925  omap2plus_defconfig
   +901        0        0     +901  omap2plus_defconfig_2430sdp_only
   +925        0        0     +925  omap2plus_defconfig_cpupm
 -14807    -1880    -8256   -24943  omap2plus_defconfig_no_pm
   +989        0        0     +989  omap2plus_defconfig_omap2_4_only
   +925        0        0     +925  omap2plus_defconfig_omap3_4_only
   +384        0      -16     +368  rmk_omap3430_ldp_allnoconfig
   +285        0        0     +285  rmk_omap3430_ldp_oldconfig
   +384        0      -16     +368  rmk_omap4430_sdp_allnoconfig
   +257        0        0     +257  rmk_omap4430_sdp_oldconfig



From pavel at ucw.cz  Mon Jul  1 15:51:56 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Mon, 1 Jul 2013 21:51:56 +0200
Subject: [PATCH] N900: fix operation on emulator
In-Reply-To: <51D1C8DD.6040409@cogentembedded.com>
References: <20130613142809.GA3775@amd.pavel.ucw.cz>
 <20130613145724.GH8164@atomide.com>
 <20130613155240.GB3775@amd.pavel.ucw.cz>
 <20130613161418.GJ8164@atomide.com>
 <20130613230808.GA14876@amd.pavel.ucw.cz>
 <20130614055629.GM8164@atomide.com>
 <20130614212816.GA31768@atrey.karlin.mff.cuni.cz>
 <20130617111031.GQ20992@atomide.com>
 <20130701140315.GA15318@amd.pavel.ucw.cz>
 <51D1C8DD.6040409@cogentembedded.com>
Message-ID: <20130701195147.GA22174@amd.pavel.ucw.cz>

On Mon 2013-07-01 22:22:21, Sergei Shtylyov wrote:
> Hello.
> 
> On 07/01/2013 06:03 PM, Pavel Machek wrote:
> 
> >Errata workarounds for N900 hardware actually break operation on
> >emulator. Fix it.
> 
> >This approach was suggested by Pali Roh?r <pali.rohar at gmail.com>
> >(thanks!).
> 
> >(Also explain what "sleep_ind" led actually does).
> 
>    Looks like unrelated change and probably worth another patch?

Separate patch for adding single-line comment?

> >--- a/arch/arm/mach-omap2/board-rx51.c
> >+++ b/arch/arm/mach-omap2/board-rx51.c
> >@@ -33,9 +33,12 @@
> >  #include "pm.h"
> >  #include "sdram-nokia.h"
> >  #include "board-rx51-secure.h"
> >+#include "soc.h"
> >
> >  #define RX51_GPIO_SLEEP_IND 162
> >
> >+/* This lights up left part of keyboard */
> >+
> >  static struct gpio_led gpio_leds[] = {
...
> >  #ifdef CONFIG_ARM_ERRATA_430973
> >-	printk(KERN_INFO "RX-51: Enabling ARM errata 430973 workaround.\n");
> >-	/* set IBE to 1 */
> >-	rx51_secure_update_aux_cr(1 << 6, 0);
> >+	if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
> >+		printk(KERN_INFO "RX-51: Enabling ARM errata 430973 workaround.\n");
> 
>    How about pr_info() instead?

<sarcasm>Would not that be unrelated change and worth of separate
patch?</sarcasm>

:-).

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From sergei.shtylyov at cogentembedded.com  Mon Jul  1 16:00:02 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 02 Jul 2013 00:00:02 +0400
Subject: [PATCH] N900: fix operation on emulator
In-Reply-To: <20130701195147.GA22174@amd.pavel.ucw.cz>
References: <20130613142809.GA3775@amd.pavel.ucw.cz>
 <20130613145724.GH8164@atomide.com> <20130613155240.GB3775@amd.pavel.ucw.cz>
 <20130613161418.GJ8164@atomide.com> <20130613230808.GA14876@amd.pavel.ucw.cz>
 <20130614055629.GM8164@atomide.com>
 <20130614212816.GA31768@atrey.karlin.mff.cuni.cz>
 <20130617111031.GQ20992@atomide.com>
 <20130701140315.GA15318@amd.pavel.ucw.cz>
 <51D1C8DD.6040409@cogentembedded.com>
 <20130701195147.GA22174@amd.pavel.ucw.cz>
Message-ID: <51D1DFC2.4080209@cogentembedded.com>

Hello.

On 07/01/2013 11:51 PM, Pavel Machek wrote:

>>> Errata workarounds for N900 hardware actually break operation on
>>> emulator. Fix it.

>>> This approach was suggested by Pali Roh?r <pali.rohar at gmail.com>
>>> (thanks!).

>>> (Also explain what "sleep_ind" led actually does).

>>     Looks like unrelated change and probably worth another patch?

> Separate patch for adding single-line comment?

    If it's unrelated to the main patch purpose, yes. As the Russians 
say: "cutlets separately and flies separately".

>>> --- a/arch/arm/mach-omap2/board-rx51.c
>>> +++ b/arch/arm/mach-omap2/board-rx51.c
>>> @@ -33,9 +33,12 @@
>>>   #include "pm.h"
>>>   #include "sdram-nokia.h"
>>>   #include "board-rx51-secure.h"
>>> +#include "soc.h"
>>>
>>>   #define RX51_GPIO_SLEEP_IND 162
>>>
>>> +/* This lights up left part of keyboard */
>>> +
>>>   static struct gpio_led gpio_leds[] = {
> ...
>>>   #ifdef CONFIG_ARM_ERRATA_430973
>>> -	printk(KERN_INFO "RX-51: Enabling ARM errata 430973 workaround.\n");
>>> -	/* set IBE to 1 */
>>> -	rx51_secure_update_aux_cr(1 << 6, 0);
>>> +	if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
>>> +		printk(KERN_INFO "RX-51: Enabling ARM errata 430973 workaround.\n");

>>     How about pr_info() instead?

> <sarcasm>Would not that be unrelated change and worth of separate
> patch?</sarcasm>

    No, this would be a related change. Sarcasm wasted.

> :-).

> 									Pavel

WBR, Sergei



From arno at natisbad.org  Mon Jul  1 16:23:14 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Mon, 01 Jul 2013 22:23:14 +0200
Subject: [PATCH] arm: kirkwood: readynas duo v2: Add GMT G762 Fan Controller
 DT bindings
Message-ID: <87sizyuj0t.fsf@natisbad.org>


Now that GMT G762 PWM Fan Controller is available upstream, let's add
missing bindings in Netgear ReadyNAS Duo v2 .dts file. Let's also take
the opportunity to fix space issues at the end of the file.

Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
---
Hi Jason and Andrew,

This one applies and has been tested against Stephen Rothwell tree.
Can you make it flow to Linus tree during the merge window? Thanks
in advance.

Cheers,

a+

 .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  | 54 +++++++++++++++-------
 1 file changed, 37 insertions(+), 17 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
index ad6ade7..796a307 100644
--- a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
+++ b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
@@ -52,6 +52,17 @@
 			};
 		};
 
+		clocks {
+		       #address-cells = <1>;
+		       #size-cells = <0>;
+
+		       g762_clk: fixedclk {
+				 compatible = "fixed-clock";
+				 #clock-cells = <0>;
+				 clock-frequency = <8192>;
+		       };
+		};
+
 		i2c at 11000 {
 			status = "okay";
 
@@ -59,6 +70,15 @@
 				compatible = "ricoh,rs5c372a";
 				reg = <0x32>;
 			};
+
+			g762: g762 at 3e {
+				compatible = "gmt,g762";
+				reg = <0x3e>;
+				clocks = <&g762_clk>; /* input clock */
+				fan_gear_mode = <0>;
+				fan_startv = <1>;
+				pwm_polarity = <0>;
+			};
 		};
 
 		serial at 12000 {
@@ -166,21 +186,21 @@
 		};
 	};
 
-        regulators {
-                compatible = "simple-bus";
-                #address-cells = <1>;
-                #size-cells = <0>;
-
-                usb_power: regulator at 1 {
-                        compatible = "regulator-fixed";
-                        reg = <1>;
-                        regulator-name = "USB 3.0 Power";
-                        regulator-min-microvolt = <5000000>;
-                        regulator-max-microvolt = <5000000>;
-                        enable-active-high;
-                        regulator-always-on;
-                        regulator-boot-on;
-                        gpio = <&gpio1 14 0>;
-                };
-        };
+	regulators {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		usb_power: regulator at 1 {
+			compatible = "regulator-fixed";
+			reg = <1>;
+			regulator-name = "USB 3.0 Power";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			enable-active-high;
+			regulator-always-on;
+			regulator-boot-on;
+			gpio = <&gpio1 14 0>;
+		};
+	};
 };
-- 
1.8.3.1



From thomas.petazzoni at free-electrons.com  Mon Jul  1 16:28:14 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 1 Jul 2013 22:28:14 +0200
Subject: [PATCH] arm: kirkwood: readynas duo v2: Add GMT G762 Fan
 Controller DT bindings
In-Reply-To: <87sizyuj0t.fsf@natisbad.org>
References: <87sizyuj0t.fsf@natisbad.org>
Message-ID: <20130701222814.36ca395a@skate>

Dear Arnaud Ebalard,

On Mon, 01 Jul 2013 22:23:14 +0200, Arnaud Ebalard wrote:

> -        regulators {
> -                compatible = "simple-bus";
> -                #address-cells = <1>;
> -                #size-cells = <0>;
> -
> -                usb_power: regulator at 1 {
> -                        compatible = "regulator-fixed";
> -                        reg = <1>;
> -                        regulator-name = "USB 3.0 Power";
> -                        regulator-min-microvolt = <5000000>;
> -                        regulator-max-microvolt = <5000000>;
> -                        enable-active-high;
> -                        regulator-always-on;
> -                        regulator-boot-on;
> -                        gpio = <&gpio1 14 0>;
> -                };
> -        };
> +	regulators {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		usb_power: regulator at 1 {
> +			compatible = "regulator-fixed";
> +			reg = <1>;
> +			regulator-name = "USB 3.0 Power";
> +			regulator-min-microvolt = <5000000>;
> +			regulator-max-microvolt = <5000000>;
> +			enable-active-high;
> +			regulator-always-on;
> +			regulator-boot-on;
> +			gpio = <&gpio1 14 0>;
> +		};
> +	};
>  };

Those white-space changes are not related to the addition of the G762
Device Tree informations.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From dsd at laptop.org  Mon Jul  1 16:30:09 2013
From: dsd at laptop.org (Daniel Drake)
Date: Mon,  1 Jul 2013 16:30:09 -0400 (EDT)
Subject: armada_drm clock selection - try 2
Message-ID: <20130701203009.633A8FAAD5@dev.laptop.org>

Hi Russell,

Here is a new patch which should incorporate all your previous feedback.
Now each variant passes clock info to the main driver via a new
armada_clk_info structure.

A helper function in the core lets each variant find the best clock.
As you suggested we first try external ("dedicated") clocks, where we can
change the rate to find an exact match. We fall back on looking at the rates
of the other clocks and we return the clock that provides us with the closest
match after integer division (rejecting those that don't bring us within 1%).

There is still the possibility that two CRTCs on the same device end up using
the same clock, so I added a usage counter to each clock to prevent the rate
from being changed by another CRTC.

This is compile-tested only - but after your feedback I will add the
remaining required hacks and test it on XO.

diff --git a/drivers/gpu/drm/armada/armada_510.c b/drivers/gpu/drm/armada/armada_510.c
index a016888..7dff2dc 100644
--- a/drivers/gpu/drm/armada/armada_510.c
+++ b/drivers/gpu/drm/armada/armada_510.c
@@ -17,12 +17,29 @@
 
 static int armada510_init(struct armada_private *priv, struct device *dev)
 {
-	priv->extclk[0] = devm_clk_get(dev, "ext_ref_clk_1");
+	struct armada_clk_info *clk_info = devm_kzalloc(dev,
+		sizeof(struct armada_clk_info) * 4, GFP_KERNEL);
 
-	if (IS_ERR(priv->extclk[0]) && PTR_ERR(priv->extclk[0]) == -ENOENT)
-		priv->extclk[0] = ERR_PTR(-EPROBE_DEFER);
+	if (!clk_info)
+		return -ENOMEM;
 
-	return PTR_RET(priv->extclk[0]);
+	/* External clocks */
+	clk_info[0].clk = devm_clk_get(dev, "ext_ref_clk_0");
+	clk_info[0].is_dedicated = true;
+	clk_info[0].sclk = SCLK_510_EXTCLK0;
+	clk_info[1].clk = devm_clk_get(dev, "ext_ref_clk_1");
+	clk_info[1].is_dedicated = true;
+	clk_info[1].sclk = SCLK_510_EXTCLK1;
+
+	/* Internal/shared clocks */
+	clk_info[2].clk = devm_clk_get(dev, "axi");
+	clk_info[2].sclk = SCLK_510_AXI;
+	clk_info[3].clk = devm_clk_get(dev, "pll");
+	clk_info[3].sclk = SCLK_510_PLL;
+
+	priv->num_clks = 4;
+	priv->clk_info = clk_info;
+	return 0;
 }
 
 static int armada510_crtc_init(struct armada_crtc *dcrtc)
@@ -38,42 +55,25 @@ static int armada510_crtc_init(struct armada_crtc *dcrtc)
  * supportable, and again with sclk != NULL to set the clocks up for
  * that.  The former can return an error, but the latter is expected
  * not to.
- *
- * We currently are pretty rudimentary here, always selecting
- * EXT_REF_CLK_1 for LCD0 and erroring LCD1.  This needs improvement!
  */
 static int armada510_crtc_compute_clock(struct armada_crtc *dcrtc,
 	const struct drm_display_mode *mode, uint32_t *sclk)
 {
 	struct armada_private *priv = dcrtc->crtc.dev->dev_private;
-	struct clk *clk = priv->extclk[0];
-	int ret;
-
-	if (dcrtc->num == 1)
-		return -EINVAL;
-
-	if (IS_ERR(clk))
-		return PTR_ERR(clk);
-
-	if (dcrtc->clk != clk) {
-		ret = clk_prepare_enable(clk);
-		if (ret)
-			return ret;
-		dcrtc->clk = clk;
-	}
+	struct armada_clk_info *clk_info;
+	int err;
+	int divider;
 
-	if (sclk) {
-		uint32_t rate, ref, div;
+	clk_info = armada_drm_find_best_clock(priv, mode->clock * 1000, &divider);
+	if (!clk_info)
+		return -ENOENT;
 
-		rate = mode->clock * 1000;
-		ref = clk_round_rate(clk, rate);
-		div = DIV_ROUND_UP(ref, rate);
-		if (div < 1)
-			div = 1;
+	err = armada_drm_crtc_switch_clock(dcrtc, clk_info);
+	if (err)
+		return err;
 
-		clk_set_rate(clk, ref);
-		*sclk = div | SCLK_510_EXTCLK1;
-	}
+	if (sclk)
+		*sclk = divider | clk_info->sclk;
 
 	return 0;
 }
diff --git a/drivers/gpu/drm/armada/armada_crtc.c b/drivers/gpu/drm/armada/armada_crtc.c
index f489157..8202be2 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -83,6 +83,34 @@ enum csc_mode {
  * porch, which we're reprogramming.)
  */
 
+/* Switch to a new clock source after disabling and unpreparing the current
+ * one. If non-NULL, the new clock source is expected to be prepared before
+ * this function is called. */
+int armada_drm_crtc_switch_clock(struct armada_crtc *dcrtc,
+	struct armada_clk_info *clk_info)
+{
+	int err;
+
+	if (dcrtc->active_clk == clk_info)
+		return 0;
+
+	if (dcrtc->active_clk) {
+		clk_disable_unprepare(dcrtc->active_clk->clk);
+		dcrtc->active_clk->usage_count--;
+		dcrtc->active_clk = NULL;
+	}
+
+	if (clk_info) {
+		err = clk_enable(clk_info->clk);
+		if (err)
+			return err;
+		dcrtc->active_clk = clk_info;
+		clk_info->usage_count++;
+	}
+
+	return 0;
+}
+
 void
 armada_drm_crtc_update_regs(struct armada_crtc *dcrtc, struct armada_regs *regs)
 {
@@ -647,10 +675,7 @@ static void armada_drm_crtc_destroy(struct drm_crtc *crtc)
 
 	priv->dcrtc[dcrtc->num] = NULL;
 	drm_crtc_cleanup(&dcrtc->crtc);
-
-	if (!IS_ERR(dcrtc->clk))
-		clk_disable_unprepare(dcrtc->clk);
-
+	armada_drm_crtc_switch_clock(dcrtc, NULL);
 	kfree(dcrtc);
 }
 
@@ -814,7 +839,6 @@ int armada_drm_crtc_create(struct drm_device *dev, unsigned num,
 
 	dcrtc->base = base;
 	dcrtc->num = num;
-	dcrtc->clk = ERR_PTR(-EINVAL);
 	dcrtc->csc_yuv_mode = CSC_AUTO;
 	dcrtc->csc_rgb_mode = CSC_AUTO;
 	dcrtc->cfg_dumb_ctrl = DUMB24_RGB888_0;
diff --git a/drivers/gpu/drm/armada/armada_crtc.h b/drivers/gpu/drm/armada/armada_crtc.h
index 972da53..f260676 100644
--- a/drivers/gpu/drm/armada/armada_crtc.h
+++ b/drivers/gpu/drm/armada/armada_crtc.h
@@ -37,7 +37,7 @@ struct armada_crtc {
 	struct drm_crtc		crtc;
 	unsigned		num;
 	void __iomem		*base;
-	struct clk		*clk;
+	struct armada_clk_info	*active_clk;
 	struct {
 		uint32_t	spu_v_h_total;
 		uint32_t	spu_v_porch;
@@ -70,5 +70,7 @@ void armada_drm_crtc_irq(struct armada_crtc *, u32);
 void armada_drm_crtc_disable_irq(struct armada_crtc *, u32);
 void armada_drm_crtc_enable_irq(struct armada_crtc *, u32);
 void armada_drm_crtc_update_regs(struct armada_crtc *, struct armada_regs *);
+int armada_drm_crtc_switch_clock(struct armada_crtc *dcrtc,
+	struct armada_clk_info *clk_info);
 
 #endif
diff --git a/drivers/gpu/drm/armada/armada_drm.h b/drivers/gpu/drm/armada/armada_drm.h
index e8c4f80..4fe8ec5 100644
--- a/drivers/gpu/drm/armada/armada_drm.h
+++ b/drivers/gpu/drm/armada/armada_drm.h
@@ -55,6 +55,20 @@ void armada_drm_vbl_event_remove_unlocked(struct armada_crtc *,
 	__e->fn = _f;					\
 } while (0)
 
+struct armada_clk_info {
+	struct clk *clk;
+
+	/* If this clock is dedicated to us, we can change its rate without
+	 * worrying about any other users in other parts of the system. */
+	bool is_dedicated;
+
+	/* However, we cannot share the same dedicated clock between two CRTCs
+	 * if each CRTC wants a different rate. Track the number of users. */
+	int usage_count;
+
+	/* The bits in the SCLK register that select this clock */
+	uint32_t sclk;
+};
 
 struct armada_private;
 
@@ -77,7 +91,8 @@ struct armada_private {
 	struct drm_fb_helper	*fbdev;
 	struct armada_crtc	*dcrtc[2];
 	struct drm_mm		linear;
-	struct clk		*extclk[2];
+	int			num_clks;
+	struct armada_clk_info	*clk_info;
 	struct drm_property	*csc_yuv_prop;
 	struct drm_property	*csc_rgb_prop;
 	struct drm_property	*colorkey_prop;
@@ -99,6 +114,9 @@ void __armada_drm_queue_unref_work(struct drm_device *,
 void armada_drm_queue_unref_work(struct drm_device *,
 	struct drm_framebuffer *);
 
+struct armada_clk_info *armada_drm_find_best_clock(struct armada_private *priv,
+	long rate, int *divider);
+
 extern const struct drm_mode_config_funcs armada_drm_mode_config_funcs;
 
 int armada_fbdev_init(struct drm_device *);
diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
index e0a08e9..411d56f 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -16,6 +16,97 @@
 #include "armada_ioctl.h"
 #include "armada_ioctlP.h"
 
+/* Find the best clock and integer divisor for a given rate.
+ * NULL is returned when no clock can be found.
+ * When the return value is non-NULL, the divider output variable is set
+ * appropriately, and the clock is returned in prepared state. */
+struct armada_clk_info *armada_drm_find_best_clock(struct armada_private *priv, 
+	long rate, int *divider)
+{
+	int i;
+	int div;
+	long residue;
+	long res_max;
+	long ref;
+	struct armada_clk_info *ret = NULL;
+
+	/* Look for an unused dedicated clock (e.g. an external clock with
+	 * no other users) which can provide the desired rate exactly. In this
+	 * case we can change the clock rate to meet our needs. */
+	for (i = 0; i < priv->num_clks; i++) {
+		struct armada_clk_info *clkinfo = &priv->clk_info[i];
+		struct clk *candidate = clkinfo->clk;
+		if (IS_ERR(candidate))
+			continue;
+
+		if (!clkinfo->is_dedicated || clkinfo->usage_count > 0)
+			continue;
+
+		if (clk_prepare(candidate))
+			continue;
+
+		ref = clk_round_rate(candidate, rate);
+		if (ref == rate) {
+			*divider = 1;
+			clk_set_rate(candidate, ref);
+			return clkinfo;
+
+		}
+		clk_unprepare(candidate);
+	}
+
+	/* Fallback: look for a clock that can bring us within 1% of the
+	 * desired rate when an integer divider is applied. In this case we
+	 * do not change the clock's rate because the clock may be shared with
+	 * other elements. */
+	res_max = rate / 100;
+	for (i = 0; i < priv->num_clks; i++) {
+		struct armada_clk_info *clkinfo = &priv->clk_info[i];
+		struct clk *candidate = clkinfo->clk;
+		long ref_residue;
+
+		if (IS_ERR(candidate) || clk_prepare(candidate))
+			continue;
+
+		ref = clk_get_rate(candidate);
+		ref_residue = ref % rate;
+
+		/* Normalize the residue value: if its at the high end of
+		 * the range, calculate its offset from the next possible
+		 * divisor. */
+		if (ref_residue > res_max)
+			ref_residue = rate - ref_residue;
+
+		/* Ignore rates worse than 1% */
+		if (ref_residue > res_max) {
+			clk_unprepare(candidate);
+			continue;
+		}
+
+		/* Do we have a better previous match? */
+		if (ret && residue < ref_residue) {
+			clk_unprepare(candidate);
+			continue;
+		}
+
+		/* We have the best match, store it for later. */
+		if (ret)
+			clk_unprepare(ret->clk);
+
+		ret = clkinfo;
+		residue = ref_residue;
+	}
+
+	if (ret) {
+		div = DIV_ROUND_UP(ref, rate);
+		if (div < 1)
+			div = 1;
+		*divider = div;
+	}
+
+	return ret;
+}
+
 static void armada_drm_unref_work(struct work_struct *work)
 {
 	struct armada_private *priv =
-- 
1.8.1.4



From arno at natisbad.org  Mon Jul  1 16:31:54 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Mon, 01 Jul 2013 22:31:54 +0200
Subject: [PATCH] arm: kirkwood: readynas duo v2: Add GMT G762 Fan
 Controller DT bindings
In-Reply-To: <20130701222814.36ca395a@skate> (Thomas Petazzoni's message of
 "Mon, 1 Jul 2013 22:28:14 +0200")
References: <87sizyuj0t.fsf@natisbad.org> <20130701222814.36ca395a@skate>
Message-ID: <87k3lauimd.fsf@natisbad.org>

Hi Thomas,

Thomas Petazzoni <thomas.petazzoni at free-electrons.com> writes:

> On Mon, 01 Jul 2013 22:23:14 +0200, Arnaud Ebalard wrote:
>
>> -        regulators {
>> -                compatible = "simple-bus";
>> -                #address-cells = <1>;
>> -                #size-cells = <0>;
>> -
>> -                usb_power: regulator at 1 {
>> -                        compatible = "regulator-fixed";
>> -                        reg = <1>;
>> -                        regulator-name = "USB 3.0 Power";
>> -                        regulator-min-microvolt = <5000000>;
>> -                        regulator-max-microvolt = <5000000>;
>> -                        enable-active-high;
>> -                        regulator-always-on;
>> -                        regulator-boot-on;
>> -                        gpio = <&gpio1 14 0>;
>> -                };
>> -        };
>> +	regulators {
>> +		compatible = "simple-bus";
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		usb_power: regulator at 1 {
>> +			compatible = "regulator-fixed";
>> +			reg = <1>;
>> +			regulator-name = "USB 3.0 Power";
>> +			regulator-min-microvolt = <5000000>;
>> +			regulator-max-microvolt = <5000000>;
>> +			enable-active-high;
>> +			regulator-always-on;
>> +			regulator-boot-on;
>> +			gpio = <&gpio1 14 0>;
>> +		};
>> +	};
>>  };
>
> Those white-space changes are not related to the addition of the G762
> Device Tree informations.

Should I make two unrelated patches (one for G762 and another cosmetic
one) or simply let the spaces as they are in .dts?

Cheers,

a+


From balbi at ti.com  Mon Jul  1 16:42:36 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 1 Jul 2013 23:42:36 +0300
Subject: OMAP baseline test results for v3.10-rc7
In-Reply-To: <alpine.DEB.2.02.1307011946180.4358@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307011946180.4358@utopia.booyaka.com>
Message-ID: <20130701204236.GA805@arwen.pp.htv.fi>

Hi,

On Mon, Jul 01, 2013 at 07:48:50PM +0000, Paul Walmsley wrote:
> Boot to userspace:
>     FAIL ( 2/12): 37xxevm, am335xbonelt

<quoting part of [1]>
| U-Boot# tftp 0x82000000 am335x-boneblack.dtb
| link up on port 0, speed 100, full duplex
| Using cpsw device
| TFTP from server 192.168.57.1; our IP address is 192.168.57.138
| Filename 'am335x-boneblack.dtb'.

Where are you taking am335x-boneblack.dtb from ? It's not in mainline
v3.10-rc7 kernel:

$ ls arch/arm/boot/dts/am33*.dts
arch/arm/boot/dts/am335x-bone.dts  arch/arm/boot/dts/am335x-evm.dts
arch/arm/boot/dts/am335x-evmsk.dts
$ git grep -e boneblack arch/arm/
$ echo $
1
$ git show
commit 9e895ace5d82df8929b16f58e9f515f6d54ab82d
Author: Linus Torvalds <torvalds at linux-foundation.org>
Date:   Sat Jun 22 09:47:31 2013 -1000

    Linux 3.10-rc7

diff --git a/Makefile b/Makefile
index c6863b5..0142c93 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 3
 PATCHLEVEL = 10
 SUBLEVEL = 0
-EXTRAVERSION = -rc6
+EXTRAVERSION = -rc7
 NAME = Unicycling Gorilla
 
 # *DOCUMENTATION*

[1] http://www.pwsan.com/omap/testlogs/test_v3.10-rc7/20130630191558/boot/am335xbonelt/am335x-bone/am335xbonelt_log.txt

-- 
balbi
-------------- 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/20130701/beaafe0a/attachment.sig>

From arno at natisbad.org  Mon Jul  1 16:45:02 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Mon, 01 Jul 2013 22:45:02 +0200
Subject: [PATCH,
 RESEND] arm: kirkwood: readynas duo v2: Add GMT G762 Fan Controller
Message-ID: <874nceui0h.fsf@natisbad.org>


Now that GMT G762 PWM Fan Controller is available upstream, let's add
missing bindings in Netgear ReadyNAS Duo v2 .dts file.

Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
---
Hi Jason and Andrew,

This one applies and has been tested against Stephen Rothwell tree.
Can you make it flow to Linus tree during the merge window?

Following Thomas feedback, this is a resend of previous version, this
time w/o fixes for bad spaces at the end of the file. Just tell me if
I should send a separate one for that purpose.

Thanks in advance.

Cheers,

a+

 .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts    | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
index ad6ade7..cc43d24 100644
--- a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
+++ b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
@@ -52,6 +52,17 @@
 			};
 		};
 
+		clocks {
+		       #address-cells = <1>;
+		       #size-cells = <0>;
+
+		       g762_clk: fixedclk {
+				 compatible = "fixed-clock";
+				 #clock-cells = <0>;
+				 clock-frequency = <8192>;
+		       };
+		};
+
 		i2c at 11000 {
 			status = "okay";
 
@@ -59,6 +70,15 @@
 				compatible = "ricoh,rs5c372a";
 				reg = <0x32>;
 			};
+
+			g762: g762 at 3e {
+				compatible = "gmt,g762";
+				reg = <0x3e>;
+				clocks = <&g762_clk>; /* input clock */
+				fan_gear_mode = <0>;
+				fan_startv = <1>;
+				pwm_polarity = <0>;
+			};
 		};
 
 		serial at 12000 {
-- 
1.8.3.1




From balbi at ti.com  Mon Jul  1 16:46:33 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 1 Jul 2013 23:46:33 +0300
Subject: [RFC] wlcore: sdio: add wilink clock providers
In-Reply-To: <1372707250-11998-1-git-send-email-coelho@ti.com>
References: <1372707250-11998-1-git-send-email-coelho@ti.com>
Message-ID: <20130701204633.GB805@arwen.pp.htv.fi>

Hi,

On Mon, Jul 01, 2013 at 10:34:10PM +0300, Luciano Coelho wrote:
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 670c3ce..7f061b8 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -65,11 +65,19 @@
>  		enable-active-high;
>  	};
>  
> +
>  	wlan {
> -	     compatible = "ti,wilink6";
> -	     interrupt-parent = <&gpio2>;
> -	     interrupts = <21 0x4>;	/* gpio line 53, high level triggered */
> -	     refclock = <2>;		/* 38.4 MHz */
> +		compatible = "ti,wilink6";
> +		interrupt-parent = <&gpio2>;
> +		interrupts = <21 0x4>;	/* gpio line 53, high level triggered */
> +		clocks = <&refclock>;
> +		clock-names = "refclock";

hmmm, shouldn't you provide both clocks (refclock and tcx0clock)
explicitly here ?

Also, you should probably make it clear that the WiLink module is fed by
the 32K sync clock just to make sure clock usecounts are correctly
incremented ?

-- 
balbi
-------------- 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/20130701/09e9beae/attachment.sig>

From stern at rowland.harvard.edu  Mon Jul  1 16:50:58 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Mon, 1 Jul 2013 16:50:58 -0400 (EDT)
Subject: [PATCH] USB: OHCI: make ohci-nxp a separate driver
In-Reply-To: <1372585818-8441-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <Pine.LNX.4.44L0.1307011649190.1547-100000@iolanthe.rowland.org>

On Sun, 30 Jun 2013, Manjunath Goudar wrote:

> Separate the OHCI NXP host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM.
> 
> Many place function name and struct name started with usb,
> current scenario replaced usb with ohci for proper naming.

> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index f3dcaa2..9a0b023 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -1194,11 +1194,6 @@ MODULE_LICENSE ("GPL");
>  #define EP93XX_PLATFORM_DRIVER	ohci_hcd_ep93xx_driver
>  #endif
>  
> -#ifdef CONFIG_ARCH_LPC32XX
> -#include "ohci-nxp.c"
> -#define NXP_PLATFORM_DRIVER	usb_hcd_nxp_driver
> -#endif
> -
>  #ifdef CONFIG_ARCH_DAVINCI_DA8XX
>  #include "ohci-da8xx.c"
>  #define DAVINCI_PLATFORM_DRIVER	ohci_hcd_da8xx_driver
> @@ -1301,12 +1296,6 @@ static int __init ohci_hcd_mod_init(void)
>  		goto error_ep93xx;
>  #endif
>  
> -#ifdef NXP_PLATFORM_DRIVER
> -	retval = platform_driver_register(&NXP_PLATFORM_DRIVER);
> -	if (retval < 0)
> -		goto error_nxp;
> -#endif
> -
>  #ifdef DAVINCI_PLATFORM_DRIVER
>  	retval = platform_driver_register(&DAVINCI_PLATFORM_DRIVER);
>  	if (retval < 0)
> @@ -1320,10 +1309,6 @@ static int __init ohci_hcd_mod_init(void)
>  	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
>   error_davinci:
>  #endif
> -#ifdef NXP_PLATFORM_DRIVER
> -	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
> - error_nxp:
> -#endif
>  #ifdef EP93XX_PLATFORM_DRIVER
>  	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
>   error_ep93xx:

You forgot to remove

#ifdef NXP_PLATFORM_DRIVER
	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
#endif

from ohci_hcd_mod_exit().  The rest is okay.

Alan Stern



From pavel at ucw.cz  Mon Jul  1 16:53:53 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Mon, 1 Jul 2013 22:53:53 +0200
Subject: [PATCH] N900: fix operation on emulator
In-Reply-To: <51D1C8DD.6040409@cogentembedded.com>
References: <20130613142809.GA3775@amd.pavel.ucw.cz>
 <20130613145724.GH8164@atomide.com>
 <20130613155240.GB3775@amd.pavel.ucw.cz>
 <20130613161418.GJ8164@atomide.com>
 <20130613230808.GA14876@amd.pavel.ucw.cz>
 <20130614055629.GM8164@atomide.com>
 <20130614212816.GA31768@atrey.karlin.mff.cuni.cz>
 <20130617111031.GQ20992@atomide.com>
 <20130701140315.GA15318@amd.pavel.ucw.cz>
 <51D1C8DD.6040409@cogentembedded.com>
Message-ID: <20130701205353.GB22174@amd.pavel.ucw.cz>

Hi!

> >Errata workarounds for N900 hardware actually break operation on
> >emulator. Fix it.
> 
> >This approach was suggested by Pali Roh?r <pali.rohar at gmail.com>
> >(thanks!).
> 
> >(Also explain what "sleep_ind" led actually does).
> 
>    Looks like unrelated change and probably worth another patch?

Ok, more serious issue is that code this was modifying is not yet in
mainline. Sorry.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From coelho at ti.com  Mon Jul  1 16:55:28 2013
From: coelho at ti.com (Luciano Coelho)
Date: Mon, 1 Jul 2013 23:55:28 +0300
Subject: [RFC] wlcore: sdio: add wilink clock providers
In-Reply-To: <20130701204633.GB805@arwen.pp.htv.fi>
References: <1372707250-11998-1-git-send-email-coelho@ti.com>
 <20130701204633.GB805@arwen.pp.htv.fi>
Message-ID: <1372712128.21065.71.camel@cumari.coelho.fi>

On Mon, 2013-07-01 at 23:46 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Jul 01, 2013 at 10:34:10PM +0300, Luciano Coelho wrote:
> > diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> > index 670c3ce..7f061b8 100644
> > --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> > +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> > @@ -65,11 +65,19 @@
> >  		enable-active-high;
> >  	};
> >  
> > +
> >  	wlan {
> > -	     compatible = "ti,wilink6";
> > -	     interrupt-parent = <&gpio2>;
> > -	     interrupts = <21 0x4>;	/* gpio line 53, high level triggered */
> > -	     refclock = <2>;		/* 38.4 MHz */
> > +		compatible = "ti,wilink6";
> > +		interrupt-parent = <&gpio2>;
> > +		interrupts = <21 0x4>;	/* gpio line 53, high level triggered */
> > +		clocks = <&refclock>;
> > +		clock-names = "refclock";
> 
> hmmm, shouldn't you provide both clocks (refclock and tcx0clock)
> explicitly here ?

No, not needed for Panda.  Panda uses WiLink6 and only the refclock
needs to be provided.


> Also, you should probably make it clear that the WiLink module is fed by
> the 32K sync clock just to make sure clock usecounts are correctly
> incremented ?

Hmmm, yes, that is probably a good idea.  At least to make sure
everything is initialized properly before the WiLink module is up and
running.  I'll look into it and eventually add in a separate patch.

Thanks for your comments!

--
Luca.



From stern at rowland.harvard.edu  Mon Jul  1 17:01:27 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Mon, 1 Jul 2013 17:01:27 -0400 (EDT)
Subject: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during
 bus suspend
In-Reply-To: <20130701164920.GA31370@arwen.pp.htv.fi>
Message-ID: <Pine.LNX.4.44L0.1307011655580.1547-100000@iolanthe.rowland.org>

On Mon, 1 Jul 2013, Felipe Balbi wrote:

> > I don't know what Pad wakeup is.  The wakeup signal has to originate 
> > from the EHCI controller, doesn't it?  If not, how does the Pad know 
> > when a wakeup is needed?
> 
> That's really an OMAP thing, I guess. Pad wakeup sits in the PRCM (IIRC)
> inside and always on power domain. EHCI sits in another power domain
> which be turned off. When it's turned off (power gated and clock gated)
> the EHCI block has no means to wakeup whatsoever. That's when pad wakeup
> comes into play. It is generated when PRCM sees a change in the actual
> pad of the die. To check who should 'own' the wakeup, it checks the
> muxing settings to verify whose pad is that.

How does the PRCM know which changes should generate wakeup events?  
In the EHCI controller, this is managed by the settings of the WKOC_E,
WKDSCNNT_E, and WKCNNT_E bits in the PORTSC registers.  But if EHCI is
powered off, those bits can't be used.

Also, once the wakeup signal has been turned on, how does it get turned 
off again?

Alan Stern



From swarren at wwwdotorg.org  Mon Jul  1 17:07:05 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon,  1 Jul 2013 15:07:05 -0600
Subject: [PATCH] ARM: tegra: fix VBUS regulator GPIO polarity in DT
Message-ID: <1372712825-13757-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Commit 4c94c8b "ARM: tegra: update device trees for USB binding rework"
added regulator definitions for GPIO-controlled USB VBUS. However, none
of these contained the essential DT property enable-active-high. Add
this so that the regulator definitions are correct.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
I'm sending this to arm-soc to be taken into v3.11-rc1. However, if it
won't get in until -rc2, let me know; I'd be tempted not to fix it in
3.11 in that case, so I don't have to wait until v3.11-rc2 before
applying patches that use these new regulators, since they rely on this
fix going in first.

 arch/arm/boot/dts/tegra20-seaboard.dts  | 1 +
 arch/arm/boot/dts/tegra20-trimslice.dts | 1 +
 arch/arm/boot/dts/tegra20-whistler.dts  | 2 ++
 3 files changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index 9c5cb54..7f460bb 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -814,6 +814,7 @@
 			regulator-name = "vdd_vbus_wup1";
 			regulator-min-microvolt = <5000000>;
 			regulator-max-microvolt = <5000000>;
+			enable-active-high;
 			gpio = <&gpio 24 0>; /* PD0 */
 		};
 
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index a997eaf..77efb09 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -417,6 +417,7 @@
 			regulator-name = "usb1_vbus";
 			regulator-min-microvolt = <5000000>;
 			regulator-max-microvolt = <5000000>;
+			enable-active-high;
 			gpio = <&gpio 170 0>; /* PV2 */
 		};
 	};
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index e07f210..a6b1b5b 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -584,6 +584,7 @@
 			regulator-name = "vbus1";
 			regulator-min-microvolt = <5000000>;
 			regulator-max-microvolt = <5000000>;
+			enable-active-high;
 			gpio = <&tca6416 0 0>; /* GPIO_PMU0 */
 		};
 
@@ -593,6 +594,7 @@
 			regulator-name = "vbus3";
 			regulator-min-microvolt = <5000000>;
 			regulator-max-microvolt = <5000000>;
+			enable-active-high;
 			gpio = <&tca6416 1 0>; /* GPIO_PMU1 */
 		};
 	};
-- 
1.8.1.5



From pavel at ucw.cz  Mon Jul  1 17:15:04 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Mon, 1 Jul 2013 23:15:04 +0200
Subject: [PATCH] N900: enable N900-specific drivers even if device tree is
 enabled
In-Reply-To: <20130617111031.GQ20992@atomide.com>
References: <20130613132624.GA3464@amd.pavel.ucw.cz>
 <20130613141001.GF8164@atomide.com>
 <20130613142809.GA3775@amd.pavel.ucw.cz>
 <20130613145724.GH8164@atomide.com>
 <20130613155240.GB3775@amd.pavel.ucw.cz>
 <20130613161418.GJ8164@atomide.com>
 <20130613230808.GA14876@amd.pavel.ucw.cz>
 <20130614055629.GM8164@atomide.com>
 <20130614212816.GA31768@atrey.karlin.mff.cuni.cz>
 <20130617111031.GQ20992@atomide.com>
Message-ID: <20130701211504.GB15318@amd.pavel.ucw.cz>


We still need video & sound drivers with device tree enabled.

Signed-off-by: Pavel Machek <pavel at ucw.cz>

---

Patch against 3.10.

--- linux-delme-clean//arch/arm/mach-omap2/board-rx51-video.c	2013-07-01 21:51:07.000000000 +0200
+++ linux-delme/arch/arm/mach-omap2/board-rx51-video.c	2013-07-01 22:50:27.000000000 +0200
@@ -61,7 +61,7 @@
 
 static int __init rx51_video_init(void)
 {
-	if (!machine_is_nokia_rx51())
+	if (!machine_is_nokia_rx51() && !of_machine_is_compatible("nokia,omap3-n900"))
 		return 0;
 
 	if (omap_mux_init_gpio(RX51_LCD_RESET_GPIO, OMAP_PIN_OUTPUT)) {
diff -urN linux-delme-clean//sound/soc/omap/rx51.c linux-delme/sound/soc/omap/rx51.c
--- linux-delme-clean//sound/soc/omap/rx51.c	2013-07-01 21:54:49.000000000 +0200
+++ linux-delme/sound/soc/omap/rx51.c	2013-07-01 22:50:27.000000000 +0200
@@ -396,7 +396,7 @@
 {
 	int err;
 
-	if (!machine_is_nokia_rx51())
+	if (!machine_is_nokia_rx51() && !of_machine_is_compatible("nokia,omap3-n900"))
 		return -ENODEV;
 
 	err = gpio_request_one(RX51_TVOUT_SEL_GPIO,

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From pavel at ucw.cz  Mon Jul  1 17:17:54 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Mon, 1 Jul 2013 23:17:54 +0200
Subject: [PATCH] N900: add device tree
In-Reply-To: <20130617111031.GQ20992@atomide.com>
References: <20130613132624.GA3464@amd.pavel.ucw.cz>
 <20130613141001.GF8164@atomide.com>
 <20130613142809.GA3775@amd.pavel.ucw.cz>
 <20130613145724.GH8164@atomide.com>
 <20130613155240.GB3775@amd.pavel.ucw.cz>
 <20130613161418.GJ8164@atomide.com>
 <20130613230808.GA14876@amd.pavel.ucw.cz>
 <20130614055629.GM8164@atomide.com>
 <20130614212816.GA31768@atrey.karlin.mff.cuni.cz>
 <20130617111031.GQ20992@atomide.com>
Message-ID: <20130701211753.GC15318@amd.pavel.ucw.cz>


This adds device tree with neccessary support to boot with functional
video (on both emulator and real N900 device).

Signed-off-by: Pavel Machek <pavel at ucw.cz>

--- linux-delme-clean//arch/arm/boot/dts/Makefile	2013-07-01 21:51:00.000000000 +0200
+++ linux-delme/arch/arm/boot/dts/Makefile	2013-07-01 22:53:06.000000000 +0200
@@ -141,6 +141,7 @@
 	omap3-devkit8000.dtb \
 	omap3-beagle-xm.dtb \
 	omap3-evm.dtb \
+	omap3-n900.dtb \
 	omap3-tobi.dtb \
 	omap3-igep0020.dtb \
 	omap3-igep0030.dtb \
--- linux-delme-clean//arch/arm/boot/dts/omap3-n900.dts	1970-01-01 01:00:00.000000000 +0100
+++ linux-delme/arch/arm/boot/dts/omap3-n900.dts	2013-07-01 22:50:21.000000000 +0200
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2013 Pavel Machek <pavel at ucw.cz>
+ * Copyright 2013 Aaro Koskinen <aaro.koskinen at iki.fi>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 (or later) as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+/include/ "omap34xx.dtsi"
+
+/ {
+	model = "Nokia N900";
+	compatible = "nokia,omap3-n900", "ti,omap3";
+
+	cpus {
+		cpu at 0 {
+//			cpu0-supply = <&vcc>;
+		};
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x10000000>; /* 256 MB */
+	};
+
+};
+
+&i2c1 {
+	clock-frequency = <2200000>;
+
+	twl: twl at 48 {
+		reg = <0x48>;
+		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+		interrupt-parent = <&intc>;
+	};
+};
+
+/include/ "twl4030.dtsi"
+
+&twl_gpio {
+	ti,pullups	= <0x0>;
+	ti,pulldowns	= <0x03ff3f>; /* BIT(0..5) | BIT(8..17) */
+};
+
+&i2c2 {
+	clock-frequency = <400000>;
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+};
+
+&mmc1 {
+	status = "disabled";
+};
+
+&mmc2 {
+	status = "disabled";
+};
+
+&mmc3 {
+	status = "disabled";
+};
+
+&mcspi1 {
+	// For some reason, touchscreen is neccessary for screen to work at 
+	// all on real hw. It works well without it on emulator.
+	//
+	// Also... order in the device tree actually matters here.
+	tsc2005 at 0 {
+		compatible = "tsc2005";
+		spi-max-frequency = <6000000>;
+		reg = <0>;
+	};
+	mipid at 2 {
+		compatible = "acx565akm";
+		spi-max-frequency = <6000000>;
+		reg = <2>;
+		// turbo_mode = 0,
+		// cs_per_word = 0
+	};
+};
+
+/*
+&usb_otg_hs {
+	interface-type = <0>;
+	usb-phy = <&usb2_phy>;
+	mode = <2>;
+	power = <50>;
+};
+*/

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From jason at lakedaemon.net  Mon Jul  1 17:24:49 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 1 Jul 2013 17:24:49 -0400
Subject: [PATCH] arm: kirkwood: readynas duo v2: Add GMT G762 Fan
 Controller DT bindings
In-Reply-To: <87k3lauimd.fsf@natisbad.org>
References: <87sizyuj0t.fsf@natisbad.org> <20130701222814.36ca395a@skate>
 <87k3lauimd.fsf@natisbad.org>
Message-ID: <20130701212449.GE19937@titan.lakedaemon.net>

On Mon, Jul 01, 2013 at 10:31:54PM +0200, Arnaud Ebalard wrote:
> Hi Thomas,
> 
> Thomas Petazzoni <thomas.petazzoni at free-electrons.com> writes:
> 
> > On Mon, 01 Jul 2013 22:23:14 +0200, Arnaud Ebalard wrote:
> >
> >> -        regulators {
> >> -                compatible = "simple-bus";
> >> -                #address-cells = <1>;
> >> -                #size-cells = <0>;
> >> -
> >> -                usb_power: regulator at 1 {
> >> -                        compatible = "regulator-fixed";
> >> -                        reg = <1>;
> >> -                        regulator-name = "USB 3.0 Power";
> >> -                        regulator-min-microvolt = <5000000>;
> >> -                        regulator-max-microvolt = <5000000>;
> >> -                        enable-active-high;
> >> -                        regulator-always-on;
> >> -                        regulator-boot-on;
> >> -                        gpio = <&gpio1 14 0>;
> >> -                };
> >> -        };
> >> +	regulators {
> >> +		compatible = "simple-bus";
> >> +		#address-cells = <1>;
> >> +		#size-cells = <0>;
> >> +
> >> +		usb_power: regulator at 1 {
> >> +			compatible = "regulator-fixed";
> >> +			reg = <1>;
> >> +			regulator-name = "USB 3.0 Power";
> >> +			regulator-min-microvolt = <5000000>;
> >> +			regulator-max-microvolt = <5000000>;
> >> +			enable-active-high;
> >> +			regulator-always-on;
> >> +			regulator-boot-on;
> >> +			gpio = <&gpio1 14 0>;
> >> +		};
> >> +	};
> >>  };
> >
> > Those white-space changes are not related to the addition of the G762
> > Device Tree informations.
> 
> Should I make two unrelated patches (one for G762 and another cosmetic
> one) or simply let the spaces as they are in .dts?

Leave them as they are.  I'm intending to do a cleanup series for all
the whitespace issues in the dts files.

thx,

Jason.


From airlied at gmail.com  Mon Jul  1 17:26:31 2013
From: airlied at gmail.com (Dave Airlie)
Date: Tue, 2 Jul 2013 07:26:31 +1000
Subject: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver
In-Reply-To: <51D15F13.7040408@gmail.com>
References: <20130629225210.GF3353@n2100.arm.linux.org.uk>
 <E1Ut41C-0000wl-Ff@rmk-PC.arm.linux.org.uk>
 <20130630115941.GG18285@phenom.ffwll.local>
 <20130630125238.GH3353@n2100.arm.linux.org.uk>
 <CAPM=9tydcpP2-A6fnnHB873Nekj4HnxjraZ3TtRG3UF-Bqa6OQ@mail.gmail.com>
 <51D14333.40307@gmail.com>
 <20130701094258.GT18285@phenom.ffwll.local>
 <51D15F13.7040408@gmail.com>
Message-ID: <CAPM=9tzaCyuut=fkGCDCqi1cFirPF-G4GRWYdRDGUfRCc-C7-w@mail.gmail.com>

> Of course, I share the idea of true, full-blown of_drm_something
> helpers. But the DT patch, is not an improvement but a real fix as in
> "make DRM not break on some platforms". From that on, I can start
> digging into DRM API and improve DT support here and there.
>
> So for the three patches I mentioned above, they are all minor
> improvements of the API. Minor, because I cannot ever sent _the_ single
> perfect patch just because I don't know the API well enough, yet.
>
> Just based on my personal experience: TDA998x driver got merged the way it
> is _although_ I addressed some concerns - the fixes are not merged
> _although_ I provided experimental results. This is of course
> disappointing for me, but I am sure it will work out soon and I will
> get back to happily send improvements for the platforms I can test on.

To be honest I've no idea what those tda998x patches could fix or
break, so they go on my no ideas list and I hope if they get reposted
someone will tell me what they do.

I could probably be more motivated towards poking other people to
review stuff, but I mostly hope in vain that the ARM people will cross
review things for other ARM chips, I had a bit of that happening for a
while at the start, but it seems to have died off. Now I'm mostly
relying on Rob to have some clue what I'm merging is sane.

My current priority for merging stuff is:
core patches that affect all platforms,
core patches that affect x86
drivers that I maintain by default
core patches that affect ARM
misc ARM drivers that fall through cracks.

Maybe I can persuade Rob to become a sub maintainer for all of the SoC
drivers but I suspect he'd try and hurt me in real life.

I'll take another look at the tda patches but I may still have no idea
what they are doing.

Dave.


From robherring2 at gmail.com  Mon Jul  1 17:34:26 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 01 Jul 2013 16:34:26 -0500
Subject: [PATCH v2] of: Specify initrd location using 64-bit
In-Reply-To: <1372702835-5333-1-git-send-email-santosh.shilimkar@ti.com>
References: <1372702835-5333-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <51D1F5E2.6070609@gmail.com>

On 07/01/2013 01:20 PM, Santosh Shilimkar wrote:
> On some PAE architectures, the entire range of physical memory could reside
> outside the 32-bit limit.  These systems need the ability to specify the
> initrd location using 64-bit numbers.
> 
> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
> use 64-bit numbers instead of the current unsigned long.
> 
> There has been quite a bit of debate about whether to use u64 or phys_addr_t.
> It was concluded to stick to u64 to be consistent with rest of the device
> tree code. As summarized by Geert, "The address to load the initrd is decided
> by the bootloader/user and set at that point later in time. The dtb should not
> be tied to the kernel you are booting"

That was quoting me. Otherwise:

Acked-by: Rob Herring <rob.herring at calxeda.com>

Unless Grant feels compelled to pick this up for 3.11, I think it has to
wait for 3.12.

Rob

> 
> More details on the discussion can be found here:
> https://lkml.org/lkml/2013/6/20/690
> https://lkml.org/lkml/2012/9/13/544
> 
> Cc: Grant Likely <grant.likely at linaro.org>
> Cc: Rob Herring <rob.herring at calxeda.com>
> Cc: Geert Uytterhoeven <geert at linux-m68k.org>
> Cc: Sebastian Andrzej Siewior <bigeasy at linutronix.de>
> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: Vineet Gupta <vgupta at synopsys.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Mark Salter <msalter at redhat.com>
> Cc: Aurelien Jacquiot <a-jacquiot at ti.com>
> Cc: James Hogan <james.hogan at imgtec.com>
> Cc: Michal Simek <monstr at monstr.eu>
> Cc: Ralf Baechle <ralf at linux-mips.org>
> Cc: Jonas Bonn <jonas at southpole.se>
> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> Cc: Paul Mackerras <paulus at samba.org>
> Cc: x86 at kernel.org
> Cc: arm at kernel.org
> Cc: Chris Zankel <chris at zankel.net>
> Cc: Max Filippov <jcmvbkbc at gmail.com>
> Cc: bigeasy at linutronix.de
> Cc: robherring2 at gmail.com
> Cc: Nicolas Pitre <nicolas.pitre at linaro.org>
> 
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-c6x-dev at linux-c6x.org
> Cc: linux-mips at linux-mips.org
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: linux-xtensa at linux-xtensa.org
> Cc: devicetree-discuss at lists.ozlabs.org
> 
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arc/mm/init.c            |    5 ++---
>  arch/arm/mm/init.c            |    2 +-
>  arch/arm64/mm/init.c          |    3 +--
>  arch/c6x/kernel/devicetree.c  |    3 +--
>  arch/metag/mm/init.c          |    5 ++---
>  arch/microblaze/kernel/prom.c |    3 +--
>  arch/mips/kernel/prom.c       |    3 +--
>  arch/openrisc/kernel/prom.c   |    3 +--
>  arch/powerpc/kernel/prom.c    |    3 +--
>  arch/x86/kernel/devicetree.c  |    3 +--
>  arch/xtensa/kernel/setup.c    |    3 +--
>  drivers/of/fdt.c              |   10 ++++++----
>  include/linux/of_fdt.h        |    3 +--
>  13 files changed, 20 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> index 4a17736..7991e08 100644
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -157,9 +157,8 @@ void __init free_initrd_mem(unsigned long start, unsigned long end)
>  #endif
>  
>  #ifdef CONFIG_OF_FLATTREE
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -					    unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
> -	pr_err("%s(%lx, %lx)\n", __func__, start, end);
> +	pr_err("%s(%llx, %llx)\n", __func__, start, end);
>  }
>  #endif /* CONFIG_OF_FLATTREE */
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 9a5cdc0..afeaef7 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -76,7 +76,7 @@ static int __init parse_tag_initrd2(const struct tag *tag)
>  __tagtable(ATAG_INITRD2, parse_tag_initrd2);
>  
>  #ifdef CONFIG_OF_FLATTREE
> -void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	phys_initrd_start = start;
>  	phys_initrd_size = end - start;
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index f497ca7..7047708 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -44,8 +44,7 @@ static unsigned long phys_initrd_size __initdata = 0;
>  
>  phys_addr_t memstart_addr __read_mostly = 0;
>  
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -					    unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	phys_initrd_start = start;
>  	phys_initrd_size = end - start;
> diff --git a/arch/c6x/kernel/devicetree.c b/arch/c6x/kernel/devicetree.c
> index bdb56f0..287d0e6 100644
> --- a/arch/c6x/kernel/devicetree.c
> +++ b/arch/c6x/kernel/devicetree.c
> @@ -33,8 +33,7 @@ void __init early_init_devtree(void *params)
>  
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -		unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	initrd_start = (unsigned long)__va(start);
>  	initrd_end = (unsigned long)__va(end);
> diff --git a/arch/metag/mm/init.c b/arch/metag/mm/init.c
> index d05b845..bdc4811 100644
> --- a/arch/metag/mm/init.c
> +++ b/arch/metag/mm/init.c
> @@ -419,10 +419,9 @@ void free_initrd_mem(unsigned long start, unsigned long end)
>  #endif
>  
>  #ifdef CONFIG_OF_FLATTREE
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -					    unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
> -	pr_err("%s(%lx, %lx)\n",
> +	pr_err("%s(%llx, %llx)\n",
>  	       __func__, start, end);
>  }
>  #endif /* CONFIG_OF_FLATTREE */
> diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
> index 0a2c68f..62e2e8f 100644
> --- a/arch/microblaze/kernel/prom.c
> +++ b/arch/microblaze/kernel/prom.c
> @@ -136,8 +136,7 @@ void __init early_init_devtree(void *params)
>  }
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -		unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	initrd_start = (unsigned long)__va(start);
>  	initrd_end = (unsigned long)__va(end);
> diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
> index 5712bb5..32b8788 100644
> --- a/arch/mips/kernel/prom.c
> +++ b/arch/mips/kernel/prom.c
> @@ -58,8 +58,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
>  }
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -					    unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	initrd_start = (unsigned long)__va(start);
>  	initrd_end = (unsigned long)__va(end);
> diff --git a/arch/openrisc/kernel/prom.c b/arch/openrisc/kernel/prom.c
> index 5869e3f..150215a 100644
> --- a/arch/openrisc/kernel/prom.c
> +++ b/arch/openrisc/kernel/prom.c
> @@ -96,8 +96,7 @@ void __init early_init_devtree(void *params)
>  }
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -		unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	initrd_start = (unsigned long)__va(start);
>  	initrd_end = (unsigned long)__va(end);
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 8b6f7a9..2f3e252 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -550,8 +550,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
>  }
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -		unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	initrd_start = (unsigned long)__va(start);
>  	initrd_end = (unsigned long)__va(end);
> diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
> index b158152..2fbad6b 100644
> --- a/arch/x86/kernel/devicetree.c
> +++ b/arch/x86/kernel/devicetree.c
> @@ -52,8 +52,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
>  }
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -					    unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	initrd_start = (unsigned long)__va(start);
>  	initrd_end = (unsigned long)__va(end);
> diff --git a/arch/xtensa/kernel/setup.c b/arch/xtensa/kernel/setup.c
> index 6dd25ec..d45e602 100644
> --- a/arch/xtensa/kernel/setup.c
> +++ b/arch/xtensa/kernel/setup.c
> @@ -170,8 +170,7 @@ static int __init parse_tag_fdt(const bp_tag_t *tag)
>  
>  __tagtable(BP_TAG_FDT, parse_tag_fdt);
>  
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -		unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	initrd_start = (void *)__va(start);
>  	initrd_end = (void *)__va(end);
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 808be06..21123b8 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -550,7 +550,8 @@ int __init of_flat_dt_match(unsigned long node, const char *const *compat)
>   */
>  void __init early_init_dt_check_for_initrd(unsigned long node)
>  {
> -	unsigned long start, end, len;
> +	u64 start, end;
> +	unsigned long len;
>  	__be32 *prop;
>  
>  	pr_debug("Looking for initrd properties... ");
> @@ -558,15 +559,16 @@ void __init early_init_dt_check_for_initrd(unsigned long node)
>  	prop = of_get_flat_dt_prop(node, "linux,initrd-start", &len);
>  	if (!prop)
>  		return;
> -	start = of_read_ulong(prop, len/4);
> +	start = of_read_number(prop, len/4);
>  
>  	prop = of_get_flat_dt_prop(node, "linux,initrd-end", &len);
>  	if (!prop)
>  		return;
> -	end = of_read_ulong(prop, len/4);
> +	end = of_read_number(prop, len/4);
>  
>  	early_init_dt_setup_initrd_arch(start, end);
> -	pr_debug("initrd_start=0x%lx  initrd_end=0x%lx\n", start, end);
> +	pr_debug("initrd_start=0x%llx  initrd_end=0x%llx\n",
> +		 (unsigned long long)start, (unsigned long long)end);
>  }
>  #else
>  inline void early_init_dt_check_for_initrd(unsigned long node)
> diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
> index ed136ad..4a17939 100644
> --- a/include/linux/of_fdt.h
> +++ b/include/linux/of_fdt.h
> @@ -106,8 +106,7 @@ extern u64 dt_mem_next_cell(int s, __be32 **cellp);
>   * physical addresses.
>   */
>  #ifdef CONFIG_BLK_DEV_INITRD
> -extern void early_init_dt_setup_initrd_arch(unsigned long start,
> -					    unsigned long end);
> +extern void early_init_dt_setup_initrd_arch(u64 start, u64 end);
>  #endif
>  
>  /* Early flat tree scan hooks */
> 



From broonie at kernel.org  Mon Jul  1 17:36:39 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon,  1 Jul 2013 22:36:39 +0100
Subject: [PATCH 3/3] ARM: dts: Add WM1811A audio CODEC to Arndale bindings
In-Reply-To: <1372714599-17588-1-git-send-email-broonie@kernel.org>
References: <1372714599-17588-1-git-send-email-broonie@kernel.org>
Message-ID: <1372714599-17588-3-git-send-email-broonie@kernel.org>

From: Mark Brown <broonie at linaro.org>

The default audio module for the Arndale has a WM811A on it. Add this to
the device tree bindings.

Signed-off-by: Mark Brown <broonie at linaro.org>
---
 arch/arm/boot/dts/exynos5250-arndale.dts | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index 482f275..75c3065 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -325,7 +325,22 @@
 	};
 
 	i2c at 12C90000 {
-		status = "disabled";
+		wm1811a at 11 {
+			compatible = "wlf,wm1811";
+			reg = <0x1a>;
+
+			AVDD2-supply = <&main_dc_reg>;
+			CPVDD-supply = <&main_dc_reg>;
+			DBVDD1-supply = <&main_dc_reg>;
+			DBVDD2-supply = <&main_dc_reg>;
+			DBVDD3-supply = <&main_dc_reg>;
+			LDO1VDD-supply = <&main_dc_reg>;
+			SPKVDD1-supply = <&main_dc_reg>;
+			SPKVDD2-supply = <&main_dc_reg>;
+
+			wlf,ldo1ena = <&gpb0 0 0>;
+			wlf,ldo2ena = <&gpb0 1 0>;
+		};
 	};
 
 	i2c at 12CA0000 {
-- 
1.8.3.1



From broonie at kernel.org  Mon Jul  1 17:36:37 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon,  1 Jul 2013 22:36:37 +0100
Subject: [PATCH 1/3] ARM: dts: Put Arndale fixed voltage regulators on a
 simple-bus
Message-ID: <1372714599-17588-1-git-send-email-broonie@kernel.org>

From: Mark Brown <broonie at linaro.org>

Fixed voltage regulators (and other similar free standing things) are
supposed to go on a simple-bus for DT correctness reasons.

Signed-off-by: Mark Brown <broonie at linaro.org>
---
 arch/arm/boot/dts/exynos5250-arndale.dts | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index abc7272..68a13a6 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -429,18 +429,24 @@
 		vdd-supply = <&ldo8_reg>;
 	};
 
-	mmc_reg: voltage-regulator {
-		compatible = "regulator-fixed";
-		regulator-name = "VDD_33ON_2.8V";
-		regulator-min-microvolt = <2800000>;
-		regulator-max-microvolt = <2800000>;
-		gpio = <&gpx1 1 1>;
-		enable-active-high;
-	};
+	regulators {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		mmc_reg: voltage-regulator {
+			compatible = "regulator-fixed";
+			regulator-name = "VDD_33ON_2.8V";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			gpio = <&gpx1 1 1>;
+			enable-active-high;
+		};
 
-	reg_hdmi_en: fixedregulator at 0 {
-		compatible = "regulator-fixed";
-		regulator-name = "hdmi-en";
+		reg_hdmi_en: fixedregulator at 0 {
+			compatible = "regulator-fixed";
+			regulator-name = "hdmi-en";
+		};
 	};
 
 	fixed-rate-clocks {
-- 
1.8.3.1



From broonie at kernel.org  Mon Jul  1 17:36:38 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon,  1 Jul 2013 22:36:38 +0100
Subject: [PATCH 2/3] ARM: dts: Hook up supplies for Arndale S5M8767
In-Reply-To: <1372714599-17588-1-git-send-email-broonie@kernel.org>
References: <1372714599-17588-1-git-send-email-broonie@kernel.org>
Message-ID: <1372714599-17588-2-git-send-email-broonie@kernel.org>

From: Mark Brown <broonie at linaro.org>

As part of this add nodes for the main wall supply as well as bucks 7
and 8 which are used to drop that down for several of the LDOs.

Signed-off-by: Mark Brown <broonie at linaro.org>
---
 arch/arm/boot/dts/exynos5250-arndale.dts | 35 ++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index 68a13a6..482f275 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -38,6 +38,26 @@
 			compatible = "samsung,s5m8767-pmic";
 			reg = <0x66>;
 
+			vinb1-supply = <&main_dc_reg>;
+			vinb2-supply = <&main_dc_reg>;
+			vinb3-supply = <&main_dc_reg>;
+			vinb4-supply = <&main_dc_reg>;
+			vinb5-supply = <&main_dc_reg>;
+			vinb6-supply = <&main_dc_reg>;
+			vinb7-supply = <&main_dc_reg>;
+			vinb8-supply = <&main_dc_reg>;
+			vinb9-supply = <&main_dc_reg>;
+
+			vinl1-supply = <&buck7_reg>;
+			vinl2-supply = <&buck7_reg>;
+			vinl3-supply = <&buck7_reg>;
+			vinl4-supply = <&main_dc_reg>;
+			vinl5-supply = <&main_dc_reg>;
+			vinl6-supply = <&main_dc_reg>;
+			vinl7-supply = <&main_dc_reg>;
+			vinl8-supply = <&buck8_reg>;
+			vinl9-supply = <&buck8_reg>;
+
 			s5m8767,pmic-buck2-dvs-voltage = <1300000>;
 			s5m8767,pmic-buck3-dvs-voltage = <1100000>;
 			s5m8767,pmic-buck4-dvs-voltage = <1200000>;
@@ -276,6 +296,16 @@
 					op_mode = <1>;
 				};
 
+				buck7_reg: BUCK7 {
+					regulator-name = "PVDD_BUCK7";
+					regulator-always-on;
+				};
+
+				buck8_reg: BUCK8 {
+					regulator-name = "PVDD_BUCK8";
+					regulator-always-on;
+				};
+
 				buck9_reg: BUCK9 {
 					regulator-name = "VDD_33_OFF_EXT1";
 					regulator-min-microvolt = <750000>;
@@ -434,6 +464,11 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
+		main_dc_reg: fixedregulator at 1 {
+			compatible = "regulator-fixed";
+			regulator-name = "MAIN_DC";
+		};
+
 		mmc_reg: voltage-regulator {
 			compatible = "regulator-fixed";
 			regulator-name = "VDD_33ON_2.8V";
-- 
1.8.3.1



From jason at lakedaemon.net  Mon Jul  1 17:37:06 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 1 Jul 2013 17:37:06 -0400
Subject: [PATCH] DMA: Fix Marvell Orion and mv_xor after MEMSET removal
In-Reply-To: <20130701124205.9571b26975c1910ce5afa896@linux-foundation.org>
References: <1372690589-2218-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130701150407.GB19937@titan.lakedaemon.net>
 <20130701124205.9571b26975c1910ce5afa896@linux-foundation.org>
Message-ID: <20130701213706.GF19937@titan.lakedaemon.net>

On Mon, Jul 01, 2013 at 12:42:05PM -0700, Andrew Morton wrote:
> On Mon, 1 Jul 2013 11:04:07 -0400 Jason Cooper <jason at lakedaemon.net> wrote:
> 
> > On Mon, Jul 01, 2013 at 04:56:29PM +0200, Sebastian Hesselbarth wrote:
> > > Commit 834cbfe966bece50afded79da8e975d255bf0772
> > >  ("drivers/dma: remove unused support for MEMSET operations")
> > > removes MEMSET from dmaengine but does not completely removes it from
> > > Marvell Orion (arch/arm/plat-orion) and XOR (drivers/dma/mv_xor).
> > > This also fixes some compiler warnings about now obsolete functions by
> > > removing those.
> > > 
> > > Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> > > ---
> > > Cc: Jason Cooper <jason at lakedaemon.net>
> > > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
> > > Cc: Kyungmin Park <kyungmin.park at samsung.com>
> > > Cc: Andrew Morton <akpm at linux-foundation.org>
> > > Cc: linux-arm-kernel at lists.infradead.org
> > > Cc: linux-kernel at vger.kernel.org
> > > ---
> > >  arch/arm/plat-orion/common.c |    6 ------
> > >  drivers/dma/mv_xor.c         |   25 +------------------------
> > >  2 files changed, 1 insertions(+), 30 deletions(-)
> > 
> > Please take a look at the email from lkml I just forwarded to you.  I
> > believe this solves your problem, but I don't have time to look closely
> > atm.
> 
> Unhelpful.  Can the rest of us see this email as well please?

Sorry about that, the thread I was referring to on lkml was here:

http://comments.gmane.org/gmane.linux.kernel/1516018

And the specific email I was referring to is here (second version of
Bartlomiej's patch which addresses what Sebastian was attempting to fix):

http://permalink.gmane.org/gmane.linux.kernel/1517735

thx,

Jason.


From akpm at linux-foundation.org  Mon Jul  1 17:41:06 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Mon, 1 Jul 2013 14:41:06 -0700
Subject: [PATCH] DMA: Fix Marvell Orion and mv_xor after MEMSET removal
In-Reply-To: <20130701213706.GF19937@titan.lakedaemon.net>
References: <1372690589-2218-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130701150407.GB19937@titan.lakedaemon.net>
 <20130701124205.9571b26975c1910ce5afa896@linux-foundation.org>
 <20130701213706.GF19937@titan.lakedaemon.net>
Message-ID: <20130701144106.cf0cff602dbff596bf364de0@linux-foundation.org>

On Mon, 1 Jul 2013 17:37:06 -0400 Jason Cooper <jason at lakedaemon.net> wrote:

> > > Please take a look at the email from lkml I just forwarded to you.  I
> > > believe this solves your problem, but I don't have time to look closely
> > > atm.
> > 
> > Unhelpful.  Can the rest of us see this email as well please?
> 
> Sorry about that, the thread I was referring to on lkml was here:
> 
> http://comments.gmane.org/gmane.linux.kernel/1516018
> 
> And the specific email I was referring to is here (second version of
> Bartlomiej's patch which addresses what Sebastian was attempting to fix):
> 
> http://permalink.gmane.org/gmane.linux.kernel/1517735

Ah, OK, I have that:

http://ozlabs.org/~akpm/mmots/broken-out/drivers-dma-remove-unused-support-for-memset-operations.patch
http://ozlabs.org/~akpm/mmots/broken-out/drivers-dma-remove-unused-support-for-memset-operations-v3.patch


From festevam at gmail.com  Mon Jul  1 17:47:00 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 1 Jul 2013 18:47:00 -0300
Subject: [PATCH 3/3] ARM: dts: Add WM1811A audio CODEC to Arndale bindings
In-Reply-To: <1372714599-17588-3-git-send-email-broonie@kernel.org>
References: <1372714599-17588-1-git-send-email-broonie@kernel.org>
 <1372714599-17588-3-git-send-email-broonie@kernel.org>
Message-ID: <CAOMZO5DZb1wWu93eEHkEqNORhm_hn6qy_LdiRSumP7UODJ3uMw@mail.gmail.com>

On Mon, Jul 1, 2013 at 6:36 PM, Mark Brown <broonie at kernel.org> wrote:

>         i2c at 12C90000 {
> -               status = "disabled";
> +               wm1811a at 11 {
> +                       compatible = "wlf,wm1811";
> +                       reg = <0x1a>;

Shouldn't it be reg = <0x11> ? Or wm1811a at 1a ?


From sebastian.hesselbarth at gmail.com  Mon Jul  1 17:48:17 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 01 Jul 2013 23:48:17 +0200
Subject: armada_drm clock selection - try 2
In-Reply-To: <20130701203009.633A8FAAD5@dev.laptop.org>
References: <20130701203009.633A8FAAD5@dev.laptop.org>
Message-ID: <51D1F921.9050608@gmail.com>

On 07/01/2013 10:30 PM, Daniel Drake wrote:
> Here is a new patch which should incorporate all your previous feedback.
> Now each variant passes clock info to the main driver via a new
> armada_clk_info structure.
>
> A helper function in the core lets each variant find the best clock.
> As you suggested we first try external ("dedicated") clocks, where we can
> change the rate to find an exact match. We fall back on looking at the rates
> of the other clocks and we return the clock that provides us with the closest
> match after integer division (rejecting those that don't bring us within 1%).
>
> There is still the possibility that two CRTCs on the same device end up using
> the same clock, so I added a usage counter to each clock to prevent the rate
> from being changed by another CRTC.
>
> This is compile-tested only - but after your feedback I will add the
> remaining required hacks and test it on XO.
>
> diff --git a/drivers/gpu/drm/armada/armada_510.c b/drivers/gpu/drm/armada/armada_510.c
> index a016888..7dff2dc 100644
> --- a/drivers/gpu/drm/armada/armada_510.c
> +++ b/drivers/gpu/drm/armada/armada_510.c
> @@ -17,12 +17,29 @@
>
>   static int armada510_init(struct armada_private *priv, struct device *dev)
>   {
> -	priv->extclk[0] = devm_clk_get(dev, "ext_ref_clk_1");
> +	struct armada_clk_info *clk_info = devm_kzalloc(dev,
> +		sizeof(struct armada_clk_info) * 4, GFP_KERNEL);
>
> -	if (IS_ERR(priv->extclk[0])&&  PTR_ERR(priv->extclk[0]) == -ENOENT)
> -		priv->extclk[0] = ERR_PTR(-EPROBE_DEFER);
> +	if (!clk_info)
> +		return -ENOMEM;
>
> -	return PTR_RET(priv->extclk[0]);
> +	/* External clocks */
> +	clk_info[0].clk = devm_clk_get(dev, "ext_ref_clk_0");
> +	clk_info[0].is_dedicated = true;

Daniel,

I guess "extclk0" and "extclk1" should be sufficient for clock names.
Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g.
extclk0 simultaneously. See below for .is_dedicated in general.

[...]
> diff --git a/drivers/gpu/drm/armada/armada_drm.h b/drivers/gpu/drm/armada/armada_drm.h
> index e8c4f80..4fe8ec5 100644
> --- a/drivers/gpu/drm/armada/armada_drm.h
> +++ b/drivers/gpu/drm/armada/armada_drm.h
> @@ -55,6 +55,20 @@ void armada_drm_vbl_event_remove_unlocked(struct armada_crtc *,
>   	__e->fn = _f;					\
>   } while (0)
>
> +struct armada_clk_info {
> +	struct clk *clk;
> +
> +	/* If this clock is dedicated to us, we can change its rate without
> +	 * worrying about any other users in other parts of the system. */
> +	bool is_dedicated;
> +
> +	/* However, we cannot share the same dedicated clock between two CRTCs
> +	 * if each CRTC wants a different rate. Track the number of users. */
> +	int usage_count;

You can share the same clock between two CRTCs. Just consider CRTC1
using a mode with half pixel clock as CRTC0. Not that I think this will
ever happen, but it is possible.

> +	/* The bits in the SCLK register that select this clock */
> +	uint32_t sclk;
> +};
>
>   struct armada_private;
>
> @@ -77,7 +91,8 @@ struct armada_private {
>   	struct drm_fb_helper	*fbdev;
>   	struct armada_crtc	*dcrtc[2];
>   	struct drm_mm		linear;
> -	struct clk		*extclk[2];
> +	int			num_clks;
> +	struct armada_clk_info	*clk_info;
>   	struct drm_property	*csc_yuv_prop;
>   	struct drm_property	*csc_rgb_prop;
>   	struct drm_property	*colorkey_prop;
> @@ -99,6 +114,9 @@ void __armada_drm_queue_unref_work(struct drm_device *,
>   void armada_drm_queue_unref_work(struct drm_device *,
>   	struct drm_framebuffer *);
>
> +struct armada_clk_info *armada_drm_find_best_clock(struct armada_private *priv,
> +	long rate, int *divider);
> +
>   extern const struct drm_mode_config_funcs armada_drm_mode_config_funcs;
>
>   int armada_fbdev_init(struct drm_device *);
> diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
> index e0a08e9..411d56f 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -16,6 +16,97 @@
>   #include "armada_ioctl.h"
>   #include "armada_ioctlP.h"
>
> +/* Find the best clock and integer divisor for a given rate.
> + * NULL is returned when no clock can be found.
> + * When the return value is non-NULL, the divider output variable is set
> + * appropriately, and the clock is returned in prepared state. */
> +struct armada_clk_info *armada_drm_find_best_clock(struct armada_private *priv,
> +	long rate, int *divider)

I prefer not to try to find the best clock (source) at all. Let the
user pass the clock name by e.g. platform_data (or DT) and just try to
get the requested pixclk or a integer multiple of it. You will never be
able to find the best clock for all use cases.

Just figure out, if integer division is sufficient to get requested
pixclk and clk_set_rate otherwise. This may be useful for current mode
running at 148.5MHz (1080p50) and new mode at 74.25MHz (1080i50, 720p).

> +{
> +	int i;
> +	int div;
> +	long residue;
> +	long res_max;
> +	long ref;
> +	struct armada_clk_info *ret = NULL;
> +
> +	/* Look for an unused dedicated clock (e.g. an external clock with
> +	 * no other users) which can provide the desired rate exactly. In this
> +	 * case we can change the clock rate to meet our needs. */
> +	for (i = 0; i<  priv->num_clks; i++) {
> +		struct armada_clk_info *clkinfo =&priv->clk_info[i];
> +		struct clk *candidate = clkinfo->clk;
> +		if (IS_ERR(candidate))
> +			continue;
> +
> +		if (!clkinfo->is_dedicated || clkinfo->usage_count>  0)
> +			continue;
> +
> +		if (clk_prepare(candidate))
> +			continue;
> +
> +		ref = clk_round_rate(candidate, rate);
> +		if (ref == rate) {
> +			*divider = 1;
> +			clk_set_rate(candidate, ref);
> +			return clkinfo;
> +
> +		}
> +		clk_unprepare(candidate);
> +	}
> +
> +	/* Fallback: look for a clock that can bring us within 1% of the
> +	 * desired rate when an integer divider is applied. In this case we
> +	 * do not change the clock's rate because the clock may be shared with
> +	 * other elements. */

Just use clk_set_rate and don't try to make any assumptions. If the
clock you get back is way out of requested pixclk either fail or
just take what you get. HD/SD TV modes usually don't work with wrong
pixclk while VESA modes do.

Audio clock over HDMI will be broken and vert refresh will be wrong but
it is nothing you can check here. Otherwise, I think the patch is going
in the right direction.

Maybe, also clk API should be extended someday to allow to get min/max
frequency range. That will allow us to rule out some modes in a
mode_valid callback based on the pixclk rate.

Sebastian


From robdclark at gmail.com  Mon Jul  1 17:55:08 2013
From: robdclark at gmail.com (Rob Clark)
Date: Mon, 1 Jul 2013 17:55:08 -0400
Subject: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver
In-Reply-To: <51D14333.40307@gmail.com>
References: <20130629225210.GF3353@n2100.arm.linux.org.uk>
 <E1Ut41C-0000wl-Ff@rmk-PC.arm.linux.org.uk>
 <20130630115941.GG18285@phenom.ffwll.local>
 <20130630125238.GH3353@n2100.arm.linux.org.uk>
 <CAPM=9tydcpP2-A6fnnHB873Nekj4HnxjraZ3TtRG3UF-Bqa6OQ@mail.gmail.com>
 <51D14333.40307@gmail.com>
Message-ID: <CAF6AEGuJZeFBKgnTa8NM82jsfyx1wuyRcVnb9g2fqrZ+1LSuKw@mail.gmail.com>

On Mon, Jul 1, 2013 at 4:52 AM, Sebastian Hesselbarth
<sebastian.hesselbarth at gmail.com> wrote:
> On 07/01/13 02:01, Dave Airlie wrote:
>>
>> how about instead of writing:
>> "However, at least I've taken the time to_think_  about what I'm doing
>> and realise that there_is_  scope here for the DRM core to improve,
>>
>> rather than burying this stuff deep inside my driver like everyone else
>> has.  That's no reason to penalise patches from the "good guys" who think"
>>
>> you go with
>> "I noticed this piece of functionality could be refactored, here is a
>> patch adding them to
>> the core, does anyone think its a good idea?"
>
>
> Dave,
>
> at least on this point I do share Russell's impression. I've sent
> bunch of patches improving TDA998x and DRM+DT:
> - TDA998x irq handling - ignored
> - TDA998x sync fix - ignored

At least the sync fix, looks like I missed it (it probably is a good
idea to CC me if you want me to look at it).  Looks like there was
some follow-up discussion on both patches, unless I missed seeing a
newer version of those patches.

Sometimes if you think a patch has been ignored/forgotten, it doesn't
hurt to ping on mailing list or #dri-devel..  a lot of us are working
not just on kernel (the relatively small part in the whole linux
graphics stack), but also mesa and/or x11.  Some times things end up
several pages down in the mail folder.  It's not because we are all
sitting on a beach drinking margaritas, or because we don't like you.
It is just because we are busy and missed it.

Last few months I've been pretty buried in r/e + gallium driver for
new gpu, so I wasn't always checking dri-devel list every day.  At
least now I am in drm-driver mode again ;-)

> - Fix drm I2C slave encoder probing
>
> I am aware that this is not an easy job nor one you get much
> appreciation for. But, back when TDA998x driver was published,
> all my comments were basically answered with "Oh, I know. Maybe
> someday somebody will fix it".

If you have a better idea about how to make the slave encoder probing
better (and/or more generic to support stuff other than i2c), please
send RFC patch.  (And if you already did this, please send updated
version, see previous point about sometimes missing patches.)


BR,
-R


> I am not being paid for any of this, but have a strong intrinsic
> motivation here. But I am loosing interest in sending fixes for
> DRM stuff because my (personal) impression is the same Russell
> has: Depending on who sends patches, they get merged independent
> of how broken they are - others are discussed to death.
>
> Sebastian
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From sebastian.hesselbarth at gmail.com  Mon Jul  1 18:03:13 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue, 02 Jul 2013 00:03:13 +0200
Subject: [PATCH] DMA: Fix Marvell Orion and mv_xor after MEMSET removal
In-Reply-To: <20130701144106.cf0cff602dbff596bf364de0@linux-foundation.org>
References: <1372690589-2218-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130701150407.GB19937@titan.lakedaemon.net>
 <20130701124205.9571b26975c1910ce5afa896@linux-foundation.org>
 <20130701213706.GF19937@titan.lakedaemon.net>
 <20130701144106.cf0cff602dbff596bf364de0@linux-foundation.org>
Message-ID: <51D1FCA1.10004@gmail.com>

On 07/01/2013 11:41 PM, Andrew Morton wrote:
> On Mon, 1 Jul 2013 17:37:06 -0400 Jason Cooper<jason at lakedaemon.net>  wrote:
>
>>>> Please take a look at the email from lkml I just forwarded to you.  I
>>>> believe this solves your problem, but I don't have time to look closely
>>>> atm.
>>>
>>> Unhelpful.  Can the rest of us see this email as well please?
>>
>> Sorry about that, the thread I was referring to on lkml was here:
>>
>> http://comments.gmane.org/gmane.linux.kernel/1516018
>>
>> And the specific email I was referring to is here (second version of
>> Bartlomiej's patch which addresses what Sebastian was attempting to fix):
>>
>> http://permalink.gmane.org/gmane.linux.kernel/1517735
>
> Ah, OK, I have that:
>
> http://ozlabs.org/~akpm/mmots/broken-out/drivers-dma-remove-unused-support-for-memset-operations.patch

I guess, that is what is in next-20130701? My patch was based on it.

> http://ozlabs.org/~akpm/mmots/broken-out/drivers-dma-remove-unused-support-for-memset-operations-v3.patch

Bartlomeij sent another patch with all remaining differences between my
patch and the both above: https://lkml.org/lkml/2013/7/1/397

Sebastian


From sebastian.hesselbarth at gmail.com  Mon Jul  1 18:07:41 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue, 02 Jul 2013 00:07:41 +0200
Subject: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver
In-Reply-To: <CAF6AEGuJZeFBKgnTa8NM82jsfyx1wuyRcVnb9g2fqrZ+1LSuKw@mail.gmail.com>
References: <20130629225210.GF3353@n2100.arm.linux.org.uk>
 <E1Ut41C-0000wl-Ff@rmk-PC.arm.linux.org.uk>
 <20130630115941.GG18285@phenom.ffwll.local>
 <20130630125238.GH3353@n2100.arm.linux.org.uk>
 <CAPM=9tydcpP2-A6fnnHB873Nekj4HnxjraZ3TtRG3UF-Bqa6OQ@mail.gmail.com>
 <51D14333.40307@gmail.com>
 <CAF6AEGuJZeFBKgnTa8NM82jsfyx1wuyRcVnb9g2fqrZ+1LSuKw@mail.gmail.com>
Message-ID: <51D1FDAD.9090109@gmail.com>

On 07/01/2013 11:55 PM, Rob Clark wrote:
> On Mon, Jul 1, 2013 at 4:52 AM, Sebastian Hesselbarth
> <sebastian.hesselbarth at gmail.com>  wrote:
>> - TDA998x irq handling - ignored
>> - TDA998x sync fix - ignored
>
> At least the sync fix, looks like I missed it (it probably is a good
> idea to CC me if you want me to look at it).  Looks like there was
> some follow-up discussion on both patches, unless I missed seeing a
> newer version of those patches.

Yeah, I will update the patch for current mainline linux as it was
based on some of Russell's RFC patches.

> Sometimes if you think a patch has been ignored/forgotten, it doesn't
> hurt to ping on mailing list or #dri-devel..  a lot of us are working
> not just on kernel (the relatively small part in the whole linux
> graphics stack), but also mesa and/or x11.  Some times things end up
> several pages down in the mail folder.  It's not because we are all
> sitting on a beach drinking margaritas, or because we don't like you.
> It is just because we are busy and missed it.
>
> Last few months I've been pretty buried in r/e + gallium driver for
> new gpu, so I wasn't always checking dri-devel list every day.  At
> least now I am in drm-driver mode again ;-)

It is ok, I don't blame anyone here. Darren wants to test it on tilcdc.
I also found a datasheet for TDA9983b which is kind of compatible but
has more information about register layout in it. IIRC digikey also has
it.

>> - Fix drm I2C slave encoder probing
>>
> If you have a better idea about how to make the slave encoder probing
> better (and/or more generic to support stuff other than i2c), please
> send RFC patch.  (And if you already did this, please send updated
> version, see previous point about sometimes missing patches.)

Also, will send an updated fix.

Sebastian


From broonie at kernel.org  Mon Jul  1 18:38:49 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 1 Jul 2013 23:38:49 +0100
Subject: [PATCH 3/3] ARM: dts: Add WM1811A audio CODEC to Arndale bindings
In-Reply-To: <CAOMZO5DZb1wWu93eEHkEqNORhm_hn6qy_LdiRSumP7UODJ3uMw@mail.gmail.com>
References: <1372714599-17588-1-git-send-email-broonie@kernel.org>
 <1372714599-17588-3-git-send-email-broonie@kernel.org>
 <CAOMZO5DZb1wWu93eEHkEqNORhm_hn6qy_LdiRSumP7UODJ3uMw@mail.gmail.com>
Message-ID: <20130701223849.GR27646@sirena.org.uk>

On Mon, Jul 01, 2013 at 06:47:00PM -0300, Fabio Estevam wrote:
> On Mon, Jul 1, 2013 at 6:36 PM, Mark Brown <broonie at kernel.org> wrote:

> >         i2c at 12C90000 {
> > -               status = "disabled";
> > +               wm1811a at 11 {
> > +                       compatible = "wlf,wm1811";
> > +                       reg = <0x1a>;

> Shouldn't it be reg = <0x11> ? Or wm1811a at 1a ?

The @ should change.  Though since it's one of the bits of ornamental
noise DT has rules for :/
-------------- 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/20130701/08101330/attachment.sig>

From ezequiel.garcia at free-electrons.com  Mon Jul  1 18:47:27 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon,  1 Jul 2013 19:47:27 -0300
Subject: [RFC/PATCH 0/2] ARM: kirkwood: Add suspend/resume support
Message-ID: <1372718849-2912-1-git-send-email-ezequiel.garcia@free-electrons.com>

This patchset implements a very basic suspend/resume support on
Kirkwood SoC's, based on the work of Simon Guinot.
Given the CPU itself is not stopped on suspend, but just sits
waiting for interruption, this is more similar to a standby-mode,
than to a real suspend-to-RAM.

In this opportunity, I'm sending this patchset as a very early RFC,
mostly to get some feedback on the first patch that implements the
suspend/resume procedures in the Feroceon CPU. This implemenation
has been copy-pasted from the one in ARM926, since I failed to spot
any differences between the CPU's on that matter.

Maybe someone more knowledgable can take a look and provide some insights.

This applies cleanly on top of v3.10-rc7 and has been tested on an
Openblocks A6 box. Notice that the network controller clock is not gated,
because the driver still needs proper suspend/resume operations.

Thanks a lot!

Ezequiel Garcia (2):
  ARM: feroceon: Add suspend/resume operation
  ARM: kirkwood: Add basic suspend-to-RAM support

 arch/arm/Kconfig                                  |  2 +-
 arch/arm/mach-kirkwood/Makefile                   |  1 +
 arch/arm/mach-kirkwood/include/mach/bridge-regs.h |  2 +
 arch/arm/mach-kirkwood/pm.c                       | 83 +++++++++++++++++++++++
 arch/arm/mm/proc-feroceon.S                       | 26 +++++++
 5 files changed, 113 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-kirkwood/pm.c

-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul  1 18:47:28 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon,  1 Jul 2013 19:47:28 -0300
Subject: [RFC/PATCH 1/2] ARM: feroceon: Add suspend/resume operation
In-Reply-To: <1372718849-2912-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1372718849-2912-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1372718849-2912-2-git-send-email-ezequiel.garcia@free-electrons.com>

Add support for suspend/resume operations. The implemented procedures
are identical to the ones for ARM926.

Cc: Assaf Hoffman <hoffman at marvell.com>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/Kconfig            |  2 +-
 arch/arm/mm/proc-feroceon.S | 26 ++++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2651b1d..a35287b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2207,7 +2207,7 @@ source "kernel/power/Kconfig"
 
 config ARCH_SUSPEND_POSSIBLE
 	depends on !ARCH_S5PC100
-	depends on CPU_ARM920T || CPU_ARM926T || CPU_SA1100 || \
+	depends on CPU_ARM920T || CPU_ARM926T || CPU_FEROCEON || CPU_SA1100 || \
 		CPU_V6 || CPU_V6K || CPU_V7 || CPU_XSC3 || CPU_XSCALE || CPU_MOHAWK
 	def_bool y
 
diff --git a/arch/arm/mm/proc-feroceon.S b/arch/arm/mm/proc-feroceon.S
index 4106b09..ac9201c 100644
--- a/arch/arm/mm/proc-feroceon.S
+++ b/arch/arm/mm/proc-feroceon.S
@@ -514,6 +514,32 @@ ENTRY(cpu_feroceon_set_pte_ext)
 #endif
 	mov	pc, lr
 
+/* Suspend/resume support: taken from arch/arm/mm/proc-arm926.S */
+.globl	cpu_feroceon_suspend_size
+.equ	cpu_feroceon_suspend_size, 4 * 3
+#ifdef CONFIG_ARM_CPU_SUSPEND
+ENTRY(cpu_feroceon_do_suspend)
+	stmfd	sp!, {r4 - r6, lr}
+	mrc	p15, 0, r4, c13, c0, 0	@ PID
+	mrc	p15, 0, r5, c3, c0, 0	@ Domain ID
+	mrc	p15, 0, r6, c1, c0, 0	@ Control register
+	stmia	r0, {r4 - r6}
+	ldmfd	sp!, {r4 - r6, pc}
+ENDPROC(cpu_feroceon_do_suspend)
+
+ENTRY(cpu_feroceon_do_resume)
+	mov	ip, #0
+	mcr	p15, 0, ip, c8, c7, 0	@ invalidate I+D TLBs
+	mcr	p15, 0, ip, c7, c7, 0	@ invalidate I+D caches
+	ldmia	r0, {r4 - r6}
+	mcr	p15, 0, r4, c13, c0, 0	@ PID
+	mcr	p15, 0, r5, c3, c0, 0	@ Domain ID
+	mcr	p15, 0, r1, c2, c0, 0	@ TTB address
+	mov	r0, r6			@ control register
+	b	cpu_resume_mmu
+ENDPROC(cpu_feroceon_do_resume)
+#endif
+
 	__CPUINIT
 
 	.type	__feroceon_setup, #function
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul  1 18:47:29 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon,  1 Jul 2013 19:47:29 -0300
Subject: [RFC/PATCH 2/2] ARM: kirkwood: Add basic suspend-to-RAM support
In-Reply-To: <1372718849-2912-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1372718849-2912-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1372718849-2912-3-git-send-email-ezequiel.garcia@free-electrons.com>

Implements suspend-to-RAM support in a standby-like fashion:
when the SoC enters suspend state the peripheral clocks are gated
and the memory PM units are disabled.

However the network controller clock is not gated for now, since there is
still some work to be done in the driver to provide proper suspend/resume
operations.

Signed-off-by: Simon Guinot <sguinot at lacie.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/mach-kirkwood/Makefile                   |  1 +
 arch/arm/mach-kirkwood/include/mach/bridge-regs.h |  2 +
 arch/arm/mach-kirkwood/pm.c                       | 83 +++++++++++++++++++++++
 3 files changed, 86 insertions(+)
 create mode 100644 arch/arm/mach-kirkwood/pm.c

diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index e1f3735..2c56aa0 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -1,4 +1,5 @@
 obj-y				+= common.o irq.o pcie.o mpp.o
+obj-$(CONFIG_PM)		+= pm.o
 
 obj-$(CONFIG_MACH_D2NET_V2)		+= d2net_v2-setup.o lacie_v2-common.o
 obj-$(CONFIG_MACH_DB88F6281_BP)		+= db88f6281-bp-setup.o
diff --git a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
index 5c82b7d..fad3a35 100644
--- a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
+++ b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
@@ -78,4 +78,6 @@
 #define CGC_TDM			(1 << 20)
 #define CGC_RESERVED		(0x6 << 21)
 
+#define MEMORY_PM_CTRL		(BRIDGE_VIRT_BASE + 0x118)
+
 #endif
diff --git a/arch/arm/mach-kirkwood/pm.c b/arch/arm/mach-kirkwood/pm.c
new file mode 100644
index 0000000..5624b66
--- /dev/null
+++ b/arch/arm/mach-kirkwood/pm.c
@@ -0,0 +1,83 @@
+/*
+ * Power Management driver for Marvell Kirkwood SoCs
+ *
+ * Copyright (C) 2013 Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
+ * Copyright (C) 2010 Simon Guinot <sguinot at lacie.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License,
+ * version 2 of the License.
+ *
+ * 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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/suspend.h>
+#include <linux/io.h>
+#include <mach/bridge-regs.h>
+
+
+static void __iomem *ddr_operation_base;
+
+static void kirkwood_suspend_mem(void)
+{
+	u32 clk_ctrl, mem_pm_ctrl;
+
+	clk_ctrl = readl(CLOCK_GATING_CTRL);
+	mem_pm_ctrl = readl(MEMORY_PM_CTRL);
+
+	/*
+	 * Gate clocks, except for so-called 'Runit' unit, which apparently
+	 * corresponds to NAND, SPI and BootROM.
+	 *
+	 * Also, we skip the gating of the GE0 and GE1 clocks for now.
+	 *
+	 * Contrary to my expectation, the SDRAM clock can also be disabled and
+	 * the suspend-resume cycle will complete successfully.
+	 */
+	writel(CGC_GE1 | CGC_GE0 | CGC_RUNIT, CLOCK_GATING_CTRL);
+
+	/* Set peripherals to low-power mode */
+	writel(~0, MEMORY_PM_CTRL);
+
+	/*
+	 * Set DDR in self-refresh.
+	 */
+	writel(0x7, ddr_operation_base);
+
+	/*
+	 * Set CPU in wait-for-interrupt state.
+	 */
+	cpu_do_idle();
+
+	writel(mem_pm_ctrl, MEMORY_PM_CTRL);
+	writel(clk_ctrl, CLOCK_GATING_CTRL);
+}
+
+static int kirkwood_suspend_enter(suspend_state_t state)
+{
+	switch (state) {
+	case PM_SUSPEND_MEM:
+		kirkwood_suspend_mem();
+		break;
+	default:
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static const struct platform_suspend_ops kirkwood_suspend_ops = {
+	.enter = kirkwood_suspend_enter,
+	.valid = suspend_valid_only_mem,
+};
+
+static int __init kirkwood_pm_init(void)
+{
+	ddr_operation_base = ioremap(DDR_OPERATION_BASE, 4);
+	suspend_set_ops(&kirkwood_suspend_ops);
+	return 0;
+}
+arch_initcall(kirkwood_pm_init);
-- 
1.8.1.5



From r.schwebel at pengutronix.de  Mon Jul  1 18:55:03 2013
From: r.schwebel at pengutronix.de (Robert Schwebel)
Date: Tue, 2 Jul 2013 00:55:03 +0200
Subject: [PATCH 1/2] ARM: dts: mx53qsb: Enable VPU support
In-Reply-To: <1372683396.4971.35.camel@pizza.hi.pengutronix.de>
References: <1372459759-10488-1-git-send-email-festevam@gmail.com>
 <1372683396.4971.35.camel@pizza.hi.pengutronix.de>
Message-ID: <20130701225503.GU4634@pengutronix.de>

On Mon, Jul 01, 2013 at 02:56:36PM +0200, Philipp Zabel wrote:
> /*
>  * The CODA driver needs the raw firmware without header in memory order.
>  * This is how I converted vpu_fw_imx53.bin from the Freescale BSP into
>  * v4l2-coda7541-imx53.bin:
>  */

That code sniplet should get a GPL license header.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From swarren at wwwdotorg.org  Mon Jul  1 19:07:46 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 01 Jul 2013 17:07:46 -0600
Subject: [PATCH 03/23] ARM: dt: tegra30: iommu: Add "nvidia,
 memory-clients"
In-Reply-To: <20130626101816.GE27083@manwe>
References: <1372238906-9346-4-git-send-email-hdoyu@nvidia.com>
 <20130626101816.GE27083@manwe>
Message-ID: <51D20BC2.4090302@wwwdotorg.org>

On 06/26/2013 04:18 AM, Thierry Reding wrote:
> On Wed, Jun 26, 2013 at 12:28:06PM +0300, Hiroshi Doyu wrote: 
> [...]
>> diff --git
>> a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
>> b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
>
>> 
[...]
>> @@ -23,3 +24,13 @@ Example: nvidia,swgroups = <0x00000000
>> 0x000779ff>; nvidia,ahb = <&ahb>; }; + +	host1x { +		compatible =
>> "nvidia,tegra30-host1x", "simple-bus"; +		nvidia,memory-clients =
>> <SWGID_HC>;
> 
> And this could use the SWGID(HC) to match up with how GPIOs are 
> referenced in the DTS files.

I only made TEGRA_GPIO(bank, id) a macro because there was a regular
bank/id structure to the GPIO numbering. I haven't read these patches
yet, but I assume SWGIDs are just a flat numbering space with
arbitrarily assigned number in HW, so there's no much point saying
SWGID(X) rather than SWGID_X.


From swarren at wwwdotorg.org  Mon Jul  1 19:10:01 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 01 Jul 2013 17:10:01 -0600
Subject: [PATCH 06/23] ARM: dt: tegra114: iommu: Add "nvidia,swgroups"
In-Reply-To: <20130701.112446.119298599375396428.hdoyu@nvidia.com>
References: <1372238906-9346-7-git-send-email-hdoyu@nvidia.com><20130626105216.GL27083@manwe>
 <20130701.112446.119298599375396428.hdoyu@nvidia.com>
Message-ID: <51D20C49.2020802@wwwdotorg.org>

On 07/01/2013 02:24 AM, Hiroshi Doyu wrote:
> Thierry Reding <thierry.reding at gmail.com> wrote @ Wed, 26 Jun 2013 12:52:17 +0200:
>> On Wed, Jun 26, 2013 at 12:28:09PM +0300, Hiroshi Doyu wrote:
>>> This is a bitmap that indicates which HardWare Accelerators(HWA) are
>>> supported on Tegra114 SoC.
...
>> It seems like an nvidia,tegra114-smmu.txt file is missing from the
>> Documentation/devicetree/bindings/iommu directory.
> 
> All difference between T30 and T114 is now provided from DT. They have
> all same entries but only those values are different.
> 
> Do we still need a copy of nvidia,tegra30-smmu.txt for t114 or is just
> tweaking nvidia,tegra30-smmu.txt for t114 enough?

If the two HW are identical (at least as far as bindings), the existing
nvidia,tegra30-smmu.txt should be enough. We probably should at least
update it to list the additional supported compatible value though,
especially if the driver interprets the two compatible values in a
different way (e.g. there are HW differences, but they don't affect the
binding definition).


From swarren at wwwdotorg.org  Mon Jul  1 19:11:31 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 01 Jul 2013 17:11:31 -0600
Subject: [PATCH 19/23] iommu/tegra: smmu: Unfied driver for Tegra SoCs
In-Reply-To: <20130701.113259.1041478084393668638.hdoyu@nvidia.com>
References: <1372238906-9346-20-git-send-email-hdoyu@nvidia.com><20130626110747.GP27083@manwe>
 <20130701.113259.1041478084393668638.hdoyu@nvidia.com>
Message-ID: <51D20CA3.1040105@wwwdotorg.org>

On 07/01/2013 02:32 AM, Hiroshi Doyu wrote:
> Thierry Reding <thierry.reding at gmail.com> wrote @ Wed, 26 Jun 2013 13:07:47 +0200:
>> On Wed, Jun 26, 2013 at 12:28:22PM +0300, Hiroshi Doyu wrote:
>>> Support multiple generation of Tegra SoCs with this unified
>>> SMMU driver. Necessary info is expected to be passed from DT.

>>> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c

>>> - * IOMMU API for SMMU in Tegra30
>>> + * IOMMU API for SMMU in Tegra SoC
>>
>> Maybe "Tegra30 and later SoCs" given that Tegra20 has no compatible
>> IOMMU?
>>
>>> -MODULE_DESCRIPTION("IOMMU API for SMMU in Tegra30");
>>> +MODULE_DESCRIPTION("IOMMU API for SMMU in Tegra SoC");
>>
>> Same here.
> 
> Currently most of Tegra SoC has SMMU, and which doesn't have can be
> identified from DT. IMHO, we don't have to be so strict on this
> decritpions. Otherwise, we would need to list up which one (doesn't)
> has whenever a new one comes?

I would just say "Tegra30" here. The fact that other SoCs use the same
HW block (or one compatible with it) doesn't really warrant changing
those comments.


From robdclark at gmail.com  Mon Jul  1 19:33:14 2013
From: robdclark at gmail.com (Rob Clark)
Date: Mon, 1 Jul 2013 19:33:14 -0400
Subject: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver
In-Reply-To: <CAPM=9tzaCyuut=fkGCDCqi1cFirPF-G4GRWYdRDGUfRCc-C7-w@mail.gmail.com>
References: <20130629225210.GF3353@n2100.arm.linux.org.uk>
 <E1Ut41C-0000wl-Ff@rmk-PC.arm.linux.org.uk>
 <20130630115941.GG18285@phenom.ffwll.local>
 <20130630125238.GH3353@n2100.arm.linux.org.uk>
 <CAPM=9tydcpP2-A6fnnHB873Nekj4HnxjraZ3TtRG3UF-Bqa6OQ@mail.gmail.com>
 <51D14333.40307@gmail.com>
 <20130701094258.GT18285@phenom.ffwll.local>
 <51D15F13.7040408@gmail.com>
 <CAPM=9tzaCyuut=fkGCDCqi1cFirPF-G4GRWYdRDGUfRCc-C7-w@mail.gmail.com>
Message-ID: <CAF6AEGtMa+hOAgGO47H8Lkwqs9OdX8m-H0i6YCOhu5upbnPV3w@mail.gmail.com>

On Mon, Jul 1, 2013 at 5:26 PM, Dave Airlie <airlied at gmail.com> wrote:
>> Of course, I share the idea of true, full-blown of_drm_something
>> helpers. But the DT patch, is not an improvement but a real fix as in
>> "make DRM not break on some platforms". From that on, I can start
>> digging into DRM API and improve DT support here and there.
>>
>> So for the three patches I mentioned above, they are all minor
>> improvements of the API. Minor, because I cannot ever sent _the_ single
>> perfect patch just because I don't know the API well enough, yet.
>>
>> Just based on my personal experience: TDA998x driver got merged the way it
>> is _although_ I addressed some concerns - the fixes are not merged
>> _although_ I provided experimental results. This is of course
>> disappointing for me, but I am sure it will work out soon and I will
>> get back to happily send improvements for the platforms I can test on.
>
> To be honest I've no idea what those tda998x patches could fix or
> break, so they go on my no ideas list and I hope if they get reposted
> someone will tell me what they do.

IIRC, a few of those patches were breaking things on tilcdc, which
someone needs to get to the bottom of..  and for that I'm relying a
bit on Darren as he is the one with both hw to test with tilcdc plus
an hdmi tester.  And I think understands the issue better than I do at
this point.

> I could probably be more motivated towards poking other people to
> review stuff, but I mostly hope in vain that the ARM people will cross
> review things for other ARM chips, I had a bit of that happening for a
> while at the start, but it seems to have died off. Now I'm mostly
> relying on Rob to have some clue what I'm merging is sane.
>
> My current priority for merging stuff is:
> core patches that affect all platforms,
> core patches that affect x86
> drivers that I maintain by default
> core patches that affect ARM
> misc ARM drivers that fall through cracks.
>
> Maybe I can persuade Rob to become a sub maintainer for all of the SoC
> drivers but I suspect he'd try and hurt me in real life.

/me runs :-P

well, anyways, I do at least try to review arm patches.  Things
sometimes do fall on the floor when I'm busy in other areas.

BR,
-R

> I'll take another look at the tda patches but I may still have no idea
> what they are doing.
>
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


From mturquette at linaro.org  Mon Jul  1 19:36:14 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 01 Jul 2013 16:36:14 -0700
Subject: [GIT PULL] clk: changes for 3.11
Message-ID: <20130701233614.10823.24820@quantum>

The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b:

  Linux 3.10-rc3 (2013-05-26 16:00:47 -0700)

are available in the git repository at:

  git://git.linaro.org/people/mturquette/linux.git tags/clk-for-linus-3.11

for you to fetch changes up to 45e3ec3784aec0d194740b75b547bfabca448ff3:

  clk: tegra: fix ifdef for tegra_periph_reset_assert inline (2013-06-24 14:17:59 -0700)

----------------------------------------------------------------
The common clock framework changes for 3.11 include new clock drivers
across several different platforms and architectures, fixes to existing
drivers, a MAINTAINERS file fix and improvements to the basic clock
types that allow them to be of use to more platforms than before. Only a
few fixes to the core framework are included with most all of the
changes landing in the various clock drivers themselves.

----------------------------------------------------------------
Alexandre Courbot (1):
      clk: tegra114: correctly output clk_32k

Arnd Bergmann (1):
      clk: tegra: provide tegra_periph_reset_assert alternative

Axel Lin (2):
      clk: wm831x: Fix update wrong register for enable/disable FLL
      clk: wm831x: Fix wm831x_clkout_get_parent

Daniel Tang (1):
      clk: Add TI-Nspire clock drivers

Fabio Baltieri (1):
      clk: ux500: abx500-clk: rename ux500 audio codec aliases

Giacomo A. Catenazzi (1):
      clk: sunxi: "cpu_data" is defined in header files of some architectures

Haojian Zhuang (3):
      clk: mux: add CLK_MUX_HIWORD_MASK
      clk: divider: add CLK_DIVIDER_HIWORD_MASK flag
      clk: gate: add CLK_GATE_HIWORD_MASK

Heiko St?bner (1):
      clk: add support for Rockchip gate clocks

Jean-Francois Moine (1):
      clk: si5351: declare all device IDs for module loading

Jingoo Han (1):
      clk: use platform_{get,set}_drvdata()

Maxime Ripard (1):
      clk: sun5i: Add compatibles for Allwinner A13

Mikko Perttunen (1):
      clk: tegra114: Fix msenc clock register

Paul Walmsley (3):
      clk: tegra: T114: add FCPU clock shaper programming, needed by the DFLL
      clk: tegra: T114: add DFLL source clocks
      clk: tegra: T114: add DFLL DVCO reset control

Pawel Moll (2):
      clk: vexpress: Use full node name to identify individual clocks
      clk: vexpress: Make the clock drivers directly available for arm64

Peter De Schrijver (12):
      clk: tegra: pllc and pllxc should use pdiv_map
      clk: tegra: pllp_out2 divider is int only
      clk: tegra: allow PLL m,n,p init from SoC files
      clk: tegra: PLL m,n,p init for Tegra114
      clk: tegra: fix pllre initilization
      clk: tegra: fix sclk_parents
      clk: tegra: Add fields for override bits
      clk: tegra: override bits for Tegra114 PLLM
      clk: tegra: override bits for Tegra30 PLLM
      clk: tegra: Use override bits when needed
      clk: use clk_get_rate() for debugfs
      clk: honor CLK_GET_RATE_NOCACHE in clk_set_rate

Philippe Begnic (4):
      clk: ux500: Pass clock base adresses in initcall for u8540 and u9540
      mfd: db8500: Update register definition for u8540 clock
      mfd: db8500: Update BML clock register for db8580
      clk: ux500: Clocks definition for u8540

Prashant Gaikwad (2):
      clk: tegra: fix clk_out parents list
      clk: tegra: Use common of_clk_init function

Saravana Kannan (2):
      clk: Fix race condition between clk_set_parent and clk_enable()
      clk: Disable unused clocks after deferred probing is done

Sebastian Hesselbarth (3):
      clk: si5351: Allow user to define disabled state for every clock output
      clk: add non CONFIG_OF routines for clk-provider
      clk: si5351: Allow to build without CONFIG_OF

Shawn Guo (1):
      clk: divider: do not propagate rate change request when unnecessary

Soren Brinkmann (1):
      clk: Always notify whole subtree when reparenting

Stephen Warren (2):
      MAINTAINERS: make drivers/clk entry match subdirs
      clk: tegra: fix ifdef for tegra_periph_reset_assert inline

Tang Yuantian (2):
      clk: add PowerPC corenet clock driver support
      clk: mpc85xx: Update the compatible string

Tony Prisk (2):
      clk: vt8500: Add support for clocks on the WM8850 SoCs
      clk: vt8500: Remove unnecessary divisor adjustment in vtwm_dclk_set_rate()

Tushar Behera (4):
      clk: exynos5250: Update cpufreq related clocks for EXYNOS5250
      clk: exynos5250: Add sclk_mpll to the parent list of mout_cpu clock
      clk: samsung: Add MUX_FA macro to pass flag and alias
      clk: exynos4: Fix clock aliases for cpufreq related clocks

 .../devicetree/bindings/clock/nspire-clock.txt     |  24 +
 .../devicetree/bindings/clock/rockchip.txt         |  74 +++
 .../devicetree/bindings/clock/silabs,si5351.txt    |   5 +
 Documentation/devicetree/bindings/clock/sunxi.txt  | 117 +----
 .../bindings/clock/sunxi/sun4i-a10-gates.txt       |  93 ++++
 .../bindings/clock/sunxi/sun5i-a13-gates.txt       |  58 +++
 Documentation/devicetree/bindings/clock/vt8500.txt |   2 +
 MAINTAINERS                                        |   5 +-
 arch/arm/mach-tegra/common.c                       |   4 +-
 arch/arm/mach-ux500/cpu.c                          |   6 +-
 arch/powerpc/platforms/Kconfig.cputype             |   1 +
 drivers/clk/Kconfig                                |  10 +-
 drivers/clk/Makefile                               |   3 +
 drivers/clk/clk-divider.c                          |  25 +-
 drivers/clk/clk-gate.c                             |  25 +-
 drivers/clk/clk-mux.c                              |  17 +-
 drivers/clk/clk-nspire.c                           | 153 ++++++
 drivers/clk/clk-ppc-corenet.c                      | 280 ++++++++++
 drivers/clk/clk-si5351.c                           |  79 ++-
 drivers/clk/clk-si5351.h                           |   1 +
 drivers/clk/clk-twl6040.c                          |   4 +-
 drivers/clk/clk-vt8500.c                           |  75 ++-
 drivers/clk/clk-wm831x.c                           |  14 +-
 drivers/clk/clk.c                                  | 100 ++--
 drivers/clk/rockchip/Makefile                      |   5 +
 drivers/clk/rockchip/clk-rockchip.c                |  94 ++++
 drivers/clk/samsung/clk-exynos4.c                  |  21 +-
 drivers/clk/samsung/clk-exynos5250.c               |   8 +-
 drivers/clk/samsung/clk.h                          |   3 +
 drivers/clk/sunxi/clk-sunxi.c                      |  35 +-
 drivers/clk/tegra/clk-pll.c                        | 281 +++++-----
 drivers/clk/tegra/clk-tegra114.c                   | 270 +++++++++-
 drivers/clk/tegra/clk-tegra20.c                    |   3 +-
 drivers/clk/tegra/clk-tegra30.c                    |  25 +-
 drivers/clk/tegra/clk.c                            |  12 -
 drivers/clk/tegra/clk.h                            |  62 +--
 drivers/clk/ux500/abx500-clk.c                     |   8 +-
 drivers/clk/ux500/u8540_clk.c                      | 564 ++++++++++++++++++++-
 drivers/clk/ux500/u9540_clk.c                      |   4 +-
 drivers/clk/versatile/clk-vexpress-osc.c           |   4 +-
 drivers/mfd/db8500-prcmu.c                         |   1 +
 drivers/mfd/dbx500-prcmu-regs.h                    |   1 +
 include/linux/clk-provider.h                       |  62 ++-
 include/linux/clk/tegra.h                          |   6 +-
 include/linux/mfd/abx500/ab8500-sysctrl.h          |   4 +-
 include/linux/mfd/dbx500-prcmu.h                   |  12 +
 include/linux/platform_data/clk-ux500.h            |   6 +-
 include/linux/platform_data/si5351.h               |  18 +
 48 files changed, 2265 insertions(+), 419 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/nspire-clock.txt
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip.txt
 create mode 100644 Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
 create mode 100644 Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt
 create mode 100644 drivers/clk/clk-nspire.c
 create mode 100644 drivers/clk/clk-ppc-corenet.c
 create mode 100644 drivers/clk/rockchip/Makefile
 create mode 100644 drivers/clk/rockchip/clk-rockchip.c


From khilman at linaro.org  Mon Jul  1 20:06:38 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Mon, 01 Jul 2013 17:06:38 -0700
Subject: [PATCH 1/4] rtc: omap: restore back (hard-code) wakeup support
In-Reply-To: <1372412109-986-2-git-send-email-gururaja.hebbar@ti.com> (Hebbar
 Gururaja's message of "Fri, 28 Jun 2013 15:05:06 +0530")
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-2-git-send-email-gururaja.hebbar@ti.com>
Message-ID: <87ehbhomep.fsf@linaro.org>

Hebbar Gururaja <gururaja.hebbar at ti.com> writes:

> rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms.
>
> However, rtc wake support on OMAP1 is broken. Hence the
> device_init_wakeup() was removed from rtc-omap driver and moved to
> platform board files that supported it (DA850/OMAP-L138). [1]
>
> However, recently [2] it was suggested that driver should always do a
> device_init_wakeup(dev, true). Platforms that don't want/need
> wakeup support can disable it from userspace via:
>
>     echo disabled > /sys/devices/.../power/wakeup
>
> Also, with the new DT boot-up, board file doesn't exist and hence there
> is no way to have device wakeup support rtc.
>
> The fix for above issues, is to hard code device_init_wakeup() inside
> driver and let platforms that don't need this, handle it through the
> sysfs power entry.
>
> [1]
> https://patchwork.kernel.org/patch/136731/
>
> [2]
> http://www.mail-archive.com/davinci-linux-open-source at linux.
> davincidsp.com/msg26077.html
>
> Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> Cc: Alessandro Zummo <a.zummo at towertech.it>
> Cc: rtc-linux at googlegroups.com

Acked-by: Kevin Hilman <khilman at linaro.org>

> ---
> :100644 100644 b0ba3fc... 761919d... M	drivers/rtc/rtc-omap.c
>  drivers/rtc/rtc-omap.c |    2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index b0ba3fc..761919d 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -423,6 +423,8 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  	 *    is write-only, and always reads as zero...)
>  	 */
>  
> +	device_init_wakeup(&pdev->dev, true);
> +
>  	if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
>  		pr_info("%s: split power mode\n", pdev->name);


From khilman at linaro.org  Mon Jul  1 20:07:43 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Mon, 01 Jul 2013 17:07:43 -0700
Subject: [PATCH 2/4] davinci: da8xx/omap-l1: Remove hard coding of rtc
 device wakeup
In-Reply-To: <1372412109-986-3-git-send-email-gururaja.hebbar@ti.com> (Hebbar
 Gururaja's message of "Fri, 28 Jun 2013 15:05:07 +0530")
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-3-git-send-email-gururaja.hebbar@ti.com>
Message-ID: <87a9m5omcw.fsf@linaro.org>

Hebbar Gururaja <gururaja.hebbar at ti.com> writes:

> Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
> duplicate call from the rtc device registration can be removed.
>
> This is basically a partial revert of the prev commit
>
> commit 75c99bb0006ee065b4e2995078d779418b0fab54
> Author: Sekhar Nori <nsekhar at ti.com>
>
>     davinci: da8xx/omap-l1: mark RTC as a wakeup source
>
> Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> Cc: Sekhar Nori <nsekhar at ti.com>
> Cc: Kevin Hilman <khilman at linaro.org>
> Cc: Russell King <linux at arm.linux.org.uk>
>
> ---
> :100644 100644 bf57252... 85a900c... M	arch/arm/mach-davinci/devices-da8xx.c
>  arch/arm/mach-davinci/devices-da8xx.c |    9 +--------
>  1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index bf57252..85a900c 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -827,14 +827,7 @@ static struct platform_device da8xx_rtc_device = {
>  
>  int da8xx_register_rtc(void)
>  {
> -	int ret;
> -
> -	ret = platform_device_register(&da8xx_rtc_device);
> -	if (!ret)
> -		/* Atleast on DA850, RTC is a wakeup source */
> -		device_init_wakeup(&da8xx_rtc_device.dev, true);
> -
> -	return ret;
> +	return  platform_device_register(&da8xx_rtc_device);

nit: extra space between 'return' and 'platform_'

>  }
>  
>  static void __iomem *da8xx_ddr2_ctlr_base;

Otherwise,

Acked-by: Kevin Hilman <khilman at linaro.org>



From khilman at linaro.org  Mon Jul  1 20:15:01 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Mon, 01 Jul 2013 17:15:01 -0700
Subject: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
In-Reply-To: <1372412109-986-4-git-send-email-gururaja.hebbar@ti.com> (Hebbar
 Gururaja's message of "Fri, 28 Jun 2013 15:05:08 +0530")
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-4-git-send-email-gururaja.hebbar@ti.com>
Message-ID: <871u7hom0q.fsf@linaro.org>

Hebbar Gururaja <gururaja.hebbar at ti.com> writes:

> On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
> is available to enable Alarm Wakeup feature. This register needs to be
> properly handled for the rtcwake to work properly.
>
> Platforms using such IP should set "ti,am3352-rtc" in rtc device dt
> compatibility node.
>
> Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> Cc: Grant Likely <grant.likely at linaro.org>
> Cc: Rob Herring <rob.herring at calxeda.com>
> Cc: Rob Landley <rob at landley.net>
> Cc: Sekhar Nori <nsekhar at ti.com>
> Cc: Kevin Hilman <khilman at linaro.org>
> Cc: Alessandro Zummo <a.zummo at towertech.it>
> Cc: rtc-linux at googlegroups.com
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: linux-doc at vger.kernel.org

Acked-by: Kevin Hilman <khilman at linaro.org>

...with a minor nit below...

> ---
> :100644 100644 b47aa41... 5a0f02d... M	Documentation/devicetree/bindings/rtc/rtc-omap.txt
> :100644 100644 761919d... 666b0c2... M	drivers/rtc/rtc-omap.c
>  Documentation/devicetree/bindings/rtc/rtc-omap.txt |    6 ++-
>  drivers/rtc/rtc-omap.c                             |   56 +++++++++++++++++---
>  2 files changed, 54 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> index b47aa41..5a0f02d 100644
> --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> @@ -1,7 +1,11 @@
>  TI Real Time Clock
>  
>  Required properties:
> -- compatible: "ti,da830-rtc"
> +- compatible:
> +	- "ti,da830-rtc"  - for RTC IP used similar to that on DA8xx SoC family.
> +	- "ti,am3352-rtc" - for RTC IP used similar to that on AM335x SoC family.
> +			    This RTC IP has special WAKE-EN Register to enable
> +			    Wakeup generation for event Alarm.
>  - reg: Address range of rtc register set
>  - interrupts: rtc timer, alarm interrupts in order
>  - interrupt-parent: phandle for the interrupt controller
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 761919d..666b0c2 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -72,6 +72,8 @@
>  #define OMAP_RTC_KICK0_REG		0x6c
>  #define OMAP_RTC_KICK1_REG		0x70
>  
> +#define OMAP_RTC_IRQWAKEEN		0x7C
> +

nit: letters in hex numbers are usually lower-case.


Kevin


From khilman at linaro.org  Mon Jul  1 20:18:54 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Mon, 01 Jul 2013 17:18:54 -0700
Subject: [PATCH 0/4] rtc: omap: handle rtc wakeup support in driver
In-Reply-To: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com> (Hebbar
 Gururaja's message of "Fri, 28 Jun 2013 15:05:05 +0530")
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
Message-ID: <87sizxn79t.fsf@linaro.org>

Hi Hebbar,

Hebbar Gururaja <gururaja.hebbar at ti.com> writes:

> rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms.
>
> However, rtc wake support on OMAP1 is broken. Hence the
> device_init_wakeup() was removed from rtc-omap driver and moved to
> platform board files that supported it (DA850/OMAP-L138). [1]
>
> However, recently [2] it was suggested that driver should always do a
> device_init_wakeup(dev, true). Platforms that don't want/need
> wakeup support can disable it from userspace via:
>
>     echo disabled > /sys/devices/.../power/wakeup
>
> Also, with the new DT boot-up, board file doesn't exist and hence there
> is no way to have device wakeup support rtc.
>
> The fix for above issues, is to hard code device_init_wakeup() inside
> driver and let platforms that don't need this, handle it through the
> sysfs power entry.

This series looks good now, thanks for your persistence.

Kevin


From josephl at nvidia.com  Mon Jul  1 20:49:48 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Jul 2013 08:49:48 +0800
Subject: [PATCH V3 0/3] ARM: tegra114: cpuidle: add power down state
In-Reply-To: <51D1BEAD.6060003@wwwdotorg.org>
References: <1372152242-16373-1-git-send-email-josephl@nvidia.com>
 <51D1BEAD.6060003@wwwdotorg.org>
Message-ID: <1372726188.2874.6.camel@jlo-ubuntu-64.nvidia.com>

On Tue, 2013-07-02 at 01:38 +0800, Stephen Warren wrote:
> On 06/25/2013 03:23 AM, Joseph Lo wrote:
> > This series introduce CPU core power down state for CPU idle. When CPU go
> > into this state, it saves it's context and needs a proper configuration
> > in flow controller to power gate the CPU when CPU runs into WFI
> > instruction. And the CPU also needs to set the IRQ as CPU power down idle
> > wake up event in flow controller.
> > 
> > To prevent race conditions and ensure proper interrupt routing on
> > Cortex-A15 CPUs when they are power-gated, add a CPU PM notifier
> > call-back to reprogram the GIC CPU interface on PM entry. The
> > GIC CPU interface will be reset back to its normal state by
> > the common GIC CPU PM exit callback when the CPU wakes up.
> > 
> > This series depends on the patch of "tick:  Fix
> > tick_broadcast_pending_mask not cleared".
> 
> Joseph, I applied all 3 of your patches/series on top of next-20130701,
> which does include dependency "tick:  Fix tick_broadcast_pending_mask
> not cleared":
> 
> * ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
> * This series
> * ARM: tegra114: add support for system suspend
> 
> I find that at least on on Tegra114/Dalmore, CPU hotplug doesn't work
> correctly.
> 
Yes, it's due to the CPU hotplug function broken in next-20130701. The
last working version was next-20130624 that I had tested and verified.
It also breaks the resume function when enable non-boot CPUs. You can
verify the suspend function by un-plug secondary CPUs first. I am
checking what cause the CPU hotplug function broken on next-20130701.

Thanks,
Joseph




From michael at ellerman.id.au  Mon Jul  1 20:53:16 2013
From: michael at ellerman.id.au (Michael Ellerman)
Date: Tue, 02 Jul 2013 10:53:16 +1000
Subject: [PATCHv4 02/11] pci: use weak functions for MSI arch-specific
 functions
In-Reply-To: <1372686136-1370-3-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-3-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1372726396.17904.1.camel@concordia>

On Mon, 2013-07-01 at 15:42 +0200, Thomas Petazzoni wrote:
> Until now, the MSI architecture-specific functions could be overloaded
> using a fairly complex set of #define and compile-time
> conditionals. In order to prepare for the introduction of the msi_chip
> infrastructure, it is desirable to switch all those functions to use
> the 'weak' mechanism. This commit converts all the architectures that
> were overidding those MSI functions to use the new strategy.

The MSI code used to use weak functions, until we discovered they were
being miscompiled on some toolchains (11df1f0). I assume these days
we're confident they work correctly.

cheers




From horms at verge.net.au  Mon Jul  1 21:22:28 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Jul 2013 10:22:28 +0900
Subject: [PATCH v4 2/3] ARM: shmobile: lager: enable Ether
In-Reply-To: <1870016.uXUUSHgrj5@avalon>
References: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
 <1372663234-13486-3-git-send-email-horms+renesas@verge.net.au>
 <1870016.uXUUSHgrj5@avalon>
Message-ID: <20130702012227.GA24086@verge.net.au>

On Mon, Jul 01, 2013 at 03:29:21PM +0200, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Monday 01 July 2013 16:20:33 Simon Horman wrote:
> > Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> > Cc: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> > 
> > ---
> > 
> > This patch has a build-time dependency on "sh_eth: add support for gpio
> > reset". This patch has a run-time dependency on "sh_eth: add support for
> > r8a7790 SoC".
> > 
> > v4
> > * Annotate ether_platdata as __initdata
> > 
> > v3
> > * Rebase
> > 
> > v2
> > * As suggested by Laurent Pinchart
> >   - Do not manipilate sh_eth reset GPIO directly,
> >     rather, do so through newly proposed support for this in
> >     the sh_eth driver.
> > * A suggested by Sergei Shtylyov
> >   - Move DTS portion into a separate patch
> > ---
> >  arch/arm/mach-shmobile/board-lager.c | 24 ++++++++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> > 
> > diff --git a/arch/arm/mach-shmobile/board-lager.c
> > b/arch/arm/mach-shmobile/board-lager.c index 0b4a1f9..7d5db20 100644
> > --- a/arch/arm/mach-shmobile/board-lager.c
> > +++ b/arch/arm/mach-shmobile/board-lager.c
> > @@ -71,6 +71,17 @@ static __initdata struct gpio_keys_platform_data
> > lager_keys_pdata = { .nbuttons	= ARRAY_SIZE(gpio_buttons),
> >  };
> > 
> > +/* Ether */
> > +static struct sh_eth_plat_data ether_platdata __initdata = {
> > +	.phy			= 0x1,
> > +	.edmac_endian		= EDMAC_LITTLE_ENDIAN,
> > +	.register_type		= SH_ETH_REG_FAST_RCAR,
> > +	.phy_interface		= PHY_INTERFACE_MODE_RMII,
> > +	.ether_link_active_low	= 1,
> > +	.needs_gpio_reset	= 1,
> > +	.reset_gpio		= RCAR_GP_PIN(5, 31),
> > +};
> > +
> >  static const struct pinctrl_map lager_pinctrl_map[] = {
> >  	/* SCIF0 (CN19: DEBUG SERIAL0) */
> >  	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7790",
> > @@ -78,6 +89,17 @@ static const struct pinctrl_map lager_pinctrl_map[] = {
> >  	/* SCIF1 (CN20: DEBUG SERIAL1) */
> >  	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.7", "pfc-r8a7790",
> >  				  "scif1_data", "scif1"),
> > +	/* Ether */
> > +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> > +				  "eth_link", "eth"),
> > +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> > +				  "eth_magic", "eth"),
> 
> That pin isn't used on Lager, you can drop it.

Thanks, I will drop that.

> By the way, the latest R8A7790 datasheet errata renamed the eth_magic pin to 
> eth_wol. What would you think about renaming it to eth_wol in 
> drivers/pinctrl/sh-pfc/pfc-r8a7790.c ?

I do not have a strong opinion but changing it sounds entirely reasonable
to me.

> > +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> > +				  "eth_mdio", "eth"),
> > +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> > +				  "eth_rmii", "eth"),
> > +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> > +				  "intc_irq0", "intc"),
> >  };
> > 
> >  static void __init lager_add_standard_devices(void)
> > @@ -89,6 +111,8 @@ static void __init lager_add_standard_devices(void)
> >  	r8a7790_pinmux_init();
> > 
> >  	r8a7790_add_standard_devices();
> > +	r8a7790_add_ether_device(&ether_platdata);
> > +
> >  	platform_device_register_data(&platform_bus, "leds-gpio", -1,
> >  				      &lager_leds_pdata,
> >  				      sizeof(lager_leds_pdata));


From iamjoonsoo.kim at lge.com  Mon Jul  1 21:28:19 2013
From: iamjoonsoo.kim at lge.com (Joonsoo Kim)
Date: Tue, 2 Jul 2013 10:28:19 +0900
Subject: [RFC PATCH 5/6] ARM, mm: change meaning of max_low_pfn to
 maximum pfn for nobootmem
In-Reply-To: <51D18ED5.50103@ti.com>
References: <1364184674-13798-1-git-send-email-iamjoonsoo.kim@lge.com>
 <1364184674-13798-6-git-send-email-iamjoonsoo.kim@lge.com>
 <51D18ED5.50103@ti.com>
Message-ID: <20130702012819.GA31505@lge.com>

On Mon, Jul 01, 2013 at 10:14:45AM -0400, Santosh Shilimkar wrote:
> Joonsoo,
> 
> On Monday 25 March 2013 12:11 AM, Joonsoo Kim wrote:
> > nobootmem use max_low_pfn for computing boundary in free_all_bootmem()
> > So we need proper value to max_low_pfn.
> > 
> > But, there is some difficulty related to max_low_pfn. max_low_pfn is used
> > for two meanings in various architectures. One is for number of pages
> > in lowmem and the other is for maximum lowmem pfn. Now, in ARM, it is used
> > as number of pages in lowmem. You can get more information in below link.
> > http://lwn.net/Articles/543408/
> > http://lwn.net/Articles/543424/
> > 
> > As I investigated, architectures which use max_low_pfn as maximum pfn are
> > more than others, so to change meaning of max_low_pfn to maximum pfn
> > is preferable solution to me. This patch change max_low_pfn as maximum
> > lowmem pfn in ARM. In addition, min_low_pfn, max_pfn is assigned according
> > to this criteria.
> > 
> > There is no real user for max_low_pfn except block/blk-setting.c and
> > blk-setting.c assume that max_low_pfn is maximum lowmem pfn,
> > so this patch may not harm anything.
> > 
> > Signed-off-by: Joonsoo Kim <iamjoonsoo.kim at lge.com>
> >
> I have been also carrying similar patch as yours in an attempt
> to make LPAE kernel work on ARM. Your patch carries better
> description, so will your version and include in my series
> which I plan to post on the list after some more testing.
> Will copy you. The changes are very similar to your series.

Okay!

Thanks.
> 
> Regards,
> Santosh
>  
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


From dsd at laptop.org  Mon Jul  1 21:57:04 2013
From: dsd at laptop.org (Daniel Drake)
Date: Mon, 1 Jul 2013 19:57:04 -0600
Subject: armada_drm clock selection - try 2
In-Reply-To: <51D1F921.9050608@gmail.com>
References: <20130701203009.633A8FAAD5@dev.laptop.org>
 <51D1F921.9050608@gmail.com>
Message-ID: <CAMLZHHRrdazrJwujCWrfzo_fcudtd4GUgMEEN2YScOAZeZ-4vA@mail.gmail.com>

On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
<sebastian.hesselbarth at gmail.com> wrote:
> I guess "extclk0" and "extclk1" should be sufficient for clock names.
> Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g.
> extclk0 simultaneously. See below for .is_dedicated in general.

Maybe we can find better terminology, or just document it a bit
better, but having two CRTCs share the same clock falls within the
scheme designed and implemented there. "Dedicated" simply means a
clock that is dedicated to the display controller, it is not shared by
other devices.

>> +struct armada_clk_info {
>> +       struct clk *clk;
>> +
>> +       /* If this clock is dedicated to us, we can change its rate
>> without
>> +        * worrying about any other users in other parts of the system. */
>> +       bool is_dedicated;
>> +
>> +       /* However, we cannot share the same dedicated clock between two
>> CRTCs
>> +        * if each CRTC wants a different rate. Track the number of users.
>> */
>> +       int usage_count;
>
>
> You can share the same clock between two CRTCs. Just consider CRTC1
> using a mode with half pixel clock as CRTC0. Not that I think this will
> ever happen, but it is possible.

And my implementation already lets that happen - its just that I
didn't document it in enough detail.

> I prefer not to try to find the best clock (source) at all. Let the
> user pass the clock name by e.g. platform_data (or DT) and just try to
> get the requested pixclk or a integer multiple of it. You will never be
> able to find the best clock for all use cases.
>
> Just figure out, if integer division is sufficient to get requested
> pixclk and clk_set_rate otherwise. This may be useful for current mode
> running at 148.5MHz (1080p50) and new mode at 74.25MHz (1080i50, 720p).

I am not opposed to this approach, it is nice and simple, but as
Russell points out we do additionally need to distinguish between
clocks that are "ours" to play with, vs those that are shared with
other devices. It would be a bad idea to try call clk_set_rate() on
the AXI bus clock, for example, changing the clock for a whole bunch
of other devices. This is what the is_dedicated flag is about. However
such a flag could be easily added to the DT/platform data definition
that you propose.

Daniel


From shawn.guo at linaro.org  Mon Jul  1 22:16:53 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 2 Jul 2013 10:16:53 +0800
Subject: [alsa-devel] [PATCH 1/4] ASoC: sgtl5000: give it a ramping time
 before writting
In-Reply-To: <201307011943.27489.marex@denx.de>
References: <1372666571-17276-1-git-send-email-shawn.guo@linaro.org>
 <20130701153327.GX13206@S2101-09.ap.freescale.net>
 <CAOMZO5B5jh1XciO4K1u3yBcHHDAgi8hA3GcywnJd11M7=aOPxA@mail.gmail.com>
 <201307011943.27489.marex@denx.de>
Message-ID: <20130702021651.GY13206@S2101-09.ap.freescale.net>

On Mon, Jul 01, 2013 at 07:43:27PM +0200, Marek Vasut wrote:
> Dear Fabio Estevam,
> 
> > On Mon, Jul 1, 2013 at 12:33 PM, Shawn Guo <shawn.guo at linaro.org> wrote:
> > > On Mon, Jul 01, 2013 at 12:11:58PM -0300, Fabio Estevam wrote:
> > >> On Mon, Jul 1, 2013 at 11:34 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> > >> > And also why we do not see the impact of i2c issue on sgtl5000 before
> > >> > the offending commit af8ee11 (ASoC: sgtl5000: Fix driver probe after
> > >> > reset)?
> > >> 
> > >> Probably because the mxs i2c was working before this commit.
> > > 
> > > Do you have a commit id at which mxs i2c is known good?  I would like to
> > > find out it's a mxs i2c issue or sgtl5000 problem.
> > 
> > I don't have it, but I am adding Alexandre in case he knows.
> > 
> > Alexandre,
> > 
> > Do you happen to know a commit id which does not show the mxs i2c
> > timeouts you have been observing?
> 
> I think you can just disable the PIO mode altogether (around line 500 ... if 
> (msg->len < 8) ... replace this with if (0) ) and then the problem should not be 
> there (if it's a PIO problem).

Ok, Fabio is right. With the change, sgtl5000 write works even without
that msleep(50).

So, Mark, please disregard the patch, and we should fix mxs i2c driver
instead.

Shawn




From r65037 at freescale.com  Mon Jul  1 22:24:56 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Tue, 2 Jul 2013 02:24:56 +0000
Subject: [v2 4/4] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <20130701152955.GW13206@S2101-09.ap.freescale.net>
References: <1372672975-2997-1-git-send-email-r65037@freescale.com>
 <1372672975-2997-5-git-send-email-r65037@freescale.com>
 <20130701124445.GW516@pengutronix.de>
 <20130701152955.GW13206@S2101-09.ap.freescale.net>
Message-ID: <0E83723C55F66F43A6041464FE31119D30C5EF@039-SN2MPN1-013.039d.mgd.msft.net>

Hi Shawn:
Never mind, I misunderstand what you said.

Now, I know what your are expecting now, would prepare the Version3, and send them later.

Best Regards
Richard Zhu


-----Original Message-----
From: Shawn Guo [mailto:shawn.guo at linaro.org] 
Sent: Monday, July 01, 2013 11:30 PM
To: Sascha Hauer
Cc: Richard Zhu; linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; avorontsov at ru.mvista.com; rob.herring at calxeda.com; linux-ide at vger.kernel.org; Zhu Richard-R65037
Subject: Re: [v2 4/4] sata: imx: add ahci sata support on imx platforms

On Mon, Jul 01, 2013 at 02:44:45PM +0200, Sascha Hauer wrote:
> On Mon, Jul 01, 2013 at 06:02:55PM +0800, Richard Zhu wrote:
> > imx6q contains one Synopsys AHCI SATA controller, But it can't 
> > shares ahci_platform driver with other controllers.
> > Because there are some misalignments of the bits definitions of the 
> > HBA registers and the Vendor Specific registers
> >  - CAP_SSS(bit20) of the HOST_CAP is writable, default  value is 
> > '0', should be configured to be '1'
> >  - bit0 (only one AHCI SATA port on imx6q) of the  HOST_PORTS_IMPL 
> > should be set to be '1'.(default 0)
> >  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)  should 
> > be configured regarding to the frequency of AHB  bus clock.
> > 
> > Setup its own ahci sata driver, enable the imx6q ahci sata support, 
> > and update the ahci sata binding document.
> > 
> > Signed-off-by: Richard Zhu <r65037 at freescale.com>
> 
> Wait a minute. We suggested to add a i.MX specific ahci driver to put 
> the i.MX speicific setup in there. Now you really post a separate i.MX 
> driver, but instead of putting the setup in there, it's a nearly 
> identical copy of the generic driver *without* the setup and the setup 
> is still in arch/arm/. That doesn't make sense to me.

+1

Richard,

You could have confused by me with pointing you to the sata_highbank driver.  Sorry.  But Sascha posted his work [1] later in the same thread.  That's obviously the way we should go, and I thought you knew you should start your v2 based on that.  You missed that?

Shawn

[1] http://thread.gmane.org/gmane.linux.ide/54410/focus=54434



From dsd at laptop.org  Mon Jul  1 22:27:33 2013
From: dsd at laptop.org (Daniel Drake)
Date: Mon, 1 Jul 2013 20:27:33 -0600
Subject: [PATCH] mmp: irq: Don't clear unused interrupt enable bits
In-Reply-To: <CAMPhdO8jAN5kCT_tgH4NxTJ=GOGQqXukUrxNWsHExUSXZ+44bA@mail.gmail.com>
References: <20130627175118.8A9FEFAACF@dev.laptop.org>
 <CAMPhdO_Ccp_JeuNNkqP6Q+ubmG8rah_hkxFJmOBsetysu-+dNw@mail.gmail.com>
 <CAMLZHHSS75dSd_PM5-Gu2K-kP+RF0Fx1E+TL=d-TeXzYSLsQPg@mail.gmail.com>
 <CAMPhdO8jAN5kCT_tgH4NxTJ=GOGQqXukUrxNWsHExUSXZ+44bA@mail.gmail.com>
Message-ID: <CAMLZHHTa18d7+Vtw9UiZrKqdw2xhWjkntYUOX56U0iwV2GLmhA@mail.gmail.com>

On Fri, Jun 28, 2013 at 10:55 PM, Eric Miao <eric.y.miao at gmail.com> wrote:
> I'm fine with leaving these bits out as your patch does, the only concern
> is some other code may have a chance to depend on this, and may
> benefit from this boot configuration flexibility as well.

I would prefer to leave them out for simplicity of the driver.
However, I'm happy to weigh in if/when any future need comes up where
Linux needs to be directly involved with SP setup.

Daniel


From b32955 at freescale.com  Mon Jul  1 22:15:29 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 2 Jul 2013 10:15:29 +0800
Subject: [PATCH] ARM: dts: imx: add #dma-cells property for sdma
Message-ID: <1372731329-1016-1-git-send-email-b32955@freescale.com>

Add the #dma-cells property for all the sdma in all the imx platforms.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx25.dtsi   |    1 +
 arch/arm/boot/dts/imx51.dtsi   |    1 +
 arch/arm/boot/dts/imx53.dtsi   |    1 +
 arch/arm/boot/dts/imx6qdl.dtsi |    1 +
 arch/arm/boot/dts/imx6sl.dtsi  |    1 +
 5 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 7011539..1f72862 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -424,6 +424,7 @@
 				reg = <0x53fd4000 0x4000>;
 				clocks = <&clks 112>, <&clks 68>;
 				clock-names = "ipg", "ahb";
+				#dma-cells = <3>;
 				interrupts = <34>;
 			};
 
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 25764b5..40ab745 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -645,6 +645,7 @@
 				interrupts = <6>;
 				clocks = <&clks 56>, <&clks 56>;
 				clock-names = "ipg", "ahb";
+				#dma-cells = <3>;
 				fsl,sdma-ram-script-name = "imx/sdma/sdma-imx51.bin";
 			};
 
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 569aa9f..78bcd9a 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -990,6 +990,7 @@
 				interrupts = <6>;
 				clocks = <&clks 56>, <&clks 56>;
 				clock-names = "ipg", "ahb";
+				#dma-cells = <3>;
 				fsl,sdma-ram-script-name = "imx/sdma/sdma-imx53.bin";
 			};
 
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index f21d259..0509344 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -582,6 +582,7 @@
 				interrupts = <0 2 0x04>;
 				clocks = <&clks 155>, <&clks 155>;
 				clock-names = "ipg", "ahb";
+				#dma-cells = <3>;
 				fsl,sdma-ram-script-name = "imx/sdma/sdma-imx6q.bin";
 			};
 		};
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index c5e5da0..9138c67 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -594,6 +594,7 @@
 				clocks = <&clks IMX6SL_CLK_SDMA>,
 					 <&clks IMX6SL_CLK_SDMA>;
 				clock-names = "ipg", "ahb";
+				#dma-cells = <3>;
 				fsl,sdma-ram-script-name = "imx/sdma/sdma-imx6sl.bin";
 			};
 
-- 
1.7.1




From Baohua.Song at csr.com  Mon Jul  1 22:42:46 2013
From: Baohua.Song at csr.com (Barry Song)
Date: Tue, 2 Jul 2013 10:42:46 +0800
Subject: [PATCH] sdhci:sirf:drop SDHCI_QUIRK_INVERTED_WRITE_PROTECT as only
 sd0 has inverted_wp
Message-ID: <1372732966-9464-1-git-send-email-Baohua.Song@csr.com>

From: Bin Shi <Bin.Shi at csr.com>

only sd0 has the issue that WP is inverted, so we drop the global set of
SDHCI_QUIRK_INVERTED_WRITE_PROTECT and only enable the "wp-inverted" prop
for sd0 in dts.

Signed-off-by: Bin Shi <Bin.Shi at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 arch/arm/boot/dts/atlas6.dtsi | 1 +
 arch/arm/boot/dts/prima2.dtsi | 1 +
 drivers/mmc/host/sdhci-sirf.c | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/atlas6.dtsi b/arch/arm/boot/dts/atlas6.dtsi
index 7d1a279..d928b11 100644
--- a/arch/arm/boot/dts/atlas6.dtsi
+++ b/arch/arm/boot/dts/atlas6.dtsi
@@ -561,6 +561,7 @@
 					interrupts = <38>;
 					bus-width = <8>;
 					clocks = <&clks 36>;
+					wp-inverted;
 				};
 
 				sd1: sdhci at 56100000 {
diff --git a/arch/arm/boot/dts/prima2.dtsi b/arch/arm/boot/dts/prima2.dtsi
index 3329719..36cb064 100644
--- a/arch/arm/boot/dts/prima2.dtsi
+++ b/arch/arm/boot/dts/prima2.dtsi
@@ -557,6 +557,7 @@
 					compatible = "sirf,prima2-sdhc";
 					reg = <0x56000000 0x100000>;
 					interrupts = <38>;
+					wp-inverted;
 				};
 
 				sd1: sdhci at 56100000 {
diff --git a/drivers/mmc/host/sdhci-sirf.c b/drivers/mmc/host/sdhci-sirf.c
index 62a4a83..38e69f7 100644
--- a/drivers/mmc/host/sdhci-sirf.c
+++ b/drivers/mmc/host/sdhci-sirf.c
@@ -36,7 +36,6 @@ static struct sdhci_pltfm_data sdhci_sirf_pdata = {
 	.quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
 		SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
 		SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN |
-		SDHCI_QUIRK_INVERTED_WRITE_PROTECT |
 		SDHCI_QUIRK_DELAY_AFTER_POWER,
 };
 
@@ -70,6 +69,7 @@ static int sdhci_sirf_probe(struct platform_device *pdev)
 	priv->gpio_cd = gpio_cd;
 
 	sdhci_get_of_property(pdev);
+	mmc_of_parse(host->mmc);
 
 	ret = clk_prepare_enable(priv->clk);
 	if (ret)
-- 
1.8.2.3



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog


From festevam at gmail.com  Mon Jul  1 22:45:53 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 1 Jul 2013 23:45:53 -0300
Subject: [PATCHv3 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
In-Reply-To: <1372094699-3832-3-git-send-email-alexandre.belloni@free-electrons.com>
References: <1372094699-3832-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1372094699-3832-3-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <CAOMZO5CLcT=OXYd=ggxpDzUqFxoXSaanqUPGugYLT2Og-VgzCA@mail.gmail.com>

Hi Alexandre,

On Mon, Jun 24, 2013 at 2:24 PM, Alexandre Belloni
<alexandre.belloni at free-electrons.com> wrote:
> From: Maxime Ripard <maxime.ripard at free-electrons.com>
>
> The ADCs connected to this bus have been experiencing some timeout
> issues when using the iMX28 i2c controller. Switching back to bitbanging
> solves this.

Are you able to use the mxs i2c controller instead of bitbang if you
use this patch?
http://www.spinics.net/lists/stable/msg13202.html

Regards,

Fabio Estevam


From voice.shen at atmel.com  Mon Jul  1 23:01:45 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Tue, 2 Jul 2013 11:01:45 +0800
Subject: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
In-Reply-To: <1372667978-4718-2-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-2-git-send-email-richard.genoud@gmail.com>
Message-ID: <51D24299.9050209@atmel.com>

Hi Richard,

On 7/1/2013 16:39, Richard Genoud wrote:
> The ssc device has to fill the at_dma_slave structure with the
> device tree informations.
> Doing a of_dma_request_slave_channel()+dma_release_channel() for that
> seems wrong (or at least not very clean).

Please hold on of this, as to the ASoC dmaengine will deal with this. 
So, we not need do it manually.

Now, I am working on it. And will send out the patch soon after testing OK.

> Signed-off-by: Richard Genoud<richard.genoud at gmail.com>
> ---
>   drivers/misc/atmel-ssc.c                |   56 +++++++++++++++++++++++++++++++
>   include/linux/atmel-ssc.h               |    2 ++
>   include/linux/platform_data/dma-atmel.h |    2 ++
>   3 files changed, 60 insertions(+)

Best Regards,
Bo Shen


From mhu4 at marvell.com  Mon Jul  1 23:00:34 2013
From: mhu4 at marvell.com (Mingliang Hu)
Date: Mon, 1 Jul 2013 20:00:34 -0700
Subject: [PATCH] mmp: irq: Don't clear unused interrupt enable bits
In-Reply-To: <CAMPhdO8jAN5kCT_tgH4NxTJ=GOGQqXukUrxNWsHExUSXZ+44bA@mail.gmail.com>
References: <20130627175118.8A9FEFAACF@dev.laptop.org>
 <CAMPhdO_Ccp_JeuNNkqP6Q+ubmG8rah_hkxFJmOBsetysu-+dNw@mail.gmail.com>
 <CAMLZHHSS75dSd_PM5-Gu2K-kP+RF0Fx1E+TL=d-TeXzYSLsQPg@mail.gmail.com>
 <CAMPhdO8jAN5kCT_tgH4NxTJ=GOGQqXukUrxNWsHExUSXZ+44bA@mail.gmail.com>
Message-ID: <27A9CDBCD298C74285705477D186E0C918133E94F4@sc-vexch3.marvell.com>

Add Chao to comment.

-----Original Message-----
From: Eric Miao [mailto:eric.y.miao at gmail.com] 
Sent: 2013?6?29? 12:55
To: Daniel Drake
Cc: Haojian Zhuang; linux-arm-kernel; paul fox; Mingliang Hu
Subject: Re: [PATCH] mmp: irq: Don't clear unused interrupt enable bits

On Fri, Jun 28, 2013 at 10:24 PM, Daniel Drake <dsd at laptop.org> wrote:
> On Thu, Jun 27, 2013 at 11:15 PM, Eric Miao <eric.y.miao at gmail.com> wrote:
>> Is there any way to check this at run-time or at least by boot parameters?
>
> The only thing that occurs to me would be checking for the device tree 
> node that corresponds to our input serio. But doing that from platform 
> code would be horrible, and it would also be nasty doing it from the 
> input driver.

I think that should be OK and clean, e.g.

  if (of_property_read_bool(np, "irq-route-to-sp")) {
     ....
  }

I'm fine with leaving these bits out as your patch does, the only concern is some other code may have a chance to depend on this, and may benefit from this boot configuration flexibility as well.

>
>> Decide whether the interrupt gets delivered to SP seems to be a 
>> choice that the main CPU should be doing, as well as the interrupt priority.
>
> Incidentally the main CPU does make these choices - just before Linux 
> has booted.
>
> While Linux has no interaction with the SP (it is not even aware of 
> it), I would say not stomping on its configuration is an OK policy to 
> have.
>
>> And this is really all about bit 4 right?
>
> Yes, bit 4 is the crucial one, it is required for the OLPC inbuilt 
> keyboard/touchpad to work.
>
> However on numerous occasions during interactions with Marvell they 
> have stressed the importance of setting interrupt priorities on 
> interrupts used for wakeups. We don't think it makes a difference for 
> the issues that we have seen, but we do not ignore the request. As 
> that cannot be done in Linux, we do it in the firmware, and it seems 
> like while Linux does not work with interrupt priorities it should not 
> overwite any earlier setup.

Haojian & Mingliang, could you help check this is the case, and that no known driver (including those for upstream) is depending on this behavior?

>
> Daniel

From voice.shen at atmel.com  Mon Jul  1 23:03:52 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Tue, 2 Jul 2013 11:03:52 +0800
Subject: [RFC PATCH 02/13] misc: atmel_ssc: keep the count of pdev->id
In-Reply-To: <1372667978-4718-3-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-3-git-send-email-richard.genoud@gmail.com>
Message-ID: <51D24318.40908@atmel.com>

Hi Richard,

On 7/1/2013 16:39, Richard Genoud wrote:
> With device tree, pdev->id is always -1, so we introduce a local
> counter.
>
> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
> ---
>   drivers/misc/atmel-ssc.c |    7 +++++++
>   1 file changed, 7 insertions(+)
>
> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
> index 3afbd82..d1ec5ab 100644
> --- a/drivers/misc/atmel-ssc.c
> +++ b/drivers/misc/atmel-ssc.c
> @@ -173,6 +173,12 @@ out:
>   	return err;
>   }
>
> +/* counter of ssc devive instances.
> + * With device tree pdev->id is always -1, so we have to keep the
> + * count ourselves
> + */
> +static int ssc_device_id;

Do we really need this? If Yes, would it better to get from device 
through of_alias_get_id?

> +
>   static int ssc_probe(struct platform_device *pdev)
>   {
>   	struct resource *regs;
> @@ -235,6 +241,7 @@ static int ssc_probe(struct platform_device *pdev)
>   	}
>
>   	spin_lock(&user_lock);
> +	pdev->id = ssc_device_id++;
>   	list_add_tail(&ssc->list, &ssc_list);
>   	spin_unlock(&user_lock);
>
>

Best Regards,
Bo Shen



From voice.shen at atmel.com  Mon Jul  1 23:05:10 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Tue, 2 Jul 2013 11:05:10 +0800
Subject: [RFC PATCH 03/13] ARM: at91: DTS: sam9x5: add clock for SSC DT
 entry
In-Reply-To: <1372667978-4718-4-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-4-git-send-email-richard.genoud@gmail.com>
Message-ID: <51D24366.5000101@atmel.com>

Hi Richard,

On 7/1/2013 16:39, Richard Genoud wrote:
> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
> ---
>   arch/arm/mach-at91/at91sam9x5.c |    1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
> index 2abee66..191eb4b 100644
> --- a/arch/arm/mach-at91/at91sam9x5.c
> +++ b/arch/arm/mach-at91/at91sam9x5.c
> @@ -233,6 +233,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
>   	CLKDEV_CON_DEV_ID("mci_clk", "f000c000.mmc", &mmc1_clk),
>   	CLKDEV_CON_DEV_ID("dma_clk", "ffffec00.dma-controller", &dma0_clk),
>   	CLKDEV_CON_DEV_ID("dma_clk", "ffffee00.dma-controller", &dma1_clk),
> +	CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", &ssc_clk),

Actually, we don't use this anymore. Am I right?

>   	CLKDEV_CON_DEV_ID("pclk", "f0010000.ssc", &ssc_clk),
>   	CLKDEV_CON_DEV_ID(NULL, "f8010000.i2c", &twi0_clk),
>   	CLKDEV_CON_DEV_ID(NULL, "f8014000.i2c", &twi1_clk),
>

Best Regards,
Bo Shen


From dsd at laptop.org  Mon Jul  1 23:12:44 2013
From: dsd at laptop.org (Daniel Drake)
Date: Mon,  1 Jul 2013 23:12:44 -0400 (EDT)
Subject: [GIT PULL] Initial OLPC XO-1.75/XO-4 support
Message-ID: <20130702031244.B2D74FAAD2@dev.laptop.org>

Hi,

These patches add support for booting OLPC XO-1.75 (Marvell MMP2) and OLPC
XO-4 (Marvell MMP3) which present device trees from OpenFirmware.

With the exception of the most recent patch, which has been acked (I think),
the other patches were posted about 2 weeks ago and haven't received
any comments from the MMP arch maintainers.

Please consider for the next available merge window (not sure if we're
now too late for 3.11, no big deal if so).

The following changes since commit 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376:

  Linux 3.10 (2013-06-30 15:13:29 -0700)

are available in the git repository at:

  git://dev.laptop.org/users/dsd/linux-olpc arm-xo-boot

for you to fetch changes up to 99ba42c6d18a81935fcc40b604bbcccc1a04d0c5:

  mmp: irq: Don't clear unused interrupt enable bits (2013-07-01 20:54:12 -0600)

----------------------------------------------------------------
Chris Ball (1):
      ARM: mmp: Add compatible entries for OLPC XO laptops

Daniel Drake (4):
      clk: mmp: use global clock lock
      clk: mmp: add support for DT-defined clocks
      ARM: mmp: initialize l2x0 cache on MMP3
      mmp: irq: Don't clear unused interrupt enable bits

Mitch Bradley (1):
      ARM: mmp: irq: Improve DT layout

 .../devicetree/bindings/arm/mrvl/intc.txt          |  43 ++++---
 .../devicetree/bindings/arm/mrvl/mrvl.txt          |   8 ++
 .../devicetree/bindings/clock/mmp-apbc.txt         |  30 +++++
 .../devicetree/bindings/clock/mmp-apmu.txt         |  30 +++++
 arch/arm/Kconfig                                   |   5 +-
 arch/arm/boot/dts/mmp2.dtsi                        | 128 +++++++++----------
 arch/arm/mach-mmp/Kconfig                          |   5 +-
 arch/arm/mach-mmp/irq.c                            |  19 +--
 arch/arm/mach-mmp/mmp2-dt.c                        |   2 +
 arch/arm/mach-mmp/mmp2.c                           |   6 +
 drivers/clk/mmp/Makefile                           |   2 +-
 drivers/clk/mmp/clk-apbc.c                         | 104 +++++++++++-----
 drivers/clk/mmp/clk-apmu.c                         |  57 ++++++---
 drivers/clk/mmp/clk-mmp2.c                         | 135 ++++++++++++---------
 drivers/clk/mmp/clk.h                              |   8 +-
 drivers/clk/mmp/common.c                           |  13 ++
 16 files changed, 391 insertions(+), 204 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/mmp-apbc.txt
 create mode 100644 Documentation/devicetree/bindings/clock/mmp-apmu.txt
 create mode 100644 drivers/clk/mmp/common.c


From voice.shen at atmel.com  Mon Jul  1 23:21:15 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Tue, 2 Jul 2013 11:21:15 +0800
Subject: [RFC PATCH 08/13] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <1372667978-4718-9-git-send-email-richard.genoud@gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-9-git-send-email-richard.genoud@gmail.com>
Message-ID: <51D2472B.2010407@atmel.com>

Hi Richard,

   Will move this patch before 5, 6, 7?

On 7/1/2013 16:39, Richard Genoud wrote:
> From: Nicolas Ferre <nicolas.ferre at atmel.com>
>
> Description of the Asoc machine driver for an at91sam9x5 based board
> with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
> master on the SSC/I2S interface. Its connections are a headphone jack
> and an Line input jack.
>
> [Richard: this is based on an old patch from Nicolas that I forward
> ported and reworked to use only device tree]
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
> ---
>   sound/soc/atmel/Kconfig         |   12 ++
>   sound/soc/atmel/Makefile        |    2 +
>   sound/soc/atmel/sam9x5_wm8731.c |  232 +++++++++++++++++++++++++++++++++++++++
>   3 files changed, 246 insertions(+)
>   create mode 100644 sound/soc/atmel/sam9x5_wm8731.c
>
> diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
> index 3fdd87f..f24d601 100644
> --- a/sound/soc/atmel/Kconfig
> +++ b/sound/soc/atmel/Kconfig
> @@ -13,6 +13,7 @@ config SND_ATMEL_SOC_PDC
>   config SND_ATMEL_SOC_DMA
>   	tristate
>   	depends on SND_ATMEL_SOC
> +	select SND_SOC_DMAENGINE_PCM
>
>   config SND_ATMEL_SOC_SSC
>   	tristate
> @@ -32,6 +33,17 @@ config SND_AT91_SOC_SAM9G20_WM8731
>   	  Say Y if you want to add support for SoC audio on WM8731-based
>   	  AT91sam9g20 evaluation board.
>
> +config SND_AT91_SOC_SAM9X5_WM8731
> +	tristate "SoC Audio support for WM8731-based at91sam9x5 board"
> +	depends on ATMEL_SSC && SND_ATMEL_SOC && SOC_AT91SAM9X5
> +	select SND_ATMEL_SOC_SSC
> +	select SND_ATMEL_SOC_DMA
> +	select SND_ATMEL_SOC_PDC

Not need to select SND_ATMEL_SOC_PDC

> +	select SND_SOC_WM8731
> +	help
> +	  Say Y if you want to add support for audio SoC on an
> +	  at91sam9x5 based board that is using WM8731 codec.
> +
>   config SND_AT91_SOC_AFEB9260
>   	tristate "SoC Audio support for AFEB9260 board"
>   	depends on ARCH_AT91 && ATMEL_SSC && ARCH_AT91 && MACH_AFEB9260 && SND_ATMEL_SOC
> diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
> index 41967cc..7784c09 100644
> --- a/sound/soc/atmel/Makefile
> +++ b/sound/soc/atmel/Makefile
> @@ -11,6 +11,8 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
>
>   # AT91 Machine Support
>   snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
> +snd-soc-sam9x5-wm8731-objs := sam9x5_wm8731.o
>
>   obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
> +obj-$(CONFIG_SND_AT91_SOC_SAM9X5_WM8731) += snd-soc-sam9x5-wm8731.o
>   obj-$(CONFIG_SND_AT91_SOC_AFEB9260) += snd-soc-afeb9260.o
> diff --git a/sound/soc/atmel/sam9x5_wm8731.c b/sound/soc/atmel/sam9x5_wm8731.c
> new file mode 100644
> index 0000000..83ca457
> --- /dev/null
> +++ b/sound/soc/atmel/sam9x5_wm8731.c
> @@ -0,0 +1,232 @@
> +/*
> + * sam9x5_wm8731   --	SoC audio for AT91SAM9X5-based boards
> + *			that are using WM8731 as codec.
> + *
> + *  Copyright (C) 2011 Atmel,
> + *		  Nicolas Ferre <nicolas.ferre at atmel.com>
> + *
> + * Based on sam9g20_wm8731.c by:
> + * Sedji Gaouaou <sedji.gaouaou at atmel.com>
> + *
> + * GPL
> + */
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/kernel.h>
> +#include <linux/clk.h>
> +#include <linux/timer.h>
> +#include <linux/interrupt.h>
> +#include <linux/platform_device.h>
> +#include <linux/i2c.h>
> +
> +#include <linux/atmel-ssc.h>
> +
> +#include <sound/core.h>
> +#include <sound/pcm.h>
> +#include <sound/pcm_params.h>
> +#include <sound/soc.h>
> +
> +#include <asm/mach-types.h>
> +#include <mach/hardware.h>
> +#include <mach/gpio.h>
> +
> +#include "../codecs/wm8731.h"
> +#include "atmel-pcm.h"
> +#include "atmel_ssc_dai.h"
> +
> +#define MCLK_RATE 12288000
> +
> +#define DRV_NAME "sam9x5-snd-wm8731"
> +
> +/*
> + * Audio paths on at91sam9x5ek board:
> + *
> + *  |A| ------------> |      | ---R----> Headphone Jack
> + *  |T| <----\        |  WM  | ---L--/
> + *  |9| ---> CLK <--> | 8751 | <--R----- Line In Jack
> + *  |1| <------------ |      | <--L--/
> + */
> +static const struct snd_soc_dapm_widget at91sam9x5ek_dapm_widgets[] = {
> +	SND_SOC_DAPM_HP("Headphone Jack", NULL),
> +	SND_SOC_DAPM_LINE("Line In Jack", NULL),
> +};
> +
> +/*
> + * Logic for a wm8731 as connected on a at91sam9x5 based board.
> + */
> +static int at91sam9x5ek_wm8731_init(struct snd_soc_pcm_runtime *rtd)
> +{
> +	struct snd_soc_codec *codec = rtd->codec;
> +	struct snd_soc_dai *codec_dai = rtd->codec_dai;
> +	struct snd_soc_dapm_context *dapm = &codec->dapm;
> +	struct device *dev = rtd->dev;
> +	int ret;
> +
> +	dev_dbg(dev, "ASoC: at91sam9x5ek_wm8731_init() called\n");
> +
> +	/*
> +	 * remove some not supported rates in relation with clock
> +	 * provided to the wm8731 codec
> +	 */
> +	switch (MCLK_RATE) {
> +	case 12288000:
> +		codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 |
> +						     SNDRV_PCM_RATE_32000 |
> +						     SNDRV_PCM_RATE_48000 |
> +						     SNDRV_PCM_RATE_96000;
> +		codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 |
> +						    SNDRV_PCM_RATE_32000 |
> +						    SNDRV_PCM_RATE_48000 |
> +						    SNDRV_PCM_RATE_96000;
> +		break;
> +	case 12000000:
> +		/* all wm8731 rates supported */
> +		break;
> +	default:
> +		dev_err(dev, "ASoC: Codec Master clock rate not defined\n");
> +		return -EINVAL;
> +	}

Here, I think we not need to use switch ... case, as the MCLK_RATE is 
hard code as 12288000.

-----------------------------------------------

> +	/* set not connected pins */
> +	snd_soc_dapm_nc_pin(dapm, "Mic Bias");
> +	snd_soc_dapm_nc_pin(dapm, "MICIN");
> +	snd_soc_dapm_nc_pin(dapm, "LOUT");
> +	snd_soc_dapm_nc_pin(dapm, "ROUT");
> +
> +	/* always connected */
> +	snd_soc_dapm_enable_pin(dapm, "Headphone Jack");
> +	snd_soc_dapm_enable_pin(dapm, "Line In Jack");

------------------------------------------------
This part, not needed, as to the ASoC framework will deal with it.

> +	/* set the codec system clock for DAC and ADC */
> +	ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
> +				     MCLK_RATE, SND_SOC_CLOCK_IN);
> +	if (ret < 0) {
> +		dev_err(dev, "ASoC: Failed to set WM8731 SYSCLK: %d\n", ret);
> +		return ret;
> +	}
> +
> +	/* signal a DAPM event */
> +	snd_soc_dapm_sync(dapm);
> +	return 0;
> +}
> +
> +static int sam9x5_wm8731_driver_probe(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct device_node *codec_np, *cpu_np;
> +	struct snd_soc_card *card;
> +	struct snd_soc_dai_link *dai;
> +	int ret;
> +
> +	if (!np) {
> +		dev_err(&pdev->dev, "No device node supplied\n");
> +		return -EINVAL;
> +	}
> +
> +	ret = atmel_ssc_set_audio(0);
> +	if (ret != 0) {
> +		dev_err(&pdev->dev,
> +			"ASoC: Failed to set SSC 0 for audio: %d\n", ret);
> +		return ret;
> +	}
> +
> +	card = devm_kzalloc(&pdev->dev, sizeof(*card), GFP_KERNEL);
> +	dai = devm_kzalloc(&pdev->dev, sizeof(*dai), GFP_KERNEL);
> +	if (!dai || !card) {
> +		ret = -ENOMEM;
> +		goto out;
> +	}
> +
> +	card->dev = &pdev->dev;
> +	card->owner = THIS_MODULE;
> +	card->dai_link = dai;
> +	card->num_links = 1;
> +	dai->name = "WM8731";
> +	dai->stream_name = "WM8731 PCM";
> +	dai->codec_dai_name = "wm8731-hifi";
> +	dai->init = at91sam9x5ek_wm8731_init;
> +	card->dapm_widgets = at91sam9x5ek_dapm_widgets;
> +	card->num_dapm_widgets = ARRAY_SIZE(at91sam9x5ek_dapm_widgets);

Will keep these as snd_soc_card and snd_soc_dai_link structure separately?

> +	ret = snd_soc_of_parse_card_name(card, "atmel,model");
> +	if (ret)
> +		goto out;
> +
> +	ret = snd_soc_of_parse_audio_routing(card, "atmel,audio-routing");
> +	if (ret)
> +		goto out;
> +
> +	codec_np = of_parse_phandle(np, "atmel,audio-codec", 0);
> +	if (!codec_np) {
> +		dev_err(&pdev->dev, "codec info missing\n");
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	dai->codec_of_node = codec_np;
> +
> +	cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
> +	if (!cpu_np) {
> +		dev_err(&pdev->dev, "ssc controller node missing\n");
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	dai->cpu_of_node = cpu_np;
> +	dai->platform_of_node = cpu_np;
> +
> +	of_node_put(codec_np);
> +	of_node_put(cpu_np);
> +
> +	dai->dai_fmt = snd_soc_of_parse_daifmt(np, "atmel,");
> +
> +	ret = snd_soc_register_card(card);
> +	if (ret) {
> +		dev_err(&pdev->dev,
> +			"ASoC: Platform device allocation failed\n");
> +		goto out;
> +	}
> +
> +	platform_set_drvdata(pdev, card);
> +
> +	dev_info(&pdev->dev, "ASoC: at91sam9x5ek_init ok\n");
> +
> +	return ret;
> +
> +out:
> +	atmel_ssc_put_audio(0);
> +	return ret;
> +}
> +
> +static int sam9x5_wm8731_driver_remove(struct platform_device *pdev)
> +{
> +	struct snd_soc_card *card = platform_get_drvdata(pdev);
> +
> +	snd_soc_unregister_card(card);
> +	atmel_ssc_put_audio(0);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id sam9x5_wm8731_of_match[] = {
> +	{ .compatible = "atmel,sam9x5-audio-wm8731", },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, sam9x5_wm8731_of_match);
> +
> +static struct platform_driver sam9x5_wm8731_driver = {
> +	.driver = {
> +		.name = DRV_NAME,
> +		.owner = THIS_MODULE,
> +		.of_match_table = of_match_ptr(sam9x5_wm8731_of_match),
> +	},
> +	.probe = sam9x5_wm8731_driver_probe,
> +	.remove = sam9x5_wm8731_driver_remove,
> +};
> +module_platform_driver(sam9x5_wm8731_driver);
> +
> +/* Module information */
> +MODULE_AUTHOR("Nicolas Ferre <nicolas.ferre at atmel.com>");
> +MODULE_AUTHOR("Richard Genoud <richard.genoud at gmail.com>");
> +MODULE_DESCRIPTION("ALSA SoC machine driver for AT91SAM9x5 - WM8731");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:" DRV_NAME);
>

Best Regards,
Bo Shen


From horms at verge.net.au  Mon Jul  1 23:30:47 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Jul 2013 12:30:47 +0900
Subject: [PATCH] ARM: shmobile: emev2 GIO3 resource fix
In-Reply-To: <20130701114807.29137.43972.sendpatchset@w520>
References: <20130701114807.29137.43972.sendpatchset@w520>
Message-ID: <20130702033046.GC14567@verge.net.au>

On Mon, Jul 01, 2013 at 08:48:07PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Fix GIO3 base addresses for EMEV2.
> 
> This bug was introduced by 088efd9273b5076a0aead479aa31f1066d182b3e
> ("mach-shmobile: Emma Mobile EV2 GPIO support V3") which was included in v3.5.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

Thanks, I will try and get this included in v3.11 as a fix
and then added to v3.9 and v3.10 stable.




From xobs at kosagi.com  Mon Jul  1 23:46:04 2013
From: xobs at kosagi.com (Sean Cross)
Date: Tue, 2 Jul 2013 11:46:04 +0800
Subject: [PATCH 3/4] PCI: Add driver for i.MX6 PCI Express
In-Reply-To: <51D15513.7020101@st.com>
References: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
 <1372662947-27160-4-git-send-email-xobs@kosagi.com>
 <51D15513.7020101@st.com>
Message-ID: <2E3BDF14016345FA887E3BACAE05DADA@kosagi.com>

On Monday, July 1, 2013 at 6:08 PM, Pratyush Anand wrote:
> On 7/1/2013 12:45 PM, Sean Cross wrote:
> > This adds a PCI Express port driver for the on-chip PCI Express port
> > present on the i.MX6 SoC. It is based on the PCI Express driver available
> > in the Freescale BSP.
> > 
> > Signed-off-by: Sean Cross <xobs at kosagi.com (mailto:xobs at kosagi.com)>
> > ---
> 
> 
> 
> ...
> 
> > diff --git a/drivers/pci/pcie/pcie-imx.c b/drivers/pci/pcie/pcie-imx.c
> > new file mode 100644
> > index 0000000..664679e
> > --- /dev/null
> > +++ b/drivers/pci/pcie/pcie-imx.c
> 
> 
> 
> Should go to drivers/pci/host/
I'll pull from arm-soc rather than from Linus' tree and place the driver there instead.
 
> > @@ -0,0 +1,1049 @@
> > +/*
> > + * drivers/pci/pcie/pcie-imx.c
> > + *
> 
> 
> 
> ...
> 
> 
> > +#define ATU_R_BaseAddress 0x900
> > +#define PCIE_PL_iATUVR (ATU_R_BaseAddress + 0x0)
> > +#define PCIE_PL_iATURC1 (ATU_R_BaseAddress + 0x4)
> > +#define PCIE_PL_iATURC2 (ATU_R_BaseAddress + 0x8)
> > +#define PCIE_PL_iATURLBA (ATU_R_BaseAddress + 0xC)
> > +#define PCIE_PL_iATURUBA (ATU_R_BaseAddress + 0x10)
> > +#define PCIE_PL_iATURLA (ATU_R_BaseAddress + 0x14)
> > +#define PCIE_PL_iATURLTA (ATU_R_BaseAddress + 0x18)
> > +#define PCIE_PL_iATURUTA (ATU_R_BaseAddress + 0x1C)
> 
> 
> 
> I may be wrong, but from these offset it seems to me that it is SNPS 
> controller. If yes, then please go through comments of
> "[PATCH V1-10 0/4] PCIe support for Samsung Exynos5440 SoC"

Exynos5440 appears to use the same port logic controller.  However, the PHYs are different.  I'm not exactly certain which comments you want me to notice in that series of patchsets, but I see references to splitting Exynos-specific code into its own project.  Based on that, it seems like the best approach would be to:

    1) Move Exynos code into its own file, say, pcie-exynos.c.  This would leave only Synopsys-specific ATC code in pcie-designware.c
    2) Rename generic exynos functions to reflect the fact that they're designware-generic functions.
    3) Have pcie-imx.c reference this generic designware ATC code.

I'll rework the patch and re-submit it following these three changes.


--
Sean Cross



From Vineet.Gupta1 at synopsys.com  Tue Jul  2 00:17:46 2013
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Tue, 2 Jul 2013 04:17:46 +0000
Subject: [PATCH v2] of: Specify initrd location using 64-bit
References: <1372702835-5333-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <C2D7FE5348E1B147BCA15975FBA23075137087@IN01WEMBXA.internal.synopsys.com>

On 07/01/2013 11:52 PM, Santosh Shilimkar wrote:
> On some PAE architectures, the entire range of physical memory could reside
> outside the 32-bit limit.  These systems need the ability to specify the
> initrd location using 64-bit numbers.
>
> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
> use 64-bit numbers instead of the current unsigned long.
>
> There has been quite a bit of debate about whether to use u64 or phys_addr_t.
> It was concluded to stick to u64 to be consistent with rest of the device
> tree code. As summarized by Geert, "The address to load the initrd is decided
> by the bootloader/user and set at that point later in time. The dtb should not
> be tied to the kernel you are booting"
>
> More details on the discussion can be found here:
> https://lkml.org/lkml/2013/6/20/690
> https://lkml.org/lkml/2012/9/13/544
>
> Cc: Grant Likely <grant.likely at linaro.org>
> Cc: Rob Herring <rob.herring at calxeda.com>
> Cc: Geert Uytterhoeven <geert at linux-m68k.org>
> Cc: Sebastian Andrzej Siewior <bigeasy at linutronix.de>
> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: Vineet Gupta <vgupta at synopsys.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Mark Salter <msalter at redhat.com>
> Cc: Aurelien Jacquiot <a-jacquiot at ti.com>
> Cc: James Hogan <james.hogan at imgtec.com>
> Cc: Michal Simek <monstr at monstr.eu>
> Cc: Ralf Baechle <ralf at linux-mips.org>
> Cc: Jonas Bonn <jonas at southpole.se>
> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> Cc: Paul Mackerras <paulus at samba.org>
> Cc: x86 at kernel.org
> Cc: arm at kernel.org
> Cc: Chris Zankel <chris at zankel.net>
> Cc: Max Filippov <jcmvbkbc at gmail.com>
> Cc: bigeasy at linutronix.de
> Cc: robherring2 at gmail.com
> Cc: Nicolas Pitre <nicolas.pitre at linaro.org>
>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-c6x-dev at linux-c6x.org
> Cc: linux-mips at linux-mips.org
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: linux-xtensa at linux-xtensa.org
> Cc: devicetree-discuss at lists.ozlabs.org
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---

Acked-by: Vineet Gupta <vgupta at synopsys.com>  [For arch/arc bits]

-Vineet



From hvaibhav at ti.com  Tue Jul  2 00:29:20 2013
From: hvaibhav at ti.com (Hiremath, Vaibhav)
Date: Tue, 2 Jul 2013 04:29:20 +0000
Subject: OMAP baseline test results for v3.10-rc6
In-Reply-To: <alpine.DEB.2.02.1307010211580.3741@utopia.booyaka.com>
References: <alpine.DEB.2.02.1306170521020.9909@utopia.booyaka.com>
 <20130625160243.GE22312@arwen.pp.htv.fi>
 <alpine.DEB.2.02.1306251746060.14373@utopia.booyaka.com>
 <51C9F0A8.1050607@ti.com> <87fvw6t136.fsf@linaro.org>
 <79CD15C6BA57404B839C016229A409A83ECC952D@DBDE04.ent.ti.com>
 <51CAEB33.5010101@ti.com>
 <alpine.DEB.2.02.1306261722520.6135@utopia.booyaka.com>
 <51CBBCD8.5030600@ti.com>
 <alpine.DEB.2.02.1306281844090.8767@utopia.booyaka.com>
 <alpine.DEB.2.02.1307010211580.3741@utopia.booyaka.com>
Message-ID: <79CD15C6BA57404B839C016229A409A83ECCC435@DBDE04.ent.ti.com>


> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Monday, July 01, 2013 7:46 AM
> To: Vutla, Lokesh
> Cc: Nayak, Rajendra; Hiremath, Vaibhav; Kevin Hilman; Rini, Tom; linux-
> omap at vger.kernel.org; Balbi, Felipe; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: OMAP baseline test results for v3.10-rc6
> 
> On Fri, 28 Jun 2013, Paul Walmsley wrote:
> 
> > On Thu, 27 Jun 2013, Lokesh Vutla wrote:
> >
> > > Here is the catch..
> > > Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb
> was
> > > generated in arch/arm/boot).
> >
> > Ugh... that's probably it :-(
> 
> Indeed, this was at least one major problem.  With this fixed, and with
> CONFIG_MACH_OMAP_GENERIC=y in the v3.10-rc Kconfigs, the BeagleBone
> white
> boots here now with v3.10-rc7.  Will test the previous releases going
> back

Surely it will boot. :)

Thanks,
Vaibhav


From shc_work at mail.ru  Tue Jul  2 00:30:37 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Tue, 02 Jul 2013 08:30:37 +0400
Subject: =?UTF-8?B?UmVbMl06IFtQQVRDSCB2MyAyLzVdIEFSTTogZHRzOiBpbXgyNzogQWRkIGlt?=
 =?UTF-8?B?eCBmcmFtZWJ1ZmZlciBkZXZpY2U=?=
In-Reply-To: <20130701093032.GG13206@S2101-09.ap.freescale.net>
References: <1372431037-13519-1-git-send-email-mpa@pengutronix.de>
 <1372432206.785926201@f326.mail.ru>
 <20130701093032.GG13206@S2101-09.ap.freescale.net>
Message-ID: <1372739437.489198409@f348.mail.ru>

> On Fri, Jun 28, 2013 at 07:10:06PM +0400, Alexander Shiyan wrote:
> > > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > > ---
> > >  arch/arm/boot/dts/imx27.dtsi | 9 +++++++++
> > >  1 file changed, 9 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
> > > index 8603886..10dcbd3 100644
> > > --- a/arch/arm/boot/dts/imx27.dtsi
> > > +++ b/arch/arm/boot/dts/imx27.dtsi
> > > @@ -342,6 +342,15 @@
> > >  			reg = <0x10020000 0x20000>;
> > >  			ranges;
> > >  
> > > +			imxfb: fb at 10021000 {
> > 
> > If it can be fixed while applying, it would be right to use just "fb" here.
> > We now use a lot of devices without "imx"-prefix, so I do not see any need to use it here.
> 
> I actually prefer to use the block name if it's not a thing defined by
> ePAPR.  In this case, it's "lcdc".  But since "fb" is already used in
> compatible.  Okay, I fixed it up by dropping "imx" prefix.

i.MX27 have a SLCDC module, so perhaps your proposed option (lcdc) is better.

---

From horms+renesas at verge.net.au  Tue Jul  2 00:35:32 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Jul 2013 13:35:32 +0900
Subject: [GIT PULL 0/2] Renesas ARM based SoC fixes for v3.11
Message-ID: <cover.1372739438.git.horms+renesas@verge.net.au>

Hi Arnd, Hi Olof,

please consider the following fixes for v3.11, both of which are suitable for
stable.

This pull request is based on renesas-soc2-for-v3.11 which you have
already pulled.


The following changes since commit 018222f5d32bc5ca9fd830aebfeed10f1be96c93:

  ARM: shmobile: r8a7790: add clock definitions and aliases for MMCIF and SDHI (2013-06-12 21:07:38 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-fixes-for-v3.11

for you to fetch changes up to 1eb14ea1e6bcd11d6d0ba937fc39808bb4d3453e:

  ARM: shmobile: emev2 GIO3 resource fix (2013-07-02 12:28:01 +0900)

----------------------------------------------------------------
Renesas ARM based SoC fixes for v3.11

* Correct GIO3 base addresses for EMEV2 SoC
  - This bug bug added when GPIO support was added for the EMEV2 SoC
    in v3.5

* Correct SCIFB0 resources for r8a77a4 SoC
  - This was a bug was added when SCIF support was added for the r8a77a4 SoC
    in v3.10

----------------------------------------------------------------
Magnus Damm (1):
      ARM: shmobile: emev2 GIO3 resource fix

Takanari Hayama (1):
      ARM: shmobile: r8a73a4: Fix resources for SCIFB0

 arch/arm/mach-shmobile/setup-emev2.c   | 8 ++++----
 arch/arm/mach-shmobile/setup-r8a73a4.c | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)


From horms+renesas at verge.net.au  Tue Jul  2 00:35:53 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Jul 2013 13:35:53 +0900
Subject: [PATCH 1/2] ARM: shmobile: r8a73a4: Fix resources for SCIFB0
In-Reply-To: <cover.1372739438.git.horms+renesas@verge.net.au>
References: <cover.1372739438.git.horms+renesas@verge.net.au>
Message-ID: <f820b60582f75e73e83b8505d7e48fe59770f558.1372739438.git.horms+renesas@verge.net.au>

From: Takanari Hayama <taki at igel.co.jp>

Fix base address and IRQ resources associated with SCIFB0.

This bug was introduced by e481a528901d0cd18b5b5fcbdc55207ea3b6ef68
("ARM: shmobile: r8a73a4 SCIF support V3") which was included in v3.10.

Signed-off-by: Takanari Hayama <taki at igel.co.jp>
Acked-by: Magnus Damm <damm at opensource.se>
[ horms+renesas at verge.net.au: Add information about commit and version
  this bug was added in ]
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Cc: stable at vger.kernel.org
---
 arch/arm/mach-shmobile/setup-r8a73a4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c b/arch/arm/mach-shmobile/setup-r8a73a4.c
index c5a75a7..7f45c2e 100644
--- a/arch/arm/mach-shmobile/setup-r8a73a4.c
+++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
@@ -62,7 +62,7 @@ enum { SCIFA0, SCIFA1, SCIFB0, SCIFB1, SCIFB2, SCIFB3 };
 static const struct plat_sci_port scif[] = {
 	SCIFA_DATA(SCIFA0, 0xe6c40000, gic_spi(144)), /* SCIFA0 */
 	SCIFA_DATA(SCIFA1, 0xe6c50000, gic_spi(145)), /* SCIFA1 */
-	SCIFB_DATA(SCIFB0, 0xe6c50000, gic_spi(145)), /* SCIFB0 */
+	SCIFB_DATA(SCIFB0, 0xe6c20000, gic_spi(148)), /* SCIFB0 */
 	SCIFB_DATA(SCIFB1, 0xe6c30000, gic_spi(149)), /* SCIFB1 */
 	SCIFB_DATA(SCIFB2, 0xe6ce0000, gic_spi(150)), /* SCIFB2 */
 	SCIFB_DATA(SCIFB3, 0xe6cf0000, gic_spi(151)), /* SCIFB3 */
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul  2 00:35:54 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Jul 2013 13:35:54 +0900
Subject: [PATCH 2/2] ARM: shmobile: emev2 GIO3 resource fix
In-Reply-To: <cover.1372739438.git.horms+renesas@verge.net.au>
References: <cover.1372739438.git.horms+renesas@verge.net.au>
Message-ID: <1eb14ea1e6bcd11d6d0ba937fc39808bb4d3453e.1372739438.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Fix GIO3 base addresses for EMEV2.

This bug was introduced by 088efd9273b5076a0aead479aa31f1066d182b3e
("mach-shmobile: Emma Mobile EV2 GPIO support V3") which was included in v3.5.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Cc: stable at vger.kernel.org
---
 arch/arm/mach-shmobile/setup-emev2.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
index 899a86c..1ccddd2 100644
--- a/arch/arm/mach-shmobile/setup-emev2.c
+++ b/arch/arm/mach-shmobile/setup-emev2.c
@@ -287,14 +287,14 @@ static struct gpio_em_config gio3_config = {
 static struct resource gio3_resources[] = {
 	[0] = {
 		.name	= "GIO_096",
-		.start	= 0xe0050100,
-		.end	= 0xe005012b,
+		.start	= 0xe0050180,
+		.end	= 0xe00501ab,
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
 		.name	= "GIO_096",
-		.start	= 0xe0050140,
-		.end	= 0xe005015f,
+		.start	= 0xe00501c0,
+		.end	= 0xe00501df,
 		.flags	= IORESOURCE_MEM,
 	},
 	[2] = {
-- 
1.8.2.1



From pratyush.anand at st.com  Tue Jul  2 00:41:55 2013
From: pratyush.anand at st.com (Pratyush Anand)
Date: Tue, 2 Jul 2013 10:11:55 +0530
Subject: [PATCH 3/4] PCI: Add driver for i.MX6 PCI Express
In-Reply-To: <2E3BDF14016345FA887E3BACAE05DADA@kosagi.com>
References: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
 <1372662947-27160-4-git-send-email-xobs@kosagi.com> <51D15513.7020101@st.com>
 <2E3BDF14016345FA887E3BACAE05DADA@kosagi.com>
Message-ID: <51D25A13.9060006@st.com>

On 7/2/2013 9:16 AM, Sean Cross wrote:
>> >I may be wrong, but from these offset it seems to me that it is SNPS
>> >controller. If yes, then please go through comments of
>> >"[PATCH V1-10 0/4] PCIe support for Samsung Exynos5440 SoC"
> Exynos5440 appears to use the same port logic controller.  However, the PHYs are different.  I'm not exactly certain which comments you want me to notice in that series of patchsets, but I see references to splitting Exynos-specific code into its own project.  Based on that, it seems like the best approach would be to:
>
>      1) Move Exynos code into its own file, say, pcie-exynos.c.  This would leave only Synopsys-specific ATC code in pcie-designware.c
>      2) Rename generic exynos functions to reflect the fact that they're designware-generic functions.
>      3) Have pcie-imx.c reference this generic designware ATC code.
>
> I'll rework the patch and re-submit it following these three changes.

Correct, Exactly these steps has to be done. But, Mohit might be doing 
similar work, so it would be better to get consensus on what has to be done.

IMO, there should be three categories of functions. May be arnd can 
comment if we can do even something better.

Group I: Initially, These functions should remain in pcie-designware.c 
(offcourse by changing exynos tag to dw). Latter on, we can see if some 
of them can even be moved to common pci layer.

sys_to_pcie
cfg_read
cfg_write
dw_pcie_prog_viewport_cfg0
dw_pcie_prog_viewport_cfg1
dw_pcie_prog_viewport_mem_outbound
dw_pcie_prog_viewport_io_outbound
dw_pcie_rd_other_conf
dw_pcie_wr_other_conf
dw_pcie_setup
dw_pcie_valid_config
dw_pcie_rd_conf
dw_pcie_wd_conf
dw_pcie_scan_bus
dw_pcie_map_irq
dw_pcie_setup_rc
add_pcie_port (after a bit of generalization)
dw_pcie_probe
dw_pcie_remove


Group II: These functions should still remain as dummy in 
pcie-designware.c , and should be classified as __week. So, each 
implementer of designware controller say Exynos/SPEAr/imx will have to 
define their own function to super-seed default dummy definitions.

dw_readl_rc
dw_writel_rc
dw_pcie_rd_own_conf
dw_pcie_wr_own_conf
dw_pcie_link_up
dw_pcie_host_init (will contain all platform specific and phy 
initialization)

Group III: Functions specific to Exynos, which should move to pcie-exynos.c

exynos_pcie_sideband_dbi_w_mode
exynos_pcie_sideband_dbi_r_mode
exynos_pcie_assert_core_reset
exynos_pcie_deassert_core_reset
exynos_pcie_assert_phy_reset
exynos_pcie_deassert_phy_reset
exynos_pcie_init_phy
exynos_pcie_assert_reset
exynos_pcie_establish_link


@Mohit, See if you have BW then please take it further.

arnd, are exynos patches applied to any branch of arm-soc git tree?

Regards
Pratyush







From olof at lixom.net  Tue Jul  2 00:53:04 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 1 Jul 2013 21:53:04 -0700
Subject: [GIT PULL] Initial OLPC XO-1.75/XO-4 support
In-Reply-To: <20130702031244.B2D74FAAD2@dev.laptop.org>
References: <20130702031244.B2D74FAAD2@dev.laptop.org>
Message-ID: <20130702045304.GA27829@quad.lixom.net>

On Mon, Jul 01, 2013 at 11:12:44PM -0400, Daniel Drake wrote:
> Hi,
> 
> These patches add support for booting OLPC XO-1.75 (Marvell MMP2) and OLPC
> XO-4 (Marvell MMP3) which present device trees from OpenFirmware.
> 
> With the exception of the most recent patch, which has been acked (I think),
> the other patches were posted about 2 weeks ago and haven't received
> any comments from the MMP arch maintainers.
> 
> Please consider for the next available merge window (not sure if we're
> now too late for 3.11, no big deal if so).

Daniel,

Unfortunately too late for 3.11 indeed, so this is 3.12 material at this point.
Given that the merge window just opened, most maintainers will be too busy to
look at much new patches at this time as well.

Can I ask you to do a few things though?

1) Please post the drivers/clk patches to mturquette. THey don't look dependent
   on the rest of the patches, just general improvements and cleanups.
2) I really wish there was a generic catch-all compat for the boards, so we
   didn't have to modify mmp2-dt.c for every new board added -- it really
   defies the purpose of only changing the data you pass into the kernel. This
   is mostly something for Eric/Haojian to sort out though.
3) Please post the patches as a series instead of a pull request, given that
   they should probably take different paths up the tree (clk vs the platform,
   etc). You should at least get review/acked-by of the clk pieces from Mike
   Turquette.

Beyond that I didn't look all that closely at the patches yet.


-Olof


From r65037 at freescale.com  Tue Jul  2 00:53:22 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Tue, 2 Jul 2013 04:53:22 +0000
Subject: [PATCH 3/4] PCI: Add driver for i.MX6 PCI Express
In-Reply-To: <2E3BDF14016345FA887E3BACAE05DADA@kosagi.com>
References: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
 <1372662947-27160-4-git-send-email-xobs@kosagi.com>
 <51D15513.7020101@st.com> <2E3BDF14016345FA887E3BACAE05DADA@kosagi.com>
Message-ID: <0E83723C55F66F43A6041464FE31119D30C672@039-SN2MPN1-013.039d.mgd.msft.net>

Hi Cross:
First of all, Thanks for your efforts to summit the imx pcie support patches.
I looked through your patch-set, and have some concerns:
* PCIe driver used in the FSL linux-2.6.35 BSP, is not good enough,
Based on the latest FSL BSP.
* The PCIe switch/MSI features had been supported.
* In order to support the 8MB memory space size, the mem layout had been updated as listed below,
 otherwise, the memory space size required by PCIe EP device wouldn't larger than 4MB.
        /*
         * i.MX6 defines 16MB in the AXI address map for PCIe.
         *
         * That address space excepted the pcie registers is
         * split and defined into different regions by iATU,
         * with sizes and offsets as follows:
         *
         * RC:
         * 0x0100_0000 --- 0x01DF_FFFF 14MB IORESOURCE_MEM
         * 0x01E0_0000 --- 0x01EF_FFFF 1MB IORESOURCE_IO
         * 0x01F0_0000 --- 0x01FF_FFFF 1MB Cfg + MSI + Registers
         *
         * EP (default value):
         * 0x0100_0000 --- 0x01FF_C000 16MB - 16KB IORESOURCE_MEM
         */

* BTW, the PCIe EP mode had been verified too.

Best Regards
Richard Zhu


-----Original Message-----
From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org] On Behalf Of Sean Cross
Sent: Tuesday, July 02, 2013 11:46 AM
To: Pratyush Anand
Cc: devicetree-discuss at lists.ozlabs.org; linux-pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Arnd Bergmann; Mohit KUMAR
Subject: Re: [PATCH 3/4] PCI: Add driver for i.MX6 PCI Express

On Monday, July 1, 2013 at 6:08 PM, Pratyush Anand wrote:
> On 7/1/2013 12:45 PM, Sean Cross wrote:
> > This adds a PCI Express port driver for the on-chip PCI Express port 
> > present on the i.MX6 SoC. It is based on the PCI Express driver 
> > available in the Freescale BSP.
> > 
> > Signed-off-by: Sean Cross <xobs at kosagi.com (mailto:xobs at kosagi.com)>
> > ---
> 
> 
> 
> ...
> 
> > diff --git a/drivers/pci/pcie/pcie-imx.c 
> > b/drivers/pci/pcie/pcie-imx.c new file mode 100644 index 
> > 0000000..664679e
> > --- /dev/null
> > +++ b/drivers/pci/pcie/pcie-imx.c
> 
> 
> 
> Should go to drivers/pci/host/
I'll pull from arm-soc rather than from Linus' tree and place the driver there instead.
 
> > @@ -0,0 +1,1049 @@
> > +/*
> > + * drivers/pci/pcie/pcie-imx.c
> > + *
> 
> 
> 
> ...
> 
> 
> > +#define ATU_R_BaseAddress 0x900
> > +#define PCIE_PL_iATUVR (ATU_R_BaseAddress + 0x0) #define 
> > +PCIE_PL_iATURC1 (ATU_R_BaseAddress + 0x4) #define PCIE_PL_iATURC2 
> > +(ATU_R_BaseAddress + 0x8) #define PCIE_PL_iATURLBA 
> > +(ATU_R_BaseAddress + 0xC) #define PCIE_PL_iATURUBA 
> > +(ATU_R_BaseAddress + 0x10) #define PCIE_PL_iATURLA 
> > +(ATU_R_BaseAddress + 0x14) #define PCIE_PL_iATURLTA 
> > +(ATU_R_BaseAddress + 0x18) #define PCIE_PL_iATURUTA 
> > +(ATU_R_BaseAddress + 0x1C)
> 
> 
> 
> I may be wrong, but from these offset it seems to me that it is SNPS 
> controller. If yes, then please go through comments of "[PATCH V1-10 
> 0/4] PCIe support for Samsung Exynos5440 SoC"

Exynos5440 appears to use the same port logic controller.  However, the PHYs are different.  I'm not exactly certain which comments you want me to notice in that series of patchsets, but I see references to splitting Exynos-specific code into its own project.  Based on that, it seems like the best approach would be to:

    1) Move Exynos code into its own file, say, pcie-exynos.c.  This would leave only Synopsys-specific ATC code in pcie-designware.c
    2) Rename generic exynos functions to reflect the fact that they're designware-generic functions.
    3) Have pcie-imx.c reference this generic designware ATC code.

I'll rework the patch and re-submit it following these three changes.


--
Sean Cross

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo at vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html


From magnus.damm at gmail.com  Tue Jul  2 00:59:20 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 2 Jul 2013 13:59:20 +0900
Subject: [PATCH 1/3] ARM: shmobile: use common platform header for HPB-DMAC
In-Reply-To: <201306300245.58486.sergei.shtylyov@cogentembedded.com>
References: <201306300243.57180.sergei.shtylyov@cogentembedded.com>
 <201306300245.58486.sergei.shtylyov@cogentembedded.com>
Message-ID: <CANqRtoTCaJfbECSpX7nMZoV8SPeQqs-xrJQ0-+-smA+bx3QG=w@mail.gmail.com>

Hi Sergei,

On Sun, Jun 30, 2013 at 7:45 AM, Sergei Shtylyov
<sergei.shtylyov at cogentembedded.com> wrote:
> From: Max Filippov <max.filippov at cogentembedded.com>
>
> Use previously empty <mach/dma.h> to declare HPB-DMA slave IDs.
>
> Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
> [Sergei: changed the guard macro name, fixed comment, extended copyright.]
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>
> ---
>  arch/arm/mach-shmobile/include/mach/dma.h |   25 ++++++++++++++++++++++++-
>  1 file changed, 24 insertions(+), 1 deletion(-)

Thanks for your patch. Can you please explain the reason why you put
this shared information under mach/?

>From my point of view we should really have as few special things as
possible under mach/. Starting to share DMA stuff here looks special.
I would like mach-shmobile to be as standard as possible (basically
only ARM code in the future), and in the case we have I/O devices or
other IOMMUs or DMA controllers then we should use include/linux or
that recently added platform data directory if needed. We need to make
sure that our headers stay compatible with multiplatform support.

I realize you may want to share this header between multiple SoCs, but
I really want to avoid creating local common code under arch/arm/ that
has nothing to do with ARM. Also, this is IMO a total non-issue,
instead of merging code and making back porting more difficult for any
particular SoC, then how about spending effort on the ling term
instead, like DMA DT?

So my recommendation is to keep this information together with each
SoC. And also work on DT. In between have a coffee or work on DT, but
please do not spend time on merging short term per-SoC information and
making back porting more difficult.

Thanks,

/ magnus


From gururaja.hebbar at ti.com  Tue Jul  2 01:20:29 2013
From: gururaja.hebbar at ti.com (Hebbar, Gururaja)
Date: Tue, 2 Jul 2013 05:20:29 +0000
Subject: [PATCH 2/4] davinci: da8xx/omap-l1: Remove hard coding of rtc
 device wakeup
In-Reply-To: <87a9m5omcw.fsf@linaro.org>
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-3-git-send-email-gururaja.hebbar@ti.com>
 <87a9m5omcw.fsf@linaro.org>
Message-ID: <1BAFE6F6C881BF42822005164F1491C33EC4E6EE@DBDE04.ent.ti.com>

On Tue, Jul 02, 2013 at 05:37:43, Kevin Hilman wrote:
> Hebbar Gururaja <gururaja.hebbar at ti.com> writes:
> 
> > Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
> > duplicate call from the rtc device registration can be removed.
> >
> > This is basically a partial revert of the prev commit
> >
> > commit 75c99bb0006ee065b4e2995078d779418b0fab54
> > Author: Sekhar Nori <nsekhar at ti.com>
> >
> >     davinci: da8xx/omap-l1: mark RTC as a wakeup source
> >
> > Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> > Cc: Sekhar Nori <nsekhar at ti.com>
> > Cc: Kevin Hilman <khilman at linaro.org>
> > Cc: Russell King <linux at arm.linux.org.uk>
> >
> > ---
> > :100644 100644 bf57252... 85a900c... M	arch/arm/mach-davinci/devices-da8xx.c
> >  arch/arm/mach-davinci/devices-da8xx.c |    9 +--------
> >  1 file changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> > index bf57252..85a900c 100644
> > --- a/arch/arm/mach-davinci/devices-da8xx.c
> > +++ b/arch/arm/mach-davinci/devices-da8xx.c
> > @@ -827,14 +827,7 @@ static struct platform_device da8xx_rtc_device = {
> >  
> >  int da8xx_register_rtc(void)
> >  {
> > -	int ret;
> > -
> > -	ret = platform_device_register(&da8xx_rtc_device);
> > -	if (!ret)
> > -		/* Atleast on DA850, RTC is a wakeup source */
> > -		device_init_wakeup(&da8xx_rtc_device.dev, true);
> > -
> > -	return ret;
> > +	return  platform_device_register(&da8xx_rtc_device);
> 
> nit: extra space between 'return' and 'platform_'

Thanks for the review. V2 will soon follow.

> 
> >  }
> >  
> >  static void __iomem *da8xx_ddr2_ctlr_base;
> 
> Otherwise,
> 
> Acked-by: Kevin Hilman <khilman at linaro.org>
> 
> 


Regards, 
Gururaja


From gururaja.hebbar at ti.com  Tue Jul  2 01:20:53 2013
From: gururaja.hebbar at ti.com (Hebbar, Gururaja)
Date: Tue, 2 Jul 2013 05:20:53 +0000
Subject: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
In-Reply-To: <871u7hom0q.fsf@linaro.org>
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-4-git-send-email-gururaja.hebbar@ti.com>
 <871u7hom0q.fsf@linaro.org>
Message-ID: <1BAFE6F6C881BF42822005164F1491C33EC4E6FE@DBDE04.ent.ti.com>

On Tue, Jul 02, 2013 at 05:45:01, Kevin Hilman wrote:
> Hebbar Gururaja <gururaja.hebbar at ti.com> writes:
> 
> > On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
> > is available to enable Alarm Wakeup feature. This register needs to be
> > properly handled for the rtcwake to work properly.
> >
> > Platforms using such IP should set "ti,am3352-rtc" in rtc device dt
> > compatibility node.
> >
> > Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> > Cc: Grant Likely <grant.likely at linaro.org>
> > Cc: Rob Herring <rob.herring at calxeda.com>
> > Cc: Rob Landley <rob at landley.net>
> > Cc: Sekhar Nori <nsekhar at ti.com>
> > Cc: Kevin Hilman <khilman at linaro.org>
> > Cc: Alessandro Zummo <a.zummo at towertech.it>
> > Cc: rtc-linux at googlegroups.com
> > Cc: devicetree-discuss at lists.ozlabs.org
> > Cc: linux-doc at vger.kernel.org
> 
> Acked-by: Kevin Hilman <khilman at linaro.org>
> 
> ...with a minor nit below...
> 
> > ---
> > :100644 100644 b47aa41... 5a0f02d... M	Documentation/devicetree/bindings/rtc/rtc-omap.txt
> > :100644 100644 761919d... 666b0c2... M	drivers/rtc/rtc-omap.c
> >  Documentation/devicetree/bindings/rtc/rtc-omap.txt |    6 ++-
> >  drivers/rtc/rtc-omap.c                             |   56 +++++++++++++++++---
> >  2 files changed, 54 insertions(+), 8 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> > index b47aa41..5a0f02d 100644
> > --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> > +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> > @@ -1,7 +1,11 @@
> >  TI Real Time Clock
> >  
> >  Required properties:
> > -- compatible: "ti,da830-rtc"
> > +- compatible:
> > +	- "ti,da830-rtc"  - for RTC IP used similar to that on DA8xx SoC family.
> > +	- "ti,am3352-rtc" - for RTC IP used similar to that on AM335x SoC family.
> > +			    This RTC IP has special WAKE-EN Register to enable
> > +			    Wakeup generation for event Alarm.
> >  - reg: Address range of rtc register set
> >  - interrupts: rtc timer, alarm interrupts in order
> >  - interrupt-parent: phandle for the interrupt controller
> > diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> > index 761919d..666b0c2 100644
> > --- a/drivers/rtc/rtc-omap.c
> > +++ b/drivers/rtc/rtc-omap.c
> > @@ -72,6 +72,8 @@
> >  #define OMAP_RTC_KICK0_REG		0x6c
> >  #define OMAP_RTC_KICK1_REG		0x70
> >  
> > +#define OMAP_RTC_IRQWAKEEN		0x7C
> > +
> 
> nit: letters in hex numbers are usually lower-case.

Thanks for the review. V2 will soon follow.

> 
> 
> Kevin
> 


Regards, 
Gururaja


From tushar.behera at linaro.org  Tue Jul  2 01:21:36 2013
From: tushar.behera at linaro.org (Tushar Behera)
Date: Tue, 02 Jul 2013 10:51:36 +0530
Subject: [PATCH 3/3] ARM: dts: Add WM1811A audio CODEC to Arndale bindings
In-Reply-To: <1372714599-17588-3-git-send-email-broonie@kernel.org>
References: <1372714599-17588-1-git-send-email-broonie@kernel.org>
 <1372714599-17588-3-git-send-email-broonie@kernel.org>
Message-ID: <51D26360.2080708@linaro.org>

On 07/02/2013 03:06 AM, Mark Brown wrote:
> From: Mark Brown <broonie at linaro.org>
> 
> The default audio module for the Arndale has a WM811A on it. Add this to

typo: WM1811A

Arndale board also comes with two other audio codec boards - ALC5631Q
and AK4678. Different audio codec boards came with different shipments.

> the device tree bindings.
> 
> Signed-off-by: Mark Brown <broonie at linaro.org>
> ---
>  arch/arm/boot/dts/exynos5250-arndale.dts | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
> index 482f275..75c3065 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -325,7 +325,22 @@
>  	};
>  
>  	i2c at 12C90000 {
> -		status = "disabled";
> +		wm1811a at 11 {
> +			compatible = "wlf,wm1811";
> +			reg = <0x1a>;
> +
> +			AVDD2-supply = <&main_dc_reg>;
> +			CPVDD-supply = <&main_dc_reg>;
> +			DBVDD1-supply = <&main_dc_reg>;
> +			DBVDD2-supply = <&main_dc_reg>;
> +			DBVDD3-supply = <&main_dc_reg>;
> +			LDO1VDD-supply = <&main_dc_reg>;
> +			SPKVDD1-supply = <&main_dc_reg>;
> +			SPKVDD2-supply = <&main_dc_reg>;
> +
> +			wlf,ldo1ena = <&gpb0 0 0>;
> +			wlf,ldo2ena = <&gpb0 1 0>;
> +		};
>  	};
>  
>  	i2c at 12CA0000 {
> 


-- 
Tushar Behera


From sfr at canb.auug.org.au  Tue Jul  2 01:29:54 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 2 Jul 2013 15:29:54 +1000
Subject: linux-next: manual merge of the arm-soc tree with the l2-mtd tree
Message-ID: <20130702152954.f25bbf51c1a79aa4437e22ee@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
Documentation/devicetree/bindings/mtd/gpmc-nand.txt between commits
6c88058ef927 ("ARM: OMAP2+: cleaned-up DT support of various ECC
schemes") and 212012138deb ("mtd: nand: omap2: updated support for BCH4
ECC scheme") from the l2-mtd tree and commit 496c8a0bbb72 ("ARM: OMAP2+:
Allow NAND transfer mode to be specified in DT") from the arm-soc tree.

I fixed it up (maybe - see below) and can carry the fix as necessary (no
action is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index b3f23df,df338cb..0000000
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@@ -17,59 -17,27 +17,66 @@@ Required properties
  
  Optional properties:
  
 - - nand-bus-width: 		Set this numeric value to 16 if the hardware
 -				is wired that way. If not specified, a bus
 -				width of 8 is assumed.
 + - nand-bus-width: 		Determines data-width of the connected device
 +				x16 = "16"
 +				x8  = "8" (default)
  
 - - ti,nand-ecc-opt:		A string setting the ECC layout to use. One of:
  
 -		"sw"		Software method (default)
 -		"hw"		Hardware method
 -		"hw-romcode"	gpmc hamming mode method & romcode layout
 -		"bch4"		4-bit BCH ecc code
 -		"bch8"		8-bit BCH ecc code
 + - ti,nand-ecc-opt:		Determines the ECC scheme used by driver.
 +				It can be any of the following strings:
 +
 +	"hamming_code_sw"		1-bit Hamming ECC
 +					- ECC calculation in software
 +					- Error detection in software
 +					- ECC layout compatible with S/W scheme
 +
 +	"hamming_code_hw"		1-bit Hamming ECC
 +					- ECC calculation in hardware
 +					- Error detection in software
 +					- ECC layout compatible with S/W scheme
 +
 +	"hamming_code_hw_romcode"	1-bit Hamming ECC
 +					- ECC calculation in hardware
 +					- Error detection in software
 +					- ECC layout compatible with ROM code
 +
 +	"bch4_code_hw_detection_sw"	4-bit BCH ECC
 +					- ECC calculation in hardware
 +					- Error detection in software
 +					- ECC layout compatible with S/W scheme
 +					* depends on CONFIG_MTD_NAND_ECC_BCH
 +
 +	"bch4_code_hw"             	4-bit BCH ECC
 +					- ECC calculation in hardware
 +					- Error detection in hardware
 +					- ECC layout compatible with ROM code
 +					* depends on CONFIG_MTD_NAND_OMAP_BCH
 +					* requires <elm_id> to be specified
 +
 +	"bch8_code_hw_detection_sw"	8-bit BCH ECC
 +					- ECC calculation in hardware
 +					- Error detection in software
 +					- ECC layout compatible with S/W scheme
 +					* depends on CONFIG_MTD_NAND_ECC_BCH
 +
 +	"bch8_code_hw"             	8-bit BCH ECC
 +					- ECC calculation in hardware
 +					- Error detection in hardware
 +					- ECC layout compatible with ROM code
 +					* depends on CONFIG_MTD_NAND_OMAP_BCH
 +					* requires <elm_id> to be specified
  
+  - ti,nand-xfer-type:		A string setting the data transfer type. One of:
+ 
+ 		"prefetch-polled"	Prefetch polled mode (default)
+ 		"polled"		Polled mode, without prefetch
+ 		"prefetch-dma"		Prefetch enabled sDMA mode
+ 		"prefetch-irq"		Prefetch enabled irq mode
+ 
 - - elm_id:	Specifies elm device node. This is required to support BCH
 - 		error correction using ELM module.
 +
 + - elm_id:			Specifies elm device node. This is required to
 +				support some BCH ECC schemes mentioned above.
 +
  
  For inline partiton table parsing (optional):
  
-------------- 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/20130702/9d37f3fa/attachment.sig>

From thomas.petazzoni at free-electrons.com  Tue Jul  2 01:30:37 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 2 Jul 2013 07:30:37 +0200
Subject: [PATCHv4 02/11] pci: use weak functions for MSI arch-specific
 functions
In-Reply-To: <1372726396.17904.1.camel@concordia>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-3-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372726396.17904.1.camel@concordia>
Message-ID: <20130702073037.55a53642@skate>

Dear Michael Ellerman,

On Tue, 02 Jul 2013 10:53:16 +1000, Michael Ellerman wrote:
> On Mon, 2013-07-01 at 15:42 +0200, Thomas Petazzoni wrote:
> > Until now, the MSI architecture-specific functions could be overloaded
> > using a fairly complex set of #define and compile-time
> > conditionals. In order to prepare for the introduction of the msi_chip
> > infrastructure, it is desirable to switch all those functions to use
> > the 'weak' mechanism. This commit converts all the architectures that
> > were overidding those MSI functions to use the new strategy.
> 
> The MSI code used to use weak functions, until we discovered they were
> being miscompiled on some toolchains (11df1f0). I assume these days
> we're confident they work correctly.

Hum, interesting. I see from your commit that gcc 4.3.2 was apparently
affected, and gcc 4.3.x is not /that/ old. Bjorn, what's your point of
view on this?

Another option would be to have architecture register some msi_arch_ops
structure, with a set of operations, which I believe is a pattern that
is more widespread in the kernel than weak functions.

Thoughts?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From sfr at canb.auug.org.au  Tue Jul  2 01:33:48 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 2 Jul 2013 15:33:48 +1000
Subject: linux-next: manual merge of the arm-soc tree with the l2-mtd tree
Message-ID: <20130702153348.ce27e4a6185c0b403e039e06@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
drivers/mtd/nand/Kconfig between commit 212012138deb ("mtd: nand: omap2:
updated support for BCH4 ECC scheme") from the l2-mtd tree and commit
930d800bded7 ("mtd: omap2: allow bulding as a module") from the arm-soc
tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au

diff --cc drivers/mtd/nand/Kconfig
index a6e247c,50543f1..0000000
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@@ -95,13 -95,35 +95,13 @@@ config MTD_NAND_OMAP
  
  config MTD_NAND_OMAP_BCH
  	depends on MTD_NAND && MTD_NAND_OMAP2 && ARCH_OMAP3
- 	bool "Support hardware based BCH error correction"
 -	tristate "Enable support for hardware BCH error correction"
++	tristate "Support hardware based BCH error correction"
  	default n
  	select BCH
 -	select BCH_CONST_PARAMS
  	help
 -	 Support for hardware BCH error correction.
 -
 -choice
 -	prompt "BCH error correction capability"
 -	depends on MTD_NAND_OMAP_BCH
 -
 -config MTD_NAND_OMAP_BCH8
 -	bool "8 bits / 512 bytes (recommended)"
 -	help
 -	 Support correcting up to 8 bitflips per 512-byte block.
 -	 This will use 13 bytes of spare area per 512 bytes of page data.
 -	 This is the recommended mode, as 4-bit mode does not work
 -	 on some OMAP3 revisions, due to a hardware bug.
 -
 -config MTD_NAND_OMAP_BCH4
 -	bool "4 bits / 512 bytes"
 -	help
 -	 Support correcting up to 4 bitflips per 512-byte block.
 -	 This will use 7 bytes of spare area per 512 bytes of page data.
 -	 Note that this mode does not work on some OMAP3 revisions, due to a
 -	 hardware bug. Please check your OMAP datasheet before selecting this
 -	 mode.
 -
 -endchoice
 +	  Some devices have built-in ELM hardware engine, which can be used to
 +	  locate and correct errors when using BCH ECC scheme. This enables the
 +	  driver support for same.
  
  if MTD_NAND_OMAP_BCH
  config BCH_CONST_M
-------------- 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/20130702/008501bf/attachment.sig>

From nsekhar at ti.com  Tue Jul  2 01:40:14 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Jul 2013 11:10:14 +0530
Subject: [PATCH 2/4] davinci: da8xx/omap-l1: Remove hard coding of rtc
 device wakeup
In-Reply-To: <1372412109-986-3-git-send-email-gururaja.hebbar@ti.com>
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-3-git-send-email-gururaja.hebbar@ti.com>
Message-ID: <51D267BE.8090605@ti.com>


On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
> duplicate call from the rtc device registration can be removed.
> 
> This is basically a partial revert of the prev commit
> 
> commit 75c99bb0006ee065b4e2995078d779418b0fab54
> Author: Sekhar Nori <nsekhar at ti.com>
> 
>     davinci: da8xx/omap-l1: mark RTC as a wakeup source
> 
> Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> Cc: Sekhar Nori <nsekhar at ti.com>
> Cc: Kevin Hilman <khilman at linaro.org>
> Cc: Russell King <linux at arm.linux.org.uk>

Subject line should be prefixed with ARM: keeping with arch/arm
convention. Otherwise looks good.

Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar


From gururaja.hebbar at ti.com  Tue Jul  2 01:41:37 2013
From: gururaja.hebbar at ti.com (Hebbar, Gururaja)
Date: Tue, 2 Jul 2013 05:41:37 +0000
Subject: [PATCH 2/4] davinci: da8xx/omap-l1: Remove hard coding of rtc
 device wakeup
In-Reply-To: <51D267BE.8090605@ti.com>
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-3-git-send-email-gururaja.hebbar@ti.com>
 <51D267BE.8090605@ti.com>
Message-ID: <1BAFE6F6C881BF42822005164F1491C33EC4E74E@DBDE04.ent.ti.com>

On Tue, Jul 02, 2013 at 11:10:14, Nori, Sekhar wrote:
> 
> On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> > Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
> > duplicate call from the rtc device registration can be removed.
> > 
> > This is basically a partial revert of the prev commit
> > 
> > commit 75c99bb0006ee065b4e2995078d779418b0fab54
> > Author: Sekhar Nori <nsekhar at ti.com>
> > 
> >     davinci: da8xx/omap-l1: mark RTC as a wakeup source
> > 
> > Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> > Cc: Sekhar Nori <nsekhar at ti.com>
> > Cc: Kevin Hilman <khilman at linaro.org>
> > Cc: Russell King <linux at arm.linux.org.uk>
> 
> Subject line should be prefixed with ARM: keeping with arch/arm
> convention. Otherwise looks good.

Will fix it in v2.

> 
> Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks for the review.

> 
> Thanks,
> Sekhar
> 


Regards, 
Gururaja

From pekon at ti.com  Tue Jul  2 01:44:25 2013
From: pekon at ti.com (Gupta, Pekon)
Date: Tue, 2 Jul 2013 05:44:25 +0000
Subject: linux-next: manual merge of the arm-soc tree with the l2-mtd tree
In-Reply-To: <20130702152954.f25bbf51c1a79aa4437e22ee@canb.auug.org.au>
References: <20130702152954.f25bbf51c1a79aa4437e22ee@canb.auug.org.au>
Message-ID: <20980858CB6D3A4BAE95CA194937D5E73E9E3BF5@DBDE04.ent.ti.com>

> 
> Hi all,
> 
> Today's linux-next merge of the arm-soc tree got a conflict in
> Documentation/devicetree/bindings/mtd/gpmc-nand.txt between commits
> 6c88058ef927 ("ARM: OMAP2+: cleaned-up DT support of various ECC
> schemes") and 212012138deb ("mtd: nand: omap2: updated support for
> BCH4
> ECC scheme") from the l2-mtd tree and commit 496c8a0bbb72 ("ARM:
> OMAP2+:
> Allow NAND transfer mode to be specified in DT") from the arm-soc tree.
> 
> I fixed it up (maybe - see below) and can carry the fix as necessary (no
> action is required).
> 
> --
> Cheers,
> Stephen Rothwell                    sfr at canb.auug.org.au
> 
Yes following merge is correct. Apologies, as there were multiple OMAP2 NAND and GPMC updates and clean-up going into different trees, so these conflict came. Going forward you shouldn't find such issues, as code is more stable now. Thanks for help.

with regards, pekon

> diff --cc Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> index b3f23df,df338cb..0000000
> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> @@@ -17,59 -17,27 +17,66 @@@ Required properties
> 
>   Optional properties:
> 
>  - - nand-bus-width: 		Set this numeric value to 16 if the hardware
>  -				is wired that way. If not specified, a bus
>  -				width of 8 is assumed.
>  + - nand-bus-width: 		Determines data-width of the connected
> device
>  +				x16 = "16"
>  +				x8  = "8" (default)
> 
>  - - ti,nand-ecc-opt:		A string setting the ECC layout to use. One of:
> 
>  -		"sw"		Software method (default)
>  -		"hw"		Hardware method
>  -		"hw-romcode"	gpmc hamming mode method & romcode
> layout
>  -		"bch4"		4-bit BCH ecc code
>  -		"bch8"		8-bit BCH ecc code
>  + - ti,nand-ecc-opt:		Determines the ECC scheme used by driver.
>  +				It can be any of the following strings:
>  +
>  +	"hamming_code_sw"		1-bit Hamming ECC
>  +					- ECC calculation in software
>  +					- Error detection in software
>  +					- ECC layout compatible with S/W
> scheme
>  +
>  +	"hamming_code_hw"		1-bit Hamming ECC
>  +					- ECC calculation in hardware
>  +					- Error detection in software
>  +					- ECC layout compatible with S/W
> scheme
>  +
>  +	"hamming_code_hw_romcode"	1-bit Hamming ECC
>  +					- ECC calculation in hardware
>  +					- Error detection in software
>  +					- ECC layout compatible with ROM
> code
>  +
>  +	"bch4_code_hw_detection_sw"	4-bit BCH ECC
>  +					- ECC calculation in hardware
>  +					- Error detection in software
>  +					- ECC layout compatible with S/W
> scheme
>  +					* depends on
> CONFIG_MTD_NAND_ECC_BCH
>  +
>  +	"bch4_code_hw"             	4-bit BCH ECC
>  +					- ECC calculation in hardware
>  +					- Error detection in hardware
>  +					- ECC layout compatible with ROM
> code
>  +					* depends on
> CONFIG_MTD_NAND_OMAP_BCH
>  +					* requires <elm_id> to be specified
>  +
>  +	"bch8_code_hw_detection_sw"	8-bit BCH ECC
>  +					- ECC calculation in hardware
>  +					- Error detection in software
>  +					- ECC layout compatible with S/W
> scheme
>  +					* depends on
> CONFIG_MTD_NAND_ECC_BCH
>  +
>  +	"bch8_code_hw"             	8-bit BCH ECC
>  +					- ECC calculation in hardware
>  +					- Error detection in hardware
>  +					- ECC layout compatible with ROM
> code
>  +					* depends on
> CONFIG_MTD_NAND_OMAP_BCH
>  +					* requires <elm_id> to be specified
> 
> +  - ti,nand-xfer-type:		A string setting the data transfer type. One
> of:
> +
> + 		"prefetch-polled"	Prefetch polled mode (default)
> + 		"polled"		Polled mode, without prefetch
> + 		"prefetch-dma"		Prefetch enabled sDMA
> mode
> + 		"prefetch-irq"		Prefetch enabled irq mode
> +
>  - - elm_id:	Specifies elm device node. This is required to support BCH
>  - 		error correction using ELM module.
>  +
>  + - elm_id:			Specifies elm device node. This is required to
>  +				support some BCH ECC schemes mentioned
> above.
>  +
> 
>   For inline partiton table parsing (optional):
> 


From magnus.damm at gmail.com  Tue Jul  2 01:52:23 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 2 Jul 2013 14:52:23 +0900
Subject: [PATCH 00/03] ARM: 64-bit memory fixes, APE6EVM second memory bank
In-Reply-To: <201306121441.35924.arnd@arndb.de>
References: <20130605104427.1720.68752.sendpatchset@w520>
 <201306051317.02284.arnd@arndb.de>
 <CANqRtoSZXz5-z4pMTM_gpTf11qQCc870Vf35qLQ4jpoCPnq4KQ@mail.gmail.com>
 <201306121441.35924.arnd@arndb.de>
Message-ID: <CANqRtoR=oDnJc48CpvF2GZjL1bBByoaWno58fVAyP9GeqpFSfQ@mail.gmail.com>

Hi Russel, Arnd, Stepan,

On Wed, Jun 12, 2013 at 9:41 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Wednesday 12 June 2013, Magnus Damm wrote:
>> On Wed, Jun 5, 2013 at 8:17 PM, Arnd Bergmann <arnd at arndb.de> wrote:
>> > On Wednesday 05 June 2013, Magnus Damm wrote:
>> >> ARM: 64-bit memory fixes, APE6EVM second memory bank
>> >>
>> >> [PATCH 01/03] ARM: Let arm_add_memory() always use 64-bit arguments
>> >> [PATCH 02/03] ARM: Handle 64-bit memory in case of 32-bit phys_addr_t
>> >> [PATCH 03/03] ARM: shmobile: Add second memory bank to DTS for APE6EVM
>> >>
>> >> This patch set contains two fixes and one mach-shmobile specific patch
>> >> to add a second memory bank. The fixes attempt to improve the memory bank
>> >> handling in the ARM kernel in case of 64-bit addresses.
>> >
>> > Please have a look at this patch that Stepan Moskovchenko posted:
>> >
>> > https://patchwork.kernel.org/patch/2639171/
>> >
>> > I think we are going to need only one of the two approaches.
>>
>> Thanks for pointing out this implementation. Is there anything I can
>> do to move this forward?
>
> I'm fine with either solution. If Russell doesn't have a preference
> one way or the other, I'd suggest you agree with Stepan on one of the
> two and put that into the patch tracker.

Thanks for your guidance, Arnd. After pinging Stepan I assume that he
doesn't have any preference either.

Russel, what is your opinion?

Thanks,

/ magnus


From nsekhar at ti.com  Tue Jul  2 02:02:34 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Jul 2013 11:32:34 +0530
Subject: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
In-Reply-To: <1372412109-986-4-git-send-email-gururaja.hebbar@ti.com>
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-4-git-send-email-gururaja.hebbar@ti.com>
Message-ID: <51D26CFA.5090500@ti.com>

On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
> is available to enable Alarm Wakeup feature. This register needs to be
> properly handled for the rtcwake to work properly.
> 
> Platforms using such IP should set "ti,am3352-rtc" in rtc device dt
> compatibility node.
> 
> Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> Cc: Grant Likely <grant.likely at linaro.org>
> Cc: Rob Herring <rob.herring at calxeda.com>
> Cc: Rob Landley <rob at landley.net>
> Cc: Sekhar Nori <nsekhar at ti.com>
> Cc: Kevin Hilman <khilman at linaro.org>
> Cc: Alessandro Zummo <a.zummo at towertech.it>
> Cc: rtc-linux at googlegroups.com
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: linux-doc at vger.kernel.org
> ---

[...]

> -#define	OMAP_RTC_DATA_DA830_IDX	1
> +#define	OMAP_RTC_DATA_DA830_IDX		1
> +#define	OMAP_RTC_DATA_AM335X_IDX	2
>  
>  static struct platform_device_id omap_rtc_devtype[] = {
>  	{
> @@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] = {
>  	}, {
>  		.name	= "da830-rtc",
>  		.driver_data = OMAP_RTC_HAS_KICKER,
> +	}, {
> +		.name	= "am335x-rtc",

may be use am3352-rtc here just to keep the platform device name and of
compatible in sync.

> +		.driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
>  	},
>  	{},

It is better to use the index defined above in the static initialization
so they remain in sync.

	...
	[OMAP_RTC_DATA_DA830_IDX] = {
		.name	= "da830-rtc",
		.driver_data = OMAP_RTC_HAS_KICKER,
	},
	...

>  };
> @@ -318,6 +333,9 @@ static const struct of_device_id omap_rtc_of_match[] = {
>  	{	.compatible	= "ti,da830-rtc",
>  		.data		= &omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
>  	},
> +	{	.compatible	= "ti,am3352-rtc",
> +		.data		= &omap_rtc_devtype[OMAP_RTC_DATA_AM335X_IDX],
> +	},
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, omap_rtc_of_match);

Apart from these minor issues, the patch looks good to me.

Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar


From gururaja.hebbar at ti.com  Tue Jul  2 02:04:22 2013
From: gururaja.hebbar at ti.com (Hebbar, Gururaja)
Date: Tue, 2 Jul 2013 06:04:22 +0000
Subject: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
In-Reply-To: <51D26CFA.5090500@ti.com>
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-4-git-send-email-gururaja.hebbar@ti.com>
 <51D26CFA.5090500@ti.com>
Message-ID: <1BAFE6F6C881BF42822005164F1491C33EC4E7AB@DBDE04.ent.ti.com>

On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
> On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> > On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
> > is available to enable Alarm Wakeup feature. This register needs to be
> > properly handled for the rtcwake to work properly.
> > 
> > Platforms using such IP should set "ti,am3352-rtc" in rtc device dt
> > compatibility node.
> > 
> > Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> > Cc: Grant Likely <grant.likely at linaro.org>
> > Cc: Rob Herring <rob.herring at calxeda.com>
> > Cc: Rob Landley <rob at landley.net>
> > Cc: Sekhar Nori <nsekhar at ti.com>
> > Cc: Kevin Hilman <khilman at linaro.org>
> > Cc: Alessandro Zummo <a.zummo at towertech.it>
> > Cc: rtc-linux at googlegroups.com
> > Cc: devicetree-discuss at lists.ozlabs.org
> > Cc: linux-doc at vger.kernel.org
> > ---
> 
> [...]
> 
> > -#define	OMAP_RTC_DATA_DA830_IDX	1
> > +#define	OMAP_RTC_DATA_DA830_IDX		1
> > +#define	OMAP_RTC_DATA_AM335X_IDX	2
> >  
> >  static struct platform_device_id omap_rtc_devtype[] = {
> >  	{
> > @@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] = {
> >  	}, {
> >  		.name	= "da830-rtc",
> >  		.driver_data = OMAP_RTC_HAS_KICKER,
> > +	}, {
> > +		.name	= "am335x-rtc",
> 
> may be use am3352-rtc here just to keep the platform device name and of
> compatible in sync.

Correct. I will update the same in v2.

> 
> > +		.driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
> >  	},
> >  	{},
> 
> It is better to use the index defined above in the static initialization
> so they remain in sync.

Sorry. I didn?t get this.

> 
> 	...
> 	[OMAP_RTC_DATA_DA830_IDX] = {
> 		.name	= "da830-rtc",
> 		.driver_data = OMAP_RTC_HAS_KICKER,
> 	},
> 	...
> 
> >  };
> > @@ -318,6 +333,9 @@ static const struct of_device_id omap_rtc_of_match[] = {
> >  	{	.compatible	= "ti,da830-rtc",
> >  		.data		= &omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
> >  	},
> > +	{	.compatible	= "ti,am3352-rtc",
> > +		.data		= &omap_rtc_devtype[OMAP_RTC_DATA_AM335X_IDX],
> > +	},
> >  	{},
> >  };
> >  MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
> 
> Apart from these minor issues, the patch looks good to me.
> 
> Acked-by: Sekhar Nori <nsekhar at ti.com>
> 
> Thanks,
> Sekhar
> 


Regards, 
Gururaja

From olof at lixom.net  Tue Jul  2 02:00:44 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 1 Jul 2013 23:00:44 -0700
Subject: linux-next: manual merge of the arm-soc tree with the l2-mtd tree
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73E9E3BF5@DBDE04.ent.ti.com>
References: <20130702152954.f25bbf51c1a79aa4437e22ee@canb.auug.org.au>
 <20980858CB6D3A4BAE95CA194937D5E73E9E3BF5@DBDE04.ent.ti.com>
Message-ID: <CAOesGMgh=CLCrtohrNF59Sh40-weCorL1_yjFgFKr47qhVy+xg@mail.gmail.com>

On Mon, Jul 1, 2013 at 10:44 PM, Gupta, Pekon <pekon at ti.com> wrote:
>>
>> Hi all,
>>
>> Today's linux-next merge of the arm-soc tree got a conflict in
>> Documentation/devicetree/bindings/mtd/gpmc-nand.txt between commits
>> 6c88058ef927 ("ARM: OMAP2+: cleaned-up DT support of various ECC
>> schemes") and 212012138deb ("mtd: nand: omap2: updated support for
>> BCH4
>> ECC scheme") from the l2-mtd tree and commit 496c8a0bbb72 ("ARM:
>> OMAP2+:
>> Allow NAND transfer mode to be specified in DT") from the arm-soc tree.
>>
>> I fixed it up (maybe - see below) and can carry the fix as necessary (no
>> action is required).
>>
>> --
>> Cheers,
>> Stephen Rothwell                    sfr at canb.auug.org.au
>>
> Yes following merge is correct. Apologies, as there were multiple OMAP2 NAND and GPMC updates and clean-up going into different trees, so these conflict came. Going forward you shouldn't find such issues, as code is more stable now. Thanks for help.
>
> with regards, pekon

Sigh. The new bindings seem to never have been reviewed by any device
tree maintainers, and from the look of it, it might need some
discussion. It wasn't even cc:d to devicetree-discuss.

It's completely inappropriate to merge a patch like this at this time
without any kind of acks from the people reviewing bindings. Can it
please be dropped ASAP from the MTD tree? Thanks!

Or, if you want it in different wording: The mtd-tree patch is a
strong NAK until this has been sorted out.

It was also applied today, after the merge window opened. Don't merge
it for 3.11. Artem?


-Olof


From nsekhar at ti.com  Tue Jul  2 02:09:28 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Jul 2013 11:39:28 +0530
Subject: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
In-Reply-To: <1BAFE6F6C881BF42822005164F1491C33EC4E7AB@DBDE04.ent.ti.com>
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-4-git-send-email-gururaja.hebbar@ti.com>
 <51D26CFA.5090500@ti.com>
 <1BAFE6F6C881BF42822005164F1491C33EC4E7AB@DBDE04.ent.ti.com>
Message-ID: <51D26E98.9040303@ti.com>

On 7/2/2013 11:34 AM, Hebbar, Gururaja wrote:
> On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
>> On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
>>> On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
>>> is available to enable Alarm Wakeup feature. This register needs to be
>>> properly handled for the rtcwake to work properly.
>>>
>>> Platforms using such IP should set "ti,am3352-rtc" in rtc device dt
>>> compatibility node.
>>>
>>> Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
>>> Cc: Grant Likely <grant.likely at linaro.org>
>>> Cc: Rob Herring <rob.herring at calxeda.com>
>>> Cc: Rob Landley <rob at landley.net>
>>> Cc: Sekhar Nori <nsekhar at ti.com>
>>> Cc: Kevin Hilman <khilman at linaro.org>
>>> Cc: Alessandro Zummo <a.zummo at towertech.it>
>>> Cc: rtc-linux at googlegroups.com
>>> Cc: devicetree-discuss at lists.ozlabs.org
>>> Cc: linux-doc at vger.kernel.org
>>> ---
>>
>> [...]
>>
>>> -#define	OMAP_RTC_DATA_DA830_IDX	1
>>> +#define	OMAP_RTC_DATA_DA830_IDX		1
>>> +#define	OMAP_RTC_DATA_AM335X_IDX	2
>>>  
>>>  static struct platform_device_id omap_rtc_devtype[] = {
>>>  	{
>>> @@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] = {
>>>  	}, {
>>>  		.name	= "da830-rtc",
>>>  		.driver_data = OMAP_RTC_HAS_KICKER,
>>> +	}, {
>>> +		.name	= "am335x-rtc",
>>
>> may be use am3352-rtc here just to keep the platform device name and of
>> compatible in sync.
> 
> Correct. I will update the same in v2.
> 
>>
>>> +		.driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
>>>  	},
>>>  	{},
>>
>> It is better to use the index defined above in the static initialization
>> so they remain in sync.
> 
> Sorry. I didn?t get this.
> 

See example below I provided. If its still not clear, let me know what
is not clear.

>> 	...
>> 	[OMAP_RTC_DATA_DA830_IDX] = {
>> 		.name	= "da830-rtc",
>> 		.driver_data = OMAP_RTC_HAS_KICKER,
>> 	},

Thanks,
Sekhar


From gururaja.hebbar at ti.com  Tue Jul  2 02:11:01 2013
From: gururaja.hebbar at ti.com (Hebbar, Gururaja)
Date: Tue, 2 Jul 2013 06:11:01 +0000
Subject: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
In-Reply-To: <51D26E98.9040303@ti.com>
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-4-git-send-email-gururaja.hebbar@ti.com>
 <51D26CFA.5090500@ti.com>
 <1BAFE6F6C881BF42822005164F1491C33EC4E7AB@DBDE04.ent.ti.com>
 <51D26E98.9040303@ti.com>
Message-ID: <1BAFE6F6C881BF42822005164F1491C33EC4E7CC@DBDE04.ent.ti.com>

On Tue, Jul 02, 2013 at 11:39:28, Nori, Sekhar wrote:
> On 7/2/2013 11:34 AM, Hebbar, Gururaja wrote:
> > On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
> >> On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> >>> On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
> >>> is available to enable Alarm Wakeup feature. This register needs to be
> >>> properly handled for the rtcwake to work properly.
> >>>
> >>> Platforms using such IP should set "ti,am3352-rtc" in rtc device dt
> >>> compatibility node.
> >>>
> >>> Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> >>> Cc: Grant Likely <grant.likely at linaro.org>
> >>> Cc: Rob Herring <rob.herring at calxeda.com>
> >>> Cc: Rob Landley <rob at landley.net>
> >>> Cc: Sekhar Nori <nsekhar at ti.com>
> >>> Cc: Kevin Hilman <khilman at linaro.org>
> >>> Cc: Alessandro Zummo <a.zummo at towertech.it>
> >>> Cc: rtc-linux at googlegroups.com
> >>> Cc: devicetree-discuss at lists.ozlabs.org
> >>> Cc: linux-doc at vger.kernel.org
> >>> ---
> >>
> >> [...]
> >>
> >>> -#define	OMAP_RTC_DATA_DA830_IDX	1
> >>> +#define	OMAP_RTC_DATA_DA830_IDX		1
> >>> +#define	OMAP_RTC_DATA_AM335X_IDX	2
> >>>  
> >>>  static struct platform_device_id omap_rtc_devtype[] = {
> >>>  	{
> >>> @@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] = {
> >>>  	}, {
> >>>  		.name	= "da830-rtc",
> >>>  		.driver_data = OMAP_RTC_HAS_KICKER,
> >>> +	}, {
> >>> +		.name	= "am335x-rtc",
> >>
> >> may be use am3352-rtc here just to keep the platform device name and of
> >> compatible in sync.
> > 
> > Correct. I will update the same in v2.
> > 
> >>
> >>> +		.driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
> >>>  	},
> >>>  	{},
> >>
> >> It is better to use the index defined above in the static initialization
> >> so they remain in sync.
> > 
> > Sorry. I didn?t get this.
> > 
> 
> See example below I provided. If its still not clear, let me know what
> is not clear.
> 
> >> 	...
> >> 	[OMAP_RTC_DATA_DA830_IDX] = {
> >> 		.name	= "da830-rtc",
> >> 		.driver_data = OMAP_RTC_HAS_KICKER,
> >> 	},

Thanks for the clarification. In this case will it ok if I update the previous
member also.

> 
> Thanks,
> Sekhar
> 


Regards, 
Gururaja

From nsekhar at ti.com  Tue Jul  2 02:12:49 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Jul 2013 11:42:49 +0530
Subject: [PATCH 4/4] ARM: dts: AM33XX: update rtc node compatibility
In-Reply-To: <1372412109-986-5-git-send-email-gururaja.hebbar@ti.com>
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-5-git-send-email-gururaja.hebbar@ti.com>
Message-ID: <51D26F61.7080308@ti.com>

Changing to Benoit's gmail id since he apparently wont access TI mail
anymore.

On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> Since AM33xx  RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
> 
> Update the rtc compatible property to "ti,am3352-rtc" to enable handling
> of this feature inside rtc-omap driver.
> 
> Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> Cc: Tony Lindgren <tony at atomide.com>
> Cc: Sekhar Nori <nsekhar at ti.com>
> Cc: Kevin Hilman <khilman at linaro.org>
> Cc: b-cousson at ti.com
> ---
> :100644 100644 77aa1b0... dde180a... M	arch/arm/boot/dts/am33xx.dtsi
>  arch/arm/boot/dts/am33xx.dtsi |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 77aa1b0..dde180a 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -297,7 +297,7 @@
>  		};
>  
>  		rtc at 44e3e000 {
> -			compatible = "ti,da830-rtc";
> +			compatible = "ti,am3352-rtc";

compatible is a list so you can instead do:
	
	compatible = "ti,am3352-rtc", "ti,da830-rtc";

That way the dts works irrespective of driver updates. When driver
supports enhanced features of hardware, they are available to the user
else the basic functionality still works.

Thanks,
Sekhar


From gururaja.hebbar at ti.com  Tue Jul  2 02:14:30 2013
From: gururaja.hebbar at ti.com (Hebbar, Gururaja)
Date: Tue, 2 Jul 2013 06:14:30 +0000
Subject: [PATCH 4/4] ARM: dts: AM33XX: update rtc node compatibility
In-Reply-To: <51D26F61.7080308@ti.com>
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-5-git-send-email-gururaja.hebbar@ti.com>
 <51D26F61.7080308@ti.com>
Message-ID: <1BAFE6F6C881BF42822005164F1491C33EC4E7E6@DBDE04.ent.ti.com>

On Tue, Jul 02, 2013 at 11:42:49, Nori, Sekhar wrote:
> Changing to Benoit's gmail id since he apparently wont access TI mail
> anymore.
> 
> On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> > Since AM33xx  RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
> > 
> > Update the rtc compatible property to "ti,am3352-rtc" to enable handling
> > of this feature inside rtc-omap driver.
> > 
> > Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> > Cc: Tony Lindgren <tony at atomide.com>
> > Cc: Sekhar Nori <nsekhar at ti.com>
> > Cc: Kevin Hilman <khilman at linaro.org>
> > Cc: b-cousson at ti.com
> > ---
> > :100644 100644 77aa1b0... dde180a... M	arch/arm/boot/dts/am33xx.dtsi
> >  arch/arm/boot/dts/am33xx.dtsi |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > index 77aa1b0..dde180a 100644
> > --- a/arch/arm/boot/dts/am33xx.dtsi
> > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > @@ -297,7 +297,7 @@
> >  		};
> >  
> >  		rtc at 44e3e000 {
> > -			compatible = "ti,da830-rtc";
> > +			compatible = "ti,am3352-rtc";
> 
> compatible is a list so you can instead do:
> 	
> 	compatible = "ti,am3352-rtc", "ti,da830-rtc";
> 
> That way the dts works irrespective of driver updates. When driver
> supports enhanced features of hardware, they are available to the user
> else the basic functionality still works.

Ok. I will update the same now in v2.

> 
> Thanks,
> Sekhar
> 


Regards, 
Gururaja

From nsekhar at ti.com  Tue Jul  2 02:16:50 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 2 Jul 2013 11:46:50 +0530
Subject: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
In-Reply-To: <1BAFE6F6C881BF42822005164F1491C33EC4E7CC@DBDE04.ent.ti.com>
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-4-git-send-email-gururaja.hebbar@ti.com>
 <51D26CFA.5090500@ti.com>
 <1BAFE6F6C881BF42822005164F1491C33EC4E7AB@DBDE04.ent.ti.com>
 <51D26E98.9040303@ti.com>
 <1BAFE6F6C881BF42822005164F1491C33EC4E7CC@DBDE04.ent.ti.com>
Message-ID: <51D27052.6080303@ti.com>



On 7/2/2013 11:41 AM, Hebbar, Gururaja wrote:
> On Tue, Jul 02, 2013 at 11:39:28, Nori, Sekhar wrote:
>> On 7/2/2013 11:34 AM, Hebbar, Gururaja wrote:
>>> On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
>>>> On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
>>>>> On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
>>>>> is available to enable Alarm Wakeup feature. This register needs to be
>>>>> properly handled for the rtcwake to work properly.
>>>>>
>>>>> Platforms using such IP should set "ti,am3352-rtc" in rtc device dt
>>>>> compatibility node.
>>>>>
>>>>> Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
>>>>> Cc: Grant Likely <grant.likely at linaro.org>
>>>>> Cc: Rob Herring <rob.herring at calxeda.com>
>>>>> Cc: Rob Landley <rob at landley.net>
>>>>> Cc: Sekhar Nori <nsekhar at ti.com>
>>>>> Cc: Kevin Hilman <khilman at linaro.org>
>>>>> Cc: Alessandro Zummo <a.zummo at towertech.it>
>>>>> Cc: rtc-linux at googlegroups.com
>>>>> Cc: devicetree-discuss at lists.ozlabs.org
>>>>> Cc: linux-doc at vger.kernel.org
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> -#define	OMAP_RTC_DATA_DA830_IDX	1
>>>>> +#define	OMAP_RTC_DATA_DA830_IDX		1
>>>>> +#define	OMAP_RTC_DATA_AM335X_IDX	2
>>>>>  
>>>>>  static struct platform_device_id omap_rtc_devtype[] = {
>>>>>  	{
>>>>> @@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] = {
>>>>>  	}, {
>>>>>  		.name	= "da830-rtc",
>>>>>  		.driver_data = OMAP_RTC_HAS_KICKER,
>>>>> +	}, {
>>>>> +		.name	= "am335x-rtc",
>>>>
>>>> may be use am3352-rtc here just to keep the platform device name and of
>>>> compatible in sync.
>>>
>>> Correct. I will update the same in v2.
>>>
>>>>
>>>>> +		.driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
>>>>>  	},
>>>>>  	{},
>>>>
>>>> It is better to use the index defined above in the static initialization
>>>> so they remain in sync.
>>>
>>> Sorry. I didn?t get this.
>>>
>>
>> See example below I provided. If its still not clear, let me know what
>> is not clear.
>>
>>>> 	...
>>>> 	[OMAP_RTC_DATA_DA830_IDX] = {
>>>> 		.name	= "da830-rtc",
>>>> 		.driver_data = OMAP_RTC_HAS_KICKER,
>>>> 	},
> 
> Thanks for the clarification. In this case will it ok if I update the previous
> member also.

You dont really reference [0] in omap_rtc_of_match[] so even if you
leave it as-is, that's fine with me. I am mostly concerned with the
index definitions and initialization order being out of sync and that's
really not an issue with [0].

Thanks,
Sekhar


From pekon at ti.com  Tue Jul  2 02:18:28 2013
From: pekon at ti.com (Gupta, Pekon)
Date: Tue, 2 Jul 2013 06:18:28 +0000
Subject: linux-next: manual merge of the arm-soc tree with the l2-mtd tree
In-Reply-To: <CAOesGMgh=CLCrtohrNF59Sh40-weCorL1_yjFgFKr47qhVy+xg@mail.gmail.com>
References: <20130702152954.f25bbf51c1a79aa4437e22ee@canb.auug.org.au>
 <20980858CB6D3A4BAE95CA194937D5E73E9E3BF5@DBDE04.ent.ti.com>
 <CAOesGMgh=CLCrtohrNF59Sh40-weCorL1_yjFgFKr47qhVy+xg@mail.gmail.com>
Message-ID: <20980858CB6D3A4BAE95CA194937D5E73E9E3C27@DBDE04.ent.ti.com>

> 
> On Mon, Jul 1, 2013 at 10:44 PM, Gupta, Pekon <pekon at ti.com> wrote:
> >>
> >> Hi all,
> >>
> >> Today's linux-next merge of the arm-soc tree got a conflict in
> >> Documentation/devicetree/bindings/mtd/gpmc-nand.txt between
> commits
> >> 6c88058ef927 ("ARM: OMAP2+: cleaned-up DT support of various ECC
> >> schemes") and 212012138deb ("mtd: nand: omap2: updated support for
> >> BCH4
> >> ECC scheme") from the l2-mtd tree and commit 496c8a0bbb72 ("ARM:
> >> OMAP2+:
> >> Allow NAND transfer mode to be specified in DT") from the arm-soc tree.
> >>
> >> I fixed it up (maybe - see below) and can carry the fix as necessary (no
> >> action is required).
> >>
> >> --
> >> Cheers,
> >> Stephen Rothwell                    sfr at canb.auug.org.au
> >>
> > Yes following merge is correct. Apologies, as there were multiple OMAP2
> NAND and GPMC updates and clean-up going into different trees, so these
> conflict came. Going forward you shouldn't find such issues, as code is more
> stable now. Thanks for help.
> >
> > with regards, pekon
> 
> Sigh. The new bindings seem to never have been reviewed by any device
> tree maintainers, and from the look of it, it might need some
> discussion. It wasn't even cc:d to devicetree-discuss.
> 
> It's completely inappropriate to merge a patch like this at this time
> without any kind of acks from the people reviewing bindings. Can it
> please be dropped ASAP from the MTD tree? Thanks!
> 
> Or, if you want it in different wording: The mtd-tree patch is a
> strong NAK until this has been sorted out.
> 
> It was also applied today, after the merge window opened. Don't merge
> it for 3.11. Artem?
> 
> 
Hi OIof,

You may drop this patch if you wish so, but its not correct to say that this
was not reviewed. Following are comments from "Arnd Bergmann"
http://lists.infradead.org/pipermail/linux-mtd/2013-May/047030.html
And follow-up reasoning..
http://lists.infradead.org/pipermail/linux-mtd/2013-May/047032.html


And based on Arnd's feedbacks patches which contained changes in 
binding string was even dropped from the series, please see 
cover-letter of V3 set below.
http://lists.infradead.org/pipermail/linux-mtd/2013-June/047319.html
- PATCH-4 <DROPPED> update DT attribute for ti,nand-ecc-opt 
	- received feedback to keep DT mapping independent of linuxism
- PATCH-4:<NEW> : ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt
	- independent patch for AM335x-evm.dts update based on PATCH-2

So, in case you have objections to same earlier patch where I had
introduced 'linux-based' nomenclature for bindings, that particular
one is already dropped in V3 of this patch series.


with regards, pekon


From gururaja.hebbar at ti.com  Tue Jul  2 02:19:45 2013
From: gururaja.hebbar at ti.com (Hebbar, Gururaja)
Date: Tue, 2 Jul 2013 06:19:45 +0000
Subject: [PATCH 4/4] ARM: dts: AM33XX: update rtc node compatibility
In-Reply-To: <51D26F61.7080308@ti.com>
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-5-git-send-email-gururaja.hebbar@ti.com>
 <51D26F61.7080308@ti.com>
Message-ID: <1BAFE6F6C881BF42822005164F1491C33EC4E80D@DBDE04.ent.ti.com>

On Tue, Jul 02, 2013 at 11:42:49, Nori, Sekhar wrote:
> Changing to Benoit's gmail id since he apparently wont access TI mail
> anymore.
> 
> On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> > Since AM33xx  RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
> > 
> > Update the rtc compatible property to "ti,am3352-rtc" to enable handling
> > of this feature inside rtc-omap driver.
> > 
> > Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> > Cc: Tony Lindgren <tony at atomide.com>
> > Cc: Sekhar Nori <nsekhar at ti.com>
> > Cc: Kevin Hilman <khilman at linaro.org>
> > Cc: b-cousson at ti.com
> > ---
> > :100644 100644 77aa1b0... dde180a... M	arch/arm/boot/dts/am33xx.dtsi
> >  arch/arm/boot/dts/am33xx.dtsi |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > index 77aa1b0..dde180a 100644
> > --- a/arch/arm/boot/dts/am33xx.dtsi
> > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > @@ -297,7 +297,7 @@
> >  		};
> >  
> >  		rtc at 44e3e000 {
> > -			compatible = "ti,da830-rtc";
> > +			compatible = "ti,am3352-rtc";
> 
> compatible is a list so you can instead do:
> 	
> 	compatible = "ti,am3352-rtc", "ti,da830-rtc";

I believe the order is not important here. I mean, below is also fine. Right?

	compatible = "ti,da830-rtc", "ti,am3352-rtc";


> 
> That way the dts works irrespective of driver updates. When driver
> supports enhanced features of hardware, they are available to the user
> else the basic functionality still works.
> 
> Thanks,
> Sekhar
> 


Regards, 
Gururaja

From michael at ellerman.id.au  Tue Jul  2 02:52:20 2013
From: michael at ellerman.id.au (Michael Ellerman)
Date: Tue, 2 Jul 2013 16:52:20 +1000
Subject: [PATCHv4 02/11] pci: use weak functions for MSI arch-specific
 functions
In-Reply-To: <20130702073037.55a53642@skate>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-3-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372726396.17904.1.camel@concordia>
 <20130702073037.55a53642@skate>
Message-ID: <20130702065220.GA20521@concordia>

On Tue, Jul 02, 2013 at 07:30:37AM +0200, Thomas Petazzoni wrote:
> Dear Michael Ellerman,
> 
> On Tue, 02 Jul 2013 10:53:16 +1000, Michael Ellerman wrote:
> > On Mon, 2013-07-01 at 15:42 +0200, Thomas Petazzoni wrote:
> > > Until now, the MSI architecture-specific functions could be overloaded
> > > using a fairly complex set of #define and compile-time
> > > conditionals. In order to prepare for the introduction of the msi_chip
> > > infrastructure, it is desirable to switch all those functions to use
> > > the 'weak' mechanism. This commit converts all the architectures that
> > > were overidding those MSI functions to use the new strategy.
> > 
> > The MSI code used to use weak functions, until we discovered they were
> > being miscompiled on some toolchains (11df1f0). I assume these days
> > we're confident they work correctly.
> 
> Hum, interesting. I see from your commit that gcc 4.3.2 was apparently
> affected, and gcc 4.3.x is not /that/ old. Bjorn, what's your point of
> view on this?

Stop press.

I went back and found the old threads on this, it's been a while. It
looks like it was only gcc 4.1.[01] that miscompiled. The reference to
gcc 4.3.2 was WRT ellision of the unused code, which is a separate
issue.

The kernel blacklists gcc 4.1.[01] (see f9d1425), so weak should be
safe to use.

We merged the change to the PCI code anyway because we thought it was
nicer and it also avoided any problems with weak.

So pretend I never said anything :)

cheers


From b32955 at freescale.com  Tue Jul  2 02:30:23 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 2 Jul 2013 14:30:23 +0800
Subject: [PATCH 0/5] serial: imx: add DMA support for imx6
Message-ID: <1372746628-20092-1-git-send-email-b32955@freescale.com>

(1) This patch set adds the DMA support for the imx serial driver.
    The uart with the dma support is usually used by the Bluetooth.

    For the firmware's limit, i only enable the DMA for imx6.
    If we have proper firmware for imx53 (or other chips), we can also
    enable the DMA for it.

(2) We only enable the DMA support when the following are meet:

    [1] The uart port supports the hardware flow control(CTS/RTS).
      (Some uart port does not support the CTS/RTS.)

    [2] The application enables the CTS/RTS.

    [3] The Soc is imx6.
      For the sdma's firmware limit, we do not support the DMA except
      the imx6 platform.

    [4] The uart is not used as a console.


(3) Tested this patch set by:
	connecting a imx6q-arm2 board(DTE) with a imx53 board(DCE).


Huang Shijie (5):
  serial: imx: distinguish the imx6 uart from the others
  serial: imx: add DMA support for imx6
  ARM: dts: imx6: rename the uart's compatible property
  ARM: dts: imx6: add dte pinctrl for uart2
  ARM: dts: enable the uart2 for imx6q-arm2

 arch/arm/boot/dts/imx6q-arm2.dts |   10 +
 arch/arm/boot/dts/imx6q.dtsi     |    9 +
 arch/arm/boot/dts/imx6qdl.dtsi   |   10 +-
 arch/arm/boot/dts/imx6sl.dtsi    |   10 +-
 drivers/tty/serial/imx.c         |  430 +++++++++++++++++++++++++++++++++++++-
 5 files changed, 452 insertions(+), 17 deletions(-)




From b32955 at freescale.com  Tue Jul  2 02:30:24 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 2 Jul 2013 14:30:24 +0800
Subject: [PATCH 1/5] serial: imx: distinguish the imx6 uart from the others
In-Reply-To: <1372746628-20092-1-git-send-email-b32955@freescale.com>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
Message-ID: <1372746628-20092-2-git-send-email-b32955@freescale.com>

We will add the DMA support for the imx uart. For the firmware's limit,
only the imx6 uart can supports the DMA.

This patch adds the necessary macro and helper to distinguish the imx6 uart
from the other imx uart.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 drivers/tty/serial/imx.c |   17 +++++++++++++++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 48bace0..d215fa9 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -187,6 +187,7 @@
 enum imx_uart_type {
 	IMX1_UART,
 	IMX21_UART,
+	IMX6_UART,
 };
 
 /* device type dependent stuff */
@@ -232,6 +233,10 @@ static struct imx_uart_data imx_uart_devdata[] = {
 		.uts_reg = IMX21_UTS,
 		.devtype = IMX21_UART,
 	},
+	[IMX6_UART] = {
+		.uts_reg = IMX21_UTS,
+		.devtype = IMX6_UART,
+	},
 };
 
 static struct platform_device_id imx_uart_devtype[] = {
@@ -242,6 +247,9 @@ static struct platform_device_id imx_uart_devtype[] = {
 		.name = "imx21-uart",
 		.driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX21_UART],
 	}, {
+		.name = "imx6-uart",
+		.driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX6_UART],
+	}, {
 		/* sentinel */
 	}
 };
@@ -250,6 +258,7 @@ MODULE_DEVICE_TABLE(platform, imx_uart_devtype);
 static struct of_device_id imx_uart_dt_ids[] = {
 	{ .compatible = "fsl,imx1-uart", .data = &imx_uart_devdata[IMX1_UART], },
 	{ .compatible = "fsl,imx21-uart", .data = &imx_uart_devdata[IMX21_UART], },
+	{ .compatible = "fsl,imx6-uart", .data = &imx_uart_devdata[IMX6_UART], },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, imx_uart_dt_ids);
@@ -269,6 +278,10 @@ static inline int is_imx21_uart(struct imx_port *sport)
 	return sport->devdata->devtype == IMX21_UART;
 }
 
+static inline int is_imx6_uart(struct imx_port *sport)
+{
+	return sport->devdata->devtype == IMX6_UART;
+}
 /*
  * Save and restore functions for UCR1, UCR2 and UCR3 registers
  */
@@ -801,7 +814,7 @@ static int imx_startup(struct uart_port *port)
 		}
 	}
 
-	if (is_imx21_uart(sport)) {
+	if (is_imx21_uart(sport) || is_imx6_uart(sport)) {
 		temp = readl(sport->port.membase + UCR3);
 		temp |= IMX21_UCR3_RXDMUXSEL;
 		writel(temp, sport->port.membase + UCR3);
@@ -1044,7 +1057,7 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 	writel(num, sport->port.membase + UBIR);
 	writel(denom, sport->port.membase + UBMR);
 
-	if (is_imx21_uart(sport))
+	if (is_imx21_uart(sport) || is_imx6_uart(sport))
 		writel(sport->port.uartclk / div / 1000,
 				sport->port.membase + IMX21_ONEMS);
 
-- 
1.7.1




From b32955 at freescale.com  Tue Jul  2 02:30:26 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 2 Jul 2013 14:30:26 +0800
Subject: [PATCH 3/5] ARM: dts: imx6: rename the uart's compatible property
In-Reply-To: <1372746628-20092-1-git-send-email-b32955@freescale.com>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
Message-ID: <1372746628-20092-4-git-send-email-b32955@freescale.com>

The imx6 uart can supports the DMA, imx uart driver has added a new
compatible property for the imx6 uart.

In order to enable the DMA for some uart port in imx6, we rename the
uart's compatible property to "fsl,imx6-uart".

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6qdl.dtsi |   10 +++++-----
 arch/arm/boot/dts/imx6sl.dtsi  |   10 +++++-----
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 0509344..d4ab0ee 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -179,7 +179,7 @@
 				};
 
 				uart1: serial at 02020000 {
-					compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6-uart";
 					reg = <0x02020000 0x4000>;
 					interrupts = <0 26 0x04>;
 					clocks = <&clks 160>, <&clks 161>;
@@ -787,7 +787,7 @@
 			};
 
 			uart2: serial at 021e8000 {
-				compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
+				compatible = "fsl,imx6-uart";
 				reg = <0x021e8000 0x4000>;
 				interrupts = <0 27 0x04>;
 				clocks = <&clks 160>, <&clks 161>;
@@ -796,7 +796,7 @@
 			};
 
 			uart3: serial at 021ec000 {
-				compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
+				compatible = "fsl,imx6-uart";
 				reg = <0x021ec000 0x4000>;
 				interrupts = <0 28 0x04>;
 				clocks = <&clks 160>, <&clks 161>;
@@ -805,7 +805,7 @@
 			};
 
 			uart4: serial at 021f0000 {
-				compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
+				compatible = "fsl,imx6-uart";
 				reg = <0x021f0000 0x4000>;
 				interrupts = <0 29 0x04>;
 				clocks = <&clks 160>, <&clks 161>;
@@ -814,7 +814,7 @@
 			};
 
 			uart5: serial at 021f4000 {
-				compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
+				compatible = "fsl,imx6-uart";
 				reg = <0x021f4000 0x4000>;
 				interrupts = <0 30 0x04>;
 				clocks = <&clks 160>, <&clks 161>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 9138c67..ca1527f 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -152,7 +152,7 @@
 				};
 
 				uart5: serial at 02018000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6-uart";
 					reg = <0x02018000 0x4000>;
 					interrupts = <0 30 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -162,7 +162,7 @@
 				};
 
 				uart1: serial at 02020000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6-uart";
 					reg = <0x02020000 0x4000>;
 					interrupts = <0 26 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -172,7 +172,7 @@
 				};
 
 				uart2: serial at 02024000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6-uart";
 					reg = <0x02024000 0x4000>;
 					interrupts = <0 27 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -209,7 +209,7 @@
 				};
 
 				uart3: serial at 02034000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6-uart";
 					reg = <0x02034000 0x4000>;
 					interrupts = <0 28 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -219,7 +219,7 @@
 				};
 
 				uart4: serial at 02038000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6-uart";
 					reg = <0x02038000 0x4000>;
 					interrupts = <0 29 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
-- 
1.7.1




From b32955 at freescale.com  Tue Jul  2 02:30:25 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 2 Jul 2013 14:30:25 +0800
Subject: [PATCH 2/5] serial: imx: add DMA support for imx6
In-Reply-To: <1372746628-20092-1-git-send-email-b32955@freescale.com>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
Message-ID: <1372746628-20092-3-git-send-email-b32955@freescale.com>

We only enable the DMA support when the following are meet:

  [1] The uart port supports the hardware flow control(CTS/RTS).
      (Some uart port does not support the CTS/RTS.)

  [2] The application enables the CTS/RTS.

  [3] The Soc is imx6.
      For the sdma's firmware limit, we do not support the DMA except
      the imx6 platform.

  [4] The uart is not used as a console.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 drivers/tty/serial/imx.c |  413 +++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 408 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index d215fa9..2a4cf89 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -49,9 +49,11 @@
 #include <linux/of_device.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/io.h>
+#include <linux/dma-mapping.h>
 
 #include <asm/irq.h>
 #include <linux/platform_data/serial-imx.h>
+#include <linux/platform_data/dma-imx.h>
 
 /* Register definitions */
 #define URXD0 0x0  /* Receiver Register */
@@ -83,6 +85,7 @@
 #define UCR1_ADBR	(1<<14) /* Auto detect baud rate */
 #define UCR1_TRDYEN	(1<<13) /* Transmitter ready interrupt enable */
 #define UCR1_IDEN	(1<<12) /* Idle condition interrupt */
+#define UCR1_ICD_REG(x) (((x) & 3) << 10) /* idle condition detect */
 #define UCR1_RRDYEN	(1<<9)	/* Recv ready interrupt enable */
 #define UCR1_RDMAEN	(1<<8)	/* Recv ready DMA enable */
 #define UCR1_IREN	(1<<7)	/* Infrared interface enable */
@@ -91,6 +94,7 @@
 #define UCR1_SNDBRK	(1<<4)	/* Send break */
 #define UCR1_TDMAEN	(1<<3)	/* Transmitter ready DMA enable */
 #define IMX1_UCR1_UARTCLKEN (1<<2) /* UART clock enabled, i.mx1 only */
+#define UCR1_ATDMAEN    (1<<2)  /* Aging DMA Timer Enable */
 #define UCR1_DOZE	(1<<1)	/* Doze */
 #define UCR1_UARTEN	(1<<0)	/* UART enabled */
 #define UCR2_ESCI	(1<<15)	/* Escape seq interrupt enable */
@@ -126,6 +130,7 @@
 #define UCR4_ENIRI	(1<<8)	/* Serial infrared interrupt enable */
 #define UCR4_WKEN	(1<<7)	/* Wake interrupt enable */
 #define UCR4_REF16	(1<<6)	/* Ref freq 16 MHz */
+#define UCR4_IDDMAEN    (1<<6)  /* DMA IDLE Condition Detected */
 #define UCR4_IRSC	(1<<5)	/* IR special case */
 #define UCR4_TCEN	(1<<3)	/* Transmit complete interrupt enable */
 #define UCR4_BKEN	(1<<2)	/* Break condition interrupt enable */
@@ -210,6 +215,19 @@ struct imx_port {
 	struct clk		*clk_ipg;
 	struct clk		*clk_per;
 	const struct imx_uart_data *devdata;
+
+	/* DMA fields */
+	unsigned int		dma_is_inited:1;
+	unsigned int		dma_is_enabled:1;
+	unsigned int		dma_is_rxing:1;
+	unsigned int		dma_is_txing:1;
+	struct dma_chan		*dma_chan_rx, *dma_chan_tx;
+	struct scatterlist	rx_sgl, tx_sgl[2];
+	void			*rx_buf;
+	unsigned int		rx_bytes, tx_bytes;
+	struct work_struct	tsk_dma_rx, tsk_dma_tx;
+	unsigned int		dma_tx_nents;
+	wait_queue_head_t	dma_wait;
 };
 
 struct imx_port_ucrs {
@@ -400,6 +418,13 @@ static void imx_stop_tx(struct uart_port *port)
 		return;
 	}
 
+	/*
+	 * We are maybe in the SMP context, so if the DMA TX thread is running
+	 * on other cpu, we have to wait for it to finish.
+	 */
+	if (sport->dma_is_enabled && sport->dma_is_txing)
+		return;
+
 	temp = readl(sport->port.membase + UCR1);
 	writel(temp & ~UCR1_TXMPTYEN, sport->port.membase + UCR1);
 }
@@ -412,6 +437,13 @@ static void imx_stop_rx(struct uart_port *port)
 	struct imx_port *sport = (struct imx_port *)port;
 	unsigned long temp;
 
+	/*
+	 * We are maybe in the SMP context, so if the DMA TX thread is running
+	 * on other cpu, we have to wait for it to finish.
+	 */
+	if (sport->dma_is_enabled && sport->dma_is_rxing)
+		return;
+
 	temp = readl(sport->port.membase + UCR2);
 	writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
 }
@@ -447,6 +479,96 @@ static inline void imx_transmit_buffer(struct imx_port *sport)
 		imx_stop_tx(&sport->port);
 }
 
+static void dma_tx_callback(void *data)
+{
+	struct imx_port *sport = data;
+	struct scatterlist *sgl = &sport->tx_sgl[0];
+	struct circ_buf *xmit = &sport->port.state->xmit;
+	unsigned long flags;
+
+	dma_unmap_sg(sport->port.dev, sgl, sport->dma_tx_nents, DMA_TO_DEVICE);
+
+	sport->dma_is_txing = 0;
+
+	/* update the stat */
+	spin_lock_irqsave(&sport->port.lock, flags);
+	xmit->tail = (xmit->tail + sport->tx_bytes) & (UART_XMIT_SIZE - 1);
+	sport->port.icount.tx += sport->tx_bytes;
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+
+	dev_dbg(sport->port.dev, "we finish the TX DMA.\n");
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(&sport->port);
+
+	if (waitqueue_active(&sport->dma_wait)) {
+		wake_up(&sport->dma_wait);
+		dev_dbg(sport->port.dev, "exit in %s.\n", __func__);
+		return;
+	}
+
+	schedule_work(&sport->tsk_dma_tx);
+}
+
+static void dma_tx_work(struct work_struct *w)
+{
+	struct imx_port *sport = container_of(w, struct imx_port, tsk_dma_tx);
+	struct circ_buf *xmit = &sport->port.state->xmit;
+	struct scatterlist *sgl = sport->tx_sgl;
+	struct dma_async_tx_descriptor *desc;
+	struct dma_chan	*chan = sport->dma_chan_tx;
+	struct device *dev = sport->port.dev;
+	enum dma_status status;
+	unsigned long flags;
+	int ret;
+
+	status = chan->device->device_tx_status(chan, (dma_cookie_t)0, NULL);
+	if (DMA_IN_PROGRESS == status)
+		return;
+
+	spin_lock_irqsave(&sport->port.lock, flags);
+	sport->tx_bytes = uart_circ_chars_pending(xmit);
+	if (sport->tx_bytes == 0) {
+		spin_unlock_irqrestore(&sport->port.lock, flags);
+		return;
+	}
+
+	if (xmit->tail > xmit->head) {
+		sport->dma_tx_nents = 2;
+		sg_init_table(sgl, 2);
+		sg_set_buf(sgl, xmit->buf + xmit->tail,
+				UART_XMIT_SIZE - xmit->tail);
+		sg_set_buf(sgl + 1, xmit->buf, xmit->head);
+	} else {
+		sport->dma_tx_nents = 1;
+		sg_init_one(sgl, xmit->buf + xmit->tail, sport->tx_bytes);
+	}
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+
+	ret = dma_map_sg(dev, sgl, sport->dma_tx_nents, DMA_TO_DEVICE);
+	if (ret == 0) {
+		dev_err(dev, "DMA mapping error for TX.\n");
+		return;
+	}
+	desc = dmaengine_prep_slave_sg(chan, sgl, sport->dma_tx_nents,
+					DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT);
+	if (!desc) {
+		dev_err(dev, "We cannot prepare for the TX slave dma!\n");
+		return;
+	}
+	desc->callback = dma_tx_callback;
+	desc->callback_param = sport;
+
+	sport->dma_is_txing = 1;
+
+	dev_dbg(dev, "TX: prepare to send %lu bytes by DMA.\n",
+			uart_circ_chars_pending(xmit));
+	/* fire it */
+	dmaengine_submit(desc);
+	dma_async_issue_pending(chan);
+	return;
+}
+
 /*
  * interrupts disabled on entry
  */
@@ -473,8 +595,10 @@ static void imx_start_tx(struct uart_port *port)
 	temp |= UCR4_OREN;
 	writel(temp, sport->port.membase + UCR4);
 
-	temp = readl(sport->port.membase + UCR1);
-	writel(temp | UCR1_TXMPTYEN, sport->port.membase + UCR1);
+	if (!sport->dma_is_enabled) {
+		temp = readl(sport->port.membase + UCR1);
+		writel(temp | UCR1_TXMPTYEN, sport->port.membase + UCR1);
+	}
 
 	if (USE_IRDA(sport)) {
 		temp = readl(sport->port.membase + UCR1);
@@ -486,6 +610,15 @@ static void imx_start_tx(struct uart_port *port)
 		writel(temp, sport->port.membase + UCR4);
 	}
 
+	if (sport->dma_is_enabled) {
+		/*
+		 * We may in the interrupt context, so arise a work_struct to
+		 * do the real job.
+		 */
+		schedule_work(&sport->tsk_dma_tx);
+		return;
+	}
+
 	if (readl(sport->port.membase + uts_reg(sport)) & UTS_TXEMPTY)
 		imx_transmit_buffer(sport);
 }
@@ -601,6 +734,28 @@ out:
 	return IRQ_HANDLED;
 }
 
+/*
+ * If the RXFIFO is filled with some data, and then we
+ * arise a DMA operation to receive them.
+ */
+static void imx_dma_rxint(struct imx_port *sport)
+{
+	unsigned long temp;
+
+	temp = readl(sport->port.membase + USR2);
+	if ((temp & USR2_RDR) && !sport->dma_is_rxing) {
+		sport->dma_is_rxing = 1;
+
+		/* disable the `Recerver Ready Interrrupt` */
+		temp = readl(sport->port.membase + UCR1);
+		temp &= ~(UCR1_RRDYEN);
+		writel(temp, sport->port.membase + UCR1);
+
+		/* tell the DMA to receive the data. */
+		schedule_work(&sport->tsk_dma_rx);
+	}
+}
+
 static irqreturn_t imx_int(int irq, void *dev_id)
 {
 	struct imx_port *sport = dev_id;
@@ -609,8 +764,12 @@ static irqreturn_t imx_int(int irq, void *dev_id)
 
 	sts = readl(sport->port.membase + USR1);
 
-	if (sts & USR1_RRDY)
-		imx_rxint(irq, dev_id);
+	if (sts & USR1_RRDY) {
+		if (sport->dma_is_enabled)
+			imx_dma_rxint(sport);
+		else
+			imx_rxint(irq, dev_id);
+	}
 
 	if (sts & USR1_TRDY &&
 			readl(sport->port.membase + UCR1) & UCR1_TXMPTYEN)
@@ -667,7 +826,8 @@ static void imx_set_mctrl(struct uart_port *port, unsigned int mctrl)
 	temp = readl(sport->port.membase + UCR2) & ~UCR2_CTS;
 
 	if (mctrl & TIOCM_RTS)
-		temp |= UCR2_CTS;
+		if (!sport->dma_is_enabled)
+			temp |= UCR2_CTS;
 
 	writel(temp, sport->port.membase + UCR2);
 }
@@ -706,6 +866,226 @@ static int imx_setup_ufcr(struct imx_port *sport, unsigned int mode)
 	return 0;
 }
 
+#define RX_BUF_SIZE	(PAGE_SIZE)
+static int start_rx_dma(struct imx_port *sport);
+static void dma_rx_work(struct work_struct *w)
+{
+	struct imx_port *sport = container_of(w, struct imx_port, tsk_dma_rx);
+	struct tty_port *port = &sport->port.state->port;
+
+	if (sport->rx_bytes) {
+		tty_insert_flip_string(port, sport->rx_buf, sport->rx_bytes);
+		tty_flip_buffer_push(port);
+		sport->rx_bytes = 0;
+	}
+
+	if (sport->dma_is_rxing)
+		start_rx_dma(sport);
+}
+
+static void imx_rx_dma_done(struct imx_port *sport)
+{
+	unsigned long temp;
+
+	/* Enable this interrupt when the RXFIFO is empty. */
+	temp = readl(sport->port.membase + UCR1);
+	temp |= UCR1_RRDYEN;
+	writel(temp, sport->port.membase + UCR1);
+
+	sport->dma_is_rxing = 0;
+
+	/* Is the shutdown waiting for us? */
+	if (waitqueue_active(&sport->dma_wait))
+		wake_up(&sport->dma_wait);
+}
+
+/*
+ * There are three kinds of RX DMA interrupts(such as in the MX6Q):
+ *   [1] the RX DMA buffer is full.
+ *   [2] the Aging timer expires(wait for 8 bytes long)
+ *   [3] the Idle Condition Detect(enabled the UCR4_IDDMAEN).
+ *
+ * The [2] is trigger when a character was been sitting in the FIFO
+ * meanwhile [3] can wait for 32 bytes long when the RX line is
+ * on IDLE state and RxFIFO is empty.
+ */
+static void dma_rx_callback(void *data)
+{
+	struct imx_port *sport = data;
+	struct dma_chan	*chan = sport->dma_chan_rx;
+	unsigned int count;
+	struct tty_struct *tty;
+	struct scatterlist *sgl;
+	struct dma_tx_state state;
+	enum dma_status status;
+
+	tty = sport->port.state->port.tty;
+	sgl = &sport->rx_sgl;
+
+	/* unmap it first */
+	dma_unmap_sg(sport->port.dev, sgl, 1, DMA_FROM_DEVICE);
+
+	status = chan->device->device_tx_status(chan, (dma_cookie_t)0, &state);
+	count = RX_BUF_SIZE - state.residue;
+	dev_dbg(sport->port.dev, "We get %d bytes.\n", count);
+
+	if (count) {
+		sport->rx_bytes = count;
+		schedule_work(&sport->tsk_dma_rx);
+	} else
+		imx_rx_dma_done(sport);
+}
+
+static int start_rx_dma(struct imx_port *sport)
+{
+	struct scatterlist *sgl = &sport->rx_sgl;
+	struct dma_chan	*chan = sport->dma_chan_rx;
+	struct device *dev = sport->port.dev;
+	struct dma_async_tx_descriptor *desc;
+	int ret;
+
+	sg_init_one(sgl, sport->rx_buf, RX_BUF_SIZE);
+	ret = dma_map_sg(dev, sgl, 1, DMA_FROM_DEVICE);
+	if (ret == 0) {
+		dev_err(dev, "DMA mapping error for RX.\n");
+		return -EINVAL;
+	}
+	desc = dmaengine_prep_slave_sg(chan, sgl, 1, DMA_DEV_TO_MEM,
+					DMA_PREP_INTERRUPT);
+	if (!desc) {
+		dev_err(dev, "We cannot prepare for the RX slave dma!\n");
+		return -EINVAL;
+	}
+	desc->callback = dma_rx_callback;
+	desc->callback_param = sport;
+
+	dev_dbg(dev, "RX: prepare for the DMA.\n");
+	dmaengine_submit(desc);
+	dma_async_issue_pending(chan);
+	return 0;
+}
+
+static void imx_uart_dma_exit(struct imx_port *sport)
+{
+	if (sport->dma_chan_rx) {
+		dma_release_channel(sport->dma_chan_rx);
+		sport->dma_chan_rx = NULL;
+
+		kfree(sport->rx_buf);
+		sport->rx_buf = NULL;
+	}
+
+	if (sport->dma_chan_tx) {
+		dma_release_channel(sport->dma_chan_tx);
+		sport->dma_chan_tx = NULL;
+	}
+}
+
+static int imx_uart_dma_init(struct imx_port *sport)
+{
+	struct dma_slave_config slave_config;
+	struct device *dev = sport->port.dev;
+	int ret;
+
+	/* Prepare for RX : */
+	sport->dma_chan_rx = dma_request_slave_channel(dev, "rx");
+	if (!sport->dma_chan_rx) {
+		dev_err(dev, "cannot get the DMA channel.\n");
+		ret = -EINVAL;
+		goto err;
+	}
+
+	slave_config.direction = DMA_DEV_TO_MEM;
+	slave_config.src_addr = sport->port.mapbase + URXD0;
+	slave_config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	slave_config.src_maxburst = RXTL;
+	ret = dmaengine_slave_config(sport->dma_chan_rx, &slave_config);
+	if (ret) {
+		dev_err(dev, "error in RX dma configuration.\n");
+		goto err;
+	}
+
+	sport->rx_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
+	if (!sport->rx_buf) {
+		dev_err(dev, "cannot alloc DMA buffer.\n");
+		ret = -ENOMEM;
+		goto err;
+	}
+	sport->rx_bytes = 0;
+
+	/* Prepare for TX : */
+	sport->dma_chan_tx = dma_request_slave_channel(dev, "tx");
+	if (!sport->dma_chan_tx) {
+		dev_err(dev, "cannot get the TX DMA channel!\n");
+		ret = -EINVAL;
+		goto err;
+	}
+
+	slave_config.direction = DMA_MEM_TO_DEV;
+	slave_config.dst_addr = sport->port.mapbase + URTX0;
+	slave_config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	slave_config.dst_maxburst = TXTL;
+	ret = dmaengine_slave_config(sport->dma_chan_tx, &slave_config);
+	if (ret) {
+		dev_err(dev, "error in TX dma configuration.");
+		goto err;
+	}
+
+	return 0;
+err:
+	imx_uart_dma_exit(sport);
+	return ret;
+}
+
+static void imx_enable_dma(struct imx_port *sport)
+{
+	unsigned long temp;
+	struct tty_port *port = &sport->port.state->port;
+
+	port->low_latency = 1;
+	INIT_WORK(&sport->tsk_dma_tx, dma_tx_work);
+	INIT_WORK(&sport->tsk_dma_rx, dma_rx_work);
+	init_waitqueue_head(&sport->dma_wait);
+
+	/* set UCR1 */
+	temp = readl(sport->port.membase + UCR1);
+	temp |= UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN |
+		/* wait for 4 idle frames and enable AGING Timer */
+		UCR1_ICD_REG(0);
+	writel(temp, sport->port.membase + UCR1);
+
+	/* set UCR4 */
+	temp = readl(sport->port.membase + UCR4);
+	temp |= UCR4_IDDMAEN;
+	writel(temp, sport->port.membase + UCR4);
+}
+
+static void imx_disable_dma(struct imx_port *sport)
+{
+	unsigned long temp;
+	struct tty_port *port = &sport->port.state->port;
+
+	/* clear UCR1 */
+	temp = readl(sport->port.membase + UCR1);
+	temp &= ~(UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN);
+	writel(temp, sport->port.membase + UCR1);
+
+	/* clear UCR2 */
+	temp = readl(sport->port.membase + UCR2);
+	temp &= ~(UCR2_CTSC | UCR2_CTS);
+	writel(temp, sport->port.membase + UCR2);
+
+	/* clear UCR4 */
+	temp = readl(sport->port.membase + UCR4);
+	temp &= ~UCR4_IDDMAEN;
+	writel(temp, sport->port.membase + UCR4);
+
+	sport->dma_is_enabled = 0;
+	sport->dma_is_inited = 0;
+
+	port->low_latency = 0;
+}
+
 /* half the RX buffer size */
 #define CTSTL 16
 
@@ -870,6 +1250,14 @@ static void imx_shutdown(struct uart_port *port)
 	unsigned long temp;
 	unsigned long flags;
 
+	if (sport->dma_is_enabled) {
+		/* We have to wait for the DMA to finish. */
+		wait_event(sport->dma_wait,
+			!sport->dma_is_rxing && !sport->dma_is_txing);
+		imx_stop_rx(port);
+		imx_uart_dma_exit(sport);
+	}
+
 	spin_lock_irqsave(&sport->port.lock, flags);
 	temp = readl(sport->port.membase + UCR2);
 	temp &= ~(UCR2_TXEN);
@@ -910,6 +1298,10 @@ static void imx_shutdown(struct uart_port *port)
 		temp &= ~(UCR1_IREN);
 
 	writel(temp, sport->port.membase + UCR1);
+
+	if (sport->dma_is_enabled)
+		imx_disable_dma(sport);
+
 	spin_unlock_irqrestore(&sport->port.lock, flags);
 
 	clk_disable_unprepare(sport->clk_per);
@@ -956,6 +1348,13 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 		if (sport->have_rtscts) {
 			ucr2 &= ~UCR2_IRTS;
 			ucr2 |= UCR2_CTSC;
+
+			/* Can we enable the DMA support? */
+			if (is_imx6_uart(sport) && !uart_console(port)
+				&& !sport->dma_is_inited) {
+				if (!imx_uart_dma_init(sport))
+					sport->dma_is_inited = 1;
+			}
 		} else {
 			termios->c_cflag &= ~CRTSCTS;
 		}
@@ -1069,6 +1468,10 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 	if (UART_ENABLE_MS(&sport->port, termios->c_cflag))
 		imx_enable_ms(&sport->port);
 
+	if (sport->dma_is_inited && !sport->dma_is_enabled) {
+		imx_enable_dma(sport);
+		sport->dma_is_enabled = 1;
+	}
 	spin_unlock_irqrestore(&sport->port.lock, flags);
 }
 
-- 
1.7.1




From b32955 at freescale.com  Tue Jul  2 02:30:28 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 2 Jul 2013 14:30:28 +0800
Subject: [PATCH 5/5] ARM: dts: enable the uart2 for imx6q-arm2
In-Reply-To: <1372746628-20092-1-git-send-email-b32955@freescale.com>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
Message-ID: <1372746628-20092-6-git-send-email-b32955@freescale.com>

enable the uart2 for imx6q-arm2 board.
The uart2 works in the DTE mode, with the RTS/CTS and DMA enabled.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6q-arm2.dts |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-arm2.dts b/arch/arm/boot/dts/imx6q-arm2.dts
index 4e54fde..8beaa68 100644
--- a/arch/arm/boot/dts/imx6q-arm2.dts
+++ b/arch/arm/boot/dts/imx6q-arm2.dts
@@ -97,6 +97,16 @@
 	status = "okay";
 };
 
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2_dte>;
+	fsl,dte-mode;
+	fsl,uart-has-rtscts;
+	dma-names = "rx", "tx";
+	dmas = <&sdma 27 4 0>, <&sdma 28 4 0>;
+	status = "okay";
+};
+
 &uart4 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart4_1>;
-- 
1.7.1




From b32955 at freescale.com  Tue Jul  2 02:30:27 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 2 Jul 2013 14:30:27 +0800
Subject: [PATCH 4/5] ARM: dts: imx6: add dte pinctrl for uart2
In-Reply-To: <1372746628-20092-1-git-send-email-b32955@freescale.com>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
Message-ID: <1372746628-20092-5-git-send-email-b32955@freescale.com>

In arm2 board, the UART2 works in the dte mode.
So add a pinctrl for it.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6q.dtsi |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 9a69891..8a518c6 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -266,6 +266,15 @@
 							MX6Q_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
 						>;
 					};
+
+					pinctrl_uart2_dte: uart2grp-2 {
+						fsl,pins = <
+							MX6Q_PAD_EIM_D26__UART2_RX_DATA 0x1b0b1
+							MX6Q_PAD_EIM_D27__UART2_TX_DATA 0x1b0b1
+							MX6Q_PAD_EIM_D28__UART2_CTS_B	0x1b0b1
+							MX6Q_PAD_EIM_D29__UART2_CTS_B	0x1b0b1
+						>;
+					};
 				};
 
 				uart4 {
-- 
1.7.1




From jg1.han at samsung.com  Tue Jul  2 02:58:44 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Tue, 02 Jul 2013 15:58:44 +0900
Subject: [PATCH V3 2/3] phy: Add driver for Exynos DP PHY
In-Reply-To: <51D1DCF0.50803@gmail.com>
References: <005301ce761b$32adf960$9809ec20$@samsung.com>
 <51D1DCF0.50803@gmail.com>
Message-ID: <000001ce76f1$97e47210$c7ad5630$@samsung.com>

On Tuesday, July 02, 2013 4:48 AM, Sylwester Nawrocki wrote:
> On 07/01/2013 07:24 AM, Jingoo Han wrote:
> > Add a PHY provider driver for the Samsung Exynos SoC DP PHY.
> >
> > Signed-off-by: Jingoo Han<jg1.han at samsung.com>
> > Cc: Sylwester Nawrocki<s.nawrocki at samsung.com>
> > Acked-by: Felipe Balbi<balbi at ti.com>
> > ---
> >   .../devicetree/bindings/phy/samsung-phy.txt        |    8 ++
> >   drivers/phy/Kconfig                                |    5 +
> >   drivers/phy/Makefile                               |    1 +
> >   drivers/phy/phy-exynos-dp-video.c                  |  118 ++++++++++++++++++++
> >   4 files changed, 132 insertions(+)
> >   create mode 100644 drivers/phy/phy-exynos-dp-video.c
> >
> > diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> > index 5ff208c..3fb656a 100644
> > --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> > +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> > @@ -12,3 +12,11 @@ the PHY specifier identifies the PHY and its meaning is as follows:
> >     1 - MIPI DSIM 0,
> >     2 - MIPI CSIS 1,
> >     3 - MIPI DSIM 1.
> > +
> > +Samsung EXYNOS SoC series DP PHY
> 
> I would make it "Samsung EXYNOS SoC series Display Port PHY"

OK.

> 
> > +-------------------------------------------------
> > +
> > +Required properties:
> > +- compatible : should be "samsung,exynos5250-dp-video-phy";
> > +- reg : offset and length of the DP PHY register set;
> > +- #phy-cells : from the generic phy bindings, must be 0;
> 
> s/phy/PHY ?

OK.

> 
> > \ No newline at end of file
> 
> Missing new line character.

OK.

> 
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > index 6f446d0..760f55a 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -19,4 +19,9 @@ config PHY_EXYNOS_MIPI_VIDEO
> >   	help
> >   	  Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
> >   	  S5P and EXYNOS SoCs.
> > +
> > +config PHY_EXYNOS_DP_VIDEO
> > +	tristate "EXYNOS SoC series DP PHY driver"
> 
> "EXYNOS SoC series Display Port PHY driver" ?
> 
> > +	help
> > +	  Support for DP PHY found on Samsung EXYNOS SoCs.
> 
> s/DP/Display Port ?

OK.

> 
> >   endif
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> > index 71d8841..0fd1340 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -4,3 +4,4 @@
> >
> >   obj-$(CONFIG_GENERIC_PHY)		+= phy-core.o
> >   obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)	+= phy-exynos-mipi-video.o
> > +obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)	+= phy-exynos-dp-video.o
> > diff --git a/drivers/phy/phy-exynos-dp-video.c b/drivers/phy/phy-exynos-dp-video.c
> > new file mode 100644
> > index 0000000..75e1d11
> > --- /dev/null
> > +++ b/drivers/phy/phy-exynos-dp-video.c
> > @@ -0,0 +1,118 @@
> > +/*
> > + * Samsung EXYNOS SoC series DP PHY driver
> 
> s/DP/Display Port ?

OK.

> 
> > + *
> > + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> > + * Author: Jingoo Han<jg1.han at samsung.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include<linux/io.h>
> > +#include<linux/kernel.h>
> > +#include<linux/module.h>
> > +#include<linux/of.h>
> > +#include<linux/of_address.h>
> > +#include<linux/phy/phy.h>
> > +#include<linux/platform_device.h>
> > +
> > +/* DPTX_PHY_CONTROL register */
> > +#define EXYNOS_DPTX_PHY_ENABLE		(1<<  0)
> > +
> > +struct exynos_dp_video_phy {
> > +	void __iomem *regs;
> > +};
> > +
> > +static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int on)
> > +{
> > +	void __iomem *addr;
> 
> How about just dropping this local variable ?

OK.
I will drop this local variable.

> 
> > +	u32 reg;
> > +
> > +	addr = state->regs;
> > +
> > +	reg = readl(addr);
> > +	if (on)
> > +		reg |= EXYNOS_DPTX_PHY_ENABLE;
> > +	else
> > +		reg&= ~EXYNOS_DPTX_PHY_ENABLE;
> > +	writel(reg, addr);
> > +
> > +	return 0;
> > +}
> > +
> > +static int exynos_dp_video_phy_power_on(struct phy *phy)
> > +{
> > +	struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
> > +
> > +	return __set_phy_state(state, 1);
> > +}
> > +
> > +static int exynos_dp_video_phy_power_off(struct phy *phy)
> > +{
> > +	struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
> > +
> > +	return __set_phy_state(state, 0);
> > +}
> > +
> > +static struct phy_ops exynos_dp_video_phy_ops = {
> > +	.power_on	= exynos_dp_video_phy_power_on,
> > +	.power_off	= exynos_dp_video_phy_power_off,
> > +	.owner		= THIS_MODULE,
> > +};
> > +
> > +static int exynos_dp_video_phy_probe(struct platform_device *pdev)
> > +{
> > +	struct exynos_dp_video_phy *state;
> > +	struct device *dev =&pdev->dev;
> > +	struct resource *res;
> > +	struct phy_provider *phy_provider;
> > +	struct phy *phy;
> > +
> > +	state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
> > +	if (!state)
> > +		return -ENOMEM;
> > +
> > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +
> > +	state->regs = devm_ioremap_resource(dev, res);
> > +	if (IS_ERR(state->regs))
> > +		return PTR_ERR(state->regs);
> > +
> > +	dev_set_drvdata(dev, state);
> 
> I can't see any corresponding dev_get_drvdata(), it should be safe
> to remove this assignment.

OK.
I will remove 'dev_set_drvdata(dev, state)'.

> 
> > +	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> > +	if (IS_ERR(phy_provider))
> > +		return PTR_ERR(phy_provider);
> > +
> > +	phy = devm_phy_create(dev, 0,&exynos_dp_video_phy_ops, "dp");
> 
> The label could be NULL, since there is no need to support non-dt config.

OK.
I will replace "dp" with NULL.

> 
> > +	if (IS_ERR(phy)) {
> > +		dev_err(dev, "failed to create DP PHY\n");
> > +		return PTR_ERR(phy);
> > +	}
> > +	phy_set_drvdata(phy, state);
> > +
> > +	return 0;
> > +}
> > +
> > +#ifdef CONFIG_OF
> 
> You don't use of_match_ptr() macro to assign of_match_table to the driver
> structure below. This means build with CONFIG_OF disabled is broken now.
> I would just remove that #ifdef and would make the driver depends on
> CONFIG_OF.

OK.
I will add 'depends on OF', then remove '#ifdef CONFIG_OF'.

Thank you for your detailed comment. :)

Best regards,
Jingoo Han

> 
> > +static const struct of_device_id exynos_dp_video_phy_of_match[] = {
> > +	{ .compatible = "samsung,exynos5250-dp-video-phy" },
> > +	{ },
> > +};
> > +MODULE_DEVICE_TABLE(of, exynos_dp_video_phy_of_match);
> > +#endif
> > +
> > +static struct platform_driver exynos_dp_video_phy_driver = {
> > +	.probe	= exynos_dp_video_phy_probe,
> > +	.driver = {
> > +		.name	= "exynos-dp-video-phy",
> > +		.owner	= THIS_MODULE,
> > +		.of_match_table	= exynos_dp_video_phy_of_match,
> > +	}
> > +};
> > +module_platform_driver(exynos_dp_video_phy_driver);
> > +
> > +MODULE_AUTHOR("Jingoo Han<jg1.han at samsung.com>");
> > +MODULE_DESCRIPTION("Samsung EXYNOS SoC DP PHY driver");
> > +MODULE_LICENSE("GPL v2");
> 
> Thanks,
> Sylwester



From jg1.han at samsung.com  Tue Jul  2 03:05:49 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Tue, 02 Jul 2013 16:05:49 +0900
Subject: [PATCH V3 3/3] video: exynos_dp: Use the generic PHY driver
In-Reply-To: <51D1DA07.3010803@gmail.com>
References: <005401ce761b$504d7090$f0e851b0$@samsung.com>
 <51D1DA07.3010803@gmail.com>
Message-ID: <000101ce76f2$94df04d0$be9d0e70$@samsung.com>

On Tuesday, July 02, 2013 4:36 AM, Sylwester Nawrocki wrote:
> 
> Hi Jingoo,
> 
> On 07/01/2013 07:24 AM, Jingoo Han wrote:
> > Use the generic PHY API instead of the platform callback to control
> > the DP PHY. The 'phy_label' field is added to the platform data
> > structure to allow PHY lookup on non-dt platforms.
> 
> Since Exynos is currently a dt-only platform upstream, how about
> first making a pre-requisite patch that would remove support for
> non-dt platforms from this driver ? I think you could now move the
> content of file include/video/exynos_dp.h to e.g. drivers/video/
> exynos/exynos_dp_core.h and remove the public exynos_dp.h file.
> pdata->phy_init/exit could also be dropped and you wouldn't need
> to care about non-dt support with the generic PHY API.

Yes, you're right.

I will make the pre-requisite patch that would remove support for
non-dt platforms from exynos_dp_core.c.
Then, I will move the content of file include/video/exynos_dp.h
and remove 'exynos_dp.h' file.

> 
> > Signed-off-by: Jingoo Han<jg1.han at samsung.com>
> > Acked-by: Felipe Balbi<balbi at ti.com>
> > ---
> >   .../devicetree/bindings/video/exynos_dp.txt        |   23 +---
> >   drivers/video/exynos/exynos_dp_core.c              |  118 ++------------------
> >   drivers/video/exynos/exynos_dp_core.h              |    2 +
> >   include/video/exynos_dp.h                          |    6 +-
> >   4 files changed, 21 insertions(+), 128 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
> b/Documentation/devicetree/bindings/video/exynos_dp.txt
> > index 84f10c1..71645dc 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> > @@ -1,17 +1,6 @@
> >   The Exynos display port interface should be configured based on
> >   the type of panel connected to it.
> >
> > -We use two nodes:
> > -	-dp-controller node
> > -	-dptx-phy node(defined inside dp-controller node)
> > -
> > -For the DP-PHY initialization, we use the dptx-phy node.
> > -Required properties for dptx-phy:
> > -	-reg:
> > -		Base address of DP PHY register.
> > -	-samsung,enable-mask:
> > -		The bit-mask used to enable/disable DP PHY.
> > -
> >   For the Panel initialization, we read data from dp-controller node.
> >   Required properties for dp-controller:
> >   	-compatible:
> > @@ -25,6 +14,10 @@ Required properties for dp-controller:
> >   		from common clock binding: handle to dp clock.
> >   	-clock-names:
> >   		from common clock binding: Shall be "dp".
> > +	-phys:
> > +		from general phy binding: the phandle for the PHY device.
> > +	-phy-names:
> > +		from general phy binding: Should be "dp".
> >   	-interrupt-parent:
> >   		phandle to Interrupt combiner node.
> >   	-samsung,color-space:
> > @@ -67,12 +60,8 @@ SOC specific portion:
> >   		interrupt-parent =<&combiner>;
> >   		clocks =<&clock 342>;
> >   		clock-names = "dp";
> > -
> > -		dptx-phy {
> > -			reg =<0x10040720>;
> > -			samsung,enable-mask =<1>;
> > -		};
> > -
> > +		phys =<&dp_phy>;
> > +		phy-names = "dp";
> >   	};
> >
> >   Board Specific portion:
> > diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> > index 12bbede..bac515b 100644
> > --- a/drivers/video/exynos/exynos_dp_core.c
> > +++ b/drivers/video/exynos/exynos_dp_core.c
> > @@ -19,6 +19,7 @@
> >   #include<linux/interrupt.h>
> >   #include<linux/delay.h>
> >   #include<linux/of.h>
> > +#include<linux/phy/phy.h>
> >
> >   #include<video/exynos_dp.h>
> >
> > @@ -960,84 +961,15 @@ static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
> >   		return ERR_PTR(-EINVAL);
> >   	}
> >
> > -	return pd;
> > -}
> > -
> > -static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
> > -{
> > -	struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
> > -	u32 phy_base;
> > -	int ret = 0;
> > -
> > -	dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
> > -	if (!dp_phy_node) {
> > -		dev_err(dp->dev, "could not find dptx-phy node\n");
> > -		return -ENODEV;
> > -	}
> > -
> > -	if (of_property_read_u32(dp_phy_node, "reg",&phy_base)) {
> > -		dev_err(dp->dev, "failed to get reg for dptx-phy\n");
> > -		ret = -EINVAL;
> > -		goto err;
> > -	}
> > -
> > -	if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
> > -				&dp->enable_mask)) {
> > -		dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
> > -		ret = -EINVAL;
> > -		goto err;
> > -	}
> > -
> > -	dp->phy_addr = ioremap(phy_base, SZ_4);
> > -	if (!dp->phy_addr) {
> > -		dev_err(dp->dev, "failed to ioremap dp-phy\n");
> > -		ret = -ENOMEM;
> > -		goto err;
> > -	}
> > -
> > -err:
> > -	of_node_put(dp_phy_node);
> > -
> > -	return ret;
> > -}
> > -
> > -static void exynos_dp_phy_init(struct exynos_dp_device *dp)
> > -{
> > -	u32 reg;
> > -
> > -	reg = __raw_readl(dp->phy_addr);
> > -	reg |= dp->enable_mask;
> > -	__raw_writel(reg, dp->phy_addr);
> > -}
> > -
> > -static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
> > -{
> > -	u32 reg;
> > +	pd->phy_label = "dp";
> >
> > -	reg = __raw_readl(dp->phy_addr);
> > -	reg&= ~(dp->enable_mask);
> > -	__raw_writel(reg, dp->phy_addr);
> > +	return pd;
> >   }
> 
> I'm afraid you cannot simply remove the above code, the original binding
> still needs to be supported. As far as I can see Arndale and smdk5250 are
> already users of that binding in mainline now.
> 
> Thus the benefits of adding the generic PHY support to this Display Port
> controller driver are starting to be a bit questionable.

OK.
I will keep supporting this original DT binding.

> 
> >   #else
> >   static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
> >   {
> >   	return NULL;
> >   }
> > -
> > -static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
> > -{
> > -	return -EINVAL;
> > -}
> > -
> > -static void exynos_dp_phy_init(struct exynos_dp_device *dp)
> > -{
> > -	return;
> > -}
> > -
> > -static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
> > -{
> > -	return;
> > -}
> >   #endif /* CONFIG_OF */
> 
> I think you could make the driver dependent on CONFIG_OF now and
> related #ifdefs and !CONFIG_OF function stubs could be removed.

OK.
I will add 'depends on OF', then remove '#ifdef CONFIG_OF'
as well as !CONFIG_OF function stubs.

> 
> >   static int exynos_dp_probe(struct platform_device *pdev)
> > @@ -1061,10 +993,6 @@ static int exynos_dp_probe(struct platform_device *pdev)
> >   		pdata = exynos_dp_dt_parse_pdata(&pdev->dev);
> >   		if (IS_ERR(pdata))
> >   			return PTR_ERR(pdata);
> > -
> > -		ret = exynos_dp_dt_parse_phydata(dp);
> > -		if (ret)
> > -			return ret;
> >   	} else {
> >   		pdata = pdev->dev.platform_data;
> >   		if (!pdata) {
> > @@ -1073,6 +1001,10 @@ static int exynos_dp_probe(struct platform_device *pdev)
> >   		}
> >   	}
> >
> > +	dp->phy = devm_phy_get(&pdev->dev, pdata->phy_label);
> > +	if (IS_ERR(dp->phy))
> > +		return PTR_ERR(dp->phy);
> > +
> >   	dp->clock = devm_clk_get(&pdev->dev, "dp");
> >   	if (IS_ERR(dp->clock)) {
> >   		dev_err(&pdev->dev, "failed to get clock\n");
> > @@ -1097,13 +1029,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
> >
> >   	dp->video_info = pdata->video_info;
> >
> > -	if (pdev->dev.of_node) {
> > -		if (dp->phy_addr)
> > -			exynos_dp_phy_init(dp);
> > -	} else {
> > -		if (pdata->phy_init)
> > -			pdata->phy_init();
> > -	}
> > +	phy_power_on(dp->phy);
> >
> >   	exynos_dp_init_dp(dp);
> >
> > @@ -1121,42 +1047,27 @@ static int exynos_dp_probe(struct platform_device *pdev)
> >
> >   static int exynos_dp_remove(struct platform_device *pdev)
> >   {
> > -	struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
> >   	struct exynos_dp_device *dp = platform_get_drvdata(pdev);
> >
> >   	flush_work(&dp->hotplug_work);
> >
> > -	if (pdev->dev.of_node) {
> > -		if (dp->phy_addr)
> > -			exynos_dp_phy_exit(dp);
> > -	} else {
> > -		if (pdata->phy_exit)
> > -			pdata->phy_exit();
> > -	}
> > +	phy_power_off(dp->phy);
> >
> >   	clk_disable_unprepare(dp->clock);
> >
> > -
> >   	return 0;
> >   }
> >
> >   #ifdef CONFIG_PM_SLEEP
> >   static int exynos_dp_suspend(struct device *dev)
> >   {
> > -	struct exynos_dp_platdata *pdata = dev->platform_data;
> >   	struct exynos_dp_device *dp = dev_get_drvdata(dev);
> >
> >   	disable_irq(dp->irq);
> >
> >   	flush_work(&dp->hotplug_work);
> >
> > -	if (dev->of_node) {
> > -		if (dp->phy_addr)
> > -			exynos_dp_phy_exit(dp);
> > -	} else {
> > -		if (pdata->phy_exit)
> > -			pdata->phy_exit();
> > -	}
> > +	phy_power_off(dp->phy);
> >
> >   	clk_disable_unprepare(dp->clock);
> >
> > @@ -1165,16 +1076,9 @@ static int exynos_dp_suspend(struct device *dev)
> >
> >   static int exynos_dp_resume(struct device *dev)
> >   {
> > -	struct exynos_dp_platdata *pdata = dev->platform_data;
> >   	struct exynos_dp_device *dp = dev_get_drvdata(dev);
> >
> > -	if (dev->of_node) {
> > -		if (dp->phy_addr)
> > -			exynos_dp_phy_init(dp);
> > -	} else {
> > -		if (pdata->phy_init)
> > -			pdata->phy_init();
> > -	}
> > +	phy_power_on(dp->phy);
> >
> >   	clk_prepare_enable(dp->clock);
> >
> > diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
> > index 6c567bbf..b3d0328 100644
> > --- a/drivers/video/exynos/exynos_dp_core.h
> > +++ b/drivers/video/exynos/exynos_dp_core.h
> > @@ -42,6 +42,8 @@ struct exynos_dp_device {
> >   	struct video_info	*video_info;
> >   	struct link_train	link_train;
> >   	struct work_struct	hotplug_work;
> > +
> > +	struct phy		*phy;
> >   };
> >
> >   /* exynos_dp_reg.c */
> > diff --git a/include/video/exynos_dp.h b/include/video/exynos_dp.h
> > index bd8cabd..f38c9af 100644
> > --- a/include/video/exynos_dp.h
> > +++ b/include/video/exynos_dp.h
> > @@ -122,10 +122,8 @@ struct video_info {
> >   };
> >
> >   struct exynos_dp_platdata {
> 
> Since Exynos doesn't support non-dt boot now this platform data structure
> is not used, is it ?

You're right.
It can be removed, if Exynos DP driver does not non-DT.

Best regards,
Jingoo Han

> 
> > -	struct video_info *video_info;
> > -
> > -	void (*phy_init)(void);
> > -	void (*phy_exit)(void);
> > +	struct video_info	*video_info;
> > +	const char		*phy_label;
> >   };
> >
> >   #endif /* _EXYNOS_DP_H */
> 
> Regards,
> Sylwester



From sebastian.hesselbarth at gmail.com  Tue Jul  2 03:21:14 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue, 02 Jul 2013 09:21:14 +0200
Subject: armada_drm clock selection - try 2
In-Reply-To: <CAMLZHHRrdazrJwujCWrfzo_fcudtd4GUgMEEN2YScOAZeZ-4vA@mail.gmail.com>
References: <20130701203009.633A8FAAD5@dev.laptop.org>
 <51D1F921.9050608@gmail.com>
 <CAMLZHHRrdazrJwujCWrfzo_fcudtd4GUgMEEN2YScOAZeZ-4vA@mail.gmail.com>
Message-ID: <51D27F6A.5000503@gmail.com>

On 07/02/13 03:57, Daniel Drake wrote:
> On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
> <sebastian.hesselbarth at gmail.com> wrote:
>> I prefer not to try to find the best clock (source) at all. Let the
>> user pass the clock name by e.g. platform_data (or DT) and just try to
>> get the requested pixclk or a integer multiple of it. You will never be
>> able to find the best clock for all use cases.
>>
>> Just figure out, if integer division is sufficient to get requested
>> pixclk and clk_set_rate otherwise. This may be useful for current mode
>> running at 148.5MHz (1080p50) and new mode at 74.25MHz (1080i50, 720p).
>
> I am not opposed to this approach, it is nice and simple, but as
> Russell points out we do additionally need to distinguish between
> clocks that are "ours" to play with, vs those that are shared with
> other devices. It would be a bad idea to try call clk_set_rate() on
> the AXI bus clock, for example, changing the clock for a whole bunch
> of other devices. This is what the is_dedicated flag is about. However
> such a flag could be easily added to the DT/platform data definition
> that you propose.

Daniel,

now I got the idea of .is_dedicated. At least for Dove, we could still
implement AXI bus clock as fixed-rate clock, so you cannot mess with it.
I am almost sure, it will hang Dove when you change it, as there are
some devices depending on it (and the correct rate of it). Moreover,
LCDCLK is dedicated to CRTC0/1 so AXICLK is the only clock not
dedicated to LCD controllers.

But I am fine with .is_dedicated - I just think we should not try to
find the best clock source but leave that decision to the user
(=developer, DTS author; not userspace user).

Sebastian


From dedekind1 at gmail.com  Tue Jul  2 03:30:21 2013
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 02 Jul 2013 10:30:21 +0300
Subject: linux-next: manual merge of the arm-soc tree with the l2-mtd tree
In-Reply-To: <CAOesGMgh=CLCrtohrNF59Sh40-weCorL1_yjFgFKr47qhVy+xg@mail.gmail.com>
References: <20130702152954.f25bbf51c1a79aa4437e22ee@canb.auug.org.au>
 <20980858CB6D3A4BAE95CA194937D5E73E9E3BF5@DBDE04.ent.ti.com>
 <CAOesGMgh=CLCrtohrNF59Sh40-weCorL1_yjFgFKr47qhVy+xg@mail.gmail.com>
Message-ID: <1372750221.9767.17.camel@sauron.fi.intel.com>

On Mon, 2013-07-01 at 23:00 -0700, Olof Johansson wrote:
> It was also applied today, after the merge window opened. Don't merge
> it for 3.11. Artem?

OK, dropping it.

-- 
Best Regards,
Artem Bityutskiy



From dedekind1 at gmail.com  Tue Jul  2 03:33:02 2013
From: dedekind1 at gmail.com (Artem Bityutskiy)
Date: Tue, 02 Jul 2013 10:33:02 +0300
Subject: linux-next: manual merge of the arm-soc tree with the l2-mtd tree
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73E9E3C27@DBDE04.ent.ti.com>
References: <20130702152954.f25bbf51c1a79aa4437e22ee@canb.auug.org.au>
 <20980858CB6D3A4BAE95CA194937D5E73E9E3BF5@DBDE04.ent.ti.com>
 <CAOesGMgh=CLCrtohrNF59Sh40-weCorL1_yjFgFKr47qhVy+xg@mail.gmail.com>
 <20980858CB6D3A4BAE95CA194937D5E73E9E3C27@DBDE04.ent.ti.com>
Message-ID: <1372750382.9767.19.camel@sauron.fi.intel.com>

On Tue, 2013-07-02 at 06:18 +0000, Gupta, Pekon wrote:
> You may drop this patch if you wish so, but its not correct to say that this
> was not reviewed. Following are comments from "Arnd Bergmann"
> http://lists.infradead.org/pipermail/linux-mtd/2013-May/047030.html
> And follow-up reasoning..
> http://lists.infradead.org/pipermail/linux-mtd/2013-May/047032.html

Pekon, let me drop these 3 patches so far anyway. Please, re-submit it
with CC to the devicetree-discuss mailing list. Thanks!

-- 
Best Regards,
Artem Bityutskiy



From magnus.damm at gmail.com  Tue Jul  2 03:41:01 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 2 Jul 2013 16:41:01 +0900
Subject: [PATCH v2 0/2] ARM: shmobile: lager: Add DT reference
In-Reply-To: <1372645120-27256-1-git-send-email-horms+renesas@verge.net.au>
References: <1372645120-27256-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <CANqRtoSk2+mgkzOWZMsyDbJKYCS+Pp2cXMu4=SvO35EQ9sKtig@mail.gmail.com>

Hi Simon,

On Mon, Jul 1, 2013 at 11:18 AM, Simon Horman
<horms+renesas at verge.net.au> wrote:
> Hi,
>
> this short series adds DT reference to Lager.

Thanks for your work on this.

> The intention of this is to allow the board to be
> brought up as much as possible using DT. And for
> this to act as a basis for further DT coverage
> of devices present on the Lager and its r8a7790 SoC.
>
>
> This series differs from v2 in that it has been
> rebased on top of reneas-next-20130701 and now makes use
> of r8a7790_init_delay().
>
>
> Simon Horman (2):
>   ARM: shmobile: r8a7790:  Initialise clocks and SCIF in
>     r8a7790_add_dt_devices()

At this point I'm inclined to say "no" to new DT reference using
platform devices for SCIF. I believe we instead should really work on
adding DT support to the SCIF driver and use DT for SCIF on more
recent boards. Also, we probably don't want to enable clocks like
that, instead we should tie in common clocks. That will take a little
bit longer time though, so I wonder what is a good solution until
then..

>   ARM: shmobile: lager: Add DT reference

I think you want to update Makefile.boot to include the
lager-reference board. Also, I believe that without SCIF and clocks
the init_machine() and init_irq() callbacks can be left unset to make
use of the default behaviour.

Cheers,

/ magnus


From s.hauer at pengutronix.de  Tue Jul  2 04:03:27 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 2 Jul 2013 10:03:27 +0200
Subject: [PATCH 3/4] PCI: Add driver for i.MX6 PCI Express
In-Reply-To: <1372662947-27160-4-git-send-email-xobs@kosagi.com>
References: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
 <1372662947-27160-4-git-send-email-xobs@kosagi.com>
Message-ID: <20130702080327.GD516@pengutronix.de>

On Mon, Jul 01, 2013 at 07:15:46AM +0000, Sean Cross wrote:
> This adds a PCI Express port driver for the on-chip PCI Express port
> present on the i.MX6 SoC.  It is based on the PCI Express driver available
> in the Freescale BSP.
> 
> Signed-off-by: Sean Cross <xobs at kosagi.com>
> ---
>  .../devicetree/bindings/pci/imx6q-pcie.txt         |   20 +
>  arch/arm/mach-imx/Kconfig                          |    1 +
>  drivers/pci/pcie/Kconfig                           |   10 +
>  drivers/pci/pcie/Makefile                          |    2 +
>  drivers/pci/pcie/pcie-imx.c                        | 1049 ++++++++++++++++++++
>  5 files changed, 1082 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/imx6q-pcie.txt
>  create mode 100644 drivers/pci/pcie/pcie-imx.c
> 
> diff --git a/Documentation/devicetree/bindings/pci/imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/imx6q-pcie.txt
> new file mode 100644
> index 0000000..2dc9eae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/imx6q-pcie.txt
> @@ -0,0 +1,20 @@
> +* Freescale i.MX6Q PCI Express bridge
> +
> +Example (i.MX6Q)
> +	pcie: pcie at 01ffc000 {
> +		compatible = "fsl,imx6q-pcie";
> +		reg = <0x01ffc000 0x4000>,
> +		      <0x01000000 0x100000>,
> +		      <0x01100000 0xe00000>,
> +		      <0x01f00000 0xfc000>;
> +		interrupts = <0 122 0x04>;
> +		clocks = <&clks 186>, <&clks 189>, <&clks 196>,
> +			 <&clks 198>, <&clks 144>;
> +		clock-names = "sata_ref", "pcie_ref_125m", "lvds1_sel",
> +			      "lvds1", "pcie_axi";
> +		power-enable = <&gpio7 12 0>;
> +		pcie-reset = <&gpio3 29 0>;
> +		wake-up = <&gpio3 22 0>;
> +		disable-endpoint = <&gpio2 16 0>;
> +	};
> +
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index ba44328..cad4e5a 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -811,6 +811,7 @@ config SOC_IMX6Q
>  	select PL310_ERRATA_588369 if CACHE_PL310
>  	select PL310_ERRATA_727915 if CACHE_PL310
>  	select PL310_ERRATA_769419 if CACHE_PL310
> +	select MIGHT_HAVE_PCI
>  	select PM_OPP if PM
>  
>  	help
> diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
> index 569f82f..d1d70db 100644
> --- a/drivers/pci/pcie/Kconfig
> +++ b/drivers/pci/pcie/Kconfig
> @@ -83,3 +83,13 @@ endchoice
>  config PCIE_PME
>  	def_bool y
>  	depends on PCIEPORTBUS && PM_RUNTIME
> +
> +#
> +# Platform driver for i.MX6
> +#
> +config PCIE_IMX
> +        bool "Support for i.MX6"
> +        depends on SOC_IMX6Q
> +        help
> +          Enable support for the 1x PCI Express bus on the Freescale i.MX6
> +        depends on PCIEPORTBUS && PM_RUNTIME
> diff --git a/drivers/pci/pcie/Makefile b/drivers/pci/pcie/Makefile
> index 00c62df..5393d21 100644
> --- a/drivers/pci/pcie/Makefile
> +++ b/drivers/pci/pcie/Makefile
> @@ -14,3 +14,5 @@ obj-$(CONFIG_PCIEPORTBUS)	+= pcieportdrv.o
>  obj-$(CONFIG_PCIEAER)		+= aer/
>  
>  obj-$(CONFIG_PCIE_PME) += pme.o
> +
> +obj-$(CONFIG_PCIE_IMX)		+= pcie-imx.o
> diff --git a/drivers/pci/pcie/pcie-imx.c b/drivers/pci/pcie/pcie-imx.c
> new file mode 100644
> index 0000000..664679e
> --- /dev/null
> +++ b/drivers/pci/pcie/pcie-imx.c
> @@ -0,0 +1,1049 @@
> +/*
> + * drivers/pci/pcie/pcie-imx.c
> + *
> + * PCIe host controller driver for IMX6 SOCs
> + *
> + * Copyright (C) 2012 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * Code originally taken from Freescale linux-2.6.35 BSP.
> + *
> + * Other bits taken from arch/arm/mach-dove/pcie.c
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> +
> + * This 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.
> +
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/pci.h>
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/irq.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/gpio.h>
> +#include <linux/platform_device.h>
> +#include <linux/types.h>
> +#include <linux/of.h>
> +#include <linux/of_gpio.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/of_device.h>
> +#include <linux/clk-provider.h>
> +#include <linux/regmap.h>
> +#include <linux/rfkill.h>
> +
> +#include <asm/sizes.h>
> +#include <asm/io.h>
> +
> +
> +/* IOMUXC */
> +#define IOMUXC_GPR0                     (0x00)
> +#define IOMUXC_GPR1                     (0x04)
> +#define IOMUXC_GPR2                     (0x08)
> +#define IOMUXC_GPR3                     (0x0C)
> +#define IOMUXC_GPR4                     (0x10)
> +#define IOMUXC_GPR5                     (0x14)
> +#define IOMUXC_GPR6                     (0x18)
> +#define IOMUXC_GPR7                     (0x1C)
> +#define IOMUXC_GPR8                     (0x20)
> +#define IOMUXC_GPR9                     (0x24)
> +#define IOMUXC_GPR10                    (0x28)
> +#define IOMUXC_GPR11                    (0x2C)
> +#define IOMUXC_GPR12                    (0x30)
> +#define IOMUXC_GPR13                    (0x34)

These are already defined in include/linux/mfd/syscon/imx6q-iomuxc-gpr.h

> +
> +
> +/* Register Definitions */
> +#define PRT_LOG_R_BaseAddress 0x700
> +
> +/* Register DEBUG_R0 */
> +/* Debug Register 0 */
> +#define DEBUG_R0 (PRT_LOG_R_BaseAddress + 0x28)
> +#define DEBUG_R0_RegisterSize 32
> +#define DEBUG_R0_RegisterResetValue 0x0
> +#define DEBUG_R0_RegisterResetMask 0xFFFFFFFF
> +/* End of Register Definition for DEBUG_R0 */
> +
> +/* Register DEBUG_R1 */
> +/* Debug Register 1 */
> +#define DEBUG_R1 (PRT_LOG_R_BaseAddress + 0x2c)
> +#define DEBUG_R1_RegisterSize 32
> +#define DEBUG_R1_RegisterResetValue 0x0
> +#define DEBUG_R1_RegisterResetMask 0xFFFFFFFF
> +/* End of Register Definition for DEBUG_R1 */
> +
> +#define ATU_R_BaseAddress 0x900
> +#define PCIE_PL_iATUVR (ATU_R_BaseAddress + 0x0)
> +#define PCIE_PL_iATURC1 (ATU_R_BaseAddress + 0x4)
> +#define PCIE_PL_iATURC2 (ATU_R_BaseAddress + 0x8)
> +#define PCIE_PL_iATURLBA (ATU_R_BaseAddress + 0xC)
> +#define PCIE_PL_iATURUBA (ATU_R_BaseAddress + 0x10)
> +#define PCIE_PL_iATURLA (ATU_R_BaseAddress + 0x14)
> +#define PCIE_PL_iATURLTA (ATU_R_BaseAddress + 0x18)
> +#define PCIE_PL_iATURUTA (ATU_R_BaseAddress + 0x1C)

PleaseGetRidOfThisCamelCase.

> +
> +/* GPR1: iomuxc_gpr1_pcie_ref_clk_en(iomuxc_gpr1[16]) */
> +#define iomuxc_gpr1_pcie_ref_clk_en		(1 << 16)
> +/* GPR1: iomuxc_gpr1_test_powerdown(iomuxc_gpr1_18) */
> +#define iomuxc_gpr1_test_powerdown		(1 << 18)

Defines should use uppercase letters. Besides, we already have these in
include/linux/mfd/syscon/imx6q-iomuxc-gpr.h. If there's something
missing add them there not in your driver.

> +
> +/* GPR12: iomuxc_gpr12_los_level(iomuxc_gpr12[8:4]) */
> +#define iomuxc_gpr12_los_level			(0x1F << 4)
> +/* GPR12: iomuxc_gpr12_app_ltssm_enable(iomuxc_gpr12[10]) */
> +#define iomuxc_gpr12_app_ltssm_enable		(1 << 10)
> +/* GPR12: iomuxc_gpr12_device_type(iomuxc_gpr12[15:12]) */
> +#define iomuxc_gpr12_device_type		(0xF << 12)
> +
> +/* GPR8: iomuxc_gpr8_tx_deemph_gen1(iomuxc_gpr8[5:0]) */
> +#define iomuxc_gpr8_tx_deemph_gen1		(0x3F << 0)
> +/* GPR8: iomuxc_gpr8_tx_deemph_gen2_3p5db(iomuxc_gpr8[11:6]) */
> +#define iomuxc_gpr8_tx_deemph_gen2_3p5db	(0x3F << 6)
> +/* GPR8: iomuxc_gpr8_tx_deemph_gen2_6db(iomuxc_gpr8[17:12]) */
> +#define iomuxc_gpr8_tx_deemph_gen2_6db		(0x3F << 12)
> +/* GPR8: iomuxc_gpr8_tx_swing_full(iomuxc_gpr8[24:18]) */
> +#define iomuxc_gpr8_tx_swing_full		(0x7F << 18)
> +/* GPR8: iomuxc_gpr8_tx_swing_low(iomuxc_gpr8[31:25]) */
> +#define iomuxc_gpr8_tx_swing_low		(0x7F << 25)
> +
> +/* Registers of PHY */
> +/* Register PHY_STS_R */
> +/* PHY Status Register */
> +#define PHY_STS_R (PRT_LOG_R_BaseAddress + 0x110)
> +
> +/* Register PHY_CTRL_R */
> +/* PHY Control Register */
> +#define PHY_CTRL_R (PRT_LOG_R_BaseAddress + 0x114)
> +
> +#define SSP_CR_SUP_DIG_MPLL_OVRD_IN_LO 0x0011
> +/* FIELD: RES_ACK_IN_OVRD [15:15]
> +// FIELD: RES_ACK_IN [14:14]
> +// FIELD: RES_REQ_IN_OVRD [13:13]
> +// FIELD: RES_REQ_IN [12:12]
> +// FIELD: RTUNE_REQ_OVRD [11:11]
> +// FIELD: RTUNE_REQ [10:10]
> +// FIELD: MPLL_MULTIPLIER_OVRD [9:9]
> +// FIELD: MPLL_MULTIPLIER [8:2]
> +// FIELD: MPLL_EN_OVRD [1:1]
> +// FIELD: MPLL_EN [0:0]

If you would use defines instead of comments these would actually be
useful.

> +*/
> +
> +#define SSP_CR_SUP_DIG_ATEOVRD 0x0010
> +/* FIELD: ateovrd_en [2:2]
> +// FIELD: ref_usb2_en [1:1]
> +// FIELD: ref_clkdiv2 [0:0]
> +*/
> +
> +#define SSP_CR_LANE0_DIG_RX_OVRD_IN_LO 0x1005
> +/* FIELD: RX_LOS_EN_OVRD [13:13]
> +// FIELD: RX_LOS_EN [12:12]
> +// FIELD: RX_TERM_EN_OVRD [11:11]
> +// FIELD: RX_TERM_EN [10:10]
> +// FIELD: RX_BIT_SHIFT_OVRD [9:9]
> +// FIELD: RX_BIT_SHIFT [8:8]
> +// FIELD: RX_ALIGN_EN_OVRD [7:7]
> +// FIELD: RX_ALIGN_EN [6:6]
> +// FIELD: RX_DATA_EN_OVRD [5:5]
> +// FIELD: RX_DATA_EN [4:4]
> +// FIELD: RX_PLL_EN_OVRD [3:3]
> +// FIELD: RX_PLL_EN [2:2]
> +// FIELD: RX_INVERT_OVRD [1:1]
> +// FIELD: RX_INVERT [0:0]
> +*/
> +
> +#define SSP_CR_LANE0_DIG_RX_ASIC_OUT 0x100D
> +/* FIELD: LOS [2:2]
> +// FIELD: PLL_STATE [1:1]
> +// FIELD: VALID [0:0]
> +*/
> +
> +/* control bus bit definition */
> +#define PCIE_CR_CTL_DATA_LOC 0
> +#define PCIE_CR_CTL_CAP_ADR_LOC 16
> +#define PCIE_CR_CTL_CAP_DAT_LOC 17
> +#define PCIE_CR_CTL_WR_LOC 18
> +#define PCIE_CR_CTL_RD_LOC 19
> +#define PCIE_CR_STAT_DATA_LOC 0
> +#define PCIE_CR_STAT_ACK_LOC 16
> +
> +/* End of Register Definitions */
> +
> +#define  PCIE_CONF_BUS(b)		(((b) & 0xFF) << 16)
> +#define  PCIE_CONF_DEV(d)		(((d) & 0x1F) << 11)
> +#define  PCIE_CONF_FUNC(f)		(((f) & 0x7) << 8)
> +#define  PCIE_CONF_REG(r)		((r) & ~0x3)
> +
> +
> +/* Taken from PCI specs */
> +enum {
> +	MemRdWr = 0,
> +	MemRdLk = 1,
> +	IORdWr = 2,
> +	CfgRdWr0 = 4,
> +	CfgRdWr1 = 5
> +};
> +
> +
> +struct imx_pcie_port {
> +	struct device		*dev;
> +	u8			index;
> +	u8			root_bus_nr;
> +	int			interrupt;
> +
> +	struct resource		*dbi;
> +	struct resource		*io;
> +	struct resource 	*mem;
> +	struct resource 	*root;
> +
> +	struct regmap		*iomuxc_gpr;
> +
> +	void __iomem		*root_base;
> +	void __iomem		*dbi_base;
> +	void __iomem		*io_base;
> +	void __iomem		*mem_base;
> +	spinlock_t		conf_lock;
> +
> +	char			io_space_name[16];
> +	char			mem_space_name[16];
> +
> +	struct list_head	next;
> +
> +	struct clk		*lvds1_sel;
> +	struct clk		*lvds1;
> +	struct clk		*pcie_ref_125m;
> +	struct clk		*pcie_axi;
> +	struct clk		*sata_ref;
> +
> +        unsigned int		pcie_pwr_en;
> +        unsigned int		pcie_rst;
> +        unsigned int		pcie_wake_up;

Whitespace damage here.

> +
> +	struct rfkill		*rfkill;
> +};
> +
> +static const struct of_device_id pcie_of_match[] = {
> +	{
> +		.compatible	= "fsl,imx6q-pcie",
> +		.data		= NULL,

No need to set .data to NULL.

> +	},
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, pcie_of_match);
> +
> +static struct list_head pcie_port_list;
> +static struct hw_pci imx_pcie;
> +
> +static int pcie_phy_cr_read(void __iomem *dbi_base, int addr, int *data);
> +static int pcie_phy_cr_write(void __iomem *dbi_base, int addr, int data);
> +
> +
> +/* IMX PCIE GPR configure routines */
> +static void imx_pcie_clrset(struct imx_pcie_port *pp,
> +			    u32 mask, u32 val, u32 reg)
> +{
> +	u32 tmp;
> +	regmap_read(pp->iomuxc_gpr, reg, &tmp);
> +	tmp &= ~mask;
> +	tmp |= (val & mask);
> +	regmap_write(pp->iomuxc_gpr, reg, tmp);
> +}

This duplicates regmap_update_bits without the locking.

> +
> +static void change_field(int *in, int start, int end, int val)
> +{
> +	int mask;
> +	mask = ((0xFFFFFFFF << start) ^ (0xFFFFFFFF << (end + 1))) & 0xFFFFFFFF;
> +	*in = (*in & ~mask) | (val << start);
> +}
> +
> +
> +static struct imx_pcie_port *controller_to_port(int index)
> +{
> +	struct imx_pcie_port *pp;
> +
> +	if (index >= imx_pcie.nr_controllers) {
> +		pr_err("%d exceeded number of controllers %d\n",
> +			index, imx_pcie.nr_controllers);
> +		return NULL;
> +	}
> +
> +	list_for_each_entry(pp, &pcie_port_list, next) {
> +		if (pp->index == index)
> +			return pp;
> +	}
> +	return NULL;
> +}
> +
> +static struct imx_pcie_port *bus_to_port(int bus)
> +{
> +	int i;
> +	int rbus;
> +	struct imx_pcie_port *pp;
> +
> +	for (i = imx_pcie.nr_controllers - 1 ; i >= 0; i--) {
> +		pp = controller_to_port(i);
> +		rbus = pp->root_bus_nr;
> +		if (rbus != -1 && rbus <= bus)
> +			break;
> +	}
> +
> +	return i >= 0 ? pp : NULL;
> +}

There's certainly something wrong here if you have to iterate over lists
to find your own private data. struct pci_sys_data has a private_data
field exactly for this purpose.

> +
> +static int __init imx_pcie_setup(int nr, struct pci_sys_data *sys)
> +{
> +	struct imx_pcie_port *pp;
> +	int ret;
> +
> +	pp = controller_to_port(nr);
> +	if (!pp) {
> +		pr_err("unable to find port %d\n", nr);
> +		return 0;
> +	}
> +
> +	pp->root_bus_nr = sys->busnr;
> +
> +	/*
> +	 * IORESOURCE_MEM
> +	 */
> +	snprintf(pp->mem_space_name, sizeof(pp->mem_space_name),
> +			"PCIe %d MEM", pp->index);
> +
> +	pp->mem_space_name[sizeof(pp->mem_space_name) - 1] = 0;
> +	pp->mem->name = pp->mem_space_name;
> +	pp->mem->flags = IORESOURCE_MEM;
> +	ret = request_resource(&iomem_resource, pp->mem);
> +	if (ret)
> +		dev_err(pp->dev, "Request PCIe Memory resource failed\n");
> +	pci_add_resource_offset(&sys->resources, pp->mem, sys->mem_offset);
> +
> +
> +	snprintf(pp->io_space_name, sizeof(pp->io_space_name),
> +		 "PCIe %d I/O", pp->index);
> +	pp->io_space_name[sizeof(pp->io_space_name) - 1] = 0;
> +	pp->io->name = pp->io_space_name;
> +	pp->io->flags = IORESOURCE_IO;
> +
> +	ret = request_resource(&iomem_resource, pp->io);
> +	if (ret)
> +		dev_err(pp->dev, "Request PCIe IO resource failed\n");
> +	pci_add_resource_offset(&sys->resources, pp->io, sys->io_offset);
> +
> +	/*
> +	 * IORESOURCE_IO
> +	 */
> +	ret = pci_ioremap_io(PCIBIOS_MIN_IO, pp->io->start);
> +	if (ret)
> +		dev_err(pp->dev, "Request PCIe IO resource failed\n");
> +
> +	return 1;
> +}
> +
> +static int imx_pcie_link_up(struct platform_device *pdev)
> +{
> +	struct imx_pcie_port *pp = platform_get_drvdata(pdev);
> +	int iterations = 200;
> +	u32 rc, ltssm, rx_valid, temp;
> +
> +	rc = 0;
> +	for (iterations = 200; iterations > 0 && !rc; iterations--) {
> +		/* link is debug bit 36, debug register 1 starts at bit 32 */
> +		rc = readl(pp->dbi_base + DEBUG_R1) & (0x1 << (36 - 32)) ;
> +		usleep_range(2000, 3000);
> +
> +		/* From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
> +		 * Wait 2ms (LTSSM timeout is 24ms, PHY lock is ~5us in gen2).
> +		 * If (MAC/LTSSM.state == Recovery.RcvrLock)
> +		 * && (PHY/rx_valid==0) then pulse PHY/rx_reset. Transition
> +		 * to gen2 is stuck
> +		 */

Sorry, what? Do others understand what the problem is? Can we clarify
this?

> +		pcie_phy_cr_read(pp->dbi_base, SSP_CR_LANE0_DIG_RX_ASIC_OUT, &rx_valid);
> +		ltssm = readl(pp->dbi_base + DEBUG_R0) & 0x3F;
> +		if ((ltssm == 0x0D) && ((rx_valid & 0x01) == 0)) {
> +			dev_err(&pdev->dev,
> +				"transition to gen2 is stuck, reset PHY!\n");
> +			pcie_phy_cr_read(pp->dbi_base, SSP_CR_LANE0_DIG_RX_OVRD_IN_LO, &temp);
> +			change_field(&temp, 3, 3, 0x1);
> +			change_field(&temp, 5, 5, 0x1);

I wonder how complicated one can write temp |= (1 << 3) | (1 << 5).
Please get rid of this change_field function.

> +			pcie_phy_cr_write(pp->dbi_base, SSP_CR_LANE0_DIG_RX_OVRD_IN_LO,
> +					0x0028);
> +			usleep_range(2000, 3000);
> +			pcie_phy_cr_read(pp->dbi_base, SSP_CR_LANE0_DIG_RX_OVRD_IN_LO, &temp);
> +			change_field(&temp, 3, 3, 0x0);
> +			change_field(&temp, 5, 5, 0x0);
> +			pcie_phy_cr_write(pp->dbi_base, SSP_CR_LANE0_DIG_RX_OVRD_IN_LO,
> +					0x0000);
> +		}
> +
> +	}
> +
> +	if (!rc) {
> +		if (iterations <= 0) {
> +			dev_err(&pdev->dev,
> +				"link up failed, DEBUG_R0:0x%08x, DEBUG_R1:0x%08x  RX_VALID:0x%x!\n",
> +				readl(pp->dbi_base + DEBUG_R0),
> +				readl(pp->dbi_base + DEBUG_R1),
> +				rx_valid);
> +			return -ETIMEDOUT;
> +		}
> +		return -ENODEV;

I wonder under which circumstances you can reach this -ENODEV.

> +	}
> +
> +	return 0;
> +}
> +
> +static int imx_pcie_regions_setup(struct platform_device *pdev,
> +					struct imx_pcie_port *pp)
> +{
> +	void __iomem *dbi_base = pp->dbi_base;
> +	/*
> +	 * i.MX6 defines 16MB in the AXI address map for PCIe.
> +	 *
> +	 * That address space excepted the pcie registers is
> +	 * split and defined into different regions by iATU,
> +	 * with sizes and offsets as follows:
> +	 *
> +	 * 0x0100_0000 --- 0x010F_FFFF 1MB IORESOURCE_IO
> +	 * 0x0110_0000 --- 0x01EF_FFFF 14MB IORESOURCE_MEM
> +	 * 0x01F0_0000 --- 0x01FF_FFFF 1MB Cfg + Registers
> +	 */
> +
> +	/* CMD reg:I/O space, MEM space, and Bus Master Enable */
> +	writel(readl(dbi_base + PCI_COMMAND)
> +			| PCI_COMMAND_IO
> +			| PCI_COMMAND_MEMORY
> +			| PCI_COMMAND_MASTER,
> +			dbi_base + PCI_COMMAND);
> +
> +	/* Set the CLASS_REV of RC CFG header to PCI_CLASS_BRIDGE_PCI */
> +	writel(readl(dbi_base + PCI_CLASS_REVISION)
> +			| (PCI_CLASS_BRIDGE_PCI << 16),
> +			dbi_base + PCI_CLASS_REVISION);
> +
> +	/*
> +	 * region0 outbound used to access target cfg
> +	 */
> +	writel(0, dbi_base + PCIE_PL_iATUVR);
> +	writel(pp->root->start, dbi_base + PCIE_PL_iATURLBA);
> +	writel(pp->dbi->end, dbi_base + PCIE_PL_iATURLA);
> +	writel(0, dbi_base + PCIE_PL_iATURUBA);
> +
> +	writel(0, dbi_base + PCIE_PL_iATURLTA);
> +	writel(0, dbi_base + PCIE_PL_iATURUTA);
> +	writel(CfgRdWr0, dbi_base + PCIE_PL_iATURC1);
> +	writel((1<<31), dbi_base + PCIE_PL_iATURC2);
> +
> +	return 0;
> +}
> +
> +
> +static int imx_pcie_valid_config(struct imx_pcie_port *pp,
> +				struct pci_bus *bus, int devfn)
> +{
> +	if (bus->number >= 2)
> +		return 0;
> +
> +	if (devfn != 0)
> +		return 0;
> +
> +	return 1;
> +}
> +
> +
> +static u32 get_bus_address(struct imx_pcie_port *pp,
> +			   struct pci_bus *bus, u32 devfn, int where)
> +{
> +	u32 va_address;
> +	if (bus->number == 0) {
> +		va_address = (u32)pp->dbi_base + (where & ~0x3);
> +	}
> +	else {

The 'else' is supposed to be on the same line as the '}'

> +		va_address = (u32)pp->root_base +
> +					(PCIE_CONF_BUS(bus->number - 1) +
> +					PCIE_CONF_DEV(PCI_SLOT(devfn)) +
> +					PCIE_CONF_FUNC(PCI_FUNC(devfn)) +
> +					PCIE_CONF_REG(where));
> +	}
> +	return va_address;
> +}
> +
> +static int imx_pcie_read_config(struct pci_bus *bus, u32 devfn, int where,
> +			int size, u32 *val)
> +{
> +	struct imx_pcie_port *pp = bus_to_port(bus->number);
> +	u32 va_address;
> +
> +	if (!pp) {
> +		BUG();
> +		return -EINVAL;
> +	}
> +
> +	if (imx_pcie_valid_config(pp, bus, PCI_SLOT(devfn)) == 0) {
> +		*val = 0xffffffff;
> +		return PCIBIOS_DEVICE_NOT_FOUND;
> +	}
> +
> +	va_address = get_bus_address(pp, bus, devfn, where);
> +
> +	*val = readl((u32 *)va_address);
> +
> +	if (size == 1)
> +		*val = (*val >> (8 * (where & 3))) & 0xFF;
> +	else if (size == 2)
> +		*val = (*val >> (8 * (where & 3))) & 0xFFFF;
> +
> +	return PCIBIOS_SUCCESSFUL;
> +}
> +
> +static int imx_pcie_write_config(struct pci_bus *bus, u32 devfn,
> +			int where, int size, u32 val)
> +{
> +	struct imx_pcie_port *pp = bus_to_port(bus->number);
> +	u32 va_address = 0, mask = 0, tmp = 0;
> +	int ret = PCIBIOS_SUCCESSFUL;
> +
> +	if (!pp) {
> +		BUG();
> +		return -EINVAL;
> +	}
> +
> +	if (imx_pcie_valid_config(pp, bus, PCI_SLOT(devfn)) == 0)
> +		return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +	va_address = get_bus_address(pp, bus, devfn, where);
> +
> +	if (size == 4) {
> +		writel(val, (u32 *)va_address);
> +		goto exit;
> +	}
> +
> +	if (size == 2)
> +		mask = ~(0xFFFF << ((where & 0x3) * 8));
> +	else if (size == 1)
> +		mask = ~(0xFF << ((where & 0x3) * 8));
> +	else
> +		ret = PCIBIOS_BAD_REGISTER_NUMBER;
> +
> +	tmp = readl((u32 *)va_address) & mask;
> +	tmp |= val << ((where & 0x3) * 8);
> +	writel(tmp, (u32 *)va_address);
> +exit:
> +
> +	return ret;
> +}
> +
> +
> +
> +static struct pci_ops imx_pcie_ops = {
> +	.read = imx_pcie_read_config,
> +	.write = imx_pcie_write_config,
> +};
> +
> +static struct pci_bus __init *
> +imx_pcie_scan_bus(int nr, struct pci_sys_data *sys)
> +{
> +	struct imx_pcie_port *pp = controller_to_port(nr);
> +	if (nr > 1)
> +		return NULL;
> +        pp->root_bus_nr = sys->busnr;
> +
> +        return pci_scan_root_bus(NULL, sys->busnr, &imx_pcie_ops, sys,
> +                                 &sys->resources);

Whitespace damage here.

> +}
> +
> +static int __init imx_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
> +{
> +	struct imx_pcie_port *pp = controller_to_port(0);
> +	return pp->interrupt;
> +}
> +
> +static struct hw_pci imx_pci __initdata = {
> +	.nr_controllers	= 1,
> +	.setup		= imx_pcie_setup,
> +	.scan		= imx_pcie_scan_bus,
> +	.map_irq	= imx_pcie_map_irq,
> +};
> +
> +/* PHY CR bus acess routines */
> +static int pcie_phy_cr_ack_polling(void __iomem *dbi_base, int max_iterations, int exp_val)
> +{
> +	u32 temp_rd_data, wait_counter = 0;
> +
> +	do {
> +		temp_rd_data = readl(dbi_base + PHY_STS_R);
> +		temp_rd_data = (temp_rd_data >> PCIE_CR_STAT_ACK_LOC) & 0x1;
> +		wait_counter++;
> +	} while ((wait_counter < max_iterations) && (temp_rd_data != exp_val));
> +
> +	if (temp_rd_data != exp_val)
> +		return 0 ;
> +	return 1 ;
> +}
> +
> +static int pcie_phy_cr_cap_addr(void __iomem *dbi_base, int addr)
> +{
> +	u32 temp_wr_data;
> +
> +	/* write addr */
> +	temp_wr_data = addr << PCIE_CR_CTL_DATA_LOC ;
> +	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
> +
> +	/* capture addr */
> +	temp_wr_data |= (0x1 << PCIE_CR_CTL_CAP_ADR_LOC);
> +	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
> +
> +	/* wait for ack */
> +	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 1))
> +		return 0;
> +
> +	/* deassert cap addr */
> +	temp_wr_data = addr << PCIE_CR_CTL_DATA_LOC;
> +	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
> +
> +	/* wait for ack de-assetion */
> +	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 0))
> +		return 0 ;
> +
> +	return 1 ;

Remove the whitespace before the semicolons, also elsewhere in this
patch.

> +}
> +
> +static int pcie_phy_cr_read(void __iomem *dbi_base, int addr , int *data)
> +{
> +	u32 temp_rd_data, temp_wr_data;
> +
> +	/*  write addr */
> +	/* cap addr */
> +	if (!pcie_phy_cr_cap_addr(dbi_base, addr))
> +		return 0;
> +
> +	/* assert rd signal */
> +	temp_wr_data = 0x1 << PCIE_CR_CTL_RD_LOC;
> +	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
> +
> +	/* wait for ack */
> +	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 1))
> +		return 0;
> +
> +	/* after got ack return data */
> +	temp_rd_data = readl(dbi_base + PHY_STS_R);
> +	*data = (temp_rd_data & (0xffff << PCIE_CR_STAT_DATA_LOC)) ;
> +
> +	/* deassert rd signal */
> +	temp_wr_data = 0x0;
> +	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
> +
> +	/* wait for ack de-assetion */

s/assetion/assertion/

This typo is multiple times in this patch.

> +	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 0))
> +		return 0 ;
> +
> +	return 1 ;
> +
> +}
> +
> +static int pcie_phy_cr_write(void __iomem *dbi_base, int addr, int data)
> +{
> +	u32 temp_wr_data;
> +
> +	/* write addr */
> +	/* cap addr */
> +	if (!pcie_phy_cr_cap_addr(dbi_base, addr))
> +		return 0 ;
> +
> +	temp_wr_data = data << PCIE_CR_CTL_DATA_LOC;
> +	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
> +
> +	/* capture data */
> +	temp_wr_data |= (0x1 << PCIE_CR_CTL_CAP_DAT_LOC);
> +	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
> +
> +	/* wait for ack */
> +	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 1))
> +		return 0 ;
> +
> +	/* deassert cap data */
> +	temp_wr_data = data << PCIE_CR_CTL_DATA_LOC;
> +	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
> +
> +	/* wait for ack de-assetion */
> +	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 0))
> +		return 0;
> +
> +	/* assert wr signal */
> +	temp_wr_data = 0x1 << PCIE_CR_CTL_WR_LOC;
> +	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
> +
> +	/* wait for ack */
> +	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 1))
> +		return 0;
> +
> +	/* deassert wr signal */
> +	temp_wr_data = data << PCIE_CR_CTL_DATA_LOC;
> +	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
> +
> +	/* wait for ack de-assetion */
> +	if (!pcie_phy_cr_ack_polling(dbi_base, 100, 0))
> +		return 0;
> +
> +	temp_wr_data = 0x0 ;
> +	writel(temp_wr_data, dbi_base + PHY_CTRL_R);
> +
> +	return 1;
> +}
> +
> +static int imx_pcie_enable_controller(struct platform_device *pdev)
> +{
> +	struct imx_pcie_port *pp = platform_get_drvdata(pdev);
> +	int ret;
> +
> +	/* Enable PCIE power */
> +	gpio_set_value(pp->pcie_pwr_en, 1);
> +
> +	imx_pcie_clrset(pp, iomuxc_gpr1_test_powerdown, 0 << 18, IOMUXC_GPR1);
> +	imx_pcie_clrset(pp, iomuxc_gpr1_pcie_ref_clk_en, 1 << 16, IOMUXC_GPR1);
> +
> +	/* Enable clocks */
> +	ret = clk_set_parent(pp->lvds1_sel, pp->sata_ref);
> +	if (ret) {
> +		dev_err(&pdev->dev, "unable to set lvds1 parent: %d\n", ret);
> +		return -EINVAL;
> +	}

This should be done in architecture code I think.

> +
> +	ret = clk_prepare_enable(pp->pcie_ref_125m);
> +	if (ret) {
> +		dev_err(&pdev->dev, "unable to enable pcie_ref_125m: %d\n", ret);
> +		return -EINVAL;
> +	}
> +
> +	ret = clk_prepare_enable(pp->lvds1);
> +	if (ret) {
> +		dev_err(&pdev->dev, "unable to enable lvds1: %d\n", ret);
> +		return -EINVAL;
> +	}
> +
> +	ret = clk_prepare_enable(pp->pcie_axi);
> +	if (ret) {
> +		dev_err(&pdev->dev, "unable to enable pcie_axi: %d\n", ret);
> +		return -EINVAL;
> +	}

This function does not disable the already enabled clocks in the error
path. Please fix.

> +
> +
> +	return 0;
> +}
> +
> +static void card_reset(struct platform_device *pdev)
> +{
> +	struct imx_pcie_port *pp = platform_get_drvdata(pdev);
> +
> +	imx_pcie_clrset(pp, iomuxc_gpr1_test_powerdown, 1 << 18, IOMUXC_GPR1);
> +	imx_pcie_clrset(pp, iomuxc_gpr12_app_ltssm_enable, 1 << 10, IOMUXC_GPR12);
> +	imx_pcie_clrset(pp, iomuxc_gpr1_pcie_ref_clk_en, 0 << 16, IOMUXC_GPR1);
> +
> +	gpio_set_value(pp->pcie_rst, 0);
> +	msleep(100);
> +	gpio_set_value(pp->pcie_rst, 1);
> +}
> +
> +static int __init add_pcie_port(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct imx_pcie_port *pp = platform_get_drvdata(pdev);
> +	int ret;
> +
> +	ret = imx_pcie_link_up(pdev);
> +	if (ret) {
> +		dev_info(dev, "IMX PCIe port: link down!\n");
> +		/* Release the clocks, and disable the power */
> +
> +		clk_disable(pp->pcie_axi);
> +		clk_put(pp->pcie_axi);
> +
> +		clk_disable(pp->lvds1);
> +		clk_put(pp->lvds1);
> +
> +		clk_put(pp->pcie_ref_125m);
> +		clk_put(pp->sata_ref);

You clk_put the clocks in the error path of the probe function. Don't
duplicate it.

> +
> +		imx_pcie_clrset(pp, iomuxc_gpr1_pcie_ref_clk_en, 0 << 16,
> +				IOMUXC_GPR1);
> +
> +		/* Disable PCIE power */
> +		gpio_set_value(pp->pcie_pwr_en, 0);
> +
> +		imx_pcie_clrset(pp, iomuxc_gpr1_test_powerdown, 1 << 18,
> +				IOMUXC_GPR1);
> +
> +		return ret;
> +	}
> +
> +	dev_info(dev, "IMX PCIe port: link up.\n");
> +	pp->index = 0;
> +	pp->root_bus_nr = -1;
> +	spin_lock_init(&pp->conf_lock);
> +	return 0;
> +}
> +
> +
> +static int set_pcie_clock_tunings(struct platform_device *pdev)
> +{
> +	struct imx_pcie_port *pp = platform_get_drvdata(pdev);
> +	/* FIXME the field name should be aligned to RM */
> +	imx_pcie_clrset(pp, iomuxc_gpr12_app_ltssm_enable, 0 << 10, IOMUXC_GPR12);
> +
> +	/* configure constant input signal to the pcie ctrl and phy */
> +	imx_pcie_clrset(pp, iomuxc_gpr12_device_type, PCI_EXP_TYPE_ROOT_PORT << 12,
> +			IOMUXC_GPR12);
> +	imx_pcie_clrset(pp, iomuxc_gpr12_los_level, 9 << 4, IOMUXC_GPR12);
> +
> +	imx_pcie_clrset(pp, iomuxc_gpr8_tx_deemph_gen1, 0 << 0, IOMUXC_GPR8);
> +	imx_pcie_clrset(pp, iomuxc_gpr8_tx_deemph_gen2_3p5db, 0 << 6, IOMUXC_GPR8);
> +	imx_pcie_clrset(pp, iomuxc_gpr8_tx_deemph_gen2_6db, 20 << 12, IOMUXC_GPR8);
> +	imx_pcie_clrset(pp, iomuxc_gpr8_tx_swing_full, 127 << 18, IOMUXC_GPR8);
> +	imx_pcie_clrset(pp, iomuxc_gpr8_tx_swing_low, 127 << 25, IOMUXC_GPR8);
> +	return 0;
> +}
> +
> +
> +static int __init imx_pcie_pltfm_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct imx_pcie_port *pp = devm_kzalloc(dev, sizeof(*pp), GFP_KERNEL);
> +	int ret;
> +
> +	platform_set_drvdata(pdev, pp);
> +	pp->dev = &pdev->dev;
> +
> +        pp->pcie_pwr_en = of_get_named_gpio(pdev->dev.of_node,
> +                                "power-enable", 0);
> +        if (gpio_is_valid(pp->pcie_pwr_en))
> +                devm_gpio_request_one(dev, pp->pcie_pwr_en,
> +                                    GPIOF_OUT_INIT_LOW,
> +                                    "PCIe power enable");
> +
> +        pp->pcie_rst = of_get_named_gpio(pdev->dev.of_node,
> +                                "pcie-reset", 0);
> +        if (gpio_is_valid(pp->pcie_rst))
> +                devm_gpio_request_one(dev, pp->pcie_rst,
> +                                    GPIOF_OUT_INIT_LOW,
> +                                    "PCIe reset");
> +
> +        pp->pcie_wake_up = of_get_named_gpio(pdev->dev.of_node,
> +                                "wake-up", 0);
> +        if (gpio_is_valid(pp->pcie_wake_up))
> +                devm_gpio_request_one(dev, pp->pcie_wake_up,
> +                                    GPIOF_IN,
> +                                    "PCIe wake up");

More whitespace damage above.

> +
> +	pp->dbi = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!pp->dbi) {
> +		dev_err(dev, "no mmio space\n");
> +		return -EINVAL;
> +	}
> +
> +	pp->dbi_base = devm_request_and_ioremap(&pdev->dev, pp->dbi);
> +	if (!pp->dbi_base) {
> +		pr_err("unable to remap dbi\n");
> +		return -ENOMEM;
> +	}
> +
> +
> +	pp->io = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +	if (!pp->io) {
> +		dev_err(dev, "no mmio space\n");
> +		return -EINVAL;
> +	}
> +
> +	pp->mem = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> +	if (!pp->mem) {
> +		dev_err(dev, "no mmio space\n");
> +		return -EINVAL;
> +	}
> +
> +	pp->root = platform_get_resource(pdev, IORESOURCE_MEM, 3);
> +	if (!pp->root) {
> +		dev_err(dev, "no root memory space\n");
> +		return -EINVAL;
> +	}
> +
> +	pp->root_base = devm_request_and_ioremap(&pdev->dev, pp->root);
> +	if (!pp->root_base) {
> +		dev_err(&pdev->dev, "unable to remap root mem\n");
> +		return -ENOMEM;
> +	}
> +
> +
> +	pp->interrupt = platform_get_irq(pdev, 0);
> +
> +
> +        /* Setup clocks */

Whitespace damage here.

> +	pp->lvds1_sel = clk_get(dev, "lvds1_sel");

Use devm_clk_get

> +	if (IS_ERR(pp->lvds1_sel)) {
> +		dev_err(dev,
> +			"lvds1_sel clock missing or invalid\n");
> +		ret = -EINVAL;
> +		goto err_out;
> +	}
> +
> +	pp->lvds1 = clk_get(dev, "lvds1");
> +	if (IS_ERR(pp->lvds1)) {
> +		dev_err(dev,
> +			"lvds1 clock select missing or invalid\n");
> +		ret = -EINVAL;
> +		goto err_out;
> +	}
> +
> +	pp->pcie_ref_125m = clk_get(dev, "pcie_ref_125m");
> +	if (IS_ERR(pp->pcie_ref_125m)) {
> +		dev_err(dev,
> +			"pcie_ref_125m clock source missing or invalid\n");
> +		ret = -EINVAL;
> +		goto err_out;
> +	}
> +
> +	pp->pcie_axi = clk_get(dev, "pcie_axi");
> +	if (IS_ERR(pp->pcie_axi)) {
> +		dev_err(dev, "pcie_axi clock source missing or invalid\n");
> +		ret = -EINVAL;
> +		goto err_out;
> +	}
> +
> +	pp->sata_ref = clk_get(dev, "sata_ref");
> +	if (IS_ERR(pp->sata_ref)) {
> +		dev_err(dev, "sata_ref clock source missing or invalid\n");
> +		ret = -EINVAL;
> +		goto err_out;
> +	}
> +
> +	pp->iomuxc_gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +	if (IS_ERR(pp->iomuxc_gpr)) {
> +		dev_err(dev, "unable to find iomuxc registers\n");
> +		ret = -EINVAL;
> +		goto err_out;
> +	}
> +
> +	/* togle the external card's reset */
> +	card_reset(pdev);
> +
> +	/* Enable the pwr, clks and so on */
> +	set_pcie_clock_tunings(pdev);
> +	ret = imx_pcie_enable_controller(pdev);
> +	if (ret)
> +		goto err_out;
> +
> +	usleep_range(3000, 4000);
> +	imx_pcie_regions_setup(pdev, pp);
> +	usleep_range(3000, 4000);

Are these usleeps required?

> +
> +	/* start link up */
> +	imx_pcie_clrset(pp, iomuxc_gpr12_app_ltssm_enable, 1 << 10, IOMUXC_GPR12);
> +
> +	/* add the pcie port */
> +	ret = add_pcie_port(pdev);
> +	if (ret)
> +		goto err_out;
> +
> +	pp->index = imx_pcie.nr_controllers;
> +	imx_pcie.nr_controllers++;
> +	list_add_tail(&pp->next, &pcie_port_list);
> +
> +	pci_common_init(&imx_pci);
> +
> +	return 0;
> +
> +err_out:
> +	if (pp->lvds1_sel)
> +		clk_put(pp->lvds1_sel);
> +	if (pp->lvds1)
> +		clk_put(pp->lvds1);
> +	if (pp->pcie_ref_125m)
> +		clk_put(pp->pcie_ref_125m);
> +	if (pp->pcie_axi)
> +		clk_put(pp->pcie_axi);
> +	if (pp->sata_ref)
> +		clk_put(pp->sata_ref);

You shouldn't call clk_put with error codes.

> +	return ret;
> +}
> +
> +static int __exit imx_pcie_pltfm_remove(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct imx_pcie_port *pp = platform_get_drvdata(pdev);
> +
> +	if (pp->rfkill) {
> +		rfkill_unregister(pp->rfkill);
> +		rfkill_destroy(pp->rfkill);
> +		pp->rfkill = NULL;
> +	}
> +
> +	imx_pcie_clrset(pp, iomuxc_gpr1_pcie_ref_clk_en, 0 << 16, IOMUXC_GPR1);
> +	imx_pcie_clrset(pp, iomuxc_gpr1_test_powerdown, 1 << 18, IOMUXC_GPR1);
> +	imx_pcie_clrset(pp, iomuxc_gpr12_app_ltssm_enable, 1 << 10, IOMUXC_GPR12);
> +
> +	/* Release clocks, and disable power  */
> +	if (pp->pcie_axi) {
> +		clk_disable(pp->pcie_axi);
> +		clk_put(pp->pcie_axi);
> +	}
> +
> +	if (pp->lvds1) {
> +		clk_disable(pp->lvds1);
> +		clk_put(pp->lvds1);
> +	}
> +
> +	if (pp->pcie_ref_125m)
> +		clk_put(pp->pcie_ref_125m);
> +
> +	if (pp->sata_ref)
> +		clk_put(pp->sata_ref);

All these tests are *always* true.

> +
> +	gpio_set_value(pp->pcie_rst, 0);
> +	gpio_set_value(pp->pcie_pwr_en, 0);
> +
> +	dev_err(dev, "disabled everything\n");

Remove this.

> +	msleep(500);

Why?

> +
> +	platform_set_drvdata(pdev, NULL);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver imx_pcie_pltfm_driver = {
> +	.driver = {
> +		.name		= "imx-pcie",
> +		.owner		= THIS_MODULE,
> +		.of_match_table = pcie_of_match,
> +	},
> +	.probe		= imx_pcie_pltfm_probe,
> +	.remove		= __exit_p(imx_pcie_pltfm_remove),
> +};
> +
> +/*****************************************************************************\
> + *                                                                           *
> + * Driver init/exit                                                          *
> + *                                                                           *
> +\*****************************************************************************/
> +
> +static int __init imx_pcie_drv_init(void)
> +{
> +	INIT_LIST_HEAD(&pcie_port_list);
> +	return platform_driver_register(&imx_pcie_pltfm_driver);
> +}
> +
> +static void __exit imx_pcie_drv_exit(void)
> +{
> +	platform_driver_unregister(&imx_pcie_pltfm_driver);
> +}
> +
> +module_init(imx_pcie_drv_init);
> +module_exit(imx_pcie_drv_exit);
> +
> +MODULE_DESCRIPTION("i.MX PCIE platform driver");
> +MODULE_AUTHOR("Sean Cross <xobs at kosagi.com>");
> +MODULE_LICENSE("GPL v2");
> -- 
> 1.7.9.5
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From arnd at arndb.de  Tue Jul  2 04:09:37 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 02 Jul 2013 10:09:37 +0200
Subject: [PATCH 3/4] PCI: Add driver for i.MX6 PCI Express
In-Reply-To: <51D25A13.9060006@st.com>
References: <1372662947-27160-1-git-send-email-xobs@kosagi.com>
 <2E3BDF14016345FA887E3BACAE05DADA@kosagi.com> <51D25A13.9060006@st.com>
Message-ID: <2810182.Mjp7jITIaf@wuerfel>

On Tuesday 02 July 2013 10:11:55 Pratyush Anand wrote:
> On 7/2/2013 9:16 AM, Sean Cross wrote:
> >> >I may be wrong, but from these offset it seems to me that it is SNPS
> >> >controller. If yes, then please go through comments of
> >> >"[PATCH V1-10 0/4] PCIe support for Samsung Exynos5440 SoC"
> > Exynos5440 appears to use the same port logic controller.  However, the PHYs are different.  I'm not exactly certain which comments you want me to notice in that series of patchsets, but I see references to splitting Exynos-specific code into its own project.  Based on that, it seems like the best approach would be to:
> >
> >      1) Move Exynos code into its own file, say, pcie-exynos.c.  This would leave only Synopsys-specific ATC code in pcie-designware.c
> >      2) Rename generic exynos functions to reflect the fact that they're designware-generic functions.

Ouch, I missed the fact that Jingoo Han had only renamed the file, but not
also all the function identifiers. This change needs to be done anyway.

> >      3) Have pcie-imx.c reference this generic designware ATC code.
> >
> > I'll rework the patch and re-submit it following these three changes.
>
> Correct, Exactly these steps has to be done. But, Mohit might be doing 
> similar work, so it would be better to get consensus on what has to be done.

If the platform specific parts are small enough, you can actually just leave
everything in one file, and use the of_device_id data field to point
to a structure describing the differences, e.g. using function pointers.
 
> IMO, there should be three categories of functions. May be arnd can 
> comment if we can do even something better.

As a general comment in case you are wondering: In a situation like this,
the common code should always be structured as a "library" of functions
and the hardware specific drivers become the actual driver that register
to a particular device 'compatible' string in DT.

> Group I: Initially, These functions should remain in pcie-designware.c 
> (offcourse by changing exynos tag to dw). Latter on, we can see if some 
> of them can even be moved to common pci layer.
> 
> sys_to_pcie
> cfg_read
> cfg_write
> dw_pcie_prog_viewport_cfg0
> dw_pcie_prog_viewport_cfg1
> dw_pcie_prog_viewport_mem_outbound
> dw_pcie_prog_viewport_io_outbound
> dw_pcie_rd_other_conf
> dw_pcie_wr_other_conf
> dw_pcie_setup
> dw_pcie_valid_config
> dw_pcie_rd_conf
> dw_pcie_wd_conf
> dw_pcie_scan_bus
> dw_pcie_map_irq
> dw_pcie_setup_rc
> add_pcie_port (after a bit of generalization)
> dw_pcie_probe
> dw_pcie_remove

The probe and remove functions might need be split up into a generic
part that gets called by the hardware specific part.

> Group II: These functions should still remain as dummy in 
> pcie-designware.c , and should be classified as __week. So, each 
> implementer of designware controller say Exynos/SPEAr/imx will have to 
> define their own function to super-seed default dummy definitions.
> 
> dw_readl_rc
> dw_writel_rc
> dw_pcie_rd_own_conf
> dw_pcie_wr_own_conf
> dw_pcie_link_up
> dw_pcie_host_init (will contain all platform specific and phy 
> initialization)

I don't like __weak functions really, and they don't work well with loadable
modules the way I suggested above. Instead, you probably need a structure
with function pointers that gets initialized by platform specific
driver.

	struct dw_pcie_host_ops {
		void (*readl_rc)(struct pcie_port *pp, void *dbi_base, u32 *val);
		...
	};

static inline void dw_pcie_readl_rc(struct pcie_port *pp, void *dbi_base, u32 *val);
{
	if (pp->ops->readl_rc)
		pp->ops->readl_rc(pp, dbi_base, val);
	else
		*val = readl(dbi_base);
}

dw_pcie_host_init would become the probe function that calls the generic
dw_pcie_probe.

> Group III: Functions specific to Exynos, which should move to pcie-exynos.c
> 
> exynos_pcie_sideband_dbi_w_mode
> exynos_pcie_sideband_dbi_r_mode
> exynos_pcie_assert_core_reset
> exynos_pcie_deassert_core_reset
> exynos_pcie_assert_phy_reset
> exynos_pcie_deassert_phy_reset
> exynos_pcie_init_phy
> exynos_pcie_assert_reset
> exynos_pcie_establish_link
> 
> 
> @Mohit, See if you have BW then please take it further.
> 
> arnd, are exynos patches applied to any branch of arm-soc git tree?

Yes, they are currently in the next/soc branch.

	Arnd


From richard.genoud at gmail.com  Tue Jul  2 04:13:08 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 2 Jul 2013 10:13:08 +0200
Subject: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
In-Reply-To: <51D24299.9050209@atmel.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-2-git-send-email-richard.genoud@gmail.com>
 <51D24299.9050209@atmel.com>
Message-ID: <CACQ1gAgcc=j3kmcpjp8bbdHhxr_k=h8jJs6R_paJbPUMv74uGg@mail.gmail.com>

2013/7/2 Bo Shen <voice.shen at atmel.com>:
> Hi Richard,
>
>
> On 7/1/2013 16:39, Richard Genoud wrote:
>>
>> The ssc device has to fill the at_dma_slave structure with the
>> device tree informations.
>> Doing a of_dma_request_slave_channel()+dma_release_channel() for that
>> seems wrong (or at least not very clean).
>
>
> Please hold on of this, as to the ASoC dmaengine will deal with this. So, we
> not need do it manually.
>
> Now, I am working on it. And will send out the patch soon after testing OK.
Ok, I stay tuned !

Thanks !

Best regards,
Richard


From rogerq at ti.com  Tue Jul  2 04:22:17 2013
From: rogerq at ti.com (Roger Quadros)
Date: Tue, 2 Jul 2013 11:22:17 +0300
Subject: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during
 bus suspend
In-Reply-To: <Pine.LNX.4.44L0.1307011655580.1547-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307011655580.1547-100000@iolanthe.rowland.org>
Message-ID: <51D28DB9.704@ti.com>

On 07/02/2013 12:01 AM, Alan Stern wrote:
> On Mon, 1 Jul 2013, Felipe Balbi wrote:
> 
>>> I don't know what Pad wakeup is.  The wakeup signal has to originate 
>>> from the EHCI controller, doesn't it?  If not, how does the Pad know 
>>> when a wakeup is needed?
>>
>> That's really an OMAP thing, I guess. Pad wakeup sits in the PRCM (IIRC)
>> inside and always on power domain. EHCI sits in another power domain
>> which be turned off. When it's turned off (power gated and clock gated)
>> the EHCI block has no means to wakeup whatsoever. That's when pad wakeup
>> comes into play. It is generated when PRCM sees a change in the actual
>> pad of the die. To check who should 'own' the wakeup, it checks the
>> muxing settings to verify whose pad is that.
> 
> How does the PRCM know which changes should generate wakeup events?  

It doesn't know. It will always generate a wakeup on any change in the monitored pins.
We can only configure which pins we want to monitor.
So we can't choose which wakeup events we want to monitor. We just can
enable or disable all events.

> In the EHCI controller, this is managed by the settings of the WKOC_E,
> WKDSCNNT_E, and WKCNNT_E bits in the PORTSC registers.  But if EHCI is
> powered off, those bits can't be used.

Is "powered off" same as ehci_suspend? If yes then how does it work on other systems
for remote wakeup?

> 
> Also, once the wakeup signal has been turned on, how does it get turned 
> off again?

That is taken care of by the OMAP pinctrl driver. It will always turn off the
wakeup signal once the event is detected and forwarded as an IRQ.

I know that all this is a bit ugly :(.

cheers,
-roger


From jg1.han at samsung.com  Tue Jul  2 04:38:23 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Tue, 02 Jul 2013 17:38:23 +0900
Subject: [PATCH V4 0/4] Generic PHY driver for the Exynos SoC DP PHY
Message-ID: <000901ce76ff$83d697e0$8b83c7a0$@samsung.com>

This patch series adds a simple driver for the Samsung Exynos SoC
series DP transmitter PHY, using the generic PHY framework [1].
Previously the DP PHY used an internal DT node to control the PHY
power enable bit.

These patches was tested on Exynos5250.

This PATCH v4 follows:
 * PATCH v3, sent on July, 1st 2013
 * PATCH v2, sent on June, 28th 2013
 * PATCH v1, sent on June, 28th 2013

Changes between v3 and v4:
  * Added OF dependancy.
  * Removed redundant local variable 'void __iomem *addr'.
  * Removed unnecessary dev_set_drvdata().
  * Added a patch that remove non-DT support for Exynos
    Display Port driver.
  * Removed unnecessary 'struct exynos_dp_platdata'.
  * Kept supporting the original bindings for DT compatibility.

Changes between v2 and v3:
  * Removed redundant spinlock
  * Removed 'struct phy' from 'struct exynos_dp_video_phy'
  * Updated 'samsung-phy.txt', instead of creating
    'samsung,exynos5250-dp-video-phy.txt'.
  * Removed unnecessary additional specifier from 'phys'
    DT property.
  * Added 'phys', 'phy-names' properties to 'exynos_dp.txt' file.
  * Added Felipe Balbi's Acked-by.

Changes between v1 and v2:
  * Replaced exynos_dp_video_phy_xlate() with of_phy_simple_xlate(),
    as Kishon Vijay Abraham I guided.
  * Set the value of phy-cells as 0, because the phy_provider implements
    only one PHY.
  * Removed unnecessary header include.
  * Added '#ifdef CONFIG_OF' and of_match_ptr macro.

This series depends on the generic PHY framework [1]. These patches
refer to Sylwester Nawrocki's patches about Exynos MIPI [2].

[1] https://lkml.org/lkml/2013/6/26/259
[2] http://www.spinics.net/lists/linux-samsung-soc/msg20098.html

Jingoo Han (4):
  ARM: dts: Add DP PHY node to exynos5250.dtsi
  phy: Add driver for Exynos DP PHY
  video: exynos_dp: remove non-DT support for Exynos Display Port
  video: exynos_dp: Use the generic PHY driver

 .../devicetree/bindings/phy/samsung-phy.txt        |    8 ++
 .../devicetree/bindings/video/exynos_dp.txt        |   23 +++++---------------
 arch/arm/boot/dts/exynos5250.dtsi                  |   13 ++++++++-----
 drivers/phy/Kconfig                                |    6 ++
 drivers/phy/Makefile                               |    1 +
 drivers/phy/phy-exynos-dp-video.c                  |  111 ++++++++++++++++++++
 drivers/video/exynos/Kconfig                       |    2 +-
 drivers/video/exynos/exynos_dp_core.c              |  132 +++++++----------------------
 drivers/video/exynos/exynos_dp_core.h              |  111 +++++++++++++++++++++++++++
 drivers/video/exynos/exynos_dp_reg.c               |    2 -
 include/video/exynos_dp.h                          |  131 ---------------------------------
 11 files changed, 289 insertions(+), 251 deletions(-)
 create mode 100644 drivers/phy/phy-exynos-dp-video.c
 delete mode 100644 include/video/exynos_dp.h
 
--
1.7.10.4



From jg1.han at samsung.com  Tue Jul  2 04:39:11 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Tue, 02 Jul 2013 17:39:11 +0900
Subject: [PATCH V4 1/4] ARM: dts: Add DP PHY node to exynos5250.dtsi
Message-ID: <000a01ce76ff$a02a7c40$e07f74c0$@samsung.com>

Add PHY provider node for the DP PHY.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/boot/dts/exynos5250.dtsi |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 41cd625..7e397c6 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -614,6 +614,12 @@
 		interrupts = <0 94 0>;
 	};
 
+	dp_phy: video-phy at 10040720 {
+		compatible = "samsung,exynos5250-dp-video-phy";
+		reg = <0x10040720 4>;
+		#phy-cells = <0>;
+	};
+
 	dp-controller {
 		compatible = "samsung,exynos5-dp";
 		reg = <0x145b0000 0x1000>;
@@ -623,11 +629,8 @@
 		clock-names = "dp";
 		#address-cells = <1>;
 		#size-cells = <0>;
-
-		dptx-phy {
-			reg = <0x10040720>;
-			samsung,enable-mask = <1>;
-		};
+		phys = <&dp_phy>;
+		phy-names = "dp";
 	};
 
 	fimd {
-- 
1.7.10.4




From jg1.han at samsung.com  Tue Jul  2 04:40:31 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Tue, 02 Jul 2013 17:40:31 +0900
Subject: [PATCH V4 2/4] phy: Add driver for Exynos DP PHY
Message-ID: <000b01ce76ff$cf9fd6a0$6edf83e0$@samsung.com>

Add a PHY provider driver for the Samsung Exynos SoC DP PHY.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 .../devicetree/bindings/phy/samsung-phy.txt        |    8 ++
 drivers/phy/Kconfig                                |    6 ++
 drivers/phy/Makefile                               |    1 +
 drivers/phy/phy-exynos-dp-video.c                  |  111 ++++++++++++++++++++
 4 files changed, 126 insertions(+)
 create mode 100644 drivers/phy/phy-exynos-dp-video.c

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 5ff208c..c0fccaa 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -12,3 +12,11 @@ the PHY specifier identifies the PHY and its meaning is as follows:
   1 - MIPI DSIM 0,
   2 - MIPI CSIS 1,
   3 - MIPI DSIM 1.
+
+Samsung EXYNOS SoC series Display Port PHY
+-------------------------------------------------
+
+Required properties:
+- compatible : should be "samsung,exynos5250-dp-video-phy";
+- reg : offset and length of the Display Port PHY register set;
+- #phy-cells : from the generic PHY bindings, must be 0;
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 6f446d0..ed0b1b8 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -19,4 +19,10 @@ config PHY_EXYNOS_MIPI_VIDEO
 	help
 	  Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
 	  S5P and EXYNOS SoCs.
+
+config PHY_EXYNOS_DP_VIDEO
+	tristate "EXYNOS SoC series Display Port PHY driver"
+	depends on OF
+	help
+	  Support for Display Port PHY found on Samsung EXYNOS SoCs.
 endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 71d8841..0fd1340 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_GENERIC_PHY)		+= phy-core.o
 obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)	+= phy-exynos-mipi-video.o
+obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)	+= phy-exynos-dp-video.o
diff --git a/drivers/phy/phy-exynos-dp-video.c b/drivers/phy/phy-exynos-dp-video.c
new file mode 100644
index 0000000..3c8e247
--- /dev/null
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -0,0 +1,111 @@
+/*
+ * Samsung EXYNOS SoC series Display Port PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Jingoo Han <jg1.han at samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+
+/* DPTX_PHY_CONTROL register */
+#define EXYNOS_DPTX_PHY_ENABLE		(1 << 0)
+
+struct exynos_dp_video_phy {
+	void __iomem *regs;
+};
+
+static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int on)
+{
+	u32 reg;
+
+	reg = readl(state->regs);
+	if (on)
+		reg |= EXYNOS_DPTX_PHY_ENABLE;
+	else
+		reg &= ~EXYNOS_DPTX_PHY_ENABLE;
+	writel(reg, state->regs);
+
+	return 0;
+}
+
+static int exynos_dp_video_phy_power_on(struct phy *phy)
+{
+	struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+	return __set_phy_state(state, 1);
+}
+
+static int exynos_dp_video_phy_power_off(struct phy *phy)
+{
+	struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+	return __set_phy_state(state, 0);
+}
+
+static struct phy_ops exynos_dp_video_phy_ops = {
+	.power_on	= exynos_dp_video_phy_power_on,
+	.power_off	= exynos_dp_video_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
+static int exynos_dp_video_phy_probe(struct platform_device *pdev)
+{
+	struct exynos_dp_video_phy *state;
+	struct device *dev = &pdev->dev;
+	struct resource *res;
+	struct phy_provider *phy_provider;
+	struct phy *phy;
+
+	state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
+	if (!state)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+	state->regs = devm_ioremap_resource(dev, res);
+	if (IS_ERR(state->regs))
+		return PTR_ERR(state->regs);
+
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	phy = devm_phy_create(dev, 0, &exynos_dp_video_phy_ops, NULL);
+	if (IS_ERR(phy)) {
+		dev_err(dev, "failed to create Display Port PHY\n");
+		return PTR_ERR(phy);
+	}
+	phy_set_drvdata(phy, state);
+
+	return 0;
+}
+
+static const struct of_device_id exynos_dp_video_phy_of_match[] = {
+	{ .compatible = "samsung,exynos5250-dp-video-phy" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, exynos_dp_video_phy_of_match);
+
+static struct platform_driver exynos_dp_video_phy_driver = {
+	.probe	= exynos_dp_video_phy_probe,
+	.driver = {
+		.name	= "exynos-dp-video-phy",
+		.owner	= THIS_MODULE,
+		.of_match_table	= exynos_dp_video_phy_of_match,
+	}
+};
+module_platform_driver(exynos_dp_video_phy_driver);
+
+MODULE_AUTHOR("Jingoo Han <jg1.han at samsung.com>");
+MODULE_DESCRIPTION("Samsung EXYNOS SoC DP PHY driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.10.4




From jg1.han at samsung.com  Tue Jul  2 04:41:52 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Tue, 02 Jul 2013 17:41:52 +0900
Subject: [PATCH V4 3/4] video: exynos_dp: remove non-DT support for Exynos
 Display Port
Message-ID: <000c01ce76ff$fffa39d0$ffeead70$@samsung.com>

Exynos Display Port can be used only for Exynos SoCs. In addition,
non-DT for EXYNOS SoCs is be supported from v3.11; thus, there is
no need to support non-DT for Exynos Display Port.

The 'include/video/exynos_dp.h' file has been used for non-DT
support and the content of file include/video/exynos_dp.h is moved
to drivers/video/exynos/exynos_dp_core.h. Thus, the 'exynos_dp.h'
file is removed. Also, 'struct exynos_dp_platdata' is removed,
because it is not used any more.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
---
 drivers/video/exynos/Kconfig          |    2 +-
 drivers/video/exynos/exynos_dp_core.c |  116 +++++++----------------------
 drivers/video/exynos/exynos_dp_core.h |  109 +++++++++++++++++++++++++++
 drivers/video/exynos/exynos_dp_reg.c  |    2 -
 include/video/exynos_dp.h             |  131 ---------------------------------
 5 files changed, 135 insertions(+), 225 deletions(-)
 delete mode 100644 include/video/exynos_dp.h

diff --git a/drivers/video/exynos/Kconfig b/drivers/video/exynos/Kconfig
index 1b035b2..fab9019 100644
--- a/drivers/video/exynos/Kconfig
+++ b/drivers/video/exynos/Kconfig
@@ -29,7 +29,7 @@ config EXYNOS_LCD_S6E8AX0
 
 config EXYNOS_DP
 	bool "EXYNOS DP driver support"
-	depends on ARCH_EXYNOS
+	depends on OF && ARCH_EXYNOS
 	default n
 	help
 	  This enables support for DP device.
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index 12bbede..05fed7d 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -20,8 +20,6 @@
 #include <linux/delay.h>
 #include <linux/of.h>
 
-#include <video/exynos_dp.h>
-
 #include "exynos_dp_core.h"
 
 static int exynos_dp_init_dp(struct exynos_dp_device *dp)
@@ -894,26 +892,17 @@ static void exynos_dp_hotplug(struct work_struct *work)
 		dev_err(dp->dev, "unable to config video\n");
 }
 
-#ifdef CONFIG_OF
-static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
+static struct video_info *exynos_dp_dt_parse_pdata(struct device *dev)
 {
 	struct device_node *dp_node = dev->of_node;
-	struct exynos_dp_platdata *pd;
 	struct video_info *dp_video_config;
 
-	pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
-	if (!pd) {
-		dev_err(dev, "memory allocation for pdata failed\n");
-		return ERR_PTR(-ENOMEM);
-	}
 	dp_video_config = devm_kzalloc(dev,
 				sizeof(*dp_video_config), GFP_KERNEL);
-
 	if (!dp_video_config) {
 		dev_err(dev, "memory allocation for video config failed\n");
 		return ERR_PTR(-ENOMEM);
 	}
-	pd->video_info = dp_video_config;
 
 	dp_video_config->h_sync_polarity =
 		of_property_read_bool(dp_node, "hsync-active-high");
@@ -960,7 +949,7 @@ static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
 		return ERR_PTR(-EINVAL);
 	}
 
-	return pd;
+	return dp_video_config;
 }
 
 static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
@@ -1003,48 +992,30 @@ err:
 
 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 {
-	u32 reg;
+	if (dp->phy_addr) {
+		u32 reg;
 
-	reg = __raw_readl(dp->phy_addr);
-	reg |= dp->enable_mask;
-	__raw_writel(reg, dp->phy_addr);
+		reg = __raw_readl(dp->phy_addr);
+		reg |= dp->enable_mask;
+		__raw_writel(reg, dp->phy_addr);
+	}
 }
 
 static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
 {
-	u32 reg;
-
-	reg = __raw_readl(dp->phy_addr);
-	reg &= ~(dp->enable_mask);
-	__raw_writel(reg, dp->phy_addr);
-}
-#else
-static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
-{
-	return NULL;
-}
-
-static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
-{
-	return -EINVAL;
-}
-
-static void exynos_dp_phy_init(struct exynos_dp_device *dp)
-{
-	return;
-}
+	if (dp->phy_addr) {
+		u32 reg;
 
-static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
-{
-	return;
+		reg = __raw_readl(dp->phy_addr);
+		reg &= ~(dp->enable_mask);
+		__raw_writel(reg, dp->phy_addr);
+	}
 }
-#endif /* CONFIG_OF */
 
 static int exynos_dp_probe(struct platform_device *pdev)
 {
 	struct resource *res;
 	struct exynos_dp_device *dp;
-	struct exynos_dp_platdata *pdata;
 
 	int ret = 0;
 
@@ -1057,21 +1028,13 @@ static int exynos_dp_probe(struct platform_device *pdev)
 
 	dp->dev = &pdev->dev;
 
-	if (pdev->dev.of_node) {
-		pdata = exynos_dp_dt_parse_pdata(&pdev->dev);
-		if (IS_ERR(pdata))
-			return PTR_ERR(pdata);
+	dp->video_info = exynos_dp_dt_parse_pdata(&pdev->dev);
+	if (IS_ERR(dp->video_info))
+		return PTR_ERR(dp->video_info);
 
-		ret = exynos_dp_dt_parse_phydata(dp);
-		if (ret)
-			return ret;
-	} else {
-		pdata = pdev->dev.platform_data;
-		if (!pdata) {
-			dev_err(&pdev->dev, "no platform data\n");
-			return -EINVAL;
-		}
-	}
+	ret = exynos_dp_dt_parse_phydata(dp);
+	if (ret)
+		return ret;
 
 	dp->clock = devm_clk_get(&pdev->dev, "dp");
 	if (IS_ERR(dp->clock)) {
@@ -1095,15 +1058,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
 
 	INIT_WORK(&dp->hotplug_work, exynos_dp_hotplug);
 
-	dp->video_info = pdata->video_info;
-
-	if (pdev->dev.of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_init(dp);
-	} else {
-		if (pdata->phy_init)
-			pdata->phy_init();
-	}
+	exynos_dp_phy_init(dp);
 
 	exynos_dp_init_dp(dp);
 
@@ -1121,18 +1076,11 @@ static int exynos_dp_probe(struct platform_device *pdev)
 
 static int exynos_dp_remove(struct platform_device *pdev)
 {
-	struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
 	struct exynos_dp_device *dp = platform_get_drvdata(pdev);
 
 	flush_work(&dp->hotplug_work);
 
-	if (pdev->dev.of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_exit(dp);
-	} else {
-		if (pdata->phy_exit)
-			pdata->phy_exit();
-	}
+	exynos_dp_phy_exit(dp);
 
 	clk_disable_unprepare(dp->clock);
 
@@ -1143,20 +1091,13 @@ static int exynos_dp_remove(struct platform_device *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int exynos_dp_suspend(struct device *dev)
 {
-	struct exynos_dp_platdata *pdata = dev->platform_data;
 	struct exynos_dp_device *dp = dev_get_drvdata(dev);
 
 	disable_irq(dp->irq);
 
 	flush_work(&dp->hotplug_work);
 
-	if (dev->of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_exit(dp);
-	} else {
-		if (pdata->phy_exit)
-			pdata->phy_exit();
-	}
+	exynos_dp_phy_exit(dp);
 
 	clk_disable_unprepare(dp->clock);
 
@@ -1165,16 +1106,9 @@ static int exynos_dp_suspend(struct device *dev)
 
 static int exynos_dp_resume(struct device *dev)
 {
-	struct exynos_dp_platdata *pdata = dev->platform_data;
 	struct exynos_dp_device *dp = dev_get_drvdata(dev);
 
-	if (dev->of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_init(dp);
-	} else {
-		if (pdata->phy_init)
-			pdata->phy_init();
-	}
+	exynos_dp_phy_init(dp);
 
 	clk_prepare_enable(dp->clock);
 
@@ -1203,7 +1137,7 @@ static struct platform_driver exynos_dp_driver = {
 		.name	= "exynos-dp",
 		.owner	= THIS_MODULE,
 		.pm	= &exynos_dp_pm_ops,
-		.of_match_table = of_match_ptr(exynos_dp_match),
+		.of_match_table = exynos_dp_match,
 	},
 };
 
diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
index 6c567bbf..56cfec8 100644
--- a/drivers/video/exynos/exynos_dp_core.h
+++ b/drivers/video/exynos/exynos_dp_core.h
@@ -13,6 +13,99 @@
 #ifndef _EXYNOS_DP_CORE_H
 #define _EXYNOS_DP_CORE_H
 
+#define DP_TIMEOUT_LOOP_COUNT 100
+#define MAX_CR_LOOP 5
+#define MAX_EQ_LOOP 5
+
+enum link_rate_type {
+	LINK_RATE_1_62GBPS = 0x06,
+	LINK_RATE_2_70GBPS = 0x0a
+};
+
+enum link_lane_count_type {
+	LANE_COUNT1 = 1,
+	LANE_COUNT2 = 2,
+	LANE_COUNT4 = 4
+};
+
+enum link_training_state {
+	START,
+	CLOCK_RECOVERY,
+	EQUALIZER_TRAINING,
+	FINISHED,
+	FAILED
+};
+
+enum voltage_swing_level {
+	VOLTAGE_LEVEL_0,
+	VOLTAGE_LEVEL_1,
+	VOLTAGE_LEVEL_2,
+	VOLTAGE_LEVEL_3,
+};
+
+enum pre_emphasis_level {
+	PRE_EMPHASIS_LEVEL_0,
+	PRE_EMPHASIS_LEVEL_1,
+	PRE_EMPHASIS_LEVEL_2,
+	PRE_EMPHASIS_LEVEL_3,
+};
+
+enum pattern_set {
+	PRBS7,
+	D10_2,
+	TRAINING_PTN1,
+	TRAINING_PTN2,
+	DP_NONE
+};
+
+enum color_space {
+	COLOR_RGB,
+	COLOR_YCBCR422,
+	COLOR_YCBCR444
+};
+
+enum color_depth {
+	COLOR_6,
+	COLOR_8,
+	COLOR_10,
+	COLOR_12
+};
+
+enum color_coefficient {
+	COLOR_YCBCR601,
+	COLOR_YCBCR709
+};
+
+enum dynamic_range {
+	VESA,
+	CEA
+};
+
+enum pll_status {
+	PLL_UNLOCKED,
+	PLL_LOCKED
+};
+
+enum clock_recovery_m_value_type {
+	CALCULATED_M,
+	REGISTER_M
+};
+
+enum video_timing_recognition_type {
+	VIDEO_TIMING_FROM_CAPTURE,
+	VIDEO_TIMING_FROM_REGISTER
+};
+
+enum analog_power_block {
+	AUX_BLOCK,
+	CH0_BLOCK,
+	CH1_BLOCK,
+	CH2_BLOCK,
+	CH3_BLOCK,
+	ANALOG_TOTAL,
+	POWER_ALL
+};
+
 enum dp_irq_type {
 	DP_IRQ_TYPE_HP_CABLE_IN,
 	DP_IRQ_TYPE_HP_CABLE_OUT,
@@ -20,6 +113,22 @@ enum dp_irq_type {
 	DP_IRQ_TYPE_UNKNOWN,
 };
 
+struct video_info {
+	char *name;
+
+	bool h_sync_polarity;
+	bool v_sync_polarity;
+	bool interlaced;
+
+	enum color_space color_space;
+	enum dynamic_range dynamic_range;
+	enum color_coefficient ycbcr_coeff;
+	enum color_depth color_depth;
+
+	enum link_rate_type link_rate;
+	enum link_lane_count_type lane_count;
+};
+
 struct link_train {
 	int eq_loop;
 	int cr_loop[4];
diff --git a/drivers/video/exynos/exynos_dp_reg.c b/drivers/video/exynos/exynos_dp_reg.c
index 29d9d03..b70da50 100644
--- a/drivers/video/exynos/exynos_dp_reg.c
+++ b/drivers/video/exynos/exynos_dp_reg.c
@@ -14,8 +14,6 @@
 #include <linux/io.h>
 #include <linux/delay.h>
 
-#include <video/exynos_dp.h>
-
 #include "exynos_dp_core.h"
 #include "exynos_dp_reg.h"
 
diff --git a/include/video/exynos_dp.h b/include/video/exynos_dp.h
deleted file mode 100644
index bd8cabd..0000000
--- a/include/video/exynos_dp.h
+++ /dev/null
@@ -1,131 +0,0 @@
-/*
- * Samsung SoC DP device support
- *
- * Copyright (C) 2012 Samsung Electronics Co., Ltd.
- * Author: Jingoo Han <jg1.han at samsung.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef _EXYNOS_DP_H
-#define _EXYNOS_DP_H
-
-#define DP_TIMEOUT_LOOP_COUNT 100
-#define MAX_CR_LOOP 5
-#define MAX_EQ_LOOP 5
-
-enum link_rate_type {
-	LINK_RATE_1_62GBPS = 0x06,
-	LINK_RATE_2_70GBPS = 0x0a
-};
-
-enum link_lane_count_type {
-	LANE_COUNT1 = 1,
-	LANE_COUNT2 = 2,
-	LANE_COUNT4 = 4
-};
-
-enum link_training_state {
-	START,
-	CLOCK_RECOVERY,
-	EQUALIZER_TRAINING,
-	FINISHED,
-	FAILED
-};
-
-enum voltage_swing_level {
-	VOLTAGE_LEVEL_0,
-	VOLTAGE_LEVEL_1,
-	VOLTAGE_LEVEL_2,
-	VOLTAGE_LEVEL_3,
-};
-
-enum pre_emphasis_level {
-	PRE_EMPHASIS_LEVEL_0,
-	PRE_EMPHASIS_LEVEL_1,
-	PRE_EMPHASIS_LEVEL_2,
-	PRE_EMPHASIS_LEVEL_3,
-};
-
-enum pattern_set {
-	PRBS7,
-	D10_2,
-	TRAINING_PTN1,
-	TRAINING_PTN2,
-	DP_NONE
-};
-
-enum color_space {
-	COLOR_RGB,
-	COLOR_YCBCR422,
-	COLOR_YCBCR444
-};
-
-enum color_depth {
-	COLOR_6,
-	COLOR_8,
-	COLOR_10,
-	COLOR_12
-};
-
-enum color_coefficient {
-	COLOR_YCBCR601,
-	COLOR_YCBCR709
-};
-
-enum dynamic_range {
-	VESA,
-	CEA
-};
-
-enum pll_status {
-	PLL_UNLOCKED,
-	PLL_LOCKED
-};
-
-enum clock_recovery_m_value_type {
-	CALCULATED_M,
-	REGISTER_M
-};
-
-enum video_timing_recognition_type {
-	VIDEO_TIMING_FROM_CAPTURE,
-	VIDEO_TIMING_FROM_REGISTER
-};
-
-enum analog_power_block {
-	AUX_BLOCK,
-	CH0_BLOCK,
-	CH1_BLOCK,
-	CH2_BLOCK,
-	CH3_BLOCK,
-	ANALOG_TOTAL,
-	POWER_ALL
-};
-
-struct video_info {
-	char *name;
-
-	bool h_sync_polarity;
-	bool v_sync_polarity;
-	bool interlaced;
-
-	enum color_space color_space;
-	enum dynamic_range dynamic_range;
-	enum color_coefficient ycbcr_coeff;
-	enum color_depth color_depth;
-
-	enum link_rate_type link_rate;
-	enum link_lane_count_type lane_count;
-};
-
-struct exynos_dp_platdata {
-	struct video_info *video_info;
-
-	void (*phy_init)(void);
-	void (*phy_exit)(void);
-};
-
-#endif /* _EXYNOS_DP_H */
-- 
1.7.10.4




From jg1.han at samsung.com  Tue Jul  2 04:42:49 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Tue, 02 Jul 2013 17:42:49 +0900
Subject: [PATCH V4 4/4] video: exynos_dp: Use the generic PHY driver
Message-ID: <000d01ce7700$222a35a0$667ea0e0$@samsung.com>

Use the generic PHY API instead of the platform callback to control
the DP PHY.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
---
 .../devicetree/bindings/video/exynos_dp.txt        |   23 +++++---------------
 drivers/video/exynos/exynos_dp_core.c              |   16 ++++++++++----
 drivers/video/exynos/exynos_dp_core.h              |    2 ++
 3 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 84f10c1..022f4b6 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -1,17 +1,6 @@
 The Exynos display port interface should be configured based on
 the type of panel connected to it.
 
-We use two nodes:
-	-dp-controller node
-	-dptx-phy node(defined inside dp-controller node)
-
-For the DP-PHY initialization, we use the dptx-phy node.
-Required properties for dptx-phy:
-	-reg:
-		Base address of DP PHY register.
-	-samsung,enable-mask:
-		The bit-mask used to enable/disable DP PHY.
-
 For the Panel initialization, we read data from dp-controller node.
 Required properties for dp-controller:
 	-compatible:
@@ -25,6 +14,10 @@ Required properties for dp-controller:
 		from common clock binding: handle to dp clock.
 	-clock-names:
 		from common clock binding: Shall be "dp".
+	-phys:
+		from general PHY binding: the phandle for the PHY device.
+	-phy-names:
+		from general PHY binding: Should be "dp".
 	-interrupt-parent:
 		phandle to Interrupt combiner node.
 	-samsung,color-space:
@@ -67,12 +60,8 @@ SOC specific portion:
 		interrupt-parent = <&combiner>;
 		clocks = <&clock 342>;
 		clock-names = "dp";
-
-		dptx-phy {
-			reg = <0x10040720>;
-			samsung,enable-mask = <1>;
-		};
-
+		phys = <&dp_phy>;
+		phy-names = "dp";
 	};
 
 Board Specific portion:
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index 05fed7d..5e1a715 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -19,6 +19,7 @@
 #include <linux/interrupt.h>
 #include <linux/delay.h>
 #include <linux/of.h>
+#include <linux/phy/phy.h>
 
 #include "exynos_dp_core.h"
 
@@ -960,8 +961,11 @@ static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
 
 	dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
 	if (!dp_phy_node) {
-		dev_err(dp->dev, "could not find dptx-phy node\n");
-		return -ENODEV;
+		dp->phy = devm_phy_get(dp->dev, "dp");
+		if (IS_ERR(dp->phy))
+			return PTR_ERR(dp->phy);
+		else
+			return 0;
 	}
 
 	if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
@@ -992,7 +996,9 @@ err:
 
 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 {
-	if (dp->phy_addr) {
+	if (dp->phy) {
+		phy_power_on(dp->phy);
+	} else if (dp->phy_addr) {
 		u32 reg;
 
 		reg = __raw_readl(dp->phy_addr);
@@ -1003,7 +1009,9 @@ static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 
 static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
 {
-	if (dp->phy_addr) {
+	if (dp->phy) {
+		phy_power_off(dp->phy);
+	} else if (dp->phy_addr) {
 		u32 reg;
 
 		reg = __raw_readl(dp->phy_addr);
diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
index 56cfec8..87804b6 100644
--- a/drivers/video/exynos/exynos_dp_core.h
+++ b/drivers/video/exynos/exynos_dp_core.h
@@ -151,6 +151,8 @@ struct exynos_dp_device {
 	struct video_info	*video_info;
 	struct link_train	link_train;
 	struct work_struct	hotplug_work;
+
+	struct phy		*phy;
 };
 
 /* exynos_dp_reg.c */
-- 
1.7.10.4




From josephl at nvidia.com  Tue Jul  2 04:52:00 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 2 Jul 2013 16:52:00 +0800
Subject: [PATCH 07/32] arm: delete __cpuinit/__CPUINIT usage from all
 ARM users
In-Reply-To: <1372102237-8757-8-git-send-email-paul.gortmaker@windriver.com>
References: <1372102237-8757-1-git-send-email-paul.gortmaker@windriver.com>
 <1372102237-8757-8-git-send-email-paul.gortmaker@windriver.com>
Message-ID: <1372755120.2874.18.camel@jlo-ubuntu-64.nvidia.com>

Adding linux-tegra in Cc.

On Tue, 2013-06-25 at 03:30 +0800, Paul Gortmaker wrote:
> The __cpuinit type of throwaway sections might have made sense
> some time ago when RAM was more constrained, but now the savings
> do not offset the cost and complications.  For example, the fix in
> commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
> is a good example of the nasty type of bugs that can be created
> with improper use of the various __init prefixes.
> 
> After a discussion on LKML[1] it was decided that cpuinit should go
> the way of devinit and be phased out.  Once all the users are gone,
> we can then finally remove the macros themselves from linux/init.h.
> 
> Note that some harmless section mismatch warnings may result, since
> notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
> and are flagged as __cpuinit  -- so if we remove the __cpuinit from
> the arch specific callers, we will also get section mismatch warnings.
> As an intermediate step, we intend to turn the linux/init.h cpuinit
> related content into no-ops as early as possible, since that will get
> rid of these warnings.  In any case, they are temporary and harmless.
> 
> This removes all the ARM uses of the __cpuinit macros from C code,
> and all __CPUINIT from assembly code.  It also had two ".previous"
> section statements that were paired off against __CPUINIT
> (aka .section ".cpuinit.text") that also get removed here.
> 
> [1] https://lkml.org/lkml/2013/5/20/589
> 
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> ---
> 
> [This commit is part of the __cpuinit removal work.  If you don't see
>  any problems with it, then you don't have to do anything ; it will be
>  submitted with all the rest of the __cpuinit removal work.  On the
>  other hand, if you want to carry this patch in with your other pending
>  changes so as to handle conflicts with other pending work yourself, then
>  that is fine too, as the commits can largely be treated independently.
>  For more information, please see: https://lkml.org/lkml/2013/6/20/513 ]
> 

Hi Paul,

I just tested this series on Tegra platform. It looks broken CPU hotplug
function for Tegra at least. The CPU can't plug-in after unplugging. And
the system resume function also not working when "enable_nonboot_cpus".

Both of the issue cause system hang up. Are we missing something for
__cpuinit removal work?

Thanks,
Joseph



From linux at arm.linux.org.uk  Tue Jul  2 04:58:19 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 2 Jul 2013 09:58:19 +0100
Subject: [PATCH 07/32] arm: delete __cpuinit/__CPUINIT usage from all
 ARM users
In-Reply-To: <1372755120.2874.18.camel@jlo-ubuntu-64.nvidia.com>
References: <1372102237-8757-1-git-send-email-paul.gortmaker@windriver.com>
 <1372102237-8757-8-git-send-email-paul.gortmaker@windriver.com>
 <1372755120.2874.18.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <20130702085818.GD24642@n2100.arm.linux.org.uk>

On Tue, Jul 02, 2013 at 04:52:00PM +0800, Joseph Lo wrote:
> I just tested this series on Tegra platform. It looks broken CPU hotplug
> function for Tegra at least. The CPU can't plug-in after unplugging. And
> the system resume function also not working when "enable_nonboot_cpus".
> 
> Both of the issue cause system hang up. Are we missing something for
> __cpuinit removal work?

Check that any assembly code you're using where the __CPUINIT* marker has
been removed is not preceded by an __INIT or similar.   This code needs
to end up in the normal .text, .data or .bss sections now.


From voice.shen at atmel.com  Tue Jul  2 05:04:07 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Tue,  2 Jul 2013 17:04:07 +0800
Subject: [PATCH 0/2] ASoC: atmel-pcm: use generic dmaengine framework
Message-ID: <1372755849-19546-1-git-send-email-voice.shen@atmel.com>

this patch series is based on next-20130701

Bo Shen (2):
  ASoC: atmel_ssc_dai: move set dma data to startup callback
  ASoC: atmel-pcm: use generic dmaengine framework

 sound/soc/atmel/atmel-pcm-dma.c |  118 ++++++---------------------------------
 sound/soc/atmel/atmel_ssc_dai.c |   33 ++++++-----
 2 files changed, 32 insertions(+), 119 deletions(-)

-- 
1.7.9.5



From voice.shen at atmel.com  Tue Jul  2 05:04:08 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Tue,  2 Jul 2013 17:04:08 +0800
Subject: [PATCH 1/2] ASoC: atmel_ssc_dai: move set dma data to startup callback
In-Reply-To: <1372755849-19546-1-git-send-email-voice.shen@atmel.com>
References: <1372755849-19546-1-git-send-email-voice.shen@atmel.com>
Message-ID: <1372755849-19546-2-git-send-email-voice.shen@atmel.com>

move set dma data to startup callback function, if the set dma
data exist in hw_params callback, so the dma data only usable when
call hw_params, if want use it before hw_params callback, it will
cause NULL pointer access oops

Signed-off-by: Bo Shen <voice.shen at atmel.com>
---
 sound/soc/atmel/atmel_ssc_dai.c |   33 ++++++++++++++++-----------------
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index f3fdfa0..6cf9cf1 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -196,15 +196,27 @@ static int atmel_ssc_startup(struct snd_pcm_substream *substream,
 			     struct snd_soc_dai *dai)
 {
 	struct atmel_ssc_info *ssc_p = &ssc_info[dai->id];
-	int dir_mask;
+	struct atmel_pcm_dma_params *dma_params;
+	int dir, dir_mask;
 
 	pr_debug("atmel_ssc_startup: SSC_SR=0x%u\n",
 		ssc_readl(ssc_p->ssc->regs, SR));
 
-	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+		dir = 0;
 		dir_mask = SSC_DIR_MASK_PLAYBACK;
-	else
+	} else {
+		dir = 1;
 		dir_mask = SSC_DIR_MASK_CAPTURE;
+	}
+
+	dma_params = &ssc_dma_params[dai->id][dir];
+	dma_params->ssc = ssc_p->ssc;
+	dma_params->substream = substream;
+
+	ssc_p->dma_params[dir] = dma_params;
+
+	snd_soc_dai_set_dma_data(dai, substream, dma_params);
 
 	spin_lock_irq(&ssc_p->lock);
 	if (ssc_p->dir_mask & dir_mask) {
@@ -325,7 +337,6 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
 	struct snd_pcm_hw_params *params,
 	struct snd_soc_dai *dai)
 {
-	struct snd_soc_pcm_runtime *rtd = snd_pcm_substream_chip(substream);
 	int id = dai->id;
 	struct atmel_ssc_info *ssc_p = &ssc_info[id];
 	struct atmel_pcm_dma_params *dma_params;
@@ -344,19 +355,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
 	else
 		dir = 1;
 
-	dma_params = &ssc_dma_params[id][dir];
-	dma_params->ssc = ssc_p->ssc;
-	dma_params->substream = substream;
-
-	ssc_p->dma_params[dir] = dma_params;
-
-	/*
-	 * The snd_soc_pcm_stream->dma_data field is only used to communicate
-	 * the appropriate DMA parameters to the pcm driver hw_params()
-	 * function.  It should not be used for other purposes
-	 * as it is common to all substreams.
-	 */
-	snd_soc_dai_set_dma_data(rtd->cpu_dai, substream, dma_params);
+	dma_params = ssc_p->dma_params[dir];
 
 	channels = params_channels(params);
 
-- 
1.7.9.5



From voice.shen at atmel.com  Tue Jul  2 05:04:09 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Tue,  2 Jul 2013 17:04:09 +0800
Subject: [PATCH 2/2] ASoC: atmel-pcm: use generic dmaengine framework
In-Reply-To: <1372755849-19546-1-git-send-email-voice.shen@atmel.com>
References: <1372755849-19546-1-git-send-email-voice.shen@atmel.com>
Message-ID: <1372755849-19546-3-git-send-email-voice.shen@atmel.com>

Align atmel pcm to use ASoC generic dmaengine framework

Signed-off-by: Bo Shen <voice.shen at atmel.com>

---
 sound/soc/atmel/atmel-pcm-dma.c |  118 ++++++---------------------------------
 1 file changed, 16 insertions(+), 102 deletions(-)

diff --git a/sound/soc/atmel/atmel-pcm-dma.c b/sound/soc/atmel/atmel-pcm-dma.c
index 1d38fd0..0f6c701 100644
--- a/sound/soc/atmel/atmel-pcm-dma.c
+++ b/sound/soc/atmel/atmel-pcm-dma.c
@@ -89,138 +89,52 @@ static void atmel_pcm_dma_irq(u32 ssc_sr,
 	}
 }
 
-/*--------------------------------------------------------------------------*\
- * DMAENGINE operations
-\*--------------------------------------------------------------------------*/
-static bool filter(struct dma_chan *chan, void *slave)
-{
-	struct at_dma_slave *sl = slave;
-
-	if (sl->dma_dev == chan->device->dev) {
-		chan->private = sl;
-		return true;
-	} else {
-		return false;
-	}
-}
-
 static int atmel_pcm_configure_dma(struct snd_pcm_substream *substream,
-	struct snd_pcm_hw_params *params, struct atmel_pcm_dma_params *prtd)
+	struct snd_pcm_hw_params *params, struct dma_slave_config *slave_config)
 {
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct atmel_pcm_dma_params *prtd;
 	struct ssc_device *ssc;
-	struct dma_chan *dma_chan;
-	struct dma_slave_config slave_config;
 	int ret;
 
+	prtd = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
 	ssc = prtd->ssc;
 
-	ret = snd_hwparams_to_dma_slave_config(substream, params,
-			&slave_config);
+	ret = snd_hwparams_to_dma_slave_config(substream, params, slave_config);
 	if (ret) {
 		pr_err("atmel-pcm: hwparams to dma slave configure failed\n");
 		return ret;
 	}
 
 	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-		slave_config.dst_addr = (dma_addr_t)ssc->phybase + SSC_THR;
-		slave_config.dst_maxburst = 1;
+		slave_config->dst_addr = (dma_addr_t)ssc->phybase + SSC_THR;
+		slave_config->dst_maxburst = 1;
 	} else {
-		slave_config.src_addr = (dma_addr_t)ssc->phybase + SSC_RHR;
-		slave_config.src_maxburst = 1;
-	}
-
-	dma_chan = snd_dmaengine_pcm_get_chan(substream);
-	if (dmaengine_slave_config(dma_chan, &slave_config)) {
-		pr_err("atmel-pcm: failed to configure dma channel\n");
-		ret = -EBUSY;
-		return ret;
-	}
-
-	return 0;
-}
-
-static int atmel_pcm_hw_params(struct snd_pcm_substream *substream,
-	struct snd_pcm_hw_params *params)
-{
-	struct snd_soc_pcm_runtime *rtd = substream->private_data;
-	struct atmel_pcm_dma_params *prtd;
-	struct ssc_device *ssc;
-	struct at_dma_slave *sdata = NULL;
-	int ret;
-
-	snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer);
-
-	prtd = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
-	ssc = prtd->ssc;
-	if (ssc->pdev)
-		sdata = ssc->pdev->dev.platform_data;
-
-	ret = snd_dmaengine_pcm_open_request_chan(substream, filter, sdata);
-	if (ret) {
-		pr_err("atmel-pcm: dmaengine pcm open failed\n");
-		return -EINVAL;
-	}
-
-	ret = atmel_pcm_configure_dma(substream, params, prtd);
-	if (ret) {
-		pr_err("atmel-pcm: failed to configure dmai\n");
-		goto err;
+		slave_config->src_addr = (dma_addr_t)ssc->phybase + SSC_RHR;
+		slave_config->src_maxburst = 1;
 	}
 
 	prtd->dma_intr_handler = atmel_pcm_dma_irq;
 
 	return 0;
-err:
-	snd_dmaengine_pcm_close_release_chan(substream);
-	return ret;
 }
 
-static int atmel_pcm_dma_prepare(struct snd_pcm_substream *substream)
-{
-	struct snd_soc_pcm_runtime *rtd = substream->private_data;
-	struct atmel_pcm_dma_params *prtd;
-
-	prtd = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
-
-	ssc_writex(prtd->ssc->regs, SSC_IER, prtd->mask->ssc_error);
-	ssc_writex(prtd->ssc->regs, SSC_CR, prtd->mask->ssc_enable);
-
-	return 0;
-}
-
-static int atmel_pcm_open(struct snd_pcm_substream *substream)
-{
-	snd_soc_set_runtime_hwparams(substream, &atmel_pcm_dma_hardware);
-
-	return 0;
-}
-
-static struct snd_pcm_ops atmel_pcm_ops = {
-	.open		= atmel_pcm_open,
-	.close		= snd_dmaengine_pcm_close_release_chan,
-	.ioctl		= snd_pcm_lib_ioctl,
-	.hw_params	= atmel_pcm_hw_params,
-	.prepare	= atmel_pcm_dma_prepare,
-	.trigger	= snd_dmaengine_pcm_trigger,
-	.pointer	= snd_dmaengine_pcm_pointer_no_residue,
-	.mmap		= atmel_pcm_mmap,
-};
-
-static struct snd_soc_platform_driver atmel_soc_platform = {
-	.ops		= &atmel_pcm_ops,
-	.pcm_new	= atmel_pcm_new,
-	.pcm_free	= atmel_pcm_free,
+static const struct snd_dmaengine_pcm_config atmel_dmaengine_pcm_config = {
+	.prepare_slave_config = atmel_pcm_configure_dma,
+	.pcm_hardware = &atmel_pcm_dma_hardware,
+	.prealloc_buffer_size = ATMEL_SSC_DMABUF_SIZE,
 };
 
 int atmel_pcm_dma_platform_register(struct device *dev)
 {
-	return snd_soc_register_platform(dev, &atmel_soc_platform);
+	return snd_dmaengine_pcm_register(dev, &atmel_dmaengine_pcm_config,
+			SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
 }
 EXPORT_SYMBOL(atmel_pcm_dma_platform_register);
 
 void atmel_pcm_dma_platform_unregister(struct device *dev)
 {
-	snd_soc_unregister_platform(dev);
+	snd_dmaengine_pcm_unregister(dev);
 }
 EXPORT_SYMBOL(atmel_pcm_dma_platform_unregister);
 
-- 
1.7.9.5



From voice.shen at atmel.com  Tue Jul  2 05:11:03 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Tue, 2 Jul 2013 17:11:03 +0800
Subject: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
In-Reply-To: <CACQ1gAgcc=j3kmcpjp8bbdHhxr_k=h8jJs6R_paJbPUMv74uGg@mail.gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-2-git-send-email-richard.genoud@gmail.com>
 <51D24299.9050209@atmel.com>
 <CACQ1gAgcc=j3kmcpjp8bbdHhxr_k=h8jJs6R_paJbPUMv74uGg@mail.gmail.com>
Message-ID: <51D29927.80900@atmel.com>

Hi Richard,

On 7/2/2013 16:13, Richard Genoud wrote:
>> Please hold on of this, as to the ASoC dmaengine will deal with this. So, we
>> >not need do it manually.
>> >
>> >Now, I am working on it. And will send out the patch soon after testing OK.
> Ok, I stay tuned !

I think you can go on working with the two patches I send just now.
[1]: ASoC: atmel_ssc_dai: move set dma data to startup callback
https://patchwork.kernel.org/patch/2811241/

[2]: ASoC: atmel-pcm: use generic dmaengine framework
https://patchwork.kernel.org/patch/2811261/

I use your patches 4 ~ 8 do a quick testing, it works. Please note the 
name of asound.state under /etc in your rootfs should the same with 
atmel,model in patch 6.

> Thanks !
>
> Best regards,
> Richard

Best Regards,
Bo Shen



From broonie at kernel.org  Tue Jul  2 05:25:07 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 2 Jul 2013 10:25:07 +0100
Subject: [PATCH 3/3] ARM: dts: Add WM1811A audio CODEC to Arndale bindings
In-Reply-To: <51D26360.2080708@linaro.org>
References: <1372714599-17588-1-git-send-email-broonie@kernel.org>
 <1372714599-17588-3-git-send-email-broonie@kernel.org>
 <51D26360.2080708@linaro.org>
Message-ID: <20130702092507.GV27646@sirena.org.uk>

On Tue, Jul 02, 2013 at 10:51:36AM +0530, Tushar Behera wrote:

> Arndale board also comes with two other audio codec boards - ALC5631Q
> and AK4678. Different audio codec boards came with different shipments.

This is the default though and since they didn't bother providing any
way of identifying the modules we just have to put them all in the
device tree and hope that the individual CODEC drivers can do runtime
identification (the WM1811A can but I don't know about the other two,
nobody supported them upstream).
-------------- 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/20130702/4a28b8a7/attachment-0001.sig>

From weiyj.lk at gmail.com  Tue Jul  2 05:26:21 2013
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Tue, 2 Jul 2013 17:26:21 +0800
Subject: [PATCH] ASoC: brownstone: add .owner to struct snd_soc_card
Message-ID: <CAPgLHd-VN4BiM=cEkFF4EgbL7iqR1XrhEzBiKyoJBVnzKspHJg@mail.gmail.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Add missing .owner of struct snd_soc_card. This prevents the
module from being removed from underneath its users.

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
 sound/soc/pxa/brownstone.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/pxa/brownstone.c b/sound/soc/pxa/brownstone.c
index 4ad7609..e582c05 100644
--- a/sound/soc/pxa/brownstone.c
+++ b/sound/soc/pxa/brownstone.c
@@ -129,6 +129,7 @@ static struct snd_soc_dai_link brownstone_wm8994_dai[] = {
 /* audio machine driver */
 static struct snd_soc_card brownstone = {
 	.name         = "brownstone",
+	.owner        = THIS_MODULE,
 	.dai_link     = brownstone_wm8994_dai,
 	.num_links    = ARRAY_SIZE(brownstone_wm8994_dai),
 



From weiyj.lk at gmail.com  Tue Jul  2 05:26:40 2013
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Tue, 2 Jul 2013 17:26:40 +0800
Subject: [PATCH] ASoC: ttc_dkb: add .owner to struct snd_soc_card
Message-ID: <CAPgLHd_CJUYf8Ry=J9Y8ZPSrCgqPLTj74rDr__bxoymQ8GR_1A@mail.gmail.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Add missing .owner of struct snd_soc_card. This prevents the
module from being removed from underneath its users.

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
 sound/soc/pxa/ttc-dkb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/pxa/ttc-dkb.c b/sound/soc/pxa/ttc-dkb.c
index f4ea4f6..13c9ee0 100644
--- a/sound/soc/pxa/ttc-dkb.c
+++ b/sound/soc/pxa/ttc-dkb.c
@@ -122,6 +122,7 @@ static struct snd_soc_dai_link ttc_pm860x_hifi_dai[] = {
 /* ttc/td audio machine driver */
 static struct snd_soc_card ttc_dkb_card = {
 	.name = "ttc-dkb-hifi",
+	.owner = THIS_MODULE,
 	.dai_link = ttc_pm860x_hifi_dai,
 	.num_links = ARRAY_SIZE(ttc_pm860x_hifi_dai),
 



From magnus.damm at gmail.com  Tue Jul  2 05:27:25 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 02 Jul 2013 18:27:25 +0900
Subject: [PATCH 00/08] ARM: shmobile: EMEV2 and KZM9D update
Message-ID: <20130702092725.32066.54861.sendpatchset@w520>

ARM: shmobile: EMEV2 and KZM9D update

[PATCH 01/08] ARM: shmobile: Remove unused EMEV2/KZM9D early console
[PATCH 02/08] ARM: shmobile: Update KZM9D dts command line
[PATCH 03/08] ARM: shmobile: Make EMEV2 platform devices more compact
[PATCH 04/08] ARM: shmobile: Add GIO to EMEV2 dtsi
[PATCH 05/08] ARM: shmobile: Use DT for GIC on EMEV2 and KZM9D
[PATCH 06/08] ARM: shmobile: Use DT for SMP on EMEV2 and KZM9D
[PATCH 07/08] ARM: shmobile: EMEV2 map_io update
[PATCH 08/08] ARM: shmobile: Disconnect EMEV2 SMP code from clocks

Several minor updates for the EMEV2 SoC and the KZM9D board:
- Get rid of early console - the 8250-em driver does not support it
- Update command line in DTS and remove old cruft
- Make the EMEV2 platform devices more compact
- Add GIO device nodes to the EMEV2 dtsi
- Use DT for GIC and SMP for both regular KZM9D board code and DT
- Reduce the size of the EMEV2 map_io - SCU is still however needed
- Allow EMEV2 SMP to operate without legacy clock bits

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Written against renesas.git renesas-next-20130702

 arch/arm/boot/dts/emev2-kzm9d.dts           |    2 
 arch/arm/boot/dts/emev2.dtsi                |   59 ++++
 arch/arm/mach-shmobile/board-kzm9d.c        |    4 
 arch/arm/mach-shmobile/clock-emev2.c        |   18 -
 arch/arm/mach-shmobile/include/mach/emev2.h |    4 
 arch/arm/mach-shmobile/setup-emev2.c        |  374 ++++-----------------------
 arch/arm/mach-shmobile/smp-emev2.c          |   28 --
 7 files changed, 142 insertions(+), 347 deletions(-)


From magnus.damm at gmail.com  Tue Jul  2 05:27:33 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 02 Jul 2013 18:27:33 +0900
Subject: [PATCH 01/08] ARM: shmobile: Remove unused EMEV2/KZM9D early console
In-Reply-To: <20130702092725.32066.54861.sendpatchset@w520>
References: <20130702092725.32066.54861.sendpatchset@w520>
Message-ID: <20130702092733.32066.50335.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove EMEV2 early console code from KZM9D and instead
rely on console setup during regular platform device
probe time. This makes the DT code and the KZM9D board
support behave the same.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-kzm9d.c        |    2 +-
 arch/arm/mach-shmobile/include/mach/emev2.h |    2 +-
 arch/arm/mach-shmobile/setup-emev2.c        |   24 +++---------------------
 3 files changed, 5 insertions(+), 23 deletions(-)

--- 0001/arch/arm/mach-shmobile/board-kzm9d.c
+++ work/arch/arm/mach-shmobile/board-kzm9d.c	2013-07-01 20:07:13.000000000 +0900
@@ -85,7 +85,7 @@ static const char *kzm9d_boards_compat_d
 DT_MACHINE_START(KZM9D_DT, "kzm9d")
 	.smp		= smp_ops(emev2_smp_ops),
 	.map_io		= emev2_map_io,
-	.init_early	= emev2_add_early_devices,
+	.init_early	= emev2_init_delay,
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= emev2_init_irq,
 	.init_machine	= kzm9d_add_standard_devices,
--- 0001/arch/arm/mach-shmobile/include/mach/emev2.h
+++ work/arch/arm/mach-shmobile/include/mach/emev2.h	2013-07-01 20:06:35.000000000 +0900
@@ -3,7 +3,7 @@
 
 extern void emev2_map_io(void);
 extern void emev2_init_irq(void);
-extern void emev2_add_early_devices(void);
+extern void emev2_init_delay(void);
 extern void emev2_add_standard_devices(void);
 extern void emev2_clock_init(void);
 extern void emev2_set_boot_vector(unsigned long value);
--- 0012/arch/arm/mach-shmobile/setup-emev2.c
+++ work/arch/arm/mach-shmobile/setup-emev2.c	2013-07-01 20:08:10.000000000 +0900
@@ -375,14 +375,11 @@ static struct platform_device pmu_device
 	.resource	= pmu_resources,
 };
 
-static struct platform_device *emev2_early_devices[] __initdata = {
+static struct platform_device *emev2_devices[] __initdata = {
 	&uart0_device,
 	&uart1_device,
 	&uart2_device,
 	&uart3_device,
-};
-
-static struct platform_device *emev2_late_devices[] __initdata = {
 	&sti_device,
 	&gio0_device,
 	&gio1_device,
@@ -396,29 +393,14 @@ void __init emev2_add_standard_devices(v
 {
 	emev2_clock_init();
 
-	platform_add_devices(emev2_early_devices,
-			     ARRAY_SIZE(emev2_early_devices));
-
-	platform_add_devices(emev2_late_devices,
-			     ARRAY_SIZE(emev2_late_devices));
+	platform_add_devices(emev2_devices, ARRAY_SIZE(emev2_devices));
 }
 
-static void __init emev2_init_delay(void)
+void __init emev2_init_delay(void)
 {
 	shmobile_setup_delay(533, 1, 3); /* Cortex-A9 @ 533MHz */
 }
 
-void __init emev2_add_early_devices(void)
-{
-	emev2_init_delay();
-
-	early_platform_add_devices(emev2_early_devices,
-				   ARRAY_SIZE(emev2_early_devices));
-
-	/* setup early console here as well */
-	shmobile_setup_console();
-}
-
 void __init emev2_init_irq(void)
 {
 	void __iomem *gic_dist_base;


From magnus.damm at gmail.com  Tue Jul  2 05:27:41 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 02 Jul 2013 18:27:41 +0900
Subject: [PATCH 02/08] ARM: shmobile: Update KZM9D dts command line
In-Reply-To: <20130702092725.32066.54861.sendpatchset@w520>
References: <20130702092725.32066.54861.sendpatchset@w520>
Message-ID: <20130702092741.32066.76218.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Update the KZM9D DTS command line to remove following cruft:
 - console=tty0 - no graphic support upstream anyway
 - earlyprintk= - not supported by the 8250-em driver anyway
 - mem= - this is provided via DT anyway

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/boot/dts/emev2-kzm9d.dts |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 0001/arch/arm/boot/dts/emev2-kzm9d.dts
+++ work/arch/arm/boot/dts/emev2-kzm9d.dts	2013-07-02 17:07:18.000000000 +0900
@@ -21,6 +21,6 @@
 	};
 
 	chosen {
-		bootargs = "console=tty0 console=ttyS1,115200n81 earlyprintk=serial8250-em.1,115200n81 mem=128M at 0x40000000 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096";
+		bootargs = "console=ttyS1,115200n81 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096";
 	};
 };


From magnus.damm at gmail.com  Tue Jul  2 05:27:49 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 02 Jul 2013 18:27:49 +0900
Subject: [PATCH 03/08] ARM: shmobile: Make EMEV2 platform devices more compact
In-Reply-To: <20130702092725.32066.54861.sendpatchset@w520>
References: <20130702092725.32066.54861.sendpatchset@w520>
Message-ID: <20130702092749.32066.62026.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Convert the EMEV2 SoC device setup code from using very
verbose resources and static platform devices to the
same style as more recent boards. This reduces the size
of the code.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Depends on "[PATCH] ARM: shmobile: emev2 GIO3 resource fix"

 arch/arm/mach-shmobile/setup-emev2.c |  327 ++++++----------------------------
 1 file changed, 64 insertions(+), 263 deletions(-)

--- 0016/arch/arm/mach-shmobile/setup-emev2.c
+++ work/arch/arm/mach-shmobile/setup-emev2.c	2013-07-01 20:31:49.000000000 +0900
@@ -62,102 +62,40 @@ void __init emev2_map_io(void)
 
 /* UART */
 static struct resource uart0_resources[] = {
-	[0]	= {
-		.start	= 0xe1020000,
-		.end	= 0xe1020037,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1]	= {
-		.start	= 40,
-		.flags	= IORESOURCE_IRQ,
-	}
-};
-
-static struct platform_device uart0_device = {
-	.name		= "serial8250-em",
-	.id		= 0,
-	.num_resources	= ARRAY_SIZE(uart0_resources),
-	.resource	= uart0_resources,
+	DEFINE_RES_MEM(0xe1020000, 0x38),
+	DEFINE_RES_IRQ(40),
 };
 
 static struct resource uart1_resources[] = {
-	[0]	= {
-		.start	= 0xe1030000,
-		.end	= 0xe1030037,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1]	= {
-		.start	= 41,
-		.flags	= IORESOURCE_IRQ,
-	}
-};
-
-static struct platform_device uart1_device = {
-	.name		= "serial8250-em",
-	.id		= 1,
-	.num_resources	= ARRAY_SIZE(uart1_resources),
-	.resource	= uart1_resources,
+	DEFINE_RES_MEM(0xe1030000, 0x38),
+	DEFINE_RES_IRQ(41),
 };
 
 static struct resource uart2_resources[] = {
-	[0]	= {
-		.start	= 0xe1040000,
-		.end	= 0xe1040037,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1]	= {
-		.start	= 42,
-		.flags	= IORESOURCE_IRQ,
-	}
-};
-
-static struct platform_device uart2_device = {
-	.name		= "serial8250-em",
-	.id		= 2,
-	.num_resources	= ARRAY_SIZE(uart2_resources),
-	.resource	= uart2_resources,
+	DEFINE_RES_MEM(0xe1040000, 0x38),
+	DEFINE_RES_IRQ(42),
 };
 
 static struct resource uart3_resources[] = {
-	[0]	= {
-		.start	= 0xe1050000,
-		.end	= 0xe1050037,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1]	= {
-		.start	= 43,
-		.flags	= IORESOURCE_IRQ,
-	}
-};
-
-static struct platform_device uart3_device = {
-	.name		= "serial8250-em",
-	.id		= 3,
-	.num_resources	= ARRAY_SIZE(uart3_resources),
-	.resource	= uart3_resources,
+	DEFINE_RES_MEM(0xe1050000, 0x38),
+	DEFINE_RES_IRQ(43),
 };
 
+#define emev2_register_uart(idx)					\
+	platform_device_register_simple("serial8250-em", idx,		\
+					uart##idx##_resources,		\
+					ARRAY_SIZE(uart##idx##_resources))
+
 /* STI */
 static struct resource sti_resources[] = {
-	[0] = {
-		.name	= "STI",
-		.start	= 0xe0180000,
-		.end	= 0xe0180053,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= 157,
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device sti_device = {
-	.name		= "em_sti",
-	.id		= 0,
-	.resource	= sti_resources,
-	.num_resources	= ARRAY_SIZE(sti_resources),
+	DEFINE_RES_MEM(0xe0180000, 0x54),
+	DEFINE_RES_IRQ(157),
 };
 
+#define emev2_register_sti()					\
+	platform_device_register_simple("em_sti", 0,		\
+					sti_resources,		\
+					ARRAY_SIZE(sti_resources))
 
 /* GIO */
 static struct gpio_em_config gio0_config = {
@@ -167,36 +105,10 @@ static struct gpio_em_config gio0_config
 };
 
 static struct resource gio0_resources[] = {
-	[0] = {
-		.name	= "GIO_000",
-		.start	= 0xe0050000,
-		.end	= 0xe005002b,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.name	= "GIO_000",
-		.start	= 0xe0050040,
-		.end	= 0xe005005f,
-		.flags	= IORESOURCE_MEM,
-	},
-	[2] = {
-		.start	= 99,
-		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
-		.start	= 100,
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device gio0_device = {
-	.name		= "em_gio",
-	.id		= 0,
-	.resource	= gio0_resources,
-	.num_resources	= ARRAY_SIZE(gio0_resources),
-	.dev		= {
-		.platform_data	= &gio0_config,
-	},
+	DEFINE_RES_MEM(0xe0050000, 0x2c),
+	DEFINE_RES_MEM(0xe0050040, 0x20),
+	DEFINE_RES_IRQ(99),
+	DEFINE_RES_IRQ(100),
 };
 
 static struct gpio_em_config gio1_config = {
@@ -206,36 +118,10 @@ static struct gpio_em_config gio1_config
 };
 
 static struct resource gio1_resources[] = {
-	[0] = {
-		.name	= "GIO_032",
-		.start	= 0xe0050080,
-		.end	= 0xe00500ab,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.name	= "GIO_032",
-		.start	= 0xe00500c0,
-		.end	= 0xe00500df,
-		.flags	= IORESOURCE_MEM,
-	},
-	[2] = {
-		.start	= 101,
-		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
-		.start	= 102,
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device gio1_device = {
-	.name		= "em_gio",
-	.id		= 1,
-	.resource	= gio1_resources,
-	.num_resources	= ARRAY_SIZE(gio1_resources),
-	.dev		= {
-		.platform_data	= &gio1_config,
-	},
+	DEFINE_RES_MEM(0xe0050080, 0x2c),
+	DEFINE_RES_MEM(0xe00500c0, 0x20),
+	DEFINE_RES_IRQ(101),
+	DEFINE_RES_IRQ(102),
 };
 
 static struct gpio_em_config gio2_config = {
@@ -245,36 +131,10 @@ static struct gpio_em_config gio2_config
 };
 
 static struct resource gio2_resources[] = {
-	[0] = {
-		.name	= "GIO_064",
-		.start	= 0xe0050100,
-		.end	= 0xe005012b,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.name	= "GIO_064",
-		.start	= 0xe0050140,
-		.end	= 0xe005015f,
-		.flags	= IORESOURCE_MEM,
-	},
-	[2] = {
-		.start	= 103,
-		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
-		.start	= 104,
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device gio2_device = {
-	.name		= "em_gio",
-	.id		= 2,
-	.resource	= gio2_resources,
-	.num_resources	= ARRAY_SIZE(gio2_resources),
-	.dev		= {
-		.platform_data	= &gio2_config,
-	},
+	DEFINE_RES_MEM(0xe0050100, 0x2c),
+	DEFINE_RES_MEM(0xe0050140, 0x20),
+	DEFINE_RES_IRQ(103),
+	DEFINE_RES_IRQ(104),
 };
 
 static struct gpio_em_config gio3_config = {
@@ -284,36 +144,10 @@ static struct gpio_em_config gio3_config
 };
 
 static struct resource gio3_resources[] = {
-	[0] = {
-		.name	= "GIO_096",
-		.start	= 0xe0050180,
-		.end	= 0xe00501ab,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.name	= "GIO_096",
-		.start	= 0xe00501c0,
-		.end	= 0xe00501df,
-		.flags	= IORESOURCE_MEM,
-	},
-	[2] = {
-		.start	= 105,
-		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
-		.start	= 106,
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device gio3_device = {
-	.name		= "em_gio",
-	.id		= 3,
-	.resource	= gio3_resources,
-	.num_resources	= ARRAY_SIZE(gio3_resources),
-	.dev		= {
-		.platform_data	= &gio3_config,
-	},
+	DEFINE_RES_MEM(0xe0050180, 0x2c),
+	DEFINE_RES_MEM(0xe00501c0, 0x20),
+	DEFINE_RES_IRQ(105),
+	DEFINE_RES_IRQ(106),
 };
 
 static struct gpio_em_config gio4_config = {
@@ -323,77 +157,44 @@ static struct gpio_em_config gio4_config
 };
 
 static struct resource gio4_resources[] = {
-	[0] = {
-		.name	= "GIO_128",
-		.start	= 0xe0050200,
-		.end	= 0xe005022b,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.name	= "GIO_128",
-		.start	= 0xe0050240,
-		.end	= 0xe005025f,
-		.flags	= IORESOURCE_MEM,
-	},
-	[2] = {
-		.start	= 107,
-		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
-		.start	= 108,
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device gio4_device = {
-	.name		= "em_gio",
-	.id		= 4,
-	.resource	= gio4_resources,
-	.num_resources	= ARRAY_SIZE(gio4_resources),
-	.dev		= {
-		.platform_data	= &gio4_config,
-	},
+	DEFINE_RES_MEM(0xe0050200, 0x2c),
+	DEFINE_RES_MEM(0xe0050240, 0x20),
+	DEFINE_RES_IRQ(107),
+	DEFINE_RES_IRQ(108),
 };
 
+#define emev2_register_gio(idx)						\
+	platform_device_register_resndata(&platform_bus, "em_gio",	\
+					  idx, gio##idx##_resources,	\
+					  ARRAY_SIZE(gio##idx##_resources), \
+					  &gio##idx##_config,		\
+					  sizeof(struct gpio_em_config))
+
 static struct resource pmu_resources[] = {
-	[0] = {
-		.start	= 152,
-		.end	= 152,
-		.flags	= IORESOURCE_IRQ,
-	},
-	[1] = {
-		.start	= 153,
-		.end	= 153,
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device pmu_device = {
-	.name		= "arm-pmu",
-	.id		= -1,
-	.num_resources	= ARRAY_SIZE(pmu_resources),
-	.resource	= pmu_resources,
-};
-
-static struct platform_device *emev2_devices[] __initdata = {
-	&uart0_device,
-	&uart1_device,
-	&uart2_device,
-	&uart3_device,
-	&sti_device,
-	&gio0_device,
-	&gio1_device,
-	&gio2_device,
-	&gio3_device,
-	&gio4_device,
-	&pmu_device,
+	DEFINE_RES_IRQ(152),
+	DEFINE_RES_IRQ(153),
 };
 
+#define emev2_register_pmu()					\
+	platform_device_register_simple("arm-pmu", -1,		\
+					pmu_resources,		\
+					ARRAY_SIZE(pmu_resources))
+
 void __init emev2_add_standard_devices(void)
 {
 	emev2_clock_init();
 
-	platform_add_devices(emev2_devices, ARRAY_SIZE(emev2_devices));
+	emev2_register_uart(0);
+	emev2_register_uart(1);
+	emev2_register_uart(2);
+	emev2_register_uart(3);
+	emev2_register_sti();
+	emev2_register_gio(0);
+	emev2_register_gio(1);
+	emev2_register_gio(2);
+	emev2_register_gio(3);
+	emev2_register_gio(4);
+	emev2_register_pmu();
 }
 
 void __init emev2_init_delay(void)


From magnus.damm at gmail.com  Tue Jul  2 05:27:57 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 02 Jul 2013 18:27:57 +0900
Subject: [PATCH 04/08] ARM: shmobile: Add GIO to EMEV2 dtsi
In-Reply-To: <20130702092725.32066.54861.sendpatchset@w520>
References: <20130702092725.32066.54861.sendpatchset@w520>
Message-ID: <20130702092757.32066.58136.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Add GIO0->GIO4 device nodes to the EMEV2 dtsi file.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/boot/dts/emev2.dtsi |   59 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

--- 0001/arch/arm/boot/dts/emev2.dtsi
+++ work/arch/arm/boot/dts/emev2.dtsi	2013-07-02 16:27:34.000000000 +0900
@@ -14,6 +14,14 @@
 	compatible = "renesas,emev2";
 	interrupt-parent = <&gic>;
 
+	aliases {
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
+		gpio4 = &gpio4;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
@@ -67,4 +75,55 @@
 		reg = <0xe1050000 0x38>;
 		interrupts = <0 11 0>;
 	};
+
+	gpio0: gpio at e0050000 {
+		compatible = "renesas,em-gio";
+		reg = <0xe0050000 0x2c>, <0xe0050040 0x20>;
+		interrupts = <0 67 0>, <0 68 0>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ngpios = <32>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+	gpio1: gpio at e0050080 {
+		compatible = "renesas,em-gio";
+		reg = <0xe0050080 0x2c>, <0xe00500c0 0x20>;
+		interrupts = <0 69 0>, <0 70 0>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ngpios = <32>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+	gpio2: gpio at e0050100 {
+		compatible = "renesas,em-gio";
+		reg = <0xe0050100 0x2c>, <0xe0050140 0x20>;
+		interrupts = <0 71 0>, <0 72 0>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ngpios = <32>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+	gpio3: gpio at e0050180 {
+		compatible = "renesas,em-gio";
+		reg = <0xe0050180 0x2c>, <0xe00501c0 0x20>;
+		interrupts = <0 73 0>, <0 74 0>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ngpios = <32>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+	gpio4: gpio at e0050200 {
+		compatible = "renesas,em-gio";
+		reg = <0xe0050200 0x2c>, <0xe0050240 0x20>;
+		interrupts = <0 75 0>, <0 76 0>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ngpios = <31>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
 };


From magnus.damm at gmail.com  Tue Jul  2 05:28:06 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 02 Jul 2013 18:28:06 +0900
Subject: [PATCH 05/08] ARM: shmobile: Use DT for GIC on EMEV2 and KZM9D
In-Reply-To: <20130702092725.32066.54861.sendpatchset@w520>
References: <20130702092725.32066.54861.sendpatchset@w520>
Message-ID: <20130702092806.32066.58281.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove the C version of the EMEV2 GIC setup code,
instead rely on GIC information provided by DT.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-kzm9d.c        |    2 --
 arch/arm/mach-shmobile/include/mach/emev2.h |    1 -
 arch/arm/mach-shmobile/setup-emev2.c        |   15 ---------------
 3 files changed, 18 deletions(-)

--- 0002/arch/arm/mach-shmobile/board-kzm9d.c
+++ work/arch/arm/mach-shmobile/board-kzm9d.c	2013-07-02 15:01:32.000000000 +0900
@@ -86,8 +86,6 @@ DT_MACHINE_START(KZM9D_DT, "kzm9d")
 	.smp		= smp_ops(emev2_smp_ops),
 	.map_io		= emev2_map_io,
 	.init_early	= emev2_init_delay,
-	.nr_irqs	= NR_IRQS_LEGACY,
-	.init_irq	= emev2_init_irq,
 	.init_machine	= kzm9d_add_standard_devices,
 	.init_late	= shmobile_init_late,
 	.dt_compat	= kzm9d_boards_compat_dt,
--- 0002/arch/arm/mach-shmobile/include/mach/emev2.h
+++ work/arch/arm/mach-shmobile/include/mach/emev2.h	2013-07-02 15:01:48.000000000 +0900
@@ -2,7 +2,6 @@
 #define __ASM_EMEV2_H__
 
 extern void emev2_map_io(void);
-extern void emev2_init_irq(void);
 extern void emev2_init_delay(void);
 extern void emev2_add_standard_devices(void);
 extern void emev2_clock_init(void);
--- 0003/arch/arm/mach-shmobile/setup-emev2.c
+++ work/arch/arm/mach-shmobile/setup-emev2.c	2013-07-02 15:01:17.000000000 +0900
@@ -202,20 +202,6 @@ void __init emev2_init_delay(void)
 	shmobile_setup_delay(533, 1, 3); /* Cortex-A9 @ 533MHz */
 }
 
-void __init emev2_init_irq(void)
-{
-	void __iomem *gic_dist_base;
-	void __iomem *gic_cpu_base;
-
-	/* Static mappings, never released */
-	gic_dist_base = ioremap(0xe0028000, PAGE_SIZE);
-	gic_cpu_base = ioremap(0xe0020000, PAGE_SIZE);
-	BUG_ON(!gic_dist_base || !gic_cpu_base);
-
-	/* Use GIC to handle interrupts */
-	gic_init(0, 29, gic_dist_base, gic_cpu_base);
-}
-
 #ifdef CONFIG_USE_OF
 static const struct of_dev_auxdata emev2_auxdata_lookup[] __initconst = {
 	{ }
@@ -235,7 +221,6 @@ static const char *emev2_boards_compat_d
 DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
 	.smp		= smp_ops(emev2_smp_ops),
 	.init_early	= emev2_init_delay,
-	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_machine	= emev2_add_standard_devices_dt,
 	.dt_compat	= emev2_boards_compat_dt,
 MACHINE_END


From magnus.damm at gmail.com  Tue Jul  2 05:28:14 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 02 Jul 2013 18:28:14 +0900
Subject: [PATCH 06/08] ARM: shmobile: Use DT for SMP on EMEV2 and KZM9D
In-Reply-To: <20130702092725.32066.54861.sendpatchset@w520>
References: <20130702092725.32066.54861.sendpatchset@w520>
Message-ID: <20130702092814.32066.30138.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Rework the EMEV2 SMP code to rely on DT for CPU information
instead of reading out number of CPU cores from the SCU.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/smp-emev2.c |   17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

--- 0001/arch/arm/mach-shmobile/smp-emev2.c
+++ work/arch/arm/mach-shmobile/smp-emev2.c	2013-07-02 15:09:53.000000000 +0900
@@ -38,9 +38,12 @@ static int __cpuinit emev2_boot_secondar
 
 static void __init emev2_smp_prepare_cpus(unsigned int max_cpus)
 {
+	/* setup EMEV2 specific SCU base, enable */
+	shmobile_scu_base = ioremap(EMEV2_SCU_BASE, PAGE_SIZE);
 	scu_enable(shmobile_scu_base);
 
 	/* Tell ROM loader about our vector (in headsmp-scu.S, headsmp.S) */
+	emev2_clock_init(); /* need ioremapped SMU */
 	emev2_set_boot_vector(__pa(shmobile_boot_vector));
 	shmobile_boot_fn = virt_to_phys(shmobile_boot_scu);
 	shmobile_boot_arg = (unsigned long)shmobile_scu_base;
@@ -49,21 +52,7 @@ static void __init emev2_smp_prepare_cpu
 	scu_power_mode(shmobile_scu_base, SCU_PM_NORMAL);
 }
 
-static void __init emev2_smp_init_cpus(void)
-{
-	unsigned int ncores;
-
-	/* setup EMEV2 specific SCU base */
-	shmobile_scu_base = ioremap(EMEV2_SCU_BASE, PAGE_SIZE);
-	emev2_clock_init(); /* need ioremapped SMU */
-
-	ncores = shmobile_scu_base ? scu_get_core_count(shmobile_scu_base) : 1;
-
-	shmobile_smp_init_cpus(ncores);
-}
-
 struct smp_operations emev2_smp_ops __initdata = {
-	.smp_init_cpus		= emev2_smp_init_cpus,
 	.smp_prepare_cpus	= emev2_smp_prepare_cpus,
 	.smp_boot_secondary	= emev2_boot_secondary,
 };


From magnus.damm at gmail.com  Tue Jul  2 05:28:22 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 02 Jul 2013 18:28:22 +0900
Subject: [PATCH 07/08] ARM: shmobile: EMEV2 map_io update
In-Reply-To: <20130702092725.32066.54861.sendpatchset@w520>
References: <20130702092725.32066.54861.sendpatchset@w520>
Message-ID: <20130702092822.32066.80242.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Update the EMEV2 struct map_desc to exclude the SMU
and also include the ->map_io() callback in the DT
version of EMEV2 board support.

The EMEV2 SMP code can these days perform ioremap()
early on without the SMU information in the io_desc[].

To correctly support SMP in case of DT-only board
support then the ->map_io() callback is needed.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-emev2.c |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

--- 0004/arch/arm/mach-shmobile/setup-emev2.c
+++ work/arch/arm/mach-shmobile/setup-emev2.c	2013-07-02 15:22:37.000000000 +0900
@@ -38,13 +38,6 @@
 
 static struct map_desc emev2_io_desc[] __initdata = {
 #ifdef CONFIG_SMP
-	/* 128K entity map for 0xe0100000 (SMU) */
-	{
-		.virtual	= 0xe0100000,
-		.pfn		= __phys_to_pfn(0xe0100000),
-		.length		= SZ_128K,
-		.type		= MT_DEVICE
-	},
 	/* 2M mapping for SCU + L2 controller */
 	{
 		.virtual	= 0xf0000000,
@@ -220,6 +213,7 @@ static const char *emev2_boards_compat_d
 
 DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
 	.smp		= smp_ops(emev2_smp_ops),
+	.map_io		= emev2_map_io,
 	.init_early	= emev2_init_delay,
 	.init_machine	= emev2_add_standard_devices_dt,
 	.dt_compat	= emev2_boards_compat_dt,


From magnus.damm at gmail.com  Tue Jul  2 05:28:30 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 02 Jul 2013 18:28:30 +0900
Subject: [PATCH 08/08] ARM: shmobile: Disconnect EMEV2 SMP code from clocks
In-Reply-To: <20130702092725.32066.54861.sendpatchset@w520>
References: <20130702092725.32066.54861.sendpatchset@w520>
Message-ID: <20130702092830.32066.8431.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Update the EMEV2 SMP code to access the SMU directly
instead of relying on help from the legacy clock code.

This change moves us one step closer to common clocks.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/clock-emev2.c        |   18 ------------------
 arch/arm/mach-shmobile/include/mach/emev2.h |    1 -
 arch/arm/mach-shmobile/smp-emev2.c          |   11 +++++++++--
 3 files changed, 9 insertions(+), 21 deletions(-)

--- 0001/arch/arm/mach-shmobile/clock-emev2.c
+++ work/arch/arm/mach-shmobile/clock-emev2.c	2013-07-02 15:31:52.000000000 +0900
@@ -40,7 +40,6 @@
 #define USIB2SCLKDIV 0x65c
 #define USIB3SCLKDIV 0x660
 #define STI_CLKSEL 0x688
-#define SMU_GENERAL_REG0 0x7c0
 
 /* not pretty, but hey */
 static void __iomem *smu_base;
@@ -51,11 +50,6 @@ static void emev2_smu_write(unsigned lon
 	iowrite32(value, smu_base + offs);
 }
 
-void emev2_set_boot_vector(unsigned long value)
-{
-	emev2_smu_write(value, SMU_GENERAL_REG0);
-}
-
 static struct clk_mapping smu_mapping = {
 	.phys	= EMEV2_SMU_BASE,
 	.len	= PAGE_SIZE,
@@ -205,18 +199,6 @@ static struct clk_lookup lookups[] = {
 void __init emev2_clock_init(void)
 {
 	int k, ret = 0;
-	static int is_setup;
-
-	/* yuck, this is ugly as hell, but the non-smp case of clocks
-	 * code is now designed to rely on ioremap() instead of static
-	 * entity maps. in the case of smp we need access to the SMU
-	 * register earlier than ioremap() is actually working without
-	 * any static maps. to enable SMP in ugly but with dynamic
-	 * mappings we have to call emev2_clock_init() from different
-	 * places depending on UP and SMP...
-	 */
-	if (is_setup++)
-		return;
 
 	smu_base = ioremap(EMEV2_SMU_BASE, PAGE_SIZE);
 	BUG_ON(!smu_base);
--- 0004/arch/arm/mach-shmobile/include/mach/emev2.h
+++ work/arch/arm/mach-shmobile/include/mach/emev2.h	2013-07-02 15:32:05.000000000 +0900
@@ -5,7 +5,6 @@ extern void emev2_map_io(void);
 extern void emev2_init_delay(void);
 extern void emev2_add_standard_devices(void);
 extern void emev2_clock_init(void);
-extern void emev2_set_boot_vector(unsigned long value);
 
 #define EMEV2_GPIO_BASE 200
 #define EMEV2_GPIO_IRQ(n) (EMEV2_GPIO_BASE + (n))
--- 0005/arch/arm/mach-shmobile/smp-emev2.c
+++ work/arch/arm/mach-shmobile/smp-emev2.c	2013-07-02 15:31:01.000000000 +0900
@@ -29,6 +29,8 @@
 #include <asm/smp_scu.h>
 
 #define EMEV2_SCU_BASE 0x1e000000
+#define EMEV2_SMU_BASE 0xe0110000
+#define SMU_GENERAL_REG0 0x7c0
 
 static int __cpuinit emev2_boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
@@ -38,13 +40,18 @@ static int __cpuinit emev2_boot_secondar
 
 static void __init emev2_smp_prepare_cpus(unsigned int max_cpus)
 {
+	void __iomem *smu;
+
 	/* setup EMEV2 specific SCU base, enable */
 	shmobile_scu_base = ioremap(EMEV2_SCU_BASE, PAGE_SIZE);
 	scu_enable(shmobile_scu_base);
 
 	/* Tell ROM loader about our vector (in headsmp-scu.S, headsmp.S) */
-	emev2_clock_init(); /* need ioremapped SMU */
-	emev2_set_boot_vector(__pa(shmobile_boot_vector));
+	smu = ioremap(EMEV2_SMU_BASE, PAGE_SIZE);
+	if (smu) {
+		iowrite32(__pa(shmobile_boot_vector), smu + SMU_GENERAL_REG0);
+		iounmap(smu);
+	}
 	shmobile_boot_fn = virt_to_phys(shmobile_boot_scu);
 	shmobile_boot_arg = (unsigned long)shmobile_scu_base;
 


From mark.rutland at arm.com  Tue Jul  2 05:56:45 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 2 Jul 2013 10:56:45 +0100
Subject: [PATCH 3/5] ARM: dts: imx6: rename the uart's compatible property
In-Reply-To: <1372746628-20092-4-git-send-email-b32955@freescale.com>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
 <1372746628-20092-4-git-send-email-b32955@freescale.com>
Message-ID: <20130702095645.GD31358@e106331-lin.cambridge.arm.com>

On Tue, Jul 02, 2013 at 07:30:26AM +0100, Huang Shijie wrote:
> The imx6 uart can supports the DMA, imx uart driver has added a new
> compatible property for the imx6 uart.
> 
> In order to enable the DMA for some uart port in imx6, we rename the
> uart's compatible property to "fsl,imx6-uart".

Doesn't this change break using these dts with an older kernel? You
remove the "fsl,imx21-uart" string older kernels understand.

Given you already had "fsl,imx6q-uart" and "fsl,imx6sl-uart" strings,
would it not have made more sense to just add these to the driver?

Thanks,
Mark.

> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>
> ---
>  arch/arm/boot/dts/imx6qdl.dtsi |   10 +++++-----
>  arch/arm/boot/dts/imx6sl.dtsi  |   10 +++++-----
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index 0509344..d4ab0ee 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -179,7 +179,7 @@
>  				};
>  
>  				uart1: serial at 02020000 {
> -					compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
> +					compatible = "fsl,imx6-uart";
>  					reg = <0x02020000 0x4000>;
>  					interrupts = <0 26 0x04>;
>  					clocks = <&clks 160>, <&clks 161>;
> @@ -787,7 +787,7 @@
>  			};
>  
>  			uart2: serial at 021e8000 {
> -				compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
> +				compatible = "fsl,imx6-uart";
>  				reg = <0x021e8000 0x4000>;
>  				interrupts = <0 27 0x04>;
>  				clocks = <&clks 160>, <&clks 161>;
> @@ -796,7 +796,7 @@
>  			};
>  
>  			uart3: serial at 021ec000 {
> -				compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
> +				compatible = "fsl,imx6-uart";
>  				reg = <0x021ec000 0x4000>;
>  				interrupts = <0 28 0x04>;
>  				clocks = <&clks 160>, <&clks 161>;
> @@ -805,7 +805,7 @@
>  			};
>  
>  			uart4: serial at 021f0000 {
> -				compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
> +				compatible = "fsl,imx6-uart";
>  				reg = <0x021f0000 0x4000>;
>  				interrupts = <0 29 0x04>;
>  				clocks = <&clks 160>, <&clks 161>;
> @@ -814,7 +814,7 @@
>  			};
>  
>  			uart5: serial at 021f4000 {
> -				compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
> +				compatible = "fsl,imx6-uart";
>  				reg = <0x021f4000 0x4000>;
>  				interrupts = <0 30 0x04>;
>  				clocks = <&clks 160>, <&clks 161>;
> diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
> index 9138c67..ca1527f 100644
> --- a/arch/arm/boot/dts/imx6sl.dtsi
> +++ b/arch/arm/boot/dts/imx6sl.dtsi
> @@ -152,7 +152,7 @@
>  				};
>  
>  				uart5: serial at 02018000 {
> -					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
> +					compatible = "fsl,imx6-uart";
>  					reg = <0x02018000 0x4000>;
>  					interrupts = <0 30 0x04>;
>  					clocks = <&clks IMX6SL_CLK_UART>,
> @@ -162,7 +162,7 @@
>  				};
>  
>  				uart1: serial at 02020000 {
> -					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
> +					compatible = "fsl,imx6-uart";
>  					reg = <0x02020000 0x4000>;
>  					interrupts = <0 26 0x04>;
>  					clocks = <&clks IMX6SL_CLK_UART>,
> @@ -172,7 +172,7 @@
>  				};
>  
>  				uart2: serial at 02024000 {
> -					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
> +					compatible = "fsl,imx6-uart";
>  					reg = <0x02024000 0x4000>;
>  					interrupts = <0 27 0x04>;
>  					clocks = <&clks IMX6SL_CLK_UART>,
> @@ -209,7 +209,7 @@
>  				};
>  
>  				uart3: serial at 02034000 {
> -					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
> +					compatible = "fsl,imx6-uart";
>  					reg = <0x02034000 0x4000>;
>  					interrupts = <0 28 0x04>;
>  					clocks = <&clks IMX6SL_CLK_UART>,
> @@ -219,7 +219,7 @@
>  				};
>  
>  				uart4: serial at 02038000 {
> -					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
> +					compatible = "fsl,imx6-uart";
>  					reg = <0x02038000 0x4000>;
>  					interrupts = <0 29 0x04>;
>  					clocks = <&clks IMX6SL_CLK_UART>,
> -- 
> 1.7.1
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From b32955 at freescale.com  Tue Jul  2 06:43:13 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 2 Jul 2013 18:43:13 +0800
Subject: [PATCH 3/5] ARM: dts: imx6: rename the uart's compatible property
In-Reply-To: <20130702095645.GD31358@e106331-lin.cambridge.arm.com>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
 <1372746628-20092-4-git-send-email-b32955@freescale.com>
 <20130702095645.GD31358@e106331-lin.cambridge.arm.com>
Message-ID: <51D2AEC1.6030004@freescale.com>

? 2013?07?02? 17:56, Mark Rutland ??:
> On Tue, Jul 02, 2013 at 07:30:26AM +0100, Huang Shijie wrote:
>> >  The imx6 uart can supports the DMA, imx uart driver has added a new
>> >  compatible property for the imx6 uart.
>> >  
>> >  In order to enable the DMA for some uart port in imx6, we rename the
>> >  uart's compatible property to "fsl,imx6-uart".
> Doesn't this change break using these dts with an older kernel? You
is it reasonable to use a new dts with an old kernel?


> remove the "fsl,imx21-uart" string older kernels understand.
>
> Given you already had "fsl,imx6q-uart" and "fsl,imx6sl-uart" strings,
> would it not have made more sense to just add these to the driver?
I think it's not a good idea.

Shawn, what's your opinion about this?

thanks
Huang Shijie




From sebastian.hesselbarth at gmail.com  Tue Jul  2 06:54:11 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 12:54:11 +0200
Subject: [PATCH 0/2] ARM: mvebu: fixes for v3.11
Message-ID: <1372762453-12018-1-git-send-email-sebastian.hesselbarth@gmail.com>

This patch set comprises two unrelated fixes for Marvell SoCs based on
what is currently in next-20130701. There may be fixes already pending
for the issues.

The first patch is a clean-up patch removing dmacap,memset from the
device tree binding and users. DMA_MEMSET support has been removed from
DMA API and mv_xor driver.

The second patch fixes compilation of orion5x edmini_v2 by adding a
missing include.

devicetree-discuss is added on Cc for completeness, this is all Marvell
related and should go through Jason Cooper's branch if there are no
objections.

Sebastian Hesselbarth (2):
  ARM: remove dmacap,memset from Device tree binding
  ARM: orion5x: add missing mbus include

 Documentation/devicetree/bindings/dma/mv-xor.txt |    2 --
 arch/arm/boot/dts/armada-370.dtsi                |    2 --
 arch/arm/boot/dts/armada-xp.dtsi                 |    2 --
 arch/arm/boot/dts/dove.dtsi                      |    2 --
 arch/arm/boot/dts/kirkwood.dtsi                  |    2 --
 arch/arm/boot/dts/orion5x.dtsi                   |    1 -
 arch/arm/mach-orion5x/edmini_v2-setup.c          |    1 +
 7 files changed, 1 insertions(+), 11 deletions(-)

---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 06:54:12 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 12:54:12 +0200
Subject: [PATCH 1/2] ARM: remove dmacap,memset from Device tree binding
In-Reply-To: <1372762453-12018-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762453-12018-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372762453-12018-2-git-send-email-sebastian.hesselbarth@gmail.com>

DMA_MEMSET support has been removed, so update the device tree files
and corresponding binding documentation for Marvell SoCs.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Russell King <linux at arm.linux.org.uk> 
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com> 
Cc: devicetree-discuss at lists.ozlabs.org 
Cc: linux-kernel at vger.kernel.org 
Cc: linux-arm-kernel at lists.infradead.org 
---
 Documentation/devicetree/bindings/dma/mv-xor.txt |    2 --
 arch/arm/boot/dts/armada-370.dtsi                |    2 --
 arch/arm/boot/dts/armada-xp.dtsi                 |    2 --
 arch/arm/boot/dts/dove.dtsi                      |    2 --
 arch/arm/boot/dts/kirkwood.dtsi                  |    2 --
 arch/arm/boot/dts/orion5x.dtsi                   |    1 -
 6 files changed, 0 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/mv-xor.txt b/Documentation/devicetree/bindings/dma/mv-xor.txt
index 7c6cb7f..68f7004 100644
--- a/Documentation/devicetree/bindings/dma/mv-xor.txt
+++ b/Documentation/devicetree/bindings/dma/mv-xor.txt
@@ -14,7 +14,6 @@ properties:
 
 And the following optional properties:
 - dmacap,memcpy to indicate that the XOR channel is capable of memcpy operations
-- dmacap,memset to indicate that the XOR channel is capable of memset operations
 - dmacap,xor to indicate that the XOR channel is capable of xor operations
 
 Example:
@@ -35,6 +34,5 @@ xor at d0060900 {
 	      interrupts = <52>;
 	      dmacap,memcpy;
 	      dmacap,xor;
-	      dmacap,memset;
 	};
 };
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..a315ad1 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -132,7 +132,6 @@
 					interrupts = <52>;
 					dmacap,memcpy;
 					dmacap,xor;
-					dmacap,memset;
 				};
 			};
 
@@ -151,7 +150,6 @@
 					interrupts = <95>;
 					dmacap,memcpy;
 					dmacap,xor;
-					dmacap,memset;
 				};
 			};
 
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 416eb94..4b3dd56 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -114,7 +114,6 @@
 					interrupts = <52>;
 					dmacap,memcpy;
 					dmacap,xor;
-					dmacap,memset;
 				};
 			};
 
@@ -134,7 +133,6 @@
 					interrupts = <95>;
 					dmacap,memcpy;
 					dmacap,xor;
-					dmacap,memset;
 				};
 			};
 
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 6cab468..2cef34f 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -232,7 +232,6 @@
 
 			channel1 {
 				interrupts = <40>;
-				dmacap,memset;
 				dmacap,memcpy;
 				dmacap,xor;
 			};
@@ -253,7 +252,6 @@
 
 			channel1 {
 				interrupts = <43>;
-				dmacap,memset;
 				dmacap,memcpy;
 				dmacap,xor;
 			};
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 9809fc1..078637c 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -126,7 +126,6 @@
 			      interrupts = <6>;
 			      dmacap,memcpy;
 			      dmacap,xor;
-			      dmacap,memset;
 			};
 		};
 
@@ -146,7 +145,6 @@
 			      interrupts = <8>;
 			      dmacap,memcpy;
 			      dmacap,xor;
-			      dmacap,memset;
 			};
 		};
 
diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
index 892c64e..f82ece7 100644
--- a/arch/arm/boot/dts/orion5x.dtsi
+++ b/arch/arm/boot/dts/orion5x.dtsi
@@ -120,7 +120,6 @@
 			      interrupts = <31>;
 			      dmacap,memcpy;
 			      dmacap,xor;
-			      dmacap,memset;
 			};
 		};
 
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 06:54:13 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 12:54:13 +0200
Subject: [PATCH 2/2] ARM: orion5x: add missing mbus include
In-Reply-To: <1372762453-12018-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762453-12018-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372762453-12018-3-git-send-email-sebastian.hesselbarth@gmail.com>

edmini_v2-setup is missing an include of linux/mbus.h which causes
compiler error because of missing reference to mvebu_mbus_add_window.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Russell King <linux at arm.linux.org.uk> 
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com> 
Cc: devicetree-discuss at lists.ozlabs.org 
Cc: linux-kernel at vger.kernel.org 
Cc: linux-arm-kernel at lists.infradead.org 
---
 arch/arm/mach-orion5x/edmini_v2-setup.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-orion5x/edmini_v2-setup.c b/arch/arm/mach-orion5x/edmini_v2-setup.c
index 1476155..1cecedc 100644
--- a/arch/arm/mach-orion5x/edmini_v2-setup.c
+++ b/arch/arm/mach-orion5x/edmini_v2-setup.c
@@ -23,6 +23,7 @@
 #include <linux/platform_device.h>
 #include <linux/pci.h>
 #include <linux/irq.h>
+#include <linux/mbus.h>
 #include <linux/mtd/physmap.h>
 #include <linux/mv643xx_eth.h>
 #include <linux/leds.h>
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:00:24 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:00:24 +0200
Subject: [PATCH v6 7/7] ARM: orion5x: remove legacy mv643xx_eth board setup
In-Reply-To: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372762824-12202-8-git-send-email-sebastian.hesselbarth@gmail.com>

With DT support for mv643xx_eth we do not need legacy platform_data
based setup for DT enabled boards. This patch removes eth setup
for all orion5x DT board files.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Changelog:
v5->v6:
- rebase for v3.11-rc1

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: netdev at vger.kernel.org
---
 arch/arm/mach-orion5x/edmini_v2-setup.c |   10 ----------
 1 files changed, 0 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-orion5x/edmini_v2-setup.c b/arch/arm/mach-orion5x/edmini_v2-setup.c
index 1cecedc..7d316ed 100644
--- a/arch/arm/mach-orion5x/edmini_v2-setup.c
+++ b/arch/arm/mach-orion5x/edmini_v2-setup.c
@@ -25,7 +25,6 @@
 #include <linux/irq.h>
 #include <linux/mbus.h>
 #include <linux/mtd/physmap.h>
-#include <linux/mv643xx_eth.h>
 #include <linux/leds.h>
 #include <linux/gpio_keys.h>
 #include <linux/input.h>
@@ -97,14 +96,6 @@ static struct platform_device edmini_v2_nor_flash = {
 };
 
 /*****************************************************************************
- * Ethernet
- ****************************************************************************/
-
-static struct mv643xx_eth_platform_data edmini_v2_eth_data = {
-	.phy_addr	= 8,
-};
-
-/*****************************************************************************
  * RTC 5C372a on I2C bus
  ****************************************************************************/
 
@@ -153,7 +144,6 @@ void __init edmini_v2_init(void)
 	 * Configure peripherals.
 	 */
 	orion5x_ehci0_init();
-	orion5x_eth_init(&edmini_v2_eth_data);
 
 	mvebu_mbus_add_window("devbus-boot", EDMINI_V2_NOR_BOOT_BASE,
 			      EDMINI_V2_NOR_BOOT_SIZE);
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:00:17 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:00:17 +0200
Subject: [PATCH v6 0/7] ARM: mvebu: switch to DT probed mv643xx_eth
Message-ID: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>

This patch set converts Marvell Dove, Kirkwood, and Orion5x DT enabled
boards to probe mv643xx_eth by DT. The corresponding DT support patches
for mv643xx_eth driver have already been taked by David Miller and are
available in next-20130701. This only contains the ARM part of
mv643xx_eth DT support patches and therefore patch counting is
continued as v6 with respect to the combined patch set.

The first three patches add nodes for ethernet-controller, mdio-bus,
and ethernet PHYs found on the three SoCs and their boards.

The last four patches convert DT boards for each SoC from platform_device
registration to DT based probing by removing the corresponding calls.
For Kirkwood this makes almost all DT board setup (except board-dnskw)
obsolete. Therefore, patch 5 removes board setup files, Kconfig, Makefile,
and defconfig entries for those boards.

This patch set has been tested on Marvell Dove, and compile-tested for
Kirkwood and Orion5x defconfig on top of next-20130701 with some fixes
sent earlier applied (DMA_MEMSET fixes and missing include on edmini_v2).

netdev is added on Cc for completeness, this is all Marvell related and
should go through Jason Cooper's branch if there are no objections.

Sebastian Hesselbarth (7):
  ARM: dove: add gigabit ethernet and mvmdio device tree nodes
  ARM: kirkwood: add gigabit ethernet and mvmdio device tree nodes
  ARM: orion5x: add gigabit ethernet and mvmdio device tree nodes
  ARM: dove: remove legacy mv643xx_eth setup
  ARM: kirkwood: remove redundant DT board files
  ARM: kirkwood: remove legacy clk alias for mv643xx_eth
  ARM: orion5x: remove legacy mv643xx_eth board setup

 arch/arm/boot/dts/dove-cubox.dts                   |    7 +
 arch/arm/boot/dts/dove.dtsi                        |   35 +++++
 arch/arm/boot/dts/kirkwood-cloudbox.dts            |   16 ++
 arch/arm/boot/dts/kirkwood-db.dtsi                 |   16 ++
 arch/arm/boot/dts/kirkwood-dnskw.dtsi              |   16 ++
 arch/arm/boot/dts/kirkwood-dockstar.dts            |   17 ++
 arch/arm/boot/dts/kirkwood-dreamplug.dts           |   28 ++++
 arch/arm/boot/dts/kirkwood-goflexnet.dts           |   16 ++
 .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |   30 ++++
 arch/arm/boot/dts/kirkwood-ib62x0.dts              |   16 ++
 arch/arm/boot/dts/kirkwood-iconnect.dts            |   16 ++
 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts      |   24 +++
 arch/arm/boot/dts/kirkwood-is2.dts                 |    2 +
 arch/arm/boot/dts/kirkwood-km_kirkwood.dts         |   16 ++
 arch/arm/boot/dts/kirkwood-lsxl.dtsi               |   28 ++++
 arch/arm/boot/dts/kirkwood-mplcec4.dts             |   27 ++++
 .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  |   16 ++
 arch/arm/boot/dts/kirkwood-ns2-common.dtsi         |   16 ++
 arch/arm/boot/dts/kirkwood-ns2.dts                 |    2 +
 arch/arm/boot/dts/kirkwood-ns2lite.dts             |    2 +
 arch/arm/boot/dts/kirkwood-ns2max.dts              |    2 +
 arch/arm/boot/dts/kirkwood-ns2mini.dts             |    2 +
 arch/arm/boot/dts/kirkwood-openblocks_a6.dts       |   16 ++
 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi  |   16 ++
 arch/arm/boot/dts/kirkwood-topkick.dts             |   16 ++
 arch/arm/boot/dts/kirkwood-ts219-6281.dts          |    4 +-
 arch/arm/boot/dts/kirkwood-ts219-6282.dts          |    4 +-
 arch/arm/boot/dts/kirkwood-ts219.dtsi              |   16 ++
 arch/arm/boot/dts/kirkwood.dtsi                    |   52 +++++++
 .../dts/orion5x-lacie-ethernet-disk-mini-v2.dts    |   17 ++
 arch/arm/boot/dts/orion5x.dtsi                     |   29 ++++
 arch/arm/configs/kirkwood_defconfig                |   22 ---
 arch/arm/mach-dove/board-dt.c                      |    9 -
 arch/arm/mach-kirkwood/Kconfig                     |  156 --------------------
 arch/arm/mach-kirkwood/Makefile                    |   23 +---
 arch/arm/mach-kirkwood/board-db88f628x-bp.c        |   24 ---
 arch/arm/mach-kirkwood/board-dnskw.c               |    7 -
 arch/arm/mach-kirkwood/board-dockstar.c            |   32 ----
 arch/arm/mach-kirkwood/board-dreamplug.c           |   35 -----
 arch/arm/mach-kirkwood/board-dt.c                  |   86 +-----------
 arch/arm/mach-kirkwood/board-goflexnet.c           |   34 -----
 arch/arm/mach-kirkwood/board-guruplug.c            |   33 ----
 arch/arm/mach-kirkwood/board-ib62x0.c              |   29 ----
 arch/arm/mach-kirkwood/board-iconnect.c            |   24 ---
 arch/arm/mach-kirkwood/board-iomega_ix2_200.c      |   34 -----
 arch/arm/mach-kirkwood/board-km_kirkwood.c         |   44 ------
 arch/arm/mach-kirkwood/board-lsxl.c                |   36 -----
 arch/arm/mach-kirkwood/board-mplcec4.c             |   35 -----
 arch/arm/mach-kirkwood/board-ns2.c                 |   35 -----
 arch/arm/mach-kirkwood/board-openblocks_a6.c       |   26 ----
 arch/arm/mach-kirkwood/board-readynas.c            |   27 ----
 arch/arm/mach-kirkwood/board-sheevaplug.c          |   27 ----
 arch/arm/mach-kirkwood/board-ts219.c               |   40 -----
 arch/arm/mach-kirkwood/board-usi_topkick.c         |   29 ----
 arch/arm/mach-orion5x/edmini_v2-setup.c            |   10 --
 55 files changed, 520 insertions(+), 857 deletions(-)
 delete mode 100644 arch/arm/mach-kirkwood/board-db88f628x-bp.c
 delete mode 100644 arch/arm/mach-kirkwood/board-dockstar.c
 delete mode 100644 arch/arm/mach-kirkwood/board-dreamplug.c
 delete mode 100644 arch/arm/mach-kirkwood/board-goflexnet.c
 delete mode 100644 arch/arm/mach-kirkwood/board-guruplug.c
 delete mode 100644 arch/arm/mach-kirkwood/board-ib62x0.c
 delete mode 100644 arch/arm/mach-kirkwood/board-iconnect.c
 delete mode 100644 arch/arm/mach-kirkwood/board-iomega_ix2_200.c
 delete mode 100644 arch/arm/mach-kirkwood/board-km_kirkwood.c
 delete mode 100644 arch/arm/mach-kirkwood/board-lsxl.c
 delete mode 100644 arch/arm/mach-kirkwood/board-mplcec4.c
 delete mode 100644 arch/arm/mach-kirkwood/board-ns2.c
 delete mode 100644 arch/arm/mach-kirkwood/board-openblocks_a6.c
 delete mode 100644 arch/arm/mach-kirkwood/board-readynas.c
 delete mode 100644 arch/arm/mach-kirkwood/board-sheevaplug.c
 delete mode 100644 arch/arm/mach-kirkwood/board-ts219.c
 delete mode 100644 arch/arm/mach-kirkwood/board-usi_topkick.c

---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: netdev at vger.kernel.org
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:00:18 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:00:18 +0200
Subject: [PATCH v6 1/7] ARM: dove: add gigabit ethernet and mvmdio device tree
 nodes
In-Reply-To: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372762824-12202-2-git-send-email-sebastian.hesselbarth@gmail.com>

This patch adds orion-eth and mvmdio device tree nodes for DT enabled
Dove boards. As there is only one ethernet controller on Dove, a default
phy node is also added with a note to set its reg property on a per-board
basis.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Changelog:
v5->v6:
- rebase for v3.11-rc1

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: netdev at vger.kernel.org
---
 arch/arm/boot/dts/dove-cubox.dts |    7 +++++++
 arch/arm/boot/dts/dove.dtsi      |   35 +++++++++++++++++++++++++++++++++++
 2 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/dove-cubox.dts b/arch/arm/boot/dts/dove-cubox.dts
index 5cae2ab..955188f 100644
--- a/arch/arm/boot/dts/dove-cubox.dts
+++ b/arch/arm/boot/dts/dove-cubox.dts
@@ -57,6 +57,13 @@
 
 &uart0 { status = "okay"; };
 &sata0 { status = "okay"; };
+&mdio { status = "okay"; };
+&eth { status = "okay"; };
+
+&ethphy {
+	compatible = "marvell,88e1310";
+	reg = <1>;
+};
 
 &i2c0 {
 	status = "okay";
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 2cef34f..5e394a6 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -256,5 +256,40 @@
 				dmacap,xor;
 			};
 		};
+
+		mdio: mdio-bus at 72004 {
+			compatible = "marvell,orion-mdio";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x72004 0x84>;
+			interrupts = <30>;
+			clocks = <&gate_clk 2>;
+			status = "disabled";
+
+			ethphy: ethernet-phy {
+				device-type = "ethernet-phy";
+				/* set phy address in board file */
+			};
+		};
+
+		eth: ethernet-controller at 72000 {
+			compatible = "marvell,orion-eth";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x72000 0x4000>;
+			clocks = <&gate_clk 2>;
+			marvell,tx-checksum-limit = <1600>;
+			status = "disabled";
+
+			ethernet-port at 0 {
+				device_type = "network";
+				compatible = "marvell,orion-eth-port";
+				reg = <0>;
+				interrupts = <29>;
+				/* overwrite MAC address in bootloader */
+				local-mac-address = [00 00 00 00 00 00];
+				phy-handle = <&ethphy>;
+			};
+		};
 	};
 };
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:00:21 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:00:21 +0200
Subject: [PATCH v6 4/7] ARM: dove: remove legacy mv643xx_eth setup
In-Reply-To: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372762824-12202-5-git-send-email-sebastian.hesselbarth@gmail.com>

With DT support for mv643xx_eth we do not need legacy platform_data
based setup for DT enabled boards anymore.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Changelog:
v5->v6:
- rebase for v3.11-rc1

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: netdev at vger.kernel.org
---
 arch/arm/mach-dove/board-dt.c |    9 ---------
 1 files changed, 0 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-dove/board-dt.c
index f3755ac..b5ccc1c 100644
--- a/arch/arm/mach-dove/board-dt.c
+++ b/arch/arm/mach-dove/board-dt.c
@@ -33,10 +33,6 @@ static void __init dove_legacy_clk_init(void)
 	clkspec.np = np;
 	clkspec.args_count = 1;
 
-	clkspec.args[0] = CLOCK_GATING_BIT_GBE;
-	orion_clkdev_add(NULL, "mv643xx_eth_port.0",
-			 of_clk_get_from_provider(&clkspec));
-
 	clkspec.args[0] = CLOCK_GATING_BIT_PCIE0;
 	orion_clkdev_add("0", "pcie",
 			 of_clk_get_from_provider(&clkspec));
@@ -52,10 +48,6 @@ static void __init dove_of_clk_init(void)
 	dove_legacy_clk_init();
 }
 
-static struct mv643xx_eth_platform_data dove_dt_ge00_data = {
-	.phy_addr = MV643XX_ETH_PHY_ADDR_DEFAULT,
-};
-
 static void __init dove_dt_init(void)
 {
 	pr_info("Dove 88AP510 SoC\n");
@@ -69,7 +61,6 @@ static void __init dove_dt_init(void)
 	dove_of_clk_init();
 
 	/* Internal devices not ported to DT yet */
-	dove_ge00_init(&dove_dt_ge00_data);
 	dove_pcie_init(1, 1);
 
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:00:23 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:00:23 +0200
Subject: [PATCH v6 6/7] ARM: kirkwood: remove legacy clk alias for mv643xx_eth
In-Reply-To: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372762824-12202-7-git-send-email-sebastian.hesselbarth@gmail.com>

With all boards converted to DT enabled mv643xx_eth we can now
remove the clock alias for gbe clocks.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Changelog:
v5->v6:
- rebase for v3.11-rc1

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: netdev at vger.kernel.org
---
 arch/arm/mach-kirkwood/board-dt.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index a3271f6..881f37e 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -60,12 +60,10 @@ static void __init kirkwood_legacy_clk_init(void)
 	 */
 	clkspec.args[0] = CGC_BIT_GE0;
 	clk = of_clk_get_from_provider(&clkspec);
-	orion_clkdev_add(NULL, "mv643xx_eth_port.0", clk);
 	clk_prepare_enable(clk);
 
 	clkspec.args[0] = CGC_BIT_GE1;
 	clk = of_clk_get_from_provider(&clkspec);
-	orion_clkdev_add(NULL, "mv643xx_eth_port.1", clk);
 	clk_prepare_enable(clk);
 }
 
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:00:20 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:00:20 +0200
Subject: [PATCH v6 3/7] ARM: orion5x: add gigabit ethernet and mvmdio device
 tree nodes
In-Reply-To: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372762824-12202-4-git-send-email-sebastian.hesselbarth@gmail.com>

This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Orion5x boards. Phy nodes are also added with reg property set on a
per-board basis.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Changelog:
v5->v6:
- rebase for v3.11-rc1

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: netdev at vger.kernel.org
---
 .../dts/orion5x-lacie-ethernet-disk-mini-v2.dts    |   17 +++++++++++
 arch/arm/boot/dts/orion5x.dtsi                     |   29 ++++++++++++++++++++
 2 files changed, 46 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts b/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
index 0077fc8..aed83de 100644
--- a/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
+++ b/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
@@ -53,3 +53,20 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy: ethernet-phy {
+		device-type = "ethernet-phy";
+		reg = <8>;
+	};
+};
+
+&eth {
+	status = "okay";
+
+	ethernet-port at 0 {
+		phy-handle = <&ethphy>;
+	};
+};
diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
index f82ece7..2d241fc 100644
--- a/arch/arm/boot/dts/orion5x.dtsi
+++ b/arch/arm/boot/dts/orion5x.dtsi
@@ -131,5 +131,34 @@
 			interrupts = <28>;
 			status = "okay";
 		};
+
+		mdio: mdio-bus at 72004 {
+			compatible = "marvell,orion-mdio";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x72004 0x84>;
+			interrupts = <22>;
+			status = "disabled";
+
+			/* add phy nodes in board file */
+		};
+
+		eth: ethernet-controller at 72000 {
+			compatible = "marvell,orion-eth";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x72000 0x4000>;
+			marvell,tx-checksum-limit = <1600>;
+			status = "disabled";
+
+			ethernet-port at 0 {
+				device_type = "network";
+				compatible = "marvell,orion-eth-port";
+				reg = <0>;
+				/* overwrite MAC address in bootloader */
+				local-mac-address = [00 00 00 00 00 00];
+				/* set phy-handle property in board file */
+			};
+		};
 	};
 };
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:00:19 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:00:19 +0200
Subject: [PATCH v6 2/7] ARM: kirkwood: add gigabit ethernet and mvmdio device
 tree nodes
In-Reply-To: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372762824-12202-3-git-send-email-sebastian.hesselbarth@gmail.com>

This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Kirkwood boards. Phy nodes are also added with reg property set on a
per-board basis.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Changelog:
v5->v6:
- rebase for v3.11-rc1
- also convert Sheevaplug and DB628x

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: netdev at vger.kernel.org
---
 arch/arm/boot/dts/kirkwood-cloudbox.dts            |   16 ++++++
 arch/arm/boot/dts/kirkwood-db.dtsi                 |   16 ++++++
 arch/arm/boot/dts/kirkwood-dnskw.dtsi              |   16 ++++++
 arch/arm/boot/dts/kirkwood-dockstar.dts            |   17 ++++++
 arch/arm/boot/dts/kirkwood-dreamplug.dts           |   28 +++++++++++
 arch/arm/boot/dts/kirkwood-goflexnet.dts           |   16 ++++++
 .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |   30 +++++++++++
 arch/arm/boot/dts/kirkwood-ib62x0.dts              |   16 ++++++
 arch/arm/boot/dts/kirkwood-iconnect.dts            |   16 ++++++
 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts      |   24 +++++++++
 arch/arm/boot/dts/kirkwood-is2.dts                 |    2 +
 arch/arm/boot/dts/kirkwood-km_kirkwood.dts         |   16 ++++++
 arch/arm/boot/dts/kirkwood-lsxl.dtsi               |   28 +++++++++++
 arch/arm/boot/dts/kirkwood-mplcec4.dts             |   27 ++++++++++
 .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  |   16 ++++++
 arch/arm/boot/dts/kirkwood-ns2-common.dtsi         |   16 ++++++
 arch/arm/boot/dts/kirkwood-ns2.dts                 |    2 +
 arch/arm/boot/dts/kirkwood-ns2lite.dts             |    2 +
 arch/arm/boot/dts/kirkwood-ns2max.dts              |    2 +
 arch/arm/boot/dts/kirkwood-ns2mini.dts             |    2 +
 arch/arm/boot/dts/kirkwood-openblocks_a6.dts       |   16 ++++++
 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi  |   16 ++++++
 arch/arm/boot/dts/kirkwood-topkick.dts             |   16 ++++++
 arch/arm/boot/dts/kirkwood-ts219-6281.dts          |    4 +-
 arch/arm/boot/dts/kirkwood-ts219-6282.dts          |    4 +-
 arch/arm/boot/dts/kirkwood-ts219.dtsi              |   16 ++++++
 arch/arm/boot/dts/kirkwood.dtsi                    |   52 ++++++++++++++++++++
 27 files changed, 430 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-cloudbox.dts b/arch/arm/boot/dts/kirkwood-cloudbox.dts
index 00c48d2..85eed62 100644
--- a/arch/arm/boot/dts/kirkwood-cloudbox.dts
+++ b/arch/arm/boot/dts/kirkwood-cloudbox.dts
@@ -89,3 +89,19 @@
 		gpios = <&gpio0 17 0>;
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-db.dtsi b/arch/arm/boot/dts/kirkwood-db.dtsi
index c87cfb8..ca8bf36 100644
--- a/arch/arm/boot/dts/kirkwood-db.dtsi
+++ b/arch/arm/boot/dts/kirkwood-db.dtsi
@@ -87,3 +87,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 8 {
+		device_type = "ethernet-phy";
+		reg = <8>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 0afe1d0..f600ed7 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -219,3 +219,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 8 {
+		device_type = "ethernet-phy";
+		reg = <8>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-dockstar.dts b/arch/arm/boot/dts/kirkwood-dockstar.dts
index 7714742..915aca6 100644
--- a/arch/arm/boot/dts/kirkwood-dockstar.dts
+++ b/arch/arm/boot/dts/kirkwood-dockstar.dts
@@ -90,3 +90,20 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		compatible = "marvell,88e1116";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 36c7ba3..300fbf8 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -99,3 +99,31 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+
+	ethphy1: ethernet-phy at 1 {
+		device_type = "ethernet-phy";
+		reg = <1>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-goflexnet.dts b/arch/arm/boot/dts/kirkwood-goflexnet.dts
index 31caa64..e9ba68e 100644
--- a/arch/arm/boot/dts/kirkwood-goflexnet.dts
+++ b/arch/arm/boot/dts/kirkwood-goflexnet.dts
@@ -170,3 +170,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
index 1e642f3..e696c31 100644
--- a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
+++ b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
@@ -96,3 +96,33 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		compatible = "marvell,88e1121";
+		reg = <0>;
+	};
+
+	ethphy1: ethernet-phy at 1 {
+		device_type = "ethernet-phy";
+		compatible = "marvell,88e1121";
+		reg = <1>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ib62x0.dts b/arch/arm/boot/dts/kirkwood-ib62x0.dts
index 20c4b08..69019b8 100644
--- a/arch/arm/boot/dts/kirkwood-ib62x0.dts
+++ b/arch/arm/boot/dts/kirkwood-ib62x0.dts
@@ -122,3 +122,19 @@
 
 
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 8 {
+		device_type = "ethernet-phy";
+		reg = <8>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-iconnect.dts b/arch/arm/boot/dts/kirkwood-iconnect.dts
index 441204e..3d99164 100644
--- a/arch/arm/boot/dts/kirkwood-iconnect.dts
+++ b/arch/arm/boot/dts/kirkwood-iconnect.dts
@@ -176,3 +176,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 11 {
+		device_type = "ethernet-phy";
+		reg = <11>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
index 00a7bfe..b08c733 100644
--- a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
+++ b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
@@ -194,3 +194,27 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy1: ethernet-phy at 11 {
+		device_type = "ethernet-phy";
+		reg = <11>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		speed = <1000>;
+		duplex = <1>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-is2.dts b/arch/arm/boot/dts/kirkwood-is2.dts
index c3f036b..ff9be45 100644
--- a/arch/arm/boot/dts/kirkwood-is2.dts
+++ b/arch/arm/boot/dts/kirkwood-is2.dts
@@ -30,3 +30,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <8>; };
diff --git a/arch/arm/boot/dts/kirkwood-km_kirkwood.dts b/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
index 5d9f5ea..466280b 100644
--- a/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
+++ b/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
@@ -50,3 +50,19 @@
 		i2c-gpio,delay-us = <2>;	/* ~100 kHz */
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
index 31b17f5..93397b1 100644
--- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
+++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
@@ -207,3 +207,31 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+
+	ethphy1: ethernet-phy at 8 {
+		device_type = "ethernet-phy";
+		reg = <8>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-mplcec4.dts b/arch/arm/boot/dts/kirkwood-mplcec4.dts
index 6179333..def825f 100644
--- a/arch/arm/boot/dts/kirkwood-mplcec4.dts
+++ b/arch/arm/boot/dts/kirkwood-mplcec4.dts
@@ -191,3 +191,30 @@
 	};
 };
 
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 1 {
+		device_type = "ethernet-phy";
+		reg = <1>;
+	};
+
+	ethphy1: ethernet-phy at 2 {
+		device_type = "ethernet-phy";
+		reg = <2>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
index ad6ade7..716b203 100644
--- a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
+++ b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
@@ -184,3 +184,19 @@
                 };
         };
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2-common.dtsi b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
index 2afac04..e7b8017 100644
--- a/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
@@ -84,3 +84,19 @@
 	};
 
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy {
+		device_type = "ethernet-phy";
+                /* overwrite reg property in board file */
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2.dts b/arch/arm/boot/dts/kirkwood-ns2.dts
index b50e93d..e93276d 100644
--- a/arch/arm/boot/dts/kirkwood-ns2.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2.dts
@@ -30,3 +30,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <8>; };
diff --git a/arch/arm/boot/dts/kirkwood-ns2lite.dts b/arch/arm/boot/dts/kirkwood-ns2lite.dts
index af8259f..34f5e69 100644
--- a/arch/arm/boot/dts/kirkwood-ns2lite.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2lite.dts
@@ -30,3 +30,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <0>; };
diff --git a/arch/arm/boot/dts/kirkwood-ns2max.dts b/arch/arm/boot/dts/kirkwood-ns2max.dts
index 85f24d2..f834c55 100644
--- a/arch/arm/boot/dts/kirkwood-ns2max.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2max.dts
@@ -49,3 +49,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <8>; };
diff --git a/arch/arm/boot/dts/kirkwood-ns2mini.dts b/arch/arm/boot/dts/kirkwood-ns2mini.dts
index 329e530..b6b66ea 100644
--- a/arch/arm/boot/dts/kirkwood-ns2mini.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2mini.dts
@@ -50,3 +50,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <0>; };
diff --git a/arch/arm/boot/dts/kirkwood-openblocks_a6.dts b/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
index 38dc851..7235f0c 100644
--- a/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
+++ b/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
@@ -166,3 +166,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
index f7143f1..f55a145 100644
--- a/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
@@ -91,3 +91,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-topkick.dts b/arch/arm/boot/dts/kirkwood-topkick.dts
index f2052d7..184b8c5 100644
--- a/arch/arm/boot/dts/kirkwood-topkick.dts
+++ b/arch/arm/boot/dts/kirkwood-topkick.dts
@@ -203,3 +203,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6281.dts b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
index 6dd1038..222435d 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6281.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
@@ -50,4 +50,6 @@
 			gpios = <&gpio0 16 1>;
 		};
 	};
-};
\ No newline at end of file
+};
+
+&ethphy0 { reg = <8>; };
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
index 6fdc5ff..510c555 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -58,4 +58,6 @@
 			gpios = <&gpio1 5 1>;
 		};
 	};
-};
\ No newline at end of file
+};
+
+&ethphy0 { reg = <0>; };
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
index 0c9a94c..102eaeb 100644
--- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -96,3 +96,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy {
+		device_type = "ethernet-phy";
+                /* overwrite reg property in board file */
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 078637c..ad56dd8 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -190,5 +190,57 @@
 			clocks = <&gate_clk 17>;
 			status = "okay";
 		};
+
+		mdio: mdio-bus at 72004 {
+			compatible = "marvell,orion-mdio";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x72004 0x84>;
+			interrupts = <46>;
+			clocks = <&gate_clk 0>;
+			status = "disabled";
+
+			/* add phy nodes in board file */
+		};
+
+		eth0: ethernet-controller at 72000 {
+			compatible = "marvell,kirkwood-eth";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x72000 0x4000>;
+			clocks = <&gate_clk 0>;
+			marvell,tx-checksum-limit = <1600>;
+			status = "disabled";
+
+			ethernet0-port at 0 {
+				device_type = "network";
+				compatible = "marvell,kirkwood-eth-port";
+				reg = <0>;
+				interrupts = <11>;
+				/* overwrite MAC address in bootloader */
+				local-mac-address = [00 00 00 00 00 00];
+				/* set phy-handle property in board file */
+			};
+		};
+
+		eth1: ethernet-controller at 76000 {
+			compatible = "marvell,kirkwood-eth";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x76000 0x4000>;
+			clocks = <&gate_clk 19>;
+			marvell,tx-checksum-limit = <1600>;
+			status = "disabled";
+
+			ethernet1-port at 1 {
+				device_type = "network";
+				compatible = "marvell,kirkwood-eth-port";
+				reg = <1>;
+				interrupts = <15>;
+				/* overwrite MAC address in bootloader */
+				local-mac-address = [00 00 00 00 00 00];
+				/* set phy-handle property in board file */
+			};
+		};
 	};
 };
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:00:22 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:00:22 +0200
Subject: [PATCH v6 5/7] ARM: kirkwood: remove redundant DT board files
In-Reply-To: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372762824-12202-6-git-send-email-sebastian.hesselbarth@gmail.com>

With DT support for mv643xx_eth board specific init for some boards now
is unneccessary. Remove those board files, Kconfig entries, and
corresponding entries in kirkwood_defconfig.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Changelog:
v5->v6:
- rebase for v3.11-rc1

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: netdev at vger.kernel.org
---
 arch/arm/configs/kirkwood_defconfig           |   22 ----
 arch/arm/mach-kirkwood/Kconfig                |  156 -------------------------
 arch/arm/mach-kirkwood/Makefile               |   23 +----
 arch/arm/mach-kirkwood/board-db88f628x-bp.c   |   24 ----
 arch/arm/mach-kirkwood/board-dnskw.c          |    7 -
 arch/arm/mach-kirkwood/board-dockstar.c       |   32 -----
 arch/arm/mach-kirkwood/board-dreamplug.c      |   35 ------
 arch/arm/mach-kirkwood/board-dt.c             |   84 +-------------
 arch/arm/mach-kirkwood/board-goflexnet.c      |   34 ------
 arch/arm/mach-kirkwood/board-guruplug.c       |   33 -----
 arch/arm/mach-kirkwood/board-ib62x0.c         |   29 -----
 arch/arm/mach-kirkwood/board-iconnect.c       |   24 ----
 arch/arm/mach-kirkwood/board-iomega_ix2_200.c |   34 ------
 arch/arm/mach-kirkwood/board-km_kirkwood.c    |   44 -------
 arch/arm/mach-kirkwood/board-lsxl.c           |   36 ------
 arch/arm/mach-kirkwood/board-mplcec4.c        |   35 ------
 arch/arm/mach-kirkwood/board-ns2.c            |   35 ------
 arch/arm/mach-kirkwood/board-openblocks_a6.c  |   26 ----
 arch/arm/mach-kirkwood/board-readynas.c       |   27 -----
 arch/arm/mach-kirkwood/board-sheevaplug.c     |   27 -----
 arch/arm/mach-kirkwood/board-ts219.c          |   40 -------
 arch/arm/mach-kirkwood/board-usi_topkick.c    |   29 -----
 22 files changed, 2 insertions(+), 834 deletions(-)
 delete mode 100644 arch/arm/mach-kirkwood/board-db88f628x-bp.c
 delete mode 100644 arch/arm/mach-kirkwood/board-dockstar.c
 delete mode 100644 arch/arm/mach-kirkwood/board-dreamplug.c
 delete mode 100644 arch/arm/mach-kirkwood/board-goflexnet.c
 delete mode 100644 arch/arm/mach-kirkwood/board-guruplug.c
 delete mode 100644 arch/arm/mach-kirkwood/board-ib62x0.c
 delete mode 100644 arch/arm/mach-kirkwood/board-iconnect.c
 delete mode 100644 arch/arm/mach-kirkwood/board-iomega_ix2_200.c
 delete mode 100644 arch/arm/mach-kirkwood/board-km_kirkwood.c
 delete mode 100644 arch/arm/mach-kirkwood/board-lsxl.c
 delete mode 100644 arch/arm/mach-kirkwood/board-mplcec4.c
 delete mode 100644 arch/arm/mach-kirkwood/board-ns2.c
 delete mode 100644 arch/arm/mach-kirkwood/board-openblocks_a6.c
 delete mode 100644 arch/arm/mach-kirkwood/board-readynas.c
 delete mode 100644 arch/arm/mach-kirkwood/board-sheevaplug.c
 delete mode 100644 arch/arm/mach-kirkwood/board-ts219.c
 delete mode 100644 arch/arm/mach-kirkwood/board-usi_topkick.c

diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
index 0f2aa61..3235808 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig
@@ -29,29 +29,7 @@ CONFIG_MACH_SHEEVAPLUG=y
 CONFIG_MACH_T5325=y
 CONFIG_MACH_TS219=y
 CONFIG_MACH_TS41X=y
-CONFIG_MACH_CLOUDBOX_DT=y
-CONFIG_MACH_DB88F628X_BP_DT=y
 CONFIG_MACH_DLINK_KIRKWOOD_DT=y
-CONFIG_MACH_DOCKSTAR_DT=y
-CONFIG_MACH_DREAMPLUG_DT=y
-CONFIG_MACH_GOFLEXNET_DT=y
-CONFIG_MACH_GURUPLUG_DT=y
-CONFIG_MACH_IB62X0_DT=y
-CONFIG_MACH_ICONNECT_DT=y
-CONFIG_MACH_INETSPACE_V2_DT=y
-CONFIG_MACH_IOMEGA_IX2_200_DT=y
-CONFIG_MACH_KM_KIRKWOOD_DT=y
-CONFIG_MACH_LSXL_DT=y
-CONFIG_MACH_MPLCEC4_DT=y
-CONFIG_MACH_NETSPACE_LITE_V2_DT=y
-CONFIG_MACH_NETSPACE_MAX_V2_DT=y
-CONFIG_MACH_NETSPACE_MINI_V2_DT=y
-CONFIG_MACH_NETSPACE_V2_DT=y
-CONFIG_MACH_NSA310_DT=y
-CONFIG_MACH_OPENBLOCKS_A6_DT=y
-CONFIG_MACH_READYNAS_DT=y
-CONFIG_MACH_SHEEVAPLUG_DT=y
-CONFIG_MACH_TOPKICK_DT=y
 CONFIG_MACH_TS219_DT=y
 # CONFIG_CPU_FEROCEON_OLD_ID is not set
 CONFIG_PCI_MVEBU=y
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index b634f96..493c71a 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -139,20 +139,6 @@ config ARCH_KIRKWOOD_DT
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell Kirkwood using flattened device tree.
 
-config MACH_CLOUDBOX_DT
-	bool "LaCie CloudBox NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  CloudBox NAS, using Flattened Device Tree.
-
-config MACH_DB88F628X_BP_DT
-	bool "Marvell DB-88F628x-BP Development Board (Flattened Device Tree)"
-	help
-	  Say 'Y' here if you want your kernel to support the Marvell
-	  DB-88F6281-BP and DB-88F6282-BP Development Board (Flattened
-	  Device Tree).
-
 config MACH_DLINK_KIRKWOOD_DT
 	bool "D-Link Kirkwood-based NAS (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
@@ -161,148 +147,6 @@ config MACH_DLINK_KIRKWOOD_DT
 	  Kirkwood-based D-Link NASes such as DNS-320 & DNS-325,
 	  using Flattened Device Tree.
 
-config MACH_DOCKSTAR_DT
-	bool "Seagate FreeAgent Dockstar (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Seagate FreeAgent Dockstar (Flattened Device Tree).
-
-config MACH_DREAMPLUG_DT
-	bool "Marvell DreamPlug (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell DreamPlug (Flattened Device Tree).
-
-config MACH_GOFLEXNET_DT
-	bool "Seagate GoFlex Net (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Seagate GoFlex Net (Flattened Device Tree).
-
-config MACH_GURUPLUG_DT
-	bool "Marvell GuruPlug Reference Board (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell GuruPlug Reference Board (Flattened Device Tree).
-
-config MACH_IB62X0_DT
-	bool "RaidSonic IB-NAS6210, IB-NAS6220 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  RaidSonic IB-NAS6210 & IB-NAS6220 devices, using
-	  Flattened Device Tree.
-
-config MACH_ICONNECT_DT
-	bool "Iomega Iconnect (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here to enable Iomega Iconnect support.
-
-config MACH_INETSPACE_V2_DT
-	bool "LaCie Internet Space v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Internet Space v2 NAS, using Flattened Device Tree.
-
-config MACH_IOMEGA_IX2_200_DT
-	bool "Iomega StorCenter ix2-200 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Iomega StorCenter ix2-200 (Flattened Device Tree).
-
-config MACH_KM_KIRKWOOD_DT
-	bool "Keymile Kirkwood Reference Design (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Keymile Kirkwood Reference Desgin, using Flattened Device Tree.
-
-config MACH_LSXL_DT
-	bool "Buffalo Linkstation LS-XHL, LS-CHLv2 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	select POWER_RESET_RESTART
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Buffalo Linkstation LS-XHL & LS-CHLv2 devices, using
-	  Flattened Device Tree.
-
-config MACH_MPLCEC4_DT
-	bool "MPL CEC4 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  MPL CEC4 (Flattened Device Tree).
-
-config MACH_NETSPACE_LITE_V2_DT
-	bool "LaCie Network Space Lite v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space Lite v2 NAS, using Flattened Device Tree.
-
-config MACH_NETSPACE_MAX_V2_DT
-	bool "LaCie Network Space Max v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space Max v2 NAS, using Flattened Device Tree.
-
-config MACH_NETSPACE_MINI_V2_DT
-	bool "LaCie Network Space Mini v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space Mini v2 NAS using Flattened Device Tree.
-
-	  This board is embedded in a product named CloudBox, which
-	  provides automatic backup on a 100GB cloud storage. This
-	  should not confused with a more recent LaCie NAS also named
-	  CloudBox. For this last, the disk capacity is 1TB or above.
-
-config MACH_NETSPACE_V2_DT
-	bool "LaCie Network Space v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space v2 NAS, using Flattened Device Tree.
-
-config MACH_OPENBLOCKS_A6_DT
-	bool "Plat'Home OpenBlocks A6 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Plat'Home OpenBlocks A6 (Flattened Device Tree).
-
-config MACH_READYNAS_DT
-	bool "NETGEAR ReadyNAS Duo v2 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	select ARM_APPENDED_DTB
-	select ARM_ATAG_DTB_COMPAT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  NETGEAR ReadyNAS Duo v2 using Fattened Device Tree.
-
-config MACH_SHEEVAPLUG_DT
-	bool "Marvell (eSATA) SheevaPlug (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell (eSATA) SheevaPlug (Flattened Device Tree).
-
-config MACH_TOPKICK_DT
-	bool "USI Topkick (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  USI Topkick, using Flattened Device Tree
-
 config MACH_TS219_DT
 	bool "Device Tree for QNAP TS-11X, TS-21X NAS"
 	select ARCH_KIRKWOOD_DT
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index ac4cd75..062f8c7 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -19,26 +19,5 @@ obj-$(CONFIG_MACH_TS219)		+= ts219-setup.o tsx1x-common.o
 obj-$(CONFIG_MACH_TS41X)		+= ts41x-setup.o tsx1x-common.o
 
 obj-$(CONFIG_ARCH_KIRKWOOD_DT)		+= board-dt.o
-obj-$(CONFIG_MACH_CLOUDBOX_DT)		+= board-ns2.o
-obj-$(CONFIG_MACH_DB88F628X_BP_DT)	+= board-db88f628x-bp.o
 obj-$(CONFIG_MACH_DLINK_KIRKWOOD_DT)	+= board-dnskw.o
-obj-$(CONFIG_MACH_DOCKSTAR_DT)		+= board-dockstar.o
-obj-$(CONFIG_MACH_DREAMPLUG_DT)		+= board-dreamplug.o
-obj-$(CONFIG_MACH_GOFLEXNET_DT)		+= board-goflexnet.o
-obj-$(CONFIG_MACH_GURUPLUG_DT)		+= board-guruplug.o
-obj-$(CONFIG_MACH_IB62X0_DT)		+= board-ib62x0.o
-obj-$(CONFIG_MACH_ICONNECT_DT)		+= board-iconnect.o
-obj-$(CONFIG_MACH_INETSPACE_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_IOMEGA_IX2_200_DT)	+= board-iomega_ix2_200.o
-obj-$(CONFIG_MACH_KM_KIRKWOOD_DT)	+= board-km_kirkwood.o
-obj-$(CONFIG_MACH_LSXL_DT)		+= board-lsxl.o
-obj-$(CONFIG_MACH_MPLCEC4_DT)		+= board-mplcec4.o
-obj-$(CONFIG_MACH_NETSPACE_LITE_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_NETSPACE_MAX_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_NETSPACE_MINI_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_NETSPACE_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_OPENBLOCKS_A6_DT)	+= board-openblocks_a6.o
-obj-$(CONFIG_MACH_READYNAS_DT)		+= board-readynas.o
-obj-$(CONFIG_MACH_SHEEVAPLUG_DT)	+= board-sheevaplug.o
-obj-$(CONFIG_MACH_TOPKICK_DT)		+= board-usi_topkick.o
-obj-$(CONFIG_MACH_TS219_DT)		+= board-ts219.o tsx1x-common.o
+obj-$(CONFIG_MACH_TS219_DT)		+= tsx1x-common.o
diff --git a/arch/arm/mach-kirkwood/board-db88f628x-bp.c b/arch/arm/mach-kirkwood/board-db88f628x-bp.c
deleted file mode 100644
index 2f574bc..0000000
--- a/arch/arm/mach-kirkwood/board-db88f628x-bp.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * Saeed Bishara <saeed at marvell.com>
- *
- * Marvell DB-88F628{1,2}-BP Development Board Setup
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/of.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data db88f628x_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init db88f628x_init(void)
-{
-	kirkwood_ge00_init(&db88f628x_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-dnskw.c b/arch/arm/mach-kirkwood/board-dnskw.c
index a1aa87f..2af7a95 100644
--- a/arch/arm/mach-kirkwood/board-dnskw.c
+++ b/arch/arm/mach-kirkwood/board-dnskw.c
@@ -14,14 +14,9 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
 #include <linux/gpio.h>
 #include "common.h"
 
-static struct mv643xx_eth_platform_data dnskw_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
 /* Register any GPIO for output and set the value */
 static void __init dnskw_gpio_register(unsigned gpio, char *name, int def)
 {
@@ -36,8 +31,6 @@ static void __init dnskw_gpio_register(unsigned gpio, char *name, int def)
 
 void __init dnskw_init(void)
 {
-	kirkwood_ge00_init(&dnskw_ge00_data);
-
 	/* Set NAS to turn back on after a power failure */
 	dnskw_gpio_register(37, "dnskw:power:recover", 1);
 }
diff --git a/arch/arm/mach-kirkwood/board-dockstar.c b/arch/arm/mach-kirkwood/board-dockstar.c
deleted file mode 100644
index d7196db..0000000
--- a/arch/arm/mach-kirkwood/board-dockstar.c
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-dockstar.c
- *
- * Seagate FreeAgent Dockstar Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- *
- * Copied and modified for Seagate GoFlex Net support by
- * Joshua Coombs <josh.coombs at gmail.com> based on ArchLinux ARM's
- * GoFlex kernel patches.
- *
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data dockstar_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init dockstar_dt_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&dockstar_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-dreamplug.c b/arch/arm/mach-kirkwood/board-dreamplug.c
deleted file mode 100644
index 0903242..0000000
--- a/arch/arm/mach-kirkwood/board-dreamplug.c
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Copyright 2012 (C), Jason Cooper <jason at lakedaemon.net>
- *
- * arch/arm/mach-kirkwood/board-dreamplug.c
- *
- * Marvell DreamPlug Reference Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/gpio.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data dreamplug_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data dreamplug_ge01_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(1),
-};
-
-void __init dreamplug_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&dreamplug_ge00_data);
-	kirkwood_ge01_init(&dreamplug_ge01_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 6e122ed..a3271f6 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -102,96 +102,14 @@ static void __init kirkwood_dt_init(void)
 	kexec_reinit = kirkwood_enable_pcie;
 #endif
 
-	if (of_machine_is_compatible("globalscale,dreamplug"))
-		dreamplug_init();
-
-	if (of_machine_is_compatible("globalscale,guruplug"))
-		guruplug_dt_init();
-
-	if (of_machine_is_compatible("globalscale,sheevaplug"))
-		sheevaplug_dt_init();
-
 	if (of_machine_is_compatible("dlink,dns-kirkwood"))
 		dnskw_init();
 
-	if (of_machine_is_compatible("iom,iconnect"))
-		iconnect_init();
-
-	if (of_machine_is_compatible("raidsonic,ib-nas62x0"))
-		ib62x0_init();
-
-	if (of_machine_is_compatible("qnap,ts219"))
-		qnap_dt_ts219_init();
-
-	if (of_machine_is_compatible("seagate,dockstar"))
-		dockstar_dt_init();
-
-	if (of_machine_is_compatible("seagate,goflexnet"))
-		goflexnet_init();
-
-	if (of_machine_is_compatible("buffalo,lsxl"))
-		lsxl_init();
-
-	if (of_machine_is_compatible("iom,ix2-200"))
-		iomega_ix2_200_init();
-
-	if (of_machine_is_compatible("keymile,km_kirkwood"))
-		km_kirkwood_init();
-
-	if (of_machine_is_compatible("lacie,cloudbox") ||
-	    of_machine_is_compatible("lacie,inetspace_v2") ||
-	    of_machine_is_compatible("lacie,netspace_lite_v2") ||
-	    of_machine_is_compatible("lacie,netspace_max_v2") ||
-	    of_machine_is_compatible("lacie,netspace_mini_v2") ||
-	    of_machine_is_compatible("lacie,netspace_v2"))
-		ns2_init();
-
-	if (of_machine_is_compatible("marvell,db-88f6281-bp") ||
-	    of_machine_is_compatible("marvell,db-88f6282-bp"))
-		db88f628x_init();
-
-	if (of_machine_is_compatible("mpl,cec4"))
-		mplcec4_init();
-
-	if (of_machine_is_compatible("netgear,readynas-duo-v2"))
-		netgear_readynas_init();
-
-	if (of_machine_is_compatible("plathome,openblocks-a6"))
-		openblocks_a6_init();
-
-	if (of_machine_is_compatible("usi,topkick"))
-		usi_topkick_init();
-
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
 static const char * const kirkwood_dt_board_compat[] = {
-	"globalscale,dreamplug",
-	"globalscale,guruplug",
-	"globalscale,sheevaplug",
-	"dlink,dns-320",
-	"dlink,dns-325",
-	"iom,iconnect",
-	"raidsonic,ib-nas62x0",
-	"qnap,ts219",
-	"seagate,dockstar",
-	"seagate,goflexnet",
-	"buffalo,lsxl",
-	"iom,ix2-200",
-	"keymile,km_kirkwood",
-	"lacie,cloudbox",
-	"lacie,inetspace_v2",
-	"lacie,netspace_lite_v2",
-	"lacie,netspace_max_v2",
-	"lacie,netspace_mini_v2",
-	"lacie,netspace_v2",
-	"marvell,db-88f6281-bp",
-	"marvell,db-88f6282-bp",
-	"mpl,cec4",
-	"netgear,readynas-duo-v2",
-	"plathome,openblocks-a6",
-	"usi,topkick",
-	"zyxel,nsa310",
+	"marvell,kirkwood",
 	NULL
 };
 
diff --git a/arch/arm/mach-kirkwood/board-goflexnet.c b/arch/arm/mach-kirkwood/board-goflexnet.c
deleted file mode 100644
index 9db979a..0000000
--- a/arch/arm/mach-kirkwood/board-goflexnet.c
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * Copyright 2012 (C), Jason Cooper <jason at lakedaemon.net>
- *
- * arch/arm/mach-kirkwood/board-goflexnet.c
- *
- * Seagate GoFlext Net Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- *
- * Copied and modified for Seagate GoFlex Net support by
- * Joshua Coombs <josh.coombs at gmail.com> based on ArchLinux ARM's
- * GoFlex kernel patches.
- *
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data goflexnet_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init goflexnet_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&goflexnet_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-guruplug.c b/arch/arm/mach-kirkwood/board-guruplug.c
deleted file mode 100644
index a857163..0000000
--- a/arch/arm/mach-kirkwood/board-guruplug.c
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-guruplug.c
- *
- * Marvell Guruplug Reference Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/gpio.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data guruplug_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data guruplug_ge01_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(1),
-};
-
-void __init guruplug_dt_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&guruplug_ge00_data);
-	kirkwood_ge01_init(&guruplug_ge01_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-ib62x0.c b/arch/arm/mach-kirkwood/board-ib62x0.c
deleted file mode 100644
index 9a857ae..0000000
--- a/arch/arm/mach-kirkwood/board-ib62x0.c
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * Copyright 2012 (C), Simon Baatz <gmbnomis at gmail.com>
- *
- * arch/arm/mach-kirkwood/board-ib62x0.c
- *
- * RaidSonic ICY BOX IB-NAS6210 & IB-NAS6220 init for drivers not
- * converted to flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data ib62x0_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init ib62x0_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&ib62x0_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-iconnect.c b/arch/arm/mach-kirkwood/board-iconnect.c
deleted file mode 100644
index 98b5ad1..0000000
--- a/arch/arm/mach-kirkwood/board-iconnect.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-iconnect.c
- *
- * Iomega i-connect Board Setup
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/of.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data iconnect_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(11),
-};
-
-void __init iconnect_init(void)
-{
-	kirkwood_ge00_init(&iconnect_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-iomega_ix2_200.c b/arch/arm/mach-kirkwood/board-iomega_ix2_200.c
deleted file mode 100644
index e5f7041..0000000
--- a/arch/arm/mach-kirkwood/board-iomega_ix2_200.c
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-iomega_ix2_200.c
- *
- * Iomega StorCenter ix2-200
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/ethtool.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data iomega_ix2_200_ge00_data = {
-	.phy_addr       = MV643XX_ETH_PHY_NONE,
-	.speed          = SPEED_1000,
-	.duplex         = DUPLEX_FULL,
-};
-
-static struct mv643xx_eth_platform_data iomega_ix2_200_ge01_data = {
-        .phy_addr       = MV643XX_ETH_PHY_ADDR(11),
-};
-
-void __init iomega_ix2_200_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&iomega_ix2_200_ge00_data);
-	kirkwood_ge01_init(&iomega_ix2_200_ge01_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-km_kirkwood.c b/arch/arm/mach-kirkwood/board-km_kirkwood.c
deleted file mode 100644
index 44e4605..0000000
--- a/arch/arm/mach-kirkwood/board-km_kirkwood.c
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * Copyright 2012 2012 KEYMILE AG, CH-3097 Bern
- * Valentin Longchamp <valentin.longchamp at keymile.com>
- *
- * arch/arm/mach-kirkwood/board-km_kirkwood.c
- *
- * Keymile km_kirkwood Reference Desing Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/clk.h>
-#include <linux/clk-private.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data km_kirkwood_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init km_kirkwood_init(void)
-{
-	struct clk *sata_clk;
-	/*
-	 * Our variant of kirkwood (integrated in the Bobcat) hangs on accessing
-	 * SATA bits (14-15) of the Clock Gating Control Register. Since these
-	 * devices are also not present in this variant, their clocks get
-	 * disabled because unused when clk_disable_unused() gets called.
-	 * That's why we change the flags to these clocks to CLK_IGNORE_UNUSED
-	 */
-	sata_clk = clk_get_sys("sata_mv.0", "0");
-	if (!IS_ERR(sata_clk))
-		sata_clk->flags |= CLK_IGNORE_UNUSED;
-	sata_clk = clk_get_sys("sata_mv.0", "1");
-	if (!IS_ERR(sata_clk))
-		sata_clk->flags |= CLK_IGNORE_UNUSED;
-
-	kirkwood_ge00_init(&km_kirkwood_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-lsxl.c b/arch/arm/mach-kirkwood/board-lsxl.c
deleted file mode 100644
index 3483952..0000000
--- a/arch/arm/mach-kirkwood/board-lsxl.c
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * Copyright 2012 (C), Michael Walle <michael at walle.cc>
- *
- * arch/arm/mach-kirkwood/board-lsxl.c
- *
- * Buffalo Linkstation LS-XHL and LS-CHLv2 init for drivers not
- * converted to flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data lsxl_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data lsxl_ge01_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init lsxl_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-
-	kirkwood_ge00_init(&lsxl_ge00_data);
-	kirkwood_ge01_init(&lsxl_ge01_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-mplcec4.c b/arch/arm/mach-kirkwood/board-mplcec4.c
deleted file mode 100644
index 938712e..0000000
--- a/arch/arm/mach-kirkwood/board-mplcec4.c
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Copyright (C) 2012 MPL AG, Switzerland
- * Stefan Peter <s.peter at mpl.ch>
- *
- * arch/arm/mach-kirkwood/board-mplcec4.c
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data mplcec4_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(1),
-};
-
-static struct mv643xx_eth_platform_data mplcec4_ge01_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(2),
-};
-
-void __init mplcec4_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&mplcec4_ge00_data);
-	kirkwood_ge01_init(&mplcec4_ge01_data);
-}
-
-
-
diff --git a/arch/arm/mach-kirkwood/board-ns2.c b/arch/arm/mach-kirkwood/board-ns2.c
deleted file mode 100644
index f8f6605..0000000
--- a/arch/arm/mach-kirkwood/board-ns2.c
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Copyright 2012 (C), Simon Guinot <simon.guinot at sequanux.org>
- *
- * arch/arm/mach-kirkwood/board-ns2.c
- *
- * LaCie Network Space v2 board (and parents) initialization for drivers
- * not converted to flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/of.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data ns2_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init ns2_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	if (of_machine_is_compatible("lacie,cloudbox") ||
-	    of_machine_is_compatible("lacie,netspace_lite_v2") ||
-	    of_machine_is_compatible("lacie,netspace_mini_v2"))
-		ns2_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
-	kirkwood_ge00_init(&ns2_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-openblocks_a6.c b/arch/arm/mach-kirkwood/board-openblocks_a6.c
deleted file mode 100644
index b11d8fd..0000000
--- a/arch/arm/mach-kirkwood/board-openblocks_a6.c
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * Copyright 2012 Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
- *
- * arch/arm/mach-kirkwood/board-openblocks_a6.c
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data openblocks_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init openblocks_a6_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&openblocks_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-readynas.c b/arch/arm/mach-kirkwood/board-readynas.c
deleted file mode 100644
index 341b82d..0000000
--- a/arch/arm/mach-kirkwood/board-readynas.c
+++ /dev/null
@@ -1,27 +0,0 @@
-/*
- * NETGEAR ReadyNAS Duo v2 Board setup for drivers not already
- * converted to DT.
- *
- * Copyright (C) 2013, Arnaud EBALARD <arno at natisbad.org>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
-#include <mach/kirkwood.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data netgear_readynas_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init netgear_readynas_init(void)
-{
-	kirkwood_ge00_init(&netgear_readynas_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-sheevaplug.c b/arch/arm/mach-kirkwood/board-sheevaplug.c
deleted file mode 100644
index fa38937..0000000
--- a/arch/arm/mach-kirkwood/board-sheevaplug.c
+++ /dev/null
@@ -1,27 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-sheevaplug.c
- *
- * Marvell Sheevaplug Reference Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data sheevaplug_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init sheevaplug_dt_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&sheevaplug_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
deleted file mode 100644
index 860f44a..0000000
--- a/arch/arm/mach-kirkwood/board-ts219.c
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- *
- * QNAP TS-11x/TS-21x Turbo NAS Board Setup via DT
- *
- * Copyright (C) 2012 Andrew Lunn <andrew at lunn.ch>
- *
- * Based on the board file ts219-setup.c:
- *
- * Copyright (C) 2009  Martin Michlmayr <tbm at cyrius.com>
- * Copyright (C) 2008  Byron Bradley <byron.bbradley at gmail.com>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <mach/kirkwood.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data qnap_ts219_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init qnap_dt_ts219_init(void)
-{
-	u32 dev, rev;
-
-	kirkwood_pcie_id(&dev, &rev);
-	if (dev == MV88F6282_DEV_ID)
-		qnap_ts219_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
-
-	kirkwood_ge00_init(&qnap_ts219_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-usi_topkick.c b/arch/arm/mach-kirkwood/board-usi_topkick.c
deleted file mode 100644
index 1cc04ec..0000000
--- a/arch/arm/mach-kirkwood/board-usi_topkick.c
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * Copyright 2012 (C), Jason Cooper <jason at lakedaemon.net>
- *
- * arch/arm/mach-kirkwood/board-usi_topkick.c
- *
- * USI Topkick Init for drivers not converted to flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/gpio.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data topkick_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init usi_topkick_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&topkick_ge00_data);
-}
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:03:36 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:03:36 +0200
Subject: [PATCH v4 0/7] ARM: mvebu: switch to DT probed irqchip and clocksource
Message-ID: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>

This patch set converts Marvell Dove and Kirkwood DT enabled boards
to probe irqchip and clocksource by DT. The corresponding irqchip and
clocksource drivers have been taken by Thomas Gleixner and Daniel Lezcano
respectively. This patch set is based on next-20130701 plus tip/core and
timers/clockevents. Also, mv643xx_eth DT patches sent earlier are applied.

Unfortunately, the same compatible string is used by irqchip driver and
irq DT stub in plat-orion/irq.c while reg layout is different. This patch
set should be applied as a whole only, as device tree conversion breaks
kernel boot until the corresponding second patch is applied. As this set
is Marvell SoC related only, I suggest to take it all through Jason
Cooper's branch.

Patch set version has been bumped to v4, but this only contains the
remaining Marvell related patches. irqchip and clocksource drivers from
v3 have already been taken by the respective maintainers.

The first three patches convert Dove, Kirkwood, and Orion5x DT files to
the new reg layout. Patch 4 and 5 add the new clocksource and irqchip
nodes. Patch 6 also removes an obsolete clock gate workaround from
Kirkwood DT board setup. Patch 7 then updates the irq driver DT stub in
plat-orion/irq to reflect the changed reg layout. The irq driver DT stub
is still used on Orion5x until proper DT clk provider is available.

The patch set has been tested on Dove, and compile-tested on Kirkwood
and Orion5x defconfig.

Sebastian Hesselbarth (7):
  ARM: dove: move device tree nodes to DT irqchip and clocksource
  ARM: kirkwood: move device tree nodes to DT irqchip and clocksource
  ARM: orion5x: update intc device tree node to new reg layout
  ARM: dove: convert to DT irqchip and clocksource
  ARM: kirkwood: convert to DT irqchip and clocksource
  ARM: kirkwood: remove obsolete SDIO clock gate workaround
  ARM: plat-orion: add reg offset to DT irq driver stub

 arch/arm/boot/dts/dove.dtsi       |   21 +++++++++++++++++++--
 arch/arm/boot/dts/kirkwood.dtsi   |   35 +++++++++++++++++++++++++++--------
 arch/arm/boot/dts/orion5x.dtsi    |    5 +++--
 arch/arm/mach-dove/Kconfig        |    2 ++
 arch/arm/mach-dove/Makefile       |    4 ++--
 arch/arm/mach-dove/board-dt.c     |   23 ++++++++++++++++-------
 arch/arm/mach-kirkwood/Kconfig    |   22 ++++++++++++++++++++++
 arch/arm/mach-kirkwood/Makefile   |    4 ++--
 arch/arm/mach-kirkwood/board-dt.c |   28 +++++++++++++++++-----------
 arch/arm/plat-orion/irq.c         |    2 +-
 10 files changed, 111 insertions(+), 35 deletions(-)

---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:03:38 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:03:38 +0200
Subject: [PATCH v4 2/7] ARM: kirkwood: move device tree nodes to DT irqchip
 and clocksource
In-Reply-To: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372763023-12374-3-git-send-email-sebastian.hesselbarth@gmail.com>

With recent support for true irqchip and clocksource drivers for Orion
SoCs, now make use of it on DT enabled Kirkwood boards.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
--- 
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/kirkwood.dtsi |   35 +++++++++++++++++++++++++++--------
 1 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index ad56dd8..204f44f 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -20,13 +20,6 @@
 	       gpio0 = &gpio0;
 	       gpio1 = &gpio1;
 	};
-	intc: interrupt-controller {
-		compatible = "marvell,orion-intc", "marvell,intc";
-		interrupt-controller;
-		#interrupt-cells = <1>;
-		reg = <0xf1020204 0x04>,
-		      <0xf1020214 0x04>;
-	};
 
 	ocp at f1000000 {
 		compatible = "simple-bus";
@@ -37,6 +30,30 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 
+		timer: timer at 20300 {
+			compatible = "marvell,orion-timer";
+			reg = <0x20300 0x20>;
+			interrupt-parent = <&bridge_intc>;
+			interrupts = <1>, <2>;
+			clocks = <&core_clk 0>;
+		};
+
+		intc: main-interrupt-ctrl at 20200 {
+			compatible = "marvell,orion-intc";
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			reg = <0x20200 0x10>, <0x20210 0x10>;
+		};
+
+		bridge_intc: bridge-interrupt-ctrl at 20110 {
+			compatible = "marvell,orion-bridge-intc";
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			reg = <0x20110 0x8>;
+			interrupts = <1>;
+			marvell,#interrupts = <6>;
+		};
+
 		core_clk: core-clocks at 10030 {
 			compatible = "marvell,kirkwood-core-clock";
 			reg = <0x10030 0x4>;
@@ -103,9 +120,11 @@
 			#clock-cells = <1>;
 		};
 
-		wdt at 20300 {
+		wdt: watchdog-timer at 20300 {
 			compatible = "marvell,orion-wdt";
 			reg = <0x20300 0x28>;
+			interrupt-parent = <&bridge_intc>;
+			interrupts = <3>;
 			clocks = <&gate_clk 7>;
 			status = "okay";
 		};
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:03:37 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:03:37 +0200
Subject: [PATCH v4 1/7] ARM: dove: move device tree nodes to DT irqchip and
 clocksource
In-Reply-To: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372763023-12374-2-git-send-email-sebastian.hesselbarth@gmail.com>

With recent support for true irqchip and clocksource drivers for Orion
SoCs, now make use of it on DT enabled Dove boards.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
--- 
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove.dtsi |   21 +++++++++++++++++++--
 1 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 5e394a6..44f50c4 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -30,11 +30,28 @@
 			marvell,tauros2-cache-features = <0>;
 		};
 
-		intc: interrupt-controller {
+		timer: timer at 20300 {
+			compatible = "marvell,orion-timer";
+			reg = <0x20300 0x20>;
+			interrupt-parent = <&bridge_intc>;
+			interrupts = <1>, <2>;
+			clocks = <&core_clk 0>;
+		};
+
+		intc: main-interrupt-ctrl at 20200 {
 			compatible = "marvell,orion-intc";
 			interrupt-controller;
 			#interrupt-cells = <1>;
-			reg = <0x20204 0x04>, <0x20214 0x04>;
+			reg = <0x20200 0x10>, <0x20210 0x10>;
+		};
+
+		bridge_intc: bridge-interrupt-ctrl at 20110 {
+			compatible = "marvell,orion-bridge-intc";
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			reg = <0x20110 0x8>;
+			interrupts = <0>;
+			marvell,#interrupts = <5>;
 		};
 
 		core_clk: core-clocks at d0214 {
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:03:39 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:03:39 +0200
Subject: [PATCH v4 3/7] ARM: orion5x: update intc device tree node to new reg
 layout
In-Reply-To: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372763023-12374-4-git-send-email-sebastian.hesselbarth@gmail.com>

Future irqchip driver for Orion SoCs has a modified reg layout starting
from CAUSE register. The former DT irq driver stub just used what the
non-DT driver wants. Currently, orion5x is not ready for irqchip driver
because of legacy timer and missing DT clk provider. To ease future
conversion and just because orion-intc binding documentation already
reflects new reg layout, we convert orion5x DT now.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
--- 
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/orion5x.dtsi |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
index 2d241fc..ede6c3b 100644
--- a/arch/arm/boot/dts/orion5x.dtsi
+++ b/arch/arm/boot/dts/orion5x.dtsi
@@ -16,11 +16,12 @@
 	aliases {
 		gpio0 = &gpio0;
 	};
+
 	intc: interrupt-controller {
-		compatible = "marvell,orion-intc", "marvell,intc";
+		compatible = "marvell,orion-intc";
 		interrupt-controller;
 		#interrupt-cells = <1>;
-		reg = <0xf1020204 0x04>;
+		reg = <0xf1020200 0x08>;
 	};
 
 	ocp at f1000000 {
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:03:42 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:03:42 +0200
Subject: [PATCH v4 6/7] ARM: kirkwood: remove obsolete SDIO clock gate
 workaround
In-Reply-To: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372763023-12374-7-git-send-email-sebastian.hesselbarth@gmail.com>

Kirkwood DT boards have been converted to DT SDIO already, we can now
remove the legacy clock gate workaround for SDIO clock.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
--- 
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/mach-kirkwood/board-dt.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 385244c..a2c8c20 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -52,10 +52,6 @@ static void __init kirkwood_legacy_clk_init(void)
 	orion_clkdev_add("1", "pcie",
 			 of_clk_get_from_provider(&clkspec));
 
-	clkspec.args[0] = CGC_BIT_SDIO;
-	orion_clkdev_add(NULL, "mvsdio",
-			 of_clk_get_from_provider(&clkspec));
-
 	/*
 	 * The ethernet interfaces forget the MAC address assigned by
 	 * u-boot if the clocks are turned off. Until proper DT support
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:03:40 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:03:40 +0200
Subject: [PATCH v4 4/7] ARM: dove: convert to DT irqchip and clocksource
In-Reply-To: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372763023-12374-5-git-send-email-sebastian.hesselbarth@gmail.com>

With recent support for true irqchip and clocksource drivers for Orion
SoCs, now make use of it on DT enabled Dove boards.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
--- 
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/mach-dove/Kconfig    |    2 ++
 arch/arm/mach-dove/Makefile   |    4 ++--
 arch/arm/mach-dove/board-dt.c |   23 ++++++++++++++++-------
 3 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
index dff7b2f..0bc7cdf 100644
--- a/arch/arm/mach-dove/Kconfig
+++ b/arch/arm/mach-dove/Kconfig
@@ -23,6 +23,8 @@ config MACH_CM_A510
 config MACH_DOVE_DT
 	bool "Marvell Dove Flattened Device Tree"
 	select DOVE_CLK
+	select ORION_IRQCHIP
+	select ORION_TIMER
 	select REGULATOR
 	select REGULATOR_FIXED_VOLTAGE
 	select USE_OF
diff --git a/arch/arm/mach-dove/Makefile b/arch/arm/mach-dove/Makefile
index 4d9d2ff..cbc5c06 100644
--- a/arch/arm/mach-dove/Makefile
+++ b/arch/arm/mach-dove/Makefile
@@ -1,5 +1,5 @@
-obj-y				+= common.o irq.o
-obj-$(CONFIG_DOVE_LEGACY)	+= mpp.o
+obj-y				+= common.o
+obj-$(CONFIG_DOVE_LEGACY)	+= irq.o mpp.o
 obj-$(CONFIG_PCI)		+= pcie.o
 obj-$(CONFIG_MACH_DOVE_DB)	+= dove-db-setup.o
 obj-$(CONFIG_MACH_DOVE_DT)	+= board-dt.o
diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-dove/board-dt.c
index b5ccc1c..49f72a8 100644
--- a/arch/arm/mach-dove/board-dt.c
+++ b/arch/arm/mach-dove/board-dt.c
@@ -10,11 +10,14 @@
 
 #include <linux/init.h>
 #include <linux/clk-provider.h>
+#include <linux/clocksource.h>
+#include <linux/irqchip.h>
 #include <linux/of.h>
 #include <linux/of_platform.h>
 #include <linux/platform_data/usb-ehci-orion.h>
 #include <asm/hardware/cache-tauros2.h>
 #include <asm/mach/arch.h>
+#include <mach/dove.h>
 #include <mach/pm.h>
 #include <plat/common.h>
 #include <plat/irq.h>
@@ -42,10 +45,17 @@ static void __init dove_legacy_clk_init(void)
 			 of_clk_get_from_provider(&clkspec));
 }
 
-static void __init dove_of_clk_init(void)
+static void __init dove_dt_time_init(void)
 {
 	of_clk_init(NULL);
-	dove_legacy_clk_init();
+	clocksource_of_init();
+}
+
+static void __init dove_dt_init_early(void)
+{
+	mvebu_mbus_init("marvell,dove-mbus",
+			BRIDGE_WINS_BASE, BRIDGE_WINS_SZ,
+			DOVE_MC_WINS_BASE, DOVE_MC_WINS_SZ);
 }
 
 static void __init dove_dt_init(void)
@@ -57,8 +67,8 @@ static void __init dove_dt_init(void)
 #endif
 	dove_setup_cpu_wins();
 
-	/* Setup root of clk tree */
-	dove_of_clk_init();
+	/* Setup clocks for legacy devices */
+	dove_legacy_clk_init();
 
 	/* Internal devices not ported to DT yet */
 	dove_pcie_init(1, 1);
@@ -73,9 +83,8 @@ static const char * const dove_dt_board_compat[] = {
 
 DT_MACHINE_START(DOVE_DT, "Marvell Dove (Flattened Device Tree)")
 	.map_io		= dove_map_io,
-	.init_early	= dove_init_early,
-	.init_irq	= orion_dt_init_irq,
-	.init_time	= dove_timer_init,
+	.init_early	= dove_dt_init_early,
+	.init_time	= dove_dt_time_init,
 	.init_machine	= dove_dt_init,
 	.restart	= dove_restart,
 	.dt_compat	= dove_dt_board_compat,
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:03:43 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:03:43 +0200
Subject: [PATCH v4 7/7] ARM: plat-orion: add reg offset to DT irq driver stub
In-Reply-To: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372763023-12374-8-git-send-email-sebastian.hesselbarth@gmail.com>

With irqchip driver for Orion SoCs, reg layout of orion-intc has changed.
This updates irq driver stub implemented before to the new reg layout by
adding an offset to the base address passed by DT node. As orion5x still
uses this stub, it cannot be removed yet.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
--- 
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/plat-orion/irq.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-orion/irq.c b/arch/arm/plat-orion/irq.c
index 8db0b98..c492e1b 100644
--- a/arch/arm/plat-orion/irq.c
+++ b/arch/arm/plat-orion/irq.c
@@ -47,7 +47,7 @@ static int __init orion_add_irq_domain(struct device_node *np,
 	do {
 		base = of_iomap(np, i);
 		if (base) {
-			orion_irq_init(i * 32, base);
+			orion_irq_init(i * 32, base + 0x04);
 			i++;
 		}
 	} while (base);
-- 
1.7.2.5



From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:03:41 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 13:03:41 +0200
Subject: [PATCH v4 5/7] ARM: kirkwood: convert to DT irqchip and clocksource
In-Reply-To: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372763023-12374-6-git-send-email-sebastian.hesselbarth@gmail.com>

With recent support for true irqchip and clocksource drivers for Orion
SoCs, now make use of it on DT enabled Kirkwood boards.

This also introduces a new Kconfig option for legacy (non-DT) Kirkwood
where old code is moved out to and polishes DT board file a little bit.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
--- 
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/mach-kirkwood/Kconfig    |   22 ++++++++++++++++++++++
 arch/arm/mach-kirkwood/Makefile   |    4 ++--
 arch/arm/mach-kirkwood/board-dt.c |   24 +++++++++++++++++-------
 3 files changed, 41 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 493c71a..ede131e 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -2,67 +2,81 @@ if ARCH_KIRKWOOD
 
 menu "Marvell Kirkwood Implementations"
 
+config KIRKWOOD_LEGACY
+	bool
+
 config MACH_D2NET_V2
 	bool "LaCie d2 Network v2 NAS Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  LaCie d2 Network v2 NAS.
 
 config MACH_DOCKSTAR
 	bool "Seagate FreeAgent DockStar"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Seagate FreeAgent DockStar.
 
 config MACH_ESATA_SHEEVAPLUG
 	bool "Marvell eSATA SheevaPlug Reference Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell eSATA SheevaPlug Reference Board.
 
 config MACH_GURUPLUG
 	bool "Marvell GuruPlug Reference Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell GuruPlug Reference Board.
 
 config MACH_INETSPACE_V2
 	bool "LaCie Internet Space v2 NAS Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  LaCie Internet Space v2 NAS.
 
 config MACH_MV88F6281GTW_GE
 	bool "Marvell 88F6281 GTW GE Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell 88F6281 GTW GE Board.
 
 config MACH_NET2BIG_V2
 	bool "LaCie 2Big Network v2 NAS Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  LaCie 2Big Network v2 NAS.
 
 config MACH_NET5BIG_V2
 	bool "LaCie 5Big Network v2 NAS Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  LaCie 5Big Network v2 NAS.
 
 config MACH_NETSPACE_MAX_V2
 	bool "LaCie Network Space Max v2 NAS Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  LaCie Network Space Max v2 NAS.
 
 config MACH_NETSPACE_V2
 	bool "LaCie Network Space v2 NAS Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  LaCie Network Space v2 NAS.
 
 config MACH_OPENRD
+	select KIRKWOOD_LEGACY
         bool
 
 config MACH_OPENRD_BASE
@@ -88,30 +102,35 @@ config MACH_OPENRD_ULTIMATE
 
 config MACH_RD88F6192_NAS
 	bool "Marvell RD-88F6192-NAS Reference Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell RD-88F6192-NAS Reference Board.
 
 config MACH_RD88F6281
 	bool "Marvell RD-88F6281 Reference Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell RD-88F6281 Reference Board.
 
 config MACH_SHEEVAPLUG
 	bool "Marvell SheevaPlug Reference Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell SheevaPlug Reference Board.
 
 config MACH_T5325
 	bool "HP t5325 Thin Client"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  HP t5325 Thin Client.
 
 config MACH_TS219
 	bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
@@ -119,6 +138,7 @@ config MACH_TS219
 
 config MACH_TS41X
 	bool "QNAP TS-410, TS-410U, TS-419P, TS-419P+ and TS-419U Turbo NAS"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  QNAP TS-410, TS-410U, TS-419P, TS-419P+ and TS-419U Turbo
@@ -129,6 +149,8 @@ comment "Device tree entries"
 config ARCH_KIRKWOOD_DT
 	bool "Marvell Kirkwood Flattened Device Tree"
 	select KIRKWOOD_CLK
+	select ORION_IRQCHIP
+	select ORION_TIMER
 	select POWER_SUPPLY
 	select POWER_RESET
 	select POWER_RESET_GPIO
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 062f8c7..f78f333 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -1,5 +1,5 @@
-obj-y				+= common.o irq.o pcie.o mpp.o
-
+obj-y				+= common.o pcie.o
+obj-$(CONFIG_KIRKWOOD_LEGACY)	+= irq.o mpp.o
 obj-$(CONFIG_MACH_D2NET_V2)		+= d2net_v2-setup.o lacie_v2-common.o
 obj-$(CONFIG_MACH_DOCKSTAR)		+= dockstar-setup.o
 obj-$(CONFIG_MACH_ESATA_SHEEVAPLUG)	+= sheevaplug-setup.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 881f37e..385244c 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -15,6 +15,9 @@
 #include <linux/of.h>
 #include <linux/of_platform.h>
 #include <linux/clk-provider.h>
+#include <linux/clocksource.h>
+#include <linux/dma-mapping.h>
+#include <linux/irqchip.h>
 #include <linux/kexec.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
@@ -67,10 +70,18 @@ static void __init kirkwood_legacy_clk_init(void)
 	clk_prepare_enable(clk);
 }
 
-static void __init kirkwood_of_clk_init(void)
+static void __init kirkwood_dt_time_init(void)
 {
 	of_clk_init(NULL);
-	kirkwood_legacy_clk_init();
+	clocksource_of_init();
+}
+
+static void __init kirkwood_dt_init_early(void)
+{
+	init_dma_coherent_pool_size(SZ_1M);
+	mvebu_mbus_init("marvell,kirkwood-mbus",
+			BRIDGE_WINS_BASE, BRIDGE_WINS_SZ,
+			DDR_WINDOW_CPU_BASE, DDR_WINDOW_CPU_SZ);
 }
 
 static void __init kirkwood_dt_init(void)
@@ -91,8 +102,8 @@ static void __init kirkwood_dt_init(void)
 
 	kirkwood_cpufreq_init();
 
-	/* Setup root of clk tree */
-	kirkwood_of_clk_init();
+	/* Setup clocks for legacy devices */
+	kirkwood_legacy_clk_init();
 
 	kirkwood_cpuidle_init();
 
@@ -114,9 +125,8 @@ static const char * const kirkwood_dt_board_compat[] = {
 DT_MACHINE_START(KIRKWOOD_DT, "Marvell Kirkwood (Flattened Device Tree)")
 	/* Maintainer: Jason Cooper <jason at lakedaemon.net> */
 	.map_io		= kirkwood_map_io,
-	.init_early	= kirkwood_init_early,
-	.init_irq	= orion_dt_init_irq,
-	.init_time	= kirkwood_timer_init,
+	.init_early	= kirkwood_dt_init_early,
+	.init_time	= kirkwood_dt_time_init,
 	.init_machine	= kirkwood_dt_init,
 	.restart	= kirkwood_restart,
 	.dt_compat	= kirkwood_dt_board_compat,
-- 
1.7.2.5



From mark.rutland at arm.com  Tue Jul  2 07:11:18 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 2 Jul 2013 12:11:18 +0100
Subject: [PATCH 3/5] ARM: dts: imx6: rename the uart's compatible property
In-Reply-To: <51D2AEC1.6030004@freescale.com>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
 <1372746628-20092-4-git-send-email-b32955@freescale.com>
 <20130702095645.GD31358@e106331-lin.cambridge.arm.com>
 <51D2AEC1.6030004@freescale.com>
Message-ID: <20130702111118.GE31358@e106331-lin.cambridge.arm.com>

On Tue, Jul 02, 2013 at 11:43:13AM +0100, Huang Shijie wrote:
> ? 2013?07?02? 17:56, Mark Rutland ??:
> > On Tue, Jul 02, 2013 at 07:30:26AM +0100, Huang Shijie wrote:
> >> >  The imx6 uart can supports the DMA, imx uart driver has added a new
> >> >  compatible property for the imx6 uart.
> >> >  
> >> >  In order to enable the DMA for some uart port in imx6, we rename the
> >> >  uart's compatible property to "fsl,imx6-uart".
> > Doesn't this change break using these dts with an older kernel? You
> is it reasonable to use a new dts with an old kernel?

As long as everything required to boot is described in a fashion the old
kernel understands, I see no reason it shouldn't be. I certainly see no
reason to break compatibility with an old kernel by *removing* a
compatible string ("fsl,imx21-uart") that should not break newer
kernels if they choose to use the more-specific compatible string.

> 
> 
> > remove the "fsl,imx21-uart" string older kernels understand.
> >
> > Given you already had "fsl,imx6q-uart" and "fsl,imx6sl-uart" strings,
> > would it not have made more sense to just add these to the driver?
> I think it's not a good idea.

Are there instances of "fsl-imx6q-uart" or "fsl,imx6sl-uart" that aren't
compatible with this new "fsl,imx6-uart" (i.e. are any not DMA capable)?

If not, then using the existing binding gives the same behaviour without
confusing everyone by adding a slightly different compatible string,
without the churn caused by modifying the dts, and the cost to Linux is
a single line. Boards with a pre-built dtb will get the new
functionality by just changing the Linux image.

I don't see what's wrong with this.

Thanks,
Mark.

> 
> Shawn, what's your opinion about this?
> 
> thanks
> Huang Shijie
> 
> 
> 


From vaibhav.bedia at ti.com  Tue Jul  2 07:28:09 2013
From: vaibhav.bedia at ti.com (Vaibhav Bedia)
Date: Tue, 2 Jul 2013 16:58:09 +0530
Subject: [RFC 0/9] Consolidate AM335x and OMAP4 PRM/CM APIs
Message-ID: <1372764498-32503-1-git-send-email-vaibhav.bedia@ti.com>

Even though there are differences in the PRCM features on different
TI SoCs (mostly OMAP3+) the underlying PRCM architecture is similar
on OMAP4+, AM335x, AM437x (and DM81xx). With some rework of the OMAP4
APIs we can easily consolidate the low level PRM/CM APIs for these
SoCs and cut down 800+ lines under mach-omap2.

These patches go on top of v3.10-rc7 (would rebase once 3.11-rc1 is out)
and have been boot tested on AM335x EVM. I have tried to ensure OMAP4+
is not affected but any testing on OMAP4+ would be helpful.

NOTE: The last patch which has the AM335x restart function would need
to be reworked since the OMAP4 code is moving to a different file.

Vaibhav Bedia (9):
  ARM: OMAP2+: AM335X: Add a constant CM_INST for all the clkdomains
  ARM: OMAP2+: CM code: Reintroduce SW_SLEEP for OMAP4 class of devices
  ARM: OMAP2+: AM335X: Add a constant PRCM_PARITION for the pwrdomains
  ARM: OMAP4: PRM: Get rid of hardcoded offsets
  ARM: OMAP4: Add offsets for pwrstctrl and pwrstst
  ARM: OMAP4: CM code: Remove the check for non-zero clkctrl_offs
  ARM: OMAP4: Generalize reset handling API
  ARM: OMAP2+: AM335x: Migrate to OMAP4 PRM/CM APIs
  ARM: OMAP2+: AM33XX: Get rid of custom PRM, CM APIs

 arch/arm/mach-omap2/Makefile                |   3 +-
 arch/arm/mach-omap2/am33xx-restart.c        |  34 ---
 arch/arm/mach-omap2/clockdomains33xx_data.c |  18 ++
 arch/arm/mach-omap2/cm33xx.c                | 364 ----------------------------
 arch/arm/mach-omap2/cm33xx.h                |  41 +---
 arch/arm/mach-omap2/cminst44xx.c            |  31 ++-
 arch/arm/mach-omap2/io.c                    |   3 +
 arch/arm/mach-omap2/omap4-common.c          |  14 ++
 arch/arm/mach-omap2/omap_hwmod.c            | 184 +-------------
 arch/arm/mach-omap2/powerdomains33xx_data.c |   6 +
 arch/arm/mach-omap2/powerdomains44xx_data.c |  32 +++
 arch/arm/mach-omap2/prm33xx.c               | 338 --------------------------
 arch/arm/mach-omap2/prm33xx.h               |  12 +-
 arch/arm/mach-omap2/prm44xx.c               |  45 ++--
 arch/arm/mach-omap2/prminst44xx.c           |  47 +++-
 arch/arm/mach-omap2/prminst44xx.h           |   6 +-
 16 files changed, 183 insertions(+), 995 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/am33xx-restart.c
 delete mode 100644 arch/arm/mach-omap2/cm33xx.c
 delete mode 100644 arch/arm/mach-omap2/prm33xx.c

-- 
1.8.1



From alexandre.belloni at free-electrons.com  Tue Jul  2 07:35:33 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Tue, 02 Jul 2013 13:35:33 +0200
Subject: [PATCHv3 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
In-Reply-To: <CAOMZO5CLcT=OXYd=ggxpDzUqFxoXSaanqUPGugYLT2Og-VgzCA@mail.gmail.com>
References: <1372094699-3832-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1372094699-3832-3-git-send-email-alexandre.belloni@free-electrons.com>
 <CAOMZO5CLcT=OXYd=ggxpDzUqFxoXSaanqUPGugYLT2Og-VgzCA@mail.gmail.com>
Message-ID: <51D2BB05.9040201@free-electrons.com>

Hi,

On 02/07/2013 04:45, Fabio Estevam wrote:
> Are you able to use the mxs i2c controller instead of bitbang if you
> use this patch?
> http://www.spinics.net/lists/stable/msg13202.html
> 

Actually, it gets worse. I'm probably doing something wrong but I get:

mxs-i2c 8005a000.i2c: Failed to get PIO reg. write descriptor.

That is the one line 243. I'm open to any suggestion.

BTW, I also tested PIO mode with and without touchscreen support as that
seemed to toggle the issue on your side. It is also worse than what it
was in 3.9. Trying to read the nau7802 ADC never returns.

The excerpt from my DT:

i2c1: i2c at 8005a000 {
	pinctrl-names = "default";
	pinctrl-0 = <&i2c1_pins_a>;
	status = "okay";
};

i2cmux {
	compatible = "i2c-mux-gpio";
	#address-cells = <1>;
	#size-cells = <0>;
	pinctrl-names = "default";
	pinctrl-0 = <&i2cmux_pins_cfa10049>;
	mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
	i2c-parent = <&i2c1>;

	i2c at 0 {
		reg = <0>;
		#address-cells = <1>;
		#size-cells = <0>;

		adc0: nau7802 at 2a {
			compatible = "nuvoton,nau7802";
			reg = <0x2a>;
			nuvoton,vldo = <3000>;
		};
	};

[...]


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From manjunath.goudar at linaro.org  Tue Jul  2 07:36:59 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Tue,  2 Jul 2013 17:06:59 +0530
Subject: [PATCH] USB: OHCI: make ohci-da8xx a separate driver
Message-ID: <1372765019-7191-1-git-send-email-manjunath.goudar@linaro.org>

Separate the Davinci OHCI host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

One preexisting error:
"da8xx_syscfg0_base" [drivers/usb/host/ohci-da8xx.ko] undefined!

Fixed eventually using below modification:
added EXPORT_SYMBOL_GPL(da8xx_syscfg0_base) in
arch/arm/mach-davinci/devices-da8xx.c.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Sergei Shtylyov <sshtylyov at ru.mvista.com>
Cc: Kevin Hilman <kjh at hilman.org>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org
---
 drivers/usb/host/Kconfig      |    8 +++
 drivers/usb/host/Makefile     |    1 +
 drivers/usb/host/ohci-da8xx.c |  139 +++++++++++++++++++----------------------
 drivers/usb/host/ohci-hcd.c   |   18 ------
 4 files changed, 75 insertions(+), 91 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 002bf73..bf2689d 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -406,6 +406,14 @@ config USB_OHCI_HCD_LPC32XX
           Enables support for the on-chip OHCI controller on
           NXP chips.
 
+config USB_OHCI_HCD_DA8XX
+	tristate "Support for DAVINCI on-chip OHCI USB controller"
+	depends on USB_OHCI_HCD && ARCH_DAVINCI_DA8XX
+	default y
+	---help---
+          Enables support for the on-chip OHCI controller on
+          Davinci chips.
+
 config USB_OHCI_HCD_AT91
         tristate  "Support for Atmel on-chip OHCI USB controller"
         depends on USB_OHCI_HCD && ARCH_AT91
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index edc0909..f8d59371 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_USB_OHCI_HCD_SPEAR)	+= ohci-spear.o
 obj-$(CONFIG_USB_OHCI_HCD_AT91)	+= ohci-at91.o
 obj-$(CONFIG_USB_OHCI_HCD_S3CXXXX)	+= ohci-s3c2410.o
 obj-$(CONFIG_USB_OHCI_HCD_LPC32XX)	+= ohci-nxp.o
+obj-$(CONFIG_USB_OHCI_HCD_DA8XX)	+= ohci-da8xx.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index c649a35..9b4d1e4 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -11,20 +11,35 @@
  * kind, whether express or implied.
  */
 
+#include <linux/clk.h>
+#include <linux/io.h>
 #include <linux/interrupt.h>
 #include <linux/jiffies.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/platform_device.h>
-#include <linux/clk.h>
+#include <linux/platform_data/usb-davinci.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
 
 #include <mach/da8xx.h>
-#include <linux/platform_data/usb-davinci.h>
+#include <asm/unaligned.h>
 
-#ifndef CONFIG_ARCH_DAVINCI_DA8XX
-#error "This file is DA8xx bus glue.  Define CONFIG_ARCH_DAVINCI_DA8XX."
-#endif
+#include "ohci.h"
 
 #define CFGCHIP2	DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG)
 
+#define DRIVER_DESC "OHCI DA8XX driver"
+
+static const char hcd_name[] = "ohci-da8xx";
+
+static struct hc_driver __read_mostly ohci_da8xx_hc_driver;
+
+static int (*orig_ohci_hub_control)(struct usb_hcd  *hcd, u16 typeReq,
+			u16 wValue, u16 wIndex, char *buf, u16 wLength);
+static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
+
 static struct clk *usb11_clk;
 static struct clk *usb20_clk;
 
@@ -82,7 +97,7 @@ static void ohci_da8xx_ocic_handler(struct da8xx_ohci_root_hub *hub,
 		hub->set_power(port, 0);
 }
 
-static int ohci_da8xx_init(struct usb_hcd *hcd)
+static int ohci_da8xx_reset(struct usb_hcd *hcd)
 {
 	struct device *dev		= hcd->self.controller;
 	struct da8xx_ohci_root_hub *hub	= dev->platform_data;
@@ -100,7 +115,7 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
 	 */
 	ohci->num_ports = 1;
 
-	result = ohci_init(ohci);
+	result = ohci_setup(hcd);
 	if (result < 0)
 		return result;
 
@@ -126,30 +141,12 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
 	return result;
 }
 
-static void ohci_da8xx_stop(struct usb_hcd *hcd)
-{
-	ohci_stop(hcd);
-	ohci_da8xx_clock(0);
-}
-
-static int ohci_da8xx_start(struct usb_hcd *hcd)
-{
-	struct ohci_hcd	*ohci		= hcd_to_ohci(hcd);
-	int result;
-
-	result = ohci_run(ohci);
-	if (result < 0)
-		ohci_da8xx_stop(hcd);
-
-	return result;
-}
-
 /*
  * Update the status data from the hub with the over-current indicator change.
  */
 static int ohci_da8xx_hub_status_data(struct usb_hcd *hcd, char *buf)
 {
-	int length		= ohci_hub_status_data(hcd, buf);
+	int length		= orig_ohci_hub_status_data(hcd, buf);
 
 	/* See if we have OCIC bit set on port 1 */
 	if (ocic_mask & (1 << 1)) {
@@ -231,53 +228,10 @@ check_port:
 		}
 	}
 
-	return ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+	return orig_ohci_hub_control(hcd, typeReq, wValue,
+			wIndex, buf, wLength);
 }
 
-static const struct hc_driver ohci_da8xx_hc_driver = {
-	.description		= hcd_name,
-	.product_desc		= "DA8xx OHCI",
-	.hcd_priv_size		= sizeof(struct ohci_hcd),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq			= ohci_irq,
-	.flags			= HCD_USB11 | HCD_MEMORY,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.reset			= ohci_da8xx_init,
-	.start			= ohci_da8xx_start,
-	.stop			= ohci_da8xx_stop,
-	.shutdown		= ohci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue		= ohci_urb_enqueue,
-	.urb_dequeue		= ohci_urb_dequeue,
-	.endpoint_disable	= ohci_endpoint_disable,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number	= ohci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data	= ohci_da8xx_hub_status_data,
-	.hub_control		= ohci_da8xx_hub_control,
-
-#ifdef	CONFIG_PM
-	.bus_suspend		= ohci_bus_suspend,
-	.bus_resume		= ohci_bus_resume,
-#endif
-	.start_port_reset	= ohci_start_port_reset,
-};
-
 /*-------------------------------------------------------------------------*/
 
 
@@ -337,8 +291,6 @@ static int usb_hcd_da8xx_probe(const struct hc_driver *driver,
 		goto err3;
 	}
 
-	ohci_hcd_init(hcd_to_ohci(hcd));
-
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
 		error = -ENODEV;
@@ -383,6 +335,7 @@ usb_hcd_da8xx_remove(struct usb_hcd *hcd, struct platform_device *pdev)
 	struct da8xx_ohci_root_hub *hub	= pdev->dev.platform_data;
 
 	hub->ocic_notify(NULL);
+	ohci_da8xx_clock(0);
 	usb_remove_hcd(hcd);
 	iounmap(hcd->regs);
 	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
@@ -444,6 +397,11 @@ static int ohci_da8xx_resume(struct platform_device *dev)
 }
 #endif
 
+static const struct ohci_driver_overrides da8xx_overrides __initconst = {
+	.reset		= ohci_da8xx_reset
+};
+
+
 /*
  * Driver definition to register with platform structure.
  */
@@ -461,4 +419,39 @@ static struct platform_driver ohci_hcd_da8xx_driver = {
 	},
 };
 
+static int __init ohci_da8xx_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+	ohci_init_driver(&ohci_da8xx_hc_driver, &da8xx_overrides);
+
+	/*
+	 * The Davinci da8xx HW has some unusual quirks, which require
+	 * da8xx-specific workarounds. We override certain hc_driver
+	 * functions here to achieve that. We explicitly do not enhance
+	 * ohci_driver_overrides to allow this more easily, since this
+	 * is an unusual case, and we don't want to encourage others to
+	 * override these functions by making it too easy.
+	 */
+
+	orig_ohci_hub_control = ohci_da8xx_hc_driver.hub_control;
+	orig_ohci_hub_status_data = ohci_da8xx_hc_driver.hub_status_data;
+
+	ohci_da8xx_hc_driver.hub_status_data     = ohci_da8xx_hub_status_data;
+	ohci_da8xx_hc_driver.hub_control         = ohci_da8xx_hub_control;
+
+	return platform_driver_register(&ohci_hcd_da8xx_driver);
+}
+module_init(ohci_da8xx_init);
+
+static void __exit ohci_da8xx_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_da8xx_driver);
+}
+module_exit(ohci_da8xx_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:ohci");
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 9a0b023..8ae7a1b 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1194,11 +1194,6 @@ MODULE_LICENSE ("GPL");
 #define EP93XX_PLATFORM_DRIVER	ohci_hcd_ep93xx_driver
 #endif
 
-#ifdef CONFIG_ARCH_DAVINCI_DA8XX
-#include "ohci-da8xx.c"
-#define DAVINCI_PLATFORM_DRIVER	ohci_hcd_da8xx_driver
-#endif
-
 #ifdef CONFIG_USB_OHCI_HCD_PPC_OF
 #include "ohci-ppc-of.c"
 #define OF_PLATFORM_DRIVER	ohci_hcd_ppc_of_driver
@@ -1296,19 +1291,9 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_ep93xx;
 #endif
 
-#ifdef DAVINCI_PLATFORM_DRIVER
-	retval = platform_driver_register(&DAVINCI_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_davinci;
-#endif
-
 	return retval;
 
 	/* Error path */
-#ifdef DAVINCI_PLATFORM_DRIVER
-	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
- error_davinci:
-#endif
 #ifdef EP93XX_PLATFORM_DRIVER
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
  error_ep93xx:
@@ -1350,9 +1335,6 @@ module_init(ohci_hcd_mod_init);
 
 static void __exit ohci_hcd_mod_exit(void)
 {
-#ifdef DAVINCI_PLATFORM_DRIVER
-	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
-#endif
 #ifdef NXP_PLATFORM_DRIVER
 	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
 #endif
-- 
1.7.9.5



From festevam at gmail.com  Tue Jul  2 07:45:56 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 2 Jul 2013 08:45:56 -0300
Subject: [PATCHv3 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
In-Reply-To: <51D2BB05.9040201@free-electrons.com>
References: <1372094699-3832-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1372094699-3832-3-git-send-email-alexandre.belloni@free-electrons.com>
 <CAOMZO5CLcT=OXYd=ggxpDzUqFxoXSaanqUPGugYLT2Og-VgzCA@mail.gmail.com>
 <51D2BB05.9040201@free-electrons.com>
Message-ID: <CAOMZO5DZufiOjguOCEbe5n0j=w9B5ezBYh0Rejv3zF5Xht5_qQ@mail.gmail.com>

On Tue, Jul 2, 2013 at 8:35 AM, Alexandre Belloni
<alexandre.belloni at free-electrons.com> wrote:

> mxs-i2c 8005a000.i2c: Failed to get PIO reg. write descriptor.
>
> That is the one line 243. I'm open to any suggestion.
>
> BTW, I also tested PIO mode with and without touchscreen support as that
> seemed to toggle the issue on your side. It is also worse than what it
> was in 3.9. Trying to read the nau7802 ADC never returns.
>
> The excerpt from my DT:
>
> i2c1: i2c at 8005a000 {
>         pinctrl-names = "default";
>         pinctrl-0 = <&i2c1_pins_a>;
>         status = "okay";
> };
>
> i2cmux {
>         compatible = "i2c-mux-gpio";
>         #address-cells = <1>;
>         #size-cells = <0>;
>         pinctrl-names = "default";
>         pinctrl-0 = <&i2cmux_pins_cfa10049>;
>         mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
>         i2c-parent = <&i2c1>;
>
>         i2c at 0 {
>                 reg = <0>;

Shouldn't this be

         i2c at 1 {
                 reg = <1>; ?


From manjunath.goudar at linaro.org  Tue Jul  2 07:50:31 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Tue,  2 Jul 2013 17:20:31 +0530
Subject: [PATCH V2] USB: OHCI: make ohci-nxp a separate driver
In-Reply-To: <1372585818-8441-1-git-send-email-manjunath.goudar@linaro.org>
References: <1372585818-8441-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1372765832-18054-1-git-send-email-manjunath.goudar@linaro.org>

Separate the OHCI NXP host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.

Many place function name and struct name started with usb,
current scenario replaced usb with ohci for proper naming.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
  - Directive check NXP_PLATFORM_DRIVER block has been removed.
---
 drivers/usb/host/Kconfig    |    8 +++
 drivers/usb/host/Makefile   |    1 +
 drivers/usb/host/ohci-hcd.c |   18 -------
 drivers/usb/host/ohci-nxp.c |  124 +++++++++++++++++--------------------------
 4 files changed, 58 insertions(+), 93 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index f19524f..002bf73 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -398,6 +398,14 @@ config USB_OHCI_HCD_S3CXXXX
           Enables support for the on-chip OHCI controller on
           S3CXXXX chips.
 
+config USB_OHCI_HCD_LPC32XX
+	tristate "Support for LPC on-chip OHCI USB controller"
+	depends on USB_OHCI_HCD && ARCH_LPC32XX
+	default y
+	---help---
+          Enables support for the on-chip OHCI controller on
+          NXP chips.
+
 config USB_OHCI_HCD_AT91
         tristate  "Support for Atmel on-chip OHCI USB controller"
         depends on USB_OHCI_HCD && ARCH_AT91
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 9dffe81..edc0909 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_USB_OHCI_HCD_OMAP3)	+= ohci-omap3.o
 obj-$(CONFIG_USB_OHCI_HCD_SPEAR)	+= ohci-spear.o
 obj-$(CONFIG_USB_OHCI_HCD_AT91)	+= ohci-at91.o
 obj-$(CONFIG_USB_OHCI_HCD_S3CXXXX)	+= ohci-s3c2410.o
+obj-$(CONFIG_USB_OHCI_HCD_LPC32XX)	+= ohci-nxp.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index f3dcaa2..39d14f0 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1194,11 +1194,6 @@ MODULE_LICENSE ("GPL");
 #define EP93XX_PLATFORM_DRIVER	ohci_hcd_ep93xx_driver
 #endif
 
-#ifdef CONFIG_ARCH_LPC32XX
-#include "ohci-nxp.c"
-#define NXP_PLATFORM_DRIVER	usb_hcd_nxp_driver
-#endif
-
 #ifdef CONFIG_ARCH_DAVINCI_DA8XX
 #include "ohci-da8xx.c"
 #define DAVINCI_PLATFORM_DRIVER	ohci_hcd_da8xx_driver
@@ -1301,12 +1296,6 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_ep93xx;
 #endif
 
-#ifdef NXP_PLATFORM_DRIVER
-	retval = platform_driver_register(&NXP_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_nxp;
-#endif
-
 #ifdef DAVINCI_PLATFORM_DRIVER
 	retval = platform_driver_register(&DAVINCI_PLATFORM_DRIVER);
 	if (retval < 0)
@@ -1320,10 +1309,6 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
  error_davinci:
 #endif
-#ifdef NXP_PLATFORM_DRIVER
-	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
- error_nxp:
-#endif
 #ifdef EP93XX_PLATFORM_DRIVER
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
  error_ep93xx:
@@ -1368,9 +1353,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef DAVINCI_PLATFORM_DRIVER
 	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
 #endif
-#ifdef NXP_PLATFORM_DRIVER
-	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
-#endif
 #ifdef EP93XX_PLATFORM_DRIVER
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-nxp.c b/drivers/usb/host/ohci-nxp.c
index 7d7d507..8d6eecf 100644
--- a/drivers/usb/host/ohci-nxp.c
+++ b/drivers/usb/host/ohci-nxp.c
@@ -19,10 +19,19 @@
  * or implied.
  */
 #include <linux/clk.h>
-#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
 #include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/of.h>
+#include <linux/platform_device.h>
 #include <linux/usb/isp1301.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ohci.h"
+
 
 #include <mach/hardware.h>
 #include <asm/mach-types.h>
@@ -57,6 +66,11 @@
 #define start_int_umask(irq)
 #endif
 
+#define DRIVER_DESC "OHCI NXP driver"
+
+static const char hcd_name[] = "ohci-nxp";
+static struct hc_driver __read_mostly ohci_nxp_hc_driver;
+
 static struct i2c_client *isp1301_i2c_client;
 
 extern int usb_disabled(void);
@@ -132,14 +146,14 @@ static inline void isp1301_vbus_off(void)
 		OTG1_VBUS_DRV);
 }
 
-static void nxp_start_hc(void)
+static void ohci_nxp_start_hc(void)
 {
 	unsigned long tmp = __raw_readl(USB_OTG_STAT_CONTROL) | HOST_EN;
 	__raw_writel(tmp, USB_OTG_STAT_CONTROL);
 	isp1301_vbus_on();
 }
 
-static void nxp_stop_hc(void)
+static void ohci_nxp_stop_hc(void)
 {
 	unsigned long tmp;
 	isp1301_vbus_off();
@@ -147,68 +161,9 @@ static void nxp_stop_hc(void)
 	__raw_writel(tmp, USB_OTG_STAT_CONTROL);
 }
 
-static int ohci_nxp_start(struct usb_hcd *hcd)
-{
-	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
-	int ret;
-
-	if ((ret = ohci_init(ohci)) < 0)
-		return ret;
-
-	if ((ret = ohci_run(ohci)) < 0) {
-		dev_err(hcd->self.controller, "can't start\n");
-		ohci_stop(hcd);
-		return ret;
-	}
-	return 0;
-}
-
-static const struct hc_driver ohci_nxp_hc_driver = {
-	.description = hcd_name,
-	.product_desc =		"nxp OHCI",
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq = ohci_irq,
-	.flags = HCD_USB11 | HCD_MEMORY,
-
-	.hcd_priv_size =	sizeof(struct ohci_hcd),
-	/*
-	 * basic lifecycle operations
-	 */
-	.start = ohci_nxp_start,
-	.stop = ohci_stop,
-	.shutdown = ohci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue = ohci_urb_enqueue,
-	.urb_dequeue = ohci_urb_dequeue,
-	.endpoint_disable = ohci_endpoint_disable,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number = ohci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data = ohci_hub_status_data,
-	.hub_control = ohci_hub_control,
-#ifdef	CONFIG_PM
-	.bus_suspend = ohci_bus_suspend,
-	.bus_resume = ohci_bus_resume,
-#endif
-	.start_port_reset = ohci_start_port_reset,
-};
-
-static int usb_hcd_nxp_probe(struct platform_device *pdev)
+static int ohci_hcd_nxp_probe(struct platform_device *pdev)
 {
 	struct usb_hcd *hcd = 0;
-	struct ohci_hcd *ohci;
 	const struct hc_driver *driver = &ohci_nxp_hc_driver;
 	struct resource *res;
 	int ret = 0, irq;
@@ -313,17 +268,15 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
 		goto fail_resource;
 	}
 
-	nxp_start_hc();
+	ohci_nxp_start_hc();
 	platform_set_drvdata(pdev, hcd);
-	ohci = hcd_to_ohci(hcd);
-	ohci_hcd_init(ohci);
 
 	dev_info(&pdev->dev, "at 0x%p, irq %d\n", hcd->regs, hcd->irq);
 	ret = usb_add_hcd(hcd, irq, 0);
 	if (ret == 0)
 		return ret;
 
-	nxp_stop_hc();
+	ohci_nxp_stop_hc();
 fail_resource:
 	usb_put_hcd(hcd);
 fail_hcd:
@@ -345,12 +298,12 @@ fail_disable:
 	return ret;
 }
 
-static int usb_hcd_nxp_remove(struct platform_device *pdev)
+static int ohci_hcd_nxp_remove(struct platform_device *pdev)
 {
 	struct usb_hcd *hcd = platform_get_drvdata(pdev);
 
 	usb_remove_hcd(hcd);
-	nxp_stop_hc();
+	ohci_nxp_stop_hc();
 	usb_put_hcd(hcd);
 	clk_disable(usb_pll_clk);
 	clk_put(usb_pll_clk);
@@ -366,20 +319,41 @@ static int usb_hcd_nxp_remove(struct platform_device *pdev)
 MODULE_ALIAS("platform:usb-ohci");
 
 #ifdef CONFIG_OF
-static const struct of_device_id usb_hcd_nxp_match[] = {
+static const struct of_device_id ohci_hcd_nxp_match[] = {
 	{ .compatible = "nxp,ohci-nxp" },
 	{},
 };
-MODULE_DEVICE_TABLE(of, usb_hcd_nxp_match);
+MODULE_DEVICE_TABLE(of, ohci_hcd_nxp_match);
 #endif
 
-static struct platform_driver usb_hcd_nxp_driver = {
+static struct platform_driver ohci_hcd_nxp_driver = {
 	.driver = {
 		.name = "usb-ohci",
 		.owner	= THIS_MODULE,
-		.of_match_table = of_match_ptr(usb_hcd_nxp_match),
+		.of_match_table = of_match_ptr(ohci_hcd_nxp_match),
 	},
-	.probe = usb_hcd_nxp_probe,
-	.remove = usb_hcd_nxp_remove,
+	.probe = ohci_hcd_nxp_probe,
+	.remove = ohci_hcd_nxp_remove,
 };
 
+static int __init ohci_nxp_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ohci_init_driver(&ohci_nxp_hc_driver, NULL);
+	return platform_driver_register(&ohci_hcd_nxp_driver);
+}
+module_init(ohci_nxp_init);
+
+static void __exit ohci_nxp_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_nxp_driver);
+}
+module_exit(ohci_nxp_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL v2");
+
-- 
1.7.9.5



From alexandre.belloni at free-electrons.com  Tue Jul  2 07:50:57 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Tue, 02 Jul 2013 13:50:57 +0200
Subject: [PATCHv3 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
In-Reply-To: <CAOMZO5DZufiOjguOCEbe5n0j=w9B5ezBYh0Rejv3zF5Xht5_qQ@mail.gmail.com>
References: <1372094699-3832-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1372094699-3832-3-git-send-email-alexandre.belloni@free-electrons.com>
 <CAOMZO5CLcT=OXYd=ggxpDzUqFxoXSaanqUPGugYLT2Og-VgzCA@mail.gmail.com>
 <51D2BB05.9040201@free-electrons.com>
 <CAOMZO5DZufiOjguOCEbe5n0j=w9B5ezBYh0Rejv3zF5Xht5_qQ@mail.gmail.com>
Message-ID: <51D2BEA1.6010206@free-electrons.com>

On 02/07/2013 13:45, Fabio Estevam wrote:

> Shouldn't this be
> 
>          i2c at 1 {
>                  reg = <1>; ?
> 

No, we have 4 devices on that mux and 2 pins to select the muxing.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From jason at lakedaemon.net  Tue Jul  2 07:53:11 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 2 Jul 2013 07:53:11 -0400
Subject: [PATCH v4 5/7] ARM: kirkwood: convert to DT irqchip and
 clocksource
In-Reply-To: <1372763023-12374-6-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1372763023-12374-6-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130702115311.GG19937@titan.lakedaemon.net>

On Tue, Jul 02, 2013 at 01:03:41PM +0200, Sebastian Hesselbarth wrote:
> With recent support for true irqchip and clocksource drivers for Orion
> SoCs, now make use of it on DT enabled Kirkwood boards.
> 
> This also introduces a new Kconfig option for legacy (non-DT) Kirkwood
> where old code is moved out to and polishes DT board file a little bit.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> --- 
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Andrew Lunn <andrew at lunn.ch>
> Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  arch/arm/mach-kirkwood/Kconfig    |   22 ++++++++++++++++++++++
>  arch/arm/mach-kirkwood/Makefile   |    4 ++--
>  arch/arm/mach-kirkwood/board-dt.c |   24 +++++++++++++++++-------
>  3 files changed, 41 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
> index 493c71a..ede131e 100644
> --- a/arch/arm/mach-kirkwood/Kconfig
> +++ b/arch/arm/mach-kirkwood/Kconfig
> @@ -2,67 +2,81 @@ if ARCH_KIRKWOOD
>  
>  menu "Marvell Kirkwood Implementations"
>  
> +config KIRKWOOD_LEGACY
> +	bool
> +
>  config MACH_D2NET_V2
>  	bool "LaCie d2 Network v2 NAS Board"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  LaCie d2 Network v2 NAS.
>  
>  config MACH_DOCKSTAR
>  	bool "Seagate FreeAgent DockStar"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  Seagate FreeAgent DockStar.
>  
>  config MACH_ESATA_SHEEVAPLUG
>  	bool "Marvell eSATA SheevaPlug Reference Board"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  Marvell eSATA SheevaPlug Reference Board.
>  
>  config MACH_GURUPLUG
>  	bool "Marvell GuruPlug Reference Board"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  Marvell GuruPlug Reference Board.
>  
>  config MACH_INETSPACE_V2
>  	bool "LaCie Internet Space v2 NAS Board"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  LaCie Internet Space v2 NAS.
>  
>  config MACH_MV88F6281GTW_GE
>  	bool "Marvell 88F6281 GTW GE Board"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  Marvell 88F6281 GTW GE Board.
>  
>  config MACH_NET2BIG_V2
>  	bool "LaCie 2Big Network v2 NAS Board"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  LaCie 2Big Network v2 NAS.
>  
>  config MACH_NET5BIG_V2
>  	bool "LaCie 5Big Network v2 NAS Board"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  LaCie 5Big Network v2 NAS.
>  
>  config MACH_NETSPACE_MAX_V2
>  	bool "LaCie Network Space Max v2 NAS Board"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  LaCie Network Space Max v2 NAS.
>  
>  config MACH_NETSPACE_V2
>  	bool "LaCie Network Space v2 NAS Board"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  LaCie Network Space v2 NAS.
>  
>  config MACH_OPENRD
> +	select KIRKWOOD_LEGACY
>          bool
>  
>  config MACH_OPENRD_BASE
> @@ -88,30 +102,35 @@ config MACH_OPENRD_ULTIMATE
>  
>  config MACH_RD88F6192_NAS
>  	bool "Marvell RD-88F6192-NAS Reference Board"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  Marvell RD-88F6192-NAS Reference Board.
>  
>  config MACH_RD88F6281
>  	bool "Marvell RD-88F6281 Reference Board"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  Marvell RD-88F6281 Reference Board.
>  
>  config MACH_SHEEVAPLUG
>  	bool "Marvell SheevaPlug Reference Board"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  Marvell SheevaPlug Reference Board.
>  
>  config MACH_T5325
>  	bool "HP t5325 Thin Client"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  HP t5325 Thin Client.
>  
>  config MACH_TS219
>  	bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
> @@ -119,6 +138,7 @@ config MACH_TS219
>  
>  config MACH_TS41X
>  	bool "QNAP TS-410, TS-410U, TS-419P, TS-419P+ and TS-419U Turbo NAS"
> +	select KIRKWOOD_LEGACY
>  	help
>  	  Say 'Y' here if you want your kernel to support the
>  	  QNAP TS-410, TS-410U, TS-419P, TS-419P+ and TS-419U Turbo
> @@ -129,6 +149,8 @@ comment "Device tree entries"
>  config ARCH_KIRKWOOD_DT
>  	bool "Marvell Kirkwood Flattened Device Tree"
>  	select KIRKWOOD_CLK
> +	select ORION_IRQCHIP
> +	select ORION_TIMER
>  	select POWER_SUPPLY
>  	select POWER_RESET
>  	select POWER_RESET_GPIO
> diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
> index 062f8c7..f78f333 100644
> --- a/arch/arm/mach-kirkwood/Makefile
> +++ b/arch/arm/mach-kirkwood/Makefile
> @@ -1,5 +1,5 @@
> -obj-y				+= common.o irq.o pcie.o mpp.o
> -
> +obj-y				+= common.o pcie.o
> +obj-$(CONFIG_KIRKWOOD_LEGACY)	+= irq.o mpp.o
>  obj-$(CONFIG_MACH_D2NET_V2)		+= d2net_v2-setup.o lacie_v2-common.o
>  obj-$(CONFIG_MACH_DOCKSTAR)		+= dockstar-setup.o
>  obj-$(CONFIG_MACH_ESATA_SHEEVAPLUG)	+= sheevaplug-setup.o
> diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
> index 881f37e..385244c 100644
> --- a/arch/arm/mach-kirkwood/board-dt.c
> +++ b/arch/arm/mach-kirkwood/board-dt.c
> @@ -15,6 +15,9 @@
>  #include <linux/of.h>
>  #include <linux/of_platform.h>
>  #include <linux/clk-provider.h>
> +#include <linux/clocksource.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/irqchip.h>
>  #include <linux/kexec.h>
>  #include <asm/mach/arch.h>
>  #include <asm/mach/map.h>
> @@ -67,10 +70,18 @@ static void __init kirkwood_legacy_clk_init(void)
>  	clk_prepare_enable(clk);
>  }
>  
> -static void __init kirkwood_of_clk_init(void)
> +static void __init kirkwood_dt_time_init(void)
>  {
>  	of_clk_init(NULL);
> -	kirkwood_legacy_clk_init();
> +	clocksource_of_init();
> +}
> +
> +static void __init kirkwood_dt_init_early(void)
> +{


> +	init_dma_coherent_pool_size(SZ_1M);

This shouldn't be needed any more.  Is there a reason you're adding it
back in?

thx,

Jason.

> +	mvebu_mbus_init("marvell,kirkwood-mbus",
> +			BRIDGE_WINS_BASE, BRIDGE_WINS_SZ,
> +			DDR_WINDOW_CPU_BASE, DDR_WINDOW_CPU_SZ);
>  }
>  
>  static void __init kirkwood_dt_init(void)
> @@ -91,8 +102,8 @@ static void __init kirkwood_dt_init(void)
>  
>  	kirkwood_cpufreq_init();
>  
> -	/* Setup root of clk tree */
> -	kirkwood_of_clk_init();
> +	/* Setup clocks for legacy devices */
> +	kirkwood_legacy_clk_init();
>  
>  	kirkwood_cpuidle_init();
>  
> @@ -114,9 +125,8 @@ static const char * const kirkwood_dt_board_compat[] = {
>  DT_MACHINE_START(KIRKWOOD_DT, "Marvell Kirkwood (Flattened Device Tree)")
>  	/* Maintainer: Jason Cooper <jason at lakedaemon.net> */
>  	.map_io		= kirkwood_map_io,
> -	.init_early	= kirkwood_init_early,
> -	.init_irq	= orion_dt_init_irq,
> -	.init_time	= kirkwood_timer_init,
> +	.init_early	= kirkwood_dt_init_early,
> +	.init_time	= kirkwood_dt_time_init,
>  	.init_machine	= kirkwood_dt_init,
>  	.restart	= kirkwood_restart,
>  	.dt_compat	= kirkwood_dt_board_compat,
> -- 
> 1.7.2.5
> 


From nicolas.ferre at atmel.com  Tue Jul  2 08:12:25 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 2 Jul 2013 14:12:25 +0200
Subject: [PATCH 0/2] ARM: sunxi: Convert DTSI to new CPU bindings
In-Reply-To: <1372437844-16325-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1372437844-16325-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <51D2C3A9.5080809@atmel.com>

On 28/06/2013 18:44, Maxime Ripard :
> Hi Arnd, Olof,
>
> Sorry for steping in so late, but these two patches fixes a warning
> introduced by the commit 1ba9bf0a (ARM: 7762/1: kernel: fix
> arm_dt_init_cpu_maps() to skip non-cpu nodes) after 3.10-rc7.
>
> These two patches solve the situation for sunxi. The first one by
> Lorenzo is to be applied for 3.10 if it's still possible, and the
> second one on top of arm-soc/for-next. Tell me if you prefer a more
> formal pull request for these patches

Just for the heads-up, the same happened to AT91 SAMA5D3.
As the solution is already in linux-next, we simply have to make sure 
that the patch is reported to the stable branches...

Bye,


>
> Thanks!
> Maxime
>
> Lorenzo Pieralisi (1):
>    ARM: dts: sunxi: cpus/cpu nodes dts updates
>
> Maxime Ripard (1):
>    sunxi: a10s: dtsi: Convert cpu node to the new cpu bindings
>
>   arch/arm/boot/dts/sun4i-a10.dtsi  | 2 ++
>   arch/arm/boot/dts/sun5i-a10s.dtsi | 2 ++
>   arch/arm/boot/dts/sun5i-a13.dtsi  | 2 ++
>   3 files changed, 6 insertions(+)
>


-- 
Nicolas Ferre


From inki.dae at samsung.com  Tue Jul  2 08:21:32 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Tue, 02 Jul 2013 21:21:32 +0900
Subject: [PATCH] drm/exynos: Add missing includes
In-Reply-To: <1372683355-27460-1-git-send-email-broonie@kernel.org>
References: <1372683355-27460-1-git-send-email-broonie@kernel.org>
Message-ID: <008a01ce771e$afe02670$0fa07350$%dae@samsung.com>



> -----Original Message-----
> From: Mark Brown [mailto:broonie at kernel.org]
> Sent: Monday, July 01, 2013 9:56 PM
> To: Inki Dae; Joonyoung Shim; Seung-Woo Kim; Kyungmin Park; David Airlie
> Cc: dri-devel at lists.freedesktop.org; linux-arm-kernel at lists.infradead.org;
> linux-samsung-soc at vger.kernel.org; Mark Brown
> Subject: [PATCH] drm/exynos: Add missing includes
> 
> From: Mark Brown <broonie at linaro.org>
> 
> Ensure that all externally accessed functions are correctly prototyped
> when defined in each file by making sure the headers with the protoypes
> are included in the file with the definition.
> 

Hi Mark,

I don't see why this patch is needed. it seems like including unnecessary
headers so it makes the code size enlarged.

Thanks,
Inki Dae

> Signed-off-by: Mark Brown <broonie at linaro.org>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_connector.c | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c      | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c    | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c     | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c      | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c       | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c       | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_plane.c     | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c   | 1 +
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c      | 1 +
>  10 files changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> index 8bcc13a..ec80293 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> @@ -17,6 +17,7 @@
>  #include <drm/exynos_drm.h>
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_encoder.h"
> +#include "exynos_drm_connector.h"
> 
>  #define to_exynos_connector(x)	container_of(x, struct
> exynos_drm_connector,\
>  				drm_connector)
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 073c10a..6933ee9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -15,6 +15,7 @@
>  #include <drm/drmP.h>
>  #include <drm/drm_crtc_helper.h>
> 
> +#include "exynos_drm_crtc.h"
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_encoder.h"
>  #include "exynos_drm_plane.h"
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> index ff7f2a8..8adafde 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> @@ -11,6 +11,7 @@
> 
>  #include <drm/drmP.h>
>  #include <drm/exynos_drm.h>
> +#include "exynos_drm_dmabuf.h"
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_gem.h"
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 8f007aa..45b6cb3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -19,6 +19,7 @@
> 
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_fb.h"
> +#include "exynos_drm_fbdev.h"
>  #include "exynos_drm_gem.h"
>  #include "exynos_drm_iommu.h"
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 4a1616a..a83e664 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -22,6 +22,7 @@
>  #include <drm/drmP.h>
>  #include <drm/exynos_drm.h>
>  #include "regs-fimc.h"
> +#include "exynos_drm_drv.h"
>  #include "exynos_drm_ipp.h"
>  #include "exynos_drm_fimc.h"
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index af75434..03ba897 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -24,6 +24,7 @@
>  #include <drm/drmP.h>
>  #include <drm/exynos_drm.h>
>  #include "exynos_drm_drv.h"
> +#include "exynos_drm_g2d.h"
>  #include "exynos_drm_gem.h"
>  #include "exynos_drm_iommu.h"
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 762f40d..4683251 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -21,6 +21,7 @@
>  #include <drm/drmP.h>
>  #include <drm/exynos_drm.h>
>  #include "regs-gsc.h"
> +#include "exynos_drm_drv.h"
>  #include "exynos_drm_ipp.h"
>  #include "exynos_drm_gsc.h"
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index 83efc66..63ebeeb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -16,6 +16,7 @@
>  #include "exynos_drm_encoder.h"
>  #include "exynos_drm_fb.h"
>  #include "exynos_drm_gem.h"
> +#include "exynos_drm_plane.h"
> 
>  #define to_exynos_plane(x)	container_of(x, struct exynos_plane,
> base)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> index 9b6c709..2e9eee2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -22,6 +22,7 @@
>  #include <drm/exynos_drm.h>
>  #include "regs-rotator.h"
>  #include "exynos_drm.h"
> +#include "exynos_drm_drv.h"
>  #include "exynos_drm_ipp.h"
> 
>  /*
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index 24376c1..498647a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -24,6 +24,7 @@
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_crtc.h"
>  #include "exynos_drm_encoder.h"
> +#include "exynos_drm_vidi.h"
> 
>  /* vidi has totally three virtual windows. */
>  #define WINDOWS_NR		3
> --
> 1.8.3.1



From ambresh at ti.com  Tue Jul  2 08:23:41 2013
From: ambresh at ti.com (Ambresh K)
Date: Tue, 2 Jul 2013 17:53:41 +0530
Subject: [3.10] [AM335x-EVMSK] BUG: spinlock bad magic on CPU#0
Message-ID: <51D2C64D.5000500@ti.com>

Hi, 
While booting 3.10 on AM355x-evmsk with following steps seeing race condition leading to SPIN BUG:
Attached  log for reference.

Config: omap2plus_defconfig. 
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage -j 8 LOADADDR=0x80008000
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- am335x-evmsk.dtb
cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-evmsk.dtb > zImage
mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d zImage uImage  


[    2.359689] cpsw: platform data missing
[    2.364835] BUG: spinlock bad magic on CPU#0, swapper/0/1
[    2.370537]  lock: 0xce11021c, .magic: 00000000, .owner: /0, .owner_cpu: 3
[    2.377767] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-dirty #10
[    2.384662] [<c001bf38>] (unwind_backtrace+0x0/0xf4) from [<c0018650>] (show_stack+0x10/0x14)
[    2.393639] [<c0018650>] (show_stack+0x10/0x14) from [<c02ec380>] (do_raw_spin_lock+0x1b8/0x1f8)
[    2.402896] [<c02ec380>] (do_raw_spin_lock+0x1b8/0x1f8) from [<c054e7a8>] (_raw_spin_lock_irqsave+0x4c/0x58)
[    2.413243] [<c054e7a8>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c035d3d0>] (devres_remove+0x20/0x80)
[    2.423125] [<c035d3d0>] (devres_remove+0x20/0x80) from [<c035d440>] (devres_release+0x10/0x38)
[    2.432273] [<c035d440>] (devres_release+0x10/0x38) from [<c02fa718>] (devm_pinctrl_put+0x18/0x40)
[    2.441699] [<c02fa718>] (devm_pinctrl_put+0x18/0x40) from [<c0370470>] (pinctrl_bind_pins+0x84/0xb8)
[    2.451397] [<c0370470>] (pinctrl_bind_pins+0x84/0xb8) from [<c035a588>] (driver_probe_device+0x60/0x224)
[    2.461462] [<c035a588>] (driver_probe_device+0x60/0x224) from [<c035a7e0>] (__driver_attach+0x94/0x98)
[    2.471343] [<c035a7e0>] (__driver_attach+0x94/0x98) from [<c0358dd0>] (bus_for_each_dev+0x68/0x8c)
[    2.480857] [<c0358dd0>] (bus_for_each_dev+0x68/0x8c) from [<c0359714>] (bus_add_driver+0x208/0x2a4)
[    2.490462] [<c0359714>] (bus_add_driver+0x208/0x2a4) from [<c035adb4>] (driver_register+0x78/0x194)
[    2.500067] [<c035adb4>] (driver_register+0x78/0x194) from [<c0008684>] (do_one_initcall+0x30/0x168)
[    2.509682] [<c0008684>] (do_one_initcall+0x30/0x168) from [<c075c308>] (kernel_init_freeable+0xf4/0x1c0)
[    2.519745] [<c075c308>] (kernel_init_freeable+0xf4/0x1c0) from [<c05454cc>] (kernel_init+0x8/0xe4)
[    2.529268] [<c05454cc>] (kernel_init+0x8/0xe4) from [<c00142e8>] (ret_from_fork+0x14/0x2c)
[   11.974206] BUG: spinlock lockup suspected on CPU#0, swapper/0/1
[   11.980519]  lock: 0xce11021c, .magic: 00000000, .owner: /0, .owner_cpu: 3
[   11.987744] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-dirty #10
[   11.994612] [<c001bf38>] (unwind_backtrace+0x0/0xf4) from [<c0018650>] (show_stack+0x10/0x14)
[   12.003577] [<c0018650>] (show_stack+0x10/0x14) from [<c02ec338>] (do_raw_spin_lock+0x170/0x1f8)
[   12.012818] [<c02ec338>] (do_raw_spin_lock+0x170/0x1f8) from [<c054e7a8>] (_raw_spin_lock_irqsave+0x4c/0x58)
[   12.023155] [<c054e7a8>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c035d3d0>] (devres_remove+0x20/0x80)
[   12.033033] [<c035d3d0>] (devres_remove+0x20/0x80) from [<c035d440>] (devres_release+0x10/0x38)
[   12.042179] [<c035d440>] (devres_release+0x10/0x38) from [<c02fa718>] (devm_pinctrl_put+0x18/0x40)
[   12.051600] [<c02fa718>] (devm_pinctrl_put+0x18/0x40) from [<c0370470>] (pinctrl_bind_pins+0x84/0xb8)
[   12.061294] [<c0370470>] (pinctrl_bind_pins+0x84/0xb8) from [<c035a588>] (driver_probe_device+0x60/0x224)
[   12.071352] [<c035a588>] (driver_probe_device+0x60/0x224) from [<c035a7e0>] (__driver_attach+0x94/0x98)
[   12.081228] [<c035a7e0>] (__driver_attach+0x94/0x98) from [<c0358dd0>] (bus_for_each_dev+0x68/0x8c)
[   12.090738] [<c0358dd0>] (bus_for_each_dev+0x68/0x8c) from [<c0359714>] (bus_add_driver+0x208/0x2a4)
[   12.100339] [<c0359714>] (bus_add_driver+0x208/0x2a4) from [<c035adb4>] (driver_register+0x78/0x194)
[   12.109940] [<c035adb4>] (driver_register+0x78/0x194) from [<c0008684>] (do_one_initcall+0x30/0x168)
[   12.119545] [<c0008684>] (do_one_initcall+0x30/0x168) from [<c075c308>] (kernel_init_freeable+0xf4/0x1c0)
[   12.129602] [<c075c308>] (kernel_init_freeable+0xf4/0x1c0) from [<c05454cc>] (kernel_init+0x8/0xe4)
[   12.139112] [<c05454cc>] (kernel_init+0x8/0xe4) from [<c00142e8>] (ret_from_fork+0x14/0x2c)

Regards,
Ambresh
-------------- next part --------------
U-Boot 2012.10 (Jul 02 2013 - 10:41:19)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net:   cpsw, usb_ether
Hit any key to stop autoboot:  0 
U-Boot# 
U-Boot# 
U-Boot# 
U-Boot# 
U-Boot# setenv bootargs console=ttyO0,115200n8 root=/dev/ram0 rw ramdisk_size=64413 initrd=0x81600000,64M no_console_suspend
U-Boot# fatload mmc 0 0x81600000 ramdisk-pm.gz; fatload mmc 0 0x80300000 uimage; bootm 0x80300000
reading ramdisk-pm.gz

2022580 bytes read
reading uimage

4390952 bytes read
## Booting kernel from Legacy Image at 80300000 ...
   Image Name:   Linux
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4390888 Bytes = 4.2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.10.0-dirty (a0393775 at ula0393775) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #10 SMP Tue Jul 2 17:19:30 IST 2013
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x EVM-SK
[    0.000000] cma: CMA: reserved 16 MiB at 8e800000
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] DT missing boot CPU MPIDR[23:0], fall back to default cpu_logical_map
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] AM335X ES2.1 (neon )
[    0.000000] PERCPU: Embedded 9 pages/cpu @c0fc8000 s13632 r8192 d15040 u36864
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64768
[    0.000000] Kernel command line: console=ttyO0,115200n8 root=/dev/ram0 rw ramdisk_size=64413 initrd=0x81600000,64M no_console_suspend
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 255MB = 255MB total
[    0.000000] Memory: 162768k/162768k available, 99376k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc075b260   (7501 kB)
[    0.000000]       .init : 0xc075c000 - 0xc07be540   ( 394 kB)
[    0.000000]       .data : 0xc07c0000 - 0xc0856408   ( 602 kB)
[    0.000000]        .bss : 0xc0856408 - 0xc0dba8e0   (5522 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: timer2 at 24000000 Hz
[    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[    0.000000] OMAP clocksource: timer1 at 24000000 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.001046] Calibrating delay loop... 476.77 BogoMIPS (lpj=2383872)
[    0.119668] pid_max: default: 32768 minimum: 301
[    0.120181] Security Framework initialized
[    0.120341] Mount-cache hash table entries: 512
[    0.131989] CPU: Testing write buffer coherency: ok
[    0.133549] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.133633] Setting up static identity map for 0xc0554688 - 0xc05546f8
[    0.136755] Brought up 1 CPUs
[    0.136780] SMP: Total of 1 processors activated (476.77 BogoMIPS).
[    0.136792] CPU: All CPU(s) started in SVC mode.
[    0.140055] devtmpfs: initialized
[    0.214310] pinctrl core: initialized pinctrl subsystem
[    0.218999] regulator-dummy: no parameters
[    0.222983] NET: Registered protocol family 16
[    0.231414] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.254858] OMAP GPIO hardware version 0.1
[    0.279489] No ATAGs?
[    0.279520] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.346184] bio: create slab <bio-0> at 0
[    0.351901] vbat: 5000 mV 
[    0.353124] lis3_reg: no parameters
[    0.360906] SCSI subsystem initialized
[    0.363224] usbcore: registered new interface driver usbfs
[    0.363722] usbcore: registered new interface driver hub
[    0.364567] usbcore: registered new device driver usb
[    0.366632] omap_i2c 44e0b000.i2c: did not get pins for i2c error: -19
[    0.368841] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[    0.371673] tps65910 0-002d: No interrupt support, no core IRQ
[    0.377529] vrtc: 1800 mV 
[    0.377955] vrtc: supplied by vbat
[    0.381841] vio: at 1500 mV 
[    0.382002] vio: supplied by vbat
[    0.385095] vdd_mpu: 912 <--> 1312 mV at 1262 mV 
[    0.385249] vdd_mpu: supplied by vbat
[    0.388273] vdd_core: 912 <--> 1150 mV at 1137 mV 
[    0.388420] vdd_core: supplied by vbat
[    0.391229] vdd3: 5000 mV 
[    0.393699] vdig1: at 1800 mV 
[    0.393843] vdig1: supplied by vbat
[    0.396566] vdig2: at 1800 mV 
[    0.396705] vdig2: supplied by vbat
[    0.399416] vpll: at 1800 mV 
[    0.399553] vpll: supplied by vbat
[    0.402455] vdac: at 1800 mV 
[    0.402618] vdac: supplied by vbat
[    0.405242] vaux1: at 1800 mV 
[    0.405382] vaux1: supplied by vbat
[    0.408105] vaux2: at 3300 mV 
[    0.408271] vaux2: supplied by vbat
[    0.411267] vaux33: at 3300 mV 
[    0.411415] vaux33: supplied by vbat
[    0.414092] vmmc: at 3300 mV 
[    0.414254] vmmc: supplied by vbat
[    0.426233] Switching to clocksource timer1
[    0.568841] NET: Registered protocol family 2
[    0.571034] TCP established hash table entries: 2048 (order: 2, 16384 bytes)
[    0.571258] TCP bind hash table entries: 2048 (order: 4, 73728 bytes)
[    0.572213] TCP: Hash tables configured (established 2048 bind 2048)
[    0.572436] TCP: reno registered
[    0.572475] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.572738] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.574107] NET: Registered protocol family 1
[    0.575708] RPC: Registered named UNIX socket transport module.
[    0.575733] RPC: Registered udp transport module.
[    0.575746] RPC: Registered tcp transport module.
[    0.575758] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.577019] Trying to unpack rootfs image as initramfs...
[    0.579171] rootfs image is not initramfs (no cpio magic); looks like an initrd
[    1.021655] Freeing initrd memory: 65536K (c1600000 - c5600000)
[    1.021842] NetWinder Floating Point Emulator V0.97 (double precision)
[    1.219409] VFS: Disk quotas dquot_6.5.2
[    1.219665] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.222489] NFS: Registering the id_resolver key type
[    1.222980] Key type id_resolver registered
[    1.223003] Key type id_legacy registered
[    1.223156] jffs2: version 2.2. (NAND) (SUMMARY)  ? 2001-2006 Red Hat, Inc.
[    1.223756] msgmni has been set to 477
[    1.227535] io scheduler noop registered
[    1.227562] io scheduler deadline registered
[    1.227666] io scheduler cfq registered (default)
[    1.229234] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[    1.233961] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    1.241344] omap_uart 44e09000.serial: did not get pins for uart0 error: -19
[    1.242262] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
[    1.948967] console [ttyO0] enabled
[    1.987501] brd: module loaded
[    2.012066] loop: module loaded
[    2.021427] mtdoops: mtd device (mtddev=name/number) must be supplied
[    2.035971] usbcore: registered new interface driver asix
[    2.042657] usbcore: registered new interface driver ax88179_178a
[    2.051197] usbcore: registered new interface driver cdc_ether
[    2.058131] usbcore: registered new interface driver smsc95xx
[    2.064644] usbcore: registered new interface driver net1080
[    2.071323] usbcore: registered new interface driver cdc_subset
[    2.078228] usbcore: registered new interface driver zaurus
[    2.084675] usbcore: registered new interface driver cdc_ncm
[    2.093084] usbcore: registered new interface driver cdc_wdm
[    2.099788] usbcore: registered new interface driver usb-storage
[    2.106758] usbcore: registered new interface driver usbtest
[    2.115100] mousedev: PS/2 mouse device common for all mice
[    2.127933] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
[    2.135460] 44e3e000.rtc: already running
[    2.141107] i2c /dev entries driver
[    2.147561] Driver for 1-wire Dallas network protocol.
[    2.158055] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    2.169434] leds-gpio leds.5: pins are not configured from the driver
[    2.182533] ledtrig-cpu: registered to indicate activity on CPUs
[    2.190918] usbcore: registered new interface driver usbhid
[    2.196941] usbhid: USB HID core driver
[    2.202582] oprofile: no performance counters
[    2.209988] oprofile: using timer interrupt.
[    2.215285] TCP: cubic registered
[    2.218980] Initializing XFRM netlink socket
[    2.223692] NET: Registered protocol family 17
[    2.228531] NET: Registered protocol family 15
[    2.233631] Key type dns_resolver registered
[    2.238346] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    2.246518] ThumbEE CPU extension supported.
[    2.316768] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    2.323207] davinci_mdio 4a101000.mdio: detected phy mask fffffffc
[    2.333722] libphy: 4a101000.mdio: probed
[    2.338091] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver unknown
[    2.346510] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, driver unknown
[    2.355135] Missing slave[0] phy_id property
[    2.359689] cpsw: platform data missing
[    2.364835] BUG: spinlock bad magic on CPU#0, swapper/0/1
[    2.370537]  lock: 0xce11021c, .magic: 00000000, .owner: /0, .owner_cpu: 3
[    2.377767] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-dirty #10
[    2.384662] [<c001bf38>] (unwind_backtrace+0x0/0xf4) from [<c0018650>] (show_stack+0x10/0x14)
[    2.393639] [<c0018650>] (show_stack+0x10/0x14) from [<c02ec380>] (do_raw_spin_lock+0x1b8/0x1f8)
[    2.402896] [<c02ec380>] (do_raw_spin_lock+0x1b8/0x1f8) from [<c054e7a8>] (_raw_spin_lock_irqsave+0x4c/0x58)
[    2.413243] [<c054e7a8>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c035d3d0>] (devres_remove+0x20/0x80)
[    2.423125] [<c035d3d0>] (devres_remove+0x20/0x80) from [<c035d440>] (devres_release+0x10/0x38)
[    2.432273] [<c035d440>] (devres_release+0x10/0x38) from [<c02fa718>] (devm_pinctrl_put+0x18/0x40)
[    2.441699] [<c02fa718>] (devm_pinctrl_put+0x18/0x40) from [<c0370470>] (pinctrl_bind_pins+0x84/0xb8)
[    2.451397] [<c0370470>] (pinctrl_bind_pins+0x84/0xb8) from [<c035a588>] (driver_probe_device+0x60/0x224)
[    2.461462] [<c035a588>] (driver_probe_device+0x60/0x224) from [<c035a7e0>] (__driver_attach+0x94/0x98)
[    2.471343] [<c035a7e0>] (__driver_attach+0x94/0x98) from [<c0358dd0>] (bus_for_each_dev+0x68/0x8c)
[    2.480857] [<c0358dd0>] (bus_for_each_dev+0x68/0x8c) from [<c0359714>] (bus_add_driver+0x208/0x2a4)
[    2.490462] [<c0359714>] (bus_add_driver+0x208/0x2a4) from [<c035adb4>] (driver_register+0x78/0x194)
[    2.500067] [<c035adb4>] (driver_register+0x78/0x194) from [<c0008684>] (do_one_initcall+0x30/0x168)
[    2.509682] [<c0008684>] (do_one_initcall+0x30/0x168) from [<c075c308>] (kernel_init_freeable+0xf4/0x1c0)
[    2.519745] [<c075c308>] (kernel_init_freeable+0xf4/0x1c0) from [<c05454cc>] (kernel_init+0x8/0xe4)
[    2.529268] [<c05454cc>] (kernel_init+0x8/0xe4) from [<c00142e8>] (ret_from_fork+0x14/0x2c)
[   11.974206] BUG: spinlock lockup suspected on CPU#0, swapper/0/1
[   11.980519]  lock: 0xce11021c, .magic: 00000000, .owner: /0, .owner_cpu: 3
[   11.987744] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-dirty #10
[   11.994612] [<c001bf38>] (unwind_backtrace+0x0/0xf4) from [<c0018650>] (show_stack+0x10/0x14)
[   12.003577] [<c0018650>] (show_stack+0x10/0x14) from [<c02ec338>] (do_raw_spin_lock+0x170/0x1f8)
[   12.012818] [<c02ec338>] (do_raw_spin_lock+0x170/0x1f8) from [<c054e7a8>] (_raw_spin_lock_irqsave+0x4c/0x58)
[   12.023155] [<c054e7a8>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c035d3d0>] (devres_remove+0x20/0x80)
[   12.033033] [<c035d3d0>] (devres_remove+0x20/0x80) from [<c035d440>] (devres_release+0x10/0x38)
[   12.042179] [<c035d440>] (devres_release+0x10/0x38) from [<c02fa718>] (devm_pinctrl_put+0x18/0x40)
[   12.051600] [<c02fa718>] (devm_pinctrl_put+0x18/0x40) from [<c0370470>] (pinctrl_bind_pins+0x84/0xb8)
[   12.061294] [<c0370470>] (pinctrl_bind_pins+0x84/0xb8) from [<c035a588>] (driver_probe_device+0x60/0x224)
[   12.071352] [<c035a588>] (driver_probe_device+0x60/0x224) from [<c035a7e0>] (__driver_attach+0x94/0x98)
[   12.081228] [<c035a7e0>] (__driver_attach+0x94/0x98) from [<c0358dd0>] (bus_for_each_dev+0x68/0x8c)
[   12.090738] [<c0358dd0>] (bus_for_each_dev+0x68/0x8c) from [<c0359714>] (bus_add_driver+0x208/0x2a4)
[   12.100339] [<c0359714>] (bus_add_driver+0x208/0x2a4) from [<c035adb4>] (driver_register+0x78/0x194)
[   12.109940] [<c035adb4>] (driver_register+0x78/0x194) from [<c0008684>] (do_one_initcall+0x30/0x168)
[   12.119545] [<c0008684>] (do_one_initcall+0x30/0x168) from [<c075c308>] (kernel_init_freeable+0xf4/0x1c0)
[   12.129602] [<c075c308>] (kernel_init_freeable+0xf4/0x1c0) from [<c05454cc>] (kernel_init+0x8/0xe4)
[   12.139112] [<c05454cc>] (kernel_init+0x8/0xe4) from [<c00142e8>] (ret_from_fork+0x14/0x2c)



From jason at lakedaemon.net  Tue Jul  2 08:46:39 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 2 Jul 2013 08:46:39 -0400
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <87fvvzfh70.fsf@natisbad.org>
References: <87fvvzfh70.fsf@natisbad.org>
Message-ID: <20130702124639.GI19937@titan.lakedaemon.net>

Arnaud,

On Sun, Jun 30, 2013 at 10:59:31PM +0200, Arnaud Ebalard wrote:
> Regarding the device, I put some information on the various hardware
> parts here: http://natisbad.org/NAS2/ . I still have to update the
> page now that almost everything is as it should.

Nice!

> With the appended .dts file, all the various parts of the device work
> as expected:
> 
>  - USB 3.0 rear ports via FL1009 XHCI controller connected to PCIe
>    bus (eSATA not tested yet)
>  - USB 2.0 front port
>  - Gigabit Ethernet port (MAC needs to be set by the system at boot)
>  - Backup, Power and Reset buttons
>  - LEDS (most set to on but changeable). At the moment, I still have not
>    found by which gpio the last one is controlled (activity led).
>  - serial port at the rear
> 
>  - G762 PWM fan controller on I2C bus: it requires G762 driver which
>    is *currently sitting in hwmon maintainer tree* and will be available
>    in 3.11. Jason, as a side note I have a short patch for available for
>    ReadyNAS Duo v2 .dts file (the device also has a G762). I can hold
>    it until rc cycle if you prefer.

Nope, post patches when you have them ready.  I am capable of holding
them until -rc1 drops ;-)

>  - Intersil ISL 12057 RTC on I2C bus: support for that one is *not
>    available upstream yet* but I have an initial working patch which I
>    intend to push upstream (same as for G762 driver).
> 
> In the end, the main missing part is the NAND but I guess this is the
> same for all Aramda 370/XP boards and this is not a big issue as it is
> still possible to interact w/ it via u-boot and install a set of
> uImage/uInitramfs that way. 

What's the big blocker for this?  Once this is done, debian should be
able to add support for this board.  After all, upgrading the kernel and
initrd from userspace is a desirable option.

> Jason, the tests were done against your for-next branch (with all the
> fixes which accumulated in Linux tree from rc7). I will work directly
> against Linus tree as soon as the rc- cycle for 3.11 starts. 

hmmm, my latest for-next (20130623) is based against v3.10-rc7, are you
using that?

> Additionally, I don't think this is a problem but my whole toolchain is
> an arm-linux-gnueabi- one and the tests were done using a Debian (ho hfp
> at all).

I do believe there is an active aversion to floating point within the
kernel, you should be fine.  We also don't like C libraries, or
hamsters, apparently.

> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
> ---
>  arch/arm/boot/dts/Makefile                     |   1 +
>  arch/arm/boot/dts/armada-370-netgear-rn102.dts | 215 +++++++++++++++++++++++++
>  2 files changed, 216 insertions(+)
>  create mode 100644 arch/arm/boot/dts/armada-370-netgear-rn102.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ae7124c..076ff01 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -97,6 +97,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
>  	msm8960-cdp.dtb
>  dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>  	armada-370-mirabox.dtb \
> +	armada-370-netgear-rn102.dtb \
>  	armada-370-rd.dtb \
>  	armada-xp-db.dtb \
>  	armada-xp-gp.dtb \
> diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
> new file mode 100644
> index 0000000..5a9e129
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
> @@ -0,0 +1,215 @@
> +/*
> + * Device Tree file for NETGEAR ReadyNAS 102
> + *
> + * Copyright (C) 2013, Arnaud EBALARD <arno at natisbad.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +/dts-v1/;
> +
> +/include/ "armada-370.dtsi"
> +
> +/ {
> +	model = "NETGEAR ReadyNAS 102";
> +	compatible = "netgear,readynas-102", "marvell,armada370", "marvell,armada-370-xp";
> +
> +	chosen {
> +		bootargs = "console=ttyS0,115200 earlyprintk";
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x20000000>; /* 512 MB */
> +	};
> +
> +	soc {
> +		internal-regs {
> +			serial at 12000 {
> +				clock-frequency = <200000000>;
> +				status = "okay";
> +			};
> +
> +			sata at a0000 {
> +				nr-ports = <2>;
> +				status = "okay";
> +			};
> +
> +			pinctrl {
> +				power_led_pin: power-led-pin {
> +					marvell,pins = "mpp57";
> +					marvell,function = "gpio";
> +				};
> +				sata1_led_pin: sata1-led-pin {
> +					marvell,pins = "mpp15";
> +					marvell,function = "gpio";
> +				};
> +
> +				sata2_led_pin: sata2-led-pin {
> +					marvell,pins = "mpp14";
> +					marvell,function = "gpio";
> +				};
> +
> +				backup_led_pin: backup-led-pin {
> +					marvell,pins = "mpp56";
> +					marvell,function = "gpio";
> +				};
> +			};
> +
> +			gpio_leds {
> +				compatible = "gpio-leds";
> +				pinctrl-0 = < &power_led_pin
> +					      &sata1_led_pin
> +					      &sata2_led_pin
> +					      &backup_led_pin >;
> +				pinctrl-names = "default";
> +
> +				blue_power_led {
> +					label = "rn102:blue:pwr";
> +					gpios = <&gpio1 25 1>;  /* GPIO 57 Active Low */
> +					linux,default-trigger = "heartbeat";
> +				};
> +
> +				green_sata1_led {
> +					label = "rn102:green:sata1";
> +					gpios = <&gpio0 15 1>;  /* GPIO 15 Active Low */
> +					default-state = "on";
> +				};
> +
> +				green_sata2_led {
> +					label = "rn102:green:sata2";
> +					gpios = <&gpio0 14 1>;   /* GPIO 14 Active Low */
> +					default-state = "on";
> +				};
> +
> +				green_backup_led {
> +					label = "rn102:green:backup";
> +					gpios = <&gpio1 24 1>;   /* GPIO 56 Active Low */
> +					default-state = "on";
> +				};
> +			};
> +
> +			gpio_keys {
> +				compatible = "gpio-keys";
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				button at 1 {
> +					label = "Power Button";
> +					linux,code = <116>;     /* KEY_POWER */
> +					gpios = <&gpio1 30 1>;
> +				};
> +				button at 2 {
> +					label = "Reset Button";
> +					linux,code = <0x198>;   /* KEY_RESTART */
> +					gpios = <&gpio0 6 1>;
> +				};
> +				button at 3 {
> +					label = "Backup Button";
> +					linux,code = <133>;     /* KEY_COPY */
> +					gpios = <&gpio1 26 1>;
> +				};
> +			};
> +
> +			mdio {
> +				phy0: ethernet-phy at 0 {
> +					reg = <0>;
> +				};
> +			};
> +
> +			ethernet at 74000 {
> +				status = "okay";
> +				phy = <&phy0>;
> +				phy-mode = "rgmii-id";
> +			};
> +
> +			/* Waiting for NAND support to appear in armada-370.dtsi

I would just leave this out until we get the driver sorted.

thx,

Jason.

> +
> +			nand at d0000 {
> +				status = "okay";
> +
> +				partition at 0 {
> +				   label = "u-boot";
> +				   reg = <0x0000000 0x180000>;
> +				   read-only;
> +				};
> +
> +				partition at 180000 {
> +				   label = "u-boot-env";
> +				   reg = <0x180000 0x20000>;
> +				};
> +
> +				partition at 200000 {
> +				   label = "uImage";
> +				   reg = <0x0200000 0x600000>;
> +				};
> +
> +				partition at 800000 {
> +				   label = "minirootfs";
> +				   reg = <0x0800000 0x400000>;
> +				};
> +
> +				partition at c00000 {
> +				   label = "ubi";
> +				   reg = <0x0c00000 0x7400000>;
> +				};
> +			};
> +
> +			*/
> +
> +			usb at 50000 {
> +				status = "okay";
> +			};
> +
> +			clocks {
> +			       #address-cells = <1>;
> +			       #size-cells = <0>;
> +
> +			       g762_clk: fixedclk {
> +					 compatible = "fixed-clock";
> +					 #clock-cells = <0>;
> +					 clock-frequency = <8192>;
> +			       };
> +			};
> +
> +			i2c at 11000 {
> +				compatible = "marvell,mv64xxx-i2c";
> +				clock-frequency = <100000>;
> +				status = "okay";
> +
> +				isl12057: isl12057 at 68 {
> +					compatible = "isil,isl12057";
> +					reg = <0x68>;
> +					wakeup-source;
> +				};
> +
> +				g762: g762 at 3e {
> +					compatible = "gmt,g762";
> +					reg = <0x3e>;
> +					clocks = <&g762_clk>; /* input clock */
> +					fan_gear_mode = <0>;
> +					fan_startv = <1>;
> +					pwm_polarity = <0>;
> +				};
> +			};
> +
> +			pcie-controller {
> +				status = "okay";
> +
> +				/* Connected to Marvell SATA controller */
> +				pcie at 1,0 {
> +					/* Port 0, Lane 0 */
> +					status = "okay";
> +				};
> +
> +				/* Connected to FL1009 USB 3.0 controller */
> +				pcie at 2,0 {
> +					/* Port 1, Lane 0 */
> +					status = "okay";
> +				};
> +			};
> +		};
> +	};
> +};
> -- 
> 1.8.3.1
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From sebastian.hesselbarth at gmail.com  Tue Jul  2 08:51:16 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue, 02 Jul 2013 14:51:16 +0200
Subject: [PATCH v4 5/7] ARM: kirkwood: convert to DT irqchip and
 clocksource
In-Reply-To: <20130702115311.GG19937@titan.lakedaemon.net>
References: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1372763023-12374-6-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130702115311.GG19937@titan.lakedaemon.net>
Message-ID: <51D2CCC4.30109@gmail.com>

On 07/02/13 13:53, Jason Cooper wrote:
> On Tue, Jul 02, 2013 at 01:03:41PM +0200, Sebastian Hesselbarth wrote:
>> With recent support for true irqchip and clocksource drivers for Orion
>> SoCs, now make use of it on DT enabled Kirkwood boards.
>>
>> This also introduces a new Kconfig option for legacy (non-DT) Kirkwood
>> where old code is moved out to and polishes DT board file a little bit.
>>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
>> ---
[...]
>> diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
>> index 881f37e..385244c 100644
>> --- a/arch/arm/mach-kirkwood/board-dt.c
>> +++ b/arch/arm/mach-kirkwood/board-dt.c
>> @@ -15,6 +15,9 @@
>>   #include <linux/of.h>
>>   #include <linux/of_platform.h>
>>   #include <linux/clk-provider.h>
>> +#include <linux/clocksource.h>
>> +#include <linux/dma-mapping.h>
>> +#include <linux/irqchip.h>
>>   #include <linux/kexec.h>
>>   #include <asm/mach/arch.h>
>>   #include <asm/mach/map.h>
>> @@ -67,10 +70,18 @@ static void __init kirkwood_legacy_clk_init(void)
>>   	clk_prepare_enable(clk);
>>   }
>>
>> -static void __init kirkwood_of_clk_init(void)
>> +static void __init kirkwood_dt_time_init(void)
>>   {
>>   	of_clk_init(NULL);
>> -	kirkwood_legacy_clk_init();
>> +	clocksource_of_init();
>> +}
>> +
>> +static void __init kirkwood_dt_init_early(void)
>> +{
>
>
>> +	init_dma_coherent_pool_size(SZ_1M);
>
> This shouldn't be needed any more.  Is there a reason you're adding it
> back in?

Jason, thanks for catching this. The last patch I had was before removal
of init_dma_coherent_pool_size. I slipped back in because I missed the
removal patches.

Can you remove it prior merge, should I prepare a fixup patch, or respin
this patch?

Sebastian



From lorenzo.pieralisi at arm.com  Tue Jul  2 08:56:42 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 2 Jul 2013 13:56:42 +0100
Subject: [PATCH 0/2] ARM: sunxi: Convert DTSI to new CPU bindings
In-Reply-To: <51D2C3A9.5080809@atmel.com>
References: <1372437844-16325-1-git-send-email-maxime.ripard@free-electrons.com>
 <51D2C3A9.5080809@atmel.com>
Message-ID: <20130702125642.GA10446@e102568-lin.cambridge.arm.com>

On Tue, Jul 02, 2013 at 01:12:25PM +0100, Nicolas Ferre wrote:
> On 28/06/2013 18:44, Maxime Ripard :
> > Hi Arnd, Olof,
> >
> > Sorry for steping in so late, but these two patches fixes a warning
> > introduced by the commit 1ba9bf0a (ARM: 7762/1: kernel: fix
> > arm_dt_init_cpu_maps() to skip non-cpu nodes) after 3.10-rc7.
> >
> > These two patches solve the situation for sunxi. The first one by
> > Lorenzo is to be applied for 3.10 if it's still possible, and the
> > second one on top of arm-soc/for-next. Tell me if you prefer a more
> > formal pull request for these patches
> 
> Just for the heads-up, the same happened to AT91 SAMA5D3.
> As the solution is already in linux-next, we simply have to make sure 
> that the patch is reported to the stable branches...

Not really. I dropped 1ba9bf0a (ARM 7762/1) from stable kernel queues, hence
if and when we decide to backport all these DT updates/fixes to stable kernels
we will have to do it in one go.

Let's postpone this decision until -rc1 is out.

Thanks,
Lorenzo

> 
> Bye,
> 
> 
> >
> > Thanks!
> > Maxime
> >
> > Lorenzo Pieralisi (1):
> >    ARM: dts: sunxi: cpus/cpu nodes dts updates
> >
> > Maxime Ripard (1):
> >    sunxi: a10s: dtsi: Convert cpu node to the new cpu bindings
> >
> >   arch/arm/boot/dts/sun4i-a10.dtsi  | 2 ++
> >   arch/arm/boot/dts/sun5i-a10s.dtsi | 2 ++
> >   arch/arm/boot/dts/sun5i-a13.dtsi  | 2 ++
> >   3 files changed, 6 insertions(+)
> >
> 
> 
> -- 
> Nicolas Ferre
> 



From jason at lakedaemon.net  Tue Jul  2 09:00:13 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 2 Jul 2013 09:00:13 -0400
Subject: [PATCH v4 5/7] ARM: kirkwood: convert to DT irqchip and
 clocksource
In-Reply-To: <51D2CCC4.30109@gmail.com>
References: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1372763023-12374-6-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130702115311.GG19937@titan.lakedaemon.net>
 <51D2CCC4.30109@gmail.com>
Message-ID: <20130702130013.GJ19937@titan.lakedaemon.net>

On Tue, Jul 02, 2013 at 02:51:16PM +0200, Sebastian Hesselbarth wrote:
> On 07/02/13 13:53, Jason Cooper wrote:
> >On Tue, Jul 02, 2013 at 01:03:41PM +0200, Sebastian Hesselbarth wrote:
> >>With recent support for true irqchip and clocksource drivers for Orion
> >>SoCs, now make use of it on DT enabled Kirkwood boards.
> >>
> >>This also introduces a new Kconfig option for legacy (non-DT) Kirkwood
> >>where old code is moved out to and polishes DT board file a little bit.
> >>
> >>Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> >>---
> [...]
> >>diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
> >>index 881f37e..385244c 100644
> >>--- a/arch/arm/mach-kirkwood/board-dt.c
> >>+++ b/arch/arm/mach-kirkwood/board-dt.c
> >>@@ -15,6 +15,9 @@
> >>  #include <linux/of.h>
> >>  #include <linux/of_platform.h>
> >>  #include <linux/clk-provider.h>
> >>+#include <linux/clocksource.h>
> >>+#include <linux/dma-mapping.h>
> >>+#include <linux/irqchip.h>
> >>  #include <linux/kexec.h>
> >>  #include <asm/mach/arch.h>
> >>  #include <asm/mach/map.h>
> >>@@ -67,10 +70,18 @@ static void __init kirkwood_legacy_clk_init(void)
> >>  	clk_prepare_enable(clk);
> >>  }
> >>
> >>-static void __init kirkwood_of_clk_init(void)
> >>+static void __init kirkwood_dt_time_init(void)
> >>  {
> >>  	of_clk_init(NULL);
> >>-	kirkwood_legacy_clk_init();
> >>+	clocksource_of_init();
> >>+}
> >>+
> >>+static void __init kirkwood_dt_init_early(void)
> >>+{
> >
> >
> >>+	init_dma_coherent_pool_size(SZ_1M);
> >
> >This shouldn't be needed any more.  Is there a reason you're adding it
> >back in?
> 
> Jason, thanks for catching this. The last patch I had was before removal
> of init_dma_coherent_pool_size. I slipped back in because I missed the
> removal patches.

ah, ok.

> Can you remove it prior merge, should I prepare a fixup patch, or respin
> this patch?

Please check for other occurrences (all should be gone), and post a v2
of only the affected patches.

thx,

Jason.


From thomas.petazzoni at free-electrons.com  Tue Jul  2 09:14:07 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 2 Jul 2013 15:14:07 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130702124639.GI19937@titan.lakedaemon.net>
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net>
Message-ID: <20130702151407.01680d21@skate>

Dear Jason Cooper,

On Tue, 2 Jul 2013 08:46:39 -0400, Jason Cooper wrote:

> > In the end, the main missing part is the NAND but I guess this is the
> > same for all Aramda 370/XP boards and this is not a big issue as it is
> > still possible to interact w/ it via u-boot and install a set of
> > uImage/uInitramfs that way. 
> 
> What's the big blocker for this?  Once this is done, debian should be
> able to add support for this board.  After all, upgrading the kernel and
> initrd from userspace is a desirable option.

The big blocker is that no-one has written  the driver for it. It is
still on our (Free Electrons) TODO-list, but not as a top-priority item
for the moment.

Ezequiel had started to do some preliminary cleanup work on the
pxa3xx-nand driver, with the ultimate goal of making it support Armada
370/XP (because the IP in the Armada 370/XP is apparently an evolution
of the PXA3xx NAND controller), but our priorities shifted to those
other topics. We will back on it some day, but I can't say when at the
moment.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From sebastian.hesselbarth at gmail.com  Tue Jul  2 09:15:07 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue,  2 Jul 2013 15:15:07 +0200
Subject: [PATCH v5 5/7] ARM: kirkwood: convert to DT irqchip and clocksource
In-Reply-To: <1372763023-12374-6-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372763023-12374-6-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372770907-32738-1-git-send-email-sebastian.hesselbarth@gmail.com>

With recent support for true irqchip and clocksource drivers for Orion
SoCs, now make use of it on DT enabled Kirkwood boards.

This also introduces a new Kconfig option for legacy (non-DT) Kirkwood
where old code is moved out to and polishes DT board file a little bit.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
--- 
Changelog:
v4->v5:
- do not re-introduce already removed init_dma_coherent_pool_size
  (Reported by Jason Cooper)

@Jason: I did a 'git grep init_dma_coherent_pool_size' and now there
are no users of that function - as it was before. Patch 6/7 only differs
in the 'index' diff line because of the rebase here. I will not resend that,
it should still apply.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/mach-kirkwood/Kconfig    |   22 ++++++++++++++++++++++
 arch/arm/mach-kirkwood/Makefile   |    4 ++--
 arch/arm/mach-kirkwood/board-dt.c |   23 ++++++++++++++++-------
 3 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 493c71a..ede131e 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -2,67 +2,81 @@ if ARCH_KIRKWOOD
 
 menu "Marvell Kirkwood Implementations"
 
+config KIRKWOOD_LEGACY
+	bool
+
 config MACH_D2NET_V2
 	bool "LaCie d2 Network v2 NAS Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  LaCie d2 Network v2 NAS.
 
 config MACH_DOCKSTAR
 	bool "Seagate FreeAgent DockStar"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Seagate FreeAgent DockStar.
 
 config MACH_ESATA_SHEEVAPLUG
 	bool "Marvell eSATA SheevaPlug Reference Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell eSATA SheevaPlug Reference Board.
 
 config MACH_GURUPLUG
 	bool "Marvell GuruPlug Reference Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell GuruPlug Reference Board.
 
 config MACH_INETSPACE_V2
 	bool "LaCie Internet Space v2 NAS Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  LaCie Internet Space v2 NAS.
 
 config MACH_MV88F6281GTW_GE
 	bool "Marvell 88F6281 GTW GE Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell 88F6281 GTW GE Board.
 
 config MACH_NET2BIG_V2
 	bool "LaCie 2Big Network v2 NAS Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  LaCie 2Big Network v2 NAS.
 
 config MACH_NET5BIG_V2
 	bool "LaCie 5Big Network v2 NAS Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  LaCie 5Big Network v2 NAS.
 
 config MACH_NETSPACE_MAX_V2
 	bool "LaCie Network Space Max v2 NAS Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  LaCie Network Space Max v2 NAS.
 
 config MACH_NETSPACE_V2
 	bool "LaCie Network Space v2 NAS Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  LaCie Network Space v2 NAS.
 
 config MACH_OPENRD
+	select KIRKWOOD_LEGACY
         bool
 
 config MACH_OPENRD_BASE
@@ -88,30 +102,35 @@ config MACH_OPENRD_ULTIMATE
 
 config MACH_RD88F6192_NAS
 	bool "Marvell RD-88F6192-NAS Reference Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell RD-88F6192-NAS Reference Board.
 
 config MACH_RD88F6281
 	bool "Marvell RD-88F6281 Reference Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell RD-88F6281 Reference Board.
 
 config MACH_SHEEVAPLUG
 	bool "Marvell SheevaPlug Reference Board"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell SheevaPlug Reference Board.
 
 config MACH_T5325
 	bool "HP t5325 Thin Client"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  HP t5325 Thin Client.
 
 config MACH_TS219
 	bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
@@ -119,6 +138,7 @@ config MACH_TS219
 
 config MACH_TS41X
 	bool "QNAP TS-410, TS-410U, TS-419P, TS-419P+ and TS-419U Turbo NAS"
+	select KIRKWOOD_LEGACY
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  QNAP TS-410, TS-410U, TS-419P, TS-419P+ and TS-419U Turbo
@@ -129,6 +149,8 @@ comment "Device tree entries"
 config ARCH_KIRKWOOD_DT
 	bool "Marvell Kirkwood Flattened Device Tree"
 	select KIRKWOOD_CLK
+	select ORION_IRQCHIP
+	select ORION_TIMER
 	select POWER_SUPPLY
 	select POWER_RESET
 	select POWER_RESET_GPIO
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 062f8c7..f78f333 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -1,5 +1,5 @@
-obj-y				+= common.o irq.o pcie.o mpp.o
-
+obj-y				+= common.o pcie.o
+obj-$(CONFIG_KIRKWOOD_LEGACY)	+= irq.o mpp.o
 obj-$(CONFIG_MACH_D2NET_V2)		+= d2net_v2-setup.o lacie_v2-common.o
 obj-$(CONFIG_MACH_DOCKSTAR)		+= dockstar-setup.o
 obj-$(CONFIG_MACH_ESATA_SHEEVAPLUG)	+= sheevaplug-setup.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 881f37e..56d4a5e 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -15,6 +15,9 @@
 #include <linux/of.h>
 #include <linux/of_platform.h>
 #include <linux/clk-provider.h>
+#include <linux/clocksource.h>
+#include <linux/dma-mapping.h>
+#include <linux/irqchip.h>
 #include <linux/kexec.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
@@ -67,10 +70,17 @@ static void __init kirkwood_legacy_clk_init(void)
 	clk_prepare_enable(clk);
 }
 
-static void __init kirkwood_of_clk_init(void)
+static void __init kirkwood_dt_time_init(void)
 {
 	of_clk_init(NULL);
-	kirkwood_legacy_clk_init();
+	clocksource_of_init();
+}
+
+static void __init kirkwood_dt_init_early(void)
+{
+	mvebu_mbus_init("marvell,kirkwood-mbus",
+			BRIDGE_WINS_BASE, BRIDGE_WINS_SZ,
+			DDR_WINDOW_CPU_BASE, DDR_WINDOW_CPU_SZ);
 }
 
 static void __init kirkwood_dt_init(void)
@@ -91,8 +101,8 @@ static void __init kirkwood_dt_init(void)
 
 	kirkwood_cpufreq_init();
 
-	/* Setup root of clk tree */
-	kirkwood_of_clk_init();
+	/* Setup clocks for legacy devices */
+	kirkwood_legacy_clk_init();
 
 	kirkwood_cpuidle_init();
 
@@ -114,9 +124,8 @@ static const char * const kirkwood_dt_board_compat[] = {
 DT_MACHINE_START(KIRKWOOD_DT, "Marvell Kirkwood (Flattened Device Tree)")
 	/* Maintainer: Jason Cooper <jason at lakedaemon.net> */
 	.map_io		= kirkwood_map_io,
-	.init_early	= kirkwood_init_early,
-	.init_irq	= orion_dt_init_irq,
-	.init_time	= kirkwood_timer_init,
+	.init_early	= kirkwood_dt_init_early,
+	.init_time	= kirkwood_dt_time_init,
 	.init_machine	= kirkwood_dt_init,
 	.restart	= kirkwood_restart,
 	.dt_compat	= kirkwood_dt_board_compat,
-- 
1.7.2.5



From cb at sgoc.de  Tue Jul  2 09:29:19 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Tue, 2 Jul 2013 15:29:19 +0200 (CEST)
Subject: [PATCHv2 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
In-Reply-To: <1371754675-12242-3-git-send-email-alexandre.belloni@free-electrons.com>
References: <1371754675-12242-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1371754675-12242-3-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <1235070882.565234.1372771759233.open-xchange@email.1und1.de>

Hello Alexandre,

> The ADCs connected to this bus have been experiencing some timeout
> issues when using the iMX28 i2c controller. Switching back to bitbanging
> solves this.

the chip errata for i.MX23(!) contains an issue (no 2727) with the I2C
controller that is also applicable for the i.MX28:

"
2727 I2C 9th Clock Pulse (ACK) not generated when RETAIN_CLOCK set.

Description:
When RETAIN_CLOCK is set, the ninth clock pulse (ACK) is not generated. However,
the SDA
line is read at the proper timing interval. If RETAIN_CLOCK is cleared, the
ninth clock pulse is
generated.
Also, the HW_I2C_VERSION register incorrectly states the version is 1.2. It
should be 1.3.

Workaround:
HW_I2C_CTRL1[ACK_MODE] has default value of 0. It should be set to 1 to enable
the fix for
this issue.
"
?


Regards
Christoph Baumann


From jason at lakedaemon.net  Tue Jul  2 09:33:37 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 2 Jul 2013 09:33:37 -0400
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130702151407.01680d21@skate>
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net>
 <20130702151407.01680d21@skate>
Message-ID: <20130702133337.GA17110@titan.lakedaemon.net>

Thomas,

On Tue, Jul 02, 2013 at 03:14:07PM +0200, Thomas Petazzoni wrote:
> On Tue, 2 Jul 2013 08:46:39 -0400, Jason Cooper wrote:
> > > In the end, the main missing part is the NAND but I guess this is the
> > > same for all Aramda 370/XP boards and this is not a big issue as it is
> > > still possible to interact w/ it via u-boot and install a set of
> > > uImage/uInitramfs that way. 
> > 
> > What's the big blocker for this?  Once this is done, debian should be
> > able to add support for this board.  After all, upgrading the kernel and
> > initrd from userspace is a desirable option.
> 
> The big blocker is that no-one has written  the driver for it. It is
> still on our (Free Electrons) TODO-list, but not as a top-priority item
> for the moment.

Ok.

> Ezequiel had started to do some preliminary cleanup work on the
> pxa3xx-nand driver, with the ultimate goal of making it support Armada
> 370/XP (because the IP in the Armada 370/XP is apparently an evolution
> of the PXA3xx NAND controller), but our priorities shifted to those
> other topics. We will back on it some day, but I can't say when at the
> moment.

Is this under contract?  If so, I don't want to take it from you.  If it
isn't, perhaps Ezequiel and Arnaud could mind-meld?

thx,

Jason.


From jason at lakedaemon.net  Tue Jul  2 09:36:46 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 2 Jul 2013 09:36:46 -0400
Subject: [PATCH v5 5/7] ARM: kirkwood: convert to DT irqchip and
 clocksource
In-Reply-To: <1372770907-32738-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372763023-12374-6-git-send-email-sebastian.hesselbarth@gmail.com>
 <1372770907-32738-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130702133646.GB17110@titan.lakedaemon.net>

On Tue, Jul 02, 2013 at 03:15:07PM +0200, Sebastian Hesselbarth wrote:
> With recent support for true irqchip and clocksource drivers for Orion
> SoCs, now make use of it on DT enabled Kirkwood boards.
> 
> This also introduces a new Kconfig option for legacy (non-DT) Kirkwood
> where old code is moved out to and polishes DT board file a little bit.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> --- 
> Changelog:
> v4->v5:
> - do not re-introduce already removed init_dma_coherent_pool_size
>   (Reported by Jason Cooper)
> 
> @Jason: I did a 'git grep init_dma_coherent_pool_size' and now there
> are no users of that function - as it was before. Patch 6/7 only differs
> in the 'index' diff line because of the rebase here. I will not resend that,
> it should still apply.

ok, great, thanks for turning that around.

thx,

Jason.


From thomas.petazzoni at free-electrons.com  Tue Jul  2 09:38:25 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 2 Jul 2013 15:38:25 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130702133337.GA17110@titan.lakedaemon.net>
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net>
 <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
Message-ID: <20130702153825.139a93a5@skate>

Dear Jason Cooper,

On Tue, 2 Jul 2013 09:33:37 -0400, Jason Cooper wrote:

> > The big blocker is that no-one has written  the driver for it. It is
> > still on our (Free Electrons) TODO-list, but not as a top-priority item
> > for the moment.
> 
> Ok.
> 
> > Ezequiel had started to do some preliminary cleanup work on the
> > pxa3xx-nand driver, with the ultimate goal of making it support Armada
> > 370/XP (because the IP in the Armada 370/XP is apparently an evolution
> > of the PXA3xx NAND controller), but our priorities shifted to those
> > other topics. We will back on it some day, but I can't say when at the
> > moment.
> 
> Is this under contract?  If so, I don't want to take it from you.  If it
> isn't, perhaps Ezequiel and Arnaud could mind-meld?

The big problem is that the Armada 370 and Armada XP datasheets are
still only available under NDA, so it's quite hard for someone to step
up and do this, without access to those datasheets.

It used to be on our TODO-list, but isn't any longer, and I have no
informations about when it will re-appear on our TODO-list at this
point.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From jason at lakedaemon.net  Tue Jul  2 09:44:21 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 2 Jul 2013 09:44:21 -0400
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130702153825.139a93a5@skate>
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net>
 <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
Message-ID: <20130702134421.GC17110@titan.lakedaemon.net>

On Tue, Jul 02, 2013 at 03:38:25PM +0200, Thomas Petazzoni wrote:
> Dear Jason Cooper,
> 
> On Tue, 2 Jul 2013 09:33:37 -0400, Jason Cooper wrote:
> 
> > > The big blocker is that no-one has written  the driver for it. It is
> > > still on our (Free Electrons) TODO-list, but not as a top-priority item
> > > for the moment.
> > 
> > Ok.
> > 
> > > Ezequiel had started to do some preliminary cleanup work on the
> > > pxa3xx-nand driver, with the ultimate goal of making it support Armada
> > > 370/XP (because the IP in the Armada 370/XP is apparently an evolution
> > > of the PXA3xx NAND controller), but our priorities shifted to those
> > > other topics. We will back on it some day, but I can't say when at the
> > > moment.
> > 
> > Is this under contract?  If so, I don't want to take it from you.  If it
> > isn't, perhaps Ezequiel and Arnaud could mind-meld?
> 
> The big problem is that the Armada 370 and Armada XP datasheets are
> still only available under NDA, so it's quite hard for someone to step
> up and do this, without access to those datasheets.

bummer.

> It used to be on our TODO-list, but isn't any longer, and I have no
> informations about when it will re-appear on our TODO-list at this
> point.

So, Arnaud, how do you feel about tackling the nand driver based on the
sources you have and the pointers above?

thx,

Jason.


From sebastian.hesselbarth at gmail.com  Tue Jul  2 09:48:08 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue, 02 Jul 2013 15:48:08 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <87fvvzfh70.fsf@natisbad.org>
References: <87fvvzfh70.fsf@natisbad.org>
Message-ID: <51D2DA18.3020905@gmail.com>

On 06/30/13 22:59, Arnaud Ebalard wrote:
> Hi,
>
> Here is a .dts file for Armada-370-based Netgear ReadyNAS 102. The
> purpose of this submission is to get some feedback and also some
> directions on how to proceed to get it included at some point.
[...]
> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
> ---
>   arch/arm/boot/dts/Makefile                     |   1 +
>   arch/arm/boot/dts/armada-370-netgear-rn102.dts | 215 +++++++++++++++++++++++++
>   2 files changed, 216 insertions(+)
>   create mode 100644 arch/arm/boot/dts/armada-370-netgear-rn102.dts
>
[...]
> diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
> new file mode 100644
> index 0000000..5a9e129
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
> @@ -0,0 +1,215 @@
> +/*
> + * Device Tree file for NETGEAR ReadyNAS 102
> + *
> + * Copyright (C) 2013, Arnaud EBALARD <arno at natisbad.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +/dts-v1/;
> +
> +/include/ "armada-370.dtsi"
> +
> +/ {
> +	model = "NETGEAR ReadyNAS 102";
> +	compatible = "netgear,readynas-102", "marvell,armada370", "marvell,armada-370-xp";
> +
> +	chosen {
> +		bootargs = "console=ttyS0,115200 earlyprintk";
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x20000000>; /* 512 MB */
> +	};
> +
> +	soc {
> +		internal-regs {
> +			serial at 12000 {
> +				clock-frequency = <200000000>;
> +				status = "okay";
> +			};
> +
> +			sata at a0000 {
> +				nr-ports = <2>;
> +				status = "okay";
> +			};
> +
> +			pinctrl {
> +				power_led_pin: power-led-pin {
> +					marvell,pins = "mpp57";
> +					marvell,function = "gpio";
> +				};
> +				sata1_led_pin: sata1-led-pin {
> +					marvell,pins = "mpp15";
> +					marvell,function = "gpio";
> +				};
> +
> +				sata2_led_pin: sata2-led-pin {
> +					marvell,pins = "mpp14";
> +					marvell,function = "gpio";
> +				};
> +
> +				backup_led_pin: backup-led-pin {
> +					marvell,pins = "mpp56";
> +					marvell,function = "gpio";
> +				};
> +			};
> +
> +			gpio_leds {

Arnaud,

gpio_leds, gpio_keys, and clocks nodes shouldn't be children of
soc/internal-regs. I suggest to move them up as siblings of soc,
memory, and chosen instead.

> +				compatible = "gpio-leds";
> +				pinctrl-0 = < &power_led_pin
> +					      &sata1_led_pin
> +					      &sata2_led_pin
> +					      &backup_led_pin >;
> +				pinctrl-names = "default";
> +
> +				blue_power_led {
> +					label = "rn102:blue:pwr";
> +					gpios = <&gpio1 25 1>;  /* GPIO 57 Active Low */
> +					linux,default-trigger = "heartbeat";
> +				};
> +
> +				green_sata1_led {
> +					label = "rn102:green:sata1";
> +					gpios = <&gpio0 15 1>;  /* GPIO 15 Active Low */
> +					default-state = "on";
> +				};
> +
> +				green_sata2_led {
> +					label = "rn102:green:sata2";
> +					gpios = <&gpio0 14 1>;   /* GPIO 14 Active Low */
> +					default-state = "on";
> +				};
> +
> +				green_backup_led {
> +					label = "rn102:green:backup";
> +					gpios = <&gpio1 24 1>;   /* GPIO 56 Active Low */
> +					default-state = "on";
> +				};
> +			};
> +
> +			gpio_keys {
> +				compatible = "gpio-keys";
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				button at 1 {
> +					label = "Power Button";
> +					linux,code = <116>;     /* KEY_POWER */
> +					gpios = <&gpio1 30 1>;
> +				};
> +				button at 2 {
> +					label = "Reset Button";
> +					linux,code = <0x198>;   /* KEY_RESTART */
> +					gpios = <&gpio0 6 1>;
> +				};
> +				button at 3 {
> +					label = "Backup Button";
> +					linux,code = <133>;     /* KEY_COPY */
> +					gpios = <&gpio1 26 1>;
> +				};
> +			};
> +
> +			mdio {
> +				phy0: ethernet-phy at 0 {
> +					reg = <0>;
> +				};
> +			};
> +
> +			ethernet at 74000 {
> +				status = "okay";
> +				phy = <&phy0>;
> +				phy-mode = "rgmii-id";
> +			};
> +
> +			/* Waiting for NAND support to appear in armada-370.dtsi
> +
> +			nand at d0000 {
> +				status = "okay";
> +
> +				partition at 0 {
> +				   label = "u-boot";
> +				   reg = <0x0000000 0x180000>;
> +				   read-only;
> +				};
> +
> +				partition at 180000 {
> +				   label = "u-boot-env";
> +				   reg = <0x180000 0x20000>;
> +				};
> +
> +				partition at 200000 {
> +				   label = "uImage";
> +				   reg = <0x0200000 0x600000>;
> +				};
> +
> +				partition at 800000 {
> +				   label = "minirootfs";
> +				   reg = <0x0800000 0x400000>;
> +				};
> +
> +				partition at c00000 {
> +				   label = "ubi";
> +				   reg = <0x0c00000 0x7400000>;
> +				};
> +			};
> +
> +			*/
> +
> +			usb at 50000 {
> +				status = "okay";
> +			};
> +
> +			clocks {
> +			       #address-cells = <1>;
> +			       #size-cells = <0>;
> +
> +			       g762_clk: fixedclk {
> +					 compatible = "fixed-clock";
> +					 #clock-cells = <0>;
> +					 clock-frequency = <8192>;
> +			       };
> +			};
> +
> +			i2c at 11000 {
> +				compatible = "marvell,mv64xxx-i2c";
> +				clock-frequency = <100000>;
> +				status = "okay";
> +
> +				isl12057: isl12057 at 68 {
> +					compatible = "isil,isl12057";
> +					reg = <0x68>;
> +					wakeup-source;
> +				};
> +
> +				g762: g762 at 3e {
> +					compatible = "gmt,g762";
> +					reg = <0x3e>;
> +					clocks = <&g762_clk>; /* input clock */
> +					fan_gear_mode = <0>;
> +					fan_startv = <1>;
> +					pwm_polarity = <0>;
> +				};
> +			};
> +
> +			pcie-controller {
> +				status = "okay";
> +
> +				/* Connected to Marvell SATA controller */
> +				pcie at 1,0 {
> +					/* Port 0, Lane 0 */
> +					status = "okay";
> +				};
> +
> +				/* Connected to FL1009 USB 3.0 controller */
> +				pcie at 2,0 {
> +					/* Port 1, Lane 0 */
> +					status = "okay";
> +				};
> +			};
> +		};
> +	};
> +};
>



From w at 1wt.eu  Tue Jul  2 09:49:47 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Tue, 2 Jul 2013 15:49:47 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130702134421.GC17110@titan.lakedaemon.net>
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net> <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net> <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
Message-ID: <20130702134947.GC6740@1wt.eu>

On Tue, Jul 02, 2013 at 09:44:21AM -0400, Jason Cooper wrote:
> On Tue, Jul 02, 2013 at 03:38:25PM +0200, Thomas Petazzoni wrote:
> > Dear Jason Cooper,
> > 
> > On Tue, 2 Jul 2013 09:33:37 -0400, Jason Cooper wrote:
> > 
> > > > The big blocker is that no-one has written  the driver for it. It is
> > > > still on our (Free Electrons) TODO-list, but not as a top-priority item
> > > > for the moment.
> > > 
> > > Ok.
> > > 
> > > > Ezequiel had started to do some preliminary cleanup work on the
> > > > pxa3xx-nand driver, with the ultimate goal of making it support Armada
> > > > 370/XP (because the IP in the Armada 370/XP is apparently an evolution
> > > > of the PXA3xx NAND controller), but our priorities shifted to those
> > > > other topics. We will back on it some day, but I can't say when at the
> > > > moment.
> > > 
> > > Is this under contract?  If so, I don't want to take it from you.  If it
> > > isn't, perhaps Ezequiel and Arnaud could mind-meld?
> > 
> > The big problem is that the Armada 370 and Armada XP datasheets are
> > still only available under NDA, so it's quite hard for someone to step
> > up and do this, without access to those datasheets.
> 
> bummer.
> 
> > It used to be on our TODO-list, but isn't any longer, and I have no
> > informations about when it will re-appear on our TODO-list at this
> > point.
> 
> So, Arnaud, how do you feel about tackling the nand driver based on the
> sources you have and the pointers above?

BTW if that can help, I already have a working port of the driver that is
present in Marvell's kernel. The port is absolutely ugly, it's plain copy
paste of the HAL parts that I needed until it built and booted. It worked
on my mirabox with 3.8. I know it doesn't work since recently (I believe
since introduction of the mbus driver) though I haven't had time to check
why yet. The advantage of such an ugly work is that I'm sure that it will
never be merged into mainline :-)

Regards,
Willy



From festevam at gmail.com  Tue Jul  2 09:57:04 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 2 Jul 2013 10:57:04 -0300
Subject: [PATCHv2 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
In-Reply-To: <1235070882.565234.1372771759233.open-xchange@email.1und1.de>
References: <1371754675-12242-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1371754675-12242-3-git-send-email-alexandre.belloni@free-electrons.com>
 <1235070882.565234.1372771759233.open-xchange@email.1und1.de>
Message-ID: <CAOMZO5AASS4sr08i4K-uSUuvG+x9cjfFUtheY9JatA4dWCB0ww@mail.gmail.com>

Hi Christoph,

On Tue, Jul 2, 2013 at 10:29 AM, Christoph G. Baumann <cb at sgoc.de> wrote:
> Hello Alexandre,
>
>> The ADCs connected to this bus have been experiencing some timeout
>> issues when using the iMX28 i2c controller. Switching back to bitbanging
>> solves this.
>
> the chip errata for i.MX23(!) contains an issue (no 2727) with the I2C
> controller that is also applicable for the i.MX28:
>
> "
> 2727 I2C 9th Clock Pulse (ACK) not generated when RETAIN_CLOCK set.
>
> Description:
> When RETAIN_CLOCK is set, the ninth clock pulse (ACK) is not generated. However,
> the SDA
> line is read at the proper timing interval. If RETAIN_CLOCK is cleared, the
> ninth clock pulse is
> generated.
> Also, the HW_I2C_VERSION register incorrectly states the version is 1.2. It
> should be 1.3.
>
> Workaround:
> HW_I2C_CTRL1[ACK_MODE] has default value of 0. It should be set to 1 to enable
> the fix for
> this issue.

Differently than mx23, the mx28 reference manual states that ACK_MODE
bit has a default value of 1.

Thanks for pointing this out, as we need to take this into
consideration for supporting mx23 in the mxs i2c driver.

Regards,

Fabio Estevam


From alexandre.belloni at free-electrons.com  Tue Jul  2 10:06:19 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Tue, 02 Jul 2013 16:06:19 +0200
Subject: [PATCHv3 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
In-Reply-To: <51D2BEA1.6010206@free-electrons.com>
References: <1372094699-3832-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1372094699-3832-3-git-send-email-alexandre.belloni@free-electrons.com>
 <CAOMZO5CLcT=OXYd=ggxpDzUqFxoXSaanqUPGugYLT2Og-VgzCA@mail.gmail.com>
 <51D2BB05.9040201@free-electrons.com>
 <CAOMZO5DZufiOjguOCEbe5n0j=w9B5ezBYh0Rejv3zF5Xht5_qQ@mail.gmail.com>
 <51D2BEA1.6010206@free-electrons.com>
Message-ID: <51D2DE5B.9060309@free-electrons.com>

On 02/07/2013 13:50, Alexandre Belloni wrote:
> On 02/07/2013 13:45, Fabio Estevam wrote:
> 
>> Shouldn't this be
>>
>>          i2c at 1 {
>>                  reg = <1>; ?
>>
> 
> No, we have 4 devices on that mux and 2 pins to select the muxing.
> 

OK, got it working.

So, the results:

bitbanging:

# time cat /sys/bus/iio/devices/iio\:device1/in_voltage0_raw
2637
real	0m 0.09s
user	0m 0.01s
sys	0m 0.01s


i2c-mxs PIO mode:

# time cat /sys/bus/iio/devices/iio\:device1/in_voltage0_raw
[   35.007650] [sched_delayed] sched: RT throttling activated
2627
real	0m 7.14s
user	0m 0.02s
sys	0m 0.01s


i2c-mxs PIO mode without LRADC:

# time cat /sys/bus/iio/devices/iio\:device1/in_voltage0_raw
[   18.007432] [sched_delayed] sched: RT throttling activated
2629
real	0m 7.09s
user	0m 0.00s
sys	0m 0.03s


i2c-mxs DMA mode:

# time cat /sys/bus/iio/devices/iio\:device1/in_voltage0_raw
2631
real	0m 0.12s
user	0m 0.01s
sys	0m 0.01s


It seems fine for me.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From cb at sgoc.de  Tue Jul  2 10:09:17 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Tue, 2 Jul 2013 16:09:17 +0200 (CEST)
Subject: [PATCHv2 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
In-Reply-To: <CAOMZO5AASS4sr08i4K-uSUuvG+x9cjfFUtheY9JatA4dWCB0ww@mail.gmail.com>
References: <1371754675-12242-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1371754675-12242-3-git-send-email-alexandre.belloni@free-electrons.com>
 <1235070882.565234.1372771759233.open-xchange@email.1und1.de>
 <CAOMZO5AASS4sr08i4K-uSUuvG+x9cjfFUtheY9JatA4dWCB0ww@mail.gmail.com>
Message-ID: <489238046.567779.1372774157223.open-xchange@email.1und1.de>

Hi Fabio,

>
> Differently than mx23, the mx28 reference manual states that ACK_MODE
> bit has a default value of 1.
>
> Thanks for pointing this out, as we need to take this into
> consideration for supporting mx23 in the mxs i2c driver.
>

nevertheless the mx28 I2C controller seems to suffer from this error too, as
SMbus doesn't work with it.



Regards
Christoph


From nm at ti.com  Tue Jul  2 10:15:50 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 2 Jul 2013 09:15:50 -0500
Subject: OMAP baseline test results for v3.10-rc6
In-Reply-To: <79CD15C6BA57404B839C016229A409A83ECCC435@DBDE04.ent.ti.com>
References: <alpine.DEB.2.02.1306170521020.9909@utopia.booyaka.com>
 <20130625160243.GE22312@arwen.pp.htv.fi>
 <alpine.DEB.2.02.1306251746060.14373@utopia.booyaka.com>
 <51C9F0A8.1050607@ti.com> <87fvw6t136.fsf@linaro.org>
 <79CD15C6BA57404B839C016229A409A83ECC952D@DBDE04.ent.ti.com>
 <51CAEB33.5010101@ti.com>
 <alpine.DEB.2.02.1306261722520.6135@utopia.booyaka.com>
 <51CBBCD8.5030600@ti.com>
 <alpine.DEB.2.02.1306281844090.8767@utopia.booyaka.com>
 <alpine.DEB.2.02.1307010211580.3741@utopia.booyaka.com>
 <79CD15C6BA57404B839C016229A409A83ECCC435@DBDE04.ent.ti.com>
Message-ID: <51D2E096.5040700@ti.com>

On 07/01/2013 11:29 PM, Hiremath, Vaibhav wrote:
>
>> -----Original Message-----
>> From: Paul Walmsley [mailto:paul at pwsan.com]
>> Sent: Monday, July 01, 2013 7:46 AM
>> To: Vutla, Lokesh
>> Cc: Nayak, Rajendra; Hiremath, Vaibhav; Kevin Hilman; Rini, Tom; linux-
>> omap at vger.kernel.org; Balbi, Felipe; linux-arm-
>> kernel at lists.infradead.org
>> Subject: Re: OMAP baseline test results for v3.10-rc6
>>
>> On Fri, 28 Jun 2013, Paul Walmsley wrote:
>>
>>> On Thu, 27 Jun 2013, Lokesh Vutla wrote:
>>>
>>>> Here is the catch..
>>>> Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb
>> was
>>>> generated in arch/arm/boot).
>>>
>>> Ugh... that's probably it :-(
to prevent this from happening again, Lokesh did post a patch:
https://patchwork.kernel.org/patch/2796921/

Will be good to ack it if we think it might prevent such scenarios in 
the future.

-- 
Regards,
Nishanth Menon


From jason at lakedaemon.net  Tue Jul  2 10:24:16 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 2 Jul 2013 10:24:16 -0400
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130702134947.GC6740@1wt.eu>
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net>
 <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
 <20130702134947.GC6740@1wt.eu>
Message-ID: <20130702142416.GD17110@titan.lakedaemon.net>

On Tue, Jul 02, 2013 at 03:49:47PM +0200, Willy Tarreau wrote:
> On Tue, Jul 02, 2013 at 09:44:21AM -0400, Jason Cooper wrote:
> > On Tue, Jul 02, 2013 at 03:38:25PM +0200, Thomas Petazzoni wrote:
> > > Dear Jason Cooper,
> > > 
> > > On Tue, 2 Jul 2013 09:33:37 -0400, Jason Cooper wrote:
> > > 
> > > > > The big blocker is that no-one has written  the driver for it. It is
> > > > > still on our (Free Electrons) TODO-list, but not as a top-priority item
> > > > > for the moment.
> > > > 
> > > > Ok.
> > > > 
> > > > > Ezequiel had started to do some preliminary cleanup work on the
> > > > > pxa3xx-nand driver, with the ultimate goal of making it support Armada
> > > > > 370/XP (because the IP in the Armada 370/XP is apparently an evolution
> > > > > of the PXA3xx NAND controller), but our priorities shifted to those
> > > > > other topics. We will back on it some day, but I can't say when at the
> > > > > moment.
> > > > 
> > > > Is this under contract?  If so, I don't want to take it from you.  If it
> > > > isn't, perhaps Ezequiel and Arnaud could mind-meld?
> > > 
> > > The big problem is that the Armada 370 and Armada XP datasheets are
> > > still only available under NDA, so it's quite hard for someone to step
> > > up and do this, without access to those datasheets.
> > 
> > bummer.
> > 
> > > It used to be on our TODO-list, but isn't any longer, and I have no
> > > informations about when it will re-appear on our TODO-list at this
> > > point.
> > 
> > So, Arnaud, how do you feel about tackling the nand driver based on the
> > sources you have and the pointers above?
> 
> BTW if that can help, I already have a working port of the driver that is
> present in Marvell's kernel. The port is absolutely ugly, it's plain copy
> paste of the HAL parts that I needed until it built and booted. It worked
> on my mirabox with 3.8. I know it doesn't work since recently (I believe
> since introduction of the mbus driver) though I haven't had time to check
> why yet. The advantage of such an ugly work is that I'm sure that it will
> never be merged into mainline :-)

Could you post a branch somewhere for us to look at?  Or, just post it
RFC in all it's ugly glory :)  Hopefully, there's enough hints in there
to give us a good idea of what needs changed in pxa33xx-nand.

thx,

Jason.
> 
> Regards,
> Willy
> 


From dsd at laptop.org  Tue Jul  2 10:26:22 2013
From: dsd at laptop.org (Daniel Drake)
Date: Tue, 2 Jul 2013 08:26:22 -0600
Subject: [GIT PULL] Initial OLPC XO-1.75/XO-4 support
In-Reply-To: <20130702045304.GA27829@quad.lixom.net>
References: <20130702031244.B2D74FAAD2@dev.laptop.org>
 <20130702045304.GA27829@quad.lixom.net>
Message-ID: <CAMLZHHQu_UUQvT1db7hL2XYX=EzwNaGjyeTuZkwfYHJmG5BUdA@mail.gmail.com>

On Mon, Jul 1, 2013 at 10:53 PM, Olof Johansson <olof at lixom.net> wrote:
> 1) Please post the drivers/clk patches to mturquette. THey don't look dependent
>    on the rest of the patches, just general improvements and cleanups.
> 2) I really wish there was a generic catch-all compat for the boards, so we
>    didn't have to modify mmp2-dt.c for every new board added -- it really
>    defies the purpose of only changing the data you pass into the kernel. This
>    is mostly something for Eric/Haojian to sort out though.
> 3) Please post the patches as a series instead of a pull request, given that
>    they should probably take different paths up the tree (clk vs the platform,
>    etc). You should at least get review/acked-by of the clk pieces from Mike
>    Turquette.

Thanks for the suggestions. I have already posted the patches as
emails a little more than 2 weeks ago, including sending the clock
ones to Mike. I will resend next week if they are still pending, when
the maintainers might be a bit less busy.

cheers
Daniel


From sergei.shtylyov at cogentembedded.com  Tue Jul  2 10:50:08 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 02 Jul 2013 18:50:08 +0400
Subject: [PATCH] USB: OHCI: make ohci-da8xx a separate driver
In-Reply-To: <1372765019-7191-1-git-send-email-manjunath.goudar@linaro.org>
References: <1372765019-7191-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <51D2E8A0.1080102@cogentembedded.com>

Hello.

On 02-07-2013 15:36, Manjunath Goudar wrote:

> Separate the Davinci OHCI host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.11.

> One preexisting error:
> "da8xx_syscfg0_base" [drivers/usb/host/ohci-da8xx.ko] undefined!

> Fixed eventually using below modification:
> added EXPORT_SYMBOL_GPL(da8xx_syscfg0_base) in
> arch/arm/mach-davinci/devices-da8xx.c.

    And you managed to get this fix into the DaVinci tree? I tried it 
long ago and it was refused by then DaVinci maintainer Kevin Hilman.

> Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Sergei Shtylyov <sshtylyov at ru.mvista.com>
> Cc: Kevin Hilman <kjh at hilman.org>
> Cc: Greg KH <greg at kroah.com>
> Cc: linux-usb at vger.kernel.org
> ---
>   drivers/usb/host/Kconfig      |    8 +++
>   drivers/usb/host/Makefile     |    1 +
>   drivers/usb/host/ohci-da8xx.c |  139 +++++++++++++++++++----------------------
>   drivers/usb/host/ohci-hcd.c   |   18 ------
>   4 files changed, 75 insertions(+), 91 deletions(-)

> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 002bf73..bf2689d 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -406,6 +406,14 @@ config USB_OHCI_HCD_LPC32XX
>             Enables support for the on-chip OHCI controller on
>             NXP chips.
>
> +config USB_OHCI_HCD_DA8XX
> +	tristate "Support for DAVINCI on-chip OHCI USB controller"
> +	depends on USB_OHCI_HCD && ARCH_DAVINCI_DA8XX
> +	default y
> +	---help---
> +          Enables support for the on-chip OHCI controller on
> +          Davinci chips.

    DA8xx is not a real DaVinci chip. The real DaVincis don't have OHCI 
at all. Please replace "Davinci" with "DA8xx/OMAP-L1x" in both the 
prompt and help text.

> diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
> index c649a35..9b4d1e4 100644
> --- a/drivers/usb/host/ohci-da8xx.c
> +++ b/drivers/usb/host/ohci-da8xx.c
> @@ -11,20 +11,35 @@
p...]
> +#define DRIVER_DESC "OHCI DA8XX driver"

    Better "DA8xx".

[...]
> @@ -444,6 +397,11 @@ static int ohci_da8xx_resume(struct platform_device *dev)
>   }
>   #endif
>
> +static const struct ohci_driver_overrides da8xx_overrides __initconst = {
> +	.reset		= ohci_da8xx_reset

    Better terminate the line with comma.

> +};
> +
> +

    Too many blank lines?

> @@ -461,4 +419,39 @@ static struct platform_driver ohci_hcd_da8xx_driver = {
>   	},
>   };
>
> +static int __init ohci_da8xx_init(void)
> +{
> +	if (usb_disabled())
> +		return -ENODEV;
> +
> +	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
> +	ohci_init_driver(&ohci_da8xx_hc_driver, &da8xx_overrides);
> +
> +	/*
> +	 * The Davinci da8xx HW has some unusual quirks, which require
> +	 * da8xx-specific workarounds. We override certain hc_driver
> +	 * functions here to achieve that. We explicitly do not enhance
> +	 * ohci_driver_overrides to allow this more easily, since this
> +	 * is an unusual case, and we don't want to encourage others to

    Not as unusual as it seems. IIRC Samsung OHCI has the same quirks.

WBR, Sergei



From coelho at ti.com  Tue Jul  2 10:55:39 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 17:55:39 +0300
Subject: [PATCH v2 0/9] wilink: add device tree support
Message-ID: <1372776948-24840-1-git-send-email-coelho@ti.com>

Hi,

This is a follow-up on a previous patch set that had a smaller
audience.  This time, I added the lists and people who were involved
in the review of the bindings documentation, since most of my changes
in v2 are coming from discussions there.

This patch series adds device tree support to the wlcore_sdio driver,
which is used by WiLink6, WiLink7 and WiLink8.

The first patches do some clean-up to make the data needed in the
wilink device tree node smaller.  The remaining patches implement the
actual device tree node parsing in wlcore_sdio.

I still need to figure out how to add the information about whether
the clocks are XTAL or not.  I'll send it in a separate patche set.

The DTS file changes will be sent separately, since they need to go
via different trees.

The bindings documentation patch will also be updated and sent
separately, once the XTAL issue is solved.

Tony has acked some of the patches that touch OMAP areas.  I still
need one more ack to a new patch I added (wl12xx: use frequency
instead of enumerations for pdata clocks).

Sekhar, can you please check the patches that touch the davinci board
file and ack them?

Changes in v2:

* New clean-up patch (4/9);

* Patch 6/9 (previously patch 5/5) now doesn't add the clock parsing,
  since it became more complicated and I added separate patches for
  that;

* 3 new patches (from 7/9 till 9/9) to handle the clock reading in the
  device tree;

Please review.

--
Cheers,
Luca.

Luciano Coelho (9):
  wl1251: split wl251 platform data to a separate structure
  wlcore: use irq_flags in pdata instead of hiding it behind a quirk
  wlcore: remove pwr_in_suspend from platform data
  wl12xx: use frequency instead of enumerations for pdata clocks
  wlcore: always use one-shot IRQ
  wlcore: add initial device tree support to the sdio module
  wlcore: sdio: add wilink clock providers
  wlcore: sdio: get clocks from device tree
  wlcore/wl12xx: check if we got correct clock data from DT

 arch/arm/mach-davinci/board-da850-evm.c        |    5 +-
 arch/arm/mach-omap2/board-4430sdp.c            |    6 +-
 arch/arm/mach-omap2/board-omap3evm.c           |    4 +-
 arch/arm/mach-omap2/board-omap3pandora.c       |    4 +-
 arch/arm/mach-omap2/board-omap4panda.c         |    4 +-
 arch/arm/mach-omap2/board-rx51-peripherals.c   |    2 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c   |    4 +-
 drivers/net/wireless/ti/wilink_platform_data.c |   37 ++++++--
 drivers/net/wireless/ti/wl1251/sdio.c          |   12 +--
 drivers/net/wireless/ti/wl1251/spi.c           |    2 +-
 drivers/net/wireless/ti/wl12xx/main.c          |   78 +++++++++++++++--
 drivers/net/wireless/ti/wl12xx/wl12xx.h        |   28 ++++++
 drivers/net/wireless/ti/wlcore/debugfs.c       |    2 +-
 drivers/net/wireless/ti/wlcore/main.c          |   16 ++--
 drivers/net/wireless/ti/wlcore/sdio.c          |  112 ++++++++++++++++++++++--
 drivers/net/wireless/ti/wlcore/wlcore.h        |    5 +-
 drivers/net/wireless/ti/wlcore/wlcore_i.h      |    1 +
 include/linux/wl12xx.h                         |   54 ++++++------
 18 files changed, 295 insertions(+), 81 deletions(-)

-- 
1.7.10.4



From coelho at ti.com  Tue Jul  2 10:55:42 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 17:55:42 +0300
Subject: [PATCH v2 3/9] wlcore: remove pwr_in_suspend from platform data
In-Reply-To: <1372776948-24840-1-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
Message-ID: <1372776948-24840-4-git-send-email-coelho@ti.com>

The pwr_in_suspend flag depends on the MMC settings which can be
retrieved from the SDIO subsystem, so it doesn't need to be part of
the platform data structure.  Move it to the platform device data that
is passed from SDIO to wlcore.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 drivers/net/wireless/ti/wlcore/main.c     |    2 +-
 drivers/net/wireless/ti/wlcore/sdio.c     |    2 +-
 drivers/net/wireless/ti/wlcore/wlcore_i.h |    1 +
 include/linux/wl12xx.h                    |    1 -
 4 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index e7294b8..d306cd5 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5941,7 +5941,7 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
 	if (!ret) {
 		wl->irq_wake_enabled = true;
 		device_init_wakeup(wl->dev, 1);
-		if (pdata->pwr_in_suspend)
+		if (pdev_data->pwr_in_suspend)
 			wl->hw->wiphy->wowlan = &wlcore_wowlan_support;
 	}
 #endif
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 29ef249..4c7e8ac 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -260,7 +260,7 @@ static int wl1271_probe(struct sdio_func *func,
 	dev_dbg(glue->dev, "sdio PM caps = 0x%x\n", mmcflags);
 
 	if (mmcflags & MMC_PM_KEEP_POWER)
-		pdev_data->pdata->pwr_in_suspend = true;
+		pdev_data->pwr_in_suspend = true;
 
 	sdio_set_drvdata(func, glue);
 
diff --git a/drivers/net/wireless/ti/wlcore/wlcore_i.h b/drivers/net/wireless/ti/wlcore/wlcore_i.h
index e5e1464..f2c4227 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore_i.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore_i.h
@@ -209,6 +209,7 @@ struct wl1271_if_operations {
 struct wlcore_platdev_data {
 	struct wl12xx_platform_data *pdata;
 	struct wl1271_if_operations *if_ops;
+	bool pwr_in_suspend;
 };
 
 #define MAX_NUM_KEYS 14
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 04e3096..1e4ed6e 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -60,7 +60,6 @@ struct wl12xx_platform_data {
 	unsigned long irq_flags;
 	int board_ref_clock;
 	int board_tcxo_clock;
-	bool pwr_in_suspend;
 };
 
 #ifdef CONFIG_WILINK_PLATFORM_DATA
-- 
1.7.10.4



From coelho at ti.com  Tue Jul  2 10:55:40 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 17:55:40 +0300
Subject: [PATCH v2 1/9] wl1251: split wl251 platform data to a separate
 structure
In-Reply-To: <1372776948-24840-1-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
Message-ID: <1372776948-24840-2-git-send-email-coelho@ti.com>

Move the wl1251 part of the wl12xx platform data structure into a new
structure specifically for wl1251.  Change the platform data built-in
block and board files accordingly.

Cc: Tony Lindgren <tony at atomide.com>
Signed-off-by: Luciano Coelho <coelho at ti.com>
Acked-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/mach-omap2/board-omap3pandora.c       |    4 +--
 arch/arm/mach-omap2/board-rx51-peripherals.c   |    2 +-
 drivers/net/wireless/ti/wilink_platform_data.c |   37 ++++++++++++++++++++----
 drivers/net/wireless/ti/wl1251/sdio.c          |   12 ++++----
 drivers/net/wireless/ti/wl1251/spi.c           |    2 +-
 include/linux/wl12xx.h                         |   22 +++++++++++++-
 6 files changed, 62 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index 28133d5..bf06d95 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -540,7 +540,7 @@ static struct spi_board_info omap3pandora_spi_board_info[] __initdata = {
 
 static void __init pandora_wl1251_init(void)
 {
-	struct wl12xx_platform_data pandora_wl1251_pdata;
+	struct wl1251_platform_data pandora_wl1251_pdata;
 	int ret;
 
 	memset(&pandora_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
@@ -554,7 +554,7 @@ static void __init pandora_wl1251_init(void)
 		goto fail_irq;
 
 	pandora_wl1251_pdata.use_eeprom = true;
-	ret = wl12xx_set_platform_data(&pandora_wl1251_pdata);
+	ret = wl1251_set_platform_data(&pandora_wl1251_pdata);
 	if (ret < 0)
 		goto fail_irq;
 
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 18ca61e..733f3f2 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -80,7 +80,7 @@ enum {
 	RX51_SPI_MIPID,		/* LCD panel */
 };
 
-static struct wl12xx_platform_data wl1251_pdata;
+static struct wl1251_platform_data wl1251_pdata;
 static struct tsc2005_platform_data tsc2005_pdata;
 
 #if defined(CONFIG_SENSORS_LIS3_I2C) || defined(CONFIG_SENSORS_LIS3_I2C_MODULE)
diff --git a/drivers/net/wireless/ti/wilink_platform_data.c b/drivers/net/wireless/ti/wilink_platform_data.c
index 998e958..a92bd3e 100644
--- a/drivers/net/wireless/ti/wilink_platform_data.c
+++ b/drivers/net/wireless/ti/wilink_platform_data.c
@@ -23,17 +23,17 @@
 #include <linux/err.h>
 #include <linux/wl12xx.h>
 
-static struct wl12xx_platform_data *platform_data;
+static struct wl12xx_platform_data *wl12xx_platform_data;
 
 int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
 {
-	if (platform_data)
+	if (wl12xx_platform_data)
 		return -EBUSY;
 	if (!data)
 		return -EINVAL;
 
-	platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
-	if (!platform_data)
+	wl12xx_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+	if (!wl12xx_platform_data)
 		return -ENOMEM;
 
 	return 0;
@@ -41,9 +41,34 @@ int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
 
 struct wl12xx_platform_data *wl12xx_get_platform_data(void)
 {
-	if (!platform_data)
+	if (!wl12xx_platform_data)
 		return ERR_PTR(-ENODEV);
 
-	return platform_data;
+	return wl12xx_platform_data;
 }
 EXPORT_SYMBOL(wl12xx_get_platform_data);
+
+static struct wl1251_platform_data *wl1251_platform_data;
+
+int __init wl1251_set_platform_data(const struct wl1251_platform_data *data)
+{
+	if (wl1251_platform_data)
+		return -EBUSY;
+	if (!data)
+		return -EINVAL;
+
+	wl1251_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+	if (!wl1251_platform_data)
+		return -ENOMEM;
+
+	return 0;
+}
+
+struct wl1251_platform_data *wl1251_get_platform_data(void)
+{
+	if (!wl1251_platform_data)
+		return ERR_PTR(-ENODEV);
+
+	return wl1251_platform_data;
+}
+EXPORT_SYMBOL(wl1251_get_platform_data);
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c b/drivers/net/wireless/ti/wl1251/sdio.c
index e2b3d9c..b75a37a 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -227,7 +227,7 @@ static int wl1251_sdio_probe(struct sdio_func *func,
 	struct wl1251 *wl;
 	struct ieee80211_hw *hw;
 	struct wl1251_sdio *wl_sdio;
-	const struct wl12xx_platform_data *wl12xx_board_data;
+	const struct wl1251_platform_data *wl1251_board_data;
 
 	hw = wl1251_alloc_hw();
 	if (IS_ERR(hw))
@@ -254,11 +254,11 @@ static int wl1251_sdio_probe(struct sdio_func *func,
 	wl->if_priv = wl_sdio;
 	wl->if_ops = &wl1251_sdio_ops;
 
-	wl12xx_board_data = wl12xx_get_platform_data();
-	if (!IS_ERR(wl12xx_board_data)) {
-		wl->set_power = wl12xx_board_data->set_power;
-		wl->irq = wl12xx_board_data->irq;
-		wl->use_eeprom = wl12xx_board_data->use_eeprom;
+	wl1251_board_data = wl1251_get_platform_data();
+	if (!IS_ERR(wl1251_board_data)) {
+		wl->set_power = wl1251_board_data->set_power;
+		wl->irq = wl1251_board_data->irq;
+		wl->use_eeprom = wl1251_board_data->use_eeprom;
 	}
 
 	if (wl->irq) {
diff --git a/drivers/net/wireless/ti/wl1251/spi.c b/drivers/net/wireless/ti/wl1251/spi.c
index c7dc6fe..6bbbfe6 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -238,7 +238,7 @@ static const struct wl1251_if_operations wl1251_spi_ops = {
 
 static int wl1251_spi_probe(struct spi_device *spi)
 {
-	struct wl12xx_platform_data *pdata;
+	struct wl1251_platform_data *pdata;
 	struct ieee80211_hw *hw;
 	struct wl1251 *wl;
 	int ret;
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index a54fe82..b516b4f 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -48,11 +48,15 @@ enum {
 	WL12XX_TCXOCLOCK_33_6	= 7, /* 33.6 MHz */
 };
 
-struct wl12xx_platform_data {
+struct wl1251_platform_data {
 	void (*set_power)(bool enable);
 	/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
 	int irq;
 	bool use_eeprom;
+};
+
+struct wl12xx_platform_data {
+	int irq;
 	int board_ref_clock;
 	int board_tcxo_clock;
 	unsigned long platform_quirks;
@@ -68,6 +72,10 @@ int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
 
 struct wl12xx_platform_data *wl12xx_get_platform_data(void);
 
+int wl1251_set_platform_data(const struct wl1251_platform_data *data);
+
+struct wl1251_platform_data *wl1251_get_platform_data(void);
+
 #else
 
 static inline
@@ -82,6 +90,18 @@ struct wl12xx_platform_data *wl12xx_get_platform_data(void)
 	return ERR_PTR(-ENODATA);
 }
 
+static inline
+int wl1251_set_platform_data(const struct wl1251_platform_data *data)
+{
+	return -ENOSYS;
+}
+
+static inline
+struct wl1251_platform_data *wl1251_get_platform_data(void)
+{
+	return ERR_PTR(-ENODATA);
+}
+
 #endif
 
 #endif
-- 
1.7.10.4



From coelho at ti.com  Tue Jul  2 10:55:41 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 17:55:41 +0300
Subject: [PATCH v2 2/9] wlcore: use irq_flags in pdata instead of hiding it
 behind a quirk
In-Reply-To: <1372776948-24840-1-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
Message-ID: <1372776948-24840-3-git-send-email-coelho@ti.com>

The platform_quirk element in the platform data was used to change the
way the IRQ is triggered.  When set, the EDGE_IRQ quirk would change
the irqflags used and treat edge trigger differently from the rest.

Instead of hiding this irq flag setting behind the quirk, export the
whole irq_flags element and let the board file define what to use.
This will be more meaningful than driver-specific quirks when we
switch to DT.

Cc: Tony Lindgren <tony at atomide.com>
Cc: Sekhar Nori <nsekhar at ti.com>
Signed-off-by: Luciano Coelho <coelho at ti.com>
Acked-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/mach-davinci/board-da850-evm.c      |    2 +-
 arch/arm/mach-omap2/board-4430sdp.c          |    1 +
 arch/arm/mach-omap2/board-omap3evm.c         |    1 +
 arch/arm/mach-omap2/board-omap4panda.c       |    1 +
 arch/arm/mach-omap2/board-zoom-peripherals.c |    1 +
 drivers/net/wireless/ti/wlcore/debugfs.c     |    2 +-
 drivers/net/wireless/ti/wlcore/main.c        |   13 +++----------
 drivers/net/wireless/ti/wlcore/wlcore.h      |    5 ++---
 include/linux/wl12xx.h                       |    5 +----
 9 files changed, 12 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 8a24b6c..d2a2a98 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1377,8 +1377,8 @@ static const short da850_wl12xx_pins[] __initconst = {
 
 static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
 	.irq			= -1,
+	.irq_flags		= IRQF_TRIGGER_RISING,
 	.board_ref_clock	= WL12XX_REFCLOCK_38,
-	.platform_quirks	= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
 };
 
 static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 56a9a4f..c2334aa 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -693,6 +693,7 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
 }
 
 static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
+	.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
 	.board_ref_clock = WL12XX_REFCLOCK_26,
 	.board_tcxo_clock = WL12XX_TCXOCLOCK_26,
 };
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index f76d0de..a0c0adf 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -458,6 +458,7 @@ static struct platform_device omap3evm_wlan_regulator = {
 };
 
 struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
+	.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
 	.board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
 };
 #endif
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 1e2c75e..ba00862 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -230,6 +230,7 @@ static struct platform_device omap_vwlan_device = {
 };
 
 static struct wl12xx_platform_data omap_panda_wlan_data  __initdata = {
+	.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
 	.board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
 };
 
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
index a90375d..ced012c 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -244,6 +244,7 @@ static struct platform_device *zoom_devices[] __initdata = {
 };
 
 static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
+	.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
 	.board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz */
 };
 
diff --git a/drivers/net/wireless/ti/wlcore/debugfs.c b/drivers/net/wireless/ti/wlcore/debugfs.c
index c3e1f79..5eff663 100644
--- a/drivers/net/wireless/ti/wlcore/debugfs.c
+++ b/drivers/net/wireless/ti/wlcore/debugfs.c
@@ -486,7 +486,7 @@ static ssize_t driver_state_read(struct file *file, char __user *user_buf,
 	DRIVER_STATE_PRINT_HEX(irq);
 	/* TODO: ref_clock and tcxo_clock were moved to wl12xx priv */
 	DRIVER_STATE_PRINT_HEX(hw_pg_ver);
-	DRIVER_STATE_PRINT_HEX(platform_quirks);
+	DRIVER_STATE_PRINT_HEX(irq_flags);
 	DRIVER_STATE_PRINT_HEX(chip.id);
 	DRIVER_STATE_PRINT_STR(chip.fw_ver_str);
 	DRIVER_STATE_PRINT_STR(chip.phy_fw_ver_str);
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index b8db55c..e7294b8 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -516,7 +516,7 @@ static int wlcore_irq_locked(struct wl1271 *wl)
 	 * In case edge triggered interrupt must be used, we cannot iterate
 	 * more than once without introducing race conditions with the hardirq.
 	 */
-	if (wl->platform_quirks & WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
+	if (wl->irq_flags & IRQF_TRIGGER_RISING)
 		loopcount = 1;
 
 	wl1271_debug(DEBUG_IRQ, "IRQ work");
@@ -5765,7 +5765,6 @@ struct ieee80211_hw *wlcore_alloc_hw(size_t priv_size, u32 aggr_buf_size,
 	wl->ap_ps_map = 0;
 	wl->ap_fw_ps_map = 0;
 	wl->quirks = 0;
-	wl->platform_quirks = 0;
 	wl->system_hlid = WL12XX_SYSTEM_HLID;
 	wl->active_sta_count = 0;
 	wl->active_link_count = 0;
@@ -5901,7 +5900,6 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
 	struct platform_device *pdev = wl->pdev;
 	struct wlcore_platdev_data *pdev_data = pdev->dev.platform_data;
 	struct wl12xx_platform_data *pdata = pdev_data->pdata;
-	unsigned long irqflags;
 	int ret;
 
 	if (fw) {
@@ -5928,16 +5926,11 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
 	wlcore_adjust_conf(wl);
 
 	wl->irq = platform_get_irq(pdev, 0);
-	wl->platform_quirks = pdata->platform_quirks;
 	wl->if_ops = pdev_data->if_ops;
-
-	if (wl->platform_quirks & WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
-		irqflags = IRQF_TRIGGER_RISING;
-	else
-		irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
+	wl->irq_flags = pdata->irq_flags;
 
 	ret = request_threaded_irq(wl->irq, NULL, wlcore_irq,
-				   irqflags, pdev->name, wl);
+				   wl->irq_flags, pdev->name, wl);
 	if (ret < 0) {
 		wl1271_error("request_irq() failed: %d", ret);
 		goto out_free_nvs;
diff --git a/drivers/net/wireless/ti/wlcore/wlcore.h b/drivers/net/wireless/ti/wlcore/wlcore.h
index 0034979..8306bde 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore.h
@@ -185,6 +185,8 @@ struct wl1271 {
 
 	int irq;
 
+	int irq_flags;
+
 	spinlock_t wl_lock;
 
 	enum wlcore_state state;
@@ -384,9 +386,6 @@ struct wl1271 {
 	/* Quirks of specific hardware revisions */
 	unsigned int quirks;
 
-	/* Platform limitations */
-	unsigned int platform_quirks;
-
 	/* number of currently active RX BA sessions */
 	int ba_rx_session_count;
 
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index b516b4f..04e3096 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -57,15 +57,12 @@ struct wl1251_platform_data {
 
 struct wl12xx_platform_data {
 	int irq;
+	unsigned long irq_flags;
 	int board_ref_clock;
 	int board_tcxo_clock;
-	unsigned long platform_quirks;
 	bool pwr_in_suspend;
 };
 
-/* Platform does not support level trigger interrupts */
-#define WL12XX_PLATFORM_QUIRK_EDGE_IRQ	BIT(0)
-
 #ifdef CONFIG_WILINK_PLATFORM_DATA
 
 int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
-- 
1.7.10.4



From coelho at ti.com  Tue Jul  2 10:55:43 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 17:55:43 +0300
Subject: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for
 pdata clocks
In-Reply-To: <1372776948-24840-1-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
Message-ID: <1372776948-24840-5-git-send-email-coelho@ti.com>

Instead of defining an enumeration with the FW specific values for the
different clock rates, use the actual frequency instead.  Also add a
boolean to specify whether the clock is XTAL or not.

Change all board files to reflect this.

Cc: Tony Lindgren <tony at atomide.com>
Cc: Sekhar Nori <nsekhar at ti.com>
Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 arch/arm/mach-davinci/board-da850-evm.c      |    3 +-
 arch/arm/mach-omap2/board-4430sdp.c          |    5 ++-
 arch/arm/mach-omap2/board-omap3evm.c         |    3 +-
 arch/arm/mach-omap2/board-omap4panda.c       |    3 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c |    3 +-
 drivers/net/wireless/ti/wl12xx/main.c        |   58 +++++++++++++++++++++++++-
 drivers/net/wireless/ti/wl12xx/wl12xx.h      |   28 +++++++++++++
 include/linux/wl12xx.h                       |   28 ++-----------
 8 files changed, 99 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index d2a2a98..202f3d0 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1378,7 +1378,8 @@ static const short da850_wl12xx_pins[] __initconst = {
 static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
 	.irq			= -1,
 	.irq_flags		= IRQF_TRIGGER_RISING,
-	.board_ref_clock	= WL12XX_REFCLOCK_38,
+	.ref_clock_freq		= 38400000,
+	.ref_clock_xtal		= false,
 };
 
 static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index c2334aa..da2b892 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -694,8 +694,9 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
 
 static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
 	.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
-	.board_ref_clock = WL12XX_REFCLOCK_26,
-	.board_tcxo_clock = WL12XX_TCXOCLOCK_26,
+	.ref_clock_freq = 26000000,
+	.ref_clock_xtal = false,
+	.tcxo_clock_freq = 26000000,
 };
 
 static void __init omap4_sdp4430_wifi_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index a0c0adf..d24435c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -459,7 +459,8 @@ static struct platform_device omap3evm_wlan_regulator = {
 
 struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
 	.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
-	.board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+	.ref_clock_freq = 38400000,
+	.ref_clock_xtal = false,
 };
 #endif
 
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index ba00862..ac6413c 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -231,7 +231,8 @@ static struct platform_device omap_vwlan_device = {
 
 static struct wl12xx_platform_data omap_panda_wlan_data  __initdata = {
 	.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
-	.board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+	.ref_clock_freq = 38400000,
+	.ref_clock_xtal = false,
 };
 
 static struct twl6040_codec_data twl6040_codec = {
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
index ced012c..f4f4fe7 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -245,7 +245,8 @@ static struct platform_device *zoom_devices[] __initdata = {
 
 static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
 	.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
-	.board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz */
+	.ref_clock_freq = 26000000,
+	.ref_clock_xtal = false,
 };
 
 static struct omap2_hsmmc_info mmc[] = {
diff --git a/drivers/net/wireless/ti/wl12xx/main.c b/drivers/net/wireless/ti/wl12xx/main.c
index 1c627da..903dcb3 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1701,6 +1701,42 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
 		},
 };
 
+static struct wl12xx_clock wl12xx_refclock_table[] = {
+	{ 19200000,	false,	WL12XX_REFCLOCK_19	},
+	{ 26000000,	false,	WL12XX_REFCLOCK_26	},
+	{ 26000000,	true,	WL12XX_REFCLOCK_26_XTAL	},
+	{ 38400000,	false,	WL12XX_REFCLOCK_38	},
+	{ 38400000,	true,	WL12XX_REFCLOCK_38_XTAL	},
+	{ 52000000,	false,	WL12XX_REFCLOCK_52	},
+	{ 0,		false,	0 }
+};
+
+static struct wl12xx_clock wl12xx_tcxoclock_table[] = {
+	{ 16368000,	false,	WL12XX_TCXOCLOCK_16_368	},
+	{ 16800000,	false,	WL12XX_TCXOCLOCK_16_8	},
+	{ 19200000,	false,	WL12XX_TCXOCLOCK_19_2	},
+	{ 26000000,	false,	WL12XX_TCXOCLOCK_26	},
+	{ 32736000,	false,	WL12XX_TCXOCLOCK_32_736	},
+	{ 33600000,	false,	WL12XX_TCXOCLOCK_33_6	},
+	{ 38400000,	false,	WL12XX_TCXOCLOCK_38_4	},
+	{ 52000000,	false,	WL12XX_TCXOCLOCK_52	},
+	{ 0,		false,	0 }
+};
+
+static int wl12xx_get_clock_idx(struct wl12xx_clock *table, u32 freq, bool xtal)
+{
+	int i = 0;
+
+	while(table[i].freq != 0) {
+		if ((table[i].freq == freq) &&
+		    (table[i].xtal == xtal))
+			return table[i].hw_idx;
+		i++;
+	};
+
+	return -EINVAL;
+}
+
 static int wl12xx_setup(struct wl1271 *wl)
 {
 	struct wl12xx_priv *priv = wl->priv;
@@ -1722,7 +1758,16 @@ static int wl12xx_setup(struct wl1271 *wl)
 	wl12xx_conf_init(wl);
 
 	if (!fref_param) {
-		priv->ref_clock = pdata->board_ref_clock;
+		priv->ref_clock = wl12xx_get_clock_idx(wl12xx_refclock_table,
+						       pdata->ref_clock_freq,
+						       pdata->ref_clock_xtal);
+		if (priv->ref_clock < 0) {
+			wl1271_error("Invalid ref_clock frequency (%d Hz, %s)",
+				pdata->ref_clock_freq,
+				pdata->ref_clock_xtal ? "XTAL" : "not XTAL");
+
+			return priv->ref_clock;
+		}
 	} else {
 		if (!strcmp(fref_param, "19.2"))
 			priv->ref_clock = WL12XX_REFCLOCK_19;
@@ -1741,7 +1786,16 @@ static int wl12xx_setup(struct wl1271 *wl)
 	}
 
 	if (!tcxo_param) {
-		priv->tcxo_clock = pdata->board_tcxo_clock;
+		priv->tcxo_clock = wl12xx_get_clock_idx(wl12xx_tcxoclock_table,
+							pdata->tcxo_clock_freq,
+							pdata->tcxo_clock_xtal);
+		if (priv->tcxo_clock < 0) {
+			wl1271_error("Invalid tcxo_clock frequency (%d Hz, %s)",
+				pdata->tcxo_clock_freq,
+				pdata->tcxo_clock_xtal ? "XTAL" : "not XTAL");
+
+			return priv->tcxo_clock;
+		}
 	} else {
 		if (!strcmp(tcxo_param, "19.2"))
 			priv->tcxo_clock = WL12XX_TCXOCLOCK_19_2;
diff --git a/drivers/net/wireless/ti/wl12xx/wl12xx.h b/drivers/net/wireless/ti/wl12xx/wl12xx.h
index 9e5484a..05f631b 100644
--- a/drivers/net/wireless/ti/wl12xx/wl12xx.h
+++ b/drivers/net/wireless/ti/wl12xx/wl12xx.h
@@ -79,4 +79,32 @@ struct wl12xx_priv {
 	struct wl127x_rx_mem_pool_addr *rx_mem_addr;
 };
 
+/* Reference clock values */
+enum {
+	WL12XX_REFCLOCK_19	= 0, /* 19.2 MHz */
+	WL12XX_REFCLOCK_26	= 1, /* 26 MHz */
+	WL12XX_REFCLOCK_38	= 2, /* 38.4 MHz */
+	WL12XX_REFCLOCK_52	= 3, /* 52 MHz */
+	WL12XX_REFCLOCK_38_XTAL = 4, /* 38.4 MHz, XTAL */
+	WL12XX_REFCLOCK_26_XTAL = 5, /* 26 MHz, XTAL */
+};
+
+/* TCXO clock values */
+enum {
+	WL12XX_TCXOCLOCK_19_2	= 0, /* 19.2MHz */
+	WL12XX_TCXOCLOCK_26	= 1, /* 26 MHz */
+	WL12XX_TCXOCLOCK_38_4	= 2, /* 38.4MHz */
+	WL12XX_TCXOCLOCK_52	= 3, /* 52 MHz */
+	WL12XX_TCXOCLOCK_16_368	= 4, /* 16.368 MHz */
+	WL12XX_TCXOCLOCK_32_736	= 5, /* 32.736 MHz */
+	WL12XX_TCXOCLOCK_16_8	= 6, /* 16.8 MHz */
+	WL12XX_TCXOCLOCK_33_6	= 7, /* 33.6 MHz */
+};
+
+struct wl12xx_clock {
+	u32	freq;
+	bool	xtal;
+	u8	hw_idx;
+};
+
 #endif /* __WL12XX_PRIV_H__ */
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 1e4ed6e..4982b94 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -26,28 +26,6 @@
 
 #include <linux/err.h>
 
-/* Reference clock values */
-enum {
-	WL12XX_REFCLOCK_19	= 0, /* 19.2 MHz */
-	WL12XX_REFCLOCK_26	= 1, /* 26 MHz */
-	WL12XX_REFCLOCK_38	= 2, /* 38.4 MHz */
-	WL12XX_REFCLOCK_52	= 3, /* 52 MHz */
-	WL12XX_REFCLOCK_38_XTAL = 4, /* 38.4 MHz, XTAL */
-	WL12XX_REFCLOCK_26_XTAL = 5, /* 26 MHz, XTAL */
-};
-
-/* TCXO clock values */
-enum {
-	WL12XX_TCXOCLOCK_19_2	= 0, /* 19.2MHz */
-	WL12XX_TCXOCLOCK_26	= 1, /* 26 MHz */
-	WL12XX_TCXOCLOCK_38_4	= 2, /* 38.4MHz */
-	WL12XX_TCXOCLOCK_52	= 3, /* 52 MHz */
-	WL12XX_TCXOCLOCK_16_368	= 4, /* 16.368 MHz */
-	WL12XX_TCXOCLOCK_32_736	= 5, /* 32.736 MHz */
-	WL12XX_TCXOCLOCK_16_8	= 6, /* 16.8 MHz */
-	WL12XX_TCXOCLOCK_33_6	= 7, /* 33.6 MHz */
-};
-
 struct wl1251_platform_data {
 	void (*set_power)(bool enable);
 	/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
@@ -58,8 +36,10 @@ struct wl1251_platform_data {
 struct wl12xx_platform_data {
 	int irq;
 	unsigned long irq_flags;
-	int board_ref_clock;
-	int board_tcxo_clock;
+	int ref_clock_freq;	/* in Hertz */
+	bool ref_clock_xtal;	/* specify whether the clock is XTAL or not */
+	int tcxo_clock_freq;	/* in Hertz */
+	bool tcxo_clock_xtal;	/* specify whether the clock is XTAL or not */
 };
 
 #ifdef CONFIG_WILINK_PLATFORM_DATA
-- 
1.7.10.4



From coelho at ti.com  Tue Jul  2 10:55:45 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 17:55:45 +0300
Subject: [PATCH v2 6/9] wlcore: add initial device tree support to the sdio
 module
In-Reply-To: <1372776948-24840-1-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
Message-ID: <1372776948-24840-7-git-send-email-coelho@ti.com>

If platform data is not available, try to get the required information
from the device tree.  Register an OF match table and parse the
appropriate device tree nodes.

Parse interrupt property only, for now.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 drivers/net/wireless/ti/wlcore/sdio.c |   69 ++++++++++++++++++++++++++++++---
 1 file changed, 63 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 4c7e8ac..9370d7e 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -30,7 +30,7 @@
 #include <linux/mmc/sdio_ids.h>
 #include <linux/mmc/card.h>
 #include <linux/mmc/host.h>
-#include <linux/gpio.h>
+#include <linux/of_irq.h>
 #include <linux/wl12xx.h>
 #include <linux/pm_runtime.h>
 #include <linux/printk.h>
@@ -214,6 +214,43 @@ static struct wl1271_if_operations sdio_ops = {
 	.set_block_size = wl1271_sdio_set_block_size,
 };
 
+static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
+{
+	struct wl12xx_platform_data *pdata;
+	struct device_node *np = dev->of_node;
+
+	if (!np) {
+		np = of_find_matching_node(NULL, dev->driver->of_match_table);
+		if (!np) {
+			dev_notice(dev, "device tree node not available\n");
+			pdata = ERR_PTR(-ENODEV);
+			goto out;
+		}
+	}
+
+	pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+	if (!pdata) {
+		dev_err(dev, "can't allocate platform data\n");
+		pdata = ERR_PTR(-ENODEV);
+		goto out;
+	}
+
+	pdata->irq = irq_of_parse_and_map(np, 0);
+	if (pdata->irq < 0) {
+		dev_err(dev, "can't get interrupt gpio from the device tree\n");
+		goto out_free;
+	}
+
+	goto out;
+
+out_free:
+	kfree(pdata);
+	pdata = ERR_PTR(-ENODEV);
+
+out:
+	return pdata;
+}
+
 static int wl1271_probe(struct sdio_func *func,
 				  const struct sdio_device_id *id)
 {
@@ -248,11 +285,22 @@ static int wl1271_probe(struct sdio_func *func,
 	/* Use block mode for transferring over one block size of data */
 	func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
+	/* The pdata allocated here is freed when the device is freed,
+	 * so we don't need an additional out label to free it in case
+	 * of error further on.
+	 */
+
+	/* Try to get legacy platform data from the board file */
 	pdev_data->pdata = wl12xx_get_platform_data();
 	if (IS_ERR(pdev_data->pdata)) {
-		ret = PTR_ERR(pdev_data->pdata);
-		dev_err(glue->dev, "missing wlan platform data: %d\n", ret);
-		goto out_free_glue;
+		dev_info(&func->dev,
+			 "legacy platform data not found, trying device tree\n");
+
+		pdev_data->pdata = wlcore_get_pdata_from_of(&func->dev);
+		if (IS_ERR(pdev_data->pdata)) {
+			dev_err(&func->dev, "can't get platform data\n");
+			goto out_free_glue;
+		}
 	}
 
 	/* if sdio can keep power while host is suspended, enable wow */
@@ -386,16 +434,25 @@ static const struct dev_pm_ops wl1271_sdio_pm_ops = {
 };
 #endif
 
+static const struct of_device_id wlcore_sdio_of_match_table[] = {
+	{ .compatible = "ti,wilink6" },
+	{ .compatible = "ti,wilink7" },
+	{ .compatible = "ti,wilink8" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, wlcore_sdio_of_match_table);
+
 static struct sdio_driver wl1271_sdio_driver = {
 	.name		= "wl1271_sdio",
 	.id_table	= wl1271_devices,
 	.probe		= wl1271_probe,
 	.remove		= wl1271_remove,
-#ifdef CONFIG_PM
 	.drv = {
+#ifdef CONFIG_PM
 		.pm = &wl1271_sdio_pm_ops,
-	},
 #endif
+		.of_match_table = of_match_ptr(wlcore_sdio_of_match_table),
+	},
 };
 
 static int __init wl1271_init(void)
-- 
1.7.10.4



From coelho at ti.com  Tue Jul  2 10:55:44 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 17:55:44 +0300
Subject: [PATCH v2 5/9] wlcore: always use one-shot IRQ
In-Reply-To: <1372776948-24840-1-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
Message-ID: <1372776948-24840-6-git-send-email-coelho@ti.com>

Since we are now using threaded IRQs without the primary handler, we
need to set IRQF_ONESHOT, otherwise our request will fail.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 drivers/net/wireless/ti/wlcore/main.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index d306cd5..bc1cff3 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5927,7 +5927,8 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
 
 	wl->irq = platform_get_irq(pdev, 0);
 	wl->if_ops = pdev_data->if_ops;
-	wl->irq_flags = pdata->irq_flags;
+	/* Since we don't use the primary handler, we must set ONESHOT */
+	wl->irq_flags = pdata->irq_flags | IRQF_ONESHOT;
 
 	ret = request_threaded_irq(wl->irq, NULL, wlcore_irq,
 				   wl->irq_flags, pdev->name, wl);
-- 
1.7.10.4



From coelho at ti.com  Tue Jul  2 10:55:47 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 17:55:47 +0300
Subject: [PATCH v2 8/9] wlcore: sdio: get clocks from device tree
In-Reply-To: <1372776948-24840-1-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
Message-ID: <1372776948-24840-9-git-send-email-coelho@ti.com>

Read the clock nodes from the device tree and use them to set the
frequency for the refclock and the tcxo clock.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 drivers/net/wireless/ti/wlcore/sdio.c |   36 +++++++++++++++++++++++++++++++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 980bf3d..60fce49 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -53,6 +53,7 @@ static bool dump = false;
 struct wl12xx_sdio_glue {
 	struct device *dev;
 	struct platform_device *core;
+	struct clk *refclock, *tcxoclock;
 };
 
 static const struct sdio_device_id wl1271_devices[] = {
@@ -224,6 +225,7 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 	struct wl12xx_platform_data *pdata;
 	struct device_node *np = dev->of_node;
 	struct device_node *clock_node;
+	struct wl12xx_sdio_glue *glue = sdio_get_drvdata(dev_to_sdio_func(dev));
 
 	if (!np) {
 		np = of_find_matching_node(NULL, dev->driver->of_match_table);
@@ -250,6 +252,26 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 	for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
 		of_fixed_clk_setup(clock_node);
 
+	/* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
+	glue->refclock = of_clk_get_by_name(np, "refclock");
+	if (IS_ERR(glue->refclock)) {
+		dev_err(dev, "couldn't find refclock on the device tree\n");
+		glue->refclock = NULL;
+	} else {
+		clk_prepare_enable(glue->refclock);
+		pdata->ref_clock_freq = clk_get_rate(glue->refclock);
+	}
+
+	/* TODO: make sure we have this when needed (ie. for WL7) */
+	glue->tcxoclock = of_clk_get_by_name(np, "tcxoclock");
+	if (IS_ERR(glue->tcxoclock)) {
+		dev_err(dev, "couldn't find tcxoclock on the device tree\n");
+		glue->tcxoclock = NULL;
+	} else {
+		clk_prepare_enable(glue->tcxoclock);
+		pdata->ref_clock_freq = clk_get_rate(glue->tcxoclock);
+	}
+
 	goto out;
 
 out_free:
@@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func,
 	/* Use block mode for transferring over one block size of data */
 	func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
+	sdio_set_drvdata(func, glue);
+
 	/* The pdata allocated here is freed when the device is freed,
 	 * so we don't need an additional out label to free it in case
 	 * of error further on.
@@ -319,8 +343,6 @@ static int wl1271_probe(struct sdio_func *func,
 	if (mmcflags & MMC_PM_KEEP_POWER)
 		pdev_data->pwr_in_suspend = true;
 
-	sdio_set_drvdata(func, glue);
-
 	/* Tell PM core that we don't need the card to be powered now */
 	pm_runtime_put_noidle(&func->dev);
 
@@ -387,6 +409,16 @@ static void wl1271_remove(struct sdio_func *func)
 {
 	struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
 
+	if (glue->refclock) {
+		clk_disable_unprepare(glue->refclock);
+		clk_put(glue->refclock);
+	}
+
+	if (glue->tcxoclock) {
+		clk_disable_unprepare(glue->tcxoclock);
+		clk_put(glue->tcxoclock);
+	}
+
 	/* Undo decrement done above in wl1271_probe */
 	pm_runtime_get_noresume(&func->dev);
 
-- 
1.7.10.4



From coelho at ti.com  Tue Jul  2 10:55:46 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 17:55:46 +0300
Subject: [PATCH v2 7/9] wlcore: sdio: add wilink clock providers
In-Reply-To: <1372776948-24840-1-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
Message-ID: <1372776948-24840-8-git-send-email-coelho@ti.com>

Add refclock and tcxoclock as clock providers in WiLink.  These clocks
are not accesible outside the WiLink module, but they are registered
in the clock framework anyway.  Only the WiLink chip consumes these
clocks.

In theory, the WiLink chip could be connected to external clocks
instead of using these internal clocks, so make the clock consumer
code generic enough.  If external clocks are used, then the internal
clock device tree nodes are not necessary, but the external ones must
be specified.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 drivers/net/wireless/ti/wlcore/sdio.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 9370d7e..980bf3d 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,7 @@
 #include <linux/wl12xx.h>
 #include <linux/pm_runtime.h>
 #include <linux/printk.h>
+#include <linux/clk-provider.h>
 
 #include "wlcore.h"
 #include "wl12xx_80211.h"
@@ -214,10 +215,15 @@ static struct wl1271_if_operations sdio_ops = {
 	.set_block_size = wl1271_sdio_set_block_size,
 };
 
+static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
+	{ .compatible = "ti,wilink-clock" },
+};
+
 static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 {
 	struct wl12xx_platform_data *pdata;
 	struct device_node *np = dev->of_node;
+	struct device_node *clock_node;
 
 	if (!np) {
 		np = of_find_matching_node(NULL, dev->driver->of_match_table);
@@ -241,6 +247,9 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 		goto out_free;
 	}
 
+	for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
+		of_fixed_clk_setup(clock_node);
+
 	goto out;
 
 out_free:
-- 
1.7.10.4



From coelho at ti.com  Tue Jul  2 10:55:48 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 17:55:48 +0300
Subject: [PATCH v2 9/9] wlcore/wl12xx: check if we got correct clock data from
 DT
In-Reply-To: <1372776948-24840-1-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
Message-ID: <1372776948-24840-10-git-send-email-coelho@ti.com>

The fref and the tcxo clocks settings are optional in some platforms.
WiLink8 doesn't need either, so we don't check the values.  WiLink 6
only needs the fref clock, so we check that it is valid or return with
an error.  WiLink7 needs both clocks, if either is not available we
return with an error.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 drivers/net/wireless/ti/wl12xx/main.c |   20 +++++++++++++++++---
 drivers/net/wireless/ti/wlcore/sdio.c |    4 ----
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ti/wl12xx/main.c b/drivers/net/wireless/ti/wl12xx/main.c
index 903dcb3..72d13e4 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -927,6 +927,11 @@ static int wl128x_boot_clk(struct wl1271 *wl, int *selected_clock)
 	u16 sys_clk_cfg;
 	int ret;
 
+	if ((priv->ref_clock < 0) || (priv->tcxo_clock < 0)) {
+		wl1271_error("Missing fref and/or tcxo clock settings\n");
+		return -EINVAL;
+	}
+
 	/* For XTAL-only modes, FREF will be used after switching from TCXO */
 	if (priv->ref_clock == WL12XX_REFCLOCK_26_XTAL ||
 	    priv->ref_clock == WL12XX_REFCLOCK_38_XTAL) {
@@ -976,6 +981,11 @@ static int wl127x_boot_clk(struct wl1271 *wl)
 	u32 clk;
 	int ret;
 
+	if (priv->ref_clock < 0) {
+		wl1271_error("Missing fref clock settings\n");
+		return -EINVAL;
+	}
+
 	if (WL127X_PG_GET_MAJOR(wl->hw_pg_ver) < 3)
 		wl->quirks |= WLCORE_QUIRK_END_OF_TRANSACTION;
 
@@ -1757,7 +1767,7 @@ static int wl12xx_setup(struct wl1271 *wl)
 	wlcore_set_ht_cap(wl, IEEE80211_BAND_5GHZ, &wl12xx_ht_cap);
 	wl12xx_conf_init(wl);
 
-	if (!fref_param) {
+	if (!fref_param && (pdata->ref_clock_freq > 0)) {
 		priv->ref_clock = wl12xx_get_clock_idx(wl12xx_refclock_table,
 						       pdata->ref_clock_freq,
 						       pdata->ref_clock_xtal);
@@ -1768,6 +1778,8 @@ static int wl12xx_setup(struct wl1271 *wl)
 
 			return priv->ref_clock;
 		}
+	} else if (!fref_param) {
+		priv->ref_clock = -EINVAL;
 	} else {
 		if (!strcmp(fref_param, "19.2"))
 			priv->ref_clock = WL12XX_REFCLOCK_19;
@@ -1785,7 +1797,7 @@ static int wl12xx_setup(struct wl1271 *wl)
 			wl1271_error("Invalid fref parameter %s", fref_param);
 	}
 
-	if (!tcxo_param) {
+	if (!fref_param && (pdata->tcxo_clock_freq > 0)) {
 		priv->tcxo_clock = wl12xx_get_clock_idx(wl12xx_tcxoclock_table,
 							pdata->tcxo_clock_freq,
 							pdata->tcxo_clock_xtal);
@@ -1796,7 +1808,9 @@ static int wl12xx_setup(struct wl1271 *wl)
 
 			return priv->tcxo_clock;
 		}
-	} else {
+	} else if (!fref_param) {
+		priv->tcxo_clock = -EINVAL;
+	}else {
 		if (!strcmp(tcxo_param, "19.2"))
 			priv->tcxo_clock = WL12XX_TCXOCLOCK_19_2;
 		else if (!strcmp(tcxo_param, "26"))
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 60fce49..c76eb66 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -252,20 +252,16 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 	for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
 		of_fixed_clk_setup(clock_node);
 
-	/* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
 	glue->refclock = of_clk_get_by_name(np, "refclock");
 	if (IS_ERR(glue->refclock)) {
-		dev_err(dev, "couldn't find refclock on the device tree\n");
 		glue->refclock = NULL;
 	} else {
 		clk_prepare_enable(glue->refclock);
 		pdata->ref_clock_freq = clk_get_rate(glue->refclock);
 	}
 
-	/* TODO: make sure we have this when needed (ie. for WL7) */
 	glue->tcxoclock = of_clk_get_by_name(np, "tcxoclock");
 	if (IS_ERR(glue->tcxoclock)) {
-		dev_err(dev, "couldn't find tcxoclock on the device tree\n");
 		glue->tcxoclock = NULL;
 	} else {
 		clk_prepare_enable(glue->tcxoclock);
-- 
1.7.10.4



From nm at ti.com  Tue Jul  2 11:02:08 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 2 Jul 2013 10:02:08 -0500
Subject: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for
 pdata clocks
In-Reply-To: <1372776948-24840-5-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-5-git-send-email-coelho@ti.com>
Message-ID: <20130702150208.GA4233@kahuna>

On 17:55-20130702, Luciano Coelho wrote:
> Instead of defining an enumeration with the FW specific values for the
> different clock rates, use the actual frequency instead.  Also add a
> boolean to specify whether the clock is XTAL or not.
> 
> Change all board files to reflect this.
> 
> Cc: Tony Lindgren <tony at atomide.com>
> Cc: Sekhar Nori <nsekhar at ti.com>
> Signed-off-by: Luciano Coelho <coelho at ti.com>
> ---
>  arch/arm/mach-davinci/board-da850-evm.c      |    3 +-
>  arch/arm/mach-omap2/board-4430sdp.c          |    5 ++-
^^
>  arch/arm/mach-omap2/board-omap3evm.c         |    3 +-
>  arch/arm/mach-omap2/board-omap4panda.c       |    3 +-
^^
Please do not add more platform data to platforms that are DT only.

>  arch/arm/mach-omap2/board-zoom-peripherals.c |    3 +-
>  drivers/net/wireless/ti/wl12xx/main.c        |   58 +++++++++++++++++++++++++-
>  drivers/net/wireless/ti/wl12xx/wl12xx.h      |   28 +++++++++++++
>  include/linux/wl12xx.h                       |   28 ++-----------
>  8 files changed, 99 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index d2a2a98..202f3d0 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1378,7 +1378,8 @@ static const short da850_wl12xx_pins[] __initconst = {
>  static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
>  	.irq			= -1,
>  	.irq_flags		= IRQF_TRIGGER_RISING,
> -	.board_ref_clock	= WL12XX_REFCLOCK_38,
> +	.ref_clock_freq		= 38400000,
> +	.ref_clock_xtal		= false,
>  };
>  
>  static __init int da850_wl12xx_init(void)
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> index c2334aa..da2b892 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -694,8 +694,9 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
>  
>  static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
>  	.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> -	.board_ref_clock = WL12XX_REFCLOCK_26,
> -	.board_tcxo_clock = WL12XX_TCXOCLOCK_26,
> +	.ref_clock_freq = 26000000,
> +	.ref_clock_xtal = false,
> +	.tcxo_clock_freq = 26000000,
>  };
>  
>  static void __init omap4_sdp4430_wifi_init(void)
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
> index a0c0adf..d24435c 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -459,7 +459,8 @@ static struct platform_device omap3evm_wlan_regulator = {
>  
>  struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
>  	.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> -	.board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
> +	.ref_clock_freq = 38400000,
> +	.ref_clock_xtal = false,
>  };
>  #endif
>  
> diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
> index ba00862..ac6413c 100644
> --- a/arch/arm/mach-omap2/board-omap4panda.c
> +++ b/arch/arm/mach-omap2/board-omap4panda.c
> @@ -231,7 +231,8 @@ static struct platform_device omap_vwlan_device = {
>  
>  static struct wl12xx_platform_data omap_panda_wlan_data  __initdata = {
>  	.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> -	.board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
> +	.ref_clock_freq = 38400000,
> +	.ref_clock_xtal = false,
>  };
>  
>  static struct twl6040_codec_data twl6040_codec = {
> diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
> index ced012c..f4f4fe7 100644
> --- a/arch/arm/mach-omap2/board-zoom-peripherals.c
> +++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
> @@ -245,7 +245,8 @@ static struct platform_device *zoom_devices[] __initdata = {
>  
>  static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
>  	.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> -	.board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz */
> +	.ref_clock_freq = 26000000,
> +	.ref_clock_xtal = false,
>  };
>  
>  static struct omap2_hsmmc_info mmc[] = {
> diff --git a/drivers/net/wireless/ti/wl12xx/main.c b/drivers/net/wireless/ti/wl12xx/main.c
> index 1c627da..903dcb3 100644
> --- a/drivers/net/wireless/ti/wl12xx/main.c
> +++ b/drivers/net/wireless/ti/wl12xx/main.c
> @@ -1701,6 +1701,42 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
>  		},
>  };
>  
> +static struct wl12xx_clock wl12xx_refclock_table[] = {
> +	{ 19200000,	false,	WL12XX_REFCLOCK_19	},
> +	{ 26000000,	false,	WL12XX_REFCLOCK_26	},
> +	{ 26000000,	true,	WL12XX_REFCLOCK_26_XTAL	},
> +	{ 38400000,	false,	WL12XX_REFCLOCK_38	},
> +	{ 38400000,	true,	WL12XX_REFCLOCK_38_XTAL	},
> +	{ 52000000,	false,	WL12XX_REFCLOCK_52	},
> +	{ 0,		false,	0 }
> +};
> +
> +static struct wl12xx_clock wl12xx_tcxoclock_table[] = {
> +	{ 16368000,	false,	WL12XX_TCXOCLOCK_16_368	},
> +	{ 16800000,	false,	WL12XX_TCXOCLOCK_16_8	},
> +	{ 19200000,	false,	WL12XX_TCXOCLOCK_19_2	},
> +	{ 26000000,	false,	WL12XX_TCXOCLOCK_26	},
> +	{ 32736000,	false,	WL12XX_TCXOCLOCK_32_736	},
> +	{ 33600000,	false,	WL12XX_TCXOCLOCK_33_6	},
> +	{ 38400000,	false,	WL12XX_TCXOCLOCK_38_4	},
> +	{ 52000000,	false,	WL12XX_TCXOCLOCK_52	},
> +	{ 0,		false,	0 }
> +};
> +
> +static int wl12xx_get_clock_idx(struct wl12xx_clock *table, u32 freq, bool xtal)
> +{
> +	int i = 0;
> +
> +	while(table[i].freq != 0) {
> +		if ((table[i].freq == freq) &&
> +		    (table[i].xtal == xtal))
> +			return table[i].hw_idx;
> +		i++;
> +	};
> +
> +	return -EINVAL;
> +}
> +
>  static int wl12xx_setup(struct wl1271 *wl)
>  {
>  	struct wl12xx_priv *priv = wl->priv;
> @@ -1722,7 +1758,16 @@ static int wl12xx_setup(struct wl1271 *wl)
>  	wl12xx_conf_init(wl);
>  
>  	if (!fref_param) {
> -		priv->ref_clock = pdata->board_ref_clock;
> +		priv->ref_clock = wl12xx_get_clock_idx(wl12xx_refclock_table,
> +						       pdata->ref_clock_freq,
> +						       pdata->ref_clock_xtal);
> +		if (priv->ref_clock < 0) {
> +			wl1271_error("Invalid ref_clock frequency (%d Hz, %s)",
> +				pdata->ref_clock_freq,
> +				pdata->ref_clock_xtal ? "XTAL" : "not XTAL");
> +
> +			return priv->ref_clock;
> +		}
>  	} else {
>  		if (!strcmp(fref_param, "19.2"))
>  			priv->ref_clock = WL12XX_REFCLOCK_19;
> @@ -1741,7 +1786,16 @@ static int wl12xx_setup(struct wl1271 *wl)
>  	}
>  
>  	if (!tcxo_param) {
> -		priv->tcxo_clock = pdata->board_tcxo_clock;
> +		priv->tcxo_clock = wl12xx_get_clock_idx(wl12xx_tcxoclock_table,
> +							pdata->tcxo_clock_freq,
> +							pdata->tcxo_clock_xtal);
> +		if (priv->tcxo_clock < 0) {
> +			wl1271_error("Invalid tcxo_clock frequency (%d Hz, %s)",
> +				pdata->tcxo_clock_freq,
> +				pdata->tcxo_clock_xtal ? "XTAL" : "not XTAL");
> +
> +			return priv->tcxo_clock;
> +		}
>  	} else {
>  		if (!strcmp(tcxo_param, "19.2"))
>  			priv->tcxo_clock = WL12XX_TCXOCLOCK_19_2;
> diff --git a/drivers/net/wireless/ti/wl12xx/wl12xx.h b/drivers/net/wireless/ti/wl12xx/wl12xx.h
> index 9e5484a..05f631b 100644
> --- a/drivers/net/wireless/ti/wl12xx/wl12xx.h
> +++ b/drivers/net/wireless/ti/wl12xx/wl12xx.h
> @@ -79,4 +79,32 @@ struct wl12xx_priv {
>  	struct wl127x_rx_mem_pool_addr *rx_mem_addr;
>  };
>  
> +/* Reference clock values */
> +enum {
> +	WL12XX_REFCLOCK_19	= 0, /* 19.2 MHz */
> +	WL12XX_REFCLOCK_26	= 1, /* 26 MHz */
> +	WL12XX_REFCLOCK_38	= 2, /* 38.4 MHz */
> +	WL12XX_REFCLOCK_52	= 3, /* 52 MHz */
> +	WL12XX_REFCLOCK_38_XTAL = 4, /* 38.4 MHz, XTAL */
> +	WL12XX_REFCLOCK_26_XTAL = 5, /* 26 MHz, XTAL */
> +};
> +
> +/* TCXO clock values */
> +enum {
> +	WL12XX_TCXOCLOCK_19_2	= 0, /* 19.2MHz */
> +	WL12XX_TCXOCLOCK_26	= 1, /* 26 MHz */
> +	WL12XX_TCXOCLOCK_38_4	= 2, /* 38.4MHz */
> +	WL12XX_TCXOCLOCK_52	= 3, /* 52 MHz */
> +	WL12XX_TCXOCLOCK_16_368	= 4, /* 16.368 MHz */
> +	WL12XX_TCXOCLOCK_32_736	= 5, /* 32.736 MHz */
> +	WL12XX_TCXOCLOCK_16_8	= 6, /* 16.8 MHz */
> +	WL12XX_TCXOCLOCK_33_6	= 7, /* 33.6 MHz */
> +};
> +
> +struct wl12xx_clock {
> +	u32	freq;
> +	bool	xtal;
> +	u8	hw_idx;
> +};
> +
>  #endif /* __WL12XX_PRIV_H__ */
> diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
> index 1e4ed6e..4982b94 100644
> --- a/include/linux/wl12xx.h
> +++ b/include/linux/wl12xx.h
> @@ -26,28 +26,6 @@
>  
>  #include <linux/err.h>
>  
> -/* Reference clock values */
> -enum {
> -	WL12XX_REFCLOCK_19	= 0, /* 19.2 MHz */
> -	WL12XX_REFCLOCK_26	= 1, /* 26 MHz */
> -	WL12XX_REFCLOCK_38	= 2, /* 38.4 MHz */
> -	WL12XX_REFCLOCK_52	= 3, /* 52 MHz */
> -	WL12XX_REFCLOCK_38_XTAL = 4, /* 38.4 MHz, XTAL */
> -	WL12XX_REFCLOCK_26_XTAL = 5, /* 26 MHz, XTAL */
> -};
> -
> -/* TCXO clock values */
> -enum {
> -	WL12XX_TCXOCLOCK_19_2	= 0, /* 19.2MHz */
> -	WL12XX_TCXOCLOCK_26	= 1, /* 26 MHz */
> -	WL12XX_TCXOCLOCK_38_4	= 2, /* 38.4MHz */
> -	WL12XX_TCXOCLOCK_52	= 3, /* 52 MHz */
> -	WL12XX_TCXOCLOCK_16_368	= 4, /* 16.368 MHz */
> -	WL12XX_TCXOCLOCK_32_736	= 5, /* 32.736 MHz */
> -	WL12XX_TCXOCLOCK_16_8	= 6, /* 16.8 MHz */
> -	WL12XX_TCXOCLOCK_33_6	= 7, /* 33.6 MHz */
> -};
> -
>  struct wl1251_platform_data {
>  	void (*set_power)(bool enable);
>  	/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
> @@ -58,8 +36,10 @@ struct wl1251_platform_data {
>  struct wl12xx_platform_data {
>  	int irq;
>  	unsigned long irq_flags;
> -	int board_ref_clock;
> -	int board_tcxo_clock;
> +	int ref_clock_freq;	/* in Hertz */
> +	bool ref_clock_xtal;	/* specify whether the clock is XTAL or not */
> +	int tcxo_clock_freq;	/* in Hertz */
> +	bool tcxo_clock_xtal;	/* specify whether the clock is XTAL or not */
>  };
>  
>  #ifdef CONFIG_WILINK_PLATFORM_DATA
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Regards,
Nishanth Menon


From broonie at kernel.org  Tue Jul  2 11:04:49 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 2 Jul 2013 16:04:49 +0100
Subject: [PATCH] drm/exynos: Add missing includes
In-Reply-To: <008a01ce771e$afe02670$0fa07350$%dae@samsung.com>
References: <1372683355-27460-1-git-send-email-broonie@kernel.org>
 <008a01ce771e$afe02670$0fa07350$%dae@samsung.com>
Message-ID: <20130702150449.GO27646@sirena.org.uk>

On Tue, Jul 02, 2013 at 09:21:32PM +0900, Inki Dae wrote:

> > Ensure that all externally accessed functions are correctly prototyped
> > when defined in each file by making sure the headers with the protoypes
> > are included in the file with the definition.

> I don't see why this patch is needed. it seems like including unnecessary
> headers so it makes the code size enlarged.

Well, aside from it being basic good practice and allowing the compiler
to check for errors in the prototypes this is also something that sparse
warns about.

If the resulting binary size is changed by having the headers included
then that indicates a bug in the headers - they *really* shouldn't be
doing anything substantial here.  None of the headers in question looked
at all worrying.
-------------- 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/20130702/d4c8cc03/attachment.sig>

From lars at metafoo.de  Tue Jul  2 11:25:46 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Tue, 02 Jul 2013 17:25:46 +0200
Subject: [alsa-devel] [PATCH 1/2] ASoC: atmel_ssc_dai: move set dma data
 to startup callback
In-Reply-To: <1372755849-19546-2-git-send-email-voice.shen@atmel.com>
References: <1372755849-19546-1-git-send-email-voice.shen@atmel.com>
 <1372755849-19546-2-git-send-email-voice.shen@atmel.com>
Message-ID: <51D2F0FA.6040409@metafoo.de>

On 07/02/2013 11:04 AM, Bo Shen wrote:
[...]
> +	dma_params->substream = substream;

Unrelated to this patch, but having a substream field in the dma_params seems
to be redundant, since you need to know the substream to get the dma_params in
the first place. Looking at the code it also seems to be unused other than this
assignment. Maybe you can send a follow up patch to remove it.

[...]



From stern at rowland.harvard.edu  Tue Jul  2 11:26:11 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 2 Jul 2013 11:26:11 -0400 (EDT)
Subject: [PATCH V2] USB: OHCI: make ohci-nxp a separate driver
In-Reply-To: <1372765832-18054-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <Pine.LNX.4.44L0.1307021125480.1086-100000@iolanthe.rowland.org>

On Tue, 2 Jul 2013, Manjunath Goudar wrote:

> Separate the OHCI NXP host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM.
> 
> Many place function name and struct name started with usb,
> current scenario replaced usb with ohci for proper naming.
> 
> Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Greg KH <greg at kroah.com>
> Cc: linux-usb at vger.kernel.org
> 
> V2:
>   - Directive check NXP_PLATFORM_DRIVER block has been removed.

Acked-by: Alan Stern <stern at rowland.harvard.edu>



From balbi at ti.com  Tue Jul  2 11:26:57 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 2 Jul 2013 18:26:57 +0300
Subject: [PATCH v2 2/9] wlcore: use irq_flags in pdata instead of hiding
 it behind a quirk
In-Reply-To: <1372776948-24840-3-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-3-git-send-email-coelho@ti.com>
Message-ID: <20130702152657.GE7013@arwen.pp.htv.fi>

Hi,

On Tue, Jul 02, 2013 at 05:55:41PM +0300, Luciano Coelho wrote:
> The platform_quirk element in the platform data was used to change the
> way the IRQ is triggered.  When set, the EDGE_IRQ quirk would change
> the irqflags used and treat edge trigger differently from the rest.
> 
> Instead of hiding this irq flag setting behind the quirk, export the
> whole irq_flags element and let the board file define what to use.
> This will be more meaningful than driver-specific quirks when we
> switch to DT.
> 
> Cc: Tony Lindgren <tony at atomide.com>
> Cc: Sekhar Nori <nsekhar at ti.com>
> Signed-off-by: Luciano Coelho <coelho at ti.com>
> Acked-by: Tony Lindgren <tony at atomide.com>
> ---
>  arch/arm/mach-davinci/board-da850-evm.c      |    2 +-
>  arch/arm/mach-omap2/board-4430sdp.c          |    1 +
>  arch/arm/mach-omap2/board-omap3evm.c         |    1 +
>  arch/arm/mach-omap2/board-omap4panda.c       |    1 +
>  arch/arm/mach-omap2/board-zoom-peripherals.c |    1 +
>  drivers/net/wireless/ti/wlcore/debugfs.c     |    2 +-
>  drivers/net/wireless/ti/wlcore/main.c        |   13 +++----------
>  drivers/net/wireless/ti/wlcore/wlcore.h      |    5 ++---
>  include/linux/wl12xx.h                       |    5 +----
>  9 files changed, 12 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 8a24b6c..d2a2a98 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1377,8 +1377,8 @@ static const short da850_wl12xx_pins[] __initconst = {
>  
>  static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
>  	.irq			= -1,
> +	.irq_flags		= IRQF_TRIGGER_RISING,
>  	.board_ref_clock	= WL12XX_REFCLOCK_38,
> -	.platform_quirks	= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
>  };
>  
>  static __init int da850_wl12xx_init(void)
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> index 56a9a4f..c2334aa 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -693,6 +693,7 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
>  }
>  
>  static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
> +	.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,

couldn't you just call irq_set_irq_type() from the board-file itself ?
Then on your driver you can just pass IRQF_ONESHOT (to make sure heh) to
your request_threaded_irq_handler()

-- 
balbi
-------------- 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/20130702/4de089c4/attachment.sig>

From lars at metafoo.de  Tue Jul  2 11:34:30 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Tue, 02 Jul 2013 17:34:30 +0200
Subject: [alsa-devel] [PATCH 2/2] ASoC: atmel-pcm: use generic dmaengine
 framework
In-Reply-To: <1372755849-19546-3-git-send-email-voice.shen@atmel.com>
References: <1372755849-19546-1-git-send-email-voice.shen@atmel.com>
 <1372755849-19546-3-git-send-email-voice.shen@atmel.com>
Message-ID: <51D2F306.7040603@metafoo.de>

On 07/02/2013 11:04 AM, Bo Shen wrote:
[...]
> -/*--------------------------------------------------------------------------*\
> - * DMAENGINE operations
> -\*--------------------------------------------------------------------------*/
> -static bool filter(struct dma_chan *chan, void *slave)
> -{
> -	struct at_dma_slave *sl = slave;
> -
> -	if (sl->dma_dev == chan->device->dev) {
> -		chan->private = sl;
> -		return true;
> -	} else {
> -		return false;
> -	}
> -}

I'm wondering why is filtering no longer required?

[...]
> +		slave_config->dst_addr = (dma_addr_t)ssc->phybase + SSC_THR;
[...]
> +		slave_config->src_addr = (dma_addr_t)ssc->phybase + SSC_RHR;

Change the type of phybase to dma_addr_t

[...]
>  }
>  
> -static int atmel_pcm_dma_prepare(struct snd_pcm_substream *substream)
> -{
> -	struct snd_soc_pcm_runtime *rtd = substream->private_data;
> -	struct atmel_pcm_dma_params *prtd;
> -
> -	prtd = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
> -
> -	ssc_writex(prtd->ssc->regs, SSC_IER, prtd->mask->ssc_error);
> -	ssc_writex(prtd->ssc->regs, SSC_CR, prtd->mask->ssc_enable);

These writes are also completely lost

> -
> -	return 0;
> -}

I think it would also be good to get rid of any references to the ssc struct
from the DMA driver and move them over to the DAI driver.

- Lars


From balbi at ti.com  Tue Jul  2 11:31:13 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 2 Jul 2013 18:31:13 +0300
Subject: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for
 pdata clocks
In-Reply-To: <1372776948-24840-5-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-5-git-send-email-coelho@ti.com>
Message-ID: <20130702153113.GF7013@arwen.pp.htv.fi>

Hi,

On Tue, Jul 02, 2013 at 05:55:43PM +0300, Luciano Coelho wrote:
> diff --git a/drivers/net/wireless/ti/wl12xx/main.c b/drivers/net/wireless/ti/wl12xx/main.c
> index 1c627da..903dcb3 100644
> --- a/drivers/net/wireless/ti/wl12xx/main.c
> +++ b/drivers/net/wireless/ti/wl12xx/main.c
> @@ -1701,6 +1701,42 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
>  		},
>  };
>  
> +static struct wl12xx_clock wl12xx_refclock_table[] = {

const

> +	{ 19200000,	false,	WL12XX_REFCLOCK_19	},
> +	{ 26000000,	false,	WL12XX_REFCLOCK_26	},
> +	{ 26000000,	true,	WL12XX_REFCLOCK_26_XTAL	},
> +	{ 38400000,	false,	WL12XX_REFCLOCK_38	},
> +	{ 38400000,	true,	WL12XX_REFCLOCK_38_XTAL	},
> +	{ 52000000,	false,	WL12XX_REFCLOCK_52	},
> +	{ 0,		false,	0 }
> +};
> +
> +static struct wl12xx_clock wl12xx_tcxoclock_table[] = {

const

-- 
balbi
-------------- 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/20130702/38e6d799/attachment.sig>

From balbi at ti.com  Tue Jul  2 11:32:29 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 2 Jul 2013 18:32:29 +0300
Subject: [PATCH v2 5/9] wlcore: always use one-shot IRQ
In-Reply-To: <1372776948-24840-6-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-6-git-send-email-coelho@ti.com>
Message-ID: <20130702153229.GG7013@arwen.pp.htv.fi>

On Tue, Jul 02, 2013 at 05:55:44PM +0300, Luciano Coelho wrote:
> Since we are now using threaded IRQs without the primary handler, we
> need to set IRQF_ONESHOT, otherwise our request will fail.
> 
> Signed-off-by: Luciano Coelho <coelho at ti.com>

good to see this happening, I remember we talked about this a while back
:-)

Acked-by: Felipe Balbi <balbi at ti.com>

Still, if you call irq_set_irq_type() on board-file (since DT will do
something similar for you anyway) then you can completely drop
irq_flags.

-- 
balbi
-------------- 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/20130702/d9741fff/attachment-0001.sig>

From balbi at ti.com  Tue Jul  2 11:34:23 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 2 Jul 2013 18:34:23 +0300
Subject: [PATCH v2 7/9] wlcore: sdio: add wilink clock providers
In-Reply-To: <1372776948-24840-8-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-8-git-send-email-coelho@ti.com>
Message-ID: <20130702153423.GH7013@arwen.pp.htv.fi>

On Tue, Jul 02, 2013 at 05:55:46PM +0300, Luciano Coelho wrote:
> Add refclock and tcxoclock as clock providers in WiLink.  These clocks
> are not accesible outside the WiLink module, but they are registered
> in the clock framework anyway.  Only the WiLink chip consumes these
> clocks.
> 
> In theory, the WiLink chip could be connected to external clocks
> instead of using these internal clocks, so make the clock consumer
> code generic enough.  If external clocks are used, then the internal
> clock device tree nodes are not necessary, but the external ones must
> be specified.
> 
> Signed-off-by: Luciano Coelho <coelho at ti.com>

Acked-by: Felipe Balbi <balbi at ti.com>

-- 
balbi
-------------- 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/20130702/18186793/attachment.sig>

From balbi at ti.com  Tue Jul  2 11:35:26 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 2 Jul 2013 18:35:26 +0300
Subject: [PATCH v2 8/9] wlcore: sdio: get clocks from device tree
In-Reply-To: <1372776948-24840-9-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-9-git-send-email-coelho@ti.com>
Message-ID: <20130702153526.GI7013@arwen.pp.htv.fi>

Hi,

On Tue, Jul 02, 2013 at 05:55:47PM +0300, Luciano Coelho wrote:
> @@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func,
>  	/* Use block mode for transferring over one block size of data */
>  	func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
>  
> +	sdio_set_drvdata(func, glue);

is this move really necessary ?

-- 
balbi
-------------- 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/20130702/a7cd1015/attachment.sig>

From dserrg at gmail.com  Tue Jul  2 11:58:05 2013
From: dserrg at gmail.com (Sergey Dyasly)
Date: Tue,  2 Jul 2013 19:58:05 +0400
Subject: [PATCH v2] ARM: LPAE: don't reject mapping /dev/mem above 4GB
Message-ID: <1372780685-2528-1-git-send-email-dserrg@gmail.com>

With LPAE enabled, physical address space is larger than 4GB. Allow mapping any
part of it via /dev/mem by utilizing the same check as in arm64.

PHYS_MASK covers 40 bits with LPAE enabled and 32 bits otherwise.

Signed-off-by: Sergey Dyasly <dserrg at gmail.com>
---

v2:
- Removed #ifdef and changed original function as suggested by Catalin Marinas

 arch/arm/mm/mmap.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 10062ce..09bab92 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -204,13 +204,11 @@ int valid_phys_addr_range(phys_addr_t addr, size_t size)
 }
 
 /*
- * We don't use supersection mappings for mmap() on /dev/mem, which
- * means that we can't map the memory area above the 4G barrier into
- * userspace.
+ * Do not allow /dev/mem mappings beyond the supported physical range.
  */
 int valid_mmap_phys_addr_range(unsigned long pfn, size_t size)
 {
-	return !(pfn + (size >> PAGE_SHIFT) > 0x00100000);
+	return !(((pfn << PAGE_SHIFT) + size) & ~PHYS_MASK);
 }
 
 #ifdef CONFIG_STRICT_DEVMEM
-- 
1.8.1.2



From shc_work at mail.ru  Tue Jul  2 12:02:24 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Tue,  2 Jul 2013 20:02:24 +0400
Subject: [PATCH 1/6] ARM: dts: i.MX27: Move IIM node under AIPI2 bus
Message-ID: <1372780949-31897-1-git-send-email-shc_work@mail.ru>

This patch moves IIM node under AIPI2 bus, since this is proper
location for this module.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27.dtsi | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index a587294..516473c 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -375,13 +375,6 @@
 				clocks = <&clks 41>, <&clks 61>;
 				clock-names = "ipg", "per";
 			};
-
-			iim: iim at 10028000 {
-				compatible = "fsl,imx27-iim";
-				reg = <0x10028000 0x1000>;
-				interrupts = <62>;
-				clocks = <&clks 38>;
-			};
 		};
 
 		aipi at 10020000 { /* AIPI2 */
@@ -423,6 +416,13 @@
 				#clock-cells = <1>;
 			};
 
+			iim: iim at 10028000 {
+				compatible = "fsl,imx27-iim";
+				reg = <0x10028000 0x1000>;
+				interrupts = <62>;
+				clocks = <&clks 38>;
+			};
+
 			fec: ethernet at 1002b000 {
 				compatible = "fsl,imx27-fec";
 				reg = <0x1002b000 0x4000>;
-- 
1.8.1.5



From shc_work at mail.ru  Tue Jul  2 12:02:27 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Tue,  2 Jul 2013 20:02:27 +0400
Subject: [PATCH 4/6] ARM: dts: imx27-phytec-phycore-som: Add SRAM node
In-Reply-To: <1372780949-31897-1-git-send-email-shc_work@mail.ru>
References: <1372780949-31897-1-git-send-email-shc_work@mail.ru>
Message-ID: <1372780949-31897-4-git-send-email-shc_work@mail.ru>

This patch adds SRAM node for Phytec PCM-038 module.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27-phytec-phycore-som.dts | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/imx27-phytec-phycore-som.dts b/arch/arm/boot/dts/imx27-phytec-phycore-som.dts
index 92765ee..bd7df2e 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore-som.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycore-som.dts
@@ -181,4 +181,14 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 	};
+
+	sram: sram at c8000000 {
+		compatible = "mtd-ram";
+		reg = <1 0x00000000 0x00800000>;
+		bank-width = <2>;
+		linux,mtd-name = "mtd-ram.0";
+		fsl,weim-cs-timing = <0x0000d843 0x22252521 0x22220a00>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+	};
 };
-- 
1.8.1.5



From shc_work at mail.ru  Tue Jul  2 12:02:28 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Tue,  2 Jul 2013 20:02:28 +0400
Subject: [PATCH 5/6] ARM: dts: imx27-phytec-phycore-rdk: Add CAN node
In-Reply-To: <1372780949-31897-1-git-send-email-shc_work@mail.ru>
References: <1372780949-31897-1-git-send-email-shc_work@mail.ru>
Message-ID: <1372780949-31897-5-git-send-email-shc_work@mail.ru>

This patch adds CAN (NXP SJA1000) node for Phytec PCM-970 RDK.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts b/arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts
index e7ed978..0fc6551 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts
@@ -35,3 +35,16 @@
 	fsl,uart-has-rtscts;
 	status = "okay";
 };
+
+&weim {
+	can at d4000000 {
+		compatible = "nxp,sja1000";
+		reg = <4 0x00000000 0x00000100>;
+		interrupt-parent = <&gpio5>;
+		interrupts = <19 0x2>;
+		nxp,external-clock-frequency = <16000000>;
+		nxp,tx-output-config = <0x16>;
+		nxp,no-comparator-bypass;
+		fsl,weim-cs-timing = <0x0000dcf6 0x444a0301 0x44443302>;
+	};
+};
-- 
1.8.1.5



From shc_work at mail.ru  Tue Jul  2 12:02:29 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Tue,  2 Jul 2013 20:02:29 +0400
Subject: [PATCH 6/6] ARM: dts: imx27-phytec-phycore-som: Using labels for
 reusing UART, I2C and FEC
In-Reply-To: <1372780949-31897-1-git-send-email-shc_work@mail.ru>
References: <1372780949-31897-1-git-send-email-shc_work@mail.ru>
Message-ID: <1372780949-31897-6-git-send-email-shc_work@mail.ru>


Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27-phytec-phycore-som.dts | 63 ++++++++++++--------------
 1 file changed, 30 insertions(+), 33 deletions(-)

diff --git a/arch/arm/boot/dts/imx27-phytec-phycore-som.dts b/arch/arm/boot/dts/imx27-phytec-phycore-som.dts
index bd7df2e..22d0d27 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore-som.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycore-som.dts
@@ -19,39 +19,6 @@
 	memory {
 		reg = <0xa0000000 0x08000000>;
 	};
-
-	soc {
-		aipi at 10000000 { /* aipi1 */
-			serial at 1000a000 {
-				status = "okay";
-			};
-
-			i2c at 1001d000 {
-				clock-frequency = <400000>;
-				status = "okay";
-				at24 at 52 {
-					compatible = "at,24c32";
-					pagesize = <32>;
-					reg = <0x52>;
-				};
-				pcf8563 at 51 {
-					compatible = "nxp,pcf8563";
-					reg = <0x51>;
-				};
-				lm75 at 4a {
-					compatible = "national,lm75";
-					reg = <0x4a>;
-				};
-			};
-		};
-
-		aipi at 10020000 { /* aipi2 */
-			ethernet at 1002b000 {
-				phy-reset-gpios = <&gpio3 30 0>;
-				status = "okay";
-			};
-		};
-	};
 };
 
 &cspi1 {
@@ -163,12 +130,42 @@
 	};
 };
 
+&fec {
+	phy-reset-gpios = <&gpio3 30 0>;
+	status = "okay";
+};
+
+&i2c2 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	at24 at 52 {
+		compatible = "at,24c32";
+		pagesize = <32>;
+		reg = <0x52>;
+	};
+
+	pcf8563 at 51 {
+		compatible = "nxp,pcf8563";
+		reg = <0x51>;
+	};
+
+	lm75 at 4a {
+		compatible = "national,lm75";
+		reg = <0x4a>;
+	};
+};
+
 &nfc {
 	nand-bus-width = <8>;
 	nand-ecc-mode = "hw";
 	status = "okay";
 };
 
+&uart1 {
+	status = "okay";
+};
+
 &weim {
 	status = "okay";
 
-- 
1.8.1.5



From shc_work at mail.ru  Tue Jul  2 12:02:25 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Tue,  2 Jul 2013 20:02:25 +0400
Subject: [PATCH 2/6] ARM: dts: i.MX27: Add WEIM node
In-Reply-To: <1372780949-31897-1-git-send-email-shc_work@mail.ru>
References: <1372780949-31897-1-git-send-email-shc_work@mail.ru>
Message-ID: <1372780949-31897-2-git-send-email-shc_work@mail.ru>

This patch adds the missing (Wireless External Interface Module) WEIM
devicetree node for i.MX27 CPUs.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index 516473c..056e33b 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -443,6 +443,23 @@
 			status = "disabled";
 		};
 
+		weim: weim at d8002000 {
+			#address-cells = <2>;
+			#size-cells = <1>;
+			compatible = "fsl,imx27-weim";
+			reg = <0xd8002000 0x1000>;
+			clocks = <&clks 0>;
+			ranges = <
+				0 0 0xc0000000 0x08000000
+				1 0 0xc8000000 0x08000000
+				2 0 0xd0000000 0x02000000
+				3 0 0xd2000000 0x02000000
+				4 0 0xd4000000 0x02000000
+				5 0 0xd6000000 0x02000000
+			>;
+			status = "disabled";
+		};
+
 		iram: iram at ffff4c00 {
 			compatible = "mmio-sram";
 			reg = <0xffff4c00 0xb400>;
-- 
1.8.1.5



From shc_work at mail.ru  Tue Jul  2 12:02:26 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Tue,  2 Jul 2013 20:02:26 +0400
Subject: [PATCH 3/6] ARM: dts: imx27-phytec-phycore-som: Add WEIM node
In-Reply-To: <1372780949-31897-1-git-send-email-shc_work@mail.ru>
References: <1372780949-31897-1-git-send-email-shc_work@mail.ru>
Message-ID: <1372780949-31897-3-git-send-email-shc_work@mail.ru>

This patch adds WEIM node for Phytec PCM-038 module.
Migrate existing on-module NOR-flash as children of WEIM CS0.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27-phytec-phycore-som.dts | 23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/imx27-phytec-phycore-som.dts b/arch/arm/boot/dts/imx27-phytec-phycore-som.dts
index 76edf59..92765ee 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore-som.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycore-som.dts
@@ -52,15 +52,6 @@
 			};
 		};
 	};
-
-	nor_flash at c0000000 {
-		compatible = "cfi-flash";
-		bank-width = <2>;
-		reg = <0xc0000000 0x02000000>;
-		linux,mtd-name = "physmap-flash.0";
-		#address-cells = <1>;
-		#size-cells = <1>;
-	};
 };
 
 &cspi1 {
@@ -177,3 +168,17 @@
 	nand-ecc-mode = "hw";
 	status = "okay";
 };
+
+&weim {
+	status = "okay";
+
+	nor: nor at c0000000 {
+		compatible = "cfi-flash";
+		reg = <0 0x00000000 0x02000000>;
+		bank-width = <2>;
+		linux,mtd-name = "physmap-flash.0";
+		fsl,weim-cs-timing = <0x22c2cf00 0x75000d01 0x00000900>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+	};
+};
-- 
1.8.1.5



From festevam at gmail.com  Tue Jul  2 12:04:42 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 2 Jul 2013 13:04:42 -0300
Subject: [PATCHv2 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
In-Reply-To: <489238046.567779.1372774157223.open-xchange@email.1und1.de>
References: <1371754675-12242-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1371754675-12242-3-git-send-email-alexandre.belloni@free-electrons.com>
 <1235070882.565234.1372771759233.open-xchange@email.1und1.de>
 <CAOMZO5AASS4sr08i4K-uSUuvG+x9cjfFUtheY9JatA4dWCB0ww@mail.gmail.com>
 <489238046.567779.1372774157223.open-xchange@email.1und1.de>
Message-ID: <CAOMZO5CN614eF_YDEc92x4QY1JLc7b-BzZf-GbWFveNJE1oguw@mail.gmail.com>

On Tue, Jul 2, 2013 at 11:09 AM, Christoph G. Baumann <cb at sgoc.de> wrote:
> Hi Fabio,
>
>>
>> Differently than mx23, the mx28 reference manual states that ACK_MODE
>> bit has a default value of 1.
>>
>> Thanks for pointing this out, as we need to take this into
>> consideration for supporting mx23 in the mxs i2c driver.
>>
>
> nevertheless the mx28 I2C controller seems to suffer from this error too, as
> SMbus doesn't work with it.

Understood. Just sent a patch for this. Please help testing it.

Thanks,

Fabio Estevam


From tixy at linaro.org  Tue Jul  2 12:09:41 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Tue, 02 Jul 2013 17:09:41 +0100
Subject: [PATCH 4/4] drivers: clocksource: add CPU PM notifier for ARM
 architected timer
In-Reply-To: <1371575223-21702-5-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1371575223-21702-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1371575223-21702-5-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1372781381.3689.27.camel@linaro1.home>

On Tue, 2013-06-18 at 18:07 +0100, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> Few control settings done in architected timer as part of initialisation
> are lost when CPU enters deeper power states. They need to be re-initialised
> when the CPU is (warm)reset again.
> 
> This patch moves all such initialisation into separate function that can
> be used both in cold and warm CPU reset paths. It also adds CPU PM
> notifiers to do the timer initialisation on warm resets.
> 
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> Reviewed-by: Will Deacon <will.deacon at arm.com>
> ---
>  drivers/clocksource/arm_arch_timer.c | 51 +++++++++++++++++++++++++++++++-----
>  1 file changed, 44 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 11aaf06..1c691b1 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -13,6 +13,7 @@
>  #include <linux/device.h>
>  #include <linux/smp.h>
>  #include <linux/cpu.h>
> +#include <linux/cpu_pm.h>
>  #include <linux/clockchips.h>
>  #include <linux/interrupt.h>
>  #include <linux/of_irq.h>
> @@ -123,10 +124,20 @@ static int arch_timer_set_next_event_phys(unsigned long evt,
>  	return 0;
>  }
>  
> -static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
> +static void arch_timer_initialise(void)
>  {
>  	int evt_stream_div, pos;
>  
> +	/* Find the closest power of two to the divisor */
> +	evt_stream_div = arch_timer_rate / ARCH_TIMER_EVT_STREAM_FREQ;
> +	pos = fls(evt_stream_div);
> +	if (pos > 1 && !(evt_stream_div & (1 << (pos - 2))))
> +		pos--;
> +	arch_counter_set_user_access(min(pos, 15));

Would it not be good to calculate the value once in arch_timer_setup
rather than repeatedly in this function? The calculations aren't that
expensive, but when I gave these patches a spin on TC2 I noticed that
this function gets called >500 times a second, so it seems a bit
wasteful.

> +}
> +
> +static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
> +{
>  	clk->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP;
>  	clk->name = "arch_sys_timer";
>  	clk->rating = 450;
> @@ -155,12 +166,7 @@ static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
>  			enable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI], 0);
>  	}
>  
> -	/* Find the closest power of two to the divisor */
> -	evt_stream_div = arch_timer_rate / ARCH_TIMER_EVT_STREAM_FREQ;
> -	pos = fls(evt_stream_div);
> -	if (pos > 1 && !(evt_stream_div & (1 << (pos - 2))))
> -		pos--;
> -	arch_counter_set_user_access(min(pos, 15));
> +	arch_timer_initialise();
>  
>  	return 0;
>  }
> @@ -267,6 +273,31 @@ static struct notifier_block arch_timer_cpu_nb __cpuinitdata = {
>  	.notifier_call = arch_timer_cpu_notify,
>  };
>  
> +#ifdef CONFIG_CPU_PM
> +static int arch_timer_cpu_pm_notify(struct notifier_block *self,
> +				    unsigned long action, void *hcpu)
> +{
> +	if (action == CPU_PM_EXIT)
> +		arch_timer_initialise();
> +
> +	return NOTIFY_OK;
> +}
> +
> +static struct notifier_block arch_timer_cpu_pm_notifier = {
> +	.notifier_call = arch_timer_cpu_pm_notify,
> +};
> +
> +static int __init arch_timer_cpu_pm_init(void)
> +{
> +	return cpu_pm_register_notifier(&arch_timer_cpu_pm_notifier);
> +}
> +#else
> +static int __init arch_timer_cpu_pm_init(void)
> +{
> +	return 0;
> +}
> +#endif
> +
>  static int __init arch_timer_register(void)
>  {
>  	int err;
> @@ -316,11 +347,17 @@ static int __init arch_timer_register(void)
>  	if (err)
>  		goto out_free_irq;
>  
> +	err = arch_timer_cpu_pm_init();
> +	if (err)
> +		goto out_unreg_notify;
> +
>  	/* Immediately configure the timer on the boot CPU */
>  	arch_timer_setup(this_cpu_ptr(arch_timer_evt));
>  
>  	return 0;
>  
> +out_unreg_notify:
> +	unregister_cpu_notifier(&arch_timer_cpu_nb);
>  out_free_irq:
>  	if (arch_timer_use_virtual)
>  		free_percpu_irq(arch_timer_ppi[VIRT_PPI], arch_timer_evt);

-- 
Tixy



From shc_work at mail.ru  Tue Jul  2 12:27:49 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Tue, 02 Jul 2013 20:27:49 +0400
Subject: =?UTF-8?B?UmU6IFtQQVRDSCB2MyA1LzVdIEFSTTogZHRzOiBBZGQgZGV2aWNlIHRyZWUg?=
 =?UTF-8?B?c3VwcG9ydCBmb3IgcGh5Y2FyZCBwY2ExMDA=?=
In-Reply-To: <1372431037-13519-6-git-send-email-mpa@pengutronix.de>
References: <1372431037-13519-1-git-send-email-mpa@pengutronix.de>
 <1372431037-13519-6-git-send-email-mpa@pengutronix.de>
Message-ID: <1372782469.486055292@f129.mail.ru>

> Board files for Phytec phyCARD-S "System on Module" and "Rapid
> Development Kit".
> 
> Based on patches from:
> 
> Steffen Trumtrar <s.trumtrar at pengutronix.de>:
>  - Original patch
>  - ARM: dts: Set partition offsets for phycard
>  - ARM: dts: Use CSPI1 instead of CSPI2 on phycard pca100
>  - ARM: imx27-phytec-phycard-S.dts: resize nand partitions
...
> diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
...
> +&i2c1 {
> +	status = "okay";
> +
> +	ioexpander at 41 {
> +		compatible = "nxp,pca9536";
> +		reg = <0x41>;
> +	};
> +
> +	rtc at 51 {
> +		compatible = "nxp,pcf8563";
> +		reg = <0x51>;
> +	};
> +};
> +
> +&i2c2 {
> +	status = "okay";
> +
> +	lm75 at 4a {
> +		compatible = "national,lm75";
> +		reg = <0x4a>;
> +	};
> +
> +	rtc at 51 {
> +		compatible = "nxp,pcf8563";
> +		reg = <0x51>;
> +	};

Really two identical RTC on I2C1 & I2C2 or it is typo?

---

From marex at denx.de  Tue Jul  2 12:33:04 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 2 Jul 2013 18:33:04 +0200
Subject: [PATCHv3 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
In-Reply-To: <51D2DE5B.9060309@free-electrons.com>
References: <1372094699-3832-1-git-send-email-alexandre.belloni@free-electrons.com>
 <51D2BEA1.6010206@free-electrons.com> <51D2DE5B.9060309@free-electrons.com>
Message-ID: <201307021833.04282.marex@denx.de>

Dear Alexandre Belloni,

> On 02/07/2013 13:50, Alexandre Belloni wrote:
> > On 02/07/2013 13:45, Fabio Estevam wrote:
> >> Shouldn't this be
> >> 
> >>          i2c at 1 {
> >>          
> >>                  reg = <1>; ?
> > 
> > No, we have 4 devices on that mux and 2 pins to select the muxing.
> 
> OK, got it working.
> 
> So, the results:
> 
> bitbanging:
> 
> # time cat /sys/bus/iio/devices/iio\:device1/in_voltage0_raw
> 2637
> real	0m 0.09s
> user	0m 0.01s
> sys	0m 0.01s
> 
> 
> i2c-mxs PIO mode:
> 
> # time cat /sys/bus/iio/devices/iio\:device1/in_voltage0_raw
> [   35.007650] [sched_delayed] sched: RT throttling activated
> 2627
> real	0m 7.14s
> user	0m 0.02s
> sys	0m 0.01s
> 
> 
> i2c-mxs PIO mode without LRADC:
> 
> # time cat /sys/bus/iio/devices/iio\:device1/in_voltage0_raw
> [   18.007432] [sched_delayed] sched: RT throttling activated
> 2629
> real	0m 7.09s
> user	0m 0.00s
> sys	0m 0.03s
> 
> 
> i2c-mxs DMA mode:
> 
> # time cat /sys/bus/iio/devices/iio\:device1/in_voltage0_raw
> 2631
> real	0m 0.12s
> user	0m 0.01s
> sys	0m 0.01s
> 
> 
> It seems fine for me.

I think I'm getting a little lost in these gazilions of i2c and lradc threads. 
Can we not create one thread and keep the related stuff in there instead of 
discussing it all around !?

Only one question comes to mind with this email -- what do LRADC and I2C have to 
do with each other here ?

It'd be nice if someone could summarize on what I should focus and possibly 
prepare a testcase.

Best regards,
Marek Vasut


From mturquette at linaro.org  Tue Jul  2 12:35:01 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 02 Jul 2013 09:35:01 -0700
Subject: [GIT PULL] Initial OLPC XO-1.75/XO-4 support
In-Reply-To: <CAMLZHHQu_UUQvT1db7hL2XYX=EzwNaGjyeTuZkwfYHJmG5BUdA@mail.gmail.com>
References: <20130702031244.B2D74FAAD2@dev.laptop.org>
 <20130702045304.GA27829@quad.lixom.net>
 <CAMLZHHQu_UUQvT1db7hL2XYX=EzwNaGjyeTuZkwfYHJmG5BUdA@mail.gmail.com>
Message-ID: <20130702163501.10823.57484@quantum>

Quoting Daniel Drake (2013-07-02 07:26:22)
> On Mon, Jul 1, 2013 at 10:53 PM, Olof Johansson <olof at lixom.net> wrote:
> > 1) Please post the drivers/clk patches to mturquette. THey don't look dependent
> >    on the rest of the patches, just general improvements and cleanups.
> > 2) I really wish there was a generic catch-all compat for the boards, so we
> >    didn't have to modify mmp2-dt.c for every new board added -- it really
> >    defies the purpose of only changing the data you pass into the kernel. This
> >    is mostly something for Eric/Haojian to sort out though.
> > 3) Please post the patches as a series instead of a pull request, given that
> >    they should probably take different paths up the tree (clk vs the platform,
> >    etc). You should at least get review/acked-by of the clk pieces from Mike
> >    Turquette.
> 
> Thanks for the suggestions. I have already posted the patches as
> emails a little more than 2 weeks ago, including sending the clock
> ones to Mike. I will resend next week if they are still pending, when
> the maintainers might be a bit less busy.

I saw the MMP patches but they were too late for me to take into
clk-next towards 3.11. When this happens I usually email the patch
author privately and let them know that I will take a look after the
merge window but I forgot to send you that email.

Regards,
Mike

> 
> cheers
> Daniel


From bhelgaas at google.com  Tue Jul  2 13:14:01 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Tue, 2 Jul 2013 11:14:01 -0600
Subject: [PATCHv4 02/11] pci: use weak functions for MSI arch-specific
 functions
In-Reply-To: <20130702073037.55a53642@skate>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-3-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372726396.17904.1.camel@concordia> <20130702073037.55a53642@skate>
Message-ID: <CAErSpo5NuwC5cWiWxOb0c3tO47SPBcbW3Vx5vMu=cCu2m4vYLw@mail.gmail.com>

On Mon, Jul 1, 2013 at 11:30 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Dear Michael Ellerman,
>
> On Tue, 02 Jul 2013 10:53:16 +1000, Michael Ellerman wrote:
>> On Mon, 2013-07-01 at 15:42 +0200, Thomas Petazzoni wrote:
>> > Until now, the MSI architecture-specific functions could be overloaded
>> > using a fairly complex set of #define and compile-time
>> > conditionals. In order to prepare for the introduction of the msi_chip
>> > infrastructure, it is desirable to switch all those functions to use
>> > the 'weak' mechanism. This commit converts all the architectures that
>> > were overidding those MSI functions to use the new strategy.
>>
>> The MSI code used to use weak functions, until we discovered they were
>> being miscompiled on some toolchains (11df1f0). I assume these days
>> we're confident they work correctly.
>
> Hum, interesting. I see from your commit that gcc 4.3.2 was apparently
> affected, and gcc 4.3.x is not /that/ old. Bjorn, what's your point of
> view on this?

There *were* compilation issues with weak functions, but AFAIK they've
been resolved and there's no reason to avoid them.  Commit f9d142500
addressed this.

Bjorn


From alexandre.belloni at free-electrons.com  Tue Jul  2 13:15:49 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Tue, 02 Jul 2013 19:15:49 +0200
Subject: [PATCHv3 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
In-Reply-To: <201307021833.04282.marex@denx.de>
References: <1372094699-3832-1-git-send-email-alexandre.belloni@free-electrons.com>
 <51D2BEA1.6010206@free-electrons.com> <51D2DE5B.9060309@free-electrons.com>
 <201307021833.04282.marex@denx.de>
Message-ID: <51D30AC5.9000701@free-electrons.com>

On 02/07/2013 18:33, Marek Vasut wrote:
> Dear Alexandre Belloni,
> 
>> On 02/07/2013 13:50, Alexandre Belloni wrote:
>>> On 02/07/2013 13:45, Fabio Estevam wrote:
>>>> Shouldn't this be
>>>>
>>>>          i2c at 1 {
>>>>          
>>>>                  reg = <1>; ?
>>>
>>> No, we have 4 devices on that mux and 2 pins to select the muxing.
>>
>> OK, got it working.
>>
>> So, the results:
>>
>> bitbanging:
>>
>> # time cat /sys/bus/iio/devices/iio\:device1/in_voltage0_raw
>> 2637
>> real	0m 0.09s
>> user	0m 0.01s
>> sys	0m 0.01s
>>
>>
>> i2c-mxs PIO mode:
>>
>> # time cat /sys/bus/iio/devices/iio\:device1/in_voltage0_raw
>> [   35.007650] [sched_delayed] sched: RT throttling activated
>> 2627
>> real	0m 7.14s
>> user	0m 0.02s
>> sys	0m 0.01s
>>
>>
>> i2c-mxs PIO mode without LRADC:
>>
>> # time cat /sys/bus/iio/devices/iio\:device1/in_voltage0_raw
>> [   18.007432] [sched_delayed] sched: RT throttling activated
>> 2629
>> real	0m 7.09s
>> user	0m 0.00s
>> sys	0m 0.03s
>>
>>
>> i2c-mxs DMA mode:
>>
>> # time cat /sys/bus/iio/devices/iio\:device1/in_voltage0_raw
>> 2631
>> real	0m 0.12s
>> user	0m 0.01s
>> sys	0m 0.01s
>>
>>
>> It seems fine for me.
> 
> I think I'm getting a little lost in these gazilions of i2c and lradc threads. 
> Can we not create one thread and keep the related stuff in there instead of 
> discussing it all around !?
> 
> Only one question comes to mind with this email -- what do LRADC and I2C have to 
> do with each other here ?
> 

Yeah, sorry, I meant the lradc touchscreen support. This seemed to
trigger the issue for Fabio but as my testing shows, this is not the
case for me, I get the issue with PIO, whether the lradc touchscreen
support is activated or not.

I think Torsten is the one that investigated it the most :

http://www.spinics.net/lists/linux-i2c/msg12619.html


> It'd be nice if someone could summarize on what I should focus and possibly 
> prepare a testcase.
> 

On my setup, it happens on every i2c read that are done in PIO mode.
But, my setup may be a bit unconventional as we are using a i2c gpio muxer.

Regards,

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From catalin.marinas at arm.com  Tue Jul  2 13:15:31 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 2 Jul 2013 18:15:31 +0100
Subject: [PATCH v2] ARM: LPAE: don't reject mapping /dev/mem above 4GB
In-Reply-To: <1372780685-2528-1-git-send-email-dserrg@gmail.com>
References: <1372780685-2528-1-git-send-email-dserrg@gmail.com>
Message-ID: <20130702171530.GG24828@arm.com>

On Tue, Jul 02, 2013 at 04:58:05PM +0100, Sergey Dyasly wrote:
> With LPAE enabled, physical address space is larger than 4GB. Allow mapping any
> part of it via /dev/mem by utilizing the same check as in arm64.
> 
> PHYS_MASK covers 40 bits with LPAE enabled and 32 bits otherwise.
> 
> Signed-off-by: Sergey Dyasly <dserrg at gmail.com>
> ---
> 
> v2:
> - Removed #ifdef and changed original function as suggested by Catalin Marinas
> 
>  arch/arm/mm/mmap.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
> index 10062ce..09bab92 100644
> --- a/arch/arm/mm/mmap.c
> +++ b/arch/arm/mm/mmap.c
> @@ -204,13 +204,11 @@ int valid_phys_addr_range(phys_addr_t addr, size_t size)
>  }
>  
>  /*
> - * We don't use supersection mappings for mmap() on /dev/mem, which
> - * means that we can't map the memory area above the 4G barrier into
> - * userspace.
> + * Do not allow /dev/mem mappings beyond the supported physical range.
>   */
>  int valid_mmap_phys_addr_range(unsigned long pfn, size_t size)
>  {
> -	return !(pfn + (size >> PAGE_SHIFT) > 0x00100000);
> +	return !(((pfn << PAGE_SHIFT) + size) & ~PHYS_MASK);

I don't think that's what I suggested. For classic MMU ~PHYS_MASK is 0.

-- 
Catalin


From stern at rowland.harvard.edu  Tue Jul  2 13:17:58 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 2 Jul 2013 13:17:58 -0400 (EDT)
Subject: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during
 bus suspend
In-Reply-To: <51D28DB9.704@ti.com>
Message-ID: <Pine.LNX.4.44L0.1307021302430.1086-100000@iolanthe.rowland.org>

On Tue, 2 Jul 2013, Roger Quadros wrote:

> On 07/02/2013 12:01 AM, Alan Stern wrote:
> > On Mon, 1 Jul 2013, Felipe Balbi wrote:
> > 
> >>> I don't know what Pad wakeup is.  The wakeup signal has to originate 
> >>> from the EHCI controller, doesn't it?  If not, how does the Pad know 
> >>> when a wakeup is needed?
> >>
> >> That's really an OMAP thing, I guess. Pad wakeup sits in the PRCM (IIRC)
> >> inside and always on power domain. EHCI sits in another power domain
> >> which be turned off. When it's turned off (power gated and clock gated)
> >> the EHCI block has no means to wakeup whatsoever. That's when pad wakeup
> >> comes into play. It is generated when PRCM sees a change in the actual
> >> pad of the die. To check who should 'own' the wakeup, it checks the
> >> muxing settings to verify whose pad is that.
> > 
> > How does the PRCM know which changes should generate wakeup events?  
> 
> It doesn't know. It will always generate a wakeup on any change in the monitored pins.
> We can only configure which pins we want to monitor.
> So we can't choose which wakeup events we want to monitor. We just can
> enable or disable all events.
> 
> > In the EHCI controller, this is managed by the settings of the WKOC_E,
> > WKDSCNNT_E, and WKCNNT_E bits in the PORTSC registers.  But if EHCI is
> > powered off, those bits can't be used.
> 
> Is "powered off" same as ehci_suspend? If yes then how does it work on other systems
> for remote wakeup?

Above, Felipe wrote that on OMAP, EHCI sits in a power domain which is
turned off: power gated and clock gated.  ehci_suspend() doesn't do
those things, but they are what I was referring to.

A PCI-based EHCI controller has two power sources: the core well (which
is turned off during suspend) and the auxiliary well (which remains
powered).  That's how remote wakeup works; it uses the auxiliary well.

> > Also, once the wakeup signal has been turned on, how does it get turned 
> > off again?
> 
> That is taken care of by the OMAP pinctrl driver. It will always turn off the
> wakeup signal once the event is detected and forwarded as an IRQ.
> 
> I know that all this is a bit ugly :(.

I still a little confused.  The wakeup signal turns on.  Then the
pinctrl driver sees it, forwards it as an IRQ, and turns the wakeup
signal off.  But what if the IRQ is disabled (as it would be with your
patch)?  Does the IRQ line remain active until it causes an interrupt?  
What eventually turns off the IRQ line?

Alan Stern



From khilman at linaro.org  Tue Jul  2 13:20:00 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Tue, 02 Jul 2013 10:20:00 -0700
Subject: [PATCH] USB: OHCI: make ohci-da8xx a separate driver
In-Reply-To: <CAJFYCKErW5hvgBvKiywHmf0eBYOix8Fkn9vQFa-TKHA63hX7aQ@mail.gmail.com>
References: <1372765019-7191-1-git-send-email-manjunath.goudar@linaro.org>
 <51D2E8A0.1080102@cogentembedded.com>
 <CAJFYCKErW5hvgBvKiywHmf0eBYOix8Fkn9vQFa-TKHA63hX7aQ@mail.gmail.com>
Message-ID: <51D30BC0.9090108@linaro.org>

On 07/02/2013 08:14 AM, Manjunath Goudar wrote:
> 
> 
> On 2 July 2013 20:20, Sergei Shtylyov
> <sergei.shtylyov at cogentembedded.com
> <mailto:sergei.shtylyov at cogentembedded.com>> wrote:
> 
>     Hello.
> 
> 
>     On 02-07-2013 15:36, Manjunath Goudar wrote:
> 
>         Separate the Davinci OHCI host controller driver from ohci-hcd
>         host code so that it can be built as a separate driver module.
>         This work is part of enabling multi-platform kernels on ARM;
>         it would be nice to have in 3.11.
> 
> 
>         One preexisting error:
>         "da8xx_syscfg0_base" [drivers/usb/host/ohci-da8xx.__ko] undefined!
> 
> 
>         Fixed eventually using below modification:
>         added EXPORT_SYMBOL_GPL(da8xx___syscfg0_base) in
>         arch/arm/mach-davinci/devices-__da8xx.c.
> 
> 
>        And you managed to get this fix into the DaVinci tree? I tried it
>     long ago and it was refused by then DaVinci maintainer Kevin Hilman.
> 
> 
> Yes I saw your patch that is what I mentioned in patch description.
> We will wait for DaVinci maintainer response,what he will suggest. 

Note that Sekhar Nori (now Cc'd) is the primary maintainer of davinci,
and I'll defer the final decision to him.  However, the mach-davinci
change is not in this patch, so I'm not sure exactly how it relates
here, since that problem exists independently of this patch.

That being said, I will NAK the above EXPORT_SYMBOL change in
mach-davinci code because passing data between platform code and drivers
via global variables is still a bad idea.  Some helper accessor
functions will need to be created to abstract those low-level accesses.

>         Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org
>         <mailto:manjunath.goudar at linaro.org>>
>         Cc: Arnd Bergmann <arnd at arndb.de <mailto:arnd at arndb.de>>
>         Cc: Alan Stern <stern at rowland.harvard.edu
>         <mailto:stern at rowland.harvard.edu>>
>         Cc: Sergei Shtylyov <sshtylyov at ru.mvista.com
>         <mailto:sshtylyov at ru.mvista.com>>
>         Cc: Kevin Hilman <kjh at hilman.org <mailto:kjh at hilman.org>>

Also, please khilman at linaro.org instead of my personal address.  Thanks,

Kevin



From arno at natisbad.org  Tue Jul  2 13:21:52 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Tue, 02 Jul 2013 19:21:52 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net>
Message-ID: <87vc4sho7j.fsf@natisbad.org>

Hi,

Jason Cooper <jason at lakedaemon.net> writes:

>>  - G762 PWM fan controller on I2C bus: it requires G762 driver which
>>    is *currently sitting in hwmon maintainer tree* and will be available
>>    in 3.11. Jason, as a side note I have a short patch for available for
>>    ReadyNAS Duo v2 .dts file (the device also has a G762). I can hold
>>    it until rc cycle if you prefer.
>
> Nope, post patches when you have them ready.  I am capable of holding
> them until -rc1 drops ;-)

That's the one I sent yesterday (the patch tagged RESEND, i.e. w/o the
fixes for space issue in .dts file)


>> Jason, the tests were done against your for-next branch (with all the
>> fixes which accumulated in Linux tree from rc7). I will work directly
>> against Linus tree as soon as the rc- cycle for 3.11 starts. 
>
> hmmm, my latest for-next (20130623) is based against v3.10-rc7, are you
> using that?


Yes, but with just your tree I got some freezes during boot and applying
the additional commits available in Linux tree, this fixed the issue. I
did not spend much the time but I think this is related to
PJ4B_ERRATA_4742 which you do not have in your for-next branch: 

commit 3e0a07f8c401bb43e0f964c5f1285b2cb2028645
Author: Gregory CLEMENT <gregory.clement at free-electrons.com>
Date:   Sun Jun 23 10:17:11 2013 +0100

    ARM: 7773/1: PJ4B: Add support for errata 4742
    
    This commit fixes the regression on Armada 370 (the kernal hang during
    boot) introduced by the commit: "ARM: 7691/1: mm: kill unused
    TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead".

    ...


>>  [snip]
>>
>> +
>> +			/* Waiting for NAND support to appear in armada-370.dtsi
>
> I would just leave this out until we get the driver sorted.

ok, will do that in next versions.


>> +			i2c at 11000 {
>> +				compatible = "marvell,mv64xxx-i2c";
>> +				clock-frequency = <100000>;
>> +				status = "okay";
>> +
>> +				isl12057: isl12057 at 68 {
>> +					compatible = "isil,isl12057";
>> +					reg = <0x68>;
>> +					wakeup-source;
>> +				};

My main question is for ISL12057 RTC chip: I guess it's just pointless to
push the .dts file for the RN102 w/o a working RTC clock?

Cheers,

a+


From arno at natisbad.org  Tue Jul  2 13:22:34 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Tue, 02 Jul 2013 19:22:34 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net>
 <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
Message-ID: <87obakho6d.fsf@natisbad.org>

Hi,

Jason Cooper <jason at lakedaemon.net> writes:

>> The big problem is that the Armada 370 and Armada XP datasheets are
>> still only available under NDA, so it's quite hard for someone to step
>> up and do this, without access to those datasheets.
>
> bummer.
>
>> It used to be on our TODO-list, but isn't any longer, and I have no
>> informations about when it will re-appear on our TODO-list at this
>> point.
>
> So, Arnaud, how do you feel about tackling the nand driver based on the
> sources you have and the pointers above?

Sadly, I do not have enough spare time to work on this: at the moment, I
intend to focus on writing a clean driver for ISL 12057 RTC/Alarm chip
and get it accepted for 3.12.

Cheers,

a+


From Sudeep.KarkadaNagesha at arm.com  Tue Jul  2 13:24:31 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Tue, 02 Jul 2013 18:24:31 +0100
Subject: [PATCH 4/4] drivers: clocksource: add CPU PM notifier for ARM
 architected timer
In-Reply-To: <1372781381.3689.27.camel@linaro1.home>
References: <1371575223-21702-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1371575223-21702-5-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1372781381.3689.27.camel@linaro1.home>
Message-ID: <51D30CCF.5020808@arm.com>

On 02/07/13 17:09, Jon Medhurst (Tixy) wrote:
> On Tue, 2013-06-18 at 18:07 +0100, Sudeep KarkadaNagesha wrote:
>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>>
>> Few control settings done in architected timer as part of initialisation
>> are lost when CPU enters deeper power states. They need to be re-initialised
>> when the CPU is (warm)reset again.
>>
>> This patch moves all such initialisation into separate function that can
>> be used both in cold and warm CPU reset paths. It also adds CPU PM
>> notifiers to do the timer initialisation on warm resets.
>>
>> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
>> Reviewed-by: Will Deacon <will.deacon at arm.com>
>> ---
>>  drivers/clocksource/arm_arch_timer.c | 51 +++++++++++++++++++++++++++++++-----
>>  1 file changed, 44 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>> index 11aaf06..1c691b1 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -13,6 +13,7 @@
>>  #include <linux/device.h>
>>  #include <linux/smp.h>
>>  #include <linux/cpu.h>
>> +#include <linux/cpu_pm.h>
>>  #include <linux/clockchips.h>
>>  #include <linux/interrupt.h>
>>  #include <linux/of_irq.h>
>> @@ -123,10 +124,20 @@ static int arch_timer_set_next_event_phys(unsigned long evt,
>>  	return 0;
>>  }
>>  
>> -static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
>> +static void arch_timer_initialise(void)
>>  {
>>  	int evt_stream_div, pos;
>>  
>> +	/* Find the closest power of two to the divisor */
>> +	evt_stream_div = arch_timer_rate / ARCH_TIMER_EVT_STREAM_FREQ;
>> +	pos = fls(evt_stream_div);
>> +	if (pos > 1 && !(evt_stream_div & (1 << (pos - 2))))
>> +		pos--;
>> +	arch_counter_set_user_access(min(pos, 15));
> 
> Would it not be good to calculate the value once in arch_timer_setup
> rather than repeatedly in this function? The calculations aren't that
> expensive, but when I gave these patches a spin on TC2 I noticed that
> this function gets called >500 times a second, so it seems a bit
> wasteful.
> 
Makes sense, will save the divider and re-use it.

Regards,
Sudeep




From jason at lakedaemon.net  Tue Jul  2 13:38:21 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 2 Jul 2013 13:38:21 -0400
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <87vc4sho7j.fsf@natisbad.org>
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net>
 <87vc4sho7j.fsf@natisbad.org>
Message-ID: <20130702173821.GE17110@titan.lakedaemon.net>

On Tue, Jul 02, 2013 at 07:21:52PM +0200, Arnaud Ebalard wrote:
> Jason Cooper <jason at lakedaemon.net> writes:
> 
> >>  - G762 PWM fan controller on I2C bus: it requires G762 driver which
> >>    is *currently sitting in hwmon maintainer tree* and will be available
> >>    in 3.11. Jason, as a side note I have a short patch for available for
> >>    ReadyNAS Duo v2 .dts file (the device also has a G762). I can hold
> >>    it until rc cycle if you prefer.
> >
> > Nope, post patches when you have them ready.  I am capable of holding
> > them until -rc1 drops ;-)
> 
> That's the one I sent yesterday (the patch tagged RESEND, i.e. w/o the
> fixes for space issue in .dts file)

Yep, I have it queued up.

> >> +			i2c at 11000 {
> >> +				compatible = "marvell,mv64xxx-i2c";
> >> +				clock-frequency = <100000>;
> >> +				status = "okay";
> >> +
> >> +				isl12057: isl12057 at 68 {
> >> +					compatible = "isil,isl12057";
> >> +					reg = <0x68>;
> >> +					wakeup-source;
> >> +				};
> 
> My main question is for ISL12057 RTC chip: I guess it's just pointless to
> push the .dts file for the RN102 w/o a working RTC clock?

Not necessarily.  Support for the rtc can be done in a follow on patch
once you have the driver mainlined.

I have a bunch of boards that boot up and think it's 1970...

Afterall, the mirabox doesn't have nand support :-P

thx,

Jason.


From santosh.shilimkar at ti.com  Tue Jul  2 13:38:20 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 2 Jul 2013 13:38:20 -0400
Subject: [RFC PATCH 5/6] ARM, mm: change meaning of max_low_pfn to maximum
 pfn for nobootmem
In-Reply-To: <20130701170941.GC24642@n2100.arm.linux.org.uk>
References: <1364184674-13798-1-git-send-email-iamjoonsoo.kim@lge.com>
 <1364184674-13798-6-git-send-email-iamjoonsoo.kim@lge.com>
 <51D18ED5.50103@ti.com> <20130701170941.GC24642@n2100.arm.linux.org.uk>
Message-ID: <51D3100C.6010209@ti.com>

On Monday 01 July 2013 01:09 PM, Russell King - ARM Linux wrote:
> On Mon, Jul 01, 2013 at 10:14:45AM -0400, Santosh Shilimkar wrote:
>> I have been also carrying similar patch as yours in an attempt
>> to make LPAE kernel work on ARM. Your patch carries better
>> description, so will your version and include in my series
>> which I plan to post on the list after some more testing.
>> Will copy you. The changes are very similar to your series.
> 
> And will you try to investigate and/or address my concerns with this
> change?
> 
Sure. Will try to look and come back to you. 

Regards,
Santosh 



From jason at lakedaemon.net  Tue Jul  2 13:41:11 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 2 Jul 2013 13:41:11 -0400
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <87obakho6d.fsf@natisbad.org>
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net>
 <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org>
Message-ID: <20130702174111.GF17110@titan.lakedaemon.net>

On Tue, Jul 02, 2013 at 07:22:34PM +0200, Arnaud Ebalard wrote:
> Hi,
> 
> Jason Cooper <jason at lakedaemon.net> writes:
> 
> >> The big problem is that the Armada 370 and Armada XP datasheets are
> >> still only available under NDA, so it's quite hard for someone to step
> >> up and do this, without access to those datasheets.
> >
> > bummer.
> >
> >> It used to be on our TODO-list, but isn't any longer, and I have no
> >> informations about when it will re-appear on our TODO-list at this
> >> point.
> >
> > So, Arnaud, how do you feel about tackling the nand driver based on the
> > sources you have and the pointers above?
> 
> Sadly, I do not have enough spare time to work on this: at the moment, I
> intend to focus on writing a clean driver for ISL 12057 RTC/Alarm chip
> and get it accepted for 3.12.

more bummer.  Willy, mind posting what you have?  Arnaud, do you have a
link to the source code for your device?  And have you found the code
they started with?

thx,

Jason.


From paul.gortmaker at windriver.com  Tue Jul  2 13:53:00 2013
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Tue, 2 Jul 2013 13:53:00 -0400
Subject: [PATCH 07/32] arm: delete __cpuinit/__CPUINIT usage from all ARM
 users
In-Reply-To: <20130702085818.GD24642@n2100.arm.linux.org.uk>
References: <1372102237-8757-1-git-send-email-paul.gortmaker@windriver.com>
 <1372102237-8757-8-git-send-email-paul.gortmaker@windriver.com>
 <1372755120.2874.18.camel@jlo-ubuntu-64.nvidia.com>
 <20130702085818.GD24642@n2100.arm.linux.org.uk>
Message-ID: <20130702175257.GC21817@windriver.com>

[Re: [PATCH 07/32] arm: delete __cpuinit/__CPUINIT usage from all ARM users] On 02/07/2013 (Tue 09:58) Russell King - ARM Linux wrote:

> On Tue, Jul 02, 2013 at 04:52:00PM +0800, Joseph Lo wrote:
> > I just tested this series on Tegra platform. It looks broken CPU hotplug
> > function for Tegra at least. The CPU can't plug-in after unplugging. And
> > the system resume function also not working when "enable_nonboot_cpus".
> > 
> > Both of the issue cause system hang up. Are we missing something for
> > __cpuinit removal work?
> 
> Check that any assembly code you're using where the __CPUINIT* marker has
> been removed is not preceded by an __INIT or similar.   This code needs
> to end up in the normal .text, .data or .bss sections now.

Yes, As Russell says it is entirely possible that the earlier section
was __INIT and there was already a missing __FINIT (or .previous).

Hence what was __cpuinit got grandfathered into __INIT instead of
.text/.data/.bss

I'm offline at the moment but will double check myself later this
evening if nothing obvious has been found by then.

Thanks,
Paul.
--


From ville.syrjala at linux.intel.com  Tue Jul  2 14:01:55 2013
From: ville.syrjala at linux.intel.com (Ville =?iso-8859-1?Q?Syrj=E4l=E4?=)
Date: Tue, 2 Jul 2013 21:01:55 +0300
Subject: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver
In-Reply-To: <CAKMK7uFcsbxciq-J_HLCm61kOtGpeAK0Tg2=2AOWSa9YYc4TeA@mail.gmail.com>
References: <20130629225210.GF3353@n2100.arm.linux.org.uk>
 <E1Ut41C-0000wl-Ff@rmk-PC.arm.linux.org.uk>
 <20130630115941.GG18285@phenom.ffwll.local>
 <20130630125238.GH3353@n2100.arm.linux.org.uk>
 <CAKMK7uFcsbxciq-J_HLCm61kOtGpeAK0Tg2=2AOWSa9YYc4TeA@mail.gmail.com>
Message-ID: <20130702180155.GP5004@intel.com>

On Sun, Jun 30, 2013 at 07:29:27PM +0200, Daniel Vetter wrote:
> On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Sun, Jun 30, 2013 at 01:59:41PM +0200, Daniel Vetter wrote:
> >> On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
> >> > +static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc)
> >> > +{
> >> > +   struct drm_display_mode *adj = &dcrtc->crtc.mode;
> >> > +   uint32_t val = 0;
> >> > +
> >> > +   if (dcrtc->csc_yuv_mode == CSC_YUV_CCIR709)
> >> > +           val |= CFG_CSC_YUV_CCIR709;
> >> > +   if (dcrtc->csc_rgb_mode == CSC_RGB_STUDIO)
> >> > +           val |= CFG_CSC_RGB_STUDIO;
> >> > +
> >> > +   /*
> >> > +    * In auto mode, set the colorimetry, based upon the HDMI spec.
> >> > +    * 1280x720p, 1920x1080p and 1920x1080i use ITU709, others use
> >> > +    * ITU601.  It may be more appropriate to set this depending on
> >> > +    * the source - but what if the graphic frame is YUV and the
> >> > +    * video frame is RGB?
> >> > +    */
> >> > +   if ((adj->hdisplay == 1280 && adj->vdisplay == 720 &&
> >> > +        !(adj->flags & DRM_MODE_FLAG_INTERLACE)) ||
> >> > +       (adj->hdisplay == 1920 && adj->vdisplay == 1080)) {
> >> > +           if (dcrtc->csc_yuv_mode == CSC_AUTO)
> >> > +                   val |= CFG_CSC_YUV_CCIR709;
> >> > +   }
> >> > +
> >> > +   /*
> >> > +    * We assume we're connected to a TV-like device, so the YUV->RGB
> >> > +    * conversion should produce a limited range.  We should set this
> >> > +    * depending on the connectors attached to this CRTC, and what
> >> > +    * kind of device they report being connected.
> >> > +    */
> >> > +   if (dcrtc->csc_rgb_mode == CSC_AUTO)
> >> > +           val |= CFG_CSC_RGB_STUDIO;
> >>
> >> In the intel driver we check whether it's an cea mode with
> >> drm_match_cea_mode, e.g. in intel_hdmi.c:
> >>
> >>       if (intel_hdmi->color_range_auto) {
> >>               /* See CEA-861-E - 5.1 Default Encoding Parameters */
> >>               if (intel_hdmi->has_hdmi_sink &&
> >>                   drm_match_cea_mode(adjusted_mode) > 1)
> >>                       intel_hdmi->color_range = HDMI_COLOR_RANGE_16_235;
> >>               else
> >>                       intel_hdmi->color_range = 0;
> >>       }
> >>
> >> (The color_range gets then propageted to the right place since different
> >> platforms have different ways to do that in intel hw).
> >
> > Unfortunately, this disagrees with the HDMI v1.3a specification:
> >
> > | Default Colorimetry
> > |
> > | ...
> > |
> > | 480p, 480i, 576p, 576i, 240p and 288p
> > |
> > | The default colorimetry for all 480-line, 576-line, 240-line, and 288-line
> > | video formats described in CEA-861-D is based on SMPTE 170M.
> > |
> > | 1080i, 1080p and 720p
> > |
> > | The default colorimetry for high-definition video formats (1080i, 1080p and
> > | 720p) described in CEA-861-D is based on ITU-R BT.709-5.

I think this was pretty much copy pasted from CEA-861-D which is very
vague.

CEA-861-E is a bit better, and more clearly states that if the sink can
receive YCbCr, then the source should use it by default for CE formats,
and the default colorimetry depends on whether it's SD or HD. It also
states that when transmitting IT or CE formats as RGB, the color space
is the one defined in the EDID. CEA-861-D only made that statement for
IT formats, and left the RGB CE format case out in the cold.

> > As the HDMI spec refers to the CEA-861 specs, the HDMI spec overrides
> > CEA when dealing with HDMI specifics.
> >
> > So, according to the HDMI specification, the default is that it's only
> > 1080i, 1080p and 720p which are 709, the others are 601.  This does not
> > correspond with "drm_match_cea_mode(adjusted_mode) > 1".

We're mixing our apples and oranges here. The logic in i915 has to do
with the default RGB quantization range only.

> Hm, sounds like we need to improve stuff a bit, maybe add a common cea
> helper to the drm core with a bool is_hdmi to decide whether it's
> palin CEA or HDMI-CEA. Ville (who's written the current code and the
> match cea mode helper) can you please take a look?

Currently i915 only outputs RGB, so based on CEA-861-E setting C=00 is
the right thing to do. So I think the only thing we could improve is to
use YCbCr for CE formats by default, but first we need to implement
YCbCr output support :P

Oh and the other thing someone should do is fix the intel Xv code to
use BT.709 CSC matrix for HD content. I believe that code is hardcoded
for BT.601 currently, which may explain the last weirdness reported in
that CEA bug or ours.

> > Unfortunately, given DRM's structure, there's no way for the CRTC layer
> > to really know what its driving, and this setting is at the CRTC layer,
> > not the output layer.  It may be that you have the CRTC duplicated
> > between two different display devices with different characteristics,
> > which means you have to "choose" one - or just not bother.  I've chosen
> > the latter because it's a simpler solution, and is in no way any more
> > correct than any other solution.
> >
> > This is also why these are exported to userspace via properties, so if
> > userspace knows better, it can deal with those issues.
> 
> Yeah, allowing userspace to overwrite the default selection makes lots
> of sense, we expose similar properties.

We really should start documenting properties in some ABI document,
and actually designing them properly. Too many ad-hoc things in most
of the the drivers.

-- 
Ville Syrj?l?
Intel OTC


From broonie at kernel.org  Tue Jul  2 14:13:31 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 2 Jul 2013 19:13:31 +0100
Subject: [PATCH] ASoC: brownstone: add .owner to struct snd_soc_card
In-Reply-To: <CAPgLHd-VN4BiM=cEkFF4EgbL7iqR1XrhEzBiKyoJBVnzKspHJg@mail.gmail.com>
References: <CAPgLHd-VN4BiM=cEkFF4EgbL7iqR1XrhEzBiKyoJBVnzKspHJg@mail.gmail.com>
Message-ID: <20130702181331.GU27646@sirena.org.uk>

On Tue, Jul 02, 2013 at 05:26:21PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> 
> Add missing .owner of struct snd_soc_card. This prevents the
> module from being removed from underneath its users.

Applied, thanks.
-------------- 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/20130702/112fec91/attachment.sig>

From broonie at kernel.org  Tue Jul  2 14:13:48 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 2 Jul 2013 19:13:48 +0100
Subject: [PATCH] ASoC: ttc_dkb: add .owner to struct snd_soc_card
In-Reply-To: <CAPgLHd_CJUYf8Ry=J9Y8ZPSrCgqPLTj74rDr__bxoymQ8GR_1A@mail.gmail.com>
References: <CAPgLHd_CJUYf8Ry=J9Y8ZPSrCgqPLTj74rDr__bxoymQ8GR_1A@mail.gmail.com>
Message-ID: <20130702181348.GV27646@sirena.org.uk>

On Tue, Jul 02, 2013 at 05:26:40PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> 
> Add missing .owner of struct snd_soc_card. This prevents the
> module from being removed from underneath its users.

Applied, thanks.
-------------- 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/20130702/fc4a27d7/attachment.sig>

From balbi at ti.com  Tue Jul  2 14:16:47 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 2 Jul 2013 21:16:47 +0300
Subject: OMAP baseline test results for v3.10-rc7
In-Reply-To: <20130701204236.GA805@arwen.pp.htv.fi>
References: <alpine.DEB.2.02.1307011946180.4358@utopia.booyaka.com>
 <20130701204236.GA805@arwen.pp.htv.fi>
Message-ID: <20130702181647.GA9216@arwen.pp.htv.fi>

Hi,

On Mon, Jul 01, 2013 at 11:42:36PM +0300, Felipe Balbi wrote:
> On Mon, Jul 01, 2013 at 07:48:50PM +0000, Paul Walmsley wrote:
> > Boot to userspace:
> >     FAIL ( 2/12): 37xxevm, am335xbonelt
> 
> <quoting part of [1]>
> | U-Boot# tftp 0x82000000 am335x-boneblack.dtb
> | link up on port 0, speed 100, full duplex
> | Using cpsw device
> | TFTP from server 192.168.57.1; our IP address is 192.168.57.138
> | Filename 'am335x-boneblack.dtb'.
> 
> Where are you taking am335x-boneblack.dtb from ? It's not in mainline
> v3.10-rc7 kernel:
> 
> $ ls arch/arm/boot/dts/am33*.dts
> arch/arm/boot/dts/am335x-bone.dts  arch/arm/boot/dts/am335x-evm.dts
> arch/arm/boot/dts/am335x-evmsk.dts
> $ git grep -e boneblack arch/arm/
> $ echo $
> 1
> $ git show
> commit 9e895ace5d82df8929b16f58e9f515f6d54ab82d
> Author: Linus Torvalds <torvalds at linux-foundation.org>
> Date:   Sat Jun 22 09:47:31 2013 -1000
> 
>     Linux 3.10-rc7
> 
> diff --git a/Makefile b/Makefile
> index c6863b5..0142c93 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,7 +1,7 @@
>  VERSION = 3
>  PATCHLEVEL = 10
>  SUBLEVEL = 0
> -EXTRAVERSION = -rc6
> +EXTRAVERSION = -rc7
>  NAME = Unicycling Gorilla
>  
>  # *DOCUMENTATION*
> 
> [1] http://www.pwsan.com/omap/testlogs/test_v3.10-rc7/20130630191558/boot/am335xbonelt/am335x-bone/am335xbonelt_log.txt

just a gentle ping here, wondering if you still have some garbage DTBs
left in your tree.


-- 
balbi
-------------- 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/20130702/6599572e/attachment-0001.sig>

From linux at arm.linux.org.uk  Tue Jul  2 14:23:27 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 2 Jul 2013 19:23:27 +0100
Subject: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver
In-Reply-To: <20130702180155.GP5004@intel.com>
References: <20130629225210.GF3353@n2100.arm.linux.org.uk>
 <E1Ut41C-0000wl-Ff@rmk-PC.arm.linux.org.uk>
 <20130630115941.GG18285@phenom.ffwll.local>
 <20130630125238.GH3353@n2100.arm.linux.org.uk>
 <CAKMK7uFcsbxciq-J_HLCm61kOtGpeAK0Tg2=2AOWSa9YYc4TeA@mail.gmail.com>
 <20130702180155.GP5004@intel.com>
Message-ID: <20130702182327.GE24642@n2100.arm.linux.org.uk>

On Tue, Jul 02, 2013 at 09:01:55PM +0300, Ville Syrj?l? wrote:
> On Sun, Jun 30, 2013 at 07:29:27PM +0200, Daniel Vetter wrote:
> > On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux
> > <linux at arm.linux.org.uk> wrote:
> > > | Default Colorimetry
> > > |
> > > | ...
> > > |
> > > | 480p, 480i, 576p, 576i, 240p and 288p
> > > |
> > > | The default colorimetry for all 480-line, 576-line, 240-line, and 288-line
> > > | video formats described in CEA-861-D is based on SMPTE 170M.
> > > |
> > > | 1080i, 1080p and 720p
> > > |
> > > | The default colorimetry for high-definition video formats (1080i, 1080p and
> > > | 720p) described in CEA-861-D is based on ITU-R BT.709-5.
> 
> I think this was pretty much copy pasted from CEA-861-D which is very
> vague.
> 
> CEA-861-E is a bit better, and more clearly states that if the sink can
> receive YCbCr, then the source should use it by default for CE formats,
> and the default colorimetry depends on whether it's SD or HD. It also
> states that when transmitting IT or CE formats as RGB, the color space
> is the one defined in the EDID. CEA-861-D only made that statement for
> IT formats, and left the RGB CE format case out in the cold.

Actually, what I'm doing there is probably wrong when you consider
what is going on:

 Overlay (YUV) -> YUV->RGB colorspace conversion
                              |
                              v
 Graphic (RGB) -----------(colorkey)--------------------> HDMI

These bits control the YUV->RGB colorspace conversion.  The "is it 601
or 709 colorspace" question applies more to the colorspace of the
overlay image.  As far as I can tell, that is unspecified within our
normal video playback programs - there's provision to communicate that
information (they certainly don't seem to look for any kind of Xv
attribute).

The "is it computer or studio RGB" question (I think - I can't say
because the documentation is hellishly poor, and you now have as much
information on this as I do) refers to the colorspace of the RGB side.

So, maybe I should move the YUV colorspace setting to be a drm_plane
property?  But then how do we know what format it is supposed to be?
Do we just pick one and hope it's right?  Do we try to autodetect it
from the size of the drm_plane framebuffer?  What if something
downscales a HD YUV framebuffer to something smaller because the
display is smaller?

What I can say is that I've watched many hours of content with my driver
and at 720p output resolution, I prefer it converting the YUV between
709 to studio RGB - otherwise the blacks are too black and I find that
I have to adjust the brightness/contrast to bring the black levels up
compared to a standard TV broadcast.

> Oh and the other thing someone should do is fix the intel Xv code to
> use BT.709 CSC matrix for HD content. I believe that code is hardcoded
> for BT.601 currently, which may explain the last weirdness reported in
> that CEA bug or ours.

How do you propose to switch between the two?


From nsekhar at ti.com  Tue Jul  2 14:45:00 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 3 Jul 2013 00:15:00 +0530
Subject: [PATCH] USB: OHCI: make ohci-da8xx a separate driver
In-Reply-To: <51D30BC0.9090108@linaro.org>
References: <1372765019-7191-1-git-send-email-manjunath.goudar@linaro.org>
 <51D2E8A0.1080102@cogentembedded.com>
 <CAJFYCKErW5hvgBvKiywHmf0eBYOix8Fkn9vQFa-TKHA63hX7aQ@mail.gmail.com>
 <51D30BC0.9090108@linaro.org>
Message-ID: <51D31FAC.9050706@ti.com>

On 7/2/2013 10:50 PM, Kevin Hilman wrote:
> On 07/02/2013 08:14 AM, Manjunath Goudar wrote:
>>
>>
>> On 2 July 2013 20:20, Sergei Shtylyov
>> <sergei.shtylyov at cogentembedded.com
>> <mailto:sergei.shtylyov at cogentembedded.com>> wrote:
>>
>>     Hello.
>>
>>
>>     On 02-07-2013 15:36, Manjunath Goudar wrote:
>>
>>         Separate the Davinci OHCI host controller driver from ohci-hcd
>>         host code so that it can be built as a separate driver module.
>>         This work is part of enabling multi-platform kernels on ARM;
>>         it would be nice to have in 3.11.
>>
>>
>>         One preexisting error:
>>         "da8xx_syscfg0_base" [drivers/usb/host/ohci-da8xx.__ko] undefined!
>>
>>
>>         Fixed eventually using below modification:
>>         added EXPORT_SYMBOL_GPL(da8xx___syscfg0_base) in
>>         arch/arm/mach-davinci/devices-__da8xx.c.
>>
>>
>>        And you managed to get this fix into the DaVinci tree? I tried it
>>     long ago and it was refused by then DaVinci maintainer Kevin Hilman.
>>
>>
>> Yes I saw your patch that is what I mentioned in patch description.
>> We will wait for DaVinci maintainer response,what he will suggest. 
> 
> Note that Sekhar Nori (now Cc'd) is the primary maintainer of davinci,
> and I'll defer the final decision to him.  However, the mach-davinci
> change is not in this patch, so I'm not sure exactly how it relates
> here, since that problem exists independently of this patch.
> 
> That being said, I will NAK the above EXPORT_SYMBOL change in
> mach-davinci code because passing data between platform code and drivers
> via global variables is still a bad idea.  Some helper accessor
> functions will need to be created to abstract those low-level accesses.

Okay, I haven't seen the patch as well, but I agree with Kevin that
EXPORT_SYMBOL from platform code is a bad idea and wont help the
multi-platform build.

Right clean-up for this most probably requires creation of a PHY driver
to handle the USB 2.0 and USB 1.1 phy specifics on this chip. Its best
to start a mail thread on USB list for guidance. You can keep me in loop
too.

Thanks,
Sekhar


From ville.syrjala at linux.intel.com  Tue Jul  2 14:52:53 2013
From: ville.syrjala at linux.intel.com (Ville =?iso-8859-1?Q?Syrj=E4l=E4?=)
Date: Tue, 2 Jul 2013 21:52:53 +0300
Subject: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver
In-Reply-To: <20130702182327.GE24642@n2100.arm.linux.org.uk>
References: <20130629225210.GF3353@n2100.arm.linux.org.uk>
 <E1Ut41C-0000wl-Ff@rmk-PC.arm.linux.org.uk>
 <20130630115941.GG18285@phenom.ffwll.local>
 <20130630125238.GH3353@n2100.arm.linux.org.uk>
 <CAKMK7uFcsbxciq-J_HLCm61kOtGpeAK0Tg2=2AOWSa9YYc4TeA@mail.gmail.com>
 <20130702180155.GP5004@intel.com>
 <20130702182327.GE24642@n2100.arm.linux.org.uk>
Message-ID: <20130702185253.GQ5004@intel.com>

On Tue, Jul 02, 2013 at 07:23:27PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 02, 2013 at 09:01:55PM +0300, Ville Syrj?l? wrote:
> > On Sun, Jun 30, 2013 at 07:29:27PM +0200, Daniel Vetter wrote:
> > > On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux
> > > <linux at arm.linux.org.uk> wrote:
> > > > | Default Colorimetry
> > > > |
> > > > | ...
> > > > |
> > > > | 480p, 480i, 576p, 576i, 240p and 288p
> > > > |
> > > > | The default colorimetry for all 480-line, 576-line, 240-line, and 288-line
> > > > | video formats described in CEA-861-D is based on SMPTE 170M.
> > > > |
> > > > | 1080i, 1080p and 720p
> > > > |
> > > > | The default colorimetry for high-definition video formats (1080i, 1080p and
> > > > | 720p) described in CEA-861-D is based on ITU-R BT.709-5.
> > 
> > I think this was pretty much copy pasted from CEA-861-D which is very
> > vague.
> > 
> > CEA-861-E is a bit better, and more clearly states that if the sink can
> > receive YCbCr, then the source should use it by default for CE formats,
> > and the default colorimetry depends on whether it's SD or HD. It also
> > states that when transmitting IT or CE formats as RGB, the color space
> > is the one defined in the EDID. CEA-861-D only made that statement for
> > IT formats, and left the RGB CE format case out in the cold.
> 
> Actually, what I'm doing there is probably wrong when you consider
> what is going on:
> 
>  Overlay (YUV) -> YUV->RGB colorspace conversion
>                               |
>                               v
>  Graphic (RGB) -----------(colorkey)--------------------> HDMI
> 
> These bits control the YUV->RGB colorspace conversion.  The "is it 601
> or 709 colorspace" question applies more to the colorspace of the
> overlay image.  As far as I can tell, that is unspecified within our
> normal video playback programs - there's provision to communicate that
> information (they certainly don't seem to look for any kind of Xv
> attribute).
> 
> The "is it computer or studio RGB" question (I think - I can't say
> because the documentation is hellishly poor, and you now have as much
> information on this as I do) refers to the colorspace of the RGB side.
> 
> So, maybe I should move the YUV colorspace setting to be a drm_plane
> property?  But then how do we know what format it is supposed to be?
> Do we just pick one and hope it's right?  Do we try to autodetect it
> from the size of the drm_plane framebuffer?  What if something
> downscales a HD YUV framebuffer to something smaller because the
> display is smaller?

Yes a plane property would be the right thing to use here. I'm not sure
we need any automagic default in the kernel for this stuff. I'm thinking
we just default to BT.601 (or something else if the hardware is really
weird and doesn't do BT.601) and let userspace override if it wants.

My plan for such a property has thus far been an enum called "csc matrix"
(or something vaguely similar) and the values could just be something
like "BT.601", "BT.709" etc.

Calling the property "csc matrix" has one downside though; What if the
hardware CSC is fully programmable and we want to push an actual matrix
from userspace. That property might also like to be called "csc matrix",
so maybe we want try to come up with a better name for this first guy.
Or maybe it should be "csc matrix" = "custom" + "csc matrix custom" =
<actual matrix>. There's also the question of the format of the
coefficients in the custom matrix. We may need some HW specifics
there...

> What I can say is that I've watched many hours of content with my driver
> and at 720p output resolution, I prefer it converting the YUV between
> 709 to studio RGB - otherwise the blacks are too black and I find that
> I have to adjust the brightness/contrast to bring the black levels up
> compared to a standard TV broadcast.
> 
> > Oh and the other thing someone should do is fix the intel Xv code to
> > use BT.709 CSC matrix for HD content. I believe that code is hardcoded
> > for BT.601 currently, which may explain the last weirdness reported in
> > that CEA bug or ours.
> 
> How do you propose to switch between the two?

An Xv port attribute should do. Google found me XV_COLORSPACE, which
seems to be the name the radeon folks picked for it.

-- 
Ville Syrj?l?
Intel OTC


From shc_work at mail.ru  Tue Jul  2 15:16:33 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Tue,  2 Jul 2013 23:16:33 +0400
Subject: [PATCH RESEND] ARM: plat-samsung: Fix switching FIFO in
 arch_enable_uart_fifo function
Message-ID: <1372792593-7457-1-git-send-email-shc_work@mail.ru>

When CONFIG_S3C_BOOT_UART_FORCE_FIFO symbol is set, we should
enable FIFO but actually switch command is missing in the code.
This patch adds this switching.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/plat-samsung/include/plat/uncompress.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/plat-samsung/include/plat/uncompress.h b/arch/arm/plat-samsung/include/plat/uncompress.h
index 4afc32f..f48dc0a 100644
--- a/arch/arm/plat-samsung/include/plat/uncompress.h
+++ b/arch/arm/plat-samsung/include/plat/uncompress.h
@@ -145,6 +145,8 @@ static inline void arch_enable_uart_fifo(void)
 			if (!(fifocon & S3C2410_UFCON_RESETBOTH))
 				break;
 		}
+
+		uart_wr(S3C2410_UFCON, S3C2410_UFCON_FIFOMODE);
 	}
 }
 #else
-- 
1.8.1.5



From arnd at arndb.de  Tue Jul  2 15:01:44 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 2 Jul 2013 21:01:44 +0200
Subject: [GIT PULL 2/7] ARM SoC cleanups
In-Reply-To: <201307022055.50717.arnd@arndb.de>
References: <201307022055.50717.arnd@arndb.de>
Message-ID: <201307022101.44753.arnd@arndb.de>

The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f:

  Linux 3.10-rc6 (2013-06-15 11:51:07 -1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/cleanup-for-linus

for you to fetch changes up to 0ee8090c1d059eca4d60e8e473bee91fb5d1996b:

  Merge branch 'armsoc/for-3.11/cleanups' of git://github.com/broadcom/bcm11351 into next/cleanup (2013-06-21 15:39:24 +0200)

----------------------------------------------------------------

ARM SoC cleanups

This contains cleanups as preparation for other branches adding new
features, we pulled 16 branches for 9 platforms into this one.

Most notable here is the removal of support for ATAGS based OMAP4
systems. Since all OMAP4 machines are fully functional with DT based
booting in 3.10, we can remove a lot of code here.

Also noteworthy is Maxime Ripard's cleanup of the machine descriptors,
which means we need no machine descriptors in a lot more cases and
can boot additional machines by just having the respective device
drivers enabled.

----------------------------------------------------------------

Andrew Lunn (1):
      ARM: Orion: Remove redundant init_dma_coherent_pool_size()

Andrew Murray (1):
      of/pci: Provide support for parsing PCI DT ranges property

Arnd Bergmann (11):
      Merge tag 'zynq-cleanup-for-3.11' of git://git.xilinx.com/linux-xlnx into next/cleanup
      Merge tag 'at91-cleanup' of git://github.com/at91linux/linux-at91 into next/cleanup
      Merge branch 'picoxcell-next' of git://github.com/jamieiles/linux-2.6-ji into next/cleanup
      Merge tag 'omap-for-v3.11/pm-serial-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/cleanup
      Merge tag 'omap-for-v3.11/pm-voltdomain-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/cleanup
      Merge tag 'omap-for-v3.11/dma-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/cleanup
      Merge tag 'samsung-cleanup-1' of git://git.kernel.org/.../kgene/linux-samsung into next/cleanup
      ARM: s5p64x0: avoid build warning for uncompress.h
      ARM: picoxcell: remove .nr_irqs reference
      Merge branch 'armsoc/for-3.11/cleanups' of git://github.com/broadcom/bcm11351 into next/cleanup
      Merge tag 'cleanup-for-linus' into for-linus

David Brown (1):
      ARM: dts: msm: Fix merge resolution

Ezequiel Garcia (1):
      bus: mvebu-mbus: Use pr_fmt

Jamie Iles (1):
      picoxcell: remove redundant common.h

Jarkko Nikula (8):
      ARM: OMAP2+: Remove AES crypto device DMA channel definitions
      ARM: OMAP2+: Remove duplicated DMA channel definitions
      ARM: OMAP2+: hwmod: Remove remaining DMA channel definitions
      ARM: OMAP2+: Remove dma.h
      ARM: OMAP1: Remove McBSP DMA channel definitions
      ARM: OMAP1: Remove duplicated DMA channel definitions
      ARM: OMAP1: Remove legacy irda.h and irda setup from board files
      ARM: OMAP1: Remove dma.h

Jean-Christophe PLAGNIOL-VILLARD (7):
      ARM: at91: dt: use #include for all device trees
      ARM: at91: dt: switch to standard GPIO flag defines.
      ARM: at91: dt: add pinctrl pre-processor define
      ARM: at91: dt: switch to pinctrl to pre-processor
      ARM: at91: dt: switch to standard IRQ flag defines
      ARM: at91: udpate defconfigs
      ARM: at91: drop rm9200dk board support

Maxime Ripard (18):
      ARM: picoxcell: Remove init_irq declaration in machine description
      ARM: bcm281xx: Remove init_irq declaration in machine description
      ARM: sunxi: Remove init_irq declaration in machine description
      ARM: msm: Remove init_irq declaration in machine description
      ARM: mvebu: Remove init_irq declaration in machine description
      ARM: zynq: Remove init_irq declaration in machine description
      ARM: nomadik: Remove init_irq declaration in machine description
      ARM: spear: Remove init_irq declaration in machine description
      ARM: sirf: Remove init_irq declaration in machine description
      ARM: vexpress: Remove init_irq declaration in machine description
      ARM: virt: Remove init_irq declaration in machine description
      ARM: vt8500: Remove init_irq declaration in machine description
      ARM: mmu: Call debug_ll_io_init if no map_io function is specified
      ARM: highbank: remove the .map_io declaration
      ARM: mxs: remove the .map_io declaration
      ARM: sunxi: Remove the .map_io function declaration
      ARM: sunxi: Update datasheet documentation
      ARM: sunxi: irqchip: Update the documentation

Michal Simek (1):
      ARM: zynq: Not to rewrite jump code when starting address is 0x0

Olof Johansson (10):
      Merge tag 'at91-cleanup' of git://github.com/at91linux/linux-at91 into next/cleanup
      Merge tag 'arm-soc-cleanups-for-3.11' of git://github.com/mripard/linux into next/cleanup
      Merge tag 'cleanup-3.11-3' of git://git.infradead.org/users/jcooper/linux into next/cleanup
      Merge tag 'of_pci-3.11' of git://git.infradead.org/users/jcooper/linux into next/cleanup
      Merge tag 'omap-for-v3.10/fixes-v3.10-rc4' of git://git.kernel.org/.../tmlind/linux-omap into next/cleanup
      Merge tag 'omap-for-v3.11/cleanup-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/cleanup
      Merge tag 'cleanup-3.11-4' of git://git.infradead.org/users/jcooper/linux into next/cleanup
      Merge tag 'msm-fix-for-3.11' of git://git.kernel.org/.../davidb/linux-msm into next/cleanup
      Merge tag 'msm-cleanup-for-3.11' of git://git.kernel.org/.../davidb/linux-msm into next/cleanup
      Merge tag 'sunxi-core-for-3.11' of git://github.com/mripard/linux into next/cleanup

R Sricharan (2):
      ARM: OMAP: dma: Remove the wrong dev_id check
      ARM: OMAP: dma: Fix the dma_chan_link_map init order

Rajendra Nayak (3):
      ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm
      ARM: AM33xx: Remove the unused voltagedomain data
      ARM: OMAP: dma: Remove the erroneous freeing of platform data

Rohit Vaswani (4):
      msm: Remove unused file core.h
      msm: iomap: Remove unused bases and mappings
      ARM: msm: Remove gpiomux-v2 and re-organize MSM_GPIOMUX configs
      gpio: msm: Add device tree and irqdomain support for gpio-msm-v2

Sourav Poddar (3):
      arm: omap2+: serial: remove no_console_suspend support
      arm: dts: am33xx: Remove "ti,no_idle_on_suspend" property.
      arm: omap2+: omap_device: remove no_idle_on_suspend

Sricharan R (2):
      ARM: OMAP4: hwmod data: Clean up the data file
      ARM: OMAP4: hwmod data: Remove irq entries from mcspi, mmc hwmods

Stephen Boyd (1):
      mfd: ssbi: Use devm_* and simplify code

Thierry Reding (2):
      of/pci: Add of_pci_get_devfn() function
      of/pci: Add of_pci_parse_bus_range() function

Thomas Petazzoni (1):
      arm: mvebu: mark functions of armada-370-xp.c as static

Tomasz Figa (7):
      ARM: S5P64X0: Use common uncompress.h part for plat-samsung
      watchdog: s3c2410_wdt: Use local register definitions
      ARM: SAMSUNG: Use local definitions of watchdog registers
      ARM: SAMSUNG: Add watchdog reset driver
      ARM: SAMSUNG: Let platforms use the new watchdog reset driver
      ARM: SAMSUNG: Remove legacy watchdog reset code
      ARM: SAMSUNG: Remove unused plat/regs-watchdog.h header

Tomi Valkeinen (1):
      ARM: OMAP4: hwmod data: add DSS data back

Tony Lindgren (10):
      ARM: OMAP2+: Legacy support for wl12xx when booted with devicetree
      ARM: OMAP2+: Remove board-4430sdp.c
      ARM: OMAP2+: Remove board-omap4panda.c
      ARM: OMAP2+: Remove legacy mux data for omap4
      ARM: OMAP2+: Remove omap4 pdata from hsmmc.c
      ARM: OMAP2+: Remove omap4 pdata for USB
      ARM: OMAP2+: Remove omap4 ocp2scp pdata
      Merge branch 'am33xx' into omap-for-v3.11/cleanup
      Merge tag 'omap-pm-v3.11/cleanup/pm' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-v3.11/pm-serial
      Merge tag 'omap-pm-v3.11/voltdm' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-v3.11/pm-voltdomain

Tushar Behera (1):
      ARM: SAMSUNG: Consolidate uncompress subroutine

Vaibhav Hiremath (1):
      ARM: AM33XX: hwmod data: irq, dma and addr info clean up

 Documentation/arm/sunxi/README                     |   21 +-
 .../devicetree/bindings/gpio/gpio-msm.txt          |   26 +
 .../interrupt-controller/allwinner,sun4i-ic.txt    |   87 +-
 .../interrupt-controller/sunxi/sun4i-a10.txt       |   89 ++
 .../interrupt-controller/sunxi/sun5i-a13.txt       |   55 +
 arch/arm/Kconfig                                   |    3 +
 arch/arm/boot/dts/aks-cdu.dts                      |   12 +-
 arch/arm/boot/dts/am33xx.dtsi                      |    1 -
 arch/arm/boot/dts/animeo_ip.dts                    |   18 +-
 arch/arm/boot/dts/at91-ariag25.dts                 |    6 +-
 arch/arm/boot/dts/at91rm9200.dtsi                  |  207 +--
 arch/arm/boot/dts/at91rm9200ek.dts                 |   10 +-
 arch/arm/boot/dts/at91sam9260.dtsi                 |  215 +--
 arch/arm/boot/dts/at91sam9263.dtsi                 |  203 +--
 arch/arm/boot/dts/at91sam9263ek.dts                |   24 +-
 arch/arm/boot/dts/at91sam9g15.dtsi                 |    2 +-
 arch/arm/boot/dts/at91sam9g15ek.dts                |    4 +-
 arch/arm/boot/dts/at91sam9g20.dtsi                 |    2 +-
 arch/arm/boot/dts/at91sam9g20ek.dts                |    6 +-
 arch/arm/boot/dts/at91sam9g20ek_2mmc.dts           |   10 +-
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi        |   28 +-
 arch/arm/boot/dts/at91sam9g25.dtsi                 |    2 +-
 arch/arm/boot/dts/at91sam9g25ek.dts                |    4 +-
 arch/arm/boot/dts/at91sam9g35.dtsi                 |    2 +-
 arch/arm/boot/dts/at91sam9g35ek.dts                |    4 +-
 arch/arm/boot/dts/at91sam9g45.dtsi                 |  213 +--
 arch/arm/boot/dts/at91sam9m10g45ek.dts             |   38 +-
 arch/arm/boot/dts/at91sam9n12.dtsi                 |  141 +-
 arch/arm/boot/dts/at91sam9n12ek.dts                |   14 +-
 arch/arm/boot/dts/at91sam9x25.dtsi                 |   22 +-
 arch/arm/boot/dts/at91sam9x25ek.dts                |    4 +-
 arch/arm/boot/dts/at91sam9x35.dtsi                 |    2 +-
 arch/arm/boot/dts/at91sam9x35ek.dts                |    4 +-
 arch/arm/boot/dts/at91sam9x5.dtsi                  |  279 ++--
 arch/arm/boot/dts/at91sam9x5cm.dtsi                |    8 +-
 arch/arm/boot/dts/at91sam9x5ek.dtsi                |   14 +-
 arch/arm/boot/dts/ethernut5.dts                    |    6 +-
 arch/arm/boot/dts/evk-pro3.dts                     |    6 +-
 arch/arm/boot/dts/ge863-pro3.dtsi                  |    2 +-
 arch/arm/boot/dts/kizbox.dts                       |   16 +-
 arch/arm/boot/dts/mpa1600.dts                      |    4 +-
 arch/arm/boot/dts/msm8660-surf.dts                 |   11 +
 arch/arm/boot/dts/msm8960-cdp.dts                  |   11 +
 arch/arm/boot/dts/pm9g45.dts                       |   22 +-
 arch/arm/boot/dts/sama5d3.dtsi                     |  520 +++----
 arch/arm/boot/dts/sama5d31ek.dts                   |    6 +-
 arch/arm/boot/dts/sama5d33ek.dts                   |    4 +-
 arch/arm/boot/dts/sama5d34ek.dts                   |    6 +-
 arch/arm/boot/dts/sama5d35ek.dts                   |    4 +-
 arch/arm/boot/dts/sama5d3xcm.dtsi                  |    4 +-
 arch/arm/boot/dts/sama5d3xdm.dtsi                  |    2 +-
 arch/arm/boot/dts/sama5d3xmb.dtsi                  |   26 +-
 arch/arm/boot/dts/tny_a9260.dts                    |    4 +-
 arch/arm/boot/dts/tny_a9263.dts                    |    4 +-
 arch/arm/boot/dts/tny_a9g20.dts                    |    4 +-
 arch/arm/boot/dts/usb_a9260.dts                    |    4 +-
 arch/arm/boot/dts/usb_a9260_common.dtsi            |    6 +-
 arch/arm/boot/dts/usb_a9263.dts                    |    8 +-
 arch/arm/boot/dts/usb_a9g20-dab-mmx.dtsi           |   22 +-
 arch/arm/boot/dts/usb_a9g20.dts                    |    4 +-
 arch/arm/configs/at91_dt_defconfig                 |   55 +-
 arch/arm/configs/at91rm9200_defconfig              |  219 +--
 ...am9g20_defconfig => at91sam9260_9g20_defconfig} |   67 +-
 arch/arm/configs/at91sam9260_defconfig             |   91 --
 ...am9261_defconfig => at91sam9261_9g10_defconfig} |   19 +-
 arch/arm/configs/at91sam9263_defconfig             |   39 +-
 arch/arm/configs/at91sam9g45_defconfig             |   94 +-
 arch/arm/configs/sama5_defconfig                   |   35 +-
 arch/arm/mach-at91/Kconfig.non_dt                  |  166 +--
 arch/arm/mach-at91/Makefile                        |    3 -
 arch/arm/mach-at91/board-rm9200dk.c                |  228 ---
 arch/arm/mach-at91/board-sam9261ek.c               |   28 +-
 arch/arm/mach-bcm/board_bcm.c                      |    2 -
 arch/arm/mach-exynos/include/mach/uncompress.h     |    3 -
 arch/arm/mach-highbank/highbank.c                  |    1 -
 arch/arm/mach-msm/Kconfig                          |   13 +-
 arch/arm/mach-msm/Makefile                         |    6 +-
 arch/arm/mach-msm/board-dt-8660.c                  |    2 -
 arch/arm/mach-msm/board-dt-8960.c                  |    2 -
 arch/arm/mach-msm/core.h                           |    2 -
 arch/arm/mach-msm/gpiomux-8x60.c                   |   19 -
 arch/arm/mach-msm/gpiomux-v2.c                     |   25 -
 arch/arm/mach-msm/gpiomux-v2.h                     |   61 -
 arch/arm/mach-msm/gpiomux.c                        |   15 +
 arch/arm/mach-msm/gpiomux.h                        |    5 -
 arch/arm/mach-msm/include/mach/msm_iomap-8960.h    |    7 -
 arch/arm/mach-msm/include/mach/msm_iomap-8x60.h    |    6 -
 arch/arm/mach-msm/include/mach/msm_iomap.h         |    2 -
 arch/arm/mach-msm/io.c                             |    4 -
 arch/arm/mach-mvebu/armada-370-xp.c                |    8 +-
 arch/arm/mach-mxs/mach-mxs.c                       |    1 -
 arch/arm/mach-nomadik/cpu-8815.c                   |    2 -
 arch/arm/mach-omap1/board-h2.c                     |   36 -
 arch/arm/mach-omap1/board-palmte.c                 |   31 -
 arch/arm/mach-omap1/board-palmtt.c                 |   30 -
 arch/arm/mach-omap1/board-palmz71.c                |   31 -
 arch/arm/mach-omap1/board-sx1.c                    |   36 -
 arch/arm/mach-omap1/devices.c                      |    9 +-
 arch/arm/mach-omap1/dma.c                          |    2 -
 arch/arm/mach-omap1/dma.h                          |   42 -
 arch/arm/mach-omap1/include/mach/irda.h            |   33 -
 arch/arm/mach-omap1/lcd_dma.c                      |    2 -
 arch/arm/mach-omap1/mcbsp.c                        |   33 +-
 arch/arm/mach-omap2/Kconfig                        |   22 -
 arch/arm/mach-omap2/Makefile                       |    4 -
 arch/arm/mach-omap2/board-4430sdp.c                |  765 ----------
 arch/arm/mach-omap2/board-omap4panda.c             |  455 ------
 arch/arm/mach-omap2/devices.c                      |  133 +-
 arch/arm/mach-omap2/dma.h                          |   61 -
 arch/arm/mach-omap2/hsmmc.c                        |  103 +-
 arch/arm/mach-omap2/io.c                           |    1 -
 arch/arm/mach-omap2/mux.h                          |    3 -
 arch/arm/mach-omap2/mux44xx.c                      | 1356 -----------------
 arch/arm/mach-omap2/mux44xx.h                      |  298 ----
 arch/arm/mach-omap2/omap_device.c                  |    9 +-
 arch/arm/mach-omap2/omap_device.h                  |   10 -
 .../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c |   21 +-
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         | 1074 --------------
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |   19 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         | 1544 +-------------------
 arch/arm/mach-omap2/powerdomain.c                  |    5 +
 arch/arm/mach-omap2/powerdomain.h                  |    2 +
 arch/arm/mach-omap2/prm33xx.c                      |    7 +
 arch/arm/mach-omap2/serial.c                       |    7 -
 arch/arm/mach-omap2/usb-host.c                     |  194 ---
 arch/arm/mach-omap2/usb-musb.c                     |    3 -
 arch/arm/mach-omap2/voltage.h                      |    1 -
 arch/arm/mach-omap2/voltagedomains33xx_data.c      |   43 -
 arch/arm/mach-picoxcell/common.c                   |    8 -
 arch/arm/mach-picoxcell/common.h                   |   17 -
 arch/arm/mach-prima2/common.c                      |    4 -
 arch/arm/mach-s3c24xx/Kconfig                      |    2 +
 arch/arm/mach-s3c24xx/include/mach/uncompress.h    |    3 +
 arch/arm/mach-s3c24xx/s3c2410.c                    |    3 +-
 arch/arm/mach-s3c24xx/s3c244x.c                    |    3 +-
 arch/arm/mach-s3c64xx/common.c                     |    8 +-
 arch/arm/mach-s3c64xx/include/mach/uncompress.h    |    3 +
 arch/arm/mach-s5p64x0/common.c                     |    4 +-
 arch/arm/mach-s5p64x0/include/mach/uncompress.h    |  162 +-
 arch/arm/mach-s5pc100/common.c                     |    3 +-
 arch/arm/mach-s5pc100/include/mach/uncompress.h    |    2 +
 arch/arm/mach-s5pv210/include/mach/uncompress.h    |    2 +
 arch/arm/mach-spear/spear1310.c                    |    2 -
 arch/arm/mach-spear/spear1340.c                    |    2 -
 arch/arm/mach-spear/spear300.c                     |    2 -
 arch/arm/mach-spear/spear310.c                     |    2 -
 arch/arm/mach-spear/spear320.c                     |    2 -
 arch/arm/mach-spear/spear6xx.c                     |    2 -
 arch/arm/mach-sunxi/sunxi.c                        |   19 -
 arch/arm/mach-sunxi/sunxi.h                        |   20 -
 arch/arm/mach-vexpress/v2m.c                       |    2 -
 arch/arm/mach-virt/virt.c                          |    2 -
 arch/arm/mach-vt8500/vt8500.c                      |    2 -
 arch/arm/mach-zynq/common.c                        |    2 -
 arch/arm/mach-zynq/platsmp.c                       |   52 +-
 arch/arm/mm/mmu.c                                  |    2 +
 arch/arm/plat-omap/dma.c                           |   11 +-
 arch/arm/plat-samsung/Kconfig                      |    6 +
 arch/arm/plat-samsung/Makefile                     |    1 +
 arch/arm/plat-samsung/include/plat/regs-watchdog.h |   41 -
 arch/arm/plat-samsung/include/plat/uncompress.h    |   21 +-
 .../arm/plat-samsung/include/plat/watchdog-reset.h |   38 +-
 arch/arm/plat-samsung/watchdog-reset.c             |   97 ++
 drivers/bus/mvebu-mbus.c                           |    8 +-
 drivers/bus/omap-ocp2scp.c                         |   60 -
 drivers/gpio/Kconfig                               |    2 +-
 drivers/gpio/gpio-msm-v2.c                         |  195 ++-
 drivers/of/address.c                               |   67 +
 drivers/of/of_pci.c                                |   59 +-
 drivers/ssbi/ssbi.c                                |   69 +-
 drivers/watchdog/s3c2410_wdt.c                     |   17 +-
 include/dt-bindings/pinctrl/at91.h                 |   35 +
 include/linux/of_address.h                         |   48 +
 include/linux/of_pci.h                             |    2 +
 include/linux/platform_data/omap_ocp2scp.h         |   31 -
 175 files changed, 2257 insertions(+), 9029 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-msm.txt
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/sunxi/sun5i-a13.txt
 rename arch/arm/configs/{at91sam9g20_defconfig => at91sam9260_9g20_defconfig} (67%)
 delete mode 100644 arch/arm/configs/at91sam9260_defconfig
 rename arch/arm/configs/{at91sam9261_defconfig => at91sam9261_9g10_defconfig} (91%)
 delete mode 100644 arch/arm/mach-at91/board-rm9200dk.c
 delete mode 100644 arch/arm/mach-msm/core.h
 delete mode 100644 arch/arm/mach-msm/gpiomux-8x60.c
 delete mode 100644 arch/arm/mach-msm/gpiomux-v2.c
 delete mode 100644 arch/arm/mach-msm/gpiomux-v2.h
 delete mode 100644 arch/arm/mach-omap1/dma.h
 delete mode 100644 arch/arm/mach-omap1/include/mach/irda.h
 delete mode 100644 arch/arm/mach-omap2/board-4430sdp.c
 delete mode 100644 arch/arm/mach-omap2/board-omap4panda.c
 delete mode 100644 arch/arm/mach-omap2/dma.h
 delete mode 100644 arch/arm/mach-omap2/mux44xx.c
 delete mode 100644 arch/arm/mach-omap2/mux44xx.h
 delete mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c
 delete mode 100644 arch/arm/mach-picoxcell/common.h
 delete mode 100644 arch/arm/mach-sunxi/sunxi.h
 delete mode 100644 arch/arm/plat-samsung/include/plat/regs-watchdog.h
 create mode 100644 arch/arm/plat-samsung/watchdog-reset.c
 create mode 100644 include/dt-bindings/pinctrl/at91.h
 delete mode 100644 include/linux/platform_data/omap_ocp2scp.h


From arnd at arndb.de  Tue Jul  2 15:06:06 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 2 Jul 2013 21:06:06 +0200
Subject: [GIT PULL 4/7] ARM SoC board specific changes
In-Reply-To: <201307022055.50717.arnd@arndb.de>
References: <201307022055.50717.arnd@arndb.de>
Message-ID: <201307022106.06880.arnd@arndb.de>

The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f:

  Linux 3.10-rc6 (2013-06-15 11:51:07 -1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/boards-for-linus

for you to fetch changes up to f8ace40e88eb7063f66697713373ac64cbc1412a:

  Merge tag 'zynq-defconfig-for-3.11' of git://git.xilinx.com/linux-xlnx into next/boards (2013-06-21 15:48:32 +0200)

----------------------------------------------------------------

ARM SoC board specific changes

These are 18 branches on 9 platforms with board specific changes, mostly
for defconfig files, but nothing really exciting in here.

Since the shmobile platform still uses board files for some of the newer
machines, we get a few changes there as the result of drivers getting
enabled for those boards. This causes some conflicts with contents getting
added from multiple branches in sh-mobile specific files. Renesas is
putting a lot of work into migrating to device-tree based setup, which
will make all those files obsolete in the future and avoid both the
conflicts and the need to have these files in the first place.

----------------------------------------------------------------

Aaro Koskinen (1):
      ARM: OMAP1: nokia770: enable Tahvo

Adrien Verg? (1):
      ARM: omap2plus_defconfig: enable USB_PHY and NOP_USB_XCEIV

Andrew Lunn (2):
      ARM: Kirkwood: Make use of the QNAP Power off driver.
      ARM: Kirkwood: Convert LSXL to restart-poweroff driver.

Arnd Bergmann (5):
      ARM: ux500: avoid warning in ux500_read_asicid
      Merge tag 'omap-for-v3.11/board-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/boards
      Merge tag 'renesas-boards2-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/boards
      Merge tag 'zynq-defconfig-for-3.11' of git://git.xilinx.com/linux-xlnx into next/boards
      Merge tag 'boards-for-linus' into for-linus

Fabio Baltieri (1):
      ARM: ux500: update MSP1 pinctrl defintions

Florian Vaussard (1):
      arm: omap: board-overo: reset GPIO for SMSC911x

Guennadi Liakhovetski (2):
      ARM: shmobile: kzm9g: enable AS3711 PMIC in defconfig
      ARM: shmobile: kzm9g: add AS3711 PMIC platform data

Kuninori Morimoto (13):
      ARM: shmobile: bockw: enable SDHI on defconfig
      ARM: shmobile: ape6evm: MP clock parent become EXTAL2
      ARM: shmobile: bockw: define FPGA address and rename iomem variable
      ARM: shmobile: bockw: add CN9 SCIF/RCAN selection dipswitch explanation
      ARM: shmobile: bockw: add dummy regulators for SMSC
      ARM: shmobile: bockw: add SDHI0 support
      ARM: shmobile: marzen: keep local function as static
      ARM: shmobile: bockw defconfig: add RTC RX8581 support
      ARM: shmobile: bockw defconfig: add M25P80 support
      ARM: shmobile: bockw defconfig: add MMCIF support
      ARM: shmobile: bockw: add I2C device support
      ARM: shmobile: bockw: add SPI FLASH support
      ARM: shmobile: bockw: add MMCIF support

Lee Jones (3):
      ARM: ux500: Increase the size of the PRCMU's TCPM size
      ARM: ux500: Remove incorrect DB9540 PRCMU TCDM base location
      ARM: ux500: regulators: Remove misleading comment

Lokesh Vutla (1):
      ARM: OMAP3EVM: Marking omap3_evm_display_init() with CONFIG_BROKEN

Nobuhiro Iwamatsu (1):
      ARM: shmobile: armadillo800eva: Fix maximum number of SCIF

Olof Johansson (11):
      Merge tag 'boards-3.11-2' of git://git.infradead.org/users/jcooper/linux into next/boards
      Merge tag 'renesas-defconfig-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/boards
      Merge branch 'renesas/pinmux-gpio' into next/boards
      Merge branch 'renesas/soc' into next/boards
      Merge tag 'renesas-boards-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/boards
      Merge tag 'ux500-core-for-arm-soc' of git://git.kernel.org/.../linusw/linux-stericsson into next/boards
      Merge tag 'ux500-pinctrl-for-arm-soc' of git://git.kernel.org/.../linusw/linux-stericsson into next/boards
      ARM: ux500: board-mop500: remove unused pin modes
      Merge tag 'bcm2835-for-3.11-defconfig' of git://git.kernel.org/.../swarren/linux-rpi into next/boards
      Merge tag 'renesas-defconfig2-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/boards
      Merge tag 'tegra-for-3.11-defconfig' of git://git.kernel.org/.../swarren/linux-tegra into next/boards

Patrice Chotard (1):
      ARM: ux500: add ABx500 pinctrl tables

Sergei Shtylyov (3):
      ARM: shmobile: bockw: enable USB in defconfig
      ARM: shmobile: BOCK-W: add Ether support
      ARM: shmobile: BOCK-W: change Ether device name

Simon Baatz (1):
      ARM: Kirkwood: add DT support for Sheevaplug and Sheevaplug eSATA

Simon Horman (6):
      Merge branches 'pinmux' and 'soc' into boards-base
      ARM: shmobile: kzm9d: resigser smsc911x platform device with id -1
      ARM: shmobile: lager: Add GPIO LEDs
      ARM: shmobile: lager: support GPIO switches
      ARM: shmobile: marzen: Use INTC External IRQ pin driver for SMSC
      Merge branch 'soc2' into boards-base

Soren Brinkmann (2):
      arm: multi_v7_defconfig: Enable Zynq UART driver
      arm: multi_v7_defconfig: Enable initrd/initramfs support

Stephen Warren (2):
      ARM: bcm2835: defconfig updates
      ARM: tegra: defconfig updates

Ulf Hansson (6):
      ARM: ux500: Enable 100MHz for SD/SDIO/MMC devices
      ARM: ux500: Don't set plf ocr mask for SD/MMC device
      ARM: ux500: Enable support for RPMB and Reliable Write for eMMC
      ARM: ux500: Enable support for discard for MMC/SD
      ARM: ux500: Set eMMC and WLAN card slot as non-removable
      ARM: ux500: Enable support for UHS-I SD-cards

Vladimir Barinov (2):
      ARM: shmobile: bockw: enable I2C in defconfig
      ARM: shmobile: bockw: enable CONFIG_PM_RUNTIME in defconfig

 arch/arm/boot/dts/kirkwood-lsxl.dtsi          |   4 +
 arch/arm/boot/dts/kirkwood-ts219.dtsi         |   5 +
 arch/arm/configs/armadillo800eva_defconfig    |   2 +-
 arch/arm/configs/bcm2835_defconfig            |  19 +-
 arch/arm/configs/bockw_defconfig              |  27 ++-
 arch/arm/configs/kzm9g_defconfig              |   3 +
 arch/arm/configs/multi_v7_defconfig           |   3 +
 arch/arm/configs/omap2plus_defconfig          |   2 +
 arch/arm/configs/tegra_defconfig              |  23 ++-
 arch/arm/mach-kirkwood/Kconfig                |   9 +
 arch/arm/mach-kirkwood/Makefile               |   1 +
 arch/arm/mach-kirkwood/board-dt.c             |   4 +
 arch/arm/mach-kirkwood/board-lsxl.c           |  16 --
 arch/arm/mach-kirkwood/board-sheevaplug.c     |  27 +++
 arch/arm/mach-kirkwood/board-ts219.c          |   3 -
 arch/arm/mach-kirkwood/common.h               |   5 +
 arch/arm/mach-omap1/board-nokia770.c          |  10 +
 arch/arm/mach-omap2/board-omap3evm.c          |   4 +
 arch/arm/mach-omap2/board-overo.c             |   3 +-
 arch/arm/mach-shmobile/board-ape6evm.c        |  15 ++
 arch/arm/mach-shmobile/board-bockw.c          | 158 +++++++++++++-
 arch/arm/mach-shmobile/board-kzm9d.c          |   2 +-
 arch/arm/mach-shmobile/board-kzm9g.c          | 193 +++++++++++++-----
 arch/arm/mach-shmobile/board-lager.c          |  49 +++++
 arch/arm/mach-shmobile/board-marzen.c         |   3 +-
 arch/arm/mach-ux500/board-mop500-pins.c       | 283 ++++++++++++++++++++++++--
 arch/arm/mach-ux500/board-mop500-regulators.c |   1 -
 arch/arm/mach-ux500/board-mop500-sdi.c        |  34 ++--
 arch/arm/mach-ux500/db8500-regs.h             |   3 +-
 arch/arm/mach-ux500/devices-db8500.c          |   2 +-
 arch/arm/mach-ux500/id.c                      |   6 +-
 31 files changed, 791 insertions(+), 128 deletions(-)
 create mode 100644 arch/arm/mach-kirkwood/board-sheevaplug.c


From arnd at arndb.de  Tue Jul  2 15:14:19 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 2 Jul 2013 21:14:19 +0200
Subject: [GIT PULL 7/7] ARM SoC late changes
In-Reply-To: <201307022055.50717.arnd@arndb.de>
References: <201307022055.50717.arnd@arndb.de>
Message-ID: <201307022114.19228.arnd@arndb.de>

The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f:

  Linux 3.10-rc6 (2013-06-15 11:51:07 -1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/late-for-linus

for you to fetch changes up to 8c3d913888cfb0066d62831969c3a992f7e4aba5:

  Merge tag 'msm-clock-for-3.11b' of git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm into next/late (2013-06-27 17:04:27 -0700)

----------------------------------------------------------------

ARM SoC late changes

These are changes that arrived a little late before the merge
window or that have multiple dependencies on previous branches
so they did not fit into one of the earlier ones. There
are 10 branches merged here, a total of 39 non-merge commits.
Contents are a mixed bag for the above reasons:

* Two new SoC platforms: ST microelectronics stixxxx and
  the TI 'Nspire' graphing calculator. These should have
  been in the 'soc' branch but were a little late
* Support for the Exynos 5420 variant in mach-exynos,
  which is based on the other exynos branches to avoid
  conflicts.
* Various small changes for sh-mobile, ux500 and davinci
* Common clk support for MSM

Conflicts:
* In Kconfig.debug, various additions trivially conflict,
  the list should be kept in alphabetical order when
  resolving.

----------------------------------------------------------------

Arnd Bergmann (6):
      Merge tag 'renesas-cleanup-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/late
      Merge tag 'soc-exynos5420-1' of git://git.kernel.org/.../kgene/linux-samsung into next/late
      Merge branch 'renesas/boards2' into next/late
      Merge tag 'renesas-sh-sci-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/late
      Merge tag 'davinci-for-v3.11/dt' of git://git.kernel.org/.../nsekhar/linux-davinci into next/late
      Merge tag 'late-for-linus' into for-linus

Chander Kashyap (10):
      ARM: dts: fork out common EXYNOS5 nodes
      ARM: dts: list the CPU nodes for EXYNOS5250
      ARM: EXYNOS: Add support for EXYNOS5420 SoC
      serial: samsung: select EXYNOS specific driver data if ARCH_EXYNOS is defined
      ARM: EXYNOS: use four additional chipid bits to identify EXYNOS family
      clk: exynos5420: register clocks using common clock framework
      ARM: dts: Add initial device tree support for EXYNOS5420
      clocksource: exynos_mct: use (request/free)_irq calls for local timer registration
      ARM: EXYNOS: add secondary CPU boot base location for EXYNOS5420
      ARM: EXYNOS: extend soft-reset support for EXYNOS5420

Daniel Tang (2):
      arm: Add device trees for TI-Nspire hardware
      arm: Add Initial TI-Nspire support

Kuninori Morimoto (1):
      ARM: shmobile: r8a7790: add __initdata on resource and device data

Leela Krishna Amudala (2):
      ARM: dts: add pinctrl support to EXYNOS5420
      pinctrl: exynos: add exynos5420 SoC specific data

Linus Walleij (1):
      ARM: ux500: bail out on alien cpus

Manjunathappa, Prakash (1):
      ARM: davinci: da850: adopt to pinctrl-single change for configuring multiple pins

Olof Johansson (5):
      Merge tag 'soc-exynos5420-2' of git://git.kernel.org/.../kgene/linux-samsung into next/late
      Merge branch 'nspire/soc' into next/late
      Merge branch 'sti/soc' into next/late
      Merge branch 'msm/fixes' into next/late
      Merge tag 'msm-clock-for-3.11b' of git://git.kernel.org/.../davidb/linux-msm into next/late

Philip Avinash (1):
      ARM: davinci: da850: Use #include for all device trees

Simon Horman (2):
      Merge tags 'renesas-pinmux-for-v3.11' and 'renesas-soc-for-v3.11' into cleanup
      serial: sh-sci: Initialise variables before access in sci_set_termios()

Srinivas Kandagatla (5):
      ARM: sti: Add STiH415 SOC support
      ARM: sti: Add STiH416 SOC support
      ARM: sti: Add DEBUG_LL console support
      ARM: stih41x: Add B2000 board support
      ARM: stih41x: Add B2020 board support

Stephen Boyd (12):
      msm_serial: Convert to clk_prepare/unprepare
      msm_serial: Use devm_clk_get() and properly return errors
      usb: otg: msm: Convert to clk_prepare/unprepare
      msm_sdcc: Convert to clk_prepare/unprepare
      msm: iommu: Convert to clk_prepare/unprepare
      msm: iommu: Use clk_set_rate() instead of clk_set_min_rate()
      ARM: msm: Remove custom clk_set_flags() API
      ARM: msm: Remove custom clk_set_{max,min}_rate() API
      ARM: msm: Remove clock-7x30.h include file
      ARM: msm: Prepare clk_get() users in mach-msm for clock-pcom driver
      ARM: msm: Make proc_comm clock control into a platform driver
      ARM: msm: Migrate to common clock framework

Ulrich Hecht (3):
      serial: sh-sci: HSCIF support
      ARM: shmobile: r8a7790: HSCIF support
      ARM: shmobile: r8a7790: don't use external clock for SCIFs

 Documentation/arm/sti/overview.txt                 |  33 +
 Documentation/arm/sti/stih415-overview.txt         |  12 +
 Documentation/arm/sti/stih416-overview.txt         |  12 +
 Documentation/devicetree/bindings/arm/nspire.txt   |  14 +
 .../devicetree/bindings/clock/exynos5420-clock.txt | 201 ++++++
 .../bindings/pinctrl/samsung-pinctrl.txt           |   1 +
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 MAINTAINERS                                        |   9 +
 arch/arm/Kconfig                                   |   6 +-
 arch/arm/Kconfig.debug                             |  52 ++
 arch/arm/Makefile                                  |   2 +
 arch/arm/boot/dts/Makefile                         |   8 +
 arch/arm/boot/dts/da850-enbw-cmc.dts               |   2 +-
 arch/arm/boot/dts/da850-evm.dts                    |   2 +-
 arch/arm/boot/dts/da850.dtsi                       |   4 +-
 arch/arm/boot/dts/exynos5.dtsi                     | 111 +++
 arch/arm/boot/dts/exynos5250.dtsi                  |  78 +--
 arch/arm/boot/dts/exynos5420-pinctrl.dtsi          | 680 ++++++++++++++++++
 arch/arm/boot/dts/exynos5420-smdk5420.dts          |  33 +
 arch/arm/boot/dts/exynos5420.dtsi                  | 148 ++++
 arch/arm/boot/dts/nspire-classic.dtsi              |  74 ++
 arch/arm/boot/dts/nspire-clp.dts                   |  45 ++
 arch/arm/boot/dts/nspire-cx.dts                    | 112 +++
 arch/arm/boot/dts/nspire-tp.dts                    |  44 ++
 arch/arm/boot/dts/nspire.dtsi                      | 175 +++++
 arch/arm/boot/dts/st-pincfg.h                      |  71 ++
 arch/arm/boot/dts/stih415-b2000.dts                |  15 +
 arch/arm/boot/dts/stih415-b2020.dts                |  15 +
 arch/arm/boot/dts/stih415-clock.dtsi               |  38 +
 arch/arm/boot/dts/stih415-pinctrl.dtsi             | 268 ++++++++
 arch/arm/boot/dts/stih415.dtsi                     |  87 +++
 arch/arm/boot/dts/stih416-b2000.dts                |  16 +
 arch/arm/boot/dts/stih416-b2020.dts                |  16 +
 arch/arm/boot/dts/stih416-clock.dtsi               |  41 ++
 arch/arm/boot/dts/stih416-pinctrl.dtsi             | 295 ++++++++
 arch/arm/boot/dts/stih416.dtsi                     |  96 +++
 arch/arm/boot/dts/stih41x-b2000.dtsi               |  41 ++
 arch/arm/boot/dts/stih41x-b2020.dtsi               |  42 ++
 arch/arm/boot/dts/stih41x.dtsi                     |  38 +
 arch/arm/include/debug/nspire.S                    |  28 +
 arch/arm/include/debug/sti.S                       |  61 ++
 arch/arm/mach-exynos/Kconfig                       |  10 +
 arch/arm/mach-exynos/common.c                      |  18 +-
 arch/arm/mach-exynos/include/mach/uncompress.h     |   7 +-
 arch/arm/mach-exynos/mach-exynos5-dt.c             |   1 +
 arch/arm/mach-exynos/platsmp.c                     |  12 +-
 arch/arm/mach-msm/Makefile                         |  10 +-
 arch/arm/mach-msm/board-halibut.c                  |   2 +-
 arch/arm/mach-msm/board-msm7x30.c                  |   2 +-
 arch/arm/mach-msm/board-qsd8x50.c                  |   2 +-
 arch/arm/mach-msm/board-trout-panel.c              |  19 +-
 arch/arm/mach-msm/board-trout.c                    |   3 +-
 arch/arm/mach-msm/clock-7x30.h                     | 155 -----
 arch/arm/mach-msm/clock-debug.c                    | 130 ----
 arch/arm/mach-msm/clock-pcom.c                     | 149 ++--
 arch/arm/mach-msm/clock-pcom.h                     |  31 +-
 arch/arm/mach-msm/clock.c                          | 166 +----
 arch/arm/mach-msm/clock.h                          |  51 +-
 arch/arm/mach-msm/devices-msm7x00.c                |  12 +-
 arch/arm/mach-msm/devices-msm7x30.c                |  15 +-
 arch/arm/mach-msm/devices-qsd8x50.c                |  12 +-
 arch/arm/mach-msm/devices.h                        |  15 +-
 arch/arm/mach-msm/dma.c                            |   5 +-
 arch/arm/mach-msm/include/mach/board.h             |   5 -
 arch/arm/mach-msm/include/mach/clk.h               |   9 -
 arch/arm/mach-nspire/Kconfig                       |  16 +
 arch/arm/mach-nspire/Makefile                      |   2 +
 arch/arm/mach-nspire/Makefile.boot                 |   0
 arch/arm/mach-nspire/clcd.c                        | 119 ++++
 arch/arm/mach-nspire/clcd.h                        |  14 +
 arch/arm/mach-nspire/mmio.h                        |  20 +
 arch/arm/mach-nspire/nspire.c                      |  89 +++
 arch/arm/mach-shmobile/setup-r8a7790.c             |  28 +-
 arch/arm/mach-sti/Kconfig                          |  45 ++
 arch/arm/mach-sti/Makefile                         |   2 +
 arch/arm/mach-sti/board-dt.c                       |  48 ++
 arch/arm/mach-sti/headsmp.S                        |  44 ++
 arch/arm/mach-sti/platsmp.c                        | 117 ++++
 arch/arm/mach-sti/smp.h                            |  17 +
 arch/arm/mach-ux500/cache-l2x0.c                   |   3 +-
 arch/arm/plat-samsung/include/plat/cpu.h           |   8 +
 drivers/clk/samsung/Makefile                       |   1 +
 drivers/clk/samsung/clk-exynos5420.c               | 762 +++++++++++++++++++++
 drivers/clocksource/exynos_mct.c                   |  35 +-
 drivers/iommu/msm_iommu_dev.c                      |  20 +-
 drivers/mmc/host/msm_sdcc.c                        |  14 +-
 drivers/pinctrl/pinctrl-exynos.c                   | 118 ++++
 drivers/pinctrl/pinctrl-samsung.c                  |   2 +
 drivers/pinctrl/pinctrl-samsung.h                  |   1 +
 drivers/tty/serial/msm_serial.c                    |  35 +-
 drivers/tty/serial/samsung.c                       |   4 +-
 drivers/tty/serial/sh-sci.c                        | 104 ++-
 drivers/usb/phy/phy-msm-usb.c                      |  38 +-
 include/linux/serial_sci.h                         |  12 +-
 include/uapi/linux/serial_core.h                   |   3 +
 95 files changed, 4799 insertions(+), 790 deletions(-)
 create mode 100644 Documentation/arm/sti/overview.txt
 create mode 100644 Documentation/arm/sti/stih415-overview.txt
 create mode 100644 Documentation/arm/sti/stih416-overview.txt
 create mode 100644 Documentation/devicetree/bindings/arm/nspire.txt
 create mode 100644 Documentation/devicetree/bindings/clock/exynos5420-clock.txt
 create mode 100644 arch/arm/boot/dts/exynos5.dtsi
 create mode 100644 arch/arm/boot/dts/exynos5420-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/exynos5420-smdk5420.dts
 create mode 100644 arch/arm/boot/dts/exynos5420.dtsi
 create mode 100644 arch/arm/boot/dts/nspire-classic.dtsi
 create mode 100644 arch/arm/boot/dts/nspire-clp.dts
 create mode 100644 arch/arm/boot/dts/nspire-cx.dts
 create mode 100644 arch/arm/boot/dts/nspire-tp.dts
 create mode 100644 arch/arm/boot/dts/nspire.dtsi
 create mode 100644 arch/arm/boot/dts/st-pincfg.h
 create mode 100644 arch/arm/boot/dts/stih415-b2000.dts
 create mode 100644 arch/arm/boot/dts/stih415-b2020.dts
 create mode 100644 arch/arm/boot/dts/stih415-clock.dtsi
 create mode 100644 arch/arm/boot/dts/stih415-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/stih415.dtsi
 create mode 100644 arch/arm/boot/dts/stih416-b2000.dts
 create mode 100644 arch/arm/boot/dts/stih416-b2020.dts
 create mode 100644 arch/arm/boot/dts/stih416-clock.dtsi
 create mode 100644 arch/arm/boot/dts/stih416-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/stih416.dtsi
 create mode 100644 arch/arm/boot/dts/stih41x-b2000.dtsi
 create mode 100644 arch/arm/boot/dts/stih41x-b2020.dtsi
 create mode 100644 arch/arm/boot/dts/stih41x.dtsi
 create mode 100644 arch/arm/include/debug/nspire.S
 create mode 100644 arch/arm/include/debug/sti.S
 delete mode 100644 arch/arm/mach-msm/clock-7x30.h
 delete mode 100644 arch/arm/mach-msm/clock-debug.c
 create mode 100644 arch/arm/mach-nspire/Kconfig
 create mode 100644 arch/arm/mach-nspire/Makefile
 create mode 100644 arch/arm/mach-nspire/Makefile.boot
 create mode 100644 arch/arm/mach-nspire/clcd.c
 create mode 100644 arch/arm/mach-nspire/clcd.h
 create mode 100644 arch/arm/mach-nspire/mmio.h
 create mode 100644 arch/arm/mach-nspire/nspire.c
 create mode 100644 arch/arm/mach-sti/Kconfig
 create mode 100644 arch/arm/mach-sti/Makefile
 create mode 100644 arch/arm/mach-sti/board-dt.c
 create mode 100644 arch/arm/mach-sti/headsmp.S
 create mode 100644 arch/arm/mach-sti/platsmp.c
 create mode 100644 arch/arm/mach-sti/smp.h
 create mode 100644 drivers/clk/samsung/clk-exynos5420.c


From arnd at arndb.de  Tue Jul  2 14:59:08 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 2 Jul 2013 20:59:08 +0200
Subject: [GIT PULL 1/7] ARM SoC non-cricitical bug fixes
In-Reply-To: <201307022055.50717.arnd@arndb.de>
References: <201307022055.50717.arnd@arndb.de>
Message-ID: <201307022059.09216.arnd@arndb.de>

The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10:

  Linux 3.10-rc5 (2013-06-08 17:41:04 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-non-critical-for-linus

for you to fetch changes up to 6b9a39de73490abb93a0b48a5e6c417c518f3a59:

  Merge tag 'at91-fixes' of git://github.com/at91linux/linux-at91 into next/fixes-non-critical (2013-06-27 15:03:13 +0200)

----------------------------------------------------------------

ARM SoC non-critical bug fixes

These are various bug fixes that were not considered important enough
for merging into 3.10. The majority of the ARM fixes are for the OMAP
and at91 platforms, and there is another set of bug fixes for device
drivers that resolve 'randconfig' build errors and that the subsystem
maintainers either did not pick up or preferred to get merged through
the arm-soc tree.

----------------------------------------------------------------
Alexandre Belloni (1):
      ARM: at91: Fix link breakage when !CONFIG_PHYLIB

Arnd Bergmann (12):
      hwrng: bcm2835: fix MODULE_LICENSE tag
      [SCSI] nsp32: use mdelay instead of large udelay constants
      mtd: omap2: allow bulding as a module
      X.509: do not emit any informational output
      clocksource: kona: adapt to CLOCKSOURCE_OF_DECLARE change
      ARM: sirf: use CONFIG_SIRF rather than CONFIG_PRIMA2 where necessary
      Merge tag 'at91-fixes' of git://github.com/at91linux/linux-at91 into next/fixes-non-critical
      Merge tag 'non-critical-fixes-1' of git://git.kernel.org/.../kgene/linux-samsung into next/fixes-non-critical
      cpuidle: calxeda: select ARM_CPU_SUSPEND
      ARM: mxs: stub out mxs_pm_init for !CONFIG_PM
      ARM: mxs: don't select HAVE_PWM
      Merge tag 'at91-fixes' of git://github.com/at91linux/linux-at91 into next/fixes-non-critical

Axel Lin (1):
      irqchip: renesas-irqc: Fix irqc_probe error handling

Barry Song (3):
      ARM: prima2: fix a checkpatch issue
      arm: prima2: use of_platform_populate instead of of_platform_bus_probe
      MAINTAINERS: ARM: SIRF: add the source code tree path

Bastian Hecht (1):
      irqchip: Add irqchip_init dummy function

Chen Gang (1):
      arch: arm: mach-msm: using strlcpy instead of strncpy

Daniel Lezcano (1):
      ARM: at91: cpuidle: Fix target_residency

Doug Anderson (1):
      MAINTAINERS: Add exynos filename match to ARM/S5P EXYNOS ARM ARCHITECTURES

Ezequiel Garcia (1):
      ARM: mvebu: fix length of ethernet registers in mv78260 dtsi

Hugo Villeneuve (1):
      ARM: davinci: remove stale SFFSDR maintainer name

Jean-Christophe PLAGNIOL-VILLARD (1):
      ARM: at91: fix at91_extern_irq usage for non-dt boards

Nicolas Ferre (4):
      ARM: at91/PMC: sama5d3 family doesn't have a PLLB
      ARM: at91/PMC: at91sam9n12 family has a PLLB
      ARM: at91/PMC: fix at91sam9n12 USB FS init
      ARM: at91/PMC: use at91_usb_rate() for UTMI PLL

Olof Johansson (7):
      Merge tag 'fixes-non-3.11-1' of git://git.infradead.org/users/jcooper/linux into next/fixes-non-critical
      Merge tag 'sirf-arm-soc-v3.10-fixes' of git://gitorious.org/sirfprima2-kernel/sirfprima2-kernel into next/fixes-non-critical
      Merge tag 'renesas-intc-external-irq-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/fixes-non-critical
      Merge tag 'omap-for-v3.11/fixes-non-critical-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/fixes-non-critical
      Merge tag 'davinci-for-v3.11/board' of git://git.kernel.org/.../nsekhar/linux-davinci into next/fixes-non-critical
      Merge tag 'msm-fix-for-3.11' of git://git.kernel.org/.../davidb/linux-msm into next/fixes-non-critical
      Merge tag 'fixes-non-3.11-2' of git://git.infradead.org/users/jcooper/linux into next/fixes-non-critical

Peter Ujfalusi (3):
      ARM: OMAP2+: devices: Do not print error when McPDM hwmod lookup fails
      ARM: OMAP2+: devices: Do not print error when DMIC hwmod lookup fails
      ARM: OMAP2+: devices: Do not print error when dss_hdmi hwmod lookup fails

Roger Quadros (1):
      ARM: OMAP2+: omap-usb-host: Fix memory leaks

Sebastian Andrzej Siewior (1):
      arm/omap: use const char properly

Stephen Boyd (3):
      ARM: dts: msm: Fix bad register addresses
      mfd: ssbi: Add MODULE_DEVICE_TABLE
      gpio: msm-v1: Remove errant __devinit to fix compile

Stephen Warren (1):
      ARM: tegra: fix section mismatch in tegra_pmc_parse_dt

Suman Anna (1):
      ARM: OMAP2+: control: add OMAP5 support for dsp boot programming

Syam Sidhardhan (1):
      ARM: prima2: Replace include linux/module.h with linux/export.h

Thomas Petazzoni (2):
      arm: mvebu: fix length of SATA registers area in .dtsi
      arm: mvebu: fix length of Ethernet registers area in .dtsi

Tomi Valkeinen (3):
      ARM: OMAP: fix dsi regulator names
      ARM: OMAP: add vdds_dsi supply for omapdss_dpi.0
      ARM: OMAP: add vdds_sdi supply for omapdss_sdi.0

Tony Lindgren (2):
      Merge branch 'dss-regulator' into omap-for-v3.11/fixes-non-critical
      ARM: OMAP2+: Fix serial init for device tree based booting

Wenyou Yang (1):
      ARM: at91: Change the internal SRAM memory type MT_MEMORY_NONCACHED

 MAINTAINERS                                  |   2 +
 arch/arm/Makefile                            |   2 +-
 arch/arm/boot/dts/armada-370-xp.dtsi         |   6 +-
 arch/arm/boot/dts/armada-xp-mv78260.dtsi     |   2 +-
 arch/arm/boot/dts/armada-xp-mv78460.dtsi     |   2 +-
 arch/arm/boot/dts/armada-xp.dtsi             |   2 +-
 arch/arm/boot/dts/msm8660-surf.dts           |   4 +-
 arch/arm/boot/dts/msm8960-cdp.dts            |   2 +-
 arch/arm/mach-at91/Kconfig                   |   1 +
 arch/arm/mach-at91/at91rm9200.c              |   8 +-
 arch/arm/mach-at91/at91sam9260.c             |   4 +-
 arch/arm/mach-at91/at91sam9261.c             |   4 +-
 arch/arm/mach-at91/at91sam9263.c             |   2 +-
 arch/arm/mach-at91/at91sam9g45.c             |   2 +-
 arch/arm/mach-at91/at91sam9rl.c              |   2 +-
 arch/arm/mach-at91/at91x40.c                 |   7 +-
 arch/arm/mach-at91/board-dt-sama5.c          |   3 +-
 arch/arm/mach-at91/clock.c                   |  30 ++++++--
 arch/arm/mach-at91/cpuidle.c                 |   2 +-
 arch/arm/mach-at91/generic.h                 |   2 +-
 arch/arm/mach-at91/include/mach/at91_pmc.h   |   3 +
 arch/arm/mach-at91/irq.c                     |   9 ++-
 arch/arm/mach-at91/pm.c                      |   2 +-
 arch/arm/mach-at91/setup.c                   |   4 +-
 arch/arm/mach-at91/soc.h                     |   1 +
 arch/arm/mach-davinci/board-sffsdr.c         |   1 -
 arch/arm/mach-msm/clock-debug.c              |   2 +-
 arch/arm/mach-mxs/Kconfig                    |   2 -
 arch/arm/mach-mxs/pm.h                       |   4 +
 arch/arm/mach-omap2/board-cm-t35.c           |   3 +-
 arch/arm/mach-omap2/board-devkit8000.c       |   1 +
 arch/arm/mach-omap2/board-ldp.c              |   3 +-
 arch/arm/mach-omap2/board-omap3pandora.c     |   1 +
 arch/arm/mach-omap2/board-rx51-peripherals.c |   1 +
 arch/arm/mach-omap2/control.c                |   1 +
 arch/arm/mach-omap2/devices.c                |  12 +--
 arch/arm/mach-omap2/id.c                     |   2 +-
 arch/arm/mach-omap2/serial.c                 |   3 +
 arch/arm/mach-omap2/twl-common.c             |   1 +
 arch/arm/mach-omap2/usb-host.c               | 106 ++++++++++++++-------------
 arch/arm/mach-prima2/common.c                |  17 +----
 arch/arm/mach-prima2/pm.c                    |   2 +-
 arch/arm/mach-tegra/pmc.c                    |   2 +-
 drivers/char/hw_random/bcm2835-rng.c         |   2 +-
 drivers/clk/Makefile                         |   2 +-
 drivers/clocksource/bcm_kona_timer.c         |  15 +---
 drivers/cpuidle/Kconfig                      |   1 +
 drivers/gpio/gpio-msm-v1.c                   |   2 +-
 drivers/i2c/busses/Kconfig                   |   2 +-
 drivers/irqchip/irq-renesas-irqc.c           |   4 +-
 drivers/mtd/nand/Kconfig                     |   2 +-
 drivers/scsi/nsp32.c                         |   2 +-
 drivers/spi/Kconfig                          |   2 +-
 drivers/ssbi/ssbi.c                          |   1 +
 drivers/tty/serial/Kconfig                   |   2 +-
 include/linux/irqchip.h                      |   4 +
 lib/build_OID_registry                       |   2 -
 57 files changed, 170 insertions(+), 145 deletions(-)


From arnd at arndb.de  Tue Jul  2 15:18:21 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 2 Jul 2013 21:18:21 +0200
Subject: [GIT PULL 0/7] ARM SoC updates for 3.11
Message-ID: <201307022118.21872.arnd@arndb.de>

Hi Linus,

Here are the pull requests for arm-soc for 3.11. Things are not all that
different from the previous times, but we decided to reduce the number of
branches a bit, which simplified the work for us and resulted in fewer
conflicts between our branches.

While in 3.10 there were lots of platforms converted to "multiplatform",
that trend did not continue this time. Instead, we have four new
SoC platforms that got added, and a couple of platforms have gotten
smaller as we remove support for non-devicetree based booting.

Changes to the device tree source files now make up the larges chunk
of the total changesets, which I consider a good thing. Once the 
process of converting platforms and drivers to devicetree has completed
enough, those files will get moved out of the kernel and get maintained
as a separate project.

For reference, a merge of all seven branches is available at
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-linus

I believe this merge window has the larges number of ARM related changes
so far, here are some overall statistics:

* 1241 non-merge changesets

* 132 branches merged into arm-soc

* 162 individual contributors

* 1105 files changed, 62057 insertions, 34538 deletions

* Top contributors in number of patches:

 Laurent Pinchart (105)
 Lee Jones (86)
 Linus Walleij (67)
 Thomas Petazzoni (55)
 Kuninori Morimoto (50)
 Tomasz Figa (37)
 Maxime Ripard (32)
 Alexander Shiyan (29)
 Arnd Bergmann (26)
 Jean-Christophe PLAGNIOL-VILLARD (23)
 Sergei Shtylyov (21)
 Magnus Damm (19)
 Guennadi Liakhovetski (18)

* Interesting note:

  Almost all of the people above are European, some Asian, and no American,
  contrary to the usual distribution of geographies we have in other parts
  of the kernel.

* Dirstat:

   0.8% Documentation/devicetree/bindings/clock/
   1.5% Documentation/devicetree/bindings/
  21.8% arch/arm/boot/dts/
   0.9% arch/arm/configs/
   0.4% arch/arm/include/asm/
   0.7% arch/arm/mach-at91/
   0.9% arch/arm/mach-clps711x/
   1.4% arch/arm/mach-exynos/include/mach/
   6.3% arch/arm/mach-exynos/
   1.9% arch/arm/mach-imx/
   0.7% arch/arm/mach-integrator/
   0.8% arch/arm/mach-msm/
  18.9% arch/arm/mach-omap2/
   1.1% arch/arm/mach-shmobile/include/mach/
   4.2% arch/arm/mach-shmobile/
   1.1% arch/arm/mach-u300/include/mach/
   1.3% arch/arm/mach-u300/
   1.2% arch/arm/mach-ux500/
   5.2% arch/arm/
   0.6% drivers/bus/
   1.7% drivers/clk/mvebu/
   1.2% drivers/clk/samsung/
   0.8% drivers/clk/zynq/
   1.9% drivers/clk/
   0.8% drivers/dma/
   0.6% drivers/gpio/
   1.8% drivers/pci/host/
  13.1% drivers/pinctrl/sh-pfc/
   0.8% drivers/pinctrl/
   0.5% drivers/usb/
   1.5% drivers/
   1.0% include/dt-bindings/clock/
   0.6% include/linux/

* List of all pull requests we got for each of our branches

next/fixes-non-critical
	mvebu/fixes-non-critical
		git://git.infradead.org/users/jcooper/linux.git tags/fixes-non-3.11-1
	sirf/fixes-non-critical
		git://gitorious.org/sirfprima2-kernel/sirfprima2-kernel.git tags/sirf-arm-soc-v3.10-fixes
	omap/fixes-non-critical
		git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/fixes-non-critical-signed
	davinci/board
		git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.11/board
	msm/fixes
		git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git tags/msm-fix-for-3.11
	patches
		MAINTAINERS: ARM: SIRF: add the source code tree path
		ARM: dts: msm: Fix merge resolution
		clocksource: kona: adapt to CLOCKSOURCE_OF_DECLARE change
		X.509: do not emit any informational output
		mtd: omap2: allow bulding as a module
		[SCSI] nsp32: use mdelay instead of large udelay constants
		hwrng: bcm2835: fix MODULE_LICENSE tag
		ARM: sirf: use CONFIG_SIRF rather than CONFIG_PRIMA2 where necessary
	at91/fixes
		git://github.com/at91linux/linux-at91.git tags/at91-fixes
	exynos/fixes
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/non-critical-fixes-1
	patches
		ARM: mxs: don't select HAVE_PWM
		ARM: mxs: stub out mxs_pm_init for !CONFIG_PM
		cpuidle: calxeda: select ARM_CPU_SUSPEND
	at91/fixes2
		git://github.com/at91linux/linux-at91.git tags/at91-fixes

next/cleanup
	at91/cleanup
		git://github.com/at91linux/linux-at91.git tags/at91-cleanup
	machdesc/cleanup
		git://github.com/mripard/linux.git tags/arm-soc-cleanups-for-3.11
	mvebu/cleanup
		git://git.infradead.org/users/jcooper/linux.git tags/cleanup-3.11-3
	dt/pci-helpers
		git://git.infradead.org/users/jcooper/linux.git tags/of_pci-3.11
	omap/cleanup
		git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/cleanup-signed
	mvebu/cleanup4
		git://git.infradead.org/users/jcooper/linux.git tags/cleanup-3.11-4
	msm/cleanup
		git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git tags/msm-fix-for-3.11
	sunxi/core
		git://github.com/mripard/linux.git tags/sunxi-core-for-3.11
	zynq/cleanup
		git://git.xilinx.com/linux-xlnx.git tags/zynq-cleanup-for-3.11
	at91/cleanup2
		git://github.com/at91linux/linux-at91.git tags/at91-cleanup
	picoxcell/cleanup
		git://github.com/jamieiles/linux-2.6-ji.git picoxcell-next
	omap/pm-serial-cleanup
		git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap-for-v3.11/pm-serial
	omap/pm-voltdomain-cleanup
		git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/pm-voltdomain-signed
	omap/dma-cleanup
		git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/dma-signed
	samsung/cleanup
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-cleanup-1
	bcm/cleanup
		git://github.com/broadcom/bcm11351.git armsoc/for-3.11/cleanups

next/soc
	mvebu/soc
		git://git.infradead.org/users/jcooper/linux.git tags/soc-3.11-2
	mvebu/defconfig
		git://git.infradead.org/users/jcooper/linux.git tags/defconfig-3.11-3
	mvebu/pcie
		git://git.infradead.org/users/jcooper/linux.git tags/pcie-3.11-2
	mvebu/pcie-kirkwood
		git://git.infradead.org/users/jcooper/linux.git tags/pcie_kw-3.11
	mvebu/pcie2
		git://git.infradead.org/users/jcooper/linux.git tags/pcie_bridge-3.11
	mvebu/clk-cleanup
		git://git.infradead.org/users/jcooper/linux.git tags/seb_clk-3.11
	vexpress/dual-cluster
		git://git.linaro.org/people/nico/linux VExpress_DCSCB
		depends on depends/rmk-devel-stable
		+patch "drivers/bus: arm-cci: fix combined ARMv6+v7 build"
	zynq/clk
		git://git.xilinx.com/linux-xlnx tags/zynq-clk-for-3.11
	mvebu/pcie-kirkwood2
		git://git.infradead.org/users/jcooper/linux.git tags/pcie_kw-3.11-2
	renesas/pinmux-gpio
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-pinmux-for-v3.11
	renesas/soc
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-for-v3.11
	clps711x/soc
		patches
			GPIO: clps711x: Rewrite driver for using generic GPIO cod
			GPIO: clps711x: Add DT support
			ARM: clps711x: Re-add GPIO support
			ARM: clps711x: Remove NEED_MACH_MEMORY_H dependency
			ARM: clps711x: Set PLL clock to zero if we work from 13 mHz sourc
			ARM: clps711x: autcpu12: Move LCD DPOT definitions to board file
			ARM: clps711x: autcpu12: Add support for NOR flash
			ARM: clps711x: autcpu12: Special driver for handling memory is re
			ARM: clps711x: autcpu12: Move remaining specific definitions to b
			ARM: clps711x: p720t: Define PLD registers as GPIOs
			ARM: clps711x: Move specific definitions from hardware.h to board
			ARM: clps711x: Replace "arch_initcall" in common code with ".init
			ARM: clps711x: Add clocksource framework
			ARM: clps711x: Optimize interrupt handling
			ARM: clps711x: edb7211: Add support for I2C
			ARM: clps711x: edb7211: Control LCD backlight via PWM
			ARM: clps711x: Add support for SYSCON driver
			ARM: clps711x: Update defconfig
	patches
		ARM: socfpga: Add support to gate peripheral clocks
		ARM: socfpga: Add syscon to be part of socfpga
	samsung/s3c24xx-arch
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/s3c24xx-arch-1
	omap/pm
		git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/pm-signed
	omap/soc
		git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/gpmc-signed
	omap/omap5
		git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/soc-signed
	mvebu/regmap
		git://git.infradead.org/users/jcooper/linux.git tags/regmap-3.11
			depends on cleanup and fixes-non-critical branches
	renesas/usb
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-phy-rcar-usb-for-v3.11
	renesas/soc2
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc2-for-v3.11
	tegra/soc
		git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.11-soc
	keystone/soc
		git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone-soc-for-arm-soc
	integrator/pci
		git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git tags/integrator-pci-for-arm-soc
	u300/multiplatform
		git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git tags/u300-multiplatform
	imx/soc
		git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-soc-3.11
	davinci/soc
		git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.11/soc-v2
i	sunxi/defconfig
		git://github.com/mripard/linux.git tags/sunxi-defconfig-for-3.11
	sunxi/core2
		git://github.com/mripard/linux.git tags/sunxi-core-for-3.11-2
	omap/soc2
		git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/soc-part2-signed
	samsung/exynos-arch
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/exynos-arch-2
	rockchip/soc
		git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v3.11-rockchip-basics
	renesas/soc-cleanup
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-cleanup-boot-for-v3.11
	patches
		ARM: dts: Add pcie controller node for exynos5440-ssdk5440
		ARM: dts: Add pcie controller node for Samsung EXYNOS5440 SoC
		ARM: EXYNOS: Enable PCIe support for Exynos5440
		pci: Add PCIe driver for Samsung Exynos
		ARM: integrator: let pciv3 use mem/premem from device tree
		ARM: integrator: set local side PCI addresses right

next/boards
	mvebu/boards
		  git://git.infradead.org/users/jcooper/linux.git tags/boards-3.11-2
	renesas/defconfig
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-defconfig-for-v3.11
	renesas/boards
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards-for-v3.11
		depends on renesas/pinmux-gpio
		depends on renesas/soc
	ux500/core
		git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git tags/ux500-core-for-arm-soc
	ux500/pinctrl
		git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git tags/ux500-pinctrl-for-arm-soc
	patch
		"ARM: ux500: board-mop500: remove unused pin modes"
	bcm2835/defconfig
		git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git bcm2835-for-3.11-defconfig
	renesas/defconfig2
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-defconfig2-for-v3.11
	tegra/defconfig
		git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.11-defconfig
	omap/boards
		git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/mailbox-signed
	samsung/exynos-remove-nondt
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/remove-nondt-exynos-3
	samsung/defconfig
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-defconfig-1
	renesas/boards
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards2-for-v3.11
	zynq/defconfig
		git://git.xilinx.com/linux-xlnx.git tags/zynq-defconfig-for-3.11
	mvebu/regmap2
		git://git.infradead.org/users/jcooper/linux.git tags/regmap-3.11-2
	patches
		ARM: multiplatform: always pick one CPU type
		ARM: imx: select syscon for IMX6SL
		ARM: keystone: select ARM_ERRATA_798181 only for SMP
		ARM: imx: Synertronixx scb9328 needs to select SOC_IMX1
		ARM: OMAP2+: AM43x: resolve SMP related build error
		ARM: keystone: Move CPU bringup code to dedicated asm file
	davinci/soc2
		git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.11/soc-2
	omap/voltdm
		git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.11/fixes/omap5-voltdm

next/dt
	nomadik/dt
		git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git tags/nomadik-dt-for-arm-soc
	mvebu/dt
		git://git.infradead.org/users/jcooper/linux.git tags/dt-3.11-3
	patch
		"ARM: nomadik: fix clocksource warning"
	at91/dt
		git://github.com/at91linux/linux-at91.git tags/at91-dt
	vt8500/dt
		git://github.com/linux-wmt/linux-vtwm vt8500/dts-3.11
	cleanup/dts-cpus
		git://linux-arm.org/linux-2.6-lp dts-cpus-updates
	patch
		"ARM: dts: add missing cpu #address-cell values"
	mvebu/dt4
		git://git.infradead.org/users/jcooper/linux.git tags/dt-3.11-4
	renesas/dt
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-for-v3.11
	patches
		ARM: socfpga: dts: Add ethernet bindings for SOCFPGA
		ARM: socfpga: dts: Add gate-clock bindings
	samsung/s3c24xx-dt
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/s3c24xx-dt-1
	samsung/exynos-dt
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/exynos-dt-1
	mvebu/dt5
		git://git.infradead.org/users/jcooper/linux.git tags/dt-3.11-5
	ux500/dt
		git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git tags/ux500-dt-for-arm-soc
	bcm2835/dt
		git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git bcm2835-for-3.11-dt
	tegra/dt
		git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.11-dt
	sunxi/dt
		git://github.com/mripard/linux.git tags/sunxi-dt-for-3.11
	at91/dt2
		git://github.com/at91linux/linux-at91.git tags/at91-dt
	zynq/dt
		git://git.xilinx.com/linux-xlnx.git tags/zynq-dt-for-3.11
	mxs/dt
		git://git.linaro.org/people/shawnguo/linux-2.6.git tags/mxs-dt-3.11
	imx/dt
		git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-dt-3.11
	sunxi/dt2
		git://github.com/mripard/linux.git tags/sunxi-dt-for-3.11-2
	nomadik/dt2
		git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git tags/nomadik-dt-2
	samsung/exynos-dt2
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/exynos-dt-2
	samsung/s3c24xx-dt2
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/s3c24xx-dt-2
	omap/dt
		git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts
	bcm/dt
		git://github.com/broadcom/bcm11351.git armsoc/for-3.11/dt
	renesas/dt
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt2-for-v3.11
	mvebu/dt6
		git://git.infradead.org/users/jcooper/linux.git tags/dt-3.11-6
	at91/dt3
		git://github.com/at91linux/linux-at91.git tags/at91-dt

next/drivers
	ux500/dma40
		git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git tags/ux500-dma40-for-arm-soc
	timer/dw_apb_timer_of
		git://github.com/mmind/linux-rockchip.git tags/dw_apb_timer_of
	samsung/s3c24xx-drivers
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/s3c24xx-driver-1
	omap/gpmc
		git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/gpmc-signed
	ux500/clksrc
		git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git tags/ux500-clksrc-for-arm-soc
	ux500/dma540_2
		git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git tags/ux500-dma40-for-arm-soc-2
	renesas/rcar-gpio
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-gpio-rcar-for-v3.11
		depends on renesas/pinmux-gpio
	at91/drivers
		git://github.com/at91linux/linux-at91.git tags/at91-drivers
	patch
		gpio: rcar: fix gpio_rcar_of_table
	omap/gpmc2
		git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/gpmc-part2-signed
	drivers/mailbox
		git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/mailbox-signed
	samsung/common-clk-audio
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/common-clk-audio
	samsung/s3c24xx-pinctrl2
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/s3c24xx-pinctrl-2
	ux500/cleanup patches
		ARM: ux500: Provide a AB8500 GPIO Device Tree node
		ARM: ux500: Correct the EN_3v3 regulator's on/off GPIO
		ARM: ux500: Remove mop500_snowball_ethernet_clock_enable()
	renesas/pinmux2
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-pinmux2-for-v3.11
	renesas/gpio-rcar2
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-gpio-rcar2-for-v3.11

next/late
	renesas/cleanup
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-cleanup-for-v3.11
	samsung/exynos5420
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/soc-exynos5420-1
	samsung/soc2
		git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/soc-exynos5420-2
	nspire/soc patches 
		arm: Add Initial TI-Nspire support
		arm: Add device trees for TI-Nspire hardware
	sti/soc patches
		ARM: sti: Add STiH415 SOC support
		ARM: sti: Add STiH416 SOC support
		ARM: sti: Add DEBUG_LL console support
		ARM: stih41x: Add B2000 board support
		ARM: stih41x: Add B2020 board support
	rensas/sh-sci
		git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-sh-sci-for-v3.11
	patches
		ARM: ux500: bail out on alien cpus
	davinci/dt
		git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci davinci-for-v3.11/dt
	msm/clock
		git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git tags/msm-clock-for-3.11b
		based on msm/fixes to avoid conflict


From arnd at arndb.de  Tue Jul  2 15:12:13 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 2 Jul 2013 21:12:13 +0200
Subject: [GIT PULL 6/7] ARM SoC driver specific changes
In-Reply-To: <201307022055.50717.arnd@arndb.de>
References: <201307022055.50717.arnd@arndb.de>
Message-ID: <201307022112.13518.arnd@arndb.de>

The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10:

  Linux 3.10-rc5 (2013-06-08 17:41:04 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/drivers-for-linus

for you to fetch changes up to 5c913a9a9772f4b434aaea7328836419287b5d1c:

  Merge tag 'ux500-dma40-for-arm-soc-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into next/drivers (2013-06-25 11:20:15 -0700)

----------------------------------------------------------------

ARM SoC driver specific changes

These changes are all driver specific and cross over between arm-soc
contents and some other subsystem, in these cases cpufreq, crypto,
dma, pinctrl, mailbox and usb, and the subsystem owners agreed to
have these changes merged through arm-soc. As we proceed to untangle
the dependencies between platform code and driver code, the amount of
changes in this category is fortunately shrinking, for 3.11 we have
16 branches here and 101 non-merge changesets, the majority of which
are for the stedma40 dma engine driver used in the ux500 platform.
Cleaning up that code touches multiple subsystems, but gets rid
of the dependency in the end.

The mailbox code moved out from mach-omap2 to drivers/mailbox
is an intermediate step and is still omap specific at the moment.
Patches exist to generalize the subsystem and add other drivers
with the same API, but those did not make it for 3.11.

Conflicts:
* In cpu-db8500.c results from the removal of the u8500_of_init_devices
  function in combination with the split of u8500_auxdata_lookup.

* In arch/arm/mach-omap2/devices.c, the includes got reshuffled.
  we need to keep linux/wl12xx.h and linux/platform_data/mailbox-omap.h.


----------------------------------------------------------------

Arnd Bergmann (10):
      gpio: rcar: fix gpio_rcar_of_table
      Merge tag 'omap-for-v3.11/gpmc-part2-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/drivers
      Merge tag 'omap-for-v3.11/mailbox-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/drivers
      Merge branches 'samsung/exynos-dt2' and 'samsung/s3c24xx-dt2' into next/drivers
      Merge tag 'common-clk-audio' of git://git.kernel.org/.../kgene/linux-samsung into next/drivers
      Merge tag 's3c24xx-pinctrl-2' of git://git.kernel.org/.../kgene/linux-samsung into next/drivers
      Merge branch 'ux500/cleanup' into next/drivers
      Merge tag 'renesas-pinmux2-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/drivers
      Merge tag 'renesas-gpio-rcar2-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/drivers
      Merge tag 'drivers-for-linus' into for-linus

Christoph Fritz (1):
      ARM: OMAP2+: nand: reorganize gpmc timing values

Fabio Baltieri (8):
      clocksource: dbx500-prcmu: comment cleanup
      dmaengine: ste_dma40: Declare memcpy config as static
      crypto: ux500/hash: use readl on iomem addresses
      crypto: ux500/hash: add missing static qualifiers
      crypto: ux500/crypt: add missing __iomem qualifiers
      crypto: ux500: use dmaengine_device_control API
      crypto: ux500: use dmaengine_prep_slave_sg API
      crypto: ux500: use dmaengine_submit API

Guennadi Liakhovetski (2):
      pinctrl: r8a73a4: add pinmux data for MMCIF and SDHI interfaces
      pinctrl: r8a7790: fix two pin numbers

Gupta Pekon (1):
      ARM: OMAP2+: gpmc: get number of useable GPMC chip-selects via DT

Heiko Stuebner (2):
      pinctrl: Add pinctrl-s3c24xx driver
      pinctrl: s3c24xx: use correct header for chained_irq functions

Jean-Christophe PLAGNIOL-VILLARD (3):
      USB: gadget: atmel_usba: move global struct usba_ep usba_ep to struct usba_udc
      USB: gadget: atmel_usba: allow multi instance
      USB: gadget: atmel_usba: add DT support

Jon Hunter (1):
      ARM: dts: OMAP2+: Simplify NAND support

Kukjin Kim (4):
      Merge branch 'v3.11-next/driver-gpio' into v3.11-next/s3c24xx-driver
      Merge branch 'v3.11-next/driver-pinctrl' into v3.11-next/s3c24xx-driver
      Merge branch 'v3.11-next/driver-cpufreq' into v3.11-next/s3c24xx-driver
      Merge branch 'v3.11-next/s3c24xx-dt-2' into v3.11-next/dt-n-clk-audio

Kuninori Morimoto (1):
      sh-pfc: r8a7778: tidyup MMC_D1 pin

Laurent Pinchart (3):
      gpio-rcar: Add DT support
      gpio-rcar: Reference core gpio documentation in the DT bindings
      gpio-rcar: Remove #ifdef CONFIG_OF around OF-specific sections

Lee Jones (57):
      dmaengine: ste_dma40: Assign memcpy channels in the driver
      dmaengine: ste_dma40: Move default memcpy configs into the driver
      dmaengine: ste_dma40: Rectify incorrect configuration validation checking
      dmaengine: ste_dma40: Amalgamate DMA source and destination channel numbers
      ARM: ux500: Strip out duplicate USB DMA configuration
      dmaengine: ste_dma40: Remove home-brew MAX() macro
      ARM: ux500: Remove unused 'data_width' attributes from SDI DMA configs
      ARM: ux500: Remove unused 'data_width' attributes from SSP DMA configs
      ARM: ux500: Remove unused 'data_width' attributes from UART DMA configs
      ARM: ux500: Remove superfluous 'psize' attribute from Audio platform data
      dmaengine: ste_dma40: Calculate number of logical channels from physical ones
      dmaengine: ste_dma40: Remove 'always true' checking
      dmaengine: ste_dma40: Move rev error-check up to revision acquisition
      dmaengine: ste_dma40: Also report the number of logical channels
      dmaengine: ste_dma40: Allocate plat_data on declaration
      dmaengine: ste_dma40: Allow driver to be probe()able when DT is enabled
      dmaengine: ste_dma40: Supply full Device Tree parsing support
      ARM: ux500: Pass remnant platform data though to DMA40 driver
      dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
      dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
      dmaengine: ste_dma40: Don't configure runtime configurable setup during allocate
      ARM: ux500: Stop passing UART's platform data for Device Tree boots
      dmaengine: ste_dma40: Only use addresses passed as configuration information
      dmaengine: ste_dma40: Remove redundant address fetching function
      ARM: ux500: Remove DMA address look-up table
      dmaengine: ste_dma40: Correct copy/paste error
      ARM: ux500: Remove unnecessary attributes from DMA channel request pdata
      crypto: ux500/hash - Prepare clock before enabling it
      crypto: ux500/hash - Set DMA configuration though dma_slave_config()
      ARM: ux500: Stop passing Hash DMA channel config information though pdata
      crypto: ux500/cryp - Prepare clock before enabling it
      crypto: ux500/cryp - Set DMA configuration though dma_slave_config()
      ARM: ux500: Stop passing Cryp DMA channel config information though pdata
      crypto: ux500/[cryp|hash] - Show successful start-up in the bootlog
      ARM: ux500: Register Cryp and Hash platform drivers on Snowball
      usb: musb: ux500: move channel number knowledge into the driver
      usb: musb: ux500: move the MUSB HDRC configuration into the driver
      usb: musb: ux500: take the dma_mask from coherent_dma_mask
      usb: musb: ux500: harden checks for platform data
      usb: musb: ux500: attempt to find channels by name before using pdata
      usb: musb: ux500: add device tree probing support
      ARM: ux500: Remove ux500-musb platform registation when booting with DT
      ARM: ux500: Remove empty function u8500_of_init_devices()
      dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
      ARM: ux500: Replace ST-E's home-brew DMA direction definition with the generic one
      dmaengine: ste_dma40: Replace ST-E's home-brew DMA direction defs with generic ones
      ARM: ux500: Remove recently unused stedma40_xfer_dir enums
      dmaengine: ste_dma40_ll: Use the BIT macro to replace ugly '(1 << x)'s
      dmaengine: ste_dma40: Convert data_width from register bit format to value
      dmaengine: ste_dma40_ll: Replace meaningless register set with comment
      dmaengine: ste_dma40: Allow memcpy channels to be configured from DT
      ARM: ux500: Stop passing DMA platform data though AUXDATA
      dmaengine: ste_dma40: Fetch the number of physical channels from DT
      dmaengine: ste_dma40: Fetch disabled channels from DT
      ARM: ux500: Provide a AB8500 GPIO Device Tree node
      ARM: ux500: Correct the EN_3v3 regulator's on/off GPIO
      ARM: ux500: Remove mop500_snowball_ethernet_clock_enable()

Linus Walleij (1):
      dmaengine: ste_dma40: Fix up static memcpy event lines

Mark Jackson (1):
      ARM: OMAP2+: Allow NAND transfer mode to be specified in DT

Olof Johansson (9):
      Merge tag 'ux500-dma40-for-arm-soc' of git://git.kernel.org/.../linusw/linux-stericsson into next/drivers
      Merge tag 'dw_apb_timer_of' of git://github.com/mmind/linux-rockchip into next/drivers
      Merge tag 's3c24xx-driver-1' of git://git.kernel.org/.../kgene/linux-samsung into next/drivers
      Merge tag 'omap-for-v3.11/gpmc-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/drivers
      Merge tag 'ux500-clksrc-for-arm-soc' of git://git.kernel.org/.../linusw/linux-stericsson into next/drivers
      Merge tag 'ux500-dma40-for-arm-soc-2' of git://git.kernel.org/.../linusw/linux-stericsson into next/drivers
      Merge tag 'renesas-gpio-rcar-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/drivers
      Merge tag 'at91-drivers' of git://github.com/at91linux/linux-at91 into next/drivers
      Merge tag 'ux500-dma40-for-arm-soc-3' of git://git.kernel.org/.../linusw/linux-stericsson into next/drivers

Padmavathi Venna (6):
      ARM: dts: use #include for all device trees for Samsung
      clk: samsung: register audio subsystem clocks using common clock framework
      ARM: dts: add Exynos audio subsystem clock controller node
      ARM: dts: add clock provider information for i2s controllers in Exynos5250
      ARM: dts: Update Samsung I2S documentation
      clk: exynos5250: Add enum entries for divider clock of i2s1 and i2s2

Rabin Vincent (1):
      clocksource: dbx500-prcmu: use relaxed readl variant

Suman Anna (6):
      omap: mailbox: check iomem resource before dereferencing it
      omap: mailbox: call request_irq after mbox queues are allocated
      omap: mailbox: correct the argument type for irq ops
      ARM: OMAP2+: mbox: remove dependencies with soc.h
      ARM: OMAP2+: add user and fifo info to mailbox platform data
      mailbox/omap: move the OMAP mailbox framework to drivers

Sylwester Nawrocki (1):
      gpio: samsung: Remove OF support for s3c24xx

Tony Lindgren (1):
      Merge tag 'omap-mailbox-for-v3.11' of git://github.com/sumananna/mailbox into omap-for-v3.11/mailbox

Ulrich Hecht (1):
      sh-pfc: r8a7790: add HSCIF pin groups

Viresh Kumar (1):
      cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq

Wei Yongjun (1):
      dmaengine: ste_dma40: fix error return code in d40_probe()

avinash philip (2):
      ARM: OMAP2+: gpmc: Converts GPMC driver to pm_runtime capable
      ARM: OMAP2+: gpmc: Low power transition support

 Documentation/devicetree/bindings/bus/ti-gpmc.txt  |   1 -
 .../devicetree/bindings/clock/clk-exynos-audss.txt |  64 ++
 .../devicetree/bindings/dma/ste-dma40.txt          |  66 +++
 .../devicetree/bindings/gpio/gpio-samsung.txt      |  43 --
 .../devicetree/bindings/gpio/renesas,gpio-rcar.txt |  46 ++
 .../devicetree/bindings/mtd/gpmc-nand.txt          |   8 +
 .../bindings/pinctrl/samsung-pinctrl.txt           |   8 +
 .../devicetree/bindings/sound/samsung-i2s.txt      |  46 +-
 .../devicetree/bindings/usb/atmel-usb.txt          |  82 +++
 .../devicetree/bindings/usb/ux500-usb.txt          |  50 ++
 arch/arm/Kconfig                                   |  47 --
 arch/arm/boot/dts/dbx5x0.dtsi                      |   5 +
 arch/arm/boot/dts/exynos4.dtsi                     |   2 +-
 arch/arm/boot/dts/exynos4210-origen.dts            |   2 +-
 arch/arm/boot/dts/exynos4210-smdkv310.dts          |   2 +-
 arch/arm/boot/dts/exynos4210-trats.dts             |   2 +-
 arch/arm/boot/dts/exynos4210-universal_c210.dts    |   2 +-
 arch/arm/boot/dts/exynos4210.dtsi                  |   4 +-
 arch/arm/boot/dts/exynos4212.dtsi                  |   2 +-
 arch/arm/boot/dts/exynos4412-odroidx.dts           |   2 +-
 arch/arm/boot/dts/exynos4412-origen.dts            |   2 +-
 arch/arm/boot/dts/exynos4412-smdk4412.dts          |   2 +-
 arch/arm/boot/dts/exynos4412.dtsi                  |   2 +-
 arch/arm/boot/dts/exynos4x12.dtsi                  |   4 +-
 arch/arm/boot/dts/exynos5250-arndale.dts           |   2 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts          |   2 +-
 arch/arm/boot/dts/exynos5250-snow.dts              |   4 +-
 arch/arm/boot/dts/exynos5250.dtsi                  |  20 +-
 arch/arm/boot/dts/exynos5440-sd5v1.dts             |   2 +-
 arch/arm/boot/dts/exynos5440-ssdk5440.dts          |   2 +-
 arch/arm/boot/dts/exynos5440.dtsi                  |   2 +-
 arch/arm/boot/dts/omap3430-sdp.dts                 |   1 -
 arch/arm/boot/dts/s3c2416-smdk2416.dts             |   2 +-
 arch/arm/boot/dts/s3c2416.dtsi                     |   4 +-
 arch/arm/boot/dts/s3c24xx.dtsi                     |   2 +-
 arch/arm/boot/dts/snowball.dts                     |  13 +-
 arch/arm/configs/omap1_defconfig                   |   3 +-
 arch/arm/mach-omap1/Makefile                       |   4 -
 arch/arm/mach-omap2/Makefile                       |   3 -
 arch/arm/mach-omap2/board-flash.c                  |   3 +
 arch/arm/mach-omap2/devices.c                      |  13 +-
 arch/arm/mach-omap2/gpmc-nand.c                    |  44 +-
 arch/arm/mach-omap2/gpmc.c                         |  82 ++-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c         |  14 +
 arch/arm/mach-omap2/omap_hwmod_2430_data.c         |  13 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |  13 +
 arch/arm/mach-s3c24xx/Kconfig                      |  66 +--
 arch/arm/mach-s3c24xx/Makefile                     |   6 -
 arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h |   0
 arch/arm/mach-s3c24xx/iotiming-s3c2412.c           |   2 +-
 arch/arm/mach-ux500/board-mop500-audio.c           |  68 +--
 arch/arm/mach-ux500/board-mop500-sdi.c             |  56 +-
 arch/arm/mach-ux500/board-mop500.c                 |  94 +--
 arch/arm/mach-ux500/board-mop500.h                 |   2 +-
 arch/arm/mach-ux500/cpu-db8500.c                   |  66 +--
 arch/arm/mach-ux500/devices-db8500.c               | 123 +---
 arch/arm/mach-ux500/ste-dma40-db8500.h             | 193 +++---
 arch/arm/mach-ux500/usb.c                          |  47 +-
 arch/arm/plat-omap/Kconfig                         |  16 -
 arch/arm/plat-omap/Makefile                        |   3 -
 arch/arm/plat-samsung/include/plat/cpu-freq-core.h |  10 +-
 arch/arm/plat-samsung/include/plat/cpu-freq.h      |   6 +-
 drivers/clk/samsung/Makefile                       |   1 +
 drivers/clk/samsung/clk-exynos-audss.c             | 133 +++++
 drivers/clk/samsung/clk-exynos5250.c               |   5 +-
 drivers/clocksource/clksrc-dbx500-prcmu.c          |  11 +-
 drivers/cpufreq/Kconfig.arm                        |  58 ++
 drivers/cpufreq/Makefile                           |   5 +
 .../cpufreq/s3c2410-cpufreq.c                      |   0
 .../cpufreq/s3c2412-cpufreq.c                      |   3 +-
 .../cpufreq/s3c2440-cpufreq.c                      |   0
 .../cpufreq/s3c24xx-cpufreq-debugfs.c              |   0
 .../cpufreq.c => drivers/cpufreq/s3c24xx-cpufreq.c |   0
 drivers/crypto/ux500/cryp/cryp.c                   |   4 +-
 drivers/crypto/ux500/cryp/cryp.h                   |   7 +-
 drivers/crypto/ux500/cryp/cryp_core.c              |  57 +-
 drivers/crypto/ux500/hash/hash_alg.h               |   5 +-
 drivers/crypto/ux500/hash/hash_core.c              |  57 +-
 drivers/dma/ste_dma40.c                            | 533 ++++++++++-------
 drivers/dma/ste_dma40_ll.c                         | 189 +++---
 drivers/dma/ste_dma40_ll.h                         |   3 +-
 drivers/gpio/gpio-rcar.c                           |  63 +-
 drivers/gpio/gpio-samsung.c                        |  67 +--
 drivers/mailbox/Kconfig                            |  34 ++
 drivers/mailbox/Makefile                           |   6 +
 .../mailbox.c => drivers/mailbox/mailbox-omap1.c   |  12 +-
 .../mailbox.c => drivers/mailbox/mailbox-omap2.c   | 276 ++++-----
 .../mailbox.c => drivers/mailbox/omap-mailbox.c    |  54 +-
 .../plat/mailbox.h => drivers/mailbox/omap-mbox.h  |  70 +--
 drivers/pinctrl/Kconfig                            |   5 +
 drivers/pinctrl/Makefile                           |   1 +
 drivers/pinctrl/pinctrl-s3c24xx.c                  | 651 +++++++++++++++++++++
 drivers/pinctrl/pinctrl-samsung.c                  |  10 +
 drivers/pinctrl/pinctrl-samsung.h                  |   4 +
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c               | 198 +++++++
 drivers/pinctrl/sh-pfc/pfc-r8a7778.c               |   4 +-
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c               | 227 ++++++-
 drivers/remoteproc/Kconfig                         |   3 +-
 drivers/remoteproc/omap_remoteproc.c               |   2 +-
 drivers/staging/tidspbridge/Kconfig                |   3 +-
 .../tidspbridge/include/dspbridge/host_os.h        |   2 +-
 drivers/usb/gadget/Kconfig                         |   2 +-
 drivers/usb/gadget/atmel_usba_udc.c                | 264 ++++++---
 drivers/usb/gadget/atmel_usba_udc.h                |   2 +
 drivers/usb/musb/ux500.c                           |  61 +-
 drivers/usb/musb/ux500_dma.c                       |  59 +-
 include/dt-bindings/clk/exynos-audss-clk.h         |  25 +
 include/linux/omap-mailbox.h                       |  29 +
 include/linux/platform_data/dma-ste-dma40.h        |  41 +-
 include/linux/platform_data/mailbox-omap.h         |  58 ++
 include/linux/platform_data/usb-musb-ux500.h       |   5 +-
 sound/soc/ux500/ux500_pcm.c                        |  10 +-
 112 files changed, 3168 insertions(+), 1651 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
 create mode 100644 Documentation/devicetree/bindings/dma/ste-dma40.txt
 create mode 100644 Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
 create mode 100644 Documentation/devicetree/bindings/usb/ux500-usb.txt
 rename arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h (100%)
 create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
 rename arch/arm/mach-s3c24xx/cpufreq-s3c2410.c => drivers/cpufreq/s3c2410-cpufreq.c (100%)
 rename arch/arm/mach-s3c24xx/cpufreq-s3c2412.c => drivers/cpufreq/s3c2412-cpufreq.c (99%)
 rename arch/arm/mach-s3c24xx/cpufreq-s3c2440.c => drivers/cpufreq/s3c2440-cpufreq.c (100%)
 rename arch/arm/mach-s3c24xx/cpufreq-debugfs.c => drivers/cpufreq/s3c24xx-cpufreq-debugfs.c (100%)
 rename arch/arm/mach-s3c24xx/cpufreq.c => drivers/cpufreq/s3c24xx-cpufreq.c (100%)
 rename arch/arm/mach-omap1/mailbox.c => drivers/mailbox/mailbox-omap1.c (94%)
 rename arch/arm/mach-omap2/mailbox.c => drivers/mailbox/mailbox-omap2.c (59%)
 rename arch/arm/plat-omap/mailbox.c => drivers/mailbox/omap-mailbox.c (92%)
 rename arch/arm/plat-omap/include/plat/mailbox.h => drivers/mailbox/omap-mbox.h (54%)
 create mode 100644 drivers/pinctrl/pinctrl-s3c24xx.c
 create mode 100644 include/dt-bindings/clk/exynos-audss-clk.h
 create mode 100644 include/linux/omap-mailbox.h
 create mode 100644 include/linux/platform_data/mailbox-omap.h



From arnd at arndb.de  Tue Jul  2 15:08:48 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 2 Jul 2013 21:08:48 +0200
Subject: [GIT PULL 5/7] ARM SoC device tree changes
In-Reply-To: <201307022055.50717.arnd@arndb.de>
References: <201307022055.50717.arnd@arndb.de>
Message-ID: <201307022108.48580.arnd@arndb.de>

The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f:

  Linux 3.10-rc6 (2013-06-15 11:51:07 -1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/dt-for-linus

for you to fetch changes up to 9686bb66a4c50e43ffee903a9fc62237ee2de1e6:

  Merge tag 'at91-dt' of git://github.com/at91linux/linux-at91 into next/dt (2013-06-26 16:56:24 +0200)

----------------------------------------------------------------

ARM SoC device tree changes

These changes from 30 individual branches for the most part update device
tree files, but there are also a few source code changes that have crept
in this time, usually in order to atomically move over a driver from
using hardcoded data to DT probing.

A number of platforms change their DT files to use the C preprocessor,
which is causing a bit of churn, but that is hopefully only this once.

There are a few conflicts with the other branches unfortunately:

* in exynos5440.dtsi and kirkwood-6281.dtsi, device nodes are added
  from multiple branches. Need to be careful to have the right
  set of closing braces as git gets this one wrong.

* In kirkwood.dtsi, one 'ranges' line got split into two lines, while
  another line got added. Order of the lines does not matter.

* in sama5d3.dtsi, some cleanup was merged the wrong way, causing
  a bogus conflict. We want the 'dmas' and 'dma-names' properties
  to get added here.

* Two lines got removed independently in arch/arm/mach-mxs/mach-mxs.c

* Contents get added independently in arch/arm/mach-omap2/cclock33xx_data.c

----------------------------------------------------------------

The following changes since commit 9dfedaad4e6b7f9fbae06d3b342a1c77b8c025a5:

  Merge tag 'boards-for-linus' into for-linus (2013-07-02 15:11:10 +0200)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 

for you to fetch changes up to d1bf673810d5a1e050e423c22687d705f35adcba:

  Merge tag 'dt-for-linus' into for-linus (2013-07-02 15:29:09 +0200)

----------------------------------------------------------------

Adam Baker (1):
      ARM: Kirkwood add cpus definition needed by cpufreq driver to dtsi

Afzal Mohammed (2):
      ARM: dts: AM43x: Initial support
      ARM: dts: AM43x EPOS EVM support

Alexander Shiyan (11):
      ARM: dts: Add aliases for i.MX27 SPI controller
      ARM: dts: Add SPI support for i.MX27 Phytec PCM038 module
      ARM: dts: imx27-phytec-phycore: Add reset GPIO for FEC
      ARM: dts: imx27-phytec-phycore: Rename file to match functionality
      ARM: dts: imx27-phytec-phycore-som: Remove UART definitions
      ARM: dts: imx27-phytec-phycore-som: Add initial support for PCM970 RDK
      ARM: dts: i.MX27: Add DMA devicetree node
      ARM: dts: i.MX27: Add SDHC devicetree nodes
      ARM: dts: imx27-phytec-phycore-rdk: Add SDHC support
      ARM: dts: imx27-phytec-phycore-rdk: Add MTD name for NOR flash
      ARM: dts: imx27: Add VPU devicetree node

Amit Daniel Kachhap (1):
      ARM: dts: Add more opp levels in exynos5440

Andrew Lunn (1):
      ARM: Kirkwood: ts219: Enable second PCIe port in DT.

Arnd Bergmann (16):
      ARM: nomadik: fix clocksource warning
      ARM: dts: add missing cpu #address-cell values
      Merge tag 'zynq-dt-for-3.11' of git://git.xilinx.com/linux-xlnx into next/dt
      Merge tag 'mxs-dt-3.11' of git://git.linaro.org/people/shawnguo/linux-2.6 into next/dt
      Merge tag 'imx-soc-3.11' of git://git.linaro.org/people/shawnguo/linux-2.6 into next/dt
      Merge tag 'imx-dt-3.11' of git://git.linaro.org/people/shawnguo/linux-2.6 into next/dt
      Merge tag 'sunxi-dt-for-3.11-2' of git://github.com/mripard/linux into next/dt
      Merge tag 'nomadik-dt-2' of git://git.kernel.org/.../linusw/linux-nomadik into next/dt
      Merge tag 'exynos-dt-2' of git://git.kernel.org/.../kgene/linux-samsung into next/dt
      Merge tag 's3c24xx-dt-2' of git://git.kernel.org/.../kgene/linux-samsung into next/dt
      Merge branch 'for_3.11/dts' of git://git.kernel.org/.../bcousson/linux-omap-dt into next/dt
      Merge tag 'renesas-dt2-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/dt
      Merge branch 'armsoc/for-3.11/dt' of git://github.com/broadcom/bcm11351 into next/dt
      Merge tag 'dt-3.11-6' of git://git.infradead.org/users/jcooper/linux into next/dt
      Merge tag 'at91-dt' of git://github.com/at91linux/linux-at91 into next/dt
      Merge tag 'dt-for-linus' into for-linus

Bastian Hecht (3):
      ARM: shmobile: r8a7740: Add OF support to initialze the GIC
      ARM: shmobile: r8a7740: Prepare for reference DT setup
      ARM: shmobile: armadillo800eva: Reference DT implementation

Boris BREZILLON (1):
      ARM: at91/dt: add pinctrl definition for at91 tc blocks

Brian Lilly (3):
      ARM: cfa10049: Switch the chip select pin of the LCD controller
      ARM: mxs: dt: Add the Crystalfontz CFA-10055 device tree
      ARM: mxs: dt: Add Crystalfontz CFA-10057 device tree

Christian Daudt (1):
      ARM: mmc: bcm281xx SDHCI driver (dt mods)

Christian Hemp (2):
      ARM: dts: imx6q: Add pinctrl for usdhc2 and enet
      ARM: dts: Phytec imx6q pfla02 and pbab01 support

Dan Murphy (3):
      ARM: dts: omap4-panda: Update the LED support for the panda
      ARM: dts: omap4-panda: Update the twl6040 gpio to macro definition
      ARM: dts: omap5-uevm: Add LED support for uEVM blue LED

Daniel Mack (1):
      ARM: bcm2835: Add Raspberry Pi's ACT LED to DT

Dinh Nguyen (2):
      ARM: socfpga: dts: Add ethernet bindings for SOCFPGA
      ARM: socfpga: dts: Add gate-clock bindings

Dirk Behme (2):
      ARM: dts: i.MX6: configure L2 cache data and tag latency
      i.MX6: Documentation: update from fsl,card-wired to non-removable

Dongjin Kim (2):
      ARM: dts: add max77686 node entry for ODROID-X
      ARM: dts: add vmmc regulator support for ODROID-X

Doug Anderson (1):
      ARM: dts: Enable RTC node for exynos5250-snow

Douglas Gilbert (1):
      ARM: at91: add Acme Systems Fox G20 board

Eduardo Valentin (3):
      ARM: dts: OMAP443x: Add bandgap entry for OMAP443x devices
      ARM: dts: OMAP4460: Add bandgap entry for OMAP4460 devices
      ARM: dts: OMAP5: Add bandgap DT entry

Emilio L?pez (1):
      ARM: sun4i: cubieboard: Enable the i2c controllers

Eric Brower (1):
      ARM: tegra: Add gpio-leds to Tegra30 Beaver

Eric B?nard (3):
      ARM: mx28: add auart2 2 pins pinmux to imx28.dtsi
      ARM: mx28: add auart3 2 pins pinmux to imx28.dtsi
      ARM: mx28: add auart4 2 pins pinmux to imx28.dtsi

Ezequiel Garcia (3):
      ARM: mvebu: Add support for NOR flash device on Armada XP-DB board
      ARM: mvebu: Remove device tree unused properties on A370
      ARM: Kirkwood: Fix the internal register ranges translation

Fabio Baltieri (5):
      ARM: ux500: Fix intcore regulator name
      ARM: ux500: Fix trivial typo in v-anamic1 comment
      ARM: ux500: Correct anamic2 typo in DT files
      ARM: ux500: Add DT regulators for ab8500-codec
      ARM: ux500: Provide auxdata to ux500 ASoC driver

Fabio Estevam (2):
      ARM: dts: mx28: Adjust the digctl compatible string
      ARM: mxs: Use soc bus infrastructure

Florian Vaussard (15):
      ARM: dts: OMAP2+: Use #include for all device trees
      ARM: dts: OMAP2+: Use existing constants for GPIOs
      ARM: dts: OMAP4/5: Use existing constants for IRQs
      ARM: dts: OMAP2+: Header file for pinctrl constants
      ARM: dts: OMAP2+: Use pinctrl constants
      ARM: dts: AM3XXX: Use #include for all device trees
      ARM: dts: AM33XX: Use existing constants for GPIOs
      ARM: dts: AM33XX: Specific pinctrl header
      ARM: dts: AM33XX: Use pinctrl constants
      ARM: dts: OMAP4/AM35xx: Add missing dtb in the dtbs target
      ARM: dts: Protect pinctrl headers against multiple inclusions
      ARM: dts: OMAP3: Include IRQ header
      ARM: dts: omap3-tobi: Add SMSC911X node
      ARM: dts: omap3-tobi: Correct polarity for GPIO LED
      ARM: dts: omap3-overo: Add default trigger for TWL4030 LED

Gabriel Fernandez (2):
      ARM: ux500: DT: Rename root node "soc-u9500" into "soc"
      ARM: ux500: use #include syntax to include *.dtsi.

Giridhar Maruthy (1):
      ARM: dts: Removing pdma for exynos5440

Girish K S (2):
      ARM: dts: add dts node for the ahci sata exynos5440
      ARM: dts: enable spi for EXYNOS5440 SOC

Guennadi Liakhovetski (5):
      ARM: shmobile: kzm9g-reference: add AS3711 and CPUFreq DT bindings
      ARM: shmobile: marzen-reference: add irqpin support in DT
      irqchip: renesas-intc-irqpin: DT binding for sense bitfield width
      ARM: shmobile: sh73a0: remove "0x" prefix from DT node names
      ARM: shmobile: irqpin: add a DT property to enable masking on parent

Gwenhael Goavec-Merou (3):
      ARM: dts: apf28dev: Add touchscreen support for APF28dev
      ARM: imx27: Add PWM0 to device tree
      ARM: imx: apf51: add nfc support

Heiko Stuebner (2):
      ARM: dts: add devicetree support for s3c2416-smdk2416
      ARM: S3C24XX: update uart addresses in s3c2416-dt auxdata

Hiroshi Doyu (6):
      ARM: tegra20: create a DT header defining CLK IDs
      ARM: tegra30: create a DT header defining CLK IDs
      ARM: tegra114: create a DT header defining CLK IDs
      ARM: tegra20: convert device tree files to use CLK defines
      ARM: tegra30: convert device tree files to use CLK defines
      ARM: tegra114: convert device tree files to use CLK defines

Huang Shijie (13):
      ARM: dts: imx6q: remove the unused pins for gpmi-nand
      ARM: dts: imx6dl: add pinctrl for gpmi-nand
      ARM: dts: enable the gpmi-nand for imx6q{dl}-sabreauto boards
      ARM: dts: imx6dl: add a pinctrl for eCSPI1
      ARM: dts: imx6dl: add a gpio for hog
      ARM: dts: imx6q: add a gpio for hog
      ARM: dts: add SPI/NOR for mx6q{dl}-sabreauto boards
      drivers: bus: add a new driver for WEIM
      ARM: dts: imx6q{dl}: fix the pin conflict between SPI and WEIM
      ARM: dts: imx6qdl: add more information for WEIM
      ARM: dts: imx6q: add pinctrls for WEIM NOR
      ARM: dts: imx6dl: add pinctrls for WEIM NOR
      ARM: dts: imx6qdl-sabreauto: enable the WEIM NOR

J Keerthy (1):
      ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes

Javier Martinez Canillas (3):
      ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support
      ARM: dts: omap3-igep0020: Add NAND flash support
      ARM: dts: omap3-igep0030: Add NAND flash support

Jean-Christophe PLAGNIOL-VILLARD (12):
      ARM: at91: dt: sam9260: add i2c gpio pinctrl
      ARM: at91: dt: usb-a9260: update shutdown controller
      ARM: at91: dt: usb-a9263: update shutdown controller
      ARM: at91: dt: usb-a9263: add dataflash support
      ARM: at91: dt: add Calao USB-A9G20 low power version
      ARM: at91: drop non DT: Calao USB-A96x
      ARM: at91: sam9x5 add udc DT support
      ARM: at91: sam9x5ek add udc DT support
      ARM: at91: sam9g45 add udc DT support
      ARM: at91: sam9m10g45ek add udc DT support
      ARM: at91: dt: rm9200: add spi support
      ARM: at91: dt: rm9200ek: add spi support

Jingchang Lu (2):
      ARM: dts: add SoC level device tree source for VF610
      ARM: dts: add initial VF610 Tower board dts support

Jingoo Han (2):
      ARM: dts: add pin state information for DP HPD support to Exynos5250
      ARM: dts: Document DP clock in samsung,exynos5-dp binding

Jonas Andersson (3):
      ARM: dts: imx53: add cspi pinctrl
      ARM: dts: imx53: add ecspi2 pinctrl
      ARM: dts: imx53: add fec pinctrl

Kevin Hilman (3):
      ARM: dts: OMAP3: beagle/overo: mux console UART, enable wakeup
      ARM: dts: OMAP3: beagle: enable user button via gpio_keys, enable wakeup
      ARM: dts: TWL4030: fix mux and wakeup for SYS_NIRQ line

Laxman Dewangan (1):
      ARM: tegra: enable spi4 on Dalmore

Lee Jones (26):
      ARM: ux500: Move Snowball's thermal DT node into existing PRCMU one
      ARM: ux500: Create a new of_dev_auxdata structure for u8540 enablement
      ARM: ux500: Add a VQMMC (level-shifting) regulator DT node for Snowball
      ARM: ux500: Supply address location names for the DMA40 DMA controller
      ARM: ux500: Setup the DMA40 driver's DT node using the new DMA API
      ARM: ux500: Supply UART's DMA configuration via Device Tree
      ARM: ux500: Supply MMC DMA configuration via Device Tree
      ARM: ux500: Populate the ux500-musb Device Tree entry
      ARM: ux500: Pass DMA memcpy channels though Device Tree
      ARM: ux500: Supply a DTS file for the u8540 platform
      ARM: ux500: Over-ride TCDM size when booting the DB8540 platform
      ARM: ux500: Add Device Tree nodes for the ux500 Crypt device
      ARM: ux500: Add Device Tree nodes for the ux500 Hash device
      ARM: ux500: Provide an AUXDATA entry for ux500-crypt
      ARM: ux500: Provide an AUXDATA entry for ux500-hash
      crypto: ux500/cryp - Enable DT probing of the driver
      crypto: ux500/hash - Enable DT probing of the driver
      ARM: ux500: Standardise DBx5x0 based Pinctrl compat string in the DTS
      ARM: ux500: Standardise Pinctrl compatible string for DBx5x based platforms
      pinctrl/nomadik: Standardise Pinctrl compat string for DBx5x based platforms
      ARM: ux500: Apply other compatible name to the u8540 DTS file
      ARM: nomadik: Standardise Nomadik STN8815 based Pinctrl compat string in the DTS
      pinctrl/nomadik: Standardise Pinctrl compat string for Nomadik based platforms
      ARM: ux500: Add an auxdata entry for MUSB for clock-name look-up
      ARM: ux500: Reduce PRCMU reg-names to shorter form for u8540 DT
      ARM: ux500: Allocate correct amount of memory for the u8540 in DT

Leela Krishna Amudala (1):
      Documentation: Add examples to samsung-pinctrl device tree bindings documentation

Linus Walleij (14):
      ARM: nomadik: convert all clocks except timer to dt
      ARM: nomadik: register clocksource from device tree
      ARM: nomadik: add led and key for S8815
      ARM: nomadik: move the pin configuration to DT
      ARM: ux500: build ccu8540 device tree blob
      ARM: ux500: fix typo in STUIB device tree
      ARM: ux500: register LP5521 LEDs in the device tree
      ARM: ux500: enable the crypto and hash on all dbx500
      ARM: ux500: bump MMC/SD max frequency for DT boots
      ARM: ux500: use symbolic names for interrupt flags
      ARM: ux500: cut chip-select GPIOs from SSP device
      ARM: ux500: drop any 0x prefix from I2C DT devices
      clk: nomadik: implement the Nomadik clocks properly
      ARM: nomadik: add the new clocks to the device tree

Lorenzo Pieralisi (14):
      ARM: dts: am33xx: cpus/cpu nodes dts updates
      ARM: dts: armada-370-xp: cpus/cpu node dts updates
      ARM: dts: at91: cpus/cpu node dts updates
      ARM: dts: exynos5440: cpus/cpu nodes dts updates
      ARM: dts: imx: cpus/cpu nodes dts updates
      ARM: dts: lpc32xx: cpus/cpu nodes dts updates
      ARM: dts: omap: cpus/cpu nodes dts updates
      ARM: dts: picoxcell: cpus/cpu nodes dts updates
      ARM: dts: prima2: cpus/cpu node dts updates
      ARM: dts: pxa2xx: cpus/cpu nodes dts updates
      ARM: dts: r8a7740: cpus/cpu nodes dts updates
      ARM: dts: sh7372: cpus/cpu nodes dts updates
      ARM: dts: spear: cpus/cpu nodes dts updates
      ARM: dts: sunxi: cpus/cpu nodes dts updates

Ludovic Desroches (2):
      ARM: at91: dt: add header to define at_hdmac configuration
      ARM: at91: dt: switch DMA DT bindings to pre-processor

Magnus Damm (2):
      ARM: shmobile: Remove unused r8a73a4 GIC CPU interface DT bits
      ARM: shmobile: Remove unused r8a7790 GIC CPU interface DT bits

Marek Vasut (9):
      ARM: mxs: Fix UARTs on M28EVK
      ARM: mx5: Add AUDMUX4 pinctrl data
      ARM: mx5: Add CAN1 pinctrl data
      ARM: mx5: Add I2C1 pinctrl data
      ARM: mx5: Add I2C2 pinctrl data
      ARM: mx5: Add NAND pinctrl data
      ARM: mx5: Add LCD IPU pinctrl data
      ARM: mx5: Add PWM1 pinctrl data
      ARM: mx5: Add support for DENX M53EVK

Markus Niebel (4):
      ARM i.MX53: mba53: add sound support
      ARM i.MX53: mba53: add missing gpio stuff for pca9554
      ARM i.MX53: mba53: use reset gpio for FEC
      ARM i.MX53: mba53: add DI1_CLK to pinctrl for disp1

Matt Porter (3):
      ARM: dts: bcm281xx: use #include for device tree files
      ARM: dts: bcm281xx: use existing defines for irqs
      ARM: dts: bcm281xx: change comment to C89 style

Maxime Ripard (12):
      ARM: sun5i: Update the clock compatible strings
      ARM: sunxi: dt: Register the pio node as interrupt controller
      ARM: sunxi: dt: Add i2c controller nodes to the DTSI
      ARM: sun4i: dt: Add i2c muxing options
      ARM: sun5i: dt: Add i2c muxing options
      ARM: sun5i: olinuxino: Enable the i2c controllers
      ARM: sunxi: dt: Add Allwinner A10s DTSI
      ARM: mxs: Remove init_irq declaration in machine description
      ARM: dts: cfa10036: Change the OLED display to SSD1306
      ARM: cfa10036: dt: Change i2c0 clock frequency
      ARM: cfa10036: Add USB0 OTG port
      ARM: sunxi: Add Olimex A10s-Olinuxino-micro device tree

Michael Grzeschik (4):
      ARM: dts: imx: add imx5x usbmisc entries
      ARM: dts: imx: add imx5x usb clock DT lookups
      ARM: dts: imx: use usb-nop-xceiv usbphy entries for imx5x
      ARM: dts: imx: imx53-qsb.dts: enable usbotg and usbh1

Michael Olbrich (1):
      ARM i.MX53: mba53: enable usbotg & usbh1

Mugunthan V N (3):
      ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone
      ARM: dts: AM33XX: Add pinmux configuration for CPSW to EVMsk
      ARM: dts: AM33XX: Add pinmux configuration for CPSW to am335x EVM

Nicolas Ferre (8):
      ARM: at91: at91sam9x5 RTC is not compatible with at91rm9200 one
      ARM: at91/at91-ariag25.dts: add RTC node
      ARM: at91/at91sam9x5.dtsi: add UART0/1 nodes
      ARM: at91/at91-ariag25.dts: UART0/1 nodes are disabled
      ARM: at91: switch Fox G20 board .dts to pre-processor defines
      ARM: at91/DT: fix SPI compatibility string
      ARM: at91/DT: sama5d3: add SPI DMA client infos
      ARM: at91/DT: at91sam9n12: add SPI DMA client infos

Nicolin Chen (7):
      ARM: dts: imx6qdl-sabresd: add clko1 iomux configuration
      ARM: dtsi: imx6q/imx6dl: Add a pinctrl for I2C1
      ARM: dtsi: imx6dl: Add a pinctrl for AUDMUX
      ARM: dtsi: imx6qdl-sabresd: add a fixed regulator for WM8962
      ARM: dtsi: imx6qdl-sabresd: Add WM8962 CODEC support
      ARM: dtsi: imx6qdl-sabresd: Enable SSI2 and AUDMUX
      ARM: dtsi: imx6qdl-sabresd: Enable WM8962 audio support

Olof Johansson (15):
      Merge tag 'nomadik-dt-for-arm-soc' of git://git.kernel.org/.../linusw/linux-nomadik into next/dt
      Merge tag 'dt-3.11-3' of git://git.infradead.org/users/jcooper/linux into next/dt
      Merge tag 'at91-dt' of git://github.com/at91linux/linux-at91 into next/dt
      Merge branch 'dts-cpus-updates' of git://linux-arm.org/linux-2.6-lp into next/dt
      Merge tag 'vt8500/dts-3.11' of git://github.com/linux-wmt/linux-vtwm into next/dt
      Merge tag 'dt-3.11-4' of git://git.infradead.org/users/jcooper/linux into next/dt
      Merge tag 'renesas-dt-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/dt
      Merge tag 's3c24xx-dt-1' of git://git.kernel.org/.../kgene/linux-samsung into next/dt
      Merge tag 'exynos-dt-1' of git://git.kernel.org/.../kgene/linux-samsung into next/dt
      Merge tag 'dt-3.11-5' of git://git.infradead.org/users/jcooper/linux into next/dt
      Merge tag 'ux500-dt-for-arm-soc' of git://git.kernel.org/.../linusw/linux-stericsson into next/dt
      Merge tag 'bcm2835-for-3.11-dt' of git://git.kernel.org/.../swarren/linux-rpi into next/dt
      Merge tag 'tegra-for-3.11-dt' of git://git.kernel.org/.../swarren/linux-tegra into next/dt
      Merge tag 'sunxi-dt-for-3.11' of git://github.com/mripard/linux into next/dt
      Merge tag 'at91-dt' of git://github.com/at91linux/linux-at91 into next/dt

Padmavathi Venna (1):
      ARM: dts: Add wm8994 regulator support on smdk5250

Philip Avinash (4):
      ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
      ARM: dts: AM33XX: Add PWMSS device tree nodes
      ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm
      ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk

Philip, Avinash (1):
      ARM: dts: AM33XX: Add ELM node

Philipp Zabel (5):
      ARM i.MX53: dts: add i2c aliases
      ARM i.MX53: tqma53: fix pinctrl settings
      ARM i.MX53: tqma53: rev 300 specific pin configuration
      ARM i.MX53: Add TVE entry to i.MX53 dtsi
      ARM i.MX53: mba53: add Tevision Encoder

Rabin Vincent (1):
      clocksource: nomadik-mtu: support of probe

Rhyland Klein (2):
      ARM: tegra: Add charger subnode to tps65090 node
      ARM: tegra: add power-supplies link between battery and charger

Richard Genoud (1):
      ARM: at91: dt: at91sam9x5: add SPI DMA client infos

Roger Quadros (4):
      ARM: dts: omap5-uevm: Add USB Host support
      ARM: dts: omap4-panda: Add USB Host support
      ARM: dts: omap4-panda: Fix DVI EDID reads
      ARM: dts: omap5-uevm: Provide USB Host PHY clock frequency

Rogerio Pimentel (1):
      ARM: dts: mx53qsb: Add support for parallel display

Sachin Kamat (16):
      ARM: dts: Remove keypad entries from exynos4x12-pinctrl.dtsi
      ARM: dts: Add keypad entries to Exynos4412 based Origen
      ARM: dts: Add keypad entries to SMDK4412
      ARM: dts: Add MFC clock entries for exynos4
      ARM: dts: Update MFC documentation for clock entries
      ARM: dts: Add TMU clock entries to exynos4210.dtsi
      ARM: dts: Enable TMU on Origen4210 board
      ARM: dts: Remove combiner IRQ node from exynos4x12.dtsi
      clk: exynos4: Add additional G2D clocks
      ARM: dts: Remove duplicate and add missing G2D nodes
      ARM: dts: Add clock entries to G2D node for exynos4210
      ARM: dts: Add clock entries to G2D node for exynos4x12
      ARM: dts: Update G2D documentation for clock entries
      ARM: dts: Add PWM related pinctrl entries for exynos4210
      ARM: dts: Add LCD related pinctrl entries for exynos4210
      ARM: dts: Add FIMD node to Origen4210 board

Sascha Hauer (2):
      ARM i.MX53: tqma53: Fix interrupt polarity for the mc34708
      ARM i.MX53: mba53: Add display support

Sebastian Hesselbarth (1):
      ARM: dove: add si5351 clock driver to CuBox DT

Shawn Guo (6):
      Merge tag 'imx-soc-3.11' into imx/dt
      ARM: imx: move imx53-qsb audio codec clk lookup into DT
      ARM: dts: add device tree source for imx6sl SoC
      ARM: dts: imx6sl: add initial imx6sl-evk support
      ARM: dts: imx6qdl: remove redundant usbmisc label
      ARM: dts: imx6qdl: remove redundant ocotp node

Simon Baatz (3):
      ARM: mvebu: Use standard MMC binding for all users of mvsdio
      ARM: Kirkwood: Add dts files for Sheevaplug and eSATA Sheevaplug
      arm: kirkwood: sheevaplug: move pinmux configs to the right devices

Soren Brinkmann (4):
      arm: zynq: Remove board specific compatibility string
      arm: dt: zynq: Use 'status' property for UART nodes
      arm: dt: zynq: Add support for the zc706 platform
      arm: dt: zynq: Add support for the zed platform

Sourav Poddar (1):
      ARM: dts: omap5-uevm: Add uart pinctrl data

Sricharan R (1):
      ARM: dts: omap5: Make uevm as the official board and deprecate sevm support

Steffen Trumtrar (9):
      ARM: i.MX53: add audmux pinctrl
      ARM: i.MX53: add csi pinctrl
      ARM: i.MX53: add ecspi pinctrl
      ARM: i.MX53: add pwm2 pinctrl
      ARM: i.MX53: add uart1 pinctrl
      ARM: i.MX53: add uart2 pinctrl
      ARM: dts: add Ka-Ro tx53 devicetree
      ARM i.MX53: tqma53: add WP/CD pinctrl and vmmc to esdhc2
      ARM i.MX53: mba53: fix lvds/disp pinctrl

Stephen Warren (10):
      Merge branch 'for-3.11/deps-for-clk' into for-3.11/dt
      ARM: tegra: fix memory size on Beaver
      ARM: tegra: use #include for all device trees
      ARM: tegra: create a DT header defining GPIO IDs
      ARM: tegra: convert device tree files to use GPIO defines
      ARM: tegra: convert device tree files to use IRQ defines
      ARM: tegra: add audio-related nodes to Tegra114 DT
      ARM: tegra: enable audio on Dalmore
      ARM: tegra: enable audio on Beaver
      ARM: mxc: fix gpio-ranges for VF610

Subash Patel (1):
      ARM: dts: update bootargs to support 8GiB for SSDK5440 and SD5v1

Suman Anna (1):
      ARM: dts: OMAP4+: Remove multimedia carveouts

Thomas Abraham (2):
      ARM: dts: add max8997 device node for exynos4210-origen board
      ARM: dts: add ohci and ehci controller nodes for EXYNOS5440

Thomas Petazzoni (25):
      arm: mvebu: enable the third USB interface on OpenBlocks AX3
      arm: mvebu: enable two USB interfaces on the Armada XP GP board
      arm: kirkwood: cloudbox: move pinmux configs to the right devices
      arm: kirkwood: dlink dns: move pinmux configs to the right devices
      arm: kirkwood: dockstar: move pinmux configs to the right devices
      arm: kirkwood: dreamplug: move pinmux configs to the right devices
      arm: kirkwood: goflexnet: move pinmux configs to the right devices
      arm: kirkwood: guruplug: move pinmux configs to the right devices
      arm: kirkwood: ib62x0: move pinmux configs to the right devices
      arm: kirkwood: iconnect: give meaningful names to pinmux configs
      arm: kirkwood: iconnect: move pinmux configs to the right devices
      arm: kirkwood: iomega ix2-200: move pinmux configs to the right devices
      arm: kirkwood: ns2: move pinmux configs to the right devices
      arm: kirkwood: keymile: move pinmux configs to the right devices
      arm: kirkwood: buffalo linkstation: move pinmux configs to the right devices
      arm: kirkwood: mplcec4: move pinmux configs to the right devices
      arm: kirkwood: readynas: move pinmux configs to the right devices
      arm: kirkwood: nsa310: move pinmux configs to the right devices
      arm: kirkwood: openblocks_a6: move pinmux configs to the right devices
      arm: kirkwood: topkick: move pinmux configs to the right devices
      arm: kirkwood: ts219: move pinmux configs to the right devices
      arm: kirkwood: openblocks-a6: group pinmux configurations
      arm: kirkwood: openblocks-a6: add support for Init button
      arm: mvebu: armada-xp-db: ensure PCIe range is specified
      arm: mvebu: enable mini-PCIe connectors on Armada 370 RD

Tony Prisk (7):
      dts: vt8500: Fix invalid/missing cpu nodes for soc files.
      dts: vt8500: Add devicetree support for WM8750 SoC and APC8750 board
      dts: vt8500: Update serial nodes and disable by default in SoC files
      dts: clk: vt8500: Update SoC dtsi to use WM8850 PLL      clocks
      dts: vt8500: Populate missing PLL nodes
      dts: vt8500: Add ARM, AHB, APB and DDR clock nodes to SoC files
      dts: vt8500: Correct reference clock on WM8850 SoCs

Tushar Behera (2):
      ARM: dts: Enable RTC node for Arndale
      ARM: dts: Set BUCK7 as always on for Origen board

Vaibhav Hiremath (7):
      ARM: dts: AM33XX: Add default pinctrl binding for I2C device
      ARM: dts: AM33XX: Add pinctrl binding to gpio-leds node
      ARM: dts: AM33XX: Fix uart numbering to match hardware/TRM
      ARM: dts: AM33XX: Add default pinctrl binding for UART0 device
      ARM: dts: AM33XX: Set pinmux for clkout2 pad used for clock output
      ARM: AM33XX: clock: Add debugSS clock nodes
      ARM: AM33XX: clock data: Enable clkout2 as part of init

Valentin Longchamp (2):
      ARM: kirkwood: refactor dtsi to largest common nodes
      ARM: kirkwood: add i2c-gpio controller for km_kirkwood

Venu Byravarasu (3):
      ARM: tegra: finalize USB EHCI and PHY bindings
      ARM: tegra: modify ULPI reset GPIO properties
      ARM: tegra: update device trees for USB binding rework

Vikas Sajjan (3):
      ARM: dts: Add DT node for DP controller for Arndale Board
      ARM: dts: Add clock provider information for DP controller in Exynos5250 SoC
      ARM: dts: Add display timing node to exynos5250-arndale.dts

Vivek Gautam (3):
      ARM: dts: Enabling samsung-usb3phy driver for exynos5250
      ARM: dts: Add device tree bindings for dwc3-exynos
      ARM: dts: Enabling dwc3-exynos driver for exynos5250

Wenyou Yang (2):
      ARM: at91/dtsi: add the watchdog nodes for at91 SoC
      ARM: at91/dts: add the watchdog nodes for at91 boards

Willy Tarreau (1):
      ARM: mvebu: set aliases for ethernet controllers

Youngmin Nam (1):
      ARM: dts: Enable RTC by default on EXYNOS5440

 .../devicetree/bindings/arm/omap/omap.txt          |   3 +
 .../devicetree/bindings/arm/ste-nomadik.txt        |   5 +
 Documentation/devicetree/bindings/bus/imx-weim.txt |  49 ++
 .../devicetree/bindings/clock/altr_socfpga.txt     |   7 +
 .../devicetree/bindings/clock/exynos4-clock.txt    |   3 +-
 .../bindings/clock/nvidia,tegra114-car.txt         | 252 +------
 .../bindings/clock/nvidia,tegra20-car.txt          | 154 +---
 .../bindings/clock/nvidia,tegra30-car.txt          | 211 +-----
 .../devicetree/bindings/clock/st,nomadik.txt       | 104 +++
 .../devicetree/bindings/gpu/samsung-g2d.txt        |   5 +
 .../interrupt-controller/renesas,intc-irqpin.txt   |  16 +
 .../devicetree/bindings/media/s5p-mfc.txt          |   5 +
 Documentation/devicetree/bindings/mfd/ab8500.txt   |   2 +-
 .../devicetree/bindings/mmc/bcm,kona-sdhci.txt     |  16 +
 .../bindings/pinctrl/fsl,imx-pinctrl.txt           |   2 +-
 .../bindings/pinctrl/samsung-pinctrl.txt           |  44 +-
 .../devicetree/bindings/usb/exynos-usb.txt         |  34 +
 .../bindings/usb/nvidia,tegra20-ehci.txt           |  27 +-
 .../bindings/usb/nvidia,tegra20-usb-phy.txt        |  41 +-
 .../devicetree/bindings/video/exynos_dp.txt        |   6 +
 arch/arm/boot/dts/Makefile                         |  32 +-
 arch/arm/boot/dts/am335x-bone.dts                  | 118 ++-
 arch/arm/boot/dts/am335x-evm.dts                   | 264 ++++++-
 arch/arm/boot/dts/am335x-evmsk.dts                 | 184 ++++-
 arch/arm/boot/dts/am33xx.dtsi                      | 125 +++-
 arch/arm/boot/dts/am3517-evm.dts                   |   2 +-
 arch/arm/boot/dts/am3517_mt_ventoux.dts            |   2 +-
 arch/arm/boot/dts/am4372.dtsi                      |  68 ++
 arch/arm/boot/dts/am43x-epos-evm.dts               |  18 +
 arch/arm/boot/dts/armada-370-db.dts                |   1 +
 arch/arm/boot/dts/armada-370-mirabox.dts           |   1 +
 arch/arm/boot/dts/armada-370-rd.dts                |  17 +
 arch/arm/boot/dts/armada-370-xp.dtsi               |  17 +-
 arch/arm/boot/dts/armada-370.dtsi                  |   4 -
 arch/arm/boot/dts/armada-xp-db.dts                 |  34 +
 arch/arm/boot/dts/armada-xp-gp.dts                 |  10 +
 arch/arm/boot/dts/armada-xp-mv78460.dtsi           |   3 +-
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |   9 +
 arch/arm/boot/dts/armada-xp.dtsi                   |   6 +-
 arch/arm/boot/dts/at91-ariag25.dts                 |  21 +-
 arch/arm/boot/dts/at91-foxg20.dts                  | 157 ++++
 arch/arm/boot/dts/at91rm9200.dtsi                  | 102 ++-
 arch/arm/boot/dts/at91rm9200ek.dts                 |  10 +
 arch/arm/boot/dts/at91sam9260.dtsi                 |  94 ++-
 arch/arm/boot/dts/at91sam9263.dtsi                 |  46 +-
 arch/arm/boot/dts/at91sam9263ek.dts                |   4 +
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi        |   4 +
 arch/arm/boot/dts/at91sam9g45.dtsi                 | 151 +++-
 arch/arm/boot/dts/at91sam9m10g45ek.dts             |   9 +
 arch/arm/boot/dts/at91sam9n12.dtsi                 | 107 ++-
 arch/arm/boot/dts/at91sam9n12ek.dts                |   4 +
 arch/arm/boot/dts/at91sam9x5.dtsi                  | 195 ++++-
 arch/arm/boot/dts/at91sam9x5ek.dtsi                |   9 +
 arch/arm/boot/dts/bcm11351-brt.dts                 |  19 +-
 arch/arm/boot/dts/bcm11351.dtsi                    |  39 +-
 arch/arm/boot/dts/bcm2835-rpi-b.dts                |  11 +
 arch/arm/boot/dts/ccu8540.dts                      |  41 ++
 arch/arm/boot/dts/ccu9540.dts                      |   6 +-
 arch/arm/boot/dts/dbx5x0.dtsi                      | 226 ++++--
 arch/arm/boot/dts/dove-cubox.dts                   |  51 +-
 arch/arm/boot/dts/exynos4.dtsi                     |   2 +
 arch/arm/boot/dts/exynos4210-origen.dts            | 169 +++++
 arch/arm/boot/dts/exynos4210-pinctrl.dtsi          |  89 +++
 arch/arm/boot/dts/exynos4210.dtsi                  |   5 +
 arch/arm/boot/dts/exynos4412-odroidx.dts           | 197 +++++
 arch/arm/boot/dts/exynos4412-origen.dts            |  66 ++
 arch/arm/boot/dts/exynos4412-smdk4412.dts          |  85 ++-
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi          |  56 --
 arch/arm/boot/dts/exynos4x12.dtsi                  |  10 +-
 arch/arm/boot/dts/exynos5250-arndale.dts           |  31 +
 arch/arm/boot/dts/exynos5250-pinctrl.dtsi          |   7 +
 arch/arm/boot/dts/exynos5250-smdk5250.dts          |  40 +-
 arch/arm/boot/dts/exynos5250-snow.dts              |   4 +
 arch/arm/boot/dts/exynos5250.dtsi                  |  34 +-
 arch/arm/boot/dts/exynos5440-sd5v1.dts             |   2 +-
 arch/arm/boot/dts/exynos5440-ssdk5440.dts          |  41 +-
 arch/arm/boot/dts/exynos5440.dtsi                  |  70 +-
 arch/arm/boot/dts/href.dtsi                        |  61 +-
 arch/arm/boot/dts/hrefprev60.dts                   |  10 +-
 arch/arm/boot/dts/hrefv60plus.dts                  |  20 +-
 arch/arm/boot/dts/imx23.dtsi                       |   8 +-
 arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts     |  37 +
 arch/arm/boot/dts/imx27-phytec-phycore-som.dts     | 179 +++++
 arch/arm/boot/dts/imx27-phytec-phycore.dts         |  79 --
 arch/arm/boot/dts/imx27.dtsi                       |  80 +-
 arch/arm/boot/dts/imx28-apf28dev.dts               |   1 +
 arch/arm/boot/dts/imx28-cfa10036.dts               |  38 +-
 arch/arm/boot/dts/imx28-cfa10049.dts               |   8 +-
 arch/arm/boot/dts/imx28-cfa10055.dts               | 179 +++++
 arch/arm/boot/dts/imx28-cfa10057.dts               | 191 +++++
 arch/arm/boot/dts/imx28-m28evk.dts                 |  14 +-
 arch/arm/boot/dts/imx28.dtsi                       |  43 +-
 arch/arm/boot/dts/imx51-apf51.dts                  |   7 +
 arch/arm/boot/dts/imx51.dtsi                       |  23 +
 arch/arm/boot/dts/imx53-m53evk.dts                 | 259 +++++++
 arch/arm/boot/dts/imx53-mba53.dts                  | 175 ++++-
 arch/arm/boot/dts/imx53-qsb.dts                    |  36 +
 arch/arm/boot/dts/imx53-tqma53.dtsi                |  45 +-
 arch/arm/boot/dts/imx53-tx53.dtsi                  | 122 ++++
 arch/arm/boot/dts/imx53.dtsi                       | 297 +++++++-
 arch/arm/boot/dts/imx6dl-sabreauto.dts             |   8 +
 arch/arm/boot/dts/imx6dl-sabresd.dts               |   1 +
 arch/arm/boot/dts/imx6dl.dtsi                      | 114 +++
 arch/arm/boot/dts/imx6q-phytec-pbab01.dts          |  34 +
 arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi         |  74 ++
 arch/arm/boot/dts/imx6q-sabreauto.dts              |   8 +
 arch/arm/boot/dts/imx6q-sabresd.dts                |   1 +
 arch/arm/boot/dts/imx6q.dtsi                       | 104 ++-
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi           |  41 ++
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi             |  66 ++
 arch/arm/boot/dts/imx6qdl.dtsi                     |  13 +-
 arch/arm/boot/dts/imx6sl-evk.dts                   |  74 ++
 arch/arm/boot/dts/imx6sl.dtsi                      | 779 ++++++++++++++++++++
 arch/arm/boot/dts/kirkwood-6281.dtsi               |  28 +
 arch/arm/boot/dts/kirkwood-6282.dtsi               |  28 +
 arch/arm/boot/dts/kirkwood-cloudbox.dts            |  10 +-
 arch/arm/boot/dts/kirkwood-dns320.dts              |   7 +
 arch/arm/boot/dts/kirkwood-dns325.dts              |   5 +
 arch/arm/boot/dts/kirkwood-dnskw.dtsi              |  32 +-
 arch/arm/boot/dts/kirkwood-dockstar.dts            |   9 +-
 arch/arm/boot/dts/kirkwood-dreamplug.dts           |  12 +-
 arch/arm/boot/dts/kirkwood-goflexnet.dts           |  18 +-
 .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |  10 +-
 arch/arm/boot/dts/kirkwood-ib62x0.dts              |  17 +-
 arch/arm/boot/dts/kirkwood-iconnect.dts            |  36 +-
 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts      |  15 +-
 arch/arm/boot/dts/kirkwood-is2.dts                 |   2 +
 arch/arm/boot/dts/kirkwood-km_kirkwood.dts         |  13 +-
 arch/arm/boot/dts/kirkwood-lsxl.dtsi               |  22 +-
 arch/arm/boot/dts/kirkwood-mplcec4.dts             |  25 +-
 .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  |  22 +-
 arch/arm/boot/dts/kirkwood-ns2-common.dtsi         |  10 +-
 arch/arm/boot/dts/kirkwood-ns2.dts                 |   2 +
 arch/arm/boot/dts/kirkwood-ns2lite.dts             |   2 +
 arch/arm/boot/dts/kirkwood-ns2max.dts              |   2 +
 arch/arm/boot/dts/kirkwood-ns2mini.dts             |   2 +
 arch/arm/boot/dts/kirkwood-nsa310.dts              |  30 +-
 arch/arm/boot/dts/kirkwood-openblocks_a6.dts       | 108 +--
 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi  |  93 +++
 arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts    |  43 ++
 arch/arm/boot/dts/kirkwood-sheevaplug.dts          |  43 ++
 arch/arm/boot/dts/kirkwood-topkick.dts             |  52 +-
 arch/arm/boot/dts/kirkwood-ts219-6281.dts          |   8 +-
 arch/arm/boot/dts/kirkwood-ts219-6282.dts          |  16 +-
 arch/arm/boot/dts/kirkwood-ts219.dtsi              |  10 +
 arch/arm/boot/dts/kirkwood.dtsi                    |  41 +-
 arch/arm/boot/dts/lpc32xx.dtsi                     |   8 +-
 arch/arm/boot/dts/omap2.dtsi                       |  11 +-
 arch/arm/boot/dts/omap2420-h4.dts                  |   2 +-
 arch/arm/boot/dts/omap2420.dtsi                    |   2 +-
 arch/arm/boot/dts/omap2430.dtsi                    |   2 +-
 arch/arm/boot/dts/omap3-beagle-xm.dts              |  48 +-
 arch/arm/boot/dts/omap3-beagle.dts                 |  72 +-
 arch/arm/boot/dts/omap3-devkit8000.dts             |  11 +-
 arch/arm/boot/dts/omap3-evm.dts                    |   7 +-
 arch/arm/boot/dts/omap3-igep.dtsi                  |  43 +-
 arch/arm/boot/dts/omap3-igep0020.dts               | 111 ++-
 arch/arm/boot/dts/omap3-igep0030.dts               |  60 +-
 arch/arm/boot/dts/omap3-overo.dtsi                 |  20 +-
 arch/arm/boot/dts/omap3-tobi.dts                   |  52 +-
 arch/arm/boot/dts/omap3.dtsi                       |  11 +-
 arch/arm/boot/dts/omap3430-sdp.dts                 |   5 +-
 arch/arm/boot/dts/omap34xx.dtsi                    |   2 +-
 arch/arm/boot/dts/omap36xx.dtsi                    |   2 +-
 arch/arm/boot/dts/omap4-panda-a4.dts               |  10 +-
 arch/arm/boot/dts/omap4-panda-common.dtsi          | 162 ++++-
 arch/arm/boot/dts/omap4-panda-es.dts               |  38 +-
 arch/arm/boot/dts/omap4-panda.dts                  |   4 +-
 arch/arm/boot/dts/omap4-sdp-es23plus.dts           |   8 +-
 arch/arm/boot/dts/omap4-sdp.dts                    | 126 ++--
 arch/arm/boot/dts/omap4-var-som.dts                |   8 +-
 arch/arm/boot/dts/omap4.dtsi                       | 131 ++--
 arch/arm/boot/dts/omap443x.dtsi                    |   8 +-
 arch/arm/boot/dts/omap4460.dtsi                    |  15 +-
 arch/arm/boot/dts/omap5-evm.dts                    | 261 -------
 arch/arm/boot/dts/omap5-uevm.dts                   | 485 ++++++++++++
 arch/arm/boot/dts/omap5.dtsi                       | 180 +++--
 arch/arm/boot/dts/picoxcell-pc3x2.dtsi             |   8 +-
 arch/arm/boot/dts/picoxcell-pc3x3.dtsi             |   8 +-
 arch/arm/boot/dts/prima2.dtsi                      |   2 +
 arch/arm/boot/dts/pxa2xx.dtsi                      |   7 +-
 arch/arm/boot/dts/r8a73a4.dtsi                     |   6 -
 .../boot/dts/r8a7740-armadillo800eva-reference.dts |  45 ++
 arch/arm/boot/dts/r8a7740.dtsi                     | 121 +++
 arch/arm/boot/dts/r8a7779.dtsi                     |  17 +
 arch/arm/boot/dts/r8a7790.dtsi                     |   6 -
 arch/arm/boot/dts/s3c2416-pinctrl.dtsi             | 173 +++++
 arch/arm/boot/dts/s3c2416-smdk2416.dts             |  72 ++
 arch/arm/boot/dts/s3c2416.dtsi                     |  79 ++
 arch/arm/boot/dts/s3c24xx.dtsi                     |  92 +++
 arch/arm/boot/dts/sama5d3.dtsi                     |  33 +-
 arch/arm/boot/dts/sh7372.dtsi                      |   5 +
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts       |  86 +++
 arch/arm/boot/dts/sh73a0.dtsi                      |  18 +-
 arch/arm/boot/dts/snowball.dts                     |  80 +-
 arch/arm/boot/dts/socfpga.dtsi                     | 217 +++++-
 arch/arm/boot/dts/socfpga_cyclone5.dts             |  13 +
 arch/arm/boot/dts/socfpga_vt.dts                   |   5 +
 arch/arm/boot/dts/spear13xx.dtsi                   |   2 +
 arch/arm/boot/dts/spear3xx.dtsi                    |   8 +-
 arch/arm/boot/dts/spear600.dtsi                    |   8 +-
 arch/arm/boot/dts/ste-nomadik-s8815.dts            |  69 ++
 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi         | 574 ++++++++++++++-
 arch/arm/boot/dts/stuib.dtsi                       |  26 +-
 arch/arm/boot/dts/sun4i-a10-cubieboard.dts         |  12 +
 arch/arm/boot/dts/sun4i-a10.dtsi                   |  54 ++
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts   |  76 ++
 arch/arm/boot/dts/sun5i-a10s.dtsi                  | 286 ++++++++
 arch/arm/boot/dts/sun5i-a13-olinuxino.dts          |  18 +
 arch/arm/boot/dts/sun5i-a13.dtsi                   |  89 ++-
 arch/arm/boot/dts/tegra114-dalmore.dts             |  71 +-
 arch/arm/boot/dts/tegra114-pluto.dts               |   2 +-
 arch/arm/boot/dts/tegra114.dtsi                    | 277 ++++---
 arch/arm/boot/dts/tegra20-colibri-512.dtsi         |  29 +-
 arch/arm/boot/dts/tegra20-harmony.dts              |  67 +-
 arch/arm/boot/dts/tegra20-iris-512.dts             |  13 +-
 arch/arm/boot/dts/tegra20-medcom-wide.dts          |  12 +-
 arch/arm/boot/dts/tegra20-paz00.dts                |  48 +-
 arch/arm/boot/dts/tegra20-plutux.dts               |  12 +-
 arch/arm/boot/dts/tegra20-seaboard.dts             |  69 +-
 arch/arm/boot/dts/tegra20-tamonten.dtsi            |  15 +-
 arch/arm/boot/dts/tegra20-tec.dts                  |  13 +-
 arch/arm/boot/dts/tegra20-trimslice.dts            |  46 +-
 arch/arm/boot/dts/tegra20-ventana.dts              |  60 +-
 arch/arm/boot/dts/tegra20-whistler.dts             |  47 +-
 arch/arm/boot/dts/tegra20.dtsi                     | 285 ++++----
 arch/arm/boot/dts/tegra30-beaver.dts               |  68 +-
 arch/arm/boot/dts/tegra30-cardhu-a02.dts           |  16 +-
 arch/arm/boot/dts/tegra30-cardhu-a04.dts           |  18 +-
 arch/arm/boot/dts/tegra30-cardhu.dtsi              |  47 +-
 arch/arm/boot/dts/tegra30.dtsi                     | 288 ++++----
 arch/arm/boot/dts/twl4030_omap3.dtsi               |  25 +
 arch/arm/boot/dts/usb_a9260.dts                    |   9 +
 arch/arm/boot/dts/usb_a9263.dts                    |  14 +
 arch/arm/boot/dts/usb_a9g20.dts                    |  18 +-
 arch/arm/boot/dts/usb_a9g20_common.dtsi            |  27 +
 arch/arm/boot/dts/usb_a9g20_lpw.dts                |  31 +
 arch/arm/boot/dts/vf610-pinfunc.h                  | 810 +++++++++++++++++++++
 arch/arm/boot/dts/vf610-twr.dts                    |  57 ++
 arch/arm/boot/dts/vf610.dtsi                       | 464 ++++++++++++
 arch/arm/boot/dts/vt8500-bv07.dts                  |   4 +
 arch/arm/boot/dts/vt8500.dtsi                      |  29 +-
 arch/arm/boot/dts/wm8505-ref.dts                   |   4 +
 arch/arm/boot/dts/wm8505.dtsi                      |  84 ++-
 arch/arm/boot/dts/wm8650-mid.dts                   |   3 +
 arch/arm/boot/dts/wm8650.dtsi                      |  79 +-
 arch/arm/boot/dts/wm8750-apc8750.dts               |  30 +
 arch/arm/boot/dts/wm8750.dtsi                      | 347 +++++++++
 arch/arm/boot/dts/wm8850-w70v2.dts                 |   4 +
 arch/arm/boot/dts/wm8850.dtsi                      |  94 ++-
 arch/arm/boot/dts/zynq-7000.dtsi                   |   2 +
 arch/arm/boot/dts/zynq-zc702.dts                   |   6 +-
 arch/arm/boot/dts/zynq-zc706.dts                   |  35 +
 arch/arm/boot/dts/zynq-zed.dts                     |  35 +
 arch/arm/configs/at91_dt_defconfig                 |   2 +
 arch/arm/configs/at91sam9260_9g20_defconfig        |   1 -
 arch/arm/configs/at91sam9263_defconfig             |   1 -
 arch/arm/configs/nhk8815_defconfig                 |   6 +
 arch/arm/mach-at91/Kconfig.non_dt                  |  19 -
 arch/arm/mach-at91/Makefile                        |   3 -
 arch/arm/mach-at91/at91sam9g45.c                   |   2 +
 arch/arm/mach-at91/at91sam9x5.c                    |   2 +
 arch/arm/mach-at91/board-usb-a926x.c               | 384 ----------
 arch/arm/mach-imx/clk-imx51-imx53.c                |   2 -
 arch/arm/mach-imx/mach-imx53.c                     |  16 -
 arch/arm/mach-mxs/Kconfig                          |   1 +
 arch/arm/mach-mxs/mach-mxs.c                       | 129 +++-
 arch/arm/mach-nomadik/Kconfig                      |   1 +
 arch/arm/mach-nomadik/cpu-8815.c                   |  73 +-
 arch/arm/mach-omap2/cclock33xx_data.c              |  49 +-
 arch/arm/mach-s3c24xx/Kconfig                      |  12 +
 arch/arm/mach-s3c24xx/Makefile                     |   1 +
 arch/arm/mach-s3c24xx/mach-s3c2416-dt.c            |  91 +++
 arch/arm/mach-shmobile/Kconfig                     |  14 +
 arch/arm/mach-shmobile/Makefile                    |   1 +
 .../board-armadillo800eva-reference.c              | 213 ++++++
 arch/arm/mach-shmobile/include/mach/r8a7740.h      |   3 +
 arch/arm/mach-shmobile/intc-r8a7740.c              |  24 +-
 arch/arm/mach-shmobile/setup-r8a7740.c             |  54 +-
 arch/arm/mach-ux500/cpu-db8500.c                   |  26 +-
 arch/arm/mach-zynq/common.c                        |   1 -
 drivers/bus/Kconfig                                |   9 +
 drivers/bus/Makefile                               |   1 +
 drivers/bus/imx-weim.c                             | 138 ++++
 drivers/clk/clk-nomadik.c                          | 576 ++++++++++++++-
 drivers/clk/samsung/clk-exynos4.c                  |   9 +-
 drivers/clocksource/nomadik-mtu.c                  |  60 +-
 drivers/crypto/ux500/cryp/cryp_core.c              |   6 +
 drivers/crypto/ux500/hash/hash_core.c              |   6 +
 drivers/irqchip/irq-renesas-intc-irqpin.c          |   9 +-
 drivers/pinctrl/pinctrl-nomadik.c                  |   6 +-
 drivers/regulator/ab8500.c                         |   8 +-
 include/dt-bindings/clock/tegra114-car.h           | 342 +++++++++
 include/dt-bindings/clock/tegra20-car.h            | 158 ++++
 include/dt-bindings/clock/tegra30-car.h            | 265 +++++++
 include/dt-bindings/dma/at91.h                     |  27 +
 include/dt-bindings/gpio/tegra-gpio.h              |  50 ++
 include/dt-bindings/pinctrl/am33xx.h               |  42 ++
 include/dt-bindings/pinctrl/omap.h                 |  55 ++
 299 files changed, 15647 insertions(+), 3302 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/bus/imx-weim.txt
 create mode 100644 Documentation/devicetree/bindings/clock/st,nomadik.txt
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
 create mode 100644 Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt
 create mode 100644 arch/arm/boot/dts/am4372.dtsi
 create mode 100644 arch/arm/boot/dts/am43x-epos-evm.dts
 create mode 100644 arch/arm/boot/dts/at91-foxg20.dts
 create mode 100644 arch/arm/boot/dts/ccu8540.dts
 create mode 100644 arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts
 create mode 100644 arch/arm/boot/dts/imx27-phytec-phycore-som.dts
 delete mode 100644 arch/arm/boot/dts/imx27-phytec-phycore.dts
 create mode 100644 arch/arm/boot/dts/imx28-cfa10055.dts
 create mode 100644 arch/arm/boot/dts/imx28-cfa10057.dts
 create mode 100644 arch/arm/boot/dts/imx53-m53evk.dts
 create mode 100644 arch/arm/boot/dts/imx53-tx53.dtsi
 create mode 100644 arch/arm/boot/dts/imx6q-phytec-pbab01.dts
 create mode 100644 arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
 create mode 100644 arch/arm/boot/dts/imx6sl-evk.dts
 create mode 100644 arch/arm/boot/dts/imx6sl.dtsi
 create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
 create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-sheevaplug.dts
 delete mode 100644 arch/arm/boot/dts/omap5-evm.dts
 create mode 100644 arch/arm/boot/dts/omap5-uevm.dts
 create mode 100644 arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
 create mode 100644 arch/arm/boot/dts/s3c2416-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/s3c2416-smdk2416.dts
 create mode 100644 arch/arm/boot/dts/s3c2416.dtsi
 create mode 100644 arch/arm/boot/dts/s3c24xx.dtsi
 create mode 100644 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
 create mode 100644 arch/arm/boot/dts/sun5i-a10s.dtsi
 create mode 100644 arch/arm/boot/dts/twl4030_omap3.dtsi
 create mode 100644 arch/arm/boot/dts/usb_a9g20_common.dtsi
 create mode 100644 arch/arm/boot/dts/usb_a9g20_lpw.dts
 create mode 100644 arch/arm/boot/dts/vf610-pinfunc.h
 create mode 100644 arch/arm/boot/dts/vf610-twr.dts
 create mode 100644 arch/arm/boot/dts/vf610.dtsi
 create mode 100644 arch/arm/boot/dts/wm8750-apc8750.dts
 create mode 100644 arch/arm/boot/dts/wm8750.dtsi
 create mode 100644 arch/arm/boot/dts/zynq-zc706.dts
 create mode 100644 arch/arm/boot/dts/zynq-zed.dts
 delete mode 100644 arch/arm/mach-at91/board-usb-a926x.c
 create mode 100644 arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
 create mode 100644 arch/arm/mach-shmobile/board-armadillo800eva-reference.c
 create mode 100644 drivers/bus/imx-weim.c
 create mode 100644 include/dt-bindings/clock/tegra114-car.h
 create mode 100644 include/dt-bindings/clock/tegra20-car.h
 create mode 100644 include/dt-bindings/clock/tegra30-car.h
 create mode 100644 include/dt-bindings/dma/at91.h
 create mode 100644 include/dt-bindings/gpio/tegra-gpio.h
 create mode 100644 include/dt-bindings/pinctrl/am33xx.h
 create mode 100644 include/dt-bindings/pinctrl/omap.h


From arnd at arndb.de  Tue Jul  2 15:04:01 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 2 Jul 2013 21:04:01 +0200
Subject: [GIT PULL 3/7] ARM SoC specific changes
In-Reply-To: <201307022055.50717.arnd@arndb.de>
References: <201307022055.50717.arnd@arndb.de>
Message-ID: <201307022104.01826.arnd@arndb.de>

The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f:

  Linux 3.10-rc6 (2013-06-15 11:51:07 -1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/soc-for-linus

for you to fetch changes up to 1eb92b24e243085d242cf5ffd64829bba70972e1:

  ARM: integrator: let pciv3 use mem/premem from device tree (2013-06-27 14:19:54 +0200)

----------------------------------------------------------------
ARM SoC specific changes

These changes are all to SoC-specific code, a total of 33 branches on
17 platforms were pulled into this. Like last time, Renesas sh-mobile
is now the platform with the most changes, followed by OMAP and EXYNOS.

Two new platforms, TI Keystone and Rockchips RK3xxx are added in
this branch, both containing almost no platform specific code at all,
since they are using generic subsystem interfaces for clocks, pinctrl,
interrupts etc. The device drivers are getting merged through the
respective subsystem maintainer trees.

One more SoC (u300) is now multiplatform capable and several others
(shmobile, exynos, msm, integrator, kirkwood, clps711x) are moving
towards that goal with this series but need more work.

Also noteworthy is the work on PCI here, which is traditionally part of
the SoC specific code. With the changes done by Thomas Petazzoni, we can
now more easily have PCI host controller drivers as loadable modules and
keep them separate from the platform code in drivers/pci/host. This has
already led to the discovery that three platforms (exynos, spear and imx)
are actually using an identical PCIe host controller and will be able
to share a driver once support for spear and imx is added.

Conflicts:
* asm/glue-proc.h has one CPU type getting added that conflicts
  with another addition in 3.10-rc7
* Simple context changes in arch/arm/Makefile and arch/arm/Kconfig

----------------------------------------------------------------

Afzal Mohammed (9):
      ARM: OMAP2+: separate out OMAP4 restart
      ARM: OMAP2+: AM43x: Kconfig
      ARM: OMAP2+: AM43x: kbuild
      ARM: OMAP2+: AM43x: soc_is support
      ARM: OMAP2+: AM437x: SoC revision detection
      ARM: OMAP2+: AM43x: static mapping
      ARM: OMAP2+: AM43x: early init
      ARM: OMAP2+: AM43x: GP or HS ?
      ARM: OMAP2+: AM43x: basic dt support

Aida Mynzhasova (2):
      ARM: OMAP2: TI81XX: id: Add cpu id for TI816x ES2.0 and ES2.1
      ARM: OMAP: TI816X: add powerdomains for TI816x

Alexander Shiyan (18):
      GPIO: clps711x: Rewrite driver for using generic GPIO code
      GPIO: clps711x: Add DT support
      ARM: clps711x: Re-add GPIO support
      ARM: clps711x: Remove NEED_MACH_MEMORY_H dependency
      ARM: clps711x: Set PLL clock to zero if we work from 13 mHz source
      ARM: clps711x: autcpu12: Move LCD DPOT definitions to board file
      ARM: clps711x: autcpu12: Add support for NOR flash
      ARM: clps711x: autcpu12: Special driver for handling memory is removed
      ARM: clps711x: autcpu12: Move remaining specific definitions to board file
      ARM: clps711x: p720t: Define PLD registers as GPIOs
      ARM: clps711x: Move specific definitions from hardware.h to boards files
      ARM: clps711x: Replace "arch_initcall" in common code with ".init_early"
      ARM: clps711x: Add clocksource framework
      ARM: clps711x: Optimize interrupt handling
      ARM: clps711x: edb7211: Add support for I2C
      ARM: clps711x: edb7211: Control LCD backlight via PWM
      ARM: clps711x: Add support for SYSCON driver
      ARM: clps711x: Update defconfig

Andrew Lunn (3):
      ARM: Kirkwood: Enable USB 3.0 in kirkwood_defconfig
      arm: kirkwood: Enable cpufreq and ondemand on kirkwood_defconfig
      arm: kirkwood: Instantiate cpufreq driver

Arnaud Ebalard (1):
      arm: kirkwood: NETGEAR ReadyNAS Duo v2 init PCIe via DT

Arnd Bergmann (27):
      drivers/bus: arm-cci: fix combined ARMv6+v7 build
      ARM: EXYNOS: Remove custom init_irq callbacks
      ARM: EXYNOS: Use exynos_init_io() as map_io callback
      ARM: EXYNOS: Remove legacy L2X0 initialization
      ARM: EXYNOS: Remove remaining dead code after non-DT support removal
      Merge tag 'integrator-pci-for-arm-soc' of git://git.kernel.org/.../linusw/linux-integrator into next/soc
      Merge tag 'u300-multiplatform' of git://git.kernel.org/.../linusw/linux-stericsson into next/soc
      Merge tag 'imx-soc-3.11' of git://git.linaro.org/people/shawnguo/linux-2.6 into next/soc
      ARM: u300: only build for ARCH_MULTI_V5
      Merge tag 'davinci-for-v3.11/soc-v2' of git://git.kernel.org/.../nsekhar/linux-davinci into next/soc
      Merge tag 'sunxi-defconfig-for-3.11' of git://github.com/mripard/linux into next/soc
      Merge tag 'sunxi-core-for-3.11-2' of git://github.com/mripard/linux into next/soc
      Merge tag 'omap-for-v3.11/soc-part2-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/soc
      Merge branch 'omap/pm-voltdomain-cleanup' into next/soc
      Merge tag 'exynos-arch-2' of git://git.kernel.org/.../kgene/linux-samsung into next/soc
      Merge tag 'remove-nondt-exynos-3' of git://git.kernel.org/.../kgene/linux-samsung into next/soc
      Merge tag 'samsung-defconfig-1' of git://git.kernel.org/.../kgene/linux-samsung into next/soc
      Merge tag 'v3.11-rockchip-basics' of git://git.kernel.org/.../mmind/linux-rockchip into next/soc
      Merge tag 'renesas-cleanup-boot-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/soc
      Merge tag 'regmap-3.11-2' of git://git.infradead.org/users/jcooper/linux into next/soc
      ARM: imx: Synertronixx scb9328 needs to select SOC_IMX1
      ARM: keystone: select ARM_ERRATA_798181 only for SMP
      ARM: imx: select syscon for IMX6SL
      ARM: multiplatform: always pick one CPU type
      Merge tag 'davinci-for-v3.11/soc-2' of git://git.kernel.org/.../nsekhar/linux-davinci into next/soc
      Merge tag 'omap-pm-v3.11/fixes/omap5-voltdm' of git://git.kernel.org/.../khilman/linux-omap-pm into next/soc
      Merge tag 'soc-for-linus' into for-linus

Bastian Hecht (5):
      sh-pfc: Add entries for INTC external IRQs
      sh-pfc: r8a7740: Add SCIFA1 data group
      ARM: shmobile: armadillo800eva: Convert SCIFA1 to pinctrl
      ARM: shmobile: r8a7740: Add interim sh-eth device name to clocks list
      ARM: shmobile: r8a7740: Add I2C DT clock names

Benoit Cousson (7):
      ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files
      ARM: OMAP5: CM: Add OMAP54XX register and bitfield files
      ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers
      ARM: OMAP5: SCRM: Add OMAP54XX header file.
      ARM: OMAP5: clockdomain data: Add OMAP54XX data and update the header
      ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header
      ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data

Catalin Marinas (1):
      ARM: Add base support for ARMv7-M

Dave Martin (1):
      ARM: vexpress/dcscb: handle platform coherency exit/setup and CCI

Dinh Nguyen (2):
      ARM: socfpga: Add support to gate peripheral clocks
      ARM: socfpga: Add syscon to be part of socfpga

Dirk Behme (3):
      ARM: i.MX6: add i.MX6 specific L2 cache configuration
      ARM: i.MX6: clk: add i.MX6 DualLite differences
      ARM: i.MX6: clk: add different DualLite MLB clock config

Dmitry Osipenko (1):
      ARM: tegra: emc: correction of ram-code parsing from dt

Doug Anderson (1):
      ARM: EXYNOS: Select PINCTRL_EXYNOS for exynos4/5 at chip level

Ezequiel Garcia (1):
      ARM: mvebu: Add support for USB storage class in mvebu_defconfig

Fabio Estevam (6):
      ARM: imx: imx_v6_v7_defconfig: Select CONFIG_DRM_IMX_TVE
      ARM: imx: Enable mx6 solo-lite support
      ARM: imx: irq-common: Include header to avoid sparse warning
      ARM: imx: clk: No need to initialize phandle struct
      ARM: imx_v6_v7_defconfig: Enable PWM and backlight options
      ARM: imx_v6_v7_defconfig: Enable Vybrid VF610

Guennadi Liakhovetski (9):
      pinctrl: sh-pfc: fix r8a7790 Function Select register tables
      pinctrl: sh-pfc: fix a typo in pfc-r8a7790
      pinctrl: r8a7790: add pinmux data for MMCIF and SDHI interfaces
      ARM: shmobile: sh73a0: add support for adjusting CPU frequency
      ARM: shmobile: sh73a0: add CPUFreq support
      ARM: shmobile: sh73a0: do not overwrite all div4 clock operations
      ARM: shmobile: sh73a0: div4 clocks must check the kick bit before changing rate
      ARM: shmobile: r8a73a4: add clock definitions and aliases for MMCIF and SDHI
      ARM: shmobile: r8a7790: add clock definitions and aliases for MMCIF and SDHI

Heiko Stuebner (10):
      ARM: S3C24XX: split s3c2412 spi dma channels
      ARM: S3C24XX: dma-s3c2443 - do not write into arbitary bits
      ARM: S3C24XX: remove obsolete s3c2412 specific dma settings
      clocksource: dw_apb_timer_of: enable the use the clocksource as sched clock
      clocksource: dw_apb_timer_of: add clock-handling
      clocksource: dw_apb_timer_of: select DW_APB_TIMER
      clocksource: dw_apb_timer_of: use clocksource_of_init
      arm: Add basic clocks for Rockchip rk3066a SoCs
      arm: add debug uarts for rockchip rk29xx and rk3xxx series
      arm: add basic support for Rockchip RK3066a boards

Huang Shijie (1):
      ARM: imx6q: clk: add the eim_slow clock

Jason Cooper (3):
      ARM: kirkwood: enable Sheevaplug DT in defconfig
      Merge tag 'tags/fixes-non-3.11-1' into mvebu/regmap
      Merge tag 'tags/cleanup-3.11-3' into mvebu/regmap

Jiada Wang (2):
      ARM: imx: disable pll8_mlb in mx6q_clks
      ARM: imx: remove MLB PLL from pllv3

Jingchang Lu (2):
      ARM: imx: add VF610 clock support
      ARM: imx: add initial support for VF610

Jingoo Han (4):
      pci: Add PCIe driver for Samsung Exynos
      ARM: EXYNOS: Enable PCIe support for Exynos5440
      ARM: dts: Add pcie controller node for Samsung EXYNOS5440 SoC
      ARM: dts: Add pcie controller node for exynos5440-ssdk5440

Jon Medhurst (2):
      ARM: Enable selection of SMP operations at boot time
      ARM: vexpress: Select multi-cluster SMP operation if required

Joseph Lo (12):
      ARM: tegra: add an assembly marco to check Tegra SoC ID
      ARM: tegra: skip SCU and PL310 code when CPU is not Cortex-A9
      ARM: tegra: make tegra_resume can work for Tegra114
      ARM: tegra114: add power up sequence for warm boot CPU
      clk: tegra114: implement wait_for_reset and disable_clock for tegra_cpu_car_ops
      ARM: tegra114: add CPU hotplug support
      ARM: tegra: add cpu_disable for hotplug
      ARM: tegra: remove ifdef in the tegra_resume
      ARM: tegra: cpuidle: move the init function behind the suspend init function
      ARM: tegra: hook tegra_tear_down_cpu function in the PM suspend init function
      ARM: tegra: cpuidle: using IS_ENABLED for multi SoCs management in init func
      ARM: tegra: don't pass CPU ID to tegra_{set,clear}_cpu_in_lp2

Koji Matsuoka (1):
      sh-pfc: Initial r8a7790 PFC support

Kukjin Kim (1):
      ARM: EXYNOS: no more support non-DT for EXYNOS SoCs

Kuninori Morimoto (35):
      gpio-rcar: R-Car GPIO IRQ share interrupt
      ARM: shmobile: add GPIO IRQ macro
      ARM: shmobile: r8a7778: Register PFC device
      sh-pfc: Add r8a7778 pinmux support
      sh-pfc: r8a7779: use RCAR_GP_PIN() on _GP_GPIO() macro
      sh-pfc: r8a7778: add common PFC macro helper
      sh-pfc: r8a7778: add SDHI support
      sh-pfc: r8a7778: tidyup SDHI naming suffixes and sort it alphabetically
      ARM: shmobile: r8a7778: add GPIO support
      sh-pfc: r8a7778: fixup IRQ1A settings
      sh-pfc: r8a7778: add I2C pin groups
      sh-pfc: r8a7778: add HSPI pin groups
      sh-pfc: r8a7778: add MMCIF pin groups
      ARM: shmobile: kzm9g: tidyup FSI pinctrl
      ARM: shmobile: bockw: add pinctrl support
      ARM: shmobile: remove ";" from SH_FIXED_RATIO_CLK*() macro
      ARM: shmobile: use do{ }while() on SH_CLK_SET_RATIO()
      ARM: shmobile: r8a7778: fixup Ether setup code position
      ARM: shmobile: r8a73a4: add main clock
      ARM: shmobile: r8a73a4: add pll clocks
      ARM: shmobile: r8a73a4: add div4 clocks
      ARM: shmobile: r8a73a4: add div6 clocks
      ARM: shmobile: r8a7778: use fixed ratio clock
      ARM: shmobile: r8a7778: add SDHI clock support
      ARM: shmobile: r8a7778: Register SDHI device
      ARM: shmobile: r8a7790: add main clock
      ARM: shmobile: r8a7790: add div4 clocks
      ARM: shmobile: r8a7790: add div6 clocks
      ARM: shmobile: r8a7778: add support I2C clock
      ARM: shmobile: r8a7778: add support HSPI clock
      ARM: shmobile: r8a7778: add support MMC clock
      ARM: shmobile: r8a7778: add support I2C driver
      ARM: shmobile: r8a7778: add support HSPI driver
      ARM: shmobile: r8a7778: add support MMC driver
      ARM: shmobile: Remove Bonito board support

Lad, Prabhakar (2):
      ARM: davinci: remove __init atrribute from function declaration
      ARM: edma: Convert to devm_* api

Laurent Pinchart (102):
      gpio-rcar: Make the platform data gpio_base field signed
      gpio-rcar: Add RCAR_GP_PIN macro
      sh-pfc: Remove dependency on GPIOLIB
      sh-pfc: r8a7790: Add ETH pin groups and functions
      sh-pfc: r8a7790: Add INTC pin groups and functions
      sh-pfc: r8a7790: Add SCIF, SCIFA and SCIFB pin groups and functions
      sh-pfc: r8a7790: Remove GPIO data
      sh-pfc: r8a7790: Remove function GPIOs
      sh-pfc: r8a7790: Don't use GPIO enum entries
      sh-pfc: r8a7779: Replace hardcoded pin numbers with RCAR_GP_PIN macro
      sh-pfc: sh7372: Add BSC pin groups and functions
      sh-pfc: sh7372: Add CEU pin groups and functions
      sh-pfc: sh7372: Add FLCTL pin groups and functions
      sh-pfc: sh7372: Add FSI pin groups and functions
      sh-pfc: sh7372: Add HDMI pin groups and functions
      sh-pfc: sh7372: Add INTC pin groups and functions
      sh-pfc: sh7372: Add KEYSC pin groups and functions
      sh-pfc: sh7372: Add LCDC pin groups and functions
      sh-pfc: sh7372: Add SCIF pin groups and functions
      sh-pfc: sh7372: Add USB pin groups and functions
      ARM: shmobile: mackerel: Register pinctrl mapping for the ADXL34X
      ARM: shmobile: mackerel: Register pinctrl mapping for CEU
      ARM: shmobile: mackerel: Register pinctrl mapping for FLCTL
      ARM: shmobile: mackerel: Register pinctrl mapping for FSI
      ARM: shmobile: mackerel: Register pinctrl mapping for HDMI
      ARM: shmobile: mackerel: Register pinctrl mapping for LCD
      ARM: shmobile: mackerel: Register pinctrl mapping for SCIF
      ARM: shmobile: mackerel: Register IRQ pinctrl mapping for SDHI0
      ARM: shmobile: mackerel: Register pinctrl mapping for SMSC911x
      ARM: shmobile: mackerel: Register pinctrl mapping for ST1232
      ARM: shmobile: mackerel: Register pinctrl mapping for TCA6416
      ARM: shmobile: mackerel: Register pinctrl mapping for USBHS
      ARM: shmobile: ap4evb: Register pinctrl mapping for CEU
      ARM: shmobile: ap4evb: Register pinctrl mapping for FSI
      ARM: shmobile: ap4evb: Register pinctrl mapping for HDMI
      ARM: shmobile: ap4evb: Register pinctrl mapping for KEYSC
      ARM: shmobile: ap4evb: Register pinctrl mapping for LCD
      ARM: shmobile: ap4evb: Register pinctrl mapping for SCIF
      ARM: shmobile: ap4evb: Register pinctrl mapping for SMSC911x
      ARM: shmobile: ap4evb: Simplify tsc2007 pen state read function
      ARM: shmobile: ap4evb: Register pinctrl mapping for TSC2007
      ARM: shmobile: ap4evb: Register pinctrl mapping for USBHS
      sh-pfc: sh7372: Replace GPIO_PORTx enum with GPIO port numbers
      sh-pfc: sh7372: Remove function GPIOs
      ARM: shmobile: sh7372: Remove all GPIOs
      sh-pfc: sh7372: Add bias (pull-up/down) pinconf support
      sh-pfc: r8a7740: Add SCIF pin groups and functions
      sh-pfc: r8a7740: Declare missing INTC function
      sh-pfc: r8a7740: Add BSC pin groups and functions
      sh-pfc: r8a7740: Add GETHER pin groups and functions
      sh-pfc: r8a7740: Add CEU pin groups and functions
      sh-pfc: r8a7740: Add FSI pin groups and functions
      sh-pfc: r8a7740: Add HDMI pin groups and functions
      sh-pfc: r8a7740: Hardcode the LCDC0 output
      ARM: shmobile: armadillo800eva: Register pinctrl mapping for INTC
      ARM: shmobile: armadillo800eva: Register pinctrl mapping for GETHER
      ARM: shmobile: armadillo800eva: Register pinctrl mapping for CEU0
      ARM: shmobile: armadillo800eva: Register pinctrl mapping for FSI
      ARM: shmobile: armadillo800eva: Register pinctrl mapping for HDMI
      ARM: shmobile: armadillo800eva: Don't configure LCDC routing manually
      ARM: shmobile: armadillo800eva: Replace GPIO_PORTx with GPIO port numbers
      ARM: shmobile: bonito: Remove empty core devices array
      ARM: shmobile: bonito: Register pinctrl mapping for SCIF
      ARM: shmobile: bonito: Register pinctrl mapping for INTC
      ARM: shmobile: bonito: Register pinctrl mapping for BSC
      ARM: shmobile: bonito: Don't configure LCDC routing manually
      sh-pfc: r8a7740: Remove SCIF function GPIOS
      sh-pfc: r8a7740: Remove INTC function GPIOS
      sh-pfc: r8a7740: Remove BSC function GPIOS
      sh-pfc: r8a7740: Remove GETHER function GPIOS
      sh-pfc: r8a7740: Remove CEU function GPIOS
      sh-pfc: r8a7740: Remove FSI function GPIOS
      sh-pfc: r8a7740: Remove HDMI function GPIOS
      ARM: shmobile: r8a7740: Remove SCIF function GPIOs
      ARM: shmobile: r8a7740: Remove INTC function GPIOs
      ARM: shmobile: r8a7740: Remove BSC function GPIOs
      ARM: shmobile: r8a7740: Remove GETHER function GPIOs
      ARM: shmobile: r8a7740: Remove CEU function GPIOs
      ARM: shmobile: r8a7740: Remove FSI function GPIOs
      ARM: shmobile: r8a7740: Remove HDMI function GPIOs
      sh-pfc: r8a7740: Remove function GPIOs
      sh-pfc: r8a7740: Replace GPIO_PORTx enum with GPIO port numbers
      ARM: shmobile: r8a7740: Remove all GPIOs
      sh-pfc: r8a7740: Add bias (pull-up/down) pinconf support
      sh-pfc: r8a7778: Fix outdated GPIO_FN comments
      ARM: shmobile: r8a7790: Register GPIO devices
      ARM: shmobile: r8a7790: Remove all GPIOs
      sh-pfc: Add support for SoC-specific initialization
      sh-pfc: sh73a0: Add VCCQ MC0 regulator
      ARM: shmobile: kzm9g: Remove the VCCQ MC0 function GPIO
      ARM: shmobile: kzm9g-reference: Remove the VCCQ MC0 function GPIO
      sh-pfc: sh73a0: Add TPU pin groups and functions
      sh-pfc: r8a7740: Add TPU pin groups and functions
      sh-pfc: r8a7790: Add TPU pin groups and functions
      sh-pfc: sh73a0: Remove function GPIOs
      Revert "ARM: shmobile: Disallow PINCTRL without GPIOLIB"
      ARM: shmobile: lager: Initialize pinmux
      ARM: shmobile: marzen: Use RCAR_GP_PIN macro
      ARM: shmobile: r8a7740: Make private clock arrays static
      ARM: shmobile: r8a7740: add TPU PWM support
      ARM: shmobile: r8a7790: Make private clock arrays static
      ARM: shmobile: r8a7790: add TPU PWM support

Leela Krishna Amudala (1):
      ARM: EXYNOS: call scu_enable() only in case of cortex-A9 processor

Linus Walleij (51):
      ARM: u300: enable delaytimer on the U300
      ARM: u300: device tree support for the timer
      pinctrl: u300 device tree support
      pinctrl: coh901: add device tree support
      ARM: u300: basic device tree support
      i2c: stu300: device tree support
      ARM: u300: register I2C bus drivers from device tree
      watchdog: coh901327: devicetree support
      ARM: u300: add the COH 901 327 watchdog to device tree
      Documentation/devicetree: add a small note on PCI
      ARM: pci: create pci_common_init_dev()
      ARM: integrator: merge PCIv3 driver into one file
      ARM: integrator: convert PCIv3 bridge to platform device
      ARM: integrator: grab PCI error IRQ in probe()
      ARM: integrator: move PCI base address grab to probe
      ARM: integrator: move V3 register definitions into driver
      ARM: integrator: remap PCIv3 base dynamically
      ARM: integrator: move VGA base assignment
      ARM: integrator: move static ioremapping into PCIv3 driver
      ARM: integrator: basic PCIv3 device tree support
      rtc: coh901331: add devicetree support
      ARM: u300: add RTC to device tree
      ARM: u300: set up board power from device tree
      ARM: u300: support regulators in the device tree
      ARM: u300: enable MMC/SD card from device tree
      dma: coh901318: add devicetree support
      ARM: u300: augment device tree with DMA channels
      ARM: u300: add the COH 901 318 DMAC to device tree
      ARM: u300: add SPI PL022 to the device tree
      ARM: u300: probe the U300 dummy-spichip from device tree
      ARM: u300: add FSMC flash into the device tree
      ARM: u300: delete all static board data
      ARM: u300: move debugmacro to debug includes
      ARM: u300: remove deps from debug macro
      ARM: u300: push down syscon registers
      ARM: u300: delete <mach/hardware.h>
      ARM: u300: delete <mach/irqs.h>
      ARM: u300: localize <mach/u300-regs.h>
      ARM: u300: convert to multiplatform
      ARM: u300: delete remnant machine headers
      ARM: u300: add syscon node
      ARM: u300: remove register definition file
      clk: move the U300 fixed and fixed-factor to DT
      i2c: stu300: do not request a specific clock name
      ARM: u300: move the gated system controller clocks to DT
      ARM: u300: convert MMC/SD clock to device tree
      pinctrl: get rid of all platform data for coh901
      spi: pl022: use DMA by default when probing from DT
      ARM: u300: switch to using syscon regmap for board
      ARM: integrator: set local side PCI addresses right
      ARM: integrator: let pciv3 use mem/premem from device tree

Lorenzo Pieralisi (1):
      drivers: bus: add ARM CCI support

Magnus Damm (17):
      ARM: shmobile: r8a7779 pinmux platform device cleanup
      ARM: shmobile: r8a7740 pinmux platform device cleanup
      ARM: shmobile: sh73a0: Always use shmobile_setup_delay()
      ARM: shmobile: uImage load address rework
      ARM: shmobile: Let romImage rely on default ATAGS
      ARM: shmobile: Remove romImage CONFIG_MEMORY_START
      ARM: shmobile: Rework sh7372 sleep code to use virt_to_phys()
      ARM: shmobile: Add SMP boot function and argument
      ARM: shmobile: Add SCU boot function using argument
      ARM: shmobile: r8a7779 SMP with SCU boot fn and args
      ARM: shmobile: sh73a0 SMP with SCU boot fn and args
      ARM: shmobile: EMEV2 SMP with SCU boot fn and args
      ARM: shmobile: Remove old SCU boot code
      ARM: shmobile: Enable ARM_PATCH_PHYS_VIRT
      ARM: shmobile: Remove MEMORY_START/SIZE
      ARM: shmobile: Remove mach/memory.h
      ARM: shmobile: Remove AP4EVB board support

Markus Pargmann (1):
      ARM: imx: Remove mxc specific ulpi access ops

Martin Fuzzey (1):
      ARM: i.MX5: Allow DT clock providers

Matt Porter (6):
      ARM: davinci: move private EDMA API to arm/common
      ARM: edma: remove unused transfer controller handlers
      dmaengine: edma: Add TI EDMA device tree binding
      ARM: edma: Add DT and runtime PM support to the private EDMA API
      ARM: edma: Add EDMA crossbar event mux support
      dmaengine: edma: enable build for AM33XX

Maxime Ripard (2):
      ARM: sunxi: Add Allwinner A10s machine compatible
      ARM: multi_v7: Enable Allwinner EMAC in multi_v7_defconfig

Mohammed, Afzal (1):
      ARM: OMAP2+: AM43x: resolve SMP related build error

Nicolas Pitre (4):
      drivers/bus: arm-cci: function to enable CCI ports from early boot code
      ARM: vexpress: introduce DCSCB support
      ARM: vexpress/dcscb: add CPU use counts to the power up/down API implementation
      ARM: vexpress/dcscb: do not hardcode number of CPUs per cluster

Nicolin Chen (2):
      ARM: clk-imx6qdl: Add clko1 configuration for imx6qdl-sabresd
      ARM: imx_v6_v7_defconfig: Enable imx-wm8962 by default

Nishanth Menon (1):
      ARM: OMAP5: voltagedomain data: remove temporary OMAP4 voltage data

Olof Johansson (22):
      Merge tag 'soc-3.11-2' of git://git.infradead.org/users/jcooper/linux into next/soc
      Merge tag 'defconfig-3.11-3' of git://git.infradead.org/users/jcooper/linux into next/soc
      Merge tag 'pcie-3.11-2' of git://git.infradead.org/users/jcooper/linux into next/soc
      Merge tag 'pcie_kw-3.11' of git://git.infradead.org/users/jcooper/linux into next/soc
      Merge tag 'pcie_bridge-3.11' of git://git.infradead.org/users/jcooper/linux into next/soc
      Merge tag 'seb_clk-3.11' of git://git.infradead.org/users/jcooper/linux into next/soc
      Merge branch 'depends/rmk-devel-stable' into next/soc
      Merge branch 'VExpress_DCSCB' of git://git.linaro.org/people/nico/linux into next/soc
      Merge tag 'zynq-clk-for-3.11' of git://git.xilinx.com/linux-xlnx into next/soc
      Merge tag 'pcie_kw-3.11-2' of git://git.infradead.org/users/jcooper/linux into next/soc
      Merge tag 'renesas-pinmux-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/soc
      Merge tag 'renesas-soc-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/soc
      Merge branch 'clps711x/soc' into next/soc
      Merge tag 's3c24xx-arch-1' of git://git.kernel.org/.../kgene/linux-samsung into next/soc
      Merge tag 'omap-for-v3.11/pm-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/soc
      Merge tag 'omap-for-v3.11/soc-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/soc
      Merge tag 'omap-for-v3.11/omap5-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/soc
      Merge tag 'regmap-3.11' of git://git.infradead.org/users/jcooper/linux into next/soc
      Merge tag 'renesas-phy-rcar-usb-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/soc
      Merge tag 'renesas-soc2-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/soc
      Merge tag 'tegra-for-3.11-soc' of git://git.kernel.org/.../swarren/linux-tegra into next/soc
      Merge tag 'keystone-soc-for-arm-soc' of git://git.kernel.org/.../ssantosh/linux-keystone into next/soc

Peter Huewe (1):
      ARM: u300 use module_spi_driver to register driver

Phil Edworthy (2):
      pinctrl: sh-pfc: r8a7779: Fix missing MOD_SEL2 entry
      ARM: shmobile: r8a7779: Add PCIe clocks

Philip Avinash (1):
      ARM: AM33XX: clk: Add clock node for EHRPWM TBCLK

Philipp Zabel (1):
      ARM i.MX5: Add S/PDIF clocks

Rob Herring (1):
      ARM: introduce common set_auxcr/get_auxcr functions

Roger Quadros (1):
      ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies

Rogerio Pimentel (1):
      ARM: imx_v6_v7_defconfig: enable parallel display

Russell King (2):
      Merge branch 'for-next' of git://git.pengutronix.de/git/ukl/linux into devel-stable
      Merge tag '3.10-rc2-psci-ops-11-tag' of git://git.kernel.org/.../sstabellini/xen into devel-stable

Sanjeev Premi (1):
      ARM: OMAP2+: AM43x: SRAM base and size

Santosh Shilimkar (13):
      ARM: OMAP4: PM: Avoid expensive cpu_suspend() path for all CPU power states except off
      ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
      ARM: OMAP4+: Make secondary_startup function name more consistent
      ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
      ARM: OMAP4+: PRM: Move function prototypes to common header for re-use
      ARM: OMAP4+: CM: Move function prototypes to common header for re-use
      ARM: OMAP4+: PRCM MPU: Move function prototypes to common header for re-use
      ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data
      ARM: OMAP5: Enable build and frameowrk initialisations
      ARM: dts: keystone: Add minimal Keystone SOC device tree data
      ARM: keystone: Add minimal TI Keystone platform support
      ARM: keystone: Enable SMP support on Keystone machines
      ARM: keystone: Move CPU bringup code to dedicated asm file

Sascha Hauer (1):
      ARM i.MX53: Add SATA clock

Sebastian Hesselbarth (10):
      clk: mvebu: introduce per-clock-gate flags
      clk: mvebu: add common clock functions for core clk and clk gating
      clk: mvebu: add Dove SoC-centric clock init
      clk: mvebu: add Kirkwood SoC-centric clock init
      clk: mvebu: add Armada 370 SoC-centric clock init
      clk: mvebu: add Armada XP SoC-centric clock init
      ARM: dove: move DT boards to SoC-centric clock init
      ARM: kirkwood: move DT boards to SoC-centric clock init
      ARM: mvebu: move DT boards to SoC-centric clock init
      clk: mvebu: disintegrate obsolete file

Sergei Shtylyov (18):
      sh-pfc: r8a7778: add USB pin groups
      sh-pfc: r8a7778: add Ether pin groups
      sh-pfc: r8a7779: add Ether pin groups
      ARM: shmobile: r8a7778: correct model name in Kconfig
      ARM: shmobile: r8a7779: fix Ether device name
      ARM: shmobile: r8a7778: fix Ether device name
      ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
      ehci-platform: add pre_setup() method to platform data
      ARM: shmobile: r8a7779: setup EHCI internal buffer
      phy-rcar-usb: remove EHCI internal buffer setup
      ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource
      phy-rcar-usb: correct base address
      phy-rcar-usb: add platform data
      ARM: shmobile: Marzen: pass platform data to USB PHY device
      phy-rcar-usb: handle platform data
      phy-rcar-usb: add R8A7778 support
      ARM: shmobile: r8a7778: add USB support
      ARM: shmobile: BOCK-W: add USB support

Shawn Guo (8):
      ARM: imx: include <asm/io.h> in hardware.h
      ARM: imx: move clk_prepare() out from mxc_restart()
      ARM: imx: create mxc_arch_reset_init_dt() for DT boot
      ARM: imx: add clock support for imx6sl
      ARM: imx: enable low-level debug support for imx6sl
      ARM: imx: add initial support for imx6sl
      ARM: imx6q: call of_clk_init() to register fixed rate clocks
      ARM: imx6: use common of_clk_init() call to initialize clocks

Simon Horman (4):
      gpio-rcar: Add support for IRQ_TYPE_EDGE_BOTH
      ARM: shmobile: r8a7790: Configure R-Car GPIO for IRQ_TYPE_EDGE_BOTH
      ARM: shmobile: sh73a0: Use DEFINE_RES_MEM*() everywhere
      Merge branches 'heads/pinmux' and 'heads/soc' into phy-rcar-usb-base

Soren Brinkmann (4):
      clk: zynq: Factor out PLL driver
      clk: zynq: Add clock controller driver
      arm: zynq: Migrate platform to clock controller
      clk: zynq: Remove deprecated clock code

Stefano Stabellini (1):
      arm: introduce psci_smp_ops

Thomas Petazzoni (27):
      arm: kirkwood: use the default of match table
      arm: mvebu: update defconfig with PCI and USB support
      clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
      clk: mvebu: add more PCIe clocks for Armada XP
      pci: PCIe driver for Marvell Armada 370/XP systems
      arm: mvebu: PCIe support is now available on mvebu
      arm: kirkwood: update defconfig with PCIe driver and board updates
      pci: mvebu: no longer fake the slot location of downstream devices
      pci: mvebu: allow the enumeration of devices beyond physical bridges
      pci: mvebu: fix the emulation of the status register
      pci: mvebu: enable driver usage on Kirkwood
      arm: kirkwood: move PCIe window init to legacy driver
      arm: kirkwood: add SoC-level Device Tree data for PCIe interfaces
      arm: kirkwood: convert Iomega Iconnect to use DT for the PCIe interface
      arm: kirkwood: convert MPL CEC4 to use DT for the PCIe interface
      arm: kirkwood: convert ZyXEL NSA310 to use DT for the PCIe interface
      arm: kirkwood: convert QNAP TS219 to use DT for the PCIe interface
      arm: kirkwood: convert db-88f6281/db-88f6282 to the Device Tree
      arm: mvebu: remove dependency of SMP init on static I/O mapping
      arm: mvebu: avoid hardcoded virtual address in coherency code
      arm: mvebu: move cache and mvebu-mbus initialization later
      arm: mvebu: remove hardcoded static I/O mapping
      arm: mvebu: don't hardcode a physical address in headsmp.S
      arm: mvebu: don't hardcode the physical address for mvebu-mbus
      arm: mvebu: add another earlyprintk Kconfig option
      arm: mvebu: disable DEBUG_LL/EARLY_PRINTK in defconfig
      arm: mvebu: fix coherency_late_init() for multiplatform

Tomasz Figa (30):
      ARM: EXYNOS: Remove unused board files
      ARM: EXYNOS: Make ARCH_EXYNOS select USE_OF
      ARM: SAMSUNG: Introduce SAMSUNG_ATAGS Kconfig entry
      ARM: EXYNOS: Remove legacy PMU initialization code
      ARM: EXYNOS: Remove legacy EINT initialization code
      ARM: EXYNOS: Remove legacy UART initialization code
      ARM: EXYNOS: Remove legacy dev- and setup- files
      ARM: EXYNOS: Remove legacy interrupt initialization code
      ARM: EXYNOS: Remove legacy timer initialization code
      ARM: EXYNOS: Remove platform device initialization
      ARM: EXYNOS: Remove legacy mapping of chip ID block
      ARM: EXYNOS: Remove check for device tree presence
      ARM: EXYNOS: Remove legacy power domain registration code
      ARM: SAMSUNG: Introduce GPIO_SAMSUNG Kconfig entry
      ARM: EXYNOS: Provide compatibility stubs for PM code in pm-core.h header
      ARM: SAMSUNG: Compile legacy IRQ and GPIO PM code only with ATAGS support
      platform: Check for ARCH_EXYNOS separately
      USB: Check for ARCH_EXYNOS separately
      ARM: EXYNOS: Decouple ARCH_EXYNOS from PLAT_S5P
      ARM: SAMSUNG: Include most of mach/ headers conditionally
      ARM: EXYNOS: Do not select legacy Kconfig symbols any more
      ARM: EXYNOS: Remove setup-i2c0.c
      ARM: EXYNOS: Remove mach/gpio.h
      ARM: EXYNOS: Remove mach/regs-gpio.h header
      ARM: SAMSUNG: Make legacy MFC support code depend on SAMSUNG_ATAGS
      ARM: EXYNOS: Select SPARSE_IRQ for Exynos
      ARM: EXYNOS: Remove mach/irqs.h header
      ARM: EXYNOS: Remove unused base addresses from mach/map.h header
      thermal: exynos: Support both EXYNOS4X12 SoCs
      ARM: EXYNOS: Remove mach/regs-usb-phy.h header

Tony Lindgren (4):
      Merge tag 'omap-pm-v3.10/cleanup/pm' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-v3.11/pm
      Merge tag 'omap-devel-b-for-3.11' of http://git.kernel.org/cgit/linux/kernel/git/pjw/omap-pending into omap-for-v3.11/soc
      Merge tag 'omap-devel-a-for-3.11' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.11/omap5
      ARM: OMAP5: Remove unused include for ocp2scp

Tushar Behera (1):
      ARM: exynos_defconfig: Enable GPIO buttons and RTC drivers

Ulf Hansson (1):
      ARM: u300: Update MMC configs for u300 defconfig

Ulrich Hecht (1):
      ARM: shmobile: r8a7790: HSCIF support

Uwe Kleine-K?nig (3):
      ARM: ARMv7-M: Add support for exception handling
      ARM: ARMv7-M: Allow the building of new kernel port
      ARM: ARMv7-M: implement read_cpuid_ext

Vaibhav Hiremath (2):
      ARM: OMAP2+: AM33xx: Add missing reset status info to GFX hwmod
      ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature

Vivek Gautam (1):
      ARM: EXYNOS: Enable XHCI support on exynos5

Vladimir Barinov (2):
      sh-pfc: r8a7779: add VIN pin groups
      sh-pfc: r8a7778: add VIN pin groups

Wei Yongjun (1):
      pci: mvebu: fix return value check in mvebu_pcie_probe()

 Documentation/arm/sunxi/README                     |    4 +
 Documentation/devicetree/bindings/arm/cci.txt      |  172 +
 .../devicetree/bindings/arm/keystone/keystone.txt  |   10 +
 .../devicetree/bindings/arm/rtsm-dcscb.txt         |   19 +
 Documentation/devicetree/bindings/arm/ste-u300.txt |   46 +
 .../devicetree/bindings/clock/imx5-clock.txt       |   13 +
 .../devicetree/bindings/clock/imx6q-clock.txt      |    1 +
 .../devicetree/bindings/clock/imx6sl-clock.txt     |   10 +
 .../bindings/clock/ste-u300-syscon-clock.txt       |   80 +
 .../devicetree/bindings/clock/vf610-clock.txt      |   26 +
 .../devicetree/bindings/clock/zynq-7000.txt        |  123 +-
 .../devicetree/bindings/dma/ste-coh901318.txt      |   32 +
 Documentation/devicetree/bindings/dma/ti-edma.txt  |   34 +
 .../devicetree/bindings/gpio/gpio-clps711x.txt     |   28 +
 .../bindings/gpio/gpio-stericsson-coh901.txt       |    7 +
 .../devicetree/bindings/i2c/i2c-st-ddci2c.txt      |   15 +
 .../devicetree/bindings/pci/designware-pcie.txt    |   73 +
 .../devicetree/bindings/pci/mvebu-pci.txt          |  221 ++
 Documentation/devicetree/bindings/pci/pci.txt      |    9 +
 .../devicetree/bindings/pci/v3-v360epc-pci.txt     |   15 +
 Documentation/devicetree/bindings/rtc/dw-apb.txt   |   19 +
 .../bindings/timer/stericsson-u300-apptimer.txt    |   18 +
 .../devicetree/bindings/vendor-prefixes.txt        |    1 +
 .../bindings/watchdog/stericsson-coh901327.txt     |   19 +
 arch/arm/Kconfig                                   |   64 +-
 arch/arm/Kconfig-nommu                             |    2 +-
 arch/arm/Kconfig.debug                             |  101 +-
 arch/arm/Makefile                                  |    4 +
 arch/arm/boot/compressed/head-shmobile.S           |   21 +-
 arch/arm/boot/dts/Makefile                         |    3 +
 arch/arm/boot/dts/exynos5440-ssdk5440.dts          |    8 +
 arch/arm/boot/dts/exynos5440.dtsi                  |   40 +-
 arch/arm/boot/dts/integratorap.dts                 |   41 +
 arch/arm/boot/dts/keystone.dts                     |  117 +
 arch/arm/boot/dts/kirkwood-6281.dtsi               |   31 +
 arch/arm/boot/dts/kirkwood-6282.dtsi               |   48 +
 arch/arm/boot/dts/kirkwood-db-88f6281.dts          |   30 +
 arch/arm/boot/dts/kirkwood-db-88f6282.dts          |   34 +
 arch/arm/boot/dts/kirkwood-db.dtsi                 |   89 +
 arch/arm/boot/dts/kirkwood-iconnect.dts            |    8 +
 arch/arm/boot/dts/kirkwood-mplcec4.dts             |    8 +
 .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  |    8 +
 arch/arm/boot/dts/kirkwood-nsa310.dts              |    8 +
 arch/arm/boot/dts/kirkwood-ts219-6281.dts          |    3 +-
 arch/arm/boot/dts/kirkwood-ts219-6282.dts          |    3 +-
 arch/arm/boot/dts/kirkwood-ts219.dtsi              |    9 +-
 arch/arm/boot/dts/kirkwood.dtsi                    |    1 +
 arch/arm/boot/dts/rk3066a-clocks.dtsi              |  299 ++
 arch/arm/boot/dts/rk3066a.dtsi                     |  390 ++
 arch/arm/boot/dts/ste-u300.dts                     |  473 +++
 arch/arm/boot/dts/zynq-7000.dtsi                   |   71 +-
 arch/arm/boot/dts/zynq-zc702.dts                   |    4 -
 arch/arm/common/Kconfig                            |    3 +
 arch/arm/common/Makefile                           |    1 +
 arch/arm/{mach-davinci/dma.c => common/edma.c}     |  368 +-
 arch/arm/configs/ap4evb_defconfig                  |   56 -
 arch/arm/configs/bonito_defconfig                  |   72 -
 arch/arm/configs/clps711x_defconfig                |    8 +-
 arch/arm/configs/exynos_defconfig                  |    3 +
 arch/arm/configs/imx_v6_v7_defconfig               |   10 +
 arch/arm/configs/keystone_defconfig                |  157 +
 arch/arm/configs/kirkwood_defconfig                |   10 +-
 arch/arm/configs/multi_v7_defconfig                |    2 +
 arch/arm/configs/mvebu_defconfig                   |    6 +-
 arch/arm/configs/u300_defconfig                    |   14 +-
 arch/arm/include/asm/assembler.h                   |   17 +-
 arch/arm/include/asm/cp15.h                        |   14 +
 arch/arm/include/asm/cputype.h                     |   44 +-
 arch/arm/include/asm/glue-cache.h                  |   27 +
 arch/arm/include/asm/glue-df.h                     |    8 +
 arch/arm/include/asm/glue-proc.h                   |    9 +
 arch/arm/include/asm/hardware/pci_v3.h             |  186 -
 arch/arm/include/asm/irqflags.h                    |   22 +-
 arch/arm/include/asm/mach/arch.h                   |    5 +
 arch/arm/include/asm/mach/pci.h                    |   17 +-
 arch/arm/include/asm/psci.h                        |    9 +
 arch/arm/include/asm/ptrace.h                      |    4 +
 arch/arm/include/asm/system_info.h                 |    1 +
 arch/arm/include/asm/v7m.h                         |   44 +
 arch/arm/include/debug/imx-uart.h                  |   10 +
 arch/arm/include/debug/keystone.S                  |   43 +
 arch/arm/include/debug/mvebu.S                     |    5 +
 arch/arm/include/debug/rockchip.S                  |   42 +
 .../mach/debug-macro.S => include/debug/u300.S}    |    9 +-
 arch/arm/include/uapi/asm/ptrace.h                 |   35 +-
 arch/arm/kernel/Makefile                           |   13 +-
 arch/arm/kernel/bios32.c                           |    9 +-
 arch/arm/kernel/entry-common.S                     |    4 +
 arch/arm/kernel/entry-header.S                     |  124 +
 arch/arm/kernel/entry-v7m.S                        |  143 +
 arch/arm/kernel/head-nommu.S                       |   10 +-
 arch/arm/kernel/psci.c                             |    7 +-
 arch/arm/kernel/psci_smp.c                         |   84 +
 arch/arm/kernel/setup.c                            |   26 +-
 arch/arm/kernel/traps.c                            |    8 +
 arch/arm/mach-clps711x/Kconfig                     |    3 +-
 arch/arm/mach-clps711x/Makefile                    |    5 +-
 arch/arm/mach-clps711x/board-autcpu12.c            |  133 +-
 arch/arm/mach-clps711x/board-cdb89712.c            |    3 +
 arch/arm/mach-clps711x/board-clep7312.c            |    1 +
 arch/arm/mach-clps711x/board-edb7211.c             |   34 +-
 arch/arm/mach-clps711x/board-fortunet.c            |    1 +
 arch/arm/mach-clps711x/board-p720t.c               |  254 +-
 arch/arm/mach-clps711x/common.c                    |   89 +-
 arch/arm/mach-clps711x/common.h                    |    1 +
 arch/arm/mach-clps711x/devices.c                   |   68 +
 arch/arm/mach-clps711x/devices.h                   |   12 +
 arch/arm/mach-clps711x/include/mach/autcpu12.h     |   59 -
 arch/arm/mach-clps711x/include/mach/clps711x.h     |   88 +-
 arch/arm/mach-clps711x/include/mach/hardware.h     |    7 -
 arch/arm/mach-clps711x/include/mach/memory.h       |   41 -
 arch/arm/mach-clps711x/include/mach/syspld.h       |  116 -
 arch/arm/mach-davinci/Makefile                     |    2 +-
 arch/arm/mach-davinci/board-tnetv107x-evm.c        |    2 +-
 arch/arm/mach-davinci/davinci.h                    |   30 +-
 arch/arm/mach-davinci/devices-da8xx.c              |    8 +-
 arch/arm/mach-davinci/devices-tnetv107x.c          |    6 +-
 arch/arm/mach-davinci/devices.c                    |    6 +-
 arch/arm/mach-davinci/dm355.c                      |    6 +-
 arch/arm/mach-davinci/dm365.c                      |    6 +-
 arch/arm/mach-davinci/dm644x.c                     |    6 +-
 arch/arm/mach-davinci/dm646x.c                     |    6 +-
 arch/arm/mach-davinci/include/mach/cp_intc.h       |    4 +-
 arch/arm/mach-davinci/include/mach/da8xx.h         |   18 +-
 arch/arm/mach-davinci/include/mach/tnetv107x.h     |    6 +-
 arch/arm/mach-dove/Kconfig                         |    3 +-
 arch/arm/mach-dove/board-dt.c                      |    3 +-
 arch/arm/mach-dove/common.c                        |    1 -
 arch/arm/mach-exynos/Kconfig                       |  352 +-
 arch/arm/mach-exynos/Makefile                      |   33 -
 arch/arm/mach-exynos/common.c                      |  547 +--
 arch/arm/mach-exynos/common.h                      |    4 +-
 arch/arm/mach-exynos/dev-ahci.c                    |  255 --
 arch/arm/mach-exynos/dev-audio.c                   |  254 --
 arch/arm/mach-exynos/dev-ohci.c                    |   52 -
 arch/arm/mach-exynos/dev-uart.c                    |   55 -
 arch/arm/mach-exynos/dma.c                         |  322 --
 arch/arm/mach-exynos/firmware.c                    |   22 +-
 arch/arm/mach-exynos/include/mach/gpio.h           |  289 --
 arch/arm/mach-exynos/include/mach/irqs.h           |  476 ---
 arch/arm/mach-exynos/include/mach/map.h            |  214 --
 arch/arm/mach-exynos/include/mach/pm-core.h        |   12 +-
 arch/arm/mach-exynos/include/mach/regs-gpio.h      |   40 -
 arch/arm/mach-exynos/include/mach/regs-usb-phy.h   |   74 -
 arch/arm/mach-exynos/mach-armlex4210.c             |  207 --
 arch/arm/mach-exynos/mach-exynos4-dt.c             |    8 +-
 arch/arm/mach-exynos/mach-exynos5-dt.c             |    8 +-
 arch/arm/mach-exynos/mach-nuri.c                   | 1388 -------
 arch/arm/mach-exynos/mach-origen.c                 |  823 -----
 arch/arm/mach-exynos/mach-smdk4x12.c               |  396 --
 arch/arm/mach-exynos/mach-smdkv310.c               |  444 ---
 arch/arm/mach-exynos/mach-universal_c210.c         | 1159 ------
 arch/arm/mach-exynos/platsmp.c                     |    2 +-
 arch/arm/mach-exynos/pm.c                          |    1 -
 arch/arm/mach-exynos/pm_domains.c                  |  101 +-
 arch/arm/mach-exynos/setup-fimc.c                  |   44 -
 arch/arm/mach-exynos/setup-fimd0.c                 |   43 -
 arch/arm/mach-exynos/setup-i2c0.c                  |   29 -
 arch/arm/mach-exynos/setup-i2c1.c                  |   23 -
 arch/arm/mach-exynos/setup-i2c2.c                  |   23 -
 arch/arm/mach-exynos/setup-i2c3.c                  |   23 -
 arch/arm/mach-exynos/setup-i2c4.c                  |   23 -
 arch/arm/mach-exynos/setup-i2c5.c                  |   23 -
 arch/arm/mach-exynos/setup-i2c6.c                  |   23 -
 arch/arm/mach-exynos/setup-i2c7.c                  |   23 -
 arch/arm/mach-exynos/setup-keypad.c                |   36 -
 arch/arm/mach-exynos/setup-sdhci-gpio.c            |  152 -
 arch/arm/mach-exynos/setup-spi.c                   |   45 -
 arch/arm/mach-exynos/setup-usb-phy.c               |  223 --
 arch/arm/mach-imx/Kconfig                          |   65 +-
 arch/arm/mach-imx/Makefile                         |    4 +-
 arch/arm/mach-imx/clk-imx51-imx53.c                |   73 +-
 arch/arm/mach-imx/clk-imx6q.c                      |   48 +-
 arch/arm/mach-imx/clk-imx6sl.c                     |  267 ++
 arch/arm/mach-imx/clk-pllv3.c                      |   10 -
 arch/arm/mach-imx/clk-vf610.c                      |  319 ++
 arch/arm/mach-imx/clk.c                            |   35 +
 arch/arm/mach-imx/clk.h                            |    4 +-
 arch/arm/mach-imx/common.h                         |    2 +-
 arch/arm/mach-imx/hardware.h                       |    1 +
 arch/arm/mach-imx/imx25-dt.c                       |    2 +
 arch/arm/mach-imx/imx27-dt.c                       |    2 +
 arch/arm/mach-imx/imx31-dt.c                       |    2 +
 arch/arm/mach-imx/imx51-dt.c                       |    2 +
 arch/arm/mach-imx/irq-common.c                     |    1 +
 arch/arm/mach-imx/mach-imx53.c                     |    3 +
 arch/arm/mach-imx/mach-imx6q.c                     |   81 +-
 arch/arm/mach-imx/mach-imx6sl.c                    |   52 +
 arch/arm/mach-imx/mach-pca100.c                    |    4 +-
 arch/arm/mach-imx/mach-vf610.c                     |   48 +
 arch/arm/mach-imx/mm-imx1.c                        |    2 +-
 arch/arm/mach-imx/mm-imx21.c                       |    2 +-
 arch/arm/mach-imx/mm-imx25.c                       |    2 +-
 arch/arm/mach-imx/mm-imx27.c                       |    2 +-
 arch/arm/mach-imx/mm-imx3.c                        |    4 +-
 arch/arm/mach-imx/mm-imx5.c                        |    3 +-
 arch/arm/mach-imx/system.c                         |   47 +-
 arch/arm/mach-imx/ulpi.c                           |  118 -
 arch/arm/mach-imx/ulpi.h                           |   11 +-
 arch/arm/mach-integrator/Makefile                  |    2 +-
 arch/arm/mach-integrator/include/mach/platform.h   |   23 -
 arch/arm/mach-integrator/integrator_ap.c           |   31 +-
 arch/arm/mach-integrator/pci.c                     |  113 -
 arch/arm/mach-integrator/pci_v3.c                  |  564 ++-
 arch/arm/mach-integrator/pci_v3.h                  |    2 +
 arch/arm/mach-keystone/Kconfig                     |   15 +
 arch/arm/mach-keystone/Makefile                    |    6 +
 arch/arm/mach-keystone/Makefile.boot               |    1 +
 arch/arm/mach-keystone/keystone.c                  |   75 +
 arch/arm/mach-keystone/keystone.h                  |   23 +
 arch/arm/mach-keystone/platsmp.c                   |   43 +
 arch/arm/mach-keystone/smc.S                       |   29 +
 arch/arm/mach-kirkwood/Kconfig                     |   24 +-
 arch/arm/mach-kirkwood/Makefile                    |    3 +-
 arch/arm/mach-kirkwood/board-db88f628x-bp.c        |   24 +
 arch/arm/mach-kirkwood/board-dt.c                  |   18 +-
 arch/arm/mach-kirkwood/board-iconnect.c            |    8 -
 arch/arm/mach-kirkwood/board-mplcec4.c             |    1 -
 arch/arm/mach-kirkwood/board-nsa310.c              |   25 -
 arch/arm/mach-kirkwood/board-readynas.c            |    1 -
 arch/arm/mach-kirkwood/common.c                    |   47 +-
 arch/arm/mach-kirkwood/common.h                    |    8 +
 arch/arm/mach-kirkwood/db88f6281-bp-setup.c        |  108 -
 arch/arm/mach-kirkwood/include/mach/bridge-regs.h  |    2 +
 arch/arm/mach-kirkwood/pcie.c                      |   22 +
 arch/arm/mach-mvebu/Kconfig                        |    7 +-
 arch/arm/mach-mvebu/armada-370-xp.c                |   53 +-
 arch/arm/mach-mvebu/armada-370-xp.h                |   10 -
 arch/arm/mach-mvebu/coherency.c                    |   45 +-
 arch/arm/mach-mvebu/coherency.h                    |    4 -
 arch/arm/mach-mvebu/common.h                       |    2 +
 arch/arm/mach-mvebu/headsmp.S                      |   16 +-
 arch/arm/mach-mvebu/platsmp.c                      |   10 +-
 arch/arm/mach-omap2/Kconfig                        |    9 +
 arch/arm/mach-omap2/Makefile                       |   19 +-
 arch/arm/mach-omap2/am33xx.h                       |    1 +
 arch/arm/mach-omap2/board-generic.c                |   16 +
 arch/arm/mach-omap2/cclock33xx_data.c              |   30 +
 arch/arm/mach-omap2/cclock3xxx_data.c              |   11 -
 arch/arm/mach-omap2/clockdomain.h                  |    1 +
 arch/arm/mach-omap2/clockdomains54xx_data.c        |  464 +++
 arch/arm/mach-omap2/cm-regbits-54xx.h              | 1737 +++++++++
 arch/arm/mach-omap2/cm1_44xx.h                     |    7 +-
 arch/arm/mach-omap2/cm1_54xx.h                     |  213 ++
 arch/arm/mach-omap2/cm2_44xx.h                     |    7 +-
 arch/arm/mach-omap2/cm2_54xx.h                     |  389 ++
 arch/arm/mach-omap2/cm33xx.h                       |    2 +-
 arch/arm/mach-omap2/cm_44xx_54xx.h                 |   36 +
 arch/arm/mach-omap2/common.h                       |    5 +-
 arch/arm/mach-omap2/control.h                      |   12 +
 arch/arm/mach-omap2/id.c                           |   32 +-
 arch/arm/mach-omap2/io.c                           |   25 +-
 arch/arm/mach-omap2/omap-headsmp.S                 |    8 +-
 arch/arm/mach-omap2/omap-mpuss-lowpower.c          |   69 +-
 arch/arm/mach-omap2/omap-smp.c                     |    6 +-
 arch/arm/mach-omap2/omap4-common.c                 |   16 -
 arch/arm/mach-omap2/omap4-restart.c                |   27 +
 arch/arm/mach-omap2/omap_hwmod.h                   |    1 +
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    3 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         | 2150 +++++++++++
 arch/arm/mach-omap2/pm44xx.c                       |   58 +-
 arch/arm/mach-omap2/powerdomain.h                  |    1 +
 arch/arm/mach-omap2/powerdomains3xxx_data.c        |   62 +
 arch/arm/mach-omap2/powerdomains54xx_data.c        |  331 ++
 arch/arm/mach-omap2/prcm-common.h                  |   11 +
 arch/arm/mach-omap2/prcm44xx.h                     |    6 +
 arch/arm/mach-omap2/prcm_mpu44xx.h                 |   14 +-
 arch/arm/mach-omap2/prcm_mpu54xx.h                 |   87 +
 arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h           |   36 +
 arch/arm/mach-omap2/prm-regbits-54xx.h             | 2701 ++++++++++++++
 arch/arm/mach-omap2/prm44xx.h                      |   33 +-
 arch/arm/mach-omap2/prm44xx_54xx.h                 |   58 +
 arch/arm/mach-omap2/prm54xx.h                      |  421 +++
 arch/arm/mach-omap2/scrm54xx.h                     |  231 ++
 arch/arm/mach-omap2/soc.h                          |   26 +
 arch/arm/mach-omap2/sram.c                         |    3 +
 arch/arm/mach-omap2/timer.c                        |    2 +-
 arch/arm/mach-omap2/voltage.h                      |    1 +
 arch/arm/mach-omap2/voltagedomains54xx_data.c      |   92 +
 arch/arm/mach-picoxcell/Kconfig                    |    1 -
 arch/arm/mach-picoxcell/common.c                   |    2 -
 arch/arm/mach-rockchip/Kconfig                     |   16 +
 arch/arm/mach-rockchip/Makefile                    |    1 +
 arch/arm/mach-rockchip/rockchip.c                  |   52 +
 arch/arm/mach-s3c24xx/dma-s3c2412.c                |   56 +-
 arch/arm/mach-s3c24xx/dma-s3c2443.c                |    3 +-
 arch/arm/mach-s3c24xx/dma.c                        |    3 -
 arch/arm/mach-shmobile/Kconfig                     |   65 +-
 arch/arm/mach-shmobile/Makefile                    |    2 -
 arch/arm/mach-shmobile/Makefile.boot               |   18 +-
 arch/arm/mach-shmobile/board-ap4evb.c              | 1332 -------
 arch/arm/mach-shmobile/board-armadillo800eva.c     |  116 +-
 arch/arm/mach-shmobile/board-bockw.c               |   21 +
 arch/arm/mach-shmobile/board-bonito.c              |  495 ---
 arch/arm/mach-shmobile/board-kzm9g-reference.c     |    1 -
 arch/arm/mach-shmobile/board-kzm9g.c               |   11 +-
 arch/arm/mach-shmobile/board-lager.c               |   15 +
 arch/arm/mach-shmobile/board-mackerel.c            |  171 +-
 arch/arm/mach-shmobile/board-marzen.c              |  188 +-
 arch/arm/mach-shmobile/clock-r8a73a4.c             |  387 +-
 arch/arm/mach-shmobile/clock-r8a7740.c             |   11 +-
 arch/arm/mach-shmobile/clock-r8a7778.c             |  183 +-
 arch/arm/mach-shmobile/clock-r8a7779.c             |    4 +-
 arch/arm/mach-shmobile/clock-r8a7790.c             |  255 +-
 arch/arm/mach-shmobile/clock-sh73a0.c              |  111 +-
 arch/arm/mach-shmobile/headsmp-scu.S               |   29 +-
 arch/arm/mach-shmobile/headsmp.S                   |   13 +-
 arch/arm/mach-shmobile/include/mach/clock.h        |    8 +-
 arch/arm/mach-shmobile/include/mach/common.h       |    6 +-
 .../arm/mach-shmobile/include/mach/head-ap4evb.txt |   93 -
 arch/arm/mach-shmobile/include/mach/irqs.h         |    5 +
 arch/arm/mach-shmobile/include/mach/memory.h       |    7 -
 arch/arm/mach-shmobile/include/mach/mmc-ap4eb.h    |   29 -
 arch/arm/mach-shmobile/include/mach/mmc.h          |    4 +-
 arch/arm/mach-shmobile/include/mach/r8a7740.h      |  488 ---
 arch/arm/mach-shmobile/include/mach/r8a7778.h      |   11 +
 arch/arm/mach-shmobile/include/mach/r8a7779.h      |    3 +
 arch/arm/mach-shmobile/include/mach/sh7372.h       |  393 +-
 arch/arm/mach-shmobile/include/mach/zboot.h        |    6 +-
 arch/arm/mach-shmobile/pm-sh7372.c                 |    3 +
 arch/arm/mach-shmobile/setup-r8a7740.c             |   24 +-
 arch/arm/mach-shmobile/setup-r8a7778.c             |  262 +-
 arch/arm/mach-shmobile/setup-r8a7779.c             |  215 +-
 arch/arm/mach-shmobile/setup-r8a7790.c             |   36 +-
 arch/arm/mach-shmobile/setup-sh73a0.c              |   95 +-
 arch/arm/mach-shmobile/sleep-sh7372.S              |    5 +-
 arch/arm/mach-shmobile/smp-emev2.c                 |    6 +-
 arch/arm/mach-shmobile/smp-r8a7779.c               |    6 +-
 arch/arm/mach-shmobile/smp-sh73a0.c                |    6 +-
 arch/arm/mach-socfpga/Kconfig                      |    2 +-
 arch/arm/mach-socfpga/socfpga.c                    |    2 -
 arch/arm/mach-sunxi/sunxi.c                        |    1 +
 arch/arm/mach-tegra/Makefile                       |    1 +
 arch/arm/mach-tegra/common.c                       |    2 +
 arch/arm/mach-tegra/common.h                       |    1 +
 arch/arm/mach-tegra/cpuidle-tegra20.c              |   10 +-
 arch/arm/mach-tegra/cpuidle-tegra30.c              |   10 +-
 arch/arm/mach-tegra/cpuidle.c                      |   19 +-
 arch/arm/mach-tegra/cpuidle.h                      |   15 +-
 arch/arm/mach-tegra/flowctrl.h                     |    1 +
 arch/arm/mach-tegra/fuse.h                         |   22 +-
 arch/arm/mach-tegra/hotplug.c                      |   13 +
 arch/arm/mach-tegra/platsmp.c                      |   26 +-
 arch/arm/mach-tegra/pm.c                           |   25 +-
 arch/arm/mach-tegra/pm.h                           |    4 +-
 arch/arm/mach-tegra/reset-handler.S                |   51 +-
 arch/arm/mach-tegra/sleep-tegra30.S                |   30 +-
 arch/arm/mach-tegra/sleep.S                        |    8 +-
 arch/arm/mach-tegra/sleep.h                        |   35 +-
 arch/arm/mach-tegra/tegra2_emc.c                   |    2 +-
 arch/arm/mach-u300/Kconfig                         |   32 +-
 arch/arm/mach-u300/Makefile                        |    2 -
 arch/arm/mach-u300/core.c                          |  759 ++--
 arch/arm/mach-u300/dummyspichip.c                  |   20 +-
 arch/arm/mach-u300/i2c.c                           |  285 --
 arch/arm/mach-u300/i2c.h                           |   23 -
 arch/arm/mach-u300/include/mach/hardware.h         |    5 -
 arch/arm/mach-u300/include/mach/irqs.h             |   80 -
 arch/arm/mach-u300/include/mach/syscon.h           |  592 ---
 arch/arm/mach-u300/include/mach/timex.h            |   17 -
 arch/arm/mach-u300/include/mach/u300-regs.h        |  165 -
 arch/arm/mach-u300/include/mach/uncompress.h       |   45 -
 arch/arm/mach-u300/regulator.c                     |   67 +-
 arch/arm/mach-u300/spi.c                           |  102 -
 arch/arm/mach-u300/spi.h                           |   26 -
 arch/arm/mach-u300/timer.c                         |  113 +-
 arch/arm/mach-u300/timer.h                         |    1 -
 arch/arm/mach-u300/u300-gpio.h                     |   70 -
 arch/arm/mach-vexpress/Kconfig                     |    9 +
 arch/arm/mach-vexpress/Makefile                    |    1 +
 arch/arm/mach-vexpress/core.h                      |    2 +
 arch/arm/mach-vexpress/dcscb.c                     |  253 ++
 arch/arm/mach-vexpress/dcscb_setup.S               |   38 +
 arch/arm/mach-vexpress/platsmp.c                   |   20 +
 arch/arm/mach-vexpress/v2m.c                       |    1 +
 arch/arm/mach-virt/Makefile                        |    1 -
 arch/arm/mach-virt/platsmp.c                       |   50 -
 arch/arm/mach-virt/virt.c                          |    3 -
 arch/arm/mach-zynq/slcr.c                          |    2 +-
 arch/arm/mm/Kconfig                                |   21 +-
 arch/arm/mm/Makefile                               |    2 +
 arch/arm/mm/cache-nop.S                            |   50 +
 arch/arm/mm/nommu.c                                |    7 +
 arch/arm/mm/proc-v7m.S                             |  157 +
 arch/arm/plat-samsung/Kconfig                      |   47 +-
 arch/arm/plat-samsung/Makefile                     |   11 +-
 arch/arm/plat-samsung/include/plat/dma-s3c24xx.h   |    5 -
 arch/arm/plat-samsung/include/plat/pm.h            |    5 +
 arch/arm/plat-samsung/init.c                       |    8 +-
 arch/arm/plat-samsung/pm-gpio.c                    |    5 +-
 arch/arm/plat-samsung/pm.c                         |    8 +-
 arch/arm/plat-samsung/s5p-dev-mfc.c                |   11 +-
 drivers/bus/Kconfig                                |    7 +
 drivers/bus/Makefile                               |    2 +
 drivers/bus/arm-cci.c                              |  533 +++
 drivers/clk/Makefile                               |    2 +-
 drivers/clk/clk-u300.c                             |  718 +++-
 drivers/clk/clk-zynq.c                             |  378 --
 drivers/clk/mvebu/Kconfig                          |   25 +-
 drivers/clk/mvebu/Makefile                         |    8 +-
 drivers/clk/mvebu/armada-370.c                     |  176 +
 drivers/clk/mvebu/armada-xp.c                      |  210 ++
 drivers/clk/mvebu/clk-core.c                       |  675 ----
 drivers/clk/mvebu/clk-core.h                       |   18 -
 drivers/clk/mvebu/clk-gating-ctrl.c                |  250 --
 drivers/clk/mvebu/clk-gating-ctrl.h                |   22 -
 drivers/clk/mvebu/clk.c                            |   23 -
 drivers/clk/mvebu/common.c                         |  163 +
 drivers/clk/mvebu/common.h                         |   48 +
 drivers/clk/mvebu/dove.c                           |  194 +
 drivers/clk/mvebu/kirkwood.c                       |  247 ++
 drivers/clk/socfpga/clk.c                          |  194 +-
 drivers/clk/tegra/clk-tegra114.c                   |   23 +-
 drivers/clk/zynq/Makefile                          |    3 +
 drivers/clk/zynq/clkc.c                            |  533 +++
 drivers/clk/zynq/pll.c                             |  235 ++
 drivers/clocksource/Kconfig                        |    2 +
 drivers/clocksource/cadence_ttc_timer.c            |   23 +-
 drivers/clocksource/dw_apb_timer_of.c              |   95 +-
 drivers/cpuidle/cpuidle-calxeda.c                  |   14 -
 drivers/dma/Kconfig                                |    2 +-
 drivers/dma/coh901318.c                            |   43 +
 drivers/dma/edma.c                                 |    2 +-
 drivers/gpio/Kconfig                               |   12 +-
 drivers/gpio/Makefile                              |    2 +-
 drivers/gpio/gpio-clps711x.c                       |  236 +-
 drivers/gpio/gpio-rcar.c                           |   28 +-
 drivers/i2c/busses/i2c-stu300.c                    |   16 +-
 drivers/media/platform/Kconfig                     |    6 +-
 drivers/media/platform/exynos4-is/Kconfig          |    3 +-
 drivers/media/platform/s5p-tv/Kconfig              |    2 +-
 drivers/mfd/syscon.c                               |    3 +
 drivers/mmc/host/davinci_mmc.c                     |    1 +
 drivers/mtd/maps/Kconfig                           |    7 -
 drivers/mtd/maps/Makefile                          |    1 -
 drivers/mtd/maps/autcpu12-nvram.c                  |  129 -
 drivers/pci/Kconfig                                |    2 +
 drivers/pci/Makefile                               |    3 +
 drivers/pci/host/Kconfig                           |   17 +
 drivers/pci/host/Makefile                          |    2 +
 drivers/pci/host/pci-mvebu.c                       |  914 +++++
 drivers/pci/host/pcie-designware.c                 | 1057 ++++++
 drivers/pinctrl/Kconfig                            |    5 +-
 drivers/pinctrl/pinctrl-coh901.c                   |   35 +-
 drivers/pinctrl/pinctrl-u300.c                     |    7 +
 drivers/pinctrl/sh-pfc/Kconfig                     |   13 +-
 drivers/pinctrl/sh-pfc/Makefile                    |    2 +
 drivers/pinctrl/sh-pfc/core.c                      |   22 +-
 drivers/pinctrl/sh-pfc/core.h                      |    4 +
 drivers/pinctrl/sh-pfc/pfc-r8a7740.c               | 1923 +++++++---
 drivers/pinctrl/sh-pfc/pfc-r8a7778.c               | 2783 ++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c               |  493 ++-
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c               | 3835 ++++++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-sh7372.c                | 1652 ++++++---
 drivers/pinctrl/sh-pfc/pfc-sh73a0.c                |  742 ++--
 drivers/pinctrl/sh-pfc/sh_pfc.h                    |    4 +-
 drivers/rtc/rtc-coh901331.c                        |    6 +
 drivers/spi/spi-pl022.c                            |    1 +
 drivers/thermal/exynos_thermal.c                   |    3 +-
 drivers/tty/serial/xilinx_uartps.c                 |   85 +-
 drivers/usb/Kconfig                                |    1 +
 drivers/usb/host/Kconfig                           |    2 +-
 drivers/usb/host/ehci-platform.c                   |    6 +
 drivers/usb/phy/Kconfig                            |   10 +-
 drivers/usb/phy/phy-rcar-usb.c                     |  128 +-
 drivers/watchdog/coh901327_wdt.c                   |   12 +-
 include/dt-bindings/clock/imx6sl-clock.h           |  148 +
 include/dt-bindings/clock/vf610-clock.h            |  163 +
 include/linux/arm-cci.h                            |   61 +
 include/linux/clk/mvebu.h                          |   22 -
 include/linux/clk/zynq.h                           |    8 +-
 include/linux/dw_apb_timer.h                       |    1 -
 include/linux/mfd/davinci_voicecodec.h             |    3 +-
 include/linux/mfd/syscon/clps711x.h                |   94 +
 .../mach => include/linux/platform_data}/edma.h    |   94 +-
 include/linux/platform_data/gpio-rcar.h            |    5 +-
 include/linux/platform_data/pinctrl-coh901.h       |   22 -
 include/linux/platform_data/spi-davinci.h          |    2 +-
 include/linux/platform_data/usb-rcar-phy.h         |   28 +
 include/linux/usb/ehci_pdriver.h                   |    4 +
 sound/soc/davinci/davinci-evm.c                    |    1 +
 sound/soc/davinci/davinci-pcm.c                    |    1 +
 sound/soc/davinci/davinci-pcm.h                    |    2 +-
 483 files changed, 34845 insertions(+), 19523 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/cci.txt
 create mode 100644 Documentation/devicetree/bindings/arm/keystone/keystone.txt
 create mode 100644 Documentation/devicetree/bindings/arm/rtsm-dcscb.txt
 create mode 100644 Documentation/devicetree/bindings/arm/ste-u300.txt
 create mode 100644 Documentation/devicetree/bindings/clock/imx6sl-clock.txt
 create mode 100644 Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt
 create mode 100644 Documentation/devicetree/bindings/clock/vf610-clock.txt
 create mode 100644 Documentation/devicetree/bindings/dma/ste-coh901318.txt
 create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-clps711x.txt
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt
 create mode 100644 Documentation/devicetree/bindings/pci/designware-pcie.txt
 create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt
 create mode 100644 Documentation/devicetree/bindings/pci/pci.txt
 create mode 100644 Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt
 create mode 100644 Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt
 create mode 100644 arch/arm/boot/dts/keystone.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6281.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6282.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-db.dtsi
 create mode 100644 arch/arm/boot/dts/rk3066a-clocks.dtsi
 create mode 100644 arch/arm/boot/dts/rk3066a.dtsi
 create mode 100644 arch/arm/boot/dts/ste-u300.dts
 rename arch/arm/{mach-davinci/dma.c => common/edma.c} (86%)
 delete mode 100644 arch/arm/configs/ap4evb_defconfig
 delete mode 100644 arch/arm/configs/bonito_defconfig
 create mode 100644 arch/arm/configs/keystone_defconfig
 delete mode 100644 arch/arm/include/asm/hardware/pci_v3.h
 create mode 100644 arch/arm/include/asm/v7m.h
 create mode 100644 arch/arm/include/debug/keystone.S
 create mode 100644 arch/arm/include/debug/rockchip.S
 rename arch/arm/{mach-u300/include/mach/debug-macro.S => include/debug/u300.S} (78%)
 create mode 100644 arch/arm/kernel/entry-v7m.S
 create mode 100644 arch/arm/kernel/psci_smp.c
 create mode 100644 arch/arm/mach-clps711x/devices.c
 create mode 100644 arch/arm/mach-clps711x/devices.h
 delete mode 100644 arch/arm/mach-clps711x/include/mach/autcpu12.h
 delete mode 100644 arch/arm/mach-clps711x/include/mach/memory.h
 delete mode 100644 arch/arm/mach-clps711x/include/mach/syspld.h
 delete mode 100644 arch/arm/mach-exynos/dev-ahci.c
 delete mode 100644 arch/arm/mach-exynos/dev-audio.c
 delete mode 100644 arch/arm/mach-exynos/dev-ohci.c
 delete mode 100644 arch/arm/mach-exynos/dev-uart.c
 delete mode 100644 arch/arm/mach-exynos/dma.c
 delete mode 100644 arch/arm/mach-exynos/include/mach/gpio.h
 delete mode 100644 arch/arm/mach-exynos/include/mach/irqs.h
 delete mode 100644 arch/arm/mach-exynos/include/mach/regs-gpio.h
 delete mode 100644 arch/arm/mach-exynos/include/mach/regs-usb-phy.h
 delete mode 100644 arch/arm/mach-exynos/mach-armlex4210.c
 delete mode 100644 arch/arm/mach-exynos/mach-nuri.c
 delete mode 100644 arch/arm/mach-exynos/mach-origen.c
 delete mode 100644 arch/arm/mach-exynos/mach-smdk4x12.c
 delete mode 100644 arch/arm/mach-exynos/mach-smdkv310.c
 delete mode 100644 arch/arm/mach-exynos/mach-universal_c210.c
 delete mode 100644 arch/arm/mach-exynos/setup-fimc.c
 delete mode 100644 arch/arm/mach-exynos/setup-fimd0.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c0.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c1.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c2.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c3.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c4.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c5.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c6.c
 delete mode 100644 arch/arm/mach-exynos/setup-i2c7.c
 delete mode 100644 arch/arm/mach-exynos/setup-keypad.c
 delete mode 100644 arch/arm/mach-exynos/setup-sdhci-gpio.c
 delete mode 100644 arch/arm/mach-exynos/setup-spi.c
 delete mode 100644 arch/arm/mach-exynos/setup-usb-phy.c
 create mode 100644 arch/arm/mach-imx/clk-imx6sl.c
 create mode 100644 arch/arm/mach-imx/clk-vf610.c
 create mode 100644 arch/arm/mach-imx/mach-imx6sl.c
 create mode 100644 arch/arm/mach-imx/mach-vf610.c
 delete mode 100644 arch/arm/mach-imx/ulpi.c
 delete mode 100644 arch/arm/mach-integrator/pci.c
 create mode 100644 arch/arm/mach-integrator/pci_v3.h
 create mode 100644 arch/arm/mach-keystone/Kconfig
 create mode 100644 arch/arm/mach-keystone/Makefile
 create mode 100644 arch/arm/mach-keystone/Makefile.boot
 create mode 100644 arch/arm/mach-keystone/keystone.c
 create mode 100644 arch/arm/mach-keystone/keystone.h
 create mode 100644 arch/arm/mach-keystone/platsmp.c
 create mode 100644 arch/arm/mach-keystone/smc.S
 create mode 100644 arch/arm/mach-kirkwood/board-db88f628x-bp.c
 delete mode 100644 arch/arm/mach-kirkwood/board-nsa310.c
 delete mode 100644 arch/arm/mach-kirkwood/db88f6281-bp-setup.c
 create mode 100644 arch/arm/mach-omap2/clockdomains54xx_data.c
 create mode 100644 arch/arm/mach-omap2/cm-regbits-54xx.h
 create mode 100644 arch/arm/mach-omap2/cm1_54xx.h
 create mode 100644 arch/arm/mach-omap2/cm2_54xx.h
 create mode 100644 arch/arm/mach-omap2/cm_44xx_54xx.h
 create mode 100644 arch/arm/mach-omap2/omap4-restart.c
 create mode 100644 arch/arm/mach-omap2/omap_hwmod_54xx_data.c
 create mode 100644 arch/arm/mach-omap2/powerdomains54xx_data.c
 create mode 100644 arch/arm/mach-omap2/prcm_mpu54xx.h
 create mode 100644 arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h
 create mode 100644 arch/arm/mach-omap2/prm-regbits-54xx.h
 create mode 100644 arch/arm/mach-omap2/prm44xx_54xx.h
 create mode 100644 arch/arm/mach-omap2/prm54xx.h
 create mode 100644 arch/arm/mach-omap2/scrm54xx.h
 create mode 100644 arch/arm/mach-omap2/voltagedomains54xx_data.c
 create mode 100644 arch/arm/mach-rockchip/Kconfig
 create mode 100644 arch/arm/mach-rockchip/Makefile
 create mode 100644 arch/arm/mach-rockchip/rockchip.c
 delete mode 100644 arch/arm/mach-shmobile/board-ap4evb.c
 delete mode 100644 arch/arm/mach-shmobile/board-bonito.c
 delete mode 100644 arch/arm/mach-shmobile/include/mach/head-ap4evb.txt
 delete mode 100644 arch/arm/mach-shmobile/include/mach/memory.h
 delete mode 100644 arch/arm/mach-shmobile/include/mach/mmc-ap4eb.h
 delete mode 100644 arch/arm/mach-u300/i2c.c
 delete mode 100644 arch/arm/mach-u300/i2c.h
 delete mode 100644 arch/arm/mach-u300/include/mach/hardware.h
 delete mode 100644 arch/arm/mach-u300/include/mach/irqs.h
 delete mode 100644 arch/arm/mach-u300/include/mach/syscon.h
 delete mode 100644 arch/arm/mach-u300/include/mach/timex.h
 delete mode 100644 arch/arm/mach-u300/include/mach/u300-regs.h
 delete mode 100644 arch/arm/mach-u300/include/mach/uncompress.h
 delete mode 100644 arch/arm/mach-u300/spi.c
 delete mode 100644 arch/arm/mach-u300/spi.h
 delete mode 100644 arch/arm/mach-u300/timer.h
 delete mode 100644 arch/arm/mach-u300/u300-gpio.h
 create mode 100644 arch/arm/mach-vexpress/dcscb.c
 create mode 100644 arch/arm/mach-vexpress/dcscb_setup.S
 delete mode 100644 arch/arm/mach-virt/platsmp.c
 create mode 100644 arch/arm/mm/cache-nop.S
 create mode 100644 arch/arm/mm/proc-v7m.S
 create mode 100644 drivers/bus/arm-cci.c
 delete mode 100644 drivers/clk/clk-zynq.c
 create mode 100644 drivers/clk/mvebu/armada-370.c
 create mode 100644 drivers/clk/mvebu/armada-xp.c
 delete mode 100644 drivers/clk/mvebu/clk-core.c
 delete mode 100644 drivers/clk/mvebu/clk-core.h
 delete mode 100644 drivers/clk/mvebu/clk-gating-ctrl.c
 delete mode 100644 drivers/clk/mvebu/clk-gating-ctrl.h
 delete mode 100644 drivers/clk/mvebu/clk.c
 create mode 100644 drivers/clk/mvebu/common.c
 create mode 100644 drivers/clk/mvebu/common.h
 create mode 100644 drivers/clk/mvebu/dove.c
 create mode 100644 drivers/clk/mvebu/kirkwood.c
 create mode 100644 drivers/clk/zynq/Makefile
 create mode 100644 drivers/clk/zynq/clkc.c
 create mode 100644 drivers/clk/zynq/pll.c
 delete mode 100644 drivers/mtd/maps/autcpu12-nvram.c
 create mode 100644 drivers/pci/host/Kconfig
 create mode 100644 drivers/pci/host/Makefile
 create mode 100644 drivers/pci/host/pci-mvebu.c
 create mode 100644 drivers/pci/host/pcie-designware.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a7778.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a7790.c
 create mode 100644 include/dt-bindings/clock/imx6sl-clock.h
 create mode 100644 include/dt-bindings/clock/vf610-clock.h
 create mode 100644 include/linux/arm-cci.h
 delete mode 100644 include/linux/clk/mvebu.h
 create mode 100644 include/linux/mfd/syscon/clps711x.h
 rename {arch/arm/mach-davinci/include/mach => include/linux/platform_data}/edma.h (58%)
 delete mode 100644 include/linux/platform_data/pinctrl-coh901.h
 create mode 100644 include/linux/platform_data/usb-rcar-phy.h


From jgunthorpe at obsidianresearch.com  Tue Jul  2 15:55:24 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Tue, 2 Jul 2013 13:55:24 -0600
Subject: [PATCH v5 00/12] MBus DT binding: A new hope
In-Reply-To: <1372532655-20321-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1372532655-20321-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130702195524.GA14547@obsidianresearch.com>

On Sat, Jun 29, 2013 at 04:04:03PM -0300, Ezequiel Garcia wrote:

> In the current proposal we have now required a 'controller' property
> to specify the MBus controller MMIO registers. To us this looks more
> appropriate, since the MBus registers are effectively located within
> the internal register region, behind the so-called internal-regs window.

Interesting, seems reasonable to me.

> Personally, I can't see any disadvantage, and the binding looks much
> cleaner now. But of course I can be wrong, and I'm open to discussion.
> 
> There's another pending issue. Arnd Bergmann has required to add a
> property to specify the available space within the CPU address space
> for decoding windows. This property would allow to support fully
> dynamic mbus window allocation.

I wonder if this range is implied - eg it is address space not covered
by the memory node or any mbus ranges? Is there a situation where that
is not sufficient?

> For now, this property is intentionally missing, and I expect that
> it can be added in the future, together with the full-dynamic MBus
> implementation.
> 
> @Arnd, @Jason: Given the v4 patchset didn't receive any comments but
> wasn't accepted either, I'd like to know which other pending issues
> I'm forgetting to address.

I took a quick look and it seems to match what was discussed..

Regards,
Jason


From coelho at ti.com  Tue Jul  2 16:12:12 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 23:12:12 +0300
Subject: [PATCH v2 2/9] wlcore: use irq_flags in pdata instead of hiding
 it behind a quirk
In-Reply-To: <20130702152657.GE7013@arwen.pp.htv.fi>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-3-git-send-email-coelho@ti.com>
 <20130702152657.GE7013@arwen.pp.htv.fi>
Message-ID: <1372795932.21065.84.camel@cumari.coelho.fi>

On Tue, 2013-07-02 at 18:26 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 02, 2013 at 05:55:41PM +0300, Luciano Coelho wrote:
> > The platform_quirk element in the platform data was used to change the
> > way the IRQ is triggered.  When set, the EDGE_IRQ quirk would change
> > the irqflags used and treat edge trigger differently from the rest.
> > 
> > Instead of hiding this irq flag setting behind the quirk, export the
> > whole irq_flags element and let the board file define what to use.
> > This will be more meaningful than driver-specific quirks when we
> > switch to DT.
> > 
> > Cc: Tony Lindgren <tony at atomide.com>
> > Cc: Sekhar Nori <nsekhar at ti.com>
> > Signed-off-by: Luciano Coelho <coelho at ti.com>
> > Acked-by: Tony Lindgren <tony at atomide.com>
> > ---
> >  arch/arm/mach-davinci/board-da850-evm.c      |    2 +-
> >  arch/arm/mach-omap2/board-4430sdp.c          |    1 +
> >  arch/arm/mach-omap2/board-omap3evm.c         |    1 +
> >  arch/arm/mach-omap2/board-omap4panda.c       |    1 +
> >  arch/arm/mach-omap2/board-zoom-peripherals.c |    1 +
> >  drivers/net/wireless/ti/wlcore/debugfs.c     |    2 +-
> >  drivers/net/wireless/ti/wlcore/main.c        |   13 +++----------
> >  drivers/net/wireless/ti/wlcore/wlcore.h      |    5 ++---
> >  include/linux/wl12xx.h                       |    5 +----
> >  9 files changed, 12 insertions(+), 19 deletions(-)
> > 
> > diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> > index 8a24b6c..d2a2a98 100644
> > --- a/arch/arm/mach-davinci/board-da850-evm.c
> > +++ b/arch/arm/mach-davinci/board-da850-evm.c
> > @@ -1377,8 +1377,8 @@ static const short da850_wl12xx_pins[] __initconst = {
> >  
> >  static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
> >  	.irq			= -1,
> > +	.irq_flags		= IRQF_TRIGGER_RISING,
> >  	.board_ref_clock	= WL12XX_REFCLOCK_38,
> > -	.platform_quirks	= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
> >  };
> >  
> >  static __init int da850_wl12xx_init(void)
> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> > index 56a9a4f..c2334aa 100644
> > --- a/arch/arm/mach-omap2/board-4430sdp.c
> > +++ b/arch/arm/mach-omap2/board-4430sdp.c
> > @@ -693,6 +693,7 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
> >  }
> >  
> >  static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
> > +	.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> 
> couldn't you just call irq_set_irq_type() from the board-file itself ?
> Then on your driver you can just pass IRQF_ONESHOT (to make sure heh) to
> your request_threaded_irq_handler()

Good point.  This is an oldish patch from the time I still thought I'd
have to pass the flags in the device tree.  It turned out that I don't
need it anymore, so this can be totally removed from pdata and be set by
the board file itself.

As you saw in a later patch, I do make sure the driver sets
IRQF_ONESHOT. ;)

--
Cheers,
Luca.



From coelho at ti.com  Tue Jul  2 16:14:44 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 23:14:44 +0300
Subject: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations
 for pdata clocks
In-Reply-To: <20130702153113.GF7013@arwen.pp.htv.fi>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-5-git-send-email-coelho@ti.com>
 <20130702153113.GF7013@arwen.pp.htv.fi>
Message-ID: <1372796084.21065.85.camel@cumari.coelho.fi>

On Tue, 2013-07-02 at 18:31 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 02, 2013 at 05:55:43PM +0300, Luciano Coelho wrote:
> > diff --git a/drivers/net/wireless/ti/wl12xx/main.c b/drivers/net/wireless/ti/wl12xx/main.c
> > index 1c627da..903dcb3 100644
> > --- a/drivers/net/wireless/ti/wl12xx/main.c
> > +++ b/drivers/net/wireless/ti/wl12xx/main.c
> > @@ -1701,6 +1701,42 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
> >  		},
> >  };
> >  
> > +static struct wl12xx_clock wl12xx_refclock_table[] = {
> 
> const
> 
> > +	{ 19200000,	false,	WL12XX_REFCLOCK_19	},
> > +	{ 26000000,	false,	WL12XX_REFCLOCK_26	},
> > +	{ 26000000,	true,	WL12XX_REFCLOCK_26_XTAL	},
> > +	{ 38400000,	false,	WL12XX_REFCLOCK_38	},
> > +	{ 38400000,	true,	WL12XX_REFCLOCK_38_XTAL	},
> > +	{ 52000000,	false,	WL12XX_REFCLOCK_52	},
> > +	{ 0,		false,	0 }
> > +};
> > +
> > +static struct wl12xx_clock wl12xx_tcxoclock_table[] = {
> 
> const

Duh! Thanks for noticing it.

--
Luca.



From coelho at ti.com  Tue Jul  2 16:16:58 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 23:16:58 +0300
Subject: [PATCH v2 5/9] wlcore: always use one-shot IRQ
In-Reply-To: <20130702153229.GG7013@arwen.pp.htv.fi>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-6-git-send-email-coelho@ti.com>
 <20130702153229.GG7013@arwen.pp.htv.fi>
Message-ID: <1372796218.21065.87.camel@cumari.coelho.fi>

On Tue, 2013-07-02 at 18:32 +0300, Felipe Balbi wrote:
> On Tue, Jul 02, 2013 at 05:55:44PM +0300, Luciano Coelho wrote:
> > Since we are now using threaded IRQs without the primary handler, we
> > need to set IRQF_ONESHOT, otherwise our request will fail.
> > 
> > Signed-off-by: Luciano Coelho <coelho at ti.com>
> 
> good to see this happening, I remember we talked about this a while back
> :-)

Yeah, we talked about it and I did the patch immediately.  This is
needed because this is obviously not set automatically in the interrupts
created via device tree.


> Acked-by: Felipe Balbi <balbi at ti.com>
> 
> Still, if you call irq_set_irq_type() on board-file (since DT will do
> something similar for you anyway) then you can completely drop
> irq_flags.

Yep.

--
Luca.



From linus.walleij at linaro.org  Tue Jul  2 16:19:36 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 2 Jul 2013 22:19:36 +0200
Subject: [PATCH v4] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <1372687359-18235-1-git-send-email-jonas.jensen@gmail.com>
References: <1372332203-30228-1-git-send-email-jonas.jensen@gmail.com>
 <1372687359-18235-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <CACRpkdbT3yiq79rCRK0kFe39Y6QkSZHJ+7kbcmKFH8esGEN3LQ@mail.gmail.com>

On Mon, Jul 1, 2013 at 4:02 PM, Jonas Jensen <jonas.jensen at gmail.com> wrote:

> This patch adds an clocksource driver for the main timer(s)
> found on MOXA ART SoCs.
>
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>

I'm pretty happy with this version, tglx points out a possible optimization
getting rid of some unnecessary reads in hotpath but anyway:
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From coelho at ti.com  Tue Jul  2 16:19:54 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 23:19:54 +0300
Subject: [PATCH v2 8/9] wlcore: sdio: get clocks from device tree
In-Reply-To: <20130702153526.GI7013@arwen.pp.htv.fi>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-9-git-send-email-coelho@ti.com>
 <20130702153526.GI7013@arwen.pp.htv.fi>
Message-ID: <1372796394.21065.89.camel@cumari.coelho.fi>

On Tue, 2013-07-02 at 18:35 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 02, 2013 at 05:55:47PM +0300, Luciano Coelho wrote:
> > @@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func,
> >  	/* Use block mode for transferring over one block size of data */
> >  	func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
> >  
> > +	sdio_set_drvdata(func, glue);
> 
> is this move really necessary ?

It is, because I use the glue in wlcore_get_pdata_from_of(), so I need
to call sdio_set_drvdata() earlier.  I reckoned it wouldn't hurt to move
this, so I wouldn't have to pass the glue in the
wlcore_get_pdata_from_of() call.

--
Luca.



From coelho at ti.com  Tue Jul  2 16:27:30 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 2 Jul 2013 23:27:30 +0300
Subject: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations
 for pdata clocks
In-Reply-To: <20130702150208.GA4233@kahuna>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-5-git-send-email-coelho@ti.com>
 <20130702150208.GA4233@kahuna>
Message-ID: <1372796850.21065.93.camel@cumari.coelho.fi>

On Tue, 2013-07-02 at 10:02 -0500, Nishanth Menon wrote:
> On 17:55-20130702, Luciano Coelho wrote:
> > Instead of defining an enumeration with the FW specific values for the
> > different clock rates, use the actual frequency instead.  Also add a
> > boolean to specify whether the clock is XTAL or not.
> > 
> > Change all board files to reflect this.
> > 
> > Cc: Tony Lindgren <tony at atomide.com>
> > Cc: Sekhar Nori <nsekhar at ti.com>
> > Signed-off-by: Luciano Coelho <coelho at ti.com>
> > ---
> >  arch/arm/mach-davinci/board-da850-evm.c      |    3 +-
> >  arch/arm/mach-omap2/board-4430sdp.c          |    5 ++-
> ^^
> >  arch/arm/mach-omap2/board-omap3evm.c         |    3 +-
> >  arch/arm/mach-omap2/board-omap4panda.c       |    3 +-
> ^^
> Please do not add more platform data to platforms that are DT only.

Ah, I hadn't realized that board_omap4panda.c and board-4430sdp.c had
been removed in linux-next.  I base my tree on wireless-next and it
doesn't contain these changes yet.  I would only have noticed this when
I rebased my tree once the merge window is closed. ;)

Thanks for pointing out, I'll make sure these changes will not be there
when I send the pull request.

--
Cheers,
Luca.



From lho at apm.com  Tue Jul  2 16:38:57 2013
From: lho at apm.com (Loc Ho)
Date: Tue,  2 Jul 2013 14:38:57 -0600
Subject: [PATCH 0/2] power: Add APM X-Gene SoC system reboot driver.
Message-ID: <1372797539-13111-1-git-send-email-lho@apm.com>

Add APM X-Gene SoC system reboot driver. This driver only supports system
reboot. System shutdown is board specific and will be handled by board specific
driver or GPIO based driver.

Loc Ho (2):
  power: Add APM X-Gene SoC system reboot driver. This driver handles
    only
  power: arm64: Add DTS entry for APM X-Gene reboot driver.

 arch/arm64/boot/dts/apm-storm.dtsi |    6 ++
 drivers/power/reset/Kconfig        |    7 +++
 drivers/power/reset/Makefile       |    1 +
 drivers/power/reset/xgene-reboot.c |  101 ++++++++++++++++++++++++++++++++++++
 4 files changed, 115 insertions(+), 0 deletions(-)
 create mode 100755 drivers/power/reset/xgene-reboot.c



From lho at apm.com  Tue Jul  2 16:38:58 2013
From: lho at apm.com (Loc Ho)
Date: Tue,  2 Jul 2013 14:38:58 -0600
Subject: [PATCH 1/2] power: Add APM X-Gene system reboot driver
In-Reply-To: <1372797539-13111-1-git-send-email-lho@apm.com>
References: <1372797539-13111-1-git-send-email-lho@apm.com>
Message-ID: <1372797539-13111-2-git-send-email-lho@apm.com>

power: Add APM X-Gene SoC system reboot driver. This driver handles only
system reboot. System shutdown is board specific and can be handled by board
driver or GPIO based shutdown driver.

Signed-off-by: Loc Ho <lho at apm.com>
Signed-off-by: Feng Kan <fkan at apm.com>
Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
---
 drivers/power/reset/Kconfig        |    7 +++
 drivers/power/reset/Makefile       |    1 +
 drivers/power/reset/xgene-reboot.c |  101 ++++++++++++++++++++++++++++++++++++
 3 files changed, 109 insertions(+), 0 deletions(-)
 create mode 100755 drivers/power/reset/xgene-reboot.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 349e9ae..c41a7de 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -37,3 +37,10 @@ config POWER_RESET_VEXPRESS
 	help
 	  Power off and reset support for the ARM Ltd. Versatile
 	  Express boards.
+
+config POWER_RESET_XGENE
+        bool
+	default y if ARM64
+        depends on POWER_RESET	
+        help
+          Reboot support for the APM SoC X-Gene Eval boards.
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 372807f..e75d54c 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
 obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
 obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
 obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
+obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
diff --git a/drivers/power/reset/xgene-reboot.c b/drivers/power/reset/xgene-reboot.c
new file mode 100755
index 0000000..e6e4178
--- /dev/null
+++ b/drivers/power/reset/xgene-reboot.c
@@ -0,0 +1,101 @@
+/*
+ * xgene-reboot.c - AppliedMicro X-Gene SoC Reboot Driver
+ *
+ * Copyright (c) 2013, Applied Micro Circuits Corporation
+ * Author: Feng Kan <fkan at apm.com>
+ * Author: Loc Ho <lho at apm.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ * This driver provides system reboot functionality for APM X-Gene SoC.
+ * For system shutdown, this is board specify. If a board designer
+ * implements GPIO shutdown, use the gpio-poweroff.c driver.
+ *
+ */
+#include <linux/io.h>
+#include <linux/of_device.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/stat.h>
+#include <linux/slab.h>
+#include <asm/system_misc.h>
+
+struct xgene_reboot_context {
+	struct platform_device *pdev;
+	void *csr;
+	u32 mask;
+};
+
+static struct xgene_reboot_context *xgene_restart_ctx;
+
+static void xgene_restart(char str, const char *cmd)
+{
+	struct xgene_reboot_context *ctx = xgene_restart_ctx;
+	unsigned long timeout;
+
+	/* Issue the reboot */
+	if (ctx)
+		writel(ctx->mask, ctx->csr);
+
+	timeout = jiffies + HZ;
+	while (time_before(jiffies, timeout))
+		cpu_relax();
+
+	dev_emerg(&ctx->pdev->dev, "Unable to restart system\n");
+}
+
+static int xgene_reboot_probe(struct platform_device *pdev)
+{
+	struct xgene_reboot_context *ctx;
+
+	ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+	if (ctx == NULL) {
+		dev_err(&pdev->dev, "out of memory for context\n");
+		return -ENODEV;
+	}
+	ctx->csr = of_iomap(pdev->dev.of_node, 0);
+	if (ctx->csr == NULL) {
+		devm_kfree(&pdev->dev, ctx);
+		dev_err(&pdev->dev, "can not map resource\n");
+		return -ENODEV;
+	}
+	if (of_property_read_u32(pdev->dev.of_node, "mask", &ctx->mask))
+		ctx->mask = 0xFFFFFFFF;
+	ctx->pdev = pdev;
+	arm_pm_restart = xgene_restart;
+	xgene_restart_ctx = ctx;
+
+	return 0;
+}
+
+static struct of_device_id xgene_reboot_of_match[] = {
+	{ .compatible = "apm,xgene-reboot" },
+	{}
+};
+
+static struct platform_driver xgene_reboot_driver = {
+	.probe = xgene_reboot_probe,
+	.driver = {
+		.name = "xgene-reboot",
+		.of_match_table = xgene_reboot_of_match,
+	},
+};
+
+static int __init xgene_reboot_init(void)
+{
+	return platform_driver_register(&xgene_reboot_driver);
+}
+device_initcall(xgene_reboot_init);
-- 
1.5.5



From lho at apm.com  Tue Jul  2 16:38:59 2013
From: lho at apm.com (Loc Ho)
Date: Tue,  2 Jul 2013 14:38:59 -0600
Subject: [PATCH 2/2] power: arm64: Add DTS entry for APM X-Gene reboot driver.
In-Reply-To: <1372797539-13111-2-git-send-email-lho@apm.com>
References: <1372797539-13111-1-git-send-email-lho@apm.com>
 <1372797539-13111-2-git-send-email-lho@apm.com>
Message-ID: <1372797539-13111-3-git-send-email-lho@apm.com>

power: arm64: Add DTS entry for APM X-Gene reboot driver.

Signed-off-by: Loc Ho <lho at apm.com>
Signed-off-by: Feng Kan <fkan at apm.com>
Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
---
 arch/arm64/boot/dts/apm-storm.dtsi |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
index d37d736..e686919 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -178,6 +178,12 @@
 			};
 		};
 
+                reboot at 0x17000014 {
+                        compatible = "apm,xgene-reboot";
+                        reg = <0x0 0x17000014 0x0 0x100>;
+                        mask = <0x1>;
+                };
+
 		serial0: serial at 1c020000 {
 			device_type = "serial";
 			compatible = "ns16550";
-- 
1.5.5



From balbi at ti.com  Tue Jul  2 17:30:30 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Jul 2013 00:30:30 +0300
Subject: [PATCH v2 7/9] wlcore: sdio: add wilink clock providers
In-Reply-To: <20130702153423.GH7013@arwen.pp.htv.fi>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-8-git-send-email-coelho@ti.com>
 <20130702153423.GH7013@arwen.pp.htv.fi>
Message-ID: <20130702213030.GB10388@arwen.pp.htv.fi>

Hi,

On Tue, Jul 02, 2013 at 06:34:23PM +0300, Felipe Balbi wrote:
> On Tue, Jul 02, 2013 at 05:55:46PM +0300, Luciano Coelho wrote:
> > Add refclock and tcxoclock as clock providers in WiLink.  These clocks
> > are not accesible outside the WiLink module, but they are registered
> > in the clock framework anyway.  Only the WiLink chip consumes these
> > clocks.
> > 
> > In theory, the WiLink chip could be connected to external clocks
> > instead of using these internal clocks, so make the clock consumer
> > code generic enough.  If external clocks are used, then the internal
> > clock device tree nodes are not necessary, but the external ones must
> > be specified.
> > 
> > Signed-off-by: Luciano Coelho <coelho at ti.com>
> 
> Acked-by: Felipe Balbi <balbi at ti.com>

I guess this should've been

Reviewed-by: Felipe Balbi <balbi at ti.com>

instead

-- 
balbi
-------------- 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/20130703/5194aa14/attachment.sig>

From balbi at ti.com  Tue Jul  2 17:32:08 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Jul 2013 00:32:08 +0300
Subject: [PATCH v2 8/9] wlcore: sdio: get clocks from device tree
In-Reply-To: <1372796394.21065.89.camel@cumari.coelho.fi>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-9-git-send-email-coelho@ti.com>
 <20130702153526.GI7013@arwen.pp.htv.fi>
 <1372796394.21065.89.camel@cumari.coelho.fi>
Message-ID: <20130702213208.GC10388@arwen.pp.htv.fi>

On Tue, Jul 02, 2013 at 11:19:54PM +0300, Luciano Coelho wrote:
> On Tue, 2013-07-02 at 18:35 +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > On Tue, Jul 02, 2013 at 05:55:47PM +0300, Luciano Coelho wrote:
> > > @@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func,
> > >  	/* Use block mode for transferring over one block size of data */
> > >  	func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
> > >  
> > > +	sdio_set_drvdata(func, glue);
> > 
> > is this move really necessary ?
> 
> It is, because I use the glue in wlcore_get_pdata_from_of(), so I need
> to call sdio_set_drvdata() earlier.  I reckoned it wouldn't hurt to move
> this, so I wouldn't have to pass the glue in the
> wlcore_get_pdata_from_of() call.

that's alright, it does look like it deserves a mention in changelog
though. Other than that:

Reviewed-by: Felipe Balbi <balbi at ti.com>

-- 
balbi
-------------- 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/20130703/ec49d171/attachment.sig>

From coelho at ti.com  Tue Jul  2 17:38:45 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 3 Jul 2013 00:38:45 +0300
Subject: [PATCH v2 8/9] wlcore: sdio: get clocks from device tree
In-Reply-To: <20130702213208.GC10388@arwen.pp.htv.fi>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-9-git-send-email-coelho@ti.com>
 <20130702153526.GI7013@arwen.pp.htv.fi>
 <1372796394.21065.89.camel@cumari.coelho.fi>
 <20130702213208.GC10388@arwen.pp.htv.fi>
Message-ID: <1372801125.21065.99.camel@cumari.coelho.fi>

On Wed, 2013-07-03 at 00:32 +0300, Felipe Balbi wrote:
> On Tue, Jul 02, 2013 at 11:19:54PM +0300, Luciano Coelho wrote:
> > On Tue, 2013-07-02 at 18:35 +0300, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Tue, Jul 02, 2013 at 05:55:47PM +0300, Luciano Coelho wrote:
> > > > @@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func,
> > > >  	/* Use block mode for transferring over one block size of data */
> > > >  	func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
> > > >  
> > > > +	sdio_set_drvdata(func, glue);
> > > 
> > > is this move really necessary ?
> > 
> > It is, because I use the glue in wlcore_get_pdata_from_of(), so I need
> > to call sdio_set_drvdata() earlier.  I reckoned it wouldn't hurt to move
> > this, so I wouldn't have to pass the glue in the
> > wlcore_get_pdata_from_of() call.
> 
> that's alright, it does look like it deserves a mention in changelog
> though. Other than that:

Uh, ok.  This was so tiny (and I thought so obvious) a change that I
didn't mention it.  But if you asked about it, it was not obvious
enough. ;) I'll add a small comment about it in the commit message.


> Reviewed-by: Felipe Balbi <balbi at ti.com>

Thanks!

--
Luca.



From arno at natisbad.org  Tue Jul  2 17:48:08 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Tue, 02 Jul 2013 23:48:08 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130702174111.GF17110@titan.lakedaemon.net> (Jason Cooper's
 message of "Tue, 2 Jul 2013 13:41:11 -0400")
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net>
 <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net>
Message-ID: <87y59ows4n.fsf@natisbad.org>

Hi,

Jason Cooper <jason at lakedaemon.net> writes:

> On Tue, Jul 02, 2013 at 07:22:34PM +0200, Arnaud Ebalard wrote:
>> Hi,
>> 
>> Jason Cooper <jason at lakedaemon.net> writes:
>> 
>> >> The big problem is that the Armada 370 and Armada XP datasheets are
>> >> still only available under NDA, so it's quite hard for someone to step
>> >> up and do this, without access to those datasheets.
>> >
>> > bummer.
>> >
>> >> It used to be on our TODO-list, but isn't any longer, and I have no
>> >> informations about when it will re-appear on our TODO-list at this
>> >> point.
>> >
>> > So, Arnaud, how do you feel about tackling the nand driver based on the
>> > sources you have and the pointers above?
>> 
>> Sadly, I do not have enough spare time to work on this: at the moment, I
>> intend to focus on writing a clean driver for ISL 12057 RTC/Alarm chip
>> and get it accepted for 3.12.
>
> more bummer.  Willy, mind posting what you have?  Arnaud, do you have a
> link to the source code for your device?  And have you found the code
> they started with?

The code NETGEAR provides for ReadyNAS 102 is a (lightly) modified
version of KW40 LSP release 3.1.0-NQ. This is basically a 3.0.X kernel
(X=6 for Marvell LSP, X=56 in NETGEAR's tarball), with some 1,133,970
(no typo) lines patches on top of it:

 http://www.readynas.com/download/GPL/other/linux-ntgr-3.0.56.tar.xz

A quick look provides the following:

$ wc -l arch/arm/plat-armada/mv_drivers_lsp/mv_mtd/nand_nfc.c 
1761 arch/arm/plat-armada/mv_drivers_lsp/mv_mtd/nand_nfc.c

$ head -10 arch/arm/plat-armada/mv_drivers_lsp/mv_mtd/nand_nfc.c 
/*
 * nand_nfc.c
 *
 * Copyright c 2005 Intel Corporation
 * Copyright c 2006 Marvell International Ltd.
 *
 * This driver is based on the PXA drivers/mtd/nand/pxa3xx_nand.c
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as

Which matches what Thomas wrote in a previous email regarding pwa3xx
base. 

Cheers,

a+


From swarren at wwwdotorg.org  Tue Jul  2 18:53:49 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue,  2 Jul 2013 16:53:49 -0600
Subject: [PATCH] ARM: move body of head-common.S back to text section
Message-ID: <1372805629-18382-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Commit 281ecb7 "arm: delete __cpuinit/__CPUINIT usage from all ARM
users" removed a __CPUINIT from head-common.S. However, the code
immediately before the removed tag was marked __INIT, and was missing
a match __FINIT. This caused code after the removed __CPUINIT to end
up in the init section rather than the main text section as desired.
This caused issues such as secondary CPU boot failures or crashes.
Add the missing __FINIT to solve this.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/kernel/head-common.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
index 529ce99..a9dc804 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -122,6 +122,8 @@ __mmap_switched_data:
 	.long	init_thread_union + THREAD_START_SP @ sp
 	.size	__mmap_switched_data, . - __mmap_switched_data
 
+	__FINIT
+
 /*
  * This provides a C-API version of __lookup_processor_type
  */
-- 
1.8.1.5



From arno at natisbad.org  Tue Jul  2 19:09:50 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Wed, 03 Jul 2013 01:09:50 +0200
Subject: [PATCH v6 5/7] ARM: kirkwood: remove redundant DT board files
In-Reply-To: <1372762824-12202-6-git-send-email-sebastian.hesselbarth@gmail.com>
 (Sebastian Hesselbarth's message of "Tue, 2 Jul 2013 13:00:22 +0200")
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1372762824-12202-6-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <87k3l8v9s1.fsf@natisbad.org>

Hi Sebastian,

Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> writes:

> With DT support for mv643xx_eth board specific init for some boards now
> is unneccessary. Remove those board files, Kconfig entries, and
> corresponding entries in kirkwood_defconfig.

Applying above your set an old quilt cleaning patch Jason asked at some
point, it became empty except for arch/arm/mach_kirkwood/common.h in
which some declarations were left behind. If this is correct, can you
just merge the hunks below in your 5/7 in next round?

AFAICT, only dnskw_init() remains, which matches the list of board-*.c
files in arch/arm/mach_kirkwood/ (i.e. board-dt.c and board-dnskw.c).

Cheers,

a+

Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
---
 arch/arm/mach-kirkwood/common.h | 108 ----------------------------------------
 1 file changed, 108 deletions(-)

diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 1c09f3f..1cbdd2b 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -57,26 +57,6 @@ void kirkwood_restart(char, const char *);
 void kirkwood_clk_init(void);
 
 /* board init functions for boards not fully converted to fdt */
-#ifdef CONFIG_MACH_DREAMPLUG_DT
-void dreamplug_init(void);
-#else
-static inline void dreamplug_init(void) {};
-#endif
-#ifdef CONFIG_MACH_GURUPLUG_DT
-void guruplug_dt_init(void);
-#else
-static inline void guruplug_dt_init(void) {};
-#endif
-#ifdef CONFIG_MACH_SHEEVAPLUG_DT
-void sheevaplug_dt_init(void);
-#else
-static inline void sheevaplug_dt_init(void) {};
-#endif
-#ifdef CONFIG_MACH_TS219_DT
-void qnap_dt_ts219_init(void);
-#else
-static inline void qnap_dt_ts219_init(void) {};
-#endif
 
 #ifdef CONFIG_MACH_DLINK_KIRKWOOD_DT
 void dnskw_init(void);
@@ -84,94 +64,6 @@ void dnskw_init(void);
 static inline void dnskw_init(void) {};
 #endif
 
-#ifdef CONFIG_MACH_ICONNECT_DT
-void iconnect_init(void);
-#else
-static inline void iconnect_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_IB62X0_DT
-void ib62x0_init(void);
-#else
-static inline void ib62x0_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_DOCKSTAR_DT
-void dockstar_dt_init(void);
-#else
-static inline void dockstar_dt_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_GOFLEXNET_DT
-void goflexnet_init(void);
-#else
-static inline void goflexnet_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_LSXL_DT
-void lsxl_init(void);
-#else
-static inline void lsxl_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_IOMEGA_IX2_200_DT
-void iomega_ix2_200_init(void);
-#else
-static inline void iomega_ix2_200_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_KM_KIRKWOOD_DT
-void km_kirkwood_init(void);
-#else
-static inline void km_kirkwood_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_DB88F628X_BP_DT
-void db88f628x_init(void);
-#else
-static inline void db88f628x_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_MPLCEC4_DT
-void mplcec4_init(void);
-#else
-static inline void mplcec4_init(void) {};
-#endif
-
-#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
-	defined(CONFIG_MACH_NETSPACE_V2_DT) || \
-	defined(CONFIG_MACH_NETSPACE_MAX_V2_DT) || \
-	defined(CONFIG_MACH_NETSPACE_LITE_V2_DT) || \
-	defined(CONFIG_MACH_NETSPACE_MINI_V2_DT)
-void ns2_init(void);
-#else
-static inline void ns2_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_OPENBLOCKS_A6_DT
-void openblocks_a6_init(void);
-#else
-static inline void openblocks_a6_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_READYNAS_DT
-void netgear_readynas_init(void);
-#else
-static inline void netgear_readynas_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_TOPKICK_DT
-void usi_topkick_init(void);
-#else
-static inline void usi_topkick_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_CLOUDBOX_DT
-void cloudbox_init(void);
-#else
-static inline void cloudbox_init(void) {};
-#endif
-
 /* early init functions not converted to fdt yet */
 char *kirkwood_id(void);
 void kirkwood_l2_init(void);
-- 
1.8.3.1



From linux at arm.linux.org.uk  Tue Jul  2 19:17:06 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 3 Jul 2013 00:17:06 +0100
Subject: [GIT PULL 3/7] ARM SoC specific changes
In-Reply-To: <201307022104.01826.arnd@arndb.de>
References: <201307022055.50717.arnd@arndb.de>
 <201307022104.01826.arnd@arndb.de>
Message-ID: <20130702231706.GF24642@n2100.arm.linux.org.uk>

Please don't merge this yet.

Arnd has just done the worst possible thing - the arm-soc tree has taken
bits of my tree, merged them into their own tree, had the same conflicts
I've had, and then resolved them differently.

The result is that when these two trees now merge, they conflict on the
conflict resolutions.  This is utter madness.

This has also only _just_ happened.

On Tue, Jul 02, 2013 at 09:04:01PM +0200, Arnd Bergmann wrote:
> The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f:
> 
>   Linux 3.10-rc6 (2013-06-15 11:51:07 -1000)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/soc-for-linus
> 
> for you to fetch changes up to 1eb92b24e243085d242cf5ffd64829bba70972e1:
> 
>   ARM: integrator: let pciv3 use mem/premem from device tree (2013-06-27 14:19:54 +0200)
> 
> ----------------------------------------------------------------
> ARM SoC specific changes
> 
> These changes are all to SoC-specific code, a total of 33 branches on
> 17 platforms were pulled into this. Like last time, Renesas sh-mobile
> is now the platform with the most changes, followed by OMAP and EXYNOS.
> 
> Two new platforms, TI Keystone and Rockchips RK3xxx are added in
> this branch, both containing almost no platform specific code at all,
> since they are using generic subsystem interfaces for clocks, pinctrl,
> interrupts etc. The device drivers are getting merged through the
> respective subsystem maintainer trees.
> 
> One more SoC (u300) is now multiplatform capable and several others
> (shmobile, exynos, msm, integrator, kirkwood, clps711x) are moving
> towards that goal with this series but need more work.
> 
> Also noteworthy is the work on PCI here, which is traditionally part of
> the SoC specific code. With the changes done by Thomas Petazzoni, we can
> now more easily have PCI host controller drivers as loadable modules and
> keep them separate from the platform code in drivers/pci/host. This has
> already led to the discovery that three platforms (exynos, spear and imx)
> are actually using an identical PCIe host controller and will be able
> to share a driver once support for spear and imx is added.
> 
> Conflicts:
> * asm/glue-proc.h has one CPU type getting added that conflicts
>   with another addition in 3.10-rc7
> * Simple context changes in arch/arm/Makefile and arch/arm/Kconfig
> 
> ----------------------------------------------------------------
> 
> Afzal Mohammed (9):
>       ARM: OMAP2+: separate out OMAP4 restart
>       ARM: OMAP2+: AM43x: Kconfig
>       ARM: OMAP2+: AM43x: kbuild
>       ARM: OMAP2+: AM43x: soc_is support
>       ARM: OMAP2+: AM437x: SoC revision detection
>       ARM: OMAP2+: AM43x: static mapping
>       ARM: OMAP2+: AM43x: early init
>       ARM: OMAP2+: AM43x: GP or HS ?
>       ARM: OMAP2+: AM43x: basic dt support
> 
> Aida Mynzhasova (2):
>       ARM: OMAP2: TI81XX: id: Add cpu id for TI816x ES2.0 and ES2.1
>       ARM: OMAP: TI816X: add powerdomains for TI816x
> 
> Alexander Shiyan (18):
>       GPIO: clps711x: Rewrite driver for using generic GPIO code
>       GPIO: clps711x: Add DT support
>       ARM: clps711x: Re-add GPIO support
>       ARM: clps711x: Remove NEED_MACH_MEMORY_H dependency
>       ARM: clps711x: Set PLL clock to zero if we work from 13 mHz source
>       ARM: clps711x: autcpu12: Move LCD DPOT definitions to board file
>       ARM: clps711x: autcpu12: Add support for NOR flash
>       ARM: clps711x: autcpu12: Special driver for handling memory is removed
>       ARM: clps711x: autcpu12: Move remaining specific definitions to board file
>       ARM: clps711x: p720t: Define PLD registers as GPIOs
>       ARM: clps711x: Move specific definitions from hardware.h to boards files
>       ARM: clps711x: Replace "arch_initcall" in common code with ".init_early"
>       ARM: clps711x: Add clocksource framework
>       ARM: clps711x: Optimize interrupt handling
>       ARM: clps711x: edb7211: Add support for I2C
>       ARM: clps711x: edb7211: Control LCD backlight via PWM
>       ARM: clps711x: Add support for SYSCON driver
>       ARM: clps711x: Update defconfig
> 
> Andrew Lunn (3):
>       ARM: Kirkwood: Enable USB 3.0 in kirkwood_defconfig
>       arm: kirkwood: Enable cpufreq and ondemand on kirkwood_defconfig
>       arm: kirkwood: Instantiate cpufreq driver
> 
> Arnaud Ebalard (1):
>       arm: kirkwood: NETGEAR ReadyNAS Duo v2 init PCIe via DT
> 
> Arnd Bergmann (27):
>       drivers/bus: arm-cci: fix combined ARMv6+v7 build
>       ARM: EXYNOS: Remove custom init_irq callbacks
>       ARM: EXYNOS: Use exynos_init_io() as map_io callback
>       ARM: EXYNOS: Remove legacy L2X0 initialization
>       ARM: EXYNOS: Remove remaining dead code after non-DT support removal
>       Merge tag 'integrator-pci-for-arm-soc' of git://git.kernel.org/.../linusw/linux-integrator into next/soc
>       Merge tag 'u300-multiplatform' of git://git.kernel.org/.../linusw/linux-stericsson into next/soc
>       Merge tag 'imx-soc-3.11' of git://git.linaro.org/people/shawnguo/linux-2.6 into next/soc
>       ARM: u300: only build for ARCH_MULTI_V5
>       Merge tag 'davinci-for-v3.11/soc-v2' of git://git.kernel.org/.../nsekhar/linux-davinci into next/soc
>       Merge tag 'sunxi-defconfig-for-3.11' of git://github.com/mripard/linux into next/soc
>       Merge tag 'sunxi-core-for-3.11-2' of git://github.com/mripard/linux into next/soc
>       Merge tag 'omap-for-v3.11/soc-part2-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/soc
>       Merge branch 'omap/pm-voltdomain-cleanup' into next/soc
>       Merge tag 'exynos-arch-2' of git://git.kernel.org/.../kgene/linux-samsung into next/soc
>       Merge tag 'remove-nondt-exynos-3' of git://git.kernel.org/.../kgene/linux-samsung into next/soc
>       Merge tag 'samsung-defconfig-1' of git://git.kernel.org/.../kgene/linux-samsung into next/soc
>       Merge tag 'v3.11-rockchip-basics' of git://git.kernel.org/.../mmind/linux-rockchip into next/soc
>       Merge tag 'renesas-cleanup-boot-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/soc
>       Merge tag 'regmap-3.11-2' of git://git.infradead.org/users/jcooper/linux into next/soc
>       ARM: imx: Synertronixx scb9328 needs to select SOC_IMX1
>       ARM: keystone: select ARM_ERRATA_798181 only for SMP
>       ARM: imx: select syscon for IMX6SL
>       ARM: multiplatform: always pick one CPU type
>       Merge tag 'davinci-for-v3.11/soc-2' of git://git.kernel.org/.../nsekhar/linux-davinci into next/soc
>       Merge tag 'omap-pm-v3.11/fixes/omap5-voltdm' of git://git.kernel.org/.../khilman/linux-omap-pm into next/soc
>       Merge tag 'soc-for-linus' into for-linus
> 
> Bastian Hecht (5):
>       sh-pfc: Add entries for INTC external IRQs
>       sh-pfc: r8a7740: Add SCIFA1 data group
>       ARM: shmobile: armadillo800eva: Convert SCIFA1 to pinctrl
>       ARM: shmobile: r8a7740: Add interim sh-eth device name to clocks list
>       ARM: shmobile: r8a7740: Add I2C DT clock names
> 
> Benoit Cousson (7):
>       ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files
>       ARM: OMAP5: CM: Add OMAP54XX register and bitfield files
>       ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers
>       ARM: OMAP5: SCRM: Add OMAP54XX header file.
>       ARM: OMAP5: clockdomain data: Add OMAP54XX data and update the header
>       ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header
>       ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
> 
> Catalin Marinas (1):
>       ARM: Add base support for ARMv7-M
> 
> Dave Martin (1):
>       ARM: vexpress/dcscb: handle platform coherency exit/setup and CCI
> 
> Dinh Nguyen (2):
>       ARM: socfpga: Add support to gate peripheral clocks
>       ARM: socfpga: Add syscon to be part of socfpga
> 
> Dirk Behme (3):
>       ARM: i.MX6: add i.MX6 specific L2 cache configuration
>       ARM: i.MX6: clk: add i.MX6 DualLite differences
>       ARM: i.MX6: clk: add different DualLite MLB clock config
> 
> Dmitry Osipenko (1):
>       ARM: tegra: emc: correction of ram-code parsing from dt
> 
> Doug Anderson (1):
>       ARM: EXYNOS: Select PINCTRL_EXYNOS for exynos4/5 at chip level
> 
> Ezequiel Garcia (1):
>       ARM: mvebu: Add support for USB storage class in mvebu_defconfig
> 
> Fabio Estevam (6):
>       ARM: imx: imx_v6_v7_defconfig: Select CONFIG_DRM_IMX_TVE
>       ARM: imx: Enable mx6 solo-lite support
>       ARM: imx: irq-common: Include header to avoid sparse warning
>       ARM: imx: clk: No need to initialize phandle struct
>       ARM: imx_v6_v7_defconfig: Enable PWM and backlight options
>       ARM: imx_v6_v7_defconfig: Enable Vybrid VF610
> 
> Guennadi Liakhovetski (9):
>       pinctrl: sh-pfc: fix r8a7790 Function Select register tables
>       pinctrl: sh-pfc: fix a typo in pfc-r8a7790
>       pinctrl: r8a7790: add pinmux data for MMCIF and SDHI interfaces
>       ARM: shmobile: sh73a0: add support for adjusting CPU frequency
>       ARM: shmobile: sh73a0: add CPUFreq support
>       ARM: shmobile: sh73a0: do not overwrite all div4 clock operations
>       ARM: shmobile: sh73a0: div4 clocks must check the kick bit before changing rate
>       ARM: shmobile: r8a73a4: add clock definitions and aliases for MMCIF and SDHI
>       ARM: shmobile: r8a7790: add clock definitions and aliases for MMCIF and SDHI
> 
> Heiko Stuebner (10):
>       ARM: S3C24XX: split s3c2412 spi dma channels
>       ARM: S3C24XX: dma-s3c2443 - do not write into arbitary bits
>       ARM: S3C24XX: remove obsolete s3c2412 specific dma settings
>       clocksource: dw_apb_timer_of: enable the use the clocksource as sched clock
>       clocksource: dw_apb_timer_of: add clock-handling
>       clocksource: dw_apb_timer_of: select DW_APB_TIMER
>       clocksource: dw_apb_timer_of: use clocksource_of_init
>       arm: Add basic clocks for Rockchip rk3066a SoCs
>       arm: add debug uarts for rockchip rk29xx and rk3xxx series
>       arm: add basic support for Rockchip RK3066a boards
> 
> Huang Shijie (1):
>       ARM: imx6q: clk: add the eim_slow clock
> 
> Jason Cooper (3):
>       ARM: kirkwood: enable Sheevaplug DT in defconfig
>       Merge tag 'tags/fixes-non-3.11-1' into mvebu/regmap
>       Merge tag 'tags/cleanup-3.11-3' into mvebu/regmap
> 
> Jiada Wang (2):
>       ARM: imx: disable pll8_mlb in mx6q_clks
>       ARM: imx: remove MLB PLL from pllv3
> 
> Jingchang Lu (2):
>       ARM: imx: add VF610 clock support
>       ARM: imx: add initial support for VF610
> 
> Jingoo Han (4):
>       pci: Add PCIe driver for Samsung Exynos
>       ARM: EXYNOS: Enable PCIe support for Exynos5440
>       ARM: dts: Add pcie controller node for Samsung EXYNOS5440 SoC
>       ARM: dts: Add pcie controller node for exynos5440-ssdk5440
> 
> Jon Medhurst (2):
>       ARM: Enable selection of SMP operations at boot time
>       ARM: vexpress: Select multi-cluster SMP operation if required
> 
> Joseph Lo (12):
>       ARM: tegra: add an assembly marco to check Tegra SoC ID
>       ARM: tegra: skip SCU and PL310 code when CPU is not Cortex-A9
>       ARM: tegra: make tegra_resume can work for Tegra114
>       ARM: tegra114: add power up sequence for warm boot CPU
>       clk: tegra114: implement wait_for_reset and disable_clock for tegra_cpu_car_ops
>       ARM: tegra114: add CPU hotplug support
>       ARM: tegra: add cpu_disable for hotplug
>       ARM: tegra: remove ifdef in the tegra_resume
>       ARM: tegra: cpuidle: move the init function behind the suspend init function
>       ARM: tegra: hook tegra_tear_down_cpu function in the PM suspend init function
>       ARM: tegra: cpuidle: using IS_ENABLED for multi SoCs management in init func
>       ARM: tegra: don't pass CPU ID to tegra_{set,clear}_cpu_in_lp2
> 
> Koji Matsuoka (1):
>       sh-pfc: Initial r8a7790 PFC support
> 
> Kukjin Kim (1):
>       ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
> 
> Kuninori Morimoto (35):
>       gpio-rcar: R-Car GPIO IRQ share interrupt
>       ARM: shmobile: add GPIO IRQ macro
>       ARM: shmobile: r8a7778: Register PFC device
>       sh-pfc: Add r8a7778 pinmux support
>       sh-pfc: r8a7779: use RCAR_GP_PIN() on _GP_GPIO() macro
>       sh-pfc: r8a7778: add common PFC macro helper
>       sh-pfc: r8a7778: add SDHI support
>       sh-pfc: r8a7778: tidyup SDHI naming suffixes and sort it alphabetically
>       ARM: shmobile: r8a7778: add GPIO support
>       sh-pfc: r8a7778: fixup IRQ1A settings
>       sh-pfc: r8a7778: add I2C pin groups
>       sh-pfc: r8a7778: add HSPI pin groups
>       sh-pfc: r8a7778: add MMCIF pin groups
>       ARM: shmobile: kzm9g: tidyup FSI pinctrl
>       ARM: shmobile: bockw: add pinctrl support
>       ARM: shmobile: remove ";" from SH_FIXED_RATIO_CLK*() macro
>       ARM: shmobile: use do{ }while() on SH_CLK_SET_RATIO()
>       ARM: shmobile: r8a7778: fixup Ether setup code position
>       ARM: shmobile: r8a73a4: add main clock
>       ARM: shmobile: r8a73a4: add pll clocks
>       ARM: shmobile: r8a73a4: add div4 clocks
>       ARM: shmobile: r8a73a4: add div6 clocks
>       ARM: shmobile: r8a7778: use fixed ratio clock
>       ARM: shmobile: r8a7778: add SDHI clock support
>       ARM: shmobile: r8a7778: Register SDHI device
>       ARM: shmobile: r8a7790: add main clock
>       ARM: shmobile: r8a7790: add div4 clocks
>       ARM: shmobile: r8a7790: add div6 clocks
>       ARM: shmobile: r8a7778: add support I2C clock
>       ARM: shmobile: r8a7778: add support HSPI clock
>       ARM: shmobile: r8a7778: add support MMC clock
>       ARM: shmobile: r8a7778: add support I2C driver
>       ARM: shmobile: r8a7778: add support HSPI driver
>       ARM: shmobile: r8a7778: add support MMC driver
>       ARM: shmobile: Remove Bonito board support
> 
> Lad, Prabhakar (2):
>       ARM: davinci: remove __init atrribute from function declaration
>       ARM: edma: Convert to devm_* api
> 
> Laurent Pinchart (102):
>       gpio-rcar: Make the platform data gpio_base field signed
>       gpio-rcar: Add RCAR_GP_PIN macro
>       sh-pfc: Remove dependency on GPIOLIB
>       sh-pfc: r8a7790: Add ETH pin groups and functions
>       sh-pfc: r8a7790: Add INTC pin groups and functions
>       sh-pfc: r8a7790: Add SCIF, SCIFA and SCIFB pin groups and functions
>       sh-pfc: r8a7790: Remove GPIO data
>       sh-pfc: r8a7790: Remove function GPIOs
>       sh-pfc: r8a7790: Don't use GPIO enum entries
>       sh-pfc: r8a7779: Replace hardcoded pin numbers with RCAR_GP_PIN macro
>       sh-pfc: sh7372: Add BSC pin groups and functions
>       sh-pfc: sh7372: Add CEU pin groups and functions
>       sh-pfc: sh7372: Add FLCTL pin groups and functions
>       sh-pfc: sh7372: Add FSI pin groups and functions
>       sh-pfc: sh7372: Add HDMI pin groups and functions
>       sh-pfc: sh7372: Add INTC pin groups and functions
>       sh-pfc: sh7372: Add KEYSC pin groups and functions
>       sh-pfc: sh7372: Add LCDC pin groups and functions
>       sh-pfc: sh7372: Add SCIF pin groups and functions
>       sh-pfc: sh7372: Add USB pin groups and functions
>       ARM: shmobile: mackerel: Register pinctrl mapping for the ADXL34X
>       ARM: shmobile: mackerel: Register pinctrl mapping for CEU
>       ARM: shmobile: mackerel: Register pinctrl mapping for FLCTL
>       ARM: shmobile: mackerel: Register pinctrl mapping for FSI
>       ARM: shmobile: mackerel: Register pinctrl mapping for HDMI
>       ARM: shmobile: mackerel: Register pinctrl mapping for LCD
>       ARM: shmobile: mackerel: Register pinctrl mapping for SCIF
>       ARM: shmobile: mackerel: Register IRQ pinctrl mapping for SDHI0
>       ARM: shmobile: mackerel: Register pinctrl mapping for SMSC911x
>       ARM: shmobile: mackerel: Register pinctrl mapping for ST1232
>       ARM: shmobile: mackerel: Register pinctrl mapping for TCA6416
>       ARM: shmobile: mackerel: Register pinctrl mapping for USBHS
>       ARM: shmobile: ap4evb: Register pinctrl mapping for CEU
>       ARM: shmobile: ap4evb: Register pinctrl mapping for FSI
>       ARM: shmobile: ap4evb: Register pinctrl mapping for HDMI
>       ARM: shmobile: ap4evb: Register pinctrl mapping for KEYSC
>       ARM: shmobile: ap4evb: Register pinctrl mapping for LCD
>       ARM: shmobile: ap4evb: Register pinctrl mapping for SCIF
>       ARM: shmobile: ap4evb: Register pinctrl mapping for SMSC911x
>       ARM: shmobile: ap4evb: Simplify tsc2007 pen state read function
>       ARM: shmobile: ap4evb: Register pinctrl mapping for TSC2007
>       ARM: shmobile: ap4evb: Register pinctrl mapping for USBHS
>       sh-pfc: sh7372: Replace GPIO_PORTx enum with GPIO port numbers
>       sh-pfc: sh7372: Remove function GPIOs
>       ARM: shmobile: sh7372: Remove all GPIOs
>       sh-pfc: sh7372: Add bias (pull-up/down) pinconf support
>       sh-pfc: r8a7740: Add SCIF pin groups and functions
>       sh-pfc: r8a7740: Declare missing INTC function
>       sh-pfc: r8a7740: Add BSC pin groups and functions
>       sh-pfc: r8a7740: Add GETHER pin groups and functions
>       sh-pfc: r8a7740: Add CEU pin groups and functions
>       sh-pfc: r8a7740: Add FSI pin groups and functions
>       sh-pfc: r8a7740: Add HDMI pin groups and functions
>       sh-pfc: r8a7740: Hardcode the LCDC0 output
>       ARM: shmobile: armadillo800eva: Register pinctrl mapping for INTC
>       ARM: shmobile: armadillo800eva: Register pinctrl mapping for GETHER
>       ARM: shmobile: armadillo800eva: Register pinctrl mapping for CEU0
>       ARM: shmobile: armadillo800eva: Register pinctrl mapping for FSI
>       ARM: shmobile: armadillo800eva: Register pinctrl mapping for HDMI
>       ARM: shmobile: armadillo800eva: Don't configure LCDC routing manually
>       ARM: shmobile: armadillo800eva: Replace GPIO_PORTx with GPIO port numbers
>       ARM: shmobile: bonito: Remove empty core devices array
>       ARM: shmobile: bonito: Register pinctrl mapping for SCIF
>       ARM: shmobile: bonito: Register pinctrl mapping for INTC
>       ARM: shmobile: bonito: Register pinctrl mapping for BSC
>       ARM: shmobile: bonito: Don't configure LCDC routing manually
>       sh-pfc: r8a7740: Remove SCIF function GPIOS
>       sh-pfc: r8a7740: Remove INTC function GPIOS
>       sh-pfc: r8a7740: Remove BSC function GPIOS
>       sh-pfc: r8a7740: Remove GETHER function GPIOS
>       sh-pfc: r8a7740: Remove CEU function GPIOS
>       sh-pfc: r8a7740: Remove FSI function GPIOS
>       sh-pfc: r8a7740: Remove HDMI function GPIOS
>       ARM: shmobile: r8a7740: Remove SCIF function GPIOs
>       ARM: shmobile: r8a7740: Remove INTC function GPIOs
>       ARM: shmobile: r8a7740: Remove BSC function GPIOs
>       ARM: shmobile: r8a7740: Remove GETHER function GPIOs
>       ARM: shmobile: r8a7740: Remove CEU function GPIOs
>       ARM: shmobile: r8a7740: Remove FSI function GPIOs
>       ARM: shmobile: r8a7740: Remove HDMI function GPIOs
>       sh-pfc: r8a7740: Remove function GPIOs
>       sh-pfc: r8a7740: Replace GPIO_PORTx enum with GPIO port numbers
>       ARM: shmobile: r8a7740: Remove all GPIOs
>       sh-pfc: r8a7740: Add bias (pull-up/down) pinconf support
>       sh-pfc: r8a7778: Fix outdated GPIO_FN comments
>       ARM: shmobile: r8a7790: Register GPIO devices
>       ARM: shmobile: r8a7790: Remove all GPIOs
>       sh-pfc: Add support for SoC-specific initialization
>       sh-pfc: sh73a0: Add VCCQ MC0 regulator
>       ARM: shmobile: kzm9g: Remove the VCCQ MC0 function GPIO
>       ARM: shmobile: kzm9g-reference: Remove the VCCQ MC0 function GPIO
>       sh-pfc: sh73a0: Add TPU pin groups and functions
>       sh-pfc: r8a7740: Add TPU pin groups and functions
>       sh-pfc: r8a7790: Add TPU pin groups and functions
>       sh-pfc: sh73a0: Remove function GPIOs
>       Revert "ARM: shmobile: Disallow PINCTRL without GPIOLIB"
>       ARM: shmobile: lager: Initialize pinmux
>       ARM: shmobile: marzen: Use RCAR_GP_PIN macro
>       ARM: shmobile: r8a7740: Make private clock arrays static
>       ARM: shmobile: r8a7740: add TPU PWM support
>       ARM: shmobile: r8a7790: Make private clock arrays static
>       ARM: shmobile: r8a7790: add TPU PWM support
> 
> Leela Krishna Amudala (1):
>       ARM: EXYNOS: call scu_enable() only in case of cortex-A9 processor
> 
> Linus Walleij (51):
>       ARM: u300: enable delaytimer on the U300
>       ARM: u300: device tree support for the timer
>       pinctrl: u300 device tree support
>       pinctrl: coh901: add device tree support
>       ARM: u300: basic device tree support
>       i2c: stu300: device tree support
>       ARM: u300: register I2C bus drivers from device tree
>       watchdog: coh901327: devicetree support
>       ARM: u300: add the COH 901 327 watchdog to device tree
>       Documentation/devicetree: add a small note on PCI
>       ARM: pci: create pci_common_init_dev()
>       ARM: integrator: merge PCIv3 driver into one file
>       ARM: integrator: convert PCIv3 bridge to platform device
>       ARM: integrator: grab PCI error IRQ in probe()
>       ARM: integrator: move PCI base address grab to probe
>       ARM: integrator: move V3 register definitions into driver
>       ARM: integrator: remap PCIv3 base dynamically
>       ARM: integrator: move VGA base assignment
>       ARM: integrator: move static ioremapping into PCIv3 driver
>       ARM: integrator: basic PCIv3 device tree support
>       rtc: coh901331: add devicetree support
>       ARM: u300: add RTC to device tree
>       ARM: u300: set up board power from device tree
>       ARM: u300: support regulators in the device tree
>       ARM: u300: enable MMC/SD card from device tree
>       dma: coh901318: add devicetree support
>       ARM: u300: augment device tree with DMA channels
>       ARM: u300: add the COH 901 318 DMAC to device tree
>       ARM: u300: add SPI PL022 to the device tree
>       ARM: u300: probe the U300 dummy-spichip from device tree
>       ARM: u300: add FSMC flash into the device tree
>       ARM: u300: delete all static board data
>       ARM: u300: move debugmacro to debug includes
>       ARM: u300: remove deps from debug macro
>       ARM: u300: push down syscon registers
>       ARM: u300: delete <mach/hardware.h>
>       ARM: u300: delete <mach/irqs.h>
>       ARM: u300: localize <mach/u300-regs.h>
>       ARM: u300: convert to multiplatform
>       ARM: u300: delete remnant machine headers
>       ARM: u300: add syscon node
>       ARM: u300: remove register definition file
>       clk: move the U300 fixed and fixed-factor to DT
>       i2c: stu300: do not request a specific clock name
>       ARM: u300: move the gated system controller clocks to DT
>       ARM: u300: convert MMC/SD clock to device tree
>       pinctrl: get rid of all platform data for coh901
>       spi: pl022: use DMA by default when probing from DT
>       ARM: u300: switch to using syscon regmap for board
>       ARM: integrator: set local side PCI addresses right
>       ARM: integrator: let pciv3 use mem/premem from device tree
> 
> Lorenzo Pieralisi (1):
>       drivers: bus: add ARM CCI support
> 
> Magnus Damm (17):
>       ARM: shmobile: r8a7779 pinmux platform device cleanup
>       ARM: shmobile: r8a7740 pinmux platform device cleanup
>       ARM: shmobile: sh73a0: Always use shmobile_setup_delay()
>       ARM: shmobile: uImage load address rework
>       ARM: shmobile: Let romImage rely on default ATAGS
>       ARM: shmobile: Remove romImage CONFIG_MEMORY_START
>       ARM: shmobile: Rework sh7372 sleep code to use virt_to_phys()
>       ARM: shmobile: Add SMP boot function and argument
>       ARM: shmobile: Add SCU boot function using argument
>       ARM: shmobile: r8a7779 SMP with SCU boot fn and args
>       ARM: shmobile: sh73a0 SMP with SCU boot fn and args
>       ARM: shmobile: EMEV2 SMP with SCU boot fn and args
>       ARM: shmobile: Remove old SCU boot code
>       ARM: shmobile: Enable ARM_PATCH_PHYS_VIRT
>       ARM: shmobile: Remove MEMORY_START/SIZE
>       ARM: shmobile: Remove mach/memory.h
>       ARM: shmobile: Remove AP4EVB board support
> 
> Markus Pargmann (1):
>       ARM: imx: Remove mxc specific ulpi access ops
> 
> Martin Fuzzey (1):
>       ARM: i.MX5: Allow DT clock providers
> 
> Matt Porter (6):
>       ARM: davinci: move private EDMA API to arm/common
>       ARM: edma: remove unused transfer controller handlers
>       dmaengine: edma: Add TI EDMA device tree binding
>       ARM: edma: Add DT and runtime PM support to the private EDMA API
>       ARM: edma: Add EDMA crossbar event mux support
>       dmaengine: edma: enable build for AM33XX
> 
> Maxime Ripard (2):
>       ARM: sunxi: Add Allwinner A10s machine compatible
>       ARM: multi_v7: Enable Allwinner EMAC in multi_v7_defconfig
> 
> Mohammed, Afzal (1):
>       ARM: OMAP2+: AM43x: resolve SMP related build error
> 
> Nicolas Pitre (4):
>       drivers/bus: arm-cci: function to enable CCI ports from early boot code
>       ARM: vexpress: introduce DCSCB support
>       ARM: vexpress/dcscb: add CPU use counts to the power up/down API implementation
>       ARM: vexpress/dcscb: do not hardcode number of CPUs per cluster
> 
> Nicolin Chen (2):
>       ARM: clk-imx6qdl: Add clko1 configuration for imx6qdl-sabresd
>       ARM: imx_v6_v7_defconfig: Enable imx-wm8962 by default
> 
> Nishanth Menon (1):
>       ARM: OMAP5: voltagedomain data: remove temporary OMAP4 voltage data
> 
> Olof Johansson (22):
>       Merge tag 'soc-3.11-2' of git://git.infradead.org/users/jcooper/linux into next/soc
>       Merge tag 'defconfig-3.11-3' of git://git.infradead.org/users/jcooper/linux into next/soc
>       Merge tag 'pcie-3.11-2' of git://git.infradead.org/users/jcooper/linux into next/soc
>       Merge tag 'pcie_kw-3.11' of git://git.infradead.org/users/jcooper/linux into next/soc
>       Merge tag 'pcie_bridge-3.11' of git://git.infradead.org/users/jcooper/linux into next/soc
>       Merge tag 'seb_clk-3.11' of git://git.infradead.org/users/jcooper/linux into next/soc
>       Merge branch 'depends/rmk-devel-stable' into next/soc
>       Merge branch 'VExpress_DCSCB' of git://git.linaro.org/people/nico/linux into next/soc
>       Merge tag 'zynq-clk-for-3.11' of git://git.xilinx.com/linux-xlnx into next/soc
>       Merge tag 'pcie_kw-3.11-2' of git://git.infradead.org/users/jcooper/linux into next/soc
>       Merge tag 'renesas-pinmux-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/soc
>       Merge tag 'renesas-soc-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/soc
>       Merge branch 'clps711x/soc' into next/soc
>       Merge tag 's3c24xx-arch-1' of git://git.kernel.org/.../kgene/linux-samsung into next/soc
>       Merge tag 'omap-for-v3.11/pm-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/soc
>       Merge tag 'omap-for-v3.11/soc-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/soc
>       Merge tag 'omap-for-v3.11/omap5-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/soc
>       Merge tag 'regmap-3.11' of git://git.infradead.org/users/jcooper/linux into next/soc
>       Merge tag 'renesas-phy-rcar-usb-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/soc
>       Merge tag 'renesas-soc2-for-v3.11' of git://git.kernel.org/.../horms/renesas into next/soc
>       Merge tag 'tegra-for-3.11-soc' of git://git.kernel.org/.../swarren/linux-tegra into next/soc
>       Merge tag 'keystone-soc-for-arm-soc' of git://git.kernel.org/.../ssantosh/linux-keystone into next/soc
> 
> Peter Huewe (1):
>       ARM: u300 use module_spi_driver to register driver
> 
> Phil Edworthy (2):
>       pinctrl: sh-pfc: r8a7779: Fix missing MOD_SEL2 entry
>       ARM: shmobile: r8a7779: Add PCIe clocks
> 
> Philip Avinash (1):
>       ARM: AM33XX: clk: Add clock node for EHRPWM TBCLK
> 
> Philipp Zabel (1):
>       ARM i.MX5: Add S/PDIF clocks
> 
> Rob Herring (1):
>       ARM: introduce common set_auxcr/get_auxcr functions
> 
> Roger Quadros (1):
>       ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
> 
> Rogerio Pimentel (1):
>       ARM: imx_v6_v7_defconfig: enable parallel display
> 
> Russell King (2):
>       Merge branch 'for-next' of git://git.pengutronix.de/git/ukl/linux into devel-stable
>       Merge tag '3.10-rc2-psci-ops-11-tag' of git://git.kernel.org/.../sstabellini/xen into devel-stable
> 
> Sanjeev Premi (1):
>       ARM: OMAP2+: AM43x: SRAM base and size
> 
> Santosh Shilimkar (13):
>       ARM: OMAP4: PM: Avoid expensive cpu_suspend() path for all CPU power states except off
>       ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
>       ARM: OMAP4+: Make secondary_startup function name more consistent
>       ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
>       ARM: OMAP4+: PRM: Move function prototypes to common header for re-use
>       ARM: OMAP4+: CM: Move function prototypes to common header for re-use
>       ARM: OMAP4+: PRCM MPU: Move function prototypes to common header for re-use
>       ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data
>       ARM: OMAP5: Enable build and frameowrk initialisations
>       ARM: dts: keystone: Add minimal Keystone SOC device tree data
>       ARM: keystone: Add minimal TI Keystone platform support
>       ARM: keystone: Enable SMP support on Keystone machines
>       ARM: keystone: Move CPU bringup code to dedicated asm file
> 
> Sascha Hauer (1):
>       ARM i.MX53: Add SATA clock
> 
> Sebastian Hesselbarth (10):
>       clk: mvebu: introduce per-clock-gate flags
>       clk: mvebu: add common clock functions for core clk and clk gating
>       clk: mvebu: add Dove SoC-centric clock init
>       clk: mvebu: add Kirkwood SoC-centric clock init
>       clk: mvebu: add Armada 370 SoC-centric clock init
>       clk: mvebu: add Armada XP SoC-centric clock init
>       ARM: dove: move DT boards to SoC-centric clock init
>       ARM: kirkwood: move DT boards to SoC-centric clock init
>       ARM: mvebu: move DT boards to SoC-centric clock init
>       clk: mvebu: disintegrate obsolete file
> 
> Sergei Shtylyov (18):
>       sh-pfc: r8a7778: add USB pin groups
>       sh-pfc: r8a7778: add Ether pin groups
>       sh-pfc: r8a7779: add Ether pin groups
>       ARM: shmobile: r8a7778: correct model name in Kconfig
>       ARM: shmobile: r8a7779: fix Ether device name
>       ARM: shmobile: r8a7778: fix Ether device name
>       ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
>       ehci-platform: add pre_setup() method to platform data
>       ARM: shmobile: r8a7779: setup EHCI internal buffer
>       phy-rcar-usb: remove EHCI internal buffer setup
>       ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource
>       phy-rcar-usb: correct base address
>       phy-rcar-usb: add platform data
>       ARM: shmobile: Marzen: pass platform data to USB PHY device
>       phy-rcar-usb: handle platform data
>       phy-rcar-usb: add R8A7778 support
>       ARM: shmobile: r8a7778: add USB support
>       ARM: shmobile: BOCK-W: add USB support
> 
> Shawn Guo (8):
>       ARM: imx: include <asm/io.h> in hardware.h
>       ARM: imx: move clk_prepare() out from mxc_restart()
>       ARM: imx: create mxc_arch_reset_init_dt() for DT boot
>       ARM: imx: add clock support for imx6sl
>       ARM: imx: enable low-level debug support for imx6sl
>       ARM: imx: add initial support for imx6sl
>       ARM: imx6q: call of_clk_init() to register fixed rate clocks
>       ARM: imx6: use common of_clk_init() call to initialize clocks
> 
> Simon Horman (4):
>       gpio-rcar: Add support for IRQ_TYPE_EDGE_BOTH
>       ARM: shmobile: r8a7790: Configure R-Car GPIO for IRQ_TYPE_EDGE_BOTH
>       ARM: shmobile: sh73a0: Use DEFINE_RES_MEM*() everywhere
>       Merge branches 'heads/pinmux' and 'heads/soc' into phy-rcar-usb-base
> 
> Soren Brinkmann (4):
>       clk: zynq: Factor out PLL driver
>       clk: zynq: Add clock controller driver
>       arm: zynq: Migrate platform to clock controller
>       clk: zynq: Remove deprecated clock code
> 
> Stefano Stabellini (1):
>       arm: introduce psci_smp_ops
> 
> Thomas Petazzoni (27):
>       arm: kirkwood: use the default of match table
>       arm: mvebu: update defconfig with PCI and USB support
>       clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
>       clk: mvebu: add more PCIe clocks for Armada XP
>       pci: PCIe driver for Marvell Armada 370/XP systems
>       arm: mvebu: PCIe support is now available on mvebu
>       arm: kirkwood: update defconfig with PCIe driver and board updates
>       pci: mvebu: no longer fake the slot location of downstream devices
>       pci: mvebu: allow the enumeration of devices beyond physical bridges
>       pci: mvebu: fix the emulation of the status register
>       pci: mvebu: enable driver usage on Kirkwood
>       arm: kirkwood: move PCIe window init to legacy driver
>       arm: kirkwood: add SoC-level Device Tree data for PCIe interfaces
>       arm: kirkwood: convert Iomega Iconnect to use DT for the PCIe interface
>       arm: kirkwood: convert MPL CEC4 to use DT for the PCIe interface
>       arm: kirkwood: convert ZyXEL NSA310 to use DT for the PCIe interface
>       arm: kirkwood: convert QNAP TS219 to use DT for the PCIe interface
>       arm: kirkwood: convert db-88f6281/db-88f6282 to the Device Tree
>       arm: mvebu: remove dependency of SMP init on static I/O mapping
>       arm: mvebu: avoid hardcoded virtual address in coherency code
>       arm: mvebu: move cache and mvebu-mbus initialization later
>       arm: mvebu: remove hardcoded static I/O mapping
>       arm: mvebu: don't hardcode a physical address in headsmp.S
>       arm: mvebu: don't hardcode the physical address for mvebu-mbus
>       arm: mvebu: add another earlyprintk Kconfig option
>       arm: mvebu: disable DEBUG_LL/EARLY_PRINTK in defconfig
>       arm: mvebu: fix coherency_late_init() for multiplatform
> 
> Tomasz Figa (30):
>       ARM: EXYNOS: Remove unused board files
>       ARM: EXYNOS: Make ARCH_EXYNOS select USE_OF
>       ARM: SAMSUNG: Introduce SAMSUNG_ATAGS Kconfig entry
>       ARM: EXYNOS: Remove legacy PMU initialization code
>       ARM: EXYNOS: Remove legacy EINT initialization code
>       ARM: EXYNOS: Remove legacy UART initialization code
>       ARM: EXYNOS: Remove legacy dev- and setup- files
>       ARM: EXYNOS: Remove legacy interrupt initialization code
>       ARM: EXYNOS: Remove legacy timer initialization code
>       ARM: EXYNOS: Remove platform device initialization
>       ARM: EXYNOS: Remove legacy mapping of chip ID block
>       ARM: EXYNOS: Remove check for device tree presence
>       ARM: EXYNOS: Remove legacy power domain registration code
>       ARM: SAMSUNG: Introduce GPIO_SAMSUNG Kconfig entry
>       ARM: EXYNOS: Provide compatibility stubs for PM code in pm-core.h header
>       ARM: SAMSUNG: Compile legacy IRQ and GPIO PM code only with ATAGS support
>       platform: Check for ARCH_EXYNOS separately
>       USB: Check for ARCH_EXYNOS separately
>       ARM: EXYNOS: Decouple ARCH_EXYNOS from PLAT_S5P
>       ARM: SAMSUNG: Include most of mach/ headers conditionally
>       ARM: EXYNOS: Do not select legacy Kconfig symbols any more
>       ARM: EXYNOS: Remove setup-i2c0.c
>       ARM: EXYNOS: Remove mach/gpio.h
>       ARM: EXYNOS: Remove mach/regs-gpio.h header
>       ARM: SAMSUNG: Make legacy MFC support code depend on SAMSUNG_ATAGS
>       ARM: EXYNOS: Select SPARSE_IRQ for Exynos
>       ARM: EXYNOS: Remove mach/irqs.h header
>       ARM: EXYNOS: Remove unused base addresses from mach/map.h header
>       thermal: exynos: Support both EXYNOS4X12 SoCs
>       ARM: EXYNOS: Remove mach/regs-usb-phy.h header
> 
> Tony Lindgren (4):
>       Merge tag 'omap-pm-v3.10/cleanup/pm' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-v3.11/pm
>       Merge tag 'omap-devel-b-for-3.11' of http://git.kernel.org/cgit/linux/kernel/git/pjw/omap-pending into omap-for-v3.11/soc
>       Merge tag 'omap-devel-a-for-3.11' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.11/omap5
>       ARM: OMAP5: Remove unused include for ocp2scp
> 
> Tushar Behera (1):
>       ARM: exynos_defconfig: Enable GPIO buttons and RTC drivers
> 
> Ulf Hansson (1):
>       ARM: u300: Update MMC configs for u300 defconfig
> 
> Ulrich Hecht (1):
>       ARM: shmobile: r8a7790: HSCIF support
> 
> Uwe Kleine-K?nig (3):
>       ARM: ARMv7-M: Add support for exception handling
>       ARM: ARMv7-M: Allow the building of new kernel port
>       ARM: ARMv7-M: implement read_cpuid_ext
> 
> Vaibhav Hiremath (2):
>       ARM: OMAP2+: AM33xx: Add missing reset status info to GFX hwmod
>       ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature
> 
> Vivek Gautam (1):
>       ARM: EXYNOS: Enable XHCI support on exynos5
> 
> Vladimir Barinov (2):
>       sh-pfc: r8a7779: add VIN pin groups
>       sh-pfc: r8a7778: add VIN pin groups
> 
> Wei Yongjun (1):
>       pci: mvebu: fix return value check in mvebu_pcie_probe()
> 
>  Documentation/arm/sunxi/README                     |    4 +
>  Documentation/devicetree/bindings/arm/cci.txt      |  172 +
>  .../devicetree/bindings/arm/keystone/keystone.txt  |   10 +
>  .../devicetree/bindings/arm/rtsm-dcscb.txt         |   19 +
>  Documentation/devicetree/bindings/arm/ste-u300.txt |   46 +
>  .../devicetree/bindings/clock/imx5-clock.txt       |   13 +
>  .../devicetree/bindings/clock/imx6q-clock.txt      |    1 +
>  .../devicetree/bindings/clock/imx6sl-clock.txt     |   10 +
>  .../bindings/clock/ste-u300-syscon-clock.txt       |   80 +
>  .../devicetree/bindings/clock/vf610-clock.txt      |   26 +
>  .../devicetree/bindings/clock/zynq-7000.txt        |  123 +-
>  .../devicetree/bindings/dma/ste-coh901318.txt      |   32 +
>  Documentation/devicetree/bindings/dma/ti-edma.txt  |   34 +
>  .../devicetree/bindings/gpio/gpio-clps711x.txt     |   28 +
>  .../bindings/gpio/gpio-stericsson-coh901.txt       |    7 +
>  .../devicetree/bindings/i2c/i2c-st-ddci2c.txt      |   15 +
>  .../devicetree/bindings/pci/designware-pcie.txt    |   73 +
>  .../devicetree/bindings/pci/mvebu-pci.txt          |  221 ++
>  Documentation/devicetree/bindings/pci/pci.txt      |    9 +
>  .../devicetree/bindings/pci/v3-v360epc-pci.txt     |   15 +
>  Documentation/devicetree/bindings/rtc/dw-apb.txt   |   19 +
>  .../bindings/timer/stericsson-u300-apptimer.txt    |   18 +
>  .../devicetree/bindings/vendor-prefixes.txt        |    1 +
>  .../bindings/watchdog/stericsson-coh901327.txt     |   19 +
>  arch/arm/Kconfig                                   |   64 +-
>  arch/arm/Kconfig-nommu                             |    2 +-
>  arch/arm/Kconfig.debug                             |  101 +-
>  arch/arm/Makefile                                  |    4 +
>  arch/arm/boot/compressed/head-shmobile.S           |   21 +-
>  arch/arm/boot/dts/Makefile                         |    3 +
>  arch/arm/boot/dts/exynos5440-ssdk5440.dts          |    8 +
>  arch/arm/boot/dts/exynos5440.dtsi                  |   40 +-
>  arch/arm/boot/dts/integratorap.dts                 |   41 +
>  arch/arm/boot/dts/keystone.dts                     |  117 +
>  arch/arm/boot/dts/kirkwood-6281.dtsi               |   31 +
>  arch/arm/boot/dts/kirkwood-6282.dtsi               |   48 +
>  arch/arm/boot/dts/kirkwood-db-88f6281.dts          |   30 +
>  arch/arm/boot/dts/kirkwood-db-88f6282.dts          |   34 +
>  arch/arm/boot/dts/kirkwood-db.dtsi                 |   89 +
>  arch/arm/boot/dts/kirkwood-iconnect.dts            |    8 +
>  arch/arm/boot/dts/kirkwood-mplcec4.dts             |    8 +
>  .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  |    8 +
>  arch/arm/boot/dts/kirkwood-nsa310.dts              |    8 +
>  arch/arm/boot/dts/kirkwood-ts219-6281.dts          |    3 +-
>  arch/arm/boot/dts/kirkwood-ts219-6282.dts          |    3 +-
>  arch/arm/boot/dts/kirkwood-ts219.dtsi              |    9 +-
>  arch/arm/boot/dts/kirkwood.dtsi                    |    1 +
>  arch/arm/boot/dts/rk3066a-clocks.dtsi              |  299 ++
>  arch/arm/boot/dts/rk3066a.dtsi                     |  390 ++
>  arch/arm/boot/dts/ste-u300.dts                     |  473 +++
>  arch/arm/boot/dts/zynq-7000.dtsi                   |   71 +-
>  arch/arm/boot/dts/zynq-zc702.dts                   |    4 -
>  arch/arm/common/Kconfig                            |    3 +
>  arch/arm/common/Makefile                           |    1 +
>  arch/arm/{mach-davinci/dma.c => common/edma.c}     |  368 +-
>  arch/arm/configs/ap4evb_defconfig                  |   56 -
>  arch/arm/configs/bonito_defconfig                  |   72 -
>  arch/arm/configs/clps711x_defconfig                |    8 +-
>  arch/arm/configs/exynos_defconfig                  |    3 +
>  arch/arm/configs/imx_v6_v7_defconfig               |   10 +
>  arch/arm/configs/keystone_defconfig                |  157 +
>  arch/arm/configs/kirkwood_defconfig                |   10 +-
>  arch/arm/configs/multi_v7_defconfig                |    2 +
>  arch/arm/configs/mvebu_defconfig                   |    6 +-
>  arch/arm/configs/u300_defconfig                    |   14 +-
>  arch/arm/include/asm/assembler.h                   |   17 +-
>  arch/arm/include/asm/cp15.h                        |   14 +
>  arch/arm/include/asm/cputype.h                     |   44 +-
>  arch/arm/include/asm/glue-cache.h                  |   27 +
>  arch/arm/include/asm/glue-df.h                     |    8 +
>  arch/arm/include/asm/glue-proc.h                   |    9 +
>  arch/arm/include/asm/hardware/pci_v3.h             |  186 -
>  arch/arm/include/asm/irqflags.h                    |   22 +-
>  arch/arm/include/asm/mach/arch.h                   |    5 +
>  arch/arm/include/asm/mach/pci.h                    |   17 +-
>  arch/arm/include/asm/psci.h                        |    9 +
>  arch/arm/include/asm/ptrace.h                      |    4 +
>  arch/arm/include/asm/system_info.h                 |    1 +
>  arch/arm/include/asm/v7m.h                         |   44 +
>  arch/arm/include/debug/imx-uart.h                  |   10 +
>  arch/arm/include/debug/keystone.S                  |   43 +
>  arch/arm/include/debug/mvebu.S                     |    5 +
>  arch/arm/include/debug/rockchip.S                  |   42 +
>  .../mach/debug-macro.S => include/debug/u300.S}    |    9 +-
>  arch/arm/include/uapi/asm/ptrace.h                 |   35 +-
>  arch/arm/kernel/Makefile                           |   13 +-
>  arch/arm/kernel/bios32.c                           |    9 +-
>  arch/arm/kernel/entry-common.S                     |    4 +
>  arch/arm/kernel/entry-header.S                     |  124 +
>  arch/arm/kernel/entry-v7m.S                        |  143 +
>  arch/arm/kernel/head-nommu.S                       |   10 +-
>  arch/arm/kernel/psci.c                             |    7 +-
>  arch/arm/kernel/psci_smp.c                         |   84 +
>  arch/arm/kernel/setup.c                            |   26 +-
>  arch/arm/kernel/traps.c                            |    8 +
>  arch/arm/mach-clps711x/Kconfig                     |    3 +-
>  arch/arm/mach-clps711x/Makefile                    |    5 +-
>  arch/arm/mach-clps711x/board-autcpu12.c            |  133 +-
>  arch/arm/mach-clps711x/board-cdb89712.c            |    3 +
>  arch/arm/mach-clps711x/board-clep7312.c            |    1 +
>  arch/arm/mach-clps711x/board-edb7211.c             |   34 +-
>  arch/arm/mach-clps711x/board-fortunet.c            |    1 +
>  arch/arm/mach-clps711x/board-p720t.c               |  254 +-
>  arch/arm/mach-clps711x/common.c                    |   89 +-
>  arch/arm/mach-clps711x/common.h                    |    1 +
>  arch/arm/mach-clps711x/devices.c                   |   68 +
>  arch/arm/mach-clps711x/devices.h                   |   12 +
>  arch/arm/mach-clps711x/include/mach/autcpu12.h     |   59 -
>  arch/arm/mach-clps711x/include/mach/clps711x.h     |   88 +-
>  arch/arm/mach-clps711x/include/mach/hardware.h     |    7 -
>  arch/arm/mach-clps711x/include/mach/memory.h       |   41 -
>  arch/arm/mach-clps711x/include/mach/syspld.h       |  116 -
>  arch/arm/mach-davinci/Makefile                     |    2 +-
>  arch/arm/mach-davinci/board-tnetv107x-evm.c        |    2 +-
>  arch/arm/mach-davinci/davinci.h                    |   30 +-
>  arch/arm/mach-davinci/devices-da8xx.c              |    8 +-
>  arch/arm/mach-davinci/devices-tnetv107x.c          |    6 +-
>  arch/arm/mach-davinci/devices.c                    |    6 +-
>  arch/arm/mach-davinci/dm355.c                      |    6 +-
>  arch/arm/mach-davinci/dm365.c                      |    6 +-
>  arch/arm/mach-davinci/dm644x.c                     |    6 +-
>  arch/arm/mach-davinci/dm646x.c                     |    6 +-
>  arch/arm/mach-davinci/include/mach/cp_intc.h       |    4 +-
>  arch/arm/mach-davinci/include/mach/da8xx.h         |   18 +-
>  arch/arm/mach-davinci/include/mach/tnetv107x.h     |    6 +-
>  arch/arm/mach-dove/Kconfig                         |    3 +-
>  arch/arm/mach-dove/board-dt.c                      |    3 +-
>  arch/arm/mach-dove/common.c                        |    1 -
>  arch/arm/mach-exynos/Kconfig                       |  352 +-
>  arch/arm/mach-exynos/Makefile                      |   33 -
>  arch/arm/mach-exynos/common.c                      |  547 +--
>  arch/arm/mach-exynos/common.h                      |    4 +-
>  arch/arm/mach-exynos/dev-ahci.c                    |  255 --
>  arch/arm/mach-exynos/dev-audio.c                   |  254 --
>  arch/arm/mach-exynos/dev-ohci.c                    |   52 -
>  arch/arm/mach-exynos/dev-uart.c                    |   55 -
>  arch/arm/mach-exynos/dma.c                         |  322 --
>  arch/arm/mach-exynos/firmware.c                    |   22 +-
>  arch/arm/mach-exynos/include/mach/gpio.h           |  289 --
>  arch/arm/mach-exynos/include/mach/irqs.h           |  476 ---
>  arch/arm/mach-exynos/include/mach/map.h            |  214 --
>  arch/arm/mach-exynos/include/mach/pm-core.h        |   12 +-
>  arch/arm/mach-exynos/include/mach/regs-gpio.h      |   40 -
>  arch/arm/mach-exynos/include/mach/regs-usb-phy.h   |   74 -
>  arch/arm/mach-exynos/mach-armlex4210.c             |  207 --
>  arch/arm/mach-exynos/mach-exynos4-dt.c             |    8 +-
>  arch/arm/mach-exynos/mach-exynos5-dt.c             |    8 +-
>  arch/arm/mach-exynos/mach-nuri.c                   | 1388 -------
>  arch/arm/mach-exynos/mach-origen.c                 |  823 -----
>  arch/arm/mach-exynos/mach-smdk4x12.c               |  396 --
>  arch/arm/mach-exynos/mach-smdkv310.c               |  444 ---
>  arch/arm/mach-exynos/mach-universal_c210.c         | 1159 ------
>  arch/arm/mach-exynos/platsmp.c                     |    2 +-
>  arch/arm/mach-exynos/pm.c                          |    1 -
>  arch/arm/mach-exynos/pm_domains.c                  |  101 +-
>  arch/arm/mach-exynos/setup-fimc.c                  |   44 -
>  arch/arm/mach-exynos/setup-fimd0.c                 |   43 -
>  arch/arm/mach-exynos/setup-i2c0.c                  |   29 -
>  arch/arm/mach-exynos/setup-i2c1.c                  |   23 -
>  arch/arm/mach-exynos/setup-i2c2.c                  |   23 -
>  arch/arm/mach-exynos/setup-i2c3.c                  |   23 -
>  arch/arm/mach-exynos/setup-i2c4.c                  |   23 -
>  arch/arm/mach-exynos/setup-i2c5.c                  |   23 -
>  arch/arm/mach-exynos/setup-i2c6.c                  |   23 -
>  arch/arm/mach-exynos/setup-i2c7.c                  |   23 -
>  arch/arm/mach-exynos/setup-keypad.c                |   36 -
>  arch/arm/mach-exynos/setup-sdhci-gpio.c            |  152 -
>  arch/arm/mach-exynos/setup-spi.c                   |   45 -
>  arch/arm/mach-exynos/setup-usb-phy.c               |  223 --
>  arch/arm/mach-imx/Kconfig                          |   65 +-
>  arch/arm/mach-imx/Makefile                         |    4 +-
>  arch/arm/mach-imx/clk-imx51-imx53.c                |   73 +-
>  arch/arm/mach-imx/clk-imx6q.c                      |   48 +-
>  arch/arm/mach-imx/clk-imx6sl.c                     |  267 ++
>  arch/arm/mach-imx/clk-pllv3.c                      |   10 -
>  arch/arm/mach-imx/clk-vf610.c                      |  319 ++
>  arch/arm/mach-imx/clk.c                            |   35 +
>  arch/arm/mach-imx/clk.h                            |    4 +-
>  arch/arm/mach-imx/common.h                         |    2 +-
>  arch/arm/mach-imx/hardware.h                       |    1 +
>  arch/arm/mach-imx/imx25-dt.c                       |    2 +
>  arch/arm/mach-imx/imx27-dt.c                       |    2 +
>  arch/arm/mach-imx/imx31-dt.c                       |    2 +
>  arch/arm/mach-imx/imx51-dt.c                       |    2 +
>  arch/arm/mach-imx/irq-common.c                     |    1 +
>  arch/arm/mach-imx/mach-imx53.c                     |    3 +
>  arch/arm/mach-imx/mach-imx6q.c                     |   81 +-
>  arch/arm/mach-imx/mach-imx6sl.c                    |   52 +
>  arch/arm/mach-imx/mach-pca100.c                    |    4 +-
>  arch/arm/mach-imx/mach-vf610.c                     |   48 +
>  arch/arm/mach-imx/mm-imx1.c                        |    2 +-
>  arch/arm/mach-imx/mm-imx21.c                       |    2 +-
>  arch/arm/mach-imx/mm-imx25.c                       |    2 +-
>  arch/arm/mach-imx/mm-imx27.c                       |    2 +-
>  arch/arm/mach-imx/mm-imx3.c                        |    4 +-
>  arch/arm/mach-imx/mm-imx5.c                        |    3 +-
>  arch/arm/mach-imx/system.c                         |   47 +-
>  arch/arm/mach-imx/ulpi.c                           |  118 -
>  arch/arm/mach-imx/ulpi.h                           |   11 +-
>  arch/arm/mach-integrator/Makefile                  |    2 +-
>  arch/arm/mach-integrator/include/mach/platform.h   |   23 -
>  arch/arm/mach-integrator/integrator_ap.c           |   31 +-
>  arch/arm/mach-integrator/pci.c                     |  113 -
>  arch/arm/mach-integrator/pci_v3.c                  |  564 ++-
>  arch/arm/mach-integrator/pci_v3.h                  |    2 +
>  arch/arm/mach-keystone/Kconfig                     |   15 +
>  arch/arm/mach-keystone/Makefile                    |    6 +
>  arch/arm/mach-keystone/Makefile.boot               |    1 +
>  arch/arm/mach-keystone/keystone.c                  |   75 +
>  arch/arm/mach-keystone/keystone.h                  |   23 +
>  arch/arm/mach-keystone/platsmp.c                   |   43 +
>  arch/arm/mach-keystone/smc.S                       |   29 +
>  arch/arm/mach-kirkwood/Kconfig                     |   24 +-
>  arch/arm/mach-kirkwood/Makefile                    |    3 +-
>  arch/arm/mach-kirkwood/board-db88f628x-bp.c        |   24 +
>  arch/arm/mach-kirkwood/board-dt.c                  |   18 +-
>  arch/arm/mach-kirkwood/board-iconnect.c            |    8 -
>  arch/arm/mach-kirkwood/board-mplcec4.c             |    1 -
>  arch/arm/mach-kirkwood/board-nsa310.c              |   25 -
>  arch/arm/mach-kirkwood/board-readynas.c            |    1 -
>  arch/arm/mach-kirkwood/common.c                    |   47 +-
>  arch/arm/mach-kirkwood/common.h                    |    8 +
>  arch/arm/mach-kirkwood/db88f6281-bp-setup.c        |  108 -
>  arch/arm/mach-kirkwood/include/mach/bridge-regs.h  |    2 +
>  arch/arm/mach-kirkwood/pcie.c                      |   22 +
>  arch/arm/mach-mvebu/Kconfig                        |    7 +-
>  arch/arm/mach-mvebu/armada-370-xp.c                |   53 +-
>  arch/arm/mach-mvebu/armada-370-xp.h                |   10 -
>  arch/arm/mach-mvebu/coherency.c                    |   45 +-
>  arch/arm/mach-mvebu/coherency.h                    |    4 -
>  arch/arm/mach-mvebu/common.h                       |    2 +
>  arch/arm/mach-mvebu/headsmp.S                      |   16 +-
>  arch/arm/mach-mvebu/platsmp.c                      |   10 +-
>  arch/arm/mach-omap2/Kconfig                        |    9 +
>  arch/arm/mach-omap2/Makefile                       |   19 +-
>  arch/arm/mach-omap2/am33xx.h                       |    1 +
>  arch/arm/mach-omap2/board-generic.c                |   16 +
>  arch/arm/mach-omap2/cclock33xx_data.c              |   30 +
>  arch/arm/mach-omap2/cclock3xxx_data.c              |   11 -
>  arch/arm/mach-omap2/clockdomain.h                  |    1 +
>  arch/arm/mach-omap2/clockdomains54xx_data.c        |  464 +++
>  arch/arm/mach-omap2/cm-regbits-54xx.h              | 1737 +++++++++
>  arch/arm/mach-omap2/cm1_44xx.h                     |    7 +-
>  arch/arm/mach-omap2/cm1_54xx.h                     |  213 ++
>  arch/arm/mach-omap2/cm2_44xx.h                     |    7 +-
>  arch/arm/mach-omap2/cm2_54xx.h                     |  389 ++
>  arch/arm/mach-omap2/cm33xx.h                       |    2 +-
>  arch/arm/mach-omap2/cm_44xx_54xx.h                 |   36 +
>  arch/arm/mach-omap2/common.h                       |    5 +-
>  arch/arm/mach-omap2/control.h                      |   12 +
>  arch/arm/mach-omap2/id.c                           |   32 +-
>  arch/arm/mach-omap2/io.c                           |   25 +-
>  arch/arm/mach-omap2/omap-headsmp.S                 |    8 +-
>  arch/arm/mach-omap2/omap-mpuss-lowpower.c          |   69 +-
>  arch/arm/mach-omap2/omap-smp.c                     |    6 +-
>  arch/arm/mach-omap2/omap4-common.c                 |   16 -
>  arch/arm/mach-omap2/omap4-restart.c                |   27 +
>  arch/arm/mach-omap2/omap_hwmod.h                   |    1 +
>  arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    3 +-
>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c         | 2150 +++++++++++
>  arch/arm/mach-omap2/pm44xx.c                       |   58 +-
>  arch/arm/mach-omap2/powerdomain.h                  |    1 +
>  arch/arm/mach-omap2/powerdomains3xxx_data.c        |   62 +
>  arch/arm/mach-omap2/powerdomains54xx_data.c        |  331 ++
>  arch/arm/mach-omap2/prcm-common.h                  |   11 +
>  arch/arm/mach-omap2/prcm44xx.h                     |    6 +
>  arch/arm/mach-omap2/prcm_mpu44xx.h                 |   14 +-
>  arch/arm/mach-omap2/prcm_mpu54xx.h                 |   87 +
>  arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h           |   36 +
>  arch/arm/mach-omap2/prm-regbits-54xx.h             | 2701 ++++++++++++++
>  arch/arm/mach-omap2/prm44xx.h                      |   33 +-
>  arch/arm/mach-omap2/prm44xx_54xx.h                 |   58 +
>  arch/arm/mach-omap2/prm54xx.h                      |  421 +++
>  arch/arm/mach-omap2/scrm54xx.h                     |  231 ++
>  arch/arm/mach-omap2/soc.h                          |   26 +
>  arch/arm/mach-omap2/sram.c                         |    3 +
>  arch/arm/mach-omap2/timer.c                        |    2 +-
>  arch/arm/mach-omap2/voltage.h                      |    1 +
>  arch/arm/mach-omap2/voltagedomains54xx_data.c      |   92 +
>  arch/arm/mach-picoxcell/Kconfig                    |    1 -
>  arch/arm/mach-picoxcell/common.c                   |    2 -
>  arch/arm/mach-rockchip/Kconfig                     |   16 +
>  arch/arm/mach-rockchip/Makefile                    |    1 +
>  arch/arm/mach-rockchip/rockchip.c                  |   52 +
>  arch/arm/mach-s3c24xx/dma-s3c2412.c                |   56 +-
>  arch/arm/mach-s3c24xx/dma-s3c2443.c                |    3 +-
>  arch/arm/mach-s3c24xx/dma.c                        |    3 -
>  arch/arm/mach-shmobile/Kconfig                     |   65 +-
>  arch/arm/mach-shmobile/Makefile                    |    2 -
>  arch/arm/mach-shmobile/Makefile.boot               |   18 +-
>  arch/arm/mach-shmobile/board-ap4evb.c              | 1332 -------
>  arch/arm/mach-shmobile/board-armadillo800eva.c     |  116 +-
>  arch/arm/mach-shmobile/board-bockw.c               |   21 +
>  arch/arm/mach-shmobile/board-bonito.c              |  495 ---
>  arch/arm/mach-shmobile/board-kzm9g-reference.c     |    1 -
>  arch/arm/mach-shmobile/board-kzm9g.c               |   11 +-
>  arch/arm/mach-shmobile/board-lager.c               |   15 +
>  arch/arm/mach-shmobile/board-mackerel.c            |  171 +-
>  arch/arm/mach-shmobile/board-marzen.c              |  188 +-
>  arch/arm/mach-shmobile/clock-r8a73a4.c             |  387 +-
>  arch/arm/mach-shmobile/clock-r8a7740.c             |   11 +-
>  arch/arm/mach-shmobile/clock-r8a7778.c             |  183 +-
>  arch/arm/mach-shmobile/clock-r8a7779.c             |    4 +-
>  arch/arm/mach-shmobile/clock-r8a7790.c             |  255 +-
>  arch/arm/mach-shmobile/clock-sh73a0.c              |  111 +-
>  arch/arm/mach-shmobile/headsmp-scu.S               |   29 +-
>  arch/arm/mach-shmobile/headsmp.S                   |   13 +-
>  arch/arm/mach-shmobile/include/mach/clock.h        |    8 +-
>  arch/arm/mach-shmobile/include/mach/common.h       |    6 +-
>  .../arm/mach-shmobile/include/mach/head-ap4evb.txt |   93 -
>  arch/arm/mach-shmobile/include/mach/irqs.h         |    5 +
>  arch/arm/mach-shmobile/include/mach/memory.h       |    7 -
>  arch/arm/mach-shmobile/include/mach/mmc-ap4eb.h    |   29 -
>  arch/arm/mach-shmobile/include/mach/mmc.h          |    4 +-
>  arch/arm/mach-shmobile/include/mach/r8a7740.h      |  488 ---
>  arch/arm/mach-shmobile/include/mach/r8a7778.h      |   11 +
>  arch/arm/mach-shmobile/include/mach/r8a7779.h      |    3 +
>  arch/arm/mach-shmobile/include/mach/sh7372.h       |  393 +-
>  arch/arm/mach-shmobile/include/mach/zboot.h        |    6 +-
>  arch/arm/mach-shmobile/pm-sh7372.c                 |    3 +
>  arch/arm/mach-shmobile/setup-r8a7740.c             |   24 +-
>  arch/arm/mach-shmobile/setup-r8a7778.c             |  262 +-
>  arch/arm/mach-shmobile/setup-r8a7779.c             |  215 +-
>  arch/arm/mach-shmobile/setup-r8a7790.c             |   36 +-
>  arch/arm/mach-shmobile/setup-sh73a0.c              |   95 +-
>  arch/arm/mach-shmobile/sleep-sh7372.S              |    5 +-
>  arch/arm/mach-shmobile/smp-emev2.c                 |    6 +-
>  arch/arm/mach-shmobile/smp-r8a7779.c               |    6 +-
>  arch/arm/mach-shmobile/smp-sh73a0.c                |    6 +-
>  arch/arm/mach-socfpga/Kconfig                      |    2 +-
>  arch/arm/mach-socfpga/socfpga.c                    |    2 -
>  arch/arm/mach-sunxi/sunxi.c                        |    1 +
>  arch/arm/mach-tegra/Makefile                       |    1 +
>  arch/arm/mach-tegra/common.c                       |    2 +
>  arch/arm/mach-tegra/common.h                       |    1 +
>  arch/arm/mach-tegra/cpuidle-tegra20.c              |   10 +-
>  arch/arm/mach-tegra/cpuidle-tegra30.c              |   10 +-
>  arch/arm/mach-tegra/cpuidle.c                      |   19 +-
>  arch/arm/mach-tegra/cpuidle.h                      |   15 +-
>  arch/arm/mach-tegra/flowctrl.h                     |    1 +
>  arch/arm/mach-tegra/fuse.h                         |   22 +-
>  arch/arm/mach-tegra/hotplug.c                      |   13 +
>  arch/arm/mach-tegra/platsmp.c                      |   26 +-
>  arch/arm/mach-tegra/pm.c                           |   25 +-
>  arch/arm/mach-tegra/pm.h                           |    4 +-
>  arch/arm/mach-tegra/reset-handler.S                |   51 +-
>  arch/arm/mach-tegra/sleep-tegra30.S                |   30 +-
>  arch/arm/mach-tegra/sleep.S                        |    8 +-
>  arch/arm/mach-tegra/sleep.h                        |   35 +-
>  arch/arm/mach-tegra/tegra2_emc.c                   |    2 +-
>  arch/arm/mach-u300/Kconfig                         |   32 +-
>  arch/arm/mach-u300/Makefile                        |    2 -
>  arch/arm/mach-u300/core.c                          |  759 ++--
>  arch/arm/mach-u300/dummyspichip.c                  |   20 +-
>  arch/arm/mach-u300/i2c.c                           |  285 --
>  arch/arm/mach-u300/i2c.h                           |   23 -
>  arch/arm/mach-u300/include/mach/hardware.h         |    5 -
>  arch/arm/mach-u300/include/mach/irqs.h             |   80 -
>  arch/arm/mach-u300/include/mach/syscon.h           |  592 ---
>  arch/arm/mach-u300/include/mach/timex.h            |   17 -
>  arch/arm/mach-u300/include/mach/u300-regs.h        |  165 -
>  arch/arm/mach-u300/include/mach/uncompress.h       |   45 -
>  arch/arm/mach-u300/regulator.c                     |   67 +-
>  arch/arm/mach-u300/spi.c                           |  102 -
>  arch/arm/mach-u300/spi.h                           |   26 -
>  arch/arm/mach-u300/timer.c                         |  113 +-
>  arch/arm/mach-u300/timer.h                         |    1 -
>  arch/arm/mach-u300/u300-gpio.h                     |   70 -
>  arch/arm/mach-vexpress/Kconfig                     |    9 +
>  arch/arm/mach-vexpress/Makefile                    |    1 +
>  arch/arm/mach-vexpress/core.h                      |    2 +
>  arch/arm/mach-vexpress/dcscb.c                     |  253 ++
>  arch/arm/mach-vexpress/dcscb_setup.S               |   38 +
>  arch/arm/mach-vexpress/platsmp.c                   |   20 +
>  arch/arm/mach-vexpress/v2m.c                       |    1 +
>  arch/arm/mach-virt/Makefile                        |    1 -
>  arch/arm/mach-virt/platsmp.c                       |   50 -
>  arch/arm/mach-virt/virt.c                          |    3 -
>  arch/arm/mach-zynq/slcr.c                          |    2 +-
>  arch/arm/mm/Kconfig                                |   21 +-
>  arch/arm/mm/Makefile                               |    2 +
>  arch/arm/mm/cache-nop.S                            |   50 +
>  arch/arm/mm/nommu.c                                |    7 +
>  arch/arm/mm/proc-v7m.S                             |  157 +
>  arch/arm/plat-samsung/Kconfig                      |   47 +-
>  arch/arm/plat-samsung/Makefile                     |   11 +-
>  arch/arm/plat-samsung/include/plat/dma-s3c24xx.h   |    5 -
>  arch/arm/plat-samsung/include/plat/pm.h            |    5 +
>  arch/arm/plat-samsung/init.c                       |    8 +-
>  arch/arm/plat-samsung/pm-gpio.c                    |    5 +-
>  arch/arm/plat-samsung/pm.c                         |    8 +-
>  arch/arm/plat-samsung/s5p-dev-mfc.c                |   11 +-
>  drivers/bus/Kconfig                                |    7 +
>  drivers/bus/Makefile                               |    2 +
>  drivers/bus/arm-cci.c                              |  533 +++
>  drivers/clk/Makefile                               |    2 +-
>  drivers/clk/clk-u300.c                             |  718 +++-
>  drivers/clk/clk-zynq.c                             |  378 --
>  drivers/clk/mvebu/Kconfig                          |   25 +-
>  drivers/clk/mvebu/Makefile                         |    8 +-
>  drivers/clk/mvebu/armada-370.c                     |  176 +
>  drivers/clk/mvebu/armada-xp.c                      |  210 ++
>  drivers/clk/mvebu/clk-core.c                       |  675 ----
>  drivers/clk/mvebu/clk-core.h                       |   18 -
>  drivers/clk/mvebu/clk-gating-ctrl.c                |  250 --
>  drivers/clk/mvebu/clk-gating-ctrl.h                |   22 -
>  drivers/clk/mvebu/clk.c                            |   23 -
>  drivers/clk/mvebu/common.c                         |  163 +
>  drivers/clk/mvebu/common.h                         |   48 +
>  drivers/clk/mvebu/dove.c                           |  194 +
>  drivers/clk/mvebu/kirkwood.c                       |  247 ++
>  drivers/clk/socfpga/clk.c                          |  194 +-
>  drivers/clk/tegra/clk-tegra114.c                   |   23 +-
>  drivers/clk/zynq/Makefile                          |    3 +
>  drivers/clk/zynq/clkc.c                            |  533 +++
>  drivers/clk/zynq/pll.c                             |  235 ++
>  drivers/clocksource/Kconfig                        |    2 +
>  drivers/clocksource/cadence_ttc_timer.c            |   23 +-
>  drivers/clocksource/dw_apb_timer_of.c              |   95 +-
>  drivers/cpuidle/cpuidle-calxeda.c                  |   14 -
>  drivers/dma/Kconfig                                |    2 +-
>  drivers/dma/coh901318.c                            |   43 +
>  drivers/dma/edma.c                                 |    2 +-
>  drivers/gpio/Kconfig                               |   12 +-
>  drivers/gpio/Makefile                              |    2 +-
>  drivers/gpio/gpio-clps711x.c                       |  236 +-
>  drivers/gpio/gpio-rcar.c                           |   28 +-
>  drivers/i2c/busses/i2c-stu300.c                    |   16 +-
>  drivers/media/platform/Kconfig                     |    6 +-
>  drivers/media/platform/exynos4-is/Kconfig          |    3 +-
>  drivers/media/platform/s5p-tv/Kconfig              |    2 +-
>  drivers/mfd/syscon.c                               |    3 +
>  drivers/mmc/host/davinci_mmc.c                     |    1 +
>  drivers/mtd/maps/Kconfig                           |    7 -
>  drivers/mtd/maps/Makefile                          |    1 -
>  drivers/mtd/maps/autcpu12-nvram.c                  |  129 -
>  drivers/pci/Kconfig                                |    2 +
>  drivers/pci/Makefile                               |    3 +
>  drivers/pci/host/Kconfig                           |   17 +
>  drivers/pci/host/Makefile                          |    2 +
>  drivers/pci/host/pci-mvebu.c                       |  914 +++++
>  drivers/pci/host/pcie-designware.c                 | 1057 ++++++
>  drivers/pinctrl/Kconfig                            |    5 +-
>  drivers/pinctrl/pinctrl-coh901.c                   |   35 +-
>  drivers/pinctrl/pinctrl-u300.c                     |    7 +
>  drivers/pinctrl/sh-pfc/Kconfig                     |   13 +-
>  drivers/pinctrl/sh-pfc/Makefile                    |    2 +
>  drivers/pinctrl/sh-pfc/core.c                      |   22 +-
>  drivers/pinctrl/sh-pfc/core.h                      |    4 +
>  drivers/pinctrl/sh-pfc/pfc-r8a7740.c               | 1923 +++++++---
>  drivers/pinctrl/sh-pfc/pfc-r8a7778.c               | 2783 ++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-r8a7779.c               |  493 ++-
>  drivers/pinctrl/sh-pfc/pfc-r8a7790.c               | 3835 ++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7372.c                | 1652 ++++++---
>  drivers/pinctrl/sh-pfc/pfc-sh73a0.c                |  742 ++--
>  drivers/pinctrl/sh-pfc/sh_pfc.h                    |    4 +-
>  drivers/rtc/rtc-coh901331.c                        |    6 +
>  drivers/spi/spi-pl022.c                            |    1 +
>  drivers/thermal/exynos_thermal.c                   |    3 +-
>  drivers/tty/serial/xilinx_uartps.c                 |   85 +-
>  drivers/usb/Kconfig                                |    1 +
>  drivers/usb/host/Kconfig                           |    2 +-
>  drivers/usb/host/ehci-platform.c                   |    6 +
>  drivers/usb/phy/Kconfig                            |   10 +-
>  drivers/usb/phy/phy-rcar-usb.c                     |  128 +-
>  drivers/watchdog/coh901327_wdt.c                   |   12 +-
>  include/dt-bindings/clock/imx6sl-clock.h           |  148 +
>  include/dt-bindings/clock/vf610-clock.h            |  163 +
>  include/linux/arm-cci.h                            |   61 +
>  include/linux/clk/mvebu.h                          |   22 -
>  include/linux/clk/zynq.h                           |    8 +-
>  include/linux/dw_apb_timer.h                       |    1 -
>  include/linux/mfd/davinci_voicecodec.h             |    3 +-
>  include/linux/mfd/syscon/clps711x.h                |   94 +
>  .../mach => include/linux/platform_data}/edma.h    |   94 +-
>  include/linux/platform_data/gpio-rcar.h            |    5 +-
>  include/linux/platform_data/pinctrl-coh901.h       |   22 -
>  include/linux/platform_data/spi-davinci.h          |    2 +-
>  include/linux/platform_data/usb-rcar-phy.h         |   28 +
>  include/linux/usb/ehci_pdriver.h                   |    4 +
>  sound/soc/davinci/davinci-evm.c                    |    1 +
>  sound/soc/davinci/davinci-pcm.c                    |    1 +
>  sound/soc/davinci/davinci-pcm.h                    |    2 +-
>  483 files changed, 34845 insertions(+), 19523 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/cci.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/keystone/keystone.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/rtsm-dcscb.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/ste-u300.txt
>  create mode 100644 Documentation/devicetree/bindings/clock/imx6sl-clock.txt
>  create mode 100644 Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt
>  create mode 100644 Documentation/devicetree/bindings/clock/vf610-clock.txt
>  create mode 100644 Documentation/devicetree/bindings/dma/ste-coh901318.txt
>  create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-clps711x.txt
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt
>  create mode 100644 Documentation/devicetree/bindings/pci/designware-pcie.txt
>  create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt
>  create mode 100644 Documentation/devicetree/bindings/pci/pci.txt
>  create mode 100644 Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt
>  create mode 100644 Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt
>  create mode 100644 Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt
>  create mode 100644 arch/arm/boot/dts/keystone.dts
>  create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6281.dts
>  create mode 100644 arch/arm/boot/dts/kirkwood-db-88f6282.dts
>  create mode 100644 arch/arm/boot/dts/kirkwood-db.dtsi
>  create mode 100644 arch/arm/boot/dts/rk3066a-clocks.dtsi
>  create mode 100644 arch/arm/boot/dts/rk3066a.dtsi
>  create mode 100644 arch/arm/boot/dts/ste-u300.dts
>  rename arch/arm/{mach-davinci/dma.c => common/edma.c} (86%)
>  delete mode 100644 arch/arm/configs/ap4evb_defconfig
>  delete mode 100644 arch/arm/configs/bonito_defconfig
>  create mode 100644 arch/arm/configs/keystone_defconfig
>  delete mode 100644 arch/arm/include/asm/hardware/pci_v3.h
>  create mode 100644 arch/arm/include/asm/v7m.h
>  create mode 100644 arch/arm/include/debug/keystone.S
>  create mode 100644 arch/arm/include/debug/rockchip.S
>  rename arch/arm/{mach-u300/include/mach/debug-macro.S => include/debug/u300.S} (78%)
>  create mode 100644 arch/arm/kernel/entry-v7m.S
>  create mode 100644 arch/arm/kernel/psci_smp.c
>  create mode 100644 arch/arm/mach-clps711x/devices.c
>  create mode 100644 arch/arm/mach-clps711x/devices.h
>  delete mode 100644 arch/arm/mach-clps711x/include/mach/autcpu12.h
>  delete mode 100644 arch/arm/mach-clps711x/include/mach/memory.h
>  delete mode 100644 arch/arm/mach-clps711x/include/mach/syspld.h
>  delete mode 100644 arch/arm/mach-exynos/dev-ahci.c
>  delete mode 100644 arch/arm/mach-exynos/dev-audio.c
>  delete mode 100644 arch/arm/mach-exynos/dev-ohci.c
>  delete mode 100644 arch/arm/mach-exynos/dev-uart.c
>  delete mode 100644 arch/arm/mach-exynos/dma.c
>  delete mode 100644 arch/arm/mach-exynos/include/mach/gpio.h
>  delete mode 100644 arch/arm/mach-exynos/include/mach/irqs.h
>  delete mode 100644 arch/arm/mach-exynos/include/mach/regs-gpio.h
>  delete mode 100644 arch/arm/mach-exynos/include/mach/regs-usb-phy.h
>  delete mode 100644 arch/arm/mach-exynos/mach-armlex4210.c
>  delete mode 100644 arch/arm/mach-exynos/mach-nuri.c
>  delete mode 100644 arch/arm/mach-exynos/mach-origen.c
>  delete mode 100644 arch/arm/mach-exynos/mach-smdk4x12.c
>  delete mode 100644 arch/arm/mach-exynos/mach-smdkv310.c
>  delete mode 100644 arch/arm/mach-exynos/mach-universal_c210.c
>  delete mode 100644 arch/arm/mach-exynos/setup-fimc.c
>  delete mode 100644 arch/arm/mach-exynos/setup-fimd0.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c0.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c1.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c2.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c3.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c4.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c5.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c6.c
>  delete mode 100644 arch/arm/mach-exynos/setup-i2c7.c
>  delete mode 100644 arch/arm/mach-exynos/setup-keypad.c
>  delete mode 100644 arch/arm/mach-exynos/setup-sdhci-gpio.c
>  delete mode 100644 arch/arm/mach-exynos/setup-spi.c
>  delete mode 100644 arch/arm/mach-exynos/setup-usb-phy.c
>  create mode 100644 arch/arm/mach-imx/clk-imx6sl.c
>  create mode 100644 arch/arm/mach-imx/clk-vf610.c
>  create mode 100644 arch/arm/mach-imx/mach-imx6sl.c
>  create mode 100644 arch/arm/mach-imx/mach-vf610.c
>  delete mode 100644 arch/arm/mach-imx/ulpi.c
>  delete mode 100644 arch/arm/mach-integrator/pci.c
>  create mode 100644 arch/arm/mach-integrator/pci_v3.h
>  create mode 100644 arch/arm/mach-keystone/Kconfig
>  create mode 100644 arch/arm/mach-keystone/Makefile
>  create mode 100644 arch/arm/mach-keystone/Makefile.boot
>  create mode 100644 arch/arm/mach-keystone/keystone.c
>  create mode 100644 arch/arm/mach-keystone/keystone.h
>  create mode 100644 arch/arm/mach-keystone/platsmp.c
>  create mode 100644 arch/arm/mach-keystone/smc.S
>  create mode 100644 arch/arm/mach-kirkwood/board-db88f628x-bp.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-nsa310.c
>  delete mode 100644 arch/arm/mach-kirkwood/db88f6281-bp-setup.c
>  create mode 100644 arch/arm/mach-omap2/clockdomains54xx_data.c
>  create mode 100644 arch/arm/mach-omap2/cm-regbits-54xx.h
>  create mode 100644 arch/arm/mach-omap2/cm1_54xx.h
>  create mode 100644 arch/arm/mach-omap2/cm2_54xx.h
>  create mode 100644 arch/arm/mach-omap2/cm_44xx_54xx.h
>  create mode 100644 arch/arm/mach-omap2/omap4-restart.c
>  create mode 100644 arch/arm/mach-omap2/omap_hwmod_54xx_data.c
>  create mode 100644 arch/arm/mach-omap2/powerdomains54xx_data.c
>  create mode 100644 arch/arm/mach-omap2/prcm_mpu54xx.h
>  create mode 100644 arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h
>  create mode 100644 arch/arm/mach-omap2/prm-regbits-54xx.h
>  create mode 100644 arch/arm/mach-omap2/prm44xx_54xx.h
>  create mode 100644 arch/arm/mach-omap2/prm54xx.h
>  create mode 100644 arch/arm/mach-omap2/scrm54xx.h
>  create mode 100644 arch/arm/mach-omap2/voltagedomains54xx_data.c
>  create mode 100644 arch/arm/mach-rockchip/Kconfig
>  create mode 100644 arch/arm/mach-rockchip/Makefile
>  create mode 100644 arch/arm/mach-rockchip/rockchip.c
>  delete mode 100644 arch/arm/mach-shmobile/board-ap4evb.c
>  delete mode 100644 arch/arm/mach-shmobile/board-bonito.c
>  delete mode 100644 arch/arm/mach-shmobile/include/mach/head-ap4evb.txt
>  delete mode 100644 arch/arm/mach-shmobile/include/mach/memory.h
>  delete mode 100644 arch/arm/mach-shmobile/include/mach/mmc-ap4eb.h
>  delete mode 100644 arch/arm/mach-u300/i2c.c
>  delete mode 100644 arch/arm/mach-u300/i2c.h
>  delete mode 100644 arch/arm/mach-u300/include/mach/hardware.h
>  delete mode 100644 arch/arm/mach-u300/include/mach/irqs.h
>  delete mode 100644 arch/arm/mach-u300/include/mach/syscon.h
>  delete mode 100644 arch/arm/mach-u300/include/mach/timex.h
>  delete mode 100644 arch/arm/mach-u300/include/mach/u300-regs.h
>  delete mode 100644 arch/arm/mach-u300/include/mach/uncompress.h
>  delete mode 100644 arch/arm/mach-u300/spi.c
>  delete mode 100644 arch/arm/mach-u300/spi.h
>  delete mode 100644 arch/arm/mach-u300/timer.h
>  delete mode 100644 arch/arm/mach-u300/u300-gpio.h
>  create mode 100644 arch/arm/mach-vexpress/dcscb.c
>  create mode 100644 arch/arm/mach-vexpress/dcscb_setup.S
>  delete mode 100644 arch/arm/mach-virt/platsmp.c
>  create mode 100644 arch/arm/mm/cache-nop.S
>  create mode 100644 arch/arm/mm/proc-v7m.S
>  create mode 100644 drivers/bus/arm-cci.c
>  delete mode 100644 drivers/clk/clk-zynq.c
>  create mode 100644 drivers/clk/mvebu/armada-370.c
>  create mode 100644 drivers/clk/mvebu/armada-xp.c
>  delete mode 100644 drivers/clk/mvebu/clk-core.c
>  delete mode 100644 drivers/clk/mvebu/clk-core.h
>  delete mode 100644 drivers/clk/mvebu/clk-gating-ctrl.c
>  delete mode 100644 drivers/clk/mvebu/clk-gating-ctrl.h
>  delete mode 100644 drivers/clk/mvebu/clk.c
>  create mode 100644 drivers/clk/mvebu/common.c
>  create mode 100644 drivers/clk/mvebu/common.h
>  create mode 100644 drivers/clk/mvebu/dove.c
>  create mode 100644 drivers/clk/mvebu/kirkwood.c
>  create mode 100644 drivers/clk/zynq/Makefile
>  create mode 100644 drivers/clk/zynq/clkc.c
>  create mode 100644 drivers/clk/zynq/pll.c
>  delete mode 100644 drivers/mtd/maps/autcpu12-nvram.c
>  create mode 100644 drivers/pci/host/Kconfig
>  create mode 100644 drivers/pci/host/Makefile
>  create mode 100644 drivers/pci/host/pci-mvebu.c
>  create mode 100644 drivers/pci/host/pcie-designware.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a7778.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a7790.c
>  create mode 100644 include/dt-bindings/clock/imx6sl-clock.h
>  create mode 100644 include/dt-bindings/clock/vf610-clock.h
>  create mode 100644 include/linux/arm-cci.h
>  delete mode 100644 include/linux/clk/mvebu.h
>  create mode 100644 include/linux/mfd/syscon/clps711x.h
>  rename {arch/arm/mach-davinci/include/mach => include/linux/platform_data}/edma.h (58%)
>  delete mode 100644 include/linux/platform_data/pinctrl-coh901.h
>  create mode 100644 include/linux/platform_data/usb-rcar-phy.h


From sboyd at codeaurora.org  Tue Jul  2 19:22:59 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 2 Jul 2013 16:22:59 -0700
Subject: [PATCH] ARM: move body of head-common.S back to text section
In-Reply-To: <1372805629-18382-1-git-send-email-swarren@wwwdotorg.org>
References: <1372805629-18382-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130702232259.GH11625@codeaurora.org>

On 07/02, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> Commit 281ecb7 "arm: delete __cpuinit/__CPUINIT usage from all ARM
> users" removed a __CPUINIT from head-common.S. However, the code
> immediately before the removed tag was marked __INIT, and was missing
> a match __FINIT. This caused code after the removed __CPUINIT to end
> up in the init section rather than the main text section as desired.
> This caused issues such as secondary CPU boot failures or crashes.
> Add the missing __FINIT to solve this.
> 
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> ---
>  arch/arm/kernel/head-common.S | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
> index 529ce99..a9dc804 100644
> --- a/arch/arm/kernel/head-common.S
> +++ b/arch/arm/kernel/head-common.S
> @@ -122,6 +122,8 @@ __mmap_switched_data:
>  	.long	init_thread_union + THREAD_START_SP @ sp
>  	.size	__mmap_switched_data, . - __mmap_switched_data
>  
> +	__FINIT
> +
>  /*
>   * This provides a C-API version of __lookup_processor_type
>   */

Shouldn't this come after lookup_processor_type()? Otherwise you
just removed that function from the init section?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From ezequiel.garcia at free-electrons.com  Tue Jul  2 19:23:12 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 2 Jul 2013 20:23:12 -0300
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130702220936.GC10215@1wt.eu>
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net>
 <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
Message-ID: <20130702232311.GA3949@localhost>

Hi guys,

I feel I might share some of my findings when I worked on this,
in the hope it's useful for anyone.

On Wed, Jul 03, 2013 at 12:09:36AM +0200, Willy Tarreau wrote:
> > 
> > Which matches what Thomas wrote in a previous email regarding pwa3xx
> > base. 
> 
> Yes and indeed I must say that when I read the driver I found some
> similarities with pxa3xx, though it was done differently. I initially
> wanted to try to merge them but of course without the spec it's a huge
> waste of time, especially considering that this is still in the roadmap
> of the Free Electrons guys even though low priority.
> 

I wish I could say I'm going to work on this soon but, as Thomas said,
we have no idea when/if NAND will be prioritized.

On the other side if you look at the driver Willy just posted, merging
the juicy stuff into pxa3xx-nand driver is not for the faint of heart.

Without the spec, is only tougher.

Just a quick hint. As far as I can recall, one of the first items in a
TODO list should be:

 * adding bigger page support to pxa3xx (4 KiB, 8 KiB).
   Willy's posted driver might be helpful to accomplish this;
   provided your eyes don't melt when you look at it :-)

 * once the above is done, bad block management can/should be added.

With these two we're almost there for R/W support.

> Since I'm now flashing a rootfs from within u-boot, support for the
> NAND is of less importance to me than what it used to, but I have no
> problem with helping with my very limited time. I have 3 machines
> with this controller (mirabox, openblocks AX3, and an XP-GP, though

With my latest patches pxa3xx-nand should at least *detect* the NAND
device in XP-GP. Doesn't work for Mirabox, though.

> the AX3 only has NOR IIRC). I can do some tests if you manage to get
> the driver to work again.
> 
> Be very careful when playing with this, the driver expects the partition
> table to be passed from u-boot as "armada_nand", and if it uses the wrong
> partition layout, you can be certain that ubifs will destroy them at the
> first mount attempt. That's how I initially bricked my mirabox and did so
> repeatedly. Better keep a copy before booting the patched kernel!
> 
> Another point, I had to add a new entry for the Micro 8Gb flash of the
> mirabox, maybe you won't need it or maybe you'll need a different one.
> 

Just a note about this. You need that entry because your driver doesn't
support ONFI-detected flash devices. You could workaround that, by
adding support simple command. I did it for pxa3xx-nand recently:

"mtd: nand: pxa3xx: Add address support for READID command"
http://permalink.gmane.org/gmane.linux.drivers.mtd/46606

Thanks,
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From arno at natisbad.org  Tue Jul  2 19:27:31 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Wed, 03 Jul 2013 01:27:31 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <51D2DA18.3020905@gmail.com> (Sebastian Hesselbarth's message of
 "Tue, 02 Jul 2013 15:48:08 +0200")
References: <87fvvzfh70.fsf@natisbad.org> <51D2DA18.3020905@gmail.com>
Message-ID: <87vc4stue4.fsf@natisbad.org>

Hi,

Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> writes:

>> +			pinctrl {
>> +				power_led_pin: power-led-pin {
>> +					marvell,pins = "mpp57";
>> +					marvell,function = "gpio";
>> +				};
>> +				sata1_led_pin: sata1-led-pin {
>> +					marvell,pins = "mpp15";
>> +					marvell,function = "gpio";
>> +				};
>> +
>> +				sata2_led_pin: sata2-led-pin {
>> +					marvell,pins = "mpp14";
>> +					marvell,function = "gpio";
>> +				};
>> +
>> +				backup_led_pin: backup-led-pin {
>> +					marvell,pins = "mpp56";
>> +					marvell,function = "gpio";
>> +				};
>> +			};
>> +
>> +			gpio_leds {
>
> Arnaud,
>
> gpio_leds, gpio_keys, and clocks nodes shouldn't be children of
> soc/internal-regs. I suggest to move them up as siblings of soc,
> memory, and chosen instead.

Will do that in next round. Thanks for pointing it.

Cheers,

a+


From sebastian.hesselbarth at gmail.com  Tue Jul  2 19:29:56 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Wed, 03 Jul 2013 01:29:56 +0200
Subject: [PATCH v6 5/7] ARM: kirkwood: remove redundant DT board files
In-Reply-To: <87k3l8v9s1.fsf@natisbad.org>
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1372762824-12202-6-git-send-email-sebastian.hesselbarth@gmail.com>
 <87k3l8v9s1.fsf@natisbad.org>
Message-ID: <51D36274.6020204@gmail.com>

On 07/03/2013 01:09 AM, Arnaud Ebalard wrote:
> Hi Sebastian,
>
> Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>  writes:
>
>> With DT support for mv643xx_eth board specific init for some boards now
>> is unneccessary. Remove those board files, Kconfig entries, and
>> corresponding entries in kirkwood_defconfig.
>
> Applying above your set an old quilt cleaning patch Jason asked at some
> point, it became empty except for arch/arm/mach_kirkwood/common.h in
> which some declarations were left behind. If this is correct, can you
> just merge the hunks below in your 5/7 in next round?
>
> AFAICT, only dnskw_init() remains, which matches the list of board-*.c
> files in arch/arm/mach_kirkwood/ (i.e. board-dt.c and board-dnskw.c).

Arnaud,

thanks for sending this! I will squash it into v6 and send a v7 of this
patch. Looks like ARM SoC pull request causes some issues with Russell's
tree, so there is plenty of time left to resend (and re-test :))

And you are right, only board-dt.c and board-dnskw.c remain in
mach-kirkwood. With irqchip/clocksource patches in, IMHO kirkwood is
quite ready for mach-mvebu. mach-dove is still missing DT pcie, and I 
haven't had any success to get my hands on a board with pcie to test,
yet.

Sebastian

> Signed-off-by: Arnaud Ebalard<arno at natisbad.org>
> ---
>   arch/arm/mach-kirkwood/common.h | 108 ----------------------------------------
>   1 file changed, 108 deletions(-)
>
> diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
> index 1c09f3f..1cbdd2b 100644
> --- a/arch/arm/mach-kirkwood/common.h
> +++ b/arch/arm/mach-kirkwood/common.h
> @@ -57,26 +57,6 @@ void kirkwood_restart(char, const char *);
>   void kirkwood_clk_init(void);
>
>   /* board init functions for boards not fully converted to fdt */
> -#ifdef CONFIG_MACH_DREAMPLUG_DT
> -void dreamplug_init(void);
> -#else
> -static inline void dreamplug_init(void) {};
> -#endif
> -#ifdef CONFIG_MACH_GURUPLUG_DT
> -void guruplug_dt_init(void);
> -#else
> -static inline void guruplug_dt_init(void) {};
> -#endif
> -#ifdef CONFIG_MACH_SHEEVAPLUG_DT
> -void sheevaplug_dt_init(void);
> -#else
> -static inline void sheevaplug_dt_init(void) {};
> -#endif
> -#ifdef CONFIG_MACH_TS219_DT
> -void qnap_dt_ts219_init(void);
> -#else
> -static inline void qnap_dt_ts219_init(void) {};
> -#endif
>
>   #ifdef CONFIG_MACH_DLINK_KIRKWOOD_DT
>   void dnskw_init(void);
> @@ -84,94 +64,6 @@ void dnskw_init(void);
>   static inline void dnskw_init(void) {};
>   #endif
>
> -#ifdef CONFIG_MACH_ICONNECT_DT
> -void iconnect_init(void);
> -#else
> -static inline void iconnect_init(void) {};
> -#endif
> -
> -#ifdef CONFIG_MACH_IB62X0_DT
> -void ib62x0_init(void);
> -#else
> -static inline void ib62x0_init(void) {};
> -#endif
> -
> -#ifdef CONFIG_MACH_DOCKSTAR_DT
> -void dockstar_dt_init(void);
> -#else
> -static inline void dockstar_dt_init(void) {};
> -#endif
> -
> -#ifdef CONFIG_MACH_GOFLEXNET_DT
> -void goflexnet_init(void);
> -#else
> -static inline void goflexnet_init(void) {};
> -#endif
> -
> -#ifdef CONFIG_MACH_LSXL_DT
> -void lsxl_init(void);
> -#else
> -static inline void lsxl_init(void) {};
> -#endif
> -
> -#ifdef CONFIG_MACH_IOMEGA_IX2_200_DT
> -void iomega_ix2_200_init(void);
> -#else
> -static inline void iomega_ix2_200_init(void) {};
> -#endif
> -
> -#ifdef CONFIG_MACH_KM_KIRKWOOD_DT
> -void km_kirkwood_init(void);
> -#else
> -static inline void km_kirkwood_init(void) {};
> -#endif
> -
> -#ifdef CONFIG_MACH_DB88F628X_BP_DT
> -void db88f628x_init(void);
> -#else
> -static inline void db88f628x_init(void) {};
> -#endif
> -
> -#ifdef CONFIG_MACH_MPLCEC4_DT
> -void mplcec4_init(void);
> -#else
> -static inline void mplcec4_init(void) {};
> -#endif
> -
> -#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
> -	defined(CONFIG_MACH_NETSPACE_V2_DT) || \
> -	defined(CONFIG_MACH_NETSPACE_MAX_V2_DT) || \
> -	defined(CONFIG_MACH_NETSPACE_LITE_V2_DT) || \
> -	defined(CONFIG_MACH_NETSPACE_MINI_V2_DT)
> -void ns2_init(void);
> -#else
> -static inline void ns2_init(void) {};
> -#endif
> -
> -#ifdef CONFIG_MACH_OPENBLOCKS_A6_DT
> -void openblocks_a6_init(void);
> -#else
> -static inline void openblocks_a6_init(void) {};
> -#endif
> -
> -#ifdef CONFIG_MACH_READYNAS_DT
> -void netgear_readynas_init(void);
> -#else
> -static inline void netgear_readynas_init(void) {};
> -#endif
> -
> -#ifdef CONFIG_MACH_TOPKICK_DT
> -void usi_topkick_init(void);
> -#else
> -static inline void usi_topkick_init(void) {};
> -#endif
> -
> -#ifdef CONFIG_MACH_CLOUDBOX_DT
> -void cloudbox_init(void);
> -#else
> -static inline void cloudbox_init(void) {};
> -#endif
> -
>   /* early init functions not converted to fdt yet */
>   char *kirkwood_id(void);
>   void kirkwood_l2_init(void);



From torvalds at linux-foundation.org  Tue Jul  2 19:51:07 2013
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Tue, 2 Jul 2013 16:51:07 -0700
Subject: [GIT PULL 3/7] ARM SoC specific changes
In-Reply-To: <20130702231706.GF24642@n2100.arm.linux.org.uk>
References: <201307022055.50717.arnd@arndb.de>
 <201307022104.01826.arnd@arndb.de>
 <20130702231706.GF24642@n2100.arm.linux.org.uk>
Message-ID: <CA+55aFzV12kJgNOax7B1rM8capK2uYLH66wHnQRNn4k5wa1LMQ@mail.gmail.com>

On Tue, Jul 2, 2013 at 4:17 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> Please don't merge this yet.

Oops, too late. The ARM SoC pull requests got merged a couple of hours ago..

            Linus


From olof at lixom.net  Tue Jul  2 20:00:43 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 2 Jul 2013 17:00:43 -0700
Subject: [GIT PULL 3/7] ARM SoC specific changes
In-Reply-To: <CA+55aFzV12kJgNOax7B1rM8capK2uYLH66wHnQRNn4k5wa1LMQ@mail.gmail.com>
References: <201307022055.50717.arnd@arndb.de>
 <201307022104.01826.arnd@arndb.de>
 <20130702231706.GF24642@n2100.arm.linux.org.uk>
 <CA+55aFzV12kJgNOax7B1rM8capK2uYLH66wHnQRNn4k5wa1LMQ@mail.gmail.com>
Message-ID: <CAOesGMifPRVr=TVWJfEOm83tMVE0aXFCBVNvAKLV8mvqbDEJmQ@mail.gmail.com>

On Tue, Jul 2, 2013 at 4:51 PM, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
> On Tue, Jul 2, 2013 at 4:17 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
>> Please don't merge this yet.
>
> Oops, too late. The ARM SoC pull requests got merged a couple of hours ago..

It should hopefully not be a big problem, you'll see a merge conflict
(so will sfr) when merging from Russell due to add/add conflicts been
resolved by ordering them in opposite order in
arch/arm/include/asm/glue-proc.h.

Feel free to flip them back to Russell's preferred ordering at that
time, of course.


-Olof


From voice.shen at atmel.com  Tue Jul  2 21:20:25 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Wed, 3 Jul 2013 09:20:25 +0800
Subject: [alsa-devel] [PATCH 1/2] ASoC: atmel_ssc_dai: move set dma data
 to startup callback
In-Reply-To: <51D2F0FA.6040409@metafoo.de>
References: <1372755849-19546-1-git-send-email-voice.shen@atmel.com>
 <1372755849-19546-2-git-send-email-voice.shen@atmel.com>
 <51D2F0FA.6040409@metafoo.de>
Message-ID: <51D37C59.3090306@atmel.com>

Hi Lars-Peter,

On 7/2/2013 23:25, Lars-Peter Clausen wrote:
> On 07/02/2013 11:04 AM, Bo Shen wrote:
> [...]
>> +	dma_params->substream = substream;
>
> Unrelated to this patch, but having a substream field in the dma_params seems
> to be redundant, since you need to know the substream to get the dma_params in
> the first place. Looking at the code it also seems to be unused other than this
> assignment. Maybe you can send a follow up patch to remove it.
>
> [...]
>

Yes, this is redundant. I will remove it in next version patches.

Best Regards,
Bo Shen


From shawn.guo at linaro.org  Tue Jul  2 21:25:49 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Jul 2013 09:25:49 +0800
Subject: [PATCH] ARM: dts: imx: add #dma-cells property for sdma
In-Reply-To: <1372731329-1016-1-git-send-email-b32955@freescale.com>
References: <1372731329-1016-1-git-send-email-b32955@freescale.com>
Message-ID: <20130703012547.GA9145@S2101-09.ap.freescale.net>

On Tue, Jul 02, 2013 at 10:15:29AM +0800, Huang Shijie wrote:
> Add the #dma-cells property for all the sdma in all the imx platforms.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>

Applied, thanks.

Shawn



From voice.shen at atmel.com  Tue Jul  2 21:33:59 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Wed, 3 Jul 2013 09:33:59 +0800
Subject: [alsa-devel] [PATCH 2/2] ASoC: atmel-pcm: use generic dmaengine
 framework
In-Reply-To: <51D2F306.7040603@metafoo.de>
References: <1372755849-19546-1-git-send-email-voice.shen@atmel.com>
 <1372755849-19546-3-git-send-email-voice.shen@atmel.com>
 <51D2F306.7040603@metafoo.de>
Message-ID: <51D37F87.2010008@atmel.com>

Hi Lars-Peter,

On 7/2/2013 23:34, Lars-Peter Clausen wrote:
> On 07/02/2013 11:04 AM, Bo Shen wrote:
> [...]
>> -/*--------------------------------------------------------------------------*\
>> - * DMAENGINE operations
>> -\*--------------------------------------------------------------------------*/
>> -static bool filter(struct dma_chan *chan, void *slave)
>> -{
>> -	struct at_dma_slave *sl = slave;
>> -
>> -	if (sl->dma_dev == chan->device->dev) {
>> -		chan->private = sl;
>> -		return true;
>> -	} else {
>> -		return false;
>> -	}
>> -}
>
> I'm wondering why is filtering no longer required?

Now this is handled by at_dma_filter in at_hdmac driver. More 
information, you can reference: <driver/dma/at_hdmac.c> file

> [...]
>> +		slave_config->dst_addr = (dma_addr_t)ssc->phybase + SSC_THR;
> [...]
>> +		slave_config->src_addr = (dma_addr_t)ssc->phybase + SSC_RHR;
>
> Change the type of phybase to dma_addr_t

It should be:
slave_config->dst_addr = (dma_addr_t)(ssc->phybase + SSC_THR);
slave_config->src_addr = (dma_addr_t)(ssc->phybase + SSC_RHR);

> [...]
>>   }
>>
>> -static int atmel_pcm_dma_prepare(struct snd_pcm_substream *substream)
>> -{
>> -	struct snd_soc_pcm_runtime *rtd = substream->private_data;
>> -	struct atmel_pcm_dma_params *prtd;
>> -
>> -	prtd = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
>> -
>> -	ssc_writex(prtd->ssc->regs, SSC_IER, prtd->mask->ssc_error);
>> -	ssc_writex(prtd->ssc->regs, SSC_CR, prtd->mask->ssc_enable);
>
> These writes are also completely lost

This will be moved to DAI driver startup callback function.

>> -
>> -	return 0;
>> -}
>
> I think it would also be good to get rid of any references to the ssc struct
> from the DMA driver and move them over to the DAI driver.

I will try to implement this in next version patch.

Thanks.

> - Lars
>

Best Regards,
Bo Shen



From shawn.guo at linaro.org  Tue Jul  2 21:46:24 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Jul 2013 09:46:24 +0800
Subject: [PATCH 3/5] ARM: dts: imx6: rename the uart's compatible property
In-Reply-To: <51D2AEC1.6030004@freescale.com>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
 <1372746628-20092-4-git-send-email-b32955@freescale.com>
 <20130702095645.GD31358@e106331-lin.cambridge.arm.com>
 <51D2AEC1.6030004@freescale.com>
Message-ID: <20130703014623.GB9145@S2101-09.ap.freescale.net>

On Tue, Jul 02, 2013 at 06:43:13PM +0800, Huang Shijie wrote:
> ? 2013?07?02? 17:56, Mark Rutland ??:
> >On Tue, Jul 02, 2013 at 07:30:26AM +0100, Huang Shijie wrote:
> >>>  The imx6 uart can supports the DMA, imx uart driver has added a new
> >>>  compatible property for the imx6 uart.
> >>>  >  In order to enable the DMA for some uart port in imx6, we
> >>rename the
> >>>  uart's compatible property to "fsl,imx6-uart".
> >Doesn't this change break using these dts with an older kernel? You
> is it reasonable to use a new dts with an old kernel?
> 
> 
> >remove the "fsl,imx21-uart" string older kernels understand.
> >
> >Given you already had "fsl,imx6q-uart" and "fsl,imx6sl-uart" strings,
> >would it not have made more sense to just add these to the driver?
> I think it's not a good idea.
> 
> Shawn, what's your opinion about this?

I agree with Mark.  I think all we need is to add "fsl,imx6q-uart"
into both driver matching table and imx6sl uart compatible property,
something like the below.

Shawn

---8<-------

diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index c5e5da0..078dfc7 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -152,7 +152,8 @@
                                };

                                uart5: serial at 02018000 {
-                                       compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+                                       compatible = "fsl,imx6sl-uart", "fsl,imx6q-uart",
+                                                    "fsl,imx21-uart";
                                        reg = <0x02018000 0x4000>;
                                        interrupts = <0 30 0x04>;
                                        clocks = <&clks IMX6SL_CLK_UART>,
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 8cdfbd3..457984d 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -249,6 +249,7 @@ MODULE_DEVICE_TABLE(platform, imx_uart_devtype);
 static struct of_device_id imx_uart_dt_ids[] = {
        { .compatible = "fsl,imx1-uart", .data = &imx_uart_devdata[IMX1_UART], },
        { .compatible = "fsl,imx21-uart", .data = &imx_uart_devdata[IMX21_UART], },
+       { .compatible = "fsl,imx6q-uart", .data = &imx_uart_devdata[IMX6Q_UART], },
        { /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, imx_uart_dt_ids);




From shawn.guo at linaro.org  Tue Jul  2 21:48:38 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Jul 2013 09:48:38 +0800
Subject: [PATCH 1/5] serial: imx: distinguish the imx6 uart from the others
In-Reply-To: <1372746628-20092-2-git-send-email-b32955@freescale.com>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
 <1372746628-20092-2-git-send-email-b32955@freescale.com>
Message-ID: <20130703014836.GC9145@S2101-09.ap.freescale.net>

On Tue, Jul 02, 2013 at 02:30:24PM +0800, Huang Shijie wrote:
> We will add the DMA support for the imx uart. For the firmware's limit,
> only the imx6 uart can supports the DMA.
> 
> This patch adds the necessary macro and helper to distinguish the imx6 uart
> from the other imx uart.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>
> ---
>  drivers/tty/serial/imx.c |   17 +++++++++++++++--
>  1 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 48bace0..d215fa9 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -187,6 +187,7 @@
>  enum imx_uart_type {
>  	IMX1_UART,
>  	IMX21_UART,
> +	IMX6_UART,
>  };
>  
>  /* device type dependent stuff */
> @@ -232,6 +233,10 @@ static struct imx_uart_data imx_uart_devdata[] = {
>  		.uts_reg = IMX21_UTS,
>  		.devtype = IMX21_UART,
>  	},
> +	[IMX6_UART] = {
> +		.uts_reg = IMX21_UTS,
> +		.devtype = IMX6_UART,
> +	},
>  };
>  
>  static struct platform_device_id imx_uart_devtype[] = {
> @@ -242,6 +247,9 @@ static struct platform_device_id imx_uart_devtype[] = {
>  		.name = "imx21-uart",
>  		.driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX21_UART],
>  	}, {
> +		.name = "imx6-uart",
> +		.driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX6_UART],
> +	}, {
>  		/* sentinel */
>  	}
>  };
> @@ -250,6 +258,7 @@ MODULE_DEVICE_TABLE(platform, imx_uart_devtype);
>  static struct of_device_id imx_uart_dt_ids[] = {
>  	{ .compatible = "fsl,imx1-uart", .data = &imx_uart_devdata[IMX1_UART], },
>  	{ .compatible = "fsl,imx21-uart", .data = &imx_uart_devdata[IMX21_UART], },
> +	{ .compatible = "fsl,imx6-uart", .data = &imx_uart_devdata[IMX6_UART], },

We generally use a chip/SoC name in compatible to specify a particular
device type.  imx6 is not such a name.

Shawn

>  	{ /* sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(of, imx_uart_dt_ids);
> @@ -269,6 +278,10 @@ static inline int is_imx21_uart(struct imx_port *sport)
>  	return sport->devdata->devtype == IMX21_UART;
>  }
>  
> +static inline int is_imx6_uart(struct imx_port *sport)
> +{
> +	return sport->devdata->devtype == IMX6_UART;
> +}
>  /*
>   * Save and restore functions for UCR1, UCR2 and UCR3 registers
>   */
> @@ -801,7 +814,7 @@ static int imx_startup(struct uart_port *port)
>  		}
>  	}
>  
> -	if (is_imx21_uart(sport)) {
> +	if (is_imx21_uart(sport) || is_imx6_uart(sport)) {
>  		temp = readl(sport->port.membase + UCR3);
>  		temp |= IMX21_UCR3_RXDMUXSEL;
>  		writel(temp, sport->port.membase + UCR3);
> @@ -1044,7 +1057,7 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
>  	writel(num, sport->port.membase + UBIR);
>  	writel(denom, sport->port.membase + UBMR);
>  
> -	if (is_imx21_uart(sport))
> +	if (is_imx21_uart(sport) || is_imx6_uart(sport))
>  		writel(sport->port.uartclk / div / 1000,
>  				sport->port.membase + IMX21_ONEMS);
>  
> -- 
> 1.7.1
> 
> 



From shawn.guo at linaro.org  Tue Jul  2 21:52:45 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Jul 2013 09:52:45 +0800
Subject: [PATCH 1/5] serial: imx: distinguish the imx6 uart from the others
In-Reply-To: <1372746628-20092-2-git-send-email-b32955@freescale.com>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
 <1372746628-20092-2-git-send-email-b32955@freescale.com>
Message-ID: <20130703015243.GD9145@S2101-09.ap.freescale.net>

On Tue, Jul 02, 2013 at 02:30:24PM +0800, Huang Shijie wrote:
> @@ -801,7 +814,7 @@ static int imx_startup(struct uart_port *port)
>  		}
>  	}
>  
> -	if (is_imx21_uart(sport)) {
> +	if (is_imx21_uart(sport) || is_imx6_uart(sport)) {

Would it be better to use (!is_imx1_uart(sport)) here?  Thus when there
is another derivative of imx21-uart device to be added, we do not need
to touch this line again.

Shawn

>  		temp = readl(sport->port.membase + UCR3);
>  		temp |= IMX21_UCR3_RXDMUXSEL;
>  		writel(temp, sport->port.membase + UCR3);



From b32955 at freescale.com  Tue Jul  2 22:15:36 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 3 Jul 2013 10:15:36 +0800
Subject: [PATCH 3/5] ARM: dts: imx6: rename the uart's compatible property
In-Reply-To: <20130702111118.GE31358@e106331-lin.cambridge.arm.com>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
 <1372746628-20092-4-git-send-email-b32955@freescale.com>
 <20130702095645.GD31358@e106331-lin.cambridge.arm.com>
 <51D2AEC1.6030004@freescale.com>
 <20130702111118.GE31358@e106331-lin.cambridge.arm.com>
Message-ID: <51D38948.4040606@freescale.com>

? 2013?07?02? 19:11, Mark Rutland ??:
> compatible string ("fsl,imx21-uart") that should not break newer
> kernels if they choose to use the more-specific compatible string.
>
ok.

I will add back the the "fsl,imx21-uart".

thanks for the review.

Huang Shijie




From b32955 at freescale.com  Tue Jul  2 22:17:44 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 3 Jul 2013 10:17:44 +0800
Subject: [PATCH 1/5] serial: imx: distinguish the imx6 uart from the others
In-Reply-To: <20130703015243.GD9145@S2101-09.ap.freescale.net>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
 <1372746628-20092-2-git-send-email-b32955@freescale.com>
 <20130703015243.GD9145@S2101-09.ap.freescale.net>
Message-ID: <51D389C8.1030101@freescale.com>

? 2013?07?03? 09:52, Shawn Guo ??:
> Would it be better to use (!is_imx1_uart(sport)) here?  Thus when there
a good idea.

i will fix it in next version.

thanks
Huang Shijie



From horms at verge.net.au  Tue Jul  2 22:26:09 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 3 Jul 2013 11:26:09 +0900
Subject: [PATCH v2 0/2] ARM: shmobile: lager: Add DT reference
In-Reply-To: <CANqRtoSk2+mgkzOWZMsyDbJKYCS+Pp2cXMu4=SvO35EQ9sKtig@mail.gmail.com>
References: <1372645120-27256-1-git-send-email-horms+renesas@verge.net.au>
 <CANqRtoSk2+mgkzOWZMsyDbJKYCS+Pp2cXMu4=SvO35EQ9sKtig@mail.gmail.com>
Message-ID: <20130703022608.GA31914@verge.net.au>

On Tue, Jul 02, 2013 at 04:41:01PM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Mon, Jul 1, 2013 at 11:18 AM, Simon Horman
> <horms+renesas at verge.net.au> wrote:
> > Hi,
> >
> > this short series adds DT reference to Lager.
> 
> Thanks for your work on this.
> 
> > The intention of this is to allow the board to be
> > brought up as much as possible using DT. And for
> > this to act as a basis for further DT coverage
> > of devices present on the Lager and its r8a7790 SoC.
> >
> >
> > This series differs from v2 in that it has been
> > rebased on top of reneas-next-20130701 and now makes use
> > of r8a7790_init_delay().
> >
> >
> > Simon Horman (2):
> >   ARM: shmobile: r8a7790:  Initialise clocks and SCIF in
> >     r8a7790_add_dt_devices()
> 
> At this point I'm inclined to say "no" to new DT reference using
> platform devices for SCIF. I believe we instead should really work on
> adding DT support to the SCIF driver and use DT for SCIF on more
> recent boards. Also, we probably don't want to enable clocks like
> that, instead we should tie in common clocks. That will take a little
> bit longer time though, so I wonder what is a good solution until
> then..

I guess we should just delay lager-reference until its dependencies are ready.

> >   ARM: shmobile: lager: Add DT reference
> 
> I think you want to update Makefile.boot to include the
> lager-reference board. Also, I believe that without SCIF and clocks
> the init_machine() and init_irq() callbacks can be left unset to make
> use of the default behaviour.
> 
> Cheers,
> 
> / magnus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From laurent.pinchart at ideasonboard.com  Tue Jul  2 22:30:50 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Wed, 03 Jul 2013 04:30:50 +0200
Subject: [PATCH v4 2/3] ARM: shmobile: lager: enable Ether
In-Reply-To: <20130702012227.GA24086@verge.net.au>
References: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
 <1870016.uXUUSHgrj5@avalon> <20130702012227.GA24086@verge.net.au>
Message-ID: <2350201.0bf2NXOx7A@avalon>

Hi Simon,

On Tuesday 02 July 2013 10:22:28 Simon Horman wrote:
> On Mon, Jul 01, 2013 at 03:29:21PM +0200, Laurent Pinchart wrote:
> > On Monday 01 July 2013 16:20:33 Simon Horman wrote:
> > > Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> > > Cc: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> > > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> > > 
> > > ---
> > > 
> > > This patch has a build-time dependency on "sh_eth: add support for gpio
> > > reset". This patch has a run-time dependency on "sh_eth: add support for
> > > r8a7790 SoC".
> > > 
> > > v4
> > > * Annotate ether_platdata as __initdata
> > > 
> > > v3
> > > * Rebase
> > > 
> > > v2
> > > * As suggested by Laurent Pinchart
> > >   - Do not manipilate sh_eth reset GPIO directly,
> > >     rather, do so through newly proposed support for this in
> > >     the sh_eth driver.
> > > * A suggested by Sergei Shtylyov
> > >   - Move DTS portion into a separate patch
> > > 
> > > ---
> > > 
> > >  arch/arm/mach-shmobile/board-lager.c | 24 ++++++++++++++++++++++++
> > >  1 file changed, 24 insertions(+)
> > > 
> > > diff --git a/arch/arm/mach-shmobile/board-lager.c
> > > b/arch/arm/mach-shmobile/board-lager.c index 0b4a1f9..7d5db20 100644
> > > --- a/arch/arm/mach-shmobile/board-lager.c
> > > +++ b/arch/arm/mach-shmobile/board-lager.c
> > > @@ -71,6 +71,17 @@ static __initdata struct gpio_keys_platform_data
> > > lager_keys_pdata = { .nbuttons	= ARRAY_SIZE(gpio_buttons),
> > >  };
> > > 
> > > +/* Ether */
> > > +static struct sh_eth_plat_data ether_platdata __initdata = {
> > > +	.phy			= 0x1,
> > > +	.edmac_endian		= EDMAC_LITTLE_ENDIAN,
> > > +	.register_type		= SH_ETH_REG_FAST_RCAR,
> > > +	.phy_interface		= PHY_INTERFACE_MODE_RMII,
> > > +	.ether_link_active_low	= 1,
> > > +	.needs_gpio_reset	= 1,
> > > +	.reset_gpio		= RCAR_GP_PIN(5, 31),
> > > +};
> > > +
> > > 
> > >  static const struct pinctrl_map lager_pinctrl_map[] = {
> > >  	/* SCIF0 (CN19: DEBUG SERIAL0) */
> > >  	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7790",
> > > @@ -78,6 +89,17 @@ static const struct pinctrl_map lager_pinctrl_map[] =
> > > {
> > >  	/* SCIF1 (CN20: DEBUG SERIAL1) */
> > >  	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.7", "pfc-r8a7790",
> > >  				  "scif1_data", "scif1"),
> > > +	/* Ether */
> > > +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> > > +				  "eth_link", "eth"),
> > > +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> > > +				  "eth_magic", "eth"),
> > 
> > That pin isn't used on Lager, you can drop it.
> 
> Thanks, I will drop that.
> 
> > By the way, the latest R8A7790 datasheet errata renamed the eth_magic pin
> > to eth_wol. What would you think about renaming it to eth_wol in
> > drivers/pinctrl/sh-pfc/pfc-r8a7790.c ?
> 
> I do not have a strong opinion but changing it sounds entirely reasonable to
> me.

The errata renamed the pin, but the latest datasheet, supposed to include the 
errata, still uses eth_magic. Let's not bother then (even though wol would be 
much more descriptive than magic).

> > > +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> > > +				  "eth_mdio", "eth"),
> > > +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> > > +				  "eth_rmii", "eth"),
> > > +	PIN_MAP_MUX_GROUP_DEFAULT("sh-eth", "pfc-r8a7790",
> > > +				  "intc_irq0", "intc"),
> > >  };
> > >  
> > >  static void __init lager_add_standard_devices(void)
> > > @@ -89,6 +111,8 @@ static void __init lager_add_standard_devices(void)
> > >  	r8a7790_pinmux_init();
> > >  	r8a7790_add_standard_devices();
> > > +	r8a7790_add_ether_device(&ether_platdata);
> > > +
> > >  	platform_device_register_data(&platform_bus, "leds-gpio", -1,
> > >  				      &lager_leds_pdata,
> > >  				      sizeof(lager_leds_pdata));

-- 
Regards,

Laurent Pinchart



From swarren at wwwdotorg.org  Tue Jul  2 22:44:20 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 02 Jul 2013 20:44:20 -0600
Subject: [PATCH] ARM: move body of head-common.S back to text section
In-Reply-To: <20130702232259.GH11625@codeaurora.org>
References: <1372805629-18382-1-git-send-email-swarren@wwwdotorg.org>
 <20130702232259.GH11625@codeaurora.org>
Message-ID: <51D39004.9000907@wwwdotorg.org>

On 07/02/2013 05:22 PM, Stephen Boyd wrote:
> On 07/02, Stephen Warren wrote:
>> From: Stephen Warren <swarren at nvidia.com>
>>
>> Commit 281ecb7 "arm: delete __cpuinit/__CPUINIT usage from all ARM
>> users" removed a __CPUINIT from head-common.S. However, the code
>> immediately before the removed tag was marked __INIT, and was missing
>> a match __FINIT. This caused code after the removed __CPUINIT to end
>> up in the init section rather than the main text section as desired.
>> This caused issues such as secondary CPU boot failures or crashes.
>> Add the missing __FINIT to solve this.
>>
>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>> ---
>>  arch/arm/kernel/head-common.S | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
>> index 529ce99..a9dc804 100644
>> --- a/arch/arm/kernel/head-common.S
>> +++ b/arch/arm/kernel/head-common.S
>> @@ -122,6 +122,8 @@ __mmap_switched_data:
>>  	.long	init_thread_union + THREAD_START_SP @ sp
>>  	.size	__mmap_switched_data, . - __mmap_switched_data
>>  
>> +	__FINIT
>> +
>>  /*
>>   * This provides a C-API version of __lookup_processor_type
>>   */
> 
> Shouldn't this come after lookup_processor_type()? Otherwise you
> just removed that function from the init section?

I think this is correct. Prior to "arm: delete __cpuinit/__CPUINIT usage
from all ARM users", lookup_processor_type() was in the cpuinit section.
After that commit, it moved to the init section and hence got dumped
soon after boot. The change above moves lookup_processor_type() back
into the regular text section, which I believe was the intent of the
__cpuinit removal patch.


From shawn.guo at linaro.org  Tue Jul  2 23:38:39 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Jul 2013 11:38:39 +0800
Subject: [PATCH 2/5] serial: imx: add DMA support for imx6
In-Reply-To: <1372746628-20092-3-git-send-email-b32955@freescale.com>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
 <1372746628-20092-3-git-send-email-b32955@freescale.com>
Message-ID: <20130703033837.GE9145@S2101-09.ap.freescale.net>

On Tue, Jul 02, 2013 at 02:30:25PM +0800, Huang Shijie wrote:
> We only enable the DMA support when the following are meet:
> 
>   [1] The uart port supports the hardware flow control(CTS/RTS).
>       (Some uart port does not support the CTS/RTS.)
> 
>   [2] The application enables the CTS/RTS.
> 
>   [3] The Soc is imx6.
>       For the sdma's firmware limit, we do not support the DMA except
>       the imx6 platform.
> 
>   [4] The uart is not used as a console.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>
> ---
>  drivers/tty/serial/imx.c |  413 +++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 408 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index d215fa9..2a4cf89 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -49,9 +49,11 @@
>  #include <linux/of_device.h>
>  #include <linux/pinctrl/consumer.h>
>  #include <linux/io.h>
> +#include <linux/dma-mapping.h>
>  
>  #include <asm/irq.h>
>  #include <linux/platform_data/serial-imx.h>
> +#include <linux/platform_data/dma-imx.h>
>  
>  /* Register definitions */
>  #define URXD0 0x0  /* Receiver Register */
> @@ -83,6 +85,7 @@
>  #define UCR1_ADBR	(1<<14) /* Auto detect baud rate */
>  #define UCR1_TRDYEN	(1<<13) /* Transmitter ready interrupt enable */
>  #define UCR1_IDEN	(1<<12) /* Idle condition interrupt */
> +#define UCR1_ICD_REG(x) (((x) & 3) << 10) /* idle condition detect */
>  #define UCR1_RRDYEN	(1<<9)	/* Recv ready interrupt enable */
>  #define UCR1_RDMAEN	(1<<8)	/* Recv ready DMA enable */
>  #define UCR1_IREN	(1<<7)	/* Infrared interface enable */
> @@ -91,6 +94,7 @@
>  #define UCR1_SNDBRK	(1<<4)	/* Send break */
>  #define UCR1_TDMAEN	(1<<3)	/* Transmitter ready DMA enable */
>  #define IMX1_UCR1_UARTCLKEN (1<<2) /* UART clock enabled, i.mx1 only */
> +#define UCR1_ATDMAEN    (1<<2)  /* Aging DMA Timer Enable */
>  #define UCR1_DOZE	(1<<1)	/* Doze */
>  #define UCR1_UARTEN	(1<<0)	/* UART enabled */
>  #define UCR2_ESCI	(1<<15)	/* Escape seq interrupt enable */
> @@ -126,6 +130,7 @@
>  #define UCR4_ENIRI	(1<<8)	/* Serial infrared interrupt enable */
>  #define UCR4_WKEN	(1<<7)	/* Wake interrupt enable */
>  #define UCR4_REF16	(1<<6)	/* Ref freq 16 MHz */
> +#define UCR4_IDDMAEN    (1<<6)  /* DMA IDLE Condition Detected */
>  #define UCR4_IRSC	(1<<5)	/* IR special case */
>  #define UCR4_TCEN	(1<<3)	/* Transmit complete interrupt enable */
>  #define UCR4_BKEN	(1<<2)	/* Break condition interrupt enable */
> @@ -210,6 +215,19 @@ struct imx_port {
>  	struct clk		*clk_ipg;
>  	struct clk		*clk_per;
>  	const struct imx_uart_data *devdata;
> +
> +	/* DMA fields */
> +	unsigned int		dma_is_inited:1;
> +	unsigned int		dma_is_enabled:1;
> +	unsigned int		dma_is_rxing:1;
> +	unsigned int		dma_is_txing:1;
> +	struct dma_chan		*dma_chan_rx, *dma_chan_tx;
> +	struct scatterlist	rx_sgl, tx_sgl[2];
> +	void			*rx_buf;
> +	unsigned int		rx_bytes, tx_bytes;
> +	struct work_struct	tsk_dma_rx, tsk_dma_tx;
> +	unsigned int		dma_tx_nents;
> +	wait_queue_head_t	dma_wait;
>  };
>  
>  struct imx_port_ucrs {
> @@ -400,6 +418,13 @@ static void imx_stop_tx(struct uart_port *port)
>  		return;
>  	}
>  
> +	/*
> +	 * We are maybe in the SMP context, so if the DMA TX thread is running
> +	 * on other cpu, we have to wait for it to finish.
> +	 */
> +	if (sport->dma_is_enabled && sport->dma_is_txing)
> +		return;
> +
>  	temp = readl(sport->port.membase + UCR1);
>  	writel(temp & ~UCR1_TXMPTYEN, sport->port.membase + UCR1);
>  }
> @@ -412,6 +437,13 @@ static void imx_stop_rx(struct uart_port *port)
>  	struct imx_port *sport = (struct imx_port *)port;
>  	unsigned long temp;
>  
> +	/*
> +	 * We are maybe in the SMP context, so if the DMA TX thread is running
> +	 * on other cpu, we have to wait for it to finish.
> +	 */
> +	if (sport->dma_is_enabled && sport->dma_is_rxing)
> +		return;
> +
>  	temp = readl(sport->port.membase + UCR2);
>  	writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
>  }
> @@ -447,6 +479,96 @@ static inline void imx_transmit_buffer(struct imx_port *sport)
>  		imx_stop_tx(&sport->port);
>  }
>  
> +static void dma_tx_callback(void *data)
> +{
> +	struct imx_port *sport = data;
> +	struct scatterlist *sgl = &sport->tx_sgl[0];
> +	struct circ_buf *xmit = &sport->port.state->xmit;
> +	unsigned long flags;
> +
> +	dma_unmap_sg(sport->port.dev, sgl, sport->dma_tx_nents, DMA_TO_DEVICE);
> +
> +	sport->dma_is_txing = 0;
> +
> +	/* update the stat */
> +	spin_lock_irqsave(&sport->port.lock, flags);
> +	xmit->tail = (xmit->tail + sport->tx_bytes) & (UART_XMIT_SIZE - 1);
> +	sport->port.icount.tx += sport->tx_bytes;
> +	spin_unlock_irqrestore(&sport->port.lock, flags);
> +
> +	dev_dbg(sport->port.dev, "we finish the TX DMA.\n");
> +
> +	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
> +		uart_write_wakeup(&sport->port);
> +
> +	if (waitqueue_active(&sport->dma_wait)) {
> +		wake_up(&sport->dma_wait);
> +		dev_dbg(sport->port.dev, "exit in %s.\n", __func__);
> +		return;
> +	}
> +
> +	schedule_work(&sport->tsk_dma_tx);
> +}
> +
> +static void dma_tx_work(struct work_struct *w)
> +{
> +	struct imx_port *sport = container_of(w, struct imx_port, tsk_dma_tx);
> +	struct circ_buf *xmit = &sport->port.state->xmit;
> +	struct scatterlist *sgl = sport->tx_sgl;
> +	struct dma_async_tx_descriptor *desc;
> +	struct dma_chan	*chan = sport->dma_chan_tx;
> +	struct device *dev = sport->port.dev;
> +	enum dma_status status;
> +	unsigned long flags;
> +	int ret;
> +
> +	status = chan->device->device_tx_status(chan, (dma_cookie_t)0, NULL);
> +	if (DMA_IN_PROGRESS == status)
> +		return;
> +
> +	spin_lock_irqsave(&sport->port.lock, flags);
> +	sport->tx_bytes = uart_circ_chars_pending(xmit);
> +	if (sport->tx_bytes == 0) {
> +		spin_unlock_irqrestore(&sport->port.lock, flags);
> +		return;
> +	}
> +
> +	if (xmit->tail > xmit->head) {
> +		sport->dma_tx_nents = 2;
> +		sg_init_table(sgl, 2);
> +		sg_set_buf(sgl, xmit->buf + xmit->tail,
> +				UART_XMIT_SIZE - xmit->tail);
> +		sg_set_buf(sgl + 1, xmit->buf, xmit->head);
> +	} else {
> +		sport->dma_tx_nents = 1;
> +		sg_init_one(sgl, xmit->buf + xmit->tail, sport->tx_bytes);
> +	}
> +	spin_unlock_irqrestore(&sport->port.lock, flags);
> +
> +	ret = dma_map_sg(dev, sgl, sport->dma_tx_nents, DMA_TO_DEVICE);
> +	if (ret == 0) {
> +		dev_err(dev, "DMA mapping error for TX.\n");
> +		return;
> +	}
> +	desc = dmaengine_prep_slave_sg(chan, sgl, sport->dma_tx_nents,
> +					DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT);
> +	if (!desc) {
> +		dev_err(dev, "We cannot prepare for the TX slave dma!\n");
> +		return;
> +	}
> +	desc->callback = dma_tx_callback;
> +	desc->callback_param = sport;
> +
> +	sport->dma_is_txing = 1;
> +
> +	dev_dbg(dev, "TX: prepare to send %lu bytes by DMA.\n",
> +			uart_circ_chars_pending(xmit));
> +	/* fire it */
> +	dmaengine_submit(desc);
> +	dma_async_issue_pending(chan);
> +	return;
> +}
> +
>  /*
>   * interrupts disabled on entry
>   */
> @@ -473,8 +595,10 @@ static void imx_start_tx(struct uart_port *port)
>  	temp |= UCR4_OREN;
>  	writel(temp, sport->port.membase + UCR4);
>  
> -	temp = readl(sport->port.membase + UCR1);
> -	writel(temp | UCR1_TXMPTYEN, sport->port.membase + UCR1);
> +	if (!sport->dma_is_enabled) {
> +		temp = readl(sport->port.membase + UCR1);
> +		writel(temp | UCR1_TXMPTYEN, sport->port.membase + UCR1);
> +	}
>  
>  	if (USE_IRDA(sport)) {
>  		temp = readl(sport->port.membase + UCR1);
> @@ -486,6 +610,15 @@ static void imx_start_tx(struct uart_port *port)
>  		writel(temp, sport->port.membase + UCR4);
>  	}
>  
> +	if (sport->dma_is_enabled) {
> +		/*
> +		 * We may in the interrupt context, so arise a work_struct to
> +		 * do the real job.
> +		 */
> +		schedule_work(&sport->tsk_dma_tx);
> +		return;
> +	}
> +
>  	if (readl(sport->port.membase + uts_reg(sport)) & UTS_TXEMPTY)
>  		imx_transmit_buffer(sport);
>  }
> @@ -601,6 +734,28 @@ out:
>  	return IRQ_HANDLED;
>  }
>  
> +/*
> + * If the RXFIFO is filled with some data, and then we
> + * arise a DMA operation to receive them.
> + */
> +static void imx_dma_rxint(struct imx_port *sport)
> +{
> +	unsigned long temp;
> +
> +	temp = readl(sport->port.membase + USR2);
> +	if ((temp & USR2_RDR) && !sport->dma_is_rxing) {
> +		sport->dma_is_rxing = 1;
> +
> +		/* disable the `Recerver Ready Interrrupt` */
> +		temp = readl(sport->port.membase + UCR1);
> +		temp &= ~(UCR1_RRDYEN);
> +		writel(temp, sport->port.membase + UCR1);
> +
> +		/* tell the DMA to receive the data. */
> +		schedule_work(&sport->tsk_dma_rx);
> +	}
> +}
> +
>  static irqreturn_t imx_int(int irq, void *dev_id)
>  {
>  	struct imx_port *sport = dev_id;
> @@ -609,8 +764,12 @@ static irqreturn_t imx_int(int irq, void *dev_id)
>  
>  	sts = readl(sport->port.membase + USR1);
>  
> -	if (sts & USR1_RRDY)
> -		imx_rxint(irq, dev_id);
> +	if (sts & USR1_RRDY) {
> +		if (sport->dma_is_enabled)
> +			imx_dma_rxint(sport);
> +		else
> +			imx_rxint(irq, dev_id);
> +	}
>  
>  	if (sts & USR1_TRDY &&
>  			readl(sport->port.membase + UCR1) & UCR1_TXMPTYEN)
> @@ -667,7 +826,8 @@ static void imx_set_mctrl(struct uart_port *port, unsigned int mctrl)
>  	temp = readl(sport->port.membase + UCR2) & ~UCR2_CTS;
>  
>  	if (mctrl & TIOCM_RTS)
> -		temp |= UCR2_CTS;
> +		if (!sport->dma_is_enabled)
> +			temp |= UCR2_CTS;
>  
>  	writel(temp, sport->port.membase + UCR2);
>  }
> @@ -706,6 +866,226 @@ static int imx_setup_ufcr(struct imx_port *sport, unsigned int mode)
>  	return 0;
>  }
>  
> +#define RX_BUF_SIZE	(PAGE_SIZE)
> +static int start_rx_dma(struct imx_port *sport);
> +static void dma_rx_work(struct work_struct *w)
> +{
> +	struct imx_port *sport = container_of(w, struct imx_port, tsk_dma_rx);
> +	struct tty_port *port = &sport->port.state->port;
> +
> +	if (sport->rx_bytes) {
> +		tty_insert_flip_string(port, sport->rx_buf, sport->rx_bytes);
> +		tty_flip_buffer_push(port);
> +		sport->rx_bytes = 0;
> +	}
> +
> +	if (sport->dma_is_rxing)
> +		start_rx_dma(sport);
> +}
> +
> +static void imx_rx_dma_done(struct imx_port *sport)
> +{
> +	unsigned long temp;
> +
> +	/* Enable this interrupt when the RXFIFO is empty. */
> +	temp = readl(sport->port.membase + UCR1);
> +	temp |= UCR1_RRDYEN;
> +	writel(temp, sport->port.membase + UCR1);
> +
> +	sport->dma_is_rxing = 0;
> +
> +	/* Is the shutdown waiting for us? */
> +	if (waitqueue_active(&sport->dma_wait))
> +		wake_up(&sport->dma_wait);
> +}
> +
> +/*
> + * There are three kinds of RX DMA interrupts(such as in the MX6Q):
> + *   [1] the RX DMA buffer is full.
> + *   [2] the Aging timer expires(wait for 8 bytes long)
> + *   [3] the Idle Condition Detect(enabled the UCR4_IDDMAEN).
> + *
> + * The [2] is trigger when a character was been sitting in the FIFO
> + * meanwhile [3] can wait for 32 bytes long when the RX line is
> + * on IDLE state and RxFIFO is empty.
> + */
> +static void dma_rx_callback(void *data)
> +{
> +	struct imx_port *sport = data;
> +	struct dma_chan	*chan = sport->dma_chan_rx;
> +	unsigned int count;
> +	struct tty_struct *tty;
> +	struct scatterlist *sgl;
> +	struct dma_tx_state state;
> +	enum dma_status status;
> +
> +	tty = sport->port.state->port.tty;
> +	sgl = &sport->rx_sgl;
> +
> +	/* unmap it first */
> +	dma_unmap_sg(sport->port.dev, sgl, 1, DMA_FROM_DEVICE);
> +
> +	status = chan->device->device_tx_status(chan, (dma_cookie_t)0, &state);
> +	count = RX_BUF_SIZE - state.residue;
> +	dev_dbg(sport->port.dev, "We get %d bytes.\n", count);
> +
> +	if (count) {
> +		sport->rx_bytes = count;
> +		schedule_work(&sport->tsk_dma_rx);
> +	} else
> +		imx_rx_dma_done(sport);
> +}
> +
> +static int start_rx_dma(struct imx_port *sport)
> +{
> +	struct scatterlist *sgl = &sport->rx_sgl;
> +	struct dma_chan	*chan = sport->dma_chan_rx;
> +	struct device *dev = sport->port.dev;
> +	struct dma_async_tx_descriptor *desc;
> +	int ret;
> +
> +	sg_init_one(sgl, sport->rx_buf, RX_BUF_SIZE);
> +	ret = dma_map_sg(dev, sgl, 1, DMA_FROM_DEVICE);
> +	if (ret == 0) {
> +		dev_err(dev, "DMA mapping error for RX.\n");
> +		return -EINVAL;
> +	}
> +	desc = dmaengine_prep_slave_sg(chan, sgl, 1, DMA_DEV_TO_MEM,
> +					DMA_PREP_INTERRUPT);
> +	if (!desc) {
> +		dev_err(dev, "We cannot prepare for the RX slave dma!\n");
> +		return -EINVAL;
> +	}
> +	desc->callback = dma_rx_callback;
> +	desc->callback_param = sport;
> +
> +	dev_dbg(dev, "RX: prepare for the DMA.\n");
> +	dmaengine_submit(desc);
> +	dma_async_issue_pending(chan);
> +	return 0;
> +}
> +
> +static void imx_uart_dma_exit(struct imx_port *sport)
> +{
> +	if (sport->dma_chan_rx) {
> +		dma_release_channel(sport->dma_chan_rx);
> +		sport->dma_chan_rx = NULL;
> +
> +		kfree(sport->rx_buf);
> +		sport->rx_buf = NULL;
> +	}
> +
> +	if (sport->dma_chan_tx) {
> +		dma_release_channel(sport->dma_chan_tx);
> +		sport->dma_chan_tx = NULL;
> +	}
> +}
> +
> +static int imx_uart_dma_init(struct imx_port *sport)
> +{
> +	struct dma_slave_config slave_config;
> +	struct device *dev = sport->port.dev;
> +	int ret;
> +
> +	/* Prepare for RX : */
> +	sport->dma_chan_rx = dma_request_slave_channel(dev, "rx");
> +	if (!sport->dma_chan_rx) {
> +		dev_err(dev, "cannot get the DMA channel.\n");
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	slave_config.direction = DMA_DEV_TO_MEM;
> +	slave_config.src_addr = sport->port.mapbase + URXD0;
> +	slave_config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
> +	slave_config.src_maxburst = RXTL;
> +	ret = dmaengine_slave_config(sport->dma_chan_rx, &slave_config);
> +	if (ret) {
> +		dev_err(dev, "error in RX dma configuration.\n");
> +		goto err;
> +	}
> +
> +	sport->rx_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
> +	if (!sport->rx_buf) {
> +		dev_err(dev, "cannot alloc DMA buffer.\n");
> +		ret = -ENOMEM;
> +		goto err;
> +	}
> +	sport->rx_bytes = 0;
> +
> +	/* Prepare for TX : */
> +	sport->dma_chan_tx = dma_request_slave_channel(dev, "tx");
> +	if (!sport->dma_chan_tx) {
> +		dev_err(dev, "cannot get the TX DMA channel!\n");
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	slave_config.direction = DMA_MEM_TO_DEV;
> +	slave_config.dst_addr = sport->port.mapbase + URTX0;
> +	slave_config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
> +	slave_config.dst_maxburst = TXTL;
> +	ret = dmaengine_slave_config(sport->dma_chan_tx, &slave_config);
> +	if (ret) {
> +		dev_err(dev, "error in TX dma configuration.");
> +		goto err;
> +	}
> +
> +	return 0;
> +err:
> +	imx_uart_dma_exit(sport);
> +	return ret;
> +}
> +
> +static void imx_enable_dma(struct imx_port *sport)
> +{
> +	unsigned long temp;
> +	struct tty_port *port = &sport->port.state->port;
> +
> +	port->low_latency = 1;
> +	INIT_WORK(&sport->tsk_dma_tx, dma_tx_work);
> +	INIT_WORK(&sport->tsk_dma_rx, dma_rx_work);
> +	init_waitqueue_head(&sport->dma_wait);

I had a hard time to understand why these work and wait queue are
necessarily needed here.

I haven't totally understand it.  But it looks like to me that the
implementation might be complexer than it needs to be.  Can you please
take a look at serial-tegra.c to see how the DMA is supported there?
It looks much neater than the changes we have here.

> +
> +	/* set UCR1 */
> +	temp = readl(sport->port.membase + UCR1);
> +	temp |= UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN |
> +		/* wait for 4 idle frames and enable AGING Timer */
> +		UCR1_ICD_REG(0);
> +	writel(temp, sport->port.membase + UCR1);
> +
> +	/* set UCR4 */
> +	temp = readl(sport->port.membase + UCR4);
> +	temp |= UCR4_IDDMAEN;
> +	writel(temp, sport->port.membase + UCR4);
> +}
> +
> +static void imx_disable_dma(struct imx_port *sport)
> +{
> +	unsigned long temp;
> +	struct tty_port *port = &sport->port.state->port;
> +
> +	/* clear UCR1 */
> +	temp = readl(sport->port.membase + UCR1);
> +	temp &= ~(UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN);
> +	writel(temp, sport->port.membase + UCR1);
> +
> +	/* clear UCR2 */
> +	temp = readl(sport->port.membase + UCR2);
> +	temp &= ~(UCR2_CTSC | UCR2_CTS);
> +	writel(temp, sport->port.membase + UCR2);
> +
> +	/* clear UCR4 */
> +	temp = readl(sport->port.membase + UCR4);
> +	temp &= ~UCR4_IDDMAEN;
> +	writel(temp, sport->port.membase + UCR4);
> +
> +	sport->dma_is_enabled = 0;
> +	sport->dma_is_inited = 0;

Shouldn't dma_is_inited be reset in imx_uart_dma_exit() for better?
(I haven't looked at the necessity of these flags.  But please save
the use of them if we can.)

> +
> +	port->low_latency = 0;
> +}
> +
>  /* half the RX buffer size */
>  #define CTSTL 16
>  
> @@ -870,6 +1250,14 @@ static void imx_shutdown(struct uart_port *port)
>  	unsigned long temp;
>  	unsigned long flags;
>  
> +	if (sport->dma_is_enabled) {
> +		/* We have to wait for the DMA to finish. */
> +		wait_event(sport->dma_wait,
> +			!sport->dma_is_rxing && !sport->dma_is_txing);
> +		imx_stop_rx(port);
> +		imx_uart_dma_exit(sport);
> +	}
> +
>  	spin_lock_irqsave(&sport->port.lock, flags);
>  	temp = readl(sport->port.membase + UCR2);
>  	temp &= ~(UCR2_TXEN);
> @@ -910,6 +1298,10 @@ static void imx_shutdown(struct uart_port *port)
>  		temp &= ~(UCR1_IREN);
>  
>  	writel(temp, sport->port.membase + UCR1);
> +
> +	if (sport->dma_is_enabled)
> +		imx_disable_dma(sport);
> +

Shouldn't imx_disable_dma() be called before imx_uart_dma_exit()
logically?

>  	spin_unlock_irqrestore(&sport->port.lock, flags);
>  
>  	clk_disable_unprepare(sport->clk_per);
> @@ -956,6 +1348,13 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
>  		if (sport->have_rtscts) {
>  			ucr2 &= ~UCR2_IRTS;
>  			ucr2 |= UCR2_CTSC;
> +
> +			/* Can we enable the DMA support? */
> +			if (is_imx6_uart(sport) && !uart_console(port)
> +				&& !sport->dma_is_inited) {
> +				if (!imx_uart_dma_init(sport))
> +					sport->dma_is_inited = 1;

I think the setting of the flag can just be handled inside
imx_uart_dma_init().


> +			}
>  		} else {
>  			termios->c_cflag &= ~CRTSCTS;
>  		}
> @@ -1069,6 +1468,10 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
>  	if (UART_ENABLE_MS(&sport->port, termios->c_cflag))
>  		imx_enable_ms(&sport->port);
>  
> +	if (sport->dma_is_inited && !sport->dma_is_enabled) {
> +		imx_enable_dma(sport);
> +		sport->dma_is_enabled = 1;

Ditto

> +	}

I see imx_disable_dma() and imx_uart_dma_exit() are called in
imx_shutdown().  Why can not imx_uart_dma_init() and imx_enable_dma()
be called in imx_startup()?

Shawn

>  	spin_unlock_irqrestore(&sport->port.lock, flags);
>  }
>  
> -- 
> 1.7.1
> 
> 



From roy.franz at linaro.org  Tue Jul  2 23:45:10 2013
From: roy.franz at linaro.org (Roy Franz)
Date: Tue,  2 Jul 2013 20:45:10 -0700
Subject: [PATCH] ARM: Add kernel build # to build message
Message-ID: <1372823110-18170-1-git-send-email-roy.franz@linaro.org>

from: Roy Franz <roy.franz at linaro.org>

Add the display of the incrementing kernel build number, similar
to the x86 build.  Example output:
Kernel: arch/arm/boot/zImage is ready  (#94)

Signed-off-by: Roy Franz <roy.franz at linaro.org>

---
 arch/arm/boot/Makefile |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index 84aa2ca..f1192f5 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -31,7 +31,7 @@ ifeq ($(CONFIG_XIP_KERNEL),y)
 
 $(obj)/xipImage: vmlinux FORCE
 	$(call if_changed,objcopy)
-	@$(kecho) '  Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))'
+	@$(kecho) '  Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))' ' (#'`cat .version`')'
 
 $(obj)/Image $(obj)/zImage: FORCE
 	@echo 'Kernel configured for XIP (CONFIG_XIP_KERNEL=y)'
@@ -46,14 +46,14 @@ $(obj)/xipImage: FORCE
 
 $(obj)/Image: vmlinux FORCE
 	$(call if_changed,objcopy)
-	@$(kecho) '  Kernel: $@ is ready'
+	@$(kecho) '  Kernel: $@ is ready' ' (#'`cat .version`')'
 
 $(obj)/compressed/vmlinux: $(obj)/Image FORCE
 	$(Q)$(MAKE) $(build)=$(obj)/compressed $@
 
 $(obj)/zImage:	$(obj)/compressed/vmlinux FORCE
 	$(call if_changed,objcopy)
-	@$(kecho) '  Kernel: $@ is ready'
+	@$(kecho) '  Kernel: $@ is ready' ' (#'`cat .version`')'
 
 endif
 
@@ -78,7 +78,7 @@ fi
 $(obj)/uImage:	$(obj)/zImage FORCE
 	@$(check_for_multiple_loadaddr)
 	$(call if_changed,uimage)
-	@$(kecho) '  Image $@ is ready'
+	@$(kecho) '  Image $@ is ready' ' (#'`cat .version`')'
 
 $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
 	$(Q)$(MAKE) $(build)=$(obj)/bootp $@
@@ -86,7 +86,7 @@ $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
 
 $(obj)/bootpImage: $(obj)/bootp/bootp FORCE
 	$(call if_changed,objcopy)
-	@$(kecho) '  Kernel: $@ is ready'
+	@$(kecho) '  Kernel: $@ is ready' ' (#'`cat .version`')'
 
 PHONY += initrd FORCE
 initrd:
-- 
1.7.10.4



From magnus.damm at gmail.com  Wed Jul  3 00:02:52 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 3 Jul 2013 13:02:52 +0900
Subject: [PATCH v2 1/2] ARM: shmobile: r8a7790: Initialise clocks and SCIF
 in r8a7790_add_dt_devices()
In-Reply-To: <1372645120-27256-2-git-send-email-horms+renesas@verge.net.au>
References: <1372645120-27256-1-git-send-email-horms+renesas@verge.net.au>
 <1372645120-27256-2-git-send-email-horms+renesas@verge.net.au>
Message-ID: <CANqRtoRKzbgBNt=Ztise5eeqnbiFWCZZZkhAq0zCnjjoetGFkg@mail.gmail.com>

Hi Simon,

On Mon, Jul 1, 2013 at 11:18 AM, Simon Horman
<horms+renesas at verge.net.au> wrote:
> This is sufficient to allow boot of the Lager board with
> a console without boards-lager.c compiled into the kernel.
> This is an example of a minimal but still useful initialisation
> of the board using DT as much as possible.
>
> Also provide r8a7790_add_dt_device() in
> r8a7790.h to allow it be used from a boards-lager-reference.c
> file which will be added by a subsequent patch.
>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
>
> ---
>
> v2
>
> * Rebase
> ---
>  arch/arm/mach-shmobile/include/mach/r8a7790.h |  1 +
>  arch/arm/mach-shmobile/setup-r8a7790.c        | 11 ++++++++++-
>  2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h b/arch/arm/mach-shmobile/include/mach/r8a7790.h
> index 7851cc1..7a25138 100644
> --- a/arch/arm/mach-shmobile/include/mach/r8a7790.h
> +++ b/arch/arm/mach-shmobile/include/mach/r8a7790.h
> @@ -2,6 +2,7 @@
>  #define __ASM_R8A7790_H__
>
>  void r8a7790_add_standard_devices(void);
> +void r8a7790_add_standard_devices_dt(void);
>  void r8a7790_clock_init(void);
>  void r8a7790_pinmux_init(void);
>  void r8a7790_init_delay(void);
> diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
> index d89cd83..770109b 100644
> --- a/arch/arm/mach-shmobile/setup-r8a7790.c
> +++ b/arch/arm/mach-shmobile/setup-r8a7790.c
> @@ -180,7 +180,7 @@ static struct resource cmt00_resources[] = {
>                                           &cmt##idx##_platform_data,    \
>                                           sizeof(struct sh_timer_config))
>
> -void __init r8a7790_add_standard_devices(void)
> +void __init r8a7790_add_dt_devices(void)
>  {
>         r8a7790_register_scif(SCIFA0);
>         r8a7790_register_scif(SCIFA1);
> @@ -192,6 +192,11 @@ void __init r8a7790_add_standard_devices(void)
>         r8a7790_register_scif(SCIF1);
>         r8a7790_register_scif(HSCIF0);
>         r8a7790_register_scif(HSCIF1);
> +}
> +
> +void __init r8a7790_add_standard_devices(void)
> +{
> +       r8a7790_add_dt_devices();
>         r8a7790_register_irqc(0);
>         r8a7790_register_thermal();
>         r8a7790_register_cmt(00);
> @@ -219,6 +224,10 @@ void __init r8a7790_init_delay(void)
>  #ifdef CONFIG_USE_OF
>  void __init r8a7790_add_standard_devices_dt(void)
>  {
> +       /* clocks are setup late during boot in the case of DT */
> +       r8a7790_clock_init();
> +
> +       r8a7790_add_dt_devices();
>         of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>  }
>
> --
> 1.8.2.1

In this patch you modify r8a7790_add_standard_devices_dt() to include
clocks. I prefer not to make this kind of modification to the generic
r8a7790 DT code since it clashes with upcoming common clock framework
changes. I would like to keep the generic per-SoC DT_MACHINE bits so
they don't enable legacy clocks.

Also, as you probably noticed, this patch conflicts with the idea to
keep ->init_machine() set to NULL for modern platforms.

Despite what I said yesterday, I think it would be very useful to have
Lager DT reference board code around even though SCIF can't do DT yet.

How about keeping the DT_MACHINE stuff for r8a7790 in setup-r8a7790.c
as-is, but in your board-lager-reference.c you have a temporary
version of ->init_machine() that enables clocks, adds SCIF (and CMT?)
as platform devices, but does the rest via DT? Then when SCIF is ready
we can drop the C code for the DT reference board support.

Cheers,

/ magnus


From w at 1wt.eu  Wed Jul  3 00:33:30 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Wed, 3 Jul 2013 06:33:30 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130702232311.GA3949@localhost>
References: <20130702124639.GI19937@titan.lakedaemon.net>
 <20130702151407.01680d21@skate> <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate> <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org> <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
 <20130702232311.GA3949@localhost>
Message-ID: <20130703043330.GF10215@1wt.eu>

Hi Ezequiel,

On Tue, Jul 02, 2013 at 08:23:12PM -0300, Ezequiel Garcia wrote:
> > Yes and indeed I must say that when I read the driver I found some
> > similarities with pxa3xx, though it was done differently. I initially
> > wanted to try to merge them but of course without the spec it's a huge
> > waste of time, especially considering that this is still in the roadmap
> > of the Free Electrons guys even though low priority.
> 
> I wish I could say I'm going to work on this soon but, as Thomas said,
> we have no idea when/if NAND will be prioritized.
> 
> On the other side if you look at the driver Willy just posted, merging
> the juicy stuff into pxa3xx-nand driver is not for the faint of heart.
> 
> Without the spec, is only tougher.

Confirmed :-)

> Just a quick hint. As far as I can recall, one of the first items in a
> TODO list should be:
> 
>  * adding bigger page support to pxa3xx (4 KiB, 8 KiB).
>    Willy's posted driver might be helpful to accomplish this;
>    provided your eyes don't melt when you look at it :-)
> 
>  * once the above is done, bad block management can/should be added.
> 
> With these two we're almost there for R/W support.

Since the driver I posted is poorly commented, I'm not even sure it
will be easy to spot the relevant parts in it.

> > Since I'm now flashing a rootfs from within u-boot, support for the
> > NAND is of less importance to me than what it used to, but I have no
> > problem with helping with my very limited time. I have 3 machines
> > with this controller (mirabox, openblocks AX3, and an XP-GP, though
> 
> With my latest patches pxa3xx-nand should at least *detect* the NAND
> device in XP-GP. Doesn't work for Mirabox, though.

OK good to know!

> > the AX3 only has NOR IIRC). I can do some tests if you manage to get
> > the driver to work again.
> > 
> > Be very careful when playing with this, the driver expects the partition
> > table to be passed from u-boot as "armada_nand", and if it uses the wrong
> > partition layout, you can be certain that ubifs will destroy them at the
> > first mount attempt. That's how I initially bricked my mirabox and did so
> > repeatedly. Better keep a copy before booting the patched kernel!
> > 
> > Another point, I had to add a new entry for the Micro 8Gb flash of the
> > mirabox, maybe you won't need it or maybe you'll need a different one.
> 
> Just a note about this. You need that entry because your driver doesn't
> support ONFI-detected flash devices. You could workaround that, by
> adding support simple command. I did it for pxa3xx-nand recently:
> 
> "mtd: nand: pxa3xx: Add address support for READID command"
> http://permalink.gmane.org/gmane.linux.drivers.mtd/46606

I remember having seen your patches, I didn't know that it allowed
to use such flashes and now it makes sense because I was surprized
about having to add entries for all possible devices while we're
not even certain that two consecutive versions of a board will use
the same brand of NAND devices.

Thanks for sharing these information, Ezequiel!

Willy



From gururaja.hebbar at ti.com  Wed Jul  3 01:03:05 2013
From: gururaja.hebbar at ti.com (Hebbar, Gururaja)
Date: Wed, 3 Jul 2013 05:03:05 +0000
Subject: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-4-git-send-email-gururaja.hebbar@ti.com>
 <51D26CFA.5090500@ti.com>
 <1BAFE6F6C881BF42822005164F1491C33EC4E7AB@DBDE04.ent.ti.com>
 <51D26E98.9040303@ti.com>
 <1BAFE6F6C881BF42822005164F1491C33EC4E7CC@DBDE04.ent.ti.com>
 <51D27052.6080303@ti.com> 
Message-ID: <1BAFE6F6C881BF42822005164F1491C33EC4F8CA@DBDE04.ent.ti.com>

Hi all,

Kindly ignore this message. It was sent in wrong format.

Sorry for the noise

Regards, 
Gururaja

On Wed, Jul 03, 2013 at 10:26:57, Hebbar, Gururaja wrote:
> Below is the code snippet I was referring to
>  
>  
> From drivers/rtc/rtc-omap.c
>  
> static struct platform_device_id omap_rtc_devtype[] = {
>       {
>             .name = DRIVER_NAME,
>       },
>       [OMAP_RTC_DATA_AM3352_IDX] = {
>             .name = "am3352-rtc",
>             .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
>       },
>       [OMAP_RTC_DATA_DA830_IDX] = {
>             .name = "da830-rtc",
>             .driver_data = OMAP_RTC_HAS_KICKER,
>      },
>       {},
> };
> MODULE_DEVICE_TABLE(platform, omap_rtc_devtype);
>  
> static const struct of_device_id omap_rtc_of_match[] = {
>       {     .compatible = "ti,da830-rtc",
>             .data       = &omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
>       },
>       {     .compatible = "ti,am3352-rtc",
>             .data       = &omap_rtc_devtype[OMAP_RTC_DATA_AM3352_IDX],
>       },
>       {},
> };
> MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
>  
>  
> From arch/arm/boot/dts/am33xx.dtsi
>  
>             rtc at 44e3e000 {
>                   compatible = "ti,da830-rtc", "ti,am3352-rtc";
>                   reg = <0x44e3e000 0x1000>;
>                   interrupts = <75
>                               76>;
>                   ti,hwmods = "rtc";
>             };
>  
>  
> As seen from above snippet, 2 compatible items are specified for
> compatible dt property (ti,da830-rtc" & "ti,am3352-rtc?)
> These are the same compatibles that are mentioned in the of_device_id
> structure inside rtc-omap driver.
>  
> What I observed is, if we mention both compatible in the .dtsi file that
> are under one single of_device_id structure, the first match from the
> of_device_id structure is considered (ti,da830-rtc in above case)
>  
> To confirm, I switched the 2 compatible inside of_device_id structure as
> below
>  
>  
> static const struct of_device_id omap_rtc_of_match[] = {
>       {     .compatible = "ti,am3352-rtc",
>             .data       = &omap_rtc_devtype[OMAP_RTC_DATA_AM3352_IDX],
>       },
>       {     .compatible = "ti,da830-rtc",
>             .data       = &omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
>       },
>       {},
> };
>  
> In this case, the first match from compatible field was chosen
> (ti,am3352-rtc now).
>  
>  
> Hope this is clear.
>  
> Kindly let me know when you are free to discuss.
>  
>  
> Regards
> Gururaja
>  
> > -----Original Message-----
> > From: Nori, Sekhar
> > Sent: Tuesday, July 02, 2013 11:47 AM
> > To: Hebbar, Gururaja
> > Cc: khilman at linaro.org; tony at atomide.com; Cousson, Benoit; linux-
> > omap at vger.kernel.org; devicetree-discuss at lists.ozlabs.org; linux-
> > kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > davinci-linux-open-source at linux.davincidsp.com; Bedia, Vaibhav;
> > Rajashekhara, Sudhakar; Grant Likely; Rob Herring; Rob Landley;
> > Alessandro Zummo; rtc-linux at googlegroups.com; linux-
> > doc at vger.kernel.org
> > Subject: Re: [PATCH 3/4] rtc: omap: add rtc wakeup support to
> > alarm events
> > 
> > 
> > 
> > On 7/2/2013 11:41 AM, Hebbar, Gururaja wrote:
> > > On Tue, Jul 02, 2013 at 11:39:28, Nori, Sekhar wrote:
> > >> On 7/2/2013 11:34 AM, Hebbar, Gururaja wrote:
> > >>> On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
> > >>>> On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> > >>>>> On some platforms (like AM33xx), a special register
> > (RTC_IRQWAKEEN)
> > >>>>> is available to enable Alarm Wakeup feature. This register
> > needs to be
> > >>>>> properly handled for the rtcwake to work properly.
> > >>>>>
> > >>>>> Platforms using such IP should set "ti,am3352-rtc" in rtc
> > device dt
> > >>>>> compatibility node.
> > >>>>>
> > >>>>> Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com
> <mailto:gururaja.hebbar at ti.com> >
> > >>>>> Cc: Grant Likely <grant.likely at linaro.org
> <mailto:grant.likely at linaro.org> >
> > >>>>> Cc: Rob Herring <rob.herring at calxeda.com
> <mailto:rob.herring at calxeda.com> >
> > >>>>> Cc: Rob Landley <rob at landley.net <mailto:rob at landley.net> >
> > >>>>> Cc: Sekhar Nori <nsekhar at ti.com <mailto:nsekhar at ti.com> >
> > >>>>> Cc: Kevin Hilman <khilman at linaro.org <mailto:khilman at linaro.org>
> >
> > >>>>> Cc: Alessandro Zummo <a.zummo at towertech.it
> <mailto:a.zummo at towertech.it> >
> > >>>>> Cc: rtc-linux at googlegroups.com
> <mailto:rtc-linux at googlegroups.com> 
> > >>>>> Cc: devicetree-discuss at lists.ozlabs.org
> <mailto:devicetree-discuss at lists.ozlabs.org> 
> > >>>>> Cc: linux-doc at vger.kernel.org <mailto:linux-doc at vger.kernel.org>
> > >>>>> ---
> > >>>>
> > >>>> [...]
> > >>>>
> > >>>>> -#define  OMAP_RTC_DATA_DA830_IDX 1
> > >>>>> +#define  OMAP_RTC_DATA_DA830_IDX       1
> > >>>>> +#define  OMAP_RTC_DATA_AM335X_IDX      2
> > >>>>>
> > >>>>>  static struct platform_device_id omap_rtc_devtype[] = {
> > >>>>>     {
> > >>>>> @@ -309,6 +321,9 @@ static struct platform_device_id
> > omap_rtc_devtype[] = {
> > >>>>>     }, {
> > >>>>>           .name = "da830-rtc",
> > >>>>>           .driver_data = OMAP_RTC_HAS_KICKER,
> > >>>>> +   }, {
> > >>>>> +         .name = "am335x-rtc",
> > >>>>
> > >>>> may be use am3352-rtc here just to keep the platform device
> > name and of
> > >>>> compatible in sync.
> > >>>
> > >>> Correct. I will update the same in v2.
> > >>>
> > >>>>
> > >>>>> +         .driver_data = OMAP_RTC_HAS_KICKER |
> > OMAP_RTC_HAS_IRQWAKEEN,
> > >>>>>     },
> > >>>>>     {},
> > >>>>
> > >>>> It is better to use the index defined above in the static
> > initialization
> > >>>> so they remain in sync.
> > >>>
> > >>> Sorry. I didn?t get this.
> > >>>
> > >>
> > >> See example below I provided. If its still not clear, let me
> > know what
> > >> is not clear.
> > >>
> > >>>>      ...
> > >>>>      [OMAP_RTC_DATA_DA830_IDX] = {
> > >>>>            .name = "da830-rtc",
> > >>>>            .driver_data = OMAP_RTC_HAS_KICKER,
> > >>>>      },
> > >
> > > Thanks for the clarification. In this case will it ok if I
> > update the previous
> > > member also.
> > 
> > You dont really reference [0] in omap_rtc_of_match[] so even if
> > you
> > leave it as-is, that's fine with me. I am mostly concerned with
> > the
> > index definitions and initialization order being out of sync and
> > that's
> > really not an issue with [0].
> > 
> > Thanks,
> > Sekhar
> 

From b32955 at freescale.com  Wed Jul  3 01:20:20 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 3 Jul 2013 13:20:20 +0800
Subject: [PATCH 2/5] serial: imx: add DMA support for imx6
In-Reply-To: <20130703033837.GE9145@S2101-09.ap.freescale.net>
References: <1372746628-20092-1-git-send-email-b32955@freescale.com>
 <1372746628-20092-3-git-send-email-b32955@freescale.com>
 <20130703033837.GE9145@S2101-09.ap.freescale.net>
Message-ID: <51D3B494.3090700@freescale.com>

? 2013?07?03? 11:38, Shawn Guo ??:
>> static void imx_enable_dma(struct imx_port *sport)
>> >  +{
>> >  +	unsigned long temp;
>> >  +	struct tty_port *port =&sport->port.state->port;
>> >  +
>> >  +	port->low_latency = 1;
>> >  +	INIT_WORK(&sport->tsk_dma_tx, dma_tx_work);
>> >  +	INIT_WORK(&sport->tsk_dma_rx, dma_rx_work);
>> >  +	init_waitqueue_head(&sport->dma_wait);
> I had a hard time to understand why these work and wait queue are
> necessarily needed here.
Blame it on the sdma driver.

For example, we receive some data in the RXFIFO, normally , the 
interrupt handler will
arise a DMA to fetch the data. We will call the 
dmaengine_prep_slave_sg() to prepare for the DMA,
but sdma will call:
->sdma_prep_slave_sg() -->sdma_load_context() --> sdma_run_channel0()

the sdma_run_channel0() will poll for 500us(we have found the 500us is 
not long enough in some case),
that's why i use the work queue:
We should not delay such long in interrupt context.

The same reason for TX.
> I haven't totally understand it.  But it looks like to me that the
> implementation might be complexer than it needs to be.  Can you please
> take a look at serial-tegra.c to see how the DMA is supported there?
serial-tegra.c arises the dma in the interrupt context. maybe its 
dmaengine is better then the imx-sdma.
> It looks much neater than the changes we have here.
>
>> >  +
>> >  +	/* set UCR1 */
>> >  +	temp = readl(sport->port.membase + UCR1);
>> >  +	temp |= UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN |
>> >  +		/* wait for 4 idle frames and enable AGING Timer */
>> >  +		UCR1_ICD_REG(0);
>> >  +	writel(temp, sport->port.membase + UCR1);
>> >  +
>> >  +	/* set UCR4 */
>> >  +	temp = readl(sport->port.membase + UCR4);
>> >  +	temp |= UCR4_IDDMAEN;
>> >  +	writel(temp, sport->port.membase + UCR4);
>> >  +}
>> >  +
>> >  +static void imx_disable_dma(struct imx_port *sport)
>> >  +{
>> >  +	unsigned long temp;
>> >  +	struct tty_port *port =&sport->port.state->port;
>> >  +
>> >  +	/* clear UCR1 */
>> >  +	temp = readl(sport->port.membase + UCR1);
>> >  +	temp&= ~(UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN);
>> >  +	writel(temp, sport->port.membase + UCR1);
>> >  +
>> >  +	/* clear UCR2 */
>> >  +	temp = readl(sport->port.membase + UCR2);
>> >  +	temp&= ~(UCR2_CTSC | UCR2_CTS);
>> >  +	writel(temp, sport->port.membase + UCR2);
>> >  +
>> >  +	/* clear UCR4 */
>> >  +	temp = readl(sport->port.membase + UCR4);
>> >  +	temp&= ~UCR4_IDDMAEN;
>> >  +	writel(temp, sport->port.membase + UCR4);
>> >  +
>> >  +	sport->dma_is_enabled = 0;
>> >  +	sport->dma_is_inited = 0;
> Shouldn't dma_is_inited be reset in imx_uart_dma_exit() for better?
yes. it's ok to set there.
> (I haven't looked at the necessity of these flags.  But please save
> the use of them if we can.)
>
>> >  +
>> >  +	port->low_latency = 0;
>> >  +}
>> >  +
>> >    /* half the RX buffer size */
>> >    #define CTSTL 16
>> >  
>> >  @@ -870,6 +1250,14 @@ static void imx_shutdown(struct uart_port *port)
>> >    	unsigned long temp;
>> >    	unsigned long flags;
>> >  
>> >  +	if (sport->dma_is_enabled) {
>> >  +		/* We have to wait for the DMA to finish. */
>> >  +		wait_event(sport->dma_wait,
>> >  +			!sport->dma_is_rxing&&  !sport->dma_is_txing);
>> >  +		imx_stop_rx(port);
>> >  +		imx_uart_dma_exit(sport);
>> >  +	}
>> >  +
>> >    	spin_lock_irqsave(&sport->port.lock, flags);
>> >    	temp = readl(sport->port.membase + UCR2);
>> >    	temp&= ~(UCR2_TXEN);
>> >  @@ -910,6 +1298,10 @@ static void imx_shutdown(struct uart_port *port)
>> >    		temp&= ~(UCR1_IREN);
>> >  
>> >    	writel(temp, sport->port.membase + UCR1);
>> >  +
>> >  +	if (sport->dma_is_enabled)
>> >  +		imx_disable_dma(sport);
>> >  +
> Shouldn't imx_disable_dma() be called before imx_uart_dma_exit()
> logically?
>
i think it's ok.
I have forgotten why i puted it there. The dma support patch is kept in 
my hand for a long time....

I will try to put the imx_disable_dma() in the imx_uart_dma_exit().
>> >    	spin_unlock_irqrestore(&sport->port.lock, flags);
>> >  
>> >    	clk_disable_unprepare(sport->clk_per);
>> >  @@ -956,6 +1348,13 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
>> >    		if (sport->have_rtscts) {
>> >    			ucr2&= ~UCR2_IRTS;
>> >    			ucr2 |= UCR2_CTSC;
>> >  +
>> >  +			/* Can we enable the DMA support? */
>> >  +			if (is_imx6_uart(sport)&&  !uart_console(port)
>> >  +				&&  !sport->dma_is_inited) {
>> >  +				if (!imx_uart_dma_init(sport))
>> >  +					sport->dma_is_inited = 1;
> I think the setting of the flag can just be handled inside
> imx_uart_dma_init().
>
ok.
>> >  +			}
>> >    		} else {
>> >    			termios->c_cflag&= ~CRTSCTS;
>> >    		}
>> >  @@ -1069,6 +1468,10 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
>> >    	if (UART_ENABLE_MS(&sport->port, termios->c_cflag))
>> >    		imx_enable_ms(&sport->port);
>> >  
>> >  +	if (sport->dma_is_inited&&  !sport->dma_is_enabled) {
>> >  +		imx_enable_dma(sport);
>> >  +		sport->dma_is_enabled = 1;
> Ditto
>
>> >  +	}
> I see imx_disable_dma() and imx_uart_dma_exit() are called in
> imx_shutdown().  Why can not imx_uart_dma_init() and imx_enable_dma()
> be called in imx_startup()?
i intend to binding the DMA with the RTS/CTS together.

The setting of rts/cts is not in imx_startup(), but in the 
imx_set_termios().




thanks
Huang Shijie





From paul.gortmaker at windriver.com  Wed Jul  3 01:19:07 2013
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Wed, 3 Jul 2013 01:19:07 -0400
Subject: [PATCH] ARM: move body of head-common.S back to text section
In-Reply-To: <51D39004.9000907@wwwdotorg.org>
References: <1372805629-18382-1-git-send-email-swarren@wwwdotorg.org>
 <20130702232259.GH11625@codeaurora.org>
 <51D39004.9000907@wwwdotorg.org>
Message-ID: <20130703051907.GA22702@windriver.com>

[Re: [PATCH] ARM: move body of head-common.S back to text section] On 02/07/2013 (Tue 20:44) Stephen Warren wrote:

> On 07/02/2013 05:22 PM, Stephen Boyd wrote:
> > On 07/02, Stephen Warren wrote:
> >> From: Stephen Warren <swarren at nvidia.com>
> >>
> >> Commit 281ecb7 "arm: delete __cpuinit/__CPUINIT usage from all ARM

We shouldn't reference this commit since (a) the SHA is from linux-next
and hence is transient, and (b) this commit really isn't the one that
triggers the breakage.  It is the commit where we dummy out the macros
that will reveal the missing __FINIT.

So, assuming Linus takes my pull request here...

https://lkml.org/lkml/2013/7/2/405

...for phase one of the __cpuinit purge, then the SHA you want to
blame for triggering this hidden bug into life is:

22f0a2736 "init.h: remove __cpuinit sections from the kernel" at:

http://git.kernel.org/cgit/linux/kernel/git/paulg/linux.git/log/?h=cpuinit-delete

After you update the commit log (and make the change below), it probably
makes sense for this to go in via one of the ARM trees, since if I take
it, it will go in at the very end of the merge window with the phase two
commits.  If it goes in via an arm tree, the regression window within
3.10 --> 3.11-rc1 will be minimized. (That and it is a pre-existing bug).

> >> users" removed a __CPUINIT from head-common.S. However, the code
> >> immediately before the removed tag was marked __INIT, and was missing
> >> a match __FINIT. This caused code after the removed __CPUINIT to end
> >> up in the init section rather than the main text section as desired.
> >> This caused issues such as secondary CPU boot failures or crashes.
> >> Add the missing __FINIT to solve this.
> >>
> >> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> >> ---
> >>  arch/arm/kernel/head-common.S | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
> >> index 529ce99..a9dc804 100644
> >> --- a/arch/arm/kernel/head-common.S
> >> +++ b/arch/arm/kernel/head-common.S
> >> @@ -122,6 +122,8 @@ __mmap_switched_data:
> >>  	.long	init_thread_union + THREAD_START_SP @ sp
> >>  	.size	__mmap_switched_data, . - __mmap_switched_data
> >>  
> >> +	__FINIT
> >> +
> >>  /*
> >>   * This provides a C-API version of __lookup_processor_type
> >>   */
> > 
> > Shouldn't this come after lookup_processor_type()? Otherwise you
> > just removed that function from the init section?
> 
> I think this is correct. Prior to "arm: delete __cpuinit/__CPUINIT usage
> from all ARM users", lookup_processor_type() was in the cpuinit section.

No, it was __lookup_processor_type that was in the cpuinit section.
The non-underscore (C-API) version was __INIT, and if you look at the
one and only calling function in C, it too is tagged __init.  So it
appears to me that was a thought out and deliberate choice.

> After that commit, it moved to the init section and hence got dumped
> soon after boot. The change above moves lookup_processor_type() back
> into the regular text section, which I believe was the intent of the
> __cpuinit removal patch.

Given the above, actually I think StephenB is right here.  The __FINIT
can go exactly where the removed __CPUINIT was (plus or minus a blank
line...)

Thanks for testing, reporting and then tracking down where it was once
you knew what it was that you were looking for (and to Russell for the
quick and accurate diagnosis.)  You can add an Acked-by from me to the
updated patch if you want.

As an aside, I'm now thinking any __INIT that implicitly rely on EOF for
closure are nasty traps waiting to happen and it might be worthwhile to
audit and explicitly __FINIT them before someone appends to the file...

Paul.
--


From bard.shen at gmail.com  Wed Jul  3 01:22:53 2013
From: bard.shen at gmail.com (Bo Shen)
Date: Wed, 03 Jul 2013 13:22:53 +0800
Subject: [alsa-devel] [PATCH 1/2] ASoC: atmel_ssc_dai: move set dma data
 to startup callback
In-Reply-To: <51D37C59.3090306@atmel.com>
References: <1372755849-19546-1-git-send-email-voice.shen@atmel.com>
 <1372755849-19546-2-git-send-email-voice.shen@atmel.com>
 <51D2F0FA.6040409@metafoo.de> <51D37C59.3090306@atmel.com>
Message-ID: <51D3B52D.5020304@gmail.com>

Hi Lars,

On 7/3/2013 09:20, Bo Shen wrote:
> Hi Lars-Peter,
>
> On 7/2/2013 23:25, Lars-Peter Clausen wrote:
>> On 07/02/2013 11:04 AM, Bo Shen wrote:
>> [...]
>>> +    dma_params->substream = substream;
>>
>> Unrelated to this patch, but having a substream field in the
>> dma_params seems
>> to be redundant, since you need to know the substream to get the
>> dma_params in
>> the first place. Looking at the code it also seems to be unused other
>> than this
>> assignment. Maybe you can send a follow up patch to remove it.
>>
>> [...]
>>
>
> Yes, this is redundant. I will remove it in next version patches.

Sorry for mistake, this substream parameter need by the interrupt for 
PDC transfer, so, I will keep it.

Best Regards,
Bo Shen



From arnd at arndb.de  Wed Jul  3 03:31:38 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 3 Jul 2013 09:31:38 +0200
Subject: [GIT PULL 3/7] ARM SoC specific changes
In-Reply-To: <20130702231706.GF24642@n2100.arm.linux.org.uk>
References: <201307022055.50717.arnd@arndb.de>
 <201307022104.01826.arnd@arndb.de>
 <20130702231706.GF24642@n2100.arm.linux.org.uk>
Message-ID: <201307030931.39043.arnd@arndb.de>

On Wednesday 03 July 2013, Russell King - ARM Linux wrote:
> Please don't merge this yet.
> 
> Arnd has just done the worst possible thing - the arm-soc tree has taken
> bits of my tree, merged them into their own tree, had the same conflicts
> I've had, and then resolved them differently.
> 
> The result is that when these two trees now merge, they conflict on the
> conflict resolutions.  This is utter madness.

I assume you mean the confict in arch/arm/include/asm/glue-proc.h, right?

I'm sorry I did not realize that the conflict was between a commit
from your tree and from v3.10, otherwise I would have waited for your
pull request to come first.

I did the merge in my latest for-next branch, but not in the branches
that I sent off to Linus, instead I describe the conflict and Linus
picked one of the two possible resolutions. Unfortunately it was the
one I had, not yours, so he will get the conflict between the merges
again when he pulls your tree. I don't think there is any good way
to avoid that now, but since Linus now knows about the conflict it
at least won't be hard for him to figure out the solution, in this
case by using your version of the file.

	Arnd


From shawn.guo at linaro.org  Wed Jul  3 03:32:00 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 3 Jul 2013 15:32:00 +0800
Subject: [PATCH] ARM: i.MX6Q: correct emi_sel clock muxing
Message-ID: <1372836720-24660-1-git-send-email-shawn.guo@linaro.org>

From: Liu Ying <Ying.Liu at freescale.com>

The correct muxing for emi_sel clock should be
2b'00 - 396M PFD
2b'01 - PLL3
2b'10 - AXI clk root
2b'11 - 352M PFD

This patch corrects the muxing in the clock driver.

Signed-off-by: Liu Ying <Ying.Liu at freescale.com>
Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/mach-imx/clk-imx6q.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 4282e99f..86567d9 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -199,7 +199,8 @@ static const char *pcie_axi_sels[]	= { "axi", "ahb", };
 static const char *ssi_sels[]		= { "pll3_pfd2_508m", "pll3_pfd3_454m", "pll4_post_div", };
 static const char *usdhc_sels[]	= { "pll2_pfd2_396m", "pll2_pfd0_352m", };
 static const char *enfc_sels[]	= { "pll2_pfd0_352m", "pll2_bus", "pll3_usb_otg", "pll2_pfd2_396m", };
-static const char *emi_sels[]		= { "axi", "pll3_usb_otg", "pll2_pfd2_396m", "pll2_pfd0_352m", };
+static const char *emi_sels[]		= { "pll2_pfd2_396m", "pll3_usb_otg", "axi", "pll2_pfd0_352m", };
+static const char *emi_slow_sels[]      = { "axi", "pll3_usb_otg", "pll2_pfd2_396m", "pll2_pfd0_352m", };
 static const char *vdo_axi_sels[]	= { "axi", "ahb", };
 static const char *vpu_axi_sels[]	= { "axi", "pll2_pfd2_396m", "pll2_pfd0_352m", };
 static const char *cko1_sels[]	= { "pll3_usb_otg", "pll2_bus", "pll1_sys", "pll5_video_div",
@@ -392,7 +393,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[usdhc4_sel]       = imx_clk_mux("usdhc4_sel",       base + 0x1c, 19, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels));
 	clk[enfc_sel]         = imx_clk_mux("enfc_sel",         base + 0x2c, 16, 2, enfc_sels,         ARRAY_SIZE(enfc_sels));
 	clk[emi_sel]          = imx_clk_mux("emi_sel",          base + 0x1c, 27, 2, emi_sels,          ARRAY_SIZE(emi_sels));
-	clk[emi_slow_sel]     = imx_clk_mux("emi_slow_sel",     base + 0x1c, 29, 2, emi_sels,          ARRAY_SIZE(emi_sels));
+	clk[emi_slow_sel]     = imx_clk_mux("emi_slow_sel",     base + 0x1c, 29, 2, emi_slow_sels,     ARRAY_SIZE(emi_slow_sels));
 	clk[vdo_axi_sel]      = imx_clk_mux("vdo_axi_sel",      base + 0x18, 11, 1, vdo_axi_sels,      ARRAY_SIZE(vdo_axi_sels));
 	clk[vpu_axi_sel]      = imx_clk_mux("vpu_axi_sel",      base + 0x18, 14, 2, vpu_axi_sels,      ARRAY_SIZE(vpu_axi_sels));
 	clk[cko1_sel]         = imx_clk_mux("cko1_sel",         base + 0x60, 0,  4, cko1_sels,         ARRAY_SIZE(cko1_sels));
-- 
1.7.9.5




From lars at metafoo.de  Wed Jul  3 03:36:34 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Wed, 03 Jul 2013 09:36:34 +0200
Subject: [alsa-devel] [PATCH 2/2] ASoC: atmel-pcm: use generic dmaengine
 framework
In-Reply-To: <51D37F87.2010008@atmel.com>
References: <1372755849-19546-1-git-send-email-voice.shen@atmel.com>
 <1372755849-19546-3-git-send-email-voice.shen@atmel.com>
 <51D2F306.7040603@metafoo.de> <51D37F87.2010008@atmel.com>
Message-ID: <51D3D482.1050100@metafoo.de>

On 07/03/2013 03:33 AM, Bo Shen wrote:
> Hi Lars-Peter,
> 
> On 7/2/2013 23:34, Lars-Peter Clausen wrote:
>> On 07/02/2013 11:04 AM, Bo Shen wrote:
>> [...]
>>> -/*--------------------------------------------------------------------------*\
>>> - * DMAENGINE operations
>>> -\*--------------------------------------------------------------------------*/
>>> -static bool filter(struct dma_chan *chan, void *slave)
>>> -{
>>> -    struct at_dma_slave *sl = slave;
>>> -
>>> -    if (sl->dma_dev == chan->device->dev) {
>>> -        chan->private = sl;
>>> -        return true;
>>> -    } else {
>>> -        return false;
>>> -    }
>>> -}
>>
>> I'm wondering why is filtering no longer required?
> 
> Now this is handled by at_dma_filter in at_hdmac driver. More information, you
> can reference: <driver/dma/at_hdmac.c> file

Ok, so the DMA channel is now supplied via devicetree. This is really a change
that should be listed in the changelog.

> 
>> [...]
>>> +        slave_config->dst_addr = (dma_addr_t)ssc->phybase + SSC_THR;
>> [...]
>>> +        slave_config->src_addr = (dma_addr_t)ssc->phybase + SSC_RHR;
>>
>> Change the type of phybase to dma_addr_t
> 
> It should be:
> slave_config->dst_addr = (dma_addr_t)(ssc->phybase + SSC_THR);
> slave_config->src_addr = (dma_addr_t)(ssc->phybase + SSC_RHR);

The type of phybase in the ssc_device struct should be changed from
resource_size_t to dma_addr_t.


From thomas.petazzoni at free-electrons.com  Wed Jul  3 03:42:03 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 3 Jul 2013 09:42:03 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130702232311.GA3949@localhost>
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net>
 <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
 <20130702232311.GA3949@localhost>
Message-ID: <20130703094203.37562f9c@skate>

Hello,

On Tue, 2 Jul 2013 20:23:12 -0300, Ezequiel Garcia wrote:

> I wish I could say I'm going to work on this soon but, as Thomas said,
> we have no idea when/if NAND will be prioritized.
> 
> On the other side if you look at the driver Willy just posted, merging
> the juicy stuff into pxa3xx-nand driver is not for the faint of heart.
> 
> Without the spec, is only tougher.
> 
> Just a quick hint. As far as I can recall, one of the first items in a
> TODO list should be:
> 
>  * adding bigger page support to pxa3xx (4 KiB, 8 KiB).
>    Willy's posted driver might be helpful to accomplish this;
>    provided your eyes don't melt when you look at it :-)
> 
>  * once the above is done, bad block management can/should be added.
> 
> With these two we're almost there for R/W support.

Wasn't also part of the TODO-list to make pxa3xx_nand divorce from the
PXA-specific DMA API, and use instead the PXA dmaengine driver, through
the DMA engine API? As far as I remember, this was one of the
prerequisite to be able to re-use the driver in a non-PXA context.
There is a patch that was floating around doing this conversion (I
could dig the relevant link if needed), but of course it needs to be
tested, and we don't have PXA3xx hardware, so making changes to this
driver without breaking it is quite tedious.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From horms+renesas at verge.net.au  Wed Jul  3 03:57:31 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed,  3 Jul 2013 16:57:31 +0900
Subject: [PATCH v3] ARM: shmobile: lager: Add DT reference
Message-ID: <1372838251-6314-1-git-send-email-horms+renesas@verge.net.au>

This is sufficient to allow boot of the Lager board with
a console without boards-lager.c compiled into the kernel.
This is an example of a minimal but still useful initialisation
of the board using DT as much as possible.

As such it is the same as the boot of Lager that can be achieved
without a board file. The intention of adding this file
is to facilitate further work to allow board specific devices to be
initialised via DT.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

v3
* Supply temporary machine_init call-back in lager-reference.c to
  initialise clocks and bring up SCIF and CMT in C. Magnus
  advised me that this is not desired in the SoC code.
* Add lager-reference to Makefile.boot

v2
* Use recently added r8a7790_init_delay()
---
 arch/arm/boot/dts/Makefile                     |  1 +
 arch/arm/boot/dts/r8a7790-lager-reference.dts  | 31 +++++++++++++++++
 arch/arm/mach-shmobile/Kconfig                 | 11 ++++++
 arch/arm/mach-shmobile/Makefile                |  1 +
 arch/arm/mach-shmobile/Makefile.boot           |  1 +
 arch/arm/mach-shmobile/board-lager-reference.c | 46 ++++++++++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/r8a7790.h  |  1 +
 arch/arm/mach-shmobile/setup-r8a7790.c         |  9 +++--
 8 files changed, 99 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/boot/dts/r8a7790-lager-reference.dts
 create mode 100644 arch/arm/mach-shmobile/board-lager-reference.c

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cb31259..f2dc697 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -165,6 +165,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
 	r8a7740-armadillo800eva-reference.dtb \
 	r8a7779-marzen-reference.dtb \
 	r8a7790-lager.dtb \
+	r8a7790-lager-reference.dtb \
 	sh73a0-kzm9g.dtb \
 	sh73a0-kzm9g-reference.dtb \
 	r8a73a4-ape6evm.dtb \
diff --git a/arch/arm/boot/dts/r8a7790-lager-reference.dts b/arch/arm/boot/dts/r8a7790-lager-reference.dts
new file mode 100644
index 0000000..fa5b81b
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7790-lager-reference.dts
@@ -0,0 +1,31 @@
+/*
+ * Device Tree Source for the Lager board
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "r8a7790.dtsi"
+
+/ {
+	model = "Lager";
+	compatible = "renesas,lager-reference", "renesas,r8a7790";
+
+	chosen {
+		bootargs = "console=ttySC6,115200 ignore_loglevel";
+	};
+
+	memory at 40000000 {
+		device_type = "memory";
+		reg = <0 0x40000000 0 0x80000000>;
+	};
+
+	lbsc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+	};
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 64dc24d..30c571b 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -150,6 +150,17 @@ config MACH_LAGER
 	depends on ARCH_R8A7790
 	select USE_OF
 
+config MACH_LAGER_REFERENCE
+	bool "Lager board - Reference Device Tree Implementation"
+	depends on ARCH_R8A7790
+	select USE_OF
+	---help---
+	   Use reference implementation of Lager board support
+	   which makes use of device tree at the expense
+	   of not supporting a number of devices.
+
+	   This is intended to aid developers
+
 config MACH_KZM9D
 	bool "KZM9D board"
 	depends on ARCH_EMEV2
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 6165a51..d813133 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_MACH_BOCKW)	+= board-bockw.o
 obj-$(CONFIG_MACH_MARZEN)	+= board-marzen.o
 obj-$(CONFIG_MACH_MARZEN_REFERENCE)	+= board-marzen-reference.o
 obj-$(CONFIG_MACH_LAGER)	+= board-lager.o
+obj-$(CONFIG_MACH_LAGER_REFERENCE)	+= board-lager-reference.o
 obj-$(CONFIG_MACH_ARMADILLO800EVA)	+= board-armadillo800eva.o
 obj-$(CONFIG_MACH_ARMADILLO800EVA_REFERENCE)	+= board-armadillo800eva-reference.o
 obj-$(CONFIG_MACH_KZM9D)	+= board-kzm9d.o
diff --git a/arch/arm/mach-shmobile/Makefile.boot b/arch/arm/mach-shmobile/Makefile.boot
index 84c6868..16834d8 100644
--- a/arch/arm/mach-shmobile/Makefile.boot
+++ b/arch/arm/mach-shmobile/Makefile.boot
@@ -10,6 +10,7 @@ loadaddr-$(CONFIG_MACH_KZM9D) += 0x40008000
 loadaddr-$(CONFIG_MACH_KZM9G) += 0x41008000
 loadaddr-$(CONFIG_MACH_KZM9G_REFERENCE) += 0x41008000
 loadaddr-$(CONFIG_MACH_LAGER) += 0x40008000
+loadaddr-$(CONFIG_MACH_LAGER_REFERENCE) += 0x40008000
 loadaddr-$(CONFIG_MACH_MACKEREL) += 0x40008000
 loadaddr-$(CONFIG_MACH_MARZEN) += 0x60008000
 loadaddr-$(CONFIG_MACH_MARZEN_REFERENCE) += 0x60008000
diff --git a/arch/arm/mach-shmobile/board-lager-reference.c b/arch/arm/mach-shmobile/board-lager-reference.c
new file mode 100644
index 0000000..eb6c55e
--- /dev/null
+++ b/arch/arm/mach-shmobile/board-lager-reference.c
@@ -0,0 +1,46 @@
+/*
+ * Lager board support - Reference DT implementation
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Simon Horman
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <linux/init.h>
+#include <linux/irqchip.h>
+#include <linux/of_platform.h>
+#include <mach/r8a7790.h>
+#include <asm/mach/arch.h>
+
+void __init lager_add_standard_devices(void)
+{
+	/* clocks are setup late during boot in the case of DT */
+	r8a7790_clock_init();
+
+	r8a7790_add_dt_devices();
+        of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char *lager_boards_compat_dt[] __initdata = {
+	"renesas,lager-reference",
+	NULL,
+};
+
+DT_MACHINE_START(LAGER_DT, "lager")
+	.init_early	= r8a7790_init_delay,
+	.init_machine	= lager_add_standard_devices,
+	.init_time	= r8a7790_timer_init,
+	.dt_compat	= lager_boards_compat_dt,
+MACHINE_END
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h b/arch/arm/mach-shmobile/include/mach/r8a7790.h
index 7851cc1..421d842 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7790.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7790.h
@@ -2,6 +2,7 @@
 #define __ASM_R8A7790_H__
 
 void r8a7790_add_standard_devices(void);
+void r8a7790_add_dt_devices(void);
 void r8a7790_clock_init(void);
 void r8a7790_pinmux_init(void);
 void r8a7790_init_delay(void);
diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index f01542e..7f01178 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -179,7 +179,7 @@ static struct resource cmt00_resources[] = {
 					  &cmt##idx##_platform_data,	\
 					  sizeof(struct sh_timer_config))
 
-void __init r8a7790_add_standard_devices(void)
+void __init r8a7790_add_dt_devices(void)
 {
 	r8a7790_register_scif(SCIFA0);
 	r8a7790_register_scif(SCIFA1);
@@ -191,9 +191,14 @@ void __init r8a7790_add_standard_devices(void)
 	r8a7790_register_scif(SCIF1);
 	r8a7790_register_scif(HSCIF0);
 	r8a7790_register_scif(HSCIF1);
+	r8a7790_register_cmt(00);
+}
+
+void __init r8a7790_add_standard_devices(void)
+{
+	r8a7790_add_dt_devices();
 	r8a7790_register_irqc(0);
 	r8a7790_register_thermal();
-	r8a7790_register_cmt(00);
 }
 
 void __init r8a7790_timer_init(void)
-- 
1.8.2.1



From voice.shen at atmel.com  Wed Jul  3 03:57:29 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Wed, 3 Jul 2013 15:57:29 +0800
Subject: [alsa-devel] [PATCH 2/2] ASoC: atmel-pcm: use generic dmaengine
 framework
In-Reply-To: <51D3D482.1050100@metafoo.de>
References: <1372755849-19546-1-git-send-email-voice.shen@atmel.com>
 <1372755849-19546-3-git-send-email-voice.shen@atmel.com>
 <51D2F306.7040603@metafoo.de> <51D37F87.2010008@atmel.com>
 <51D3D482.1050100@metafoo.de>
Message-ID: <51D3D969.1060308@atmel.com>

Hi Lars,

On 7/3/2013 15:36, Lars-Peter Clausen wrote:
>>>> +        slave_config->dst_addr = (dma_addr_t)ssc->phybase + SSC_THR;
>>> >>[...]
>>>> >>>+        slave_config->src_addr = (dma_addr_t)ssc->phybase + SSC_RHR;
>>> >>
>>> >>Change the type of phybase to dma_addr_t
>> >
>> >It should be:
>> >slave_config->dst_addr = (dma_addr_t)(ssc->phybase + SSC_THR);
>> >slave_config->src_addr = (dma_addr_t)(ssc->phybase + SSC_RHR);
> The type of phybase in the ssc_device struct should be changed from
> resource_size_t to dma_addr_t.

Actually, the phybase in ssc_device structure is resource_size_t which 
used to access the ssc device register.
Here, we use ssc register as dma source address or destination address, 
so we convert it to dma_addr_t type. So, not need to change, am I right?

Best Regards,
Bo Shen


From lars at metafoo.de  Wed Jul  3 04:08:08 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Wed, 03 Jul 2013 10:08:08 +0200
Subject: [alsa-devel] [PATCH 2/2] ASoC: atmel-pcm: use generic dmaengine
 framework
In-Reply-To: <51D3D969.1060308@atmel.com>
References: <1372755849-19546-1-git-send-email-voice.shen@atmel.com>
 <1372755849-19546-3-git-send-email-voice.shen@atmel.com>
 <51D2F306.7040603@metafoo.de> <51D37F87.2010008@atmel.com>
 <51D3D482.1050100@metafoo.de> <51D3D969.1060308@atmel.com>
Message-ID: <51D3DBE8.4090407@metafoo.de>

On 07/03/2013 09:57 AM, Bo Shen wrote:
> Hi Lars,
> 
> On 7/3/2013 15:36, Lars-Peter Clausen wrote:
>>>>> +        slave_config->dst_addr = (dma_addr_t)ssc->phybase + SSC_THR;
>>>> >>[...]
>>>>> >>>+        slave_config->src_addr = (dma_addr_t)ssc->phybase + SSC_RHR;
>>>> >>
>>>> >>Change the type of phybase to dma_addr_t
>>> >
>>> >It should be:
>>> >slave_config->dst_addr = (dma_addr_t)(ssc->phybase + SSC_THR);
>>> >slave_config->src_addr = (dma_addr_t)(ssc->phybase + SSC_RHR);
>> The type of phybase in the ssc_device struct should be changed from
>> resource_size_t to dma_addr_t.
> 
> Actually, the phybase in ssc_device structure is resource_size_t which used to
> access the ssc device register.
> Here, we use ssc register as dma source address or destination address, so we
> convert it to dma_addr_t type. So, not need to change, am I right?

Isn't 'regs' used to access the registers? As far as I can see phybase is only
used in the audio DMA driver.

- Lars


From nsekhar at ti.com  Wed Jul  3 04:12:07 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 3 Jul 2013 13:42:07 +0530
Subject: [PATCH 4/4] ARM: dts: AM33XX: update rtc node compatibility
In-Reply-To: <51D26F61.7080308@ti.com>
References: <1372412109-986-1-git-send-email-gururaja.hebbar@ti.com>
 <1372412109-986-5-git-send-email-gururaja.hebbar@ti.com>
 <51D26F61.7080308@ti.com>
Message-ID: <51D3DCD7.2010209@ti.com>

Gururaja,

On 7/2/2013 11:42 AM, Sekhar Nori wrote:
> Changing to Benoit's gmail id since he apparently wont access TI mail
> anymore.
> 
> On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
>> Since AM33xx  RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
>>
>> Update the rtc compatible property to "ti,am3352-rtc" to enable handling
>> of this feature inside rtc-omap driver.
>>
>> Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
>> Cc: Tony Lindgren <tony at atomide.com>
>> Cc: Sekhar Nori <nsekhar at ti.com>
>> Cc: Kevin Hilman <khilman at linaro.org>
>> Cc: b-cousson at ti.com
>> ---
>> :100644 100644 77aa1b0... dde180a... M	arch/arm/boot/dts/am33xx.dtsi
>>  arch/arm/boot/dts/am33xx.dtsi |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>> index 77aa1b0..dde180a 100644
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> @@ -297,7 +297,7 @@
>>  		};
>>  
>>  		rtc at 44e3e000 {
>> -			compatible = "ti,da830-rtc";
>> +			compatible = "ti,am3352-rtc";
> 
> compatible is a list so you can instead do:
> 	
> 	compatible = "ti,am3352-rtc", "ti,da830-rtc";
> 
> That way the dts works irrespective of driver updates. When driver
> supports enhanced features of hardware, they are available to the user
> else the basic functionality still works.

On doing some experiments myself, the of_device_id which gets selected
during probe depends on the order in which its entry appears in the
match table inside the driver rather than how the compatible string is
written. I think this puts undue dependency on how the driver is
written, so I am okay with providing a single compatible value like the
way you have done ATM.

I do think the string appearing first in the compatible list is what
should be selected if a match is available but I am not sure if there
are other considerations due to which of_match_device() is written the
way it is written.

Thanks,
Sekhar


From vincent.stehle at freescale.com  Wed Jul  3 04:12:59 2013
From: vincent.stehle at freescale.com (=?UTF-8?q?Vincent=20Stehl=C3=A9?=)
Date: Wed, 3 Jul 2013 10:12:59 +0200
Subject: [PATCH linux-next 2/2] arm: multi_v7_defconfig: add support for NFS
 root
In-Reply-To: <1372839179-14542-1-git-send-email-vincent.stehle@freescale.com>
References: <1372839179-14542-1-git-send-email-vincent.stehle@freescale.com>
Message-ID: <1372839179-14542-3-git-send-email-vincent.stehle@freescale.com>

Add the necessary config options, to allow booting with NFS root on an i.MX6
sabre sd.

Signed-off-by: Vincent Stehl? <vincent.stehle at freescale.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Olof Johansson <olof at lixom.net>
---
 arch/arm/configs/multi_v7_defconfig |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index cc8723a..81eac83 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -47,6 +47,8 @@ CONFIG_ARM_APPENDED_DTB=y
 CONFIG_NET=y
 CONFIG_UNIX=y
 CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_BLK_DEV_SD=y
@@ -149,6 +151,10 @@ CONFIG_PWM=y
 CONFIG_PWM_VT8500=y
 CONFIG_EXT4_FS=y
 CONFIG_TMPFS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_ROOT_NFS=y
 CONFIG_PRINTK_TIME=y
 CONFIG_DEBUG_FS=y
 CONFIG_DEBUG_KERNEL=y
-- 
1.7.10.4





From voice.shen at atmel.com  Wed Jul  3 04:13:28 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Wed, 3 Jul 2013 16:13:28 +0800
Subject: [alsa-devel] [PATCH 2/2] ASoC: atmel-pcm: use generic dmaengine
 framework
In-Reply-To: <51D3DBE8.4090407@metafoo.de>
References: <1372755849-19546-1-git-send-email-voice.shen@atmel.com>
 <1372755849-19546-3-git-send-email-voice.shen@atmel.com>
 <51D2F306.7040603@metafoo.de> <51D37F87.2010008@atmel.com>
 <51D3D482.1050100@metafoo.de> <51D3D969.1060308@atmel.com>
 <51D3DBE8.4090407@metafoo.de>
Message-ID: <51D3DD28.8050900@atmel.com>

Hi Lars,

On 7/3/2013 16:08, Lars-Peter Clausen wrote:
> On 07/03/2013 09:57 AM, Bo Shen wrote:
>> Hi Lars,
>>
>> On 7/3/2013 15:36, Lars-Peter Clausen wrote:
>>>>>> +        slave_config->dst_addr = (dma_addr_t)ssc->phybase + SSC_THR;
>>>>>>> [...]
>>>>>>>>> +        slave_config->src_addr = (dma_addr_t)ssc->phybase + SSC_RHR;
>>>>>>>
>>>>>>> Change the type of phybase to dma_addr_t
>>>>>
>>>>> It should be:
>>>>> slave_config->dst_addr = (dma_addr_t)(ssc->phybase + SSC_THR);
>>>>> slave_config->src_addr = (dma_addr_t)(ssc->phybase + SSC_RHR);
>>> The type of phybase in the ssc_device struct should be changed from
>>> resource_size_t to dma_addr_t.
>>
>> Actually, the phybase in ssc_device structure is resource_size_t which used to
>> access the ssc device register.
>> Here, we use ssc register as dma source address or destination address, so we
>> convert it to dma_addr_t type. So, not need to change, am I right?
>
> Isn't 'regs' used to access the registers? As far as I can see phybase is only
> used in the audio DMA driver.

Thanks for point out this. I will change the phybase type from 
resource_size_t to dma_addr_t.

> - Lars
>

Best Regards,
Bo Shen


From vincent.stehle at freescale.com  Wed Jul  3 04:12:57 2013
From: vincent.stehle at freescale.com (=?UTF-8?q?Vincent=20Stehl=C3=A9?=)
Date: Wed, 3 Jul 2013 10:12:57 +0200
Subject: linux-next arm multi_v7_defconfig: add support for i.MX6 on NFS root
Message-ID: <1372839179-14542-1-git-send-email-vincent.stehle@freescale.com>

Hi,

I would like to propose the following two patches, which allow me to boot
next-20130702 with NFS root on an i.MX6 sabre sd:

  [PATCH linux-next 1/2] arm: multi_v7_defconfig: add i.MX serial
  [PATCH linux-next 2/2] arm: multi_v7_defconfig: add support for NFS

Note that at the time of writing, a few other patches are necessary for me as
well:

- i2c-designware: use div_u64 to fix link
  https://lkml.org/lkml/2013/7/2/145

- tick: Prevent uncontrolled switch to oneshot mode
  https://lkml.org/lkml/2013/7/2/270

- tick: Sanitize broadcast control logic
  https://lkml.org/lkml/2013/7/2/272

Best regards,

V.




From vincent.stehle at freescale.com  Wed Jul  3 04:12:58 2013
From: vincent.stehle at freescale.com (=?UTF-8?q?Vincent=20Stehl=C3=A9?=)
Date: Wed, 3 Jul 2013 10:12:58 +0200
Subject: [PATCH linux-next 1/2] arm: multi_v7_defconfig: add i.MX serial
 console
In-Reply-To: <1372839179-14542-1-git-send-email-vincent.stehle@freescale.com>
References: <1372839179-14542-1-git-send-email-vincent.stehle@freescale.com>
Message-ID: <1372839179-14542-2-git-send-email-vincent.stehle@freescale.com>

Add i.MX serial console support. This gives us the boot messages on UART on
e.g. the i.MX6Q sabre sd platform.

Signed-off-by: Vincent Stehl? <vincent.stehle at freescale.com>
Cc: Olof Johansson <olof at lixom.net>
Cc: Russell King <linux at arm.linux.org.uk>
---
 arch/arm/configs/multi_v7_defconfig |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 6d8d3c4..cc8723a 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -75,6 +75,8 @@ CONFIG_SERIAL_OMAP=y
 CONFIG_SERIAL_OMAP_CONSOLE=y
 CONFIG_SERIAL_XILINX_PS_UART=y
 CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
+CONFIG_SERIAL_IMX=y
+CONFIG_SERIAL_IMX_CONSOLE=y
 CONFIG_I2C_DESIGNWARE_PLATFORM=y
 CONFIG_I2C_SIRF=y
 CONFIG_I2C_TEGRA=y
-- 
1.7.10.4





From shc_work at mail.ru  Wed Jul  3 04:18:06 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Wed, 03 Jul 2013 12:18:06 +0400
Subject: =?UTF-8?B?UHJvcG9zYWw6IG1hY2gtZHQ=?=
Message-ID: <1372839486.487159774@f54.mail.ru>

Hello.

More and more platforms are now using devicetree.
Ideally the platform code contains only one function "of_platform_populate".
My idea is to make a generic architecture (mach-dt) with the call then add support
for compatible subarchitectures as they become available in "compatible"-property.
Your opinion?
Thanks.

---

From magnus.damm at gmail.com  Wed Jul  3 04:21:10 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 3 Jul 2013 17:21:10 +0900
Subject: [PATCH v3] ARM: shmobile: lager: Add DT reference
In-Reply-To: <1372838251-6314-1-git-send-email-horms+renesas@verge.net.au>
References: <1372838251-6314-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <CANqRtoTD3Bgm775DhFhs2kn1+sSLb-pX89mFRoHrc2x4sRT_RQ@mail.gmail.com>

Hi Simon,

On Wed, Jul 3, 2013 at 4:57 PM, Simon Horman <horms+renesas at verge.net.au> wrote:
> This is sufficient to allow boot of the Lager board with
> a console without boards-lager.c compiled into the kernel.
> This is an example of a minimal but still useful initialisation
> of the board using DT as much as possible.
>
> As such it is the same as the boot of Lager that can be achieved
> without a board file. The intention of adding this file
> is to facilitate further work to allow board specific devices to be
> initialised via DT.
>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
>
> ---
>
> v3
> * Supply temporary machine_init call-back in lager-reference.c to
>   initialise clocks and bring up SCIF and CMT in C. Magnus
>   advised me that this is not desired in the SoC code.
> * Add lager-reference to Makefile.boot
>
> v2
> * Use recently added r8a7790_init_delay()

This looks good to me, thanks!

Acked-by: Magnus Damm <damm at opensource.se>


From voice.shen at atmel.com  Wed Jul  3 04:37:55 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Wed,  3 Jul 2013 16:37:55 +0800
Subject: [v2 0/5] ASoC: atmel-pcm: align with generic dmaengine framwork
Message-ID: <1372840680-2253-1-git-send-email-voice.shen@atmel.com>

This patch set is based on linux next-20130701

mainly implement
  - move set dma data from hw_params to startup callback to avoid memory leak
  - align atmel pcm with generic dmaenigne framwork

Bo Shen (5):
  ASoC: atmel_ssc_dai: move set dma data to startup callback
  ASoC: atmel_ssc_dai: add error mask define
  ASoC: atmel-pcm-dma: move prepare for dma to dai prepare
  ARM: atmel-ssc: change phybase type to dma_addr_t
  ASoC: atmel-pcm: use generic dmaengine framework

 include/linux/atmel-ssc.h       |    2 +-
 sound/soc/atmel/Kconfig         |    1 +
 sound/soc/atmel/atmel-pcm-dma.c |  118 ++++++---------------------------------
 sound/soc/atmel/atmel_ssc_dai.c |   36 ++++++------
 4 files changed, 37 insertions(+), 120 deletions(-)

-- 
1.7.9.5



From anup.patel at linaro.org  Wed Jul  3 04:42:03 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Wed,  3 Jul 2013 14:12:03 +0530
Subject: [PATCH] arm64: KVM: Support Cortex-A57 guest CPU on APM X-Gene host
Message-ID: <1372840923-12808-1-git-send-email-anup.patel@linaro.org>

Update kvm_target_cpu() to allow Cortex-A57 guest CPU on APM X-Gene.

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm64/kvm/guest.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 2c3ff67..765f56f 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -207,8 +207,13 @@ int __attribute_const__ kvm_target_cpu(void)
 	unsigned long implementor = read_cpuid_implementor();
 	unsigned long part_number = read_cpuid_part_number();
 
-	if (implementor != ARM_CPU_IMP_ARM)
-		return -EINVAL;
+	switch (implementor) {
+	case ARM_CPU_IMP_ARM:
+	case ARM_CPU_IMP_APM:
+		break;
+	default:
+ 		return -EINVAL;
+	}
 
 	switch (part_number) {
 	case ARM_CPU_PART_AEM_V8:
@@ -216,6 +221,7 @@ int __attribute_const__ kvm_target_cpu(void)
 	case ARM_CPU_PART_FOUNDATION:
 		return KVM_ARM_TARGET_FOUNDATION_V8;
 	case ARM_CPU_PART_CORTEX_A57:
+	case APM_CPU_PART_POTENZA:
 		/* Currently handled by the generic backend */
 		return KVM_ARM_TARGET_CORTEX_A57;
 	default:
-- 
1.7.9.5



From gururaja.hebbar at ti.com  Wed Jul  3 04:47:02 2013
From: gururaja.hebbar at ti.com (Hebbar Gururaja)
Date: Wed, 3 Jul 2013 14:17:02 +0530
Subject: [Patch V2 1/4] rtc: omap: restore back (hard-code) wakeup support
In-Reply-To: <1372841225-18813-1-git-send-email-gururaja.hebbar@ti.com>
References: <1372841225-18813-1-git-send-email-gururaja.hebbar@ti.com>
Message-ID: <1372841225-18813-2-git-send-email-gururaja.hebbar@ti.com>

rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms.

However, rtc wake support on OMAP1 is broken. Hence the
device_init_wakeup() was removed from rtc-omap driver and moved to
platform board files that supported it (DA850/OMAP-L138). [1]

However, recently [2] it was suggested that driver should always do a
device_init_wakeup(dev, true). Platforms that don't want/need
wakeup support can disable it from userspace via:

    echo disabled > /sys/devices/.../power/wakeup

Also, with the new DT boot-up, board file doesn't exist and hence there
is no way to have device wakeup support rtc.

The fix for above issues, is to hard code device_init_wakeup() inside
driver and let platforms that don't need this, handle it through the
sysfs power entry.

[1]
https://patchwork.kernel.org/patch/136731/

[2]
http://www.mail-archive.com/davinci-linux-open-source at linux.
davincidsp.com/msg26077.html

Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
Acked-by: Kevin Hilman <khilman at linaro.org>
Cc: Alessandro Zummo <a.zummo at towertech.it>
Cc: rtc-linux at googlegroups.com
---
:100644 100644 b0ba3fc... 761919d... M	drivers/rtc/rtc-omap.c
 drivers/rtc/rtc-omap.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index b0ba3fc..761919d 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -423,6 +423,8 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	 *    is write-only, and always reads as zero...)
 	 */
 
+	device_init_wakeup(&pdev->dev, true);
+
 	if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
 		pr_info("%s: split power mode\n", pdev->name);
 
-- 
1.7.9.5



From gururaja.hebbar at ti.com  Wed Jul  3 04:47:01 2013
From: gururaja.hebbar at ti.com (Hebbar Gururaja)
Date: Wed, 3 Jul 2013 14:17:01 +0530
Subject: [Patch V2 0/4] rtc: omap: handle rtc wakeup support in driver
Message-ID: <1372841225-18813-1-git-send-email-gururaja.hebbar@ti.com>

rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms.

However, rtc wake support on OMAP1 is broken. Hence the
device_init_wakeup() was removed from rtc-omap driver and moved to
platform board files that supported it (DA850/OMAP-L138). [1]

However, recently [2] it was suggested that driver should always do a
device_init_wakeup(dev, true). Platforms that don't want/need
wakeup support can disable it from userspace via:

    echo disabled > /sys/devices/.../power/wakeup

Also, with the new DT boot-up, board file doesn't exist and hence there
is no way to have device wakeup support rtc.

The fix for above issues, is to hard code device_init_wakeup() inside
driver and let platforms that don't need this, handle it through the
sysfs power entry.


Also, update Davinci & AM335x files to above changes.

[1]
https://patchwork.kernel.org/patch/136731/

[2]
http://www.mail-archive.com/davinci-linux-open-source at linux.
davincidsp.com/msg26077.html

Changes in V2:
	- Coding style corrections (remove extra space, use lower case
	  for hex numbers
	- use prefix ARM: for commit subject keeping with arch/arm
	  convention)
	- use "[AM/am]3352" instead of "[AM/am]335x" to keep the all
	  usages in sync.
	- Use index defined for struct members so they remain in sync
	- Add new compatible to existing one so that when driver
	  supports enhanced features of hardware, they are available
	  to the user else the basic functionality still works

Hebbar Gururaja (4):
  rtc: omap: restore back (hard-code) wakeup support
  ARM: Davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
  rtc: omap: add rtc wakeup support to alarm events
  ARM: dts: AM33XX: update rtc node compatibility

 Documentation/devicetree/bindings/rtc/rtc-omap.txt |    6 +-
 arch/arm/boot/dts/am33xx.dtsi                      |    2 +-
 arch/arm/mach-davinci/devices-da8xx.c              |    9 +--
 drivers/rtc/rtc-omap.c                             |   62 +++++++++++++++++---
 4 files changed, 61 insertions(+), 18 deletions(-)

-- 
1.7.9.5



From gururaja.hebbar at ti.com  Wed Jul  3 04:47:05 2013
From: gururaja.hebbar at ti.com (Hebbar Gururaja)
Date: Wed, 3 Jul 2013 14:17:05 +0530
Subject: [Patch V2 4/4] ARM: dts: AM33XX: update rtc node compatibility
In-Reply-To: <1372841225-18813-1-git-send-email-gururaja.hebbar@ti.com>
References: <1372841225-18813-1-git-send-email-gururaja.hebbar@ti.com>
Message-ID: <1372841225-18813-5-git-send-email-gururaja.hebbar@ti.com>

Since AM33xx  RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.

Update the rtc compatible property to "ti,am3352-rtc" to enable handling
of this feature inside rtc-omap driver.

Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
---
:100644 100644 77aa1b0... dde180a... M	arch/arm/boot/dts/am33xx.dtsi
 arch/arm/boot/dts/am33xx.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 77aa1b0..dde180a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -297,7 +297,7 @@
 		};
 
 		rtc at 44e3e000 {
-			compatible = "ti,da830-rtc";
+			compatible = "ti,am3352-rtc";
 			reg = <0x44e3e000 0x1000>;
 			interrupts = <75
 				      76>;
-- 
1.7.9.5



From gururaja.hebbar at ti.com  Wed Jul  3 04:47:04 2013
From: gururaja.hebbar at ti.com (Hebbar Gururaja)
Date: Wed, 3 Jul 2013 14:17:04 +0530
Subject: [Patch V2 3/4] rtc: omap: add rtc wakeup support to alarm events
In-Reply-To: <1372841225-18813-1-git-send-email-gururaja.hebbar@ti.com>
References: <1372841225-18813-1-git-send-email-gururaja.hebbar@ti.com>
Message-ID: <1372841225-18813-4-git-send-email-gururaja.hebbar@ti.com>

On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
is available to enable Alarm Wakeup feature. This register needs to be
properly handled for the rtcwake to work properly.

Platforms using such IP should set "ti,am3352-rtc" in rtc device dt
compatibility node.

Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
Acked-by: Kevin Hilman <khilman at linaro.org>
Acked-by: Sekhar Nori <nsekhar at ti.com>
Cc: Grant Likely <grant.likely at linaro.org>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Rob Landley <rob at landley.net>
Cc: Alessandro Zummo <a.zummo at towertech.it>
Cc: rtc-linux at googlegroups.com
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-doc at vger.kernel.org
---
Changes in V2:
	- Coding style corrections (use lower case for hex numbers)
	- use "[AM/am]3352" instead of "[AM/am]335x" to keep the all
	  usages in sync.
	- Use index defined for struct members so they remain in sync

:100644 100644 b47aa41... 5a0f02d... M	Documentation/devicetree/bindings/rtc/rtc-omap.txt
:100644 100644 761919d... c2e18fe... M	drivers/rtc/rtc-omap.c
 Documentation/devicetree/bindings/rtc/rtc-omap.txt |    6 +-
 drivers/rtc/rtc-omap.c                             |   60 +++++++++++++++++---
 2 files changed, 57 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..5a0f02d 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -1,7 +1,11 @@
 TI Real Time Clock
 
 Required properties:
-- compatible: "ti,da830-rtc"
+- compatible:
+	- "ti,da830-rtc"  - for RTC IP used similar to that on DA8xx SoC family.
+	- "ti,am3352-rtc" - for RTC IP used similar to that on AM335x SoC family.
+			    This RTC IP has special WAKE-EN Register to enable
+			    Wakeup generation for event Alarm.
 - reg: Address range of rtc register set
 - interrupts: rtc timer, alarm interrupts in order
 - interrupt-parent: phandle for the interrupt controller
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 761919d..c2e18fe 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,8 @@
 #define OMAP_RTC_KICK0_REG		0x6c
 #define OMAP_RTC_KICK1_REG		0x70
 
+#define OMAP_RTC_IRQWAKEEN		0x7c
+
 /* OMAP_RTC_CTRL_REG bit fields: */
 #define OMAP_RTC_CTRL_SPLIT		(1<<7)
 #define OMAP_RTC_CTRL_DISABLE		(1<<6)
@@ -96,12 +98,21 @@
 #define OMAP_RTC_INTERRUPTS_IT_ALARM    (1<<3)
 #define OMAP_RTC_INTERRUPTS_IT_TIMER    (1<<2)
 
+/* OMAP_RTC_IRQWAKEEN bit fields: */
+#define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN    (1<<1)
+
 /* OMAP_RTC_KICKER values */
 #define	KICK0_VALUE			0x83e70b13
 #define	KICK1_VALUE			0x95a4f1e0
 
 #define	OMAP_RTC_HAS_KICKER		0x1
 
+/*
+ * Few RTC IP revisions has special WAKE-EN Register to enable Wakeup
+ * generation for event Alarm.
+ */
+#define	OMAP_RTC_HAS_IRQWAKEEN		0x2
+
 static void __iomem	*rtc_base;
 
 #define rtc_read(addr)		readb(rtc_base + (addr))
@@ -301,12 +312,18 @@ static struct rtc_class_ops omap_rtc_ops = {
 static int omap_rtc_alarm;
 static int omap_rtc_timer;
 
-#define	OMAP_RTC_DATA_DA830_IDX	1
+#define	OMAP_RTC_DATA_AM3352_IDX	1
+#define	OMAP_RTC_DATA_DA830_IDX		2
 
 static struct platform_device_id omap_rtc_devtype[] = {
 	{
 		.name	= DRIVER_NAME,
-	}, {
+	},
+	[OMAP_RTC_DATA_AM3352_IDX] = {
+		.name	= "am3352-rtc",
+		.driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
+	},
+	[OMAP_RTC_DATA_DA830_IDX] = {
 		.name	= "da830-rtc",
 		.driver_data = OMAP_RTC_HAS_KICKER,
 	},
@@ -318,6 +335,9 @@ static const struct of_device_id omap_rtc_of_match[] = {
 	{	.compatible	= "ti,da830-rtc",
 		.data		= &omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
 	},
+	{	.compatible	= "ti,am3352-rtc",
+		.data		= &omap_rtc_devtype[OMAP_RTC_DATA_AM3352_IDX],
+	},
 	{},
 };
 MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
@@ -466,16 +486,28 @@ static u8 irqstat;
 
 static int omap_rtc_suspend(struct device *dev)
 {
+	u8 irqwake_stat;
+	struct platform_device *pdev = to_platform_device(dev);
+	const struct platform_device_id *id_entry =
+					platform_get_device_id(pdev);
+
 	irqstat = rtc_read(OMAP_RTC_INTERRUPTS_REG);
 
 	/* FIXME the RTC alarm is not currently acting as a wakeup event
-	 * source, and in fact this enable() call is just saving a flag
-	 * that's never used...
+	 * source on some platforms, and in fact this enable() call is just
+	 * saving a flag that's never used...
 	 */
-	if (device_may_wakeup(dev))
+	if (device_may_wakeup(dev)) {
 		enable_irq_wake(omap_rtc_alarm);
-	else
+
+		if (id_entry->driver_data & OMAP_RTC_HAS_IRQWAKEEN) {
+			irqwake_stat = rtc_read(OMAP_RTC_IRQWAKEEN);
+			irqwake_stat |= OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN;
+			rtc_write(irqwake_stat, OMAP_RTC_IRQWAKEEN);
+		}
+	} else {
 		rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
+	}
 
 	/* Disable the clock/module */
 	pm_runtime_put_sync(dev);
@@ -485,13 +517,25 @@ static int omap_rtc_suspend(struct device *dev)
 
 static int omap_rtc_resume(struct device *dev)
 {
+	u8 irqwake_stat;
+	struct platform_device *pdev = to_platform_device(dev);
+	const struct platform_device_id *id_entry =
+				platform_get_device_id(pdev);
+
 	/* Enable the clock/module so that we can access the registers */
 	pm_runtime_get_sync(dev);
 
-	if (device_may_wakeup(dev))
+	if (device_may_wakeup(dev)) {
 		disable_irq_wake(omap_rtc_alarm);
-	else
+
+		if (id_entry->driver_data & OMAP_RTC_HAS_IRQWAKEEN) {
+			irqwake_stat = rtc_read(OMAP_RTC_IRQWAKEEN);
+			irqwake_stat &= ~OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN;
+			rtc_write(irqwake_stat, OMAP_RTC_IRQWAKEEN);
+		}
+	} else {
 		rtc_write(irqstat, OMAP_RTC_INTERRUPTS_REG);
+	}
 	return 0;
 }
 #endif
-- 
1.7.9.5



From gururaja.hebbar at ti.com  Wed Jul  3 04:47:03 2013
From: gururaja.hebbar at ti.com (Hebbar Gururaja)
Date: Wed, 3 Jul 2013 14:17:03 +0530
Subject: [Patch V2 2/4] ARM: Davinci: da8xx/omap-l1: Remove hard coding of rtc
 device wakeup
In-Reply-To: <1372841225-18813-1-git-send-email-gururaja.hebbar@ti.com>
References: <1372841225-18813-1-git-send-email-gururaja.hebbar@ti.com>
Message-ID: <1372841225-18813-3-git-send-email-gururaja.hebbar@ti.com>

Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
duplicate call from the rtc device registration can be removed.

This is basically a partial revert of the prev commit

commit 75c99bb0006ee065b4e2995078d779418b0fab54
Author: Sekhar Nori <nsekhar at ti.com>

    davinci: da8xx/omap-l1: mark RTC as a wakeup source

Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
Acked-by: Kevin Hilman <khilman at linaro.org>
Acked-by: Sekhar Nori <nsekhar at ti.com>
Cc: Russell King <linux at arm.linux.org.uk>
---
Changes in V2:
	- Coding style corrections (remove extra space)
	- use prefix ARM: for commit subject keeping with arch/arm convention

:100644 100644 bf57252... 9140b1c... M	arch/arm/mach-davinci/devices-da8xx.c
 arch/arm/mach-davinci/devices-da8xx.c |    9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index bf57252..9140b1c 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -827,14 +827,7 @@ static struct platform_device da8xx_rtc_device = {
 
 int da8xx_register_rtc(void)
 {
-	int ret;
-
-	ret = platform_device_register(&da8xx_rtc_device);
-	if (!ret)
-		/* Atleast on DA850, RTC is a wakeup source */
-		device_init_wakeup(&da8xx_rtc_device.dev, true);
-
-	return ret;
+	return platform_device_register(&da8xx_rtc_device);
 }
 
 static void __iomem *da8xx_ddr2_ctlr_base;
-- 
1.7.9.5



From anup.patel at linaro.org  Wed Jul  3 04:46:23 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Wed, 3 Jul 2013 14:16:23 +0530
Subject: [PATCH] arm64: KVM: Support Cortex-A57 guest CPU on APM X-Gene
 host
In-Reply-To: <1372840923-12808-1-git-send-email-anup.patel@linaro.org>
References: <1372840923-12808-1-git-send-email-anup.patel@linaro.org>
Message-ID: <CALrVBkssu1_swS6rYocVDtXZxBvriiMqK6x211-MLRKXvQtEOw@mail.gmail.com>

On 3 July 2013 14:12, Anup Patel <anup.patel at linaro.org> wrote:
> Update kvm_target_cpu() to allow Cortex-A57 guest CPU on APM X-Gene.
>
> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> ---
>  arch/arm64/kvm/guest.c |   10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 2c3ff67..765f56f 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -207,8 +207,13 @@ int __attribute_const__ kvm_target_cpu(void)
>         unsigned long implementor = read_cpuid_implementor();
>         unsigned long part_number = read_cpuid_part_number();
>
> -       if (implementor != ARM_CPU_IMP_ARM)
> -               return -EINVAL;
> +       switch (implementor) {
> +       case ARM_CPU_IMP_ARM:
> +       case ARM_CPU_IMP_APM:
> +               break;
> +       default:
> +               return -EINVAL;
> +       }
>
>         switch (part_number) {
>         case ARM_CPU_PART_AEM_V8:
> @@ -216,6 +221,7 @@ int __attribute_const__ kvm_target_cpu(void)
>         case ARM_CPU_PART_FOUNDATION:
>                 return KVM_ARM_TARGET_FOUNDATION_V8;
>         case ARM_CPU_PART_CORTEX_A57:
> +       case APM_CPU_PART_POTENZA:
>                 /* Currently handled by the generic backend */
>                 return KVM_ARM_TARGET_CORTEX_A57;
>         default:
> --
> 1.7.9.5
>

Hi Catalin/Marc,

This patch depends on the patch titled "arm64: Add defines
for APM ARMv8 implementation" from Vinyak Kale.

Regards,
Anup


From christian.ruppert at abilis.com  Wed Jul  3 04:54:04 2013
From: christian.ruppert at abilis.com (Christian Ruppert)
Date: Wed, 3 Jul 2013 10:54:04 +0200
Subject: [PATCH v2] pinctrl: elaborate a bit on arrangements in doc
In-Reply-To: <51CCB611.6010709@wwwdotorg.org>
References: <1372326887-6497-1-git-send-email-linus.walleij@stericsson.com>
 <51CCB611.6010709@wwwdotorg.org>
Message-ID: <20130703085403.GC19130@ab42.lan>

On Thu, Jun 27, 2013 at 04:00:49PM -0600, Stephen Warren wrote:
> On 06/27/2013 03:54 AM, Linus Walleij wrote:
> > From: Linus Walleij <linus.walleij at linaro.org>
> [...]
> > +From a kernel point of view, however, these are different aspects of the
> > +hardware and shall be put into different subsystems.
> > +
> > +Electrical properties of the pin such as biasing and drive strength
> > +may be placed at some pin-specific register in all cases or as part
> > +of the GPIO register in case (B) especially. This doesn't mean that such
> > +properties necessarily pertain to what the Linux kernel calls "GPIO".
> 
> Is it worth explaining which Linux subsystem each of the three aspects
> are controlled by. Something like:
> 
> -----
> Registers (or fields within registers) that control electrical
> properties of the pin such as biasing and drive strength should be
> exposed through the pinctrl subsystem, as "pin configuration" settings.
> 
> Registers (or fields within registers) that control muxing of signals
> from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should
> be exposed through the pinctrl subssytem, as mux functions.
> 
> Registers (or fields within registers) that control GPIO functionality
> such as setting a GPIO's output value, reading a GPIO's input value, or
> setting GPIO pin direction should be exposed through the GPIO subsystem.
> 
> Depending on the exact HW register design, some functions exposed by the
> GPIO subsystem may call into the pinctrl subsystem in order to
> co-ordinate register settings across HW modules. In particular, this may
> be needed for HW with separate GPIO and pin controller HW modules, where
> e.g. GPIO direction is determined by a register in the pin controller HW
> module rather than the GPIO HW module.
> -----

I agree, this is really worth mentioning in some place, maybe even a
more prominent one than here.

-- 
  Christian Ruppert              ,          <christian.ruppert at abilis.com>
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates


From maxime.ripard at free-electrons.com  Wed Jul  3 04:55:05 2013
From: maxime.ripard at free-electrons.com (maxime.ripard at free-electrons.com)
Date: Wed, 3 Jul 2013 10:55:05 +0200
Subject: [PATCH RESEND] video: mxsfb: fix color settings for 18bit data
 bus and 32bpp
In-Reply-To: <51C01DE1.8030300@digi.com>
References: <51C01DE1.8030300@digi.com>
Message-ID: <20130703085505.GG2969@lukather>

Hi Jean-Christophe,

On Tue, Jun 18, 2013 at 10:44:17AM +0200, Hector Palacios wrote:
> For a combination of 18bit LCD data bus width and a color
> mode of 32bpp, the driver was setting the color mapping to
> rgb666, which is wrong, as the color in memory realy has an
> rgb888 layout.
> 
> This patch also removes the setting of flag CTRL_DF24 that
> makes the driver dimiss the upper 2 bits when handling 32/24bpp
> colors in a diplay with 18bit data bus width. This flag made
> true color images display wrong in such configurations.
> 
> Finally, the color mapping rgb666 has also been removed as nobody
> is using it and high level applications like Qt5 cannot work
> with it either.
> 
> Reference: https://lkml.org/lkml/2013/5/23/220
> Signed-off-by: Hector Palacios <hector.palacios at digi.com>
> Acked-by: Juergen Beisert <jbe at pengutronix.de>
> Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

I don't see this patch in your for-next branch.

It would be really great to have it for 3.11 if possible.

Could you take a look at this patch please?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130703/ea9b9965/attachment.sig>

From lars at metafoo.de  Wed Jul  3 05:01:49 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Wed, 03 Jul 2013 11:01:49 +0200
Subject: [v2 0/5] ASoC: atmel-pcm: align with generic dmaengine framwork
In-Reply-To: <1372840680-2253-1-git-send-email-voice.shen@atmel.com>
References: <1372840680-2253-1-git-send-email-voice.shen@atmel.com>
Message-ID: <51D3E87D.6040203@metafoo.de>

On 07/03/2013 10:37 AM, Bo Shen wrote:
> This patch set is based on linux next-20130701
> 
> mainly implement
>   - move set dma data from hw_params to startup callback to avoid memory leak
>   - align atmel pcm with generic dmaenigne framwork
> 

Whole series looks good to me. Although the DMA driver still references the
ssc struct, but that can be fixed later.

FWIW, Reviewed-by: Lars-Peter Clausen <lars at metafoo.de>


> Bo Shen (5):
>   ASoC: atmel_ssc_dai: move set dma data to startup callback
>   ASoC: atmel_ssc_dai: add error mask define
>   ASoC: atmel-pcm-dma: move prepare for dma to dai prepare
>   ARM: atmel-ssc: change phybase type to dma_addr_t
>   ASoC: atmel-pcm: use generic dmaengine framework
> 
>  include/linux/atmel-ssc.h       |    2 +-
>  sound/soc/atmel/Kconfig         |    1 +
>  sound/soc/atmel/atmel-pcm-dma.c |  118 ++++++---------------------------------
>  sound/soc/atmel/atmel_ssc_dai.c |   36 ++++++------
>  4 files changed, 37 insertions(+), 120 deletions(-)
> 



From rogerq at ti.com  Wed Jul  3 05:13:55 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 3 Jul 2013 12:13:55 +0300
Subject: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during
 bus suspend
In-Reply-To: <Pine.LNX.4.44L0.1307021302430.1086-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307021302430.1086-100000@iolanthe.rowland.org>
Message-ID: <51D3EB53.7080803@ti.com>

On 07/02/2013 08:17 PM, Alan Stern wrote:
> On Tue, 2 Jul 2013, Roger Quadros wrote:
> 
>> On 07/02/2013 12:01 AM, Alan Stern wrote:
>>> On Mon, 1 Jul 2013, Felipe Balbi wrote:
>>>
>>>>> I don't know what Pad wakeup is.  The wakeup signal has to originate 
>>>>> from the EHCI controller, doesn't it?  If not, how does the Pad know 
>>>>> when a wakeup is needed?
>>>>
>>>> That's really an OMAP thing, I guess. Pad wakeup sits in the PRCM (IIRC)
>>>> inside and always on power domain. EHCI sits in another power domain
>>>> which be turned off. When it's turned off (power gated and clock gated)
>>>> the EHCI block has no means to wakeup whatsoever. That's when pad wakeup
>>>> comes into play. It is generated when PRCM sees a change in the actual
>>>> pad of the die. To check who should 'own' the wakeup, it checks the
>>>> muxing settings to verify whose pad is that.
>>>
>>> How does the PRCM know which changes should generate wakeup events?  
>>
>> It doesn't know. It will always generate a wakeup on any change in the monitored pins.
>> We can only configure which pins we want to monitor.
>> So we can't choose which wakeup events we want to monitor. We just can
>> enable or disable all events.
>>
>>> In the EHCI controller, this is managed by the settings of the WKOC_E,
>>> WKDSCNNT_E, and WKCNNT_E bits in the PORTSC registers.  But if EHCI is
>>> powered off, those bits can't be used.
>>
>> Is "powered off" same as ehci_suspend? If yes then how does it work on other systems
>> for remote wakeup?
> 
> Above, Felipe wrote that on OMAP, EHCI sits in a power domain which is
> turned off: power gated and clock gated.  ehci_suspend() doesn't do
> those things, but they are what I was referring to.

OK right, those things are done by OMAP platform support code.
> 
> A PCI-based EHCI controller has two power sources: the core well (which
> is turned off during suspend) and the auxiliary well (which remains
> powered).  That's how remote wakeup works; it uses the auxiliary well.
> 

OK. Thanks for the info.

>>> Also, once the wakeup signal has been turned on, how does it get turned 
>>> off again?
>>
>> That is taken care of by the OMAP pinctrl driver. It will always turn off the
>> wakeup signal once the event is detected and forwarded as an IRQ.
>>
>> I know that all this is a bit ugly :(.
> 
> I still a little confused.  The wakeup signal turns on.  Then the
> pinctrl driver sees it, forwards it as an IRQ, and turns the wakeup
> signal off.  But what if the IRQ is disabled (as it would be with your
> patch)?  Does the IRQ line remain active until it causes an interrupt?  
> What eventually turns off the IRQ line?
> 

In the beagle/panda board, the USB lines of the OMAP are used in ULPI mode.
Here we are monitoring DATA0, DATA1 and DATA3 lines which get configured as Linestate
and Interrupt of the PHY device whenever the PHY is put into suspend mode. This usually
happens when we suspend the EHCI controller.

When EHCI is suspended, the pinctrl wakeup mechanism is active. Whenever there is
a change in the monitored lines we get the PAD IRQ and hence the EHCI IRQ. We don't really
care much about which line changed state.
(NOTE: while suspending, we didn't disable the EHCI IRQ). So we will always get the first IRQ
and then we disable it and queue a hub_resume_work.
Then EHCI resumes, pinctrl wakeup is disabled and EHCI IRQ is enabled.

When pinctrl wakeup mechanism is active, it clears the wakeup event flag after a PAD IRQ, but it
has no control on disabling the interrupt source. If there is a change in the pad, the
PAD IRQ will fire again.

cheers,
-roger


From marc.zyngier at arm.com  Wed Jul  3 05:20:17 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 03 Jul 2013 10:20:17 +0100
Subject: Proposal: mach-dt
In-Reply-To: <1372839486.487159774@f54.mail.ru>
References: <1372839486.487159774@f54.mail.ru>
Message-ID: <51D3ECD1.8030305@arm.com>

On 03/07/13 09:18, Alexander Shiyan wrote:

Hi Alexander,

> More and more platforms are now using devicetree.
> Ideally the platform code contains only one function "of_platform_populate".
> My idea is to make a generic architecture (mach-dt) with the call then add support
> for compatible subarchitectures as they become available in "compatible"-property.
> Your opinion?

Well, my (admittedly partial) opinion is that mach-virt is an incredibly
nicer sounding name, 'specially as you can mistype it as mach-triv.

More seriously, arch/arm/mach-virt is probably what you need.

Cheers,

	M.
-- 
Jazz is not dead. It just smells funny...



From satish.patel at ti.com  Wed Jul  3 05:32:58 2013
From: satish.patel at ti.com (Patel, Satish)
Date: Wed, 3 Jul 2013 09:32:58 +0000
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <1372247257-30186-1-git-send-email-kishon@ti.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
Message-ID: <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>

Hi Kishon,

> -----Original Message-----
> From: ABRAHAM, KISHON VIJAY
> Sent: Wednesday, June 26, 2013 5:17 PM
> To: grant.likely at linaro.org; tony at atomide.com; Balbi, Felipe; ABRAHAM,
> KISHON VIJAY; arnd at arndb.de; swarren at nvidia.com;
> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> foundation.org
> Cc: rob.herring at calxeda.com; rob at landley.net; linux at arm.linux.org.uk;
> benoit.cousson at linaro.org; mchehab at redhat.com; cesarb at cesarb.net;
> davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org; Shilimkar,
> Santosh; devicetree-discuss at lists.ozlabs.org; linux-
> doc at vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T; Cherian,
> George
> Subject: [PATCH v9 0/8] Generic PHY Framework
> 
> Added a generic PHY framework that provides a set of APIs for the PHY
> drivers
> to create/destroy a PHY and APIs for the PHY users to obtain a
> reference to
> the PHY with or without using phandle.
> 
> This framework will be of use only to devices that uses external PHY
> (PHY
> functionality is not embedded within the controller).
> 
> The intention of creating this framework is to bring the phy drivers
> spread
> all over the Linux kernel to drivers/phy to increase code re-use and
> to
> increase code maintainability.

I would like to use this framework for a smart-card controller connected to a
smart-card phy. I have some questions and would like to get feedback on the same.

I am using ?TDA8026" Smartcard PHY from NXP. Here is the link for datasheet
and app note for the same. The smart card controller is inside the TI SoC
I am working with.

Datasheet : 
www.nxp.com/documents/data_sheet/TDA8026.pdf?

Appnote :
http://www.nxp.com/documents/application_note/AN10724.pdf

The TI SoC details are not public (yet). I can provide details to you offline.

Brief about operation:
-	The controller can work with and without a PHY
-	When not using PHY, it is limited to talking to a single
	smart card. There is also a need to put external de-activation logic
	on card removal for this case.
-	With a PHY you can use more than one smart card.
-	Phy has 5 slots :  1 for smart card (credit/debit/other card with chip) 
      and others for SAM ? SIM like modules
- 	Once the PHY is initialized, there are some operations that the controller
	can request of the PHY like:
	- Card configurations  - set voltage
	- Activation of card
	- ATR ? Answer to reset
	- Warm reset
	- ADPU exchange
	- Deactivation ( Normal/Emergency)
- 	In the mode when smartcard controller talks directly to the card	without the need
	for a PHY, all the above operations will be carried	out by the controller itself

My current thought process is to make the controller driver provide the user interface
and talk to the PHY using the generic PHY framework you proposed. In the case where there
is no PHY, my idea is to create a "dummy" PHY which uses the controller functionality itself.

What I seem to be missing from the PHY framework is support for event detection and generic
read/write API which will enable the controller to talk to the PHY for the operations listed
above and also react to events from the PHY.

Is there a reason why such functionality has not been included. If it was only a case
of lack of use case, then do you think it will be useful to extend the framework to add
such functionality? I can help with the development.

Thanks,
Satish



From josephl at nvidia.com  Wed Jul  3 05:50:36 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Jul 2013 17:50:36 +0800
Subject: [PATCH V2 00/11] ARM: tegra114: add support for system suspend
Message-ID: <1372845047-25147-1-git-send-email-josephl@nvidia.com>

This series introduce system suspend function for Tegra114 and depend on
the series of "ARM: tegra114: cpuidle: add power down state".

Verified on Seaboard, Cardhu and Dalmore and with THUMB2_KERNEL as well.

V2:
* do some fixes from the comments in the review

Joseph Lo (11):
  ARM: tegra: do v7_invalidate_l1 only when CPU is Cortex-A9
  ARM: tegra: add a flag for tegra_disable_clean_inv_dcache to do LoUIS
    or ALL
  ARM: tegra114: set up the correct L2 data RAM latency for Cortex-A15
  ARM: tegra114: add low level support code for cluster power down
  ARM: tegra114: shut off the CPU rail when the last CPU in suspend
  ARM: tegra114: hook tegra_tear_down_cpu function
  ARM: tegra114: flowctrl: add support for cpu_suspend_enter/exit
  clk: tegra114: add suspend/resume function for tegra_cpu_car_ops
  ARM: tegra: remove the limitation that Tegra114 can't support suspend
  ARM: dts: tegra114: dalmore: add GPIO power key support
  ARM: dts: tegra114: dalmore: add PM configurations for PMC

 arch/arm/boot/dts/tegra114-dalmore.dts | 18 ++++++++++++++++++
 arch/arm/mach-tegra/flowctrl.c         |  2 ++
 arch/arm/mach-tegra/flowctrl.h         |  7 +++++++
 arch/arm/mach-tegra/headsmp.S          |  3 ++-
 arch/arm/mach-tegra/hotplug.c          |  2 +-
 arch/arm/mach-tegra/pm.c               |  8 +++-----
 arch/arm/mach-tegra/pmc.c              | 16 +++++++++++++++-
 arch/arm/mach-tegra/reset-handler.S    |  8 ++++++--
 arch/arm/mach-tegra/sleep-tegra20.S    |  1 +
 arch/arm/mach-tegra/sleep-tegra30.S    |  7 ++++++-
 arch/arm/mach-tegra/sleep.S            | 29 ++++++++++++++++++++++++++++-
 arch/arm/mach-tegra/sleep.h            |  6 +++++-
 drivers/clk/tegra/clk-tegra114.c       | 26 ++++++++++++++++++++++++++
 13 files changed, 120 insertions(+), 13 deletions(-)

-- 
1.8.3.2



From josephl at nvidia.com  Wed Jul  3 05:50:38 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Jul 2013 17:50:38 +0800
Subject: [PATCH V2 02/11] ARM: tegra: add a flag for
 tegra_disable_clean_inv_dcache to do LoUIS or ALL
In-Reply-To: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
References: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
Message-ID: <1372845047-25147-3-git-send-email-josephl@nvidia.com>

Adding a flag for tegra_disable_clean_inv_dcache to flush cache as LoUIS
or ALL. After this patch, the v7_flush_dcache_louis is used for CPU hotplug
and CPU suspend in CPU power down (e.g. CPU idle power-down mode) case. And
the v7_flush_dcache_all is used for CPU cluster power down (e.g. suspend to
LP2 mode).

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V2:
* change the define value of TEGRA_FLUSH_CACHE_LOUIS and ALL to 0 and 1
---
 arch/arm/mach-tegra/hotplug.c       | 2 +-
 arch/arm/mach-tegra/sleep-tegra20.S | 1 +
 arch/arm/mach-tegra/sleep-tegra30.S | 1 +
 arch/arm/mach-tegra/sleep.S         | 7 ++++++-
 arch/arm/mach-tegra/sleep.h         | 6 +++++-
 5 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-tegra/hotplug.c b/arch/arm/mach-tegra/hotplug.c
index a52c10e..4687ec0 100644
--- a/arch/arm/mach-tegra/hotplug.c
+++ b/arch/arm/mach-tegra/hotplug.c
@@ -37,7 +37,7 @@ int tegra_cpu_kill(unsigned cpu)
 void __ref tegra_cpu_die(unsigned int cpu)
 {
 	/* Clean L1 data cache */
-	tegra_disable_clean_inv_dcache();
+	tegra_disable_clean_inv_dcache(TEGRA_FLUSH_CACHE_LOUIS);
 
 	/* Shut down the current CPU. */
 	tegra_hotplug_shutdown();
diff --git a/arch/arm/mach-tegra/sleep-tegra20.S b/arch/arm/mach-tegra/sleep-tegra20.S
index e3f2417..f87721d 100644
--- a/arch/arm/mach-tegra/sleep-tegra20.S
+++ b/arch/arm/mach-tegra/sleep-tegra20.S
@@ -191,6 +191,7 @@ ENTRY(tegra20_sleep_cpu_secondary_finish)
 	mrc	p15, 0, r11, c1, c0, 1  @ save actlr before exiting coherency
 
 	/* Flush and disable the L1 data cache */
+	mov	r0, #TEGRA_FLUSH_CACHE_LOUIS
 	bl	tegra_disable_clean_inv_dcache
 
 	mov32	r0, TEGRA_PMC_VIRT + PMC_SCRATCH41
diff --git a/arch/arm/mach-tegra/sleep-tegra30.S b/arch/arm/mach-tegra/sleep-tegra30.S
index 5877f26..6744161 100644
--- a/arch/arm/mach-tegra/sleep-tegra30.S
+++ b/arch/arm/mach-tegra/sleep-tegra30.S
@@ -137,6 +137,7 @@ ENTRY(tegra30_sleep_cpu_secondary_finish)
 	mov	r7, lr
 
 	/* Flush and disable the L1 data cache */
+	mov 	r0, #TEGRA_FLUSH_CACHE_LOUIS
 	bl	tegra_disable_clean_inv_dcache
 
 	/* Powergate this CPU. */
diff --git a/arch/arm/mach-tegra/sleep.S b/arch/arm/mach-tegra/sleep.S
index 9daaef2..6d6600d 100644
--- a/arch/arm/mach-tegra/sleep.S
+++ b/arch/arm/mach-tegra/sleep.S
@@ -56,7 +56,9 @@ ENTRY(tegra_disable_clean_inv_dcache)
 	isb
 
 	/* Flush the D-cache */
-	bl	v7_flush_dcache_louis
+	cmp	r0, #TEGRA_FLUSH_CACHE_ALL
+	blne	v7_flush_dcache_louis
+	bleq	v7_flush_dcache_all
 
 	/* Trun off coherency */
 	exit_smp r4, r5
@@ -73,9 +75,12 @@ ENDPROC(tegra_disable_clean_inv_dcache)
  * tegra?_tear_down_cpu
  */
 ENTRY(tegra_sleep_cpu_finish)
+	mov	r4, r0
 	/* Flush and disable the L1 data cache */
+	mov	r0, #TEGRA_FLUSH_CACHE_ALL
 	bl	tegra_disable_clean_inv_dcache
 
+	mov	r0, r4
 	mov32	r6, tegra_tear_down_cpu
 	ldr	r1, [r6]
 	add	r1, r1, r0
diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
index 98b7da6..e907e40 100644
--- a/arch/arm/mach-tegra/sleep.h
+++ b/arch/arm/mach-tegra/sleep.h
@@ -41,6 +41,10 @@
 #define CPU_NOT_RESETTABLE	0
 #endif
 
+/* flag of tegra_disable_clean_inv_dcache to do LoUIS or all */
+#define TEGRA_FLUSH_CACHE_LOUIS	0
+#define TEGRA_FLUSH_CACHE_ALL	1
+
 #ifdef __ASSEMBLY__
 /* returns the offset of the flow controller halt register for a cpu */
 .macro cpu_to_halt_reg rd, rcpu
@@ -144,7 +148,7 @@ void tegra_pen_lock(void);
 void tegra_pen_unlock(void);
 void tegra_resume(void);
 int tegra_sleep_cpu_finish(unsigned long);
-void tegra_disable_clean_inv_dcache(void);
+void tegra_disable_clean_inv_dcache(u32 flag);
 
 #ifdef CONFIG_HOTPLUG_CPU
 void tegra20_hotplug_shutdown(void);
-- 
1.8.3.2



From josephl at nvidia.com  Wed Jul  3 05:50:37 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Jul 2013 17:50:37 +0800
Subject: [PATCH V2 01/11] ARM: tegra: do v7_invalidate_l1 only when CPU is
 Cortex-A9
In-Reply-To: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
References: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
Message-ID: <1372845047-25147-2-git-send-email-josephl@nvidia.com>

The v7_invalidate_l1 was used for the L1 cache that come out from reset
in a undefined state. This is no need for Cortex-A15. We do it for A9
only.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V2:
* take care the v7_invalidate_l1 in tegra_secondary_startup also
---
 arch/arm/mach-tegra/headsmp.S       | 3 ++-
 arch/arm/mach-tegra/reset-handler.S | 7 +++++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-tegra/headsmp.S b/arch/arm/mach-tegra/headsmp.S
index 045c16f..2072e73 100644
--- a/arch/arm/mach-tegra/headsmp.S
+++ b/arch/arm/mach-tegra/headsmp.S
@@ -6,6 +6,7 @@
         .section ".text.head", "ax"
 
 ENTRY(tegra_secondary_startup)
-        bl      v7_invalidate_l1
+        check_cpu_part_num 0xc09, r8, r9
+        bleq    v7_invalidate_l1
         b       secondary_startup
 ENDPROC(tegra_secondary_startup)
diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
index 39dc9e7..75285a3 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -40,9 +40,11 @@
  *	  re-enabling sdram.
  *
  *	r6: SoC ID
+ *	r8: CPU part number
  */
 ENTRY(tegra_resume)
-	bl	v7_invalidate_l1
+	check_cpu_part_num 0xc09, r8, r9
+	bleq	v7_invalidate_l1
 
 	cpu_id	r0
 	tegra_get_soc_id TEGRA_APB_MISC_BASE, r6
@@ -70,7 +72,8 @@ no_cpu0_chk:
 	str	r1, [r2]
 1:
 
-	check_cpu_part_num 0xc09, r8, r9
+	mov32	r9, 0xc09
+	cmp	r8, r9
 	bne	not_ca9
 #ifdef CONFIG_HAVE_ARM_SCU
 	/* enable SCU */
-- 
1.8.3.2



From josephl at nvidia.com  Wed Jul  3 05:50:40 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Jul 2013 17:50:40 +0800
Subject: [PATCH V2 04/11] ARM: tegra114: add low level support code for
 cluster power down
In-Reply-To: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
References: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
Message-ID: <1372845047-25147-5-git-send-email-josephl@nvidia.com>

When the CPU cluster power down, the vGIC is powered down too. The
flow controller needs to monitor the legacy interrupt controller to
wake up CPU. So setting up the appropriate wake up event in flow
controller.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V2:
* no change
---
 arch/arm/mach-tegra/flowctrl.h      | 2 ++
 arch/arm/mach-tegra/sleep-tegra30.S | 6 +++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/flowctrl.h b/arch/arm/mach-tegra/flowctrl.h
index e56a950..de0acb9 100644
--- a/arch/arm/mach-tegra/flowctrl.h
+++ b/arch/arm/mach-tegra/flowctrl.h
@@ -28,6 +28,8 @@
 #define FLOW_CTRL_SCLK_RESUME		(1 << 27)
 #define FLOW_CTRL_HALT_CPU_IRQ		(1 << 10)
 #define	FLOW_CTRL_HALT_CPU_FIQ		(1 << 8)
+#define FLOW_CTRL_HALT_LIC_IRQ		(1 << 11)
+#define FLOW_CTRL_HALT_LIC_FIQ		(1 << 10)
 #define FLOW_CTRL_HALT_GIC_IRQ		(1 << 9)
 #define FLOW_CTRL_HALT_GIC_FIQ		(1 << 8)
 #define FLOW_CTRL_CPU0_CSR		0x8
diff --git a/arch/arm/mach-tegra/sleep-tegra30.S b/arch/arm/mach-tegra/sleep-tegra30.S
index 6744161..ecad4ea 100644
--- a/arch/arm/mach-tegra/sleep-tegra30.S
+++ b/arch/arm/mach-tegra/sleep-tegra30.S
@@ -175,8 +175,12 @@ tegra30_enter_sleep:
 	orr	r0, r0, #FLOW_CTRL_CSR_ENABLE
 	str	r0, [r6, r2]
 
+	tegra_get_soc_id TEGRA_APB_MISC_BASE, r10
+	cmp	r10, #TEGRA30
 	mov	r0, #FLOW_CTRL_WAIT_FOR_INTERRUPT
-	orr	r0, r0, #FLOW_CTRL_HALT_CPU_IRQ | FLOW_CTRL_HALT_CPU_FIQ
+	orreq	r0, r0, #FLOW_CTRL_HALT_CPU_IRQ | FLOW_CTRL_HALT_CPU_FIQ
+	orrne   r0, r0, #FLOW_CTRL_HALT_LIC_IRQ | FLOW_CTRL_HALT_LIC_FIQ
+
 	cpu_to_halt_reg r2, r1
 	str	r0, [r6, r2]
 	dsb
-- 
1.8.3.2



From josephl at nvidia.com  Wed Jul  3 05:50:39 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Jul 2013 17:50:39 +0800
Subject: [PATCH V2 03/11] ARM: tegra114: set up the correct L2 data RAM
 latency for Cortex-A15
In-Reply-To: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
References: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
Message-ID: <1372845047-25147-4-git-send-email-josephl@nvidia.com>

When there is a cluster power down cycle in suspend, we need to set up
the correct L2 RAM data RAM latency to make L2 cache work correctly. This
is only needed for cluster 0 and needs to be done in tegra_resume before
the cache is enabled.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V2:
* no change
---
 arch/arm/mach-tegra/reset-handler.S |  1 +
 arch/arm/mach-tegra/sleep.S         | 22 ++++++++++++++++++++++
 2 files changed, 23 insertions(+)

diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
index 75285a3..34614bd 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -45,6 +45,7 @@
 ENTRY(tegra_resume)
 	check_cpu_part_num 0xc09, r8, r9
 	bleq	v7_invalidate_l1
+	blne	tegra_init_l2_for_a15
 
 	cpu_id	r0
 	tegra_get_soc_id TEGRA_APB_MISC_BASE, r6
diff --git a/arch/arm/mach-tegra/sleep.S b/arch/arm/mach-tegra/sleep.S
index 6d6600d..8388113 100644
--- a/arch/arm/mach-tegra/sleep.S
+++ b/arch/arm/mach-tegra/sleep.S
@@ -69,6 +69,28 @@ ENDPROC(tegra_disable_clean_inv_dcache)
 
 #ifdef CONFIG_PM_SLEEP
 /*
+ * tegra_init_l2_for_a15
+ *
+ * set up the correct L2 cache data RAM latency
+ */
+ENTRY(tegra_init_l2_for_a15)
+	mrc	p15, 0, r0, c0, c0, 5
+	ubfx	r0, r0, #8, #4
+	tst	r0, #1				@ only need for cluster 0
+	bne	_exit_init_l2_a15
+
+	mrc	p15, 0x1, r0, c9, c0, 2
+	and	r0, r0, #7
+	cmp	r0, #2
+	bicne	r0, r0, #7
+	orrne	r0, r0, #2
+	mcrne	p15, 0x1, r0, c9, c0, 2
+_exit_init_l2_a15:
+
+	mov	pc, lr
+ENDPROC(tegra_init_l2_for_a15)
+
+/*
  * tegra_sleep_cpu_finish(unsigned long v2p)
  *
  * enters suspend in LP2 by turning off the mmu and jumping to
-- 
1.8.3.2



From josephl at nvidia.com  Wed Jul  3 05:50:42 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Jul 2013 17:50:42 +0800
Subject: [PATCH V2 06/11] ARM: tegra114: hook tegra_tear_down_cpu function
In-Reply-To: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
References: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
Message-ID: <1372845047-25147-7-git-send-email-josephl@nvidia.com>

Hooking tegra_tear_down_cpu for Tegra114 for supporting cluster power
down when CPU cluster suspneded in LP2.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V2:
* take care the combination of the selection of the config ARCH_TEGRA_3x_SOC
  and TEGRA_114_SOC
---
 arch/arm/mach-tegra/pm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index 261fec1..3d07cd5 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -52,7 +52,9 @@ static void tegra_tear_down_cpu_init(void)
 			tegra_tear_down_cpu = tegra20_tear_down_cpu;
 		break;
 	case TEGRA30:
-		if (IS_ENABLED(CONFIG_ARCH_TEGRA_3x_SOC))
+	case TEGRA114:
+		if (IS_ENABLED(CONFIG_ARCH_TEGRA_3x_SOC) ||
+		    IS_ENABLED(CONFIG_ARCH_TEGRA_114_SOC))
 			tegra_tear_down_cpu = tegra30_tear_down_cpu;
 		break;
 	}
-- 
1.8.3.2



From josephl at nvidia.com  Wed Jul  3 05:50:41 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Jul 2013 17:50:41 +0800
Subject: [PATCH V2 05/11] ARM: tegra114: shut off the CPU rail when the last
 CPU in suspend
In-Reply-To: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
References: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
Message-ID: <1372845047-25147-6-git-send-email-josephl@nvidia.com>

When the last CPU core in suspend, the CPU power rail can be turned off
by setting flags to flow controller. Then the flow controller will inform
PMC to turn off the CPU rail when the last CPU goes into suspend.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V2:
* presumably we need to code the cut off the CRAIL after Tegra114, modify the
  code for that
---
 arch/arm/mach-tegra/flowctrl.h |  5 +++++
 arch/arm/mach-tegra/pmc.c      | 16 +++++++++++++++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/flowctrl.h b/arch/arm/mach-tegra/flowctrl.h
index de0acb9..c89aac6 100644
--- a/arch/arm/mach-tegra/flowctrl.h
+++ b/arch/arm/mach-tegra/flowctrl.h
@@ -35,6 +35,11 @@
 #define FLOW_CTRL_CPU0_CSR		0x8
 #define	FLOW_CTRL_CSR_INTR_FLAG		(1 << 15)
 #define FLOW_CTRL_CSR_EVENT_FLAG	(1 << 14)
+#define FLOW_CTRL_CSR_ENABLE_EXT_CRAIL	(1 << 13)
+#define FLOW_CTRL_CSR_ENABLE_EXT_NCPU	(1 << 12)
+#define FLOW_CTRL_CSR_ENABLE_EXT_MASK ( \
+		FLOW_CTRL_CSR_ENABLE_EXT_NCPU | \
+		FLOW_CTRL_CSR_ENABLE_EXT_CRAIL)
 #define FLOW_CTRL_CSR_ENABLE		(1 << 0)
 #define FLOW_CTRL_HALT_CPU1_EVENTS	0x14
 #define FLOW_CTRL_CPU1_CSR		0x18
diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
index eb3fa4a..8345fcd 100644
--- a/arch/arm/mach-tegra/pmc.c
+++ b/arch/arm/mach-tegra/pmc.c
@@ -21,6 +21,7 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 
+#include "flowctrl.h"
 #include "fuse.h"
 #include "pm.h"
 #include "pmc.h"
@@ -195,13 +196,26 @@ enum tegra_suspend_mode tegra_pmc_get_suspend_mode(void)
 
 void tegra_pmc_pm_set(enum tegra_suspend_mode mode)
 {
-	u32 reg;
+	u32 reg, csr_reg;
 	unsigned long rate = 0;
 
 	reg = tegra_pmc_readl(PMC_CTRL);
 	reg |= TEGRA_POWER_CPU_PWRREQ_OE;
 	reg &= ~TEGRA_POWER_EFFECT_LP0;
 
+	switch (tegra_chip_id) {
+	case TEGRA20:
+	case TEGRA30:
+		break;
+	default:
+		/* Turn off CRAIL */
+		csr_reg = flowctrl_read_cpu_csr(0);
+		csr_reg &= ~FLOW_CTRL_CSR_ENABLE_EXT_MASK;
+		csr_reg |= FLOW_CTRL_CSR_ENABLE_EXT_CRAIL;
+		flowctrl_write_cpu_csr(0, csr_reg);
+		break;
+	}
+
 	switch (mode) {
 	case TEGRA_SUSPEND_LP2:
 		rate = clk_get_rate(tegra_pclk);
-- 
1.8.3.2



From josephl at nvidia.com  Wed Jul  3 05:50:43 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Jul 2013 17:50:43 +0800
Subject: [PATCH V2 07/11] ARM: tegra114: flowctrl: add support for
 cpu_suspend_enter/exit
In-Reply-To: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
References: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
Message-ID: <1372845047-25147-8-git-send-email-josephl@nvidia.com>

The flow controller can help CPU to go into suspend mode (powered-down
state). When CPU goes into powered-down state, it needs some careful
settings before getting into and after leaving. The enter and exit
functions do that by configuring appropriate mode for flow controller.

For Tegra114, the setting is compatible with Tegra30.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V2:
* no change
---
 arch/arm/mach-tegra/flowctrl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-tegra/flowctrl.c b/arch/arm/mach-tegra/flowctrl.c
index b477ef3..5348543 100644
--- a/arch/arm/mach-tegra/flowctrl.c
+++ b/arch/arm/mach-tegra/flowctrl.c
@@ -86,6 +86,7 @@ void flowctrl_cpu_suspend_enter(unsigned int cpuid)
 		reg |= TEGRA20_FLOW_CTRL_CSR_WFE_CPU0 << cpuid;
 		break;
 	case TEGRA30:
+	case TEGRA114:
 		/* clear wfe bitmap */
 		reg &= ~TEGRA30_FLOW_CTRL_CSR_WFE_BITMAP;
 		/* clear wfi bitmap */
@@ -123,6 +124,7 @@ void flowctrl_cpu_suspend_exit(unsigned int cpuid)
 		reg &= ~TEGRA20_FLOW_CTRL_CSR_WFI_BITMAP;
 		break;
 	case TEGRA30:
+	case TEGRA114:
 		/* clear wfe bitmap */
 		reg &= ~TEGRA30_FLOW_CTRL_CSR_WFE_BITMAP;
 		/* clear wfi bitmap */
-- 
1.8.3.2



From josephl at nvidia.com  Wed Jul  3 05:50:44 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Jul 2013 17:50:44 +0800
Subject: [PATCH V2 08/11] clk: tegra114: add suspend/resume function for
 tegra_cpu_car_ops
In-Reply-To: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
References: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
Message-ID: <1372845047-25147-9-git-send-email-josephl@nvidia.com>

Adding suspend/resume function for tegra_cpu_car_ops. We only save and
restore the setting of the clock of CoreSight. Other clocks still need
to be taken care by clock driver.

Cc: Mike Turquette <mturquette at linaro.org>
Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V2:
* fix the coding style
---
 drivers/clk/tegra/clk-tegra114.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index 9839e86..0908fcd 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -290,6 +290,12 @@
 #define PMC_PLLM_WB0_OVERRIDE 0x1dc
 #define PMC_PLLM_WB0_OVERRIDE_2 0x2b0
 
+#ifdef CONFIG_PM_SLEEP
+static struct cpu_clk_suspend_context {
+	u32 clk_csite_src;
+} tegra114_cpu_clk_sctx;
+#endif
+
 static int periph_clk_enb_refcnt[CLK_OUT_ENB_NUM * 32];
 
 static void __iomem *clk_base;
@@ -2142,9 +2148,29 @@ static void tegra114_disable_cpu_clock(u32 cpu)
 	/* flow controller would take care in the power sequence. */
 }
 
+#ifdef CONFIG_PM_SLEEP
+static void tegra114_cpu_clock_suspend(void)
+{
+	/* switch coresite to clk_m, save off original source */
+	tegra114_cpu_clk_sctx.clk_csite_src =
+				readl(clk_base + CLK_SOURCE_CSITE);
+	writel(3 << 30, clk_base + CLK_SOURCE_CSITE);
+}
+
+static void tegra114_cpu_clock_resume(void)
+{
+	writel(tegra114_cpu_clk_sctx.clk_csite_src,
+					clk_base + CLK_SOURCE_CSITE);
+}
+#endif
+
 static struct tegra_cpu_car_ops tegra114_cpu_car_ops = {
 	.wait_for_reset	= tegra114_wait_cpu_in_reset,
 	.disable_clock	= tegra114_disable_cpu_clock,
+#ifdef CONFIG_PM_SLEEP
+	.suspend	= tegra114_cpu_clock_suspend,
+	.resume		= tegra114_cpu_clock_resume,
+#endif
 };
 
 static const struct of_device_id pmc_match[] __initconst = {
-- 
1.8.3.2



From josephl at nvidia.com  Wed Jul  3 05:50:46 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Jul 2013 17:50:46 +0800
Subject: [PATCH V2 10/11] ARM: dts: tegra114: dalmore: add GPIO power key
 support
In-Reply-To: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
References: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
Message-ID: <1372845047-25147-11-git-send-email-josephl@nvidia.com>

Adding the GPIO power key and enabling the wake up function.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V2:
* no change
---
 arch/arm/boot/dts/tegra114-dalmore.dts | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index cb640eb..b97a8cc 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -883,6 +883,17 @@
 		};
 	};
 
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		power {
+			label = "Power";
+			gpios = <&gpio TEGRA_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
+			linux,code = <116>; /* KEY_POWER */
+			gpio-key,wakeup;
+		};
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
-- 
1.8.3.2



From josephl at nvidia.com  Wed Jul  3 05:50:45 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Jul 2013 17:50:45 +0800
Subject: [PATCH V2 09/11] ARM: tegra: remove the limitation that Tegra114
 can't support suspend
In-Reply-To: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
References: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
Message-ID: <1372845047-25147-10-git-send-email-josephl@nvidia.com>

The Tegra114 can support suspend function now, removing the limitation.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V2:
* no change
---
 arch/arm/mach-tegra/pm.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index 3d07cd5..5792872 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -173,10 +173,6 @@ void tegra_idle_lp2_last(void)
 enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
 				enum tegra_suspend_mode mode)
 {
-	/* Tegra114 didn't support any suspending mode yet. */
-	if (tegra_chip_id == TEGRA114)
-		return TEGRA_SUSPEND_NONE;
-
 	/*
 	 * The Tegra devices only support suspending to LP2 currently.
 	 */
-- 
1.8.3.2



From josephl at nvidia.com  Wed Jul  3 05:50:47 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Jul 2013 17:50:47 +0800
Subject: [PATCH V2 11/11] ARM: dts: tegra114: dalmore: add PM configurations
 for PMC
In-Reply-To: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
References: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
Message-ID: <1372845047-25147-12-git-send-email-josephl@nvidia.com>

Adding the PM configurations for PMC to support platform suspend.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V2:
* no change
---
 arch/arm/boot/dts/tegra114-dalmore.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index b97a8cc..625bf3a 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -850,6 +850,13 @@
 
 	pmc {
 		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <2>;
+		nvidia,cpu-pwr-good-time = <500>;
+		nvidia,cpu-pwr-off-time = <300>;
+		nvidia,core-pwr-good-time = <641 3845>;
+		nvidia,core-pwr-off-time = <61036>;
+		nvidia,core-power-req-active-high;
+		nvidia,sys-clock-req-active-high;
 	};
 
 	ahub {
-- 
1.8.3.2



From josh.wu at atmel.com  Wed Jul  3 05:50:28 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Wed, 3 Jul 2013 17:50:28 +0800
Subject: [PATCH v5 0/6] mtd: atmel_nand: enable Nand Flash Controller (NFC)
 support
Message-ID: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>

This patch series enable NFC support for SAMA5 soc. It can send command,
address cycles automaticly. Also when enable NFC sram, NFC will transfer
data to sram. Which can save lots of cpu time.

The mtd speed test results (non-NFC vs NFC), run in sama5d3x-ek with DMA
enable, is in the end of this patch.

v4 --> v5:
 1) rebase to latest l2-mtd.git
 2) remove blank line in EOF for atmel_nand.txt
 3) add blank line for patch 2/6 for coding style.

v3 --> v4:
 1) refine the commit message for ofpart.c patch and also change the
    description in partition.txt
 2) remove len parameter for ofpart.c's change.
 3) use devm_ioremap_resource instead of devm_requrest_and_ioremap.
 4) add BIT_POS macro definition for magic number.

v2 --> v3:
 1) Change the dts usage for NFC. Now use a NFC child node of atmel nand
    to enable NFC driver. In this way the atmel nand driver will include
    a NFC driver, which will be probed if dts has NFC node.
 2) can enable/disable NFC write by sram in dts.
 3) merged J.C's patch(use devm_xxx to simple the code) in this series.
 4) remove unused NFC register definitions. Change the definition names.
 5) trival fix accroding to J.C's suggestion.
 6) modify the ofpart.c for child node check. If the child node has compatible
    property then this node is a device not a partition.

v1 --> v2:
 1) rebase it with latest l2-mtd git tree: 
    - remove useless nand commands (NAND_CMD_DEPLETE1, NAND_CMD_STATUS_ERRORx).
    - adopt to the new nand write function's parameters. Add error message when
      handle subpage write via nfc sram.
 2) rewrite pmecc_enable function. Now I use exist NAND_ECC_READ/WRITE const
    instead of using a new enum definition.

Jean-Christophe PLAGNIOL-VILLARD (1):
  MTD: atmel_nand: use devm_xxx gpio kzalloc, gpio and ioremap

Josh Wu (5):
  mtd: atmel_nand: replace pmecc enable code with one function.
  mtd: atmel_nand: add Nand Flash Controller (NFC) support
  mtd: atmel_nand: enable Nand Flash Controller (NFC) read data via
    sram
  mtd: atmel_nand: enable Nand Flash Controller (NFC) write via sram
  mtd: ofpart: add compatible check for child nodes

 .../devicetree/bindings/mtd/atmel-nand.txt         |   27 +
 .../devicetree/bindings/mtd/partition.txt          |    1 +
 drivers/mtd/nand/atmel_nand.c                      |  877 ++++++++++++++++----
 drivers/mtd/nand/atmel_nand_nfc.h                  |   98 +++
 drivers/mtd/ofpart.c                               |   13 +-
 5 files changed, 853 insertions(+), 163 deletions(-)
 create mode 100644 drivers/mtd/nand/atmel_nand_nfc.h


mtd_speedtest is run in 60M partition with DMA enabled for two cases:
 1. Using NFC and sram read/write with DMA enabled.
 2. Using Non-NFC with DMA enabled.

Summary of the two test results:
 1. With NFC and sram read/write enabled, the write speed will become %10 slower
    and the cpu load also is reduce a lot (50% -> 20%):
                          Non-NFC                  NFC
      Page write Speed:   5536KiB : 46% ~ 64% --> 4989KiB : 13% ~ 22%
      2 Page write speed: 5567KiB : 52% ~ 69% --> 5043KiB : 10% ~ 20%

 2. With NFC and sram read/write enabled, the read speed is almost same and the
    cpu load is reduced (30% -> 15%):
                          Non-NFC                  NFC
      Page read Speed:    9361KiB : %24 ~ 46% --> 9340KiB : 13% ~ 19%
      2 Page read Speed:  9361KiB : %21 ~ 57% --> 9426KiB :  8% ~ 15%

Following is the detail test log:

case 1: Non-NFC with DMA:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: MTD device size 62914560, eraseblock size 131072, page size 2048, count of eraseblocks 480, pages per eraseblock 64, OOB size 64
mtd_speedtest: scanning for bad eraseblocks
mtd_speedtest: scanned 480 eraseblocks, 0 are bad
mtd_speedtest: testing eraseblock write speed
top -n 130 -d 1 | grep speedtest
  513   504 root     R     1164   0%  62% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     D     1164   0%  53% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  57% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  58% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  53% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  60% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  55% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  55% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  59% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  57% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  62% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: eraseblock write speed is 5594 KiB/s
mtd_speedtest: testing eraseblock read speed
  513   504 root     R     1164   0%  27% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  14% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%   5% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%   1% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%   2% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%   1% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: eraseblock read speed is 9442 KiB/s
mtd_speedtest: testing page write speed
  513   504 root     R     1164   0%  46% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  64% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  57% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  64% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  56% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  59% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  59% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  56% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  59% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  62% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  60% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: page write speed is 5536 KiB/s
mtd_speedtest: testing page read speed
  513   504 root     R     1164   0%  46% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  24% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  30% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  30% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  26% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  25% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: page read speed is 9361 KiB/s
  513   504 root     R     1164   0%  24% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: testing 2 page write speed
  513   504 root     R     1164   0%  69% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  56% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  57% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  61% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  55% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  61% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  55% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  52% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  55% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  58% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: 2 page write speed is 5567 KiB/s
mtd_speedtest: testing 2 page read speed
  513   504 root     D     1164   0%  57% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  26% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  21% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  23% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  24% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  25% insmod /root/mtd_test/mtd_speedtest.ko
  513   504 root     R     1164   0%  23% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: 2 page read speed is 9361 KiB/s
mtd_speedtest: Testing erase speed
mtd_speedtest: erase speed is 167411 KiB/s
mtd_speedtest: Testing 2x multi-block erase speed
mtd_speedtest: 2x multi-block erase speed is 326808 KiB/s
mtd_speedtest: Testing 4x multi-block erase speed
  513   504 root     R     1164   0%  74% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: 4x multi-block erase speed is 301176 KiB/s
mtd_speedtest: Testing 8x multi-block erase speed
mtd_speedtest: 8x multi-block erase speed is 326808 KiB/s
mtd_speedtest: Testing 16x multi-block erase speed
mtd_speedtest: 16x multi-block erase speed is 328556 KiB/s
mtd_speedtest: Testing 32x multi-block erase speed
mtd_speedtest: 32x multi-block erase speed is 328556 KiB/s
mtd_speedtest: Testing 64x multi-block erase speed
mtd_speedtest: 64x multi-block erase speed is 325079 KiB/s
mtd_speedtest: finished
=================================================


case 2: NFC with DMA:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: MTD device size 62914560, eraseblock size 131072, page size 2048, count of eraseblocks 480, pages per eraseblock 64, OOB size 64
mtd_speedtest: scanning for bad eraseblocks
mtd_speedtest: scanned 480 eraseblocks, 0 are bad
top -n 130 -d 1 | grep speedtest
mtd_speedtest: testing eraseblock write speed
  514   504 root     R     1164   0%   8% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  12% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  10% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  13% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     D     1164   0%  15% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     D     1164   0%  14% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  11% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%   9% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  15% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  11% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  15% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  12% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: eraseblock write speed is 5105 KiB/s
mtd_speedtest: testing eraseblock read speed
  514   504 root     R     1164   0%  14% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  20% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  17% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%   8% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%   6% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  15% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: eraseblock read speed is 9512 KiB/s
  514   504 root     R     1164   0%   6% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: testing page write speed
  514   504 root     R     1164   0%  17% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  20% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  13% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  12% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  14% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  17% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  11% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  22% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  17% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  14% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  17% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: page write speed is 4989 KiB/s
mtd_speedtest: testing page read speed
  514   504 root     R     1164   0%  16% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  13% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  17% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  16% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  18% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  19% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  16% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: page read speed is 9340 KiB/s
mtd_speedtest: testing 2 page write speed
  514   504 root     R     1164   0%  20% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  10% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  14% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  16% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  15% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  12% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  16% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  18% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  15% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  16% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  17% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  13% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: 2 page write speed is 5043 KiB/s
mtd_speedtest: testing 2 page read speed
  514   504 root     R     1164   0%   8% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%   9% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  14% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  12% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  12% insmod /root/mtd_test/mtd_speedtest.ko
  514   504 root     R     1164   0%  15% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: 2 page read speed is 9426 KiB/s
mtd_speedtest: Testing erase speed
  514   504 root     R     1164   0%  12% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: erase speed is 157943 KiB/s
mtd_speedtest: Testing 2x multi-block erase speed
mtd_speedtest: 2x multi-block erase speed is 308743 KiB/s
mtd_speedtest: Testing 4x multi-block erase speed
mtd_speedtest: 4x multi-block erase speed is 313469 KiB/s
mtd_speedtest: Testing 8x multi-block erase speed
mtd_speedtest: 8x multi-block erase speed is 313469 KiB/s
mtd_speedtest: Testing 16x multi-block erase speed
mtd_speedtest: 16x multi-block erase speed is 315076 KiB/s
mtd_speedtest: Testing 32x multi-block erase speed
  514   504 root     R     1164   0%  12% insmod /root/mtd_test/mtd_speedtest.ko
mtd_speedtest: 32x multi-block erase speed is 298252 KiB/s
mtd_speedtest: Testing 64x multi-block erase speed
mtd_speedtest: 64x multi-block erase speed is 311878 KiB/s
mtd_speedtest: finished
=================================================

-- 
1.7.9.5



From broonie at kernel.org  Wed Jul  3 05:52:57 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 3 Jul 2013 10:52:57 +0100
Subject: [v2 0/5] ASoC: atmel-pcm: align with generic dmaengine framwork
In-Reply-To: <1372840680-2253-1-git-send-email-voice.shen@atmel.com>
References: <1372840680-2253-1-git-send-email-voice.shen@atmel.com>
Message-ID: <20130703095257.GF27646@sirena.org.uk>

On Wed, Jul 03, 2013 at 04:37:55PM +0800, Bo Shen wrote:
> This patch set is based on linux next-20130701
> 
> mainly implement
>   - move set dma data from hw_params to startup callback to avoid memory leak
>   - align atmel pcm with generic dmaenigne framwork

Applied all, thanks.
-------------- 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/20130703/ddf15300/attachment.sig>

From josh.wu at atmel.com  Wed Jul  3 05:50:29 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Wed, 3 Jul 2013 17:50:29 +0800
Subject: [PATCH 1/6] MTD: atmel_nand: use devm_xxx gpio kzalloc,
 gpio and ioremap
In-Reply-To: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>
References: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1372845034-5579-2-git-send-email-josh.wu@atmel.com>

From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

this will allow to simply the error and remove path

Cc: linux-mtd at lists.infradead.org
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
[josh.wu at atmel.com: fix checkpatch warnings and rebase to latest mtd git tree]
[josh.wu at atmel.com: replace devm_request_and_ioremap with devm_ioremap_resource]
Signed-off-by: Josh Wu <josh.wu at atmel.com>
---
v3 --> v4:
  use devm_ioremap_resource instead of devm_request_and_ioremap.

 drivers/mtd/nand/atmel_nand.c |  182 +++++++++++++++--------------------------
 1 file changed, 66 insertions(+), 116 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 7e50ed8..e3cc418 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -359,43 +359,34 @@ static void __iomem *pmecc_get_alpha_to(struct atmel_nand_host *host)
 			table_size * sizeof(int16_t);
 }
 
-static void pmecc_data_free(struct atmel_nand_host *host)
-{
-	kfree(host->pmecc_partial_syn);
-	kfree(host->pmecc_si);
-	kfree(host->pmecc_lmu);
-	kfree(host->pmecc_smu);
-	kfree(host->pmecc_mu);
-	kfree(host->pmecc_dmu);
-	kfree(host->pmecc_delta);
-}
-
 static int pmecc_data_alloc(struct atmel_nand_host *host)
 {
 	const int cap = host->pmecc_corr_cap;
+	int size;
+
+	size = (2 * cap + 1) * sizeof(int16_t);
+	host->pmecc_partial_syn = devm_kzalloc(host->dev, size, GFP_KERNEL);
+	host->pmecc_si = devm_kzalloc(host->dev, size, GFP_KERNEL);
+	host->pmecc_lmu = devm_kzalloc(host->dev,
+			(cap + 1) * sizeof(int16_t), GFP_KERNEL);
+	host->pmecc_smu = devm_kzalloc(host->dev,
+			(cap + 2) * size, GFP_KERNEL);
+
+	size = (cap + 1) * sizeof(int);
+	host->pmecc_mu = devm_kzalloc(host->dev, size, GFP_KERNEL);
+	host->pmecc_dmu = devm_kzalloc(host->dev, size, GFP_KERNEL);
+	host->pmecc_delta = devm_kzalloc(host->dev, size, GFP_KERNEL);
+
+	if (!host->pmecc_partial_syn ||
+		!host->pmecc_si ||
+		!host->pmecc_lmu ||
+		!host->pmecc_smu ||
+		!host->pmecc_mu ||
+		!host->pmecc_dmu ||
+		!host->pmecc_delta)
+		return -ENOMEM;
 
-	host->pmecc_partial_syn = kzalloc((2 * cap + 1) * sizeof(int16_t),
-					GFP_KERNEL);
-	host->pmecc_si = kzalloc((2 * cap + 1) * sizeof(int16_t), GFP_KERNEL);
-	host->pmecc_lmu = kzalloc((cap + 1) * sizeof(int16_t), GFP_KERNEL);
-	host->pmecc_smu = kzalloc((cap + 2) * (2 * cap + 1) * sizeof(int16_t),
-					GFP_KERNEL);
-	host->pmecc_mu = kzalloc((cap + 1) * sizeof(int), GFP_KERNEL);
-	host->pmecc_dmu = kzalloc((cap + 1) * sizeof(int), GFP_KERNEL);
-	host->pmecc_delta = kzalloc((cap + 1) * sizeof(int), GFP_KERNEL);
-
-	if (host->pmecc_partial_syn &&
-			host->pmecc_si &&
-			host->pmecc_lmu &&
-			host->pmecc_smu &&
-			host->pmecc_mu &&
-			host->pmecc_dmu &&
-			host->pmecc_delta)
-		return 0;
-
-	/* error happened */
-	pmecc_data_free(host);
-	return -ENOMEM;
+	return 0;
 }
 
 static void pmecc_gen_syndrome(struct mtd_info *mtd, int sector)
@@ -1016,27 +1007,28 @@ static int __init atmel_pmecc_nand_init_params(struct platform_device *pdev,
 		return 0;
 	}
 
-	host->ecc = ioremap(regs->start, resource_size(regs));
-	if (host->ecc == NULL) {
+	host->ecc = devm_ioremap_resource(&pdev->dev, regs);
+	if (IS_ERR(host->ecc)) {
 		dev_err(host->dev, "ioremap failed\n");
-		err_no = -EIO;
-		goto err_pmecc_ioremap;
+		err_no = PTR_ERR(host->ecc);
+		goto err;
 	}
 
 	regs_pmerr = platform_get_resource(pdev, IORESOURCE_MEM, 2);
-	regs_rom = platform_get_resource(pdev, IORESOURCE_MEM, 3);
-	if (regs_pmerr && regs_rom) {
-		host->pmerrloc_base = ioremap(regs_pmerr->start,
-			resource_size(regs_pmerr));
-		host->pmecc_rom_base = ioremap(regs_rom->start,
-			resource_size(regs_rom));
+	host->pmerrloc_base = devm_ioremap_resource(&pdev->dev, regs_pmerr);
+	if (IS_ERR(host->pmerrloc_base)) {
+		dev_err(host->dev,
+			"Can not get I/O resource for PMECC ERRLOC controller!\n");
+		err_no = PTR_ERR(host->pmerrloc_base);
+		goto err;
 	}
 
-	if (!host->pmerrloc_base || !host->pmecc_rom_base) {
-		dev_err(host->dev,
-			"Can not get I/O resource for PMECC ERRLOC controller or ROM!\n");
-		err_no = -EIO;
-		goto err_pmloc_ioremap;
+	regs_rom = platform_get_resource(pdev, IORESOURCE_MEM, 3);
+	host->pmecc_rom_base = devm_ioremap_resource(&pdev->dev, regs_rom);
+	if (IS_ERR(host->pmecc_rom_base)) {
+		dev_err(host->dev, "Can not get I/O resource for ROM!\n");
+		err_no = PTR_ERR(host->pmecc_rom_base);
+		goto err;
 	}
 
 	/* ECC is calculated for the whole page (1 step) */
@@ -1061,7 +1053,7 @@ static int __init atmel_pmecc_nand_init_params(struct platform_device *pdev,
 		if (nand_chip->ecc.bytes > mtd->oobsize - 2) {
 			dev_err(host->dev, "No room for ECC bytes\n");
 			err_no = -EINVAL;
-			goto err_no_ecc_room;
+			goto err;
 		}
 		pmecc_config_ecc_layout(&atmel_pmecc_oobinfo,
 					mtd->oobsize,
@@ -1086,7 +1078,7 @@ static int __init atmel_pmecc_nand_init_params(struct platform_device *pdev,
 	if (err_no) {
 		dev_err(host->dev,
 				"Cannot allocate memory for PMECC computation!\n");
-		goto err_pmecc_data_alloc;
+		goto err;
 	}
 
 	nand_chip->ecc.read_page = atmel_nand_pmecc_read_page;
@@ -1096,15 +1088,7 @@ static int __init atmel_pmecc_nand_init_params(struct platform_device *pdev,
 
 	return 0;
 
-err_pmecc_data_alloc:
-err_no_ecc_room:
-err_pmloc_ioremap:
-	iounmap(host->ecc);
-	if (host->pmerrloc_base)
-		iounmap(host->pmerrloc_base);
-	if (host->pmecc_rom_base)
-		iounmap(host->pmecc_rom_base);
-err_pmecc_ioremap:
+err:
 	return err_no;
 }
 
@@ -1408,10 +1392,10 @@ static int __init atmel_hw_nand_init_params(struct platform_device *pdev,
 		return 0;
 	}
 
-	host->ecc = ioremap(regs->start, resource_size(regs));
-	if (host->ecc == NULL) {
+	host->ecc = devm_ioremap_resource(&pdev->dev, regs);
+	if (IS_ERR(host->ecc)) {
 		dev_err(host->dev, "ioremap failed\n");
-		return -EIO;
+		return PTR_ERR(host->ecc);
 	}
 
 	/* ECC is calculated for the whole page (1 step) */
@@ -1466,27 +1450,21 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 	int res;
 	struct pinctrl *pinctrl;
 
-	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (!mem) {
-		printk(KERN_ERR "atmel_nand: can't get I/O resource mem\n");
-		return -ENXIO;
-	}
-
 	/* Allocate memory for the device structure (and zero it) */
-	host = kzalloc(sizeof(struct atmel_nand_host), GFP_KERNEL);
+	host = devm_kzalloc(&pdev->dev, sizeof(*host), GFP_KERNEL);
 	if (!host) {
 		printk(KERN_ERR "atmel_nand: failed to allocate device structure.\n");
 		return -ENOMEM;
 	}
 
-	host->io_phys = (dma_addr_t)mem->start;
-
-	host->io_base = ioremap(mem->start, resource_size(mem));
-	if (host->io_base == NULL) {
-		printk(KERN_ERR "atmel_nand: ioremap failed\n");
-		res = -EIO;
+	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	host->io_base = devm_ioremap_resource(&pdev->dev, mem);
+	if (IS_ERR(host->io_base)) {
+		dev_err(&pdev->dev, "atmel_nand: ioremap resource failed\n");
+		res = PTR_ERR(host->io_base);
 		goto err_nand_ioremap;
 	}
+	host->io_phys = (dma_addr_t)mem->start;
 
 	mtd = &host->mtd;
 	nand_chip = &host->nand_chip;
@@ -1494,7 +1472,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 	if (pdev->dev.of_node) {
 		res = atmel_of_init_port(host, pdev->dev.of_node);
 		if (res)
-			goto err_ecc_ioremap;
+			goto err_nand_ioremap;
 	} else {
 		memcpy(&host->board, pdev->dev.platform_data,
 		       sizeof(struct atmel_nand_data));
@@ -1513,16 +1491,17 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 	if (IS_ERR(pinctrl)) {
 		dev_err(host->dev, "Failed to request pinctrl\n");
 		res = PTR_ERR(pinctrl);
-		goto err_ecc_ioremap;
+		goto err_nand_ioremap;
 	}
 
 	if (gpio_is_valid(host->board.rdy_pin)) {
-		res = gpio_request(host->board.rdy_pin, "nand_rdy");
+		res = devm_gpio_request(&pdev->dev,
+				host->board.rdy_pin, "nand_rdy");
 		if (res < 0) {
 			dev_err(&pdev->dev,
 				"can't request rdy gpio %d\n",
 				host->board.rdy_pin);
-			goto err_ecc_ioremap;
+			goto err_nand_ioremap;
 		}
 
 		res = gpio_direction_input(host->board.rdy_pin);
@@ -1530,19 +1509,20 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev,
 				"can't request input direction rdy gpio %d\n",
 				host->board.rdy_pin);
-			goto err_ecc_ioremap;
+			goto err_nand_ioremap;
 		}
 
 		nand_chip->dev_ready = atmel_nand_device_ready;
 	}
 
 	if (gpio_is_valid(host->board.enable_pin)) {
-		res = gpio_request(host->board.enable_pin, "nand_enable");
+		res = devm_gpio_request(&pdev->dev,
+				host->board.enable_pin, "nand_enable");
 		if (res < 0) {
 			dev_err(&pdev->dev,
 				"can't request enable gpio %d\n",
 				host->board.enable_pin);
-			goto err_ecc_ioremap;
+			goto err_nand_ioremap;
 		}
 
 		res = gpio_direction_output(host->board.enable_pin, 1);
@@ -1550,7 +1530,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev,
 				"can't request output direction enable gpio %d\n",
 				host->board.enable_pin);
-			goto err_ecc_ioremap;
+			goto err_nand_ioremap;
 		}
 	}
 
@@ -1567,7 +1547,8 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 	atmel_nand_enable(host);
 
 	if (gpio_is_valid(host->board.det_pin)) {
-		res = gpio_request(host->board.det_pin, "nand_det");
+		res = devm_gpio_request(&pdev->dev,
+				host->board.det_pin, "nand_det");
 		if (res < 0) {
 			dev_err(&pdev->dev,
 				"can't request det gpio %d\n",
@@ -1645,26 +1626,15 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 		return res;
 
 err_scan_tail:
-	if (host->has_pmecc && host->nand_chip.ecc.mode == NAND_ECC_HW) {
+	if (host->has_pmecc && host->nand_chip.ecc.mode == NAND_ECC_HW)
 		pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DISABLE);
-		pmecc_data_free(host);
-	}
-	if (host->ecc)
-		iounmap(host->ecc);
-	if (host->pmerrloc_base)
-		iounmap(host->pmerrloc_base);
-	if (host->pmecc_rom_base)
-		iounmap(host->pmecc_rom_base);
 err_hw_ecc:
 err_scan_ident:
 err_no_card:
 	atmel_nand_disable(host);
 	if (host->dma_chan)
 		dma_release_channel(host->dma_chan);
-err_ecc_ioremap:
-	iounmap(host->io_base);
 err_nand_ioremap:
-	kfree(host);
 	return res;
 }
 
@@ -1684,31 +1654,11 @@ static int __exit atmel_nand_remove(struct platform_device *pdev)
 		pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DISABLE);
 		pmerrloc_writel(host->pmerrloc_base, ELDIS,
 				PMERRLOC_DISABLE);
-		pmecc_data_free(host);
 	}
 
-	if (gpio_is_valid(host->board.det_pin))
-		gpio_free(host->board.det_pin);
-
-	if (gpio_is_valid(host->board.enable_pin))
-		gpio_free(host->board.enable_pin);
-
-	if (gpio_is_valid(host->board.rdy_pin))
-		gpio_free(host->board.rdy_pin);
-
-	if (host->ecc)
-		iounmap(host->ecc);
-	if (host->pmecc_rom_base)
-		iounmap(host->pmecc_rom_base);
-	if (host->pmerrloc_base)
-		iounmap(host->pmerrloc_base);
-
 	if (host->dma_chan)
 		dma_release_channel(host->dma_chan);
 
-	iounmap(host->io_base);
-	kfree(host);
-
 	return 0;
 }
 
-- 
1.7.9.5



From josh.wu at atmel.com  Wed Jul  3 05:50:30 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Wed, 3 Jul 2013 17:50:30 +0800
Subject: [PATCH 2/6] mtd: atmel_nand: replace pmecc enable code with one
 function.
In-Reply-To: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>
References: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1372845034-5579-3-git-send-email-josh.wu@atmel.com>

Signed-off-by: Josh Wu <josh.wu at atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
---
v4 --> v5:
  add blank line after variable declaration.

 drivers/mtd/nand/atmel_nand.c |   41 ++++++++++++++++++++++++++---------------
 1 file changed, 26 insertions(+), 15 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index e3cc418..5ce13f4 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -747,6 +747,30 @@ normal_check:
 	return total_err;
 }
 
+static void pmecc_enable(struct atmel_nand_host *host, int ecc_op)
+{
+	u32 val;
+
+	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_RST);
+	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DISABLE);
+	val = pmecc_readl_relaxed(host->ecc, CFG);
+
+	if (ecc_op != NAND_ECC_READ && ecc_op != NAND_ECC_WRITE) {
+		dev_err(host->dev, "atmel_nand: wrong pmecc operation type!");
+		return;
+	}
+
+	if (ecc_op == NAND_ECC_READ)
+		pmecc_writel(host->ecc, CFG, (val & ~PMECC_CFG_WRITE_OP)
+			| PMECC_CFG_AUTO_ENABLE);
+	else
+		pmecc_writel(host->ecc, CFG, (val | PMECC_CFG_WRITE_OP)
+			& ~PMECC_CFG_AUTO_ENABLE);
+
+	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_ENABLE);
+	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DATA);
+}
+
 static int atmel_nand_pmecc_read_page(struct mtd_info *mtd,
 	struct nand_chip *chip, uint8_t *buf, int oob_required, int page)
 {
@@ -758,13 +782,7 @@ static int atmel_nand_pmecc_read_page(struct mtd_info *mtd,
 	unsigned long end_time;
 	int bitflips = 0;
 
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_RST);
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DISABLE);
-	pmecc_writel(host->ecc, CFG, (pmecc_readl_relaxed(host->ecc, CFG)
-		& ~PMECC_CFG_WRITE_OP) | PMECC_CFG_AUTO_ENABLE);
-
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_ENABLE);
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DATA);
+	pmecc_enable(host, NAND_ECC_READ);
 
 	chip->read_buf(mtd, buf, eccsize);
 	chip->read_buf(mtd, oob, mtd->oobsize);
@@ -797,14 +815,7 @@ static int atmel_nand_pmecc_write_page(struct mtd_info *mtd,
 	int i, j;
 	unsigned long end_time;
 
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_RST);
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DISABLE);
-
-	pmecc_writel(host->ecc, CFG, (pmecc_readl_relaxed(host->ecc, CFG) |
-		PMECC_CFG_WRITE_OP) & ~PMECC_CFG_AUTO_ENABLE);
-
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_ENABLE);
-	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DATA);
+	pmecc_enable(host, NAND_ECC_WRITE);
 
 	chip->write_buf(mtd, (u8 *)buf, mtd->writesize);
 
-- 
1.7.9.5



From josh.wu at atmel.com  Wed Jul  3 05:50:31 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Wed, 3 Jul 2013 17:50:31 +0800
Subject: =?UTF-8?q?=5BPATCH=203/6=5D=20mtd=3A=20atmel=5Fnand=3A=20add=20Nand=20Flash=20Controller=20=28NFC=29=20support?=
In-Reply-To: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>
References: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1372845034-5579-4-git-send-email-josh.wu@atmel.com>

Nand Flash Controller (NFC) can handle automatic transfers, sending the
commands and address cycles to the NAND Flash.

To use NFC in this driver, user needs to add NFC child node in nand flash
driver. The NFC child node includes NFC's compatible string and regiters
of the address and size of NFC command registers, NFC registers (embedded
in HSMC) and NFC SRAM.
Also user need to set up the HSMC irq, which use to check whether nfc
command is finish or not.

This driver has been tested on SAMA5D3X-EK board with JFFS2, YAFFS,
UBIFS and mtd-utils.

I put the part of the mtd_speedtest result here for your information.
>From the mtd_speedtest, we can see the NFC will reduce the %50 of cpu load
when writing nand flash. No change when reading.
In the meantime, the speed will be slow about %8.

- commands use to test:
    #insmod /mnt/mtd_speedtest.ko dev=2 &
    #top -n 30 -d 1 | grep speedtest

- test result:

Before the patch:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: MTD device size 41943040, eraseblock size 131072, page size 2048, count of eraseblocks 320, pages per eraseblock 64, OOB size 64
  515   495 root     R     1164   0%  93% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  98% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  99% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock write speed is 5768 KiB/s
mtd_speedtest: testing eraseblock read speed
  515   495 root     R     1164   0%  92% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  91% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  94% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock read speed is 5932 KiB/s
mtd_speedtest: testing page write speed
  515   495 root     R     1164   0%  94% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  98% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  98% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page write speed is 5770 KiB/s
mtd_speedtest: testing page read speed
  515   495 root     R     1164   0%  91% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  89% insmod /mnt/mtd_speedtest.ko dev=2
  515   495 root     R     1164   0%  91% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page read speed is 5910 KiB/s

After the patch:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: MTD device size 41943040, eraseblock size 131072, page size 2048, count of eraseblocks 320, pages per eraseblock 64, OOB size 64
mtd_speedtest: testing eraseblock write speed
  509   495 root     D     1164   0%  49% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  50% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  47% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock write speed is 5370 KiB/s
mtd_speedtest: testing eraseblock read speed
  509   495 root     R     1164   0%  92% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%  91% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%  95% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock read speed is 5715 KiB/s
mtd_speedtest: testing page write speed
  509   495 root     D     1164   0%  48% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  47% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  50% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page write speed is 5224 KiB/s
mtd_speedtest: testing page read speed
  509   495 root     R     1164   0%  89% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%  94% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%  93% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page read speed is 5641 KiB/s

Signed-off-by: Josh Wu <josh.wu at atmel.com>
---
v4 --> v5:
  - remove blank line in EOF.

v3 --> v4:
  - remove printk and use dev_err.
  - use macro definition for the BIT_POS for bit shift instead of magical
    numbers.
  - add/remove blank line for coding style.

v2 --> v3:
  - Add a NFC child node of atmel nand to enable NFC.
  - So add a NFC driver which use to initialize the NFC reg resources.
  - remove unused NFC register definitions.
  - modify NFC register definition names.

 .../devicetree/bindings/mtd/atmel-nand.txt         |   26 ++
 drivers/mtd/nand/atmel_nand.c                      |  411 ++++++++++++++++++--
 drivers/mtd/nand/atmel_nand_nfc.h                  |   98 +++++
 3 files changed, 501 insertions(+), 33 deletions(-)
 create mode 100644 drivers/mtd/nand/atmel_nand_nfc.h

diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index b6eb484..5d8b7d5 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -30,6 +30,12 @@ Optional properties:
   sector size 1024.
 - nand-bus-width : 8 or 16 bus width if not present 8
 - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
+- Nand Flash Controller(NFC) is a slave driver under Atmel nand flash
+  - Required properties:
+    - compatible : "atmel,sama5d3-nfc".
+    - reg : should specify the address and size used for NFC command registers,
+            NFC registers and NFC Sram. NFC Sram address and size can be absent
+            if don't want to use it.
 
 Examples:
 nand0: nand at 40000000,0 {
@@ -78,3 +84,22 @@ nand0: nand at 40000000 {
 		...
 	};
 };
+
+/* for NFC supported chips */
+nand0: nand at 40000000 {
+	compatible = "atmel,at91rm9200-nand";
+	#address-cells = <1>;
+	#size-cells = <1>;
+	ranges;
+        ...
+        nfc at 70000000 {
+		compatible = "atmel,sama5d3-nfc";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <
+			0x70000000 0x10000000	/* NFC Command Registers */
+			0xffffc000 0x00000070	/* NFC HSMC regs */
+			0x00200000 0x00100000	/* NFC SRAM banks */
+		>;
+	};
+};
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 5ce13f4..9dcb519 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -18,6 +18,9 @@
  *  Add Programmable Multibit ECC support for various AT91 SoC
  *     ? Copyright 2012 ATMEL, Hong Xu
  *
+ *  Add Nand Flash Controller support for SAMA5 SoC
+ *     ? Copyright 2013 ATMEL, Josh Wu (josh.wu at atmel.com)
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
@@ -37,9 +40,11 @@
 #include <linux/mtd/nand.h>
 #include <linux/mtd/partitions.h>
 
+#include <linux/delay.h>
 #include <linux/dmaengine.h>
 #include <linux/gpio.h>
 #include <linux/io.h>
+#include <linux/interrupt.h>
 #include <linux/platform_data/atmel.h>
 #include <linux/pinctrl/consumer.h>
 
@@ -56,6 +61,7 @@ module_param(on_flash_bbt, int, 0);
 	__raw_writel((value), add + ATMEL_ECC_##reg)
 
 #include "atmel_nand_ecc.h"	/* Hardware ECC registers */
+#include "atmel_nand_nfc.h"	/* Nand Flash Controller definition */
 
 /* oob layout for large page size
  * bad block info is on bytes 0 and 1
@@ -83,6 +89,17 @@ static struct nand_ecclayout atmel_oobinfo_small = {
 	},
 };
 
+struct atmel_nfc {
+	void __iomem		*base_cmd_regs;
+	void __iomem		*hsmc_regs;
+	void __iomem		*sram_bank0;
+	dma_addr_t		sram_bank0_phys;
+
+	bool			is_initialized;
+	struct completion	comp_nfc;
+};
+static struct atmel_nfc	nand_nfc;
+
 struct atmel_nand_host {
 	struct nand_chip	nand_chip;
 	struct mtd_info		mtd;
@@ -95,6 +112,8 @@ struct atmel_nand_host {
 	struct completion	comp;
 	struct dma_chan		*dma_chan;
 
+	struct atmel_nfc	*nfc;
+
 	bool			has_pmecc;
 	u8			pmecc_corr_cap;
 	u16			pmecc_sector_size;
@@ -179,6 +198,56 @@ static int atmel_nand_device_ready(struct mtd_info *mtd)
                 !!host->board.rdy_pin_active_low;
 }
 
+/* Set up for hardware ready pin and enable pin. */
+static int atmel_nand_set_enable_ready_pins(struct mtd_info *mtd)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct atmel_nand_host *host = chip->priv;
+	int res = 0;
+
+	if (gpio_is_valid(host->board.rdy_pin)) {
+		res = devm_gpio_request(host->dev,
+				host->board.rdy_pin, "nand_rdy");
+		if (res < 0) {
+			dev_err(host->dev,
+				"can't request rdy gpio %d\n",
+				host->board.rdy_pin);
+			return res;
+		}
+
+		res = gpio_direction_input(host->board.rdy_pin);
+		if (res < 0) {
+			dev_err(host->dev,
+				"can't request input direction rdy gpio %d\n",
+				host->board.rdy_pin);
+			return res;
+		}
+
+		chip->dev_ready = atmel_nand_device_ready;
+	}
+
+	if (gpio_is_valid(host->board.enable_pin)) {
+		res = devm_gpio_request(host->dev,
+				host->board.enable_pin, "nand_enable");
+		if (res < 0) {
+			dev_err(host->dev,
+				"can't request enable gpio %d\n",
+				host->board.enable_pin);
+			return res;
+		}
+
+		res = gpio_direction_output(host->board.enable_pin, 1);
+		if (res < 0) {
+			dev_err(host->dev,
+				"can't request output direction enable gpio %d\n",
+				host->board.enable_pin);
+			return res;
+		}
+	}
+
+	return res;
+}
+
 /*
  * Minimal-overhead PIO for data access.
  */
@@ -1337,6 +1406,9 @@ static int atmel_of_init_port(struct atmel_nand_host *host,
 
 	host->has_pmecc = of_property_read_bool(np, "atmel,has-pmecc");
 
+	/* load the nfc driver if there is */
+	of_platform_populate(np, NULL, NULL, host->dev);
+
 	if (!(board->ecc_mode == NAND_ECC_HW) || !host->has_pmecc)
 		return 0;	/* Not using PMECC */
 
@@ -1448,6 +1520,239 @@ static int __init atmel_hw_nand_init_params(struct platform_device *pdev,
 	return 0;
 }
 
+/* SMC interrupt service routine */
+static irqreturn_t hsmc_interrupt(int irq, void *dev_id)
+{
+	struct atmel_nand_host *host = dev_id;
+	u32 status, mask, pending;
+	irqreturn_t ret = IRQ_HANDLED;
+
+	status = nfc_readl(host->nfc->hsmc_regs, SR);
+	mask = nfc_readl(host->nfc->hsmc_regs, IMR);
+	pending = status & mask;
+
+	if (pending & NFC_SR_XFR_DONE) {
+		complete(&host->nfc->comp_nfc);
+		nfc_writel(host->nfc->hsmc_regs, IDR, NFC_SR_XFR_DONE);
+	} else if (pending & NFC_SR_RB_EDGE) {
+		complete(&host->nfc->comp_nfc);
+		nfc_writel(host->nfc->hsmc_regs, IDR, NFC_SR_RB_EDGE);
+	} else if (pending & NFC_SR_CMD_DONE) {
+		complete(&host->nfc->comp_nfc);
+		nfc_writel(host->nfc->hsmc_regs, IDR, NFC_SR_CMD_DONE);
+	} else {
+		ret = IRQ_NONE;
+	}
+
+	return ret;
+}
+
+/* NFC(Nand Flash Controller) related functions */
+static int nfc_wait_interrupt(struct atmel_nand_host *host, u32 flag)
+{
+	unsigned long timeout;
+	init_completion(&host->nfc->comp_nfc);
+
+	/* Enable interrupt that need to wait for */
+	nfc_writel(host->nfc->hsmc_regs, IER, flag);
+
+	timeout = wait_for_completion_timeout(&host->nfc->comp_nfc,
+			msecs_to_jiffies(NFC_TIME_OUT_MS));
+	if (timeout)
+		return 0;
+
+	/* Time out to wait for the interrupt */
+	dev_err(host->dev, "Time out to wait for interrupt: 0x%08x\n", flag);
+	return -ETIMEDOUT;
+}
+
+static int nfc_send_command(struct atmel_nand_host *host,
+	unsigned int cmd, unsigned int addr, unsigned char cycle0)
+{
+	unsigned long timeout;
+	dev_dbg(host->dev,
+		"nfc_cmd: 0x%08x, addr1234: 0x%08x, cycle0: 0x%02x\n",
+		cmd, addr, cycle0);
+
+	timeout = jiffies + msecs_to_jiffies(NFC_TIME_OUT_MS);
+	while (nfc_cmd_readl(NFCADDR_CMD_NFCBUSY, host->nfc->base_cmd_regs)
+			& NFCADDR_CMD_NFCBUSY) {
+		if (time_after(jiffies, timeout)) {
+			dev_err(host->dev,
+				"Time out to wait CMD_NFCBUSY ready!\n");
+			return -ETIMEDOUT;
+		}
+	}
+	nfc_writel(host->nfc->hsmc_regs, CYCLE0, cycle0);
+	nfc_cmd_addr1234_writel(cmd, addr, host->nfc->base_cmd_regs);
+	return nfc_wait_interrupt(host, NFC_SR_CMD_DONE);
+}
+
+static int nfc_device_ready(struct mtd_info *mtd)
+{
+	struct nand_chip *nand_chip = mtd->priv;
+	struct atmel_nand_host *host = nand_chip->priv;
+	if (!nfc_wait_interrupt(host, NFC_SR_RB_EDGE))
+		return 1;
+	return 0;
+}
+
+static void nfc_select_chip(struct mtd_info *mtd, int chip)
+{
+	struct nand_chip *nand_chip = mtd->priv;
+	struct atmel_nand_host *host = nand_chip->priv;
+
+	if (chip == -1)
+		nfc_writel(host->nfc->hsmc_regs, CTRL, NFC_CTRL_DISABLE);
+	else
+		nfc_writel(host->nfc->hsmc_regs, CTRL, NFC_CTRL_ENABLE);
+}
+
+static int nfc_make_addr(struct mtd_info *mtd, int column, int page_addr,
+		unsigned int *addr1234, unsigned int *cycle0)
+{
+	struct nand_chip *chip = mtd->priv;
+
+	int acycle = 0;
+	unsigned char addr_bytes[8];
+	int index = 0, bit_shift;
+
+	BUG_ON(addr1234 == NULL || cycle0 == NULL);
+
+	*cycle0 = 0;
+	*addr1234 = 0;
+
+	if (column != -1) {
+		if (chip->options & NAND_BUSWIDTH_16)
+			column >>= 1;
+		addr_bytes[acycle++] = column & 0xff;
+		if (mtd->writesize > 512)
+			addr_bytes[acycle++] = (column >> 8) & 0xff;
+	}
+
+	if (page_addr != -1) {
+		addr_bytes[acycle++] = page_addr & 0xff;
+		addr_bytes[acycle++] = (page_addr >> 8) & 0xff;
+		if (chip->chipsize > (128 << 20))
+			addr_bytes[acycle++] = (page_addr >> 16) & 0xff;
+	}
+
+	if (acycle > 4)
+		*cycle0 = addr_bytes[index++];
+
+	for (bit_shift = 0; index < acycle; bit_shift += 8)
+		*addr1234 += addr_bytes[index++] << bit_shift;
+
+	/* return acycle in cmd register */
+	return acycle << NFCADDR_CMD_ACYCLE_BIT_POS;
+}
+
+static void nfc_nand_command(struct mtd_info *mtd, unsigned int command,
+				int column, int page_addr)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct atmel_nand_host *host = chip->priv;
+	unsigned long timeout;
+	unsigned int nfc_addr_cmd = 0;
+
+	unsigned int cmd1 = command << NFCADDR_CMD_CMD1_BIT_POS;
+
+	/* Set default settings: no cmd2, no addr cycle. read from nand */
+	unsigned int cmd2 = 0;
+	unsigned int vcmd2 = 0;
+	int acycle = NFCADDR_CMD_ACYCLE_NONE;
+	int csid = NFCADDR_CMD_CSID_3;
+	int dataen = NFCADDR_CMD_DATADIS;
+	int nfcwr = NFCADDR_CMD_NFCRD;
+	unsigned int addr1234 = 0;
+	unsigned int cycle0 = 0;
+	bool do_addr = true;
+
+	dev_dbg(host->dev, "%s: cmd = 0x%02x, col = 0x%08x, page = 0x%08x\n",
+	     __func__, command, column, page_addr);
+
+	switch (command) {
+	case NAND_CMD_RESET:
+		nfc_addr_cmd = cmd1 | acycle | csid | dataen | nfcwr;
+		nfc_send_command(host, nfc_addr_cmd, addr1234, cycle0);
+		udelay(chip->chip_delay);
+
+		nfc_nand_command(mtd, NAND_CMD_STATUS, -1, -1);
+		timeout = jiffies + msecs_to_jiffies(NFC_TIME_OUT_MS);
+		while (!(chip->read_byte(mtd) & NAND_STATUS_READY)) {
+			if (time_after(jiffies, timeout)) {
+				dev_err(host->dev,
+					"Time out to wait status ready!\n");
+				break;
+			}
+		}
+		return;
+	case NAND_CMD_STATUS:
+		do_addr = false;
+		break;
+	case NAND_CMD_PARAM:
+	case NAND_CMD_READID:
+		do_addr = false;
+		acycle = NFCADDR_CMD_ACYCLE_1;
+		if (column != -1)
+			addr1234 = column;
+		break;
+	case NAND_CMD_RNDOUT:
+		cmd2 = NAND_CMD_RNDOUTSTART << NFCADDR_CMD_CMD2_BIT_POS;
+		vcmd2 = NFCADDR_CMD_VCMD2;
+		break;
+	case NAND_CMD_READ0:
+	case NAND_CMD_READOOB:
+		if (command == NAND_CMD_READOOB) {
+			column += mtd->writesize;
+			command = NAND_CMD_READ0; /* only READ0 is valid */
+			cmd1 = command << NFCADDR_CMD_CMD1_BIT_POS;
+		}
+
+		cmd2 = NAND_CMD_READSTART << NFCADDR_CMD_CMD2_BIT_POS;
+		vcmd2 = NFCADDR_CMD_VCMD2;
+		break;
+	/* For prgramming command, the cmd need set to write enable */
+	case NAND_CMD_PAGEPROG:
+	case NAND_CMD_SEQIN:
+	case NAND_CMD_RNDIN:
+		nfcwr = NFCADDR_CMD_NFCWR;
+		break;
+	default:
+		break;
+	}
+
+	if (do_addr)
+		acycle = nfc_make_addr(mtd, column, page_addr, &addr1234,
+				&cycle0);
+
+	nfc_addr_cmd = cmd1 | cmd2 | vcmd2 | acycle | csid | dataen | nfcwr;
+	nfc_send_command(host, nfc_addr_cmd, addr1234, cycle0);
+
+	/*
+	 * Program and erase have their own busy handlers status, sequential
+	 * in, and deplete1 need no delay.
+	 */
+	switch (command) {
+	case NAND_CMD_CACHEDPROG:
+	case NAND_CMD_PAGEPROG:
+	case NAND_CMD_ERASE1:
+	case NAND_CMD_ERASE2:
+	case NAND_CMD_RNDIN:
+	case NAND_CMD_STATUS:
+	case NAND_CMD_RNDOUT:
+	case NAND_CMD_SEQIN:
+	case NAND_CMD_READID:
+		return;
+
+	case NAND_CMD_READ0:
+		/* fall through */
+	default:
+		nfc_wait_interrupt(host, NFC_SR_RB_EDGE);
+	}
+}
+
+static struct platform_driver atmel_nand_nfc_driver;
 /*
  * Probe for the NAND device.
  */
@@ -1458,7 +1763,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 	struct nand_chip *nand_chip;
 	struct resource *mem;
 	struct mtd_part_parser_data ppdata = {};
-	int res;
+	int res, irq;
 	struct pinctrl *pinctrl;
 
 	/* Allocate memory for the device structure (and zero it) */
@@ -1468,6 +1773,10 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
+	res = platform_driver_register(&atmel_nand_nfc_driver);
+	if (res)
+		dev_err(&pdev->dev, "atmel_nand: can't register NFC driver\n");
+
 	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	host->io_base = devm_ioremap_resource(&pdev->dev, mem);
 	if (IS_ERR(host->io_base)) {
@@ -1496,7 +1805,6 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 	/* Set address of NAND IO lines */
 	nand_chip->IO_ADDR_R = host->io_base;
 	nand_chip->IO_ADDR_W = host->io_base;
-	nand_chip->cmd_ctrl = atmel_nand_cmd_ctrl;
 
 	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
 	if (IS_ERR(pinctrl)) {
@@ -1505,44 +1813,34 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 		goto err_nand_ioremap;
 	}
 
-	if (gpio_is_valid(host->board.rdy_pin)) {
-		res = devm_gpio_request(&pdev->dev,
-				host->board.rdy_pin, "nand_rdy");
-		if (res < 0) {
-			dev_err(&pdev->dev,
-				"can't request rdy gpio %d\n",
-				host->board.rdy_pin);
-			goto err_nand_ioremap;
-		}
-
-		res = gpio_direction_input(host->board.rdy_pin);
-		if (res < 0) {
-			dev_err(&pdev->dev,
-				"can't request input direction rdy gpio %d\n",
-				host->board.rdy_pin);
-			goto err_nand_ioremap;
-		}
+	if (nand_nfc.is_initialized) {
+		/* NFC driver is probed and initialized */
+		host->nfc = &nand_nfc;
 
-		nand_chip->dev_ready = atmel_nand_device_ready;
-	}
+		nand_chip->select_chip = nfc_select_chip;
+		nand_chip->dev_ready = nfc_device_ready;
+		nand_chip->cmdfunc = nfc_nand_command;
 
-	if (gpio_is_valid(host->board.enable_pin)) {
-		res = devm_gpio_request(&pdev->dev,
-				host->board.enable_pin, "nand_enable");
-		if (res < 0) {
-			dev_err(&pdev->dev,
-				"can't request enable gpio %d\n",
-				host->board.enable_pin);
+		/* Initialize the interrupt for NFC */
+		irq = platform_get_irq(pdev, 0);
+		if (irq < 0) {
+			dev_err(host->dev, "Cannot get HSMC irq!\n");
 			goto err_nand_ioremap;
 		}
 
-		res = gpio_direction_output(host->board.enable_pin, 1);
-		if (res < 0) {
-			dev_err(&pdev->dev,
-				"can't request output direction enable gpio %d\n",
-				host->board.enable_pin);
+		res = devm_request_irq(&pdev->dev, irq, hsmc_interrupt,
+				0, "hsmc", host);
+		if (res) {
+			dev_err(&pdev->dev, "Unable to request HSMC irq %d\n",
+				irq);
 			goto err_nand_ioremap;
 		}
+	} else {
+		res = atmel_nand_set_enable_ready_pins(mtd);
+		if (res)
+			goto err_nand_ioremap;
+
+		nand_chip->cmd_ctrl = atmel_nand_cmd_ctrl;
 	}
 
 	nand_chip->ecc.mode = host->board.ecc_mode;
@@ -1646,6 +1944,7 @@ err_no_card:
 	if (host->dma_chan)
 		dma_release_channel(host->dma_chan);
 err_nand_ioremap:
+	platform_driver_unregister(&atmel_nand_nfc_driver);
 	return res;
 }
 
@@ -1670,6 +1969,8 @@ static int __exit atmel_nand_remove(struct platform_device *pdev)
 	if (host->dma_chan)
 		dma_release_channel(host->dma_chan);
 
+	platform_driver_unregister(&atmel_nand_nfc_driver);
+
 	return 0;
 }
 
@@ -1682,6 +1983,50 @@ static const struct of_device_id atmel_nand_dt_ids[] = {
 MODULE_DEVICE_TABLE(of, atmel_nand_dt_ids);
 #endif
 
+static int atmel_nand_nfc_probe(struct platform_device *pdev)
+{
+	struct atmel_nfc *nfc = &nand_nfc;
+	struct resource *nfc_cmd_regs, *nfc_hsmc_regs, *nfc_sram;
+
+	nfc_cmd_regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	nfc->base_cmd_regs = devm_ioremap_resource(&pdev->dev, nfc_cmd_regs);
+	if (IS_ERR(nfc->base_cmd_regs))
+		return PTR_ERR(nfc->base_cmd_regs);
+
+	nfc_hsmc_regs = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	nfc->hsmc_regs = devm_ioremap_resource(&pdev->dev, nfc_hsmc_regs);
+	if (IS_ERR(nfc->hsmc_regs))
+		return PTR_ERR(nfc->hsmc_regs);
+
+	nfc_sram = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+	if (nfc_sram) {
+		nfc->sram_bank0 = devm_ioremap_resource(&pdev->dev, nfc_sram);
+		if (IS_ERR(nfc->sram_bank0))
+			dev_warn(&pdev->dev, "Fail to ioremap the NFC sram with error: %ld. So disable NFC sram.\n",
+					PTR_ERR(nfc->sram_bank0));
+		else
+			nfc->sram_bank0_phys = (dma_addr_t)nfc_sram->start;
+	}
+
+	nfc->is_initialized = true;
+	dev_info(&pdev->dev, "NFC is probed.\n");
+	return 0;
+}
+
+static struct of_device_id atmel_nand_nfc_match[] = {
+	{ .compatible = "atmel,sama5d3-nfc" },
+	{ /* sentinel */ }
+};
+
+static struct platform_driver atmel_nand_nfc_driver = {
+	.driver = {
+		.name = "atmel_nand_nfc",
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(atmel_nand_nfc_match),
+	},
+	.probe = atmel_nand_nfc_probe,
+};
+
 static struct platform_driver atmel_nand_driver = {
 	.remove		= __exit_p(atmel_nand_remove),
 	.driver		= {
diff --git a/drivers/mtd/nand/atmel_nand_nfc.h b/drivers/mtd/nand/atmel_nand_nfc.h
new file mode 100644
index 0000000..4efd117
--- /dev/null
+++ b/drivers/mtd/nand/atmel_nand_nfc.h
@@ -0,0 +1,98 @@
+/*
+ * Atmel Nand Flash Controller (NFC) - System peripherals regsters.
+ * Based on SAMA5D3 datasheet.
+ *
+ * ? Copyright 2013 Atmel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifndef ATMEL_NAND_NFC_H
+#define ATMEL_NAND_NFC_H
+
+/*
+ * HSMC NFC registers
+ */
+#define ATMEL_HSMC_NFC_CFG	0x00		/* NFC Configuration Register */
+#define		NFC_CFG_PAGESIZE	(7 << 0)
+#define			NFC_CFG_PAGESIZE_512	(0 << 0)
+#define			NFC_CFG_PAGESIZE_1024	(1 << 0)
+#define			NFC_CFG_PAGESIZE_2048	(2 << 0)
+#define			NFC_CFG_PAGESIZE_4096	(3 << 0)
+#define			NFC_CFG_PAGESIZE_8192	(4 << 0)
+#define		NFC_CFG_WSPARE		(1 << 8)
+#define		NFC_CFG_RSPARE		(1 << 9)
+#define		NFC_CFG_NFC_DTOCYC	(0xf << 16)
+#define		NFC_CFG_NFC_DTOMUL	(0x7 << 20)
+#define		NFC_CFG_NFC_SPARESIZE	(0x7f << 24)
+#define		NFC_CFG_NFC_SPARESIZE_BIT_POS	24
+
+#define ATMEL_HSMC_NFC_CTRL	0x04		/* NFC Control Register */
+#define		NFC_CTRL_ENABLE		(1 << 0)
+#define		NFC_CTRL_DISABLE	(1 << 1)
+
+#define ATMEL_HSMC_NFC_SR	0x08		/* NFC Status Register */
+#define		NFC_SR_XFR_DONE		(1 << 16)
+#define		NFC_SR_CMD_DONE		(1 << 17)
+#define		NFC_SR_RB_EDGE		(1 << 24)
+
+#define ATMEL_HSMC_NFC_IER	0x0c
+#define ATMEL_HSMC_NFC_IDR	0x10
+#define ATMEL_HSMC_NFC_IMR	0x14
+#define ATMEL_HSMC_NFC_CYCLE0	0x18		/* NFC Address Cycle Zero */
+#define		ATMEL_HSMC_NFC_ADDR_CYCLE0	(0xff)
+
+#define ATMEL_HSMC_NFC_BANK	0x1c		/* NFC Bank Register */
+#define		ATMEL_HSMC_NFC_BANK0		(0 << 0)
+#define		ATMEL_HSMC_NFC_BANK1		(1 << 0)
+
+#define nfc_writel(addr, reg, value) \
+	writel((value), (addr) + ATMEL_HSMC_NFC_##reg)
+
+#define nfc_readl(addr, reg) \
+	readl_relaxed((addr) + ATMEL_HSMC_NFC_##reg)
+
+/*
+ * NFC Address Command definitions
+ */
+#define NFCADDR_CMD_CMD1	(0xff << 2)	/* Command for Cycle 1 */
+#define NFCADDR_CMD_CMD1_BIT_POS	2
+#define NFCADDR_CMD_CMD2	(0xff << 10)	/* Command for Cycle 2 */
+#define NFCADDR_CMD_CMD2_BIT_POS	10
+#define NFCADDR_CMD_VCMD2	(0x1 << 18)	/* Valid Cycle 2 Command */
+#define NFCADDR_CMD_ACYCLE	(0x7 << 19)	/* Number of Address required */
+#define		NFCADDR_CMD_ACYCLE_NONE		(0x0 << 19)
+#define		NFCADDR_CMD_ACYCLE_1		(0x1 << 19)
+#define		NFCADDR_CMD_ACYCLE_2		(0x2 << 19)
+#define		NFCADDR_CMD_ACYCLE_3		(0x3 << 19)
+#define		NFCADDR_CMD_ACYCLE_4		(0x4 << 19)
+#define		NFCADDR_CMD_ACYCLE_5		(0x5 << 19)
+#define NFCADDR_CMD_ACYCLE_BIT_POS	19
+#define NFCADDR_CMD_CSID	(0x7 << 22)	/* Chip Select Identifier */
+#define		NFCADDR_CMD_CSID_0		(0x0 << 22)
+#define		NFCADDR_CMD_CSID_1		(0x1 << 22)
+#define		NFCADDR_CMD_CSID_2		(0x2 << 22)
+#define		NFCADDR_CMD_CSID_3		(0x3 << 22)
+#define		NFCADDR_CMD_CSID_4		(0x4 << 22)
+#define		NFCADDR_CMD_CSID_5		(0x5 << 22)
+#define		NFCADDR_CMD_CSID_6		(0x6 << 22)
+#define		NFCADDR_CMD_CSID_7		(0x7 << 22)
+#define NFCADDR_CMD_DATAEN	(0x1 << 25)	/* Data Transfer Enable */
+#define NFCADDR_CMD_DATADIS	(0x0 << 25)	/* Data Transfer Disable */
+#define NFCADDR_CMD_NFCRD	(0x0 << 26)	/* NFC Read Enable */
+#define NFCADDR_CMD_NFCWR	(0x1 << 26)	/* NFC Write Enable */
+#define NFCADDR_CMD_NFCBUSY	(0x1 << 27)	/* NFC Busy */
+
+#define nfc_cmd_addr1234_writel(cmd, addr1234, nfc_base) \
+	writel((addr1234), (cmd) + nfc_base)
+
+#define nfc_cmd_readl(bitstatus, nfc_base) \
+	readl_relaxed((bitstatus) + nfc_base)
+
+#define NFC_TIME_OUT_MS		100
+#define	NFC_SRAM_BANK1_OFFSET	0x1200
+
+#endif
-- 
1.7.9.5



From josephl at nvidia.com  Wed Jul  3 05:55:48 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 3 Jul 2013 17:55:48 +0800
Subject: [PATCH] ARM: tegra114: Enable Cortex-A15 errata 798181
Message-ID: <1372845348-27089-1-git-send-email-josephl@nvidia.com>

The commit 93dc688 (ARM: 7684/1: errata: Workaround for Cortex-A15
erratum 798181 (TLBI/DSB operations)) introduecd a workaround for
Cortex-A15 errata 798181. Enabling it for Tegra114.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/mach-tegra/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index ef3a8da..add345e 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -59,6 +59,7 @@ config ARCH_TEGRA_3x_SOC
 config ARCH_TEGRA_114_SOC
 	bool "Enable support for Tegra114 family"
 	select HAVE_ARM_ARCH_TIMER
+	select ARM_ERRATA_798181
 	select ARM_GIC
 	select ARM_L1_CACHE_SHIFT_6
 	select CPU_V7
-- 
1.8.3.2



From josh.wu at atmel.com  Wed Jul  3 05:50:32 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Wed, 3 Jul 2013 17:50:32 +0800
Subject: [PATCH 4/6] mtd: atmel_nand: enable Nand Flash Controller (NFC) read
 data via sram
In-Reply-To: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>
References: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1372845034-5579-5-git-send-email-josh.wu@atmel.com>

NFC has embedded sram which can use to transfer data. This patch enable reading
nand flash via NFC SRAM. It will minimize the CPU overhead.

This driver has been tested on SAMA5D3X-EK with JFFS2, YAFFS2, UBIFS and
mtd-utils.

Here puts the part of mtd_speedtest (read test) result as following:
Compare with non-NFC mtd_speedtest result, reading will reduce %45 cpu load
with increase %80 speed.

- commands use to test:
  # insmod /mnt/mtd_speedtest.ko dev=2 &
  # top -n 30 -d 1 | grep speedtest

- test result:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: MTD device size 41943040, eraseblock size 131072, page size 2048, count of eraseblocks 320, pages per eraseblock 64, OOB size 64
mtd_speedtest: testing eraseblock read speed
  509   495 root     D     1164   0%  28% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  25% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  26% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock read speed is 9403 KiB/s
mtd_speedtest: testing page read speed
  509   495 root     R     1164   0%  31% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  57% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  53% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  71% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page read speed is 9258 KiB/s

Signed-off-by: Josh Wu <josh.wu at atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
---
v3 --> v4:
  - use BIT_POS definition not magical number.

v2 --> v3:
  - if NFC sram address and size is specified then enable NFC sram read.
    Otherwise disable NFC sram read.

 drivers/mtd/nand/atmel_nand.c |  163 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 157 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 9dcb519..7e14dbe 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -94,9 +94,13 @@ struct atmel_nfc {
 	void __iomem		*hsmc_regs;
 	void __iomem		*sram_bank0;
 	dma_addr_t		sram_bank0_phys;
+	bool			use_nfc_sram;
 
 	bool			is_initialized;
 	struct completion	comp_nfc;
+
+	/* Point to the sram bank which include readed data via NFC */
+	void __iomem		*data_in_sram;
 };
 static struct atmel_nfc	nand_nfc;
 
@@ -248,21 +252,43 @@ static int atmel_nand_set_enable_ready_pins(struct mtd_info *mtd)
 	return res;
 }
 
+static void memcpy32_fromio(void *trg, const void __iomem  *src, size_t size)
+{
+	int i;
+	u32 *t = trg;
+	const __iomem u32 *s = src;
+
+	for (i = 0; i < (size >> 2); i++)
+		*t++ = readl_relaxed(s++);
+}
+
 /*
  * Minimal-overhead PIO for data access.
  */
 static void atmel_read_buf8(struct mtd_info *mtd, u8 *buf, int len)
 {
 	struct nand_chip	*nand_chip = mtd->priv;
+	struct atmel_nand_host *host = nand_chip->priv;
 
-	__raw_readsb(nand_chip->IO_ADDR_R, buf, len);
+	if (host->nfc && host->nfc->use_nfc_sram && host->nfc->data_in_sram) {
+		memcpy32_fromio(buf, host->nfc->data_in_sram, len);
+		host->nfc->data_in_sram += len;
+	} else {
+		__raw_readsb(nand_chip->IO_ADDR_R, buf, len);
+	}
 }
 
 static void atmel_read_buf16(struct mtd_info *mtd, u8 *buf, int len)
 {
 	struct nand_chip	*nand_chip = mtd->priv;
+	struct atmel_nand_host *host = nand_chip->priv;
 
-	__raw_readsw(nand_chip->IO_ADDR_R, buf, len / 2);
+	if (host->nfc && host->nfc->use_nfc_sram && host->nfc->data_in_sram) {
+		memcpy32_fromio(buf, host->nfc->data_in_sram, len);
+		host->nfc->data_in_sram += len;
+	} else {
+		__raw_readsw(nand_chip->IO_ADDR_R, buf, len / 2);
+	}
 }
 
 static void atmel_write_buf8(struct mtd_info *mtd, const u8 *buf, int len)
@@ -284,6 +310,40 @@ static void dma_complete_func(void *completion)
 	complete(completion);
 }
 
+static int nfc_set_sram_bank(struct atmel_nand_host *host, unsigned int bank)
+{
+	/* NFC only has two banks. Must be 0 or 1 */
+	if (bank > 1)
+		return -EINVAL;
+
+	if (bank) {
+		/* Only for a 2k-page or lower flash, NFC can handle 2 banks */
+		if (host->mtd.writesize > 2048)
+			return -EINVAL;
+		nfc_writel(host->nfc->hsmc_regs, BANK, ATMEL_HSMC_NFC_BANK1);
+	} else {
+		nfc_writel(host->nfc->hsmc_regs, BANK, ATMEL_HSMC_NFC_BANK0);
+	}
+
+	return 0;
+}
+
+static uint nfc_get_sram_off(struct atmel_nand_host *host)
+{
+	if (nfc_readl(host->nfc->hsmc_regs, BANK) & ATMEL_HSMC_NFC_BANK1)
+		return NFC_SRAM_BANK1_OFFSET;
+	else
+		return 0;
+}
+
+static dma_addr_t nfc_sram_phys(struct atmel_nand_host *host)
+{
+	if (nfc_readl(host->nfc->hsmc_regs, BANK) & ATMEL_HSMC_NFC_BANK1)
+		return host->nfc->sram_bank0_phys + NFC_SRAM_BANK1_OFFSET;
+	else
+		return host->nfc->sram_bank0_phys;
+}
+
 static int atmel_nand_dma_op(struct mtd_info *mtd, void *buf, int len,
 			       int is_read)
 {
@@ -297,6 +357,7 @@ static int atmel_nand_dma_op(struct mtd_info *mtd, void *buf, int len,
 	void *p = buf;
 	int err = -EIO;
 	enum dma_data_direction dir = is_read ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+	struct atmel_nfc *nfc = host->nfc;
 
 	if (buf >= high_memory)
 		goto err_buf;
@@ -313,7 +374,12 @@ static int atmel_nand_dma_op(struct mtd_info *mtd, void *buf, int len,
 	}
 
 	if (is_read) {
-		dma_src_addr = host->io_phys;
+		if (nfc && nfc->data_in_sram)
+			dma_src_addr = nfc_sram_phys(host) + (nfc->data_in_sram
+				- (nfc->sram_bank0 + nfc_get_sram_off(host)));
+		else
+			dma_src_addr = host->io_phys;
+
 		dma_dst_addr = phys_addr;
 	} else {
 		dma_src_addr = phys_addr;
@@ -340,6 +406,10 @@ static int atmel_nand_dma_op(struct mtd_info *mtd, void *buf, int len,
 	dma_async_issue_pending(host->dma_chan);
 	wait_for_completion(&host->comp);
 
+	if (is_read && nfc && nfc->data_in_sram)
+		/* After read data from SRAM, need to increase the position */
+		nfc->data_in_sram += len;
+
 	err = 0;
 
 err_dma:
@@ -851,7 +921,8 @@ static int atmel_nand_pmecc_read_page(struct mtd_info *mtd,
 	unsigned long end_time;
 	int bitflips = 0;
 
-	pmecc_enable(host, NAND_ECC_READ);
+	if (!host->nfc || !host->nfc->use_nfc_sram)
+		pmecc_enable(host, NAND_ECC_READ);
 
 	chip->read_buf(mtd, buf, eccsize);
 	chip->read_buf(mtd, oob, mtd->oobsize);
@@ -1667,6 +1738,7 @@ static void nfc_nand_command(struct mtd_info *mtd, unsigned int command,
 	unsigned int addr1234 = 0;
 	unsigned int cycle0 = 0;
 	bool do_addr = true;
+	host->nfc->data_in_sram = NULL;
 
 	dev_dbg(host->dev, "%s: cmd = 0x%02x, col = 0x%08x, page = 0x%08x\n",
 	     __func__, command, column, page_addr);
@@ -1708,6 +1780,16 @@ static void nfc_nand_command(struct mtd_info *mtd, unsigned int command,
 			command = NAND_CMD_READ0; /* only READ0 is valid */
 			cmd1 = command << NFCADDR_CMD_CMD1_BIT_POS;
 		}
+		if (host->nfc->use_nfc_sram) {
+			/* Enable Data transfer to sram */
+			dataen = NFCADDR_CMD_DATAEN;
+
+			/* Need enable PMECC now, since NFC will transfer
+			 * data in bus after sending nfc read command.
+			 */
+			if (chip->ecc.mode == NAND_ECC_HW && host->has_pmecc)
+				pmecc_enable(host, NAND_ECC_READ);
+		}
 
 		cmd2 = NAND_CMD_READSTART << NFCADDR_CMD_CMD2_BIT_POS;
 		vcmd2 = NFCADDR_CMD_VCMD2;
@@ -1729,6 +1811,10 @@ static void nfc_nand_command(struct mtd_info *mtd, unsigned int command,
 	nfc_addr_cmd = cmd1 | cmd2 | vcmd2 | acycle | csid | dataen | nfcwr;
 	nfc_send_command(host, nfc_addr_cmd, addr1234, cycle0);
 
+	if (dataen == NFCADDR_CMD_DATAEN)
+		if (nfc_wait_interrupt(host, NFC_SR_XFR_DONE))
+			dev_err(host->dev, "something wrong, No XFR_DONE interrupt comes.\n");
+
 	/*
 	 * Program and erase have their own busy handlers status, sequential
 	 * in, and deplete1 need no delay.
@@ -1746,12 +1832,66 @@ static void nfc_nand_command(struct mtd_info *mtd, unsigned int command,
 		return;
 
 	case NAND_CMD_READ0:
+		if (dataen == NFCADDR_CMD_DATAEN) {
+			host->nfc->data_in_sram = host->nfc->sram_bank0 +
+				nfc_get_sram_off(host);
+			return;
+		}
 		/* fall through */
 	default:
 		nfc_wait_interrupt(host, NFC_SR_RB_EDGE);
 	}
 }
 
+static int nfc_sram_init(struct mtd_info *mtd)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct atmel_nand_host *host = chip->priv;
+	int res = 0;
+
+	/* Initialize the NFC CFG register */
+	unsigned int cfg_nfc = 0;
+
+	/* set page size and oob layout */
+	switch (mtd->writesize) {
+	case 512:
+		cfg_nfc = NFC_CFG_PAGESIZE_512;
+		break;
+	case 1024:
+		cfg_nfc = NFC_CFG_PAGESIZE_1024;
+		break;
+	case 2048:
+		cfg_nfc = NFC_CFG_PAGESIZE_2048;
+		break;
+	case 4096:
+		cfg_nfc = NFC_CFG_PAGESIZE_4096;
+		break;
+	case 8192:
+		cfg_nfc = NFC_CFG_PAGESIZE_8192;
+		break;
+	default:
+		dev_err(host->dev, "Unsupported page size for NFC.\n");
+		res = -ENXIO;
+		return res;
+	}
+
+	/* oob bytes size = (NFCSPARESIZE + 1) * 4
+	 * Max support spare size is 512 bytes. */
+	cfg_nfc |= (((mtd->oobsize / 4) - 1) << NFC_CFG_NFC_SPARESIZE_BIT_POS
+		& NFC_CFG_NFC_SPARESIZE);
+	/* default set a max timeout */
+	cfg_nfc |= NFC_CFG_RSPARE |
+			NFC_CFG_NFC_DTOCYC | NFC_CFG_NFC_DTOMUL;
+
+	nfc_writel(host->nfc->hsmc_regs, CFG, cfg_nfc);
+
+	nfc_set_sram_bank(host, 0);
+
+	dev_info(host->dev, "Using NFC Sram read\n");
+
+	return 0;
+}
+
 static struct platform_driver atmel_nand_nfc_driver;
 /*
  * Probe for the NAND device.
@@ -1921,6 +2061,15 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
 			goto err_hw_ecc;
 	}
 
+	/* initialize the nfc configuration register */
+	if (host->nfc && host->nfc->use_nfc_sram) {
+		res = nfc_sram_init(mtd);
+		if (res) {
+			host->nfc->use_nfc_sram = false;
+			dev_err(host->dev, "Disable use nfc sram for data transfer.\n");
+		}
+	}
+
 	/* second phase scan */
 	if (nand_scan_tail(mtd)) {
 		res = -ENXIO;
@@ -2001,11 +2150,13 @@ static int atmel_nand_nfc_probe(struct platform_device *pdev)
 	nfc_sram = platform_get_resource(pdev, IORESOURCE_MEM, 2);
 	if (nfc_sram) {
 		nfc->sram_bank0 = devm_ioremap_resource(&pdev->dev, nfc_sram);
-		if (IS_ERR(nfc->sram_bank0))
+		if (IS_ERR(nfc->sram_bank0)) {
 			dev_warn(&pdev->dev, "Fail to ioremap the NFC sram with error: %ld. So disable NFC sram.\n",
 					PTR_ERR(nfc->sram_bank0));
-		else
+		} else {
+			nfc->use_nfc_sram = true;
 			nfc->sram_bank0_phys = (dma_addr_t)nfc_sram->start;
+		}
 	}
 
 	nfc->is_initialized = true;
-- 
1.7.9.5



From josh.wu at atmel.com  Wed Jul  3 05:50:33 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Wed, 3 Jul 2013 17:50:33 +0800
Subject: [PATCH 5/6] mtd: atmel_nand: enable Nand Flash Controller (NFC) write
 via sram
In-Reply-To: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>
References: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1372845034-5579-6-git-send-email-josh.wu@atmel.com>

This patch enable writing nand flash via NFC SRAM. It will minimize the CPU
overhead. The SRAM write only support ECC_NONE and ECC_HW with PMECC.

To enable this NFC write by SRAM feature, you can add a string in dts under
NFC driver node.

This driver has been tested on SAMA5D3X-EK with JFFS2, YAFFS2, UBIFS and
mtd-utils.

Here is part of mtd_speedtest (writing test) result, compare with non-NFC
writing, it reduces %65 cpu load with loss %12 speed.

- commands use to test:
  # insmod /mnt/mtd_speedtest.ko dev=2 &
  # top -n 30 -d 1 | grep speedtest

- test result:
=================================================
mtd_speedtest: MTD device: 2
mtd_speedtest: MTD device size 41943040, eraseblock size 131072, page size 2048, count of eraseblocks 320, pages per eraseblock 64, OOB size 64
mtd_speedtest: testing eraseblock write speed
  509   495 root     D     1164   0%   7% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%   8% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     R     1164   0%   5% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: eraseblock write speed is 5194 KiB/s
mtd_speedtest: testing page write speed
  509   495 root     D     1164   0%  32% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  27% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  25% insmod /mnt/mtd_speedtest.ko dev=2
  509   495 root     D     1164   0%  30% insmod /mnt/mtd_speedtest.ko dev=2
mtd_speedtest: page write speed is 5024 KiB/s

Signed-off-by: Josh Wu <josh.wu at atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
---
v3 --> v4:
  - no blank line change.

v2 --> v3:
  - use a property of NFC node to enable/disable NFC write via sram.

 .../devicetree/bindings/mtd/atmel-nand.txt         |    2 +
 drivers/mtd/nand/atmel_nand.c                      |  106 +++++++++++++++++++-
 2 files changed, 103 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index 5d8b7d5..c472883 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -36,6 +36,8 @@ Optional properties:
     - reg : should specify the address and size used for NFC command registers,
             NFC registers and NFC Sram. NFC Sram address and size can be absent
             if don't want to use it.
+  - Optional properties:
+    - atmel,write-by-sram: boolean to enable NFC write by sram.
 
 Examples:
 nand0: nand at 40000000,0 {
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 7e14dbe..a784704 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -95,12 +95,14 @@ struct atmel_nfc {
 	void __iomem		*sram_bank0;
 	dma_addr_t		sram_bank0_phys;
 	bool			use_nfc_sram;
+	bool			write_by_sram;
 
 	bool			is_initialized;
 	struct completion	comp_nfc;
 
 	/* Point to the sram bank which include readed data via NFC */
 	void __iomem		*data_in_sram;
+	bool			will_write_sram;
 };
 static struct atmel_nfc	nand_nfc;
 
@@ -262,6 +264,16 @@ static void memcpy32_fromio(void *trg, const void __iomem  *src, size_t size)
 		*t++ = readl_relaxed(s++);
 }
 
+static void memcpy32_toio(void __iomem *trg, const void *src, int size)
+{
+	int i;
+	u32 __iomem *t = trg;
+	const u32 *s = src;
+
+	for (i = 0; i < (size >> 2); i++)
+		writel_relaxed(*s++, t++);
+}
+
 /*
  * Minimal-overhead PIO for data access.
  */
@@ -383,7 +395,11 @@ static int atmel_nand_dma_op(struct mtd_info *mtd, void *buf, int len,
 		dma_dst_addr = phys_addr;
 	} else {
 		dma_src_addr = phys_addr;
-		dma_dst_addr = host->io_phys;
+
+		if (nfc && nfc->write_by_sram)
+			dma_dst_addr = nfc_sram_phys(host);
+		else
+			dma_dst_addr = host->io_phys;
 	}
 
 	tx = dma_dev->device_prep_dma_memcpy(host->dma_chan, dma_dst_addr,
@@ -955,9 +971,10 @@ static int atmel_nand_pmecc_write_page(struct mtd_info *mtd,
 	int i, j;
 	unsigned long end_time;
 
-	pmecc_enable(host, NAND_ECC_WRITE);
-
-	chip->write_buf(mtd, (u8 *)buf, mtd->writesize);
+	if (!host->nfc || !host->nfc->write_by_sram) {
+		pmecc_enable(host, NAND_ECC_WRITE);
+		chip->write_buf(mtd, (u8 *)buf, mtd->writesize);
+	}
 
 	end_time = jiffies + msecs_to_jiffies(PMECC_MAX_TIMEOUT_MS);
 	while ((pmecc_readl_relaxed(host->ecc, SR) & PMECC_SR_BUSY)) {
@@ -1799,6 +1816,8 @@ static void nfc_nand_command(struct mtd_info *mtd, unsigned int command,
 	case NAND_CMD_SEQIN:
 	case NAND_CMD_RNDIN:
 		nfcwr = NFCADDR_CMD_NFCWR;
+		if (host->nfc->will_write_sram && command == NAND_CMD_SEQIN)
+			dataen = NFCADDR_CMD_DATAEN;
 		break;
 	default:
 		break;
@@ -1843,6 +1862,68 @@ static void nfc_nand_command(struct mtd_info *mtd, unsigned int command,
 	}
 }
 
+static int nfc_sram_write_page(struct mtd_info *mtd, struct nand_chip *chip,
+			uint32_t offset, int data_len, const uint8_t *buf,
+			int oob_required, int page, int cached, int raw)
+{
+	int cfg, len;
+	int status = 0;
+	struct atmel_nand_host *host = chip->priv;
+	void __iomem *sram = host->nfc->sram_bank0 + nfc_get_sram_off(host);
+
+	/* Subpage write is not supported */
+	if (offset || (data_len < mtd->writesize))
+		return -EINVAL;
+
+	cfg = nfc_readl(host->nfc->hsmc_regs, CFG);
+	len = mtd->writesize;
+
+	if (unlikely(raw)) {
+		len += mtd->oobsize;
+		nfc_writel(host->nfc->hsmc_regs, CFG, cfg | NFC_CFG_WSPARE);
+	} else
+		nfc_writel(host->nfc->hsmc_regs, CFG, cfg & ~NFC_CFG_WSPARE);
+
+	/* Copy page data to sram that will write to nand via NFC */
+	if (use_dma) {
+		if (atmel_nand_dma_op(mtd, (void *)buf, len, 0) != 0)
+			/* Fall back to use cpu copy */
+			memcpy32_toio(sram, buf, len);
+	} else {
+		memcpy32_toio(sram, buf, len);
+	}
+
+	if (chip->ecc.mode == NAND_ECC_HW && host->has_pmecc)
+		/*
+		 * When use NFC sram, need set up PMECC before send
+		 * NAND_CMD_SEQIN command. Since when the nand command
+		 * is sent, nfc will do transfer from sram and nand.
+		 */
+		pmecc_enable(host, NAND_ECC_WRITE);
+
+	host->nfc->will_write_sram = true;
+	chip->cmdfunc(mtd, NAND_CMD_SEQIN, 0x00, page);
+	host->nfc->will_write_sram = false;
+
+	if (likely(!raw))
+		/* Need to write ecc into oob */
+		status = chip->ecc.write_page(mtd, chip, buf, oob_required);
+
+	if (status < 0)
+		return status;
+
+	chip->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1);
+	status = chip->waitfunc(mtd, chip);
+
+	if ((status & NAND_STATUS_FAIL) && (chip->errstat))
+		status = chip->errstat(mtd, chip, FL_WRITING, status, page);
+
+	if (status & NAND_STATUS_FAIL)
+		return -EIO;
+
+	return 0;
+}
+
 static int nfc_sram_init(struct mtd_info *mtd)
 {
 	struct nand_chip *chip = mtd->priv;
@@ -1885,10 +1966,20 @@ static int nfc_sram_init(struct mtd_info *mtd)
 
 	nfc_writel(host->nfc->hsmc_regs, CFG, cfg_nfc);
 
+	host->nfc->will_write_sram = false;
 	nfc_set_sram_bank(host, 0);
 
-	dev_info(host->dev, "Using NFC Sram read\n");
+	/* Use Write page with NFC SRAM only for PMECC or ECC NONE. */
+	if (host->nfc->write_by_sram) {
+		if ((chip->ecc.mode == NAND_ECC_HW && host->has_pmecc) ||
+				chip->ecc.mode == NAND_ECC_NONE)
+			chip->write_page = nfc_sram_write_page;
+		else
+			host->nfc->write_by_sram = false;
+	}
 
+	dev_info(host->dev, "Using NFC Sram read %s\n",
+			host->nfc->write_by_sram ? "and write" : "");
 	return 0;
 }
 
@@ -2156,6 +2247,11 @@ static int atmel_nand_nfc_probe(struct platform_device *pdev)
 		} else {
 			nfc->use_nfc_sram = true;
 			nfc->sram_bank0_phys = (dma_addr_t)nfc_sram->start;
+
+			if (pdev->dev.of_node)
+				nfc->write_by_sram = of_property_read_bool(
+						pdev->dev.of_node,
+						"atmel,write-by-sram");
 		}
 	}
 
-- 
1.7.9.5



From josh.wu at atmel.com  Wed Jul  3 05:50:34 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Wed, 3 Jul 2013 17:50:34 +0800
Subject: [PATCH 6/6] mtd: ofpart: add compatible check for child nodes
In-Reply-To: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>
References: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1372845034-5579-7-git-send-email-josh.wu@atmel.com>

In case that the nand device will support some features like Nand Flash
Controller, we want to make the sub feature as a sub node of nand device.

Use such organization it is easy to enable/disable feature, also it is back
compatible and more readable.

If the sub-node has a compatible property then it is a driver not partition.

Signed-off-by: Josh Wu <josh.wu at atmel.com>
---
v3 --> v4:
  - remove the 'len' parameter, just use NULL.
  - refine the commit message.
  - also add a NOTE in devicetree/bindings/mtd/partition.txt.

 .../devicetree/bindings/mtd/partition.txt          |    1 +
 drivers/mtd/ofpart.c                               |   13 ++++++++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt
index 9315ac9..8e5557d 100644
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -4,6 +4,7 @@ Partitions can be represented by sub-nodes of an mtd device. This can be used
 on platforms which have strong conventions about which portions of a flash are
 used for what purposes, but which don't use an on-flash partition table such
 as RedBoot.
+NOTE: if the sub-node has a compatible string, then it is not a partition.
 
 #address-cells & #size-cells must both be present in the mtd device. There are
 two valid values for both:
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 553d6d6..30fcea1 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -20,6 +20,10 @@
 #include <linux/slab.h>
 #include <linux/mtd/partitions.h>
 
+static bool node_has_compatible(struct device_node *pp)
+{
+	return of_get_property(pp, "compatible", NULL);
+}
 static int parse_ofpart_partitions(struct mtd_info *master,
 				   struct mtd_partition **pparts,
 				   struct mtd_part_parser_data *data)
@@ -40,8 +44,12 @@ static int parse_ofpart_partitions(struct mtd_info *master,
 	/* First count the subnodes */
 	pp = NULL;
 	nr_parts = 0;
-	while ((pp = of_get_next_child(node, pp)))
+	while ((pp = of_get_next_child(node, pp))) {
+		if (node_has_compatible(pp))
+			continue;
+
 		nr_parts++;
+	}
 
 	if (nr_parts == 0)
 		return 0;
@@ -57,6 +65,9 @@ static int parse_ofpart_partitions(struct mtd_info *master,
 		int len;
 		int a_cells, s_cells;
 
+		if (node_has_compatible(pp))
+			continue;
+
 		reg = of_get_property(pp, "reg", &len);
 		if (!reg) {
 			nr_parts--;
-- 
1.7.9.5



From josh.wu at atmel.com  Wed Jul  3 05:56:19 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Wed, 3 Jul 2013 17:56:19 +0800
Subject: [PATCH] mtd: atmel_nand: fix pmecc selction for ecc requirement typo
Message-ID: <1372845379-5958-1-git-send-email-josh.wu@atmel.com>

Atmel PMECC support 2, 4, 8, 12, 24 bit error correction.
So if the ecc requirement in ONFI is <= 2, 4, 8, 12, 24.
We will use 2, 4, 8, 12, 24.

This patch fix the typo. Use '<=' replace '<'.

Reported-by: Scott Wood <scottwood at freescale.com>
Signed-off-by: Josh Wu <josh.wu at atmel.com>
---
 drivers/mtd/nand/atmel_nand.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 7e50ed8..2a42aa8 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -960,11 +960,11 @@ static int pmecc_choose_ecc(struct atmel_nand_host *host,
 			host->pmecc_corr_cap = 2;
 		else if (*cap <= 4)
 			host->pmecc_corr_cap = 4;
-		else if (*cap < 8)
+		else if (*cap <= 8)
 			host->pmecc_corr_cap = 8;
-		else if (*cap < 12)
+		else if (*cap <= 12)
 			host->pmecc_corr_cap = 12;
-		else if (*cap < 24)
+		else if (*cap <= 24)
 			host->pmecc_corr_cap = 24;
 		else
 			return -EINVAL;
-- 
1.7.9.5



From linux at arm.linux.org.uk  Wed Jul  3 06:00:44 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 3 Jul 2013 11:00:44 +0100
Subject: [PATCH] ARM: move body of head-common.S back to text section
In-Reply-To: <20130703051907.GA22702@windriver.com>
References: <1372805629-18382-1-git-send-email-swarren@wwwdotorg.org>
 <20130702232259.GH11625@codeaurora.org> <51D39004.9000907@wwwdotorg.org>
 <20130703051907.GA22702@windriver.com>
Message-ID: <20130703100044.GG24642@n2100.arm.linux.org.uk>

On Wed, Jul 03, 2013 at 01:19:07AM -0400, Paul Gortmaker wrote:
> As an aside, I'm now thinking any __INIT that implicitly rely on EOF for
> closure are nasty traps waiting to happen and it might be worthwhile to
> audit and explicitly __FINIT them before someone appends to the file...

That hides a different kind of bug though - I hate __FINIT for exactly
that reason.  Consider this:

	.text
	blah blah blah
	__INIT
	lots of init stuff
	__FINIT
	more .text stuff

Now, someone comes along and modifies this to be:

	.text
	blah blah blah
	.data
	something else
	__INIT
	lots of init stuff
	__FINIT
	more .text stuff

Now, what is the effect of that __FINIT now?  You get the following .text
emitted into the .data section instead.  This is basically the same problem
you've just encounted.

Maybe:

	__FINIT
	.text

is the safest solution - and __FINIT becomes just a no-op marker to avoid
anyone relying on its properties.


From kishon at ti.com  Wed Jul  3 06:05:39 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 3 Jul 2013 15:35:39 +0530
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
Message-ID: <51D3F773.9000209@ti.com>

Hi,

On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote:
> Hi Kishon,
>
>> -----Original Message-----
>> From: ABRAHAM, KISHON VIJAY
>> Sent: Wednesday, June 26, 2013 5:17 PM
>> To: grant.likely at linaro.org; tony at atomide.com; Balbi, Felipe; ABRAHAM,
>> KISHON VIJAY; arnd at arndb.de; swarren at nvidia.com;
>> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
>> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
>> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
>> foundation.org
>> Cc: rob.herring at calxeda.com; rob at landley.net; linux at arm.linux.org.uk;
>> benoit.cousson at linaro.org; mchehab at redhat.com; cesarb at cesarb.net;
>> davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org; Shilimkar,
>> Santosh; devicetree-discuss at lists.ozlabs.org; linux-
>> doc at vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T; Cherian,
>> George
>> Subject: [PATCH v9 0/8] Generic PHY Framework
>>
>> Added a generic PHY framework that provides a set of APIs for the PHY
>> drivers
>> to create/destroy a PHY and APIs for the PHY users to obtain a
>> reference to
>> the PHY with or without using phandle.
>>
>> This framework will be of use only to devices that uses external PHY
>> (PHY
>> functionality is not embedded within the controller).
>>
>> The intention of creating this framework is to bring the phy drivers
>> spread
>> all over the Linux kernel to drivers/phy to increase code re-use and
>> to
>> increase code maintainability.
>
> I would like to use this framework for a smart-card controller connected to a
> smart-card phy. I have some questions and would like to get feedback on the same.

glad to know that :-)
>
> I am using ?TDA8026" Smartcard PHY from NXP. Here is the link for datasheet
> and app note for the same. The smart card controller is inside the TI SoC
> I am working with.
>
> Datasheet :
> www.nxp.com/documents/data_sheet/TDA8026.pdf?
>
> Appnote :
> http://www.nxp.com/documents/application_note/AN10724.pdf
>
> The TI SoC details are not public (yet). I can provide details to you offline.
>
> Brief about operation:
> -	The controller can work with and without a PHY
> -	When not using PHY, it is limited to talking to a single
> 	smart card. There is also a need to put external de-activation logic
> 	on card removal for this case.
> -	With a PHY you can use more than one smart card.
> -	Phy has 5 slots :  1 for smart card (credit/debit/other card with chip)
>        and others for SAM ? SIM like modules
> - 	Once the PHY is initialized, there are some operations that the controller
> 	can request of the PHY like:
> 	- Card configurations  - set voltage
> 	- Activation of card
> 	- ATR ? Answer to reset
> 	- Warm reset
> 	- ADPU exchange
> 	- Deactivation ( Normal/Emergency)

hmm.. We should think about extending the phy_ops to include these 
operations (something like phy_smart_card_ops so that other smart_card 
PHYs will also be able to use it).
> - 	In the mode when smartcard controller talks directly to the card without the need
> 	for a PHY, all the above operations will be carried out by the controller itself
>
> My current thought process is to make the controller driver provide the user interface
> and talk to the PHY using the generic PHY framework you proposed. In the case where there
> is no PHY, my idea is to create a "dummy" PHY which uses the controller functionality itself.

right. And in the case where you actually have a PHY, create a PHY 
driver and implement the phy_smart_card_ops and register with the PHY 
framework.
>
> What I seem to be missing from the PHY framework is support for event detection and generic
> read/write API which will enable the controller to talk to the PHY for the operations listed
> above and also react to events from the PHY.

IMO the event detection should be handled in the PHY driver. And I dint 
feel the need for a read/write API as phy_xxxx_ops should be doing that 
precisely.

Thanks
Kishon


From b32955 at freescale.com  Wed Jul  3 05:42:36 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 3 Jul 2013 17:42:36 +0800
Subject: [PATCH v2 4/5] ARM: dts: imx6q: add dte pinctrl for uart2
In-Reply-To: <1372844557-3078-1-git-send-email-b32955@freescale.com>
References: <1372844557-3078-1-git-send-email-b32955@freescale.com>
Message-ID: <1372844557-3078-5-git-send-email-b32955@freescale.com>

In imx6q-arm2 board, the UART2 works in the dte mode.
So add a pinctrl for it.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6q.dtsi |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 9a69891..8a518c6 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -266,6 +266,15 @@
 							MX6Q_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
 						>;
 					};
+
+					pinctrl_uart2_dte: uart2grp-2 {
+						fsl,pins = <
+							MX6Q_PAD_EIM_D26__UART2_RX_DATA 0x1b0b1
+							MX6Q_PAD_EIM_D27__UART2_TX_DATA 0x1b0b1
+							MX6Q_PAD_EIM_D28__UART2_CTS_B	0x1b0b1
+							MX6Q_PAD_EIM_D29__UART2_CTS_B	0x1b0b1
+						>;
+					};
 				};
 
 				uart4 {
-- 
1.7.1




From b32955 at freescale.com  Wed Jul  3 05:42:32 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 3 Jul 2013 17:42:32 +0800
Subject: [PATCH v2 0/5] serial: imx: add DMA support for imx6
Message-ID: <1372844557-3078-1-git-send-email-b32955@freescale.com>

(1) This patch set adds the DMA support for the imx serial driver.
    The uart with the dma support is usually used by the Bluetooth.

    For the firmware's limit, i only enable the DMA for imx6 serials.
    If we have proper firmware for imx53 (or other chips), we can also
    enable the DMA for it.

(2) We only enable the DMA support when the following are meet:

    [1] The uart port supports the hardware flow control(CTS/RTS).
      (Some uart port does not support the CTS/RTS.)

    [2] The application enables the CTS/RTS.

    [3] The Soc is imx6 serials.
      For the sdma's firmware limit, we do not support the DMA except
      the imx6 platform.

    [4] The uart is not used as a console.


(3) Tested this patch set by:
	connecting a imx6q-arm2 board(DTE) with a imx53 board(DCE).

v1 --> v2:
	[0] use the "fsl,imx6q-uart" as the new compatible value.
	[1] move dma_is_inited to imx_uart_dma_init();
	    move dma_is_enabled to imx_enable_dma();
	[2] move imx_disable_dma() to the front place of the imx_shutdown(),
	    just before calls the imx_uart_dma_exit().
	[3] misc    
	

Huang Shijie (5):
  serial: imx: distinguish the imx6q uart from the others
  serial: imx: add DMA support for imx6q
  ARM: dts: imx6sl: add "fsl,imx6q-uart" for uart compatible
  ARM: dts: imx6q: add dte pinctrl for uart2
  ARM: dts: enable the uart2 for imx6q-arm2

 arch/arm/boot/dts/imx6q-arm2.dts |   10 +
 arch/arm/boot/dts/imx6q.dtsi     |    9 +
 arch/arm/boot/dts/imx6sl.dtsi    |   15 +-
 drivers/tty/serial/imx.c         |  422 +++++++++++++++++++++++++++++++++++++-
 4 files changed, 444 insertions(+), 12 deletions(-)




From b32955 at freescale.com  Wed Jul  3 05:42:33 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 3 Jul 2013 17:42:33 +0800
Subject: [PATCH v2 1/5] serial: imx: distinguish the imx6q uart from the others
In-Reply-To: <1372844557-3078-1-git-send-email-b32955@freescale.com>
References: <1372844557-3078-1-git-send-email-b32955@freescale.com>
Message-ID: <1372844557-3078-2-git-send-email-b32955@freescale.com>

We will add the DMA support for the imx uart. For the firmware's limit,
only the imx6 serial chips (including the imx6q, imx6dl, imx6sl) can
support the DMA.

This patch adds the necessary macro and helper to distinguish the
imx6q uart from the other imx uart. Other chips can use the "fsl,imx6q-uart"
to enable the DMA support.

This patch also replaces the check "is_imx21_uart()" with "!is_imx1_uart()".

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 drivers/tty/serial/imx.c |   17 +++++++++++++++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 48bace0..ca61677 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -187,6 +187,7 @@
 enum imx_uart_type {
 	IMX1_UART,
 	IMX21_UART,
+	IMX6Q_UART,
 };
 
 /* device type dependent stuff */
@@ -232,6 +233,10 @@ static struct imx_uart_data imx_uart_devdata[] = {
 		.uts_reg = IMX21_UTS,
 		.devtype = IMX21_UART,
 	},
+	[IMX6Q_UART] = {
+		.uts_reg = IMX21_UTS,
+		.devtype = IMX6Q_UART,
+	},
 };
 
 static struct platform_device_id imx_uart_devtype[] = {
@@ -242,6 +247,9 @@ static struct platform_device_id imx_uart_devtype[] = {
 		.name = "imx21-uart",
 		.driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX21_UART],
 	}, {
+		.name = "imx6q-uart",
+		.driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX6Q_UART],
+	}, {
 		/* sentinel */
 	}
 };
@@ -250,6 +258,7 @@ MODULE_DEVICE_TABLE(platform, imx_uart_devtype);
 static struct of_device_id imx_uart_dt_ids[] = {
 	{ .compatible = "fsl,imx1-uart", .data = &imx_uart_devdata[IMX1_UART], },
 	{ .compatible = "fsl,imx21-uart", .data = &imx_uart_devdata[IMX21_UART], },
+	{ .compatible = "fsl,imx6q-uart", .data = &imx_uart_devdata[IMX6Q_UART], },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, imx_uart_dt_ids);
@@ -269,6 +278,10 @@ static inline int is_imx21_uart(struct imx_port *sport)
 	return sport->devdata->devtype == IMX21_UART;
 }
 
+static inline int is_imx6q_uart(struct imx_port *sport)
+{
+	return sport->devdata->devtype == IMX6Q_UART;
+}
 /*
  * Save and restore functions for UCR1, UCR2 and UCR3 registers
  */
@@ -801,7 +814,7 @@ static int imx_startup(struct uart_port *port)
 		}
 	}
 
-	if (is_imx21_uart(sport)) {
+	if (!is_imx1_uart(sport)) {
 		temp = readl(sport->port.membase + UCR3);
 		temp |= IMX21_UCR3_RXDMUXSEL;
 		writel(temp, sport->port.membase + UCR3);
@@ -1044,7 +1057,7 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 	writel(num, sport->port.membase + UBIR);
 	writel(denom, sport->port.membase + UBMR);
 
-	if (is_imx21_uart(sport))
+	if (!is_imx1_uart(sport))
 		writel(sport->port.uartclk / div / 1000,
 				sport->port.membase + IMX21_ONEMS);
 
-- 
1.7.1




From b32955 at freescale.com  Wed Jul  3 05:42:37 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 3 Jul 2013 17:42:37 +0800
Subject: [PATCH v2 5/5] ARM: dts: enable the uart2 for imx6q-arm2
In-Reply-To: <1372844557-3078-1-git-send-email-b32955@freescale.com>
References: <1372844557-3078-1-git-send-email-b32955@freescale.com>
Message-ID: <1372844557-3078-6-git-send-email-b32955@freescale.com>

enable the uart2 for imx6q-arm2 board.
The uart2 works in the DTE mode, with the RTS/CTS and DMA enabled.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6q-arm2.dts |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-arm2.dts b/arch/arm/boot/dts/imx6q-arm2.dts
index 4e54fde..8beaa68 100644
--- a/arch/arm/boot/dts/imx6q-arm2.dts
+++ b/arch/arm/boot/dts/imx6q-arm2.dts
@@ -97,6 +97,16 @@
 	status = "okay";
 };
 
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2_dte>;
+	fsl,dte-mode;
+	fsl,uart-has-rtscts;
+	dma-names = "rx", "tx";
+	dmas = <&sdma 27 4 0>, <&sdma 28 4 0>;
+	status = "okay";
+};
+
 &uart4 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart4_1>;
-- 
1.7.1




From b32955 at freescale.com  Wed Jul  3 05:42:35 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 3 Jul 2013 17:42:35 +0800
Subject: [PATCH v2 3/5] ARM: dts: imx6sl: add "fsl,
 imx6q-uart" for uart compatible
In-Reply-To: <1372844557-3078-1-git-send-email-b32955@freescale.com>
References: <1372844557-3078-1-git-send-email-b32955@freescale.com>
Message-ID: <1372844557-3078-4-git-send-email-b32955@freescale.com>

In order to enable the DMA for some uart port in imx6sl, we add the
"fsl,imx6q-uart" to the uart's compatible property.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6sl.dtsi |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 9138c67..0a297af 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -152,7 +152,8 @@
 				};
 
 				uart5: serial at 02018000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02018000 0x4000>;
 					interrupts = <0 30 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -162,7 +163,8 @@
 				};
 
 				uart1: serial at 02020000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02020000 0x4000>;
 					interrupts = <0 26 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -172,7 +174,8 @@
 				};
 
 				uart2: serial at 02024000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02024000 0x4000>;
 					interrupts = <0 27 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -209,7 +212,8 @@
 				};
 
 				uart3: serial at 02034000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02034000 0x4000>;
 					interrupts = <0 28 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -219,7 +223,8 @@
 				};
 
 				uart4: serial at 02038000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02038000 0x4000>;
 					interrupts = <0 29 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
-- 
1.7.1




From b32955 at freescale.com  Wed Jul  3 05:42:34 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 3 Jul 2013 17:42:34 +0800
Subject: [PATCH v2 2/5] serial: imx: add DMA support for imx6q
In-Reply-To: <1372844557-3078-1-git-send-email-b32955@freescale.com>
References: <1372844557-3078-1-git-send-email-b32955@freescale.com>
Message-ID: <1372844557-3078-3-git-send-email-b32955@freescale.com>

We only enable the DMA support when the following are meet:

  [1] The uart port supports the hardware flow control(CTS/RTS).
      (Some uart port does not support the CTS/RTS.)

  [2] The application enables the CTS/RTS.

  [3] The Soc is imx6q.
      For the sdma's firmware limit, we do not support the DMA except
      the imx6q platform.

  [4] The uart is not used as a console.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 drivers/tty/serial/imx.c |  405 +++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 400 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index ca61677..182f1a8 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -49,9 +49,11 @@
 #include <linux/of_device.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/io.h>
+#include <linux/dma-mapping.h>
 
 #include <asm/irq.h>
 #include <linux/platform_data/serial-imx.h>
+#include <linux/platform_data/dma-imx.h>
 
 /* Register definitions */
 #define URXD0 0x0  /* Receiver Register */
@@ -83,6 +85,7 @@
 #define UCR1_ADBR	(1<<14) /* Auto detect baud rate */
 #define UCR1_TRDYEN	(1<<13) /* Transmitter ready interrupt enable */
 #define UCR1_IDEN	(1<<12) /* Idle condition interrupt */
+#define UCR1_ICD_REG(x) (((x) & 3) << 10) /* idle condition detect */
 #define UCR1_RRDYEN	(1<<9)	/* Recv ready interrupt enable */
 #define UCR1_RDMAEN	(1<<8)	/* Recv ready DMA enable */
 #define UCR1_IREN	(1<<7)	/* Infrared interface enable */
@@ -91,6 +94,7 @@
 #define UCR1_SNDBRK	(1<<4)	/* Send break */
 #define UCR1_TDMAEN	(1<<3)	/* Transmitter ready DMA enable */
 #define IMX1_UCR1_UARTCLKEN (1<<2) /* UART clock enabled, i.mx1 only */
+#define UCR1_ATDMAEN    (1<<2)  /* Aging DMA Timer Enable */
 #define UCR1_DOZE	(1<<1)	/* Doze */
 #define UCR1_UARTEN	(1<<0)	/* UART enabled */
 #define UCR2_ESCI	(1<<15)	/* Escape seq interrupt enable */
@@ -126,6 +130,7 @@
 #define UCR4_ENIRI	(1<<8)	/* Serial infrared interrupt enable */
 #define UCR4_WKEN	(1<<7)	/* Wake interrupt enable */
 #define UCR4_REF16	(1<<6)	/* Ref freq 16 MHz */
+#define UCR4_IDDMAEN    (1<<6)  /* DMA IDLE Condition Detected */
 #define UCR4_IRSC	(1<<5)	/* IR special case */
 #define UCR4_TCEN	(1<<3)	/* Transmit complete interrupt enable */
 #define UCR4_BKEN	(1<<2)	/* Break condition interrupt enable */
@@ -210,6 +215,19 @@ struct imx_port {
 	struct clk		*clk_ipg;
 	struct clk		*clk_per;
 	const struct imx_uart_data *devdata;
+
+	/* DMA fields */
+	unsigned int		dma_is_inited:1;
+	unsigned int		dma_is_enabled:1;
+	unsigned int		dma_is_rxing:1;
+	unsigned int		dma_is_txing:1;
+	struct dma_chan		*dma_chan_rx, *dma_chan_tx;
+	struct scatterlist	rx_sgl, tx_sgl[2];
+	void			*rx_buf;
+	unsigned int		rx_bytes, tx_bytes;
+	struct work_struct	tsk_dma_rx, tsk_dma_tx;
+	unsigned int		dma_tx_nents;
+	wait_queue_head_t	dma_wait;
 };
 
 struct imx_port_ucrs {
@@ -400,6 +418,13 @@ static void imx_stop_tx(struct uart_port *port)
 		return;
 	}
 
+	/*
+	 * We are maybe in the SMP context, so if the DMA TX thread is running
+	 * on other cpu, we have to wait for it to finish.
+	 */
+	if (sport->dma_is_enabled && sport->dma_is_txing)
+		return;
+
 	temp = readl(sport->port.membase + UCR1);
 	writel(temp & ~UCR1_TXMPTYEN, sport->port.membase + UCR1);
 }
@@ -412,6 +437,13 @@ static void imx_stop_rx(struct uart_port *port)
 	struct imx_port *sport = (struct imx_port *)port;
 	unsigned long temp;
 
+	/*
+	 * We are maybe in the SMP context, so if the DMA TX thread is running
+	 * on other cpu, we have to wait for it to finish.
+	 */
+	if (sport->dma_is_enabled && sport->dma_is_rxing)
+		return;
+
 	temp = readl(sport->port.membase + UCR2);
 	writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
 }
@@ -447,6 +479,95 @@ static inline void imx_transmit_buffer(struct imx_port *sport)
 		imx_stop_tx(&sport->port);
 }
 
+static void dma_tx_callback(void *data)
+{
+	struct imx_port *sport = data;
+	struct scatterlist *sgl = &sport->tx_sgl[0];
+	struct circ_buf *xmit = &sport->port.state->xmit;
+	unsigned long flags;
+
+	dma_unmap_sg(sport->port.dev, sgl, sport->dma_tx_nents, DMA_TO_DEVICE);
+
+	sport->dma_is_txing = 0;
+
+	/* update the stat */
+	spin_lock_irqsave(&sport->port.lock, flags);
+	xmit->tail = (xmit->tail + sport->tx_bytes) & (UART_XMIT_SIZE - 1);
+	sport->port.icount.tx += sport->tx_bytes;
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+
+	dev_dbg(sport->port.dev, "we finish the TX DMA.\n");
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(&sport->port);
+
+	if (waitqueue_active(&sport->dma_wait)) {
+		wake_up(&sport->dma_wait);
+		dev_dbg(sport->port.dev, "exit in %s.\n", __func__);
+		return;
+	}
+
+	schedule_work(&sport->tsk_dma_tx);
+}
+
+static void dma_tx_work(struct work_struct *w)
+{
+	struct imx_port *sport = container_of(w, struct imx_port, tsk_dma_tx);
+	struct circ_buf *xmit = &sport->port.state->xmit;
+	struct scatterlist *sgl = sport->tx_sgl;
+	struct dma_async_tx_descriptor *desc;
+	struct dma_chan	*chan = sport->dma_chan_tx;
+	struct device *dev = sport->port.dev;
+	enum dma_status status;
+	unsigned long flags;
+	int ret;
+
+	status = chan->device->device_tx_status(chan, (dma_cookie_t)0, NULL);
+	if (DMA_IN_PROGRESS == status)
+		return;
+
+	spin_lock_irqsave(&sport->port.lock, flags);
+	sport->tx_bytes = uart_circ_chars_pending(xmit);
+	if (sport->tx_bytes == 0) {
+		spin_unlock_irqrestore(&sport->port.lock, flags);
+		return;
+	}
+
+	if (xmit->tail > xmit->head) {
+		sport->dma_tx_nents = 2;
+		sg_init_table(sgl, 2);
+		sg_set_buf(sgl, xmit->buf + xmit->tail,
+				UART_XMIT_SIZE - xmit->tail);
+		sg_set_buf(sgl + 1, xmit->buf, xmit->head);
+	} else {
+		sport->dma_tx_nents = 1;
+		sg_init_one(sgl, xmit->buf + xmit->tail, sport->tx_bytes);
+	}
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+
+	ret = dma_map_sg(dev, sgl, sport->dma_tx_nents, DMA_TO_DEVICE);
+	if (ret == 0) {
+		dev_err(dev, "DMA mapping error for TX.\n");
+		return;
+	}
+	desc = dmaengine_prep_slave_sg(chan, sgl, sport->dma_tx_nents,
+					DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT);
+	if (!desc) {
+		dev_err(dev, "We cannot prepare for the TX slave dma!\n");
+		return;
+	}
+	desc->callback = dma_tx_callback;
+	desc->callback_param = sport;
+
+	dev_dbg(dev, "TX: prepare to send %lu bytes by DMA.\n",
+			uart_circ_chars_pending(xmit));
+	/* fire it */
+	sport->dma_is_txing = 1;
+	dmaengine_submit(desc);
+	dma_async_issue_pending(chan);
+	return;
+}
+
 /*
  * interrupts disabled on entry
  */
@@ -473,8 +594,10 @@ static void imx_start_tx(struct uart_port *port)
 	temp |= UCR4_OREN;
 	writel(temp, sport->port.membase + UCR4);
 
-	temp = readl(sport->port.membase + UCR1);
-	writel(temp | UCR1_TXMPTYEN, sport->port.membase + UCR1);
+	if (!sport->dma_is_enabled) {
+		temp = readl(sport->port.membase + UCR1);
+		writel(temp | UCR1_TXMPTYEN, sport->port.membase + UCR1);
+	}
 
 	if (USE_IRDA(sport)) {
 		temp = readl(sport->port.membase + UCR1);
@@ -486,6 +609,15 @@ static void imx_start_tx(struct uart_port *port)
 		writel(temp, sport->port.membase + UCR4);
 	}
 
+	if (sport->dma_is_enabled) {
+		/*
+		 * We may in the interrupt context, so arise a work_struct to
+		 * do the real job.
+		 */
+		schedule_work(&sport->tsk_dma_tx);
+		return;
+	}
+
 	if (readl(sport->port.membase + uts_reg(sport)) & UTS_TXEMPTY)
 		imx_transmit_buffer(sport);
 }
@@ -601,6 +733,28 @@ out:
 	return IRQ_HANDLED;
 }
 
+/*
+ * If the RXFIFO is filled with some data, and then we
+ * arise a DMA operation to receive them.
+ */
+static void imx_dma_rxint(struct imx_port *sport)
+{
+	unsigned long temp;
+
+	temp = readl(sport->port.membase + USR2);
+	if ((temp & USR2_RDR) && !sport->dma_is_rxing) {
+		sport->dma_is_rxing = 1;
+
+		/* disable the `Recerver Ready Interrrupt` */
+		temp = readl(sport->port.membase + UCR1);
+		temp &= ~(UCR1_RRDYEN);
+		writel(temp, sport->port.membase + UCR1);
+
+		/* tell the DMA to receive the data. */
+		schedule_work(&sport->tsk_dma_rx);
+	}
+}
+
 static irqreturn_t imx_int(int irq, void *dev_id)
 {
 	struct imx_port *sport = dev_id;
@@ -609,8 +763,12 @@ static irqreturn_t imx_int(int irq, void *dev_id)
 
 	sts = readl(sport->port.membase + USR1);
 
-	if (sts & USR1_RRDY)
-		imx_rxint(irq, dev_id);
+	if (sts & USR1_RRDY) {
+		if (sport->dma_is_enabled)
+			imx_dma_rxint(sport);
+		else
+			imx_rxint(irq, dev_id);
+	}
 
 	if (sts & USR1_TRDY &&
 			readl(sport->port.membase + UCR1) & UCR1_TXMPTYEN)
@@ -667,7 +825,8 @@ static void imx_set_mctrl(struct uart_port *port, unsigned int mctrl)
 	temp = readl(sport->port.membase + UCR2) & ~UCR2_CTS;
 
 	if (mctrl & TIOCM_RTS)
-		temp |= UCR2_CTS;
+		if (!sport->dma_is_enabled)
+			temp |= UCR2_CTS;
 
 	writel(temp, sport->port.membase + UCR2);
 }
@@ -706,6 +865,226 @@ static int imx_setup_ufcr(struct imx_port *sport, unsigned int mode)
 	return 0;
 }
 
+#define RX_BUF_SIZE	(PAGE_SIZE)
+static int start_rx_dma(struct imx_port *sport);
+static void dma_rx_work(struct work_struct *w)
+{
+	struct imx_port *sport = container_of(w, struct imx_port, tsk_dma_rx);
+	struct tty_port *port = &sport->port.state->port;
+
+	if (sport->rx_bytes) {
+		tty_insert_flip_string(port, sport->rx_buf, sport->rx_bytes);
+		tty_flip_buffer_push(port);
+		sport->rx_bytes = 0;
+	}
+
+	if (sport->dma_is_rxing)
+		start_rx_dma(sport);
+}
+
+static void imx_rx_dma_done(struct imx_port *sport)
+{
+	unsigned long temp;
+
+	/* Enable this interrupt when the RXFIFO is empty. */
+	temp = readl(sport->port.membase + UCR1);
+	temp |= UCR1_RRDYEN;
+	writel(temp, sport->port.membase + UCR1);
+
+	sport->dma_is_rxing = 0;
+
+	/* Is the shutdown waiting for us? */
+	if (waitqueue_active(&sport->dma_wait))
+		wake_up(&sport->dma_wait);
+}
+
+/*
+ * There are three kinds of RX DMA interrupts(such as in the MX6Q):
+ *   [1] the RX DMA buffer is full.
+ *   [2] the Aging timer expires(wait for 8 bytes long)
+ *   [3] the Idle Condition Detect(enabled the UCR4_IDDMAEN).
+ *
+ * The [2] is trigger when a character was been sitting in the FIFO
+ * meanwhile [3] can wait for 32 bytes long when the RX line is
+ * on IDLE state and RxFIFO is empty.
+ */
+static void dma_rx_callback(void *data)
+{
+	struct imx_port *sport = data;
+	struct dma_chan	*chan = sport->dma_chan_rx;
+	struct scatterlist *sgl = &sport->rx_sgl;
+	struct dma_tx_state state;
+	enum dma_status status;
+	unsigned int count;
+
+	/* unmap it first */
+	dma_unmap_sg(sport->port.dev, sgl, 1, DMA_FROM_DEVICE);
+
+	status = chan->device->device_tx_status(chan, (dma_cookie_t)0, &state);
+	count = RX_BUF_SIZE - state.residue;
+	dev_dbg(sport->port.dev, "We get %d bytes.\n", count);
+
+	if (count) {
+		sport->rx_bytes = count;
+		schedule_work(&sport->tsk_dma_rx);
+	} else
+		imx_rx_dma_done(sport);
+}
+
+static int start_rx_dma(struct imx_port *sport)
+{
+	struct scatterlist *sgl = &sport->rx_sgl;
+	struct dma_chan	*chan = sport->dma_chan_rx;
+	struct device *dev = sport->port.dev;
+	struct dma_async_tx_descriptor *desc;
+	int ret;
+
+	sg_init_one(sgl, sport->rx_buf, RX_BUF_SIZE);
+	ret = dma_map_sg(dev, sgl, 1, DMA_FROM_DEVICE);
+	if (ret == 0) {
+		dev_err(dev, "DMA mapping error for RX.\n");
+		return -EINVAL;
+	}
+	desc = dmaengine_prep_slave_sg(chan, sgl, 1, DMA_DEV_TO_MEM,
+					DMA_PREP_INTERRUPT);
+	if (!desc) {
+		dev_err(dev, "We cannot prepare for the RX slave dma!\n");
+		return -EINVAL;
+	}
+	desc->callback = dma_rx_callback;
+	desc->callback_param = sport;
+
+	dev_dbg(dev, "RX: prepare for the DMA.\n");
+	dmaengine_submit(desc);
+	dma_async_issue_pending(chan);
+	return 0;
+}
+
+static void imx_uart_dma_exit(struct imx_port *sport)
+{
+	if (sport->dma_chan_rx) {
+		dma_release_channel(sport->dma_chan_rx);
+		sport->dma_chan_rx = NULL;
+
+		kfree(sport->rx_buf);
+		sport->rx_buf = NULL;
+	}
+
+	if (sport->dma_chan_tx) {
+		dma_release_channel(sport->dma_chan_tx);
+		sport->dma_chan_tx = NULL;
+	}
+
+	sport->dma_is_inited = 0;
+}
+
+static int imx_uart_dma_init(struct imx_port *sport)
+{
+	struct dma_slave_config slave_config;
+	struct device *dev = sport->port.dev;
+	int ret;
+
+	/* Prepare for RX : */
+	sport->dma_chan_rx = dma_request_slave_channel(dev, "rx");
+	if (!sport->dma_chan_rx) {
+		dev_dbg(dev, "cannot get the DMA channel.\n");
+		ret = -EINVAL;
+		goto err;
+	}
+
+	slave_config.direction = DMA_DEV_TO_MEM;
+	slave_config.src_addr = sport->port.mapbase + URXD0;
+	slave_config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	slave_config.src_maxburst = RXTL;
+	ret = dmaengine_slave_config(sport->dma_chan_rx, &slave_config);
+	if (ret) {
+		dev_err(dev, "error in RX dma configuration.\n");
+		goto err;
+	}
+
+	sport->rx_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
+	if (!sport->rx_buf) {
+		dev_err(dev, "cannot alloc DMA buffer.\n");
+		ret = -ENOMEM;
+		goto err;
+	}
+	sport->rx_bytes = 0;
+
+	/* Prepare for TX : */
+	sport->dma_chan_tx = dma_request_slave_channel(dev, "tx");
+	if (!sport->dma_chan_tx) {
+		dev_err(dev, "cannot get the TX DMA channel!\n");
+		ret = -EINVAL;
+		goto err;
+	}
+
+	slave_config.direction = DMA_MEM_TO_DEV;
+	slave_config.dst_addr = sport->port.mapbase + URTX0;
+	slave_config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	slave_config.dst_maxburst = TXTL;
+	ret = dmaengine_slave_config(sport->dma_chan_tx, &slave_config);
+	if (ret) {
+		dev_err(dev, "error in TX dma configuration.");
+		goto err;
+	}
+
+	sport->dma_is_inited = 1;
+
+	return 0;
+err:
+	imx_uart_dma_exit(sport);
+	return ret;
+}
+
+static void imx_enable_dma(struct imx_port *sport)
+{
+	unsigned long temp;
+	struct tty_port *port = &sport->port.state->port;
+
+	port->low_latency = 1;
+	INIT_WORK(&sport->tsk_dma_tx, dma_tx_work);
+	INIT_WORK(&sport->tsk_dma_rx, dma_rx_work);
+	init_waitqueue_head(&sport->dma_wait);
+
+	/* set UCR1 */
+	temp = readl(sport->port.membase + UCR1);
+	temp |= UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN |
+		/* wait for 32 idle frames for IDDMA interrupt */
+		UCR1_ICD_REG(3);
+	writel(temp, sport->port.membase + UCR1);
+
+	/* set UCR4 */
+	temp = readl(sport->port.membase + UCR4);
+	temp |= UCR4_IDDMAEN;
+	writel(temp, sport->port.membase + UCR4);
+
+	sport->dma_is_enabled = 1;
+}
+
+static void imx_disable_dma(struct imx_port *sport)
+{
+	unsigned long temp;
+	struct tty_port *port = &sport->port.state->port;
+
+	/* clear UCR1 */
+	temp = readl(sport->port.membase + UCR1);
+	temp &= ~(UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN);
+	writel(temp, sport->port.membase + UCR1);
+
+	/* clear UCR2 */
+	temp = readl(sport->port.membase + UCR2);
+	temp &= ~(UCR2_CTSC | UCR2_CTS);
+	writel(temp, sport->port.membase + UCR2);
+
+	/* clear UCR4 */
+	temp = readl(sport->port.membase + UCR4);
+	temp &= ~UCR4_IDDMAEN;
+	writel(temp, sport->port.membase + UCR4);
+
+	sport->dma_is_enabled = 0;
+	port->low_latency = 0;
+}
+
 /* half the RX buffer size */
 #define CTSTL 16
 
@@ -870,6 +1249,15 @@ static void imx_shutdown(struct uart_port *port)
 	unsigned long temp;
 	unsigned long flags;
 
+	if (sport->dma_is_enabled) {
+		/* We have to wait for the DMA to finish. */
+		wait_event(sport->dma_wait,
+			!sport->dma_is_rxing && !sport->dma_is_txing);
+		imx_stop_rx(port);
+		imx_disable_dma(sport);
+		imx_uart_dma_exit(sport);
+	}
+
 	spin_lock_irqsave(&sport->port.lock, flags);
 	temp = readl(sport->port.membase + UCR2);
 	temp &= ~(UCR2_TXEN);
@@ -956,6 +1344,11 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 		if (sport->have_rtscts) {
 			ucr2 &= ~UCR2_IRTS;
 			ucr2 |= UCR2_CTSC;
+
+			/* Can we enable the DMA support? */
+			if (is_imx6q_uart(sport) && !uart_console(port)
+				&& !sport->dma_is_inited)
+				imx_uart_dma_init(sport);
 		} else {
 			termios->c_cflag &= ~CRTSCTS;
 		}
@@ -1069,6 +1462,8 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 	if (UART_ENABLE_MS(&sport->port, termios->c_cflag))
 		imx_enable_ms(&sport->port);
 
+	if (sport->dma_is_inited && !sport->dma_is_enabled)
+		imx_enable_dma(sport);
 	spin_unlock_irqrestore(&sport->port.lock, flags);
 }
 
-- 
1.7.1




From notasas at gmail.com  Wed Jul  3 06:13:08 2013
From: notasas at gmail.com (Grazvydas Ignotas)
Date: Wed, 3 Jul 2013 13:13:08 +0300
Subject: [PATCH v2 0/9] wilink: add device tree support
In-Reply-To: <1372776948-24840-1-git-send-email-coelho@ti.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
Message-ID: <CANOLnOPBHesTiV61zpQ_QS9c7E91K50EnbMnGhvgaViuA_3=Bw@mail.gmail.com>

Hi,

On Tue, Jul 2, 2013 at 5:55 PM, Luciano Coelho <coelho at ti.com> wrote:
> Hi,
>
> This is a follow-up on a previous patch set that had a smaller
> audience.  This time, I added the lists and people who were involved
> in the review of the bindings documentation, since most of my changes
> in v2 are coming from discussions there.
>
> This patch series adds device tree support to the wlcore_sdio driver,
> which is used by WiLink6, WiLink7 and WiLink8.

Could you perhaps consider doing device tree conversion for wl1251
too? With the knowledge you have from working on this series, it would
be much easier for you to do it than for someone else, and I don't
have much hope someone will do it at all. It's WiLink series chip
after all. Without this pandora and N900 are going to lose wifi
support after the switch to dt-only kernel.

I can offer you my help testing things on pandora and I'm sure someone
here could try it on N900.


--
Gra?vydas


From peter.maydell at linaro.org  Wed Jul  3 06:54:03 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Wed, 3 Jul 2013 11:54:03 +0100
Subject: [PATCH] arm64: KVM: Support Cortex-A57 guest CPU on APM X-Gene
 host
In-Reply-To: <1372840923-12808-1-git-send-email-anup.patel@linaro.org>
References: <1372840923-12808-1-git-send-email-anup.patel@linaro.org>
Message-ID: <CAFEAcA_9mfYT6pPOT3dmqGoFAeJpQACO4FZp_971XUSowxoBaA@mail.gmail.com>

On 3 July 2013 09:42, Anup Patel <anup.patel at linaro.org> wrote:
> Update kvm_target_cpu() to allow Cortex-A57 guest CPU on APM X-Gene.
>
> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> ---
>  arch/arm64/kvm/guest.c |   10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 2c3ff67..765f56f 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -207,8 +207,13 @@ int __attribute_const__ kvm_target_cpu(void)
>         unsigned long implementor = read_cpuid_implementor();
>         unsigned long part_number = read_cpuid_part_number();
>
> -       if (implementor != ARM_CPU_IMP_ARM)
> -               return -EINVAL;
> +       switch (implementor) {
> +       case ARM_CPU_IMP_ARM:
> +       case ARM_CPU_IMP_APM:
> +               break;
> +       default:
> +               return -EINVAL;
> +       }

Doesn't this change mean we now accept the below part
numbers for all implementors? That doesn't look right.

>         switch (part_number) {
>         case ARM_CPU_PART_AEM_V8:
> @@ -216,6 +221,7 @@ int __attribute_const__ kvm_target_cpu(void)
>         case ARM_CPU_PART_FOUNDATION:
>                 return KVM_ARM_TARGET_FOUNDATION_V8;
>         case ARM_CPU_PART_CORTEX_A57:
> +       case APM_CPU_PART_POTENZA:
>                 /* Currently handled by the generic backend */
>                 return KVM_ARM_TARGET_CORTEX_A57;
>         default:

Do we really model all the system registers and so on correctly
sufficiently to be able to present the guest with an A57 vcpu
on an APM X-Gene host? (ie without accidentally leaking the
host ID registers/system registers/impdef registers to the
guest).

thanks
-- PMM


From nicolas.ferre at atmel.com  Wed Jul  3 07:00:50 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 3 Jul 2013 13:00:50 +0200
Subject: [PATCH] ARM: at91/DT: at91sam9x5ek: fix USB host property to enable
 port C
Message-ID: <1372849250-14715-1-git-send-email-nicolas.ferre@atmel.com>

Device Tree "num-ports" property of USB host node has to be
set to maximum number of ports available.
The possibility to activate a particular port is done by specifying the proper
gpio configuration for its vbus.

This patch fixes the USB host node by configuring the 3 ports available on the
product and letting "port A" available for USB gadget usage.

Reported-by: Rodolfo Giometti <giometti at enneenne.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Cc: Bo Shen <voice.shen at atmel.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index b753855..49e3c45 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -94,8 +94,9 @@
 
 		usb0: ohci at 00600000 {
 			status = "okay";
-			num-ports = <2>;
-			atmel,vbus-gpio = <&pioD 19 GPIO_ACTIVE_LOW
+			num-ports = <3>;
+			atmel,vbus-gpio = <0 /* &pioD 18 GPIO_ACTIVE_LOW *//* Activate to have access to port A */
+					   &pioD 19 GPIO_ACTIVE_LOW
 					   &pioD 20 GPIO_ACTIVE_LOW
 					  >;
 		};
-- 
1.8.2.2



From plagnioj at jcrosoft.com  Wed Jul  3 07:10:16 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 3 Jul 2013 13:10:16 +0200
Subject: [PATCH v2 4/4] at91/avr32/atmel_lcdfb: prepare clk before
 calling enable
In-Reply-To: <51C951C2.8090901@atmel.com>
References: <1372147702-4074-1-git-send-email-b.brezillon@overkiz.com>
 <1372148053-4477-1-git-send-email-b.brezillon@overkiz.com>
 <51C951C2.8090901@atmel.com>
Message-ID: <20130703111016.GM305@game.jcrosoft.org>

On 10:16 Tue 25 Jun     , Nicolas Ferre wrote:
> On 25/06/2013 10:14, Boris BREZILLON :
> >Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
> >avoid common clk framework warnings.
> >
> >Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
> 
> Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> Jean-Christophe, can you take this one?

Yes I'll

Best Regards,
J.
> 
> Thanks, best regards,
> 
> >---
> >  drivers/video/atmel_lcdfb.c |    8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> >diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> >index 540909d..8525457 100644
> >--- a/drivers/video/atmel_lcdfb.c
> >+++ b/drivers/video/atmel_lcdfb.c
> >@@ -893,14 +893,14 @@ static int __init atmel_lcdfb_init_fbinfo(struct atmel_lcdfb_info *sinfo)
> >
> >  static void atmel_lcdfb_start_clock(struct atmel_lcdfb_info *sinfo)
> >  {
> >-	clk_enable(sinfo->bus_clk);
> >-	clk_enable(sinfo->lcdc_clk);
> >+	clk_prepare_enable(sinfo->bus_clk);
> >+	clk_prepare_enable(sinfo->lcdc_clk);
> >  }
> >
> >  static void atmel_lcdfb_stop_clock(struct atmel_lcdfb_info *sinfo)
> >  {
> >-	clk_disable(sinfo->bus_clk);
> >-	clk_disable(sinfo->lcdc_clk);
> >+	clk_disable_unprepare(sinfo->bus_clk);
> >+	clk_disable_unprepare(sinfo->lcdc_clk);
> >  }
> >
> >
> >
> 
> 
> -- 
> Nicolas Ferre


From plagnioj at jcrosoft.com  Wed Jul  3 07:01:37 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 3 Jul 2013 13:01:37 +0200
Subject: [PATCH] ARM: at91/DT: at91sam9x5ek: fix USB host property to
 enable port C
In-Reply-To: <1372849250-14715-1-git-send-email-nicolas.ferre@atmel.com>
References: <1372849250-14715-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <20130703110137.GE21034@game.jcrosoft.org>

On 13:00 Wed 03 Jul     , Nicolas Ferre wrote:
> Device Tree "num-ports" property of USB host node has to be
> set to maximum number of ports available.
> The possibility to activate a particular port is done by specifying the proper
> gpio configuration for its vbus.
> 
> This patch fixes the USB host node by configuring the 3 ports available on the
> product and letting "port A" available for USB gadget usage.
> 
> Reported-by: Rodolfo Giometti <giometti at enneenne.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> Cc: Bo Shen <voice.shen at atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

> ---
>  arch/arm/boot/dts/at91sam9x5ek.dtsi | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
> index b753855..49e3c45 100644
> --- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
> @@ -94,8 +94,9 @@
>  
>  		usb0: ohci at 00600000 {
>  			status = "okay";
> -			num-ports = <2>;
> -			atmel,vbus-gpio = <&pioD 19 GPIO_ACTIVE_LOW
> +			num-ports = <3>;
> +			atmel,vbus-gpio = <0 /* &pioD 18 GPIO_ACTIVE_LOW *//* Activate to have access to port A */
on 2 line would have been more clear


Best Regards,
J.
> +					   &pioD 19 GPIO_ACTIVE_LOW
>  					   &pioD 20 GPIO_ACTIVE_LOW
>  					  >;
>  		};
> -- 
> 1.8.2.2
> 


From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:00:19 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue, 2 Jul 2013 13:00:19 +0200
Subject: [PATCH v6 2/7] ARM: kirkwood: add gigabit ethernet and mvmdio device
 tree nodes
In-Reply-To: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372762824-12202-3-git-send-email-sebastian.hesselbarth@gmail.com>

This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Kirkwood boards. Phy nodes are also added with reg property set on a
per-board basis.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Changelog:
v5->v6:
- rebase for v3.11-rc1
- also convert Sheevaplug and DB628x

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: netdev at vger.kernel.org
---
 arch/arm/boot/dts/kirkwood-cloudbox.dts            |   16 ++++++
 arch/arm/boot/dts/kirkwood-db.dtsi                 |   16 ++++++
 arch/arm/boot/dts/kirkwood-dnskw.dtsi              |   16 ++++++
 arch/arm/boot/dts/kirkwood-dockstar.dts            |   17 ++++++
 arch/arm/boot/dts/kirkwood-dreamplug.dts           |   28 +++++++++++
 arch/arm/boot/dts/kirkwood-goflexnet.dts           |   16 ++++++
 .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |   30 +++++++++++
 arch/arm/boot/dts/kirkwood-ib62x0.dts              |   16 ++++++
 arch/arm/boot/dts/kirkwood-iconnect.dts            |   16 ++++++
 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts      |   24 +++++++++
 arch/arm/boot/dts/kirkwood-is2.dts                 |    2 +
 arch/arm/boot/dts/kirkwood-km_kirkwood.dts         |   16 ++++++
 arch/arm/boot/dts/kirkwood-lsxl.dtsi               |   28 +++++++++++
 arch/arm/boot/dts/kirkwood-mplcec4.dts             |   27 ++++++++++
 .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  |   16 ++++++
 arch/arm/boot/dts/kirkwood-ns2-common.dtsi         |   16 ++++++
 arch/arm/boot/dts/kirkwood-ns2.dts                 |    2 +
 arch/arm/boot/dts/kirkwood-ns2lite.dts             |    2 +
 arch/arm/boot/dts/kirkwood-ns2max.dts              |    2 +
 arch/arm/boot/dts/kirkwood-ns2mini.dts             |    2 +
 arch/arm/boot/dts/kirkwood-openblocks_a6.dts       |   16 ++++++
 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi  |   16 ++++++
 arch/arm/boot/dts/kirkwood-topkick.dts             |   16 ++++++
 arch/arm/boot/dts/kirkwood-ts219-6281.dts          |    4 +-
 arch/arm/boot/dts/kirkwood-ts219-6282.dts          |    4 +-
 arch/arm/boot/dts/kirkwood-ts219.dtsi              |   16 ++++++
 arch/arm/boot/dts/kirkwood.dtsi                    |   52 ++++++++++++++++++++
 27 files changed, 430 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-cloudbox.dts b/arch/arm/boot/dts/kirkwood-cloudbox.dts
index 00c48d2..85eed62 100644
--- a/arch/arm/boot/dts/kirkwood-cloudbox.dts
+++ b/arch/arm/boot/dts/kirkwood-cloudbox.dts
@@ -89,3 +89,19 @@
 		gpios = <&gpio0 17 0>;
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-db.dtsi b/arch/arm/boot/dts/kirkwood-db.dtsi
index c87cfb8..ca8bf36 100644
--- a/arch/arm/boot/dts/kirkwood-db.dtsi
+++ b/arch/arm/boot/dts/kirkwood-db.dtsi
@@ -87,3 +87,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 8 {
+		device_type = "ethernet-phy";
+		reg = <8>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 0afe1d0..f600ed7 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -219,3 +219,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 8 {
+		device_type = "ethernet-phy";
+		reg = <8>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-dockstar.dts b/arch/arm/boot/dts/kirkwood-dockstar.dts
index 7714742..915aca6 100644
--- a/arch/arm/boot/dts/kirkwood-dockstar.dts
+++ b/arch/arm/boot/dts/kirkwood-dockstar.dts
@@ -90,3 +90,20 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		compatible = "marvell,88e1116";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 36c7ba3..300fbf8 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -99,3 +99,31 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+
+	ethphy1: ethernet-phy at 1 {
+		device_type = "ethernet-phy";
+		reg = <1>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-goflexnet.dts b/arch/arm/boot/dts/kirkwood-goflexnet.dts
index 31caa64..e9ba68e 100644
--- a/arch/arm/boot/dts/kirkwood-goflexnet.dts
+++ b/arch/arm/boot/dts/kirkwood-goflexnet.dts
@@ -170,3 +170,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
index 1e642f3..e696c31 100644
--- a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
+++ b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
@@ -96,3 +96,33 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		compatible = "marvell,88e1121";
+		reg = <0>;
+	};
+
+	ethphy1: ethernet-phy at 1 {
+		device_type = "ethernet-phy";
+		compatible = "marvell,88e1121";
+		reg = <1>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ib62x0.dts b/arch/arm/boot/dts/kirkwood-ib62x0.dts
index 20c4b08..69019b8 100644
--- a/arch/arm/boot/dts/kirkwood-ib62x0.dts
+++ b/arch/arm/boot/dts/kirkwood-ib62x0.dts
@@ -122,3 +122,19 @@
 
 
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 8 {
+		device_type = "ethernet-phy";
+		reg = <8>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-iconnect.dts b/arch/arm/boot/dts/kirkwood-iconnect.dts
index 441204e..3d99164 100644
--- a/arch/arm/boot/dts/kirkwood-iconnect.dts
+++ b/arch/arm/boot/dts/kirkwood-iconnect.dts
@@ -176,3 +176,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 11 {
+		device_type = "ethernet-phy";
+		reg = <11>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
index 00a7bfe..b08c733 100644
--- a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
+++ b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
@@ -194,3 +194,27 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy1: ethernet-phy at 11 {
+		device_type = "ethernet-phy";
+		reg = <11>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		speed = <1000>;
+		duplex = <1>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-is2.dts b/arch/arm/boot/dts/kirkwood-is2.dts
index c3f036b..ff9be45 100644
--- a/arch/arm/boot/dts/kirkwood-is2.dts
+++ b/arch/arm/boot/dts/kirkwood-is2.dts
@@ -30,3 +30,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <8>; };
diff --git a/arch/arm/boot/dts/kirkwood-km_kirkwood.dts b/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
index 5d9f5ea..466280b 100644
--- a/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
+++ b/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
@@ -50,3 +50,19 @@
 		i2c-gpio,delay-us = <2>;	/* ~100 kHz */
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
index 31b17f5..93397b1 100644
--- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
+++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
@@ -207,3 +207,31 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+
+	ethphy1: ethernet-phy at 8 {
+		device_type = "ethernet-phy";
+		reg = <8>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-mplcec4.dts b/arch/arm/boot/dts/kirkwood-mplcec4.dts
index 6179333..def825f 100644
--- a/arch/arm/boot/dts/kirkwood-mplcec4.dts
+++ b/arch/arm/boot/dts/kirkwood-mplcec4.dts
@@ -191,3 +191,30 @@
 	};
 };
 
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 1 {
+		device_type = "ethernet-phy";
+		reg = <1>;
+	};
+
+	ethphy1: ethernet-phy at 2 {
+		device_type = "ethernet-phy";
+		reg = <2>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
index ad6ade7..716b203 100644
--- a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
+++ b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
@@ -184,3 +184,19 @@
                 };
         };
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2-common.dtsi b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
index 2afac04..e7b8017 100644
--- a/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
@@ -84,3 +84,19 @@
 	};
 
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy {
+		device_type = "ethernet-phy";
+                /* overwrite reg property in board file */
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2.dts b/arch/arm/boot/dts/kirkwood-ns2.dts
index b50e93d..e93276d 100644
--- a/arch/arm/boot/dts/kirkwood-ns2.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2.dts
@@ -30,3 +30,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <8>; };
diff --git a/arch/arm/boot/dts/kirkwood-ns2lite.dts b/arch/arm/boot/dts/kirkwood-ns2lite.dts
index af8259f..34f5e69 100644
--- a/arch/arm/boot/dts/kirkwood-ns2lite.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2lite.dts
@@ -30,3 +30,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <0>; };
diff --git a/arch/arm/boot/dts/kirkwood-ns2max.dts b/arch/arm/boot/dts/kirkwood-ns2max.dts
index 85f24d2..f834c55 100644
--- a/arch/arm/boot/dts/kirkwood-ns2max.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2max.dts
@@ -49,3 +49,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <8>; };
diff --git a/arch/arm/boot/dts/kirkwood-ns2mini.dts b/arch/arm/boot/dts/kirkwood-ns2mini.dts
index 329e530..b6b66ea 100644
--- a/arch/arm/boot/dts/kirkwood-ns2mini.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2mini.dts
@@ -50,3 +50,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <0>; };
diff --git a/arch/arm/boot/dts/kirkwood-openblocks_a6.dts b/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
index 38dc851..7235f0c 100644
--- a/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
+++ b/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
@@ -166,3 +166,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
index f7143f1..f55a145 100644
--- a/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
@@ -91,3 +91,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-topkick.dts b/arch/arm/boot/dts/kirkwood-topkick.dts
index f2052d7..184b8c5 100644
--- a/arch/arm/boot/dts/kirkwood-topkick.dts
+++ b/arch/arm/boot/dts/kirkwood-topkick.dts
@@ -203,3 +203,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6281.dts b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
index 6dd1038..222435d 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6281.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
@@ -50,4 +50,6 @@
 			gpios = <&gpio0 16 1>;
 		};
 	};
-};
\ No newline at end of file
+};
+
+&ethphy0 { reg = <8>; };
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
index 6fdc5ff..510c555 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -58,4 +58,6 @@
 			gpios = <&gpio1 5 1>;
 		};
 	};
-};
\ No newline at end of file
+};
+
+&ethphy0 { reg = <0>; };
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
index 0c9a94c..102eaeb 100644
--- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -96,3 +96,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy {
+		device_type = "ethernet-phy";
+                /* overwrite reg property in board file */
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 078637c..ad56dd8 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -190,5 +190,57 @@
 			clocks = <&gate_clk 17>;
 			status = "okay";
 		};
+
+		mdio: mdio-bus at 72004 {
+			compatible = "marvell,orion-mdio";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x72004 0x84>;
+			interrupts = <46>;
+			clocks = <&gate_clk 0>;
+			status = "disabled";
+
+			/* add phy nodes in board file */
+		};
+
+		eth0: ethernet-controller at 72000 {
+			compatible = "marvell,kirkwood-eth";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x72000 0x4000>;
+			clocks = <&gate_clk 0>;
+			marvell,tx-checksum-limit = <1600>;
+			status = "disabled";
+
+			ethernet0-port at 0 {
+				device_type = "network";
+				compatible = "marvell,kirkwood-eth-port";
+				reg = <0>;
+				interrupts = <11>;
+				/* overwrite MAC address in bootloader */
+				local-mac-address = [00 00 00 00 00 00];
+				/* set phy-handle property in board file */
+			};
+		};
+
+		eth1: ethernet-controller at 76000 {
+			compatible = "marvell,kirkwood-eth";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x76000 0x4000>;
+			clocks = <&gate_clk 19>;
+			marvell,tx-checksum-limit = <1600>;
+			status = "disabled";
+
+			ethernet1-port at 1 {
+				device_type = "network";
+				compatible = "marvell,kirkwood-eth-port";
+				reg = <1>;
+				interrupts = <15>;
+				/* overwrite MAC address in bootloader */
+				local-mac-address = [00 00 00 00 00 00];
+				/* set phy-handle property in board file */
+			};
+		};
 	};
 };
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


From sebastian.hesselbarth at gmail.com  Tue Jul  2 07:00:22 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue, 2 Jul 2013 13:00:22 +0200
Subject: [PATCH v6 5/7] ARM: kirkwood: remove redundant DT board files
In-Reply-To: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372762824-12202-6-git-send-email-sebastian.hesselbarth@gmail.com>

With DT support for mv643xx_eth board specific init for some boards now
is unneccessary. Remove those board files, Kconfig entries, and
corresponding entries in kirkwood_defconfig.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Changelog:
v5->v6:
- rebase for v3.11-rc1

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: netdev at vger.kernel.org
---
 arch/arm/configs/kirkwood_defconfig           |   22 ----
 arch/arm/mach-kirkwood/Kconfig                |  156 -------------------------
 arch/arm/mach-kirkwood/Makefile               |   23 +----
 arch/arm/mach-kirkwood/board-db88f628x-bp.c   |   24 ----
 arch/arm/mach-kirkwood/board-dnskw.c          |    7 -
 arch/arm/mach-kirkwood/board-dockstar.c       |   32 -----
 arch/arm/mach-kirkwood/board-dreamplug.c      |   35 ------
 arch/arm/mach-kirkwood/board-dt.c             |   84 +-------------
 arch/arm/mach-kirkwood/board-goflexnet.c      |   34 ------
 arch/arm/mach-kirkwood/board-guruplug.c       |   33 -----
 arch/arm/mach-kirkwood/board-ib62x0.c         |   29 -----
 arch/arm/mach-kirkwood/board-iconnect.c       |   24 ----
 arch/arm/mach-kirkwood/board-iomega_ix2_200.c |   34 ------
 arch/arm/mach-kirkwood/board-km_kirkwood.c    |   44 -------
 arch/arm/mach-kirkwood/board-lsxl.c           |   36 ------
 arch/arm/mach-kirkwood/board-mplcec4.c        |   35 ------
 arch/arm/mach-kirkwood/board-ns2.c            |   35 ------
 arch/arm/mach-kirkwood/board-openblocks_a6.c  |   26 ----
 arch/arm/mach-kirkwood/board-readynas.c       |   27 -----
 arch/arm/mach-kirkwood/board-sheevaplug.c     |   27 -----
 arch/arm/mach-kirkwood/board-ts219.c          |   40 -------
 arch/arm/mach-kirkwood/board-usi_topkick.c    |   29 -----
 22 files changed, 2 insertions(+), 834 deletions(-)
 delete mode 100644 arch/arm/mach-kirkwood/board-db88f628x-bp.c
 delete mode 100644 arch/arm/mach-kirkwood/board-dockstar.c
 delete mode 100644 arch/arm/mach-kirkwood/board-dreamplug.c
 delete mode 100644 arch/arm/mach-kirkwood/board-goflexnet.c
 delete mode 100644 arch/arm/mach-kirkwood/board-guruplug.c
 delete mode 100644 arch/arm/mach-kirkwood/board-ib62x0.c
 delete mode 100644 arch/arm/mach-kirkwood/board-iconnect.c
 delete mode 100644 arch/arm/mach-kirkwood/board-iomega_ix2_200.c
 delete mode 100644 arch/arm/mach-kirkwood/board-km_kirkwood.c
 delete mode 100644 arch/arm/mach-kirkwood/board-lsxl.c
 delete mode 100644 arch/arm/mach-kirkwood/board-mplcec4.c
 delete mode 100644 arch/arm/mach-kirkwood/board-ns2.c
 delete mode 100644 arch/arm/mach-kirkwood/board-openblocks_a6.c
 delete mode 100644 arch/arm/mach-kirkwood/board-readynas.c
 delete mode 100644 arch/arm/mach-kirkwood/board-sheevaplug.c
 delete mode 100644 arch/arm/mach-kirkwood/board-ts219.c
 delete mode 100644 arch/arm/mach-kirkwood/board-usi_topkick.c

diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
index 0f2aa61..3235808 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig
@@ -29,29 +29,7 @@ CONFIG_MACH_SHEEVAPLUG=y
 CONFIG_MACH_T5325=y
 CONFIG_MACH_TS219=y
 CONFIG_MACH_TS41X=y
-CONFIG_MACH_CLOUDBOX_DT=y
-CONFIG_MACH_DB88F628X_BP_DT=y
 CONFIG_MACH_DLINK_KIRKWOOD_DT=y
-CONFIG_MACH_DOCKSTAR_DT=y
-CONFIG_MACH_DREAMPLUG_DT=y
-CONFIG_MACH_GOFLEXNET_DT=y
-CONFIG_MACH_GURUPLUG_DT=y
-CONFIG_MACH_IB62X0_DT=y
-CONFIG_MACH_ICONNECT_DT=y
-CONFIG_MACH_INETSPACE_V2_DT=y
-CONFIG_MACH_IOMEGA_IX2_200_DT=y
-CONFIG_MACH_KM_KIRKWOOD_DT=y
-CONFIG_MACH_LSXL_DT=y
-CONFIG_MACH_MPLCEC4_DT=y
-CONFIG_MACH_NETSPACE_LITE_V2_DT=y
-CONFIG_MACH_NETSPACE_MAX_V2_DT=y
-CONFIG_MACH_NETSPACE_MINI_V2_DT=y
-CONFIG_MACH_NETSPACE_V2_DT=y
-CONFIG_MACH_NSA310_DT=y
-CONFIG_MACH_OPENBLOCKS_A6_DT=y
-CONFIG_MACH_READYNAS_DT=y
-CONFIG_MACH_SHEEVAPLUG_DT=y
-CONFIG_MACH_TOPKICK_DT=y
 CONFIG_MACH_TS219_DT=y
 # CONFIG_CPU_FEROCEON_OLD_ID is not set
 CONFIG_PCI_MVEBU=y
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index b634f96..493c71a 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -139,20 +139,6 @@ config ARCH_KIRKWOOD_DT
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell Kirkwood using flattened device tree.
 
-config MACH_CLOUDBOX_DT
-	bool "LaCie CloudBox NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  CloudBox NAS, using Flattened Device Tree.
-
-config MACH_DB88F628X_BP_DT
-	bool "Marvell DB-88F628x-BP Development Board (Flattened Device Tree)"
-	help
-	  Say 'Y' here if you want your kernel to support the Marvell
-	  DB-88F6281-BP and DB-88F6282-BP Development Board (Flattened
-	  Device Tree).
-
 config MACH_DLINK_KIRKWOOD_DT
 	bool "D-Link Kirkwood-based NAS (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
@@ -161,148 +147,6 @@ config MACH_DLINK_KIRKWOOD_DT
 	  Kirkwood-based D-Link NASes such as DNS-320 & DNS-325,
 	  using Flattened Device Tree.
 
-config MACH_DOCKSTAR_DT
-	bool "Seagate FreeAgent Dockstar (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Seagate FreeAgent Dockstar (Flattened Device Tree).
-
-config MACH_DREAMPLUG_DT
-	bool "Marvell DreamPlug (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell DreamPlug (Flattened Device Tree).
-
-config MACH_GOFLEXNET_DT
-	bool "Seagate GoFlex Net (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Seagate GoFlex Net (Flattened Device Tree).
-
-config MACH_GURUPLUG_DT
-	bool "Marvell GuruPlug Reference Board (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell GuruPlug Reference Board (Flattened Device Tree).
-
-config MACH_IB62X0_DT
-	bool "RaidSonic IB-NAS6210, IB-NAS6220 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  RaidSonic IB-NAS6210 & IB-NAS6220 devices, using
-	  Flattened Device Tree.
-
-config MACH_ICONNECT_DT
-	bool "Iomega Iconnect (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here to enable Iomega Iconnect support.
-
-config MACH_INETSPACE_V2_DT
-	bool "LaCie Internet Space v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Internet Space v2 NAS, using Flattened Device Tree.
-
-config MACH_IOMEGA_IX2_200_DT
-	bool "Iomega StorCenter ix2-200 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Iomega StorCenter ix2-200 (Flattened Device Tree).
-
-config MACH_KM_KIRKWOOD_DT
-	bool "Keymile Kirkwood Reference Design (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Keymile Kirkwood Reference Desgin, using Flattened Device Tree.
-
-config MACH_LSXL_DT
-	bool "Buffalo Linkstation LS-XHL, LS-CHLv2 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	select POWER_RESET_RESTART
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Buffalo Linkstation LS-XHL & LS-CHLv2 devices, using
-	  Flattened Device Tree.
-
-config MACH_MPLCEC4_DT
-	bool "MPL CEC4 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  MPL CEC4 (Flattened Device Tree).
-
-config MACH_NETSPACE_LITE_V2_DT
-	bool "LaCie Network Space Lite v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space Lite v2 NAS, using Flattened Device Tree.
-
-config MACH_NETSPACE_MAX_V2_DT
-	bool "LaCie Network Space Max v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space Max v2 NAS, using Flattened Device Tree.
-
-config MACH_NETSPACE_MINI_V2_DT
-	bool "LaCie Network Space Mini v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space Mini v2 NAS using Flattened Device Tree.
-
-	  This board is embedded in a product named CloudBox, which
-	  provides automatic backup on a 100GB cloud storage. This
-	  should not confused with a more recent LaCie NAS also named
-	  CloudBox. For this last, the disk capacity is 1TB or above.
-
-config MACH_NETSPACE_V2_DT
-	bool "LaCie Network Space v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space v2 NAS, using Flattened Device Tree.
-
-config MACH_OPENBLOCKS_A6_DT
-	bool "Plat'Home OpenBlocks A6 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Plat'Home OpenBlocks A6 (Flattened Device Tree).
-
-config MACH_READYNAS_DT
-	bool "NETGEAR ReadyNAS Duo v2 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	select ARM_APPENDED_DTB
-	select ARM_ATAG_DTB_COMPAT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  NETGEAR ReadyNAS Duo v2 using Fattened Device Tree.
-
-config MACH_SHEEVAPLUG_DT
-	bool "Marvell (eSATA) SheevaPlug (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell (eSATA) SheevaPlug (Flattened Device Tree).
-
-config MACH_TOPKICK_DT
-	bool "USI Topkick (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  USI Topkick, using Flattened Device Tree
-
 config MACH_TS219_DT
 	bool "Device Tree for QNAP TS-11X, TS-21X NAS"
 	select ARCH_KIRKWOOD_DT
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index ac4cd75..062f8c7 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -19,26 +19,5 @@ obj-$(CONFIG_MACH_TS219)		+= ts219-setup.o tsx1x-common.o
 obj-$(CONFIG_MACH_TS41X)		+= ts41x-setup.o tsx1x-common.o
 
 obj-$(CONFIG_ARCH_KIRKWOOD_DT)		+= board-dt.o
-obj-$(CONFIG_MACH_CLOUDBOX_DT)		+= board-ns2.o
-obj-$(CONFIG_MACH_DB88F628X_BP_DT)	+= board-db88f628x-bp.o
 obj-$(CONFIG_MACH_DLINK_KIRKWOOD_DT)	+= board-dnskw.o
-obj-$(CONFIG_MACH_DOCKSTAR_DT)		+= board-dockstar.o
-obj-$(CONFIG_MACH_DREAMPLUG_DT)		+= board-dreamplug.o
-obj-$(CONFIG_MACH_GOFLEXNET_DT)		+= board-goflexnet.o
-obj-$(CONFIG_MACH_GURUPLUG_DT)		+= board-guruplug.o
-obj-$(CONFIG_MACH_IB62X0_DT)		+= board-ib62x0.o
-obj-$(CONFIG_MACH_ICONNECT_DT)		+= board-iconnect.o
-obj-$(CONFIG_MACH_INETSPACE_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_IOMEGA_IX2_200_DT)	+= board-iomega_ix2_200.o
-obj-$(CONFIG_MACH_KM_KIRKWOOD_DT)	+= board-km_kirkwood.o
-obj-$(CONFIG_MACH_LSXL_DT)		+= board-lsxl.o
-obj-$(CONFIG_MACH_MPLCEC4_DT)		+= board-mplcec4.o
-obj-$(CONFIG_MACH_NETSPACE_LITE_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_NETSPACE_MAX_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_NETSPACE_MINI_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_NETSPACE_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_OPENBLOCKS_A6_DT)	+= board-openblocks_a6.o
-obj-$(CONFIG_MACH_READYNAS_DT)		+= board-readynas.o
-obj-$(CONFIG_MACH_SHEEVAPLUG_DT)	+= board-sheevaplug.o
-obj-$(CONFIG_MACH_TOPKICK_DT)		+= board-usi_topkick.o
-obj-$(CONFIG_MACH_TS219_DT)		+= board-ts219.o tsx1x-common.o
+obj-$(CONFIG_MACH_TS219_DT)		+= tsx1x-common.o
diff --git a/arch/arm/mach-kirkwood/board-db88f628x-bp.c b/arch/arm/mach-kirkwood/board-db88f628x-bp.c
deleted file mode 100644
index 2f574bc..0000000
--- a/arch/arm/mach-kirkwood/board-db88f628x-bp.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * Saeed Bishara <saeed at marvell.com>
- *
- * Marvell DB-88F628{1,2}-BP Development Board Setup
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/of.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data db88f628x_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init db88f628x_init(void)
-{
-	kirkwood_ge00_init(&db88f628x_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-dnskw.c b/arch/arm/mach-kirkwood/board-dnskw.c
index a1aa87f..2af7a95 100644
--- a/arch/arm/mach-kirkwood/board-dnskw.c
+++ b/arch/arm/mach-kirkwood/board-dnskw.c
@@ -14,14 +14,9 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
 #include <linux/gpio.h>
 #include "common.h"
 
-static struct mv643xx_eth_platform_data dnskw_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
 /* Register any GPIO for output and set the value */
 static void __init dnskw_gpio_register(unsigned gpio, char *name, int def)
 {
@@ -36,8 +31,6 @@ static void __init dnskw_gpio_register(unsigned gpio, char *name, int def)
 
 void __init dnskw_init(void)
 {
-	kirkwood_ge00_init(&dnskw_ge00_data);
-
 	/* Set NAS to turn back on after a power failure */
 	dnskw_gpio_register(37, "dnskw:power:recover", 1);
 }
diff --git a/arch/arm/mach-kirkwood/board-dockstar.c b/arch/arm/mach-kirkwood/board-dockstar.c
deleted file mode 100644
index d7196db..0000000
--- a/arch/arm/mach-kirkwood/board-dockstar.c
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-dockstar.c
- *
- * Seagate FreeAgent Dockstar Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- *
- * Copied and modified for Seagate GoFlex Net support by
- * Joshua Coombs <josh.coombs at gmail.com> based on ArchLinux ARM's
- * GoFlex kernel patches.
- *
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data dockstar_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init dockstar_dt_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&dockstar_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-dreamplug.c b/arch/arm/mach-kirkwood/board-dreamplug.c
deleted file mode 100644
index 0903242..0000000
--- a/arch/arm/mach-kirkwood/board-dreamplug.c
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Copyright 2012 (C), Jason Cooper <jason at lakedaemon.net>
- *
- * arch/arm/mach-kirkwood/board-dreamplug.c
- *
- * Marvell DreamPlug Reference Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/gpio.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data dreamplug_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data dreamplug_ge01_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(1),
-};
-
-void __init dreamplug_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&dreamplug_ge00_data);
-	kirkwood_ge01_init(&dreamplug_ge01_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 6e122ed..a3271f6 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -102,96 +102,14 @@ static void __init kirkwood_dt_init(void)
 	kexec_reinit = kirkwood_enable_pcie;
 #endif
 
-	if (of_machine_is_compatible("globalscale,dreamplug"))
-		dreamplug_init();
-
-	if (of_machine_is_compatible("globalscale,guruplug"))
-		guruplug_dt_init();
-
-	if (of_machine_is_compatible("globalscale,sheevaplug"))
-		sheevaplug_dt_init();
-
 	if (of_machine_is_compatible("dlink,dns-kirkwood"))
 		dnskw_init();
 
-	if (of_machine_is_compatible("iom,iconnect"))
-		iconnect_init();
-
-	if (of_machine_is_compatible("raidsonic,ib-nas62x0"))
-		ib62x0_init();
-
-	if (of_machine_is_compatible("qnap,ts219"))
-		qnap_dt_ts219_init();
-
-	if (of_machine_is_compatible("seagate,dockstar"))
-		dockstar_dt_init();
-
-	if (of_machine_is_compatible("seagate,goflexnet"))
-		goflexnet_init();
-
-	if (of_machine_is_compatible("buffalo,lsxl"))
-		lsxl_init();
-
-	if (of_machine_is_compatible("iom,ix2-200"))
-		iomega_ix2_200_init();
-
-	if (of_machine_is_compatible("keymile,km_kirkwood"))
-		km_kirkwood_init();
-
-	if (of_machine_is_compatible("lacie,cloudbox") ||
-	    of_machine_is_compatible("lacie,inetspace_v2") ||
-	    of_machine_is_compatible("lacie,netspace_lite_v2") ||
-	    of_machine_is_compatible("lacie,netspace_max_v2") ||
-	    of_machine_is_compatible("lacie,netspace_mini_v2") ||
-	    of_machine_is_compatible("lacie,netspace_v2"))
-		ns2_init();
-
-	if (of_machine_is_compatible("marvell,db-88f6281-bp") ||
-	    of_machine_is_compatible("marvell,db-88f6282-bp"))
-		db88f628x_init();
-
-	if (of_machine_is_compatible("mpl,cec4"))
-		mplcec4_init();
-
-	if (of_machine_is_compatible("netgear,readynas-duo-v2"))
-		netgear_readynas_init();
-
-	if (of_machine_is_compatible("plathome,openblocks-a6"))
-		openblocks_a6_init();
-
-	if (of_machine_is_compatible("usi,topkick"))
-		usi_topkick_init();
-
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
 static const char * const kirkwood_dt_board_compat[] = {
-	"globalscale,dreamplug",
-	"globalscale,guruplug",
-	"globalscale,sheevaplug",
-	"dlink,dns-320",
-	"dlink,dns-325",
-	"iom,iconnect",
-	"raidsonic,ib-nas62x0",
-	"qnap,ts219",
-	"seagate,dockstar",
-	"seagate,goflexnet",
-	"buffalo,lsxl",
-	"iom,ix2-200",
-	"keymile,km_kirkwood",
-	"lacie,cloudbox",
-	"lacie,inetspace_v2",
-	"lacie,netspace_lite_v2",
-	"lacie,netspace_max_v2",
-	"lacie,netspace_mini_v2",
-	"lacie,netspace_v2",
-	"marvell,db-88f6281-bp",
-	"marvell,db-88f6282-bp",
-	"mpl,cec4",
-	"netgear,readynas-duo-v2",
-	"plathome,openblocks-a6",
-	"usi,topkick",
-	"zyxel,nsa310",
+	"marvell,kirkwood",
 	NULL
 };
 
diff --git a/arch/arm/mach-kirkwood/board-goflexnet.c b/arch/arm/mach-kirkwood/board-goflexnet.c
deleted file mode 100644
index 9db979a..0000000
--- a/arch/arm/mach-kirkwood/board-goflexnet.c
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * Copyright 2012 (C), Jason Cooper <jason at lakedaemon.net>
- *
- * arch/arm/mach-kirkwood/board-goflexnet.c
- *
- * Seagate GoFlext Net Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- *
- * Copied and modified for Seagate GoFlex Net support by
- * Joshua Coombs <josh.coombs at gmail.com> based on ArchLinux ARM's
- * GoFlex kernel patches.
- *
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data goflexnet_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init goflexnet_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&goflexnet_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-guruplug.c b/arch/arm/mach-kirkwood/board-guruplug.c
deleted file mode 100644
index a857163..0000000
--- a/arch/arm/mach-kirkwood/board-guruplug.c
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-guruplug.c
- *
- * Marvell Guruplug Reference Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/gpio.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data guruplug_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data guruplug_ge01_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(1),
-};
-
-void __init guruplug_dt_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&guruplug_ge00_data);
-	kirkwood_ge01_init(&guruplug_ge01_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-ib62x0.c b/arch/arm/mach-kirkwood/board-ib62x0.c
deleted file mode 100644
index 9a857ae..0000000
--- a/arch/arm/mach-kirkwood/board-ib62x0.c
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * Copyright 2012 (C), Simon Baatz <gmbnomis at gmail.com>
- *
- * arch/arm/mach-kirkwood/board-ib62x0.c
- *
- * RaidSonic ICY BOX IB-NAS6210 & IB-NAS6220 init for drivers not
- * converted to flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data ib62x0_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init ib62x0_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&ib62x0_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-iconnect.c b/arch/arm/mach-kirkwood/board-iconnect.c
deleted file mode 100644
index 98b5ad1..0000000
--- a/arch/arm/mach-kirkwood/board-iconnect.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-iconnect.c
- *
- * Iomega i-connect Board Setup
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/of.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data iconnect_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(11),
-};
-
-void __init iconnect_init(void)
-{
-	kirkwood_ge00_init(&iconnect_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-iomega_ix2_200.c b/arch/arm/mach-kirkwood/board-iomega_ix2_200.c
deleted file mode 100644
index e5f7041..0000000
--- a/arch/arm/mach-kirkwood/board-iomega_ix2_200.c
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-iomega_ix2_200.c
- *
- * Iomega StorCenter ix2-200
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/ethtool.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data iomega_ix2_200_ge00_data = {
-	.phy_addr       = MV643XX_ETH_PHY_NONE,
-	.speed          = SPEED_1000,
-	.duplex         = DUPLEX_FULL,
-};
-
-static struct mv643xx_eth_platform_data iomega_ix2_200_ge01_data = {
-        .phy_addr       = MV643XX_ETH_PHY_ADDR(11),
-};
-
-void __init iomega_ix2_200_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&iomega_ix2_200_ge00_data);
-	kirkwood_ge01_init(&iomega_ix2_200_ge01_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-km_kirkwood.c b/arch/arm/mach-kirkwood/board-km_kirkwood.c
deleted file mode 100644
index 44e4605..0000000
--- a/arch/arm/mach-kirkwood/board-km_kirkwood.c
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * Copyright 2012 2012 KEYMILE AG, CH-3097 Bern
- * Valentin Longchamp <valentin.longchamp at keymile.com>
- *
- * arch/arm/mach-kirkwood/board-km_kirkwood.c
- *
- * Keymile km_kirkwood Reference Desing Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/clk.h>
-#include <linux/clk-private.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data km_kirkwood_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init km_kirkwood_init(void)
-{
-	struct clk *sata_clk;
-	/*
-	 * Our variant of kirkwood (integrated in the Bobcat) hangs on accessing
-	 * SATA bits (14-15) of the Clock Gating Control Register. Since these
-	 * devices are also not present in this variant, their clocks get
-	 * disabled because unused when clk_disable_unused() gets called.
-	 * That's why we change the flags to these clocks to CLK_IGNORE_UNUSED
-	 */
-	sata_clk = clk_get_sys("sata_mv.0", "0");
-	if (!IS_ERR(sata_clk))
-		sata_clk->flags |= CLK_IGNORE_UNUSED;
-	sata_clk = clk_get_sys("sata_mv.0", "1");
-	if (!IS_ERR(sata_clk))
-		sata_clk->flags |= CLK_IGNORE_UNUSED;
-
-	kirkwood_ge00_init(&km_kirkwood_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-lsxl.c b/arch/arm/mach-kirkwood/board-lsxl.c
deleted file mode 100644
index 3483952..0000000
--- a/arch/arm/mach-kirkwood/board-lsxl.c
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * Copyright 2012 (C), Michael Walle <michael at walle.cc>
- *
- * arch/arm/mach-kirkwood/board-lsxl.c
- *
- * Buffalo Linkstation LS-XHL and LS-CHLv2 init for drivers not
- * converted to flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data lsxl_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data lsxl_ge01_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init lsxl_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-
-	kirkwood_ge00_init(&lsxl_ge00_data);
-	kirkwood_ge01_init(&lsxl_ge01_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-mplcec4.c b/arch/arm/mach-kirkwood/board-mplcec4.c
deleted file mode 100644
index 938712e..0000000
--- a/arch/arm/mach-kirkwood/board-mplcec4.c
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Copyright (C) 2012 MPL AG, Switzerland
- * Stefan Peter <s.peter at mpl.ch>
- *
- * arch/arm/mach-kirkwood/board-mplcec4.c
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data mplcec4_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(1),
-};
-
-static struct mv643xx_eth_platform_data mplcec4_ge01_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(2),
-};
-
-void __init mplcec4_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&mplcec4_ge00_data);
-	kirkwood_ge01_init(&mplcec4_ge01_data);
-}
-
-
-
diff --git a/arch/arm/mach-kirkwood/board-ns2.c b/arch/arm/mach-kirkwood/board-ns2.c
deleted file mode 100644
index f8f6605..0000000
--- a/arch/arm/mach-kirkwood/board-ns2.c
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Copyright 2012 (C), Simon Guinot <simon.guinot at sequanux.org>
- *
- * arch/arm/mach-kirkwood/board-ns2.c
- *
- * LaCie Network Space v2 board (and parents) initialization for drivers
- * not converted to flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/of.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data ns2_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init ns2_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	if (of_machine_is_compatible("lacie,cloudbox") ||
-	    of_machine_is_compatible("lacie,netspace_lite_v2") ||
-	    of_machine_is_compatible("lacie,netspace_mini_v2"))
-		ns2_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
-	kirkwood_ge00_init(&ns2_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-openblocks_a6.c b/arch/arm/mach-kirkwood/board-openblocks_a6.c
deleted file mode 100644
index b11d8fd..0000000
--- a/arch/arm/mach-kirkwood/board-openblocks_a6.c
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * Copyright 2012 Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
- *
- * arch/arm/mach-kirkwood/board-openblocks_a6.c
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data openblocks_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init openblocks_a6_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&openblocks_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-readynas.c b/arch/arm/mach-kirkwood/board-readynas.c
deleted file mode 100644
index 341b82d..0000000
--- a/arch/arm/mach-kirkwood/board-readynas.c
+++ /dev/null
@@ -1,27 +0,0 @@
-/*
- * NETGEAR ReadyNAS Duo v2 Board setup for drivers not already
- * converted to DT.
- *
- * Copyright (C) 2013, Arnaud EBALARD <arno at natisbad.org>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
-#include <mach/kirkwood.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data netgear_readynas_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init netgear_readynas_init(void)
-{
-	kirkwood_ge00_init(&netgear_readynas_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-sheevaplug.c b/arch/arm/mach-kirkwood/board-sheevaplug.c
deleted file mode 100644
index fa38937..0000000
--- a/arch/arm/mach-kirkwood/board-sheevaplug.c
+++ /dev/null
@@ -1,27 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-sheevaplug.c
- *
- * Marvell Sheevaplug Reference Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data sheevaplug_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init sheevaplug_dt_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&sheevaplug_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
deleted file mode 100644
index 860f44a..0000000
--- a/arch/arm/mach-kirkwood/board-ts219.c
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- *
- * QNAP TS-11x/TS-21x Turbo NAS Board Setup via DT
- *
- * Copyright (C) 2012 Andrew Lunn <andrew at lunn.ch>
- *
- * Based on the board file ts219-setup.c:
- *
- * Copyright (C) 2009  Martin Michlmayr <tbm at cyrius.com>
- * Copyright (C) 2008  Byron Bradley <byron.bbradley at gmail.com>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <mach/kirkwood.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data qnap_ts219_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init qnap_dt_ts219_init(void)
-{
-	u32 dev, rev;
-
-	kirkwood_pcie_id(&dev, &rev);
-	if (dev == MV88F6282_DEV_ID)
-		qnap_ts219_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
-
-	kirkwood_ge00_init(&qnap_ts219_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-usi_topkick.c b/arch/arm/mach-kirkwood/board-usi_topkick.c
deleted file mode 100644
index 1cc04ec..0000000
--- a/arch/arm/mach-kirkwood/board-usi_topkick.c
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * Copyright 2012 (C), Jason Cooper <jason at lakedaemon.net>
- *
- * arch/arm/mach-kirkwood/board-usi_topkick.c
- *
- * USI Topkick Init for drivers not converted to flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/gpio.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data topkick_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init usi_topkick_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&topkick_ge00_data);
-}
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


From sebastian.hesselbarth at gmail.com  Wed Jul  3 07:31:47 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Wed, 03 Jul 2013 13:31:47 +0200
Subject: [PATCH v6 5/7] ARM: kirkwood: remove redundant DT board files
In-Reply-To: <87k3l8v9s1.fsf@natisbad.org>
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1372762824-12202-6-git-send-email-sebastian.hesselbarth@gmail.com>
 <87k3l8v9s1.fsf@natisbad.org>
Message-ID: <51D40BA3.6000603@gmail.com>

On 07/03/13 01:09, Arnaud Ebalard wrote:
> Hi Sebastian,
>
> Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> writes:
>
>> With DT support for mv643xx_eth board specific init for some boards now
>> is unneccessary. Remove those board files, Kconfig entries, and
>> corresponding entries in kirkwood_defconfig.
>
> Applying above your set an old quilt cleaning patch Jason asked at some
> point, it became empty except for arch/arm/mach_kirkwood/common.h in
> which some declarations were left behind. If this is correct, can you
> just merge the hunks below in your 5/7 in next round?
>
> AFAICT, only dnskw_init() remains, which matches the list of board-*.c
> files in arch/arm/mach_kirkwood/ (i.e. board-dt.c and board-dnskw.c).

While updating the patch with yours, I stumbled upon MACH_TS219_DT that
also remains because it includes tsx1x-common.c.

I cannot recall if Jason or Andrew said something about removing it..

Sebastian


From tony at atomide.com  Wed Jul  3 07:33:34 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Jul 2013 04:33:34 -0700
Subject: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations
 for pdata clocks
In-Reply-To: <1372796850.21065.93.camel@cumari.coelho.fi>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-5-git-send-email-coelho@ti.com>
 <20130702150208.GA4233@kahuna>
 <1372796850.21065.93.camel@cumari.coelho.fi>
Message-ID: <20130703113334.GY5523@atomide.com>

* Luciano Coelho <coelho at ti.com> [130702 13:33]:
> On Tue, 2013-07-02 at 10:02 -0500, Nishanth Menon wrote:
> > On 17:55-20130702, Luciano Coelho wrote:
> > > Instead of defining an enumeration with the FW specific values for the
> > > different clock rates, use the actual frequency instead.  Also add a
> > > boolean to specify whether the clock is XTAL or not.
> > > 
> > > Change all board files to reflect this.
> > > 
> > > Cc: Tony Lindgren <tony at atomide.com>
> > > Cc: Sekhar Nori <nsekhar at ti.com>
> > > Signed-off-by: Luciano Coelho <coelho at ti.com>
> > > ---
> > >  arch/arm/mach-davinci/board-da850-evm.c      |    3 +-
> > >  arch/arm/mach-omap2/board-4430sdp.c          |    5 ++-
> > ^^
> > >  arch/arm/mach-omap2/board-omap3evm.c         |    3 +-
> > >  arch/arm/mach-omap2/board-omap4panda.c       |    3 +-
> > ^^
> > Please do not add more platform data to platforms that are DT only.
> 
> Ah, I hadn't realized that board_omap4panda.c and board-4430sdp.c had
> been removed in linux-next.  I base my tree on wireless-next and it
> doesn't contain these changes yet.  I would only have noticed this when
> I rebased my tree once the merge window is closed. ;)
> 
> Thanks for pointing out, I'll make sure these changes will not be there
> when I send the pull request.

Please separate out the minimal pdata and arch/arm/mach-omap2 changes int
a immutable branch on v3.11-rc1 that I can also pull in. For v3.12, we're
going to be making more boards device tree only, so these changes may
otherwise cause pointless merge conflicts.

Regards,

Tony


From arnd at arndb.de  Wed Jul  3 08:04:02 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 3 Jul 2013 14:04:02 +0200
Subject: [PATCH v5 00/12] MBus DT binding: A new hope
In-Reply-To: <20130702195524.GA14547@obsidianresearch.com>
References: <1372532655-20321-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130702195524.GA14547@obsidianresearch.com>
Message-ID: <201307031404.02930.arnd@arndb.de>

On Tuesday 02 July 2013, Jason Gunthorpe wrote:
> On Sat, Jun 29, 2013 at 04:04:03PM -0300, Ezequiel Garcia wrote:

> > Personally, I can't see any disadvantage, and the binding looks much
> > cleaner now. But of course I can be wrong, and I'm open to discussion.
> > 
> > There's another pending issue. Arnd Bergmann has required to add a
> > property to specify the available space within the CPU address space
> > for decoding windows. This property would allow to support fully
> > dynamic mbus window allocation.
> 
> I wonder if this range is implied - eg it is address space not covered
> by the memory node or any mbus ranges? Is there a situation where that
> is not sufficient?

I think it's sufficient, yes. It feels odd to have the mbus code rely
on the contents of the memory node for that, but it would work.

	Arnd


From coelho at ti.com  Wed Jul  3 08:14:34 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 3 Jul 2013 15:14:34 +0300
Subject: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations
 for pdata clocks
In-Reply-To: <20130703113334.GY5523@atomide.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <1372776948-24840-5-git-send-email-coelho@ti.com>
 <20130702150208.GA4233@kahuna> <1372796850.21065.93.camel@cumari.coelho.fi>
 <20130703113334.GY5523@atomide.com>
Message-ID: <1372853674.21065.106.camel@cumari.coelho.fi>

On Wed, 2013-07-03 at 04:33 -0700, Tony Lindgren wrote:
> * Luciano Coelho <coelho at ti.com> [130702 13:33]:
> > On Tue, 2013-07-02 at 10:02 -0500, Nishanth Menon wrote:
> > > On 17:55-20130702, Luciano Coelho wrote:
> > > > Instead of defining an enumeration with the FW specific values for the
> > > > different clock rates, use the actual frequency instead.  Also add a
> > > > boolean to specify whether the clock is XTAL or not.
> > > > 
> > > > Change all board files to reflect this.
> > > > 
> > > > Cc: Tony Lindgren <tony at atomide.com>
> > > > Cc: Sekhar Nori <nsekhar at ti.com>
> > > > Signed-off-by: Luciano Coelho <coelho at ti.com>
> > > > ---
> > > >  arch/arm/mach-davinci/board-da850-evm.c      |    3 +-
> > > >  arch/arm/mach-omap2/board-4430sdp.c          |    5 ++-
> > > ^^
> > > >  arch/arm/mach-omap2/board-omap3evm.c         |    3 +-
> > > >  arch/arm/mach-omap2/board-omap4panda.c       |    3 +-
> > > ^^
> > > Please do not add more platform data to platforms that are DT only.
> > 
> > Ah, I hadn't realized that board_omap4panda.c and board-4430sdp.c had
> > been removed in linux-next.  I base my tree on wireless-next and it
> > doesn't contain these changes yet.  I would only have noticed this when
> > I rebased my tree once the merge window is closed. ;)
> > 
> > Thanks for pointing out, I'll make sure these changes will not be there
> > when I send the pull request.
> 
> Please separate out the minimal pdata and arch/arm/mach-omap2 changes int
> a immutable branch on v3.11-rc1 that I can also pull in. For v3.12, we're
> going to be making more boards device tree only, so these changes may
> otherwise cause pointless merge conflicts.

Okay.  I don't want to freeze my work, I'll continue using my
wireless-based tree (which is based on 3.10) for now.  When the merge
window closes, I'll reorganize all this before sending pull requests, so
we can avoid conflicts.

Please ignore my changes to board files that will disappear on 3.11 and
keep reviewing the rest. ;)

--
Cheers,
Luca.



From dirk.behme at de.bosch.com  Wed Jul  3 08:18:26 2013
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Wed, 3 Jul 2013 14:18:26 +0200
Subject: [PATCH] ARM: i.MX6Q: correct emi_sel clock muxing
In-Reply-To: <1372836720-24660-1-git-send-email-shawn.guo@linaro.org>
References: <1372836720-24660-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <51D41692.5090306@de.bosch.com>

On 03.07.2013 09:32, Shawn Guo wrote:
> From: Liu Ying <Ying.Liu at freescale.com>
>
> The correct muxing for emi_sel clock should be
> 2b'00 - 396M PFD
> 2b'01 - PLL3
> 2b'10 - AXI clk root
> 2b'11 - 352M PFD
>
> This patch corrects the muxing in the clock driver.
>
> Signed-off-by: Liu Ying <Ying.Liu at freescale.com>
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>

Acked-by: Dirk Behme <dirk.behme at de.bosch.com>

Thanks

Dirk

> ---
>   arch/arm/mach-imx/clk-imx6q.c |    5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
> index 4282e99f..86567d9 100644
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -199,7 +199,8 @@ static const char *pcie_axi_sels[]	= { "axi", "ahb", };
>   static const char *ssi_sels[]		= { "pll3_pfd2_508m", "pll3_pfd3_454m", "pll4_post_div", };
>   static const char *usdhc_sels[]	= { "pll2_pfd2_396m", "pll2_pfd0_352m", };
>   static const char *enfc_sels[]	= { "pll2_pfd0_352m", "pll2_bus", "pll3_usb_otg", "pll2_pfd2_396m", };
> -static const char *emi_sels[]		= { "axi", "pll3_usb_otg", "pll2_pfd2_396m", "pll2_pfd0_352m", };
> +static const char *emi_sels[]		= { "pll2_pfd2_396m", "pll3_usb_otg", "axi", "pll2_pfd0_352m", };
> +static const char *emi_slow_sels[]      = { "axi", "pll3_usb_otg", "pll2_pfd2_396m", "pll2_pfd0_352m", };
>   static const char *vdo_axi_sels[]	= { "axi", "ahb", };
>   static const char *vpu_axi_sels[]	= { "axi", "pll2_pfd2_396m", "pll2_pfd0_352m", };
>   static const char *cko1_sels[]	= { "pll3_usb_otg", "pll2_bus", "pll1_sys", "pll5_video_div",
> @@ -392,7 +393,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
>   	clk[usdhc4_sel]       = imx_clk_mux("usdhc4_sel",       base + 0x1c, 19, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels));
>   	clk[enfc_sel]         = imx_clk_mux("enfc_sel",         base + 0x2c, 16, 2, enfc_sels,         ARRAY_SIZE(enfc_sels));
>   	clk[emi_sel]          = imx_clk_mux("emi_sel",          base + 0x1c, 27, 2, emi_sels,          ARRAY_SIZE(emi_sels));
> -	clk[emi_slow_sel]     = imx_clk_mux("emi_slow_sel",     base + 0x1c, 29, 2, emi_sels,          ARRAY_SIZE(emi_sels));
> +	clk[emi_slow_sel]     = imx_clk_mux("emi_slow_sel",     base + 0x1c, 29, 2, emi_slow_sels,     ARRAY_SIZE(emi_slow_sels));
>   	clk[vdo_axi_sel]      = imx_clk_mux("vdo_axi_sel",      base + 0x18, 11, 1, vdo_axi_sels,      ARRAY_SIZE(vdo_axi_sels));
>   	clk[vpu_axi_sel]      = imx_clk_mux("vpu_axi_sel",      base + 0x18, 14, 2, vpu_axi_sels,      ARRAY_SIZE(vpu_axi_sels));
>   	clk[cko1_sel]         = imx_clk_mux("cko1_sel",         base + 0x60, 0,  4, cko1_sels,         ARRAY_SIZE(cko1_sels));


From richard.genoud at gmail.com  Wed Jul  3 08:21:06 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Wed, 3 Jul 2013 14:21:06 +0200
Subject: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
In-Reply-To: <51D29927.80900@atmel.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-2-git-send-email-richard.genoud@gmail.com>
 <51D24299.9050209@atmel.com>
 <CACQ1gAgcc=j3kmcpjp8bbdHhxr_k=h8jJs6R_paJbPUMv74uGg@mail.gmail.com>
 <51D29927.80900@atmel.com>
Message-ID: <CACQ1gAhnDk-qSt_5xrsMakXqGGDO5pEbA-9UDWCJG=AABDc+zg@mail.gmail.com>

2013/7/2 Bo Shen <voice.shen at atmel.com>:
> Hi Richard,
>
>
> On 7/2/2013 16:13, Richard Genoud wrote:
>>>
>>> Please hold on of this, as to the ASoC dmaengine will deal with this. So,
>>> we
>>> >not need do it manually.
>>> >
>>> >Now, I am working on it. And will send out the patch soon after testing
>>> > OK.
>>
>> Ok, I stay tuned !
>
>
> I think you can go on working with the two patches I send just now.
> [1]: ASoC: atmel_ssc_dai: move set dma data to startup callback
> https://patchwork.kernel.org/patch/2811241/
>
> [2]: ASoC: atmel-pcm: use generic dmaengine framework
> https://patchwork.kernel.org/patch/2811261/
>
> I use your patches 4 ~ 8 do a quick testing, it works. Please note the name
> of asound.state under /etc in your rootfs should the same with atmel,model
> in patch 6.

Thanks for testing !
I was just doing the same test, it works with
aplay  -Dplug:default  good_music.wav

but there's a violent hang (kernel stops, no trace) when I try the record :
arecord -v -V stereo -Dplug:default -f cd -t wav -c 2 /tmp/toto.wav
last thing I see is :
dma dma0chan3: atc_control (3)

I'll try to trace that.


Best regards,
Richard.


From arnd at arndb.de  Wed Jul  3 08:29:41 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 3 Jul 2013 14:29:41 +0200
Subject: [PATCH 00/08] ARM: shmobile: EMEV2 and KZM9D update
In-Reply-To: <20130702092725.32066.54861.sendpatchset@w520>
References: <20130702092725.32066.54861.sendpatchset@w520>
Message-ID: <201307031429.41711.arnd@arndb.de>

On Tuesday 02 July 2013, Magnus Damm wrote:
> ARM: shmobile: EMEV2 and KZM9D update
> 
> [PATCH 01/08] ARM: shmobile: Remove unused EMEV2/KZM9D early console
> [PATCH 02/08] ARM: shmobile: Update KZM9D dts command line
> [PATCH 03/08] ARM: shmobile: Make EMEV2 platform devices more compact
> [PATCH 04/08] ARM: shmobile: Add GIO to EMEV2 dtsi
> [PATCH 05/08] ARM: shmobile: Use DT for GIC on EMEV2 and KZM9D
> [PATCH 06/08] ARM: shmobile: Use DT for SMP on EMEV2 and KZM9D
> [PATCH 07/08] ARM: shmobile: EMEV2 map_io update
> [PATCH 08/08] ARM: shmobile: Disconnect EMEV2 SMP code from clocks
> 
> Several minor updates for the EMEV2 SoC and the KZM9D board:
> - Get rid of early console - the 8250-em driver does not support it
> - Update command line in DTS and remove old cruft
> - Make the EMEV2 platform devices more compact
> - Add GIO device nodes to the EMEV2 dtsi
> - Use DT for GIC and SMP for both regular KZM9D board code and DT
> - Reduce the size of the EMEV2 map_io - SCU is still however needed
> - Allow EMEV2 SMP to operate without legacy clock bits

Looks all good to me,

Acked-by: Arnd Bergmann <arnd at arndb.de>


From arnd at arndb.de  Wed Jul  3 08:35:05 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 3 Jul 2013 14:35:05 +0200
Subject: [GIT PULL 0/2] Renesas ARM based SoC fixes for v3.11
In-Reply-To: <cover.1372739438.git.horms+renesas@verge.net.au>
References: <cover.1372739438.git.horms+renesas@verge.net.au>
Message-ID: <201307031435.05949.arnd@arndb.de>

On Tuesday 02 July 2013, Simon Horman wrote:
> --------------------------------------------------
> Renesas ARM based SoC fixes for v3.11
> 
> * Correct GIO3 base addresses for EMEV2 SoC
>   - This bug bug added when GPIO support was added for the EMEV2 SoC
>     in v3.5
> 
> * Correct SCIFB0 resources for r8a77a4 SoC
>   - This was a bug was added when SCIF support was added for the r8a77a4 SoC
>     in v3.10
> 

Pulled into the fixes branch, thanks!

	Arnd


From arnd at arndb.de  Wed Jul  3 08:39:37 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 3 Jul 2013 14:39:37 +0200
Subject: [PATCH] ARM: tegra: fix VBUS regulator GPIO polarity in DT
In-Reply-To: <1372712825-13757-1-git-send-email-swarren@wwwdotorg.org>
References: <1372712825-13757-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <201307031439.38070.arnd@arndb.de>

On Monday 01 July 2013, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> Commit 4c94c8b "ARM: tegra: update device trees for USB binding rework"
> added regulator definitions for GPIO-controlled USB VBUS. However, none
> of these contained the essential DT property enable-active-high. Add
> this so that the regulator definitions are correct.
> 
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> ---
> I'm sending this to arm-soc to be taken into v3.11-rc1. However, if it
> won't get in until -rc2, let me know; I'd be tempted not to fix it in
> 3.11 in that case, so I don't have to wait until v3.11-rc2 before
> applying patches that use these new regulators, since they rely on this
> fix going in first.

Applied to fixes branch, thanks!

	Arnd


From cb at sgoc.de  Wed Jul  3 08:39:11 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Wed,  3 Jul 2013 14:39:11 +0200
Subject: [PATCH 0/3] Added support for On Chip OTP in i.MX23/28
Message-ID: <1372855154-8422-1-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <cb at sgoc.de>

This patch contains the ported driver from Freescale for the On Chip OTP
cells in the i.MX23 and i.MX28. The OTP cells can be read and written via
files in /sys/fsl_otp.

Christoph G. Baumann (3):
  Added support for On Chip OTP in i.MX23/28
  Added support for On Chip OTP in i.MX23/28
  Added support for On Chip OTP in i.MX23/28

 arch/arm/boot/dts/imx28.dtsi                |    1 -
 arch/arm/mach-mxs/include/mach/mx23-ocotp.h |  311 +++++++++++++++++++++++++++
 arch/arm/mach-mxs/include/mach/mx28-ocotp.h |  239 ++++++++++++++++++++
 drivers/clk/mxs/clk-imx23.c                 |    2 +
 drivers/clk/mxs/clk-imx28.c                 |    1 +
 drivers/misc/Kconfig                        |   14 ++
 drivers/misc/Makefile                       |    1 +
 drivers/misc/fsl_otp.c                      |  249 +++++++++++++++++++++
 drivers/misc/fsl_otp.h                      |  201 +++++++++++++++++
 9 files changed, 1018 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-mxs/include/mach/mx23-ocotp.h
 create mode 100644 arch/arm/mach-mxs/include/mach/mx28-ocotp.h
 create mode 100644 drivers/misc/fsl_otp.c
 create mode 100644 drivers/misc/fsl_otp.h

-- 
1.7.9.5



From cb at sgoc.de  Wed Jul  3 08:39:14 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Wed,  3 Jul 2013 14:39:14 +0200
Subject: [PATCH 3/3] Added support for On Chip OTP in i.MX23/28
In-Reply-To: <1372855154-8422-1-git-send-email-cb@sgoc.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
Message-ID: <1372855154-8422-4-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <cb at sgoc.de>

Signed-off-by: Christoph G. Baumann <cb at sgoc.de>
---
 arch/arm/boot/dts/imx28.dtsi |    1 -
 drivers/clk/mxs/clk-imx23.c  |    2 ++
 drivers/clk/mxs/clk-imx28.c  |    1 +
 drivers/misc/Kconfig         |   14 ++++++++++++++
 drivers/misc/Makefile        |    1 +
 5 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 600f7cb..e9de86b 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -711,7 +711,6 @@
 			ocotp at 8002c000 {
 				compatible = "fsl,ocotp";
 				reg = <0x8002c000 0x2000>;
-				status = "disabled";
 			};
 
 			axi-ahb at 8002e000 {
diff --git a/drivers/clk/mxs/clk-imx23.c b/drivers/clk/mxs/clk-imx23.c
index f6a7487..ec76d00 100644
--- a/drivers/clk/mxs/clk-imx23.c
+++ b/drivers/clk/mxs/clk-imx23.c
@@ -168,6 +168,8 @@ int __init mx23_clocks_init(void)
 	clk_data.clk_num = ARRAY_SIZE(clks);
 	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
 
+	clk_register_clkdev(clks[hbus], NULL, "hbus");
+
 	for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
 		clk_prepare_enable(clks[clks_init_on[i]]);
 
diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c
index 4faf0af..792fcaf 100644
--- a/drivers/clk/mxs/clk-imx28.c
+++ b/drivers/clk/mxs/clk-imx28.c
@@ -247,6 +247,7 @@ int __init mx28_clocks_init(void)
 	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
 
 	clk_register_clkdev(clks[enet_out], NULL, "enet_out");
+	clk_register_clkdev(clks[hbus], NULL, "hbus");
 
 	for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
 		clk_prepare_enable(clks[clks_init_on[i]]);
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index c002d86..b44ef48 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -527,6 +527,20 @@ config SRAM
 	  the genalloc API. It is supposed to be used for small on-chip SRAM
 	  areas found on many SoCs.
 
+config FSL_OTP
+	tristate "Freescale On-Chip OTP Memory Support"
+	depends on SOC_IMX23 || SOC_IMX28
+	default n
+	help
+		If you say Y here, you will get support for a SysFS interface for
+		the One Time Programmable memory pages that are stored on the
+		iMX23/28 processor.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called fsl_otp.
+
+	  If unsure, it is safe to say N.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index c235d5b..e622e01 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_INTEL_MEI)		+= mei/
 obj-$(CONFIG_VMWARE_VMCI)	+= vmw_vmci/
 obj-$(CONFIG_LATTICE_ECP3_CONFIG)	+= lattice-ecp3-config.o
 obj-$(CONFIG_SRAM)		+= sram.o
+obj-$(CONFIG_FSL_OTP)           += fsl_otp.o
-- 
1.7.9.5



From cb at sgoc.de  Wed Jul  3 08:39:12 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Wed,  3 Jul 2013 14:39:12 +0200
Subject: [PATCH 1/3] Added support for On Chip OTP in i.MX23/28
In-Reply-To: <1372855154-8422-1-git-send-email-cb@sgoc.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
Message-ID: <1372855154-8422-2-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <cb at sgoc.de>

Signed-off-by: Christoph G. Baumann <cb at sgoc.de>
---
 drivers/misc/fsl_otp.c |  249 ++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/misc/fsl_otp.h |  201 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 450 insertions(+)
 create mode 100644 drivers/misc/fsl_otp.c
 create mode 100644 drivers/misc/fsl_otp.h

diff --git a/drivers/misc/fsl_otp.c b/drivers/misc/fsl_otp.c
new file mode 100644
index 0000000..fd1941a
--- /dev/null
+++ b/drivers/misc/fsl_otp.c
@@ -0,0 +1,249 @@
+/*
+ * Freescale On-Chip OTP driver
+ *
+ * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Ported to 3.7 by Christoph G. Baumann <cgb at debian.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ */
+#include <linux/kobject.h>
+#include <linux/string.h>
+#include <linux/sysfs.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/delay.h>
+#include <linux/fcntl.h>
+#include <linux/mutex.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+
+#include "fsl_otp.h"
+
+static DEFINE_MUTEX(otp_mutex);
+static struct kobject *otp_kobj;
+static struct attribute **attrs;
+static struct kobj_attribute *kattr;
+static struct attribute_group attr_group;
+
+static inline unsigned int get_reg_index(struct kobj_attribute *tmp)
+{
+	return tmp - kattr;
+}
+
+static int otp_wait_busy(u32 flags)
+{
+	int count;
+	u32 c;
+
+	for (count = 10000; count >= 0; count--) {
+		c = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CTRL);
+		if (!(c & (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR | flags)))
+			break;
+		cpu_relax();
+	}
+
+	if (count < 0)
+		return -ETIMEDOUT;
+	return 0;
+}
+
+static ssize_t otp_show(struct kobject *kobj, struct kobj_attribute *attr,
+		      char *buf)
+{
+	unsigned int index = get_reg_index(attr);
+	u32 value = 0;
+
+	/* sanity check */
+	if (index >= otp_data.fuse_num)
+		return 0;
+
+	mutex_lock(&otp_mutex);
+
+	if (otp_read_prepare()) {
+		mutex_unlock(&otp_mutex);
+		return 0;
+	}
+	value = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CUST_N(index));
+	otp_read_post();
+
+	mutex_unlock(&otp_mutex);
+	return sprintf(buf, "0x%x\n", value);
+}
+
+static int otp_write_bits(int addr, u32 data, u32 magic)
+{
+	u32 c; /* for control register */
+
+	/* init the control register */
+	c = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CTRL);
+	c &= ~BM_OCOTP_CTRL_ADDR;
+	c |= BF(addr, OCOTP_CTRL_ADDR);
+	c |= BF(magic, OCOTP_CTRL_WR_UNLOCK);
+	__raw_writel(c, REGS_OCOTP_BASE + HW_OCOTP_CTRL);
+
+	/* init the data register */
+	__raw_writel(data, REGS_OCOTP_BASE + HW_OCOTP_DATA);
+	otp_wait_busy(0);
+
+	mdelay(2); /* Write Postamble */
+	return 0;
+}
+
+static ssize_t otp_store(struct kobject *kobj, struct kobj_attribute *attr,
+		       const char *buf, size_t count)
+{
+	unsigned int index = get_reg_index(attr);
+	int value;
+
+	/* sanity check */
+	if (index >= otp_data.fuse_num)
+		return 0;
+
+	sscanf(buf, "0x%x", &value);
+
+	mutex_lock(&otp_mutex);
+	if (otp_write_prepare()) {
+		mutex_unlock(&otp_mutex);
+		return 0;
+	}
+	otp_write_bits(index, value, 0x3e77);
+	otp_write_post();
+	mutex_unlock(&otp_mutex);
+
+	return count;
+}
+
+static void free_otp_attr(void)
+{
+	kfree(attrs);
+	attrs = NULL;
+
+	kfree(kattr);
+	kattr = NULL;
+}
+
+static int alloc_otp_attr(void)
+{
+	int i;
+
+	/* The last one is NULL, which is used to detect the end */
+	attrs = kzalloc((otp_data.fuse_num + 1) * sizeof(attrs[0]),
+			GFP_KERNEL);
+	kattr = kzalloc(otp_data.fuse_num * sizeof(struct kobj_attribute),
+			GFP_KERNEL);
+
+	if (!attrs || !kattr)
+		goto error_out;
+
+	for (i = 0; i < otp_data.fuse_num; i++) {
+		kattr[i].attr.name = otp_data.fuse_name[i];
+		kattr[i].attr.mode = 0600;
+		kattr[i].show  = otp_show;
+		kattr[i].store = otp_store;
+		attrs[i] = &kattr[i].attr;
+		sysfs_attr_init(attrs[i]);
+	}
+	memset(&attr_group, 0, sizeof(attr_group));
+	attr_group.attrs = attrs;
+	return 0;
+
+error_out:
+	free_otp_attr();
+	return -ENOMEM;
+}
+
+static int fsl_otp_probe(struct platform_device *pdev)
+{
+	int retval;
+	struct fsl_otp_data *pdata;
+
+
+	pdata = &otp_data;
+	if (pdev->dev.platform_data == NULL)
+		pdev->dev.platform_data = &otp_data;
+
+	retval = alloc_otp_attr();
+	if (retval)
+		return retval;
+
+	retval = map_ocotp_addr(pdev);
+	if (retval)
+		goto error;
+
+	otp_kobj = kobject_create_and_add("fsl_otp", NULL);
+	if (!otp_kobj) {
+		retval = -ENOMEM;
+		goto error;
+	}
+
+	retval = sysfs_create_group(otp_kobj, &attr_group);
+	if (retval)
+		goto error;
+
+	mutex_init(&otp_mutex);
+	return 0;
+error:
+	kobject_put(otp_kobj);
+	otp_kobj = NULL;
+	free_otp_attr();
+	unmap_ocotp_addr();
+	return retval;
+}
+
+static int otp_remove(struct platform_device *pdev)
+{
+	kobject_put(otp_kobj);
+	otp_kobj = NULL;
+
+	free_otp_attr();
+	unmap_ocotp_addr();
+	return 0;
+}
+
+static const struct of_device_id mxs_otp_dt_ids[] = {
+	{ .compatible = "fsl,ocotp", .data = NULL, },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mxs_otp_dt_ids);
+
+static struct platform_driver ocotp_driver = {
+	.probe		= fsl_otp_probe,
+	.remove		= otp_remove,
+	.driver		= {
+		.name   = "ocotp",
+		.owner	= THIS_MODULE,
+		.of_match_table = mxs_otp_dt_ids,
+	},
+};
+
+static int __init fsl_otp_init(void)
+{
+	return platform_driver_register(&ocotp_driver);
+}
+
+static void __exit fsl_otp_exit(void)
+{
+	platform_driver_unregister(&ocotp_driver);
+}
+module_init(fsl_otp_init);
+module_exit(fsl_otp_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Huang Shijie <b32955 at freescale.com>");
+MODULE_DESCRIPTION("Common driver for OTP controller");
diff --git a/drivers/misc/fsl_otp.h b/drivers/misc/fsl_otp.h
new file mode 100644
index 0000000..b429479
--- /dev/null
+++ b/drivers/misc/fsl_otp.h
@@ -0,0 +1,201 @@
+/*
+ * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Ported to 3.7 by Christoph G. Baumann <cgb at debian.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+#ifndef __FREESCALE_OTP__
+#define __FREESCALE_OTP__
+
+
+static int otp_wait_busy(u32 flags);
+
+/* IMX23 and IMX28 share most of the defination ========================= */
+#if (defined(CONFIG_SOC_IMX23) || defined(CONFIG_SOC_IMX28))
+
+#if defined(CONFIG_SOC_IMX28) && defined(CONFIG_SOC_IMX23)
+#undef CONFIG_SOC_IMX23
+#endif
+
+#include <linux/regulator/consumer.h>
+#include <mach/hardware.h>
+#include <mach/mxs.h>
+
+#if defined(CONFIG_SOC_IMX23)
+#include <mach/mx23.h>
+#include <mach/mx23-ocotp.h>
+#else
+#include <mach/mx28.h>
+#include <mach/mx28-ocotp.h>
+#endif
+
+#define OCOTP_PHYS_ADDR         MXS_OCOTP_BASE_ADDR
+#define REGS_OCOTP_BASE		(MXS_IO_ADDRESS(OCOTP_PHYS_ADDR))
+#define BF(value, field)	(((value) << BP_##field) & BM_##field)
+
+#if defined(CONFIG_SOC_IMX28)
+/* Building up eight registers's names of a bank */
+#define MXS_OTP_BANK(a, b, c, d, e, f, g, h)	\
+	{\
+	("HW_OCOTP_"#a), ("HW_OCOTP_"#b), ("HW_OCOTP_"#c), ("HW_OCOTP_"#d), \
+	("HW_OCOTP_"#e), ("HW_OCOTP_"#f), ("HW_OCOTP_"#g), ("HW_OCOTP_"#h) \
+	}
+
+#define MXS_OTP_BANKS		(5)
+#define MXS_OTP_BANK_ITEMS	(8)
+static const char *bank_reg_desc[MXS_OTP_BANKS][MXS_OTP_BANK_ITEMS] = {
+MXS_OTP_BANK(CUST0, CUST1, CUST2, CUST3, CRYPTO0, CRYPTO1, CRYPTO2, CRYPTO3),
+MXS_OTP_BANK(HWCAP0, HWCAP1, HWCAP2, HWCAP3, HWCAP4, HWCAP5, SWCAP, CUSTCAP),
+MXS_OTP_BANK(LOCK, OPS0, OPS1, OPS2, OPS3, UN0, UN1, UN2),
+MXS_OTP_BANK(ROM0, ROM1, ROM2, ROM3, ROM4, ROM5, ROM6, ROM7),
+MXS_OTP_BANK(SRK0, SRK1, SRK2, SRK3, SRK4, SRK5, SRK6, SRK7),
+};
+#endif /* if defined(CONFIG_SOC_IMX28) */
+
+
+#if defined(CONFIG_SOC_IMX23)
+/* Building up eight registers's names of a bank */
+#define MXS_OTP_BANK(a, b, c, d, e, f, g, h)	\
+	{\
+	("HW_OCOTP_"#a), ("HW_OCOTP_"#b), ("HW_OCOTP_"#c), ("HW_OCOTP_"#d), \
+	("HW_OCOTP_"#e), ("HW_OCOTP_"#f), ("HW_OCOTP_"#g), ("HW_OCOTP_"#h) \
+	}
+
+#define MXS_OTP_BANKS		(4)
+#define MXS_OTP_BANK_ITEMS	(8)
+static const char *bank_reg_desc[MXS_OTP_BANKS][MXS_OTP_BANK_ITEMS] = {
+MXS_OTP_BANK(CUST0, CUST1, CUST2, CUST3, CRYPTO0, CRYPTO1, CRYPTO2, CRYPTO3),
+MXS_OTP_BANK(HWCAP0, HWCAP1, HWCAP2, HWCAP3, HWCAP4, HWCAP5, SWCAP, CUSTCAP),
+MXS_OTP_BANK(LOCK, OPS0, OPS1, OPS2, OPS3, UN0, UN1, UN2),
+MXS_OTP_BANK(ROM0, ROM1, ROM2, ROM3, ROM4, ROM5, ROM6, ROM7),
+};
+
+#endif/* if defined(CONFIG_SOC_IMX23) */
+
+static unsigned long otp_hclk_saved;
+static u32 otp_voltage_saved;
+struct regulator *regu;
+
+struct fsl_otp_data {
+	char		**fuse_name;
+	char		*regulator_name;
+	unsigned int	fuse_num;
+};
+
+static struct fsl_otp_data otp_data = {
+	.fuse_name	= (char **)bank_reg_desc,
+	.regulator_name	= "vddio-sd0",
+	.fuse_num	= MXS_OTP_BANKS * MXS_OTP_BANK_ITEMS,
+};
+
+/* open the bank for the imx23/imx28 */
+static int otp_read_prepare(void)
+{
+	int r;
+
+	/* [1] set the HCLK */
+	/* [2] check BUSY and ERROR bit */
+	r = otp_wait_busy(0);
+	if (r < 0)
+		goto error;
+
+	/* [3] open bank */
+	__raw_writel(BM_OCOTP_CTRL_RD_BANK_OPEN,
+		REGS_OCOTP_BASE + HW_OCOTP_CTRL_SET);
+	udelay(10);
+
+	/* [4] wait for BUSY */
+	r = otp_wait_busy(0);
+	return 0;
+error:
+	return r;
+}
+
+static int otp_read_post(void)
+{
+	/* [5] close bank */
+	__raw_writel(BM_OCOTP_CTRL_RD_BANK_OPEN,
+		REGS_OCOTP_BASE + HW_OCOTP_CTRL_CLR);
+	return 0;
+}
+
+static int otp_write_prepare(void)
+{
+	struct clk *hclk;
+	int err = 0;
+
+	/* [1] HCLK to 24MHz. */
+	hclk = clk_get_sys("hbus", NULL);
+	if (IS_ERR(hclk)) {
+		err = PTR_ERR(hclk);
+		goto out;
+	}
+	/*
+	   WARNING  ACHTUNG  UWAGA
+
+	   the code below changes HCLK clock rate to 24M. This is
+	   required to write OTP bits (7.2.2 in STMP378x Target
+	   Specification), and might affect LCD operation, for example.
+	   Moreover, this hacky code changes VDDIO to 2.8V; and resto-
+	   res it only on otp_close(). This may affect... anything.
+
+	   You are warned now.
+	 */
+	otp_hclk_saved = clk_get_rate(hclk);
+	clk_set_rate(hclk, 24000000);
+
+	/* [2] The voltage is set to 2.8V */
+	regu = regulator_get(NULL, otp_data.regulator_name);
+	otp_voltage_saved = regulator_get_voltage(regu);
+	regulator_set_voltage(regu, 2800000, 2800000);
+
+	/* [3] wait for BUSY and ERROR */
+	err = otp_wait_busy(BM_OCOTP_CTRL_RD_BANK_OPEN);
+out:
+	return err;
+}
+
+static int otp_write_post(void)
+{
+	struct clk *hclk;
+
+	hclk = clk_get_sys("hbus", NULL);
+	if (IS_ERR(hclk))
+		return PTR_ERR(hclk);
+
+	/* restore the clock and voltage */
+	clk_set_rate(hclk, otp_hclk_saved);
+	regulator_set_voltage(regu, otp_voltage_saved, otp_voltage_saved);
+	otp_wait_busy(0);
+
+	/* reset */
+	__raw_writel(BM_OCOTP_CTRL_RELOAD_SHADOWS,
+			REGS_OCOTP_BASE + HW_OCOTP_CTRL_SET);
+	otp_wait_busy(BM_OCOTP_CTRL_RELOAD_SHADOWS);
+	return 0;
+}
+
+static int __init map_ocotp_addr(struct platform_device *pdev)
+{
+	return 0;
+}
+static void unmap_ocotp_addr(void)
+{
+}
+
+
+#endif /* (defined(CONFIG_SOC_IMX23) || defined(CONFIG_SOC_IMX28)) */
+#endif
-- 
1.7.9.5



From cb at sgoc.de  Wed Jul  3 08:39:13 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Wed,  3 Jul 2013 14:39:13 +0200
Subject: [PATCH 2/3] Added support for On Chip OTP in i.MX23/28
In-Reply-To: <1372855154-8422-1-git-send-email-cb@sgoc.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
Message-ID: <1372855154-8422-3-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <cb at sgoc.de>

Signed-off-by: Christoph G. Baumann <cb at sgoc.de>
---
 arch/arm/mach-mxs/include/mach/mx23-ocotp.h |  311 +++++++++++++++++++++++++++
 arch/arm/mach-mxs/include/mach/mx28-ocotp.h |  239 ++++++++++++++++++++
 2 files changed, 550 insertions(+)
 create mode 100644 arch/arm/mach-mxs/include/mach/mx23-ocotp.h
 create mode 100644 arch/arm/mach-mxs/include/mach/mx28-ocotp.h

diff --git a/arch/arm/mach-mxs/include/mach/mx23-ocotp.h b/arch/arm/mach-mxs/include/mach/mx23-ocotp.h
new file mode 100644
index 0000000..b246ef2
--- /dev/null
+++ b/arch/arm/mach-mxs/include/mach/mx23-ocotp.h
@@ -0,0 +1,311 @@
+/*
+ * Freescale OCOTP Register Definitions
+ *
+ * Copyright 2008-2010 Freescale Semiconductor, Inc.
+ * Copyright 2008 Embedded Alley Solutions, Inc All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ *
+ * This file is created by xml file. Don't Edit it.
+ *
+ * Xml Revision: 1.21
+ * Template revision: 26195
+ */
+
+#ifndef __ARCH_ARM___OCOTP_H
+#define __ARCH_ARM___OCOTP_H
+
+
+#define HW_OCOTP_CTRL	(0x00000000)
+#define HW_OCOTP_CTRL_SET	(0x00000004)
+#define HW_OCOTP_CTRL_CLR	(0x00000008)
+#define HW_OCOTP_CTRL_TOG	(0x0000000c)
+
+#define BP_OCOTP_CTRL_WR_UNLOCK	16
+#define BM_OCOTP_CTRL_WR_UNLOCK	0xFFFF0000
+#define BF_OCOTP_CTRL_WR_UNLOCK(v) \
+		(((v) << 16) & BM_OCOTP_CTRL_WR_UNLOCK)
+#define BV_OCOTP_CTRL_WR_UNLOCK__KEY 0x3E77
+#define BP_OCOTP_CTRL_RSRVD2	14
+#define BM_OCOTP_CTRL_RSRVD2	0x0000C000
+#define BF_OCOTP_CTRL_RSRVD2(v)  \
+		(((v) << 14) & BM_OCOTP_CTRL_RSRVD2)
+#define BM_OCOTP_CTRL_RELOAD_SHADOWS	0x00002000
+#define BM_OCOTP_CTRL_RD_BANK_OPEN	0x00001000
+#define BP_OCOTP_CTRL_RSRVD1	10
+#define BM_OCOTP_CTRL_RSRVD1	0x00000C00
+#define BF_OCOTP_CTRL_RSRVD1(v)  \
+		(((v) << 10) & BM_OCOTP_CTRL_RSRVD1)
+#define BM_OCOTP_CTRL_ERROR	0x00000200
+#define BM_OCOTP_CTRL_BUSY	0x00000100
+#define BP_OCOTP_CTRL_RSRVD0	5
+#define BM_OCOTP_CTRL_RSRVD0	0x000000E0
+#define BF_OCOTP_CTRL_RSRVD0(v)  \
+		(((v) << 5) & BM_OCOTP_CTRL_RSRVD0)
+#define BP_OCOTP_CTRL_ADDR	0
+#define BM_OCOTP_CTRL_ADDR	0x0000001F
+#define BF_OCOTP_CTRL_ADDR(v)  \
+		(((v) << 0) & BM_OCOTP_CTRL_ADDR)
+
+#define HW_OCOTP_DATA	(0x00000010)
+
+#define BP_OCOTP_DATA_DATA	0
+#define BM_OCOTP_DATA_DATA	0xFFFFFFFF
+#define BF_OCOTP_DATA_DATA(v)	(v)
+
+/*
+ *  multi-register-define name HW_OCOTP_CUST_N
+ *              base 0x00000020
+ *              count 4
+ *              offset 0x10
+ */
+#define HW_OCOTP_CUST_N(n)	(0x00000020 + (n) * 0x10)
+#define BP_OCOTP_CUST_N_BITS	0
+#define BM_OCOTP_CUST_N_BITS	0xFFFFFFFF
+#define BF_OCOTP_CUST_N_BITS(v)	(v)
+
+/*
+ *  multi-register-define name HW_OCOTP_CRYPTO_N
+ *              base 0x00000060
+ *              count 4
+ *              offset 0x10
+ */
+#define HW_OCOTP_CRYPTO_N(n)	(0x00000060 + (n) * 0x10)
+#define BP_OCOTP_CRYPTO_N_BITS	0
+#define BM_OCOTP_CRYPTO_N_BITS	0xFFFFFFFF
+#define BF_OCOTP_CRYPTO_N_BITS(v)	(v)
+
+/*
+ *  multi-register-define name HW_OCOTP_HWCAP_N
+ *              base 0x000000A0
+ *              count 6
+ *              offset 0x10
+ */
+#define HW_OCOTP_HWCAP_N(n)	(0x000000a0 + (n) * 0x10)
+#define BP_OCOTP_HWCAP_N_BITS	0
+#define BM_OCOTP_HWCAP_N_BITS	0xFFFFFFFF
+#define BF_OCOTP_HWCAP_N_BITS(v)	(v)
+
+#define HW_OCOTP_SWCAP	(0x00000100)
+
+#define BP_OCOTP_SWCAP_BITS	0
+#define BM_OCOTP_SWCAP_BITS	0xFFFFFFFF
+#define BF_OCOTP_SWCAP_BITS(v)	(v)
+
+#define HW_OCOTP_CUSTCAP	(0x00000110)
+
+#define BM_OCOTP_CUSTCAP_CUST_DISABLE_WMADRM9	0x80000000
+#define BM_OCOTP_CUSTCAP_CUST_DISABLE_JANUSDRM10	0x40000000
+#define BP_OCOTP_CUSTCAP_RSRVD1	5
+#define BM_OCOTP_CUSTCAP_RSRVD1	0x3FFFFFE0
+#define BF_OCOTP_CUSTCAP_RSRVD1(v)  \
+		(((v) << 5) & BM_OCOTP_CUSTCAP_RSRVD1)
+#define BM_OCOTP_CUSTCAP_ENABLE_SJTAG_12MA_DRIVE	0x00000010
+#define BM_OCOTP_CUSTCAP_USE_PARALLEL_JTAG	0x00000008
+#define BM_OCOTP_CUSTCAP_RTC_XTAL_32768_PRESENT	0x00000004
+#define BM_OCOTP_CUSTCAP_RTC_XTAL_32000_PRESENT	0x00000002
+#define BM_OCOTP_CUSTCAP_RSRVD0	0x00000001
+
+#define HW_OCOTP_LOCK	(0x00000120)
+
+#define BM_OCOTP_LOCK_ROM7	0x80000000
+#define BM_OCOTP_LOCK_ROM6	0x40000000
+#define BM_OCOTP_LOCK_ROM5	0x20000000
+#define BM_OCOTP_LOCK_ROM4	0x10000000
+#define BM_OCOTP_LOCK_ROM3	0x08000000
+#define BM_OCOTP_LOCK_ROM2	0x04000000
+#define BM_OCOTP_LOCK_ROM1	0x02000000
+#define BM_OCOTP_LOCK_ROM0	0x01000000
+#define BM_OCOTP_LOCK_HWSW_SHADOW_ALT	0x00800000
+#define BM_OCOTP_LOCK_CRYPTODCP_ALT	0x00400000
+#define BM_OCOTP_LOCK_CRYPTOKEY_ALT	0x00200000
+#define BM_OCOTP_LOCK_PIN	0x00100000
+#define BM_OCOTP_LOCK_OPS	0x00080000
+#define BM_OCOTP_LOCK_UN2	0x00040000
+#define BM_OCOTP_LOCK_UN1	0x00020000
+#define BM_OCOTP_LOCK_UN0	0x00010000
+#define BP_OCOTP_LOCK_UNALLOCATED	11
+#define BM_OCOTP_LOCK_UNALLOCATED	0x0000F800
+#define BF_OCOTP_LOCK_UNALLOCATED(v)  \
+		(((v) << 11) & BM_OCOTP_LOCK_UNALLOCATED)
+#define BM_OCOTP_LOCK_ROM_SHADOW	0x00000400
+#define BM_OCOTP_LOCK_CUSTCAP	0x00000200
+#define BM_OCOTP_LOCK_HWSW	0x00000100
+#define BM_OCOTP_LOCK_CUSTCAP_SHADOW	0x00000080
+#define BM_OCOTP_LOCK_HWSW_SHADOW	0x00000040
+#define BM_OCOTP_LOCK_CRYPTODCP	0x00000020
+#define BM_OCOTP_LOCK_CRYPTOKEY	0x00000010
+#define BM_OCOTP_LOCK_CUST3	0x00000008
+#define BM_OCOTP_LOCK_CUST2	0x00000004
+#define BM_OCOTP_LOCK_CUST1	0x00000002
+#define BM_OCOTP_LOCK_CUST0	0x00000001
+
+/*
+ *  multi-register-define name HW_OCOTP_OPS_N
+ *              base 0x00000130
+ *              count 4
+ *              offset 0x10
+ */
+#define HW_OCOTP_OPS_N(n)	(0x00000130 + (n) * 0x10)
+#define BP_OCOTP_OPS_N_BITS	0
+#define BM_OCOTP_OPS_N_BITS	0xFFFFFFFF
+#define BF_OCOTP_OPS_N_BITS(v)	(v)
+
+/*
+ *  multi-register-define name HW_OCOTP_UN_N
+ *              base 0x00000170
+ *              count 3
+ *              offset 0x10
+ */
+#define HW_OCOTP_UN_N(n)	(0x00000170 + (n) * 0x10)
+#define BP_OCOTP_UN_N_BITS	0
+#define BM_OCOTP_UN_N_BITS	0xFFFFFFFF
+#define BF_OCOTP_UN_N_BITS(v)	(v)
+
+#define HW_OCOTP_ROM0	(0x000001a0)
+
+#define BP_OCOTP_ROM0_BOOT_MODE	24
+#define BM_OCOTP_ROM0_BOOT_MODE	0xFF000000
+#define BF_OCOTP_ROM0_BOOT_MODE(v) \
+		(((v) << 24) & BM_OCOTP_ROM0_BOOT_MODE)
+#define BM_OCOTP_ROM0_ENABLE_PJTAG_12MA_DRIVE	0x00800000
+#define BM_OCOTP_ROM0_USE_PARALLEL_JTAG	0x00400000
+#define BP_OCOTP_ROM0_SD_POWER_GATE_GPIO	20
+#define BM_OCOTP_ROM0_SD_POWER_GATE_GPIO	0x00300000
+#define BF_OCOTP_ROM0_SD_POWER_GATE_GPIO(v)  \
+		(((v) << 20) & BM_OCOTP_ROM0_SD_POWER_GATE_GPIO)
+#define BP_OCOTP_ROM0_SD_POWER_UP_DELAY	14
+#define BM_OCOTP_ROM0_SD_POWER_UP_DELAY	0x000FC000
+#define BF_OCOTP_ROM0_SD_POWER_UP_DELAY(v)  \
+		(((v) << 14) & BM_OCOTP_ROM0_SD_POWER_UP_DELAY)
+#define BP_OCOTP_ROM0_SD_BUS_WIDTH	12
+#define BM_OCOTP_ROM0_SD_BUS_WIDTH	0x00003000
+#define BF_OCOTP_ROM0_SD_BUS_WIDTH(v)  \
+		(((v) << 12) & BM_OCOTP_ROM0_SD_BUS_WIDTH)
+#define BP_OCOTP_ROM0_SSP_SCK_INDEX	8
+#define BM_OCOTP_ROM0_SSP_SCK_INDEX	0x00000F00
+#define BF_OCOTP_ROM0_SSP_SCK_INDEX(v)  \
+		(((v) << 8) & BM_OCOTP_ROM0_SSP_SCK_INDEX)
+#define BM_OCOTP_ROM0_RSRVD3	0x00000080
+#define BM_OCOTP_ROM0_DISABLE_SPI_NOR_FAST_READ		0x00000040
+#define BM_OCOTP_ROM0_ENABLE_USB_BOOT_SERIAL_NUM	0x00000020
+#define BM_OCOTP_ROM0_ENABLE_UNENCRYPTED_BOOT		0x00000010
+#define BM_OCOTP_ROM0_SD_MBR_BOOT	0x00000008
+#define BM_OCOTP_ROM0_RSRVD2	0x00000004
+#define BM_OCOTP_ROM0_RSRVD1	0x00000002
+#define BM_OCOTP_ROM0_RSRVD0	0x00000001
+
+#define HW_OCOTP_ROM1	(0x000001b0)
+
+#define BP_OCOTP_ROM1_RSRVD1	30
+#define BM_OCOTP_ROM1_RSRVD1	0xC0000000
+#define BF_OCOTP_ROM1_RSRVD1(v) \
+		(((v) << 30) & BM_OCOTP_ROM1_RSRVD1)
+#define BP_OCOTP_ROM1_USE_ALT_GPMI_RDY3	28
+#define BM_OCOTP_ROM1_USE_ALT_GPMI_RDY3	0x30000000
+#define BF_OCOTP_ROM1_USE_ALT_GPMI_RDY3(v)  \
+		(((v) << 28) & BM_OCOTP_ROM1_USE_ALT_GPMI_RDY3)
+#define BP_OCOTP_ROM1_USE_ALT_GPMI_CE3	26
+#define BM_OCOTP_ROM1_USE_ALT_GPMI_CE3	0x0C000000
+#define BF_OCOTP_ROM1_USE_ALT_GPMI_CE3(v)  \
+		(((v) << 26) & BM_OCOTP_ROM1_USE_ALT_GPMI_CE3)
+#define BM_OCOTP_ROM1_USE_ALT_GPMI_RDY2	0x02000000
+#define BM_OCOTP_ROM1_USE_ALT_GPMI_CE2	0x01000000
+#define BM_OCOTP_ROM1_ENABLE_NAND3_CE_RDY_PULLUP	0x00800000
+#define BM_OCOTP_ROM1_ENABLE_NAND2_CE_RDY_PULLUP	0x00400000
+#define BM_OCOTP_ROM1_ENABLE_NAND1_CE_RDY_PULLUP	0x00200000
+#define BM_OCOTP_ROM1_ENABLE_NAND0_CE_RDY_PULLUP	0x00100000
+#define BM_OCOTP_ROM1_UNTOUCH_INTERNAL_SSP_PULLUP	0x00080000
+#define BM_OCOTP_ROM1_SSP2_EXT_PULLUP	0x00040000
+#define BM_OCOTP_ROM1_SSP1_EXT_PULLUP	0x00020000
+#define BM_OCOTP_ROM1_SD_INCREASE_INIT_SEQ_TIME	0x00010000
+#define BM_OCOTP_ROM1_SD_INIT_SEQ_2_ENABLE	0x00008000
+#define BM_OCOTP_ROM1_SD_CMD0_DISABLE	0x00004000
+#define BM_OCOTP_ROM1_SD_INIT_SEQ_1_DISABLE	0x00002000
+#define BM_OCOTP_ROM1_USE_ALT_SSP1_DATA4_7	0x00001000
+#define BP_OCOTP_ROM1_BOOT_SEARCH_COUNT	8
+#define BM_OCOTP_ROM1_BOOT_SEARCH_COUNT	0x00000F00
+#define BF_OCOTP_ROM1_BOOT_SEARCH_COUNT(v)  \
+		(((v) << 8) & BM_OCOTP_ROM1_BOOT_SEARCH_COUNT)
+#define BP_OCOTP_ROM1_RSRVD0	3
+#define BM_OCOTP_ROM1_RSRVD0	0x000000F8
+#define BF_OCOTP_ROM1_RSRVD0(v)  \
+		(((v) << 3) & BM_OCOTP_ROM1_RSRVD0)
+#define BP_OCOTP_ROM1_NUMBER_OF_NANDS	0
+#define BM_OCOTP_ROM1_NUMBER_OF_NANDS	0x00000007
+#define BF_OCOTP_ROM1_NUMBER_OF_NANDS(v)  \
+		(((v) << 0) & BM_OCOTP_ROM1_NUMBER_OF_NANDS)
+
+#define HW_OCOTP_ROM2	(0x000001c0)
+
+#define BP_OCOTP_ROM2_USB_VID	16
+#define BM_OCOTP_ROM2_USB_VID	0xFFFF0000
+#define BF_OCOTP_ROM2_USB_VID(v) \
+		(((v) << 16) & BM_OCOTP_ROM2_USB_VID)
+#define BP_OCOTP_ROM2_USB_PID	0
+#define BM_OCOTP_ROM2_USB_PID	0x0000FFFF
+#define BF_OCOTP_ROM2_USB_PID(v)  \
+		(((v) << 0) & BM_OCOTP_ROM2_USB_PID)
+
+#define HW_OCOTP_ROM3	(0x000001d0)
+
+#define BP_OCOTP_ROM3_RSRVD1	10
+#define BM_OCOTP_ROM3_RSRVD1	0xFFFFFC00
+#define BF_OCOTP_ROM3_RSRVD1(v) \
+		(((v) << 10) & BM_OCOTP_ROM3_RSRVD1)
+#define BP_OCOTP_ROM3_RSRVD0	0
+#define BM_OCOTP_ROM3_RSRVD0	0x000003FF
+#define BF_OCOTP_ROM3_RSRVD0(v)  \
+		(((v) << 0) & BM_OCOTP_ROM3_RSRVD0)
+
+#define HW_OCOTP_ROM4	(0x000001e0)
+
+#define BP_OCOTP_ROM4_BITS	0
+#define BM_OCOTP_ROM4_BITS	0xFFFFFFFF
+#define BF_OCOTP_ROM4_BITS(v)	(v)
+
+#define HW_OCOTP_ROM5	(0x000001f0)
+
+#define BP_OCOTP_ROM5_BITS	0
+#define BM_OCOTP_ROM5_BITS	0xFFFFFFFF
+#define BF_OCOTP_ROM5_BITS(v)	(v)
+
+#define HW_OCOTP_ROM6	(0x00000200)
+
+#define BP_OCOTP_ROM6_BITS	0
+#define BM_OCOTP_ROM6_BITS	0xFFFFFFFF
+#define BF_OCOTP_ROM6_BITS(v)	(v)
+
+#define HW_OCOTP_ROM7	(0x00000210)
+
+#define BP_OCOTP_ROM7_BITS	0
+#define BM_OCOTP_ROM7_BITS	0xFFFFFFFF
+#define BF_OCOTP_ROM7_BITS(v)	(v)
+
+#define HW_OCOTP_VERSION	(0x00000220)
+
+#define BP_OCOTP_VERSION_MAJOR	24
+#define BM_OCOTP_VERSION_MAJOR	0xFF000000
+#define BF_OCOTP_VERSION_MAJOR(v) \
+		(((v) << 24) & BM_OCOTP_VERSION_MAJOR)
+#define BP_OCOTP_VERSION_MINOR	16
+#define BM_OCOTP_VERSION_MINOR	0x00FF0000
+#define BF_OCOTP_VERSION_MINOR(v)  \
+		(((v) << 16) & BM_OCOTP_VERSION_MINOR)
+#define BP_OCOTP_VERSION_STEP	0
+#define BM_OCOTP_VERSION_STEP	0x0000FFFF
+#define BF_OCOTP_VERSION_STEP(v)  \
+		(((v) << 0) & BM_OCOTP_VERSION_STEP)
+#endif /* __ARCH_ARM___OCOTP_H */
diff --git a/arch/arm/mach-mxs/include/mach/mx28-ocotp.h b/arch/arm/mach-mxs/include/mach/mx28-ocotp.h
new file mode 100644
index 0000000..61fa3f7
--- /dev/null
+++ b/arch/arm/mach-mxs/include/mach/mx28-ocotp.h
@@ -0,0 +1,239 @@
+/*
+ * Freescale OCOTP Register Definitions
+ *
+ * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ *
+ * This file is created by xml file. Don't Edit it.
+ *
+ * Xml Revision: 1.21
+ * Template revision: 26195
+ */
+
+#ifndef __ARCH_ARM___OCOTP_H
+#define __ARCH_ARM___OCOTP_H
+
+
+#define HW_OCOTP_CTRL	(0x00000000)
+#define HW_OCOTP_CTRL_SET	(0x00000004)
+#define HW_OCOTP_CTRL_CLR	(0x00000008)
+#define HW_OCOTP_CTRL_TOG	(0x0000000c)
+
+#define BP_OCOTP_CTRL_WR_UNLOCK	16
+#define BM_OCOTP_CTRL_WR_UNLOCK	0xFFFF0000
+#define BF_OCOTP_CTRL_WR_UNLOCK(v) \
+		(((v) << 16) & BM_OCOTP_CTRL_WR_UNLOCK)
+#define BV_OCOTP_CTRL_WR_UNLOCK__KEY 0x3E77
+#define BP_OCOTP_CTRL_RSRVD2	14
+#define BM_OCOTP_CTRL_RSRVD2	0x0000C000
+#define BF_OCOTP_CTRL_RSRVD2(v)  \
+		(((v) << 14) & BM_OCOTP_CTRL_RSRVD2)
+#define BM_OCOTP_CTRL_RELOAD_SHADOWS	0x00002000
+#define BM_OCOTP_CTRL_RD_BANK_OPEN	0x00001000
+#define BP_OCOTP_CTRL_RSRVD1	10
+#define BM_OCOTP_CTRL_RSRVD1	0x00000C00
+#define BF_OCOTP_CTRL_RSRVD1(v)  \
+		(((v) << 10) & BM_OCOTP_CTRL_RSRVD1)
+#define BM_OCOTP_CTRL_ERROR	0x00000200
+#define BM_OCOTP_CTRL_BUSY	0x00000100
+#define BP_OCOTP_CTRL_RSRVD0	6
+#define BM_OCOTP_CTRL_RSRVD0	0x000000C0
+#define BF_OCOTP_CTRL_RSRVD0(v)  \
+		(((v) << 6) & BM_OCOTP_CTRL_RSRVD0)
+#define BP_OCOTP_CTRL_ADDR	0
+#define BM_OCOTP_CTRL_ADDR	0x0000003F
+#define BF_OCOTP_CTRL_ADDR(v)  \
+		(((v) << 0) & BM_OCOTP_CTRL_ADDR)
+
+#define HW_OCOTP_DATA	(0x00000010)
+
+#define BP_OCOTP_DATA_DATA	0
+#define BM_OCOTP_DATA_DATA	0xFFFFFFFF
+#define BF_OCOTP_DATA_DATA(v)	(v)
+
+/*
+ *  multi-register-define name HW_OCOTP_CUST_N
+ *              base 0x00000020
+ *              count 4
+ *              offset 0x10
+ */
+#define HW_OCOTP_CUST_N(n)	(0x00000020 + (n) * 0x10)
+#define BP_OCOTP_CUST_N_BITS	0
+#define BM_OCOTP_CUST_N_BITS	0xFFFFFFFF
+#define BF_OCOTP_CUST_N_BITS(v)	(v)
+
+/*
+ *  multi-register-define name HW_OCOTP_CRYPTO_N
+ *              base 0x00000060
+ *              count 4
+ *              offset 0x10
+ */
+#define HW_OCOTP_CRYPTO_N(n)	(0x00000060 + (n) * 0x10)
+#define BP_OCOTP_CRYPTO_N_BITS	0
+#define BM_OCOTP_CRYPTO_N_BITS	0xFFFFFFFF
+#define BF_OCOTP_CRYPTO_N_BITS(v)	(v)
+
+/*
+ *  multi-register-define name HW_OCOTP_HWCAP_N
+ *              base 0x000000A0
+ *              count 6
+ *              offset 0x10
+ */
+#define HW_OCOTP_HWCAP_N(n)	(0x000000a0 + (n) * 0x10)
+#define BP_OCOTP_HWCAP_N_BITS	0
+#define BM_OCOTP_HWCAP_N_BITS	0xFFFFFFFF
+#define BF_OCOTP_HWCAP_N_BITS(v)	(v)
+
+#define HW_OCOTP_SWCAP	(0x00000100)
+
+#define BP_OCOTP_SWCAP_BITS	0
+#define BM_OCOTP_SWCAP_BITS	0xFFFFFFFF
+#define BF_OCOTP_SWCAP_BITS(v)	(v)
+
+#define HW_OCOTP_CUSTCAP	(0x00000110)
+
+#define BP_OCOTP_CUSTCAP_RSRVD1	3
+#define BM_OCOTP_CUSTCAP_RSRVD1	0xFFFFFFF8
+#define BF_OCOTP_CUSTCAP_RSRVD1(v) \
+		(((v) << 3) & BM_OCOTP_CUSTCAP_RSRVD1)
+#define BM_OCOTP_CUSTCAP_RTC_XTAL_32768_PRESENT	0x00000004
+#define BM_OCOTP_CUSTCAP_RTC_XTAL_32000_PRESENT	0x00000002
+#define BM_OCOTP_CUSTCAP_RSRVD0	0x00000001
+
+#define HW_OCOTP_LOCK	(0x00000120)
+
+#define BM_OCOTP_LOCK_ROM7	0x80000000
+#define BM_OCOTP_LOCK_ROM6	0x40000000
+#define BM_OCOTP_LOCK_ROM5	0x20000000
+#define BM_OCOTP_LOCK_ROM4	0x10000000
+#define BM_OCOTP_LOCK_ROM3	0x08000000
+#define BM_OCOTP_LOCK_ROM2	0x04000000
+#define BM_OCOTP_LOCK_ROM1	0x02000000
+#define BM_OCOTP_LOCK_ROM0	0x01000000
+#define BM_OCOTP_LOCK_HWSW_SHADOW_ALT	0x00800000
+#define BM_OCOTP_LOCK_CRYPTODCP_ALT	0x00400000
+#define BM_OCOTP_LOCK_CRYPTOKEY_ALT	0x00200000
+#define BM_OCOTP_LOCK_PIN	0x00100000
+#define BM_OCOTP_LOCK_OPS	0x00080000
+#define BM_OCOTP_LOCK_UN2	0x00040000
+#define BM_OCOTP_LOCK_UN1	0x00020000
+#define BM_OCOTP_LOCK_UN0	0x00010000
+#define BM_OCOTP_LOCK_SRK	0x00008000
+#define BP_OCOTP_LOCK_UNALLOCATED	12
+#define BM_OCOTP_LOCK_UNALLOCATED	0x00007000
+#define BF_OCOTP_LOCK_UNALLOCATED(v)  \
+		(((v) << 12) & BM_OCOTP_LOCK_UNALLOCATED)
+#define BM_OCOTP_LOCK_SRK_SHADOW	0x00000800
+#define BM_OCOTP_LOCK_ROM_SHADOW	0x00000400
+#define BM_OCOTP_LOCK_CUSTCAP	0x00000200
+#define BM_OCOTP_LOCK_HWSW	0x00000100
+#define BM_OCOTP_LOCK_CUSTCAP_SHADOW	0x00000080
+#define BM_OCOTP_LOCK_HWSW_SHADOW	0x00000040
+#define BM_OCOTP_LOCK_CRYPTODCP	0x00000020
+#define BM_OCOTP_LOCK_CRYPTOKEY	0x00000010
+#define BM_OCOTP_LOCK_CUST3	0x00000008
+#define BM_OCOTP_LOCK_CUST2	0x00000004
+#define BM_OCOTP_LOCK_CUST1	0x00000002
+#define BM_OCOTP_LOCK_CUST0	0x00000001
+
+/*
+ *  multi-register-define name HW_OCOTP_OPS_N
+ *              base 0x00000130
+ *              count 4
+ *              offset 0x10
+ */
+#define HW_OCOTP_OPS_N(n)	(0x00000130 + (n) * 0x10)
+#define BP_OCOTP_OPS_N_BITS	0
+#define BM_OCOTP_OPS_N_BITS	0xFFFFFFFF
+#define BF_OCOTP_OPS_N_BITS(v)	(v)
+
+/*
+ *  multi-register-define name HW_OCOTP_UN_N
+ *              base 0x00000170
+ *              count 3
+ *              offset 0x10
+ */
+#define HW_OCOTP_UN_N(n)	(0x00000170 + (n) * 0x10)
+#define BP_OCOTP_UN_N_BITS	0
+#define BM_OCOTP_UN_N_BITS	0xFFFFFFFF
+#define BF_OCOTP_UN_N_BITS(v)	(v)
+
+/*
+ *  multi-register-define name HW_OCOTP_ROM_N
+ *              base 0x000001A0
+ *              count 8
+ *              offset 0x10
+ */
+#define HW_OCOTP_ROM_N(n)	(0x000001a0 + (n) * 0x10)
+#define BP_OCOTP_ROM_N_BOOT_MODE	24
+#define BM_OCOTP_ROM_N_BOOT_MODE	0xFF000000
+#define BF_OCOTP_ROM_N_BOOT_MODE(v) \
+		(((v) << 24) & BM_OCOTP_ROM_N_BOOT_MODE)
+#define BP_OCOTP_ROM_N_SD_MMC_MODE	22
+#define BM_OCOTP_ROM_N_SD_MMC_MODE	0x00C00000
+#define BF_OCOTP_ROM_N_SD_MMC_MODE(v)  \
+		(((v) << 22) & BM_OCOTP_ROM_N_SD_MMC_MODE)
+#define BP_OCOTP_ROM_N_SD_POWER_GATE_GPIO	20
+#define BM_OCOTP_ROM_N_SD_POWER_GATE_GPIO	0x00300000
+#define BF_OCOTP_ROM_N_SD_POWER_GATE_GPIO(v)  \
+		(((v) << 20) & BM_OCOTP_ROM_N_SD_POWER_GATE_GPIO)
+#define BP_OCOTP_ROM_N_SD_POWER_UP_DELAY	14
+#define BM_OCOTP_ROM_N_SD_POWER_UP_DELAY	0x000FC000
+#define BF_OCOTP_ROM_N_SD_POWER_UP_DELAY(v)  \
+		(((v) << 14) & BM_OCOTP_ROM_N_SD_POWER_UP_DELAY)
+#define BP_OCOTP_ROM_N_SD_BUS_WIDTH	12
+#define BM_OCOTP_ROM_N_SD_BUS_WIDTH	0x00003000
+#define BF_OCOTP_ROM_N_SD_BUS_WIDTH(v)  \
+		(((v) << 12) & BM_OCOTP_ROM_N_SD_BUS_WIDTH)
+#define BP_OCOTP_ROM_N_SSP_SCK_INDEX	8
+#define BM_OCOTP_ROM_N_SSP_SCK_INDEX	0x00000F00
+#define BF_OCOTP_ROM_N_SSP_SCK_INDEX(v)  \
+		(((v) << 8) & BM_OCOTP_ROM_N_SSP_SCK_INDEX)
+#define BM_OCOTP_ROM_N_EMMC_USE_DDR	0x00000080
+#define BM_OCOTP_ROM_N_DISABLE_SPI_NOR_FAST_READ	0x00000040
+#define BM_OCOTP_ROM_N_ENABLE_USB_BOOT_SERIAL_NUM	0x00000020
+#define BM_OCOTP_ROM_N_ENABLE_UNENCRYPTED_BOOT	0x00000010
+#define BM_OCOTP_ROM_N_SD_MBR_BOOT	0x00000008
+#define BM_OCOTP_ROM_N_RSRVD2	0x00000004
+#define BM_OCOTP_ROM_N_RSRVD1	0x00000002
+#define BM_OCOTP_ROM_N_RSRVD0	0x00000001
+
+/*
+ *  multi-register-define name HW_OCOTP_SRK_N
+ *              base 0x00000220
+ *              count 8
+ *              offset 0x10
+ */
+#define HW_OCOTP_SRK_N(n)	(0x00000220 + (n) * 0x10)
+#define BP_OCOTP_SRK_N_BITS	0
+#define BM_OCOTP_SRK_N_BITS	0xFFFFFFFF
+#define BF_OCOTP_SRK_N_BITS(v)	(v)
+
+#define HW_OCOTP_VERSION	(0x000002a0)
+
+#define BP_OCOTP_VERSION_MAJOR	24
+#define BM_OCOTP_VERSION_MAJOR	0xFF000000
+#define BF_OCOTP_VERSION_MAJOR(v) \
+		(((v) << 24) & BM_OCOTP_VERSION_MAJOR)
+#define BP_OCOTP_VERSION_MINOR	16
+#define BM_OCOTP_VERSION_MINOR	0x00FF0000
+#define BF_OCOTP_VERSION_MINOR(v)  \
+		(((v) << 16) & BM_OCOTP_VERSION_MINOR)
+#define BP_OCOTP_VERSION_STEP	0
+#define BM_OCOTP_VERSION_STEP	0x0000FFFF
+#define BF_OCOTP_VERSION_STEP(v)  \
+		(((v) << 0) & BM_OCOTP_VERSION_STEP)
+#endif /* __ARCH_ARM___OCOTP_H */
-- 
1.7.9.5



From festevam at gmail.com  Wed Jul  3 08:42:57 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  3 Jul 2013 09:42:57 -0300
Subject: [PATCH] ARM: imx_v4_v5_defconfig: Select CONFIG_MACH_IMX25_DT
Message-ID: <1372855377-19884-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Allow booting a mx25 dt kernel by default.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/configs/imx_v4_v5_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/imx_v4_v5_defconfig b/arch/arm/configs/imx_v4_v5_defconfig
index f07a847..dcd3d91 100644
--- a/arch/arm/configs/imx_v4_v5_defconfig
+++ b/arch/arm/configs/imx_v4_v5_defconfig
@@ -27,6 +27,7 @@ CONFIG_MACH_APF9328=y
 CONFIG_MACH_MX21ADS=y
 CONFIG_MACH_MX25_3DS=y
 CONFIG_MACH_EUKREA_CPUIMX25SD=y
+CONFIG_MACH_IMX25_DT=y
 CONFIG_MACH_MX27ADS=y
 CONFIG_MACH_PCM038=y
 CONFIG_MACH_CPUIMX27=y
-- 
1.8.1.2



From paul.gortmaker at windriver.com  Wed Jul  3 11:30:12 2013
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Wed, 3 Jul 2013 11:30:12 -0400
Subject: [PATCH] ARM: move body of head-common.S back to text section
In-Reply-To: <20130703100044.GG24642@n2100.arm.linux.org.uk>
References: <1372805629-18382-1-git-send-email-swarren@wwwdotorg.org>
 <20130702232259.GH11625@codeaurora.org>
 <51D39004.9000907@wwwdotorg.org>
 <20130703051907.GA22702@windriver.com>
 <20130703100044.GG24642@n2100.arm.linux.org.uk>
Message-ID: <20130703153012.GK22702@windriver.com>

[Re: [PATCH] ARM: move body of head-common.S back to text section] On 03/07/2013 (Wed 11:00) Russell King - ARM Linux wrote:

> On Wed, Jul 03, 2013 at 01:19:07AM -0400, Paul Gortmaker wrote:
> > As an aside, I'm now thinking any __INIT that implicitly rely on EOF for
> > closure are nasty traps waiting to happen and it might be worthwhile to
> > audit and explicitly __FINIT them before someone appends to the file...
> 
> That hides a different kind of bug though - I hate __FINIT for exactly
> that reason.  Consider this:

Agreed - perhaps masking that it is a ".previous" just hides the fact
that it is more like a pop operation vs. an on/off operation, or per
function as we have in C.

> 
> 	.text
> 	blah blah blah
> 	__INIT
> 	lots of init stuff
> 	__FINIT
> 	more .text stuff
> 
> Now, someone comes along and modifies this to be:
> 
> 	.text
> 	blah blah blah
> 	.data
> 	something else

Yeah, that would be kind of careless; not putting .data above the .text,
or at least closing with a .previous, but sure it could sneak past
review.

> 	__INIT
> 	lots of init stuff
> 	__FINIT

The presence of the above 3 lines of init block (i.e. here or not)
doesn't really change the fact that the .data guy broke the below .text
code by grandfathering it into .data -- But you could argue that him
seeing the 1st __INIT and that influenced him to decide to not read any
further down into the file -- which probably does happen, though.... :(

> 	more .text stuff
> 
> Now, what is the effect of that __FINIT now?  You get the following .text
> emitted into the .data section instead.  This is basically the same problem
> you've just encounted.
> 
> Maybe:
> 
> 	__FINIT
> 	.text
> 
> is the safest solution - and __FINIT becomes just a no-op marker to avoid
> anyone relying on its properties.

That seems reasonable to me.  I can't think of any self auditing that is
reasonably simple to implement.  One downside of __FINIT as a no-op vs.
what it is today, is that a dangling __FINIT in a file with no other
previous sections will emit a warning.  But that is a small low value
corner case I think.


From dserrg at gmail.com  Wed Jul  3 11:37:52 2013
From: dserrg at gmail.com (Sergey Dyasly)
Date: Wed, 3 Jul 2013 19:37:52 +0400
Subject: [PATCH v2] ARM: LPAE: don't reject mapping /dev/mem above 4GB
In-Reply-To: <20130702171530.GG24828@arm.com>
References: <1372780685-2528-1-git-send-email-dserrg@gmail.com>
 <20130702171530.GG24828@arm.com>
Message-ID: <20130703193752.f5b76b6f24bcebbdb7fec379@gmail.com>

On Tue, 2 Jul 2013 18:15:31 +0100
Catalin Marinas <catalin.marinas at arm.com> wrote:
> >  int valid_mmap_phys_addr_range(unsigned long pfn, size_t size)
> >  {
> > -	return !(pfn + (size >> PAGE_SHIFT) > 0x00100000);
> > +	return !(((pfn << PAGE_SHIFT) + size) & ~PHYS_MASK);
> 
> I don't think that's what I suggested. For classic MMU ~PHYS_MASK is 0.
> 

Thanks for your comments!

Indeed, I did some testing today and v2 check doesn't work at all because of
32-bit overflow in case of using '<<' operator. Also, it turned out that v1
doesn't reject mappings > 40 bit in case of LPAE (the same overflow).

I didn't want to additionally define PHYS_MASK_SHIFT, so I came up with
something like:

	return (pfn + (size >> PAGE_SHIFT)) <= (1 + (PHYS_MASK >> PAGE_SHIFT))

I will post v3 tomorrow.

Best regards,
Sergey Dyasly


From festevam at gmail.com  Wed Jul  3 11:40:06 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  3 Jul 2013 12:40:06 -0300
Subject: [PATCH] ARM: mx6: Fix the number of reported cores
Message-ID: <1372866006-3892-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

On a mx6 quad-core processor:

$ cat /proc/cpuinfo                                             
processor       : 0                                                             
model name      : ARMv7 Processor rev 10 (v7l)                                  
BogoMIPS        : 1581.05                                                       
Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls               
CPU implementer : 0x41                                                          
CPU architecture: 7                                                             
CPU variant     : 0x2                                                           
CPU part        : 0xc09                                                         
CPU revision    : 10                                                            

,which incorrectly shows this is a single core device.

Commit a0ae0240 (ARM: kernel: add device tree init map function) introduced the 
following requirement according to Documentation/devicetree/bindings/arm/cpus.txt:
"For the ARM architecture every CPU node must contain the following properties:

- device_type:	must be "cpu" 

Pass the 'device_type' property for each cpu node, so that we can have all the 
four cores correctly reported again.

Cc: <stable at vger.kernel.org> #3.10
Reported-by: Mike Loebl <mloebl at gmail.com> 
Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/imx6dl.dtsi | 2 ++
 arch/arm/boot/dts/imx6q.dtsi  | 4 ++++
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 63fafe2..a4b3e1e 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -16,12 +16,14 @@
 
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu"
 			reg = <0>;
 			next-level-cache = <&L2>;
 		};
 
 		cpu at 1 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu"
 			reg = <1>;
 			next-level-cache = <&L2>;
 		};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index cba021e..f4e9ebf 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -17,6 +17,7 @@
 
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <0>;
 			next-level-cache = <&L2>;
 			operating-points = <
@@ -38,18 +39,21 @@
 
 		cpu at 1 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <1>;
 			next-level-cache = <&L2>;
 		};
 
 		cpu at 2 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <2>;
 			next-level-cache = <&L2>;
 		};
 
 		cpu at 3 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <3>;
 			next-level-cache = <&L2>;
 		};
-- 
1.8.1.2



From richard.genoud at gmail.com  Wed Jul  3 11:51:49 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Wed, 3 Jul 2013 17:51:49 +0200
Subject: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
In-Reply-To: <CACQ1gAhnDk-qSt_5xrsMakXqGGDO5pEbA-9UDWCJG=AABDc+zg@mail.gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-2-git-send-email-richard.genoud@gmail.com>
 <51D24299.9050209@atmel.com>
 <CACQ1gAgcc=j3kmcpjp8bbdHhxr_k=h8jJs6R_paJbPUMv74uGg@mail.gmail.com>
 <51D29927.80900@atmel.com>
 <CACQ1gAhnDk-qSt_5xrsMakXqGGDO5pEbA-9UDWCJG=AABDc+zg@mail.gmail.com>
Message-ID: <CACQ1gAgPaRm3gxxJNgfj9bR565Q0+SNY3+EcjA_mrh1N+yPzSA@mail.gmail.com>

2013/7/3 Richard Genoud <richard.genoud at gmail.com>:
> 2013/7/2 Bo Shen <voice.shen at atmel.com>:
>> Hi Richard,
>>
>>
>> On 7/2/2013 16:13, Richard Genoud wrote:
>>>>
>>>> Please hold on of this, as to the ASoC dmaengine will deal with this. So,
>>>> we
>>>> >not need do it manually.
>>>> >
>>>> >Now, I am working on it. And will send out the patch soon after testing
>>>> > OK.
>>>
>>> Ok, I stay tuned !
>>
>>
>> I think you can go on working with the two patches I send just now.
>> [1]: ASoC: atmel_ssc_dai: move set dma data to startup callback
>> https://patchwork.kernel.org/patch/2811241/
>>
>> [2]: ASoC: atmel-pcm: use generic dmaengine framework
>> https://patchwork.kernel.org/patch/2811261/
>>
>> I use your patches 4 ~ 8 do a quick testing, it works. Please note the name
>> of asound.state under /etc in your rootfs should the same with atmel,model
>> in patch 6.
>
> Thanks for testing !
> I was just doing the same test, it works with
> aplay  -Dplug:default  good_music.wav
>
> but there's a violent hang (kernel stops, no trace) when I try the record :
> arecord -v -V stereo -Dplug:default -f cd -t wav -c 2 /tmp/toto.wav
> last thing I see is :
> dma dma0chan3: atc_control (3)
>
> I'll try to trace that.
I think it's DMA related.
the last thing done by the kernel is:
 i2c i2c-0: i2c_outb: 0x34 A
 i2c i2c-0: i2c_outb: 0x0c A
 i2c i2c-0: i2c_outb: 0x5a A
meaning: enable power on, LINE IN, ADC, OSC, on the WM8731
so, after that, data is comming from the codec to the SSC and then is
handled by the DMA.
there must be something nasty on the DMA bus to hang everything like that...

Richard.


From dinguyen at altera.com  Wed Jul  3 11:09:50 2013
From: dinguyen at altera.com (Dinh Nguyen)
Date: Wed, 3 Jul 2013 10:09:50 -0500
Subject: socfpga: mmc problems
In-Reply-To: <51D43CB0.4070104@communistcode.co.uk>
References: <51D43CB0.4070104@communistcode.co.uk>
Message-ID: <1372864190.9525.6.camel@linux-builds1>

Hi Jack,

On Wed, 2013-07-03 at 16:01 +0100, Jack Mitchell wrote:
> Having received one of the new Arrow SoCkit boards at a recent training 
> day I set about seeing how far mainline was in successfully booting this 
> board.
> 
> As I wanted to boot from mmc, I first checked out linux-next [1] in 
> order to get the newly merged mmc driver, I then applied the device-tree 
> enablement series [2] on top before finally attempting to boot. I then 
> found that the standard socfpga_defconfig didn't enable the MMC drivers, 
> which I also did (should this be part of the socfpga_defconfig...?).

I was going to update this when I enable ethernet as well to avoid less
churn on the defconfig.

> 
> However, the boot hangs at:
> 
> Synopsys Designware Multimedia Card Interface Driver
> dwmmc_socfpga ff704000.dwmmc0: Using internal DMA controller.
> dwmmc_socfpga ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host 
> data width, 1024 deep fifo
> 
> To fix this I checked out the diff between the Altera vendor mmc driver 
> and the mainline driver and found that if I added this small change:
> 
> 
>    if (of_property_read_u32(dev->of_node, "pwr-en", &pwr_en)) {
>      dev_info(dev, "couldn't determine pwr-en, assuming pwr-en = 0\n");
>      pwr_en = 0;
>    }
> 
>    /* Set PWREN bit */
>    mci_writel(host, PWREN, pwr_en);

I tested this on my devkit, which was not made by Arrow, but is _almost_
the same. I'll try to see if I can get my hands on an Arrow board to
reproduce.

> 
> In the dw_mci_socfpga_priv_init function, the board would boot.
> 
> Synopsys Designware Multimedia Card Interface Driver
> dwmmc_socfpga ff704000.dwmmc0: couldn't determine pwr-en, assuming 
> pwr-en = 0
> dwmmc_socfpga ff704000.dwmmc0: Using internal DMA controller.
> dwmmc_socfpga ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host 
> data width, 1024 deep fifo
> mmc_host mmc0: Bus speed (slot 0) = 100000000Hz (slot req 400000Hz, 
> actual 400000HZ div = 125)
> dwmmc_socfpga ff704000.dwmmc0: 1 slots initialized
> dwmmc_socfpga ff704000.dwmmc0: Version ID is 240a
> .....
> .....
> .....
> 
> 
> Has this been overlooked, or are there some other changes elsewhere that 
> I haven't yet come across which addresses this?

I'm not aware of any other changes.

Dinh
> 
> Cheers,
> 
> [1] fa1383200d289afdff2f5678eb89483daa537465
> [2] http://comments.gmane.org/gmane.linux.ports.arm.kernel/243529
> 





From ml at communistcode.co.uk  Wed Jul  3 11:01:04 2013
From: ml at communistcode.co.uk (Jack Mitchell)
Date: Wed, 03 Jul 2013 16:01:04 +0100
Subject: socfpga: mmc problems
Message-ID: <51D43CB0.4070104@communistcode.co.uk>

Having received one of the new Arrow SoCkit boards at a recent training 
day I set about seeing how far mainline was in successfully booting this 
board.

As I wanted to boot from mmc, I first checked out linux-next [1] in 
order to get the newly merged mmc driver, I then applied the device-tree 
enablement series [2] on top before finally attempting to boot. I then 
found that the standard socfpga_defconfig didn't enable the MMC drivers, 
which I also did (should this be part of the socfpga_defconfig...?).

However, the boot hangs at:

Synopsys Designware Multimedia Card Interface Driver
dwmmc_socfpga ff704000.dwmmc0: Using internal DMA controller.
dwmmc_socfpga ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host 
data width, 1024 deep fifo

To fix this I checked out the diff between the Altera vendor mmc driver 
and the mainline driver and found that if I added this small change:


   if (of_property_read_u32(dev->of_node, "pwr-en", &pwr_en)) {
     dev_info(dev, "couldn't determine pwr-en, assuming pwr-en = 0\n");
     pwr_en = 0;
   }

   /* Set PWREN bit */
   mci_writel(host, PWREN, pwr_en);

In the dw_mci_socfpga_priv_init function, the board would boot.

Synopsys Designware Multimedia Card Interface Driver
dwmmc_socfpga ff704000.dwmmc0: couldn't determine pwr-en, assuming 
pwr-en = 0
dwmmc_socfpga ff704000.dwmmc0: Using internal DMA controller.
dwmmc_socfpga ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host 
data width, 1024 deep fifo
mmc_host mmc0: Bus speed (slot 0) = 100000000Hz (slot req 400000Hz, 
actual 400000HZ div = 125)
dwmmc_socfpga ff704000.dwmmc0: 1 slots initialized
dwmmc_socfpga ff704000.dwmmc0: Version ID is 240a
.....
.....
.....


Has this been overlooked, or are there some other changes elsewhere that 
I haven't yet come across which addresses this?

Cheers,

[1] fa1383200d289afdff2f5678eb89483daa537465
[2] http://comments.gmane.org/gmane.linux.ports.arm.kernel/243529

-- 

   Jack Mitchell (jack at embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--


From stefano.stabellini at eu.citrix.com  Wed Jul  3 11:59:37 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 3 Jul 2013 16:59:37 +0100
Subject: [Xen-devel] [PATCH RFC] xen/arm: domain kernel: Small fixes for
 making suspendable for arm
In-Reply-To: <1372842988-27547-1-git-send-email-jaeyong.yoo@samsung.com>
References: <1372842988-27547-1-git-send-email-jaeyong.yoo@samsung.com>
Message-ID: <alpine.DEB.2.02.1307031440350.5067@kaball.uk.xensource.com>

On Wed, 3 Jul 2013, Jaeyong Yoo wrote:
> Modify makefile to compile driver/xen/manage.c for arm and implement
> resuming the shared page info. This patch is required for domu kernel
> to test the xen-on-arndale migration.
> 
> Since there are lot of missing functions for compiling hibernation mode,
> temporarily I put empty functions in xen/dummy.c, but they are originally
> belong to such as arch/arm/power directories (which is not existing).
> I think there would be any better way...
> 
> Signed-off-by: Jaeyong Yoo <jaeyong.yoo at samsung.com>
>
>  arch/arm/Kconfig                |  3 ++
>  arch/arm/boot/dts/xenvm-4.2.dts |  2 +-
>  arch/arm/xen/Makefile           |  2 +-
>  arch/arm/xen/dummy.c            | 30 ++++++++++++++++
>  arch/arm/xen/mmu.c              | 12 +++++++
>  arch/arm/xen/suspend.c          | 76 +++++++++++++++++++++++++++++++++++++++++
>  arch/arm/xen/time.c             |  7 ++++

Be careful that xen for arm64 just went upstream and it's just
recompiling the same Xen files under arm64.  See arch/arm64/xen.
The changes you make to c files under arch/arm/xen need to compile on
arm64 too.


>  drivers/xen/Makefile            |  2 +-
>  drivers/xen/manage.c            |  8 +++++
>  9 files changed, 139 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/xen/dummy.c
>  create mode 100644 arch/arm/xen/mmu.c
>  create mode 100644 arch/arm/xen/suspend.c
>  create mode 100644 arch/arm/xen/time.c
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2c3bdce..77309f7 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1469,6 +1469,9 @@ config ARCH_NO_VIRT_TO_BUS
>  config ISA_DMA_API
>  	bool
>  
> +config ARCH_HIBERNATION_POSSIBLE
> +        def_bool y
> +

This could be an issue because if you introduce this symbol you allow
users to compile hibernation code on all arm platforms.
At the very least it should have "depends on XEN".



>  config PCI
>  	bool "PCI support" if MIGHT_HAVE_PCI
>  	help
>
> diff --git a/arch/arm/boot/dts/xenvm-4.2.dts b/arch/arm/boot/dts/xenvm-4.2.dts
> index 2f4136b..33df5e6 100644
> --- a/arch/arm/boot/dts/xenvm-4.2.dts
> +++ b/arch/arm/boot/dts/xenvm-4.2.dts
> @@ -17,7 +17,7 @@
>  
>  	chosen {
>  		/* this field is going to be adjusted by the hypervisor */
> -		bootargs = "console=hvc0 root=/dev/xvda";
> +		bootargs = "console=hvc0 root=/dev/xvda1 rw init";
>  	};
>  
>  	cpus {

please remove this change, this dts is just an example


> diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
> index 4384103..6fdc47a 100644
> --- a/arch/arm/xen/Makefile
> +++ b/arch/arm/xen/Makefile
> @@ -1 +1 @@
> -obj-y		:= enlighten.o hypercall.o grant-table.o
> +obj-y		:= enlighten.o hypercall.o grant-table.o suspend.o mmu.o time.o dummy.o
> diff --git a/arch/arm/xen/dummy.c b/arch/arm/xen/dummy.c
> new file mode 100644
> index 0000000..daa949c
> --- /dev/null
> +++ b/arch/arm/xen/dummy.c
> @@ -0,0 +1,30 @@
> +#include <linux/kernel.h>
> +#include <linux/printk.h>
> +
> +void save_processor_state(void)
> +{
> +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> +}
> +
> +void restore_processor_state(void)
> +{
> +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> +}
> +
> +int swsusp_arch_suspend(void)
> +{
> +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> +	return 0;
> +}
> +
> +int swsusp_arch_resume(void)
> +{
> +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> +	return 0;
> +}
> +
> +int pfn_is_nosave(unsigned long pfn)
> +{
> +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> +	return 0;
> +}

These functions are not Xen specific, they should not be under
arch/arm/xen.
Maybe we could put them under arch/arm/power or drivers/xen?



> diff --git a/arch/arm/xen/mmu.c b/arch/arm/xen/mmu.c
> new file mode 100644
> index 0000000..cc0ccc9
> --- /dev/null
> +++ b/arch/arm/xen/mmu.c
> @@ -0,0 +1,12 @@
> +#include <linux/kernel.h>
> +#include <xen/xen.h>
> +
> +void xen_mm_pin_all(void)
> +{
> +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> +}
> +
> +void xen_mm_unpin_all(void)
> +{
> +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> +}

No need to print an error here, I would just add a comment saying "no
need to pin/unpin anything because we are always using second stage
translation".


> diff --git a/arch/arm/xen/suspend.c b/arch/arm/xen/suspend.c
> new file mode 100644
> index 0000000..946a960
> --- /dev/null
> +++ b/arch/arm/xen/suspend.c
> @@ -0,0 +1,76 @@
> +#include <xen/xen.h>
> +#include <xen/events.h>
> +#include <xen/grant_table.h>
> +#include <xen/hvm.h>
> +#include <xen/interface/vcpu.h>
> +#include <xen/interface/xen.h>
> +#include <xen/interface/memory.h>
> +#include <xen/interface/hvm/params.h>
> +#include <xen/features.h>
> +#include <xen/platform_pci.h>
> +#include <xen/xenbus.h>
> +#include <xen/page.h>
> +#include <xen/xen-ops.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqreturn.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_address.h>
> +
> +#include <linux/mm.h>
> +
> +void xen_arch_pre_suspend(void)
> +{
> +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> +}

if we don't need to do anything, it's not an error.


> +void xen_arch_hvm_post_suspend(int suspend_cancelled)
> +{
> +	if( !suspend_cancelled ) {
> +		int cpu;
> +		struct xen_add_to_physmap xatp;
> +		static struct shared_info *shared_info_page = 0;
> +
> +		if( !shared_info_page )
> +			shared_info_page = (struct shared_info *)
> +				get_zeroed_page(GFP_KERNEL);
> +		if (!shared_info_page) {
> +			pr_err("not enough memory\n");
> +			return;
> +		}
> +
> +		xatp.domid = DOMID_SELF;
> +		xatp.idx = 0;
> +		xatp.space = XENMAPSPACE_shared_info;
> +		xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
> +		if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
> +			BUG();
> +
> +		HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
> +
> +		/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
> +		 * page, we use it in the event channel upcall */
> +		for_each_online_cpu(cpu) {
> +			per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
> +		}
> +		printk(KERN_ERR"%s: remmaping shared info...\n", __func__);
> +	}
> +}

It would be good to refactor the shared_info page setup on a separate
function that can be called from xen_guest_init and from
xen_arch_hvm_post_suspend, like we do on x86.


> +void xen_arch_post_suspend(int suspend_cancelled)
> +{
> +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> +}
> +
> +static void xen_vcpu_notify_restore(void *data)
> +{
> +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> +}
> +
> +void xen_arch_resume(void)
> +{
> +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> +}

if don't need to do anything, it's not an error.


> diff --git a/arch/arm/xen/time.c b/arch/arm/xen/time.c
> new file mode 100644
> index 0000000..af90e53
> --- /dev/null
> +++ b/arch/arm/xen/time.c
> @@ -0,0 +1,7 @@
> +#include <linux/kernel.h>
> +#include <xen/xen.h>
> +
> +void xen_timer_resume(void)
> +{
> +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> +}

same here


> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index eabd0ee..3d24a95 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -1,10 +1,10 @@
>  ifneq ($(CONFIG_ARM),y)
> -obj-y	+= manage.o
>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>  endif
>  obj-$(CONFIG_X86)			+= fallback.o
>  obj-y	+= grant-table.o features.o events.o balloon.o
>  obj-y	+= xenbus/
> +obj-y	+= manage.o
>  
>  nostackp := $(call cc-option, -fno-stack-protector)
>  CFLAGS_features.o			:= $(nostackp)
> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
> index 412b96c..140c7a9 100644
> --- a/drivers/xen/manage.c
> +++ b/drivers/xen/manage.c
> @@ -17,6 +17,7 @@
>  #include <xen/events.h>
>  #include <xen/hvc-console.h>
>  #include <xen/xen-ops.h>
> +#include <xen/interface/sched.h>
>  
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/page.h>
> @@ -86,7 +87,14 @@ static int xen_suspend(void *data)
>  	 * or the domain was merely checkpointed, and 0 if it
>  	 * is resuming in a new domain.
>  	 */
> +#ifdef CONFIG_ARM
> +	{
> +		struct sched_shutdown r = { .reason = SHUTDOWN_suspend };
> +		HYPERVISOR_sched_op(SCHEDOP_shutdown, &r);
> +	}
> +#else
>  	si->cancelled = HYPERVISOR_suspend(si->arg);
> +#endif
>  
>  	if (si->post)
>  		si->post(si->cancelled);

We should implement HYPERVISOR_suspend on ARM


From coelho at ti.com  Wed Jul  3 09:45:32 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 3 Jul 2013 16:45:32 +0300
Subject: [PATCH v2 0/9] wilink: add device tree support
In-Reply-To: <CANOLnOPBHesTiV61zpQ_QS9c7E91K50EnbMnGhvgaViuA_3=Bw@mail.gmail.com>
References: <1372776948-24840-1-git-send-email-coelho@ti.com>
 <CANOLnOPBHesTiV61zpQ_QS9c7E91K50EnbMnGhvgaViuA_3=Bw@mail.gmail.com>
Message-ID: <1372859132.21065.111.camel@cumari.coelho.fi>

On Wed, 2013-07-03 at 13:13 +0300, Grazvydas Ignotas wrote:
> Hi,

Hi Gra?vydas,


> On Tue, Jul 2, 2013 at 5:55 PM, Luciano Coelho <coelho at ti.com> wrote:
> > Hi,
> >
> > This is a follow-up on a previous patch set that had a smaller
> > audience.  This time, I added the lists and people who were involved
> > in the review of the bindings documentation, since most of my changes
> > in v2 are coming from discussions there.
> >
> > This patch series adds device tree support to the wlcore_sdio driver,
> > which is used by WiLink6, WiLink7 and WiLink8.
> 
> Could you perhaps consider doing device tree conversion for wl1251
> too? With the knowledge you have from working on this series, it would
> be much easier for you to do it than for someone else, and I don't
> have much hope someone will do it at all. It's WiLink series chip
> after all. Without this pandora and N900 are going to lose wifi
> support after the switch to dt-only kernel.

Unfortunately I don't have much time to work on wl1251.  I think it
wouldn't be too difficult to do though, so patches are welcome. ;)

Maybe you could try to make this change and I could support you if
needed?


> I can offer you my help testing things on pandora and I'm sure someone
> here could try it on N900.

I could try it on the N900, if it is still bootable easily with the
mainline. ;)

--
Cheers,
Luca.



From broonie at kernel.org  Wed Jul  3 12:02:18 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 3 Jul 2013 17:02:18 +0100
Subject: [PATCH v9 01/10] ASoC: imx-pcm-dma: DT support
In-Reply-To: <1371734429-6081-2-git-send-email-mpa@pengutronix.de>
References: <1371734429-6081-1-git-send-email-mpa@pengutronix.de>
 <1371734429-6081-2-git-send-email-mpa@pengutronix.de>
Message-ID: <20130703160218.GO27646@sirena.org.uk>

On Thu, Jun 20, 2013 at 03:20:20PM +0200, Markus Pargmann wrote:
> This patch removes the NO_DT flag. The pdev pointer may have a proper
> of_node with the dmas property, so we can use it to request DMA
> channels.

Applied, thanks.
-------------- 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/20130703/88ac9765/attachment.sig>

From broonie at kernel.org  Wed Jul  3 12:02:31 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 3 Jul 2013 17:02:31 +0100
Subject: [PATCH v9 02/10] ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
In-Reply-To: <1371734429-6081-3-git-send-email-mpa@pengutronix.de>
References: <1371734429-6081-1-git-send-email-mpa@pengutronix.de>
 <1371734429-6081-3-git-send-email-mpa@pengutronix.de>
Message-ID: <20130703160231.GP27646@sirena.org.uk>

On Thu, Jun 20, 2013 at 03:20:21PM +0200, Markus Pargmann wrote:
> Cleaner parameter passing for imx-pcm-fiq. Create a seperated fiq-params
> struct to pass all arguments.

Applied, thanks.
-------------- 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/20130703/b798cf23/attachment.sig>

From arnd at arndb.de  Wed Jul  3 12:03:04 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 3 Jul 2013 18:03:04 +0200
Subject: scripts/kallsyms: Avoid ARM veneer symbols
In-Reply-To: <20130625150941.GF2327@linaro.org>
References: <2983817.Xe2505Drlj@wuerfel> <20130625150941.GF2327@linaro.org>
Message-ID: <201307031803.04501.arnd@arndb.de>

On Tuesday 25 June 2013, Dave Martin wrote:
> On Mon, Jun 24, 2013 at 04:01:43PM +0200, Arnd Bergmann wrote:
> > When building ARM kernels that exceed a certain size, the linker
> > will add "veneers" that allow long branches. Unfortunately,
> > using a longer kallsyms section may lead to the extra veneers
> > being needed, which leads to inconsistent kallsyms data with the
> > message
> > 
> > Inconsistent kallsyms data
> > Try make KALLSYMS_EXTRA_PASS=1 as a workaround
> > 
> > In some case, not just one but up to three extra passes were
> > needed before getting to a state that needed no extra veneers.
> 
> Do you understand why this was happening?  It sounds like there
> must have been branches crossing from one side of the kallsyms
> data to the other, triggering veneer insertion any time the
> kallsyms data grows.
> 
> Branches between .{init,exit}.text and .text (crossing .rodata) seem the
> likeliest culprits, but that's guesswork on my part.

kallsyms is part of rodata, which is between .text and .init.text.
I understand this is intentional, and we already use two passes
of kallsyms to make sure the size is right. However the assumption
is that only the data of the kallsyms table changes between runs,
not the size of it.

> If that's whats going on, multiple kallsyms passes is actually a correct
> approach here: I think they should terminate after a number of steps
> roughly proportional to log(number of branches across .rodata). We
> could come up with a heuristic which allows us to choose the right
> limit with a high degree of reliability, since branch density in
> compiled C code is likely to be roughly.

It also seems to be a part of the design to do exactly two passes
and treat anything beyond that as bugs, doing it the way you
suggest would significantly increase the build time since the
kallsyms+linker stage cannot be done in parallel or sped up
using ccache.

> But including the veneer symbols in kallsyms is arguably not all
> that useful.
> 
> The main potential effect is that profiling might occasionally
> sample the PC as being in a completely bogus function which it
> never passed through at all, because of the way kallsyms tracks
> only symbol locations and not sizes (if I remember right) --
> so a veneer will actually get accounted against some arbitrary
> adjacent function.
> 
> I don't know how much this matters.

Interesting point. No idea how often that happens. All the veneers
for one section are in one place though, so we could in theory
add a kallsyms entry for that section as long as can identify
it.

> > The easiest solution is to skip veneers in kallsyms in the
> > same way we already skip a couple of other symbols.
> 
> The other symbols are not stripped for the purpose of making
> kallsyms terminate quickly.  The mapping symbols are rather
> different: masses of symbols with duplicate names which are
> not very interesting for most people.

Right.

> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > ---
> > diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
> > index 487ac6f..53ec0bb 100644
> > --- a/scripts/kallsyms.c
> > +++ b/scripts/kallsyms.c
> > @@ -69,14 +69,32 @@ static void usage(void)
> >  	exit(1);
> >  }
> >  
> > -/*
> > - * This ignores the intensely annoying "mapping symbols" found
> > - * in ARM ELF files: $a, $t and $d.
> > - */
> >  static inline int is_arm_mapping_symbol(const char *str)
> 
> The function's name is now wrong.  Should it be renamed or split up?

Sure I can rename it. Any suggestions?

	Arnd


From Ian.Campbell at citrix.com  Wed Jul  3 12:04:57 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Wed, 3 Jul 2013 17:04:57 +0100
Subject: [Xen-devel] [PATCH RFC] xen/arm: domain kernel: Small fixes for
 making suspendable for arm
In-Reply-To: <alpine.DEB.2.02.1307031440350.5067@kaball.uk.xensource.com>
References: <1372842988-27547-1-git-send-email-jaeyong.yoo@samsung.com>
 <alpine.DEB.2.02.1307031440350.5067@kaball.uk.xensource.com>
Message-ID: <1372867497.27768.282.camel@zakaz.uk.xensource.com>

On Wed, 2013-07-03 at 16:59 +0100, Stefano Stabellini wrote:

> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 2c3bdce..77309f7 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1469,6 +1469,9 @@ config ARCH_NO_VIRT_TO_BUS
> >  config ISA_DMA_API
> >  	bool
> >  
> > +config ARCH_HIBERNATION_POSSIBLE
> > +        def_bool y
> > +
> 
> This could be an issue because if you introduce this symbol you allow
> users to compile hibernation code on all arm platforms.
> At the very least it should have "depends on XEN".
> 
[...]
> > +void save_processor_state(void)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> > +}
> > +
> > +void restore_processor_state(void)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> > +}
> > +
> > +int swsusp_arch_suspend(void)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> > +	return 0;
> > +}
> > +
> > +int swsusp_arch_resume(void)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> > +	return 0;
> > +}
> > +
> > +int pfn_is_nosave(unsigned long pfn)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> > +	return 0;
> > +}
> 
> These functions are not Xen specific, they should not be under
> arch/arm/xen.
> Maybe we could put them under arch/arm/power or drivers/xen?

Together with the spurious config symbol this suggests that perhaps the
hibernation interface is not the right one to be using for Xen on ARM.

How does this work on native ARM I wonder?

Ian.



From balbi at ti.com  Wed Jul  3 10:19:48 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Jul 2013 17:19:48 +0300
Subject: [PATCH v3 8/8] wlcore/wl12xx: check if we got correct clock data
 from DT
In-Reply-To: <1372860209-3504-9-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
 <1372860209-3504-9-git-send-email-coelho@ti.com>
Message-ID: <20130703141948.GS15056@arwen.pp.htv.fi>

On Wed, Jul 03, 2013 at 05:03:29PM +0300, Luciano Coelho wrote:
> The fref and the tcxo clocks settings are optional in some platforms.
> WiLink8 doesn't need either, so we don't check the values.  WiLink 6
> only needs the fref clock, so we check that it is valid or return with
> an error.  WiLink7 needs both clocks, if either is not available we
> return with an error.
> 
> Signed-off-by: Luciano Coelho <coelho at ti.com>

Reviewed-by: Felipe Balbi <balbi at ti.com>

-- 
balbi
-------------- 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/20130703/e00fbc09/attachment.sig>

From tom.leiming at gmail.com  Wed Jul  3 10:15:50 2013
From: tom.leiming at gmail.com (Ming Lei)
Date: Wed, 3 Jul 2013 22:15:50 +0800
Subject: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is
 64-bits
In-Reply-To: <517AF270.8040106@gmail.com>
References: <1367008266-1431-1-git-send-email-lauraa@codeaurora.org>
 <517AF270.8040106@gmail.com>
Message-ID: <CACVXFVPfkqP+UyoGd-+QFRzndSam_DtU=utrBPYCPjQCGQ_F6g@mail.gmail.com>

On Sat, Apr 27, 2013 at 5:32 AM, Rob Herring <robherring2 at gmail.com> wrote:
> On 04/26/2013 03:31 PM, Laura Abbott wrote:
>> Currently, of_platform_device_create_pdata always sets the
>> coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA,
>> arm_dma_limit gets set to ~0 or 0xFFFFFFFFFFFFFFFF on LPAE based
>> systems. Since arm_dma_limit represents the smallest dma_mask
>> on the system, the default of 32 bits prevents any dma_coherent
>> allocation from succeeding unless clients manually set the
>> dma mask first. Rather than make every client on an LPAE system set
>> the mask manually, account for the size of dma_addr_t when setting
>> the coherent mask.
>>
>> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
>> ---
>>  drivers/of/platform.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index 0970505..5f0ba94 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -214,7 +214,7 @@ struct platform_device *of_platform_device_create_pdata(
>>  #if defined(CONFIG_MICROBLAZE)
>>       dev->archdata.dma_mask = 0xffffffffUL;
>>  #endif
>> -     dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> +     dev->dev.coherent_dma_mask = DMA_BIT_MASK(sizeof(dma_addr_t) * 8);
>
> This is going to change the mask from 32 to 64 bits on 64-bit powerpc
> and others possibly. Maybe it doesn't matter. I think it doesn't, but
> I'm not sure enough to apply for 3.10. So I'll queue it for 3.11.

Without the patch, LPAE enabled board may not boot at all, but looks
it still isn't in -next tree.

But I am wondering if it is a correct approach, because enabling LPAE
doesn't mean the I/O devices can support DMA to/from 64bit address, and
it is very probably devices can't do it at all.

Another way is to always set arm_dma_limit as 0xFFFFFFFF when
CONFIG_ZONE_DMA is unset, and let driver override device's dma
mask if the device supports 64bit DMA.

Thanks,
-- 
Ming Lei


From broonie at kernel.org  Wed Jul  3 12:06:37 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 3 Jul 2013 17:06:37 +0100
Subject: [PATCH v9 04/10] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <1371734429-6081-5-git-send-email-mpa@pengutronix.de>
References: <1371734429-6081-1-git-send-email-mpa@pengutronix.de>
 <1371734429-6081-5-git-send-email-mpa@pengutronix.de>
Message-ID: <20130703160637.GQ27646@sirena.org.uk>

On Thu, Jun 20, 2013 at 03:20:23PM +0200, Markus Pargmann wrote:

> +	ssi_private->use_dma = !of_property_read_bool(np, "fsl,imx-fiq");
> +

This binding should be documented.  I'm not sure it really needs to be
a binding, though - is it not possible for the driver to just figure out
that DMA won't work automatically (for example by looking at the CODEC
in use)?  I'm not sure this is a good name either, it should be saying
why the FIQ is needed rather than saying that we should use the FIQ.
-------------- 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/20130703/3c369fbd/attachment.sig>

From balbi at ti.com  Wed Jul  3 10:14:03 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Jul 2013 17:14:03 +0300
Subject: [PATCH v3 3/8] wlcore: remove pwr_in_suspend from platform data
In-Reply-To: <1372860209-3504-4-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
 <1372860209-3504-4-git-send-email-coelho@ti.com>
Message-ID: <20130703141403.GP15056@arwen.pp.htv.fi>

On Wed, Jul 03, 2013 at 05:03:24PM +0300, Luciano Coelho wrote:
> The pwr_in_suspend flag depends on the MMC settings which can be
> retrieved from the SDIO subsystem, so it doesn't need to be part of
> the platform data structure.  Move it to the platform device data that
> is passed from SDIO to wlcore.
> 
> Signed-off-by: Luciano Coelho <coelho at ti.com>

Reviewed-by: Felipe Balbi <balbi at ti.com>

-- 
balbi
-------------- 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/20130703/93a6706d/attachment.sig>

From broonie at kernel.org  Wed Jul  3 12:07:47 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 3 Jul 2013 17:07:47 +0100
Subject: [PATCH v9 03/10] ASoC: fsl: Move soc_ac97_ops from imx-ssi to
 fsl_ssi
In-Reply-To: <1371734429-6081-4-git-send-email-mpa@pengutronix.de>
References: <1371734429-6081-1-git-send-email-mpa@pengutronix.de>
 <1371734429-6081-4-git-send-email-mpa@pengutronix.de>
Message-ID: <20130703160747.GR27646@sirena.org.uk>

On Thu, Jun 20, 2013 at 03:20:22PM +0200, Markus Pargmann wrote:
> fsl_ssi and imx-ssi can be both enabled at the same time. To be able to
> add AC97 support to fsl_ssi, soc_ac97_ops have to be available to both
> drivers.

This needs to be redone on top of the changes that went into v3.11 to
support multiplatform AC'97 - it won't apply any more.
-------------- 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/20130703/fb7c3d28/attachment.sig>

From coelho at ti.com  Wed Jul  3 10:03:28 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 3 Jul 2013 17:03:28 +0300
Subject: [PATCH v3 7/8] wlcore: sdio: get clocks from device tree
In-Reply-To: <1372860209-3504-1-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
Message-ID: <1372860209-3504-8-git-send-email-coelho@ti.com>

Read the clock nodes from the device tree and use them to set the
frequency for the refclock and the tcxo clock.

Also, call sdio_set_drvdata() earlier, so the glue is already set in
the driver data when we call wlcore_get_pdata_from_of() and we don't
need to pass it as a parameter.

Signed-off-by: Luciano Coelho <coelho at ti.com>
Reviewed-by: Felipe Balbi <balbi at ti.com>
---
 drivers/net/wireless/ti/wlcore/sdio.c |   36 +++++++++++++++++++++++++++++++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 980bf3d..60fce49 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -53,6 +53,7 @@ static bool dump = false;
 struct wl12xx_sdio_glue {
 	struct device *dev;
 	struct platform_device *core;
+	struct clk *refclock, *tcxoclock;
 };
 
 static const struct sdio_device_id wl1271_devices[] = {
@@ -224,6 +225,7 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 	struct wl12xx_platform_data *pdata;
 	struct device_node *np = dev->of_node;
 	struct device_node *clock_node;
+	struct wl12xx_sdio_glue *glue = sdio_get_drvdata(dev_to_sdio_func(dev));
 
 	if (!np) {
 		np = of_find_matching_node(NULL, dev->driver->of_match_table);
@@ -250,6 +252,26 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 	for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
 		of_fixed_clk_setup(clock_node);
 
+	/* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
+	glue->refclock = of_clk_get_by_name(np, "refclock");
+	if (IS_ERR(glue->refclock)) {
+		dev_err(dev, "couldn't find refclock on the device tree\n");
+		glue->refclock = NULL;
+	} else {
+		clk_prepare_enable(glue->refclock);
+		pdata->ref_clock_freq = clk_get_rate(glue->refclock);
+	}
+
+	/* TODO: make sure we have this when needed (ie. for WL7) */
+	glue->tcxoclock = of_clk_get_by_name(np, "tcxoclock");
+	if (IS_ERR(glue->tcxoclock)) {
+		dev_err(dev, "couldn't find tcxoclock on the device tree\n");
+		glue->tcxoclock = NULL;
+	} else {
+		clk_prepare_enable(glue->tcxoclock);
+		pdata->ref_clock_freq = clk_get_rate(glue->tcxoclock);
+	}
+
 	goto out;
 
 out_free:
@@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func,
 	/* Use block mode for transferring over one block size of data */
 	func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
+	sdio_set_drvdata(func, glue);
+
 	/* The pdata allocated here is freed when the device is freed,
 	 * so we don't need an additional out label to free it in case
 	 * of error further on.
@@ -319,8 +343,6 @@ static int wl1271_probe(struct sdio_func *func,
 	if (mmcflags & MMC_PM_KEEP_POWER)
 		pdev_data->pwr_in_suspend = true;
 
-	sdio_set_drvdata(func, glue);
-
 	/* Tell PM core that we don't need the card to be powered now */
 	pm_runtime_put_noidle(&func->dev);
 
@@ -387,6 +409,16 @@ static void wl1271_remove(struct sdio_func *func)
 {
 	struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
 
+	if (glue->refclock) {
+		clk_disable_unprepare(glue->refclock);
+		clk_put(glue->refclock);
+	}
+
+	if (glue->tcxoclock) {
+		clk_disable_unprepare(glue->tcxoclock);
+		clk_put(glue->tcxoclock);
+	}
+
 	/* Undo decrement done above in wl1271_probe */
 	pm_runtime_get_noresume(&func->dev);
 
-- 
1.7.10.4



From coelho at ti.com  Wed Jul  3 10:03:27 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 3 Jul 2013 17:03:27 +0300
Subject: [PATCH v3 6/8] wlcore: sdio: add wilink clock providers
In-Reply-To: <1372860209-3504-1-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
Message-ID: <1372860209-3504-7-git-send-email-coelho@ti.com>

Add refclock and tcxoclock as clock providers in WiLink.  These clocks
are not accesible outside the WiLink module, but they are registered
in the clock framework anyway.  Only the WiLink chip consumes these
clocks.

In theory, the WiLink chip could be connected to external clocks
instead of using these internal clocks, so make the clock consumer
code generic enough.  If external clocks are used, then the internal
clock device tree nodes are not necessary, but the external ones must
be specified.

Signed-off-by: Luciano Coelho <coelho at ti.com>
Reviewed-by: Felipe Balbi <balbi at ti.com>
---
 drivers/net/wireless/ti/wlcore/sdio.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 9370d7e..980bf3d 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,7 @@
 #include <linux/wl12xx.h>
 #include <linux/pm_runtime.h>
 #include <linux/printk.h>
+#include <linux/clk-provider.h>
 
 #include "wlcore.h"
 #include "wl12xx_80211.h"
@@ -214,10 +215,15 @@ static struct wl1271_if_operations sdio_ops = {
 	.set_block_size = wl1271_sdio_set_block_size,
 };
 
+static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
+	{ .compatible = "ti,wilink-clock" },
+};
+
 static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 {
 	struct wl12xx_platform_data *pdata;
 	struct device_node *np = dev->of_node;
+	struct device_node *clock_node;
 
 	if (!np) {
 		np = of_find_matching_node(NULL, dev->driver->of_match_table);
@@ -241,6 +247,9 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 		goto out_free;
 	}
 
+	for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
+		of_fixed_clk_setup(clock_node);
+
 	goto out;
 
 out_free:
-- 
1.7.10.4



From coelho at ti.com  Wed Jul  3 10:03:24 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 3 Jul 2013 17:03:24 +0300
Subject: [PATCH v3 3/8] wlcore: remove pwr_in_suspend from platform data
In-Reply-To: <1372860209-3504-1-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
Message-ID: <1372860209-3504-4-git-send-email-coelho@ti.com>

The pwr_in_suspend flag depends on the MMC settings which can be
retrieved from the SDIO subsystem, so it doesn't need to be part of
the platform data structure.  Move it to the platform device data that
is passed from SDIO to wlcore.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 drivers/net/wireless/ti/wlcore/main.c     |    2 +-
 drivers/net/wireless/ti/wlcore/sdio.c     |    2 +-
 drivers/net/wireless/ti/wlcore/wlcore_i.h |    1 +
 include/linux/wl12xx.h                    |    1 -
 4 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 7b5d0cc..aada037 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5952,7 +5952,7 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
 	if (!ret) {
 		wl->irq_wake_enabled = true;
 		device_init_wakeup(wl->dev, 1);
-		if (pdata->pwr_in_suspend)
+		if (pdev_data->pwr_in_suspend)
 			wl->hw->wiphy->wowlan = &wlcore_wowlan_support;
 	}
 #endif
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 29ef249..4c7e8ac 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -260,7 +260,7 @@ static int wl1271_probe(struct sdio_func *func,
 	dev_dbg(glue->dev, "sdio PM caps = 0x%x\n", mmcflags);
 
 	if (mmcflags & MMC_PM_KEEP_POWER)
-		pdev_data->pdata->pwr_in_suspend = true;
+		pdev_data->pwr_in_suspend = true;
 
 	sdio_set_drvdata(func, glue);
 
diff --git a/drivers/net/wireless/ti/wlcore/wlcore_i.h b/drivers/net/wireless/ti/wlcore/wlcore_i.h
index e5e1464..f2c4227 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore_i.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore_i.h
@@ -209,6 +209,7 @@ struct wl1271_if_operations {
 struct wlcore_platdev_data {
 	struct wl12xx_platform_data *pdata;
 	struct wl1271_if_operations *if_ops;
+	bool pwr_in_suspend;
 };
 
 #define MAX_NUM_KEYS 14
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 1bfcd19..ab90b1c 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -59,7 +59,6 @@ struct wl12xx_platform_data {
 	int irq;
 	int board_ref_clock;
 	int board_tcxo_clock;
-	bool pwr_in_suspend;
 };
 
 #ifdef CONFIG_WILINK_PLATFORM_DATA
-- 
1.7.10.4



From coelho at ti.com  Wed Jul  3 10:03:25 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 3 Jul 2013 17:03:25 +0300
Subject: [PATCH v3 4/8] wl12xx: use frequency instead of enumerations for
 pdata clocks
In-Reply-To: <1372860209-3504-1-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
Message-ID: <1372860209-3504-5-git-send-email-coelho@ti.com>

Instead of defining an enumeration with the FW specific values for the
different clock rates, use the actual frequency instead.  Also add a
boolean to specify whether the clock is XTAL or not.

Change all board files to reflect this.

Cc: Tony Lindgren <tony at atomide.com>
Cc: Sekhar Nori <nsekhar at ti.com>
Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 arch/arm/mach-davinci/board-da850-evm.c      |    3 +-
 arch/arm/mach-omap2/board-4430sdp.c          |    5 ++-
 arch/arm/mach-omap2/board-omap3evm.c         |    3 +-
 arch/arm/mach-omap2/board-omap4panda.c       |    3 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c |    3 +-
 drivers/net/wireless/ti/wl12xx/main.c        |   57 +++++++++++++++++++++++++-
 drivers/net/wireless/ti/wl12xx/wl12xx.h      |   28 +++++++++++++
 include/linux/wl12xx.h                       |   27 ++----------
 8 files changed, 97 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 544b6fa..eddced8 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1377,7 +1377,8 @@ static const short da850_wl12xx_pins[] __initconst = {
 
 static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
 	.irq			= -1,
-	.board_ref_clock	= WL12XX_REFCLOCK_38,
+	.ref_clock_freq		= 38400000,
+	.ref_clock_xtal		= false,
 };
 
 static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 953f620..0d3cb10 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -693,8 +693,9 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
 }
 
 static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
-	.board_ref_clock = WL12XX_REFCLOCK_26,
-	.board_tcxo_clock = WL12XX_TCXOCLOCK_26,
+	.ref_clock_freq = 26000000,
+	.ref_clock_xtal = false,
+	.tcxo_clock_freq = 26000000,
 };
 
 static void __init omap4_sdp4430_wifi_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 8abce3cd..8f953ed 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -458,7 +458,8 @@ static struct platform_device omap3evm_wlan_regulator = {
 };
 
 struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
-	.board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+	.ref_clock_freq = 38400000,
+	.ref_clock_xtal = false,
 };
 #endif
 
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 5b33626..b90fd4c 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -230,7 +230,8 @@ static struct platform_device omap_vwlan_device = {
 };
 
 static struct wl12xx_platform_data omap_panda_wlan_data  __initdata = {
-	.board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+	.ref_clock_freq = 38400000,
+	.ref_clock_xtal = false,
 };
 
 static struct twl6040_codec_data twl6040_codec = {
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 4f84cf9..83a9a36 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -244,7 +244,8 @@ static struct platform_device *zoom_devices[] __initdata = {
 };
 
 static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
-	.board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz */
+	.ref_clock_freq = 26000000,
+	.ref_clock_xtal = false,
 };
 
 static struct omap2_hsmmc_info mmc[] = {
diff --git a/drivers/net/wireless/ti/wl12xx/main.c b/drivers/net/wireless/ti/wl12xx/main.c
index 1c627da..216c2fd 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1701,6 +1701,42 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
 		},
 };
 
+static const struct wl12xx_clock wl12xx_refclock_table[] = {
+	{ 19200000,	false,	WL12XX_REFCLOCK_19	},
+	{ 26000000,	false,	WL12XX_REFCLOCK_26	},
+	{ 26000000,	true,	WL12XX_REFCLOCK_26_XTAL	},
+	{ 38400000,	false,	WL12XX_REFCLOCK_38	},
+	{ 38400000,	true,	WL12XX_REFCLOCK_38_XTAL	},
+	{ 52000000,	false,	WL12XX_REFCLOCK_52	},
+	{ 0,		false,	0 }
+};
+
+static const struct wl12xx_clock wl12xx_tcxoclock_table[] = {
+	{ 16368000,	true,	WL12XX_TCXOCLOCK_16_368	},
+	{ 16800000,	true,	WL12XX_TCXOCLOCK_16_8	},
+	{ 19200000,	true,	WL12XX_TCXOCLOCK_19_2	},
+	{ 26000000,	true,	WL12XX_TCXOCLOCK_26	},
+	{ 32736000,	true,	WL12XX_TCXOCLOCK_32_736	},
+	{ 33600000,	true,	WL12XX_TCXOCLOCK_33_6	},
+	{ 38400000,	true,	WL12XX_TCXOCLOCK_38_4	},
+	{ 52000000,	true,	WL12XX_TCXOCLOCK_52	},
+	{ 0,		false,	0 }
+};
+
+static int wl12xx_get_clock_idx(struct wl12xx_clock *table, u32 freq, bool xtal)
+{
+	int i = 0;
+
+	while(table[i].freq != 0) {
+		if ((table[i].freq == freq) &&
+		    (table[i].xtal == xtal))
+			return table[i].hw_idx;
+		i++;
+	};
+
+	return -EINVAL;
+}
+
 static int wl12xx_setup(struct wl1271 *wl)
 {
 	struct wl12xx_priv *priv = wl->priv;
@@ -1722,7 +1758,16 @@ static int wl12xx_setup(struct wl1271 *wl)
 	wl12xx_conf_init(wl);
 
 	if (!fref_param) {
-		priv->ref_clock = pdata->board_ref_clock;
+		priv->ref_clock = wl12xx_get_clock_idx(wl12xx_refclock_table,
+						       pdata->ref_clock_freq,
+						       pdata->ref_clock_xtal);
+		if (priv->ref_clock < 0) {
+			wl1271_error("Invalid ref_clock frequency (%d Hz, %s)",
+				pdata->ref_clock_freq,
+				pdata->ref_clock_xtal ? "XTAL" : "not XTAL");
+
+			return priv->ref_clock;
+		}
 	} else {
 		if (!strcmp(fref_param, "19.2"))
 			priv->ref_clock = WL12XX_REFCLOCK_19;
@@ -1741,7 +1786,15 @@ static int wl12xx_setup(struct wl1271 *wl)
 	}
 
 	if (!tcxo_param) {
-		priv->tcxo_clock = pdata->board_tcxo_clock;
+		priv->tcxo_clock = wl12xx_get_clock_idx(wl12xx_tcxoclock_table,
+							pdata->tcxo_clock_freq,
+							true);
+		if (priv->tcxo_clock < 0) {
+			wl1271_error("Invalid tcxo_clock frequency (%d Hz)",
+				pdata->tcxo_clock_freq);
+
+			return priv->tcxo_clock;
+		}
 	} else {
 		if (!strcmp(tcxo_param, "19.2"))
 			priv->tcxo_clock = WL12XX_TCXOCLOCK_19_2;
diff --git a/drivers/net/wireless/ti/wl12xx/wl12xx.h b/drivers/net/wireless/ti/wl12xx/wl12xx.h
index 9e5484a..05f631b 100644
--- a/drivers/net/wireless/ti/wl12xx/wl12xx.h
+++ b/drivers/net/wireless/ti/wl12xx/wl12xx.h
@@ -79,4 +79,32 @@ struct wl12xx_priv {
 	struct wl127x_rx_mem_pool_addr *rx_mem_addr;
 };
 
+/* Reference clock values */
+enum {
+	WL12XX_REFCLOCK_19	= 0, /* 19.2 MHz */
+	WL12XX_REFCLOCK_26	= 1, /* 26 MHz */
+	WL12XX_REFCLOCK_38	= 2, /* 38.4 MHz */
+	WL12XX_REFCLOCK_52	= 3, /* 52 MHz */
+	WL12XX_REFCLOCK_38_XTAL = 4, /* 38.4 MHz, XTAL */
+	WL12XX_REFCLOCK_26_XTAL = 5, /* 26 MHz, XTAL */
+};
+
+/* TCXO clock values */
+enum {
+	WL12XX_TCXOCLOCK_19_2	= 0, /* 19.2MHz */
+	WL12XX_TCXOCLOCK_26	= 1, /* 26 MHz */
+	WL12XX_TCXOCLOCK_38_4	= 2, /* 38.4MHz */
+	WL12XX_TCXOCLOCK_52	= 3, /* 52 MHz */
+	WL12XX_TCXOCLOCK_16_368	= 4, /* 16.368 MHz */
+	WL12XX_TCXOCLOCK_32_736	= 5, /* 32.736 MHz */
+	WL12XX_TCXOCLOCK_16_8	= 6, /* 16.8 MHz */
+	WL12XX_TCXOCLOCK_33_6	= 7, /* 33.6 MHz */
+};
+
+struct wl12xx_clock {
+	u32	freq;
+	bool	xtal;
+	u8	hw_idx;
+};
+
 #endif /* __WL12XX_PRIV_H__ */
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index ab90b1c..11491ad 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -26,28 +26,6 @@
 
 #include <linux/err.h>
 
-/* Reference clock values */
-enum {
-	WL12XX_REFCLOCK_19	= 0, /* 19.2 MHz */
-	WL12XX_REFCLOCK_26	= 1, /* 26 MHz */
-	WL12XX_REFCLOCK_38	= 2, /* 38.4 MHz */
-	WL12XX_REFCLOCK_52	= 3, /* 52 MHz */
-	WL12XX_REFCLOCK_38_XTAL = 4, /* 38.4 MHz, XTAL */
-	WL12XX_REFCLOCK_26_XTAL = 5, /* 26 MHz, XTAL */
-};
-
-/* TCXO clock values */
-enum {
-	WL12XX_TCXOCLOCK_19_2	= 0, /* 19.2MHz */
-	WL12XX_TCXOCLOCK_26	= 1, /* 26 MHz */
-	WL12XX_TCXOCLOCK_38_4	= 2, /* 38.4MHz */
-	WL12XX_TCXOCLOCK_52	= 3, /* 52 MHz */
-	WL12XX_TCXOCLOCK_16_368	= 4, /* 16.368 MHz */
-	WL12XX_TCXOCLOCK_32_736	= 5, /* 32.736 MHz */
-	WL12XX_TCXOCLOCK_16_8	= 6, /* 16.8 MHz */
-	WL12XX_TCXOCLOCK_33_6	= 7, /* 33.6 MHz */
-};
-
 struct wl1251_platform_data {
 	void (*set_power)(bool enable);
 	/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
@@ -57,8 +35,9 @@ struct wl1251_platform_data {
 
 struct wl12xx_platform_data {
 	int irq;
-	int board_ref_clock;
-	int board_tcxo_clock;
+	int ref_clock_freq;	/* in Hertz */
+	bool ref_clock_xtal;	/* specify whether the clock is XTAL or not */
+	int tcxo_clock_freq;	/* in Hertz, tcxo is always XTAL */
 };
 
 #ifdef CONFIG_WILINK_PLATFORM_DATA
-- 
1.7.10.4



From coelho at ti.com  Wed Jul  3 10:03:23 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 3 Jul 2013 17:03:23 +0300
Subject: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of
 hiding behind a quirk
In-Reply-To: <1372860209-3504-1-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
Message-ID: <1372860209-3504-3-git-send-email-coelho@ti.com>

The platform_quirk element in the platform data was used to change the
way the IRQ is triggered.  When set, the EDGE_IRQ quirk would change
the irqflags used and treat edge trigger differently from the rest.

Instead of hiding this irq flag setting behind the quirk, have the
board files set the flags during initialization.  This will be more
meaningful than driver-specific quirks when we switch to DT.

Additionally, fix missing gpio_request() calls in the boarding files
(so that setting the flags actually works).

Cc: Tony Lindgren <tony at atomide.com>
Cc: Sekhar Nori <nsekhar at ti.com>
Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 arch/arm/mach-davinci/board-da850-evm.c      |    8 +++++-
 arch/arm/mach-omap2/board-4430sdp.c          |   18 +++++++++++++
 arch/arm/mach-omap2/board-omap3evm.c         |   19 ++++++++++++++
 arch/arm/mach-omap2/board-omap4panda.c       |   36 +++++++++++++++++++++-----
 arch/arm/mach-omap2/board-zoom-peripherals.c |   30 ++++++++++++++++++---
 drivers/net/wireless/ti/wlcore/debugfs.c     |    2 +-
 drivers/net/wireless/ti/wlcore/main.c        |   24 ++++++++++-------
 drivers/net/wireless/ti/wlcore/wlcore.h      |    5 ++--
 include/linux/wl12xx.h                       |    4 ---
 9 files changed, 118 insertions(+), 28 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 8a24b6c..544b6fa 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1378,7 +1378,6 @@ static const short da850_wl12xx_pins[] __initconst = {
 static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
 	.irq			= -1,
 	.board_ref_clock	= WL12XX_REFCLOCK_38,
-	.platform_quirks	= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
 };
 
 static __init int da850_wl12xx_init(void)
@@ -1409,6 +1408,13 @@ static __init int da850_wl12xx_init(void)
 		goto free_wlan_en;
 	}
 
+	ret = irq_set_irq_type(gpio_to_irq(DA850_WLAN_IRQ),
+			       IRQ_TYPE_EDGE_RISING);
+	if (ret) {
+		pr_err("Could not set wl12xx irq type: %d\n", ret);
+		goto free;
+	}
+
 	da850_wl12xx_wlan_data.irq = gpio_to_irq(DA850_WLAN_IRQ);
 
 	ret = wl12xx_set_platform_data(&da850_wl12xx_wlan_data);
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 56a9a4f..953f620 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -703,12 +703,30 @@ static void __init omap4_sdp4430_wifi_init(void)
 
 	omap4_sdp4430_wifi_mux_init();
 	omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
+	ret = gpio_request_one(GPIO_WIFI_IRQ, GPIOF_IN, "GPIO_WIFI_IRQ");
+	if (ret) {
+		pr_err("error requesting wl12xx gpio: %d\n", ret);
+		goto out;
+	}
+
+	ret = irq_set_irq_type(gpio_to_irq(GPIO_WIFI_IRQ), IRQ_TYPE_LEVEL_HIGH);
+	if (ret) {
+		pr_err("error setting wl12xx irq type: %d\n", ret);
+		goto free;
+	}
+
 	ret = wl12xx_set_platform_data(&omap4_sdp4430_wlan_data);
 	if (ret)
 		pr_err("Error setting wl12xx data: %d\n", ret);
+
 	ret = platform_device_register(&omap_vwlan_device);
 	if (ret)
 		pr_err("Error registering wl12xx device: %d\n", ret);
+out:
+	return;
+free:
+	gpio_free(GPIO_WIFI_IRQ);
 }
 
 static void __init omap_4430sdp_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index f76d0de..8abce3cd 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -612,12 +612,31 @@ static void __init omap3_evm_wl12xx_init(void)
 
 	/* WL12xx WLAN Init */
 	omap3evm_wlan_data.irq = gpio_to_irq(OMAP3EVM_WLAN_IRQ_GPIO);
+
+	ret = gpio_request_one(OMAP3EVM_WLAN_IRQ_GPIO, GPIOF_IN,
+			       "OMAP3EVM_WLAN_IRQ_GPIO");
+	if (ret) {
+		pr_err("error requesting wl12xx gpio: %d\n", ret);
+		goto out;
+	}
+
+	ret = irq_set_irq_type(gpio_to_irq(OMAP3EVM_WLAN_IRQ_GPIO),
+			       IRQ_TYPE_LEVEL_HIGH);
+	if (ret) {
+		pr_err("error setting wl12xx irq type: %d\n", ret);
+		goto free;
+	}
+
 	ret = wl12xx_set_platform_data(&omap3evm_wlan_data);
 	if (ret)
 		pr_err("error setting wl12xx data: %d\n", ret);
 	ret = platform_device_register(&omap3evm_wlan_regulator);
 	if (ret)
 		pr_err("error registering wl12xx device: %d\n", ret);
+out:
+	return;
+free:
+	gpio_free(OMAP3EVM_WLAN_IRQ_GPIO);
 #endif
 }
 
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 1e2c75e..5b33626 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -413,20 +413,44 @@ static void omap4_panda_init_rev(void)
 	}
 }
 
+static void __init omap4_panda_wilink_init(void)
+{
+	int ret;
+
+	omap_panda_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
+	ret = gpio_request_one(GPIO_WIFI_IRQ, GPIOF_IN, "GPIO_WIFI_IRQ");
+	if (ret) {
+		pr_err("error requesting wl12xx gpio: %d\n", ret);
+		goto out;
+	}
+
+	ret = irq_set_irq_type(gpio_to_irq(GPIO_WIFI_IRQ), IRQ_TYPE_LEVEL_HIGH);
+	if (ret) {
+		pr_err("error setting wl12xx irq type: %d\n", ret);
+		goto free;
+	}
+
+	ret = wl12xx_set_platform_data(&omap_panda_wlan_data);
+	if (ret) {
+		pr_err("error setting wl12xx data: %d\n", ret);
+		goto free;
+	}
+out:
+	return;
+free:
+	gpio_free(GPIO_WIFI_IRQ);
+}
+
 static void __init omap4_panda_init(void)
 {
 	int package = OMAP_PACKAGE_CBS;
-	int ret;
 
 	if (omap_rev() == OMAP4430_REV_ES1_0)
 		package = OMAP_PACKAGE_CBL;
 	omap4_mux_init(board_mux, NULL, package);
 
-	omap_panda_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
-	ret = wl12xx_set_platform_data(&omap_panda_wlan_data);
-	if (ret)
-		pr_err("error setting wl12xx data: %d\n", ret);
-
+	omap4_panda_wilink_init();
 	omap4_panda_init_rev();
 	omap4_panda_i2c_init();
 	platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
index a90375d..4f84cf9 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -339,16 +339,40 @@ static void enable_board_wakeup_source(void)
 		OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
 }
 
-void __init zoom_peripherals_init(void)
+static void __init zoom_wilink_init(void)
 {
 	int ret;
 
 	omap_zoom_wlan_data.irq = gpio_to_irq(OMAP_ZOOM_WLAN_IRQ_GPIO);
-	ret = wl12xx_set_platform_data(&omap_zoom_wlan_data);
 
-	if (ret)
+	ret = gpio_request_one(OMAP_ZOOM_WLAN_IRQ_GPIO, GPIOF_IN,
+			       "OMAP_ZOOM_WLAN_IRQ_GPIO");
+	if (ret) {
+		pr_err("error requesting wl12xx gpio: %d\n", ret);
+		goto out;
+	}
+
+	ret = irq_set_irq_type(gpio_to_irq(OMAP_ZOOM_WLAN_IRQ_GPIO),
+			       IRQ_TYPE_LEVEL_HIGH);
+	if (ret) {
+		pr_err("error setting wl12xx irq type: %d\n", ret);
+		goto free;
+	}
+
+	ret = wl12xx_set_platform_data(&omap_zoom_wlan_data);
+	if (ret) {
 		pr_err("error setting wl12xx data: %d\n", ret);
+		goto free;
+	}
+out:
+	return;
+free:
+	gpio_free(OMAP_ZOOM_WLAN_IRQ_GPIO);
+}
 
+void __init zoom_peripherals_init(void)
+{
+	zoom_wilink_init();
 	omap_hsmmc_init(mmc);
 	omap_i2c_init();
 	pwm_add_table(zoom_pwm_lookup, ARRAY_SIZE(zoom_pwm_lookup));
diff --git a/drivers/net/wireless/ti/wlcore/debugfs.c b/drivers/net/wireless/ti/wlcore/debugfs.c
index c3e1f79..5eff663 100644
--- a/drivers/net/wireless/ti/wlcore/debugfs.c
+++ b/drivers/net/wireless/ti/wlcore/debugfs.c
@@ -486,7 +486,7 @@ static ssize_t driver_state_read(struct file *file, char __user *user_buf,
 	DRIVER_STATE_PRINT_HEX(irq);
 	/* TODO: ref_clock and tcxo_clock were moved to wl12xx priv */
 	DRIVER_STATE_PRINT_HEX(hw_pg_ver);
-	DRIVER_STATE_PRINT_HEX(platform_quirks);
+	DRIVER_STATE_PRINT_HEX(irq_flags);
 	DRIVER_STATE_PRINT_HEX(chip.id);
 	DRIVER_STATE_PRINT_STR(chip.fw_ver_str);
 	DRIVER_STATE_PRINT_STR(chip.phy_fw_ver_str);
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index b8db55c..7b5d0cc 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -27,6 +27,7 @@
 #include <linux/vmalloc.h>
 #include <linux/wl12xx.h>
 #include <linux/interrupt.h>
+#include <linux/irq.h>
 
 #include "wlcore.h"
 #include "debug.h"
@@ -516,7 +517,7 @@ static int wlcore_irq_locked(struct wl1271 *wl)
 	 * In case edge triggered interrupt must be used, we cannot iterate
 	 * more than once without introducing race conditions with the hardirq.
 	 */
-	if (wl->platform_quirks & WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
+	if (wl->irq_flags & IRQF_TRIGGER_RISING)
 		loopcount = 1;
 
 	wl1271_debug(DEBUG_IRQ, "IRQ work");
@@ -5765,7 +5766,6 @@ struct ieee80211_hw *wlcore_alloc_hw(size_t priv_size, u32 aggr_buf_size,
 	wl->ap_ps_map = 0;
 	wl->ap_fw_ps_map = 0;
 	wl->quirks = 0;
-	wl->platform_quirks = 0;
 	wl->system_hlid = WL12XX_SYSTEM_HLID;
 	wl->active_sta_count = 0;
 	wl->active_link_count = 0;
@@ -5900,8 +5900,7 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
 	struct wl1271 *wl = context;
 	struct platform_device *pdev = wl->pdev;
 	struct wlcore_platdev_data *pdev_data = pdev->dev.platform_data;
-	struct wl12xx_platform_data *pdata = pdev_data->pdata;
-	unsigned long irqflags;
+	struct irq_data *irq_data;
 	int ret;
 
 	if (fw) {
@@ -5928,16 +5927,21 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
 	wlcore_adjust_conf(wl);
 
 	wl->irq = platform_get_irq(pdev, 0);
-	wl->platform_quirks = pdata->platform_quirks;
 	wl->if_ops = pdev_data->if_ops;
 
-	if (wl->platform_quirks & WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
-		irqflags = IRQF_TRIGGER_RISING;
-	else
-		irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
+	irq_data = irq_get_irq_data(wl->irq);
+	if (!irq_data) {
+		wl1271_error("couldn't get irq data for irq %d\n", wl->irq);
+		ret = -EINVAL;
+		goto out_free_nvs;
+	}
+
+	wl->irq_flags = irqd_get_trigger_type(irq_data);
+	/* Since we don't use the primary handler, we must set ONESHOT */
+	wl->irq_flags |= IRQF_ONESHOT;
 
 	ret = request_threaded_irq(wl->irq, NULL, wlcore_irq,
-				   irqflags, pdev->name, wl);
+				   wl->irq_flags, pdev->name, wl);
 	if (ret < 0) {
 		wl1271_error("request_irq() failed: %d", ret);
 		goto out_free_nvs;
diff --git a/drivers/net/wireless/ti/wlcore/wlcore.h b/drivers/net/wireless/ti/wlcore/wlcore.h
index 0034979..8306bde 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore.h
@@ -185,6 +185,8 @@ struct wl1271 {
 
 	int irq;
 
+	int irq_flags;
+
 	spinlock_t wl_lock;
 
 	enum wlcore_state state;
@@ -384,9 +386,6 @@ struct wl1271 {
 	/* Quirks of specific hardware revisions */
 	unsigned int quirks;
 
-	/* Platform limitations */
-	unsigned int platform_quirks;
-
 	/* number of currently active RX BA sessions */
 	int ba_rx_session_count;
 
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index b516b4f..1bfcd19 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -59,13 +59,9 @@ struct wl12xx_platform_data {
 	int irq;
 	int board_ref_clock;
 	int board_tcxo_clock;
-	unsigned long platform_quirks;
 	bool pwr_in_suspend;
 };
 
-/* Platform does not support level trigger interrupts */
-#define WL12XX_PLATFORM_QUIRK_EDGE_IRQ	BIT(0)
-
 #ifdef CONFIG_WILINK_PLATFORM_DATA
 
 int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
-- 
1.7.10.4



From cov at codeaurora.org  Wed Jul  3 10:03:40 2013
From: cov at codeaurora.org (Christopher Covington)
Date: Wed, 03 Jul 2013 10:03:40 -0400
Subject: Proposal: mach-dt
In-Reply-To: <51D3ECD1.8030305@arm.com>
References: <1372839486.487159774@f54.mail.ru> <51D3ECD1.8030305@arm.com>
Message-ID: <51D42F3C.3020805@codeaurora.org>

On 07/03/2013 05:20 AM, Marc Zyngier wrote:
> On 03/07/13 09:18, Alexander Shiyan wrote:
> 
> Hi Alexander,
> 
>> More and more platforms are now using devicetree.
>> Ideally the platform code contains only one function "of_platform_populate".
>> My idea is to make a generic architecture (mach-dt) with the call then add support
>> for compatible subarchitectures as they become available in "compatible"-property.
>> Your opinion?
> 
> Well, my (admittedly partial) opinion is that mach-virt is an incredibly
> nicer sounding name, 'specially as you can mistype it as mach-triv.

As mentioned before, I disagree and would love to see the the
virtualization-specific name replaced by something more suitably generic.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.


From marc.zyngier at arm.com  Wed Jul  3 09:59:56 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 03 Jul 2013 14:59:56 +0100
Subject: [PATCH] arm64: KVM: Support Cortex-A57 guest CPU on APM X-Gene
 host
In-Reply-To: <CAFEAcA_9mfYT6pPOT3dmqGoFAeJpQACO4FZp_971XUSowxoBaA@mail.gmail.com>
References: <1372840923-12808-1-git-send-email-anup.patel@linaro.org>
 <CAFEAcA_9mfYT6pPOT3dmqGoFAeJpQACO4FZp_971XUSowxoBaA@mail.gmail.com>
Message-ID: <51D42E5C.6050209@arm.com>

On 03/07/13 11:54, Peter Maydell wrote:
> On 3 July 2013 09:42, Anup Patel <anup.patel at linaro.org> wrote:
>> Update kvm_target_cpu() to allow Cortex-A57 guest CPU on APM X-Gene.
>>
>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>> ---
>>  arch/arm64/kvm/guest.c |   10 ++++++++--
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>> index 2c3ff67..765f56f 100644
>> --- a/arch/arm64/kvm/guest.c
>> +++ b/arch/arm64/kvm/guest.c
>> @@ -207,8 +207,13 @@ int __attribute_const__ kvm_target_cpu(void)
>>         unsigned long implementor = read_cpuid_implementor();
>>         unsigned long part_number = read_cpuid_part_number();
>>
>> -       if (implementor != ARM_CPU_IMP_ARM)
>> -               return -EINVAL;
>> +       switch (implementor) {
>> +       case ARM_CPU_IMP_ARM:
>> +       case ARM_CPU_IMP_APM:
>> +               break;
>> +       default:
>> +               return -EINVAL;
>> +       }
> 
> Doesn't this change mean we now accept the below part
> numbers for all implementors? That doesn't look right.
> 
>>         switch (part_number) {
>>         case ARM_CPU_PART_AEM_V8:
>> @@ -216,6 +221,7 @@ int __attribute_const__ kvm_target_cpu(void)
>>         case ARM_CPU_PART_FOUNDATION:
>>                 return KVM_ARM_TARGET_FOUNDATION_V8;
>>         case ARM_CPU_PART_CORTEX_A57:
>> +       case APM_CPU_PART_POTENZA:
>>                 /* Currently handled by the generic backend */
>>                 return KVM_ARM_TARGET_CORTEX_A57;
>>         default:
> 
> Do we really model all the system registers and so on correctly
> sufficiently to be able to present the guest with an A57 vcpu
> on an APM X-Gene host? (ie without accidentally leaking the
> host ID registers/system registers/impdef registers to the
> guest).

There is no such thing in the KVM/arm64 code. The guest sees the real
host, and I really don't lie the idea of lying to userspace by
pretending that we're going to emulate an A57.

Anup: I suggest you rework that patch to present a X-Gene vcpu. You can
implement it by declaring a new target and implementing it in terms of
the generic backend one if that's convenient. But just pretending this
is an A57 is not going to fly, sorry.

Cheers,

	M.
-- 
Jazz is not dead. It just smells funny...



From anup at brainfault.org  Wed Jul  3 10:00:54 2013
From: anup at brainfault.org (Anup Patel)
Date: Wed, 3 Jul 2013 19:30:54 +0530
Subject: [PATCH] arm64: KVM: Support Cortex-A57 guest CPU on APM X-Gene
 host
In-Reply-To: <CAFEAcA_9mfYT6pPOT3dmqGoFAeJpQACO4FZp_971XUSowxoBaA@mail.gmail.com>
References: <1372840923-12808-1-git-send-email-anup.patel@linaro.org>
 <CAFEAcA_9mfYT6pPOT3dmqGoFAeJpQACO4FZp_971XUSowxoBaA@mail.gmail.com>
Message-ID: <CAAhSdy1eVTk2ztzir3yZ_GZMC1+D9Co+J2UZAFWKMoZnpAg_+w@mail.gmail.com>

On Wed, Jul 3, 2013 at 4:24 PM, Peter Maydell <peter.maydell at linaro.org> wrote:
> On 3 July 2013 09:42, Anup Patel <anup.patel at linaro.org> wrote:
>> Update kvm_target_cpu() to allow Cortex-A57 guest CPU on APM X-Gene.
>>
>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>> ---
>>  arch/arm64/kvm/guest.c |   10 ++++++++--
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>> index 2c3ff67..765f56f 100644
>> --- a/arch/arm64/kvm/guest.c
>> +++ b/arch/arm64/kvm/guest.c
>> @@ -207,8 +207,13 @@ int __attribute_const__ kvm_target_cpu(void)
>>         unsigned long implementor = read_cpuid_implementor();
>>         unsigned long part_number = read_cpuid_part_number();
>>
>> -       if (implementor != ARM_CPU_IMP_ARM)
>> -               return -EINVAL;
>> +       switch (implementor) {
>> +       case ARM_CPU_IMP_ARM:
>> +       case ARM_CPU_IMP_APM:
>> +               break;
>> +       default:
>> +               return -EINVAL;
>> +       }
>
> Doesn't this change mean we now accept the below part
> numbers for all implementors? That doesn't look right.

Sure, we can use nested switch case instead of two separate
switch cases.

>
>>         switch (part_number) {
>>         case ARM_CPU_PART_AEM_V8:
>> @@ -216,6 +221,7 @@ int __attribute_const__ kvm_target_cpu(void)
>>         case ARM_CPU_PART_FOUNDATION:
>>                 return KVM_ARM_TARGET_FOUNDATION_V8;
>>         case ARM_CPU_PART_CORTEX_A57:
>> +       case APM_CPU_PART_POTENZA:
>>                 /* Currently handled by the generic backend */
>>                 return KVM_ARM_TARGET_CORTEX_A57;
>>         default:
>
> Do we really model all the system registers and so on correctly
> sufficiently to be able to present the guest with an A57 vcpu
> on an APM X-Gene host? (ie without accidentally leaking the
> host ID registers/system registers/impdef registers to the
> guest).

Yes, there are very few APM impdef registers. For now A57 vcpu
is not allowed to access these impdef registers.

For rest of the registers, A57 vcpu will see:
1. MIDR and MPIDR as expected on a A57 vcpu.
2. Cache configuration related registers will be same as that
    of underlying host so that cache operations work fine in guest

>
> thanks
> -- PMM
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

--Anup


From santosh.shilimkar at ti.com  Wed Jul  3 09:55:21 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 3 Jul 2013 09:55:21 -0400
Subject: [PATCH] ARM: OMAP5: Enable Cortex A15 errata 798181
In-Reply-To: <1371671532-27071-1-git-send-email-santosh.shilimkar@ti.com>
References: <1371671532-27071-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <51D42D49.700@ti.com>

Ping..

On Wednesday 19 June 2013 03:52 PM, Santosh Shilimkar wrote:
> ARM errata 798181 is applicable for OMAP5 based devices. So enable
> the same in the build. Errata extract and workaround information
> is as below.
> 
> On Cortex-A15 (r0p0..r3p2) the TLBI*IS/DSB operations are not
> adequately shooting down all use of the old entries. The
> ARM_ERRATA_798181 option enables the Linux kernel workaround
> for this erratum which sends an IPI to the CPUs that are running
> the same ASID as the one being invalidated.
> 
> Cc: Tony Lindgren <tony at atomide.com>
> 
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/mach-omap2/Kconfig |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index f49cd51..fbd2b9f 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -112,6 +112,7 @@ config SOC_OMAP5
>  	select HAVE_SMP
>  	select COMMON_CLK
>  	select HAVE_ARM_ARCH_TIMER
> +	select ARM_ERRATA_798181
>  
>  comment "OMAP Core Type"
>  	depends on ARCH_OMAP2
> 



From broonie at kernel.org  Wed Jul  3 12:17:27 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 3 Jul 2013 17:17:27 +0100
Subject: [PATCH v9 08/10] ASoC: Add phycore-ac97-dt driver
In-Reply-To: <1371734429-6081-9-git-send-email-mpa@pengutronix.de>
References: <1371734429-6081-1-git-send-email-mpa@pengutronix.de>
 <1371734429-6081-9-git-send-email-mpa@pengutronix.de>
Message-ID: <20130703161727.GS27646@sirena.org.uk>

On Thu, Jun 20, 2013 at 03:20:27PM +0200, Markus Pargmann wrote:

> Notes:
>     Changes in v9:
>      - Fix blank line at end of file.
>     

Please don't include enormous changelogs like this, they're just noise.

> +config SND_SOC_PHYCORE_AC97_DT
> +	bool "SoC Audio support for Phytec phyCORE (and phyCARD) boards (devicetree only)"
> +	depends on MACH_PCA100 || MACH_PCM043

Is there an actual dependency on the machine type?  This seems wrong for
a DT driver.

> +static struct snd_soc_ops imx_phycore_hifi_ops = {
> +};
> +

You shouldn't have this if there's nothing in it.

> +static struct platform_device *imx_phycore_snd_device;

This shouldn't be a global, it should be in driver data.

> +/*
> + * Pointer to AC97 reset functions for specific boards
> + */
> +#if IS_ENABLED(CONFIG_MACH_PCA100)
> +extern void pca100_ac97_cold_reset(struct snd_ac97 *ac97);
> +extern void pca100_ac97_warm_reset(struct snd_ac97 *ac97);
> +#else
> +static void pca100_ac97_cold_reset(struct snd_ac97 *ac97) { }
> +static void pca100_ac97_warm_reset(struct snd_ac97 *ac97) { }
> +#endif

> +	if (of_machine_is_compatible("phytec,imx27-pca100")) {
> +		phycore_ac97_reset = pca100_ac97_cold_reset;
> +		phycore_ac97_warm_reset = pca100_ac97_warm_reset;
> +	} else if (of_machine_is_compatible("phytec,imx35-pcm043")) {
> +		phycore_ac97_reset = pcm043_ac97_cold_reset;
> +		phycore_ac97_warm_reset = pcm043_ac97_warm_reset;
> +	} else {
> +		dev_err(&pdev->dev, "Failed to set AC97 reset functions, unknown board.\n");
> +		return -EINVAL;
> +	}

These functions have no reason to be anywhere except in the driver and
really you should just be specifying which pins to use there - ideally
via pinctrl but I don't think i.MX has adopted that yet.
-------------- 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/20130703/97fef7f1/attachment.sig>

From broonie at kernel.org  Wed Jul  3 12:18:02 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 3 Jul 2013 17:18:02 +0100
Subject: [PATCH v9 09/10] ASoC: fsl: Move fsl-ssi binding doc to sound/
In-Reply-To: <1371734429-6081-10-git-send-email-mpa@pengutronix.de>
References: <1371734429-6081-1-git-send-email-mpa@pengutronix.de>
 <1371734429-6081-10-git-send-email-mpa@pengutronix.de>
Message-ID: <20130703161802.GT27646@sirena.org.uk>

On Thu, Jun 20, 2013 at 03:20:28PM +0200, Markus Pargmann wrote:
> fsl-ssi was located in powerpc/fsl/ssi.txt. This is no powerpc specific
> device, so it should be moved to sound/ as it connects to differen audio
> codecs.

Applied, thanks.
-------------- 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/20130703/14249b6f/attachment-0001.sig>

From broonie at kernel.org  Wed Jul  3 12:19:00 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 3 Jul 2013 17:19:00 +0100
Subject: [PATCH v9 10/10] ASoC: fsl: Update fsl-ssi binding doc
In-Reply-To: <1371734429-6081-11-git-send-email-mpa@pengutronix.de>
References: <1371734429-6081-1-git-send-email-mpa@pengutronix.de>
 <1371734429-6081-11-git-send-email-mpa@pengutronix.de>
Message-ID: <20130703161900.GU27646@sirena.org.uk>

On Thu, Jun 20, 2013 at 03:20:29PM +0200, Markus Pargmann wrote:
> Update the fsl-ssi bindings. DMA is no required property anymore and
> uses the generic DMA bindings. imx-fiq is a new alternative to DMA

These updates should be done as part of the patches making the code
changes - see the review comment I had earlier for an example.
-------------- 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/20130703/7c482336/attachment.sig>

From martinez.javier at gmail.com  Wed Jul  3 11:12:25 2013
From: martinez.javier at gmail.com (Javier Martinez Canillas)
Date: Wed, 3 Jul 2013 17:12:25 +0200
Subject: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead
 of hiding behind a quirk
In-Reply-To: <1372860925.21065.115.camel@cumari.coelho.fi>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
 <1372860209-3504-3-git-send-email-coelho@ti.com>
 <1372860925.21065.115.camel@cumari.coelho.fi>
Message-ID: <CAAwP0s3xkqUGnGvojfpyQq97qUmKCqY3BD4RyK1_uuX=pNy91g@mail.gmail.com>

On Wed, Jul 3, 2013 at 4:15 PM, Luciano Coelho <coelho at ti.com> wrote:
> On Wed, 2013-07-03 at 17:03 +0300, Luciano Coelho wrote:
>> The platform_quirk element in the platform data was used to change the
>> way the IRQ is triggered.  When set, the EDGE_IRQ quirk would change
>> the irqflags used and treat edge trigger differently from the rest.
>>
>> Instead of hiding this irq flag setting behind the quirk, have the
>> board files set the flags during initialization.  This will be more
>> meaningful than driver-specific quirks when we switch to DT.
>>
>> Additionally, fix missing gpio_request() calls in the boarding files
>> (so that setting the flags actually works).
>>
>> Cc: Tony Lindgren <tony at atomide.com>
>> Cc: Sekhar Nori <nsekhar at ti.com>
>> Signed-off-by: Luciano Coelho <coelho at ti.com>
>> ---
>
> [...]
>
>> @@ -5928,16 +5927,21 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
>>       wlcore_adjust_conf(wl);
>>
>>       wl->irq = platform_get_irq(pdev, 0);
>> -     wl->platform_quirks = pdata->platform_quirks;
>>       wl->if_ops = pdev_data->if_ops;
>>
>> -     if (wl->platform_quirks & WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
>> -             irqflags = IRQF_TRIGGER_RISING;
>> -     else
>> -             irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
>> +     irq_data = irq_get_irq_data(wl->irq);
>> +     if (!irq_data) {
>> +             wl1271_error("couldn't get irq data for irq %d\n", wl->irq);
>> +             ret = -EINVAL;
>> +             goto out_free_nvs;
>> +     }
>> +
>> +     wl->irq_flags = irqd_get_trigger_type(irq_data);
>
> BTW, there seems to be a patch on its way to make reading the flags
> easier (ie. no need to get the irq_data first):
>
> http://mid.gmane.org/1367945288-5625-1-git-send-email-javier at dowhile0.org
>
> I'm not sure if this is going to be taken in, but if it does, it would
> be nice to change the code here to use the new irq_get_trigger_type()
> function.
>
> --
> Luca.
>

Hi Luca

That patch has been already merged in Linus tree as commit 1f6236bf
("genirq: Add irq_get_trigger_type() to get IRQ flags").

So yes, it would be better if you can use irq_get_trigger_type()
instead calling irq_get_irq_data() + irqd_get_trigger_type().

Best regards,
Javier


From stern at rowland.harvard.edu  Wed Jul  3 10:30:30 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Wed, 3 Jul 2013 10:30:30 -0400 (EDT)
Subject: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during
 bus suspend
In-Reply-To: <20130703131513.GH15056@arwen.pp.htv.fi>
Message-ID: <Pine.LNX.4.44L0.1307031023060.1241-100000@iolanthe.rowland.org>

On Wed, 3 Jul 2013, Felipe Balbi wrote:

> On Wed, Jul 03, 2013 at 04:06:04PM +0300, Roger Quadros wrote:
> > On 07/03/2013 03:57 PM, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Tue, Jul 02, 2013 at 01:17:58PM -0400, Alan Stern wrote:
> > >> A PCI-based EHCI controller has two power sources: the core well (which
> > >> is turned off during suspend) and the auxiliary well (which remains
> > >> powered).  That's how remote wakeup works; it uses the auxiliary well.
> > > 
> > > This, kinda, matches what OMAP tries to do with pad wakeup. Just that
> > > pad wakeup sits outside of the device itself. Perhaps we could look into
> > > how PCI handles the aux well and take some inspiration from there.
> > > 
> > > Any pointers under drivers/pci/ would be great :-)
> > > 
> > From what I understood, auxiliary well is just a power source, and it keeps
> > the EHCI controller powered even during suspend.
> > 
> > If that is true then it is different from our situation as we power down the
> > EHCI controller completely.
> 
> right but our "auxiliary well" keeps PRCM powered which can wake EHCI up
> ;-)
> 
> What I'm saying is that from ehci-omap's perspective, there's very
> little difference, specially since we route the wakeup through the same
> IRQ line anyway. Perhaps we could take some inspiration from the PCI
> land to make our hwmod/omap_device a little easier from driver
> perspective.
> 
> Or maybe it doesn't make sense ;-)

This idea probably won't lead anywhere.  To the best of my knowledge 
(and I'm not an expert on PCI), these different power wells are simply 
part of the PCI bus.  The bus controller knows to turn off one of them 
when the device (or maybe when all the devices on a bus segment) goes 
into D3.

One big difference with respect to OMAP is the way PCI handles wakeup
messages.  There's a separate bus signal, PME# (which stands for Power
Management Event), that a device asserts when it wants to send a wakeup
request.  When the ACPI driver sees the PME# signal, it searches
through the entire PCI tree to find the device or devices which need to
be resumed.  Or maybe when ACPI sees the signal, it tells the PCI core 
to do this -- I'm not sure of the details.

Alan Stern



From arnd at arndb.de  Wed Jul  3 10:51:04 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 3 Jul 2013 16:51:04 +0200
Subject: Proposal: mach-dt
In-Reply-To: <51D437C6.9000909@arm.com>
References: <1372839486.487159774@f54.mail.ru>
 <51D43127.6080206@codeaurora.org> <51D437C6.9000909@arm.com>
Message-ID: <201307031651.05181.arnd@arndb.de>

On Wednesday 03 July 2013, Marc Zyngier wrote:
> On 03/07/13 15:11, Christopher Covington wrote:
> > On 07/03/2013 10:10 AM, Marc Zyngier wrote:
> >> On 03/07/13 15:03, Christopher Covington wrote:
> >>> On 07/03/2013 05:20 AM, Marc Zyngier wrote:
> >>>> On 03/07/13 09:18, Alexander Shiyan wrote:
> >>>>
> >>>> Hi Alexander,
> >>>>
> >>>>> More and more platforms are now using devicetree.
> >>>>> Ideally the platform code contains only one function "of_platform_populate".
> >>>>> My idea is to make a generic architecture (mach-dt) with the call then add support
> >>>>> for compatible subarchitectures as they become available in "compatible"-property.
> >>>>> Your opinion?
> >>>>
> >>>> Well, my (admittedly partial) opinion is that mach-virt is an incredibly
> >>>> nicer sounding name, 'specially as you can mistype it as mach-triv.
> >>>
> >>> As mentioned before, I disagree and would love to see the the
> >>> virtualization-specific name replaced by something more suitably generic.
> >>
> >> I think you're missing the point. The right fix would to remove it
> >> entirely and make it the basic default. There are patches for that already.
> > 
> > Where?
> 
> There were patches from Arnd (CC-ed) a while ago, moving some of the
> mach-virt SMP stuff to smp.c. Don't have the pointers handy, but surely
> Arnd knows where they are.
> 
> Once SMP is done, the rest should be pretty trivial.

In 3.11, mach-virt is basically empty. The SMP functions were moved out
already and everything is optional, so you should not need to even build
arch/arm/mach-virt/virt.c any more, except to get a particular platform
name in /proc/cpuinfo.

We have a couple of real (as opposed to virtual) platforms that are
almost at the same point and only have one or two functions left in them.

I'm definitely open for suggestions what to do about them. Putting all
the trivial files into a shared directory would be one possibility,
as would removing the files entirely by making the code more generic.

Note that arm64 platforms by definition have no such machine specific
code, and they should be able to boot a 32 bit kernel as well without
needing it.

	Arnd


From jason at lakedaemon.net  Wed Jul  3 10:40:24 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 3 Jul 2013 10:40:24 -0400
Subject: [PATCH v6 5/7] ARM: kirkwood: remove redundant DT board files
In-Reply-To: <51D40BA3.6000603@gmail.com>
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1372762824-12202-6-git-send-email-sebastian.hesselbarth@gmail.com>
 <87k3l8v9s1.fsf@natisbad.org> <51D40BA3.6000603@gmail.com>
Message-ID: <20130703144024.GJ17110@titan.lakedaemon.net>

On Wed, Jul 03, 2013 at 01:31:47PM +0200, Sebastian Hesselbarth wrote:
> On 07/03/13 01:09, Arnaud Ebalard wrote:
> >Hi Sebastian,
> >
> >Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> writes:
> >
> >>With DT support for mv643xx_eth board specific init for some boards now
> >>is unneccessary. Remove those board files, Kconfig entries, and
> >>corresponding entries in kirkwood_defconfig.
> >
> >Applying above your set an old quilt cleaning patch Jason asked at some
> >point, it became empty except for arch/arm/mach_kirkwood/common.h in
> >which some declarations were left behind. If this is correct, can you
> >just merge the hunks below in your 5/7 in next round?
> >
> >AFAICT, only dnskw_init() remains, which matches the list of board-*.c
> >files in arch/arm/mach_kirkwood/ (i.e. board-dt.c and board-dnskw.c).
> 
> While updating the patch with yours, I stumbled upon MACH_TS219_DT that
> also remains because it includes tsx1x-common.c.

Oh yeah, that line can be removed as well.  It was originally included
for qnap_tsx1x_power_off().  This was replaced by

  e8fc721 power/reset: Add a new driver to turn QNAP board power off

thx,

Jason.


From jason at lakedaemon.net  Wed Jul  3 10:33:04 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 3 Jul 2013 10:33:04 -0400
Subject: [PATCH v6 5/7] ARM: kirkwood: remove redundant DT board files
In-Reply-To: <51D40BA3.6000603@gmail.com>
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1372762824-12202-6-git-send-email-sebastian.hesselbarth@gmail.com>
 <87k3l8v9s1.fsf@natisbad.org> <51D40BA3.6000603@gmail.com>
Message-ID: <20130703143304.GI17110@titan.lakedaemon.net>

On Wed, Jul 03, 2013 at 01:31:47PM +0200, Sebastian Hesselbarth wrote:
> On 07/03/13 01:09, Arnaud Ebalard wrote:
> >Hi Sebastian,
> >
> >Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> writes:
> >
> >>With DT support for mv643xx_eth board specific init for some boards now
> >>is unneccessary. Remove those board files, Kconfig entries, and
> >>corresponding entries in kirkwood_defconfig.
> >
> >Applying above your set an old quilt cleaning patch Jason asked at some
> >point, it became empty except for arch/arm/mach_kirkwood/common.h in
> >which some declarations were left behind. If this is correct, can you
> >just merge the hunks below in your 5/7 in next round?
> >
> >AFAICT, only dnskw_init() remains, which matches the list of board-*.c
> >files in arch/arm/mach_kirkwood/ (i.e. board-dt.c and board-dnskw.c).
> 
> While updating the patch with yours, I stumbled upon MACH_TS219_DT that
> also remains because it includes tsx1x-common.c.
> 
> I cannot recall if Jason or Andrew said something about removing it..

board-ts219.c can be removed as well.  It needed a check for running on
the 6282 variant in order to set the phy address properly.  This can now
be handled in kirkwood-ts219-628[12].dts.

thx,

Jason.


From balbi at ti.com  Wed Jul  3 10:23:11 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Jul 2013 17:23:11 +0300
Subject: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead
 of hiding behind a quirk
In-Reply-To: <1372861094.21065.118.camel@cumari.coelho.fi>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
 <1372860209-3504-3-git-send-email-coelho@ti.com>
 <20130703141332.GO15056@arwen.pp.htv.fi>
 <1372861094.21065.118.camel@cumari.coelho.fi>
Message-ID: <20130703142310.GT15056@arwen.pp.htv.fi>

On Wed, Jul 03, 2013 at 05:18:14PM +0300, Luciano Coelho wrote:
> On Wed, 2013-07-03 at 17:13 +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > On Wed, Jul 03, 2013 at 05:03:23PM +0300, Luciano Coelho wrote:
> > > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> > > index 56a9a4f..953f620 100644
> > > --- a/arch/arm/mach-omap2/board-4430sdp.c
> > > +++ b/arch/arm/mach-omap2/board-4430sdp.c
> > > @@ -703,12 +703,30 @@ static void __init omap4_sdp4430_wifi_init(void)
> > >  
> > >  	omap4_sdp4430_wifi_mux_init();
> > >  	omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
> > > +
> > > +	ret = gpio_request_one(GPIO_WIFI_IRQ, GPIOF_IN, "GPIO_WIFI_IRQ");
> > > +	if (ret) {
> > > +		pr_err("error requesting wl12xx gpio: %d\n", ret);
> > > +		goto out;
> > > +	}
> > > +
> > > +	ret = irq_set_irq_type(gpio_to_irq(GPIO_WIFI_IRQ), IRQ_TYPE_LEVEL_HIGH);
> > > +	if (ret) {
> > > +		pr_err("error setting wl12xx irq type: %d\n", ret);
> > > +		goto free;
> > > +	}
> > > +
> > >  	ret = wl12xx_set_platform_data(&omap4_sdp4430_wlan_data);
> > >  	if (ret)
> > >  		pr_err("Error setting wl12xx data: %d\n", ret);
> > > +
> > >  	ret = platform_device_register(&omap_vwlan_device);
> > >  	if (ret)
> > >  		pr_err("Error registering wl12xx device: %d\n", ret);
> > > +out:
> > > +	return;
> > > +free:
> > > +	gpio_free(GPIO_WIFI_IRQ);
> > 
> > actually, you should leave this GPIO requested in order to use it as
> > IRQ.
> > 
> > ditto for all others
> 
> Actually, I don't need to use the GPIO if something goes wrong (ie.
> setting the IRQ type or setting the platform data).  Notice that in the
> normal cases (ie. without errors), I return before the gpio_free() is
> called.

hah, missed the 'return' call, my bad :-p

Reviewed-by: Felipe Balbi <balbi at ti.com>
Corrected-my-broken-eye-sight-by: Luciano Coelho <coelho at ti.com>

-- 
balbi
-------------- 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/20130703/4745be1a/attachment-0001.sig>

From balbi at ti.com  Wed Jul  3 10:18:46 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Jul 2013 17:18:46 +0300
Subject: [PATCH v3 5/8] wlcore: add initial device tree support to the
 sdio module
In-Reply-To: <1372860209-3504-6-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
 <1372860209-3504-6-git-send-email-coelho@ti.com>
Message-ID: <20130703141846.GR15056@arwen.pp.htv.fi>

On Wed, Jul 03, 2013 at 05:03:26PM +0300, Luciano Coelho wrote:
> If platform data is not available, try to get the required information
> from the device tree.  Register an OF match table and parse the
> appropriate device tree nodes.
> 
> Parse interrupt property only, for now.
> 
> Signed-off-by: Luciano Coelho <coelho at ti.com>

Reviewed-by: Felipe Balbi <balbi at ti.com>

-- 
balbi
-------------- 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/20130703/5ca0ae61/attachment.sig>

From coelho at ti.com  Wed Jul  3 10:18:14 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 3 Jul 2013 17:18:14 +0300
Subject: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead
 of hiding behind a quirk
In-Reply-To: <20130703141332.GO15056@arwen.pp.htv.fi>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
 <1372860209-3504-3-git-send-email-coelho@ti.com>
 <20130703141332.GO15056@arwen.pp.htv.fi>
Message-ID: <1372861094.21065.118.camel@cumari.coelho.fi>

On Wed, 2013-07-03 at 17:13 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Jul 03, 2013 at 05:03:23PM +0300, Luciano Coelho wrote:
> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> > index 56a9a4f..953f620 100644
> > --- a/arch/arm/mach-omap2/board-4430sdp.c
> > +++ b/arch/arm/mach-omap2/board-4430sdp.c
> > @@ -703,12 +703,30 @@ static void __init omap4_sdp4430_wifi_init(void)
> >  
> >  	omap4_sdp4430_wifi_mux_init();
> >  	omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
> > +
> > +	ret = gpio_request_one(GPIO_WIFI_IRQ, GPIOF_IN, "GPIO_WIFI_IRQ");
> > +	if (ret) {
> > +		pr_err("error requesting wl12xx gpio: %d\n", ret);
> > +		goto out;
> > +	}
> > +
> > +	ret = irq_set_irq_type(gpio_to_irq(GPIO_WIFI_IRQ), IRQ_TYPE_LEVEL_HIGH);
> > +	if (ret) {
> > +		pr_err("error setting wl12xx irq type: %d\n", ret);
> > +		goto free;
> > +	}
> > +
> >  	ret = wl12xx_set_platform_data(&omap4_sdp4430_wlan_data);
> >  	if (ret)
> >  		pr_err("Error setting wl12xx data: %d\n", ret);
> > +
> >  	ret = platform_device_register(&omap_vwlan_device);
> >  	if (ret)
> >  		pr_err("Error registering wl12xx device: %d\n", ret);
> > +out:
> > +	return;
> > +free:
> > +	gpio_free(GPIO_WIFI_IRQ);
> 
> actually, you should leave this GPIO requested in order to use it as
> IRQ.
> 
> ditto for all others

Actually, I don't need to use the GPIO if something goes wrong (ie.
setting the IRQ type or setting the platform data).  Notice that in the
normal cases (ie. without errors), I return before the gpio_free() is
called.

This is not really needed, but it's a bit cleaner and we can probably
release some resources.

--
Luca.



From balbi at ti.com  Wed Jul  3 10:16:59 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Jul 2013 17:16:59 +0300
Subject: [PATCH v3 4/8] wl12xx: use frequency instead of enumerations for
 pdata clocks
In-Reply-To: <1372860209-3504-5-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
 <1372860209-3504-5-git-send-email-coelho@ti.com>
Message-ID: <20130703141659.GQ15056@arwen.pp.htv.fi>

On Wed, Jul 03, 2013 at 05:03:25PM +0300, Luciano Coelho wrote:
> Instead of defining an enumeration with the FW specific values for the
> different clock rates, use the actual frequency instead.  Also add a
> boolean to specify whether the clock is XTAL or not.
> 
> Change all board files to reflect this.
> 
> Cc: Tony Lindgren <tony at atomide.com>
> Cc: Sekhar Nori <nsekhar at ti.com>
> Signed-off-by: Luciano Coelho <coelho at ti.com>

Reviewed-by: Felipe Balbi <balbi at ti.com>

-- 
balbi
-------------- 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/20130703/bc1df054/attachment-0001.sig>

From balbi at ti.com  Wed Jul  3 10:13:32 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Jul 2013 17:13:32 +0300
Subject: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead
 of hiding behind a quirk
In-Reply-To: <1372860209-3504-3-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
 <1372860209-3504-3-git-send-email-coelho@ti.com>
Message-ID: <20130703141332.GO15056@arwen.pp.htv.fi>

Hi,

On Wed, Jul 03, 2013 at 05:03:23PM +0300, Luciano Coelho wrote:
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> index 56a9a4f..953f620 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -703,12 +703,30 @@ static void __init omap4_sdp4430_wifi_init(void)
>  
>  	omap4_sdp4430_wifi_mux_init();
>  	omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
> +
> +	ret = gpio_request_one(GPIO_WIFI_IRQ, GPIOF_IN, "GPIO_WIFI_IRQ");
> +	if (ret) {
> +		pr_err("error requesting wl12xx gpio: %d\n", ret);
> +		goto out;
> +	}
> +
> +	ret = irq_set_irq_type(gpio_to_irq(GPIO_WIFI_IRQ), IRQ_TYPE_LEVEL_HIGH);
> +	if (ret) {
> +		pr_err("error setting wl12xx irq type: %d\n", ret);
> +		goto free;
> +	}
> +
>  	ret = wl12xx_set_platform_data(&omap4_sdp4430_wlan_data);
>  	if (ret)
>  		pr_err("Error setting wl12xx data: %d\n", ret);
> +
>  	ret = platform_device_register(&omap_vwlan_device);
>  	if (ret)
>  		pr_err("Error registering wl12xx device: %d\n", ret);
> +out:
> +	return;
> +free:
> +	gpio_free(GPIO_WIFI_IRQ);

actually, you should leave this GPIO requested in order to use it as
IRQ.

ditto for all others

-- 
balbi
-------------- 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/20130703/6376cbe3/attachment-0001.sig>

From cov at codeaurora.org  Wed Jul  3 10:11:51 2013
From: cov at codeaurora.org (Christopher Covington)
Date: Wed, 03 Jul 2013 10:11:51 -0400
Subject: Proposal: mach-dt
In-Reply-To: <51D430DE.3030609@arm.com>
References: <1372839486.487159774@f54.mail.ru> <51D3ECD1.8030305@arm.com>
 <51D42F3C.3020805@codeaurora.org> <51D430DE.3030609@arm.com>
Message-ID: <51D43127.6080206@codeaurora.org>

On 07/03/2013 10:10 AM, Marc Zyngier wrote:
> On 03/07/13 15:03, Christopher Covington wrote:
>> On 07/03/2013 05:20 AM, Marc Zyngier wrote:
>>> On 03/07/13 09:18, Alexander Shiyan wrote:
>>>
>>> Hi Alexander,
>>>
>>>> More and more platforms are now using devicetree.
>>>> Ideally the platform code contains only one function "of_platform_populate".
>>>> My idea is to make a generic architecture (mach-dt) with the call then add support
>>>> for compatible subarchitectures as they become available in "compatible"-property.
>>>> Your opinion?
>>>
>>> Well, my (admittedly partial) opinion is that mach-virt is an incredibly
>>> nicer sounding name, 'specially as you can mistype it as mach-triv.
>>
>> As mentioned before, I disagree and would love to see the the
>> virtualization-specific name replaced by something more suitably generic.
> 
> I think you're missing the point. The right fix would to remove it
> entirely and make it the basic default. There are patches for that already.

Where?

Thanks,
Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.


From balbi at ti.com  Wed Jul  3 10:11:10 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Jul 2013 17:11:10 +0300
Subject: [PATCH v3 1/8] wl1251: split wl251 platform data to a separate
 structure
In-Reply-To: <1372860209-3504-2-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
 <1372860209-3504-2-git-send-email-coelho@ti.com>
Message-ID: <20130703141110.GN15056@arwen.pp.htv.fi>

On Wed, Jul 03, 2013 at 05:03:22PM +0300, Luciano Coelho wrote:
> Move the wl1251 part of the wl12xx platform data structure into a new
> structure specifically for wl1251.  Change the platform data built-in
> block and board files accordingly.
> 
> Cc: Tony Lindgren <tony at atomide.com>
> Signed-off-by: Luciano Coelho <coelho at ti.com>
> Acked-by: Tony Lindgren <tony at atomide.com>

Reviewed-by: Felipe Balbi <balbi at ti.com>

-- 
balbi
-------------- 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/20130703/6b8a1695/attachment-0001.sig>

From marc.zyngier at arm.com  Wed Jul  3 10:10:38 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 03 Jul 2013 15:10:38 +0100
Subject: Proposal: mach-dt
In-Reply-To: <51D42F3C.3020805@codeaurora.org>
References: <1372839486.487159774@f54.mail.ru> <51D3ECD1.8030305@arm.com>
 <51D42F3C.3020805@codeaurora.org>
Message-ID: <51D430DE.3030609@arm.com>

On 03/07/13 15:03, Christopher Covington wrote:
> On 07/03/2013 05:20 AM, Marc Zyngier wrote:
>> On 03/07/13 09:18, Alexander Shiyan wrote:
>>
>> Hi Alexander,
>>
>>> More and more platforms are now using devicetree.
>>> Ideally the platform code contains only one function "of_platform_populate".
>>> My idea is to make a generic architecture (mach-dt) with the call then add support
>>> for compatible subarchitectures as they become available in "compatible"-property.
>>> Your opinion?
>>
>> Well, my (admittedly partial) opinion is that mach-virt is an incredibly
>> nicer sounding name, 'specially as you can mistype it as mach-triv.
> 
> As mentioned before, I disagree and would love to see the the
> virtualization-specific name replaced by something more suitably generic.

I think you're missing the point. The right fix would to remove it
entirely and make it the basic default. There are patches for that already.

	M.
-- 
Jazz is not dead. It just smells funny...



From anup at brainfault.org  Wed Jul  3 10:06:51 2013
From: anup at brainfault.org (Anup Patel)
Date: Wed, 3 Jul 2013 19:36:51 +0530
Subject: [PATCH] arm64: KVM: Support Cortex-A57 guest CPU on APM X-Gene
 host
In-Reply-To: <51D42E5C.6050209@arm.com>
References: <1372840923-12808-1-git-send-email-anup.patel@linaro.org>
 <CAFEAcA_9mfYT6pPOT3dmqGoFAeJpQACO4FZp_971XUSowxoBaA@mail.gmail.com>
 <51D42E5C.6050209@arm.com>
Message-ID: <CAAhSdy2O5_e5D2jGMtxtThsCaqHti9q7CEA59gCpL3urCaC49A@mail.gmail.com>

On Wed, Jul 3, 2013 at 7:29 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 03/07/13 11:54, Peter Maydell wrote:
>> On 3 July 2013 09:42, Anup Patel <anup.patel at linaro.org> wrote:
>>> Update kvm_target_cpu() to allow Cortex-A57 guest CPU on APM X-Gene.
>>>
>>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>> ---
>>>  arch/arm64/kvm/guest.c |   10 ++++++++--
>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>>> index 2c3ff67..765f56f 100644
>>> --- a/arch/arm64/kvm/guest.c
>>> +++ b/arch/arm64/kvm/guest.c
>>> @@ -207,8 +207,13 @@ int __attribute_const__ kvm_target_cpu(void)
>>>         unsigned long implementor = read_cpuid_implementor();
>>>         unsigned long part_number = read_cpuid_part_number();
>>>
>>> -       if (implementor != ARM_CPU_IMP_ARM)
>>> -               return -EINVAL;
>>> +       switch (implementor) {
>>> +       case ARM_CPU_IMP_ARM:
>>> +       case ARM_CPU_IMP_APM:
>>> +               break;
>>> +       default:
>>> +               return -EINVAL;
>>> +       }
>>
>> Doesn't this change mean we now accept the below part
>> numbers for all implementors? That doesn't look right.
>>
>>>         switch (part_number) {
>>>         case ARM_CPU_PART_AEM_V8:
>>> @@ -216,6 +221,7 @@ int __attribute_const__ kvm_target_cpu(void)
>>>         case ARM_CPU_PART_FOUNDATION:
>>>                 return KVM_ARM_TARGET_FOUNDATION_V8;
>>>         case ARM_CPU_PART_CORTEX_A57:
>>> +       case APM_CPU_PART_POTENZA:
>>>                 /* Currently handled by the generic backend */
>>>                 return KVM_ARM_TARGET_CORTEX_A57;
>>>         default:
>>
>> Do we really model all the system registers and so on correctly
>> sufficiently to be able to present the guest with an A57 vcpu
>> on an APM X-Gene host? (ie without accidentally leaking the
>> host ID registers/system registers/impdef registers to the
>> guest).
>
> There is no such thing in the KVM/arm64 code. The guest sees the real
> host, and I really don't lie the idea of lying to userspace by
> pretending that we're going to emulate an A57.
>
> Anup: I suggest you rework that patch to present a X-Gene vcpu. You can
> implement it by declaring a new target and implementing it in terms of
> the generic backend one if that's convenient. But just pretending this
> is an A57 is not going to fly, sorry.

Sure, I will add separate target vcpu for X-Gene and try to re-use your
generic backend.

>
> Cheers,
>
>         M.
> --
> Jazz is not dead. It just smells funny...
>
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

--Anup


From coelho at ti.com  Wed Jul  3 10:03:29 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 3 Jul 2013 17:03:29 +0300
Subject: [PATCH v3 8/8] wlcore/wl12xx: check if we got correct clock data from
 DT
In-Reply-To: <1372860209-3504-1-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
Message-ID: <1372860209-3504-9-git-send-email-coelho@ti.com>

The fref and the tcxo clocks settings are optional in some platforms.
WiLink8 doesn't need either, so we don't check the values.  WiLink 6
only needs the fref clock, so we check that it is valid or return with
an error.  WiLink7 needs both clocks, if either is not available we
return with an error.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 drivers/net/wireless/ti/wl12xx/main.c |   20 +++++++++++++++++---
 drivers/net/wireless/ti/wlcore/sdio.c |    4 ----
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ti/wl12xx/main.c b/drivers/net/wireless/ti/wl12xx/main.c
index 216c2fd..1be0b51 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -927,6 +927,11 @@ static int wl128x_boot_clk(struct wl1271 *wl, int *selected_clock)
 	u16 sys_clk_cfg;
 	int ret;
 
+	if ((priv->ref_clock < 0) || (priv->tcxo_clock < 0)) {
+		wl1271_error("Missing fref and/or tcxo clock settings\n");
+		return -EINVAL;
+	}
+
 	/* For XTAL-only modes, FREF will be used after switching from TCXO */
 	if (priv->ref_clock == WL12XX_REFCLOCK_26_XTAL ||
 	    priv->ref_clock == WL12XX_REFCLOCK_38_XTAL) {
@@ -976,6 +981,11 @@ static int wl127x_boot_clk(struct wl1271 *wl)
 	u32 clk;
 	int ret;
 
+	if (priv->ref_clock < 0) {
+		wl1271_error("Missing fref clock settings\n");
+		return -EINVAL;
+	}
+
 	if (WL127X_PG_GET_MAJOR(wl->hw_pg_ver) < 3)
 		wl->quirks |= WLCORE_QUIRK_END_OF_TRANSACTION;
 
@@ -1757,7 +1767,7 @@ static int wl12xx_setup(struct wl1271 *wl)
 	wlcore_set_ht_cap(wl, IEEE80211_BAND_5GHZ, &wl12xx_ht_cap);
 	wl12xx_conf_init(wl);
 
-	if (!fref_param) {
+	if (!fref_param && (pdata->ref_clock_freq > 0)) {
 		priv->ref_clock = wl12xx_get_clock_idx(wl12xx_refclock_table,
 						       pdata->ref_clock_freq,
 						       pdata->ref_clock_xtal);
@@ -1768,6 +1778,8 @@ static int wl12xx_setup(struct wl1271 *wl)
 
 			return priv->ref_clock;
 		}
+	} else if (!fref_param) {
+		priv->ref_clock = -EINVAL;
 	} else {
 		if (!strcmp(fref_param, "19.2"))
 			priv->ref_clock = WL12XX_REFCLOCK_19;
@@ -1785,7 +1797,7 @@ static int wl12xx_setup(struct wl1271 *wl)
 			wl1271_error("Invalid fref parameter %s", fref_param);
 	}
 
-	if (!tcxo_param) {
+	if (!fref_param && (pdata->tcxo_clock_freq > 0)) {
 		priv->tcxo_clock = wl12xx_get_clock_idx(wl12xx_tcxoclock_table,
 							pdata->tcxo_clock_freq,
 							true);
@@ -1795,7 +1807,9 @@ static int wl12xx_setup(struct wl1271 *wl)
 
 			return priv->tcxo_clock;
 		}
-	} else {
+	} else if (!fref_param) {
+		priv->tcxo_clock = -EINVAL;
+	}else {
 		if (!strcmp(tcxo_param, "19.2"))
 			priv->tcxo_clock = WL12XX_TCXOCLOCK_19_2;
 		else if (!strcmp(tcxo_param, "26"))
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 60fce49..c76eb66 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -252,20 +252,16 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 	for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
 		of_fixed_clk_setup(clock_node);
 
-	/* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
 	glue->refclock = of_clk_get_by_name(np, "refclock");
 	if (IS_ERR(glue->refclock)) {
-		dev_err(dev, "couldn't find refclock on the device tree\n");
 		glue->refclock = NULL;
 	} else {
 		clk_prepare_enable(glue->refclock);
 		pdata->ref_clock_freq = clk_get_rate(glue->refclock);
 	}
 
-	/* TODO: make sure we have this when needed (ie. for WL7) */
 	glue->tcxoclock = of_clk_get_by_name(np, "tcxoclock");
 	if (IS_ERR(glue->tcxoclock)) {
-		dev_err(dev, "couldn't find tcxoclock on the device tree\n");
 		glue->tcxoclock = NULL;
 	} else {
 		clk_prepare_enable(glue->tcxoclock);
-- 
1.7.10.4



From coelho at ti.com  Wed Jul  3 10:03:26 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 3 Jul 2013 17:03:26 +0300
Subject: [PATCH v3 5/8] wlcore: add initial device tree support to the sdio
 module
In-Reply-To: <1372860209-3504-1-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
Message-ID: <1372860209-3504-6-git-send-email-coelho@ti.com>

If platform data is not available, try to get the required information
from the device tree.  Register an OF match table and parse the
appropriate device tree nodes.

Parse interrupt property only, for now.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 drivers/net/wireless/ti/wlcore/sdio.c |   69 ++++++++++++++++++++++++++++++---
 1 file changed, 63 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 4c7e8ac..9370d7e 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -30,7 +30,7 @@
 #include <linux/mmc/sdio_ids.h>
 #include <linux/mmc/card.h>
 #include <linux/mmc/host.h>
-#include <linux/gpio.h>
+#include <linux/of_irq.h>
 #include <linux/wl12xx.h>
 #include <linux/pm_runtime.h>
 #include <linux/printk.h>
@@ -214,6 +214,43 @@ static struct wl1271_if_operations sdio_ops = {
 	.set_block_size = wl1271_sdio_set_block_size,
 };
 
+static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
+{
+	struct wl12xx_platform_data *pdata;
+	struct device_node *np = dev->of_node;
+
+	if (!np) {
+		np = of_find_matching_node(NULL, dev->driver->of_match_table);
+		if (!np) {
+			dev_notice(dev, "device tree node not available\n");
+			pdata = ERR_PTR(-ENODEV);
+			goto out;
+		}
+	}
+
+	pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+	if (!pdata) {
+		dev_err(dev, "can't allocate platform data\n");
+		pdata = ERR_PTR(-ENODEV);
+		goto out;
+	}
+
+	pdata->irq = irq_of_parse_and_map(np, 0);
+	if (pdata->irq < 0) {
+		dev_err(dev, "can't get interrupt gpio from the device tree\n");
+		goto out_free;
+	}
+
+	goto out;
+
+out_free:
+	kfree(pdata);
+	pdata = ERR_PTR(-ENODEV);
+
+out:
+	return pdata;
+}
+
 static int wl1271_probe(struct sdio_func *func,
 				  const struct sdio_device_id *id)
 {
@@ -248,11 +285,22 @@ static int wl1271_probe(struct sdio_func *func,
 	/* Use block mode for transferring over one block size of data */
 	func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
+	/* The pdata allocated here is freed when the device is freed,
+	 * so we don't need an additional out label to free it in case
+	 * of error further on.
+	 */
+
+	/* Try to get legacy platform data from the board file */
 	pdev_data->pdata = wl12xx_get_platform_data();
 	if (IS_ERR(pdev_data->pdata)) {
-		ret = PTR_ERR(pdev_data->pdata);
-		dev_err(glue->dev, "missing wlan platform data: %d\n", ret);
-		goto out_free_glue;
+		dev_info(&func->dev,
+			 "legacy platform data not found, trying device tree\n");
+
+		pdev_data->pdata = wlcore_get_pdata_from_of(&func->dev);
+		if (IS_ERR(pdev_data->pdata)) {
+			dev_err(&func->dev, "can't get platform data\n");
+			goto out_free_glue;
+		}
 	}
 
 	/* if sdio can keep power while host is suspended, enable wow */
@@ -386,16 +434,25 @@ static const struct dev_pm_ops wl1271_sdio_pm_ops = {
 };
 #endif
 
+static const struct of_device_id wlcore_sdio_of_match_table[] = {
+	{ .compatible = "ti,wilink6" },
+	{ .compatible = "ti,wilink7" },
+	{ .compatible = "ti,wilink8" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, wlcore_sdio_of_match_table);
+
 static struct sdio_driver wl1271_sdio_driver = {
 	.name		= "wl1271_sdio",
 	.id_table	= wl1271_devices,
 	.probe		= wl1271_probe,
 	.remove		= wl1271_remove,
-#ifdef CONFIG_PM
 	.drv = {
+#ifdef CONFIG_PM
 		.pm = &wl1271_sdio_pm_ops,
-	},
 #endif
+		.of_match_table = of_match_ptr(wlcore_sdio_of_match_table),
+	},
 };
 
 static int __init wl1271_init(void)
-- 
1.7.10.4



From coelho at ti.com  Wed Jul  3 10:03:22 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 3 Jul 2013 17:03:22 +0300
Subject: [PATCH v3 1/8] wl1251: split wl251 platform data to a separate
 structure
In-Reply-To: <1372860209-3504-1-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
Message-ID: <1372860209-3504-2-git-send-email-coelho@ti.com>

Move the wl1251 part of the wl12xx platform data structure into a new
structure specifically for wl1251.  Change the platform data built-in
block and board files accordingly.

Cc: Tony Lindgren <tony at atomide.com>
Signed-off-by: Luciano Coelho <coelho at ti.com>
Acked-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/mach-omap2/board-omap3pandora.c       |    4 +--
 arch/arm/mach-omap2/board-rx51-peripherals.c   |    2 +-
 drivers/net/wireless/ti/wilink_platform_data.c |   37 ++++++++++++++++++++----
 drivers/net/wireless/ti/wl1251/sdio.c          |   12 ++++----
 drivers/net/wireless/ti/wl1251/spi.c           |    2 +-
 include/linux/wl12xx.h                         |   22 +++++++++++++-
 6 files changed, 62 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index 28133d5..bf06d95 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -540,7 +540,7 @@ static struct spi_board_info omap3pandora_spi_board_info[] __initdata = {
 
 static void __init pandora_wl1251_init(void)
 {
-	struct wl12xx_platform_data pandora_wl1251_pdata;
+	struct wl1251_platform_data pandora_wl1251_pdata;
 	int ret;
 
 	memset(&pandora_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
@@ -554,7 +554,7 @@ static void __init pandora_wl1251_init(void)
 		goto fail_irq;
 
 	pandora_wl1251_pdata.use_eeprom = true;
-	ret = wl12xx_set_platform_data(&pandora_wl1251_pdata);
+	ret = wl1251_set_platform_data(&pandora_wl1251_pdata);
 	if (ret < 0)
 		goto fail_irq;
 
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 18ca61e..733f3f2 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -80,7 +80,7 @@ enum {
 	RX51_SPI_MIPID,		/* LCD panel */
 };
 
-static struct wl12xx_platform_data wl1251_pdata;
+static struct wl1251_platform_data wl1251_pdata;
 static struct tsc2005_platform_data tsc2005_pdata;
 
 #if defined(CONFIG_SENSORS_LIS3_I2C) || defined(CONFIG_SENSORS_LIS3_I2C_MODULE)
diff --git a/drivers/net/wireless/ti/wilink_platform_data.c b/drivers/net/wireless/ti/wilink_platform_data.c
index 998e958..a92bd3e 100644
--- a/drivers/net/wireless/ti/wilink_platform_data.c
+++ b/drivers/net/wireless/ti/wilink_platform_data.c
@@ -23,17 +23,17 @@
 #include <linux/err.h>
 #include <linux/wl12xx.h>
 
-static struct wl12xx_platform_data *platform_data;
+static struct wl12xx_platform_data *wl12xx_platform_data;
 
 int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
 {
-	if (platform_data)
+	if (wl12xx_platform_data)
 		return -EBUSY;
 	if (!data)
 		return -EINVAL;
 
-	platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
-	if (!platform_data)
+	wl12xx_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+	if (!wl12xx_platform_data)
 		return -ENOMEM;
 
 	return 0;
@@ -41,9 +41,34 @@ int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
 
 struct wl12xx_platform_data *wl12xx_get_platform_data(void)
 {
-	if (!platform_data)
+	if (!wl12xx_platform_data)
 		return ERR_PTR(-ENODEV);
 
-	return platform_data;
+	return wl12xx_platform_data;
 }
 EXPORT_SYMBOL(wl12xx_get_platform_data);
+
+static struct wl1251_platform_data *wl1251_platform_data;
+
+int __init wl1251_set_platform_data(const struct wl1251_platform_data *data)
+{
+	if (wl1251_platform_data)
+		return -EBUSY;
+	if (!data)
+		return -EINVAL;
+
+	wl1251_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+	if (!wl1251_platform_data)
+		return -ENOMEM;
+
+	return 0;
+}
+
+struct wl1251_platform_data *wl1251_get_platform_data(void)
+{
+	if (!wl1251_platform_data)
+		return ERR_PTR(-ENODEV);
+
+	return wl1251_platform_data;
+}
+EXPORT_SYMBOL(wl1251_get_platform_data);
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c b/drivers/net/wireless/ti/wl1251/sdio.c
index e2b3d9c..b75a37a 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -227,7 +227,7 @@ static int wl1251_sdio_probe(struct sdio_func *func,
 	struct wl1251 *wl;
 	struct ieee80211_hw *hw;
 	struct wl1251_sdio *wl_sdio;
-	const struct wl12xx_platform_data *wl12xx_board_data;
+	const struct wl1251_platform_data *wl1251_board_data;
 
 	hw = wl1251_alloc_hw();
 	if (IS_ERR(hw))
@@ -254,11 +254,11 @@ static int wl1251_sdio_probe(struct sdio_func *func,
 	wl->if_priv = wl_sdio;
 	wl->if_ops = &wl1251_sdio_ops;
 
-	wl12xx_board_data = wl12xx_get_platform_data();
-	if (!IS_ERR(wl12xx_board_data)) {
-		wl->set_power = wl12xx_board_data->set_power;
-		wl->irq = wl12xx_board_data->irq;
-		wl->use_eeprom = wl12xx_board_data->use_eeprom;
+	wl1251_board_data = wl1251_get_platform_data();
+	if (!IS_ERR(wl1251_board_data)) {
+		wl->set_power = wl1251_board_data->set_power;
+		wl->irq = wl1251_board_data->irq;
+		wl->use_eeprom = wl1251_board_data->use_eeprom;
 	}
 
 	if (wl->irq) {
diff --git a/drivers/net/wireless/ti/wl1251/spi.c b/drivers/net/wireless/ti/wl1251/spi.c
index c7dc6fe..6bbbfe6 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -238,7 +238,7 @@ static const struct wl1251_if_operations wl1251_spi_ops = {
 
 static int wl1251_spi_probe(struct spi_device *spi)
 {
-	struct wl12xx_platform_data *pdata;
+	struct wl1251_platform_data *pdata;
 	struct ieee80211_hw *hw;
 	struct wl1251 *wl;
 	int ret;
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index a54fe82..b516b4f 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -48,11 +48,15 @@ enum {
 	WL12XX_TCXOCLOCK_33_6	= 7, /* 33.6 MHz */
 };
 
-struct wl12xx_platform_data {
+struct wl1251_platform_data {
 	void (*set_power)(bool enable);
 	/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
 	int irq;
 	bool use_eeprom;
+};
+
+struct wl12xx_platform_data {
+	int irq;
 	int board_ref_clock;
 	int board_tcxo_clock;
 	unsigned long platform_quirks;
@@ -68,6 +72,10 @@ int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
 
 struct wl12xx_platform_data *wl12xx_get_platform_data(void);
 
+int wl1251_set_platform_data(const struct wl1251_platform_data *data);
+
+struct wl1251_platform_data *wl1251_get_platform_data(void);
+
 #else
 
 static inline
@@ -82,6 +90,18 @@ struct wl12xx_platform_data *wl12xx_get_platform_data(void)
 	return ERR_PTR(-ENODATA);
 }
 
+static inline
+int wl1251_set_platform_data(const struct wl1251_platform_data *data)
+{
+	return -ENOSYS;
+}
+
+static inline
+struct wl1251_platform_data *wl1251_get_platform_data(void)
+{
+	return ERR_PTR(-ENODATA);
+}
+
 #endif
 
 #endif
-- 
1.7.10.4



From coelho at ti.com  Wed Jul  3 10:03:21 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 3 Jul 2013 17:03:21 +0300
Subject: [PATCH v3 0/8] wilink: add device tree support
Message-ID: <1372860209-3504-1-git-send-email-coelho@ti.com>

Hi,

This patch series adds device tree support to the wlcore_sdio driver,
which is used by WiLink6, WiLink7 and WiLink8.

The first patches do some clean-up to make the data needed in the
wilink device tree node smaller.  The remaining patches implement the
actual device tree node parsing in wlcore_sdio.

I still need to figure out how to add the information about whether
the clocks are XTAL or not.  I'll send it in a separate patche set.

The DTS file changes will be sent separately, since they need to go
via different trees.

The bindings documentation patch will also be updated and sent
separately, once the XTAL issue is solved.


Changes in v3:

* Remove irq_flags from pdata and handle them in the board files.
  This caused the "wlcore: use irq_flags in pdata instead of hiding it
  behind a quirk" (now 2/8) to be changed considerably, so I removed
  the Acked-by from Tony.  I also added calls to gpio_request_one()
  for the WiLink IRQ GPIO that were missing in the board files (thanks
  Felipe);

* Added "const" to the frequency tables in patch 4/8 (thanks Felipe);

* Squashed patch 5/9 into the new 2/8;

* Added comment about the sdio_set_drvdata() call move in 7/8 (thanks
  Felipe);

* I'm still modifying the panda and 4430sdp board files that are going
  to be removed in 3.11.  Please ignore the changes I made there, I
  just wanted to make sure they still work with my current tree.  Once
  the 3.11 merge window close, I'll do the relevant merges before I
  send pull requests (thanks Tony and Nishant).

Please review.

--
Cheers,
Luca.

Luciano Coelho (8):
  wl1251: split wl251 platform data to a separate structure
  wlcore: set irq_flags in the board files instead of hiding behind a
    quirk
  wlcore: remove pwr_in_suspend from platform data
  wl12xx: use frequency instead of enumerations for pdata clocks
  wlcore: add initial device tree support to the sdio module
  wlcore: sdio: add wilink clock providers
  wlcore: sdio: get clocks from device tree
  wlcore/wl12xx: check if we got correct clock data from DT

 arch/arm/mach-davinci/board-da850-evm.c        |   11 ++-
 arch/arm/mach-omap2/board-4430sdp.c            |   23 ++++-
 arch/arm/mach-omap2/board-omap3evm.c           |   22 ++++-
 arch/arm/mach-omap2/board-omap3pandora.c       |    4 +-
 arch/arm/mach-omap2/board-omap4panda.c         |   39 +++++++--
 arch/arm/mach-omap2/board-rx51-peripherals.c   |    2 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c   |   33 ++++++-
 drivers/net/wireless/ti/wilink_platform_data.c |   37 ++++++--
 drivers/net/wireless/ti/wl1251/sdio.c          |   12 +--
 drivers/net/wireless/ti/wl1251/spi.c           |    2 +-
 drivers/net/wireless/ti/wl12xx/main.c          |   77 ++++++++++++++--
 drivers/net/wireless/ti/wl12xx/wl12xx.h        |   28 ++++++
 drivers/net/wireless/ti/wlcore/debugfs.c       |    2 +-
 drivers/net/wireless/ti/wlcore/main.c          |   26 +++---
 drivers/net/wireless/ti/wlcore/sdio.c          |  112 ++++++++++++++++++++++--
 drivers/net/wireless/ti/wlcore/wlcore.h        |    5 +-
 drivers/net/wireless/ti/wlcore/wlcore_i.h      |    1 +
 include/linux/wl12xx.h                         |   52 +++++------
 18 files changed, 398 insertions(+), 90 deletions(-)

-- 
1.7.10.4



From mindentropy at gmail.com  Wed Jul  3 09:35:03 2013
From: mindentropy at gmail.com (mind entropy)
Date: Wed, 3 Jul 2013 19:05:03 +0530
Subject: On common struct clk in clock framework.
Message-ID: <CAM2a4uyrX0t-W8hXKROvZgJPSyCY+DaviV-eRVZOhyPx=WNBUw@mail.gmail.com>

Hi,

   I am reading through mini2440 code and trying to understand
clocking code. I am getting confused as to whether it uses the common
clocking framework. In
https://github.com/torvalds/linux/blob/master/arch/arm/plat-samsung/include/plat/clock.h#L42
they define a struct clk. Even in OMAP
(http://processors.wiki.ti.com/index.php/Clock_Framework_User_Guide#Software_Implementation)
they have a separate struct clk definition. In the common clocking
framework shouldn't they be using the common struct clk rather than
have their own versions of struct clk?

Thanks in advance.


From balbi at ti.com  Wed Jul  3 09:20:38 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Jul 2013 16:20:38 +0300
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <51D3F773.9000209@ti.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
 <51D3F773.9000209@ti.com>
Message-ID: <20130703132038.GI15056@arwen.pp.htv.fi>

Hi,

On Wed, Jul 03, 2013 at 03:35:39PM +0530, Kishon Vijay Abraham I wrote:
> On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote:
> >Hi Kishon,
> >
> >>-----Original Message-----
> >>From: ABRAHAM, KISHON VIJAY
> >>Sent: Wednesday, June 26, 2013 5:17 PM
> >>To: grant.likely at linaro.org; tony at atomide.com; Balbi, Felipe; ABRAHAM,
> >>KISHON VIJAY; arnd at arndb.de; swarren at nvidia.com;
> >>sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
> >>omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> >>usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> >>foundation.org
> >>Cc: rob.herring at calxeda.com; rob at landley.net; linux at arm.linux.org.uk;
> >>benoit.cousson at linaro.org; mchehab at redhat.com; cesarb at cesarb.net;
> >>davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org; Shilimkar,
> >>Santosh; devicetree-discuss at lists.ozlabs.org; linux-
> >>doc at vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T; Cherian,
> >>George
> >>Subject: [PATCH v9 0/8] Generic PHY Framework
> >>
> >>Added a generic PHY framework that provides a set of APIs for the PHY
> >>drivers
> >>to create/destroy a PHY and APIs for the PHY users to obtain a
> >>reference to
> >>the PHY with or without using phandle.
> >>
> >>This framework will be of use only to devices that uses external PHY
> >>(PHY
> >>functionality is not embedded within the controller).
> >>
> >>The intention of creating this framework is to bring the phy drivers
> >>spread
> >>all over the Linux kernel to drivers/phy to increase code re-use and
> >>to
> >>increase code maintainability.
> >
> >I would like to use this framework for a smart-card controller connected to a
> >smart-card phy. I have some questions and would like to get feedback on the same.
> 
> glad to know that :-)
> >
> >I am using ?TDA8026" Smartcard PHY from NXP. Here is the link for datasheet
> >and app note for the same. The smart card controller is inside the TI SoC
> >I am working with.
> >
> >Datasheet :
> >www.nxp.com/documents/data_sheet/TDA8026.pdf?
> >
> >Appnote :
> >http://www.nxp.com/documents/application_note/AN10724.pdf
> >
> >The TI SoC details are not public (yet). I can provide details to you offline.
> >
> >Brief about operation:
> >-	The controller can work with and without a PHY
> >-	When not using PHY, it is limited to talking to a single
> >	smart card. There is also a need to put external de-activation logic
> >	on card removal for this case.
> >-	With a PHY you can use more than one smart card.
> >-	Phy has 5 slots :  1 for smart card (credit/debit/other card with chip)
> >       and others for SAM ? SIM like modules
> >- 	Once the PHY is initialized, there are some operations that the controller
> >	can request of the PHY like:
> >	- Card configurations  - set voltage
> >	- Activation of card
> >	- ATR ? Answer to reset
> >	- Warm reset
> >	- ADPU exchange
> >	- Deactivation ( Normal/Emergency)
> 
> hmm.. We should think about extending the phy_ops to include these
> operations (something like phy_smart_card_ops so that other
> smart_card PHYs will also be able to use it).

let's try to avoid use-case specific additions. set_voltage sounds like
a regulator thing, but the regulator is controlled through the PHY. I
guess it makes sense to have a generic phy_set_voltage() call since even
USB can make use of that.

For card activation, it sounds like phy_init()/phy_shutdown() would
cover it.

For warm reset perhaps a phy_reset() callback ? Although that could,
easily, get abused.

For deactivation, that's phy_shutdown().

ATR and ADPU needs more thought, I guess.

> >- 	In the mode when smartcard controller talks directly to the card without the need
> >	for a PHY, all the above operations will be carried out by the controller itself
> >
> >My current thought process is to make the controller driver provide the user interface
> >and talk to the PHY using the generic PHY framework you proposed. In the case where there
> >is no PHY, my idea is to create a "dummy" PHY which uses the controller functionality itself.
> 
> right. And in the case where you actually have a PHY, create a PHY
> driver and implement the phy_smart_card_ops and register with the PHY
> framework.

I would try to avoid that. Otherwise we will have phy_usb_ops,
phy_sata_ops, phy_network_ops, phy_pci_ops, etc etc etc. It would easily
blow up.

-- 
balbi
-------------- 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/20130703/9388d732/attachment.sig>

From rogerq at ti.com  Wed Jul  3 09:06:04 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 3 Jul 2013 16:06:04 +0300
Subject: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during
 bus suspend
In-Reply-To: <20130703125719.GD15056@arwen.pp.htv.fi>
References: <51D28DB9.704@ti.com>
 <Pine.LNX.4.44L0.1307021302430.1086-100000@iolanthe.rowland.org>
 <20130703125719.GD15056@arwen.pp.htv.fi>
Message-ID: <51D421BC.9050600@ti.com>

On 07/03/2013 03:57 PM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 02, 2013 at 01:17:58PM -0400, Alan Stern wrote:
>> A PCI-based EHCI controller has two power sources: the core well (which
>> is turned off during suspend) and the auxiliary well (which remains
>> powered).  That's how remote wakeup works; it uses the auxiliary well.
> 
> This, kinda, matches what OMAP tries to do with pad wakeup. Just that
> pad wakeup sits outside of the device itself. Perhaps we could look into
> how PCI handles the aux well and take some inspiration from there.
> 
> Any pointers under drivers/pci/ would be great :-)
> 
>From what I understood, auxiliary well is just a power source, and it keeps
the EHCI controller powered even during suspend.

If that is true then it is different from our situation as we power down the
EHCI controller completely.

cheers,
-roger


From ezequiel.garcia at free-electrons.com  Wed Jul  3 09:00:55 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Wed, 3 Jul 2013 10:00:55 -0300
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130703094203.37562f9c@skate>
References: <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
 <20130702232311.GA3949@localhost> <20130703094203.37562f9c@skate>
Message-ID: <20130703130054.GA2382@localhost>


On Wed, Jul 03, 2013 at 09:42:03AM +0200, Thomas Petazzoni wrote:
> On Tue, 2 Jul 2013 20:23:12 -0300, Ezequiel Garcia wrote:
> 
> > I wish I could say I'm going to work on this soon but, as Thomas said,
> > we have no idea when/if NAND will be prioritized.
> > 
> > On the other side if you look at the driver Willy just posted, merging
> > the juicy stuff into pxa3xx-nand driver is not for the faint of heart.
> > 
> > Without the spec, is only tougher.
> > 
> > Just a quick hint. As far as I can recall, one of the first items in a
> > TODO list should be:
> > 
> >  * adding bigger page support to pxa3xx (4 KiB, 8 KiB).
> >    Willy's posted driver might be helpful to accomplish this;
> >    provided your eyes don't melt when you look at it :-)
> > 
> >  * once the above is done, bad block management can/should be added.
> > 
> > With these two we're almost there for R/W support.
> 
> Wasn't also part of the TODO-list to make pxa3xx_nand divorce from the
> PXA-specific DMA API, and use instead the PXA dmaengine driver, through
> the DMA engine API? As far as I remember, this was one of the
> prerequisite to be able to re-use the driver in a non-PXA context.
> There is a patch that was floating around doing this conversion (I
> could dig the relevant link if needed), but of course it needs to be
> tested, and we don't have PXA3xx hardware, so making changes to this
> driver without breaking it is quite tedious.
> 

Well that conversion is not *strictly* needed to get R/W support.
AFAICR, you just need to add some nasty ifdefs around the
mach-pxa-specific headers.

The conversion you mention is needed to have DMA on platforms
other than pxa.

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From coelho at ti.com  Wed Jul  3 10:15:25 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 3 Jul 2013 17:15:25 +0300
Subject: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead
 of hiding behind a quirk
In-Reply-To: <1372860209-3504-3-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
 <1372860209-3504-3-git-send-email-coelho@ti.com>
Message-ID: <1372860925.21065.115.camel@cumari.coelho.fi>

On Wed, 2013-07-03 at 17:03 +0300, Luciano Coelho wrote:
> The platform_quirk element in the platform data was used to change the
> way the IRQ is triggered.  When set, the EDGE_IRQ quirk would change
> the irqflags used and treat edge trigger differently from the rest.
> 
> Instead of hiding this irq flag setting behind the quirk, have the
> board files set the flags during initialization.  This will be more
> meaningful than driver-specific quirks when we switch to DT.
> 
> Additionally, fix missing gpio_request() calls in the boarding files
> (so that setting the flags actually works).
> 
> Cc: Tony Lindgren <tony at atomide.com>
> Cc: Sekhar Nori <nsekhar at ti.com>
> Signed-off-by: Luciano Coelho <coelho at ti.com>
> ---

[...]

> @@ -5928,16 +5927,21 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
>  	wlcore_adjust_conf(wl);
>  
>  	wl->irq = platform_get_irq(pdev, 0);
> -	wl->platform_quirks = pdata->platform_quirks;
>  	wl->if_ops = pdev_data->if_ops;
>  
> -	if (wl->platform_quirks & WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
> -		irqflags = IRQF_TRIGGER_RISING;
> -	else
> -		irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
> +	irq_data = irq_get_irq_data(wl->irq);
> +	if (!irq_data) {
> +		wl1271_error("couldn't get irq data for irq %d\n", wl->irq);
> +		ret = -EINVAL;
> +		goto out_free_nvs;
> +	}
> +
> +	wl->irq_flags = irqd_get_trigger_type(irq_data);

BTW, there seems to be a patch on its way to make reading the flags
easier (ie. no need to get the irq_data first):

http://mid.gmane.org/1367945288-5625-1-git-send-email-javier at dowhile0.org

I'm not sure if this is going to be taken in, but if it does, it would
be nice to change the code here to use the new irq_get_trigger_type()
function.

--
Luca.



From balbi at ti.com  Wed Jul  3 08:57:19 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Jul 2013 15:57:19 +0300
Subject: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during
 bus suspend
In-Reply-To: <Pine.LNX.4.44L0.1307021302430.1086-100000@iolanthe.rowland.org>
References: <51D28DB9.704@ti.com>
 <Pine.LNX.4.44L0.1307021302430.1086-100000@iolanthe.rowland.org>
Message-ID: <20130703125719.GD15056@arwen.pp.htv.fi>

Hi,

On Tue, Jul 02, 2013 at 01:17:58PM -0400, Alan Stern wrote:
> A PCI-based EHCI controller has two power sources: the core well (which
> is turned off during suspend) and the auxiliary well (which remains
> powered).  That's how remote wakeup works; it uses the auxiliary well.

This, kinda, matches what OMAP tries to do with pad wakeup. Just that
pad wakeup sits outside of the device itself. Perhaps we could look into
how PCI handles the aux well and take some inspiration from there.

Any pointers under drivers/pci/ would be great :-)

-- 
balbi
-------------- 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/20130703/3c404967/attachment.sig>

From balbi at ti.com  Wed Jul  3 09:15:13 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 3 Jul 2013 16:15:13 +0300
Subject: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during
 bus suspend
In-Reply-To: <51D421BC.9050600@ti.com>
References: <51D28DB9.704@ti.com>
 <Pine.LNX.4.44L0.1307021302430.1086-100000@iolanthe.rowland.org>
 <20130703125719.GD15056@arwen.pp.htv.fi> <51D421BC.9050600@ti.com>
Message-ID: <20130703131513.GH15056@arwen.pp.htv.fi>

On Wed, Jul 03, 2013 at 04:06:04PM +0300, Roger Quadros wrote:
> On 07/03/2013 03:57 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Tue, Jul 02, 2013 at 01:17:58PM -0400, Alan Stern wrote:
> >> A PCI-based EHCI controller has two power sources: the core well (which
> >> is turned off during suspend) and the auxiliary well (which remains
> >> powered).  That's how remote wakeup works; it uses the auxiliary well.
> > 
> > This, kinda, matches what OMAP tries to do with pad wakeup. Just that
> > pad wakeup sits outside of the device itself. Perhaps we could look into
> > how PCI handles the aux well and take some inspiration from there.
> > 
> > Any pointers under drivers/pci/ would be great :-)
> > 
> From what I understood, auxiliary well is just a power source, and it keeps
> the EHCI controller powered even during suspend.
> 
> If that is true then it is different from our situation as we power down the
> EHCI controller completely.

right but our "auxiliary well" keeps PRCM powered which can wake EHCI up
;-)

What I'm saying is that from ehci-omap's perspective, there's very
little difference, specially since we route the wakeup through the same
IRQ line anyway. Perhaps we could take some inspiration from the PCI
land to make our hwmod/omap_device a little easier from driver
perspective.

Or maybe it doesn't make sense ;-)

-- 
balbi
-------------- 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/20130703/22b54fc6/attachment.sig>

From marc.zyngier at arm.com  Wed Jul  3 10:40:06 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 03 Jul 2013 15:40:06 +0100
Subject: Proposal: mach-dt
In-Reply-To: <51D43127.6080206@codeaurora.org>
References: <1372839486.487159774@f54.mail.ru> <51D3ECD1.8030305@arm.com>
 <51D42F3C.3020805@codeaurora.org> <51D430DE.3030609@arm.com>
 <51D43127.6080206@codeaurora.org>
Message-ID: <51D437C6.9000909@arm.com>

On 03/07/13 15:11, Christopher Covington wrote:
> On 07/03/2013 10:10 AM, Marc Zyngier wrote:
>> On 03/07/13 15:03, Christopher Covington wrote:
>>> On 07/03/2013 05:20 AM, Marc Zyngier wrote:
>>>> On 03/07/13 09:18, Alexander Shiyan wrote:
>>>>
>>>> Hi Alexander,
>>>>
>>>>> More and more platforms are now using devicetree.
>>>>> Ideally the platform code contains only one function "of_platform_populate".
>>>>> My idea is to make a generic architecture (mach-dt) with the call then add support
>>>>> for compatible subarchitectures as they become available in "compatible"-property.
>>>>> Your opinion?
>>>>
>>>> Well, my (admittedly partial) opinion is that mach-virt is an incredibly
>>>> nicer sounding name, 'specially as you can mistype it as mach-triv.
>>>
>>> As mentioned before, I disagree and would love to see the the
>>> virtualization-specific name replaced by something more suitably generic.
>>
>> I think you're missing the point. The right fix would to remove it
>> entirely and make it the basic default. There are patches for that already.
> 
> Where?

There were patches from Arnd (CC-ed) a while ago, moving some of the
mach-virt SMP stuff to smp.c. Don't have the pointers handy, but surely
Arnd knows where they are.

Once SMP is done, the rest should be pretty trivial.

	M.
-- 
Jazz is not dead. It just smells funny...



From festevam at gmail.com  Wed Jul  3 12:55:10 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed,  3 Jul 2013 13:55:10 -0300
Subject: [PATCH v2] ARM: mx6: Fix the number of reported cores
Message-ID: <1372870510-14624-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

On a mx6 quad-core processor:

$ cat /proc/cpuinfo                                             
processor       : 0                                                             
model name      : ARMv7 Processor rev 10 (v7l)                                  
BogoMIPS        : 1581.05                                                       
Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls               
CPU implementer : 0x41                                                          
CPU architecture: 7                                                             
CPU variant     : 0x2                                                           
CPU part        : 0xc09                                                         
CPU revision    : 10                                                            

,which incorrectly shows this is a single core device.

Commit a0ae0240 (ARM: kernel: add device tree init map function) introduced the 
following requirement according to Documentation/devicetree/bindings/arm/cpus.txt:
"For the ARM architecture every CPU node must contain the following properties:

- device_type:	must be "cpu" 

Pass the 'device_type' property for each cpu node, so that we can have all the 
four cores correctly reported again.

Cc: <stable at vger.kernel.org> #3.10
Reported-by: Mike Loebl <mloebl at gmail.com> 
Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- Add missing ";" in the dual-lite .dtsi

 arch/arm/boot/dts/imx6dl.dtsi | 2 ++
 arch/arm/boot/dts/imx6q.dtsi  | 4 ++++
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 5bcdf3a..62dc781 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -18,12 +18,14 @@
 
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <0>;
 			next-level-cache = <&L2>;
 		};
 
 		cpu at 1 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <1>;
 			next-level-cache = <&L2>;
 		};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 21e6758..dc54a72 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -18,6 +18,7 @@
 
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <0>;
 			next-level-cache = <&L2>;
 			operating-points = <
@@ -39,18 +40,21 @@
 
 		cpu at 1 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <1>;
 			next-level-cache = <&L2>;
 		};
 
 		cpu at 2 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <2>;
 			next-level-cache = <&L2>;
 		};
 
 		cpu at 3 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <3>;
 			next-level-cache = <&L2>;
 		};
-- 
1.8.1.2



From sebastian.hesselbarth at gmail.com  Wed Jul  3 12:57:51 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Wed,  3 Jul 2013 18:57:51 +0200
Subject: [PATCH v7 5/7] ARM: kirkwood: remove redundant DT board files
In-Reply-To: <1372762824-12202-6-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762824-12202-6-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1372870671-3083-1-git-send-email-sebastian.hesselbarth@gmail.com>

With DT support for mv643xx_eth board specific init for some boards now
is unneccessary. Remove those board files, Kconfig entries, and
corresponding entries in kirkwood_defconfig.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Changelog:
v6->v7:
- cleanup mach-kirkwood/common.h (Reported by Arnaud Ebalard)
- also remove MACH_TS219_DT (Suggested by Jason Cooper)

v5->v6:
- rebase for v3.11-rc1

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: netdev at vger.kernel.org
---
 arch/arm/configs/kirkwood_defconfig           |   23 ----
 arch/arm/mach-kirkwood/Kconfig                |  171 -------------------------
 arch/arm/mach-kirkwood/Makefile               |   22 ---
 arch/arm/mach-kirkwood/board-db88f628x-bp.c   |   24 ----
 arch/arm/mach-kirkwood/board-dnskw.c          |    7 -
 arch/arm/mach-kirkwood/board-dockstar.c       |   32 -----
 arch/arm/mach-kirkwood/board-dreamplug.c      |   35 -----
 arch/arm/mach-kirkwood/board-dt.c             |   84 +------------
 arch/arm/mach-kirkwood/board-goflexnet.c      |   34 -----
 arch/arm/mach-kirkwood/board-guruplug.c       |   33 -----
 arch/arm/mach-kirkwood/board-ib62x0.c         |   29 ----
 arch/arm/mach-kirkwood/board-iconnect.c       |   24 ----
 arch/arm/mach-kirkwood/board-iomega_ix2_200.c |   34 -----
 arch/arm/mach-kirkwood/board-km_kirkwood.c    |   44 -------
 arch/arm/mach-kirkwood/board-lsxl.c           |   36 -----
 arch/arm/mach-kirkwood/board-mplcec4.c        |   35 -----
 arch/arm/mach-kirkwood/board-ns2.c            |   35 -----
 arch/arm/mach-kirkwood/board-openblocks_a6.c  |   26 ----
 arch/arm/mach-kirkwood/board-readynas.c       |   27 ----
 arch/arm/mach-kirkwood/board-sheevaplug.c     |   27 ----
 arch/arm/mach-kirkwood/board-ts219.c          |   40 ------
 arch/arm/mach-kirkwood/board-usi_topkick.c    |   29 ----
 arch/arm/mach-kirkwood/common.h               |  109 ----------------
 23 files changed, 1 insertions(+), 959 deletions(-)
 delete mode 100644 arch/arm/mach-kirkwood/board-db88f628x-bp.c
 delete mode 100644 arch/arm/mach-kirkwood/board-dockstar.c
 delete mode 100644 arch/arm/mach-kirkwood/board-dreamplug.c
 delete mode 100644 arch/arm/mach-kirkwood/board-goflexnet.c
 delete mode 100644 arch/arm/mach-kirkwood/board-guruplug.c
 delete mode 100644 arch/arm/mach-kirkwood/board-ib62x0.c
 delete mode 100644 arch/arm/mach-kirkwood/board-iconnect.c
 delete mode 100644 arch/arm/mach-kirkwood/board-iomega_ix2_200.c
 delete mode 100644 arch/arm/mach-kirkwood/board-km_kirkwood.c
 delete mode 100644 arch/arm/mach-kirkwood/board-lsxl.c
 delete mode 100644 arch/arm/mach-kirkwood/board-mplcec4.c
 delete mode 100644 arch/arm/mach-kirkwood/board-ns2.c
 delete mode 100644 arch/arm/mach-kirkwood/board-openblocks_a6.c
 delete mode 100644 arch/arm/mach-kirkwood/board-readynas.c
 delete mode 100644 arch/arm/mach-kirkwood/board-sheevaplug.c
 delete mode 100644 arch/arm/mach-kirkwood/board-ts219.c
 delete mode 100644 arch/arm/mach-kirkwood/board-usi_topkick.c

diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
index 0f2aa61..b180588 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig
@@ -29,30 +29,7 @@ CONFIG_MACH_SHEEVAPLUG=y
 CONFIG_MACH_T5325=y
 CONFIG_MACH_TS219=y
 CONFIG_MACH_TS41X=y
-CONFIG_MACH_CLOUDBOX_DT=y
-CONFIG_MACH_DB88F628X_BP_DT=y
 CONFIG_MACH_DLINK_KIRKWOOD_DT=y
-CONFIG_MACH_DOCKSTAR_DT=y
-CONFIG_MACH_DREAMPLUG_DT=y
-CONFIG_MACH_GOFLEXNET_DT=y
-CONFIG_MACH_GURUPLUG_DT=y
-CONFIG_MACH_IB62X0_DT=y
-CONFIG_MACH_ICONNECT_DT=y
-CONFIG_MACH_INETSPACE_V2_DT=y
-CONFIG_MACH_IOMEGA_IX2_200_DT=y
-CONFIG_MACH_KM_KIRKWOOD_DT=y
-CONFIG_MACH_LSXL_DT=y
-CONFIG_MACH_MPLCEC4_DT=y
-CONFIG_MACH_NETSPACE_LITE_V2_DT=y
-CONFIG_MACH_NETSPACE_MAX_V2_DT=y
-CONFIG_MACH_NETSPACE_MINI_V2_DT=y
-CONFIG_MACH_NETSPACE_V2_DT=y
-CONFIG_MACH_NSA310_DT=y
-CONFIG_MACH_OPENBLOCKS_A6_DT=y
-CONFIG_MACH_READYNAS_DT=y
-CONFIG_MACH_SHEEVAPLUG_DT=y
-CONFIG_MACH_TOPKICK_DT=y
-CONFIG_MACH_TS219_DT=y
 # CONFIG_CPU_FEROCEON_OLD_ID is not set
 CONFIG_PCI_MVEBU=y
 CONFIG_PREEMPT=y
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index b634f96..e28cb72 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -139,20 +139,6 @@ config ARCH_KIRKWOOD_DT
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell Kirkwood using flattened device tree.
 
-config MACH_CLOUDBOX_DT
-	bool "LaCie CloudBox NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  CloudBox NAS, using Flattened Device Tree.
-
-config MACH_DB88F628X_BP_DT
-	bool "Marvell DB-88F628x-BP Development Board (Flattened Device Tree)"
-	help
-	  Say 'Y' here if you want your kernel to support the Marvell
-	  DB-88F6281-BP and DB-88F6282-BP Development Board (Flattened
-	  Device Tree).
-
 config MACH_DLINK_KIRKWOOD_DT
 	bool "D-Link Kirkwood-based NAS (Flattened Device Tree)"
 	select ARCH_KIRKWOOD_DT
@@ -161,163 +147,6 @@ config MACH_DLINK_KIRKWOOD_DT
 	  Kirkwood-based D-Link NASes such as DNS-320 & DNS-325,
 	  using Flattened Device Tree.
 
-config MACH_DOCKSTAR_DT
-	bool "Seagate FreeAgent Dockstar (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Seagate FreeAgent Dockstar (Flattened Device Tree).
-
-config MACH_DREAMPLUG_DT
-	bool "Marvell DreamPlug (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell DreamPlug (Flattened Device Tree).
-
-config MACH_GOFLEXNET_DT
-	bool "Seagate GoFlex Net (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Seagate GoFlex Net (Flattened Device Tree).
-
-config MACH_GURUPLUG_DT
-	bool "Marvell GuruPlug Reference Board (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell GuruPlug Reference Board (Flattened Device Tree).
-
-config MACH_IB62X0_DT
-	bool "RaidSonic IB-NAS6210, IB-NAS6220 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  RaidSonic IB-NAS6210 & IB-NAS6220 devices, using
-	  Flattened Device Tree.
-
-config MACH_ICONNECT_DT
-	bool "Iomega Iconnect (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here to enable Iomega Iconnect support.
-
-config MACH_INETSPACE_V2_DT
-	bool "LaCie Internet Space v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Internet Space v2 NAS, using Flattened Device Tree.
-
-config MACH_IOMEGA_IX2_200_DT
-	bool "Iomega StorCenter ix2-200 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Iomega StorCenter ix2-200 (Flattened Device Tree).
-
-config MACH_KM_KIRKWOOD_DT
-	bool "Keymile Kirkwood Reference Design (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Keymile Kirkwood Reference Desgin, using Flattened Device Tree.
-
-config MACH_LSXL_DT
-	bool "Buffalo Linkstation LS-XHL, LS-CHLv2 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	select POWER_RESET_RESTART
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Buffalo Linkstation LS-XHL & LS-CHLv2 devices, using
-	  Flattened Device Tree.
-
-config MACH_MPLCEC4_DT
-	bool "MPL CEC4 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  MPL CEC4 (Flattened Device Tree).
-
-config MACH_NETSPACE_LITE_V2_DT
-	bool "LaCie Network Space Lite v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space Lite v2 NAS, using Flattened Device Tree.
-
-config MACH_NETSPACE_MAX_V2_DT
-	bool "LaCie Network Space Max v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space Max v2 NAS, using Flattened Device Tree.
-
-config MACH_NETSPACE_MINI_V2_DT
-	bool "LaCie Network Space Mini v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space Mini v2 NAS using Flattened Device Tree.
-
-	  This board is embedded in a product named CloudBox, which
-	  provides automatic backup on a 100GB cloud storage. This
-	  should not confused with a more recent LaCie NAS also named
-	  CloudBox. For this last, the disk capacity is 1TB or above.
-
-config MACH_NETSPACE_V2_DT
-	bool "LaCie Network Space v2 NAS (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the LaCie
-	  Network Space v2 NAS, using Flattened Device Tree.
-
-config MACH_OPENBLOCKS_A6_DT
-	bool "Plat'Home OpenBlocks A6 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Plat'Home OpenBlocks A6 (Flattened Device Tree).
-
-config MACH_READYNAS_DT
-	bool "NETGEAR ReadyNAS Duo v2 (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	select ARM_APPENDED_DTB
-	select ARM_ATAG_DTB_COMPAT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  NETGEAR ReadyNAS Duo v2 using Fattened Device Tree.
-
-config MACH_SHEEVAPLUG_DT
-	bool "Marvell (eSATA) SheevaPlug (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  Marvell (eSATA) SheevaPlug (Flattened Device Tree).
-
-config MACH_TOPKICK_DT
-	bool "USI Topkick (Flattened Device Tree)"
-	select ARCH_KIRKWOOD_DT
-	help
-	  Say 'Y' here if you want your kernel to support the
-	  USI Topkick, using Flattened Device Tree
-
-config MACH_TS219_DT
-	bool "Device Tree for QNAP TS-11X, TS-21X NAS"
-	select ARCH_KIRKWOOD_DT
-	select ARM_APPENDED_DTB
-	select ARM_ATAG_DTB_COMPAT
-	select POWER_RESET_QNAP
-	help
-	  Say 'Y' here if you want your kernel to support the QNAP
-	  TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
-	  TS-219P+ Turbo NAS devices using Fattened Device Tree.
-	  There are two different Device Tree descriptions, depending
-	  on if the device is based on an if the board uses the MV6281
-	  or MV6282. If you have the wrong one, the buttons will not
-	  work.
-
 endmenu
 
 endif
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index ac4cd75..9489c82 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -19,26 +19,4 @@ obj-$(CONFIG_MACH_TS219)		+= ts219-setup.o tsx1x-common.o
 obj-$(CONFIG_MACH_TS41X)		+= ts41x-setup.o tsx1x-common.o
 
 obj-$(CONFIG_ARCH_KIRKWOOD_DT)		+= board-dt.o
-obj-$(CONFIG_MACH_CLOUDBOX_DT)		+= board-ns2.o
-obj-$(CONFIG_MACH_DB88F628X_BP_DT)	+= board-db88f628x-bp.o
 obj-$(CONFIG_MACH_DLINK_KIRKWOOD_DT)	+= board-dnskw.o
-obj-$(CONFIG_MACH_DOCKSTAR_DT)		+= board-dockstar.o
-obj-$(CONFIG_MACH_DREAMPLUG_DT)		+= board-dreamplug.o
-obj-$(CONFIG_MACH_GOFLEXNET_DT)		+= board-goflexnet.o
-obj-$(CONFIG_MACH_GURUPLUG_DT)		+= board-guruplug.o
-obj-$(CONFIG_MACH_IB62X0_DT)		+= board-ib62x0.o
-obj-$(CONFIG_MACH_ICONNECT_DT)		+= board-iconnect.o
-obj-$(CONFIG_MACH_INETSPACE_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_IOMEGA_IX2_200_DT)	+= board-iomega_ix2_200.o
-obj-$(CONFIG_MACH_KM_KIRKWOOD_DT)	+= board-km_kirkwood.o
-obj-$(CONFIG_MACH_LSXL_DT)		+= board-lsxl.o
-obj-$(CONFIG_MACH_MPLCEC4_DT)		+= board-mplcec4.o
-obj-$(CONFIG_MACH_NETSPACE_LITE_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_NETSPACE_MAX_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_NETSPACE_MINI_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_NETSPACE_V2_DT)	+= board-ns2.o
-obj-$(CONFIG_MACH_OPENBLOCKS_A6_DT)	+= board-openblocks_a6.o
-obj-$(CONFIG_MACH_READYNAS_DT)		+= board-readynas.o
-obj-$(CONFIG_MACH_SHEEVAPLUG_DT)	+= board-sheevaplug.o
-obj-$(CONFIG_MACH_TOPKICK_DT)		+= board-usi_topkick.o
-obj-$(CONFIG_MACH_TS219_DT)		+= board-ts219.o tsx1x-common.o
diff --git a/arch/arm/mach-kirkwood/board-db88f628x-bp.c b/arch/arm/mach-kirkwood/board-db88f628x-bp.c
deleted file mode 100644
index 2f574bc..0000000
--- a/arch/arm/mach-kirkwood/board-db88f628x-bp.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * Saeed Bishara <saeed at marvell.com>
- *
- * Marvell DB-88F628{1,2}-BP Development Board Setup
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/of.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data db88f628x_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init db88f628x_init(void)
-{
-	kirkwood_ge00_init(&db88f628x_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-dnskw.c b/arch/arm/mach-kirkwood/board-dnskw.c
index a1aa87f..2af7a95 100644
--- a/arch/arm/mach-kirkwood/board-dnskw.c
+++ b/arch/arm/mach-kirkwood/board-dnskw.c
@@ -14,14 +14,9 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
 #include <linux/gpio.h>
 #include "common.h"
 
-static struct mv643xx_eth_platform_data dnskw_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
 /* Register any GPIO for output and set the value */
 static void __init dnskw_gpio_register(unsigned gpio, char *name, int def)
 {
@@ -36,8 +31,6 @@ static void __init dnskw_gpio_register(unsigned gpio, char *name, int def)
 
 void __init dnskw_init(void)
 {
-	kirkwood_ge00_init(&dnskw_ge00_data);
-
 	/* Set NAS to turn back on after a power failure */
 	dnskw_gpio_register(37, "dnskw:power:recover", 1);
 }
diff --git a/arch/arm/mach-kirkwood/board-dockstar.c b/arch/arm/mach-kirkwood/board-dockstar.c
deleted file mode 100644
index d7196db..0000000
--- a/arch/arm/mach-kirkwood/board-dockstar.c
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-dockstar.c
- *
- * Seagate FreeAgent Dockstar Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- *
- * Copied and modified for Seagate GoFlex Net support by
- * Joshua Coombs <josh.coombs at gmail.com> based on ArchLinux ARM's
- * GoFlex kernel patches.
- *
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data dockstar_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init dockstar_dt_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&dockstar_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-dreamplug.c b/arch/arm/mach-kirkwood/board-dreamplug.c
deleted file mode 100644
index 0903242..0000000
--- a/arch/arm/mach-kirkwood/board-dreamplug.c
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Copyright 2012 (C), Jason Cooper <jason at lakedaemon.net>
- *
- * arch/arm/mach-kirkwood/board-dreamplug.c
- *
- * Marvell DreamPlug Reference Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/gpio.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data dreamplug_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data dreamplug_ge01_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(1),
-};
-
-void __init dreamplug_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&dreamplug_ge00_data);
-	kirkwood_ge01_init(&dreamplug_ge01_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 6e122ed..a3271f6 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -102,96 +102,14 @@ static void __init kirkwood_dt_init(void)
 	kexec_reinit = kirkwood_enable_pcie;
 #endif
 
-	if (of_machine_is_compatible("globalscale,dreamplug"))
-		dreamplug_init();
-
-	if (of_machine_is_compatible("globalscale,guruplug"))
-		guruplug_dt_init();
-
-	if (of_machine_is_compatible("globalscale,sheevaplug"))
-		sheevaplug_dt_init();
-
 	if (of_machine_is_compatible("dlink,dns-kirkwood"))
 		dnskw_init();
 
-	if (of_machine_is_compatible("iom,iconnect"))
-		iconnect_init();
-
-	if (of_machine_is_compatible("raidsonic,ib-nas62x0"))
-		ib62x0_init();
-
-	if (of_machine_is_compatible("qnap,ts219"))
-		qnap_dt_ts219_init();
-
-	if (of_machine_is_compatible("seagate,dockstar"))
-		dockstar_dt_init();
-
-	if (of_machine_is_compatible("seagate,goflexnet"))
-		goflexnet_init();
-
-	if (of_machine_is_compatible("buffalo,lsxl"))
-		lsxl_init();
-
-	if (of_machine_is_compatible("iom,ix2-200"))
-		iomega_ix2_200_init();
-
-	if (of_machine_is_compatible("keymile,km_kirkwood"))
-		km_kirkwood_init();
-
-	if (of_machine_is_compatible("lacie,cloudbox") ||
-	    of_machine_is_compatible("lacie,inetspace_v2") ||
-	    of_machine_is_compatible("lacie,netspace_lite_v2") ||
-	    of_machine_is_compatible("lacie,netspace_max_v2") ||
-	    of_machine_is_compatible("lacie,netspace_mini_v2") ||
-	    of_machine_is_compatible("lacie,netspace_v2"))
-		ns2_init();
-
-	if (of_machine_is_compatible("marvell,db-88f6281-bp") ||
-	    of_machine_is_compatible("marvell,db-88f6282-bp"))
-		db88f628x_init();
-
-	if (of_machine_is_compatible("mpl,cec4"))
-		mplcec4_init();
-
-	if (of_machine_is_compatible("netgear,readynas-duo-v2"))
-		netgear_readynas_init();
-
-	if (of_machine_is_compatible("plathome,openblocks-a6"))
-		openblocks_a6_init();
-
-	if (of_machine_is_compatible("usi,topkick"))
-		usi_topkick_init();
-
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
 static const char * const kirkwood_dt_board_compat[] = {
-	"globalscale,dreamplug",
-	"globalscale,guruplug",
-	"globalscale,sheevaplug",
-	"dlink,dns-320",
-	"dlink,dns-325",
-	"iom,iconnect",
-	"raidsonic,ib-nas62x0",
-	"qnap,ts219",
-	"seagate,dockstar",
-	"seagate,goflexnet",
-	"buffalo,lsxl",
-	"iom,ix2-200",
-	"keymile,km_kirkwood",
-	"lacie,cloudbox",
-	"lacie,inetspace_v2",
-	"lacie,netspace_lite_v2",
-	"lacie,netspace_max_v2",
-	"lacie,netspace_mini_v2",
-	"lacie,netspace_v2",
-	"marvell,db-88f6281-bp",
-	"marvell,db-88f6282-bp",
-	"mpl,cec4",
-	"netgear,readynas-duo-v2",
-	"plathome,openblocks-a6",
-	"usi,topkick",
-	"zyxel,nsa310",
+	"marvell,kirkwood",
 	NULL
 };
 
diff --git a/arch/arm/mach-kirkwood/board-goflexnet.c b/arch/arm/mach-kirkwood/board-goflexnet.c
deleted file mode 100644
index 9db979a..0000000
--- a/arch/arm/mach-kirkwood/board-goflexnet.c
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * Copyright 2012 (C), Jason Cooper <jason at lakedaemon.net>
- *
- * arch/arm/mach-kirkwood/board-goflexnet.c
- *
- * Seagate GoFlext Net Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- *
- * Copied and modified for Seagate GoFlex Net support by
- * Joshua Coombs <josh.coombs at gmail.com> based on ArchLinux ARM's
- * GoFlex kernel patches.
- *
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data goflexnet_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init goflexnet_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&goflexnet_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-guruplug.c b/arch/arm/mach-kirkwood/board-guruplug.c
deleted file mode 100644
index a857163..0000000
--- a/arch/arm/mach-kirkwood/board-guruplug.c
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-guruplug.c
- *
- * Marvell Guruplug Reference Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/gpio.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data guruplug_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data guruplug_ge01_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(1),
-};
-
-void __init guruplug_dt_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&guruplug_ge00_data);
-	kirkwood_ge01_init(&guruplug_ge01_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-ib62x0.c b/arch/arm/mach-kirkwood/board-ib62x0.c
deleted file mode 100644
index 9a857ae..0000000
--- a/arch/arm/mach-kirkwood/board-ib62x0.c
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * Copyright 2012 (C), Simon Baatz <gmbnomis at gmail.com>
- *
- * arch/arm/mach-kirkwood/board-ib62x0.c
- *
- * RaidSonic ICY BOX IB-NAS6210 & IB-NAS6220 init for drivers not
- * converted to flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data ib62x0_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init ib62x0_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&ib62x0_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-iconnect.c b/arch/arm/mach-kirkwood/board-iconnect.c
deleted file mode 100644
index 98b5ad1..0000000
--- a/arch/arm/mach-kirkwood/board-iconnect.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-iconnect.c
- *
- * Iomega i-connect Board Setup
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/of.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data iconnect_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(11),
-};
-
-void __init iconnect_init(void)
-{
-	kirkwood_ge00_init(&iconnect_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-iomega_ix2_200.c b/arch/arm/mach-kirkwood/board-iomega_ix2_200.c
deleted file mode 100644
index e5f7041..0000000
--- a/arch/arm/mach-kirkwood/board-iomega_ix2_200.c
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-iomega_ix2_200.c
- *
- * Iomega StorCenter ix2-200
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/ethtool.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data iomega_ix2_200_ge00_data = {
-	.phy_addr       = MV643XX_ETH_PHY_NONE,
-	.speed          = SPEED_1000,
-	.duplex         = DUPLEX_FULL,
-};
-
-static struct mv643xx_eth_platform_data iomega_ix2_200_ge01_data = {
-        .phy_addr       = MV643XX_ETH_PHY_ADDR(11),
-};
-
-void __init iomega_ix2_200_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&iomega_ix2_200_ge00_data);
-	kirkwood_ge01_init(&iomega_ix2_200_ge01_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-km_kirkwood.c b/arch/arm/mach-kirkwood/board-km_kirkwood.c
deleted file mode 100644
index 44e4605..0000000
--- a/arch/arm/mach-kirkwood/board-km_kirkwood.c
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * Copyright 2012 2012 KEYMILE AG, CH-3097 Bern
- * Valentin Longchamp <valentin.longchamp at keymile.com>
- *
- * arch/arm/mach-kirkwood/board-km_kirkwood.c
- *
- * Keymile km_kirkwood Reference Desing Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/clk.h>
-#include <linux/clk-private.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data km_kirkwood_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init km_kirkwood_init(void)
-{
-	struct clk *sata_clk;
-	/*
-	 * Our variant of kirkwood (integrated in the Bobcat) hangs on accessing
-	 * SATA bits (14-15) of the Clock Gating Control Register. Since these
-	 * devices are also not present in this variant, their clocks get
-	 * disabled because unused when clk_disable_unused() gets called.
-	 * That's why we change the flags to these clocks to CLK_IGNORE_UNUSED
-	 */
-	sata_clk = clk_get_sys("sata_mv.0", "0");
-	if (!IS_ERR(sata_clk))
-		sata_clk->flags |= CLK_IGNORE_UNUSED;
-	sata_clk = clk_get_sys("sata_mv.0", "1");
-	if (!IS_ERR(sata_clk))
-		sata_clk->flags |= CLK_IGNORE_UNUSED;
-
-	kirkwood_ge00_init(&km_kirkwood_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-lsxl.c b/arch/arm/mach-kirkwood/board-lsxl.c
deleted file mode 100644
index 3483952..0000000
--- a/arch/arm/mach-kirkwood/board-lsxl.c
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * Copyright 2012 (C), Michael Walle <michael at walle.cc>
- *
- * arch/arm/mach-kirkwood/board-lsxl.c
- *
- * Buffalo Linkstation LS-XHL and LS-CHLv2 init for drivers not
- * converted to flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data lsxl_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data lsxl_ge01_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init lsxl_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-
-	kirkwood_ge00_init(&lsxl_ge00_data);
-	kirkwood_ge01_init(&lsxl_ge01_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-mplcec4.c b/arch/arm/mach-kirkwood/board-mplcec4.c
deleted file mode 100644
index 938712e..0000000
--- a/arch/arm/mach-kirkwood/board-mplcec4.c
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Copyright (C) 2012 MPL AG, Switzerland
- * Stefan Peter <s.peter at mpl.ch>
- *
- * arch/arm/mach-kirkwood/board-mplcec4.c
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data mplcec4_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(1),
-};
-
-static struct mv643xx_eth_platform_data mplcec4_ge01_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(2),
-};
-
-void __init mplcec4_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&mplcec4_ge00_data);
-	kirkwood_ge01_init(&mplcec4_ge01_data);
-}
-
-
-
diff --git a/arch/arm/mach-kirkwood/board-ns2.c b/arch/arm/mach-kirkwood/board-ns2.c
deleted file mode 100644
index f8f6605..0000000
--- a/arch/arm/mach-kirkwood/board-ns2.c
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Copyright 2012 (C), Simon Guinot <simon.guinot at sequanux.org>
- *
- * arch/arm/mach-kirkwood/board-ns2.c
- *
- * LaCie Network Space v2 board (and parents) initialization for drivers
- * not converted to flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/of.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data ns2_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init ns2_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	if (of_machine_is_compatible("lacie,cloudbox") ||
-	    of_machine_is_compatible("lacie,netspace_lite_v2") ||
-	    of_machine_is_compatible("lacie,netspace_mini_v2"))
-		ns2_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
-	kirkwood_ge00_init(&ns2_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-openblocks_a6.c b/arch/arm/mach-kirkwood/board-openblocks_a6.c
deleted file mode 100644
index b11d8fd..0000000
--- a/arch/arm/mach-kirkwood/board-openblocks_a6.c
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * Copyright 2012 Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
- *
- * arch/arm/mach-kirkwood/board-openblocks_a6.c
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data openblocks_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init openblocks_a6_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&openblocks_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-readynas.c b/arch/arm/mach-kirkwood/board-readynas.c
deleted file mode 100644
index 341b82d..0000000
--- a/arch/arm/mach-kirkwood/board-readynas.c
+++ /dev/null
@@ -1,27 +0,0 @@
-/*
- * NETGEAR ReadyNAS Duo v2 Board setup for drivers not already
- * converted to DT.
- *
- * Copyright (C) 2013, Arnaud EBALARD <arno at natisbad.org>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
-#include <mach/kirkwood.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data netgear_readynas_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init netgear_readynas_init(void)
-{
-	kirkwood_ge00_init(&netgear_readynas_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-sheevaplug.c b/arch/arm/mach-kirkwood/board-sheevaplug.c
deleted file mode 100644
index fa38937..0000000
--- a/arch/arm/mach-kirkwood/board-sheevaplug.c
+++ /dev/null
@@ -1,27 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/board-sheevaplug.c
- *
- * Marvell Sheevaplug Reference Board Init for drivers not converted to
- * flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data sheevaplug_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init sheevaplug_dt_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&sheevaplug_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
deleted file mode 100644
index 860f44a..0000000
--- a/arch/arm/mach-kirkwood/board-ts219.c
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- *
- * QNAP TS-11x/TS-21x Turbo NAS Board Setup via DT
- *
- * Copyright (C) 2012 Andrew Lunn <andrew at lunn.ch>
- *
- * Based on the board file ts219-setup.c:
- *
- * Copyright (C) 2009  Martin Michlmayr <tbm at cyrius.com>
- * Copyright (C) 2008  Byron Bradley <byron.bbradley at gmail.com>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <mach/kirkwood.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data qnap_ts219_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
-};
-
-void __init qnap_dt_ts219_init(void)
-{
-	u32 dev, rev;
-
-	kirkwood_pcie_id(&dev, &rev);
-	if (dev == MV88F6282_DEV_ID)
-		qnap_ts219_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
-
-	kirkwood_ge00_init(&qnap_ts219_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/board-usi_topkick.c b/arch/arm/mach-kirkwood/board-usi_topkick.c
deleted file mode 100644
index 1cc04ec..0000000
--- a/arch/arm/mach-kirkwood/board-usi_topkick.c
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * Copyright 2012 (C), Jason Cooper <jason at lakedaemon.net>
- *
- * arch/arm/mach-kirkwood/board-usi_topkick.c
- *
- * USI Topkick Init for drivers not converted to flattened device tree yet.
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/gpio.h>
-#include "common.h"
-
-static struct mv643xx_eth_platform_data topkick_ge00_data = {
-	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
-};
-
-void __init usi_topkick_init(void)
-{
-	/*
-	 * Basic setup. Needs to be called early.
-	 */
-	kirkwood_ge00_init(&topkick_ge00_data);
-}
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index fcf3ba6..9d8caae 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -59,121 +59,12 @@ void kirkwood_restart(enum reboot_mode, const char *);
 void kirkwood_clk_init(void);
 
 /* board init functions for boards not fully converted to fdt */
-#ifdef CONFIG_MACH_DREAMPLUG_DT
-void dreamplug_init(void);
-#else
-static inline void dreamplug_init(void) {};
-#endif
-#ifdef CONFIG_MACH_GURUPLUG_DT
-void guruplug_dt_init(void);
-#else
-static inline void guruplug_dt_init(void) {};
-#endif
-#ifdef CONFIG_MACH_SHEEVAPLUG_DT
-void sheevaplug_dt_init(void);
-#else
-static inline void sheevaplug_dt_init(void) {};
-#endif
-#ifdef CONFIG_MACH_TS219_DT
-void qnap_dt_ts219_init(void);
-#else
-static inline void qnap_dt_ts219_init(void) {};
-#endif
-
 #ifdef CONFIG_MACH_DLINK_KIRKWOOD_DT
 void dnskw_init(void);
 #else
 static inline void dnskw_init(void) {};
 #endif
 
-#ifdef CONFIG_MACH_ICONNECT_DT
-void iconnect_init(void);
-#else
-static inline void iconnect_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_IB62X0_DT
-void ib62x0_init(void);
-#else
-static inline void ib62x0_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_DOCKSTAR_DT
-void dockstar_dt_init(void);
-#else
-static inline void dockstar_dt_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_GOFLEXNET_DT
-void goflexnet_init(void);
-#else
-static inline void goflexnet_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_LSXL_DT
-void lsxl_init(void);
-#else
-static inline void lsxl_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_IOMEGA_IX2_200_DT
-void iomega_ix2_200_init(void);
-#else
-static inline void iomega_ix2_200_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_KM_KIRKWOOD_DT
-void km_kirkwood_init(void);
-#else
-static inline void km_kirkwood_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_DB88F628X_BP_DT
-void db88f628x_init(void);
-#else
-static inline void db88f628x_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_MPLCEC4_DT
-void mplcec4_init(void);
-#else
-static inline void mplcec4_init(void) {};
-#endif
-
-#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
-	defined(CONFIG_MACH_NETSPACE_V2_DT) || \
-	defined(CONFIG_MACH_NETSPACE_MAX_V2_DT) || \
-	defined(CONFIG_MACH_NETSPACE_LITE_V2_DT) || \
-	defined(CONFIG_MACH_NETSPACE_MINI_V2_DT)
-void ns2_init(void);
-#else
-static inline void ns2_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_OPENBLOCKS_A6_DT
-void openblocks_a6_init(void);
-#else
-static inline void openblocks_a6_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_READYNAS_DT
-void netgear_readynas_init(void);
-#else
-static inline void netgear_readynas_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_TOPKICK_DT
-void usi_topkick_init(void);
-#else
-static inline void usi_topkick_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_CLOUDBOX_DT
-void cloudbox_init(void);
-#else
-static inline void cloudbox_init(void) {};
-#endif
-
 /* early init functions not converted to fdt yet */
 char *kirkwood_id(void);
 void kirkwood_l2_init(void);
-- 
1.7.2.5



From linux at arm.linux.org.uk  Wed Jul  3 13:20:01 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 3 Jul 2013 18:20:01 +0100
Subject: [PATCH] ARM: move body of head-common.S back to text section
In-Reply-To: <20130703153012.GK22702@windriver.com>
References: <1372805629-18382-1-git-send-email-swarren@wwwdotorg.org>
 <20130702232259.GH11625@codeaurora.org> <51D39004.9000907@wwwdotorg.org>
 <20130703051907.GA22702@windriver.com>
 <20130703100044.GG24642@n2100.arm.linux.org.uk>
 <20130703153012.GK22702@windriver.com>
Message-ID: <20130703172001.GH24642@n2100.arm.linux.org.uk>

On Wed, Jul 03, 2013 at 11:30:12AM -0400, Paul Gortmaker wrote:
> [Re: [PATCH] ARM: move body of head-common.S back to text section] On 03/07/2013 (Wed 11:00) Russell King - ARM Linux wrote:
> 
> > On Wed, Jul 03, 2013 at 01:19:07AM -0400, Paul Gortmaker wrote:
> > > As an aside, I'm now thinking any __INIT that implicitly rely on EOF for
> > > closure are nasty traps waiting to happen and it might be worthwhile to
> > > audit and explicitly __FINIT them before someone appends to the file...
> > 
> > That hides a different kind of bug though - I hate __FINIT for exactly
> > that reason.  Consider this:
> 
> Agreed - perhaps masking that it is a ".previous" just hides the fact
> that it is more like a pop operation vs. an on/off operation, or per
> function as we have in C.

I read the info pages, because I thought it was a pop operation too.
I was concerned that .section didn't push the previous section onto the
stack.

However, .popsection is the pseudio-op which pops.  .previous just toggles
the current section with the section immediately before it.

So:

	.text
	.data
	.previous
	/* this is .text */
	.previous
	/* this is .data */
	.previous
	/* this is .text */
	.previous
	/* this is .data */

> That seems reasonable to me.  I can't think of any self auditing that is
> reasonably simple to implement.  One downside of __FINIT as a no-op vs.
> what it is today, is that a dangling __FINIT in a file with no other
> previous sections will emit a warning.  But that is a small low value
> corner case I think.

That warning from __FINIT will only happen if there has been no section
or .text or .data statement in the file at all.  As soon as you have any
statement setting any kind of section, .previous doesn't warn.

So:

	.text
	...
	__FINIT

produces no warning.


From tomasz.figa at gmail.com  Wed Jul  3 14:07:33 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 03 Jul 2013 20:07:33 +0200
Subject: On common struct clk in clock framework.
In-Reply-To: <CAM2a4uyrX0t-W8hXKROvZgJPSyCY+DaviV-eRVZOhyPx=WNBUw@mail.gmail.com>
References: <CAM2a4uyrX0t-W8hXKROvZgJPSyCY+DaviV-eRVZOhyPx=WNBUw@mail.gmail.com>
Message-ID: <16151917.X00PMOJFZ6@flatron>

Hi,

On Wednesday 03 of July 2013 19:05:03 mind entropy wrote:
> Hi,
> 
>    I am reading through mini2440 code and trying to understand
> clocking code. I am getting confused as to whether it uses the common
> clocking framework. In
> https://github.com/torvalds/linux/blob/master/arch/arm/plat-samsung/incl
> ude/plat/clock.h#L42 they define a struct clk. Even in OMAP
> (http://processors.wiki.ti.com/index.php/Clock_Framework_User_Guide#Soft
> ware_Implementation) they have a separate struct clk definition. In the
> common clocking framework shouldn't they be using the common struct clk
> rather than have their own versions of struct clk?

The examples you pointed are not using Common Clock Framework. See 
Documentation/clk.txt and drivers/clk/ for more information about CCF.

As for s3c24xx, CCF driver for the whole platform is already merged for 
Linux 3.11.

Best regards,
Tomasz



From swarren at wwwdotorg.org  Wed Jul  3 14:12:54 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed,  3 Jul 2013 12:12:54 -0600
Subject: [PATCH V2] ARM: add missing __FINIT to head-common.S to match __INIT
Message-ID: <1372875174-26812-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Macro __INIT is used to place various code in head-common.S into the init
section. This should be matched by a closing __FINIT at the end of the
code destined for the init section. Add this missing macro.

This historically caused no problem, because macro __CPUINIT was used at
the exact location where __FINIT was missing, which then placed following
code into the cpuinit section. However, with commit 22f0a2736 "init.h:
remove __cpuinit sections from the kernel" applied, __CPUINIT becomes a
no-op, thus leaving all this code in the init section, rather than the
regular text section. This caused issues such as secondary CPU boot
failures or crashes.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
Acked-by: Paul Gortmaker <paul.gortmaker at windriver.com>
---
v2: Moved __FINIT after lookup_processor_type, to correctly match the
location of __CPUINIT.

Russell, I assume I should add this to the ARM patch tracker.

This version is based on v3.10.
---
 arch/arm/kernel/head-common.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
index 5b391a6..1fb887d 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -133,6 +133,8 @@ ENTRY(lookup_processor_type)
 	ldmfd	sp!, {r4 - r6, r9, pc}
 ENDPROC(lookup_processor_type)
 
+	__FINIT
+
 /*
  * Read processor ID register (CP#15, CR0), and look up in the linker-built
  * supported processor list.  Note that we can't use the absolute addresses
-- 
1.8.1.5



From olof at lixom.net  Wed Jul  3 14:27:12 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 3 Jul 2013 11:27:12 -0700
Subject: amba-pl08x and 'get_signal' namespace collision/build error
In-Reply-To: <20130627094650.GC4283@n2100.arm.linux.org.uk>
References: <51C97F40.5030101@arm.com>
 <20130625184539.GB2718@n2100.arm.linux.org.uk>
 <20130626044842.GR23141@intel.com>
 <20130626081909.GD2718@n2100.arm.linux.org.uk>
 <20130626103930.GS23141@intel.com>
 <20130627094650.GC4283@n2100.arm.linux.org.uk>
Message-ID: <CAOesGMgSPNggnBm=E3B774m7Ad_QMXdqvcGqRMxhap6dtpNtCg@mail.gmail.com>

Hi,


On Thu, Jun 27, 2013 at 2:46 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Wed, Jun 26, 2013 at 04:09:30PM +0530, Vinod Koul wrote:
>> On Wed, Jun 26, 2013 at 09:19:09AM +0100, Russell King - ARM Linux wrote:
>> > On Wed, Jun 26, 2013 at 10:18:42AM +0530, Vinod Koul wrote:
>> > > Yup. This is fixed in slave-dma tree by a patch from mark by renaming it.
>> > >
>> > > This should not show in the -next tree
>> >
>> > Except, that change probably is probably responsible for this new error:
>> >
>> > drivers/dma/amba-pl08x.c: In function 'pl08x_request_mux':
>> > drivers/dma/amba-pl08x.c:304:13: error: expected identifier before '(' token
>> This was pushed four days ago and havent seen any error report expect this.
>>
>> Anyway I rebuild my -next and looks fine for me
>>
>>   CC      drivers/dma/dmaengine.o
>>   CC      drivers/dma/virt-dma.o
>>   CC      drivers/dma/iovlock.o
>>   CC [M]  drivers/dma/dmatest.o
>>   CC      drivers/dma/amba-pl08x.o
>>   LD      drivers/dma/built-in.o
>>
>> Can you share your config which failed for you?
>>
>> Mark, I believe you are testing for this, have you seen above error?
>
> Right, what's going on is that I have a commit in my tree which adds an
> include to asm/pgtable.h which introduces a #define for get_signal.
> This becomes visible to amba-pl08x.c.
>
> However, my build test tree fails *every* time because what I'm building
> is Linus' tree, my tree plus arm-soc, and it doesn't include your tree.
> This makes my build testing for the next merge window impossible.
>
> So, I need the fix to pl08x.c merged into my tree.

This has now hit the mainline kernel, and several defconfigs (nhk815,
lpc32xx and the spear ones) are broken there.

Vinod, when are you sending up your pull request with the fix? It'd be
good to see it go in soon.


-Olof


From khilman at linaro.org  Wed Jul  3 14:36:38 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed,  3 Jul 2013 11:36:38 -0700
Subject: [PATCH 0/3] nohz/full: final Kconfig bits for ARM support
Message-ID: <1372876601-23881-1-git-send-email-khilman@linaro.org>

As of v3.10, the core ARM support is in mainline for NO_HZ_FULL.  The
only remaining part is the removal of the hard-coded Kconfig
requirement on 64-bit platforms, which I believe can now be removed
after the nsec granularity cputime was made to work on non 64_BIT
(c.f. commit 8c23b80e, cputime_nsecs: use math64.h for nsec
resolution conversion helpers.)

This series makes the final Kconfig changes to bring NO_HZ_FULL
support to ARM.

Series applies to v3.10.

I will queue up the arch/arm patch for Russell separately once the
generic changes are accepted.

Kevin

 arch/arm/Kconfig    | 1 +
 init/Kconfig        | 2 +-
 kernel/time/Kconfig | 2 --
 3 files changed, 2 insertions(+), 3 deletions(-)

-- 
1.8.3



From khilman at linaro.org  Wed Jul  3 14:36:39 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed,  3 Jul 2013 11:36:39 -0700
Subject: [PATCH 1/3] nohz: Kconfig: remove redundant 64-bit dependency
In-Reply-To: <1372876601-23881-1-git-send-email-khilman@linaro.org>
References: <1372876601-23881-1-git-send-email-khilman@linaro.org>
Message-ID: <1372876601-23881-2-git-send-email-khilman@linaro.org>

The current 64-bit dependency is on VIRT_CPU_ACCOUNTING_GEN, which already
has its own dependency on 64-bit.  Remove it from NO_HZ_FULL.

Cc: Frederic Weisbecker <fweisbec at gmail.com>
Signed-off-by: Kevin Hilman <khilman at linaro.org>
---
 kernel/time/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
index 70f27e8..b78760f 100644
--- a/kernel/time/Kconfig
+++ b/kernel/time/Kconfig
@@ -99,8 +99,6 @@ config NO_HZ_FULL
 	depends on SMP
 	# RCU_USER_QS dependency
 	depends on HAVE_CONTEXT_TRACKING
-	# VIRT_CPU_ACCOUNTING_GEN dependency
-	depends on 64BIT
 	select NO_HZ_COMMON
 	select RCU_USER_QS
 	select RCU_NOCB_CPU
-- 
1.8.3



From khilman at linaro.org  Wed Jul  3 14:36:40 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed,  3 Jul 2013 11:36:40 -0700
Subject: [PATCH 2/3] init/Kconfig: VIRT_CPU_ACCOUNTING_GEN: drop 64-bit
 requirement
In-Reply-To: <1372876601-23881-1-git-send-email-khilman@linaro.org>
References: <1372876601-23881-1-git-send-email-khilman@linaro.org>
Message-ID: <1372876601-23881-3-git-send-email-khilman@linaro.org>

The 64-bit requirement can be removed after the conversion of the nsec
granularity cputime to work on !64_BIT, which was done in commit
8c23b80e (cputime_nsecs: use math64.h for nsec resolution conversion
helpers)

Cc: Frederic Weisbecker <fweisbec at gmail.com>
Signed-off-by: Kevin Hilman <khilman at linaro.org>
---
 init/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/init/Kconfig b/init/Kconfig
index 2d9b831..e151022 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -325,7 +325,7 @@ config VIRT_CPU_ACCOUNTING_NATIVE
 
 config VIRT_CPU_ACCOUNTING_GEN
 	bool "Full dynticks CPU time accounting"
-	depends on HAVE_CONTEXT_TRACKING && 64BIT
+	depends on HAVE_CONTEXT_TRACKING
 	select VIRT_CPU_ACCOUNTING
 	select CONTEXT_TRACKING
 	help
-- 
1.8.3



From khilman at linaro.org  Wed Jul  3 14:36:41 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed,  3 Jul 2013 11:36:41 -0700
Subject: [PATCH 3/3] ARM: Kconfig: allow virt CPU accounting
In-Reply-To: <1372876601-23881-1-git-send-email-khilman@linaro.org>
References: <1372876601-23881-1-git-send-email-khilman@linaro.org>
Message-ID: <1372876601-23881-4-git-send-email-khilman@linaro.org>

With the 64-bit requirement removed from virt CPU accounting,
allow ARM platforms to enable it.

Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Signed-off-by: Kevin Hilman <khilman at linaro.org>
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 136f263..7850612 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -61,6 +61,7 @@ config ARM
 	select OLD_SIGSUSPEND3
 	select OLD_SIGACTION
 	select HAVE_CONTEXT_TRACKING
+	select HAVE_VIRT_CPU_ACCOUNTING
 	help
 	  The ARM series is a line of low-power-consumption RISC chip designs
 	  licensed by ARM Ltd and targeted at embedded applications and
-- 
1.8.3



From w at 1wt.eu  Wed Jul  3 15:07:53 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Wed, 3 Jul 2013 21:07:53 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130703094203.37562f9c@skate>
References: <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net> <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net> <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net> <87y59ows4n.fsf@natisbad.org>
 <20130702220936.GC10215@1wt.eu> <20130702232311.GA3949@localhost>
 <20130703094203.37562f9c@skate>
Message-ID: <20130703190753.GB16785@1wt.eu>

Hi Thomas,

On Wed, Jul 03, 2013 at 09:42:03AM +0200, Thomas Petazzoni wrote:
> Wasn't also part of the TODO-list to make pxa3xx_nand divorce from the
> PXA-specific DMA API, and use instead the PXA dmaengine driver, through
> the DMA engine API? As far as I remember, this was one of the
> prerequisite to be able to re-use the driver in a non-PXA context.
> There is a patch that was floating around doing this conversion (I
> could dig the relevant link if needed), but of course it needs to be
> tested, and we don't have PXA3xx hardware, so making changes to this
> driver without breaking it is quite tedious.

Thus I think it would make more sense to split the driver (at least at
the beginning) in order not to risk breaking anything. If the driver is
copy-pasted from pxa3xx, the merge will still be doable later when
someone can test it.

Just my two cents, cause I hate breaking working stuff.

Best regards,
Willy



From jason at lakedaemon.net  Wed Jul  3 15:10:24 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 3 Jul 2013 15:10:24 -0400
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130703190753.GB16785@1wt.eu>
References: <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
 <20130702232311.GA3949@localhost> <20130703094203.37562f9c@skate>
 <20130703190753.GB16785@1wt.eu>
Message-ID: <20130703191024.GC27003@titan.lakedaemon.net>

On Wed, Jul 03, 2013 at 09:07:53PM +0200, Willy Tarreau wrote:
> Just my two cents, cause I hate breaking working stuff.

If you don't break stuff, how else do you find out how many users you
have? :-P

thx,

Jason.


From w at 1wt.eu  Wed Jul  3 15:38:01 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Wed, 3 Jul 2013 21:38:01 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130703191024.GC27003@titan.lakedaemon.net>
References: <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net> <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net> <87y59ows4n.fsf@natisbad.org>
 <20130702220936.GC10215@1wt.eu> <20130702232311.GA3949@localhost>
 <20130703094203.37562f9c@skate> <20130703190753.GB16785@1wt.eu>
 <20130703191024.GC27003@titan.lakedaemon.net>
Message-ID: <20130703193801.GG16785@1wt.eu>

On Wed, Jul 03, 2013 at 03:10:24PM -0400, Jason Cooper wrote:
> On Wed, Jul 03, 2013 at 09:07:53PM +0200, Willy Tarreau wrote:
> > Just my two cents, cause I hate breaking working stuff.
> 
> If you don't break stuff, how else do you find out how many users you
> have? :-P

Yeah good point indeed :-)
I continue to discover 2.4 users exactly for this reason !

Willy



From jason at lakedaemon.net  Wed Jul  3 15:39:56 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 3 Jul 2013 15:39:56 -0400
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130703193801.GG16785@1wt.eu>
References: <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
 <20130702232311.GA3949@localhost> <20130703094203.37562f9c@skate>
 <20130703190753.GB16785@1wt.eu>
 <20130703191024.GC27003@titan.lakedaemon.net>
 <20130703193801.GG16785@1wt.eu>
Message-ID: <20130703193956.GD27003@titan.lakedaemon.net>

On Wed, Jul 03, 2013 at 09:38:01PM +0200, Willy Tarreau wrote:
> On Wed, Jul 03, 2013 at 03:10:24PM -0400, Jason Cooper wrote:
> > On Wed, Jul 03, 2013 at 09:07:53PM +0200, Willy Tarreau wrote:
> > > Just my two cents, cause I hate breaking working stuff.
> > 
> > If you don't break stuff, how else do you find out how many users you
> > have? :-P
> 
> Yeah good point indeed :-)
> I continue to discover 2.4 users exactly for this reason !

hehe, I first read that as a little less than 2 1/2 users... ;-)

thx,

Jason.


From broonie at kernel.org  Wed Jul  3 15:43:03 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 3 Jul 2013 20:43:03 +0100
Subject: [RFC PATCH v4 2/2] drivers: mfd: vexpress: add Serial Power
 Controller (SPC) support
In-Reply-To: <20130618102213.GA1564@e102568-lin.cambridge.arm.com>
References: <1371484269-11743-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1371484269-11743-3-git-send-email-lorenzo.pieralisi@arm.com>
 <20130617174451.GF28497@quad.lixom.net>
 <20130618102213.GA1564@e102568-lin.cambridge.arm.com>
Message-ID: <20130703194303.GG27646@sirena.org.uk>

On Tue, Jun 18, 2013 at 11:22:13AM +0100, Lorenzo Pieralisi wrote:
> On Mon, Jun 17, 2013 at 06:44:51PM +0100, Olof Johansson wrote:

> > That'll trim down the driver to a point where I think you'll find it much
> > easier to get merged. :-)

> To start with I have to understand in which directory this code should
> live. Moving the frequency settings in clk/CPUfreq drivers should be
> feasible with extra DT complexity for their bindings.

You shoudn't really need to change the DT bindings at all - MFD is a
purely Linux construct, it doesn't affect how the hardware is
constructed.
-------------- 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/20130703/267f48d3/attachment.sig>

From paul at pwsan.com  Wed Jul  3 15:51:09 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 3 Jul 2013 19:51:09 +0000 (UTC)
Subject: OMAP baseline test results for v3.10-rc6
In-Reply-To: <51D2E096.5040700@ti.com>
References: <alpine.DEB.2.02.1306170521020.9909@utopia.booyaka.com>
 <20130625160243.GE22312@arwen.pp.htv.fi>
 <alpine.DEB.2.02.1306251746060.14373@utopia.booyaka.com>
 <51C9F0A8.1050607@ti.com> <87fvw6t136.fsf@linaro.org>
 <79CD15C6BA57404B839C016229A409A83ECC952D@DBDE04.ent.ti.com>
 <51CAEB33.5010101@ti.com>
 <alpine.DEB.2.02.1306261722520.6135@utopia.booyaka.com>
 <51CBBCD8.5030600@ti.com>
 <alpine.DEB.2.02.1306281844090.8767@utopia.booyaka.com>
 <alpine.DEB.2.02.1307010211580.3741@utopia.booyaka.com>
 <79CD15C6BA57404B839C016229A409A83ECCC435@DBDE04.ent.ti.com>
 <51D2E096.5040700@ti.com>
Message-ID: <alpine.DEB.2.02.1307031944580.9618@utopia.booyaka.com>

On Tue, 2 Jul 2013, Nishanth Menon wrote:

> On 07/01/2013 11:29 PM, Hiremath, Vaibhav wrote:
> > 
> > > -----Original Message-----
> > > From: Paul Walmsley [mailto:paul at pwsan.com]
> > > Sent: Monday, July 01, 2013 7:46 AM
> > > To: Vutla, Lokesh
> > > Cc: Nayak, Rajendra; Hiremath, Vaibhav; Kevin Hilman; Rini, Tom; linux-
> > > omap at vger.kernel.org; Balbi, Felipe; linux-arm-
> > > kernel at lists.infradead.org
> > > Subject: Re: OMAP baseline test results for v3.10-rc6
> > > 
> > > On Fri, 28 Jun 2013, Paul Walmsley wrote:
> > > 
> > > > On Thu, 27 Jun 2013, Lokesh Vutla wrote:
> > > > 
> > > > > Here is the catch..
> > > > > Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb
> > > was
> > > > > generated in arch/arm/boot).
> > > > 
> > > > Ugh... that's probably it :-(
> to prevent this from happening again, Lokesh did post a patch:
> https://patchwork.kernel.org/patch/2796921/
> 
> Will be good to ack it if we think it might prevent such scenarios in the
> future.

Thanks for the suggestion.  

Unfortunately it wouldn't have caught the problem, since, as I mentioned 
in the E-mail you quoted, I build from a fresh tree each time.  So there 
was no previous DTB.  This wasn't caught here because 'cat' was copying 
over the kernel to its standard output, even though it was returning an 
error, and I wasn't checking the 'cat' return value.  This is obviously 
being remedied here.

Also will modify the build scripts to output each command as it's being 
run.

As far as Lokesh's patch goes: it doesn't make sense to me to remove a 
file during 'make clean' that the build process doesn't create.  So while 
I understand the motivation for the patch, and don't mind if upstream 
takes it, I personally wouldn't care to ack it.


- Paul


From jason at lakedaemon.net  Wed Jul  3 16:21:05 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 3 Jul 2013 16:21:05 -0400
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130702220936.GC10215@1wt.eu>
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net>
 <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
Message-ID: <20130703202105.GE27003@titan.lakedaemon.net>

On Wed, Jul 03, 2013 at 12:09:36AM +0200, Willy Tarreau wrote:
> Hi,
> 
> On Tue, Jul 02, 2013 at 11:48:08PM +0200, Arnaud Ebalard wrote:
> > > more bummer.  Willy, mind posting what you have?
> 
> Attached. Usual warning "this will destroy your device etc..." comes
> with it.

Thanks Willy!

How much effort would it be to put this pig in drivers/staging?  iirc,
the only rule is that it has to compile...

thx,

Jason.


From javier.picorel at epfl.ch  Wed Jul  3 16:32:55 2013
From: javier.picorel at epfl.ch (javier.picorel at epfl.ch)
Date: Wed, 03 Jul 2013 22:32:55 +0200
Subject: ARM Cortex A9: LL counters
Message-ID: <20130703223255.15536gmsbwonw5fb@webmail.epfl.ch>

Dear all,

It seems that there is no mapping between any ARM Cortex A9 counter to  
the L2 (Last Level) access or misses event.

arch/arm/kernel/perf_event_v7.c

  [C(LL)] = {
  293                [C(OP_READ)] = {
  294                        [C(RESULT_ACCESS)]      = CACHE_OP_UNSUPPORTED,
  295                        [C(RESULT_MISS)]        = CACHE_OP_UNSUPPORTED,
  296                },
  297                [C(OP_WRITE)] = {
  298                        [C(RESULT_ACCESS)]      = CACHE_OP_UNSUPPORTED,
  299                        [C(RESULT_MISS)]        = CACHE_OP_UNSUPPORTED,
  300                },
  301                [C(OP_PREFETCH)] = {
  302                        [C(RESULT_ACCESS)]      = CACHE_OP_UNSUPPORTED,
  303                        [C(RESULT_MISS)]        = CACHE_OP_UNSUPPORTED,
  304                },
  305        },

Looking at ARM's reference manual and OProfile's event list on A9, I  
see the following two counters:

CO_LF_MISS: (counter: 1, 2, 3, 4, 5, 6)
         Number of coherent linefill requests which miss in all other  
CPUs, meaning that the request
         is sent to external memory (min count: 500)
CO_LF_HIT: (counter: 1, 2, 3, 4, 5, 6)
         Number of coherent linefill requests which hit in another  
CPU, meaning that the linefill
         data is fetched directly from the relevant cache (min count: 500)

It seems that the first counter refers to the L2 Misses and the second  
one to the L2 Hits (Last Level Cache in this architecture). I'm not sure
whether we should do something about this or nor. Thanks!

Best Regards,
Javier


From w at 1wt.eu  Wed Jul  3 16:35:41 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Wed, 3 Jul 2013 22:35:41 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130703202105.GE27003@titan.lakedaemon.net>
References: <20130702124639.GI19937@titan.lakedaemon.net>
 <20130702151407.01680d21@skate> <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate> <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org> <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
 <20130703202105.GE27003@titan.lakedaemon.net>
Message-ID: <20130703203541.GI16785@1wt.eu>

On Wed, Jul 03, 2013 at 04:21:05PM -0400, Jason Cooper wrote:
> On Wed, Jul 03, 2013 at 12:09:36AM +0200, Willy Tarreau wrote:
> > Hi,
> > 
> > On Tue, Jul 02, 2013 at 11:48:08PM +0200, Arnaud Ebalard wrote:
> > > > more bummer.  Willy, mind posting what you have?
> > 
> > Attached. Usual warning "this will destroy your device etc..." comes
> > with it.
> 
> Thanks Willy!
> 
> How much effort would it be to put this pig in drivers/staging?  iirc,
> the only rule is that it has to compile...

I think we should at least get it to work again. Otherwise it's pointless
to pollute the kernel. No way to get any tester if all you get when you
load it is :

  calling drivers/mtd/nand/armada_nand.c:3227 orion_nfc_probe
  armada-nand nand.3: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC
  drivers/mtd/nand/armada_nand.c:3318:orion_nfc_probe irq=105
  armada-nand: probe of nand.3 failed with error -12

Oh damn, I'm back in the code again trying to fix it now...

Also we must not put it into staging in its current shape as it
patches drivers/mtd. We must first apply Ezequiel's explanation
about the READID command to detect the ONFI flash. I don't know
how long this could take. I remember having noticed this difference
in later drivers that was not there without knowing what it was
about.

What makes me uncomfortable is that we have guys who have started
some clean work and in parallel we're doing some crap which will
discourage Marvell from reprioritizing their work. I'd rather keep
that as an out of tree patch so that nobody there claims that the
NAND driver already exists in the kernel.

Best regards,
Willy



From jason at lakedaemon.net  Wed Jul  3 16:44:51 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 3 Jul 2013 16:44:51 -0400
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130703203541.GI16785@1wt.eu>
References: <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
 <20130703202105.GE27003@titan.lakedaemon.net>
 <20130703203541.GI16785@1wt.eu>
Message-ID: <20130703204451.GF27003@titan.lakedaemon.net>

On Wed, Jul 03, 2013 at 10:35:41PM +0200, Willy Tarreau wrote:
> On Wed, Jul 03, 2013 at 04:21:05PM -0400, Jason Cooper wrote:
> > On Wed, Jul 03, 2013 at 12:09:36AM +0200, Willy Tarreau wrote:
> > > Hi,
> > > 
> > > On Tue, Jul 02, 2013 at 11:48:08PM +0200, Arnaud Ebalard wrote:
> > > > > more bummer.  Willy, mind posting what you have?
> > > 
> > > Attached. Usual warning "this will destroy your device etc..." comes
> > > with it.
> > 
> > Thanks Willy!
> > 
> > How much effort would it be to put this pig in drivers/staging?  iirc,
> > the only rule is that it has to compile...
> 
> I think we should at least get it to work again. Otherwise it's pointless
> to pollute the kernel. No way to get any tester if all you get when you
> load it is :
> 
>   calling drivers/mtd/nand/armada_nand.c:3227 orion_nfc_probe
>   armada-nand nand.3: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC
>   drivers/mtd/nand/armada_nand.c:3318:orion_nfc_probe irq=105
>   armada-nand: probe of nand.3 failed with error -12
> 
> Oh damn, I'm back in the code again trying to fix it now...

:-)

> Also we must not put it into staging in its current shape as it
> patches drivers/mtd.

Understood.  That's why I was asking.

> We must first apply Ezequiel's explanation
> about the READID command to detect the ONFI flash. I don't know
> how long this could take. I remember having noticed this difference
> in later drivers that was not there without knowing what it was
> about.

Ok.

> What makes me uncomfortable is that we have guys who have started
> some clean work and in parallel we're doing some crap which will
> discourage Marvell from reprioritizing their work. I'd rather keep
> that as an out of tree patch so that nobody there claims that the
> NAND driver already exists in the kernel.

Good point.  I was thinking the exact opposite :-P  "The in tree driver
is crap, we'd better re-prioritize our work before people default to the
crap driver"  However, I agree that your more cynical pov is probably
more correct.

I'd love to see the mirabox etc supported by mainline debian et al, but
it'll have to wait.

thx,

Jason.


From arno at natisbad.org  Wed Jul  3 17:05:57 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Wed, 03 Jul 2013 23:05:57 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130703203541.GI16785@1wt.eu> (Willy Tarreau's message of "Wed, 
 3 Jul 2013 22:35:41 +0200")
References: <20130702124639.GI19937@titan.lakedaemon.net>
 <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
 <20130703202105.GE27003@titan.lakedaemon.net>
 <20130703203541.GI16785@1wt.eu>
Message-ID: <87a9m3fj62.fsf@natisbad.org>


Willy Tarreau <w at 1wt.eu> writes:

> What makes me uncomfortable is that we have guys who have started
> some clean work and in parallel we're doing some crap which will
> discourage Marvell from reprioritizing their work.

*FWIW*, +1.


From w at 1wt.eu  Wed Jul  3 17:14:50 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Wed, 3 Jul 2013 23:14:50 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130703204451.GF27003@titan.lakedaemon.net>
References: <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate> <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org> <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
 <20130703202105.GE27003@titan.lakedaemon.net> <20130703203541.GI16785@1wt.eu>
 <20130703204451.GF27003@titan.lakedaemon.net>
Message-ID: <20130703211450.GJ16785@1wt.eu>

On Wed, Jul 03, 2013 at 04:44:51PM -0400, Jason Cooper wrote:
> > What makes me uncomfortable is that we have guys who have started
> > some clean work and in parallel we're doing some crap which will
> > discourage Marvell from reprioritizing their work. I'd rather keep
> > that as an out of tree patch so that nobody there claims that the
> > NAND driver already exists in the kernel.
> 
> Good point.  I was thinking the exact opposite :-P  "The in tree driver
> is crap, we'd better re-prioritize our work before people default to the
> crap driver"

Do you really think that people who provide bogus kernel patches to
vendors who sell hardware with unmaintained outdated kernels and many
bugs have anything to care about the quality of the in-kernel driver ?

I'm afraid they simply don't care a dime. I bricked my mirabox a few
days after using it, I hoped to find some JTAG info to write an openocd
driver and found nothing. I asked to apply for an NDA to get access to
this precious data (Most likely the hardware is still in beta and they
don't want the remaining flaws to be unveiled). I did this exactly one
year ago and nothing moved after maybe 20 repeated attempts, nothing
moved. Finally I managed to unbrick it by reversing the boot loader
code and their image generator.

The reality is that they absolutely don't care about their hardware
being supported by mainline since they already have enough customers
who buy their crippled LSP kernel.

> However, I agree that your more cynical pov is probably more correct.
> 
> I'd love to see the mirabox etc supported by mainline debian et al, but
> it'll have to wait.

I would love it too. The platform is good. The mirabox is small and
powerful. The AX3 is absolutely marvelous (no pun intended). I would
love that they once for all understand that they just need to let
developers do the work they barely drafted with their crappy LSP and
become one of the best linux platforms for many SOHO usages. Their
marketing would be better done by their end users and community...
But at the moment, all the makers of these devices have to live with
the idea that their devices are limited by bogus and unstable code
and that their sales suffer from this. Pfff....

OK fixed the driver. The problem was the hard-coded internal register
address which was 0xfeb00000 in previous versions and is 0xfec00000
now.

Now I'm getting this upon modprobe :

calling drivers/mtd/nand/armada_nand.c:3227 orion_nfc_probe
armada-nand d00d0000.nand: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC
drivers/mtd/nand/armada_nand.c:3318:orion_nfc_probe irq=105
drivers/mtd/nand/armada_nand.c:3324:orion_nfc_probe irq=105
drivers/mtd/nand/armada_nand.c:3332:orion_nfc_probe mmio_base=fecd0000
drivers/mtd/nand/armada_nand.c:3338:orion_nfc_probe base=fecd0000
drivers/mtd/nand/armada_nand.c:1531:setNANDClock nVal=0428040a
drivers/mtd/nand/armada_nand.c:1539:setNANDClock nVal=0428080a
drivers/mtd/nand/armada_nand.c:1544:setNANDClock nVal=ff000002
drivers/mtd/nand/armada_nand.c:1552:setNANDClock nVal=ff000002
drivers/mtd/nand/armada_nand.c:1531:setNANDClock nVal=0428080a
drivers/mtd/nand/armada_nand.c:1539:setNANDClock nVal=0428050a
drivers/mtd/nand/armada_nand.c:1544:setNANDClock nVal=ff000002
drivers/mtd/nand/armada_nand.c:1552:setNANDClock nVal=ff000002
NAND device: Manufacturer ID: 0x2c, Chip ID: 0x38 (Micron NAND 1GiB 1,8V 8-bit), 1024MiB, page size: 4096, OOB size: 128
Bad block table found at page 262016, version 0x01
Bad block table found at page 261888, version 0x01
6 cmdlinepart partitions found on MTD device armada-nand
Creating 6 MTD partitions on "armada-nand":
0x000000000000-0x000000400000 : "uboot"
0x000000400000-0x000000800000 : "config"
0x000000800000-0x000001000000 : "kernel"
0x000001000000-0x000002000000 : "initrd"
0x000002000000-0x000020000000 : "rootfs"
0x000020000000-0x000040000000 : "pad"
root at mirabox:~# 

I'll tidy up a little bit this ugly thing and resend something to use
as a basis to work on.

Best regards,
Willy



From soren.brinkmann at xilinx.com  Wed Jul  3 17:50:16 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Wed,  3 Jul 2013 14:50:16 -0700
Subject: [PATCH] clocksource/cadence_ttc: Reuse clocksource as sched_clock
Message-ID: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>

Reuse the TTC clocksource timer as sched clock, too. Since only a single
sched clock is supported in Linux, this feature optional and can be
selected through Kconfig.

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
---
 drivers/clocksource/Kconfig             |  7 +++++++
 drivers/clocksource/cadence_ttc_timer.c | 18 ++++++++++++++++++
 2 files changed, 25 insertions(+)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 5871933..8dda767 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -36,6 +36,13 @@ config VT8500_TIMER
 config CADENCE_TTC_TIMER
 	bool
 
+config CADENCE_TTC_TIMER_SCHED_CLOCK
+	bool "Cadence TTC Sched Clock"
+	depends on CADENCE_TTC_TIMER
+	help
+	  Use the clocksource timer provided by the TTC as
+	  sched clock, also.
+
 config CLKSRC_NOMADIK_MTU
 	bool
 	depends on (ARCH_NOMADIK || ARCH_U8500)
diff --git a/drivers/clocksource/cadence_ttc_timer.c b/drivers/clocksource/cadence_ttc_timer.c
index 4cbe28c..ef0f52b 100644
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@ -22,6 +22,7 @@
 #include <linux/of_irq.h>
 #include <linux/slab.h>
 #include <linux/clk-provider.h>
+#include <asm/sched_clock.h>
 
 /*
  * This driver configures the 2 16-bit count-up timers as follows:
@@ -95,6 +96,10 @@ struct ttc_timer_clockevent {
 #define to_ttc_timer_clkevent(x) \
 		container_of(x, struct ttc_timer_clockevent, ce)
 
+#ifdef CONFIG_CADENCE_TTC_TIMER_SCHED_CLOCK
+static void __iomem *ttc_sched_clock_val_reg;
+#endif
+
 /**
  * ttc_set_interval - Set the timer interval value
  *
@@ -156,6 +161,13 @@ static cycle_t __ttc_clocksource_read(struct clocksource *cs)
 				TTC_COUNT_VAL_OFFSET);
 }
 
+#ifdef CONFIG_CADENCE_TTC_TIMER_SCHED_CLOCK
+static u32 notrace ttc_sched_clock_read(void)
+{
+	return __raw_readl(ttc_sched_clock_val_reg);
+}
+#endif
+
 /**
  * ttc_set_next_event - Sets the time interval for next event
  *
@@ -297,6 +309,12 @@ static void __init ttc_setup_clocksource(struct clk *clk, void __iomem *base)
 		kfree(ttccs);
 		return;
 	}
+
+#ifdef CONFIG_CADENCE_TTC_TIMER_SCHED_CLOCK
+	ttc_sched_clock_val_reg = base + TTC_COUNT_VAL_OFFSET;
+	setup_sched_clock(ttc_sched_clock_read, 16,
+			clk_get_rate(ttccs->ttc.clk) / PRESCALE);
+#endif
 }
 
 static int ttc_rate_change_clockevent_cb(struct notifier_block *nb,
-- 
1.8.3.2



From w at 1wt.eu  Wed Jul  3 18:23:15 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 4 Jul 2013 00:23:15 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130703211450.GJ16785@1wt.eu>
References: <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net> <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net> <87y59ows4n.fsf@natisbad.org>
 <20130702220936.GC10215@1wt.eu> <20130703202105.GE27003@titan.lakedaemon.net>
 <20130703203541.GI16785@1wt.eu> <20130703204451.GF27003@titan.lakedaemon.net>
 <20130703211450.GJ16785@1wt.eu>
Message-ID: <20130703222315.GK16785@1wt.eu>

On Wed, Jul 03, 2013 at 11:14:50PM +0200, Willy Tarreau wrote:
> OK fixed the driver. The problem was the hard-coded internal register
> address which was 0xfeb00000 in previous versions and is 0xfec00000
> now.
> 
> Now I'm getting this upon modprobe :
> 
> calling drivers/mtd/nand/armada_nand.c:3227 orion_nfc_probe
> armada-nand d00d0000.nand: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC
> drivers/mtd/nand/armada_nand.c:3318:orion_nfc_probe irq=105
> drivers/mtd/nand/armada_nand.c:3324:orion_nfc_probe irq=105
> drivers/mtd/nand/armada_nand.c:3332:orion_nfc_probe mmio_base=fecd0000
> drivers/mtd/nand/armada_nand.c:3338:orion_nfc_probe base=fecd0000
> drivers/mtd/nand/armada_nand.c:1531:setNANDClock nVal=0428040a
> drivers/mtd/nand/armada_nand.c:1539:setNANDClock nVal=0428080a
> drivers/mtd/nand/armada_nand.c:1544:setNANDClock nVal=ff000002
> drivers/mtd/nand/armada_nand.c:1552:setNANDClock nVal=ff000002
> drivers/mtd/nand/armada_nand.c:1531:setNANDClock nVal=0428080a
> drivers/mtd/nand/armada_nand.c:1539:setNANDClock nVal=0428050a
> drivers/mtd/nand/armada_nand.c:1544:setNANDClock nVal=ff000002
> drivers/mtd/nand/armada_nand.c:1552:setNANDClock nVal=ff000002
> NAND device: Manufacturer ID: 0x2c, Chip ID: 0x38 (Micron NAND 1GiB 1,8V 8-bit), 1024MiB, page size: 4096, OOB size: 128
> Bad block table found at page 262016, version 0x01
> Bad block table found at page 261888, version 0x01
> 6 cmdlinepart partitions found on MTD device armada-nand
> Creating 6 MTD partitions on "armada-nand":
> 0x000000000000-0x000000400000 : "uboot"
> 0x000000400000-0x000000800000 : "config"
> 0x000000800000-0x000001000000 : "kernel"
> 0x000001000000-0x000002000000 : "initrd"
> 0x000002000000-0x000020000000 : "rootfs"
> 0x000020000000-0x000040000000 : "pad"
> root at mirabox:~# 
> 
> I'll tidy up a little bit this ugly thing and resend something to use
> as a basis to work on.

The patch it too large (150kB), last time I received a warning from the ML
because of its size. So I'm putting it here instead :

   http://linux.1wt.eu/kernel/armada-nand/3.10-armada_nand.patch

I've tested it on both my mirabox and the xp-gp board, the same flash is
detected (Micron 1GB) and works on both boards. (BTW, Florian if you read
this, your board has already served its intended purpose :-)).

Among the important things to do that immediately come to mind :

  - implement the READID command as explained by Ezequiel to stop
    patching nand_ids.h

  - remove the hard-coded dependency on INTERNAL_REGS_BASE and
    replace all calls to MV_REG_* with their cleaner equivalents
    found in mvneta.c. This will require passing the nfcCtrl
    pointer all along to have the mmio_base pointer I guess.

  - check if include/linux/mtd/nand.h really needs to be patched
    or if the information put there can be moved somewhere else.

And probably try to help Ezequiel finish the work he began by using
this work as documentation rather than the other way around.

Feel free to host this driver anywhere if you like, I don't have the
time to maintain it, and I don't want to see it merged into the kernel,
we have enough crap and this one certainly qualifies as such.

Oh last important point, I found it in the 2.6.35.9-LSP-1.0.2_gw patch.
If someone finds a more recent one in a more recent kernel, it might be
worth comparing them.

Best regards,
Willy



From ezequiel.garcia at free-electrons.com  Wed Jul  3 18:33:24 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Wed, 3 Jul 2013 19:33:24 -0300
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130703043330.GF10215@1wt.eu>
References: <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
 <20130702232311.GA3949@localhost> <20130703043330.GF10215@1wt.eu>
Message-ID: <20130703223323.GA21722@localhost>

Hi everyone,

On Wed, Jul 03, 2013 at 06:33:30AM +0200, Willy Tarreau wrote:
> 
> On Tue, Jul 02, 2013 at 08:23:12PM -0300, Ezequiel Garcia wrote:
> > > Yes and indeed I must say that when I read the driver I found some
> > > similarities with pxa3xx, though it was done differently. I initially
> > > wanted to try to merge them but of course without the spec it's a huge
> > > waste of time, especially considering that this is still in the roadmap
> > > of the Free Electrons guys even though low priority.
> > 
> > I wish I could say I'm going to work on this soon but, as Thomas said,
> > we have no idea when/if NAND will be prioritized.
> > 
> > On the other side if you look at the driver Willy just posted, merging
> > the juicy stuff into pxa3xx-nand driver is not for the faint of heart.
> > 
> > Without the spec, is only tougher.
> 
> Confirmed :-)
> 

Just a note on the (lack of) documentation issue.

If there's a brave soul reading this and longing to tackle this,
the pxa3xx SoC documentation *is* publicly available:

http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Developers_Manual.zip

The NAND specifications can be found in the "[...] Vol. II: Memory Controller" document,
inside the above zip file. IMHO, that's the reading entry point in order to
understand pxa3xx-nand driver better.

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From w at 1wt.eu  Wed Jul  3 18:38:58 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 4 Jul 2013 00:38:58 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130703223323.GA21722@localhost>
References: <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate> <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org> <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
 <20130702232311.GA3949@localhost> <20130703043330.GF10215@1wt.eu>
 <20130703223323.GA21722@localhost>
Message-ID: <20130703223858.GL16785@1wt.eu>

Hi Ezequiel,

On Wed, Jul 03, 2013 at 07:33:24PM -0300, Ezequiel Garcia wrote:
> Hi everyone,
> 
> On Wed, Jul 03, 2013 at 06:33:30AM +0200, Willy Tarreau wrote:
> > 
> > On Tue, Jul 02, 2013 at 08:23:12PM -0300, Ezequiel Garcia wrote:
> > > > Yes and indeed I must say that when I read the driver I found some
> > > > similarities with pxa3xx, though it was done differently. I initially
> > > > wanted to try to merge them but of course without the spec it's a huge
> > > > waste of time, especially considering that this is still in the roadmap
> > > > of the Free Electrons guys even though low priority.
> > > 
> > > I wish I could say I'm going to work on this soon but, as Thomas said,
> > > we have no idea when/if NAND will be prioritized.
> > > 
> > > On the other side if you look at the driver Willy just posted, merging
> > > the juicy stuff into pxa3xx-nand driver is not for the faint of heart.
> > > 
> > > Without the spec, is only tougher.
> > 
> > Confirmed :-)
> > 
> 
> Just a note on the (lack of) documentation issue.
> 
> If there's a brave soul reading this and longing to tackle this,
> the pxa3xx SoC documentation *is* publicly available:
> 
> http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Developers_Manual.zip
>
> The NAND specifications can be found in the "[...] Vol. II: Memory Controller" document,
> inside the above zip file. IMHO, that's the reading entry point in order to
> understand pxa3xx-nand driver better.

Yes I have this one as well, but initially since I was not really sure
about the ressemblance of the two controllers, I did not spend too much
time on it. Now probably it can be useful, especially if we use your
existing work as a complement of information :-)

Best regards,
Willy



From arno at natisbad.org  Wed Jul  3 18:58:10 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Thu, 04 Jul 2013 00:58:10 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130703222315.GK16785@1wt.eu> (Willy Tarreau's message of "Thu, 
 4 Jul 2013 00:23:15 +0200")
References: <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
 <20130703202105.GE27003@titan.lakedaemon.net>
 <20130703203541.GI16785@1wt.eu>
 <20130703204451.GF27003@titan.lakedaemon.net>
 <20130703211450.GJ16785@1wt.eu> <20130703222315.GK16785@1wt.eu>
Message-ID: <8761wrp7y5.fsf@natisbad.org>

Hi Willy,

Willy Tarreau <w at 1wt.eu> writes:

> The patch it too large (150kB), last time I received a warning from the ML
> because of its size.
>
> [snip]
>
> Feel free to host this driver anywhere if you like, I don't have the
> time to maintain it, and I don't want to see it merged into the kernel,
> we have enough crap and this one certainly qualifies as such.

;-)

> Oh last important point, I found it in the 2.6.35.9-LSP-1.0.2_gw patch.
> If someone finds a more recent one in a more recent kernel, it might be
> worth comparing them.

The version in Netgear kernel (a 3.0.56, 25/Apr/2012 KW40 LSP release
3.1.0-NQ) is almost identical to the one in mirabox 2.6.35 kernel
(24/Nov/2011, KW40 LSP release 1.0.2-NQ) if you remove the fixes for
trailing spaces and tabs: 


@@ -1618,7 +1618,9 @@
 		ret = -ENXIO;
 		goto fail_free_irq;
 	}
-	if (mtd_has_partitions()) {
+
+
+#ifdef CONFIG_MTD_CMDLINE_PARTS
 		if (mtd_has_cmdlinepart()) {
 			static const char *probes[] = { "cmdlinepart", NULL };
 			struct mtd_partition *parts;
@@ -1627,12 +1629,11 @@
 			nr_parts = parse_mtd_partitions(mtd, probes, &parts, 0);
 
 			if (nr_parts)
-				return add_mtd_partitions(mtd, parts, nr_parts);
+				return mtd_device_register(mtd, parts, nr_parts);
 		}
-		return add_mtd_partitions(mtd, pdata->parts, pdata->nr_parts);
-	}
-
-	return add_mtd_device(mtd) == 1 ? -ENODEV : 0;
+		return mtd_device_register(mtd, pdata->parts, pdata->nr_parts);
+#endif
+		return (mtd_device_register(mtd, pdata->parts, pdata->nr_parts));
 
 fail_free_irq:
 	free_irq(IRQ_AURORA_NFC, info);
@@ -1661,10 +1662,6 @@
 
 	platform_set_drvdata(pdev, NULL);
 
-	del_mtd_device(mtd);
-#ifdef CONFIG_MTD_PARTITIONS
-	del_mtd_partitions(mtd);
-#endif
 	free_irq(IRQ_AURORA_NFC, info);
 	if (info->use_dma) {
 		dma_free_writecombine(&pdev->dev, info->data_buff_size,
@@ -1675,7 +1672,10 @@
 	clk_disable(info->clk);
 	clk_put(info->clk);
 #endif
-	kfree(mtd);
+	if (mtd) {
+		mtd_device_unregister(mtd);
+		kfree(mtd);
+	}
 	return 0;
 }
 


From festevam at gmail.com  Wed Jul  3 19:52:47 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 3 Jul 2013 20:52:47 -0300
Subject: mx6q boot on linux-next 20130703
Message-ID: <CAOMZO5DgAu2-cknESp4a675KP5gDrJxM2A_FqUgAZav83Db=fw@mail.gmail.com>

Hi,

I am running linux-next 20130703 on a mx6q board, and seeing a strange
behaviour.

Only if I enable DEBUG_LL + earlyprintk and disable
CONFIG_SERIAL_FSL_LPUART (serial driver for the FSL Vybrid SoC), I am
able to boot the kernel until the prompt.

Does anyone have any suggestion?

Regards,

Fabio Estevam


From laurent.pinchart at ideasonboard.com  Wed Jul  3 19:53:40 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 04 Jul 2013 01:53:40 +0200
Subject: [PATCH v2] ARM: shmobile: uImage load address rework
In-Reply-To: <CANqRtoTmhrdB+U_kTdwStXY2xrrGxjMWOEY7NWMgFGXDYQNVNQ@mail.gmail.com>
References: <20130610092857.19175.25629.sendpatchset@w520>
 <76205076.EsFJngGrIh@avalon>
 <CANqRtoTmhrdB+U_kTdwStXY2xrrGxjMWOEY7NWMgFGXDYQNVNQ@mail.gmail.com>
Message-ID: <13462253.7rIkoX3g1h@avalon>

Hi Magnus,

On Tuesday 25 June 2013 23:00:49 Magnus Damm wrote:
> On Wed, Jun 19, 2013 at 10:16 PM, Laurent Pinchart wrote:
> > On Wednesday 12 June 2013 04:31:26 Laurent Pinchart wrote:
> >> On Wednesday 12 June 2013 11:21:34 Magnus Damm wrote:
> >> > On Wed, Jun 12, 2013 at 6:50 AM, Laurent Pinchart wrote:
> >> > > I've noticed today that KZM9G doesn't boot v3.10-rc2 with
> >> > > CONFIG_AUTO_ZRELADDR=y. While not caused by this patch, that's
> >> > > something that will need to be fixed to support multi-arch kernels.
> >> > > I'm not too familiar with early boot code, would you be able to have
> >> > > a look at this ?
> >> > 
> >> > I will have a look. I suspect that issue is not related to this patch,
> >> > is it?
> >> 
> >> No, it isn't, the issue is present in v3.10-rc2. I don't know if it has
> >> ever worked.
> > 
> > The following patch fixes the issue, caused by physical RAM being present
> > at 0x41000000 on KZM9G. I'm not sure if it would be acceptable as a
> > generic solution though.
> > 
> > diff --git a/arch/arm/boot/compressed/head.S
> > b/arch/arm/boot/compressed/head.S index fe4d9c3..ea2f112 100644
> > --- a/arch/arm/boot/compressed/head.S
> > +++ b/arch/arm/boot/compressed/head.S
> > @@ -176,7 +176,7 @@ not_angel:
> >  #ifdef CONFIG_AUTO_ZRELADDR
> >                 @ determine final kernel image address
> >                 mov     r4, pc
> > -               and     r4, r4, #0xf8000000
> > +               and     r4, r4, #0xff000000
> >                 add     r4, r4, #TEXT_OFFSET
> >  #else
> >                 ldr     r4, =zreladdr
> 
> Thanks for tracking this down. I've now been looking into this a bit, and I
> think we should try to get KZM9G working without modifying the generic code.
> I am afraid that I have not been able to find the proper fix for this
> though, see below for a dump of the current state.
> 
> To be able to get some more details from the kernel I've cooked up some
> debug patches. It turns out that it's not really the code in
> boot/compressed/ that is problematic - more the kernel itself. Also, before
> trying to enable relocatable support via AUTO_ZRELADDR=y I think we should
> try to get the regular AUTO_ZRELADDR=n case going with an address that is
> compatible with the generic code that you pointed out above. Then when that
> is fine it should be relatively easy to support the relocatable case as
> well.
> 
> The attached patch
> "linux-3.11-pre-arm-shmobile-kzm9g-zreladdr-48000000-20130625.patch"
> makes sure the uImage gets loaded at 0x48008000 which from the
> boot/compressed code is compatible with either AUTO_ZRELADDR=n or =y.
> 
> I've used the following patches on top of renesas git
> renesas-next-20130620 to enable output together with DEBUG_LL=y and
> EARLY_PRINTK=y:
> 
> linux-3.11-pre-arm-shmobile-kzm9g-putc-20130625b.patch
> linux-3.11-pre-arm-shmobile-kzm9g-debug-macro-20130625.patch
> linux-3.11-pre-arm-mem-add-printout-20130625.patch
> linux-3.11-pre-arm-shmobile-kzm9g-zreladdr-48000000-20130625.patch
> 
> With the patches applied I get this serial output:
> 
> - - -
> 
> Filename 'kzm9g/uImage'.
> Load address: 0x43000000
> Loading: #################################################################
>          ##########################
> done
> Bytes transferred = 1335151 (145f6f hex)
> ## Booting kernel from Legacy Image at 43000000 ...
>    Image Name:   'Linux-3.10.0-rc2'
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    1335087 Bytes = 1.3 MiB
>    Load Address: 48008000
>    Entry Point:  48008000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> OK
> 
> Starting kernel ...
> 
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 3.10.0-rc2 (damm at w520) (gcc version 4.5.1 (Sourcery G++
> Lite 2010.09-50) ) #1 SMP Tue Jun 25 22:25:10 JST 2013
> CPU: ARMv7 Processor [412fc098] revision 8 (ARMv7), cr=10c5347d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine: kzm9g, model: KZM-A9-GT
> Adding RAM at 41000000-5f7fffff.
> bootconsole [earlycon0] enabled
> debug: ignoring loglevel setting.
> Ignoring RAM at 41000000-5f7fffff (vmalloc region overlap).
> cma: CMA: failed to reserve 16 MiB
> Memory policy: ECC disabled, Data cache writealloc
> Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below
> 0x0.
> 
> - - -
> 
> The fatal memory allocation most likely fails because all system memory is
> ignored, see "(vmalloc region overlap)" above. This seems to be the case
> regardless of HIGHMEM=y or =n.
> 
> It is possible to work around this issue by changing the memory bank start
> address in the DTS:
> 
> --- 0001/arch/arm/boot/dts/sh73a0-kzm9g.dts
> +++ work/arch/arm/boot/dts/sh73a0-kzm9g.dts     2013-06-25
> 22:17:19.000000000 +0900
> @@ -19,8 +19,14 @@
>                 bootargs = "console=tty0 console=ttySC4,115200
> root=/dev/nfs ip=dhcp ignore_loglevel earlyprintk=sh-sci.4,115200";
>         };
> 
> -       memory {
> +       memory at 48000000 {
>                 device_type = "memory";
> -               reg = <0x41000000 0x1e800000>;
> +               reg = <0x48000000 0x10000000>;
>         };
> 
> With the above hunk the kernel boots just fine. Unfortunately we cannot
> enable all memory which is kind of limiting. =)
> 
> So my current conclusion is that it looks like the kernel doesn't like to
> have the memory start address not aligned to 128 MByte somehow..

The vmalloc overlap range check will be gone in v3.11-rc1, but that 
unfortunately won't fix our issue. The kernel now fails to boot with

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.10.0-ag5+ (laurent at avalon) (gcc version 4.7.3 20130205 
(prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.02-01-20130221 - Linaro GCC 
2013.02) ) #450 SMP Thu Jul 4 01:16:013
CPU: ARMv7 Processor [412fc098] revision 8 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: kzm9g, model: KZM-A9-GT
Adding RAM at 41000000-5f7fffff.
debug: ignoring loglevel setting.
bootconsole [earlycon0] enabled
cma: dma_contiguous_reserve(limit 5f800000)
cma: dma_contiguous_reserve: reserving 16 MiB for global area
cma: dma_declare_contiguous(size 1000000, base 00000000, limit 5f800000)
cma: CMA: reserved 16 MiB at 5e800000
Memory policy: ECC disabled, Data cache writealloc
BUG: not creating mapping for 0x41000000 at 0xb9000000 in user region

Further investigation showed that the problem lies in a wrong dynamic 
PHYS_OFFSET computation, in __fixup_pv_table (arch/arm/kernel/head.S). The 
code assumes that the kernel is loaded at the beginning of the physical memory 
and thus computes a PHYS_OFFSET of 0x48000000. The value is stored in 
__pv_phys_offset, later used in the __phys_to_virt() implementation.

When adding low memory the base physical address 0x41000000 is erroneously 
converted to a virtual address of 0xb9000000 instead of 0xc0000000, which 
leads to the bug.

I'm pretty new to early boot code, so don't really see a way to compute the 
PHYS_OFFSET without assuming that the kernel is loaded at the beginning of the 
physical memory.

-- 
Regards,

Laurent Pinchart



From paul.gortmaker at windriver.com  Wed Jul  3 20:22:35 2013
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Wed, 3 Jul 2013 20:22:35 -0400
Subject: [PATCH] ARM: move body of head-common.S back to text section
In-Reply-To: <20130703172001.GH24642@n2100.arm.linux.org.uk>
References: <1372805629-18382-1-git-send-email-swarren@wwwdotorg.org>
 <20130702232259.GH11625@codeaurora.org>
 <51D39004.9000907@wwwdotorg.org>
 <20130703051907.GA22702@windriver.com>
 <20130703100044.GG24642@n2100.arm.linux.org.uk>
 <20130703153012.GK22702@windriver.com>
 <20130703172001.GH24642@n2100.arm.linux.org.uk>
Message-ID: <20130704002235.GL22702@windriver.com>

[Re: [PATCH] ARM: move body of head-common.S back to text section] On 03/07/2013 (Wed 18:20) Russell King - ARM Linux wrote:

> On Wed, Jul 03, 2013 at 11:30:12AM -0400, Paul Gortmaker wrote:
> > [Re: [PATCH] ARM: move body of head-common.S back to text section] On 03/07/2013 (Wed 11:00) Russell King - ARM Linux wrote:
> > 
> > > On Wed, Jul 03, 2013 at 01:19:07AM -0400, Paul Gortmaker wrote:
> > > > As an aside, I'm now thinking any __INIT that implicitly rely on EOF for
> > > > closure are nasty traps waiting to happen and it might be worthwhile to
> > > > audit and explicitly __FINIT them before someone appends to the file...
> > > 
> > > That hides a different kind of bug though - I hate __FINIT for exactly
> > > that reason.  Consider this:
> > 
> > Agreed - perhaps masking that it is a ".previous" just hides the fact
> > that it is more like a pop operation vs. an on/off operation, or per
> > function as we have in C.
> 
> I read the info pages, because I thought it was a pop operation too.
> I was concerned that .section didn't push the previous section onto the
> stack.
> 
> However, .popsection is the pseudio-op which pops.  .previous just toggles
> the current section with the section immediately before it.
> 
> So:
> 
> 	.text
> 	.data
> 	.previous
> 	/* this is .text */
> 	.previous
> 	/* this is .data */
> 	.previous
> 	/* this is .text */
> 	.previous
> 	/* this is .data */

Cool -- I bet we weren't the only ones thinking it was a pop.  Thanks.

Does that make __FINIT less evil than we previously assumed?  I think
your example was the following pseudo-patch:


	.text
	<some text>
+	.data
+ 	<some data>
	__INIT
	<big hunk of init>
	__FINIT
	/* this below used to be text */
	<more stuff that was originally meant for text>

Even if it is a toggle (vs. pop), the end text will now become data,
so the no-op __FINIT with an explicit section called out just below
it may still be the most unambiguous way to indicate what is going on.

> 
> > That seems reasonable to me.  I can't think of any self auditing that is
> > reasonably simple to implement.  One downside of __FINIT as a no-op vs.
> > what it is today, is that a dangling __FINIT in a file with no other
> > previous sections will emit a warning.  But that is a small low value
> > corner case I think.
> 
> That warning from __FINIT will only happen if there has been no section
> or .text or .data statement in the file at all.  As soon as you have any
> statement setting any kind of section, .previous doesn't warn.
> 
> So:
> 
> 	.text
> 	...
> 	__FINIT
> 
> produces no warning.o

Yep -- we are both saying the same thing here - hence why I called it a
small low value corner case.


From voice.shen at atmel.com  Wed Jul  3 21:15:00 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu, 4 Jul 2013 09:15:00 +0800
Subject: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
In-Reply-To: <CACQ1gAgPaRm3gxxJNgfj9bR565Q0+SNY3+EcjA_mrh1N+yPzSA@mail.gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-2-git-send-email-richard.genoud@gmail.com>
 <51D24299.9050209@atmel.com>
 <CACQ1gAgcc=j3kmcpjp8bbdHhxr_k=h8jJs6R_paJbPUMv74uGg@mail.gmail.com>
 <51D29927.80900@atmel.com>
 <CACQ1gAhnDk-qSt_5xrsMakXqGGDO5pEbA-9UDWCJG=AABDc+zg@mail.gmail.com>
 <CACQ1gAgPaRm3gxxJNgfj9bR565Q0+SNY3+EcjA_mrh1N+yPzSA@mail.gmail.com>
Message-ID: <51D4CC94.3020908@atmel.com>

Hi Richard,

On 7/3/2013 23:51, Richard Genoud wrote:
>> >but there's a violent hang (kernel stops, no trace) when I try the record :
>> >arecord -v -V stereo -Dplug:default -f cd -t wav -c 2 /tmp/toto.wav
>> >last thing I see is :
>> >dma dma0chan3: atc_control (3)

I don't meet this issue. Playback and recording works well on my side on 
at91sam9g35ek board.

>> >I'll try to trace that.
> I think it's DMA related.
> the last thing done by the kernel is:
>   i2c i2c-0: i2c_outb: 0x34 A
>   i2c i2c-0: i2c_outb: 0x0c A
>   i2c i2c-0: i2c_outb: 0x5a A
> meaning: enable power on, LINE IN, ADC, OSC, on the WM8731
> so, after that, data is comming from the codec to the SSC and then is
> handled by the DMA.
> there must be something nasty on the DMA bus to hang everything like that...

Will you try i2c without DMA support to test this issue?

> Richard.

Best Regards,
Bo Shen



From horms at verge.net.au  Wed Jul  3 21:23:02 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Jul 2013 10:23:02 +0900
Subject: [PATCH 00/08] ARM: shmobile: EMEV2 and KZM9D update
In-Reply-To: <20130702092725.32066.54861.sendpatchset@w520>
References: <20130702092725.32066.54861.sendpatchset@w520>
Message-ID: <20130704012301.GC13029@verge.net.au>

On Tue, Jul 02, 2013 at 06:27:25PM +0900, Magnus Damm wrote:
> ARM: shmobile: EMEV2 and KZM9D update
> 
> [PATCH 01/08] ARM: shmobile: Remove unused EMEV2/KZM9D early console
> [PATCH 02/08] ARM: shmobile: Update KZM9D dts command line
> [PATCH 03/08] ARM: shmobile: Make EMEV2 platform devices more compact
> [PATCH 04/08] ARM: shmobile: Add GIO to EMEV2 dtsi
> [PATCH 05/08] ARM: shmobile: Use DT for GIC on EMEV2 and KZM9D
> [PATCH 06/08] ARM: shmobile: Use DT for SMP on EMEV2 and KZM9D
> [PATCH 07/08] ARM: shmobile: EMEV2 map_io update
> [PATCH 08/08] ARM: shmobile: Disconnect EMEV2 SMP code from clocks
> 
> Several minor updates for the EMEV2 SoC and the KZM9D board:
> - Get rid of early console - the 8250-em driver does not support it
> - Update command line in DTS and remove old cruft
> - Make the EMEV2 platform devices more compact
> - Add GIO device nodes to the EMEV2 dtsi
> - Use DT for GIC and SMP for both regular KZM9D board code and DT
> - Reduce the size of the EMEV2 map_io - SCU is still however needed
> - Allow EMEV2 SMP to operate without legacy clock bits
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

Thanks, I have queued up all these patches for v3.12.


From jaeyong.yoo at samsung.com  Wed Jul  3 21:34:27 2013
From: jaeyong.yoo at samsung.com (Jaeyong Yoo)
Date: Thu, 04 Jul 2013 10:34:27 +0900
Subject: [Xen-devel] [PATCH RFC] xen/arm: domain kernel: Small fixes for
 making suspendable for arm
In-Reply-To: <alpine.DEB.2.02.1307031440350.5067@kaball.uk.xensource.com>
References: <1372842988-27547-1-git-send-email-jaeyong.yoo@samsung.com>
 <alpine.DEB.2.02.1307031440350.5067@kaball.uk.xensource.com>
Message-ID: <003b01ce7856$9f83d220$de8b7660$%yoo@samsung.com>



> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini at eu.citrix.com]
> Sent: Thursday, July 04, 2013 1:00 AM
> To: Jaeyong Yoo
> Cc: xen-devel at lists.xen.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; Will Deacon; Arnd Bergmann; Olof Johansson
> Subject: Re: [Xen-devel] [PATCH RFC] xen/arm: domain kernel: Small fixes
> for making suspendable for arm
> 
> On Wed, 3 Jul 2013, Jaeyong Yoo wrote:
> > Modify makefile to compile driver/xen/manage.c for arm and implement
> > resuming the shared page info. This patch is required for domu kernel
> > to test the xen-on-arndale migration.
> >
> > Since there are lot of missing functions for compiling hibernation
> > mode, temporarily I put empty functions in xen/dummy.c, but they are
> > originally belong to such as arch/arm/power directories (which is not
> existing).
> > I think there would be any better way...
> >
> > Signed-off-by: Jaeyong Yoo <jaeyong.yoo at samsung.com>
> >
> >  arch/arm/Kconfig                |  3 ++
> >  arch/arm/boot/dts/xenvm-4.2.dts |  2 +-
> >  arch/arm/xen/Makefile           |  2 +-
> >  arch/arm/xen/dummy.c            | 30 ++++++++++++++++
> >  arch/arm/xen/mmu.c              | 12 +++++++
> >  arch/arm/xen/suspend.c          | 76
> +++++++++++++++++++++++++++++++++++++++++
> >  arch/arm/xen/time.c             |  7 ++++
> 
> Be careful that xen for arm64 just went upstream and it's just recompiling
> the same Xen files under arm64.  See arch/arm64/xen.
> The changes you make to c files under arch/arm/xen need to compile on
> arm64 too.

OK.

> 
> 
> >  drivers/xen/Makefile            |  2 +-
> >  drivers/xen/manage.c            |  8 +++++
> >  9 files changed, 139 insertions(+), 3 deletions(-)  create mode
> > 100644 arch/arm/xen/dummy.c  create mode 100644 arch/arm/xen/mmu.c
> > create mode 100644 arch/arm/xen/suspend.c  create mode 100644
> > arch/arm/xen/time.c
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
> > 2c3bdce..77309f7 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1469,6 +1469,9 @@ config ARCH_NO_VIRT_TO_BUS  config ISA_DMA_API
> >  	bool
> >
> > +config ARCH_HIBERNATION_POSSIBLE
> > +        def_bool y
> > +
> 
> This could be an issue because if you introduce this symbol you allow
> users to compile hibernation code on all arm platforms.
> At the very least it should have "depends on XEN".

Got it! Thanks.

> 
> 
> 
> >  config PCI
> >  	bool "PCI support" if MIGHT_HAVE_PCI
> >  	help
> >
> > diff --git a/arch/arm/boot/dts/xenvm-4.2.dts
> > b/arch/arm/boot/dts/xenvm-4.2.dts index 2f4136b..33df5e6 100644
> > --- a/arch/arm/boot/dts/xenvm-4.2.dts
> > +++ b/arch/arm/boot/dts/xenvm-4.2.dts
> > @@ -17,7 +17,7 @@
> >
> >  	chosen {
> >  		/* this field is going to be adjusted by the hypervisor */
> > -		bootargs = "console=hvc0 root=/dev/xvda";
> > +		bootargs = "console=hvc0 root=/dev/xvda1 rw init";
> >  	};
> >
> >  	cpus {
> 
> please remove this change, this dts is just an example


OK

> 
> 
> > diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile index
> > 4384103..6fdc47a 100644
> > --- a/arch/arm/xen/Makefile
> > +++ b/arch/arm/xen/Makefile
> > @@ -1 +1 @@
> > -obj-y		:= enlighten.o hypercall.o grant-table.o
> > +obj-y		:= enlighten.o hypercall.o grant-table.o suspend.o
> mmu.o time.o dummy.o
> > diff --git a/arch/arm/xen/dummy.c b/arch/arm/xen/dummy.c new file mode
> > 100644 index 0000000..daa949c
> > --- /dev/null
> > +++ b/arch/arm/xen/dummy.c
> > @@ -0,0 +1,30 @@
> > +#include <linux/kernel.h>
> > +#include <linux/printk.h>
> > +
> > +void save_processor_state(void)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__); }
> > +
> > +void restore_processor_state(void)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__); }
> > +
> > +int swsusp_arch_suspend(void)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> > +	return 0;
> > +}
> > +
> > +int swsusp_arch_resume(void)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> > +	return 0;
> > +}
> > +
> > +int pfn_is_nosave(unsigned long pfn)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__);
> > +	return 0;
> > +}
> 
> These functions are not Xen specific, they should not be under
> arch/arm/xen.
> Maybe we could put them under arch/arm/power or drivers/xen?

Yes, that was my first thought, but I don't want to put anything to
arch/arm/power.
Also, I'm not sure about drivers/xen either. Maybe we have to think about
the 
whole power-related in arm.

> 
> 
> 
> > diff --git a/arch/arm/xen/mmu.c b/arch/arm/xen/mmu.c new file mode
> > 100644 index 0000000..cc0ccc9
> > --- /dev/null
> > +++ b/arch/arm/xen/mmu.c
> > @@ -0,0 +1,12 @@
> > +#include <linux/kernel.h>
> > +#include <xen/xen.h>
> > +
> > +void xen_mm_pin_all(void)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__); }
> > +
> > +void xen_mm_unpin_all(void)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__); }
> 
> No need to print an error here, I would just add a comment saying "no need
> to pin/unpin anything because we are always using second stage
> translation".

Got it.

> 
> 
> > diff --git a/arch/arm/xen/suspend.c b/arch/arm/xen/suspend.c new file
> > mode 100644 index 0000000..946a960
> > --- /dev/null
> > +++ b/arch/arm/xen/suspend.c
> > @@ -0,0 +1,76 @@
> > +#include <xen/xen.h>
> > +#include <xen/events.h>
> > +#include <xen/grant_table.h>
> > +#include <xen/hvm.h>
> > +#include <xen/interface/vcpu.h>
> > +#include <xen/interface/xen.h>
> > +#include <xen/interface/memory.h>
> > +#include <xen/interface/hvm/params.h> #include <xen/features.h>
> > +#include <xen/platform_pci.h> #include <xen/xenbus.h> #include
> > +<xen/page.h> #include <xen/xen-ops.h> #include <asm/xen/hypervisor.h>
> > +#include <asm/xen/hypercall.h> #include <linux/interrupt.h> #include
> > +<linux/irqreturn.h> #include <linux/module.h> #include <linux/of.h>
> > +#include <linux/of_irq.h> #include <linux/of_address.h>
> > +
> > +#include <linux/mm.h>
> > +
> > +void xen_arch_pre_suspend(void)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__); }
> 
> if we don't need to do anything, it's not an error.
> 

OK

> 
> > +void xen_arch_hvm_post_suspend(int suspend_cancelled) {
> > +	if( !suspend_cancelled ) {
> > +		int cpu;
> > +		struct xen_add_to_physmap xatp;
> > +		static struct shared_info *shared_info_page = 0;
> > +
> > +		if( !shared_info_page )
> > +			shared_info_page = (struct shared_info *)
> > +				get_zeroed_page(GFP_KERNEL);
> > +		if (!shared_info_page) {
> > +			pr_err("not enough memory\n");
> > +			return;
> > +		}
> > +
> > +		xatp.domid = DOMID_SELF;
> > +		xatp.idx = 0;
> > +		xatp.space = XENMAPSPACE_shared_info;
> > +		xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
> > +		if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
> > +			BUG();
> > +
> > +		HYPERVISOR_shared_info = (struct shared_info
> *)shared_info_page;
> > +
> > +		/* xen_vcpu is a pointer to the vcpu_info struct in the
> shared_info
> > +		 * page, we use it in the event channel upcall */
> > +		for_each_online_cpu(cpu) {
> > +			per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info-
> >vcpu_info[cpu];
> > +		}
> > +		printk(KERN_ERR"%s: remmaping shared info...\n", __func__);
> > +	}
> > +}
> 
> It would be good to refactor the shared_info page setup on a separate
> function that can be called from xen_guest_init and from
> xen_arch_hvm_post_suspend, like we do on x86.

OK.

> 
> 
> > +void xen_arch_post_suspend(int suspend_cancelled) {
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__); }
> > +
> > +static void xen_vcpu_notify_restore(void *data) {
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__); }
> > +
> > +void xen_arch_resume(void)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__); }
> 
> if don't need to do anything, it's not an error.
> 
> 
> > diff --git a/arch/arm/xen/time.c b/arch/arm/xen/time.c new file mode
> > 100644 index 0000000..af90e53
> > --- /dev/null
> > +++ b/arch/arm/xen/time.c
> > @@ -0,0 +1,7 @@
> > +#include <linux/kernel.h>
> > +#include <xen/xen.h>
> > +
> > +void xen_timer_resume(void)
> > +{
> > +	printk(KERN_ERR"%s: function not implemented\n", __func__); }
> 
> same here
> 
> 
> > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index
> > eabd0ee..3d24a95 100644
> > --- a/drivers/xen/Makefile
> > +++ b/drivers/xen/Makefile
> > @@ -1,10 +1,10 @@
> >  ifneq ($(CONFIG_ARM),y)
> > -obj-y	+= manage.o
> >  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
> >  endif
> >  obj-$(CONFIG_X86)			+= fallback.o
> >  obj-y	+= grant-table.o features.o events.o balloon.o
> >  obj-y	+= xenbus/
> > +obj-y	+= manage.o
> >
> >  nostackp := $(call cc-option, -fno-stack-protector)
> >  CFLAGS_features.o			:= $(nostackp)
> > diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c index
> > 412b96c..140c7a9 100644
> > --- a/drivers/xen/manage.c
> > +++ b/drivers/xen/manage.c
> > @@ -17,6 +17,7 @@
> >  #include <xen/events.h>
> >  #include <xen/hvc-console.h>
> >  #include <xen/xen-ops.h>
> > +#include <xen/interface/sched.h>
> >
> >  #include <asm/xen/hypercall.h>
> >  #include <asm/xen/page.h>
> > @@ -86,7 +87,14 @@ static int xen_suspend(void *data)
> >  	 * or the domain was merely checkpointed, and 0 if it
> >  	 * is resuming in a new domain.
> >  	 */
> > +#ifdef CONFIG_ARM
> > +	{
> > +		struct sched_shutdown r = { .reason = SHUTDOWN_suspend };
> > +		HYPERVISOR_sched_op(SCHEDOP_shutdown, &r);
> > +	}
> > +#else
> >  	si->cancelled = HYPERVISOR_suspend(si->arg);
> > +#endif
> >
> >  	if (si->post)
> >  		si->post(si->cancelled);
> 
> We should implement HYPERVISOR_suspend on ARM

Got it!

Jaeyong



From shawn.guo at linaro.org  Wed Jul  3 22:01:53 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 4 Jul 2013 10:01:53 +0800
Subject: [PATCH v2] ARM: mx6: Fix the number of reported cores
In-Reply-To: <1372870510-14624-1-git-send-email-festevam@gmail.com>
References: <1372870510-14624-1-git-send-email-festevam@gmail.com>
Message-ID: <20130704020151.GB14617@S2101-09.ap.freescale.net>

On Wed, Jul 03, 2013 at 01:55:10PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> On a mx6 quad-core processor:
> 
> $ cat /proc/cpuinfo                                             
> processor       : 0                                                             
> model name      : ARMv7 Processor rev 10 (v7l)                                  
> BogoMIPS        : 1581.05                                                       
> Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls               
> CPU implementer : 0x41                                                          
> CPU architecture: 7                                                             
> CPU variant     : 0x2                                                           
> CPU part        : 0xc09                                                         
> CPU revision    : 10                                                            
> 
> ,which incorrectly shows this is a single core device.
> 
> Commit a0ae0240 (ARM: kernel: add device tree init map function) introduced the 
> following requirement according to Documentation/devicetree/bindings/arm/cpus.txt:
> "For the ARM architecture every CPU node must contain the following properties:
> 
> - device_type:	must be "cpu" 
> 
> Pass the 'device_type' property for each cpu node, so that we can have all the 
> four cores correctly reported again.
> 
> Cc: <stable at vger.kernel.org> #3.10
> Reported-by: Mike Loebl <mloebl at gmail.com> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Lorenzo had commit 7925e89 (ARM: dts: imx: cpus/cpu nodes dts updates)
fixing up thing, which has just hit the mainline.  But it seems we were
unaware of this user space regression and did not apply the fix to 3.10.
Now we have to apply it for 3.10 via stable tree.

Shawn



From horms at verge.net.au  Wed Jul  3 22:36:17 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 4 Jul 2013 11:36:17 +0900
Subject: [PATCH v3] ARM: shmobile: lager: Add DT reference
In-Reply-To: <CANqRtoTD3Bgm775DhFhs2kn1+sSLb-pX89mFRoHrc2x4sRT_RQ@mail.gmail.com>
References: <1372838251-6314-1-git-send-email-horms+renesas@verge.net.au>
 <CANqRtoTD3Bgm775DhFhs2kn1+sSLb-pX89mFRoHrc2x4sRT_RQ@mail.gmail.com>
Message-ID: <20130704023614.GA435@verge.net.au>

On Wed, Jul 03, 2013 at 05:21:10PM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Wed, Jul 3, 2013 at 4:57 PM, Simon Horman <horms+renesas at verge.net.au> wrote:
> > This is sufficient to allow boot of the Lager board with
> > a console without boards-lager.c compiled into the kernel.
> > This is an example of a minimal but still useful initialisation
> > of the board using DT as much as possible.
> >
> > As such it is the same as the boot of Lager that can be achieved
> > without a board file. The intention of adding this file
> > is to facilitate further work to allow board specific devices to be
> > initialised via DT.
> >
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> >
> > ---
> >
> > v3
> > * Supply temporary machine_init call-back in lager-reference.c to
> >   initialise clocks and bring up SCIF and CMT in C. Magnus
> >   advised me that this is not desired in the SoC code.
> > * Add lager-reference to Makefile.boot
> >
> > v2
> > * Use recently added r8a7790_init_delay()
> 
> This looks good to me, thanks!
> 
> Acked-by: Magnus Damm <damm at opensource.se>

Thanks, I have queued this up for v3.12.


From baruch at tkos.co.il  Wed Jul  3 23:30:26 2013
From: baruch at tkos.co.il (Baruch Siach)
Date: Thu, 4 Jul 2013 06:30:26 +0300
Subject: [PATCH] clocksource/cadence_ttc: Reuse clocksource as sched_clock
In-Reply-To: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <20130704033026.GX4288@tarshish>

Hi Soren,

On Wed, Jul 03, 2013 at 02:50:16PM -0700, Soren Brinkmann wrote:
> Reuse the TTC clocksource timer as sched clock, too. Since only a single
> sched clock is supported in Linux, this feature optional and can be
> selected through Kconfig.
> 
> Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
> ---

[...]

> diff --git a/drivers/clocksource/cadence_ttc_timer.c 
> b/drivers/clocksource/cadence_ttc_timer.c
> index 4cbe28c..ef0f52b 100644
> --- a/drivers/clocksource/cadence_ttc_timer.c
> +++ b/drivers/clocksource/cadence_ttc_timer.c
> @@ -22,6 +22,7 @@
>  #include <linux/of_irq.h>
>  #include <linux/slab.h>
>  #include <linux/clk-provider.h>
> +#include <asm/sched_clock.h>

This has changed to linux/sched_clock.h in the tip tree. See 
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers/core&id=38ff87f77af0b5a93fc8581cff1d6e5692ab8970.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -


From festevam at gmail.com  Thu Jul  4 00:08:13 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 4 Jul 2013 01:08:13 -0300
Subject: mx6q boot on linux-next 20130703
In-Reply-To: <CAOMZO5DgAu2-cknESp4a675KP5gDrJxM2A_FqUgAZav83Db=fw@mail.gmail.com>
References: <CAOMZO5DgAu2-cknESp4a675KP5gDrJxM2A_FqUgAZav83Db=fw@mail.gmail.com>
Message-ID: <CAOMZO5AvXJJHmoEu3BMN=EYCxS4O1-2ivsSzS2eCuyPeiw_brQ@mail.gmail.com>

On Wed, Jul 3, 2013 at 8:52 PM, Fabio Estevam <festevam at gmail.com> wrote:
> Hi,
>
> I am running linux-next 20130703 on a mx6q board, and seeing a strange
> behaviour.
>
> Only if I enable DEBUG_LL + earlyprintk and disable
> CONFIG_SERIAL_FSL_LPUART (serial driver for the FSL Vybrid SoC), I am
> able to boot the kernel until the prompt.
>
> Does anyone have any suggestion?

Ok, I managed to boot the default imx_v6_v7_defconfig on my mx6q board if I do:

--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1652,7 +1652,7 @@ static void __exit imx_serial_exit(void)
        uart_unregister_driver(&imx_reg);
 }

-module_init(imx_serial_init);
+arch_initcall(imx_serial_init);
 module_exit(imx_serial_exit);

 MODULE_AUTHOR("Sascha Hauer");

Is this the correct approach?


From nsekhar at ti.com  Thu Jul  4 00:46:24 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Thu, 4 Jul 2013 10:16:24 +0530
Subject: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead
 of hiding behind a quirk
In-Reply-To: <1372860209-3504-3-git-send-email-coelho@ti.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
 <1372860209-3504-3-git-send-email-coelho@ti.com>
Message-ID: <51D4FE20.6000805@ti.com>

On 7/3/2013 7:33 PM, Luciano Coelho wrote:
> The platform_quirk element in the platform data was used to change the
> way the IRQ is triggered.  When set, the EDGE_IRQ quirk would change
> the irqflags used and treat edge trigger differently from the rest.
> 
> Instead of hiding this irq flag setting behind the quirk, have the
> board files set the flags during initialization.  This will be more
> meaningful than driver-specific quirks when we switch to DT.
> 
> Additionally, fix missing gpio_request() calls in the boarding files
> (so that setting the flags actually works).
> 
> Cc: Tony Lindgren <tony at atomide.com>
> Cc: Sekhar Nori <nsekhar at ti.com>
> Signed-off-by: Luciano Coelho <coelho at ti.com>
> ---
>  arch/arm/mach-davinci/board-da850-evm.c      |    8 +++++-

For the board-da850-evm.c change,

Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar


From mindentropy at gmail.com  Thu Jul  4 00:51:27 2013
From: mindentropy at gmail.com (mind entropy)
Date: Thu, 4 Jul 2013 10:21:27 +0530
Subject: On common struct clk in clock framework.
In-Reply-To: <16151917.X00PMOJFZ6@flatron>
References: <CAM2a4uyrX0t-W8hXKROvZgJPSyCY+DaviV-eRVZOhyPx=WNBUw@mail.gmail.com>
 <16151917.X00PMOJFZ6@flatron>
Message-ID: <CAM2a4uxMO4JjA-_QS_x+9FB38CYJFWCcYQk-kTc7YXMVuJ91Ug@mail.gmail.com>

On Wed, Jul 3, 2013 at 11:37 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
>
> The examples you pointed are not using Common Clock Framework. See
> Documentation/clk.txt and drivers/clk/ for more information about CCF.
>
> As for s3c24xx, CCF driver for the whole platform is already merged for
> Linux 3.11.
>
> Best regards,
> Tomasz
>

Thanks TomasZ. I have gone through the docs and was quite confused. I
will have a look at the merge.


From mturquette at linaro.org  Thu Jul  4 01:07:35 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 3 Jul 2013 22:07:35 -0700
Subject: On common struct clk in clock framework.
In-Reply-To: <CAM2a4uxMO4JjA-_QS_x+9FB38CYJFWCcYQk-kTc7YXMVuJ91Ug@mail.gmail.com>
References: <CAM2a4uyrX0t-W8hXKROvZgJPSyCY+DaviV-eRVZOhyPx=WNBUw@mail.gmail.com>
 <16151917.X00PMOJFZ6@flatron>
 <CAM2a4uxMO4JjA-_QS_x+9FB38CYJFWCcYQk-kTc7YXMVuJ91Ug@mail.gmail.com>
Message-ID: <CAPtuhTgne+GrCwiSpJn5ngV5qaZwQTe82sLSM+3Dvr5nfCE9Jg@mail.gmail.com>

On Wed, Jul 3, 2013 at 9:51 PM, mind entropy <mindentropy at gmail.com> wrote:
> On Wed, Jul 3, 2013 at 11:37 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
>>
>> The examples you pointed are not using Common Clock Framework. See
>> Documentation/clk.txt and drivers/clk/ for more information about CCF.
>>
>> As for s3c24xx, CCF driver for the whole platform is already merged for
>> Linux 3.11.
>>
>> Best regards,
>> Tomasz
>>
>
> Thanks TomasZ. I have gone through the docs and was quite confused. I
> will have a look at the merge.

Any clock implementation that defines its own struct clk is a legacy
clock framework and is not using the common clock infrastructure.
Another hint is if you see a clock driver that includes
linux/clk-provider.h, this implies a clock driver that is using the
common clock framework.

Regards,
Mike

>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From kishon at ti.com  Thu Jul  4 01:17:53 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 4 Jul 2013 10:47:53 +0530
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <20130703132038.GI15056@arwen.pp.htv.fi>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
 <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi>
Message-ID: <51D50581.1000800@ti.com>

Hi,

On Wednesday 03 July 2013 06:50 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Jul 03, 2013 at 03:35:39PM +0530, Kishon Vijay Abraham I wrote:
>> On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote:
>>> Hi Kishon,
>>>
>>>> -----Original Message-----
>>>> From: ABRAHAM, KISHON VIJAY
>>>> Sent: Wednesday, June 26, 2013 5:17 PM
>>>> To: grant.likely at linaro.org; tony at atomide.com; Balbi, Felipe; ABRAHAM,
>>>> KISHON VIJAY; arnd at arndb.de; swarren at nvidia.com;
>>>> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
>>>> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
>>>> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
>>>> foundation.org
>>>> Cc: rob.herring at calxeda.com; rob at landley.net; linux at arm.linux.org.uk;
>>>> benoit.cousson at linaro.org; mchehab at redhat.com; cesarb at cesarb.net;
>>>> davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org; Shilimkar,
>>>> Santosh; devicetree-discuss at lists.ozlabs.org; linux-
>>>> doc at vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T; Cherian,
>>>> George
>>>> Subject: [PATCH v9 0/8] Generic PHY Framework
>>>>
>>>> Added a generic PHY framework that provides a set of APIs for the PHY
>>>> drivers
>>>> to create/destroy a PHY and APIs for the PHY users to obtain a
>>>> reference to
>>>> the PHY with or without using phandle.
>>>>
>>>> This framework will be of use only to devices that uses external PHY
>>>> (PHY
>>>> functionality is not embedded within the controller).
>>>>
>>>> The intention of creating this framework is to bring the phy drivers
>>>> spread
>>>> all over the Linux kernel to drivers/phy to increase code re-use and
>>>> to
>>>> increase code maintainability.
>>>
>>> I would like to use this framework for a smart-card controller connected to a
>>> smart-card phy. I have some questions and would like to get feedback on the same.
>>
>> glad to know that :-)
>>>
>>> I am using ?TDA8026" Smartcard PHY from NXP. Here is the link for datasheet
>>> and app note for the same. The smart card controller is inside the TI SoC
>>> I am working with.
>>>
>>> Datasheet :
>>> www.nxp.com/documents/data_sheet/TDA8026.pdf?
>>>
>>> Appnote :
>>> http://www.nxp.com/documents/application_note/AN10724.pdf
>>>
>>> The TI SoC details are not public (yet). I can provide details to you offline.
>>>
>>> Brief about operation:
>>> -	The controller can work with and without a PHY
>>> -	When not using PHY, it is limited to talking to a single
>>> 	smart card. There is also a need to put external de-activation logic
>>> 	on card removal for this case.
>>> -	With a PHY you can use more than one smart card.
>>> -	Phy has 5 slots :  1 for smart card (credit/debit/other card with chip)
>>>        and others for SAM ? SIM like modules
>>> - 	Once the PHY is initialized, there are some operations that the controller
>>> 	can request of the PHY like:
>>> 	- Card configurations  - set voltage
>>> 	- Activation of card
>>> 	- ATR ? Answer to reset
>>> 	- Warm reset
>>> 	- ADPU exchange
>>> 	- Deactivation ( Normal/Emergency)
>>
>> hmm.. We should think about extending the phy_ops to include these
>> operations (something like phy_smart_card_ops so that other
>> smart_card PHYs will also be able to use it).
>
> let's try to avoid use-case specific additions. set_voltage sounds like
> a regulator thing, but the regulator is controlled through the PHY. I
> guess it makes sense to have a generic phy_set_voltage() call since even
> USB can make use of that.
>
> For card activation, it sounds like phy_init()/phy_shutdown() would
> cover it.
>
> For warm reset perhaps a phy_reset() callback ? Although that could,
> easily, get abused.
>
> For deactivation, that's phy_shutdown().
>
> ATR and ADPU needs more thought, I guess.
>
>>> - 	In the mode when smartcard controller talks directly to the card without the need
>>> 	for a PHY, all the above operations will be carried out by the controller itself
>>>
>>> My current thought process is to make the controller driver provide the user interface
>>> and talk to the PHY using the generic PHY framework you proposed. In the case where there
>>> is no PHY, my idea is to create a "dummy" PHY which uses the controller functionality itself.
>>
>> right. And in the case where you actually have a PHY, create a PHY
>> driver and implement the phy_smart_card_ops and register with the PHY
>> framework.
>
> I would try to avoid that. Otherwise we will have phy_usb_ops,
> phy_sata_ops, phy_network_ops, phy_pci_ops, etc etc etc. It would easily
> blow up.

true. But it's certainly going to be difficult to map certain function
specific ops to the generic ops (just like ATR and ADPU in smart card
case or set pixel for hdmi).

Thanks
Kishon


From w at 1wt.eu  Thu Jul  4 02:15:30 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 4 Jul 2013 08:15:30 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <8761wrp7y5.fsf@natisbad.org>
References: <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net> <87y59ows4n.fsf@natisbad.org>
 <20130702220936.GC10215@1wt.eu> <20130703202105.GE27003@titan.lakedaemon.net>
 <20130703203541.GI16785@1wt.eu> <20130703204451.GF27003@titan.lakedaemon.net>
 <20130703211450.GJ16785@1wt.eu> <20130703222315.GK16785@1wt.eu>
 <8761wrp7y5.fsf@natisbad.org>
Message-ID: <20130704061530.GM16785@1wt.eu>

Hi Arnaud,

On Thu, Jul 04, 2013 at 12:58:10AM +0200, Arnaud Ebalard wrote:
> > Oh last important point, I found it in the 2.6.35.9-LSP-1.0.2_gw patch.
> > If someone finds a more recent one in a more recent kernel, it might be
> > worth comparing them.
> 
> The version in Netgear kernel (a 3.0.56, 25/Apr/2012 KW40 LSP release
> 3.1.0-NQ) is almost identical to the one in mirabox 2.6.35 kernel
> (24/Nov/2011, KW40 LSP release 1.0.2-NQ) if you remove the fixes for
> trailing spaces and tabs: 
> 
> 
> @@ -1618,7 +1618,9 @@
>  		ret = -ENXIO;
>  		goto fail_free_irq;
>  	}
> -	if (mtd_has_partitions()) {
> +
> +
> +#ifdef CONFIG_MTD_CMDLINE_PARTS
>  		if (mtd_has_cmdlinepart()) {
>  			static const char *probes[] = { "cmdlinepart", NULL };
>  			struct mtd_partition *parts;
> @@ -1627,12 +1629,11 @@
>  			nr_parts = parse_mtd_partitions(mtd, probes, &parts, 0);
>  
>  			if (nr_parts)
> -				return add_mtd_partitions(mtd, parts, nr_parts);
> +				return mtd_device_register(mtd, parts, nr_parts);
>  		}
> -		return add_mtd_partitions(mtd, pdata->parts, pdata->nr_parts);
> -	}
> -
> -	return add_mtd_device(mtd) == 1 ? -ENODEV : 0;
> +		return mtd_device_register(mtd, pdata->parts, pdata->nr_parts);
> +#endif
> +		return (mtd_device_register(mtd, pdata->parts, pdata->nr_parts));
>  
>  fail_free_irq:
>  	free_irq(IRQ_AURORA_NFC, info);
> @@ -1661,10 +1662,6 @@
>  
>  	platform_set_drvdata(pdev, NULL);
>  
> -	del_mtd_device(mtd);
> -#ifdef CONFIG_MTD_PARTITIONS
> -	del_mtd_partitions(mtd);
> -#endif
>  	free_irq(IRQ_AURORA_NFC, info);
>  	if (info->use_dma) {
>  		dma_free_writecombine(&pdev->dev, info->data_buff_size,
> @@ -1675,7 +1672,10 @@
>  	clk_disable(info->clk);
>  	clk_put(info->clk);
>  #endif
> -	kfree(mtd);
> +	if (mtd) {
> +		mtd_device_unregister(mtd);
> +		kfree(mtd);
> +	}
>  	return 0;
>  }
 
I had found a 3.5.x version somewhere (don't remember where, maybe an
ubuntu repository) which had the same changes. I had merged the last
hunk above, and other ones were not needed.

Thanks,
Willy



From shawn.guo at linaro.org  Thu Jul  4 02:29:14 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 4 Jul 2013 14:29:14 +0800
Subject: ASoC: wm8962: NULL pdata pointer
Message-ID: <20130704062913.GC14617@S2101-09.ap.freescale.net>

Mark,

I'm running next-20130703 and seeing the following NULL pointer bug.

Unable to handle kernel NULL pointer dereference at virtual address 00000004
pgd = 80004000
[00000004] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-next-20130703 #6
task: bf870000 ti: bf874000 task.ti: bf874000
PC is at wm8962_probe+0x140/0x6b4
...

It seems to me that it's caused by a merge error in 384b834.  And the
change below can remove the problem.

Shawn

---8<----

diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
index b1dc7d4..e2de9ec 100644
--- a/sound/soc/codecs/wm8962.c
+++ b/sound/soc/codecs/wm8962.c
@@ -3377,7 +3377,7 @@ static int wm8962_probe(struct snd_soc_codec *codec)
 {
        int ret;
        struct wm8962_priv *wm8962 = snd_soc_codec_get_drvdata(codec);
-       struct wm8962_pdata *pdata = dev_get_platdata(codec->dev);
+       struct wm8962_pdata *pdata = &wm8962->pdata;
        int i, trigger, irq_pol;
        bool dmicclk, dmicdat;





From b32955 at freescale.com  Thu Jul  4 02:39:01 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Thu, 4 Jul 2013 14:39:01 +0800
Subject: mx6q boot on linux-next 20130703
In-Reply-To: <CAOMZO5DgAu2-cknESp4a675KP5gDrJxM2A_FqUgAZav83Db=fw@mail.gmail.com>
References: <CAOMZO5DgAu2-cknESp4a675KP5gDrJxM2A_FqUgAZav83Db=fw@mail.gmail.com>
Message-ID: <51D51885.3080102@freescale.com>

? 2013?07?04? 07:52, Fabio Estevam ??:
> Hi,
>
> I am running linux-next 20130703 on a mx6q board, and seeing a strange
> behaviour.
>
> Only if I enable DEBUG_LL + earlyprintk and disable
> CONFIG_SERIAL_FSL_LPUART (serial driver for the FSL Vybrid SoC), I am
> able to boot the kernel until the prompt.
>
> Does anyone have any suggestion?

I tested the linux-next-0625, the boot is ok.

I think this issue is caused by the common code, not the imx code.

thanks
Huang Shijie





From shawn.guo at linaro.org  Thu Jul  4 02:41:51 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 4 Jul 2013 14:41:51 +0800
Subject: mx6q boot on linux-next 20130703
In-Reply-To: <CAOMZO5AvXJJHmoEu3BMN=EYCxS4O1-2ivsSzS2eCuyPeiw_brQ@mail.gmail.com>
References: <CAOMZO5DgAu2-cknESp4a675KP5gDrJxM2A_FqUgAZav83Db=fw@mail.gmail.com>
 <CAOMZO5AvXJJHmoEu3BMN=EYCxS4O1-2ivsSzS2eCuyPeiw_brQ@mail.gmail.com>
Message-ID: <20130704064149.GD14617@S2101-09.ap.freescale.net>

On Thu, Jul 04, 2013 at 01:08:13AM -0300, Fabio Estevam wrote:
> On Wed, Jul 3, 2013 at 8:52 PM, Fabio Estevam <festevam at gmail.com> wrote:
> > Hi,
> >
> > I am running linux-next 20130703 on a mx6q board, and seeing a strange
> > behaviour.
> >
> > Only if I enable DEBUG_LL + earlyprintk and disable

Yes, I see the issue here too, and turning on earlyprintk can remove the
issue.

> > CONFIG_SERIAL_FSL_LPUART (serial driver for the FSL Vybrid SoC), I am

This is irrelevant according to my test.

> > able to boot the kernel until the prompt.
> >
> > Does anyone have any suggestion?
> 

I do not get time to track it down.  But it does not seems to be an imx
specific problem.

> Ok, I managed to boot the default imx_v6_v7_defconfig on my mx6q board if I do:
> 
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -1652,7 +1652,7 @@ static void __exit imx_serial_exit(void)
>         uart_unregister_driver(&imx_reg);
>  }
> 
> -module_init(imx_serial_init);
> +arch_initcall(imx_serial_init);
>  module_exit(imx_serial_exit);
> 
>  MODULE_AUTHOR("Sascha Hauer");
> 
> Is this the correct approach?

Without knowing the root cause of the problem, we can not tell.

Shawn



From shawn.guo at linaro.org  Thu Jul  4 02:56:59 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 4 Jul 2013 14:56:59 +0800
Subject: [PATCH 1/6] ARM: dts: i.MX27: Move IIM node under AIPI2 bus
In-Reply-To: <1372780949-31897-1-git-send-email-shc_work@mail.ru>
References: <1372780949-31897-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130704065658.GG14617@S2101-09.ap.freescale.net>

On Tue, Jul 02, 2013 at 08:02:24PM +0400, Alexander Shiyan wrote:
> This patch moves IIM node under AIPI2 bus, since this is proper
> location for this module.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>

All applied, thanks.

Shawn



From shawn.guo at linaro.org  Thu Jul  4 03:05:55 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 4 Jul 2013 15:05:55 +0800
Subject: [PATCH] ARM: imx_v4_v5_defconfig: Select CONFIG_MACH_IMX25_DT
In-Reply-To: <1372855377-19884-1-git-send-email-festevam@gmail.com>
References: <1372855377-19884-1-git-send-email-festevam@gmail.com>
Message-ID: <20130704070553.GA11046@S2101-09.ap.freescale.net>

On Wed, Jul 03, 2013 at 09:42:57AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Allow booting a mx25 dt kernel by default.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Applied, thanks.



From wangyuhang2014 at gmail.com  Thu Jul  4 03:07:31 2013
From: wangyuhang2014 at gmail.com (=?GB2312?B?zfXT7rq9?=)
Date: Thu, 4 Jul 2013 15:07:31 +0800
Subject: SPI : DUAL/QUAD support
Message-ID: <CAHSAbzMGqQgCLL9ymQ6qSeJRybv2jJfm-sbzZVgayVyKYgufLQ@mail.gmail.com>

Hi

Now some SPI controllers and Slave Devices have supported
DUAL and QUAD transfer mode. But SPI controller driver in kernel
has no member to deliver this information from Slave to Master.
So in my opinion, adding transfer mode members to deal with the problem.

In my SPI system, slave device is a Nor-Flash chip(s25fl129p) which
use m25p80 driver. My patch below aims to make spi controller know
the way that the slave want.

Firstly user provides the SPI slave information into spi_board_info,
including tx_bitwidth and rx_bitwidth. When the SPI slave is registered,
information in spi_board_info is delivered to spi_device. Then SPI slave
driver will add the transfer mode information into the spi_tranfer package
and send it out to SPI controller driver. SPI controller driver will
analyse the transfer package and set the certain transfer mode to
its register.

This patch do not support device tree....


Signed-off-by: wangyuhang <wangyuhang2014 at gmail.com>
---
 drivers/mtd/devices/m25p80.c |    2 ++
 drivers/spi/spi.c            |    2 ++
 include/linux/spi/spi.h      |    8 ++++++++
 3 files changed, 12 insertions(+)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 5b6b072..1411678 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -354,6 +354,7 @@ static int m25p80_read(struct mtd_info *mtd,
loff_t from, size_t len,

        t[1].rx_buf = buf;
        t[1].len = len;
+       t[1].bitwidth = flash->spi->rx_bitwidth;
        spi_message_add_tail(&t[1], &m);

        mutex_lock(&flash->lock);
@@ -409,6 +410,7 @@ static int m25p80_write(struct mtd_info *mtd,
loff_t to, size_t len,
        spi_message_add_tail(&t[0], &m);

        t[1].tx_buf = buf;
+       t[1].bitwidth = flash->spi->tx_bitwidth;
        spi_message_add_tail(&t[1], &m);

        mutex_lock(&flash->lock);
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 004b10f..cd99022 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -452,6 +452,8 @@ struct spi_device *spi_new_device(struct spi_master *master,
        proxy->irq = chip->irq;
        strlcpy(proxy->modalias, chip->modalias, sizeof(proxy->modalias));
        proxy->dev.platform_data = (void *) chip->platform_data;
+       proxy->rx_bitwidth = chip->rx_bitwidth;
+       proxy->tx_bitwidth = chip->tx_bitwidth;
        proxy->controller_data = chip->controller_data;
        proxy->controller_state = NULL;

diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 38c2b92..ddcf308 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -93,6 +93,8 @@ struct spi_device {
        void                    *controller_data;
        char                    modalias[SPI_NAME_SIZE];
        int                     cs_gpio;        /* chip select gpio */
+       u8                      rx_bitwidth;
+       u8                      tx_bitwidth;

        /*
         * likely need more hooks for more protocol options affecting how
@@ -511,6 +513,10 @@ struct spi_transfer {
        dma_addr_t      rx_dma;

        unsigned        cs_change:1;
+       u8              bitwidth;
+#define        SPI_BITWIDTH_SINGLE     0x01; /* 1bit transfer */
+#define        SPI_BITWIDTH_DUAL       0x02; /* 2bits transfer */
+#define        SPI_BITWIDTH_QUAD       0x03; /* 4bits transfer */
        u8              bits_per_word;
        u16             delay_usecs;
        u32             speed_hz;
@@ -859,6 +865,8 @@ struct spi_board_info {
         * where the default of SPI_CS_HIGH = 0 is wrong.
         */
        u8              mode;
+       u8              rx_bitwidth;
+       u8              tx_bitwidth;

        /* ... may need additional spi_device chip config data here.
         * avoid stuff protocol drivers can set; but include stuff
--
1.7.9.5

Best regards
Jay


From voice.shen at atmel.com  Thu Jul  4 03:16:38 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu,  4 Jul 2013 15:16:38 +0800
Subject: [PATCH 0/4] arm: atmel: enable kernel uncompress info output
Message-ID: <1372922202-28606-1-git-send-email-voice.shen@atmel.com>

this patch set enable kernel uncompress info output
  - sama5d3
  - at91sam9n12

without this patch set, it won't show following information
---8>---
Uncompressing Linux... done, booting the kernel.
---<8---


Bo Shen (4):
  arm: atmel: sama5: add definition for usart base address
  arm: atmel: include sama5d3.h into hardware.h
  arm: atmel: sama5: enable kernel uncompress info output
  arm: atmel: sam9n12: enable kernel uncompress info output

 arch/arm/mach-at91/include/mach/hardware.h   |    1 +
 arch/arm/mach-at91/include/mach/sama5d3.h    |    8 ++++++++
 arch/arm/mach-at91/include/mach/uncompress.h |   13 +++++++++++++
 3 files changed, 22 insertions(+)

-- 
1.7.9.5



From voice.shen at atmel.com  Thu Jul  4 03:16:39 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu,  4 Jul 2013 15:16:39 +0800
Subject: [PATCH 1/4] arm: atmel: sama5: add definition for usart base address
In-Reply-To: <1372922202-28606-1-git-send-email-voice.shen@atmel.com>
References: <1372922202-28606-1-git-send-email-voice.shen@atmel.com>
Message-ID: <1372922202-28606-2-git-send-email-voice.shen@atmel.com>

add definition for usart base address

Signed-off-by: Bo Shen <voice.shen at atmel.com>
---
 arch/arm/mach-at91/include/mach/sama5d3.h |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-at91/include/mach/sama5d3.h b/arch/arm/mach-at91/include/mach/sama5d3.h
index 6dc81ee..31096a8 100644
--- a/arch/arm/mach-at91/include/mach/sama5d3.h
+++ b/arch/arm/mach-at91/include/mach/sama5d3.h
@@ -65,6 +65,14 @@
 #define SAMA5D3_ID_IRQ0		47	/* Advanced Interrupt Controller (IRQ0) */
 
 /*
+ * User Peripheral physical base addresses.
+ */
+#define SAMA5D3_BASE_USART0	0xf001c000
+#define SAMA5D3_BASE_USART1	0xf0020000
+#define SAMA5D3_BASE_USART2	0xf8020000
+#define SAMA5D3_BASE_USART3	0xf8024000
+
+/*
  * Internal Memory
  */
 #define SAMA5D3_SRAM_BASE	0x00300000	/* Internal SRAM base address */
-- 
1.7.9.5



From voice.shen at atmel.com  Thu Jul  4 03:16:40 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu,  4 Jul 2013 15:16:40 +0800
Subject: [PATCH 2/4] arm: atmel: include sama5d3.h into hardware.h
In-Reply-To: <1372922202-28606-1-git-send-email-voice.shen@atmel.com>
References: <1372922202-28606-1-git-send-email-voice.shen@atmel.com>
Message-ID: <1372922202-28606-3-git-send-email-voice.shen@atmel.com>

include sama5d3.h into hardware.h

Signed-off-by: Bo Shen <voice.shen at atmel.com>
---
 arch/arm/mach-at91/include/mach/hardware.h |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-at91/include/mach/hardware.h b/arch/arm/mach-at91/include/mach/hardware.h
index a832e07..f17aa31 100644
--- a/arch/arm/mach-at91/include/mach/hardware.h
+++ b/arch/arm/mach-at91/include/mach/hardware.h
@@ -33,6 +33,7 @@
 #include <mach/at91sam9g45.h>
 #include <mach/at91sam9x5.h>
 #include <mach/at91sam9n12.h>
+#include <mach/sama5d3.h>
 
 /*
  * On all at91 except rm9200 and x40 have the System Controller starts
-- 
1.7.9.5



From voice.shen at atmel.com  Thu Jul  4 03:16:41 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu,  4 Jul 2013 15:16:41 +0800
Subject: [PATCH 3/4] arm: atmel: sama5: enable kernel uncompress info output
In-Reply-To: <1372922202-28606-1-git-send-email-voice.shen@atmel.com>
References: <1372922202-28606-1-git-send-email-voice.shen@atmel.com>
Message-ID: <1372922202-28606-4-git-send-email-voice.shen@atmel.com>

enable kernel uncompress info output, which will show as following:
---8>---
Uncompressing Linux... done, booting the kernel.
---<8---

Signed-off-by: Bo Shen <voice.shen at atmel.com>
---
 arch/arm/mach-at91/include/mach/uncompress.h |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-at91/include/mach/uncompress.h b/arch/arm/mach-at91/include/mach/uncompress.h
index 5659f7c..fe097e6 100644
--- a/arch/arm/mach-at91/include/mach/uncompress.h
+++ b/arch/arm/mach-at91/include/mach/uncompress.h
@@ -94,6 +94,15 @@ static const u32 uarts_sam9x5[] = {
 	0,
 };
 
+static const u32 uarts_sama5[] = {
+	AT91_BASE_DBGU1,
+	SAMA5D3_BASE_USART0,
+	SAMA5D3_BASE_USART1,
+	SAMA5D3_BASE_USART2,
+	SAMA5D3_BASE_USART3,
+	0,
+};
+
 static inline const u32* decomp_soc_detect(void __iomem *dbgu_base)
 {
 	u32 cidr, socid;
@@ -123,6 +132,9 @@ static inline const u32* decomp_soc_detect(void __iomem *dbgu_base)
 
 	case ARCH_ID_AT91SAM9X5:
 		return uarts_sam9x5;
+
+	case ARCH_ID_SAMA5D3:
+		return uarts_sama5;
 	}
 
 	/* at91sam9g10 */
-- 
1.7.9.5



From voice.shen at atmel.com  Thu Jul  4 03:16:42 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu,  4 Jul 2013 15:16:42 +0800
Subject: [PATCH 4/4] arm: atmel: sam9n12: enable kernel uncompress info output
In-Reply-To: <1372922202-28606-1-git-send-email-voice.shen@atmel.com>
References: <1372922202-28606-1-git-send-email-voice.shen@atmel.com>
Message-ID: <1372922202-28606-5-git-send-email-voice.shen@atmel.com>

the sam9n12 use the same array usart as sam9x5, add it which will
enable output kernel uncompress info:
---8>---
Uncompressing Linux... done, booting the kernel.
---<8---

Signed-off-by: Bo Shen <voice.shen at atmel.com>

---
 arch/arm/mach-at91/include/mach/uncompress.h |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-at91/include/mach/uncompress.h b/arch/arm/mach-at91/include/mach/uncompress.h
index fe097e6..4bb644f 100644
--- a/arch/arm/mach-at91/include/mach/uncompress.h
+++ b/arch/arm/mach-at91/include/mach/uncompress.h
@@ -130,6 +130,7 @@ static inline const u32* decomp_soc_detect(void __iomem *dbgu_base)
 	case ARCH_ID_AT91SAM9RL64:
 		return uarts_sam9rl;
 
+	case ARCH_ID_AT91SAM9N12:
 	case ARCH_ID_AT91SAM9X5:
 		return uarts_sam9x5;
 
-- 
1.7.9.5



From shawn.guo at linaro.org  Thu Jul  4 03:23:45 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 4 Jul 2013 15:23:45 +0800
Subject: [PATCH v2 4/5] ARM: dts: imx6q: add dte pinctrl for uart2
In-Reply-To: <1372844557-3078-5-git-send-email-b32955@freescale.com>
References: <1372844557-3078-1-git-send-email-b32955@freescale.com>
 <1372844557-3078-5-git-send-email-b32955@freescale.com>
Message-ID: <20130704072344.GB11046@S2101-09.ap.freescale.net>

On Wed, Jul 03, 2013 at 05:42:36PM +0800, Huang Shijie wrote:
> In imx6q-arm2 board, the UART2 works in the dte mode.
> So add a pinctrl for it.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>
> ---
>  arch/arm/boot/dts/imx6q.dtsi |    9 +++++++++
>  1 files changed, 9 insertions(+), 0 deletions(-)

Since imx6q and imx6dl are pin-to-pin compatible, from now on I would
require the same pin group be added for these two SoC together, so that
we can enforce the same label name.

> 
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index 9a69891..8a518c6 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -266,6 +266,15 @@
>  							MX6Q_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
>  						>;
>  					};
> +
> +					pinctrl_uart2_dte: uart2grp-2 {
> +						fsl,pins = <
> +							MX6Q_PAD_EIM_D26__UART2_RX_DATA 0x1b0b1
> +							MX6Q_PAD_EIM_D27__UART2_TX_DATA 0x1b0b1
> +							MX6Q_PAD_EIM_D28__UART2_CTS_B	0x1b0b1
> +							MX6Q_PAD_EIM_D29__UART2_CTS_B	0x1b0b1

Why do you have two pads mux-ed on one function?

Shawn

> +						>;
> +					};
>  				};
>  
>  				uart4 {
> -- 
> 1.7.1
> 
> 



From voice.shen at atmel.com  Thu Jul  4 03:27:57 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu, 4 Jul 2013 15:27:57 +0800
Subject: [RFC PATCH] pwm: atmel-pwm: add pwm controller driver
In-Reply-To: <1371804355-8071-1-git-send-email-voice.shen@atmel.com>
References: <1371804355-8071-1-git-send-email-voice.shen@atmel.com>
Message-ID: <51D523FD.7040409@atmel.com>

Hi All,

On 6/21/2013 16:45, Bo Shen wrote:
> add atmel pwm controller driver based on PWM framework
>
> this is basic function implementation of pwm controller
> it can work with pwm based led and backlight
>
> Signed-off-by: Bo Shen <voice.shen at atmel.com>
> ---
>   .../devicetree/bindings/pwm/atmel-pwm.txt          |   19 ++
>   drivers/pwm/Kconfig                                |    9 +
>   drivers/pwm/Makefile                               |    1 +
>   drivers/pwm/pwm-atmel.c                            |  326 ++++++++++++++++++++
>   4 files changed, 355 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/pwm/atmel-pwm.txt
>   create mode 100644 drivers/pwm/pwm-atmel.c

Does this patch can be applied? If yes, I will send out the formal patch 
without RFC in subject. If no, please help review this patch and give 
your comments.

Thanks.

Best Regards,
Bo Shen

> diff --git a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
> new file mode 100644
> index 0000000..127fcdb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
> @@ -0,0 +1,19 @@
> +Atmel PWM controller
> +
> +Required properties:
> +  - compatible: should be one of:
> +    - "atmel,at91sam9rl-pwm"
> +    - "atmel,sama5-pwm"
> +  - reg: physical base address and length of the controller's registers
> +  - #pwm-cells: Should be 3.
> +    - The first cell specifies the per-chip index of the PWM to use
> +    - The second cell is the period in nanoseconds
> +    - The third cell is used to encode the polarity of PWM output
> +
> +Example:
> +
> +	pwm0: pwm at f8034000 {
> +		compatible = "atmel,at91sam9rl-pwm";
> +		reg = <0xf8034000 0x400>;
> +		#pwm-cells = <3>;
> +	};
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 115b644..70518c9 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -37,6 +37,15 @@ config PWM_AB8500
>   	  To compile this driver as a module, choose M here: the module
>   	  will be called pwm-ab8500.
>
> +config PWM_ATMEL
> +	tristate "Atmel PWM support"
> +	depends on ARCH_AT91
> +	help
> +	  Generic PWM framework driver for Atmel SoC.
> +
> +	  To compile this driver as a module, choose M here: the module
> +	  will be called pwm-atmel.
> +
>   config PWM_ATMEL_TCB
>   	tristate "Atmel TC Block PWM support"
>   	depends on ATMEL_TCLIB && OF
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 94ba21e..a905a52 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -1,5 +1,6 @@
>   obj-$(CONFIG_PWM)		+= core.o
>   obj-$(CONFIG_PWM_AB8500)	+= pwm-ab8500.o
> +obj-$(CONFIG_PWM_ATMEL)		+= pwm-atmel.o
>   obj-$(CONFIG_PWM_ATMEL_TCB)	+= pwm-atmel-tcb.o
>   obj-$(CONFIG_PWM_BFIN)		+= pwm-bfin.o
>   obj-$(CONFIG_PWM_IMX)		+= pwm-imx.o
> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> new file mode 100644
> index 0000000..15ec4d5
> --- /dev/null
> +++ b/drivers/pwm/pwm-atmel.c
> @@ -0,0 +1,326 @@
> +/*
> + * Driver for Atmel Pulse Width Modulation Controller
> + *
> + * Copyright (C) 2013 Atmel Semiconductor Technology Ltd.
> + *
> + * GPL v2 or later
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/pinctrl/consumer.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +#include <linux/slab.h>
> +
> +#define PWM_MR		0x00
> +#define PWM_ENA		0x04
> +#define PWM_DIS		0x08
> +#define PWM_SR		0x0C
> +
> +#define PWM_CMR		0x00
> +
> +/* The following register for PWM v1 */
> +#define PWMv1_CDTY	0x04
> +#define PWMv1_CPRD	0x08
> +#define PWMv1_CUPD	0x10
> +
> +/* The following register for PWM v2 */
> +#define PWMv2_CDTY	0x04
> +#define PWMv2_CDTYUPD	0x08
> +#define PWMv2_CPRD	0x0C
> +#define PWMv2_CPRDUPD	0x10
> +
> +#define PWM_NUM		4
> +
> +struct atmel_pwm_chip {
> +	struct pwm_chip chip;
> +	struct clk *clk;
> +	void __iomem *base;
> +
> +	void (*config)(struct atmel_pwm_chip *chip, struct pwm_device *pwm,
> +			unsigned int dty, unsigned int prd);
> +};
> +
> +#define to_atmel_pwm_chip(chip) container_of(chip, struct atmel_pwm_chip, chip)
> +
> +static inline u32 atmel_pwm_readl(struct atmel_pwm_chip *chip, int offset)
> +{
> +	return readl(chip->base + offset);
> +}
> +
> +static inline void atmel_pwm_writel(struct atmel_pwm_chip *chip, int offset,
> +		u32 val)
> +{
> +	writel(val, chip->base + offset);
> +}
> +
> +static inline u32 atmel_pwm_ch_readl(struct atmel_pwm_chip *chip, int ch,
> +		int offset)
> +{
> +	return readl(chip->base + 0x200 + ch * 0x20 + offset);
> +}
> +
> +static inline void atmel_pwm_ch_writel(struct atmel_pwm_chip *chip, int ch,
> +		int offset, u32 val)
> +{
> +	writel(val, chip->base + 0x200 + ch * 0x20 + offset);
> +}
> +
> +static int atmel_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> +		int duty_ns, int period_ns)
> +{
> +	struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
> +	unsigned long long val, prd, dty;
> +	unsigned long long div, clk_rate;
> +	int ret, pres = 0;
> +
> +	clk_rate = clk_get_rate(atmel_pwm->clk);
> +
> +	while (1) {
> +		div = 1000000000;
> +		div *= 1 << pres;
> +		val = clk_rate * period_ns;
> +		prd = div_u64(val, div);
> +		val = clk_rate * duty_ns;
> +		dty = div_u64(val, div);
> +
> +		if (prd < 0x0001 || dty < 0x0)
> +			return -EINVAL;
> +
> +		if (prd > 0xffff || dty > 0xffff) {
> +			if (++pres > 0x10)
> +				return -EINVAL;
> +			continue;
> +		}
> +
> +		break;
> +	}
> +
> +	/* Enable clock */
> +	ret = clk_prepare_enable(atmel_pwm->clk);
> +	if (ret) {
> +		pr_err("failed to enable pwm clock\n");
> +		return ret;
> +	}
> +
> +	atmel_pwm->config(atmel_pwm, pwm, dty, prd);
> +
> +	/* Check whether need to disable clock */
> +	val = atmel_pwm_readl(atmel_pwm, PWM_SR);
> +	if ((val & 0xf) == 0)
> +		clk_disable_unprepare(atmel_pwm->clk);
> +
> +	return 0;
> +}
> +
> +static void atmel_pwm_config_v1(struct atmel_pwm_chip *atmel_pwm,
> +		struct pwm_device *pwm, unsigned int dty, unsigned int prd)
> +{
> +	unsigned int val;
> +
> +	/*
> +	 * if the pwm channel is enabled, using update register to update
> +	 * related register value, or else write it directly
> +	 */
> +	if (test_bit(PWMF_ENABLED, &pwm->flags)) {
> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMv1_CUPD, dty);
> +
> +		val = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm, PWM_CMR);
> +		val &= ~(1 << 10);
> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWM_CMR, val);
> +	} else {
> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMv1_CDTY, dty);
> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMv1_CPRD, prd);
> +	}
> +}
> +
> +static void atmel_pwm_config_v2(struct atmel_pwm_chip *atmel_pwm,
> +		struct pwm_device *pwm, unsigned int dty, unsigned int prd)
> +{
> +	/*
> +	 * if the pwm channel is enabled, using update register to update
> +	 * related register value, or else write it directly
> +	 */
> +	if (test_bit(PWMF_ENABLED, &pwm->flags)) {
> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMv2_CDTYUPD, dty);
> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMv2_CPRDUPD, prd);
> +	} else {
> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMv2_CDTY, dty);
> +		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWMv2_CPRD, prd);
> +	}
> +}
> +
> +static int atmel_pwm_set_polarity(struct pwm_chip *chip, struct pwm_device *pwm,
> +		enum pwm_polarity polarity)
> +{
> +	struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
> +	u32 val = 0;
> +	int ret;
> +
> +	/* Enable clock */
> +	ret = clk_prepare_enable(atmel_pwm->clk);
> +	if (ret) {
> +		pr_err("failed to enable pwm clock\n");
> +		return ret;
> +	}
> +
> +	if (polarity == PWM_POLARITY_NORMAL)
> +		val &= ~(1 << 9);
> +	else
> +		val |= 1 << 9;
> +
> +	atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWM_CMR, val);
> +
> +	/* Disable clock */
> +	clk_disable_unprepare(atmel_pwm->clk);
> +
> +	return 0;
> +}
> +
> +static int atmel_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> +	struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
> +
> +	clk_prepare_enable(atmel_pwm->clk);
> +
> +	atmel_pwm_writel(atmel_pwm, PWM_ENA, 1 << pwm->hwpwm);
> +
> +	return 0;
> +}
> +
> +static void atmel_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> +	struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
> +	u32 val;
> +
> +	atmel_pwm_writel(atmel_pwm, PWM_DIS, 1 << pwm->hwpwm);
> +
> +	/* Disable clock */
> +	val = atmel_pwm_readl(atmel_pwm, PWM_SR);
> +	if ((val & 0xf) == 0)
> +		clk_disable_unprepare(atmel_pwm->clk);
> +}
> +
> +static const struct pwm_ops atmel_pwm_ops = {
> +	.config = atmel_pwm_config,
> +	.set_polarity = atmel_pwm_set_polarity,
> +	.enable = atmel_pwm_enable,
> +	.disable = atmel_pwm_disable,
> +	.owner = THIS_MODULE,
> +};
> +
> +struct atmel_pwm_data {
> +	void (*config)(struct atmel_pwm_chip *chip, struct pwm_device *pwm,
> +			unsigned int dty, unsigned int prd);
> +};
> +
> +static struct atmel_pwm_data atmel_pwm_data_v1 = {
> +	.config = atmel_pwm_config_v1,
> +};
> +
> +static struct atmel_pwm_data atmel_pwm_data_v2 = {
> +	.config = atmel_pwm_config_v2,
> +};
> +
> +static const struct of_device_id atmel_pwm_dt_ids[] = {
> +	{
> +		.compatible = "atmel,at91sam9rl-pwm",
> +		.data = &atmel_pwm_data_v1,
> +	}, {
> +		.compatible = "atmel,sama5-pwm",
> +		.data = &atmel_pwm_data_v2,
> +	}, {
> +		/* sentinel */
> +	},
> +};
> +MODULE_DEVICE_TABLE(of, atmel_pwm_dt_ids);
> +
> +static int atmel_pwm_probe(struct platform_device *pdev)
> +{
> +	const struct of_device_id *of_id =
> +		of_match_device(atmel_pwm_dt_ids, &pdev->dev);
> +	const struct atmel_pwm_data *data;
> +	struct atmel_pwm_chip *atmel_pwm;
> +	struct resource *res;
> +	struct pinctrl *pinctrl;
> +	int ret;
> +
> +	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> +	if (IS_ERR(pinctrl)) {
> +		dev_err(&pdev->dev, "failed get pinctrl\n");
> +		return PTR_ERR(pinctrl);
> +	}
> +
> +	atmel_pwm = devm_kzalloc(&pdev->dev, sizeof(*atmel_pwm), GFP_KERNEL);
> +	if (!atmel_pwm) {
> +		dev_err(&pdev->dev, "out of memory\n");
> +		return -ENOMEM;
> +	}
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res) {
> +		dev_err(&pdev->dev, "no memory resource defined\n");
> +		return -ENODEV;
> +	}
> +
> +	atmel_pwm->base = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(atmel_pwm->base)) {
> +		dev_err(&pdev->dev, "ioremap failed\n");
> +		return PTR_ERR(atmel_pwm->base);
> +	}
> +
> +	atmel_pwm->clk = devm_clk_get(&pdev->dev, "pwm_clk");
> +	if (IS_ERR(atmel_pwm->clk)) {
> +		dev_err(&pdev->dev, "clk get failed\n");
> +		return PTR_ERR(atmel_pwm->clk);
> +	}
> +
> +	atmel_pwm->chip.dev = &pdev->dev;
> +	atmel_pwm->chip.ops = &atmel_pwm_ops;
> +	atmel_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
> +	atmel_pwm->chip.of_pwm_n_cells = 3;
> +	atmel_pwm->chip.base = -1;
> +	atmel_pwm->chip.npwm = PWM_NUM;
> +
> +	data = of_id->data;
> +	atmel_pwm->config = data->config;
> +
> +	ret = pwmchip_add(&atmel_pwm->chip);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to add pwm chip %d\n", ret);
> +		return ret;
> +	}
> +
> +	platform_set_drvdata(pdev, atmel_pwm);
> +
> +	dev_info(&pdev->dev, "successfully register pwm\n");
> +
> +	return 0;
> +}
> +
> +static int atmel_pwm_remove(struct platform_device *pdev)
> +{
> +	struct atmel_pwm_chip *atmel_pwm = platform_get_drvdata(pdev);
> +
> +	return pwmchip_remove(&atmel_pwm->chip);
> +}
> +
> +static struct platform_driver atmel_pwm_driver = {
> +	.driver = {
> +		.name = "atmel-pwm",
> +		.of_match_table = of_match_ptr(atmel_pwm_dt_ids),
> +	},
> +	.probe = atmel_pwm_probe,
> +	.remove = atmel_pwm_remove,
> +};
> +module_platform_driver(atmel_pwm_driver);
> +
> +MODULE_ALIAS("platform:atmel-pwm");
> +MODULE_AUTHOR("Bo Shen <voice.shen at atmel.com>");
> +MODULE_DESCRIPTION("Atmel PWM driver");
> +MODULE_LICENSE("GPL v2");
>



From Baohua.Song at csr.com  Thu Jul  4 03:54:52 2013
From: Baohua.Song at csr.com (Barry Song)
Date: Thu, 4 Jul 2013 15:54:52 +0800
Subject: [PATCH 0/5] a bundle of minor fixes for CSR SiRF pinctrl drivers
Message-ID: <1372924492-5477-1-git-send-email-Baohua.Song@csr.com>

Hi Linus,
this patchset is againest for-next branch of your tree. i guess there will
be no conflict in 3.11-rc.

Barry Song (2):
  arm/dts: sirf: fix the pingroup name mismatch between drivers and dts
  pinctrl: sirf: add freeze and restore entries for hibernation support

Qipan Li (2):
  pinctrl: sirf: fix the pin number and mux bit for usp0
  pinctrl: sirf: add usp0_uart_nostreamctrl pin group for usp-uart
    without flowctrl

Rongjun Ying (1):
  pinctrl: sirf: fix the checkpatch issue about indentation

 arch/arm/boot/dts/atlas6.dtsi         | 22 ++++++++++++++--------
 arch/arm/boot/dts/prima2.dtsi         | 16 ++++++++--------
 drivers/pinctrl/sirf/pinctrl-atlas6.c | 24 ++++++++++++++++++++++--
 drivers/pinctrl/sirf/pinctrl-sirf.c   |  8 +++++---
 4 files changed, 49 insertions(+), 21 deletions(-)

-- 
1.8.2.3



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog


From Baohua.Song at csr.com  Thu Jul  4 03:55:25 2013
From: Baohua.Song at csr.com (Barry Song)
Date: Thu, 4 Jul 2013 15:55:25 +0800
Subject: [PATCH 1/5] pinctrl: sirf: fix the pin number and mux bit for usp0
Message-ID: <1372924529-5519-1-git-send-email-Baohua.Song@csr.com>

From: Qipan Li <Qipan.Li at csr.com>

we missed a pin and related mux bit for usp pin group, this
patch fixes it.

Signed-off-by: Qipan Li <Qipan.Li at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 drivers/pinctrl/sirf/pinctrl-atlas6.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/sirf/pinctrl-atlas6.c b/drivers/pinctrl/sirf/pinctrl-atlas6.c
index 1fa39a4..c641be9 100644
--- a/drivers/pinctrl/sirf/pinctrl-atlas6.c
+++ b/drivers/pinctrl/sirf/pinctrl-atlas6.c
@@ -496,7 +496,7 @@ static const unsigned sdmmc5_pins[] = { 24, 25, 26 };
 static const struct sirfsoc_muxmask usp0_muxmask[] = {
 	{
 		.group = 1,
-		.mask = BIT(19) | BIT(20) | BIT(21) | BIT(22),
+		.mask = BIT(19) | BIT(20) | BIT(21) | BIT(22) | BIT(23),
 	},
 };
 
@@ -507,7 +507,7 @@ static const struct sirfsoc_padmux usp0_padmux = {
 	.funcval = 0,
 };
 
-static const unsigned usp0_pins[] = { 51, 52, 53, 54 };
+static const unsigned usp0_pins[] = { 51, 52, 53, 54, 55 };
 
 static const struct sirfsoc_muxmask usp1_muxmask[] = {
 	{
-- 
1.8.2.3



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog


From Baohua.Song at csr.com  Thu Jul  4 03:55:26 2013
From: Baohua.Song at csr.com (Barry Song)
Date: Thu, 4 Jul 2013 15:55:26 +0800
Subject: [PATCH 2/5] pinctrl: sirf: add usp0_uart_nostreamctrl pin group for
 usp-uart without flowctrl
In-Reply-To: <1372924529-5519-1-git-send-email-Baohua.Song@csr.com>
References: <1372924529-5519-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <1372924529-5519-2-git-send-email-Baohua.Song@csr.com>

From: Qipan Li <Qipan.Li at csr.com>

this patch adds the lost pin group which supports to let USP0 to simulate
a UART without hardware flow control.

Signed-off-by: Qipan Li <Qipan.Li at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 arch/arm/boot/dts/atlas6.dtsi         |  6 ++++++
 drivers/pinctrl/sirf/pinctrl-atlas6.c | 20 ++++++++++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/atlas6.dtsi b/arch/arm/boot/dts/atlas6.dtsi
index 7d1a279..6e24ecf 100644
--- a/arch/arm/boot/dts/atlas6.dtsi
+++ b/arch/arm/boot/dts/atlas6.dtsi
@@ -485,6 +485,12 @@
                                                 sirf,function = "usp0";
                                         };
                                 };
+				usp0_uart_nostreamctrl_pins_a: usp0 at 1 {
+                                        usp0 {
+                                                sirf,pins = "usp0_uart_nostreamctrl_grp";
+                                                sirf,function = "usp0_uart_nostreamctrl";
+                                        };
+                                };
                                 usp1_pins_a: usp1 at 0 {
                                         usp1 {
                                                 sirf,pins = "usp1grp";
diff --git a/drivers/pinctrl/sirf/pinctrl-atlas6.c b/drivers/pinctrl/sirf/pinctrl-atlas6.c
index c641be9..867c968 100644
--- a/drivers/pinctrl/sirf/pinctrl-atlas6.c
+++ b/drivers/pinctrl/sirf/pinctrl-atlas6.c
@@ -509,6 +509,19 @@ static const struct sirfsoc_padmux usp0_padmux = {
 
 static const unsigned usp0_pins[] = { 51, 52, 53, 54, 55 };
 
+static const struct sirfsoc_muxmask usp0_uart_nostreamctrl_muxmask[] = {
+	{
+		.group = 1,
+		.mask = BIT(20) | BIT(21),
+	},
+};
+
+static const struct sirfsoc_padmux usp0_uart_nostreamctrl_padmux = {
+	.muxmask_counts = ARRAY_SIZE(usp0_uart_nostreamctrl_muxmask),
+	.muxmask = usp0_uart_nostreamctrl_muxmask,
+};
+
+static const unsigned usp0_uart_nostreamctrl_pins[] = { 52, 53 };
 static const struct sirfsoc_muxmask usp1_muxmask[] = {
 	{
 		.group = 0,
@@ -822,6 +835,8 @@ static const struct sirfsoc_pin_group sirfsoc_pin_groups[] = {
 	SIRFSOC_PIN_GROUP("uart2grp", uart2_pins),
 	SIRFSOC_PIN_GROUP("uart2_nostreamctrlgrp", uart2_nostreamctrl_pins),
 	SIRFSOC_PIN_GROUP("usp0grp", usp0_pins),
+	SIRFSOC_PIN_GROUP("usp0_uart_nostreamctrl_grp",
+					usp0_uart_nostreamctrl_pins),
 	SIRFSOC_PIN_GROUP("usp1grp", usp1_pins),
 	SIRFSOC_PIN_GROUP("i2c0grp", i2c0_pins),
 	SIRFSOC_PIN_GROUP("i2c1grp", i2c1_pins),
@@ -862,6 +877,8 @@ static const char * const uart0grp[] = { "uart0grp" };
 static const char * const uart1grp[] = { "uart1grp" };
 static const char * const uart2grp[] = { "uart2grp" };
 static const char * const uart2_nostreamctrlgrp[] = { "uart2_nostreamctrlgrp" };
+static const char * const usp0_uart_nostreamctrl_grp[] = {
+					"usp0_uart_nostreamctrl_grp" };
 static const char * const usp0grp[] = { "usp0grp" };
 static const char * const usp1grp[] = { "usp1grp" };
 static const char * const i2c0grp[] = { "i2c0grp" };
@@ -904,6 +921,9 @@ static const struct sirfsoc_pmx_func sirfsoc_pmx_functions[] = {
 	SIRFSOC_PMX_FUNCTION("uart2", uart2grp, uart2_padmux),
 	SIRFSOC_PMX_FUNCTION("uart2_nostreamctrl", uart2_nostreamctrlgrp, uart2_nostreamctrl_padmux),
 	SIRFSOC_PMX_FUNCTION("usp0", usp0grp, usp0_padmux),
+	SIRFSOC_PMX_FUNCTION("usp0_uart_nostreamctrl",
+						usp0_uart_nostreamctrl_grp,
+						usp0_uart_nostreamctrl_padmux),
 	SIRFSOC_PMX_FUNCTION("usp1", usp1grp, usp1_padmux),
 	SIRFSOC_PMX_FUNCTION("i2c0", i2c0grp, i2c0_padmux),
 	SIRFSOC_PMX_FUNCTION("i2c1", i2c1grp, i2c1_padmux),
-- 
1.8.2.3



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog


From Baohua.Song at csr.com  Thu Jul  4 03:55:27 2013
From: Baohua.Song at csr.com (Barry Song)
Date: Thu, 4 Jul 2013 15:55:27 +0800
Subject: [PATCH 3/5] arm/dts: sirf: fix the pingroup name mismatch between
 drivers and dts
In-Reply-To: <1372924529-5519-1-git-send-email-Baohua.Song@csr.com>
References: <1372924529-5519-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <1372924529-5519-3-git-send-email-Baohua.Song@csr.com>

in drivers/pinctrl/sirf, pingroup name is cko0 and cko1, but in dts, they
are cko0 and cko1_rst. this patch fixes the error in dts.

Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 arch/arm/boot/dts/atlas6.dtsi | 16 ++++++++--------
 arch/arm/boot/dts/prima2.dtsi | 16 ++++++++--------
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/atlas6.dtsi b/arch/arm/boot/dts/atlas6.dtsi
index 6e24ecf..ab1183b 100644
--- a/arch/arm/boot/dts/atlas6.dtsi
+++ b/arch/arm/boot/dts/atlas6.dtsi
@@ -521,16 +521,16 @@
                                                 sirf,function = "pulse_count";
                                         };
                                 };
-                                cko0_rst_pins_a: cko0_rst at 0 {
-                                        cko0_rst {
-                                                sirf,pins = "cko0_rstgrp";
-                                                sirf,function = "cko0_rst";
+                                cko0_pins_a: cko0 at 0 {
+                                        cko0 {
+                                                sirf,pins = "cko0grp";
+                                                sirf,function = "cko0";
                                         };
                                 };
-                                cko1_rst_pins_a: cko1_rst at 0 {
-                                        cko1_rst {
-                                                sirf,pins = "cko1_rstgrp";
-                                                sirf,function = "cko1_rst";
+                                cko1_pins_a: cko1 at 0 {
+                                        cko1 {
+                                                sirf,pins = "cko1grp";
+                                                sirf,function = "cko1";
                                         };
                                 };
 			};
diff --git a/arch/arm/boot/dts/prima2.dtsi b/arch/arm/boot/dts/prima2.dtsi
index 3329719..ce0266c 100644
--- a/arch/arm/boot/dts/prima2.dtsi
+++ b/arch/arm/boot/dts/prima2.dtsi
@@ -513,16 +513,16 @@
                                                 sirf,function = "pulse_count";
                                         };
                                 };
-                                cko0_rst_pins_a: cko0_rst at 0 {
-                                        cko0_rst {
-                                                sirf,pins = "cko0_rstgrp";
-                                                sirf,function = "cko0_rst";
+                                cko0_pins_a: cko0 at 0 {
+                                        cko0 {
+                                                sirf,pins = "cko0grp";
+                                                sirf,function = "cko0";
                                         };
                                 };
-                                cko1_rst_pins_a: cko1_rst at 0 {
-                                        cko1_rst {
-                                                sirf,pins = "cko1_rstgrp";
-                                                sirf,function = "cko1_rst";
+                                cko1_pins_a: cko1 at 0 {
+                                        cko1 {
+                                                sirf,pins = "cko1grp";
+                                                sirf,function = "cko1";
                                         };
                                 };
 			};
-- 
1.8.2.3



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog


From Baohua.Song at csr.com  Thu Jul  4 03:55:28 2013
From: Baohua.Song at csr.com (Barry Song)
Date: Thu, 4 Jul 2013 15:55:28 +0800
Subject: [PATCH 4/5] pinctrl: sirf: fix the checkpatch issue about indentation
In-Reply-To: <1372924529-5519-1-git-send-email-Baohua.Song@csr.com>
References: <1372924529-5519-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <1372924529-5519-4-git-send-email-Baohua.Song@csr.com>

From: Rongjun Ying <Rongjun.Ying at csr.com>

Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 drivers/pinctrl/sirf/pinctrl-sirf.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/sirf/pinctrl-sirf.c b/drivers/pinctrl/sirf/pinctrl-sirf.c
index 0677e19..7186b46 100644
--- a/drivers/pinctrl/sirf/pinctrl-sirf.c
+++ b/drivers/pinctrl/sirf/pinctrl-sirf.c
@@ -306,13 +306,13 @@ static int sirfsoc_gpio_of_xlate(struct gpio_chip *gc,
        u32 *flags)
 {
        if (gpiospec->args[0] > SIRFSOC_GPIO_NO_OF_BANKS * SIRFSOC_GPIO_BANK_SIZE)
-               return -EINVAL;
+		return -EINVAL;
 
        if (gc != &sgpio_bank[gpiospec->args[0] / SIRFSOC_GPIO_BANK_SIZE].chip.gc)
-               return -EINVAL;
+		return -EINVAL;
 
        if (flags)
-               *flags = gpiospec->args[1];
+		*flags = gpiospec->args[1];
 
        return gpiospec->args[0] % SIRFSOC_GPIO_BANK_SIZE;
 }
-- 
1.8.2.3



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog


From Baohua.Song at csr.com  Thu Jul  4 03:59:53 2013
From: Baohua.Song at csr.com (Barry Song)
Date: Thu, 4 Jul 2013 15:59:53 +0800
Subject: [PATCH 5/5] pinctrl: sirf: add freeze and restore entries for
 hibernation support
Message-ID: <1372924793-5579-1-git-send-email-Baohua.Song@csr.com>

this patch adds hibernation entries so that the sirf platform can
support suspend-to-disk.

Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 drivers/pinctrl/sirf/pinctrl-sirf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pinctrl/sirf/pinctrl-sirf.c b/drivers/pinctrl/sirf/pinctrl-sirf.c
index 7186b46..0792e8d 100644
--- a/drivers/pinctrl/sirf/pinctrl-sirf.c
+++ b/drivers/pinctrl/sirf/pinctrl-sirf.c
@@ -440,6 +440,8 @@ static int sirfsoc_pinmux_resume_noirq(struct device *dev)
 static const struct dev_pm_ops sirfsoc_pinmux_pm_ops = {
 	.suspend_noirq = sirfsoc_pinmux_suspend_noirq,
 	.resume_noirq = sirfsoc_pinmux_resume_noirq,
+	.freeze_noirq = sirfsoc_pinmux_suspend_noirq,
+	.restore_noirq = sirfsoc_pinmux_resume_noirq,
 };
 #endif
 
-- 
1.8.2.3



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog


From ml at communistcode.co.uk  Thu Jul  4 04:31:14 2013
From: ml at communistcode.co.uk (Jack Mitchell)
Date: Thu, 04 Jul 2013 09:31:14 +0100
Subject: socfpga: mmc problems
In-Reply-To: <1372864190.9525.6.camel@linux-builds1>
References: <51D43CB0.4070104@communistcode.co.uk>
 <1372864190.9525.6.camel@linux-builds1>
Message-ID: <51D532D2.1030709@communistcode.co.uk>

Morning Dinh,

On 03/07/13 16:09, Dinh Nguyen wrote:
> Hi Jack,
>
> On Wed, 2013-07-03 at 16:01 +0100, Jack Mitchell wrote:
>> Having received one of the new Arrow SoCkit boards at a recent training
>> day I set about seeing how far mainline was in successfully booting this
>> board.
>>
>> As I wanted to boot from mmc, I first checked out linux-next [1] in
>> order to get the newly merged mmc driver, I then applied the device-tree
>> enablement series [2] on top before finally attempting to boot. I then
>> found that the standard socfpga_defconfig didn't enable the MMC drivers,
>> which I also did (should this be part of the socfpga_defconfig...?).
>
> I was going to update this when I enable ethernet as well to avoid less
> churn on the defconfig.

That's great!

>
>>
>> However, the boot hangs at:
>>
>> Synopsys Designware Multimedia Card Interface Driver
>> dwmmc_socfpga ff704000.dwmmc0: Using internal DMA controller.
>> dwmmc_socfpga ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host
>> data width, 1024 deep fifo
>>
>> To fix this I checked out the diff between the Altera vendor mmc driver
>> and the mainline driver and found that if I added this small change:
>>
>>
>>     if (of_property_read_u32(dev->of_node, "pwr-en", &pwr_en)) {
>>       dev_info(dev, "couldn't determine pwr-en, assuming pwr-en = 0\n");
>>       pwr_en = 0;
>>     }
>>
>>     /* Set PWREN bit */
>>     mci_writel(host, PWREN, pwr_en);
>
> I tested this on my devkit, which was not made by Arrow, but is _almost_
> the same. I'll try to see if I can get my hands on an Arrow board to
> reproduce.

Now, I think I made a _slight_ mistake, in that I accidentally copied 
the Altera vendor kernel onto the sdcard instead of the linux-next 
kernel. Re-testing this morning with a fresh mind, I checked the config 
again and now I find the Arrow board still won't boot from MMC, even 
with the above change, with the code hanging at the same place.

I know you don't have an Arrow board, but if you have a tree which I 
could pull from with your amalgamated changes; that would rule out me 
missing any patches and it actually being a board problem. I can't seem 
to see if the V8 device tree patches were pulled into anyones tree, 
otherwise I would just wait till they appeared in 3.11-rc1...?

Sorry for the confusion!

>
>>
>> In the dw_mci_socfpga_priv_init function, the board would boot.
>>
>> Synopsys Designware Multimedia Card Interface Driver
>> dwmmc_socfpga ff704000.dwmmc0: couldn't determine pwr-en, assuming
>> pwr-en = 0
>> dwmmc_socfpga ff704000.dwmmc0: Using internal DMA controller.
>> dwmmc_socfpga ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host
>> data width, 1024 deep fifo
>> mmc_host mmc0: Bus speed (slot 0) = 100000000Hz (slot req 400000Hz,
>> actual 400000HZ div = 125)
>> dwmmc_socfpga ff704000.dwmmc0: 1 slots initialized
>> dwmmc_socfpga ff704000.dwmmc0: Version ID is 240a
>> .....
>> .....
>> .....
>>
>>
>> Has this been overlooked, or are there some other changes elsewhere that
>> I haven't yet come across which addresses this?
>
> I'm not aware of any other changes.
>
> Dinh
>>
>> Cheers,
>>
>> [1] fa1383200d289afdff2f5678eb89483daa537465
>> [2] http://comments.gmane.org/gmane.linux.ports.arm.kernel/243529
>>
>
>
>


-- 

   Jack Mitchell (jack at embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--


From b32955 at freescale.com  Thu Jul  4 04:42:39 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Thu, 4 Jul 2013 16:42:39 +0800
Subject: [PATCH v2 4/5] ARM: dts: imx6q: add dte pinctrl for uart2
In-Reply-To: <20130704072344.GB11046@S2101-09.ap.freescale.net>
References: <1372844557-3078-1-git-send-email-b32955@freescale.com>
 <1372844557-3078-5-git-send-email-b32955@freescale.com>
 <20130704072344.GB11046@S2101-09.ap.freescale.net>
Message-ID: <51D5357F.8040609@freescale.com>

? 2013?07?04? 15:23, Shawn Guo ??:
> On Wed, Jul 03, 2013 at 05:42:36PM +0800, Huang Shijie wrote:
>> In imx6q-arm2 board, the UART2 works in the dte mode.
>> So add a pinctrl for it.
>>
>> Signed-off-by: Huang Shijie<b32955 at freescale.com>
>> ---
>>   arch/arm/boot/dts/imx6q.dtsi |    9 +++++++++
>>   1 files changed, 9 insertions(+), 0 deletions(-)
> Since imx6q and imx6dl are pin-to-pin compatible, from now on I would
> require the same pin group be added for these two SoC together, so that
> we can enforce the same label name.
>
I knew it.

But this pinctrl is only used in imx6q-arm2 board which uses a big 
armdillo board,
so i did not add the same label to imx6dl.

Do we have a imx6dl-arm2 board? if we have , i can add it.


>> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
>> index 9a69891..8a518c6 100644
>> --- a/arch/arm/boot/dts/imx6q.dtsi
>> +++ b/arch/arm/boot/dts/imx6q.dtsi
>> @@ -266,6 +266,15 @@
>>   							MX6Q_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
>>   						>;
>>   					};
>> +
>> +					pinctrl_uart2_dte: uart2grp-2 {
>> +						fsl,pins =<
>> +							MX6Q_PAD_EIM_D26__UART2_RX_DATA 0x1b0b1
>> +							MX6Q_PAD_EIM_D27__UART2_TX_DATA 0x1b0b1
>> +							MX6Q_PAD_EIM_D28__UART2_CTS_B	0x1b0b1
>> +							MX6Q_PAD_EIM_D29__UART2_CTS_B	0x1b0b1
> Why do you have two pads mux-ed on one function?
I think the name of the PAD is wrong.

thanks
Huang Shijie



From linux at arm.linux.org.uk  Thu Jul  4 04:35:20 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 4 Jul 2013 09:35:20 +0100
Subject: [PATCH V2] ARM: add missing __FINIT to head-common.S to match
 __INIT
In-Reply-To: <1372875174-26812-1-git-send-email-swarren@wwwdotorg.org>
References: <1372875174-26812-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130704083520.GI24642@n2100.arm.linux.org.uk>

On Wed, Jul 03, 2013 at 12:12:54PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> Macro __INIT is used to place various code in head-common.S into the init
> section. This should be matched by a closing __FINIT at the end of the
> code destined for the init section. Add this missing macro.
> 
> This historically caused no problem, because macro __CPUINIT was used at
> the exact location where __FINIT was missing, which then placed following
> code into the cpuinit section. However, with commit 22f0a2736 "init.h:
> remove __cpuinit sections from the kernel" applied, __CPUINIT becomes a
> no-op, thus leaving all this code in the init section, rather than the
> regular text section. This caused issues such as secondary CPU boot
> failures or crashes.
> 
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> Acked-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> ---
> v2: Moved __FINIT after lookup_processor_type, to correctly match the
> location of __CPUINIT.
> 
> Russell, I assume I should add this to the ARM patch tracker.

See the discussion I've had with Paul on this.  I disagree that adding
__FINIT "solves" the problem.  It just _changes_ the possibilities for
getting it wrong to a different set of possibilities.

__FINIT just swaps the current section with the one which was last in
use, which might be a fair way back up the file.  The problem is what
happens if someone changes the section before the __INIT without
checking the following code.

If we want to mark the end of the .init.text section, then __FINIT is
a good way to do that, but follow it with an explicit statement about
what section you want the following code to be in to ensure that it
is placed into the intended section irrespective of what future changes
occur.


From Baohua.Song at csr.com  Thu Jul  4 04:42:53 2013
From: Baohua.Song at csr.com (Barry Song)
Date: Thu, 4 Jul 2013 16:42:53 +0800
Subject: [PATCH] DMAEngine: sirf: let the users be able to pause and resume
 specific buffer
Message-ID: <1372927373-17407-1-git-send-email-Baohua.Song@csr.com>

From: Qipan Li <Qipan.Li at csr.com>

this patch adds a buffer_index in pause and resume entries, then users
can pause and resume a buffer they want, but don't pause the whole dma.

a typical application scenerios is Ping-Pang in two buffers:
at the beginning, we enable buf1 and buf2 to receive dma data, after
buf1 is full, we pause buf1 and handle the data in this buffer to avoid
overflow in buf1. but at the same time, dma is still tranferring in buf2.
once we have finished data process in buf1, we enable buf1 again.
this will maximize the chance of dma transferring. users pause buf1 by:
dmaengine_device_control(sirfport->rx_dma_chan, DMA_PAUSE, 1);
users pause buf2 by:
dmaengine_device_control(sirfport->rx_dma_chan, DMA_PAUSE, 2);
users can still pause the whole dma transferring by dmaengine_pause().

Signed-off-by: Qipan Li <Qipan.Li at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 drivers/dma/sirf-dma.c | 102 ++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 80 insertions(+), 22 deletions(-)

diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
index 1d627e2..7d500d2 100644
--- a/drivers/dma/sirf-dma.c
+++ b/drivers/dma/sirf-dma.c
@@ -315,43 +315,101 @@ static int sirfsoc_dma_terminate_all(struct sirfsoc_dma_chan *schan)
 	return 0;
 }
 
-static int sirfsoc_dma_pause_chan(struct sirfsoc_dma_chan *schan)
+static int sirfsoc_dma_pause_chan(struct sirfsoc_dma_chan *schan,
+						unsigned long buf_index)
 {
 	struct sirfsoc_dma *sdma = dma_chan_to_sirfsoc_dma(&schan->chan);
 	int cid = schan->chan.chan_id;
 	unsigned long flags;
+	unsigned long loop_ctrl_val;
 
 	spin_lock_irqsave(&schan->lock, flags);
-
-	if (!sdma->is_marco)
-		writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL)
-			& ~((1 << cid) | 1 << (cid + 16)),
-			sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
-	else
-		writel_relaxed((1 << cid) | 1 << (cid + 16),
-			sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL_CLR);
-
+	if (!sdma->is_marco) {
+		loop_ctrl_val = readl_relaxed(sdma->base +
+				SIRFSOC_DMA_CH_LOOP_CTRL);
+		switch (buf_index) {
+		case 1:
+			writel_relaxed(loop_ctrl_val & ~(1 << cid),
+					sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
+			break;
+		case 2:
+			writel_relaxed(loop_ctrl_val & ~(1 << (cid + 16)),
+					sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
+			break;
+		case 0:
+		default:
+			writel_relaxed(loop_ctrl_val &
+					~((1 << cid) | 1 << (cid + 16)),
+					sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
+			break;
+		}
+	} else {
+		switch (buf_index) {
+		case 1:
+			writel_relaxed((1 << cid), sdma->base +
+						SIRFSOC_DMA_CH_LOOP_CTRL_CLR);
+			break;
+		case 2:
+			writel_relaxed(1 << (cid + 16), sdma->base +
+						SIRFSOC_DMA_CH_LOOP_CTRL_CLR);
+			break;
+		case 0:
+		default:
+			writel_relaxed((1 << cid) | 1 << (cid + 16),
+				sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL_CLR);
+			break;
+		}
+	}
 	spin_unlock_irqrestore(&schan->lock, flags);
 
 	return 0;
 }
 
-static int sirfsoc_dma_resume_chan(struct sirfsoc_dma_chan *schan)
+static int sirfsoc_dma_resume_chan(struct sirfsoc_dma_chan *schan,
+						unsigned long buf_index)
 {
 	struct sirfsoc_dma *sdma = dma_chan_to_sirfsoc_dma(&schan->chan);
 	int cid = schan->chan.chan_id;
 	unsigned long flags;
+	unsigned long loop_ctrl_val;
 
 	spin_lock_irqsave(&schan->lock, flags);
-
-	if (!sdma->is_marco)
-		writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL)
-			| ((1 << cid) | 1 << (cid + 16)),
-			sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
-	else
-		writel_relaxed((1 << cid) | 1 << (cid + 16),
-			sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
-
+	if (!sdma->is_marco) {
+		loop_ctrl_val = readl_relaxed(sdma->base +
+				SIRFSOC_DMA_CH_LOOP_CTRL);
+		switch (buf_index) {
+		case 1:
+			writel_relaxed(loop_ctrl_val | (1 << cid),
+					sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
+			break;
+		case 2:
+			writel_relaxed(loop_ctrl_val | 1 << (cid + 16),
+					sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
+			break;
+		case 0:
+		default:
+			writel_relaxed(loop_ctrl_val | (1 << cid) |
+					1 << (cid + 16),
+					sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
+			break;
+		}
+	} else {
+		switch (buf_index) {
+		case 1:
+			writel_relaxed((1 << cid),
+					sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
+			break;
+		case 2:
+			writel_relaxed((1 << (cid + 16)),
+					sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
+			break;
+		case 0:
+		default:
+			writel_relaxed((1 << cid) | 1 << (cid + 16),
+					sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
+			break;
+		}
+	}
 	spin_unlock_irqrestore(&schan->lock, flags);
 
 	return 0;
@@ -365,9 +423,9 @@ static int sirfsoc_dma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
 
 	switch (cmd) {
 	case DMA_PAUSE:
-		return sirfsoc_dma_pause_chan(schan);
+		return sirfsoc_dma_pause_chan(schan, arg);
 	case DMA_RESUME:
-		return sirfsoc_dma_resume_chan(schan);
+		return sirfsoc_dma_resume_chan(schan, arg);
 	case DMA_TERMINATE_ALL:
 		return sirfsoc_dma_terminate_all(schan);
 	case DMA_SLAVE_CONFIG:
-- 
1.8.2.3



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog


From shawn.guo at linaro.org  Thu Jul  4 04:56:28 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 4 Jul 2013 16:56:28 +0800
Subject: [PATCH v2 4/5] ARM: dts: imx6q: add dte pinctrl for uart2
In-Reply-To: <51D5357F.8040609@freescale.com>
References: <1372844557-3078-1-git-send-email-b32955@freescale.com>
 <1372844557-3078-5-git-send-email-b32955@freescale.com>
 <20130704072344.GB11046@S2101-09.ap.freescale.net>
 <51D5357F.8040609@freescale.com>
Message-ID: <20130704085623.GA11209@S2101-09.ap.freescale.net>

On Thu, Jul 04, 2013 at 04:42:39PM +0800, Huang Shijie wrote:
> But this pinctrl is only used in imx6q-arm2 board which uses a big
> armdillo board,
> so i did not add the same label to imx6dl.
> 
> Do we have a imx6dl-arm2 board? if we have , i can add it.

It does not matter whether or not the pin group is used on an imx6dl
board.  We have to add it for both SoCs, because it's the only way to
keep use same label for same pin group on two SoCs.

> 
> >>diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> >>index 9a69891..8a518c6 100644
> >>--- a/arch/arm/boot/dts/imx6q.dtsi
> >>+++ b/arch/arm/boot/dts/imx6q.dtsi
> >>@@ -266,6 +266,15 @@
> >>  							MX6Q_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
> >>  						>;
> >>  					};
> >>+
> >>+					pinctrl_uart2_dte: uart2grp-2 {

Forgot mentioning that in imx dts we generally do not encode function
name like "dte" in the label but just number.

> >>+						fsl,pins =<
> >>+							MX6Q_PAD_EIM_D26__UART2_RX_DATA 0x1b0b1
> >>+							MX6Q_PAD_EIM_D27__UART2_TX_DATA 0x1b0b1
> >>+							MX6Q_PAD_EIM_D28__UART2_CTS_B	0x1b0b1
> >>+							MX6Q_PAD_EIM_D29__UART2_CTS_B	0x1b0b1
> >Why do you have two pads mux-ed on one function?
> I think the name of the PAD is wrong.

Fix the name first, then.

Shawn



From broonie at kernel.org  Thu Jul  4 05:00:49 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 4 Jul 2013 10:00:49 +0100
Subject: SPI : DUAL/QUAD support
In-Reply-To: <CAHSAbzMGqQgCLL9ymQ6qSeJRybv2jJfm-sbzZVgayVyKYgufLQ@mail.gmail.com>
References: <CAHSAbzMGqQgCLL9ymQ6qSeJRybv2jJfm-sbzZVgayVyKYgufLQ@mail.gmail.com>
Message-ID: <20130704090049.GJ27646@sirena.org.uk>

On Thu, Jul 04, 2013 at 03:07:31PM +0800, ??? wrote:

> Now some SPI controllers and Slave Devices have supported
> DUAL and QUAD transfer mode. But SPI controller driver in kernel
> has no member to deliver this information from Slave to Master.
> So in my opinion, adding transfer mode members to deal with the problem.

You'll need to tell us what "DUAL" and "QUAD" modes are and provide some
kerneldoc for the new fields.
-------------- 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/20130704/6b1f6dc6/attachment.sig>

From b32955 at freescale.com  Thu Jul  4 05:06:37 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Thu, 4 Jul 2013 17:06:37 +0800
Subject: [PATCH v2 4/5] ARM: dts: imx6q: add dte pinctrl for uart2
In-Reply-To: <20130704085623.GA11209@S2101-09.ap.freescale.net>
References: <1372844557-3078-1-git-send-email-b32955@freescale.com>
 <1372844557-3078-5-git-send-email-b32955@freescale.com>
 <20130704072344.GB11046@S2101-09.ap.freescale.net>
 <51D5357F.8040609@freescale.com>
 <20130704085623.GA11209@S2101-09.ap.freescale.net>
Message-ID: <51D53B1D.6000404@freescale.com>

? 2013?07?04? 16:56, Shawn Guo ??:
> On Thu, Jul 04, 2013 at 04:42:39PM +0800, Huang Shijie wrote:
>> But this pinctrl is only used in imx6q-arm2 board which uses a big
>> armdillo board,
>> so i did not add the same label to imx6dl.
>>
>> Do we have a imx6dl-arm2 board? if we have , i can add it.
> It does not matter whether or not the pin group is used on an imx6dl
> board.  We have to add it for both SoCs, because it's the only way to
> keep use same label for same pin group on two SoCs.
>
>>>> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
>>>> index 9a69891..8a518c6 100644
>>>> --- a/arch/arm/boot/dts/imx6q.dtsi
>>>> +++ b/arch/arm/boot/dts/imx6q.dtsi
>>>> @@ -266,6 +266,15 @@
>>>>   							MX6Q_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
>>>>   						>;
>>>>   					};
>>>> +
>>>> +					pinctrl_uart2_dte: uart2grp-2 {
> Forgot mentioning that in imx dts we generally do not encode function
> name like "dte" in the label but just number.
>
>>>> +						fsl,pins =<
>>>> +							MX6Q_PAD_EIM_D26__UART2_RX_DATA 0x1b0b1
>>>> +							MX6Q_PAD_EIM_D27__UART2_TX_DATA 0x1b0b1
>>>> +							MX6Q_PAD_EIM_D28__UART2_CTS_B	0x1b0b1
>>>> +							MX6Q_PAD_EIM_D29__UART2_CTS_B	0x1b0b1
>>> Why do you have two pads mux-ed on one function?
>> I think the name of the PAD is wrong.
> Fix the name first, then.
ok.

i will fix them in the next version.


thanks
Huang Shijie



From lars at metafoo.de  Thu Jul  4 05:08:02 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Thu, 04 Jul 2013 11:08:02 +0200
Subject: [PATCHv3 1/3] iio: Add Nuvoton NAU7802 ADC driver
In-Reply-To: <1372094699-3832-2-git-send-email-alexandre.belloni@free-electrons.com>
References: <1372094699-3832-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1372094699-3832-2-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <51D53B72.6020309@metafoo.de>

On 06/24/2013 07:24 PM, Alexandre Belloni wrote:
> The Nuvoton NAU7802 ADC is a 24-bit 2-channels I2C ADC, with adjustable
> gain and sampling rates.
> 
> Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Reviewed-by: Lars-Peter Clausen <lars at metafoo.de>

One remark though. Multiline comments should be like

/*
 * foo
 * bar
 */

not

/* foo
 * bar
 */

But not need to resend the patch just for this

- Lars


From wni at nvidia.com  Thu Jul  4 05:09:39 2013
From: wni at nvidia.com (Wei Ni)
Date: Thu, 4 Jul 2013 17:09:39 +0800
Subject: [PATCH 2/2] ARM: dt: t114 dalmore: add dt entry for lm90
In-Reply-To: <1372928979-26938-1-git-send-email-wni@nvidia.com>
References: <1372928979-26938-1-git-send-email-wni@nvidia.com>
Message-ID: <1372928979-26938-3-git-send-email-wni@nvidia.com>

Enable thermal sensor lm90 for t114 dalmore.

Signed-off-by: Wei Ni <wni at nvidia.com>
---
 arch/arm/boot/dts/tegra114-dalmore.dts |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index cb640eb..8325797 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -738,6 +738,13 @@
 			realtek,ldo1-en-gpios =
 				<&gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
 		};
+
+		nct1008: nct1008 {
+			compatible = "lm90,nct1008";
+			reg = <0x4c>;
+			interrupt-parent = <&gpio>;
+			interrupts = <TEGRA_GPIO(O, 4) IRQ_TYPE_LEVEL_LOW>;
+		};
 	};
 
 	i2c at 7000d000 {
-- 
1.7.9.5



From wni at nvidia.com  Thu Jul  4 05:09:37 2013
From: wni at nvidia.com (Wei Ni)
Date: Thu, 4 Jul 2013 17:09:37 +0800
Subject: [PATCH 0/2] Enable lm90 in Tegra30 and Tegra114.
Message-ID: <1372928979-26938-1-git-send-email-wni@nvidia.com>

Enable thermal sensor lm90 for Tegra30 Cardhu and Tegra114 Dalmore.

This series is v1, based on [RFC 1/9] submitted here:
http://thread.gmane.org/gmane.linux.power-management.general/31056

Changes from RFC:
1. Enable it for Tegra114 Dalmore.

Wei Ni (2):
  ARM: dt: t30 cardhu: add dt entry for lm90
  ARM: dt: t114 dalmore: add dt entry for lm90

 arch/arm/boot/dts/tegra114-dalmore.dts |    7 +++++++
 arch/arm/boot/dts/tegra30-cardhu.dtsi  |    7 +++++++
 2 files changed, 14 insertions(+)

-- 
1.7.9.5



From wni at nvidia.com  Thu Jul  4 05:09:38 2013
From: wni at nvidia.com (Wei Ni)
Date: Thu, 4 Jul 2013 17:09:38 +0800
Subject: [PATCH 1/2] ARM: dt: t30 cardhu: add dt entry for lm90
In-Reply-To: <1372928979-26938-1-git-send-email-wni@nvidia.com>
References: <1372928979-26938-1-git-send-email-wni@nvidia.com>
Message-ID: <1372928979-26938-2-git-send-email-wni@nvidia.com>

Enable thermal sensor lm90 for t30 cardhu.

Signed-off-by: Wei Ni <wni at nvidia.com>
---
 arch/arm/boot/dts/tegra30-cardhu.dtsi |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index f65b53d..8778c94 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -286,6 +286,13 @@
 				};
 			};
 		};
+
+		nct1008: nct1008 {
+			compatible = "lm90,nct1008";
+			reg = <0x4c>;
+			interrupt-parent = <&gpio>;
+			interrupts = <TEGRA_GPIO(CC, 2) IRQ_TYPE_LEVEL_LOW>;
+		};
 	};
 
 	spi at 7000da00 {
-- 
1.7.9.5



From satish.patel at ti.com  Thu Jul  4 05:21:57 2013
From: satish.patel at ti.com (Patel, Satish)
Date: Thu, 4 Jul 2013 09:21:57 +0000
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <20130703132038.GI15056@arwen.pp.htv.fi>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
 <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi>
Message-ID: <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com>

Hi,

> -----Original Message-----
> From: Balbi, Felipe
> Sent: Wednesday, July 03, 2013 6:51 PM
> To: ABRAHAM, KISHON VIJAY
> Cc: Patel, Satish; grant.likely at linaro.org; tony at atomide.com; Balbi,
> Felipe; arnd at arndb.de; swarren at nvidia.com;
> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> foundation.org; rob.herring at calxeda.com; rob at landley.net;
> linux at arm.linux.org.uk; benoit.cousson at linaro.org; mchehab at redhat.com;
> cesarb at cesarb.net; davem at davemloft.net; Nayak, Rajendra;
> shawn.guo at linaro.org; Shilimkar, Santosh; devicetree-
> discuss at lists.ozlabs.org; linux-doc at vger.kernel.org; Nori, Sekhar;
> Krishnamoorthy, Balaji T; Cherian, George
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> Hi,
> 
> On Wed, Jul 03, 2013 at 03:35:39PM +0530, Kishon Vijay Abraham I
> wrote:
> > On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote:
> > >Hi Kishon,
> > >
> > >>-----Original Message-----
> > >>From: ABRAHAM, KISHON VIJAY
> > >>Sent: Wednesday, June 26, 2013 5:17 PM
> > >>To: grant.likely at linaro.org; tony at atomide.com; Balbi, Felipe;
> ABRAHAM,
> > >>KISHON VIJAY; arnd at arndb.de; swarren at nvidia.com;
> > >>sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
> > >>omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> > >>usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> > >>foundation.org
> > >>Cc: rob.herring at calxeda.com; rob at landley.net;
> linux at arm.linux.org.uk;
> > >>benoit.cousson at linaro.org; mchehab at redhat.com; cesarb at cesarb.net;
> > >>davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org;
> Shilimkar,
> > >>Santosh; devicetree-discuss at lists.ozlabs.org; linux-
> > >>doc at vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T;
> Cherian,
> > >>George
> > >>Subject: [PATCH v9 0/8] Generic PHY Framework
> > >>
> > >>Added a generic PHY framework that provides a set of APIs for the
> PHY
> > >>drivers
> > >>to create/destroy a PHY and APIs for the PHY users to obtain a
> > >>reference to
> > >>the PHY with or without using phandle.
> > >>
> > >>This framework will be of use only to devices that uses external
> PHY
> > >>(PHY
> > >>functionality is not embedded within the controller).
> > >>
> > >>The intention of creating this framework is to bring the phy
> drivers
> > >>spread
> > >>all over the Linux kernel to drivers/phy to increase code re-use
> and
> > >>to
> > >>increase code maintainability.
> > >
> > >I would like to use this framework for a smart-card controller
> connected to a
> > >smart-card phy. I have some questions and would like to get
> feedback on the same.
> >
> > glad to know that :-)
> > >
> > >I am using ?TDA8026" Smartcard PHY from NXP. Here is the link for
> datasheet
> > >and app note for the same. The smart card controller is inside the
> TI SoC
> > >I am working with.
> > >
> > >Datasheet :
> > >www.nxp.com/documents/data_sheet/TDA8026.pdf?
> > >
> > >Appnote :
> > >http://www.nxp.com/documents/application_note/AN10724.pdf
> > >
> > >The TI SoC details are not public (yet). I can provide details to
> you offline.
> > >
> > >Brief about operation:
> > >-	The controller can work with and without a PHY
> > >-	When not using PHY, it is limited to talking to a single
> > >	smart card. There is also a need to put external de-activation
> logic
> > >	on card removal for this case.
> > >-	With a PHY you can use more than one smart card.
> > >-	Phy has 5 slots :  1 for smart card (credit/debit/other card
> with chip)
> > >       and others for SAM ? SIM like modules
> > >- 	Once the PHY is initialized, there are some operations that the
> controller
> > >	can request of the PHY like:
> > >	- Card configurations  - set voltage
> > >	- Activation of card
> > >	- ATR ? Answer to reset
> > >	- Warm reset
> > >	- ADPU exchange
> > >	- Deactivation ( Normal/Emergency)
> >
> > hmm.. We should think about extending the phy_ops to include these
> > operations (something like phy_smart_card_ops so that other
> > smart_card PHYs will also be able to use it).
> 
> let's try to avoid use-case specific additions. set_voltage sounds
> like
> a regulator thing, but the regulator is controlled through the PHY. I
> guess it makes sense to have a generic phy_set_voltage() call since
> even
> USB can make use of that.
> 
> For card activation, it sounds like phy_init()/phy_shutdown() would
> cover it.
> 
> For warm reset perhaps a phy_reset() callback ? Although that could,
> easily, get abused.
> 
> For deactivation, that's phy_shutdown().
> 
> ATR and ADPU needs more thought, I guess.
> 
> > >- 	In the mode when smartcard controller talks directly to the
> card without the need
> > >	for a PHY, all the above operations will be carried out by the
> controller itself
> > >
> > >My current thought process is to make the controller driver provide
> the user interface
> > >and talk to the PHY using the generic PHY framework you proposed.
> In the case where there
> > >is no PHY, my idea is to create a "dummy" PHY which uses the
> controller functionality itself.
> >
> > right. And in the case where you actually have a PHY, create a PHY
> > driver and implement the phy_smart_card_ops and register with the
> PHY
> > framework.
> 
> I would try to avoid that. Otherwise we will have phy_usb_ops,
> phy_sata_ops, phy_network_ops, phy_pci_ops, etc etc etc. It would
> easily
> blow up.
> 

- I do agree with you. Creating Phy specific ops will blow up whole 
  concept of generic phy f/w.
- Can we have interface like phy_setconfig - with parameter like 
  phy_setconfig(int param, void *value)
	- Here param can be enum of available config parameters for 
	  specific phy. 
Phy can perform different operation/set internal state based on 
param selection and value passed by.
	
e.x in case of smartcard
	enum set_config {
		SET_VOLATAGE,
		SET_ACTIVATE,
		SET_WARMRESET,
		SET_ATR,
		SET_DEACTIVE,
		....
	};

- Also, can have similar interface phy_getconfig to know current phy state.



> --
> balbi

From will.deacon at arm.com  Thu Jul  4 05:45:16 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 4 Jul 2013 10:45:16 +0100
Subject: ARM Cortex A9: LL counters
In-Reply-To: <BFCB49997E59134AAAF17FFE77F8FF06673738BC@REXMD.intranet.epfl.ch>
References: <BFCB49997E59134AAAF17FFE77F8FF06673738BC@REXMD.intranet.epfl.ch>
Message-ID: <20130704094516.GC8782@mudshark.cambridge.arm.com>

On Wed, Jul 03, 2013 at 07:59:14PM +0100, Javier Picorel wrote:
> Dear all,

Hello Javier,

> It seems that there is no mapping between any ARM Cortex A9 counter to the L2 (Last Level) access or misses event.

The L2 cache on Cortex-A9 is external to the CPU core and has its own set of
memory-mapped performance counters. Mark Rutland [CC'd] had something
working for this, but I haven't seen a refresh of the patches for a while.

> Looking at ARM's reference manual and OProfile's event list on A9, I see the following two counters:
> 
> CO_LF_MISS: (counter: 1, 2, 3, 4, 5, 6)
>         Number of coherent linefill requests which miss in all other CPUs, meaning that the request
>         is sent to external memory (min count: 500)
> CO_LF_HIT: (counter: 1, 2, 3, 4, 5, 6)
>         Number of coherent linefill requests which hit in another CPU, meaning that the linefill
>         data is fetched directly from the relevant cache (min count: 500)
> 
> It seems that the first counter refers to the L2 Misses and the second one to the L2 Hits (Last Level Cache in this architecture). I'm not sure
> whether we should do something about this or nor. Thanks!

No, these are all for L1. `sent to external memory' means sent to L2.

Will


From broonie at kernel.org  Thu Jul  4 05:45:07 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 4 Jul 2013 10:45:07 +0100
Subject: [alsa-devel] ASoC: wm8962: NULL pdata pointer
In-Reply-To: <20130704062913.GC14617@S2101-09.ap.freescale.net>
References: <20130704062913.GC14617@S2101-09.ap.freescale.net>
Message-ID: <20130704094507.GN27646@sirena.org.uk>

On Thu, Jul 04, 2013 at 02:29:14PM +0800, Shawn Guo wrote:
> Mark,
> 
> I'm running next-20130703 and seeing the following NULL pointer bug.

Please send a patch, and please send mail to this address which is the
one that's advertised and consistently used...
-------------- 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/20130704/328f0857/attachment.sig>

From kishon at ti.com  Thu Jul  4 05:55:32 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 4 Jul 2013 15:25:32 +0530
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
 <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com>
Message-ID: <51D54694.20203@ti.com>

On Thursday 04 July 2013 02:51 PM, Patel, Satish wrote:
> Hi,
>
>> -----Original Message-----
>> From: Balbi, Felipe
>> Sent: Wednesday, July 03, 2013 6:51 PM
>> To: ABRAHAM, KISHON VIJAY
>> Cc: Patel, Satish; grant.likely at linaro.org; tony at atomide.com; Balbi,
>> Felipe; arnd at arndb.de; swarren at nvidia.com;
>> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
>> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
>> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
>> foundation.org; rob.herring at calxeda.com; rob at landley.net;
>> linux at arm.linux.org.uk; benoit.cousson at linaro.org; mchehab at redhat.com;
>> cesarb at cesarb.net; davem at davemloft.net; Nayak, Rajendra;
>> shawn.guo at linaro.org; Shilimkar, Santosh; devicetree-
>> discuss at lists.ozlabs.org; linux-doc at vger.kernel.org; Nori, Sekhar;
>> Krishnamoorthy, Balaji T; Cherian, George
>> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
>>
>> Hi,
>>
>> On Wed, Jul 03, 2013 at 03:35:39PM +0530, Kishon Vijay Abraham I
>> wrote:
>>> On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote:
>>>> Hi Kishon,
>>>>
>>>>> -----Original Message-----
>>>>> From: ABRAHAM, KISHON VIJAY
>>>>> Sent: Wednesday, June 26, 2013 5:17 PM
>>>>> To: grant.likely at linaro.org; tony at atomide.com; Balbi, Felipe;
>> ABRAHAM,
>>>>> KISHON VIJAY; arnd at arndb.de; swarren at nvidia.com;
>>>>> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
>>>>> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
>>>>> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
>>>>> foundation.org
>>>>> Cc: rob.herring at calxeda.com; rob at landley.net;
>> linux at arm.linux.org.uk;
>>>>> benoit.cousson at linaro.org; mchehab at redhat.com; cesarb at cesarb.net;
>>>>> davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org;
>> Shilimkar,
>>>>> Santosh; devicetree-discuss at lists.ozlabs.org; linux-
>>>>> doc at vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T;
>> Cherian,
>>>>> George
>>>>> Subject: [PATCH v9 0/8] Generic PHY Framework
>>>>>
>>>>> Added a generic PHY framework that provides a set of APIs for the
>> PHY
>>>>> drivers
>>>>> to create/destroy a PHY and APIs for the PHY users to obtain a
>>>>> reference to
>>>>> the PHY with or without using phandle.
>>>>>
>>>>> This framework will be of use only to devices that uses external
>> PHY
>>>>> (PHY
>>>>> functionality is not embedded within the controller).
>>>>>
>>>>> The intention of creating this framework is to bring the phy
>> drivers
>>>>> spread
>>>>> all over the Linux kernel to drivers/phy to increase code re-use
>> and
>>>>> to
>>>>> increase code maintainability.
>>>>
>>>> I would like to use this framework for a smart-card controller
>> connected to a
>>>> smart-card phy. I have some questions and would like to get
>> feedback on the same.
>>>
>>> glad to know that :-)
>>>>
>>>> I am using ?TDA8026" Smartcard PHY from NXP. Here is the link for
>> datasheet
>>>> and app note for the same. The smart card controller is inside the
>> TI SoC
>>>> I am working with.
>>>>
>>>> Datasheet :
>>>> www.nxp.com/documents/data_sheet/TDA8026.pdf?
>>>>
>>>> Appnote :
>>>> http://www.nxp.com/documents/application_note/AN10724.pdf
>>>>
>>>> The TI SoC details are not public (yet). I can provide details to
>> you offline.
>>>>
>>>> Brief about operation:
>>>> -	The controller can work with and without a PHY
>>>> -	When not using PHY, it is limited to talking to a single
>>>> 	smart card. There is also a need to put external de-activation
>> logic
>>>> 	on card removal for this case.
>>>> -	With a PHY you can use more than one smart card.
>>>> -	Phy has 5 slots :  1 for smart card (credit/debit/other card
>> with chip)
>>>>        and others for SAM ? SIM like modules
>>>> - 	Once the PHY is initialized, there are some operations that the
>> controller
>>>> 	can request of the PHY like:
>>>> 	- Card configurations  - set voltage
>>>> 	- Activation of card
>>>> 	- ATR ? Answer to reset
>>>> 	- Warm reset
>>>> 	- ADPU exchange
>>>> 	- Deactivation ( Normal/Emergency)
>>>
>>> hmm.. We should think about extending the phy_ops to include these
>>> operations (something like phy_smart_card_ops so that other
>>> smart_card PHYs will also be able to use it).
>>
>> let's try to avoid use-case specific additions. set_voltage sounds
>> like
>> a regulator thing, but the regulator is controlled through the PHY. I
>> guess it makes sense to have a generic phy_set_voltage() call since
>> even
>> USB can make use of that.
>>
>> For card activation, it sounds like phy_init()/phy_shutdown() would
>> cover it.
>>
>> For warm reset perhaps a phy_reset() callback ? Although that could,
>> easily, get abused.
>>
>> For deactivation, that's phy_shutdown().
>>
>> ATR and ADPU needs more thought, I guess.
>>
>>>> - 	In the mode when smartcard controller talks directly to the
>> card without the need
>>>> 	for a PHY, all the above operations will be carried out by the
>> controller itself
>>>>
>>>> My current thought process is to make the controller driver provide
>> the user interface
>>>> and talk to the PHY using the generic PHY framework you proposed.
>> In the case where there
>>>> is no PHY, my idea is to create a "dummy" PHY which uses the
>> controller functionality itself.
>>>
>>> right. And in the case where you actually have a PHY, create a PHY
>>> driver and implement the phy_smart_card_ops and register with the
>> PHY
>>> framework.
>>
>> I would try to avoid that. Otherwise we will have phy_usb_ops,
>> phy_sata_ops, phy_network_ops, phy_pci_ops, etc etc etc. It would
>> easily
>> blow up.
>>
>
> - I do agree with you. Creating Phy specific ops will blow up whole
>    concept of generic phy f/w.
> - Can we have interface like phy_setconfig - with parameter like
>    phy_setconfig(int param, void *value)
> 	- Here param can be enum of available config parameters for
> 	  specific phy.
> Phy can perform different operation/set internal state based on
> param selection and value passed by.
> 	
> e.x in case of smartcard
> 	enum set_config {
> 		SET_VOLATAGE,
> 		SET_ACTIVATE,
> 		SET_WARMRESET,
> 		SET_ATR,
> 		SET_DEACTIVE,
> 		....
> 	};

hmm.. this looks similar to ioctl and can be abused easily IMO :s

-Kishon


From satish.patel at ti.com  Thu Jul  4 05:58:07 2013
From: satish.patel at ti.com (Patel, Satish)
Date: Thu, 4 Jul 2013 09:58:07 +0000
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <51D54694.20203@ti.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
 <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com>
 <51D54694.20203@ti.com>
Message-ID: <780E789C2E067A4BB8F69D0BB9EC4F253E975DB0@DBDE04.ent.ti.com>

Hi,

> -----Original Message-----
> From: ABRAHAM, KISHON VIJAY
> Sent: Thursday, July 04, 2013 3:26 PM
> To: Patel, Satish
> Cc: Balbi, Felipe; grant.likely at linaro.org; tony at atomide.com;
> arnd at arndb.de; swarren at nvidia.com; sylvester.nawrocki at gmail.com;
> linux-kernel at vger.kernel.org; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-usb at vger.kernel.org;
> gregkh at linuxfoundation.org; akpm at linux-foundation.org;
> rob.herring at calxeda.com; rob at landley.net; linux at arm.linux.org.uk;
> benoit.cousson at linaro.org; mchehab at redhat.com; cesarb at cesarb.net;
> davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org; Shilimkar,
> Santosh; devicetree-discuss at lists.ozlabs.org; linux-
> doc at vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T; Cherian,
> George; Mankad, Maulik Ojas
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> On Thursday 04 July 2013 02:51 PM, Patel, Satish wrote:
> > Hi,
> >
> >> -----Original Message-----
> >> From: Balbi, Felipe
> >> Sent: Wednesday, July 03, 2013 6:51 PM
> >> To: ABRAHAM, KISHON VIJAY
> >> Cc: Patel, Satish; grant.likely at linaro.org; tony at atomide.com;
> Balbi,
> >> Felipe; arnd at arndb.de; swarren at nvidia.com;
> >> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
> >> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> >> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> >> foundation.org; rob.herring at calxeda.com; rob at landley.net;
> >> linux at arm.linux.org.uk; benoit.cousson at linaro.org;
> mchehab at redhat.com;
> >> cesarb at cesarb.net; davem at davemloft.net; Nayak, Rajendra;
> >> shawn.guo at linaro.org; Shilimkar, Santosh; devicetree-
> >> discuss at lists.ozlabs.org; linux-doc at vger.kernel.org; Nori, Sekhar;
> >> Krishnamoorthy, Balaji T; Cherian, George
> >> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> >>
> >> Hi,
> >>
> >> On Wed, Jul 03, 2013 at 03:35:39PM +0530, Kishon Vijay Abraham I
> >> wrote:
> >>> On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote:
> >>>> Hi Kishon,
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: ABRAHAM, KISHON VIJAY
> >>>>> Sent: Wednesday, June 26, 2013 5:17 PM
> >>>>> To: grant.likely at linaro.org; tony at atomide.com; Balbi, Felipe;
> >> ABRAHAM,
> >>>>> KISHON VIJAY; arnd at arndb.de; swarren at nvidia.com;
> >>>>> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org;
> linux-
> >>>>> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-
> >>>>> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> >>>>> foundation.org
> >>>>> Cc: rob.herring at calxeda.com; rob at landley.net;
> >> linux at arm.linux.org.uk;
> >>>>> benoit.cousson at linaro.org; mchehab at redhat.com;
> cesarb at cesarb.net;
> >>>>> davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org;
> >> Shilimkar,
> >>>>> Santosh; devicetree-discuss at lists.ozlabs.org; linux-
> >>>>> doc at vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T;
> >> Cherian,
> >>>>> George
> >>>>> Subject: [PATCH v9 0/8] Generic PHY Framework
> >>>>>
> >>>>> Added a generic PHY framework that provides a set of APIs for
> the
> >> PHY
> >>>>> drivers
> >>>>> to create/destroy a PHY and APIs for the PHY users to obtain a
> >>>>> reference to
> >>>>> the PHY with or without using phandle.
> >>>>>
> >>>>> This framework will be of use only to devices that uses external
> >> PHY
> >>>>> (PHY
> >>>>> functionality is not embedded within the controller).
> >>>>>
> >>>>> The intention of creating this framework is to bring the phy
> >> drivers
> >>>>> spread
> >>>>> all over the Linux kernel to drivers/phy to increase code re-use
> >> and
> >>>>> to
> >>>>> increase code maintainability.
> >>>>
> >>>> I would like to use this framework for a smart-card controller
> >> connected to a
> >>>> smart-card phy. I have some questions and would like to get
> >> feedback on the same.
> >>>
> >>> glad to know that :-)
> >>>>
> >>>> I am using ?TDA8026" Smartcard PHY from NXP. Here is the link for
> >> datasheet
> >>>> and app note for the same. The smart card controller is inside
> the
> >> TI SoC
> >>>> I am working with.
> >>>>
> >>>> Datasheet :
> >>>> www.nxp.com/documents/data_sheet/TDA8026.pdf?
> >>>>
> >>>> Appnote :
> >>>> http://www.nxp.com/documents/application_note/AN10724.pdf
> >>>>
> >>>> The TI SoC details are not public (yet). I can provide details to
> >> you offline.
> >>>>
> >>>> Brief about operation:
> >>>> -	The controller can work with and without a PHY
> >>>> -	When not using PHY, it is limited to talking to a single
> >>>> 	smart card. There is also a need to put external de-activation
> >> logic
> >>>> 	on card removal for this case.
> >>>> -	With a PHY you can use more than one smart card.
> >>>> -	Phy has 5 slots :  1 for smart card (credit/debit/other card
> >> with chip)
> >>>>        and others for SAM ? SIM like modules
> >>>> - 	Once the PHY is initialized, there are some operations
> that the
> >> controller
> >>>> 	can request of the PHY like:
> >>>> 	- Card configurations  - set voltage
> >>>> 	- Activation of card
> >>>> 	- ATR ? Answer to reset
> >>>> 	- Warm reset
> >>>> 	- ADPU exchange
> >>>> 	- Deactivation ( Normal/Emergency)
> >>>
> >>> hmm.. We should think about extending the phy_ops to include these
> >>> operations (something like phy_smart_card_ops so that other
> >>> smart_card PHYs will also be able to use it).
> >>
> >> let's try to avoid use-case specific additions. set_voltage sounds
> >> like
> >> a regulator thing, but the regulator is controlled through the PHY.
> I
> >> guess it makes sense to have a generic phy_set_voltage() call since
> >> even
> >> USB can make use of that.
> >>
> >> For card activation, it sounds like phy_init()/phy_shutdown() would
> >> cover it.
> >>
> >> For warm reset perhaps a phy_reset() callback ? Although that
> could,
> >> easily, get abused.
> >>
> >> For deactivation, that's phy_shutdown().
> >>
> >> ATR and ADPU needs more thought, I guess.
> >>
> >>>> - 	In the mode when smartcard controller talks directly to
> the
> >> card without the need
> >>>> 	for a PHY, all the above operations will be carried out by the
> >> controller itself
> >>>>
> >>>> My current thought process is to make the controller driver
> provide
> >> the user interface
> >>>> and talk to the PHY using the generic PHY framework you proposed.
> >> In the case where there
> >>>> is no PHY, my idea is to create a "dummy" PHY which uses the
> >> controller functionality itself.
> >>>
> >>> right. And in the case where you actually have a PHY, create a PHY
> >>> driver and implement the phy_smart_card_ops and register with the
> >> PHY
> >>> framework.
> >>
> >> I would try to avoid that. Otherwise we will have phy_usb_ops,
> >> phy_sata_ops, phy_network_ops, phy_pci_ops, etc etc etc. It would
> >> easily
> >> blow up.
> >>
> >
> > - I do agree with you. Creating Phy specific ops will blow up whole
> >    concept of generic phy f/w.
> > - Can we have interface like phy_setconfig - with parameter like
> >    phy_setconfig(int param, void *value)
> > 	- Here param can be enum of available config parameters for
> > 	  specific phy.
> > Phy can perform different operation/set internal state based on
> > param selection and value passed by.
> >
> > e.x in case of smartcard
> > 	enum set_config {
> > 		SET_VOLATAGE,
> > 		SET_ACTIVATE,
> > 		SET_WARMRESET,
> > 		SET_ATR,
> > 		SET_DEACTIVE,
> > 		....
> > 	};
> 
> hmm.. this looks similar to ioctl and can be abused easily IMO :s
> 
what are your inputs to adapt multiple phys into generic phy f/w ?

> -Kishon

From balbi at ti.com  Thu Jul  4 06:12:16 2013
From: balbi at ti.com (Felipe Balbi)
Date: Thu, 4 Jul 2013 13:12:16 +0300
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <51D54694.20203@ti.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
 <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com>
 <51D54694.20203@ti.com>
Message-ID: <20130704101216.GD4830@arwen.pp.htv.fi>

On Thu, Jul 04, 2013 at 03:25:32PM +0530, Kishon Vijay Abraham I wrote:
> On Thursday 04 July 2013 02:51 PM, Patel, Satish wrote:
> >Hi,
> >
> >>-----Original Message-----
> >>From: Balbi, Felipe
> >>Sent: Wednesday, July 03, 2013 6:51 PM
> >>To: ABRAHAM, KISHON VIJAY
> >>Cc: Patel, Satish; grant.likely at linaro.org; tony at atomide.com; Balbi,
> >>Felipe; arnd at arndb.de; swarren at nvidia.com;
> >>sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
> >>omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> >>usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> >>foundation.org; rob.herring at calxeda.com; rob at landley.net;
> >>linux at arm.linux.org.uk; benoit.cousson at linaro.org; mchehab at redhat.com;
> >>cesarb at cesarb.net; davem at davemloft.net; Nayak, Rajendra;
> >>shawn.guo at linaro.org; Shilimkar, Santosh; devicetree-
> >>discuss at lists.ozlabs.org; linux-doc at vger.kernel.org; Nori, Sekhar;
> >>Krishnamoorthy, Balaji T; Cherian, George
> >>Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> >>
> >>Hi,
> >>
> >>On Wed, Jul 03, 2013 at 03:35:39PM +0530, Kishon Vijay Abraham I
> >>wrote:
> >>>On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote:
> >>>>Hi Kishon,
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: ABRAHAM, KISHON VIJAY
> >>>>>Sent: Wednesday, June 26, 2013 5:17 PM
> >>>>>To: grant.likely at linaro.org; tony at atomide.com; Balbi, Felipe;
> >>ABRAHAM,
> >>>>>KISHON VIJAY; arnd at arndb.de; swarren at nvidia.com;
> >>>>>sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
> >>>>>omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> >>>>>usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> >>>>>foundation.org
> >>>>>Cc: rob.herring at calxeda.com; rob at landley.net;
> >>linux at arm.linux.org.uk;
> >>>>>benoit.cousson at linaro.org; mchehab at redhat.com; cesarb at cesarb.net;
> >>>>>davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org;
> >>Shilimkar,
> >>>>>Santosh; devicetree-discuss at lists.ozlabs.org; linux-
> >>>>>doc at vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T;
> >>Cherian,
> >>>>>George
> >>>>>Subject: [PATCH v9 0/8] Generic PHY Framework
> >>>>>
> >>>>>Added a generic PHY framework that provides a set of APIs for the
> >>PHY
> >>>>>drivers
> >>>>>to create/destroy a PHY and APIs for the PHY users to obtain a
> >>>>>reference to
> >>>>>the PHY with or without using phandle.
> >>>>>
> >>>>>This framework will be of use only to devices that uses external
> >>PHY
> >>>>>(PHY
> >>>>>functionality is not embedded within the controller).
> >>>>>
> >>>>>The intention of creating this framework is to bring the phy
> >>drivers
> >>>>>spread
> >>>>>all over the Linux kernel to drivers/phy to increase code re-use
> >>and
> >>>>>to
> >>>>>increase code maintainability.
> >>>>
> >>>>I would like to use this framework for a smart-card controller
> >>connected to a
> >>>>smart-card phy. I have some questions and would like to get
> >>feedback on the same.
> >>>
> >>>glad to know that :-)
> >>>>
> >>>>I am using ?TDA8026" Smartcard PHY from NXP. Here is the link for
> >>datasheet
> >>>>and app note for the same. The smart card controller is inside the
> >>TI SoC
> >>>>I am working with.
> >>>>
> >>>>Datasheet :
> >>>>www.nxp.com/documents/data_sheet/TDA8026.pdf?
> >>>>
> >>>>Appnote :
> >>>>http://www.nxp.com/documents/application_note/AN10724.pdf
> >>>>
> >>>>The TI SoC details are not public (yet). I can provide details to
> >>you offline.
> >>>>
> >>>>Brief about operation:
> >>>>-	The controller can work with and without a PHY
> >>>>-	When not using PHY, it is limited to talking to a single
> >>>>	smart card. There is also a need to put external de-activation
> >>logic
> >>>>	on card removal for this case.
> >>>>-	With a PHY you can use more than one smart card.
> >>>>-	Phy has 5 slots :  1 for smart card (credit/debit/other card
> >>with chip)
> >>>>       and others for SAM ? SIM like modules
> >>>>- 	Once the PHY is initialized, there are some operations that the
> >>controller
> >>>>	can request of the PHY like:
> >>>>	- Card configurations  - set voltage
> >>>>	- Activation of card
> >>>>	- ATR ? Answer to reset
> >>>>	- Warm reset
> >>>>	- ADPU exchange
> >>>>	- Deactivation ( Normal/Emergency)
> >>>
> >>>hmm.. We should think about extending the phy_ops to include these
> >>>operations (something like phy_smart_card_ops so that other
> >>>smart_card PHYs will also be able to use it).
> >>
> >>let's try to avoid use-case specific additions. set_voltage sounds
> >>like
> >>a regulator thing, but the regulator is controlled through the PHY. I
> >>guess it makes sense to have a generic phy_set_voltage() call since
> >>even
> >>USB can make use of that.
> >>
> >>For card activation, it sounds like phy_init()/phy_shutdown() would
> >>cover it.
> >>
> >>For warm reset perhaps a phy_reset() callback ? Although that could,
> >>easily, get abused.
> >>
> >>For deactivation, that's phy_shutdown().
> >>
> >>ATR and ADPU needs more thought, I guess.
> >>
> >>>>- 	In the mode when smartcard controller talks directly to the
> >>card without the need
> >>>>	for a PHY, all the above operations will be carried out by the
> >>controller itself
> >>>>
> >>>>My current thought process is to make the controller driver provide
> >>the user interface
> >>>>and talk to the PHY using the generic PHY framework you proposed.
> >>In the case where there
> >>>>is no PHY, my idea is to create a "dummy" PHY which uses the
> >>controller functionality itself.
> >>>
> >>>right. And in the case where you actually have a PHY, create a PHY
> >>>driver and implement the phy_smart_card_ops and register with the
> >>PHY
> >>>framework.
> >>
> >>I would try to avoid that. Otherwise we will have phy_usb_ops,
> >>phy_sata_ops, phy_network_ops, phy_pci_ops, etc etc etc. It would
> >>easily
> >>blow up.
> >>
> >
> >- I do agree with you. Creating Phy specific ops will blow up whole
> >   concept of generic phy f/w.
> >- Can we have interface like phy_setconfig - with parameter like
> >   phy_setconfig(int param, void *value)
> >	- Here param can be enum of available config parameters for
> >	  specific phy.
> >Phy can perform different operation/set internal state based on
> >param selection and value passed by.
> >	
> >e.x in case of smartcard
> >	enum set_config {
> >		SET_VOLATAGE,
> >		SET_ACTIVATE,
> >		SET_WARMRESET,
> >		SET_ATR,
> >		SET_DEACTIVE,
> >		....
> >	};
> 
> hmm.. this looks similar to ioctl and can be abused easily IMO :s

+1

What we need is to come up with generic ways to model those, if we need
set voltage, then add a phy_set_voltage() kinda thing, perhaps add
capability flags to enable/disable support fort those (just like mmc
does).

But adding something which can handle "anything" like phy_set_config(),
it's the same as adding use-case specific ops.

-- 
balbi
-------------- 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/20130704/5ba55a88/attachment-0001.sig>

From t.figa at samsung.com  Thu Jul  4 06:32:26 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Thu, 04 Jul 2013 12:32:26 +0200
Subject: On common struct clk in clock framework.
In-Reply-To: <CAM2a4uxMO4JjA-_QS_x+9FB38CYJFWCcYQk-kTc7YXMVuJ91Ug@mail.gmail.com>
References: <CAM2a4uyrX0t-W8hXKROvZgJPSyCY+DaviV-eRVZOhyPx=WNBUw@mail.gmail.com>
 <16151917.X00PMOJFZ6@flatron>
 <CAM2a4uxMO4JjA-_QS_x+9FB38CYJFWCcYQk-kTc7YXMVuJ91Ug@mail.gmail.com>
Message-ID: <2625323.Iy4l3LBv4H@amdc1227>

On Thursday 04 of July 2013 10:21:27 mind entropy wrote:
> On Wed, Jul 3, 2013 at 11:37 PM, Tomasz Figa <tomasz.figa at gmail.com> 
wrote:
> > The examples you pointed are not using Common Clock Framework. See
> > Documentation/clk.txt and drivers/clk/ for more information about CCF.
> > 
> > As for s3c24xx, CCF driver for the whole platform is already merged for
> > Linux 3.11.
> > 
> > Best regards,
> > Tomasz
> 
> Thanks TomasZ. I have gone through the docs and was quite confused. I
> will have a look at the merge.

Oops. It seems like s3c24xx clk driver is not merged yet. I don't know why 
I thought it is. Heiko (on CC) has been working on it and I remember seeing 
some patches from him. Sorry for misinformation.

Best regards,
Tomasz

> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From B46079 at freescale.com  Thu Jul  4 06:44:11 2013
From: B46079 at freescale.com (Stehle Vincent-B46079)
Date: Thu, 4 Jul 2013 10:44:11 +0000
Subject: Mainline crashes in wm8962_probe() on i.MX6
Message-ID: <F7C43F8B2814514CA05F3436BC68046EF3A272@039-SN2MPN1-011.039d.mgd.msft.net>

Hi,

Mainline of today* will not boot anymore on i.MX6 with ARM config imx_v6_v7_defconfig. It crashes in wm8962_probe() (see log below).

Bisecting points at merge commit 1286da8bc009cb2aee7f285e94623fc974c0c983, but its two "parents" commits do not crash.

Best regards,

V.

*: commit ddcf6600b133697adbafd96e080818bdc0dfd028

---

wm8962 0-001a: customer id 0 revision D
Unable to handle kernel NULL pointer dereference at virtual address 00000004
pgd = 80004000
[00000004] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0+ #1
task: bf870000 ti: bf874000 task.ti: bf874000
PC is at wm8962_probe+0x134/0x6c8
LR is at regmap_unlock_mutex+0x10/0x14
pc : [<80452100>]    lr : [<80304cf4>]    psr: a0000113
sp : bf875c98  ip : 00000000  fp : bf875cd4
r10: 00000000  r9 : bfb1830c  r8 : 80779bc4
r7 : 00000000  r6 : 00000001  r5 : bfbac010  r4 : bfb33e00
r3 : 80304ce4  r2 : 00000000  r1 : 00000001  r0 : fffffffb
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 1000404a  DAC: 00000017
Process swapper/0 (pid: 1, stack limit = 0xbf874238)
Stack: (0xbf875c98 to 0xbf876000)
5c80:                                                       00000000 00000000
5ca0: 00000000 00000000 00000000 bfb33e00 80778a00 80778ab0 bfba8c60 80779bc4
5cc0: bfb1830c bfb33eb0 bf875d04 bf875cd8 80440c30 80451fd8 8058c9c8 bf875ce8
5ce0: bfaf5000 00000000 80778a88 bfba8c60 00000000 00000000 bf875d84 bf875d08
5d00: 80442ae4 80440ac4 bfba8c70 80fed848 bf875d44 bf875d20 bfba8d38 bfba8d30
5d20: bfba8d40 bfba8d58 bfba8c80 80778aa8 bfb1830c bfb1833c bfb33e00 80778ab8
5d40: 80778aa8 bfb33e30 bfaf52f0 bfaf5240 bfba8c60 bfba8d68 bf875d84 00000000
5d60: bf983810 80fe5984 bfba8c60 bf9b9020 bf827000 bfba8c10 bf875dc4 bf875d88
5d80: 804563f0 804420a4 00000000 bf91a400 00000001 00000002 bf875db4 807d3ed8
5da0: bf983810 00000000 8077d1b4 807207dc bf874000 000000ac bf875dd4 bf875dc8
5dc0: 802f6388 8045613c bf875df4 bf875dd8 802f4fe4 802f6374 bf983810 8077d1b4
5de0: bf983844 00000000 bf875e14 bf875df8 802f5190 802f4ee4 bf83c85c 00000000
5e00: 8077d1b4 802f50fc bf875e3c bf875e18 802f34f0 802f5108 bf83c85c bf928bb4
5e20: bf83c870 8077d1b4 bfb2c080 807662d0 bf875e4c bf875e40 802f4ad8 802f34a0
5e40: bf875e7c bf875e50 802f4650 802f4ac4 806b7204 80783bc0 bf875e7c 8077d1b4
5e60: 00000006 80783bc0 806f220c 807207dc bf875ea4 bf875e80 802f56b4 802f4580
5e80: 8073dcdc 00000006 80783bc0 806f220c 807207dc 000000ac bf875eb4 bf875ea8
5ea0: 802f65ac 802f5640 bf875ec4 bf875eb8 807207f4 802f6568 bf875f54 bf875ec8
5ec0: 80008794 807207e8 bf875f0c bf875ed8 8054b368 00000000 00100100 80755408
5ee0: bf875f0c bf875ef0 bf875f00 bf875ef8 806f220c 80fedb1b 80564964 000000ac
5f00: bf875f54 bf875f10 800419b0 806f2218 00000000 00000006 00000006 806f017c
5f20: 00000000 806a41fc bf875f54 8073dcdc 00000006 80783bc0 806f220c 807324a4
5f40: 80732498 000000ac bf875f94 bf875f58 806f29b8 800086ac 00000006 00000006
5f60: 806f220c 80000084 38070000 00000000 8053fbe8 00000000 00000000 00000000
5f80: 00000000 00000000 bf875fac bf875f98 8053fbf8 806f28c4 ffffffff 00000000
5fa0: 00000000 bf875fb0 8000e2b8 8053fbf4 00000000 00000000 00000000 00000000
5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
Backtrace:
[<80451fcc>] (wm8962_probe+0x0/0x6c8) from [<80440c30>] (soc_probe_codec+0x178/0x308)
[<80440ab8>] (soc_probe_codec+0x0/0x308) from [<80442ae4>] (snd_soc_register_card+0xa4c/0x162c)
[<80442098>] (snd_soc_register_card+0x0/0x162c) from [<804563f0>] (imx_wm8962_probe+0x2c0/0x378)
[<80456130>] (imx_wm8962_probe+0x0/0x378) from [<802f6388>] (platform_drv_probe+0x20/0x24)
[<802f6368>] (platform_drv_probe+0x0/0x24) from [<802f4fe4>] (driver_probe_device+0x10c/0x224)
[<802f4ed8>] (driver_probe_device+0x0/0x224) from [<802f5190>] (__driver_attach+0x94/0x98)
 r7:00000000 r6:bf983844 r5:8077d1b4 r4:bf983810
[<802f50fc>] (__driver_attach+0x0/0x98) from [<802f34f0>] (bus_for_each_dev+0x5c/0x90)
 r6:802f50fc r5:8077d1b4 r4:00000000 r3:bf83c85c
[<802f3494>] (bus_for_each_dev+0x0/0x90) from [<802f4ad8>] (driver_attach+0x20/0x28)
 r6:807662d0 r5:bfb2c080 r4:8077d1b4
[<802f4ab8>] (driver_attach+0x0/0x28) from [<802f4650>] (bus_add_driver+0xdc/0x238)
[<802f4574>] (bus_add_driver+0x0/0x238) from [<802f56b4>] (driver_register+0x80/0x154)
 r8:807207dc r7:806f220c r6:80783bc0 r5:00000006 r4:8077d1b4
[<802f5634>] (driver_register+0x0/0x154) from [<802f65ac>] (__platform_driver_register+0x50/0x64)
[<802f655c>] (__platform_driver_register+0x0/0x64) from [<807207f4>] (imx_wm8962_driver_init+0x18/0x20)
[<807207dc>] (imx_wm8962_driver_init+0x0/0x20) from [<80008794>] (do_one_initcall+0xf4/0x154)
[<800086a0>] (do_one_initcall+0x0/0x154) from [<806f29b8>] (kernel_init_freeable+0x100/0x1cc)
[<806f28b8>] (kernel_init_freeable+0x0/0x1cc) from [<8053fbf8>] (kernel_init+0x10/0xec)
[<8053fbe8>] (kernel_init+0x0/0xec) from [<8000e2b8>] (ret_from_fork+0x14/0x3c)
 r4:00000000 r3:ffffffff
Code: ea000002 e2866001 e3560007 0a00000d (e5b73004)




From marc.zyngier at arm.com  Thu Jul  4 06:45:25 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 04 Jul 2013 11:45:25 +0100
Subject: [PULL] Enable KVM on arm64
Message-ID: <51D55245.8080207@arm.com>

Paolo, Gleb,

Following Linus' pull of the KVM/arm64 code, please pull the following
patch that actually enables KVM on AArch64 platforms.

Thanks,

	M.

The following changes since commit ddcf6600b133697adbafd96e080818bdc0dfd028:

  Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging (2013-07-03 19:56:35 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/enable-kvm-for-3.11

for you to fetch changes up to e48bf1151165524a42a63611edcc961249ecc4b4:

  arm64: KVM: Kconfig integration (2013-07-04 11:34:43 +0100)

----------------------------------------------------------------
Marc Zyngier (1):
      arm64: KVM: Kconfig integration

 arch/arm64/Kconfig              |  2 ++
 arch/arm64/kernel/asm-offsets.c |  1 +
 arch/arm64/kvm/Kconfig          | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 57 insertions(+)
 create mode 100644 arch/arm64/kvm/Kconfig

-- 
Jazz is not dead. It just smells funny...



From satish.patel at ti.com  Thu Jul  4 06:45:34 2013
From: satish.patel at ti.com (Patel, Satish)
Date: Thu, 4 Jul 2013 10:45:34 +0000
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <20130704101216.GD4830@arwen.pp.htv.fi>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
 <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com>
 <51D54694.20203@ti.com> <20130704101216.GD4830@arwen.pp.htv.fi>
Message-ID: <780E789C2E067A4BB8F69D0BB9EC4F253E975E03@DBDE04.ent.ti.com>

Hi,

> -----Original Message-----
> From: Balbi, Felipe
> Sent: Thursday, July 04, 2013 3:42 PM
> To: ABRAHAM, KISHON VIJAY
> Cc: Patel, Satish; Balbi, Felipe; grant.likely at linaro.org;
> tony at atomide.com; arnd at arndb.de; swarren at nvidia.com;
> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> foundation.org; rob.herring at calxeda.com; rob at landley.net;
> linux at arm.linux.org.uk; benoit.cousson at linaro.org; mchehab at redhat.com;
> cesarb at cesarb.net; davem at davemloft.net; Nayak, Rajendra;
> shawn.guo at linaro.org; Shilimkar, Santosh; devicetree-
> discuss at lists.ozlabs.org; linux-doc at vger.kernel.org; Nori, Sekhar;
> Krishnamoorthy, Balaji T; Cherian, George; Mankad, Maulik Ojas
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> On Thu, Jul 04, 2013 at 03:25:32PM +0530, Kishon Vijay Abraham I
> wrote:
> > On Thursday 04 July 2013 02:51 PM, Patel, Satish wrote:
> > >Hi,
> > >
> > >>-----Original Message-----
> > >>From: Balbi, Felipe
> > >>Sent: Wednesday, July 03, 2013 6:51 PM
> > >>To: ABRAHAM, KISHON VIJAY
> > >>Cc: Patel, Satish; grant.likely at linaro.org; tony at atomide.com;
> Balbi,
> > >>Felipe; arnd at arndb.de; swarren at nvidia.com;
> > >>sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
> > >>omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> > >>usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> > >>foundation.org; rob.herring at calxeda.com; rob at landley.net;
> > >>linux at arm.linux.org.uk; benoit.cousson at linaro.org;
> mchehab at redhat.com;
> > >>cesarb at cesarb.net; davem at davemloft.net; Nayak, Rajendra;
> > >>shawn.guo at linaro.org; Shilimkar, Santosh; devicetree-
> > >>discuss at lists.ozlabs.org; linux-doc at vger.kernel.org; Nori, Sekhar;
> > >>Krishnamoorthy, Balaji T; Cherian, George
> > >>Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> > >>
> > >>Hi,
> > >>
> > >>On Wed, Jul 03, 2013 at 03:35:39PM +0530, Kishon Vijay Abraham I
> > >>wrote:
> > >>>On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote:
> > >>>>Hi Kishon,
> > >>>>
> > >>>>>-----Original Message-----
> > >>>>>From: ABRAHAM, KISHON VIJAY
> > >>>>>Sent: Wednesday, June 26, 2013 5:17 PM
> > >>>>>To: grant.likely at linaro.org; tony at atomide.com; Balbi, Felipe;
> > >>ABRAHAM,
> > >>>>>KISHON VIJAY; arnd at arndb.de; swarren at nvidia.com;
> > >>>>>sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org;
> linux-
> > >>>>>omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-
> > >>>>>usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> > >>>>>foundation.org
> > >>>>>Cc: rob.herring at calxeda.com; rob at landley.net;
> > >>linux at arm.linux.org.uk;
> > >>>>>benoit.cousson at linaro.org; mchehab at redhat.com;
> cesarb at cesarb.net;
> > >>>>>davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org;
> > >>Shilimkar,
> > >>>>>Santosh; devicetree-discuss at lists.ozlabs.org; linux-
> > >>>>>doc at vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T;
> > >>Cherian,
> > >>>>>George
> > >>>>>Subject: [PATCH v9 0/8] Generic PHY Framework
> > >>>>>
> > >>>>>Added a generic PHY framework that provides a set of APIs for
> the
> > >>PHY
> > >>>>>drivers
> > >>>>>to create/destroy a PHY and APIs for the PHY users to obtain a
> > >>>>>reference to
> > >>>>>the PHY with or without using phandle.
> > >>>>>
> > >>>>>This framework will be of use only to devices that uses
> external
> > >>PHY
> > >>>>>(PHY
> > >>>>>functionality is not embedded within the controller).
> > >>>>>
> > >>>>>The intention of creating this framework is to bring the phy
> > >>drivers
> > >>>>>spread
> > >>>>>all over the Linux kernel to drivers/phy to increase code re-
> use
> > >>and
> > >>>>>to
> > >>>>>increase code maintainability.
> > >>>>
> > >>>>I would like to use this framework for a smart-card controller
> > >>connected to a
> > >>>>smart-card phy. I have some questions and would like to get
> > >>feedback on the same.
> > >>>
> > >>>glad to know that :-)
> > >>>>
> > >>>>I am using ?TDA8026" Smartcard PHY from NXP. Here is the link
> for
> > >>datasheet
> > >>>>and app note for the same. The smart card controller is inside
> the
> > >>TI SoC
> > >>>>I am working with.
> > >>>>
> > >>>>Datasheet :
> > >>>>www.nxp.com/documents/data_sheet/TDA8026.pdf?
> > >>>>
> > >>>>Appnote :
> > >>>>http://www.nxp.com/documents/application_note/AN10724.pdf
> > >>>>
> > >>>>The TI SoC details are not public (yet). I can provide details
> to
> > >>you offline.
> > >>>>
> > >>>>Brief about operation:
> > >>>>-	The controller can work with and without a PHY
> > >>>>-	When not using PHY, it is limited to talking to a single
> > >>>>	smart card. There is also a need to put external de-activation
> > >>logic
> > >>>>	on card removal for this case.
> > >>>>-	With a PHY you can use more than one smart card.
> > >>>>-	Phy has 5 slots :  1 for smart card (credit/debit/other
> card
> > >>with chip)
> > >>>>       and others for SAM ? SIM like modules
> > >>>>- 	Once the PHY is initialized, there are some operations
> that the
> > >>controller
> > >>>>	can request of the PHY like:
> > >>>>	- Card configurations  - set voltage
> > >>>>	- Activation of card
> > >>>>	- ATR ? Answer to reset
> > >>>>	- Warm reset
> > >>>>	- ADPU exchange
> > >>>>	- Deactivation ( Normal/Emergency)
> > >>>
> > >>>hmm.. We should think about extending the phy_ops to include
> these
> > >>>operations (something like phy_smart_card_ops so that other
> > >>>smart_card PHYs will also be able to use it).
> > >>
> > >>let's try to avoid use-case specific additions. set_voltage sounds
> > >>like
> > >>a regulator thing, but the regulator is controlled through the
> PHY. I
> > >>guess it makes sense to have a generic phy_set_voltage() call
> since
> > >>even
> > >>USB can make use of that.
> > >>
> > >>For card activation, it sounds like phy_init()/phy_shutdown()
> would
> > >>cover it.
> > >>
> > >>For warm reset perhaps a phy_reset() callback ? Although that
> could,
> > >>easily, get abused.
> > >>
> > >>For deactivation, that's phy_shutdown().
> > >>
> > >>ATR and ADPU needs more thought, I guess.
> > >>
> > >>>>- 	In the mode when smartcard controller talks directly to
> the
> > >>card without the need
> > >>>>	for a PHY, all the above operations will be carried out by the
> > >>controller itself
> > >>>>
> > >>>>My current thought process is to make the controller driver
> provide
> > >>the user interface
> > >>>>and talk to the PHY using the generic PHY framework you
> proposed.
> > >>In the case where there
> > >>>>is no PHY, my idea is to create a "dummy" PHY which uses the
> > >>controller functionality itself.
> > >>>
> > >>>right. And in the case where you actually have a PHY, create a
> PHY
> > >>>driver and implement the phy_smart_card_ops and register with the
> > >>PHY
> > >>>framework.
> > >>
> > >>I would try to avoid that. Otherwise we will have phy_usb_ops,
> > >>phy_sata_ops, phy_network_ops, phy_pci_ops, etc etc etc. It would
> > >>easily
> > >>blow up.
> > >>
> > >
> > >- I do agree with you. Creating Phy specific ops will blow up whole
> > >   concept of generic phy f/w.
> > >- Can we have interface like phy_setconfig - with parameter like
> > >   phy_setconfig(int param, void *value)
> > >	- Here param can be enum of available config parameters for
> > >	  specific phy.
> > >Phy can perform different operation/set internal state based on
> > >param selection and value passed by.
> > >
> > >e.x in case of smartcard
> > >	enum set_config {
> > >		SET_VOLATAGE,
> > >		SET_ACTIVATE,
> > >		SET_WARMRESET,
> > >		SET_ATR,
> > >		SET_DEACTIVE,
> > >		....
> > >	};
> >
> > hmm.. this looks similar to ioctl and can be abused easily IMO :s
> 
> +1
> 
> What we need is to come up with generic ways to model those, if we
> need
> set voltage, then add a phy_set_voltage() kinda thing, perhaps add
> capability flags to enable/disable support fort those (just like mmc
> does).
> 

This will required study of capabilities of available phys.
Only point of consideration is  - list should not gets exhausted to cover all 
phy capabilities

> But adding something which can handle "anything" like
> phy_set_config(),
> it's the same as adding use-case specific ops.
> 
> --
> balbi

From heiko at sntech.de  Thu Jul  4 06:58:48 2013
From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=)
Date: Thu, 4 Jul 2013 12:58:48 +0200
Subject: On common struct clk in clock framework.
In-Reply-To: <2625323.Iy4l3LBv4H@amdc1227>
References: <CAM2a4uyrX0t-W8hXKROvZgJPSyCY+DaviV-eRVZOhyPx=WNBUw@mail.gmail.com>
 <CAM2a4uxMO4JjA-_QS_x+9FB38CYJFWCcYQk-kTc7YXMVuJ91Ug@mail.gmail.com>
 <2625323.Iy4l3LBv4H@amdc1227>
Message-ID: <201307041258.49200.heiko@sntech.de>

Hi,

Am Donnerstag, 4. Juli 2013, 12:32:26 schrieb Tomasz Figa:
> On Thursday 04 of July 2013 10:21:27 mind entropy wrote:
> > On Wed, Jul 3, 2013 at 11:37 PM, Tomasz Figa <tomasz.figa at gmail.com>
> 
> wrote:
> > > The examples you pointed are not using Common Clock Framework. See
> > > Documentation/clk.txt and drivers/clk/ for more information about CCF.
> > > 
> > > As for s3c24xx, CCF driver for the whole platform is already merged for
> > > Linux 3.11.
> > > 
> > > Best regards,
> > > Tomasz
> > 
> > Thanks TomasZ. I have gone through the docs and was quite confused. I
> > will have a look at the merge.
> 
> Oops. It seems like s3c24xx clk driver is not merged yet. I don't know why
> I thought it is. Heiko (on CC) has been working on it and I remember seeing
> some patches from him. Sorry for misinformation.

the ccf conversion should be ready, but at the time I submitted them, the pwm 
rework [that got rid of the pwm-internal clocks] was still missing.

At some point in the threads I lost track of its state, did the pwm rework 
make it into 3.11 after all, or is it an early 3.12 change?


Heiko


From pbonzini at redhat.com  Thu Jul  4 07:06:21 2013
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Thu, 04 Jul 2013 13:06:21 +0200
Subject: [PULL] Enable KVM on arm64
In-Reply-To: <51D55245.8080207@arm.com>
References: <51D55245.8080207@arm.com>
Message-ID: <51D5572D.40600@redhat.com>

Il 04/07/2013 12:45, Marc Zyngier ha scritto:
> Paolo, Gleb,
> 
> Following Linus' pull of the KVM/arm64 code, please pull the following
> patch that actually enables KVM on AArch64 platforms.
> 
> Thanks,
> 
> 	M.
> 
> The following changes since commit ddcf6600b133697adbafd96e080818bdc0dfd028:
> 
>   Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging (2013-07-03 19:56:35 -0700)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/enable-kvm-for-3.11
> 
> for you to fetch changes up to e48bf1151165524a42a63611edcc961249ecc4b4:
> 
>   arm64: KVM: Kconfig integration (2013-07-04 11:34:43 +0100)

Please base this patch on commit fe489bf4 (Linus prefers not to have
pull requests base on "random HEAD of the day").  Also, please post the
patch. :)

Paolo


From heiko at sntech.de  Thu Jul  4 07:07:42 2013
From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=)
Date: Thu, 4 Jul 2013 13:07:42 +0200
Subject: On common struct clk in clock framework.
In-Reply-To: <201307041258.49200.heiko@sntech.de>
References: <CAM2a4uyrX0t-W8hXKROvZgJPSyCY+DaviV-eRVZOhyPx=WNBUw@mail.gmail.com>
 <2625323.Iy4l3LBv4H@amdc1227> <201307041258.49200.heiko@sntech.de>
Message-ID: <201307041307.42397.heiko@sntech.de>

Am Donnerstag, 4. Juli 2013, 12:58:48 schrieb Heiko St?bner:
> Hi,
> 
> Am Donnerstag, 4. Juli 2013, 12:32:26 schrieb Tomasz Figa:
> > On Thursday 04 of July 2013 10:21:27 mind entropy wrote:
> > > On Wed, Jul 3, 2013 at 11:37 PM, Tomasz Figa <tomasz.figa at gmail.com>
> > 
> > wrote:
> > > > The examples you pointed are not using Common Clock Framework. See
> > > > Documentation/clk.txt and drivers/clk/ for more information about
> > > > CCF.
> > > > 
> > > > As for s3c24xx, CCF driver for the whole platform is already merged
> > > > for Linux 3.11.
> > > > 
> > > > Best regards,
> > > > Tomasz
> > > 
> > > Thanks TomasZ. I have gone through the docs and was quite confused. I
> > > will have a look at the merge.
> > 
> > Oops. It seems like s3c24xx clk driver is not merged yet. I don't know
> > why I thought it is. Heiko (on CC) has been working on it and I remember
> > seeing some patches from him. Sorry for misinformation.
> 
> the ccf conversion should be ready, but at the time I submitted them, the
> pwm rework [that got rid of the pwm-internal clocks] was still missing.
> 
> At some point in the threads I lost track of its state, did the pwm rework
> make it into 3.11 after all, or is it an early 3.12 change?

of course I forgot the most important thing :-)

There is a big red line between the clocks starting with the s3c2443 and the 
other s3c24xx before it - they have nearly nothing in common. The ccf driver I 
created [0] therefore only provides the clocks for s3c2443, s3c2416 and 
s3c2450, which are very similar.


Heiko

[0] http://patches.sntech.de/projects/linux-kernel/01_mailinglist/s3c2416-
common-clk/


From enrico.scholz at sigma-chemnitz.de  Thu Jul  4 07:33:38 2013
From: enrico.scholz at sigma-chemnitz.de (Enrico Scholz)
Date: Thu, 04 Jul 2013 13:33:38 +0200
Subject: Oops on 'cat /dev/kmem'
Message-ID: <ly8v1m5zl9.fsf@ensc-virt.intern.sigma-chemnitz.de>

Hi,

read access on /dev/kmem oopses here on pxa168 and omap3 platforms
(kernel 3.4 and 3.2):

~ # cat /dev/kmem 
[ 2925.599453] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 2925.649173] pgd = c7a7c000
[ 2925.657282] [00000000] *pgd=071a0831, *pte=00000000, *ppte=00000000
[ 2925.697821] Internal error: Oops: 17 [#1] PREEMPT ARM
[ 2925.712938] Modules linked in: ...
[ 2925.825207] CPU: 0    Not tainted  (3.4.52.ipan7 #1)
[ 2925.840083] PC is at __copy_to_user_std+0x4c/0x3a8
[ 2925.854431] LR is at read_kmem+0xa0/0x1d4
[ 2925.866438] pc : [<c01e768c>]    lr : [<c02304bc>]    psr: 20000013


What would be the correct fix? Defining '__ARCH_HAS_NO_PAGE_ZERO_MAPPED'
also for ARM?



Enrico


From wangyuhang2014 at gmail.com  Thu Jul  4 07:36:48 2013
From: wangyuhang2014 at gmail.com (yuhang wang)
Date: Thu, 4 Jul 2013 19:36:48 +0800
Subject: SPI: DUAL/QUAD support
Message-ID: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>

Hi Mark,

Thanks for your reply.
I have added the kerneldoc into the patch below to explain the "DUAL"
and "QUAD" modes.
Hope for your suggestions.

Documentation/spi/spi-dual_quad |  102 +++++++++++++++++++++++++++++++++++++++
 drivers/mtd/devices/m25p80.c    |    2 +
 drivers/spi/spi.c               |    2 +
 include/linux/spi/spi.h         |    8 +++
 4 files changed, 114 insertions(+)
 create mode 100644 Documentation/spi/spi-dual_quad

diff --git a/Documentation/spi/spi-dual_quad b/Documentation/spi/spi-dual_quad
new file mode 100644
index 0000000..06a2f9e
--- /dev/null
+++ b/Documentation/spi/spi-dual_quad
@@ -0,0 +1,102 @@
+spi-dual_quad: make spi support DUAL/QUAD
+============================================
+
+Description
+----------------------
+DUAL/QUAD means spi can transfer in 2bits/4bits at the same time.
+These spi controllers provide 8 data lines(4-tx and 4-rx). User can
+choose tranfer mode(SINGLE/DUAL/QUAD) by setting the certain register.
+Though SPI is a serial interface, some spi controllers can support
+transmitting and receiving in DUAL and QUAD modes aimed to improve
+the performance. Also as spi slave lots of flashes do support this attribute,
+such as serial-norflash in spansion company.
+
+Serial-flash such as s25fl129p in spansion company.
+In common way, the flash has two data pins(IO0,IO1) supporting SINGLE/DUAL.
+The flash also can work in QUAD mode, there are still other two
pins(HOLD,W#)which
+in other usage will be regarded as data pins.
+
+The members added below is used to provide the transfer information from slave
+to master. Thus spi controller driver can distinguish the transfer mode(SINGLE
+/DUAL/QUAD) and set the certain controlling register.
+
+
+Members added
+----------------------
+struct spi_device {
++       u8     rx_bitwidth;
++       u8     tx_bitwidth;
+}
+
+struct spi_transfer {
++       u8     bitwidth;
++#define        SPI_BITWIDTH_SINGLE     0x01; /* 1bit transfer */
++#define        SPI_BITWIDTH_DUAL       0x02; /* 2bits transfer */
++#define        SPI_BITWIDTH_QUAD       0x03; /* 4bits transfer */
+}
+
+struct spi_board_info {
++       u8     rx_bitwidth;
++       u8     tx_bitwidth;
+}
+
+
+How to use the added members
+----------------------
+
+DECLARE SLAVE DEVICES
+
+Normally your arch/.../mach-*/board-*.c files would provide a small table
+listing the SPI devices on each board.  Details refered to "spi-summary".
+At the same time, if your slave device support DUAL/QUAD transfer, you can
+set as below:
+
+       static struct spi_board_info spi_board_info[] __initdata = {
+       {
+               .modalias       = "xxxxx",
+               .......
+               .chip_select    = 0,
+               .rx_bitwidth = SPI_BITWIDTH_DUAL,
+               .tx_bitwidth = SPI_BITWIDTH_QUAD,
+       },
+       };
+
+ORGANISE SPI PACKAGE
+
+When your slave is registered by:
+
+       spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info));
+
+rx_bitwidth and tx_bitwidth members will be delivered into "struct spi_device".
+Thus the flash driver can notice the tranfer mode that user has appointed.
+Flash driver receives the data from the uplayer and organise the spi_transfer
+package as below:
+
+       ......
+       struct spi_transfer t[2];
+       struct spi_message m;
+       spi_message_init(&m);
+       memset(t, 0, (sizeof t));
+       ......
+       t[0].rx_buf = buf;
+       t[0].len = len;
+       t[0].bitwidth = spi->rx_bitwidth/spi->tx_bitwidth;
+       spi_message_add_tail(&t[0], &m);
+       ......
+       spi_sync(spi, &m);
+       ......
+
+finally, spi controller driver will deal with the spi_tranfer package.
+Controller driver will pick the bitwidth member out due to which set
the transfer
+mode register.
+
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 5b6b072..1411678 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -354,6 +354,7 @@ static int m25p80_read(struct mtd_info *mtd,
loff_t from, size_t len,

        t[1].rx_buf = buf;
        t[1].len = len;
+       t[1].bitwidth = flash->spi->rx_bitwidth;
        spi_message_add_tail(&t[1], &m);

        mutex_lock(&flash->lock);
@@ -409,6 +410,7 @@ static int m25p80_write(struct mtd_info *mtd,
loff_t to, size_t len,
        spi_message_add_tail(&t[0], &m);

        t[1].tx_buf = buf;
+       t[1].bitwidth = flash->spi->tx_bitwidth;
        spi_message_add_tail(&t[1], &m);

        mutex_lock(&flash->lock);
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 004b10f..cd99022 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -452,6 +452,8 @@ struct spi_device *spi_new_device(struct spi_master *master,
        proxy->irq = chip->irq;
        strlcpy(proxy->modalias, chip->modalias, sizeof(proxy->modalias));
        proxy->dev.platform_data = (void *) chip->platform_data;
+       proxy->rx_bitwidth = chip->rx_bitwidth;
+       proxy->tx_bitwidth = chip->tx_bitwidth;
        proxy->controller_data = chip->controller_data;
        proxy->controller_state = NULL;

diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 38c2b92..ddcf308 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -93,6 +93,8 @@ struct spi_device {
        void                    *controller_data;
        char                    modalias[SPI_NAME_SIZE];
        int                     cs_gpio;        /* chip select gpio */
+       u8                      rx_bitwidth;
+       u8                      tx_bitwidth;

        /*
         * likely need more hooks for more protocol options affecting how
@@ -511,6 +513,10 @@ struct spi_transfer {
        dma_addr_t      rx_dma;

        unsigned        cs_change:1;
+       u8              bitwidth;
+#define        SPI_BITWIDTH_SINGLE     0x01; /* 1bit transfer */
+#define        SPI_BITWIDTH_DUAL       0x02; /* 2bits transfer */
+#define        SPI_BITWIDTH_QUAD       0x03; /* 4bits transfer */
        u8              bits_per_word;
        u16             delay_usecs;
        u32             speed_hz;
@@ -859,6 +865,8 @@ struct spi_board_info {
         * where the default of SPI_CS_HIGH = 0 is wrong.
         */
        u8              mode;
+       u8              rx_bitwidth;
+       u8              tx_bitwidth;

        /* ... may need additional spi_device chip config data here.
         * avoid stuff protocol drivers can set; but include stuff

--
1.7.9.5

Best regards


From tony at atomide.com  Thu Jul  4 07:44:39 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Jul 2013 04:44:39 -0700
Subject: [PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
In-Reply-To: <1371631951-369-2-git-send-email-kishon@ti.com>
References: <1371631951-369-1-git-send-email-kishon@ti.com>
 <1371631951-369-2-git-send-email-kishon@ti.com>
Message-ID: <20130704114439.GA5523@atomide.com>

* Kishon Vijay Abraham I <kishon at ti.com> [130619 01:58]:
> In order for controllers to get PHY in case of non dt boot, the phy
> binding information (phy label) should be added in the platform
> data of the controller.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> Acked-by: Felipe Balbi <balbi at ti.com>
> Tested-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
> ---
>  arch/arm/mach-omap2/usb-musb.c |    6 +++++-
>  include/linux/usb/musb.h       |    3 +++
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> index 3242a55..5ddbe39 100644
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -85,8 +85,12 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
>  	musb_plat.mode = board_data->mode;
>  	musb_plat.extvbus = board_data->extvbus;
>  
> -	if (cpu_is_omap44xx())
> +	if (cpu_is_omap44xx()) {
>  		musb_plat.has_mailbox = true;
> +		musb_plat.phy_name = "omap-usb2";
> +	} else if (cpu_is_omap34xx()) {
> +		musb_plat.phy_name = "twl4030";
> +	}
>  
>  	if (soc_is_am35xx()) {
>  		oh_name = "am35x_otg_hs";

Care to refresh this patch against the current mainline tree?
Now omap4 is DT only, so this part won't apply. Mostly I'm wondering
what the phy_name should be for am35xx that's not covered by this
patch.

Also let me know if the last patch is safe to queue alone as a fix
or if it depends on the driver related changes in this series.

Regards,

Tony



From tony at atomide.com  Thu Jul  4 07:47:37 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Jul 2013 04:47:37 -0700
Subject: [PATCH] ARM: OMAP2+: timer: initialize before using oh_name
In-Reply-To: <51A51FAC.5090606@gmail.com>
References: <1369722288-15592-1-git-send-email-afzal@ti.com>
 <51A51FAC.5090606@gmail.com>
Message-ID: <20130704114736.GC5523@atomide.com>

* Jon Hunter <jgchunter at gmail.com> [130528 14:26]:
> 
> On 28/05/13 07:24, Afzal Mohammed wrote:
> > of_property_read_string_index(...,&oh_name) in omap_dm_timer_init_one
> > does not alter the value of 'oh_name' even if the relevant function
> > fails and as 'oh_name' in stack may have a non-zero value, it would
> > be misunderstood by timer code that DT has specified "ti,hwmod"
> > property for timer. 'oh_name' in this scenario would be a junk value,
> > this would result in module not being enabled by hwmod API's for
> > timer, and in turn crash.
> > 
> > Signed-off-by: Afzal Mohammed <afzal at ti.com>
> > ---
> >  arch/arm/mach-omap2/timer.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> > index f8b23b8..8e0c390 100644
> > --- a/arch/arm/mach-omap2/timer.c
> > +++ b/arch/arm/mach-omap2/timer.c
> > @@ -220,7 +220,7 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
> >  					 int posted)
> >  {
> >  	char name[10]; /* 10 = sizeof("gptXX_Xck0") */
> > -	const char *oh_name;
> > +	const char *oh_name = NULL;
> >  	struct device_node *np;
> >  	struct omap_hwmod *oh;
> >  	struct resource irq, mem;
> 
> Thanks!
> 
> Acked-by: Jon Hunter <jgchunter at gmail.com>

Thanks, applying into omap-for-v3.11/fixes.

Tony 



From tony at atomide.com  Thu Jul  4 07:47:45 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Jul 2013 04:47:45 -0700
Subject: [PATCH] ARM: OMAP2+: Remove obsolete Makefile line
In-Reply-To: <1369912823.23034.46.camel@x61.thuisdomein>
References: <1369912823.23034.46.camel@x61.thuisdomein>
Message-ID: <20130704114744.GD5523@atomide.com>

* Paul Bolle <pebolle at tiscali.nl> [130530 04:26]:
> The OMAP runtime PM implementation was removed in v3.0. But one Makefile
> line, which was used to tweak CFLAGS, was overlooked. Remove it too.
> 
> Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
> ---
> Untested. This cleans up after commit 638080c37a ("OMAP2+ / PM: move
> runtime PM implementation to use device power domains").

Thanks, applying into omap-for-v3.11/fixes.

Tony
 
>  arch/arm/mach-omap2/Makefile | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 55a9d67..7279fa8 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -93,10 +93,6 @@ obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)    += smartreflex-class3.o
>  AFLAGS_sleep24xx.o			:=-Wa,-march=armv6
>  AFLAGS_sleep34xx.o			:=-Wa,-march=armv7-a$(plus_sec)
>  
> -ifeq ($(CONFIG_PM_VERBOSE),y)
> -CFLAGS_pm_bus.o				+= -DDEBUG
> -endif
> -
>  endif
>  
>  ifeq ($(CONFIG_CPU_IDLE),y)
> -- 
> 1.7.11.7
> 


From tony at atomide.com  Thu Jul  4 07:47:56 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Jul 2013 04:47:56 -0700
Subject: [PATCH] N900: enable N900-specific drivers even if device tree
 is enabled
In-Reply-To: <20130701211504.GB15318@amd.pavel.ucw.cz>
References: <20130613141001.GF8164@atomide.com>
 <20130613142809.GA3775@amd.pavel.ucw.cz>
 <20130613145724.GH8164@atomide.com>
 <20130613155240.GB3775@amd.pavel.ucw.cz>
 <20130613161418.GJ8164@atomide.com>
 <20130613230808.GA14876@amd.pavel.ucw.cz>
 <20130614055629.GM8164@atomide.com>
 <20130614212816.GA31768@atrey.karlin.mff.cuni.cz>
 <20130617111031.GQ20992@atomide.com>
 <20130701211504.GB15318@amd.pavel.ucw.cz>
Message-ID: <20130704114755.GE5523@atomide.com>

* Pavel Machek <pavel at ucw.cz> [130701 14:21]:
> 
> We still need video & sound drivers with device tree enabled.
> 
> Signed-off-by: Pavel Machek <pavel at ucw.cz>

Thanks, applying this into omap-for-v3.11/fixes. Benoit should
queue the .dts related changes.

Tony

> 
> ---
> 
> Patch against 3.10.
> 
> --- linux-delme-clean//arch/arm/mach-omap2/board-rx51-video.c	2013-07-01 21:51:07.000000000 +0200
> +++ linux-delme/arch/arm/mach-omap2/board-rx51-video.c	2013-07-01 22:50:27.000000000 +0200
> @@ -61,7 +61,7 @@
>  
>  static int __init rx51_video_init(void)
>  {
> -	if (!machine_is_nokia_rx51())
> +	if (!machine_is_nokia_rx51() && !of_machine_is_compatible("nokia,omap3-n900"))
>  		return 0;
>  
>  	if (omap_mux_init_gpio(RX51_LCD_RESET_GPIO, OMAP_PIN_OUTPUT)) {
> diff -urN linux-delme-clean//sound/soc/omap/rx51.c linux-delme/sound/soc/omap/rx51.c
> --- linux-delme-clean//sound/soc/omap/rx51.c	2013-07-01 21:54:49.000000000 +0200
> +++ linux-delme/sound/soc/omap/rx51.c	2013-07-01 22:50:27.000000000 +0200
> @@ -396,7 +396,7 @@
>  {
>  	int err;
>  
> -	if (!machine_is_nokia_rx51())
> +	if (!machine_is_nokia_rx51() && !of_machine_is_compatible("nokia,omap3-n900"))
>  		return -ENODEV;
>  
>  	err = gpio_request_one(RX51_TVOUT_SEL_GPIO,
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From tony at atomide.com  Thu Jul  4 07:48:11 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Jul 2013 04:48:11 -0700
Subject: [PATCHv3 5/6] arm: omap2plus_defconfig: enable TI bandgap driver
In-Reply-To: <51C0C2A8.4020707@ti.com>
References: <1370637968-23299-1-git-send-email-eduardo.valentin@ti.com>
 <1370637968-23299-6-git-send-email-eduardo.valentin@ti.com>
 <51C0C2A8.4020707@ti.com>
Message-ID: <20130704114811.GG5523@atomide.com>

* Eduardo Valentin <eduardo.valentin at ti.com> [130618 13:33]:
> Tony,
> 
> On 07-06-2013 16:46, Eduardo Valentin wrote:
> > Enable the bandgap driver for TI SoCs thermal support.
> > 
> > Cc: Russell King <linux at arm.linux.org.uk>
> > Cc: Tony Lindgren <tony at atomide.com>
> > Cc: Javier Martinez Canillas <javier.martinez at collabora.co.uk>
> > Cc: AnilKumar Ch <anilkumar at ti.com>
> > Cc: Santosh Shilimkar <santosh.shilimkar at ti.com>
> > Cc: Tomi Valkeinen <tomi.valkeinen at ti.com>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: linux-kernel at vger.kernel.org
> > Signed-off-by: Eduardo Valentin <eduardo.valentin at ti.com>
> 
> Is it possible for you to queue this one and patch 6 for 3.11?

Yes thanks applying into omap-for-v3.11/fixes.

Tony


From tony at atomide.com  Thu Jul  4 07:50:04 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Jul 2013 04:50:04 -0700
Subject: [PATCH] ARM: OMAP5: Enable Cortex A15 errata 798181
In-Reply-To: <51D42D49.700@ti.com>
References: <1371671532-27071-1-git-send-email-santosh.shilimkar@ti.com>
 <51D42D49.700@ti.com>
Message-ID: <20130704115004.GH5523@atomide.com>

* Santosh Shilimkar <santosh.shilimkar at ti.com> [130703 07:01]:
> Ping..

Applying into omap-for-v3.11/fixes now that all our pending branches
have been merged.

Tony
 


From tony at atomide.com  Thu Jul  4 07:53:27 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Jul 2013 04:53:27 -0700
Subject: [PATCH -next] ARM: OMAP2+: devices: remove duplicated include
 from devices.c
In-Reply-To: <CAPgLHd9rXBA_QtQqOj4JbcFpfPoRTN5Ac9m9ofbP2PKVSmgANA@mail.gmail.com>
References: <CAPgLHd9rXBA_QtQqOj4JbcFpfPoRTN5Ac9m9ofbP2PKVSmgANA@mail.gmail.com>
Message-ID: <20130704115327.GI5523@atomide.com>

* Wei Yongjun <weiyj.lk at gmail.com> [130619 17:07]:
> From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> 
> Remove duplicated include.
> 
> Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Thanks applying into omap-for-v3.11/fixes. Looks like the reboot.h
duplicate has already been removed.

Regards,

Tony

> ---
>  arch/arm/mach-omap2/devices.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index c0f99ab..8349238 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -15,7 +15,6 @@
>  #include <linux/io.h>
>  #include <linux/clk.h>
>  #include <linux/err.h>
> -#include <linux/gpio.h>
>  #include <linux/slab.h>
>  #include <linux/of.h>
>  #include <linux/pinctrl/machine.h>




From tony at atomide.com  Thu Jul  4 07:58:19 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Jul 2013 04:58:19 -0700
Subject: [RFC 0/4] Cleanup PRM and CM regbit headers
In-Reply-To: <51C95839.6050307@ti.com>
References: <1372076143-12955-1-git-send-email-rnayak@ti.com>
 <20130625071428.GC5523@atomide.com> <51C95839.6050307@ti.com>
Message-ID: <20130704115819.GJ5523@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130625 01:49]:
> On Tuesday 25 June 2013 12:44 PM, Tony Lindgren wrote:
> >> Rajendra Nayak (4):
> >> >   ARM: OMAP2: PRM/CM: Cleanup unused header contents
> >> >   ARM: OMAP3: PRM/CM: Cleanup unused header contents
> >> >   ARM: OMAP4: PRM/CM: Cleanup unused header contents
> >> >   ARM: OMAP5: PRM/CM: Cleanup unused header contents
> >> > 
> >> >  arch/arm/mach-omap2/cm-regbits-24xx.h  |  317 ----
> >> >  arch/arm/mach-omap2/cm-regbits-33xx.h  |  758 ---------
> >> >  arch/arm/mach-omap2/cm-regbits-34xx.h  |  631 --------
> >> >  arch/arm/mach-omap2/cm-regbits-44xx.h  | 1557 -------------------
> >> >  arch/arm/mach-omap2/cm-regbits-54xx.h  | 1632 -------------------
> >> >  arch/arm/mach-omap2/prm-regbits-24xx.h |  246 ---
> >> >  arch/arm/mach-omap2/prm-regbits-33xx.h |  305 ----
> >> >  arch/arm/mach-omap2/prm-regbits-34xx.h |  480 ------
> >> >  arch/arm/mach-omap2/prm-regbits-44xx.h | 2225 --------------------------
> >> >  arch/arm/mach-omap2/prm-regbits-54xx.h | 2677 --------------------------------
> >> >  10 files changed, 10828 deletions(-)
> > If things build and work after applying this, I suggest we send them
> > as a clean-up branch right after -rc1.
> 
> They build fine, and I boot tested on the omap4/5 boards that I have too.
> (I had the out of tree clock data pulled in for omap5 before I did this
> cleanup).
> 
> > 
> > It seems that build testing and then randconfig testing
> > should be enough for these if they are unused and only
> > removal.
> 
> Right, I'll do more testing and even though they should just boot
> fine on the omap2/3 boards too since all thats removed is anyway
> unused, I will still do more sanity test before posting them on -rc1.

Looks like we have all the pending stuff merged already, this would
probably be a good time to post a pull request for these.

Tony


From tony at atomide.com  Thu Jul  4 07:59:30 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Jul 2013 04:59:30 -0700
Subject: [PATCHv2] ARM: OMAP: build mach-omap code only if needed
In-Reply-To: <20130625072812.GD5523@atomide.com>
References: <3976244.L5dCjrM5gT@wuerfel>
 <20130625072812.GD5523@atomide.com>
Message-ID: <20130704115929.GK5523@atomide.com>

* Tony Lindgren <tony at atomide.com> [130625 00:34]:
> * Arnd Bergmann <arnd at arndb.de> [130624 07:25]:
> > If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the
> > individual SoCs disabled, we run into a large number of link errors
> > because if incorrect dependencies:
> > 
> > arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep':
> > arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep':
> > arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable':
> > arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup'
> > arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable'
> > arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable'
> > arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function `_idle':
> > arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown':
> > arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count':
> > arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup':
> > arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle'
> > arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init':
> > arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init':
> > arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context'
> > 
> > We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that
> > gets enabled any time that one of the SoC versions is enabled.
> 
> /me hopes this does the trick finally ;)
> 
> I could not apply this to anything I tried though..
> Which branch is this against?

Ping, do you have updated patche(s) available as we discussed on IRC?

Tony


From tony at atomide.com  Thu Jul  4 08:02:17 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Jul 2013 05:02:17 -0700
Subject: [-next PATCH 0/2] ARM: OMAP5: fix build breakage due to SCU usage
In-Reply-To: <51D1A17D.9070701@ti.com>
References: <1372257587-21720-1-git-send-email-nm@ti.com>
 <51D1A17D.9070701@ti.com>
Message-ID: <20130704120216.GL5523@atomide.com>

* Nishanth Menon <nm at ti.com> [130701 08:41]:
> Tony,
> 
> Any chance of picking these up?

Thanks yes applying into omap-for-v3.11/fixes now that the pending
branches have been merged.

Tony


From marc.zyngier at arm.com  Thu Jul  4 08:02:57 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Jul 2013 13:02:57 +0100
Subject: [PATCH] arm64: KVM: Kconfig integration
Message-ID: <1372939377-24657-1-git-send-email-marc.zyngier@arm.com>

Finally plug KVM/arm64 into the config system, making it possible
to enable KVM support on AArch64 CPUs.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/Kconfig              |  2 ++
 arch/arm64/kernel/asm-offsets.c |  1 +
 arch/arm64/kvm/Kconfig          | 54 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 57 insertions(+)
 create mode 100644 arch/arm64/kvm/Kconfig

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4143d9b..9737e97 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -270,6 +270,8 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
+source "arch/arm64/kvm/Kconfig"
+
 source "arch/arm64/Kconfig.debug"
 
 source "security/Kconfig"
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 49c162c..666e231 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -21,6 +21,7 @@
 #include <linux/sched.h>
 #include <linux/mm.h>
 #include <linux/dma-mapping.h>
+#include <linux/kvm_host.h>
 #include <asm/thread_info.h>
 #include <asm/memory.h>
 #include <asm/cputable.h>
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
new file mode 100644
index 0000000..84f54f0
--- /dev/null
+++ b/arch/arm64/kvm/Kconfig
@@ -0,0 +1,54 @@
+#
+# KVM configuration
+#
+
+source "virt/kvm/Kconfig"
+
+menuconfig VIRTUALIZATION
+	bool "Virtualization"
+	---help---
+	  Say Y here to get to see options for using your Linux host to run
+	  other operating systems inside virtual machines (guests).
+	  This option alone does not add any kernel code.
+
+	  If you say N, all options in this submenu will be skipped and
+	  disabled.
+
+if VIRTUALIZATION
+
+config KVM
+	bool "Kernel-based Virtual Machine (KVM) support"
+	select MMU_NOTIFIER
+	select PREEMPT_NOTIFIERS
+	select ANON_INODES
+	select KVM_MMIO
+	select KVM_ARM_HOST
+	select KVM_ARM_VGIC
+	select KVM_ARM_TIMER
+	---help---
+	  Support hosting virtualized guest machines.
+
+	  This module provides access to the hardware capabilities through
+	  a character device node named /dev/kvm.
+
+	  If unsure, say N.
+
+config KVM_ARM_HOST
+	bool
+	---help---
+	  Provides host support for ARM processors.
+
+config KVM_ARM_VGIC
+        bool
+	depends on KVM_ARM_HOST && OF
+	select HAVE_KVM_IRQCHIP
+	---help---
+	  Adds support for a hardware assisted, in-kernel GIC emulation.
+
+config KVM_ARM_TIMER
+        bool
+	depends on KVM_ARM_VGIC
+	---help---
+	  Adds support for the Architected Timers in virtual machines
+
+endif # VIRTUALIZATION
-- 
1.8.2.3




From tony at atomide.com  Thu Jul  4 08:05:23 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Jul 2013 05:05:23 -0700
Subject: [PATCH v2 1/2] ARM: configs: Enable TI_EDMA in omap2plus_defconfig
In-Reply-To: <1372304523-30742-1-git-send-email-joelf@ti.com>
References: <1372304523-30742-1-git-send-email-joelf@ti.com>
Message-ID: <20130704120523.GM5523@atomide.com>

* Joel Fernandes <joelf at ti.com> [130626 20:48]:
> Build EDMA in by default to avoid fewer people stepping on their toes
> with broken DMA on drivers needing EDMA.

Thanks applying this one into omap-for-v3.11/fixes.

Tony


From marc.zyngier at arm.com  Thu Jul  4 08:06:38 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 04 Jul 2013 13:06:38 +0100
Subject: [PULL] Enable KVM on arm64, take #2
Message-ID: <51D5654E.5010908@arm.com>

Paolo, Gleb,

Following Linus' pull of the KVM/arm64 code, please pull the following
patch that actually enables KVM on AArch64 platforms.

The patch has also been posted as a separate email:
https://lists.cs.columbia.edu/pipermail/kvmarm/2013-July/006246.html

Thanks,

	M.

The following changes since commit fe489bf4505ae26d3c6d6a1f1d3064c2a9c5cd85:

  Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm (2013-07-03 13:21:40 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/enable-kvm-for-3.11

for you to fetch changes up to 980ed6a84cb708ba5f14f01d7df4b2e311a4bdcb:

  arm64: KVM: Kconfig integration (2013-07-04 12:58:27 +0100)

----------------------------------------------------------------
Marc Zyngier (1):
      arm64: KVM: Kconfig integration

 arch/arm64/Kconfig              |  2 ++
 arch/arm64/kernel/asm-offsets.c |  1 +
 arch/arm64/kvm/Kconfig          | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 57 insertions(+)
 create mode 100644 arch/arm64/kvm/Kconfig

-- 
Jazz is not dead. It just smells funny...



From festevam at gmail.com  Thu Jul  4 08:07:10 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 4 Jul 2013 09:07:10 -0300
Subject: mx6q boot on linux-next 20130703
In-Reply-To: <51D51885.3080102@freescale.com>
References: <CAOMZO5DgAu2-cknESp4a675KP5gDrJxM2A_FqUgAZav83Db=fw@mail.gmail.com>
 <51D51885.3080102@freescale.com>
Message-ID: <CAOMZO5Bw8ApabxMX8GVNSpqp-A3-PjNkr=S4VBXPw8t=KsraYg@mail.gmail.com>

On Thu, Jul 4, 2013 at 3:39 AM, Huang Shijie <b32955 at freescale.com> wrote:

> I tested the linux-next-0625, the boot is ok.

This version does not show the problem. Please try linux-next 20130703 instead.

Regards,

Fabio Estevam


From tony at atomide.com  Thu Jul  4 08:09:04 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Jul 2013 05:09:04 -0700
Subject: [PATCH] ARM: OMAP2+: omap2plus_defconfig: Enable appended DTB
 support
In-Reply-To: <1372684393-19025-1-git-send-email-trini@ti.com>
References: <1372684393-19025-1-git-send-email-trini@ti.com>
Message-ID: <20130704120903.GN5523@atomide.com>

* Tom Rini <trini at ti.com> [130701 06:19]:
> As this config must support boards which cannot support separate device
> trees, enable support for appended ones.

This can cause things to go wrong when DTB is not appended for mistaking the
memory as an appended DTB, especially when doing a warm reset. But as we need
this in practise for older platforms, let's add it.

Regards,

Tony


From kishon at ti.com  Thu Jul  4 08:10:25 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 4 Jul 2013 17:40:25 +0530
Subject: [PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
In-Reply-To: <20130704114439.GA5523@atomide.com>
References: <1371631951-369-1-git-send-email-kishon@ti.com>
 <1371631951-369-2-git-send-email-kishon@ti.com>
 <20130704114439.GA5523@atomide.com>
Message-ID: <51D56631.2010901@ti.com>

Hi,

On Thursday 04 July 2013 05:14 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kishon at ti.com> [130619 01:58]:
>> In order for controllers to get PHY in case of non dt boot, the phy
>> binding information (phy label) should be added in the platform
>> data of the controller.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
>> Acked-by: Felipe Balbi <balbi at ti.com>
>> Tested-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
>> ---
>>   arch/arm/mach-omap2/usb-musb.c |    6 +++++-
>>   include/linux/usb/musb.h       |    3 +++
>>   2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
>> index 3242a55..5ddbe39 100644
>> --- a/arch/arm/mach-omap2/usb-musb.c
>> +++ b/arch/arm/mach-omap2/usb-musb.c
>> @@ -85,8 +85,12 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
>>   	musb_plat.mode = board_data->mode;
>>   	musb_plat.extvbus = board_data->extvbus;
>>
>> -	if (cpu_is_omap44xx())
>> +	if (cpu_is_omap44xx()) {
>>   		musb_plat.has_mailbox = true;
>> +		musb_plat.phy_name = "omap-usb2";
>> +	} else if (cpu_is_omap34xx()) {
>> +		musb_plat.phy_name = "twl4030";
>> +	}
>>
>>   	if (soc_is_am35xx()) {
>>   		oh_name = "am35x_otg_hs";
>
> Care to refresh this patch against the current mainline tree?

I'll do that on monday as I'm not in office and I dont have any boards
to test at my disposal now.
> Now omap4 is DT only, so this part won't apply. Mostly I'm wondering
> what the phy_name should be for am35xx that's not covered by this
> patch.

am35xx doesn't have a separate PHY driver yet (I guess the programming
is done in the controller code now). So this binding is not needed for
am35xx.
>
> Also let me know if the last patch is safe to queue alone as a fix
> or if it depends on the driver related changes in this series.

No. The last patch is kind-of cleanup needed after applying the first
3 patches. It's better it's applied along with the other patches.

Thanks
Kishon


From peter.maydell at linaro.org  Thu Jul  4 08:11:17 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Thu, 4 Jul 2013 13:11:17 +0100
Subject: [PATCH] arm64: KVM: Kconfig integration
In-Reply-To: <1372939377-24657-1-git-send-email-marc.zyngier@arm.com>
References: <1372939377-24657-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <CAFEAcA-LCenzvJSyyGBMAxraiJx-4OT2dnMsnCGzWJ-ESEkAiw@mail.gmail.com>

On 4 July 2013 13:02, Marc Zyngier <marc.zyngier at arm.com> wrote:
> Finally plug KVM/arm64 into the config system, making it possible
> to enable KVM support on AArch64 CPUs.
>
> +config KVM
> +       bool "Kernel-based Virtual Machine (KVM) support"
> +       select MMU_NOTIFIER
> +       select PREEMPT_NOTIFIERS
> +       select ANON_INODES
> +       select KVM_MMIO
> +       select KVM_ARM_HOST
> +       select KVM_ARM_VGIC
> +       select KVM_ARM_TIMER
> +       ---help---
> +         Support hosting virtualized guest machines.
> +
> +         This module provides access to the hardware capabilities through
> +         a character device node named /dev/kvm.

"This module" ? I didn't think we supported KVM-as-a-module on ARM...

> +
> +         If unsure, say N.
> +
> +config KVM_ARM_HOST
> +       bool
> +       ---help---
> +         Provides host support for ARM processors.
> +
> +config KVM_ARM_VGIC
> +        bool
> +       depends on KVM_ARM_HOST && OF
> +       select HAVE_KVM_IRQCHIP
> +       ---help---
> +         Adds support for a hardware assisted, in-kernel GIC emulation.
> +
> +config KVM_ARM_TIMER
> +        bool
> +       depends on KVM_ARM_VGIC
> +       ---help---
> +         Adds support for the Architected Timers in virtual machines

Trailing '.' would be consistent with the other config options.

thanks
-- PMM


From rnayak at ti.com  Thu Jul  4 08:14:59 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Thu, 4 Jul 2013 17:44:59 +0530
Subject: [RFC 0/4] Cleanup PRM and CM regbit headers
In-Reply-To: <20130704115819.GJ5523@atomide.com>
References: <1372076143-12955-1-git-send-email-rnayak@ti.com>
 <20130625071428.GC5523@atomide.com> <51C95839.6050307@ti.com>
 <20130704115819.GJ5523@atomide.com>
Message-ID: <51D56743.9080800@ti.com>

On Thursday 04 July 2013 05:28 PM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak at ti.com> [130625 01:49]:
>> On Tuesday 25 June 2013 12:44 PM, Tony Lindgren wrote:
>>>> Rajendra Nayak (4):
>>>>>   ARM: OMAP2: PRM/CM: Cleanup unused header contents
>>>>>   ARM: OMAP3: PRM/CM: Cleanup unused header contents
>>>>>   ARM: OMAP4: PRM/CM: Cleanup unused header contents
>>>>>   ARM: OMAP5: PRM/CM: Cleanup unused header contents
>>>>>
>>>>>  arch/arm/mach-omap2/cm-regbits-24xx.h  |  317 ----
>>>>>  arch/arm/mach-omap2/cm-regbits-33xx.h  |  758 ---------
>>>>>  arch/arm/mach-omap2/cm-regbits-34xx.h  |  631 --------
>>>>>  arch/arm/mach-omap2/cm-regbits-44xx.h  | 1557 -------------------
>>>>>  arch/arm/mach-omap2/cm-regbits-54xx.h  | 1632 -------------------
>>>>>  arch/arm/mach-omap2/prm-regbits-24xx.h |  246 ---
>>>>>  arch/arm/mach-omap2/prm-regbits-33xx.h |  305 ----
>>>>>  arch/arm/mach-omap2/prm-regbits-34xx.h |  480 ------
>>>>>  arch/arm/mach-omap2/prm-regbits-44xx.h | 2225 --------------------------
>>>>>  arch/arm/mach-omap2/prm-regbits-54xx.h | 2677 --------------------------------
>>>>>  10 files changed, 10828 deletions(-)
>>> If things build and work after applying this, I suggest we send them
>>> as a clean-up branch right after -rc1.
>>
>> They build fine, and I boot tested on the omap4/5 boards that I have too.
>> (I had the out of tree clock data pulled in for omap5 before I did this
>> cleanup).
>>
>>>
>>> It seems that build testing and then randconfig testing
>>> should be enough for these if they are unused and only
>>> removal.
>>
>> Right, I'll do more testing and even though they should just boot
>> fine on the omap2/3 boards too since all thats removed is anyway
>> unused, I will still do more sanity test before posting them on -rc1.
> 
> Looks like we have all the pending stuff merged already, this would
> probably be a good time to post a pull request for these.

Ok, will do, thanks.

Paul/Benoit,

Should I also drop these lines from the file headers since they are no
longer same as the outputs from autogen files?

 * This file is automatically generated from the OMAP hardware databases.
 * We respectfully ask that any modifications to this file be coordinated
 * with the public linux-omap at vger.kernel.org mailing list and the
 * authors above to ensure that the autogeneration scripts are kept
 * up-to-date with the file contents.

regards,
Rajendra

> 
> Tony
> 



From pbonzini at redhat.com  Thu Jul  4 08:18:55 2013
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Thu, 04 Jul 2013 14:18:55 +0200
Subject: [PATCH] arm64: KVM: Kconfig integration
In-Reply-To: <1372939377-24657-1-git-send-email-marc.zyngier@arm.com>
References: <1372939377-24657-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <51D5682F.8040706@redhat.com>

Il 04/07/2013 14:02, Marc Zyngier ha scritto:
> Finally plug KVM/arm64 into the config system, making it possible
> to enable KVM support on AArch64 CPUs.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/Kconfig              |  2 ++
>  arch/arm64/kernel/asm-offsets.c |  1 +
>  arch/arm64/kvm/Kconfig          | 54 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 57 insertions(+)
>  create mode 100644 arch/arm64/kvm/Kconfig
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 4143d9b..9737e97 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -270,6 +270,8 @@ source "drivers/Kconfig"
>  
>  source "fs/Kconfig"
>  
> +source "arch/arm64/kvm/Kconfig"
> +
>  source "arch/arm64/Kconfig.debug"
>  
>  source "security/Kconfig"
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> index 49c162c..666e231 100644
> --- a/arch/arm64/kernel/asm-offsets.c
> +++ b/arch/arm64/kernel/asm-offsets.c
> @@ -21,6 +21,7 @@
>  #include <linux/sched.h>
>  #include <linux/mm.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/kvm_host.h>
>  #include <asm/thread_info.h>
>  #include <asm/memory.h>
>  #include <asm/cputable.h>
> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> new file mode 100644
> index 0000000..84f54f0
> --- /dev/null
> +++ b/arch/arm64/kvm/Kconfig
> @@ -0,0 +1,54 @@
> +#
> +# KVM configuration
> +#
> +
> +source "virt/kvm/Kconfig"
> +
> +menuconfig VIRTUALIZATION
> +	bool "Virtualization"
> +	---help---
> +	  Say Y here to get to see options for using your Linux host to run
> +	  other operating systems inside virtual machines (guests).
> +	  This option alone does not add any kernel code.
> +
> +	  If you say N, all options in this submenu will be skipped and
> +	  disabled.
> +
> +if VIRTUALIZATION
> +
> +config KVM
> +	bool "Kernel-based Virtual Machine (KVM) support"
> +	select MMU_NOTIFIER
> +	select PREEMPT_NOTIFIERS
> +	select ANON_INODES
> +	select KVM_MMIO
> +	select KVM_ARM_HOST
> +	select KVM_ARM_VGIC
> +	select KVM_ARM_TIMER
> +	---help---
> +	  Support hosting virtualized guest machines.
> +
> +	  This module provides access to the hardware capabilities through
> +	  a character device node named /dev/kvm.
> +
> +	  If unsure, say N.
> +
> +config KVM_ARM_HOST
> +	bool
> +	---help---
> +	  Provides host support for ARM processors.
> +
> +config KVM_ARM_VGIC
> +        bool

Spaces instead of tabs (another occurrence below).

Paolo

> +	depends on KVM_ARM_HOST && OF
> +	select HAVE_KVM_IRQCHIP
> +	---help---
> +	  Adds support for a hardware assisted, in-kernel GIC emulation.
> +
> +config KVM_ARM_TIMER
> +        bool
> +	depends on KVM_ARM_VGIC
> +	---help---
> +	  Adds support for the Architected Timers in virtual machines
> +
> +endif # VIRTUALIZATION
> 



From jonas.jensen at gmail.com  Thu Jul  4 08:19:43 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Thu,  4 Jul 2013 14:19:43 +0200
Subject: [PATCH v5] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <1372687359-18235-1-git-send-email-jonas.jensen@gmail.com>
References: <1372687359-18235-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1372940383-5957-1-git-send-email-jonas.jensen@gmail.com>

This patch adds an clocksource driver for the main timer(s)
found on MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130703
    
    Changes since v4:
    
    1. add general cache for TIMER_CR register

 drivers/clocksource/Makefile       |   1 +
 drivers/clocksource/moxart_timer.c | 163 +++++++++++++++++++++++++++++++++++++
 2 files changed, 164 insertions(+)
 create mode 100644 drivers/clocksource/moxart_timer.c

diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 9ba8b4d..56257f6 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_CLKSRC_DBX500_PRCMU)	+= clksrc-dbx500-prcmu.o
 obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
 obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
 obj-$(CONFIG_ARCH_MARCO)	+= timer-marco.o
+obj-$(CONFIG_ARCH_MOXART)	+= moxart_timer.o
 obj-$(CONFIG_ARCH_MXS)		+= mxs_timer.o
 obj-$(CONFIG_ARCH_PRIMA2)	+= timer-prima2.o
 obj-$(CONFIG_SUN4I_TIMER)	+= sun4i_timer.o
diff --git a/drivers/clocksource/moxart_timer.c b/drivers/clocksource/moxart_timer.c
new file mode 100644
index 0000000..61601ef
--- /dev/null
+++ b/drivers/clocksource/moxart_timer.c
@@ -0,0 +1,163 @@
+/*
+ * MOXA ART SoCs timer handling.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqreturn.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/io.h>
+#include <linux/clocksource.h>
+
+#define TIMER1_BASE		0x00
+#define TIMER2_BASE		0x10
+#define TIMER3_BASE		0x20
+
+#define REG_COUNT		0x0 /* writable */
+#define REG_LOAD		0x4
+#define REG_MATCH1		0x8
+#define REG_MATCH2		0xC
+
+#define TIMER_CR		0x30
+#define TIMER_INTR_STATE	0x34
+#define TIMER_INTR_MASK		0x38
+
+/*
+ * TIMER_CR flags:
+ *
+ * TIMEREG_CR_*_CLOCK	0: PCLK, 1: EXT1CLK
+ * TIMEREG_CR_*_INT	overflow interrupt enable bit
+ */
+#define TIMEREG_CR_1_ENABLE	(1 << 0)
+#define TIMEREG_CR_1_CLOCK	(1 << 1)
+#define TIMEREG_CR_1_INT	(1 << 2)
+#define TIMEREG_CR_2_ENABLE	(1 << 3)
+#define TIMEREG_CR_2_CLOCK	(1 << 4)
+#define TIMEREG_CR_2_INT	(1 << 5)
+#define TIMEREG_CR_3_ENABLE	(1 << 6)
+#define TIMEREG_CR_3_CLOCK	(1 << 7)
+#define TIMEREG_CR_3_INT	(1 << 8)
+#define TIMEREG_CR_COUNT_UP	(1 << 9)
+#define TIMEREG_CR_COUNT_DOWN	(0 << 9)
+
+static void __iomem *base;
+static unsigned int clock_count_per_tick;
+static u32 timereg_cache;
+
+static void moxart_clkevt_mode(enum clock_event_mode mode,
+			       struct clock_event_device *clk)
+{
+	switch (mode) {
+	case CLOCK_EVT_MODE_RESUME:
+	case CLOCK_EVT_MODE_ONESHOT:
+		writel(timereg_cache & ~TIMEREG_CR_1_ENABLE, base + TIMER_CR);
+		writel(~0, base + TIMER1_BASE + REG_LOAD);
+		break;
+	case CLOCK_EVT_MODE_PERIODIC:
+		writel(clock_count_per_tick, base + TIMER1_BASE + REG_LOAD);
+		writel(timereg_cache | TIMEREG_CR_1_ENABLE, base + TIMER_CR);
+		break;
+	case CLOCK_EVT_MODE_UNUSED:
+	case CLOCK_EVT_MODE_SHUTDOWN:
+	default:
+		writel(timereg_cache & ~TIMEREG_CR_1_ENABLE, base + TIMER_CR);
+		break;
+	}
+}
+
+static int moxart_clkevt_next_event(unsigned long cycles,
+				    struct clock_event_device *unused)
+{
+	u32 u;
+
+	writel(timereg_cache & ~TIMEREG_CR_1_ENABLE, base + TIMER_CR);
+
+	u = readl(base + TIMER1_BASE + REG_COUNT) - cycles;
+	writel(u, base + TIMER1_BASE + REG_MATCH1);
+
+	writel(timereg_cache | TIMEREG_CR_1_ENABLE, base + TIMER_CR);
+
+	return 0;
+}
+
+static struct clock_event_device moxart_clockevent = {
+	.name		= "moxart_timer",
+	.rating		= 200,
+	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
+	.set_mode	= moxart_clkevt_mode,
+	.set_next_event	= moxart_clkevt_next_event,
+};
+
+static irqreturn_t moxart_timer_interrupt(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+	evt->event_handler(evt);
+	return IRQ_HANDLED;
+}
+
+static struct irqaction moxart_timer_irq = {
+	.name		= "moxart-timer",
+	.flags		= IRQF_TIMER,
+	.handler	= moxart_timer_interrupt,
+	.dev_id		= &moxart_clockevent,
+};
+
+static void __init moxart_timer_init(struct device_node *node)
+{
+	int ret, irq;
+	unsigned long pclk;
+	struct clk *clk;
+
+	base = of_iomap(node, 0);
+	if (!base)
+		panic("%s: of_iomap failed\n", node->full_name);
+
+	irq = irq_of_parse_and_map(node, 0);
+	if (irq <= 0)
+		panic("%s: irq_of_parse_and_map failed\n", node->full_name);
+
+	ret = setup_irq(irq, &moxart_timer_irq);
+	if (ret)
+		panic("%s: setup_irq failed\n", node->full_name);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk))
+		panic("%s: of_clk_get failed\n", node->full_name);
+
+	pclk = clk_get_rate(clk);
+
+	if (clocksource_mmio_init(base + TIMER2_BASE + REG_COUNT,
+				  "moxart_timer", pclk, 200, 32,
+				  clocksource_mmio_readl_down))
+		panic("%s: clocksource_mmio_init failed\n", node->full_name);
+
+	clock_count_per_tick = DIV_ROUND_CLOSEST(pclk, HZ);
+
+	writel(~0, base + TIMER2_BASE + REG_LOAD);
+	timereg_cache = readl(base + TIMER_CR) | TIMEREG_CR_2_ENABLE;
+	writel(timereg_cache, base + TIMER_CR);
+
+	moxart_clockevent.cpumask = cpumask_of(0);
+
+	/*
+	 * documentation is not publicly available:
+	 * min_delta / max_delta obtained by trial-and-error,
+	 * max_delta 0xfffffffe should be ok because count
+	 * register size is u32
+	 */
+	clockevents_config_and_register(&moxart_clockevent, pclk,
+					0x4, 0xfffffffe);
+}
+CLOCKSOURCE_OF_DECLARE(moxart, "moxa,moxart-timer", moxart_timer_init);
-- 
1.8.2.1



From marc.zyngier at arm.com  Thu Jul  4 08:34:32 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Jul 2013 13:34:32 +0100
Subject: [PATCH v2] arm64: KVM: Kconfig integration
Message-ID: <1372941272-24919-1-git-send-email-marc.zyngier@arm.com>

Finally plug KVM/arm64 into the config system, making it possible
to enable KVM support on AArch64 CPUs.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/Kconfig              |  2 ++
 arch/arm64/kernel/asm-offsets.c |  1 +
 arch/arm64/kvm/Kconfig          | 51 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 54 insertions(+)
 create mode 100644 arch/arm64/kvm/Kconfig

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4143d9b..9737e97 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -270,6 +270,8 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
+source "arch/arm64/kvm/Kconfig"
+
 source "arch/arm64/Kconfig.debug"
 
 source "security/Kconfig"
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 49c162c..666e231 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -21,6 +21,7 @@
 #include <linux/sched.h>
 #include <linux/mm.h>
 #include <linux/dma-mapping.h>
+#include <linux/kvm_host.h>
 #include <asm/thread_info.h>
 #include <asm/memory.h>
 #include <asm/cputable.h>
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
new file mode 100644
index 0000000..21e9082
--- /dev/null
+++ b/arch/arm64/kvm/Kconfig
@@ -0,0 +1,51 @@
+#
+# KVM configuration
+#
+
+source "virt/kvm/Kconfig"
+
+menuconfig VIRTUALIZATION
+	bool "Virtualization"
+	---help---
+	  Say Y here to get to see options for using your Linux host to run
+	  other operating systems inside virtual machines (guests).
+	  This option alone does not add any kernel code.
+
+	  If you say N, all options in this submenu will be skipped and
+	  disabled.
+
+if VIRTUALIZATION
+
+config KVM
+	bool "Kernel-based Virtual Machine (KVM) support"
+	select MMU_NOTIFIER
+	select PREEMPT_NOTIFIERS
+	select ANON_INODES
+	select KVM_MMIO
+	select KVM_ARM_HOST
+	select KVM_ARM_VGIC
+	select KVM_ARM_TIMER
+	---help---
+	  Support hosting virtualized guest machines.
+
+	  If unsure, say N.
+
+config KVM_ARM_HOST
+	bool
+	---help---
+	  Provides host support for ARM processors.
+
+config KVM_ARM_VGIC
+	bool
+	depends on KVM_ARM_HOST && OF
+	select HAVE_KVM_IRQCHIP
+	---help---
+	  Adds support for a hardware assisted, in-kernel GIC emulation.
+
+config KVM_ARM_TIMER
+	bool
+	depends on KVM_ARM_VGIC
+	---help---
+	  Adds support for the Architected Timers in virtual machines.
+
+endif # VIRTUALIZATION
-- 
1.8.2.3




From marc.zyngier at arm.com  Thu Jul  4 08:38:54 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 04 Jul 2013 13:38:54 +0100
Subject: [PATCH] arm64: KVM: Kconfig integration
In-Reply-To: <51D5682F.8040706@redhat.com>
References: <1372939377-24657-1-git-send-email-marc.zyngier@arm.com>
 <51D5682F.8040706@redhat.com>
Message-ID: <51D56CDE.2010409@arm.com>

On 04/07/13 13:18, Paolo Bonzini wrote:
> Il 04/07/2013 14:02, Marc Zyngier ha scritto:
>> Finally plug KVM/arm64 into the config system, making it possible
>> to enable KVM support on AArch64 CPUs.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/Kconfig              |  2 ++
>>  arch/arm64/kernel/asm-offsets.c |  1 +
>>  arch/arm64/kvm/Kconfig          | 54 +++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 57 insertions(+)
>>  create mode 100644 arch/arm64/kvm/Kconfig
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 4143d9b..9737e97 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -270,6 +270,8 @@ source "drivers/Kconfig"
>>  
>>  source "fs/Kconfig"
>>  
>> +source "arch/arm64/kvm/Kconfig"
>> +
>>  source "arch/arm64/Kconfig.debug"
>>  
>>  source "security/Kconfig"
>> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
>> index 49c162c..666e231 100644
>> --- a/arch/arm64/kernel/asm-offsets.c
>> +++ b/arch/arm64/kernel/asm-offsets.c
>> @@ -21,6 +21,7 @@
>>  #include <linux/sched.h>
>>  #include <linux/mm.h>
>>  #include <linux/dma-mapping.h>
>> +#include <linux/kvm_host.h>
>>  #include <asm/thread_info.h>
>>  #include <asm/memory.h>
>>  #include <asm/cputable.h>
>> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
>> new file mode 100644
>> index 0000000..84f54f0
>> --- /dev/null
>> +++ b/arch/arm64/kvm/Kconfig
>> @@ -0,0 +1,54 @@
>> +#
>> +# KVM configuration
>> +#
>> +
>> +source "virt/kvm/Kconfig"
>> +
>> +menuconfig VIRTUALIZATION
>> +	bool "Virtualization"
>> +	---help---
>> +	  Say Y here to get to see options for using your Linux host to run
>> +	  other operating systems inside virtual machines (guests).
>> +	  This option alone does not add any kernel code.
>> +
>> +	  If you say N, all options in this submenu will be skipped and
>> +	  disabled.
>> +
>> +if VIRTUALIZATION
>> +
>> +config KVM
>> +	bool "Kernel-based Virtual Machine (KVM) support"
>> +	select MMU_NOTIFIER
>> +	select PREEMPT_NOTIFIERS
>> +	select ANON_INODES
>> +	select KVM_MMIO
>> +	select KVM_ARM_HOST
>> +	select KVM_ARM_VGIC
>> +	select KVM_ARM_TIMER
>> +	---help---
>> +	  Support hosting virtualized guest machines.
>> +
>> +	  This module provides access to the hardware capabilities through
>> +	  a character device node named /dev/kvm.
>> +
>> +	  If unsure, say N.
>> +
>> +config KVM_ARM_HOST
>> +	bool
>> +	---help---
>> +	  Provides host support for ARM processors.
>> +
>> +config KVM_ARM_VGIC
>> +        bool
> 
> Spaces instead of tabs (another occurrence below).

Sent v2 with fixes. If you're pleased with it, do you want another pull
request? Or will you just pick that patch?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From jonas.jensen at gmail.com  Thu Jul  4 08:38:51 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Thu,  4 Jul 2013 14:38:51 +0200
Subject: [PATCH v5] ARM: irqchip: add support for MOXA ART SoCs
In-Reply-To: <1372689241-18758-1-git-send-email-jonas.jensen@gmail.com>
References: <1372689241-18758-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1372941531-6393-1-git-send-email-jonas.jensen@gmail.com>

This patch adds an irqchip driver for the main interrupt controller found
on MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130703
    
    Changes since v4:
    
    1. shorten DT compatible value to "moxart-ic"
    2. use alphabetic ordering in Makefile

 drivers/irqchip/Makefile     |   1 +
 drivers/irqchip/irq-moxart.c | 118 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 119 insertions(+)
 create mode 100644 drivers/irqchip/irq-moxart.c

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 2065ef6..e65c41a 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_ARCH_MXS)			+= irq-mxs.o
 obj-$(CONFIG_ARCH_S3C24XX)		+= irq-s3c24xx.o
 obj-$(CONFIG_METAG)			+= irq-metag-ext.o
 obj-$(CONFIG_METAG_PERFCOUNTER_IRQS)	+= irq-metag.o
+obj-$(CONFIG_ARCH_MOXART)		+= irq-moxart.o
 obj-$(CONFIG_ORION_IRQCHIP)		+= irq-orion.o
 obj-$(CONFIG_ARCH_SUNXI)		+= irq-sun4i.o
 obj-$(CONFIG_ARCH_SPEAR3XX)		+= spear-shirq.o
diff --git a/drivers/irqchip/irq-moxart.c b/drivers/irqchip/irq-moxart.c
new file mode 100644
index 0000000..a9d9f36
--- /dev/null
+++ b/drivers/irqchip/irq-moxart.c
@@ -0,0 +1,118 @@
+/*
+ * MOXA ART SoCs IRQ chip driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/irqdomain.h>
+
+#include <asm/exception.h>
+
+#include "irqchip.h"
+
+#define IRQ_SOURCE_REG		0
+#define IRQ_MASK_REG		0x04
+#define IRQ_CLEAR_REG		0x08
+#define IRQ_MODE_REG		0x0c
+#define IRQ_LEVEL_REG		0x10
+#define IRQ_STATUS_REG		0x14
+
+#define FIQ_SOURCE_REG		0x20
+#define FIQ_MASK_REG		0x24
+#define FIQ_CLEAR_REG		0x28
+#define FIQ_MODE_REG		0x2c
+#define FIQ_LEVEL_REG		0x30
+#define FIQ_STATUS_REG		0x34
+
+
+struct moxart_irq_data {
+	void __iomem *base;
+	struct irq_domain *domain;
+	unsigned int interrupt_mask;
+};
+
+static struct moxart_irq_data intc;
+
+static asmlinkage void __exception_irq_entry handle_irq(struct pt_regs *regs)
+{
+	u32 irqstat;
+	int hwirq;
+
+	irqstat = readl(intc.base + IRQ_STATUS_REG);
+
+	while (irqstat) {
+		hwirq = ffs(irqstat) - 1;
+		handle_IRQ(irq_linear_revmap(intc.domain, hwirq), regs);
+		irqstat &= ~(1 << hwirq);
+	}
+}
+
+static int __init moxart_of_intc_init(struct device_node *node,
+				      struct device_node *parent)
+{
+	unsigned int clr = IRQ_NOREQUEST | IRQ_NOPROBE | IRQ_NOAUTOEN;
+	int ret;
+	struct irq_chip_generic *gc;
+
+	intc.base = of_iomap(node, 0);
+	if (!intc.base) {
+		pr_err("%s: unable to map IC registers\n",
+		       node->full_name);
+		return -EINVAL;
+	}
+
+	intc.domain = irq_domain_add_linear(node, 32, &irq_generic_chip_ops,
+					    intc.base);
+	if (!intc.domain) {
+		pr_err("%s: unable to create IRQ domain\n", node->full_name);
+		return -EINVAL;
+	}
+
+	ret = irq_alloc_domain_generic_chips(intc.domain, 32, 1,
+					     "MOXARTINTC", handle_edge_irq,
+					     clr, 0, IRQ_GC_INIT_MASK_CACHE);
+	if (ret) {
+		pr_err("%s: could not allocate generic chip\n",
+		       node->full_name);
+		irq_domain_remove(intc.domain);
+		return -EINVAL;
+	}
+
+	ret = of_property_read_u32(node, "interrupt-mask",
+				   &intc.interrupt_mask);
+	if (ret)
+		pr_err("%s: could not read interrupt-mask DT property\n",
+		       node->full_name);
+
+	gc = irq_get_domain_generic_chip(intc.domain, 0);
+
+	gc->reg_base = intc.base;
+	gc->chip_types[0].regs.mask = IRQ_MASK_REG;
+	gc->chip_types[0].regs.ack = IRQ_CLEAR_REG;
+	gc->chip_types[0].chip.irq_ack = irq_gc_ack_set_bit;
+	gc->chip_types[0].chip.irq_mask = irq_gc_mask_clr_bit;
+	gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit;
+
+	writel(0, intc.base + IRQ_MASK_REG);
+	writel(0xffffffff, intc.base + IRQ_CLEAR_REG);
+
+	writel(intc.interrupt_mask, intc.base + IRQ_MODE_REG);
+	writel(intc.interrupt_mask, intc.base + IRQ_LEVEL_REG);
+
+	set_handle_irq(handle_irq);
+
+	return 0;
+}
+IRQCHIP_DECLARE(moxa_moxart_ic, "moxa,moxart-ic",
+		moxart_of_intc_init);
-- 
1.8.2.1



From pbonzini at redhat.com  Thu Jul  4 08:40:55 2013
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Thu, 04 Jul 2013 14:40:55 +0200
Subject: [PATCH] arm64: KVM: Kconfig integration
In-Reply-To: <51D56CDE.2010409@arm.com>
References: <1372939377-24657-1-git-send-email-marc.zyngier@arm.com>
 <51D5682F.8040706@redhat.com> <51D56CDE.2010409@arm.com>
Message-ID: <51D56D57.6000108@redhat.com>

Il 04/07/2013 14:38, Marc Zyngier ha scritto:
> Sent v2 with fixes. If you're pleased with it, do you want another pull
> request? Or will you just pick that patch?

Since it would be a fast forward, I can (and did) just pick that patch.

Paolo


From marc.zyngier at arm.com  Thu Jul  4 08:42:14 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 04 Jul 2013 13:42:14 +0100
Subject: [PATCH] arm64: KVM: Kconfig integration
In-Reply-To: <51D56D57.6000108@redhat.com>
References: <1372939377-24657-1-git-send-email-marc.zyngier@arm.com>
 <51D5682F.8040706@redhat.com> <51D56CDE.2010409@arm.com>
 <51D56D57.6000108@redhat.com>
Message-ID: <51D56DA6.603@arm.com>

On 04/07/13 13:40, Paolo Bonzini wrote:
> Il 04/07/2013 14:38, Marc Zyngier ha scritto:
>> Sent v2 with fixes. If you're pleased with it, do you want another pull
>> request? Or will you just pick that patch?
> 
> Since it would be a fast forward, I can (and did) just pick that patch.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From js at sig21.net  Thu Jul  4 09:00:17 2013
From: js at sig21.net (Johannes Stezenbach)
Date: Thu, 4 Jul 2013 15:00:17 +0200
Subject: SPI: DUAL/QUAD support
In-Reply-To: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
Message-ID: <20130704130017.GA25997@sig21.net>

On Thu, Jul 04, 2013 at 07:36:48PM +0800, yuhang wang wrote:
> 
> I have added the kerneldoc into the patch below to explain the "DUAL"
> and "QUAD" modes.
> Hope for your suggestions.
> 
> Documentation/spi/spi-dual_quad |  102 +++++++++++++++++++++++++++++++++++++++
>  drivers/mtd/devices/m25p80.c    |    2 +
>  drivers/spi/spi.c               |    2 +
>  include/linux/spi/spi.h         |    8 +++

I think what Mark meant is to add new fields to the /** comments
in include/linux/spi/spi.h, then documentation could be generated
(but it seems only outdated copies are online, everyone prefers
to look at the code):
https://www.kernel.org/doc/htmldocs/device-drivers/

> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -354,6 +354,7 @@ static int m25p80_read(struct mtd_info *mtd,
> loff_t from, size_t len,
> 
>         t[1].rx_buf = buf;
>         t[1].len = len;
> +       t[1].bitwidth = flash->spi->rx_bitwidth;
>         spi_message_add_tail(&t[1], &m);
> 
>         mutex_lock(&flash->lock);
> @@ -409,6 +410,7 @@ static int m25p80_write(struct mtd_info *mtd,
> loff_t to, size_t len,
>         spi_message_add_tail(&t[0], &m);
> 
>         t[1].tx_buf = buf;
> +       t[1].bitwidth = flash->spi->tx_bitwidth;
>         spi_message_add_tail(&t[1], &m);
> 
>         mutex_lock(&flash->lock);

Doesn't m25p80 need to use different commands (OPCODEs)
for 2x and 4x speed?  It seems this change is incomplete.

Thanks,
Johannes


From jonas.jensen at gmail.com  Thu Jul  4 09:08:12 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Thu,  4 Jul 2013 15:08:12 +0200
Subject: [PATCH v2] clk: add MOXA ART SoCs clock driver
In-Reply-To: <1372341834-6557-1-git-send-email-jonas.jensen@gmail.com>
References: <1372341834-6557-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1372943292-6960-1-git-send-email-jonas.jensen@gmail.com>

This patch adds MOXA ART SoCs clock driver support.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    of_clk_init(NULL) is now called from moxart machine descriptor
    .init_time hook. clocksource now depend on this to be loaded first.
    
    Applies to next-20130703
    
    Changes since v1:
    1. rewritten to register one fixed rate clock "clkapb"
    2. use CLK_OF_DECLARE

 drivers/clk/Makefile     |  1 +
 drivers/clk/clk-moxart.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 83 insertions(+)
 create mode 100644 drivers/clk/clk-moxart.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4038c2b..933622f 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_COMMON_CLK)	+= clk-composite.o
 
 # SoCs specific
 obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
+obj-$(CONFIG_ARCH_MOXART)	+= clk-moxart.o
 obj-$(CONFIG_ARCH_NOMADIK)	+= clk-nomadik.o
 obj-$(CONFIG_ARCH_HIGHBANK)	+= clk-highbank.o
 obj-$(CONFIG_ARCH_NSPIRE)	+= clk-nspire.o
diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
new file mode 100644
index 0000000..d61e305
--- /dev/null
+++ b/drivers/clk/clk-moxart.c
@@ -0,0 +1,82 @@
+/*
+ * MOXA ART SoCs clock driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/platform_device.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/slab.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/clkdev.h>
+
+static const struct of_device_id moxart_tclk_match[] = {
+	{ .compatible = "moxa,moxart-apb-clock" },
+	{ }
+};
+
+void __init moxart_of_clk_init(struct device_node *node)
+{
+	static void __iomem *base;
+	struct device_node *clk_node;
+	struct clk *clk;
+	unsigned long rate;
+	unsigned int mul, val, div;
+
+	base = of_iomap(node, 0);
+	if (IS_ERR(base))
+		panic("%s: of_iomap failed\n", node->full_name);
+
+	clk_node = of_find_matching_node(NULL, moxart_tclk_match);
+	if (!clk_node)
+		panic("%s: can't find clock DT node\n", node->full_name);
+
+	mul = (readl(base + 0x30) >> 3) & 0x1ff;
+	val = (readl(base + 0x0c) >> 4) & 0x7;
+
+	switch (val) {
+	case 1:
+		div = 3;
+		break;
+	case 2:
+		div = 4;
+		break;
+	case 3:
+		div = 6;
+		break;
+	case 4:
+		div = 8;
+		break;
+	default:
+		div = 2;
+		break;
+	}
+
+	/*
+	 * the rate calculation below is only tested and proven
+	 * to be true for UC-7112-LX
+	 *
+	 * UC-7112-LX: mul=80 val=0
+	 *
+	 * to support other moxart SoC hardware, this may need
+	 * a change, though it's possible it works there too
+	 */
+	rate = (mul * 1200000 / div);
+
+	clk = clk_register_fixed_rate(NULL, "clkapb", NULL, CLK_IS_ROOT, rate);
+	clk_register_clkdev(clk, NULL, "clkapb");
+	of_clk_add_provider(clk_node, of_clk_src_simple_get, clk);
+
+	iounmap(base);
+}
+CLK_OF_DECLARE(moxart_core_clock, "moxa,moxart-core-clock", moxart_of_clk_init);
-- 
1.8.2.1



From linux at arm.linux.org.uk  Thu Jul  4 09:16:41 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 4 Jul 2013 14:16:41 +0100
Subject: Oops on 'cat /dev/kmem'
In-Reply-To: <ly8v1m5zl9.fsf@ensc-virt.intern.sigma-chemnitz.de>
References: <ly8v1m5zl9.fsf@ensc-virt.intern.sigma-chemnitz.de>
Message-ID: <20130704131641.GJ24642@n2100.arm.linux.org.uk>

On Thu, Jul 04, 2013 at 01:33:38PM +0200, Enrico Scholz wrote:
> Hi,
> 
> read access on /dev/kmem oopses here on pxa168 and omap3 platforms
> (kernel 3.4 and 3.2):
> 
> ~ # cat /dev/kmem 
> [ 2925.599453] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [ 2925.649173] pgd = c7a7c000
> [ 2925.657282] [00000000] *pgd=071a0831, *pte=00000000, *ppte=00000000
> [ 2925.697821] Internal error: Oops: 17 [#1] PREEMPT ARM
> [ 2925.712938] Modules linked in: ...
> [ 2925.825207] CPU: 0    Not tainted  (3.4.52.ipan7 #1)
> [ 2925.840083] PC is at __copy_to_user_std+0x4c/0x3a8
> [ 2925.854431] LR is at read_kmem+0xa0/0x1d4
> [ 2925.866438] pc : [<c01e768c>]    lr : [<c02304bc>]    psr: 20000013
> 
> 
> What would be the correct fix? Defining '__ARCH_HAS_NO_PAGE_ZERO_MAPPED'
> also for ARM?

That will just solve the "problem" for the first page.

It looks to me that cat'ing /dev/kmem on x86 will also lead to similar
effects, as it will end up trying to read from the virtual address
given by the file position.

I think this is a case of "don't do that then" - in much the same way
that on x86, if you configure a serial port at an address where another
device may be, you can end up killing the machine.

You have to be root to access /dev/kmem, and root is expected to know
what they're doing.


From mpfj-list at newflow.co.uk  Thu Jul  4 09:25:58 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Thu, 04 Jul 2013 14:25:58 +0100
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
Message-ID: <51D577E6.5010507@newflow.co.uk>

Our custom AM335x board has been booting just fine under 3.10.0-rc4.

I've just done a git pull to update to 3.10 (now that it's released)
and the board now hangs.

Before I start trying to bisect the issue, does anyone have an clues ?

I've attached my dotconfig.

Cheers
Mark J.

<<<< BAD BOOT >>>>

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.10.0-05288-g526a1a9-dirty (mpfj at mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #260 Thu Jul 4 13:43:19 BST 2013
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow AM335x NanoBone
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 65280
[    0.000000] free_area_init_node: node 0, pgdat c05d2c84, node_mem_map c0b06000
[    0.000000]   Normal zone: 512 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 65280 pages, LIFO batch:15
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64768
[    0.000000] Kernel command line: earlyprintk debug console=ttyO0,115200n8 noinitrd ip=off mem=256M rootwait=1 rootfstype=jffs2 root=/dev/mtdblock4 ignore_loglevel
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 247508K/261120K available (4372K kernel code, 334K rwdata, 1016K rodata, 202K init, 5305K bss, 13612K reserved, 0K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]       .text : 0xc0008000 - 0xc054b4e4   (5390 kB)
[    0.000000]       .init : 0xc054c000 - 0xc057eb74   ( 203 kB)
[    0.000000]       .data : 0xc0580000 - 0xc05d38a0   ( 335 kB)
[    0.000000]        .bss : 0xc05d38a0 - 0xc0b01f08   (5306 kB)
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: timer2 at 26000000 Hz
[    0.000000] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every 165191ms
[    0.000000] OMAP clocksource: timer1 at 26000000 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.062349] Calibrating delay loop... 363.72 BogoMIPS (lpj=1818624)
[    0.119097] pid_max: default: 32768 minimum: 301
[    0.124246] Security Framework initialized
[    0.128690] Mount-cache hash table entries: 512
[    0.146814] CPU: Testing write buffer coherency: ok
[    0.153481] Setting up static identity map for 0xc0426b20 - 0xc0426b78
[    0.164988] devtmpfs: initialized

<<<< GOOD BOOT >>>>

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.10.0-rc4-00172-gf31c62e-dirty (mpfj at mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #259 Thu Jul 4 11:05:23 BST 2013
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow AM335x NanoBone
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 65280
[    0.000000] free_area_init_node: node 0, pgdat c05c8a3c, node_mem_map c0afc000
[    0.000000]   Normal zone: 512 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 65280 pages, LIFO batch:15
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64768
[    0.000000] Kernel command line: earlyprintk debug console=ttyO0,115200n8 noinitrd ip=off mem=256M rootwait=1 rootfstype=jffs2 root=/dev/mtdblock4 ignore_loglevel
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 255MB = 255MB total
[    0.000000] Memory: 247552k/247552k available, 14592k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]       .text : 0xc0008000 - 0xc054210c   (5353 kB)
[    0.000000]       .init : 0xc0543000 - 0xc05757ac   ( 202 kB)
[    0.000000]       .data : 0xc0576000 - 0xc05c9620   ( 334 kB)
[    0.000000]        .bss : 0xc05c9620 - 0xc0af7a88   (5306 kB)
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: timer2 at 26000000 Hz
[    0.000000] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every 165191ms
[    0.000000] OMAP clocksource: timer1 at 26000000 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.062209] Calibrating delay loop... 363.72 BogoMIPS (lpj=1818624)
[    0.119227] pid_max: default: 32768 minimum: 301
[    0.124383] Security Framework initialized
[    0.128826] Mount-cache hash table entries: 512
[    0.145982] CPU: Testing write buffer coherency: ok
[    0.152707] Setting up static identity map for 0xc041ed88 - 0xc041ede0
[    0.164118] devtmpfs: initialized
[    0.173232] ttyO0 used as console in debug mode: uart0 clocks will not be gated
[    0.242012] pinctrl core: initialized pinctrl subsystem
[    0.252653] regulator-dummy: no parameters
[    0.260174] NET: Registered protocol family 16
[    0.265723] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.295484] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[    0.303439] OMAP GPIO hardware version 0.1
[    0.310567] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[    0.320495] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[    0.330479] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[    0.356857] omap-gpmc 50000000.gpmc: could not find pctldev for node /pinmux at 44e10800/gpmc_pins, deferring probe
[    0.367516] platform 50000000.gpmc: Driver omap-gpmc requests probe deferral
[    0.375643] No ATAGs?
[    0.377853] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.385002] cpsw.0: No hwaddr in dt. Using c8:a0:30:83:91:be from efuse
[    0.391981] cpsw.1: No hwaddr in dt. Using c8:a0:30:83:91:bf from efuse
[    0.449213] bio: create slab <bio-0> at 0
[    0.463822] usbcore: registered new interface driver usbfs
[    0.470140] usbcore: registered new interface driver hub
[    0.476512] usbcore: registered new device driver usb
[    0.482966] omap_i2c 44e0b000.i2c: could not find pctldev for node /pinmux at 44e10800/i2c0_pins, deferring probe
[    0.493433] platform 44e0b000.i2c: Driver omap_i2c requests probe deferral
[    0.510569] cfg80211: Calling CRDA to update world regulatory domain
[    0.519405] Switching to clocksource timer1
[    0.585009] NET: Registered protocol family 2
[    0.591523] TCP established hash table entries: 2048 (order: 2, 16384 bytes)
[    0.599211] TCP bind hash table entries: 2048 (order: 4, 73728 bytes)
[    0.607185] TCP: Hash tables configured (established 2048 bind 2048)
[    0.614144] TCP: reno registered
[    0.617577] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.624133] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.632359] NET: Registered protocol family 1
[    0.638659] RPC: Registered named UNIX socket transport module.
[    0.644927] RPC: Registered udp transport module.
[    0.649858] RPC: Registered tcp transport module.
[    0.654821] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.662640] NetWinder Floating Point Emulator V0.97 (double precision)
[    0.683580] jffs2: version 2.2. ? 2001-2006 Red Hat, Inc.
[    0.689959] msgmni has been set to 483
[    0.699227] io scheduler noop registered
[    0.703370] io scheduler deadline registered
[    0.707997] io scheduler cfq registered (default)
[    0.714510] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[    0.723777] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.739698] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
[    0.747967] console [ttyO0] enabled, bootconsole disabled
[    0.747967] console [ttyO0] enabled, bootconsole disabled
[    0.762091] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89) is a OMAP UART1
[    0.772232] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90) is a OMAP UART2
[    0.782654] 481a6000.serial: ttyO3 at MMIO 0x481a6000 (irq = 60) is a OMAP UART3
[    0.792624] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is a OMAP UART4
[    0.802588] 481aa000.serial: ttyO5 at MMIO 0x481aa000 (irq = 62) is a OMAP UART5
[    0.843181] brd: module loaded
[    0.865884] loop: module loaded
[    0.874171] Generic platform RAM MTD, (c) 2004 Simtec Electronics
[    0.886752] usbcore: registered new interface driver rt2800usb
[    0.893362] usbcore: registered new interface driver asix
[    0.899570] usbcore: registered new interface driver cdc_ether
[    0.906226] usbcore: registered new interface driver smsc95xx
[    0.912745] usbcore: registered new interface driver net1080
[    0.919220] usbcore: registered new interface driver cdc_subset
[    0.925972] usbcore: registered new interface driver zaurus
[    0.932386] usbcore: registered new interface driver cdc_ncm
[    0.940627] usbcore: registered new interface driver cdc_wdm
[    0.947182] usbcore: registered new interface driver usbtest
[    0.953609] i2c /dev entries driver
[    0.962424] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    0.975466] usbcore: registered new interface driver usbhid
[    0.981346] usbhid: USB HID core driver
[    0.986783] oprofile: no performance counters
[    0.993932] oprofile: using timer interrupt.
[    0.999224] TCP: cubic registered
[    1.002724] Initializing XFRM netlink socket
[    1.007408] NET: Registered protocol family 17
[    1.012203] NET: Registered protocol family 15
[    1.017496] Key type dns_resolver registered
[    1.022171] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    1.030376] ThumbEE CPU extension supported.
[    1.039576] omap-gpmc 50000000.gpmc: GPMC revision 6.0
[    1.052059] spansion,s29gl010p11t: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x002266 Chip ID 0x00223e
[    1.063590] Amd/Fujitsu Extended Query Table at 0x0040
[    1.069058]   Amd/Fujitsu Extended Query version 1.3.
[    1.074426] number of CFI chips: 1
[    1.078250] 7 ofpart partitions found on MTD device spansion,s29gl010p11t
[    1.085438] Creating 7 MTD partitions on "spansion,s29gl010p11t":
[    1.091869] 0x000000000000-0x0000000c0000 : "boot"
[    1.104959] 0x0000000c0000-0x0000000e0000 : "env1"
[    1.115074] 0x0000000e0000-0x000000100000 : "env2"
[    1.124888] 0x000000100000-0x000000500000 : "kernel"
[    1.134892] 0x000000500000-0x000001500000 : "rootfs"
[    1.145051] 0x000001500000-0x000004000000 : "user"
[    1.154950] 0x000004000000-0x000008000000 : "data"
[    1.170564] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[    1.181724] gpiochip_find_base: found new base at 240
[    1.188394] gpiochip_add: registered GPIOs 240 to 255 on device: mcp23017
[    1.201011] DCDC1: at 1500 mV
[    1.206835] vdd_mpu: 925 <--> 1325 mV at 1100 mV
[    1.214128] vdd_core: 925 <--> 1150 mV at 1100 mV
[    1.221458] LDO1: at 1800 mV
[    1.226815] LDO2: at 3300 mV
[    1.232215] LDO3: at 1800 mV
[    1.237537] LDO4: at 3300 mV
[    1.242640] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[    1.249346] at24 0-0053: 256 byte 24c02 EEPROM, writable, 8 bytes/write
[    1.260583] rtc-ds1307 0-0068: rtc core: registered ds1307 as rtc0
[    1.267223] rtc-ds1307 0-0068: 56 bytes nvram
[    1.333979] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    1.340425] davinci_mdio 4a101000.mdio: detected phy mask fffffffc
[    1.350461] libphy: 4a101000.mdio: probed
[    1.354791] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[    1.364453] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, driver SMSC LAN8710/LAN8720
[    1.374403] Detected MACID = c8:a0:30:83:91:be
[    1.382355] cpsw: Detected MACID = c8:a0:30:83:91:bf
[    1.391359] rtc-ds1307 0-0068: setting system clock to 2000-01-23 22:06:49 UTC (948665209)
[    3.010550] VFS: Mounted root (jffs2 filesystem) readonly on device 31:4.
[    3.019030] devtmpfs: mounted
[    3.022638] Freeing unused kernel memory: 200K (c0543000 - c0575000)
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.10.0 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_ARCH_HAS_BANDGAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_SPARSE_IRQ=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
CONFIG_UIDGID_CONVERTED=y
# CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_EXPERT=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set

#
# Multiple platform selection
#

#
# CPU Core family selection
#
# CONFIG_ARCH_MULTI_V6 is not set
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_ARCH_BCM is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_KEYSTONE is not set
# CONFIG_ARCH_MXC is not set

#
# TI OMAP Common Features
#

#
# OMAP Feature Selections
#
CONFIG_OMAP_RESET_CLOCKS=y
CONFIG_OMAP_MUX=y
CONFIG_OMAP_MUX_DEBUG=y
CONFIG_OMAP_MUX_WARNINGS=y
CONFIG_OMAP_32K_TIMER=y
# CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE is not set
CONFIG_OMAP_DM_TIMER=y
CONFIG_OMAP_PM_NOOP=y
CONFIG_MACH_OMAP_GENERIC=y
CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP2PLUS=y

#
# TI OMAP2/3/4 Specific Features
#
CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
CONFIG_SOC_HAS_OMAP2_SDRC=y
CONFIG_ARCH_OMAP3=y
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_OMAP5 is not set
# CONFIG_SOC_OMAP3430 is not set
CONFIG_SOC_TI81XX=y
CONFIG_SOC_AM33XX=y
# CONFIG_SOC_AM43XX is not set

#
# OMAP Board Type
#
# CONFIG_MACH_OMAP3_BEAGLE is not set
# CONFIG_MACH_DEVKIT8000 is not set
# CONFIG_MACH_OMAP_LDP is not set
# CONFIG_MACH_OMAP3530_LV_SOM is not set
# CONFIG_MACH_OMAP3_TORPEDO is not set
# CONFIG_MACH_OVERO is not set
# CONFIG_MACH_OMAP3EVM is not set
# CONFIG_MACH_OMAP3517EVM is not set
# CONFIG_MACH_CRANEBOARD is not set
# CONFIG_MACH_OMAP3_PANDORA is not set
# CONFIG_MACH_TOUCHBOOK is not set
# CONFIG_MACH_OMAP_3430SDP is not set
# CONFIG_MACH_NOKIA_RM680 is not set
# CONFIG_MACH_NOKIA_RX51 is not set
# CONFIG_MACH_OMAP_ZOOM2 is not set
# CONFIG_MACH_OMAP_ZOOM3 is not set
# CONFIG_MACH_CM_T35 is not set
# CONFIG_MACH_CM_T3517 is not set
# CONFIG_MACH_IGEP0020 is not set
# CONFIG_MACH_IGEP0030 is not set
# CONFIG_MACH_SBC3530 is not set
# CONFIG_MACH_OMAP_3630SDP is not set
# CONFIG_MACH_TI8168EVM is not set
# CONFIG_MACH_TI8148EVM is not set
# CONFIG_OMAP3_EMU is not set
# CONFIG_OMAP3_SDRC_AC_TIMING is not set
# CONFIG_ARCH_ROCKCHIP is not set
# CONFIG_ARCH_SOCFPGA is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_STI is not set
# CONFIG_ARCH_SUNXI is not set
# CONFIG_ARCH_SIRF is not set
# CONFIG_ARCH_TEGRA is not set

#
# ST-Ericsson AB U300/U335 Platform
#

#
# ST-Ericsson Mobile Platform Products
#

#
# ST-Ericsson U300/U335 Feature Selections
#
# CONFIG_ARCH_U8500 is not set
CONFIG_ARCH_VEXPRESS=y

#
# Versatile Express platform type
#
# CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
# CONFIG_ARCH_VEXPRESS_CA9X4 is not set
CONFIG_PLAT_VERSATILE_CLCD=y
CONFIG_PLAT_VERSATILE_SCHED_CLOCK=y
# CONFIG_ARCH_VIRT is not set
# CONFIG_ARCH_WM8850 is not set
# CONFIG_ARCH_ZYNQ is not set
CONFIG_PLAT_VERSATILE=y
CONFIG_ARM_TIMER_SP804=y

#
# Processor Type
#
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_LPAE is not set
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
CONFIG_ARM_THUMBEE=y
CONFIG_ARM_VIRT_EXT=y
# CONFIG_SWP_EMULATE is not set
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_CACHE_PL310=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_430973 is not set
CONFIG_PL310_ERRATA_588369=y
CONFIG_ARM_ERRATA_720789=y
CONFIG_PL310_ERRATA_727915=y
# CONFIG_PL310_ERRATA_753970 is not set
# CONFIG_ARM_ERRATA_754322 is not set
# CONFIG_PL310_ERRATA_769419 is not set
# CONFIG_ARM_ERRATA_775420 is not set
CONFIG_ICST=y
CONFIG_TI_PRIV_EDMA=y

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_HAVE_SMP=y
# CONFIG_SMP is not set
CONFIG_HAVE_ARM_ARCH_TIMER=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_ARM_PSCI is not set
CONFIG_ARCH_NR_GPIO=0
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
CONFIG_HW_PERF_EVENTS=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_XEN is not set

#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
CONFIG_KEXEC=y
CONFIG_ATAGS_PROC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set
# CONFIG_GENERIC_CPUFREQ_CPU0 is not set

#
# ARM CPU frequency scaling drivers
#
# CONFIG_ARM_EXYNOS4210_CPUFREQ is not set
# CONFIG_ARM_EXYNOS4X12_CPUFREQ is not set
# CONFIG_ARM_EXYNOS5250_CPUFREQ is not set
# CONFIG_ARM_EXYNOS5440_CPUFREQ is not set
# CONFIG_ARM_KIRKWOOD_CPUFREQ is not set
CONFIG_ARM_OMAP2PLUS_CPUFREQ=y
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_COREDUMP=y

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_PM_SLEEP_DEBUG=y
# CONFIG_APM_EMULATION is not set
CONFIG_ARCH_HAS_OPP=y
CONFIG_PM_OPP=y
CONFIG_PM_CLK=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_XFRM_MIGRATE=y
# CONFIG_XFRM_STATISTICS is not set
CONFIG_NET_KEY=y
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_NET_IP_TUNNEL is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_IPVTI is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_ACCT is not set
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NETFILTER_XTABLES is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV4 is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_NETLINK_DIAG is not set
CONFIG_BQL=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
# CONFIG_CFG80211_CERTIFICATION_ONUS is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
# CONFIG_CFG80211_WEXT is not set
# CONFIG_LIB80211 is not set
CONFIG_MAC80211=y
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
CONFIG_MAC80211_RC_DEFAULT_PID=y
# CONFIG_MAC80211_RC_DEFAULT_MINSTREL is not set
CONFIG_MAC80211_RC_DEFAULT="pid"
# CONFIG_MAC80211_MESH is not set
# CONFIG_MAC80211_LEDS is not set
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_MESSAGE_TRACING is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_SOC_BUS=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
# CONFIG_DMA_SHARED_BUFFER is not set
# CONFIG_CMA is not set

#
# Bus devices
#
# CONFIG_OMAP_OCP2SCP is not set
CONFIG_OMAP_INTERCONNECT=y
# CONFIG_ARM_CCI is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_MTD=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_OF_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_RAM=y
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
# CONFIG_MTD_PHYSMAP_COMPAT is not set
CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_PLATRAM=y

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SST25L is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
CONFIG_MTD_BLOCK2MTD=y

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
CONFIG_BCH_CONST_M=13
CONFIG_BCH_CONST_T=8
CONFIG_MTD_NAND_ECC=y
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_ECC_BCH is not set
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_DENALI is not set
# CONFIG_MTD_NAND_GPIO is not set
CONFIG_MTD_NAND_OMAP2=y
CONFIG_MTD_NAND_OMAP_BCH=y
CONFIG_MTD_NAND_OMAP_BCH8=y
# CONFIG_MTD_NAND_OMAP_BCH4 is not set
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_DOCG4 is not set
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_ALAUDA is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
# CONFIG_MTD_UBI_GLUEBI is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
CONFIG_PROC_DEVICETREE=y
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
CONFIG_OF_MTD=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLK_DEV_RBD is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_TI_DAC7512 is not set
# CONFIG_ARM_CHARLCD is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_BMP085_SPI is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_LATTICE_ECP3_CONFIG is not set
# CONFIG_SRAM is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
CONFIG_EEPROM_AT24=y
# CONFIG_EEPROM_AT25 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_EEPROM_93XX46 is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_HAVE_PATA_PLATFORM=y
# CONFIG_ATA is not set
# CONFIG_MD is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
# CONFIG_NET_VENDOR_CIRRUS is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
# CONFIG_NET_VENDOR_FARADAY is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_NET_VENDOR_MARVELL is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROCHIP is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_ETHOC is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SMSC is not set
# CONFIG_NET_VENDOR_STMICRO is not set
CONFIG_NET_VENDOR_TI=y
# CONFIG_TI_DAVINCI_EMAC is not set
CONFIG_TI_DAVINCI_MDIO=y
CONFIG_TI_DAVINCI_CPDMA=y
CONFIG_TI_CPSW=y
# CONFIG_TI_CPTS is not set
# CONFIG_NET_VENDOR_WIZNET is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
CONFIG_SMSC_PHY=y
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_RTL8152 is not set
CONFIG_USB_USBNET=y
CONFIG_USB_NET_AX8817X=y
# CONFIG_USB_NET_AX88179_178A is not set
CONFIG_USB_NET_CDCETHER=y
# CONFIG_USB_NET_CDC_EEM is not set
CONFIG_USB_NET_CDC_NCM=y
# CONFIG_USB_NET_CDC_MBIM is not set
# CONFIG_USB_NET_DM9601 is not set
# CONFIG_USB_NET_SMSC75XX is not set
CONFIG_USB_NET_SMSC95XX=y
# CONFIG_USB_NET_GL620A is not set
CONFIG_USB_NET_NET1080=y
# CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_MCS7830 is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
CONFIG_USB_NET_CDC_SUBSET=y
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_KC2190=y
CONFIG_USB_NET_ZAURUS=y
# CONFIG_USB_NET_CX82310_ETH is not set
# CONFIG_USB_NET_KALMIA is not set
# CONFIG_USB_NET_QMI_WWAN is not set
# CONFIG_USB_NET_INT51X1 is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_USB_SIERRA_NET is not set
# CONFIG_USB_VL600 is not set
CONFIG_WLAN=y
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AT76C50X_USB is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8187 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_ATH_CARDS is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_BRCMFMAC is not set
# CONFIG_HOSTAP is not set
# CONFIG_LIBERTAS is not set
# CONFIG_P54_COMMON is not set
CONFIG_RT2X00=y
# CONFIG_RT2500USB is not set
# CONFIG_RT73USB is not set
CONFIG_RT2800USB=y
CONFIG_RT2800USB_RT33XX=y
CONFIG_RT2800USB_RT35XX=y
# CONFIG_RT2800USB_RT53XX is not set
# CONFIG_RT2800USB_RT55XX is not set
# CONFIG_RT2800USB_UNKNOWN is not set
CONFIG_RT2800_LIB=y
CONFIG_RT2X00_LIB_USB=y
CONFIG_RT2X00_LIB=y
CONFIG_RT2X00_LIB_FIRMWARE=y
CONFIG_RT2X00_LIB_CRYPTO=y
CONFIG_RT2X00_LIB_LEDS=y
# CONFIG_RT2X00_DEBUG is not set
# CONFIG_RTLWIFI is not set
# CONFIG_WL_TI is not set
# CONFIG_ZD1211RW is not set
# CONFIG_MWIFIEX is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EM is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
# CONFIG_SERIAL_AMBA_PL011 is not set
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_OF_PLATFORM is not set
CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_ATMEL is not set
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_NOMADIK is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_OMAP=y
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_VERSATILE is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_GPIO is not set
# CONFIG_SPI_FSL_SPI is not set
# CONFIG_SPI_OC_TINY is not set
CONFIG_SPI_OMAP24XX=y
# CONFIG_SPI_PL022 is not set
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_XCOMM is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set

#
# Qualcomm MSM SSBI bus support
#
# CONFIG_SSBI is not set
# CONFIG_HSI is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
CONFIG_PINCTRL=y

#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_GENERIC_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
CONFIG_PINCTRL_SINGLE=y
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
# CONFIG_GPIO_PL061 is not set
# CONFIG_GPIO_RCAR is not set
# CONFIG_GPIO_TS5500 is not set
# CONFIG_GPIO_GRGPIO is not set

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_TWL4030 is not set
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
CONFIG_GPIO_MCP23S08=y
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_74X164 is not set

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#

#
# USB GPIO expanders:
#
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_TWL4030 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_GPIO is not set
# CONFIG_CHARGER_MANAGER is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_SMB347 is not set
# CONFIG_BATTERY_GOLDFISH is not set
CONFIG_POWER_RESET=y
# CONFIG_POWER_RESET_GPIO is not set
# CONFIG_POWER_RESET_RESTART is not set
CONFIG_POWER_RESET_VEXPRESS=y
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ARM_SP805_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
CONFIG_OMAP_WATCHDOG=y
CONFIG_TWL4030_WATCHDOG=y
# CONFIG_MAX63XX_WATCHDOG is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65090 is not set
CONFIG_MFD_TPS65217=y
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TPS80031 is not set
CONFIG_TWL4030_CORE=y
# CONFIG_TWL4030_MADC is not set
CONFIG_TWL4030_POWER=y
# CONFIG_MFD_TWL4030_AUDIO is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
CONFIG_VEXPRESS_CONFIG=y
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
# CONFIG_REGULATOR_DUMMY is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_GPIO is not set
# CONFIG_REGULATOR_AD5398 is not set
# CONFIG_REGULATOR_FAN53555 is not set
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
# CONFIG_REGULATOR_MAX8973 is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_LP872X is not set
# CONFIG_REGULATOR_LP8755 is not set
# CONFIG_REGULATOR_TPS51632 is not set
# CONFIG_REGULATOR_TPS62360 is not set
CONFIG_REGULATOR_TPS65023=y
CONFIG_REGULATOR_TPS6507X=y
CONFIG_REGULATOR_TPS65217=y
# CONFIG_REGULATOR_TPS6524X is not set
CONFIG_REGULATOR_TWL4030=y
# CONFIG_REGULATOR_TI_ABB is not set
# CONFIG_REGULATOR_VEXPRESS is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_TEGRA_HOST1X is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_OMAP2_DSS is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=y
# CONFIG_HID_BATTERY_STRENGTH is not set
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_APPLEIR is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MAGICMOUSE is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_PS3REMOTE is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THINGM is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_WACOM is not set
# CONFIG_HID_WIIMOTE is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set

#
# USB HID support
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_FUSBH200_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
CONFIG_USB_WDM=y
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_DWC3 is not set
# CONFIG_USB_CHIPIDEA is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
CONFIG_USB_TEST=y
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set
# CONFIG_USB_HSIC_USB3503 is not set
# CONFIG_USB_PHY is not set
# CONFIG_USB_GADGET is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_UNSAFE_RESUME=y
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_SDIO_UART=y
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_ARMMMCI is not set
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
# CONFIG_MMC_DW is not set
# CONFIG_MMC_VUB300 is not set
# CONFIG_MMC_USHC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_GPIO is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_LP5562 is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA9633 is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_REGULATOR is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_LT3593 is not set
# CONFIG_LEDS_RENESAS_TPU is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_LM355x is not set
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set

#
# LED Triggers
#
# CONFIG_LEDS_TRIGGERS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=y
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF2127 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_TWL4030 is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
# CONFIG_RTC_DRV_RX4581 is not set

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# CONFIG_RTC_DRV_DS2404 is not set

#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_OMAP is not set
# CONFIG_RTC_DRV_PL030 is not set
# CONFIG_RTC_DRV_PL031 is not set
# CONFIG_RTC_DRV_SNVS is not set

#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
# CONFIG_AMBA_PL08X is not set
# CONFIG_DW_DMAC is not set
# CONFIG_TIMB_DMA is not set
CONFIG_TI_EDMA=y
# CONFIG_PL330_DMA is not set
CONFIG_DMA_OMAP=y
CONFIG_DMA_ENGINE=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DMA_OF=y

#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VIRT_DRIVERS is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_DEBUG is not set
CONFIG_COMMON_CLK_VERSATILE=y
# CONFIG_COMMON_CLK_SI5351 is not set

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_OF=y
CONFIG_CLKSRC_MMIO=y
CONFIG_ARM_ARCH_TIMER=y
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y
# CONFIG_OMAP_IOMMU is not set

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_PWM is not set
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_FMC is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
# CONFIG_EXT3_FS_XATTR is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
# CONFIG_FS_POSIX_ACL is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
# CONFIG_JFFS2_FS_WRITEBUFFER is not set
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_FS_XATTR is not set
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_LZO=y
CONFIG_JFFS2_RTIME=y
CONFIG_JFFS2_RUBIN=y
CONFIG_JFFS2_CMODE_NONE=y
# CONFIG_JFFS2_CMODE_PRIORITY is not set
# CONFIG_JFFS2_CMODE_SIZE is not set
# CONFIG_JFFS2_CMODE_FAVOURLZO is not set
CONFIG_UBIFS_FS=y
CONFIG_UBIFS_FS_ADVANCED_COMPR=y
CONFIG_UBIFS_FS_LZO=y
# CONFIG_UBIFS_FS_ZLIB is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_SWAP is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_NLS_UTF8 is not set

#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set

#
# RCU Debugging
#
# CONFIG_PROVE_RCU is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_ENABLE_DEFAULT_TRACERS is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_PROBE_EVENTS is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_RING_BUFFER_STARTUP_TEST is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
# CONFIG_DEBUG_USER is not set
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_OMAP2PLUS_UART=y
# CONFIG_DEBUG_VEXPRESS_UART0_DETECT is not set
# CONFIG_DEBUG_VEXPRESS_UART0_CA9 is not set
# CONFIG_DEBUG_VEXPRESS_UART0_RS1 is not set
# CONFIG_DEBUG_ICEDCC is not set
# CONFIG_DEBUG_SEMIHOSTING is not set
# CONFIG_DEBUG_OMAP2UART1 is not set
# CONFIG_DEBUG_OMAP2UART2 is not set
# CONFIG_DEBUG_OMAP2UART3 is not set
# CONFIG_DEBUG_OMAP3UART3 is not set
# CONFIG_DEBUG_OMAP4UART3 is not set
# CONFIG_DEBUG_OMAP3UART4 is not set
# CONFIG_DEBUG_OMAP4UART4 is not set
# CONFIG_DEBUG_TI81XXUART1 is not set
# CONFIG_DEBUG_TI81XXUART2 is not set
# CONFIG_DEBUG_TI81XXUART3 is not set
CONFIG_DEBUG_AM33XXUART1=y
# CONFIG_DEBUG_ZOOM_UART is not set
CONFIG_DEBUG_LL_INCLUDE="debug/omap2plus.S"
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
CONFIG_EARLY_PRINTK=y
# CONFIG_OC_ETM is not set
# CONFIG_PID_IN_CONTEXTIDR is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_ENCRYPTED_KEYS is not set
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_NETWORK is not set
# CONFIG_SECURITY_PATH is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set
# CONFIG_IMA is not set
# CONFIG_EVM is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA1_ARM is not set
CONFIG_CRYPTO_SHA256=y
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=y

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
CONFIG_CRC7=y
CONFIG_LIBCRC32C=y
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_BCH=y
CONFIG_BCH_CONST_PARAMS=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
# CONFIG_VIRTUALIZATION is not set

From weiyj.lk at gmail.com  Thu Jul  4 09:35:00 2013
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Thu, 4 Jul 2013 21:35:00 +0800
Subject: [PATCH] drm/exynos: exynos_drm_ipp: fix return value check
Message-ID: <CAPgLHd9yE7YES-yDFSWfHOKbbay2yLS_VrvF5-QyJumnNFitQw@mail.gmail.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

In case of error, the function ipp_find_obj() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index b1ef8e7..0eb8538 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -342,10 +342,10 @@ int exynos_drm_ipp_get_property(struct drm_device *drm_dev, void *data,
 		 */
 		ippdrv = ipp_find_obj(&ctx->ipp_idr, &ctx->ipp_lock,
 						prop_list->ipp_id);
-		if (!ippdrv) {
+		if (IS_ERR(ippdrv)) {
 			DRM_ERROR("not found ipp%d driver.\n",
 					prop_list->ipp_id);
-			return -EINVAL;
+			return PTR_ERR(ippdrv);
 		}
 
 		prop_list = ippdrv->prop_list;
@@ -970,9 +970,9 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, void *data,
 	/* find command node */
 	c_node = ipp_find_obj(&ctx->prop_idr, &ctx->prop_lock,
 		qbuf->prop_id);
-	if (!c_node) {
+	if (IS_ERR(c_node)) {
 		DRM_ERROR("failed to get command node.\n");
-		return -EFAULT;
+		return PTR_ERR(c_node);
 	}
 
 	/* buffer control */
@@ -1106,9 +1106,9 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev, void *data,
 
 	c_node = ipp_find_obj(&ctx->prop_idr, &ctx->prop_lock,
 		cmd_ctrl->prop_id);
-	if (!c_node) {
+	if (IS_ERR(c_node)) {
 		DRM_ERROR("invalid command node list.\n");
-		return -EINVAL;
+		return PTR_ERR(c_node);
 	}
 
 	if (!exynos_drm_ipp_check_valid(ippdrv->dev, cmd_ctrl->ctrl,



From weiyj.lk at gmail.com  Thu Jul  4 09:42:34 2013
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Thu, 4 Jul 2013 21:42:34 +0800
Subject: [PATCH] ARM: OMAP: fix return value check in
 omap_device_build_from_dt()
Message-ID: <CAPgLHd_E8wht4q5c9=TjUTwXxysjbbX+HnZyYe2KJU=w79cK4w@mail.gmail.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

In case of error, the function omap_device_alloc() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
 arch/arm/mach-omap2/omap_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..28e70c0 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -155,7 +155,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
 	}
 
 	od = omap_device_alloc(pdev, hwmods, oh_cnt);
-	if (!od) {
+	if (IS_ERR(od)) {
 		dev_err(&pdev->dev, "Cannot allocate omap_device for :%s\n",
 			oh_name);
 		ret = PTR_ERR(od);



From richard.genoud at gmail.com  Thu Jul  4 09:44:21 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Thu, 4 Jul 2013 15:44:21 +0200
Subject: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
In-Reply-To: <51D4CC94.3020908@atmel.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-2-git-send-email-richard.genoud@gmail.com>
 <51D24299.9050209@atmel.com>
 <CACQ1gAgcc=j3kmcpjp8bbdHhxr_k=h8jJs6R_paJbPUMv74uGg@mail.gmail.com>
 <51D29927.80900@atmel.com>
 <CACQ1gAhnDk-qSt_5xrsMakXqGGDO5pEbA-9UDWCJG=AABDc+zg@mail.gmail.com>
 <CACQ1gAgPaRm3gxxJNgfj9bR565Q0+SNY3+EcjA_mrh1N+yPzSA@mail.gmail.com>
 <51D4CC94.3020908@atmel.com>
Message-ID: <CACQ1gAio0ekQMgyfrLjTHmMPGJQoKoe61GreFQDN-iLjxbLQ0w@mail.gmail.com>

2013/7/4 Bo Shen <voice.shen at atmel.com>:
> Hi Richard,
>
>
> On 7/3/2013 23:51, Richard Genoud wrote:
>>>
>>> >but there's a violent hang (kernel stops, no trace) when I try the
>>> > record :
>>> >arecord -v -V stereo -Dplug:default -f cd -t wav -c 2 /tmp/toto.wav
>>> >last thing I see is :
>>> >dma dma0chan3: atc_control (3)
>
>
> I don't meet this issue. Playback and recording works well on my side on
> at91sam9g35ek board.
>
>
>>> >I'll try to trace that.
>>
>> I think it's DMA related.
>> the last thing done by the kernel is:
>>   i2c i2c-0: i2c_outb: 0x34 A
>>   i2c i2c-0: i2c_outb: 0x0c A
>>   i2c i2c-0: i2c_outb: 0x5a A
>> meaning: enable power on, LINE IN, ADC, OSC, on the WM8731
>> so, after that, data is comming from the codec to the SSC and then is
>> handled by the DMA.
>> there must be something nasty on the DMA bus to hang everything like
>> that...
>
>
> Will you try i2c without DMA support to test this issue?

Ok, I nailed it !

To be sure we are on the same base, here is what I have done:
onto next-20130704:
- your 5 patches:
ASoC: atmel_ssc_dai: move set dma data to startup callback
ASoC: atmel_ssc_dai: add error mask define
ASoC: atmel-pcm-dma: move prepare for dma to dai prepare
ARM: atmel-ssc: change phybase type to dma_addr_t
ASoC: atmel-pcm: use generic dmaengine framework
- my patches 4-8:
ARM: at91: DTS: sam9x5: add SSC DMA parameters
ARM: AT91: DTS: sam9x5ek: add WM8731 codec
ARM: AT91: DTS: sam9x5ek: add sound configuration
ARM: AT91: DTS: sam9x5ek: enable SSC
sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards

To be sure that dma-I2c doesn't disturb something, I use i2c gpio bitbang:
diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi
b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index 6684d4b..53a991e 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -57,15 +57,6 @@
 				status = "okay";
 			};

-			i2c0: i2c at f8010000 {
-				status = "okay";
-
-				wm8731: wm8731 at 1a {
-					compatible = "wm8731";
-					reg = <0x1a>;
-				};
-			};
-
 			pinctrl at fffff400 {
 				mmc0 {
 					pinctrl_board_mmc0: mmc0-board {
@@ -114,6 +105,15 @@
 		};
 	};

+	i2c at 0 {
+		status = "okay";
+
+		wm8731: wm8731 at 1a {
+			compatible = "wm8731";
+			reg = <0x1a>;
+		};
+	};
+
 	sound {
 		compatible = "atmel,sam9x5-audio-wm8731";

with that configuration, it hangs when I do a:
arecord -v -V stereo -Dplug:default -f cd -t wav -c 2 /tmp/toto.wav

Now, if I remove the overrun error on ssc in rx_mask:
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index 0ecf356..c04e825 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -83,7 +83,6 @@ static struct atmel_ssc_mask ssc_rx_mask = {
 	.ssc_disable	= SSC_BIT(CR_RXDIS),
 	.ssc_endx	= SSC_BIT(SR_ENDRX),
 	.ssc_endbuf	= SSC_BIT(SR_RXBUFF),
-	.ssc_error	= SSC_BIT(SR_OVRUN),
 	.pdc_enable	= ATMEL_PDC_RXTEN,
 	.pdc_disable	= ATMEL_PDC_RXTDIS,
 };

It doesn't hang any more doing a simple record.
BUT it still hangs if we do record and play at the same time.

Removing the overrun on tx_mask prevent the hang:
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index 0ecf356..41e15c2 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -73,7 +73,6 @@ static struct atmel_ssc_mask ssc_tx_mask = {
 	.ssc_disable	= SSC_BIT(CR_TXDIS),
 	.ssc_endx	= SSC_BIT(SR_ENDTX),
 	.ssc_endbuf	= SSC_BIT(SR_TXBUFE),
-	.ssc_error	= SSC_BIT(SR_OVRUN),
 	.pdc_enable	= ATMEL_PDC_TXTEN,
 	.pdc_disable	= ATMEL_PDC_TXTDIS,
 };

i.e. when I revert "ASoC: atmel_ssc_dai: add error mask define", I
don't see any hang.

Could you test and confirm that behaviour please ?

I attached a the (simple) .config I used for the tests.

PS: I hope the patches won't be mangled by gmail...

Best regards,
Richard.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snd_9x5_defconfig
Type: application/octet-stream
Size: 3939 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130704/0e273121/attachment.obj>

From shawn.guo at linaro.org  Thu Jul  4 09:49:32 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 4 Jul 2013 21:49:32 +0800
Subject: Mainline crashes in wm8962_probe() on i.MX6
In-Reply-To: <F7C43F8B2814514CA05F3436BC68046EF3A272@039-SN2MPN1-011.039d.mgd.msft.net>
References: <F7C43F8B2814514CA05F3436BC68046EF3A272@039-SN2MPN1-011.039d.mgd.msft.net>
Message-ID: <20130704134930.GC11046@S2101-09.ap.freescale.net>

On Thu, Jul 04, 2013 at 10:44:11AM +0000, Stehle Vincent-B46079 wrote:
> Hi,
> 
> Mainline of today* will not boot anymore on i.MX6 with ARM config imx_v6_v7_defconfig. It crashes in wm8962_probe() (see log below).
> 
> Bisecting points at merge commit 1286da8bc009cb2aee7f285e94623fc974c0c983, but its two "parents" commits do not crash.

Yeah, I just ran into it with linux-next and reported it there [1].  I
will send a formal patch for it soon.

Shawn

[1] http://thread.gmane.org/gmane.linux.alsa.devel/109844



From weiyj.lk at gmail.com  Thu Jul  4 09:51:31 2013
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Thu, 4 Jul 2013 21:51:31 +0800
Subject: [PATCH] ARM: u300: fix return value check in __u300_init_boardpower()
Message-ID: <CAPgLHd9cUJtF7WXmY4Sy+53MxjKJRe8RVNNtbfdYLzh6OwbNzg@mail.gmail.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

In case of error, the function syscon_node_to_regmap() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
 arch/arm/mach-u300/regulator.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-u300/regulator.c b/arch/arm/mach-u300/regulator.c
index bf40cd4..0493a84 100644
--- a/arch/arm/mach-u300/regulator.c
+++ b/arch/arm/mach-u300/regulator.c
@@ -69,9 +69,9 @@ static int __init __u300_init_boardpower(struct platform_device *pdev)
 		return -ENODEV;
 	}
 	regmap = syscon_node_to_regmap(syscon_np);
-	if (!regmap) {
+	if (IS_ERR(regmap)) {
 		pr_crit("U300: could not locate syscon regmap\n");
-		return -ENODEV;
+		return PTR_ERR(regmap);
 	}
 
 	main_power_15 = regulator_get(&pdev->dev, "vana15");



From thomas.petazzoni at free-electrons.com  Thu Jul  4 09:59:51 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 4 Jul 2013 15:59:51 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130702232311.GA3949@localhost>
References: <87fvvzfh70.fsf@natisbad.org>
 <20130702124639.GI19937@titan.lakedaemon.net>
 <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
 <20130702232311.GA3949@localhost>
Message-ID: <20130704155951.268ebada@skate>

Hello guys,

On Tue, 2 Jul 2013 20:23:12 -0300, Ezequiel Garcia wrote:

> > Yes and indeed I must say that when I read the driver I found some
> > similarities with pxa3xx, though it was done differently. I initially
> > wanted to try to merge them but of course without the spec it's a huge
> > waste of time, especially considering that this is still in the roadmap
> > of the Free Electrons guys even though low priority.
> > 
> 
> I wish I could say I'm going to work on this soon but, as Thomas said,
> we have no idea when/if NAND will be prioritized.

We've got some news. NAND is back into the list of priorities, Ezequiel
should restart working on NAND support relatively soon.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From w at 1wt.eu  Thu Jul  4 10:01:16 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 4 Jul 2013 16:01:16 +0200
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130704155951.268ebada@skate>
References: <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net> <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net> <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net> <87y59ows4n.fsf@natisbad.org>
 <20130702220936.GC10215@1wt.eu> <20130702232311.GA3949@localhost>
 <20130704155951.268ebada@skate>
Message-ID: <20130704140116.GD20739@1wt.eu>

On Thu, Jul 04, 2013 at 03:59:51PM +0200, Thomas Petazzoni wrote:
> Hello guys,
> 
> On Tue, 2 Jul 2013 20:23:12 -0300, Ezequiel Garcia wrote:
> 
> > > Yes and indeed I must say that when I read the driver I found some
> > > similarities with pxa3xx, though it was done differently. I initially
> > > wanted to try to merge them but of course without the spec it's a huge
> > > waste of time, especially considering that this is still in the roadmap
> > > of the Free Electrons guys even though low priority.
> > > 
> > 
> > I wish I could say I'm going to work on this soon but, as Thomas said,
> > we have no idea when/if NAND will be prioritized.
> 
> We've got some news. NAND is back into the list of priorities, Ezequiel
> should restart working on NAND support relatively soon.

Yeah, excellent news! Thanks for keeping us up to date!

Best regards,
Willy



From B46079 at freescale.com  Thu Jul  4 10:18:11 2013
From: B46079 at freescale.com (Stehle Vincent-B46079)
Date: Thu, 4 Jul 2013 14:18:11 +0000
Subject: Mainline crashes in wm8962_probe() on i.MX6
In-Reply-To: <20130704134930.GC11046@S2101-09.ap.freescale.net>
References: <F7C43F8B2814514CA05F3436BC68046EF3A272@039-SN2MPN1-011.039d.mgd.msft.net>
 <20130704134930.GC11046@S2101-09.ap.freescale.net>
Message-ID: <F7C43F8B2814514CA05F3436BC68046EF3AD16@039-SN2MPN1-011.039d.mgd.msft.net>

> From: Shawn Guo [mailto:shawn.guo at linaro.org]
(..)
> Yeah, I just ran into it with linux-next and reported it there [1].  I
> will send a formal patch for it soon.
> [1] http://thread.gmane.org/gmane.linux.alsa.devel/109844

Thank you for your patch; I confirm it repairs mainline imx_v6_v7_defconfig on i.MX6 sabre sd.

Best regards,

V.




From coelho at ti.com  Thu Jul  4 10:21:43 2013
From: coelho at ti.com (Luciano Coelho)
Date: Thu, 4 Jul 2013 17:21:43 +0300
Subject: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead
 of hiding behind a quirk
In-Reply-To: <CAAwP0s3xkqUGnGvojfpyQq97qUmKCqY3BD4RyK1_uuX=pNy91g@mail.gmail.com>
References: <1372860209-3504-1-git-send-email-coelho@ti.com>
 <1372860209-3504-3-git-send-email-coelho@ti.com>
 <1372860925.21065.115.camel@cumari.coelho.fi>
 <CAAwP0s3xkqUGnGvojfpyQq97qUmKCqY3BD4RyK1_uuX=pNy91g@mail.gmail.com>
Message-ID: <1372947703.21065.126.camel@cumari.coelho.fi>

On Wed, 2013-07-03 at 17:12 +0200, Javier Martinez Canillas wrote:
> On Wed, Jul 3, 2013 at 4:15 PM, Luciano Coelho <coelho at ti.com> wrote:
> > On Wed, 2013-07-03 at 17:03 +0300, Luciano Coelho wrote:
> >> The platform_quirk element in the platform data was used to change the
> >> way the IRQ is triggered.  When set, the EDGE_IRQ quirk would change
> >> the irqflags used and treat edge trigger differently from the rest.
> >>
> >> Instead of hiding this irq flag setting behind the quirk, have the
> >> board files set the flags during initialization.  This will be more
> >> meaningful than driver-specific quirks when we switch to DT.
> >>
> >> Additionally, fix missing gpio_request() calls in the boarding files
> >> (so that setting the flags actually works).
> >>
> >> Cc: Tony Lindgren <tony at atomide.com>
> >> Cc: Sekhar Nori <nsekhar at ti.com>
> >> Signed-off-by: Luciano Coelho <coelho at ti.com>
> >> ---
> >
> > [...]
> >
> >> @@ -5928,16 +5927,21 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
> >>       wlcore_adjust_conf(wl);
> >>
> >>       wl->irq = platform_get_irq(pdev, 0);
> >> -     wl->platform_quirks = pdata->platform_quirks;
> >>       wl->if_ops = pdev_data->if_ops;
> >>
> >> -     if (wl->platform_quirks & WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
> >> -             irqflags = IRQF_TRIGGER_RISING;
> >> -     else
> >> -             irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
> >> +     irq_data = irq_get_irq_data(wl->irq);
> >> +     if (!irq_data) {
> >> +             wl1271_error("couldn't get irq data for irq %d\n", wl->irq);
> >> +             ret = -EINVAL;
> >> +             goto out_free_nvs;
> >> +     }
> >> +
> >> +     wl->irq_flags = irqd_get_trigger_type(irq_data);
> >
> > BTW, there seems to be a patch on its way to make reading the flags
> > easier (ie. no need to get the irq_data first):
> >
> > http://mid.gmane.org/1367945288-5625-1-git-send-email-javier at dowhile0.org
> >
> > I'm not sure if this is going to be taken in, but if it does, it would
> > be nice to change the code here to use the new irq_get_trigger_type()
> > function.

> That patch has been already merged in Linus tree as commit 1f6236bf
> ("genirq: Add irq_get_trigger_type() to get IRQ flags").
> 
> So yes, it would be better if you can use irq_get_trigger_type()
> instead calling irq_get_irq_data() + irqd_get_trigger_type().

That's great, thanks! I'll make this change as soon as I get your patch
into my tree (ie. after the merge window closes).

--
Luca.



From heiko at sntech.de  Thu Jul  4 10:34:10 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Thu, 4 Jul 2013 16:34:10 +0200
Subject: [PATCH v2 1/6] misc: sram: fix error path in sram_probe
In-Reply-To: <1372151074.3981.21.camel@pizza.hi.pengutronix.de>
References: <201306251046.04873.heiko@sntech.de>
 <201306251046.38993.heiko@sntech.de>
 <1372151074.3981.21.camel@pizza.hi.pengutronix.de>
Message-ID: <201307041634.11248.heiko@sntech.de>

Hi Philipp,

Am Dienstag, 25. Juni 2013, 11:04:34 schrieb Philipp Zabel:
> Hi Heiko,
> 
> Am Dienstag, den 25.06.2013, 10:46 +0200 schrieb Heiko St?bner:
> > The pool is created thru devm_gen_pool_create, so the call to
> > gen_pool_destroy is not necessary.
> > Instead the sram-clock must be turned off again if it exists.
> > 
> > Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> > ---
> > 
> >  drivers/misc/sram.c |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
> > index d87cc91..afe66571 100644
> > --- a/drivers/misc/sram.c
> > +++ b/drivers/misc/sram.c
> > @@ -68,7 +68,8 @@ static int sram_probe(struct platform_device *pdev)
> > 
> >  	ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
> >  	
> >  				res->start, size, -1);
> >  	
> >  	if (ret < 0) {
> > 
> > -		gen_pool_destroy(sram->pool);
> 
> Right, thanks.
> 
> > +		if (sram->clk)
> > +			clk_disable_unprepare(sram->clk);
> > 
> >  		return ret;
> >  	
> >  	}
> 
> In light of the following patch, I'd rather move the
> clk_prepare_enable() call after gen_pool_add_virt() and its error path.

I'm not sure, but isn't moving the clock enablement below the pool allocation 
producing a race condition?

I.e. can the case happen that some other part wants to allocate part of the 
newly generated pool already, while the subsequent gen_pool_add_virt calls 
from the following patch are still running? ... And what will happen in this 
case, when the sram clock is still disabled?


Thanks
Heiko


From broonie at kernel.org  Thu Jul  4 10:36:45 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 4 Jul 2013 15:36:45 +0100
Subject: SPI: DUAL/QUAD support
In-Reply-To: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
Message-ID: <20130704143645.GA27646@sirena.org.uk>

On Thu, Jul 04, 2013 at 07:36:48PM +0800, yuhang wang wrote:
> Hi Mark,
> 
> Thanks for your reply.
> I have added the kerneldoc into the patch below to explain the "DUAL"
> and "QUAD" modes.
> Hope for your suggestions.

Please submit things in the form covered in SubmittingPatches -
especially you need to sign off anything you're submitting to the
standard kernel.

> +Description
> +----------------------
> +DUAL/QUAD means spi can transfer in 2bits/4bits at the same time.
> +These spi controllers provide 8 data lines(4-tx and 4-rx). User can
> +choose tranfer mode(SINGLE/DUAL/QUAD) by setting the certain register.
> +Though SPI is a serial interface, some spi controllers can support
> +transmitting and receiving in DUAL and QUAD modes aimed to improve
> +the performance. Also as spi slave lots of flashes do support this attribute,
> +such as serial-norflash in spansion company.

OK, so all this is about is devices that have extra data lines.  Please
don't invent terms like "DUAL" and "QUAD", it makes things much less
clear.  Just describe it as support for multiple data lines.

> +struct spi_transfer {
> ++       u8     bitwidth;
> ++#define        SPI_BITWIDTH_SINGLE     0x01; /* 1bit transfer */
> ++#define        SPI_BITWIDTH_DUAL       0x02; /* 2bits transfer */
> ++#define        SPI_BITWIDTH_QUAD       0x03; /* 4bits transfer */

Calling this "bandwidth" is really unclear - I would expect a bandwidth
to be expressed in bits per second or similar.  This would be much
clearer if it was just the number of data signals.

> +       t[0].rx_buf = buf;
> +       t[0].len = len;
> +       t[0].bitwidth = spi->rx_bitwidth/spi->tx_bitwidth;
> +       spi_message_add_tail(&t[0], &m);

This interface won't work for bidirectional transfers with asymmetric
numbers of data lines - we need separate fields for rx and rx.

> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -354,6 +354,7 @@ static int m25p80_read(struct mtd_info *mtd,
> loff_t from, size_t len,
> 
>         t[1].rx_buf = buf;
>         t[1].len = len;
> +       t[1].bitwidth = flash->spi->rx_bitwidth;
>         spi_message_add_tail(&t[1], &m);
> 
>         mutex_lock(&flash->lock);

This is going to fail in cases where the extra data lines aren't
available.
-------------- 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/20130704/3999b302/attachment.sig>

From jonas.jensen at gmail.com  Thu Jul  4 10:44:38 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Thu,  4 Jul 2013 16:44:38 +0200
Subject: [PATCH v3 1/4] ARM: mach-moxart: add MOXA ART SoC files
In-Reply-To: <1371040448-28742-2-git-send-email-jonas.jensen@gmail.com>
References: <1371040448-28742-2-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1372949078-8154-1-git-send-email-jonas.jensen@gmail.com>

Add MOXA ART SoC support.

The MOXA ART SoC is based on a Faraday FA526 ARMv4 32-bit 192 MHz CPU
with MMU and 16KB/8KB D/I-cache (UC-7112-LX).

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130703
    
    Changes since v2:
    
    1. add CLKSRC_MMIO and GENERIC_CLOCKEVENTS to ARCH_MOXART
    2. call of_clk_init(NULL) from .init_time hook

 arch/arm/Kconfig                  |   2 +
 arch/arm/Makefile                 |   1 +
 arch/arm/configs/moxart_defconfig | 116 ++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-moxart/Kconfig      |  29 ++++++++++
 arch/arm/mach-moxart/Makefile     |   3 +
 arch/arm/mach-moxart/moxart.c     |  43 ++++++++++++++
 6 files changed, 194 insertions(+)
 create mode 100644 arch/arm/configs/moxart_defconfig
 create mode 100644 arch/arm/mach-moxart/Kconfig
 create mode 100644 arch/arm/mach-moxart/Makefile
 create mode 100644 arch/arm/mach-moxart/moxart.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0ac9be6..d84161c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -964,6 +964,8 @@ source "arch/arm/mach-ks8695/Kconfig"
 
 source "arch/arm/mach-msm/Kconfig"
 
+source "arch/arm/mach-moxart/Kconfig"
+
 source "arch/arm/mach-mv78xx0/Kconfig"
 
 source "arch/arm/mach-imx/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 72caf82..17907c8 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -158,6 +158,7 @@ machine-$(CONFIG_ARCH_KIRKWOOD)		+= kirkwood
 machine-$(CONFIG_ARCH_KS8695)		+= ks8695
 machine-$(CONFIG_ARCH_LPC32XX)		+= lpc32xx
 machine-$(CONFIG_ARCH_MMP)		+= mmp
+machine-$(CONFIG_ARCH_MOXART)		+= moxart
 machine-$(CONFIG_ARCH_MSM)		+= msm
 machine-$(CONFIG_ARCH_MV78XX0)		+= mv78xx0
 machine-$(CONFIG_ARCH_MXC)		+= imx
diff --git a/arch/arm/configs/moxart_defconfig b/arch/arm/configs/moxart_defconfig
new file mode 100644
index 0000000..9977d33
--- /dev/null
+++ b/arch/arm/configs/moxart_defconfig
@@ -0,0 +1,116 @@
+# CONFIG_LOCALVERSION_AUTO is not set
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_SYSCTL_SYSCALL=y
+# CONFIG_ELF_CORE is not set
+# CONFIG_BASE_FULL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_TIMERFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+CONFIG_EMBEDDED=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_COMPAT_BRK is not set
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_MULTI_V4=y
+# CONFIG_ARCH_MULTI_V7 is not set
+CONFIG_ARCH_MOXART=y
+CONFIG_MACH_UC7112LX=y
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+# CONFIG_OABI_COMPAT is not set
+# CONFIG_ATAGS is not set
+CONFIG_ARM_APPENDED_DTB=y
+# CONFIG_SUSPEND is not set
+CONFIG_NET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_FW_LOADER is not set
+CONFIG_MTD=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_ADV_OPTIONS=y
+CONFIG_MTD_CFI_GEOMETRY=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_COMPLEX_MAPPINGS=y
+CONFIG_MTD_PHYSMAP=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_PROC_DEVICETREE=y
+CONFIG_NETDEVICES=y
+# CONFIG_NET_VENDOR_ARC is not set
+# CONFIG_NET_CADENCE is not set
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+CONFIG_ARM_MOXART_ETHER=y
+# CONFIG_WLAN is not set
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_LEGACY_PTYS is not set
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=1
+CONFIG_SERIAL_8250_RUNTIME_UARTS=1
+CONFIG_SERIAL_8250_EXTENDED=y
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+CONFIG_SERIAL_OF_PLATFORM=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_GPIO_MOXART=y
+# CONFIG_HWMON is not set
+CONFIG_WATCHDOG=y
+CONFIG_MOXART_WDT=y
+# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI_MOXART=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_MOXART=y
+CONFIG_DMADEVICES=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_EXT3_FS=y
+CONFIG_TMPFS=y
+CONFIG_JFFS2_FS=y
+CONFIG_PRINTK_TIME=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_SHIRQ=y
+CONFIG_DETECT_HUNG_TASK=y
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_PREEMPT is not set
+CONFIG_PROVE_LOCKING=y
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_MEMORY_INIT=y
+# CONFIG_FTRACE is not set
+CONFIG_DEBUG_LL=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_KEYS=y
diff --git a/arch/arm/mach-moxart/Kconfig b/arch/arm/mach-moxart/Kconfig
new file mode 100644
index 0000000..a6ad825
--- /dev/null
+++ b/arch/arm/mach-moxart/Kconfig
@@ -0,0 +1,29 @@
+config ARCH_MOXART
+	bool "MOXA ART SoC" if ARCH_MULTI_V4
+	select CPU_FA526
+	select ARM_DMA_MEM_BUFFERABLE
+	select USE_OF
+	select CLKSRC_OF
+	select CLKSRC_MMIO
+	select HAVE_CLK
+	select COMMON_CLK
+	select GENERIC_IRQ_CHIP
+	select ARCH_REQUIRE_GPIOLIB
+	select GENERIC_CLOCKEVENTS
+	help
+	  Say Y here if you want to run your kernel on hardware with a
+	  MOXA ART SoC.
+	  The MOXA ART SoC is based on a Faraday FA526 ARMv4 32-bit
+	  192 MHz CPU with MMU and 16KB/8KB D/I-cache (UC-7112-LX).
+	  Used on models UC-7101, UC-7112/UC-7110, IA240/IA241, IA3341.
+
+if ARCH_MOXART
+
+config MACH_UC7112LX
+	bool "MOXA UC-7112-LX"
+	depends on ARCH_MOXART
+	help
+	  Say Y here if you intend to run this kernel on a MOXA
+	  UC-7112-LX embedded computer.
+
+endif
diff --git a/arch/arm/mach-moxart/Makefile b/arch/arm/mach-moxart/Makefile
new file mode 100644
index 0000000..fa022eb
--- /dev/null
+++ b/arch/arm/mach-moxart/Makefile
@@ -0,0 +1,3 @@
+# Object file lists.
+
+obj-$(CONFIG_MACH_UC7112LX)	+= moxart.o
diff --git a/arch/arm/mach-moxart/moxart.c b/arch/arm/mach-moxart/moxart.c
new file mode 100644
index 0000000..86b4e49
--- /dev/null
+++ b/arch/arm/mach-moxart/moxart.c
@@ -0,0 +1,43 @@
+/*
+ * arch/arm/mach-moxart/moxart.c
+ *
+ * (C) Copyright 2013, Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <linux/init.h>
+#include <linux/clocksource.h>
+#include <linux/of_platform.h>
+#include <linux/clk-provider.h>
+
+#include <asm/mach/arch.h>
+
+static const char * const moxart_dt_compat[] = {
+	"moxa,moxart",
+	NULL,
+};
+
+static void __init moxart_init_time(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+DT_MACHINE_START(MOXART, "MOXA UC-7112-LX")
+	.init_time		= moxart_init_time,
+	.dt_compat		= moxart_dt_compat,
+MACHINE_END
-- 
1.8.2.1



From jonas.jensen at gmail.com  Thu Jul  4 10:45:15 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Thu,  4 Jul 2013 16:45:15 +0200
Subject: [PATCH v3 2/4] ARM: mach-moxart: add MOXA ART device tree files
In-Reply-To: <1371040448-28742-3-git-send-email-jonas.jensen@gmail.com>
References: <1371040448-28742-3-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1372949115-8190-1-git-send-email-jonas.jensen@gmail.com>

Add generic SoC include and UC-7112-LX platform device tree files
and documentation.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130703
    
    Changes since v2:
    
    1. add and update documentation, new drivers: mmc, mac, rtc,
       watchdog, gpio, core-clock, apb-clock

 .../bindings/arm/moxart/moxa,moxart-apb-clock.txt  | 18 +++++
 .../devicetree/bindings/arm/moxart/moxart.txt      | 12 ++++
 .../bindings/clock/moxa,moxart-core-clock          | 19 +++++
 .../devicetree/bindings/gpio/moxa,moxart-gpio.txt  | 16 +++++
 .../interrupt-controller/moxa,moxart-ic.txt        | 28 ++++++++
 .../devicetree/bindings/mmc/moxa,moxart-mmc.txt    | 17 +++++
 .../devicetree/bindings/net/moxa,moxart-mac.txt    | 25 +++++++
 .../devicetree/bindings/rtc/moxa,moxart-rtc.txt    | 11 +++
 .../bindings/timer/moxa,moxart-timer.txt           | 17 +++++
 .../bindings/watchdog/moxa,moxart-watchdog.txt     | 15 ++++
 arch/arm/boot/dts/Makefile                         |  1 +
 arch/arm/boot/dts/moxart-uc7112lx.dts              | 82 ++++++++++++++++++++++
 arch/arm/boot/dts/moxart.dtsi                      | 79 +++++++++++++++++++++
 13 files changed, 340 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/moxart/moxa,moxart-apb-clock.txt
 create mode 100644 Documentation/devicetree/bindings/arm/moxart/moxart.txt
 create mode 100644 Documentation/devicetree/bindings/clock/moxa,moxart-core-clock
 create mode 100644 Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/moxa,moxart-ic.txt
 create mode 100644 Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt
 create mode 100644 Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
 create mode 100644 Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
 create mode 100644 Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
 create mode 100644 arch/arm/boot/dts/moxart-uc7112lx.dts
 create mode 100644 arch/arm/boot/dts/moxart.dtsi

diff --git a/Documentation/devicetree/bindings/arm/moxart/moxa,moxart-apb-clock.txt b/Documentation/devicetree/bindings/arm/moxart/moxa,moxart-apb-clock.txt
new file mode 100644
index 0000000..f6e88fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/moxart/moxa,moxart-apb-clock.txt
@@ -0,0 +1,18 @@
+MOXA ART APB clock
+
+Required properties:
+
+- compatible : Should be "moxa,moxart-apb-clock"
+- #clock-cells : Should be 0
+
+Example:
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clkapb: clkapb {
+			compatible = "moxa,moxart-apb-clock";
+			#clock-cells = <0>;
+		};
+	};
diff --git a/Documentation/devicetree/bindings/arm/moxart/moxart.txt b/Documentation/devicetree/bindings/arm/moxart/moxart.txt
new file mode 100644
index 0000000..11087ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/moxart/moxart.txt
@@ -0,0 +1,12 @@
+MOXA ART device tree bindings
+
+Boards with the MOXA ART SoC shall have the following properties:
+
+Required root node property:
+
+compatible = "moxa,moxart";
+
+Boards:
+
+- UC-7112-LX: embedded computer
+  compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart"
diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock
new file mode 100644
index 0000000..cf69361
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock
@@ -0,0 +1,19 @@
+Device Tree Clock bindings for arch-moxart
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+MOXA ART SoCs allow to determine core clock frequencies by reading
+a register.
+
+Required properties:
+- compatible : Should be "moxa,moxart-core-clock"
+- reg : Should contain registers location and length
+
+For example:
+
+	clk: core-clock at 98100000 {
+		compatible = "moxa,moxart-core-clock";
+		reg = <0x98100000 0x34>;
+	};
diff --git a/Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt b/Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt
new file mode 100644
index 0000000..1be5875
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt
@@ -0,0 +1,16 @@
+MOXA ART GPIO Controller
+
+Required properties:
+
+- compatible : Should be "moxa,moxart-gpio"
+- reg : Should contain registers location and length
+	index 0 : input, output, and direction control
+	index 1 : enable/disable individual pins, pin 0-31
+
+Example:
+
+	gpio: gpio at 98700000 {
+		compatible = "moxa,moxart-gpio";
+		reg =	<0x98700000 0xC>,
+			<0x98100100 0x4>;
+	};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/moxa,moxart-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/moxa,moxart-ic.txt
new file mode 100644
index 0000000..58f1fe1
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/moxa,moxart-ic.txt
@@ -0,0 +1,28 @@
+* MOXA ART Interrupt Controller
+
+MOXA ART Interrupt Controller (moxart-ic) is used on MOXA ART SoCs
+and supports 32 non-configurable number of interrupts
+
+Main node required properties:
+
+- compatible : "moxa,moxart-ic"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The type shall be a <u32> and the value shall be 2.
+
+  The first cell contains the interrupt number in the range [0-31].
+  The second cell contains the interrupt type
+
+- reg: physical base address and size of the intc registers map.
+- interrupt-mask: Specifies if the interrupt is edge or level-triggered
+  each bit represent an interrupt 0-31 where 1 signify edge
+
+Example:
+
+	intc: interrupt-controller at 98800000 {
+		compatible = "moxa,moxart-ic";
+		reg = <0x98800000 0x38>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-mask = <0x00080000>;
+	};
diff --git a/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt b/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt
new file mode 100644
index 0000000..7cd7bd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt
@@ -0,0 +1,17 @@
+MOXA ART SD Host Controller Interface
+
+Required properties:
+
+- compatible : Should be "moxa,moxart-mmc"
+- reg : Should contain registers location and length
+- interrupts : Should contain the interrupt number
+- clocks : Should contain phandle for the internal bus clock "tclk"
+
+Example:
+
+	mmc: mmc at 98e00000 {
+		compatible = "moxa,moxart-mmc";
+		reg = <0x98e00000 0x0000005C>;
+		interrupts = <5 0>;
+		clocks = <&tclk>;
+	};
diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
new file mode 100644
index 0000000..8be75cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
@@ -0,0 +1,25 @@
+MOXA ART Ethernet Controller
+
+Required properties:
+
+- compatible : Should be "moxa,moxart-mac"
+- reg : Should contain registers location and length
+  index 0 : main register
+  index 1 : mac address (stored on flash)
+- interrupts : Should contain the mac interrupt number
+
+Example:
+
+	mac0: mac at 90900000 {
+		compatible = "moxa,moxart-mac";
+		reg =	<0x90900000 0x1000>,
+			<0x80000050 0x6>;
+		interrupts = <25 0>;
+	};
+
+	mac1: mac at 92000000 {
+		compatible = "moxa,moxart-mac";
+		reg =	<0x92000000 0x1000>,
+			<0x80000056 0x6>;
+		interrupts = <27 0>;
+	};
diff --git a/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt b/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
new file mode 100644
index 0000000..65f632c
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
@@ -0,0 +1,11 @@
+MOXA ART real-time clock
+
+Required properties:
+
+- compatible : Should be "moxa,moxart-rtc"
+
+Example:
+
+	rtc: rtc {
+		compatible = "moxa,moxart-rtc";
+	};
diff --git a/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt b/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt
new file mode 100644
index 0000000..9015b88
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt
@@ -0,0 +1,17 @@
+MOXA ART timer
+
+Required properties:
+
+- compatible : Should be "moxa,moxart-timer"
+- reg : Should contain registers location and length
+- interrupts : Should contain the timer interrupt number
+- clocks : Should contain phandle for the internal bus clock "tclk"
+
+Example:
+
+	timer: timer at 98400000 {
+		compatible = "moxa,moxart-timer";
+		reg = <0x98400000 0x10>;
+		interrupts = <19 1>;
+		clocks = <&tclk>;
+	};
diff --git a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
new file mode 100644
index 0000000..00a23b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
@@ -0,0 +1,15 @@
+MOXA ART Watchdog timer
+
+Required properties:
+
+- compatible : Should be "moxa,moxart-watchdog"
+- reg : Should contain registers location and length
+- clocks : Should contain phandle for the internal bus clock "tclk"
+
+Example:
+
+	watchdog: watchdog at 98500000 {
+		compatible = "moxa,moxart-watchdog";
+		reg = <0x98500000 0x10>;
+		clocks = <&tclk>;
+	};
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 2cec2ff..66d4d73 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -96,6 +96,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
 	kirkwood-ts219-6282.dtb \
 	kirkwood-openblocks_a6.dtb
 dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
+dtb-$(CONFIG_ARCH_MOXART) += moxart-uc7112lx.dtb
 dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
 	msm8960-cdp.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
diff --git a/arch/arm/boot/dts/moxart-uc7112lx.dts b/arch/arm/boot/dts/moxart-uc7112lx.dts
new file mode 100644
index 0000000..db65575
--- /dev/null
+++ b/arch/arm/boot/dts/moxart-uc7112lx.dts
@@ -0,0 +1,82 @@
+/* moxart-uc7112lx.dts - Device Tree file for MOXA UC-7112-LX
+ *
+ * Copyright (C) 2013 Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+/dts-v1/;
+/include/ "moxart.dtsi"
+
+/ {
+	model = "MOXA UC-7112-LX";
+	compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart";
+
+	memory {
+		/* SAMSUNG K4S561632J-UC75 */
+		device_type = "memory";
+		reg = <0x0 0x2000000>;
+	};
+
+	flash at 80000000,0 {
+		/* JS28F128 J3D75 A9087684
+		 * Numonyx Embedded Flash Memory (J3 v. D)
+		 */
+		compatible = "numonyx,js28f128", "cfi-flash";
+		reg = <0x80000000 0x1000000>;
+		bank-width = <2>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		partition at 0 {
+			label = "bootloader";
+			reg = <0x0 0x40000>;
+		};
+		partition at 40000 {
+			label = "linux kernel";
+			reg = <0x40000 0x1C0000>;
+		};
+		partition at 200000 {
+			label = "root filesystem";
+			reg = <0x200000 0x800000>;
+		};
+		partition at a00000 {
+			label = "user filesystem";
+			reg = <0xa00000 0x600000>;
+		};
+	};
+
+	mmc: mmc at 98e00000 {
+		compatible = "moxa,moxart-mmc";
+		reg = <0x98e00000 0x5C>;
+		interrupts = <5 0>;
+		clocks = <&clkapb>;
+	};
+
+	mac0: mac at 90900000 {
+		compatible = "moxa,moxart-mac";
+		reg =   <0x90900000 0x100>,
+			<0x80000050 0x6>;
+		interrupts = <25 0>;
+	};
+
+	mac1: mac at 92000000 {
+		compatible = "moxa,moxart-mac";
+		reg =	<0x92000000 0x100>,
+			<0x80000056 0x6>;
+		interrupts = <27 0>;
+	};
+
+	uart0: uart at 98200000 {
+		compatible = "ns16550a";
+		reg = <0x98200000 0x20>;
+		interrupts = <31 8>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		clock-frequency = <14745600>;
+		status = "okay";
+	};
+
+	chosen {
+		bootargs = "console=ttyS0,115200n8 root=/dev/mtdblock2 rootfstype=jffs2 rw";
+	};
+};
diff --git a/arch/arm/boot/dts/moxart.dtsi b/arch/arm/boot/dts/moxart.dtsi
new file mode 100644
index 0000000..40f20f3
--- /dev/null
+++ b/arch/arm/boot/dts/moxart.dtsi
@@ -0,0 +1,79 @@
+/* moxart.dtsi - Device Tree Include file for MOXA ART family SoC
+ *
+ * Copyright (C) 2013 Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "moxa,moxart";
+	model = "MOXART";
+	interrupt-parent = <&intc>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "faraday,fa526";
+			reg = <0>;
+		};
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clkapb: clkapb {
+			compatible = "moxa,moxart-apb-clock";
+			#clock-cells = <0>;
+		};
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0x90000000 0x10000000>;
+		ranges;
+
+		intc: interrupt-controller at 98800000 {
+			compatible = "moxa,moxart-ic";
+			reg = <0x98800000 0x38>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			interrupt-mask = <0x00080000>;
+		};
+
+		clk: core-clock at 98100000 {
+			compatible = "moxa,moxart-core-clock";
+			reg = <0x98100000 0x34>;
+		};
+
+		timer: timer at 98400000 {
+			compatible = "moxa,moxart-timer";
+			reg = <0x98400000 0x42>;
+			interrupts = <19 1>;
+			clocks = <&clkapb>;
+		};
+
+		gpio: gpio at 98700000 {
+			compatible = "moxa,moxart-gpio";
+			reg =	<0x98700000 0xC>,
+				<0x98100100 0x4>;
+		};
+
+		rtc: rtc {
+			compatible = "moxa,moxart-rtc";
+		};
+
+		watchdog: watchdog at 98500000 {
+			compatible = "moxa,moxart-watchdog";
+			reg = <0x98500000 0x10>;
+			clocks = <&clkapb>;
+		};
+	};
+};
-- 
1.8.2.1



From jonas.jensen at gmail.com  Thu Jul  4 10:45:31 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Thu,  4 Jul 2013 16:45:31 +0200
Subject: [PATCH v3 3/4] ARM: mach-moxart: add MOXA ART UART debug files
In-Reply-To: <1371040448-28742-4-git-send-email-jonas.jensen@gmail.com>
References: <1371040448-28742-4-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1372949131-8225-1-git-send-email-jonas.jensen@gmail.com>

Add MOXA ART kernel low-level debugging port support.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130703
    
    Changes since v2:
    
    1. use alphabetic ordering in Kconfig

 arch/arm/Kconfig.debug          |  8 ++++++++
 arch/arm/include/debug/moxart.S | 20 ++++++++++++++++++++
 2 files changed, 28 insertions(+)
 create mode 100644 arch/arm/include/debug/moxart.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 5b7be8d..781018c 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -286,6 +286,13 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on MMP UART3.
 
+	config DEBUG_MOXART_UART0
+		bool "Kernel low-level debugging messages via MOXART UART0"
+		depends on ARCH_MOXART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on MOXART based platforms on the UART0.
+
 	config DEBUG_MSM_UART1
 		bool "Kernel low-level debugging messages via MSM UART1"
 		depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50
@@ -777,6 +784,7 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX6SL_UART
 	default "debug/keystone.S" if DEBUG_KEYSTONE_UART0 || \
 				      DEBUG_KEYSTONE_UART1
+	default "debug/moxart.S" if DEBUG_MOXART_UART0
 	default "debug/mvebu.S" if DEBUG_MVEBU_UART || \
 				   DEBUG_MVEBU_UART_ALTERNATE
 	default "debug/mxs.S" if DEBUG_IMX23_UART || DEBUG_IMX28_UART
diff --git a/arch/arm/include/debug/moxart.S b/arch/arm/include/debug/moxart.S
new file mode 100644
index 0000000..a228451
--- /dev/null
+++ b/arch/arm/include/debug/moxart.S
@@ -0,0 +1,20 @@
+/*
+ * Debugging macro include header
+ *
+ *  Copyright (C) 2013 Jonas Jensen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define MOXART_UART_DEBUG_PHYS_BASE		0x98200000
+#define MOXART_UART_DEBUG_VIRT_BASE		0xf9820000
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =MOXART_UART_DEBUG_PHYS_BASE
+	ldr	\rv, =MOXART_UART_DEBUG_VIRT_BASE
+	.endm
+
+#define UART_SHIFT	2
+#include <asm/hardware/debug-8250.S>
-- 
1.8.2.1



From jonas.jensen at gmail.com  Thu Jul  4 10:45:42 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Thu,  4 Jul 2013 16:45:42 +0200
Subject: [PATCH v3 4/4] ARM: reinsert ARCH_MULTI_V4 Kconfig option
Message-ID: <1372949142-8260-1-git-send-email-jonas.jensen@gmail.com>

CPU_FA526 is thumbless and adding under e.g. ARCH_MULTI_V4T instead means inclusion of CPU_ARM920T
which in turn selects CPU_ABRT_EV4T, CPU_CACHE_V4WT, CPU_COPY_V4WB, CPU_TLB_V4WBI, which in turn can
mean trouble when the kernel eventually tries to exec init:

[    2.580000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
[    2.580000]
[    2.580000] CPU: 0 PID: 1 Comm: init Not tainted 3.10.0-next-20130703+ #3
[    2.580000] [<c000cc64>] (unwind_backtrace+0x0/0xf0) from [<c000b524>] (show_stack+0x10/0x14)
[    2.580000] [<c000b524>] (show_stack+0x10/0x14) from [<c021d6dc>] (panic+0x90/0x1e0)
[    2.580000] [<c021d6dc>] (panic+0x90/0x1e0) from [<c0019664>] (do_exit+0x724/0x834)
[    2.580000] [<c0019664>] (do_exit+0x724/0x834) from [<c00197d8>] (do_group_exit+0x3c/0xb0)
[    2.580000] [<c00197d8>] (do_group_exit+0x3c/0xb0) from [<c0024c34>] (get_signal_to_deliver+0x2ec/0x598)
[    2.580000] [<c0024c34>] (get_signal_to_deliver+0x2ec/0x598) from [<c021d2a8>] (do_signal+0x9c/0x3cc)
[    2.580000] [<c021d2a8>] (do_signal+0x9c/0x3cc) from [<c000b110>] (do_work_pending+0xc4/0xe0)
[    2.580000] [<c000b110>] (do_work_pending+0xc4/0xe0) from [<c0009334>] (work_pending+0xc/0x20)

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---
 arch/arm/Kconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d84161c..87e93ab 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -878,6 +878,11 @@ menu "Multiple platform selection"
 
 comment "CPU Core family selection"
 
+config ARCH_MULTI_V4
+	bool "ARMv4 based platforms (FA526, StrongARM)"
+	depends on !ARCH_MULTI_V6_V7
+	select ARCH_MULTI_V4_V5
+
 config ARCH_MULTI_V4T
 	bool "ARMv4T based platforms (ARM720T, ARM920T, ...)"
 	depends on !ARCH_MULTI_V6_V7
-- 
1.8.2.1



From Thomas.Betker at rohde-schwarz.com  Thu Jul  4 10:58:52 2013
From: Thomas.Betker at rohde-schwarz.com (Thomas.Betker at rohde-schwarz.com)
Date: Thu, 4 Jul 2013 16:58:52 +0200
Subject: SPI: DUAL/QUAD support
In-Reply-To: <20130704130017.GA25997@sig21.net>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704130017.GA25997@sig21.net>
Message-ID: <OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>

Hello Johannes:

> Doesn't m25p80 need to use different commands (OPCODEs)
> for 2x and 4x speed?  It seems this change is incomplete.

Yes, there are usually different opcodes, and as far as I know, they are 
not supported by the m25p80 driver. It seems we are missing some 
background info here.

My guess is that the flash chip in question is configured to treat single 
mode opcodes as dual or quad mode commands (some chips support this), and 
that the SPI controller needs to be told, for each transfer, which mode to 
use.

E.g., you would send a READ command with the command bytes in single mode 
(t[0].bitwidth is missing in the patch) and the data bytes in dual or quad 
mode. No dummy bytes are used -- the SPI is running at slower speed.

This situation is certainly a bit special. To me, the patch looks like a 
short-time workaround; I would rather see the flash driver support actual 
dual or quad mode commands. Is there any work in progress?

Best regards,
Thomas



From laurent.pinchart at ideasonboard.com  Thu Jul  4 11:02:30 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 04 Jul 2013 17:02:30 +0200
Subject: [PATCH v3] ARM: shmobile: lager: Add DT reference
In-Reply-To: <1372838251-6314-1-git-send-email-horms+renesas@verge.net.au>
References: <1372838251-6314-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1438555.HIWtKGAp3v@avalon>

Hi Simon,

On Wednesday 03 July 2013 16:57:31 Simon Horman wrote:
> This is sufficient to allow boot of the Lager board with a console without
> boards-lager.c compiled into the kernel. This is an example of a minimal but
> still useful initialisation of the board using DT as much as possible.
> 
> As such it is the same as the boot of Lager that can be achieved without a
> board file. The intention of adding this file is to facilitate further work
> to allow board specific devices to be initialised via DT.

At some (hopefully not too distant) point we should stop adding both 
traditional and DT board files. DT is supposed to lower the number of board 
files, not multiply it by two.

Work is still needed in order to achieve this, as we lack DT bindings for core 
(and non core) devices. That's something we need to work on. As a first step, 
do we have a roadmap with a list of devices that lack DT support ? At the very 
least I see more work needed on

- Common clock framework
- SCI
- Timers

We shouldn't delay CCF much longer, v3.12 seems an achievable target to me. 
Who will work on that ?

> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> ---
> 
> v3
> * Supply temporary machine_init call-back in lager-reference.c to
>   initialise clocks and bring up SCIF and CMT in C. Magnus
>   advised me that this is not desired in the SoC code.
> * Add lager-reference to Makefile.boot
> 
> v2
> * Use recently added r8a7790_init_delay()
> ---
>  arch/arm/boot/dts/Makefile                     |  1 +
>  arch/arm/boot/dts/r8a7790-lager-reference.dts  | 31 +++++++++++++++++
>  arch/arm/mach-shmobile/Kconfig                 | 11 ++++++
>  arch/arm/mach-shmobile/Makefile                |  1 +
>  arch/arm/mach-shmobile/Makefile.boot           |  1 +
>  arch/arm/mach-shmobile/board-lager-reference.c | 46 +++++++++++++++++++++++
>  arch/arm/mach-shmobile/include/mach/r8a7790.h  |  1 +
>  arch/arm/mach-shmobile/setup-r8a7790.c         |  9 +++--
>  8 files changed, 99 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/boot/dts/r8a7790-lager-reference.dts
>  create mode 100644 arch/arm/mach-shmobile/board-lager-reference.c
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index cb31259..f2dc697 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -165,6 +165,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
>  	r8a7740-armadillo800eva-reference.dtb \
>  	r8a7779-marzen-reference.dtb \
>  	r8a7790-lager.dtb \
> +	r8a7790-lager-reference.dtb \
>  	sh73a0-kzm9g.dtb \
>  	sh73a0-kzm9g-reference.dtb \
>  	r8a73a4-ape6evm.dtb \
> diff --git a/arch/arm/boot/dts/r8a7790-lager-reference.dts
> b/arch/arm/boot/dts/r8a7790-lager-reference.dts new file mode 100644
> index 0000000..fa5b81b
> --- /dev/null
> +++ b/arch/arm/boot/dts/r8a7790-lager-reference.dts
> @@ -0,0 +1,31 @@
> +/*
> + * Device Tree Source for the Lager board
> + *
> + * Copyright (C) 2013 Renesas Solutions Corp.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +/include/ "r8a7790.dtsi"
> +
> +/ {
> +	model = "Lager";
> +	compatible = "renesas,lager-reference", "renesas,r8a7790";
> +
> +	chosen {
> +		bootargs = "console=ttySC6,115200 ignore_loglevel";
> +	};
> +
> +	memory at 40000000 {
> +		device_type = "memory";
> +		reg = <0 0x40000000 0 0x80000000>;
> +	};
> +
> +	lbsc {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +	};
> +};
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index 64dc24d..30c571b 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -150,6 +150,17 @@ config MACH_LAGER
>  	depends on ARCH_R8A7790
>  	select USE_OF
> 
> +config MACH_LAGER_REFERENCE
> +	bool "Lager board - Reference Device Tree Implementation"
> +	depends on ARCH_R8A7790
> +	select USE_OF
> +	---help---
> +	   Use reference implementation of Lager board support
> +	   which makes use of device tree at the expense
> +	   of not supporting a number of devices.
> +
> +	   This is intended to aid developers
> +
>  config MACH_KZM9D
>  	bool "KZM9D board"
>  	depends on ARCH_EMEV2
> diff --git a/arch/arm/mach-shmobile/Makefile
> b/arch/arm/mach-shmobile/Makefile index 6165a51..d813133 100644
> --- a/arch/arm/mach-shmobile/Makefile
> +++ b/arch/arm/mach-shmobile/Makefile
> @@ -43,6 +43,7 @@ obj-$(CONFIG_MACH_BOCKW)	+= board-bockw.o
>  obj-$(CONFIG_MACH_MARZEN)	+= board-marzen.o
>  obj-$(CONFIG_MACH_MARZEN_REFERENCE)	+= board-marzen-reference.o
>  obj-$(CONFIG_MACH_LAGER)	+= board-lager.o
> +obj-$(CONFIG_MACH_LAGER_REFERENCE)	+= board-lager-reference.o
>  obj-$(CONFIG_MACH_ARMADILLO800EVA)	+= board-armadillo800eva.o
>  obj-$(CONFIG_MACH_ARMADILLO800EVA_REFERENCE)	+=
> board-armadillo800eva-reference.o obj-$(CONFIG_MACH_KZM9D)	+= board-
kzm9d.o
> diff --git a/arch/arm/mach-shmobile/Makefile.boot
> b/arch/arm/mach-shmobile/Makefile.boot index 84c6868..16834d8 100644
> --- a/arch/arm/mach-shmobile/Makefile.boot
> +++ b/arch/arm/mach-shmobile/Makefile.boot
> @@ -10,6 +10,7 @@ loadaddr-$(CONFIG_MACH_KZM9D) += 0x40008000
>  loadaddr-$(CONFIG_MACH_KZM9G) += 0x41008000
>  loadaddr-$(CONFIG_MACH_KZM9G_REFERENCE) += 0x41008000
>  loadaddr-$(CONFIG_MACH_LAGER) += 0x40008000
> +loadaddr-$(CONFIG_MACH_LAGER_REFERENCE) += 0x40008000
>  loadaddr-$(CONFIG_MACH_MACKEREL) += 0x40008000
>  loadaddr-$(CONFIG_MACH_MARZEN) += 0x60008000
>  loadaddr-$(CONFIG_MACH_MARZEN_REFERENCE) += 0x60008000
> diff --git a/arch/arm/mach-shmobile/board-lager-reference.c
> b/arch/arm/mach-shmobile/board-lager-reference.c new file mode 100644
> index 0000000..eb6c55e
> --- /dev/null
> +++ b/arch/arm/mach-shmobile/board-lager-reference.c
> @@ -0,0 +1,46 @@
> +/*
> + * Lager board support - Reference DT implementation
> + *
> + * Copyright (C) 2013  Renesas Solutions Corp.
> + * Copyright (C) 2013  Simon Horman
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 
> USA + */
> +
> +#include <linux/init.h>
> +#include <linux/irqchip.h>
> +#include <linux/of_platform.h>
> +#include <mach/r8a7790.h>
> +#include <asm/mach/arch.h>
> +
> +void __init lager_add_standard_devices(void)
> +{
> +	/* clocks are setup late during boot in the case of DT */
> +	r8a7790_clock_init();
> +
> +	r8a7790_add_dt_devices();
> +        of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +}
> +
> +static const char *lager_boards_compat_dt[] __initdata = {
> +	"renesas,lager-reference",
> +	NULL,
> +};
> +
> +DT_MACHINE_START(LAGER_DT, "lager")
> +	.init_early	= r8a7790_init_delay,
> +	.init_machine	= lager_add_standard_devices,
> +	.init_time	= r8a7790_timer_init,
> +	.dt_compat	= lager_boards_compat_dt,
> +MACHINE_END
> diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h
> b/arch/arm/mach-shmobile/include/mach/r8a7790.h index 7851cc1..421d842
> 100644
> --- a/arch/arm/mach-shmobile/include/mach/r8a7790.h
> +++ b/arch/arm/mach-shmobile/include/mach/r8a7790.h
> @@ -2,6 +2,7 @@
>  #define __ASM_R8A7790_H__
> 
>  void r8a7790_add_standard_devices(void);
> +void r8a7790_add_dt_devices(void);
>  void r8a7790_clock_init(void);
>  void r8a7790_pinmux_init(void);
>  void r8a7790_init_delay(void);
> diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c
> b/arch/arm/mach-shmobile/setup-r8a7790.c index f01542e..7f01178 100644
> --- a/arch/arm/mach-shmobile/setup-r8a7790.c
> +++ b/arch/arm/mach-shmobile/setup-r8a7790.c
> @@ -179,7 +179,7 @@ static struct resource cmt00_resources[] = {
>  					  &cmt##idx##_platform_data,	\
>  					  sizeof(struct sh_timer_config))
> 
> -void __init r8a7790_add_standard_devices(void)
> +void __init r8a7790_add_dt_devices(void)
>  {
>  	r8a7790_register_scif(SCIFA0);
>  	r8a7790_register_scif(SCIFA1);
> @@ -191,9 +191,14 @@ void __init r8a7790_add_standard_devices(void)
>  	r8a7790_register_scif(SCIF1);
>  	r8a7790_register_scif(HSCIF0);
>  	r8a7790_register_scif(HSCIF1);
> +	r8a7790_register_cmt(00);
> +}
> +
> +void __init r8a7790_add_standard_devices(void)
> +{
> +	r8a7790_add_dt_devices();
>  	r8a7790_register_irqc(0);
>  	r8a7790_register_thermal();
> -	r8a7790_register_cmt(00);
>  }
> 
>  void __init r8a7790_timer_init(void)
-- 
Regards,

Laurent Pinchart



From will.deacon at arm.com  Thu Jul  4 11:02:23 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu,  4 Jul 2013 16:02:23 +0100
Subject: [PATCH] ARM: mm: ensure SMP alternates assemble to exactly 4 bytes
 with Thumb-2
Message-ID: <1372950143-12789-1-git-send-email-will.deacon@arm.com>

Commit ae8a8b9553bd ("ARM: 7691/1: mm: kill unused TLB_CAN_READ_FROM_L1_CACHE
and use ALT_SMP instead") added early function returns for page table
cache flushing operations on ARMv7 SMP CPUs.

Unfortunately, when targetting Thumb-2, these `mov pc, lr' sequences
assemble to 2 bytes which can lead to corruption of the instruction
stream after code patching.

This patch fixes the alternates to use wide (32-bit) instructions for
Thumb-2, therefore ensuring that the patching code works correctly.

Cc: <stable at vger.kernel.org>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/mm/proc-v7-2level.S |  2 +-
 arch/arm/mm/proc-v7-3level.S |  2 +-
 arch/arm/mm/proc-v7.S        | 11 ++++++-----
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mm/proc-v7-2level.S b/arch/arm/mm/proc-v7-2level.S
index 9704097..b3997c7 100644
--- a/arch/arm/mm/proc-v7-2level.S
+++ b/arch/arm/mm/proc-v7-2level.S
@@ -110,7 +110,7 @@ ENTRY(cpu_v7_set_pte_ext)
  ARM(	str	r3, [r0, #2048]! )
  THUMB(	add	r0, r0, #2048 )
  THUMB(	str	r3, [r0] )
-	ALT_SMP(mov	pc,lr)
+	ALT_SMP(W(nop))
 	ALT_UP (mcr	p15, 0, r0, c7, c10, 1)		@ flush_pte
 #endif
 	mov	pc, lr
diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S
index 363027e..6ba4bd9 100644
--- a/arch/arm/mm/proc-v7-3level.S
+++ b/arch/arm/mm/proc-v7-3level.S
@@ -73,7 +73,7 @@ ENTRY(cpu_v7_set_pte_ext)
 	tst	r3, #1 << (55 - 32)		@ L_PTE_DIRTY
 	orreq	r2, #L_PTE_RDONLY
 1:	strd	r2, r3, [r0]
-	ALT_SMP(mov	pc, lr)
+	ALT_SMP(W(nop))
 	ALT_UP (mcr	p15, 0, r0, c7, c10, 1)		@ flush_pte
 #endif
 	mov	pc, lr
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index e35fec3..5fbccee 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -75,13 +75,14 @@ ENTRY(cpu_v7_do_idle)
 ENDPROC(cpu_v7_do_idle)
 
 ENTRY(cpu_v7_dcache_clean_area)
-	ALT_SMP(mov	pc, lr)			@ MP extensions imply L1 PTW
-	ALT_UP(W(nop))
-	dcache_line_size r2, r3
-1:	mcr	p15, 0, r0, c7, c10, 1		@ clean D entry
+	ALT_SMP(W(nop))			@ MP extensions imply L1 PTW
+	ALT_UP_B(1f)
+	mov	pc, lr
+1:	dcache_line_size r2, r3
+2:	mcr	p15, 0, r0, c7, c10, 1		@ clean D entry
 	add	r0, r0, r2
 	subs	r1, r1, r2
-	bhi	1b
+	bhi	2b
 	dsb
 	mov	pc, lr
 ENDPROC(cpu_v7_dcache_clean_area)
-- 
1.8.2.2



From m.weisser.m at gmail.com  Thu Jul  4 11:03:21 2013
From: m.weisser.m at gmail.com (=?UTF-8?Q?Matthias_Wei=C3=9Fer?=)
Date: Thu, 4 Jul 2013 17:03:21 +0200
Subject: imx25: How to get frame buffer device in a system using device tree
Message-ID: <CAO8h3eFq9WhvZYbbeFfWgVEXViR8MAcGaztsvvaLpFSW-W6CfA@mail.gmail.com>

Hi

I am currently try to get Linux running on a custom imx25 hardware
using device tree. So far I am quite successfull and have the system
up using current mainline kernel and a NFS root file system. Now I
would like to have the framebuffer driver to get something on the LCD.

My dts file looks like this:

/dts-v1/;
#include "imx25.dtsi"

/ {
  model = "Graf-Syteco zmx25";
  compatible = "graf,imx25-zmx25", "fsl,imx25";

  memory {
    reg = <0x80000000 0x4000000>;
  };

  soc {
    aips at 53f00000 { /* AIPS2 */
      lcdc at 53fbc000 {
        status = "okay";
      };
    };
  };
};

&uart1 {
  status = "okay";
};

&uart2 {
  status = "okay";
};

&fec {
  phy-mode = "rmii";
  status = "okay";
};

I also added the compatibility entry in the imx25.dtsi

--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -378,6 +378,7 @@
                        };

                        lcdc at 53fbc000 {
+                               compatible = "fsl,imx27-fb", "fsl,imx21-fb";
                                reg = <0x53fbc000 0x4000>;
                                interrupts = <39>;
                                clocks = <&clks 103>, <&clks 66>, <&clks 49>;

But still I didn't get /dev/fb so I think I am doing something wrong.
Any hints for docs I can study on how to do the right things?

Regards
Matthias


From shawn.guo at linaro.org  Thu Jul  4 11:14:00 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 4 Jul 2013 23:14:00 +0800
Subject: [PATCH] ASoC: wm8962: fix NULL pdata pointer
Message-ID: <1372950840-13393-1-git-send-email-shawn.guo@linaro.org>

There is an error in merge commit 384b834 on conflict resolution which
causes the following NULL pdata pointer bug.

wm8962 0-001a: customer id 0 revision D
Unable to handle kernel NULL pointer dereference at virtual address 00000004
pgd = 80004000
[00000004] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0+ #1
task: bf870000 ti: bf874000 task.ti: bf874000
PC is at wm8962_probe+0x134/0x6c8
LR is at regmap_unlock_mutex+0x10/0x14
pc : [<80452100>]    lr : [<80304cf4>]    psr: a0000113
sp : bf875c98  ip : 00000000  fp : bf875cd4
r10: 00000000  r9 : bfb1830c  r8 : 80779bc4
r7 : 00000000  r6 : 00000001  r5 : bfbac010  r4 : bfb33e00
r3 : 80304ce4  r2 : 00000000  r1 : 00000001  r0 : fffffffb
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 1000404a  DAC: 00000017
Process swapper/0 (pid: 1, stack limit = 0xbf874238)
Stack: (0xbf875c98 to 0xbf876000)
...

Fix the error by assigning pdata a correct pointer.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 sound/soc/codecs/wm8962.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
index b1dc7d4..e2de9ec 100644
--- a/sound/soc/codecs/wm8962.c
+++ b/sound/soc/codecs/wm8962.c
@@ -3377,7 +3377,7 @@ static int wm8962_probe(struct snd_soc_codec *codec)
 {
 	int ret;
 	struct wm8962_priv *wm8962 = snd_soc_codec_get_drvdata(codec);
-	struct wm8962_pdata *pdata = dev_get_platdata(codec->dev);
+	struct wm8962_pdata *pdata = &wm8962->pdata;
 	int i, trigger, irq_pol;
 	bool dmicclk, dmicdat;
 
-- 
1.7.9.5




From mpfj-list at newflow.co.uk  Thu Jul  4 11:14:14 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Thu, 04 Jul 2013 16:14:14 +0100
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51D577E6.5010507@newflow.co.uk>
References: <51D577E6.5010507@newflow.co.uk>
Message-ID: <51D59146.3070002@newflow.co.uk>

On 04/07/13 14:25, Mark Jackson wrote:
> Our custom AM335x board has been booting just fine under 3.10.0-rc4.
> 
> I've just done a git pull to update to 3.10 (now that it's released)
> and the board now hangs.
> 
> Before I start trying to bisect the issue, does anyone have an clues ?

Okay ... I've now bisected it to:-

a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
commit a630fbfbb1beeffc5bbe542a7986bf2068874633
Author: Tony Lindgren <tony at atomide.com>
Date:   Mon Jun 10 07:39:09 2013 -0700

    serial: omap: Fix device tree based PM runtime
    
    In the runtime_suspend function pdata is not being used, and
    also blocks the function in device tree based booting. Fix it
    by removing the unused pdata from the runtime_suspend function.
    
    Further, context loss count is not being passed in pdata, so
    let's just reinitialize the port every time for those case.
    This can be further optimized later on for the device tree
    case by adding detection for the hardware state and possibly
    by adding a driver specific autosuspend timeout.
    
    And doing this, we can then make the related dev_err into a
    dev_dbg message instead of an error.
    
    In order for the wake-up events to work, we also need to set
    autosuspend_timeout to -1 if 0, and also device_init_wakeup()
    as that's not being done by the platform init code for the
    device tree case.
    
    Note that this does not affect legacy booting, and in fact
    might make it work for the cases where the context loss info
    is not being passed in pdata.
    
    Thanks to Kevin Hilman <khilman at linaro.org> for debugging
    and suggesting fixes for the autosuspend_timeout and
    device_init_wakeup() related initializiation.
    
    Reviewed-by: Kevin Hilman <khilman at linaro.org>
    Tested-by: Kevin Hilman <khilman at linaro.org>
    Signed-off-by: Tony Lindgren <tony at atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

:040000 040000 38900a5a2ed6dfeb812d93bf1918725021298884 a38d37777dcd46276dc27b87157fd0b1e292804c M	drivers




From festevam at gmail.com  Thu Jul  4 11:16:36 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 4 Jul 2013 12:16:36 -0300
Subject: imx25: How to get frame buffer device in a system using device
 tree
In-Reply-To: <CAO8h3eFq9WhvZYbbeFfWgVEXViR8MAcGaztsvvaLpFSW-W6CfA@mail.gmail.com>
References: <CAO8h3eFq9WhvZYbbeFfWgVEXViR8MAcGaztsvvaLpFSW-W6CfA@mail.gmail.com>
Message-ID: <CAOMZO5Aat-iAN_TJ6BXEopB+WCkKgLjWh67sCXg0jd1DtzmKSQ@mail.gmail.com>

Hi Matthias,

On Thu, Jul 4, 2013 at 12:03 PM, Matthias Wei?er <m.weisser.m at gmail.com> wrote:
> Hi
>
> I am currently try to get Linux running on a custom imx25 hardware
> using device tree. So far I am quite successfull and have the system
> up using current mainline kernel and a NFS root file system. Now I
> would like to have the framebuffer driver to get something on the LCD.
>
> My dts file looks like this:

These mx27 examples can help you to implement the support for mx25:

https://git.linaro.org/gitweb?p=people/shawnguo/linux-2.6.git;a=commitdiff;h=dcd23b848ed2e35f968a10984e255527b4dde3d5;hp=807f38ec8aae50626d5b4705a0a0f5c585275867

https://git.linaro.org/gitweb?p=people/shawnguo/linux-2.6.git;a=blob;f=arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts;h=390d8f2f84d120bace022322c6319d82cf7e5a47;hb=refs/heads/for-next

Regards,

Fabio Estevam


From dserrg at gmail.com  Thu Jul  4 11:36:25 2013
From: dserrg at gmail.com (Sergey Dyasly)
Date: Thu,  4 Jul 2013 19:36:25 +0400
Subject: [PATCH v3] ARM: LPAE: don't reject mapping /dev/mem above 4GB
Message-ID: <1372952185-2553-1-git-send-email-dserrg@gmail.com>

With LPAE enabled, physical address space is larger than 4GB. Allow mapping any
part of it via /dev/mem by using PHYS_MASK to determine valid range.

PHYS_MASK covers 40 bits with LPAE enabled and 32 bits otherwise.

Reported-by: Vassili Karpov <av1474 at comtv.ru>
Signed-off-by: Sergey Dyasly <dserrg at gmail.com>
---

v3:
- Fixed 32-bit overflow

v2:
- Removed #ifdef and changed original function

 arch/arm/mm/mmap.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 10062ce..2db5d2d 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -204,13 +204,11 @@ int valid_phys_addr_range(phys_addr_t addr, size_t size)
 }
 
 /*
- * We don't use supersection mappings for mmap() on /dev/mem, which
- * means that we can't map the memory area above the 4G barrier into
- * userspace.
+ * Do not allow /dev/mem mappings beyond the supported physical range.
  */
 int valid_mmap_phys_addr_range(unsigned long pfn, size_t size)
 {
-	return !(pfn + (size >> PAGE_SHIFT) > 0x00100000);
+	return (pfn + (size >> PAGE_SHIFT)) <= (1 + (PHYS_MASK >> PAGE_SHIFT));
 }
 
 #ifdef CONFIG_STRICT_DEVMEM
-- 
1.8.1.2



From broonie at kernel.org  Thu Jul  4 11:41:05 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 4 Jul 2013 16:41:05 +0100
Subject: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to
 control PMIC over VC/VP
In-Reply-To: <1371849949-12649-2-git-send-email-nm@ti.com>
References: <1371849949-12649-1-git-send-email-nm@ti.com>
 <1371849949-12649-2-git-send-email-nm@ti.com>
Message-ID: <20130704154105.GD27646@sirena.org.uk>

On Fri, Jun 21, 2013 at 04:25:42PM -0500, Nishanth Menon wrote:

> +static const struct omap_pmic_info omap_twl4030_vdd1 = {
> +	.slave_addr = 0x12,
> +	.voltage_reg_addr = 0x00,
> +	.cmd_reg_addr = 0x00,
> +	.i2c_timeout_us = 200,
> +	.slew_rate_uV = 4000,
> +	.step_size_uV = 12500,
> +	.min_uV = 600000,
> +	.max_uV = 1450000,
> +	.voltage_selector_offset = 0,
> +	.voltage_selector_mask = 0x7F,
> +	.voltage_selector_setbits = 0x0,
> +	.voltage_selector_zero = false,
> +};

So, this still has the thing where all the data about the PMIC is
replicated (but now in this driver).  It should be possible to pull all
the above information except possibly the I2C timeout and perhaps the
I2C address (if there's a separate control interface) from the standard
regulator core data structures for the PMIC.  This would allow the
driver to Just Work with any PMIC without needing to add it in two
places.

Other than that this looks good, the only issue I see is where the
driver is getting the data from.
-------------- 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/20130704/f4329a32/attachment.sig>

From gianlucarenzi at eurekelettronica.it  Thu Jul  4 11:41:24 2013
From: gianlucarenzi at eurekelettronica.it (gianluca)
Date: Thu, 04 Jul 2013 17:41:24 +0200
Subject: imx25: How to get frame buffer device in a system using device
 tree
In-Reply-To: <CAOMZO5Aat-iAN_TJ6BXEopB+WCkKgLjWh67sCXg0jd1DtzmKSQ@mail.gmail.com>
References: <CAO8h3eFq9WhvZYbbeFfWgVEXViR8MAcGaztsvvaLpFSW-W6CfA@mail.gmail.com>
 <CAOMZO5Aat-iAN_TJ6BXEopB+WCkKgLjWh67sCXg0jd1DtzmKSQ@mail.gmail.com>
Message-ID: <51D597A4.2010608@eurekelettronica.it>

On 07/04/2013 05:16 PM, Fabio Estevam wrote:
> Hi Matthias,
>
> On Thu, Jul 4, 2013 at 12:03 PM, Matthias Wei?er <m.weisser.m at gmail.com> wrote:
>> Hi
>>
>> I am currently try to get Linux running on a custom imx25 hardware
>> using device tree. So far I am quite successfull and have the system
>> up using current mainline kernel and a NFS root file system. Now I
>> would like to have the framebuffer driver to get something on the LCD.
>>
>> My dts file looks like this:
>
> These mx27 examples can help you to implement the support for mx25:
>
> https://git.linaro.org/gitweb?p=people/shawnguo/linux-2.6.git;a=commitdiff;h=dcd23b848ed2e35f968a10984e255527b4dde3d5;hp=807f38ec8aae50626d5b4705a0a0f5c585275867
>
> https://git.linaro.org/gitweb?p=people/shawnguo/linux-2.6.git;a=blob;f=arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts;h=390d8f2f84d120bace022322c6319d82cf7e5a47;hb=refs/heads/for-next
>

The links above are valid as skeleton for a imx28 based board?

Best regards,
-- 
            ,,,
           (o o)
======oOO==(_)==OOo======

Gianluca Renzi
R&D
phone: +39.0542.609120
fax:   +39.0542.609212

       .oooO  Oooo.
======(   )==(   )=======
        \ (    ) /
         \_)  (_/

===================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
  \ source code!  /
   ---------------
     ?\_(".)_/?


From p.zabel at pengutronix.de  Thu Jul  4 11:41:51 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 04 Jul 2013 17:41:51 +0200
Subject: [PATCH v2 1/6] misc: sram: fix error path in sram_probe
In-Reply-To: <201307041634.11248.heiko@sntech.de>
References: <201306251046.04873.heiko@sntech.de>
 <201306251046.38993.heiko@sntech.de>
 <1372151074.3981.21.camel@pizza.hi.pengutronix.de>
 <201307041634.11248.heiko@sntech.de>
Message-ID: <1372952511.3974.38.camel@pizza.hi.pengutronix.de>

Hi Heiko,

Am Donnerstag, den 04.07.2013, 16:34 +0200 schrieb Heiko St?bner:
> Hi Philipp,
> 
> Am Dienstag, 25. Juni 2013, 11:04:34 schrieb Philipp Zabel:
> > Hi Heiko,
> > 
> > Am Dienstag, den 25.06.2013, 10:46 +0200 schrieb Heiko St?bner:
> > > The pool is created thru devm_gen_pool_create, so the call to
> > > gen_pool_destroy is not necessary.
> > > Instead the sram-clock must be turned off again if it exists.
> > > 
> > > Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> > > ---
> > > 
> > >  drivers/misc/sram.c |    3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
> > > index d87cc91..afe66571 100644
> > > --- a/drivers/misc/sram.c
> > > +++ b/drivers/misc/sram.c
> > > @@ -68,7 +68,8 @@ static int sram_probe(struct platform_device *pdev)
> > > 
> > >  	ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
> > >  	
> > >  				res->start, size, -1);
> > >  	
> > >  	if (ret < 0) {
> > > 
> > > -		gen_pool_destroy(sram->pool);
> > 
> > Right, thanks.
> > 
> > > +		if (sram->clk)
> > > +			clk_disable_unprepare(sram->clk);
> > > 
> > >  		return ret;
> > >  	
> > >  	}
> > 
> > In light of the following patch, I'd rather move the
> > clk_prepare_enable() call after gen_pool_add_virt() and its error path.
> 
> I'm not sure, but isn't moving the clock enablement below the pool allocation 
> producing a race condition?

since this is a platform device, and the driver is not allowed to be
compiled as a module, it is probed at the time platform_driver_register
is called from postcore_initcall.
You'd have to go to quite some lengths to make this race by probing your
driver before mmio-sram and then asynchronously trying to allocate
memory from the pool some time later, without having made sure that the
pool exists during probe.

It would be nice to have callbacks from gen_pool_alloc/free to
enable/disable the clock.
For the time being, maybe it's the safest bet to just enable the clock
before, especially if you reorder the loop so there is only one
gen_pool_add_virt and corresponding error path.

> I.e. can the case happen that some other part wants to allocate part of the 
> newly generated pool already, while the subsequent gen_pool_add_virt calls 
> from the following patch are still running? ... And what will happen in this 
> case, when the sram clock is still disabled?

On i.MX6, the system will hang.

regards
Philipp



From festevam at gmail.com  Thu Jul  4 11:49:14 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 4 Jul 2013 12:49:14 -0300
Subject: imx25: How to get frame buffer device in a system using device
 tree
In-Reply-To: <51D597A4.2010608@eurekelettronica.it>
References: <CAO8h3eFq9WhvZYbbeFfWgVEXViR8MAcGaztsvvaLpFSW-W6CfA@mail.gmail.com>
 <CAOMZO5Aat-iAN_TJ6BXEopB+WCkKgLjWh67sCXg0jd1DtzmKSQ@mail.gmail.com>
 <51D597A4.2010608@eurekelettronica.it>
Message-ID: <CAOMZO5DLvHDMedq5P5bwg3kdjrFnaOibgxujJj29XLSiZn4Hag@mail.gmail.com>

On Thu, Jul 4, 2013 at 12:41 PM, gianluca
<gianlucarenzi at eurekelettronica.it> wrote:

> The links above are valid as skeleton for a imx28 based board?

No, these examples are for mx27. mx25 and mx27 share the same video controller.

For a mx28 example, you can refer to imx28-evk.dts.


From broonie at kernel.org  Thu Jul  4 11:49:27 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 4 Jul 2013 16:49:27 +0100
Subject: SPI: DUAL/QUAD support
In-Reply-To: <OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704130017.GA25997@sig21.net>
 <OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>
Message-ID: <20130704154927.GE27646@sirena.org.uk>

On Thu, Jul 04, 2013 at 04:58:52PM +0200, Thomas.Betker at rohde-schwarz.com wrote:

> This situation is certainly a bit special. To me, the patch looks like a 
> short-time workaround; I would rather see the flash driver support actual 
> dual or quad mode commands. Is there any work in progress?

Well, there's two bits here.  One is the support in the client drivers
for using the extra data lines and the other is the support in the SPI
core for telling controllers to do this.  We need that second bit in
place before the first one can be implemented.
-------------- 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/20130704/5c865c14/attachment.sig>

From broonie at kernel.org  Thu Jul  4 11:50:28 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 4 Jul 2013 16:50:28 +0100
Subject: [PATCH] ASoC: wm8962: fix NULL pdata pointer
In-Reply-To: <1372950840-13393-1-git-send-email-shawn.guo@linaro.org>
References: <1372950840-13393-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130704155028.GF27646@sirena.org.uk>

On Thu, Jul 04, 2013 at 11:14:00PM +0800, Shawn Guo wrote:
> There is an error in merge commit 384b834 on conflict resolution which
> causes the following NULL pdata pointer bug.

Applied, thanks.
-------------- 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/20130704/79a0e972/attachment-0001.sig>

From mpfj-list at newflow.co.uk  Thu Jul  4 12:00:14 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Thu, 04 Jul 2013 17:00:14 +0100
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51D59146.3070002@newflow.co.uk>
References: <51D577E6.5010507@newflow.co.uk> <51D59146.3070002@newflow.co.uk>
Message-ID: <51D59C0E.8080003@newflow.co.uk>

On 04/07/13 16:14, Mark Jackson wrote:
> On 04/07/13 14:25, Mark Jackson wrote:
>> Our custom AM335x board has been booting just fine under 3.10.0-rc4.
>>
>> I've just done a git pull to update to 3.10 (now that it's released)
>> and the board now hangs.
>>
>> Before I start trying to bisect the issue, does anyone have an clues ?
> 
> Okay ... I've now bisected it to:-
> 
> a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
> commit a630fbfbb1beeffc5bbe542a7986bf2068874633
> Author: Tony Lindgren <tony at atomide.com>
> Date:   Mon Jun 10 07:39:09 2013 -0700
> 
>     serial: omap: Fix device tree based PM runtime

However, reverting the commit does *not* fix the issue, weird !!

But I have now tested:-

v3.10-rc4     -> works
v3.10-rc5     -> works
v3.10-rc6     -> works
v3.10-rc7     -> works
v3.10         -> works
origin/master -> hangs

Any ideas ?


From Thomas.Betker at rohde-schwarz.com  Thu Jul  4 12:04:14 2013
From: Thomas.Betker at rohde-schwarz.com (Thomas.Betker at rohde-schwarz.com)
Date: Thu, 4 Jul 2013 18:04:14 +0200
Subject: SPI: DUAL/QUAD support
In-Reply-To: <20130704154927.GE27646@sirena.org.uk>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704130017.GA25997@sig21.net>
 <OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>
 <20130704154927.GE27646@sirena.org.uk>
Message-ID: <OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>

Hello Mark:

> Well, there's two bits here.  One is the support in the client drivers
> for using the extra data lines and the other is the support in the SPI
> core for telling controllers to do this.  We need that second bit in
> place before the first one can be implemented.

I am not sure if we do. In the system I am working on, the QSPI controller 
recognizes the quad mode commands from the Tx data and automatically 
switches modes; no manual intervention by the flash driver is needed.

I agree that this may not be the case for all SPI controllers. Yuhang, can 
you tell us what your controller will do?

Best regards,
Thomas



From magnus.damm at gmail.com  Thu Jul  4 12:25:18 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Fri, 5 Jul 2013 01:25:18 +0900
Subject: [PATCH v3] ARM: shmobile: lager: Add DT reference
In-Reply-To: <1438555.HIWtKGAp3v@avalon>
References: <1372838251-6314-1-git-send-email-horms+renesas@verge.net.au>
 <1438555.HIWtKGAp3v@avalon>
Message-ID: <CANqRtoRzBAxeirMyKRqb-PrufFPGDQOqCnkKDEkx1pNsJqXPJA@mail.gmail.com>

Hi Laurent,

[CC Kuribayashi-san]

On Fri, Jul 5, 2013 at 12:02 AM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> Hi Simon,
>
> On Wednesday 03 July 2013 16:57:31 Simon Horman wrote:
>> This is sufficient to allow boot of the Lager board with a console without
>> boards-lager.c compiled into the kernel. This is an example of a minimal but
>> still useful initialisation of the board using DT as much as possible.
>>
>> As such it is the same as the boot of Lager that can be achieved without a
>> board file. The intention of adding this file is to facilitate further work
>> to allow board specific devices to be initialised via DT.
>
> At some (hopefully not too distant) point we should stop adding both
> traditional and DT board files. DT is supposed to lower the number of board
> files, not multiply it by two.

Well, mr-multiply-by-two: While I dislike code duplication I can't
recall when the number of files actually decreased with DT.

I realize that when we can use DT fully to describe a board then a
single DTS file is enough to describe board specific hardware together
with per-SoC C code. I can't however see how that would reduce the
number of files, but whatever. I always thought the goal was to reduce
the memory footprint of the kernel and that the source would not come
with that many limitations, but it seems that I got that all wrong...

Anyway, the current split on mach-shmobile is intentional:

1) The C version of board support (board-xxx.c)

This is where platform devices are used (with power domains in some
cases) and where out-of-tree people can experiment with things. This
code is using legacy SH clock code and is not targeted for
multiplatform. These should go away, the sooner the better.

2) The DT reference support (board-xxx-reference.c)

This file contains whatever bits of C code needed to get the DT
support going. All the board specific devices should be described via
DT. The DT reference board support is where we build incremental
support to catch up with 1) board-xxx.c. Ideally we wouldn't need the
board-xxx-reference.c file and instead only go with .dts, but in some
cases we need some extra glue and until pinctrl DT is done we also
need those written in C. The DT reference support will use common
clocks as soon as they are available.

3) SoC DT support (setup-xxx.c)

This is what will be used when 2) is caught up with 1). Common clocks
and multiplatform, one SoC at a time.

> Work is still needed in order to achieve this, as we lack DT bindings for core
> (and non core) devices. That's something we need to work on. As a first step,
> do we have a roadmap with a list of devices that lack DT support ? At the very
> least I see more work needed on
>
> - Common clock framework

Yes, I agree. Please see below for more about that.

> - SCI

Indeed, someone needs to continue earlier efforts for the SCIF driver.
Fortunately, with EMEV2 our UART driver already supports DT, so we can
implement DT-only multiplatform support on EMEV2 regardless of the
state of SCIF.

> - Timers

We can use DT-only with Arch timer, but unfortunately another clock
evenit is needed unconditionally for high resolution timer support,
search for clock event and the C3STOP flag if you want to see me moan
about that.

Regardless I believe someone took a couple of first steps towards DT
support for our timers some time ago. But as we discussed face to face
about a month ago, it makes sense to describe the hardware via DT but
in case of timers and clock event / clock sources it does not make
sense to associate 87 timer channels for operating system time
keeping. So we need some user space configuration interface to
associate different kind of timer applications (operating system
timer, PWM, clock generation, etc) to different channels.

Since you mention it: =)
- PINCTRL DT and GPIO DT

I'd like to start picking up the remaining PINCTRL and GPIO bits for
v3.12 merge. Can you please rebase and resend on top of the latest
renesas-next tag?

> We shouldn't delay CCF much longer, v3.12 seems an achievable target to me.
> Who will work on that ?

So I am currently preparing EMEV2 for multiplatform, will most likely
have patches posted for that next week. And yes, I intend to send a
new DT reference board support file.

In parallel Kuribayashi-san is taking a stab at moving to common
clocks for EMEV2 as a first step.

I expect the above to be in order for v3.12, but not much more that that.

Cheers,

/ magnus


From csd at broadcom.com  Thu Jul  4 12:25:46 2013
From: csd at broadcom.com (Christian Daudt)
Date: Thu, 4 Jul 2013 09:25:46 -0700
Subject: [PATCH] ARM bcm281xx: Turn on socket & network support.
In-Reply-To: <1371683329-14827-1-git-send-email-markus.mayer@linaro.org>
References: <1371683329-14827-1-git-send-email-markus.mayer@linaro.org>
Message-ID: <51D5A20A.6070209@broadcom.com>

On 13-06-19 04:08 PM, Markus Mayer wrote:
> We need this so an actual disk-based root file system will work.
>
> Signed-off-by: Markus Mayer <markus.mayer at linaro.org>
> Acked-by: Christian Daudt <csd at broadcom.com>
> ---
>   arch/arm/configs/bcm_defconfig |   12 ++++++++++++
>   1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
> index e3bf2d6..63780b2 100644
> --- a/arch/arm/configs/bcm_defconfig
> +++ b/arch/arm/configs/bcm_defconfig
> @@ -42,6 +42,18 @@ CONFIG_VFP=y
>   CONFIG_NEON=y
>   # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
>   CONFIG_PM_RUNTIME=y
> +CONFIG_NET=y
> +CONFIG_PACKET=y
> +CONFIG_PACKET_DIAG=y
> +CONFIG_UNIX=y
> +CONFIG_UNIX_DIAG=y
> +CONFIG_NET_KEY=y
> +CONFIG_INET=y
> +CONFIG_IP_MULTICAST=y
> +CONFIG_ARPD=y
> +CONFIG_SYN_COOKIES=y
> +CONFIG_TCP_MD5SIG=y
> +CONFIG_IPV6=y
>   CONFIG_DEVTMPFS=y
>   CONFIG_DEVTMPFS_MOUNT=y
>   CONFIG_PROC_DEVICETREE=y
applied.
  thanks,
    csd




From csd at broadcom.com  Thu Jul  4 12:26:11 2013
From: csd at broadcom.com (Christian Daudt)
Date: Thu, 4 Jul 2013 09:26:11 -0700
Subject: [PATCH] ARM: bcm281xx: Turn on L2 cache.
In-Reply-To: <1371683718-15026-1-git-send-email-markus.mayer@linaro.org>
References: <1371683718-15026-1-git-send-email-markus.mayer@linaro.org>
Message-ID: <51D5A223.5010107@broadcom.com>

On 13-06-19 04:15 PM, Markus Mayer wrote:
> Turning on the L2 cache for the bcm281xx family.
>
> Signed-off-by: Markus Mayer <markus.mayer at linaro.org>
> Acked-by: Christian Daudt <csd at broadcom.com>
> ---
>   arch/arm/mach-bcm/Kconfig |    1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index f112895..69d67f7 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -12,6 +12,7 @@ config ARCH_BCM
>   	select GPIO_BCM
>   	select SPARSE_IRQ
>   	select TICK_ONESHOT
> +	select CACHE_L2X0
>   	help
>   	  This enables support for system based on Broadcom SoCs.
>   	  It currently supports the 'BCM281XX' family, which includes
applied.
  thanks,
    csd




From csd at broadcom.com  Thu Jul  4 12:26:28 2013
From: csd at broadcom.com (Christian Daudt)
Date: Thu, 4 Jul 2013 09:26:28 -0700
Subject: [PATCH] ARM: bcm281xx: Adding bcm28155-ap.dts
In-Reply-To: <1371684254-15189-1-git-send-email-markus.mayer@linaro.org>
References: <1371684254-15189-1-git-send-email-markus.mayer@linaro.org>
Message-ID: <51D5A234.6080304@broadcom.com>

On 13-06-19 04:24 PM, Markus Mayer wrote:
> Add support for the BCM28155 AP board.
>
> Signed-off-by: Markus Mayer <markus.mayer at linaro.org>
> Acked-by: Christian Daudt <csd at broadcom.com>
> ---
>   arch/arm/boot/dts/Makefile        |    3 ++-
>   arch/arm/boot/dts/bcm28155-ap.dts |   29 +++++++++++++++++++++++++++++
>   2 files changed, 31 insertions(+), 1 deletion(-)
>   create mode 100644 arch/arm/boot/dts/bcm28155-ap.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f0895c5..187f336 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -40,7 +40,8 @@ dtb-$(CONFIG_ARCH_AT91)	+= sama5d34ek.dtb
>   dtb-$(CONFIG_ARCH_AT91)	+= sama5d35ek.dtb
>   
>   dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
> -dtb-$(CONFIG_ARCH_BCM) += bcm11351-brt.dtb
> +dtb-$(CONFIG_ARCH_BCM) += bcm11351-brt.dtb \
> +	bcm28155-ap.dtb
>   dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
>   	da850-evm.dtb
>   dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
> diff --git a/arch/arm/boot/dts/bcm28155-ap.dts b/arch/arm/boot/dts/bcm28155-ap.dts
> new file mode 100644
> index 0000000..0d66db6
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm28155-ap.dts
> @@ -0,0 +1,29 @@
> +/*
> + * Copyright (C) 2013 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +/dts-v1/;
> +
> +#include "bcm11351.dtsi"
> +
> +/ {
> +	model = "BCM28155 AP board";
> +	compatible = "bcm,bcm28155-ap", "bcm,bcm11351";
> +
> +	memory {
> +		reg = <0x80000000 0x40000000>; /* 1 GB */
> +	};
> +
> +	uart at 3e000000 {
> +		status = "okay";
> +	};
> +};
applied.
  thanks,
    csd



From axel.lin at ingics.com  Thu Jul  4 12:31:36 2013
From: axel.lin at ingics.com (Axel Lin)
Date: Fri, 05 Jul 2013 00:31:36 +0800
Subject: [PATCH] irqchip: bcm2835: Convert to use IRQCHIP_DECLARE macro
Message-ID: <1372955496.9018.2.camel@phoenix>

This patch converts irq-bcm2835 driver to use the new IRQCHIP_DECLARE and
irqchip_init.

Signed-off-by: Axel Lin <axel.lin at ingics.com>
---
 arch/arm/mach-bcm2835/bcm2835.c |  5 ++---
 drivers/irqchip/irq-bcm2835.c   | 22 ++++++++++------------
 include/linux/irqchip/bcm2835.h | 29 -----------------------------
 3 files changed, 12 insertions(+), 44 deletions(-)
 delete mode 100644 include/linux/irqchip/bcm2835.h

diff --git a/arch/arm/mach-bcm2835/bcm2835.c b/arch/arm/mach-bcm2835/bcm2835.c
index 40686d7..a4abd85 100644
--- a/arch/arm/mach-bcm2835/bcm2835.c
+++ b/arch/arm/mach-bcm2835/bcm2835.c
@@ -14,7 +14,7 @@
 
 #include <linux/delay.h>
 #include <linux/init.h>
-#include <linux/irqchip/bcm2835.h>
+#include <linux/irqchip.h>
 #include <linux/of_address.h>
 #include <linux/of_platform.h>
 #include <linux/clk/bcm2835.h>
@@ -131,8 +131,7 @@ static const char * const bcm2835_compat[] = {
 
 DT_MACHINE_START(BCM2835, "BCM2835")
 	.map_io = bcm2835_map_io,
-	.init_irq = bcm2835_init_irq,
-	.handle_irq = bcm2835_handle_irq,
+	.init_irq = irqchip_init,
 	.init_machine = bcm2835_init,
 	.init_time = clocksource_of_init,
 	.restart = bcm2835_restart,
diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index 16c78f1..c29408e 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -49,9 +49,11 @@
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 #include <linux/irqdomain.h>
-#include <linux/irqchip/bcm2835.h>
 
 #include <asm/exception.h>
+#include <asm/mach/irq.h>
+
+#include "irqchip.h"
 
 /* Put the bank and irq (32 bits) into the hwirq */
 #define MAKE_HWIRQ(b, n)	((b << 5) | (n))
@@ -93,6 +95,8 @@ struct armctrl_ic {
 };
 
 static struct armctrl_ic intc __read_mostly;
+static asmlinkage void __exception_irq_entry bcm2835_handle_irq(
+	struct pt_regs *regs);
 
 static void armctrl_mask_irq(struct irq_data *d)
 {
@@ -164,17 +168,9 @@ static int __init armctrl_of_init(struct device_node *node,
 			set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
 		}
 	}
-	return 0;
-}
-
-static struct of_device_id irq_of_match[] __initconst = {
-	{ .compatible = "brcm,bcm2835-armctrl-ic", .data = armctrl_of_init },
-	{ }
-};
 
-void __init bcm2835_init_irq(void)
-{
-	of_irq_init(irq_of_match);
+	set_handle_irq(bcm2835_handle_irq);
+	return 0;
 }
 
 /*
@@ -200,7 +196,7 @@ static void armctrl_handle_shortcut(int bank, struct pt_regs *regs,
 	handle_IRQ(irq_linear_revmap(intc.domain, irq), regs);
 }
 
-asmlinkage void __exception_irq_entry bcm2835_handle_irq(
+static asmlinkage void __exception_irq_entry bcm2835_handle_irq(
 	struct pt_regs *regs)
 {
 	u32 stat, irq;
@@ -222,3 +218,5 @@ asmlinkage void __exception_irq_entry bcm2835_handle_irq(
 		}
 	}
 }
+
+IRQCHIP_DECLARE(bcm2835_armctrl_ic, "brcm,bcm2835-armctrl-ic", armctrl_of_init);
diff --git a/include/linux/irqchip/bcm2835.h b/include/linux/irqchip/bcm2835.h
deleted file mode 100644
index 48a859b..0000000
--- a/include/linux/irqchip/bcm2835.h
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * Copyright (C) 2010 Broadcom
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-
-#ifndef __LINUX_IRQCHIP_BCM2835_H_
-#define __LINUX_IRQCHIP_BCM2835_H_
-
-#include <asm/exception.h>
-
-extern void bcm2835_init_irq(void);
-
-extern asmlinkage void __exception_irq_entry bcm2835_handle_irq(
-	struct pt_regs *regs);
-
-#endif
-- 
1.8.1.2





From catalin.marinas at arm.com  Thu Jul  4 12:34:24 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 4 Jul 2013 17:34:24 +0100
Subject: [PATCH v3] ARM: LPAE: don't reject mapping /dev/mem above 4GB
In-Reply-To: <1372952185-2553-1-git-send-email-dserrg@gmail.com>
References: <1372952185-2553-1-git-send-email-dserrg@gmail.com>
Message-ID: <20130704163424.GA20048@arm.com>

On Thu, Jul 04, 2013 at 04:36:25PM +0100, Sergey Dyasly wrote:
> With LPAE enabled, physical address space is larger than 4GB. Allow mapping any
> part of it via /dev/mem by using PHYS_MASK to determine valid range.
> 
> PHYS_MASK covers 40 bits with LPAE enabled and 32 bits otherwise.
> 
> Reported-by: Vassili Karpov <av1474 at comtv.ru>
> Signed-off-by: Sergey Dyasly <dserrg at gmail.com>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From paul at pwsan.com  Thu Jul  4 12:44:23 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Thu, 4 Jul 2013 16:44:23 +0000 (UTC)
Subject: [RFC 0/4] Cleanup PRM and CM regbit headers
In-Reply-To: <51D56743.9080800@ti.com>
References: <1372076143-12955-1-git-send-email-rnayak@ti.com>
 <20130625071428.GC5523@atomide.com> <51C95839.6050307@ti.com>
 <20130704115819.GJ5523@atomide.com> <51D56743.9080800@ti.com>
Message-ID: <alpine.DEB.2.02.1307041627540.6258@utopia.booyaka.com>

On Thu, 4 Jul 2013, Rajendra Nayak wrote:

> Paul/Benoit,
> 
> Should I also drop these lines from the file headers since they are no
> longer same as the outputs from autogen files?
> 
>  * This file is automatically generated from the OMAP hardware databases.
>  * We respectfully ask that any modifications to this file be coordinated
>  * with the public linux-omap at vger.kernel.org mailing list and the
>  * authors above to ensure that the autogeneration scripts are kept
>  * up-to-date with the file contents.

Heh...

Here's my view:

You mentioned that these patches were generated with some kind of awk/grep 
scripting.  Can you integrate that in an automated way into the 
autogeneration flow?  If the answer is yes, then keep the header.  If the 
answer is no, then the header should be dropped.  Beno?t, maybe you have 
an opinion too?

As far as whether this should go in -rcX or not, my view is that, as a 
matter of policy, large changes like this should wait until v3.12.  Now, 
having written that, I also was under the impression that the OMAP5 
changes weren't going to be sent upstream unless the total diffstat would 
be balanced to roughly zero or negative lines.  As far as I know, that 
didn't happen.  So I guess, v3.11-rc it is...  kernel development by 
diffstat :-(

Finally, please repost the whole series once you're done with your 
changes, as a non-RFC, along with your pull request (if you plan to send 
one).  I guess I should be the one to take these, since I wound up taking 
the OMAP5 addition...


regards

- Paul

From zonque at gmail.com  Thu Jul  4 12:56:24 2013
From: zonque at gmail.com (Daniel Mack)
Date: Thu, 04 Jul 2013 18:56:24 +0200
Subject: Appended DTB files for multi-machine kernels
Message-ID: <51D5A938.30607@gmail.com>

Hi,

I'm facing a problem with a transition from legacy board-file driven ARM
machines to DTB, and I'm under the impression that a solution for it
could be of broader interest.

In short, devices that have been deployed in quantities come in three
hardware variants, which all boot with a unique machine-id. We ship
kernel images that have board support for all three machine types, and
do minor fixups to platform data of some drivers at runtime, depending
on the board revision number (passed in via ATAGs).

The built-in support for attaching a DTB to the zImage does not suffice
here, because we have one image for all models, and also, we couldn't do
a 'per-board-revision' selection that way either.

Unless I missed some recent discussion, this case is not easy to handle.
Yes, I know that these kind of things should be handled by a
next-generation bootloader, but in our case, we want to avoid a loader
update of already shipped hardware by all means.

As a solution, I'm thinking of a small framework that could for example
work as follows.

a) A small mechanism allows storing multiple DTB binary files inside the
kernel binary at compile time, and a simple function can extract them
again by name at runtime (something like what the firmware framework
does, but I don't know if that one can be used at such an early stage in
the boot process).

b) A DT_MACHINE_START-like macro takes both the machine ID and the name
of a DTB file that is compiled in. When matched, generic functions would
load the given file, populate the device tree and then conduct a generic
DT boot for the specified platform.

c) Allow users to open-code the DTB lookup depending on whatever kind of
runtime information (be it the board_revision or anything else).


Of course, everything has to be an opt-in that stubs itself out at zero
costs if not needed.


I'm open to opinion and sugesstions :)


Thanks,
Daniel


From paul at pwsan.com  Thu Jul  4 13:11:33 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Thu, 4 Jul 2013 17:11:33 +0000 (UTC)
Subject: OMAP baseline test results for v3.10-rc7
In-Reply-To: <20130701204236.GA805@arwen.pp.htv.fi>
References: <alpine.DEB.2.02.1307011946180.4358@utopia.booyaka.com>
 <20130701204236.GA805@arwen.pp.htv.fi>
Message-ID: <alpine.DEB.2.02.1307041650170.6258@utopia.booyaka.com>

Hi

On Mon, 1 Jul 2013, Felipe Balbi wrote:

> On Mon, Jul 01, 2013 at 07:48:50PM +0000, Paul Walmsley wrote:
> > Boot to userspace:
> >     FAIL ( 2/12): 37xxevm, am335xbonelt
> 
> <quoting part of [1]>
> | U-Boot# tftp 0x82000000 am335x-boneblack.dtb
> | link up on port 0, speed 100, full duplex
> | Using cpsw device
> | TFTP from server 192.168.57.1; our IP address is 192.168.57.138
> | Filename 'am335x-boneblack.dtb'.
> 
> Where are you taking am335x-boneblack.dtb from ? It's not in mainline
> v3.10-rc7 kernel:

As mentioned in my earlier reply:

http://www.spinics.net/lists/arm-kernel/msg255055.html

my earlier test boots were with the am335x-boneblack.dtb from the 
ti-linux-3.8.y tree from Vaibhav's github, since that was the only DTB 
that I was able to get any kernel to boot with.

The am33xx_only/appended DTB issues don't apply to this board since it's 
booted with detached DTB and omap2plus_defconfig.

Anyway, just retried it with the mainline am335x-bone.dtb file with v3.10, 
and the board comes up now.  So that's good, will switch to 
am335x-bone.dtb for the testing restate jobs to be run for 
BeagleBone-white, and let's see what previous kernels it boots with now...


- Paul


From broonie at kernel.org  Thu Jul  4 13:11:48 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 4 Jul 2013 18:11:48 +0100
Subject: Appended DTB files for multi-machine kernels
In-Reply-To: <51D5A938.30607@gmail.com>
References: <51D5A938.30607@gmail.com>
Message-ID: <20130704171148.GJ27646@sirena.org.uk>

On Thu, Jul 04, 2013 at 06:56:24PM +0200, Daniel Mack wrote:

> Unless I missed some recent discussion, this case is not easy to handle.
> Yes, I know that these kind of things should be handled by a
> next-generation bootloader, but in our case, we want to avoid a loader
> update of already shipped hardware by all means.

There was some discussion about appending multiple DTBs recently.  I
can't actually recall anything about it though so that's not an entirely
helpful thing...

> As a solution, I'm thinking of a small framework that could for example
> work as follows.

> a) A small mechanism allows storing multiple DTB binary files inside the
> kernel binary at compile time, and a simple function can extract them
> again by name at runtime (something like what the firmware framework
> does, but I don't know if that one can be used at such an early stage in
> the boot process).

Another way of skinning this would be for either the kernel to contain
a set of machine ID to compatible string mappings or for the device
trees for the boards to have an additional properties giving the machine
IDs that the boards match.  The kernel could then look for multiple DTBs
appended to the image and try to pick one based on ATAGs.
-------------- 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/20130704/ecc19fcd/attachment.sig>

From manjunath.goudar at linaro.org  Thu Jul  4 13:16:26 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Thu,  4 Jul 2013 22:46:26 +0530
Subject: [PATCH 1/2] USB: OHCI: make ohci-ep93xx a separate driver
In-Reply-To: <1372958187-4039-1-git-send-email-manjunath.goudar@linaro.org>
References: <1372958187-4039-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1372958187-4039-2-git-send-email-manjunath.goudar@linaro.org>

Separate the OHCI EP93XX host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org
---
 drivers/usb/host/Kconfig       |    8 ++++
 drivers/usb/host/Makefile      |    1 +
 drivers/usb/host/ohci-ep93xx.c |   84 +++++++++++++++++++---------------------
 drivers/usb/host/ohci-hcd.c    |   19 ---------
 4 files changed, 48 insertions(+), 64 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index bf9a162..35c7001 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -414,6 +414,14 @@ config USB_OHCI_HCD_DA8XX
           Enables support for the on-chip OHCI controller on
           DA8xx/OMAP-L1x chips.
 
+config USB_OHCI_HCD_EP93XX
+	tristate "Support for EP93XX on-chip OHCI USB controller"
+	depends on USB_OHCI_HCD && ARCH_EP93XX
+	default y
+	---help---
+	  Enables support for the on-chip OHCI controller on
+	  EP93XX chips.
+
 config USB_OHCI_HCD_AT91
         tristate  "Support for Atmel on-chip OHCI USB controller"
         depends on USB_OHCI_HCD && ARCH_AT91
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index f8d59371..3fee3ea 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_USB_OHCI_HCD_AT91)	+= ohci-at91.o
 obj-$(CONFIG_USB_OHCI_HCD_S3CXXXX)	+= ohci-s3c2410.o
 obj-$(CONFIG_USB_OHCI_HCD_LPC32XX)	+= ohci-nxp.o
 obj-$(CONFIG_USB_OHCI_HCD_DA8XX)	+= ohci-da8xx.o
+obj-$(CONFIG_USB_OHCI_HCD_EP93XX)	+= ohci-ep93xx.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index f0aaa48..0c2f6df 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -25,8 +25,21 @@
 
 #include <linux/clk.h>
 #include <linux/device.h>
-#include <linux/signal.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/platform_device.h>
+#include <linux/signal.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ohci.h"
+
+#define DRIVER_DESC "OHCI EP93xx driver"
+
+static const char hcd_name[] = "ohci-ep93xx";
+
+static struct hc_driver __read_mostly ohci_ep93xx_hc_driver;
 
 static struct clk *usb_host_clock;
 
@@ -45,6 +58,7 @@ static int usb_hcd_ep93xx_probe(const struct hc_driver *driver,
 {
 	int retval;
 	struct usb_hcd *hcd;
+	struct ohci_hcd *ohci;
 
 	if (pdev->resource[1].flags != IORESOURCE_IRQ) {
 		dev_dbg(&pdev->dev, "resource[1] is not IORESOURCE_IRQ\n");
@@ -79,7 +93,10 @@ static int usb_hcd_ep93xx_probe(const struct hc_driver *driver,
 
 	ep93xx_start_hc(&pdev->dev);
 
-	ohci_hcd_init(hcd_to_ohci(hcd));
+	ohci = hcd_to_ohci(hcd);
+	ohci->next_statechange = jiffies;
+	spin_lock_init(&ohci->lock);
+	INIT_LIST_HEAD(&ohci->pending);
 
 	retval = usb_add_hcd(hcd, pdev->resource[1].start, 0);
 	if (retval == 0)
@@ -107,48 +124,6 @@ static void usb_hcd_ep93xx_remove(struct usb_hcd *hcd,
 	usb_put_hcd(hcd);
 }
 
-static int ohci_ep93xx_start(struct usb_hcd *hcd)
-{
-	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
-	int ret;
-
-	if ((ret = ohci_init(ohci)) < 0)
-		return ret;
-
-	if ((ret = ohci_run(ohci)) < 0) {
-		dev_err(hcd->self.controller, "can't start %s\n",
-			hcd->self.bus_name);
-		ohci_stop(hcd);
-		return ret;
-	}
-
-	return 0;
-}
-
-static struct hc_driver ohci_ep93xx_hc_driver = {
-	.description		= hcd_name,
-	.product_desc		= "EP93xx OHCI",
-	.hcd_priv_size		= sizeof(struct ohci_hcd),
-	.irq			= ohci_irq,
-	.flags			= HCD_USB11 | HCD_MEMORY,
-	.start			= ohci_ep93xx_start,
-	.stop			= ohci_stop,
-	.shutdown		= ohci_shutdown,
-	.urb_enqueue		= ohci_urb_enqueue,
-	.urb_dequeue		= ohci_urb_dequeue,
-	.endpoint_disable	= ohci_endpoint_disable,
-	.get_frame_number	= ohci_get_frame,
-	.hub_status_data	= ohci_hub_status_data,
-	.hub_control		= ohci_hub_control,
-#ifdef CONFIG_PM
-	.bus_suspend		= ohci_bus_suspend,
-	.bus_resume		= ohci_bus_resume,
-#endif
-	.start_port_reset	= ohci_start_port_reset,
-};
-
-extern int usb_disabled(void);
-
 static int ohci_hcd_ep93xx_drv_probe(struct platform_device *pdev)
 {
 	int ret;
@@ -206,7 +181,6 @@ static int ohci_hcd_ep93xx_drv_resume(struct platform_device *pdev)
 }
 #endif
 
-
 static struct platform_driver ohci_hcd_ep93xx_driver = {
 	.probe		= ohci_hcd_ep93xx_drv_probe,
 	.remove		= ohci_hcd_ep93xx_drv_remove,
@@ -221,4 +195,24 @@ static struct platform_driver ohci_hcd_ep93xx_driver = {
 	},
 };
 
+static int __init ohci_ep93xx_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ohci_init_driver(&ohci_ep93xx_hc_driver, NULL);
+	return platform_driver_register(&ohci_hcd_ep93xx_driver);
+}
+module_init(ohci_ep93xx_init);
+
+static void __exit ohci_ep93xx_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_ep93xx_driver);
+}
+module_exit(ohci_ep93xx_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:ep93xx-ohci");
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index d514e11..3f46cff 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1189,11 +1189,6 @@ MODULE_LICENSE ("GPL");
 #define PLATFORM_DRIVER		ohci_hcd_pxa27x_driver
 #endif
 
-#ifdef CONFIG_ARCH_EP93XX
-#include "ohci-ep93xx.c"
-#define EP93XX_PLATFORM_DRIVER	ohci_hcd_ep93xx_driver
-#endif
-
 #ifdef CONFIG_USB_OHCI_HCD_PPC_OF
 #include "ohci-ppc-of.c"
 #define OF_PLATFORM_DRIVER	ohci_hcd_ppc_of_driver
@@ -1284,20 +1279,9 @@ static int __init ohci_hcd_mod_init(void)
 	if (retval < 0)
 		goto error_tmio;
 #endif
-
-#ifdef EP93XX_PLATFORM_DRIVER
-	retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_ep93xx;
-#endif
-
 	return retval;
 
 	/* Error path */
-#ifdef EP93XX_PLATFORM_DRIVER
-	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
- error_ep93xx:
-#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
  error_tmio:
@@ -1335,9 +1319,6 @@ module_init(ohci_hcd_mod_init);
 
 static void __exit ohci_hcd_mod_exit(void)
 {
-#ifdef EP93XX_PLATFORM_DRIVER
-	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
-#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
 #endif
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Thu Jul  4 13:16:27 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Thu,  4 Jul 2013 22:46:27 +0530
Subject: [PATCH 2/2] USB: OHCI: make ohci-pxa27x a separate driver
In-Reply-To: <1372958187-4039-1-git-send-email-manjunath.goudar@linaro.org>
References: <1372958187-4039-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1372958187-4039-3-git-send-email-manjunath.goudar@linaro.org>

Separate the  OHCI pxa27x/pxa3xx host controller driver from
ohci-hcd host code so that it can be built as a separate driver
module. This work is part of enabling multi-platform kernels on
ARM.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: linux-usb at vger.kernel.org
---
 drivers/usb/host/Kconfig       |    8 +++
 drivers/usb/host/Makefile      |    1 +
 drivers/usb/host/ohci-hcd.c    |    5 --
 drivers/usb/host/ohci-pxa27x.c |  154 ++++++++++++++++------------------------
 4 files changed, 72 insertions(+), 96 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 35c7001..f6fefa2 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -422,6 +422,14 @@ config USB_OHCI_HCD_EP93XX
 	  Enables support for the on-chip OHCI controller on
 	  EP93XX chips.
 
+config USB_OHCI_HCD_PXA27X
+	tristate "Support for PXA27X/PXA3XX on-chip OHCI USB controller"
+	depends on USB_OHCI_HCD && ARCH_PXA
+	default y
+	---help---
+	  Enables support for the on-chip OHCI controller on
+	  PXA27X/PXA3XX chips.
+
 config USB_OHCI_HCD_AT91
         tristate  "Support for Atmel on-chip OHCI USB controller"
         depends on USB_OHCI_HCD && ARCH_AT91
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 3fee3ea..8b7fa89 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_USB_OHCI_HCD_S3CXXXX)	+= ohci-s3c2410.o
 obj-$(CONFIG_USB_OHCI_HCD_LPC32XX)	+= ohci-nxp.o
 obj-$(CONFIG_USB_OHCI_HCD_DA8XX)	+= ohci-da8xx.o
 obj-$(CONFIG_USB_OHCI_HCD_EP93XX)	+= ohci-ep93xx.o
+obj-$(CONFIG_USB_OHCI_HCD_PXA27X)	+= ohci-pxa27x.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 3f46cff..f601dde 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1184,11 +1184,6 @@ MODULE_LICENSE ("GPL");
 #define SA1111_DRIVER		ohci_hcd_sa1111_driver
 #endif
 
-#if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx)
-#include "ohci-pxa27x.c"
-#define PLATFORM_DRIVER		ohci_hcd_pxa27x_driver
-#endif
-
 #ifdef CONFIG_USB_OHCI_HCD_PPC_OF
 #include "ohci-ppc-of.c"
 #define OF_PLATFORM_DRIVER	ohci_hcd_ppc_of_driver
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 5fb91f1..791e2b5 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -19,15 +19,26 @@
  * This file is licenced under the GPL.
  */
 
-#include <linux/device.h>
-#include <linux/signal.h>
-#include <linux/platform_device.h>
 #include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/of_platform.h>
 #include <linux/of_gpio.h>
-#include <mach/hardware.h>
 #include <linux/platform_data/usb-ohci-pxa27x.h>
 #include <linux/platform_data/usb-pxa3xx-ulpi.h>
+#include <linux/platform_device.h>
+#include <linux/signal.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/otg.h>
+
+#include <mach/hardware.h>
+
+#include "ohci.h"
+
+#define DRIVER_DESC "OHCI PXA27X driver"
 
 /*
  * UHC: USB Host Controller (OHCI-like) register definitions
@@ -101,11 +112,11 @@
 
 #define PXA_UHC_MAX_PORTNUM    3
 
-struct pxa27x_ohci {
-	/* must be 1st member here for hcd_to_ohci() to work */
-	struct ohci_hcd ohci;
+static const char hcd_name[] = "ohci-pxa27x";
 
-	struct device	*dev;
+static struct hc_driver __read_mostly ohci_pxa27x_hc_driver;
+
+struct pxa27x_ohci {
 	struct clk	*clk;
 	void __iomem	*mmio_base;
 };
@@ -154,8 +165,6 @@ static int pxa27x_ohci_select_pmm(struct pxa27x_ohci *ohci, int mode)
 	return 0;
 }
 
-extern int usb_disabled(void);
-
 /*-------------------------------------------------------------------------*/
 
 static inline void pxa27x_setup_hc(struct pxa27x_ohci *ohci,
@@ -218,6 +227,7 @@ static int pxa27x_start_hc(struct pxa27x_ohci *ohci, struct device *dev)
 	int retval = 0;
 	struct pxaohci_platform_data *inf;
 	uint32_t uhchr;
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
 
 	inf = dev->platform_data;
 
@@ -240,7 +250,7 @@ static int pxa27x_start_hc(struct pxa27x_ohci *ohci, struct device *dev)
 		return retval;
 
 	if (cpu_is_pxa3xx())
-		pxa3xx_u2d_start_hc(&ohci_to_hcd(&ohci->ohci)->self);
+		pxa3xx_u2d_start_hc(&hcd->self);
 
 	uhchr = __raw_readl(ohci->mmio_base + UHCHR) & ~UHCHR_SSE;
 	__raw_writel(uhchr, ohci->mmio_base + UHCHR);
@@ -254,12 +264,13 @@ static int pxa27x_start_hc(struct pxa27x_ohci *ohci, struct device *dev)
 static void pxa27x_stop_hc(struct pxa27x_ohci *ohci, struct device *dev)
 {
 	struct pxaohci_platform_data *inf;
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
 	uint32_t uhccoms;
 
 	inf = dev->platform_data;
 
 	if (cpu_is_pxa3xx())
-		pxa3xx_u2d_stop_hc(&ohci_to_hcd(&ohci->ohci)->self);
+		pxa3xx_u2d_stop_hc(&hcd->self);
 
 	if (inf->exit)
 		inf->exit(dev);
@@ -357,6 +368,7 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver, struct platform_device
 	struct usb_hcd *hcd;
 	struct pxaohci_platform_data *inf;
 	struct pxa27x_ohci *ohci;
+	struct ohci_hcd *pxaohci;
 	struct resource *r;
 	struct clk *usb_clk;
 
@@ -410,7 +422,6 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver, struct platform_device
 
 	/* initialize "struct pxa27x_ohci" */
 	ohci = (struct pxa27x_ohci *)hcd_to_ohci(hcd);
-	ohci->dev = &pdev->dev;
 	ohci->clk = usb_clk;
 	ohci->mmio_base = (void __iomem *)hcd->regs;
 
@@ -425,7 +436,13 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver, struct platform_device
 	if (inf->power_budget)
 		hcd->power_budget = inf->power_budget;
 
-	ohci_hcd_init(hcd_to_ohci(hcd));
+	pxaohci = hcd_to_ohci(hcd);
+	pxaohci->next_statechange = jiffies;
+	spin_lock_init(&pxaohci->lock);
+	INIT_LIST_HEAD(&pxaohci->pending);
+
+	 /* The value of NDP in roothub_a is incorrect on this hardware */
+	pxaohci->num_ports = 3;
 
 	retval = usb_add_hcd(hcd, irq, 0);
 	if (retval == 0)
@@ -471,76 +488,6 @@ void usb_hcd_pxa27x_remove (struct usb_hcd *hcd, struct platform_device *pdev)
 
 /*-------------------------------------------------------------------------*/
 
-static int
-ohci_pxa27x_start (struct usb_hcd *hcd)
-{
-	struct ohci_hcd	*ohci = hcd_to_ohci (hcd);
-	int		ret;
-
-	ohci_dbg (ohci, "ohci_pxa27x_start, ohci:%p", ohci);
-
-	/* The value of NDP in roothub_a is incorrect on this hardware */
-	ohci->num_ports = 3;
-
-	if ((ret = ohci_init(ohci)) < 0)
-		return ret;
-
-	if ((ret = ohci_run (ohci)) < 0) {
-		dev_err(hcd->self.controller, "can't start %s",
-			hcd->self.bus_name);
-		ohci_stop (hcd);
-		return ret;
-	}
-
-	return 0;
-}
-
-/*-------------------------------------------------------------------------*/
-
-static const struct hc_driver ohci_pxa27x_hc_driver = {
-	.description =		hcd_name,
-	.product_desc =		"PXA27x OHCI",
-	.hcd_priv_size =	sizeof(struct pxa27x_ohci),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq =			ohci_irq,
-	.flags =		HCD_USB11 | HCD_MEMORY,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.start =		ohci_pxa27x_start,
-	.stop =			ohci_stop,
-	.shutdown =		ohci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue =		ohci_urb_enqueue,
-	.urb_dequeue =		ohci_urb_dequeue,
-	.endpoint_disable =	ohci_endpoint_disable,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number =	ohci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data =	ohci_hub_status_data,
-	.hub_control =		ohci_hub_control,
-#ifdef  CONFIG_PM
-	.bus_suspend =		ohci_bus_suspend,
-	.bus_resume =		ohci_bus_resume,
-#endif
-	.start_port_reset =	ohci_start_port_reset,
-};
-
-/*-------------------------------------------------------------------------*/
-
 static int ohci_hcd_pxa27x_drv_probe(struct platform_device *pdev)
 {
 	pr_debug ("In ohci_hcd_pxa27x_drv_probe");
@@ -565,11 +512,13 @@ static int ohci_hcd_pxa27x_drv_suspend(struct device *dev)
 	struct usb_hcd *hcd = dev_get_drvdata(dev);
 	struct pxa27x_ohci *ohci = to_pxa27x_ohci(hcd);
 	bool do_wakeup = device_may_wakeup(dev);
+	struct ohci_hcd *pxaohci = hcd_to_ohci(hcd);
 	int ret;
 
-	if (time_before(jiffies, ohci->ohci.next_statechange))
+	if (time_before(jiffies, pxaohci->next_statechange))
 		msleep(5);
-	ohci->ohci.next_statechange = jiffies;
+
+	pxaohci->next_statechange = jiffies;
 
 	ret = ohci_suspend(hcd, do_wakeup);
 	if (ret)
@@ -584,11 +533,13 @@ static int ohci_hcd_pxa27x_drv_resume(struct device *dev)
 	struct usb_hcd *hcd = dev_get_drvdata(dev);
 	struct pxa27x_ohci *ohci = to_pxa27x_ohci(hcd);
 	struct pxaohci_platform_data *inf = dev->platform_data;
+	struct ohci_hcd *pxaohci = hcd_to_ohci(hcd);
 	int status;
 
-	if (time_before(jiffies, ohci->ohci.next_statechange))
+	if (time_before(jiffies, pxaohci->next_statechange))
 		msleep(5);
-	ohci->ohci.next_statechange = jiffies;
+
+	pxaohci->next_statechange = jiffies;
 
 	if ((status = pxa27x_start_hc(ohci, dev)) < 0)
 		return status;
@@ -606,9 +557,6 @@ static const struct dev_pm_ops ohci_hcd_pxa27x_pm_ops = {
 };
 #endif
 
-/* work with hotplug and coldplug */
-MODULE_ALIAS("platform:pxa27x-ohci");
-
 static struct platform_driver ohci_hcd_pxa27x_driver = {
 	.probe		= ohci_hcd_pxa27x_drv_probe,
 	.remove		= ohci_hcd_pxa27x_drv_remove,
@@ -623,3 +571,27 @@ static struct platform_driver ohci_hcd_pxa27x_driver = {
 	},
 };
 
+static const struct ohci_driver_overrides pxa27x_overrides __initconst = {
+	.extra_priv_size =      sizeof(struct pxa27x_ohci),
+};
+
+static int __init ohci_pxa27x_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+	ohci_init_driver(&ohci_pxa27x_hc_driver, &pxa27x_overrides);
+	return platform_driver_register(&ohci_hcd_pxa27x_driver);
+}
+module_init(ohci_pxa27x_init);
+
+static void __exit ohci_pxa27x_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_pxa27x_driver);
+}
+module_exit(ohci_pxa27x_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:pxa27x-ohci");
-- 
1.7.9.5



From aaro.koskinen at iki.fi  Thu Jul  4 13:19:39 2013
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Thu, 4 Jul 2013 20:19:39 +0300
Subject: [PATCH] N900: add device tree
In-Reply-To: <20130701211753.GC15318@amd.pavel.ucw.cz>
References: <20130613141001.GF8164@atomide.com>
 <20130613142809.GA3775@amd.pavel.ucw.cz>
 <20130613145724.GH8164@atomide.com>
 <20130613155240.GB3775@amd.pavel.ucw.cz>
 <20130613161418.GJ8164@atomide.com>
 <20130613230808.GA14876@amd.pavel.ucw.cz>
 <20130614055629.GM8164@atomide.com>
 <20130614212816.GA31768@atrey.karlin.mff.cuni.cz>
 <20130617111031.GQ20992@atomide.com>
 <20130701211753.GC15318@amd.pavel.ucw.cz>
Message-ID: <20130704171939.GA27374@blackmetal.musicnaut.iki.fi>

On Mon, Jul 01, 2013 at 11:17:54PM +0200, Pavel Machek wrote:
> This adds device tree with neccessary support to boot with functional
> video (on both emulator and real N900 device).

Is this really correct? You have commented out the USB, so there is no
way for a developer to interact with the device.

Some minor issue too:

> +/*
> + * Copyright (C) 2013 Pavel Machek <pavel at ucw.cz>
> + * Copyright 2013 Aaro Koskinen <aaro.koskinen at iki.fi>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 (or later) as
> + * published by the Free Software Foundation.

Should be just GPLv2.

A.


From manjunath.goudar at linaro.org  Thu Jul  4 13:16:25 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Thu,  4 Jul 2013 22:46:25 +0530
Subject: [PATCH 0/2] USB: OHCI: more bus glues as separate modules
Message-ID: <1372958187-4039-1-git-send-email-manjunath.goudar@linaro.org>

These patches are for separating the SOC On-Chip ohci host controller
from ohci-hcd host code into its own driver module.
This work is part of enabling multi-platform kernels on ARM.

Manjunath Goudar (2):
  USB: OHCI: make ohci-ep93xx a separate driver
  USB: OHCI: make ohci-pxa27x a separate driver

 drivers/usb/host/Kconfig       |   16 +++++
 drivers/usb/host/Makefile      |    2 +
 drivers/usb/host/ohci-ep93xx.c |   84 ++++++++++------------
 drivers/usb/host/ohci-hcd.c    |   24 -------
 drivers/usb/host/ohci-pxa27x.c |  154 ++++++++++++++++------------------------
 5 files changed, 120 insertions(+), 160 deletions(-)

-- 
1.7.9.5



From nico at fluxnic.net  Thu Jul  4 13:28:54 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Thu, 04 Jul 2013 13:28:54 -0400 (EDT)
Subject: Appended DTB files for multi-machine kernels
In-Reply-To: <51D5A938.30607@gmail.com>
References: <51D5A938.30607@gmail.com>
Message-ID: <alpine.LFD.2.03.1307041322070.18597@syhkavp.arg>

On Thu, 4 Jul 2013, Daniel Mack wrote:

> Hi,
> 
> I'm facing a problem with a transition from legacy board-file driven ARM
> machines to DTB, and I'm under the impression that a solution for it
> could be of broader interest.
> 
> In short, devices that have been deployed in quantities come in three
> hardware variants, which all boot with a unique machine-id. We ship
> kernel images that have board support for all three machine types, and
> do minor fixups to platform data of some drivers at runtime, depending
> on the board revision number (passed in via ATAGs).
> 
> The built-in support for attaching a DTB to the zImage does not suffice
> here, because we have one image for all models, and also, we couldn't do
> a 'per-board-revision' selection that way either.
> 
> Unless I missed some recent discussion, this case is not easy to handle.
> Yes, I know that these kind of things should be handled by a
> next-generation bootloader, but in our case, we want to avoid a loader
> update of already shipped hardware by all means.
> 
> As a solution, I'm thinking of a small framework that could for example
> work as follows.
> 
> a) A small mechanism allows storing multiple DTB binary files inside the
> kernel binary at compile time, and a simple function can extract them
> again by name at runtime (something like what the firmware framework
> does, but I don't know if that one can be used at such an early stage in
> the boot process).
> 
> b) A DT_MACHINE_START-like macro takes both the machine ID and the name
> of a DTB file that is compiled in. When matched, generic functions would
> load the given file, populate the device tree and then conduct a generic
> DT boot for the specified platform.
> 
> c) Allow users to open-code the DTB lookup depending on whatever kind of
> runtime information (be it the board_revision or anything else).
> 
> 
> Of course, everything has to be an opt-in that stubs itself out at zero
> costs if not needed.
> 
> 
> I'm open to opinion and sugesstions :)

What you describe above more or less fits the definition of what I 
called the "impedance matcher".  However it doesn't need to be part of 
the kernel at all.  But you should make it into a separate binary.

Please have a look at the bottom of this post for a more comprehensive 
description: http://article.gmane.org/gmane.linux.ports.arm.kernel/242929


Nicolas


From jason at lakedaemon.net  Thu Jul  4 13:33:03 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 4 Jul 2013 13:33:03 -0400
Subject: [RFC] Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130704155951.268ebada@skate>
References: <20130702151407.01680d21@skate>
 <20130702133337.GA17110@titan.lakedaemon.net>
 <20130702153825.139a93a5@skate>
 <20130702134421.GC17110@titan.lakedaemon.net>
 <87obakho6d.fsf@natisbad.org>
 <20130702174111.GF17110@titan.lakedaemon.net>
 <87y59ows4n.fsf@natisbad.org> <20130702220936.GC10215@1wt.eu>
 <20130702232311.GA3949@localhost> <20130704155951.268ebada@skate>
Message-ID: <20130704173303.GA2569@titan.lakedaemon.net>

On Thu, Jul 04, 2013 at 03:59:51PM +0200, Thomas Petazzoni wrote:
> Hello guys,
> 
> On Tue, 2 Jul 2013 20:23:12 -0300, Ezequiel Garcia wrote:
> 
> > > Yes and indeed I must say that when I read the driver I found some
> > > similarities with pxa3xx, though it was done differently. I initially
> > > wanted to try to merge them but of course without the spec it's a huge
> > > waste of time, especially considering that this is still in the roadmap
> > > of the Free Electrons guys even though low priority.
> > > 
> > 
> > I wish I could say I'm going to work on this soon but, as Thomas said,
> > we have no idea when/if NAND will be prioritized.
> 
> We've got some news. NAND is back into the list of priorities, Ezequiel
> should restart working on NAND support relatively soon.

Whew!  Thanks for addressing this so quickly Thomas!  Please extend our
thanks to the folks at Marvell as well.

thx,

Jason.


From paul at pwsan.com  Thu Jul  4 13:39:48 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Thu, 4 Jul 2013 17:39:48 +0000 (UTC)
Subject: OMAP baseline test results for v3.10-rc7
In-Reply-To: <alpine.DEB.2.02.1307041650170.6258@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307011946180.4358@utopia.booyaka.com>
 <20130701204236.GA805@arwen.pp.htv.fi>
 <alpine.DEB.2.02.1307041650170.6258@utopia.booyaka.com>
Message-ID: <alpine.DEB.2.02.1307041738550.6258@utopia.booyaka.com>

On Thu, 4 Jul 2013, Paul Walmsley wrote:

> So that's good, will switch to am335x-bone.dtb for the testing restate 
> jobs to be run for BeagleBone-white, and let's see what previous kernels 
> it boots with now...

Sorry, this was unclear.  To rephrase, I will add 
BeagleBone-black boot retest runs, using am335x-bone.dtb, to the testing 
restate jobs that were planned for BeagleBone-white.


- Paul


From balbi at ti.com  Thu Jul  4 13:41:27 2013
From: balbi at ti.com (Felipe Balbi)
Date: Thu, 4 Jul 2013 20:41:27 +0300
Subject: OMAP baseline test results for v3.10-rc7
In-Reply-To: <alpine.DEB.2.02.1307041650170.6258@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307011946180.4358@utopia.booyaka.com>
 <20130701204236.GA805@arwen.pp.htv.fi>
 <alpine.DEB.2.02.1307041650170.6258@utopia.booyaka.com>
Message-ID: <20130704174127.GC6687@arwen.pp.htv.fi>

On Thu, Jul 04, 2013 at 05:11:33PM +0000, Paul Walmsley wrote:
> Hi
> 
> On Mon, 1 Jul 2013, Felipe Balbi wrote:
> 
> > On Mon, Jul 01, 2013 at 07:48:50PM +0000, Paul Walmsley wrote:
> > > Boot to userspace:
> > >     FAIL ( 2/12): 37xxevm, am335xbonelt
> > 
> > <quoting part of [1]>
> > | U-Boot# tftp 0x82000000 am335x-boneblack.dtb
> > | link up on port 0, speed 100, full duplex
> > | Using cpsw device
> > | TFTP from server 192.168.57.1; our IP address is 192.168.57.138
> > | Filename 'am335x-boneblack.dtb'.
> > 
> > Where are you taking am335x-boneblack.dtb from ? It's not in mainline
> > v3.10-rc7 kernel:
> 
> As mentioned in my earlier reply:
> 
> http://www.spinics.net/lists/arm-kernel/msg255055.html
> 
> my earlier test boots were with the am335x-boneblack.dtb from the 
> ti-linux-3.8.y tree from Vaibhav's github, since that was the only DTB 
> that I was able to get any kernel to boot with.
> 
> The am33xx_only/appended DTB issues don't apply to this board since it's 
> booted with detached DTB and omap2plus_defconfig.
> 
> Anyway, just retried it with the mainline am335x-bone.dtb file with v3.10, 
> and the board comes up now.  So that's good, will switch to 
> am335x-bone.dtb for the testing restate jobs to be run for 
> BeagleBone-white, and let's see what previous kernels it boots with now...

alright

-- 
balbi
-------------- 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/20130704/e36ba507/attachment.sig>

From zonque at gmail.com  Thu Jul  4 13:57:53 2013
From: zonque at gmail.com (Daniel Mack)
Date: Thu, 04 Jul 2013 19:57:53 +0200
Subject: Appended DTB files for multi-machine kernels
In-Reply-To: <alpine.LFD.2.03.1307041322070.18597@syhkavp.arg>
References: <51D5A938.30607@gmail.com>
 <alpine.LFD.2.03.1307041322070.18597@syhkavp.arg>
Message-ID: <51D5B7A1.60609@gmail.com>

Hi Nicolas,

On 04.07.2013 19:28, Nicolas Pitre wrote:
> On Thu, 4 Jul 2013, Daniel Mack wrote:
>> I'm open to opinion and sugesstions :)
> 
> What you describe above more or less fits the definition of what I 
> called the "impedance matcher".  However it doesn't need to be part of 
> the kernel at all.  But you should make it into a separate binary.
> 
> Please have a look at the bottom of this post for a more comprehensive 
> description: http://article.gmane.org/gmane.linux.ports.arm.kernel/242929

Thanks for the link. Interesting read indeed.

The only thing I'm pondering about is that we already have generic
loader code in Linux and a build system that supports a wide range of
platforms. I don't know whether it's worth opening that can of worms
again and re-implement all details about load addresses, compiler flags,
device-tree parsing code yet once again. At least in terms of LOCs, we
would certainly be better off doing it inside the kernel.

But I generally second your opinion about pushing vendors to do it
right, so I might give that approach a shot soon; there is no code yet
anywhere I take it?


Thanks,
Daniel



From js at sig21.net  Thu Jul  4 14:06:56 2013
From: js at sig21.net (Johannes Stezenbach)
Date: Thu, 4 Jul 2013 20:06:56 +0200
Subject: SPI: DUAL/QUAD support
In-Reply-To: <20130704143645.GA27646@sirena.org.uk>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704143645.GA27646@sirena.org.uk>
Message-ID: <20130704180656.GA1974@sig21.net>

On Thu, Jul 04, 2013 at 03:36:45PM +0100, Mark Brown wrote:
> On Thu, Jul 04, 2013 at 07:36:48PM +0800, yuhang wang wrote:
> > +Description
> > +----------------------
> > +DUAL/QUAD means spi can transfer in 2bits/4bits at the same time.
> > +These spi controllers provide 8 data lines(4-tx and 4-rx). User can
> > +choose tranfer mode(SINGLE/DUAL/QUAD) by setting the certain register.
> > +Though SPI is a serial interface, some spi controllers can support
> > +transmitting and receiving in DUAL and QUAD modes aimed to improve
> > +the performance. Also as spi slave lots of flashes do support this attribute,
> > +such as serial-norflash in spansion company.
> 
> OK, so all this is about is devices that have extra data lines.  Please
> don't invent terms like "DUAL" and "QUAD", it makes things much less
> clear.  Just describe it as support for multiple data lines.

Flash data sheets use the terms Dual and Quad I/O Mode,
e.g. for MX25L25635E
http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/6F878CF760C559BD482576E00022E6CC/?OpenDocument&EPN=MX25L25635E

> > +struct spi_transfer {
> > ++       u8     bitwidth;
> > ++#define        SPI_BITWIDTH_SINGLE     0x01; /* 1bit transfer */
> > ++#define        SPI_BITWIDTH_DUAL       0x02; /* 2bits transfer */
> > ++#define        SPI_BITWIDTH_QUAD       0x03; /* 4bits transfer */
> 
> Calling this "bandwidth" is really unclear - I would expect a bandwidth
> to be expressed in bits per second or similar.  This would be much
> clearer if it was just the number of data signals.

"bitwidth" != "bandwidth", but maybe the name could be improved,
how about xfer_width?  The mmc susbsysem has something similar
and calls it bus_width.

> > +       t[0].rx_buf = buf;
> > +       t[0].len = len;
> > +       t[0].bitwidth = spi->rx_bitwidth/spi->tx_bitwidth;
> > +       spi_message_add_tail(&t[0], &m);
> 
> This interface won't work for bidirectional transfers with asymmetric
> numbers of data lines - we need separate fields for rx and rx.

I'm not aware that bidirectional transfers are supported in
dual or quad IO mode.  I think only flash supports it and
uses all available IO lines as either input (flash write
command) or output (flash read command).  I.e. for MX25L25635E flash
it means at least the command, but usually also the address,
are transferred in single IO mode, only then do the flash
and controller switch to parallel IO for the data transfer.


Johannes


From paul at pwsan.com  Thu Jul  4 14:12:16 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Thu, 4 Jul 2013 18:12:16 +0000 (UTC)
Subject: OMAP baseline test results for v3.10-rc6
In-Reply-To: <alpine.DEB.2.02.1307031944580.9618@utopia.booyaka.com>
References: <alpine.DEB.2.02.1306170521020.9909@utopia.booyaka.com>
 <20130625160243.GE22312@arwen.pp.htv.fi>
 <alpine.DEB.2.02.1306251746060.14373@utopia.booyaka.com>
 <51C9F0A8.1050607@ti.com> <87fvw6t136.fsf@linaro.org>
 <79CD15C6BA57404B839C016229A409A83ECC952D@DBDE04.ent.ti.com>
 <51CAEB33.5010101@ti.com>
 <alpine.DEB.2.02.1306261722520.6135@utopia.booyaka.com>
 <51CBBCD8.5030600@ti.com>
 <alpine.DEB.2.02.1306281844090.8767@utopia.booyaka.com>
 <alpine.DEB.2.02.1307010211580.3741@utopia.booyaka.com>
 <79CD15C6BA57404B839C016229A409A83ECCC435@DBDE04.ent.ti.com>
 <51D2E096.5040700@ti.com>
 <alpine.DEB.2.02.1307031944580.9618@utopia.booyaka.com>
Message-ID: <alpine.DEB.2.02.1307041810410.6258@utopia.booyaka.com>

On Wed, 3 Jul 2013, Paul Walmsley wrote:

> As far as Lokesh's patch goes: it doesn't make sense to me to remove a 
> file during 'make clean' that the build process doesn't create.  So while 
> I understand the motivation for the patch, and don't mind if upstream 
> takes it, I personally wouldn't care to ack it.

Incidentally, if there's any patch that would improve the current 
situation with appended DTBs by going upstream, it would be a patch like 
Grant's "HACK" patch to add appended DTB building into the kernel build 
system.  Maybe folks can push to something similar to that one upstream?


- Paul


From nico at fluxnic.net  Thu Jul  4 14:27:41 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Thu, 04 Jul 2013 14:27:41 -0400 (EDT)
Subject: Appended DTB files for multi-machine kernels
In-Reply-To: <51D5B7A1.60609@gmail.com>
References: <51D5A938.30607@gmail.com>
 <alpine.LFD.2.03.1307041322070.18597@syhkavp.arg> <51D5B7A1.60609@gmail.com>
Message-ID: <alpine.LFD.2.03.1307041419070.18597@syhkavp.arg>

On Thu, 4 Jul 2013, Daniel Mack wrote:

> Hi Nicolas,
> 
> On 04.07.2013 19:28, Nicolas Pitre wrote:
> > On Thu, 4 Jul 2013, Daniel Mack wrote:
> >> I'm open to opinion and sugesstions :)
> > 
> > What you describe above more or less fits the definition of what I 
> > called the "impedance matcher".  However it doesn't need to be part of 
> > the kernel at all.  But you should make it into a separate binary.
> > 
> > Please have a look at the bottom of this post for a more comprehensive 
> > description: http://article.gmane.org/gmane.linux.ports.arm.kernel/242929
> 
> Thanks for the link. Interesting read indeed.
> 
> The only thing I'm pondering about is that we already have generic
> loader code in Linux and a build system that supports a wide range of
> platforms. I don't know whether it's worth opening that can of worms
> again and re-implement all details about load addresses, compiler flags,
> device-tree parsing code yet once again. At least in terms of LOCs, we
> would certainly be better off doing it inside the kernel.

That is still code with relatively low value that has to be carried and 
maintained.

And if you do it for your own device outside of the kernel then you can 
literally hack it the way you want quickly and forget about it once it 
works.  Since this is useful for legacy setups only, you do not have to 
care about maintaining it in the future.

> But I generally second your opinion about pushing vendors to do it
> right, so I might give that approach a shot soon; there is no code yet
> anywhere I take it?

Not that I'm aware of, besides parts of libfdt and atags_to_fdt.c from 
the kernel tree that can be lifted and modified according to your needs.  
I don't imagine you'd need much more than that anyway.


Nicolas


From dirk.behme at gmail.com  Thu Jul  4 14:36:05 2013
From: dirk.behme at gmail.com (Dirk Behme)
Date: Thu, 04 Jul 2013 20:36:05 +0200
Subject: Appended DTB files for multi-machine kernels
In-Reply-To: <51D5A938.30607@gmail.com>
References: <51D5A938.30607@gmail.com>
Message-ID: <51D5C095.4070909@gmail.com>

Am 04.07.2013 18:56, schrieb Daniel Mack:
> Hi,
>
> I'm facing a problem with a transition from legacy board-file driven ARM
> machines to DTB, and I'm under the impression that a solution for it
> could be of broader interest.
>
> In short, devices that have been deployed in quantities come in three
> hardware variants, which all boot with a unique machine-id. We ship
> kernel images that have board support for all three machine types, and
> do minor fixups to platform data of some drivers at runtime, depending
> on the board revision number (passed in via ATAGs).
>
> The built-in support for attaching a DTB to the zImage does not suffice
> here, because we have one image for all models, and also, we couldn't do
> a 'per-board-revision' selection that way either.
>
> Unless I missed some recent discussion, this case is not easy to handle.
> Yes, I know that these kind of things should be handled by a
> next-generation bootloader, but in our case, we want to avoid a loader
> update of already shipped hardware by all means.
>
> As a solution, I'm thinking of a small framework that could for example
> work as follows.
>
> a) A small mechanism allows storing multiple DTB binary files inside the
> kernel binary at compile time, and a simple function can extract them
> again by name at runtime (something like what the firmware framework
> does, but I don't know if that one can be used at such an early stage in
> the boot process).
>
> b) A DT_MACHINE_START-like macro takes both the machine ID and the name
> of a DTB file that is compiled in. When matched, generic functions would
> load the given file, populate the device tree and then conduct a generic
> DT boot for the specified platform.
>
> c) Allow users to open-code the DTB lookup depending on whatever kind of
> runtime information (be it the board_revision or anything else).
>
>
> Of course, everything has to be an opt-in that stubs itself out at zero
> costs if not needed.
>
>
> I'm open to opinion and sugesstions :)

Depending on how different the board support for all your three 
machine types is, there might be an (of course unimplemented) option

d) have only one DTB file which contains all the information for your 
three machine types and then have a mechanism which selects 
("activates") the entries valid for the board you boot based on some 
external information, e.g. the machine ID. I.e. you have one DTB file 
which contains alternative entries for the different boards. And which 
entry is used/activated is selected at (early) kernel runtime by the 
machine ID.

What I'm thinking about here is an extended version of the device tree 
overlays used (invented?) by the Beagle board community. They have a 
base device tree file and for their add on boards (capes) they load 
device tree overlay files based on an EEPROM ID read.

http://elinux.org/BeagleBone_and_the_3.8_Kernel#Cape_Manager_and_Device_Tree_Overlays

With this, they extend the device tree at runtime based on the 
attached extension boards.

Going one step further, having the alternative plugin/overlay 
definitions already in the initial DTB file and being able to 
select/activate single plugin/overlay definitions already in the early 
boot stage should give a general mechanism to support several, similar 
boards with slightly different configurations with one DTB.

Best regards

Dirk



From fabio.estevam at freescale.com  Thu Jul  4 14:55:06 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Thu, 4 Jul 2013 15:55:06 -0300
Subject: [PATCH] ARM: dts: imx6dl-wandboard: Add audio support
Message-ID: <1372964106-27928-1-git-send-email-fabio.estevam@freescale.com>

Wandboard has a sgtl5000 codec. 

Add audio support.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/imx6dl-wandboard.dts | 73 ++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/imx6dl.dtsi          |  7 ++++
 2 files changed, 80 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts b/arch/arm/boot/dts/imx6dl-wandboard.dts
index bfc59c3..ab6a053 100644
--- a/arch/arm/boot/dts/imx6dl-wandboard.dts
+++ b/arch/arm/boot/dts/imx6dl-wandboard.dts
@@ -18,6 +18,74 @@
 	memory {
 		reg = <0x10000000 0x40000000>;
 	};
+
+	regulators {
+		compatible = "simple-bus";
+
+		reg_2p5v: 2p5v {
+			compatible = "regulator-fixed";
+			regulator-name = "2P5V";
+			regulator-min-microvolt = <2500000>;
+			regulator-max-microvolt = <2500000>;
+			regulator-always-on;
+		};
+
+		reg_3p3v: 3p3v {
+			compatible = "regulator-fixed";
+			regulator-name = "3P3V";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
+	};
+
+	sound {
+		compatible = "fsl,imx6dl-wandboard-sgtl5000",
+			     "fsl,imx-audio-sgtl5000";
+		model = "imx6dl-wandboard-sgtl5000";
+		ssi-controller = <&ssi1>;
+		audio-codec = <&codec>;
+		audio-routing =
+			"MIC_IN", "Mic Jack",
+			"Mic Jack", "Mic Bias",
+			"Headphone Jack", "HP_OUT";
+		mux-int-port = <1>;
+		mux-ext-port = <3>;
+	};
+};
+
+&audmux {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_audmux_2>;
+	status = "okay";
+};
+
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2_2>;
+	status = "okay";
+
+	codec: sgtl5000 at 0a {
+		compatible = "fsl,sgtl5000";
+		reg = <0x0a>;
+		clocks = <&clks 169>;
+		VDDA-supply = <&reg_2p5v>;
+		VDDIO-supply = <&reg_3p3v>;
+	};
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	hog {
+		pinctrl_hog: hoggrp {
+			fsl,pins = <
+				MX6DL_PAD_GPIO_0__CCM_CLKO1    0x130b0
+			>;
+		};
+	};
 };
 
 &fec {
@@ -27,6 +95,11 @@
 	status = "okay";
 };
 
+&ssi1 {
+	fsl,mode = "i2s-slave";
+	status = "okay";
+};
+
 &uart1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart1_1>;
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 2b5628d..4505109 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -196,6 +196,13 @@
 							MX6DL_PAD_EIM_D16__I2C2_SDA 0x4001b8b1
 						>;
 					};
+
+					pinctrl_i2c2_2: i2c2grp-2 {
+						fsl,pins = <
+							MX6DL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+							MX6DL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+						>;
+					};
 				};
 
 				i2c3 {
-- 
1.8.1.2




From broonie at kernel.org  Thu Jul  4 15:12:16 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 4 Jul 2013 20:12:16 +0100
Subject: SPI: DUAL/QUAD support
In-Reply-To: <20130704180656.GA1974@sig21.net>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704143645.GA27646@sirena.org.uk>
 <20130704180656.GA1974@sig21.net>
Message-ID: <20130704191216.GK27646@sirena.org.uk>

On Thu, Jul 04, 2013 at 08:06:56PM +0200, Johannes Stezenbach wrote:
> On Thu, Jul 04, 2013 at 03:36:45PM +0100, Mark Brown wrote:

> > OK, so all this is about is devices that have extra data lines.  Please
> > don't invent terms like "DUAL" and "QUAD", it makes things much less
> > clear.  Just describe it as support for multiple data lines.

> Flash data sheets use the terms Dual and Quad I/O Mode,
> e.g. for MX25L25635E
> http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/6F878CF760C559BD482576E00022E6CC/?OpenDocument&EPN=MX25L25635E

OK, but this is not a flash specific feature but rather something at the
SPI level and even with flash are they typically written in all caps?
This really needs to be described at the SPI level for the SPI subsystem,
not in terms of the specific application.

> > Calling this "bandwidth" is really unclear - I would expect a bandwidth
> > to be expressed in bits per second or similar.  This would be much
> > clearer if it was just the number of data signals.

> "bitwidth" != "bandwidth", but maybe the name could be improved,
> how about xfer_width?  The mmc susbsysem has something similar
> and calls it bus_width.

Bus width is better but I think half the issue here is the use of
"width" and the fact that this isn't being done separately for RX and
TX, it's really not clear what's being talked about.  xfer_width sounds
to me like it's something to do with the word size so I don't think
that's a good idea.  n_mosi and n_miso perhaps?

> > > +       t[0].rx_buf = buf;
> > > +       t[0].len = len;
> > > +       t[0].bitwidth = spi->rx_bitwidth/spi->tx_bitwidth;
> > > +       spi_message_add_tail(&t[0], &m);

> > This interface won't work for bidirectional transfers with asymmetric
> > numbers of data lines - we need separate fields for rx and rx.

> I'm not aware that bidirectional transfers are supported in
> dual or quad IO mode.  I think only flash supports it and

As far as I can tell this is just because you guys are only thinking in
terms of flash chips here - I can't believe that only flash manufacturers
came up with the idea of adding extra data signals to SPI, it's not that
big a leap (and MMC obviously has some overlap here...).  If nothing
else I'd expect some FPGAs would use this, and I wouldn't be surprised
if there were DSPs that could use this.
-------------- 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/20130704/6b0c5352/attachment.sig>

From stern at rowland.harvard.edu  Thu Jul  4 16:16:11 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Thu, 4 Jul 2013 16:16:11 -0400 (EDT)
Subject: [PATCH 1/2] USB: OHCI: make ohci-ep93xx a separate driver
In-Reply-To: <1372958187-4039-2-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <Pine.LNX.4.44L0.1307041615150.26847-100000@netrider.rowland.org>

On Thu, 4 Jul 2013, Manjunath Goudar wrote:

> Separate the OHCI EP93XX host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM.

> @@ -79,7 +93,10 @@ static int usb_hcd_ep93xx_probe(const struct hc_driver *driver,
>  
>  	ep93xx_start_hc(&pdev->dev);
>  
> -	ohci_hcd_init(hcd_to_ohci(hcd));
> +	ohci = hcd_to_ohci(hcd);
> +	ohci->next_statechange = jiffies;
> +	spin_lock_init(&ohci->lock);
> +	INIT_LIST_HEAD(&ohci->pending);
>  
>  	retval = usb_add_hcd(hcd, pdev->resource[1].start, 0);
>  	if (retval == 0)

Why did you add these lines?

Alan Stern



From pavel at ucw.cz  Thu Jul  4 16:21:45 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Thu, 4 Jul 2013 22:21:45 +0200
Subject: [PATCH] N900: add device tree
In-Reply-To: <20130704171939.GA27374@blackmetal.musicnaut.iki.fi>
References: <20130613142809.GA3775@amd.pavel.ucw.cz>
 <20130613145724.GH8164@atomide.com>
 <20130613155240.GB3775@amd.pavel.ucw.cz>
 <20130613161418.GJ8164@atomide.com>
 <20130613230808.GA14876@amd.pavel.ucw.cz>
 <20130614055629.GM8164@atomide.com>
 <20130614212816.GA31768@atrey.karlin.mff.cuni.cz>
 <20130617111031.GQ20992@atomide.com>
 <20130701211753.GC15318@amd.pavel.ucw.cz>
 <20130704171939.GA27374@blackmetal.musicnaut.iki.fi>
Message-ID: <20130704202145.GB10752@amd.pavel.ucw.cz>

Hi!

> > This adds device tree with neccessary support to boot with functional
> > video (on both emulator and real N900 device).
> 
> Is this really correct? You have commented out the USB, so there is no
> way for a developer to interact with the device.

Well... I do not have USB & SDcard set up, so my testing was "does it
show failed to mount root message on screen". 

Now, if I do quick test of enabling it on 3.9, I get:

  DTC     arch/arm/boot/dts/omap3-n900.dtb
Error: arch/arm/boot/dts/omap3-n900.dts:92.2-3 label or path,
'usb_otg_hs', not found
FATAL ERROR: Syntax error parsing input tree
make[1]: *** [arch/arm/boot/dts/omap3-n900.dtb] Error 1
make: *** [dtbs] Error 2

. If you could test the patches with the USB support uncommented, that
would be very good...

Thanks,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From aaro.koskinen at iki.fi  Thu Jul  4 16:32:56 2013
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Thu, 4 Jul 2013 23:32:56 +0300
Subject: [PATCH] N900: add device tree
In-Reply-To: <20130704202145.GB10752@amd.pavel.ucw.cz>
References: <20130613145724.GH8164@atomide.com>
 <20130613155240.GB3775@amd.pavel.ucw.cz>
 <20130613161418.GJ8164@atomide.com>
 <20130613230808.GA14876@amd.pavel.ucw.cz>
 <20130614055629.GM8164@atomide.com>
 <20130614212816.GA31768@atrey.karlin.mff.cuni.cz>
 <20130617111031.GQ20992@atomide.com>
 <20130701211753.GC15318@amd.pavel.ucw.cz>
 <20130704171939.GA27374@blackmetal.musicnaut.iki.fi>
 <20130704202145.GB10752@amd.pavel.ucw.cz>
Message-ID: <20130704203256.GB27374@blackmetal.musicnaut.iki.fi>

Hi,

On Thu, Jul 04, 2013 at 10:21:45PM +0200, Pavel Machek wrote:
> > > This adds device tree with neccessary support to boot with functional
> > > video (on both emulator and real N900 device).
> > 
> > Is this really correct? You have commented out the USB, so there is no
> > way for a developer to interact with the device.
> 
> Well... I do not have USB & SDcard set up, so my testing was "does it
> show failed to mount root message on screen". 
> 
> Now, if I do quick test of enabling it on 3.9, I get:
> 
>   DTC     arch/arm/boot/dts/omap3-n900.dtb
> Error: arch/arm/boot/dts/omap3-n900.dts:92.2-3 label or path,
> 'usb_otg_hs', not found
> FATAL ERROR: Syntax error parsing input tree
> make[1]: *** [arch/arm/boot/dts/omap3-n900.dtb] Error 1
> make: *** [dtbs] Error 2

You need 3.10. It was added in ad871c10b55654910ba97af00a00e65725da5e40
(ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+ boards).

3.9 is very old. :-)

> If you could test the patches with the USB support uncommented, that
> would be very good...

I can do that, but not before next week.

A.


From stern at rowland.harvard.edu  Thu Jul  4 16:36:46 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Thu, 4 Jul 2013 16:36:46 -0400 (EDT)
Subject: [PATCH 2/2] USB: OHCI: make ohci-pxa27x a separate driver
In-Reply-To: <1372958187-4039-3-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <Pine.LNX.4.44L0.1307041633370.26847-100000@netrider.rowland.org>

On Thu, 4 Jul 2013, Manjunath Goudar wrote:

> Separate the  OHCI pxa27x/pxa3xx host controller driver from
> ohci-hcd host code so that it can be built as a separate driver
> module. This work is part of enabling multi-platform kernels on
> ARM.

> +config USB_OHCI_HCD_PXA27X
> +	tristate "Support for PXA27X/PXA3XX on-chip OHCI USB controller"
> +	depends on USB_OHCI_HCD && ARCH_PXA

Shouldn't the ARCH_PXA part be the same as ...

> @@ -1184,11 +1184,6 @@ MODULE_LICENSE ("GPL");
>  #define SA1111_DRIVER		ohci_hcd_sa1111_driver
>  #endif
>  
> -#if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx)

... this?

> diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
> index 5fb91f1..791e2b5 100644
> --- a/drivers/usb/host/ohci-pxa27x.c
> +++ b/drivers/usb/host/ohci-pxa27x.c

Several aspects of this are strange.  For example, consider how you 
used the private part of the ohci_hcd structure and how the variable 
names are inconsistent with the other OHCI glue drivers.

Alan Stern



From coelho at ti.com  Thu Jul  4 16:45:27 2013
From: coelho at ti.com (Luciano Coelho)
Date: Thu, 4 Jul 2013 23:45:27 +0300
Subject: [PATCH RESEND] clk: export __clk_get_flags for modular clock
 providers
In-Reply-To: <1366009186-32199-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1366009186-32199-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <51D5DEE7.2070400@ti.com>

Hi,

On 04/15/2013 09:59 AM, Sebastian Hesselbarth wrote:
> The common clock api provides some helpers for clk-providers but does
> not export these helpers. This hinders clk-providers to be built as modules.
> This patch adds __clk_get_flags() to the list of exported symbols.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
> Cc: Mike Turquette <mturquette at linaro.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>   drivers/clk/clk.c |    1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index ed87b24..3e478b8 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -450,6 +450,7 @@ unsigned long __clk_get_flags(struct clk *clk)
>   {
>   	return !clk ? 0 : clk->flags;
>   }
> +EXPORT_SYMBOL_GPL(__clk_get_flags);
>
>   bool __clk_is_enabled(struct clk *clk)
>   {
>

I think this got merged slightly wrong.  The EXPORT_SYMBOL_GPL macro 
came under clk_unprepare_unused_subtree() instead of under 
__clk_get_flags():


Of course this is not that important, but it's a bit confusing when you 
look at the code.

--
Cheers,
Luca.


From coelho at ti.com  Thu Jul  4 17:05:12 2013
From: coelho at ti.com (Luciano Coelho)
Date: Fri, 5 Jul 2013 00:05:12 +0300
Subject: [RFC] clk: add flags to distinguish xtal clocks
Message-ID: <1372971912-10877-1-git-send-email-coelho@ti.com>

Add a flag that indicate whether the clock is a crystal or not.  Since
no clocks set this flag right now, include an additional flag that
indicates whether the type is set or not.  If the CLK_IS_TYPE_DEFINED
flag is not set, the value of the CLK_IS_TYPE_XTAL flag is undefined.
This ensures backwards compatibility.

Additionally, parse a new device tree binding in clk-fixed-rate to set
this flag.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---

I'm not  familiar with the common clock framework and I'm not
entirely sure the flags can be used in such a way, but to me it looks
reasonable, since some clock consumers may need to know what type of
clock is being provided.

Specifically, the wl12xx firmware needs to know if the clock is XTAL
or not to handle the stabilization and boosts properly.

My main idea is that I need to pass this information in the device
tree definition of the clocks, so that the driver can pass this
information on to the firmware.

Please let me know if this looks ok or not.  If not, please let me
know if you have any other ideas on how to solve my problem (of
knowing whether the clock attached to the WiLink chip is XTAL or not).




 drivers/clk/clk-fixed-rate.c |    6 +++++-
 include/linux/clk-provider.h |    2 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index dc58fbd..4003a82 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -90,13 +90,17 @@ void of_fixed_clk_setup(struct device_node *node)
 	struct clk *clk;
 	const char *clk_name = node->name;
 	u32 rate;
+	unsigned long flags = CLK_IS_ROOT;
 
 	if (of_property_read_u32(node, "clock-frequency", &rate))
 		return;
 
+	if (of_property_read_bool(node, "clock-xtal"))
+		flags |= CLK_IS_TYPE_DEFINED | CLK_IS_TYPE_XTAL;
+
 	of_property_read_string(node, "clock-output-names", &clk_name);
 
-	clk = clk_register_fixed_rate(NULL, clk_name, NULL, CLK_IS_ROOT, rate);
+	clk = clk_register_fixed_rate(NULL, clk_name, NULL, flags, rate);
 	if (!IS_ERR(clk))
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
 }
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1186098..034320b 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -27,6 +27,8 @@
 #define CLK_IS_ROOT		BIT(4) /* root clk, has no parent */
 #define CLK_IS_BASIC		BIT(5) /* Basic clk, can't do a to_clk_foo() */
 #define CLK_GET_RATE_NOCACHE	BIT(6) /* do not use the cached clk rate */
+#define CLK_IS_TYPE_DEFINED	BIT(7) /* the clock type is defined */
+#define CLK_IS_TYPE_XTAL	BIT(8) /* this is a crystal clock */
 
 struct clk_hw;
 
-- 
1.7.10.4



From arno at natisbad.org  Thu Jul  4 17:16:46 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Thu, 04 Jul 2013 23:16:46 +0200
Subject: [PATCHv1] arm: armada: Add .dts file for Netgear ReadyNAS 102
Message-ID: <878v1mgh4x.fsf@natisbad.org>


All hardware parts of the (Armada 370 based) NETGEAR ReadyNAS 102 are
supported by mainline kernel (USB 3.0 rear ports, USB 2.0 front port,
Gigabit controller and PHY, serial port, leds, buttons, SATA ports,
G762 fan controller) except for:

 - the Intersil ISL12057 I2C RTC Chip,
 - the Armada NAND controller.

Support for both of those is currently work in progress and does not
prevent boot.

Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
---
Hi Jason and Andrew,

As requested

 - this version is tested against current head of linus tree (+ I2C
   fixes for a race condition; for details, see message #94 of
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622325).
 - nand layout entry and ISL12057 entry have been removed until support
   is available in mainline kernel for eahc of those
 - clock, gpio led and keys have been made siblings of soc, memory and
   chosen (reported by Sebastian).

Is it still acceptable for current merge window or am I too late?

Cheers,

a+

 arch/arm/boot/dts/Makefile                     |   1 +
 arch/arm/boot/dts/armada-370-netgear-rn102.dts | 176 +++++++++++++++++++++++++
 2 files changed, 177 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-370-netgear-rn102.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..d869d83 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -100,6 +100,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
 	msm8960-cdp.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
 	armada-370-mirabox.dtb \
+	armada-370-netgear-rn102.dtb \
 	armada-370-rd.dtb \
 	armada-xp-db.dtb \
 	armada-xp-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
new file mode 100644
index 0000000..9d813d2
--- /dev/null
+++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
@@ -0,0 +1,176 @@
+/*
+ * Device Tree file for NETGEAR ReadyNAS 102
+ *
+ * Copyright (C) 2013, Arnaud EBALARD <arno at natisbad.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+/dts-v1/;
+
+/include/ "armada-370.dtsi"
+
+/ {
+	model = "NETGEAR ReadyNAS 102";
+	compatible = "netgear,readynas-102", "marvell,armada370", "marvell,armada-370-xp";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x20000000>; /* 512 MB */
+	};
+
+	soc {
+		internal-regs {
+			serial at 12000 {
+				clock-frequency = <200000000>;
+				status = "okay";
+			};
+
+			sata at a0000 {
+				nr-ports = <2>;
+				status = "okay";
+			};
+
+			pinctrl {
+				power_led_pin: power-led-pin {
+					marvell,pins = "mpp57";
+					marvell,function = "gpio";
+				};
+				sata1_led_pin: sata1-led-pin {
+					marvell,pins = "mpp15";
+					marvell,function = "gpio";
+				};
+
+				sata2_led_pin: sata2-led-pin {
+					marvell,pins = "mpp14";
+					marvell,function = "gpio";
+				};
+
+				backup_led_pin: backup-led-pin {
+					marvell,pins = "mpp56";
+					marvell,function = "gpio";
+				};
+			};
+
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
+			};
+
+			ethernet at 74000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+
+			usb at 50000 {
+				status = "okay";
+			};
+
+			i2c at 11000 {
+				compatible = "marvell,mv64xxx-i2c";
+				clock-frequency = <100000>;
+				status = "okay";
+
+				g762: g762 at 3e {
+					compatible = "gmt,g762";
+					reg = <0x3e>;
+					clocks = <&g762_clk>; /* input clock */
+					fan_gear_mode = <0>;
+					fan_startv = <1>;
+					pwm_polarity = <0>;
+				};
+			};
+
+			pcie-controller {
+				status = "okay";
+
+				/* Connected to Marvell SATA controller */
+				pcie at 1,0 {
+					/* Port 0, Lane 0 */
+					status = "okay";
+				};
+
+				/* Connected to FL1009 USB 3.0 controller */
+				pcie at 2,0 {
+					/* Port 1, Lane 0 */
+					status = "okay";
+				};
+			};
+		};
+	};
+
+	clocks {
+	       #address-cells = <1>;
+	       #size-cells = <0>;
+
+	       g762_clk: fixedclk {
+			 compatible = "fixed-clock";
+			 #clock-cells = <0>;
+			 clock-frequency = <8192>;
+	       };
+	};
+
+	gpio_leds {
+		compatible = "gpio-leds";
+		pinctrl-0 = < &power_led_pin
+			      &sata1_led_pin
+			      &sata2_led_pin
+			      &backup_led_pin >;
+		pinctrl-names = "default";
+
+		blue_power_led {
+			label = "rn102:blue:pwr";
+			gpios = <&gpio1 25 1>;  /* GPIO 57 Active Low */
+			linux,default-trigger = "heartbeat";
+		};
+
+		green_sata1_led {
+			label = "rn102:green:sata1";
+			gpios = <&gpio0 15 1>;  /* GPIO 15 Active Low */
+			default-state = "on";
+		};
+
+		green_sata2_led {
+			label = "rn102:green:sata2";
+			gpios = <&gpio0 14 1>;   /* GPIO 14 Active Low */
+			default-state = "on";
+		};
+
+		green_backup_led {
+			label = "rn102:green:backup";
+			gpios = <&gpio1 24 1>;   /* GPIO 56 Active Low */
+			default-state = "on";
+		};
+	};
+
+	gpio_keys {
+		compatible = "gpio-keys";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		button at 1 {
+			label = "Power Button";
+			linux,code = <116>;     /* KEY_POWER */
+			gpios = <&gpio1 30 1>;
+		};
+		button at 2 {
+			label = "Reset Button";
+			linux,code = <0x198>;   /* KEY_RESTART */
+			gpios = <&gpio0 6 1>;
+		};
+		button at 3 {
+			label = "Backup Button";
+			linux,code = <133>;     /* KEY_COPY */
+			gpios = <&gpio1 26 1>;
+		};
+	};
+
+};
-- 
1.8.3.1



From pwalmsley at nvidia.com  Thu Jul  4 17:18:58 2013
From: pwalmsley at nvidia.com (Paul Walmsley)
Date: Thu, 4 Jul 2013 14:18:58 -0700
Subject: Tegra baseline test results for v3.10
Message-ID: <51D5E6C2.60607@nvidia.com>

Here are some basic Tegra test results for Linux v3.10.
Logs and other details at:

     http://www.pwsan.com/tegra/testlogs/test_v3.10/20130701231549/


Test summary
------------

Build: zImage:
     Pass: ( 1/ 1): tegra_defconfig

Boot to userspace:
     Pass: ( 2/ 2): tegra114-dalmore-headless, tegra30-beaver



vmlinux object size
(delta in bytes from test_v3.10-rc6 (7d132055814ef17a6c7b69f342244c410a5e000f)):
    text     data      bss    total  kernel
   +1256       -8        0    +1248  tegra_defconfig




From arnd at arndb.de  Thu Jul  4 17:34:36 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 4 Jul 2013 23:34:36 +0200
Subject: Appended DTB files for multi-machine kernels
In-Reply-To: <20130704171148.GJ27646@sirena.org.uk>
References: <51D5A938.30607@gmail.com> <20130704171148.GJ27646@sirena.org.uk>
Message-ID: <201307042334.37161.arnd@arndb.de>

On Thursday 04 July 2013, Mark Brown wrote:
> On Thu, Jul 04, 2013 at 06:56:24PM +0200, Daniel Mack wrote:
> 
> > Unless I missed some recent discussion, this case is not easy to handle.
> > Yes, I know that these kind of things should be handled by a
> > next-generation bootloader, but in our case, we want to avoid a loader
> > update of already shipped hardware by all means.
> 
> There was some discussion about appending multiple DTBs recently.  I
> can't actually recall anything about it though so that's not an entirely
> helpful thing...

Yes, it keeps coming up, I think by now everybody agreed it's a good
idea to extend the ATAGS compat mode, but so far nobody has implemented
it. Magnus Damm was very interested in this feature last year and
was planning to work on it, but I don't know how far he got.

> > As a solution, I'm thinking of a small framework that could for example
> > work as follows.
> 
> > a) A small mechanism allows storing multiple DTB binary files inside the
> > kernel binary at compile time, and a simple function can extract them
> > again by name at runtime (something like what the firmware framework
> > does, but I don't know if that one can be used at such an early stage in
> > the boot process).
> 
> Another way of skinning this would be for either the kernel to contain
> a set of machine ID to compatible string mappings or for the device
> trees for the boards to have an additional properties giving the machine
> IDs that the boards match.  The kernel could then look for multiple DTBs
> appended to the image and try to pick one based on ATAGs.

IIRC there is actually an unused field in the dtb header that could
be used to match a board ID.

	Arnd


From tglx at linutronix.de  Thu Jul  4 17:42:36 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 4 Jul 2013 23:42:36 +0200 (CEST)
Subject: [PATCH v5] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <1372940383-5957-1-git-send-email-jonas.jensen@gmail.com>
References: <1372687359-18235-1-git-send-email-jonas.jensen@gmail.com>
 <1372940383-5957-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <alpine.DEB.2.02.1307042211420.11637@ionos.tec.linutronix.de>

On Thu, 4 Jul 2013, Jonas Jensen wrote:

> This patch adds an clocksource driver for the main timer(s)
> found on MOXA ART SoCs.
> 
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
> ---
> 
> Notes:
>     Applies to next-20130703
>     
>     Changes since v4:
>     
>     1. add general cache for TIMER_CR register

What you implemented is not a register cache. A register cache is
caching the current value and not some initial constant.
 
> +static void moxart_clkevt_mode(enum clock_event_mode mode,
> +			       struct clock_event_device *clk)
> +{
> +	switch (mode) {
> +	case CLOCK_EVT_MODE_RESUME:
> +	case CLOCK_EVT_MODE_ONESHOT:
> +		writel(timereg_cache & ~TIMEREG_CR_1_ENABLE, base + TIMER_CR);

You just modify bits on the "cache" variable. though you are not
caching it. As it seems to work it looks like this register simply can
be written with constants.

> +	timereg_cache = readl(base + TIMER_CR) | TIMEREG_CR_2_ENABLE;

Why are you reading that back? You know excactly which of the timers
you are using and none of those should be enabled before you reach
that code. If it one of them is enabled by the boot loader you better
disable it in this init function. 

Now if you disable all of those timers and just use a known set, then
you can do without a pseudo cache variable and just write constants
into the control register, right ?

Thanks,

	tglx




From mturquette at linaro.org  Thu Jul  4 18:25:38 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 04 Jul 2013 15:25:38 -0700
Subject: [RFC] clk: add flags to distinguish xtal clocks
In-Reply-To: <1372971912-10877-1-git-send-email-coelho@ti.com>
References: <1372971912-10877-1-git-send-email-coelho@ti.com>
Message-ID: <20130704222538.10823.2559@quantum>

Quoting Luciano Coelho (2013-07-04 14:05:12)
> Add a flag that indicate whether the clock is a crystal or not.  Since
> no clocks set this flag right now, include an additional flag that
> indicates whether the type is set or not.  If the CLK_IS_TYPE_DEFINED
> flag is not set, the value of the CLK_IS_TYPE_XTAL flag is undefined.
> This ensures backwards compatibility.
> 
> Additionally, parse a new device tree binding in clk-fixed-rate to set
> this flag.
> 
> Signed-off-by: Luciano Coelho <coelho at ti.com>
> ---
> 
> I'm not  familiar with the common clock framework and I'm not
> entirely sure the flags can be used in such a way, but to me it looks
> reasonable, since some clock consumers may need to know what type of
> clock is being provided.
> 
> Specifically, the wl12xx firmware needs to know if the clock is XTAL
> or not to handle the stabilization and boosts properly.

Hi Luciano,

I'd like clarification on one point. Is the same clock input signal used
on the wifi chip? What I mean is, are there multiple clock inputs and
XTAL is one, and not-XTAL is another?

Or is it the same clock input and basically the problem is that you need
to know what kind of waveform to expect (e.g. square versus sine)?

Regards,
Mike

> 
> My main idea is that I need to pass this information in the device
> tree definition of the clocks, so that the driver can pass this
> information on to the firmware.
> 
> Please let me know if this looks ok or not.  If not, please let me
> know if you have any other ideas on how to solve my problem (of
> knowing whether the clock attached to the WiLink chip is XTAL or not).
> 
> 
> 
> 
>  drivers/clk/clk-fixed-rate.c |    6 +++++-
>  include/linux/clk-provider.h |    2 ++
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
> index dc58fbd..4003a82 100644
> --- a/drivers/clk/clk-fixed-rate.c
> +++ b/drivers/clk/clk-fixed-rate.c
> @@ -90,13 +90,17 @@ void of_fixed_clk_setup(struct device_node *node)
>         struct clk *clk;
>         const char *clk_name = node->name;
>         u32 rate;
> +       unsigned long flags = CLK_IS_ROOT;
>  
>         if (of_property_read_u32(node, "clock-frequency", &rate))
>                 return;
>  
> +       if (of_property_read_bool(node, "clock-xtal"))
> +               flags |= CLK_IS_TYPE_DEFINED | CLK_IS_TYPE_XTAL;
> +
>         of_property_read_string(node, "clock-output-names", &clk_name);
>  
> -       clk = clk_register_fixed_rate(NULL, clk_name, NULL, CLK_IS_ROOT, rate);
> +       clk = clk_register_fixed_rate(NULL, clk_name, NULL, flags, rate);
>         if (!IS_ERR(clk))
>                 of_clk_add_provider(node, of_clk_src_simple_get, clk);
>  }
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 1186098..034320b 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -27,6 +27,8 @@
>  #define CLK_IS_ROOT            BIT(4) /* root clk, has no parent */
>  #define CLK_IS_BASIC           BIT(5) /* Basic clk, can't do a to_clk_foo() */
>  #define CLK_GET_RATE_NOCACHE   BIT(6) /* do not use the cached clk rate */
> +#define CLK_IS_TYPE_DEFINED    BIT(7) /* the clock type is defined */
> +#define CLK_IS_TYPE_XTAL       BIT(8) /* this is a crystal clock */
>  
>  struct clk_hw;
>  
> -- 
> 1.7.10.4


From coelho at ti.com  Thu Jul  4 18:37:45 2013
From: coelho at ti.com (Luciano Coelho)
Date: Fri, 5 Jul 2013 01:37:45 +0300
Subject: [RFC] clk: add flags to distinguish xtal clocks
In-Reply-To: <20130704222538.10823.2559@quantum>
References: <1372971912-10877-1-git-send-email-coelho@ti.com>
 <20130704222538.10823.2559@quantum>
Message-ID: <1372977465.21065.136.camel@cumari.coelho.fi>

On Thu, 2013-07-04 at 15:25 -0700, Mike Turquette wrote:
> Quoting Luciano Coelho (2013-07-04 14:05:12)
> > Add a flag that indicate whether the clock is a crystal or not.  Since
> > no clocks set this flag right now, include an additional flag that
> > indicates whether the type is set or not.  If the CLK_IS_TYPE_DEFINED
> > flag is not set, the value of the CLK_IS_TYPE_XTAL flag is undefined.
> > This ensures backwards compatibility.
> > 
> > Additionally, parse a new device tree binding in clk-fixed-rate to set
> > this flag.
> > 
> > Signed-off-by: Luciano Coelho <coelho at ti.com>
> > ---
> > 
> > I'm not  familiar with the common clock framework and I'm not
> > entirely sure the flags can be used in such a way, but to me it looks
> > reasonable, since some clock consumers may need to know what type of
> > clock is being provided.
> > 
> > Specifically, the wl12xx firmware needs to know if the clock is XTAL
> > or not to handle the stabilization and boosts properly.
> 
> Hi Luciano,

Hi Mike,

> I'd like clarification on one point. Is the same clock input signal used
> on the wifi chip? What I mean is, are there multiple clock inputs and
> XTAL is one, and not-XTAL is another?

This wifi chip can work with a few different clocks and some of them are
XTAL and others are not.  What the chip's firmware can use is one of
these:

19.2MHz (not XTAL)
26.0MHz (not XTAL)
26.0MHz (XTAL)
38.4MHz (not XTAL)
38.4MHz (XTAL)
52.0MHz (not XTAL)

It treats the XTAL clocks differently (but I don't really understand
enough of the details), so the driver needs to configure the firmware
according to these values.


> Or is it the same clock input and basically the problem is that you need
> to know what kind of waveform to expect (e.g. square versus sine)?

It's the same clock input in the chip's perspective.  One clock input
that can be any of the combinations I mentioned above.  Again, I'm not
familiar with clocks, so I guess the square vs. sine explanation is
plausible.  What I could see in the firmware is that it handles the
clocks differently if they're xtal or not.

--
Luca.



From zonque at gmail.com  Thu Jul  4 19:02:25 2013
From: zonque at gmail.com (Daniel Mack)
Date: Fri, 05 Jul 2013 01:02:25 +0200
Subject: Appended DTB files for multi-machine kernels
In-Reply-To: <201307042334.37161.arnd@arndb.de>
References: <51D5A938.30607@gmail.com> <20130704171148.GJ27646@sirena.org.uk>
 <201307042334.37161.arnd@arndb.de>
Message-ID: <51D5FF01.3060104@gmail.com>

Hi Arnd,

On 04.07.2013 23:34, Arnd Bergmann wrote:
> On Thursday 04 July 2013, Mark Brown wrote:

>> Another way of skinning this would be for either the kernel to contain
>> a set of machine ID to compatible string mappings or for the device
>> trees for the boards to have an additional properties giving the machine
>> IDs that the boards match.  The kernel could then look for multiple DTBs
>> appended to the image and try to pick one based on ATAGs.
> 
> IIRC there is actually an unused field in the dtb header that could
> be used to match a board ID.

While that would help many users, it doesn't cover our case where
different board revisions require different DTBs to be loaded, depending
on the supplied ATAG.

I think I'll go for Nicolas Pitre's suggestion as first step. He's right
that's it's a hack anyway, and we're just dealing with legacy systems
here, and hence it might not even be worth caring too much about a
proper solution.


Thanks for all the answers,
Daniel



From mturquette at linaro.org  Thu Jul  4 19:19:53 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 04 Jul 2013 16:19:53 -0700
Subject: [RFC] clk: add flags to distinguish xtal clocks
In-Reply-To: <1372977465.21065.136.camel@cumari.coelho.fi>
References: <1372971912-10877-1-git-send-email-coelho@ti.com>
 <20130704222538.10823.2559@quantum>
 <1372977465.21065.136.camel@cumari.coelho.fi>
Message-ID: <20130704231953.10823.94331@quantum>

Quoting Luciano Coelho (2013-07-04 15:37:45)
> On Thu, 2013-07-04 at 15:25 -0700, Mike Turquette wrote:
> > Quoting Luciano Coelho (2013-07-04 14:05:12)
> > > Add a flag that indicate whether the clock is a crystal or not.  Since
> > > no clocks set this flag right now, include an additional flag that
> > > indicates whether the type is set or not.  If the CLK_IS_TYPE_DEFINED
> > > flag is not set, the value of the CLK_IS_TYPE_XTAL flag is undefined.
> > > This ensures backwards compatibility.
> > > 
> > > Additionally, parse a new device tree binding in clk-fixed-rate to set
> > > this flag.
> > > 
> > > Signed-off-by: Luciano Coelho <coelho at ti.com>
> > > ---
> > > 
> > > I'm not  familiar with the common clock framework and I'm not
> > > entirely sure the flags can be used in such a way, but to me it looks
> > > reasonable, since some clock consumers may need to know what type of
> > > clock is being provided.
> > > 
> > > Specifically, the wl12xx firmware needs to know if the clock is XTAL
> > > or not to handle the stabilization and boosts properly.
> > 
> > Hi Luciano,
> 
> Hi Mike,
> 
> > I'd like clarification on one point. Is the same clock input signal used
> > on the wifi chip? What I mean is, are there multiple clock inputs and
> > XTAL is one, and not-XTAL is another?
> 
> This wifi chip can work with a few different clocks and some of them are
> XTAL and others are not.  What the chip's firmware can use is one of
> these:
> 
> 19.2MHz (not XTAL)
> 26.0MHz (not XTAL)
> 26.0MHz (XTAL)
> 38.4MHz (not XTAL)
> 38.4MHz (XTAL)
> 52.0MHz (not XTAL)
> 
> It treats the XTAL clocks differently (but I don't really understand
> enough of the details), so the driver needs to configure the firmware
> according to these values.

Thanks for the explanation.

> 
> 
> > Or is it the same clock input and basically the problem is that you need
> > to know what kind of waveform to expect (e.g. square versus sine)?
> 
> It's the same clock input in the chip's perspective.  One clock input
> that can be any of the combinations I mentioned above.  Again, I'm not
> familiar with clocks, so I guess the square vs. sine explanation is
> plausible.  What I could see in the firmware is that it handles the
> clocks differently if they're xtal or not.

OMAP has a similar thing where sys_clkin (the fast reference clock for
the chip) can be 19.2, 26, 38.4, etc. This is easy to handle since only
the rates matter.

In your case you need some extra metadata to know what to do. I'm really
not sure if CLK_IS_TYPE_XTAL is the most useful form this metadata can
take. It would be best to know if the waveform is what you really need
to know, or perhaps something else. For instance you might be affected
by some clock signal stabilization time. Can you talk to your hardware
guys and figure it out? I'd rather model the actual needs instead of
just tossing a flag in there.

Regards,
Mike

> 
> --
> Luca.


From javier.picorel at epfl.ch  Thu Jul  4 19:44:58 2013
From: javier.picorel at epfl.ch (Javier Picorel)
Date: Thu, 4 Jul 2013 23:44:58 +0000
Subject: ARM Cortex A9: LL counters
In-Reply-To: <20130704094516.GC8782@mudshark.cambridge.arm.com>
References: <BFCB49997E59134AAAF17FFE77F8FF06673738BC@REXMD.intranet.epfl.ch>,
 <20130704094516.GC8782@mudshark.cambridge.arm.com>
Message-ID: <BFCB49997E59134AAAF17FFE77F8FF06673759E9@REXMD.intranet.epfl.ch>

Hello Will,

Thanks for the clarification! However, correct me if I'm wrong but, doesn't this mean that the "CO_LF_MISS" counter refers to L2 accesses? Thanks!

Regards,
Javier
________________________________________
From: Will Deacon [will.deacon at arm.com]
Sent: 04 July 2013 11:45
To: Javier Picorel
Cc: linux-arm-kernel at lists.infradead.org; mark.rutland at arm.com
Subject: Re: ARM Cortex A9: LL counters

On Wed, Jul 03, 2013 at 07:59:14PM +0100, Javier Picorel wrote:
> Dear all,

Hello Javier,

> It seems that there is no mapping between any ARM Cortex A9 counter to the L2 (Last Level) access or misses event.

The L2 cache on Cortex-A9 is external to the CPU core and has its own set of
memory-mapped performance counters. Mark Rutland [CC'd] had something
working for this, but I haven't seen a refresh of the patches for a while.

> Looking at ARM's reference manual and OProfile's event list on A9, I see the following two counters:
>
> CO_LF_MISS: (counter: 1, 2, 3, 4, 5, 6)
>         Number of coherent linefill requests which miss in all other CPUs, meaning that the request
>         is sent to external memory (min count: 500)
> CO_LF_HIT: (counter: 1, 2, 3, 4, 5, 6)
>         Number of coherent linefill requests which hit in another CPU, meaning that the linefill
>         data is fetched directly from the relevant cache (min count: 500)
>
> It seems that the first counter refers to the L2 Misses and the second one to the L2 Hits (Last Level Cache in this architecture). I'm not sure
> whether we should do something about this or nor. Thanks!

No, these are all for L1. `sent to external memory' means sent to L2.

Will


From gang.chen at asianux.com  Thu Jul  4 21:09:31 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Fri, 05 Jul 2013 09:09:31 +0800
Subject: [PATCH v3] arch/*/asm/include/bitops.h: api issue, find_*_bit()
 defination are different with each other
In-Reply-To: <51BFD51E.3040202@asianux.com>
References: <51AE8FEF.1020809@asianux.com> <51AE903C.6010806@asianux.com>
 <51AE909D.9080006@asianux.com> <20130605071915.GK23140@pengutronix.de>
 <51AF225A.5020703@asianux.com> <51B05865.30305@asianux.com>
 <51BFD51E.3040202@asianux.com>
Message-ID: <51D61CCB.40409@asianux.com>

Hello Maintainers:

Please help check this patch whether OK, when you have time.

Thanks.

On 06/18/2013 11:33 AM, Chen Gang wrote:
> Hello related Maintainers:
> 
> Please help check this patch when you have time.
> 
> Thanks.
> 
> On 06/06/2013 05:37 PM, Chen Gang wrote:
>>
>> For arm and m68k, they customize find_*_bit(), but the API is different
>> with 'generic'.
>>
>> avr32, s390, and unicore32 also customize find_*_bit(), but the API is
>> the same with 'generic', and the left architectures all use 'generic'.
>>
>> So need change arm and m68k related API to match the 'generic', then
>> all another modules can face same public API for various architectures.
>>
>> Also beautify code and comments to pass "./scripts/checkpatch.pl"
>>
>>
>> Signed-off-by: Chen Gang <gang.chen at asianux.com>
>> ---
>>  arch/arm/include/asm/bitops.h  |   26 ++++++++++++++++++--------
>>  arch/arm/lib/findbit.S         |   14 ++++++++++----
>>  arch/m68k/include/asm/bitops.h |   25 ++++++++++++++-----------
>>  3 files changed, 42 insertions(+), 23 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
>> index e691ec9..83e4d3a 100644
>> --- a/arch/arm/include/asm/bitops.h
>> +++ b/arch/arm/include/asm/bitops.h
>> @@ -161,18 +161,28 @@ extern int _test_and_change_bit(int nr, volatile unsigned long * p);
>>  /*
>>   * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
>>   */
>> -extern int _find_first_zero_bit_le(const void * p, unsigned size);
>> -extern int _find_next_zero_bit_le(const void * p, int size, int offset);
>> -extern int _find_first_bit_le(const unsigned long *p, unsigned size);
>> -extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
>> +extern unsigned long _find_first_zero_bit_le(const void *p,
>> +						unsigned long size);
>> +extern unsigned long _find_next_zero_bit_le(const void *p, unsigned long size,
>> +						unsigned long offset);
>> +extern unsigned long _find_first_bit_le(const unsigned long *p,
>> +						unsigned long size);
>> +extern unsigned long _find_next_bit_le(const unsigned long *p,
>> +						unsigned long size,
>> +						unsigned long offset);
>>  
>>  /*
>>   * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
>>   */
>> -extern int _find_first_zero_bit_be(const void * p, unsigned size);
>> -extern int _find_next_zero_bit_be(const void * p, int size, int offset);
>> -extern int _find_first_bit_be(const unsigned long *p, unsigned size);
>> -extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
>> +extern unsigned long _find_first_zero_bit_be(const void *p,
>> +						unsigned long size);
>> +extern unsigned long _find_next_zero_bit_be(const void *p, unsigned long size,
>> +						unsigned long offset);
>> +extern unsigned long _find_first_bit_be(const unsigned long *p,
>> +						unsigned long size);
>> +extern unsigned long _find_next_bit_be(const unsigned long *p,
>> +						unsigned long size,
>> +						unsigned long offset);
>>  
>>  #ifndef CONFIG_SMP
>>  /*
>> diff --git a/arch/arm/lib/findbit.S b/arch/arm/lib/findbit.S
>> index 64f6bc1..817dd70 100644
>> --- a/arch/arm/lib/findbit.S
>> +++ b/arch/arm/lib/findbit.S
>> @@ -19,7 +19,8 @@
>>  
>>  /*
>>   * Purpose  : Find a 'zero' bit
>> - * Prototype: int find_first_zero_bit(void *addr, unsigned int maxbit);
>> + * Prototype: unsigned long find_first_zero_bit(const void *p,
>> + *						unsigned long size);
>>   */
>>  ENTRY(_find_first_zero_bit_le)
>>  		teq	r1, #0	
>> @@ -40,7 +41,9 @@ ENDPROC(_find_first_zero_bit_le)
>>  
>>  /*
>>   * Purpose  : Find next 'zero' bit
>> - * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
>> + * Prototype: unsigned long find_next_zero_bit(const void *p,
>> + *						unsigned long size,
>> + *						unsigned long offset);
>>   */
>>  ENTRY(_find_next_zero_bit_le)
>>  		teq	r1, #0
>> @@ -60,7 +63,8 @@ ENDPROC(_find_next_zero_bit_le)
>>  
>>  /*
>>   * Purpose  : Find a 'one' bit
>> - * Prototype: int find_first_bit(const unsigned long *addr, unsigned int maxbit);
>> + * Prototype: unsigned long find_first_bit(const unsigned long *p,
>> + *					unsigned long size);
>>   */
>>  ENTRY(_find_first_bit_le)
>>  		teq	r1, #0	
>> @@ -81,7 +85,9 @@ ENDPROC(_find_first_bit_le)
>>  
>>  /*
>>   * Purpose  : Find next 'one' bit
>> - * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
>> + * Prototype: unsigned long find_next_bit(const unsigned long *p,
>> + *					unsigned long size,
>> + *					unsigned long offset);
>>   */
>>  ENTRY(_find_next_bit_le)
>>  		teq	r1, #0
>> diff --git a/arch/m68k/include/asm/bitops.h b/arch/m68k/include/asm/bitops.h
>> index c6baa91..b1d8752 100644
>> --- a/arch/m68k/include/asm/bitops.h
>> +++ b/arch/m68k/include/asm/bitops.h
>> @@ -320,11 +320,11 @@ static inline int bfchg_mem_test_and_change_bit(int nr,
>>  #include <asm-generic/bitops/ffz.h>
>>  #else
>>  
>> -static inline int find_first_zero_bit(const unsigned long *vaddr,
>> -				      unsigned size)
>> +static inline unsigned long find_first_zero_bit(const unsigned long *vaddr,
>> +				      unsigned long size)
>>  {
>>  	const unsigned long *p = vaddr;
>> -	int res = 32;
>> +	unsigned int res = 32;
>>  	unsigned int words;
>>  	unsigned long num;
>>  
>> @@ -346,11 +346,12 @@ out:
>>  }
>>  #define find_first_zero_bit find_first_zero_bit
>>  
>> -static inline int find_next_zero_bit(const unsigned long *vaddr, int size,
>> -				     int offset)
>> +static inline unsigned long find_next_zero_bit(const unsigned long *vaddr,
>> +						unsigned long size,
>> +						unsigned long offset)
>>  {
>>  	const unsigned long *p = vaddr + (offset >> 5);
>> -	int bit = offset & 31UL, res;
>> +	unsigned int bit = offset & 31UL, res;
>>  
>>  	if (offset >= size)
>>  		return size;
>> @@ -376,10 +377,11 @@ static inline int find_next_zero_bit(const unsigned long *vaddr, int size,
>>  }
>>  #define find_next_zero_bit find_next_zero_bit
>>  
>> -static inline int find_first_bit(const unsigned long *vaddr, unsigned size)
>> +static inline unsigned long find_first_bit(const unsigned long *vaddr,
>> +						unsigned long size)
>>  {
>>  	const unsigned long *p = vaddr;
>> -	int res = 32;
>> +	unsigned int res = 32;
>>  	unsigned int words;
>>  	unsigned long num;
>>  
>> @@ -401,11 +403,12 @@ out:
>>  }
>>  #define find_first_bit find_first_bit
>>  
>> -static inline int find_next_bit(const unsigned long *vaddr, int size,
>> -				int offset)
>> +static inline unsigned long find_next_bit(const unsigned long *vaddr,
>> +						unsigned long size,
>> +						unsigned long offset)
>>  {
>>  	const unsigned long *p = vaddr + (offset >> 5);
>> -	int bit = offset & 31UL, res;
>> +	unsigned int bit = offset & 31UL, res;
>>  
>>  	if (offset >= size)
>>  		return size;
>>
> 
> 


-- 
Chen Gang


From voice.shen at atmel.com  Thu Jul  4 21:25:08 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Fri, 5 Jul 2013 09:25:08 +0800
Subject: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
In-Reply-To: <CACQ1gAio0ekQMgyfrLjTHmMPGJQoKoe61GreFQDN-iLjxbLQ0w@mail.gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-2-git-send-email-richard.genoud@gmail.com>
 <51D24299.9050209@atmel.com>
 <CACQ1gAgcc=j3kmcpjp8bbdHhxr_k=h8jJs6R_paJbPUMv74uGg@mail.gmail.com>
 <51D29927.80900@atmel.com>
 <CACQ1gAhnDk-qSt_5xrsMakXqGGDO5pEbA-9UDWCJG=AABDc+zg@mail.gmail.com>
 <CACQ1gAgPaRm3gxxJNgfj9bR565Q0+SNY3+EcjA_mrh1N+yPzSA@mail.gmail.com>
 <51D4CC94.3020908@atmel.com>
 <CACQ1gAio0ekQMgyfrLjTHmMPGJQoKoe61GreFQDN-iLjxbLQ0w@mail.gmail.com>
Message-ID: <51D62074.9070303@atmel.com>

Hi Richard,

On 7/4/2013 21:44, Richard Genoud wrote:
> 2013/7/4 Bo Shen <voice.shen at atmel.com>:
>> Hi Richard,
>>
>>
>> On 7/3/2013 23:51, Richard Genoud wrote:
>>>>
>>>>> but there's a violent hang (kernel stops, no trace) when I try the
>>>>> record :
>>>>> arecord -v -V stereo -Dplug:default -f cd -t wav -c 2 /tmp/toto.wav
>>>>> last thing I see is :
>>>>> dma dma0chan3: atc_control (3)
>>
>>
>> I don't meet this issue. Playback and recording works well on my side on
>> at91sam9g35ek board.
>>
>>
>>>>> I'll try to trace that.
>>>
>>> I think it's DMA related.
>>> the last thing done by the kernel is:
>>>    i2c i2c-0: i2c_outb: 0x34 A
>>>    i2c i2c-0: i2c_outb: 0x0c A
>>>    i2c i2c-0: i2c_outb: 0x5a A
>>> meaning: enable power on, LINE IN, ADC, OSC, on the WM8731
>>> so, after that, data is comming from the codec to the SSC and then is
>>> handled by the DMA.
>>> there must be something nasty on the DMA bus to hang everything like
>>> that...
>>
>>
>> Will you try i2c without DMA support to test this issue?
>
> Ok, I nailed it !
>
> To be sure we are on the same base, here is what I have done:
> onto next-20130704:
> - your 5 patches:
> ASoC: atmel_ssc_dai: move set dma data to startup callback
> ASoC: atmel_ssc_dai: add error mask define
> ASoC: atmel-pcm-dma: move prepare for dma to dai prepare
> ARM: atmel-ssc: change phybase type to dma_addr_t
> ASoC: atmel-pcm: use generic dmaengine framework
> - my patches 4-8:
> ARM: at91: DTS: sam9x5: add SSC DMA parameters
> ARM: AT91: DTS: sam9x5ek: add WM8731 codec
> ARM: AT91: DTS: sam9x5ek: add sound configuration
> ARM: AT91: DTS: sam9x5ek: enable SSC
> sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards
>
> To be sure that dma-I2c doesn't disturb something, I use i2c gpio bitbang:
> diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi
> b/arch/arm/boot/dts/at91sam9x5ek.dtsi
> index 6684d4b..53a991e 100644
> --- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
> @@ -57,15 +57,6 @@
>   				status = "okay";
>   			};
>
> -			i2c0: i2c at f8010000 {
> -				status = "okay";
> -
> -				wm8731: wm8731 at 1a {
> -					compatible = "wm8731";
> -					reg = <0x1a>;
> -				};
> -			};
> -
>   			pinctrl at fffff400 {
>   				mmc0 {
>   					pinctrl_board_mmc0: mmc0-board {
> @@ -114,6 +105,15 @@
>   		};
>   	};
>
> +	i2c at 0 {
> +		status = "okay";
> +
> +		wm8731: wm8731 at 1a {
> +			compatible = "wm8731";
> +			reg = <0x1a>;
> +		};
> +	};
> +
>   	sound {
>   		compatible = "atmel,sam9x5-audio-wm8731";
>
> with that configuration, it hangs when I do a:
> arecord -v -V stereo -Dplug:default -f cd -t wav -c 2 /tmp/toto.wav
>
> Now, if I remove the overrun error on ssc in rx_mask:
> diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
> index 0ecf356..c04e825 100644
> --- a/sound/soc/atmel/atmel_ssc_dai.c
> +++ b/sound/soc/atmel/atmel_ssc_dai.c
> @@ -83,7 +83,6 @@ static struct atmel_ssc_mask ssc_rx_mask = {
>   	.ssc_disable	= SSC_BIT(CR_RXDIS),
>   	.ssc_endx	= SSC_BIT(SR_ENDRX),
>   	.ssc_endbuf	= SSC_BIT(SR_RXBUFF),
> -	.ssc_error	= SSC_BIT(SR_OVRUN),
>   	.pdc_enable	= ATMEL_PDC_RXTEN,
>   	.pdc_disable	= ATMEL_PDC_RXTDIS,
>   };
>
> It doesn't hang any more doing a simple record.
> BUT it still hangs if we do record and play at the same time.
>
> Removing the overrun on tx_mask prevent the hang:
> diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
> index 0ecf356..41e15c2 100644
> --- a/sound/soc/atmel/atmel_ssc_dai.c
> +++ b/sound/soc/atmel/atmel_ssc_dai.c
> @@ -73,7 +73,6 @@ static struct atmel_ssc_mask ssc_tx_mask = {
>   	.ssc_disable	= SSC_BIT(CR_TXDIS),
>   	.ssc_endx	= SSC_BIT(SR_ENDTX),
>   	.ssc_endbuf	= SSC_BIT(SR_TXBUFE),
> -	.ssc_error	= SSC_BIT(SR_OVRUN),
>   	.pdc_enable	= ATMEL_PDC_TXTEN,
>   	.pdc_disable	= ATMEL_PDC_TXTDIS,
>   };
>
> i.e. when I revert "ASoC: atmel_ssc_dai: add error mask define", I
> don't see any hang.
>
> Could you test and confirm that behaviour please ?

Yes, I aware this issue.
Actually the system not hang, the resource all are occupied by the 
interrupt. This because, we enable the interrupt, when once interrupt 
occur, I try many methods to clear it, however we can not clear it. So, 
it generates the interrupt all the time. It seems the system hang.

Temp solution: not enable the interrupt. use the following patch to 
disable the interrupt.
---8>---
diff --git a/sound/soc/atmel/atmel_ssc_dai.c 
b/sound/soc/atmel/atmel_ssc_dai.c
index 0ecf356..bb53dea 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -649,7 +649,7 @@ static int atmel_ssc_prepare(struct 
snd_pcm_substream *substream,
         dma_params = ssc_p->dma_params[dir];

         ssc_writel(ssc_p->ssc->regs, CR, dma_params->mask->ssc_enable);
-       ssc_writel(ssc_p->ssc->regs, IER, dma_params->mask->ssc_error);
+       ssc_writel(ssc_p->ssc->regs, IDR, dma_params->mask->ssc_error);

         pr_debug("%s enabled SSC_SR=0x%08x\n",
                         dir ? "receive" : "transmit",
---<8---

BTW, I am checking this with our IP team, if find the real solution, I 
will fix it.

> I attached a the (simple) .config I used for the tests.
>
> PS: I hope the patches won't be mangled by gmail...
>
> Best regards,
> Richard.

Best Regards,
Bo Shen



From vinod.koul at intel.com  Fri Jul  5 00:53:50 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Fri, 5 Jul 2013 10:23:50 +0530
Subject: [PATCH] dmaengine: shdma: fix a build failure on platforms
 with no DMA support
In-Reply-To: <Pine.LNX.4.64.1306192125480.12502@axis700.grange>
References: <Pine.LNX.4.64.1305301650290.29171@axis700.grange>
 <51A77CF1.7040105@ti.com> <20130531024438.GB32564@verge.net.au>
 <CAGa+x8413povhYWx+BSj=TdzQDAuYFXmjF4A2kXvQt+=n+380w@mail.gmail.com>
 <Pine.LNX.4.64.1306192125480.12502@axis700.grange>
Message-ID: <20130705045350.GA10947@intel.com>

On Wed, Jun 19, 2013 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
> Hi Vinod
> 
> On Wed, 19 Jun 2013, Kevin Hilman wrote:
> 
> > On Thu, May 30, 2013 at 7:44 PM, Simon Horman <horms at verge.net.au> wrote:
> > 
> > [...]
> > 
> > > thanks for this. I will wait for a refresh (as we discussed earlier today).
> > > Can I confirm that this is a fix for v3.10? If so, could ou note
> > > that when you post your revised patch?
> > 
> > Any progress on this patch?
> > 
> > The SH-mobile defconfigs are still all failing in linux-next.
> 
> In
> 
> https://patchwork.kernel.org/patch/2640061/
And you havent CC maintainers on this patch, so I dont have it!
> 
> I proposed a simple immediate fix for this problem. Arnd at the same time 
> developed an alternative solution:
> 
> https://patchwork.kernel.org/patch/2644121/
> https://patchwork.kernel.org/patch/2644111/
Reading these patches I agree with Arnd that client drivers should not depend on
dma slave drivers. Existing issue need to be fixed

Arnd, Have you merged these changes?

--
~Vinod
> 
> Which, I think, is a much larger change and isn't suitable as a bug-fix 
> this late in the release cycle. Instead those patches address other issues 
> with the shdma drivers, which might need to be carefully studied and 
> solutions have to be found, which, however, would require more work and 
> need a longer time. What is your opinion on this? Would you agree to apply 
> v2 of this patch, as referenced above or would you prefer a different 
> solution?
> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/

-- 


From rnayak at ti.com  Fri Jul  5 01:43:04 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 5 Jul 2013 11:13:04 +0530
Subject: [RFC 0/4] Cleanup PRM and CM regbit headers
In-Reply-To: <alpine.DEB.2.02.1307041627540.6258@utopia.booyaka.com>
References: <1372076143-12955-1-git-send-email-rnayak@ti.com>
 <20130625071428.GC5523@atomide.com> <51C95839.6050307@ti.com>
 <20130704115819.GJ5523@atomide.com> <51D56743.9080800@ti.com>
 <alpine.DEB.2.02.1307041627540.6258@utopia.booyaka.com>
Message-ID: <51D65CE8.4050004@ti.com>

On Thursday 04 July 2013 10:14 PM, Paul Walmsley wrote:
> You mentioned that these patches were generated with some kind of awk/grep 
> scripting.  Can you integrate that in an automated way into the 
> autogeneration flow?  If the answer is yes, then keep the header.  If the 
> answer is no, then the header should be dropped.  Beno?t, maybe you have 
> an opinion too?

Ok, I'll try and integrate those scripts so all this can be done in an
automated way even for newer SoCs.

> 
> As far as whether this should go in -rcX or not, my view is that, as a 
> matter of policy, large changes like this should wait until v3.12.  Now, 
> having written that, I also was under the impression that the OMAP5 
> changes weren't going to be sent upstream unless the total diffstat would 
> be balanced to roughly zero or negative lines.  As far as I know, that 
> didn't happen.  So I guess, v3.11-rc it is...  kernel development by 
> diffstat :-(

I don't mind these going in -rcX or 3.12, either way is fine.
 
> 
> Finally, please repost the whole series once you're done with your 
> changes, as a non-RFC, along with your pull request (if you plan to send 
> one).  I guess I should be the one to take these, since I wound up taking 
> the OMAP5 addition...

:) I thought so too that you should be the one sending the pull.
I will post these out as non-RFC after I do a clean integration into
the autogen scripts, and then you can take a call on sending the pull for
either -rcX or 3.12



From rnayak at ti.com  Fri Jul  5 01:48:44 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 5 Jul 2013 11:18:44 +0530
Subject: OMAP baseline test results for v3.10-rc6
In-Reply-To: <alpine.DEB.2.02.1307041810410.6258@utopia.booyaka.com>
References: <alpine.DEB.2.02.1306170521020.9909@utopia.booyaka.com>
 <20130625160243.GE22312@arwen.pp.htv.fi>
 <alpine.DEB.2.02.1306251746060.14373@utopia.booyaka.com>
 <51C9F0A8.1050607@ti.com> <87fvw6t136.fsf@linaro.org>
 <79CD15C6BA57404B839C016229A409A83ECC952D@DBDE04.ent.ti.com>
 <51CAEB33.5010101@ti.com>
 <alpine.DEB.2.02.1306261722520.6135@utopia.booyaka.com>
 <51CBBCD8.5030600@ti.com>
 <alpine.DEB.2.02.1306281844090.8767@utopia.booyaka.com>
 <alpine.DEB.2.02.1307010211580.3741@utopia.booyaka.com>
 <79CD15C6BA57404B839C016229A409A83ECCC435@DBDE04.ent.ti.com>
 <51D2E096.5040700@ti.com>
 <alpine.DEB.2.02.1307031944580.9618@utopia.booyaka.com>
 <alpine.DEB.2.02.1307041810410.6258@utopia.booyaka.com>
Message-ID: <51D65E3C.1070202@ti.com>

On Thursday 04 July 2013 11:42 PM, Paul Walmsley wrote:
> On Wed, 3 Jul 2013, Paul Walmsley wrote:
> 
>> As far as Lokesh's patch goes: it doesn't make sense to me to remove a 
>> file during 'make clean' that the build process doesn't create.  So while 
>> I understand the motivation for the patch, and don't mind if upstream 
>> takes it, I personally wouldn't care to ack it.
> 
> Incidentally, if there's any patch that would improve the current 
> situation with appended DTBs by going upstream, it would be a patch like 
> Grant's "HACK" patch to add appended DTB building into the kernel build 
> system.  Maybe folks can push to something similar to that one upstream?

Grant already made it clear when he posted that patch that neither that nor
anything similar would be taken up mainline because the appended dtb was only
meant for folks stuck with legacy bootloaders and have no way to upgrade.
Anyone who uses a bootloader capable of passing the dtb should *not* use the
appended dtb way.

> 
> 
> - Paul
> 



From wangyuhang2014 at gmail.com  Fri Jul  5 02:25:09 2013
From: wangyuhang2014 at gmail.com (yuhang wang)
Date: Fri, 5 Jul 2013 14:25:09 +0800
Subject: SPI: DUAL/QUAD support
In-Reply-To: <OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704130017.GA25997@sig21.net>
 <OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>
 <20130704154927.GE27646@sirena.org.uk>
 <OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>
Message-ID: <CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>

Hi Thomas:

>> Well, there's two bits here.  One is the support in the client drivers
>> for using the extra data lines and the other is the support in the SPI
>> core for telling controllers to do this.  We need that second bit in
>> place before the first one can be implemented.
>
> I am not sure if we do. In the system I am working on, the QSPI controller
> recognizes the quad mode commands from the Tx data and automatically
> switches modes; no manual intervention by the flash driver is needed.
>
> I agree that this may not be the case for all SPI controllers. Yuhang, can
> you tell us what your controller will do?

OK, well my spi controller just sets the certain transfer mode in the register
to make it in that mode(single,dual,quad). Then it will send and receive datas
with the specific lines. As master, it should be told the transfer lines by the
slave. Thus I need some members to deliver the information.

But what you said "QSPI controller recognizes the quad mode commands
from the Tx data and automatically switches modes;"  I can not figure out.
The communication is launched by SPI master, so how can the controller
recognizes the Tx data in the first transmission.

>Yes, there are usually different opcodes, and as far as I know, they are
>not supported by the m25p80 driver. It seems we are missing some
>background info here.
>My guess is that the flash chip in question is configured to treat single
>mode opcodes as dual or quad mode commands (some chips support this), and
>that the SPI controller needs to be told, for each transfer, which mode to
>use.
Just as Johannes said. In my patch m25p80's changes is incomplete.
Because my inicial aim is to add the transfer width member to tell controller
the mode flash in. And I will attach new patch about m25p80 later.
Also you are right. There are really series of flashes do not support dual/quad
transfer. So I don't know whether there are any standard for serial-flash just
like the CFI for parallel-flash. Personally, to make a general standard and
a general code for serial-flash is necessary. So that we do not need to add
special function in m25p80.c.

Thanks,
yuhang


From tglx at linutronix.de  Fri Jul  5 02:30:47 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 5 Jul 2013 08:30:47 +0200 (CEST)
Subject: [PATCH] clocksource/cadence_ttc: Reuse clocksource as sched_clock
In-Reply-To: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <alpine.DEB.2.02.1307050819000.11637@ionos.tec.linutronix.de>

On Wed, 3 Jul 2013, Soren Brinkmann wrote:

> Reuse the TTC clocksource timer as sched clock, too. Since only a single
> sched clock is supported in Linux, this feature optional and can be
> selected through Kconfig.

This changelog doesn't make sense.

There can be only one active sched_clock, but that does no mean, that
you cannot have different implementations compiled in.

So if you disable this config which sched_clock is your kernel using?
And if you enable it, how is guaranteed that you end up with the ttc
sched_clock as the active one? Just due to initcall ordering?

Thanks,

	tglx


From shawn.guo at linaro.org  Fri Jul  5 02:38:55 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 5 Jul 2013 14:38:55 +0800
Subject: [PATCH] mmc: sdhci: request irq after sdhci_init() is called
Message-ID: <1373006335-31239-1-git-send-email-shawn.guo@linaro.org>

Generally request_irq() should be called after hardware has been
initialized into a sane state.  However, sdhci driver currently calls
request_irq() before sdhci_init().  At least, the following kernel panic
seen on i.MX6 is caused by that.  The sdhci controller on i.MX6 may have
noisy glitch on DAT1 line, which will trigger SDIO interrupt handling
once request_irq() is called.  But at this point, the SDIO interrupt
handler host->sdio_irq_thread has not been registered yet.  Thus, we
see the NULL pointer access with wake_up_process(host->sdio_irq_thread)
in mmc_signal_sdio_irq().

sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: no vqmmc regulator found
mmc0: no vmmc regulator found
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0+ #3
task: 9f860000 ti: 9f862000 task.ti: 9f862000
PC is at wake_up_process+0xc/0x44
LR is at sdhci_irq+0x378/0x93c
pc : [<8004f768>]    lr : [<803fb698>]    psr: 40000193
sp : 9f863ba0  ip : 9f863bb8  fp : 9f863bb4
r10: 9f807900  r9 : 80761fbc  r8 : 00000000
r7 : 00000000  r6 : 00000000  r5 : 00000001  r4 : 9fa68000
r3 : 00000001  r2 : 00000002  r1 : 20000193  r0 : 00000000
Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 8000404a  DAC: 00000017
Process swapper/0 (pid: 1, stack limit = 0x9f862238)
Stack: (0x9f863ba0 to 0x9f864000)
3ba0: 00000001 9fa68000 9f863c04 9f863bb8 803fb698 8004f768 8011af00 80265aac
3bc0: 00000000 000003d9 00000000 9fa51880 00000001 00000000 9f863c14 9fa53640
3be0: 00000001 00000000 00000000 00000036 80761fbc 9f807900 9f863c3c 9f863c08
3c00: 80075154 803fb32c 802c2b38 802c63d8 802c63cc 9f807900 00000001 9f862000
3c20: 00000036 00000000 9f807930 60000113 9f863c54 9f863c40 800752ec 8007510c
3c40: 9f807900 00000001 9f863c6c 9f863c58 80078324 800752a8 00000036 8071fd64
3c60: 9f863c84 9f863c70 80074ac0 80078294 00000140 8072ab78 9f863cac 9f863c88
3c80: 8000ee34 80074aa4 00000000 a080e10c 8072acbc 9f863cd0 a080e100 00000036
3ca0: 9f863ccc 9f863cb0 80008600 8000edec 805386a8 60000113 ffffffff 9f863d04
3cc0: 9f863d24 9f863cd0 8000e0c0 800085dc 9f807950 60000113 00000007 00000000
3ce0: 9f807900 9fa53640 9f807950 9fa68240 00000036 9f807930 60000113 9f863d24
3d00: 9f863d28 9f863d18 80076834 805386a8 60000113 ffffffff 9f863d64 9f863d28
3d20: 80076834 80538688 00000000 800bfe4c 00002fac 00000001 9f863d54 9fa53640
3d40: 9f807900 803fb320 9fa68240 00000080 00000000 00000036 9f863d94 9f863d68
3d60: 80076b38 80076674 00000080 9fa68240 9fa68000 04000000 9fa6836c 9fa68380
3d80: 806d620c 80700350 9f863dc4 9f863d98 803fce8c 80076a88 9fa532c0 9fa68240
3da0: 9fa51490 9fa51490 9fa68240 00000000 9f8ae600 9f81d080 9f863df4 9f863dc8
3dc0: 803fea0c 803fc808 9f863de4 9f863dd8 80125850 807b1ed8 807576b8 9f8ae610
3de0: 00000000 807576b8 9f863e04 9f863df8 802ee0d4 803fe798 9f863e2c 9f863e08
3e00: 802ecd1c 802ee0c0 00000000 9f8ae610 807576b8 9f8ae644 00000000 000000a9
3e20: 9f863e4c 9f863e30 802ecec0 802ecc30 9f83355c 807576b8 802ece2c 00000000
3e40: 9f863e74 9f863e50 802eb3d8 802ece38 9f83355c 9f8ac3b4 9f833570 807576b8
3e60: 80746e70 9fa51400 9f863e84 9f863e78 802ec838 802eb388 9f863eb4 9f863e88
3e80: 802ec3d0 802ec824 80692748 807620c0 9f863eb4 807576b8 00000006 807620c0
3ea0: 00000000 000000a9 9f863edc 9f863eb8 802ed3e8 802ec2fc 9f862000 00000006
3ec0: 807620c0 00000000 000000a9 80700350 9f863eec 9f863ee0 802ee2f8 802ed374
3ee0: 9f863efc 9f863ef0 80700364 802ee2b8 9f863f54 9f863f00 8000870c 8070035c
3f00: 9f863f54 9f863f10 9f862000 00000000 00000000 00000006 00000006 806d3aa4
3f20: 00000000 80688b18 9f863f54 80713560 00000006 80713540 807620c0 000000a9
3f40: 806d620c 8071ec24 9f863f94 9f863f58 806d6994 800086dc 00000006 00000006
3f60: 806d620c f6bfffff fb7f5df7 00000000 8052da28 00000000 00000000 00000000
3f80: 00000000 00000000 9f863fac 9f863f98 8052da38 806d689c ffffffff 00000000
3fa0: 00000000 9f863fb0 8000e5d8 8052da34 00000000 00000000 00000000 00000000
3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 d9cdf5ff 1fff5ffe
Backtrace:
[<8004f75c>] (wake_up_process+0x0/0x44) from [<803fb698>] (sdhci_irq+0x378/0x93c)
 r4:9fa68000 r3:00000001
[<803fb320>] (sdhci_irq+0x0/0x93c) from [<80075154>] (handle_irq_event_percpu+0x54/0x19c)
[<80075100>] (handle_irq_event_percpu+0x0/0x19c) from [<800752ec>] (handle_irq_event+0x50/0x70)
[<8007529c>] (handle_irq_event+0x0/0x70) from [<80078324>] (handle_fasteoi_irq+0x9c/0x170)
 r5:00000001 r4:9f807900
[<80078288>] (handle_fasteoi_irq+0x0/0x170) from [<80074ac0>] (generic_handle_irq+0x28/0x38)
 r5:8071fd64 r4:00000036
[<80074a98>] (generic_handle_irq+0x0/0x38) from [<8000ee34>] (handle_IRQ+0x54/0xb4)
 r4:8072ab78 r3:00000140
[<8000ede0>] (handle_IRQ+0x0/0xb4) from [<80008600>] (gic_handle_irq+0x30/0x64)
 r8:00000036 r7:a080e100 r6:9f863cd0 r5:8072acbc r4:a080e10c
r3:00000000
[<800085d0>] (gic_handle_irq+0x0/0x64) from [<8000e0c0>] (__irq_svc+0x40/0x54)
Exception stack(0x9f863cd0 to 0x9f863d18)
3cc0:                                     9f807950 60000113 00000007 00000000
3ce0: 9f807900 9fa53640 9f807950 9fa68240 00000036 9f807930 60000113 9f863d24
3d00: 9f863d28 9f863d18 80076834 805386a8 60000113 ffffffff
 r7:9f863d04 r6:ffffffff r5:60000113 r4:805386a8
[<8053867c>] (_raw_spin_unlock_irqrestore+0x0/0x30) from [<80076834>] (__setup_irq+0x1cc/0x414)
[<80076668>] (__setup_irq+0x0/0x414) from [<80076b38>] (request_threaded_irq+0xbc/0x140)
[<80076a7c>] (request_threaded_irq+0x0/0x140) from [<803fce8c>] (sdhci_add_host+0x690/0xb88)
[<803fc7fc>] (sdhci_add_host+0x0/0xb88) from [<803fea0c>] (sdhci_esdhc_imx_probe+0x280/0x4d4)
 r8:9f81d080 r7:9f8ae600 r6:00000000 r5:9fa68240 r4:9fa51490
[<803fe78c>] (sdhci_esdhc_imx_probe+0x0/0x4d4) from [<802ee0d4>] (platform_drv_probe+0x20/0x24)
 r8:807576b8 r7:00000000 r6:9f8ae610 r5:807576b8 r4:807b1ed8
[<802ee0b4>] (platform_drv_probe+0x0/0x24) from [<802ecd1c>] (driver_probe_device+0xf8/0x208)
[<802ecc24>] (driver_probe_device+0x0/0x208) from [<802ecec0>] (__driver_attach+0x94/0x98)
 r8:000000a9 r7:00000000 r6:9f8ae644 r5:807576b8 r4:9f8ae610
r3:00000000
[<802ece2c>] (__driver_attach+0x0/0x98) from [<802eb3d8>] (bus_for_each_dev+0x5c/0x90)
 r6:00000000 r5:802ece2c r4:807576b8 r3:9f83355c
[<802eb37c>] (bus_for_each_dev+0x0/0x90) from [<802ec838>] (driver_attach+0x20/0x28)
 r6:9fa51400 r5:80746e70 r4:807576b8
[<802ec818>] (driver_attach+0x0/0x28) from [<802ec3d0>] (bus_add_driver+0xe0/0x234)
[<802ec2f0>] (bus_add_driver+0x0/0x234) from [<802ed3e8>] (driver_register+0x80/0x14c)
 r8:000000a9 r7:00000000 r6:807620c0 r5:00000006 r4:807576b8
[<802ed368>] (driver_register+0x0/0x14c) from [<802ee2f8>] (platform_driver_register+0x4c/0x60)
[<802ee2ac>] (platform_driver_register+0x0/0x60) from [<80700364>] (sdhci_esdhc_imx_driver_init+0x14/0x1c)
[<80700350>] (sdhci_esdhc_imx_driver_init+0x0/0x1c) from [<8000870c>] (do_one_initcall+0x3c/0x164)
[<800086d0>] (do_one_initcall+0x0/0x164) from [<806d6994>] (kernel_init_freeable+0x104/0x1d0)
[<806d6890>] (kernel_init_freeable+0x0/0x1d0) from [<8052da38>] (kernel_init+0x10/0xec)
[<8052da28>] (kernel_init+0x0/0xec) from [<8000e5d8>] (ret_from_fork+0x14/0x3c)
 r4:00000000 r3:ffffffff
Code: e89da800 e1a0c00d e92dd818 e24cb004 (e5903000)
---[ end trace e9af3588936b63f0 ]---
Kernel panic - not syncing: Fatal exception in interrupt

Fix the panic by simply reverse the calling sequence between
request_irq() and sdhci_init().

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/mmc/host/sdhci.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 2ea429c..a821b71 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3174,6 +3174,8 @@ int sdhci_add_host(struct sdhci_host *host)
 		host->tuning_timer.function = sdhci_tuning_timer;
 	}
 
+	sdhci_init(host, 0);
+
 	ret = request_irq(host->irq, sdhci_irq, IRQF_SHARED,
 		mmc_hostname(mmc), host);
 	if (ret) {
@@ -3182,8 +3184,6 @@ int sdhci_add_host(struct sdhci_host *host)
 		goto untasklet;
 	}
 
-	sdhci_init(host, 0);
-
 #ifdef CONFIG_MMC_DEBUG
 	sdhci_dumpregs(host);
 #endif
-- 
1.7.9.5




From b32955 at freescale.com  Fri Jul  5 02:12:26 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Fri, 5 Jul 2013 14:12:26 +0800
Subject: [PATCH v3 0/6] serial: imx: add DMA support for imx6
Message-ID: <1373004752-21302-1-git-send-email-b32955@freescale.com>

(1) This patch set adds the DMA support for the imx serial driver.
    The uart with the dma support is usually used by the Bluetooth.

    For the firmware's limit, i only enable the DMA for imx6 serials.
    If we have proper firmware for imx53 (or other chips), we can also
    enable the DMA for it.

(2) We only enable the DMA support when the following are meet:

    [1] The uart port supports the hardware flow control(CTS/RTS).
      (Some uart port does not support the CTS/RTS.)

    [2] The application enables the CTS/RTS.

    [3] The Soc is imx6 serials.
      For the sdma's firmware limit, we do not support the DMA except
      the imx6 platform.

    [4] The uart is not used as a console.


(3) Tested this patch set by:
	connecting a imx6q-arm2 board(DTE) with a imx53 board(DCE).

v2 --> v3:
	[0] add a new patch to fix the RTS/CTS pad name issue.
	[1] rename the uart DTE pinctrl, remove the "dte" from the pinctrl.
	[2] add a similar UART DTE pinctrl for IMX6DL.
	[3] move the "fsl,imx6q-uart" to the first of the compatible table.

v1 --> v2:
	[0] use the "fsl,imx6q-uart" as the new compatible value.
	[1] move dma_is_inited to imx_uart_dma_init();
	    move dma_is_enabled to imx_enable_dma();
	[2] move imx_disable_dma() to the front place of the imx_shutdown(),
	    just before calls the imx_uart_dma_exit().
	[3] misc    
	

Huang Shijie (6):
  serial: imx: distinguish the imx6q uart from the others
  serial: imx: add DMA support for imx6q
  ARM: dts: imx6sl: add "fsl,imx6q-uart" for uart compatible
  ARM: dts: imx6q{dl}: fix the wrong RTS/CTS pad name
  ARM: dts: imx6q{dl}: add a DTE uart pinctrl for uart2
  ARM: dts: enable the uart2 for imx6q-arm2

 arch/arm/boot/dts/imx6dl-pinfunc.h |   88 ++++----
 arch/arm/boot/dts/imx6dl.dtsi      |    9 +
 arch/arm/boot/dts/imx6q-arm2.dts   |   10 +
 arch/arm/boot/dts/imx6q-pinfunc.h  |   88 ++++----
 arch/arm/boot/dts/imx6q.dtsi       |    9 +
 arch/arm/boot/dts/imx6sl.dtsi      |   15 +-
 drivers/tty/serial/imx.c           |  422 +++++++++++++++++++++++++++++++++++-
 7 files changed, 541 insertions(+), 100 deletions(-)




From b32955 at freescale.com  Fri Jul  5 02:12:28 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Fri, 5 Jul 2013 14:12:28 +0800
Subject: [PATCH v3 2/6] serial: imx: add DMA support for imx6q
In-Reply-To: <1373004752-21302-1-git-send-email-b32955@freescale.com>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>
Message-ID: <1373004752-21302-3-git-send-email-b32955@freescale.com>

We only enable the DMA support when the following are meet:

  [1] The uart port supports the hardware flow control(CTS/RTS).
      (Some uart port does not support the CTS/RTS.)

  [2] The application enables the CTS/RTS.

  [3] The Soc is imx6q.
      For the sdma's firmware limit, we do not support the DMA except
      the imx6q platform.

  [4] The uart is not used as a console.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 drivers/tty/serial/imx.c |  405 +++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 400 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index a9643ef..d04a09e 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -49,9 +49,11 @@
 #include <linux/of_device.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/io.h>
+#include <linux/dma-mapping.h>
 
 #include <asm/irq.h>
 #include <linux/platform_data/serial-imx.h>
+#include <linux/platform_data/dma-imx.h>
 
 /* Register definitions */
 #define URXD0 0x0  /* Receiver Register */
@@ -83,6 +85,7 @@
 #define UCR1_ADBR	(1<<14) /* Auto detect baud rate */
 #define UCR1_TRDYEN	(1<<13) /* Transmitter ready interrupt enable */
 #define UCR1_IDEN	(1<<12) /* Idle condition interrupt */
+#define UCR1_ICD_REG(x) (((x) & 3) << 10) /* idle condition detect */
 #define UCR1_RRDYEN	(1<<9)	/* Recv ready interrupt enable */
 #define UCR1_RDMAEN	(1<<8)	/* Recv ready DMA enable */
 #define UCR1_IREN	(1<<7)	/* Infrared interface enable */
@@ -91,6 +94,7 @@
 #define UCR1_SNDBRK	(1<<4)	/* Send break */
 #define UCR1_TDMAEN	(1<<3)	/* Transmitter ready DMA enable */
 #define IMX1_UCR1_UARTCLKEN (1<<2) /* UART clock enabled, i.mx1 only */
+#define UCR1_ATDMAEN    (1<<2)  /* Aging DMA Timer Enable */
 #define UCR1_DOZE	(1<<1)	/* Doze */
 #define UCR1_UARTEN	(1<<0)	/* UART enabled */
 #define UCR2_ESCI	(1<<15)	/* Escape seq interrupt enable */
@@ -126,6 +130,7 @@
 #define UCR4_ENIRI	(1<<8)	/* Serial infrared interrupt enable */
 #define UCR4_WKEN	(1<<7)	/* Wake interrupt enable */
 #define UCR4_REF16	(1<<6)	/* Ref freq 16 MHz */
+#define UCR4_IDDMAEN    (1<<6)  /* DMA IDLE Condition Detected */
 #define UCR4_IRSC	(1<<5)	/* IR special case */
 #define UCR4_TCEN	(1<<3)	/* Transmit complete interrupt enable */
 #define UCR4_BKEN	(1<<2)	/* Break condition interrupt enable */
@@ -210,6 +215,19 @@ struct imx_port {
 	struct clk		*clk_ipg;
 	struct clk		*clk_per;
 	const struct imx_uart_data *devdata;
+
+	/* DMA fields */
+	unsigned int		dma_is_inited:1;
+	unsigned int		dma_is_enabled:1;
+	unsigned int		dma_is_rxing:1;
+	unsigned int		dma_is_txing:1;
+	struct dma_chan		*dma_chan_rx, *dma_chan_tx;
+	struct scatterlist	rx_sgl, tx_sgl[2];
+	void			*rx_buf;
+	unsigned int		rx_bytes, tx_bytes;
+	struct work_struct	tsk_dma_rx, tsk_dma_tx;
+	unsigned int		dma_tx_nents;
+	wait_queue_head_t	dma_wait;
 };
 
 struct imx_port_ucrs {
@@ -400,6 +418,13 @@ static void imx_stop_tx(struct uart_port *port)
 		return;
 	}
 
+	/*
+	 * We are maybe in the SMP context, so if the DMA TX thread is running
+	 * on other cpu, we have to wait for it to finish.
+	 */
+	if (sport->dma_is_enabled && sport->dma_is_txing)
+		return;
+
 	temp = readl(sport->port.membase + UCR1);
 	writel(temp & ~UCR1_TXMPTYEN, sport->port.membase + UCR1);
 }
@@ -412,6 +437,13 @@ static void imx_stop_rx(struct uart_port *port)
 	struct imx_port *sport = (struct imx_port *)port;
 	unsigned long temp;
 
+	/*
+	 * We are maybe in the SMP context, so if the DMA TX thread is running
+	 * on other cpu, we have to wait for it to finish.
+	 */
+	if (sport->dma_is_enabled && sport->dma_is_rxing)
+		return;
+
 	temp = readl(sport->port.membase + UCR2);
 	writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
 }
@@ -447,6 +479,95 @@ static inline void imx_transmit_buffer(struct imx_port *sport)
 		imx_stop_tx(&sport->port);
 }
 
+static void dma_tx_callback(void *data)
+{
+	struct imx_port *sport = data;
+	struct scatterlist *sgl = &sport->tx_sgl[0];
+	struct circ_buf *xmit = &sport->port.state->xmit;
+	unsigned long flags;
+
+	dma_unmap_sg(sport->port.dev, sgl, sport->dma_tx_nents, DMA_TO_DEVICE);
+
+	sport->dma_is_txing = 0;
+
+	/* update the stat */
+	spin_lock_irqsave(&sport->port.lock, flags);
+	xmit->tail = (xmit->tail + sport->tx_bytes) & (UART_XMIT_SIZE - 1);
+	sport->port.icount.tx += sport->tx_bytes;
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+
+	dev_dbg(sport->port.dev, "we finish the TX DMA.\n");
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(&sport->port);
+
+	if (waitqueue_active(&sport->dma_wait)) {
+		wake_up(&sport->dma_wait);
+		dev_dbg(sport->port.dev, "exit in %s.\n", __func__);
+		return;
+	}
+
+	schedule_work(&sport->tsk_dma_tx);
+}
+
+static void dma_tx_work(struct work_struct *w)
+{
+	struct imx_port *sport = container_of(w, struct imx_port, tsk_dma_tx);
+	struct circ_buf *xmit = &sport->port.state->xmit;
+	struct scatterlist *sgl = sport->tx_sgl;
+	struct dma_async_tx_descriptor *desc;
+	struct dma_chan	*chan = sport->dma_chan_tx;
+	struct device *dev = sport->port.dev;
+	enum dma_status status;
+	unsigned long flags;
+	int ret;
+
+	status = chan->device->device_tx_status(chan, (dma_cookie_t)0, NULL);
+	if (DMA_IN_PROGRESS == status)
+		return;
+
+	spin_lock_irqsave(&sport->port.lock, flags);
+	sport->tx_bytes = uart_circ_chars_pending(xmit);
+	if (sport->tx_bytes == 0) {
+		spin_unlock_irqrestore(&sport->port.lock, flags);
+		return;
+	}
+
+	if (xmit->tail > xmit->head) {
+		sport->dma_tx_nents = 2;
+		sg_init_table(sgl, 2);
+		sg_set_buf(sgl, xmit->buf + xmit->tail,
+				UART_XMIT_SIZE - xmit->tail);
+		sg_set_buf(sgl + 1, xmit->buf, xmit->head);
+	} else {
+		sport->dma_tx_nents = 1;
+		sg_init_one(sgl, xmit->buf + xmit->tail, sport->tx_bytes);
+	}
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+
+	ret = dma_map_sg(dev, sgl, sport->dma_tx_nents, DMA_TO_DEVICE);
+	if (ret == 0) {
+		dev_err(dev, "DMA mapping error for TX.\n");
+		return;
+	}
+	desc = dmaengine_prep_slave_sg(chan, sgl, sport->dma_tx_nents,
+					DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT);
+	if (!desc) {
+		dev_err(dev, "We cannot prepare for the TX slave dma!\n");
+		return;
+	}
+	desc->callback = dma_tx_callback;
+	desc->callback_param = sport;
+
+	dev_dbg(dev, "TX: prepare to send %lu bytes by DMA.\n",
+			uart_circ_chars_pending(xmit));
+	/* fire it */
+	sport->dma_is_txing = 1;
+	dmaengine_submit(desc);
+	dma_async_issue_pending(chan);
+	return;
+}
+
 /*
  * interrupts disabled on entry
  */
@@ -473,8 +594,10 @@ static void imx_start_tx(struct uart_port *port)
 	temp |= UCR4_OREN;
 	writel(temp, sport->port.membase + UCR4);
 
-	temp = readl(sport->port.membase + UCR1);
-	writel(temp | UCR1_TXMPTYEN, sport->port.membase + UCR1);
+	if (!sport->dma_is_enabled) {
+		temp = readl(sport->port.membase + UCR1);
+		writel(temp | UCR1_TXMPTYEN, sport->port.membase + UCR1);
+	}
 
 	if (USE_IRDA(sport)) {
 		temp = readl(sport->port.membase + UCR1);
@@ -486,6 +609,15 @@ static void imx_start_tx(struct uart_port *port)
 		writel(temp, sport->port.membase + UCR4);
 	}
 
+	if (sport->dma_is_enabled) {
+		/*
+		 * We may in the interrupt context, so arise a work_struct to
+		 * do the real job.
+		 */
+		schedule_work(&sport->tsk_dma_tx);
+		return;
+	}
+
 	if (readl(sport->port.membase + uts_reg(sport)) & UTS_TXEMPTY)
 		imx_transmit_buffer(sport);
 }
@@ -601,6 +733,28 @@ out:
 	return IRQ_HANDLED;
 }
 
+/*
+ * If the RXFIFO is filled with some data, and then we
+ * arise a DMA operation to receive them.
+ */
+static void imx_dma_rxint(struct imx_port *sport)
+{
+	unsigned long temp;
+
+	temp = readl(sport->port.membase + USR2);
+	if ((temp & USR2_RDR) && !sport->dma_is_rxing) {
+		sport->dma_is_rxing = 1;
+
+		/* disable the `Recerver Ready Interrrupt` */
+		temp = readl(sport->port.membase + UCR1);
+		temp &= ~(UCR1_RRDYEN);
+		writel(temp, sport->port.membase + UCR1);
+
+		/* tell the DMA to receive the data. */
+		schedule_work(&sport->tsk_dma_rx);
+	}
+}
+
 static irqreturn_t imx_int(int irq, void *dev_id)
 {
 	struct imx_port *sport = dev_id;
@@ -609,8 +763,12 @@ static irqreturn_t imx_int(int irq, void *dev_id)
 
 	sts = readl(sport->port.membase + USR1);
 
-	if (sts & USR1_RRDY)
-		imx_rxint(irq, dev_id);
+	if (sts & USR1_RRDY) {
+		if (sport->dma_is_enabled)
+			imx_dma_rxint(sport);
+		else
+			imx_rxint(irq, dev_id);
+	}
 
 	if (sts & USR1_TRDY &&
 			readl(sport->port.membase + UCR1) & UCR1_TXMPTYEN)
@@ -667,7 +825,8 @@ static void imx_set_mctrl(struct uart_port *port, unsigned int mctrl)
 	temp = readl(sport->port.membase + UCR2) & ~UCR2_CTS;
 
 	if (mctrl & TIOCM_RTS)
-		temp |= UCR2_CTS;
+		if (!sport->dma_is_enabled)
+			temp |= UCR2_CTS;
 
 	writel(temp, sport->port.membase + UCR2);
 }
@@ -706,6 +865,226 @@ static int imx_setup_ufcr(struct imx_port *sport, unsigned int mode)
 	return 0;
 }
 
+#define RX_BUF_SIZE	(PAGE_SIZE)
+static int start_rx_dma(struct imx_port *sport);
+static void dma_rx_work(struct work_struct *w)
+{
+	struct imx_port *sport = container_of(w, struct imx_port, tsk_dma_rx);
+	struct tty_port *port = &sport->port.state->port;
+
+	if (sport->rx_bytes) {
+		tty_insert_flip_string(port, sport->rx_buf, sport->rx_bytes);
+		tty_flip_buffer_push(port);
+		sport->rx_bytes = 0;
+	}
+
+	if (sport->dma_is_rxing)
+		start_rx_dma(sport);
+}
+
+static void imx_rx_dma_done(struct imx_port *sport)
+{
+	unsigned long temp;
+
+	/* Enable this interrupt when the RXFIFO is empty. */
+	temp = readl(sport->port.membase + UCR1);
+	temp |= UCR1_RRDYEN;
+	writel(temp, sport->port.membase + UCR1);
+
+	sport->dma_is_rxing = 0;
+
+	/* Is the shutdown waiting for us? */
+	if (waitqueue_active(&sport->dma_wait))
+		wake_up(&sport->dma_wait);
+}
+
+/*
+ * There are three kinds of RX DMA interrupts(such as in the MX6Q):
+ *   [1] the RX DMA buffer is full.
+ *   [2] the Aging timer expires(wait for 8 bytes long)
+ *   [3] the Idle Condition Detect(enabled the UCR4_IDDMAEN).
+ *
+ * The [2] is trigger when a character was been sitting in the FIFO
+ * meanwhile [3] can wait for 32 bytes long when the RX line is
+ * on IDLE state and RxFIFO is empty.
+ */
+static void dma_rx_callback(void *data)
+{
+	struct imx_port *sport = data;
+	struct dma_chan	*chan = sport->dma_chan_rx;
+	struct scatterlist *sgl = &sport->rx_sgl;
+	struct dma_tx_state state;
+	enum dma_status status;
+	unsigned int count;
+
+	/* unmap it first */
+	dma_unmap_sg(sport->port.dev, sgl, 1, DMA_FROM_DEVICE);
+
+	status = chan->device->device_tx_status(chan, (dma_cookie_t)0, &state);
+	count = RX_BUF_SIZE - state.residue;
+	dev_dbg(sport->port.dev, "We get %d bytes.\n", count);
+
+	if (count) {
+		sport->rx_bytes = count;
+		schedule_work(&sport->tsk_dma_rx);
+	} else
+		imx_rx_dma_done(sport);
+}
+
+static int start_rx_dma(struct imx_port *sport)
+{
+	struct scatterlist *sgl = &sport->rx_sgl;
+	struct dma_chan	*chan = sport->dma_chan_rx;
+	struct device *dev = sport->port.dev;
+	struct dma_async_tx_descriptor *desc;
+	int ret;
+
+	sg_init_one(sgl, sport->rx_buf, RX_BUF_SIZE);
+	ret = dma_map_sg(dev, sgl, 1, DMA_FROM_DEVICE);
+	if (ret == 0) {
+		dev_err(dev, "DMA mapping error for RX.\n");
+		return -EINVAL;
+	}
+	desc = dmaengine_prep_slave_sg(chan, sgl, 1, DMA_DEV_TO_MEM,
+					DMA_PREP_INTERRUPT);
+	if (!desc) {
+		dev_err(dev, "We cannot prepare for the RX slave dma!\n");
+		return -EINVAL;
+	}
+	desc->callback = dma_rx_callback;
+	desc->callback_param = sport;
+
+	dev_dbg(dev, "RX: prepare for the DMA.\n");
+	dmaengine_submit(desc);
+	dma_async_issue_pending(chan);
+	return 0;
+}
+
+static void imx_uart_dma_exit(struct imx_port *sport)
+{
+	if (sport->dma_chan_rx) {
+		dma_release_channel(sport->dma_chan_rx);
+		sport->dma_chan_rx = NULL;
+
+		kfree(sport->rx_buf);
+		sport->rx_buf = NULL;
+	}
+
+	if (sport->dma_chan_tx) {
+		dma_release_channel(sport->dma_chan_tx);
+		sport->dma_chan_tx = NULL;
+	}
+
+	sport->dma_is_inited = 0;
+}
+
+static int imx_uart_dma_init(struct imx_port *sport)
+{
+	struct dma_slave_config slave_config;
+	struct device *dev = sport->port.dev;
+	int ret;
+
+	/* Prepare for RX : */
+	sport->dma_chan_rx = dma_request_slave_channel(dev, "rx");
+	if (!sport->dma_chan_rx) {
+		dev_dbg(dev, "cannot get the DMA channel.\n");
+		ret = -EINVAL;
+		goto err;
+	}
+
+	slave_config.direction = DMA_DEV_TO_MEM;
+	slave_config.src_addr = sport->port.mapbase + URXD0;
+	slave_config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	slave_config.src_maxburst = RXTL;
+	ret = dmaengine_slave_config(sport->dma_chan_rx, &slave_config);
+	if (ret) {
+		dev_err(dev, "error in RX dma configuration.\n");
+		goto err;
+	}
+
+	sport->rx_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
+	if (!sport->rx_buf) {
+		dev_err(dev, "cannot alloc DMA buffer.\n");
+		ret = -ENOMEM;
+		goto err;
+	}
+	sport->rx_bytes = 0;
+
+	/* Prepare for TX : */
+	sport->dma_chan_tx = dma_request_slave_channel(dev, "tx");
+	if (!sport->dma_chan_tx) {
+		dev_err(dev, "cannot get the TX DMA channel!\n");
+		ret = -EINVAL;
+		goto err;
+	}
+
+	slave_config.direction = DMA_MEM_TO_DEV;
+	slave_config.dst_addr = sport->port.mapbase + URTX0;
+	slave_config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	slave_config.dst_maxburst = TXTL;
+	ret = dmaengine_slave_config(sport->dma_chan_tx, &slave_config);
+	if (ret) {
+		dev_err(dev, "error in TX dma configuration.");
+		goto err;
+	}
+
+	sport->dma_is_inited = 1;
+
+	return 0;
+err:
+	imx_uart_dma_exit(sport);
+	return ret;
+}
+
+static void imx_enable_dma(struct imx_port *sport)
+{
+	unsigned long temp;
+	struct tty_port *port = &sport->port.state->port;
+
+	port->low_latency = 1;
+	INIT_WORK(&sport->tsk_dma_tx, dma_tx_work);
+	INIT_WORK(&sport->tsk_dma_rx, dma_rx_work);
+	init_waitqueue_head(&sport->dma_wait);
+
+	/* set UCR1 */
+	temp = readl(sport->port.membase + UCR1);
+	temp |= UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN |
+		/* wait for 32 idle frames for IDDMA interrupt */
+		UCR1_ICD_REG(3);
+	writel(temp, sport->port.membase + UCR1);
+
+	/* set UCR4 */
+	temp = readl(sport->port.membase + UCR4);
+	temp |= UCR4_IDDMAEN;
+	writel(temp, sport->port.membase + UCR4);
+
+	sport->dma_is_enabled = 1;
+}
+
+static void imx_disable_dma(struct imx_port *sport)
+{
+	unsigned long temp;
+	struct tty_port *port = &sport->port.state->port;
+
+	/* clear UCR1 */
+	temp = readl(sport->port.membase + UCR1);
+	temp &= ~(UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN);
+	writel(temp, sport->port.membase + UCR1);
+
+	/* clear UCR2 */
+	temp = readl(sport->port.membase + UCR2);
+	temp &= ~(UCR2_CTSC | UCR2_CTS);
+	writel(temp, sport->port.membase + UCR2);
+
+	/* clear UCR4 */
+	temp = readl(sport->port.membase + UCR4);
+	temp &= ~UCR4_IDDMAEN;
+	writel(temp, sport->port.membase + UCR4);
+
+	sport->dma_is_enabled = 0;
+	port->low_latency = 0;
+}
+
 /* half the RX buffer size */
 #define CTSTL 16
 
@@ -870,6 +1249,15 @@ static void imx_shutdown(struct uart_port *port)
 	unsigned long temp;
 	unsigned long flags;
 
+	if (sport->dma_is_enabled) {
+		/* We have to wait for the DMA to finish. */
+		wait_event(sport->dma_wait,
+			!sport->dma_is_rxing && !sport->dma_is_txing);
+		imx_stop_rx(port);
+		imx_disable_dma(sport);
+		imx_uart_dma_exit(sport);
+	}
+
 	spin_lock_irqsave(&sport->port.lock, flags);
 	temp = readl(sport->port.membase + UCR2);
 	temp &= ~(UCR2_TXEN);
@@ -956,6 +1344,11 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 		if (sport->have_rtscts) {
 			ucr2 &= ~UCR2_IRTS;
 			ucr2 |= UCR2_CTSC;
+
+			/* Can we enable the DMA support? */
+			if (is_imx6q_uart(sport) && !uart_console(port)
+				&& !sport->dma_is_inited)
+				imx_uart_dma_init(sport);
 		} else {
 			termios->c_cflag &= ~CRTSCTS;
 		}
@@ -1069,6 +1462,8 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 	if (UART_ENABLE_MS(&sport->port, termios->c_cflag))
 		imx_enable_ms(&sport->port);
 
+	if (sport->dma_is_inited && !sport->dma_is_enabled)
+		imx_enable_dma(sport);
 	spin_unlock_irqrestore(&sport->port.lock, flags);
 }
 
-- 
1.7.1




From b32955 at freescale.com  Fri Jul  5 02:12:27 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Fri, 5 Jul 2013 14:12:27 +0800
Subject: [PATCH v3 1/6] serial: imx: distinguish the imx6q uart from the others
In-Reply-To: <1373004752-21302-1-git-send-email-b32955@freescale.com>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>
Message-ID: <1373004752-21302-2-git-send-email-b32955@freescale.com>

We will add the DMA support for the imx uart. For the firmware's limit,
only the imx6 serial chips (including the imx6q, imx6dl, imx6sl) can
support the DMA.

This patch adds the necessary macro and helper to distinguish the
imx6q uart from the other imx uart. Other chips can use the "fsl,imx6q-uart"
to enable the DMA support.

This patch also replaces the check "is_imx21_uart()" with "!is_imx1_uart()".

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 drivers/tty/serial/imx.c |   17 +++++++++++++++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 48bace0..a9643ef 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -187,6 +187,7 @@
 enum imx_uart_type {
 	IMX1_UART,
 	IMX21_UART,
+	IMX6Q_UART,
 };
 
 /* device type dependent stuff */
@@ -232,6 +233,10 @@ static struct imx_uart_data imx_uart_devdata[] = {
 		.uts_reg = IMX21_UTS,
 		.devtype = IMX21_UART,
 	},
+	[IMX6Q_UART] = {
+		.uts_reg = IMX21_UTS,
+		.devtype = IMX6Q_UART,
+	},
 };
 
 static struct platform_device_id imx_uart_devtype[] = {
@@ -242,12 +247,16 @@ static struct platform_device_id imx_uart_devtype[] = {
 		.name = "imx21-uart",
 		.driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX21_UART],
 	}, {
+		.name = "imx6q-uart",
+		.driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX6Q_UART],
+	}, {
 		/* sentinel */
 	}
 };
 MODULE_DEVICE_TABLE(platform, imx_uart_devtype);
 
 static struct of_device_id imx_uart_dt_ids[] = {
+	{ .compatible = "fsl,imx6q-uart", .data = &imx_uart_devdata[IMX6Q_UART], },
 	{ .compatible = "fsl,imx1-uart", .data = &imx_uart_devdata[IMX1_UART], },
 	{ .compatible = "fsl,imx21-uart", .data = &imx_uart_devdata[IMX21_UART], },
 	{ /* sentinel */ }
@@ -269,6 +278,10 @@ static inline int is_imx21_uart(struct imx_port *sport)
 	return sport->devdata->devtype == IMX21_UART;
 }
 
+static inline int is_imx6q_uart(struct imx_port *sport)
+{
+	return sport->devdata->devtype == IMX6Q_UART;
+}
 /*
  * Save and restore functions for UCR1, UCR2 and UCR3 registers
  */
@@ -801,7 +814,7 @@ static int imx_startup(struct uart_port *port)
 		}
 	}
 
-	if (is_imx21_uart(sport)) {
+	if (!is_imx1_uart(sport)) {
 		temp = readl(sport->port.membase + UCR3);
 		temp |= IMX21_UCR3_RXDMUXSEL;
 		writel(temp, sport->port.membase + UCR3);
@@ -1044,7 +1057,7 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 	writel(num, sport->port.membase + UBIR);
 	writel(denom, sport->port.membase + UBMR);
 
-	if (is_imx21_uart(sport))
+	if (!is_imx1_uart(sport))
 		writel(sport->port.uartclk / div / 1000,
 				sport->port.membase + IMX21_ONEMS);
 
-- 
1.7.1




From b32955 at freescale.com  Fri Jul  5 02:12:29 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Fri, 5 Jul 2013 14:12:29 +0800
Subject: [PATCH v3 3/6] ARM: dts: imx6sl: add "fsl,
 imx6q-uart" for uart compatible
In-Reply-To: <1373004752-21302-1-git-send-email-b32955@freescale.com>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>
Message-ID: <1373004752-21302-4-git-send-email-b32955@freescale.com>

In order to enable the DMA for some uart port in imx6sl, we add the
"fsl,imx6q-uart" to the uart's compatible property.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6sl.dtsi |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 9138c67..0a297af 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -152,7 +152,8 @@
 				};
 
 				uart5: serial at 02018000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02018000 0x4000>;
 					interrupts = <0 30 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -162,7 +163,8 @@
 				};
 
 				uart1: serial at 02020000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02020000 0x4000>;
 					interrupts = <0 26 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -172,7 +174,8 @@
 				};
 
 				uart2: serial at 02024000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02024000 0x4000>;
 					interrupts = <0 27 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -209,7 +212,8 @@
 				};
 
 				uart3: serial at 02034000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02034000 0x4000>;
 					interrupts = <0 28 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -219,7 +223,8 @@
 				};
 
 				uart4: serial at 02038000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02038000 0x4000>;
 					interrupts = <0 29 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
-- 
1.7.1




From b32955 at freescale.com  Fri Jul  5 02:12:31 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Fri, 5 Jul 2013 14:12:31 +0800
Subject: [PATCH v3 5/6] ARM: dts: imx6q{dl}: add a DTE uart pinctrl for uart2
In-Reply-To: <1373004752-21302-1-git-send-email-b32955@freescale.com>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>
Message-ID: <1373004752-21302-6-git-send-email-b32955@freescale.com>

In the arm2 board, the UART2 works in the dte mode.
So add a pinctrl for both the imx6q{dl} boards.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6dl.dtsi |    9 +++++++++
 arch/arm/boot/dts/imx6q.dtsi  |    9 +++++++++
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 2b5628d..5f61722 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -223,6 +223,15 @@
 							MX6DL_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
 						>;
 					};
+
+					pinctrl_uart2_2: uart2grp-2 { /* DTE mode */
+						fsl,pins = <
+							MX6DL_PAD_EIM_D26__UART2_RX_DATA 0x1b0b1
+							MX6DL_PAD_EIM_D27__UART2_TX_DATA 0x1b0b1
+							MX6DL_PAD_EIM_D28__UART2_CTS_B   0x1b0b1
+							MX6DL_PAD_EIM_D29__UART2_RTS_B	 0x1b0b1
+						>;
+					};
 				};
 
 				uart4 {
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 6f4d6ab..4ac3df5 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -266,6 +266,15 @@
 							MX6Q_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
 						>;
 					};
+
+					pinctrl_uart2_2: uart2grp-2 { /* DTE mode */
+						fsl,pins = <
+							MX6Q_PAD_EIM_D26__UART2_RX_DATA 0x1b0b1
+							MX6Q_PAD_EIM_D27__UART2_TX_DATA 0x1b0b1
+							MX6Q_PAD_EIM_D28__UART2_CTS_B	0x1b0b1
+							MX6Q_PAD_EIM_D29__UART2_RTS_B	0x1b0b1
+						>;
+					};
 				};
 
 				uart4 {
-- 
1.7.1




From b32955 at freescale.com  Fri Jul  5 02:12:30 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Fri, 5 Jul 2013 14:12:30 +0800
Subject: [PATCH v3 4/6] ARM: dts: imx6q{dl}: fix the wrong RTS/CTS pad name
In-Reply-To: <1373004752-21302-1-git-send-email-b32955@freescale.com>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>
Message-ID: <1373004752-21302-5-git-send-email-b32955@freescale.com>

There is something wrong with the RTS/CTS pads:
  The RTS pad is assigned with the CTS's value;
  while the CTS pad is assigned with the RTS's value.

In order to fix it, this patch exchanges the RTS/CTS pad name.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6dl-pinfunc.h |   88 ++++++++++++++++++------------------
 arch/arm/boot/dts/imx6q-pinfunc.h  |   88 ++++++++++++++++++------------------
 2 files changed, 88 insertions(+), 88 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl-pinfunc.h b/arch/arm/boot/dts/imx6dl-pinfunc.h
index 9aab950..4840a73 100644
--- a/arch/arm/boot/dts/imx6dl-pinfunc.h
+++ b/arch/arm/boot/dts/imx6dl-pinfunc.h
@@ -54,26 +54,26 @@
 #define MX6DL_PAD_CSI0_DAT15__ARM_TRACE12          0x060 0x374 0x000 0x7 0x0
 #define MX6DL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16     0x064 0x378 0x000 0x0 0x0
 #define MX6DL_PAD_CSI0_DAT16__EIM_DATA12           0x064 0x378 0x000 0x1 0x0
-#define MX6DL_PAD_CSI0_DAT16__UART4_RTS_B          0x064 0x378 0x910 0x3 0x0
-#define MX6DL_PAD_CSI0_DAT16__UART4_CTS_B          0x064 0x378 0x000 0x3 0x0
+#define MX6DL_PAD_CSI0_DAT16__UART4_CTS_B          0x064 0x378 0x910 0x3 0x0
+#define MX6DL_PAD_CSI0_DAT16__UART4_RTS_B          0x064 0x378 0x000 0x3 0x0
 #define MX6DL_PAD_CSI0_DAT16__GPIO6_IO02           0x064 0x378 0x000 0x5 0x0
 #define MX6DL_PAD_CSI0_DAT16__ARM_TRACE13          0x064 0x378 0x000 0x7 0x0
 #define MX6DL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17     0x068 0x37c 0x000 0x0 0x0
 #define MX6DL_PAD_CSI0_DAT17__EIM_DATA13           0x068 0x37c 0x000 0x1 0x0
-#define MX6DL_PAD_CSI0_DAT17__UART4_CTS_B          0x068 0x37c 0x000 0x3 0x0
-#define MX6DL_PAD_CSI0_DAT17__UART4_RTS_B          0x068 0x37c 0x910 0x3 0x1
+#define MX6DL_PAD_CSI0_DAT17__UART4_RTS_B          0x068 0x37c 0x000 0x3 0x0
+#define MX6DL_PAD_CSI0_DAT17__UART4_CTS_B          0x068 0x37c 0x910 0x3 0x1
 #define MX6DL_PAD_CSI0_DAT17__GPIO6_IO03           0x068 0x37c 0x000 0x5 0x0
 #define MX6DL_PAD_CSI0_DAT17__ARM_TRACE14          0x068 0x37c 0x000 0x7 0x0
 #define MX6DL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18     0x06c 0x380 0x000 0x0 0x0
 #define MX6DL_PAD_CSI0_DAT18__EIM_DATA14           0x06c 0x380 0x000 0x1 0x0
-#define MX6DL_PAD_CSI0_DAT18__UART5_RTS_B          0x06c 0x380 0x918 0x3 0x0
-#define MX6DL_PAD_CSI0_DAT18__UART5_CTS_B          0x06c 0x380 0x000 0x3 0x0
+#define MX6DL_PAD_CSI0_DAT18__UART5_CTS_B          0x06c 0x380 0x918 0x3 0x0
+#define MX6DL_PAD_CSI0_DAT18__UART5_RTS_B          0x06c 0x380 0x000 0x3 0x0
 #define MX6DL_PAD_CSI0_DAT18__GPIO6_IO04           0x06c 0x380 0x000 0x5 0x0
 #define MX6DL_PAD_CSI0_DAT18__ARM_TRACE15          0x06c 0x380 0x000 0x7 0x0
 #define MX6DL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19     0x070 0x384 0x000 0x0 0x0
 #define MX6DL_PAD_CSI0_DAT19__EIM_DATA15           0x070 0x384 0x000 0x1 0x0
-#define MX6DL_PAD_CSI0_DAT19__UART5_CTS_B          0x070 0x384 0x000 0x3 0x0
-#define MX6DL_PAD_CSI0_DAT19__UART5_RTS_B          0x070 0x384 0x918 0x3 0x1
+#define MX6DL_PAD_CSI0_DAT19__UART5_RTS_B          0x070 0x384 0x000 0x3 0x0
+#define MX6DL_PAD_CSI0_DAT19__UART5_CTS_B          0x070 0x384 0x918 0x3 0x1
 #define MX6DL_PAD_CSI0_DAT19__GPIO6_IO05           0x070 0x384 0x000 0x5 0x0
 #define MX6DL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04      0x074 0x388 0x000 0x0 0x0
 #define MX6DL_PAD_CSI0_DAT4__EIM_DATA02            0x074 0x388 0x000 0x1 0x0
@@ -376,8 +376,8 @@
 #define MX6DL_PAD_EIM_D19__ECSPI1_SS1              0x150 0x520 0x7e8 0x1 0x1
 #define MX6DL_PAD_EIM_D19__IPU1_DI0_PIN08          0x150 0x520 0x000 0x2 0x0
 #define MX6DL_PAD_EIM_D19__IPU1_CSI1_DATA16        0x150 0x520 0x8a0 0x3 0x1
-#define MX6DL_PAD_EIM_D19__UART1_CTS_B             0x150 0x520 0x000 0x4 0x0
-#define MX6DL_PAD_EIM_D19__UART1_RTS_B             0x150 0x520 0x8f8 0x4 0x0
+#define MX6DL_PAD_EIM_D19__UART1_RTS_B             0x150 0x520 0x000 0x4 0x0
+#define MX6DL_PAD_EIM_D19__UART1_CTS_B             0x150 0x520 0x8f8 0x4 0x0
 #define MX6DL_PAD_EIM_D19__GPIO3_IO19              0x150 0x520 0x000 0x5 0x0
 #define MX6DL_PAD_EIM_D19__EPIT1_OUT               0x150 0x520 0x000 0x6 0x0
 #define MX6DL_PAD_EIM_D19__EPDC_DATA12             0x150 0x520 0x000 0x8 0x0
@@ -385,8 +385,8 @@
 #define MX6DL_PAD_EIM_D20__ECSPI4_SS0              0x154 0x524 0x808 0x1 0x0
 #define MX6DL_PAD_EIM_D20__IPU1_DI0_PIN16          0x154 0x524 0x000 0x2 0x0
 #define MX6DL_PAD_EIM_D20__IPU1_CSI1_DATA15        0x154 0x524 0x89c 0x3 0x1
-#define MX6DL_PAD_EIM_D20__UART1_RTS_B             0x154 0x524 0x8f8 0x4 0x1
-#define MX6DL_PAD_EIM_D20__UART1_CTS_B             0x154 0x524 0x000 0x4 0x0
+#define MX6DL_PAD_EIM_D20__UART1_CTS_B             0x154 0x524 0x8f8 0x4 0x1
+#define MX6DL_PAD_EIM_D20__UART1_RTS_B             0x154 0x524 0x000 0x4 0x0
 #define MX6DL_PAD_EIM_D20__GPIO3_IO20              0x154 0x524 0x000 0x5 0x0
 #define MX6DL_PAD_EIM_D20__EPIT2_OUT               0x154 0x524 0x000 0x6 0x0
 #define MX6DL_PAD_EIM_D21__EIM_DATA21              0x158 0x528 0x000 0x0 0x0
@@ -407,8 +407,8 @@
 #define MX6DL_PAD_EIM_D22__EPDC_SDCE6              0x15c 0x52c 0x000 0x8 0x0
 #define MX6DL_PAD_EIM_D23__EIM_DATA23              0x160 0x530 0x000 0x0 0x0
 #define MX6DL_PAD_EIM_D23__IPU1_DI0_D0_CS          0x160 0x530 0x000 0x1 0x0
-#define MX6DL_PAD_EIM_D23__UART3_CTS_B             0x160 0x530 0x000 0x2 0x0
-#define MX6DL_PAD_EIM_D23__UART3_RTS_B             0x160 0x530 0x908 0x2 0x0
+#define MX6DL_PAD_EIM_D23__UART3_RTS_B             0x160 0x530 0x000 0x2 0x0
+#define MX6DL_PAD_EIM_D23__UART3_CTS_B             0x160 0x530 0x908 0x2 0x0
 #define MX6DL_PAD_EIM_D23__UART1_DCD_B             0x160 0x530 0x000 0x3 0x0
 #define MX6DL_PAD_EIM_D23__IPU1_CSI1_DATA_EN       0x160 0x530 0x8b0 0x4 0x0
 #define MX6DL_PAD_EIM_D23__GPIO3_IO23              0x160 0x530 0x000 0x5 0x0
@@ -459,8 +459,8 @@
 #define MX6DL_PAD_EIM_D28__I2C1_SDA                0x174 0x544 0x86c 0x1 0x1
 #define MX6DL_PAD_EIM_D28__ECSPI4_MOSI             0x174 0x544 0x000 0x2 0x0
 #define MX6DL_PAD_EIM_D28__IPU1_CSI1_DATA12        0x174 0x544 0x890 0x3 0x1
-#define MX6DL_PAD_EIM_D28__UART2_CTS_B             0x174 0x544 0x000 0x4 0x0
-#define MX6DL_PAD_EIM_D28__UART2_RTS_B             0x174 0x544 0x900 0x4 0x0
+#define MX6DL_PAD_EIM_D28__UART2_RTS_B             0x174 0x544 0x000 0x4 0x0
+#define MX6DL_PAD_EIM_D28__UART2_CTS_B             0x174 0x544 0x900 0x4 0x0
 #define MX6DL_PAD_EIM_D28__GPIO3_IO28              0x174 0x544 0x000 0x5 0x0
 #define MX6DL_PAD_EIM_D28__IPU1_EXT_TRIG           0x174 0x544 0x000 0x6 0x0
 #define MX6DL_PAD_EIM_D28__IPU1_DI0_PIN13          0x174 0x544 0x000 0x7 0x0
@@ -468,8 +468,8 @@
 #define MX6DL_PAD_EIM_D29__EIM_DATA29              0x178 0x548 0x000 0x0 0x0
 #define MX6DL_PAD_EIM_D29__IPU1_DI1_PIN15          0x178 0x548 0x000 0x1 0x0
 #define MX6DL_PAD_EIM_D29__ECSPI4_SS0              0x178 0x548 0x808 0x2 0x1
-#define MX6DL_PAD_EIM_D29__UART2_RTS_B             0x178 0x548 0x900 0x4 0x1
-#define MX6DL_PAD_EIM_D29__UART2_CTS_B             0x178 0x548 0x000 0x4 0x0
+#define MX6DL_PAD_EIM_D29__UART2_CTS_B             0x178 0x548 0x900 0x4 0x1
+#define MX6DL_PAD_EIM_D29__UART2_RTS_B             0x178 0x548 0x000 0x4 0x0
 #define MX6DL_PAD_EIM_D29__GPIO3_IO29              0x178 0x548 0x000 0x5 0x0
 #define MX6DL_PAD_EIM_D29__IPU1_CSI1_VSYNC         0x178 0x548 0x8bc 0x6 0x0
 #define MX6DL_PAD_EIM_D29__IPU1_DI0_PIN14          0x178 0x548 0x000 0x7 0x0
@@ -478,8 +478,8 @@
 #define MX6DL_PAD_EIM_D30__IPU1_DISP1_DATA21       0x17c 0x54c 0x000 0x1 0x0
 #define MX6DL_PAD_EIM_D30__IPU1_DI0_PIN11          0x17c 0x54c 0x000 0x2 0x0
 #define MX6DL_PAD_EIM_D30__IPU1_CSI0_DATA03        0x17c 0x54c 0x000 0x3 0x0
-#define MX6DL_PAD_EIM_D30__UART3_CTS_B             0x17c 0x54c 0x000 0x4 0x0
-#define MX6DL_PAD_EIM_D30__UART3_RTS_B             0x17c 0x54c 0x908 0x4 0x1
+#define MX6DL_PAD_EIM_D30__UART3_RTS_B             0x17c 0x54c 0x000 0x4 0x0
+#define MX6DL_PAD_EIM_D30__UART3_CTS_B             0x17c 0x54c 0x908 0x4 0x1
 #define MX6DL_PAD_EIM_D30__GPIO3_IO30              0x17c 0x54c 0x000 0x5 0x0
 #define MX6DL_PAD_EIM_D30__USB_H1_OC               0x17c 0x54c 0x924 0x6 0x0
 #define MX6DL_PAD_EIM_D30__EPDC_SDOEZ              0x17c 0x54c 0x000 0x8 0x0
@@ -487,8 +487,8 @@
 #define MX6DL_PAD_EIM_D31__IPU1_DISP1_DATA20       0x180 0x550 0x000 0x1 0x0
 #define MX6DL_PAD_EIM_D31__IPU1_DI0_PIN12          0x180 0x550 0x000 0x2 0x0
 #define MX6DL_PAD_EIM_D31__IPU1_CSI0_DATA02        0x180 0x550 0x000 0x3 0x0
-#define MX6DL_PAD_EIM_D31__UART3_RTS_B             0x180 0x550 0x908 0x4 0x2
-#define MX6DL_PAD_EIM_D31__UART3_CTS_B             0x180 0x550 0x000 0x4 0x0
+#define MX6DL_PAD_EIM_D31__UART3_CTS_B             0x180 0x550 0x908 0x4 0x2
+#define MX6DL_PAD_EIM_D31__UART3_RTS_B             0x180 0x550 0x000 0x4 0x0
 #define MX6DL_PAD_EIM_D31__GPIO3_IO31              0x180 0x550 0x000 0x5 0x0
 #define MX6DL_PAD_EIM_D31__USB_H1_PWR              0x180 0x550 0x000 0x6 0x0
 #define MX6DL_PAD_EIM_D31__EPDC_SDCLK_P            0x180 0x550 0x000 0x8 0x0
@@ -610,8 +610,8 @@
 #define MX6DL_PAD_EIM_EB2__EPDC_DATA05             0x1cc 0x59c 0x000 0x8 0x0
 #define MX6DL_PAD_EIM_EB3__EIM_EB3_B               0x1d0 0x5a0 0x000 0x0 0x0
 #define MX6DL_PAD_EIM_EB3__ECSPI4_RDY              0x1d0 0x5a0 0x000 0x1 0x0
-#define MX6DL_PAD_EIM_EB3__UART3_RTS_B             0x1d0 0x5a0 0x908 0x2 0x3
-#define MX6DL_PAD_EIM_EB3__UART3_CTS_B             0x1d0 0x5a0 0x000 0x2 0x0
+#define MX6DL_PAD_EIM_EB3__UART3_CTS_B             0x1d0 0x5a0 0x908 0x2 0x3
+#define MX6DL_PAD_EIM_EB3__UART3_RTS_B             0x1d0 0x5a0 0x000 0x2 0x0
 #define MX6DL_PAD_EIM_EB3__UART1_RI_B              0x1d0 0x5a0 0x000 0x3 0x0
 #define MX6DL_PAD_EIM_EB3__IPU1_CSI1_HSYNC         0x1d0 0x5a0 0x8b4 0x4 0x1
 #define MX6DL_PAD_EIM_EB3__GPIO2_IO31              0x1d0 0x5a0 0x000 0x5 0x0
@@ -815,8 +815,8 @@
 #define MX6DL_PAD_KEY_COL4__IPU1_SISG4             0x254 0x63c 0x000 0x1 0x0
 #define MX6DL_PAD_KEY_COL4__USB_OTG_OC             0x254 0x63c 0x920 0x2 0x1
 #define MX6DL_PAD_KEY_COL4__KEY_COL4               0x254 0x63c 0x000 0x3 0x0
-#define MX6DL_PAD_KEY_COL4__UART5_RTS_B            0x254 0x63c 0x918 0x4 0x2
-#define MX6DL_PAD_KEY_COL4__UART5_CTS_B            0x254 0x63c 0x000 0x4 0x0
+#define MX6DL_PAD_KEY_COL4__UART5_CTS_B            0x254 0x63c 0x918 0x4 0x2
+#define MX6DL_PAD_KEY_COL4__UART5_RTS_B            0x254 0x63c 0x000 0x4 0x0
 #define MX6DL_PAD_KEY_COL4__GPIO4_IO14             0x254 0x63c 0x000 0x5 0x0
 #define MX6DL_PAD_KEY_ROW0__ECSPI1_MOSI            0x258 0x640 0x7e0 0x0 0x3
 #define MX6DL_PAD_KEY_ROW0__ENET_TX_DATA3          0x258 0x640 0x000 0x1 0x0
@@ -851,8 +851,8 @@
 #define MX6DL_PAD_KEY_ROW4__IPU1_SISG5             0x268 0x650 0x000 0x1 0x0
 #define MX6DL_PAD_KEY_ROW4__USB_OTG_PWR            0x268 0x650 0x000 0x2 0x0
 #define MX6DL_PAD_KEY_ROW4__KEY_ROW4               0x268 0x650 0x000 0x3 0x0
-#define MX6DL_PAD_KEY_ROW4__UART5_CTS_B            0x268 0x650 0x000 0x4 0x0
-#define MX6DL_PAD_KEY_ROW4__UART5_RTS_B            0x268 0x650 0x918 0x4 0x3
+#define MX6DL_PAD_KEY_ROW4__UART5_RTS_B            0x268 0x650 0x000 0x4 0x0
+#define MX6DL_PAD_KEY_ROW4__UART5_CTS_B            0x268 0x650 0x918 0x4 0x3
 #define MX6DL_PAD_KEY_ROW4__GPIO4_IO15             0x268 0x650 0x000 0x5 0x0
 #define MX6DL_PAD_NANDF_ALE__NAND_ALE              0x26c 0x654 0x000 0x0 0x0
 #define MX6DL_PAD_NANDF_ALE__SD4_RESET             0x26c 0x654 0x000 0x1 0x0
@@ -999,30 +999,30 @@
 #define MX6DL_PAD_SD2_DAT3__AUD4_TXC               0x308 0x6f0 0x7a8 0x3 0x1
 #define MX6DL_PAD_SD2_DAT3__GPIO1_IO12             0x308 0x6f0 0x000 0x5 0x0
 #define MX6DL_PAD_SD3_CLK__SD3_CLK                 0x30c 0x6f4 0x934 0x0 0x1
-#define MX6DL_PAD_SD3_CLK__UART2_RTS_B             0x30c 0x6f4 0x900 0x1 0x2
-#define MX6DL_PAD_SD3_CLK__UART2_CTS_B             0x30c 0x6f4 0x000 0x1 0x0
+#define MX6DL_PAD_SD3_CLK__UART2_CTS_B             0x30c 0x6f4 0x900 0x1 0x2
+#define MX6DL_PAD_SD3_CLK__UART2_RTS_B             0x30c 0x6f4 0x000 0x1 0x0
 #define MX6DL_PAD_SD3_CLK__FLEXCAN1_RX             0x30c 0x6f4 0x7c8 0x2 0x2
 #define MX6DL_PAD_SD3_CLK__GPIO7_IO03              0x30c 0x6f4 0x000 0x5 0x0
 #define MX6DL_PAD_SD3_CMD__SD3_CMD                 0x310 0x6f8 0x000 0x0 0x0
-#define MX6DL_PAD_SD3_CMD__UART2_CTS_B             0x310 0x6f8 0x000 0x1 0x0
-#define MX6DL_PAD_SD3_CMD__UART2_RTS_B             0x310 0x6f8 0x900 0x1 0x3
+#define MX6DL_PAD_SD3_CMD__UART2_RTS_B             0x310 0x6f8 0x000 0x1 0x0
+#define MX6DL_PAD_SD3_CMD__UART2_CTS_B             0x310 0x6f8 0x900 0x1 0x3
 #define MX6DL_PAD_SD3_CMD__FLEXCAN1_TX             0x310 0x6f8 0x000 0x2 0x0
 #define MX6DL_PAD_SD3_CMD__GPIO7_IO02              0x310 0x6f8 0x000 0x5 0x0
 #define MX6DL_PAD_SD3_DAT0__SD3_DATA0              0x314 0x6fc 0x000 0x0 0x0
-#define MX6DL_PAD_SD3_DAT0__UART1_CTS_B            0x314 0x6fc 0x000 0x1 0x0
-#define MX6DL_PAD_SD3_DAT0__UART1_RTS_B            0x314 0x6fc 0x8f8 0x1 0x2
+#define MX6DL_PAD_SD3_DAT0__UART1_RTS_B            0x314 0x6fc 0x000 0x1 0x0
+#define MX6DL_PAD_SD3_DAT0__UART1_CTS_B            0x314 0x6fc 0x8f8 0x1 0x2
 #define MX6DL_PAD_SD3_DAT0__FLEXCAN2_TX            0x314 0x6fc 0x000 0x2 0x0
 #define MX6DL_PAD_SD3_DAT0__GPIO7_IO04             0x314 0x6fc 0x000 0x5 0x0
 #define MX6DL_PAD_SD3_DAT1__SD3_DATA1              0x318 0x700 0x000 0x0 0x0
-#define MX6DL_PAD_SD3_DAT1__UART1_RTS_B            0x318 0x700 0x8f8 0x1 0x3
-#define MX6DL_PAD_SD3_DAT1__UART1_CTS_B            0x318 0x700 0x000 0x1 0x0
+#define MX6DL_PAD_SD3_DAT1__UART1_CTS_B            0x318 0x700 0x8f8 0x1 0x3
+#define MX6DL_PAD_SD3_DAT1__UART1_RTS_B            0x318 0x700 0x000 0x1 0x0
 #define MX6DL_PAD_SD3_DAT1__FLEXCAN2_RX            0x318 0x700 0x7cc 0x2 0x1
 #define MX6DL_PAD_SD3_DAT1__GPIO7_IO05             0x318 0x700 0x000 0x5 0x0
 #define MX6DL_PAD_SD3_DAT2__SD3_DATA2              0x31c 0x704 0x000 0x0 0x0
 #define MX6DL_PAD_SD3_DAT2__GPIO7_IO06             0x31c 0x704 0x000 0x5 0x0
 #define MX6DL_PAD_SD3_DAT3__SD3_DATA3              0x320 0x708 0x000 0x0 0x0
-#define MX6DL_PAD_SD3_DAT3__UART3_CTS_B            0x320 0x708 0x000 0x1 0x0
-#define MX6DL_PAD_SD3_DAT3__UART3_RTS_B            0x320 0x708 0x908 0x1 0x4
+#define MX6DL_PAD_SD3_DAT3__UART3_RTS_B            0x320 0x708 0x000 0x1 0x0
+#define MX6DL_PAD_SD3_DAT3__UART3_CTS_B            0x320 0x708 0x908 0x1 0x4
 #define MX6DL_PAD_SD3_DAT3__GPIO7_IO07             0x320 0x708 0x000 0x5 0x0
 #define MX6DL_PAD_SD3_DAT4__SD3_DATA4              0x324 0x70c 0x000 0x0 0x0
 #define MX6DL_PAD_SD3_DAT4__UART2_RX_DATA          0x324 0x70c 0x904 0x1 0x4
@@ -1041,8 +1041,8 @@
 #define MX6DL_PAD_SD3_DAT7__UART1_RX_DATA          0x330 0x718 0x8fc 0x1 0x3
 #define MX6DL_PAD_SD3_DAT7__GPIO6_IO17             0x330 0x718 0x000 0x5 0x0
 #define MX6DL_PAD_SD3_RST__SD3_RESET               0x334 0x71c 0x000 0x0 0x0
-#define MX6DL_PAD_SD3_RST__UART3_RTS_B             0x334 0x71c 0x908 0x1 0x5
-#define MX6DL_PAD_SD3_RST__UART3_CTS_B             0x334 0x71c 0x000 0x1 0x0
+#define MX6DL_PAD_SD3_RST__UART3_CTS_B             0x334 0x71c 0x908 0x1 0x5
+#define MX6DL_PAD_SD3_RST__UART3_RTS_B             0x334 0x71c 0x000 0x1 0x0
 #define MX6DL_PAD_SD3_RST__GPIO7_IO08              0x334 0x71c 0x000 0x5 0x0
 #define MX6DL_PAD_SD4_CLK__SD4_CLK                 0x338 0x720 0x938 0x0 0x1
 #define MX6DL_PAD_SD4_CLK__NAND_WE_B               0x338 0x720 0x000 0x1 0x0
@@ -1070,12 +1070,12 @@
 #define MX6DL_PAD_SD4_DAT4__UART2_TX_DATA          0x350 0x738 0x000 0x2 0x0
 #define MX6DL_PAD_SD4_DAT4__GPIO2_IO12             0x350 0x738 0x000 0x5 0x0
 #define MX6DL_PAD_SD4_DAT5__SD4_DATA5              0x354 0x73c 0x000 0x1 0x0
-#define MX6DL_PAD_SD4_DAT5__UART2_RTS_B            0x354 0x73c 0x900 0x2 0x4
-#define MX6DL_PAD_SD4_DAT5__UART2_CTS_B            0x354 0x73c 0x000 0x2 0x0
+#define MX6DL_PAD_SD4_DAT5__UART2_CTS_B            0x354 0x73c 0x900 0x2 0x4
+#define MX6DL_PAD_SD4_DAT5__UART2_RTS_B            0x354 0x73c 0x000 0x2 0x0
 #define MX6DL_PAD_SD4_DAT5__GPIO2_IO13             0x354 0x73c 0x000 0x5 0x0
 #define MX6DL_PAD_SD4_DAT6__SD4_DATA6              0x358 0x740 0x000 0x1 0x0
-#define MX6DL_PAD_SD4_DAT6__UART2_CTS_B            0x358 0x740 0x000 0x2 0x0
-#define MX6DL_PAD_SD4_DAT6__UART2_RTS_B            0x358 0x740 0x900 0x2 0x5
+#define MX6DL_PAD_SD4_DAT6__UART2_RTS_B            0x358 0x740 0x000 0x2 0x0
+#define MX6DL_PAD_SD4_DAT6__UART2_CTS_B            0x358 0x740 0x900 0x2 0x5
 #define MX6DL_PAD_SD4_DAT6__GPIO2_IO14             0x358 0x740 0x000 0x5 0x0
 #define MX6DL_PAD_SD4_DAT7__SD4_DATA7              0x35c 0x744 0x000 0x1 0x0
 #define MX6DL_PAD_SD4_DAT7__UART2_TX_DATA          0x35c 0x744 0x000 0x2 0x0
diff --git a/arch/arm/boot/dts/imx6q-pinfunc.h b/arch/arm/boot/dts/imx6q-pinfunc.h
index faea6e1..a38838d 100644
--- a/arch/arm/boot/dts/imx6q-pinfunc.h
+++ b/arch/arm/boot/dts/imx6q-pinfunc.h
@@ -110,16 +110,16 @@
 #define MX6Q_PAD_EIM_D19__ECSPI1_SS1              0x09c 0x3b0 0x804 0x1 0x0
 #define MX6Q_PAD_EIM_D19__IPU1_DI0_PIN08          0x09c 0x3b0 0x000 0x2 0x0
 #define MX6Q_PAD_EIM_D19__IPU2_CSI1_DATA16        0x09c 0x3b0 0x8c8 0x3 0x0
-#define MX6Q_PAD_EIM_D19__UART1_CTS_B             0x09c 0x3b0 0x000 0x4 0x0
-#define MX6Q_PAD_EIM_D19__UART1_RTS_B             0x09c 0x3b0 0x91c 0x4 0x0
+#define MX6Q_PAD_EIM_D19__UART1_RTS_B             0x09c 0x3b0 0x000 0x4 0x0
+#define MX6Q_PAD_EIM_D19__UART1_CTS_B             0x09c 0x3b0 0x91c 0x4 0x0
 #define MX6Q_PAD_EIM_D19__GPIO3_IO19              0x09c 0x3b0 0x000 0x5 0x0
 #define MX6Q_PAD_EIM_D19__EPIT1_OUT               0x09c 0x3b0 0x000 0x6 0x0
 #define MX6Q_PAD_EIM_D20__EIM_DATA20              0x0a0 0x3b4 0x000 0x0 0x0
 #define MX6Q_PAD_EIM_D20__ECSPI4_SS0              0x0a0 0x3b4 0x824 0x1 0x0
 #define MX6Q_PAD_EIM_D20__IPU1_DI0_PIN16          0x0a0 0x3b4 0x000 0x2 0x0
 #define MX6Q_PAD_EIM_D20__IPU2_CSI1_DATA15        0x0a0 0x3b4 0x8c4 0x3 0x0
-#define MX6Q_PAD_EIM_D20__UART1_RTS_B             0x0a0 0x3b4 0x91c 0x4 0x1
-#define MX6Q_PAD_EIM_D20__UART1_CTS_B             0x0a0 0x3b4 0x000 0x4 0x0
+#define MX6Q_PAD_EIM_D20__UART1_CTS_B             0x0a0 0x3b4 0x91c 0x4 0x1
+#define MX6Q_PAD_EIM_D20__UART1_RTS_B             0x0a0 0x3b4 0x000 0x4 0x0
 #define MX6Q_PAD_EIM_D20__GPIO3_IO20              0x0a0 0x3b4 0x000 0x5 0x0
 #define MX6Q_PAD_EIM_D20__EPIT2_OUT               0x0a0 0x3b4 0x000 0x6 0x0
 #define MX6Q_PAD_EIM_D21__EIM_DATA21              0x0a4 0x3b8 0x000 0x0 0x0
@@ -139,8 +139,8 @@
 #define MX6Q_PAD_EIM_D22__SPDIF_OUT               0x0a8 0x3bc 0x000 0x6 0x0
 #define MX6Q_PAD_EIM_D23__EIM_DATA23              0x0ac 0x3c0 0x000 0x0 0x0
 #define MX6Q_PAD_EIM_D23__IPU1_DI0_D0_CS          0x0ac 0x3c0 0x000 0x1 0x0
-#define MX6Q_PAD_EIM_D23__UART3_CTS_B             0x0ac 0x3c0 0x000 0x2 0x0
-#define MX6Q_PAD_EIM_D23__UART3_RTS_B             0x0ac 0x3c0 0x92c 0x2 0x0
+#define MX6Q_PAD_EIM_D23__UART3_RTS_B             0x0ac 0x3c0 0x000 0x2 0x0
+#define MX6Q_PAD_EIM_D23__UART3_CTS_B             0x0ac 0x3c0 0x92c 0x2 0x0
 #define MX6Q_PAD_EIM_D23__UART1_DCD_B             0x0ac 0x3c0 0x000 0x3 0x0
 #define MX6Q_PAD_EIM_D23__IPU2_CSI1_DATA_EN       0x0ac 0x3c0 0x8d8 0x4 0x0
 #define MX6Q_PAD_EIM_D23__GPIO3_IO23              0x0ac 0x3c0 0x000 0x5 0x0
@@ -148,8 +148,8 @@
 #define MX6Q_PAD_EIM_D23__IPU1_DI1_PIN14          0x0ac 0x3c0 0x000 0x7 0x0
 #define MX6Q_PAD_EIM_EB3__EIM_EB3_B               0x0b0 0x3c4 0x000 0x0 0x0
 #define MX6Q_PAD_EIM_EB3__ECSPI4_RDY              0x0b0 0x3c4 0x000 0x1 0x0
-#define MX6Q_PAD_EIM_EB3__UART3_RTS_B             0x0b0 0x3c4 0x92c 0x2 0x1
-#define MX6Q_PAD_EIM_EB3__UART3_CTS_B             0x0b0 0x3c4 0x000 0x2 0x0
+#define MX6Q_PAD_EIM_EB3__UART3_CTS_B             0x0b0 0x3c4 0x92c 0x2 0x1
+#define MX6Q_PAD_EIM_EB3__UART3_RTS_B             0x0b0 0x3c4 0x000 0x2 0x0
 #define MX6Q_PAD_EIM_EB3__UART1_RI_B              0x0b0 0x3c4 0x000 0x3 0x0
 #define MX6Q_PAD_EIM_EB3__IPU2_CSI1_HSYNC         0x0b0 0x3c4 0x8dc 0x4 0x0
 #define MX6Q_PAD_EIM_EB3__GPIO2_IO31              0x0b0 0x3c4 0x000 0x5 0x0
@@ -195,16 +195,16 @@
 #define MX6Q_PAD_EIM_D28__I2C1_SDA                0x0c4 0x3d8 0x89c 0x1 0x0
 #define MX6Q_PAD_EIM_D28__ECSPI4_MOSI             0x0c4 0x3d8 0x000 0x2 0x0
 #define MX6Q_PAD_EIM_D28__IPU2_CSI1_DATA12        0x0c4 0x3d8 0x8b8 0x3 0x0
-#define MX6Q_PAD_EIM_D28__UART2_CTS_B             0x0c4 0x3d8 0x000 0x4 0x0
-#define MX6Q_PAD_EIM_D28__UART2_RTS_B             0x0c4 0x3d8 0x924 0x4 0x0
+#define MX6Q_PAD_EIM_D28__UART2_RTS_B             0x0c4 0x3d8 0x000 0x4 0x0
+#define MX6Q_PAD_EIM_D28__UART2_CTS_B             0x0c4 0x3d8 0x924 0x4 0x0
 #define MX6Q_PAD_EIM_D28__GPIO3_IO28              0x0c4 0x3d8 0x000 0x5 0x0
 #define MX6Q_PAD_EIM_D28__IPU1_EXT_TRIG           0x0c4 0x3d8 0x000 0x6 0x0
 #define MX6Q_PAD_EIM_D28__IPU1_DI0_PIN13          0x0c4 0x3d8 0x000 0x7 0x0
 #define MX6Q_PAD_EIM_D29__EIM_DATA29              0x0c8 0x3dc 0x000 0x0 0x0
 #define MX6Q_PAD_EIM_D29__IPU1_DI1_PIN15          0x0c8 0x3dc 0x000 0x1 0x0
 #define MX6Q_PAD_EIM_D29__ECSPI4_SS0              0x0c8 0x3dc 0x824 0x2 0x1
-#define MX6Q_PAD_EIM_D29__UART2_RTS_B             0x0c8 0x3dc 0x924 0x4 0x1
-#define MX6Q_PAD_EIM_D29__UART2_CTS_B             0x0c8 0x3dc 0x000 0x4 0x0
+#define MX6Q_PAD_EIM_D29__UART2_CTS_B             0x0c8 0x3dc 0x924 0x4 0x1
+#define MX6Q_PAD_EIM_D29__UART2_RTS_B             0x0c8 0x3dc 0x000 0x4 0x0
 #define MX6Q_PAD_EIM_D29__GPIO3_IO29              0x0c8 0x3dc 0x000 0x5 0x0
 #define MX6Q_PAD_EIM_D29__IPU2_CSI1_VSYNC         0x0c8 0x3dc 0x8e4 0x6 0x0
 #define MX6Q_PAD_EIM_D29__IPU1_DI0_PIN14          0x0c8 0x3dc 0x000 0x7 0x0
@@ -212,16 +212,16 @@
 #define MX6Q_PAD_EIM_D30__IPU1_DISP1_DATA21       0x0cc 0x3e0 0x000 0x1 0x0
 #define MX6Q_PAD_EIM_D30__IPU1_DI0_PIN11          0x0cc 0x3e0 0x000 0x2 0x0
 #define MX6Q_PAD_EIM_D30__IPU1_CSI0_DATA03        0x0cc 0x3e0 0x000 0x3 0x0
-#define MX6Q_PAD_EIM_D30__UART3_CTS_B             0x0cc 0x3e0 0x000 0x4 0x0
-#define MX6Q_PAD_EIM_D30__UART3_RTS_B             0x0cc 0x3e0 0x92c 0x4 0x2
+#define MX6Q_PAD_EIM_D30__UART3_RTS_B             0x0cc 0x3e0 0x000 0x4 0x0
+#define MX6Q_PAD_EIM_D30__UART3_CTS_B             0x0cc 0x3e0 0x92c 0x4 0x2
 #define MX6Q_PAD_EIM_D30__GPIO3_IO30              0x0cc 0x3e0 0x000 0x5 0x0
 #define MX6Q_PAD_EIM_D30__USB_H1_OC               0x0cc 0x3e0 0x948 0x6 0x0
 #define MX6Q_PAD_EIM_D31__EIM_DATA31              0x0d0 0x3e4 0x000 0x0 0x0
 #define MX6Q_PAD_EIM_D31__IPU1_DISP1_DATA20       0x0d0 0x3e4 0x000 0x1 0x0
 #define MX6Q_PAD_EIM_D31__IPU1_DI0_PIN12          0x0d0 0x3e4 0x000 0x2 0x0
 #define MX6Q_PAD_EIM_D31__IPU1_CSI0_DATA02        0x0d0 0x3e4 0x000 0x3 0x0
-#define MX6Q_PAD_EIM_D31__UART3_RTS_B             0x0d0 0x3e4 0x92c 0x4 0x3
-#define MX6Q_PAD_EIM_D31__UART3_CTS_B             0x0d0 0x3e4 0x000 0x4 0x0
+#define MX6Q_PAD_EIM_D31__UART3_CTS_B             0x0d0 0x3e4 0x92c 0x4 0x3
+#define MX6Q_PAD_EIM_D31__UART3_RTS_B             0x0d0 0x3e4 0x000 0x4 0x0
 #define MX6Q_PAD_EIM_D31__GPIO3_IO31              0x0d0 0x3e4 0x000 0x5 0x0
 #define MX6Q_PAD_EIM_D31__USB_H1_PWR              0x0d0 0x3e4 0x000 0x6 0x0
 #define MX6Q_PAD_EIM_A24__EIM_ADDR24              0x0d4 0x3e8 0x000 0x0 0x0
@@ -630,15 +630,15 @@
 #define MX6Q_PAD_KEY_COL4__IPU1_SISG4             0x218 0x5e8 0x000 0x1 0x0
 #define MX6Q_PAD_KEY_COL4__USB_OTG_OC             0x218 0x5e8 0x944 0x2 0x1
 #define MX6Q_PAD_KEY_COL4__KEY_COL4               0x218 0x5e8 0x000 0x3 0x0
-#define MX6Q_PAD_KEY_COL4__UART5_RTS_B            0x218 0x5e8 0x93c 0x4 0x0
-#define MX6Q_PAD_KEY_COL4__UART5_CTS_B            0x218 0x5e8 0x000 0x4 0x0
+#define MX6Q_PAD_KEY_COL4__UART5_CTS_B            0x218 0x5e8 0x93c 0x4 0x0
+#define MX6Q_PAD_KEY_COL4__UART5_RTS_B            0x218 0x5e8 0x000 0x4 0x0
 #define MX6Q_PAD_KEY_COL4__GPIO4_IO14             0x218 0x5e8 0x000 0x5 0x0
 #define MX6Q_PAD_KEY_ROW4__FLEXCAN2_RX            0x21c 0x5ec 0x7e8 0x0 0x0
 #define MX6Q_PAD_KEY_ROW4__IPU1_SISG5             0x21c 0x5ec 0x000 0x1 0x0
 #define MX6Q_PAD_KEY_ROW4__USB_OTG_PWR            0x21c 0x5ec 0x000 0x2 0x0
 #define MX6Q_PAD_KEY_ROW4__KEY_ROW4               0x21c 0x5ec 0x000 0x3 0x0
-#define MX6Q_PAD_KEY_ROW4__UART5_CTS_B            0x21c 0x5ec 0x000 0x4 0x0
-#define MX6Q_PAD_KEY_ROW4__UART5_RTS_B            0x21c 0x5ec 0x93c 0x4 0x1
+#define MX6Q_PAD_KEY_ROW4__UART5_RTS_B            0x21c 0x5ec 0x000 0x4 0x0
+#define MX6Q_PAD_KEY_ROW4__UART5_CTS_B            0x21c 0x5ec 0x93c 0x4 0x1
 #define MX6Q_PAD_KEY_ROW4__GPIO4_IO15             0x21c 0x5ec 0x000 0x5 0x0
 #define MX6Q_PAD_GPIO_0__CCM_CLKO1                0x220 0x5f0 0x000 0x0 0x0
 #define MX6Q_PAD_GPIO_0__KEY_COL5                 0x220 0x5f0 0x8e8 0x2 0x0
@@ -831,26 +831,26 @@
 #define MX6Q_PAD_CSI0_DAT15__ARM_TRACE12          0x294 0x664 0x000 0x7 0x0
 #define MX6Q_PAD_CSI0_DAT16__IPU1_CSI0_DATA16     0x298 0x668 0x000 0x0 0x0
 #define MX6Q_PAD_CSI0_DAT16__EIM_DATA12           0x298 0x668 0x000 0x1 0x0
-#define MX6Q_PAD_CSI0_DAT16__UART4_RTS_B          0x298 0x668 0x934 0x3 0x0
-#define MX6Q_PAD_CSI0_DAT16__UART4_CTS_B          0x298 0x668 0x000 0x3 0x0
+#define MX6Q_PAD_CSI0_DAT16__UART4_CTS_B          0x298 0x668 0x934 0x3 0x0
+#define MX6Q_PAD_CSI0_DAT16__UART4_RTS_B          0x298 0x668 0x000 0x3 0x0
 #define MX6Q_PAD_CSI0_DAT16__GPIO6_IO02           0x298 0x668 0x000 0x5 0x0
 #define MX6Q_PAD_CSI0_DAT16__ARM_TRACE13          0x298 0x668 0x000 0x7 0x0
 #define MX6Q_PAD_CSI0_DAT17__IPU1_CSI0_DATA17     0x29c 0x66c 0x000 0x0 0x0
 #define MX6Q_PAD_CSI0_DAT17__EIM_DATA13           0x29c 0x66c 0x000 0x1 0x0
-#define MX6Q_PAD_CSI0_DAT17__UART4_CTS_B          0x29c 0x66c 0x000 0x3 0x0
-#define MX6Q_PAD_CSI0_DAT17__UART4_RTS_B          0x29c 0x66c 0x934 0x3 0x1
+#define MX6Q_PAD_CSI0_DAT17__UART4_RTS_B          0x29c 0x66c 0x000 0x3 0x0
+#define MX6Q_PAD_CSI0_DAT17__UART4_CTS_B          0x29c 0x66c 0x934 0x3 0x1
 #define MX6Q_PAD_CSI0_DAT17__GPIO6_IO03           0x29c 0x66c 0x000 0x5 0x0
 #define MX6Q_PAD_CSI0_DAT17__ARM_TRACE14          0x29c 0x66c 0x000 0x7 0x0
 #define MX6Q_PAD_CSI0_DAT18__IPU1_CSI0_DATA18     0x2a0 0x670 0x000 0x0 0x0
 #define MX6Q_PAD_CSI0_DAT18__EIM_DATA14           0x2a0 0x670 0x000 0x1 0x0
-#define MX6Q_PAD_CSI0_DAT18__UART5_RTS_B          0x2a0 0x670 0x93c 0x3 0x2
-#define MX6Q_PAD_CSI0_DAT18__UART5_CTS_B          0x2a0 0x670 0x000 0x3 0x0
+#define MX6Q_PAD_CSI0_DAT18__UART5_CTS_B          0x2a0 0x670 0x93c 0x3 0x2
+#define MX6Q_PAD_CSI0_DAT18__UART5_RTS_B          0x2a0 0x670 0x000 0x3 0x0
 #define MX6Q_PAD_CSI0_DAT18__GPIO6_IO04           0x2a0 0x670 0x000 0x5 0x0
 #define MX6Q_PAD_CSI0_DAT18__ARM_TRACE15          0x2a0 0x670 0x000 0x7 0x0
 #define MX6Q_PAD_CSI0_DAT19__IPU1_CSI0_DATA19     0x2a4 0x674 0x000 0x0 0x0
 #define MX6Q_PAD_CSI0_DAT19__EIM_DATA15           0x2a4 0x674 0x000 0x1 0x0
-#define MX6Q_PAD_CSI0_DAT19__UART5_CTS_B          0x2a4 0x674 0x000 0x3 0x0
-#define MX6Q_PAD_CSI0_DAT19__UART5_RTS_B          0x2a4 0x674 0x93c 0x3 0x3
+#define MX6Q_PAD_CSI0_DAT19__UART5_RTS_B          0x2a4 0x674 0x000 0x3 0x0
+#define MX6Q_PAD_CSI0_DAT19__UART5_CTS_B          0x2a4 0x674 0x93c 0x3 0x3
 #define MX6Q_PAD_CSI0_DAT19__GPIO6_IO05           0x2a4 0x674 0x000 0x5 0x0
 #define MX6Q_PAD_SD3_DAT7__SD3_DATA7              0x2a8 0x690 0x000 0x0 0x0
 #define MX6Q_PAD_SD3_DAT7__UART1_TX_DATA          0x2a8 0x690 0x000 0x1 0x0
@@ -869,34 +869,34 @@
 #define MX6Q_PAD_SD3_DAT4__UART2_TX_DATA          0x2b4 0x69c 0x000 0x1 0x0
 #define MX6Q_PAD_SD3_DAT4__GPIO7_IO01             0x2b4 0x69c 0x000 0x5 0x0
 #define MX6Q_PAD_SD3_CMD__SD3_CMD                 0x2b8 0x6a0 0x000 0x0 0x0
-#define MX6Q_PAD_SD3_CMD__UART2_CTS_B             0x2b8 0x6a0 0x000 0x1 0x0
-#define MX6Q_PAD_SD3_CMD__UART2_RTS_B             0x2b8 0x6a0 0x924 0x1 0x2
+#define MX6Q_PAD_SD3_CMD__UART2_RTS_B             0x2b8 0x6a0 0x000 0x1 0x0
+#define MX6Q_PAD_SD3_CMD__UART2_CTS_B             0x2b8 0x6a0 0x924 0x1 0x2
 #define MX6Q_PAD_SD3_CMD__FLEXCAN1_TX             0x2b8 0x6a0 0x000 0x2 0x0
 #define MX6Q_PAD_SD3_CMD__GPIO7_IO02              0x2b8 0x6a0 0x000 0x5 0x0
 #define MX6Q_PAD_SD3_CLK__SD3_CLK                 0x2bc 0x6a4 0x000 0x0 0x0
-#define MX6Q_PAD_SD3_CLK__UART2_RTS_B             0x2bc 0x6a4 0x924 0x1 0x3
-#define MX6Q_PAD_SD3_CLK__UART2_CTS_B             0x2bc 0x6a4 0x000 0x1 0x0
+#define MX6Q_PAD_SD3_CLK__UART2_CTS_B             0x2bc 0x6a4 0x924 0x1 0x3
+#define MX6Q_PAD_SD3_CLK__UART2_RTS_B             0x2bc 0x6a4 0x000 0x1 0x0
 #define MX6Q_PAD_SD3_CLK__FLEXCAN1_RX             0x2bc 0x6a4 0x7e4 0x2 0x2
 #define MX6Q_PAD_SD3_CLK__GPIO7_IO03              0x2bc 0x6a4 0x000 0x5 0x0
 #define MX6Q_PAD_SD3_DAT0__SD3_DATA0              0x2c0 0x6a8 0x000 0x0 0x0
-#define MX6Q_PAD_SD3_DAT0__UART1_CTS_B            0x2c0 0x6a8 0x000 0x1 0x0
-#define MX6Q_PAD_SD3_DAT0__UART1_RTS_B            0x2c0 0x6a8 0x91c 0x1 0x2
+#define MX6Q_PAD_SD3_DAT0__UART1_RTS_B            0x2c0 0x6a8 0x000 0x1 0x0
+#define MX6Q_PAD_SD3_DAT0__UART1_CTS_B            0x2c0 0x6a8 0x91c 0x1 0x2
 #define MX6Q_PAD_SD3_DAT0__FLEXCAN2_TX            0x2c0 0x6a8 0x000 0x2 0x0
 #define MX6Q_PAD_SD3_DAT0__GPIO7_IO04             0x2c0 0x6a8 0x000 0x5 0x0
 #define MX6Q_PAD_SD3_DAT1__SD3_DATA1              0x2c4 0x6ac 0x000 0x0 0x0
-#define MX6Q_PAD_SD3_DAT1__UART1_RTS_B            0x2c4 0x6ac 0x91c 0x1 0x3
-#define MX6Q_PAD_SD3_DAT1__UART1_CTS_B            0x2c4 0x6ac 0x000 0x1 0x0
+#define MX6Q_PAD_SD3_DAT1__UART1_CTS_B            0x2c4 0x6ac 0x91c 0x1 0x3
+#define MX6Q_PAD_SD3_DAT1__UART1_RTS_B            0x2c4 0x6ac 0x000 0x1 0x0
 #define MX6Q_PAD_SD3_DAT1__FLEXCAN2_RX            0x2c4 0x6ac 0x7e8 0x2 0x1
 #define MX6Q_PAD_SD3_DAT1__GPIO7_IO05             0x2c4 0x6ac 0x000 0x5 0x0
 #define MX6Q_PAD_SD3_DAT2__SD3_DATA2              0x2c8 0x6b0 0x000 0x0 0x0
 #define MX6Q_PAD_SD3_DAT2__GPIO7_IO06             0x2c8 0x6b0 0x000 0x5 0x0
 #define MX6Q_PAD_SD3_DAT3__SD3_DATA3              0x2cc 0x6b4 0x000 0x0 0x0
-#define MX6Q_PAD_SD3_DAT3__UART3_CTS_B            0x2cc 0x6b4 0x000 0x1 0x0
-#define MX6Q_PAD_SD3_DAT3__UART3_RTS_B            0x2cc 0x6b4 0x92c 0x1 0x4
+#define MX6Q_PAD_SD3_DAT3__UART3_RTS_B            0x2cc 0x6b4 0x000 0x1 0x0
+#define MX6Q_PAD_SD3_DAT3__UART3_CTS_B            0x2cc 0x6b4 0x92c 0x1 0x4
 #define MX6Q_PAD_SD3_DAT3__GPIO7_IO07             0x2cc 0x6b4 0x000 0x5 0x0
 #define MX6Q_PAD_SD3_RST__SD3_RESET               0x2d0 0x6b8 0x000 0x0 0x0
-#define MX6Q_PAD_SD3_RST__UART3_RTS_B             0x2d0 0x6b8 0x92c 0x1 0x5
-#define MX6Q_PAD_SD3_RST__UART3_CTS_B             0x2d0 0x6b8 0x000 0x1 0x0
+#define MX6Q_PAD_SD3_RST__UART3_CTS_B             0x2d0 0x6b8 0x92c 0x1 0x5
+#define MX6Q_PAD_SD3_RST__UART3_RTS_B             0x2d0 0x6b8 0x000 0x1 0x0
 #define MX6Q_PAD_SD3_RST__GPIO7_IO08              0x2d0 0x6b8 0x000 0x5 0x0
 #define MX6Q_PAD_NANDF_CLE__NAND_CLE              0x2d4 0x6bc 0x000 0x0 0x0
 #define MX6Q_PAD_NANDF_CLE__IPU2_SISG4            0x2d4 0x6bc 0x000 0x1 0x0
@@ -979,12 +979,12 @@
 #define MX6Q_PAD_SD4_DAT4__UART2_TX_DATA          0x32c 0x714 0x000 0x2 0x0
 #define MX6Q_PAD_SD4_DAT4__GPIO2_IO12             0x32c 0x714 0x000 0x5 0x0
 #define MX6Q_PAD_SD4_DAT5__SD4_DATA5              0x330 0x718 0x000 0x1 0x0
-#define MX6Q_PAD_SD4_DAT5__UART2_RTS_B            0x330 0x718 0x924 0x2 0x4
-#define MX6Q_PAD_SD4_DAT5__UART2_CTS_B            0x330 0x718 0x000 0x2 0x0
+#define MX6Q_PAD_SD4_DAT5__UART2_CTS_B            0x330 0x718 0x924 0x2 0x4
+#define MX6Q_PAD_SD4_DAT5__UART2_RTS_B            0x330 0x718 0x000 0x2 0x0
 #define MX6Q_PAD_SD4_DAT5__GPIO2_IO13             0x330 0x718 0x000 0x5 0x0
 #define MX6Q_PAD_SD4_DAT6__SD4_DATA6              0x334 0x71c 0x000 0x1 0x0
-#define MX6Q_PAD_SD4_DAT6__UART2_CTS_B            0x334 0x71c 0x000 0x2 0x0
-#define MX6Q_PAD_SD4_DAT6__UART2_RTS_B            0x334 0x71c 0x924 0x2 0x5
+#define MX6Q_PAD_SD4_DAT6__UART2_RTS_B            0x334 0x71c 0x000 0x2 0x0
+#define MX6Q_PAD_SD4_DAT6__UART2_CTS_B            0x334 0x71c 0x924 0x2 0x5
 #define MX6Q_PAD_SD4_DAT6__GPIO2_IO14             0x334 0x71c 0x000 0x5 0x0
 #define MX6Q_PAD_SD4_DAT7__SD4_DATA7              0x338 0x720 0x000 0x1 0x0
 #define MX6Q_PAD_SD4_DAT7__UART2_TX_DATA          0x338 0x720 0x000 0x2 0x0
-- 
1.7.1




From b32955 at freescale.com  Fri Jul  5 02:12:32 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Fri, 5 Jul 2013 14:12:32 +0800
Subject: [PATCH v3 6/6] ARM: dts: enable the uart2 for imx6q-arm2
In-Reply-To: <1373004752-21302-1-git-send-email-b32955@freescale.com>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>
Message-ID: <1373004752-21302-7-git-send-email-b32955@freescale.com>

enable the uart2 for imx6q-arm2 board.
The uart2 works in the DTE mode, with the RTS/CTS and DMA enabled.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6q-arm2.dts |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-arm2.dts b/arch/arm/boot/dts/imx6q-arm2.dts
index 4e54fde..e7e3b56 100644
--- a/arch/arm/boot/dts/imx6q-arm2.dts
+++ b/arch/arm/boot/dts/imx6q-arm2.dts
@@ -97,6 +97,16 @@
 	status = "okay";
 };
 
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2_2>;
+	fsl,dte-mode;
+	fsl,uart-has-rtscts;
+	dma-names = "rx", "tx";
+	dmas = <&sdma 27 4 0>, <&sdma 28 4 0>;
+	status = "okay";
+};
+
 &uart4 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart4_1>;
-- 
1.7.1




From pekon at ti.com  Fri Jul  5 02:45:01 2013
From: pekon at ti.com (Gupta, Pekon)
Date: Fri, 5 Jul 2013 06:45:01 +0000
Subject: SPI: DUAL/QUAD support
In-Reply-To: <CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704130017.GA25997@sig21.net>
 <OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>
 <20130704154927.GE27646@sirena.org.uk>
 <OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>
 <CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>
Message-ID: <20980858CB6D3A4BAE95CA194937D5E73E9E4C2E@DBDE04.ent.ti.com>


> Just as Johannes said. In my patch m25p80's changes is incomplete.
> Because my inicial aim is to add the transfer width member to tell controller
> the mode flash in. And I will attach new patch about m25p80 later.
> Also you are right. There are really series of flashes do not support dual/quad
> transfer. So I don't know whether there are any standard for serial-flash just
> like the CFI for parallel-flash. Personally, to make a general standard and
> a general code for serial-flash is necessary. So that we do not need to add
> special function in m25p80.c.
> 
[Pekon]: Does below generic framework for spianand, suit your driver?
http://lists.infradead.org/pipermail/linux-mtd/2013-July/047434.html

you should be able to extend the generic spinand API for all
serial modes (SPI, Dual-SPI, Quad-SPI).
As QSPI and Dual-SPI devices should implicitly support SPI (MISO/MOSI)
So, you can do device probing using default SPI mode. And then based on
DT inputs and device support upgrade to QSPI / Dual-SPI mode.
And going forward extend it for direct memory-mapped device for XIP.


with regards, pekon


From vinod.koul at intel.com  Fri Jul  5 02:18:02 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Fri, 5 Jul 2013 11:48:02 +0530
Subject: amba-pl08x and 'get_signal' namespace collision/build error
In-Reply-To: <CAOesGMgSPNggnBm=E3B774m7Ad_QMXdqvcGqRMxhap6dtpNtCg@mail.gmail.com>
References: <51C97F40.5030101@arm.com>
 <20130625184539.GB2718@n2100.arm.linux.org.uk>
 <20130626044842.GR23141@intel.com>
 <20130626081909.GD2718@n2100.arm.linux.org.uk>
 <20130626103930.GS23141@intel.com>
 <20130627094650.GC4283@n2100.arm.linux.org.uk>
 <CAOesGMgSPNggnBm=E3B774m7Ad_QMXdqvcGqRMxhap6dtpNtCg@mail.gmail.com>
Message-ID: <20130705061802.GB10947@intel.com>

On Wed, Jul 03, 2013 at 11:27:12AM -0700, Olof Johansson wrote:
> This has now hit the mainline kernel, and several defconfigs (nhk815,
> lpc32xx and the spear ones) are broken there.
> 
> Vinod, when are you sending up your pull request with the fix? It'd be
> good to see it go in soon.
It should be on its way by the weekend

Thanks
~Vinod


From tony at atomide.com  Fri Jul  5 03:03:48 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 5 Jul 2013 00:03:48 -0700
Subject: [RFC 0/4] Cleanup PRM and CM regbit headers
In-Reply-To: <51D65CE8.4050004@ti.com>
References: <1372076143-12955-1-git-send-email-rnayak@ti.com>
 <20130625071428.GC5523@atomide.com> <51C95839.6050307@ti.com>
 <20130704115819.GJ5523@atomide.com> <51D56743.9080800@ti.com>
 <alpine.DEB.2.02.1307041627540.6258@utopia.booyaka.com>
 <51D65CE8.4050004@ti.com>
Message-ID: <20130705070347.GP5523@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130704 22:49]:
> On Thursday 04 July 2013 10:14 PM, Paul Walmsley wrote:
> > You mentioned that these patches were generated with some kind of awk/grep 
> > scripting.  Can you integrate that in an automated way into the 
> > autogeneration flow?  If the answer is yes, then keep the header.  If the 
> > answer is no, then the header should be dropped.  Beno?t, maybe you have 
> > an opinion too?
> 
> Ok, I'll try and integrate those scripts so all this can be done in an
> automated way even for newer SoCs.
> 
> > 
> > As far as whether this should go in -rcX or not, my view is that, as a 
> > matter of policy, large changes like this should wait until v3.12.  Now, 
> > having written that, I also was under the impression that the OMAP5 
> > changes weren't going to be sent upstream unless the total diffstat would 
> > be balanced to roughly zero or negative lines.  As far as I know, that 
> > didn't happen.  So I guess, v3.11-rc it is...  kernel development by 
> > diffstat :-(
> 
> I don't mind these going in -rcX or 3.12, either way is fine.

Removal of unused code should be OK for the early -rc. I doubt that
anybody would object it especially considering that's it's a huge
pile of unused defines that most likely won't ever be needed for
DT based booting.
 
> > Finally, please repost the whole series once you're done with your 
> > changes, as a non-RFC, along with your pull request (if you plan to send 
> > one).  I guess I should be the one to take these, since I wound up taking 
> > the OMAP5 addition...
> 
> :) I thought so too that you should be the one sending the pull.
> I will post these out as non-RFC after I do a clean integration into
> the autogen scripts, and then you can take a call on sending the pull for
> either -rcX or 3.12

I'd prefer to have it done now for the early -rc series. But if it
drags on, we should not merge it during the -rc series.

Regards,

Tony


From richard.genoud at gmail.com  Fri Jul  5 03:16:30 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Fri, 5 Jul 2013 09:16:30 +0200
Subject: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
In-Reply-To: <51D62074.9070303@atmel.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-2-git-send-email-richard.genoud@gmail.com>
 <51D24299.9050209@atmel.com>
 <CACQ1gAgcc=j3kmcpjp8bbdHhxr_k=h8jJs6R_paJbPUMv74uGg@mail.gmail.com>
 <51D29927.80900@atmel.com>
 <CACQ1gAhnDk-qSt_5xrsMakXqGGDO5pEbA-9UDWCJG=AABDc+zg@mail.gmail.com>
 <CACQ1gAgPaRm3gxxJNgfj9bR565Q0+SNY3+EcjA_mrh1N+yPzSA@mail.gmail.com>
 <51D4CC94.3020908@atmel.com>
 <CACQ1gAio0ekQMgyfrLjTHmMPGJQoKoe61GreFQDN-iLjxbLQ0w@mail.gmail.com>
 <51D62074.9070303@atmel.com>
Message-ID: <CACQ1gAjNGsAWMwyL_9zEobKz=MEzgiA7Gqt=p4anuGhq2dLd_w@mail.gmail.com>

2013/7/5 Bo Shen <voice.shen at atmel.com>:
> Yes, I aware this issue.
> Actually the system not hang, the resource all are occupied by the
> interrupt. This because, we enable the interrupt, when once interrupt occur,
> I try many methods to clear it, however we can not clear it. So, it
> generates the interrupt all the time. It seems the system hang.
>
> Temp solution: not enable the interrupt. use the following patch to disable
> the interrupt.
> ---8>---
> diff --git a/sound/soc/atmel/atmel_ssc_dai.c
> b/sound/soc/atmel/atmel_ssc_dai.c
> index 0ecf356..bb53dea 100644
> --- a/sound/soc/atmel/atmel_ssc_dai.c
> +++ b/sound/soc/atmel/atmel_ssc_dai.c
> @@ -649,7 +649,7 @@ static int atmel_ssc_prepare(struct snd_pcm_substream
> *substream,
>         dma_params = ssc_p->dma_params[dir];
>
>         ssc_writel(ssc_p->ssc->regs, CR, dma_params->mask->ssc_enable);
> -       ssc_writel(ssc_p->ssc->regs, IER, dma_params->mask->ssc_error);
> +       ssc_writel(ssc_p->ssc->regs, IDR, dma_params->mask->ssc_error);
>
>         pr_debug("%s enabled SSC_SR=0x%08x\n",
>                         dir ? "receive" : "transmit",
> ---<8---
>
> BTW, I am checking this with our IP team, if find the real solution, I will
> fix it.

ok, I'll rebase my patches on that.

Thanks !

Best Regards,
Richard


From oliver+list at schinagl.nl  Fri Jul  5 03:24:47 2013
From: oliver+list at schinagl.nl (Oliver Schinagl)
Date: Fri, 05 Jul 2013 09:24:47 +0200
Subject: [PATCH 1/2] Initial support for Allwinner's Security ID fuses
In-Reply-To: <20130626175144.GC2222@kroah.com>
References: <1371502778-15849-1-git-send-email-oliver+list@schinagl.nl>
 <1371502778-15849-2-git-send-email-oliver+list@schinagl.nl>
 <20130617225847.GA9494@kroah.com> <20130624092942.GG26008@lukather>
 <20130624160440.GA15201@kroah.com> <51C87DC7.50005@schinagl.nl>
 <20130624181509.GA8847@kroah.com> <51C8B84C.3020200@schinagl.nl>
 <20130624214615.GA17604@kroah.com> <51CAA709.4060801@schinagl.nl>
 <20130626175144.GC2222@kroah.com>
Message-ID: <51D674BF.9030207@schinagl.nl>

Hey Greg,

Thanks for the blog post :) it was very helpful and at least something 
good came from the less-nice bit of the discussion, but:

On 26-06-13 19:51, Greg KH wrote:
> On Wed, Jun 26, 2013 at 10:32:09AM +0200, Oliver Schinagl wrote:
>> On 24-06-13 23:46, Greg KH wrote:
>>> On Mon, Jun 24, 2013 at 11:21:16PM +0200, Oliver Schinagl wrote:
>>>> On 06/24/13 20:15, Greg KH wrote:
>>>>> On Mon, Jun 24, 2013 at 07:11:35PM +0200, Oliver Schinagl wrote:
>>>>>> Hey Greg,
>>>>>> On 06/24/13 18:04, Greg KH wrote:
>>>>>>> On Mon, Jun 24, 2013 at 11:29:42AM +0200, Maxime Ripard wrote:
>>>>>>>> Hi Greg,
>>>>>>>>
>>>>>>>> On Mon, Jun 17, 2013 at 03:58:47PM -0700, Greg KH wrote:
>>>>>>>>> On Mon, Jun 17, 2013 at 10:59:37PM +0200, Oliver Schinagl wrote:
>>>>>>>>
>>>>>>>> [..]
>>>>>>>>
>>>>>>>>>> +static int __init sunxi_sid_probe(struct platform_device *pdev)
>>>>>>>>>> +{
>>>>>>>>>> +	u8 entropy[SID_SIZE];
>>>>>>>>>> +	unsigned int i;
>>>>>>>>>> +	struct resource *res;
>>>>>>>>>> +	void __iomem *sid_reg_base;
>>>>>>>>>> +	int ret;
>>>>>>>>>> +
>>>>>>>>>> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>>>>>>>> +	sid_reg_base = devm_ioremap_resource(&pdev->dev, res);
>>>>>>>>>> +	if (IS_ERR(sid_reg_base))
>>>>>>>>>> +		return PTR_ERR(sid_reg_base);
>>>>>>>>>> +	platform_set_drvdata(pdev, sid_reg_base);
>>>>>>>>>> +
>>>>>>>>>> +	ret = device_create_bin_file(&pdev->dev, &sid_bin_attr);
>>>>>>>>>> +	if (ret)
>>>>>>>>>> +		return ret;
>>>>>>>>>
>>>>>>>>> You just raced with userspace, having the file show up after the device
>>>>>>>>> was announced to users that it was there.  Please use the proper device
>>>>>>>>> file api to add default attributes to prevent this from happening.
>>>>>>>>
>>>>>>>> Sorry if the question looks dumb, but what kind of race can we generate
>>>>>>>> here?
>>>>>>>
>>>>>>> Userspace gets told about the device from the driver core, udev runs and
>>>>>>> reads all of the attributes, then your probe function comes along and
>>>>>>> adds a new attribute.  Userspace will then not know about it at all.
>>>>>>>
>>>>>>>> The device_create_bin_file is the last call that we make (if we except
>>>>>>>> the entropy stuff, but it doesn't really matter here), so after we
>>>>>>>> created the file, we have everything properly initialised so that our
>>>>>>>> functions can be called, right?
>>>>>>>>
>>>>>>>> And another dumb question for you, what is the "proper device file API"
>>>>>>>> you are referring to ? :)
>>>>>>>
>>>>>>> Please read Documentation/driver_model/device.txt and see the section on
>>>>>>> Attributes for what to do.  If you have specific questions after reading
>>>>>>> that, please let me know.
>>>>>> Since Maxime kinda asked for me, I hope you don't mind me following up.
>>>>>>
>>>>>> That doc doesn't mention the binary interface at all. Initially I
>>>>>> had both devices up, the 'read' device as a textual representation
>>>>>> and added the binary one later. Maxime and I decided the binary one
>>>>>> made more sense, as the only textual user would be a human and they
>>>>>> don't poke that entry that often.
>>>>>>
>>>>>> So what default way exists for binary files or how would that be solved?
>>>>>
>>>>> The same interface should work just fine for binary files, have you
>>>>> tried it?
>>>> I'll just take the plunge and make myself look stupid ;)
>>>>
>>>> I tried to change things around, used DEVICE_ATTR(eeprom, S_IRUGO,
>>>> sid_read, NULL); So far so good I'd hope.
>>>
>>> Ick, no.
>>>
>>>> Of course now I'll have to change the function's parameters from
>>>>
>>>> static ssize_t sid_read(struct file *fd, struct kobject *kobj,
>>>> 			struct bin_attribute *attr, char *buf,
>>>> 			loff_t pos, size_t size)
>>>>
>>>> to
>>>>
>>>> static ssize_t sid_read(struct device *dev,
>>>> 			struct device_attribute *attr, char *buf)
>>>
>>> Which is what do you do not want, as you find out:
>>>
>>>> But now, I'm missing things like 'pos' and 'size', both which
>>>> determine the requested bytes. True, in this specific driver we are
>>>> talking about 'only' 16 bytes, but what if it weren't but a few MiB
>>>> and in sysfs we want to read some random byte, will we have to put
>>>> the entire blok into the buffer?
>>>>
>>>> So sorry for not understanding, but ... I don't understand :)
>>>
>>> Stick with a binary attribute, and attach that to the proper class
>>> structure and all should be fine.
>>>
>>> Ah crap, you're using a platform device.
>>>
>>> {sigh}
>>>
>>> Why?  Why not use a "real" device which has a "real" class, and then use
>>> the interfaces there?
>> Because, as I was told, this really is a platform device. If you
>> have some example code I can look at and learn from that would be
>> awesome. I'm still learning after all, and apparently I'm doing it
>> wrong now :)
>
> I was wrong, you can do this with a platform device just fine.  Set the
> "groups" field in your platform device->device structure, and all will
> work properly, right?
Not for me :(

Firstly, I have a platform_driver structure, but it has a .driver field 
and i can set the .groups field there just fine, as your blog post said 
I believe, so that got me on the right track.

static struct platform_driver sunxi_sid_driver = {
         .probe = sunxi_sid_probe,
         .remove = sunxi_sid_remove,
         .driver = {
                 .name = DRV_NAME,
                 .owner = THIS_MODULE,
                 .of_match_table = sunxi_sid_of_match,
                 .groups = sunxi_sid_attr_groups,
         },
};
module_platform_driver(sunxi_sid_driver);


After jumping through a few hoops, creating an array of 
attribute_groups, filling that with an array of attribute I finally can 
assign an attribute to .attr, but I have a bin_attribute.

static struct attribute *sunxi_sid_attrs[] = {
         &sid_bin_attr.attr,
         NULL,
};

static const struct attribute_group sunxi_sid_attr_group = {
         .attrs = sunxi_sid_attrs,
};

static const struct attribute_group *sunxi_sid_attr_groups[] = {
         &sunxi_sid_attr_group,
         NULL,
};

A feeble attempt to use the .attr from the bin_attribute makes it all 
crash naturally.

Being reminded of LDD3, chapter 14, section 2, re-reading sub-section 3) 
Binary Attributes

We clearly read:
"Binary attributes must be created explicitly; they cannot be set up as 
default attributes. To create a binary attribute, call:

int sysfs_create_bin_file();

Which brings us right back to where we started.

So I clearly am missing something ;)

The other 'broken' drivers that where linked earlier, also use the 
BINARY attributes.

So Greg, if you could be so kind and give me an example how to implement 
this properly, I am at loss and don't know :(

Oliver
>
> thanks,
>
> greg k-h
>



From js at sig21.net  Fri Jul  5 03:35:50 2013
From: js at sig21.net (Johannes Stezenbach)
Date: Fri, 5 Jul 2013 09:35:50 +0200
Subject: SPI: DUAL/QUAD support
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73E9E4C2E@DBDE04.ent.ti.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704130017.GA25997@sig21.net>
 <OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>
 <20130704154927.GE27646@sirena.org.uk>
 <OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>
 <CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>
 <20980858CB6D3A4BAE95CA194937D5E73E9E4C2E@DBDE04.ent.ti.com>
Message-ID: <20130705073550.GA24258@sig21.net>

On Fri, Jul 05, 2013 at 06:45:01AM +0000, Gupta, Pekon wrote:
> 
> > Just as Johannes said. In my patch m25p80's changes is incomplete.
> > Because my inicial aim is to add the transfer width member to tell controller
> > the mode flash in. And I will attach new patch about m25p80 later.
> > Also you are right. There are really series of flashes do not support dual/quad
> > transfer. So I don't know whether there are any standard for serial-flash just
> > like the CFI for parallel-flash. Personally, to make a general standard and
> > a general code for serial-flash is necessary. So that we do not need to add
> > special function in m25p80.c.
> > 
> [Pekon]: Does below generic framework for spianand, suit your driver?
> http://lists.infradead.org/pipermail/linux-mtd/2013-July/047434.html
> 
> you should be able to extend the generic spinand API for all
> serial modes (SPI, Dual-SPI, Quad-SPI).
> As QSPI and Dual-SPI devices should implicitly support SPI (MISO/MOSI)
> So, you can do device probing using default SPI mode. And then based on
> DT inputs and device support upgrade to QSPI / Dual-SPI mode.
> And going forward extend it for direct memory-mapped device for XIP.

Not sure what you have in mind since NAND and NOR flash work very
differently, and SPI vs. memory-mapped is also very different.

But to add to the spinand review comments two things caught
my eye on quick glance over the code:

> +#define mu_spi_nand_driver_version "Beagle-MTD_01.00_Linux2.6.33_20100507"

seems like an unused leftover?  if the version number is
important then maybe better put it in commit message?

> +/bin/bash: 4: command not found

how did this get in there?


Johannes


From maxime.ripard at free-electrons.com  Fri Jul  5 03:38:07 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 5 Jul 2013 09:38:07 +0200
Subject: [PATCH 0/3] Added support for On Chip OTP in i.MX23/28
In-Reply-To: <1372855154-8422-1-git-send-email-cb@sgoc.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
Message-ID: <20130705073807.GE2959@lukather>

Hi Christoph,

On Wed, Jul 03, 2013 at 02:39:11PM +0200, Christoph G. Baumann wrote:
> From: "Christoph G. Baumann" <cb at sgoc.de>
> 
> This patch contains the ported driver from Freescale for the On Chip OTP
> cells in the i.MX23 and i.MX28. The OTP cells can be read and written via
> files in /sys/fsl_otp.
> 
> Christoph G. Baumann (3):
>   Added support for On Chip OTP in i.MX23/28
>   Added support for On Chip OTP in i.MX23/28
>   Added support for On Chip OTP in i.MX23/28

You should use better commit logs here. There's no way to get what each
patch actually does from only looking at those lines.

You should probably have something like:
  misc: Add Freescale mxs On Chip OTP driver
  ARM: mxs: dt: Enable the OTP in the DTSI
  ...

This has two advantages: the review is easier since the reviewer
actually knows what each patch is doing and what to review, and most of
all, you get a cleaner and more complete history, so that in a few
month/years, you can get (ideally) all the context of this patch and
what it's actually doing without having to look into the code.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130705/bf3a310e/attachment.sig>

From axel.lin at ingics.com  Fri Jul  5 03:39:11 2013
From: axel.lin at ingics.com (Axel Lin)
Date: Fri, 05 Jul 2013 15:39:11 +0800
Subject: [PATCH] irqchip: nvic: Fix wrong num_ct argument for
 irq_alloc_domain_generic_chips()
Message-ID: <1373009951.14756.1.camel@phoenix>

The third parameter of irq_alloc_domain_generic_chips() is the number of
irq_chip_type instances associated with these chips rather than numbanks.

Signed-off-by: Axel Lin <axel.lin at ingics.com>
---
 drivers/irqchip/irq-nvic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
index 8d0c8b3..70bdf6e 100644
--- a/drivers/irqchip/irq-nvic.c
+++ b/drivers/irqchip/irq-nvic.c
@@ -84,7 +84,7 @@ static int __init nvic_of_init(struct device_node *node,
 		return -ENOMEM;
 	}
 
-	ret = irq_alloc_domain_generic_chips(nvic_irq_domain, 32, numbanks,
+	ret = irq_alloc_domain_generic_chips(nvic_irq_domain, 32, 1,
 					     "nvic_irq", handle_fasteoi_irq,
 					     clr, 0, IRQ_GC_INIT_MASK_CACHE);
 	if (ret) {
-- 
1.8.1.2





From sourav.poddar at ti.com  Fri Jul  5 03:40:01 2013
From: sourav.poddar at ti.com (Sourav Poddar)
Date: Fri, 5 Jul 2013 13:10:01 +0530
Subject: SPI: DUAL/QUAD support
In-Reply-To: <CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704130017.GA25997@sig21.net>
 <OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>
 <20130704154927.GE27646@sirena.org.uk>
 <OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>
 <CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>
Message-ID: <51D67851.8020402@ti.com>

On Friday 05 July 2013 11:55 AM, yuhang wang wrote:
> Hi Thomas:
>
>>> Well, there's two bits here.  One is the support in the client drivers
>>> for using the extra data lines and the other is the support in the SPI
>>> core for telling controllers to do this.  We need that second bit in
>>> place before the first one can be implemented.
>> I am not sure if we do. In the system I am working on, the QSPI controller
>> recognizes the quad mode commands from the Tx data and automatically
>> switches modes; no manual intervention by the flash driver is needed.
>>
>> I agree that this may not be the case for all SPI controllers. Yuhang, can
>> you tell us what your controller will do?
> OK, well my spi controller just sets the certain transfer mode in the register
> to make it in that mode(single,dual,quad). Then it will send and receive datas
> with the specific lines. As master, it should be told the transfer lines by the
> slave. Thus I need some members to deliver the information.
>

To add to all the discussion going on,
I am using a qspi controller with a spansion flash device.
I tried using quad read mode bit, and what is required to change in
my case is the following:

1. enable quad mode in flash configuration register.
2. change my read opcode to QUAD READ opcode according to flash datasheet.
3. Configure my qspi controller cmd reg to use 6 PIN whenever quad mode 
is used.

So,  I don't need to change things in spi framework to get
quad working. Though, as thomas also pointed out, it might
vary from controller to controller.

> But what you said "QSPI controller recognizes the quad mode commands
> from the Tx data and automatically switches modes;"  I can not figure out.
> The communication is launched by SPI master, so how can the controller
> recognizes the Tx data in the first transmission.
>
>> Yes, there are usually different opcodes, and as far as I know, they are
>> not supported by the m25p80 driver. It seems we are missing some
>> background info here.
>> My guess is that the flash chip in question is configured to treat single
>> mode opcodes as dual or quad mode commands (some chips support this), and
>> that the SPI controller needs to be told, for each transfer, which mode to
>> use.
> Just as Johannes said. In my patch m25p80's changes is incomplete.
> Because my inicial aim is to add the transfer width member to tell controller
> the mode flash in. And I will attach new patch about m25p80 later.
> Also you are right. There are really series of flashes do not support dual/quad
> transfer. So I don't know whether there are any standard for serial-flash just
> like the CFI for parallel-flash. Personally, to make a general standard and
> a general code for serial-flash is necessary. So that we do not need to add
> special function in m25p80.c.
>
> Thanks,
> yuhang
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/



From sourav.poddar at ti.com  Fri Jul  5 03:41:27 2013
From: sourav.poddar at ti.com (Sourav Poddar)
Date: Fri, 5 Jul 2013 13:11:27 +0530
Subject: SPI: DUAL/QUAD support
In-Reply-To: <20130705073550.GA24258@sig21.net>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704130017.GA25997@sig21.net>
 <OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>
 <20130704154927.GE27646@sirena.org.uk>
 <OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>
 <CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>
 <20980858CB6D3A4BAE95CA194937D5E73E9E4C2E@DBDE04.ent.ti.com>
 <20130705073550.GA24258@sig21.net>
Message-ID: <51D678A7.6050402@ti.com>

On Friday 05 July 2013 01:05 PM, Johannes Stezenbach wrote:
> On Fri, Jul 05, 2013 at 06:45:01AM +0000, Gupta, Pekon wrote:
>>> Just as Johannes said. In my patch m25p80's changes is incomplete.
>>> Because my inicial aim is to add the transfer width member to tell controller
>>> the mode flash in. And I will attach new patch about m25p80 later.
>>> Also you are right. There are really series of flashes do not support dual/quad
>>> transfer. So I don't know whether there are any standard for serial-flash just
>>> like the CFI for parallel-flash. Personally, to make a general standard and
>>> a general code for serial-flash is necessary. So that we do not need to add
>>> special function in m25p80.c.
>>>
>> [Pekon]: Does below generic framework for spianand, suit your driver?
>> http://lists.infradead.org/pipermail/linux-mtd/2013-July/047434.html
>>
>> you should be able to extend the generic spinand API for all
>> serial modes (SPI, Dual-SPI, Quad-SPI).
>> As QSPI and Dual-SPI devices should implicitly support SPI (MISO/MOSI)
>> So, you can do device probing using default SPI mode. And then based on
>> DT inputs and device support upgrade to QSPI / Dual-SPI mode.
>> And going forward extend it for direct memory-mapped device for XIP.
> Not sure what you have in mind since NAND and NOR flash work very
> differently, and SPI vs. memory-mapped is also very different.
>
> But to add to the spinand review comments two things caught
> my eye on quick glance over the code:
>
>> +#define mu_spi_nand_driver_version "Beagle-MTD_01.00_Linux2.6.33_20100507"
> seems like an unused leftover?  if the version number is
> important then maybe better put it in commit message?
>
Yes, actually its not required, should be removed.
>> +/bin/bash: 4: command not found
> how did this get in there?
>
>
Yes, this is useless, will  removed in the next version.
> Johannes



From coelho at ti.com  Fri Jul  5 03:54:13 2013
From: coelho at ti.com (Luciano Coelho)
Date: Fri, 5 Jul 2013 10:54:13 +0300
Subject: [RFC] clk: add flags to distinguish xtal clocks
In-Reply-To: <20130704231953.10823.94331@quantum>
References: <1372971912-10877-1-git-send-email-coelho@ti.com>
 <20130704222538.10823.2559@quantum>
 <1372977465.21065.136.camel@cumari.coelho.fi>
 <20130704231953.10823.94331@quantum>
Message-ID: <1373010853.21065.159.camel@cumari.coelho.fi>

On Thu, 2013-07-04 at 16:19 -0700, Mike Turquette wrote:
> Quoting Luciano Coelho (2013-07-04 15:37:45)
> > On Thu, 2013-07-04 at 15:25 -0700, Mike Turquette wrote:
> > > Or is it the same clock input and basically the problem is that you need
> > > to know what kind of waveform to expect (e.g. square versus sine)?
> > 
> > It's the same clock input in the chip's perspective.  One clock input
> > that can be any of the combinations I mentioned above.  Again, I'm not
> > familiar with clocks, so I guess the square vs. sine explanation is
> > plausible.  What I could see in the firmware is that it handles the
> > clocks differently if they're xtal or not.
> 
> OMAP has a similar thing where sys_clkin (the fast reference clock for
> the chip) can be 19.2, 26, 38.4, etc. This is easy to handle since only
> the rates matter.

Right, this part is easy and I already have the code for that.  What I'm
missing is a way to pass this XTAL flag to the chip.


> In your case you need some extra metadata to know what to do. I'm really
> not sure if CLK_IS_TYPE_XTAL is the most useful form this metadata can
> take. It would be best to know if the waveform is what you really need
> to know, or perhaps something else. For instance you might be affected
> by some clock signal stabilization time. Can you talk to your hardware
> guys and figure it out? I'd rather model the actual needs instead of
> just tossing a flag in there.

I get your point.  I have tried to investigate how this flag is used by
the firmware and I could see that it is used to set different "buffer
gains" and "delays" when waking up (I guess this means when the clock is
starting, so probably related to stabilization time).  They specify two
"modes", "boost" and "normal" and use different delay values for each.

As I said, I don't know almost anything about clocks, so all this
doesn't make much sense to me.  But maybe you can get an idea?

--
Cheers,
Luca.



From maxime.ripard at free-electrons.com  Fri Jul  5 04:03:51 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 5 Jul 2013 10:03:51 +0200
Subject: [PATCH 1/3] Added support for On Chip OTP in i.MX23/28
In-Reply-To: <1372855154-8422-2-git-send-email-cb@sgoc.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
 <1372855154-8422-2-git-send-email-cb@sgoc.de>
Message-ID: <20130705080351.GF2959@lukather>

Hi Christoph,

On Wed, Jul 03, 2013 at 02:39:12PM +0200, Christoph G. Baumann wrote:
> From: "Christoph G. Baumann" <cb at sgoc.de>
> 
> Signed-off-by: Christoph G. Baumann <cb at sgoc.de>
> ---
>  drivers/misc/fsl_otp.c |  249 ++++++++++++++++++++++++++++++++++++++++++++++++
>  drivers/misc/fsl_otp.h |  201 ++++++++++++++++++++++++++++++++++++++
>  2 files changed, 450 insertions(+)
>  create mode 100644 drivers/misc/fsl_otp.c
>  create mode 100644 drivers/misc/fsl_otp.h
> 
> diff --git a/drivers/misc/fsl_otp.c b/drivers/misc/fsl_otp.c
> new file mode 100644
> index 0000000..fd1941a
> --- /dev/null
> +++ b/drivers/misc/fsl_otp.c
> @@ -0,0 +1,249 @@
> +/*
> + * Freescale On-Chip OTP driver
> + *
> + * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * Ported to 3.7 by Christoph G. Baumann <cgb at debian.org>

Maybe it's not worth mentionning the version here, since it's wrong
anyway.

> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
> + */
> +#include <linux/kobject.h>
> +#include <linux/string.h>
> +#include <linux/sysfs.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/delay.h>
> +#include <linux/fcntl.h>
> +#include <linux/mutex.h>
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/slab.h>
> +#include <linux/platform_device.h>
> +
> +#include "fsl_otp.h"
> +
> +static DEFINE_MUTEX(otp_mutex);
> +static struct kobject *otp_kobj;
> +static struct attribute **attrs;
> +static struct kobj_attribute *kattr;
> +static struct attribute_group attr_group;
> +
> +static inline unsigned int get_reg_index(struct kobj_attribute *tmp)
> +{
> +	return tmp - kattr;
> +}
> +
> +static int otp_wait_busy(u32 flags)
> +{
> +	int count;
> +	u32 c;
> +
> +	for (count = 10000; count >= 0; count--) {
> +		c = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CTRL);
> +		if (!(c & (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR | flags)))
> +			break;
> +		cpu_relax();
> +	}
> +
> +	if (count < 0)
> +		return -ETIMEDOUT;
> +	return 0;
> +}
> +
> +static ssize_t otp_show(struct kobject *kobj, struct kobj_attribute *attr,
> +		      char *buf)
> +{
> +	unsigned int index = get_reg_index(attr);
> +	u32 value = 0;
> +
> +	/* sanity check */
> +	if (index >= otp_data.fuse_num)
> +		return 0;
> +
> +	mutex_lock(&otp_mutex);
> +
> +	if (otp_read_prepare()) {
> +		mutex_unlock(&otp_mutex);
> +		return 0;
> +	}
> +	value = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CUST_N(index));
> +	otp_read_post();
> +
> +	mutex_unlock(&otp_mutex);
> +	return sprintf(buf, "0x%x\n", value);
> +}
> +
> +static int otp_write_bits(int addr, u32 data, u32 magic)
> +{
> +	u32 c; /* for control register */
> +
> +	/* init the control register */
> +	c = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CTRL);
> +	c &= ~BM_OCOTP_CTRL_ADDR;
> +	c |= BF(addr, OCOTP_CTRL_ADDR);
> +	c |= BF(magic, OCOTP_CTRL_WR_UNLOCK);
> +	__raw_writel(c, REGS_OCOTP_BASE + HW_OCOTP_CTRL);
> +
> +	/* init the data register */
> +	__raw_writel(data, REGS_OCOTP_BASE + HW_OCOTP_DATA);

You shouldn't use __raw_readl/__raw_writel directly here, but
readl/writel. The __raw_* functions lack the endianness conversions and
the memory barrier readl has.

> +	otp_wait_busy(0);
> +
> +	mdelay(2); /* Write Postamble */

Why do you need the mdelay after your call to otp_wait_busy ?

> +	return 0;
> +}
> +
> +static ssize_t otp_store(struct kobject *kobj, struct kobj_attribute *attr,
> +		       const char *buf, size_t count)
> +{
> +	unsigned int index = get_reg_index(attr);
> +	int value;
> +
> +	/* sanity check */
> +	if (index >= otp_data.fuse_num)
> +		return 0;
> +
> +	sscanf(buf, "0x%x", &value);
> +
> +	mutex_lock(&otp_mutex);
> +	if (otp_write_prepare()) {
> +		mutex_unlock(&otp_mutex);
> +		return 0;
> +	}
> +	otp_write_bits(index, value, 0x3e77);

What's that magic value?

> +	otp_write_post();
> +	mutex_unlock(&otp_mutex);
> +
> +	return count;
> +}
> +
> +static void free_otp_attr(void)
> +{
> +	kfree(attrs);
> +	attrs = NULL;
> +
> +	kfree(kattr);
> +	kattr = NULL;
> +}
> +
> +static int alloc_otp_attr(void)
> +{
> +	int i;
> +
> +	/* The last one is NULL, which is used to detect the end */
> +	attrs = kzalloc((otp_data.fuse_num + 1) * sizeof(attrs[0]),
> +			GFP_KERNEL);
> +	kattr = kzalloc(otp_data.fuse_num * sizeof(struct kobj_attribute),
> +			GFP_KERNEL);
> +
> +	if (!attrs || !kattr)
> +		goto error_out;
> +
> +	for (i = 0; i < otp_data.fuse_num; i++) {
> +		kattr[i].attr.name = otp_data.fuse_name[i];
> +		kattr[i].attr.mode = 0600;
> +		kattr[i].show  = otp_show;
> +		kattr[i].store = otp_store;
> +		attrs[i] = &kattr[i].attr;
> +		sysfs_attr_init(attrs[i]);
> +	}
> +	memset(&attr_group, 0, sizeof(attr_group));
> +	attr_group.attrs = attrs;
> +	return 0;
> +
> +error_out:
> +	free_otp_attr();
> +	return -ENOMEM;
> +}
> +
> +static int fsl_otp_probe(struct platform_device *pdev)

Your function names could use some common prefix, it's a bit messy for
now. You have:
  - free_otp_*
  - otp_*
  - fsl_otp_*

You could use the prefix mxs_otp for all your functions, for example.

> +{
> +	int retval;
> +	struct fsl_otp_data *pdata;
> +
> +
> +	pdata = &otp_data;
> +	if (pdev->dev.platform_data == NULL)
> +		pdev->dev.platform_data = &otp_data;

Where is that otp_data coming from?

> +
> +	retval = alloc_otp_attr();
> +	if (retval)
> +		return retval;
> +
> +	retval = map_ocotp_addr(pdev);
> +	if (retval)
> +		goto error;
> +
> +	otp_kobj = kobject_create_and_add("fsl_otp", NULL);
> +	if (!otp_kobj) {
> +		retval = -ENOMEM;
> +		goto error;
> +	}
> +
> +	retval = sysfs_create_group(otp_kobj, &attr_group);
> +	if (retval)
> +		goto error;
> +
> +	mutex_init(&otp_mutex);
> +	return 0;
> +error:
> +	kobject_put(otp_kobj);
> +	otp_kobj = NULL;
> +	free_otp_attr();
> +	unmap_ocotp_addr();

Where is that unmap_ocotp_addr function declared?

> +	return retval;
> +}
> +
> +static int otp_remove(struct platform_device *pdev)
> +{
> +	kobject_put(otp_kobj);
> +	otp_kobj = NULL;
> +
> +	free_otp_attr();
> +	unmap_ocotp_addr();

Ditto.

> +	return 0;
> +}
> +
> +static const struct of_device_id mxs_otp_dt_ids[] = {
> +	{ .compatible = "fsl,ocotp", .data = NULL, },
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mxs_otp_dt_ids);
> +
> +static struct platform_driver ocotp_driver = {
> +	.probe		= fsl_otp_probe,
> +	.remove		= otp_remove,
> +	.driver		= {
> +		.name   = "ocotp",
> +		.owner	= THIS_MODULE,
> +		.of_match_table = mxs_otp_dt_ids,
> +	},
> +};
> +
> +static int __init fsl_otp_init(void)
> +{
> +	return platform_driver_register(&ocotp_driver);
> +}
> +
> +static void __exit fsl_otp_exit(void)
> +{
> +	platform_driver_unregister(&ocotp_driver);
> +}
> +module_init(fsl_otp_init);
> +module_exit(fsl_otp_exit);

You can use module_platform_driver here to remove all this boilerplate
code.

> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Huang Shijie <b32955 at freescale.com>");
> +MODULE_DESCRIPTION("Common driver for OTP controller");
> diff --git a/drivers/misc/fsl_otp.h b/drivers/misc/fsl_otp.h
> new file mode 100644
> index 0000000..b429479
> --- /dev/null
> +++ b/drivers/misc/fsl_otp.h
> @@ -0,0 +1,201 @@
> +/*
> + * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * Ported to 3.7 by Christoph G. Baumann <cgb at debian.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This 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.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +#ifndef __FREESCALE_OTP__
> +#define __FREESCALE_OTP__
> +
> +
> +static int otp_wait_busy(u32 flags);
> +
> +/* IMX23 and IMX28 share most of the defination ========================= */
> +#if (defined(CONFIG_SOC_IMX23) || defined(CONFIG_SOC_IMX28))
> +
> +#if defined(CONFIG_SOC_IMX28) && defined(CONFIG_SOC_IMX23)
> +#undef CONFIG_SOC_IMX23
> +#endif
> +
> +#include <linux/regulator/consumer.h>
> +#include <mach/hardware.h>
> +#include <mach/mxs.h>
> +
> +#if defined(CONFIG_SOC_IMX23)
> +#include <mach/mx23.h>
> +#include <mach/mx23-ocotp.h>
> +#else
> +#include <mach/mx28.h>
> +#include <mach/mx28-ocotp.h>
> +#endif

Are you even sure it compiles? These headers don't exist.

Also, now that the mxs platform enabled multi-platform support, you have
to keep in mind that this driver can be used on both an imx23 *and* an
imx28 at run time, so all these compile-time options should be removed.

> +#define OCOTP_PHYS_ADDR         MXS_OCOTP_BASE_ADDR
> +#define REGS_OCOTP_BASE		(MXS_IO_ADDRESS(OCOTP_PHYS_ADDR))
> +#define BF(value, field)	(((value) << BP_##field) & BM_##field)
> +
> +#if defined(CONFIG_SOC_IMX28)
> +/* Building up eight registers's names of a bank */
> +#define MXS_OTP_BANK(a, b, c, d, e, f, g, h)	\
> +	{\
> +	("HW_OCOTP_"#a), ("HW_OCOTP_"#b), ("HW_OCOTP_"#c), ("HW_OCOTP_"#d), \
> +	("HW_OCOTP_"#e), ("HW_OCOTP_"#f), ("HW_OCOTP_"#g), ("HW_OCOTP_"#h) \
> +	}
> +
> +#define MXS_OTP_BANKS		(5)
> +#define MXS_OTP_BANK_ITEMS	(8)
> +static const char *bank_reg_desc[MXS_OTP_BANKS][MXS_OTP_BANK_ITEMS] = {
> +MXS_OTP_BANK(CUST0, CUST1, CUST2, CUST3, CRYPTO0, CRYPTO1, CRYPTO2, CRYPTO3),
> +MXS_OTP_BANK(HWCAP0, HWCAP1, HWCAP2, HWCAP3, HWCAP4, HWCAP5, SWCAP, CUSTCAP),
> +MXS_OTP_BANK(LOCK, OPS0, OPS1, OPS2, OPS3, UN0, UN1, UN2),
> +MXS_OTP_BANK(ROM0, ROM1, ROM2, ROM3, ROM4, ROM5, ROM6, ROM7),
> +MXS_OTP_BANK(SRK0, SRK1, SRK2, SRK3, SRK4, SRK5, SRK6, SRK7),
> +};
> +#endif /* if defined(CONFIG_SOC_IMX28) */
> +
> +
> +#if defined(CONFIG_SOC_IMX23)
> +/* Building up eight registers's names of a bank */
> +#define MXS_OTP_BANK(a, b, c, d, e, f, g, h)	\
> +	{\
> +	("HW_OCOTP_"#a), ("HW_OCOTP_"#b), ("HW_OCOTP_"#c), ("HW_OCOTP_"#d), \
> +	("HW_OCOTP_"#e), ("HW_OCOTP_"#f), ("HW_OCOTP_"#g), ("HW_OCOTP_"#h) \
> +	}
> +
> +#define MXS_OTP_BANKS		(4)
> +#define MXS_OTP_BANK_ITEMS	(8)
> +static const char *bank_reg_desc[MXS_OTP_BANKS][MXS_OTP_BANK_ITEMS] = {
> +MXS_OTP_BANK(CUST0, CUST1, CUST2, CUST3, CRYPTO0, CRYPTO1, CRYPTO2, CRYPTO3),
> +MXS_OTP_BANK(HWCAP0, HWCAP1, HWCAP2, HWCAP3, HWCAP4, HWCAP5, SWCAP, CUSTCAP),
> +MXS_OTP_BANK(LOCK, OPS0, OPS1, OPS2, OPS3, UN0, UN1, UN2),
> +MXS_OTP_BANK(ROM0, ROM1, ROM2, ROM3, ROM4, ROM5, ROM6, ROM7),
> +};
> +
> +#endif/* if defined(CONFIG_SOC_IMX23) */
> +
> +static unsigned long otp_hclk_saved;
> +static u32 otp_voltage_saved;
> +struct regulator *regu;
> +
> +struct fsl_otp_data {
> +	char		**fuse_name;
> +	char		*regulator_name;
> +	unsigned int	fuse_num;
> +};
> +
> +static struct fsl_otp_data otp_data = {
> +	.fuse_name	= (char **)bank_reg_desc,
> +	.regulator_name	= "vddio-sd0",
> +	.fuse_num	= MXS_OTP_BANKS * MXS_OTP_BANK_ITEMS,
> +};
> +
> +/* open the bank for the imx23/imx28 */
> +static int otp_read_prepare(void)
> +{
> +	int r;
> +
> +	/* [1] set the HCLK */
> +	/* [2] check BUSY and ERROR bit */
> +	r = otp_wait_busy(0);
> +	if (r < 0)
> +		goto error;
> +
> +	/* [3] open bank */
> +	__raw_writel(BM_OCOTP_CTRL_RD_BANK_OPEN,
> +		REGS_OCOTP_BASE + HW_OCOTP_CTRL_SET);
> +	udelay(10);
> +
> +	/* [4] wait for BUSY */
> +	r = otp_wait_busy(0);
> +	return 0;
> +error:
> +	return r;
> +}
> +
> +static int otp_read_post(void)
> +{
> +	/* [5] close bank */
> +	__raw_writel(BM_OCOTP_CTRL_RD_BANK_OPEN,
> +		REGS_OCOTP_BASE + HW_OCOTP_CTRL_CLR);
> +	return 0;
> +}
> +
> +static int otp_write_prepare(void)
> +{
> +	struct clk *hclk;
> +	int err = 0;
> +
> +	/* [1] HCLK to 24MHz. */
> +	hclk = clk_get_sys("hbus", NULL);
> +	if (IS_ERR(hclk)) {
> +		err = PTR_ERR(hclk);
> +		goto out;
> +	}
> +	/*
> +	   WARNING  ACHTUNG  UWAGA
> +
> +	   the code below changes HCLK clock rate to 24M. This is
> +	   required to write OTP bits (7.2.2 in STMP378x Target
> +	   Specification), and might affect LCD operation, for example.
> +	   Moreover, this hacky code changes VDDIO to 2.8V; and resto-
> +	   res it only on otp_close(). This may affect... anything.
> +
> +	   You are warned now.
> +	 */
> +	otp_hclk_saved = clk_get_rate(hclk);
> +	clk_set_rate(hclk, 24000000);
> +
> +	/* [2] The voltage is set to 2.8V */
> +	regu = regulator_get(NULL, otp_data.regulator_name);
> +	otp_voltage_saved = regulator_get_voltage(regu);
> +	regulator_set_voltage(regu, 2800000, 2800000);
> +
> +	/* [3] wait for BUSY and ERROR */
> +	err = otp_wait_busy(BM_OCOTP_CTRL_RD_BANK_OPEN);
> +out:
> +	return err;
> +}
> +
> +static int otp_write_post(void)
> +{
> +	struct clk *hclk;
> +
> +	hclk = clk_get_sys("hbus", NULL);
> +	if (IS_ERR(hclk))
> +		return PTR_ERR(hclk);
> +
> +	/* restore the clock and voltage */
> +	clk_set_rate(hclk, otp_hclk_saved);
> +	regulator_set_voltage(regu, otp_voltage_saved, otp_voltage_saved);
> +	otp_wait_busy(0);
> +
> +	/* reset */
> +	__raw_writel(BM_OCOTP_CTRL_RELOAD_SHADOWS,
> +			REGS_OCOTP_BASE + HW_OCOTP_CTRL_SET);
> +	otp_wait_busy(BM_OCOTP_CTRL_RELOAD_SHADOWS);
> +	return 0;
> +}
> +
> +static int __init map_ocotp_addr(struct platform_device *pdev)
> +{
> +	return 0;
> +}
> +static void unmap_ocotp_addr(void)
> +{
> +}

Ah, so here are your functions and structures. Putting !inline functions
in a header is considered a bad practice, so you should move them in the
driver directly.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130705/4bca9dbb/attachment.sig>

From pekon at ti.com  Fri Jul  5 04:04:31 2013
From: pekon at ti.com (Gupta, Pekon)
Date: Fri, 5 Jul 2013 08:04:31 +0000
Subject: SPI: DUAL/QUAD support
In-Reply-To: <20130705073550.GA24258@sig21.net>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704130017.GA25997@sig21.net>
 <OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>
 <20130704154927.GE27646@sirena.org.uk>
 <OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>
 <CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>
 <20980858CB6D3A4BAE95CA194937D5E73E9E4C2E@DBDE04.ent.ti.com>
 <20130705073550.GA24258@sig21.net>
Message-ID: <20980858CB6D3A4BAE95CA194937D5E73E9E4C7D@DBDE04.ent.ti.com>

> > [Pekon]: Does below generic framework for spianand, suit your driver?
> > http://lists.infradead.org/pipermail/linux-mtd/2013-July/047434.html
> >
> > you should be able to extend the generic spinand API for all
> > serial modes (SPI, Dual-SPI, Quad-SPI).
> > As QSPI and Dual-SPI devices should implicitly support SPI (MISO/MOSI)
> > So, you can do device probing using default SPI mode. And then based on
> > DT inputs and device support upgrade to QSPI / Dual-SPI mode.
> > And going forward extend it for direct memory-mapped device for XIP.
> 
> Not sure what you have in mind since NAND and NOR flash work very
> differently, and SPI vs. memory-mapped is also very different.
> 
[Pekon]:  Opps.. Sorry for NAND v/s NOR confusion,
But I found generic framework for SPINAND (not in mainline) helpful
for us, so I pointed that..
I'm not sure about your end use-case, but I our QSPI controller supports
direct memory-addressable cpu-side bus-interface which can be enabled
for XIP support. So pointed out that here as-well..


> But to add to the spinand review comments two things caught
> my eye on quick glance over the code:
> 
> > +#define mu_spi_nand_driver_version "Beagle-
> MTD_01.00_Linux2.6.33_20100507"
> 
> seems like an unused leftover?  if the version number is
> important then maybe better put it in commit message?
> 
> > +/bin/bash: 4: command not found
> 
> how did this get in there?
> 
[Pekon]: Thanks.. Sourav needs to clean this up lot more.

with regards, pekon



From l.majewski at samsung.com  Fri Jul  5 04:08:08 2013
From: l.majewski at samsung.com (Lukasz Majewski)
Date: Fri, 05 Jul 2013 10:08:08 +0200
Subject: [PATCH] mmc: sdhci: request irq after sdhci_init() is called
In-Reply-To: <1373006335-31239-1-git-send-email-shawn.guo@linaro.org>
References: <1373006335-31239-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130705100808.6966c8ca@amdc308.digital.local>

On Fri, 05 Jul 2013 14:38:55 +0800, Shawn Guo wrote:
> Generally request_irq() should be called after hardware has been
> initialized into a sane state.  However, sdhci driver currently calls
> request_irq() before sdhci_init().  At least, the following kernel
> panic seen on i.MX6 is caused by that.  The sdhci controller on i.MX6
> may have noisy glitch on DAT1 line, which will trigger SDIO interrupt
> handling once request_irq() is called.  But at this point, the SDIO
> interrupt handler host->sdio_irq_thread has not been registered yet.
> Thus, we see the NULL pointer access with
> wake_up_process(host->sdio_irq_thread) in mmc_signal_sdio_irq().

Thanks for fixing it.
I had exactly the same problem with Samsung devices. 

My fix was to mask the unneeded (for eMMC) SDIO interrupt at the
u-boot bootloader (patches to fix this are already at u-boot mainline). 

But anyway thanks for the kernel fix.

> 
> sdhci-pltfm: SDHCI platform and OF driver helper
> mmc0: no vqmmc regulator found
> mmc0: no vmmc regulator found
> Unable to handle kernel NULL pointer dereference at virtual address
> 00000000 pgd = 80004000
> [00000000] *pgd=00000000
> Internal error: Oops: 5 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0+ #3
> task: 9f860000 ti: 9f862000 task.ti: 9f862000
> PC is at wake_up_process+0xc/0x44
> LR is at sdhci_irq+0x378/0x93c
> pc : [<8004f768>]    lr : [<803fb698>]    psr: 40000193
> sp : 9f863ba0  ip : 9f863bb8  fp : 9f863bb4
> r10: 9f807900  r9 : 80761fbc  r8 : 00000000
> r7 : 00000000  r6 : 00000000  r5 : 00000001  r4 : 9fa68000
> r3 : 00000001  r2 : 00000002  r1 : 20000193  r0 : 00000000
> Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c53c7d  Table: 8000404a  DAC: 00000017
> Process swapper/0 (pid: 1, stack limit = 0x9f862238)
> Stack: (0x9f863ba0 to 0x9f864000)
> 3ba0: 00000001 9fa68000 9f863c04 9f863bb8 803fb698 8004f768 8011af00
> 80265aac 3bc0: 00000000 000003d9 00000000 9fa51880 00000001 00000000
> 9f863c14 9fa53640 3be0: 00000001 00000000 00000000 00000036 80761fbc
> 9f807900 9f863c3c 9f863c08 3c00: 80075154 803fb32c 802c2b38 802c63d8
> 802c63cc 9f807900 00000001 9f862000 3c20: 00000036 00000000 9f807930
> 60000113 9f863c54 9f863c40 800752ec 8007510c 3c40: 9f807900 00000001
> 9f863c6c 9f863c58 80078324 800752a8 00000036 8071fd64 3c60: 9f863c84
> 9f863c70 80074ac0 80078294 00000140 8072ab78 9f863cac 9f863c88 3c80:
> 8000ee34 80074aa4 00000000 a080e10c 8072acbc 9f863cd0 a080e100
> 00000036 3ca0: 9f863ccc 9f863cb0 80008600 8000edec 805386a8 60000113
> ffffffff 9f863d04 3cc0: 9f863d24 9f863cd0 8000e0c0 800085dc 9f807950
> 60000113 00000007 00000000 3ce0: 9f807900 9fa53640 9f807950 9fa68240
> 00000036 9f807930 60000113 9f863d24 3d00: 9f863d28 9f863d18 80076834
> 805386a8 60000113 ffffffff 9f863d64 9f863d28 3d20: 80076834 80538688
> 00000000 800bfe4c 00002fac 00000001 9f863d54 9fa53640 3d40: 9f807900
> 803fb320 9fa68240 00000080 00000000 00000036 9f863d94 9f863d68 3d60:
> 80076b38 80076674 00000080 9fa68240 9fa68000 04000000 9fa6836c
> 9fa68380 3d80: 806d620c 80700350 9f863dc4 9f863d98 803fce8c 80076a88
> 9fa532c0 9fa68240 3da0: 9fa51490 9fa51490 9fa68240 00000000 9f8ae600
> 9f81d080 9f863df4 9f863dc8 3dc0: 803fea0c 803fc808 9f863de4 9f863dd8
> 80125850 807b1ed8 807576b8 9f8ae610 3de0: 00000000 807576b8 9f863e04
> 9f863df8 802ee0d4 803fe798 9f863e2c 9f863e08 3e00: 802ecd1c 802ee0c0
> 00000000 9f8ae610 807576b8 9f8ae644 00000000 000000a9 3e20: 9f863e4c
> 9f863e30 802ecec0 802ecc30 9f83355c 807576b8 802ece2c 00000000 3e40:
> 9f863e74 9f863e50 802eb3d8 802ece38 9f83355c 9f8ac3b4 9f833570
> 807576b8 3e60: 80746e70 9fa51400 9f863e84 9f863e78 802ec838 802eb388
> 9f863eb4 9f863e88 3e80: 802ec3d0 802ec824 80692748 807620c0 9f863eb4
> 807576b8 00000006 807620c0 3ea0: 00000000 000000a9 9f863edc 9f863eb8
> 802ed3e8 802ec2fc 9f862000 00000006 3ec0: 807620c0 00000000 000000a9
> 80700350 9f863eec 9f863ee0 802ee2f8 802ed374 3ee0: 9f863efc 9f863ef0
> 80700364 802ee2b8 9f863f54 9f863f00 8000870c 8070035c 3f00: 9f863f54
> 9f863f10 9f862000 00000000 00000000 00000006 00000006 806d3aa4 3f20:
> 00000000 80688b18 9f863f54 80713560 00000006 80713540 807620c0
> 000000a9 3f40: 806d620c 8071ec24 9f863f94 9f863f58 806d6994 800086dc
> 00000006 00000006 3f60: 806d620c f6bfffff fb7f5df7 00000000 8052da28
> 00000000 00000000 00000000 3f80: 00000000 00000000 9f863fac 9f863f98
> 8052da38 806d689c ffffffff 00000000 3fa0: 00000000 9f863fb0 8000e5d8
> 8052da34 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000
> 00000000 00000000 00000000 00000013 00000000 d9cdf5ff 1fff5ffe
> Backtrace: [<8004f75c>] (wake_up_process+0x0/0x44) from [<803fb698>]
> (sdhci_irq+0x378/0x93c) r4:9fa68000 r3:00000001 [<803fb320>]
> (sdhci_irq+0x0/0x93c) from [<80075154>]
> (handle_irq_event_percpu+0x54/0x19c) [<80075100>]
> (handle_irq_event_percpu+0x0/0x19c) from [<800752ec>]
> (handle_irq_event+0x50/0x70) [<8007529c>] (handle_irq_event+0x0/0x70)
> from [<80078324>] (handle_fasteoi_irq+0x9c/0x170) r5:00000001
> r4:9f807900 [<80078288>] (handle_fasteoi_irq+0x0/0x170) from
> [<80074ac0>] (generic_handle_irq+0x28/0x38) r5:8071fd64 r4:00000036
> [<80074a98>] (generic_handle_irq+0x0/0x38) from [<8000ee34>]
> (handle_IRQ+0x54/0xb4) r4:8072ab78 r3:00000140 [<8000ede0>]
> (handle_IRQ+0x0/0xb4) from [<80008600>] (gic_handle_irq+0x30/0x64)
> r8:00000036 r7:a080e100 r6:9f863cd0 r5:8072acbc r4:a080e10c
> r3:00000000 [<800085d0>] (gic_handle_irq+0x0/0x64) from [<8000e0c0>]
> (__irq_svc+0x40/0x54) Exception stack(0x9f863cd0 to 0x9f863d18)
> 3cc0:                                     9f807950 60000113 00000007
> 00000000 3ce0: 9f807900 9fa53640 9f807950 9fa68240 00000036 9f807930
> 60000113 9f863d24 3d00: 9f863d28 9f863d18 80076834 805386a8 60000113
> ffffffff r7:9f863d04 r6:ffffffff r5:60000113 r4:805386a8 [<8053867c>]
> (_raw_spin_unlock_irqrestore+0x0/0x30) from [<80076834>]
> (__setup_irq+0x1cc/0x414) [<80076668>] (__setup_irq+0x0/0x414) from
> [<80076b38>] (request_threaded_irq+0xbc/0x140) [<80076a7c>]
> (request_threaded_irq+0x0/0x140) from [<803fce8c>]
> (sdhci_add_host+0x690/0xb88) [<803fc7fc>] (sdhci_add_host+0x0/0xb88)
> from [<803fea0c>] (sdhci_esdhc_imx_probe+0x280/0x4d4) r8:9f81d080
> r7:9f8ae600 r6:00000000 r5:9fa68240 r4:9fa51490 [<803fe78c>]
> (sdhci_esdhc_imx_probe+0x0/0x4d4) from [<802ee0d4>]
> (platform_drv_probe+0x20/0x24) r8:807576b8 r7:00000000 r6:9f8ae610
> r5:807576b8 r4:807b1ed8 [<802ee0b4>] (platform_drv_probe+0x0/0x24)
> from [<802ecd1c>] (driver_probe_device+0xf8/0x208) [<802ecc24>]
> (driver_probe_device+0x0/0x208) from [<802ecec0>]
> (__driver_attach+0x94/0x98) r8:000000a9 r7:00000000 r6:9f8ae644
> r5:807576b8 r4:9f8ae610 r3:00000000 [<802ece2c>]
> (__driver_attach+0x0/0x98) from [<802eb3d8>]
> (bus_for_each_dev+0x5c/0x90) r6:00000000 r5:802ece2c r4:807576b8
> r3:9f83355c [<802eb37c>] (bus_for_each_dev+0x0/0x90) from
> [<802ec838>] (driver_attach+0x20/0x28) r6:9fa51400 r5:80746e70
> r4:807576b8 [<802ec818>] (driver_attach+0x0/0x28) from [<802ec3d0>]
> (bus_add_driver+0xe0/0x234) [<802ec2f0>] (bus_add_driver+0x0/0x234)
> from [<802ed3e8>] (driver_register+0x80/0x14c) r8:000000a9
> r7:00000000 r6:807620c0 r5:00000006 r4:807576b8 [<802ed368>]
> (driver_register+0x0/0x14c) from [<802ee2f8>]
> (platform_driver_register+0x4c/0x60) [<802ee2ac>]
> (platform_driver_register+0x0/0x60) from [<80700364>]
> (sdhci_esdhc_imx_driver_init+0x14/0x1c) [<80700350>]
> (sdhci_esdhc_imx_driver_init+0x0/0x1c) from [<8000870c>]
> (do_one_initcall+0x3c/0x164) [<800086d0>] (do_one_initcall+0x0/0x164)
> from [<806d6994>] (kernel_init_freeable+0x104/0x1d0) [<806d6890>]
> (kernel_init_freeable+0x0/0x1d0) from [<8052da38>]
> (kernel_init+0x10/0xec) [<8052da28>] (kernel_init+0x0/0xec) from
> [<8000e5d8>] (ret_from_fork+0x14/0x3c) r4:00000000 r3:ffffffff Code:
> e89da800 e1a0c00d e92dd818 e24cb004 (e5903000) ---[ end trace
> e9af3588936b63f0 ]--- Kernel panic - not syncing: Fatal exception in
> interrupt
> 
> Fix the panic by simply reverse the calling sequence between
> request_irq() and sdhci_init().
> 
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> ---
>  drivers/mmc/host/sdhci.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 2ea429c..a821b71 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -3174,6 +3174,8 @@ int sdhci_add_host(struct sdhci_host *host)
>  		host->tuning_timer.function = sdhci_tuning_timer;
>  	}
>  
> +	sdhci_init(host, 0);
> +
>  	ret = request_irq(host->irq, sdhci_irq, IRQF_SHARED,
>  		mmc_hostname(mmc), host);
>  	if (ret) {
> @@ -3182,8 +3184,6 @@ int sdhci_add_host(struct sdhci_host *host)
>  		goto untasklet;
>  	}
>  
> -	sdhci_init(host, 0);
> -
>  #ifdef CONFIG_MMC_DEBUG
>  	sdhci_dumpregs(host);
>  #endif


-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group


From maxime.ripard at free-electrons.com  Fri Jul  5 04:08:42 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 5 Jul 2013 10:08:42 +0200
Subject: [PATCH 2/3] Added support for On Chip OTP in i.MX23/28
In-Reply-To: <1372855154-8422-3-git-send-email-cb@sgoc.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
 <1372855154-8422-3-git-send-email-cb@sgoc.de>
Message-ID: <20130705080842.GG2959@lukather>

Hi Christoph,

On Wed, Jul 03, 2013 at 02:39:13PM +0200, Christoph G. Baumann wrote:
> From: "Christoph G. Baumann" <cb at sgoc.de>
> 
> Signed-off-by: Christoph G. Baumann <cb at sgoc.de>
> ---
>  arch/arm/mach-mxs/include/mach/mx23-ocotp.h |  311 +++++++++++++++++++++++++++
>  arch/arm/mach-mxs/include/mach/mx28-ocotp.h |  239 ++++++++++++++++++++
>  2 files changed, 550 insertions(+)
>  create mode 100644 arch/arm/mach-mxs/include/mach/mx23-ocotp.h
>  create mode 100644 arch/arm/mach-mxs/include/mach/mx28-ocotp.h

Ah. Here are your includes.

Two things then:
  - Like I said in my previous mail, the include/mach doesn't play well
    with the multi-platform kernels. How should you choose one header
    instead of another in this case, or even one mach/ directory or
    another if you have several platforms enabled.
  - From what I can recall, the OCOTP is only something like a few MMIO
    bytes to access, with a bit of logic when writing, but nothing more
    than a few registers and a few bits in there. Are you sure you
    actually need 550 lines of define for only a dozen defines or so?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130705/db5ffe9a/attachment.sig>

From vaibhav.bedia at ti.com  Fri Jul  5 04:11:00 2013
From: vaibhav.bedia at ti.com (Bedia, Vaibhav)
Date: Fri, 5 Jul 2013 08:11:00 +0000
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51D59C0E.8080003@newflow.co.uk>
References: <51D577E6.5010507@newflow.co.uk>
 <51D59146.3070002@newflow.co.uk> <51D59C0E.8080003@newflow.co.uk>
Message-ID: <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>

On Thu, Jul 04, 2013 at 21:30:14, Mark Jackson wrote:
> On 04/07/13 16:14, Mark Jackson wrote:
> > On 04/07/13 14:25, Mark Jackson wrote:
> >> Our custom AM335x board has been booting just fine under 3.10.0-rc4.
> >>
> >> I've just done a git pull to update to 3.10 (now that it's released)
> >> and the board now hangs.
> >>
> >> Before I start trying to bisect the issue, does anyone have an clues ?
> > 
> > Okay ... I've now bisected it to:-
> > 
> > a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
> > commit a630fbfbb1beeffc5bbe542a7986bf2068874633
> > Author: Tony Lindgren <tony at atomide.com>
> > Date:   Mon Jun 10 07:39:09 2013 -0700
> > 
> >     serial: omap: Fix device tree based PM runtime
> 
> However, reverting the commit does *not* fix the issue, weird !!
> 
> But I have now tested:-
> 
> v3.10-rc4     -> works
> v3.10-rc5     -> works
> v3.10-rc6     -> works
> v3.10-rc7     -> works
> v3.10         -> works
> origin/master -> hangs
> 
> Any ideas ?

I just checked the behavior on my AM335x-EVM. Current mainline boots fine
provided I don't use earlyprintk.  The offending patch [1] in this case is the one
that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
also results in the console UART getting reset and idled during bootup and that's where
the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
the system booting fine. 

I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
omap_serial_early_init() to get earlyprintk working again.

Regards,
Vaibhav B.

[1] http://www.spinics.net/lists/linux-omap/msg91825.html


From maxime.ripard at free-electrons.com  Fri Jul  5 04:14:05 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 5 Jul 2013 10:14:05 +0200
Subject: [PATCH 3/3] Added support for On Chip OTP in i.MX23/28
In-Reply-To: <1372855154-8422-4-git-send-email-cb@sgoc.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
 <1372855154-8422-4-git-send-email-cb@sgoc.de>
Message-ID: <20130705081405.GH2959@lukather>

Hi Christoph,

On Wed, Jul 03, 2013 at 02:39:14PM +0200, Christoph G. Baumann wrote:
> From: "Christoph G. Baumann" <cb at sgoc.de>
> 
> Signed-off-by: Christoph G. Baumann <cb at sgoc.de>
> ---
>  arch/arm/boot/dts/imx28.dtsi |    1 -
>  drivers/clk/mxs/clk-imx23.c  |    2 ++
>  drivers/clk/mxs/clk-imx28.c  |    1 +
>  drivers/misc/Kconfig         |   14 ++++++++++++++
>  drivers/misc/Makefile        |    1 +
>  5 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 600f7cb..e9de86b 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -711,7 +711,6 @@
>  			ocotp at 8002c000 {
>  				compatible = "fsl,ocotp";
>  				reg = <0x8002c000 0x2000>;
> -				status = "disabled";
>  			};

Why do you enable it only for imx28?

>  			axi-ahb at 8002e000 {
> diff --git a/drivers/clk/mxs/clk-imx23.c b/drivers/clk/mxs/clk-imx23.c
> index f6a7487..ec76d00 100644
> --- a/drivers/clk/mxs/clk-imx23.c
> +++ b/drivers/clk/mxs/clk-imx23.c
> @@ -168,6 +168,8 @@ int __init mx23_clocks_init(void)
>  	clk_data.clk_num = ARRAY_SIZE(clks);
>  	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
>  
> +	clk_register_clkdev(clks[hbus], NULL, "hbus");
> +
>  	for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
>  		clk_prepare_enable(clks[clks_init_on[i]]);
>  
> diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c
> index 4faf0af..792fcaf 100644
> --- a/drivers/clk/mxs/clk-imx28.c
> +++ b/drivers/clk/mxs/clk-imx28.c
> @@ -247,6 +247,7 @@ int __init mx28_clocks_init(void)
>  	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
>  
>  	clk_register_clkdev(clks[enet_out], NULL, "enet_out");
> +	clk_register_clkdev(clks[hbus], NULL, "hbus");
>  
>  	for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
>  		clk_prepare_enable(clks[clks_init_on[i]]);

These two should go in a separate patch (with details on why it's
needed).

> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index c002d86..b44ef48 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -527,6 +527,20 @@ config SRAM
>  	  the genalloc API. It is supposed to be used for small on-chip SRAM
>  	  areas found on many SoCs.
>  
> +config FSL_OTP
> +	tristate "Freescale On-Chip OTP Memory Support"
> +	depends on SOC_IMX23 || SOC_IMX28
> +	default n
> +	help
> +		If you say Y here, you will get support for a SysFS interface for
> +		the One Time Programmable memory pages that are stored on the
> +		iMX23/28 processor.
> +
> +	  To compile this driver as a module, choose M here: the module
> +	  will be called fsl_otp.
> +
> +	  If unsure, it is safe to say N.
> +
>  source "drivers/misc/c2port/Kconfig"
>  source "drivers/misc/eeprom/Kconfig"
>  source "drivers/misc/cb710/Kconfig"
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index c235d5b..e622e01 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -53,3 +53,4 @@ obj-$(CONFIG_INTEL_MEI)		+= mei/
>  obj-$(CONFIG_VMWARE_VMCI)	+= vmw_vmci/
>  obj-$(CONFIG_LATTICE_ECP3_CONFIG)	+= lattice-ecp3-config.o
>  obj-$(CONFIG_SRAM)		+= sram.o
> +obj-$(CONFIG_FSL_OTP)           += fsl_otp.o

And this should be merged with the first patch.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130705/b1828b3d/attachment.sig>

From b32955 at freescale.com  Fri Jul  5 03:50:55 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Fri, 5 Jul 2013 15:50:55 +0800
Subject: [PATCH] dma: imx-sdma: remove the unused completion
Message-ID: <1373010655-3800-1-git-send-email-b32955@freescale.com>

After the patch: "2ccaef0 dma: imx-sdma: make channel0 operations atomic",
the "done" completion is not used any more.

Just remove it.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 drivers/dma/imx-sdma.c |    7 -------
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 1e44b8c..2c02a9d 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -243,7 +243,6 @@ struct sdma_engine;
  * @event_id1		for channels that use 2 events
  * @word_size		peripheral access size
  * @buf_tail		ID of the buffer that was processed
- * @done		channel completion
  * @num_bd		max NUM_BD. number of descriptors currently handling
  */
 struct sdma_channel {
@@ -255,7 +254,6 @@ struct sdma_channel {
 	unsigned int			event_id1;
 	enum dma_slave_buswidth		word_size;
 	unsigned int			buf_tail;
-	struct completion		done;
 	unsigned int			num_bd;
 	struct sdma_buffer_descriptor	*bd;
 	dma_addr_t			bd_phys;
@@ -547,8 +545,6 @@ static void sdma_tasklet(unsigned long data)
 {
 	struct sdma_channel *sdmac = (struct sdma_channel *) data;
 
-	complete(&sdmac->done);
-
 	if (sdmac->flags & IMX_DMA_SG_LOOP)
 		sdma_handle_channel_loop(sdmac);
 	else
@@ -812,9 +808,6 @@ static int sdma_request_channel(struct sdma_channel *sdmac)
 	sdma->channel_control[channel].current_bd_ptr = sdmac->bd_phys;
 
 	sdma_set_channel_priority(sdmac, MXC_SDMA_DEFAULT_PRIORITY);
-
-	init_completion(&sdmac->done);
-
 	return 0;
 out:
 
-- 
1.7.1




From magnus.damm at gmail.com  Fri Jul  5 04:32:40 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Fri, 5 Jul 2013 17:32:40 +0900
Subject: Appended DTB files for multi-machine kernels
In-Reply-To: <201307042334.37161.arnd@arndb.de>
References: <51D5A938.30607@gmail.com> <20130704171148.GJ27646@sirena.org.uk>
 <201307042334.37161.arnd@arndb.de>
Message-ID: <CANqRtoT+=CJrU2AjFwN67vrypQ1WR-8JeMyn1-mzb+tXWeAp2g@mail.gmail.com>

Hi Arnd,

On Fri, Jul 5, 2013 at 6:34 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 04 July 2013, Mark Brown wrote:
>> On Thu, Jul 04, 2013 at 06:56:24PM +0200, Daniel Mack wrote:
>>
>> > Unless I missed some recent discussion, this case is not easy to handle.
>> > Yes, I know that these kind of things should be handled by a
>> > next-generation bootloader, but in our case, we want to avoid a loader
>> > update of already shipped hardware by all means.
>>
>> There was some discussion about appending multiple DTBs recently.  I
>> can't actually recall anything about it though so that's not an entirely
>> helpful thing...
>
> Yes, it keeps coming up, I think by now everybody agreed it's a good
> idea to extend the ATAGS compat mode, but so far nobody has implemented
> it. Magnus Damm was very interested in this feature last year and
> was planning to work on it, but I don't know how far he got.

Correct, I was and still am a bit interested in it. I did however
never get around to write any code. My apologies if that stalled
anyone.

With mach-shmobile we're now getting to a point where most of our
boards are using DT_MACHINE and appended DTB instead of the MACHINE
and mach-type. Because of that I feel that the moment has sort of
passed for me.

Regardless of this nearly all our boot loaders pass mach-type so it
would be nice to match on that instead of the appended DTB.

Thanks,

/ magnus


From sachin.kamat at linaro.org  Fri Jul  5 04:18:01 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Fri,  5 Jul 2013 13:48:01 +0530
Subject: [PATCH 1/1] of/documentation: Fix a typo in exynos5250-clock.txt
Message-ID: <1373012281-26433-1-git-send-email-sachin.kamat@linaro.org>

The clocks should be numbered sequentially as they are represented as
enum values in the clock driver.

Typo introduced by commit 17d4caccef ("clk: exynos5250: register
display block gate clocks to common clock framework")

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
---
 .../devicetree/bindings/clock/exynos5250-clock.txt |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 781a627..1a05761 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -154,7 +154,7 @@ clock which they consume.
   dsim0			341
   dp			342
   mixer			343
-  hdmi			345
+  hdmi			344
 
 Example 1: An example of a clock controller node is listed below.
 
-- 
1.7.9.5



From b18965 at freescale.com  Fri Jul  5 03:51:38 2013
From: b18965 at freescale.com (Alison Wang)
Date: Fri, 5 Jul 2013 15:51:38 +0800
Subject: [PATCH 0/4] ARM: vf610: Add DCU framebuffer driver for Vybrid VF610
 platform 
Message-ID: <1373010702-9244-1-git-send-email-b18965@freescale.com>

This series contain DCU framebuffer driver for Freescale Vybrid VF610 platform.

The Display Controller Unit (DCU) module is a system master that
fetches graphics stored in internal or external memory and displays
them on a TFT LCD panel. A wide range of panel sizes is supported
and the timing of the interface signals is highly configurable.
Graphics are read directly from memory and then blended in real-time,
which allows for dynamic content creation with minimal CPU intervention.

The features:

(1) Full RGB888 output to TFT LCD panel.
(2) For the current LCD panel, WQVGA "480x272" is supported.
(3) Blending of each pixel using up to 4 source layers dependent on size of panel.
(4) Each graphic layer can be placed with one pixel resolution in either axis.
(5) Each graphic layer support RGB565 and RGB888 direct colors without alpha channel
and BGRA8888 direct colors with an alpha channel.
(6) Each graphic layer support alpha blending with 8-bit resolution.

----------------------------------------------------------------
Alison Wang (4):
      ARM: dts: vf610: Add DCU and TCON nodes
      ARM: dts: vf610-twr: Enable DCU and TCON devices
      ARM: clk: vf610: Add DCU and TCON clock support
      fb: Add DCU framebuffer driver for Vybrid VF610 platform

 arch/arm/boot/dts/vf610-twr.dts         |   10 +
 arch/arm/boot/dts/vf610.dtsi            |   18 ++
 arch/arm/mach-imx/clk-vf610.c           |    5 +
 drivers/video/Kconfig                   |    9 +
 drivers/video/Makefile                  |    1 +
 drivers/video/fsl-dcu-fb.c              | 1091 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/dt-bindings/clock/vf610-clock.h |    3 +-
 7 files changed, 1136 insertions(+), 1 deletion(-)
 create mode 100644 drivers/video/fsl-dcu-fb.c




From b18965 at freescale.com  Fri Jul  5 03:51:39 2013
From: b18965 at freescale.com (Alison Wang)
Date: Fri, 5 Jul 2013 15:51:39 +0800
Subject: [PATCH 1/4] ARM: dts: vf610: Add DCU and TCON nodes
In-Reply-To: <1373010702-9244-1-git-send-email-b18965@freescale.com>
References: <1373010702-9244-1-git-send-email-b18965@freescale.com>
Message-ID: <1373010702-9244-2-git-send-email-b18965@freescale.com>

This patch adds DCU and TCON nodes in SoC level DTS for Freescale
Vybrid VF610. It also removes useless pin for DCU0 pinctrl.

Signed-off-by: Alison Wang <b18965 at freescale.com>
---
 arch/arm/boot/dts/vf610.dtsi | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index e1eb7da..037e8f1 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -140,6 +140,14 @@
 				clock-names = "pit";
 			};
 
+			tcon0: tcon at 4003d000 {
+				compatible = "fsl,vf610-tcon";
+				reg = <0x4003d000 0x1000>;
+				clocks = <&clks VF610_CLK_TCON0>;
+				clock-names = "tcon";
+				status = "disabled";
+			};
+
 			wdog at 4003e000 {
 				compatible = "fsl,vf610-wdt", "fsl,imx21-wdt";
 				reg = <0x4003e000 0x1000>;
@@ -169,7 +177,6 @@
 				dcu0 {
 					pinctrl_dcu0_1: dcu0grp_1 {
 						fsl,pins = <
-						VF610_PAD_PTB8__GPIO_30		0x42
 						VF610_PAD_PTE0__DCU0_HSYNC	0x42
 						VF610_PAD_PTE1__DCU0_VSYNC	0x42
 						VF610_PAD_PTE2__DCU0_PCLK	0x42
@@ -395,6 +402,16 @@
 				reg = <0x40050000 0x1000>;
 			};
 
+			dcu0: dcu at 40058000 {
+				compatible = "fsl,vf610-dcu";
+				reg = <0x40058000 0x1200>;
+				interrupts = <0 30 0x04>;
+				clocks = <&clks VF610_CLK_DCU0>;
+				clock-names = "dcu";
+				tcon-controller = <&tcon0>;
+				status = "disabled";
+			};
+
 			i2c0: i2c at 40066000 {
 				#address-cells = <1>;
 				#size-cells = <0>;
-- 
1.8.0




From b18965 at freescale.com  Fri Jul  5 03:51:41 2013
From: b18965 at freescale.com (Alison Wang)
Date: Fri, 5 Jul 2013 15:51:41 +0800
Subject: [PATCH 3/4] ARM: clk: vf610: Add DCU and TCON clock support
In-Reply-To: <1373010702-9244-1-git-send-email-b18965@freescale.com>
References: <1373010702-9244-1-git-send-email-b18965@freescale.com>
Message-ID: <1373010702-9244-4-git-send-email-b18965@freescale.com>

This patch adds DCU and TCON clock support for Vybrid VF610 platform.

Signed-off-by: Alison Wang <b18965 at freescale.com>
---
 arch/arm/mach-imx/clk-vf610.c           | 5 +++++
 include/dt-bindings/clock/vf610-clock.h | 3 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/clk-vf610.c b/arch/arm/mach-imx/clk-vf610.c
index d617c0b..c4dbe32 100644
--- a/arch/arm/mach-imx/clk-vf610.c
+++ b/arch/arm/mach-imx/clk-vf610.c
@@ -245,6 +245,8 @@ static void __init vf610_clocks_init(struct device_node *ccm_node)
 	clk[VF610_CLK_DCU1_DIV] = imx_clk_divider("dcu1_div", "dcu1_en", CCM_CSCDR3, 20, 3);
 	clk[VF610_CLK_DCU1] = imx_clk_gate2("dcu1", "dcu1_div", CCM_CCGR9, CCM_CCGRx_CGn(8));
 
+	clk[VF610_CLK_TCON0] = imx_clk_gate2("tcon0", "platform_bus", CCM_CCGR1, CCM_CCGRx_CGn(13));
+
 	clk[VF610_CLK_ESAI_SEL] = imx_clk_mux("esai_sel", CCM_CSCMR1, 20, 2, esai_sels, 4);
 	clk[VF610_CLK_ESAI_EN] = imx_clk_gate("esai_en", "esai_sel", CCM_CSCDR2, 30);
 	clk[VF610_CLK_ESAI_DIV] = imx_clk_divider("esai_div", "esai_en", CCM_CSCDR2, 24, 4);
@@ -311,6 +313,9 @@ static void __init vf610_clocks_init(struct device_node *ccm_node)
 	clk_set_parent(clk[VF610_CLK_SAI2_SEL], clk[VF610_CLK_AUDIO_EXT]);
 	clk_set_parent(clk[VF610_CLK_SAI3_SEL], clk[VF610_CLK_AUDIO_EXT]);
 
+	clk_set_parent(clk[VF610_CLK_DCU0_SEL], clk[VF610_CLK_PLL1_PFD2]);
+	clk_set_rate(clk[VF610_CLK_DCU0_DIV], 113200000);
+
 	/* Add the clocks to provider list */
 	clk_data.clks = clk;
 	clk_data.clk_num = ARRAY_SIZE(clk);
diff --git a/include/dt-bindings/clock/vf610-clock.h b/include/dt-bindings/clock/vf610-clock.h
index 15e997f..a2fc6d9 100644
--- a/include/dt-bindings/clock/vf610-clock.h
+++ b/include/dt-bindings/clock/vf610-clock.h
@@ -158,6 +158,7 @@
 #define VF610_CLK_GPU_SEL		145
 #define VF610_CLK_GPU_EN		146
 #define VF610_CLK_GPU2D			147
-#define VF610_CLK_END			148
+#define VF610_CLK_TCON0			148
+#define VF610_CLK_END			149
 
 #endif /* __DT_BINDINGS_CLOCK_VF610_H */
-- 
1.8.0




From b18965 at freescale.com  Fri Jul  5 03:51:42 2013
From: b18965 at freescale.com (Alison Wang)
Date: Fri, 5 Jul 2013 15:51:42 +0800
Subject: [PATCH 4/4] fb: Add DCU framebuffer driver for Vybrid VF610 platform
In-Reply-To: <1373010702-9244-1-git-send-email-b18965@freescale.com>
References: <1373010702-9244-1-git-send-email-b18965@freescale.com>
Message-ID: <1373010702-9244-5-git-send-email-b18965@freescale.com>

The Display Controller Unit (DCU) module is a system master that
fetches graphics stored in internal or external memory and displays
them on a TFT LCD panel. A wide range of panel sizes is supported
and the timing of the interface signals is highly configurable.
Graphics are read directly from memory and then blended in real-time,
which allows for dynamic content creation with minimal CPU intervention.

The features:

(1) Full RGB888 output to TFT LCD panel.
(2) For the current LCD panel, WQVGA "480x272" is supported.
(3) Blending of each pixel using up to 4 source layers dependent on size of panel.
(4) Each graphic layer can be placed with one pixel resolution in either axis.
(5) Each graphic layer support RGB565 and RGB888 direct colors without alpha channel
and BGRA8888 direct colors with an alpha channel.
(6) Each graphic layer support alpha blending with 8-bit resolution.

This driver has been tested on Vybrid VF610 TOWER board.

Signed-off-by: Alison Wang <b18965 at freescale.com>
---
 drivers/video/Kconfig      |    9 +
 drivers/video/Makefile     |    1 +
 drivers/video/fsl-dcu-fb.c | 1091 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 1101 insertions(+)
 create mode 100644 drivers/video/fsl-dcu-fb.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 2c301f8..10af3a4 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1974,6 +1974,15 @@ config FB_FSL_DIU
 	---help---
 	  Framebuffer driver for the Freescale SoC DIU
 
+config FB_FSL_DCU
+	tristate "Freescale DCU framebuffer support"
+	depends on FB
+	select FB_CFB_FILLRECT
+	select FB_CFB_COPYAREA
+	select FB_CFB_IMAGEBLIT
+	---help---
+	  Framebuffer driver for the Freescale SoC DCU
+
 config FB_W100
 	tristate "W100 frame buffer support"
 	depends on FB && ARCH_PXA
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index e8bae8d..3707a7d 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -129,6 +129,7 @@ obj-$(CONFIG_FB_IMX)              += imxfb.o
 obj-$(CONFIG_FB_S3C)		  += s3c-fb.o
 obj-$(CONFIG_FB_S3C2410)	  += s3c2410fb.o
 obj-$(CONFIG_FB_FSL_DIU)	  += fsl-diu-fb.o
+obj-$(CONFIG_FB_FSL_DCU)	  += fsl-dcu-fb.o
 obj-$(CONFIG_FB_COBALT)           += cobalt_lcdfb.o
 obj-$(CONFIG_FB_IBM_GXT4500)	  += gxt4500.o
 obj-$(CONFIG_FB_PS3)		  += ps3fb.o
diff --git a/drivers/video/fsl-dcu-fb.c b/drivers/video/fsl-dcu-fb.c
new file mode 100644
index 0000000..5571dde
--- /dev/null
+++ b/drivers/video/fsl-dcu-fb.c
@@ -0,0 +1,1091 @@
+/*
+ * Copyright 2012-2013 Freescale Semiconductor, Inc.
+ *
+ * Freescale DCU Frame Buffer device driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/dma-mapping.h>
+#include <linux/interrupt.h>
+#include <linux/fb.h>
+#include <linux/clk.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/uaccess.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+
+#define DRIVER_NAME			"fsl-dcu-fb"
+
+#define DCU_DCU_MODE			0x0010
+#define DCU_MODE_BLEND_ITER(x)		(x << 20)
+#define DCU_MODE_RASTER_EN		(1 << 14)
+#define DCU_MODE_DCU_MODE(x)		(x)
+#define DCU_MODE_DCU_MODE_MASK		0x03
+#define DCU_MODE_OFF			0
+#define DCU_MODE_NORMAL			1
+#define DCU_MODE_TEST			2
+#define DCU_MODE_COLORBAR		3
+
+#define DCU_BGND			0x0014
+#define DCU_BGND_R(x)			(x << 16)
+#define DCU_BGND_G(x)			(x << 8)
+#define DCU_BGND_B(x)			(x)
+
+#define DCU_DISP_SIZE			0x0018
+#define DCU_DISP_SIZE_DELTA_Y(x)	(x << 16)
+#define DCU_DISP_SIZE_DELTA_X(x)	(x)
+
+#define DCU_HSYN_PARA			0x001c
+#define DCU_HSYN_PARA_BP(x)		(x << 22)
+#define DCU_HSYN_PARA_PW(x)		(x << 11)
+#define DCU_HSYN_PARA_FP(x)		(x)
+
+#define DCU_VSYN_PARA			0x0020
+#define DCU_VSYN_PARA_BP(x)		(x << 22)
+#define DCU_VSYN_PARA_PW(x)		(x << 11)
+#define DCU_VSYN_PARA_FP(x)		(x)
+
+#define DCU_SYN_POL			0x0024
+#define DCU_SYN_POL_INV_PXCK_FALL	(0 << 6)
+#define DCU_SYN_POL_NEG_REMAIN		(0 << 5)
+#define DCU_SYN_POL_INV_VS_LOW		(1 << 1)
+#define DCU_SYN_POL_INV_HS_LOW		(1)
+
+#define DCU_THRESHOLD			0x0028
+#define DCU_THRESHOLD_LS_BF_VS(x)	(x << 16)
+#define DCU_THRESHOLD_OUT_BUF_HIGH(x)	(x << 8)
+#define DCU_THRESHOLD_OUT_BUF_LOW(x)	(x)
+
+#define DCU_INT_STATUS			0x002C
+#define DCU_INT_STATUS_UNDRUN		(1 << 1)
+
+#define DCU_INT_MASK			0x0030
+#define DCU_INT_MASK_UNDRUN		(1 << 1)
+
+#define DCU_DIV_RATIO			0x0054
+
+#define DCU_UPDATE_MODE			0x00cc
+#define DCU_UPDATE_MODE_MODE		(1 << 31)
+#define DCU_UPDATE_MODE_READREG		(1 << 30)
+
+#define DCU_CTRLDESCLN_1(x)		(0x200 + (x) * 0x40)
+#define DCU_CTRLDESCLN_1_HEIGHT(x)	(x << 16)
+#define DCU_CTRLDESCLN_1_WIDTH(x)	(x)
+
+#define DCU_CTRLDESCLN_2(x)		(0x204 + (x) * 0x40)
+#define DCU_CTRLDESCLN_2_POSY(x)	(x << 16)
+#define DCU_CTRLDESCLN_2_POSX(x)	(x)
+
+#define DCU_CTRLDESCLN_3(x)		(0x208 + (x) * 0x40)
+
+#define DCU_CTRLDESCLN_4(x)		(0x20c + (x) * 0x40)
+#define DCU_CTRLDESCLN_4_EN		(1 << 31)
+#define DCU_CTRLDESCLN_4_TILE_EN	(1 << 30)
+#define DCU_CTRLDESCLN_4_DATA_SEL_CLUT	(1 << 29)
+#define DCU_CTRLDESCLN_4_SAFETY_EN	(1 << 28)
+#define DCU_CTRLDESCLN_4_TRANS(x)	(x << 20)
+#define DCU_CTRLDESCLN_4_BPP(x)		(x << 16)
+#define DCU_CTRLDESCLN_4_RLE_EN		(1 << 15)
+#define DCU_CTRLDESCLN_4_LUOFFS(x)	(x << 4)
+#define DCU_CTRLDESCLN_4_BB_ON		(1 << 2)
+#define DCU_CTRLDESCLN_4_AB(x)		(x)
+
+#define DCU_CTRLDESCLN_5(x)		(0x210 + (x) * 0x40)
+#define DCU_CTRLDESCLN_5_CKMAX_R(x)	(x << 16)
+#define DCU_CTRLDESCLN_5_CKMAX_G(x)	(x << 8)
+#define DCU_CTRLDESCLN_5_CKMAX_B(x)	(x)
+
+#define DCU_CTRLDESCLN_6(x)		(0x214 + (x) * 0x40)
+#define DCU_CTRLDESCLN_6_CKMIN_R(x)	(x << 16)
+#define DCU_CTRLDESCLN_6_CKMIN_G(x)	(x << 8)
+#define DCU_CTRLDESCLN_6_CKMIN_B(x)	(x)
+
+#define DCU_CTRLDESCLN_7(x)		(0x218 + (x) * 0x40)
+#define DCU_CTRLDESCLN_7_TILE_VER(x)	(x << 16)
+#define DCU_CTRLDESCLN_7_TILE_HOR(x)	(x)
+
+#define DCU_CTRLDESCLN_8(x)		(0x21c + (x) * 0x40)
+#define DCU_CTRLDESCLN_8_FG_FCOLOR(x)	(x)
+
+#define DCU_CTRLDESCLN_9(x)		(0x220 + (x) * 0x40)
+#define DCU_CTRLDESCLN_9_BG_BCOLOR(x)	(x)
+
+#define DCU_TOTAL_LAYER_NUM		64
+#define DCU_LAYER_NUM_MAX		6
+#define DCU_LAYER_NUM			4
+
+#define BPP_16_RGB565			4
+#define BPP_24_RGB888			5
+#define BPP_32_ARGB8888			6
+
+#define TCON_CTRL1			0x0000
+#define TCON_BYPASS_ENABLE		(1 << 29)
+
+#define MFB_SET_ALPHA		_IOW('M', 0, __u8)
+#define MFB_GET_ALPHA		_IOR('M', 0, __u8)
+#define MFB_SET_LAYER		_IOW('M', 4, struct layer_display_offset)
+#define MFB_GET_LAYER		_IOR('M', 4, struct layer_display_offset)
+
+static char *fb_mode;
+static unsigned int default_bpp = 24;
+
+static struct fb_videomode dcu_mode_db[] = {
+	{
+		.name		= "480x272",
+		.refresh	= 75,
+		.xres		= 480,
+		.yres		= 272,
+		.pixclock	= 91996,
+		.left_margin	= 2,
+		.right_margin	= 2,
+		.upper_margin	= 1,
+		.lower_margin	= 1,
+		.hsync_len	= 41,
+		.vsync_len	= 2,
+		.sync		= FB_SYNC_COMP_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+		.vmode		= FB_VMODE_NONINTERLACED,
+	},
+};
+
+/* DCU framebuffer data structure */
+struct dcu_fb_data {
+	struct fb_info *fsl_dcu_info[DCU_LAYER_NUM];
+	void __iomem *reg_base;
+	unsigned int irq;
+	struct clk *clk;
+};
+
+struct layer_display_offset {
+	int x_layer_d;
+	int y_layer_d;
+};
+
+struct mfb_info {
+	int index;
+	char *id;
+	unsigned long pseudo_palette[16];
+	unsigned char alpha;
+	unsigned char blend;
+	unsigned int count;
+	int x_layer_d;	/* layer display x offset to physical screen */
+	int y_layer_d;	/* layer display y offset to physical screen */
+	struct dcu_fb_data *parent;
+};
+
+enum mfb_index {
+	LAYER0 = 0,
+	LAYER1,
+	LAYER2,
+	LAYER3,
+};
+
+static struct mfb_info mfb_template[] = {
+	{
+	.index = LAYER0,
+	.id = "Layer0",
+	.alpha = 0xff,
+	.blend = 0,
+	.count = 0,
+	.x_layer_d = 0,
+	.y_layer_d = 0,
+	},
+	{
+	.index = LAYER1,
+	.id = "Layer1",
+	.alpha = 0xff,
+	.blend = 0,
+	.count = 0,
+	.x_layer_d = 50,
+	.y_layer_d = 50,
+	},
+	{
+	.index = LAYER2,
+	.id = "Layer2",
+	.alpha = 0xff,
+	.blend = 0,
+	.count = 0,
+	.x_layer_d = 100,
+	.y_layer_d = 100,
+	},
+	{
+	.index = LAYER3,
+	.id = "Layer3",
+	.alpha = 0xff,
+	.blend = 0,
+	.count = 0,
+	.x_layer_d = 150,
+	.y_layer_d = 150,
+	},
+};
+
+static int enable_panel(struct fb_info *info)
+{
+	struct fb_var_screeninfo *var = &info->var;
+	struct mfb_info *mfbi = info->par;
+	struct dcu_fb_data *dcufb = mfbi->parent;
+	unsigned int bpp;
+
+	writel(DCU_CTRLDESCLN_1_HEIGHT(var->yres) |
+		DCU_CTRLDESCLN_1_WIDTH(var->xres),
+		dcufb->reg_base + DCU_CTRLDESCLN_1(mfbi->index));
+	writel(DCU_CTRLDESCLN_2_POSY(mfbi->y_layer_d) |
+		DCU_CTRLDESCLN_2_POSX(mfbi->x_layer_d),
+		dcufb->reg_base + DCU_CTRLDESCLN_2(mfbi->index));
+
+	writel(info->fix.smem_start,
+		dcufb->reg_base + DCU_CTRLDESCLN_3(mfbi->index));
+
+	switch (var->bits_per_pixel) {
+	case 16:
+		bpp = BPP_16_RGB565;
+		break;
+	case 24:
+		bpp = BPP_24_RGB888;
+		break;
+	case 32:
+		bpp = BPP_32_ARGB8888;
+		break;
+	default:
+		printk(KERN_ERR "unsupported color depth: %u\n",
+			var->bits_per_pixel);
+		return -EINVAL;
+	}
+
+	writel(DCU_CTRLDESCLN_4_EN |
+		DCU_CTRLDESCLN_4_TRANS(mfbi->alpha) |
+		DCU_CTRLDESCLN_4_BPP(bpp) |
+		DCU_CTRLDESCLN_4_AB(mfbi->blend),
+		dcufb->reg_base + DCU_CTRLDESCLN_4(mfbi->index));
+
+	writel(DCU_CTRLDESCLN_5_CKMAX_R(0xff) |
+		DCU_CTRLDESCLN_5_CKMAX_G(0xff) |
+		DCU_CTRLDESCLN_5_CKMAX_B(0xff),
+		dcufb->reg_base + DCU_CTRLDESCLN_5(mfbi->index));
+	writel(DCU_CTRLDESCLN_6_CKMIN_R(0) |
+		DCU_CTRLDESCLN_6_CKMIN_G(0) |
+		DCU_CTRLDESCLN_6_CKMIN_B(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_6(mfbi->index));
+
+	writel(DCU_CTRLDESCLN_7_TILE_VER(0) | DCU_CTRLDESCLN_7_TILE_HOR(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_7(mfbi->index));
+
+	writel(DCU_CTRLDESCLN_8_FG_FCOLOR(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_8(mfbi->index));
+	writel(DCU_CTRLDESCLN_9_BG_BCOLOR(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_9(mfbi->index));
+
+	writel(DCU_UPDATE_MODE_READREG, dcufb->reg_base + DCU_UPDATE_MODE);
+	return 0;
+}
+
+static int disable_panel(struct fb_info *info)
+{
+	struct mfb_info *mfbi = info->par;
+	struct dcu_fb_data *dcufb = mfbi->parent;
+
+	writel(DCU_CTRLDESCLN_1_HEIGHT(0) |
+		DCU_CTRLDESCLN_1_WIDTH(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_1(mfbi->index));
+	writel(DCU_CTRLDESCLN_2_POSY(0) | DCU_CTRLDESCLN_2_POSX(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_2(mfbi->index));
+
+	writel(0, dcufb->reg_base + DCU_CTRLDESCLN_3(mfbi->index));
+	writel(0, dcufb->reg_base + DCU_CTRLDESCLN_4(mfbi->index));
+
+	writel(DCU_CTRLDESCLN_5_CKMAX_R(0) |
+		DCU_CTRLDESCLN_5_CKMAX_G(0) |
+		DCU_CTRLDESCLN_5_CKMAX_B(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_5(mfbi->index));
+	writel(DCU_CTRLDESCLN_6_CKMIN_R(0) |
+		DCU_CTRLDESCLN_6_CKMIN_G(0) |
+		DCU_CTRLDESCLN_6_CKMIN_B(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_6(mfbi->index));
+
+	writel(DCU_CTRLDESCLN_7_TILE_VER(0) | DCU_CTRLDESCLN_7_TILE_HOR(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_7(mfbi->index));
+
+	writel(DCU_CTRLDESCLN_8_FG_FCOLOR(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_8(mfbi->index));
+	writel(DCU_CTRLDESCLN_9_BG_BCOLOR(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_9(mfbi->index));
+
+	writel(DCU_UPDATE_MODE_READREG, dcufb->reg_base + DCU_UPDATE_MODE);
+	return 0;
+}
+
+static void enable_controller(struct fb_info *info)
+{
+	struct mfb_info *mfbi = info->par;
+	struct dcu_fb_data *dcufb = mfbi->parent;
+	unsigned int dcu_mode;
+
+	dcu_mode = readl(dcufb->reg_base + DCU_DCU_MODE);
+	writel(dcu_mode | DCU_MODE_DCU_MODE(DCU_MODE_NORMAL),
+		dcufb->reg_base + DCU_DCU_MODE);
+}
+
+static void disable_controller(struct fb_info *info)
+{
+	struct mfb_info *mfbi = info->par;
+	struct dcu_fb_data *dcufb = mfbi->parent;
+
+	writel(DCU_MODE_DCU_MODE(DCU_MODE_OFF),
+		dcufb->reg_base + DCU_DCU_MODE);
+}
+
+static int fsl_dcu_check_var(struct fb_var_screeninfo *var,
+		struct fb_info *info)
+{
+	if (var->xres_virtual < var->xres)
+		var->xres_virtual = var->xres;
+	if (var->yres_virtual < var->yres)
+		var->yres_virtual = var->yres;
+
+	if (var->xoffset < 0)
+		var->xoffset = 0;
+
+	if (var->yoffset < 0)
+		var->yoffset = 0;
+
+	if (var->xoffset + info->var.xres > info->var.xres_virtual)
+		var->xoffset = info->var.xres_virtual - info->var.xres;
+
+	if (var->yoffset + info->var.yres > info->var.yres_virtual)
+		var->yoffset = info->var.yres_virtual - info->var.yres;
+
+	if ((var->bits_per_pixel != 32) && (var->bits_per_pixel != 24) &&
+	    (var->bits_per_pixel != 16))
+		var->bits_per_pixel = default_bpp;
+
+	switch (var->bits_per_pixel) {
+	case 16:
+		var->red.length = 5;
+		var->red.offset = 11;
+		var->red.msb_right = 0;
+
+		var->green.length = 6;
+		var->green.offset = 5;
+		var->green.msb_right = 0;
+
+		var->blue.length = 5;
+		var->blue.offset = 0;
+		var->blue.msb_right = 0;
+
+		var->transp.length = 0;
+		var->transp.offset = 0;
+		var->transp.msb_right = 0;
+		break;
+	case 24:
+		var->red.length = 8;
+		var->red.offset = 16;
+		var->red.msb_right = 0;
+
+		var->green.length = 8;
+		var->green.offset = 8;
+		var->green.msb_right = 0;
+
+		var->blue.length = 8;
+		var->blue.offset = 0;
+		var->blue.msb_right = 0;
+
+		var->transp.length = 0;
+		var->transp.offset = 0;
+		var->transp.msb_right = 0;
+		break;
+	case 32:
+		var->red.length = 8;
+		var->red.offset = 16;
+		var->red.msb_right = 0;
+
+		var->green.length = 8;
+		var->green.offset = 8;
+		var->green.msb_right = 0;
+
+		var->blue.length = 8;
+		var->blue.offset = 0;
+		var->blue.msb_right = 0;
+
+		var->transp.length = 8;
+		var->transp.offset = 24;
+		var->transp.msb_right = 0;
+		break;
+	default:
+		printk(KERN_ERR "unsupported color depth: %u\n",
+			var->bits_per_pixel);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int calc_div_ratio(struct fb_info *info)
+{
+	struct mfb_info *mfbi = info->par;
+	struct dcu_fb_data *dcufb = mfbi->parent;
+	unsigned long dcu_clk;
+	unsigned long long tmp;
+
+	dcu_clk = clk_get_rate(dcufb->clk);
+	tmp = info->var.pixclock * (unsigned long long)dcu_clk;
+
+	do_div(tmp, 1000000);
+
+	if (do_div(tmp, 1000000) > 500000)
+		tmp++;
+
+	tmp = tmp - 1;
+	return tmp;
+}
+
+static void update_controller(struct fb_info *info)
+{
+	struct fb_var_screeninfo *var = &info->var;
+	struct mfb_info *mfbi = info->par;
+	struct dcu_fb_data *dcufb = mfbi->parent;
+	unsigned int ratio;
+
+	ratio = calc_div_ratio(info);
+	writel(ratio, dcufb->reg_base + DCU_DIV_RATIO);
+
+	writel(DCU_DISP_SIZE_DELTA_Y(var->yres) |
+		DCU_DISP_SIZE_DELTA_X(var->xres / 16),
+		dcufb->reg_base + DCU_DISP_SIZE);
+
+	/* Horizontal and vertical sync parameter */
+	writel(DCU_HSYN_PARA_BP(var->left_margin) |
+		DCU_HSYN_PARA_PW(var->hsync_len) |
+		DCU_HSYN_PARA_FP(var->right_margin),
+		dcufb->reg_base + DCU_HSYN_PARA);
+
+	writel(DCU_VSYN_PARA_BP(var->upper_margin) |
+		DCU_VSYN_PARA_PW(var->vsync_len) |
+		DCU_VSYN_PARA_FP(var->lower_margin),
+		dcufb->reg_base + DCU_VSYN_PARA);
+
+	writel(DCU_SYN_POL_INV_PXCK_FALL | DCU_SYN_POL_NEG_REMAIN |
+		DCU_SYN_POL_INV_VS_LOW | DCU_SYN_POL_INV_HS_LOW,
+		dcufb->reg_base + DCU_SYN_POL);
+
+	writel(DCU_BGND_R(0) | DCU_BGND_G(0) | DCU_BGND_B(0),
+		dcufb->reg_base + DCU_BGND);
+
+	writel(DCU_MODE_BLEND_ITER(DCU_LAYER_NUM_MAX) | DCU_MODE_RASTER_EN,
+			dcufb->reg_base + DCU_DCU_MODE);
+
+	writel(DCU_THRESHOLD_LS_BF_VS(0x3) | DCU_THRESHOLD_OUT_BUF_HIGH(0x78) |
+		DCU_THRESHOLD_OUT_BUF_LOW(0), dcufb->reg_base + DCU_THRESHOLD);
+
+	enable_controller(info);
+}
+
+static int map_video_memory(struct fb_info *info)
+{
+	u32 smem_len = info->fix.line_length * info->var.yres_virtual;
+
+	info->fix.smem_len = smem_len;
+
+	info->screen_base = dma_alloc_coherent(info->device, info->fix.smem_len,
+		(dma_addr_t *)&info->fix.smem_start, GFP_KERNEL);
+	if (!info->screen_base) {
+		printk(KERN_ERR "unable to allocate fb memory\n");
+		return -ENOMEM;
+	}
+
+	memset(info->screen_base, 0, info->fix.smem_len);
+
+	return 0;
+}
+
+static void unmap_video_memory(struct fb_info *info)
+{
+	if (!info->screen_base)
+		return;
+
+	dma_free_coherent(info->device, info->fix.smem_len,
+		info->screen_base, info->fix.smem_start);
+
+	info->screen_base = NULL;
+	info->fix.smem_start = 0;
+	info->fix.smem_len = 0;
+}
+
+static int fsl_dcu_set_layer(struct fb_info *info)
+{
+	struct mfb_info *mfbi = info->par;
+	struct fb_var_screeninfo *var = &info->var;
+	struct dcu_fb_data *dcufb = mfbi->parent;
+	int pixel_offset;
+	unsigned long addr;
+
+	pixel_offset = (var->yoffset * var->xres_virtual) + var->xoffset;
+	addr = info->fix.smem_start +
+		(pixel_offset * (var->bits_per_pixel >> 3));
+
+	writel(addr, dcufb->reg_base + DCU_CTRLDESCLN_3(mfbi->index));
+	writel(DCU_UPDATE_MODE_READREG, dcufb->reg_base + DCU_UPDATE_MODE);
+
+	return 0;
+}
+
+static int fsl_dcu_set_par(struct fb_info *info)
+{
+	unsigned long len;
+	struct fb_var_screeninfo *var = &info->var;
+	struct fb_fix_screeninfo *fix = &info->fix;
+	struct mfb_info *mfbi = info->par;
+
+	fix->line_length = var->xres_virtual * var->bits_per_pixel / 8;
+	fix->type = FB_TYPE_PACKED_PIXELS;
+	fix->accel = FB_ACCEL_NONE;
+	fix->visual = FB_VISUAL_TRUECOLOR;
+	fix->xpanstep = 1;
+	fix->ypanstep = 1;
+
+	len = info->var.yres_virtual * info->fix.line_length;
+	if (len != info->fix.smem_len) {
+		if (info->fix.smem_start)
+			unmap_video_memory(info);
+
+		if (map_video_memory(info)) {
+			printk(KERN_ERR "unable to allocate fb memory\n");
+			return -ENOMEM;
+		}
+	}
+
+	/* Only layer 0 could update LCD controller */
+	if (mfbi->index == LAYER0)
+		update_controller(info);
+
+	enable_panel(info);
+	return 0;
+}
+
+static inline __u32 CNVT_TOHW(__u32 val, __u32 width)
+{
+	return ((val<<width) + 0x7FFF - val) >> 16;
+}
+
+static int fsl_dcu_setcolreg(unsigned regno, unsigned red, unsigned green,
+			   unsigned blue, unsigned transp, struct fb_info *info)
+{
+	unsigned int val;
+	int ret = -EINVAL;
+
+	/*
+	 * If greyscale is true, then we convert the RGB value
+	 * to greyscale no matter what visual we are using.
+	 */
+	if (info->var.grayscale)
+		red = green = blue = (19595 * red + 38470 * green +
+				      7471 * blue) >> 16;
+	switch (info->fix.visual) {
+	case FB_VISUAL_TRUECOLOR:
+		/*
+		 * 16-bit True Colour.  We encode the RGB value
+		 * according to the RGB bitfield information.
+		 */
+		if (regno < 16) {
+			u32 *pal = info->pseudo_palette;
+
+			red = CNVT_TOHW(red, info->var.red.length);
+			green = CNVT_TOHW(green, info->var.green.length);
+			blue = CNVT_TOHW(blue, info->var.blue.length);
+			transp = CNVT_TOHW(transp, info->var.transp.length);
+
+			val = (red << info->var.red.offset) |
+			    (green << info->var.green.offset) |
+			    (blue << info->var.blue.offset) |
+			    (transp << info->var.transp.offset);
+
+			pal[regno] = val;
+			ret = 0;
+		}
+		break;
+	case FB_VISUAL_STATIC_PSEUDOCOLOR:
+	case FB_VISUAL_PSEUDOCOLOR:
+		break;
+	}
+
+	return ret;
+}
+
+static int fsl_dcu_pan_display(struct fb_var_screeninfo *var,
+			     struct fb_info *info)
+{
+	if ((info->var.xoffset == var->xoffset) &&
+	    (info->var.yoffset == var->yoffset))
+		return 0;
+
+	if (var->xoffset < 0 || var->yoffset < 0
+	    || var->xoffset + info->var.xres > info->var.xres_virtual
+	    || var->yoffset + info->var.yres > info->var.yres_virtual)
+		return -EINVAL;
+
+	info->var.xoffset = var->xoffset;
+	info->var.yoffset = var->yoffset;
+
+	if (var->vmode & FB_VMODE_YWRAP)
+		info->var.vmode |= FB_VMODE_YWRAP;
+	else
+		info->var.vmode &= ~FB_VMODE_YWRAP;
+
+	fsl_dcu_set_layer(info);
+
+	return 0;
+}
+
+static int fsl_dcu_blank(int blank_mode, struct fb_info *info)
+{
+	switch (blank_mode) {
+	case FB_BLANK_VSYNC_SUSPEND:
+	case FB_BLANK_HSYNC_SUSPEND:
+	case FB_BLANK_NORMAL:
+		disable_panel(info);
+		break;
+	case FB_BLANK_POWERDOWN:
+		disable_controller(info);
+		break;
+	case FB_BLANK_UNBLANK:
+		enable_panel(info);
+		break;
+	}
+
+	return 0;
+}
+
+static int fsl_dcu_ioctl(struct fb_info *info, unsigned int cmd,
+		unsigned long arg)
+{
+	struct mfb_info *mfbi = info->par;
+	struct layer_display_offset layer_d;
+	void __user *buf = (void __user *)arg;
+	unsigned char alpha;
+
+	switch (cmd) {
+	case MFB_SET_LAYER:
+		if (copy_from_user(&layer_d, buf, sizeof(layer_d)))
+			return -EFAULT;
+		mfbi->x_layer_d = layer_d.x_layer_d;
+		mfbi->y_layer_d = layer_d.y_layer_d;
+		fsl_dcu_set_par(info);
+		break;
+	case MFB_GET_LAYER:
+		layer_d.x_layer_d = mfbi->x_layer_d;
+		layer_d.y_layer_d = mfbi->y_layer_d;
+		if (copy_to_user(buf, &layer_d, sizeof(layer_d)))
+			return -EFAULT;
+		break;
+	case MFB_GET_ALPHA:
+		alpha = mfbi->alpha;
+		if (copy_to_user(buf, &alpha, sizeof(alpha)))
+			return -EFAULT;
+		break;
+	case MFB_SET_ALPHA:
+		if (copy_from_user(&alpha, buf, sizeof(alpha)))
+			return -EFAULT;
+		mfbi->blend = 1;
+		mfbi->alpha = alpha;
+		fsl_dcu_set_par(info);
+		break;
+	default:
+		printk(KERN_ERR "unknown ioctl command (0x%08X)\n", cmd);
+		return -ENOIOCTLCMD;
+	}
+
+	return 0;
+}
+
+static void enable_interrupts(struct dcu_fb_data *dcufb)
+{
+	u32 int_mask = readl(dcufb->reg_base + DCU_INT_MASK);
+
+	writel(int_mask & ~DCU_INT_MASK_UNDRUN, dcufb->reg_base + DCU_INT_MASK);
+}
+
+static void reset_layers(struct dcu_fb_data *dcufb)
+{
+	int i;
+
+	for (i = 1; i < DCU_TOTAL_LAYER_NUM; i++) {
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_1(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_2(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_3(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_4(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_5(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_6(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_7(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_8(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_9(i));
+	}
+	writel(DCU_UPDATE_MODE_READREG, dcufb->reg_base + DCU_UPDATE_MODE);
+}
+
+static int fsl_dcu_open(struct fb_info *info, int user)
+{
+	struct mfb_info *mfbi = info->par;
+	int ret = 0;
+
+	mfbi->index = info->node;
+
+	mfbi->count++;
+	if (mfbi->count == 1) {
+		fsl_dcu_check_var(&info->var, info);
+		ret = fsl_dcu_set_par(info);
+		if (ret < 0)
+			mfbi->count--;
+		else
+			enable_interrupts(mfbi->parent);
+	}
+
+	return ret;
+}
+
+static int fsl_dcu_release(struct fb_info *info, int user)
+{
+	struct mfb_info *mfbi = info->par;
+	int ret = 0;
+
+	mfbi->count--;
+	if (mfbi->count == 0) {
+		ret = disable_panel(info);
+		if (ret < 0)
+			mfbi->count++;
+	}
+
+	return ret;
+}
+
+static struct fb_ops fsl_dcu_ops = {
+	.owner = THIS_MODULE,
+	.fb_check_var = fsl_dcu_check_var,
+	.fb_set_par = fsl_dcu_set_par,
+	.fb_setcolreg = fsl_dcu_setcolreg,
+	.fb_blank = fsl_dcu_blank,
+	.fb_pan_display = fsl_dcu_pan_display,
+	.fb_fillrect = cfb_fillrect,
+	.fb_copyarea = cfb_copyarea,
+	.fb_imageblit = cfb_imageblit,
+	.fb_ioctl = fsl_dcu_ioctl,
+	.fb_open = fsl_dcu_open,
+	.fb_release = fsl_dcu_release,
+};
+
+static int install_framebuffer(struct fb_info *info)
+{
+	struct mfb_info *mfbi = info->par;
+	struct fb_videomode *db = dcu_mode_db;
+	unsigned int dbsize = ARRAY_SIZE(dcu_mode_db);
+	int ret;
+
+	info->var.activate = FB_ACTIVATE_NOW;
+	info->fbops = &fsl_dcu_ops;
+	info->flags = FBINFO_FLAG_DEFAULT;
+	info->pseudo_palette = &mfbi->pseudo_palette;
+
+	fb_alloc_cmap(&info->cmap, 16, 0);
+
+	ret = fb_find_mode(&info->var, info, fb_mode, db, dbsize,
+			NULL, default_bpp);
+
+	if (fsl_dcu_check_var(&info->var, info)) {
+		ret = -EINVAL;
+		goto failed_checkvar;
+	}
+
+	if (register_framebuffer(info) < 0) {
+		ret = -EINVAL;
+		goto failed_register_framebuffer;
+	}
+
+	printk(KERN_INFO "fb%d: %s fb device registered successfully.\n",
+		info->node, info->fix.id);
+	return 0;
+
+failed_checkvar:
+	fb_dealloc_cmap(&info->cmap);
+failed_register_framebuffer:
+	unmap_video_memory(info);
+	fb_dealloc_cmap(&info->cmap);
+	return ret;
+}
+
+static void uninstall_framebuffer(struct fb_info *info)
+{
+	unregister_framebuffer(info);
+	unmap_video_memory(info);
+
+	if (&info->cmap)
+		fb_dealloc_cmap(&info->cmap);
+}
+
+static irqreturn_t fsl_dcu_irq(int irq, void *dev_id)
+{
+	struct dcu_fb_data *dcufb = dev_id;
+	unsigned int status = readl(dcufb->reg_base + DCU_INT_STATUS);
+	u32 dcu_mode;
+
+	if (status) {
+		if (status & DCU_INT_STATUS_UNDRUN) {
+			dcu_mode = readl(dcufb->reg_base + DCU_DCU_MODE);
+			dcu_mode &= ~DCU_MODE_DCU_MODE_MASK;
+			writel(dcu_mode | DCU_MODE_DCU_MODE(DCU_MODE_OFF),
+				dcufb->reg_base + DCU_DCU_MODE);
+			udelay(1);
+			writel(dcu_mode | DCU_MODE_DCU_MODE(DCU_MODE_NORMAL),
+				dcufb->reg_base + DCU_DCU_MODE);
+		}
+		writel(status, dcufb->reg_base + DCU_INT_STATUS);
+		return IRQ_HANDLED;
+	}
+	return IRQ_NONE;
+}
+
+#ifdef CONFIG_PM
+static int fsl_dcu_suspend(struct platform_device *pdev,
+		pm_message_t state)
+{
+	struct dcu_fb_data *dcufb = dev_get_drvdata(&pdev->dev);
+
+	clk_disable_unprepare(dcufb->clk);
+	return 0;
+}
+
+static int fsl_dcu_resume(struct platform_device *pdev)
+{
+	struct dcu_fb_data *dcufb = dev_get_drvdata(&pdev->dev);
+
+	clk_prepare_enable(dcufb->clk);
+	return 0;
+}
+#else
+#define fsl_dcu_suspend	NULL
+#define fsl_dcu_resume	NULL
+#endif
+
+static int bypass_tcon(struct device_node *np)
+{
+	struct device_node *tcon_np;
+	struct platform_device *tcon_pdev;
+	struct clk *tcon_clk;
+	void __iomem *tcon_reg;
+	int ret = 0;
+
+	tcon_np = of_parse_phandle(np, "tcon-controller", 0);
+	if (!tcon_np)
+		return -EINVAL;
+
+	tcon_pdev = of_find_device_by_node(tcon_np);
+	if (!tcon_pdev)
+		return -EINVAL;
+
+	tcon_clk = devm_clk_get(&tcon_pdev->dev, "tcon");
+	if (IS_ERR(tcon_clk)) {
+		ret = PTR_ERR(tcon_clk);
+		goto failed_getclock;
+	}
+	clk_prepare_enable(tcon_clk);
+
+	tcon_reg = of_iomap(tcon_np, 0);
+	if (!tcon_reg) {
+		ret = -ENOMEM;
+		goto failed_ioremap;
+	}
+	writel(TCON_BYPASS_ENABLE, tcon_reg + TCON_CTRL1);
+
+	return 0;
+
+failed_ioremap:
+	clk_disable_unprepare(tcon_clk);
+failed_getclock:
+	of_node_put(tcon_np);
+	return ret;
+}
+
+static int fsl_dcu_probe(struct platform_device *pdev)
+{
+	struct dcu_fb_data *dcufb;
+	struct mfb_info *mfbi;
+	struct resource *res;
+	int ret = 0;
+	int i;
+
+	dcufb = devm_kzalloc(&pdev->dev,
+		sizeof(struct dcu_fb_data), GFP_KERNEL);
+	if (!dcufb)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(&pdev->dev, "could not get memory IO resource\n");
+		return -ENODEV;
+	}
+
+	dcufb->reg_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(dcufb->reg_base)) {
+		ret = PTR_ERR(dcufb->reg_base);
+		goto failed_ioremap;
+	}
+
+	dcufb->irq = platform_get_irq(pdev, 0);
+	if (!dcufb->irq) {
+		ret = -EINVAL;
+		goto failed_getirq;
+	}
+
+	ret = request_irq(dcufb->irq, fsl_dcu_irq, 0, DRIVER_NAME, dcufb);
+	if (ret) {
+		dev_err(&pdev->dev, "could not request irq\n");
+		goto failed_requestirq;
+	}
+
+	/* Put TCON in bypass mode, so the input signals from DCU are passed
+	 * through TCON unchanged */
+	ret = bypass_tcon(pdev->dev.of_node);
+	if (ret) {
+		dev_err(&pdev->dev, "could not bypass TCON\n");
+		goto failed_bypasstcon;
+	}
+
+	dcufb->clk = devm_clk_get(&pdev->dev, "dcu");
+	if (IS_ERR(dcufb->clk)) {
+		dev_err(&pdev->dev, "could not get clock\n");
+		goto failed_getclock;
+	}
+	clk_prepare_enable(dcufb->clk);
+
+	for (i = 0; i < ARRAY_SIZE(dcufb->fsl_dcu_info); i++) {
+		dcufb->fsl_dcu_info[i] =
+			framebuffer_alloc(sizeof(struct mfb_info), &pdev->dev);
+		if (!dcufb->fsl_dcu_info[i]) {
+			ret = ENOMEM;
+			goto failed_alloc_framebuffer;
+		}
+
+		dcufb->fsl_dcu_info[i]->fix.smem_start = 0;
+
+		mfbi = dcufb->fsl_dcu_info[i]->par;
+		memcpy(mfbi, &mfb_template[i], sizeof(struct mfb_info));
+		mfbi->parent = dcufb;
+
+		ret = install_framebuffer(dcufb->fsl_dcu_info[i]);
+		if (ret) {
+			dev_err(&pdev->dev,
+				"could not register framebuffer %d\n", i);
+			goto failed_register_framebuffer;
+		}
+	}
+
+	reset_layers(mfbi->parent);
+
+	dev_set_drvdata(&pdev->dev, dcufb);
+	return 0;
+
+failed_register_framebuffer:
+	for (i = 0; i < ARRAY_SIZE(dcufb->fsl_dcu_info); i++) {
+		if (dcufb->fsl_dcu_info[i])
+			framebuffer_release(dcufb->fsl_dcu_info[i]);
+	}
+failed_alloc_framebuffer:
+failed_getclock:
+failed_bypasstcon:
+	free_irq(dcufb->irq, dcufb);
+failed_requestirq:
+failed_getirq:
+	iounmap(dcufb->reg_base);
+failed_ioremap:
+	kfree(dcufb);
+	return ret;
+}
+
+static int fsl_dcu_remove(struct platform_device *pdev)
+{
+	struct dcu_fb_data *dcufb = dev_get_drvdata(&pdev->dev);
+	int i;
+
+	disable_controller(dcufb->fsl_dcu_info[0]);
+
+	clk_disable_unprepare(dcufb->clk);
+	free_irq(dcufb->irq, dcufb);
+
+	for (i = 0; i < ARRAY_SIZE(dcufb->fsl_dcu_info); i++) {
+		uninstall_framebuffer(dcufb->fsl_dcu_info[i]);
+		framebuffer_release(dcufb->fsl_dcu_info[i]);
+	}
+
+	return 0;
+}
+
+static int fsl_dcu_setup(void)
+{
+#ifndef MODULE
+	char *opt, *options = NULL;
+	unsigned long val;
+
+	if (fb_get_options("fslfb", &options))
+		return -ENODEV;
+
+	if (!options || !*options)
+		return 0;
+
+	while ((opt = strsep(&options, ",")) != NULL) {
+		if (!*opt)
+			continue;
+		if (!strncmp(opt, "bpp=", 4)) {
+			if (!strict_strtoul(opt + 4, 10, &val))
+				default_bpp = val;
+		} else {
+			fb_mode = opt;
+		}
+	}
+#endif
+	return 0;
+}
+
+static struct of_device_id fsl_dcu_dt_ids[] = {
+	{
+		.compatible = "fsl,vf610-dcu",
+	},
+	{}
+};
+
+static struct platform_driver fsl_dcu_driver = {
+	.driver = {
+		.name = DRIVER_NAME,
+		.owner = THIS_MODULE,
+		.of_match_table = fsl_dcu_dt_ids,
+	},
+	.probe = fsl_dcu_probe,
+	.remove = fsl_dcu_remove,
+	.suspend = fsl_dcu_suspend,
+	.resume = fsl_dcu_resume,
+};
+
+static int __init fsl_dcu_init(void)
+{
+	int ret = fsl_dcu_setup();
+
+	if (ret < 0)
+		return ret;
+
+	return platform_driver_register(&fsl_dcu_driver);
+}
+
+static void __exit fsl_dcu_exit(void)
+{
+	platform_driver_unregister(&fsl_dcu_driver);
+}
+
+module_init(fsl_dcu_init);
+module_exit(fsl_dcu_exit);
+
+MODULE_AUTHOR("Alison Wang");
+MODULE_DESCRIPTION("Freescale DCU framebuffer driver");
+MODULE_LICENSE("GPL v2");
-- 
1.8.0




From b18965 at freescale.com  Fri Jul  5 03:51:40 2013
From: b18965 at freescale.com (Alison Wang)
Date: Fri, 5 Jul 2013 15:51:40 +0800
Subject: [PATCH 2/4] ARM: dts: vf610-twr: Enable DCU and TCON devices
In-Reply-To: <1373010702-9244-1-git-send-email-b18965@freescale.com>
References: <1373010702-9244-1-git-send-email-b18965@freescale.com>
Message-ID: <1373010702-9244-3-git-send-email-b18965@freescale.com>

This patch enables DCU and TCON devices for Vybrid VF610 TOWER board.

Signed-off-by: Alison Wang <b18965 at freescale.com>
---
 arch/arm/boot/dts/vf610-twr.dts | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index b3905f5..605fb04 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -36,6 +36,12 @@
 
 };
 
+&dcu0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_dcu0_1>;
+	status = "okay";
+};
+
 &fec0 {
 	phy-mode = "rmii";
 	pinctrl-names = "default";
@@ -50,6 +56,10 @@
 	status = "okay";
 };
 
+&tcon0 {
+	status = "okay";
+};
+
 &uart1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart1_1>;
-- 
1.8.0




From minggr at gmail.com  Fri Jul  5 04:44:12 2013
From: minggr at gmail.com (Lin Ming)
Date: Fri, 5 Jul 2013 16:44:12 +0800
Subject: kernel decompressor problem for ARMv7
Message-ID: <CAF1ivSakn8-HiAf+4_cLRWUUTDP9QBKpAt+hVQoMyAmKZ2-dJA@mail.gmail.com>

Hi all,

I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.

But decompressor doesn't work. With a lot of debug, I finally find
below 2 commits related.
Kernel uncompress OK with these commits reverted.

dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
(Introduced in v3.6-rc6)

5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
v6 and above
(Introduced in v3.7-rc8)

Any hint to fix it?

Thanks,
Lin Ming


From wangyuhang2014 at gmail.com  Fri Jul  5 04:48:22 2013
From: wangyuhang2014 at gmail.com (yuhang wang)
Date: Fri, 5 Jul 2013 16:48:22 +0800
Subject: SPI: DUAL/QUAD support
In-Reply-To: <51D67851.8020402@ti.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704130017.GA25997@sig21.net>
 <OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>
 <20130704154927.GE27646@sirena.org.uk>
 <OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>
 <CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>
 <51D67851.8020402@ti.com>
Message-ID: <CAHSAbzNvMo_oeaqtzO8-xDm-L-f8wVccVqfuVqbR=OwqWJhVwg@mail.gmail.com>

> To add to all the discussion going on,
> I am using a qspi controller with a spansion flash device.
> I tried using quad read mode bit, and what is required to change in
> my case is the following:
>
> 1. enable quad mode in flash configuration register.
> 2. change my read opcode to QUAD READ opcode according to flash datasheet.
> 3. Configure my qspi controller cmd reg to use 6 PIN whenever quad mode is
> used.
>

Sorry, to the third point I am still not very clear. The first time,
spi controller should send
QUAD READ opcode to your spansion flash with 1 line, then receive datas from
flash with 4 lines. So how does your controller master this process
automatically.

Please give me some details.

Thanks


From sourav.poddar at ti.com  Fri Jul  5 04:55:15 2013
From: sourav.poddar at ti.com (Sourav Poddar)
Date: Fri, 5 Jul 2013 14:25:15 +0530
Subject: SPI: DUAL/QUAD support
In-Reply-To: <CAHSAbzNvMo_oeaqtzO8-xDm-L-f8wVccVqfuVqbR=OwqWJhVwg@mail.gmail.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>	<20130704130017.GA25997@sig21.net>	<OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>	<20130704154927.GE27646@sirena.org.uk>	<OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>	<CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>	<51D67851.8020402@ti.com>
 <CAHSAbzNvMo_oeaqtzO8-xDm-L-f8wVccVqfuVqbR=OwqWJhVwg@mail.gmail.com>
Message-ID: <51D689F3.3070605@ti.com>

On Friday 05 July 2013 02:18 PM, yuhang wang wrote:
>> To add to all the discussion going on,
>> I am using a qspi controller with a spansion flash device.
>> I tried using quad read mode bit, and what is required to change in
>> my case is the following:
>>
>> 1. enable quad mode in flash configuration register.
>> 2. change my read opcode to QUAD READ opcode according to flash datasheet.
>> 3. Configure my qspi controller cmd reg to use 6 PIN whenever quad mode is
>> used.
>>
> Sorry, to the third point I am still not very clear. The first time,
> spi controller should send
> QUAD READ opcode to your spansion flash with 1 line, then receive datas from
> flash with 4 lines. So how does your controller master this process
> automatically.
>
> Please give me some details.
>
Its like, you pass txbuf and rxbuf from the spi core to your controller
driver. So, if your txbuf is not null then configure the controller
cmd register with WRITE_SINGLE and if rxbuf is not null then
configure the controller cmd register with READ_QUAD.

Something like this,
                 if (txbuf) {
                         dra7xxx_writel_data(qspi, *txbuf++,
                                 QSPI_SPI_DATA_REG, wlen);
                         dra7xxx_writel(qspi, qspi->dc, QSPI_SPI_DC_REG);
                         dra7xxx_writel(qspi, qspi->cmd | QSPI_WR_SNGL,
                                         QSPI_SPI_CMD_REG);
                         wait_for_completion(&qspi->word_complete);
                 }
                 if (rxbuf) {
                         printk("rx cmd %08x dc %08x\n",
                                 qspi->cmd | QSPI_RD_QUAD, qspi->dc);
                         dra7xxx_writel(qspi, INT_EN, 
QSPI_INTR_ENABLE_SET_REG);
                         dra7xxx_writel(qspi, qspi->dc, QSPI_SPI_DC_REG);
                     if (!quad_mode)
                             dra7xxx_writel(qspi, qspi->cmd | QSPI_RD_SNGL,
                                             QSPI_SPI_CMD_REG);
                     else
                             dra7xxx_writel(qspi, qspi->cmd | QSPI_RD_QUAD,
                                             QSPI_SPI_CMD_REG);
                  .......
                 }
> Thanks



From sachin.kamat at linaro.org  Fri Jul  5 04:42:27 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Fri,  5 Jul 2013 14:12:27 +0530
Subject: [PATCH 1/3] clk: exynos5250: Add G2D gate clock
Message-ID: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>

Adds gate clock for G2D IP for Exynos5250 SoC.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
Cc: Mike Turquette <mturquette at linaro.org>
---
This patch depends on the following patch:
http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20581
---
 .../devicetree/bindings/clock/exynos5250-clock.txt |    1 +
 drivers/clk/samsung/clk-exynos5250.c               |    5 ++++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 1a05761..7e88242 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -155,6 +155,7 @@ clock which they consume.
   dp			342
   mixer			343
   hdmi			344
+  g2d			345
 
 Example 1: An example of a clock controller node is listed below.
 
diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index 6f767c5..3da0bdf 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -62,6 +62,7 @@
 #define SRC_CDREX		0x20200
 #define PLL_DIV2_SEL		0x20a24
 #define GATE_IP_DISP1		0x10928
+#define GATE_IP_ACP		0x10000
 
 /*
  * Let each supported clock get a unique id. This id is used to lookup the clock
@@ -99,7 +100,7 @@ enum exynos5250_clks {
 	spi2, i2s1, i2s2, pcm1, pcm2, pwm, spdif, ac97, hsi2c0, hsi2c1, hsi2c2,
 	hsi2c3, chipid, sysreg, pmu, cmu_top, cmu_core, cmu_mem, tzpc0, tzpc1,
 	tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
-	wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
+	wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, g2d,
 
 	nr_clks,
 };
@@ -152,6 +153,7 @@ static __initdata unsigned long exynos5250_clk_regs[] = {
 	SRC_CDREX,
 	PLL_DIV2_SEL,
 	GATE_IP_DISP1,
+	GATE_IP_ACP,
 };
 
 /* list of all parent clock list */
@@ -463,6 +465,7 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
 	GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
 	GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
 	GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
+	GATE(g2d, "g2d", "aclk200", GATE_IP_ACP, 3, 0, 0),
 };
 
 static __initdata struct of_device_id ext_clk_match[] = {
-- 
1.7.9.5



From sachin.kamat at linaro.org  Fri Jul  5 04:42:28 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Fri,  5 Jul 2013 14:12:28 +0530
Subject: [PATCH 2/3] of/documentation: Update G2D documentation
In-Reply-To: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
References: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1373013749-14530-2-git-send-email-sachin.kamat@linaro.org>

Exynos5250 G2D IP requires only the gate clock. Update the
binding documentation accordingly.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
Cc: Inki Dae <inki.dae at samsung.com>
---
 .../devicetree/bindings/gpu/samsung-g2d.txt        |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
index 3f454ff..60ca631 100644
--- a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
+++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
@@ -12,7 +12,9 @@ Required properties:
   - interrupts : G2D interrupt number to the CPU.
   - clocks : from common clock binding: handle to G2D clocks.
   - clock-names : from common clock binding: must contain "sclk_fimg2d" and
-		  "fimg2d", corresponding to entries in the clocks property.
+		  "fimg2d" for S5PV210 & Exynos4 based SoCs and "fimg2d" for
+		  Exynos5250 SoC, corresponding to entries in the clocks
+		  property.
 
 Example:
 	g2d at 12800000 {
-- 
1.7.9.5



From sachin.kamat at linaro.org  Fri Jul  5 04:42:29 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Fri,  5 Jul 2013 14:12:29 +0530
Subject: [PATCH 3/3] ARM: EXYNOS: Add G2D support to exynos5250
In-Reply-To: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
References: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1373013749-14530-3-git-send-email-sachin.kamat@linaro.org>

Adds G2D node to exynos5250 DT file.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
---
 arch/arm/boot/dts/exynos5250.dtsi |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index ef57277..6f356ce 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -163,6 +163,14 @@
 		clock-names = "watchdog";
 	};
 
+	g2d at 10850000 {
+		compatible = "samsung,exynos5250-g2d";
+		reg = <0x10850000 0x1000>;
+		interrupts = <0 91 0>;
+		clocks = <&clock 345>;
+		clock-names = "fimg2d";
+	};
+
 	codec at 11000000 {
 		compatible = "samsung,mfc-v6";
 		reg = <0x11000000 0x10000>;
-- 
1.7.9.5



From wangyuhang2014 at gmail.com  Fri Jul  5 05:07:06 2013
From: wangyuhang2014 at gmail.com (yuhang wang)
Date: Fri, 5 Jul 2013 17:07:06 +0800
Subject: SPI: DUAL/QUAD support
In-Reply-To: <51D689F3.3070605@ti.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704130017.GA25997@sig21.net>
 <OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>
 <20130704154927.GE27646@sirena.org.uk>
 <OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>
 <CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>
 <51D67851.8020402@ti.com>
 <CAHSAbzNvMo_oeaqtzO8-xDm-L-f8wVccVqfuVqbR=OwqWJhVwg@mail.gmail.com>
 <51D689F3.3070605@ti.com>
Message-ID: <CAHSAbzM1PGoMXFNOmB7guDsVWYnRoRy89-bufHYpPz5+odnd8w@mail.gmail.com>

>                     if (!quad_mode)
>                             dra7xxx_writel(qspi, qspi->cmd | QSPI_RD_SNGL,
>                                             QSPI_SPI_CMD_REG);
>                     else
>                             dra7xxx_writel(qspi, qspi->cmd | QSPI_RD_QUAD,
>                                             QSPI_SPI_CMD_REG);
>                  .......
>                 }

So what do you based on to set variable quad_mode.


From sourav.poddar at ti.com  Fri Jul  5 05:08:36 2013
From: sourav.poddar at ti.com (Sourav Poddar)
Date: Fri, 5 Jul 2013 14:38:36 +0530
Subject: SPI: DUAL/QUAD support
In-Reply-To: <CAHSAbzM1PGoMXFNOmB7guDsVWYnRoRy89-bufHYpPz5+odnd8w@mail.gmail.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>	<20130704130017.GA25997@sig21.net>	<OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>	<20130704154927.GE27646@sirena.org.uk>	<OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>	<CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>	<51D67851.8020402@ti.com>	<CAHSAbzNvMo_oeaqtzO8-xDm-L-f8wVccVqfuVqbR=OwqWJhVwg@mail.gmail.com>	<51D689F3.3070605@ti.com>
 <CAHSAbzM1PGoMXFNOmB7guDsVWYnRoRy89-bufHYpPz5+odnd8w@mail.gmail.com>
Message-ID: <51D68D14.7090606@ti.com>

On Friday 05 July 2013 02:37 PM, yuhang wang wrote:
>>                      if (!quad_mode)
>>                              dra7xxx_writel(qspi, qspi->cmd | QSPI_RD_SNGL,
>>                                              QSPI_SPI_CMD_REG);
>>                      else
>>                              dra7xxx_writel(qspi, qspi->cmd | QSPI_RD_QUAD,
>>                                              QSPI_SPI_CMD_REG);
>>                   .......
>>                  }
> So what do you based on to set variable quad_mode.
Best way should be to check for flash device id and manufacture data. 
Based on which you
can decide whether your flash supports quad bits or not.


From b32955 at freescale.com  Fri Jul  5 04:43:38 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Fri, 5 Jul 2013 16:43:38 +0800
Subject: [PATCH] of: match the compatible in the order set by the dts file
Message-ID: <1373013818-11365-1-git-send-email-b32955@freescale.com>

If we set the uart compatible in the dts file like this:
   ------------------------------------------------------
    compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
   ------------------------------------------------------

and we set the uart compatible in the uart driver like this:
   ------------------------------------------------------
	{ .compatible = "fsl,imx1-uart", ... },
	{ .compatible = "fsl,imx21-uart", ... },
	{ .compatible = "fsl,imx6q-uart", ... },
	{ /* sentinel */ }
   ------------------------------------------------------

the current code will match the "fsl,imx21-uart" in the end.

Of course, this is not what we want. We want it to match the "fsl,imx6q-uart".

This patch rewrites the match code, and make it to check the compatible
in the order set by the DTS file.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 drivers/of/base.c |   29 +++++++++++++++++++++++++----
 1 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 0d61fc5..b13846b 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -622,10 +622,14 @@ static
 const struct of_device_id *__of_match_node(const struct of_device_id *matches,
 					   const struct device_node *node)
 {
+	struct of_device_id *old = (struct of_device_id *)matches;
+	const char *cp;
+	int cplen, l;
+
 	if (!matches)
 		return NULL;
 
-	while (matches->name[0] || matches->type[0] || matches->compatible[0]) {
+	while (matches->name[0] || matches->type[0]) {
 		int match = 1;
 		if (matches->name[0])
 			match &= node->name
@@ -633,13 +637,30 @@ const struct of_device_id *__of_match_node(const struct of_device_id *matches,
 		if (matches->type[0])
 			match &= node->type
 				&& !strcmp(matches->type, node->type);
-		if (matches->compatible[0])
-			match &= __of_device_is_compatible(node,
-							   matches->compatible);
 		if (match)
 			return matches;
 		matches++;
 	}
+
+	/* Check the compatible in the order set by the DTS file. */
+	cp = __of_get_property(node, "compatible", &cplen);
+	if (!cp)
+		return NULL;
+
+	while (cplen > 0) {
+		matches = old;
+
+		while (matches->compatible[0]) {
+			if (!of_compat_cmp(cp, matches->compatible,
+						strlen(matches->compatible)))
+				return matches;
+			matches++;
+		}
+
+		l = strlen(cp) + 1;
+		cp += l;
+		cplen -= l;
+	}
 	return NULL;
 }
 
-- 
1.7.1




From shawn.guo at linaro.org  Fri Jul  5 05:14:51 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 5 Jul 2013 17:14:51 +0800
Subject: [PATCH v4] tty: serial: add Freescale lpuart driver support
In-Reply-To: <1369733161-19168-1-git-send-email-b35083@freescale.com>
References: <1369733161-19168-1-git-send-email-b35083@freescale.com>
Message-ID: <20130705091449.GA20040@S2101-09.ap.freescale.net>

Jingchang,

On Tue, May 28, 2013 at 05:26:01PM +0800, Jingchang Lu wrote:
> +static void lpuart_setup_watermark(struct lpuart_port *sport)
> +{
> +	unsigned char val, old_cr2, cr2;
> +
> +	/* set receiver/transmitter trigger level. */
> +	old_cr2 = cr2 = readb(sport->port.membase + UARTCR2);
> +	cr2 &= ~(UARTCR2_TIE | UARTCR2_TCIE | UARTCR2_TE |
> +			UARTCR2_RIE | UARTCR2_RE);
> +	writeb(cr2, sport->port.membase + UARTCR2);
> +
> +	writeb(2, sport->port.membase + UARTTWFIFO);
> +	writeb(1, sport->port.membase + UARTRWFIFO);
> +
> +	/* determine FIFO size and enable */
> +	val = readb(sport->port.membase + UARTPFIFO);
> +
> +	sport->tx_fifo_size = 0x1 << (((val >> UARTPFIFO_TXSIZE_OFF) &
> +		UARTPFIFO_FIFOSIZE_MASK) + 1);
> +
> +	sport->rx_fifo_size = 0x1 << (((val >> UARTPFIFO_RXSIZE_OFF) &
> +		UARTPFIFO_FIFOSIZE_MASK) + 1);
> +
> +	writeb(val | UARTPFIFO_TXFE | UARTPFIFO_RXFE,
> +			sport->port.membase + UARTPFIFO);
> +
> +	/* Flush the Tx and Rx FIFO to a known state */
> +	writeb(UARTCFIFO_TXFLUSH | UARTCFIFO_RXFLUSH,
> +			sport->port.membase + UARTCFIFO);
> +
> +	/* restore CR2 */
> +	writeb(old_cr2, sport->port.membase + UARTCR2);

I just noticed that you dropped this CR2 restore since v5 of the patch.
I have a patch enabling low-level debug support for Vybrid.  It works
with v4 of your patch but has problem with the v5.  The console stops
working as below.

Serial: IMX driver
serial: Freescale lpuart driver
40028000.serial: ttyLP1 at MMIO 0x40028000 (irq = 94) is a FSL_LPUART
console [ttyLP1] enabled, bootconsole disabled

If I have above CR2 restore code added back.  The low-level debug
support will just work fine with console.

Is it an accident you removed the code?

Shawn

> +
> +}



From wangyuhang2014 at gmail.com  Fri Jul  5 05:17:41 2013
From: wangyuhang2014 at gmail.com (yuhang wang)
Date: Fri, 5 Jul 2013 17:17:41 +0800
Subject: SPI: DUAL/QUAD support
In-Reply-To: <51D68D14.7090606@ti.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704130017.GA25997@sig21.net>
 <OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>
 <20130704154927.GE27646@sirena.org.uk>
 <OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>
 <CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>
 <51D67851.8020402@ti.com>
 <CAHSAbzNvMo_oeaqtzO8-xDm-L-f8wVccVqfuVqbR=OwqWJhVwg@mail.gmail.com>
 <51D689F3.3070605@ti.com>
 <CAHSAbzM1PGoMXFNOmB7guDsVWYnRoRy89-bufHYpPz5+odnd8w@mail.gmail.com>
 <51D68D14.7090606@ti.com>
Message-ID: <CAHSAbzMfvfdDtTh=3zeBni4fNMAHEMdTJLJU-Oc13HJUqCUj0A@mail.gmail.com>

2013/7/5 Sourav Poddar <sourav.poddar at ti.com>:
> On Friday 05 July 2013 02:37 PM, yuhang wang wrote:
>>>
>>>                      if (!quad_mode)
>>>                              dra7xxx_writel(qspi, qspi->cmd |
>>> QSPI_RD_SNGL,
>>>                                              QSPI_SPI_CMD_REG);
>>>                      else
>>>                              dra7xxx_writel(qspi, qspi->cmd |
>>> QSPI_RD_QUAD,
>>>                                              QSPI_SPI_CMD_REG);
>>>                   .......
>>>                  }
>>
>> So what do you based on to set variable quad_mode.
>
> Best way should be to check for flash device id and manufacture data. Based
> on which you
> can decide whether your flash supports quad bits or not.

Perhaps I did not said it clearly. Your flash supports quad and you
set it into quad
mode. But how can your controller driver notice that. In other word,
In which way
provide this information from flash to spi controller.


From sourav.poddar at ti.com  Fri Jul  5 05:27:51 2013
From: sourav.poddar at ti.com (Sourav Poddar)
Date: Fri, 5 Jul 2013 14:57:51 +0530
Subject: SPI: DUAL/QUAD support
In-Reply-To: <CAHSAbzMfvfdDtTh=3zeBni4fNMAHEMdTJLJU-Oc13HJUqCUj0A@mail.gmail.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>	<20130704130017.GA25997@sig21.net>	<OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>	<20130704154927.GE27646@sirena.org.uk>	<OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>	<CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>	<51D67851.8020402@ti.com>	<CAHSAbzNvMo_oeaqtzO8-xDm-L-f8wVccVqfuVqbR=OwqWJhVwg@mail.gmail.com>	<51D689F3.3070605@ti.com>	<CAHSAbzM1PGoMXFNOmB7guDsVWYnRoRy89-bufHYpPz5+odnd8w@mail.gmail.com>	<51D68D14.7090606@ti.com>
 <CAHSAbzMfvfdDtTh=3zeBni4fNMAHEMdTJLJU-Oc13HJUqCUj0A@mail.gmail.com>
Message-ID: <51D69197.7060802@ti.com>

On Friday 05 July 2013 02:47 PM, yuhang wang wrote:
> 2013/7/5 Sourav Poddar<sourav.poddar at ti.com>:
>> On Friday 05 July 2013 02:37 PM, yuhang wang wrote:
>>>>                       if (!quad_mode)
>>>>                               dra7xxx_writel(qspi, qspi->cmd |
>>>> QSPI_RD_SNGL,
>>>>                                               QSPI_SPI_CMD_REG);
>>>>                       else
>>>>                               dra7xxx_writel(qspi, qspi->cmd |
>>>> QSPI_RD_QUAD,
>>>>                                               QSPI_SPI_CMD_REG);
>>>>                    .......
>>>>                   }
>>> So what do you based on to set variable quad_mode.
>> Best way should be to check for flash device id and manufacture data. Based
>> on which you
>> can decide whether your flash supports quad bits or not.
> Perhaps I did not said it clearly. Your flash supports quad and you
> set it into quad
> mode. But how can your controller driver notice that. In other word,
> In which way
> provide this information from flash to spi controller.
Perhaps, I understood you initial patch wrong. :(
Yes, this is little confusing, and I am trying to figure out that.
As of now, I have tested it with some extern variable, though
we need to see how it can be done cleanly.
I am trying to see if your patch can be used in some way now.



From B35083 at freescale.com  Fri Jul  5 05:39:03 2013
From: B35083 at freescale.com (Lu Jingchang-B35083)
Date: Fri, 5 Jul 2013 09:39:03 +0000
Subject: [PATCH v4] tty: serial: add Freescale lpuart driver support
In-Reply-To: <20130705091449.GA20040@S2101-09.ap.freescale.net>
References: <1369733161-19168-1-git-send-email-b35083@freescale.com>
 <20130705091449.GA20040@S2101-09.ap.freescale.net>
Message-ID: <B56CDBE15CE27145A4B77D2D24263E851E5AFC@039-SN1MPN1-005.039d.mgd.msft.net>



>-----Original Message-----
>From: Shawn Guo [mailto:shawn.guo at linaro.org]
>Sent: Friday, July 05, 2013 5:15 PM
>To: Lu Jingchang-B35083
>Cc: linux-serial at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>gregkh at linuxfoundation.org; s.hauer at pengutronix.de
>Subject: Re: [PATCH v4] tty: serial: add Freescale lpuart driver support

>> +	/* restore CR2 */
>> +	writeb(old_cr2, sport->port.membase + UARTCR2);
>
>I just noticed that you dropped this CR2 restore since v5 of the patch.
>I have a patch enabling low-level debug support for Vybrid.  It works with
>v4 of your patch but has problem with the v5.  The console stops working
>as below.
>
>Serial: IMX driver
>serial: Freescale lpuart driver
>40028000.serial: ttyLP1 at MMIO 0x40028000 (irq = 94) is a FSL_LPUART
>console [ttyLP1] enabled, bootconsole disabled
>
>If I have above CR2 restore code added back.  The low-level debug support
>will just work fine with console.
>
>Is it an accident you removed the code?
[Lu Jingchang-B35083] 
I explicitly removed the cr2 restore code on cleaning up the redundant code, and find it work well on normal operation.
Low level debug is not supported on Vybrid so I didn't notice that problem.
Will you fixing it? Or I submit a fix on it?
Thanks.



Best Regards,
Jingchang 




From wangyuhang2014 at gmail.com  Fri Jul  5 05:41:57 2013
From: wangyuhang2014 at gmail.com (yuhang wang)
Date: Fri, 5 Jul 2013 17:41:57 +0800
Subject: SPI: DUAL/QUAD support
In-Reply-To: <20130704191216.GK27646@sirena.org.uk>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704143645.GA27646@sirena.org.uk>
 <20130704180656.GA1974@sig21.net>
 <20130704191216.GK27646@sirena.org.uk>
Message-ID: <CAHSAbzNBkZPFOfGHqFxZH_id=PFj=BmZ4Q302zGKeM-0yJBtHg@mail.gmail.com>

>> Flash data sheets use the terms Dual and Quad I/O Mode,
>> e.g. for MX25L25635E
>> http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/6F878CF760C559BD482576E00022E6CC/?OpenDocument&EPN=MX25L25635E
>
> OK, but this is not a flash specific feature but rather something at the
> SPI level and even with flash are they typically written in all caps?
> This really needs to be described at the SPI level for the SPI subsystem,
> not in terms of the specific application.
>

Yes. I agree with you. This should be described in SPI level.
So to SPI controller, if it has the ability to transfer in 2x or 4x, but
what a pity no device can tell this info to it. No matter what the slave
is and no matter whether they will use the spi transfer width member,
firstly SPI controller should provide these members. If the slave do
not set the member, that means the slave wants to communicate
in 1 line traditionally.


From richard.zhuhongxing at gmail.com  Fri Jul  5 05:52:19 2013
From: richard.zhuhongxing at gmail.com (Richard Zhu)
Date: Fri,  5 Jul 2013 17:52:19 +0800
Subject: [PATCH v3 0/3] ahci: enable ahci sata support on imx6q
Message-ID: <1373017942-12583-1-git-send-email-Hong-Xing.Zhu@freescale.com>

v3: add imx6q specific ahci sata support
  - Keep arch/arm and ahci_platform driver clean.
  - Add the sata_imx standalone driver contained all the
  specific setup
  - Add the release function, support the loadable module
  driver.
  - Tested on imx6q sd board.

v2: http://www.spinics.net/lists/linux-ide/msg45666.html 
 - Setup standalone imx ahci sata driver, because of
 the misalignments of the bits definition of the HBA register.
 - Replace the node by the label in the board dts.
 - 

v1: http://www.spinics.net/lists/linux-ide/msg45581.html
 - add imx6q specific ahci sata support to arch/arm/mach-imx/mach-imx6q.c

These patches is based on imx/dt branch of
"http://git.linaro.org/git-ro/people/shawnguo/linux-2.6.git"

[v3 1/3] ARM: dtsi: enable ahci sata on imx6q platforms
[v3 2/3] ARM: imx6q: update the sata bits definitions of gpr13
[v3 3/3] sata: imx: add ahci sata support on imx platforms

arch/arm/boot/dts/imx6q-sabreauto.dts       |    4 +
arch/arm/boot/dts/imx6q-sabrelite.dts       |    4 +
arch/arm/boot/dts/imx6q-sabresd.dts         |    4 +
arch/arm/boot/dts/imx6q.dtsi                |    9 +
drivers/ata/Kconfig                         |    9 +
drivers/ata/Makefile                        |    1 +
drivers/ata/sata_imx.c                      |  221 +++++++++++++++++++++++++++
include/linux/mfd/syscon/imx6q-iomuxc-gpr.h |  121 ++++++++++-----
8 files changed, 336 insertions(+), 37 deletions(-)


From will.deacon at arm.com  Fri Jul  5 05:57:57 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 5 Jul 2013 10:57:57 +0100
Subject: kernel decompressor problem for ARMv7
In-Reply-To: <CAF1ivSakn8-HiAf+4_cLRWUUTDP9QBKpAt+hVQoMyAmKZ2-dJA@mail.gmail.com>
References: <CAF1ivSakn8-HiAf+4_cLRWUUTDP9QBKpAt+hVQoMyAmKZ2-dJA@mail.gmail.com>
Message-ID: <20130705095757.GA13063@mudshark.cambridge.arm.com>

On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
> Hi all,

Hello,

> I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.

Which specific processor/SoC?

> But decompressor doesn't work. With a lot of debug, I finally find
> below 2 commits related.
> Kernel uncompress OK with these commits reverted.
> 
> dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
> (Introduced in v3.6-rc6)
> 
> 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
> v6 and above
> (Introduced in v3.7-rc8)
> 
> Any hint to fix it?

There's not really enough information to go on here. What specifically
fails? Also, do you have to revert *both* of the above changes to get things
working again?

Cheers,

Will


From jonas.jensen at gmail.com  Fri Jul  5 06:04:13 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Fri,  5 Jul 2013 12:04:13 +0200
Subject: [PATCH v6] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <1372940383-5957-1-git-send-email-jonas.jensen@gmail.com>
References: <1372940383-5957-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1373018653-18421-1-git-send-email-jonas.jensen@gmail.com>

This patch adds an clocksource driver for the main timer(s)
found on MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130703
    
    Changes since v5:
    
    1. remove global timereg_cache variable
    2. use local cache for TIMER_CR register

 drivers/clocksource/Makefile       |   1 +
 drivers/clocksource/moxart_timer.c | 165 +++++++++++++++++++++++++++++++++++++
 2 files changed, 166 insertions(+)
 create mode 100644 drivers/clocksource/moxart_timer.c

diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 9ba8b4d..56257f6 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_CLKSRC_DBX500_PRCMU)	+= clksrc-dbx500-prcmu.o
 obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
 obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
 obj-$(CONFIG_ARCH_MARCO)	+= timer-marco.o
+obj-$(CONFIG_ARCH_MOXART)	+= moxart_timer.o
 obj-$(CONFIG_ARCH_MXS)		+= mxs_timer.o
 obj-$(CONFIG_ARCH_PRIMA2)	+= timer-prima2.o
 obj-$(CONFIG_SUN4I_TIMER)	+= sun4i_timer.o
diff --git a/drivers/clocksource/moxart_timer.c b/drivers/clocksource/moxart_timer.c
new file mode 100644
index 0000000..2adecdc
--- /dev/null
+++ b/drivers/clocksource/moxart_timer.c
@@ -0,0 +1,165 @@
+/*
+ * MOXA ART SoCs timer handling.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqreturn.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/io.h>
+#include <linux/clocksource.h>
+
+#define TIMER1_BASE		0x00
+#define TIMER2_BASE		0x10
+#define TIMER3_BASE		0x20
+
+#define REG_COUNT		0x0 /* writable */
+#define REG_LOAD		0x4
+#define REG_MATCH1		0x8
+#define REG_MATCH2		0xC
+
+#define TIMER_CR		0x30
+#define TIMER_INTR_STATE	0x34
+#define TIMER_INTR_MASK		0x38
+
+/*
+ * TIMER_CR flags:
+ *
+ * TIMEREG_CR_*_CLOCK	0: PCLK, 1: EXT1CLK
+ * TIMEREG_CR_*_INT	overflow interrupt enable bit
+ */
+#define TIMEREG_CR_1_ENABLE	(1 << 0)
+#define TIMEREG_CR_1_CLOCK	(1 << 1)
+#define TIMEREG_CR_1_INT	(1 << 2)
+#define TIMEREG_CR_2_ENABLE	(1 << 3)
+#define TIMEREG_CR_2_CLOCK	(1 << 4)
+#define TIMEREG_CR_2_INT	(1 << 5)
+#define TIMEREG_CR_3_ENABLE	(1 << 6)
+#define TIMEREG_CR_3_CLOCK	(1 << 7)
+#define TIMEREG_CR_3_INT	(1 << 8)
+#define TIMEREG_CR_COUNT_UP	(1 << 9)
+#define TIMEREG_CR_COUNT_DOWN	(0 << 9)
+
+static void __iomem *base;
+static unsigned int clock_count_per_tick;
+
+static void moxart_clkevt_mode(enum clock_event_mode mode,
+			       struct clock_event_device *clk)
+{
+	u32 u = readl(base + TIMER_CR);
+
+	switch (mode) {
+	case CLOCK_EVT_MODE_RESUME:
+	case CLOCK_EVT_MODE_ONESHOT:
+		writel(u & ~TIMEREG_CR_1_ENABLE, base + TIMER_CR);
+		writel(~0, base + TIMER1_BASE + REG_LOAD);
+		break;
+	case CLOCK_EVT_MODE_PERIODIC:
+		writel(clock_count_per_tick, base + TIMER1_BASE + REG_LOAD);
+		writel(u | TIMEREG_CR_1_ENABLE, base + TIMER_CR);
+		break;
+	case CLOCK_EVT_MODE_UNUSED:
+	case CLOCK_EVT_MODE_SHUTDOWN:
+	default:
+		writel(u & ~TIMEREG_CR_1_ENABLE, base + TIMER_CR);
+		break;
+	}
+}
+
+static int moxart_clkevt_next_event(unsigned long cycles,
+				    struct clock_event_device *unused)
+{
+	u32 u1, u2;
+
+	u1 = readl(base + TIMER_CR);
+
+	writel(u1 & ~TIMEREG_CR_1_ENABLE, base + TIMER_CR);
+
+	u2 = readl(base + TIMER1_BASE + REG_COUNT) - cycles;
+	writel(u2, base + TIMER1_BASE + REG_MATCH1);
+
+	writel(u1 | TIMEREG_CR_1_ENABLE, base + TIMER_CR);
+
+	return 0;
+}
+
+static struct clock_event_device moxart_clockevent = {
+	.name		= "moxart_timer",
+	.rating		= 200,
+	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
+	.set_mode	= moxart_clkevt_mode,
+	.set_next_event	= moxart_clkevt_next_event,
+};
+
+static irqreturn_t moxart_timer_interrupt(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+	evt->event_handler(evt);
+	return IRQ_HANDLED;
+}
+
+static struct irqaction moxart_timer_irq = {
+	.name		= "moxart-timer",
+	.flags		= IRQF_TIMER,
+	.handler	= moxart_timer_interrupt,
+	.dev_id		= &moxart_clockevent,
+};
+
+static void __init moxart_timer_init(struct device_node *node)
+{
+	int ret, irq;
+	unsigned long pclk;
+	struct clk *clk;
+
+	base = of_iomap(node, 0);
+	if (!base)
+		panic("%s: of_iomap failed\n", node->full_name);
+
+	irq = irq_of_parse_and_map(node, 0);
+	if (irq <= 0)
+		panic("%s: irq_of_parse_and_map failed\n", node->full_name);
+
+	ret = setup_irq(irq, &moxart_timer_irq);
+	if (ret)
+		panic("%s: setup_irq failed\n", node->full_name);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk))
+		panic("%s: of_clk_get failed\n", node->full_name);
+
+	pclk = clk_get_rate(clk);
+
+	if (clocksource_mmio_init(base + TIMER2_BASE + REG_COUNT,
+				  "moxart_timer", pclk, 200, 32,
+				  clocksource_mmio_readl_down))
+		panic("%s: clocksource_mmio_init failed\n", node->full_name);
+
+	clock_count_per_tick = DIV_ROUND_CLOSEST(pclk, HZ);
+
+	writel(~0, base + TIMER2_BASE + REG_LOAD);
+	writel(TIMEREG_CR_2_ENABLE, base + TIMER_CR);
+
+	moxart_clockevent.cpumask = cpumask_of(0);
+
+	/*
+	 * documentation is not publicly available:
+	 * min_delta / max_delta obtained by trial-and-error,
+	 * max_delta 0xfffffffe should be ok because count
+	 * register size is u32
+	 */
+	clockevents_config_and_register(&moxart_clockevent, pclk,
+					0x4, 0xfffffffe);
+}
+CLOCKSOURCE_OF_DECLARE(moxart, "moxa,moxart-timer", moxart_timer_init);
-- 
1.8.2.1



From jonas.jensen at gmail.com  Fri Jul  5 06:05:59 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Fri, 5 Jul 2013 12:05:59 +0200
Subject: [PATCH v5] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <alpine.DEB.2.02.1307042211420.11637@ionos.tec.linutronix.de>
References: <1372687359-18235-1-git-send-email-jonas.jensen@gmail.com>
 <1372940383-5957-1-git-send-email-jonas.jensen@gmail.com>
 <alpine.DEB.2.02.1307042211420.11637@ionos.tec.linutronix.de>
Message-ID: <CACmBeS03Xfo7DyyYUbpBaO8TeR3g8BTPzcoOzQayk40k1soFzA@mail.gmail.com>

On 4 July 2013 23:42, Thomas Gleixner <tglx at linutronix.de> wrote:
> You just modify bits on the "cache" variable. though you are not
> caching it. As it seems to work it looks like this register simply can
> be written with constants.

I agree, the global "cache" variable wasn't very good. The only good thing, that
it eliminated all TIMER_CR reads in moxart_clkevt_next_event.

Yes it could be written with constants, and it wouldn't be so bad, because in
this case so few need to be set. If more constants were set from init
the benefit
would be more clear.

>> +     timereg_cache = readl(base + TIMER_CR) | TIMEREG_CR_2_ENABLE;
>
> Why are you reading that back? You know excactly which of the timers
> you are using and none of those should be enabled before you reach
> that code. If it one of them is enabled by the boot loader you better
> disable it in this init function.

Removed. All timers except TIMER2 should be disabled in init.

> Now if you disable all of those timers and just use a known set, then
> you can do without a pseudo cache variable and just write constants
> into the control register, right ?

Yes, please take a look at v6.


Best regards,
Jonas


From will.deacon at arm.com  Fri Jul  5 06:12:09 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 5 Jul 2013 11:12:09 +0100
Subject: ARM Cortex A9: LL counters
In-Reply-To: <BFCB49997E59134AAAF17FFE77F8FF06673759E9@REXMD.intranet.epfl.ch>
References: <BFCB49997E59134AAAF17FFE77F8FF06673738BC@REXMD.intranet.epfl.ch>
 <20130704094516.GC8782@mudshark.cambridge.arm.com>
 <BFCB49997E59134AAAF17FFE77F8FF06673759E9@REXMD.intranet.epfl.ch>
Message-ID: <20130705101208.GC13063@mudshark.cambridge.arm.com>

On Fri, Jul 05, 2013 at 12:44:58AM +0100, Javier Picorel wrote:
> Thanks for the clarification! However, correct me if I'm wrong but, doesn't this mean that the "CO_LF_MISS" counter refers to L2 accesses? Thanks!

It will certainly account for some of them, but I wouldn't be surprised if
you can generate L2 accesses in ways other than missing at coherent L1.

You could look at the L2 counters and compare.

Will


From broonie at kernel.org  Fri Jul  5 06:12:04 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 5 Jul 2013 11:12:04 +0100
Subject: SPI: DUAL/QUAD support
In-Reply-To: <CAHSAbzNBkZPFOfGHqFxZH_id=PFj=BmZ4Q302zGKeM-0yJBtHg@mail.gmail.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704143645.GA27646@sirena.org.uk>
 <20130704180656.GA1974@sig21.net>
 <20130704191216.GK27646@sirena.org.uk>
 <CAHSAbzNBkZPFOfGHqFxZH_id=PFj=BmZ4Q302zGKeM-0yJBtHg@mail.gmail.com>
Message-ID: <20130705101204.GT27646@sirena.org.uk>

On Fri, Jul 05, 2013 at 05:41:57PM +0800, yuhang wang wrote:

> Yes. I agree with you. This should be described in SPI level.
> So to SPI controller, if it has the ability to transfer in 2x or 4x, but
> what a pity no device can tell this info to it. No matter what the slave
> is and no matter whether they will use the spi transfer width member,
> firstly SPI controller should provide these members. If the slave do
> not set the member, that means the slave wants to communicate
> in 1 line traditionally.

Yes, it definitely makes sense to have this as a feature in the SPI
core.  We just need a good API for it, which I think is mostly just
about working out what to call things.
-------------- 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/20130705/71080f89/attachment.sig>

From lorenzo.pieralisi at arm.com  Fri Jul  5 06:19:46 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 5 Jul 2013 11:19:46 +0100
Subject: [PATCH 0/2] ARM: sunxi: Convert DTSI to new CPU bindings
In-Reply-To: <20130630094846.GA27559@e102568-lin.cambridge.arm.com>
References: <1372437844-16325-1-git-send-email-maxime.ripard@free-electrons.com>
 <20130628171532.GD30603@e102568-lin.cambridge.arm.com>
 <20130628200333.GA2756@lukather>
 <CAOesGMgsD+tK4+ywvLzsWd+mngrP7zGgSFn0naWjSsQLGaUn2Q@mail.gmail.com>
 <20130629193819.GD3353@n2100.arm.linux.org.uk>
 <20130630094846.GA27559@e102568-lin.cambridge.arm.com>
Message-ID: <20130705101946.GA5584@e102568-lin.cambridge.arm.com>

On Sun, Jun 30, 2013 at 10:48:46AM +0100, Lorenzo Pieralisi wrote:
> On Sat, Jun 29, 2013 at 08:38:19PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Jun 28, 2013 at 01:05:42PM -0700, Olof Johansson wrote:
> > > On Fri, Jun 28, 2013 at 1:03 PM, Maxime Ripard
> > > <maxime.ripard at free-electrons.com> wrote:
> > > > On Fri, Jun 28, 2013 at 06:15:32PM +0100, Lorenzo Pieralisi wrote:
> > > >> The patch above should already be queued in next/dt right ?
> > > >
> > > > Indeed.
> > > >
> > > > Then why the latest patch of your patchset got in 3.10, while the
> > > > patches actually fixing the DT it would have impacted were delayed to
> > > > 3.11?
> > > >
> > > > (And why was it merged so late in the development cycle?)
> > > 
> > > This. So now we have to scramble because some device trees will
> > > produce warnings at boot.
> > > 
> > > Russell, the alternative is to revert Lorenzo's patch for 3.10 (and
> > > re-introduce it for 3.11). Do you have a preference?
> > 
> > Sorry but I really don't understand what all the fuss in this thread
> > is about.
> > 
> > This thread seems to be saying that two development patches were
> > merged, which were 7762/1 and 7763/1, and that 7764/1 is a fix?
> > Are you sure about that, because that's not how they're described,
> > and not how they look either.
> 
> As Olof's warning downgrade is being merged (thanks for that and apologies for
> failing to explain patches dependencies properly and stable related issues),
> 7764/1 won't apply cleanly anymore. Can you please drop it from the patch
> system, I will update it and test it first thing tomorrow and send a
> final version to the patch system.

Patch 7779/1, replacing 7764/1 is in the patch system now, and is ready
to get merged.

Unfortunately cpu/cpus bindings documentation updates, following:

https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036735.html
https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-May/033779.html

were not pulled in the kernel. This is an issue since this means that
we still have no reference in the kernel or wherever it has to be, to
the final cpus/cpu bindings for ARM and ARM64 provided in the pull
request link above (that has been reviewed to death and acknowledged).

It is a significant overhaul of cpu/cpus bindings standard for ARM/ARM64,
covering all CPUs harking back to arm926 and beyond, and should be final.

dts updates following that standard have already been pulled into 3.11
through arm-soc.

IMHO the bindings contained in pull request above must be merged in the
kernel asap, I would like to ask you please what should I do to get them in
please. If we want to move bindings documentation elsewhere let's do it,
as long as there is a published standard I am happy and will stop annoying
you with this stuff.

Thank you very much,
Lorenzo



From tglx at linutronix.de  Fri Jul  5 06:21:07 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 5 Jul 2013 12:21:07 +0200 (CEST)
Subject: [PATCH v5] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <CACmBeS03Xfo7DyyYUbpBaO8TeR3g8BTPzcoOzQayk40k1soFzA@mail.gmail.com>
References: <1372687359-18235-1-git-send-email-jonas.jensen@gmail.com>
 <1372940383-5957-1-git-send-email-jonas.jensen@gmail.com>
 <alpine.DEB.2.02.1307042211420.11637@ionos.tec.linutronix.de>
 <CACmBeS03Xfo7DyyYUbpBaO8TeR3g8BTPzcoOzQayk40k1soFzA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1307051213080.11637@ionos.tec.linutronix.de>

On Fri, 5 Jul 2013, Jonas Jensen wrote:

> On 4 July 2013 23:42, Thomas Gleixner <tglx at linutronix.de> wrote:
> > You just modify bits on the "cache" variable. though you are not
> > caching it. As it seems to work it looks like this register simply can
> > be written with constants.
> 
> I agree, the global "cache" variable wasn't very good. The only good thing, that
> it eliminated all TIMER_CR reads in moxart_clkevt_next_event.

Well, you can use a global cache variable. But that wants to be
implemented as a real cache, i.e. it always contains the current state
of the register.

   cache = 0;

   cache |= T2_ENABLE;
   write(cache, CR);
   ....
 
> Yes it could be written with constants, and it wouldn't be so bad, because in
> this case so few need to be set. If more constants were set from init
> the benefit
> would be more clear.
>
> >> +     timereg_cache = readl(base + TIMER_CR) | TIMEREG_CR_2_ENABLE;
> >
> > Why are you reading that back? You know excactly which of the timers
> > you are using and none of those should be enabled before you reach
> > that code. If it one of them is enabled by the boot loader you better
> > disable it in this init function.
> 
> Removed. All timers except TIMER2 should be disabled in init.
> 
> > Now if you disable all of those timers and just use a known set, then
> > you can do without a pseudo cache variable and just write constants
> > into the control register, right ?
> 
> Yes, please take a look at v6.

You are still reading from the control register.

What's wrong with:

#define T1_ENABLE	(TIMEREG_CR_2_ENABLE | TIMEREG_CR_1_ENABLE)
#define T1_DISABLE	(TIMEREG_CR_2_ENABLE)

Because you need to preserve the CR2 enable bit so your clocksource
does not get switched off.

Then the set_mode/next_event functions simply do:

     write(T1_DISABLE)
     write(data)
     write(T1_ENABLE)

Hmm?

Thanks,

	tglx


From wangyuhang2014 at gmail.com  Fri Jul  5 06:24:40 2013
From: wangyuhang2014 at gmail.com (yuhang wang)
Date: Fri, 5 Jul 2013 18:24:40 +0800
Subject: SPI: DUAL/QUAD support
In-Reply-To: <51D69197.7060802@ti.com>
References: <CAHSAbzPNDSr_6N79fh0DTWSEg8buRRPyiw8SPodtKLPjzWXJsg@mail.gmail.com>
 <20130704130017.GA25997@sig21.net>
 <OFA0D5839D.0594EA10-ONC1257B9E.004A7347-C1257B9E.00524BA5@rohde-schwarz.com>
 <20130704154927.GE27646@sirena.org.uk>
 <OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>
 <CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>
 <51D67851.8020402@ti.com>
 <CAHSAbzNvMo_oeaqtzO8-xDm-L-f8wVccVqfuVqbR=OwqWJhVwg@mail.gmail.com>
 <51D689F3.3070605@ti.com>
 <CAHSAbzM1PGoMXFNOmB7guDsVWYnRoRy89-bufHYpPz5+odnd8w@mail.gmail.com>
 <51D68D14.7090606@ti.com>
 <CAHSAbzMfvfdDtTh=3zeBni4fNMAHEMdTJLJU-Oc13HJUqCUj0A@mail.gmail.com>
 <51D69197.7060802@ti.com>
Message-ID: <CAHSAbzP1-RVot+hhtY_DcBK=u5n2234eb9WOKLESwvUNax7+pA@mail.gmail.com>

2013/7/5 Sourav Poddar <sourav.poddar at ti.com>:
> On Friday 05 July 2013 02:47 PM, yuhang wang wrote:
>>
>> 2013/7/5 Sourav Poddar<sourav.poddar at ti.com>:
>>>
>>> On Friday 05 July 2013 02:37 PM, yuhang wang wrote:
>>>>>
>>>>>                       if (!quad_mode)
>>>>>                               dra7xxx_writel(qspi, qspi->cmd |
>>>>> QSPI_RD_SNGL,
>>>>>                                               QSPI_SPI_CMD_REG);
>>>>>                       else
>>>>>                               dra7xxx_writel(qspi, qspi->cmd |
>>>>> QSPI_RD_QUAD,
>>>>>                                               QSPI_SPI_CMD_REG);
>>>>>                    .......
>>>>>                   }
>>>>
>>>> So what do you based on to set variable quad_mode.
>>>
>>> Best way should be to check for flash device id and manufacture data.
>>> Based
>>> on which you
>>> can decide whether your flash supports quad bits or not.
>>
>> Perhaps I did not said it clearly. Your flash supports quad and you
>> set it into quad
>> mode. But how can your controller driver notice that. In other word,
>> In which way
>> provide this information from flash to spi controller.
>
> Perhaps, I understood you initial patch wrong. :(
> Yes, this is little confusing, and I am trying to figure out that.
> As of now, I have tested it with some extern variable, though
> we need to see how it can be done cleanly.
> I am trying to see if your patch can be used in some way now.
>

Got it. In fact the kernel version I am working in is 3.0.77.
And I modified m25p80.c in Ver 3.0.90 to fit to the dual and quad.
But the driver is not general because I don't find any standard for
serial-flash. Also to the member name, just as Mark said, the
meaning is not suitable enough. Finally, do not support device tree.

2 Questions here:
1.In m25p80.c probe, the kmalloc below I feel very strange.
      flash->command = kmalloc(MAX_CMD_SIZE + (flash->fast_read ? 1 : 0),
                                      GFP_KERNEL);

 (flash->fast_read ? 1 : 0) must be 0! So why do it like that.

2.Is that any need to add wait_till_ready in the erase function to wait for the
  end of erase. But it will really take a long time.

Signed-off-by: wangyuhang <wangyuhang2014 at gmail.com>
---
 drivers/mtd/devices/m25p80.c |   93 ++++++++++++++++++++++++++++++++----------
 drivers/spi/spi.c            |    2 +
 include/linux/spi/spi.h      |    8 ++++
 3 files changed, 82 insertions(+), 21 deletions(-)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 5b6b072..267c8af 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -47,6 +47,10 @@
 #define        OPCODE_CHIP_ERASE       0xc7    /* Erase whole flash chip */
 #define        OPCODE_SE               0xd8    /* Sector erase
(usually 64KiB) */
 #define        OPCODE_RDID             0x9f    /* Read JEDEC ID */
+#define        OPCODE_DOR              0x3B    /* Dual Output Read */
+#define        OPCODE_QOR              0x6B    /* Quad Output Read */
+#define        OPCODE_QPP              0x32    /* Quad Page Programming */
+#define        OPCODE_QEN              0x02 /* Quad Mode Enable Flag */

 /* Used for SST flashes only. */
 #define        OPCODE_BP               0x02    /* Byte program */
@@ -73,6 +77,14 @@
 #define        MAX_READY_WAIT_JIFFIES  (40 * HZ)       /* M25P16
specs 40s max chip erase */
 #define        MAX_CMD_SIZE            5

+#ifdef CONFIG_M25PXX_USE_FAST_READ
+#define OPCODE_READ    OPCODE_FAST_READ
+#define FAST_READ_DUMMY_BYTE 1
+#else
+#define OPCODE_READ    OPCODE_NORM_READ
+#define FAST_READ_DUMMY_BYTE 0
+#endif
+
 #define JEDEC_MFR(_jedec_id)   ((_jedec_id) >> 16)

 /****************************************************************************/
@@ -85,7 +97,9 @@ struct m25p {
        u16                     addr_width;
        u8                      erase_opcode;
        u8                      *command;
-       bool                    fast_read;
+       u8                      read_opcode;
+       u8                      read_dummy;
+       u8                      write_opcode;
 };

 static inline struct m25p *mtd_to_m25p(struct mtd_info *mtd)
@@ -94,6 +108,18 @@ static inline struct m25p *mtd_to_m25p(struct mtd_info *mtd)
 }

 /****************************************************************************/
+/*
+ * Write configuration register 2 byte
+ * Returns negative if error occurred.
+ */
+static int write_cr(struct m25p *flash, u16 val)
+{
+       flash->command[0] = OPCODE_WRSR;
+       flash->command[1] = val >> 8;
+       flash->command[2] = val;
+
+       return spi_write(flash->spi, flash->command, 3);
+}

 /*
  * Internal helper functions
@@ -336,7 +362,6 @@ static int m25p80_read(struct mtd_info *mtd,
loff_t from, size_t len,
        struct m25p *flash = mtd_to_m25p(mtd);
        struct spi_transfer t[2];
        struct spi_message m;
-       uint8_t opcode;

        pr_debug("%s: %s from 0x%08x, len %zd\n", dev_name(&flash->spi->dev),
                        __func__, (u32)from, len);
@@ -349,11 +374,12 @@ static int m25p80_read(struct mtd_info *mtd,
loff_t from, size_t len,
         * Should add 1 byte DUMMY_BYTE.
         */
        t[0].tx_buf = flash->command;
-       t[0].len = m25p_cmdsz(flash) + (flash->fast_read ? 1 : 0);
+       t[0].len = m25p_cmdsz(flash) + flash->read_dummy;
        spi_message_add_tail(&t[0], &m);

        t[1].rx_buf = buf;
        t[1].len = len;
+       t[1].bitwidth = flash->spi->rx_bitwidth;
        spi_message_add_tail(&t[1], &m);

        mutex_lock(&flash->lock);
@@ -370,15 +396,13 @@ static int m25p80_read(struct mtd_info *mtd,
loff_t from, size_t len,
         * supports that opcode.
         */

-       /* Set up the write data buffer. */
-       opcode = flash->fast_read ? OPCODE_FAST_READ : OPCODE_NORM_READ;
-       flash->command[0] = opcode;
+       /* Set up opcode in read buffer */
+       flash->command[0] = flash->read_opcode;
        m25p_addr2cmd(flash, from, flash->command);

        spi_sync(flash->spi, &m);

-       *retlen = m.actual_length - m25p_cmdsz(flash) -
-                       (flash->fast_read ? 1 : 0);
+       *retlen = m.actual_length - m25p_cmdsz(flash) - flash->read_dummy;

        mutex_unlock(&flash->lock);

@@ -409,6 +433,7 @@ static int m25p80_write(struct mtd_info *mtd,
loff_t to, size_t len,
        spi_message_add_tail(&t[0], &m);

        t[1].tx_buf = buf;
+       t[1].bitwidth = flash->spi->tx_bitwidth;
        spi_message_add_tail(&t[1], &m);

        mutex_lock(&flash->lock);
@@ -422,7 +447,7 @@ static int m25p80_write(struct mtd_info *mtd,
loff_t to, size_t len,
        write_enable(flash);

        /* Set up the opcode in the write buffer. */
-       flash->command[0] = OPCODE_PP;
+       flash->command[0] = flash->write_opcode;
        m25p_addr2cmd(flash, to, flash->command);

        page_offset = to & (flash->page_size - 1);
@@ -958,8 +983,7 @@ static int m25p_probe(struct spi_device *spi)
        flash = kzalloc(sizeof *flash, GFP_KERNEL);
        if (!flash)
                return -ENOMEM;
-       flash->command = kmalloc(MAX_CMD_SIZE + (flash->fast_read ? 1 : 0),
-                                       GFP_KERNEL);
+       flash->command = kmalloc(MAX_CMD_SIZE + FAST_READ_DUMMY_BYTE,
GFP_KERNEL);
        if (!flash->command) {
                kfree(flash);
                return -ENOMEM;
@@ -1022,16 +1046,6 @@ static int m25p_probe(struct spi_device *spi)
        flash->page_size = info->page_size;
        flash->mtd.writebufsize = flash->page_size;

-       flash->fast_read = false;
-#ifdef CONFIG_OF
-       if (np && of_property_read_bool(np, "m25p,fast-read"))
-               flash->fast_read = true;
-#endif
-
-#ifdef CONFIG_M25PXX_USE_FAST_READ
-       flash->fast_read = true;
-#endif
-
        if (info->addr_width)
                flash->addr_width = info->addr_width;
        else {
@@ -1063,6 +1077,43 @@ static int m25p_probe(struct spi_device *spi)
                                flash->mtd.eraseregions[i].erasesize / 1024,
                                flash->mtd.eraseregions[i].numblocks);

+       if ((flash->spi->rx_bitwidth == SPI_BITWIDTH_QUAD) ||
+               (flash->spi->tx_bitwidth == SPI_BITWIDTH_QUAD)) {
+               write_enable(flash);
+               write_cr(flash, OPCODE_QEN);
+       }
+
+       switch (flash->spi->rx_bitwidth) {
+       case SPI_BITWIDTH_SINGLE:
+               flash->read_opcode = OPCODE_READ;
+               flash->read_dummy = FAST_READ_DUMMY_BYTE;
+               break;
+       case SPI_BITWIDTH_DUAL:
+               flash->read_opcode = OPCODE_DOR;
+               flash->read_dummy = 1;
+               break;
+       case SPI_BITWIDTH_QUAD:
+               flash->read_opcode = OPCODE_QOR;
+               flash->read_dummy = 1;
+               break;
+       default:
+               dev_err(&spi->dev, "invalid rx_bitwidth %d\n",
+                       flash->spi->rx_bitwidth);
+               return -EINVAL;
+       }
+
+       switch (flash->spi->tx_bitwidth) {
+       case SPI_BITWIDTH_SINGLE:
+               flash->write_opcode = OPCODE_PP;
+               break;
+       case SPI_BITWIDTH_QUAD:
+               flash->write_opcode = OPCODE_QPP;
+               break;
+       default:
+               dev_err(&spi->dev, "invalid tx_bitwidth %d\n",
+                       flash->spi->tx_bitwidth);
+               return -EINVAL;
+       }

        /* partitions should match sector boundaries; and it may be good to
         * use readonly partitions for writeprotected sectors (BP2..BP0).
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 004b10f..cd99022 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -452,6 +452,8 @@ struct spi_device *spi_new_device(struct spi_master *master,
        proxy->irq = chip->irq;
        strlcpy(proxy->modalias, chip->modalias, sizeof(proxy->modalias));
        proxy->dev.platform_data = (void *) chip->platform_data;
+       proxy->rx_bitwidth = chip->rx_bitwidth;
+       proxy->tx_bitwidth = chip->tx_bitwidth;
        proxy->controller_data = chip->controller_data;
        proxy->controller_state = NULL;

diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 38c2b92..ddcf308 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -93,6 +93,8 @@ struct spi_device {
        void                    *controller_data;
        char                    modalias[SPI_NAME_SIZE];
        int                     cs_gpio;        /* chip select gpio */
+       u8                      rx_bitwidth;
+       u8                      tx_bitwidth;

        /*
         * likely need more hooks for more protocol options affecting how
@@ -511,6 +513,10 @@ struct spi_transfer {
        dma_addr_t      rx_dma;

        unsigned        cs_change:1;
+       u8              bitwidth;
+#define        SPI_BITWIDTH_SINGLE     0x01; /* 1bit transfer */
+#define        SPI_BITWIDTH_DUAL       0x02; /* 2bits transfer */
+#define        SPI_BITWIDTH_QUAD       0x03; /* 4bits transfer */
        u8              bits_per_word;
        u16             delay_usecs;
        u32             speed_hz;
@@ -859,6 +865,8 @@ struct spi_board_info {
         * where the default of SPI_CS_HIGH = 0 is wrong.
         */
        u8              mode;
+       u8              rx_bitwidth;
+       u8              tx_bitwidth;

        /* ... may need additional spi_device chip config data here.
         * avoid stuff protocol drivers can set; but include stuff


From rnayak at ti.com  Fri Jul  5 06:32:33 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 5 Jul 2013 16:02:33 +0530
Subject: [PATCH 0/4] OMAP2+: Cleanup PRM and CM regbit headers
Message-ID: <1373020357-13528-1-git-send-email-rnayak@ti.com>

Over the years the PRM and CM headers for OMAP have been growing largely
due to autogeneration which creates headers for complete PRM and
CM register space, regardless of the actual usage of these registers in
the kernel.

The PRM and CM regbit headers in particular were found to be around 
90% unused and hence this series is an attempt to clean all unsued
data from these headers.

Rajendra Nayak (4):
  ARM: OMAP2: PRM/CM: Cleanup unused header
  ARM: OMAP3: PRM/CM: Cleanup unused header
  ARM: OMAP4: PRM/CM: Cleanup unused header
  ARM: OMAP5: PRM/CM: Cleanup unused header

 arch/arm/mach-omap2/cm-regbits-24xx.h       |  318 ----
 arch/arm/mach-omap2/cm-regbits-33xx.h       |  749 --------
 arch/arm/mach-omap2/cm-regbits-34xx.h       |  632 -------
 arch/arm/mach-omap2/cm-regbits-44xx.h       | 1558 ---------------
 arch/arm/mach-omap2/cm-regbits-54xx.h       | 1633 ----------------
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c  |    1 -
 arch/arm/mach-omap2/powerdomains54xx_data.c |    1 -
 arch/arm/mach-omap2/prm-regbits-24xx.h      |  247 ---
 arch/arm/mach-omap2/prm-regbits-33xx.h      |  306 ---
 arch/arm/mach-omap2/prm-regbits-34xx.h      |  481 -----
 arch/arm/mach-omap2/prm-regbits-44xx.h      | 2226 ----------------------
 arch/arm/mach-omap2/prm-regbits-54xx.h      | 2701 ---------------------------
 12 files changed, 10853 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/prm-regbits-54xx.h

-- 
1.7.9.5



From rnayak at ti.com  Fri Jul  5 06:32:34 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 5 Jul 2013 16:02:34 +0530
Subject: [PATCH 1/4] ARM: OMAP2: PRM/CM: Cleanup unused header
In-Reply-To: <1373020357-13528-1-git-send-email-rnayak@ti.com>
References: <1373020357-13528-1-git-send-email-rnayak@ti.com>
Message-ID: <1373020357-13528-2-git-send-email-rnayak@ti.com>

Cleanup unused parts of the PRM and CM regbit headers leaving only whats
used.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/cm-regbits-24xx.h  |  318 --------------------------------
 arch/arm/mach-omap2/prm-regbits-24xx.h |  247 -------------------------
 2 files changed, 565 deletions(-)

diff --git a/arch/arm/mach-omap2/cm-regbits-24xx.h b/arch/arm/mach-omap2/cm-regbits-24xx.h
index 669ef51..8538669 100644
--- a/arch/arm/mach-omap2/cm-regbits-24xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-24xx.h
@@ -14,439 +14,121 @@
  * published by the Free Software Foundation.
  */
 
-/* Bits shared between registers */
-
-/* CM_FCLKEN1_CORE and CM_ICLKEN1_CORE shared bits */
 #define OMAP24XX_EN_CAM_SHIFT				31
-#define OMAP24XX_EN_CAM_MASK				(1 << 31)
 #define OMAP24XX_EN_WDT4_SHIFT				29
-#define OMAP24XX_EN_WDT4_MASK				(1 << 29)
 #define OMAP2420_EN_WDT3_SHIFT				28
-#define OMAP2420_EN_WDT3_MASK				(1 << 28)
 #define OMAP24XX_EN_MSPRO_SHIFT				27
-#define OMAP24XX_EN_MSPRO_MASK				(1 << 27)
 #define OMAP24XX_EN_FAC_SHIFT				25
-#define OMAP24XX_EN_FAC_MASK				(1 << 25)
 #define OMAP2420_EN_EAC_SHIFT				24
-#define OMAP2420_EN_EAC_MASK				(1 << 24)
 #define OMAP24XX_EN_HDQ_SHIFT				23
-#define OMAP24XX_EN_HDQ_MASK				(1 << 23)
 #define OMAP2420_EN_I2C2_SHIFT				20
-#define OMAP2420_EN_I2C2_MASK				(1 << 20)
 #define OMAP2420_EN_I2C1_SHIFT				19
-#define OMAP2420_EN_I2C1_MASK				(1 << 19)
-
-/* CM_FCLKEN2_CORE and CM_ICLKEN2_CORE shared bits */
 #define OMAP2430_EN_MCBSP5_SHIFT			5
-#define OMAP2430_EN_MCBSP5_MASK				(1 << 5)
 #define OMAP2430_EN_MCBSP4_SHIFT			4
-#define OMAP2430_EN_MCBSP4_MASK				(1 << 4)
 #define OMAP2430_EN_MCBSP3_SHIFT			3
-#define OMAP2430_EN_MCBSP3_MASK				(1 << 3)
 #define OMAP24XX_EN_SSI_SHIFT				1
-#define OMAP24XX_EN_SSI_MASK				(1 << 1)
-
-/* CM_FCLKEN_WKUP and CM_ICLKEN_WKUP shared bits */
 #define OMAP24XX_EN_MPU_WDT_SHIFT			3
-#define OMAP24XX_EN_MPU_WDT_MASK			(1 << 3)
-
-/* Bits specific to each register */
-
-/* CM_IDLEST_MPU */
-/* 2430 only */
-#define OMAP2430_ST_MPU_MASK				(1 << 0)
-
-/* CM_CLKSEL_MPU */
 #define OMAP24XX_CLKSEL_MPU_SHIFT			0
-#define OMAP24XX_CLKSEL_MPU_MASK			(0x1f << 0)
 #define OMAP24XX_CLKSEL_MPU_WIDTH			5
-
-/* CM_CLKSTCTRL_MPU */
-#define OMAP24XX_AUTOSTATE_MPU_SHIFT			0
 #define OMAP24XX_AUTOSTATE_MPU_MASK			(1 << 0)
-
-/* CM_FCLKEN1_CORE specific bits*/
 #define OMAP24XX_EN_TV_SHIFT				2
-#define OMAP24XX_EN_TV_MASK				(1 << 2)
 #define OMAP24XX_EN_DSS2_SHIFT				1
-#define OMAP24XX_EN_DSS2_MASK				(1 << 1)
 #define OMAP24XX_EN_DSS1_SHIFT				0
 #define OMAP24XX_EN_DSS1_MASK				(1 << 0)
-
-/* CM_FCLKEN2_CORE specific bits */
 #define OMAP2430_EN_I2CHS2_SHIFT			20
-#define OMAP2430_EN_I2CHS2_MASK				(1 << 20)
 #define OMAP2430_EN_I2CHS1_SHIFT			19
-#define OMAP2430_EN_I2CHS1_MASK				(1 << 19)
 #define OMAP2430_EN_MMCHSDB2_SHIFT			17
-#define OMAP2430_EN_MMCHSDB2_MASK			(1 << 17)
 #define OMAP2430_EN_MMCHSDB1_SHIFT			16
-#define OMAP2430_EN_MMCHSDB1_MASK			(1 << 16)
-
-/* CM_ICLKEN1_CORE specific bits */
 #define OMAP24XX_EN_MAILBOXES_SHIFT			30
-#define OMAP24XX_EN_MAILBOXES_MASK			(1 << 30)
-#define OMAP24XX_EN_DSS_SHIFT				0
-#define OMAP24XX_EN_DSS_MASK				(1 << 0)
-
-/* CM_ICLKEN2_CORE specific bits */
-
-/* CM_ICLKEN3_CORE */
-/* 2430 only */
 #define OMAP2430_EN_SDRC_SHIFT				2
-#define OMAP2430_EN_SDRC_MASK				(1 << 2)
-
-/* CM_ICLKEN4_CORE */
 #define OMAP24XX_EN_PKA_SHIFT				4
-#define OMAP24XX_EN_PKA_MASK				(1 << 4)
 #define OMAP24XX_EN_AES_SHIFT				3
-#define OMAP24XX_EN_AES_MASK				(1 << 3)
 #define OMAP24XX_EN_RNG_SHIFT				2
-#define OMAP24XX_EN_RNG_MASK				(1 << 2)
 #define OMAP24XX_EN_SHA_SHIFT				1
-#define OMAP24XX_EN_SHA_MASK				(1 << 1)
 #define OMAP24XX_EN_DES_SHIFT				0
-#define OMAP24XX_EN_DES_MASK				(1 << 0)
-
-/* CM_IDLEST1_CORE specific bits */
 #define OMAP24XX_ST_MAILBOXES_SHIFT			30
-#define OMAP24XX_ST_MAILBOXES_MASK			(1 << 30)
-#define OMAP24XX_ST_WDT4_SHIFT				29
-#define OMAP24XX_ST_WDT4_MASK				(1 << 29)
-#define OMAP2420_ST_WDT3_SHIFT				28
-#define OMAP2420_ST_WDT3_MASK				(1 << 28)
-#define OMAP24XX_ST_MSPRO_SHIFT				27
-#define OMAP24XX_ST_MSPRO_MASK				(1 << 27)
-#define OMAP24XX_ST_FAC_SHIFT				25
-#define OMAP24XX_ST_FAC_MASK				(1 << 25)
-#define OMAP2420_ST_EAC_SHIFT				24
-#define OMAP2420_ST_EAC_MASK				(1 << 24)
 #define OMAP24XX_ST_HDQ_SHIFT				23
-#define OMAP24XX_ST_HDQ_MASK				(1 << 23)
 #define OMAP2420_ST_I2C2_SHIFT				20
-#define OMAP2420_ST_I2C2_MASK				(1 << 20)
 #define OMAP2430_ST_I2CHS1_SHIFT			19
-#define OMAP2430_ST_I2CHS1_MASK				(1 << 19)
 #define OMAP2420_ST_I2C1_SHIFT				19
-#define OMAP2420_ST_I2C1_MASK				(1 << 19)
 #define OMAP2430_ST_I2CHS2_SHIFT			20
-#define OMAP2430_ST_I2CHS2_MASK				(1 << 20)
 #define OMAP24XX_ST_MCBSP2_SHIFT			16
-#define OMAP24XX_ST_MCBSP2_MASK				(1 << 16)
 #define OMAP24XX_ST_MCBSP1_SHIFT			15
-#define OMAP24XX_ST_MCBSP1_MASK				(1 << 15)
 #define OMAP24XX_ST_DSS_SHIFT				0
-#define OMAP24XX_ST_DSS_MASK				(1 << 0)
-
-/* CM_IDLEST2_CORE */
 #define OMAP2430_ST_MCBSP5_SHIFT			5
-#define OMAP2430_ST_MCBSP5_MASK				(1 << 5)
 #define OMAP2430_ST_MCBSP4_SHIFT			4
-#define OMAP2430_ST_MCBSP4_MASK				(1 << 4)
 #define OMAP2430_ST_MCBSP3_SHIFT			3
-#define OMAP2430_ST_MCBSP3_MASK				(1 << 3)
-#define OMAP24XX_ST_SSI_SHIFT				1
-#define OMAP24XX_ST_SSI_MASK				(1 << 1)
-
-/* CM_IDLEST3_CORE */
-/* 2430 only */
-#define OMAP2430_ST_SDRC_MASK				(1 << 2)
-
-/* CM_IDLEST4_CORE */
-#define OMAP24XX_ST_PKA_SHIFT				4
-#define OMAP24XX_ST_PKA_MASK				(1 << 4)
 #define OMAP24XX_ST_AES_SHIFT				3
-#define OMAP24XX_ST_AES_MASK				(1 << 3)
 #define OMAP24XX_ST_RNG_SHIFT				2
-#define OMAP24XX_ST_RNG_MASK				(1 << 2)
 #define OMAP24XX_ST_SHA_SHIFT				1
-#define OMAP24XX_ST_SHA_MASK				(1 << 1)
-#define OMAP24XX_ST_DES_SHIFT				0
-#define OMAP24XX_ST_DES_MASK				(1 << 0)
-
-/* CM_AUTOIDLE1_CORE */
-#define OMAP24XX_AUTO_CAM_MASK				(1 << 31)
-#define OMAP24XX_AUTO_MAILBOXES_MASK			(1 << 30)
-#define OMAP24XX_AUTO_WDT4_MASK				(1 << 29)
-#define OMAP2420_AUTO_WDT3_MASK				(1 << 28)
-#define OMAP24XX_AUTO_MSPRO_MASK			(1 << 27)
-#define OMAP2420_AUTO_MMC_MASK				(1 << 26)
-#define OMAP24XX_AUTO_FAC_MASK				(1 << 25)
-#define OMAP2420_AUTO_EAC_MASK				(1 << 24)
-#define OMAP24XX_AUTO_HDQ_MASK				(1 << 23)
-#define OMAP24XX_AUTO_UART2_MASK			(1 << 22)
-#define OMAP24XX_AUTO_UART1_MASK			(1 << 21)
-#define OMAP24XX_AUTO_I2C2_MASK				(1 << 20)
-#define OMAP24XX_AUTO_I2C1_MASK				(1 << 19)
-#define OMAP24XX_AUTO_MCSPI2_MASK			(1 << 18)
-#define OMAP24XX_AUTO_MCSPI1_MASK			(1 << 17)
-#define OMAP24XX_AUTO_MCBSP2_MASK			(1 << 16)
-#define OMAP24XX_AUTO_MCBSP1_MASK			(1 << 15)
-#define OMAP24XX_AUTO_GPT12_MASK			(1 << 14)
-#define OMAP24XX_AUTO_GPT11_MASK			(1 << 13)
-#define OMAP24XX_AUTO_GPT10_MASK			(1 << 12)
-#define OMAP24XX_AUTO_GPT9_MASK				(1 << 11)
-#define OMAP24XX_AUTO_GPT8_MASK				(1 << 10)
-#define OMAP24XX_AUTO_GPT7_MASK				(1 << 9)
-#define OMAP24XX_AUTO_GPT6_MASK				(1 << 8)
-#define OMAP24XX_AUTO_GPT5_MASK				(1 << 7)
-#define OMAP24XX_AUTO_GPT4_MASK				(1 << 6)
-#define OMAP24XX_AUTO_GPT3_MASK				(1 << 5)
-#define OMAP24XX_AUTO_GPT2_MASK				(1 << 4)
-#define OMAP2420_AUTO_VLYNQ_MASK			(1 << 3)
-#define OMAP24XX_AUTO_DSS_MASK				(1 << 0)
-
-/* CM_AUTOIDLE2_CORE */
-#define OMAP2430_AUTO_MDM_INTC_MASK			(1 << 11)
-#define OMAP2430_AUTO_GPIO5_MASK			(1 << 10)
-#define OMAP2430_AUTO_MCSPI3_MASK			(1 << 9)
-#define OMAP2430_AUTO_MMCHS2_MASK			(1 << 8)
-#define OMAP2430_AUTO_MMCHS1_MASK			(1 << 7)
-#define OMAP2430_AUTO_USBHS_MASK			(1 << 6)
-#define OMAP2430_AUTO_MCBSP5_MASK			(1 << 5)
-#define OMAP2430_AUTO_MCBSP4_MASK			(1 << 4)
-#define OMAP2430_AUTO_MCBSP3_MASK			(1 << 3)
-#define OMAP24XX_AUTO_UART3_MASK			(1 << 2)
-#define OMAP24XX_AUTO_SSI_MASK				(1 << 1)
-#define OMAP24XX_AUTO_USB_MASK				(1 << 0)
-
-/* CM_AUTOIDLE3_CORE */
 #define OMAP24XX_AUTO_SDRC_SHIFT			2
-#define OMAP24XX_AUTO_SDRC_MASK				(1 << 2)
 #define OMAP24XX_AUTO_GPMC_SHIFT			1
-#define OMAP24XX_AUTO_GPMC_MASK				(1 << 1)
 #define OMAP24XX_AUTO_SDMA_SHIFT			0
-#define OMAP24XX_AUTO_SDMA_MASK				(1 << 0)
-
-/* CM_AUTOIDLE4_CORE */
-#define OMAP24XX_AUTO_PKA_MASK				(1 << 4)
-#define OMAP24XX_AUTO_AES_MASK				(1 << 3)
-#define OMAP24XX_AUTO_RNG_MASK				(1 << 2)
-#define OMAP24XX_AUTO_SHA_MASK				(1 << 1)
-#define OMAP24XX_AUTO_DES_MASK				(1 << 0)
-
-/* CM_CLKSEL1_CORE */
-#define OMAP24XX_CLKSEL_USB_SHIFT			25
 #define OMAP24XX_CLKSEL_USB_MASK			(0x7 << 25)
-#define OMAP24XX_CLKSEL_SSI_SHIFT			20
 #define OMAP24XX_CLKSEL_SSI_MASK			(0x1f << 20)
-#define OMAP2420_CLKSEL_VLYNQ_SHIFT			15
 #define OMAP2420_CLKSEL_VLYNQ_MASK			(0x1f << 15)
-#define OMAP24XX_CLKSEL_DSS2_SHIFT			13
 #define OMAP24XX_CLKSEL_DSS2_MASK			(0x1 << 13)
-#define OMAP24XX_CLKSEL_DSS1_SHIFT			8
 #define OMAP24XX_CLKSEL_DSS1_MASK			(0x1f << 8)
 #define OMAP24XX_CLKSEL_L4_SHIFT			5
-#define OMAP24XX_CLKSEL_L4_MASK				(0x3 << 5)
 #define OMAP24XX_CLKSEL_L4_WIDTH			2
 #define OMAP24XX_CLKSEL_L3_SHIFT			0
-#define OMAP24XX_CLKSEL_L3_MASK				(0x1f << 0)
 #define OMAP24XX_CLKSEL_L3_WIDTH			5
-
-/* CM_CLKSEL2_CORE */
-#define OMAP24XX_CLKSEL_GPT12_SHIFT			22
 #define OMAP24XX_CLKSEL_GPT12_MASK			(0x3 << 22)
-#define OMAP24XX_CLKSEL_GPT11_SHIFT			20
 #define OMAP24XX_CLKSEL_GPT11_MASK			(0x3 << 20)
-#define OMAP24XX_CLKSEL_GPT10_SHIFT			18
 #define OMAP24XX_CLKSEL_GPT10_MASK			(0x3 << 18)
-#define OMAP24XX_CLKSEL_GPT9_SHIFT			16
 #define OMAP24XX_CLKSEL_GPT9_MASK			(0x3 << 16)
-#define OMAP24XX_CLKSEL_GPT8_SHIFT			14
 #define OMAP24XX_CLKSEL_GPT8_MASK			(0x3 << 14)
-#define OMAP24XX_CLKSEL_GPT7_SHIFT			12
 #define OMAP24XX_CLKSEL_GPT7_MASK			(0x3 << 12)
-#define OMAP24XX_CLKSEL_GPT6_SHIFT			10
 #define OMAP24XX_CLKSEL_GPT6_MASK			(0x3 << 10)
-#define OMAP24XX_CLKSEL_GPT5_SHIFT			8
 #define OMAP24XX_CLKSEL_GPT5_MASK			(0x3 << 8)
-#define OMAP24XX_CLKSEL_GPT4_SHIFT			6
 #define OMAP24XX_CLKSEL_GPT4_MASK			(0x3 << 6)
-#define OMAP24XX_CLKSEL_GPT3_SHIFT			4
 #define OMAP24XX_CLKSEL_GPT3_MASK			(0x3 << 4)
-#define OMAP24XX_CLKSEL_GPT2_SHIFT			2
 #define OMAP24XX_CLKSEL_GPT2_MASK			(0x3 << 2)
-
-/* CM_CLKSTCTRL_CORE */
-#define OMAP24XX_AUTOSTATE_DSS_SHIFT			2
 #define OMAP24XX_AUTOSTATE_DSS_MASK			(1 << 2)
-#define OMAP24XX_AUTOSTATE_L4_SHIFT			1
 #define OMAP24XX_AUTOSTATE_L4_MASK			(1 << 1)
-#define OMAP24XX_AUTOSTATE_L3_SHIFT			0
 #define OMAP24XX_AUTOSTATE_L3_MASK			(1 << 0)
-
-/* CM_FCLKEN_GFX */
 #define OMAP24XX_EN_3D_SHIFT				2
-#define OMAP24XX_EN_3D_MASK				(1 << 2)
 #define OMAP24XX_EN_2D_SHIFT				1
-#define OMAP24XX_EN_2D_MASK				(1 << 1)
-
-/* CM_ICLKEN_GFX specific bits */
-
-/* CM_IDLEST_GFX specific bits */
-
-/* CM_CLKSEL_GFX specific bits */
-
-/* CM_CLKSTCTRL_GFX */
-#define OMAP24XX_AUTOSTATE_GFX_SHIFT			0
 #define OMAP24XX_AUTOSTATE_GFX_MASK			(1 << 0)
-
-/* CM_FCLKEN_WKUP specific bits */
-
-/* CM_ICLKEN_WKUP specific bits */
 #define OMAP2430_EN_ICR_SHIFT				6
-#define OMAP2430_EN_ICR_MASK				(1 << 6)
 #define OMAP24XX_EN_OMAPCTRL_SHIFT			5
-#define OMAP24XX_EN_OMAPCTRL_MASK			(1 << 5)
 #define OMAP24XX_EN_WDT1_SHIFT				4
-#define OMAP24XX_EN_WDT1_MASK				(1 << 4)
 #define OMAP24XX_EN_32KSYNC_SHIFT			1
-#define OMAP24XX_EN_32KSYNC_MASK			(1 << 1)
-
-/* CM_IDLEST_WKUP specific bits */
-#define OMAP2430_ST_ICR_SHIFT				6
-#define OMAP2430_ST_ICR_MASK				(1 << 6)
-#define OMAP24XX_ST_OMAPCTRL_SHIFT			5
-#define OMAP24XX_ST_OMAPCTRL_MASK			(1 << 5)
-#define OMAP24XX_ST_WDT1_SHIFT				4
-#define OMAP24XX_ST_WDT1_MASK				(1 << 4)
 #define OMAP24XX_ST_MPU_WDT_SHIFT			3
-#define OMAP24XX_ST_MPU_WDT_MASK			(1 << 3)
 #define OMAP24XX_ST_32KSYNC_SHIFT			1
-#define OMAP24XX_ST_32KSYNC_MASK			(1 << 1)
-
-/* CM_AUTOIDLE_WKUP */
-#define OMAP24XX_AUTO_OMAPCTRL_MASK			(1 << 5)
-#define OMAP24XX_AUTO_WDT1_MASK				(1 << 4)
-#define OMAP24XX_AUTO_MPU_WDT_MASK			(1 << 3)
-#define OMAP24XX_AUTO_GPIOS_MASK			(1 << 2)
-#define OMAP24XX_AUTO_32KSYNC_MASK			(1 << 1)
-#define OMAP24XX_AUTO_GPT1_MASK				(1 << 0)
-
-/* CM_CLKSEL_WKUP */
-#define OMAP24XX_CLKSEL_GPT1_SHIFT			0
 #define OMAP24XX_CLKSEL_GPT1_MASK			(0x3 << 0)
-
-/* CM_CLKEN_PLL */
 #define OMAP24XX_EN_54M_PLL_SHIFT			6
-#define OMAP24XX_EN_54M_PLL_MASK			(0x3 << 6)
 #define OMAP24XX_EN_96M_PLL_SHIFT			2
-#define OMAP24XX_EN_96M_PLL_MASK			(0x3 << 2)
-#define OMAP24XX_EN_DPLL_SHIFT				0
 #define OMAP24XX_EN_DPLL_MASK				(0x3 << 0)
-
-/* CM_IDLEST_CKGEN */
 #define OMAP24XX_ST_54M_APLL_SHIFT			9
-#define OMAP24XX_ST_54M_APLL_MASK			(1 << 9)
 #define OMAP24XX_ST_96M_APLL_SHIFT			8
-#define OMAP24XX_ST_96M_APLL_MASK			(1 << 8)
-#define OMAP24XX_ST_54M_CLK_MASK			(1 << 6)
-#define OMAP24XX_ST_12M_CLK_MASK			(1 << 5)
-#define OMAP24XX_ST_48M_CLK_MASK			(1 << 4)
-#define OMAP24XX_ST_96M_CLK_MASK			(1 << 2)
-#define OMAP24XX_ST_CORE_CLK_SHIFT			0
-#define OMAP24XX_ST_CORE_CLK_MASK			(0x3 << 0)
-
-/* CM_AUTOIDLE_PLL */
-#define OMAP24XX_AUTO_54M_SHIFT				6
 #define OMAP24XX_AUTO_54M_MASK				(0x3 << 6)
-#define OMAP24XX_AUTO_96M_SHIFT				2
 #define OMAP24XX_AUTO_96M_MASK				(0x3 << 2)
 #define OMAP24XX_AUTO_DPLL_SHIFT			0
 #define OMAP24XX_AUTO_DPLL_MASK				(0x3 << 0)
-
-/* CM_CLKSEL1_PLL */
-#define OMAP2430_MAXDPLLFASTLOCK_SHIFT			28
-#define OMAP2430_MAXDPLLFASTLOCK_MASK			(0x7 << 28)
 #define OMAP24XX_APLLS_CLKIN_SHIFT			23
 #define OMAP24XX_APLLS_CLKIN_MASK			(0x7 << 23)
-#define OMAP24XX_DPLL_MULT_SHIFT			12
 #define OMAP24XX_DPLL_MULT_MASK				(0x3ff << 12)
-#define OMAP24XX_DPLL_DIV_SHIFT				8
 #define OMAP24XX_DPLL_DIV_MASK				(0xf << 8)
 #define OMAP24XX_54M_SOURCE_SHIFT			5
-#define OMAP24XX_54M_SOURCE_MASK			(1 << 5)
 #define OMAP24XX_54M_SOURCE_WIDTH			1
 #define OMAP2430_96M_SOURCE_SHIFT			4
-#define OMAP2430_96M_SOURCE_MASK			(1 << 4)
 #define OMAP2430_96M_SOURCE_WIDTH			1
-#define OMAP24XX_48M_SOURCE_SHIFT			3
 #define OMAP24XX_48M_SOURCE_MASK			(1 << 3)
-#define OMAP2430_ALTCLK_SOURCE_SHIFT			0
-#define OMAP2430_ALTCLK_SOURCE_MASK			(0x7 << 0)
-
-/* CM_CLKSEL2_PLL */
-#define OMAP24XX_CORE_CLK_SRC_SHIFT			0
 #define OMAP24XX_CORE_CLK_SRC_MASK			(0x3 << 0)
-
-/* CM_FCLKEN_DSP */
 #define OMAP2420_EN_IVA_COP_SHIFT			10
-#define OMAP2420_EN_IVA_COP_MASK			(1 << 10)
 #define OMAP2420_EN_IVA_MPU_SHIFT			8
-#define OMAP2420_EN_IVA_MPU_MASK			(1 << 8)
 #define OMAP24XX_CM_FCLKEN_DSP_EN_DSP_SHIFT		0
-#define OMAP24XX_CM_FCLKEN_DSP_EN_DSP_MASK		(1 << 0)
-
-/* CM_ICLKEN_DSP */
 #define OMAP2420_EN_DSP_IPI_SHIFT			1
-#define OMAP2420_EN_DSP_IPI_MASK			(1 << 1)
-
-/* CM_IDLEST_DSP */
-#define OMAP2420_ST_IVA_MASK				(1 << 8)
-#define OMAP2420_ST_IPI_MASK				(1 << 1)
-#define OMAP24XX_ST_DSP_MASK				(1 << 0)
-
-/* CM_AUTOIDLE_DSP */
-#define OMAP2420_AUTO_DSP_IPI_MASK			(1 << 1)
-
-/* CM_CLKSEL_DSP */
-#define OMAP2420_SYNC_IVA_MASK				(1 << 13)
-#define OMAP2420_CLKSEL_IVA_SHIFT			8
 #define OMAP2420_CLKSEL_IVA_MASK			(0x1f << 8)
-#define OMAP24XX_SYNC_DSP_MASK				(1 << 7)
-#define OMAP24XX_CLKSEL_DSP_IF_SHIFT			5
 #define OMAP24XX_CLKSEL_DSP_IF_MASK			(0x3 << 5)
-#define OMAP24XX_CLKSEL_DSP_SHIFT			0
 #define OMAP24XX_CLKSEL_DSP_MASK			(0x1f << 0)
-
-/* CM_CLKSTCTRL_DSP */
-#define OMAP2420_AUTOSTATE_IVA_SHIFT			8
 #define OMAP2420_AUTOSTATE_IVA_MASK			(1 << 8)
-#define OMAP24XX_AUTOSTATE_DSP_SHIFT			0
 #define OMAP24XX_AUTOSTATE_DSP_MASK			(1 << 0)
-
-/* CM_FCLKEN_MDM */
-/* 2430 only */
 #define OMAP2430_EN_OSC_SHIFT				1
-#define OMAP2430_EN_OSC_MASK				(1 << 1)
-
-/* CM_ICLKEN_MDM */
-/* 2430 only */
 #define OMAP2430_CM_ICLKEN_MDM_EN_MDM_SHIFT		0
-#define OMAP2430_CM_ICLKEN_MDM_EN_MDM_MASK		(1 << 0)
-
-/* CM_IDLEST_MDM specific bits */
-/* 2430 only */
-
-/* CM_AUTOIDLE_MDM */
-/* 2430 only */
-#define OMAP2430_AUTO_OSC_MASK				(1 << 1)
-#define OMAP2430_AUTO_MDM_MASK				(1 << 0)
-
-/* CM_CLKSEL_MDM */
-/* 2430 only */
-#define OMAP2430_SYNC_MDM_MASK				(1 << 4)
-#define OMAP2430_CLKSEL_MDM_SHIFT			0
 #define OMAP2430_CLKSEL_MDM_MASK			(0xf << 0)
-
-/* CM_CLKSTCTRL_MDM */
-/* 2430 only */
-#define OMAP2430_AUTOSTATE_MDM_SHIFT			0
 #define OMAP2430_AUTOSTATE_MDM_MASK			(1 << 0)
-
-/* OMAP24XX CM_CLKSTCTRL_*.AUTOSTATE_* register bit values */
 #define OMAP24XX_CLKSTCTRL_DISABLE_AUTO		0x0
 #define OMAP24XX_CLKSTCTRL_ENABLE_AUTO		0x1
-
-
 #endif
diff --git a/arch/arm/mach-omap2/prm-regbits-24xx.h b/arch/arm/mach-omap2/prm-regbits-24xx.h
index 91aa510..37fc905 100644
--- a/arch/arm/mach-omap2/prm-regbits-24xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-24xx.h
@@ -16,274 +16,27 @@
 
 #include "prm2xxx.h"
 
-/* Bits shared between registers */
-
-/* PRCM_IRQSTATUS_MPU, PM_IRQSTATUS_DSP, PRCM_IRQSTATUS_IVA shared bits */
-#define OMAP24XX_VOLTTRANS_ST_MASK			(1 << 2)
-#define OMAP24XX_WKUP2_ST_MASK				(1 << 1)
-#define OMAP24XX_WKUP1_ST_MASK				(1 << 0)
-
-/* PRCM_IRQENABLE_MPU, PM_IRQENABLE_DSP, PRCM_IRQENABLE_IVA shared bits */
-#define OMAP24XX_VOLTTRANS_EN_MASK			(1 << 2)
-#define OMAP24XX_WKUP2_EN_MASK				(1 << 1)
-#define OMAP24XX_WKUP1_EN_MASK				(1 << 0)
-
-/* PM_WKDEP_GFX, PM_WKDEP_MPU, PM_WKDEP_DSP, PM_WKDEP_MDM shared bits */
-#define OMAP24XX_EN_MPU_SHIFT				1
-#define OMAP24XX_EN_MPU_MASK				(1 << 1)
 #define OMAP24XX_EN_CORE_SHIFT 				0
-#define OMAP24XX_EN_CORE_MASK				(1 << 0)
-
-/*
- * PM_PWSTCTRL_MPU, PM_PWSTCTRL_GFX, PM_PWSTCTRL_DSP, PM_PWSTCTRL_MDM
- * shared bits
- */
-#define OMAP24XX_MEMONSTATE_SHIFT			10
-#define OMAP24XX_MEMONSTATE_MASK			(0x3 << 10)
-#define OMAP24XX_MEMRETSTATE_MASK			(1 << 3)
-
-/* PM_PWSTCTRL_GFX, PM_PWSTCTRL_DSP, PM_PWSTCTRL_MDM shared bits */
 #define OMAP24XX_FORCESTATE_MASK			(1 << 18)
-
-/*
- * PM_PWSTST_CORE, PM_PWSTST_GFX, PM_PWSTST_MPU, PM_PWSTST_DSP,
- * PM_PWSTST_MDM shared bits
- */
-#define OMAP24XX_CLKACTIVITY_MASK			(1 << 19)
-
-/* PM_PWSTST_MPU, PM_PWSTST_CORE, PM_PWSTST_DSP shared bits */
-#define OMAP24XX_LASTSTATEENTERED_SHIFT			4
-#define OMAP24XX_LASTSTATEENTERED_MASK			(0x3 << 4)
-
-/* PM_PWSTST_MPU and PM_PWSTST_DSP shared bits */
-#define OMAP2430_MEMSTATEST_SHIFT			10
-#define OMAP2430_MEMSTATEST_MASK			(0x3 << 10)
-
-/* PM_PWSTST_GFX, PM_PWSTST_DSP, PM_PWSTST_MDM shared bits */
-#define OMAP24XX_POWERSTATEST_SHIFT			0
-#define OMAP24XX_POWERSTATEST_MASK			(0x3 << 0)
-
-
-/* Bits specific to each register */
-
-/* PRCM_REVISION */
-#define OMAP24XX_REV_SHIFT				0
-#define OMAP24XX_REV_MASK				(0xff << 0)
-
-/* PRCM_SYSCONFIG */
 #define OMAP24XX_AUTOIDLE_MASK				(1 << 0)
-
-/* PRCM_IRQSTATUS_MPU specific bits */
-#define OMAP2430_DPLL_RECAL_ST_MASK			(1 << 6)
-#define OMAP24XX_TRANSITION_ST_MASK			(1 << 5)
-#define OMAP24XX_EVGENOFF_ST_MASK			(1 << 4)
-#define OMAP24XX_EVGENON_ST_MASK			(1 << 3)
-
-/* PRCM_IRQENABLE_MPU specific bits */
-#define OMAP2430_DPLL_RECAL_EN_MASK			(1 << 6)
-#define OMAP24XX_TRANSITION_EN_MASK			(1 << 5)
-#define OMAP24XX_EVGENOFF_EN_MASK			(1 << 4)
-#define OMAP24XX_EVGENON_EN_MASK			(1 << 3)
-
-/* PRCM_VOLTCTRL */
 #define OMAP24XX_AUTO_EXTVOLT_MASK			(1 << 15)
-#define OMAP24XX_FORCE_EXTVOLT_MASK			(1 << 14)
 #define OMAP24XX_SETOFF_LEVEL_SHIFT			12
-#define OMAP24XX_SETOFF_LEVEL_MASK			(0x3 << 12)
 #define OMAP24XX_MEMRETCTRL_MASK			(1 << 8)
 #define OMAP24XX_SETRET_LEVEL_SHIFT			6
-#define OMAP24XX_SETRET_LEVEL_MASK			(0x3 << 6)
 #define OMAP24XX_VOLT_LEVEL_SHIFT			0
-#define OMAP24XX_VOLT_LEVEL_MASK			(0x3 << 0)
-
-/* PRCM_VOLTST */
-#define OMAP24XX_ST_VOLTLEVEL_SHIFT			0
-#define OMAP24XX_ST_VOLTLEVEL_MASK			(0x3 << 0)
-
-/* PRCM_CLKSRC_CTRL specific bits */
-
-/* PRCM_CLKOUT_CTRL */
 #define OMAP2420_CLKOUT2_EN_SHIFT			15
-#define OMAP2420_CLKOUT2_EN_MASK			(1 << 15)
 #define OMAP2420_CLKOUT2_DIV_SHIFT			11
-#define OMAP2420_CLKOUT2_DIV_MASK			(0x7 << 11)
 #define OMAP2420_CLKOUT2_DIV_WIDTH			3
-#define OMAP2420_CLKOUT2_SOURCE_SHIFT			8
 #define OMAP2420_CLKOUT2_SOURCE_MASK			(0x3 << 8)
 #define OMAP24XX_CLKOUT_EN_SHIFT			7
-#define OMAP24XX_CLKOUT_EN_MASK				(1 << 7)
 #define OMAP24XX_CLKOUT_DIV_SHIFT			3
-#define OMAP24XX_CLKOUT_DIV_MASK			(0x7 << 3)
 #define OMAP24XX_CLKOUT_DIV_WIDTH			3
-#define OMAP24XX_CLKOUT_SOURCE_SHIFT			0
 #define OMAP24XX_CLKOUT_SOURCE_MASK			(0x3 << 0)
-
-/* PRCM_CLKEMUL_CTRL */
 #define OMAP24XX_EMULATION_EN_SHIFT			0
-#define OMAP24XX_EMULATION_EN_MASK			(1 << 0)
-
-/* PRCM_CLKCFG_CTRL */
-#define OMAP24XX_VALID_CONFIG_MASK			(1 << 0)
-
-/* PRCM_CLKCFG_STATUS */
-#define OMAP24XX_CONFIG_STATUS_MASK			(1 << 0)
-
-/* PRCM_VOLTSETUP specific bits */
-
-/* PRCM_CLKSSETUP specific bits */
-
-/* PRCM_POLCTRL */
-#define OMAP2420_CLKOUT2_POL_MASK			(1 << 10)
-#define OMAP24XX_CLKOUT_POL_MASK			(1 << 9)
-#define OMAP24XX_CLKREQ_POL_MASK			(1 << 8)
-#define OMAP2430_USE_POWEROK_MASK			(1 << 2)
-#define OMAP2430_POWEROK_POL_MASK			(1 << 1)
-#define OMAP24XX_EXTVOL_POL_MASK			(1 << 0)
-
-/* RM_RSTST_MPU specific bits */
-/* 2430 calls GLOBALWMPU_RST "GLOBALWARM_RST" instead */
-
-/* PM_WKDEP_MPU specific bits */
 #define OMAP2430_PM_WKDEP_MPU_EN_MDM_SHIFT		5
-#define OMAP2430_PM_WKDEP_MPU_EN_MDM_MASK		(1 << 5)
 #define OMAP24XX_PM_WKDEP_MPU_EN_DSP_SHIFT		2
-#define OMAP24XX_PM_WKDEP_MPU_EN_DSP_MASK		(1 << 2)
-
-/* PM_EVGENCTRL_MPU specific bits */
-
-/* PM_EVEGENONTIM_MPU specific bits */
-
-/* PM_EVEGENOFFTIM_MPU specific bits */
-
-/* PM_PWSTCTRL_MPU specific bits */
-#define OMAP2430_FORCESTATE_MASK			(1 << 18)
-
-/* PM_PWSTST_MPU specific bits */
-/* INTRANSITION, CLKACTIVITY, POWERSTATE, MEMSTATEST are 2430 only */
-
-/* PM_WKEN1_CORE specific bits */
-
-/* PM_WKEN2_CORE specific bits */
-
-/* PM_WKST1_CORE specific bits*/
-
-/* PM_WKST2_CORE specific bits */
-
-/* PM_WKDEP_CORE specific bits*/
-#define OMAP2430_PM_WKDEP_CORE_EN_MDM_MASK		(1 << 5)
-#define OMAP24XX_PM_WKDEP_CORE_EN_GFX_MASK		(1 << 3)
-#define OMAP24XX_PM_WKDEP_CORE_EN_DSP_MASK		(1 << 2)
-
-/* PM_PWSTCTRL_CORE specific bits */
-#define OMAP24XX_MEMORYCHANGE_MASK			(1 << 20)
-#define OMAP24XX_MEM3ONSTATE_SHIFT			14
-#define OMAP24XX_MEM3ONSTATE_MASK			(0x3 << 14)
-#define OMAP24XX_MEM2ONSTATE_SHIFT			12
-#define OMAP24XX_MEM2ONSTATE_MASK			(0x3 << 12)
-#define OMAP24XX_MEM1ONSTATE_SHIFT			10
-#define OMAP24XX_MEM1ONSTATE_MASK			(0x3 << 10)
-#define OMAP24XX_MEM3RETSTATE_MASK			(1 << 5)
-#define OMAP24XX_MEM2RETSTATE_MASK			(1 << 4)
-#define OMAP24XX_MEM1RETSTATE_MASK			(1 << 3)
-
-/* PM_PWSTST_CORE specific bits */
-#define OMAP24XX_MEM3STATEST_SHIFT			14
-#define OMAP24XX_MEM3STATEST_MASK			(0x3 << 14)
-#define OMAP24XX_MEM2STATEST_SHIFT			12
-#define OMAP24XX_MEM2STATEST_MASK			(0x3 << 12)
-#define OMAP24XX_MEM1STATEST_SHIFT			10
-#define OMAP24XX_MEM1STATEST_MASK			(0x3 << 10)
-
-/* RM_RSTCTRL_GFX */
-#define OMAP24XX_GFX_RST_MASK				(1 << 0)
-
-/* RM_RSTST_GFX specific bits */
-#define OMAP24XX_GFX_SW_RST_MASK			(1 << 4)
-
-/* PM_PWSTCTRL_GFX specific bits */
-
-/* PM_WKDEP_GFX specific bits */
-/* 2430 often calls EN_WAKEUP "EN_WKUP" */
-
-/* RM_RSTCTRL_WKUP specific bits */
-
-/* RM_RSTTIME_WKUP specific bits */
-
-/* RM_RSTST_WKUP specific bits */
-/* 2430 calls EXTWMPU_RST "EXTWARM_RST" and GLOBALWMPU_RST "GLOBALWARM_RST" */
 #define OMAP24XX_EXTWMPU_RST_SHIFT			6
-#define OMAP24XX_EXTWMPU_RST_MASK			(1 << 6)
 #define OMAP24XX_SECU_WD_RST_SHIFT			5
-#define OMAP24XX_SECU_WD_RST_MASK			(1 << 5)
 #define OMAP24XX_MPU_WD_RST_SHIFT			4
-#define OMAP24XX_MPU_WD_RST_MASK			(1 << 4)
 #define OMAP24XX_SECU_VIOL_RST_SHIFT			3
-#define OMAP24XX_SECU_VIOL_RST_MASK			(1 << 3)
-
-/* PM_WKEN_WKUP specific bits */
-
-/* PM_WKST_WKUP specific bits */
-
-/* RM_RSTCTRL_DSP */
-#define OMAP2420_RST_IVA_MASK				(1 << 8)
-#define OMAP24XX_RST2_DSP_MASK				(1 << 1)
-#define OMAP24XX_RST1_DSP_MASK				(1 << 0)
-
-/* RM_RSTST_DSP specific bits */
-/* 2430 calls GLOBALWMPU_RST "GLOBALWARM_RST" */
-#define OMAP2420_IVA_SW_RST_MASK			(1 << 8)
-#define OMAP24XX_DSP_SW_RST2_MASK			(1 << 5)
-#define OMAP24XX_DSP_SW_RST1_MASK			(1 << 4)
-
-/* PM_WKDEP_DSP specific bits */
-
-/* PM_PWSTCTRL_DSP specific bits */
-/* 2430 only: MEMONSTATE, MEMRETSTATE */
-#define OMAP2420_MEMIONSTATE_SHIFT			12
-#define OMAP2420_MEMIONSTATE_MASK			(0x3 << 12)
-#define OMAP2420_MEMIRETSTATE_MASK			(1 << 4)
-
-/* PM_PWSTST_DSP specific bits */
-/* MEMSTATEST is 2430 only */
-#define OMAP2420_MEMISTATEST_SHIFT			12
-#define OMAP2420_MEMISTATEST_MASK			(0x3 << 12)
-
-/* PRCM_IRQSTATUS_DSP specific bits */
-
-/* PRCM_IRQENABLE_DSP specific bits */
-
-/* RM_RSTCTRL_MDM */
-/* 2430 only */
-#define OMAP2430_PWRON1_MDM_MASK			(1 << 1)
-#define OMAP2430_RST1_MDM_MASK				(1 << 0)
-
-/* RM_RSTST_MDM specific bits */
-/* 2430 only */
-#define OMAP2430_MDM_SECU_VIOL_MASK			(1 << 6)
-#define OMAP2430_MDM_SW_PWRON1_MASK			(1 << 5)
-#define OMAP2430_MDM_SW_RST1_MASK			(1 << 4)
-
-/* PM_WKEN_MDM */
-/* 2430 only */
-#define OMAP2430_PM_WKEN_MDM_EN_MDM_MASK		(1 << 0)
-
-/* PM_WKST_MDM specific bits */
-/* 2430 only */
-
-/* PM_WKDEP_MDM specific bits */
-/* 2430 only */
-
-/* PM_PWSTCTRL_MDM specific bits */
-/* 2430 only */
-#define OMAP2430_KILLDOMAINWKUP_MASK			(1 << 19)
-
-/* PM_PWSTST_MDM specific bits */
-/* 2430 only */
-
-/* PRCM_IRQSTATUS_IVA */
-/* 2420 only */
-
-/* PRCM_IRQENABLE_IVA */
-/* 2420 only */
-
 #endif
-- 
1.7.9.5



From rnayak at ti.com  Fri Jul  5 06:32:35 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 5 Jul 2013 16:02:35 +0530
Subject: [PATCH 2/4] ARM: OMAP3: PRM/CM: Cleanup unused header
In-Reply-To: <1373020357-13528-1-git-send-email-rnayak@ti.com>
References: <1373020357-13528-1-git-send-email-rnayak@ti.com>
Message-ID: <1373020357-13528-3-git-send-email-rnayak@ti.com>

Cleanup unused parts of the PRM and CM regbit headers leaving only whats
used.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/cm-regbits-33xx.h  |  749 --------------------------------
 arch/arm/mach-omap2/cm-regbits-34xx.h  |  632 ---------------------------
 arch/arm/mach-omap2/prm-regbits-33xx.h |  306 -------------
 arch/arm/mach-omap2/prm-regbits-34xx.h |  481 --------------------
 4 files changed, 2168 deletions(-)

diff --git a/arch/arm/mach-omap2/cm-regbits-33xx.h b/arch/arm/mach-omap2/cm-regbits-33xx.h
index adf7bb7..c0823fd 100644
--- a/arch/arm/mach-omap2/cm-regbits-33xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-33xx.h
@@ -20,798 +20,49 @@
 #ifndef __ARCH_ARM_MACH_OMAP2_CM_REGBITS_33XX_H
 #define __ARCH_ARM_MACH_OMAP2_CM_REGBITS_33XX_H
 
-/*
- * Used by CM_AUTOIDLE_DPLL_CORE, CM_AUTOIDLE_DPLL_DDR, CM_AUTOIDLE_DPLL_DISP,
- * CM_AUTOIDLE_DPLL_MPU, CM_AUTOIDLE_DPLL_PER
- */
-#define AM33XX_AUTO_DPLL_MODE_SHIFT			0
-#define AM33XX_AUTO_DPLL_MODE_WIDTH			3
-#define AM33XX_AUTO_DPLL_MODE_MASK			(0x7 << 0)
-
-/* Used by CM_WKUP_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_ADC_FCLK_SHIFT		14
-#define AM33XX_CLKACTIVITY_ADC_FCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_ADC_FCLK_MASK		(1 << 16)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_CAN_CLK_SHIFT		11
-#define AM33XX_CLKACTIVITY_CAN_CLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_CAN_CLK_MASK			(1 << 11)
-
-/* Used by CM_PER_CLK_24MHZ_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_CLK_24MHZ_GCLK_SHIFT		4
-#define AM33XX_CLKACTIVITY_CLK_24MHZ_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_CLK_24MHZ_GCLK_MASK		(1 << 4)
-
-/* Used by CM_PER_CPSW_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_CPSW_125MHZ_GCLK_SHIFT	4
-#define AM33XX_CLKACTIVITY_CPSW_125MHZ_GCLK_WIDTH	1
-#define AM33XX_CLKACTIVITY_CPSW_125MHZ_GCLK_MASK	(1 << 4)
-
-/* Used by CM_PER_L4HS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_CPSW_250MHZ_GCLK_SHIFT	4
-#define AM33XX_CLKACTIVITY_CPSW_250MHZ_GCLK_WIDTH	1
-#define AM33XX_CLKACTIVITY_CPSW_250MHZ_GCLK_MASK	(1 << 4)
-
-/* Used by CM_PER_L4HS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_CPSW_50MHZ_GCLK_SHIFT	5
-#define AM33XX_CLKACTIVITY_CPSW_50MHZ_GCLK_WIDTH	1
-#define AM33XX_CLKACTIVITY_CPSW_50MHZ_GCLK_MASK		(1 << 5)
-
-/* Used by CM_PER_L4HS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_CPSW_5MHZ_GCLK_SHIFT		6
-#define AM33XX_CLKACTIVITY_CPSW_5MHZ_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_CPSW_5MHZ_GCLK_MASK		(1 << 6)
-
-/* Used by CM_PER_L3_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_CPTS_RFT_GCLK_SHIFT		6
-#define AM33XX_CLKACTIVITY_CPTS_RFT_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_CPTS_RFT_GCLK_MASK		(1 << 6)
-
-/* Used by CM_CEFUSE_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_CUST_EFUSE_SYS_CLK_SHIFT	9
-#define AM33XX_CLKACTIVITY_CUST_EFUSE_SYS_CLK_WIDTH	1
-#define AM33XX_CLKACTIVITY_CUST_EFUSE_SYS_CLK_MASK	(1 << 9)
-
-/* Used by CM_L3_AON_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_DBGSYSCLK_SHIFT		2
-#define AM33XX_CLKACTIVITY_DBGSYSCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_DBGSYSCLK_MASK		(1 << 2)
-
-/* Used by CM_L3_AON_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_DEBUG_CLKA_SHIFT		4
-#define AM33XX_CLKACTIVITY_DEBUG_CLKA_WIDTH		1
-#define AM33XX_CLKACTIVITY_DEBUG_CLKA_MASK		(1 << 4)
-
-/* Used by CM_PER_L3_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_EMIF_GCLK_SHIFT		2
-#define AM33XX_CLKACTIVITY_EMIF_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_EMIF_GCLK_MASK		(1 << 2)
-
-/* Used by CM_GFX_L3_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_GFX_FCLK_SHIFT		9
-#define AM33XX_CLKACTIVITY_GFX_FCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_GFX_FCLK_MASK		(1 << 9)
-
-/* Used by CM_GFX_L3_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_GFX_L3_GCLK_SHIFT		8
-#define AM33XX_CLKACTIVITY_GFX_L3_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_GFX_L3_GCLK_MASK		(1 << 8)
-
-/* Used by CM_WKUP_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_GPIO0_GDBCLK_SHIFT		8
-#define AM33XX_CLKACTIVITY_GPIO0_GDBCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_GPIO0_GDBCLK_MASK		(1 << 8)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_GPIO_1_GDBCLK_SHIFT		19
-#define AM33XX_CLKACTIVITY_GPIO_1_GDBCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_GPIO_1_GDBCLK_MASK		(1 << 19)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_GPIO_2_GDBCLK_SHIFT		20
-#define AM33XX_CLKACTIVITY_GPIO_2_GDBCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_GPIO_2_GDBCLK_MASK		(1 << 20)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_GPIO_3_GDBCLK_SHIFT		21
-#define AM33XX_CLKACTIVITY_GPIO_3_GDBCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_GPIO_3_GDBCLK_MASK		(1 << 21)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_GPIO_4_GDBCLK_SHIFT		22
-#define AM33XX_CLKACTIVITY_GPIO_4_GDBCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_GPIO_4_GDBCLK_MASK		(1 << 22)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_GPIO_5_GDBCLK_SHIFT		26
-#define AM33XX_CLKACTIVITY_GPIO_5_GDBCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_GPIO_5_GDBCLK_MASK		(1 << 26)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_GPIO_6_GDBCLK_SHIFT		18
-#define AM33XX_CLKACTIVITY_GPIO_6_GDBCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_GPIO_6_GDBCLK_MASK		(1 << 18)
-
-/* Used by CM_WKUP_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_I2C0_GFCLK_SHIFT		11
-#define AM33XX_CLKACTIVITY_I2C0_GFCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_I2C0_GFCLK_MASK		(1 << 11)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_I2C_FCLK_SHIFT		24
-#define AM33XX_CLKACTIVITY_I2C_FCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_I2C_FCLK_MASK		(1 << 24)
-
-/* Used by CM_PER_PRUSS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_PRUSS_IEP_GCLK_SHIFT		5
-#define AM33XX_CLKACTIVITY_PRUSS_IEP_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_PRUSS_IEP_GCLK_MASK		(1 << 5)
-
-/* Used by CM_PER_PRUSS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_PRUSS_OCP_GCLK_SHIFT		4
-#define AM33XX_CLKACTIVITY_PRUSS_OCP_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_PRUSS_OCP_GCLK_MASK		(1 << 4)
-
-/* Used by CM_PER_PRUSS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_PRUSS_UART_GCLK_SHIFT	6
-#define AM33XX_CLKACTIVITY_PRUSS_UART_GCLK_WIDTH	1
-#define AM33XX_CLKACTIVITY_PRUSS_UART_GCLK_MASK		(1 << 6)
-
-/* Used by CM_PER_L3S_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_L3S_GCLK_SHIFT		3
-#define AM33XX_CLKACTIVITY_L3S_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_L3S_GCLK_MASK		(1 << 3)
-
-/* Used by CM_L3_AON_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_L3_AON_GCLK_SHIFT		3
-#define AM33XX_CLKACTIVITY_L3_AON_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_L3_AON_GCLK_MASK		(1 << 3)
-
-/* Used by CM_PER_L3_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_L3_GCLK_SHIFT		4
-#define AM33XX_CLKACTIVITY_L3_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_L3_GCLK_MASK			(1 << 4)
-
-/* Used by CM_PER_L4FW_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_L4FW_GCLK_SHIFT		8
-#define AM33XX_CLKACTIVITY_L4FW_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_L4FW_GCLK_MASK		(1 << 8)
-
-/* Used by CM_PER_L4HS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_L4HS_GCLK_SHIFT		3
-#define AM33XX_CLKACTIVITY_L4HS_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_L4HS_GCLK_MASK		(1 << 3)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_L4LS_GCLK_SHIFT		8
-#define AM33XX_CLKACTIVITY_L4LS_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_L4LS_GCLK_MASK		(1 << 8)
-
-/* Used by CM_GFX_L4LS_GFX_CLKSTCTRL__1 */
-#define AM33XX_CLKACTIVITY_L4LS_GFX_GCLK_SHIFT		8
-#define AM33XX_CLKACTIVITY_L4LS_GFX_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_L4LS_GFX_GCLK_MASK		(1 << 8)
-
-/* Used by CM_CEFUSE_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_L4_CEFUSE_GICLK_SHIFT	8
-#define AM33XX_CLKACTIVITY_L4_CEFUSE_GICLK_WIDTH	1
-#define AM33XX_CLKACTIVITY_L4_CEFUSE_GICLK_MASK		(1 << 8)
-
-/* Used by CM_RTC_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_L4_RTC_GCLK_SHIFT		8
-#define AM33XX_CLKACTIVITY_L4_RTC_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_L4_RTC_GCLK_MASK		(1 << 8)
-
-/* Used by CM_L4_WKUP_AON_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_L4_WKUP_AON_GCLK_SHIFT	2
-#define AM33XX_CLKACTIVITY_L4_WKUP_AON_GCLK_WIDTH	1
-#define AM33XX_CLKACTIVITY_L4_WKUP_AON_GCLK_MASK	(1 << 2)
-
-/* Used by CM_WKUP_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_L4_WKUP_GCLK_SHIFT		2
-#define AM33XX_CLKACTIVITY_L4_WKUP_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_L4_WKUP_GCLK_MASK		(1 << 2)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_LCDC_GCLK_SHIFT		17
-#define AM33XX_CLKACTIVITY_LCDC_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_LCDC_GCLK_MASK		(1 << 17)
-
-/* Used by CM_PER_LCDC_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_LCDC_L3_OCP_GCLK_SHIFT	4
-#define AM33XX_CLKACTIVITY_LCDC_L3_OCP_GCLK_WIDTH	1
-#define AM33XX_CLKACTIVITY_LCDC_L3_OCP_GCLK_MASK	(1 << 4)
-
-/* Used by CM_PER_LCDC_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_LCDC_L4_OCP_GCLK_SHIFT	5
-#define AM33XX_CLKACTIVITY_LCDC_L4_OCP_GCLK_WIDTH	1
-#define AM33XX_CLKACTIVITY_LCDC_L4_OCP_GCLK_MASK	(1 << 5)
-
-/* Used by CM_PER_L3_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_MCASP_GCLK_SHIFT		7
-#define AM33XX_CLKACTIVITY_MCASP_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_MCASP_GCLK_MASK		(1 << 7)
-
-/* Used by CM_PER_L3_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_MMC_FCLK_SHIFT		3
-#define AM33XX_CLKACTIVITY_MMC_FCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_MMC_FCLK_MASK		(1 << 3)
-
-/* Used by CM_MPU_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_MPU_CLK_SHIFT		2
-#define AM33XX_CLKACTIVITY_MPU_CLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_MPU_CLK_MASK			(1 << 2)
-
-/* Used by CM_PER_OCPWP_L3_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_OCPWP_L3_GCLK_SHIFT		4
-#define AM33XX_CLKACTIVITY_OCPWP_L3_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_OCPWP_L3_GCLK_MASK		(1 << 4)
-
-/* Used by CM_PER_OCPWP_L3_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_OCPWP_L4_GCLK_SHIFT		5
-#define AM33XX_CLKACTIVITY_OCPWP_L4_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_OCPWP_L4_GCLK_MASK		(1 << 5)
-
-/* Used by CM_RTC_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_RTC_32KCLK_SHIFT		9
-#define AM33XX_CLKACTIVITY_RTC_32KCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_RTC_32KCLK_MASK		(1 << 9)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_SPI_GCLK_SHIFT		25
-#define AM33XX_CLKACTIVITY_SPI_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_SPI_GCLK_MASK		(1 << 25)
-
-/* Used by CM_WKUP_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_SR_SYSCLK_SHIFT		3
-#define AM33XX_CLKACTIVITY_SR_SYSCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_SR_SYSCLK_MASK		(1 << 3)
-
-/* Used by CM_WKUP_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_TIMER0_GCLK_SHIFT		10
-#define AM33XX_CLKACTIVITY_TIMER0_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_TIMER0_GCLK_MASK		(1 << 10)
-
-/* Used by CM_WKUP_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_TIMER1_GCLK_SHIFT		13
-#define AM33XX_CLKACTIVITY_TIMER1_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_TIMER1_GCLK_MASK		(1 << 13)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_TIMER2_GCLK_SHIFT		14
-#define AM33XX_CLKACTIVITY_TIMER2_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_TIMER2_GCLK_MASK		(1 << 14)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_TIMER3_GCLK_SHIFT		15
-#define AM33XX_CLKACTIVITY_TIMER3_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_TIMER3_GCLK_MASK		(1 << 15)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_TIMER4_GCLK_SHIFT		16
-#define AM33XX_CLKACTIVITY_TIMER4_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_TIMER4_GCLK_MASK		(1 << 16)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_TIMER5_GCLK_SHIFT		27
-#define AM33XX_CLKACTIVITY_TIMER5_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_TIMER5_GCLK_MASK		(1 << 27)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_TIMER6_GCLK_SHIFT		28
-#define AM33XX_CLKACTIVITY_TIMER6_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_TIMER6_GCLK_MASK		(1 << 28)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_TIMER7_GCLK_SHIFT		13
-#define AM33XX_CLKACTIVITY_TIMER7_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_TIMER7_GCLK_MASK		(1 << 13)
-
-/* Used by CM_WKUP_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_UART0_GFCLK_SHIFT		12
-#define AM33XX_CLKACTIVITY_UART0_GFCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_UART0_GFCLK_MASK		(1 << 12)
-
-/* Used by CM_PER_L4LS_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_UART_GFCLK_SHIFT		10
-#define AM33XX_CLKACTIVITY_UART_GFCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_UART_GFCLK_MASK		(1 << 10)
-
-/* Used by CM_WKUP_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_WDT0_GCLK_SHIFT		9
-#define AM33XX_CLKACTIVITY_WDT0_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_WDT0_GCLK_MASK		(1 << 9)
-
-/* Used by CM_WKUP_CLKSTCTRL */
-#define AM33XX_CLKACTIVITY_WDT1_GCLK_SHIFT		4
-#define AM33XX_CLKACTIVITY_WDT1_GCLK_WIDTH		1
-#define AM33XX_CLKACTIVITY_WDT1_GCLK_MASK		(1 << 4)
-
-/* Used by CLKSEL_GFX_FCLK */
-#define AM33XX_CLKDIV_SEL_GFX_FCLK_SHIFT		0
-#define AM33XX_CLKDIV_SEL_GFX_FCLK_WIDTH		1
-#define AM33XX_CLKDIV_SEL_GFX_FCLK_MASK			(1 << 0)
-
-/* Used by CM_CLKOUT_CTRL */
 #define AM33XX_CLKOUT2DIV_SHIFT				3
 #define AM33XX_CLKOUT2DIV_WIDTH				3
-#define AM33XX_CLKOUT2DIV_MASK				(0x7 << 3)
-
-/* Used by CM_CLKOUT_CTRL */
 #define AM33XX_CLKOUT2EN_SHIFT				7
-#define AM33XX_CLKOUT2EN_WIDTH				1
-#define AM33XX_CLKOUT2EN_MASK				(1 << 7)
-
-/* Used by CM_CLKOUT_CTRL */
-#define AM33XX_CLKOUT2SOURCE_SHIFT			0
-#define AM33XX_CLKOUT2SOURCE_WIDTH			3
 #define AM33XX_CLKOUT2SOURCE_MASK			(0x7 << 0)
-
-/*
- * Used by CLKSEL_GPIO0_DBCLK, CLKSEL_LCDC_PIXEL_CLK, CLKSEL_TIMER2_CLK,
- * CLKSEL_TIMER3_CLK, CLKSEL_TIMER4_CLK, CLKSEL_TIMER5_CLK, CLKSEL_TIMER6_CLK,
- * CLKSEL_TIMER7_CLK
- */
-#define AM33XX_CLKSEL_SHIFT				0
-#define AM33XX_CLKSEL_WIDTH				1
-#define AM33XX_CLKSEL_MASK				(0x01 << 0)
-
-/*
- * Renamed from CLKSEL Used by CLKSEL_PRUSS_OCP_CLK, CLKSEL_WDT1_CLK,
- * CM_CPTS_RFT_CLKSEL
- */
 #define AM33XX_CLKSEL_0_0_SHIFT				0
 #define AM33XX_CLKSEL_0_0_WIDTH				1
 #define AM33XX_CLKSEL_0_0_MASK				(1 << 0)
-
-#define AM33XX_CLKSEL_0_1_SHIFT				0
-#define AM33XX_CLKSEL_0_1_WIDTH				2
 #define AM33XX_CLKSEL_0_1_MASK				(3 << 0)
-
-/* Renamed from CLKSEL Used by CLKSEL_TIMER1MS_CLK */
-#define AM33XX_CLKSEL_0_2_SHIFT				0
-#define AM33XX_CLKSEL_0_2_WIDTH				3
 #define AM33XX_CLKSEL_0_2_MASK				(7 << 0)
-
-/* Used by CLKSEL_GFX_FCLK */
-#define AM33XX_CLKSEL_GFX_FCLK_SHIFT			1
-#define AM33XX_CLKSEL_GFX_FCLK_WIDTH			1
 #define AM33XX_CLKSEL_GFX_FCLK_MASK			(1 << 1)
-
-/*
- * Used by CM_MPU_CLKSTCTRL, CM_RTC_CLKSTCTRL, CM_PER_CLK_24MHZ_CLKSTCTRL,
- * CM_PER_CPSW_CLKSTCTRL, CM_PER_PRUSS_CLKSTCTRL, CM_PER_L3S_CLKSTCTRL,
- * CM_PER_L3_CLKSTCTRL, CM_PER_L4FW_CLKSTCTRL, CM_PER_L4HS_CLKSTCTRL,
- * CM_PER_L4LS_CLKSTCTRL, CM_PER_LCDC_CLKSTCTRL, CM_PER_OCPWP_L3_CLKSTCTRL,
- * CM_L3_AON_CLKSTCTRL, CM_L4_WKUP_AON_CLKSTCTRL, CM_WKUP_CLKSTCTRL,
- * CM_GFX_L3_CLKSTCTRL, CM_GFX_L4LS_GFX_CLKSTCTRL__1, CM_CEFUSE_CLKSTCTRL
- */
 #define AM33XX_CLKTRCTRL_SHIFT				0
-#define AM33XX_CLKTRCTRL_WIDTH				2
 #define AM33XX_CLKTRCTRL_MASK				(0x3 << 0)
-
-/*
- * Used by CM_SSC_DELTAMSTEP_DPLL_CORE, CM_SSC_DELTAMSTEP_DPLL_DDR,
- * CM_SSC_DELTAMSTEP_DPLL_DISP, CM_SSC_DELTAMSTEP_DPLL_MPU,
- * CM_SSC_DELTAMSTEP_DPLL_PER
- */
-#define AM33XX_DELTAMSTEP_SHIFT				0
-#define AM33XX_DELTAMSTEP_WIDTH				20
-#define AM33XX_DELTAMSTEP_MASK				(0xfffff << 0)
-
-/* Used by CM_CLKSEL_DPLL_DDR, CM_CLKSEL_DPLL_DISP, CM_CLKSEL_DPLL_MPU */
-#define AM33XX_DPLL_BYP_CLKSEL_SHIFT			23
-#define AM33XX_DPLL_BYP_CLKSEL_WIDTH			1
-#define AM33XX_DPLL_BYP_CLKSEL_MASK			(1 << 23)
-
-/* Used by CM_CLKDCOLDO_DPLL_PER */
-#define AM33XX_DPLL_CLKDCOLDO_GATE_CTRL_SHIFT		8
-#define AM33XX_DPLL_CLKDCOLDO_GATE_CTRL_WIDTH		1
-#define AM33XX_DPLL_CLKDCOLDO_GATE_CTRL_MASK		(1 << 8)
-
-/* Used by CM_CLKDCOLDO_DPLL_PER */
-#define AM33XX_DPLL_CLKDCOLDO_PWDN_SHIFT		12
-#define AM33XX_DPLL_CLKDCOLDO_PWDN_WIDTH		1
-#define AM33XX_DPLL_CLKDCOLDO_PWDN_MASK			(1 << 12)
-
-/* Used by CM_DIV_M2_DPLL_DDR, CM_DIV_M2_DPLL_DISP, CM_DIV_M2_DPLL_MPU */
 #define AM33XX_DPLL_CLKOUT_DIV_SHIFT			0
 #define AM33XX_DPLL_CLKOUT_DIV_WIDTH			5
-#define AM33XX_DPLL_CLKOUT_DIV_MASK			(0x1f << 0)
-
-/* Renamed from DPLL_CLKOUT_DIV Used by CM_DIV_M2_DPLL_PER */
-#define AM33XX_DPLL_CLKOUT_DIV_0_6_SHIFT		0
-#define AM33XX_DPLL_CLKOUT_DIV_0_6_WIDTH		7
-#define AM33XX_DPLL_CLKOUT_DIV_0_6_MASK			(0x7f << 0)
-
-/* Used by CM_DIV_M2_DPLL_DDR, CM_DIV_M2_DPLL_DISP, CM_DIV_M2_DPLL_MPU */
-#define AM33XX_DPLL_CLKOUT_DIVCHACK_SHIFT		5
-#define AM33XX_DPLL_CLKOUT_DIVCHACK_WIDTH		1
-#define AM33XX_DPLL_CLKOUT_DIVCHACK_MASK		(1 << 5)
-
-/* Renamed from DPLL_CLKOUT_DIVCHACK Used by CM_DIV_M2_DPLL_PER */
-#define AM33XX_DPLL_CLKOUT_DIVCHACK_M2_PER_SHIFT	7
-#define AM33XX_DPLL_CLKOUT_DIVCHACK_M2_PER_WIDTH	1
-#define AM33XX_DPLL_CLKOUT_DIVCHACK_M2_PER_MASK		(1 << 7)
-
-/*
- * Used by CM_DIV_M2_DPLL_DDR, CM_DIV_M2_DPLL_DISP, CM_DIV_M2_DPLL_MPU,
- * CM_DIV_M2_DPLL_PER
- */
-#define AM33XX_DPLL_CLKOUT_GATE_CTRL_SHIFT		8
-#define AM33XX_DPLL_CLKOUT_GATE_CTRL_WIDTH		1
-#define AM33XX_DPLL_CLKOUT_GATE_CTRL_MASK		(1 << 8)
-
-/*
- * Used by CM_CLKSEL_DPLL_CORE, CM_CLKSEL_DPLL_DDR, CM_CLKSEL_DPLL_DISP,
- * CM_CLKSEL_DPLL_MPU
- */
-#define AM33XX_DPLL_DIV_SHIFT				0
-#define AM33XX_DPLL_DIV_WIDTH				7
 #define AM33XX_DPLL_DIV_MASK				(0x7f << 0)
-
 #define AM33XX_DPLL_PER_DIV_MASK			(0xff << 0)
-
-/* Renamed from DPLL_DIV Used by CM_CLKSEL_DPLL_PERIPH */
-#define AM33XX_DPLL_DIV_0_7_SHIFT			0
-#define AM33XX_DPLL_DIV_0_7_WIDTH			8
-#define AM33XX_DPLL_DIV_0_7_MASK			(0xff << 0)
-
-/*
- * Used by CM_CLKMODE_DPLL_CORE, CM_CLKMODE_DPLL_DDR, CM_CLKMODE_DPLL_DISP,
- * CM_CLKMODE_DPLL_MPU
- */
-#define AM33XX_DPLL_DRIFTGUARD_EN_SHIFT			8
-#define AM33XX_DPLL_DRIFTGUARD_EN_WIDTH			1
-#define AM33XX_DPLL_DRIFTGUARD_EN_MASK			(1 << 8)
-
-/*
- * Used by CM_CLKMODE_DPLL_CORE, CM_CLKMODE_DPLL_DDR, CM_CLKMODE_DPLL_DISP,
- * CM_CLKMODE_DPLL_MPU, CM_CLKMODE_DPLL_PER
- */
-#define AM33XX_DPLL_EN_SHIFT				0
-#define AM33XX_DPLL_EN_WIDTH				3
 #define AM33XX_DPLL_EN_MASK				(0x7 << 0)
-
-/*
- * Used by CM_CLKMODE_DPLL_CORE, CM_CLKMODE_DPLL_DDR, CM_CLKMODE_DPLL_DISP,
- * CM_CLKMODE_DPLL_MPU
- */
-#define AM33XX_DPLL_LPMODE_EN_SHIFT			10
-#define AM33XX_DPLL_LPMODE_EN_WIDTH			1
-#define AM33XX_DPLL_LPMODE_EN_MASK			(1 << 10)
-
-/*
- * Used by CM_CLKSEL_DPLL_CORE, CM_CLKSEL_DPLL_DDR, CM_CLKSEL_DPLL_DISP,
- * CM_CLKSEL_DPLL_MPU
- */
-#define AM33XX_DPLL_MULT_SHIFT				8
-#define AM33XX_DPLL_MULT_WIDTH				11
 #define AM33XX_DPLL_MULT_MASK				(0x7ff << 8)
-
-/* Renamed from DPLL_MULT Used by CM_CLKSEL_DPLL_PERIPH */
-#define AM33XX_DPLL_MULT_PERIPH_SHIFT			8
-#define AM33XX_DPLL_MULT_PERIPH_WIDTH			12
 #define AM33XX_DPLL_MULT_PERIPH_MASK			(0xfff << 8)
-
-/*
- * Used by CM_CLKMODE_DPLL_CORE, CM_CLKMODE_DPLL_DDR, CM_CLKMODE_DPLL_DISP,
- * CM_CLKMODE_DPLL_MPU
- */
-#define AM33XX_DPLL_REGM4XEN_SHIFT			11
-#define AM33XX_DPLL_REGM4XEN_WIDTH			1
-#define AM33XX_DPLL_REGM4XEN_MASK			(1 << 11)
-
-/* Used by CM_CLKSEL_DPLL_PERIPH */
-#define AM33XX_DPLL_SD_DIV_SHIFT			24
-#define AM33XX_DPLL_SD_DIV_WIDTH			8
-#define AM33XX_DPLL_SD_DIV_MASK				(0xff << 24)
-
-/*
- * Used by CM_CLKMODE_DPLL_CORE, CM_CLKMODE_DPLL_DDR, CM_CLKMODE_DPLL_DISP,
- * CM_CLKMODE_DPLL_MPU, CM_CLKMODE_DPLL_PER
- */
-#define AM33XX_DPLL_SSC_ACK_SHIFT			13
-#define AM33XX_DPLL_SSC_ACK_WIDTH			1
-#define AM33XX_DPLL_SSC_ACK_MASK			(1 << 13)
-
-/*
- * Used by CM_CLKMODE_DPLL_CORE, CM_CLKMODE_DPLL_DDR, CM_CLKMODE_DPLL_DISP,
- * CM_CLKMODE_DPLL_MPU, CM_CLKMODE_DPLL_PER
- */
-#define AM33XX_DPLL_SSC_DOWNSPREAD_SHIFT		14
-#define AM33XX_DPLL_SSC_DOWNSPREAD_WIDTH		1
-#define AM33XX_DPLL_SSC_DOWNSPREAD_MASK			(1 << 14)
-
-/*
- * Used by CM_CLKMODE_DPLL_CORE, CM_CLKMODE_DPLL_DDR, CM_CLKMODE_DPLL_DISP,
- * CM_CLKMODE_DPLL_MPU, CM_CLKMODE_DPLL_PER
- */
-#define AM33XX_DPLL_SSC_EN_SHIFT			12
-#define AM33XX_DPLL_SSC_EN_WIDTH			1
-#define AM33XX_DPLL_SSC_EN_MASK				(1 << 12)
-
-/* Used by CM_DIV_M4_DPLL_CORE */
 #define AM33XX_HSDIVIDER_CLKOUT1_DIV_SHIFT		0
 #define AM33XX_HSDIVIDER_CLKOUT1_DIV_WIDTH		5
-#define AM33XX_HSDIVIDER_CLKOUT1_DIV_MASK		(0x1f << 0)
-
-/* Used by CM_DIV_M4_DPLL_CORE */
-#define AM33XX_HSDIVIDER_CLKOUT1_DIVCHACK_SHIFT		5
-#define AM33XX_HSDIVIDER_CLKOUT1_DIVCHACK_WIDTH		1
-#define AM33XX_HSDIVIDER_CLKOUT1_DIVCHACK_MASK		(1 << 5)
-
-/* Used by CM_DIV_M4_DPLL_CORE */
-#define AM33XX_HSDIVIDER_CLKOUT1_GATE_CTRL_SHIFT	8
-#define AM33XX_HSDIVIDER_CLKOUT1_GATE_CTRL_WIDTH	1
-#define AM33XX_HSDIVIDER_CLKOUT1_GATE_CTRL_MASK		(1 << 8)
-
-/* Used by CM_DIV_M4_DPLL_CORE */
-#define AM33XX_HSDIVIDER_CLKOUT1_PWDN_SHIFT		12
-#define AM33XX_HSDIVIDER_CLKOUT1_PWDN_WIDTH		1
-#define AM33XX_HSDIVIDER_CLKOUT1_PWDN_MASK		(1 << 12)
-
-/* Used by CM_DIV_M5_DPLL_CORE */
 #define AM33XX_HSDIVIDER_CLKOUT2_DIV_SHIFT		0
 #define AM33XX_HSDIVIDER_CLKOUT2_DIV_WIDTH		5
-#define AM33XX_HSDIVIDER_CLKOUT2_DIV_MASK		(0x1f << 0)
-
-/* Used by CM_DIV_M5_DPLL_CORE */
-#define AM33XX_HSDIVIDER_CLKOUT2_DIVCHACK_SHIFT		5
-#define AM33XX_HSDIVIDER_CLKOUT2_DIVCHACK_WIDTH		1
-#define AM33XX_HSDIVIDER_CLKOUT2_DIVCHACK_MASK		(1 << 5)
-
-/* Used by CM_DIV_M5_DPLL_CORE */
-#define AM33XX_HSDIVIDER_CLKOUT2_GATE_CTRL_SHIFT	8
-#define AM33XX_HSDIVIDER_CLKOUT2_GATE_CTRL_WIDTH	1
-#define AM33XX_HSDIVIDER_CLKOUT2_GATE_CTRL_MASK		(1 << 8)
-
-/* Used by CM_DIV_M5_DPLL_CORE */
-#define AM33XX_HSDIVIDER_CLKOUT2_PWDN_SHIFT		12
-#define AM33XX_HSDIVIDER_CLKOUT2_PWDN_WIDTH		1
-#define AM33XX_HSDIVIDER_CLKOUT2_PWDN_MASK		(1 << 12)
-
-/* Used by CM_DIV_M6_DPLL_CORE */
 #define AM33XX_HSDIVIDER_CLKOUT3_DIV_SHIFT		0
 #define AM33XX_HSDIVIDER_CLKOUT3_DIV_WIDTH		5
-#define AM33XX_HSDIVIDER_CLKOUT3_DIV_MASK		(0x1f << 0)
-
-/* Used by CM_DIV_M6_DPLL_CORE */
-#define AM33XX_HSDIVIDER_CLKOUT3_DIVCHACK_SHIFT		5
-#define AM33XX_HSDIVIDER_CLKOUT3_DIVCHACK_WIDTH		1
-#define AM33XX_HSDIVIDER_CLKOUT3_DIVCHACK_MASK		(1 << 5)
-
-/* Used by CM_DIV_M6_DPLL_CORE */
-#define AM33XX_HSDIVIDER_CLKOUT3_GATE_CTRL_SHIFT	8
-#define AM33XX_HSDIVIDER_CLKOUT3_GATE_CTRL_WIDTH	1
-#define AM33XX_HSDIVIDER_CLKOUT3_GATE_CTRL_MASK		(1 << 8)
-
-/* Used by CM_DIV_M6_DPLL_CORE */
-#define AM33XX_HSDIVIDER_CLKOUT3_PWDN_SHIFT		12
-#define AM33XX_HSDIVIDER_CLKOUT3_PWDN_WIDTH		1
-#define AM33XX_HSDIVIDER_CLKOUT3_PWDN_MASK		(1 << 12)
-
-/*
- * Used by CM_MPU_MPU_CLKCTRL, CM_RTC_RTC_CLKCTRL, CM_PER_AES0_CLKCTRL,
- * CM_PER_AES1_CLKCTRL, CM_PER_CLKDIV32K_CLKCTRL, CM_PER_CPGMAC0_CLKCTRL,
- * CM_PER_DCAN0_CLKCTRL, CM_PER_DCAN1_CLKCTRL, CM_PER_DES_CLKCTRL,
- * CM_PER_ELM_CLKCTRL, CM_PER_EMIF_CLKCTRL, CM_PER_EMIF_FW_CLKCTRL,
- * CM_PER_EPWMSS0_CLKCTRL, CM_PER_EPWMSS1_CLKCTRL, CM_PER_EPWMSS2_CLKCTRL,
- * CM_PER_GPIO1_CLKCTRL, CM_PER_GPIO2_CLKCTRL, CM_PER_GPIO3_CLKCTRL,
- * CM_PER_GPIO4_CLKCTRL, CM_PER_GPIO5_CLKCTRL, CM_PER_GPIO6_CLKCTRL,
- * CM_PER_GPMC_CLKCTRL, CM_PER_I2C1_CLKCTRL, CM_PER_I2C2_CLKCTRL,
- * CM_PER_PRUSS_CLKCTRL, CM_PER_IEEE5000_CLKCTRL, CM_PER_L3_CLKCTRL,
- * CM_PER_L3_INSTR_CLKCTRL, CM_PER_L4FW_CLKCTRL, CM_PER_L4HS_CLKCTRL,
- * CM_PER_L4LS_CLKCTRL, CM_PER_LCDC_CLKCTRL, CM_PER_MAILBOX0_CLKCTRL,
- * CM_PER_MAILBOX1_CLKCTRL, CM_PER_MCASP0_CLKCTRL, CM_PER_MCASP1_CLKCTRL,
- * CM_PER_MCASP2_CLKCTRL, CM_PER_MLB_CLKCTRL, CM_PER_MMC0_CLKCTRL,
- * CM_PER_MMC1_CLKCTRL, CM_PER_MMC2_CLKCTRL, CM_PER_MSTR_EXPS_CLKCTRL,
- * CM_PER_OCMCRAM_CLKCTRL, CM_PER_OCPWP_CLKCTRL, CM_PER_PCIE_CLKCTRL,
- * CM_PER_PKA_CLKCTRL, CM_PER_RNG_CLKCTRL, CM_PER_SHA0_CLKCTRL,
- * CM_PER_SLV_EXPS_CLKCTRL, CM_PER_SPARE0_CLKCTRL, CM_PER_SPARE1_CLKCTRL,
- * CM_PER_SPARE_CLKCTRL, CM_PER_SPI0_CLKCTRL, CM_PER_SPI1_CLKCTRL,
- * CM_PER_SPI2_CLKCTRL, CM_PER_SPI3_CLKCTRL, CM_PER_SPINLOCK_CLKCTRL,
- * CM_PER_TIMER2_CLKCTRL, CM_PER_TIMER3_CLKCTRL, CM_PER_TIMER4_CLKCTRL,
- * CM_PER_TIMER5_CLKCTRL, CM_PER_TIMER6_CLKCTRL, CM_PER_TIMER7_CLKCTRL,
- * CM_PER_TPCC_CLKCTRL, CM_PER_TPTC0_CLKCTRL, CM_PER_TPTC1_CLKCTRL,
- * CM_PER_TPTC2_CLKCTRL, CM_PER_UART1_CLKCTRL, CM_PER_UART2_CLKCTRL,
- * CM_PER_UART3_CLKCTRL, CM_PER_UART4_CLKCTRL, CM_PER_UART5_CLKCTRL,
- * CM_PER_USB0_CLKCTRL, CM_WKUP_ADC_TSC_CLKCTRL, CM_WKUP_CONTROL_CLKCTRL,
- * CM_WKUP_DEBUGSS_CLKCTRL, CM_WKUP_GPIO0_CLKCTRL, CM_WKUP_I2C0_CLKCTRL,
- * CM_WKUP_L4WKUP_CLKCTRL, CM_WKUP_SMARTREFLEX0_CLKCTRL,
- * CM_WKUP_SMARTREFLEX1_CLKCTRL, CM_WKUP_TIMER0_CLKCTRL,
- * CM_WKUP_TIMER1_CLKCTRL, CM_WKUP_UART0_CLKCTRL, CM_WKUP_WDT0_CLKCTRL,
- * CM_WKUP_WDT1_CLKCTRL, CM_GFX_BITBLT_CLKCTRL, CM_GFX_GFX_CLKCTRL,
- * CM_GFX_MMUCFG_CLKCTRL, CM_GFX_MMUDATA_CLKCTRL, CM_CEFUSE_CEFUSE_CLKCTRL
- */
 #define AM33XX_IDLEST_SHIFT				16
-#define AM33XX_IDLEST_WIDTH				2
 #define AM33XX_IDLEST_MASK				(0x3 << 16)
-
-/* Used by CM_MAC_CLKSEL */
-#define AM33XX_MII_CLK_SEL_SHIFT			2
-#define AM33XX_MII_CLK_SEL_WIDTH			1
-#define AM33XX_MII_CLK_SEL_MASK				(1 << 2)
-
-/*
- * Used by CM_SSC_MODFREQDIV_DPLL_CORE, CM_SSC_MODFREQDIV_DPLL_DDR,
- * CM_SSC_MODFREQDIV_DPLL_DISP, CM_SSC_MODFREQDIV_DPLL_MPU,
- * CM_SSC_MODFREQDIV_DPLL_PER
- */
-#define AM33XX_MODFREQDIV_EXPONENT_SHIFT		8
-#define AM33XX_MODFREQDIV_EXPONENT_WIDTH		3
-#define AM33XX_MODFREQDIV_EXPONENT_MASK			(0x7 << 8)
-
-/*
- * Used by CM_SSC_MODFREQDIV_DPLL_CORE, CM_SSC_MODFREQDIV_DPLL_DDR,
- * CM_SSC_MODFREQDIV_DPLL_DISP, CM_SSC_MODFREQDIV_DPLL_MPU,
- * CM_SSC_MODFREQDIV_DPLL_PER
- */
-#define AM33XX_MODFREQDIV_MANTISSA_SHIFT		0
-#define AM33XX_MODFREQDIV_MANTISSA_WIDTH		7
-#define AM33XX_MODFREQDIV_MANTISSA_MASK			(0x7f << 0)
-
-/*
- * Used by CM_MPU_MPU_CLKCTRL, CM_RTC_RTC_CLKCTRL, CM_PER_AES0_CLKCTRL,
- * CM_PER_AES1_CLKCTRL, CM_PER_CLKDIV32K_CLKCTRL, CM_PER_CPGMAC0_CLKCTRL,
- * CM_PER_DCAN0_CLKCTRL, CM_PER_DCAN1_CLKCTRL, CM_PER_DES_CLKCTRL,
- * CM_PER_ELM_CLKCTRL, CM_PER_EMIF_CLKCTRL, CM_PER_EMIF_FW_CLKCTRL,
- * CM_PER_EPWMSS0_CLKCTRL, CM_PER_EPWMSS1_CLKCTRL, CM_PER_EPWMSS2_CLKCTRL,
- * CM_PER_GPIO1_CLKCTRL, CM_PER_GPIO2_CLKCTRL, CM_PER_GPIO3_CLKCTRL,
- * CM_PER_GPIO4_CLKCTRL, CM_PER_GPIO5_CLKCTRL, CM_PER_GPIO6_CLKCTRL,
- * CM_PER_GPMC_CLKCTRL, CM_PER_I2C1_CLKCTRL, CM_PER_I2C2_CLKCTRL,
- * CM_PER_PRUSS_CLKCTRL, CM_PER_IEEE5000_CLKCTRL, CM_PER_L3_CLKCTRL,
- * CM_PER_L3_INSTR_CLKCTRL, CM_PER_L4FW_CLKCTRL, CM_PER_L4HS_CLKCTRL,
- * CM_PER_L4LS_CLKCTRL, CM_PER_LCDC_CLKCTRL, CM_PER_MAILBOX0_CLKCTRL,
- * CM_PER_MAILBOX1_CLKCTRL, CM_PER_MCASP0_CLKCTRL, CM_PER_MCASP1_CLKCTRL,
- * CM_PER_MCASP2_CLKCTRL, CM_PER_MLB_CLKCTRL, CM_PER_MMC0_CLKCTRL,
- * CM_PER_MMC1_CLKCTRL, CM_PER_MMC2_CLKCTRL, CM_PER_MSTR_EXPS_CLKCTRL,
- * CM_PER_OCMCRAM_CLKCTRL, CM_PER_OCPWP_CLKCTRL, CM_PER_PCIE_CLKCTRL,
- * CM_PER_PKA_CLKCTRL, CM_PER_RNG_CLKCTRL, CM_PER_SHA0_CLKCTRL,
- * CM_PER_SLV_EXPS_CLKCTRL, CM_PER_SPARE0_CLKCTRL, CM_PER_SPARE1_CLKCTRL,
- * CM_PER_SPARE_CLKCTRL, CM_PER_SPI0_CLKCTRL, CM_PER_SPI1_CLKCTRL,
- * CM_PER_SPI2_CLKCTRL, CM_PER_SPI3_CLKCTRL, CM_PER_SPINLOCK_CLKCTRL,
- * CM_PER_TIMER2_CLKCTRL, CM_PER_TIMER3_CLKCTRL, CM_PER_TIMER4_CLKCTRL,
- * CM_PER_TIMER5_CLKCTRL, CM_PER_TIMER6_CLKCTRL, CM_PER_TIMER7_CLKCTRL,
- * CM_PER_TPCC_CLKCTRL, CM_PER_TPTC0_CLKCTRL, CM_PER_TPTC1_CLKCTRL,
- * CM_PER_TPTC2_CLKCTRL, CM_PER_UART1_CLKCTRL, CM_PER_UART2_CLKCTRL,
- * CM_PER_UART3_CLKCTRL, CM_PER_UART4_CLKCTRL, CM_PER_UART5_CLKCTRL,
- * CM_PER_USB0_CLKCTRL, CM_WKUP_ADC_TSC_CLKCTRL, CM_WKUP_CONTROL_CLKCTRL,
- * CM_WKUP_DEBUGSS_CLKCTRL, CM_WKUP_GPIO0_CLKCTRL, CM_WKUP_I2C0_CLKCTRL,
- * CM_WKUP_L4WKUP_CLKCTRL, CM_WKUP_SMARTREFLEX0_CLKCTRL,
- * CM_WKUP_SMARTREFLEX1_CLKCTRL, CM_WKUP_TIMER0_CLKCTRL,
- * CM_WKUP_TIMER1_CLKCTRL, CM_WKUP_UART0_CLKCTRL, CM_WKUP_WDT0_CLKCTRL,
- * CM_WKUP_WDT1_CLKCTRL, CM_WKUP_WKUP_M3_CLKCTRL, CM_GFX_BITBLT_CLKCTRL,
- * CM_GFX_GFX_CLKCTRL, CM_GFX_MMUCFG_CLKCTRL, CM_GFX_MMUDATA_CLKCTRL,
- * CM_CEFUSE_CEFUSE_CLKCTRL
- */
 #define AM33XX_MODULEMODE_SHIFT				0
-#define AM33XX_MODULEMODE_WIDTH				2
 #define AM33XX_MODULEMODE_MASK				(0x3 << 0)
-
-/* Used by CM_WKUP_DEBUGSS_CLKCTRL */
 #define AM33XX_OPTCLK_DEBUG_CLKA_SHIFT			30
-#define AM33XX_OPTCLK_DEBUG_CLKA_WIDTH			1
-#define AM33XX_OPTCLK_DEBUG_CLKA_MASK			(1 << 30)
-
-/* Used by CM_WKUP_DEBUGSS_CLKCTRL */
 #define AM33XX_OPTFCLKEN_DBGSYSCLK_SHIFT		19
-#define AM33XX_OPTFCLKEN_DBGSYSCLK_WIDTH		1
-#define AM33XX_OPTFCLKEN_DBGSYSCLK_MASK			(1 << 19)
-
-/* Used by CM_WKUP_GPIO0_CLKCTRL */
 #define AM33XX_OPTFCLKEN_GPIO0_GDBCLK_SHIFT		18
-#define AM33XX_OPTFCLKEN_GPIO0_GDBCLK_WIDTH		1
-#define AM33XX_OPTFCLKEN_GPIO0_GDBCLK_MASK		(1 << 18)
-
-/* Used by CM_PER_GPIO1_CLKCTRL */
 #define AM33XX_OPTFCLKEN_GPIO_1_GDBCLK_SHIFT		18
-#define AM33XX_OPTFCLKEN_GPIO_1_GDBCLK_WIDTH		1
-#define AM33XX_OPTFCLKEN_GPIO_1_GDBCLK_MASK		(1 << 18)
-
-/* Used by CM_PER_GPIO2_CLKCTRL */
 #define AM33XX_OPTFCLKEN_GPIO_2_GDBCLK_SHIFT		18
-#define AM33XX_OPTFCLKEN_GPIO_2_GDBCLK_WIDTH		1
-#define AM33XX_OPTFCLKEN_GPIO_2_GDBCLK_MASK		(1 << 18)
-
-/* Used by CM_PER_GPIO3_CLKCTRL */
 #define AM33XX_OPTFCLKEN_GPIO_3_GDBCLK_SHIFT		18
-#define AM33XX_OPTFCLKEN_GPIO_3_GDBCLK_WIDTH		1
-#define AM33XX_OPTFCLKEN_GPIO_3_GDBCLK_MASK		(1 << 18)
-
-/* Used by CM_PER_GPIO4_CLKCTRL */
-#define AM33XX_OPTFCLKEN_GPIO_4_GDBCLK_SHIFT		18
-#define AM33XX_OPTFCLKEN_GPIO_4_GDBCLK_WIDTH		1
-#define AM33XX_OPTFCLKEN_GPIO_4_GDBCLK_MASK		(1 << 18)
-
-/* Used by CM_PER_GPIO5_CLKCTRL */
-#define AM33XX_OPTFCLKEN_GPIO_5_GDBCLK_SHIFT		18
-#define AM33XX_OPTFCLKEN_GPIO_5_GDBCLK_WIDTH		1
-#define AM33XX_OPTFCLKEN_GPIO_5_GDBCLK_MASK		(1 << 18)
-
-/* Used by CM_PER_GPIO6_CLKCTRL */
-#define AM33XX_OPTFCLKEN_GPIO_6_GDBCLK_SHIFT		18
-#define AM33XX_OPTFCLKEN_GPIO_6_GDBCLK_WIDTH		1
-#define AM33XX_OPTFCLKEN_GPIO_6_GDBCLK_MASK		(1 << 18)
-
-/*
- * Used by CM_MPU_MPU_CLKCTRL, CM_PER_CPGMAC0_CLKCTRL, CM_PER_PRUSS_CLKCTRL,
- * CM_PER_IEEE5000_CLKCTRL, CM_PER_LCDC_CLKCTRL, CM_PER_MLB_CLKCTRL,
- * CM_PER_MSTR_EXPS_CLKCTRL, CM_PER_OCPWP_CLKCTRL, CM_PER_PCIE_CLKCTRL,
- * CM_PER_SPARE_CLKCTRL, CM_PER_TPTC0_CLKCTRL, CM_PER_TPTC1_CLKCTRL,
- * CM_PER_TPTC2_CLKCTRL, CM_PER_USB0_CLKCTRL, CM_WKUP_DEBUGSS_CLKCTRL,
- * CM_WKUP_WKUP_M3_CLKCTRL, CM_GFX_BITBLT_CLKCTRL, CM_GFX_GFX_CLKCTRL
- */
-#define AM33XX_STBYST_SHIFT				18
-#define AM33XX_STBYST_WIDTH				1
-#define AM33XX_STBYST_MASK				(1 << 18)
-
-/* Used by CM_WKUP_DEBUGSS_CLKCTRL */
 #define AM33XX_STM_PMD_CLKDIVSEL_SHIFT			27
 #define AM33XX_STM_PMD_CLKDIVSEL_WIDTH			3
-#define AM33XX_STM_PMD_CLKDIVSEL_MASK			(0x7 << 27)
-
-/* Used by CM_WKUP_DEBUGSS_CLKCTRL */
 #define AM33XX_STM_PMD_CLKSEL_SHIFT			22
 #define AM33XX_STM_PMD_CLKSEL_WIDTH			2
-#define AM33XX_STM_PMD_CLKSEL_MASK			(0x3 << 22)
-
-/*
- * Used by CM_IDLEST_DPLL_CORE, CM_IDLEST_DPLL_DDR, CM_IDLEST_DPLL_DISP,
- * CM_IDLEST_DPLL_MPU, CM_IDLEST_DPLL_PER
- */
-#define AM33XX_ST_DPLL_CLK_SHIFT			0
-#define AM33XX_ST_DPLL_CLK_WIDTH			1
 #define AM33XX_ST_DPLL_CLK_MASK				(1 << 0)
-
-/* Used by CM_CLKDCOLDO_DPLL_PER */
 #define AM33XX_ST_DPLL_CLKDCOLDO_SHIFT			8
-#define AM33XX_ST_DPLL_CLKDCOLDO_WIDTH			1
-#define AM33XX_ST_DPLL_CLKDCOLDO_MASK			(1 << 8)
-
-/*
- * Used by CM_DIV_M2_DPLL_DDR, CM_DIV_M2_DPLL_DISP, CM_DIV_M2_DPLL_MPU,
- * CM_DIV_M2_DPLL_PER
- */
-#define AM33XX_ST_DPLL_CLKOUT_SHIFT			9
-#define AM33XX_ST_DPLL_CLKOUT_WIDTH			1
-#define AM33XX_ST_DPLL_CLKOUT_MASK			(1 << 9)
-
-/* Used by CM_DIV_M4_DPLL_CORE */
-#define AM33XX_ST_HSDIVIDER_CLKOUT1_SHIFT		9
-#define AM33XX_ST_HSDIVIDER_CLKOUT1_WIDTH		1
-#define AM33XX_ST_HSDIVIDER_CLKOUT1_MASK		(1 << 9)
-
-/* Used by CM_DIV_M5_DPLL_CORE */
-#define AM33XX_ST_HSDIVIDER_CLKOUT2_SHIFT		9
-#define AM33XX_ST_HSDIVIDER_CLKOUT2_WIDTH		1
-#define AM33XX_ST_HSDIVIDER_CLKOUT2_MASK		(1 << 9)
-
-/* Used by CM_DIV_M6_DPLL_CORE */
-#define AM33XX_ST_HSDIVIDER_CLKOUT3_SHIFT		9
-#define AM33XX_ST_HSDIVIDER_CLKOUT3_WIDTH		1
-#define AM33XX_ST_HSDIVIDER_CLKOUT3_MASK		(1 << 9)
-
-/*
- * Used by CM_IDLEST_DPLL_CORE, CM_IDLEST_DPLL_DDR, CM_IDLEST_DPLL_DISP,
- * CM_IDLEST_DPLL_MPU, CM_IDLEST_DPLL_PER
- */
-#define AM33XX_ST_MN_BYPASS_SHIFT			8
-#define AM33XX_ST_MN_BYPASS_WIDTH			1
-#define AM33XX_ST_MN_BYPASS_MASK			(1 << 8)
-
-/* Used by CM_WKUP_DEBUGSS_CLKCTRL */
 #define AM33XX_TRC_PMD_CLKDIVSEL_SHIFT			24
 #define AM33XX_TRC_PMD_CLKDIVSEL_WIDTH			3
-#define AM33XX_TRC_PMD_CLKDIVSEL_MASK			(0x7 << 24)
-
-/* Used by CM_WKUP_DEBUGSS_CLKCTRL */
 #define AM33XX_TRC_PMD_CLKSEL_SHIFT			20
 #define AM33XX_TRC_PMD_CLKSEL_WIDTH			2
-#define AM33XX_TRC_PMD_CLKSEL_MASK			(0x3 << 20)
-
-/* Used by CONTROL_SEC_CLK_CTRL */
-#define AM33XX_TIMER0_CLKSEL_WIDTH			2
-#define AM33XX_TIMER0_CLKSEL_MASK			(0x3 << 4)
 #endif
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach-omap2/cm-regbits-34xx.h
index adf78d3..04dab2f 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -14,833 +14,201 @@
  * published by the Free Software Foundation.
  */
 
-/* Bits shared between registers */
-
-/* CM_FCLKEN1_CORE and CM_ICLKEN1_CORE shared bits */
-#define OMAP3430ES2_EN_MMC3_MASK			(1 << 30)
 #define OMAP3430ES2_EN_MMC3_SHIFT			30
-#define OMAP3430_EN_MSPRO_MASK				(1 << 23)
 #define OMAP3430_EN_MSPRO_SHIFT				23
-#define OMAP3430_EN_HDQ_MASK				(1 << 22)
 #define OMAP3430_EN_HDQ_SHIFT				22
-#define OMAP3430ES1_EN_FSHOSTUSB_MASK			(1 << 5)
 #define OMAP3430ES1_EN_FSHOSTUSB_SHIFT			5
-#define OMAP3430ES1_EN_D2D_MASK				(1 << 3)
 #define OMAP3430ES1_EN_D2D_SHIFT			3
-#define OMAP3430_EN_SSI_MASK				(1 << 0)
 #define OMAP3430_EN_SSI_SHIFT				0
-
-/* CM_FCLKEN3_CORE and CM_ICLKEN3_CORE shared bits */
 #define OMAP3430ES2_EN_USBTLL_SHIFT			2
-#define OMAP3430ES2_EN_USBTLL_MASK			(1 << 2)
-
-/* CM_FCLKEN_WKUP and CM_ICLKEN_WKUP shared bits */
-#define OMAP3430_EN_WDT2_MASK				(1 << 5)
 #define OMAP3430_EN_WDT2_SHIFT				5
-
-/* CM_ICLKEN_CAM, CM_FCLKEN_CAM shared bits */
-#define OMAP3430_EN_CAM_MASK				(1 << 0)
 #define OMAP3430_EN_CAM_SHIFT				0
-
-/* CM_FCLKEN_PER, CM_ICLKEN_PER shared bits */
-#define OMAP3430_EN_WDT3_MASK				(1 << 12)
 #define OMAP3430_EN_WDT3_SHIFT				12
-
-/* CM_CLKSEL2_EMU, CM_CLKSEL3_EMU shared bits */
-#define OMAP3430_OVERRIDE_ENABLE_MASK			(1 << 19)
-
-
-/* Bits specific to each register */
-
-/* CM_FCLKEN_IVA2 */
 #define OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK		(1 << 0)
 #define OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_SHIFT		0
-
-/* CM_CLKEN_PLL_IVA2 */
-#define OMAP3430_IVA2_DPLL_RAMPTIME_SHIFT		8
-#define OMAP3430_IVA2_DPLL_RAMPTIME_MASK		(0x3 << 8)
-#define OMAP3430_IVA2_DPLL_FREQSEL_SHIFT		4
 #define OMAP3430_IVA2_DPLL_FREQSEL_MASK			(0xf << 4)
 #define OMAP3430_EN_IVA2_DPLL_DRIFTGUARD_SHIFT		3
-#define OMAP3430_EN_IVA2_DPLL_DRIFTGUARD_MASK		(1 << 3)
-#define OMAP3430_EN_IVA2_DPLL_SHIFT			0
 #define OMAP3430_EN_IVA2_DPLL_MASK			(0x7 << 0)
-
-/* CM_IDLEST_IVA2 */
 #define OMAP3430_ST_IVA2_SHIFT				0
-#define OMAP3430_ST_IVA2_MASK				(1 << 0)
-
-/* CM_IDLEST_PLL_IVA2 */
-#define OMAP3430_ST_IVA2_CLK_SHIFT			0
 #define OMAP3430_ST_IVA2_CLK_MASK			(1 << 0)
-
-/* CM_AUTOIDLE_PLL_IVA2 */
-#define OMAP3430_AUTO_IVA2_DPLL_SHIFT			0
 #define OMAP3430_AUTO_IVA2_DPLL_MASK			(0x7 << 0)
-
-/* CM_CLKSEL1_PLL_IVA2 */
 #define OMAP3430_IVA2_CLK_SRC_SHIFT			19
-#define OMAP3430_IVA2_CLK_SRC_MASK			(0x7 << 19)
 #define OMAP3430_IVA2_CLK_SRC_WIDTH			3
-#define OMAP3430_IVA2_DPLL_MULT_SHIFT			8
 #define OMAP3430_IVA2_DPLL_MULT_MASK			(0x7ff << 8)
-#define OMAP3430_IVA2_DPLL_DIV_SHIFT			0
 #define OMAP3430_IVA2_DPLL_DIV_MASK			(0x7f << 0)
-
-/* CM_CLKSEL2_PLL_IVA2 */
 #define OMAP3430_IVA2_DPLL_CLKOUT_DIV_SHIFT		0
-#define OMAP3430_IVA2_DPLL_CLKOUT_DIV_MASK		(0x1f << 0)
 #define OMAP3430_IVA2_DPLL_CLKOUT_DIV_WIDTH		5
-
-/* CM_CLKSTCTRL_IVA2 */
-#define OMAP3430_CLKTRCTRL_IVA2_SHIFT			0
 #define OMAP3430_CLKTRCTRL_IVA2_MASK			(0x3 << 0)
-
-/* CM_CLKSTST_IVA2 */
-#define OMAP3430_CLKACTIVITY_IVA2_SHIFT			0
 #define OMAP3430_CLKACTIVITY_IVA2_MASK			(1 << 0)
-
-/* CM_REVISION specific bits */
-
-/* CM_SYSCONFIG specific bits */
-
-/* CM_CLKEN_PLL_MPU */
-#define OMAP3430_MPU_DPLL_RAMPTIME_SHIFT		8
-#define OMAP3430_MPU_DPLL_RAMPTIME_MASK			(0x3 << 8)
-#define OMAP3430_MPU_DPLL_FREQSEL_SHIFT			4
 #define OMAP3430_MPU_DPLL_FREQSEL_MASK			(0xf << 4)
 #define OMAP3430_EN_MPU_DPLL_DRIFTGUARD_SHIFT		3
-#define OMAP3430_EN_MPU_DPLL_DRIFTGUARD_MASK		(1 << 3)
-#define OMAP3430_EN_MPU_DPLL_SHIFT			0
 #define OMAP3430_EN_MPU_DPLL_MASK			(0x7 << 0)
-
-/* CM_IDLEST_MPU */
-#define OMAP3430_ST_MPU_MASK				(1 << 0)
-
-/* CM_IDLEST_PLL_MPU */
 #define OMAP3430_ST_MPU_CLK_SHIFT			0
 #define OMAP3430_ST_MPU_CLK_MASK			(1 << 0)
 #define OMAP3430_ST_MPU_CLK_WIDTH			1
-
-/* CM_AUTOIDLE_PLL_MPU */
-#define OMAP3430_AUTO_MPU_DPLL_SHIFT			0
 #define OMAP3430_AUTO_MPU_DPLL_MASK			(0x7 << 0)
-
-/* CM_CLKSEL1_PLL_MPU */
 #define OMAP3430_MPU_CLK_SRC_SHIFT			19
-#define OMAP3430_MPU_CLK_SRC_MASK			(0x7 << 19)
 #define OMAP3430_MPU_CLK_SRC_WIDTH			3
-#define OMAP3430_MPU_DPLL_MULT_SHIFT			8
 #define OMAP3430_MPU_DPLL_MULT_MASK			(0x7ff << 8)
-#define OMAP3430_MPU_DPLL_DIV_SHIFT			0
 #define OMAP3430_MPU_DPLL_DIV_MASK			(0x7f << 0)
-
-/* CM_CLKSEL2_PLL_MPU */
 #define OMAP3430_MPU_DPLL_CLKOUT_DIV_SHIFT		0
-#define OMAP3430_MPU_DPLL_CLKOUT_DIV_MASK		(0x1f << 0)
 #define OMAP3430_MPU_DPLL_CLKOUT_DIV_WIDTH		5
-
-/* CM_CLKSTCTRL_MPU */
-#define OMAP3430_CLKTRCTRL_MPU_SHIFT			0
 #define OMAP3430_CLKTRCTRL_MPU_MASK			(0x3 << 0)
-
-/* CM_CLKSTST_MPU */
-#define OMAP3430_CLKACTIVITY_MPU_SHIFT			0
-#define OMAP3430_CLKACTIVITY_MPU_MASK			(1 << 0)
-
-/* CM_FCLKEN1_CORE specific bits */
-#define OMAP3430_EN_MODEM_MASK				(1 << 31)
 #define OMAP3430_EN_MODEM_SHIFT				31
-
-/* CM_ICLKEN1_CORE specific bits */
-#define OMAP3430_EN_ICR_MASK				(1 << 29)
 #define OMAP3430_EN_ICR_SHIFT				29
-#define OMAP3430_EN_AES2_MASK				(1 << 28)
 #define OMAP3430_EN_AES2_SHIFT				28
-#define OMAP3430_EN_SHA12_MASK				(1 << 27)
 #define OMAP3430_EN_SHA12_SHIFT				27
-#define OMAP3430_EN_DES2_MASK				(1 << 26)
 #define OMAP3430_EN_DES2_SHIFT				26
-#define OMAP3430ES1_EN_FAC_MASK				(1 << 8)
 #define OMAP3430ES1_EN_FAC_SHIFT			8
-#define OMAP3430_EN_MAILBOXES_MASK			(1 << 7)
 #define OMAP3430_EN_MAILBOXES_SHIFT			7
-#define OMAP3430_EN_OMAPCTRL_MASK			(1 << 6)
 #define OMAP3430_EN_OMAPCTRL_SHIFT			6
-#define OMAP3430_EN_SAD2D_MASK				(1 << 3)
 #define OMAP3430_EN_SAD2D_SHIFT				3
-#define OMAP3430_EN_SDRC_MASK				(1 << 1)
 #define OMAP3430_EN_SDRC_SHIFT				1
-
-/* AM35XX specific CM_ICLKEN1_CORE bits */
-#define AM35XX_EN_IPSS_MASK				(1 << 4)
 #define AM35XX_EN_IPSS_SHIFT				4
-
-/* CM_ICLKEN2_CORE */
-#define OMAP3430_EN_PKA_MASK				(1 << 4)
 #define OMAP3430_EN_PKA_SHIFT				4
-#define OMAP3430_EN_AES1_MASK				(1 << 3)
 #define OMAP3430_EN_AES1_SHIFT				3
-#define OMAP3430_EN_RNG_MASK				(1 << 2)
 #define OMAP3430_EN_RNG_SHIFT				2
-#define OMAP3430_EN_SHA11_MASK				(1 << 1)
 #define OMAP3430_EN_SHA11_SHIFT				1
-#define OMAP3430_EN_DES1_MASK				(1 << 0)
 #define OMAP3430_EN_DES1_SHIFT				0
-
-/* CM_ICLKEN3_CORE */
 #define OMAP3430_EN_MAD2D_SHIFT				3
-#define OMAP3430_EN_MAD2D_MASK				(1 << 3)
-
-/* CM_FCLKEN3_CORE specific bits */
 #define OMAP3430ES2_EN_TS_SHIFT				1
-#define OMAP3430ES2_EN_TS_MASK				(1 << 1)
 #define OMAP3430ES2_EN_CPEFUSE_SHIFT			0
-#define OMAP3430ES2_EN_CPEFUSE_MASK			(1 << 0)
-
-/* CM_IDLEST1_CORE specific bits */
-#define OMAP3430ES2_ST_MMC3_SHIFT			30
-#define OMAP3430ES2_ST_MMC3_MASK			(1 << 30)
-#define OMAP3430_ST_ICR_SHIFT				29
-#define OMAP3430_ST_ICR_MASK				(1 << 29)
 #define OMAP3430_ST_AES2_SHIFT				28
-#define OMAP3430_ST_AES2_MASK				(1 << 28)
 #define OMAP3430_ST_SHA12_SHIFT				27
-#define OMAP3430_ST_SHA12_MASK				(1 << 27)
-#define OMAP3430_ST_DES2_SHIFT				26
-#define OMAP3430_ST_DES2_MASK				(1 << 26)
-#define OMAP3430_ST_MSPRO_SHIFT				23
-#define OMAP3430_ST_MSPRO_MASK				(1 << 23)
 #define AM35XX_ST_UART4_SHIFT				23
-#define AM35XX_ST_UART4_MASK				(1 << 23)
 #define OMAP3430_ST_HDQ_SHIFT				22
-#define OMAP3430_ST_HDQ_MASK				(1 << 22)
-#define OMAP3430ES1_ST_FAC_SHIFT			8
-#define OMAP3430ES1_ST_FAC_MASK				(1 << 8)
 #define OMAP3430ES2_ST_SSI_IDLE_SHIFT			8
-#define OMAP3430ES2_ST_SSI_IDLE_MASK			(1 << 8)
 #define OMAP3430_ST_MAILBOXES_SHIFT			7
-#define OMAP3430_ST_MAILBOXES_MASK			(1 << 7)
-#define OMAP3430_ST_OMAPCTRL_SHIFT			6
-#define OMAP3430_ST_OMAPCTRL_MASK			(1 << 6)
 #define OMAP3430_ST_SAD2D_SHIFT				3
-#define OMAP3430_ST_SAD2D_MASK				(1 << 3)
 #define OMAP3430_ST_SDMA_SHIFT				2
-#define OMAP3430_ST_SDMA_MASK				(1 << 2)
-#define OMAP3430_ST_SDRC_SHIFT				1
-#define OMAP3430_ST_SDRC_MASK				(1 << 1)
-#define OMAP3430_ST_SSI_STDBY_SHIFT			0
-#define OMAP3430_ST_SSI_STDBY_MASK			(1 << 0)
-
-/* AM35xx specific CM_IDLEST1_CORE bits */
 #define AM35XX_ST_IPSS_SHIFT				5
-#define AM35XX_ST_IPSS_MASK 				(1 << 5)
-
-/* CM_IDLEST2_CORE */
-#define OMAP3430_ST_PKA_SHIFT				4
-#define OMAP3430_ST_PKA_MASK				(1 << 4)
-#define OMAP3430_ST_AES1_SHIFT				3
-#define OMAP3430_ST_AES1_MASK				(1 << 3)
-#define OMAP3430_ST_RNG_SHIFT				2
-#define OMAP3430_ST_RNG_MASK				(1 << 2)
-#define OMAP3430_ST_SHA11_SHIFT				1
-#define OMAP3430_ST_SHA11_MASK				(1 << 1)
-#define OMAP3430_ST_DES1_SHIFT				0
-#define OMAP3430_ST_DES1_MASK				(1 << 0)
-
-/* CM_IDLEST3_CORE */
 #define OMAP3430ES2_ST_USBTLL_SHIFT			2
-#define OMAP3430ES2_ST_USBTLL_MASK			(1 << 2)
-#define OMAP3430ES2_ST_CPEFUSE_SHIFT			0
-#define OMAP3430ES2_ST_CPEFUSE_MASK			(1 << 0)
-
-/* CM_AUTOIDLE1_CORE */
-#define OMAP3430_AUTO_MODEM_MASK			(1 << 31)
-#define OMAP3430_AUTO_MODEM_SHIFT			31
-#define OMAP3430ES2_AUTO_MMC3_MASK			(1 << 30)
-#define OMAP3430ES2_AUTO_MMC3_SHIFT			30
-#define OMAP3430ES2_AUTO_ICR_MASK			(1 << 29)
-#define OMAP3430ES2_AUTO_ICR_SHIFT			29
-#define OMAP3430_AUTO_AES2_MASK				(1 << 28)
-#define OMAP3430_AUTO_AES2_SHIFT			28
-#define OMAP3430_AUTO_SHA12_MASK			(1 << 27)
-#define OMAP3430_AUTO_SHA12_SHIFT			27
-#define OMAP3430_AUTO_DES2_MASK				(1 << 26)
-#define OMAP3430_AUTO_DES2_SHIFT			26
-#define OMAP3430_AUTO_MMC2_MASK				(1 << 25)
-#define OMAP3430_AUTO_MMC2_SHIFT			25
-#define OMAP3430_AUTO_MMC1_MASK				(1 << 24)
-#define OMAP3430_AUTO_MMC1_SHIFT			24
-#define OMAP3430_AUTO_MSPRO_MASK			(1 << 23)
-#define OMAP3430_AUTO_MSPRO_SHIFT			23
-#define OMAP3430_AUTO_HDQ_MASK				(1 << 22)
-#define OMAP3430_AUTO_HDQ_SHIFT				22
-#define OMAP3430_AUTO_MCSPI4_MASK			(1 << 21)
-#define OMAP3430_AUTO_MCSPI4_SHIFT			21
-#define OMAP3430_AUTO_MCSPI3_MASK			(1 << 20)
-#define OMAP3430_AUTO_MCSPI3_SHIFT			20
-#define OMAP3430_AUTO_MCSPI2_MASK			(1 << 19)
-#define OMAP3430_AUTO_MCSPI2_SHIFT			19
-#define OMAP3430_AUTO_MCSPI1_MASK			(1 << 18)
-#define OMAP3430_AUTO_MCSPI1_SHIFT			18
-#define OMAP3430_AUTO_I2C3_MASK				(1 << 17)
-#define OMAP3430_AUTO_I2C3_SHIFT			17
-#define OMAP3430_AUTO_I2C2_MASK				(1 << 16)
-#define OMAP3430_AUTO_I2C2_SHIFT			16
-#define OMAP3430_AUTO_I2C1_MASK				(1 << 15)
-#define OMAP3430_AUTO_I2C1_SHIFT			15
-#define OMAP3430_AUTO_UART2_MASK			(1 << 14)
-#define OMAP3430_AUTO_UART2_SHIFT			14
-#define OMAP3430_AUTO_UART1_MASK			(1 << 13)
-#define OMAP3430_AUTO_UART1_SHIFT			13
-#define OMAP3430_AUTO_GPT11_MASK			(1 << 12)
-#define OMAP3430_AUTO_GPT11_SHIFT			12
-#define OMAP3430_AUTO_GPT10_MASK			(1 << 11)
-#define OMAP3430_AUTO_GPT10_SHIFT			11
-#define OMAP3430_AUTO_MCBSP5_MASK			(1 << 10)
-#define OMAP3430_AUTO_MCBSP5_SHIFT			10
-#define OMAP3430_AUTO_MCBSP1_MASK			(1 << 9)
-#define OMAP3430_AUTO_MCBSP1_SHIFT			9
-#define OMAP3430ES1_AUTO_FAC_MASK			(1 << 8)
-#define OMAP3430ES1_AUTO_FAC_SHIFT			8
-#define OMAP3430_AUTO_MAILBOXES_MASK			(1 << 7)
-#define OMAP3430_AUTO_MAILBOXES_SHIFT			7
-#define OMAP3430_AUTO_OMAPCTRL_MASK			(1 << 6)
-#define OMAP3430_AUTO_OMAPCTRL_SHIFT			6
-#define OMAP3430ES1_AUTO_FSHOSTUSB_MASK			(1 << 5)
-#define OMAP3430ES1_AUTO_FSHOSTUSB_SHIFT		5
-#define OMAP3430_AUTO_HSOTGUSB_MASK			(1 << 4)
-#define OMAP3430_AUTO_HSOTGUSB_SHIFT			4
-#define OMAP3430ES1_AUTO_D2D_MASK			(1 << 3)
-#define OMAP3430ES1_AUTO_D2D_SHIFT			3
-#define OMAP3430_AUTO_SAD2D_MASK			(1 << 3)
-#define OMAP3430_AUTO_SAD2D_SHIFT			3
-#define OMAP3430_AUTO_SSI_MASK				(1 << 0)
-#define OMAP3430_AUTO_SSI_SHIFT				0
-
-/* CM_AUTOIDLE2_CORE */
-#define OMAP3430_AUTO_PKA_MASK				(1 << 4)
-#define OMAP3430_AUTO_PKA_SHIFT				4
-#define OMAP3430_AUTO_AES1_MASK				(1 << 3)
-#define OMAP3430_AUTO_AES1_SHIFT			3
-#define OMAP3430_AUTO_RNG_MASK				(1 << 2)
-#define OMAP3430_AUTO_RNG_SHIFT				2
-#define OMAP3430_AUTO_SHA11_MASK			(1 << 1)
-#define OMAP3430_AUTO_SHA11_SHIFT			1
-#define OMAP3430_AUTO_DES1_MASK				(1 << 0)
-#define OMAP3430_AUTO_DES1_SHIFT			0
-
-/* CM_AUTOIDLE3_CORE */
-#define	OMAP3430ES2_AUTO_USBHOST			(1 << 0)
-#define	OMAP3430ES2_AUTO_USBHOST_SHIFT			0
-#define	OMAP3430ES2_AUTO_USBTLL				(1 << 2)
-#define OMAP3430ES2_AUTO_USBTLL_SHIFT			2
-#define OMAP3430ES2_AUTO_USBTLL_MASK			(1 << 2)
-#define OMAP3430_AUTO_MAD2D_SHIFT			3
-#define OMAP3430_AUTO_MAD2D_MASK			(1 << 3)
-
-/* CM_CLKSEL_CORE */
-#define OMAP3430_CLKSEL_SSI_SHIFT			8
 #define OMAP3430_CLKSEL_SSI_MASK			(0xf << 8)
 #define OMAP3430_CLKSEL_GPT11_MASK			(1 << 7)
-#define OMAP3430_CLKSEL_GPT11_SHIFT			7
 #define OMAP3430_CLKSEL_GPT10_MASK			(1 << 6)
-#define OMAP3430_CLKSEL_GPT10_SHIFT			6
-#define OMAP3430ES1_CLKSEL_FSHOSTUSB_SHIFT		4
 #define OMAP3430ES1_CLKSEL_FSHOSTUSB_MASK		(0x3 << 4)
 #define OMAP3430_CLKSEL_L4_SHIFT			2
-#define OMAP3430_CLKSEL_L4_MASK				(0x3 << 2)
 #define OMAP3430_CLKSEL_L4_WIDTH			2
 #define OMAP3430_CLKSEL_L3_SHIFT			0
-#define OMAP3430_CLKSEL_L3_MASK				(0x3 << 0)
 #define OMAP3430_CLKSEL_L3_WIDTH			2
-#define OMAP3630_CLKSEL_96M_SHIFT			12
 #define OMAP3630_CLKSEL_96M_MASK			(0x3 << 12)
-#define OMAP3630_CLKSEL_96M_WIDTH			2
-
-/* CM_CLKSTCTRL_CORE */
-#define OMAP3430ES1_CLKTRCTRL_D2D_SHIFT			4
 #define OMAP3430ES1_CLKTRCTRL_D2D_MASK			(0x3 << 4)
-#define OMAP3430_CLKTRCTRL_L4_SHIFT			2
 #define OMAP3430_CLKTRCTRL_L4_MASK			(0x3 << 2)
-#define OMAP3430_CLKTRCTRL_L3_SHIFT			0
 #define OMAP3430_CLKTRCTRL_L3_MASK			(0x3 << 0)
-
-/* CM_CLKSTST_CORE */
-#define OMAP3430ES1_CLKACTIVITY_D2D_SHIFT		2
-#define OMAP3430ES1_CLKACTIVITY_D2D_MASK		(1 << 2)
-#define OMAP3430_CLKACTIVITY_L4_SHIFT			1
-#define OMAP3430_CLKACTIVITY_L4_MASK			(1 << 1)
-#define OMAP3430_CLKACTIVITY_L3_SHIFT			0
-#define OMAP3430_CLKACTIVITY_L3_MASK			(1 << 0)
-
-/* CM_FCLKEN_GFX */
-#define OMAP3430ES1_EN_3D_MASK				(1 << 2)
 #define OMAP3430ES1_EN_3D_SHIFT				2
-#define OMAP3430ES1_EN_2D_MASK				(1 << 1)
 #define OMAP3430ES1_EN_2D_SHIFT				1
-
-/* CM_ICLKEN_GFX specific bits */
-
-/* CM_IDLEST_GFX specific bits */
-
-/* CM_CLKSEL_GFX specific bits */
-
-/* CM_SLEEPDEP_GFX specific bits */
-
-/* CM_CLKSTCTRL_GFX */
-#define OMAP3430ES1_CLKTRCTRL_GFX_SHIFT			0
 #define OMAP3430ES1_CLKTRCTRL_GFX_MASK			(0x3 << 0)
-
-/* CM_CLKSTST_GFX */
-#define OMAP3430ES1_CLKACTIVITY_GFX_SHIFT		0
-#define OMAP3430ES1_CLKACTIVITY_GFX_MASK		(1 << 0)
-
-/* CM_FCLKEN_SGX */
 #define OMAP3430ES2_CM_FCLKEN_SGX_EN_SGX_SHIFT		1
-#define OMAP3430ES2_CM_FCLKEN_SGX_EN_SGX_MASK		(1 << 1)
-
-/* CM_IDLEST_SGX */
-#define OMAP3430ES2_ST_SGX_SHIFT			1
-#define OMAP3430ES2_ST_SGX_MASK				(1 << 1)
-
-/* CM_ICLKEN_SGX */
 #define OMAP3430ES2_CM_ICLKEN_SGX_EN_SGX_SHIFT		0
-#define OMAP3430ES2_CM_ICLKEN_SGX_EN_SGX_MASK		(1 << 0)
-
-/* CM_CLKSEL_SGX */
-#define OMAP3430ES2_CLKSEL_SGX_SHIFT			0
 #define OMAP3430ES2_CLKSEL_SGX_MASK			(0x7 << 0)
-
-/* CM_CLKSTCTRL_SGX */
-#define OMAP3430ES2_CLKTRCTRL_SGX_SHIFT			0
 #define OMAP3430ES2_CLKTRCTRL_SGX_MASK			(0x3 << 0)
-
-/* CM_CLKSTST_SGX */
-#define OMAP3430ES2_CLKACTIVITY_SGX_SHIFT		0
-#define OMAP3430ES2_CLKACTIVITY_SGX_MASK		(1 << 0)
-
-/* CM_FCLKEN_WKUP specific bits */
 #define OMAP3430ES2_EN_USIMOCP_SHIFT			9
-#define OMAP3430ES2_EN_USIMOCP_MASK			(1 << 9)
-
-/* CM_ICLKEN_WKUP specific bits */
-#define OMAP3430_EN_WDT1_MASK				(1 << 4)
 #define OMAP3430_EN_WDT1_SHIFT				4
-#define OMAP3430_EN_32KSYNC_MASK			(1 << 2)
 #define OMAP3430_EN_32KSYNC_SHIFT			2
-
-/* CM_IDLEST_WKUP specific bits */
-#define OMAP3430ES2_ST_USIMOCP_SHIFT			9
-#define OMAP3430ES2_ST_USIMOCP_MASK			(1 << 9)
 #define OMAP3430_ST_WDT2_SHIFT				5
-#define OMAP3430_ST_WDT2_MASK				(1 << 5)
-#define OMAP3430_ST_WDT1_SHIFT				4
-#define OMAP3430_ST_WDT1_MASK				(1 << 4)
 #define OMAP3430_ST_32KSYNC_SHIFT			2
-#define OMAP3430_ST_32KSYNC_MASK			(1 << 2)
-
-/* CM_AUTOIDLE_WKUP */
-#define OMAP3430ES2_AUTO_USIMOCP_MASK			(1 << 9)
-#define OMAP3430ES2_AUTO_USIMOCP_SHIFT			9
-#define OMAP3430_AUTO_WDT2_MASK				(1 << 5)
-#define OMAP3430_AUTO_WDT2_SHIFT			5
-#define OMAP3430_AUTO_WDT1_MASK				(1 << 4)
-#define OMAP3430_AUTO_WDT1_SHIFT			4
-#define OMAP3430_AUTO_GPIO1_MASK			(1 << 3)
-#define OMAP3430_AUTO_GPIO1_SHIFT			3
-#define OMAP3430_AUTO_32KSYNC_MASK			(1 << 2)
-#define OMAP3430_AUTO_32KSYNC_SHIFT			2
-#define OMAP3430_AUTO_GPT12_MASK			(1 << 1)
-#define OMAP3430_AUTO_GPT12_SHIFT			1
-#define OMAP3430_AUTO_GPT1_MASK				(1 << 0)
-#define OMAP3430_AUTO_GPT1_SHIFT			0
-
-/* CM_CLKSEL_WKUP */
 #define OMAP3430ES2_CLKSEL_USIMOCP_MASK			(0xf << 3)
 #define OMAP3430_CLKSEL_RM_SHIFT			1
-#define OMAP3430_CLKSEL_RM_MASK				(0x3 << 1)
 #define OMAP3430_CLKSEL_RM_WIDTH			2
-#define OMAP3430_CLKSEL_GPT1_SHIFT			0
 #define OMAP3430_CLKSEL_GPT1_MASK			(1 << 0)
-
-/* CM_CLKEN_PLL */
 #define OMAP3430_PWRDN_EMU_PERIPH_SHIFT			31
 #define OMAP3430_PWRDN_CAM_SHIFT			30
 #define OMAP3430_PWRDN_DSS1_SHIFT			29
 #define OMAP3430_PWRDN_TV_SHIFT				28
 #define OMAP3430_PWRDN_96M_SHIFT			27
-#define OMAP3430_PERIPH_DPLL_RAMPTIME_SHIFT		24
-#define OMAP3430_PERIPH_DPLL_RAMPTIME_MASK		(0x3 << 24)
-#define OMAP3430_PERIPH_DPLL_FREQSEL_SHIFT		20
 #define OMAP3430_PERIPH_DPLL_FREQSEL_MASK		(0xf << 20)
 #define OMAP3430_EN_PERIPH_DPLL_DRIFTGUARD_SHIFT	19
-#define OMAP3430_EN_PERIPH_DPLL_DRIFTGUARD_MASK		(1 << 19)
-#define OMAP3430_EN_PERIPH_DPLL_SHIFT			16
 #define OMAP3430_EN_PERIPH_DPLL_MASK			(0x7 << 16)
 #define OMAP3430_PWRDN_EMU_CORE_SHIFT			12
-#define OMAP3430_CORE_DPLL_RAMPTIME_SHIFT		8
-#define OMAP3430_CORE_DPLL_RAMPTIME_MASK		(0x3 << 8)
-#define OMAP3430_CORE_DPLL_FREQSEL_SHIFT		4
 #define OMAP3430_CORE_DPLL_FREQSEL_MASK			(0xf << 4)
 #define OMAP3430_EN_CORE_DPLL_DRIFTGUARD_SHIFT		3
-#define OMAP3430_EN_CORE_DPLL_DRIFTGUARD_MASK		(1 << 3)
-#define OMAP3430_EN_CORE_DPLL_SHIFT			0
 #define OMAP3430_EN_CORE_DPLL_MASK			(0x7 << 0)
-
-/* CM_CLKEN2_PLL */
-#define OMAP3430ES2_EN_PERIPH2_DPLL_LPMODE_SHIFT	10
-#define OMAP3430ES2_PERIPH2_DPLL_RAMPTIME_MASK		(0x3 << 8)
-#define OMAP3430ES2_PERIPH2_DPLL_FREQSEL_SHIFT		4
 #define OMAP3430ES2_PERIPH2_DPLL_FREQSEL_MASK		(0xf << 4)
 #define OMAP3430ES2_EN_PERIPH2_DPLL_DRIFTGUARD_SHIFT	3
-#define OMAP3430ES2_EN_PERIPH2_DPLL_SHIFT		0
 #define OMAP3430ES2_EN_PERIPH2_DPLL_MASK		(0x7 << 0)
-
-/* CM_IDLEST_CKGEN */
-#define OMAP3430_ST_54M_CLK_MASK			(1 << 5)
-#define OMAP3430_ST_12M_CLK_MASK			(1 << 4)
-#define OMAP3430_ST_48M_CLK_MASK			(1 << 3)
-#define OMAP3430_ST_96M_CLK_MASK			(1 << 2)
-#define OMAP3430_ST_PERIPH_CLK_SHIFT			1
 #define OMAP3430_ST_PERIPH_CLK_MASK			(1 << 1)
-#define OMAP3430_ST_CORE_CLK_SHIFT			0
 #define OMAP3430_ST_CORE_CLK_MASK			(1 << 0)
-
-/* CM_IDLEST2_CKGEN */
-#define OMAP3430ES2_ST_USIM_CLK_SHIFT			2
-#define OMAP3430ES2_ST_USIM_CLK_MASK			(1 << 2)
-#define OMAP3430ES2_ST_120M_CLK_SHIFT			1
-#define OMAP3430ES2_ST_120M_CLK_MASK			(1 << 1)
-#define OMAP3430ES2_ST_PERIPH2_CLK_SHIFT		0
 #define OMAP3430ES2_ST_PERIPH2_CLK_MASK			(1 << 0)
-
-/* CM_AUTOIDLE_PLL */
-#define OMAP3430_AUTO_PERIPH_DPLL_SHIFT			3
 #define OMAP3430_AUTO_PERIPH_DPLL_MASK			(0x7 << 3)
-#define OMAP3430_AUTO_CORE_DPLL_SHIFT			0
 #define OMAP3430_AUTO_CORE_DPLL_MASK			(0x7 << 0)
-
-/* CM_AUTOIDLE2_PLL */
-#define OMAP3430ES2_AUTO_PERIPH2_DPLL_SHIFT		0
 #define OMAP3430ES2_AUTO_PERIPH2_DPLL_MASK		(0x7 << 0)
-
-/* CM_CLKSEL1_PLL */
-/* Note that OMAP3430_CORE_DPLL_CLKOUT_DIV_MASK was (0x3 << 27) on 3430ES1 */
 #define OMAP3430_CORE_DPLL_CLKOUT_DIV_SHIFT		27
-#define OMAP3430_CORE_DPLL_CLKOUT_DIV_MASK		(0x1f << 27)
 #define OMAP3430_CORE_DPLL_CLKOUT_DIV_WIDTH		5
-#define OMAP3430_CORE_DPLL_MULT_SHIFT			16
 #define OMAP3430_CORE_DPLL_MULT_MASK			(0x7ff << 16)
-#define OMAP3430_CORE_DPLL_DIV_SHIFT			8
 #define OMAP3430_CORE_DPLL_DIV_MASK			(0x7f << 8)
 #define OMAP3430_SOURCE_96M_SHIFT			6
-#define OMAP3430_SOURCE_96M_MASK			(1 << 6)
 #define OMAP3430_SOURCE_96M_WIDTH			1
 #define OMAP3430_SOURCE_54M_SHIFT			5
-#define OMAP3430_SOURCE_54M_MASK			(1 << 5)
 #define OMAP3430_SOURCE_54M_WIDTH			1
-#define OMAP3430_SOURCE_48M_SHIFT			3
 #define OMAP3430_SOURCE_48M_MASK			(1 << 3)
-
-/* CM_CLKSEL2_PLL */
-#define OMAP3430_PERIPH_DPLL_MULT_SHIFT			8
 #define OMAP3430_PERIPH_DPLL_MULT_MASK			(0x7ff << 8)
 #define OMAP3630_PERIPH_DPLL_MULT_MASK			(0xfff << 8)
-#define OMAP3430_PERIPH_DPLL_DIV_SHIFT			0
 #define OMAP3430_PERIPH_DPLL_DIV_MASK			(0x7f << 0)
-#define OMAP3630_PERIPH_DPLL_DCO_SEL_SHIFT		21
 #define OMAP3630_PERIPH_DPLL_DCO_SEL_MASK		(0x7 << 21)
-#define OMAP3630_PERIPH_DPLL_SD_DIV_SHIFT		24
 #define OMAP3630_PERIPH_DPLL_SD_DIV_MASK		(0xff << 24)
-
-/* CM_CLKSEL3_PLL */
 #define OMAP3430_DIV_96M_SHIFT				0
-#define OMAP3430_DIV_96M_MASK				(0x1f << 0)
-#define OMAP3430_DIV_96M_WIDTH				5
-#define OMAP3630_DIV_96M_MASK				(0x3f << 0)
 #define OMAP3630_DIV_96M_WIDTH				6
-
-/* CM_CLKSEL4_PLL */
-#define OMAP3430ES2_PERIPH2_DPLL_MULT_SHIFT		8
 #define OMAP3430ES2_PERIPH2_DPLL_MULT_MASK		(0x7ff << 8)
-#define OMAP3430ES2_PERIPH2_DPLL_DIV_SHIFT		0
 #define OMAP3430ES2_PERIPH2_DPLL_DIV_MASK		(0x7f << 0)
-
-/* CM_CLKSEL5_PLL */
 #define OMAP3430ES2_DIV_120M_SHIFT			0
-#define OMAP3430ES2_DIV_120M_MASK			(0x1f << 0)
 #define OMAP3430ES2_DIV_120M_WIDTH			5
-
-/* CM_CLKOUT_CTRL */
 #define OMAP3430_CLKOUT2_EN_SHIFT			7
-#define OMAP3430_CLKOUT2_EN_MASK			(1 << 7)
 #define OMAP3430_CLKOUT2_DIV_SHIFT			3
-#define OMAP3430_CLKOUT2_DIV_MASK			(0x7 << 3)
 #define OMAP3430_CLKOUT2_DIV_WIDTH			3
-#define OMAP3430_CLKOUT2SOURCE_SHIFT			0
 #define OMAP3430_CLKOUT2SOURCE_MASK			(0x3 << 0)
-
-/* CM_FCLKEN_DSS */
-#define OMAP3430_EN_TV_MASK				(1 << 2)
 #define OMAP3430_EN_TV_SHIFT				2
-#define OMAP3430_EN_DSS2_MASK				(1 << 1)
 #define OMAP3430_EN_DSS2_SHIFT				1
-#define OMAP3430_EN_DSS1_MASK				(1 << 0)
 #define OMAP3430_EN_DSS1_SHIFT				0
-
-/* CM_ICLKEN_DSS */
-#define OMAP3430_CM_ICLKEN_DSS_EN_DSS_MASK		(1 << 0)
 #define OMAP3430_CM_ICLKEN_DSS_EN_DSS_SHIFT		0
-
-/* CM_IDLEST_DSS */
 #define OMAP3430ES2_ST_DSS_IDLE_SHIFT			1
-#define OMAP3430ES2_ST_DSS_IDLE_MASK			(1 << 1)
 #define OMAP3430ES2_ST_DSS_STDBY_SHIFT			0
-#define OMAP3430ES2_ST_DSS_STDBY_MASK			(1 << 0)
 #define OMAP3430ES1_ST_DSS_SHIFT			0
-#define OMAP3430ES1_ST_DSS_MASK				(1 << 0)
-
-/* CM_AUTOIDLE_DSS */
-#define OMAP3430_AUTO_DSS_MASK				(1 << 0)
-#define OMAP3430_AUTO_DSS_SHIFT				0
-
-/* CM_CLKSEL_DSS */
 #define OMAP3430_CLKSEL_TV_SHIFT			8
-#define OMAP3430_CLKSEL_TV_MASK				(0x1f << 8)
-#define OMAP3430_CLKSEL_TV_WIDTH			5
-#define OMAP3630_CLKSEL_TV_MASK				(0x3f << 8)
 #define OMAP3630_CLKSEL_TV_WIDTH			6
 #define OMAP3430_CLKSEL_DSS1_SHIFT			0
-#define OMAP3430_CLKSEL_DSS1_MASK			(0x1f << 0)
-#define OMAP3430_CLKSEL_DSS1_WIDTH			5
-#define OMAP3630_CLKSEL_DSS1_MASK			(0x3f << 0)
 #define OMAP3630_CLKSEL_DSS1_WIDTH			6
-
-/* CM_SLEEPDEP_DSS specific bits */
-
-/* CM_CLKSTCTRL_DSS */
-#define OMAP3430_CLKTRCTRL_DSS_SHIFT			0
 #define OMAP3430_CLKTRCTRL_DSS_MASK			(0x3 << 0)
-
-/* CM_CLKSTST_DSS */
-#define OMAP3430_CLKACTIVITY_DSS_SHIFT			0
-#define OMAP3430_CLKACTIVITY_DSS_MASK			(1 << 0)
-
-/* CM_FCLKEN_CAM specific bits */
-#define OMAP3430_EN_CSI2_MASK				(1 << 1)
 #define OMAP3430_EN_CSI2_SHIFT				1
-
-/* CM_ICLKEN_CAM specific bits */
-
-/* CM_IDLEST_CAM */
-#define OMAP3430_ST_CAM_MASK				(1 << 0)
-
-/* CM_AUTOIDLE_CAM */
-#define OMAP3430_AUTO_CAM_MASK				(1 << 0)
-#define OMAP3430_AUTO_CAM_SHIFT				0
-
-/* CM_CLKSEL_CAM */
 #define OMAP3430_CLKSEL_CAM_SHIFT			0
-#define OMAP3430_CLKSEL_CAM_MASK			(0x1f << 0)
-#define OMAP3430_CLKSEL_CAM_WIDTH			5
-#define OMAP3630_CLKSEL_CAM_MASK			(0x3f << 0)
 #define OMAP3630_CLKSEL_CAM_WIDTH			6
-
-/* CM_SLEEPDEP_CAM specific bits */
-
-/* CM_CLKSTCTRL_CAM */
-#define OMAP3430_CLKTRCTRL_CAM_SHIFT			0
 #define OMAP3430_CLKTRCTRL_CAM_MASK			(0x3 << 0)
-
-/* CM_CLKSTST_CAM */
-#define OMAP3430_CLKACTIVITY_CAM_SHIFT			0
-#define OMAP3430_CLKACTIVITY_CAM_MASK			(1 << 0)
-
-/* CM_FCLKEN_PER specific bits */
-
-/* CM_ICLKEN_PER specific bits */
-
-/* CM_IDLEST_PER */
-#define OMAP3430_ST_WDT3_SHIFT				12
-#define OMAP3430_ST_WDT3_MASK				(1 << 12)
 #define OMAP3430_ST_MCBSP4_SHIFT			2
-#define OMAP3430_ST_MCBSP4_MASK				(1 << 2)
 #define OMAP3430_ST_MCBSP3_SHIFT			1
-#define OMAP3430_ST_MCBSP3_MASK				(1 << 1)
 #define OMAP3430_ST_MCBSP2_SHIFT			0
-#define OMAP3430_ST_MCBSP2_MASK				(1 << 0)
-
-/* CM_AUTOIDLE_PER */
-#define OMAP3630_AUTO_UART4_MASK			(1 << 18)
-#define OMAP3630_AUTO_UART4_SHIFT			18
-#define OMAP3430_AUTO_GPIO6_MASK			(1 << 17)
-#define OMAP3430_AUTO_GPIO6_SHIFT			17
-#define OMAP3430_AUTO_GPIO5_MASK			(1 << 16)
-#define OMAP3430_AUTO_GPIO5_SHIFT			16
-#define OMAP3430_AUTO_GPIO4_MASK			(1 << 15)
-#define OMAP3430_AUTO_GPIO4_SHIFT			15
-#define OMAP3430_AUTO_GPIO3_MASK			(1 << 14)
-#define OMAP3430_AUTO_GPIO3_SHIFT			14
-#define OMAP3430_AUTO_GPIO2_MASK			(1 << 13)
-#define OMAP3430_AUTO_GPIO2_SHIFT			13
-#define OMAP3430_AUTO_WDT3_MASK				(1 << 12)
-#define OMAP3430_AUTO_WDT3_SHIFT			12
-#define OMAP3430_AUTO_UART3_MASK			(1 << 11)
-#define OMAP3430_AUTO_UART3_SHIFT			11
-#define OMAP3430_AUTO_GPT9_MASK				(1 << 10)
-#define OMAP3430_AUTO_GPT9_SHIFT			10
-#define OMAP3430_AUTO_GPT8_MASK				(1 << 9)
-#define OMAP3430_AUTO_GPT8_SHIFT			9
-#define OMAP3430_AUTO_GPT7_MASK				(1 << 8)
-#define OMAP3430_AUTO_GPT7_SHIFT			8
-#define OMAP3430_AUTO_GPT6_MASK				(1 << 7)
-#define OMAP3430_AUTO_GPT6_SHIFT			7
-#define OMAP3430_AUTO_GPT5_MASK				(1 << 6)
-#define OMAP3430_AUTO_GPT5_SHIFT			6
-#define OMAP3430_AUTO_GPT4_MASK				(1 << 5)
-#define OMAP3430_AUTO_GPT4_SHIFT			5
-#define OMAP3430_AUTO_GPT3_MASK				(1 << 4)
-#define OMAP3430_AUTO_GPT3_SHIFT			4
-#define OMAP3430_AUTO_GPT2_MASK				(1 << 3)
-#define OMAP3430_AUTO_GPT2_SHIFT			3
-#define OMAP3430_AUTO_MCBSP4_MASK			(1 << 2)
-#define OMAP3430_AUTO_MCBSP4_SHIFT			2
-#define OMAP3430_AUTO_MCBSP3_MASK			(1 << 1)
-#define OMAP3430_AUTO_MCBSP3_SHIFT			1
-#define OMAP3430_AUTO_MCBSP2_MASK			(1 << 0)
-#define OMAP3430_AUTO_MCBSP2_SHIFT			0
-
-/* CM_CLKSEL_PER */
 #define OMAP3430_CLKSEL_GPT9_MASK			(1 << 7)
-#define OMAP3430_CLKSEL_GPT9_SHIFT			7
 #define OMAP3430_CLKSEL_GPT8_MASK			(1 << 6)
-#define OMAP3430_CLKSEL_GPT8_SHIFT			6
 #define OMAP3430_CLKSEL_GPT7_MASK			(1 << 5)
-#define OMAP3430_CLKSEL_GPT7_SHIFT			5
 #define OMAP3430_CLKSEL_GPT6_MASK			(1 << 4)
-#define OMAP3430_CLKSEL_GPT6_SHIFT			4
 #define OMAP3430_CLKSEL_GPT5_MASK			(1 << 3)
-#define OMAP3430_CLKSEL_GPT5_SHIFT			3
 #define OMAP3430_CLKSEL_GPT4_MASK			(1 << 2)
-#define OMAP3430_CLKSEL_GPT4_SHIFT			2
 #define OMAP3430_CLKSEL_GPT3_MASK			(1 << 1)
-#define OMAP3430_CLKSEL_GPT3_SHIFT			1
 #define OMAP3430_CLKSEL_GPT2_MASK			(1 << 0)
-#define OMAP3430_CLKSEL_GPT2_SHIFT			0
-
-/* CM_SLEEPDEP_PER specific bits */
-#define OMAP3430_CM_SLEEPDEP_PER_EN_IVA2_MASK		(1 << 2)
-
-/* CM_CLKSTCTRL_PER */
-#define OMAP3430_CLKTRCTRL_PER_SHIFT			0
 #define OMAP3430_CLKTRCTRL_PER_MASK			(0x3 << 0)
-
-/* CM_CLKSTST_PER */
-#define OMAP3430_CLKACTIVITY_PER_SHIFT			0
-#define OMAP3430_CLKACTIVITY_PER_MASK			(1 << 0)
-
-/* CM_CLKSEL1_EMU */
 #define OMAP3430_DIV_DPLL4_SHIFT			24
-#define OMAP3430_DIV_DPLL4_MASK				(0x1f << 24)
-#define OMAP3430_DIV_DPLL4_WIDTH			5
-#define OMAP3630_DIV_DPLL4_MASK				(0x3f << 24)
 #define OMAP3630_DIV_DPLL4_WIDTH			6
 #define OMAP3430_DIV_DPLL3_SHIFT			16
-#define OMAP3430_DIV_DPLL3_MASK				(0x1f << 16)
 #define OMAP3430_DIV_DPLL3_WIDTH			5
 #define OMAP3430_CLKSEL_TRACECLK_SHIFT			11
-#define OMAP3430_CLKSEL_TRACECLK_MASK			(0x7 << 11)
 #define OMAP3430_CLKSEL_TRACECLK_WIDTH			3
 #define OMAP3430_CLKSEL_PCLK_SHIFT			8
-#define OMAP3430_CLKSEL_PCLK_MASK			(0x7 << 8)
 #define OMAP3430_CLKSEL_PCLK_WIDTH			3
 #define OMAP3430_CLKSEL_PCLKX2_SHIFT			6
-#define OMAP3430_CLKSEL_PCLKX2_MASK			(0x3 << 6)
 #define OMAP3430_CLKSEL_PCLKX2_WIDTH			2
 #define OMAP3430_CLKSEL_ATCLK_SHIFT			4
-#define OMAP3430_CLKSEL_ATCLK_MASK			(0x3 << 4)
 #define OMAP3430_CLKSEL_ATCLK_WIDTH			2
 #define OMAP3430_TRACE_MUX_CTRL_SHIFT			2
-#define OMAP3430_TRACE_MUX_CTRL_MASK			(0x3 << 2)
 #define OMAP3430_TRACE_MUX_CTRL_WIDTH			2
-#define OMAP3430_MUX_CTRL_SHIFT				0
 #define OMAP3430_MUX_CTRL_MASK				(0x3 << 0)
-#define OMAP3430_MUX_CTRL_WIDTH				2
-
-/* CM_CLKSTCTRL_EMU */
-#define OMAP3430_CLKTRCTRL_EMU_SHIFT			0
 #define OMAP3430_CLKTRCTRL_EMU_MASK			(0x3 << 0)
-
-/* CM_CLKSTST_EMU */
-#define OMAP3430_CLKACTIVITY_EMU_SHIFT			0
-#define OMAP3430_CLKACTIVITY_EMU_MASK			(1 << 0)
-
-/* CM_CLKSEL2_EMU specific bits */
-#define OMAP3430_CORE_DPLL_EMU_MULT_SHIFT		8
-#define OMAP3430_CORE_DPLL_EMU_MULT_MASK		(0x7ff << 8)
-#define OMAP3430_CORE_DPLL_EMU_DIV_SHIFT		0
-#define OMAP3430_CORE_DPLL_EMU_DIV_MASK			(0x7f << 0)
-
-/* CM_CLKSEL3_EMU specific bits */
-#define OMAP3430_PERIPH_DPLL_EMU_MULT_SHIFT		8
-#define OMAP3430_PERIPH_DPLL_EMU_MULT_MASK		(0x7ff << 8)
-#define OMAP3430_PERIPH_DPLL_EMU_DIV_SHIFT		0
-#define OMAP3430_PERIPH_DPLL_EMU_DIV_MASK		(0x7f << 0)
-
-/* CM_POLCTRL */
-#define OMAP3430_CLKOUT2_POL_MASK			(1 << 0)
-
-/* CM_IDLEST_NEON */
-#define OMAP3430_ST_NEON_MASK				(1 << 0)
-
-/* CM_CLKSTCTRL_NEON */
-#define OMAP3430_CLKTRCTRL_NEON_SHIFT			0
 #define OMAP3430_CLKTRCTRL_NEON_MASK			(0x3 << 0)
-
-/* CM_FCLKEN_USBHOST */
 #define OMAP3430ES2_EN_USBHOST2_SHIFT			1
-#define OMAP3430ES2_EN_USBHOST2_MASK			(1 << 1)
 #define OMAP3430ES2_EN_USBHOST1_SHIFT			0
-#define OMAP3430ES2_EN_USBHOST1_MASK			(1 << 0)
-
-/* CM_ICLKEN_USBHOST */
 #define OMAP3430ES2_EN_USBHOST_SHIFT			0
-#define OMAP3430ES2_EN_USBHOST_MASK			(1 << 0)
-
-/* CM_IDLEST_USBHOST */
 #define OMAP3430ES2_ST_USBHOST_IDLE_SHIFT		1
-#define OMAP3430ES2_ST_USBHOST_IDLE_MASK		(1 << 1)
 #define OMAP3430ES2_ST_USBHOST_STDBY_SHIFT		0
-#define OMAP3430ES2_ST_USBHOST_STDBY_MASK		(1 << 0)
-
-/* CM_AUTOIDLE_USBHOST */
-#define OMAP3430ES2_AUTO_USBHOST_SHIFT			0
-#define OMAP3430ES2_AUTO_USBHOST_MASK			(1 << 0)
-
-/* CM_SLEEPDEP_USBHOST */
-#define OMAP3430ES2_EN_MPU_SHIFT			1
-#define OMAP3430ES2_EN_MPU_MASK				(1 << 1)
-#define OMAP3430ES2_EN_IVA2_SHIFT			2
-#define OMAP3430ES2_EN_IVA2_MASK			(1 << 2)
-
-/* CM_CLKSTCTRL_USBHOST */
-#define OMAP3430ES2_CLKTRCTRL_USBHOST_SHIFT		0
 #define OMAP3430ES2_CLKTRCTRL_USBHOST_MASK		(3 << 0)
-
-/* CM_CLKSTST_USBHOST */
-#define OMAP3430ES2_CLKACTIVITY_USBHOST_SHIFT		0
-#define OMAP3430ES2_CLKACTIVITY_USBHOST_MASK		(1 << 0)
-
-/*
- *
- */
-
-/* OMAP3XXX CM_CLKSTCTRL_*.CLKTRCTRL_* register bit values */
 #define OMAP34XX_CLKSTCTRL_DISABLE_AUTO		0x0
 #define OMAP34XX_CLKSTCTRL_FORCE_SLEEP		0x1
 #define OMAP34XX_CLKSTCTRL_FORCE_WAKEUP		0x2
 #define OMAP34XX_CLKSTCTRL_ENABLE_AUTO		0x3
-
-
 #endif
diff --git a/arch/arm/mach-omap2/prm-regbits-33xx.h b/arch/arm/mach-omap2/prm-regbits-33xx.h
index 0221b5c..bbffc03 100644
--- a/arch/arm/mach-omap2/prm-regbits-33xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-33xx.h
@@ -18,340 +18,34 @@
 
 #include "prm.h"
 
-/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */
-#define AM33XX_ABBOFF_ACT_EXPORT_SHIFT			1
-#define AM33XX_ABBOFF_ACT_EXPORT_MASK			(1 << 1)
-
-/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */
-#define AM33XX_ABBOFF_SLEEP_EXPORT_SHIFT		2
-#define AM33XX_ABBOFF_SLEEP_EXPORT_MASK			(1 << 2)
-
-/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */
-#define AM33XX_AIPOFF_SHIFT				8
-#define AM33XX_AIPOFF_MASK				(1 << 8)
-
-/* Used by PM_WKUP_PWRSTST */
-#define AM33XX_DEBUGSS_MEM_STATEST_SHIFT		17
-#define AM33XX_DEBUGSS_MEM_STATEST_MASK			(0x3 << 17)
-
-/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */
-#define AM33XX_DISABLE_RTA_EXPORT_SHIFT			0
-#define AM33XX_DISABLE_RTA_EXPORT_MASK			(1 << 0)
-
-/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */
-#define AM33XX_DPLL_CORE_RECAL_EN_SHIFT			12
-#define AM33XX_DPLL_CORE_RECAL_EN_MASK			(1 << 12)
-
-/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */
-#define AM33XX_DPLL_CORE_RECAL_ST_SHIFT			12
-#define AM33XX_DPLL_CORE_RECAL_ST_MASK			(1 << 12)
-
-/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */
-#define AM33XX_DPLL_DDR_RECAL_EN_SHIFT			14
-#define AM33XX_DPLL_DDR_RECAL_EN_MASK			(1 << 14)
-
-/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */
-#define AM33XX_DPLL_DDR_RECAL_ST_SHIFT			14
-#define AM33XX_DPLL_DDR_RECAL_ST_MASK			(1 << 14)
-
-/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */
-#define AM33XX_DPLL_DISP_RECAL_EN_SHIFT			15
-#define AM33XX_DPLL_DISP_RECAL_EN_MASK			(1 << 15)
-
-/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */
-#define AM33XX_DPLL_DISP_RECAL_ST_SHIFT			13
-#define AM33XX_DPLL_DISP_RECAL_ST_MASK			(1 << 13)
-
-/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */
-#define AM33XX_DPLL_MPU_RECAL_EN_SHIFT			11
-#define AM33XX_DPLL_MPU_RECAL_EN_MASK			(1 << 11)
-
-/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */
-#define AM33XX_DPLL_MPU_RECAL_ST_SHIFT			11
-#define AM33XX_DPLL_MPU_RECAL_ST_MASK			(1 << 11)
-
-/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */
-#define AM33XX_DPLL_PER_RECAL_EN_SHIFT			13
-#define AM33XX_DPLL_PER_RECAL_EN_MASK			(1 << 13)
-
-/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */
-#define AM33XX_DPLL_PER_RECAL_ST_SHIFT			15
-#define AM33XX_DPLL_PER_RECAL_ST_MASK			(1 << 15)
-
-/* Used by RM_WKUP_RSTST */
-#define AM33XX_EMULATION_M3_RST_SHIFT			6
-#define AM33XX_EMULATION_M3_RST_MASK			(1 << 6)
-
-/* Used by RM_MPU_RSTST */
-#define AM33XX_EMULATION_MPU_RST_SHIFT			5
-#define AM33XX_EMULATION_MPU_RST_MASK			(1 << 5)
-
-/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */
-#define AM33XX_ENFUNC1_EXPORT_SHIFT			3
-#define AM33XX_ENFUNC1_EXPORT_MASK			(1 << 3)
-
-/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */
-#define AM33XX_ENFUNC3_EXPORT_SHIFT			5
-#define AM33XX_ENFUNC3_EXPORT_MASK			(1 << 5)
-
-/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */
-#define AM33XX_ENFUNC4_SHIFT				6
-#define AM33XX_ENFUNC4_MASK				(1 << 6)
-
-/* Used by PRM_LDO_SRAM_CORE_SETUP, PRM_LDO_SRAM_MPU_SETUP */
-#define AM33XX_ENFUNC5_SHIFT				7
-#define AM33XX_ENFUNC5_MASK				(1 << 7)
-
-/* Used by PRM_RSTST */
-#define AM33XX_EXTERNAL_WARM_RST_SHIFT			5
-#define AM33XX_EXTERNAL_WARM_RST_MASK			(1 << 5)
-
-/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */
-#define AM33XX_FORCEWKUP_EN_SHIFT			10
-#define AM33XX_FORCEWKUP_EN_MASK			(1 << 10)
-
-/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */
-#define AM33XX_FORCEWKUP_ST_SHIFT			10
-#define AM33XX_FORCEWKUP_ST_MASK			(1 << 10)
-
-/* Used by PM_GFX_PWRSTCTRL */
-#define AM33XX_GFX_MEM_ONSTATE_SHIFT			17
 #define AM33XX_GFX_MEM_ONSTATE_MASK			(0x3 << 17)
-
-/* Used by PM_GFX_PWRSTCTRL */
-#define AM33XX_GFX_MEM_RETSTATE_SHIFT			6
 #define AM33XX_GFX_MEM_RETSTATE_MASK			(1 << 6)
-
-/* Used by PM_GFX_PWRSTST */
-#define AM33XX_GFX_MEM_STATEST_SHIFT			4
 #define AM33XX_GFX_MEM_STATEST_MASK			(0x3 << 4)
-
-/* Used by RM_GFX_RSTCTRL, RM_GFX_RSTST */
-#define AM33XX_GFX_RST_SHIFT				0
-#define AM33XX_GFX_RST_MASK				(1 << 0)
-
-/* Used by PRM_RSTST */
-#define AM33XX_GLOBAL_COLD_RST_SHIFT			0
-#define AM33XX_GLOBAL_COLD_RST_MASK			(1 << 0)
-
-/* Used by PRM_RSTST */
-#define AM33XX_GLOBAL_WARM_SW_RST_SHIFT			1
 #define AM33XX_GLOBAL_WARM_SW_RST_MASK			(1 << 1)
-
-/* Used by RM_WKUP_RSTST */
-#define AM33XX_ICECRUSHER_M3_RST_SHIFT			7
-#define AM33XX_ICECRUSHER_M3_RST_MASK			(1 << 7)
-
-/* Used by RM_MPU_RSTST */
-#define AM33XX_ICECRUSHER_MPU_RST_SHIFT			6
-#define AM33XX_ICECRUSHER_MPU_RST_MASK			(1 << 6)
-
-/* Used by PRM_RSTST */
-#define AM33XX_ICEPICK_RST_SHIFT			9
-#define AM33XX_ICEPICK_RST_MASK				(1 << 9)
-
-/* Used by RM_PER_RSTCTRL */
-#define AM33XX_PRUSS_LRST_SHIFT				1
-#define AM33XX_PRUSS_LRST_MASK				(1 << 1)
-
-/* Used by PM_PER_PWRSTCTRL */
-#define AM33XX_PRUSS_MEM_ONSTATE_SHIFT			5
 #define AM33XX_PRUSS_MEM_ONSTATE_MASK			(0x3 << 5)
-
-/* Used by PM_PER_PWRSTCTRL */
-#define AM33XX_PRUSS_MEM_RETSTATE_SHIFT			7
 #define AM33XX_PRUSS_MEM_RETSTATE_MASK			(1 << 7)
-
-/* Used by PM_PER_PWRSTST */
-#define AM33XX_PRUSS_MEM_STATEST_SHIFT			23
 #define AM33XX_PRUSS_MEM_STATEST_MASK			(0x3 << 23)
-
-/*
- * Used by PM_GFX_PWRSTST, PM_CEFUSE_PWRSTST, PM_PER_PWRSTST, PM_MPU_PWRSTST,
- * PM_WKUP_PWRSTST, PM_RTC_PWRSTST
- */
-#define AM33XX_INTRANSITION_SHIFT			20
-#define AM33XX_INTRANSITION_MASK			(1 << 20)
-
-/* Used by PM_CEFUSE_PWRSTST */
 #define AM33XX_LASTPOWERSTATEENTERED_SHIFT		24
 #define AM33XX_LASTPOWERSTATEENTERED_MASK		(0x3 << 24)
-
-/* Used by PM_GFX_PWRSTCTRL, PM_MPU_PWRSTCTRL, PM_RTC_PWRSTCTRL */
-#define AM33XX_LOGICRETSTATE_SHIFT			2
 #define AM33XX_LOGICRETSTATE_MASK			(1 << 2)
-
-/* Renamed from LOGICRETSTATE Used by PM_PER_PWRSTCTRL, PM_WKUP_PWRSTCTRL */
-#define AM33XX_LOGICRETSTATE_3_3_SHIFT			3
 #define AM33XX_LOGICRETSTATE_3_3_MASK			(1 << 3)
-
-/*
- * Used by PM_GFX_PWRSTST, PM_CEFUSE_PWRSTST, PM_PER_PWRSTST, PM_MPU_PWRSTST,
- * PM_WKUP_PWRSTST, PM_RTC_PWRSTST
- */
 #define AM33XX_LOGICSTATEST_SHIFT			2
 #define AM33XX_LOGICSTATEST_MASK			(1 << 2)
-
-/*
- * Used by PM_GFX_PWRSTCTRL, PM_CEFUSE_PWRSTCTRL, PM_PER_PWRSTCTRL,
- * PM_MPU_PWRSTCTRL, PM_WKUP_PWRSTCTRL, PM_RTC_PWRSTCTRL
- */
 #define AM33XX_LOWPOWERSTATECHANGE_SHIFT		4
 #define AM33XX_LOWPOWERSTATECHANGE_MASK			(1 << 4)
-
-/* Used by PM_MPU_PWRSTCTRL */
-#define AM33XX_MPU_L1_ONSTATE_SHIFT			18
 #define AM33XX_MPU_L1_ONSTATE_MASK			(0x3 << 18)
-
-/* Used by PM_MPU_PWRSTCTRL */
-#define AM33XX_MPU_L1_RETSTATE_SHIFT			22
 #define AM33XX_MPU_L1_RETSTATE_MASK			(1 << 22)
-
-/* Used by PM_MPU_PWRSTST */
-#define AM33XX_MPU_L1_STATEST_SHIFT			6
 #define AM33XX_MPU_L1_STATEST_MASK			(0x3 << 6)
-
-/* Used by PM_MPU_PWRSTCTRL */
-#define AM33XX_MPU_L2_ONSTATE_SHIFT			20
 #define AM33XX_MPU_L2_ONSTATE_MASK			(0x3 << 20)
-
-/* Used by PM_MPU_PWRSTCTRL */
-#define AM33XX_MPU_L2_RETSTATE_SHIFT			23
 #define AM33XX_MPU_L2_RETSTATE_MASK			(1 << 23)
-
-/* Used by PM_MPU_PWRSTST */
-#define AM33XX_MPU_L2_STATEST_SHIFT			8
 #define AM33XX_MPU_L2_STATEST_MASK			(0x3 << 8)
-
-/* Used by PM_MPU_PWRSTCTRL */
-#define AM33XX_MPU_RAM_ONSTATE_SHIFT			16
 #define AM33XX_MPU_RAM_ONSTATE_MASK			(0x3 << 16)
-
-/* Used by PM_MPU_PWRSTCTRL */
-#define AM33XX_MPU_RAM_RETSTATE_SHIFT			24
 #define AM33XX_MPU_RAM_RETSTATE_MASK			(1 << 24)
-
-/* Used by PM_MPU_PWRSTST */
-#define AM33XX_MPU_RAM_STATEST_SHIFT			4
 #define AM33XX_MPU_RAM_STATEST_MASK			(0x3 << 4)
-
-/* Used by PRM_RSTST */
-#define AM33XX_MPU_SECURITY_VIOL_RST_SHIFT		2
-#define AM33XX_MPU_SECURITY_VIOL_RST_MASK		(1 << 2)
-
-/* Used by PRM_SRAM_COUNT */
-#define AM33XX_PCHARGECNT_VALUE_SHIFT			0
-#define AM33XX_PCHARGECNT_VALUE_MASK			(0x3f << 0)
-
-/* Used by RM_PER_RSTCTRL */
-#define AM33XX_PCI_LRST_SHIFT				0
-#define AM33XX_PCI_LRST_MASK				(1 << 0)
-
-/* Renamed from PCI_LRST Used by RM_PER_RSTST */
-#define AM33XX_PCI_LRST_5_5_SHIFT			5
-#define AM33XX_PCI_LRST_5_5_MASK			(1 << 5)
-
-/* Used by PM_PER_PWRSTCTRL */
-#define AM33XX_PER_MEM_ONSTATE_SHIFT			25
 #define AM33XX_PER_MEM_ONSTATE_MASK			(0x3 << 25)
-
-/* Used by PM_PER_PWRSTCTRL */
-#define AM33XX_PER_MEM_RETSTATE_SHIFT			29
 #define AM33XX_PER_MEM_RETSTATE_MASK			(1 << 29)
-
-/* Used by PM_PER_PWRSTST */
-#define AM33XX_PER_MEM_STATEST_SHIFT			17
 #define AM33XX_PER_MEM_STATEST_MASK			(0x3 << 17)
-
-/*
- * Used by PM_GFX_PWRSTCTRL, PM_CEFUSE_PWRSTCTRL, PM_PER_PWRSTCTRL,
- * PM_MPU_PWRSTCTRL
- */
-#define AM33XX_POWERSTATE_SHIFT				0
-#define AM33XX_POWERSTATE_MASK				(0x3 << 0)
-
-/* Used by PM_GFX_PWRSTST, PM_CEFUSE_PWRSTST, PM_PER_PWRSTST, PM_MPU_PWRSTST */
-#define AM33XX_POWERSTATEST_SHIFT			0
-#define AM33XX_POWERSTATEST_MASK			(0x3 << 0)
-
-/* Used by PM_PER_PWRSTCTRL */
-#define AM33XX_RAM_MEM_ONSTATE_SHIFT			30
 #define AM33XX_RAM_MEM_ONSTATE_MASK			(0x3 << 30)
-
-/* Used by PM_PER_PWRSTCTRL */
-#define AM33XX_RAM_MEM_RETSTATE_SHIFT			27
 #define AM33XX_RAM_MEM_RETSTATE_MASK			(1 << 27)
-
-/* Used by PM_PER_PWRSTST */
-#define AM33XX_RAM_MEM_STATEST_SHIFT			21
 #define AM33XX_RAM_MEM_STATEST_MASK			(0x3 << 21)
-
-/* Used by PRM_LDO_SRAM_CORE_CTRL, PRM_LDO_SRAM_MPU_CTRL */
-#define AM33XX_RETMODE_ENABLE_SHIFT			0
-#define AM33XX_RETMODE_ENABLE_MASK			(1 << 0)
-
-/* Used by REVISION_PRM */
-#define AM33XX_REV_SHIFT				0
-#define AM33XX_REV_MASK					(0xff << 0)
-
-/* Used by PRM_RSTTIME */
-#define AM33XX_RSTTIME1_SHIFT				0
-#define AM33XX_RSTTIME1_MASK				(0xff << 0)
-
-/* Used by PRM_RSTTIME */
-#define AM33XX_RSTTIME2_SHIFT				8
-#define AM33XX_RSTTIME2_MASK				(0x1f << 8)
-
-/* Used by PRM_RSTCTRL */
-#define AM33XX_RST_GLOBAL_COLD_SW_SHIFT			1
-#define AM33XX_RST_GLOBAL_COLD_SW_MASK			(1 << 1)
-
-/* Used by PRM_RSTCTRL */
-#define AM33XX_RST_GLOBAL_WARM_SW_SHIFT			0
-#define AM33XX_RST_GLOBAL_WARM_SW_MASK			(1 << 0)
-
-/* Used by PRM_SRAM_COUNT */
-#define AM33XX_SLPCNT_VALUE_SHIFT			16
-#define AM33XX_SLPCNT_VALUE_MASK			(0xff << 16)
-
-/* Used by PRM_LDO_SRAM_CORE_CTRL, PRM_LDO_SRAM_MPU_CTRL */
-#define AM33XX_SRAMLDO_STATUS_SHIFT			8
-#define AM33XX_SRAMLDO_STATUS_MASK			(1 << 8)
-
-/* Used by PRM_LDO_SRAM_CORE_CTRL, PRM_LDO_SRAM_MPU_CTRL */
-#define AM33XX_SRAM_IN_TRANSITION_SHIFT			9
-#define AM33XX_SRAM_IN_TRANSITION_MASK			(1 << 9)
-
-/* Used by PRM_SRAM_COUNT */
-#define AM33XX_STARTUP_COUNT_SHIFT			24
-#define AM33XX_STARTUP_COUNT_MASK			(0xff << 24)
-
-/* Used by PRM_IRQENABLE_M3, PRM_IRQENABLE_MPU */
-#define AM33XX_TRANSITION_EN_SHIFT			8
-#define AM33XX_TRANSITION_EN_MASK			(1 << 8)
-
-/* Used by PRM_IRQSTATUS_M3, PRM_IRQSTATUS_MPU */
-#define AM33XX_TRANSITION_ST_SHIFT			8
-#define AM33XX_TRANSITION_ST_MASK			(1 << 8)
-
-/* Used by PRM_SRAM_COUNT */
-#define AM33XX_VSETUPCNT_VALUE_SHIFT			8
-#define AM33XX_VSETUPCNT_VALUE_MASK			(0xff << 8)
-
-/* Used by PRM_RSTST */
-#define AM33XX_WDT0_RST_SHIFT				3
-#define AM33XX_WDT0_RST_MASK				(1 << 3)
-
-/* Used by PRM_RSTST */
-#define AM33XX_WDT1_RST_SHIFT				4
-#define AM33XX_WDT1_RST_MASK				(1 << 4)
-
-/* Used by RM_WKUP_RSTCTRL */
-#define AM33XX_WKUP_M3_LRST_SHIFT			3
-#define AM33XX_WKUP_M3_LRST_MASK			(1 << 3)
-
-/* Renamed from WKUP_M3_LRST Used by RM_WKUP_RSTST */
-#define AM33XX_WKUP_M3_LRST_5_5_SHIFT			5
-#define AM33XX_WKUP_M3_LRST_5_5_MASK			(1 << 5)
-
 #endif
diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h b/arch/arm/mach-omap2/prm-regbits-34xx.h
index b0a2142..cebad56 100644
--- a/arch/arm/mach-omap2/prm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-34xx.h
@@ -16,115 +16,25 @@
 
 #include "prm3xxx.h"
 
-/* Shared register bits */
-
-/* PRM_VC_CMD_VAL_0, PRM_VC_CMD_VAL_1 shared bits */
-#define OMAP3430_ON_SHIFT				24
-#define OMAP3430_ON_MASK				(0xff << 24)
-#define OMAP3430_ONLP_SHIFT				16
-#define OMAP3430_ONLP_MASK				(0xff << 16)
-#define OMAP3430_RET_SHIFT				8
-#define OMAP3430_RET_MASK				(0xff << 8)
-#define OMAP3430_OFF_SHIFT				0
-#define OMAP3430_OFF_MASK				(0xff << 0)
-
-/* PRM_VP1_CONFIG, PRM_VP2_CONFIG shared bits */
-#define OMAP3430_ERROROFFSET_SHIFT			24
 #define OMAP3430_ERROROFFSET_MASK			(0xff << 24)
-#define OMAP3430_ERRORGAIN_SHIFT			16
 #define OMAP3430_ERRORGAIN_MASK				(0xff << 16)
-#define OMAP3430_INITVOLTAGE_SHIFT			8
 #define OMAP3430_INITVOLTAGE_MASK			(0xff << 8)
 #define OMAP3430_TIMEOUTEN_MASK				(1 << 3)
 #define OMAP3430_INITVDD_MASK				(1 << 2)
 #define OMAP3430_FORCEUPDATE_MASK			(1 << 1)
 #define OMAP3430_VPENABLE_MASK				(1 << 0)
-
-/* PRM_VP1_VSTEPMIN, PRM_VP2_VSTEPMIN shared bits */
 #define OMAP3430_SMPSWAITTIMEMIN_SHIFT			8
-#define OMAP3430_SMPSWAITTIMEMIN_MASK			(0xffff << 8)
 #define OMAP3430_VSTEPMIN_SHIFT				0
-#define OMAP3430_VSTEPMIN_MASK				(0xff << 0)
-
-/* PRM_VP1_VSTEPMAX, PRM_VP2_VSTEPMAX shared bits */
 #define OMAP3430_SMPSWAITTIMEMAX_SHIFT			8
-#define OMAP3430_SMPSWAITTIMEMAX_MASK			(0xffff << 8)
 #define OMAP3430_VSTEPMAX_SHIFT				0
-#define OMAP3430_VSTEPMAX_MASK				(0xff << 0)
-
-/* PRM_VP1_VLIMITTO, PRM_VP2_VLIMITTO shared bits */
 #define OMAP3430_VDDMAX_SHIFT				24
-#define OMAP3430_VDDMAX_MASK				(0xff << 24)
 #define OMAP3430_VDDMIN_SHIFT				16
-#define OMAP3430_VDDMIN_MASK				(0xff << 16)
 #define OMAP3430_TIMEOUT_SHIFT				0
-#define OMAP3430_TIMEOUT_MASK				(0xffff << 0)
-
-/* PRM_VP1_VOLTAGE, PRM_VP2_VOLTAGE shared bits */
-#define OMAP3430_VPVOLTAGE_SHIFT			0
 #define OMAP3430_VPVOLTAGE_MASK				(0xff << 0)
-
-/* PRM_VP1_STATUS, PRM_VP2_STATUS shared bits */
-#define OMAP3430_VPINIDLE_MASK				(1 << 0)
-
-/* PM_WKDEP_IVA2, PM_WKDEP_MPU shared bits */
 #define OMAP3430_EN_PER_SHIFT				7
-#define OMAP3430_EN_PER_MASK				(1 << 7)
-
-/* PM_PWSTCTRL_IVA2, PM_PWSTCTRL_MPU, PM_PWSTCTRL_CORE shared bits */
-#define OMAP3430_MEMORYCHANGE_MASK			(1 << 3)
-
-/* PM_PWSTST_IVA2, PM_PWSTST_CORE shared bits */
 #define OMAP3430_LOGICSTATEST_MASK			(1 << 2)
-
-/* PM_PREPWSTST_IVA2, PM_PREPWSTST_CORE shared bits */
 #define OMAP3430_LASTLOGICSTATEENTERED_MASK		(1 << 2)
-
-/*
- * PM_PREPWSTST_IVA2, PM_PREPWSTST_MPU, PM_PREPWSTST_CORE,
- * PM_PREPWSTST_GFX, PM_PREPWSTST_DSS, PM_PREPWSTST_CAM,
- * PM_PREPWSTST_PER, PM_PREPWSTST_NEON shared bits
- */
-#define OMAP3430_LASTPOWERSTATEENTERED_SHIFT		0
 #define OMAP3430_LASTPOWERSTATEENTERED_MASK		(0x3 << 0)
-
-/* PRM_IRQSTATUS_IVA2, PRM_IRQSTATUS_MPU shared bits */
-#define OMAP3430_WKUP_ST_MASK				(1 << 0)
-
-/* PRM_IRQENABLE_IVA2, PRM_IRQENABLE_MPU shared bits */
-#define OMAP3430_WKUP_EN_MASK				(1 << 0)
-
-/* PM_MPUGRPSEL1_CORE, PM_IVA2GRPSEL1_CORE shared bits */
-#define OMAP3430_GRPSEL_MMC2_MASK			(1 << 25)
-#define OMAP3430_GRPSEL_MMC1_MASK			(1 << 24)
-#define OMAP3430_GRPSEL_MCSPI4_MASK			(1 << 21)
-#define OMAP3430_GRPSEL_MCSPI3_MASK			(1 << 20)
-#define OMAP3430_GRPSEL_MCSPI2_MASK			(1 << 19)
-#define OMAP3430_GRPSEL_MCSPI1_MASK			(1 << 18)
-#define OMAP3430_GRPSEL_I2C3_SHIFT			17
-#define OMAP3430_GRPSEL_I2C3_MASK			(1 << 17)
-#define OMAP3430_GRPSEL_I2C2_SHIFT			16
-#define OMAP3430_GRPSEL_I2C2_MASK			(1 << 16)
-#define OMAP3430_GRPSEL_I2C1_SHIFT			15
-#define OMAP3430_GRPSEL_I2C1_MASK			(1 << 15)
-#define OMAP3430_GRPSEL_UART2_MASK			(1 << 14)
-#define OMAP3430_GRPSEL_UART1_MASK			(1 << 13)
-#define OMAP3430_GRPSEL_GPT11_MASK			(1 << 12)
-#define OMAP3430_GRPSEL_GPT10_MASK			(1 << 11)
-#define OMAP3430_GRPSEL_MCBSP5_MASK			(1 << 10)
-#define OMAP3430_GRPSEL_MCBSP1_MASK			(1 << 9)
-#define OMAP3430_GRPSEL_HSOTGUSB_MASK			(1 << 4)
-#define OMAP3430_GRPSEL_D2D_MASK			(1 << 3)
-
-/*
- * PM_PWSTCTRL_GFX, PM_PWSTCTRL_DSS, PM_PWSTCTRL_CAM,
- * PM_PWSTCTRL_PER shared bits
- */
-#define OMAP3430_MEMONSTATE_SHIFT			16
-#define OMAP3430_MEMONSTATE_MASK			(0x3 << 16)
-#define OMAP3430_MEMRETSTATE_MASK			(1 << 8)
-
-/* PM_MPUGRPSEL_PER, PM_IVA2GRPSEL_PER shared bits */
 #define OMAP3630_GRPSEL_UART4_MASK			(1 << 18)
 #define OMAP3430_GRPSEL_GPIO6_MASK			(1 << 17)
 #define OMAP3430_GRPSEL_GPIO5_MASK			(1 << 16)
@@ -132,480 +42,89 @@
 #define OMAP3430_GRPSEL_GPIO3_MASK			(1 << 14)
 #define OMAP3430_GRPSEL_GPIO2_MASK			(1 << 13)
 #define OMAP3430_GRPSEL_UART3_MASK			(1 << 11)
-#define OMAP3430_GRPSEL_GPT9_MASK			(1 << 10)
-#define OMAP3430_GRPSEL_GPT8_MASK			(1 << 9)
-#define OMAP3430_GRPSEL_GPT7_MASK			(1 << 8)
-#define OMAP3430_GRPSEL_GPT6_MASK			(1 << 7)
-#define OMAP3430_GRPSEL_GPT5_MASK			(1 << 6)
-#define OMAP3430_GRPSEL_GPT4_MASK			(1 << 5)
-#define OMAP3430_GRPSEL_GPT3_MASK			(1 << 4)
-#define OMAP3430_GRPSEL_GPT2_MASK			(1 << 3)
 #define OMAP3430_GRPSEL_MCBSP4_MASK			(1 << 2)
 #define OMAP3430_GRPSEL_MCBSP3_MASK			(1 << 1)
 #define OMAP3430_GRPSEL_MCBSP2_MASK			(1 << 0)
-
-/* PM_MPUGRPSEL_WKUP, PM_IVA2GRPSEL_WKUP shared bits */
-#define OMAP3430_GRPSEL_IO_MASK				(1 << 8)
-#define OMAP3430_GRPSEL_SR2_MASK			(1 << 7)
-#define OMAP3430_GRPSEL_SR1_MASK			(1 << 6)
 #define OMAP3430_GRPSEL_GPIO1_MASK			(1 << 3)
 #define OMAP3430_GRPSEL_GPT12_MASK			(1 << 1)
 #define OMAP3430_GRPSEL_GPT1_MASK			(1 << 0)
-
-/* Bits specific to each register */
-
-/* RM_RSTCTRL_IVA2 */
 #define OMAP3430_RST3_IVA2_MASK				(1 << 2)
 #define OMAP3430_RST2_IVA2_MASK				(1 << 1)
 #define OMAP3430_RST1_IVA2_MASK				(1 << 0)
-
-/* RM_RSTST_IVA2 specific bits */
-#define OMAP3430_EMULATION_VSEQ_RST_MASK		(1 << 13)
-#define OMAP3430_EMULATION_VHWA_RST_MASK		(1 << 12)
-#define OMAP3430_EMULATION_IVA2_RST_MASK		(1 << 11)
-#define OMAP3430_IVA2_SW_RST3_MASK			(1 << 10)
-#define OMAP3430_IVA2_SW_RST2_MASK			(1 << 9)
-#define OMAP3430_IVA2_SW_RST1_MASK			(1 << 8)
-
-/* PM_WKDEP_IVA2 specific bits */
-
-/* PM_PWSTCTRL_IVA2 specific bits */
-#define OMAP3430_L2FLATMEMONSTATE_SHIFT			22
 #define OMAP3430_L2FLATMEMONSTATE_MASK			(0x3 << 22)
-#define OMAP3430_SHAREDL2CACHEFLATONSTATE_SHIFT		20
 #define OMAP3430_SHAREDL2CACHEFLATONSTATE_MASK		(0x3 << 20)
-#define OMAP3430_L1FLATMEMONSTATE_SHIFT			18
 #define OMAP3430_L1FLATMEMONSTATE_MASK			(0x3 << 18)
-#define OMAP3430_SHAREDL1CACHEFLATONSTATE_SHIFT		16
 #define OMAP3430_SHAREDL1CACHEFLATONSTATE_MASK		(0x3 << 16)
 #define OMAP3430_L2FLATMEMRETSTATE_MASK			(1 << 11)
 #define OMAP3430_SHAREDL2CACHEFLATRETSTATE_MASK		(1 << 10)
 #define OMAP3430_L1FLATMEMRETSTATE_MASK			(1 << 9)
 #define OMAP3430_SHAREDL1CACHEFLATRETSTATE_MASK		(1 << 8)
-
-/* PM_PWSTST_IVA2 specific bits */
-#define OMAP3430_L2FLATMEMSTATEST_SHIFT			10
 #define OMAP3430_L2FLATMEMSTATEST_MASK			(0x3 << 10)
-#define OMAP3430_SHAREDL2CACHEFLATSTATEST_SHIFT		8
 #define OMAP3430_SHAREDL2CACHEFLATSTATEST_MASK		(0x3 << 8)
-#define OMAP3430_L1FLATMEMSTATEST_SHIFT			6
 #define OMAP3430_L1FLATMEMSTATEST_MASK			(0x3 << 6)
-#define OMAP3430_SHAREDL1CACHEFLATSTATEST_SHIFT		4
 #define OMAP3430_SHAREDL1CACHEFLATSTATEST_MASK		(0x3 << 4)
-
-/* PM_PREPWSTST_IVA2 specific bits */
-#define OMAP3430_LASTL2FLATMEMSTATEENTERED_SHIFT		10
 #define OMAP3430_LASTL2FLATMEMSTATEENTERED_MASK			(0x3 << 10)
-#define OMAP3430_LASTSHAREDL2CACHEFLATSTATEENTERED_SHIFT	8
 #define OMAP3430_LASTSHAREDL2CACHEFLATSTATEENTERED_MASK		(0x3 << 8)
-#define OMAP3430_LASTL1FLATMEMSTATEENTERED_SHIFT		6
-#define OMAP3430_LASTL1FLATMEMSTATEENTERED_MASK			(0x3 << 6)
-#define OMAP3430_LASTSHAREDL1CACHEFLATSTATEENTERED_SHIFT	4
-#define OMAP3430_LASTSHAREDL1CACHEFLATSTATEENTERED_MASK		(0x3 << 4)
-
-/* PRM_IRQSTATUS_IVA2 specific bits */
-#define OMAP3430_PRM_IRQSTATUS_IVA2_IVA2_DPLL_ST_MASK	(1 << 2)
-#define OMAP3430_FORCEWKUP_ST_MASK			(1 << 1)
-
-/* PRM_IRQENABLE_IVA2 specific bits */
-#define OMAP3430_PRM_IRQENABLE_IVA2_IVA2_DPLL_RECAL_EN_MASK	(1 << 2)
-#define OMAP3430_FORCEWKUP_EN_MASK				(1 << 1)
-
-/* PRM_REVISION specific bits */
-
-/* PRM_SYSCONFIG specific bits */
-
-/* PRM_IRQSTATUS_MPU specific bits */
 #define OMAP3430ES2_SND_PERIPH_DPLL_ST_SHIFT		25
-#define OMAP3430ES2_SND_PERIPH_DPLL_ST_MASK		(1 << 25)
-#define OMAP3430_VC_TIMEOUTERR_ST_MASK			(1 << 24)
-#define OMAP3430_VC_RAERR_ST_MASK			(1 << 23)
-#define OMAP3430_VC_SAERR_ST_MASK			(1 << 22)
 #define OMAP3430_VP2_TRANXDONE_ST_MASK			(1 << 21)
-#define OMAP3430_VP2_EQVALUE_ST_MASK			(1 << 20)
-#define OMAP3430_VP2_NOSMPSACK_ST_MASK			(1 << 19)
-#define OMAP3430_VP2_MAXVDD_ST_MASK			(1 << 18)
-#define OMAP3430_VP2_MINVDD_ST_MASK			(1 << 17)
-#define OMAP3430_VP2_OPPCHANGEDONE_ST_MASK		(1 << 16)
 #define OMAP3430_VP1_TRANXDONE_ST_MASK			(1 << 15)
-#define OMAP3430_VP1_EQVALUE_ST_MASK			(1 << 14)
-#define OMAP3430_VP1_NOSMPSACK_ST_MASK			(1 << 13)
-#define OMAP3430_VP1_MAXVDD_ST_MASK			(1 << 12)
-#define OMAP3430_VP1_MINVDD_ST_MASK			(1 << 11)
-#define OMAP3430_VP1_OPPCHANGEDONE_ST_MASK		(1 << 10)
-#define OMAP3430_IO_ST_MASK				(1 << 9)
-#define OMAP3430_PRM_IRQSTATUS_MPU_IVA2_DPLL_ST_MASK	(1 << 8)
 #define OMAP3430_PRM_IRQSTATUS_MPU_IVA2_DPLL_ST_SHIFT	8
-#define OMAP3430_MPU_DPLL_ST_MASK			(1 << 7)
 #define OMAP3430_MPU_DPLL_ST_SHIFT			7
-#define OMAP3430_PERIPH_DPLL_ST_MASK			(1 << 6)
 #define OMAP3430_PERIPH_DPLL_ST_SHIFT			6
-#define OMAP3430_CORE_DPLL_ST_MASK			(1 << 5)
 #define OMAP3430_CORE_DPLL_ST_SHIFT			5
-#define OMAP3430_TRANSITION_ST_MASK			(1 << 4)
-#define OMAP3430_EVGENOFF_ST_MASK			(1 << 3)
-#define OMAP3430_EVGENON_ST_MASK			(1 << 2)
-#define OMAP3430_FS_USB_WKUP_ST_MASK			(1 << 1)
-
-/* PRM_IRQENABLE_MPU specific bits */
 #define OMAP3430ES2_SND_PERIPH_DPLL_RECAL_EN_SHIFT		25
-#define OMAP3430ES2_SND_PERIPH_DPLL_RECAL_EN_MASK		(1 << 25)
-#define OMAP3430_VC_TIMEOUTERR_EN_MASK				(1 << 24)
-#define OMAP3430_VC_RAERR_EN_MASK				(1 << 23)
-#define OMAP3430_VC_SAERR_EN_MASK				(1 << 22)
-#define OMAP3430_VP2_TRANXDONE_EN_MASK				(1 << 21)
-#define OMAP3430_VP2_EQVALUE_EN_MASK				(1 << 20)
-#define OMAP3430_VP2_NOSMPSACK_EN_MASK				(1 << 19)
-#define OMAP3430_VP2_MAXVDD_EN_MASK				(1 << 18)
-#define OMAP3430_VP2_MINVDD_EN_MASK				(1 << 17)
-#define OMAP3430_VP2_OPPCHANGEDONE_EN_MASK			(1 << 16)
-#define OMAP3430_VP1_TRANXDONE_EN_MASK				(1 << 15)
-#define OMAP3430_VP1_EQVALUE_EN_MASK				(1 << 14)
-#define OMAP3430_VP1_NOSMPSACK_EN_MASK				(1 << 13)
-#define OMAP3430_VP1_MAXVDD_EN_MASK				(1 << 12)
-#define OMAP3430_VP1_MINVDD_EN_MASK				(1 << 11)
-#define OMAP3430_VP1_OPPCHANGEDONE_EN_MASK			(1 << 10)
-#define OMAP3430_IO_EN_MASK					(1 << 9)
-#define OMAP3430_PRM_IRQENABLE_MPU_IVA2_DPLL_RECAL_EN_MASK	(1 << 8)
 #define OMAP3430_PRM_IRQENABLE_MPU_IVA2_DPLL_RECAL_EN_SHIFT	8
-#define OMAP3430_MPU_DPLL_RECAL_EN_MASK				(1 << 7)
 #define OMAP3430_MPU_DPLL_RECAL_EN_SHIFT			7
-#define OMAP3430_PERIPH_DPLL_RECAL_EN_MASK			(1 << 6)
 #define OMAP3430_PERIPH_DPLL_RECAL_EN_SHIFT			6
-#define OMAP3430_CORE_DPLL_RECAL_EN_MASK			(1 << 5)
 #define OMAP3430_CORE_DPLL_RECAL_EN_SHIFT			5
-#define OMAP3430_TRANSITION_EN_MASK				(1 << 4)
-#define OMAP3430_EVGENOFF_EN_MASK				(1 << 3)
-#define OMAP3430_EVGENON_EN_MASK				(1 << 2)
-#define OMAP3430_FS_USB_WKUP_EN_MASK				(1 << 1)
-
-/* RM_RSTST_MPU specific bits */
-#define OMAP3430_EMULATION_MPU_RST_MASK			(1 << 11)
-
-/* PM_WKDEP_MPU specific bits */
 #define OMAP3430_PM_WKDEP_MPU_EN_DSS_SHIFT		5
-#define OMAP3430_PM_WKDEP_MPU_EN_DSS_MASK		(1 << 5)
 #define OMAP3430_PM_WKDEP_MPU_EN_IVA2_SHIFT		2
-#define OMAP3430_PM_WKDEP_MPU_EN_IVA2_MASK		(1 << 2)
-
-/* PM_EVGENCTRL_MPU */
-#define OMAP3430_OFFLOADMODE_SHIFT			3
-#define OMAP3430_OFFLOADMODE_MASK			(0x3 << 3)
-#define OMAP3430_ONLOADMODE_SHIFT			1
-#define OMAP3430_ONLOADMODE_MASK			(0x3 << 1)
-#define OMAP3430_ENABLE_MASK				(1 << 0)
-
-/* PM_EVGENONTIM_MPU */
-#define OMAP3430_ONTIMEVAL_SHIFT			0
-#define OMAP3430_ONTIMEVAL_MASK				(0xffffffff << 0)
-
-/* PM_EVGENOFFTIM_MPU */
-#define OMAP3430_OFFTIMEVAL_SHIFT			0
-#define OMAP3430_OFFTIMEVAL_MASK			(0xffffffff << 0)
-
-/* PM_PWSTCTRL_MPU specific bits */
-#define OMAP3430_L2CACHEONSTATE_SHIFT			16
-#define OMAP3430_L2CACHEONSTATE_MASK			(0x3 << 16)
-#define OMAP3430_L2CACHERETSTATE_MASK			(1 << 8)
-#define OMAP3430_LOGICL1CACHERETSTATE_MASK		(1 << 2)
-
-/* PM_PWSTST_MPU specific bits */
-#define OMAP3430_L2CACHESTATEST_SHIFT			6
-#define OMAP3430_L2CACHESTATEST_MASK			(0x3 << 6)
-#define OMAP3430_LOGICL1CACHESTATEST_MASK		(1 << 2)
-
-/* PM_PREPWSTST_MPU specific bits */
-#define OMAP3430_LASTL2CACHESTATEENTERED_SHIFT		6
-#define OMAP3430_LASTL2CACHESTATEENTERED_MASK		(0x3 << 6)
-#define OMAP3430_LASTLOGICL1CACHESTATEENTERED_MASK	(1 << 2)
-
-/* RM_RSTCTRL_CORE */
 #define OMAP3430_RM_RSTCTRL_CORE_MODEM_SW_RSTPWRON_MASK		(1 << 1)
 #define OMAP3430_RM_RSTCTRL_CORE_MODEM_SW_RST_MASK		(1 << 0)
-
-/* RM_RSTST_CORE specific bits */
-#define OMAP3430_MODEM_SECURITY_VIOL_RST_MASK		(1 << 10)
-#define OMAP3430_RM_RSTST_CORE_MODEM_SW_RSTPWRON_MASK	(1 << 9)
-#define OMAP3430_RM_RSTST_CORE_MODEM_SW_RST_MASK	(1 << 8)
-
-/* PM_WKEN1_CORE specific bits */
-
-/* PM_MPUGRPSEL1_CORE specific bits */
-#define OMAP3430_GRPSEL_FSHOSTUSB_MASK			(1 << 5)
-
-/* PM_IVA2GRPSEL1_CORE specific bits */
-
-/* PM_WKST1_CORE specific bits */
-
-/* PM_PWSTCTRL_CORE specific bits */
-#define OMAP3430_MEM2ONSTATE_SHIFT			18
-#define OMAP3430_MEM2ONSTATE_MASK			(0x3 << 18)
-#define OMAP3430_MEM1ONSTATE_SHIFT			16
-#define OMAP3430_MEM1ONSTATE_MASK			(0x3 << 16)
-#define OMAP3430_MEM2RETSTATE_MASK			(1 << 9)
-#define OMAP3430_MEM1RETSTATE_MASK			(1 << 8)
-
-/* PM_PWSTST_CORE specific bits */
-#define OMAP3430_MEM2STATEST_SHIFT			6
-#define OMAP3430_MEM2STATEST_MASK			(0x3 << 6)
-#define OMAP3430_MEM1STATEST_SHIFT			4
-#define OMAP3430_MEM1STATEST_MASK			(0x3 << 4)
-
-/* PM_PREPWSTST_CORE specific bits */
-#define OMAP3430_LASTMEM2STATEENTERED_SHIFT		6
 #define OMAP3430_LASTMEM2STATEENTERED_MASK		(0x3 << 6)
-#define OMAP3430_LASTMEM1STATEENTERED_SHIFT		4
 #define OMAP3430_LASTMEM1STATEENTERED_MASK		(0x3 << 4)
-
-/* RM_RSTST_GFX specific bits */
-
-/* PM_WKDEP_GFX specific bits */
-#define OMAP3430_PM_WKDEP_GFX_EN_IVA2_MASK		(1 << 2)
-
-/* PM_PWSTCTRL_GFX specific bits */
-
-/* PM_PWSTST_GFX specific bits */
-
-/* PM_PREPWSTST_GFX specific bits */
-
-/* PM_WKEN_WKUP specific bits */
 #define OMAP3430_EN_IO_CHAIN_MASK			(1 << 16)
 #define OMAP3430_EN_IO_MASK				(1 << 8)
 #define OMAP3430_EN_GPIO1_MASK				(1 << 3)
-
-/* PM_MPUGRPSEL_WKUP specific bits */
-
-/* PM_IVA2GRPSEL_WKUP specific bits */
-
-/* PM_WKST_WKUP specific bits */
 #define OMAP3430_ST_IO_CHAIN_MASK			(1 << 16)
 #define OMAP3430_ST_IO_MASK				(1 << 8)
-
-/* PRM_CLKSEL */
 #define OMAP3430_SYS_CLKIN_SEL_SHIFT			0
-#define OMAP3430_SYS_CLKIN_SEL_MASK			(0x7 << 0)
 #define OMAP3430_SYS_CLKIN_SEL_WIDTH			3
-
-/* PRM_CLKOUT_CTRL */
-#define OMAP3430_CLKOUT_EN_MASK				(1 << 7)
 #define OMAP3430_CLKOUT_EN_SHIFT			7
-
-/* RM_RSTST_DSS specific bits */
-
-/* PM_WKEN_DSS */
 #define OMAP3430_PM_WKEN_DSS_EN_DSS_MASK		(1 << 0)
-
-/* PM_WKDEP_DSS specific bits */
-#define OMAP3430_PM_WKDEP_DSS_EN_IVA2_MASK		(1 << 2)
-
-/* PM_PWSTCTRL_DSS specific bits */
-
-/* PM_PWSTST_DSS specific bits */
-
-/* PM_PREPWSTST_DSS specific bits */
-
-/* RM_RSTST_CAM specific bits */
-
-/* PM_WKDEP_CAM specific bits */
-#define OMAP3430_PM_WKDEP_CAM_EN_IVA2_MASK		(1 << 2)
-
-/* PM_PWSTCTRL_CAM specific bits */
-
-/* PM_PWSTST_CAM specific bits */
-
-/* PM_PREPWSTST_CAM specific bits */
-
-/* PM_PWSTCTRL_USBHOST specific bits */
 #define OMAP3430ES2_SAVEANDRESTORE_SHIFT		4
-
-/* RM_RSTST_PER specific bits */
-
-/* PM_WKEN_PER specific bits */
-
-/* PM_MPUGRPSEL_PER specific bits */
-
-/* PM_IVA2GRPSEL_PER specific bits */
-
-/* PM_WKST_PER specific bits */
-
-/* PM_WKDEP_PER specific bits */
-#define OMAP3430_PM_WKDEP_PER_EN_IVA2_MASK		(1 << 2)
-
-/* PM_PWSTCTRL_PER specific bits */
-
-/* PM_PWSTST_PER specific bits */
-
-/* PM_PREPWSTST_PER specific bits */
-
-/* RM_RSTST_EMU specific bits */
-
-/* PM_PWSTST_EMU specific bits */
-
-/* PRM_VC_SMPS_SA */
 #define OMAP3430_PRM_VC_SMPS_SA_SA1_SHIFT		16
 #define OMAP3430_PRM_VC_SMPS_SA_SA1_MASK		(0x7f << 16)
 #define OMAP3430_PRM_VC_SMPS_SA_SA0_SHIFT		0
 #define OMAP3430_PRM_VC_SMPS_SA_SA0_MASK		(0x7f << 0)
-
-/* PRM_VC_SMPS_VOL_RA */
-#define OMAP3430_VOLRA1_SHIFT				16
 #define OMAP3430_VOLRA1_MASK				(0xff << 16)
-#define OMAP3430_VOLRA0_SHIFT				0
 #define OMAP3430_VOLRA0_MASK				(0xff << 0)
-
-/* PRM_VC_SMPS_CMD_RA */
-#define OMAP3430_CMDRA1_SHIFT				16
 #define OMAP3430_CMDRA1_MASK				(0xff << 16)
-#define OMAP3430_CMDRA0_SHIFT				0
 #define OMAP3430_CMDRA0_MASK				(0xff << 0)
-
-/* PRM_VC_CMD_VAL_0 specific bits */
 #define OMAP3430_VC_CMD_ON_SHIFT			24
 #define OMAP3430_VC_CMD_ON_MASK				(0xFF << 24)
 #define OMAP3430_VC_CMD_ONLP_SHIFT			16
-#define OMAP3430_VC_CMD_ONLP_MASK			(0xFF << 16)
 #define OMAP3430_VC_CMD_RET_SHIFT			8
-#define OMAP3430_VC_CMD_RET_MASK			(0xFF << 8)
 #define OMAP3430_VC_CMD_OFF_SHIFT			0
-#define OMAP3430_VC_CMD_OFF_MASK			(0xFF << 0)
-
-/* PRM_VC_CMD_VAL_1 specific bits */
-
-/* PRM_VC_CH_CONF */
-#define OMAP3430_CMD1_MASK				(1 << 20)
-#define OMAP3430_RACEN1_MASK				(1 << 19)
-#define OMAP3430_RAC1_MASK				(1 << 18)
-#define OMAP3430_RAV1_MASK				(1 << 17)
-#define OMAP3430_PRM_VC_CH_CONF_SA1_MASK		(1 << 16)
-#define OMAP3430_CMD0_MASK				(1 << 4)
-#define OMAP3430_RACEN0_MASK				(1 << 3)
-#define OMAP3430_RAC0_MASK				(1 << 2)
-#define OMAP3430_RAV0_MASK				(1 << 1)
-#define OMAP3430_PRM_VC_CH_CONF_SA0_MASK		(1 << 0)
-
-/* PRM_VC_I2C_CFG */
-#define OMAP3430_HSMASTER_MASK				(1 << 5)
-#define OMAP3430_SREN_MASK				(1 << 4)
 #define OMAP3430_HSEN_MASK				(1 << 3)
-#define OMAP3430_MCODE_SHIFT				0
 #define OMAP3430_MCODE_MASK				(0x7 << 0)
-
-/* PRM_VC_BYPASS_VAL */
 #define OMAP3430_VALID_MASK				(1 << 24)
 #define OMAP3430_DATA_SHIFT				16
-#define OMAP3430_DATA_MASK				(0xff << 16)
 #define OMAP3430_REGADDR_SHIFT				8
-#define OMAP3430_REGADDR_MASK				(0xff << 8)
 #define OMAP3430_SLAVEADDR_SHIFT			0
-#define OMAP3430_SLAVEADDR_MASK				(0x7f << 0)
-
-/* PRM_RSTCTRL */
-#define OMAP3430_RST_DPLL3_MASK				(1 << 2)
-#define OMAP3430_RST_GS_MASK				(1 << 1)
-
-/* PRM_RSTTIME */
-#define OMAP3430_RSTTIME2_SHIFT				8
-#define OMAP3430_RSTTIME2_MASK				(0x1f << 8)
-#define OMAP3430_RSTTIME1_SHIFT				0
-#define OMAP3430_RSTTIME1_MASK				(0xff << 0)
-
-/* PRM_RSTST */
 #define OMAP3430_ICECRUSHER_RST_SHIFT			10
-#define OMAP3430_ICECRUSHER_RST_MASK			(1 << 10)
 #define OMAP3430_ICEPICK_RST_SHIFT			9
-#define OMAP3430_ICEPICK_RST_MASK			(1 << 9)
 #define OMAP3430_VDD2_VOLTAGE_MANAGER_RST_SHIFT		8
-#define OMAP3430_VDD2_VOLTAGE_MANAGER_RST_MASK		(1 << 8)
 #define OMAP3430_VDD1_VOLTAGE_MANAGER_RST_SHIFT		7
-#define OMAP3430_VDD1_VOLTAGE_MANAGER_RST_MASK		(1 << 7)
 #define OMAP3430_EXTERNAL_WARM_RST_SHIFT		6
-#define OMAP3430_EXTERNAL_WARM_RST_MASK			(1 << 6)
 #define OMAP3430_SECURE_WD_RST_SHIFT			5
-#define OMAP3430_SECURE_WD_RST_MASK			(1 << 5)
 #define OMAP3430_MPU_WD_RST_SHIFT			4
-#define OMAP3430_MPU_WD_RST_MASK			(1 << 4)
 #define OMAP3430_SECURITY_VIOL_RST_SHIFT		3
-#define OMAP3430_SECURITY_VIOL_RST_MASK			(1 << 3)
 #define OMAP3430_GLOBAL_SW_RST_SHIFT			1
-#define OMAP3430_GLOBAL_SW_RST_MASK			(1 << 1)
 #define OMAP3430_GLOBAL_COLD_RST_SHIFT			0
 #define OMAP3430_GLOBAL_COLD_RST_MASK			(1 << 0)
-
-/* PRM_VOLTCTRL */
-#define OMAP3430_SEL_VMODE_MASK				(1 << 4)
 #define OMAP3430_SEL_OFF_MASK				(1 << 3)
 #define OMAP3430_AUTO_OFF_MASK				(1 << 2)
-#define OMAP3430_AUTO_RET_MASK				(1 << 1)
-#define OMAP3430_AUTO_SLEEP_MASK			(1 << 0)
-
-/* PRM_SRAM_PCHARGE */
-#define OMAP3430_PCHARGE_TIME_SHIFT			0
-#define OMAP3430_PCHARGE_TIME_MASK			(0xff << 0)
-
-/* PRM_CLKSRC_CTRL */
-#define OMAP3430_SYSCLKDIV_SHIFT			6
-#define OMAP3430_SYSCLKDIV_MASK				(0x3 << 6)
-#define OMAP3430_AUTOEXTCLKMODE_SHIFT			3
-#define OMAP3430_AUTOEXTCLKMODE_MASK			(0x3 << 3)
-#define OMAP3430_SYSCLKSEL_SHIFT			0
-#define OMAP3430_SYSCLKSEL_MASK				(0x3 << 0)
-
-/* PRM_VOLTSETUP1 */
-#define OMAP3430_SETUP_TIME2_SHIFT			16
 #define OMAP3430_SETUP_TIME2_MASK			(0xffff << 16)
-#define OMAP3430_SETUP_TIME1_SHIFT			0
 #define OMAP3430_SETUP_TIME1_MASK			(0xffff << 0)
-
-/* PRM_VOLTOFFSET */
-#define OMAP3430_OFFSET_TIME_SHIFT			0
-#define OMAP3430_OFFSET_TIME_MASK			(0xffff << 0)
-
-/* PRM_CLKSETUP */
-#define OMAP3430_SETUP_TIME_SHIFT			0
-#define OMAP3430_SETUP_TIME_MASK			(0xffff << 0)
-
-/* PRM_POLCTRL */
-#define OMAP3430_OFFMODE_POL_MASK			(1 << 3)
-#define OMAP3430_CLKOUT_POL_MASK			(1 << 2)
-#define OMAP3430_CLKREQ_POL_MASK			(1 << 1)
-#define OMAP3430_EXTVOL_POL_MASK			(1 << 0)
-
-/* PRM_VOLTSETUP2 */
-#define OMAP3430_OFFMODESETUPTIME_SHIFT			0
-#define OMAP3430_OFFMODESETUPTIME_MASK			(0xffff << 0)
-
-/* PRM_VP1_CONFIG specific bits */
-
-/* PRM_VP1_VSTEPMIN specific bits */
-
-/* PRM_VP1_VSTEPMAX specific bits */
-
-/* PRM_VP1_VLIMITTO specific bits */
-
-/* PRM_VP1_VOLTAGE specific bits */
-
-/* PRM_VP1_STATUS specific bits */
-
-/* PRM_VP2_CONFIG specific bits */
-
-/* PRM_VP2_VSTEPMIN specific bits */
-
-/* PRM_VP2_VSTEPMAX specific bits */
-
-/* PRM_VP2_VLIMITTO specific bits */
-
-/* PRM_VP2_VOLTAGE specific bits */
-
-/* PRM_VP2_STATUS specific bits */
-
-/* RM_RSTST_NEON specific bits */
-
-/* PM_WKDEP_NEON specific bits */
-
-/* PM_PWSTCTRL_NEON specific bits */
-
-/* PM_PWSTST_NEON specific bits */
-
-/* PM_PREPWSTST_NEON specific bits */
-
 #endif
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:39 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:39 +0300
Subject: [PATCH v2 04/22] ARM: dt: tegra30: iommu: Add "nvidia,swgroup"
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-5-git-send-email-hdoyu@nvidia.com>

This is a bitmap that indicates which HardWare Accelerators(HWA) are
supported on Tegra30 SoC.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 arch/arm/boot/dts/tegra30.dtsi |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index d8783f0..4a9594e 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -1,6 +1,7 @@
 #include <dt-bindings/clock/tegra30-car.h>
 #include <dt-bindings/gpio/tegra-gpio.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/memory/tegra-swgroup.h>
 
 #include "skeleton.dtsi"
 
@@ -461,6 +462,7 @@
 		       0x7000f228 0x05c>;
 		nvidia,#asids = <4>;		/* # of ASIDs */
 		dma-window = <0 0x40000000>;	/* IOVA start & length */
+		nvidia,swgroup = TEGRA30_SWGROUP_ALL;
 		nvidia,ahb = <&ahb>;
 	};
 
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:41 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:41 +0300
Subject: [PATCH v2 06/22] ARM: dt: tegra114: iommu: Fix IOMMU register address
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-7-git-send-email-hdoyu@nvidia.com>

Fix IOMMU register address.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 arch/arm/boot/dts/tegra114.dtsi |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index abf6c40..1f45cf5 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -318,9 +318,9 @@
 
 	iommu {
 		compatible = "nvidia,tegra114-smmu", "nvidia,tegra30-smmu";
-		reg = <0x7000f010 0x02c
-		       0x7000f1f0 0x010
-		       0x7000f228 0x074>;
+		reg = <0x70019010 0x02c
+		       0x700191f0 0x010
+		       0x70019228 0x074>;
 		nvidia,#asids = <4>;
 		dma-window = <0 0x40000000>;
 		nvidia,swgroups = <0x18659fe>;
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:43 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:43 +0300
Subject: [PATCH v2 08/22] ARM: dt: tegra114: Add "nvidia,memory-client"
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-9-git-send-email-hdoyu@nvidia.com>

Add "nvidia,memory-client" to identify which swgroup ID a device
belongs to.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 arch/arm/boot/dts/tegra114.dtsi |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 9e231eb..df6767f 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -404,6 +404,7 @@
 		reg = <0x78000000 0x200>;
 		interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&tegra_car TEGRA114_CLK_SDMMC1>;
+		nvidia,memory-client = <TEGRA_SWGROUP_PPCS>;
 		status = "disable";
 	};
 
@@ -412,6 +413,7 @@
 		reg = <0x78000200 0x200>;
 		interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&tegra_car TEGRA114_CLK_SDMMC2>;
+		nvidia,memory-client = <TEGRA_SWGROUP_PPCS>;
 		status = "disable";
 	};
 
@@ -420,6 +422,7 @@
 		reg = <0x78000400 0x200>;
 		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&tegra_car TEGRA114_CLK_SDMMC3>;
+		nvidia,memory-client = <TEGRA_SWGROUP_PPCS>;
 		status = "disable";
 	};
 
@@ -428,6 +431,7 @@
 		reg = <0x78000600 0x200>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&tegra_car TEGRA114_CLK_SDMMC4>;
+		nvidia,memory-client = <TEGRA_SWGROUP_PPCS>;
 		status = "disable";
 	};
 
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:42 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:42 +0300
Subject: [PATCH v2 07/22] ARM: dt: tegra114: iommu: Add "nvidia,swgroups"
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-8-git-send-email-hdoyu@nvidia.com>

This is a bitmap that indicates which HardWare Accelerators(HWA) are
supported on Tegra114 SoC.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 arch/arm/boot/dts/tegra114.dtsi |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 1f45cf5..9e231eb 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -1,6 +1,7 @@
 #include <dt-bindings/clock/tegra114-car.h>
 #include <dt-bindings/gpio/tegra-gpio.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/memory/tegra-swgroup.h>
 
 #include "skeleton.dtsi"
 
@@ -323,7 +324,7 @@
 		       0x70019228 0x074>;
 		nvidia,#asids = <4>;
 		dma-window = <0 0x40000000>;
-		nvidia,swgroups = <0x18659fe>;
+		nvidia,swgroups = TEGRA114_SWGROUP_ALL;
 		nvidia,ahb = <&ahb>;
 	};
 
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:37 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:37 +0300
Subject: [PATCH v2 02/22] ARM: tegra: Populate AHB/IOMMU earlier than others
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-3-git-send-email-hdoyu@nvidia.com>

Populate AHB/IOMMU earlier than others. IOMMU depends on AHB. IOMMU
needs to be instanciated earlier than others so that IOMMU can
register other platform devices as IOMMU'able. Once IOMMU is
populated, IOMMU/AHB nodes are detached to prevent another
registeration.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 arch/arm/mach-tegra/tegra.c |   22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index 0d1e412..fe432d1 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -80,6 +80,26 @@ static struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
 	{}
 };
 
+static void tegra_of_platform_populate_iommu(void)
+{
+	int i;
+	struct platform_device *pdev;
+	const char * const path[] = {"/ahb", "/iommu", };
+
+	for (i = 0; i < ARRAY_SIZE(path); i++) {
+		struct device_node *np;
+
+		np  = of_find_node_by_path(path[i]);
+		if (!np)
+			break;
+
+		pdev = of_platform_device_create(np, NULL, NULL);
+		of_node_put(np);
+		if (!pdev)
+			break;
+	}
+}
+
 static void __init tegra_dt_init(void)
 {
 	struct soc_device_attribute *soc_dev_attr;
@@ -107,6 +127,8 @@ static void __init tegra_dt_init(void)
 
 	parent = soc_device_to_device(soc_dev);
 
+	tegra_of_platform_populate_iommu();
+
 	/*
 	 * Finished with the static registrations now; fill in the missing
 	 * devices
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:38 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:38 +0300
Subject: [PATCH v2 03/22] ARM: tegra: Create a DT header defining swgroups ID
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-4-git-send-email-hdoyu@nvidia.com>

Create a header file to define the swgroup IDs used by the IOMMU(SMMU)
binding. "swgroup" is a group of H/W clients in Tegra SoC from S/W POV.

This will allow the same header to be used by both device tree files,
and drivers implementing this binding, which guarantees that the two
stay in sync. This also makes device trees more readable by using names
instead of magic numbers.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 include/dt-bindings/memory/tegra-swgroup.h |   50 ++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 include/dt-bindings/memory/tegra-swgroup.h

diff --git a/include/dt-bindings/memory/tegra-swgroup.h b/include/dt-bindings/memory/tegra-swgroup.h
new file mode 100644
index 0000000..4cfa769
--- /dev/null
+++ b/include/dt-bindings/memory/tegra-swgroup.h
@@ -0,0 +1,50 @@
+/*
+ * This header provides constants for binding nvidia,swgroup ID
+ */
+
+#ifndef _DT_BINDINGS_MEMORY_TEGRA_SWGROUP_H
+#define _DT_BINDINGS_MEMORY_TEGRA_SWGROUP_H
+
+#define TEGRA_SWGROUP_AFI 0
+#define TEGRA_SWGROUP_AVPC 1
+#define TEGRA_SWGROUP_DC 2
+#define TEGRA_SWGROUP_DCB 3
+#define TEGRA_SWGROUP_EPP 4
+#define TEGRA_SWGROUP_G2 5
+#define TEGRA_SWGROUP_HC 6
+#define TEGRA_SWGROUP_HDA 7
+#define TEGRA_SWGROUP_ISP 8
+#define TEGRA_SWGROUP_ISP2 SWGID_ISP
+/* UNUSED: 9 */
+/* UNUSED: 10 */
+#define TEGRA_SWGROUP_MPE 11
+#define TEGRA_SWGROUP_MSENC SWGID_MPE
+#define TEGRA_SWGROUP_NV 12
+#define TEGRA_SWGROUP_NV2 13
+#define TEGRA_SWGROUP_PPCS 14
+#define TEGRA_SWGROUP_SATA2 15
+#define TEGRA_SWGROUP_SATA 16
+#define TEGRA_SWGROUP_VDE 17
+#define TEGRA_SWGROUP_VI 18
+#define TEGRA_SWGROUP_VIC 19
+#define TEGRA_SWGROUP_XUSB_HOST 20
+#define TEGRA_SWGROUP_XUSB_DEV 21
+#define TEGRA_SWGROUP_A9AVP 22
+#define TEGRA_SWGROUP_TSEC 23
+#define TEGRA_SWGROUP_PPCS1 24
+/* UNUSED: 25 */
+/* UNUSED: 26 */
+/* UNUSED: 27 */
+/* UNUSED: 28 */
+/* UNUSED: 29 */
+/* UNUSED: 30 */
+/* UNUSED: 31 */
+
+/* Reserved: 32-63 */
+
+#define TEGRA_SWGROUP_BIT(x)	(1ULL << TEGRA_SWGROUP_##x)
+
+#define TEGRA30_SWGROUP_ALL	<0x00000000 0x000779ff>
+#define TEGRA114_SWGROUP_ALL	<0x00000000 0x01b659fe>
+
+#endif /* _DT_BINDINGS_MEMORY_TEGRA_SWGROUP_H */
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:35 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:35 +0300
Subject: [PATCH v2 00/22] Unified SMMU driver among Tegra SoCs
Message-ID: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>

Hi,

This series provides:

(1) Unified SMMU driver among Tegra SoCs
(2) Multiple Address Space support(MASID) in IOMMU(SMMMU)
(3) Tegra IOMMU'able devices, most of platform devices are IOMMU'able.

There's some discussion[1] about device population order, which can
solve the following patches.

  [HACK] of: dev_node has struct device pointer
  ARM: tegra: Populate AHB/IOMMU earlier than others

Also "ARM: dma-mapping: Drop GFP_COMP for DMA memory allocations" may
not be necessary by [2]

Tested IOMMU functionality with T30 SD/MMC. Any further testing with
T114 and/or other devices would be really appreciated.

v2:
Updated based on Thierry Reding's and Stephen Warren's feedback

v1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/180267.html

Hiroshi Doyu (22):
  [HACK] of: dev_node has struct device pointer
  ARM: tegra: Populate AHB/IOMMU earlier than others
  ARM: tegra: Create a DT header defining swgroups ID
  ARM: dt: tegra30: iommu: Add "nvidia,swgroup"
  ARM: dt: tegra30: iommu: Add "nvidia,memory-client"
  ARM: dt: tegra114: iommu: Fix IOMMU register address
  ARM: dt: tegra114: iommu: Add "nvidia,swgroups"
  ARM: dt: tegra114: Add "nvidia,memory-client"
  amba: Move AHB to core_initcall
  iommu/tegra: smmu: Move IOMMU to core_initcall
  iommu/tegra: smmu: Add Tegra 114 support
  iommu/tegra: smmu: Select ARM_DMA_USE_IOMMU in Kconfig
  iommu/tegra: smmu: Create default IOVA maps
  iommu/tegra: smmu: Register platform_device to IOMMU dynamically
  iommu/tegra: smmu: Calculate ASID register offset by ID
  iommu/tegra: smmu: Get "nvidia,swgroup" from DT
  iommu/tegra: smmu: Unfied driver for Tegra SoCs
  iommu/tegra: smmu: Use dt-bindings MACRO
  iommu/tegra: smmu: Workaround PCIe IOMMU'able
  iommu/tegra: smmu: Get "nvidia,memory-client" from DT
  iommu/tegra: smmu: Support Multiple ASID
  ARM: dma-mapping: Drop GFP_COMP for DMA memory allocations

 .../bindings/iommu/nvidia,tegra30-smmu.txt         |   20 +-
 arch/arm/boot/dts/tegra114.dtsi                    |   13 +-
 arch/arm/boot/dts/tegra30.dtsi                     |   21 ++
 arch/arm/mach-tegra/tegra.c                        |   22 ++
 arch/arm/mm/dma-mapping.c                          |    7 +
 drivers/amba/tegra-ahb.c                           |    7 +-
 drivers/iommu/Kconfig                              |    1 +
 drivers/iommu/tegra-smmu.c                         |  211 +++++++++++---------
 drivers/of/base.c                                  |   23 +++
 drivers/of/platform.c                              |    8 +
 include/dt-bindings/memory/tegra-swgroup.h         |   50 +++++
 include/linux/of.h                                 |   16 ++
 12 files changed, 296 insertions(+), 103 deletions(-)
 create mode 100644 include/dt-bindings/memory/tegra-swgroup.h

-- 
1.7.9.5

[1] https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/thread.html#36542
[2] http://marc.info/?l=linux-tegra&m=137173895620957&w=1


From hdoyu at nvidia.com  Fri Jul  5 06:44:36 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:36 +0300
Subject: [PATCH v2 01/22] [HACK] of: dev_node has struct device pointer
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-2-git-send-email-hdoyu@nvidia.com>

To prevent of_platform_populate() from trying to populate duplicate
devices if a device has been already populated.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
Need to take care of early_platform_devices, or alternative solution.
---
 drivers/of/base.c     |   23 +++++++++++++++++++++++
 drivers/of/platform.c |    8 ++++++++
 include/linux/of.h    |   16 ++++++++++++++++
 3 files changed, 47 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5c54279..99062dd 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -230,6 +230,29 @@ const void *of_get_property(const struct device_node *np, const char *name,
 }
 EXPORT_SYMBOL(of_get_property);
 
+struct device *of_get_device(const struct device_node *node)
+{
+	struct device *dev;
+	unsigned long flags;
+
+	raw_spin_lock_irqsave(&devtree_lock, flags);
+	dev = node->dev;
+	raw_spin_unlock_irqrestore(&devtree_lock, flags);
+
+	return dev;
+}
+EXPORT_SYMBOL(of_get_device);
+
+void of_set_device(struct device_node *node, struct device *dev)
+{
+	unsigned long flags;
+
+	raw_spin_lock_irqsave(&devtree_lock, flags);
+	node->dev = dev;
+	raw_spin_unlock_irqrestore(&devtree_lock, flags);
+}
+EXPORT_SYMBOL(of_set_device);
+
 /** Checks if the given "compat" string matches one of the strings in
  * the device's "compatible" property
  */
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index e0a6514..a8f6b09 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -203,10 +203,17 @@ struct platform_device *of_platform_device_create_pdata(
 					struct device *parent)
 {
 	struct platform_device *dev;
+	struct device *tmp;
 
 	if (!of_device_is_available(np))
 		return NULL;
 
+	tmp = of_get_device(np);
+	if (tmp) {
+		dev_info(tmp, "Already populated\n");
+		return to_platform_device(tmp);
+	}
+
 	dev = of_device_alloc(np, bus_id, parent);
 	if (!dev)
 		return NULL;
@@ -228,6 +235,7 @@ struct platform_device *of_platform_device_create_pdata(
 		return NULL;
 	}
 
+	of_set_device(np, &dev->dev);
 	return dev;
 }
 
diff --git a/include/linux/of.h b/include/linux/of.h
index 1fd08ca..b548522 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -60,6 +60,9 @@ struct device_node {
 	struct	kref kref;
 	unsigned long _flags;
 	void	*data;
+
+	struct device *dev;		/* Set only after populated */
+
 #if defined(CONFIG_SPARC)
 	const char *path_component_name;
 	unsigned int unique_id;
@@ -268,6 +271,8 @@ extern const void *of_get_property(const struct device_node *node,
 				int *lenp);
 #define for_each_property_of_node(dn, pp) \
 	for (pp = dn->properties; pp != NULL; pp = pp->next)
+extern struct device *of_get_device(const struct device_node *node);
+extern void of_set_device(struct device_node *node, struct device *dev);
 
 extern int of_n_addr_cells(struct device_node *np);
 extern int of_n_size_cells(struct device_node *np);
@@ -459,6 +464,17 @@ static inline const void *of_get_property(const struct device_node *node,
 	return NULL;
 }
 
+static inline struct device *of_get_device(const struct device_node *node)
+{
+	return NULL;
+}
+
+static inline void of_set_device(const struct device_node *node,
+				 struct device *dev);
+{
+	return -ENOSYS;
+}
+
 static inline int of_property_read_u64(const struct device_node *np,
 				       const char *propname, u64 *out_value)
 {
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:40 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:40 +0300
Subject: [PATCH v2 05/22] ARM: dt: tegra30: iommu: Add "nvidia,memory-client"
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-6-git-send-email-hdoyu@nvidia.com>

Add "nvidia,memory-client" to identify which swgroup ID a device
belongs to.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 arch/arm/boot/dts/tegra30.dtsi |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 4a9594e..4aa5b4a 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -23,6 +23,7 @@
 		interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>, /* syncpt */
 			     <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; /* general */
 		clocks = <&tegra_car TEGRA30_CLK_HOST1X>;
+		nvidia,memory-client = <TEGRA_SWGROUP_HC>;
 
 		#address-cells = <1>;
 		#size-cells = <1>;
@@ -34,6 +35,7 @@
 			reg = <0x54040000 0x00040000>;
 			interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&tegra_car TEGRA30_CLK_MPE>;
+			nvidia,memory-client = <TEGRA_SWGROUP_MPE>;
 		};
 
 		vi {
@@ -41,6 +43,7 @@
 			reg = <0x54080000 0x00040000>;
 			interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&tegra_car TEGRA30_CLK_VI>;
+			nvidia,memory-client = <TEGRA_SWGROUP_VI>;
 		};
 
 		epp {
@@ -48,6 +51,7 @@
 			reg = <0x540c0000 0x00040000>;
 			interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&tegra_car TEGRA30_CLK_EPP>;
+			nvidia,memory-client = <TEGRA_SWGROUP_EPP>;
 		};
 
 		isp {
@@ -55,6 +59,7 @@
 			reg = <0x54100000 0x00040000>;
 			interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&tegra_car TEGRA30_CLK_ISP>;
+			nvidia,memory-client = <TEGRA_SWGROUP_ISP>;
 		};
 
 		gr2d {
@@ -62,6 +67,7 @@
 			reg = <0x54140000 0x00040000>;
 			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&tegra_car TEGRA30_CLK_GR2D>;
+			nvidia,memory-client = <TEGRA_SWGROUP_G2>;
 		};
 
 		gr3d {
@@ -69,6 +75,8 @@
 			reg = <0x54180000 0x00040000>;
 			clocks = <&tegra_car 24 &tegra_car 98>;
 			clock-names = "3d", "3d2";
+			nvidia,memory-client = <TEGRA_SWGROUP_NV
+						TEGRA_SWGROUP_NV2>;
 		};
 
 		dc at 54200000 {
@@ -78,6 +86,7 @@
 			clocks = <&tegra_car TEGRA30_CLK_DISP1>,
 				 <&tegra_car TEGRA30_CLK_PLL_P>;
 			clock-names = "disp1", "parent";
+			nvidia,memory-client = <TEGRA_SWGROUP_DC>;
 
 			rgb {
 				status = "disabled";
@@ -91,6 +100,7 @@
 			clocks = <&tegra_car TEGRA30_CLK_DISP2>,
 				 <&tegra_car TEGRA30_CLK_PLL_P>;
 			clock-names = "disp2", "parent";
+			nvidia,memory-client = <TEGRA_SWGROUP_DCB>;
 
 			rgb {
 				status = "disabled";
@@ -247,6 +257,7 @@
 		interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 8>;
 		clocks = <&tegra_car TEGRA30_CLK_UARTA>;
+		nvidia,memory-client = <TEGRA_SWGROUP_PPCS>;
 		status = "disabled";
 	};
 
@@ -257,6 +268,7 @@
 		interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 9>;
 		clocks = <&tegra_car TEGRA30_CLK_UARTB>;
+		nvidia,memory-client = <TEGRA_SWGROUP_PPCS>;
 		status = "disabled";
 	};
 
@@ -267,6 +279,7 @@
 		interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 10>;
 		clocks = <&tegra_car TEGRA30_CLK_UARTC>;
+		nvidia,memory-client = <TEGRA_SWGROUP_PPCS>;
 		status = "disabled";
 	};
 
@@ -277,6 +290,7 @@
 		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 19>;
 		clocks = <&tegra_car TEGRA30_CLK_UARTD>;
+		nvidia,memory-client = <TEGRA_SWGROUP_PPCS>;
 		status = "disabled";
 	};
 
@@ -287,6 +301,7 @@
 		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 20>;
 		clocks = <&tegra_car TEGRA30_CLK_UARTE>;
+		nvidia,memory-client = <TEGRA_SWGROUP_PPCS>;
 		status = "disabled";
 	};
 
@@ -536,6 +551,7 @@
 		reg = <0x78000000 0x200>;
 		interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&tegra_car TEGRA30_CLK_SDMMC1>;
+		nvidia,memory-client = <TEGRA_SWGROUP_PPCS>;
 		status = "disabled";
 	};
 
@@ -544,6 +560,7 @@
 		reg = <0x78000200 0x200>;
 		interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&tegra_car TEGRA30_CLK_SDMMC2>;
+		nvidia,memory-client = <TEGRA_SWGROUP_PPCS>;
 		status = "disabled";
 	};
 
@@ -552,6 +569,7 @@
 		reg = <0x78000400 0x200>;
 		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&tegra_car TEGRA30_CLK_SDMMC3>;
+		nvidia,memory-client = <TEGRA_SWGROUP_PPCS>;
 		status = "disabled";
 	};
 
@@ -560,6 +578,7 @@
 		reg = <0x78000600 0x200>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&tegra_car TEGRA30_CLK_SDMMC4>;
+		nvidia,memory-client = <TEGRA_SWGROUP_PPCS>;
 		status = "disabled";
 	};
 
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:46 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:46 +0300
Subject: [PATCH v2 11/22] iommu/tegra: smmu: Add Tegra 114 support
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-12-git-send-email-hdoyu@nvidia.com>

Tegra 114 SMMU uses the almost same logic as one in Tegra 30 except
that they have different HaredWare Accelerators(HWA). Those difference
is provided from DT.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 .../bindings/iommu/nvidia,tegra30-smmu.txt         |    2 +-
 drivers/iommu/tegra-smmu.c                         |    1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
index 89fb543..ce5c43e 100644
--- a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
@@ -1,7 +1,7 @@
 NVIDIA Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit)
 
 Required properties:
-- compatible : "nvidia,tegra30-smmu"
+- compatible : "nvidia,tegra114-smmu", "nvidia,tegra30-smmu"
 - reg : Should contain 3 register banks(address and length) for each
   of the SMMU register blocks.
 - interrupts : Should contain MC General interrupt.
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 4c16c90..3e03c69 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -1262,6 +1262,7 @@ const struct dev_pm_ops tegra_smmu_pm_ops = {
 };
 
 static struct of_device_id tegra_smmu_of_match[] = {
+	{ .compatible = "nvidia,tegra114-smmu", },
 	{ .compatible = "nvidia,tegra30-smmu", },
 	{ },
 };
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:47 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:47 +0300
Subject: [PATCH v2 12/22] iommu/tegra: smmu: Select ARM_DMA_USE_IOMMU in
 Kconfig
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-13-git-send-email-hdoyu@nvidia.com>

SMMU expects ARM_DMA_USE_IOMMU to be enabled to use DMA mapping API by
default.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 drivers/iommu/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 820d85c..cd9318b 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -160,6 +160,7 @@ config TEGRA_IOMMU_SMMU
 	bool "Tegra SMMU IOMMU Support"
 	depends on ARCH_TEGRA && TEGRA_AHB
 	select IOMMU_API
+	select ARM_DMA_USE_IOMMU
 	help
 	  Enables support for remapping discontiguous physical memory
 	  shared with the operating system into contiguous I/O virtual
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:49 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:49 +0300
Subject: [PATCH v2 14/22] iommu/tegra: smmu: Register platform_device to IOMMU
 dynamically
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-15-git-send-email-hdoyu@nvidia.com>

Register platform_devices to IOMMU dynamically via
ops->{add,remove}_device().

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 drivers/iommu/tegra-smmu.c |   37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 1617c90..35f4a16 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -39,6 +39,7 @@
 
 #include <asm/page.h>
 #include <asm/cacheflush.h>
+#include <asm/dma-iommu.h>
 
 enum smmu_hwgrp {
 	HWGRP_AFI,
@@ -949,6 +950,40 @@ static void smmu_iommu_domain_destroy(struct iommu_domain *domain)
 	dev_dbg(smmu->dev, "smmu_as@%p\n", as);
 }
 
+/*
+ * ASID[0] for the system default
+ * ASID[1] for PPCS, which has SDMMC
+ * ASID[2][3].. open for drivers, first come, first served.
+ */
+enum {
+	SYSTEM_DEFAULT,
+	SYSTEM_PROTECTED,
+};
+
+static int smmu_iommu_add_device(struct device *dev)
+{
+	int err;
+	struct dma_iommu_mapping *map = smmu_handle->map[SYSTEM_DEFAULT];
+
+	if (!map)
+		goto out;
+
+	err = arm_iommu_attach_device(dev, map);
+	if (err) {
+		dev_err(dev, "Failed to attach to map %p\n", map);
+		return err;
+	}
+out:
+	dev_dbg(dev, "Attached to map %p\n", map);
+	return 0;
+}
+
+static void smmu_iommu_remove_device(struct device *dev)
+{
+	dev_dbg(dev, "Detaching from map %p\n", to_dma_iommu_mapping(dev));
+	arm_iommu_detach_device(dev);
+}
+
 static struct iommu_ops smmu_iommu_ops = {
 	.domain_init	= smmu_iommu_domain_init,
 	.domain_destroy	= smmu_iommu_domain_destroy,
@@ -958,6 +993,8 @@ static struct iommu_ops smmu_iommu_ops = {
 	.unmap		= smmu_iommu_unmap,
 	.iova_to_phys	= smmu_iommu_iova_to_phys,
 	.domain_has_cap	= smmu_iommu_domain_has_cap,
+	.add_device	= smmu_iommu_add_device,
+	.remove_device	= smmu_iommu_remove_device,
 	.pgsize_bitmap	= SMMU_IOMMU_PGSIZES,
 };
 
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:45 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:45 +0300
Subject: [PATCH v2 10/22] iommu/tegra: smmu: Move IOMMU to core_initcall
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-11-git-send-email-hdoyu@nvidia.com>

Move IOMMU to core_initcall in order to instanciate this device earlier
than others since IOMMU driver needs to reigster other platform
devices as IOMMU'able.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 drivers/iommu/tegra-smmu.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index f6f120e..4c16c90 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -1288,7 +1288,7 @@ static void __exit tegra_smmu_exit(void)
 	platform_driver_unregister(&tegra_smmu_driver);
 }
 
-subsys_initcall(tegra_smmu_init);
+core_initcall(tegra_smmu_init);
 module_exit(tegra_smmu_exit);
 
 MODULE_DESCRIPTION("IOMMU API for SMMU in Tegra30");
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:51 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:51 +0300
Subject: [PATCH v2 16/22] iommu/tegra: smmu: Get "nvidia,swgroup" from DT
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-17-git-send-email-hdoyu@nvidia.com>

This provides the info about which H/W Accelerators are supported on
Tegra SoC. This info is passed from DT. This is necessary to have the
unified SMMU driver among Tegra SoCs. Instead of using platform data,
DT passes "nvidia,swgroup" now. DT is mandatory in Tegra.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 .../bindings/iommu/nvidia,tegra30-smmu.txt         |    6 +++-
 drivers/iommu/tegra-smmu.c                         |   31 +++++++++-----------
 2 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
index ce5c43e..0c14dca 100644
--- a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
@@ -8,14 +8,18 @@ Required properties:
 - nvidia,#asids : # of ASIDs
 - dma-window : IOVA start address and length.
 - nvidia,ahb : phandle to the ahb bus connected to SMMU.
+- nvidia,swgroups: A bitmap of supported HardWare Accelerators(HWA).
+  Each bit represents one swgroup. The assignments may be found in header
+  file <dt-bindings/memory/tegra-swgroup.h>.
 
 Example:
-	smmu {
+	iommu {
 		compatible = "nvidia,tegra30-smmu";
 		reg = <0x7000f010 0x02c
 		       0x7000f1f0 0x010
 		       0x7000f228 0x05c>;
 		nvidia,#asids = <4>;		/* # of ASIDs */
 		dma-window = <0 0x40000000>;	/* IOVA start & length */
+		nvidia,swgroups = TEGRA30_SWGROUP_ALL;
 		nvidia,ahb = <&ahb>;
 	};
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 95c6c80..c7b33f2 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -265,7 +265,7 @@ struct smmu_client {
 	struct device		*dev;
 	struct list_head	list;
 	struct smmu_as		*as;
-	u32			hwgrp;
+	u64			hwgrp;
 };
 
 /*
@@ -307,6 +307,8 @@ struct smmu_device {
 	struct device	*dev;
 	struct page *avp_vector_page;	/* dummy page shared by all AS's */
 
+	u64 swgroup;			/* swgroup ID bitmap */
+
 	/*
 	 * Register image savers for suspend/resume
 	 */
@@ -382,10 +384,10 @@ static inline void smmu_write(struct smmu_device *smmu, u32 val, size_t offs)
  */
 #define FLUSH_SMMU_REGS(smmu)	smmu_read(smmu, SMMU_CONFIG)
 
-#define smmu_client_hwgrp(c) (u32)((c)->dev->platform_data)
+#define smmu_client_hwgrp(c)	(c->as->smmu->swgroup)
 
 static int __smmu_client_set_hwgrp(struct smmu_client *c,
-				   unsigned long map, int on)
+				   u64 map, int on)
 {
 	int i;
 	struct smmu_as *as = c->as;
@@ -398,12 +400,11 @@ static int __smmu_client_set_hwgrp(struct smmu_client *c,
 	if (!on)
 		map = smmu_client_hwgrp(c);
 
-	for_each_set_bit(i, &map, HWGRP_COUNT) {
+	for_each_set_bit(i, (unsigned long *)&map,
+			 sizeof(map) * BITS_PER_BYTE) {
 		offs = HWGRP_ASID_REG(i);
 		val = smmu_read(smmu, offs);
 		if (on) {
-			if (WARN_ON(val & mask))
-				goto err_hw_busy;
 			val |= mask;
 		} else {
 			WARN_ON((val & mask) == mask);
@@ -414,15 +415,6 @@ static int __smmu_client_set_hwgrp(struct smmu_client *c,
 	FLUSH_SMMU_REGS(smmu);
 	c->hwgrp = map;
 	return 0;
-
-err_hw_busy:
-	for_each_set_bit(i, &map, HWGRP_COUNT) {
-		offs = HWGRP_ASID_REG(i);
-		val = smmu_read(smmu, offs);
-		val &= ~mask;
-		smmu_write(smmu, val, offs);
-	}
-	return -EBUSY;
 }
 
 static int smmu_client_set_hwgrp(struct smmu_client *c, u32 map, int on)
@@ -794,7 +786,7 @@ static int smmu_iommu_attach_dev(struct iommu_domain *domain,
 	struct smmu_as *as = domain->priv;
 	struct smmu_device *smmu = as->smmu;
 	struct smmu_client *client, *c;
-	u32 map;
+	u64 map;
 	int err;
 
 	client = devm_kzalloc(smmu->dev, sizeof(*c), GFP_KERNEL);
@@ -802,7 +794,7 @@ static int smmu_iommu_attach_dev(struct iommu_domain *domain,
 		return -ENOMEM;
 	client->dev = dev;
 	client->as = as;
-	map = (unsigned long)dev->platform_data;
+	map = smmu->swgroup;
 	if (!map)
 		return -EINVAL;
 
@@ -1210,6 +1202,7 @@ static int tegra_smmu_probe(struct platform_device *pdev)
 	int i, asids, err = 0;
 	dma_addr_t uninitialized_var(base);
 	size_t bytes, uninitialized_var(size);
+	u64 swgroup;
 
 	if (smmu_handle)
 		return -EIO;
@@ -1219,6 +1212,9 @@ static int tegra_smmu_probe(struct platform_device *pdev)
 	if (of_property_read_u32(dev->of_node, "nvidia,#asids", &asids))
 		return -ENODEV;
 
+	if (of_property_read_u64(dev->of_node, "nvidia,swgroup", &swgroup))
+		return -ENODEV;
+
 	bytes = sizeof(*smmu) + asids * (sizeof(*smmu->as) +
 					 sizeof(struct dma_iommu_mapping *));
 	smmu = devm_kzalloc(dev, bytes, GFP_KERNEL);
@@ -1267,6 +1263,7 @@ static int tegra_smmu_probe(struct platform_device *pdev)
 	smmu->num_as = asids;
 	smmu->iovmm_base = base;
 	smmu->page_count = size;
+	smmu->swgroup = swgroup;
 
 	smmu->translation_enable_0 = ~0;
 	smmu->translation_enable_1 = ~0;
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:44 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:44 +0300
Subject: [PATCH v2 09/22] amba: Move AHB to core_initcall
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-10-git-send-email-hdoyu@nvidia.com>

Move AHB to core_initcall in order to instanciate this device earlier
than others since IOMMU depends on AHB and then IOMMU driver needs to
reigster other platform devices as IOMMU'able.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 drivers/amba/tegra-ahb.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/amba/tegra-ahb.c b/drivers/amba/tegra-ahb.c
index 1f44e56..08e898d 100644
--- a/drivers/amba/tegra-ahb.c
+++ b/drivers/amba/tegra-ahb.c
@@ -283,7 +283,12 @@ static struct platform_driver tegra_ahb_driver = {
 		.pm = &tegra_ahb_pm,
 	},
 };
-module_platform_driver(tegra_ahb_driver);
+
+static int tegra_ahb_init(void)
+{
+	return platform_driver_register(&tegra_ahb_driver);
+}
+core_initcall(tegra_ahb_init);
 
 MODULE_AUTHOR("Hiroshi DOYU <hdoyu at nvidia.com>");
 MODULE_DESCRIPTION("Tegra AHB driver");
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:55 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:55 +0300
Subject: [PATCH v2 20/22] iommu/tegra: smmu: Get "nvidia,
 memory-client" from DT
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-21-git-send-email-hdoyu@nvidia.com>

This provides the info about which swgroups a device belongs to. This
info is passed from DT. This is necessary for the unified SMMU driver
among Tegra SoCs since each has different H/W accelerators.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 .../bindings/iommu/nvidia,tegra30-smmu.txt         |   12 ++++++++++++
 drivers/iommu/tegra-smmu.c                         |   20 +++++++++++++++++++-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
index 0c14dca..20ce1fb 100644
--- a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
@@ -11,6 +11,7 @@ Required properties:
 - nvidia,swgroups: A bitmap of supported HardWare Accelerators(HWA).
   Each bit represents one swgroup. The assignments may be found in header
   file <dt-bindings/memory/tegra-swgroup.h>.
+- nvidia,memory-client: Indicates which swgroups a device belongs to.
 
 Example:
 	iommu {
@@ -23,3 +24,14 @@ Example:
 		nvidia,swgroups = TEGRA30_SWGROUP_ALL;
 		nvidia,ahb = <&ahb>;
 	};
+
+	host1x {
+		compatible = "nvidia,tegra30-host1x", "simple-bus";
+		nvidia,memory-client = <TEGRA_SWGROUP_HC>;
+		....
+		gr3d {
+			compatible = "nvidia,tegra30-gr3d";
+			nvidia,memory-client = <TEGRA_SWGROUP_NV
+						TEGRA_SWGROUP_NV2>;
+			....
+		};
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index ac5d661..8a9434e 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -314,6 +314,24 @@ static inline void smmu_write(struct smmu_device *smmu, u32 val, size_t offs)
 
 #define smmu_client_hwgrp(c)	(c->as->smmu->swgroup)
 
+static u64 smmu_of_get_memory_client(struct device *dev)
+{
+	size_t bytes;
+	const char *propname = "nvidia,memory-client";
+	const __be32 *prop;
+	int i;
+	u64 swgroup = 0;
+
+	prop = of_get_property(dev->of_node, propname, &bytes);
+	if (!prop || !bytes)
+		return 0;
+
+	for (i = 0; i < bytes / sizeof(u32); i++, prop++)
+		swgroup |= 1ULL << be32_to_cpup(prop);
+
+	return swgroup;
+}
+
 static int __smmu_client_set_hwgrp(struct smmu_client *c,
 				   u64 map, int on)
 {
@@ -725,7 +743,7 @@ static int smmu_iommu_attach_dev(struct iommu_domain *domain,
 		return -ENOMEM;
 	client->dev = dev;
 	client->as = as;
-	map = smmu->swgroup;
+	map = smmu_of_get_memory_client(dev);
 	if (!map)
 		return -EINVAL;
 
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:57 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:57 +0300
Subject: [PATCH v2 22/22] ARM: dma-mapping: Drop GFP_COMP for DMA memory
 allocations
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-23-git-send-email-hdoyu@nvidia.com>

arm_iommu_alloc_attrs wants to split pages after allocation in order
to reduce the memory footprint. This does not work well with GFP_COMP
pages, so drop this flag before allocation.

(ref: ea2e7057c0234cfb8b09467d8f137760d371fc72)

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 arch/arm/mm/dma-mapping.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 7f9b179..cad35a3 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1322,6 +1322,13 @@ static void *arm_iommu_alloc_attrs(struct device *dev, size_t size,
 	struct page **pages;
 	void *addr = NULL;
 
+	/* Following is a work-around (a.k.a. hack) to prevent pages
+	 * with __GFP_COMP being passed to split_page() which cannot
+	 * handle them.  The real problem is that this flag probably
+	 * should be 0 on ARM as it is not supported on this
+	 * platform--see CONFIG_HUGETLB_PAGE. */
+	gfp &= ~(__GFP_COMP);
+
 	*handle = DMA_ERROR_CODE;
 	size = PAGE_ALIGN(size);
 
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:56 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:56 +0300
Subject: [PATCH v2 21/22] iommu/tegra: smmu: Support Multiple ASID
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-22-git-send-email-hdoyu@nvidia.com>

Support Multiple Address Space(AS). Tegra SMMU can have multiple
ASes. We reserve 2 of them for static assignment, AS[0] for system
default, AS[1] for AHB clusters as protected domain from others, where
there are many traditional pheripheral devices like USB, SD/MMC. They
should be isolated from some smart devices like host1x for system
robustness. Even if smart devices behaves wrongly, the traditional
devices(SD/MMC, USB) wouldn't be affected, and the system could
continue most likely.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 drivers/iommu/tegra-smmu.c |   15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 8a9434e..1945815 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -904,7 +904,18 @@ enum {
 static int smmu_iommu_add_device(struct device *dev)
 {
 	int err;
-	struct dma_iommu_mapping *map = smmu_handle->map[SYSTEM_DEFAULT];
+	u64 swgroup;
+	struct dma_iommu_mapping *map = NULL;
+
+	swgroup = smmu_of_get_memory_client(dev);
+	switch (swgroup) {
+	case TEGRA_SWGROUP_BIT(PPCS):
+		map = smmu_handle->map[SYSTEM_PROTECTED];
+		break;
+	default:
+		map = smmu_handle->map[SYSTEM_DEFAULT];
+		break;
+	}
 
 	if (!map)
 		goto out;
@@ -915,7 +926,7 @@ static int smmu_iommu_add_device(struct device *dev)
 		return err;
 	}
 out:
-	dev_dbg(dev, "Attached to map %p\n", map);
+	dev_dbg(dev, "Attached to map %p, swgroup:%08llx\n", map, swgroup);
 	return 0;
 }
 
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:50 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:50 +0300
Subject: [PATCH v2 15/22] iommu/tegra: smmu: Calculate ASID register offset by
 ID
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-16-git-send-email-hdoyu@nvidia.com>

Calculate ASID register offset by ID so that we can get rid of SoC
specific MACROs. This is needed for the unified SMMU driver over Tegra
SoCs.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 drivers/iommu/tegra-smmu.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 35f4a16..95c6c80 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -256,7 +256,7 @@ static const u32 smmu_hwgrp_asid_reg[] = {
 	HWGRP_INIT(VDE),
 	HWGRP_INIT(VI),
 };
-#define HWGRP_ASID_REG(x) (smmu_hwgrp_asid_reg[x])
+#define HWGRP_ASID_REG(x) ((x) * sizeof(u32) + SMMU_AFI_ASID)
 
 /*
  * Per client for address space
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:48 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:48 +0300
Subject: [PATCH v2 13/22] iommu/tegra: smmu: Create default IOVA maps
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-14-git-send-email-hdoyu@nvidia.com>

Create default IOVA maps at boot-up which can be attached to devices.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 drivers/iommu/tegra-smmu.c |   28 ++++++++++++++++++++++++++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 3e03c69..1617c90 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -319,6 +319,8 @@ struct smmu_device {
 
 	struct device_node *ahb;
 
+	struct dma_iommu_mapping **map;
+
 	int		num_as;
 	struct smmu_as	as[0];		/* Run-time allocated array */
 };
@@ -1144,6 +1146,26 @@ static int tegra_smmu_resume(struct device *dev)
 	return err;
 }
 
+static int tegra_smmu_create_default_map(struct smmu_device *smmu)
+{
+	int i;
+
+	for (i = 0; i < smmu->num_as; i++) {
+		dma_addr_t base = smmu->iovmm_base;
+		size_t size = smmu->page_count << PAGE_SHIFT;
+
+		smmu->map[i] = arm_iommu_create_mapping(&platform_bus_type,
+							base, size, 0);
+		if (WARN_ON(IS_ERR(smmu->map[i])))
+			return -EINVAL;
+
+		dev_dbg(smmu->dev, "map:%p %08x-%08x\n",
+			smmu->map[i], base, base + size - 1);
+	}
+
+	return 0;
+}
+
 static int tegra_smmu_probe(struct platform_device *pdev)
 {
 	struct smmu_device *smmu;
@@ -1160,13 +1182,15 @@ static int tegra_smmu_probe(struct platform_device *pdev)
 	if (of_property_read_u32(dev->of_node, "nvidia,#asids", &asids))
 		return -ENODEV;
 
-	bytes = sizeof(*smmu) + asids * sizeof(*smmu->as);
+	bytes = sizeof(*smmu) + asids * (sizeof(*smmu->as) +
+					 sizeof(struct dma_iommu_mapping *));
 	smmu = devm_kzalloc(dev, bytes, GFP_KERNEL);
 	if (!smmu) {
 		dev_err(dev, "failed to allocate smmu_device\n");
 		return -ENOMEM;
 	}
 
+	smmu->map = (struct dma_iommu_mapping **)(smmu->as + asids);
 	smmu->nregs = pdev->num_resources;
 	smmu->regs = devm_kzalloc(dev, 2 * smmu->nregs * sizeof(*smmu->regs),
 				  GFP_KERNEL);
@@ -1238,7 +1262,7 @@ static int tegra_smmu_probe(struct platform_device *pdev)
 	smmu_debugfs_create(smmu);
 	smmu_handle = smmu;
 	bus_set_iommu(&platform_bus_type, &smmu_iommu_ops);
-	return 0;
+	return tegra_smmu_create_default_map(smmu);
 }
 
 static int tegra_smmu_remove(struct platform_device *pdev)
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:54 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:54 +0300
Subject: [PATCH v2 19/22] iommu/tegra: smmu: Workaround PCIe IOMMU'able
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-20-git-send-email-hdoyu@nvidia.com>

Make PCIe work as it is. IOMMU support can be implemented later. We
need the same kind of registration framework for PCIe as platform_bus
does currently.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 drivers/iommu/tegra-smmu.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 33fb7eb..ac5d661 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -330,6 +330,9 @@ static int __smmu_client_set_hwgrp(struct smmu_client *c,
 
 	for_each_set_bit(i, (unsigned long *)&map,
 			 sizeof(map) * BITS_PER_BYTE) {
+		if (i == TEGRA_SWGROUP_AFI) /* FIXME: IOMMU'able PCIe */
+			continue;
+
 		offs = HWGRP_ASID_REG(i);
 		val = smmu_read(smmu, offs);
 		if (on) {
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:53 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:53 +0300
Subject: [PATCH v2 18/22] iommu/tegra: smmu: Use dt-bindings MACRO
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-19-git-send-email-hdoyu@nvidia.com>

Use dt-bindings MACRO instead of SoC dependent MACROs.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 drivers/iommu/tegra-smmu.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index f566972..33fb7eb 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -41,6 +41,8 @@
 #include <asm/cacheflush.h>
 #include <asm/dma-iommu.h>
 
+#include <dt-bindings/memory/tegra-swgroup.h>
+
 /* bitmap of the page sizes currently supported */
 #define SMMU_IOMMU_PGSIZES	(SZ_4K)
 
@@ -744,7 +746,7 @@ static int smmu_iommu_attach_dev(struct iommu_domain *domain,
 	 * Reserve "page zero" for AVP vectors using a common dummy
 	 * page.
 	 */
-	if (map & HWG_AVPC) {
+	if (map & TEGRA_SWGROUP_BIT(AVPC)) {
 		struct page *page;
 
 		page = as->smmu->avp_vector_page;
-- 
1.7.9.5



From hdoyu at nvidia.com  Fri Jul  5 06:44:52 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:44:52 +0300
Subject: [PATCH v2 17/22] iommu/tegra: smmu: Unfied driver for Tegra SoCs
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <1373021097-32420-18-git-send-email-hdoyu@nvidia.com>

Support multiple generation of Tegra SoCs with this unified SMMU
driver. Necessary info is expected to be passed from DT so that this
patch can remove obsolete code now.

Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
---
 drivers/iommu/tegra-smmu.c |   76 +-------------------------------------------
 1 file changed, 1 insertion(+), 75 deletions(-)

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index c7b33f2..f566972 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -41,46 +41,6 @@
 #include <asm/cacheflush.h>
 #include <asm/dma-iommu.h>
 
-enum smmu_hwgrp {
-	HWGRP_AFI,
-	HWGRP_AVPC,
-	HWGRP_DC,
-	HWGRP_DCB,
-	HWGRP_EPP,
-	HWGRP_G2,
-	HWGRP_HC,
-	HWGRP_HDA,
-	HWGRP_ISP,
-	HWGRP_MPE,
-	HWGRP_NV,
-	HWGRP_NV2,
-	HWGRP_PPCS,
-	HWGRP_SATA,
-	HWGRP_VDE,
-	HWGRP_VI,
-
-	HWGRP_COUNT,
-
-	HWGRP_END = ~0,
-};
-
-#define HWG_AFI		(1 << HWGRP_AFI)
-#define HWG_AVPC	(1 << HWGRP_AVPC)
-#define HWG_DC		(1 << HWGRP_DC)
-#define HWG_DCB		(1 << HWGRP_DCB)
-#define HWG_EPP		(1 << HWGRP_EPP)
-#define HWG_G2		(1 << HWGRP_G2)
-#define HWG_HC		(1 << HWGRP_HC)
-#define HWG_HDA		(1 << HWGRP_HDA)
-#define HWG_ISP		(1 << HWGRP_ISP)
-#define HWG_MPE		(1 << HWGRP_MPE)
-#define HWG_NV		(1 << HWGRP_NV)
-#define HWG_NV2		(1 << HWGRP_NV2)
-#define HWG_PPCS	(1 << HWGRP_PPCS)
-#define HWG_SATA	(1 << HWGRP_SATA)
-#define HWG_VDE		(1 << HWGRP_VDE)
-#define HWG_VI		(1 << HWGRP_VI)
-
 /* bitmap of the page sizes currently supported */
 #define SMMU_IOMMU_PGSIZES	(SZ_4K)
 
@@ -150,21 +110,7 @@ enum {
 #define SMMU_TRANSLATION_ENABLE_2		0x230
 
 #define SMMU_AFI_ASID	0x238   /* PCIE */
-#define SMMU_AVPC_ASID	0x23c   /* AVP */
-#define SMMU_DC_ASID	0x240   /* Display controller */
-#define SMMU_DCB_ASID	0x244   /* Display controller B */
-#define SMMU_EPP_ASID	0x248   /* Encoder pre-processor */
-#define SMMU_G2_ASID	0x24c   /* 2D engine */
-#define SMMU_HC_ASID	0x250   /* Host1x */
-#define SMMU_HDA_ASID	0x254   /* High-def audio */
-#define SMMU_ISP_ASID	0x258   /* Image signal processor */
-#define SMMU_MPE_ASID	0x264   /* MPEG encoder */
-#define SMMU_NV_ASID	0x268   /* (3D) */
-#define SMMU_NV2_ASID	0x26c   /* (3D) */
-#define SMMU_PPCS_ASID	0x270   /* AHB */
-#define SMMU_SATA_ASID	0x278   /* SATA */
-#define SMMU_VDE_ASID	0x27c   /* Video decoder */
-#define SMMU_VI_ASID	0x280   /* Video input */
+#define SMMU_SWGRP_ASID_BASE	SMMU_AFI_ASID
 
 #define SMMU_PDE_NEXT_SHIFT		28
 
@@ -236,26 +182,6 @@ enum {
 #define __smmu_client_enable_hwgrp(c, m) __smmu_client_set_hwgrp(c, m, 1)
 #define __smmu_client_disable_hwgrp(c)	__smmu_client_set_hwgrp(c, 0, 0)
 
-#define HWGRP_INIT(client) [HWGRP_##client] = SMMU_##client##_ASID
-
-static const u32 smmu_hwgrp_asid_reg[] = {
-	HWGRP_INIT(AFI),
-	HWGRP_INIT(AVPC),
-	HWGRP_INIT(DC),
-	HWGRP_INIT(DCB),
-	HWGRP_INIT(EPP),
-	HWGRP_INIT(G2),
-	HWGRP_INIT(HC),
-	HWGRP_INIT(HDA),
-	HWGRP_INIT(ISP),
-	HWGRP_INIT(MPE),
-	HWGRP_INIT(NV),
-	HWGRP_INIT(NV2),
-	HWGRP_INIT(PPCS),
-	HWGRP_INIT(SATA),
-	HWGRP_INIT(VDE),
-	HWGRP_INIT(VI),
-};
 #define HWGRP_ASID_REG(x) ((x) * sizeof(u32) + SMMU_AFI_ASID)
 
 /*
-- 
1.7.9.5



From marvin24 at gmx.de  Fri Jul  5 07:03:58 2013
From: marvin24 at gmx.de (Marc Dietrich)
Date: Fri, 05 Jul 2013 13:03:58 +0200
Subject: [PATCH v2 00/22] Unified SMMU driver among Tegra SoCs
In-Reply-To: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
Message-ID: <4999563.JlU6BysXQl@fb07-iapwap2.physik.uni-giessen.de>

Am Freitag, 5. Juli 2013, 13:44:35 schrieb Hiroshi Doyu:
> Hi,
> 
> This series provides:
> 
> (1) Unified SMMU driver among Tegra SoCs

does this affect tegra2 in any way?

> (2) Multiple Address Space support(MASID) in IOMMU(SMMMU)
> (3) Tegra IOMMU'able devices, most of platform devices are IOMMU'able.
> 
> There's some discussion[1] about device population order, which can
> solve the following patches.
> 
>   [HACK] of: dev_node has struct device pointer
>   ARM: tegra: Populate AHB/IOMMU earlier than others
> 
> Also "ARM: dma-mapping: Drop GFP_COMP for DMA memory allocations" may
> not be necessary by [2]
> 
> Tested IOMMU functionality with T30 SD/MMC. Any further testing with
> T114 and/or other devices would be really appreciated.
> 
> v2:
> Updated based on Thierry Reding's and Stephen Warren's feedback
> 
> v1:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/180267.html
> 
> Hiroshi Doyu (22):
>   [HACK] of: dev_node has struct device pointer
>   ARM: tegra: Populate AHB/IOMMU earlier than others
>   ARM: tegra: Create a DT header defining swgroups ID
>   ARM: dt: tegra30: iommu: Add "nvidia,swgroup"
>   ARM: dt: tegra30: iommu: Add "nvidia,memory-client"
>   ARM: dt: tegra114: iommu: Fix IOMMU register address
>   ARM: dt: tegra114: iommu: Add "nvidia,swgroups"
>   ARM: dt: tegra114: Add "nvidia,memory-client"
>   amba: Move AHB to core_initcall
>   iommu/tegra: smmu: Move IOMMU to core_initcall
>   iommu/tegra: smmu: Add Tegra 114 support
>   iommu/tegra: smmu: Select ARM_DMA_USE_IOMMU in Kconfig
>   iommu/tegra: smmu: Create default IOVA maps
>   iommu/tegra: smmu: Register platform_device to IOMMU dynamically
>   iommu/tegra: smmu: Calculate ASID register offset by ID
>   iommu/tegra: smmu: Get "nvidia,swgroup" from DT
>   iommu/tegra: smmu: Unfied driver for Tegra SoCs
>   iommu/tegra: smmu: Use dt-bindings MACRO
>   iommu/tegra: smmu: Workaround PCIe IOMMU'able
>   iommu/tegra: smmu: Get "nvidia,memory-client" from DT
>   iommu/tegra: smmu: Support Multiple ASID
>   ARM: dma-mapping: Drop GFP_COMP for DMA memory allocations
> 
>  .../bindings/iommu/nvidia,tegra30-smmu.txt         |   20 +-
>  arch/arm/boot/dts/tegra114.dtsi                    |   13 +-
>  arch/arm/boot/dts/tegra30.dtsi                     |   21 ++
>  arch/arm/mach-tegra/tegra.c                        |   22 ++
>  arch/arm/mm/dma-mapping.c                          |    7 +
>  drivers/amba/tegra-ahb.c                           |    7 +-
>  drivers/iommu/Kconfig                              |    1 +
>  drivers/iommu/tegra-smmu.c                         |  211
> +++++++++++--------- drivers/of/base.c                                  |  
> 23 +++
>  drivers/of/platform.c                              |    8 +
>  include/dt-bindings/memory/tegra-swgroup.h         |   50 +++++
>  include/linux/of.h                                 |   16 ++
>  12 files changed, 296 insertions(+), 103 deletions(-)
>  create mode 100644 include/dt-bindings/memory/tegra-swgroup.h


From hdoyu at nvidia.com  Fri Jul  5 07:08:36 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Fri, 5 Jul 2013 13:08:36 +0200
Subject: [PATCH v2 00/22] Unified SMMU driver among Tegra SoCs
In-Reply-To: <4999563.JlU6BysXQl@fb07-iapwap2.physik.uni-giessen.de>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com><4999563.JlU6BysXQl@fb07-iapwap2.physik.uni-giessen.de>
Message-ID: <20130705.140836.1744157186948281659.hdoyu@nvidia.com>

Hi Marc,

Marc Dietrich <marvin24 at gmx.de> wrote @ Fri, 5 Jul 2013 13:03:58 +0200:

> Am Freitag, 5. Juli 2013, 13:44:35 schrieb Hiroshi Doyu:
> > Hi,
> > 
> > This series provides:
> > 
> > (1) Unified SMMU driver among Tegra SoCs
> 
> does this affect tegra2 in any way?

No, at all for Tegra 20.
This driver should work with Tegra 30, 114 and 148.


From stefano.stabellini at eu.citrix.com  Fri Jul  5 07:17:43 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 5 Jul 2013 12:17:43 +0100
Subject: [GIT PULL] Xen ARM update for 3.11
Message-ID: <alpine.DEB.2.02.1307041229140.5067@kaball.uk.xensource.com>

Linus,
just one commit this time: the implementation of the tmem hypercall for
arm and arm64.

NOTE: because this change depends on xen support for arm64 that has been
sent to you by Catalin (we agreed that being the very first xen for arm64
set of patches, it should go via the arm64 maintainers), I based this
branch on Catalin's arm64-upstream (see his pull request here
http://marc.info/?l=linux-arm-kernel&m=137269947606106&w=2).

- Stefano



The following changes since commit aa729dccb5e8dfbc78e2e235b8754d6acccee731:

  Merge branch 'for-next/hugepages' of git://git.linaro.org/people/stevecapper/linux into upstream-hugepages (2013-07-01 11:20:58 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git xenarm-for-3.11-tag

Stefano Stabellini (1):
      xen/arm and xen/arm64: implement HYPERVISOR_tmem_op

 arch/arm/include/asm/xen/hypercall.h |    1 +
 arch/arm/xen/enlighten.c             |    1 +
 arch/arm/xen/hypercall.S             |    1 +
 arch/arm64/xen/hypercall.S           |    1 +
 4 files changed, 4 insertions(+), 0 deletions(-)


From laurent.pinchart at ideasonboard.com  Fri Jul  5 07:19:38 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 05 Jul 2013 13:19:38 +0200
Subject: [PATCH v3] ARM: shmobile: lager: Add DT reference
In-Reply-To: <CANqRtoRzBAxeirMyKRqb-PrufFPGDQOqCnkKDEkx1pNsJqXPJA@mail.gmail.com>
References: <1372838251-6314-1-git-send-email-horms+renesas@verge.net.au>
 <1438555.HIWtKGAp3v@avalon>
 <CANqRtoRzBAxeirMyKRqb-PrufFPGDQOqCnkKDEkx1pNsJqXPJA@mail.gmail.com>
Message-ID: <1631144.is6NKUrafF@avalon>

Hi Magnus,

On Friday 05 July 2013 01:25:18 Magnus Damm wrote:
> On Fri, Jul 5, 2013 at 12:02 AM, Laurent Pinchart wrote:
> > On Wednesday 03 July 2013 16:57:31 Simon Horman wrote:
> >> This is sufficient to allow boot of the Lager board with a console
> >> without boards-lager.c compiled into the kernel. This is an example of a
> >> minimal but still useful initialisation of the board using DT as much as
> >> possible.
> >> 
> >> As such it is the same as the boot of Lager that can be achieved without
> >> a board file. The intention of adding this file is to facilitate further
> >> work to allow board specific devices to be initialised via DT.
> > 
> > At some (hopefully not too distant) point we should stop adding both
> > traditional and DT board files. DT is supposed to lower the number of
> > board files, not multiply it by two.
> 
> Well, mr-multiply-by-two: While I dislike code duplication I can't recall
> when the number of files actually decreased with DT.
>
> I realize that when we can use DT fully to describe a board then a single
> DTS file is enough to describe board specific hardware together with per-SoC
> C code. I can't however see how that would reduce the number of files, but
> whatever. I always thought the goal was to reduce the memory footprint of
> the kernel and that the source would not come with that many limitations,
> but it seems that I got that all wrong...

I meant board files, sorry. The total number of files hasn't decreased much, 
if at all.

> Anyway, the current split on mach-shmobile is intentional:
> 
> 1) The C version of board support (board-xxx.c)
> 
> This is where platform devices are used (with power domains in some cases)
> and where out-of-tree people can experiment with things. This code is using
> legacy SH clock code and is not targeted for multiplatform. These should go
> away, the sooner the better.
> 
> 2) The DT reference support (board-xxx-reference.c)
> 
> This file contains whatever bits of C code needed to get the DT support
> going. All the board specific devices should be described via DT. The DT
> reference board support is where we build incremental support to catch up
> with 1) board-xxx.c. Ideally we wouldn't need the board-xxx-reference.c file
> and instead only go with .dts, but in some cases we need some extra glue and
> until pinctrl DT is done we also need those written in C. The DT reference
> support will use common clocks as soon as they are available.
> 
> 3) SoC DT support (setup-xxx.c)
> 
> This is what will be used when 2) is caught up with 1). Common clocks and
> multiplatform, one SoC at a time.

Thanks for the clarification.

> > Work is still needed in order to achieve this, as we lack DT bindings for
> > core (and non core) devices. That's something we need to work on. As a
> > first step, do we have a roadmap with a list of devices that lack DT
> > support ? At the very least I see more work needed on
> > 
> > - Common clock framework
> 
> Yes, I agree. Please see below for more about that.
> 
> > - SCI
> 
> Indeed, someone needs to continue earlier efforts for the SCIF driver.

It shouldn't be too difficult, Bastian has already layed out a plan, but the 
dependency on DT clock bindings has prevented the patches from going upstream.

> Fortunately, with EMEV2 our UART driver already supports DT, so we can
> implement DT-only multiplatform support on EMEV2 regardless of the state of
> SCIF.
> 
> > - Timers
> 
> We can use DT-only with Arch timer, but unfortunately another clock evenit
> is needed unconditionally for high resolution timer support, search for
> clock event and the C3STOP flag if you want to see me moan about that.
> 
> Regardless I believe someone took a couple of first steps towards DT support
> for our timers some time ago. But as we discussed face to face about a month
> ago, it makes sense to describe the hardware via DT but in case of timers
> and clock event / clock sources it does not make sense to associate 87 timer
> channels for operating system time keeping. So we need some user space
> configuration interface to associate different kind of timer applications
> (operating system timer, PWM, clock generation, etc) to different channels.

I agree that we need an API for this. It might make sense to restrict the API 
to in-kernel usage to start with, but we need an API nonetheless. Has this 
topic been discussed with clocks/timers people ? It might be worth bringing it 
up for LPC or KS.

> Since you mention it: =)
> - PINCTRL DT and GPIO DT
>
> I'd like to start picking up the remaining PINCTRL and GPIO bits for
> v3.12 merge. Can you please rebase and resend on top of the latest
> renesas-next tag?

Patches for v3.12 have been sent yesterday :-)

> > We shouldn't delay CCF much longer, v3.12 seems an achievable target to
> > me. Who will work on that ?
> 
> So I am currently preparing EMEV2 for multiplatform, will most likely have
> patches posted for that next week. And yes, I intend to send a new DT
> reference board support file.
> 
> In parallel Kuribayashi-san is taking a stab at moving to common clocks for
> EMEV2 as a first step.

That's great news. I'm looking forward to reviewing the patches :-)

> I expect the above to be in order for v3.12, but not much more that that.

That sounds like a reasonable time frame to me.

-- 
Cheers,

Laurent Pinchart



From jonas.jensen at gmail.com  Fri Jul  5 07:46:13 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Fri,  5 Jul 2013 13:46:13 +0200
Subject: [PATCH v7] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <1373018653-18421-1-git-send-email-jonas.jensen@gmail.com>
References: <1373018653-18421-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1373024773-24574-1-git-send-email-jonas.jensen@gmail.com>

This patch adds an clocksource driver for the main timer(s)
found on MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130703
    
    Changes since v6:
    
    1. remove TIMER_CR read back
    2. set TIMER_CR from constants

 drivers/clocksource/Makefile       |   1 +
 drivers/clocksource/moxart_timer.c | 164 +++++++++++++++++++++++++++++++++++++
 2 files changed, 165 insertions(+)
 create mode 100644 drivers/clocksource/moxart_timer.c

diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 9ba8b4d..56257f6 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_CLKSRC_DBX500_PRCMU)	+= clksrc-dbx500-prcmu.o
 obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
 obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
 obj-$(CONFIG_ARCH_MARCO)	+= timer-marco.o
+obj-$(CONFIG_ARCH_MOXART)	+= moxart_timer.o
 obj-$(CONFIG_ARCH_MXS)		+= mxs_timer.o
 obj-$(CONFIG_ARCH_PRIMA2)	+= timer-prima2.o
 obj-$(CONFIG_SUN4I_TIMER)	+= sun4i_timer.o
diff --git a/drivers/clocksource/moxart_timer.c b/drivers/clocksource/moxart_timer.c
new file mode 100644
index 0000000..5743853
--- /dev/null
+++ b/drivers/clocksource/moxart_timer.c
@@ -0,0 +1,164 @@
+/*
+ * MOXA ART SoCs timer handling.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqreturn.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/io.h>
+#include <linux/clocksource.h>
+
+#define TIMER1_BASE		0x00
+#define TIMER2_BASE		0x10
+#define TIMER3_BASE		0x20
+
+#define REG_COUNT		0x0 /* writable */
+#define REG_LOAD		0x4
+#define REG_MATCH1		0x8
+#define REG_MATCH2		0xC
+
+#define TIMER_CR		0x30
+#define TIMER_INTR_STATE	0x34
+#define TIMER_INTR_MASK		0x38
+
+/*
+ * TIMER_CR flags:
+ *
+ * TIMEREG_CR_*_CLOCK	0: PCLK, 1: EXT1CLK
+ * TIMEREG_CR_*_INT	overflow interrupt enable bit
+ */
+#define TIMEREG_CR_1_ENABLE	(1 << 0)
+#define TIMEREG_CR_1_CLOCK	(1 << 1)
+#define TIMEREG_CR_1_INT	(1 << 2)
+#define TIMEREG_CR_2_ENABLE	(1 << 3)
+#define TIMEREG_CR_2_CLOCK	(1 << 4)
+#define TIMEREG_CR_2_INT	(1 << 5)
+#define TIMEREG_CR_3_ENABLE	(1 << 6)
+#define TIMEREG_CR_3_CLOCK	(1 << 7)
+#define TIMEREG_CR_3_INT	(1 << 8)
+#define TIMEREG_CR_COUNT_UP	(1 << 9)
+#define TIMEREG_CR_COUNT_DOWN	(0 << 9)
+
+#define TIMER1_ENABLE		(TIMEREG_CR_2_ENABLE | TIMEREG_CR_1_ENABLE)
+#define TIMER1_DISABLE		(TIMEREG_CR_2_ENABLE)
+
+static void __iomem *base;
+static unsigned int clock_count_per_tick;
+
+static void moxart_clkevt_mode(enum clock_event_mode mode,
+			       struct clock_event_device *clk)
+{
+	switch (mode) {
+	case CLOCK_EVT_MODE_RESUME:
+	case CLOCK_EVT_MODE_ONESHOT:
+		writel(TIMER1_DISABLE, base + TIMER_CR);
+		writel(~0, base + TIMER1_BASE + REG_LOAD);
+		break;
+	case CLOCK_EVT_MODE_PERIODIC:
+		writel(clock_count_per_tick, base + TIMER1_BASE + REG_LOAD);
+		writel(TIMER1_ENABLE, base + TIMER_CR);
+		break;
+	case CLOCK_EVT_MODE_UNUSED:
+	case CLOCK_EVT_MODE_SHUTDOWN:
+	default:
+		writel(TIMER1_DISABLE, base + TIMER_CR);
+		break;
+	}
+}
+
+static int moxart_clkevt_next_event(unsigned long cycles,
+				    struct clock_event_device *unused)
+{
+	u32 u;
+
+	writel(TIMER1_DISABLE, base + TIMER_CR);
+
+	u = readl(base + TIMER1_BASE + REG_COUNT) - cycles;
+	writel(u, base + TIMER1_BASE + REG_MATCH1);
+
+	writel(TIMER1_ENABLE, base + TIMER_CR);
+
+	return 0;
+}
+
+static struct clock_event_device moxart_clockevent = {
+	.name		= "moxart_timer",
+	.rating		= 200,
+	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
+	.set_mode	= moxart_clkevt_mode,
+	.set_next_event	= moxart_clkevt_next_event,
+};
+
+static irqreturn_t moxart_timer_interrupt(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+	evt->event_handler(evt);
+	return IRQ_HANDLED;
+}
+
+static struct irqaction moxart_timer_irq = {
+	.name		= "moxart-timer",
+	.flags		= IRQF_TIMER,
+	.handler	= moxart_timer_interrupt,
+	.dev_id		= &moxart_clockevent,
+};
+
+static void __init moxart_timer_init(struct device_node *node)
+{
+	int ret, irq;
+	unsigned long pclk;
+	struct clk *clk;
+
+	base = of_iomap(node, 0);
+	if (!base)
+		panic("%s: of_iomap failed\n", node->full_name);
+
+	irq = irq_of_parse_and_map(node, 0);
+	if (irq <= 0)
+		panic("%s: irq_of_parse_and_map failed\n", node->full_name);
+
+	ret = setup_irq(irq, &moxart_timer_irq);
+	if (ret)
+		panic("%s: setup_irq failed\n", node->full_name);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk))
+		panic("%s: of_clk_get failed\n", node->full_name);
+
+	pclk = clk_get_rate(clk);
+
+	if (clocksource_mmio_init(base + TIMER2_BASE + REG_COUNT,
+				  "moxart_timer", pclk, 200, 32,
+				  clocksource_mmio_readl_down))
+		panic("%s: clocksource_mmio_init failed\n", node->full_name);
+
+	clock_count_per_tick = DIV_ROUND_CLOSEST(pclk, HZ);
+
+	writel(~0, base + TIMER2_BASE + REG_LOAD);
+	writel(TIMEREG_CR_2_ENABLE, base + TIMER_CR);
+
+	moxart_clockevent.cpumask = cpumask_of(0);
+
+	/*
+	 * documentation is not publicly available:
+	 * min_delta / max_delta obtained by trial-and-error,
+	 * max_delta 0xfffffffe should be ok because count
+	 * register size is u32
+	 */
+	clockevents_config_and_register(&moxart_clockevent, pclk,
+					0x4, 0xfffffffe);
+}
+CLOCKSOURCE_OF_DECLARE(moxart, "moxa,moxart-timer", moxart_timer_init);
-- 
1.8.2.1



From jonas.jensen at gmail.com  Fri Jul  5 07:48:44 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Fri, 5 Jul 2013 13:48:44 +0200
Subject: [PATCH v5] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <alpine.DEB.2.02.1307051213080.11637@ionos.tec.linutronix.de>
References: <1372687359-18235-1-git-send-email-jonas.jensen@gmail.com>
 <1372940383-5957-1-git-send-email-jonas.jensen@gmail.com>
 <alpine.DEB.2.02.1307042211420.11637@ionos.tec.linutronix.de>
 <CACmBeS03Xfo7DyyYUbpBaO8TeR3g8BTPzcoOzQayk40k1soFzA@mail.gmail.com>
 <alpine.DEB.2.02.1307051213080.11637@ionos.tec.linutronix.de>
Message-ID: <CACmBeS1djCBWeXwCQROtvyodCfunusr-3=CKOk294P+FF-h6wA@mail.gmail.com>

Thanks for the replies Thomas.

On 5 July 2013 12:21, Thomas Gleixner <tglx at linutronix.de> wrote:
> Because you need to preserve the CR2 enable bit so your clocksource
> does not get switched off.

Yes, that was my main concern. The possibility of more flags being added.
I was experimenting with TIMEREG_CR_COUNT_UP but could never get REG_MATCH1
to work right for oneshot mode.

Please take a look at v7.

Best regards,
Jonas


From shinya.kuribayashi.px at renesas.com  Fri Jul  5 07:50:24 2013
From: shinya.kuribayashi.px at renesas.com (Shinya Kuribayashi)
Date: Fri, 05 Jul 2013 20:50:24 +0900
Subject: hrtimer: one more expiry time overflow check in hrtimer_interrupt
In-Reply-To: <alpine.DEB.2.02.1306281416080.4013@ionos.tec.linutronix.de>
References: <51B6D4C4.9080400@renesas.com>
 <alpine.DEB.2.02.1306281416080.4013@ionos.tec.linutronix.de>
Message-ID: <51D6B300.20804@renesas.com>

On 6/28/2013 9:22 PM, Thomas Gleixner wrote:
>> On the other hand, we have another call site of tick_program_event() at
>> the bottom of hrtimer_interrupt().  The warning this time is triggered
>> there, so we need to apply the same fix to it.
> 
> Well, the problem is that you are just papering over the underlying
> issue of 32bit systems not being prepared for the year 2038 issue.
> 
> Just blindly silencing the warning is not going to make the system
> survive 2038 in any sane way. All timespec/val related time functions
> dealing with the clock realtime domain are simply broken in 2038 on
> 32bit, so it does not matter whether a warning triggers or not.

You're right.  With this patch applied, the hrtimer_interrupt /looks/
back to normal, but /proc/timer_list still show that "expires at [in
negative range]":

    active timers:
     #0: tick_cpu_sched, tick_sched_timer, S:01
     # expires at 50812500000-50812500000 nsecs [in -165398341280 to -165398341280 nsecs]

This shouldn't happen and something weird is still going on.

> We really need to tackle the underlying problem and not bandaiding a
> known to be broken system.

Agreed, but a little bit hard task for me.  This is 100% reproducible,
so I can help debug / verification.  Please let me know, if necessary.

Thanks for your comments,
--
Shinya Kuribayashi
Renesas Electronics


From tony at atomide.com  Fri Jul  5 07:59:59 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 5 Jul 2013 04:59:59 -0700
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
References: <51D577E6.5010507@newflow.co.uk> <51D59146.3070002@newflow.co.uk>
 <51D59C0E.8080003@newflow.co.uk>
 <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
Message-ID: <20130705115959.GQ5523@atomide.com>

* Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 01:17]:
> On Thu, Jul 04, 2013 at 21:30:14, Mark Jackson wrote:
> > On 04/07/13 16:14, Mark Jackson wrote:
> > > On 04/07/13 14:25, Mark Jackson wrote:
> > >> Our custom AM335x board has been booting just fine under 3.10.0-rc4.
> > >>
> > >> I've just done a git pull to update to 3.10 (now that it's released)
> > >> and the board now hangs.
> > >>
> > >> Before I start trying to bisect the issue, does anyone have an clues ?
> > > 
> > > Okay ... I've now bisected it to:-
> > > 
> > > a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
> > > commit a630fbfbb1beeffc5bbe542a7986bf2068874633
> > > Author: Tony Lindgren <tony at atomide.com>
> > > Date:   Mon Jun 10 07:39:09 2013 -0700
> > > 
> > >     serial: omap: Fix device tree based PM runtime
> > 
> > However, reverting the commit does *not* fix the issue, weird !!
> > 
> > But I have now tested:-
> > 
> > v3.10-rc4     -> works
> > v3.10-rc5     -> works
> > v3.10-rc6     -> works
> > v3.10-rc7     -> works
> > v3.10         -> works
> > origin/master -> hangs
> > 
> > Any ideas ?
> 
> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> also results in the console UART getting reset and idled during bootup and that's where
> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> the system booting fine. 
> 
> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> omap_serial_early_init() to get earlyprintk working again.

Hmm nothing should get idled while earlyprintk is running, and then when the
serial driver kicks in it should not idle anything by default. And for DT based
booting we should not have mach-omap2/serial.c initialize anything.

I wonder if this is because the timeouts get now initialized to 0 instead
of -1 for the serial driver?

Regards,

Tony
 
> [1] http://www.spinics.net/lists/linux-omap/msg91825.html
> 


From festevam at gmail.com  Fri Jul  5 08:09:52 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 5 Jul 2013 09:09:52 -0300
Subject: [PATCH v6] video: imxfb: Add DT support
In-Reply-To: <20130528110927.GA23653@game.jcrosoft.org>
References: <1369564538-21835-1-git-send-email-mpa@pengutronix.de>
 <20130528110927.GA23653@game.jcrosoft.org>
Message-ID: <CAOMZO5A-1gacTOSrpZ4HKfwq13mug+uNCS3m4gyFp1WT21_JeQ@mail.gmail.com>

Hi Jean-Christophe,

On Tue, May 28, 2013 at 8:09 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj at jcrosoft.com> wrote:
> On 12:35 Sun 26 May     , Markus Pargmann wrote:
>> Add devicetree support for imx framebuffer driver. It uses the generic
>> display bindings and helper functions.
>>
>> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
>> Cc: Fabio Estevam <festevam at gmail.com>
>> Cc: Mark Rutland <mark.rutland at arm.com>
>> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
>
> Applied thanks

Still don't see this patch in linux-next. Could you please check?


From pullip.cho at samsung.com  Fri Jul  5 08:29:05 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 05 Jul 2013 21:29:05 +0900
Subject: [PATCH v7 00/12] iommu/exynos: Fixes and Enhancements of System MMU
 driver with DT
Message-ID: <002801ce797b$3d2fbc80$b78f3580$@samsung.com>

The current exynos-iommu(System MMU) driver does not work autonomously
since it is lack of support for power management of peripheral blocks.
For example, MFC device driver must ensure that its System MMU is disabled
before MFC block is power-down not to invalidate IOTLB in the System MMU
when I/O memory mapping is changed. Because A System MMU is resides in the
same H/W block, access to control registers of System MMU while the H/W
block is turned off must be prohibited.

This set of changes solves the above problem with setting each System MMUs
as the parent of the device which owns the System MMU to recieve the
information when the device is turned off or turned on.

Another big change to the driver is the support for devicetree.
The bindings for System MMU is described in
Documentation/devicetree/bindings/arm/samsung/system-mmu.txt

In addition, this patchset also includes several bug fixes and enhancements
of the current driver.

Change log:
v7:
- Rebased on the stable 3.10
- Registered PM domains and gate clocks with DT
- Changed connection method between a System MMU and its master H/W
   'mmu-master' property in the node of System MMU
   --> 'iommu' property in the node of master H/W
- Marking device descriptor of master H/W of a System MMU with bus notifier.
- Power management (PM_RUNTIME, PM_SLEEP) of System MMUs with gpd_dev_ops
   of Generic IO Powerdomain. gpd_dev_ops are set to the master H/Ws
   before they are probed in the bus notifier.
- Removed additional debugging features like debugfs entries and
   version names.
- Removed support for advanced features of System MMU 3.2 and 3.3
   the current IOMMU API cannot handle the feature
  (A kind of L2 TLB that fetches several consequence page table entries.
   It must be initialized by the driver of master H/W whenever it works.)

v6:
- Rebased on the branch, next/iommu-exynos of
  git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git

v5:
- new bugfix: patch 01
- Reordered patches
  * patch 01 ~ 05: Bugfix and enhancements of the existing driver
  * patch 06 ~ 10: Device Tree support and callbacks for power management
  * patch 11     : System MMU 3.2 and 3.3 support
  * patch 12 ~ 14: Debugging features
- Additional code compaction

v4:
- Remove Change-Id from v3 patches
- Change the order of the third and the first patch
  Thanks to Kukjin Kim.
- Fix memory leak when allocating and assigning exynos_iommu_owner to client
  device if the client device has multiple System MMUs.
  Thanks to Rahul Sharma.

v3:
- Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
- Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
  Thanks to Prathyush.

v2:
- Split the patch to iommu/exynos into 9 patches
- Support for System MMU 3.3
- Some code compaction

Patch summary:
[PATCH v7 1/9] iommu/exynos: do not include removed header
[PATCH v7 2/9] iommu/exynos: add missing cache flush for removed page table entries
[PATCH v7 3/9] iommu/exynos: fix page table maintenance
[PATCH v7 4/9] iommu/exynos: allocate lv2 page table from own slab
[PATCH v7 5/9] iommu/exynos: change rwlock to spinlock
[PATCH v7 6/9] clk: exynos5250: add gate clock descriptions of System MMU
[PATCH v7 7/9] ARM: dts: Add description of System MMU of Exynos SoCs
[PATCH v7 8/9] iommu/exynos: support for device tree
[PATCH v7 9/9] iommu/exynos: add bus notifier for registering System MMU

Diffstats:
.../devicetree/bindings/clock/exynos5250-clock.txt |   28 +-
.../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 ++
arch/arm/boot/dts/exynos4.dtsi                     |  122 +++
arch/arm/boot/dts/exynos4210.dtsi                  |   25 +
arch/arm/boot/dts/exynos4x12.dtsi                  |   76 ++
arch/arm/boot/dts/exynos5250.dtsi                  |  291 ++++++
drivers/clk/samsung/clk-exynos5250.c               |   57 +-
drivers/iommu/Kconfig                              |    5 +-
drivers/iommu/exynos-iommu.c                       | 1011 +++++++++++++-------
9 files changed, 1382 insertions(+), 336 deletions(-)



From pullip.cho at samsung.com  Fri Jul  5 08:29:09 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 05 Jul 2013 21:29:09 +0900
Subject: [PATCH v7 1/9] iommu/exynos: do not include removed header
Message-ID: <002901ce797b$3fce5c30$bf6b1490$@samsung.com>

This commit remove <mach/sysmmu.h> which is removed.

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 3f32d64..233f382 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -12,6 +12,7 @@
 #define DEBUG
 #endif
 
+#include <linux/kernel.h>
 #include <linux/io.h>
 #include <linux/interrupt.h>
 #include <linux/platform_device.h>
@@ -29,8 +30,6 @@
 #include <asm/cacheflush.h>
 #include <asm/pgtable.h>
 
-#include <mach/sysmmu.h>
-
 /* We does not consider super section mapping (16MB) */
 #define SECT_ORDER 20
 #define LPAGE_ORDER 16
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul  5 08:29:13 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 05 Jul 2013 21:29:13 +0900
Subject: [PATCH v7 2/9] iommu/exynos: add missing cache flush for removed page
 table entries
Message-ID: <002a01ce797b$421b5970$c6520c50$@samsung.com>

This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 233f382..e3be3e5 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
 	if (lv2ent_small(ent)) {
 		*ent = 0;
 		size = SPAGE_SIZE;
+		pgtable_flush(ent, ent +1);
 		priv->lv2entcnt[lv1ent_offset(iova)] += 1;
 		goto done;
 	}
@@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
 	BUG_ON(size < LPAGE_SIZE);
 
 	memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
+	pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
 
 	size = LPAGE_SIZE;
 	priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE;
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul  5 08:29:18 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 05 Jul 2013 21:29:18 +0900
Subject: [PATCH v7 3/9] iommu/exynos: fix page table maintenance
Message-ID: <002b01ce797b$44d4ad10$ce7e0730$@samsung.com>

This prevents allocating lv2 page table for the lv1 page table entry
that already has 1MB page mapping. In addition some BUG_ON() is
changed to WARN_ON().

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |   34 ++++++++++++++++++++++++++--------
 1 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index e3be3e5..2bfe9fa 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -862,12 +862,14 @@ static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long iova,
 		pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
 		BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
 		if (!pent)
-			return NULL;
+			return ERR_PTR(-ENOMEM);
 
 		*sent = mk_lv1ent_page(__pa(pent));
 		*pgcounter = NUM_LV2ENTRIES;
 		pgtable_flush(pent, pent + NUM_LV2ENTRIES);
 		pgtable_flush(sent, sent + 1);
+	} else if (lv1ent_section(sent)) {
+		return ERR_PTR(-EADDRINUSE);
 	}
 
 	return page_entry(sent, iova);
@@ -944,16 +946,16 @@ static int exynos_iommu_map(struct iommu_domain *domain, unsigned long iova,
 		pent = alloc_lv2entry(entry, iova,
 					&priv->lv2entcnt[lv1ent_offset(iova)]);
 
-		if (!pent)
-			ret = -ENOMEM;
+		if (IS_ERR(pent))
+			ret = PTR_ERR(pent);
 		else
 			ret = lv2set_page(pent, paddr, size,
 					&priv->lv2entcnt[lv1ent_offset(iova)]);
 	}
 
 	if (ret) {
-		pr_debug("%s: Failed to map iova 0x%lx/0x%x bytes\n",
-							__func__, iova, size);
+		pr_err("%s: Failed(%d) to map iova 0x%#x bytes @ %#lx\n",
+						__func__, ret, size, iova);
 	}
 
 	spin_unlock_irqrestore(&priv->pgtablelock, flags);
@@ -968,6 +970,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
 	struct sysmmu_drvdata *data;
 	unsigned long flags;
 	unsigned long *ent;
+	size_t err_page;
 
 	BUG_ON(priv->pgtable == NULL);
 
@@ -976,7 +979,8 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
 	ent = section_entry(priv->pgtable, iova);
 
 	if (lv1ent_section(ent)) {
-		BUG_ON(size < SECT_SIZE);
+		if (WARN_ON(size < SECT_SIZE))
+			goto err;
 
 		*ent = 0;
 		pgtable_flush(ent, ent + 1);
@@ -1008,7 +1012,8 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
 	}
 
 	/* lv1ent_large(ent) == true here */
-	BUG_ON(size < LPAGE_SIZE);
+	if (WARN_ON(size < LPAGE_SIZE))
+		goto err;
 
 	memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
 	pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
@@ -1023,8 +1028,21 @@ done:
 		sysmmu_tlb_invalidate_entry(data->dev, iova);
 	spin_unlock_irqrestore(&priv->lock, flags);
 
-
 	return size;
+err:
+	spin_unlock_irqrestore(&priv->pgtablelock, flags);
+
+	err_page = (
+		((unsigned long)ent - (unsigned long)priv->pgtable)
+			< (NUM_LV1ENTRIES * sizeof(long))
+			   ) ?  SECT_SIZE : LPAGE_SIZE;
+
+	pr_err("%s: Failed due to size(%#lx) @ %#x is"\
+		" smaller than page size %#x\n",
+		__func__, iova, size, err_page);
+
+	       return 0;
+
 }
 
 static phys_addr_t exynos_iommu_iova_to_phys(struct iommu_domain *domain,
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul  5 08:29:22 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 05 Jul 2013 21:29:22 +0900
Subject: [PATCH v7 4/9] iommu/exynos: allocate lv2 page table from own slab
Message-ID: <002c01ce797b$47a1fde0$d6e5f9a0$@samsung.com>

Since kmalloc() does not guarantee that the allignment of 1KiB when it
allocates 1KiB, it is required to allocate lv2 page table from own
slab that guarantees alignment of 1KiB

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |   24 ++++++++++++++++++++----
 1 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 2bfe9fa..390f8b7 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -100,6 +100,8 @@
 #define REG_PB1_SADDR		0x054
 #define REG_PB1_EADDR		0x058
 
+static struct kmem_cache *lv2table_kmem_cache;
+
 static unsigned long *section_entry(unsigned long *pgtable, unsigned long iova)
 {
 	return pgtable + lv1ent_offset(iova);
@@ -765,7 +767,8 @@ static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
 
 	for (i = 0; i < NUM_LV1ENTRIES; i++)
 		if (lv1ent_page(priv->pgtable + i))
-			kfree(__va(lv2table_base(priv->pgtable + i)));
+			kmem_cache_free(lv2table_kmem_cache,
+					__va(lv2table_base(priv->pgtable + i)));
 
 	free_pages((unsigned long)priv->pgtable, 2);
 	free_pages((unsigned long)priv->lv2entcnt, 1);
@@ -859,7 +862,7 @@ static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long iova,
 	if (lv1ent_fault(sent)) {
 		unsigned long *pent;
 
-		pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
+		pent = kmem_cache_zalloc(lv2table_kmem_cache, GFP_ATOMIC);
 		BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
 		if (!pent)
 			return ERR_PTR(-ENOMEM);
@@ -884,7 +887,7 @@ static int lv1set_section(unsigned long *sent, phys_addr_t paddr, short *pgcnt)
 		if (*pgcnt != NUM_LV2ENTRIES)
 			return -EADDRINUSE;
 
-		kfree(page_entry(sent, 0));
+		kmem_cache_free(lv2table_kmem_cache, page_entry(sent, 0));
 
 		*pgcnt = 0;
 	}
@@ -1088,10 +1091,23 @@ static int __init exynos_iommu_init(void)
 {
 	int ret;
 
+	lv2table_kmem_cache = kmem_cache_create("exynos-iommu-lv2table",
+				LV2TABLE_SIZE, LV2TABLE_SIZE, 0, NULL);
+	if (!lv2table_kmem_cache) {
+		pr_err("%s: Failed to create kmem cache\n", __func__);
+		return -ENOMEM;
+	}
+
 	ret = platform_driver_register(&exynos_sysmmu_driver);
 
 	if (ret == 0)
-		bus_set_iommu(&platform_bus_type, &exynos_iommu_ops);
+		ret = bus_set_iommu(&platform_bus_type, &exynos_iommu_ops);
+
+	if (ret) {
+		pr_err("%s: Failed to register exynos-iommu driver.\n",
+								__func__);
+		kmem_cache_destroy(lv2table_kmem_cache);
+	}
 
 	return ret;
 }
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul  5 08:29:26 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 05 Jul 2013 21:29:26 +0900
Subject: [PATCH v7 5/9] iommu/exynos: change rwlock to spinlock
Message-ID: <002d01ce797b$49c441a0$dd4cc4e0$@samsung.com>

Since acquiring read_lock is not more frequent than write_lock, it is
not beneficial to use rwlock, this commit changes rwlock to spinlock.

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |   32 ++++++++++++++++----------------
 1 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 390f8b7..6793661 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -175,7 +175,7 @@ struct sysmmu_drvdata {
 	void __iomem **sfrbases;
 	struct clk *clk[2];
 	int activations;
-	rwlock_t lock;
+	spinlock_t lock;
 	struct iommu_domain *domain;
 	sysmmu_fault_handler_t fault_handler;
 	unsigned long pgtable;
@@ -259,7 +259,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
 	BUG_ON((base0 + size0) <= base0);
 	BUG_ON((size1 > 0) && ((base1 + size1) <= base1));
 
-	read_lock_irqsave(&data->lock, flags);
+	spin_lock_irqsave(&data->lock, flags);
 	if (!is_sysmmu_active(data))
 		goto finish;
 
@@ -289,7 +289,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
 		}
 	}
 finish:
-	read_unlock_irqrestore(&data->lock, flags);
+	spin_unlock_irqrestore(&data->lock, flags);
 }
 
 static void __set_fault_handler(struct sysmmu_drvdata *data,
@@ -297,9 +297,9 @@ static void __set_fault_handler(struct sysmmu_drvdata *data,
 {
 	unsigned long flags;
 
-	write_lock_irqsave(&data->lock, flags);
+	spin_lock_irqsave(&data->lock, flags);
 	data->fault_handler = handler;
-	write_unlock_irqrestore(&data->lock, flags);
+	spin_unlock_irqrestore(&data->lock, flags);
 }
 
 void exynos_sysmmu_set_fault_handler(struct device *dev,
@@ -347,7 +347,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 
 	int i, ret = -ENOSYS;
 
-	read_lock(&data->lock);
+	spin_lock(&data->lock);
 
 	WARN_ON(!is_sysmmu_active(data));
 
@@ -391,7 +391,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 	if (itype != SYSMMU_FAULT_UNKNOWN)
 		sysmmu_unblock(data->sfrbases[i]);
 
-	read_unlock(&data->lock);
+	spin_unlock(&data->lock);
 
 	return IRQ_HANDLED;
 }
@@ -402,7 +402,7 @@ static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
 	bool disabled = false;
 	int i;
 
-	write_lock_irqsave(&data->lock, flags);
+	spin_lock_irqsave(&data->lock, flags);
 
 	if (!set_sysmmu_inactive(data))
 		goto finish;
@@ -419,7 +419,7 @@ static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
 	data->pgtable = 0;
 	data->domain = NULL;
 finish:
-	write_unlock_irqrestore(&data->lock, flags);
+	spin_unlock_irqrestore(&data->lock, flags);
 
 	if (disabled)
 		dev_dbg(data->sysmmu, "(%s) Disabled\n", data->dbgname);
@@ -442,7 +442,7 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
 	int i, ret = 0;
 	unsigned long flags;
 
-	write_lock_irqsave(&data->lock, flags);
+	spin_lock_irqsave(&data->lock, flags);
 
 	if (!set_sysmmu_active(data)) {
 		if (WARN_ON(pgtable != data->pgtable)) {
@@ -481,7 +481,7 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
 
 	dev_dbg(data->sysmmu, "(%s) Enabled\n", data->dbgname);
 finish:
-	write_unlock_irqrestore(&data->lock, flags);
+	spin_unlock_irqrestore(&data->lock, flags);
 
 	return ret;
 }
@@ -528,7 +528,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
 	unsigned long flags;
 	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
 
-	read_lock_irqsave(&data->lock, flags);
+	spin_lock_irqsave(&data->lock, flags);
 
 	if (is_sysmmu_active(data)) {
 		int i;
@@ -545,7 +545,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
 			data->dbgname);
 	}
 
-	read_unlock_irqrestore(&data->lock, flags);
+	spin_unlock_irqrestore(&data->lock, flags);
 }
 
 void exynos_sysmmu_tlb_invalidate(struct device *dev)
@@ -553,7 +553,7 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
 	unsigned long flags;
 	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
 
-	read_lock_irqsave(&data->lock, flags);
+	spin_lock_irqsave(&data->lock, flags);
 
 	if (is_sysmmu_active(data)) {
 		int i;
@@ -569,7 +569,7 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
 			data->dbgname);
 	}
 
-	read_unlock_irqrestore(&data->lock, flags);
+	spin_unlock_irqrestore(&data->lock, flags);
 }
 
 static int exynos_sysmmu_probe(struct platform_device *pdev)
@@ -666,7 +666,7 @@ static int exynos_sysmmu_probe(struct platform_device *pdev)
 	}
 
 	data->sysmmu = dev;
-	rwlock_init(&data->lock);
+	spin_lock_init(&data->lock);
 	INIT_LIST_HEAD(&data->node);
 
 	__set_fault_handler(data, &default_fault_handler);
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul  5 08:29:33 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 05 Jul 2013 21:29:33 +0900
Subject: [PATCH v7 6/9] clk: exynos5250: add gate clock descriptions of System
 MMU
Message-ID: <002e01ce797b$4dc46d20$e94d4760$@samsung.com>

This adds gate clocks of all System MMUs and their master IPs
that are not apeared in clk-exynos5250.c

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
CC: Thomas Abraham <thomas.abraham at linaro.org>
---
 .../devicetree/bindings/clock/exynos5250-clock.txt |   28 +++++++++-
 drivers/clk/samsung/clk-exynos5250.c               |   57 ++++++++++++++++---
 2 files changed, 75 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 781a627..df49694 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -154,7 +154,33 @@ clock which they consume.
   dsim0			341
   dp			342
   mixer			343
-  hdmi			345
+  hdmi			344
+  camif_top		345
+  smmu_fimc_lite0	346
+  smmu_fimc_lite1	347
+  smmu_fimc_lite2	348
+  smmu_tv		349
+  smmu_fimd1		350
+  smmu_2d		351
+  fimc_isp		352
+  fimc_drc		353
+  fimc_fd		354
+  fimc_scc		355
+  fimc_scp		356
+  fimc_mcuctl		357
+  fimc_odc		358
+  fimc_dis		359
+  fimc_3dnr		360
+  smmu_fimc_isp		361
+  smmu_fimc_drc		362
+  smmu_fimc_fd		363
+  smmu_fimc_scc		364
+  smmu_fimc_scp		365
+  smmu_fimc_mcuctl	366
+  smmu_fimc_odc		367
+  smmu_fimc_dis0	368
+  smmu_fimc_dis1	369
+  smmu_fimc_3dnr	370
 
 Example 1: An example of a clock controller node is listed below.
 
diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index 22d7699..1921d6c 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -53,12 +53,15 @@
 #define DIV_PERIC3		0x10564
 #define DIV_PERIC4		0x10568
 #define DIV_PERIC5		0x1056c
+#define GATE_IP_ISP0		0x0C800
+#define GATE_IP_ISP1		0x0C800
 #define GATE_IP_GSCL		0x10920
 #define GATE_IP_MFC		0x1092c
 #define GATE_IP_GEN		0x10934
 #define GATE_IP_FSYS		0x10944
 #define GATE_IP_PERIC		0x10950
 #define GATE_IP_PERIS		0x10960
+#define GATE_IP_ACP		0x18800
 #define SRC_CDREX		0x20200
 #define PLL_DIV2_SEL		0x20a24
 #define GATE_IP_DISP1		0x10928
@@ -100,6 +103,14 @@ enum exynos5250_clks {
 	tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
 	wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
 
+	camif_top, smmu_fimc_lite0, smmu_fimc_lite1, smmu_fimc_lite2,
+	smmu_tv, smmu_fimd1, smmu_2d,
+	fimc_isp, fimc_drc, fimc_fd, fimc_scc, fimc_scp, fimc_mcuctl, fimc_odc,
+	fimc_dis, fimc_3dnr,
+	smmu_fimc_isp, smmu_fimc_drc, smmu_fimc_fd, smmu_fimc_scc,
+	smmu_fimc_scp, smmu_fimc_mcuctl, smmu_fimc_odc, smmu_fimc_dis0,
+	smmu_fimc_dis1, smmu_fimc_3dnr,
+
 	nr_clks,
 };
 
@@ -320,19 +331,26 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
 	GATE(gscl3, "gscl3", "aclk266", GATE_IP_GSCL, 3, 0, 0),
 	GATE(gscl_wa, "gscl_wa", "div_gscl_wa", GATE_IP_GSCL, 5, 0, 0),
 	GATE(gscl_wb, "gscl_wb", "div_gscl_wb", GATE_IP_GSCL, 6, 0, 0),
-	GATE(smmu_gscl0, "smmu_gscl0", "aclk266", GATE_IP_GSCL, 7, 0, 0),
-	GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
-	GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
-	GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
+	GATE(smmu_gscl0, "smmu_gscl0", "gscl0", GATE_IP_GSCL, 7, 0, 0),
+	GATE(smmu_gscl1, "smmu_gscl1", "gscl1", GATE_IP_GSCL, 8, 0, 0),
+	GATE(smmu_gscl2, "smmu_gscl2", "gscl2", GATE_IP_GSCL, 9, 0, 0),
+	GATE(smmu_gscl3, "smmu_gscl3", "gscl3", GATE_IP_GSCL, 10, 0, 0),
+	GATE(camif_top, "camif_top", "aclk266", GATE_IP_GSCL, 4, 0, 0),
+	GATE(smmu_fimc_lite0, "smmu_fimc_lite0", "camif_top",
+						GATE_IP_GSCL, 12, 0, 0),
+	GATE(smmu_fimc_lite1, "smmu_fimc_lite1", "camif_top",
+						GATE_IP_GSCL, 13, 0, 0),
+	GATE(smmu_fimc_lite2, "smmu_fimc_lite2", "camif_top",
+						GATE_IP_GSCL, 14, 0, 0),
 	GATE(mfc, "mfc", "aclk333", GATE_IP_MFC, 0, 0, 0),
-	GATE(smmu_mfcl, "smmu_mfcl", "aclk333", GATE_IP_MFC, 1, 0, 0),
-	GATE(smmu_mfcr, "smmu_mfcr", "aclk333", GATE_IP_MFC, 2, 0, 0),
+	GATE(smmu_mfcl, "smmu_mfcl", "mfc", GATE_IP_MFC, 1, 0, 0),
+	GATE(smmu_mfcr, "smmu_mfcr", "mfc", GATE_IP_MFC, 2, 0, 0),
 	GATE(rotator, "rotator", "aclk266", GATE_IP_GEN, 1, 0, 0),
 	GATE(jpeg, "jpeg", "aclk166", GATE_IP_GEN, 2, 0, 0),
 	GATE(mdma1, "mdma1", "aclk266", GATE_IP_GEN, 4, 0, 0),
-	GATE(smmu_rotator, "smmu_rotator", "aclk266", GATE_IP_GEN, 6, 0, 0),
-	GATE(smmu_jpeg, "smmu_jpeg", "aclk166", GATE_IP_GEN, 7, 0, 0),
-	GATE(smmu_mdma1, "smmu_mdma1", "aclk266", GATE_IP_GEN, 9, 0, 0),
+	GATE(smmu_rotator, "smmu_rotator", "none", GATE_IP_GEN, 6, 0, 0),
+	GATE(smmu_jpeg, "smmu_jpeg", "jpeg", GATE_IP_GEN, 7, 0, 0),
+	GATE(smmu_mdma1, "smmu_mdma1", "none", GATE_IP_GEN, 9, 0, 0),
 	GATE(pdma0, "pdma0", "aclk200", GATE_IP_FSYS, 1, 0, 0),
 	GATE(pdma1, "pdma1", "aclk200", GATE_IP_FSYS, 2, 0, 0),
 	GATE(sata, "sata", "aclk200", GATE_IP_FSYS, 6, 0, 0),
@@ -462,6 +480,27 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
 	GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
 	GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
 	GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
+	GATE(smmu_tv, "smmu_tv", "none", GATE_IP_DISP1, 2, 0, 0),
+	GATE(smmu_fimd1, "smmu_fimd1", "none", GATE_IP_DISP1, 8, 0, 0),
+
+	GATE(smmu_fimc_isp, "smmu_fimc_isp", "none", GATE_IP_ISP0, 8, 0, 0),
+	GATE(smmu_fimc_drc, "smmu_fimc_drc", "none", GATE_IP_ISP0, 9, 0, 0),
+	GATE(smmu_fimc_fd, "smmu_fimc_fd", "none", GATE_IP_ISP0, 10, 0, 0),
+	GATE(smmu_fimc_scc, "smmu_fimc_scc", "none",
+							GATE_IP_ISP0, 11, 0, 0),
+	GATE(smmu_fimc_scp, "smmu_fimc_scp", "none",
+							GATE_IP_ISP0, 12, 0, 0),
+	GATE(smmu_fimc_mcuctl, "smmu_fimc_mcuctl", "none",
+							GATE_IP_ISP0, 13, 0, 0),
+	GATE(smmu_fimc_odc, "smmu_fimc_odc", "none", GATE_IP_ISP1, 4, 0, 0),
+	GATE(smmu_fimc_dis0, "smmu_fimc_dis0", "none",
+							GATE_IP_ISP1, 5, 0, 0),
+	GATE(smmu_fimc_dis1, "smmu_fimc_dis1", "none",
+							GATE_IP_ISP1, 6, 0, 0),
+	GATE(smmu_fimc_3dnr, "smmu_fimc_3dnr", "none",
+							GATE_IP_ISP1, 7, 0, 0),
+
+	GATE(smmu_2d, "smmu_2d", "none", GATE_IP_ACP, 7, 0, 0),
 };
 
 static __initdata struct of_device_id ext_clk_match[] = {
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul  5 08:29:39 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 05 Jul 2013 21:29:39 +0900
Subject: [PATCH v7 8/9] iommu/exynos: support for device tree
Message-ID: <003001ce797b$51a8d340$f4fa79c0$@samsung.com>

This commit adds device tree support for System MMU.
This also include the following changes and enhancements:

* use managed device helper functions.
Simplyfies System MMU device driver.

* use only a single clock descriptor.
System MMU device descriptor is seperate if it is imposible to make
a single clock descriptor to make a device descriptor for a group of
System MMUs.

* removed dbgname member from sysmmu_drvdata structure.
debugging kernel message for a System MMU is distinguisheable with the
name of device descroptors.

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/Kconfig        |    5 +-
 drivers/iommu/exynos-iommu.c |  192 ++++++++++++++++++------------------------
 2 files changed, 83 insertions(+), 114 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index c332fb9..d45f3c9 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -168,16 +168,15 @@ config TEGRA_IOMMU_SMMU
 
 config EXYNOS_IOMMU
 	bool "Exynos IOMMU Support"
-	depends on ARCH_EXYNOS && EXYNOS_DEV_SYSMMU
+	depends on ARCH_EXYNOS
 	select IOMMU_API
+	default n
 	help
 	  Support for the IOMMU(System MMU) of Samsung Exynos application
 	  processor family. This enables H/W multimedia accellerators to see
 	  non-linear physical memory chunks as a linear memory in their
 	  address spaces
 
-	  If unsure, say N here.
-
 config EXYNOS_IOMMU_DEBUG
 	bool "Debugging log for Exynos IOMMU"
 	depends on EXYNOS_IOMMU
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 6793661..b151e51 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -26,6 +26,7 @@
 #include <linux/list.h>
 #include <linux/memblock.h>
 #include <linux/export.h>
+#include <linux/of.h>
 
 #include <asm/cacheflush.h>
 #include <asm/pgtable.h>
@@ -170,15 +171,14 @@ struct sysmmu_drvdata {
 	struct list_head node; /* entry of exynos_iommu_domain.clients */
 	struct device *sysmmu;	/* System MMU's device descriptor */
 	struct device *dev;	/* Owner of system MMU */
-	char *dbgname;
 	int nsfrs;
-	void __iomem **sfrbases;
-	struct clk *clk[2];
+	struct clk *clk;
 	int activations;
 	spinlock_t lock;
 	struct iommu_domain *domain;
 	sysmmu_fault_handler_t fault_handler;
 	unsigned long pgtable;
+	void __iomem *sfrbases[0];
 };
 
 static bool set_sysmmu_active(struct sysmmu_drvdata *data)
@@ -385,8 +385,8 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 	if (!ret && (itype != SYSMMU_FAULT_UNKNOWN))
 		__raw_writel(1 << itype, data->sfrbases[i] + REG_INT_CLEAR);
 	else
-		dev_dbg(data->sysmmu, "(%s) %s is not handled.\n",
-				data->dbgname, sysmmu_fault_name[itype]);
+		dev_dbg(data->sysmmu, "%s is not handled.\n",
+				sysmmu_fault_name[itype]);
 
 	if (itype != SYSMMU_FAULT_UNKNOWN)
 		sysmmu_unblock(data->sfrbases[i]);
@@ -410,10 +410,8 @@ static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
 	for (i = 0; i < data->nsfrs; i++)
 		__raw_writel(CTRL_DISABLE, data->sfrbases[i] + REG_MMU_CTRL);
 
-	if (data->clk[1])
-		clk_disable(data->clk[1]);
-	if (data->clk[0])
-		clk_disable(data->clk[0]);
+	if (data->clk)
+		clk_disable(data->clk);
 
 	disabled = true;
 	data->pgtable = 0;
@@ -422,10 +420,10 @@ finish:
 	spin_unlock_irqrestore(&data->lock, flags);
 
 	if (disabled)
-		dev_dbg(data->sysmmu, "(%s) Disabled\n", data->dbgname);
+		dev_dbg(data->sysmmu, "Disabled\n");
 	else
-		dev_dbg(data->sysmmu, "(%s) %d times left to be disabled\n",
-					data->dbgname, data->activations);
+		dev_dbg(data->sysmmu, "%d times left to be disabled\n",
+					data->activations);
 
 	return disabled;
 }
@@ -452,14 +450,12 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
 			ret = 1;
 		}
 
-		dev_dbg(data->sysmmu, "(%s) Already enabled\n", data->dbgname);
+		dev_dbg(data->sysmmu, "Already enabled\n");
 		goto finish;
 	}
 
-	if (data->clk[0])
-		clk_enable(data->clk[0]);
-	if (data->clk[1])
-		clk_enable(data->clk[1]);
+	if (data->clk)
+		clk_enable(data->clk);
 
 	data->pgtable = pgtable;
 
@@ -479,7 +475,7 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
 
 	data->domain = domain;
 
-	dev_dbg(data->sysmmu, "(%s) Enabled\n", data->dbgname);
+	dev_dbg(data->sysmmu, "Enabled\n");
 finish:
 	spin_unlock_irqrestore(&data->lock, flags);
 
@@ -495,7 +491,7 @@ int exynos_sysmmu_enable(struct device *dev, unsigned long pgtable)
 
 	ret = pm_runtime_get_sync(data->sysmmu);
 	if (ret < 0) {
-		dev_dbg(data->sysmmu, "(%s) Failed to enable\n", data->dbgname);
+		dev_dbg(data->sysmmu, "Failed to enable\n");
 		return ret;
 	}
 
@@ -503,8 +499,8 @@ int exynos_sysmmu_enable(struct device *dev, unsigned long pgtable)
 	if (WARN_ON(ret < 0)) {
 		pm_runtime_put(data->sysmmu);
 		dev_err(data->sysmmu,
-			"(%s) Already enabled with page table %#lx\n",
-			data->dbgname, data->pgtable);
+			"Already enabled with page table %#lx\n",
+			data->pgtable);
 	} else {
 		data->dev = dev;
 	}
@@ -540,9 +536,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
 			}
 		}
 	} else {
-		dev_dbg(data->sysmmu,
-			"(%s) Disabled. Skipping invalidating TLB.\n",
-			data->dbgname);
+		dev_dbg(data->sysmmu, "Disabled. Skipping invalidating TLB.\n");
 	}
 
 	spin_unlock_irqrestore(&data->lock, flags);
@@ -564,141 +558,117 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
 			}
 		}
 	} else {
-		dev_dbg(data->sysmmu,
-			"(%s) Disabled. Skipping invalidating TLB.\n",
-			data->dbgname);
+		dev_dbg(data->sysmmu, "Disabled. Skipping invalidating TLB.\n");
 	}
 
 	spin_unlock_irqrestore(&data->lock, flags);
 }
 
-static int exynos_sysmmu_probe(struct platform_device *pdev)
+static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 {
 	int i, ret;
-	struct device *dev;
+	struct device *dev = &pdev->dev;
 	struct sysmmu_drvdata *data;
 
-	dev = &pdev->dev;
-
-	data = kzalloc(sizeof(*data), GFP_KERNEL);
-	if (!data) {
-		dev_dbg(dev, "Not enough memory\n");
-		ret = -ENOMEM;
-		goto err_alloc;
+	if (pdev->num_resources == 0) {
+		dev_err(dev, "No System MMU resource defined\n");
+		return -ENODEV;
 	}
 
-	ret = dev_set_drvdata(dev, data);
-	if (ret) {
-		dev_dbg(dev, "Unabled to initialize driver data\n");
-		goto err_init;
+	data = devm_kzalloc(dev,
+			sizeof(*data) +
+			sizeof(*data->sfrbases) * (pdev->num_resources / 2),
+			GFP_KERNEL);
+	if (!data) {
+		dev_err(dev, "Not enough memory for initialization\n");
+		return -ENOMEM;
 	}
 
 	data->nsfrs = pdev->num_resources / 2;
-	data->sfrbases = kmalloc(sizeof(*data->sfrbases) * data->nsfrs,
-								GFP_KERNEL);
-	if (data->sfrbases == NULL) {
-		dev_dbg(dev, "Not enough memory\n");
-		ret = -ENOMEM;
-		goto err_init;
-	}
 
 	for (i = 0; i < data->nsfrs; i++) {
 		struct resource *res;
+
 		res = platform_get_resource(pdev, IORESOURCE_MEM, i);
 		if (!res) {
-			dev_dbg(dev, "Unable to find IOMEM region\n");
-			ret = -ENOENT;
-			goto err_res;
+			dev_err(dev, "Unable to find IOMEM region\n");
+			return -ENOENT;
 		}
 
-		data->sfrbases[i] = ioremap(res->start, resource_size(res));
+		data->sfrbases[i] = devm_request_and_ioremap(dev, res);
 		if (!data->sfrbases[i]) {
-			dev_dbg(dev, "Unable to map IOMEM @ PA:%#x\n",
-							res->start);
-			ret = -ENOENT;
-			goto err_res;
+			dev_err(dev, "Unable to map IOMEM @ %#x\n", res->start);
+			return -EBUSY;
 		}
 	}
 
 	for (i = 0; i < data->nsfrs; i++) {
-		ret = platform_get_irq(pdev, i);
-		if (ret <= 0) {
-			dev_dbg(dev, "Unable to find IRQ resource\n");
-			goto err_irq;
+		int irq;
+
+		irq = platform_get_irq(pdev, i);
+		if (irq <= 0) {
+			dev_err(dev, "Unable to find IRQ resource\n");
+			return -ENOENT;
 		}
 
-		ret = request_irq(ret, exynos_sysmmu_irq, 0,
-					dev_name(dev), data);
+		ret = devm_request_irq(dev, irq, exynos_sysmmu_irq,
+					0, dev_name(dev), data);
 		if (ret) {
-			dev_dbg(dev, "Unabled to register interrupt handler\n");
-			goto err_irq;
+			dev_err(dev, "Unable to register handler to irq %d\n",
+				irq);
+			return ret;
 		}
 	}
 
-	if (dev_get_platdata(dev)) {
-		char *deli, *beg;
-		struct sysmmu_platform_data *platdata = dev_get_platdata(dev);
-
-		beg = platdata->clockname;
-
-		for (deli = beg; (*deli != '\0') && (*deli != ','); deli++)
-			/* NOTHING */;
+	pm_runtime_enable(dev);
 
-		if (*deli == '\0')
-			deli = NULL;
-		else
-			*deli = '\0';
+	__set_fault_handler(data, &default_fault_handler);
 
-		data->clk[0] = clk_get(dev, beg);
-		if (IS_ERR(data->clk[0])) {
-			data->clk[0] = NULL;
-			dev_dbg(dev, "No clock descriptor registered\n");
+	data->sysmmu = dev;
+	data->clk = devm_clk_get(dev, "sysmmu");
+	if (IS_ERR(data->clk)) {
+		dev_info(dev, "No gate clock found!\n");
+		data->clk = NULL;
+	} else {
+		struct clk *parent;
+		ret = clk_prepare(data->clk);
+		if (ret) {
+			dev_err(dev, "Failed to prepare gate clock!\n");
+			return ret;
 		}
 
-		if (data->clk[0] && deli) {
-			*deli = ',';
-			data->clk[1] = clk_get(dev, deli + 1);
-			if (IS_ERR(data->clk[1]))
-				data->clk[1] = NULL;
+		parent = devm_clk_get(dev, "master");
+		if (!IS_ERR(parent)) {
+			ret = clk_set_parent(data->clk, parent);
+			if (ret) {
+				dev_err(dev, "Failed to set parent clock!\n");
+				return ret;
+			}
 		}
-
-		data->dbgname = platdata->dbgname;
 	}
 
-	data->sysmmu = dev;
 	spin_lock_init(&data->lock);
 	INIT_LIST_HEAD(&data->node);
 
-	__set_fault_handler(data, &default_fault_handler);
-
-	if (dev->parent)
-		pm_runtime_enable(dev);
+	platform_set_drvdata(pdev, data);
+	dev_dbg(dev, "Probed and initialized\n");
 
-	dev_dbg(dev, "(%s) Initialized\n", data->dbgname);
-	return 0;
-err_irq:
-	while (i-- > 0) {
-		int irq;
-
-		irq = platform_get_irq(pdev, i);
-		free_irq(irq, data);
-	}
-err_res:
-	while (data->nsfrs-- > 0)
-		iounmap(data->sfrbases[data->nsfrs]);
-	kfree(data->sfrbases);
-err_init:
-	kfree(data);
-err_alloc:
-	dev_err(dev, "Failed to initialize\n");
 	return ret;
 }
 
-static struct platform_driver exynos_sysmmu_driver = {
-	.probe		= exynos_sysmmu_probe,
-	.driver		= {
+#ifdef CONFIG_OF
+static struct of_device_id sysmmu_of_match[] __initconst = {
+	{ .compatible	= "samsung,exynos4210-sysmmu", },
+	{ },
+};
+#endif
+
+static struct platform_driver exynos_sysmmu_driver __refdata = {
+	.probe	= exynos_sysmmu_probe,
+	.driver	= {
 		.owner		= THIS_MODULE,
 		.name		= "exynos-sysmmu",
+		.of_match_table	= of_match_ptr(sysmmu_of_match),
 	}
 };
 
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul  5 08:29:37 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 05 Jul 2013 21:29:37 +0900
Subject: [PATCH v7 7/9] ARM: dts: Add description of System MMU of Exynos SoCs
Message-ID: <002f01ce797b$5016c190$f04444b0$@samsung.com>

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++++++
 arch/arm/boot/dts/exynos4.dtsi                     |  122 ++++++++
 arch/arm/boot/dts/exynos4210.dtsi                  |   25 ++
 arch/arm/boot/dts/exynos4x12.dtsi                  |   76 +++++
 arch/arm/boot/dts/exynos5250.dtsi                  |  291 ++++++++++++++++++++
 5 files changed, 617 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt

diff --git a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
new file mode 100644
index 0000000..92f0a33
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
@@ -0,0 +1,103 @@
+Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management Unit)
+
+Samsung's Exynos architecture contains System MMU that enables scattered
+physical memory chunks visible as a contiguous region to DMA-capable peripheral
+devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
+
+System MMU is a sort of IOMMU and support identical translation table format to
+ARMv7 translation tables with minimum set of page properties including access
+permissions, shareability and security protection. In addition, System MMU has
+another capabilities like L2 TLB or block-fetch buffers to minimize translation
+latency.
+
+A System MMU is dedicated to a single master peripheral device.  Thus, it is
+important to specify the correct System MMU in the device node of its master
+device. Whereas a System MMU is dedicated to a master device, the master device
+may have more than one System MMU.
+
+Required properties:
+- compatible: Should be "samsung,exynos4210-sysmmu"
+- reg: A tuple of base address and size of System MMU registers.
+- interrupt-parent: The phandle of the interrupt controller of System MMU
+- interrupts: A tuple of numbers that indicates the interrupt source.
+- clock-names: Should be "sysmmu" if the System MMU is needed to gate its clock.
+               Please refer to the following documents:
+	       Documentation/devicetree/bindings/clock/clock-bindings.txt
+	       Documentation/devicetree/bindings/clock/exynos4-clock.txt
+	       Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+	       Optional "master" if the clock to the System MMU is gated by
+	       another gate clock other than "sysmmu". The System MMU driver
+	       sets "master" the parent of "sysmmu".
+	       Exynos4 SoCs, there needs no "master" clocks.
+	       Exynos5 SoCs, some System MMUs must have "master" clocks.
+- clocks: Required if the System MMU is needed to gate its clock.
+	  Please refer to the documents listed above.
+- samsung,power-domain: Required if the System MMU is needed to gate its power.
+	  Please refer to the following document:
+	  Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+
+Required properties for the master peripheral devices:
+- iommu: phandles to the System MMUs of the device
+
+Examples:
+A System MMU is dedicated to a single master device.
+	gsc_0:  gsc at 0x13e00000 {
+		compatible = "samsung,exynos5-gsc";
+		reg = <0x13e00000 0x1000>;
+		interrupts = <0 85 0>;
+		samsung,power-domain = <&pd_gsc>;
+		clocks = <&clock 256>;
+		clock-names = "gscl";
+		iommu = <&sysmmu_gsc1>;
+	};
+
+	sysmmu_gsc0: sysmmu at 13E80000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13E80000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-gsc0";
+		interrupts = <2 0>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 262>, <&clock 256>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+MFC has 2 System MMUs for each port that MFC is attached. Thus it seems natural
+to define 2 System MMUs for each port of the MFC:
+
+	mfc: codec at 13400000 {
+		compatible = "samsung,mfc-v5";
+		reg = <0x13400000 0x10000>;
+		interrupts = <0 94 0>;
+		samsung,power-domain = <&pd_mfc>;
+		clocks = <&clock 170>, <&clock 273>;
+		clock-names = "sclk_mfc", "mfc";
+		status = "ok";
+		iommu = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>;
+	};
+
+	sysmmu_mfc_l: sysmmu at 13620000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13620000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-mfc-l";
+		interrupts = <5 5>;
+		clock-names = "sysmmu";
+		clocks = <&clock 274>;
+		samsung,power-domain = <&pd_mfc>;
+		status = "ok";
+	};
+
+	sysmmu_mfc_r: sysmmu at 13630000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13630000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-mfc-r";
+		interrupts = <5 6>;
+		clock-names = "sysmmu";
+		clocks = <&clock 275>;
+		samsung,power-domain = <&pd_mfc>;
+		status = "ok";
+	};
+
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 359694c..ba74ee8 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -161,6 +161,7 @@
 		interrupts = <0 94 0>;
 		samsung,power-domain = <&pd_mfc>;
 		status = "disabled";
+		iommu = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>;
 	};
 
 	serial at 13800000 {
@@ -395,5 +396,126 @@
 		clock-names = "sclk_fimd", "fimd";
 		samsung,power-domain = <&pd_lcd0>;
 		status = "disabled";
+		iommu = <&sysmmu_fimd0>;
+	};
+
+	sysmmu_mfc_l: sysmmu at 13620000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13620000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-mfc-l";
+		interrupts = <5 5>;
+		clock-names = "sysmmu";
+		clocks = <&clock 274>;
+		samsung,power-domain = <&pd_mfc>;
+		status = "ok";
+	};
+
+	sysmmu_mfc_r: sysmmu at 13630000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13630000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-mfc-r";
+		interrupts = <5 6>;
+		clock-names = "sysmmu";
+		clocks = <&clock 275>;
+		samsung,power-domain = <&pd_mfc>;
+		status = "ok";
+	};
+
+	sysmmu_tv: sysmmu at 13E20000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13E20000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-tv";
+		interrupts = <5 4>;
+		clock-names = "sysmmu";
+		clocks = <&clock 272>;
+		samsung,power-domain = <&pd_tv>;
+		status = "ok";
+	};
+
+	sysmmu_fimc0: sysmmu at 11A20000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11A20000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc0";
+		interrupts = <4 2>;
+		clock-names = "sysmmu";
+		clocks = <&clock 263>;
+		samsung,power-domain = <&pd_cam>;
+		status = "ok";
+	};
+
+	sysmmu_fimc1: sysmmu at 11A30000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11A30000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc1";
+		interrupts = <4 3>;
+		clock-names = "sysmmu";
+		clocks = <&clock 264>;
+		samsung,power-domain = <&pd_cam>;
+		status = "ok";
+	};
+
+	sysmmu_fimc2: sysmmu at 11A40000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11A40000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc2";
+		interrupts = <4 4>;
+		clock-names = "sysmmu";
+		clocks = <&clock 265>;
+		samsung,power-domain = <&pd_cam>;
+		status = "ok";
+	};
+
+	sysmmu_fimc3: sysmmu at 11A50000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11A50000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc3";
+		interrupts = <4 5>;
+		clock-names = "sysmmu";
+		clocks = <&clock 266>;
+		samsung,power-domain = <&pd_cam>;
+		status = "ok";
+	};
+
+	sysmmu_jpeg: sysmmu at 11A60000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11A60000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-jpeg";
+		interrupts = <4 6>;
+		clock-names = "sysmmu";
+		clocks = <&clock 267>;
+		samsung,power-domain = <&pd_cam>;
+		status = "ok";
+	};
+
+	sysmmu_rotator: sysmmu at 12A30000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x12A30000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-rotator";
+		interrupts = <5 0>;
+		clock-names = "sysmmu";
+		clocks = <&clock 281>;
+		samsung,power-domain = <&pd_lcd0>;
+		status = "ok";
+	};
+
+	sysmmu_fimd0: sysmmu at 11E20000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11E20000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimd0";
+		interrupts = <5 2>;
+		clock-names = "sysmmu";
+		clocks = <&clock 287>;
+		samsung,power-domain = <&pd_lcd0>;
+		status = "ok";
 	};
 };
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 54710de..09b13da 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -119,5 +119,30 @@
 		reg = <0x12800000 0x1000>;
 		interrupts = <0 89 0>;
 		status = "disabled";
+		iommu = <&sysmmu_g2d>;
+	};
+
+	sysmmu_g2d: sysmmu at 12A20000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x12A20000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-g2d";
+		interrupts = <4 7>;
+		clock-names = "sysmmu";
+		clocks = <&clock 280>;
+		samsung,power-domain = <&pd_lcd0>;
+		status = "ok";
+	};
+
+	sysmmu_fimd1: sysmmu at 12220000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimd1";
+		reg = <0x12220000 0x1000>;
+		interrupts = <5 3>;
+		clock-names = "sysmmu";
+		clocks = <&clock 291>;
+		samsung,power-domain = <&pd_lcd1>;
+		status = "ok";
 	};
 };
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index e3380a7..681db32 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -79,4 +79,80 @@
 		interrupts = <0 89 0>;
 		status = "disabled";
 	};
+
+	sysmmu_g2d: sysmmu at 10A40000{
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x10A40000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-g2d";
+		interrupts = <4 7>;
+		clock-names = "sysmmu";
+		status = "ok";
+	};
+
+	sysmmu_fimc_isp: sysmmu at 12260000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x12260000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_isp";
+		interrupts = <16 2>;
+		clock-names = "sysmmu";
+		clocks = <&clock 362>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_drc: sysmmu at 12270000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x12270000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_drc";
+		interrupts = <16 3>;
+		clock-names = "sysmmu";
+		clocks = <&clock 363>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_fd: sysmmu at 122A0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x122A0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_fd";
+		interrupts = <16 4>;
+		clock-names = "sysmmu";
+		clocks = <&clock 364>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_mcuctl: sysmmu at 122B0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x122B0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_mcuctl";
+		interrupts = <16 5>;
+		clock-names = "sysmmu";
+		clocks = <&clock 376>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_lite0: sysmmu at 123B0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x123B0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_lite0";
+		interrupts = <16 0>;
+		clock-names = "sysmmu";
+		clocks = <&clock 366>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_lite1: sysmmu at 123C0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x123C0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_lite1";
+		interrupts = <16 1>;
+		clock-names = "sysmmu";
+		clocks = <&clock 365>;
+		status = "ok";
+	};
 };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index fc9fb3d..130d23d 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -66,6 +66,16 @@
 		reg = <0x10044040 0x20>;
 	};
 
+	pd_isp: mfc-power-domain at 0x10044020 {
+		compatible = "samsung,exynos4210-pd";
+		reg = <0x10044020 0x20>;
+	};
+
+	pd_disp1: mfc-power-domain at 0x100440A0 {
+		compatible = "samsung,exynos4210-pd";
+		reg = <0x100440A0 0x20>;
+	};
+
 	clock: clock-controller at 0x10010000 {
 		compatible = "samsung,exynos5250-clock";
 		reg = <0x10010000 0x30000>;
@@ -180,6 +190,7 @@
 		reg = <0x11000000 0x10000>;
 		interrupts = <0 96 0>;
 		samsung,power-domain = <&pd_mfc>;
+		iommu = <&sysmmu_mfc_l &sysmmu_mfc_l>;
 	};
 
 	rtc {
@@ -571,6 +582,7 @@
 		samsung,power-domain = <&pd_gsc>;
 		clocks = <&clock 256>;
 		clock-names = "gscl";
+		iommu = <&sysmmu_gsc1>;
 	};
 
 	gsc_1:  gsc at 0x13e10000 {
@@ -580,6 +592,7 @@
 		samsung,power-domain = <&pd_gsc>;
 		clocks = <&clock 257>;
 		clock-names = "gscl";
+		iommu = <&sysmmu_gsc1>;
 	};
 
 	gsc_2:  gsc at 0x13e20000 {
@@ -589,6 +602,7 @@
 		samsung,power-domain = <&pd_gsc>;
 		clocks = <&clock 258>;
 		clock-names = "gscl";
+		iommu = <&sysmmu_gsc2>;
 	};
 
 	gsc_3:  gsc at 0x13e30000 {
@@ -598,6 +612,7 @@
 		samsung,power-domain = <&pd_gsc>;
 		clocks = <&clock 259>;
 		clock-names = "gscl";
+		iommu = <&sysmmu_gsc3>;
 	};
 
 	hdmi {
@@ -614,6 +629,7 @@
 		compatible = "samsung,exynos5-mixer";
 		reg = <0x14450000 0x10000>;
 		interrupts = <0 94 0>;
+		iommu = <&sysmmu_tv>;
 	};
 
 	dp-controller {
@@ -638,5 +654,280 @@
 		interrupts = <18 4>, <18 5>, <18 6>;
 		clocks = <&clock 133>, <&clock 339>;
 		clock-names = "sclk_fimd", "fimd";
+		iommu = <&sysmmu_fimd1>;
+	};
+
+	sysmmu_mfc_l: sysmmu at 11210000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11210000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-mfc_l";
+		interrupts = <8 5>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 267>, <&clock 266>;
+		samsung,power-domain = <&pd_mfc>;
+		status = "ok";
+	};
+
+	sysmmu_mfc_r: sysmmu at 11200000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11200000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-mfc_r";
+		interrupts = <6 2>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 268>, <&clock 266>;
+		samsung,power-domain = <&pd_mfc>;
+		status = "ok";
+	};
+
+	sysmmu_tv: sysmmu at 14650000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x14650000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-tv";
+		interrupts = <7 4>;
+		clock-names = "sysmmu";
+		clocks = <&clock 349>;
+		samsung,power-domain = <&pd_disp1>;
+		status = "ok";
+	};
+
+	sysmmu_gsc0: sysmmu at 13E80000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13E80000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-gsc0";
+		interrupts = <2 0>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 262>, <&clock 256>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+	sysmmu_gsc1: sysmmu at 13E90000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13E90000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-gsc1";
+		interrupts = <2 2>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 263>, <&clock 257>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+	sysmmu_gsc2: sysmmu at 13EA0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13EA0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-gsc2";
+		interrupts = <2 4>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 264>, <&clock 258>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+	sysmmu_gsc3: sysmmu at 13EB0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13EB0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-gsc3";
+		interrupts = <2 6>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 265>, <&clock 259>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+	sysmmu_fimd1: sysmmu at 14640000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x14640000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimd1";
+		interrupts = <3 2>;
+		clock-names = "sysmmu";
+		clocks = <&clock 350>;
+		samsung,power-domain = <&pd_disp1>;
+		status = "ok";
+	};
+
+	sysmmu_rotator: sysmmu at 11D40000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11D40000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-rotator";
+		interrupts = <4 0>;
+		clock-names = "sysmmu";
+		clocks = <&clock 272>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_isp: sysmmu at 13260000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13260000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_isp";
+		interrupts = <10 6>;
+		clock-names = "sysmmu";
+		clocks = <&clock 361>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_drc: sysmmu at 13270000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13270000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_drc";
+		interrupts = <11 6>;
+		clock-names = "sysmmu";
+		clocks = <&clock 362>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_fd: sysmmu at 132A0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x132A0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_fd";
+		interrupts = <5 0>;
+		clock-names = "sysmmu";
+		clocks = <&clock 363>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_scc: sysmmu at 13280000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13280000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_scalerc";
+		interrupts = <5 2>;
+		clock-names = "sysmmu";
+		clocks = <&clock 364>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_scp: sysmmu at 13290000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13290000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_scalerp";
+		interrupts = <3 6>;
+		clock-names = "sysmmu";
+		clocks = <&clock 365>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_mcuctl: sysmmu at 132B0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x132B0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_mcuctl";
+		interrupts = <5 4>;
+		clock-names = "sysmmu";
+		clocks = <&clock 366>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_odc: sysmmu at 132C0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x132C0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_odc";
+		interrupts = <11 0>;
+		clock-names = "sysmmu";
+		clocks = <&clock 367>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_dis0: sysmmu at 132D0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x132D0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_dis0";
+		interrupts = <10 4>;
+		clock-names = "sysmmu";
+		clocks = <&clock 368>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_dis1: sysmmu at 132E0000{
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x132E0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_dis1";
+		interrupts = <9 4>;
+		clock-names = "sysmmu";
+		clocks = <&clock 369>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_3dnr: sysmmu at 132F0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x132F0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_3dnr";
+		interrupts = <5 6>;
+		clock-names = "sysmmu";
+		clocks = <&clock 370>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_lite0: sysmmu at 13C40000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13C40000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_lite0";
+		interrupts = <3 4>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 346>, <&clock 345>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_lite1: sysmmu at 13C50000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13C50000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_lite1";
+		interrupts = <24 1>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 347>, <&clock 345>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_jpeg: sysmmu at 11F20000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11F20000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-jpeg";
+		interrupts = <4 2>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 273>, <&clock 270>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_2d: sysmmu at 10A60000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x10A60000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-2d";
+		interrupts = <24 5>;
+		clock-names = "sysmmu";
+		clocks = <&clock 361>;
+		status = "ok";
 	};
 };
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul  5 08:29:43 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 05 Jul 2013 21:29:43 +0900
Subject: [PATCH v7 9/9] iommu/exynos: add bus notifier for registering System
 MMU
Message-ID: <003101ce797b$5418e8e0$fc4abaa0$@samsung.com>

When a device driver is registered, all constructs to handle System MMU
is prepared by bus notifier call.

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |  778 ++++++++++++++++++++++++++++++-----------
 1 files changed, 569 insertions(+), 209 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index b151e51..51d43bb 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -27,6 +27,9 @@
 #include <linux/memblock.h>
 #include <linux/export.h>
 #include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/pm_domain.h>
+#include <linux/notifier.h>
 
 #include <asm/cacheflush.h>
 #include <asm/pgtable.h>
@@ -80,6 +83,14 @@
 #define CTRL_BLOCK	0x7
 #define CTRL_DISABLE	0x0
 
+#define CFG_LRU		0x1
+#define CFG_QOS(n)	((n & 0xF) << 7)
+#define CFG_MASK	0x0150FFFF /* Selecting bit 0-15, 20, 22 and 24 */
+#define CFG_ACGEN	(1 << 24) /* System MMU 3.3 only */
+#define CFG_SYSSEL	(1 << 22) /* System MMU 3.2 only */
+#define CFG_FLPDCACHE	(1 << 20) /* System MMU 3.2+ only */
+#define CFG_SHAREABLE	(1 << 12) /* System MMU 3.x only */
+
 #define REG_MMU_CTRL		0x000
 #define REG_MMU_CFG		0x004
 #define REG_MMU_STATUS		0x008
@@ -96,6 +107,9 @@
 
 #define REG_MMU_VERSION		0x034
 
+#define MMU_MAJ_VER(reg)	(reg >> 28)
+#define MMU_MIN_VER(reg)	((reg >> 21) & 0x7F)
+
 #define REG_PB0_SADDR		0x04C
 #define REG_PB0_EADDR		0x050
 #define REG_PB1_SADDR		0x054
@@ -126,16 +140,6 @@ enum exynos_sysmmu_inttype {
 	SYSMMU_FAULTS_NUM
 };
 
-/*
- * @itype: type of fault.
- * @pgtable_base: the physical address of page table base. This is 0 if @itype
- *                is SYSMMU_BUSERROR.
- * @fault_addr: the device (virtual) address that the System MMU tried to
- *             translated. This is 0 if @itype is SYSMMU_BUSERROR.
- */
-typedef int (*sysmmu_fault_handler_t)(enum exynos_sysmmu_inttype itype,
-			unsigned long pgtable_base, unsigned long fault_addr);
-
 static unsigned short fault_reg_offset[SYSMMU_FAULTS_NUM] = {
 	REG_PAGE_FAULT_ADDR,
 	REG_AR_FAULT_ADDR,
@@ -159,6 +163,14 @@ static char *sysmmu_fault_name[SYSMMU_FAULTS_NUM] = {
 	"UNKNOWN FAULT"
 };
 
+struct exynos_iommu_client {
+	struct list_head node;	/* entry of exynos_iommu_domain.clients */
+	struct device *dev;
+	spinlock_t lock;
+	int num_sysmmu;
+	struct device *sysmmu[0];
+};
+
 struct exynos_iommu_domain {
 	struct list_head clients; /* list of sysmmu_drvdata.node */
 	unsigned long *pgtable; /* lv1 page table, 16KB */
@@ -170,13 +182,13 @@ struct exynos_iommu_domain {
 struct sysmmu_drvdata {
 	struct list_head node; /* entry of exynos_iommu_domain.clients */
 	struct device *sysmmu;	/* System MMU's device descriptor */
-	struct device *dev;	/* Owner of system MMU */
+	struct device *master;	/* Owner of system MMU */
 	int nsfrs;
 	struct clk *clk;
 	int activations;
 	spinlock_t lock;
 	struct iommu_domain *domain;
-	sysmmu_fault_handler_t fault_handler;
+	bool runtime_active;
 	unsigned long pgtable;
 	void __iomem *sfrbases[0];
 };
@@ -200,6 +212,20 @@ static bool is_sysmmu_active(struct sysmmu_drvdata *data)
 	return data->activations > 0;
 }
 
+static unsigned int __sysmmu_version(struct sysmmu_drvdata *data,
+					int idx, unsigned int *minor)
+{
+	unsigned int major;
+
+	major = readl(data->sfrbases[idx] + REG_MMU_VERSION);
+
+	if (minor)
+		*minor = MMU_MIN_VER(major);
+	major = MMU_MAJ_VER(major);
+
+	return major;
+}
+
 static void sysmmu_unblock(void __iomem *sfrbase)
 {
 	__raw_writel(CTRL_ENABLE, sfrbase + REG_MMU_CTRL);
@@ -235,7 +261,6 @@ static void __sysmmu_tlb_invalidate_entry(void __iomem *sfrbase,
 static void __sysmmu_set_ptbase(void __iomem *sfrbase,
 				       unsigned long pgd)
 {
-	__raw_writel(0x1, sfrbase + REG_MMU_CFG); /* 16KB LV1, LRU */
 	__raw_writel(pgd, sfrbase + REG_PT_BASE_ADDR);
 
 	__sysmmu_tlb_invalidate(sfrbase);
@@ -292,34 +317,17 @@ finish:
 	spin_unlock_irqrestore(&data->lock, flags);
 }
 
-static void __set_fault_handler(struct sysmmu_drvdata *data,
-					sysmmu_fault_handler_t handler)
-{
-	unsigned long flags;
-
-	spin_lock_irqsave(&data->lock, flags);
-	data->fault_handler = handler;
-	spin_unlock_irqrestore(&data->lock, flags);
-}
-
-void exynos_sysmmu_set_fault_handler(struct device *dev,
-					sysmmu_fault_handler_t handler)
-{
-	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
-
-	__set_fault_handler(data, handler);
-}
-
-static int default_fault_handler(enum exynos_sysmmu_inttype itype,
-		     unsigned long pgtable_base, unsigned long fault_addr)
+static int show_fault_information(const char *name,
+		enum exynos_sysmmu_inttype itype,
+		unsigned long pgtable_base, unsigned long fault_addr)
 {
 	unsigned long *ent;
 
 	if ((itype >= SYSMMU_FAULTS_NUM) || (itype < SYSMMU_PAGEFAULT))
 		itype = SYSMMU_FAULT_UNKNOWN;
 
-	pr_err("%s occurred at 0x%lx(Page table base: 0x%lx)\n",
-			sysmmu_fault_name[itype], fault_addr, pgtable_base);
+	pr_err("%s occurred at 0x%lx by %s(Page table base: 0x%lx)\n",
+		sysmmu_fault_name[itype], fault_addr, name, pgtable_base);
 
 	ent = section_entry(__va(pgtable_base), fault_addr);
 	pr_err("\tLv1 entry: 0x%lx\n", *ent);
@@ -340,25 +348,34 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 {
 	/* SYSMMU is in blocked when interrupt occurred. */
 	struct sysmmu_drvdata *data = dev_id;
-	struct resource *irqres;
-	struct platform_device *pdev;
+	struct exynos_iommu_client *client = NULL;
+	struct resource *memres;
 	enum exynos_sysmmu_inttype itype;
 	unsigned long addr = -1;
-
 	int i, ret = -ENOSYS;
 
-	spin_lock(&data->lock);
+	if (data->master)
+		client = data->master->archdata.iommu;
 
 	WARN_ON(!is_sysmmu_active(data));
 
-	pdev = to_platform_device(data->sysmmu);
-	for (i = 0; i < (pdev->num_resources / 2); i++) {
-		irqres = platform_get_resource(pdev, IORESOURCE_IRQ, i);
-		if (irqres && ((int)irqres->start == irq))
+	for (i = 0; i < data->nsfrs; i++) {
+		struct resource *irqres;
+		irqres = platform_get_resource(to_platform_device(data->sysmmu),
+						IORESOURCE_IRQ, i);
+		if (irqres && ((int)irqres->start == irq)) {
+			memres = platform_get_resource(
+					to_platform_device(data->sysmmu),
+					IORESOURCE_MEM, i);
 			break;
+		}
 	}
 
-	if (i == pdev->num_resources) {
+	if (client)
+		spin_lock(&client->lock);
+	spin_lock(&data->lock);
+
+	if (i == data->nsfrs) {
 		itype = SYSMMU_FAULT_UNKNOWN;
 	} else {
 		itype = (enum exynos_sysmmu_inttype)
@@ -371,197 +388,263 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 	}
 
 	if (data->domain)
-		ret = report_iommu_fault(data->domain, data->dev,
+		ret = report_iommu_fault(data->domain, data->master,
 				addr, itype);
 
-	if ((ret == -ENOSYS) && data->fault_handler) {
-		unsigned long base = data->pgtable;
-		if (itype != SYSMMU_FAULT_UNKNOWN)
-			base = __raw_readl(
-					data->sfrbases[i] + REG_PT_BASE_ADDR);
-		ret = data->fault_handler(itype, base, addr);
-	}
-
 	if (!ret && (itype != SYSMMU_FAULT_UNKNOWN))
 		__raw_writel(1 << itype, data->sfrbases[i] + REG_INT_CLEAR);
-	else
-		dev_dbg(data->sysmmu, "%s is not handled.\n",
-				sysmmu_fault_name[itype]);
+	else {
+		unsigned long ba = data->pgtable;
+		if (itype != SYSMMU_FAULT_UNKNOWN)
+			ba = __raw_readl(data->sfrbases[i] + REG_PT_BASE_ADDR);
+		show_fault_information(dev_name(data->sysmmu),
+					itype, ba, addr);
+	}
 
 	if (itype != SYSMMU_FAULT_UNKNOWN)
 		sysmmu_unblock(data->sfrbases[i]);
 
 	spin_unlock(&data->lock);
+	if (client)
+		spin_unlock(&client->lock);
 
 	return IRQ_HANDLED;
 }
 
-static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
+static void __sysmmu_disable_nocount(struct sysmmu_drvdata *data)
 {
+		int i;
+
+		for (i = 0; i < data->nsfrs; i++) {
+			__raw_writel(CTRL_DISABLE,
+				     data->sfrbases[i] + REG_MMU_CTRL);
+			__raw_writel(0, data->sfrbases[i] + REG_MMU_CFG);
+		}
+
+		clk_disable(data->clk);
+}
+
+static bool __sysmmu_disable(struct sysmmu_drvdata *data)
+{
+	bool disabled;
 	unsigned long flags;
-	bool disabled = false;
-	int i;
 
 	spin_lock_irqsave(&data->lock, flags);
 
-	if (!set_sysmmu_inactive(data))
-		goto finish;
+	disabled = set_sysmmu_inactive(data);
 
-	for (i = 0; i < data->nsfrs; i++)
-		__raw_writel(CTRL_DISABLE, data->sfrbases[i] + REG_MMU_CTRL);
+	if (disabled) {
+		data->pgtable = 0;
+		data->domain = NULL;
 
-	if (data->clk)
-		clk_disable(data->clk);
+		if (data->runtime_active)
+			__sysmmu_disable_nocount(data);
 
-	disabled = true;
-	data->pgtable = 0;
-	data->domain = NULL;
-finish:
-	spin_unlock_irqrestore(&data->lock, flags);
-
-	if (disabled)
 		dev_dbg(data->sysmmu, "Disabled\n");
-	else
-		dev_dbg(data->sysmmu, "%d times left to be disabled\n",
+	} else  {
+		dev_dbg(data->sysmmu, "%d times left to disable\n",
 					data->activations);
+	}
+
+	spin_unlock_irqrestore(&data->lock, flags);
 
 	return disabled;
 }
 
-/* __exynos_sysmmu_enable: Enables System MMU
- *
- * returns -error if an error occurred and System MMU is not enabled,
- * 0 if the System MMU has been just enabled and 1 if System MMU was already
- * enabled before.
- */
-static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
+
+static void __sysmmu_init_config(struct sysmmu_drvdata *data, int idx)
+{
+	unsigned long cfg = CFG_LRU;
+	int maj, min = 0;
+
+	maj = __sysmmu_version(data, idx, &min);
+	if (maj == 3) {
+		cfg |= CFG_SHAREABLE;
+		if (min > 1) {
+			cfg |= CFG_FLPDCACHE;
+			cfg |= (min == 2) ? CFG_SYSSEL : CFG_ACGEN;
+		}
+	}
+
+	cfg |= __raw_readl(data->sfrbases[idx] + REG_MMU_CFG) & ~CFG_MASK;
+	__raw_writel(cfg, data->sfrbases[idx] + REG_MMU_CFG);
+}
+
+static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
+{
+	int i;
+
+	clk_enable(data->clk);
+
+	for (i = 0; i < data->nsfrs; i++) {
+		BUG_ON(__raw_readl(data->sfrbases[i] + REG_MMU_CTRL)
+								& CTRL_ENABLE);
+
+		__sysmmu_init_config(data, i);
+
+		__sysmmu_set_ptbase(data->sfrbases[i], data->pgtable);
+
+		__raw_writel(CTRL_ENABLE, data->sfrbases[i] + REG_MMU_CTRL);
+	}
+}
+
+static int __sysmmu_enable(struct sysmmu_drvdata *data,
 			unsigned long pgtable, struct iommu_domain *domain)
 {
-	int i, ret = 0;
+	int ret = 0;
 	unsigned long flags;
 
 	spin_lock_irqsave(&data->lock, flags);
+	if (set_sysmmu_active(data)) {
+		data->pgtable = pgtable;
+		data->domain = domain;
 
-	if (!set_sysmmu_active(data)) {
-		if (WARN_ON(pgtable != data->pgtable)) {
-			ret = -EBUSY;
-			set_sysmmu_inactive(data);
-		} else {
-			ret = 1;
-		}
+		if (data->runtime_active)
+			__sysmmu_enable_nocount(data);
 
-		dev_dbg(data->sysmmu, "Already enabled\n");
-		goto finish;
+		dev_dbg(data->sysmmu, "Enabled\n");
+	} else {
+		ret = (pgtable == data->pgtable) ? 1 : -EBUSY;
+
+		dev_dbg(data->sysmmu, "already enabled\n");
 	}
 
-	if (data->clk)
-		clk_enable(data->clk);
+	if (WARN_ON(ret < 0))
+		set_sysmmu_inactive(data); /* decrement count */
 
-	data->pgtable = pgtable;
+	spin_unlock_irqrestore(&data->lock, flags);
 
-	for (i = 0; i < data->nsfrs; i++) {
-		__sysmmu_set_ptbase(data->sfrbases[i], pgtable);
+	return ret;
+}
 
-		if ((readl(data->sfrbases[i] + REG_MMU_VERSION) >> 28) == 3) {
-			/* System MMU version is 3.x */
-			__raw_writel((1 << 12) | (2 << 28),
-					data->sfrbases[i] + REG_MMU_CFG);
-			__sysmmu_set_prefbuf(data->sfrbases[i], 0, -1, 0);
-			__sysmmu_set_prefbuf(data->sfrbases[i], 0, -1, 1);
-		}
+/* __exynos_sysmmu_enable: Enables System MMU
+ *
+ * returns -error if an error occurred and System MMU is not enabled,
+ * 0 if the System MMU has been just enabled and 1 if System MMU was already
+ * enabled before.
+ */
+static int __exynos_sysmmu_enable(struct device *dev, unsigned long pgtable,
+				  struct iommu_domain *domain)
+{
+	int ret = 0;
+	unsigned long flags;
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int i;
 
-		__raw_writel(CTRL_ENABLE, data->sfrbases[i] + REG_MMU_CTRL);
-	}
+	if (WARN_ON(!client))
+		return -ENODEV;
 
-	data->domain = domain;
+	spin_lock_irqsave(&client->lock, flags);
 
-	dev_dbg(data->sysmmu, "Enabled\n");
-finish:
-	spin_unlock_irqrestore(&data->lock, flags);
+	for (i = 0; i < client->num_sysmmu; i++) {
+		struct sysmmu_drvdata *data =
+				dev_get_drvdata(client->sysmmu[i]);
+		ret = __sysmmu_enable(data, pgtable, domain);
+		if (ret < 0) {
+			int j;
+			for (j = 0; j < i; j++)
+				__sysmmu_disable(data);
+			break;
+		} else {
+			data->master = dev;
+		}
+	}
+
+	spin_unlock_irqrestore(&client->lock, flags);
 
 	return ret;
 }
 
 int exynos_sysmmu_enable(struct device *dev, unsigned long pgtable)
 {
-	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
 	int ret;
 
 	BUG_ON(!memblock_is_memory(pgtable));
 
-	ret = pm_runtime_get_sync(data->sysmmu);
-	if (ret < 0) {
-		dev_dbg(data->sysmmu, "Failed to enable\n");
-		return ret;
-	}
-
-	ret = __exynos_sysmmu_enable(data, pgtable, NULL);
-	if (WARN_ON(ret < 0)) {
-		pm_runtime_put(data->sysmmu);
-		dev_err(data->sysmmu,
-			"Already enabled with page table %#lx\n",
-			data->pgtable);
-	} else {
-		data->dev = dev;
-	}
+	ret = __exynos_sysmmu_enable(dev, pgtable, NULL);
 
 	return ret;
 }
 
 static bool exynos_sysmmu_disable(struct device *dev)
 {
-	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
-	bool disabled;
+	unsigned long flags;
+	bool disabled = true;
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int i;
+
+	if (WARN_ON(!client))
+		return true;
+
+	spin_lock_irqsave(&client->lock, flags);
+
+	/* Every call to __sysmmu_disable() must return same result */
+	for (i = 0; i < client->num_sysmmu; i++) {
+		struct sysmmu_drvdata *data =
+				dev_get_drvdata(client->sysmmu[i]);
+		disabled = __sysmmu_disable(data);
+		if (disabled)
+			data->master = NULL;
+	}
 
-	disabled = __exynos_sysmmu_disable(data);
-	pm_runtime_put(data->sysmmu);
+	spin_unlock_irqrestore(&client->lock, flags);
 
 	return disabled;
 }
 
 static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
 {
-	unsigned long flags;
-	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int i;
 
-	spin_lock_irqsave(&data->lock, flags);
+	for (i = 0; i < client->num_sysmmu; i++) {
+		unsigned long flags;
+		struct sysmmu_drvdata *data;
 
-	if (is_sysmmu_active(data)) {
-		int i;
-		for (i = 0; i < data->nsfrs; i++) {
-			if (sysmmu_block(data->sfrbases[i])) {
+		data = dev_get_drvdata(client->sysmmu[i]);
+
+		spin_lock_irqsave(&data->lock, flags);
+		if (is_sysmmu_active(data) && data->runtime_active) {
+			int i;
+			for (i = 0; i < data->nsfrs; i++)
 				__sysmmu_tlb_invalidate_entry(
 						data->sfrbases[i], iova);
-				sysmmu_unblock(data->sfrbases[i]);
-			}
+		} else {
+			dev_dbg(dev,
+				"disabled. Skipping TLB invalidation @ %#lx\n",
+				iova);
 		}
-	} else {
-		dev_dbg(data->sysmmu, "Disabled. Skipping invalidating TLB.\n");
+		spin_unlock_irqrestore(&data->lock, flags);
 	}
-
-	spin_unlock_irqrestore(&data->lock, flags);
 }
 
 void exynos_sysmmu_tlb_invalidate(struct device *dev)
 {
-	unsigned long flags;
-	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
-
-	spin_lock_irqsave(&data->lock, flags);
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int i;
 
-	if (is_sysmmu_active(data)) {
-		int i;
-		for (i = 0; i < data->nsfrs; i++) {
-			if (sysmmu_block(data->sfrbases[i])) {
-				__sysmmu_tlb_invalidate(data->sfrbases[i]);
-				sysmmu_unblock(data->sfrbases[i]);
+	for (i = 0; i < client->num_sysmmu; i++) {
+		unsigned long flags;
+		struct sysmmu_drvdata *data;
+
+		data = dev_get_drvdata(client->sysmmu[i]);
+
+		spin_lock_irqsave(&data->lock, flags);
+		if (is_sysmmu_active(data) &&
+				data->runtime_active) {
+			int i;
+			for (i = 0; i < data->nsfrs; i++) {
+				if (sysmmu_block(data->sfrbases[i])) {
+					__sysmmu_tlb_invalidate(
+							data->sfrbases[i]);
+					sysmmu_unblock(data->sfrbases[i]);
+				}
 			}
+		} else {
+			dev_dbg(dev, "disabled. Skipping TLB invalidation\n");
 		}
-	} else {
-		dev_dbg(data->sysmmu, "Disabled. Skipping invalidating TLB.\n");
+		spin_unlock_irqrestore(&data->lock, flags);
 	}
-
-	spin_unlock_irqrestore(&data->lock, flags);
 }
 
 static int __init exynos_sysmmu_probe(struct platform_device *pdev)
@@ -622,8 +705,6 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 
 	pm_runtime_enable(dev);
 
-	__set_fault_handler(data, &default_fault_handler);
-
 	data->sysmmu = dev;
 	data->clk = devm_clk_get(dev, "sysmmu");
 	if (IS_ERR(data->clk)) {
@@ -647,6 +728,8 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 		}
 	}
 
+	data->runtime_active = !pm_runtime_enabled(dev);
+
 	spin_lock_init(&data->lock);
 	INIT_LIST_HEAD(&data->node);
 
@@ -656,6 +739,34 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 	return ret;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int sysmmu_suspend(struct device *dev)
+{
+	struct sysmmu_drvdata *data = dev_get_drvdata(dev);
+	unsigned long flags;
+	spin_lock_irqsave(&data->lock, flags);
+	if (is_sysmmu_active(data) &&
+		(!pm_runtime_enabled(dev) || data->runtime_active))
+		__sysmmu_disable_nocount(data);
+	spin_unlock_irqrestore(&data->lock, flags);
+	return 0;
+}
+
+static int sysmmu_resume(struct device *dev)
+{
+	struct sysmmu_drvdata *data = dev_get_drvdata(dev);
+	unsigned long flags;
+	spin_lock_irqsave(&data->lock, flags);
+	if (is_sysmmu_active(data) &&
+		(!pm_runtime_enabled(dev) || data->runtime_active))
+		__sysmmu_enable_nocount(data);
+	spin_unlock_irqrestore(&data->lock, flags);
+	return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(sysmmu_pm_ops, sysmmu_suspend, sysmmu_resume);
+
 #ifdef CONFIG_OF
 static struct of_device_id sysmmu_of_match[] __initconst = {
 	{ .compatible	= "samsung,exynos4210-sysmmu", },
@@ -668,6 +779,7 @@ static struct platform_driver exynos_sysmmu_driver __refdata = {
 	.driver	= {
 		.owner		= THIS_MODULE,
 		.name		= "exynos-sysmmu",
+		.pm		= &sysmmu_pm_ops,
 		.of_match_table	= of_match_ptr(sysmmu_of_match),
 	}
 };
@@ -720,7 +832,7 @@ err_pgtable:
 static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
 {
 	struct exynos_iommu_domain *priv = domain->priv;
-	struct sysmmu_drvdata *data;
+	struct exynos_iommu_client *client;
 	unsigned long flags;
 	int i;
 
@@ -728,11 +840,14 @@ static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
 
 	spin_lock_irqsave(&priv->lock, flags);
 
-	list_for_each_entry(data, &priv->clients, node) {
-		while (!exynos_sysmmu_disable(data->dev))
+	list_for_each_entry(client, &priv->clients, node) {
+		while (!exynos_sysmmu_disable(client->dev))
 			; /* until System MMU is actually disabled */
 	}
 
+	while (!list_empty(&priv->clients))
+		list_del_init(priv->clients.next);
+
 	spin_unlock_irqrestore(&priv->lock, flags);
 
 	for (i = 0; i < NUM_LV1ENTRIES; i++)
@@ -749,41 +864,26 @@ static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
 static int exynos_iommu_attach_device(struct iommu_domain *domain,
 				   struct device *dev)
 {
-	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
+	struct exynos_iommu_client *client = dev->archdata.iommu;
 	struct exynos_iommu_domain *priv = domain->priv;
 	unsigned long flags;
 	int ret;
 
-	ret = pm_runtime_get_sync(data->sysmmu);
-	if (ret < 0)
-		return ret;
-
-	ret = 0;
-
 	spin_lock_irqsave(&priv->lock, flags);
 
-	ret = __exynos_sysmmu_enable(data, __pa(priv->pgtable), domain);
-
-	if (ret == 0) {
-		/* 'data->node' must not be appeared in priv->clients */
-		BUG_ON(!list_empty(&data->node));
-		data->dev = dev;
-		list_add_tail(&data->node, &priv->clients);
-	}
+	ret = __exynos_sysmmu_enable(dev, __pa(priv->pgtable), domain);
+	if (ret == 0)
+		list_add_tail(&client->node, &priv->clients);
 
 	spin_unlock_irqrestore(&priv->lock, flags);
 
-	if (ret < 0) {
+	if (ret < 0)
 		dev_err(dev, "%s: Failed to attach IOMMU with pgtable %#lx\n",
 				__func__, __pa(priv->pgtable));
-		pm_runtime_put(data->sysmmu);
-	} else if (ret > 0) {
-		dev_dbg(dev, "%s: IOMMU with pgtable 0x%lx already attached\n",
-					__func__, __pa(priv->pgtable));
-	} else {
-		dev_dbg(dev, "%s: Attached new IOMMU with pgtable 0x%lx\n",
-					__func__, __pa(priv->pgtable));
-	}
+	else
+		dev_dbg(dev, "%s: Attached IOMMU with pgtable 0x%lx%s\n",
+					__func__, __pa(priv->pgtable),
+					(ret == 0) ? "" : ", again");
 
 	return ret;
 }
@@ -791,39 +891,27 @@ static int exynos_iommu_attach_device(struct iommu_domain *domain,
 static void exynos_iommu_detach_device(struct iommu_domain *domain,
 				    struct device *dev)
 {
-	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
+	struct exynos_iommu_client *client = NULL;
 	struct exynos_iommu_domain *priv = domain->priv;
-	struct list_head *pos;
 	unsigned long flags;
-	bool found = false;
 
 	spin_lock_irqsave(&priv->lock, flags);
 
-	list_for_each(pos, &priv->clients) {
-		if (list_entry(pos, struct sysmmu_drvdata, node) == data) {
-			found = true;
+	list_for_each_entry(client, &priv->clients, node) {
+		if (client == dev->archdata.iommu) {
+			if (exynos_sysmmu_disable(dev))
+				list_del_init(&client->node);
 			break;
 		}
 	}
 
-	if (!found)
-		goto finish;
+	spin_unlock_irqrestore(&priv->lock, flags);
 
-	if (__exynos_sysmmu_disable(data)) {
+	if (client == dev->archdata.iommu)
 		dev_dbg(dev, "%s: Detached IOMMU with pgtable %#lx\n",
 					__func__, __pa(priv->pgtable));
-		list_del_init(&data->node);
-
-	} else {
-		dev_dbg(dev, "%s: Detaching IOMMU with pgtable %#lx delayed",
-					__func__, __pa(priv->pgtable));
-	}
-
-finish:
-	spin_unlock_irqrestore(&priv->lock, flags);
-
-	if (found)
-		pm_runtime_put(data->sysmmu);
+	else
+		dev_dbg(dev, "%s: No IOMMU is attached\n", __func__);
 }
 
 static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long iova,
@@ -940,7 +1028,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
 					       unsigned long iova, size_t size)
 {
 	struct exynos_iommu_domain *priv = domain->priv;
-	struct sysmmu_drvdata *data;
+	struct exynos_iommu_client *client;
 	unsigned long flags;
 	unsigned long *ent;
 	size_t err_page;
@@ -997,8 +1085,8 @@ done:
 	spin_unlock_irqrestore(&priv->pgtablelock, flags);
 
 	spin_lock_irqsave(&priv->lock, flags);
-	list_for_each_entry(data, &priv->clients, node)
-		sysmmu_tlb_invalidate_entry(data->dev, iova);
+	list_for_each_entry(client, &priv->clients, node)
+		sysmmu_tlb_invalidate_entry(client->dev, iova);
 	spin_unlock_irqrestore(&priv->lock, flags);
 
 	return size;
@@ -1082,3 +1170,275 @@ static int __init exynos_iommu_init(void)
 	return ret;
 }
 subsys_initcall(exynos_iommu_init);
+
+#ifdef CONFIG_PM_SLEEP
+static int sysmmu_pm_genpd_suspend(struct device *dev)
+{
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int ret = 0;
+	int i;
+
+	for (i = 0; i < client->num_sysmmu; i++) {
+		ret = pm_generic_suspend(client->sysmmu[i]);
+		if (ret)
+			break;
+	}
+
+	if (!ret)
+		ret = pm_generic_suspend(dev);
+
+	if (ret) {
+		int j;
+
+		for (j = 0; j < i; j++)
+			pm_generic_resume(client->sysmmu[j]);
+	}
+
+	return ret;
+}
+
+static int sysmmu_pm_genpd_resume(struct device *dev)
+{
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int ret = 0;
+	int i;
+
+	for (i = 0; i < client->num_sysmmu; i++) {
+		ret = pm_generic_resume(client->sysmmu[i]);
+		if (ret)
+			break;
+	}
+
+	if (!ret)
+		ret = pm_generic_resume(dev);
+
+	if (ret) {
+		int j;
+
+		for (j = 0; j < i; j++)
+			pm_generic_suspend(client->sysmmu[j]);
+	}
+
+	return ret;
+}
+#endif
+
+#ifdef CONFIG_PM_RUNTIME
+static void sysmmu_restore_state(struct device *sysmmu)
+{
+	struct sysmmu_drvdata *data = dev_get_drvdata(sysmmu);
+	unsigned long flags;
+
+	spin_lock_irqsave(&data->lock, flags);
+	data->runtime_active = true;
+	if (is_sysmmu_active(data))
+		__sysmmu_enable_nocount(data);
+	spin_unlock_irqrestore(&data->lock, flags);
+}
+
+static void sysmmu_save_state(struct device *sysmmu)
+{
+	struct sysmmu_drvdata *data = dev_get_drvdata(sysmmu);
+	unsigned long flags;
+
+	spin_lock_irqsave(&data->lock, flags);
+	if (is_sysmmu_active(data))
+		__sysmmu_disable_nocount(data);
+	data->runtime_active = false;
+	spin_unlock_irqrestore(&data->lock, flags);
+}
+
+static int sysmmu_pm_genpd_save_state(struct device *dev)
+{
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int (*cb)(struct device *__dev);
+	int i;
+
+	if (dev->type && dev->type->pm)
+		cb = dev->type->pm->runtime_suspend;
+	else if (dev->class && dev->class->pm)
+		cb = dev->class->pm->runtime_suspend;
+	else if (dev->bus && dev->bus->pm)
+		cb = dev->bus->pm->runtime_suspend;
+	else
+		cb = NULL;
+
+	if (!cb && dev->driver && dev->driver->pm)
+		cb = dev->driver->pm->runtime_suspend;
+
+	if (cb) {
+		int ret;
+
+		ret = cb(dev);
+		if (ret)
+			return ret;
+	}
+
+	for (i = 0; i < client->num_sysmmu; i++)
+		sysmmu_save_state(client->sysmmu[i]);
+
+	return 0;
+}
+
+static int sysmmu_pm_genpd_restore_state(struct device *dev)
+{
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int (*cb)(struct device *__dev);
+	int i;
+
+	if (dev->type && dev->type->pm)
+		cb = dev->type->pm->runtime_resume;
+	else if (dev->class && dev->class->pm)
+		cb = dev->class->pm->runtime_resume;
+	else if (dev->bus && dev->bus->pm)
+		cb = dev->bus->pm->runtime_resume;
+	else
+		cb = NULL;
+
+	if (!cb && dev->driver && dev->driver->pm)
+		cb = dev->driver->pm->runtime_resume;
+
+	for (i = 0; i < client->num_sysmmu; i++)
+		sysmmu_restore_state(client->sysmmu[i]);
+
+	if (cb) {
+		int ret;
+		ret = cb(dev);
+		if (ret) {
+			for (i = 0; i < client->num_sysmmu; i++)
+				sysmmu_save_state(client->sysmmu[i]);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+#endif
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS
+struct gpd_dev_ops sysmmu_devpm_ops = {
+#ifdef CONFIG_PM_RUNTIME
+	.save_state = &sysmmu_pm_genpd_save_state,
+	.restore_state = &sysmmu_pm_genpd_restore_state,
+#endif
+#ifdef CONFIG_PM_SLEEP
+	.suspend = &sysmmu_pm_genpd_suspend,
+	.resume = &sysmmu_pm_genpd_resume,
+#endif
+};
+#endif /* CONFIG_PM_GENERIC_DOMAINS */
+
+static int sysmmu_hook_driver_register(struct notifier_block *nb,
+					unsigned long val,
+					void *p)
+{
+	struct device *dev = p;
+
+	switch (val) {
+	case BUS_NOTIFY_BIND_DRIVER:
+	{
+		int i = 0;
+		int size = 0;
+		const __be32 *phandle;
+		struct exynos_iommu_client *client;
+
+		phandle = of_get_property(dev->of_node, "iommu", &size);
+		if (!phandle)
+			break;
+
+		size = size / sizeof(*phandle); /* number of elements */
+
+		client = devm_kzalloc(dev, sizeof(*client) * size, GFP_KERNEL);
+		if (!client) {
+			dev_err(dev, "No Memory for exynos_iommu_client\n");
+			return -ENOMEM;
+		}
+
+		client->num_sysmmu = size;
+		client->dev = dev;
+		INIT_LIST_HEAD(&client->node);
+		spin_lock_init(&client->lock);
+
+		for (i = 0; i < size; i++) {
+			struct device_node *np;
+			struct platform_device *sysmmu;
+
+			/* this always success: see above of_find_property() */
+			np = of_parse_phandle(dev->of_node, "iommu", i);
+
+			sysmmu = of_find_device_by_node(np);
+			if (!sysmmu) {
+				dev_err(dev,
+					"sysmmu node '%s' is not found\n",
+					np->name);
+				break;
+			}
+
+			client->sysmmu[i] = &sysmmu->dev;
+		}
+
+		if (i < size) {
+			while (--i >= 0)
+				of_node_put(client->sysmmu[i]->of_node);
+			devm_kfree(dev, client);
+			return -ENODEV;
+		}
+
+		i = pm_genpd_add_callbacks(dev, &sysmmu_devpm_ops, NULL);
+		if (i && (i != -ENOSYS)) {
+			dev_err(dev,
+				"Failed to register 'dev_pm_ops' for iommu\n");
+			devm_kfree(dev, client);
+			return i;
+		}
+
+		dev->archdata.iommu = client;
+		break;
+	}
+	case BUS_NOTIFY_BOUND_DRIVER:
+	{
+		struct exynos_iommu_client *client = dev->archdata.iommu;
+		if (dev->archdata.iommu &&
+				(!pm_runtime_enabled(dev) ||
+					 IS_ERR(dev_to_genpd(dev)))) {
+			int i;
+			for (i = 0; i < client->num_sysmmu; i++) {
+				struct sysmmu_drvdata *data;
+				pm_runtime_disable(client->sysmmu[i]);
+				data = dev_get_drvdata(client->sysmmu[i]);
+				if (!data)
+					continue;
+				data->runtime_active =
+					!pm_runtime_enabled(data->sysmmu);
+				if (data->runtime_active &&
+						is_sysmmu_active(data))
+					__sysmmu_enable_nocount(data);
+			}
+		}
+		break;
+	}
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+	{
+		if (dev->archdata.iommu) {
+			__pm_genpd_remove_callbacks(dev, false);
+
+			devm_kfree(dev, dev->archdata.iommu);
+
+			dev->archdata.iommu = NULL;
+		}
+		break;
+	}
+	} /* switch (val) */
+
+	return 0;
+}
+
+static struct notifier_block sysmmu_notifier = {
+	.notifier_call = &sysmmu_hook_driver_register,
+};
+
+static int __init exynos_iommu_prepare(void)
+{
+	return bus_register_notifier(&platform_bus_type, &sysmmu_notifier);
+}
+arch_initcall(exynos_iommu_prepare);
-- 
1.7.2.5




From shawn.guo at linaro.org  Fri Jul  5 08:35:42 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 5 Jul 2013 20:35:42 +0800
Subject: [PATCH v4] tty: serial: add Freescale lpuart driver support
In-Reply-To: <B56CDBE15CE27145A4B77D2D24263E851E5AFC@039-SN1MPN1-005.039d.mgd.msft.net>
References: <1369733161-19168-1-git-send-email-b35083@freescale.com>
 <20130705091449.GA20040@S2101-09.ap.freescale.net>
 <B56CDBE15CE27145A4B77D2D24263E851E5AFC@039-SN1MPN1-005.039d.mgd.msft.net>
Message-ID: <20130705123541.GB20040@S2101-09.ap.freescale.net>

On Fri, Jul 05, 2013 at 09:39:03AM +0000, Lu Jingchang-B35083 wrote:
> I explicitly removed the cr2 restore code on cleaning up the redundant code, and find it work well on normal operation.
> Low level debug is not supported on Vybrid so I didn't notice that problem.
> Will you fixing it? Or I submit a fix on it?

I can send a fix for that.  But before doing that, I would need your
help to understand why we need to clear those UARTCR2 bits for setting
up FIFO stuff at all.  From my quick testing, at least console still
works fine after removing all those UARTCR2 operations from
lpuart_setup_watermark().

Shawn



From ldewangan at nvidia.com  Fri Jul  5 08:41:51 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Fri, 5 Jul 2013 18:11:51 +0530
Subject: [PATCH] ARM: tegra: enable gpio-keys on dalmore
Message-ID: <1373028111-24246-1-git-send-email-ldewangan@nvidia.com>

Dalmore have the keys mounted on board which are connected
to different pins of Tegra.

Add the keys entry in DTS file to enable key functionality.
This will enable KEY_POWER, KEY_HOME, KEY_VOLUMEUP and
KEY_VOLUMEDOWN.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 arch/arm/boot/dts/tegra114-dalmore.dts |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index cb640eb..886b66d 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -976,4 +976,33 @@
 			 <&tegra_car TEGRA114_CLK_EXTERN1>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		power {
+			label = "Power";
+			gpios = <&gpio TEGRA_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
+			linux,code = <116>; /* KEY_POWER */
+			gpio-key,wakeup;
+		};
+
+		home {
+			label = "Home";
+			gpios = <&gpio TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
+			linux,code = <102>; /* KEY_HOME */
+		};
+
+		volume_up {
+			label = "VolumeUp";
+			gpios = <&gpio TEGRA_GPIO(R, 2) GPIO_ACTIVE_LOW>;
+			linux,code = <115>; /* KEY_VOLUMEUP */
+		};
+
+		volume_down {
+			label = "VolumeDown";
+			gpios = <&gpio TEGRA_GPIO(R, 1) GPIO_ACTIVE_LOW>;
+			linux,code = <114>; /* KEY_VOLUMEDOWN */
+		};
+	};
 };
-- 
1.7.1.1



From heiko at sntech.de  Fri Jul  5 08:40:18 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Fri, 5 Jul 2013 14:40:18 +0200
Subject: [PATCH v3 0/6] ARM: rockchip: add smp functionality
Message-ID: <201307051440.19428.heiko@sntech.de>

This series enables the use of the additional cores on Rockchip
Cortex-A9 SoCs.

To achieve this, add the scu, the needed sram and power-management-unit.

Tested on a rk3066a (dual core) by me and on a rk3188 (quad core)
by Ulrich Prinz.

(Note: rk3188 support in general needs additional upcoming patchsets)


changes since v2:
- rework the sram allocation following the suggestion from Philipp Zabel

changes since v1:
- add reserved block feature for mmio-sram, to not use two logical
  sram nodes
- the sram content is kept intact while the device is running, so
  copying the trampoline is only needed once

Heiko Stuebner (6):
  misc: sram: fix error path in sram_probe
  misc: sram: add ability to mark sram sections as reserved
  ARM: rockchip: add snoop-control-unit
  ARM: rockchip: add sram dt nodes and documentation
  ARM: rockchip: add power-management-unit dt node
  ARM: rockchip: add smp bringup code

 .../devicetree/bindings/arm/rockchip/pmu.txt       |   16 ++
 .../devicetree/bindings/arm/rockchip/smp-sram.txt  |   23 +++
 Documentation/devicetree/bindings/misc/sram.txt    |    8 +
 arch/arm/boot/dts/rk3066a.dtsi                     |   16 ++
 arch/arm/mach-rockchip/Kconfig                     |    1 +
 arch/arm/mach-rockchip/Makefile                    |    1 +
 arch/arm/mach-rockchip/core.h                      |   22 +++
 arch/arm/mach-rockchip/headsmp.S                   |   32 +++
 arch/arm/mach-rockchip/platsmp.c                   |  203 ++++++++++++++++++++
 arch/arm/mach-rockchip/rockchip.c                  |    2 +
 drivers/misc/sram.c                                |   79 +++++++-
 11 files changed, 398 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.txt
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
 create mode 100644 arch/arm/mach-rockchip/core.h
 create mode 100644 arch/arm/mach-rockchip/headsmp.S
 create mode 100644 arch/arm/mach-rockchip/platsmp.c

-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 08:40:53 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Fri, 5 Jul 2013 14:40:53 +0200
Subject: [PATCH v3 1/6] misc: sram: fix error path in sram_probe
In-Reply-To: <201307051440.19428.heiko@sntech.de>
References: <201307051440.19428.heiko@sntech.de>
Message-ID: <201307051440.53993.heiko@sntech.de>

The pool is created thru devm_gen_pool_create, so the call to
gen_pool_destroy is not necessary.
Instead the sram-clock must be turned off again if it exists.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
 drivers/misc/sram.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index d87cc91..afe66571 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -68,7 +68,8 @@ static int sram_probe(struct platform_device *pdev)
 	ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
 				res->start, size, -1);
 	if (ret < 0) {
-		gen_pool_destroy(sram->pool);
+		if (sram->clk)
+			clk_disable_unprepare(sram->clk);
 		return ret;
 	}
 
-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 08:41:27 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Fri, 5 Jul 2013 14:41:27 +0200
Subject: [PATCH v3 2/6] misc: sram: add ability to mark sram sections as
 reserved
In-Reply-To: <201307051440.19428.heiko@sntech.de>
References: <201307051440.19428.heiko@sntech.de>
Message-ID: <201307051441.27605.heiko@sntech.de>

Some SoCs need parts of their sram for special purposes. So while being part
of the periphal, it should not be part of the genpool controlling the sram.

Threfore add an option mmio-sram-reserved to keep arbitary portions of the
sram from being part of the pool.

Suggested-by: Rob Herring <robherring2 at gmail.com>
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
 Documentation/devicetree/bindings/misc/sram.txt |    8 +++
 drivers/misc/sram.c                             |   80 +++++++++++++++++++++--
 2 files changed, 82 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
index 4d0a00e..eae080e 100644
--- a/Documentation/devicetree/bindings/misc/sram.txt
+++ b/Documentation/devicetree/bindings/misc/sram.txt
@@ -8,9 +8,17 @@ Required properties:
 
 - reg : SRAM iomem address range
 
+Optional properties:
+
+- mmio-sram-reserved: ordered list of reserved chunks inside the sram that
+  should not become part of the genalloc pool.
+  Format is <base size>, <base size>, ...; with base being relative to the
+  reg property base.
+
 Example:
 
 sram: sram at 5c000000 {
 	compatible = "mmio-sram";
 	reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
+	mmio-sram-reserved = <0x0 0x100>; /* reserve 0x5c000000-0x5c000100 */
 };
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index afe66571..9131e4a 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -42,6 +42,13 @@ static int sram_probe(struct platform_device *pdev)
 	struct sram_dev *sram;
 	struct resource *res;
 	unsigned long size;
+	const __be32 *reserved_list = NULL;
+	int reserved_size = 0;
+	unsigned int cur_start = 0;
+	unsigned int cur_size;
+	unsigned int rstart;
+	unsigned int rsize;
+	int i;
 	int ret;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -65,12 +72,73 @@ static int sram_probe(struct platform_device *pdev)
 	if (!sram->pool)
 		return -ENOMEM;
 
-	ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
-				res->start, size, -1);
-	if (ret < 0) {
-		if (sram->clk)
-			clk_disable_unprepare(sram->clk);
-		return ret;
+	if (pdev->dev.of_node) {
+		reserved_list = of_get_property(pdev->dev.of_node,
+						"mmio-sram-reserved",
+						&reserved_size);
+		if (reserved_list) {
+			reserved_size /= sizeof(*reserved_list);
+			if (!reserved_size || reserved_size % 2) {
+				dev_warn(&pdev->dev, "wrong number of arguments in mmio-sram-reserved\n");
+				reserved_list = NULL;
+			}
+		}
+	}
+
+	if (!reserved_list)
+		reserved_size = 0;
+
+	for (i = 0; i < (reserved_size + 2); i += 2) {
+		if (i < reserved_size) {
+			/* get the next reserved block */
+			rstart = be32_to_cpu(*reserved_list++);
+			rsize = be32_to_cpu(*reserved_list++);
+
+			/* catch unsorted list entries */
+			if (rstart < cur_start) {
+				dev_err(&pdev->dev,
+					"unsorted reserved list (0x%x before current 0x%x)\n",
+					rstart, cur_start);
+				if (sram->clk)
+					clk_disable_unprepare(sram->clk);
+				return -EINVAL;
+			}
+
+			dev_dbg(&pdev->dev,
+				"found reserved block 0x%x-0x%x\n",
+				rstart, rstart + rsize);
+		} else {
+			/* the last chunk extends to the end of the region */
+			rstart = size;
+			rsize = 0;
+		}
+
+		/* current start is in a reserved block */
+		if (rstart <= cur_start) {
+			cur_start = rstart + rsize;
+			continue;
+		}
+
+		/*
+		 * allocate the space between the current starting
+		 * address and the following reserved block, or the
+		 * end of the region.
+		 */
+		cur_size = rstart - cur_start;
+
+		dev_dbg(&pdev->dev, "adding chunk 0x%x-0x%x\n",
+			cur_start, cur_start + cur_size);
+		ret = gen_pool_add_virt(sram->pool,
+				(unsigned long)virt_base + cur_start,
+				res->start + cur_start, cur_size, -1);
+		if (ret < 0) {
+			if (sram->clk)
+				clk_disable_unprepare(sram->clk);
+			return ret;
+		}
+
+		/* next allocation after this reserved block */
+		cur_start = rstart + rsize;
 	}
 
 	platform_set_drvdata(pdev, sram);
-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 08:41:57 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Fri, 5 Jul 2013 14:41:57 +0200
Subject: [PATCH v3 3/6] ARM: rockchip: add snoop-control-unit
In-Reply-To: <201307051440.19428.heiko@sntech.de>
References: <201307051440.19428.heiko@sntech.de>
Message-ID: <201307051441.57325.heiko@sntech.de>

This adds the device-node and config select to enable the
scu in all Rockchip Cortex-A9 SoCs.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
 arch/arm/boot/dts/rk3066a.dtsi |    5 +++++
 arch/arm/mach-rockchip/Kconfig |    1 +
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 56bfac9..26c4311 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -48,6 +48,11 @@
 		compatible = "simple-bus";
 		ranges;
 
+		scu at 1013c000 {
+			compatible = "arm,cortex-a9-scu";
+			reg = <0x1013c000 0x100>;
+		};
+
 		gic: interrupt-controller at 1013d000 {
 			compatible = "arm,cortex-a9-gic";
 			interrupt-controller;
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 25ee12b..0f5484c 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -5,6 +5,7 @@ config ARCH_ROCKCHIP
 	select ARCH_REQUIRE_GPIOLIB
 	select ARM_GIC
 	select CACHE_L2X0
+	select HAVE_ARM_SCU
 	select HAVE_ARM_TWD if LOCAL_TIMERS
 	select HAVE_SMP
 	select LOCAL_TIMERS if SMP
-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 08:42:27 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Fri, 5 Jul 2013 14:42:27 +0200
Subject: [PATCH v3 4/6] ARM: rockchip: add sram dt nodes and documentation
In-Reply-To: <201307051440.19428.heiko@sntech.de>
References: <201307051440.19428.heiko@sntech.de>
Message-ID: <201307051442.27482.heiko@sntech.de>

The Rockchip SoCs need a special part of their sram for bringup
of additional cores. Therefore also add a reserved section when adding the
mmio-sram node to keep the sram driver from using this space.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
 .../devicetree/bindings/arm/rockchip/smp-sram.txt  |   23 ++++++++++++++++++++
 arch/arm/boot/dts/rk3066a.dtsi                     |    6 +++++
 2 files changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt

diff --git a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt b/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
new file mode 100644
index 0000000..80c878e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
@@ -0,0 +1,23 @@
+Rockchip SRAM for smp bringup:
+------------------------------
+
+Rockchip's smp-capable SoCs use the first part of the sram for the bringup
+of the cores. Once the core gets powered up it executes the code that is
+residing at the very beginning of the sram.
+
+Therefore a reserved section has to be added to the mmio-sram declaration.
+
+Required node properties:
+- compatible : should contain both "rockchip,rk3066-sram", "mmio-sram"
+  so that the smp code can select the correct sram node.
+
+The rest of the properties should follow the generic mmio-sram discription
+found in ../../misc/sram.txt
+
+Example:
+
+	sram: sram at 10080000 {
+		compatible = "rockchip,rk3066-sram", "mmio-sram";
+		reg = <0x10080000 0x10000>;
+		mmio-sram-reserved = <0x0 0x50>;
+	};
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 26c4311..24d1941 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -53,6 +53,12 @@
 			reg = <0x1013c000 0x100>;
 		};
 
+		sram: sram at 10080000 {
+			compatible = "rockchip,rk3066-sram", "mmio-sram";
+			reg = <0x10080000 0x10000>;
+			mmio-sram-reserved = <0x0 0x50>;
+		};
+
 		gic: interrupt-controller at 1013d000 {
 			compatible = "arm,cortex-a9-gic";
 			interrupt-controller;
-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 08:42:57 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Fri, 5 Jul 2013 14:42:57 +0200
Subject: [PATCH v3 5/6] ARM: rockchip: add power-management-unit dt node
In-Reply-To: <201307051440.19428.heiko@sntech.de>
References: <201307051440.19428.heiko@sntech.de>
Message-ID: <201307051442.58247.heiko@sntech.de>

The pmu is needed to bring up the cores during smp operations.
Therefore add a node and documentation for it.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
 Documentation/devicetree/bindings/arm/rockchip/pmu.txt |   16 ++++++++++++++++
 arch/arm/boot/dts/rk3066a.dtsi                         |    5 +++++
 2 files changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.txt

diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.txt b/Documentation/devicetree/bindings/arm/rockchip/pmu.txt
new file mode 100644
index 0000000..3ee9b42
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.txt
@@ -0,0 +1,16 @@
+Rockchip power-management-unit:
+-------------------------------
+
+The pmu is used to turn off and on different power domains of the SoCs
+This includes the power to the CPU cores.
+
+Required node properties:
+- compatible value : = "rockchip,rk3066-pmu";
+- reg : physical base address and the size of the registers window
+
+Example:
+
+	pmu at 20004000 {
+		compatible = "rockchip,rk3066-pmu";
+		reg = <0x20004000 0x100>;
+	};
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 24d1941..43ac7c8 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -59,6 +59,11 @@
 			mmio-sram-reserved = <0x0 0x50>;
 		};
 
+		pmu at 20004000 {
+			compatible = "rockchip,rk3066-pmu";
+			reg = <0x20004000 0x100>;
+		};
+
 		gic: interrupt-controller at 1013d000 {
 			compatible = "arm,cortex-a9-gic";
 			interrupt-controller;
-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 08:43:26 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Fri, 5 Jul 2013 14:43:26 +0200
Subject: [PATCH v3 6/6] ARM: rockchip: add smp bringup code
In-Reply-To: <201307051440.19428.heiko@sntech.de>
References: <201307051440.19428.heiko@sntech.de>
Message-ID: <201307051443.27172.heiko@sntech.de>

This adds the necessary smp-operations and startup code to use
additional cores on Rockchip SoCs.

We currently hog the power management unit in the smp code, as it is
necessary to control the power to the cpu core and nothing else is
currently using it, so a generic implementation can be done later.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
 arch/arm/mach-rockchip/Makefile   |    1 +
 arch/arm/mach-rockchip/core.h     |   22 ++++
 arch/arm/mach-rockchip/headsmp.S  |   32 ++++++
 arch/arm/mach-rockchip/platsmp.c  |  203 +++++++++++++++++++++++++++++++++++++
 arch/arm/mach-rockchip/rockchip.c |    2 +
 5 files changed, 260 insertions(+)
 create mode 100644 arch/arm/mach-rockchip/core.h
 create mode 100644 arch/arm/mach-rockchip/headsmp.S
 create mode 100644 arch/arm/mach-rockchip/platsmp.c

diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 1547d4f..4377a14 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip.o
+obj-$(CONFIG_SMP) += headsmp.o platsmp.o
diff --git a/arch/arm/mach-rockchip/core.h b/arch/arm/mach-rockchip/core.h
new file mode 100644
index 0000000..e2e7c9d
--- /dev/null
+++ b/arch/arm/mach-rockchip/core.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (c) 2013 MundoReader S.L.
+ * Author: Heiko Stuebner <heiko at sntech.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ */
+
+extern char rockchip_secondary_trampoline;
+extern char rockchip_secondary_trampoline_end;
+
+extern unsigned long rockchip_boot_fn;
+extern void rockchip_secondary_startup(void);
+
+extern struct smp_operations rockchip_smp_ops;
diff --git a/arch/arm/mach-rockchip/headsmp.S b/arch/arm/mach-rockchip/headsmp.S
new file mode 100644
index 0000000..3dd72f7
--- /dev/null
+++ b/arch/arm/mach-rockchip/headsmp.S
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2013 MundoReader S.L.
+ * Author: Heiko Stuebner <heiko at sntech.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ */
+#include <linux/linkage.h>
+#include <linux/init.h>
+
+	__CPUINIT
+
+ENTRY(rockchip_secondary_startup)
+	bl	v7_invalidate_l1
+	b	secondary_startup
+ENDPROC(rockchip_secondary_startup)
+
+ENTRY(rockchip_secondary_trampoline)
+	ldr	pc, 1f
+ENDPROC(rockchip_secondary_trampoline)
+	.globl	rockchip_boot_fn
+rockchip_boot_fn:
+1:	.space	4
+
+ENTRY(rockchip_secondary_trampoline_end)
diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c
new file mode 100644
index 0000000..4b8fadc
--- /dev/null
+++ b/arch/arm/mach-rockchip/platsmp.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (c) 2013 MundoReader S.L.
+ * Author: Heiko Stuebner <heiko at sntech.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ */
+
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/smp.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+#include <asm/cacheflush.h>
+#include <asm/smp_scu.h>
+#include <asm/smp_plat.h>
+#include <asm/mach/map.h>
+
+#include "core.h"
+
+static void __iomem *scu_base_addr;
+static void __iomem *sram_base_addr;
+static int ncores;
+
+/*
+ * temporary PMU handling
+ */
+
+#define PMU_PWRDN_CON		0x08
+#define PMU_PWRDN_ST		0x0c
+
+static void __iomem *pmu_base_addr;
+
+static inline bool pmu_power_domain_is_on(int pd)
+{
+	return !(readl_relaxed(pmu_base_addr + PMU_PWRDN_ST) & BIT(pd));
+}
+
+static void pmu_set_power_domain(int pd, bool on)
+{
+	u32 val = readl_relaxed(pmu_base_addr + PMU_PWRDN_CON);
+	if (on)
+		val &= ~BIT(pd);
+	else
+		val |=  BIT(pd);
+	writel(val, pmu_base_addr + PMU_PWRDN_CON);
+
+	while (pmu_power_domain_is_on(pd) != on) { }
+}
+
+/*
+ * Handling of CPU cores
+ */
+
+static int __cpuinit rockchip_boot_secondary(unsigned int cpu,
+					     struct task_struct *idle)
+{
+	if (!sram_base_addr || !pmu_base_addr) {
+		pr_err("%s: sram or pmu missing for cpu boot\n", __func__);
+		return -ENXIO;
+	}
+
+	if (cpu >= ncores) {
+		pr_err("%s: cpu %d outside maximum number of cpus %d\n",
+							__func__, cpu, ncores);
+		return -ENXIO;
+	}
+
+	/* start the core */
+	pmu_set_power_domain(0 + cpu, true);
+
+	return 0;
+}
+
+/**
+ * rockchip_smp_prepare_sram - populate necessary sram block
+ * Starting cores execute the code residing at the start of the on-chip sram
+ * after power-on. Therefore make sure, this sram region is reserved and
+ * big enough. After this check, copy the trampoline code that directs the
+ * core to the real startup code in ram into the sram-region.
+ * @node: mmio-sram device node
+ */
+static int __init rockchip_smp_prepare_sram(struct device_node *node)
+{
+	unsigned int trampoline_sz = &rockchip_secondary_trampoline_end -
+					    &rockchip_secondary_trampoline;
+	const __be32 *reserved_list = NULL;
+	int reserved_size;
+	int rstart = -1;
+	unsigned int rsize;
+	unsigned int i;
+
+	reserved_list = of_get_property(node, "mmio-sram-reserved",
+					&reserved_size);
+	if (!reserved_list) {
+		pr_err("%s: wrong number of arguments in mmio-sram-reserved\n",
+		       __func__);
+		return -ENOENT;
+	}
+
+	reserved_size /= sizeof(*reserved_list);
+	if (!reserved_size || reserved_size % 2) {
+		pr_err("%s: wrong number of arguments in mmio-sram-reserved\n",
+		       __func__);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < reserved_size; i += 2) {
+		/* get the next reserved block */
+		rstart = be32_to_cpu(*reserved_list++);
+		rsize = be32_to_cpu(*reserved_list++);
+
+		if (!rstart)
+			break;
+	}
+
+	if (rstart) {
+		pr_err("%s: start of sram is not reserved from mmio-sram\n",
+		       __func__);
+		return -EINVAL;
+	}
+
+	if (rsize < trampoline_sz) {
+		pr_err("%s: reserved block with size 0x%x is to small for trampoline size 0x%x\n",
+		       __func__, rsize, trampoline_sz);
+		return -EINVAL;
+	}
+
+	sram_base_addr = of_iomap(node, 0);
+
+	/* set the boot function for the sram code */
+	rockchip_boot_fn = virt_to_phys(rockchip_secondary_startup);
+
+	/* copy the trampoline to sram, that runs during startup of the core */
+	memcpy(sram_base_addr, &rockchip_secondary_trampoline, trampoline_sz);
+	flush_cache_all();
+	outer_clean_range(0, trampoline_sz);
+
+	dsb_sev();
+
+	return 0;
+}
+
+static void __init rockchip_smp_prepare_cpus(unsigned int max_cpus)
+{
+	struct device_node *node;
+	unsigned int i;
+
+	node = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
+	if (!node) {
+		pr_err("%s: missing scu\n", __func__);
+		return;
+	}
+
+	scu_base_addr = of_iomap(node, 0);
+	if (!scu_base_addr) {
+		pr_err("%s: could not map scu registers\n", __func__);
+		return;
+	}
+
+	node = of_find_compatible_node(NULL, NULL, "rockchip,rk3066-sram");
+	if (!node) {
+		pr_err("%s: could not find sram dt node\n", __func__);
+		return;
+	}
+
+	if (rockchip_smp_prepare_sram(node))
+		return;
+
+	node = of_find_compatible_node(NULL, NULL, "rockchip,rk3066-pmu");
+	if (!node) {
+		pr_err("%s: could not find sram dt node\n", __func__);
+		return;
+	}
+
+	pmu_base_addr = of_iomap(node, 0);
+
+	/*
+	 * While the number of cpus is gathered from dt, also get the number
+	 * of cores from the scu to verify this value when booting the cores.
+	 */
+	ncores = scu_get_core_count(scu_base_addr);
+
+	scu_enable(scu_base_addr);
+
+	/* Make sure that all cores except the first are really off */
+	for (i = 1; i < ncores; i++)
+		pmu_set_power_domain(0 + i, false);
+}
+
+struct smp_operations rockchip_smp_ops __initdata = {
+	.smp_prepare_cpus	= rockchip_smp_prepare_cpus,
+	.smp_boot_secondary	= rockchip_boot_secondary,
+};
diff --git a/arch/arm/mach-rockchip/rockchip.c b/arch/arm/mach-rockchip/rockchip.c
index 724d2d8..a0c1f19 100644
--- a/arch/arm/mach-rockchip/rockchip.c
+++ b/arch/arm/mach-rockchip/rockchip.c
@@ -24,6 +24,7 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <asm/hardware/cache-l2x0.h>
+#include "core.h"
 
 static void __init rockchip_timer_init(void)
 {
@@ -46,6 +47,7 @@ static const char * const rockchip_board_dt_compat[] = {
 };
 
 DT_MACHINE_START(ROCKCHIP_DT, "Rockchip Cortex-A9 (Device Tree)")
+	.smp		= smp_ops(rockchip_smp_ops),
 	.init_machine	= rockchip_dt_init,
 	.init_time	= rockchip_timer_init,
 	.dt_compat	= rockchip_board_dt_compat,
-- 
1.7.10.4



From festevam at gmail.com  Fri Jul  5 08:55:40 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 5 Jul 2013 09:55:40 -0300
Subject: [PATCH v3 2/6] misc: sram: add ability to mark sram sections as
 reserved
In-Reply-To: <201307051441.27605.heiko@sntech.de>
References: <201307051440.19428.heiko@sntech.de>
 <201307051441.27605.heiko@sntech.de>
Message-ID: <CAOMZO5AHX0UpeKQh+faPT=MfCf53eo=kXigtOZd7iuKrz-sFeA@mail.gmail.com>

On Fri, Jul 5, 2013 at 9:41 AM, Heiko St?bner <heiko at sntech.de> wrote:
> Some SoCs need parts of their sram for special purposes. So while being part
> of the periphal, it should not be part of the genpool controlling the sram.
>
> Threfore add an option mmio-sram-reserved to keep arbitary portions of the
> sram from being part of the pool.
>
> Suggested-by: Rob Herring <robherring2 at gmail.com>
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
> ---
>  Documentation/devicetree/bindings/misc/sram.txt |    8 +++
>  drivers/misc/sram.c                             |   80 +++++++++++++++++++++--
>  2 files changed, 82 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
> index 4d0a00e..eae080e 100644
> --- a/Documentation/devicetree/bindings/misc/sram.txt
> +++ b/Documentation/devicetree/bindings/misc/sram.txt
> @@ -8,9 +8,17 @@ Required properties:
>
>  - reg : SRAM iomem address range
>
> +Optional properties:
> +
> +- mmio-sram-reserved: ordered list of reserved chunks inside the sram that
> +  should not become part of the genalloc pool.
> +  Format is <base size>, <base size>, ...; with base being relative to the
> +  reg property base.

Isn't it a typo?

I think you meant:
Format is <base start>, <reserved size>,

> +
>  Example:
>
>  sram: sram at 5c000000 {
>         compatible = "mmio-sram";
>         reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
> +       mmio-sram-reserved = <0x0 0x100>; /* reserve 0x5c000000-0x5c000100 */
>  };


From james.hogan at imgtec.com  Fri Jul  5 09:12:08 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Fri, 5 Jul 2013 14:12:08 +0100
Subject: [RFC] clk: add flags to distinguish xtal clocks
In-Reply-To: <1372971912-10877-1-git-send-email-coelho@ti.com>
References: <1372971912-10877-1-git-send-email-coelho@ti.com>
Message-ID: <CAAG0J98UL5sLTmRx1o8XnbK8qWv_qNi9+zwuyPBbbYExPSbw8g@mail.gmail.com>

On 4 July 2013 22:05, Luciano Coelho <coelho at ti.com> wrote:
> Add a flag that indicate whether the clock is a crystal or not.  Since
> no clocks set this flag right now, include an additional flag that
> indicates whether the type is set or not.  If the CLK_IS_TYPE_DEFINED
> flag is not set, the value of the CLK_IS_TYPE_XTAL flag is undefined.
> This ensures backwards compatibility.
>
> Additionally, parse a new device tree binding in clk-fixed-rate to set
> this flag.
>
> Signed-off-by: Luciano Coelho <coelho at ti.com>
> ---
>
> I'm not  familiar with the common clock framework and I'm not
> entirely sure the flags can be used in such a way, but to me it looks
> reasonable, since some clock consumers may need to know what type of
> clock is being provided.
>
> Specifically, the wl12xx firmware needs to know if the clock is XTAL
> or not to handle the stabilization and boosts properly.
>
> My main idea is that I need to pass this information in the device
> tree definition of the clocks, so that the driver can pass this
> information on to the firmware.
>
> Please let me know if this looks ok or not.  If not, please let me
> know if you have any other ideas on how to solve my problem (of
> knowing whether the clock attached to the WiLink chip is XTAL or not).

The TZ1090 SoC has something that sounds possibly similar, where some
of the XTAL pads have a bypass bit, which according to the hardware
engineer I asked should be enabled when you want to use the
corresponding XTAL pads as a clock input pad rather than an
oscillator. I was considering extending clk-fixed-rate (via a wrapper
driver) to parse a custom DT property and a register address / bit
number and set the bypass bit as appropriate itself.

So I was wondering, is there a particular reason you don't have a DT
property on the node for the device that needs to know what type of
clock it is, rather than the clock node itself? That way you're not
depending directly on the generic common clock framework to be able to
tell you such electrical details.

Cheers
James


From tglx at linutronix.de  Fri Jul  5 09:19:57 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 5 Jul 2013 15:19:57 +0200 (CEST)
Subject: hrtimer: one more expiry time overflow check in hrtimer_interrupt
In-Reply-To: <51D6B300.20804@renesas.com>
References: <51B6D4C4.9080400@renesas.com>
 <alpine.DEB.2.02.1306281416080.4013@ionos.tec.linutronix.de>
 <51D6B300.20804@renesas.com>
Message-ID: <alpine.DEB.2.02.1307051516050.32106@ionos.tec.linutronix.de>

On Fri, 5 Jul 2013, Shinya Kuribayashi wrote:
> On 6/28/2013 9:22 PM, Thomas Gleixner wrote:
> >> On the other hand, we have another call site of tick_program_event() at
> >> the bottom of hrtimer_interrupt().  The warning this time is triggered
> >> there, so we need to apply the same fix to it.
> > 
> > Well, the problem is that you are just papering over the underlying
> > issue of 32bit systems not being prepared for the year 2038 issue.
> > 
> > Just blindly silencing the warning is not going to make the system
> > survive 2038 in any sane way. All timespec/val related time functions
> > dealing with the clock realtime domain are simply broken in 2038 on
> > 32bit, so it does not matter whether a warning triggers or not.
> 
> You're right.  With this patch applied, the hrtimer_interrupt /looks/
> back to normal, but /proc/timer_list still show that "expires at [in
> negative range]":
> 
>     active timers:
>      #0: tick_cpu_sched, tick_sched_timer, S:01
>      # expires at 50812500000-50812500000 nsecs [in -165398341280 to -165398341280 nsecs]
> 
> This shouldn't happen and something weird is still going on.

I told you :)
 
> > We really need to tackle the underlying problem and not bandaiding a
> > known to be broken system.
> 
> Agreed, but a little bit hard task for me.  This is 100% reproducible,
> so I can help debug / verification.  Please let me know, if necessary.

That will take some time. It's quite a huge change all over the
place. We are aware of that fact and we have ideas how to fix it, but
that won't happen in the near future as we need to discuss the user
space visible changes as well. But we have started to discuss possible
solutions, so this will be solved way before 1.1.2038 :)

Thanks,

	tglx


From vaibhav.bedia at ti.com  Fri Jul  5 09:20:10 2013
From: vaibhav.bedia at ti.com (Bedia, Vaibhav)
Date: Fri, 5 Jul 2013 13:20:10 +0000
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130705115959.GQ5523@atomide.com>
References: <51D577E6.5010507@newflow.co.uk>
 <51D59146.3070002@newflow.co.uk> <51D59C0E.8080003@newflow.co.uk>
 <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
Message-ID: <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>

Hi Tony,

On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> * Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 01:17]:
> > 
> > I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> > provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> > that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> > also results in the console UART getting reset and idled during bootup and that's where
> > the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> > the system booting fine. 
> > 
> > I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> > omap_serial_early_init() to get earlyprintk working again.
> 
> Hmm nothing should get idled while earlyprintk is running, and then when the
> serial driver kicks in it should not idle anything by default. And for DT based
> booting we should not have mach-omap2/serial.c initialize anything.
> 

If I add in the HWMOD flags without any reverts I get to the point where the serial driver
comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
just like Mark reported.

> I wonder if this is because the timeouts get now initialized to 0 instead
> of -1 for the serial driver?
> 

You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.

Regards,
Vaibhav

===
[1]

[    0.000000] Booting Linux on physical CPU 0x0
<...>
[    0.190107] SMP: Total of 1 processors activated (363.72 BogoMIPS).
[    0.196711] CPU: All CPU(s) started in SVC mode.
[    0.205580] devtmpfs: initialized
<stops here if booted with earlyprintk>

[2]
[    0.000000] Booting Linux on physical CPU 0x0
<...>
[    1.453364] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[    1.467121] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
<stops here if booted with earlyprintk>


From balbi at ti.com  Fri Jul  5 09:21:07 2013
From: balbi at ti.com (Felipe Balbi)
Date: Fri, 5 Jul 2013 16:21:07 +0300
Subject: [RFC] clk: add flags to distinguish xtal clocks
In-Reply-To: <CAAG0J98UL5sLTmRx1o8XnbK8qWv_qNi9+zwuyPBbbYExPSbw8g@mail.gmail.com>
References: <1372971912-10877-1-git-send-email-coelho@ti.com>
 <CAAG0J98UL5sLTmRx1o8XnbK8qWv_qNi9+zwuyPBbbYExPSbw8g@mail.gmail.com>
Message-ID: <20130705132107.GL19262@arwen.pp.htv.fi>

On Fri, Jul 05, 2013 at 02:12:08PM +0100, James Hogan wrote:
> On 4 July 2013 22:05, Luciano Coelho <coelho at ti.com> wrote:
> > Add a flag that indicate whether the clock is a crystal or not.  Since
> > no clocks set this flag right now, include an additional flag that
> > indicates whether the type is set or not.  If the CLK_IS_TYPE_DEFINED
> > flag is not set, the value of the CLK_IS_TYPE_XTAL flag is undefined.
> > This ensures backwards compatibility.
> >
> > Additionally, parse a new device tree binding in clk-fixed-rate to set
> > this flag.
> >
> > Signed-off-by: Luciano Coelho <coelho at ti.com>
> > ---
> >
> > I'm not  familiar with the common clock framework and I'm not
> > entirely sure the flags can be used in such a way, but to me it looks
> > reasonable, since some clock consumers may need to know what type of
> > clock is being provided.
> >
> > Specifically, the wl12xx firmware needs to know if the clock is XTAL
> > or not to handle the stabilization and boosts properly.
> >
> > My main idea is that I need to pass this information in the device
> > tree definition of the clocks, so that the driver can pass this
> > information on to the firmware.
> >
> > Please let me know if this looks ok or not.  If not, please let me
> > know if you have any other ideas on how to solve my problem (of
> > knowing whether the clock attached to the WiLink chip is XTAL or not).
> 
> The TZ1090 SoC has something that sounds possibly similar, where some
> of the XTAL pads have a bypass bit, which according to the hardware
> engineer I asked should be enabled when you want to use the
> corresponding XTAL pads as a clock input pad rather than an
> oscillator. I was considering extending clk-fixed-rate (via a wrapper
> driver) to parse a custom DT property and a register address / bit
> number and set the bypass bit as appropriate itself.
> 
> So I was wondering, is there a particular reason you don't have a DT
> property on the node for the device that needs to know what type of
> clock it is, rather than the clock node itself? That way you're not
> depending directly on the generic common clock framework to be able to
> tell you such electrical details.

three things here:

1) you end up with several devices implementing the clock type
attribute.

2) the type is a property of the clock itself

3) At least WiLink, can work with both types of clocks.

considering those, I really think this should belong to the clock node.
Otherwise Imagine how your DT would look like:

clock {
	compatible = "fixed-rate";
	...
};

wilink {
	clocks = &clock;
	wilink,btw-this-time-we-are-using-xtal;
	...
};

where you could:

clock {
	compatible = "fixed-rate";
	clock-type = "xtal";
	...
};

wilink {
	clocks = &clock;
	...
};

second option looks a lot cleaner to me.

-- 
balbi
-------------- 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/20130705/64e53508/attachment.sig>

From coelho at ti.com  Fri Jul  5 09:22:05 2013
From: coelho at ti.com (Luciano Coelho)
Date: Fri, 5 Jul 2013 16:22:05 +0300
Subject: [RFC] clk: add flags to distinguish xtal clocks
In-Reply-To: <CAAG0J98UL5sLTmRx1o8XnbK8qWv_qNi9+zwuyPBbbYExPSbw8g@mail.gmail.com>
References: <1372971912-10877-1-git-send-email-coelho@ti.com>
 <CAAG0J98UL5sLTmRx1o8XnbK8qWv_qNi9+zwuyPBbbYExPSbw8g@mail.gmail.com>
Message-ID: <1373030525.21065.172.camel@cumari.coelho.fi>

On Fri, 2013-07-05 at 14:12 +0100, James Hogan wrote:
> On 4 July 2013 22:05, Luciano Coelho <coelho at ti.com> wrote:
> > Add a flag that indicate whether the clock is a crystal or not.  Since
> > no clocks set this flag right now, include an additional flag that
> > indicates whether the type is set or not.  If the CLK_IS_TYPE_DEFINED
> > flag is not set, the value of the CLK_IS_TYPE_XTAL flag is undefined.
> > This ensures backwards compatibility.
> >
> > Additionally, parse a new device tree binding in clk-fixed-rate to set
> > this flag.
> >
> > Signed-off-by: Luciano Coelho <coelho at ti.com>
> > ---
> >
> > I'm not  familiar with the common clock framework and I'm not
> > entirely sure the flags can be used in such a way, but to me it looks
> > reasonable, since some clock consumers may need to know what type of
> > clock is being provided.
> >
> > Specifically, the wl12xx firmware needs to know if the clock is XTAL
> > or not to handle the stabilization and boosts properly.
> >
> > My main idea is that I need to pass this information in the device
> > tree definition of the clocks, so that the driver can pass this
> > information on to the firmware.
> >
> > Please let me know if this looks ok or not.  If not, please let me
> > know if you have any other ideas on how to solve my problem (of
> > knowing whether the clock attached to the WiLink chip is XTAL or not).
> 
> The TZ1090 SoC has something that sounds possibly similar, where some
> of the XTAL pads have a bypass bit, which according to the hardware
> engineer I asked should be enabled when you want to use the
> corresponding XTAL pads as a clock input pad rather than an
> oscillator.

Cool, good to know that I'm not alone here. ;)


>  I was considering extending clk-fixed-rate (via a wrapper
> driver) to parse a custom DT property and a register address / bit
> number and set the bypass bit as appropriate itself.

I thought about this too.  I actually have a "driver" for my clocks,
because normally they're not part of the main board, but part of the
module that contains the WiLink chip.  In those cases, I don't want my
clocks to be used as a generic clk-fixed-rate by the clock framework.
But the only difference in my "wrapper" is that it matches
"ti,wilink-clock" instead of "fixed-clock".


> So I was wondering, is there a particular reason you don't have a DT
> property on the node for the device that needs to know what type of
> clock it is, rather than the clock node itself? That way you're not
> depending directly on the generic common clock framework to be able to
> tell you such electrical details.

I think this is a detail of the clock itself, not of the user of the
clock.  Of course, the user of the clock needs to know what to do if the
clock is XTAL.  But the information of whether it is a XTAL or not
should be in the clock data.

I tried to make a generic solution that everyone could use.  For
instance, you. :) You could use the same bit that I implemented and, in
your driver, convert that bit into the action you need to take.


--
Luca.



From vaibhav.bedia at ti.com  Fri Jul  5 09:31:08 2013
From: vaibhav.bedia at ti.com (Bedia, Vaibhav)
Date: Fri, 5 Jul 2013 13:31:08 +0000
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
References: <51D577E6.5010507@newflow.co.uk>
 <51D59146.3070002@newflow.co.uk> <51D59C0E.8080003@newflow.co.uk>
 <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
Message-ID: <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>

On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
> Hi Tony,
> 
> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> > * Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 01:17]:
> > > 
> > > I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> > > provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> > > that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> > > also results in the console UART getting reset and idled during bootup and that's where
> > > the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> > > the system booting fine. 
> > > 
> > > I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> > > omap_serial_early_init() to get earlyprintk working again.
> > 
> > Hmm nothing should get idled while earlyprintk is running, and then when the
> > serial driver kicks in it should not idle anything by default. And for DT based
> > booting we should not have mach-omap2/serial.c initialize anything.
> > 
> 
> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
> just like Mark reported.
> 

Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.

> > I wonder if this is because the timeouts get now initialized to 0 instead
> > of -1 for the serial driver?
> > 
> 
> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> 
> Regards,
> Vaibhav
> 
> ===
> [1]
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> <...>
> [    0.190107] SMP: Total of 1 processors activated (363.72 BogoMIPS).
> [    0.196711] CPU: All CPU(s) started in SVC mode.
> [    0.205580] devtmpfs: initialized
> <stops here if booted with earlyprintk>
> 
> [2]
> [    0.000000] Booting Linux on physical CPU 0x0
> <...>
> [    1.453364] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
> [    1.467121] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> <stops here if booted with earlyprintk>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



From mpa at pengutronix.de  Fri Jul  5 09:45:09 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Fri,  5 Jul 2013 15:45:09 +0200
Subject: [PATCH] ARM: dts: imx27 phyCARD-S remove wrong I2C RTC
In-Reply-To: <1372782469.486055292@f129.mail.ru>
References: <1372782469.486055292@f129.mail.ru>
Message-ID: <1373031909-16178-1-git-send-email-mpa@pengutronix.de>

Fixup of commit 7874d595b78e431f0f661d2fe47625649308a52e
"ARM: dts: Add device tree support for phycard pca100".

Remove wrong I2C RTC node.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---

Thanks, Alexander, you are right. I2C2 has no RTC.

Regards,

Markus

 arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
index ec52b6d..01ee807 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
@@ -55,11 +55,6 @@
 		reg = <0x4a>;
 	};
 
-	rtc at 51 {
-		compatible = "nxp,pcf8563";
-		reg = <0x51>;
-	};
-
 	at24 at 52 {
 		compatible = "at,24c32";
 		pagesize = <32>;
-- 
1.8.2.1



From nm at ti.com  Fri Jul  5 09:55:07 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 5 Jul 2013 08:55:07 -0500
Subject: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to
 control PMIC over VC/VP
In-Reply-To: <20130704154105.GD27646@sirena.org.uk>
References: <1371849949-12649-1-git-send-email-nm@ti.com>
 <1371849949-12649-2-git-send-email-nm@ti.com>
 <20130704154105.GD27646@sirena.org.uk>
Message-ID: <20130705135507.GA17439@kahuna>

On 16:41-20130704, Mark Brown wrote:
> On Fri, Jun 21, 2013 at 04:25:42PM -0500, Nishanth Menon wrote:
> 
> > +static const struct omap_pmic_info omap_twl4030_vdd1 = {
> > +	.slave_addr = 0x12,
> > +	.voltage_reg_addr = 0x00,
> > +	.cmd_reg_addr = 0x00,
> > +	.i2c_timeout_us = 200,
> > +	.slew_rate_uV = 4000,
> > +	.step_size_uV = 12500,
> > +	.min_uV = 600000,
> > +	.max_uV = 1450000,
> > +	.voltage_selector_offset = 0,
> > +	.voltage_selector_mask = 0x7F,
> > +	.voltage_selector_setbits = 0x0,
> > +	.voltage_selector_zero = false,
> > +};
> 
> So, this still has the thing where all the data about the PMIC is
> replicated (but now in this driver).  It should be possible to pull all
> the above information except possibly the I2C timeout and perhaps the
> I2C address (if there's a separate control interface) from the standard
> regulator core data structures for the PMIC.  This would allow the
> driver to Just Work with any PMIC without needing to add it in two
> places.
> 
> Other than that this looks good, the only issue I see is where the
> driver is getting the data from.
I like the idea and had tried to implement it as well..lets get down to
the details: If I understand what you are stating,
regulators such as twl-regulator has the same/similar data that is
represented here. twl-regulator uses standard i2c path, it cannot
send voltage over so called "SR path". Alrite, so, lets say we reuse
definition of VDD1,
option 1) we just bypass get_voltage/set_voltage to point through to
this function. result will be something similar to what we got here[1]
Again, based on this discussion, it is wrong - and we already did implement
the *wrong* way in OMAP and the new code is supposed to throw away the
old code once all relevant platforms are converted to DT.
- now, we could improve this by passing rdev and slurp out required
 data from regulator structures, but obviously, as you pointed out, it wont
 be sufficient.
- In this solution, we will have existing regulator drivers supporting
additional data path. *but* that also means that existing regulator
drivers will need to be modified to handle multiple data path and "Just
Work" wont happen - so not really good other than screw up existing
regulator drivers with handling OMAP specific APIs in them.

option 2) make omap_pmic regulator use twl_regulator - regulator
chaining.
 - we already agreed that this is conceptually wrong[2](regulator
   talking to another regulator). So wont debate more here.
 - but here, you'd have omap_pmic regulator "using twl/existing
 regulators" to pick up data about slew, conversion information etc..

This series attempts to keep omap pmic delta simplified to just the
additional PMIC data, no replication of code or "OMAP specific
infection" of existing generic regulators.

Is there any other suggestions how to pick up the data from an existing
regulator and avoid few bytes of data replication?

[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/omap_twl.c#n142
[2] http://marc.info/?t=136513865200005&r=1&w=2
-- 
Regards,
Nishanth Menon


From mpa at pengutronix.de  Fri Jul  5 09:56:32 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Fri, 5 Jul 2013 15:56:32 +0200
Subject: [PATCH v9 01/10] ASoC: imx-pcm-dma: DT support
In-Reply-To: <51C7351D.9080004@tabi.org>
References: <1371734429-6081-1-git-send-email-mpa@pengutronix.de>
 <1371734429-6081-2-git-send-email-mpa@pengutronix.de>
 <51C7351D.9080004@tabi.org>
Message-ID: <20130705135632.GE16871@s25.your-server.de>

On Sun, Jun 23, 2013 at 12:49:17PM -0500, Timur Tabi wrote:
> Markus Pargmann wrote:
> > This patch removes the NO_DT flag. The pdev pointer may have a proper
> > of_node with the dmas property, so we can use it to request DMA
> > channels.
> >
> > Signed-off-by: Markus Pargmann<mpa at pengutronix.de>
> > Tested-by: Shawn Guo<shawn.guo at linaro.org>
> > ---
> 
> I won't have access to functioning hardware for another month or two, so I 
> can't test to see if this patchset breaks PowerPC, but at least it does 
> compile.  I'm a little worried that the DMA changes won't actually run on 
> PowerPC, but I can't test that now.

The DMA channels should end up to be NULL on PowerPC within the generic
dmaengine pcm, so it should fall back to NO_DT automatically.

> 
> So for the time being:
> 
> Acked-by: Timur Tabi <timur at tabi.org>
> 
> -- 
> Timur Tabi
> 

Thanks,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From broonie at kernel.org  Fri Jul  5 10:08:28 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 5 Jul 2013 15:08:28 +0100
Subject: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to
 control PMIC over VC/VP
In-Reply-To: <20130705135507.GA17439@kahuna>
References: <1371849949-12649-1-git-send-email-nm@ti.com>
 <1371849949-12649-2-git-send-email-nm@ti.com>
 <20130704154105.GD27646@sirena.org.uk>
 <20130705135507.GA17439@kahuna>
Message-ID: <20130705140828.GA27646@sirena.org.uk>

On Fri, Jul 05, 2013 at 08:55:07AM -0500, Nishanth Menon wrote:

Please write in paragraphs, an enormous wall of unbroken text isn't
helpful for legibility.

> On 16:41-20130704, Mark Brown wrote:

> > So, this still has the thing where all the data about the PMIC is
> > replicated (but now in this driver).  It should be possible to pull all
> > the above information except possibly the I2C timeout and perhaps the
> > I2C address (if there's a separate control interface) from the standard
> > regulator core data structures for the PMIC.  This would allow the
> > driver to Just Work with any PMIC without needing to add it in two
> > places.

> option 1) we just bypass get_voltage/set_voltage to point through to
> this function. result will be something similar to what we got here[1]

I don't really know what you mean when you say "bypass get_voltage/set_voltage
so it's kind of hard to comment...  the link you posted appears to be a
link to the code I'm reviewing so it's not terribly enlightening.

> Again, based on this discussion, it is wrong - and we already did implement
> the *wrong* way in OMAP and the new code is supposed to throw away the
> old code once all relevant platforms are converted to DT.
> - now, we could improve this by passing rdev and slurp out required
>  data from regulator structures, but obviously, as you pointed out, it wont
>  be sufficient.
> - In this solution, we will have existing regulator drivers supporting
> additional data path. *but* that also means that existing regulator
> drivers will need to be modified to handle multiple data path and "Just
> Work" wont happen - so not really good other than screw up existing
> regulator drivers with handling OMAP specific APIs in them.

What makes you think that the existing regulator drivers need to be
modified?  They already have all the data exported to the core (or
should do)...  the only thing that's missing is the timeouts and it's
not at all obvious why those need to be tuned per device.

> option 2) make omap_pmic regulator use twl_regulator - regulator
> chaining.

Again I don't know what this is.
-------------- 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/20130705/37daebf2/attachment.sig>

From andre.przywara at linaro.org  Fri Jul  5 10:08:55 2013
From: andre.przywara at linaro.org (Andre Przywara)
Date: Fri, 05 Jul 2013 16:08:55 +0200
Subject: [PATCH v2] ARM/KVM: save and restore generic timer registers
In-Reply-To: <51C2D528.90805@arm.com>
References: <1370963819-26165-1-git-send-email-andre.przywara@linaro.org>
 <51C2D528.90805@arm.com>
Message-ID: <51D6D377.70708@linaro.org>

Hi Marc,

 >> ...
>>
>> +int kvm_arm_num_timer_regs(void)
>> +{
>> +	return 3;
>> +}
>> +
>> +int kvm_arm_copy_timer_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
>> +{
>> +	if (put_user(KVM_REG_ARM_TIMER_CTL, uindices))
>> +		return -EFAULT;
>> +	uindices++;
>> +	if (put_user(KVM_REG_ARM_TIMER_CNT, uindices))
>> +		return -EFAULT;
>> +	uindices++;
>> +	if (put_user(KVM_REG_ARM_TIMER_CVAL, uindices))
>> +		return -EFAULT;
>
> So these macros are going to break arm64. Any chance you could introduce
> them at the same time on both platforms? The rest of the work can be
> delayed, but you shouldn't break arm64 (you'd expect me to say that,
> wouldn't you? ;-).

Is that just due to KVM_REG_ARM instead of KVM_REG_ARM64?
Or do you expect the numbering to be completely different since there is 
no mrc/mcr anymore (IIRC)?
Is put_user an issue here (should not, right?)
Is there already a document describing arch timer access on AARCH64?

If I am thinking in a totally wrong direction, please bear with me and 
feel free to point me to the right one ;-)
/me is now looking at getting a cross compiler to see what you mean...

> Also, I'd like to keep userspace access out of the timer code itself.
> Low level code shouldn't have to know about that. Can you create proper
> accessors instead, and move whole userspace access to coproc.c?

IIRC Christoffer recommended to keep this code completely out of 
coproc.c ;-) This also helps to keep coproc.c clean of ARCH_TIMER ifdefs 
in coproc.c (which I completely forgot in this version, btw, but that's 
already fixed).

>
>> +	return 0;
>> +}
>> +
>> +int kvm_arm_timer_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>> +{
>> +	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> +	void __user *uaddr = (void __user *)(long)reg->addr;
>> +	u64 val;
>> +	int ret;
>> +
>> +	ret = copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id));
>> +	if (ret != 0)
>> +		return ret;
>> +
>> +	switch (reg->id) {
>> +	case KVM_REG_ARM_TIMER_CTL:
>> +		timer->cntv_ctl = val;
>> +		break;
>> +	case KVM_REG_ARM_TIMER_CNT:
>> +		vcpu->kvm->arch.timer.cntvoff = kvm_phys_timer_read() - val;
>
> I just realized what bothers me here: You're computing cntvoff on a per
> vcpu basis, while this is a VM property. Which means that as you're
> restoring vcpus, you'll be changing cntvoff - sounds like a bad idea to me.
>
> The counter is really global. Do we have a way to handle VM-wide
> registers? I think Christoffer was trying to some a similar thing with
> the GIC...

So the consensus of this discussion was just to block writing when the 
VCPU is running, right? Or is there something else?

Regards,
Andre.

>
>> +		break;
>> +	case KVM_REG_ARM_TIMER_CVAL:
>> +		timer->cntv_cval = val;
>> +		break;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +int kvm_arm_timer_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>> +{
>> +	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> +	void __user *uaddr = (void __user *)(long)reg->addr;
>> +	u64 val;
>> +
>> +	switch (reg->id) {
>> +	case KVM_REG_ARM_TIMER_CTL:
>> +		val = timer->cntv_ctl;
>> +		break;
>> +	case KVM_REG_ARM_TIMER_CNT:
>> +		val = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
>> +		break;
>> +	case KVM_REG_ARM_TIMER_CVAL:
>> +		val = timer->cntv_cval;
>> +		break;
>> +	}
>> +	return copy_to_user(uaddr, &val, KVM_REG_SIZE(reg->id));
>> +}
>>
>>   static int kvm_timer_cpu_notify(struct notifier_block *self,
>>   				unsigned long action, void *cpu)
>> diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
>> index 152d036..a50ffb6 100644
>> --- a/arch/arm/kvm/guest.c
>> +++ b/arch/arm/kvm/guest.c
>> @@ -121,7 +121,8 @@ static unsigned long num_core_regs(void)
>>    */
>>   unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu)
>>   {
>> -	return num_core_regs() + kvm_arm_num_coproc_regs(vcpu);
>> +	return num_core_regs() + kvm_arm_num_coproc_regs(vcpu)
>> +		+ kvm_arm_num_timer_regs();
>>   }
>>
>>   /**
>> @@ -133,6 +134,7 @@ int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
>>   {
>>   	unsigned int i;
>>   	const u64 core_reg = KVM_REG_ARM | KVM_REG_SIZE_U32 | KVM_REG_ARM_CORE;
>> +	int ret;
>>
>>   	for (i = 0; i < sizeof(struct kvm_regs)/sizeof(u32); i++) {
>>   		if (put_user(core_reg | i, uindices))
>> @@ -140,9 +142,25 @@ int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
>>   		uindices++;
>>   	}
>>
>> +	ret = kvm_arm_copy_timer_indices(vcpu, uindices);
>> +	if (ret)
>> +		return ret;
>> +	uindices += kvm_arm_num_timer_regs();
>> +
>>   	return kvm_arm_copy_coproc_indices(vcpu, uindices);
>>   }
>>
>> +static bool is_timer_reg(u64 index)
>> +{
>> +	switch (index) {
>> +	case KVM_REG_ARM_TIMER_CTL:
>> +	case KVM_REG_ARM_TIMER_CNT:
>> +	case KVM_REG_ARM_TIMER_CVAL:
>> +		return true;
>> +	}
>> +	return false;
>> +}
>> +
>>   int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>>   {
>>   	/* We currently use nothing arch-specific in upper 32 bits */
>> @@ -153,6 +171,9 @@ int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>>   	if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_CORE)
>>   		return get_core_reg(vcpu, reg);
>>
>> +	if (is_timer_reg(reg->id))
>> +		return kvm_arm_timer_get_reg(vcpu, reg);
>> +
>>   	return kvm_arm_coproc_get_reg(vcpu, reg);
>>   }
>>
>> @@ -166,6 +187,9 @@ int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>>   	if ((reg->id & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_CORE)
>>   		return set_core_reg(vcpu, reg);
>>
>> +	if (is_timer_reg(reg->id))
>> +		return kvm_arm_timer_set_reg(vcpu, reg);
>> +
>>   	return kvm_arm_coproc_set_reg(vcpu, reg);
>>   }
>
> This is otherwise moving in the right direction.
>
> Thanks,
>
> 	M.
>



From trini at ti.com  Fri Jul  5 10:14:50 2013
From: trini at ti.com (Tom Rini)
Date: Fri, 5 Jul 2013 10:14:50 -0400
Subject: OMAP baseline test results for v3.10-rc6
In-Reply-To: <51D65E3C.1070202@ti.com>
References: <alpine.DEB.2.02.1306170521020.9909@utopia.booyaka.com>
 <20130625160243.GE22312@arwen.pp.htv.fi>
 <alpine.DEB.2.02.1306251746060.14373@utopia.booyaka.com>
 <51C9F0A8.1050607@ti.com> <87fvw6t136.fsf@linaro.org>
 <79CD15C6BA57404B839C016229A409A83ECC952D@DBDE04.ent.ti.com>
 <51CAEB33.5010101@ti.com>
 <alpine.DEB.2.02.1306261722520.6135@utopia.booyaka.com>
 <51CBBCD8.5030600@ti.com>
 <alpine.DEB.2.02.1306281844090.8767@utopia.booyaka.com>
 <alpine.DEB.2.02.1307010211580.3741@utopia.booyaka.com>
 <79CD15C6BA57404B839C016229A409A83ECCC435@DBDE04.ent.ti.com>
 <51D2E096.5040700@ti.com>
 <alpine.DEB.2.02.1307031944580.9618@utopia.booyaka.com>
 <alpine.DEB.2.02.1307041810410.6258@utopia.booyaka.com>
 <51D65E3C.1070202@ti.com>
Message-ID: <51D6D4DA.5070903@ti.com>

On 07/05/2013 01:48 AM, Rajendra Nayak wrote:
> On Thursday 04 July 2013 11:42 PM, Paul Walmsley wrote:
>> On Wed, 3 Jul 2013, Paul Walmsley wrote:
>>
>>> As far as Lokesh's patch goes: it doesn't make sense to me to remove a 
>>> file during 'make clean' that the build process doesn't create.  So while 
>>> I understand the motivation for the patch, and don't mind if upstream 
>>> takes it, I personally wouldn't care to ack it.
>>
>> Incidentally, if there's any patch that would improve the current 
>> situation with appended DTBs by going upstream, it would be a patch like 
>> Grant's "HACK" patch to add appended DTB building into the kernel build 
>> system.  Maybe folks can push to something similar to that one upstream?
> 
> Grant already made it clear when he posted that patch that neither that nor
> anything similar would be taken up mainline because the appended dtb was only
> meant for folks stuck with legacy bootloaders and have no way to upgrade.
> Anyone who uses a bootloader capable of passing the dtb should *not* use the
> appended dtb way.

The problem with that statement, and why I poked rmk the other week to
confirm, and posted a patch to enable appended dtb support in the
omap2plus_defconfig is that Grants statement conflicts with rmk's statement.

Now, my personal preference, with my U-Boot guy hat on, would be to say
that eval boards (those things that come with support and instructions
on un-bricking them, and really have to have bootloader source available
when applicable, or should be thrown back at the vendor, with extreme
prejudice) ought to require passed dtbs even if that means upgrading
bootloader.  Shipping product boards, well, you make do, and that
probably means passing a new bootloader to the locked bootloader to pass
in a separate dtb is going to be left to the folks who think that is
fun.  Everyone else will be happy just booting mainline(ish) kernels
with appended dtb.

-- 
Tom


From heiko at sntech.de  Fri Jul  5 10:23:33 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Fri, 5 Jul 2013 16:23:33 +0200
Subject: [PATCH v3 2/6] misc: sram: add ability to mark sram sections as
 reserved
In-Reply-To: <CAOMZO5AHX0UpeKQh+faPT=MfCf53eo=kXigtOZd7iuKrz-sFeA@mail.gmail.com>
References: <201307051440.19428.heiko@sntech.de>
 <201307051441.27605.heiko@sntech.de>
 <CAOMZO5AHX0UpeKQh+faPT=MfCf53eo=kXigtOZd7iuKrz-sFeA@mail.gmail.com>
Message-ID: <201307051623.33991.heiko@sntech.de>

Am Freitag, 5. Juli 2013, 14:55:40 schrieb Fabio Estevam:
> On Fri, Jul 5, 2013 at 9:41 AM, Heiko St?bner <heiko at sntech.de> wrote:
> > Some SoCs need parts of their sram for special purposes. So while being
> > part of the periphal, it should not be part of the genpool controlling
> > the sram.
> > 
> > Threfore add an option mmio-sram-reserved to keep arbitary portions of
> > the sram from being part of the pool.
> > 
> > Suggested-by: Rob Herring <robherring2 at gmail.com>
> > Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> > Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
> > ---
> > 
> >  Documentation/devicetree/bindings/misc/sram.txt |    8 +++
> >  drivers/misc/sram.c                             |   80
> >  +++++++++++++++++++++-- 2 files changed, 82 insertions(+), 6
> >  deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/misc/sram.txt
> > b/Documentation/devicetree/bindings/misc/sram.txt index 4d0a00e..eae080e
> > 100644
> > --- a/Documentation/devicetree/bindings/misc/sram.txt
> > +++ b/Documentation/devicetree/bindings/misc/sram.txt
> > 
> > @@ -8,9 +8,17 @@ Required properties:
> >  - reg : SRAM iomem address range
> > 
> > +Optional properties:
> > +
> > +- mmio-sram-reserved: ordered list of reserved chunks inside the sram
> > that +  should not become part of the genalloc pool.
> > +  Format is <base size>, <base size>, ...; with base being relative to
> > the +  reg property base.
> 
> Isn't it a typo?
> 
> I think you meant:
> Format is <base start>, <reserved size>,

no, the intended format is like

<0x0 0x100>, <0x1000 0x100>, ...

base + size, base + size, and so on


> 
> > +
> > 
> >  Example:
> >  
> >  sram: sram at 5c000000 {
> >  
> >         compatible = "mmio-sram";
> >         reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000
> >         */
> > 
> > +       mmio-sram-reserved = <0x0 0x100>; /* reserve
> > 0x5c000000-0x5c000100 */
>
> > 
> >  };



From p.zabel at pengutronix.de  Fri Jul  5 10:23:23 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 05 Jul 2013 16:23:23 +0200
Subject: [PATCH v3 1/6] misc: sram: fix error path in sram_probe
In-Reply-To: <201307051440.53993.heiko@sntech.de>
References: <201307051440.19428.heiko@sntech.de>
 <201307051440.53993.heiko@sntech.de>
Message-ID: <1373034203.3935.31.camel@pizza.hi.pengutronix.de>

Am Freitag, den 05.07.2013, 14:40 +0200 schrieb Heiko St?bner:
> The pool is created thru devm_gen_pool_create, so the call to
> gen_pool_destroy is not necessary.
> Instead the sram-clock must be turned off again if it exists.
> 
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>

Acked-by: Philipp Zabel <p.zabel at pengutronix.de>

> ---
>  drivers/misc/sram.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
> index d87cc91..afe66571 100644
> --- a/drivers/misc/sram.c
> +++ b/drivers/misc/sram.c
> @@ -68,7 +68,8 @@ static int sram_probe(struct platform_device *pdev)
>  	ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
>  				res->start, size, -1);
>  	if (ret < 0) {
> -		gen_pool_destroy(sram->pool);
> +		if (sram->clk)
> +			clk_disable_unprepare(sram->clk);
>  		return ret;
>  	}
>  

regards
Philipp



From p.zabel at pengutronix.de  Fri Jul  5 10:24:49 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 05 Jul 2013 16:24:49 +0200
Subject: [PATCH v3 2/6] misc: sram: add ability to mark sram sections as
 reserved
In-Reply-To: <201307051441.27605.heiko@sntech.de>
References: <201307051440.19428.heiko@sntech.de>
 <201307051441.27605.heiko@sntech.de>
Message-ID: <1373034289.3935.33.camel@pizza.hi.pengutronix.de>

Am Freitag, den 05.07.2013, 14:41 +0200 schrieb Heiko St?bner:
> Some SoCs need parts of their sram for special purposes. So while being part
> of the periphal, it should not be part of the genpool controlling the sram.
> 
> Threfore add an option mmio-sram-reserved to keep arbitary portions of the
> sram from being part of the pool.
> 
> Suggested-by: Rob Herring <robherring2 at gmail.com>
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>

Acked-by: Philipp Zabel <p.zabel at pengutronix.de>

> ---
>  Documentation/devicetree/bindings/misc/sram.txt |    8 +++
>  drivers/misc/sram.c                             |   80 +++++++++++++++++++++--
>  2 files changed, 82 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
> index 4d0a00e..eae080e 100644
> --- a/Documentation/devicetree/bindings/misc/sram.txt
> +++ b/Documentation/devicetree/bindings/misc/sram.txt
> @@ -8,9 +8,17 @@ Required properties:
>  
>  - reg : SRAM iomem address range
>  
> +Optional properties:
> +
> +- mmio-sram-reserved: ordered list of reserved chunks inside the sram that
> +  should not become part of the genalloc pool.
> +  Format is <base size>, <base size>, ...; with base being relative to the
> +  reg property base.
> +
>  Example:
>  
>  sram: sram at 5c000000 {
>  	compatible = "mmio-sram";
>  	reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
> +	mmio-sram-reserved = <0x0 0x100>; /* reserve 0x5c000000-0x5c000100 */
>  };
> diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
> index afe66571..9131e4a 100644
> --- a/drivers/misc/sram.c
> +++ b/drivers/misc/sram.c
> @@ -42,6 +42,13 @@ static int sram_probe(struct platform_device *pdev)
>  	struct sram_dev *sram;
>  	struct resource *res;
>  	unsigned long size;
> +	const __be32 *reserved_list = NULL;
> +	int reserved_size = 0;
> +	unsigned int cur_start = 0;
> +	unsigned int cur_size;
> +	unsigned int rstart;
> +	unsigned int rsize;
> +	int i;
>  	int ret;
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -65,12 +72,73 @@ static int sram_probe(struct platform_device *pdev)
>  	if (!sram->pool)
>  		return -ENOMEM;
>  
> -	ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
> -				res->start, size, -1);
> -	if (ret < 0) {
> -		if (sram->clk)
> -			clk_disable_unprepare(sram->clk);
> -		return ret;
> +	if (pdev->dev.of_node) {
> +		reserved_list = of_get_property(pdev->dev.of_node,
> +						"mmio-sram-reserved",
> +						&reserved_size);
> +		if (reserved_list) {
> +			reserved_size /= sizeof(*reserved_list);
> +			if (!reserved_size || reserved_size % 2) {
> +				dev_warn(&pdev->dev, "wrong number of arguments in mmio-sram-reserved\n");
> +				reserved_list = NULL;
> +			}
> +		}
> +	}
> +
> +	if (!reserved_list)
> +		reserved_size = 0;
> +
> +	for (i = 0; i < (reserved_size + 2); i += 2) {
> +		if (i < reserved_size) {
> +			/* get the next reserved block */
> +			rstart = be32_to_cpu(*reserved_list++);
> +			rsize = be32_to_cpu(*reserved_list++);
> +
> +			/* catch unsorted list entries */
> +			if (rstart < cur_start) {
> +				dev_err(&pdev->dev,
> +					"unsorted reserved list (0x%x before current 0x%x)\n",
> +					rstart, cur_start);
> +				if (sram->clk)
> +					clk_disable_unprepare(sram->clk);
> +				return -EINVAL;
> +			}
> +
> +			dev_dbg(&pdev->dev,
> +				"found reserved block 0x%x-0x%x\n",
> +				rstart, rstart + rsize);
> +		} else {
> +			/* the last chunk extends to the end of the region */
> +			rstart = size;
> +			rsize = 0;
> +		}
> +
> +		/* current start is in a reserved block */
> +		if (rstart <= cur_start) {
> +			cur_start = rstart + rsize;
> +			continue;
> +		}
> +
> +		/*
> +		 * allocate the space between the current starting
> +		 * address and the following reserved block, or the
> +		 * end of the region.
> +		 */
> +		cur_size = rstart - cur_start;
> +
> +		dev_dbg(&pdev->dev, "adding chunk 0x%x-0x%x\n",
> +			cur_start, cur_start + cur_size);
> +		ret = gen_pool_add_virt(sram->pool,
> +				(unsigned long)virt_base + cur_start,
> +				res->start + cur_start, cur_size, -1);
> +		if (ret < 0) {
> +			if (sram->clk)
> +				clk_disable_unprepare(sram->clk);
> +			return ret;
> +		}
> +
> +		/* next allocation after this reserved block */
> +		cur_start = rstart + rsize;
>  	}
>  
>  	platform_set_drvdata(pdev, sram);




From jason at lakedaemon.net  Fri Jul  5 10:29:51 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 5 Jul 2013 10:29:51 -0400
Subject: [PATCHv1] arm: armada: Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <878v1mgh4x.fsf@natisbad.org>
References: <878v1mgh4x.fsf@natisbad.org>
Message-ID: <20130705142951.GE2569@titan.lakedaemon.net>

On Thu, Jul 04, 2013 at 11:16:46PM +0200, Arnaud Ebalard wrote:
> 
> All hardware parts of the (Armada 370 based) NETGEAR ReadyNAS 102 are
> supported by mainline kernel (USB 3.0 rear ports, USB 2.0 front port,
> Gigabit controller and PHY, serial port, leds, buttons, SATA ports,
> G762 fan controller) except for:
> 
>  - the Intersil ISL12057 I2C RTC Chip,
>  - the Armada NAND controller.
> 
> Support for both of those is currently work in progress and does not
> prevent boot.
> 
> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
> ---
> Hi Jason and Andrew,
> 
> As requested
> 
>  - this version is tested against current head of linus tree (+ I2C
>    fixes for a race condition; for details, see message #94 of
>    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622325).
>  - nand layout entry and ISL12057 entry have been removed until support
>    is available in mainline kernel for eahc of those
>  - clock, gpio led and keys have been made siblings of soc, memory and
>    chosen (reported by Sebastian).
> 
> Is it still acceptable for current merge window or am I too late?

Unfortunately, it's too late for v3.11.  The arm-soc cutoff is typically
-rc6 or so.  Which usually means we need to see it on lakml by -rc5.
So, you're ahead of schedule for v3.12 :-P

However, with any luck, maybe Ezequiel will have something ready for the
nand driver in time as well...

thx,

Jason.


From js at sig21.net  Fri Jul  5 10:34:52 2013
From: js at sig21.net (Johannes Stezenbach)
Date: Fri, 5 Jul 2013 16:34:52 +0200
Subject: SPI: DUAL/QUAD support
In-Reply-To: <CAHSAbzP1-RVot+hhtY_DcBK=u5n2234eb9WOKLESwvUNax7+pA@mail.gmail.com>
References: <OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>
 <CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>
 <51D67851.8020402@ti.com>
 <CAHSAbzNvMo_oeaqtzO8-xDm-L-f8wVccVqfuVqbR=OwqWJhVwg@mail.gmail.com>
 <51D689F3.3070605@ti.com>
 <CAHSAbzM1PGoMXFNOmB7guDsVWYnRoRy89-bufHYpPz5+odnd8w@mail.gmail.com>
 <51D68D14.7090606@ti.com>
 <CAHSAbzMfvfdDtTh=3zeBni4fNMAHEMdTJLJU-Oc13HJUqCUj0A@mail.gmail.com>
 <51D69197.7060802@ti.com>
 <CAHSAbzP1-RVot+hhtY_DcBK=u5n2234eb9WOKLESwvUNax7+pA@mail.gmail.com>
Message-ID: <20130705143452.GA7738@sig21.net>

On Fri, Jul 05, 2013 at 06:24:40PM +0800, yuhang wang wrote:
> 
> 2 Questions here:
> 1.In m25p80.c probe, the kmalloc below I feel very strange.
>       flash->command = kmalloc(MAX_CMD_SIZE + (flash->fast_read ? 1 : 0),
>                                       GFP_KERNEL);
> 
>  (flash->fast_read ? 1 : 0) must be 0! So why do it like that.

Maybe just increase MAX_CMD_SIZE by 1 unconditonally?
Yeah, looks like a bug in m25p80.c, flash->fast_read
is initialized too late.

> +#define        OPCODE_DOR              0x3B    /* Dual Output Read */
> +#define        OPCODE_QOR              0x6B    /* Quad Output Read */
> +#define        OPCODE_QPP              0x32    /* Quad Page Programming */
> +#define        OPCODE_QEN              0x02 /* Quad Mode Enable Flag */

Which flash chip are these for?  The OPCODE_DOR and OPCODE_QOR
match MX25L25635E, but OPCODE_QPP not (Macronix uses 0x38).



> +#ifdef CONFIG_M25PXX_USE_FAST_READ
> +#define OPCODE_READ    OPCODE_FAST_READ
> +#define FAST_READ_DUMMY_BYTE 1
> +#else
> +#define OPCODE_READ    OPCODE_NORM_READ
> +#define FAST_READ_DUMMY_BYTE 0
> +#endif

this doesn't work with the flash->fast_read setting from DT

BTW, if we add "bitwidths" to spi_board_info, wouldn't
it make sense to also add "use_fast_read" and remove the
CONFIG_M25PXX_USE_FAST_READ option?

> +/*
> + * Write configuration register 2 byte
> + * Returns negative if error occurred.
> + */
> +static int write_cr(struct m25p *flash, u16 val)
> +{
> +       flash->command[0] = OPCODE_WRSR;
> +       flash->command[1] = val >> 8;
> +       flash->command[2] = val;
> +
> +       return spi_write(flash->spi, flash->command, 3);
> +}

> +       if ((flash->spi->rx_bitwidth == SPI_BITWIDTH_QUAD) ||
> +               (flash->spi->tx_bitwidth == SPI_BITWIDTH_QUAD)) {
> +               write_enable(flash);
> +               write_cr(flash, OPCODE_QEN);
> +       }

MX25L25635E doesn't have a cr, instead a bit needs to be set in the sr

Maybe we need to add some fields to m25p_ids[] to manage variation
between flash devices.


Thanks,
Johannes


From marc.zyngier at arm.com  Fri Jul  5 10:44:28 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 05 Jul 2013 15:44:28 +0100
Subject: [PATCH v2] ARM/KVM: save and restore generic timer registers
In-Reply-To: <51D6D377.70708@linaro.org>
References: <1370963819-26165-1-git-send-email-andre.przywara@linaro.org>
 <51C2D528.90805@arm.com> <51D6D377.70708@linaro.org>
Message-ID: <51D6DBCC.9040807@arm.com>

On 05/07/13 15:08, Andre Przywara wrote:
> Hi Marc,
> 
>  >> ...
>>>
>>> +int kvm_arm_num_timer_regs(void)
>>> +{
>>> +	return 3;
>>> +}
>>> +
>>> +int kvm_arm_copy_timer_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
>>> +{
>>> +	if (put_user(KVM_REG_ARM_TIMER_CTL, uindices))
>>> +		return -EFAULT;
>>> +	uindices++;
>>> +	if (put_user(KVM_REG_ARM_TIMER_CNT, uindices))
>>> +		return -EFAULT;
>>> +	uindices++;
>>> +	if (put_user(KVM_REG_ARM_TIMER_CVAL, uindices))
>>> +		return -EFAULT;
>>
>> So these macros are going to break arm64. Any chance you could introduce
>> them at the same time on both platforms? The rest of the work can be
>> delayed, but you shouldn't break arm64 (you'd expect me to say that,
>> wouldn't you? ;-).
> 
> Is that just due to KVM_REG_ARM instead of KVM_REG_ARM64?
> Or do you expect the numbering to be completely different since there is 
> no mrc/mcr anymore (IIRC)?

Both. The encoding is different (32bit is encoded CRn/CRm/Op1/Op2, and
64bit is Op0/Op1/CRn/CRm/Op2), and the KVM_REG_ARM64 is different too.

> Is put_user an issue here (should not, right?)

No, except for the reason outlined below.

> Is there already a document describing arch timer access on AARCH64?

No, but it is strikingly similar to the AArch32. Have a look at
arch/arm64/include/asm/arch_timer.h and arch/arm64/kvm/hyp.S for details.

> If I am thinking in a totally wrong direction, please bear with me and 
> feel free to point me to the right one ;-)
> /me is now looking at getting a cross compiler to see what you mean...

That'd be a good thing! ;-)

>> Also, I'd like to keep userspace access out of the timer code itself.
>> Low level code shouldn't have to know about that. Can you create proper
>> accessors instead, and move whole userspace access to coproc.c?
> 
> IIRC Christoffer recommended to keep this code completely out of 
> coproc.c ;-) This also helps to keep coproc.c clean of ARCH_TIMER ifdefs 
> in coproc.c (which I completely forgot in this version, btw, but that's 
> already fixed).

I thought we agreed on moving the userspace access out of the timer
code. In a reply to the email you just quoted, Christoffer says:
"I'm fine with this, coproc.c or guest.c - either way.".

The man has spoken! ;-)

>>
>>> +	return 0;
>>> +}
>>> +
>>> +int kvm_arm_timer_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
>>> +{
>>> +	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>>> +	void __user *uaddr = (void __user *)(long)reg->addr;
>>> +	u64 val;
>>> +	int ret;
>>> +
>>> +	ret = copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id));
>>> +	if (ret != 0)
>>> +		return ret;
>>> +
>>> +	switch (reg->id) {
>>> +	case KVM_REG_ARM_TIMER_CTL:
>>> +		timer->cntv_ctl = val;
>>> +		break;
>>> +	case KVM_REG_ARM_TIMER_CNT:
>>> +		vcpu->kvm->arch.timer.cntvoff = kvm_phys_timer_read() - val;
>>
>> I just realized what bothers me here: You're computing cntvoff on a per
>> vcpu basis, while this is a VM property. Which means that as you're
>> restoring vcpus, you'll be changing cntvoff - sounds like a bad idea to me.
>>
>> The counter is really global. Do we have a way to handle VM-wide
>> registers? I think Christoffer was trying to some a similar thing with
>> the GIC...
> 
> So the consensus of this discussion was just to block writing when the 
> VCPU is running, right? Or is there something else?

Yup. No update while vcpus are running.

	M.
-- 
Jazz is not dead. It just smells funny...



From nm at ti.com  Fri Jul  5 10:50:34 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 5 Jul 2013 09:50:34 -0500
Subject: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control
 PMIC over VC/VP
In-Reply-To: <20130705140828.GA27646@sirena.org.uk>
References: <1371849949-12649-1-git-send-email-nm@ti.com>
 <1371849949-12649-2-git-send-email-nm@ti.com>
 <20130704154105.GD27646@sirena.org.uk> <20130705135507.GA17439@kahuna>
 <20130705140828.GA27646@sirena.org.uk>
Message-ID: <51D6DD3A.1030002@ti.com>

On 07/05/2013 09:08 AM, Mark Brown wrote:
> On Fri, Jul 05, 2013 at 08:55:07AM -0500, Nishanth Menon wrote:
>
> Please write in paragraphs, an enormous wall of unbroken text isn't
> helpful for legibility.

Apologies on the same. Will try to do better.

>
>> On 16:41-20130704, Mark Brown wrote:
>
>>> So, this still has the thing where all the data about the PMIC is
>>> replicated (but now in this driver).  It should be possible to pull all
>>> the above information except possibly the I2C timeout and perhaps the
>>> I2C address (if there's a separate control interface) from the standard
>>> regulator core data structures for the PMIC.  This would allow the
>>> driver to Just Work with any PMIC without needing to add it in two
>>> places.
>
>> option 1) we just bypass get_voltage/set_voltage to point through to
>> this function. result will be something similar to what we got here[1]
>
> I don't really know what you mean when you say "bypass get_voltage/set_voltage
> so it's kind of hard to comment...  the link you posted appears to be a
> link to the code I'm reviewing so it's not terribly enlightening.

:) it is similar, yes. by bypass get/set_voltage, I mean something like [1]

>
>> Again, based on this discussion, it is wrong - and we already did implement
>> the *wrong* way in OMAP and the new code is supposed to throw away the
>> old code once all relevant platforms are converted to DT.
>> - now, we could improve this by passing rdev and slurp out required
>>   data from regulator structures, but obviously, as you pointed out, it wont
>>   be sufficient.
>> - In this solution, we will have existing regulator drivers supporting
>> additional data path. *but* that also means that existing regulator
>> drivers will need to be modified to handle multiple data path and "Just
>> Work" wont happen - so not really good other than screw up existing
>> regulator drivers with handling OMAP specific APIs in them.
>
> What makes you think that the existing regulator drivers need to be
> modified?


data path difference - Almost all standard regulators use i2c (standard 
i2c APIs) for every other SMPS/LDO except for the ones controlled by 
OMAP custom i2c path(vc/vp), the set_voltage/get_voltage needs a 
different implementation when it comes to using the vc/vp path.

 > They already have all the data exported to the core (or
 > should do)...

I see that twl-regulator does not indeed do it, but, assuming the 
regulators have all the data exported to the core, the data is hidden in 
struct regulator_desc which is private to the device and driver. lets go 
through these:

 > +static const struct omap_pmic_info omap_twl4030_vdd1 = {
 > +	.slave_addr = 0x12,
Not readily exposed, but we can solve that using reg=<0x12>; in dts - 
this might not be duplication as the register address will be unique for 
the bus.

 > +	.voltage_reg_addr = 0x00,
desc->vsel_reg maps fine

 > +	.cmd_reg_addr = 0x00,
command register is used for sending low power state commands - which is 
not the same as voltage register or vsel_reg as used in depicted in 
regulator_desc.	

 > +	.i2c_timeout_us = 200,
yep, does not match up.

 > +	.slew_rate_uV = 4000,
desc->ramp_delay maps fine

 > +	.step_size_uV = 12500,
desc->uV_step maps fine.

 > +	.min_uV = 600000,
desc->min_uV maps fine.

 > +	.max_uV = 1450000,
can be used with constraints, but most regulator drivers seem to store 
this internally.

 > +	.voltage_selector_offset = 0,
 > +	.voltage_selector_mask = 0x7F,
 > +	.voltage_selector_setbits = 0x0,
 > +	.voltage_selector_zero = false,
to an extent we can map these to vsel_mask, linear_min_sel etc. (again 
assuming the regulator driver has populated it - most that implement 
custom set_voltage, get_voltage do not do that.

Now, How do you suggest I pick up this data in omap_pmic regulator?
linux/regulator/consumer.h does not seem appropriate omap_pmic is not 
really a consumer of the regulator and further all the detailed data is 
not exposed either.

Other option is to make rdev available to omap_pmic regulator - which 
again implies change in existing regulator driver?


> the only thing that's missing is the timeouts and it's
> not at all obvious why those need to be tuned per device.

OMAP VC hardware has no idea about how long to wait before giving up on 
an ongoing i2c transaction. This may depend on PMIC and what it does 
before acking on i2c.

>
>> option 2) make omap_pmic regulator use twl_regulator - regulator
>> chaining.
>
> Again I don't know what this is.
Lets ignore this for the moment.


[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=63bfff4e20211b464cbea6e79e5fd36df227c154
-- 
Regards,
Nishanth Menon


From Dave.Martin at arm.com  Fri Jul  5 10:51:01 2013
From: Dave.Martin at arm.com (Dave P Martin)
Date: Fri, 5 Jul 2013 15:51:01 +0100
Subject: scripts/kallsyms: Avoid ARM veneer symbols
In-Reply-To: <201307031803.04501.arnd@arndb.de>
References: <2983817.Xe2505Drlj@wuerfel> <20130625150941.GF2327@linaro.org>
 <201307031803.04501.arnd@arndb.de>
Message-ID: <20130705145100.GE2932@localhost.localdomain>

On Wed, Jul 03, 2013 at 06:03:04PM +0200, Arnd Bergmann wrote:
> On Tuesday 25 June 2013, Dave Martin wrote:
> > On Mon, Jun 24, 2013 at 04:01:43PM +0200, Arnd Bergmann wrote:
> > > When building ARM kernels that exceed a certain size, the linker
> > > will add "veneers" that allow long branches. Unfortunately,
> > > using a longer kallsyms section may lead to the extra veneers
> > > being needed, which leads to inconsistent kallsyms data with the
> > > message
> > > 
> > > Inconsistent kallsyms data
> > > Try make KALLSYMS_EXTRA_PASS=1 as a workaround
> > > 
> > > In some case, not just one but up to three extra passes were
> > > needed before getting to a state that needed no extra veneers.
> > 
> > Do you understand why this was happening?  It sounds like there
> > must have been branches crossing from one side of the kallsyms
> > data to the other, triggering veneer insertion any time the
> > kallsyms data grows.
> > 
> > Branches between .{init,exit}.text and .text (crossing .rodata) seem the
> > likeliest culprits, but that's guesswork on my part.
> 
> kallsyms is part of rodata, which is between .text and .init.text.
> I understand this is intentional, and we already use two passes
> of kallsyms to make sure the size is right. However the assumption
> is that only the data of the kallsyms table changes between runs,
> not the size of it.

I guess sticking the init stuff at the end makes it tidier to
discard without leaving a gap in the middle of the kernel image.
There might be other reasons.

> > If that's whats going on, multiple kallsyms passes is actually a correct
> > approach here: I think they should terminate after a number of steps
> > roughly proportional to log(number of branches across .rodata). We
> > could come up with a heuristic which allows us to choose the right
> > limit with a high degree of reliability, since branch density in
> > compiled C code is likely to be roughly.
> 
> It also seems to be a part of the design to do exactly two passes
> and treat anything beyond that as bugs, doing it the way you

Sure -- I was that making the point the implementation is based on
an assumption that isn't true here.

> suggest would significantly increase the build time since the
> kallsyms+linker stage cannot be done in parallel or sped up
> using ccache.
> 
> > But including the veneer symbols in kallsyms is arguably not all
> > that useful.
> > 
> > The main potential effect is that profiling might occasionally
> > sample the PC as being in a completely bogus function which it
> > never passed through at all, because of the way kallsyms tracks
> > only symbol locations and not sizes (if I remember right) --
> > so a veneer will actually get accounted against some arbitrary
> > adjacent function.
> > 
> > I don't know how much this matters.
> 
> Interesting point. No idea how often that happens. All the veneers
> for one section are in one place though, so we could in theory
> add a kallsyms entry for that section as long as can identify
> it.

We could collapse any contiguous sequence of __veneer_* symbols down
to a single symbol to mark those holes.

However, many kallsyms passes could still be needed: each pass might add
extra veneer blocks, unless the size of kallsyms data is identical to
that in the previous pass.  The expected convergence rate is faster,
though.

> > > The easiest solution is to skip veneers in kallsyms in the
> > > same way we already skip a couple of other symbols.

Your suggestion of omitting the symbols completely seems to be the only
way to ensure convergence in 2 passes, so far as I can see.


Adding size information to every entry in kallsyms would make it possible
to identify the "holes" without potentially requiring many kallsyms passes,
but it would bloat the table.  The extra info would be interesting only
for a tiny subset of the symbols.  I expect people aren't going to like
that much.

So I guess your original suggestion may be the best thing to do for now,
after all...

There is no proper reserved symbol namespace for linker-generated symbols,
so a real symbol could have the name __*_veneer, at which point things
start to get really confusing.  But hopefully that won't happen much.
I don't see any such symbol right now, and hopefully nobody will be so
silly as to add one...

If we eventually need to fix the bogus symbol resolution problem, I can't
see an alternative to adding size info to every symbol.  But we should
leave that for now.  It doesn't sound like a serious problem.

> > The other symbols are not stripped for the purpose of making
> > kallsyms terminate quickly.  The mapping symbols are rather
> > different: masses of symbols with duplicate names which are
> > not very interesting for most people.
> 
> Right.
> 
> > > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > > ---
> > > diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
> > > index 487ac6f..53ec0bb 100644
> > > --- a/scripts/kallsyms.c
> > > +++ b/scripts/kallsyms.c
> > > @@ -69,14 +69,32 @@ static void usage(void)
> > >  	exit(1);
> > >  }
> > >  
> > > -/*
> > > - * This ignores the intensely annoying "mapping symbols" found
> > > - * in ARM ELF files: $a, $t and $d.
> > > - */
> > >  static inline int is_arm_mapping_symbol(const char *str)
> > 
> > The function's name is now wrong.  Should it be renamed or split up?
> 
> Sure I can rename it. Any suggestions?

Maybe just something more generic like is_arm_special_symbol()?

Cheers
---Dave


From festevam at gmail.com  Fri Jul  5 10:55:19 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 5 Jul 2013 11:55:19 -0300
Subject: [PATCH v3 6/6] ARM: rockchip: add smp bringup code
In-Reply-To: <201307051443.27172.heiko@sntech.de>
References: <201307051440.19428.heiko@sntech.de>
 <201307051443.27172.heiko@sntech.de>
Message-ID: <CAOMZO5Af=iSZMLEQOrxGfMCSTbfs2K=7QoCvEpkHNMna1V0FfQ@mail.gmail.com>

On Fri, Jul 5, 2013 at 9:43 AM, Heiko St?bner <heiko at sntech.de> wrote:

> --- /dev/null
> +++ b/arch/arm/mach-rockchip/headsmp.S
> @@ -0,0 +1,32 @@
> +/*
> + * Copyright (c) 2013 MundoReader S.L.
> + * Author: Heiko Stuebner <heiko at sntech.de>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This 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.
> + */
> +#include <linux/linkage.h>
> +#include <linux/init.h>
> +
> +       __CPUINIT

This should go away after this commit:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next-history.git/commit/arch/arm/common/mcpm_platsmp.c?id=c508abae89c3fa861c806ec00366d3b2f8d394cb


From Dave.Martin at arm.com  Fri Jul  5 11:10:02 2013
From: Dave.Martin at arm.com (Dave P Martin)
Date: Fri, 5 Jul 2013 16:10:02 +0100
Subject: [PATCH] ARM: move body of head-common.S back to text section
In-Reply-To: <20130704002235.GL22702@windriver.com>
References: <1372805629-18382-1-git-send-email-swarren@wwwdotorg.org>
 <20130702232259.GH11625@codeaurora.org>
 <51D39004.9000907@wwwdotorg.org>
 <20130703051907.GA22702@windriver.com>
 <20130703100044.GG24642@n2100.arm.linux.org.uk>
 <20130703153012.GK22702@windriver.com>
 <20130703172001.GH24642@n2100.arm.linux.org.uk>
 <20130704002235.GL22702@windriver.com>
Message-ID: <20130705151001.GF2932@localhost.localdomain>

On Wed, Jul 03, 2013 at 08:22:35PM -0400, Paul Gortmaker wrote:
> [Re: [PATCH] ARM: move body of head-common.S back to text section] On 03/07/2013 (Wed 18:20) Russell King - ARM Linux wrote:
> 
> > On Wed, Jul 03, 2013 at 11:30:12AM -0400, Paul Gortmaker wrote:
> > > [Re: [PATCH] ARM: move body of head-common.S back to text section] On 03/07/2013 (Wed 11:00) Russell King - ARM Linux wrote:
> > > 
> > > > On Wed, Jul 03, 2013 at 01:19:07AM -0400, Paul Gortmaker wrote:
> > > > > As an aside, I'm now thinking any __INIT that implicitly rely on EOF for
> > > > > closure are nasty traps waiting to happen and it might be worthwhile to
> > > > > audit and explicitly __FINIT them before someone appends to the file...
> > > > 
> > > > That hides a different kind of bug though - I hate __FINIT for exactly
> > > > that reason.  Consider this:
> > > 
> > > Agreed - perhaps masking that it is a ".previous" just hides the fact
> > > that it is more like a pop operation vs. an on/off operation, or per
> > > function as we have in C.
> > 
> > I read the info pages, because I thought it was a pop operation too.
> > I was concerned that .section didn't push the previous section onto the
> > stack.
> > 
> > However, .popsection is the pseudio-op which pops.  .previous just toggles
> > the current section with the section immediately before it.
> > 
> > So:
> > 
> > 	.text
> > 	.data
> > 	.previous
> > 	/* this is .text */
> > 	.previous
> > 	/* this is .data */
> > 	.previous
> > 	/* this is .text */
> > 	.previous
> > 	/* this is .data */
> 
> Cool -- I bet we weren't the only ones thinking it was a pop.  Thanks.
> 
> Does that make __FINIT less evil than we previously assumed?  I think
> your example was the following pseudo-patch:
> 
> 
> 	.text
> 	<some text>
> +	.data
> + 	<some data>
> 	__INIT
> 	<big hunk of init>
> 	__FINIT
> 	/* this below used to be text */
> 	<more stuff that was originally meant for text>
> 
> Even if it is a toggle (vs. pop), the end text will now become data,
> so the no-op __FINIT with an explicit section called out just below
> it may still be the most unambiguous way to indicate what is going on.
> 
> > 
> > > That seems reasonable to me.  I can't think of any self auditing that is
> > > reasonably simple to implement.  One downside of __FINIT as a no-op vs.
> > > what it is today, is that a dangling __FINIT in a file with no other
> > > previous sections will emit a warning.  But that is a small low value
> > > corner case I think.
> > 
> > That warning from __FINIT will only happen if there has been no section
> > or .text or .data statement in the file at all.  As soon as you have any
> > statement setting any kind of section, .previous doesn't warn.
> > 
> > So:
> > 
> > 	.text
> > 	...
> > 	__FINIT
> > 
> > produces no warning.o
> 
> Yep -- we are both saying the same thing here - hence why I called it a
> small low value corner case.

Note that .previous has another important gotcha.  Consider:

	__INIT
	/* now in .text.init */
	ALT_UP(...)
	/* now in .text.init */
	__FINIT

	/* now in .alt.smp.text! */


.previous (or macros containing a dangling .previous) shouldn't be used
unless you're absolutely certain what the previous section was.

In general:

	label:
		<stuff>

		.previous

restores to the section which was current at label, only if there are
no section directives in <stuff>, nor anything which could contain a
section directive after macro expansion.

The same goes for the hidden, dangling .previous embedded in __FINIT
and friends.

Cheers
---Dave


From afzal at ti.com  Fri Jul  5 11:13:17 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Fri, 5 Jul 2013 20:43:17 +0530
Subject: [PATCH 2/2] ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space
In-Reply-To: <4bb04ee7bcb8ca73d5fc43049ba029471b9cdda3.1373036932.git.afzal@ti.com>
References: <4bb04ee7bcb8ca73d5fc43049ba029471b9cdda3.1373036932.git.afzal@ti.com>
Message-ID: <84d9a3ae9ab7a47924eb54934dcad91339543d63.1373036932.git.afzal@ti.com>

Register target address to be used for cpgmac is the second device
address space. By default, hwmod picks first address space (0th index)
for register target.

With removal of address space from hwmod and using DT instead, cpgmac
is getting wrong address space for register target.

Fix it by indicating the address space to be used for register target.

Signed-off-by: Afzal Mohammed <afzal at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 28bbd56..7a9b492 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -562,6 +562,7 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
 	.clkdm_name	= "cpsw_125mhz_clkdm",
 	.flags		= (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
 	.main_clk	= "cpsw_125mhz_gclk",
+	.mpu_rt_idx	= 1,
 	.prcm		= {
 		.omap4	= {
 			.clkctrl_offs	= AM33XX_CM_PER_CPGMAC0_CLKCTRL_OFFSET,
-- 
1.8.3.1



From afzal at ti.com  Fri Jul  5 11:13:00 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Fri, 5 Jul 2013 20:43:00 +0530
Subject: [PATCH 1/2] ARM: OMAP2+: hwmod: rt address space index for DT
Message-ID: <4bb04ee7bcb8ca73d5fc43049ba029471b9cdda3.1373036932.git.afzal@ti.com>

Address space is being removed from hwmod database and DT information
in <reg> property is being used. Currently the 0th index of device
address space is used to map for register target address. This is not
always true, eg. cpgmac has it's sysconfig in second address space.

Handle it by specifying index of device address space to be used for
register target. As default value of this field would be zero with
static initialization, existing behaviour of using first address space
for register target while using DT would be kept as such.

Signed-off-by: Afzal Mohammed <afzal at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7341eff..7f4db12 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2386,7 +2386,7 @@ static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data)
 
 		np = of_dev_hwmod_lookup(of_find_node_by_name(NULL, "ocp"), oh);
 		if (np)
-			va_start = of_iomap(np, 0);
+			va_start = of_iomap(np, oh->mpu_rt_idx);
 	} else {
 		va_start = ioremap(mem->pa_start, mem->pa_end - mem->pa_start);
 	}
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index aab33fd..29f7687 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -568,6 +568,7 @@ struct omap_hwmod_link {
  * @voltdm: pointer to voltage domain (filled in at runtime)
  * @dev_attr: arbitrary device attributes that can be passed to the driver
  * @_sysc_cache: internal-use hwmod flags
+ * @mpu_rt_idx: index of device address space for register target (for DT boot)
  * @_mpu_rt_va: cached register target start address (internal use)
  * @_mpu_port: cached MPU register target slave (internal use)
  * @opt_clks_cnt: number of @opt_clks
@@ -612,6 +613,7 @@ struct omap_hwmod {
 	struct list_head		slave_ports; /* connect to *_TA */
 	void				*dev_attr;
 	u32				_sysc_cache;
+	int				mpu_rt_idx;
 	void __iomem			*_mpu_rt_va;
 	spinlock_t			_lock;
 	struct list_head		node;
-- 
1.8.3.1



From richard.genoud at gmail.com  Fri Jul  5 11:16:03 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Fri, 5 Jul 2013 17:16:03 +0200
Subject: [RFC PATCH 02/13] misc: atmel_ssc: keep the count of pdev->id
In-Reply-To: <51D24318.40908@atmel.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-3-git-send-email-richard.genoud@gmail.com>
 <51D24318.40908@atmel.com>
Message-ID: <CACQ1gAj9bY9Tw2-Ps7-Bm2-gS0PY=hocRPvXCQhmcQ9-sKg1kQ@mail.gmail.com>

2013/7/2 Bo Shen <voice.shen at atmel.com>:
> Hi Richard,
>
>
> On 7/1/2013 16:39, Richard Genoud wrote:
>>
>> With device tree, pdev->id is always -1, so we introduce a local
>> counter.
>>
>> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
>> ---
>>   drivers/misc/atmel-ssc.c |    7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
>> index 3afbd82..d1ec5ab 100644
>> --- a/drivers/misc/atmel-ssc.c
>> +++ b/drivers/misc/atmel-ssc.c
>> @@ -173,6 +173,12 @@ out:
>>         return err;
>>   }
>>
>> +/* counter of ssc devive instances.
>> + * With device tree pdev->id is always -1, so we have to keep the
>> + * count ourselves
>> + */
>> +static int ssc_device_id;
>
>
> Do we really need this? If Yes, would it better to get from device through
> of_alias_get_id?

you're right, it seems that we don't need that anymore.

thanks !

Richard.


From richard.genoud at gmail.com  Fri Jul  5 11:16:50 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Fri, 5 Jul 2013 17:16:50 +0200
Subject: [RFC PATCH 03/13] ARM: at91: DTS: sam9x5: add clock for SSC DT
 entry
In-Reply-To: <51D24366.5000101@atmel.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-4-git-send-email-richard.genoud@gmail.com>
 <51D24366.5000101@atmel.com>
Message-ID: <CACQ1gAjM+676e9srFOkbu2sBcYC25jszVuH0b7FvMm1DFc-sEQ@mail.gmail.com>

2013/7/2 Bo Shen <voice.shen at atmel.com>:
> Hi Richard,
>
>
> On 7/1/2013 16:39, Richard Genoud wrote:
>>
>> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
>> ---
>>   arch/arm/mach-at91/at91sam9x5.c |    1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/mach-at91/at91sam9x5.c
>> b/arch/arm/mach-at91/at91sam9x5.c
>> index 2abee66..191eb4b 100644
>> --- a/arch/arm/mach-at91/at91sam9x5.c
>> +++ b/arch/arm/mach-at91/at91sam9x5.c
>> @@ -233,6 +233,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
>>         CLKDEV_CON_DEV_ID("mci_clk", "f000c000.mmc", &mmc1_clk),
>>         CLKDEV_CON_DEV_ID("dma_clk", "ffffec00.dma-controller",
>> &dma0_clk),
>>         CLKDEV_CON_DEV_ID("dma_clk", "ffffee00.dma-controller",
>> &dma1_clk),
>> +       CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", &ssc_clk),
>
>
> Actually, we don't use this anymore. Am I right?
correct !
I'll drop it.

Thanks,
Richard.


From richard.genoud at gmail.com  Fri Jul  5 11:15:05 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Fri, 5 Jul 2013 17:15:05 +0200
Subject: [RFC PATCH 08/13] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <51D2472B.2010407@atmel.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-9-git-send-email-richard.genoud@gmail.com>
 <51D2472B.2010407@atmel.com>
Message-ID: <CACQ1gAji8KkjXee8o=9jt8O38611LBJ95yXimxbfn1qLaLOcnA@mail.gmail.com>

2013/7/2 Bo Shen <voice.shen at atmel.com>:
> Hi Richard,
>
>   Will move this patch before 5, 6, 7?
yes, you're right.

>
>
> On 7/1/2013 16:39, Richard Genoud wrote:
>>
>> From: Nicolas Ferre <nicolas.ferre at atmel.com>
>>
>> Description of the Asoc machine driver for an at91sam9x5 based board
>> with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
>> master on the SSC/I2S interface. Its connections are a headphone jack
>> and an Line input jack.
>>
>> [Richard: this is based on an old patch from Nicolas that I forward
>> ported and reworked to use only device tree]
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
>> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
>> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
>> ---
>>   sound/soc/atmel/Kconfig         |   12 ++
>>   sound/soc/atmel/Makefile        |    2 +
>>   sound/soc/atmel/sam9x5_wm8731.c |  232
>> +++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 246 insertions(+)
>>   create mode 100644 sound/soc/atmel/sam9x5_wm8731.c
>>
>> diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
>> index 3fdd87f..f24d601 100644
>> --- a/sound/soc/atmel/Kconfig
>> +++ b/sound/soc/atmel/Kconfig
>> @@ -13,6 +13,7 @@ config SND_ATMEL_SOC_PDC
>>   config SND_ATMEL_SOC_DMA
>>         tristate
>>         depends on SND_ATMEL_SOC
>> +       select SND_SOC_DMAENGINE_PCM
>>
>>   config SND_ATMEL_SOC_SSC
>>         tristate
>> @@ -32,6 +33,17 @@ config SND_AT91_SOC_SAM9G20_WM8731
>>           Say Y if you want to add support for SoC audio on WM8731-based
>>           AT91sam9g20 evaluation board.
>>
>> +config SND_AT91_SOC_SAM9X5_WM8731
>> +       tristate "SoC Audio support for WM8731-based at91sam9x5 board"
>> +       depends on ATMEL_SSC && SND_ATMEL_SOC && SOC_AT91SAM9X5
>> +       select SND_ATMEL_SOC_SSC
>> +       select SND_ATMEL_SOC_DMA
>> +       select SND_ATMEL_SOC_PDC
>
>
> Not need to select SND_ATMEL_SOC_PDC
ok, I'll drop this

>> +       select SND_SOC_WM8731
>> +       help
>> +         Say Y if you want to add support for audio SoC on an
>> +         at91sam9x5 based board that is using WM8731 codec.
>> +
>>   config SND_AT91_SOC_AFEB9260
>>         tristate "SoC Audio support for AFEB9260 board"
>>         depends on ARCH_AT91 && ATMEL_SSC && ARCH_AT91 && MACH_AFEB9260 &&
>> SND_ATMEL_SOC
>> diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
>> index 41967cc..7784c09 100644
>> --- a/sound/soc/atmel/Makefile
>> +++ b/sound/soc/atmel/Makefile
>> @@ -11,6 +11,8 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) +=
>> snd-soc-atmel_ssc_dai.o
>>
>>   # AT91 Machine Support
>>   snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
>> +snd-soc-sam9x5-wm8731-objs := sam9x5_wm8731.o
>>
>>   obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
>> +obj-$(CONFIG_SND_AT91_SOC_SAM9X5_WM8731) += snd-soc-sam9x5-wm8731.o
>>   obj-$(CONFIG_SND_AT91_SOC_AFEB9260) += snd-soc-afeb9260.o
>> diff --git a/sound/soc/atmel/sam9x5_wm8731.c
>> b/sound/soc/atmel/sam9x5_wm8731.c
>> new file mode 100644
>> index 0000000..83ca457
>> --- /dev/null
>> +++ b/sound/soc/atmel/sam9x5_wm8731.c
>> @@ -0,0 +1,232 @@
>> +/*
>> + * sam9x5_wm8731   --  SoC audio for AT91SAM9X5-based boards
>> + *                     that are using WM8731 as codec.
>> + *
>> + *  Copyright (C) 2011 Atmel,
>> + *               Nicolas Ferre <nicolas.ferre at atmel.com>
>> + *
>> + * Based on sam9g20_wm8731.c by:
>> + * Sedji Gaouaou <sedji.gaouaou at atmel.com>
>> + *
>> + * GPL
>> + */
>> +#include <linux/module.h>
>> +#include <linux/moduleparam.h>
>> +#include <linux/kernel.h>
>> +#include <linux/clk.h>
>> +#include <linux/timer.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/i2c.h>
>> +
>> +#include <linux/atmel-ssc.h>
>> +
>> +#include <sound/core.h>
>> +#include <sound/pcm.h>
>> +#include <sound/pcm_params.h>
>> +#include <sound/soc.h>
>> +
>> +#include <asm/mach-types.h>
>> +#include <mach/hardware.h>
>> +#include <mach/gpio.h>
>> +
>> +#include "../codecs/wm8731.h"
>> +#include "atmel-pcm.h"
>> +#include "atmel_ssc_dai.h"
>> +
>> +#define MCLK_RATE 12288000
>> +
>> +#define DRV_NAME "sam9x5-snd-wm8731"
>> +
>> +/*
>> + * Audio paths on at91sam9x5ek board:
>> + *
>> + *  |A| ------------> |      | ---R----> Headphone Jack
>> + *  |T| <----\        |  WM  | ---L--/
>> + *  |9| ---> CLK <--> | 8751 | <--R----- Line In Jack
>> + *  |1| <------------ |      | <--L--/
>> + */
>> +static const struct snd_soc_dapm_widget at91sam9x5ek_dapm_widgets[] = {
>> +       SND_SOC_DAPM_HP("Headphone Jack", NULL),
>> +       SND_SOC_DAPM_LINE("Line In Jack", NULL),
>> +};
>> +
>> +/*
>> + * Logic for a wm8731 as connected on a at91sam9x5 based board.
>> + */
>> +static int at91sam9x5ek_wm8731_init(struct snd_soc_pcm_runtime *rtd)
>> +{
>> +       struct snd_soc_codec *codec = rtd->codec;
>> +       struct snd_soc_dai *codec_dai = rtd->codec_dai;
>> +       struct snd_soc_dapm_context *dapm = &codec->dapm;
>> +       struct device *dev = rtd->dev;
>> +       int ret;
>> +
>> +       dev_dbg(dev, "ASoC: at91sam9x5ek_wm8731_init() called\n");
>> +
>> +       /*
>> +        * remove some not supported rates in relation with clock
>> +        * provided to the wm8731 codec
>> +        */
>> +       switch (MCLK_RATE) {
>> +       case 12288000:
>> +               codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 |
>> +                                                    SNDRV_PCM_RATE_32000
>> |
>> +                                                    SNDRV_PCM_RATE_48000
>> |
>> +                                                    SNDRV_PCM_RATE_96000;
>> +               codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 |
>> +                                                   SNDRV_PCM_RATE_32000 |
>> +                                                   SNDRV_PCM_RATE_48000 |
>> +                                                   SNDRV_PCM_RATE_96000;
>> +               break;
>> +       case 12000000:
>> +               /* all wm8731 rates supported */
>> +               break;
>> +       default:
>> +               dev_err(dev, "ASoC: Codec Master clock rate not
>> defined\n");
>> +               return -EINVAL;
>> +       }
>
>
> Here, I think we not need to use switch ... case, as the MCLK_RATE is hard
> code as 12288000.
yes, I'll drop the code for != 12288000

>
> -----------------------------------------------
>
>
>> +       /* set not connected pins */
>> +       snd_soc_dapm_nc_pin(dapm, "Mic Bias");
>> +       snd_soc_dapm_nc_pin(dapm, "MICIN");
>> +       snd_soc_dapm_nc_pin(dapm, "LOUT");
>> +       snd_soc_dapm_nc_pin(dapm, "ROUT");
>> +
>> +       /* always connected */
>> +       snd_soc_dapm_enable_pin(dapm, "Headphone Jack");
>> +       snd_soc_dapm_enable_pin(dapm, "Line In Jack");
>
>
> ------------------------------------------------
> This part, not needed, as to the ASoC framework will deal with it.
ok !

>
>
>> +       /* set the codec system clock for DAC and ADC */
>> +       ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
>> +                                    MCLK_RATE, SND_SOC_CLOCK_IN);
>> +       if (ret < 0) {
>> +               dev_err(dev, "ASoC: Failed to set WM8731 SYSCLK: %d\n",
>> ret);
>> +               return ret;
>> +       }
>> +
>> +       /* signal a DAPM event */
>> +       snd_soc_dapm_sync(dapm);
>> +       return 0;
>> +}
>> +
>> +static int sam9x5_wm8731_driver_probe(struct platform_device *pdev)
>> +{
>> +       struct device_node *np = pdev->dev.of_node;
>> +       struct device_node *codec_np, *cpu_np;
>> +       struct snd_soc_card *card;
>> +       struct snd_soc_dai_link *dai;
>> +       int ret;
>> +
>> +       if (!np) {
>> +               dev_err(&pdev->dev, "No device node supplied\n");
>> +               return -EINVAL;
>> +       }
>> +
>> +       ret = atmel_ssc_set_audio(0);
>> +       if (ret != 0) {
>> +               dev_err(&pdev->dev,
>> +                       "ASoC: Failed to set SSC 0 for audio: %d\n", ret);
>> +               return ret;
>> +       }
>> +
>> +       card = devm_kzalloc(&pdev->dev, sizeof(*card), GFP_KERNEL);
>> +       dai = devm_kzalloc(&pdev->dev, sizeof(*dai), GFP_KERNEL);
>> +       if (!dai || !card) {
>> +               ret = -ENOMEM;
>> +               goto out;
>> +       }
>> +
>> +       card->dev = &pdev->dev;
>> +       card->owner = THIS_MODULE;
>> +       card->dai_link = dai;
>> +       card->num_links = 1;
>> +       dai->name = "WM8731";
>> +       dai->stream_name = "WM8731 PCM";
>> +       dai->codec_dai_name = "wm8731-hifi";
>> +       dai->init = at91sam9x5ek_wm8731_init;
>> +       card->dapm_widgets = at91sam9x5ek_dapm_widgets;
>> +       card->num_dapm_widgets = ARRAY_SIZE(at91sam9x5ek_dapm_widgets);
>
>
> Will keep these as snd_soc_card and snd_soc_dai_link structure separately?
I don't really understand what you mean here.
do you mean that something like that will more explicit ? :
+       card->dai_link[0].name = "WM8731";
+       card->dai_link[0].stream_name = "WM8731 PCM";
+       card->dai_link[0].codec_dai_name = "wm8731-hifi";
+       card->dai_link[0].init = at91sam9x5ek_wm8731_init;

>
>
>> +       ret = snd_soc_of_parse_card_name(card, "atmel,model");
>> +       if (ret)
>> +               goto out;
>> +
>> +       ret = snd_soc_of_parse_audio_routing(card, "atmel,audio-routing");
>> +       if (ret)
>> +               goto out;
>> +
>> +       codec_np = of_parse_phandle(np, "atmel,audio-codec", 0);
>> +       if (!codec_np) {
>> +               dev_err(&pdev->dev, "codec info missing\n");
>> +               ret = -EINVAL;
>> +               goto out;
>> +       }
>> +
>> +       dai->codec_of_node = codec_np;
>> +
>> +       cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
>> +       if (!cpu_np) {
>> +               dev_err(&pdev->dev, "ssc controller node missing\n");
>> +               ret = -EINVAL;
>> +               goto out;
>> +       }
>> +       dai->cpu_of_node = cpu_np;
>> +       dai->platform_of_node = cpu_np;
>> +
>> +       of_node_put(codec_np);
>> +       of_node_put(cpu_np);
>> +
>> +       dai->dai_fmt = snd_soc_of_parse_daifmt(np, "atmel,");
>> +
>> +       ret = snd_soc_register_card(card);
>> +       if (ret) {
>> +               dev_err(&pdev->dev,
>> +                       "ASoC: Platform device allocation failed\n");
>> +               goto out;
>> +       }
>> +
>> +       platform_set_drvdata(pdev, card);
>> +
>> +       dev_info(&pdev->dev, "ASoC: at91sam9x5ek_init ok\n");
>> +
>> +       return ret;
>> +
>> +out:
>> +       atmel_ssc_put_audio(0);
>> +       return ret;
>> +}
>> +
>> +static int sam9x5_wm8731_driver_remove(struct platform_device *pdev)
>> +{
>> +       struct snd_soc_card *card = platform_get_drvdata(pdev);
>> +
>> +       snd_soc_unregister_card(card);
>> +       atmel_ssc_put_audio(0);
>> +
>> +       return 0;
>> +}
>> +
>> +static const struct of_device_id sam9x5_wm8731_of_match[] = {
>> +       { .compatible = "atmel,sam9x5-audio-wm8731", },
>> +       {},
>> +};
>> +MODULE_DEVICE_TABLE(of, sam9x5_wm8731_of_match);
>> +
>> +static struct platform_driver sam9x5_wm8731_driver = {
>> +       .driver = {
>> +               .name = DRV_NAME,
>> +               .owner = THIS_MODULE,
>> +               .of_match_table = of_match_ptr(sam9x5_wm8731_of_match),
>> +       },
>> +       .probe = sam9x5_wm8731_driver_probe,
>> +       .remove = sam9x5_wm8731_driver_remove,
>> +};
>> +module_platform_driver(sam9x5_wm8731_driver);
>> +
>> +/* Module information */
>> +MODULE_AUTHOR("Nicolas Ferre <nicolas.ferre at atmel.com>");
>> +MODULE_AUTHOR("Richard Genoud <richard.genoud at gmail.com>");
>> +MODULE_DESCRIPTION("ALSA SoC machine driver for AT91SAM9x5 - WM8731");
>> +MODULE_LICENSE("GPL");
>> +MODULE_ALIAS("platform:" DRV_NAME);
>>
>
> Best Regards,
> Bo Shen

Thanks for reviewing !


Best regards
Richard.

-- 
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?


From arnd at arndb.de  Fri Jul  5 11:40:13 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Jul 2013 17:40:13 +0200
Subject: [PATCH] thermal: cpu_cooling: fix stub function
Message-ID: <201307051740.13692.arnd@arndb.de>

The function stub for cpufreq_cooling_get_level introduced
in 57df81069 "Thermal: exynos: fix cooling state translation"
is not syntactically correct C and needs to be fixed to avoid
this error:

In file included from drivers/thermal/db8500_thermal.c:20:0:
 include/linux/cpu_cooling.h: In function 'cpufreq_cooling_get_level':
include/linux/cpu_cooling.h:57:1:
 error: parameter name omitted  unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int)  ^
 include/linux/cpu_cooling.h:57:1: error: parameter name omitted

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Eduardo Valentin <eduardo.valentin at ti.com>
Cc: Zhang Rui <rui.zhang at intel.com>
Cc: Amit Daniel kachhap <amit.daniel at samsung.com>
Cc: stable at vger.kernel.org
---
This is now needed for stable, since 3.10 is out.

diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
index 282e270..a5d52ee 100644
--- a/include/linux/cpu_cooling.h
+++ b/include/linux/cpu_cooling.h
@@ -41,7 +41,7 @@ cpufreq_cooling_register(const struct cpumask *clip_cpus);
  */
 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev);
 
-unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int);
+unsigned long cpufreq_cooling_get_level(unsigned int cpu, unsigned int freq);
 #else /* !CONFIG_CPU_THERMAL */
 static inline struct thermal_cooling_device *
 cpufreq_cooling_register(const struct cpumask *clip_cpus)
@@ -54,7 +54,7 @@ void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
 	return;
 }
 static inline
-unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int)
+unsigned long cpufreq_cooling_get_level(unsigned int cpu, unsigned int freq)
 {
 	return THERMAL_CSTATE_INVALID;
 }


From arnd at arndb.de  Fri Jul  5 11:38:35 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Jul 2013 17:38:35 +0200
Subject: [PATCH, re-send] Always trap on BUG()
Message-ID: <201307051738.35930.arnd@arndb.de>

I've run some size analyis using the ARM 'multi_v7_defconfig'
and gcc-4.8, using various definitions for BUG() and BUG_ON(), to
see how big the size improvement actually gets

1. Baseline: normal bug plus CONFIG_BUG_VERBOSE
   text    data     bss     dec     hex filename
3743196  224396  206812 4174404  3fb244 vmlinux-bugverbose

2. disabling CONFIG_BUG_VERBOSE, saving 0.6%
3716920  224380  206812 4148112  3f4b90 vmlinux-nobugverbose

3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.0%
3701076  224384  206812 4132272  3f0db0 vmlinux-bug-panicfunc

3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.5%
3678884  224400  206812 4110096  3eb710 vmlinux-bug-panic

4. #define BUG() unreachable(), saving 2.1%
3652636  224384  206812 4083832  3e5078 vmlinux-bug-unreachable

5. as 4, plus #define BUG_ON(c) if(c) unreachable(), saving 2.2%
3651108  224380  206812 4082300  3e4a7c vmlinux-bugon-unreachable

6. #define BUG() do{}while(0), saving 2.1%
3654264  224380  206812 4085456  3e56d0 vmlinux-nobug

7. as 6, plus #define BUG_ON if(0 && (c)) unreachable, saving 2.2%
3648392  223996  206748 4079136  3e3e20 vmlinux-no-bugon

8. my patch below, saving 1.8%
3666532  224380  206812 4097724  3e86bc obj-tmp/vmlinux

The gain of doing unreachable and letting the code run off whereever
is minimal compared to the current state of doing nothing, but it
avoids the warnings.

Same test using x86_defconfig:

1. CONFIG_BUG=y, CONFIG_BUGVERBOSE=n
10797859        1395648 1175552 13369059         cbfee3 vmlinux-x86-bug

2. CONFIG_BUG=n, saves 1.0%
10658553        1395584 1175552 13229689         c9de79 vmlinux-x86-nobug

3. with my patch, saves 0.8%
10684186        1395584 1175552 13255322         ca429a vmlinux-x86-archbug

Getting 1-2% savings in kernel size seems absolutely worth keeping the
option, but 0.2-0.4% left for getting reproducible behavior also seems
worthwhile. The result in the patch below.

This basically loses any of the BUG() reporting, but leaves the
logic to trap and kill the task in place when CONFIG_BUG is disabled.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: linux-arch at vger.kernel.org
Cc: Chen Gang <gang.chen at asianux.com>
Cc: "H. Peter Anvin" <hpa at zytor.com>
Cc: Ingo Molnar <mingo at kernel.org>
Cc: "Eric W. Biederman" <ebiederm at xmission.com>
Cc: Geert Uytterhoeven <geert at linux-m68k.org>
Cc: Russell King - ARM Linux <linux at arm.linux.org.uk>

diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
index 7af5c6c..4a5b85d 100644
--- a/arch/arm/include/asm/bug.h
+++ b/arch/arm/include/asm/bug.h
@@ -3,8 +3,6 @@
 
 #include <linux/linkage.h>
 
-#ifdef CONFIG_BUG
-
 /*
  * Use a suitable undefined instruction to use for ARM/Thumb2 bug handling.
  * We need to be careful not to conflict with those used by other modules and
@@ -54,7 +52,6 @@ do {								\
 #endif  /* CONFIG_DEBUG_BUGVERBOSE */
 
 #define HAVE_ARCH_BUG
-#endif  /* CONFIG_BUG */
 
 #include <asm-generic/bug.h>
 
diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index 2f03ff0..ba38ebb 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -1,7 +1,6 @@
 #ifndef _ASM_X86_BUG_H
 #define _ASM_X86_BUG_H
 
-#ifdef CONFIG_BUG
 #define HAVE_ARCH_BUG
 
 #ifdef CONFIG_DEBUG_BUGVERBOSE
@@ -33,8 +32,6 @@ do {								\
 } while (0)
 #endif
 
-#endif /* !CONFIG_BUG */
-
 #include <asm-generic/bug.h>
 
 #endif /* _ASM_X86_BUG_H */
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..bbd2872 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -112,12 +112,13 @@ extern void warn_slowpath_null(const char *file, const int line);
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON
 #define WARN_ON(condition) ({						\
 	int __ret_warn_on = !!(condition);				\
+	(void)__ret_warn_on;						\
 	unlikely(__ret_warn_on);					\
 })
 #endif
@@ -125,6 +126,8 @@ extern void warn_slowpath_null(const char *file, const int line);
 #ifndef WARN
 #define WARN(condition, format...) ({					\
 	int __ret_warn_on = !!(condition);				\
+	if (0 && (__ret_warn_on))					\
+		printk(format);						\
 	unlikely(__ret_warn_on);					\
 })
 #endif


From wangyuhang2014 at gmail.com  Fri Jul  5 11:41:08 2013
From: wangyuhang2014 at gmail.com (yuhang wang)
Date: Fri, 5 Jul 2013 23:41:08 +0800
Subject: SPI: DUAL/QUAD support
In-Reply-To: <20130705143452.GA7738@sig21.net>
References: <OFAD729A05.8C915625-ONC1257B9E.00576B25-C1257B9E.0058477D@rohde-schwarz.com>
 <CAHSAbzOg+uHndydSC43moF7pijc67pqzB2rPnY69ynXHEzw79g@mail.gmail.com>
 <51D67851.8020402@ti.com>
 <CAHSAbzNvMo_oeaqtzO8-xDm-L-f8wVccVqfuVqbR=OwqWJhVwg@mail.gmail.com>
 <51D689F3.3070605@ti.com>
 <CAHSAbzM1PGoMXFNOmB7guDsVWYnRoRy89-bufHYpPz5+odnd8w@mail.gmail.com>
 <51D68D14.7090606@ti.com>
 <CAHSAbzMfvfdDtTh=3zeBni4fNMAHEMdTJLJU-Oc13HJUqCUj0A@mail.gmail.com>
 <51D69197.7060802@ti.com>
 <CAHSAbzP1-RVot+hhtY_DcBK=u5n2234eb9WOKLESwvUNax7+pA@mail.gmail.com>
 <20130705143452.GA7738@sig21.net>
Message-ID: <CAHSAbzPiy1TVypP6xvHkBrhMozjifDdVSuErZY-av4RMbT1MTw@mail.gmail.com>

2013/7/5 Johannes Stezenbach <js at sig21.net>:
> On Fri, Jul 05, 2013 at 06:24:40PM +0800, yuhang wang wrote:
>>
>> 2 Questions here:
>> 1.In m25p80.c probe, the kmalloc below I feel very strange.
>>       flash->command = kmalloc(MAX_CMD_SIZE + (flash->fast_read ? 1 : 0),
>>                                       GFP_KERNEL);
>>
>>  (flash->fast_read ? 1 : 0) must be 0! So why do it like that.
>
> Maybe just increase MAX_CMD_SIZE by 1 unconditonally?
> Yeah, looks like a bug in m25p80.c, flash->fast_read
> is initialized too late.
>
>> +#define        OPCODE_DOR              0x3B    /* Dual Output Read */
>> +#define        OPCODE_QOR              0x6B    /* Quad Output Read */
>> +#define        OPCODE_QPP              0x32    /* Quad Page Programming */
>> +#define        OPCODE_QEN              0x02 /* Quad Mode Enable Flag */
>
> Which flash chip are these for?  The OPCODE_DOR and OPCODE_QOR
> match MX25L25635E, but OPCODE_QPP not (Macronix uses 0x38).
>
Thanks for the review. And I have said that it is not a general code to support
dual and quad, it is just a situation to fit my system. Perhaps it is very hard
to provide a general code before a serial-norflash standard comes out.

>> +#ifdef CONFIG_M25PXX_USE_FAST_READ
>> +#define OPCODE_READ    OPCODE_FAST_READ
>> +#define FAST_READ_DUMMY_BYTE 1
>> +#else
>> +#define OPCODE_READ    OPCODE_NORM_READ
>> +#define FAST_READ_DUMMY_BYTE 0
>> +#endif
>
> this doesn't work with the flash->fast_read setting from DT
>
> BTW, if we add "bitwidths" to spi_board_info, wouldn't
> it make sense to also add "use_fast_read" and remove the
> CONFIG_M25PXX_USE_FAST_READ option?
>

Well, I think we should make sure that whether all spi slave has the "fast read"
feature before we add "use_fast_read" into the  spi_board_info.
There should be some other flash or slaves do not support this
feature. So in my opinion, Fast read still supported as a M25p config
should be more suitable.
>> +/*
>> + * Write configuration register 2 byte
>> + * Returns negative if error occurred.
>> + */
>> +static int write_cr(struct m25p *flash, u16 val)
>> +{
>> +       flash->command[0] = OPCODE_WRSR;
>> +       flash->command[1] = val >> 8;
>> +       flash->command[2] = val;
>> +
>> +       return spi_write(flash->spi, flash->command, 3);
>> +}
>
>> +       if ((flash->spi->rx_bitwidth == SPI_BITWIDTH_QUAD) ||
>> +               (flash->spi->tx_bitwidth == SPI_BITWIDTH_QUAD)) {
>> +               write_enable(flash);
>> +               write_cr(flash, OPCODE_QEN);
>> +       }
>
> MX25L25635E doesn't have a cr, instead a bit needs to be set in the sr
>
> Maybe we need to add some fields to m25p_ids[] to manage variation
> between flash devices.
>
similar to the first answer. Also a standard is the solution to these questions.
Thanks a lot.


From arnd at arndb.de  Fri Jul  5 11:41:38 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Jul 2013 17:41:38 +0200
Subject: [PATCH, re-send] drm: always provide debugfs function prototypes
Message-ID: <201307051741.38496.arnd@arndb.de>

It is generally considered bad style to enclose function prototypes
in header files in #ifdef. This case illustrates why that is:
The tegra host1x driver calls into the debugfs functions if
CONFIG_DEBUG_FS is enabled, but that code is otherwise already
discarded by the compiler, so leaving the prototype in place
actually makes everything work.

drivers/gpu/host1x/drm/dc.c: In function 'tegra_dc_debugfs_init':
drivers/gpu/host1x/drm/dc.c:1004:2: error: implicit declaration of function 'drm_debugfs_create_files' [-Werror=implicit-function-declaration]
drivers/gpu/host1x/drm/dc.c: In function 'tegra_dc_debugfs_exit': drivers/gpu/host1x/drm/dc.c:1026:2: error: implicit declaration of function 'drm_debugfs_remove_files' [-Werror=implicit-function-declaration]

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Thierry Reding <thierry.reding@>
Cc: Ben Gamari <bgamari at gmail.com>
Cc: Dave Airlie <airlied at redhat.com>

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 63d17ee..8bc105e 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1551,7 +1551,7 @@ extern int drm_proc_init(struct drm_minor *minor, struct proc_dir_entry *root);
 extern int drm_proc_cleanup(struct drm_minor *minor, struct proc_dir_entry *root);
 
 				/* Debugfs support */
-#if defined(CONFIG_DEBUG_FS)
+
 extern int drm_debugfs_init(struct drm_minor *minor, int minor_id,
 			    struct dentry *root);
 extern int drm_debugfs_create_files(struct drm_info_list *files, int count,
@@ -1559,7 +1559,6 @@ extern int drm_debugfs_create_files(struct drm_info_list *files, int count,
 extern int drm_debugfs_remove_files(struct drm_info_list *files, int count,
                                     struct drm_minor *minor);
 extern int drm_debugfs_cleanup(struct drm_minor *minor);
-#endif
 
 				/* Info file support */
 extern int drm_name_info(struct seq_file *m, void *data);
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 88591ef..4a7759a 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -37,9 +37,7 @@
  * Generic range manager structs
  */
 #include <linux/list.h>
-#ifdef CONFIG_DEBUG_FS
 #include <linux/seq_file.h>
-#endif
 
 struct drm_mm_node {
 	struct list_head node_list;


From soren.brinkmann at xilinx.com  Fri Jul  5 11:43:11 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Fri, 5 Jul 2013 08:43:11 -0700
Subject: [PATCH] clocksource/cadence_ttc: Reuse clocksource as sched_clock
In-Reply-To: <alpine.DEB.2.02.1307050819000.11637@ionos.tec.linutronix.de>
References: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>
 <alpine.DEB.2.02.1307050819000.11637@ionos.tec.linutronix.de>
Message-ID: <fbeb6f36-f07a-4518-b6f2-0b8e36028fe9@CH1EHSMHS012.ehs.local>

On Fri, Jul 05, 2013 at 08:30:47AM +0200, Thomas Gleixner wrote:
> On Wed, 3 Jul 2013, Soren Brinkmann wrote:
> 
> > Reuse the TTC clocksource timer as sched clock, too. Since only a single
> > sched clock is supported in Linux, this feature optional and can be
> > selected through Kconfig.
> 
> This changelog doesn't make sense.
> 
> There can be only one active sched_clock, but that does no mean, that
> you cannot have different implementations compiled in.
> 
> So if you disable this config which sched_clock is your kernel using?
Jiffies

> And if you enable it, how is guaranteed that you end up with the ttc
> sched_clock as the active one? Just due to initcall ordering?
I assumed so. Is there a different mechanism?

	S?ren




From paul at pwsan.com  Fri Jul  5 11:44:32 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Fri, 5 Jul 2013 15:44:32 +0000 (UTC)
Subject: OMAP baseline test results for v3.10-rc6
In-Reply-To: <51D65E3C.1070202@ti.com>
References: <alpine.DEB.2.02.1306170521020.9909@utopia.booyaka.com>
 <20130625160243.GE22312@arwen.pp.htv.fi>
 <alpine.DEB.2.02.1306251746060.14373@utopia.booyaka.com>
 <51C9F0A8.1050607@ti.com> <87fvw6t136.fsf@linaro.org>
 <79CD15C6BA57404B839C016229A409A83ECC952D@DBDE04.ent.ti.com>
 <51CAEB33.5010101@ti.com>
 <alpine.DEB.2.02.1306261722520.6135@utopia.booyaka.com>
 <51CBBCD8.5030600@ti.com>
 <alpine.DEB.2.02.1306281844090.8767@utopia.booyaka.com>
 <alpine.DEB.2.02.1307010211580.3741@utopia.booyaka.com>
 <79CD15C6BA57404B839C016229A409A83ECCC435@DBDE04.ent.ti.com>
 <51D2E096.5040700@ti.com>
 <alpine.DEB.2.02.1307031944580.9618@utopia.booyaka.com>
 <alpine.DEB.2.02.1307041810410.6258@utopia.booyaka.com>
 <51D65E3C.1070202@ti.com>
Message-ID: <alpine.DEB.2.02.1307051530290.8573@utopia.booyaka.com>

On Fri, 5 Jul 2013, Rajendra Nayak wrote:

> Grant already made it clear when he posted that patch that neither that nor
> anything similar would be taken up mainline because the appended dtb was only
> meant for folks stuck with legacy bootloaders and have no way to upgrade.

He's not the final arbiter of what goes into the mainline kernel :-)

> Anyone who uses a bootloader capable of passing the dtb should *not* use
> the appended dtb way.

Look, either the kernel should support appended DTB booting, or it 
shouldn't.  If it shouldn't, then that code should be ripped out of the 
kernel completely, and we tell people 'tough luck'. If it should, then it 
makes sense to help the millions of folks out there with locked 
bootloaders to build and boot new kernels. This half-support that's in the 
kernel now is not good.


- Paul


From arnd at arndb.de  Fri Jul  5 11:45:15 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Jul 2013 17:45:15 +0200
Subject: [PATCH] ASoC: Allow imx-pcm-{dma,fiq}.c to be modules
Message-ID: <201307051745.16140.arnd@arndb.de>

This is required so we can build the imx sound support
when ALSA itself is a loadable module.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: alsa-devel at alsa-project.org
Cc: Mark Brown <broonie at kernel.org>
Cc: Fabio Estevam <fabio.estevam at freescale.com>

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index aa43854..805b83e 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -109,11 +109,11 @@ config SND_SOC_IMX_SSI
 	tristate
 
 config SND_SOC_IMX_PCM_FIQ
-	bool
+	tristate
 	select FIQ
 
 config SND_SOC_IMX_PCM_DMA
-	bool
+	tristate
 	select SND_SOC_GENERIC_DMAENGINE_PCM
 
 config SND_SOC_IMX_AUDMUX
diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
index 67f656c..0e3619e 100644
--- a/sound/soc/fsl/imx-pcm.h
+++ b/sound/soc/fsl/imx-pcm.h
@@ -32,7 +32,7 @@ imx_pcm_dma_params_init_data(struct imx_dma_data *dma_data,
 		dma_data->peripheral_type = IMX_DMATYPE_SSI;
 }
 
-#ifdef CONFIG_SND_SOC_IMX_PCM_DMA
+#if IS_ENABLED(CONFIG_SND_SOC_IMX_PCM_DMA)
 int imx_pcm_dma_init(struct platform_device *pdev);
 void imx_pcm_dma_exit(struct platform_device *pdev);
 #else
@@ -46,7 +46,7 @@ static inline void imx_pcm_dma_exit(struct platform_device *pdev)
 }
 #endif
 
-#ifdef CONFIG_SND_SOC_IMX_PCM_FIQ
+#if IS_ENABLED(CONFIG_SND_SOC_IMX_PCM_FIQ)
 int imx_pcm_fiq_init(struct platform_device *pdev);
 void imx_pcm_fiq_exit(struct platform_device *pdev);
 #else


From arnd at arndb.de  Fri Jul  5 11:51:20 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Jul 2013 17:51:20 +0200
Subject: [PATCH] ARM: pxa: propagate errors from regulator_enable() to pxamci
Message-ID: <201307051751.20729.arnd@arndb.de>

The em_x270_mci_setpower() and em_x270_usb_hub_init() functions
call regulator_enable(), which may return an error that must
be checked.

This changes the em_x270_usb_hub_init() function to bail out
if it fails, and changes the pxamci_platform_data->setpower
callback so that the a failed em_x270_mci_setpower call
can be propagated by the pxamci driver into the mmc core.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: Mike Rapoport <mike at compulab.co.il>
Cc: Paul Gortmaker <paul.gortmaker at windriver.com>
Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
Cc: Haojian Zhuang <haojian.zhuang at gmail.com>
Cc: Chris Ball <cjb at laptop.org>

diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index f6726bb..f8062e4 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -477,16 +477,24 @@ static int em_x270_usb_hub_init(void)
 	/* USB Hub power-on and reset */
 	gpio_direction_output(usb_hub_reset, 1);
 	gpio_direction_output(GPIO9_USB_VBUS_EN, 0);
-	regulator_enable(em_x270_usb_ldo);
+	err = regulator_enable(em_x270_usb_ldo);
+	if (err)
+		goto err_free_rst_gpio;
+
 	gpio_set_value(usb_hub_reset, 0);
 	gpio_set_value(usb_hub_reset, 1);
 	regulator_disable(em_x270_usb_ldo);
-	regulator_enable(em_x270_usb_ldo);
+	if (err)
+		goto err_free_rst_gpio;
+
+	err = regulator_enable(em_x270_usb_ldo);
 	gpio_set_value(usb_hub_reset, 0);
 	gpio_set_value(GPIO9_USB_VBUS_EN, 1);
 
 	return 0;
 
+err_free_rst_gpio:
+	gpio_free(usb_hub_reset);
 err_free_vbus_gpio:
 	gpio_free(GPIO9_USB_VBUS_EN);
 err_free_usb_ldo:
@@ -592,7 +600,7 @@ err_irq:
 	return err;
 }
 
-static void em_x270_mci_setpower(struct device *dev, unsigned int vdd)
+static int em_x270_mci_setpower(struct device *dev, unsigned int vdd)
 {
 	struct pxamci_platform_data* p_d = dev->platform_data;
 
@@ -600,10 +608,11 @@ static void em_x270_mci_setpower(struct device *dev, unsigned int vdd)
 		int vdd_uV = (2000 + (vdd - __ffs(MMC_VDD_20_21)) * 100) * 1000;
 
 		regulator_set_voltage(em_x270_sdio_ldo, vdd_uV, vdd_uV);
-		regulator_enable(em_x270_sdio_ldo);
+		return regulator_enable(em_x270_sdio_ldo);
 	} else {
 		regulator_disable(em_x270_sdio_ldo);
 	}
+	return 0;
 }
 
 static void em_x270_mci_exit(struct device *dev, void *data)
diff --git a/arch/arm/mach-pxa/mainstone.c b/arch/arm/mach-pxa/mainstone.c
index d2c6523..dd70343 100644
--- a/arch/arm/mach-pxa/mainstone.c
+++ b/arch/arm/mach-pxa/mainstone.c
@@ -408,7 +408,7 @@ static int mainstone_mci_init(struct device *dev, irq_handler_t mstone_detect_in
 	return err;
 }
 
-static void mainstone_mci_setpower(struct device *dev, unsigned int vdd)
+static int mainstone_mci_setpower(struct device *dev, unsigned int vdd)
 {
 	struct pxamci_platform_data* p_d = dev->platform_data;
 
@@ -420,6 +420,7 @@ static void mainstone_mci_setpower(struct device *dev, unsigned int vdd)
 		printk(KERN_DEBUG "%s: off\n", __func__);
 		MST_MSCWR1 &= ~MST_MSCWR1_MMC_ON;
 	}
+	return 0;
 }
 
 static void mainstone_mci_exit(struct device *dev, void *data)
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c b/arch/arm/mach-pxa/pcm990-baseboard.c
index fb7f1d1..13e5b00 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -335,7 +335,7 @@ static int pcm990_mci_init(struct device *dev, irq_handler_t mci_detect_int,
 	return err;
 }
 
-static void pcm990_mci_setpower(struct device *dev, unsigned int vdd)
+static int pcm990_mci_setpower(struct device *dev, unsigned int vdd)
 {
 	struct pxamci_platform_data *p_d = dev->platform_data;
 	u8 val;
@@ -348,6 +348,7 @@ static void pcm990_mci_setpower(struct device *dev, unsigned int vdd)
 		val &= ~PCM990_CTRL_MMC2PWR;
 
 	pcm990_cpld_writeb(PCM990_CTRL_MMC2PWR, PCM990_CTRL_REG5);
+	return 0;
 }
 
 static void pcm990_mci_exit(struct device *dev, void *data)
diff --git a/arch/arm/mach-pxa/poodle.c b/arch/arm/mach-pxa/poodle.c
index 50ccd5f..cb374c2 100644
--- a/arch/arm/mach-pxa/poodle.c
+++ b/arch/arm/mach-pxa/poodle.c
@@ -258,7 +258,7 @@ err_free_2:
 	return err;
 }
 
-static void poodle_mci_setpower(struct device *dev, unsigned int vdd)
+static int poodle_mci_setpower(struct device *dev, unsigned int vdd)
 {
 	struct pxamci_platform_data* p_d = dev->platform_data;
 
@@ -270,6 +270,8 @@ static void poodle_mci_setpower(struct device *dev, unsigned int vdd)
 		gpio_set_value(POODLE_GPIO_SD_PWR1, 0);
 		gpio_set_value(POODLE_GPIO_SD_PWR, 0);
 	}
+
+	return 0;
 }
 
 static void poodle_mci_exit(struct device *dev, void *data)
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 362726c..49bfcd7 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -597,7 +597,7 @@ static inline void spitz_spi_init(void) {}
  * NOTE: The card detect interrupt isn't debounced so we delay it by 250ms to
  * give the card a chance to fully insert/eject.
  */
-static void spitz_mci_setpower(struct device *dev, unsigned int vdd)
+static int spitz_mci_setpower(struct device *dev, unsigned int vdd)
 {
 	struct pxamci_platform_data* p_d = dev->platform_data;
 
@@ -605,6 +605,8 @@ static void spitz_mci_setpower(struct device *dev, unsigned int vdd)
 		spitz_card_pwr_ctrl(SCOOP_CPR_SD_3V, SCOOP_CPR_SD_3V);
 	else
 		spitz_card_pwr_ctrl(SCOOP_CPR_SD_3V, 0x0);
+
+	return 0;
 }
 
 static struct pxamci_platform_data spitz_mci_platform_data = {
diff --git a/arch/arm/mach-pxa/stargate2.c b/arch/arm/mach-pxa/stargate2.c
index 88fde43..62aea3e 100644
--- a/arch/arm/mach-pxa/stargate2.c
+++ b/arch/arm/mach-pxa/stargate2.c
@@ -734,9 +734,10 @@ static int stargate2_mci_init(struct device *dev,
  *
  * Very simple control. Either it is on or off and is controlled by
  * a gpio pin */
-static void stargate2_mci_setpower(struct device *dev, unsigned int vdd)
+static int stargate2_mci_setpower(struct device *dev, unsigned int vdd)
 {
 	gpio_set_value(SG2_SD_POWER_ENABLE, !!vdd);
+	return 0;
 }
 
 static void stargate2_mci_exit(struct device *dev, void *data)
diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c
index 2b2f65a..ad65170 100644
--- a/drivers/mmc/host/pxamci.c
+++ b/drivers/mmc/host/pxamci.c
@@ -128,7 +128,7 @@ static inline int pxamci_set_power(struct pxamci_host *host,
 			       !!on ^ host->pdata->gpio_power_invert);
 	}
 	if (!host->vcc && host->pdata && host->pdata->setpower)
-		host->pdata->setpower(mmc_dev(host->mmc), vdd);
+		return host->pdata->setpower(mmc_dev(host->mmc), vdd);
 
 	return 0;
 }
diff --git a/include/linux/platform_data/mmc-pxamci.h b/include/linux/platform_data/mmc-pxamci.h
index 9eb515b..1706b35 100644
--- a/include/linux/platform_data/mmc-pxamci.h
+++ b/include/linux/platform_data/mmc-pxamci.h
@@ -12,7 +12,7 @@ struct pxamci_platform_data {
 	unsigned long detect_delay_ms;		/* delay in millisecond before detecting cards after interrupt */
 	int (*init)(struct device *, irq_handler_t , void *);
 	int (*get_ro)(struct device *);
-	void (*setpower)(struct device *, unsigned int);
+	int (*setpower)(struct device *, unsigned int);
 	void (*exit)(struct device *, void *);
 	int gpio_card_detect;			/* gpio detecting card insertion */
 	int gpio_card_ro;			/* gpio detecting read only toggle */


From cjb at laptop.org  Fri Jul  5 11:53:42 2013
From: cjb at laptop.org (Chris Ball)
Date: Fri, 05 Jul 2013 16:53:42 +0100
Subject: [PATCH] ARM: pxa: propagate errors from regulator_enable() to
 pxamci
In-Reply-To: <201307051751.20729.arnd@arndb.de> (Arnd Bergmann's message of
 "Fri, 5 Jul 2013 17:51:20 +0200")
References: <201307051751.20729.arnd@arndb.de>
Message-ID: <8638rt3svt.fsf@void.printf.net>

Hi,

On Fri, Jul 05 2013, Arnd Bergmann wrote:
> The em_x270_mci_setpower() and em_x270_usb_hub_init() functions
> call regulator_enable(), which may return an error that must
> be checked.
>
> This changes the em_x270_usb_hub_init() function to bail out
> if it fails, and changes the pxamci_platform_data->setpower
> callback so that the a failed em_x270_mci_setpower call
> can be propagated by the pxamci driver into the mmc core.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

For pxamci:

Acked-by: Chris Ball <cjb at laptop.org>

Thanks,

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>


From s.hauer at pengutronix.de  Fri Jul  5 11:59:11 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 5 Jul 2013 17:59:11 +0200
Subject: [v3 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <1373017942-12583-4-git-send-email-Hong-Xing.Zhu@freescale.com>
References: <1373017942-12583-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373017942-12583-4-git-send-email-Hong-Xing.Zhu@freescale.com>
Message-ID: <20130705155911.GK516@pengutronix.de>

On Fri, Jul 05, 2013 at 05:52:22PM +0800, Richard Zhu wrote:
> From: Richard Zhu <r65037 at freescale.com>
> 
> imx6q contains one Synopsys AHCI SATA controller,
> But it can't shares ahci_platform driver with other
> controllers.
> Because there are some misalignments of the bits
> definitions of the HBA registers and the Vendor
> Specific registers
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>  value is '0', should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the
>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>  should be configured regarding to the frequency of AHB
>  bus clock.
>  - Configurations of the AHCI PHY clock, and the signal
>  parameters of the GPR13
> 
> Setup its own ahci sata driver, enable the imx6q ahci
> sata support.
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  drivers/ata/Kconfig    |    9 ++
>  drivers/ata/Makefile   |    1 +
>  drivers/ata/sata_imx.c |  230 ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 240 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/ata/sata_imx.c
> 
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index a5a3ebc..45ed2f0 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -97,6 +97,15 @@ config SATA_AHCI_PLATFORM
>  
>  	  If unsure, say N.
>  
> +config SATA_IMX
> +	tristate "Freescale iMX AHCI SATA support"

It's rather untypical to write iMX. Please write i.MX.

> +	depends on SATA_AHCI_PLATFORM
> +	help
> +	  This option enables support for the Freescale iMX SoC's
> +	  onboard AHCI SATA.
> +
> +	  If unsure, say N.
> +
>  config SATA_FSL
>  	tristate "Freescale 3.0Gbps SATA support"
>  	depends on FSL_SOC
> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
> index c04d0fd..04b1c6c 100644
> --- a/drivers/ata/Makefile
> +++ b/drivers/ata/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_SATA_INIC162X)	+= sata_inic162x.o
>  obj-$(CONFIG_SATA_SIL24)	+= sata_sil24.o
>  obj-$(CONFIG_SATA_DWC)		+= sata_dwc_460ex.o
>  obj-$(CONFIG_SATA_HIGHBANK)	+= sata_highbank.o libahci.o
> +obj-$(CONFIG_SATA_IMX)		+= sata_imx.o
>  
>  # SFF w/ custom DMA
>  obj-$(CONFIG_PDC_ADMA)		+= pdc_adma.o
> diff --git a/drivers/ata/sata_imx.c b/drivers/ata/sata_imx.c
> new file mode 100644
> index 0000000..a129efb
> --- /dev/null
> +++ b/drivers/ata/sata_imx.c
> @@ -0,0 +1,230 @@
> +/*
> + * Freescale IMX AHCI SATA platform driver
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * based on the AHCI SATA platform driver by Jeff Garzik and Anton Vorontsov
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/kernel.h>
> +#include <linux/gfp.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/device.h>
> +#include <linux/platform_device.h>
> +#include <linux/libata.h>
> +#include <linux/ahci_platform.h>
> +#include <linux/of_device.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
> +#include "ahci.h"
> +#include <linux/clk-private.h>

Do you need anything from clk-private.h? You shouldn't.

> +
> +enum {
> +	HOST_TIMER1MS = 0xe0, /* Timer 1-ms */
> +};
> +
> +/* imx6q ahci module initialization. */
> +static int imx6q_sata_phy_clk(struct device *dev, int enable)
> +{
> +	int ret = 0;
> +	struct clk *sata_ref_clk;
> +
> +	sata_ref_clk = devm_clk_get(dev, "sata_ref_100m");
> +	if (IS_ERR(sata_ref_clk)) {
> +		dev_err(dev, "can't get sata_ref clock.\n");
> +		return PTR_ERR(sata_ref_clk);
> +	}

clk_get must be balanced with clk_put. You need to have some private
data and keep a pointer to the clock.

> +	if (enable) {
> +		/* Enable PHY clock */
> +		ret = clk_prepare_enable(sata_ref_clk);
> +		if (ret < 0)
> +			dev_err(dev, "can't prepare-enable sata_ref clock\n");

When printing error messages it's always helpful to print the error code
aswell.

> +	} else {
> +		/* Disable PHY clock */

This comment (also the one above enable) doesn't contain any useful
information.

> +		clk_disable_unprepare(sata_ref_clk);
> +	}
> +
> +	return ret;
> +}
> +
> +static int imx6q_sata_init(struct device *dev, void __iomem *mmio)
> +{
> +	int ret = 0;
> +	struct regmap *gpr;
> +	struct clk *ahb_clk;
> +
> +	ret = imx6q_sata_phy_clk(dev, true);
> +	if (ret < 0)
> +		return ret;
> +
> +	gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +	if (IS_ERR(gpr)) {
> +		dev_err(dev, "failed to find fsl,imx6q-iomux-gpr regmap\n");
> +		return PTR_ERR(gpr);
> +	}
> +
> +	/*
> +	 * set PHY Paremeters, two steps to configure the GPR13,
> +	 * one write for rest of parameters, mask of first write
> +	 * is 0x07fffffd, and the other one write for setting
> +	 * the mpll_clk_en.
> +	 */
> +	regmap_update_bits(gpr, 0x34, IMX6Q_GPR13_SATA_RX_EQ_VAL_MASK
> +			| IMX6Q_GPR13_SATA_RX_LOS_LVL_MASK
> +			| IMX6Q_GPR13_SATA_RX_DPLL_MODE_MASK
> +			| IMX6Q_GPR13_SATA_SPD_MODE_MASK
> +			| IMX6Q_GPR13_SATA_MPLL_SS_EN
> +			| IMX6Q_GPR13_SATA_TX_ATTEN_MASK
> +			| IMX6Q_GPR13_SATA_TX_BOOST_MASK
> +			| IMX6Q_GPR13_SATA_TX_LVL_MASK
> +			| IMX6Q_GPR13_SATA_TX_EDGE_RATE
> +			, IMX6Q_GPR13_SATA_RX_EQ_VAL_3_0_DB
> +			| IMX6Q_GPR13_SATA_RX_LOS_LVL_SATA2M
> +			| IMX6Q_GPR13_SATA_RX_DPLL_MODE_2P_4F
> +			| IMX6Q_GPR13_SATA_SPD_MODE_3P0G
> +			| IMX6Q_GPR13_SATA_MPLL_SS_EN
> +			| IMX6Q_GPR13_SATA_TX_ATTEN_9_16
> +			| IMX6Q_GPR13_SATA_TX_BOOST_3_33_DB
> +			| IMX6Q_GPR13_SATA_TX_LVL_1_025_V);
> +	regmap_update_bits(gpr, 0x34, IMX6Q_GPR13_SATA_MPLL_CLK_EN,
> +			IMX6Q_GPR13_SATA_MPLL_CLK_EN);
> +	usleep_range(100, 200);
> +
> +	/*
> +	 * Configure the HWINIT bits of the HOST_CAP and HOST_PORTS_IMPL,
> +	 * and IP vendor specific register HOST_TIMER1MS.
> +	 *
> +	 * Configure CAP_SSS (support stagered spin up).
> +	 * Implement the port0.
> +	 * Get the ahb clock rate, and configure the TIMER1MS register.
> +	 */
> +	ret = readl(mmio + HOST_CAP);

You should use a u32 type for storing readl results.

> +	if (!(ret & HOST_CAP_SSS))
> +		writel(ret |= HOST_CAP_SSS, mmio + HOST_CAP);

Why do you write this conditionally? Just write it unconditionally.

> +	ret = readl(mmio + HOST_PORTS_IMPL);
> +	if (!(ret & 0x1))
> +		writel((ret | 0x1), mmio + HOST_PORTS_IMPL);

ditto.

> +
> +	ahb_clk = devm_clk_get(dev, "ahb");
> +	if (IS_ERR(ahb_clk)) {
> +		dev_err(dev, "no ahb clock.\n");
> +		return PTR_ERR(ahb_clk);
> +	}

This leaves the phy clock enabled in the error case.

> +	ret = clk_get_rate(ahb_clk) / 1000;
> +	writel(ret, mmio + HOST_TIMER1MS);
> +	devm_clk_put(dev, ahb_clk);
> +
> +	return 0;
> +}
> +
> +static void imx6q_sata_exit(struct device *dev)
> +{
> +	struct regmap *gpr;
> +
> +	gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +	if (IS_ERR(gpr))
> +		dev_err(dev, "failed to find fsl,imx6q-iomux-gpr regmap\n");
> +
> +	regmap_update_bits(gpr, 0x34, IMX6Q_GPR13_SATA_MPLL_CLK_EN,
> +			!IMX6Q_GPR13_SATA_MPLL_CLK_EN);
> +
> +	imx6q_sata_phy_clk(dev, false);
> +}
> +
> +static struct ahci_platform_data imx6q_sata_pdata = {
> +	.init = imx6q_sata_init,
> +	.exit = imx6q_sata_exit,
> +};
> +static const struct of_device_id imx_ahci_of_match[] = {
> +	{ .compatible = "fsl,imx6q-ahci", .data = &imx6q_sata_pdata},
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, imx_ahci_of_match);
> +
> +static void imx_ahci_platform_release(struct device *dev)
> +{
> +	return;
> +}
> +
> +static struct platform_device ahci_pdev = {
> +	.name = "ahci",
> +	.id = -1,
> +	.dev = {
> +		.release = imx_ahci_platform_release,
> +	}
> +};
> +
> +static int imx_ahci_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct resource *mem, *irq, **res;
> +	const struct of_device_id *of_id;
> +	const struct ahci_platform_data *pdata = NULL;
> +	int ret;
> +
> +	of_id = of_match_device(imx_ahci_of_match, &pdev->dev);
> +	if (of_id)
> +		pdata = of_id->data;
> +	else
> +		return -EINVAL;
> +
> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +	if (!mem || !irq) {
> +		dev_err(dev, "no mmio/irq resource\n");
> +		return -EINVAL;
> +	}
> +
> +	ahci_pdev.dev.coherent_dma_mask = DMA_BIT_MASK(32);
> +	ahci_pdev.dev.dma_mask = &ahci_pdev.dev.coherent_dma_mask;
> +	ahci_pdev.dev.of_node = pdev->dev.of_node;

No need to make ahci_pdev global. platform_device_add_data makes a copy
anyway and making it global makes this driver broken for multiple
instances.

> +
> +	res[0] = mem;
> +	res[1] = irq;

You have an uninitalized pointer to a pointer to struct resource which
you treat as an array here. Doesn't the compiler warn you?

> +	platform_device_add_resources(&ahci_pdev, *res, 2);
> +	platform_device_add_data(&ahci_pdev, pdata, sizeof(*pdata));
> +
> +	ret = platform_device_register(&ahci_pdev);
> +	if (!ret)
> +		return ret;

s/!ret/ret/

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From tglx at linutronix.de  Fri Jul  5 12:05:14 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 5 Jul 2013 18:05:14 +0200 (CEST)
Subject: [PATCH] clocksource/cadence_ttc: Reuse clocksource as sched_clock
In-Reply-To: <fbeb6f36-f07a-4518-b6f2-0b8e36028fe9@CH1EHSMHS012.ehs.local>
References: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>
 <alpine.DEB.2.02.1307050819000.11637@ionos.tec.linutronix.de>
 <fbeb6f36-f07a-4518-b6f2-0b8e36028fe9@CH1EHSMHS012.ehs.local>
Message-ID: <alpine.DEB.2.02.1307051802560.32106@ionos.tec.linutronix.de>

On Fri, 5 Jul 2013, S?ren Brinkmann wrote:
> On Fri, Jul 05, 2013 at 08:30:47AM +0200, Thomas Gleixner wrote:
> > On Wed, 3 Jul 2013, Soren Brinkmann wrote:
> > 
> > > Reuse the TTC clocksource timer as sched clock, too. Since only a single
> > > sched clock is supported in Linux, this feature optional and can be
> > > selected through Kconfig.
> > 
> > This changelog doesn't make sense.
> > 
> > There can be only one active sched_clock, but that does no mean, that
> > you cannot have different implementations compiled in.
> > 
> > So if you disable this config which sched_clock is your kernel using?
> Jiffies
> 
> > And if you enable it, how is guaranteed that you end up with the ttc
> > sched_clock as the active one? Just due to initcall ordering?
> I assumed so. Is there a different mechanism?

jiffies is the default one. If you setup an explicit sched clock then
this is used. initcall ordering only matters if you have two possible
sched clocks which might replace jiffies. The one which gets
registered last wins.

So the question is, why you want to disable your sched clock at
compile time.

Thanks,

	tglx

From soren.brinkmann at xilinx.com  Fri Jul  5 12:12:51 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Fri, 5 Jul 2013 09:12:51 -0700
Subject: [PATCH] clocksource/cadence_ttc: Reuse clocksource as sched_clock
In-Reply-To: <alpine.DEB.2.02.1307051802560.32106@ionos.tec.linutronix.de>
References: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>
 <alpine.DEB.2.02.1307050819000.11637@ionos.tec.linutronix.de>
 <fbeb6f36-f07a-4518-b6f2-0b8e36028fe9@CH1EHSMHS012.ehs.local>
 <alpine.DEB.2.02.1307051802560.32106@ionos.tec.linutronix.de>
Message-ID: <e55e70b7-7e63-4718-ad48-f5d4479b5326@DB9EHSMHS006.ehs.local>

On Fri, Jul 05, 2013 at 06:05:14PM +0200, Thomas Gleixner wrote:
> On Fri, 5 Jul 2013, S?ren Brinkmann wrote:
> > On Fri, Jul 05, 2013 at 08:30:47AM +0200, Thomas Gleixner wrote:
> > > On Wed, 3 Jul 2013, Soren Brinkmann wrote:
> > > 
> > > > Reuse the TTC clocksource timer as sched clock, too. Since only a single
> > > > sched clock is supported in Linux, this feature optional and can be
> > > > selected through Kconfig.
> > > 
> > > This changelog doesn't make sense.
> > > 
> > > There can be only one active sched_clock, but that does no mean, that
> > > you cannot have different implementations compiled in.
> > > 
> > > So if you disable this config which sched_clock is your kernel using?
> > Jiffies
> > 
> > > And if you enable it, how is guaranteed that you end up with the ttc
> > > sched_clock as the active one? Just due to initcall ordering?
> > I assumed so. Is there a different mechanism?
> 
> jiffies is the default one. If you setup an explicit sched clock then
> this is used. initcall ordering only matters if you have two possible
> sched clocks which might replace jiffies. The one which gets
> registered last wins.
> 
> So the question is, why you want to disable your sched clock at
> compile time.
The timer drivers I have seen unconditionally register themselves as
sched_clock. There does not seem to be a runtime mechanism to choose the
best one - I might miss it though.
I was thinking about this due to the arm_global_timer driver which has
been dicussed on lkml recently, which seemed to do it this way too. And since
that timer would be an alternative sched_clock for Zynq too, I thought I
follow the same approach for the TTC.

	S?ren




From tglx at linutronix.de  Fri Jul  5 12:23:19 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 5 Jul 2013 18:23:19 +0200 (CEST)
Subject: [PATCH] clocksource/cadence_ttc: Reuse clocksource as sched_clock
In-Reply-To: <e55e70b7-7e63-4718-ad48-f5d4479b5326@DB9EHSMHS006.ehs.local>
References: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>
 <alpine.DEB.2.02.1307050819000.11637@ionos.tec.linutronix.de>
 <fbeb6f36-f07a-4518-b6f2-0b8e36028fe9@CH1EHSMHS012.ehs.local>
 <alpine.DEB.2.02.1307051802560.32106@ionos.tec.linutronix.de>
 <e55e70b7-7e63-4718-ad48-f5d4479b5326@DB9EHSMHS006.ehs.local>
Message-ID: <alpine.DEB.2.02.1307051819530.32106@ionos.tec.linutronix.de>

On Fri, 5 Jul 2013, S?ren Brinkmann wrote:
> On Fri, Jul 05, 2013 at 06:05:14PM +0200, Thomas Gleixner wrote:
> > On Fri, 5 Jul 2013, S?ren Brinkmann wrote:
> > > On Fri, Jul 05, 2013 at 08:30:47AM +0200, Thomas Gleixner wrote:
> > > > On Wed, 3 Jul 2013, Soren Brinkmann wrote:
> > > > 
> > > > > Reuse the TTC clocksource timer as sched clock, too. Since only a single
> > > > > sched clock is supported in Linux, this feature optional and can be
> > > > > selected through Kconfig.
> > > > 
> > > > This changelog doesn't make sense.
> > > > 
> > > > There can be only one active sched_clock, but that does no mean, that
> > > > you cannot have different implementations compiled in.
> > > > 
> > > > So if you disable this config which sched_clock is your kernel using?
> > > Jiffies
> > > 
> > > > And if you enable it, how is guaranteed that you end up with the ttc
> > > > sched_clock as the active one? Just due to initcall ordering?
> > > I assumed so. Is there a different mechanism?
> > 
> > jiffies is the default one. If you setup an explicit sched clock then
> > this is used. initcall ordering only matters if you have two possible
> > sched clocks which might replace jiffies. The one which gets
> > registered last wins.
> > 
> > So the question is, why you want to disable your sched clock at
> > compile time.
> The timer drivers I have seen unconditionally register themselves as
> sched_clock. There does not seem to be a runtime mechanism to choose the
> best one - I might miss it though.
> I was thinking about this due to the arm_global_timer driver which has
> been dicussed on lkml recently, which seemed to do it this way too. And since
> that timer would be an alternative sched_clock for Zynq too, I thought I
> follow the same approach for the TTC.

Hmm, ok. So there is a generic one as well. If we end up with multiple
choices for that sched_clock, then there should be a mechanism to
avoid that #ifdeffery and have it runtime selected.

Having a setup call with a rating argument would be a first step. So
the one with the highest rating wins. If people want to have it
selectable from the kernel commandline, it would need some string
matching as well.

Thanks,

	tglx

From nicolas.pitre at linaro.org  Fri Jul  5 12:30:07 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 5 Jul 2013 12:30:07 -0400 (EDT)
Subject: kernel decompressor problem for ARMv7
In-Reply-To: <20130705095757.GA13063@mudshark.cambridge.arm.com>
References: <CAF1ivSakn8-HiAf+4_cLRWUUTDP9QBKpAt+hVQoMyAmKZ2-dJA@mail.gmail.com>
 <20130705095757.GA13063@mudshark.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1307051225240.18597@syhkavp.arg>

On Fri, 5 Jul 2013, Will Deacon wrote:

> On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
> > Hi all,
> 
> Hello,
> 
> > I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.
> 
> Which specific processor/SoC?
> 
> > But decompressor doesn't work. With a lot of debug, I finally find
> > below 2 commits related.
> > Kernel uncompress OK with these commits reverted.
> > 
> > dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
> > (Introduced in v3.6-rc6)
> > 
> > 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
> > v6 and above
> > (Introduced in v3.7-rc8)
> > 
> > Any hint to fix it?
> 
> There's not really enough information to go on here. What specifically
> fails? Also, do you have to revert *both* of the above changes to get things
> working again?

Also, what is the bootloader used here?

Does the bootloader call the kernel with the MMU off as documented in 
Documentation/arm/Booting?



Nicolas


From arnd at arndb.de  Fri Jul  5 12:42:44 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Jul 2013 18:42:44 +0200
Subject: scripts/kallsyms: Avoid ARM veneer symbols
In-Reply-To: <20130705145100.GE2932@localhost.localdomain>
References: <2983817.Xe2505Drlj@wuerfel> <201307031803.04501.arnd@arndb.de>
 <20130705145100.GE2932@localhost.localdomain>
Message-ID: <201307051842.44721.arnd@arndb.de>

On Friday 05 July 2013, Dave P Martin wrote:
> On Wed, Jul 03, 2013 at 06:03:04PM +0200, Arnd Bergmann wrote:
> > On Tuesday 25 June 2013, Dave Martin wrote:
> > suggest would significantly increase the build time since the
> > kallsyms+linker stage cannot be done in parallel or sped up
> > using ccache.
> > 
> > > But including the veneer symbols in kallsyms is arguably not all
> > > that useful.
> > > 
> > > The main potential effect is that profiling might occasionally
> > > sample the PC as being in a completely bogus function which it
> > > never passed through at all, because of the way kallsyms tracks
> > > only symbol locations and not sizes (if I remember right) --
> > > so a veneer will actually get accounted against some arbitrary
> > > adjacent function.
> > > 
> > > I don't know how much this matters.
> > 
> > Interesting point. No idea how often that happens. All the veneers
> > for one section are in one place though, so we could in theory
> > add a kallsyms entry for that section as long as can identify
> > it.
> 
> We could collapse any contiguous sequence of __veneer_* symbols down
> to a single symbol to mark those holes.
> 
> However, many kallsyms passes could still be needed: each pass might add
> extra veneer blocks, unless the size of kallsyms data is identical to
> that in the previous pass.  The expected convergence rate is faster,
> though.

Right, it wouldn't guarantee to converge after two passes, just make
it very likely.

> > > > The easiest solution is to skip veneers in kallsyms in the
> > > > same way we already skip a couple of other symbols.
> 
> Your suggestion of omitting the symbols completely seems to be the only
> way to ensure convergence in 2 passes, so far as I can see.
> 
> 
> Adding size information to every entry in kallsyms would make it possible
> to identify the "holes" without potentially requiring many kallsyms passes,
> but it would bloat the table.  The extra info would be interesting only
> for a tiny subset of the symbols.  I expect people aren't going to like
> that much.
> 
> So I guess your original suggestion may be the best thing to do for now,
> after all...
> 
> There is no proper reserved symbol namespace for linker-generated symbols,
> so a real symbol could have the name __*_veneer, at which point things
> start to get really confusing.  But hopefully that won't happen much.
> I don't see any such symbol right now, and hopefully nobody will be so
> silly as to add one...
> 
> If we eventually need to fix the bogus symbol resolution problem, I can't
> see an alternative to adding size info to every symbol.  But we should
> leave that for now.  It doesn't sound like a serious problem.

Unfortunately I have run into additional problems now after doing a few
hundred more builds:

* not all veneers end in _veneer, some also end in _from_arm or _from_thumb.
  This is easy enough to check for in the same way I did for _veneer.

* There are actually symbols without a name on ARM, which screws up the
  kallsyms.c parser. These also seem to be veneers, but attached to some
  random function:

$ nm obj-tmp/.tmp_vmlinux1 | head
c09e8db1 t 
c09e8db5 t 
c09e8db9 t    # <==========
c09e8dbd t 
c0abfc29 t 
c0008000 t $a
c0f7b640 t $a

$ objdump -Dr obj-tmp/.tmp_vmlinux1 | grep -C 30 c09e8db.
c0851fcc <wlc_phy_edcrs_lock>:
c0851fcc:       b538            push    {r3, r4, r5, lr}
c0851fce:       b500            push    {lr}
c0851fd0:       f7bb d8dc       bl      c000d18c <__gnu_mcount_nc>
c0851fd4:       f240 456b       movw    r5, #1131       ; 0x46b
c0851fd8:       4604            mov     r4, r0
c0851fda:       f880 14d5       strb.w  r1, [r0, #1237] ; 0x4d5
c0851fde:       462a            mov     r2, r5
c0851fe0:       f44f 710b       mov.w   r1, #556        ; 0x22c
c0851fe4:       f7ff fe6d       bl      c0851cc2 <write_phy_reg>
c0851fe8:       4620            mov     r0, r4
c0851fea:       462a            mov     r2, r5
c0851fec:       f240 212d       movw    r1, #557        ; 0x22d
c0851ff0:       f7ff fe67       bl      c0851cc2 <write_phy_reg>
c0851ff4:       4620            mov     r0, r4
c0851ff6:       f240 212e       movw    r1, #558        ; 0x22e
c0851ffa:       f44f 7270       mov.w   r2, #960        ; 0x3c0
c0851ffe:       f196 fedb       bl      c09e8db8 <tpci200_free_irq+0x78>  # <===========
c0852002:       4620            mov     r0, r4
c0852004:       f240 212f       movw    r1, #559        ; 0x22f
c0852008:       f44f 7270       mov.w   r2, #960        ; 0x3c0
c085200c:       e8bd 4038       ldmia.w sp!, {r3, r4, r5, lr}
c0852010:       f7ff be57       b.w     c0851cc2 <write_phy_reg>


... # in tpci200_free_irq:
c09e8d9e:       e003            b.n     c09e8da8 <tpci200_free_irq+0x68>
c09e8da0:       f06f 0415       mvn.w   r4, #21
c09e8da4:       e000            b.n     c09e8da8 <tpci200_free_irq+0x68>
c09e8da6:       4c01            ldr     r4, [pc, #4]    ; (c09e8dac <tpci200_free_irq+0x6c>)
c09e8da8:       4620            mov     r0, r4
c09e8daa:       bdf8            pop     {r3, r4, r5, r6, r7, pc}
c09e8dac:       fffffe00                        ; <UNDEFINED> instruction: 0xfffffe00
c09e8db0:       f4cf b814       b.w     c06b7ddc <bna_enet_sm_chld_stop_wait_entry>
c09e8db4:       f53e bed8       b.w     c0727b68 <gem_do_stop>
c09e8db8:       f668 bf83       b.w     c0851cc2 <write_phy_reg>           # <==========
c09e8dbc:       d101            bne.n   c09e8dc2 <tpci200_free_irq+0x82>
c09e8dbe:       f435 b920       b.w     c061e002 <twl_reset_sequence+0x34c>

It makes no sense to me at all that a function in one driver can just call
write_phy_reg a couple of times, but need a veneer in the middle, and put
that veneer in a totally unrelated function in another driver!

If this is a binutils bug or gcc bug, we should probably just fix it, but it
might be easier to work around it by changing kallsyms.c some more.

> > > > -/*
> > > > - * This ignores the intensely annoying "mapping symbols" found
> > > > - * in ARM ELF files: $a, $t and $d.
> > > > - */
> > > >  static inline int is_arm_mapping_symbol(const char *str)
> > > 
> > > The function's name is now wrong.  Should it be renamed or split up?
> > 
> > Sure I can rename it. Any suggestions?
> 
> Maybe just something more generic like is_arm_special_symbol()?

Ok, I can do that.

	Arnd


From minggr at gmail.com  Fri Jul  5 12:52:56 2013
From: minggr at gmail.com (Lin Ming)
Date: Sat, 6 Jul 2013 00:52:56 +0800
Subject: kernel decompressor problem for ARMv7
In-Reply-To: <20130705095757.GA13063@mudshark.cambridge.arm.com>
References: <CAF1ivSakn8-HiAf+4_cLRWUUTDP9QBKpAt+hVQoMyAmKZ2-dJA@mail.gmail.com>
 <20130705095757.GA13063@mudshark.cambridge.arm.com>
Message-ID: <CAF1ivSYzvurfUoM-+UNEhUQz9v5uBbtr20zjv0u6veG1XYoqUA@mail.gmail.com>

On Fri, Jul 5, 2013 at 5:57 PM, Will Deacon <will.deacon at arm.com> wrote:
> On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
>> Hi all,
>
> Hello,
>
>> I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.
>
> Which specific processor/SoC?

Cortex-A9 CPU on Cortina-Systems Baseboard

>
>> But decompressor doesn't work. With a lot of debug, I finally find
>> below 2 commits related.
>> Kernel uncompress OK with these commits reverted.
>>
>> dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
>> (Introduced in v3.6-rc6)
>>
>> 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
>> v6 and above
>> (Introduced in v3.7-rc8)
>>
>> Any hint to fix it?
>
> There's not really enough information to go on here. What specifically
> fails? Also, do you have to revert *both* of the above changes to get things
> working again?

The "fails" is that the decompressor code never get called.
U-Boot prints "Starting kernel", then the board just hang there.

Yes, need to revert *both*.

>
> Cheers,
>
> Will


From broonie at kernel.org  Fri Jul  5 12:52:35 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 5 Jul 2013 17:52:35 +0100
Subject: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to
 control PMIC over VC/VP
In-Reply-To: <51D6DD3A.1030002@ti.com>
References: <1371849949-12649-1-git-send-email-nm@ti.com>
 <1371849949-12649-2-git-send-email-nm@ti.com>
 <20130704154105.GD27646@sirena.org.uk>
 <20130705135507.GA17439@kahuna>
 <20130705140828.GA27646@sirena.org.uk> <51D6DD3A.1030002@ti.com>
Message-ID: <20130705165235.GC27646@sirena.org.uk>

On Fri, Jul 05, 2013 at 09:50:34AM -0500, Nishanth Menon wrote:
> On 07/05/2013 09:08 AM, Mark Brown wrote:

> >>option 1) we just bypass get_voltage/set_voltage to point through to
> >>this function. result will be something similar to what we got here[1]

> >I don't really know what you mean when you say "bypass get_voltage/set_voltage
> >so it's kind of hard to comment...  the link you posted appears to be a
> >link to the code I'm reviewing so it's not terribly enlightening.

> :) it is similar, yes. by bypass get/set_voltage, I mean something like [1]

No, that's not a good idea.

> >What makes you think that the existing regulator drivers need to be
> >modified?

> data path difference - Almost all standard regulators use i2c
> (standard i2c APIs) for every other SMPS/LDO except for the ones
> controlled by OMAP custom i2c path(vc/vp), the
> set_voltage/get_voltage needs a different implementation when it
> comes to using the vc/vp path.

> > They already have all the data exported to the core (or
> > should do)...

> I see that twl-regulator does not indeed do it, but, assuming the
> regulators have all the data exported to the core, the data is
> hidden in struct regulator_desc which is private to the device and
> driver. lets go through these:

That's just a simple matter of programming to fix, and any regulator
which can work with this sort of table based stuff you're looking at
here must also be able to be converted to work with the equivalent code
in the regulator core so open coding is a deficiency in the driver.

> > +	.cmd_reg_addr = 0x00,

> command register is used for sending low power state commands -
> which is not the same as voltage register or vsel_reg as used in
> depicted in regulator_desc.	

There's no information about how to use this register in your
bindings...  but anyway, can't be too hard to add this if it's actually
used.

> > +	.i2c_timeout_us = 200,

> yep, does not match up.

Like I say I just don't see why this is even specified per device.

> > +	.max_uV = 1450000,

> can be used with constraints, but most regulator drivers seem to
> store this internally.

Or just trivially calculate it as we do currently.

> > +	.voltage_selector_offset = 0,
> > +	.voltage_selector_mask = 0x7F,
> > +	.voltage_selector_setbits = 0x0,
> > +	.voltage_selector_zero = false,

> to an extent we can map these to vsel_mask, linear_min_sel etc.
> (again assuming the regulator driver has populated it - most that
> implement custom set_voltage, get_voltage do not do that.

Anything that implements a custom set_voltage() won't work with your
data structure either...

> Other option is to make rdev available to omap_pmic regulator -
> which again implies change in existing regulator driver?

Why would any of the drivers need to change to do this?  They're already
exporting the information.

> >the only thing that's missing is the timeouts and it's
> >not at all obvious why those need to be tuned per device.

> OMAP VC hardware has no idea about how long to wait before giving up
> on an ongoing i2c transaction. This may depend on PMIC and what it
> does before acking on i2c.

So pick a high number (it's only for error cases...)?
-------------- 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/20130705/b856fb33/attachment.sig>

From minggr at gmail.com  Fri Jul  5 12:58:06 2013
From: minggr at gmail.com (Lin Ming)
Date: Sat, 6 Jul 2013 00:58:06 +0800
Subject: kernel decompressor problem for ARMv7
In-Reply-To: <alpine.LFD.2.03.1307051225240.18597@syhkavp.arg>
References: <CAF1ivSakn8-HiAf+4_cLRWUUTDP9QBKpAt+hVQoMyAmKZ2-dJA@mail.gmail.com>
 <20130705095757.GA13063@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1307051225240.18597@syhkavp.arg>
Message-ID: <CAF1ivSbOXknHyDMH3RdmSGK2n5o2wVeR5oohCQnZ2gJrgvo=Hw@mail.gmail.com>

On Sat, Jul 6, 2013 at 12:30 AM, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> On Fri, 5 Jul 2013, Will Deacon wrote:
>
>> On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
>> > Hi all,
>>
>> Hello,
>>
>> > I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.
>>
>> Which specific processor/SoC?
>>
>> > But decompressor doesn't work. With a lot of debug, I finally find
>> > below 2 commits related.
>> > Kernel uncompress OK with these commits reverted.
>> >
>> > dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
>> > (Introduced in v3.6-rc6)
>> >
>> > 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
>> > v6 and above
>> > (Introduced in v3.7-rc8)
>> >
>> > Any hint to fix it?
>>
>> There's not really enough information to go on here. What specifically
>> fails? Also, do you have to revert *both* of the above changes to get things
>> working again?
>
> Also, what is the bootloader used here?

uboot.

>
> Does the bootloader call the kernel with the MMU off as documented in
> Documentation/arm/Booting?

How to check this?

I'll check uboot code or add debug code in boot/compressed/head.S to
check it next Monday.

>
> Nicolas


From Dave.Martin at arm.com  Fri Jul  5 13:26:59 2013
From: Dave.Martin at arm.com (Dave P Martin)
Date: Fri, 5 Jul 2013 18:26:59 +0100
Subject: scripts/kallsyms: Avoid ARM veneer symbols
In-Reply-To: <201307051842.44721.arnd@arndb.de>
References: <2983817.Xe2505Drlj@wuerfel> <201307031803.04501.arnd@arndb.de>
 <20130705145100.GE2932@localhost.localdomain>
 <201307051842.44721.arnd@arndb.de>
Message-ID: <20130705172659.GJ2932@localhost.localdomain>

On Fri, Jul 05, 2013 at 05:42:44PM +0100, Arnd Bergmann wrote:
> On Friday 05 July 2013, Dave P Martin wrote:
> > On Wed, Jul 03, 2013 at 06:03:04PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 25 June 2013, Dave Martin wrote:
> > > suggest would significantly increase the build time since the
> > > kallsyms+linker stage cannot be done in parallel or sped up
> > > using ccache.
> > > 
> > > > But including the veneer symbols in kallsyms is arguably not all
> > > > that useful.
> > > > 
> > > > The main potential effect is that profiling might occasionally
> > > > sample the PC as being in a completely bogus function which it
> > > > never passed through at all, because of the way kallsyms tracks
> > > > only symbol locations and not sizes (if I remember right) --
> > > > so a veneer will actually get accounted against some arbitrary
> > > > adjacent function.
> > > > 
> > > > I don't know how much this matters.
> > > 
> > > Interesting point. No idea how often that happens. All the veneers
> > > for one section are in one place though, so we could in theory
> > > add a kallsyms entry for that section as long as can identify
> > > it.
> > 
> > We could collapse any contiguous sequence of __veneer_* symbols down
> > to a single symbol to mark those holes.
> > 
> > However, many kallsyms passes could still be needed: each pass might add
> > extra veneer blocks, unless the size of kallsyms data is identical to
> > that in the previous pass.  The expected convergence rate is faster,
> > though.
> 
> Right, it wouldn't guarantee to converge after two passes, just make
> it very likely.
> 
> > > > > The easiest solution is to skip veneers in kallsyms in the
> > > > > same way we already skip a couple of other symbols.
> > 
> > Your suggestion of omitting the symbols completely seems to be the only
> > way to ensure convergence in 2 passes, so far as I can see.
> > 
> > 
> > Adding size information to every entry in kallsyms would make it possible
> > to identify the "holes" without potentially requiring many kallsyms passes,
> > but it would bloat the table.  The extra info would be interesting only
> > for a tiny subset of the symbols.  I expect people aren't going to like
> > that much.
> > 
> > So I guess your original suggestion may be the best thing to do for now,
> > after all...
> > 
> > There is no proper reserved symbol namespace for linker-generated symbols,
> > so a real symbol could have the name __*_veneer, at which point things
> > start to get really confusing.  But hopefully that won't happen much.
> > I don't see any such symbol right now, and hopefully nobody will be so
> > silly as to add one...
> > 
> > If we eventually need to fix the bogus symbol resolution problem, I can't
> > see an alternative to adding size info to every symbol.  But we should
> > leave that for now.  It doesn't sound like a serious problem.
> 
> Unfortunately I have run into additional problems now after doing a few
> hundred more builds:
> 
> * not all veneers end in _veneer, some also end in _from_arm or _from_thumb.
>   This is easy enough to check for in the same way I did for _veneer.

I think there are a small number of patterns to check for.

__*_veneer, __*_from_arm and __*_from_thumb should cover most cases.

> * There are actually symbols without a name on ARM, which screws up the
>   kallsyms.c parser. These also seem to be veneers, but attached to some
>   random function:

Hmmm, I don't what those are.  By default, we should probably ignore those
too.  Maybe they have something to do with link-time relocation processing.

> 
> $ nm obj-tmp/.tmp_vmlinux1 | head
> c09e8db1 t 
> c09e8db5 t 
> c09e8db9 t    # <==========
> c09e8dbd t 
> c0abfc29 t 
> c0008000 t $a
> c0f7b640 t $a
> 
> $ objdump -Dr obj-tmp/.tmp_vmlinux1 | grep -C 30 c09e8db.
> c0851fcc <wlc_phy_edcrs_lock>:
> c0851fcc:       b538            push    {r3, r4, r5, lr}
> c0851fce:       b500            push    {lr}
> c0851fd0:       f7bb d8dc       bl      c000d18c <__gnu_mcount_nc>
> c0851fd4:       f240 456b       movw    r5, #1131       ; 0x46b
> c0851fd8:       4604            mov     r4, r0
> c0851fda:       f880 14d5       strb.w  r1, [r0, #1237] ; 0x4d5
> c0851fde:       462a            mov     r2, r5
> c0851fe0:       f44f 710b       mov.w   r1, #556        ; 0x22c
> c0851fe4:       f7ff fe6d       bl      c0851cc2 <write_phy_reg>
> c0851fe8:       4620            mov     r0, r4
> c0851fea:       462a            mov     r2, r5
> c0851fec:       f240 212d       movw    r1, #557        ; 0x22d
> c0851ff0:       f7ff fe67       bl      c0851cc2 <write_phy_reg>
> c0851ff4:       4620            mov     r0, r4
> c0851ff6:       f240 212e       movw    r1, #558        ; 0x22e
> c0851ffa:       f44f 7270       mov.w   r2, #960        ; 0x3c0
> c0851ffe:       f196 fedb       bl      c09e8db8 <tpci200_free_irq+0x78>  # <===========
> c0852002:       4620            mov     r0, r4
> c0852004:       f240 212f       movw    r1, #559        ; 0x22f
> c0852008:       f44f 7270       mov.w   r2, #960        ; 0x3c0
> c085200c:       e8bd 4038       ldmia.w sp!, {r3, r4, r5, lr}
> c0852010:       f7ff be57       b.w     c0851cc2 <write_phy_reg>
> 
> 
> ... # in tpci200_free_irq:
> c09e8d9e:       e003            b.n     c09e8da8 <tpci200_free_irq+0x68>
> c09e8da0:       f06f 0415       mvn.w   r4, #21
> c09e8da4:       e000            b.n     c09e8da8 <tpci200_free_irq+0x68>
> c09e8da6:       4c01            ldr     r4, [pc, #4]    ; (c09e8dac <tpci200_free_irq+0x6c>)
> c09e8da8:       4620            mov     r0, r4
> c09e8daa:       bdf8            pop     {r3, r4, r5, r6, r7, pc}
> c09e8dac:       fffffe00                        ; <UNDEFINED> instruction: 0xfffffe00
> c09e8db0:       f4cf b814       b.w     c06b7ddc <bna_enet_sm_chld_stop_wait_entry>
> c09e8db4:       f53e bed8       b.w     c0727b68 <gem_do_stop>
> c09e8db8:       f668 bf83       b.w     c0851cc2 <write_phy_reg>           # <==========
> c09e8dbc:       d101            bne.n   c09e8dc2 <tpci200_free_irq+0x82>
> c09e8dbe:       f435 b920       b.w     c061e002 <twl_reset_sequence+0x34c>
> 
> It makes no sense to me at all that a function in one driver can just call
> write_phy_reg a couple of times, but need a veneer in the middle, and put
> that veneer in a totally unrelated function in another driver!

I think that if ld inserts a veneer for a function anywhere, branches
from any object in the link to that target symbol can reuse the same
veneer as a trampoline, effectively appearing to branch through an
unrelated location to reach the destination.

ld inserts veneers between individual input sections, but I don't
think they have to go next to the same section the branch originates
from.  In the above code, it looks like that series of unconditional
branches after the end of tpci200_free_irq might be a common veneer pool
for many different destinations.

LTO may also make the expected compilation unit boundaries disappear
completely.  Anything could end up almost anywhere in that case.
Files could get intermingled, inlined and generally spread all over the
place.

Even so, veneers shouldn't be needed in the common case where we're not
jumping across .rodata.

> 
> If this is a binutils bug or gcc bug, we should probably just fix it, but it
> might be easier to work around it by changing kallsyms.c some more.

I haven't found a trivial way to reproduce those nameless symbols.
I don't know whether they're a bug or not...

Making kallsyms robust against this might be a good idea anyway.

> > > > > -/*
> > > > > - * This ignores the intensely annoying "mapping symbols" found
> > > > > - * in ARM ELF files: $a, $t and $d.
> > > > > - */
> > > > >  static inline int is_arm_mapping_symbol(const char *str)
> > > > 
> > > > The function's name is now wrong.  Should it be renamed or split up?
> > > 
> > > Sure I can rename it. Any suggestions?
> > 
> > Maybe just something more generic like is_arm_special_symbol()?
> 
> Ok, I can do that.

Cheers
---Dave


From nm at ti.com  Fri Jul  5 13:33:10 2013
From: nm at ti.com (Nishanth Menon)
Date: Fri, 5 Jul 2013 12:33:10 -0500
Subject: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control
 PMIC over VC/VP
In-Reply-To: <20130705165235.GC27646@sirena.org.uk>
References: <1371849949-12649-1-git-send-email-nm@ti.com>
 <1371849949-12649-2-git-send-email-nm@ti.com>
 <20130704154105.GD27646@sirena.org.uk> <20130705135507.GA17439@kahuna>
 <20130705140828.GA27646@sirena.org.uk> <51D6DD3A.1030002@ti.com>
 <20130705165235.GC27646@sirena.org.uk>
Message-ID: <51D70356.30707@ti.com>

On 07/05/2013 11:52 AM, Mark Brown wrote:
> On Fri, Jul 05, 2013 at 09:50:34AM -0500, Nishanth Menon wrote:
>> On 07/05/2013 09:08 AM, Mark Brown wrote:
>
>>>> option 1) we just bypass get_voltage/set_voltage to point through to
>>>> this function. result will be something similar to what we got here[1]
>
>>> I don't really know what you mean when you say "bypass get_voltage/set_voltage
>>> so it's kind of hard to comment...  the link you posted appears to be a
>>> link to the code I'm reviewing so it's not terribly enlightening.
>
>> :) it is similar, yes. by bypass get/set_voltage, I mean something like [1]
>
> No, that's not a good idea.

I agree.

>
>>> What makes you think that the existing regulator drivers need to be
>>> modified?
>
>> data path difference - Almost all standard regulators use i2c
>> (standard i2c APIs) for every other SMPS/LDO except for the ones
>> controlled by OMAP custom i2c path(vc/vp), the
>> set_voltage/get_voltage needs a different implementation when it
>> comes to using the vc/vp path.
>
>>> They already have all the data exported to the core (or
>>> should do)...
>
>> I see that twl-regulator does not indeed do it, but, assuming the
>> regulators have all the data exported to the core, the data is
>> hidden in struct regulator_desc which is private to the device and
>> driver. lets go through these:
>
> That's just a simple matter of programming to fix, and any regulator
> which can work with this sort of table based stuff you're looking at
> here must also be able to be converted to work with the equivalent code
> in the regulator core so open coding is a deficiency in the driver.

OK, conceptually, I am a bit lost here (may be I thinking about "how the 
heck am I supposed to implement this?") - Hoping for your patience in 
trying to get through to my thick skull :)

Taking an example of twl-regulator and omap_pmic, are you suggesting 
omap_pmic to be a user twl-regulator using 
include/linux/regulator/consumer.h? or are you suggesting that omap_pmic 
should not be a regulator at all?

Could you suggest what you have in your mind here, I can see how we can 
make that happen. I am not averse to writing new code ofcourse.

>
>>> +	.cmd_reg_addr = 0x00,
>
>> command register is used for sending low power state commands -
>> which is not the same as voltage register or vsel_reg as used in
>> depicted in regulator_desc.	
>
> There's no information about how to use this register in your
> bindings...  but anyway, can't be too hard to add this if it's actually
> used.

Yes it is, and also happens to be how OMAPs achieve maximum power 
savings - when low power modes are achieved in OMAP(automatic hardware 
assisted commands are send to the specific command registers in PMIC and 
viceversa on wakeup) - but this also happens to be very specific to OMAP 
way of handling things. I can refer to the Reference Manual as to how it 
actually works, but that'd be an overkill, I will try to expand on the 
bindings a little more, I guess.

>
>>> +	.i2c_timeout_us = 200,
>
>> yep, does not match up.
>
> Like I say I just don't see why this is even specified per device.
>
>>> +	.max_uV = 1450000,
>
>> can be used with constraints, but most regulator drivers seem to
>> store this internally.
>
> Or just trivially calculate it as we do currently.
>
>>> +	.voltage_selector_offset = 0,
>>> +	.voltage_selector_mask = 0x7F,
>>> +	.voltage_selector_setbits = 0x0,
>>> +	.voltage_selector_zero = false,
>
>> to an extent we can map these to vsel_mask, linear_min_sel etc.
>> (again assuming the regulator driver has populated it - most that
>> implement custom set_voltage, get_voltage do not do that.
>
> Anything that implements a custom set_voltage() won't work with your
> data structure either...

It would not work with OMAP either ;). But that said, drivers do freely 
implement custom set_voltage/get_voltage primarily because there are 
ranges in supported voltages that are non-linear and try to be generic 
to work on non-OMAP platforms as well. However, within the supported 
range, only the linear ranges are used with OMAP.

>
>> Other option is to make rdev available to omap_pmic regulator -
>> which again implies change in existing regulator driver?
>
> Why would any of the drivers need to change to do this?  They're already
> exporting the information.
I am thinking here: two regulator drivers, using same rdev/desc for 
getting the data. probably makes no sense, I agree.

>
>>> the only thing that's missing is the timeouts and it's
>>> not at all obvious why those need to be tuned per device.
>
>> OMAP VC hardware has no idea about how long to wait before giving up
>> on an ongoing i2c transaction. This may depend on PMIC and what it
>> does before acking on i2c.
>
> So pick a high number (it's only for error cases...)?
>
from hardware perspective yeah, if it does not lockup (based on erratas 
on specific devices ;) ). it also controls in part, the latency of 
response to Voltage processor from Voltage controller also needed for 
computing SmartReflex latencies (as it should consider worst case 
conditions)

-- 
Regards,
Nishanth Menon


From broonie at kernel.org  Fri Jul  5 13:33:21 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 5 Jul 2013 18:33:21 +0100
Subject: [PATCH] ASoC: Allow imx-pcm-{dma,fiq}.c to be modules
In-Reply-To: <201307051745.16140.arnd@arndb.de>
References: <201307051745.16140.arnd@arndb.de>
Message-ID: <20130705173321.GE27646@sirena.org.uk>

On Fri, Jul 05, 2013 at 05:45:15PM +0200, Arnd Bergmann wrote:
> This is required so we can build the imx sound support
> when ALSA itself is a loadable module.

Is this actually OK with the FIQ APIs?
-------------- 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/20130705/e530bf92/attachment.sig>

From swarren at wwwdotorg.org  Fri Jul  5 13:38:11 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 05 Jul 2013 11:38:11 -0600
Subject: [PATCH 1/2] ARM: dt: t30 cardhu: add dt entry for lm90
In-Reply-To: <1372928979-26938-2-git-send-email-wni@nvidia.com>
References: <1372928979-26938-1-git-send-email-wni@nvidia.com>
 <1372928979-26938-2-git-send-email-wni@nvidia.com>
Message-ID: <51D70483.70203@wwwdotorg.org>

On 07/04/2013 03:09 AM, Wei Ni wrote:
> Enable thermal sensor lm90 for t30 cardhu.

> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi

> +		nct1008: nct1008 {
> +			compatible = "lm90,nct1008";

"lm90" isn't a valid vendor prefix. I believe the value you want is
"onnn,nct1008". Same comment for patch 2/2.


From broonie at kernel.org  Fri Jul  5 13:47:27 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 5 Jul 2013 18:47:27 +0100
Subject: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to
 control PMIC over VC/VP
In-Reply-To: <51D70356.30707@ti.com>
References: <1371849949-12649-1-git-send-email-nm@ti.com>
 <1371849949-12649-2-git-send-email-nm@ti.com>
 <20130704154105.GD27646@sirena.org.uk>
 <20130705135507.GA17439@kahuna>
 <20130705140828.GA27646@sirena.org.uk> <51D6DD3A.1030002@ti.com>
 <20130705165235.GC27646@sirena.org.uk> <51D70356.30707@ti.com>
Message-ID: <20130705174727.GF27646@sirena.org.uk>

On Fri, Jul 05, 2013 at 12:33:10PM -0500, Nishanth Menon wrote:

> Taking an example of twl-regulator and omap_pmic, are you suggesting
> omap_pmic to be a user twl-regulator using
> include/linux/regulator/consumer.h? or are you suggesting that
> omap_pmic should not be a regulator at all?

No, I'm suggesting that omap_pmic find the TWL driver data at runtime
(eg, using the device tree to locate the relevant regulator) and get the
information out of the regulator driver that way.  It can then tell the
hardware about the data that way without having to explictly add every
single regulator both standalone and to the OMAP driver.

> >There's no information about how to use this register in your
> >bindings...  but anyway, can't be too hard to add this if it's actually
> >used.

> Yes it is, and also happens to be how OMAPs achieve maximum power
> savings - when low power modes are achieved in OMAP(automatic
> hardware assisted commands are send to the specific command
> registers in PMIC and viceversa on wakeup) - but this also happens
> to be very specific to OMAP way of handling things. I can refer to
> the Reference Manual as to how it actually works, but that'd be an
> overkill, I will try to expand on the bindings a little more, I
> guess.

OK, so this is a register defined by the OMAP architecture?  I think
it's reasonable to add something to allow this to be obtained to the
core, using a DT property seems yucky since every board usingt this is
going to have to cut'n'paste the value.  Some sort of custom parameter
readback thing perhaps, it doesn't have to be too generic.

> >Anything that implements a custom set_voltage() won't work with your
> >data structure either...

> It would not work with OMAP either ;). But that said, drivers do

Yes, that's kind of my point - as with the code Paul was implementing it
doesn't matter if you can't support every single regualtor since the
hardware design constrains what the regulator can do.  The regualtor
framework already has helpers which factor out the code for anything
which has the limiations the OMAP hardware has (or where it doesn't we
could add them) so there shouldn't be any need for a driver to provide
custom callbacks.

> freely implement custom set_voltage/get_voltage primarily because
> there are ranges in supported voltages that are non-linear and try
> to be generic to work on non-OMAP platforms as well. However, within
> the supported range, only the linear ranges are used with OMAP.

OK, that's a bit more interesting but I expect such regulators will
actually work with the linear ranges helpers I added the other day
(Marvell had a PMIC using them and I realised that the same pattern can
be applied to a bunch of other devices).  Do you think that'd cover the
cases you're aware of?

Another option is for the drivers to provide the data and use the
helpers for their linear ranges as part of a more complex
implementation.

> >>OMAP VC hardware has no idea about how long to wait before giving up
> >>on an ongoing i2c transaction. This may depend on PMIC and what it
> >>does before acking on i2c.

> >So pick a high number (it's only for error cases...)?

> from hardware perspective yeah, if it does not lockup (based on
> erratas on specific devices ;) ). it also controls in part, the
> latency of response to Voltage processor from Voltage controller
> also needed for computing SmartReflex latencies (as it should
> consider worst case conditions)

OK, that's a bit more fun but I think the kernel wants that information
in general anyway since a software cpufreq driver or something might
want to make the same latency decisions.  This is what set_voltage_time() 
is for in part.  But to a first approximation is there really much
variation in the numbers?
-------------- 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/20130705/15e22df1/attachment.sig>

From tj at kernel.org  Fri Jul  5 13:43:05 2013
From: tj at kernel.org (Tejun Heo)
Date: Fri, 5 Jul 2013 10:43:05 -0700
Subject: [v3 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <1373017942-12583-4-git-send-email-Hong-Xing.Zhu@freescale.com>
References: <1373017942-12583-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373017942-12583-4-git-send-email-Hong-Xing.Zhu@freescale.com>
Message-ID: <20130705174305.GA28088@mtj.dyndns.org>

Hello,

On Fri, Jul 05, 2013 at 05:52:22PM +0800, Richard Zhu wrote:
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>  value is '0', should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the
>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>  should be configured regarding to the frequency of AHB
>  bus clock.
>  - Configurations of the AHCI PHY clock, and the signal
>  parameters of the GPR13

Can't you just add a platform specific init callback to ahci_platform?
I don't see how these small differences in init sequence justify a
separate driver.

Thanks.

-- 
tejun


From broonie at kernel.org  Fri Jul  5 14:06:03 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 5 Jul 2013 19:06:03 +0100
Subject: [RFC PATCH 08/13] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <CACQ1gAji8KkjXee8o=9jt8O38611LBJ95yXimxbfn1qLaLOcnA@mail.gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-9-git-send-email-richard.genoud@gmail.com>
 <51D2472B.2010407@atmel.com>
 <CACQ1gAji8KkjXee8o=9jt8O38611LBJ95yXimxbfn1qLaLOcnA@mail.gmail.com>
Message-ID: <20130705180603.GG27646@sirena.org.uk>

On Fri, Jul 05, 2013 at 05:15:05PM +0200, Richard Genoud wrote:
> 2013/7/2 Bo Shen <voice.shen at atmel.com>:

> >> From: Nicolas Ferre <nicolas.ferre at atmel.com>
> >>
> >> Description of the Asoc machine driver for an at91sam9x5 based board
> >> with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
> >> master on the SSC/I2S interface. Its connections are a headphone jack
> >> and an Line input jack.

Always CC relevant maintainers and mailing lists on patches...
-------------- 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/20130705/fb98e36e/attachment.sig>

From richard.genoud at gmail.com  Fri Jul  5 14:12:40 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Fri, 5 Jul 2013 20:12:40 +0200
Subject: [RFC PATCH 08/13] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <20130705180603.GG27646@sirena.org.uk>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-9-git-send-email-richard.genoud@gmail.com>
 <51D2472B.2010407@atmel.com>
 <CACQ1gAji8KkjXee8o=9jt8O38611LBJ95yXimxbfn1qLaLOcnA@mail.gmail.com>
 <20130705180603.GG27646@sirena.org.uk>
Message-ID: <CACQ1gAjCEta_E2XyGmfLWwNi4ff14HHwUPDFPbL4Fhcc_hnRsQ@mail.gmail.com>

2013/7/5 Mark Brown <broonie at kernel.org>:
> On Fri, Jul 05, 2013 at 05:15:05PM +0200, Richard Genoud wrote:
>> 2013/7/2 Bo Shen <voice.shen at atmel.com>:
>
>> >> From: Nicolas Ferre <nicolas.ferre at atmel.com>
>> >>
>> >> Description of the Asoc machine driver for an at91sam9x5 based board
>> >> with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
>> >> master on the SSC/I2S interface. Its connections are a headphone jack
>> >> and an Line input jack.
>
> Always CC relevant maintainers and mailing lists on patches...
Sorry Mark, I'll double check that on the next version.

Thanks !

Best Regards,
Richard.


From swarren at wwwdotorg.org  Fri Jul  5 14:10:55 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri,  5 Jul 2013 12:10:55 -0600
Subject: [PATCH V3] ARM: add missing linker section markup to head-common.S
Message-ID: <1373047855-24145-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Macro __INIT is used to place various code in head-common.S into the init
section. This should be matched by a closing __FINIT. Also, add an
explicit ".text" to ensure subsequent code is placed into the correct
section; __FINIT is simply a closing marker to match __INIT and doesn't
guarantee to revert to .text.

This historically caused no problem, because macro __CPUINIT was used at
the exact location where __FINIT was missing, which then placed following
code into the cpuinit section. However, with commit 22f0a2736 "init.h:
remove __cpuinit sections from the kernel" applied, __CPUINIT becomes a
no-op, thus leaving all this code in the init section, rather than the
regular text section. This caused issues such as secondary CPU boot
failures or crashes.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
Acked-by: Paul Gortmaker <paul.gortmaker at windriver.com>
---
v3: Added .text after __FINIT to force the correct section.
v2: Moved __FINIT after lookup_processor_type, to correctly match the
location of __CPUINIT.
---
 arch/arm/kernel/head-common.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
index 529ce99..47cd974 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -133,6 +133,9 @@ ENTRY(lookup_processor_type)
 	ldmfd	sp!, {r4 - r6, r9, pc}
 ENDPROC(lookup_processor_type)
 
+	__FINIT
+	.text
+
 /*
  * Read processor ID register (CP#15, CR0), and look up in the linker-built
  * supported processor list.  Note that we can't use the absolute addresses
-- 
1.8.1.5



From swarren at wwwdotorg.org  Fri Jul  5 14:36:11 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 05 Jul 2013 12:36:11 -0600
Subject: Appended DTB files for multi-machine kernels
In-Reply-To: <51D5A938.30607@gmail.com>
References: <51D5A938.30607@gmail.com>
Message-ID: <51D7121B.50704@wwwdotorg.org>

On 07/04/2013 10:56 AM, Daniel Mack wrote:
...
> The built-in support for attaching a DTB to the zImage does not suffice
> here, because we have one image for all models, and also, we couldn't do
> a 'per-board-revision' selection that way either.
...
> As a solution, I'm thinking of a small framework that could for example
> work as follows.
> 
> a) A small mechanism allows storing multiple DTB binary files inside the
> kernel binary at compile time...
...
> c) Allow users to open-code the DTB lookup depending on whatever kind of
> runtime information (be it the board_revision or anything else).

The problem with (c) is that in general it probably requires a lot of
infra-structure to be working to implement it. On Tegra, the board
revision is in an EEPROM attached to an I2C bus. You'd need to have
parsed DT and started instantiating devices already before you could
access the ID EEPROM to know which board revision you're running on.
That's a bit of a chicked-and-egg problem. Even with a much simpler
scheme such as board ID encoded into GPIOs, you'll still likely run into
similar problems; pinmux and GPIO controller drivers are needed just to
read the GPIOs, which then requires DT to instantiate those drivers.

So, the suggestion of Nicolas's that you mentioned does solve that
rather neatly.


From swarren at wwwdotorg.org  Fri Jul  5 14:43:05 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 05 Jul 2013 12:43:05 -0600
Subject: [PATCH] ARM: tegra: enable gpio-keys on dalmore
In-Reply-To: <1373028111-24246-1-git-send-email-ldewangan@nvidia.com>
References: <1373028111-24246-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <51D713B9.40205@wwwdotorg.org>

On 07/05/2013 06:41 AM, Laxman Dewangan wrote:
> Dalmore have the keys mounted on board which are connected
> to different pins of Tegra.
> 
> Add the keys entry in DTS file to enable key functionality.
> This will enable KEY_POWER, KEY_HOME, KEY_VOLUMEUP and
> KEY_VOLUMEDOWN.

> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts

>  			 <&tegra_car TEGRA114_CLK_EXTERN1>;
>  		clock-names = "pll_a", "pll_a_out0", "mclk";
>  	};
> +
> +	gpio-keys {

The node above is "sound". This node should be before that node so
they're alphabetically sorted.

> +		compatible = "gpio-keys";
> +
> +		power {
> +			label = "Power";
> +			gpios = <&gpio TEGRA_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
> +			linux,code = <116>; /* KEY_POWER */
> +			gpio-key,wakeup;
> +		};
> +
> +		home {

Similarly, the nodes inside gpio-keys should also be sorted alphabetically.


From lauraa at codeaurora.org  Fri Jul  5 15:33:21 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Fri, 05 Jul 2013 12:33:21 -0700
Subject: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is
 64-bits
In-Reply-To: <CACVXFVPfkqP+UyoGd-+QFRzndSam_DtU=utrBPYCPjQCGQ_F6g@mail.gmail.com>
References: <1367008266-1431-1-git-send-email-lauraa@codeaurora.org>
 <517AF270.8040106@gmail.com>
 <CACVXFVPfkqP+UyoGd-+QFRzndSam_DtU=utrBPYCPjQCGQ_F6g@mail.gmail.com>
Message-ID: <51D71F81.5090503@codeaurora.org>

On 7/3/2013 7:15 AM, Ming Lei wrote:
> On Sat, Apr 27, 2013 at 5:32 AM, Rob Herring <robherring2 at gmail.com> wrote:
>> On 04/26/2013 03:31 PM, Laura Abbott wrote:
>>> Currently, of_platform_device_create_pdata always sets the
>>> coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA,
>>> arm_dma_limit gets set to ~0 or 0xFFFFFFFFFFFFFFFF on LPAE based
>>> systems. Since arm_dma_limit represents the smallest dma_mask
>>> on the system, the default of 32 bits prevents any dma_coherent
>>> allocation from succeeding unless clients manually set the
>>> dma mask first. Rather than make every client on an LPAE system set
>>> the mask manually, account for the size of dma_addr_t when setting
>>> the coherent mask.
>>>
>>> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
>>> ---
>>>   drivers/of/platform.c |    2 +-
>>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>>> index 0970505..5f0ba94 100644
>>> --- a/drivers/of/platform.c
>>> +++ b/drivers/of/platform.c
>>> @@ -214,7 +214,7 @@ struct platform_device *of_platform_device_create_pdata(
>>>   #if defined(CONFIG_MICROBLAZE)
>>>        dev->archdata.dma_mask = 0xffffffffUL;
>>>   #endif
>>> -     dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>>> +     dev->dev.coherent_dma_mask = DMA_BIT_MASK(sizeof(dma_addr_t) * 8);
>>
>> This is going to change the mask from 32 to 64 bits on 64-bit powerpc
>> and others possibly. Maybe it doesn't matter. I think it doesn't, but
>> I'm not sure enough to apply for 3.10. So I'll queue it for 3.11.
>
> Without the patch, LPAE enabled board may not boot at all, but looks
> it still isn't in -next tree.
>
> But I am wondering if it is a correct approach, because enabling LPAE
> doesn't mean the I/O devices can support DMA to/from 64bit address, and
> it is very probably devices can't do it at all.
>

The problem is the way the arm_dma_limit is set up, all dma allocations 
are currently broken regardless of if the actual device supports 64-bit 
addresses or not.

> Another way is to always set arm_dma_limit as 0xFFFFFFFF when
> CONFIG_ZONE_DMA is unset, and let driver override device's dma
> mask if the device supports 64bit DMA.
>

I previously asked about the arm_dma_limit and was told that the current 
behavior is the correct approach (see 
https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-April/032729.html 
and 
https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-April/032690.html) 


The point here is to set the mask to something reasonable such that 
allocations can succeed by default. If devices can't use part of the 
memory space they can adjust the limit accordingly.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From maxime.ripard at free-electrons.com  Fri Jul  5 15:34:29 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri,  5 Jul 2013 21:34:29 +0200
Subject: [PATCHv3 02/10] clocksource: sun4i: Wrap macros arguments in
 parenthesis
In-Reply-To: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373052877-29366-3-git-send-email-maxime.ripard@free-electrons.com>

The macros were not using parenthesis to escape the arguments passed to
them. It is pretty unsafe, so add those parenthesis.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index bdf34d9..34ab658 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -30,8 +30,8 @@
 #define TIMER_CTL_ENABLE		BIT(0)
 #define TIMER_CTL_AUTORELOAD		BIT(1)
 #define TIMER_CTL_ONESHOT		BIT(7)
-#define TIMER_INTVAL_REG(val)	(0x10 * val + 0x14)
-#define TIMER_CNTVAL_REG(val)	(0x10 * val + 0x18)
+#define TIMER_INTVAL_REG(val)	(0x10 * (val) + 0x14)
+#define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
 
 #define TIMER_SCAL		16
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 15:34:31 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri,  5 Jul 2013 21:34:31 +0200
Subject: [PATCHv3 04/10] clocksource: sun4i: Add clocksource and sched clock
 drivers
In-Reply-To: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373052877-29366-5-git-send-email-maxime.ripard@free-electrons.com>

Use the second timer found on the Allwinner SoCs as a clock source and
sched clock, that were both not used yet on these platforms.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index f5e227b..224c855 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -19,6 +19,7 @@
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/irqreturn.h>
+#include <linux/sched_clock.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
@@ -96,6 +97,11 @@ static struct irqaction sun4i_timer_irq = {
 	.dev_id = &sun4i_clockevent,
 };
 
+static u32 sun4i_timer_sched_read(void)
+{
+	return ~readl(timer_base + TIMER_CNTVAL_REG(1));
+}
+
 static void __init sun4i_timer_init(struct device_node *node)
 {
 	unsigned long rate = 0;
@@ -117,6 +123,16 @@ static void __init sun4i_timer_init(struct device_node *node)
 
 	rate = clk_get_rate(clk);
 
+	writel(~0, timer_base + TIMER_INTVAL_REG(1));
+	writel(TIMER_CTL_ENABLE | TIMER_CTL_RELOAD |
+	       TIMER_CTL_CLK_SRC(TIMER_CTL_CLK_SRC_OSC24M),
+	       timer_base + TIMER_CTL_REG(1));
+
+	setup_sched_clock(sun4i_timer_sched_read, 32, clk_get_rate(clk));
+	clocksource_mmio_init(timer_base + TIMER_CNTVAL_REG(1), node->name,
+			      clk_get_rate(clk), 300, 32,
+			      clocksource_mmio_readl_down);
+
 	writel(rate / (TIMER_SCAL * HZ),
 	       timer_base + TIMER_INTVAL_REG(0));
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 15:34:28 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri,  5 Jul 2013 21:34:28 +0200
Subject: [PATCHv3 01/10] clocksource: sun4i: Use the BIT macros where possible
In-Reply-To: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373052877-29366-2-git-send-email-maxime.ripard@free-electrons.com>

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index d4674e7..bdf34d9 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -24,12 +24,12 @@
 #include <linux/of_irq.h>
 
 #define TIMER_IRQ_EN_REG	0x00
-#define TIMER_IRQ_EN(val)		(1 << val)
+#define TIMER_IRQ_EN(val)		BIT(val)
 #define TIMER_IRQ_ST_REG	0x04
 #define TIMER_CTL_REG(val)	(0x10 * val + 0x10)
-#define TIMER_CTL_ENABLE		(1 << 0)
-#define TIMER_CTL_AUTORELOAD		(1 << 1)
-#define TIMER_CTL_ONESHOT		(1 << 7)
+#define TIMER_CTL_ENABLE		BIT(0)
+#define TIMER_CTL_AUTORELOAD		BIT(1)
+#define TIMER_CTL_ONESHOT		BIT(7)
 #define TIMER_INTVAL_REG(val)	(0x10 * val + 0x14)
 #define TIMER_CNTVAL_REG(val)	(0x10 * val + 0x18)
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 15:34:27 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri,  5 Jul 2013 21:34:27 +0200
Subject: [PATCHv3 00/10] clocksource: sunxi: Timer fixes and cleanup
Message-ID: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>

Hi everyone,

The first timer code we merged when adding support for the A13 some
time back was mostly a clean up from the source drop we had, without
any documentation.  This happened to work, but the code merged in
turned out to be far from perfect, and had several flaws.

This patchset hopefully fixes these flaws, and cleanup most of the
driver as well, to end up in an almost complete rewrite of it (even
though it's not that long).

It also finally adds a clocksource from the free running counter found
in the A10/A13 SoCs.

These flaws have all been spotted when trying to add the A31 support,
work that is still ongoing, but will hopefully benefit from this
patchset as well.

Thanks,
Maxime

Changes from v2:
  - Use the clocksource timer to get the amount of time we have to
    wait for when disabling and enabling back a timer
  - Added patch to add parenthesis around the macros arguments
  - Renamed the AUTORELOAD register define to the more meaningful
    RELOAD name

Changes from v1:
  - Rebased on top of linux-next to benefit from the move to all
    architectures of the sched_clock functions
  - Moved the clock source to the second timer instead of the 64 bits
    free-running counter like suggested by Thomas.

Maxime Ripard (10):
  clocksource: sun4i: Use the BIT macros where possible
  clocksource: sun4i: Wrap macros arguments in parenthesis
  clocksource: sun4i: rename AUTORELOAD define to RELOAD
  clocksource: sun4i: Add clocksource and sched clock drivers
  clocksource: sun4i: Don't forget to enable the clock we use
  clocksource: sun4i: Fix the next event code
  clocksource: sun4i: Factor out some timer code
  clocksource: sun4i: Remove TIMER_SCAL variable
  clocksource: sun4i: Cleanup parent clock setup
  clocksource: sun4i: Fix bug when switching from periodic to oneshot
    modes

 drivers/clocksource/sun4i_timer.c | 113 +++++++++++++++++++++++++++-----------
 1 file changed, 80 insertions(+), 33 deletions(-)

-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 15:34:30 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri,  5 Jul 2013 21:34:30 +0200
Subject: [PATCHv3 03/10] clocksource: sun4i: rename AUTORELOAD define to RELOAD
In-Reply-To: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373052877-29366-4-git-send-email-maxime.ripard@free-electrons.com>

The name AUTORELOAD was actually pretty bad since it doesn't make the
register reload the previous interval when it expires, but setting this
value pushes the new programmed interval to the internal timer counter.
Rename it to RELOAD instead.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 34ab658..f5e227b 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -28,7 +28,7 @@
 #define TIMER_IRQ_ST_REG	0x04
 #define TIMER_CTL_REG(val)	(0x10 * val + 0x10)
 #define TIMER_CTL_ENABLE		BIT(0)
-#define TIMER_CTL_AUTORELOAD		BIT(1)
+#define TIMER_CTL_RELOAD		BIT(1)
 #define TIMER_CTL_ONESHOT		BIT(7)
 #define TIMER_INTVAL_REG(val)	(0x10 * (val) + 0x14)
 #define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
@@ -129,7 +129,7 @@ static void __init sun4i_timer_init(struct device_node *node)
 
 	/* set mode to auto reload */
 	val = readl(timer_base + TIMER_CTL_REG(0));
-	writel(val | TIMER_CTL_AUTORELOAD, timer_base + TIMER_CTL_REG(0));
+	writel(val | TIMER_CTL_RELOAD, timer_base + TIMER_CTL_REG(0));
 
 	ret = setup_irq(irq, &sun4i_timer_irq);
 	if (ret)
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 15:34:36 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri,  5 Jul 2013 21:34:36 +0200
Subject: [PATCHv3 09/10] clocksource: sun4i: Cleanup parent clock setup
In-Reply-To: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373052877-29366-10-git-send-email-maxime.ripard@free-electrons.com>

The current bring-up code for the timer was overly complicated. The only
thing we need is actually which clock we want to use as source and
that's pretty much all. Let's keep it that way.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 2f84075..581e903 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -30,6 +30,9 @@
 #define TIMER_CTL_REG(val)	(0x10 * val + 0x10)
 #define TIMER_CTL_ENABLE		BIT(0)
 #define TIMER_CTL_RELOAD		BIT(1)
+#define TIMER_CTL_CLK_SRC(val)		(((val) & 0x3) << 2)
+#define TIMER_CTL_CLK_SRC_OSC24M		(1)
+#define TIMER_CTL_CLK_PRES(val)		(((val) & 0x7) << 4)
 #define TIMER_CTL_ONESHOT		BIT(7)
 #define TIMER_INTVAL_REG(val)	(0x10 * (val) + 0x14)
 #define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
@@ -167,16 +170,8 @@ static void __init sun4i_timer_init(struct device_node *node)
 	writel(clk_get_rate(clk) / HZ,
 	       timer_base + TIMER_INTVAL_REG(0));
 
-	/* set clock source to HOSC, 16 pre-division */
-	val = readl(timer_base + TIMER_CTL_REG(0));
-	val &= ~(0x07 << 4);
-	val &= ~(0x03 << 2);
-	val |= (4 << 4) | (1 << 2);
-	writel(val, timer_base + TIMER_CTL_REG(0));
-
-	/* set mode to auto reload */
-	val = readl(timer_base + TIMER_CTL_REG(0));
-	writel(val | TIMER_CTL_RELOAD, timer_base + TIMER_CTL_REG(0));
+	writel(TIMER_CTL_CLK_SRC(TIMER_CTL_CLK_SRC_OSC24M) | TIMER_CTL_RELOAD,
+	       timer_base + TIMER_CTL_REG(0));
 
 	ret = setup_irq(irq, &sun4i_timer_irq);
 	if (ret)
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 15:34:32 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri,  5 Jul 2013 21:34:32 +0200
Subject: [PATCHv3 05/10] clocksource: sun4i: Don't forget to enable the clock
 we use
In-Reply-To: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373052877-29366-6-git-send-email-maxime.ripard@free-electrons.com>

Even if in our case, this clock was non-gatable, used as a parent clock
for several IPs, it still is a good idea to enable it.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 224c855..7c79968 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -120,6 +120,7 @@ static void __init sun4i_timer_init(struct device_node *node)
 	clk = of_clk_get(node, 0);
 	if (IS_ERR(clk))
 		panic("Can't get timer clock");
+	clk_prepare_enable(clk);
 
 	rate = clk_get_rate(clk);
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 15:34:37 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri,  5 Jul 2013 21:34:37 +0200
Subject: [PATCHv3 10/10] clocksource: sun4i: Fix bug when switching from
 periodic to oneshot modes
In-Reply-To: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373052877-29366-11-git-send-email-maxime.ripard@free-electrons.com>

The interval was firing at was set up at probe time, and only changed in
the set_next_event, and never changed back, which is not really what is
expected.

When enabling the periodic mode, now set an interval to tick every
jiffy.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 581e903..2b7cc31 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -38,6 +38,7 @@
 #define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
 
 static void __iomem *timer_base;
+static u32 ticks_per_jiffy;
 
 /*
  * When we disable a timer, we need to wait at least for 2 cycles of
@@ -74,7 +75,8 @@ static void sun4i_clkevt_time_start(u8 timer, bool periodic)
 	else
 		val |= TIMER_CTL_ONESHOT;
 
-	writel(val | TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(timer));
+	writel(val | TIMER_CTL_ENABLE | TIMER_CTL_RELOAD,
+	       timer_base + TIMER_CTL_REG(timer));
 }
 
 static void sun4i_clkevt_mode(enum clock_event_mode mode,
@@ -83,6 +85,7 @@ static void sun4i_clkevt_mode(enum clock_event_mode mode,
 	switch (mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
 		sun4i_clkevt_time_stop(0);
+		sun4i_clkevt_time_setup(0, ticks_per_jiffy);
 		sun4i_clkevt_time_start(0, true);
 		break;
 	case CLOCK_EVT_MODE_ONESHOT:
@@ -170,7 +173,9 @@ static void __init sun4i_timer_init(struct device_node *node)
 	writel(clk_get_rate(clk) / HZ,
 	       timer_base + TIMER_INTVAL_REG(0));
 
-	writel(TIMER_CTL_CLK_SRC(TIMER_CTL_CLK_SRC_OSC24M) | TIMER_CTL_RELOAD,
+	ticks_per_jiffy = DIV_ROUND_UP(clk_get_rate(clk), HZ);
+
+	writel(TIMER_CTL_CLK_SRC(TIMER_CTL_CLK_SRC_OSC24M),
 	       timer_base + TIMER_CTL_REG(0));
 
 	ret = setup_irq(irq, &sun4i_timer_irq);
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 15:34:33 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri,  5 Jul 2013 21:34:33 +0200
Subject: [PATCHv3 06/10] clocksource: sun4i: Fix the next event code
In-Reply-To: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373052877-29366-7-git-send-email-maxime.ripard@free-electrons.com>

The next_event logic was setting the next interval to fire in the
current timer value instead of the interval value register, which is
obviously wrong.

Plus, the logic to set the actual value was wrong as well: the interval
register can only be modified when the timer is disabled, and then
enable it back, otherwise, it'll have no effect. Fix this logic as well
since that code couldn't possibly work.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 7c79968..6938cf9 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -38,6 +38,20 @@
 
 static void __iomem *timer_base;
 
+/*
+ * When we disable a timer, we need to wait at least for 2 cycles of
+ * the timer source clock. We will use for that the clocksource timer
+ * that is already setup and runs at the same frequency than the other
+ * timers, and we never will be disabled.
+ */
+static void sun4i_clkevt_sync(void)
+{
+	u32 old = readl(timer_base + TIMER_CNTVAL_REG(1));
+
+	while ((old - readl(timer_base + TIMER_CNTVAL_REG(1))) < 3)
+		cpu_relax();
+}
+
 static void sun4i_clkevt_mode(enum clock_event_mode mode,
 			      struct clock_event_device *clk)
 {
@@ -63,9 +77,14 @@ static void sun4i_clkevt_mode(enum clock_event_mode mode,
 static int sun4i_clkevt_next_event(unsigned long evt,
 				   struct clock_event_device *unused)
 {
-	u32 u = readl(timer_base + TIMER_CTL_REG(0));
-	writel(evt, timer_base + TIMER_CNTVAL_REG(0));
-	writel(u | TIMER_CTL_ENABLE | TIMER_CTL_AUTORELOAD,
+	u32 val = readl(timer_base + TIMER_CTL_REG(0));
+	writel(val & ~TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(0));
+	sun4i_clkevt_sync();
+
+	writel(evt, timer_base + TIMER_INTVAL_REG(0));
+
+	val = readl(timer_base + TIMER_CTL_REG(0));
+	writel(val | TIMER_CTL_ENABLE | TIMER_CTL_AUTORELOAD,
 	       timer_base + TIMER_CTL_REG(0));
 
 	return 0;
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 15:34:35 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri,  5 Jul 2013 21:34:35 +0200
Subject: [PATCHv3 08/10] clocksource: sun4i: Remove TIMER_SCAL variable
In-Reply-To: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373052877-29366-9-git-send-email-maxime.ripard@free-electrons.com>

The prescaler is only used when using the internal low frequency
oscillator (at 32kHz). Since we're using the higher frequency oscillator
at 24MHz, we can just remove it.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 00e17d9..2f84075 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -34,8 +34,6 @@
 #define TIMER_INTVAL_REG(val)	(0x10 * (val) + 0x14)
 #define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
 
-#define TIMER_SCAL		16
-
 static void __iomem *timer_base;
 
 /*
@@ -139,7 +137,6 @@ static u32 sun4i_timer_sched_read(void)
 
 static void __init sun4i_timer_init(struct device_node *node)
 {
-	unsigned long rate = 0;
 	struct clk *clk;
 	int ret, irq;
 	u32 val;
@@ -157,8 +154,6 @@ static void __init sun4i_timer_init(struct device_node *node)
 		panic("Can't get timer clock");
 	clk_prepare_enable(clk);
 
-	rate = clk_get_rate(clk);
-
 	writel(~0, timer_base + TIMER_INTVAL_REG(1));
 	writel(TIMER_CTL_ENABLE | TIMER_CTL_RELOAD |
 	       TIMER_CTL_CLK_SRC(TIMER_CTL_CLK_SRC_OSC24M),
@@ -169,7 +164,7 @@ static void __init sun4i_timer_init(struct device_node *node)
 			      clk_get_rate(clk), 300, 32,
 			      clocksource_mmio_readl_down);
 
-	writel(rate / (TIMER_SCAL * HZ),
+	writel(clk_get_rate(clk) / HZ,
 	       timer_base + TIMER_INTVAL_REG(0));
 
 	/* set clock source to HOSC, 16 pre-division */
@@ -193,8 +188,8 @@ static void __init sun4i_timer_init(struct device_node *node)
 
 	sun4i_clockevent.cpumask = cpumask_of(0);
 
-	clockevents_config_and_register(&sun4i_clockevent, rate / TIMER_SCAL,
-					0x1, 0xff);
+	clockevents_config_and_register(&sun4i_clockevent, clk_get_rate(clk),
+					0x1, 0xffffffff);
 }
 CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-timer",
 		       sun4i_timer_init);
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 15:34:34 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri,  5 Jul 2013 21:34:34 +0200
Subject: [PATCHv3 07/10] clocksource: sun4i: Factor out some timer code
In-Reply-To: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373052877-29366-8-git-send-email-maxime.ripard@free-electrons.com>

The set_next_event and set_mode callbacks share a lot of common code we
can easily factor to avoid duplication and mistakes.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 48 ++++++++++++++++++++++++++-------------
 1 file changed, 32 insertions(+), 16 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 6938cf9..00e17d9 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -52,24 +52,46 @@ static void sun4i_clkevt_sync(void)
 		cpu_relax();
 }
 
+static void sun4i_clkevt_time_stop(u8 timer)
+{
+	u32 val = readl(timer_base + TIMER_CTL_REG(timer));
+	writel(val & ~TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(timer));
+	sun4i_clkevt_sync();
+}
+
+static void sun4i_clkevt_time_setup(u8 timer, unsigned long delay)
+{
+	writel(delay, timer_base + TIMER_INTVAL_REG(timer));
+}
+
+static void sun4i_clkevt_time_start(u8 timer, bool periodic)
+{
+	u32 val = readl(timer_base + TIMER_CTL_REG(timer));
+
+	if (periodic)
+		val &= ~TIMER_CTL_ONESHOT;
+	else
+		val |= TIMER_CTL_ONESHOT;
+
+	writel(val | TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(timer));
+}
+
 static void sun4i_clkevt_mode(enum clock_event_mode mode,
 			      struct clock_event_device *clk)
 {
-	u32 u = readl(timer_base + TIMER_CTL_REG(0));
-
 	switch (mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
-		u &= ~(TIMER_CTL_ONESHOT);
-		writel(u | TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(0));
+		sun4i_clkevt_time_stop(0);
+		sun4i_clkevt_time_start(0, true);
 		break;
-
 	case CLOCK_EVT_MODE_ONESHOT:
-		writel(u | TIMER_CTL_ONESHOT, timer_base + TIMER_CTL_REG(0));
+		sun4i_clkevt_time_stop(0);
+		sun4i_clkevt_time_start(0, false);
 		break;
 	case CLOCK_EVT_MODE_UNUSED:
 	case CLOCK_EVT_MODE_SHUTDOWN:
 	default:
-		writel(u & ~(TIMER_CTL_ENABLE), timer_base + TIMER_CTL_REG(0));
+		sun4i_clkevt_time_stop(0);
 		break;
 	}
 }
@@ -77,15 +99,9 @@ static void sun4i_clkevt_mode(enum clock_event_mode mode,
 static int sun4i_clkevt_next_event(unsigned long evt,
 				   struct clock_event_device *unused)
 {
-	u32 val = readl(timer_base + TIMER_CTL_REG(0));
-	writel(val & ~TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(0));
-	sun4i_clkevt_sync();
-
-	writel(evt, timer_base + TIMER_INTVAL_REG(0));
-
-	val = readl(timer_base + TIMER_CTL_REG(0));
-	writel(val | TIMER_CTL_ENABLE | TIMER_CTL_AUTORELOAD,
-	       timer_base + TIMER_CTL_REG(0));
+	sun4i_clkevt_time_stop(0);
+	sun4i_clkevt_time_setup(0, evt);
+	sun4i_clkevt_time_start(0, false);
 
 	return 0;
 }
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 16:11:18 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 5 Jul 2013 22:11:18 +0200
Subject: MTD EEPROM support and driver integration
Message-ID: <20130705201118.GM2959@lukather>

Hi everyone,

In the last weeks, we've drivers coming up both about mostly some very
simple drivers that expose to the userspace a few bytes of memory-mapped
IO. Both will probably live under drivers/misc/eeprom, where there's
support already for other kind of what could be assimilated as eeproms
(AT24, AT25, etc.).

Now, besides the code duplication every driver has to make to register
the sysfs attributes, it wouldn't cause much of a problem.

Except that these EEPROMs could store values useful for other drivers in
Linux. For example:
  - imx28 OCOTP (the latest of the two EEPROM drivers recently submitted)
    use it most of the time to store its MAC addresses
  - Allwinner SoCs SID (the other latest driver submitted) use it
    sometime to store a MAC address, and also the SoC ID, which could be
    useful to implement a SoC bus driver.
  - Some Allwinner boards (and presumably others) use an AT24 to store
    the MAC address in it.

For now, everyone comes up with a different solution:
  - imx28 has a hook in mach-mxs to patch the device tree at runtime and
    add the values retrieved from the OCOTP to it.
  - AT24 seem to have some function exported (at24_macc_(read|write)) so
    that other part of the kernel can use them to retrieve values from
    such an EEPROM.
  - Allwinner SoCs have, well, basically nothing for now, which is why I
    send this email.

The current way of working has several flaws imho:
  - The code is heavily duplicated: the sysfs registering is common to
    every driver, and at the end of the day, every driver should only
    give a read/write callback, and that's it.
  - The "consumer" drivers should not have to worry at all about the
    EEPROM type it should retrieve the needed value from, let alone
    dealing with the number of instances of such an EEPROM.

To solve this issues, I think I have some solution. Would merging this
drivers into MTD make some sense? It seems like there is already some
EEPROM drivers into drivers/mtd (such as an AT25 one, which also have a
drivers under drivers/misc/eeprom), so I guess it does, but I'd like to
have your opinion on this.

If so, would some kind of MTD in-kernel API to retrieve values from MTD
devices would be acceptable to you? I mostly have DT in mind, so I'm
thinking of having DT bindings to that API such as

  mac-storage = <&phandle 0xoffset 0xsize>

to describe which device to get a value from, and where in that device.

That would allow consumer drivers to only have to call a function like
of_mtd_get_value and let the MTD subsystem do the hard work.

What's your feeling on this?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130705/e03fd15a/attachment.sig>

From soren.brinkmann at xilinx.com  Fri Jul  5 16:12:37 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Fri, 5 Jul 2013 13:12:37 -0700
Subject: [PATCH] clocksource/cadence_ttc: Reuse clocksource as sched_clock
In-Reply-To: <20130704033026.GX4288@tarshish>
References: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>
 <20130704033026.GX4288@tarshish>
Message-ID: <0030b826-0eb1-4bb8-a0de-1d8dc68bd81a@TX2EHSMHS017.ehs.local>

On Thu, Jul 04, 2013 at 06:30:26AM +0300, Baruch Siach wrote:
> Hi Soren,
> 
> On Wed, Jul 03, 2013 at 02:50:16PM -0700, Soren Brinkmann wrote:
> > Reuse the TTC clocksource timer as sched clock, too. Since only a single
> > sched clock is supported in Linux, this feature optional and can be
> > selected through Kconfig.
> > 
> > Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
> > ---
> 
> [...]
> 
> > diff --git a/drivers/clocksource/cadence_ttc_timer.c 
> > b/drivers/clocksource/cadence_ttc_timer.c
> > index 4cbe28c..ef0f52b 100644
> > --- a/drivers/clocksource/cadence_ttc_timer.c
> > +++ b/drivers/clocksource/cadence_ttc_timer.c
> > @@ -22,6 +22,7 @@
> >  #include <linux/of_irq.h>
> >  #include <linux/slab.h>
> >  #include <linux/clk-provider.h>
> > +#include <asm/sched_clock.h>
> 
> This has changed to linux/sched_clock.h in the tip tree. See 
> https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers/core&id=38ff87f77af0b5a93fc8581cff1d6e5692ab8970.
Is that change going into Linus' tree during the 3.11 merge window? The
tip tree is missing some changes to the TTC which went in through the
armsoc tree.

	S?ren




From tglx at linutronix.de  Fri Jul  5 16:42:03 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 5 Jul 2013 22:42:03 +0200 (CEST)
Subject: [PATCH] clocksource/cadence_ttc: Reuse clocksource as sched_clock
In-Reply-To: <0030b826-0eb1-4bb8-a0de-1d8dc68bd81a@TX2EHSMHS017.ehs.local>
References: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>
 <20130704033026.GX4288@tarshish>
 <0030b826-0eb1-4bb8-a0de-1d8dc68bd81a@TX2EHSMHS017.ehs.local>
Message-ID: <alpine.DEB.2.02.1307052238170.32106@ionos.tec.linutronix.de>

On Fri, 5 Jul 2013, S?ren Brinkmann wrote:
> On Thu, Jul 04, 2013 at 06:30:26AM +0300, Baruch Siach wrote:
> > Hi Soren,
> > 
> > On Wed, Jul 03, 2013 at 02:50:16PM -0700, Soren Brinkmann wrote:
> > > Reuse the TTC clocksource timer as sched clock, too. Since only a single
> > > sched clock is supported in Linux, this feature optional and can be
> > > selected through Kconfig.
> > > 
> > > Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
> > > ---
> > 
> > [...]
> > 
> > > diff --git a/drivers/clocksource/cadence_ttc_timer.c 
> > > b/drivers/clocksource/cadence_ttc_timer.c
> > > index 4cbe28c..ef0f52b 100644
> > > --- a/drivers/clocksource/cadence_ttc_timer.c
> > > +++ b/drivers/clocksource/cadence_ttc_timer.c
> > > @@ -22,6 +22,7 @@
> > >  #include <linux/of_irq.h>
> > >  #include <linux/slab.h>
> > >  #include <linux/clk-provider.h>
> > > +#include <asm/sched_clock.h>
> > 
> > This has changed to linux/sched_clock.h in the tip tree. See 
> > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers/core&id=38ff87f77af0b5a93fc8581cff1d6e5692ab8970.
> Is that change going into Linus' tree during the 3.11 merge window? The
> tip tree is missing some changes to the TTC which went in through the
> armsoc tree.

Yes, this is about to be sent Linuswards. Can we please coordinate
that stuff. drivers/clocksource depend on tip timers/* branches and
any modification in some other tree is going to be doomed.

We have a mechanism for that in place, if stuff goes cross trees. One
of the trees provides a set of commit for the other tree to pull, so
we do not end up with merge dependencies and conflicts.

Why is clocksource stuff going through armsoc unless it contains
related modifications in arch/arm/

Grmbl.

	tglx

From tglx at linutronix.de  Fri Jul  5 16:48:45 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 5 Jul 2013 22:48:45 +0200 (CEST)
Subject: [PATCHv3 08/10] clocksource: sun4i: Remove TIMER_SCAL variable
In-Reply-To: <1373052877-29366-9-git-send-email-maxime.ripard@free-electrons.com>
References: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
 <1373052877-29366-9-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <alpine.DEB.2.02.1307052245390.32106@ionos.tec.linutronix.de>



On Fri, 5 Jul 2013, Maxime Ripard wrote:

> The prescaler is only used when using the internal low frequency
> oscillator (at 32kHz). Since we're using the higher frequency oscillator
> at 24MHz, we can just remove it.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  drivers/clocksource/sun4i_timer.c | 11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
> index 00e17d9..2f84075 100644
> --- a/drivers/clocksource/sun4i_timer.c
> +++ b/drivers/clocksource/sun4i_timer.c
> @@ -34,8 +34,6 @@
>  #define TIMER_INTVAL_REG(val)	(0x10 * (val) + 0x14)
>  #define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
>  
> -#define TIMER_SCAL		16
> -

I can understand this one.

>  static void __iomem *timer_base;
>  
>  /*
> @@ -139,7 +137,6 @@ static u32 sun4i_timer_sched_read(void)
>  
>  static void __init sun4i_timer_init(struct device_node *node)
>  {
> -	unsigned long rate = 0;
>  	struct clk *clk;
>  	int ret, irq;
>  	u32 val;
> @@ -157,8 +154,6 @@ static void __init sun4i_timer_init(struct device_node *node)
>  		panic("Can't get timer clock");
>  	clk_prepare_enable(clk);
>  
> -	rate = clk_get_rate(clk);
> -

But this one is bogus. Why do you want to read the clock rate five
times in a row instead of using the single cached value?

That does not make any sense.

>  	writel(~0, timer_base + TIMER_INTVAL_REG(1));
>  	writel(TIMER_CTL_ENABLE | TIMER_CTL_RELOAD |
>  	       TIMER_CTL_CLK_SRC(TIMER_CTL_CLK_SRC_OSC24M),
> @@ -169,7 +164,7 @@ static void __init sun4i_timer_init(struct device_node *node)
>  			      clk_get_rate(clk), 300, 32,

Here is another left over bogosity.

>  			      clocksource_mmio_readl_down);
>  
> -	writel(rate / (TIMER_SCAL * HZ),
> +	writel(clk_get_rate(clk) / HZ,

What's wrong with:

       writel(rate / HZ, timer_base + TIMER_INTVAL_REG(0));

????

>  	       timer_base + TIMER_INTVAL_REG(0));
>  
>  	/* set clock source to HOSC, 16 pre-division */
> @@ -193,8 +188,8 @@ static void __init sun4i_timer_init(struct device_node *node)
>  
>  	sun4i_clockevent.cpumask = cpumask_of(0);
>  
> -	clockevents_config_and_register(&sun4i_clockevent, rate / TIMER_SCAL,
> -					0x1, 0xff);
> +	clockevents_config_and_register(&sun4i_clockevent, clk_get_rate(clk),
> +					0x1, 0xffffffff);



From arnd at arndb.de  Fri Jul  5 16:55:10 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Jul 2013 22:55:10 +0200
Subject: [PATCH] ASoC: Allow imx-pcm-{dma,fiq}.c to be modules
In-Reply-To: <20130705173321.GE27646@sirena.org.uk>
References: <201307051745.16140.arnd@arndb.de>
 <20130705173321.GE27646@sirena.org.uk>
Message-ID: <201307052255.10765.arnd@arndb.de>

On Friday 05 July 2013, Mark Brown wrote:
> On Fri, Jul 05, 2013 at 05:45:15PM +0200, Arnd Bergmann wrote:
> > This is required so we can build the imx sound support
> > when ALSA itself is a loadable module.
> 
> Is this actually OK with the FIQ APIs?
> 

I don't know. Why wouldn't it?

Other users of the same interfaces (mx1_camera, spi-s3c24xx) can also be
modules, so I wouldn't expect a fundamental issue.

	Arnd


From soren.brinkmann at xilinx.com  Fri Jul  5 16:56:22 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Fri, 5 Jul 2013 13:56:22 -0700
Subject: [PATCH] clocksource/cadence_ttc: Reuse clocksource as sched_clock
In-Reply-To: <alpine.DEB.2.02.1307052238170.32106@ionos.tec.linutronix.de>
References: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>
 <20130704033026.GX4288@tarshish>
 <0030b826-0eb1-4bb8-a0de-1d8dc68bd81a@TX2EHSMHS017.ehs.local>
 <alpine.DEB.2.02.1307052238170.32106@ionos.tec.linutronix.de>
Message-ID: <4fab6223-45c5-453e-9972-1c12aa79a312@CO1EHSMHS008.ehs.local>

On Fri, Jul 05, 2013 at 10:42:03PM +0200, Thomas Gleixner wrote:
> On Fri, 5 Jul 2013, S?ren Brinkmann wrote:
> > On Thu, Jul 04, 2013 at 06:30:26AM +0300, Baruch Siach wrote:
> > > Hi Soren,
> > > 
> > > On Wed, Jul 03, 2013 at 02:50:16PM -0700, Soren Brinkmann wrote:
> > > > Reuse the TTC clocksource timer as sched clock, too. Since only a single
> > > > sched clock is supported in Linux, this feature optional and can be
> > > > selected through Kconfig.
> > > > 
> > > > Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
> > > > ---
> > > 
> > > [...]
> > > 
> > > > diff --git a/drivers/clocksource/cadence_ttc_timer.c 
> > > > b/drivers/clocksource/cadence_ttc_timer.c
> > > > index 4cbe28c..ef0f52b 100644
> > > > --- a/drivers/clocksource/cadence_ttc_timer.c
> > > > +++ b/drivers/clocksource/cadence_ttc_timer.c
> > > > @@ -22,6 +22,7 @@
> > > >  #include <linux/of_irq.h>
> > > >  #include <linux/slab.h>
> > > >  #include <linux/clk-provider.h>
> > > > +#include <asm/sched_clock.h>
> > > 
> > > This has changed to linux/sched_clock.h in the tip tree. See 
> > > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers/core&id=38ff87f77af0b5a93fc8581cff1d6e5692ab8970.
> > Is that change going into Linus' tree during the 3.11 merge window? The
> > tip tree is missing some changes to the TTC which went in through the
> > armsoc tree.
> 
> Yes, this is about to be sent Linuswards. Can we please coordinate
> that stuff. drivers/clocksource depend on tip timers/* branches and
> any modification in some other tree is going to be doomed.
> 
> We have a mechanism for that in place, if stuff goes cross trees. One
> of the trees provides a set of commit for the other tree to pull, so
> we do not end up with merge dependencies and conflicts.
> 
> Why is clocksource stuff going through armsoc unless it contains
> related modifications in arch/arm/
We overhauled Zynq's common clock code and migrated all Zynq drivers to
it - the TTC being one. I'm pretty sure you were on the CC list for that
change.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=30e1e28598c2674c133148d8aec6d431d7acd314

	S?ren




From tglx at linutronix.de  Fri Jul  5 16:59:53 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 5 Jul 2013 22:59:53 +0200 (CEST)
Subject: [PATCH] clocksource/cadence_ttc: Reuse clocksource as sched_clock
In-Reply-To: <4fab6223-45c5-453e-9972-1c12aa79a312@CO1EHSMHS008.ehs.local>
References: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>
 <20130704033026.GX4288@tarshish>
 <0030b826-0eb1-4bb8-a0de-1d8dc68bd81a@TX2EHSMHS017.ehs.local>
 <alpine.DEB.2.02.1307052238170.32106@ionos.tec.linutronix.de>
 <4fab6223-45c5-453e-9972-1c12aa79a312@CO1EHSMHS008.ehs.local>
Message-ID: <alpine.DEB.2.02.1307052259090.32106@ionos.tec.linutronix.de>

On Fri, 5 Jul 2013, S?ren Brinkmann wrote:
> On Fri, Jul 05, 2013 at 10:42:03PM +0200, Thomas Gleixner wrote:
> > We have a mechanism for that in place, if stuff goes cross trees. One
> > of the trees provides a set of commit for the other tree to pull, so
> > we do not end up with merge dependencies and conflicts.
> > 
> > Why is clocksource stuff going through armsoc unless it contains
> > related modifications in arch/arm/
> We overhauled Zynq's common clock code and migrated all Zynq drivers to
> it - the TTC being one. I'm pretty sure you were on the CC list for that
> change.
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=30e1e28598c2674c133148d8aec6d431d7acd314
> 

That's fine as it has no dependencies on any of the clocksource core
changes AFAICT.

Thanks,

	tglx

From arnd at arndb.de  Fri Jul  5 17:02:40 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Jul 2013 23:02:40 +0200
Subject: MTD EEPROM support and driver integration
In-Reply-To: <20130705201118.GM2959@lukather>
References: <20130705201118.GM2959@lukather>
Message-ID: <201307052302.40588.arnd@arndb.de>

On Friday 05 July 2013, Maxime Ripard wrote:
> Hi everyone,
> 
> In the last weeks, we've drivers coming up both about mostly some very
> simple drivers that expose to the userspace a few bytes of memory-mapped
> IO. Both will probably live under drivers/misc/eeprom, where there's
> support already for other kind of what could be assimilated as eeproms
> (AT24, AT25, etc.).
> 
> Now, besides the code duplication every driver has to make to register
> the sysfs attributes, it wouldn't cause much of a problem.
> 
> Except that these EEPROMs could store values useful for other drivers in
> Linux. For example:
>   - imx28 OCOTP (the latest of the two EEPROM drivers recently submitted)
>     use it most of the time to store its MAC addresses
>   - Allwinner SoCs SID (the other latest driver submitted) use it
>     sometime to store a MAC address, and also the SoC ID, which could be
>     useful to implement a SoC bus driver.
>   - Some Allwinner boards (and presumably others) use an AT24 to store
>     the MAC address in it.
> 
> For now, everyone comes up with a different solution:
>   - imx28 has a hook in mach-mxs to patch the device tree at runtime and
>     add the values retrieved from the OCOTP to it.
>   - AT24 seem to have some function exported (at24_macc_(read|write)) so
>     that other part of the kernel can use them to retrieve values from
>     such an EEPROM.
>   - Allwinner SoCs have, well, basically nothing for now, which is why I
>     send this email.
> 
> The current way of working has several flaws imho:
>   - The code is heavily duplicated: the sysfs registering is common to
>     every driver, and at the end of the day, every driver should only
>     give a read/write callback, and that's it.
>   - The "consumer" drivers should not have to worry at all about the
>     EEPROM type it should retrieve the needed value from, let alone
>     dealing with the number of instances of such an EEPROM.
> 
> To solve this issues, I think I have some solution. Would merging this
> drivers into MTD make some sense? It seems like there is already some
> EEPROM drivers into drivers/mtd (such as an AT25 one, which also have a
> drivers under drivers/misc/eeprom), so I guess it does, but I'd like to
> have your opinion on this.

I always felt that we should eventually move the eeprom drivers out of
drivers/misc into their own subsystem. Moving them under drivers/mtd
also seems reasonable.

Having a common API sounds like a good idea, and we should probably
spend some time comparing the options.
 
> If so, would some kind of MTD in-kernel API to retrieve values from MTD
> devices would be acceptable to you? I mostly have DT in mind, so I'm
> thinking of having DT bindings to that API such as
> 
>   mac-storage = <&phandle 0xoffset 0xsize>
> 
> to describe which device to get a value from, and where in that device.
> 
> That would allow consumer drivers to only have to call a function like
> of_mtd_get_value and let the MTD subsystem do the hard work.
> 
> What's your feeling on this?

My first thought is that it should be more generic than that and not
have the mac address hardcoded as the purpose. We could possibly use
regmap as the in-kernel interface, and come up with a more generic
way of referring to registers in another device node.

	Arnd


From soren.brinkmann at xilinx.com  Fri Jul  5 17:10:04 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Fri, 5 Jul 2013 14:10:04 -0700
Subject: [PATCH] clocksource/cadence_ttc: Reuse clocksource as sched_clock
In-Reply-To: <alpine.DEB.2.02.1307052259090.32106@ionos.tec.linutronix.de>
References: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>
 <20130704033026.GX4288@tarshish>
 <0030b826-0eb1-4bb8-a0de-1d8dc68bd81a@TX2EHSMHS017.ehs.local>
 <alpine.DEB.2.02.1307052238170.32106@ionos.tec.linutronix.de>
 <4fab6223-45c5-453e-9972-1c12aa79a312@CO1EHSMHS008.ehs.local>
 <alpine.DEB.2.02.1307052259090.32106@ionos.tec.linutronix.de>
Message-ID: <db965b9f-740b-4ea6-9219-09ece1fc9220@CO9EHSMHS013.ehs.local>

On Fri, Jul 05, 2013 at 10:59:53PM +0200, Thomas Gleixner wrote:
> On Fri, 5 Jul 2013, S?ren Brinkmann wrote:
> > On Fri, Jul 05, 2013 at 10:42:03PM +0200, Thomas Gleixner wrote:
> > > We have a mechanism for that in place, if stuff goes cross trees. One
> > > of the trees provides a set of commit for the other tree to pull, so
> > > we do not end up with merge dependencies and conflicts.
> > > 
> > > Why is clocksource stuff going through armsoc unless it contains
> > > related modifications in arch/arm/
> > We overhauled Zynq's common clock code and migrated all Zynq drivers to
> > it - the TTC being one. I'm pretty sure you were on the CC list for that
> > change.
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=30e1e28598c2674c133148d8aec6d431d7acd314
> > 
> 
> That's fine as it has no dependencies on any of the clocksource core
> changes AFAICT.
Right, shouldn't be a big deal. Just for this patch, I currently have the
choice of working with the old TTC but the new clocksource core or the
other way around. But since everything is going to meet in Linus' tree
soon, I just wait a bit until tip/timers is merged.

	S?ren




From broonie at kernel.org  Fri Jul  5 17:19:20 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 5 Jul 2013 22:19:20 +0100
Subject: [PATCH] ASoC: Allow imx-pcm-{dma,fiq}.c to be modules
In-Reply-To: <201307052255.10765.arnd@arndb.de>
References: <201307051745.16140.arnd@arndb.de>
 <20130705173321.GE27646@sirena.org.uk>
 <201307052255.10765.arnd@arndb.de>
Message-ID: <20130705211920.GK27646@sirena.org.uk>

On Fri, Jul 05, 2013 at 10:55:10PM +0200, Arnd Bergmann wrote:
> On Friday 05 July 2013, Mark Brown wrote:

> > Is this actually OK with the FIQ APIs?

> I don't know. Why wouldn't it?

It was the only reason I could think of why that'd have been done.

> Other users of the same interfaces (mx1_camera, spi-s3c24xx) can also be
> modules, so I wouldn't expect a fundamental issue.

OK.
-------------- 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/20130705/c6dd9378/attachment.sig>

From bhelgaas at google.com  Fri Jul  5 17:32:13 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Fri, 5 Jul 2013 15:32:13 -0600
Subject: [PATCHv4 02/11] pci: use weak functions for MSI arch-specific
 functions
In-Reply-To: <1372686136-1370-3-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-3-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAErSpo5uCpQftDmsMYEsFMtt_LP3kZPQ3Y4zz4VT7GdpcFq+1w@mail.gmail.com>

On Mon, Jul 1, 2013 at 7:42 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Until now, the MSI architecture-specific functions could be overloaded
> using a fairly complex set of #define and compile-time
> conditionals. In order to prepare for the introduction of the msi_chip
> infrastructure, it is desirable to switch all those functions to use
> the 'weak' mechanism. This commit converts all the architectures that
> were overidding those MSI functions to use the new strategy.
>
> Note that we keep a separate, non-weak, function
> default_teardown_msi_irqs() for the default behavior of the
> arch_teardown_msi_irqs(), as the default behavior is needed by the Xen
> x86 PCI code.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> Cc: Paul Mackerras <paulus at samba.org>
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: Martin Schwidefsky <schwidefsky at de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens at de.ibm.com>
> Cc: linux390 at de.ibm.com
> Cc: linux-s390 at vger.kernel.org
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Ingo Molnar <mingo at redhat.com>
> Cc: H. Peter Anvin <hpa at zytor.com>
> Cc: x86 at kernel.org
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Tony Luck <tony.luck at intel.com>
> Cc: Fenghua Yu <fenghua.yu at intel.com>
> Cc: linux-ia64 at vger.kernel.org
> Cc: Ralf Baechle <ralf at linux-mips.org>
> Cc: linux-mips at linux-mips.org
> Cc: David S. Miller <davem at davemloft.net>
> Cc: sparclinux at vger.kernel.org
> Cc: Chris Metcalf <cmetcalf at tilera.com>

Acked-by: Bjorn Helgaas <bhelgaas at google.com>

> ---
>  arch/mips/include/asm/pci.h    |  5 -----
>  arch/powerpc/include/asm/pci.h |  5 -----
>  arch/s390/include/asm/pci.h    |  4 ----
>  arch/x86/include/asm/pci.h     | 28 --------------------------
>  arch/x86/kernel/x86_init.c     | 21 ++++++++++++++++++++
>  drivers/pci/msi.c              | 45 +++++++++++++++++++-----------------------
>  include/linux/msi.h            |  7 ++++++-
>  7 files changed, 47 insertions(+), 68 deletions(-)
>
> diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
> index b8e24fd..031f4c1 100644
> --- a/arch/mips/include/asm/pci.h
> +++ b/arch/mips/include/asm/pci.h
> @@ -137,11 +137,6 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
>         return channel ? 15 : 14;
>  }
>
> -#ifdef CONFIG_CPU_CAVIUM_OCTEON
> -/* MSI arch hook for OCTEON */
> -#define arch_setup_msi_irqs arch_setup_msi_irqs
> -#endif
> -
>  extern char * (*pcibios_plat_setup)(char *str);
>
>  #ifdef CONFIG_OF
> diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
> index 6653f27..95145a1 100644
> --- a/arch/powerpc/include/asm/pci.h
> +++ b/arch/powerpc/include/asm/pci.h
> @@ -113,11 +113,6 @@ extern int pci_domain_nr(struct pci_bus *bus);
>  /* Decide whether to display the domain number in /proc */
>  extern int pci_proc_domain(struct pci_bus *bus);
>
> -/* MSI arch hooks */
> -#define arch_setup_msi_irqs arch_setup_msi_irqs
> -#define arch_teardown_msi_irqs arch_teardown_msi_irqs
> -#define arch_msi_check_device arch_msi_check_device
> -
>  struct vm_area_struct;
>  /* Map a range of PCI memory or I/O space for a device into user space */
>  int pci_mmap_page_range(struct pci_dev *pdev, struct vm_area_struct *vma,
> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
> index 6c18012..8641e8d 100644
> --- a/arch/s390/include/asm/pci.h
> +++ b/arch/s390/include/asm/pci.h
> @@ -21,10 +21,6 @@ void pci_iounmap(struct pci_dev *, void __iomem *);
>  int pci_domain_nr(struct pci_bus *);
>  int pci_proc_domain(struct pci_bus *);
>
> -/* MSI arch hooks */
> -#define arch_setup_msi_irqs    arch_setup_msi_irqs
> -#define arch_teardown_msi_irqs arch_teardown_msi_irqs
> -
>  #define ZPCI_BUS_NR                    0       /* default bus number */
>  #define ZPCI_DEVFN                     0       /* default device number */
>
> diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
> index d9e9e6c..8c61de0 100644
> --- a/arch/x86/include/asm/pci.h
> +++ b/arch/x86/include/asm/pci.h
> @@ -100,29 +100,6 @@ static inline void early_quirks(void) { }
>  extern void pci_iommu_alloc(void);
>
>  #ifdef CONFIG_PCI_MSI
> -/* MSI arch specific hooks */
> -static inline int x86_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> -{
> -       return x86_msi.setup_msi_irqs(dev, nvec, type);
> -}
> -
> -static inline void x86_teardown_msi_irqs(struct pci_dev *dev)
> -{
> -       x86_msi.teardown_msi_irqs(dev);
> -}
> -
> -static inline void x86_teardown_msi_irq(unsigned int irq)
> -{
> -       x86_msi.teardown_msi_irq(irq);
> -}
> -static inline void x86_restore_msi_irqs(struct pci_dev *dev, int irq)
> -{
> -       x86_msi.restore_msi_irqs(dev, irq);
> -}
> -#define arch_setup_msi_irqs x86_setup_msi_irqs
> -#define arch_teardown_msi_irqs x86_teardown_msi_irqs
> -#define arch_teardown_msi_irq x86_teardown_msi_irq
> -#define arch_restore_msi_irqs x86_restore_msi_irqs
>  /* implemented in arch/x86/kernel/apic/io_apic. */
>  struct msi_desc;
>  int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
> @@ -130,11 +107,6 @@ void native_teardown_msi_irq(unsigned int irq);
>  void native_restore_msi_irqs(struct pci_dev *dev, int irq);
>  int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
>                   unsigned int irq_base, unsigned int irq_offset);
> -/* default to the implementation in drivers/lib/msi.c */
> -#define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
> -#define HAVE_DEFAULT_MSI_RESTORE_IRQS
> -void default_teardown_msi_irqs(struct pci_dev *dev);
> -void default_restore_msi_irqs(struct pci_dev *dev, int irq);
>  #else
>  #define native_setup_msi_irqs          NULL
>  #define native_teardown_msi_irq                NULL
> diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
> index 45a14db..a2b189c 100644
> --- a/arch/x86/kernel/x86_init.c
> +++ b/arch/x86/kernel/x86_init.c
> @@ -116,6 +116,27 @@ struct x86_msi_ops x86_msi = {
>         .setup_hpet_msi         = default_setup_hpet_msi,
>  };
>
> +/* MSI arch specific hooks */
> +int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +{
> +       return x86_msi.setup_msi_irqs(dev, nvec, type);
> +}
> +
> +void arch_teardown_msi_irqs(struct pci_dev *dev)
> +{
> +       x86_msi.teardown_msi_irqs(dev);
> +}
> +
> +void arch_teardown_msi_irq(unsigned int irq)
> +{
> +       x86_msi.teardown_msi_irq(irq);
> +}
> +
> +void arch_restore_msi_irqs(struct pci_dev *dev, int irq)
> +{
> +       x86_msi.restore_msi_irqs(dev, irq);
> +}
> +
>  struct x86_io_apic_ops x86_io_apic_ops = {
>         .init                   = native_io_apic_init_mappings,
>         .read                   = native_io_apic_read,
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 2c10752..289fbfd 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -30,20 +30,21 @@ static int pci_msi_enable = 1;
>
>  /* Arch hooks */
>
> -#ifndef arch_msi_check_device
> -int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> +int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
>  {
> -       return 0;
> +       return -EINVAL;
>  }
> -#endif
>
> -#ifndef arch_setup_msi_irqs
> -# define arch_setup_msi_irqs default_setup_msi_irqs
> -# define HAVE_DEFAULT_MSI_SETUP_IRQS
> -#endif
> +void __weak arch_teardown_msi_irq(unsigned int irq)
> +{
> +}
>
> -#ifdef HAVE_DEFAULT_MSI_SETUP_IRQS
> -int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> +{
> +       return 0;
> +}
> +
> +int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>  {
>         struct msi_desc *entry;
>         int ret;
> @@ -65,14 +66,11 @@ int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>
>         return 0;
>  }
> -#endif
>
> -#ifndef arch_teardown_msi_irqs
> -# define arch_teardown_msi_irqs default_teardown_msi_irqs
> -# define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
> -#endif
> -
> -#ifdef HAVE_DEFAULT_MSI_TEARDOWN_IRQS
> +/*
> + * We have a default implementation available as a separate non-weak
> + * function, as it is used by the Xen x86 PCI code
> + */
>  void default_teardown_msi_irqs(struct pci_dev *dev)
>  {
>         struct msi_desc *entry;
> @@ -86,15 +84,13 @@ void default_teardown_msi_irqs(struct pci_dev *dev)
>                         arch_teardown_msi_irq(entry->irq + i);
>         }
>  }
> -#endif
>
> -#ifndef arch_restore_msi_irqs
> -# define arch_restore_msi_irqs default_restore_msi_irqs
> -# define HAVE_DEFAULT_MSI_RESTORE_IRQS
> -#endif
> +void __weak arch_teardown_msi_irqs(struct pci_dev *dev)
> +{
> +       return default_teardown_msi_irqs(dev);
> +}
>
> -#ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS
> -void default_restore_msi_irqs(struct pci_dev *dev, int irq)
> +void __weak arch_restore_msi_irqs(struct pci_dev *dev, int irq)
>  {
>         struct msi_desc *entry;
>
> @@ -111,7 +107,6 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)
>         if (entry)
>                 write_msi_msg(irq, &entry->msg);
>  }
> -#endif
>
>  static void msi_set_enable(struct pci_dev *dev, int enable)
>  {
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index 20c2d6d..c82ff8d 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -50,12 +50,17 @@ struct msi_desc {
>  };
>
>  /*
> - * The arch hook for setup up msi irqs
> + * The arch hooks to setup up msi irqs. Those functions are
> + * implemented as weak symbols so that they /can/ be overriden by
> + * architecture specific code if needed.
>   */
>  int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc);
>  void arch_teardown_msi_irq(unsigned int irq);
>  int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
>  void arch_teardown_msi_irqs(struct pci_dev *dev);
>  int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
> +void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
> +
> +void default_teardown_msi_irqs(struct pci_dev *dev);
>
>  #endif /* LINUX_MSI_H */
> --
> 1.8.1.2
>


From bhelgaas at google.com  Fri Jul  5 17:34:10 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Fri, 5 Jul 2013 15:34:10 -0600
Subject: [PATCHv4 02/11] pci: use weak functions for MSI arch-specific
 functions
In-Reply-To: <CAErSpo5uCpQftDmsMYEsFMtt_LP3kZPQ3Y4zz4VT7GdpcFq+1w@mail.gmail.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-3-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo5uCpQftDmsMYEsFMtt_LP3kZPQ3Y4zz4VT7GdpcFq+1w@mail.gmail.com>
Message-ID: <CAErSpo4HoofGhN8VumRnN0sN_+gWJ9gVQJVMiePnDBUKwh74ag@mail.gmail.com>

On Fri, Jul 5, 2013 at 3:32 PM, Bjorn Helgaas <bhelgaas at google.com> wrote:

> Acked-by: Bjorn Helgaas <bhelgaas at google.com>

But please update your subject line to use consistent capitalization, e.g.,

PCI: Use weak ...


From linux at arm.linux.org.uk  Fri Jul  5 17:32:15 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 5 Jul 2013 22:32:15 +0100
Subject: [PATCH V3] ARM: add missing linker section markup to head-common.S
In-Reply-To: <1373047855-24145-1-git-send-email-swarren@wwwdotorg.org>
References: <1373047855-24145-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130705213214.GK24642@n2100.arm.linux.org.uk>

On Fri, Jul 05, 2013 at 12:10:55PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> Macro __INIT is used to place various code in head-common.S into the init
> section. This should be matched by a closing __FINIT. Also, add an
> explicit ".text" to ensure subsequent code is placed into the correct
> section; __FINIT is simply a closing marker to match __INIT and doesn't
> guarantee to revert to .text.
> 
> This historically caused no problem, because macro __CPUINIT was used at
> the exact location where __FINIT was missing, which then placed following
> code into the cpuinit section. However, with commit 22f0a2736 "init.h:
> remove __cpuinit sections from the kernel" applied, __CPUINIT becomes a
> no-op, thus leaving all this code in the init section, rather than the
> regular text section. This caused issues such as secondary CPU boot
> failures or crashes.
> 
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> Acked-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> ---
> v3: Added .text after __FINIT to force the correct section.
> v2: Moved __FINIT after lookup_processor_type, to correctly match the
> location of __CPUINIT.

Much better, thanks.  Please put it in the patch system and I'll send it
along, thanks.


From bhelgaas at google.com  Fri Jul  5 17:37:33 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Fri, 5 Jul 2013 15:37:33 -0600
Subject: [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
In-Reply-To: <1372686136-1370-4-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-4-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAErSpo73iSBg+SYwZLea0qdXD1uVc3+Vacd8Tg4CU92vLG=2AQ@mail.gmail.com>

On Mon, Jul 1, 2013 at 7:42 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Now that we have weak versions for each of the PCI MSI architecture
> functions, we can actually build the MSI support for all platforms,
> regardless of whether they provide or not architecture-specific
> versions of those functions. For this reason, the ARCH_SUPPORTS_MSI
> hidden kconfig boolean becomes useless, and this patch gets rid of it.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> Cc: Paul Mackerras <paulus at samba.org>
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: Martin Schwidefsky <schwidefsky at de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens at de.ibm.com>
> Cc: linux390 at de.ibm.com
> Cc: linux-s390 at vger.kernel.org
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Ingo Molnar <mingo at redhat.com>
> Cc: H. Peter Anvin <hpa at zytor.com>
> Cc: x86 at kernel.org
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Tony Luck <tony.luck at intel.com>
> Cc: Fenghua Yu <fenghua.yu at intel.com>
> Cc: linux-ia64 at vger.kernel.org
> Cc: Ralf Baechle <ralf at linux-mips.org>
> Cc: linux-mips at linux-mips.org
> Cc: David S. Miller <davem at davemloft.net>
> Cc: sparclinux at vger.kernel.org
> Cc: Chris Metcalf <cmetcalf at tilera.com>

Acked-by: Bjorn Helgaas <bhelgaas at google.com>

Again, please update the subject line to "PCI: Remove ..."

I doubt that you'll get explicit acks from all the arches you touched,
but I think it's reasonable to put at least patches 2 & 3 in -next
soon after v3.11-rc1, so we should have time to shake out issues.

> ---
>  arch/arm/Kconfig     | 1 -
>  arch/ia64/Kconfig    | 1 -
>  arch/mips/Kconfig    | 2 --
>  arch/powerpc/Kconfig | 1 -
>  arch/s390/Kconfig    | 1 -
>  arch/sparc/Kconfig   | 1 -
>  arch/tile/Kconfig    | 1 -
>  arch/x86/Kconfig     | 1 -
>  drivers/pci/Kconfig  | 4 ----
>  9 files changed, 13 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 8ab5962..3413679 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -435,7 +435,6 @@ config ARCH_NETX
>  config ARCH_IOP13XX
>         bool "IOP13xx-based"
>         depends on MMU
> -       select ARCH_SUPPORTS_MSI
>         select CPU_XSC3
>         select NEED_MACH_MEMORY_H
>         select NEED_RET_TO_USER
> diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> index 1a2b774..943d425 100644
> --- a/arch/ia64/Kconfig
> +++ b/arch/ia64/Kconfig
> @@ -9,7 +9,6 @@ config IA64
>         select PCI if (!IA64_HP_SIM)
>         select ACPI if (!IA64_HP_SIM)
>         select PM if (!IA64_HP_SIM)
> -       select ARCH_SUPPORTS_MSI
>         select HAVE_UNSTABLE_SCHED_CLOCK
>         select HAVE_IDE
>         select HAVE_OPROFILE
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 7a58ab9..96c1225 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -763,7 +763,6 @@ config CAVIUM_OCTEON_REFERENCE_BOARD
>         select SYS_HAS_CPU_CAVIUM_OCTEON
>         select SWAP_IO_SPACE
>         select HW_HAS_PCI
> -       select ARCH_SUPPORTS_MSI
>         select ZONE_DMA32
>         select USB_ARCH_HAS_OHCI
>         select USB_ARCH_HAS_EHCI
> @@ -799,7 +798,6 @@ config NLM_XLR_BOARD
>         select CEVT_R4K
>         select CSRC_R4K
>         select IRQ_CPU
> -       select ARCH_SUPPORTS_MSI
>         select ZONE_DMA32 if 64BIT
>         select SYNC_R4K
>         select SYS_HAS_EARLY_PRINTK
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index c33e3ad..f9d9d8e 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -734,7 +734,6 @@ config PCI
>         default y if !40x && !CPM2 && !8xx && !PPC_83xx \
>                 && !PPC_85xx && !PPC_86xx && !GAMECUBE_COMMON
>         default PCI_QSPAN if !4xx && !CPM2 && 8xx
> -       select ARCH_SUPPORTS_MSI
>         select GENERIC_PCI_IOMAP
>         help
>           Find out whether your system includes a PCI bus. PCI is the name of
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index da183c5..9a6225b 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -429,7 +429,6 @@ menuconfig PCI
>         bool "PCI support"
>         default n
>         depends on 64BIT
> -       select ARCH_SUPPORTS_MSI
>         select PCI_MSI
>         help
>           Enable PCI support.
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index 9ac9f16..822e1a1 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -52,7 +52,6 @@ config SPARC32
>
>  config SPARC64
>         def_bool 64BIT
> -       select ARCH_SUPPORTS_MSI
>         select HAVE_FUNCTION_TRACER
>         select HAVE_FUNCTION_GRAPH_TRACER
>         select HAVE_FUNCTION_GRAPH_FP_TEST
> diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
> index 3aa3766..d2d519c 100644
> --- a/arch/tile/Kconfig
> +++ b/arch/tile/Kconfig
> @@ -379,7 +379,6 @@ config PCI
>         select PCI_DOMAINS
>         select GENERIC_PCI_IOMAP
>         select TILE_GXIO_TRIO if TILEGX
> -       select ARCH_SUPPORTS_MSI if TILEGX
>         select PCI_MSI if TILEGX
>         ---help---
>           Enable PCI root complex support, so PCIe endpoint devices can
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 685692c..4229ce0 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1999,7 +1999,6 @@ menu "Bus options (PCI etc.)"
>  config PCI
>         bool "PCI support"
>         default y
> -       select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC)
>         ---help---
>           Find out whether you have a PCI motherboard. PCI is the name of a
>           bus system, i.e. the way the CPU talks to the other stuff inside
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index ac45398..3d4c061 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -1,13 +1,9 @@
>  #
>  # PCI configuration
>  #
> -config ARCH_SUPPORTS_MSI
> -       bool
> -
>  config PCI_MSI
>         bool "Message Signaled Interrupts (MSI and MSI-X)"
>         depends on PCI
> -       depends on ARCH_SUPPORTS_MSI
>         help
>            This allows device drivers to enable MSI (Message Signaled
>            Interrupts).  Message Signaled Interrupts enable a device to
> --
> 1.8.1.2
>


From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:12 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:12 -0300
Subject: [PATCH v6 01/21] memory: mvebu-devbus: Remove address decoding window
 workaround
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-2-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus device tree binding has been introduced, remove the address
decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in
the device tree, as described by the mbus binding documentation.

Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/memory/mvebu-devbus.c | 64 ++-----------------------------------------
 1 file changed, 2 insertions(+), 62 deletions(-)

diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
index 978e8e3..94c9248 100644
--- a/drivers/memory/mvebu-devbus.c
+++ b/drivers/memory/mvebu-devbus.c
@@ -208,16 +208,11 @@ static int mvebu_devbus_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct device_node *node = pdev->dev.of_node;
-	struct device_node *parent;
 	struct devbus *devbus;
 	struct resource *res;
 	struct clk *clk;
 	unsigned long rate;
-	const __be32 *ranges;
-	int err, cs;
-	int addr_cells, p_addr_cells, size_cells;
-	int ranges_len, tuple_len;
-	u32 base, size;
+	int err;
 
 	devbus = devm_kzalloc(&pdev->dev, sizeof(struct devbus), GFP_KERNEL);
 	if (!devbus)
@@ -248,68 +243,13 @@ static int mvebu_devbus_probe(struct platform_device *pdev)
 		return err;
 
 	/*
-	 * Allocate an address window for this device.
-	 * If the device probing fails, then we won't be able to
-	 * remove the allocated address decoding window.
-	 *
-	 * FIXME: This is only a temporary hack! We need to do this here
-	 * because we still don't have device tree bindings for mbus.
-	 * Once that support is added, we will declare these address windows
-	 * statically in the device tree, and remove the window configuration
-	 * from here.
-	 */
-
-	/*
-	 * Get the CS to choose the window string.
-	 * This is a bit hacky, but it will be removed once the
-	 * address windows are declared in the device tree.
-	 */
-	cs = (((unsigned long)devbus->base) % 0x400) / 8;
-
-	/*
-	 * Parse 'ranges' property to obtain a (base,size) window tuple.
-	 * This will be removed once the address windows
-	 * are declared in the device tree.
-	 */
-	parent = of_get_parent(node);
-	if (!parent)
-		return -EINVAL;
-
-	p_addr_cells = of_n_addr_cells(parent);
-	of_node_put(parent);
-
-	addr_cells = of_n_addr_cells(node);
-	size_cells = of_n_size_cells(node);
-	tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
-
-	ranges = of_get_property(node, "ranges", &ranges_len);
-	if (ranges == NULL || ranges_len != tuple_len)
-		return -EINVAL;
-
-	base = of_translate_address(node, ranges + addr_cells);
-	if (base == OF_BAD_ADDR)
-		return -EINVAL;
-	size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
-
-	/*
-	 * Create an mbus address windows.
-	 * FIXME: Remove this, together with the above code, once the
-	 * address windows are declared in the device tree.
-	 */
-	err = mvebu_mbus_add_window(devbus_wins[cs], base, size);
-	if (err < 0)
-		return err;
-
-	/*
 	 * We need to create a child device explicitly from here to
 	 * guarantee that the child will be probed after the timing
 	 * parameters for the bus are written.
 	 */
 	err = of_platform_populate(node, NULL, NULL, dev);
-	if (err < 0) {
-		mvebu_mbus_del_window(base, size);
+	if (err < 0)
 		return err;
-	}
 
 	return 0;
 }
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:11 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:11 -0300
Subject: [PATCH v6 00/21] MBus DT binding: PCIe strikes back
Message-ID: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>

See the previous version of this patchset for further context:

http://www.mail-archive.com/devicetree-discuss at lists.ozlabs.org/msg35753.html

This new proposal is an attempt to address some issues raised about the PCIe
'fake' windows mapping present in the previous version.

Instead of defining a 'fake' MBUS_ID(0xf0, 0x02) region for the whole
PCIe memory and IO space, we use real target ID and attribute for the windows.

See the example below, where a somewhat complete device tree extract is shown:

	soc {
		compatible = "marvell,armadaxp-mbus", "simple-bus";
		controller = <&mbusc>;

		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;

		bootrom {
			compatible = "marvell,bootrom";
			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
		};

		devbus-bootcs {
			status = "okay";
			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;

			/* NOR */
			nor {
				compatible = "cfi-flash";
				reg = <0 0x8000000>;
				bank-width = <2>;
			};
		};

		pcie-controller {
			compatible = "marvell,armada-xp-pcie";
			status = "okay";
			device_type = "pci";

			#address-cells = <3>;
			#size-cells = <2>;

			ranges =
			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>;


			pcie at 1,0 {
				/* Port 0, Lane 0 */
				status = "okay";
			};
		};

		internal-regs {
			compatible = "simple-bus";
			#address-cells = <1>;
			#size-cells = <1>;
			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;

			mbusc: mbus-controller at 20000 {
				reg = <0x20000 0x100>, <0x20180 0x20>;
			};

			interrupt-controller at 20000 {
			      reg = <0x20a00 0x2d0>, <0x21070 0x58>;
			};
		};
	};

With this new approach there's no mbus-node ranges translation for the 'fake'
window that maps the PCIe regions. Such a translation was actually wrong
in the sense that the windows are allocated dynamically and hence the mappings
need to be created dynamically.

As the target ID and attribute is now encoded in the device tree, it's
now possible to remove the name-based window allocation scheme, replacing
it by a new one based in the IDs only.

This makes the MBus DT binding much consistent, as now both the statically
and dynamically allocated decoding window are defined in the same way.

I'd like to see this binding accepted more or less soon, so if the current
proposal is not accepted it'll be great to hear some hints on how to move
forward.

This series applies on top of today's linux-next. I will rebase it on v3.11-rc1
as soon as that's available.

Thanks a lot!

Ezequiel Garcia (11):
  memory: mvebu-devbus: Remove address decoding window workaround
  bus: mvebu-mbus: Factor out initialization details
  bus: mvebu-mbus: Introduce device tree binding
  bus: mvebu-mbus: Add static window allocation to the DT binding
  ARM: mvebu: Remove the harcoded BootROM window allocation
  ARM: mvebu: Initialize MBus using the DT binding
  ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
  ARM: mvebu: Add MBus to Armada 370/XP device tree
  ARM: mvebu: Add BootROM to Armada 370/XP device tree
  ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
  ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes

Thomas Petazzoni (10):
  bus: mvebu-mbus: Add new API for window creation
  ARM: kirkwood: Move to ID based MBus window creation
  ARM: mv78xx0: Move to ID based window creation
  ARM: orion5x: Move to ID based window creation
  ARM: dove: Move to ID based window creation
  pci: mvebu: Adapt to the new device tree layout
  bus: mvebu-mbus: Remove the no longer used name-based API
  bus: mvebu-mbus: Remove name -> target, attribute mapping tables
  bus: mvebu-mbus: Update main description
  bus: mvebu-mbus: Factorize Armada 370/XP data structures

 .../devicetree/bindings/bus/mvebu-mbus.txt         | 256 +++++++++++++
 arch/arm/boot/dts/armada-370-db.dts                |   5 +-
 arch/arm/boot/dts/armada-370-mirabox.dts           |  37 +-
 arch/arm/boot/dts/armada-370-rd.dts                |   5 +-
 arch/arm/boot/dts/armada-370-xp.dtsi               | 109 +++---
 arch/arm/boot/dts/armada-370.dtsi                  | 110 +++---
 arch/arm/boot/dts/armada-xp-db.dts                 | 131 ++++---
 arch/arm/boot/dts/armada-xp-gp.dts                 | 107 +++---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi           | 217 +++++------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi           | 258 ++++++-------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi           | 397 +++++++++++----------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |  88 +++--
 arch/arm/boot/dts/armada-xp.dtsi                   |   9 +-
 arch/arm/mach-dove/common.c                        |  68 ++--
 arch/arm/mach-kirkwood/common.c                    |  18 +-
 arch/arm/mach-kirkwood/pcie.c                      |  40 ++-
 arch/arm/mach-mv78xx0/pcie.c                       |  23 +-
 arch/arm/mach-mvebu/armada-370-xp.c                |  34 +-
 arch/arm/mach-mvebu/platsmp.c                      |  25 +-
 arch/arm/mach-orion5x/common.c                     |  36 +-
 arch/arm/mach-orion5x/common.h                     |  17 +
 arch/arm/mach-orion5x/d2net-setup.c                |   6 +-
 arch/arm/mach-orion5x/db88f5281-setup.c            |  24 +-
 arch/arm/mach-orion5x/dns323-setup.c               |   6 +-
 arch/arm/mach-orion5x/edmini_v2-setup.c            |   6 +-
 arch/arm/mach-orion5x/kurobox_pro-setup.c          |  12 +-
 arch/arm/mach-orion5x/ls-chl-setup.c               |   6 +-
 arch/arm/mach-orion5x/ls_hgl-setup.c               |   6 +-
 arch/arm/mach-orion5x/lsmini-setup.c               |   6 +-
 arch/arm/mach-orion5x/mss2-setup.c                 |   6 +-
 arch/arm/mach-orion5x/mv2120-setup.c               |   6 +-
 arch/arm/mach-orion5x/net2big-setup.c              |   6 +-
 arch/arm/mach-orion5x/pci.c                        |   9 +-
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c       |   6 +-
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c        |   6 +-
 arch/arm/mach-orion5x/rd88f5182-setup.c            |  13 +-
 arch/arm/mach-orion5x/terastation_pro2-setup.c     |   6 +-
 arch/arm/mach-orion5x/ts209-setup.c                |   6 +-
 arch/arm/mach-orion5x/ts409-setup.c                |   6 +-
 arch/arm/mach-orion5x/wnr854t-setup.c              |   6 +-
 arch/arm/mach-orion5x/wrt350n-v2-setup.c           |   6 +-
 drivers/bus/mvebu-mbus.c                           | 386 ++++++++++----------
 drivers/memory/mvebu-devbus.c                      |  64 +---
 drivers/pci/host/pci-mvebu.c                       | 152 ++++++--
 include/linux/mbus.h                               |  12 +-
 45 files changed, 1610 insertions(+), 1148 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt

-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:13 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:13 -0300
Subject: [PATCH v6 02/21] bus: mvebu-mbus: Add new API for window creation
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-3-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

We add an API to create MBus address decoding windows from the target
ID and attribute. This function will be used later and deprecate the
current name based scheme.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 33 +++++++++++++++++++++++++--------
 include/linux/mbus.h     |  6 ++++++
 2 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 33c6947..827468a 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -748,6 +748,22 @@ static const struct of_device_id of_mvebu_mbus_ids[] = {
 /*
  * Public API of the driver
  */
+int mvebu_mbus_add_window_remap_by_id(unsigned int target,
+				      unsigned int attribute,
+				      phys_addr_t base, size_t size,
+				      phys_addr_t remap)
+{
+	struct mvebu_mbus_state *s = &mbus_state;
+
+	if (!mvebu_mbus_window_conflicts(s, base, size, target, attribute)) {
+		pr_err("cannot add window '%x:%x', conflicts with another window\n",
+		       target, attribute);
+		return -EINVAL;
+	}
+
+	return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
+}
+
 int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 				      size_t size, phys_addr_t remap,
 				      unsigned int flags)
@@ -776,14 +792,8 @@ int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 	else if (flags == MVEBU_MBUS_PCI_WA)
 		attr |= 0x28;
 
-	if (!mvebu_mbus_window_conflicts(s, base, size, target, attr)) {
-		pr_err("cannot add window '%s', conflicts with another window\n",
-		       devname);
-		return -EINVAL;
-	}
-
-	return mvebu_mbus_alloc_window(s, base, size, remap, target, attr);
-
+	return mvebu_mbus_add_window_remap_by_id(target, attr, base,
+						 size, remap);
 }
 
 int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
@@ -792,6 +802,13 @@ int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
 						 MVEBU_MBUS_NO_REMAP, 0);
 }
 
+int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
+				phys_addr_t base, size_t size)
+{
+	return mvebu_mbus_add_window_remap_by_id(target, attribute, base,
+						 size, MVEBU_MBUS_NO_REMAP);
+}
+
 int mvebu_mbus_del_window(phys_addr_t base, size_t size)
 {
 	int win;
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index dba482e..9245b66 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -62,8 +62,14 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
 int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 				      size_t size, phys_addr_t remap,
 				      unsigned int flags);
+int mvebu_mbus_add_window_remap_by_id(unsigned int target,
+				      unsigned int attribute,
+				      phys_addr_t base, size_t size,
+				      phys_addr_t remap);
 int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
 			  size_t size);
+int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
+				phys_addr_t base, size_t size);
 int mvebu_mbus_del_window(phys_addr_t base, size_t size);
 int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
 		    size_t mbus_size, phys_addr_t sdram_phys_base,
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:14 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:14 -0300
Subject: [PATCH v6 03/21] ARM: kirkwood: Move to ID based MBus window creation
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-4-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-kirkwood/common.c | 18 ++++++++++++++----
 arch/arm/mach-kirkwood/pcie.c   | 40 ++++++++++++++++++++++++----------------
 2 files changed, 38 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index e9238b5..165e751 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -37,6 +37,12 @@
 #include <linux/platform_data/dma-mv_xor.h>
 #include "common.h"
 
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_NAND_TARGET 0x01
+#define KIRKWOOD_MBUS_NAND_ATTR   0x2f
+#define KIRKWOOD_MBUS_SRAM_TARGET 0x03
+#define KIRKWOOD_MBUS_SRAM_ATTR   0x01
+
 /*****************************************************************************
  * I/O Address Mapping
  ****************************************************************************/
@@ -672,10 +678,14 @@ char * __init kirkwood_id(void)
 
 void __init kirkwood_setup_wins(void)
 {
-	mvebu_mbus_add_window("nand", KIRKWOOD_NAND_MEM_PHYS_BASE,
-			      KIRKWOOD_NAND_MEM_SIZE);
-	mvebu_mbus_add_window("sram", KIRKWOOD_SRAM_PHYS_BASE,
-			      KIRKWOOD_SRAM_SIZE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_NAND_TARGET,
+				    KIRKWOOD_MBUS_NAND_ATTR,
+				    KIRKWOOD_NAND_MEM_PHYS_BASE,
+				    KIRKWOOD_NAND_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_SRAM_TARGET,
+				    KIRKWOOD_MBUS_SRAM_ATTR,
+				    KIRKWOOD_SRAM_PHYS_BASE,
+				    KIRKWOOD_SRAM_SIZE);
 }
 
 void __init kirkwood_l2_init(void)
diff --git a/arch/arm/mach-kirkwood/pcie.c b/arch/arm/mach-kirkwood/pcie.c
index ddcb09f..12d86f3 100644
--- a/arch/arm/mach-kirkwood/pcie.c
+++ b/arch/arm/mach-kirkwood/pcie.c
@@ -20,6 +20,16 @@
 #include <mach/bridge-regs.h>
 #include "common.h"
 
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_PCIE0_MEM_TARGET    0x4
+#define KIRKWOOD_MBUS_PCIE0_MEM_ATTR      0xe8
+#define KIRKWOOD_MBUS_PCIE0_IO_TARGET     0x4
+#define KIRKWOOD_MBUS_PCIE0_IO_ATTR       0xe0
+#define KIRKWOOD_MBUS_PCIE1_MEM_TARGET    0x4
+#define KIRKWOOD_MBUS_PCIE1_MEM_ATTR      0xd8
+#define KIRKWOOD_MBUS_PCIE1_IO_TARGET     0x4
+#define KIRKWOOD_MBUS_PCIE1_IO_ATTR       0xd0
+
 static void kirkwood_enable_pcie_clk(const char *port)
 {
 	struct clk *clk;
@@ -254,26 +264,24 @@ static void __init add_pcie_port(int index, void __iomem *base)
 
 void __init kirkwood_pcie_init(unsigned int portmask)
 {
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
+	mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE0_IO_TARGET,
+					  KIRKWOOD_MBUS_PCIE0_IO_ATTR,
 					  KIRKWOOD_PCIE_IO_PHYS_BASE,
 					  KIRKWOOD_PCIE_IO_SIZE,
-					  KIRKWOOD_PCIE_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
-					  KIRKWOOD_PCIE_MEM_PHYS_BASE,
-					  KIRKWOOD_PCIE_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
+					  KIRKWOOD_PCIE_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_PCIE0_MEM_TARGET,
+				    KIRKWOOD_MBUS_PCIE0_MEM_ATTR,
+				    KIRKWOOD_PCIE_MEM_PHYS_BASE,
+				    KIRKWOOD_PCIE_MEM_SIZE);
+	mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE1_IO_TARGET,
+					  KIRKWOOD_MBUS_PCIE1_IO_ATTR,
 					  KIRKWOOD_PCIE1_IO_PHYS_BASE,
 					  KIRKWOOD_PCIE1_IO_SIZE,
-					  KIRKWOOD_PCIE1_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
-					  KIRKWOOD_PCIE1_MEM_PHYS_BASE,
-					  KIRKWOOD_PCIE1_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+					  KIRKWOOD_PCIE1_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_PCIE1_MEM_TARGET,
+				    KIRKWOOD_MBUS_PCIE1_MEM_ATTR,
+				    KIRKWOOD_PCIE1_MEM_PHYS_BASE,
+				    KIRKWOOD_PCIE1_MEM_SIZE);
 
 	vga_base = KIRKWOOD_PCIE_MEM_PHYS_BASE;
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:15 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:15 -0300
Subject: [PATCH v6 04/21] ARM: mv78xx0: Move to ID based window creation
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-5-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-mv78xx0/pcie.c | 23 +++++++++++------------
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-mv78xx0/pcie.c b/arch/arm/mach-mv78xx0/pcie.c
index dc26a65..397afde 100644
--- a/arch/arm/mach-mv78xx0/pcie.c
+++ b/arch/arm/mach-mv78xx0/pcie.c
@@ -18,6 +18,11 @@
 #include <mach/mv78xx0.h>
 #include "common.h"
 
+#define MV78XX0_MBUS_PCIE_MEM_TARGET(port, lane) ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_MEM_ATTR(port, lane)   (0xf8 & ~(0x10 << (lane)))
+#define MV78XX0_MBUS_PCIE_IO_TARGET(port, lane)  ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_IO_ATTR(port, lane)    (0xf0 & ~(0x10 << (lane)))
+
 struct pcie_port {
 	u8			maj;
 	u8			min;
@@ -71,7 +76,6 @@ static void __init mv78xx0_pcie_preinit(void)
 	start = MV78XX0_PCIE_MEM_PHYS_BASE;
 	for (i = 0; i < num_pcie_ports; i++) {
 		struct pcie_port *pp = pcie_port + i;
-		char winname[MVEBU_MBUS_MAX_WINNAME_SZ];
 
 		snprintf(pp->mem_space_name, sizeof(pp->mem_space_name),
 			"PCIe %d.%d MEM", pp->maj, pp->min);
@@ -85,17 +89,12 @@ static void __init mv78xx0_pcie_preinit(void)
 		if (request_resource(&iomem_resource, &pp->res))
 			panic("can't allocate PCIe MEM sub-space");
 
-		snprintf(winname, sizeof(winname), "pcie%d.%d",
-			 pp->maj, pp->min);
-
-		mvebu_mbus_add_window_remap_flags(winname,
-						  pp->res.start,
-						  resource_size(&pp->res),
-						  MVEBU_MBUS_NO_REMAP,
-						  MVEBU_MBUS_PCI_MEM);
-		mvebu_mbus_add_window_remap_flags(winname,
-						  i * SZ_64K, SZ_64K,
-						  0, MVEBU_MBUS_PCI_IO);
+		mvebu_mbus_add_window_by_id(MV78XX0_MBUS_PCIE_MEM_TARGET(pp->maj, pp->min),
+					    MV78XX0_MBUS_PCIE_MEM_ATTR(pp->maj, pp->min),
+					    pp->res.start, resource_size(&pp->res));
+		mvebu_mbus_add_window_remap_by_id(MV78XX0_MBUS_PCIE_IO_TARGET(pp->maj, pp->min),
+						  MV78XX0_MBUS_PCIE_IO_ATTR(pp->maj, pp->min),
+						  i * SZ_64K, SZ_64K, 0);
 	}
 }
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:16 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:16 -0300
Subject: [PATCH v6 05/21] ARM: orion5x: Move to ID based window creation
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-6-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-orion5x/common.c                 | 36 ++++++++++++++------------
 arch/arm/mach-orion5x/common.h                 | 17 ++++++++++++
 arch/arm/mach-orion5x/d2net-setup.c            |  6 +++--
 arch/arm/mach-orion5x/db88f5281-setup.c        | 24 +++++++++++------
 arch/arm/mach-orion5x/dns323-setup.c           |  6 +++--
 arch/arm/mach-orion5x/edmini_v2-setup.c        |  6 +++--
 arch/arm/mach-orion5x/kurobox_pro-setup.c      | 12 ++++++---
 arch/arm/mach-orion5x/ls-chl-setup.c           |  6 +++--
 arch/arm/mach-orion5x/ls_hgl-setup.c           |  6 +++--
 arch/arm/mach-orion5x/lsmini-setup.c           |  6 +++--
 arch/arm/mach-orion5x/mss2-setup.c             |  6 +++--
 arch/arm/mach-orion5x/mv2120-setup.c           |  6 +++--
 arch/arm/mach-orion5x/net2big-setup.c          |  6 +++--
 arch/arm/mach-orion5x/pci.c                    |  9 +++----
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c   |  6 +++--
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c    |  6 +++--
 arch/arm/mach-orion5x/rd88f5182-setup.c        | 13 ++++++----
 arch/arm/mach-orion5x/terastation_pro2-setup.c |  6 +++--
 arch/arm/mach-orion5x/ts209-setup.c            |  6 +++--
 arch/arm/mach-orion5x/ts409-setup.c            |  6 +++--
 arch/arm/mach-orion5x/wnr854t-setup.c          |  6 +++--
 arch/arm/mach-orion5x/wrt350n-v2-setup.c       |  6 +++--
 22 files changed, 137 insertions(+), 70 deletions(-)

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index b41599f..91a5852 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -174,8 +174,10 @@ void __init orion5x_xor_init(void)
  ****************************************************************************/
 static void __init orion5x_crypto_init(void)
 {
-	mvebu_mbus_add_window("sram", ORION5X_SRAM_PHYS_BASE,
-			      ORION5X_SRAM_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_SRAM_TARGET,
+				    ORION_MBUS_SRAM_ATTR,
+				    ORION5X_SRAM_PHYS_BASE,
+				    ORION5X_SRAM_SIZE);
 	orion_crypto_init(ORION5X_CRYPTO_PHYS_BASE, ORION5X_SRAM_PHYS_BASE,
 			  SZ_8K, IRQ_ORION5X_CESA);
 }
@@ -222,22 +224,24 @@ void orion5x_setup_wins(void)
 	 * The PCIe windows will no longer be statically allocated
 	 * here once Orion5x is migrated to the pci-mvebu driver.
 	 */
-	mvebu_mbus_add_window_remap_flags("pcie0.0", ORION5X_PCIE_IO_PHYS_BASE,
+	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
+					  ORION_MBUS_PCIE_IO_ATTR,
+					  ORION5X_PCIE_IO_PHYS_BASE,
 					  ORION5X_PCIE_IO_SIZE,
-					  ORION5X_PCIE_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0", ORION5X_PCIE_MEM_PHYS_BASE,
-					  ORION5X_PCIE_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pci0.0", ORION5X_PCI_IO_PHYS_BASE,
+					  ORION5X_PCIE_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
+				    ORION_MBUS_PCIE_MEM_ATTR,
+				    ORION5X_PCIE_MEM_PHYS_BASE,
+				    ORION5X_PCIE_MEM_SIZE);
+	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
+					  ORION_MBUS_PCI_IO_ATTR,
+					  ORION5X_PCI_IO_PHYS_BASE,
 					  ORION5X_PCI_IO_SIZE,
-					  ORION5X_PCI_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pci0.0", ORION5X_PCI_MEM_PHYS_BASE,
-					  ORION5X_PCI_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+					  ORION5X_PCI_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
+				    ORION_MBUS_PCI_MEM_ATTR,
+				    ORION5X_PCI_MEM_PHYS_BASE,
+				    ORION5X_PCI_MEM_SIZE);
 }
 
 int orion5x_tclk;
diff --git a/arch/arm/mach-orion5x/common.h b/arch/arm/mach-orion5x/common.h
index a909afb..f565f99 100644
--- a/arch/arm/mach-orion5x/common.h
+++ b/arch/arm/mach-orion5x/common.h
@@ -7,6 +7,23 @@ struct dsa_platform_data;
 struct mv643xx_eth_platform_data;
 struct mv_sata_platform_data;
 
+#define ORION_MBUS_PCIE_MEM_TARGET    0x04
+#define ORION_MBUS_PCIE_MEM_ATTR      0x59
+#define ORION_MBUS_PCIE_IO_TARGET     0x04
+#define ORION_MBUS_PCIE_IO_ATTR       0x51
+#define ORION_MBUS_PCIE_WA_TARGET     0x04
+#define ORION_MBUS_PCIE_WA_ATTR       0x79
+#define ORION_MBUS_PCI_MEM_TARGET     0x03
+#define ORION_MBUS_PCI_MEM_ATTR       0x59
+#define ORION_MBUS_PCI_IO_TARGET      0x03
+#define ORION_MBUS_PCI_IO_ATTR        0x51
+#define ORION_MBUS_DEVBUS_BOOT_TARGET 0x01
+#define ORION_MBUS_DEVBUS_BOOT_ATTR   0x0f
+#define ORION_MBUS_DEVBUS_TARGET(cs)  0x01
+#define ORION_MBUS_DEVBUS_ATTR(cs)    (~(1 << cs))
+#define ORION_MBUS_SRAM_TARGET        0x00
+#define ORION_MBUS_SRAM_ATTR          0x00
+
 /*
  * Basic Orion init functions used early by machine-setup.
  */
diff --git a/arch/arm/mach-orion5x/d2net-setup.c b/arch/arm/mach-orion5x/d2net-setup.c
index 16c88bb..8f68b74 100644
--- a/arch/arm/mach-orion5x/d2net-setup.c
+++ b/arch/arm/mach-orion5x/d2net-setup.c
@@ -317,8 +317,10 @@ static void __init d2net_init(void)
 	d2net_sata_power_init();
 	orion5x_sata_init(&d2net_sata_data);
 
-	mvebu_mbus_add_window("devbus-boot", D2NET_NOR_BOOT_BASE,
-			      D2NET_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    D2NET_NOR_BOOT_BASE,
+				    D2NET_NOR_BOOT_SIZE);
 	platform_device_register(&d2net_nor_flash);
 
 	platform_device_register(&d2net_gpio_buttons);
diff --git a/arch/arm/mach-orion5x/db88f5281-setup.c b/arch/arm/mach-orion5x/db88f5281-setup.c
index 4e1263d..4b2aefd 100644
--- a/arch/arm/mach-orion5x/db88f5281-setup.c
+++ b/arch/arm/mach-orion5x/db88f5281-setup.c
@@ -340,19 +340,27 @@ static void __init db88f5281_init(void)
 	orion5x_uart0_init();
 	orion5x_uart1_init();
 
-	mvebu_mbus_add_window("devbus-boot", DB88F5281_NOR_BOOT_BASE,
-			      DB88F5281_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    DB88F5281_NOR_BOOT_BASE,
+				    DB88F5281_NOR_BOOT_SIZE);
 	platform_device_register(&db88f5281_boot_flash);
 
-	mvebu_mbus_add_window("devbus-cs0", DB88F5281_7SEG_BASE,
-			      DB88F5281_7SEG_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(0),
+				    ORION_MBUS_DEVBUS_ATTR(0),
+				    DB88F5281_7SEG_BASE,
+				    DB88F5281_7SEG_SIZE);
 
-	mvebu_mbus_add_window("devbus-cs1", DB88F5281_NOR_BASE,
-			      DB88F5281_NOR_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(1),
+				    ORION_MBUS_DEVBUS_ATTR(1),
+				    DB88F5281_NOR_BASE,
+				    DB88F5281_NOR_SIZE);
 	platform_device_register(&db88f5281_nor_flash);
 
-	mvebu_mbus_add_window("devbus-cs2", DB88F5281_NAND_BASE,
-			      DB88F5281_NAND_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(2),
+				    ORION_MBUS_DEVBUS_ATTR(2),
+				    DB88F5281_NAND_BASE,
+				    DB88F5281_NAND_SIZE);
 	platform_device_register(&db88f5281_nand_flash);
 
 	i2c_register_board_info(0, &db88f5281_i2c_rtc, 1);
diff --git a/arch/arm/mach-orion5x/dns323-setup.c b/arch/arm/mach-orion5x/dns323-setup.c
index 9e6baf5..7097473 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -611,8 +611,10 @@ static void __init dns323_init(void)
 	/* setup flash mapping
 	 * CS3 holds a 8 MB Spansion S29GL064M90TFIR4
 	 */
-	mvebu_mbus_add_window("devbus-boot", DNS323_NOR_BOOT_BASE,
-			      DNS323_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    DNS323_NOR_BOOT_BASE,
+				    DNS323_NOR_BOOT_SIZE);
 	platform_device_register(&dns323_nor_flash);
 
 	/* Sort out LEDs, Buttons and i2c devices */
diff --git a/arch/arm/mach-orion5x/edmini_v2-setup.c b/arch/arm/mach-orion5x/edmini_v2-setup.c
index 1476155..0fc33c5 100644
--- a/arch/arm/mach-orion5x/edmini_v2-setup.c
+++ b/arch/arm/mach-orion5x/edmini_v2-setup.c
@@ -154,8 +154,10 @@ void __init edmini_v2_init(void)
 	orion5x_ehci0_init();
 	orion5x_eth_init(&edmini_v2_eth_data);
 
-	mvebu_mbus_add_window("devbus-boot", EDMINI_V2_NOR_BOOT_BASE,
-			      EDMINI_V2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    EDMINI_V2_NOR_BOOT_BASE,
+				    EDMINI_V2_NOR_BOOT_SIZE);
 	platform_device_register(&edmini_v2_nor_flash);
 
 	pr_notice("edmini_v2: USB device port, flash write and power-off "
diff --git a/arch/arm/mach-orion5x/kurobox_pro-setup.c b/arch/arm/mach-orion5x/kurobox_pro-setup.c
index aae10e4..fe6a48a 100644
--- a/arch/arm/mach-orion5x/kurobox_pro-setup.c
+++ b/arch/arm/mach-orion5x/kurobox_pro-setup.c
@@ -359,13 +359,17 @@ static void __init kurobox_pro_init(void)
 	orion5x_uart1_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", KUROBOX_PRO_NOR_BOOT_BASE,
-			      KUROBOX_PRO_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    KUROBOX_PRO_NOR_BOOT_BASE,
+				    KUROBOX_PRO_NOR_BOOT_SIZE);
 	platform_device_register(&kurobox_pro_nor_flash);
 
 	if (machine_is_kurobox_pro()) {
-		mvebu_mbus_add_window("devbus-cs0", KUROBOX_PRO_NAND_BASE,
-				      KUROBOX_PRO_NAND_SIZE);
+		mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(0),
+					    ORION_MBUS_DEVBUS_ATTR(0),
+					    KUROBOX_PRO_NAND_BASE,
+					    KUROBOX_PRO_NAND_SIZE);
 		platform_device_register(&kurobox_pro_nand_flash);
 	}
 
diff --git a/arch/arm/mach-orion5x/ls-chl-setup.c b/arch/arm/mach-orion5x/ls-chl-setup.c
index 6234977..028ea03 100644
--- a/arch/arm/mach-orion5x/ls-chl-setup.c
+++ b/arch/arm/mach-orion5x/ls-chl-setup.c
@@ -294,8 +294,10 @@ static void __init lschl_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LSCHL_NOR_BOOT_BASE,
-			      LSCHL_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LSCHL_NOR_BOOT_BASE,
+				    LSCHL_NOR_BOOT_SIZE);
 	platform_device_register(&lschl_nor_flash);
 
 	platform_device_register(&lschl_leds);
diff --git a/arch/arm/mach-orion5x/ls_hgl-setup.c b/arch/arm/mach-orion5x/ls_hgl-setup.c
index fe04c4b..32b7129 100644
--- a/arch/arm/mach-orion5x/ls_hgl-setup.c
+++ b/arch/arm/mach-orion5x/ls_hgl-setup.c
@@ -243,8 +243,10 @@ static void __init ls_hgl_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LS_HGL_NOR_BOOT_BASE,
-			      LS_HGL_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LS_HGL_NOR_BOOT_BASE,
+				    LS_HGL_NOR_BOOT_SIZE);
 	platform_device_register(&ls_hgl_nor_flash);
 
 	platform_device_register(&ls_hgl_button_device);
diff --git a/arch/arm/mach-orion5x/lsmini-setup.c b/arch/arm/mach-orion5x/lsmini-setup.c
index ca4dbe9..a6493e7 100644
--- a/arch/arm/mach-orion5x/lsmini-setup.c
+++ b/arch/arm/mach-orion5x/lsmini-setup.c
@@ -244,8 +244,10 @@ static void __init lsmini_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LSMINI_NOR_BOOT_BASE,
-			      LSMINI_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LSMINI_NOR_BOOT_BASE,
+				    LSMINI_NOR_BOOT_SIZE);
 	platform_device_register(&lsmini_nor_flash);
 
 	platform_device_register(&lsmini_button_device);
diff --git a/arch/arm/mach-orion5x/mss2-setup.c b/arch/arm/mach-orion5x/mss2-setup.c
index 827acba..e105130 100644
--- a/arch/arm/mach-orion5x/mss2-setup.c
+++ b/arch/arm/mach-orion5x/mss2-setup.c
@@ -241,8 +241,10 @@ static void __init mss2_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", MSS2_NOR_BOOT_BASE,
-			      MSS2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    MSS2_NOR_BOOT_BASE,
+				    MSS2_NOR_BOOT_SIZE);
 	platform_device_register(&mss2_nor_flash);
 
 	platform_device_register(&mss2_button_device);
diff --git a/arch/arm/mach-orion5x/mv2120-setup.c b/arch/arm/mach-orion5x/mv2120-setup.c
index 92600ae..e032f01 100644
--- a/arch/arm/mach-orion5x/mv2120-setup.c
+++ b/arch/arm/mach-orion5x/mv2120-setup.c
@@ -204,8 +204,10 @@ static void __init mv2120_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", MV2120_NOR_BOOT_BASE,
-			      MV2120_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    MV2120_NOR_BOOT_BASE,
+				    MV2120_NOR_BOOT_SIZE);
 	platform_device_register(&mv2120_nor_flash);
 
 	platform_device_register(&mv2120_button_device);
diff --git a/arch/arm/mach-orion5x/net2big-setup.c b/arch/arm/mach-orion5x/net2big-setup.c
index dd0641a..ba73dc7 100644
--- a/arch/arm/mach-orion5x/net2big-setup.c
+++ b/arch/arm/mach-orion5x/net2big-setup.c
@@ -397,8 +397,10 @@ static void __init net2big_init(void)
 	net2big_sata_power_init();
 	orion5x_sata_init(&net2big_sata_data);
 
-	mvebu_mbus_add_window("devbus-boot", NET2BIG_NOR_BOOT_BASE,
-			      NET2BIG_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    NET2BIG_NOR_BOOT_BASE,
+				    NET2BIG_NOR_BOOT_SIZE);
 	platform_device_register(&net2big_nor_flash);
 
 	platform_device_register(&net2big_gpio_buttons);
diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion5x/pci.c
index 5033680..7fab670 100644
--- a/arch/arm/mach-orion5x/pci.c
+++ b/arch/arm/mach-orion5x/pci.c
@@ -157,11 +157,10 @@ static int __init pcie_setup(struct pci_sys_data *sys)
 	if (dev == MV88F5181_DEV_ID || dev == MV88F5182_DEV_ID) {
 		printk(KERN_NOTICE "Applying Orion-1/Orion-NAS PCIe config "
 				   "read transaction workaround\n");
-		mvebu_mbus_add_window_remap_flags("pcie0.0",
-						  ORION5X_PCIE_WA_PHYS_BASE,
-						  ORION5X_PCIE_WA_SIZE,
-						  MVEBU_MBUS_NO_REMAP,
-						  MVEBU_MBUS_PCI_WA);
+		mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_WA_TARGET,
+					    ORION_MBUS_PCIE_WA_ATTR,
+					    ORION5X_PCIE_WA_PHYS_BASE,
+					    ORION5X_PCIE_WA_SIZE);
 		pcie_ops.read = pcie_rd_conf_wa;
 	}
 
diff --git a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
index 1c4498b..213b3e1 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
@@ -123,8 +123,10 @@ static void __init rd88f5181l_fxo_init(void)
 	orion5x_eth_switch_init(&rd88f5181l_fxo_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5181L_FXO_NOR_BOOT_BASE,
-			      RD88F5181L_FXO_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5181L_FXO_NOR_BOOT_BASE,
+				    RD88F5181L_FXO_NOR_BOOT_SIZE);
 	platform_device_register(&rd88f5181l_fxo_nor_boot_flash);
 }
 
diff --git a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
index adabe34..594800e 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
@@ -130,8 +130,10 @@ static void __init rd88f5181l_ge_init(void)
 	orion5x_i2c_init();
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5181L_GE_NOR_BOOT_BASE,
-			      RD88F5181L_GE_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5181L_GE_NOR_BOOT_BASE,
+				    RD88F5181L_GE_NOR_BOOT_SIZE);
 	platform_device_register(&rd88f5181l_ge_nor_boot_flash);
 
 	i2c_register_board_info(0, &rd88f5181l_ge_i2c_rtc, 1);
diff --git a/arch/arm/mach-orion5x/rd88f5182-setup.c b/arch/arm/mach-orion5x/rd88f5182-setup.c
index 66e77ec..b1cf684 100644
--- a/arch/arm/mach-orion5x/rd88f5182-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5182-setup.c
@@ -264,11 +264,14 @@ static void __init rd88f5182_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5182_NOR_BOOT_BASE,
-			      RD88F5182_NOR_BOOT_SIZE);
-
-	mvebu_mbus_add_window("devbus-cs1", RD88F5182_NOR_BASE,
-			      RD88F5182_NOR_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5182_NOR_BOOT_BASE,
+				    RD88F5182_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(1),
+				    ORION_MBUS_DEVBUS_ATTR(1),
+				    RD88F5182_NOR_BASE,
+				    RD88F5182_NOR_SIZE);
 	platform_device_register(&rd88f5182_nor_flash);
 	platform_device_register(&rd88f5182_gpio_leds);
 
diff --git a/arch/arm/mach-orion5x/terastation_pro2-setup.c b/arch/arm/mach-orion5x/terastation_pro2-setup.c
index a0bfa53..7e90648 100644
--- a/arch/arm/mach-orion5x/terastation_pro2-setup.c
+++ b/arch/arm/mach-orion5x/terastation_pro2-setup.c
@@ -329,8 +329,10 @@ static void __init tsp2_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", TSP2_NOR_BOOT_BASE,
-			      TSP2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    TSP2_NOR_BOOT_BASE,
+				    TSP2_NOR_BOOT_SIZE);
 	platform_device_register(&tsp2_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/ts209-setup.c b/arch/arm/mach-orion5x/ts209-setup.c
index 80174f0..e90c061 100644
--- a/arch/arm/mach-orion5x/ts209-setup.c
+++ b/arch/arm/mach-orion5x/ts209-setup.c
@@ -286,8 +286,10 @@ static void __init qnap_ts209_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", QNAP_TS209_NOR_BOOT_BASE,
-			      QNAP_TS209_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    QNAP_TS209_NOR_BOOT_BASE,
+				    QNAP_TS209_NOR_BOOT_SIZE);
 	platform_device_register(&qnap_ts209_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/ts409-setup.c b/arch/arm/mach-orion5x/ts409-setup.c
index 9259279..5c079d3 100644
--- a/arch/arm/mach-orion5x/ts409-setup.c
+++ b/arch/arm/mach-orion5x/ts409-setup.c
@@ -277,8 +277,10 @@ static void __init qnap_ts409_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", QNAP_TS409_NOR_BOOT_BASE,
-			      QNAP_TS409_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    QNAP_TS409_NOR_BOOT_BASE,
+				    QNAP_TS409_NOR_BOOT_SIZE);
 	platform_device_register(&qnap_ts409_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/wnr854t-setup.c b/arch/arm/mach-orion5x/wnr854t-setup.c
index 6b84863..80a56ee 100644
--- a/arch/arm/mach-orion5x/wnr854t-setup.c
+++ b/arch/arm/mach-orion5x/wnr854t-setup.c
@@ -127,8 +127,10 @@ static void __init wnr854t_init(void)
 	orion5x_eth_switch_init(&wnr854t_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", WNR854T_NOR_BOOT_BASE,
-			      WNR854T_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    WNR854T_NOR_BOOT_BASE,
+				    WNR854T_NOR_BOOT_SIZE);
 	platform_device_register(&wnr854t_nor_flash);
 }
 
diff --git a/arch/arm/mach-orion5x/wrt350n-v2-setup.c b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
index fae684b..670e30d 100644
--- a/arch/arm/mach-orion5x/wrt350n-v2-setup.c
+++ b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
@@ -213,8 +213,10 @@ static void __init wrt350n_v2_init(void)
 	orion5x_eth_switch_init(&wrt350n_v2_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", WRT350N_V2_NOR_BOOT_BASE,
-			      WRT350N_V2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    WRT350N_V2_NOR_BOOT_BASE,
+				    WRT350N_V2_NOR_BOOT_SIZE);
 	platform_device_register(&wrt350n_v2_nor_flash);
 	platform_device_register(&wrt350n_v2_leds);
 	platform_device_register(&wrt350n_v2_button_device);
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:17 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:17 -0300
Subject: [PATCH v6 06/21] ARM: dove: Move to ID based window creation
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-7-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-dove/common.c | 68 ++++++++++++++++++++++++++++++---------------
 1 file changed, 45 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 00247c7..bc22056 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -27,6 +27,22 @@
 #include <plat/time.h>
 #include "common.h"
 
+/* These can go away once Dove uses the mvebu-mbus DT binding */
+#define DOVE_MBUS_PCIE0_MEM_TARGET    0x4
+#define DOVE_MBUS_PCIE0_MEM_ATTR      0xe8
+#define DOVE_MBUS_PCIE0_IO_TARGET     0x4
+#define DOVE_MBUS_PCIE0_IO_ATTR       0xe0
+#define DOVE_MBUS_PCIE1_MEM_TARGET    0x8
+#define DOVE_MBUS_PCIE1_MEM_ATTR      0xe8
+#define DOVE_MBUS_PCIE1_IO_TARGET     0x8
+#define DOVE_MBUS_PCIE1_IO_ATTR       0xe0
+#define DOVE_MBUS_CESA_TARGET         0x3
+#define DOVE_MBUS_CESA_ATTR           0x1
+#define DOVE_MBUS_BOOTROM_TARGET      0x1
+#define DOVE_MBUS_BOOTROM_ATTR        0xfd
+#define DOVE_MBUS_SCRATCHPAD_TARGET   0xd
+#define DOVE_MBUS_SCRATCHPAD_ATTR     0x0
+
 /*****************************************************************************
  * I/O Address Mapping
  ****************************************************************************/
@@ -332,34 +348,40 @@ void __init dove_setup_cpu_wins(void)
 {
 	/*
 	 * The PCIe windows will no longer be statically allocated
-	 * here once Dove is migrated to the pci-mvebu driver.
+	 * here once Dove is migrated to the pci-mvebu driver. The
+	 * non-PCIe windows will no longer be created here once Dove
+	 * fully moves to DT.
 	 */
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
+	mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE0_IO_TARGET,
+					  DOVE_MBUS_PCIE0_IO_ATTR,
 					  DOVE_PCIE0_IO_PHYS_BASE,
 					  DOVE_PCIE0_IO_SIZE,
-					  DOVE_PCIE0_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
+					  DOVE_PCIE0_IO_BUS_BASE);
+	mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE1_IO_TARGET,
+					  DOVE_MBUS_PCIE1_IO_ATTR,
 					  DOVE_PCIE1_IO_PHYS_BASE,
 					  DOVE_PCIE1_IO_SIZE,
-					  DOVE_PCIE1_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
-					  DOVE_PCIE0_MEM_PHYS_BASE,
-					  DOVE_PCIE0_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
-					  DOVE_PCIE1_MEM_PHYS_BASE,
-					  DOVE_PCIE1_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window("cesa", DOVE_CESA_PHYS_BASE,
-			      DOVE_CESA_SIZE);
-	mvebu_mbus_add_window("bootrom", DOVE_BOOTROM_PHYS_BASE,
-			      DOVE_BOOTROM_SIZE);
-	mvebu_mbus_add_window("scratchpad", DOVE_SCRATCHPAD_PHYS_BASE,
-			      DOVE_SCRATCHPAD_SIZE);
+					  DOVE_PCIE1_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE0_MEM_TARGET,
+				    DOVE_MBUS_PCIE0_MEM_ATTR,
+				    DOVE_PCIE0_MEM_PHYS_BASE,
+				    DOVE_PCIE0_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE1_MEM_TARGET,
+				    DOVE_MBUS_PCIE1_MEM_ATTR,
+				    DOVE_PCIE1_MEM_PHYS_BASE,
+				    DOVE_PCIE1_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_CESA_TARGET,
+				    DOVE_MBUS_CESA_ATTR,
+				    DOVE_CESA_PHYS_BASE,
+				    DOVE_CESA_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_BOOTROM_TARGET,
+				    DOVE_MBUS_BOOTROM_ATTR,
+				    DOVE_BOOTROM_PHYS_BASE,
+				    DOVE_BOOTROM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_SCRATCHPAD_TARGET,
+				    DOVE_MBUS_SCRATCHPAD_ATTR,
+				    DOVE_SCRATCHPAD_PHYS_BASE,
+				    DOVE_SCRATCHPAD_SIZE);
 }
 
 void __init dove_init(void)
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:21 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:21 -0300
Subject: [PATCH v6 10/21] pci: mvebu: Adapt to the new device tree layout
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-11-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

The new device tree layout encodes the window's target ID and attribute
in the PCIe controller node's ranges property. This allows to parse
such entries to obtain such information and use the recently introduced
MBus API to create the windows, instead of using the current name based
scheme.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/pci/host/pci-mvebu.c | 152 ++++++++++++++++++++++++++++++++++---------
 1 file changed, 120 insertions(+), 32 deletions(-)

diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 13a633b..a146f44 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -123,6 +123,10 @@ struct mvebu_pcie_port {
 	u32 port;
 	u32 lane;
 	int devfn;
+	unsigned int mem_target;
+	unsigned int mem_attr;
+	unsigned int io_target;
+	unsigned int io_attr;
 	struct clk *clk;
 	struct mvebu_sw_pci_bridge bridge;
 	struct device_node *dn;
@@ -307,10 +311,9 @@ static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port *port)
 			    (port->bridge.iolimitupper << 16)) -
 			    iobase);
 
-	mvebu_mbus_add_window_remap_flags(port->name, port->iowin_base,
-					  port->iowin_size,
-					  iobase,
-					  MVEBU_MBUS_PCI_IO);
+	mvebu_mbus_add_window_remap_by_id(port->io_target, port->io_attr,
+					  port->iowin_base, port->iowin_size,
+					  iobase);
 
 	pci_ioremap_io(iobase, port->iowin_base);
 }
@@ -342,10 +345,8 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
 		(((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) -
 		port->memwin_base;
 
-	mvebu_mbus_add_window_remap_flags(port->name, port->memwin_base,
-					  port->memwin_size,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+	mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr,
+				    port->memwin_base, port->memwin_size);
 }
 
 /*
@@ -755,12 +756,104 @@ mvebu_pcie_map_registers(struct platform_device *pdev,
 	return devm_request_and_ioremap(&pdev->dev, &regs);
 }
 
+#define DT_FLAGS_TO_TYPE(flags)       (((flags) >> 24) & 0x03)
+#define    DT_TYPE_IO                 0x1
+#define    DT_TYPE_MEM32              0x2
+#define DT_FLAGS_TO_DEVFN(flags)      (((flags) >> 8) & 0xFF)
+#define DT_CPUADDR_TO_ADDR(cpuaddr)   ((cpuaddr) & 0xFFFFFFFF)
+#define DT_CPUADDR_TO_TARGET(cpuaddr) (((cpuaddr) >> 56) & 0xFF)
+#define DT_CPUADDR_TO_ATTR(cpuaddr)   (((cpuaddr) >> 48) & 0xFF)
+
+static int mvebu_get_resources(struct device_node *np, struct resource *mem,
+			       struct resource *io, struct resource *realio)
+{
+	const int na = 3, ns = 2;
+	const __be32 *range;
+	int rlen, nranges, rangesz, pna, i;
+
+	range = of_get_property(np, "ranges", &rlen);
+	if (!range)
+		return -EINVAL;
+
+	pna = of_n_addr_cells(np);
+	rangesz = pna + na + ns;
+	nranges = rlen / sizeof(__be32) / rangesz;
+
+	for (i = 0; i < nranges; i++) {
+		u32 flags = of_read_number(range, 1);
+		u64 pciaddr = of_read_number(range + 1, ns);
+		u64 cpuaddr = of_read_number(range + na, pna);
+		u64 size    = of_read_number(range + na + pna, ns);
+
+		/* I/O */
+		if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_IO &&
+		    DT_FLAGS_TO_DEVFN(flags) != 0) {
+			io->start = cpuaddr & 0xFFFFFFFF;
+			io->end   = io->start + size;
+			io->flags = IORESOURCE_IO;
+			realio->start = max_t(resource_size_t,
+					      PCIBIOS_MIN_IO,
+					      pciaddr);
+			realio->end = min_t(resource_size_t,
+					    IO_SPACE_LIMIT,
+					    pciaddr + size);
+			realio->flags = io->flags;
+		}
+		/* MEM */
+		else if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_MEM32 &&
+			 DT_FLAGS_TO_DEVFN(flags) != 0) {
+			mem->start = cpuaddr & 0xFFFFFFFF;
+			mem->end   = mem->start + size;
+			mem->flags = IORESOURCE_MEM;
+		}
+
+		range += rangesz;
+	}
+
+	return 0;
+}
+
+static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
+			      unsigned long type, int *tgt, int *attr)
+{
+	const int na = 3, ns = 2;
+	const __be32 *range;
+	int rlen, nranges, rangesz, pna, i;
+
+	range = of_get_property(np, "ranges", &rlen);
+	if (!range)
+		return -EINVAL;
+
+	pna = of_n_addr_cells(np);
+	rangesz = pna + na + ns;
+	nranges = rlen / sizeof(__be32) / rangesz;
+
+	for (i = 0; i < nranges; i++) {
+		u32 flags = of_read_number(range, 1);
+		u64 cpuaddr = of_read_number(range + na, pna);
+		unsigned long rtype;
+
+		if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_IO)
+			rtype = IORESOURCE_IO;
+		else if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_MEM32)
+			rtype = IORESOURCE_MEM;
+
+		if (DT_FLAGS_TO_DEVFN(flags) == devfn && type == rtype) {
+			*tgt = DT_CPUADDR_TO_TARGET(cpuaddr);
+			*attr = DT_CPUADDR_TO_ATTR(cpuaddr);
+			return 0;
+		}
+
+		range += rangesz;
+	}
+
+	return -ENOENT;
+}
+
 static int __init mvebu_pcie_probe(struct platform_device *pdev)
 {
 	struct mvebu_pcie *pcie;
 	struct device_node *np = pdev->dev.of_node;
-	struct of_pci_range range;
-	struct of_pci_range_parser parser;
 	struct device_node *child;
 	int i, ret;
 
@@ -771,28 +864,7 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
 
 	pcie->pdev = pdev;
 
-	if (of_pci_range_parser_init(&parser, np))
-		return -EINVAL;
-
-	/* Get the I/O and memory ranges from DT */
-	for_each_of_pci_range(&parser, &range) {
-		unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
-		if (restype == IORESOURCE_IO) {
-			of_pci_range_to_resource(&range, np, &pcie->io);
-			of_pci_range_to_resource(&range, np, &pcie->realio);
-			pcie->io.name = "I/O";
-			pcie->realio.start = max_t(resource_size_t,
-						   PCIBIOS_MIN_IO,
-						   range.pci_addr);
-			pcie->realio.end = min_t(resource_size_t,
-						 IO_SPACE_LIMIT,
-						 range.pci_addr + range.size);
-		}
-		if (restype == IORESOURCE_MEM) {
-			of_pci_range_to_resource(&range, np, &pcie->mem);
-			pcie->mem.name = "MEM";
-		}
-	}
+	mvebu_get_resources(np, &pcie->mem, &pcie->io, &pcie->realio);
 
 	/* Get the bus range */
 	ret = of_pci_parse_bus_range(np, &pcie->busn);
@@ -841,6 +913,22 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
 		if (port->devfn < 0)
 			continue;
 
+		ret = mvebu_get_tgt_attr(np, port->devfn, IORESOURCE_MEM,
+					 &port->mem_target, &port->mem_attr);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "PCIe%d.%d: cannot get tgt/attr for mem window\n",
+				port->port, port->lane);
+			continue;
+		}
+
+		ret = mvebu_get_tgt_attr(np, port->devfn, IORESOURCE_IO,
+					 &port->io_target, &port->io_attr);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "PCIe%d.%d: cannot get tgt/attr for io window\n",
+				port->port, port->lane);
+			continue;
+		}
+
 		port->base = mvebu_pcie_map_registers(pdev, child, port);
 		if (!port->base) {
 			dev_err(&pdev->dev, "PCIe%d.%d: cannot map registers\n",
-- 
1.8.1.5



From thomas.petazzoni at free-electrons.com  Fri Jul  5 17:40:34 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 5 Jul 2013 23:40:34 +0200
Subject: [PATCHv4 02/11] pci: use weak functions for MSI arch-specific
 functions
In-Reply-To: <CAErSpo4HoofGhN8VumRnN0sN_+gWJ9gVQJVMiePnDBUKwh74ag@mail.gmail.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-3-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo5uCpQftDmsMYEsFMtt_LP3kZPQ3Y4zz4VT7GdpcFq+1w@mail.gmail.com>
 <CAErSpo4HoofGhN8VumRnN0sN_+gWJ9gVQJVMiePnDBUKwh74ag@mail.gmail.com>
Message-ID: <20130705234034.6c57cd43@skate>

Dear Bjorn Helgaas,

On Fri, 5 Jul 2013 15:34:10 -0600, Bjorn Helgaas wrote:
> On Fri, Jul 5, 2013 at 3:32 PM, Bjorn Helgaas <bhelgaas at google.com> wrote:
> 
> > Acked-by: Bjorn Helgaas <bhelgaas at google.com>
> 
> But please update your subject line to use consistent capitalization, e.g.,
> 
> PCI: Use weak ...

Sure, will do.

Would it be possible to get Tested-by and/or Acked-by from the
different architecture maintainers affected by PATCH 02/11 and PATCH
03/11 ?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:18 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:18 -0300
Subject: [PATCH v6 07/21] bus: mvebu-mbus: Factor out initialization details
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-8-git-send-email-ezequiel.garcia@free-electrons.com>

We introduce a common initialization function mvebu_mbus_common_init()
that will be used by both legacy and device-tree initialization code.
This patch is an intermediate step, which will allow to introduce the
DT binding for this driver in a less intrusive way.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 47 ++++++++++++++++++++++++++++++-----------------
 1 file changed, 30 insertions(+), 17 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 827468a..1b17954 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -847,26 +847,14 @@ static __init int mvebu_mbus_debugfs_init(void)
 }
 fs_initcall(mvebu_mbus_debugfs_init);
 
-int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
-			   size_t mbuswins_size,
-			   phys_addr_t sdramwins_phys_base,
-			   size_t sdramwins_size)
+static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
+					 phys_addr_t mbuswins_phys_base,
+					 size_t mbuswins_size,
+					 phys_addr_t sdramwins_phys_base,
+					 size_t sdramwins_size)
 {
-	struct mvebu_mbus_state *mbus = &mbus_state;
-	const struct of_device_id *of_id;
 	int win;
 
-	for (of_id = of_mvebu_mbus_ids; of_id->compatible; of_id++)
-		if (!strcmp(of_id->compatible, soc))
-			break;
-
-	if (!of_id->compatible) {
-		pr_err("could not find a matching SoC family\n");
-		return -ENODEV;
-	}
-
-	mbus->soc = of_id->data;
-
 	mbus->mbuswins_base = ioremap(mbuswins_phys_base, mbuswins_size);
 	if (!mbus->mbuswins_base)
 		return -ENOMEM;
@@ -887,3 +875,28 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 
 	return 0;
 }
+
+int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
+			   size_t mbuswins_size,
+			   phys_addr_t sdramwins_phys_base,
+			   size_t sdramwins_size)
+{
+	const struct of_device_id *of_id;
+
+	for (of_id = of_mvebu_mbus_ids; of_id->compatible; of_id++)
+		if (!strcmp(of_id->compatible, soc))
+			break;
+
+	if (!of_id->compatible) {
+		pr_err("could not find a matching SoC family\n");
+		return -ENODEV;
+	}
+
+	mbus_state.soc = of_id->data;
+
+	return mvebu_mbus_common_init(&mbus_state,
+			mbuswins_phys_base,
+			mbuswins_size,
+			sdramwins_phys_base,
+			sdramwins_size);
+}
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:22 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:22 -0300
Subject: [PATCH v6 11/21] bus: mvebu-mbus: Remove the no longer used
 name-based API
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-12-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Now that every user of the deprecated name-based API has been
converted to using the ID-based API, let's remove the former one.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 38 --------------------------------------
 include/linux/mbus.h     |  5 -----
 2 files changed, 43 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 8aa3b45..db68436 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -764,44 +764,6 @@ int mvebu_mbus_add_window_remap_by_id(unsigned int target,
 	return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
 }
 
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
-				      size_t size, phys_addr_t remap,
-				      unsigned int flags)
-{
-	struct mvebu_mbus_state *s = &mbus_state;
-	u8 target, attr;
-	int i;
-
-	if (!s->soc->map)
-		return -ENODEV;
-
-	for (i = 0; s->soc->map[i].name; i++)
-		if (!strcmp(s->soc->map[i].name, devname))
-			break;
-
-	if (!s->soc->map[i].name) {
-		pr_err("unknown device '%s'\n", devname);
-		return -ENODEV;
-	}
-
-	target = s->soc->map[i].target;
-	attr   = s->soc->map[i].attr;
-
-	if (flags == MVEBU_MBUS_PCI_MEM)
-		attr |= 0x8;
-	else if (flags == MVEBU_MBUS_PCI_WA)
-		attr |= 0x28;
-
-	return mvebu_mbus_add_window_remap_by_id(target, attr, base,
-						 size, remap);
-}
-
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
-{
-	return mvebu_mbus_add_window_remap_flags(devname, base, size,
-						 MVEBU_MBUS_NO_REMAP, 0);
-}
-
 int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
 				phys_addr_t base, size_t size)
 {
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index eadefd6..fa84dcb 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -59,15 +59,10 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
 }
 #endif
 
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
-				      size_t size, phys_addr_t remap,
-				      unsigned int flags);
 int mvebu_mbus_add_window_remap_by_id(unsigned int target,
 				      unsigned int attribute,
 				      phys_addr_t base, size_t size,
 				      phys_addr_t remap);
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
-			  size_t size);
 int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
 				phys_addr_t base, size_t size);
 int mvebu_mbus_del_window(phys_addr_t base, size_t size);
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:19 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:19 -0300
Subject: [PATCH v6 08/21] bus: mvebu-mbus: Introduce device tree binding
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-9-git-send-email-ezequiel.garcia@free-electrons.com>

This patch adds the most fundamental device-tree initialization.
We only introduce what's required to be able to probe the mvebu-mbus
driver from the DT. Follow-up patches will extend the device tree binding,
allowing to describe static address decoding windows.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mbus.h     |  1 +
 2 files changed, 50 insertions(+)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 1b17954..44a07c4 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -900,3 +900,52 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 			sdramwins_phys_base,
 			sdramwins_size);
 }
+
+#ifdef CONFIG_OF
+int __init mvebu_mbus_dt_init(void)
+{
+	struct resource mbuswins_res, sdramwins_res;
+	struct device_node *np, *controller;
+	const struct of_device_id *of_id;
+	const __be32 *prop;
+	int ret;
+
+	np = of_find_matching_node(NULL, of_mvebu_mbus_ids);
+	if (!np) {
+		pr_err("could not find a matching SoC family\n");
+		return -ENODEV;
+	}
+
+	of_id = of_match_node(of_mvebu_mbus_ids, np);
+	mbus_state.soc = of_id->data;
+
+	prop = of_get_property(np, "controller", NULL);
+	if (!prop) {
+		pr_err("required 'controller' property missing\n");
+		return -EINVAL;
+	}
+
+	controller = of_find_node_by_phandle(be32_to_cpup(prop));
+	if (!controller) {
+		pr_err("could not find an 'mbus-controller' node\n");
+		return -ENODEV;
+	}
+
+	if (of_address_to_resource(controller, 0, &mbuswins_res)) {
+		pr_err("cannot get MBUS register address\n");
+		return -EINVAL;
+	}
+
+	if (of_address_to_resource(controller, 1, &sdramwins_res)) {
+		pr_err("cannot get SDRAM register address\n");
+		return -EINVAL;
+	}
+
+	ret = mvebu_mbus_common_init(&mbus_state,
+				     mbuswins_res.start,
+				     resource_size(&mbuswins_res),
+				     sdramwins_res.start,
+				     resource_size(&sdramwins_res));
+	return ret;
+}
+#endif
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 9245b66..eadefd6 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -74,5 +74,6 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size);
 int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
 		    size_t mbus_size, phys_addr_t sdram_phys_base,
 		    size_t sdram_size);
+int mvebu_mbus_dt_init(void);
 
 #endif /* __LINUX_MBUS_H */
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:20 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:20 -0300
Subject: [PATCH v6 09/21] bus: mvebu-mbus: Add static window allocation to the
 binding
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-10-git-send-email-ezequiel.garcia@free-electrons.com>

This patch adds static window allocation to the device tree binding.
Each first-child of the mbus-compatible node, with a suitable 'ranges'
property, declaring an address translation, will trigger an address
decoding window allocation.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 .../devicetree/bindings/bus/mvebu-mbus.txt         | 253 +++++++++++++++++++++
 drivers/bus/mvebu-mbus.c                           | 121 +++++++++-
 2 files changed, 373 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt

diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
new file mode 100644
index 0000000..cce863f
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -0,0 +1,253 @@
+
+* Marvell MBus
+
+Required properties:
+
+- compatible:	 Should be set to one of the following:
+		 marvell,armada370-mbus
+		 marvell,armadaxp-mbus
+
+- address-cells: Must be '2'. The first cell for the MBus ID encoding,
+                 the second cell for the address offset within the window.
+
+- size-cells:    Must be '1'.
+
+- ranges:        Must be set up to provide a proper translation for each child.
+	         See the examples below.
+
+- controller:    Contains a single phandle referring to the MBus controller
+                 node. This allows to specify the node that contains the
+		 registers that control the MBus, which is typically contained
+		 within the internal register window (see below).
+
+* Marvell MBus controller
+
+Required properties:
+
+- compatible:	Should be set to "marvell,mbus-controller".
+
+- reg:          Device's register space.
+		Two entries are expected (see the examples below):
+		the first one controls the devices decoding window and
+		the second one controls the SDRAM decoding window.
+
+Example:
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+
+		internal-regs {
+			compatible = "simple-bus";
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* more children ...*/
+		};
+	};
+
+** MBus address decoding window specification
+
+The MBus children address space is comprised of two cells: the first one for
+the window ID and the second one for the offset within the window.
+In order to allow to describe valid and non-valid window entries, the
+following encoding is used:
+
+  0xSIAA0000 0x00oooooo
+
+Where:
+
+  S = 0x0 for a MBus valid window
+  S = 0xf for a non-valid window (see below)
+
+If S = 0x0, then:
+
+   I = 4-bit window target ID
+  AA = windpw attribute
+
+If S = 0xf, then:
+
+   I = don't care
+   AA = 1 for internal register
+
+Following the above encoding, for each ranges entry for a MBus valid window
+(S = 0x0), an address decoding window is allocated. On the other side,
+entries for translation that do not correspond to valid windows (S = 0xf)
+are skipped.
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+
+		ranges = <0xf0010000 0 0 0xd0000000 0x100000
+			  0x01e00000 0 0 0xfff00000 0x100000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <0x01e00000 0 0x100000>;
+		};
+
+		/* other children */
+		...
+
+		internal-regs {
+			compatible = "simple-bus";
+			ranges = <0 0xf0010000 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* more children ...*/
+		};
+	};
+
+In the shown example, the translation entry in the 'ranges' property is what
+makes the MBus driver create a static decoding window for the corresponding
+given child device. Note that the binding does not require child nodes to be
+present. Of course, child nodes are needed to probe the devices.
+
+Since each window is identified by its target ID and attribute ID there's
+a special macro that can be use to simplify the translation entries:
+
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
+Using this macro, the above example would be:
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+
+		ranges = < MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			   MBUS_ID(0x01, 0xe0) 0 0 0xfff00000 0x100000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
+		};
+
+		/* other children */
+		...
+
+		internal-regs {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* other children */
+			...
+		};
+	};
+
+
+** About the window base address
+
+Remember the MBus controller allows a great deal of flexibility for choosing
+the decoding window base address. When planning the device tree layout it's
+possible to choose any address as the base address, provided of course there's
+a region large enough available, and with the required alignment.
+
+Yet in other words: there's nothing preventing us from setting a base address
+of 0xf0000000, or 0xd0000000 for the NOR device shown above, if such region is
+unused.
+
+** Window allocation policy
+
+The mbus-node ranges property defines a set of mbus windows that are expected
+to be set by the operating system and that are guaranteed to be free of overlaps
+with one another or with the system memory ranges.
+
+Each entry in the property refers to exactly one window. If the operating system
+choses to use a different set of mbus windows, it must ensure that any address
+translations performed from downstream devices are adapted accordingly.
+
+The operating system may insert additional mbus windows that do not conflict
+with the ones listed in the ranges, e.g. for mapping PCIe devices.
+As a special case, the internal register window must be set up by the boot
+loader at the address listed in the ranges property, since access to that region
+is needed to set up the other windows.
+
+** Example
+
+See the example below, where a more complete device tree is shown:
+
+	soc {
+		compatible = "marvell,armadaxp-mbus", "simple-bus";
+		controller = <&mbusc>;
+
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
+		};
+
+		devbus-bootcs {
+			status = "okay";
+			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;
+
+			/* NOR */
+			nor {
+				compatible = "cfi-flash";
+				reg = <0 0x8000000>;
+				bank-width = <2>;
+			};
+		};
+
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "okay";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
+				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>;
+
+
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+		};
+
+		internal-regs {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			interrupt-controller at 20000 {
+			      reg = <0x20a00 0x2d0>, <0x21070 0x58>;
+			};
+		};
+	};
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 44a07c4..8aa3b45 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -902,6 +902,121 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 }
 
 #ifdef CONFIG_OF
+/*
+ * The window IDs in the ranges DT property have the following format:
+ *  - bits 28 to 31: MBus custom field
+ *  - bits 24 to 27: window target ID
+ *  - bits 16 to 23: window attribute ID
+ *  - bits  0 to 15: unused
+ */
+#define CUSTOM(id) (((id) & 0xF0000000) >> 24)
+#define TARGET(id) (((id) & 0x0F000000) >> 24)
+#define ATTR(id)   (((id) & 0x00FF0000) >> 16)
+
+static int __init mbus_dt_setup_win(struct mvebu_mbus_state *mbus,
+				    u32 base, u32 size,
+				    u8 target, u8 attr)
+{
+	const struct mvebu_mbus_mapping *map = mbus->soc->map;
+	const char *name;
+	int i;
+
+	/* Search for a suitable window in the existing mappings */
+	for (i = 0; map[i].name; i++)
+		if (map[i].target == target &&
+		    map[i].attr == (attr & map[i].attrmask))
+			break;
+
+	name = map[i].name;
+	if (!name) {
+		pr_err("window 0x%x:0x%x is unknown, skipping\n",
+		       target, attr);
+		return -EINVAL;
+	}
+
+	if (!mvebu_mbus_window_conflicts(mbus, base, size, target, attr)) {
+		pr_err("cannot add window '%s', conflicts with another window\n",
+		       name);
+		return -EBUSY;
+	}
+
+	if (mvebu_mbus_alloc_window(mbus, base, size, MVEBU_MBUS_NO_REMAP,
+				    target, attr)) {
+		pr_err("cannot add window '%s', too many windows\n",
+		       name);
+		return -ENOMEM;
+	}
+	return 0;
+}
+
+static int __init
+mbus_parse_ranges(struct device_node *node,
+		  int *addr_cells, int *c_addr_cells, int *c_size_cells,
+		  int *cell_count, const __be32 **ranges_start,
+		  const __be32 **ranges_end)
+{
+	const __be32 *prop;
+	int ranges_len, tuple_len;
+
+	*addr_cells = of_n_addr_cells(node);
+
+	prop = of_get_property(node, "#address-cells", NULL);
+	*c_addr_cells = be32_to_cpup(prop);
+
+	prop = of_get_property(node, "#size-cells", NULL);
+	*c_size_cells = be32_to_cpup(prop);
+
+	*cell_count = *addr_cells + *c_addr_cells + *c_size_cells;
+	tuple_len = (*cell_count) * sizeof(__be32);
+
+	*ranges_start = of_get_property(node, "ranges", &ranges_len);
+	*ranges_end = *ranges_start + ranges_len / sizeof(__be32);
+
+	if (*ranges_start == NULL || ranges_len % tuple_len) {
+		pr_warn("malformed ranges entry '%s'\n", node->name);
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static int __init mbus_dt_setup(struct mvebu_mbus_state *mbus,
+				struct device_node *np)
+{
+	int addr_cells, c_addr_cells, c_size_cells;
+	int i, ret, cell_count;
+	const __be32 *r, *ranges_start, *ranges_end;
+
+	ret = mbus_parse_ranges(np, &addr_cells, &c_addr_cells,
+				&c_size_cells, &cell_count,
+				&ranges_start, &ranges_end);
+	if (ret < 0)
+		return ret;
+
+	for (i = 0, r = ranges_start; r < ranges_end; r += cell_count, i++) {
+		u32 windowid, base, size;
+		u8 target, attr;
+
+		/*
+		 * An entry with a non-zero custom field do not
+		 * correspond to a static window, so skip it.
+		 */
+		windowid = of_read_number(r, 1);
+		if (CUSTOM(windowid))
+			continue;
+
+		target = TARGET(windowid);
+		attr = ATTR(windowid);
+
+		base = of_read_number(r + c_addr_cells, addr_cells);
+		size = of_read_number(r + c_addr_cells + addr_cells,
+				      c_size_cells);
+		ret = mbus_dt_setup_win(mbus, base, size, target, attr);
+		if (ret < 0)
+			return ret;
+	}
+	return 0;
+}
+
 int __init mvebu_mbus_dt_init(void)
 {
 	struct resource mbuswins_res, sdramwins_res;
@@ -946,6 +1061,10 @@ int __init mvebu_mbus_dt_init(void)
 				     resource_size(&mbuswins_res),
 				     sdramwins_res.start,
 				     resource_size(&sdramwins_res));
-	return ret;
+	if (ret)
+		return ret;
+
+	/* Setup statically declared windows in the DT */
+	return mbus_dt_setup(&mbus_state, np);
 }
 #endif
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:24 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:24 -0300
Subject: [PATCH v6 13/21] bus: mvebu-mbus: Update main description
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-14-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

After replacing the MBus name-based by the new ID-based API
let's fix the general description of the driver at the beginning
of the file.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 8240bd7..58d3c8f 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -35,13 +35,9 @@
  *
  * - Provides an API for platform code or device drivers to
  *   dynamically add or remove address decoding windows for the CPU ->
- *   device accesses. This API is mvebu_mbus_add_window(),
- *   mvebu_mbus_add_window_remap_flags() and
- *   mvebu_mbus_del_window(). Since the (target, attribute) values
- *   differ from one SoC family to another, the API uses a 'const char
- *   *' string to identify devices, and this driver is responsible for
- *   knowing the mapping between the name of a device and its
- *   corresponding (target, attribute) in the current SoC family.
+ *   device accesses. This API is mvebu_mbus_add_window_by_id(),
+ *   mvebu_mbus_add_window_remap_by_id() and
+ *   mvebu_mbus_del_window().
  *
  * - Provides a debugfs interface in /sys/kernel/debug/mvebu-mbus/ to
  *   see the list of CPU -> SDRAM windows and their configuration
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:28 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:28 -0300
Subject: [PATCH v6 17/21] ARM: mvebu: Use the preprocessor on Armada 370/XP
 device tree files
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-18-git-send-email-ezequiel.garcia@free-electrons.com>

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              | 2 +-
 arch/arm/boot/dts/armada-370-mirabox.dts         | 2 +-
 arch/arm/boot/dts/armada-370-rd.dts              | 2 +-
 arch/arm/boot/dts/armada-370.dtsi                | 2 +-
 arch/arm/boot/dts/armada-xp-db.dts               | 2 +-
 arch/arm/boot/dts/armada-xp-gp.dts               | 2 +-
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         | 2 +-
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         | 2 +-
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 2 +-
 arch/arm/boot/dts/armada-xp.dtsi                 | 2 +-
 10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index beee169..55b986c 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Marvell Armada 370 Evaluation Board";
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 45b1077..37530af 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -9,7 +9,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Globalscale Mirabox";
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index a3a2fed..7aa2171 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -12,7 +12,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Marvell Armada 370 Reference Design";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..08ec6e3 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -15,7 +15,7 @@
  * common to all Armada SoCs.
  */
 
-/include/ "armada-370-xp.dtsi"
+#include "armada-370-xp.dtsi"
 /include/ "skeleton.dtsi"
 
 / {
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index e28e68f..a9bd766 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78460.dtsi"
+#include "armada-xp-mv78460.dtsi"
 
 / {
 	model = "Marvell Armada XP Evaluation Board";
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index c87b2de..54843e5 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78460.dtsi"
+#include "armada-xp-mv78460.dtsi"
 
 / {
 	model = "Marvell Armada XP Development Board DB-MV784MP-GP";
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2d9335d..985373a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -13,7 +13,7 @@
  * common to all Armada XP SoCs.
  */
 
-/include/ "armada-xp.dtsi"
+#include "armada-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP MV78260 SoC";
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index c7b1f4d..f8bf25a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -13,7 +13,7 @@
  * common to all Armada XP SoCs.
  */
 
-/include/ "armada-xp.dtsi"
+#include "armada-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP MV78460 SoC";
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 8f51045..d090264 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -11,7 +11,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78260.dtsi"
+#include "armada-xp-mv78260.dtsi"
 
 / {
 	model = "PlatHome OpenBlocks AX3-4 board";
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 416eb94..8c07bfe 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -16,7 +16,7 @@
  * common to all Armada SoCs.
  */
 
-/include/ "armada-370-xp.dtsi"
+#include "armada-370-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP family SoC";
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:23 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:23 -0300
Subject: [PATCH v6 12/21] bus: mvebu-mbus: Remove name -> target,
 attribute mapping tables
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-13-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

This tables were used together with the name-based MBus window
creation API. Since that's has been removed, we can also remove
the tables.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 150 +++--------------------------------------------
 1 file changed, 7 insertions(+), 143 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index db68436..8240bd7 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -97,33 +97,6 @@
 
 #define DOVE_DDR_BASE_CS_OFF(n) ((n) << 4)
 
-struct mvebu_mbus_mapping {
-	const char *name;
-	u8 target;
-	u8 attr;
-	u8 attrmask;
-};
-
-/*
- * Masks used for the 'attrmask' field of mvebu_mbus_mapping. They
- * allow to get the real attribute value, discarding the special bits
- * used to select a PCI MEM region or a PCI WA region. This allows the
- * debugfs code to reverse-match the name of a device from its
- * target/attr values.
- *
- * For all devices except PCI, all bits of 'attr' must be
- * considered. For most SoCs, only bit 3 should be ignored (it allows
- * to select between PCI MEM and PCI I/O). On Orion5x however, there
- * is the special bit 5 to select a PCI WA region.
- */
-#define MAPDEF_NOMASK       0xff
-#define MAPDEF_PCIMASK      0xf7
-#define MAPDEF_ORIONPCIMASK 0xd7
-
-/* Macro used to define one mvebu_mbus_mapping entry */
-#define MAPDEF(__n, __t, __a, __m) \
-	{ .name = __n, .target = __t, .attr = __a, .attrmask = __m }
-
 struct mvebu_mbus_state;
 
 struct mvebu_mbus_soc_data {
@@ -133,7 +106,6 @@ struct mvebu_mbus_soc_data {
 	void (*setup_cpu_target)(struct mvebu_mbus_state *s);
 	int (*show_cpu_target)(struct mvebu_mbus_state *s,
 			       struct seq_file *seq, void *v);
-	const struct mvebu_mbus_mapping *map;
 };
 
 struct mvebu_mbus_state {
@@ -428,8 +400,7 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void *v)
 		u64 wbase, wremap;
 		u32 wsize;
 		u8 wtarget, wattr;
-		int enabled, i;
-		const char *name;
+		int enabled;
 
 		mvebu_mbus_read_window(mbus, win,
 				       &enabled, &wbase, &wsize,
@@ -440,18 +411,9 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void *v)
 			continue;
 		}
 
-
-		for (i = 0; mbus->soc->map[i].name; i++)
-			if (mbus->soc->map[i].target == wtarget &&
-			    mbus->soc->map[i].attr ==
-			    (wattr & mbus->soc->map[i].attrmask))
-				break;
-
-		name = mbus->soc->map[i].name ?: "unknown";
-
-		seq_printf(seq, "[%02d] %016llx - %016llx : %s",
+		seq_printf(seq, "[%02d] %016llx - %016llx : %04x:%04x\n",
 			   win, (unsigned long long)wbase,
-			   (unsigned long long)(wbase + wsize), name);
+			   (unsigned long long)(wbase + wsize), wtarget, wattr);
 
 		if (win < mbus->soc->num_remappable_wins) {
 			seq_printf(seq, " (remap %016llx)\n",
@@ -576,45 +538,12 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
 	mvebu_mbus_dram_info.num_cs = cs;
 }
 
-static const struct mvebu_mbus_mapping armada_370_map[] = {
-	MAPDEF("bootrom",     1, 0xe0, MAPDEF_NOMASK),
-	MAPDEF("devbus-boot", 1, 0x2f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x3e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x3d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x3b, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs3",  1, 0x37, MAPDEF_NOMASK),
-	MAPDEF("pcie0.0",     4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",     8, 0xe0, MAPDEF_PCIMASK),
-	{},
-};
-
 static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
 	.num_wins            = 20,
 	.num_remappable_wins = 8,
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = armada_370_map,
-};
-
-static const struct mvebu_mbus_mapping armada_xp_map[] = {
-	MAPDEF("bootrom",     1, 0x1d, MAPDEF_NOMASK),
-	MAPDEF("devbus-boot", 1, 0x2f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x3e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x3d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x3b, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs3",  1, 0x37, MAPDEF_NOMASK),
-	MAPDEF("pcie0.0",     4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.1",     4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.2",     4, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.3",     4, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",     8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.1",     8, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.2",     8, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.3",     8, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie2.0",     4, 0xf0, MAPDEF_PCIMASK),
-	MAPDEF("pcie3.0",     8, 0xf0, MAPDEF_PCIMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
@@ -623,15 +552,6 @@ static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = armada_xp_map,
-};
-
-static const struct mvebu_mbus_mapping kirkwood_map[] = {
-	MAPDEF("pcie0.0", 4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0", 4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("sram",    3, 0x01, MAPDEF_NOMASK),
-	MAPDEF("nand",    1, 0x2f, MAPDEF_NOMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data kirkwood_mbus_data = {
@@ -640,16 +560,6 @@ static const struct mvebu_mbus_soc_data kirkwood_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = kirkwood_map,
-};
-
-static const struct mvebu_mbus_mapping dove_map[] = {
-	MAPDEF("pcie0.0",    0x4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",    0x8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("cesa",       0x3, 0x01, MAPDEF_NOMASK),
-	MAPDEF("bootrom",    0x1, 0xfd, MAPDEF_NOMASK),
-	MAPDEF("scratchpad", 0xd, 0x0, MAPDEF_NOMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data dove_mbus_data = {
@@ -658,18 +568,6 @@ static const struct mvebu_mbus_soc_data dove_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_dove_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_dove,
-	.map                 = dove_map,
-};
-
-static const struct mvebu_mbus_mapping orion5x_map[] = {
-	MAPDEF("pcie0.0",     4, 0x51, MAPDEF_ORIONPCIMASK),
-	MAPDEF("pci0.0",      3, 0x51, MAPDEF_ORIONPCIMASK),
-	MAPDEF("devbus-boot", 1, 0x0f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x1e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x1d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x1b, MAPDEF_NOMASK),
-	MAPDEF("sram",        0, 0x00, MAPDEF_NOMASK),
-	{},
 };
 
 /*
@@ -682,7 +580,6 @@ static const struct mvebu_mbus_soc_data orion5x_4win_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = orion5x_map,
 };
 
 static const struct mvebu_mbus_soc_data orion5x_2win_mbus_data = {
@@ -691,21 +588,6 @@ static const struct mvebu_mbus_soc_data orion5x_2win_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = orion5x_map,
-};
-
-static const struct mvebu_mbus_mapping mv78xx0_map[] = {
-	MAPDEF("pcie0.0", 4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.1", 4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.2", 4, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.3", 4, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0", 8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.1", 8, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.2", 8, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.3", 8, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie2.0", 4, 0xf0, MAPDEF_PCIMASK),
-	MAPDEF("pcie3.0", 8, 0xf0, MAPDEF_PCIMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
@@ -714,7 +596,6 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
 	.win_cfg_offset      = mv78xx0_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = mv78xx0_map,
 };
 
 /*
@@ -879,33 +760,16 @@ static int __init mbus_dt_setup_win(struct mvebu_mbus_state *mbus,
 				    u32 base, u32 size,
 				    u8 target, u8 attr)
 {
-	const struct mvebu_mbus_mapping *map = mbus->soc->map;
-	const char *name;
-	int i;
-
-	/* Search for a suitable window in the existing mappings */
-	for (i = 0; map[i].name; i++)
-		if (map[i].target == target &&
-		    map[i].attr == (attr & map[i].attrmask))
-			break;
-
-	name = map[i].name;
-	if (!name) {
-		pr_err("window 0x%x:0x%x is unknown, skipping\n",
-		       target, attr);
-		return -EINVAL;
-	}
-
 	if (!mvebu_mbus_window_conflicts(mbus, base, size, target, attr)) {
-		pr_err("cannot add window '%s', conflicts with another window\n",
-		       name);
+		pr_err("cannot add window '%04x:%04x', conflicts with another window\n",
+		       target, attr);
 		return -EBUSY;
 	}
 
 	if (mvebu_mbus_alloc_window(mbus, base, size, MVEBU_MBUS_NO_REMAP,
 				    target, attr)) {
-		pr_err("cannot add window '%s', too many windows\n",
-		       name);
+		pr_err("cannot add window '%04x:%04x', too many windows\n",
+		       target, attr);
 		return -ENOMEM;
 	}
 	return 0;
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:25 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:25 -0300
Subject: [PATCH v6 14/21] bus: mvebu-mbus: Factorize Armada 370/XP data
 structures
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-15-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

These structures were only different in the mapping tables.
Now that those tables have been removed, it doesn't make any sense
to keep different structures.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 58d3c8f..0b7f9f7 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -534,15 +534,7 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
 	mvebu_mbus_dram_info.num_cs = cs;
 }
 
-static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
-	.num_wins            = 20,
-	.num_remappable_wins = 8,
-	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
-	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
-	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-};
-
-static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
+static const struct mvebu_mbus_soc_data armada_370_xp_mbus_data = {
 	.num_wins            = 20,
 	.num_remappable_wins = 8,
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
@@ -602,9 +594,9 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
  */
 static const struct of_device_id of_mvebu_mbus_ids[] = {
 	{ .compatible = "marvell,armada370-mbus",
-	  .data = &armada_370_mbus_data, },
+	  .data = &armada_370_xp_mbus_data, },
 	{ .compatible = "marvell,armadaxp-mbus",
-	  .data = &armada_xp_mbus_data, },
+	  .data = &armada_370_xp_mbus_data, },
 	{ .compatible = "marvell,kirkwood-mbus",
 	  .data = &kirkwood_mbus_data, },
 	{ .compatible = "marvell,dove-mbus",
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:26 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:26 -0300
Subject: [PATCH v6 15/21] ARM: mvebu: Remove the harcoded BootROM window
 allocation
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-16-git-send-email-ezequiel.garcia@free-electrons.com>

The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/mach-mvebu/platsmp.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index ce81d30..7be1ec2 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -21,6 +21,7 @@
 #include <linux/smp.h>
 #include <linux/clk.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/mbus.h>
 #include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
@@ -29,6 +30,9 @@
 #include "pmsu.h"
 #include "coherency.h"
 
+#define AXP_BOOTROM_BASE 0xfff00000
+#define AXP_BOOTROM_SIZE 0x100000
+
 void __init set_secondary_cpus_clock(void)
 {
 	int thiscpu;
@@ -114,10 +118,29 @@ static void __init armada_xp_smp_init_cpus(void)
 
 void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
 {
+	struct device_node *node;
+	struct resource res;
+	int err;
+
 	set_secondary_cpus_clock();
 	flush_cache_all();
 	set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
-	mvebu_mbus_add_window("bootrom", 0xfff00000, SZ_1M);
+
+	/*
+	 * In order to boot the secondary CPUs we need to ensure
+	 * the bootROM is mapped at the correct address.
+	 */
+	node = of_find_compatible_node(NULL, NULL, "marvell,bootrom");
+	if (!node)
+		panic("Cannot find 'marvell,bootrom' compatible node");
+
+	err = of_address_to_resource(node, 0, &res);
+	if (err < 0)
+		panic("Cannot get 'bootrom' node address");
+
+	if (res.start != AXP_BOOTROM_BASE ||
+	    resource_size(&res) != AXP_BOOTROM_SIZE)
+		panic("The address for the BootROM is incorrect");
 }
 
 struct smp_operations armada_xp_smp_ops __initdata = {
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:29 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:29 -0300
Subject: [PATCH v6 18/21] ARM: mvebu: Add MBus to Armada 370/XP device tree
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-19-git-send-email-ezequiel.garcia@free-electrons.com>

The Armada 370/XP SoC family has a completely configurable address
space handled by the MBus controller.

This patch introduces the device tree layout of MBus, making the
'soc' node as mbus-compatible.
Since every peripheral/controller is a child of this 'soc' node,
this makes all of them sit behind the mbus, thus describing the
hardware accurately.

A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              |  2 ++
 arch/arm/boot/dts/armada-370-mirabox.dts         |  2 ++
 arch/arm/boot/dts/armada-370-rd.dts              |  2 ++
 arch/arm/boot/dts/armada-370-xp.dtsi             | 15 ++++++++++-----
 arch/arm/boot/dts/armada-370.dtsi                |  4 ++--
 arch/arm/boot/dts/armada-xp-db.dts               |  4 +---
 arch/arm/boot/dts/armada-xp-gp.dts               |  4 +---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  4 +---
 arch/arm/boot/dts/armada-xp.dtsi                 |  2 ++
 9 files changed, 23 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 55b986c..5920b4e 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,6 +30,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 37530af..a4202b6 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,6 +25,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index 7aa2171..dd0ba01 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,6 +28,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 90b1176..62639b4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -18,6 +18,8 @@
 
 /include/ "skeleton64.dtsi"
 
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
 / {
 	model = "Marvell Armada 370 and XP SoC";
 	compatible = "marvell,armada-370-xp";
@@ -38,18 +40,21 @@
 	};
 
 	soc {
-		#address-cells = <1>;
+		#address-cells = <2>;
 		#size-cells = <1>;
-		compatible = "simple-bus";
+		controller = <&mbusc>;
 		interrupt-parent = <&mpic>;
-		ranges = <0          0 0xd0000000 0x0100000 /* internal registers */
-			  0xe0000000 0 0xe0000000 0x8100000 /* PCIe */>;
 
 		internal-regs {
 			compatible = "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
-			ranges;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
 
 			mpic: interrupt-controller at 20000 {
 				compatible = "marvell,mpic";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 08ec6e3..4b54e51 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -29,8 +29,8 @@
 	};
 
 	soc {
-		ranges = <0          0xd0000000 0x0100000 /* internal registers */
-			  0xe0000000 0xe0000000 0x8100000 /* PCIe */>;
+		compatible = "marvell,armada370-mbus", "simple-bus";
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index a9bd766..0d4ce54 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,9 +30,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000	/* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000     /* PCIe */
-			  0xf0000000 0 0xf0000000 0x1000000>;	/* Device Bus, NOR 16MiB   */
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 54843e5..2fa9209 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,9 +39,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000  /* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000 /* PCIe */
-			  0xf0000000 0 0xf0000000 0x1000000 /* Device Bus, NOR 16MiB  */>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index d090264..a3e3a12 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,9 +27,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000	/* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000     /* PCIe */
-			  0xf0000000 0 0xf0000000 0x8000000     /* Device Bus, NOR 128MiB   */>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 8c07bfe..8033824 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -27,6 +27,8 @@
 	};
 
 	soc {
+		compatible = "marvell,armadaxp-mbus", "simple-bus";
+
 		internal-regs {
 			L2: l2-cache {
 				compatible = "marvell,aurora-system-cache";
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:30 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:30 -0300
Subject: [PATCH v6 19/21] ARM: mvebu: Add BootROM to Armada 370/XP device tree
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-20-git-send-email-ezequiel.garcia@free-electrons.com>

In order to access the SoC BootROM, we need to declare a mapping
(through a ranges property). The mbus driver will use this property
to allocate a suitable address decoding window.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              | 3 ++-
 arch/arm/boot/dts/armada-370-mirabox.dts         | 3 ++-
 arch/arm/boot/dts/armada-370-rd.dts              | 3 ++-
 arch/arm/boot/dts/armada-370.dtsi                | 5 +++++
 arch/arm/boot/dts/armada-xp-db.dts               | 3 ++-
 arch/arm/boot/dts/armada-xp-gp.dts               | 3 ++-
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 3 ++-
 arch/arm/boot/dts/armada-xp.dtsi                 | 5 +++++
 8 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 5920b4e..90ce29d 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,7 +30,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index a4202b6..19341d2 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,7 +25,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index dd0ba01..0b3acf3 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,7 +28,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 4b54e51..bd21d49 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -31,6 +31,11 @@
 	soc {
 		compatible = "marvell,armada370-mbus", "simple-bus";
 
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
+		};
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 0d4ce54..857f272 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,7 +30,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 2fa9209..934dc46 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,7 +39,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index a3e3a12..1700f6f 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,7 +27,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 8033824..7ba99ce 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -29,6 +29,11 @@
 	soc {
 		compatible = "marvell,armadaxp-mbus", "simple-bus";
 
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
+		};
+
 		internal-regs {
 			L2: l2-cache {
 				compatible = "marvell,aurora-system-cache";
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:27 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:27 -0300
Subject: [PATCH v6 16/21] ARM: mvebu: Initialize MBus using the DT binding
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-17-git-send-email-ezequiel.garcia@free-electrons.com>

Now that the mbus device tree binding has been introduced, we can
switch over to it.

Also, and since the initialization of the mbus driver is quite
fundamental for the system to work properly, this patch adds a BUG()
in case mbus fails to initialize.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/mach-mvebu/armada-370-xp.c | 34 +---------------------------------
 1 file changed, 1 insertion(+), 33 deletions(-)

diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 97cbb80..829b573 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -34,44 +34,12 @@ static void __init armada_370_xp_map_io(void)
 	debug_ll_io_init();
 }
 
-/*
- * This initialization will be replaced by a DT-based
- * initialization once the mvebu-mbus driver gains DT support.
- */
-
-#define ARMADA_370_XP_MBUS_WINS_OFFS   0x20000
-#define ARMADA_370_XP_MBUS_WINS_SIZE   0x100
-#define ARMADA_370_XP_SDRAM_WINS_OFFS  0x20180
-#define ARMADA_370_XP_SDRAM_WINS_SIZE  0x20
-
-static void __init armada_370_xp_mbus_init(void)
-{
-	char *mbus_soc_name;
-	struct device_node *dn;
-	const __be32 mbus_wins_offs = cpu_to_be32(ARMADA_370_XP_MBUS_WINS_OFFS);
-	const __be32 sdram_wins_offs = cpu_to_be32(ARMADA_370_XP_SDRAM_WINS_OFFS);
-
-	if (of_machine_is_compatible("marvell,armada370"))
-		mbus_soc_name = "marvell,armada370-mbus";
-	else
-		mbus_soc_name = "marvell,armadaxp-mbus";
-
-	dn = of_find_node_by_name(NULL, "internal-regs");
-	BUG_ON(!dn);
-
-	mvebu_mbus_init(mbus_soc_name,
-			of_translate_address(dn, &mbus_wins_offs),
-			ARMADA_370_XP_MBUS_WINS_SIZE,
-			of_translate_address(dn, &sdram_wins_offs),
-			ARMADA_370_XP_SDRAM_WINS_SIZE);
-}
-
 static void __init armada_370_xp_timer_and_clk_init(void)
 {
 	of_clk_init(NULL);
 	armada_370_xp_timer_init();
 	coherency_init();
-	armada_370_xp_mbus_init();
+	BUG_ON(mvebu_mbus_dt_init());
 #ifdef CONFIG_CACHE_L2X0
 	l2x0_of_init(0, ~0UL);
 #endif
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:32 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:32 -0300
Subject: [PATCH v6 21/21] ARM: mvebu: Relocate Armada 370/XP PCIe device tree
 nodes
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-22-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.

Moving the PCIe nodes, we now need to introduce an extra cell to
encode the window target ID and attribute. Since this depends on
the PCIe port, we split the ranges translation entries, to correspond
to each MBus window.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-mirabox.dts         |  32 +-
 arch/arm/boot/dts/armada-370.dtsi                |  99 +++---
 arch/arm/boot/dts/armada-xp-db.dts               |  67 ++--
 arch/arm/boot/dts/armada-xp-gp.dts               |  42 +--
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         | 217 +++++++------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         | 256 ++++++++-------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         | 395 ++++++++++++-----------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  18 +-
 8 files changed, 584 insertions(+), 542 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 19341d2..2471d9d 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -28,6 +28,22 @@
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
 			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
+		pcie-controller {
+			status = "okay";
+
+			/* Internal mini-PCIe connector */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+
+			/* Connected on the PCB to a USB 3.0 XHCI controller */
+			pcie at 2,0 {
+				/* Port 1, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
@@ -123,22 +139,6 @@
 					reg = <0x25>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/* Internal mini-PCIe connector */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-
-				/* Connected on the PCB to a USB 3.0 XHCI controller */
-				pcie at 2,0 {
-					/* Port 1, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index bd21d49..066a79f 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -36,6 +36,57 @@
 			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
 		};
 
+		pcie-controller {
+			compatible = "marvell,armada-370-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000    MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
+				0x82000000 0 0x80000    MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000
+				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
+				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */
+				0x82001000 0 0xe0000000 MBUS_ID(0x08, 0xe8) 0xe0000000 0 0x08000000 /* Port 1.0 MEM */
+				0x81001000 0 0          MBUS_ID(0x08, 0xe0) 0xe8000000 0 0x00100000 /* Port 1.0 IO */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 62>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 9>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
@@ -174,54 +225,6 @@
 					0x18304 0x4>;
 				status = "okay";
 			};
-
-			pcie-controller {
-				compatible = "marvell,armada-370-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 62>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 9>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 76ae1a9..bcf6d79 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -62,6 +62,39 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+
+			/*
+			 * All 6 slots are physically present as
+			 * standard PCIe slots on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+			pcie at 2,0 {
+				/* Port 0, Lane 1 */
+				status = "okay";
+			};
+			pcie at 3,0 {
+				/* Port 0, Lane 2 */
+				status = "okay";
+			};
+			pcie at 4,0 {
+				/* Port 0, Lane 3 */
+				status = "okay";
+			};
+			pcie at 9,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+			pcie at 10,0 {
+				/* Port 3, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -155,40 +188,6 @@
 					spi-max-frequency = <20000000>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/*
-				 * All 6 slots are physically present as
-				 * standard PCIe slots on the board.
-				 */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-				pcie at 2,0 {
-					/* Port 0, Lane 1 */
-					status = "okay";
-				};
-				pcie at 3,0 {
-					/* Port 0, Lane 2 */
-					status = "okay";
-				};
-				pcie at 4,0 {
-					/* Port 0, Lane 3 */
-					status = "okay";
-				};
-				pcie at 9,0 {
-					/* Port 2, Lane 0 */
-					status = "okay";
-				};
-				pcie at 10,0 {
-					/* Port 3, Lane 0 */
-					status = "okay";
-				};
-			};
-
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 8c0de20..2298e4a 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -71,6 +71,27 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+
+			/*
+			 * The 3 slots are physically present as
+			 * standard PCIe slots on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+			pcie at 9,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+			pcie at 10,0 {
+				/* Port 3, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -154,27 +175,6 @@
 					spi-max-frequency = <108000000>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/*
-				 * The 3 slots are physically present as
-				 * standard PCIe slots on the board.
-				 */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-				pcie at 9,0 {
-					/* Port 2, Lane 0 */
-					status = "okay";
-				};
-				pcie at 10,0 {
-					/* Port 3, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f8eaa38..335a1c1 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -44,6 +44,119 @@
 	};
 
 	soc {
+		/*
+		 * MV78230 has 2 PCIe units Gen2.0: One unit can be
+		 * configured as x4 or quad x1 lanes. One unit is
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
+				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */
+				0x82001000 0 0xe0000000 MBUS_ID(0x04, 0xd8) 0xe0000000 0 0x08000000 /* Port 0.1 MEM */
+				0x81001000 0 0          MBUS_ID(0x04, 0xd0) 0xe8000000 0 0x00100000 /* Port 0.2 IO */
+				0x82001800 0 0xe0000000 MBUS_ID(0x04, 0xb8) 0xe0000000 0 0x08000000 /* Port 0.2 MEM */
+				0x81001800 0 0          MBUS_ID(0x04, 0xb0) 0xe8000000 0 0x00100000 /* Port 0.2 IO */
+				0x82002000 0 0xe0000000 MBUS_ID(0x04, 0x78) 0xe0000000 0 0x08000000 /* Port 0.3 MEM */
+				0x81002000 0 0          MBUS_ID(0x04, 0x70) 0xe8000000 0 0x00100000 /* Port 0.3 IO */
+				0x82004800 0 0xe0000000 MBUS_ID(0x04, 0xf8) 0xe0000000 0 0x08000000 /* Port 2.0 MEM */
+				0x81004800 0 0          MBUS_ID(0x04, 0xf0) 0xe8000000 0 0x00100000 /* Port 2.0 IO */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78230-pinctrl";
@@ -77,110 +190,6 @@
 				#interrupts-cells = <2>;
 				interrupts = <87>, <88>, <89>;
 			};
-
-			/*
-			 * MV78230 has 2 PCIe units Gen2.0: One unit can be
-			 * configured as x4 or quad x1 lanes. One unit is
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-#address-cells = <3>;
-#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 985373a..4d429ac 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -45,6 +45,140 @@
 	};
 
 	soc {
+		/*
+		 * MV78260 has 3 PCIe units Gen2.0: Two units can be
+		 * configured as x4 or quad x1 lanes. One unit is
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000   /* Port 1.0 registers */
+				0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000   /* Port 3.0 registers */
+				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
+				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */
+				0x82001000 0 0xe0000000 MBUS_ID(0x04, 0xd8) 0xe0000000 0 0x08000000 /* Port 0.1 MEM */
+				0x81001000 0 0          MBUS_ID(0x04, 0xd0) 0xe8000000 0 0x00100000 /* Port 0.1 IO */
+				0x82001800 0 0xe0000000 MBUS_ID(0x04, 0xb8) 0xe0000000 0 0x08000000 /* Port 0.2 MEM */
+				0x81001800 0 0          MBUS_ID(0x04, 0xb0) 0xe8000000 0 0x00100000 /* Port 0.2 IO */
+				0x82002000 0 0xe0000000 MBUS_ID(0x04, 0x78) 0xe0000000 0 0x08000000 /* Port 0.3 MEM */
+				0x81002000 0 0          MBUS_ID(0x04, 0x70) 0xe8000000 0 0x00100000 /* Port 0.3 IO */
+				0x82002800 0 0xe0000000 MBUS_ID(0x08, 0xe8) 0xe0000000 0 0x08000000 /* Port 1.0 MEM */
+				0x82004800 0 0xe0000000 MBUS_ID(0x04, 0xf8) 0xe0000000 0 0x08000000 /* Port 2.0 MEM */
+				0x81004800 0 0          MBUS_ID(0x04, 0xf0) 0xe8000000 0 0x00100000 /* Port 2.0 IO */
+				0x82005000 0 0xe0000000 MBUS_ID(0x08, 0xf8) 0xe0000000 0 0x08000000 /* Port 3.0 MEM */
+				0x81005000 0 0          MBUS_ID(0x08, 0xf0) 0xe8000000 0 0x00100000 /* Port 3.0 IO */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+
+			pcie at 10,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x82000 0 0x2000>;
+				reg = <0x5000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 103>;
+				marvell,pcie-port = <3>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 27>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78260-pinctrl";
@@ -97,128 +231,6 @@
 				clocks = <&gateclk 1>;
 				status = "disabled";
 			};
-
-			/*
-			 * MV78260 has 3 PCIe units Gen2.0: Two units can be
-			 * configured as x4 or quad x1 lanes. One unit is
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-
-				pcie at 10,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x82000 0 0x2000>;
-					reg = <0x5000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 103>;
-					marvell,pcie-port = <3>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 27>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index f8bf25a..3ad3c95 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -61,6 +61,213 @@
 	};
 
 	soc {
+		/*
+		 * MV78460 has 4 PCIe units Gen2.0: Two units can be
+		 * configured as x4 or quad x1 lanes. Two units are
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000   /* Port 1.0 registers */
+				0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000   /* Port 3.0 registers */
+				0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000   /* Port 1.1 registers */
+				0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000   /* Port 1.2 registers */
+				0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000   /* Port 1.3 registers */
+				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
+				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */
+				0x82001000 0 0xe0000000 MBUS_ID(0x04, 0xd8) 0xe0000000 0 0x08000000 /* Port 0.1 MEM */
+				0x81001000 0 0          MBUS_ID(0x04, 0xd0) 0xe8000000 0 0x00100000 /* Port 0.2 IO */
+				0x82001800 0 0xe0000000 MBUS_ID(0x04, 0xb8) 0xe0000000 0 0x08000000 /* Port 0.2 MEM */
+				0x81001800 0 0          MBUS_ID(0x04, 0xb0) 0xe8000000 0 0x00100000 /* Port 0.2 IO */
+				0x82002000 0 0xe0000000 MBUS_ID(0x04, 0x78) 0xe0000000 0 0x08000000 /* Port 0.3 MEM */
+				0x81002000 0 0          MBUS_ID(0x04, 0x70) 0xe8000000 0 0x00100000 /* Port 0.3 IO */
+				0x82002800 0 0xe0000000 MBUS_ID(0x08, 0xe8) 0xe0000000 0 0x08000000 /* Port 1.0 MEM */
+				0x81002800 0 0          MBUS_ID(0x08, 0xe0) 0xe8000000 0 0x00100000 /* Port 1.0 IO */
+				0x82003000 0 0xe0000000 MBUS_ID(0x08, 0xd8) 0xe0000000 0 0x08000000 /* Port 1.1 MEM */
+				0x81003000 0 0          MBUS_ID(0x08, 0xd0) 0xe8000000 0 0x00100000 /* Port 1.1 IO */
+				0x82003800 0 0xe0000000 MBUS_ID(0x08, 0xb8) 0xe0000000 0 0x08000000 /* Port 1.2 MEM */
+				0x81003800 0 0          MBUS_ID(0x08, 0xb0) 0xe8000000 0 0x00100000 /* Port 1.2 IO */
+				0x82004000 0 0xe0000000 MBUS_ID(0x08, 0x78) 0xe0000000 0 0x08000000 /* Port 1.3 MEM */
+				0x81004000 0 0          MBUS_ID(0x08, 0x70) 0xe8000000 0 0x00100000 /* Port 1.3 IO */
+				0x82004800 0 0xe0000000 MBUS_ID(0x04, 0xf8) 0xe0000000 0 0x08000000 /* Port 2.0 MEM */
+				0x81004800 0 0          MBUS_ID(0x04, 0xf0) 0xe8000000 0 0x00100000 /* Port 2.0 IO */
+				0x82005000 0 0xe0000000 MBUS_ID(0x08, 0xf8) 0xe0000000 0 0x08000000 /* Port 3.0 MEM */
+				0x81005000 0 0          MBUS_ID(0x08, 0xf0) 0xe8000000 0 0x00100000 /* Port 3.0 IO */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 5,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
+				reg = <0x2800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 62>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 9>;
+				status = "disabled";
+			};
+
+			pcie at 6,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
+				reg = <0x3000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 63>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 10>;
+				status = "disabled";
+			};
+
+			pcie at 7,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
+				reg = <0x3800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 64>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 11>;
+				status = "disabled";
+			};
+
+			pcie at 8,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
+				reg = <0x4000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 65>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 12>;
+				status = "disabled";
+			};
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+
+			pcie at 10,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
+				reg = <0x5000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 103>;
+				marvell,pcie-port = <3>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 27>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78460-pinctrl";
@@ -113,194 +320,6 @@
 				clocks = <&gateclk 1>;
 				status = "disabled";
 			};
-
-			/*
-			 * MV78460 has 4 PCIe units Gen2.0: Two units can be
-			 * configured as x4 or quad x1 lanes. Two units are
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
-					0x82000000 0 0x84000 0x84000 0 0x00002000   /* Port 1.1 registers */
-					0x82000000 0 0x88000 0x88000 0 0x00002000   /* Port 1.2 registers */
-					0x82000000 0 0x8c000 0x8c000 0 0x00002000   /* Port 1.3 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 5,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
-					reg = <0x2800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 62>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 9>;
-					status = "disabled";
-				};
-
-				pcie at 6,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
-					reg = <0x3000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 63>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 10>;
-					status = "disabled";
-				};
-
-				pcie at 7,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
-					reg = <0x3800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 64>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 11>;
-					status = "disabled";
-				};
-
-				pcie at 8,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
-					reg = <0x4000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 65>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 12>;
-					status = "disabled";
-				};
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-
-				pcie at 10,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
-					reg = <0x5000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 103>;
-					marvell,pcie-port = <3>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 27>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 2b60ee0..5695afc 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -59,6 +59,15 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+			/* Internal mini-PCIe connector */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -176,15 +185,6 @@
 			usb at 51000 {
 				status = "okay";
 			};
-
-			pcie-controller {
-				status = "okay";
-				/* Internal mini-PCIe connector */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul  5 17:39:31 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri,  5 Jul 2013 18:39:31 -0300
Subject: [PATCH v6 20/21] ARM: mvebu: Relocate Armada 370/XP DeviceBus device
 tree nodes
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373060372-32357-21-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus has been added to the device tree, it's possible to
move the DeviceBus out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the hardware.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi             | 94 +++++++++++++-----------
 arch/arm/boot/dts/armada-xp-db.dts               | 59 +++++++--------
 arch/arm/boot/dts/armada-xp-gp.dts               | 60 +++++++--------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 65 ++++++++--------
 4 files changed, 140 insertions(+), 138 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 62639b4..073dd20 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -45,6 +45,56 @@
 		controller = <&mbusc>;
 		interrupt-parent = <&mpic>;
 
+		devbus-bootcs {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs0 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs1 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs2 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs3 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
 		internal-regs {
 			compatible = "simple-bus";
 			#address-cells = <1>;
@@ -200,50 +250,6 @@
 				status = "disabled";
 			};
 
-			devbus-bootcs at 10400 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10400 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs0 at 10408 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10408 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs1 at 10410 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10410 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs2 at 10418 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10418 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs3 at 10420 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10420 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
 		};
 	};
  };
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 857f272..76ae1a9 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -31,7 +31,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x1000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -160,34 +189,6 @@
 				};
 			};
 
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x1000000>;
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 16 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x1000000>;
-					bank-width = <2>;
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 934dc46..8c0de20 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -40,7 +40,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x1000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -126,35 +155,6 @@
 				};
 			};
 
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf000000, size 0x1000000 */
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 16 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x1000000>;
-					bank-width = <2>;
-				};
-			};
-
 			pcie-controller {
 				status = "okay";
 
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 1700f6f..2b60ee0 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -28,7 +28,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 128 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x8000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -148,40 +177,6 @@
 				status = "okay";
 			};
 
-			/* USB interface in the mini-PCIe connector */
-			usb at 52000 {
-				status = "okay";
-			};
-
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x8000000>; /* @addr 0xf000000, size 0x8000000 */
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 128 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x8000000>;
-					bank-width = <2>;
-				};
-			};
-
 			pcie-controller {
 				status = "okay";
 				/* Internal mini-PCIe connector */
-- 
1.8.1.5



From thomas.petazzoni at free-electrons.com  Fri Jul  5 17:45:01 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 5 Jul 2013 23:45:01 +0200
Subject: [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
In-Reply-To: <CAErSpo73iSBg+SYwZLea0qdXD1uVc3+Vacd8Tg4CU92vLG=2AQ@mail.gmail.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-4-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo73iSBg+SYwZLea0qdXD1uVc3+Vacd8Tg4CU92vLG=2AQ@mail.gmail.com>
Message-ID: <20130705234501.1341f52e@skate>

Dear Bjorn Helgaas,

On Fri, 5 Jul 2013 15:37:33 -0600, Bjorn Helgaas wrote:

> Acked-by: Bjorn Helgaas <bhelgaas at google.com>
> 
> Again, please update the subject line to "PCI: Remove ..."
> 
> I doubt that you'll get explicit acks from all the arches you touched,
> but I think it's reasonable to put at least patches 2 & 3 in -next
> soon after v3.11-rc1, so we should have time to shake out issues.

Sure. Which merge strategy do you suggest for this patch series, which
touches a number of different areas, and has some build-time
dependencies between the patches (if needed, I can detail those build
time dependencies to help figuring out the best strategy).

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From bhelgaas at google.com  Fri Jul  5 17:51:10 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Fri, 5 Jul 2013 15:51:10 -0600
Subject: [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <1372686136-1370-5-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-5-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAErSpo4aodspFnC0uR87yYAgswQQdmU48uoX5NA43UZjbCpOuw@mail.gmail.com>

On Mon, Jul 1, 2013 at 7:42 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> From: Thierry Reding <thierry.reding at avionic-design.de>
>
> The new struct msi_chip is used to associated an MSI controller with a
> PCI bus. It is automatically handed down from the root to its children
> during bus enumeration.
>
> This patch provides default (weak) implementations for the architecture-
> specific MSI functions (arch_setup_msi_irq(), arch_teardown_msi_irq()
> and arch_msi_check_device()) which check if a PCI device's bus has an
> attached MSI chip and forward the call appropriately.
>
> Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

I'm OK with this patch in principle, but I do have a couple comments below.

> ---
>  drivers/pci/msi.c   | 22 ++++++++++++++++++++++
>  drivers/pci/probe.c |  1 +
>  include/linux/msi.h | 11 +++++++++++
>  include/linux/pci.h |  1 +
>  4 files changed, 35 insertions(+)
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 289fbfd..62eb3d5 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -32,15 +32,37 @@ static int pci_msi_enable = 1;
>
>  int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
>  {
> +       struct msi_chip *chip = dev->bus->msi;
> +
> +       if (chip && chip->setup_irq) {
> +               int err;
> +
> +               err = chip->setup_irq(chip, dev, desc);
> +               if (err < 0)
> +                       return err;
> +
> +               irq_set_chip_data(desc->irq, chip);
> +               return err;
> +       }
> +
>         return -EINVAL;

It's sub-optimal to indent the whole body of a function like this.  I
think this is a bit more readable:

    if (!chip || !chip->setup_irq)
        return -EINVAL

    err = chip->setup_irq(...);
    ...
    return err;

The return value of ->setup_irq() (and hence of arch_setup_msi_irq())
is a bit unclear.  Apparently it can return negative values (errors)
or positive values (not sure what they mean), or zero (again, not
sure).  A comment would clear this up.

It might even be worth introducing a no-op chip with pointers to no-op
functions so we don't have to do these checks ("if (chip &&
chip->xxx)" everywhere.  I'm not sure if there's a Linux consensus on
that -- certainly there are many examples of code that *does* make
these checks everywhere -- so I'll ack it either way.

>  }
>
>  void __weak arch_teardown_msi_irq(unsigned int irq)
>  {
> +       struct msi_chip *chip = irq_get_chip_data(irq);
> +
> +       if (chip && chip->teardown_irq)
> +               chip->teardown_irq(chip, irq);
>  }
>
>  int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
>  {
> +       struct msi_chip *chip = dev->bus->msi;
> +
> +       if (chip && chip->check_device)
> +               return chip->check_device(chip, dev, nvec, type);
> +

These functions are poorly named.  They give no clue what
"check_device" means.  Are we checking that it exists, that it
supports some property, that it's enabled, ... ?

>         return 0;
>  }
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 70f10fa..c8591e4 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -634,6 +634,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
>
>         child->parent = parent;
>         child->ops = parent->ops;
> +       child->msi = parent->msi;
>         child->sysdata = parent->sysdata;
>         child->bus_flags = parent->bus_flags;
>
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index c82ff8d..5b357d92 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -63,4 +63,15 @@ void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
>
>  void default_teardown_msi_irqs(struct pci_dev *dev);
>
> +struct msi_chip {
> +       struct module *owner;
> +       struct device *dev;
> +
> +       int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
> +                        struct msi_desc *desc);
> +       void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
> +       int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
> +                           int nvec, int type);
> +};
> +
>  #endif /* LINUX_MSI_H */
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 3a24e4f..7ffc012 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -432,6 +432,7 @@ struct pci_bus {
>         struct resource busn_res;       /* bus numbers routed to this bus */
>
>         struct pci_ops  *ops;           /* configuration access functions */
> +       struct msi_chip *msi;           /* MSI controller */
>         void            *sysdata;       /* hook for sys-specific extension */
>         struct proc_dir_entry *procdir; /* directory entry in /proc/bus/pci */
>
> --
> 1.8.1.2
>


From bhelgaas at google.com  Fri Jul  5 17:56:55 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Fri, 5 Jul 2013 15:56:55 -0600
Subject: [PATCHv4 05/11] of: pci: add registry of MSI chips
In-Reply-To: <1372686136-1370-6-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-6-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAErSpo5LqKbG=_Uw9eEfR-J0mD2Wg8oi_DdjEfPqgB_VxjouMg@mail.gmail.com>

On Mon, Jul 1, 2013 at 7:42 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> This commit adds a very basic registry of msi_chip structures, so that
> an IRQ controller driver can register an msi_chip, and a PCIe host
> controller can find it, based on a 'struct device_node'.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  drivers/of/of_pci.c    | 40 ++++++++++++++++++++++++++++++++++++++++
>  include/linux/msi.h    |  2 ++
>  include/linux/of_pci.h | 12 ++++++++++++
>  3 files changed, 54 insertions(+)
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 42c687a..f516632 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -89,3 +89,43 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
>         return 0;
>  }
>  EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
> +
> +#ifdef CONFIG_PCI_MSI
> +
> +static LIST_HEAD(msi_chip_list);
> +static DEFINE_MUTEX(msi_chip_mutex);
> +
> +int of_msi_chip_add(struct msi_chip *chip)
> +{
> +       if (! of_property_read_bool(chip->of_node, "msi-controller"))

The space between "! of_property..." is atypical.

> +               return -EINVAL;
> +
> +       mutex_lock(&msi_chip_mutex);
> +       list_add(&chip->list, &msi_chip_list);
> +       mutex_unlock(&msi_chip_mutex);
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_msi_chip_add);
> +
> +void of_msi_chip_remove(struct msi_chip *chip)
> +{
> +       mutex_lock(&msi_chip_mutex);
> +       list_del(&chip->list);
> +       mutex_unlock(&msi_chip_mutex);
> +}
> +EXPORT_SYMBOL_GPL(of_msi_chip_remove);
> +
> +struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node)
> +{
> +       struct msi_chip *c;

Normally there's a blank line here.

The list traversal below isn't safe, is it?  A simultaneous remove,
e.g., of an MSI chip unrelated to the one we're looking up, might
change the list while we're traversing it.

> +       list_for_each_entry(c, &msi_chip_list, list) {
> +               if (c->of_node == of_node)
> +                       return c;
> +       }
> +
> +       return NULL;
> +}
> +EXPORT_SYMBOL_GPL(of_find_msi_chip_by_node);
> +
> +#endif /* CONFIG_PCI_MSI */
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index 5b357d92..9e1a44b 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -66,6 +66,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);
>  struct msi_chip {
>         struct module *owner;
>         struct device *dev;
> +       struct device_node *of_node;
> +       struct list_head list;
>
>         int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
>                          struct msi_desc *desc);
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index 7a04826..99e4361 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -2,6 +2,7 @@
>  #define __OF_PCI_H
>
>  #include <linux/pci.h>
> +#include <linux/msi.h>
>
>  struct pci_dev;
>  struct of_irq;
> @@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
>  int of_pci_get_devfn(struct device_node *np);
>  int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
>
> +#if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
> +int of_msi_chip_add(struct msi_chip *chip);
> +void of_msi_chip_remove(struct msi_chip *chip);
> +struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node);
> +#else
> +static inline int of_msi_chip_add(struct msi_chip *chip) { return -EINVAL; }
> +static inline void of_msi_chip_remove(struct msi_chip *chip) { }
> +static inline struct msi_chip *
> +of_find_msi_chip_by_node(struct device_node *of_node) { return NULL };
> +#endif
> +
>  #endif
> --
> 1.8.1.2
>


From arnd at arndb.de  Fri Jul  5 17:58:21 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 5 Jul 2013 23:58:21 +0200
Subject: [PATCH] ASoC: Allow imx-pcm-{dma,fiq}.c to be modules
In-Reply-To: <20130705211920.GK27646@sirena.org.uk>
References: <201307051745.16140.arnd@arndb.de>
 <201307052255.10765.arnd@arndb.de> <20130705211920.GK27646@sirena.org.uk>
Message-ID: <201307052358.22068.arnd@arndb.de>

On Friday 05 July 2013, Mark Brown wrote:
> On Fri, Jul 05, 2013 at 10:55:10PM +0200, Arnd Bergmann wrote:
> > On Friday 05 July 2013, Mark Brown wrote:
> 
> > > Is this actually OK with the FIQ APIs?
> 
> > I don't know. Why wouldn't it?
> 
> It was the only reason I could think of why that'd have been done.

I looked in the log and found this part has been patched a couple
of times already, going back and forth between "bool" and "tristate",
always to fix build errors.

Please hold back for now, I'll try to reproduce on the bug on
the current torvalds tree first. I know it was broken in linux-next
as of a few weeks ago, but something else may have changed in the
meantime.

	Arnd


From bhelgaas at google.com  Fri Jul  5 17:59:53 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Fri, 5 Jul 2013 15:59:53 -0600
Subject: [PATCHv4 10/11] pci: mvebu: add support for MSI
In-Reply-To: <1372686136-1370-11-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-11-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAErSpo4w3q0WDJLn2mykvMF2DCd2bd+BN=N=pXbKV+GbhMp6jw@mail.gmail.com>

On Mon, Jul 1, 2013 at 7:42 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> This commit adds support for Message Signaled Interrupts in the
> Marvell PCIe host controller. The work is very simple: it simply gets
> a reference to the msi_chip associated to the PCIe controller thanks
> to the msi-parent DT property, and stores this reference in the
> pci_bus structure. This is enough to let the Linux PCI core use the
> functions of msi_chip to setup and teardown MSIs.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Reviewed-by: Thierry Reding <thierry.reding at gmail.com>
> Acked-by: Bjorn Helgaas <bhelgaas at google.com>

I've already acked this, and I reaffirm that.  Please adjust the
subject line to capitalize "PCI" and the first word of the descriptive
sentence.

> ---
>  .../devicetree/bindings/pci/mvebu-pci.txt          |  3 +++
>  drivers/pci/host/pci-mvebu.c                       | 26 ++++++++++++++++++++++
>  2 files changed, 29 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> index f8d4058..77e0ffe 100644
> --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> @@ -12,6 +12,8 @@ Mandatory properties:
>  - device_type, set to "pci"
>  - ranges: ranges for the PCI memory and I/O regions, as well as the
>    MMIO registers to control the PCIe interfaces.
> +- msi-parent: Link to the hardware entity that serves as the Message
> +  Signaled Interrupt controller for this PCI controller.
>
>  In addition, the Device Tree node must have sub-nodes describing each
>  PCIe interface, having the following mandatory properties:
> @@ -46,6 +48,7 @@ pcie-controller {
>         #size-cells = <2>;
>
>         bus-range = <0x00 0xff>;
> +       msi-parent = <&mpic>;
>
>         ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
>                   0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index 13a633b..396f578 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -11,6 +11,7 @@
>  #include <linux/clk.h>
>  #include <linux/module.h>
>  #include <linux/mbus.h>
> +#include <linux/msi.h>
>  #include <linux/slab.h>
>  #include <linux/platform_device.h>
>  #include <linux/of_address.h>
> @@ -107,6 +108,7 @@ struct mvebu_pcie_port;
>  struct mvebu_pcie {
>         struct platform_device *pdev;
>         struct mvebu_pcie_port *ports;
> +       struct msi_chip *msi;
>         struct resource io;
>         struct resource realio;
>         struct resource mem;
> @@ -695,6 +697,12 @@ static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct pci_sys_data *sys)
>         return bus;
>  }
>
> +void mvebu_pcie_add_bus(struct pci_bus *bus)
> +{
> +       struct mvebu_pcie *pcie = sys_to_pcie(bus->sysdata);
> +       bus->msi = pcie->msi;
> +}
> +
>  resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev,
>                                           const struct resource *res,
>                                           resource_size_t start,
> @@ -731,6 +739,7 @@ static void __init mvebu_pcie_enable(struct mvebu_pcie *pcie)
>         hw.map_irq        = mvebu_pcie_map_irq;
>         hw.ops            = &mvebu_pcie_ops;
>         hw.align_resource = mvebu_pcie_align_resource;
> +       hw.add_bus        = mvebu_pcie_add_bus;
>
>         pci_common_init(&hw);
>  }
> @@ -755,6 +764,21 @@ mvebu_pcie_map_registers(struct platform_device *pdev,
>         return devm_request_and_ioremap(&pdev->dev, &regs);
>  }
>
> +static void __init mvebu_pcie_msi_enable(struct mvebu_pcie *pcie)
> +{
> +       struct device_node *msi_node;
> +
> +       msi_node = of_parse_phandle(pcie->pdev->dev.of_node,
> +                                   "msi-parent", 0);
> +       if (!msi_node)
> +               return;
> +
> +       pcie->msi = of_find_msi_chip_by_node(msi_node);
> +
> +       if (pcie->msi)
> +               pcie->msi->dev = &pcie->pdev->dev;
> +}
> +
>  static int __init mvebu_pcie_probe(struct platform_device *pdev)
>  {
>         struct mvebu_pcie *pcie;
> @@ -879,6 +903,8 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
>                 i++;
>         }
>
> +       mvebu_pcie_msi_enable(pcie);
> +
>         mvebu_pcie_enable(pcie);
>
>         return 0;
> --
> 1.8.1.2
>


From thomas.petazzoni at free-electrons.com  Fri Jul  5 18:06:55 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 6 Jul 2013 00:06:55 +0200
Subject: [PATCHv4 05/11] of: pci: add registry of MSI chips
In-Reply-To: <CAErSpo5LqKbG=_Uw9eEfR-J0mD2Wg8oi_DdjEfPqgB_VxjouMg@mail.gmail.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo5LqKbG=_Uw9eEfR-J0mD2Wg8oi_DdjEfPqgB_VxjouMg@mail.gmail.com>
Message-ID: <20130706000655.00ae3659@skate>

Dear Bjorn Helgaas,

On Fri, 5 Jul 2013 15:56:55 -0600, Bjorn Helgaas wrote:

> > +int of_msi_chip_add(struct msi_chip *chip)
> > +{
> > +       if (! of_property_read_bool(chip->of_node, "msi-controller"))
> 
> The space between "! of_property..." is atypical.

Indeed.


> > +struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node)
> > +{
> > +       struct msi_chip *c;
> 
> Normally there's a blank line here.
> 
> The list traversal below isn't safe, is it?  A simultaneous remove,
> e.g., of an MSI chip unrelated to the one we're looking up, might
> change the list while we're traversing it.

True, will fix!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From thomas.petazzoni at free-electrons.com  Fri Jul  5 18:08:16 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 6 Jul 2013 00:08:16 +0200
Subject: [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <CAErSpo4aodspFnC0uR87yYAgswQQdmU48uoX5NA43UZjbCpOuw@mail.gmail.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-5-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo4aodspFnC0uR87yYAgswQQdmU48uoX5NA43UZjbCpOuw@mail.gmail.com>
Message-ID: <20130706000816.3affe558@skate>

Dear Bjorn Helgaas,

On Fri, 5 Jul 2013 15:51:10 -0600, Bjorn Helgaas wrote:

> > ---
> >  drivers/pci/msi.c   | 22 ++++++++++++++++++++++
> >  drivers/pci/probe.c |  1 +
> >  include/linux/msi.h | 11 +++++++++++
> >  include/linux/pci.h |  1 +
> >  4 files changed, 35 insertions(+)
> >
> > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> > index 289fbfd..62eb3d5 100644
> > --- a/drivers/pci/msi.c
> > +++ b/drivers/pci/msi.c
> > @@ -32,15 +32,37 @@ static int pci_msi_enable = 1;
> >
> >  int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
> >  {
> > +       struct msi_chip *chip = dev->bus->msi;
> > +
> > +       if (chip && chip->setup_irq) {
> > +               int err;
> > +
> > +               err = chip->setup_irq(chip, dev, desc);
> > +               if (err < 0)
> > +                       return err;
> > +
> > +               irq_set_chip_data(desc->irq, chip);
> > +               return err;
> > +       }
> > +
> >         return -EINVAL;
> 
> It's sub-optimal to indent the whole body of a function like this.  I
> think this is a bit more readable:
> 
>     if (!chip || !chip->setup_irq)
>         return -EINVAL
> 
>     err = chip->setup_irq(...);
>     ...
>     return err;

Right.

> The return value of ->setup_irq() (and hence of arch_setup_msi_irq())
> is a bit unclear.  Apparently it can return negative values (errors)
> or positive values (not sure what they mean), or zero (again, not
> sure).  A comment would clear this up.

Ok, I'll have to look into this. Maybe Thierry Redding can comment on
this.

> It might even be worth introducing a no-op chip with pointers to no-op
> functions so we don't have to do these checks ("if (chip &&
> chip->xxx)" everywhere.  I'm not sure if there's a Linux consensus on
> that -- certainly there are many examples of code that *does* make
> these checks everywhere -- so I'll ack it either way.

Ok, I'll see if it makes the overall thing cleaner.


> >  int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> >  {
> > +       struct msi_chip *chip = dev->bus->msi;
> > +
> > +       if (chip && chip->check_device)
> > +               return chip->check_device(chip, dev, nvec, type);
> > +
> 
> These functions are poorly named.  They give no clue what
> "check_device" means.  Are we checking that it exists, that it
> supports some property, that it's enabled, ... ?

Maybe Thierry Redding can comment on this one?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From jgunthorpe at obsidianresearch.com  Fri Jul  5 18:08:20 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Fri, 5 Jul 2013 16:08:20 -0600
Subject: [PATCH v6 00/21] MBus DT binding: PCIe strikes back
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130705220820.GA11787@obsidianresearch.com>

On Fri, Jul 05, 2013 at 06:39:11PM -0300, Ezequiel Garcia wrote:
 
> 			ranges =
> 			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
> 				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
> 				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
> 				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
> 				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
> 				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
> 				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>;

This is a good try, but this coding doesn't work...

Recall the long discussion that came up during the original
development of this binding. The OF spec says this:

 In particular, the phys.hi fields of the child address spaces in the
 "ranges" property for PCI does not contain
 the same information as "reg" property entries within PCI nodes. The
 only information that is present in
 "ranges" phys.hi entries are the non-relocatable, prefetchable and
 the PCI address space bits for which the en-
 try applies. I.e., only the n, p and ss bits are present; the
 bbbbbbbb, ddddd, fff and rrrrrrrr fields are 0.

 When an address is to be mapped through a PCI bus bridge node, the
 phys.hi value of the address to be mapped
 and the child field of a "ranges" entry should be masked so that only
 the ss bits are compared. I.e., the only
 portion of phys.hi that should participate in the range determination
 is the address space indicator (the ss bits).

Which forbids (0x82000800 .. ..) from being in a ranges

I don't have an idea how to encode MBUS_ID in the PCI-E ranges :(

Arnd? Didn't you have some idea?

FWIW, I like removing the string tables from the driver, you could
keep the fake MBUS-ID and retain that change by adding a
marvell,target-id type property to the bridges...

Jason


From maxime.ripard at free-electrons.com  Fri Jul  5 18:12:04 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat, 6 Jul 2013 00:12:04 +0200
Subject: [PATCHv3 08/10] clocksource: sun4i: Remove TIMER_SCAL variable
In-Reply-To: <alpine.DEB.2.02.1307052245390.32106@ionos.tec.linutronix.de>
References: <1373052877-29366-1-git-send-email-maxime.ripard@free-electrons.com>
 <1373052877-29366-9-git-send-email-maxime.ripard@free-electrons.com>
 <alpine.DEB.2.02.1307052245390.32106@ionos.tec.linutronix.de>
Message-ID: <20130705221204.GO2959@lukather>

On Fri, Jul 05, 2013 at 10:48:45PM +0200, Thomas Gleixner wrote:
> 
> 
> On Fri, 5 Jul 2013, Maxime Ripard wrote:
> 
> > The prescaler is only used when using the internal low frequency
> > oscillator (at 32kHz). Since we're using the higher frequency oscillator
> > at 24MHz, we can just remove it.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > ---
> >  drivers/clocksource/sun4i_timer.c | 11 +++--------
> >  1 file changed, 3 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
> > index 00e17d9..2f84075 100644
> > --- a/drivers/clocksource/sun4i_timer.c
> > +++ b/drivers/clocksource/sun4i_timer.c
> > @@ -34,8 +34,6 @@
> >  #define TIMER_INTVAL_REG(val)	(0x10 * (val) + 0x14)
> >  #define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
> >  
> > -#define TIMER_SCAL		16
> > -
> 
> I can understand this one.
> 
> >  static void __iomem *timer_base;
> >  
> >  /*
> > @@ -139,7 +137,6 @@ static u32 sun4i_timer_sched_read(void)
> >  
> >  static void __init sun4i_timer_init(struct device_node *node)
> >  {
> > -	unsigned long rate = 0;
> >  	struct clk *clk;
> >  	int ret, irq;
> >  	u32 val;
> > @@ -157,8 +154,6 @@ static void __init sun4i_timer_init(struct device_node *node)
> >  		panic("Can't get timer clock");
> >  	clk_prepare_enable(clk);
> >  
> > -	rate = clk_get_rate(clk);
> > -
> 
> But this one is bogus. Why do you want to read the clock rate five
> times in a row instead of using the single cached value?
> 
> That does not make any sense.

Right, I'll send a new version.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130706/1e21f222/attachment-0001.sig>

From maxime.ripard at free-electrons.com  Fri Jul  5 18:18:37 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat,  6 Jul 2013 00:18:37 +0200
Subject: [PATCHv4 02/10] clocksource: sun4i: Wrap macros arguments in
 parenthesis
In-Reply-To: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373062725-19625-3-git-send-email-maxime.ripard@free-electrons.com>

The macros were not using parenthesis to escape the arguments passed to
them. It is pretty unsafe, so add those parenthesis.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index bdf34d9..34ab658 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -30,8 +30,8 @@
 #define TIMER_CTL_ENABLE		BIT(0)
 #define TIMER_CTL_AUTORELOAD		BIT(1)
 #define TIMER_CTL_ONESHOT		BIT(7)
-#define TIMER_INTVAL_REG(val)	(0x10 * val + 0x14)
-#define TIMER_CNTVAL_REG(val)	(0x10 * val + 0x18)
+#define TIMER_INTVAL_REG(val)	(0x10 * (val) + 0x14)
+#define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
 
 #define TIMER_SCAL		16
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 18:18:38 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat,  6 Jul 2013 00:18:38 +0200
Subject: [PATCHv4 03/10] clocksource: sun4i: rename AUTORELOAD define to RELOAD
In-Reply-To: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373062725-19625-4-git-send-email-maxime.ripard@free-electrons.com>

The name AUTORELOAD was actually pretty bad since it doesn't make the
register reload the previous interval when it expires, but setting this
value pushes the new programmed interval to the internal timer counter.
Rename it to RELOAD instead.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 34ab658..f5e227b 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -28,7 +28,7 @@
 #define TIMER_IRQ_ST_REG	0x04
 #define TIMER_CTL_REG(val)	(0x10 * val + 0x10)
 #define TIMER_CTL_ENABLE		BIT(0)
-#define TIMER_CTL_AUTORELOAD		BIT(1)
+#define TIMER_CTL_RELOAD		BIT(1)
 #define TIMER_CTL_ONESHOT		BIT(7)
 #define TIMER_INTVAL_REG(val)	(0x10 * (val) + 0x14)
 #define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
@@ -129,7 +129,7 @@ static void __init sun4i_timer_init(struct device_node *node)
 
 	/* set mode to auto reload */
 	val = readl(timer_base + TIMER_CTL_REG(0));
-	writel(val | TIMER_CTL_AUTORELOAD, timer_base + TIMER_CTL_REG(0));
+	writel(val | TIMER_CTL_RELOAD, timer_base + TIMER_CTL_REG(0));
 
 	ret = setup_irq(irq, &sun4i_timer_irq);
 	if (ret)
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 18:18:36 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat,  6 Jul 2013 00:18:36 +0200
Subject: [PATCHv4 01/10] clocksource: sun4i: Use the BIT macros where possible
In-Reply-To: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373062725-19625-2-git-send-email-maxime.ripard@free-electrons.com>

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index d4674e7..bdf34d9 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -24,12 +24,12 @@
 #include <linux/of_irq.h>
 
 #define TIMER_IRQ_EN_REG	0x00
-#define TIMER_IRQ_EN(val)		(1 << val)
+#define TIMER_IRQ_EN(val)		BIT(val)
 #define TIMER_IRQ_ST_REG	0x04
 #define TIMER_CTL_REG(val)	(0x10 * val + 0x10)
-#define TIMER_CTL_ENABLE		(1 << 0)
-#define TIMER_CTL_AUTORELOAD		(1 << 1)
-#define TIMER_CTL_ONESHOT		(1 << 7)
+#define TIMER_CTL_ENABLE		BIT(0)
+#define TIMER_CTL_AUTORELOAD		BIT(1)
+#define TIMER_CTL_ONESHOT		BIT(7)
 #define TIMER_INTVAL_REG(val)	(0x10 * val + 0x14)
 #define TIMER_CNTVAL_REG(val)	(0x10 * val + 0x18)
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 18:18:39 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat,  6 Jul 2013 00:18:39 +0200
Subject: [PATCHv4 04/10] clocksource: sun4i: Add clocksource and sched clock
 drivers
In-Reply-To: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373062725-19625-5-git-send-email-maxime.ripard@free-electrons.com>

Use the second timer found on the Allwinner SoCs as a clock source and
sched clock, that were both not used yet on these platforms.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index f5e227b..b581c93 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -19,6 +19,7 @@
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/irqreturn.h>
+#include <linux/sched_clock.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
@@ -96,6 +97,11 @@ static struct irqaction sun4i_timer_irq = {
 	.dev_id = &sun4i_clockevent,
 };
 
+static u32 sun4i_timer_sched_read(void)
+{
+	return ~readl(timer_base + TIMER_CNTVAL_REG(1));
+}
+
 static void __init sun4i_timer_init(struct device_node *node)
 {
 	unsigned long rate = 0;
@@ -117,6 +123,15 @@ static void __init sun4i_timer_init(struct device_node *node)
 
 	rate = clk_get_rate(clk);
 
+	writel(~0, timer_base + TIMER_INTVAL_REG(1));
+	writel(TIMER_CTL_ENABLE | TIMER_CTL_RELOAD |
+	       TIMER_CTL_CLK_SRC(TIMER_CTL_CLK_SRC_OSC24M),
+	       timer_base + TIMER_CTL_REG(1));
+
+	setup_sched_clock(sun4i_timer_sched_read, 32, rate);
+	clocksource_mmio_init(timer_base + TIMER_CNTVAL_REG(1), node->name,
+			      rate, 300, 32, clocksource_mmio_readl_down);
+
 	writel(rate / (TIMER_SCAL * HZ),
 	       timer_base + TIMER_INTVAL_REG(0));
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 18:18:35 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat,  6 Jul 2013 00:18:35 +0200
Subject: [PATCHv4 00/10] clocksource: sunxi: Timer fixes and cleanup
Message-ID: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>

Hi everyone,

The first timer code we merged when adding support for the A13 some
time back was mostly a clean up from the source drop we had, without
any documentation.  This happened to work, but the code merged in
turned out to be far from perfect, and had several flaws.

This patchset hopefully fixes these flaws, and cleanup most of the
driver as well, to end up in an almost complete rewrite of it (even
though it's not that long).

It also finally adds a clocksource driver using the second timer as
our monotonic clock source.

These flaws have all been spotted when trying to add the A31 support,
work that is still ongoing, but will hopefully benefit from this
patchset as well.

Thanks,
Maxime

Changes from v3:
  - Reintroduce the rate variable to cache the parent clock rate
  - Remove the interval programming at probe time that was
    reintroduced in the v3 due to a poor rebase.

Changes from v2:
  - Use the clocksource timer to get the amount of time we have to
    wait for when disabling and enabling back a timer
  - Added patch to add parenthesis around the macros arguments
  - Renamed the AUTORELOAD register define to the more meaningful
    RELOAD name

Changes from v1:
  - Rebased on top of linux-next to benefit from the move to all
    architectures of the sched_clock functions
  - Moved the clock source to the second timer instead of the 64 bits
    free-running counter like suggested by Thomas.

Maxime Ripard (10):
  clocksource: sun4i: Use the BIT macros where possible
  clocksource: sun4i: Wrap macros arguments in parenthesis
  clocksource: sun4i: rename AUTORELOAD define to RELOAD
  clocksource: sun4i: Add clocksource and sched clock drivers
  clocksource: sun4i: Don't forget to enable the clock we use
  clocksource: sun4i: Fix the next event code
  clocksource: sun4i: Factor out some timer code
  clocksource: sun4i: Remove TIMER_SCAL variable
  clocksource: sun4i: Cleanup parent clock setup
  clocksource: sun4i: Fix bug when switching from periodic to oneshot
    modes

 drivers/clocksource/sun4i_timer.c | 110 +++++++++++++++++++++++++++-----------
 1 file changed, 78 insertions(+), 32 deletions(-)

-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 18:18:40 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat,  6 Jul 2013 00:18:40 +0200
Subject: [PATCHv4 05/10] clocksource: sun4i: Don't forget to enable the clock
 we use
In-Reply-To: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373062725-19625-6-git-send-email-maxime.ripard@free-electrons.com>

Even if in our case, this clock was non-gatable, used as a parent clock
for several IPs, it still is a good idea to enable it.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index b581c93..8e9c651 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -120,6 +120,7 @@ static void __init sun4i_timer_init(struct device_node *node)
 	clk = of_clk_get(node, 0);
 	if (IS_ERR(clk))
 		panic("Can't get timer clock");
+	clk_prepare_enable(clk);
 
 	rate = clk_get_rate(clk);
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 18:18:41 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat,  6 Jul 2013 00:18:41 +0200
Subject: [PATCHv4 06/10] clocksource: sun4i: Fix the next event code
In-Reply-To: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373062725-19625-7-git-send-email-maxime.ripard@free-electrons.com>

The next_event logic was setting the next interval to fire in the
current timer value instead of the interval value register, which is
obviously wrong.

Plus, the logic to set the actual value was wrong as well: the interval
register can only be modified when the timer is disabled, and then
enable it back, otherwise, it'll have no effect. Fix this logic as well
since that code couldn't possibly work.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 8e9c651..7123f65 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -38,6 +38,20 @@
 
 static void __iomem *timer_base;
 
+/*
+ * When we disable a timer, we need to wait at least for 2 cycles of
+ * the timer source clock. We will use for that the clocksource timer
+ * that is already setup and runs at the same frequency than the other
+ * timers, and we never will be disabled.
+ */
+static void sun4i_clkevt_sync(void)
+{
+	u32 old = readl(timer_base + TIMER_CNTVAL_REG(1));
+
+	while ((old - readl(timer_base + TIMER_CNTVAL_REG(1))) < 3)
+		cpu_relax();
+}
+
 static void sun4i_clkevt_mode(enum clock_event_mode mode,
 			      struct clock_event_device *clk)
 {
@@ -63,9 +77,14 @@ static void sun4i_clkevt_mode(enum clock_event_mode mode,
 static int sun4i_clkevt_next_event(unsigned long evt,
 				   struct clock_event_device *unused)
 {
-	u32 u = readl(timer_base + TIMER_CTL_REG(0));
-	writel(evt, timer_base + TIMER_CNTVAL_REG(0));
-	writel(u | TIMER_CTL_ENABLE | TIMER_CTL_AUTORELOAD,
+	u32 val = readl(timer_base + TIMER_CTL_REG(0));
+	writel(val & ~TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(0));
+	sun4i_clkevt_sync();
+
+	writel(evt, timer_base + TIMER_INTVAL_REG(0));
+
+	val = readl(timer_base + TIMER_CTL_REG(0));
+	writel(val | TIMER_CTL_ENABLE | TIMER_CTL_AUTORELOAD,
 	       timer_base + TIMER_CTL_REG(0));
 
 	return 0;
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 18:18:44 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat,  6 Jul 2013 00:18:44 +0200
Subject: [PATCHv4 09/10] clocksource: sun4i: Cleanup parent clock setup
In-Reply-To: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373062725-19625-10-git-send-email-maxime.ripard@free-electrons.com>

The current bring-up code for the timer was overly complicated. The only
thing we need is actually which clock we want to use as source and
that's pretty much all. Let's keep it that way.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 3217adc..2fadb3b 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -30,6 +30,9 @@
 #define TIMER_CTL_REG(val)	(0x10 * val + 0x10)
 #define TIMER_CTL_ENABLE		BIT(0)
 #define TIMER_CTL_RELOAD		BIT(1)
+#define TIMER_CTL_CLK_SRC(val)		(((val) & 0x3) << 2)
+#define TIMER_CTL_CLK_SRC_OSC24M		(1)
+#define TIMER_CTL_CLK_PRES(val)		(((val) & 0x7) << 4)
 #define TIMER_CTL_ONESHOT		BIT(7)
 #define TIMER_INTVAL_REG(val)	(0x10 * (val) + 0x14)
 #define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
@@ -168,16 +171,8 @@ static void __init sun4i_timer_init(struct device_node *node)
 
 	writel(rate / HZ, timer_base + TIMER_INTVAL_REG(0));
 
-	/* set clock source to HOSC, 16 pre-division */
-	val = readl(timer_base + TIMER_CTL_REG(0));
-	val &= ~(0x07 << 4);
-	val &= ~(0x03 << 2);
-	val |= (4 << 4) | (1 << 2);
-	writel(val, timer_base + TIMER_CTL_REG(0));
-
-	/* set mode to auto reload */
-	val = readl(timer_base + TIMER_CTL_REG(0));
-	writel(val | TIMER_CTL_RELOAD, timer_base + TIMER_CTL_REG(0));
+	writel(TIMER_CTL_CLK_SRC(TIMER_CTL_CLK_SRC_OSC24M) | TIMER_CTL_RELOAD,
+	       timer_base + TIMER_CTL_REG(0));
 
 	ret = setup_irq(irq, &sun4i_timer_irq);
 	if (ret)
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 18:18:43 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat,  6 Jul 2013 00:18:43 +0200
Subject: [PATCHv4 08/10] clocksource: sun4i: Remove TIMER_SCAL variable
In-Reply-To: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373062725-19625-9-git-send-email-maxime.ripard@free-electrons.com>

The prescaler is only used when using the internal low frequency
oscillator (at 32kHz). Since we're using the higher frequency oscillator
at 24MHz, we can just remove it.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index dd78b63..3217adc 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -34,8 +34,6 @@
 #define TIMER_INTVAL_REG(val)	(0x10 * (val) + 0x14)
 #define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
 
-#define TIMER_SCAL		16
-
 static void __iomem *timer_base;
 
 /*
@@ -168,8 +166,7 @@ static void __init sun4i_timer_init(struct device_node *node)
 	clocksource_mmio_init(timer_base + TIMER_CNTVAL_REG(1), node->name,
 			      rate, 300, 32, clocksource_mmio_readl_down);
 
-	writel(rate / (TIMER_SCAL * HZ),
-	       timer_base + TIMER_INTVAL_REG(0));
+	writel(rate / HZ, timer_base + TIMER_INTVAL_REG(0));
 
 	/* set clock source to HOSC, 16 pre-division */
 	val = readl(timer_base + TIMER_CTL_REG(0));
@@ -192,8 +189,8 @@ static void __init sun4i_timer_init(struct device_node *node)
 
 	sun4i_clockevent.cpumask = cpumask_of(0);
 
-	clockevents_config_and_register(&sun4i_clockevent, rate / TIMER_SCAL,
-					0x1, 0xff);
+	clockevents_config_and_register(&sun4i_clockevent, rate, 0x1,
+					0xffffffff);
 }
 CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-timer",
 		       sun4i_timer_init);
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 18:18:45 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat,  6 Jul 2013 00:18:45 +0200
Subject: [PATCHv4 10/10] clocksource: sun4i: Fix bug when switching from
 periodic to oneshot modes
In-Reply-To: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373062725-19625-11-git-send-email-maxime.ripard@free-electrons.com>

The interval was firing at was set up at probe time, and only changed in
the set_next_event, and never changed back, which is not really what is
expected.

When enabling the periodic mode, now set an interval to tick every
jiffy.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 2fadb3b..d00d50a 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -38,6 +38,7 @@
 #define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
 
 static void __iomem *timer_base;
+static u32 ticks_per_jiffy;
 
 /*
  * When we disable a timer, we need to wait at least for 2 cycles of
@@ -74,7 +75,8 @@ static void sun4i_clkevt_time_start(u8 timer, bool periodic)
 	else
 		val |= TIMER_CTL_ONESHOT;
 
-	writel(val | TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(timer));
+	writel(val | TIMER_CTL_ENABLE | TIMER_CTL_RELOAD,
+	       timer_base + TIMER_CTL_REG(timer));
 }
 
 static void sun4i_clkevt_mode(enum clock_event_mode mode,
@@ -83,6 +85,7 @@ static void sun4i_clkevt_mode(enum clock_event_mode mode,
 	switch (mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
 		sun4i_clkevt_time_stop(0);
+		sun4i_clkevt_time_setup(0, ticks_per_jiffy);
 		sun4i_clkevt_time_start(0, true);
 		break;
 	case CLOCK_EVT_MODE_ONESHOT:
@@ -169,9 +172,9 @@ static void __init sun4i_timer_init(struct device_node *node)
 	clocksource_mmio_init(timer_base + TIMER_CNTVAL_REG(1), node->name,
 			      rate, 300, 32, clocksource_mmio_readl_down);
 
-	writel(rate / HZ, timer_base + TIMER_INTVAL_REG(0));
+	ticks_per_jiffy = DIV_ROUND_UP(clk_get_rate(clk), HZ);
 
-	writel(TIMER_CTL_CLK_SRC(TIMER_CTL_CLK_SRC_OSC24M) | TIMER_CTL_RELOAD,
+	writel(TIMER_CTL_CLK_SRC(TIMER_CTL_CLK_SRC_OSC24M),
 	       timer_base + TIMER_CTL_REG(0));
 
 	ret = setup_irq(irq, &sun4i_timer_irq);
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Fri Jul  5 18:18:42 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat,  6 Jul 2013 00:18:42 +0200
Subject: [PATCHv4 07/10] clocksource: sun4i: Factor out some timer code
In-Reply-To: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373062725-19625-8-git-send-email-maxime.ripard@free-electrons.com>

The set_next_event and set_mode callbacks share a lot of common code we
can easily factor to avoid duplication and mistakes.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 48 ++++++++++++++++++++++++++-------------
 1 file changed, 32 insertions(+), 16 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 7123f65..dd78b63 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -52,24 +52,46 @@ static void sun4i_clkevt_sync(void)
 		cpu_relax();
 }
 
+static void sun4i_clkevt_time_stop(u8 timer)
+{
+	u32 val = readl(timer_base + TIMER_CTL_REG(timer));
+	writel(val & ~TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(timer));
+	sun4i_clkevt_sync();
+}
+
+static void sun4i_clkevt_time_setup(u8 timer, unsigned long delay)
+{
+	writel(delay, timer_base + TIMER_INTVAL_REG(timer));
+}
+
+static void sun4i_clkevt_time_start(u8 timer, bool periodic)
+{
+	u32 val = readl(timer_base + TIMER_CTL_REG(timer));
+
+	if (periodic)
+		val &= ~TIMER_CTL_ONESHOT;
+	else
+		val |= TIMER_CTL_ONESHOT;
+
+	writel(val | TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(timer));
+}
+
 static void sun4i_clkevt_mode(enum clock_event_mode mode,
 			      struct clock_event_device *clk)
 {
-	u32 u = readl(timer_base + TIMER_CTL_REG(0));
-
 	switch (mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
-		u &= ~(TIMER_CTL_ONESHOT);
-		writel(u | TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(0));
+		sun4i_clkevt_time_stop(0);
+		sun4i_clkevt_time_start(0, true);
 		break;
-
 	case CLOCK_EVT_MODE_ONESHOT:
-		writel(u | TIMER_CTL_ONESHOT, timer_base + TIMER_CTL_REG(0));
+		sun4i_clkevt_time_stop(0);
+		sun4i_clkevt_time_start(0, false);
 		break;
 	case CLOCK_EVT_MODE_UNUSED:
 	case CLOCK_EVT_MODE_SHUTDOWN:
 	default:
-		writel(u & ~(TIMER_CTL_ENABLE), timer_base + TIMER_CTL_REG(0));
+		sun4i_clkevt_time_stop(0);
 		break;
 	}
 }
@@ -77,15 +99,9 @@ static void sun4i_clkevt_mode(enum clock_event_mode mode,
 static int sun4i_clkevt_next_event(unsigned long evt,
 				   struct clock_event_device *unused)
 {
-	u32 val = readl(timer_base + TIMER_CTL_REG(0));
-	writel(val & ~TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(0));
-	sun4i_clkevt_sync();
-
-	writel(evt, timer_base + TIMER_INTVAL_REG(0));
-
-	val = readl(timer_base + TIMER_CTL_REG(0));
-	writel(val | TIMER_CTL_ENABLE | TIMER_CTL_AUTORELOAD,
-	       timer_base + TIMER_CTL_REG(0));
+	sun4i_clkevt_time_stop(0);
+	sun4i_clkevt_time_setup(0, evt);
+	sun4i_clkevt_time_start(0, false);
 
 	return 0;
 }
-- 
1.8.3.2



From linux at arm.linux.org.uk  Fri Jul  5 18:19:27 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 5 Jul 2013 23:19:27 +0100
Subject: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is
 64-bits
In-Reply-To: <CACVXFVPfkqP+UyoGd-+QFRzndSam_DtU=utrBPYCPjQCGQ_F6g@mail.gmail.com>
References: <1367008266-1431-1-git-send-email-lauraa@codeaurora.org>
 <517AF270.8040106@gmail.com>
 <CACVXFVPfkqP+UyoGd-+QFRzndSam_DtU=utrBPYCPjQCGQ_F6g@mail.gmail.com>
Message-ID: <20130705221927.GL24642@n2100.arm.linux.org.uk>

On Wed, Jul 03, 2013 at 10:15:50PM +0800, Ming Lei wrote:
> 
> Without the patch, LPAE enabled board may not boot at all, but looks
> it still isn't in -next tree.
> 
> But I am wondering if it is a correct approach, because enabling LPAE
> doesn't mean the I/O devices can support DMA to/from 64bit address, and
> it is very probably devices can't do it at all.
> 
> Another way is to always set arm_dma_limit as 0xFFFFFFFF when
> CONFIG_ZONE_DMA is unset, and let driver override device's dma
> mask if the device supports 64bit DMA.

Okay, here's a teach-in on DMA masks, this is how it's supposed to work:

1. The bus code which creates the devices sets a default mask appropriate
   for the bus type.  For PCI, this is 32-bit, for ISA, it's 24-bit.

2. Before performing DMA, drivers should query the capabilities of the
   platform using dma_set_mask() for streaming transfers, and
   dma_set_coherent_mask() for coherent transfers.  Note: the DMA API
   specifies that a mask accepted by dma_set_mask() will also be
   accepted by dma_set_coherent_mask() - in other words, it is
   permissible _not_ to check the return value of dma_set_coherent_mask()
   iff that same mask is currently in use via dma_set_mask().

   (Side note: I have a patch in my tree which introduces
   dma_set_mask_and_coherent() which sets both.)

3. Drivers should attempt to set a mask appropriate for the device.
   If the device can drive 32-bit addresses, it requests a 32-bit
   mask.  If only 24-bit, a 24-bit mask.  If it wants to do more
   than 32-bit, it should set a larger mask.

   (See the "DMA addressing limitations" section of
    Documentation/DMA-API-HOWTO.txt).

4. PCI drivers use this as part of a negotiation with the rest of the
   system; you can plug a 64-bit capable PCI card into a 32-bit only
   capable host, and it should work - the driver should try to
   request the 64-bit mask first, if that succeeds then it can use
   DMA to 64-bit addresses.  If it fails, then it should then try to
   set a 32-bit mask.

So, that's more or less what's currently "known" of DMA masks.  What a lot
of ARM drivers do is totally ignore (3) and just assume that the platform
code set the mask up appropriately.  This is an incorrect assumption, and
it's something I'm slowly fixing where I have the knowledge.

What we shouldn't be relying upon is the default DMA mask being correct.

Last point is - the device actually doing DMA should be the one which the
DMA mask counts for above; if the device is just a user of DMA, then its
DMA mask should not matter (if it does, it's likely because of x86/PCI
assumptions made in the subsystem code) and actually should _not_ be set.
In other words, the DMA engine probe function should set the DMA mask on
the DMA controller, and you should do DMA mappings against the DMA
controller's struct device, not against the IO peripheral's struct
device.


From maxime.ripard at free-electrons.com  Fri Jul  5 18:23:42 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat, 6 Jul 2013 00:23:42 +0200
Subject: MTD EEPROM support and driver integration
In-Reply-To: <201307052302.40588.arnd@arndb.de>
References: <20130705201118.GM2959@lukather> <201307052302.40588.arnd@arndb.de>
Message-ID: <20130705222342.GP2959@lukather>

Hi Arnd,

On Fri, Jul 05, 2013 at 11:02:40PM +0200, Arnd Bergmann wrote:
> On Friday 05 July 2013, Maxime Ripard wrote:
> > Hi everyone,
> > 
> > In the last weeks, we've drivers coming up both about mostly some very
> > simple drivers that expose to the userspace a few bytes of memory-mapped
> > IO. Both will probably live under drivers/misc/eeprom, where there's
> > support already for other kind of what could be assimilated as eeproms
> > (AT24, AT25, etc.).
> > 
> > Now, besides the code duplication every driver has to make to register
> > the sysfs attributes, it wouldn't cause much of a problem.
> > 
> > Except that these EEPROMs could store values useful for other drivers in
> > Linux. For example:
> >   - imx28 OCOTP (the latest of the two EEPROM drivers recently submitted)
> >     use it most of the time to store its MAC addresses
> >   - Allwinner SoCs SID (the other latest driver submitted) use it
> >     sometime to store a MAC address, and also the SoC ID, which could be
> >     useful to implement a SoC bus driver.
> >   - Some Allwinner boards (and presumably others) use an AT24 to store
> >     the MAC address in it.
> > 
> > For now, everyone comes up with a different solution:
> >   - imx28 has a hook in mach-mxs to patch the device tree at runtime and
> >     add the values retrieved from the OCOTP to it.
> >   - AT24 seem to have some function exported (at24_macc_(read|write)) so
> >     that other part of the kernel can use them to retrieve values from
> >     such an EEPROM.
> >   - Allwinner SoCs have, well, basically nothing for now, which is why I
> >     send this email.
> > 
> > The current way of working has several flaws imho:
> >   - The code is heavily duplicated: the sysfs registering is common to
> >     every driver, and at the end of the day, every driver should only
> >     give a read/write callback, and that's it.
> >   - The "consumer" drivers should not have to worry at all about the
> >     EEPROM type it should retrieve the needed value from, let alone
> >     dealing with the number of instances of such an EEPROM.
> > 
> > To solve this issues, I think I have some solution. Would merging this
> > drivers into MTD make some sense? It seems like there is already some
> > EEPROM drivers into drivers/mtd (such as an AT25 one, which also have a
> > drivers under drivers/misc/eeprom), so I guess it does, but I'd like to
> > have your opinion on this.
> 
> I always felt that we should eventually move the eeprom drivers out of
> drivers/misc into their own subsystem. Moving them under drivers/mtd
> also seems reasonable.
> 
> Having a common API sounds like a good idea, and we should probably
> spend some time comparing the options.

Great :)

> > If so, would some kind of MTD in-kernel API to retrieve values from MTD
> > devices would be acceptable to you? I mostly have DT in mind, so I'm
> > thinking of having DT bindings to that API such as
> > 
> >   mac-storage = <&phandle 0xoffset 0xsize>
> > 
> > to describe which device to get a value from, and where in that device.
> > 
> > That would allow consumer drivers to only have to call a function like
> > of_mtd_get_value and let the MTD subsystem do the hard work.
> > 
> > What's your feeling on this?
> 
> My first thought is that it should be more generic than that and not
> have the mac address hardcoded as the purpose. We could possibly use
> regmap as the in-kernel interface, and come up with a more generic
> way of referring to registers in another device node.

Hmm, I maybe wasn't as clear as I wanted. Here mac-storage was just an
example. It should indeed be completely generic, and a device could have
several "storage source" defined, each driver knowing what property it
would need, pretty much like what's done currently for the regulators
for example.

We will have such a use case anyway for the Allwinner stuff, since the
fuses can be used for several thing, including storing the SoC ID,
serial numbers, and so on.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130706/1ba30a45/attachment.sig>

From arnd at arndb.de  Fri Jul  5 18:33:13 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 6 Jul 2013 00:33:13 +0200
Subject: MTD EEPROM support and driver integration
In-Reply-To: <20130705222342.GP2959@lukather>
References: <20130705201118.GM2959@lukather>
 <201307052302.40588.arnd@arndb.de> <20130705222342.GP2959@lukather>
Message-ID: <201307060033.13259.arnd@arndb.de>

On Saturday 06 July 2013, Maxime Ripard wrote:
> > My first thought is that it should be more generic than that and not
> > have the mac address hardcoded as the purpose. We could possibly use
> > regmap as the in-kernel interface, and come up with a more generic
> > way of referring to registers in another device node.
> 
> Hmm, I maybe wasn't as clear as I wanted. Here mac-storage was just an
> example. It should indeed be completely generic, and a device could have
> several "storage source" defined, each driver knowing what property it
> would need, pretty much like what's done currently for the regulators
> for example.
> 
> We will have such a use case anyway for the Allwinner stuff, since the
> fuses can be used for several thing, including storing the SoC ID,
> serial numbers, and so on.

Ah, I see. In general, we have two ways of expressing the same thing
here:

a) like interrupts, regs, dmas, clocks, pinctrl, reset, pwm: fixed property names

	regmap = <&at25 0xstart 0xlen>;
	regmap-names = "mac-address";

b) like gpio, regulator: variable property names

	mac-storage = <&at25 0xstart 0xlen>;

It's unfortunate that we already have examples of both. They are largely
equivalent, but the tendency is towards the first.

	Arnd


From thomas.petazzoni at free-electrons.com  Fri Jul  5 18:37:32 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 6 Jul 2013 00:37:32 +0200
Subject: [PATCH v6 00/21] MBus DT binding: PCIe strikes back
In-Reply-To: <20130705220820.GA11787@obsidianresearch.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130705220820.GA11787@obsidianresearch.com>
Message-ID: <20130706003732.2013fd8e@skate>

Dear Jason Gunthorpe,

Thanks for your quick feedback!

On Fri, 5 Jul 2013 16:08:20 -0600, Jason Gunthorpe wrote:
> On Fri, Jul 05, 2013 at 06:39:11PM -0300, Ezequiel Garcia wrote:
>  
> > 			ranges =
> > 			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
> > 				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
> > 				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
> > 				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
> > 				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
> > 				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
> > 				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>;
> 
> This is a good try, but this coding doesn't work...
> 
> Recall the long discussion that came up during the original
> development of this binding. The OF spec says this:
> 
>  In particular, the phys.hi fields of the child address spaces in the
>  "ranges" property for PCI does not contain
>  the same information as "reg" property entries within PCI nodes. The
>  only information that is present in
>  "ranges" phys.hi entries are the non-relocatable, prefetchable and
>  the PCI address space bits for which the en-
>  try applies. I.e., only the n, p and ss bits are present; the
>  bbbbbbbb, ddddd, fff and rrrrrrrr fields are 0.
> 
>  When an address is to be mapped through a PCI bus bridge node, the
>  phys.hi value of the address to be mapped
>  and the child field of a "ranges" entry should be masked so that only
>  the ss bits are compared. I.e., the only
>  portion of phys.hi that should participate in the range determination
>  is the address space indicator (the ss bits).
> 
> Which forbids (0x82000800 .. ..) from being in a ranges

Ah, right, I missed this part of the OF specification. Indeed, having
the ddddd bits non-zero was critical here to allow the PCIe driver to
find which MBUS_ID(x, y) to use for a particular PCIe interface.

> I don't have an idea how to encode MBUS_ID in the PCI-E ranges :(
> 
> Arnd? Didn't you have some idea?
> 
> FWIW, I like removing the string tables from the driver, you could
> keep the fake MBUS-ID and retain that change by adding a
> marvell,target-id type property to the bridges...

The problem we were trying to address here is that apparently the fake
MBUS-ID was not seen by Arnd as a correct solution, if we understood
correctly what Arnd said in
http://www.mail-archive.com/devicetree-discuss at lists.ozlabs.org/msg34650.html:

"""
Using 0xffff0002 as a placeholder for the pcie translation is definitely
better than 0xffff0000 as you had before, but let me ask again in case
you missed it the last time (and sorry if I missed the answer):

Why not just put the actual translation here the way it happens for each
of the PCIe ports? With the definition here, the PCIe driver actually
has no way to figure out what settings the windows need to use!
"""

We're not sure how to handle this comment properly in terms of DT
binding. What the PCIe driver needs is:

 *) One global range of addresses for PCIe memory regions and one global
    range of addresses for PCIe I/O regions. Those were until the v5 of
    this patch set expressed using a fake MBUS_ID(0xf0, 0x02). Those
    are global to all PCIe interfaces.

 *) The target and attribute values for MEM and I/O windows, that are
    per-PCIe interface.

As long as we can get those two informations from the DT, I believe
we're open to all your suggestions on how to encode them.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From arnd at arndb.de  Fri Jul  5 18:40:26 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 6 Jul 2013 00:40:26 +0200
Subject: [PATCH v6 00/21] MBus DT binding: PCIe strikes back
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <201307060040.27208.arnd@arndb.de>

On Friday 05 July 2013, Ezequiel Garcia wrote:
> See the previous version of this patchset for further context:
> 
> http://www.mail-archive.com/devicetree-discuss at lists.ozlabs.org/msg35753.html
> 
> This new proposal is an attempt to address some issues raised about the PCIe
> 'fake' windows mapping present in the previous version.
> 
> Instead of defining a 'fake' MBUS_ID(0xf0, 0x02) region for the whole
> PCIe memory and IO space, we use real target ID and attribute for the windows.

Hi Ezequiel,

This looks really nice, and I is getting very close to where I think it
needs to be headed. I'll have to do a more thorough review, but for now there
is only one detail that I think you should change (we can argue about that):

> 		pcie-controller {
> 			compatible = "marvell,armada-xp-pcie";
> 			status = "okay";
> 			device_type = "pci";
> 
> 			#address-cells = <3>;
> 			#size-cells = <2>;
> 
> 			ranges =
> 			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
> 				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
> 				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
> 				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
> 				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
> 				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
> 				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>;

From all I can tell, this is a correct representation of the
translation windows. The one change you made from what I suggested
(either intentionally or because I didn't make myself clear enough)
is that you keep encoding the aperture in the ranges property of
the pcie node.

	0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
			^^^^				^^^^		^^^

This describes the intended setting of the aperture in the mbus, not
the translation that is performed by the pcie-controller as I suggested.
That would look like

	0x82000800 0 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */

iow the first 4GB of the 0x82000800 memory space get translated to 4GB
at MBUS_ID(0x04, 0xe8), and the aperture is applied by translating a
small section of that into host mmio space.

The advantage of your approach is that you can keep the existing code
that extracts the aperture (0xe0000000-0xe8000000) from the 
pcie-controller node, and you don't have to find out the aperture
from separate DT property or from looking at the remaining available
address space in mbus.

The disadvantage is that you have mbus policy spread out between the
ranges properties of the mbus node and the pcie node, rather than
having the pcie-controller node just describe the hardware capabilities.

This is actually more of a problem for the I/O space, which is still not
correctly represented:

	0x81000800 0 0 MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000

is not what the hardware does, the hardware probably has something
like 

	0x81000800 0 0 MBUS_ID(0x04, 0xe0) 0 1 0

i.e. the PIO registers are at the start of the 4GB MBUS window and
you want them to get mapped at 0xe8000000, but that is no business
of the PCIe node. Since the addresses for I/O space are fixed (unlike
memory space, which is sized dynamically per port), it would be
straightforward to put the mappings into the mbus node:

	MBUS_ID(0x04, 0xe0) 0x00000 0xe8000000 0x10000 
	MBUS_ID(0x04, 0xe1) 0x10000 0xe8010000 0x10000
	MBUS_ID(0x04, 0xe2) 0x20000 0xe8020000 0x10000

Unfortunately, the number of mapping windows in mbus is very limited
on Armada XP, so you'd run out of windows too fast by mapping them
all at boot time. The options here are to either put them into the
ranges property anyway but get the mbus driver to not map them by
default, or to encode the policy in a different way. Note that the
physical addresses do not actually have to be contiguous any more now,
so one option would be for mbus to just fill the holes whenever
the pcie driver needs an I/O space window, but there we get close
to the "fully dynamic" model again.

	Arnd


From shuah.kh at samsung.com  Fri Jul  5 18:41:03 2013
From: shuah.kh at samsung.com (Shuah Khan)
Date: Fri,  5 Jul 2013 16:41:03 -0600
Subject: [PATCH] arm: Convert locomo platform and bus legacy pm_ops to
 dev_pm_ops
Message-ID: <1373064063-13473-1-git-send-email-shuah.kh@samsung.com>

Convert arch/arm/common/locomo platform and bus legacy pm_ops to dev_pm_ops.
This change also updates the use of COMFIG_PM to CONFIG_PM_SLEEP as this
platform and bus code implements PM_SLEEP ops and not the PM_RUNTIME ops.
Compile tested.

Signed-off-by: Shuah Khan <shuah.kh at samsung.com>
---
 arch/arm/common/locomo.c |   33 ++++++++++++++++++++-------------
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index b55c362..4028e41 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -262,7 +262,7 @@ locomo_init_one_child(struct locomo *lchip, struct locomo_dev_info *info)
 	return ret;
 }
 
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
 
 struct locomo_save_data {
 	u16	LCM_GPO;
@@ -272,9 +272,9 @@ struct locomo_save_data {
 	u16	LCM_SPIMD;
 };
 
-static int locomo_suspend(struct platform_device *dev, pm_message_t state)
+static int locomo_suspend(struct device *dev)
 {
-	struct locomo *lchip = platform_get_drvdata(dev);
+	struct locomo *lchip = platform_get_drvdata(to_platform_device(dev));
 	struct locomo_save_data *save;
 	unsigned long flags;
 
@@ -316,9 +316,9 @@ static int locomo_suspend(struct platform_device *dev, pm_message_t state)
 	return 0;
 }
 
-static int locomo_resume(struct platform_device *dev)
+static int locomo_resume(struct device *dev)
 {
-	struct locomo *lchip = platform_get_drvdata(dev);
+	struct locomo *lchip = platform_get_drvdata(to_platform_device(dev));
 	struct locomo_save_data *save;
 	unsigned long r;
 	unsigned long flags;
@@ -351,6 +351,8 @@ static int locomo_resume(struct platform_device *dev)
 
 	return 0;
 }
+
+static SIMPLE_DEV_PM_OPS(locomo_dev_pm_ops, locomo_suspend, locomo_resume);
 #endif
 
 
@@ -519,12 +521,11 @@ static int locomo_remove(struct platform_device *dev)
 static struct platform_driver locomo_device_driver = {
 	.probe		= locomo_probe,
 	.remove		= locomo_remove,
-#ifdef CONFIG_PM
-	.suspend	= locomo_suspend,
-	.resume		= locomo_resume,
-#endif
 	.driver		= {
 		.name	= "locomo",
+#ifdef CONFIG_PM_SLEEP
+		.pm	= &locomo_dev_pm_ops,
+#endif
 	},
 };
 
@@ -826,14 +827,15 @@ static int locomo_match(struct device *_dev, struct device_driver *_drv)
 	return dev->devid == drv->devid;
 }
 
-static int locomo_bus_suspend(struct device *dev, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int locomo_bus_suspend(struct device *dev)
 {
 	struct locomo_dev *ldev = LOCOMO_DEV(dev);
 	struct locomo_driver *drv = LOCOMO_DRV(dev->driver);
 	int ret = 0;
 
 	if (drv && drv->suspend)
-		ret = drv->suspend(ldev, state);
+		ret = drv->suspend(ldev, PMSG_SUSPEND);
 	return ret;
 }
 
@@ -848,6 +850,10 @@ static int locomo_bus_resume(struct device *dev)
 	return ret;
 }
 
+static SIMPLE_DEV_PM_OPS(locomo_bus_dev_pm_ops, locomo_bus_suspend,
+			 locomo_bus_resume);
+#endif
+
 static int locomo_bus_probe(struct device *dev)
 {
 	struct locomo_dev *ldev = LOCOMO_DEV(dev);
@@ -875,8 +881,9 @@ struct bus_type locomo_bus_type = {
 	.match		= locomo_match,
 	.probe		= locomo_bus_probe,
 	.remove		= locomo_bus_remove,
-	.suspend	= locomo_bus_suspend,
-	.resume		= locomo_bus_resume,
+#ifdef CONFIG_PM_SLEEP
+	.pm		= &locomo_bus_dev_pm_ops,
+#endif
 };
 
 int locomo_driver_register(struct locomo_driver *driver)
-- 
1.7.10.4



From shuah.kh at samsung.com  Fri Jul  5 18:43:43 2013
From: shuah.kh at samsung.com (Shuah Khan)
Date: Fri,  5 Jul 2013 16:43:43 -0600
Subject: [PATCH] arm: Convert scoop platform and bus legacy pm_ops to
 dev_pm_ops
Message-ID: <1373064223-13510-1-git-send-email-shuah.kh@samsung.com>

Convert arch/arm/common/scoop platform and bus legacy pm_ops to dev_pm_ops.
This change also updates the use of COMFIG_PM to CONFIG_PM_SLEEP as this
platform and bus code implements PM_SLEEP ops and not the PM_RUNTIME ops.
Compile tested.

Signed-off-by: Shuah Khan <shuah.kh at samsung.com>
---
 arch/arm/common/scoop.c |   19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/arch/arm/common/scoop.c b/arch/arm/common/scoop.c
index a5c3dc3..8d64fcb 100644
--- a/arch/arm/common/scoop.c
+++ b/arch/arm/common/scoop.c
@@ -141,7 +141,7 @@ EXPORT_SYMBOL(reset_scoop);
 EXPORT_SYMBOL(read_scoop_reg);
 EXPORT_SYMBOL(write_scoop_reg);
 
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
 static void check_scoop_reg(struct scoop_dev *sdev)
 {
 	unsigned short mcr;
@@ -151,9 +151,9 @@ static void check_scoop_reg(struct scoop_dev *sdev)
 		iowrite16(0x0101, sdev->base + SCOOP_MCR);
 }
 
-static int scoop_suspend(struct platform_device *dev, pm_message_t state)
+static int scoop_suspend(struct device *dev)
 {
-	struct scoop_dev *sdev = platform_get_drvdata(dev);
+	struct scoop_dev *sdev = platform_get_drvdata(to_platform_device(dev));
 
 	check_scoop_reg(sdev);
 	sdev->scoop_gpwr = ioread16(sdev->base + SCOOP_GPWR);
@@ -162,18 +162,16 @@ static int scoop_suspend(struct platform_device *dev, pm_message_t state)
 	return 0;
 }
 
-static int scoop_resume(struct platform_device *dev)
+static int scoop_resume(struct device *dev)
 {
-	struct scoop_dev *sdev = platform_get_drvdata(dev);
+	struct scoop_dev *sdev = platform_get_drvdata(to_platform_device(dev));
 
 	check_scoop_reg(sdev);
 	iowrite16(sdev->scoop_gpwr, sdev->base + SCOOP_GPWR);
 
 	return 0;
 }
-#else
-#define scoop_suspend	NULL
-#define scoop_resume	NULL
+static SIMPLE_DEV_PM_OPS(scoop_dev_pm_ops, scoop_suspend, scoop_resume);
 #endif
 
 static int scoop_probe(struct platform_device *pdev)
@@ -269,10 +267,11 @@ static int scoop_remove(struct platform_device *pdev)
 static struct platform_driver scoop_driver = {
 	.probe		= scoop_probe,
 	.remove		= scoop_remove,
-	.suspend	= scoop_suspend,
-	.resume		= scoop_resume,
 	.driver		= {
 		.name	= "sharp-scoop",
+#ifdef CONFIG_PM_SLEEP
+		.pm	= &scoop_dev_pm_ops,
+#endif
 	},
 };
 
-- 
1.7.10.4



From shuah.kh at samsung.com  Fri Jul  5 18:44:57 2013
From: shuah.kh at samsung.com (Shuah Khan)
Date: Fri,  5 Jul 2013 16:44:57 -0600
Subject: [PATCH] arm: Convert sa1111 platform and bus legacy pm_ops to
 dev_pm_ops
Message-ID: <1373064297-13582-1-git-send-email-shuah.kh@samsung.com>

Convert arch/arm/common/sa1111 platform and bus legacy pm_ops to dev_pm_ops.
This change also updates the use of COMFIG_PM to CONFIG_PM_SLEEP as this
platform and bus code implements PM_SLEEP ops and not the PM_RUNTIME ops.
Compile tested.

Signed-off-by: Shuah Khan <shuah.kh at samsung.com>
---
 arch/arm/common/sa1111.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/common/sa1111.c b/arch/arm/common/sa1111.c
index 2a64c12..95594f0 100644
--- a/arch/arm/common/sa1111.c
+++ b/arch/arm/common/sa1111.c
@@ -1321,7 +1321,7 @@ static int sa1111_bus_resume(struct device *dev)
 }
 static SIMPLE_DEV_PM_OPS(sa1111_bus_dev_pm_ops, sa1111_bus_suspend,
 			 sa1111_bus_resume);
-#endif 
+#endif
 
 static void sa1111_bus_shutdown(struct device *dev)
 {
-- 
1.7.10.4



From sergei.shtylyov at cogentembedded.com  Fri Jul  5 18:48:03 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 06 Jul 2013 02:48:03 +0400
Subject: [PATCH] arm: Convert sa1111 platform and bus legacy pm_ops to
 dev_pm_ops
In-Reply-To: <1373064297-13582-1-git-send-email-shuah.kh@samsung.com>
References: <1373064297-13582-1-git-send-email-shuah.kh@samsung.com>
Message-ID: <51D74D23.8030805@cogentembedded.com>

Hello.

On 07/06/2013 02:44 AM, Shuah Khan wrote:

> Convert arch/arm/common/sa1111 platform and bus legacy pm_ops to dev_pm_ops.
> This change also updates the use of COMFIG_PM to CONFIG_PM_SLEEP as this
> platform and bus code implements PM_SLEEP ops and not the PM_RUNTIME ops.
> Compile tested.

    It may be compile tested but the patch description doesn't match the 
patch (which is a simple trailing space fix).

> Signed-off-by: Shuah Khan <shuah.kh at samsung.com>
> ---
>   arch/arm/common/sa1111.c |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/common/sa1111.c b/arch/arm/common/sa1111.c
> index 2a64c12..95594f0 100644
> --- a/arch/arm/common/sa1111.c
> +++ b/arch/arm/common/sa1111.c
> @@ -1321,7 +1321,7 @@ static int sa1111_bus_resume(struct device *dev)
>   }
>   static SIMPLE_DEV_PM_OPS(sa1111_bus_dev_pm_ops, sa1111_bus_suspend,
>   			 sa1111_bus_resume);
> -#endif
> +#endif

WBR, Sergei




From linux at arm.linux.org.uk  Fri Jul  5 18:48:14 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 5 Jul 2013 23:48:14 +0100
Subject: [PATCH] arm: Convert sa1111 platform and bus legacy pm_ops to
 dev_pm_ops
In-Reply-To: <1373064297-13582-1-git-send-email-shuah.kh@samsung.com>
References: <1373064297-13582-1-git-send-email-shuah.kh@samsung.com>
Message-ID: <20130705224814.GM24642@n2100.arm.linux.org.uk>

On Fri, Jul 05, 2013 at 04:44:57PM -0600, Shuah Khan wrote:
> Convert arch/arm/common/sa1111 platform and bus legacy pm_ops to dev_pm_ops.
> This change also updates the use of COMFIG_PM to CONFIG_PM_SLEEP as this
> platform and bus code implements PM_SLEEP ops and not the PM_RUNTIME ops.
> Compile tested.

Err...

> diff --git a/arch/arm/common/sa1111.c b/arch/arm/common/sa1111.c
> index 2a64c12..95594f0 100644
> --- a/arch/arm/common/sa1111.c
> +++ b/arch/arm/common/sa1111.c
> @@ -1321,7 +1321,7 @@ static int sa1111_bus_resume(struct device *dev)
>  }
>  static SIMPLE_DEV_PM_OPS(sa1111_bus_dev_pm_ops, sa1111_bus_suspend,
>  			 sa1111_bus_resume);
> -#endif 
> +#endif

Patch doesn't match description.


From shuah.kh at samsung.com  Fri Jul  5 18:49:21 2013
From: shuah.kh at samsung.com (Shuah Khan)
Date: Fri, 05 Jul 2013 22:49:21 +0000
Subject: [PATCH] arm: Convert sa1111 platform and bus legacy pm_ops to
 dev_pm_ops
References: <1373064297-13582-1-git-send-email-shuah.kh@samsung.com>
Message-ID: <B8EFE96D1287C24090BAD9D858E15E617360A6@sisaex02sj>

On 07/05/2013 04:45 PM, Shuah Khan wrote:
> Convert arch/arm/common/sa1111 platform and bus legacy pm_ops to dev_pm_ops.
> This change also updates the use of COMFIG_PM to CONFIG_PM_SLEEP as this
> platform and bus code implements PM_SLEEP ops and not the PM_RUNTIME ops.
> Compile tested.
>
> Signed-off-by: Shuah Khan <shuah.kh at samsung.com>
> ---
>   arch/arm/common/sa1111.c |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/common/sa1111.c b/arch/arm/common/sa1111.c
> index 2a64c12..95594f0 100644
> --- a/arch/arm/common/sa1111.c
> +++ b/arch/arm/common/sa1111.c
> @@ -1321,7 +1321,7 @@ static int sa1111_bus_resume(struct device *dev)
>   }
>   static SIMPLE_DEV_PM_OPS(sa1111_bus_dev_pm_ops, sa1111_bus_suspend,
>   			 sa1111_bus_resume);
> -#endif
> +#endif
>
>   static void sa1111_bus_shutdown(struct device *dev)
>   {
>

Please ignore this patch - it is not correct.

-- Shuah

-- 
Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research 
America (Silicon Valley) shuah.kh at samsung.com | (970) 672-0658


From heiko at sntech.de  Fri Jul  5 18:51:08 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 6 Jul 2013 00:51:08 +0200
Subject: [PATCH 0/9] clocksource: dw_apb_timer: support for timer variant used
 in rk3188 SoCs
Message-ID: <201307060051.09716.heiko@sntech.de>

The Rockchip rk3188 SoCs use a variant of the timer with some slight
modifications. This series implements them as quirks for the dw_apb_timer.

Tested on a rk3188 for the quirk handling and on a rk3066a to check that
nothing broke.

Heiko Stuebner (5):
  clocksource: dw_apb_timer: infrastructure to handle quirks
  clocksource: dw_apb_timer: flexible register addresses
  clocksource: dw_apb_timer: quirk for variants with 64bit counter
  clocksource: dw_apb_timer_of: add quirk handling
  clocksource: dw_apb_timer: special variant for rockchip rk3188 timers

Ulrich Prinz (4):
  clocksource: dw_apb_timer: use the eoi callback to clear pending interrupts
  clocksource: dw_apb_timer: quirk for variants without EOI register
  clocksource: dw_apb_timer: quirk for inverted int mask
  clocksource: dw_apb_timer: quirk for inverted timer mode setting

 .../bindings/arm/rockchip/rk3188-timer.txt         |   20 +++
 arch/x86/kernel/apb_timer.c                        |    4 +-
 drivers/clocksource/dw_apb_timer.c                 |  166 +++++++++++++++-----
 drivers/clocksource/dw_apb_timer_of.c              |   27 +++-
 include/linux/dw_apb_timer.h                       |   34 +++-
 5 files changed, 198 insertions(+), 53 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/rk3188-timer.txt

-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 18:51:52 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 6 Jul 2013 00:51:52 +0200
Subject: [PATCH 1/9] clocksource: dw_apb_timer: infrastructure to handle quirks
In-Reply-To: <201307060051.09716.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
Message-ID: <201307060051.53244.heiko@sntech.de>

There exist variants of the timer IP with some modified properties.

Therefore add infrastructure to handle hardware-quirks in the driver.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 arch/x86/kernel/apb_timer.c           |    4 ++--
 drivers/clocksource/dw_apb_timer.c    |    7 +++++--
 drivers/clocksource/dw_apb_timer_of.c |    4 ++--
 include/linux/dw_apb_timer.h          |    6 ++++--
 4 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/apb_timer.c b/arch/x86/kernel/apb_timer.c
index c9876ef..e7fe0f6 100644
--- a/arch/x86/kernel/apb_timer.c
+++ b/arch/x86/kernel/apb_timer.c
@@ -121,7 +121,7 @@ static inline void apbt_set_mapping(void)
 
 	clocksource_apbt = dw_apb_clocksource_init(APBT_CLOCKSOURCE_RATING,
 		"apbt0", apbt_virt_address + phy_cs_timer_id *
-		APBTMRS_REG_SIZE, apbt_freq);
+		APBTMRS_REG_SIZE, apbt_freq, 0);
 	return;
 
 panic_noapbt:
@@ -159,7 +159,7 @@ static int __init apbt_clockevent_register(void)
 	adev->timer = dw_apb_clockevent_init(smp_processor_id(), "apbt0",
 		mrst_timer_options == MRST_TIMER_LAPIC_APBT ?
 		APBT_CLOCKEVENT_RATING - 100 : APBT_CLOCKEVENT_RATING,
-		adev_virt_addr(adev), 0, apbt_freq);
+		adev_virt_addr(adev), 0, apbt_freq, 0);
 	/* Firmware does EOI handling for us. */
 	adev->timer->eoi = NULL;
 
diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
index 8c2a35f..01bdac0 100644
--- a/drivers/clocksource/dw_apb_timer.c
+++ b/drivers/clocksource/dw_apb_timer.c
@@ -213,7 +213,8 @@ static int apbt_next_event(unsigned long delta,
  */
 struct dw_apb_clock_event_device *
 dw_apb_clockevent_init(int cpu, const char *name, unsigned rating,
-		       void __iomem *base, int irq, unsigned long freq)
+		       void __iomem *base, int irq, unsigned long freq,
+		       int quirks)
 {
 	struct dw_apb_clock_event_device *dw_ced =
 		kzalloc(sizeof(*dw_ced), GFP_KERNEL);
@@ -225,6 +226,7 @@ dw_apb_clockevent_init(int cpu, const char *name, unsigned rating,
 	dw_ced->timer.base = base;
 	dw_ced->timer.irq = irq;
 	dw_ced->timer.freq = freq;
+	dw_ced->timer.quirks = quirks;
 
 	clockevents_calc_mult_shift(&dw_ced->ced, freq, APBT_MIN_PERIOD);
 	dw_ced->ced.max_delta_ns = clockevent_delta2ns(0x7fffffff,
@@ -349,7 +351,7 @@ static void apbt_restart_clocksource(struct clocksource *cs)
  */
 struct dw_apb_clocksource *
 dw_apb_clocksource_init(unsigned rating, const char *name, void __iomem *base,
-			unsigned long freq)
+			unsigned long freq, int quirks)
 {
 	struct dw_apb_clocksource *dw_cs = kzalloc(sizeof(*dw_cs), GFP_KERNEL);
 
@@ -358,6 +360,7 @@ dw_apb_clocksource_init(unsigned rating, const char *name, void __iomem *base,
 
 	dw_cs->timer.base = base;
 	dw_cs->timer.freq = freq;
+	dw_cs->timer.quirks = quirks;
 	dw_cs->cs.name = name;
 	dw_cs->cs.rating = rating;
 	dw_cs->cs.read = __apbt_read_clocksource;
diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
index cef5544..b5412af 100644
--- a/drivers/clocksource/dw_apb_timer_of.c
+++ b/drivers/clocksource/dw_apb_timer_of.c
@@ -74,7 +74,7 @@ static void add_clockevent(struct device_node *event_timer)
 	timer_get_base_and_rate(event_timer, &iobase, &rate);
 
 	ced = dw_apb_clockevent_init(0, event_timer->name, 300, iobase, irq,
-				     rate);
+				     rate, 0);
 	if (!ced)
 		panic("Unable to initialise clockevent device");
 
@@ -92,7 +92,7 @@ static void add_clocksource(struct device_node *source_timer)
 
 	timer_get_base_and_rate(source_timer, &iobase, &rate);
 
-	cs = dw_apb_clocksource_init(300, source_timer->name, iobase, rate);
+	cs = dw_apb_clocksource_init(300, source_timer->name, iobase, rate, 0);
 	if (!cs)
 		panic("Unable to initialise clocksource device");
 
diff --git a/include/linux/dw_apb_timer.h b/include/linux/dw_apb_timer.h
index 07261d5..67d09c7 100644
--- a/include/linux/dw_apb_timer.h
+++ b/include/linux/dw_apb_timer.h
@@ -23,6 +23,7 @@ struct dw_apb_timer {
 	void __iomem				*base;
 	unsigned long				freq;
 	int					irq;
+	int					quirks;
 };
 
 struct dw_apb_clock_event_device {
@@ -44,10 +45,11 @@ void dw_apb_clockevent_stop(struct dw_apb_clock_event_device *dw_ced);
 
 struct dw_apb_clock_event_device *
 dw_apb_clockevent_init(int cpu, const char *name, unsigned rating,
-		       void __iomem *base, int irq, unsigned long freq);
+		       void __iomem *base, int irq, unsigned long freq,
+		       int quirks);
 struct dw_apb_clocksource *
 dw_apb_clocksource_init(unsigned rating, const char *name, void __iomem *base,
-			unsigned long freq);
+			unsigned long freq, int quirks);
 void dw_apb_clocksource_register(struct dw_apb_clocksource *dw_cs);
 void dw_apb_clocksource_start(struct dw_apb_clocksource *dw_cs);
 cycle_t dw_apb_clocksource_read(struct dw_apb_clocksource *dw_cs);
-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 18:52:31 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 6 Jul 2013 00:52:31 +0200
Subject: [PATCH 2/9] clocksource: dw_apb_timer: flexible register addresses
In-Reply-To: <201307060051.09716.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
Message-ID: <201307060052.31758.heiko@sntech.de>

There exists variants of the apb-timer that use slightly different
register positions. To accomodate this, add elements to the timer struct
to hold the actual register offsets.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 drivers/clocksource/dw_apb_timer.c |   83 ++++++++++++++++++++++--------------
 include/linux/dw_apb_timer.h       |    5 +++
 2 files changed, 56 insertions(+), 32 deletions(-)

diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
index 01bdac0..f5e7be8 100644
--- a/drivers/clocksource/dw_apb_timer.c
+++ b/drivers/clocksource/dw_apb_timer.c
@@ -49,6 +49,15 @@ clocksource_to_dw_apb_clocksource(struct clocksource *cs)
 	return container_of(cs, struct dw_apb_clocksource, cs);
 }
 
+static void apbt_init_regs(struct dw_apb_timer *timer, int quirks)
+{
+	timer->reg_load_count = APBTMR_N_LOAD_COUNT;
+	timer->reg_current_value = APBTMR_N_CURRENT_VALUE;
+	timer->reg_control = APBTMR_N_CONTROL;
+	timer->reg_eoi = APBTMR_N_EOI;
+	timer->reg_int_status = APBTMR_N_INT_STATUS;
+}
+
 static unsigned long apbt_readl(struct dw_apb_timer *timer, unsigned long offs)
 {
 	return readl(timer->base + offs);
@@ -62,10 +71,10 @@ static void apbt_writel(struct dw_apb_timer *timer, unsigned long val,
 
 static void apbt_disable_int(struct dw_apb_timer *timer)
 {
-	unsigned long ctrl = apbt_readl(timer, APBTMR_N_CONTROL);
+	unsigned long ctrl = apbt_readl(timer, timer->reg_control);
 
 	ctrl |= APBTMR_CONTROL_INT;
-	apbt_writel(timer, ctrl, APBTMR_N_CONTROL);
+	apbt_writel(timer, ctrl, timer->reg_control);
 }
 
 /**
@@ -81,7 +90,7 @@ void dw_apb_clockevent_pause(struct dw_apb_clock_event_device *dw_ced)
 
 static void apbt_eoi(struct dw_apb_timer *timer)
 {
-	apbt_readl(timer, APBTMR_N_EOI);
+	apbt_readl(timer, timer->reg_eoi);
 }
 
 static irqreturn_t dw_apb_clockevent_irq(int irq, void *data)
@@ -103,11 +112,11 @@ static irqreturn_t dw_apb_clockevent_irq(int irq, void *data)
 
 static void apbt_enable_int(struct dw_apb_timer *timer)
 {
-	unsigned long ctrl = apbt_readl(timer, APBTMR_N_CONTROL);
+	unsigned long ctrl = apbt_readl(timer, timer->reg_control);
 	/* clear pending intr */
-	apbt_readl(timer, APBTMR_N_EOI);
+	apbt_readl(timer, timer->reg_eoi);
 	ctrl &= ~APBTMR_CONTROL_INT;
-	apbt_writel(timer, ctrl, APBTMR_N_CONTROL);
+	apbt_writel(timer, ctrl, timer->reg_control);
 }
 
 static void apbt_set_mode(enum clock_event_mode mode,
@@ -116,31 +125,32 @@ static void apbt_set_mode(enum clock_event_mode mode,
 	unsigned long ctrl;
 	unsigned long period;
 	struct dw_apb_clock_event_device *dw_ced = ced_to_dw_apb_ced(evt);
+	struct dw_apb_timer *timer = &dw_ced->timer;
 
 	pr_debug("%s CPU %d mode=%d\n", __func__, first_cpu(*evt->cpumask),
 		 mode);
 
 	switch (mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
-		period = DIV_ROUND_UP(dw_ced->timer.freq, HZ);
-		ctrl = apbt_readl(&dw_ced->timer, APBTMR_N_CONTROL);
+		period = DIV_ROUND_UP(timer->freq, HZ);
+		ctrl = apbt_readl(timer, timer->reg_control);
 		ctrl |= APBTMR_CONTROL_MODE_PERIODIC;
-		apbt_writel(&dw_ced->timer, ctrl, APBTMR_N_CONTROL);
+		apbt_writel(timer, ctrl, timer->reg_control);
 		/*
 		 * DW APB p. 46, have to disable timer before load counter,
 		 * may cause sync problem.
 		 */
 		ctrl &= ~APBTMR_CONTROL_ENABLE;
-		apbt_writel(&dw_ced->timer, ctrl, APBTMR_N_CONTROL);
+		apbt_writel(timer, ctrl, timer->reg_control);
 		udelay(1);
 		pr_debug("Setting clock period %lu for HZ %d\n", period, HZ);
-		apbt_writel(&dw_ced->timer, period, APBTMR_N_LOAD_COUNT);
+		apbt_writel(timer, period, timer->reg_load_count);
 		ctrl |= APBTMR_CONTROL_ENABLE;
-		apbt_writel(&dw_ced->timer, ctrl, APBTMR_N_CONTROL);
+		apbt_writel(timer, ctrl, timer->reg_control);
 		break;
 
 	case CLOCK_EVT_MODE_ONESHOT:
-		ctrl = apbt_readl(&dw_ced->timer, APBTMR_N_CONTROL);
+		ctrl = apbt_readl(timer, timer->reg_control);
 		/*
 		 * set free running mode, this mode will let timer reload max
 		 * timeout which will give time (3min on 25MHz clock) to rearm
@@ -149,29 +159,29 @@ static void apbt_set_mode(enum clock_event_mode mode,
 		ctrl &= ~APBTMR_CONTROL_ENABLE;
 		ctrl &= ~APBTMR_CONTROL_MODE_PERIODIC;
 
-		apbt_writel(&dw_ced->timer, ctrl, APBTMR_N_CONTROL);
+		apbt_writel(timer, ctrl, timer->reg_control);
 		/* write again to set free running mode */
-		apbt_writel(&dw_ced->timer, ctrl, APBTMR_N_CONTROL);
+		apbt_writel(timer, ctrl, timer->reg_control);
 
 		/*
 		 * DW APB p. 46, load counter with all 1s before starting free
 		 * running mode.
 		 */
-		apbt_writel(&dw_ced->timer, ~0, APBTMR_N_LOAD_COUNT);
+		apbt_writel(timer, ~0, timer->reg_load_count);
 		ctrl &= ~APBTMR_CONTROL_INT;
 		ctrl |= APBTMR_CONTROL_ENABLE;
-		apbt_writel(&dw_ced->timer, ctrl, APBTMR_N_CONTROL);
+		apbt_writel(timer, ctrl, timer->reg_control);
 		break;
 
 	case CLOCK_EVT_MODE_UNUSED:
 	case CLOCK_EVT_MODE_SHUTDOWN:
-		ctrl = apbt_readl(&dw_ced->timer, APBTMR_N_CONTROL);
+		ctrl = apbt_readl(timer, timer->reg_control);
 		ctrl &= ~APBTMR_CONTROL_ENABLE;
-		apbt_writel(&dw_ced->timer, ctrl, APBTMR_N_CONTROL);
+		apbt_writel(timer, ctrl, timer->reg_control);
 		break;
 
 	case CLOCK_EVT_MODE_RESUME:
-		apbt_enable_int(&dw_ced->timer);
+		apbt_enable_int(timer);
 		break;
 	}
 }
@@ -181,15 +191,16 @@ static int apbt_next_event(unsigned long delta,
 {
 	unsigned long ctrl;
 	struct dw_apb_clock_event_device *dw_ced = ced_to_dw_apb_ced(evt);
+	struct dw_apb_timer *timer = &dw_ced->timer;
 
 	/* Disable timer */
-	ctrl = apbt_readl(&dw_ced->timer, APBTMR_N_CONTROL);
+	ctrl = apbt_readl(timer, timer->reg_control);
 	ctrl &= ~APBTMR_CONTROL_ENABLE;
-	apbt_writel(&dw_ced->timer, ctrl, APBTMR_N_CONTROL);
+	apbt_writel(timer, ctrl, timer->reg_control);
 	/* write new count */
-	apbt_writel(&dw_ced->timer, delta, APBTMR_N_LOAD_COUNT);
+	apbt_writel(timer, delta, timer->reg_load_count);
 	ctrl |= APBTMR_CONTROL_ENABLE;
-	apbt_writel(&dw_ced->timer, ctrl, APBTMR_N_CONTROL);
+	apbt_writel(timer, ctrl, timer->reg_control);
 
 	return 0;
 }
@@ -227,6 +238,7 @@ dw_apb_clockevent_init(int cpu, const char *name, unsigned rating,
 	dw_ced->timer.irq = irq;
 	dw_ced->timer.freq = freq;
 	dw_ced->timer.quirks = quirks;
+	apbt_init_regs(&dw_ced->timer, quirks);
 
 	clockevents_calc_mult_shift(&dw_ced->ced, freq, APBT_MIN_PERIOD);
 	dw_ced->ced.max_delta_ns = clockevent_delta2ns(0x7fffffff,
@@ -286,9 +298,11 @@ void dw_apb_clockevent_stop(struct dw_apb_clock_event_device *dw_ced)
  */
 void dw_apb_clockevent_register(struct dw_apb_clock_event_device *dw_ced)
 {
-	apbt_writel(&dw_ced->timer, 0, APBTMR_N_CONTROL);
+	struct dw_apb_timer *timer = &dw_ced->timer;
+
+	apbt_writel(timer, 0, timer->reg_control);
 	clockevents_register_device(&dw_ced->ced);
-	apbt_enable_int(&dw_ced->timer);
+	apbt_enable_int(timer);
 }
 
 /**
@@ -301,19 +315,20 @@ void dw_apb_clockevent_register(struct dw_apb_clock_event_device *dw_ced)
  */
 void dw_apb_clocksource_start(struct dw_apb_clocksource *dw_cs)
 {
+	struct dw_apb_timer *timer = &dw_cs->timer;
 	/*
 	 * start count down from 0xffff_ffff. this is done by toggling the
 	 * enable bit then load initial load count to ~0.
 	 */
-	unsigned long ctrl = apbt_readl(&dw_cs->timer, APBTMR_N_CONTROL);
+	unsigned long ctrl = apbt_readl(timer, timer->reg_control);
 
 	ctrl &= ~APBTMR_CONTROL_ENABLE;
-	apbt_writel(&dw_cs->timer, ctrl, APBTMR_N_CONTROL);
-	apbt_writel(&dw_cs->timer, ~0, APBTMR_N_LOAD_COUNT);
+	apbt_writel(timer, ctrl, timer->reg_control);
+	apbt_writel(timer, ~0, timer->reg_load_count);
 	/* enable, mask interrupt */
 	ctrl &= ~APBTMR_CONTROL_MODE_PERIODIC;
 	ctrl |= (APBTMR_CONTROL_ENABLE | APBTMR_CONTROL_INT);
-	apbt_writel(&dw_cs->timer, ctrl, APBTMR_N_CONTROL);
+	apbt_writel(timer, ctrl, timer->reg_control);
 	/* read it once to get cached counter value initialized */
 	dw_apb_clocksource_read(dw_cs);
 }
@@ -323,8 +338,9 @@ static cycle_t __apbt_read_clocksource(struct clocksource *cs)
 	unsigned long current_count;
 	struct dw_apb_clocksource *dw_cs =
 		clocksource_to_dw_apb_clocksource(cs);
+	struct dw_apb_timer *timer = &dw_cs->timer;
 
-	current_count = apbt_readl(&dw_cs->timer, APBTMR_N_CURRENT_VALUE);
+	current_count = apbt_readl(timer, timer->reg_current_value);
 
 	return (cycle_t)~current_count;
 }
@@ -361,6 +377,8 @@ dw_apb_clocksource_init(unsigned rating, const char *name, void __iomem *base,
 	dw_cs->timer.base = base;
 	dw_cs->timer.freq = freq;
 	dw_cs->timer.quirks = quirks;
+	apbt_init_regs(&dw_cs->timer, quirks);
+
 	dw_cs->cs.name = name;
 	dw_cs->cs.rating = rating;
 	dw_cs->cs.read = __apbt_read_clocksource;
@@ -388,7 +406,8 @@ void dw_apb_clocksource_register(struct dw_apb_clocksource *dw_cs)
  */
 cycle_t dw_apb_clocksource_read(struct dw_apb_clocksource *dw_cs)
 {
-	return (cycle_t)~apbt_readl(&dw_cs->timer, APBTMR_N_CURRENT_VALUE);
+	struct dw_apb_timer *timer = &dw_cs->timer;
+	return (cycle_t)~apbt_readl(timer, timer->reg_current_value);
 }
 
 /**
diff --git a/include/linux/dw_apb_timer.h b/include/linux/dw_apb_timer.h
index 67d09c7..7dc7166 100644
--- a/include/linux/dw_apb_timer.h
+++ b/include/linux/dw_apb_timer.h
@@ -24,6 +24,11 @@ struct dw_apb_timer {
 	unsigned long				freq;
 	int					irq;
 	int					quirks;
+	u8					reg_load_count;
+	u8					reg_current_value;
+	u8					reg_control;
+	u8					reg_eoi;
+	u8					reg_int_status;
 };
 
 struct dw_apb_clock_event_device {
-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 18:53:09 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 6 Jul 2013 00:53:09 +0200
Subject: [PATCH 3/9] clocksource: dw_apb_timer: quirk for variants with 64bit
 counter
In-Reply-To: <201307060051.09716.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
Message-ID: <201307060053.10182.heiko@sntech.de>

This adds a quirk for IP variants containing two load_count and value
registers that are used to provide 64bit accuracy on 32bit systems.

The added accuracy is currently not used, the driver is only adapted to
handle the different register layout and make it work on affected devices.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 drivers/clocksource/dw_apb_timer.c |   27 +++++++++++++++++++++++++++
 include/linux/dw_apb_timer.h       |    6 ++++++
 2 files changed, 33 insertions(+)

diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
index f5e7be8..bd45351 100644
--- a/drivers/clocksource/dw_apb_timer.c
+++ b/drivers/clocksource/dw_apb_timer.c
@@ -56,6 +56,17 @@ static void apbt_init_regs(struct dw_apb_timer *timer, int quirks)
 	timer->reg_control = APBTMR_N_CONTROL;
 	timer->reg_eoi = APBTMR_N_EOI;
 	timer->reg_int_status = APBTMR_N_INT_STATUS;
+
+	/*
+	 * On variants with 64bit counters some registers are
+	 * moved further down.
+	 */
+	if (quirks & APBTMR_QUIRK_64BIT_COUNTER) {
+		timer->reg_current_value += 0x4;
+		timer->reg_control += 0x8;
+		timer->reg_eoi += 0x8;
+		timer->reg_int_status += 0x8;
+	}
 }
 
 static unsigned long apbt_readl(struct dw_apb_timer *timer, unsigned long offs)
@@ -145,6 +156,10 @@ static void apbt_set_mode(enum clock_event_mode mode,
 		udelay(1);
 		pr_debug("Setting clock period %lu for HZ %d\n", period, HZ);
 		apbt_writel(timer, period, timer->reg_load_count);
+
+		if (timer->quirks & APBTMR_QUIRK_64BIT_COUNTER)
+			apbt_writel(timer, 0, timer->reg_load_count + 0x4);
+
 		ctrl |= APBTMR_CONTROL_ENABLE;
 		apbt_writel(timer, ctrl, timer->reg_control);
 		break;
@@ -168,6 +183,10 @@ static void apbt_set_mode(enum clock_event_mode mode,
 		 * running mode.
 		 */
 		apbt_writel(timer, ~0, timer->reg_load_count);
+
+		if (timer->quirks & APBTMR_QUIRK_64BIT_COUNTER)
+			apbt_writel(timer, 0, timer->reg_load_count + 0x4);
+
 		ctrl &= ~APBTMR_CONTROL_INT;
 		ctrl |= APBTMR_CONTROL_ENABLE;
 		apbt_writel(timer, ctrl, timer->reg_control);
@@ -199,6 +218,10 @@ static int apbt_next_event(unsigned long delta,
 	apbt_writel(timer, ctrl, timer->reg_control);
 	/* write new count */
 	apbt_writel(timer, delta, timer->reg_load_count);
+
+	if (timer->quirks & APBTMR_QUIRK_64BIT_COUNTER)
+		apbt_writel(timer, 0, timer->reg_load_count + 0x4);
+
 	ctrl |= APBTMR_CONTROL_ENABLE;
 	apbt_writel(timer, ctrl, timer->reg_control);
 
@@ -325,6 +348,10 @@ void dw_apb_clocksource_start(struct dw_apb_clocksource *dw_cs)
 	ctrl &= ~APBTMR_CONTROL_ENABLE;
 	apbt_writel(timer, ctrl, timer->reg_control);
 	apbt_writel(timer, ~0, timer->reg_load_count);
+
+	if (timer->quirks & APBTMR_QUIRK_64BIT_COUNTER)
+		apbt_writel(timer, 0, timer->reg_load_count + 0x4);
+
 	/* enable, mask interrupt */
 	ctrl &= ~APBTMR_CONTROL_MODE_PERIODIC;
 	ctrl |= (APBTMR_CONTROL_ENABLE | APBTMR_CONTROL_INT);
diff --git a/include/linux/dw_apb_timer.h b/include/linux/dw_apb_timer.h
index 7dc7166..80f6686 100644
--- a/include/linux/dw_apb_timer.h
+++ b/include/linux/dw_apb_timer.h
@@ -19,6 +19,12 @@
 
 #define APBTMRS_REG_SIZE       0x14
 
+/* The IP uses two registers for count and values, to provide 64bit accuracy
+ * on 32bit platforms. The additional registers move the following registers
+ * down by 0x8 byte, as both the count and value registers are duplicated.
+ */
+#define APBTMR_QUIRK_64BIT_COUNTER	BIT(0)
+
 struct dw_apb_timer {
 	void __iomem				*base;
 	unsigned long				freq;
-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 18:53:36 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 6 Jul 2013 00:53:36 +0200
Subject: [PATCH 4/9] clocksource: dw_apb_timer: use the eoi callback to clear
 pending interrupts
In-Reply-To: <201307060051.09716.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
Message-ID: <201307060053.36885.heiko@sntech.de>

Some timer variants have different mechanisms to clear a pending timer
interrupt. Therefore don't hardcode the reading of the eoi register to
clear them, but instead use the already existing eoi callback for this.

Signed-off-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
 drivers/clocksource/dw_apb_timer.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
index bd45351..5f80a30 100644
--- a/drivers/clocksource/dw_apb_timer.c
+++ b/drivers/clocksource/dw_apb_timer.c
@@ -121,11 +121,14 @@ static irqreturn_t dw_apb_clockevent_irq(int irq, void *data)
 	return IRQ_HANDLED;
 }
 
-static void apbt_enable_int(struct dw_apb_timer *timer)
+static void apbt_enable_int(struct dw_apb_clock_event_device *dw_ced)
 {
+	struct dw_apb_timer *timer = &dw_ced->timer;
 	unsigned long ctrl = apbt_readl(timer, timer->reg_control);
+
 	/* clear pending intr */
-	apbt_readl(timer, timer->reg_eoi);
+	if (dw_ced->eoi)
+		dw_ced->eoi(timer);
 	ctrl &= ~APBTMR_CONTROL_INT;
 	apbt_writel(timer, ctrl, timer->reg_control);
 }
@@ -200,7 +203,7 @@ static void apbt_set_mode(enum clock_event_mode mode,
 		break;
 
 	case CLOCK_EVT_MODE_RESUME:
-		apbt_enable_int(timer);
+		apbt_enable_int(dw_ced);
 		break;
 	}
 }
@@ -325,7 +328,7 @@ void dw_apb_clockevent_register(struct dw_apb_clock_event_device *dw_ced)
 
 	apbt_writel(timer, 0, timer->reg_control);
 	clockevents_register_device(&dw_ced->ced);
-	apbt_enable_int(timer);
+	apbt_enable_int(dw_ced);
 }
 
 /**
-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 18:54:07 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 6 Jul 2013 00:54:07 +0200
Subject: [PATCH 5/9] clocksource: dw_apb_timer: quirk for variants without EOI
 register
In-Reply-To: <201307060051.09716.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
Message-ID: <201307060054.07784.heiko@sntech.de>

Some variants of the dw_apb_timer don't have an eoi register but instead expect a
one to be written to the int_status register at eoi time.

Signed-off-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
 drivers/clocksource/dw_apb_timer.c |   10 +++++++++-
 include/linux/dw_apb_timer.h       |    5 +++++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
index 5f80a30..23cd7c6 100644
--- a/drivers/clocksource/dw_apb_timer.c
+++ b/drivers/clocksource/dw_apb_timer.c
@@ -104,6 +104,11 @@ static void apbt_eoi(struct dw_apb_timer *timer)
 	apbt_readl(timer, timer->reg_eoi);
 }
 
+static void apbt_eoi_int_status(struct dw_apb_timer *timer)
+{
+	apbt_writel(timer, 1, timer->reg_int_status);
+}
+
 static irqreturn_t dw_apb_clockevent_irq(int irq, void *data)
 {
 	struct clock_event_device *evt = data;
@@ -286,7 +291,10 @@ dw_apb_clockevent_init(int cpu, const char *name, unsigned rating,
 					  IRQF_NOBALANCING |
 					  IRQF_DISABLED;
 
-	dw_ced->eoi = apbt_eoi;
+	if (quirks & APBTMR_QUIRK_NO_EOI)
+		dw_ced->eoi = apbt_eoi_int_status;
+	else
+		dw_ced->eoi = apbt_eoi;
 	err = setup_irq(irq, &dw_ced->irqaction);
 	if (err) {
 		pr_err("failed to request timer irq\n");
diff --git a/include/linux/dw_apb_timer.h b/include/linux/dw_apb_timer.h
index 80f6686..fbe4c6b 100644
--- a/include/linux/dw_apb_timer.h
+++ b/include/linux/dw_apb_timer.h
@@ -25,6 +25,11 @@
  */
 #define APBTMR_QUIRK_64BIT_COUNTER	BIT(0)
 
+/* The IP does not provide a end-of-interrupt register to clear pending
+ * interrupts, but requires to write a 1 to the interrupt-status register.
+ */
+#define APBTMR_QUIRK_NO_EOI		BIT(1)
+
 struct dw_apb_timer {
 	void __iomem				*base;
 	unsigned long				freq;
-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 18:54:35 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 6 Jul 2013 00:54:35 +0200
Subject: [PATCH 6/9] clocksource: dw_apb_timer: quirk for inverted int mask
In-Reply-To: <201307060051.09716.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
Message-ID: <201307060054.35996.heiko@sntech.de>

Some timer variants use an inverted setting to mask the timer interrupt.
Therefore add a quirk to handle these variants.

Signed-off-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
 drivers/clocksource/dw_apb_timer.c |   23 ++++++++++++++++++-----
 include/linux/dw_apb_timer.h       |    6 ++++++
 2 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
index 23cd7c6..7705d13 100644
--- a/drivers/clocksource/dw_apb_timer.c
+++ b/drivers/clocksource/dw_apb_timer.c
@@ -84,7 +84,10 @@ static void apbt_disable_int(struct dw_apb_timer *timer)
 {
 	unsigned long ctrl = apbt_readl(timer, timer->reg_control);
 
-	ctrl |= APBTMR_CONTROL_INT;
+	if (timer->quirks & APBTMR_QUIRK_INVERSE_INTMASK)
+		ctrl &= ~APBTMR_CONTROL_INT;
+	else
+		ctrl |= APBTMR_CONTROL_INT;
 	apbt_writel(timer, ctrl, timer->reg_control);
 }
 
@@ -134,7 +137,10 @@ static void apbt_enable_int(struct dw_apb_clock_event_device *dw_ced)
 	/* clear pending intr */
 	if (dw_ced->eoi)
 		dw_ced->eoi(timer);
-	ctrl &= ~APBTMR_CONTROL_INT;
+	if (timer->quirks & APBTMR_QUIRK_INVERSE_INTMASK)
+		ctrl |= APBTMR_CONTROL_INT;
+	else
+		ctrl &= ~APBTMR_CONTROL_INT;
 	apbt_writel(timer, ctrl, timer->reg_control);
 }
 
@@ -195,7 +201,10 @@ static void apbt_set_mode(enum clock_event_mode mode,
 		if (timer->quirks & APBTMR_QUIRK_64BIT_COUNTER)
 			apbt_writel(timer, 0, timer->reg_load_count + 0x4);
 
-		ctrl &= ~APBTMR_CONTROL_INT;
+		if (timer->quirks & APBTMR_QUIRK_INVERSE_INTMASK)
+			ctrl |= APBTMR_CONTROL_INT;
+		else
+			ctrl &= ~APBTMR_CONTROL_INT;
 		ctrl |= APBTMR_CONTROL_ENABLE;
 		apbt_writel(timer, ctrl, timer->reg_control);
 		break;
@@ -363,9 +372,13 @@ void dw_apb_clocksource_start(struct dw_apb_clocksource *dw_cs)
 	if (timer->quirks & APBTMR_QUIRK_64BIT_COUNTER)
 		apbt_writel(timer, 0, timer->reg_load_count + 0x4);
 
-	/* enable, mask interrupt */
+	/* set periodic, mask interrupt, enable timer */
 	ctrl &= ~APBTMR_CONTROL_MODE_PERIODIC;
-	ctrl |= (APBTMR_CONTROL_ENABLE | APBTMR_CONTROL_INT);
+	if (timer->quirks & APBTMR_QUIRK_INVERSE_INTMASK)
+		ctrl &= ~APBTMR_CONTROL_INT;
+	else
+		ctrl |= APBTMR_CONTROL_INT;
+	ctrl |= APBTMR_CONTROL_ENABLE;
 	apbt_writel(timer, ctrl, timer->reg_control);
 	/* read it once to get cached counter value initialized */
 	dw_apb_clocksource_read(dw_cs);
diff --git a/include/linux/dw_apb_timer.h b/include/linux/dw_apb_timer.h
index fbe4c6b..7d36d91 100644
--- a/include/linux/dw_apb_timer.h
+++ b/include/linux/dw_apb_timer.h
@@ -30,6 +30,12 @@
  */
 #define APBTMR_QUIRK_NO_EOI		BIT(1)
 
+/* The IP uses an inverted interrupt-mask bit.
+ * Instead of activating interrupts clearing a maks bit, it needs an enable
+ * bit to be set 1.
+ */
+#define APBTMR_QUIRK_INVERSE_INTMASK	BIT(2)
+
 struct dw_apb_timer {
 	void __iomem				*base;
 	unsigned long				freq;
-- 
1.7.10.4



From arnd at arndb.de  Fri Jul  5 18:54:22 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 6 Jul 2013 00:54:22 +0200
Subject: [PATCH v6 00/21] MBus DT binding: PCIe strikes back
In-Reply-To: <20130705220820.GA11787@obsidianresearch.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130705220820.GA11787@obsidianresearch.com>
Message-ID: <201307060054.23086.arnd@arndb.de>

On Saturday 06 July 2013, Jason Gunthorpe wrote:
> This is a good try, but this coding doesn't work...
> 
> Recall the long discussion that came up during the original
> development of this binding. The OF spec says this:
> 
>  In particular, the phys.hi fields of the child address spaces in the
>  "ranges" property for PCI does not contain
>  the same information as "reg" property entries within PCI nodes. The
>  only information that is present in
>  "ranges" phys.hi entries are the non-relocatable, prefetchable and
>  the PCI address space bits for which the en-
>  try applies. I.e., only the n, p and ss bits are present; the
>  bbbbbbbb, ddddd, fff and rrrrrrrr fields are 0.
> 
>  When an address is to be mapped through a PCI bus bridge node, the
>  phys.hi value of the address to be mapped
>  and the child field of a "ranges" entry should be masked so that only
>  the ss bits are compared. I.e., the only
>  portion of phys.hi that should participate in the range determination
>  is the address space indicator (the ss bits).
> 
> Which forbids (0x82000800 .. ..) from being in a ranges

ah, and I thought Ezequiel was being more clever than what I had suggested

> I don't have an idea how to encode MBUS_ID in the PCI-E ranges :(
> 
> Arnd? Didn't you have some idea?

The way I described it during the last review, I suggested using
the middle cell of the PCI address here. Since the PCIe port
is 32 bit only, it's otherwise unused. We can do one of two things
here:

a) put the port number in the second cell

   0x82000000 1 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
   0x82000000 2 0xe0000000 MBUS_ID(0x04, 0xe9) 0xe0000000 0 0x08000000 /* Port 1.0 MEM */

b) translate the entire MBUS space here

   0x82000000 0 0 0 0 0x1000000 0 /* all MBUS_IDs */

In both cases, the individual ports would have another non-empty
ranges property

a) 
   0x82000000 1 0xe0000000 0x82000000 0 0xe0000000 0x08000000 /* ranges for port 0.0 */

b)
   0x82000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0x82000000 0 0xe0000000 0 0x08000000

I left out the change I suggested in my other reply to not describe
the aperture in this node but translate the entire 4GB space.

	Arnd


From heiko at sntech.de  Fri Jul  5 18:55:31 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 6 Jul 2013 00:55:31 +0200
Subject: [PATCH 7/9] clocksource: dw_apb_timer: quirk for inverted timer mode
 setting
In-Reply-To: <201307060051.09716.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
Message-ID: <201307060055.31882.heiko@sntech.de>

From: Ulrich Prinz <ulrich.prinz at googlemail.com>

Some variants of SOCs using dw_apb_timer have inverted logic for the
bit that sets one-shot / periodic mode or free running timer. This
commit adds the new APBTMR_QUIRK_INVERSE_PERIODIC.

Signed-off-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
 drivers/clocksource/dw_apb_timer.c |   11 +++++++++--
 include/linux/dw_apb_timer.h       |    6 ++++++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/dw_apb_timer.c 
b/drivers/clocksource/dw_apb_timer.c
index 7705d13..a2e8306 100644
--- a/drivers/clocksource/dw_apb_timer.c
+++ b/drivers/clocksource/dw_apb_timer.c
@@ -159,7 +159,11 @@ static void apbt_set_mode(enum clock_event_mode mode,
 	case CLOCK_EVT_MODE_PERIODIC:
 		period = DIV_ROUND_UP(timer->freq, HZ);
 		ctrl = apbt_readl(timer, timer->reg_control);
-		ctrl |= APBTMR_CONTROL_MODE_PERIODIC;
+
+		if (timer->quirks & APBTMR_QUIRK_INVERSE_PERIODIC)
+			ctrl &= ~APBTMR_CONTROL_MODE_PERIODIC;
+		else
+			ctrl |= APBTMR_CONTROL_MODE_PERIODIC;
 		apbt_writel(timer, ctrl, timer->reg_control);
 		/*
 		 * DW APB p. 46, have to disable timer before load counter,
@@ -186,7 +190,10 @@ static void apbt_set_mode(enum clock_event_mode mode,
 		 * the next event, therefore emulate the one-shot mode.
 		 */
 		ctrl &= ~APBTMR_CONTROL_ENABLE;
-		ctrl &= ~APBTMR_CONTROL_MODE_PERIODIC;
+		if (timer->quirks & APBTMR_QUIRK_INVERSE_PERIODIC)
+			ctrl |= APBTMR_CONTROL_MODE_PERIODIC;
+		else
+			ctrl &= ~APBTMR_CONTROL_MODE_PERIODIC;
 
 		apbt_writel(timer, ctrl, timer->reg_control);
 		/* write again to set free running mode */
diff --git a/include/linux/dw_apb_timer.h b/include/linux/dw_apb_timer.h
index 7d36d91..5d9210cc 100644
--- a/include/linux/dw_apb_timer.h
+++ b/include/linux/dw_apb_timer.h
@@ -36,6 +36,12 @@
  */
 #define APBTMR_QUIRK_INVERSE_INTMASK	BIT(2)
 
+/* The IP uses inverted logic for the bit setting periodic mode.
+ * Periodic means it times out after the period is over and is set to
+ * 1 in the original IP. This IP uses 1 for free running mode.
+ */
+#define APBTMR_QUIRK_INVERSE_PERIODIC	BIT(3)
+
 struct dw_apb_timer {
 	void __iomem				*base;
 	unsigned long				freq;
-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 18:56:03 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 6 Jul 2013 00:56:03 +0200
Subject: [PATCH 8/9] clocksource: dw_apb_timer_of: add quirk handling
In-Reply-To: <201307060051.09716.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
Message-ID: <201307060056.03543.heiko@sntech.de>

timer_get_base_and_rate now also can extract informations about present
hardware-quirks from the devicetree node and transmit it to the
clocksource / clockevent init function.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 drivers/clocksource/dw_apb_timer_of.c |   21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
index b5412af..4bcc1c1 100644
--- a/drivers/clocksource/dw_apb_timer_of.c
+++ b/drivers/clocksource/dw_apb_timer_of.c
@@ -26,7 +26,7 @@
 #include <asm/sched_clock.h>
 
 static void timer_get_base_and_rate(struct device_node *np,
-				    void __iomem **base, u32 *rate)
+				    void __iomem **base, u32 *rate, int *quirks)
 {
 	struct clk *timer_clk;
 	struct clk *pclk;
@@ -36,6 +36,8 @@ static void timer_get_base_and_rate(struct device_node *np,
 	if (!*base)
 		panic("Unable to map regs for %s", np->name);
 
+	*quirks = 0;
+
 	/*
 	 * Not all implementations use a periphal clock, so don't panic
 	 * if it's not present
@@ -66,15 +68,16 @@ static void add_clockevent(struct device_node *event_timer)
 	void __iomem *iobase;
 	struct dw_apb_clock_event_device *ced;
 	u32 irq, rate;
+	int quirks;
 
 	irq = irq_of_parse_and_map(event_timer, 0);
 	if (irq == NO_IRQ)
 		panic("No IRQ for clock event timer");
 
-	timer_get_base_and_rate(event_timer, &iobase, &rate);
+	timer_get_base_and_rate(event_timer, &iobase, &rate, &quirks);
 
 	ced = dw_apb_clockevent_init(0, event_timer->name, 300, iobase, irq,
-				     rate, 0);
+				     rate, quirks);
 	if (!ced)
 		panic("Unable to initialise clockevent device");
 
@@ -89,10 +92,12 @@ static void add_clocksource(struct device_node *source_timer)
 	void __iomem *iobase;
 	struct dw_apb_clocksource *cs;
 	u32 rate;
+	int quirks;
 
-	timer_get_base_and_rate(source_timer, &iobase, &rate);
+	timer_get_base_and_rate(source_timer, &iobase, &rate, &quirks);
 
-	cs = dw_apb_clocksource_init(300, source_timer->name, iobase, rate, 0);
+	cs = dw_apb_clocksource_init(300, source_timer->name, iobase, rate,
+				     quirks);
 	if (!cs)
 		panic("Unable to initialise clocksource device");
 
@@ -106,6 +111,9 @@ static void add_clocksource(struct device_node *source_timer)
 	 */
 	sched_io_base = iobase + 0x04;
 	sched_rate = rate;
+
+	if (quirks & APBTMR_QUIRK_64BIT_COUNTER)
+		sched_io_base += 0x04;
 }
 
 static u32 read_sched_clock(void)
@@ -122,11 +130,12 @@ static const struct of_device_id sptimer_ids[] __initconst = {
 static void init_sched_clock(void)
 {
 	struct device_node *sched_timer;
+	int quirks;
 
 	sched_timer = of_find_matching_node(NULL, sptimer_ids);
 	if (sched_timer) {
 		timer_get_base_and_rate(sched_timer, &sched_io_base,
-					&sched_rate);
+					&sched_rate, &quirks);
 		of_node_put(sched_timer);
 	}
 
-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 18:56:29 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 6 Jul 2013 00:56:29 +0200
Subject: [PATCH 9/9] clocksource: dw_apb_timer: special variant for rockchip
 rk3188 timers
In-Reply-To: <201307060051.09716.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
Message-ID: <201307060056.29370.heiko@sntech.de>

The rk3188 uses a variant of the timer containing two registers for load_count
and current_values.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 .../bindings/arm/rockchip/rk3188-timer.txt         |   20 ++++++++++++++++++++
 drivers/clocksource/dw_apb_timer_of.c              |    6 ++++++
 2 files changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/rk3188-timer.txt

diff --git a/Documentation/devicetree/bindings/arm/rockchip/rk3188-timer.txt b/Documentation/devicetree/bindings/arm/rockchip/rk3188-timer.txt
new file mode 100644
index 0000000..ccbb389
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/rk3188-timer.txt
@@ -0,0 +1,20 @@
+Rockchip rk3188 timer:
+----------------------
+
+The rk3188 SoCs contain a slightly modified dw-apb-timer.
+
+Required node properties:
+- compatible value : = "rockchip,rk3188-dw-apb-timer-osc";
+
+For the other properties see the generic documentation in
+../../rtc/dw-apb.txt
+
+Example:
+
+	timer3: timer at ffe00000 {
+			compatible = "rockchip,rk3188-dw-apb-timer-osc";
+			interrupts = <0 170 4>;
+			reg = <0xffe00000 0x1000>;
+			clocks = <&timer_clk>, <&timer_pclk>;
+			clock-names = "timer", "pclk";
+		};
diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
index 4bcc1c1..7824796 100644
--- a/drivers/clocksource/dw_apb_timer_of.c
+++ b/drivers/clocksource/dw_apb_timer_of.c
@@ -38,6 +38,11 @@ static void timer_get_base_and_rate(struct device_node *np,
 
 	*quirks = 0;
 
+	if (of_device_is_compatible(np, "rockchip,rk3188-dw-apb-timer-osc"))
+		*quirks |= APBTMR_QUIRK_64BIT_COUNTER | APBTMR_QUIRK_NO_EOI |
+			   APBTMR_QUIRK_INVERSE_INTMASK |
+			   APBTMR_QUIRK_INVERSE_PERIODIC;
+
 	/*
 	 * Not all implementations use a periphal clock, so don't panic
 	 * if it's not present
@@ -165,3 +170,4 @@ static void __init dw_apb_timer_init(struct device_node *timer)
 }
 CLOCKSOURCE_OF_DECLARE(pc3x2_timer, "picochip,pc3x2-timer", dw_apb_timer_init);
 CLOCKSOURCE_OF_DECLARE(apb_timer, "snps,dw-apb-timer-osc", dw_apb_timer_init);
+CLOCKSOURCE_OF_DECLARE(rk3188_timer, "rockchip,rk3188-dw-apb-timer-osc", dw_apb_timer_init);
-- 
1.7.10.4



From shuah.kh at samsung.com  Fri Jul  5 18:57:35 2013
From: shuah.kh at samsung.com (Shuah Khan)
Date: Fri,  5 Jul 2013 16:57:35 -0600
Subject: [PATCH] arm: Convert sa1111 platform and bus legacy pm_ops to
 dev_pm_ops
Message-ID: <1373065055-13887-1-git-send-email-shuah.kh@samsung.com>

Convert arch/arm/common/sa1111 platform and bus legacy pm_ops to dev_pm_ops.
This change also updates the use of COMFIG_PM to CONFIG_PM_SLEEP as this
platform and bus code implements PM_SLEEP ops and not the PM_RUNTIME ops.
Compile tested.

Signed-off-by: Shuah Khan <shuah.kh at samsung.com>
---
 arch/arm/common/sa1111.c |   39 ++++++++++++++++++++++-----------------
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/arch/arm/common/sa1111.c b/arch/arm/common/sa1111.c
index e57d7e5..95594f0 100644
--- a/arch/arm/common/sa1111.c
+++ b/arch/arm/common/sa1111.c
@@ -107,7 +107,7 @@ struct sa1111 {
 	spinlock_t	lock;
 	void __iomem	*base;
 	struct sa1111_platform_data *pdata;
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
 	void		*saved_state;
 #endif
 };
@@ -870,11 +870,11 @@ struct sa1111_save_data {
 	unsigned int	wakeen1;
 };
 
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
 
-static int sa1111_suspend(struct platform_device *dev, pm_message_t state)
+static int sa1111_suspend(struct device *dev)
 {
-	struct sa1111 *sachip = platform_get_drvdata(dev);
+	struct sa1111 *sachip = platform_get_drvdata(to_platform_device(dev));
 	struct sa1111_save_data *save;
 	unsigned long flags;
 	unsigned int val;
@@ -937,9 +937,10 @@ static int sa1111_suspend(struct platform_device *dev, pm_message_t state)
  *	restored by their respective drivers, and must be called
  *	via LDM after this function.
  */
-static int sa1111_resume(struct platform_device *dev)
+static int sa1111_resume(struct device *dev)
 {
-	struct sa1111 *sachip = platform_get_drvdata(dev);
+	struct platform_device *pdev = to_platform_device(dev);
+	struct sa1111 *sachip = platform_get_drvdata(pdev);
 	struct sa1111_save_data *save;
 	unsigned long flags, id;
 	void __iomem *base;
@@ -955,7 +956,7 @@ static int sa1111_resume(struct platform_device *dev)
 	id = sa1111_readl(sachip->base + SA1111_SKID);
 	if ((id & SKID_ID_MASK) != SKID_SA1111_ID) {
 		__sa1111_remove(sachip);
-		platform_set_drvdata(dev, NULL);
+		platform_set_drvdata(pdev, NULL);
 		kfree(save);
 		return 0;
 	}
@@ -1005,9 +1006,7 @@ static int sa1111_resume(struct platform_device *dev)
 	return 0;
 }
 
-#else
-#define sa1111_suspend NULL
-#define sa1111_resume  NULL
+static SIMPLE_DEV_PM_OPS(sa1111_dev_pm_ops, sa1111_suspend, sa1111_resume);
 #endif
 
 static int sa1111_probe(struct platform_device *pdev)
@@ -1030,7 +1029,7 @@ static int sa1111_remove(struct platform_device *pdev)
 	struct sa1111 *sachip = platform_get_drvdata(pdev);
 
 	if (sachip) {
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
 		kfree(sachip->saved_state);
 		sachip->saved_state = NULL;
 #endif
@@ -1053,11 +1052,12 @@ static int sa1111_remove(struct platform_device *pdev)
 static struct platform_driver sa1111_device_driver = {
 	.probe		= sa1111_probe,
 	.remove		= sa1111_remove,
-	.suspend	= sa1111_suspend,
-	.resume		= sa1111_resume,
 	.driver		= {
 		.name	= "sa1111",
 		.owner	= THIS_MODULE,
+#ifdef CONFIG_PM_SLEEP
+		.pm = &sa1111_dev_pm_ops,
+#endif
 	},
 };
 
@@ -1297,14 +1297,15 @@ static int sa1111_match(struct device *_dev, struct device_driver *_drv)
 	return dev->devid & drv->devid;
 }
 
-static int sa1111_bus_suspend(struct device *dev, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int sa1111_bus_suspend(struct device *dev)
 {
 	struct sa1111_dev *sadev = SA1111_DEV(dev);
 	struct sa1111_driver *drv = SA1111_DRV(dev->driver);
 	int ret = 0;
 
 	if (drv && drv->suspend)
-		ret = drv->suspend(sadev, state);
+		ret = drv->suspend(sadev, PMSG_SUSPEND);
 	return ret;
 }
 
@@ -1318,6 +1319,9 @@ static int sa1111_bus_resume(struct device *dev)
 		ret = drv->resume(sadev);
 	return ret;
 }
+static SIMPLE_DEV_PM_OPS(sa1111_bus_dev_pm_ops, sa1111_bus_suspend,
+			 sa1111_bus_resume);
+#endif
 
 static void sa1111_bus_shutdown(struct device *dev)
 {
@@ -1354,8 +1358,9 @@ struct bus_type sa1111_bus_type = {
 	.match		= sa1111_match,
 	.probe		= sa1111_bus_probe,
 	.remove		= sa1111_bus_remove,
-	.suspend	= sa1111_bus_suspend,
-	.resume		= sa1111_bus_resume,
+#ifdef CONFIG_PM_SLEEP
+	.pm		= &sa1111_bus_dev_pm_ops,
+#endif
 	.shutdown	= sa1111_bus_shutdown,
 };
 EXPORT_SYMBOL(sa1111_bus_type);
-- 
1.7.10.4



From heiko at sntech.de  Fri Jul  5 18:58:34 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 6 Jul 2013 00:58:34 +0200
Subject: [PATCH 6/9] clocksource: dw_apb_timer: quirk for inverted int mask
In-Reply-To: <201307060054.35996.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
 <201307060054.35996.heiko@sntech.de>
Message-ID: <201307060058.34736.heiko@sntech.de>

this patch should have had a

From: Ulrich Prinz <ulrich.prinz at googlemail.com>

sorry for the mistake

Am Samstag, 6. Juli 2013, 00:54:35 schrieb Heiko St?bner:
> Some timer variants use an inverted setting to mask the timer interrupt.
> Therefore add a quirk to handle these variants.
> 
> Signed-off-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
> ---
>  drivers/clocksource/dw_apb_timer.c |   23 ++++++++++++++++++-----
>  include/linux/dw_apb_timer.h       |    6 ++++++
>  2 files changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/clocksource/dw_apb_timer.c
> b/drivers/clocksource/dw_apb_timer.c index 23cd7c6..7705d13 100644
> --- a/drivers/clocksource/dw_apb_timer.c
> +++ b/drivers/clocksource/dw_apb_timer.c
> @@ -84,7 +84,10 @@ static void apbt_disable_int(struct dw_apb_timer *timer)
>  {
>  	unsigned long ctrl = apbt_readl(timer, timer->reg_control);
> 
> -	ctrl |= APBTMR_CONTROL_INT;
> +	if (timer->quirks & APBTMR_QUIRK_INVERSE_INTMASK)
> +		ctrl &= ~APBTMR_CONTROL_INT;
> +	else
> +		ctrl |= APBTMR_CONTROL_INT;
>  	apbt_writel(timer, ctrl, timer->reg_control);
>  }
> 
> @@ -134,7 +137,10 @@ static void apbt_enable_int(struct
> dw_apb_clock_event_device *dw_ced) /* clear pending intr */
>  	if (dw_ced->eoi)
>  		dw_ced->eoi(timer);
> -	ctrl &= ~APBTMR_CONTROL_INT;
> +	if (timer->quirks & APBTMR_QUIRK_INVERSE_INTMASK)
> +		ctrl |= APBTMR_CONTROL_INT;
> +	else
> +		ctrl &= ~APBTMR_CONTROL_INT;
>  	apbt_writel(timer, ctrl, timer->reg_control);
>  }
> 
> @@ -195,7 +201,10 @@ static void apbt_set_mode(enum clock_event_mode mode,
>  		if (timer->quirks & APBTMR_QUIRK_64BIT_COUNTER)
>  			apbt_writel(timer, 0, timer->reg_load_count + 0x4);
> 
> -		ctrl &= ~APBTMR_CONTROL_INT;
> +		if (timer->quirks & APBTMR_QUIRK_INVERSE_INTMASK)
> +			ctrl |= APBTMR_CONTROL_INT;
> +		else
> +			ctrl &= ~APBTMR_CONTROL_INT;
>  		ctrl |= APBTMR_CONTROL_ENABLE;
>  		apbt_writel(timer, ctrl, timer->reg_control);
>  		break;
> @@ -363,9 +372,13 @@ void dw_apb_clocksource_start(struct
> dw_apb_clocksource *dw_cs) if (timer->quirks & APBTMR_QUIRK_64BIT_COUNTER)
>  		apbt_writel(timer, 0, timer->reg_load_count + 0x4);
> 
> -	/* enable, mask interrupt */
> +	/* set periodic, mask interrupt, enable timer */
>  	ctrl &= ~APBTMR_CONTROL_MODE_PERIODIC;
> -	ctrl |= (APBTMR_CONTROL_ENABLE | APBTMR_CONTROL_INT);
> +	if (timer->quirks & APBTMR_QUIRK_INVERSE_INTMASK)
> +		ctrl &= ~APBTMR_CONTROL_INT;
> +	else
> +		ctrl |= APBTMR_CONTROL_INT;
> +	ctrl |= APBTMR_CONTROL_ENABLE;
>  	apbt_writel(timer, ctrl, timer->reg_control);
>  	/* read it once to get cached counter value initialized */
>  	dw_apb_clocksource_read(dw_cs);
> diff --git a/include/linux/dw_apb_timer.h b/include/linux/dw_apb_timer.h
> index fbe4c6b..7d36d91 100644
> --- a/include/linux/dw_apb_timer.h
> +++ b/include/linux/dw_apb_timer.h
> @@ -30,6 +30,12 @@
>   */
>  #define APBTMR_QUIRK_NO_EOI		BIT(1)
> 
> +/* The IP uses an inverted interrupt-mask bit.
> + * Instead of activating interrupts clearing a maks bit, it needs an
> enable + * bit to be set 1.
> + */
> +#define APBTMR_QUIRK_INVERSE_INTMASK	BIT(2)
> +
>  struct dw_apb_timer {
>  	void __iomem				*base;
>  	unsigned long				freq;



From heiko at sntech.de  Fri Jul  5 18:58:51 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 6 Jul 2013 00:58:51 +0200
Subject: [PATCH 5/9] clocksource: dw_apb_timer: quirk for variants without
 EOI register
In-Reply-To: <201307060054.07784.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
 <201307060054.07784.heiko@sntech.de>
Message-ID: <201307060058.52177.heiko@sntech.de>

this patch should have had a

From: Ulrich Prinz <ulrich.prinz at googlemail.com>

sorry for the mistake

Am Samstag, 6. Juli 2013, 00:54:07 schrieb Heiko St?bner:
> Some variants of the dw_apb_timer don't have an eoi register but instead
> expect a one to be written to the int_status register at eoi time.
> 
> Signed-off-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
> ---
>  drivers/clocksource/dw_apb_timer.c |   10 +++++++++-
>  include/linux/dw_apb_timer.h       |    5 +++++
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/dw_apb_timer.c
> b/drivers/clocksource/dw_apb_timer.c index 5f80a30..23cd7c6 100644
> --- a/drivers/clocksource/dw_apb_timer.c
> +++ b/drivers/clocksource/dw_apb_timer.c
> @@ -104,6 +104,11 @@ static void apbt_eoi(struct dw_apb_timer *timer)
>  	apbt_readl(timer, timer->reg_eoi);
>  }
> 
> +static void apbt_eoi_int_status(struct dw_apb_timer *timer)
> +{
> +	apbt_writel(timer, 1, timer->reg_int_status);
> +}
> +
>  static irqreturn_t dw_apb_clockevent_irq(int irq, void *data)
>  {
>  	struct clock_event_device *evt = data;
> @@ -286,7 +291,10 @@ dw_apb_clockevent_init(int cpu, const char *name,
> unsigned rating, IRQF_NOBALANCING |
>  					  IRQF_DISABLED;
> 
> -	dw_ced->eoi = apbt_eoi;
> +	if (quirks & APBTMR_QUIRK_NO_EOI)
> +		dw_ced->eoi = apbt_eoi_int_status;
> +	else
> +		dw_ced->eoi = apbt_eoi;
>  	err = setup_irq(irq, &dw_ced->irqaction);
>  	if (err) {
>  		pr_err("failed to request timer irq\n");
> diff --git a/include/linux/dw_apb_timer.h b/include/linux/dw_apb_timer.h
> index 80f6686..fbe4c6b 100644
> --- a/include/linux/dw_apb_timer.h
> +++ b/include/linux/dw_apb_timer.h
> @@ -25,6 +25,11 @@
>   */
>  #define APBTMR_QUIRK_64BIT_COUNTER	BIT(0)
> 
> +/* The IP does not provide a end-of-interrupt register to clear pending
> + * interrupts, but requires to write a 1 to the interrupt-status register.
> + */
> +#define APBTMR_QUIRK_NO_EOI		BIT(1)
> +
>  struct dw_apb_timer {
>  	void __iomem				*base;
>  	unsigned long				freq;



From heiko at sntech.de  Fri Jul  5 18:59:05 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Sat, 6 Jul 2013 00:59:05 +0200
Subject: [PATCH 4/9] clocksource: dw_apb_timer: use the eoi callback to
 clear pending interrupts
In-Reply-To: <201307060053.36885.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
 <201307060053.36885.heiko@sntech.de>
Message-ID: <201307060059.06053.heiko@sntech.de>

this patch should have had a

From: Ulrich Prinz <ulrich.prinz at googlemail.com>

sorry for the mistake

Am Samstag, 6. Juli 2013, 00:53:36 schrieb Heiko St?bner:
> Some timer variants have different mechanisms to clear a pending timer
> interrupt. Therefore don't hardcode the reading of the eoi register to
> clear them, but instead use the already existing eoi callback for this.
> 
> Signed-off-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
> ---
>  drivers/clocksource/dw_apb_timer.c |   11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clocksource/dw_apb_timer.c
> b/drivers/clocksource/dw_apb_timer.c index bd45351..5f80a30 100644
> --- a/drivers/clocksource/dw_apb_timer.c
> +++ b/drivers/clocksource/dw_apb_timer.c
> @@ -121,11 +121,14 @@ static irqreturn_t dw_apb_clockevent_irq(int irq,
> void *data) return IRQ_HANDLED;
>  }
> 
> -static void apbt_enable_int(struct dw_apb_timer *timer)
> +static void apbt_enable_int(struct dw_apb_clock_event_device *dw_ced)
>  {
> +	struct dw_apb_timer *timer = &dw_ced->timer;
>  	unsigned long ctrl = apbt_readl(timer, timer->reg_control);
> +
>  	/* clear pending intr */
> -	apbt_readl(timer, timer->reg_eoi);
> +	if (dw_ced->eoi)
> +		dw_ced->eoi(timer);
>  	ctrl &= ~APBTMR_CONTROL_INT;
>  	apbt_writel(timer, ctrl, timer->reg_control);
>  }
> @@ -200,7 +203,7 @@ static void apbt_set_mode(enum clock_event_mode mode,
>  		break;
> 
>  	case CLOCK_EVT_MODE_RESUME:
> -		apbt_enable_int(timer);
> +		apbt_enable_int(dw_ced);
>  		break;
>  	}
>  }
> @@ -325,7 +328,7 @@ void dw_apb_clockevent_register(struct
> dw_apb_clock_event_device *dw_ced)
> 
>  	apbt_writel(timer, 0, timer->reg_control);
>  	clockevents_register_device(&dw_ced->ced);
> -	apbt_enable_int(timer);
> +	apbt_enable_int(dw_ced);
>  }
> 
>  /**



From tomasz.figa at gmail.com  Fri Jul  5 19:04:23 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Jul 2013 01:04:23 +0200
Subject: [PATCH V4 4/4] video: exynos_dp: Use the generic PHY driver
In-Reply-To: <000d01ce7700$222a35a0$667ea0e0$@samsung.com>
References: <000d01ce7700$222a35a0$667ea0e0$@samsung.com>
Message-ID: <1441230.DzaqAQ9HHT@flatron>

Hi Jingoo,

On Tuesday 02 of July 2013 17:42:49 Jingoo Han wrote:
> Use the generic PHY API instead of the platform callback to control
> the DP PHY.
> 
> Signed-off-by: Jingoo Han <jg1.han at samsung.com>
> ---
>  .../devicetree/bindings/video/exynos_dp.txt        |   23
> +++++--------------- drivers/video/exynos/exynos_dp_core.c             
> |   16 ++++++++++---- drivers/video/exynos/exynos_dp_core.h            
>  |    2 ++
>  3 files changed, 20 insertions(+), 21 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
> b/Documentation/devicetree/bindings/video/exynos_dp.txt index
> 84f10c1..022f4b6 100644
> --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> @@ -1,17 +1,6 @@
>  The Exynos display port interface should be configured based on
>  the type of panel connected to it.
> 
> -We use two nodes:
> -	-dp-controller node
> -	-dptx-phy node(defined inside dp-controller node)
> -
> -For the DP-PHY initialization, we use the dptx-phy node.
> -Required properties for dptx-phy:
> -	-reg:
> -		Base address of DP PHY register.
> -	-samsung,enable-mask:
> -		The bit-mask used to enable/disable DP PHY.
> -

I wonder if this part shouldn't stay here, just marked as deprecated, 
because compatibility with old dtbs must be preserved (and rest of the 
patch looks like it is).

>  For the Panel initialization, we read data from dp-controller node.
>  Required properties for dp-controller:
>  	-compatible:
> @@ -25,6 +14,10 @@ Required properties for dp-controller:
>  		from common clock binding: handle to dp clock.
>  	-clock-names:
>  		from common clock binding: Shall be "dp".
> +	-phys:
> +		from general PHY binding: the phandle for the PHY device.
> +	-phy-names:
> +		from general PHY binding: Should be "dp".
>  	-interrupt-parent:
>  		phandle to Interrupt combiner node.
>  	-samsung,color-space:
> @@ -67,12 +60,8 @@ SOC specific portion:
>  		interrupt-parent = <&combiner>;
>  		clocks = <&clock 342>;
>  		clock-names = "dp";
> -
> -		dptx-phy {
> -			reg = <0x10040720>;
> -			samsung,enable-mask = <1>;
> -		};
> -
> +		phys = <&dp_phy>;
> +		phy-names = "dp";
>  	};
> 
>  Board Specific portion:
> diff --git a/drivers/video/exynos/exynos_dp_core.c
> b/drivers/video/exynos/exynos_dp_core.c index 05fed7d..5e1a715 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -19,6 +19,7 @@
>  #include <linux/interrupt.h>
>  #include <linux/delay.h>
>  #include <linux/of.h>
> +#include <linux/phy/phy.h>
> 
>  #include "exynos_dp_core.h"
> 
> @@ -960,8 +961,11 @@ static int exynos_dp_dt_parse_phydata(struct
> exynos_dp_device *dp)
> 
>  	dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
>  	if (!dp_phy_node) {
> -		dev_err(dp->dev, "could not find dptx-phy node\n");
> -		return -ENODEV;
> +		dp->phy = devm_phy_get(dp->dev, "dp");
> +		if (IS_ERR(dp->phy))
> +			return PTR_ERR(dp->phy);
> +		else
> +			return 0;
>  	}
> 
>  	if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
> @@ -992,7 +996,9 @@ err:
> 
>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>  {
> -	if (dp->phy_addr) {
> +	if (dp->phy) {
> +		phy_power_on(dp->phy);
> +	} else if (dp->phy_addr) {
>  		u32 reg;
> 
>  		reg = __raw_readl(dp->phy_addr);
> @@ -1003,7 +1009,9 @@ static void exynos_dp_phy_init(struct
> exynos_dp_device *dp)
> 
>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>  {
> -	if (dp->phy_addr) {
> +	if (dp->phy) {
> +		phy_power_off(dp->phy);
> +	} else if (dp->phy_addr) {
>  		u32 reg;
> 
>  		reg = __raw_readl(dp->phy_addr);
> diff --git a/drivers/video/exynos/exynos_dp_core.h
> b/drivers/video/exynos/exynos_dp_core.h index 56cfec8..87804b6 100644
> --- a/drivers/video/exynos/exynos_dp_core.h
> +++ b/drivers/video/exynos/exynos_dp_core.h
> @@ -151,6 +151,8 @@ struct exynos_dp_device {
>  	struct video_info	*video_info;
>  	struct link_train	link_train;
>  	struct work_struct	hotplug_work;
> +

nit: unnecessary blank line

> +	struct phy		*phy;
>  };
> 
>  /* exynos_dp_reg.c */

Otherwise looks good.

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From tomasz.figa at gmail.com  Fri Jul  5 19:11:02 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Fri, 05 Jul 2013 16:11:02 -0700 (PDT)
Subject: [PATCH V4 3/4] video: exynos_dp: remove non-DT support for Exynos
 Display Port
In-Reply-To: <000c01ce76ff$fffa39d0$ffeead70$@samsung.com>
References: <000c01ce76ff$fffa39d0$ffeead70$@samsung.com>
Message-ID: <2149220.dCp7esoXHa@flatron>

Hi Jingoo,

On Tuesday 02 of July 2013 17:41:52 Jingoo Han wrote:
> Exynos Display Port can be used only for Exynos SoCs. In addition,
> non-DT for EXYNOS SoCs is be supported from v3.11; thus, there is
> no need to support non-DT for Exynos Display Port.
> 
> The 'include/video/exynos_dp.h' file has been used for non-DT
> support and the content of file include/video/exynos_dp.h is moved
> to drivers/video/exynos/exynos_dp_core.h. Thus, the 'exynos_dp.h'
> file is removed. Also, 'struct exynos_dp_platdata' is removed,
> because it is not used any more.
> 
> Signed-off-by: Jingoo Han <jg1.han at samsung.com>
> ---
>  drivers/video/exynos/Kconfig          |    2 +-
>  drivers/video/exynos/exynos_dp_core.c |  116
> +++++++---------------------- drivers/video/exynos/exynos_dp_core.h | 
> 109 +++++++++++++++++++++++++++ drivers/video/exynos/exynos_dp_reg.c  |
>    2 -
>  include/video/exynos_dp.h             |  131
> --------------------------------- 5 files changed, 135 insertions(+),
> 225 deletions(-)
>  delete mode 100644 include/video/exynos_dp.h

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From tomasz.figa at gmail.com  Fri Jul  5 19:12:05 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Jul 2013 01:12:05 +0200
Subject: [PATCH V4 2/4] phy: Add driver for Exynos DP PHY
In-Reply-To: <000b01ce76ff$cf9fd6a0$6edf83e0$@samsung.com>
References: <000b01ce76ff$cf9fd6a0$6edf83e0$@samsung.com>
Message-ID: <1543218.1F6S8MDx2p@flatron>

On Tuesday 02 of July 2013 17:40:31 Jingoo Han wrote:
> Add a PHY provider driver for the Samsung Exynos SoC DP PHY.
> 
> Signed-off-by: Jingoo Han <jg1.han at samsung.com>
> Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Acked-by: Felipe Balbi <balbi at ti.com>
> ---
>  .../devicetree/bindings/phy/samsung-phy.txt        |    8 ++
>  drivers/phy/Kconfig                                |    6 ++
>  drivers/phy/Makefile                               |    1 +
>  drivers/phy/phy-exynos-dp-video.c                  |  111
> ++++++++++++++++++++ 4 files changed, 126 insertions(+)
>  create mode 100644 drivers/phy/phy-exynos-dp-video.c

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From tomasz.figa at gmail.com  Fri Jul  5 19:13:25 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Jul 2013 01:13:25 +0200
Subject: [PATCH V4 1/4] ARM: dts: Add DP PHY node to exynos5250.dtsi
In-Reply-To: <000a01ce76ff$a02a7c40$e07f74c0$@samsung.com>
References: <000a01ce76ff$a02a7c40$e07f74c0$@samsung.com>
Message-ID: <9669926.RxF55qzGZI@flatron>

On Tuesday 02 of July 2013 17:39:11 Jingoo Han wrote:
> Add PHY provider node for the DP PHY.
> 
> Signed-off-by: Jingoo Han <jg1.han at samsung.com>
> Acked-by: Felipe Balbi <balbi at ti.com>
> ---
>  arch/arm/boot/dts/exynos5250.dtsi |   13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From tglx at linutronix.de  Fri Jul  5 19:17:41 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sat, 6 Jul 2013 01:17:41 +0200 (CEST)
Subject: [PATCHv4 08/10] clocksource: sun4i: Remove TIMER_SCAL variable
In-Reply-To: <1373062725-19625-9-git-send-email-maxime.ripard@free-electrons.com>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
 <1373062725-19625-9-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <alpine.DEB.2.02.1307060031030.32106@ionos.tec.linutronix.de>

Maxime,

On Sat, 6 Jul 2013, Maxime Ripard wrote:
> @@ -168,8 +166,7 @@ static void __init sun4i_timer_init(struct device_node *node)
>  	clocksource_mmio_init(timer_base + TIMER_CNTVAL_REG(1), node->name,
>  			      rate, 300, 32, clocksource_mmio_readl_down);
>  
> -	writel(rate / (TIMER_SCAL * HZ),
> -	       timer_base + TIMER_INTVAL_REG(0));
> +	writel(rate / HZ, timer_base + TIMER_INTVAL_REG(0));
>  
>  	/* set clock source to HOSC, 16 pre-division */
>  	val = readl(timer_base + TIMER_CTL_REG(0));
> @@ -192,8 +189,8 @@ static void __init sun4i_timer_init(struct device_node *node)
>  
>  	sun4i_clockevent.cpumask = cpumask_of(0);
>  
> -	clockevents_config_and_register(&sun4i_clockevent, rate / TIMER_SCAL,
> -					0x1, 0xff);
> +	clockevents_config_and_register(&sun4i_clockevent, rate, 0x1,
> +					0xffffffff);

I really recommend that you go out for lots of beer/wine NOW and
resume reading this mail when you recovered from that.

I definitely appreciate your responsivness to feedback, but please go
back and read my reply to the previous version of this patch
carefully. You might eventually find out that I pointed you to another
redundant clk_get_rate() call in that code.

After you did this, please go through the other patches in that series
and check how many new instances of clk_get_rate() calls you add down
the road. I did not even bother to look whether you cleaned it up
between v3 and v4, but I'm quite sure you did not. If I'm wrong, I owe
you a beer at the next conference.

Please take your time to address all concerns and look over the whole
thing carefullly before resending. This is not a speed coding contest!

Taking time and reconsidering whether a comment for patch N/M might
apply to other parts of the code or other parts of the patch series is
not optional. Review comments are mostly hints. So it's up to you to
check whether such a comment might apply to more than the particular
patch line which was commented.

Taking time and being careful actually spares time on both and aside
of that it spares a lot of pointless wasted electrons sent through the
intertubes.

Have a good weekend!

     tglx


From tomasz.figa at gmail.com  Fri Jul  5 19:18:46 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Jul 2013 01:18:46 +0200
Subject: [PATCH v3 07/13] ARM: dts: Add AK8975 device node for Exynos4412
 TRATS2 board
In-Reply-To: <1372692155-17653-8-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
 <1372692155-17653-8-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1491290.c836bFtNe2@flatron>

Hi Sylwester, Jacek,

On Monday 01 of July 2013 17:22:29 Sylwester Nawrocki wrote:
> From: Jacek Anaszewski <j.anaszewski at samsung.com>
> 
> This patch adds AK8975 magnetometer node and corresponding
> i2c-gpio bus node for TRATS2 board.
> 
> Signed-off-by: Jacek Anaszewski <j.anaszewski at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> ---
>  arch/arm/boot/dts/exynos4412-trats2.dts |   19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
> b/arch/arm/boot/dts/exynos4412-trats2.dts index 056b835..b9de3b5 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -19,6 +19,10 @@
>  	model = "Samsung Trats 2 based on Exynos4412";
>  	compatible = "samsung,trats2", "samsung,exynos4412";
> 
> +	aliases {
> +		i2c8 = &i2c_ak8975;
> +	};
> +
>  	memory {
>  		reg =  <0x40000000 0x40000000>;
>  	};
> @@ -453,4 +457,19 @@
>  	serial at 13830000 {
>  		status = "okay";
>  	};
> +
> +	i2c_ak8975: i2c-gpio at 0 {

I think this @0 is slightly incorrect here, as it seems like there is no 
reg property present inside the node and so the device isn't located at 
any address.

For logical indices like in this case I would rather use i2c-gpio-0 
instead.

> +		compatible = "i2c-gpio";
> +		gpios = <&gpy2 4 0>, <&gpy2 5 0>;
> +		i2c-gpio,delay-us = <2>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "okay";
> +
> +		ak8975 at 0c {
> +			compatible = "asahi-kasei,ak8975";
> +			reg = <0x0c>;
> +			gpios = <&gpj0 7 0>;
> +		};
> +	};
>  };

Otherwise looks good.

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From tomasz.figa at gmail.com  Fri Jul  5 19:23:10 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Jul 2013 01:23:10 +0200
Subject: [PATCH v3 08/13] ARM: dts: Add camera device nodes for Exynos4412
 TRATS2 board
In-Reply-To: <1372692155-17653-9-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
 <1372692155-17653-9-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1996184.tcirO0Du7j@flatron>

Hi Sylwester,

On Monday 01 of July 2013 17:22:30 Sylwester Nawrocki wrote:
> This patch enables the front camera using the internal
> camera ISP (FIMC-IS).
> 
> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> ---
>  arch/arm/boot/dts/exynos4412-trats2.dts |   91
> +++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
> b/arch/arm/boot/dts/exynos4412-trats2.dts index b9de3b5..e9fb3de 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -62,6 +62,15 @@
>  			enable-active-high;
>  		};
> 
> +		cam_io_reg: voltage-regulator at 3 {

Same comment here as for patch 7/13. This is not an address of this 
regulator, so I would rather use -3 prefix.

> +			compatible = "regulator-fixed";
> +			regulator-name = "CAM_SENSOR_A";
> +			regulator-min-microvolt = <2800000>;
> +			regulator-max-microvolt = <2800000>;
> +			gpio = <&gpm0 2 0>;
> +			enable-active-high;
> +		};
> +
>  		/* More to come */
>  	};
> 
> @@ -472,4 +481,86 @@
>  			gpios = <&gpj0 7 0>;
>  		};
>  	};
> +
> +	camera {
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&cam_port_b_clk_active>;
> +		status = "okay";
> +
> +		fimc_0: fimc at 11800000 {
> +			clock-frequency = <160000000>;
> +			status = "okay";
> +		};
> +
> +		fimc_1: fimc at 11810000 {
> +			clock-frequency = <160000000>;
> +			status = "okay";
> +		};
> +
> +		fimc_2: fimc at 11820000 {
> +			clock-frequency = <160000000>;
> +			status = "okay";
> +		};
> +
> +		fimc_3: fimc at 11830000 {
> +			clock-frequency = <160000000>;
> +			status = "okay";
> +		};
> +
> +		csis_1: csis at 11890000 {
> +			vddcore-supply = <&ldo8_reg>;
> +			vddio-supply = <&ldo10_reg>;
> +			clock-frequency = <160000000>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;

Hmm. Couldn't the two #properties above be moved to exynos4.dtsi instead?

Otherwise looks good.

Best regards,
Tomasz

> +			status = "okay";
> +
> +			/* Camera D (4) MIPI CSI-2 (CSIS1) */
> +			port at 4 {
> +				reg = <4>;
> +				csis1_ep: endpoint {
> +					remote-endpoint = <&is_s5k6a3_ep>;
> +					data-lanes = <1>;
> +					samsung,csis-hs-settle = <18>;
> +					samsung,csis-wclk;
> +				};
> +			};
> +		};
> +
> +		fimc_lite_0: fimc-lite at 12390000 {
> +			status = "okay";
> +		};
> +
> +		fimc_lite_1: fimc-lite at 123A0000 {
> +			status = "okay";
> +		};
> +
> +		fimc-is at 12000000 {
> +			pinctrl-0 = <&fimc_is_uart>;
> +			pinctrl-names = "default";
> +			status = "okay";
> +
> +			i2c1_isp: i2c-isp at 12140000 {
> +				pinctrl-0 = <&fimc_is_i2c1>;
> +				pinctrl-names = "default";
> +
> +				s5k6a3 at 10 {
> +					compatible = "samsung,s5k6a3";
> +					reg = <0x10>;
> +					svdda-supply = <&cam_io_reg>;
> +					svddio-supply = <&ldo19_reg>;
> +					clock-frequency = <24000000>;
> +					samsung,camclk-out = <1>;
> +					gpios = <&gpm1 6 0>;
> +
> +					port {
> +						is_s5k6a3_ep: endpoint {
> +							remote-endpoint = 
<&csis1_ep>;
> +							data-lanes = <1>;
> +						};
> +					};
> +				};
> +			};
> +		};
> +	};
>  };


From tomasz.figa at gmail.com  Fri Jul  5 19:26:03 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Jul 2013 01:26:03 +0200
Subject: [PATCH v3 12/13] ARM: dts: Add S5K5BA sensor regulator
 definitions for Trats board
In-Reply-To: <1372692155-17653-13-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
 <1372692155-17653-13-git-send-email-s.nawrocki@samsung.com>
Message-ID: <11736061.3CXfgF4Q9h@flatron>

Hi Sylwester, Andrzej,

On Monday 01 of July 2013 17:22:34 Sylwester Nawrocki wrote:
> From: Andrzej Hajda <a.hajda at samsung.com>
> 
> Add MAX8998 LDO12 and fixed voltage regulator nodes. While at it,
> all fixed voltage regulator nodes are grouped in a 'regulators' node.
> 
> Signed-off-by: Andrzej Hajda <a.hajda at samsung.com>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> ---
>  arch/arm/boot/dts/exynos4210-trats.dts |   80
> +++++++++++++++++++++++++------- 1 file changed, 64 insertions(+), 16
> deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
> b/arch/arm/boot/dts/exynos4210-trats.dts index 6b1568e..f62e299 100644
> --- a/arch/arm/boot/dts/exynos4210-trats.dts
> +++ b/arch/arm/boot/dts/exynos4210-trats.dts
> @@ -30,13 +30,64 @@
>  		bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 
rootwait
> earlyprintk panic=5"; };
> 
> -	vemmc_reg: voltage-regulator at 0 {
> -	        compatible = "regulator-fixed";
> -		regulator-name = "VMEM_VDD_2.8V";
> -		regulator-min-microvolt = <2800000>;
> -		regulator-max-microvolt = <2800000>;
> -		gpio = <&gpk0 2 0>;
> -		enable-active-high;
> +	regulators {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <0>;

I don't think any addressing is needed for these regulators, so I'd 
suggest removing those #properties and replacing @N with -N suffix.

Otherwise looks good.

Best regards,
Tomasz

> +
> +		vemmc_reg: regulator at 0 {
> +			compatible = "regulator-fixed";
> +			regulator-name = "VMEM_VDD_2.8V";
> +			regulator-min-microvolt = <2800000>;
> +			regulator-max-microvolt = <2800000>;
> +			gpio = <&gpk0 2 0>;
> +			enable-active-high;
> +		};
> +
> +		tsp_reg: regulator at 1 {
> +			compatible = "regulator-fixed";
> +			regulator-name = "TSP_FIXED_VOLTAGES";
> +			regulator-min-microvolt = <2800000>;
> +			regulator-max-microvolt = <2800000>;
> +			gpio = <&gpl0 3 0>;
> +			enable-active-high;
> +		};
> +
> +		cam_af_28v_reg: regulator at 2 {
> +			compatible = "regulator-fixed";
> +			regulator-name = "8M_AF_2.8V_EN";
> +			regulator-min-microvolt = <2800000>;
> +			regulator-max-microvolt = <2800000>;
> +			gpio = <&gpk1 1 0>;
> +			enable-active-high;
> +		};
> +
> +		cam_io_en_reg: regulator at 3 {
> +			compatible = "regulator-fixed";
> +			regulator-name = "CAM_IO_EN";
> +			regulator-min-microvolt = <2800000>;
> +			regulator-max-microvolt = <2800000>;
> +			gpio = <&gpe2 1 0>;
> +			enable-active-high;
> +		};
> +
> +		cam_io_12v_reg: regulator at 4 {
> +			compatible = "regulator-fixed";
> +			regulator-name = "8M_1.2V_EN";
> +			regulator-min-microvolt = <1200000>;
> +			regulator-max-microvolt = <1200000>;
> +			gpio = <&gpe2 5 0>;
> +			enable-active-high;
> +		};
> +
> +		vt_core_15v_reg: regulator at 5 {
> +			compatible = "regulator-fixed";
> +			regulator-name = "VT_CORE_1.5V";
> +			regulator-min-microvolt = <1500000>;
> +			regulator-max-microvolt = <1500000>;
> +			gpio = <&gpe2 2 0>;
> +			enable-active-high;
> +		};
>  	};
> 
>  	sdhci_emmc: sdhci at 12510000 {
> @@ -97,15 +148,6 @@
>  		};
>  	};
> 
> -	tsp_reg: voltage-regulator {
> -		compatible = "regulator-fixed";
> -		regulator-name = "TSP_FIXED_VOLTAGES";
> -		regulator-min-microvolt = <2800000>;
> -		regulator-max-microvolt = <2800000>;
> -		gpio = <&gpl0 3 0>;
> -		enable-active-high;
> -	};
> -
>  	i2c at 13890000 {
>  		samsung,i2c-sda-delay = <100>;
>  		samsung,i2c-slave-addr = <0x10>;
> @@ -218,6 +260,12 @@
>  				     regulator-always-on;
>  				};
> 
> +				vtcam_reg: LDO12 {
> +				     regulator-name = "VT_CAM_1.8V";
> +				     regulator-min-microvolt = <1800000>;
> +				     regulator-max-microvolt = <1800000>;
> +				};
> +
>  				vcclcd_reg: LDO13 {
>  				     regulator-name = "VCC_3.3V_LCD";
>  				     regulator-min-microvolt = <3300000>;


From tomasz.figa at gmail.com  Fri Jul  5 19:27:36 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Jul 2013 01:27:36 +0200
Subject: [PATCH v3 00/13] ARM: dts: Add camera and magnetometer support
 for TRATS(2) board
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <7005891.8tx3m8lCx1@flatron>

Hi Sylwester,

On Monday 01 of July 2013 17:22:22 Sylwester Nawrocki wrote:
> This patch series includes some fixes and extensions to the Exynos dts
> files to add the camera and magnetometer sensor support for the TRATS
> and TRATS2 board. It depends on a patch from Tomasz adding initial
> TRATS2 board dts file [1].
> 
> Comparing to the previous version of this patch set I've added a few
> more patches, for the Exynos4210 based TRATS board and a patch adding
> MIPI CSIS/DSIM PHY provider nodes and related properties to the PHY
> consumer nodes.
> 
> This series has been tested with the S5K6A3/FIMC-IS and S5K5BAFX
> (front facing) cameras on top of next-20130627 tag. It can be found
> also at:
> http://git.linuxtv.org/snawrocki/samsung.git/next-20130627-dts-trats-v3
> 
> Detailed changes since v2 are listed in each patch.
> 
> Changes since v1:
>  - enabled pull down in cam-port-{a, b}-clk-idle nodes (1/8)
>  - added node alias for i2c-gpio at 0 I2C controller node (7/8).
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg253184.html
> 
> Andrzej Hajda (2):
>   ARM: dts: Add Exynos4210 SoC camera port pinctrl nodes
>   ARM: dts: Add S5K5BA sensor regulator definitions for Trats board
> 
> Jacek Anaszewski (1):
>   ARM: dts: Add AK8975 device node for Exynos4412 TRATS2 board
> 
> Sylwester Nawrocki (10):
>   ARM: dts: Correct camera pinctrl nodes for Exynos4x12 SoCs
>   ARM: dts: Add pinctrl entries for Exynos4x12 FIMC-IS peripherals
>   ARM: dts: Add ISP power domain node for Exynos4x12
>   ARM: dts: Use generic DMA bindings for Exynos4 SPI devices
>   ARM: dts: Add camera subsystem device nodes to exynos4.dtsi
>   ARM: dts: Add camera subsystem nodes to exynos4x12.dtsi
>   ARM: dts: Add camera device nodes for Exynos4412 TRATS2 board
>   ARM: dts: Add camera device nodes for Exynos4210 SoCs
>   ARM: dts: Add FIMC nodes for Exynos4210 Trats board
>   ARM: dts: Add MIPI PHY node to exynos4.dtsi
> 
>  arch/arm/boot/dts/exynos4.dtsi            |  102
> ++++++++++++++++++++++++-- arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 
>  23 ++++++
>  arch/arm/boot/dts/exynos4210-trats.dts    |  103
> ++++++++++++++++++++++----- arch/arm/boot/dts/exynos4210.dtsi         |
>   30 ++++++++
>  arch/arm/boot/dts/exynos4412-trats2.dts   |  110
> +++++++++++++++++++++++++++++ arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
> |   61 ++++++++++++++-- arch/arm/boot/dts/exynos4x12.dtsi         | 
> 103 +++++++++++++++++++++++++++ 7 files changed, 503 insertions(+), 29
> deletions(-)

For all the patches I haven't commented on:

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From arnd at arndb.de  Fri Jul  5 19:34:56 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 6 Jul 2013 01:34:56 +0200
Subject: scripts/kallsyms: Avoid ARM veneer symbols
In-Reply-To: <20130705172659.GJ2932@localhost.localdomain>
References: <2983817.Xe2505Drlj@wuerfel> <201307051842.44721.arnd@arndb.de>
 <20130705172659.GJ2932@localhost.localdomain>
Message-ID: <201307060134.56933.arnd@arndb.de>

On Friday 05 July 2013, Dave P Martin wrote:
> On Fri, Jul 05, 2013 at 05:42:44PM +0100, Arnd Bergmann wrote:
> > On Friday 05 July 2013, Dave P Martin wrote:
> > > On Wed, Jul 03, 2013 at 06:03:04PM +0200, Arnd Bergmann wrote:
> 
> I think there are a small number of patterns to check for.
> 
> __*_veneer, __*_from_arm and __*_from_thumb should cover most cases.

Ok.

> > * There are actually symbols without a name on ARM, which screws up the
> >   kallsyms.c parser. These also seem to be veneers, but attached to some
> >   random function:
> 
> Hmmm, I don't what those are.  By default, we should probably ignore those
> too.  Maybe they have something to do with link-time relocation processing.

Definitely link-time. It only shows up after the final link, and only
with ld.bfd not with ld.gold as I found out now.

> > $ nm obj-tmp/.tmp_vmlinux1 | head
> > c09e8db1 t 
> > c09e8db5 t 
> > c09e8db9 t    # <==========
> > c09e8dbd t 
> > c0abfc29 t 
> > c0008000 t $a
> > c0f7b640 t $a
> > 
> > $ objdump -Dr obj-tmp/.tmp_vmlinux1 | grep -C 30 c09e8db.
> > c0851fcc <wlc_phy_edcrs_lock>:
> > c0851fcc:       b538            push    {r3, r4, r5, lr}
> > c0851fce:       b500            push    {lr}
> > c0851fd0:       f7bb d8dc       bl      c000d18c <__gnu_mcount_nc>
> > c0851fd4:       f240 456b       movw    r5, #1131       ; 0x46b
> > c0851fd8:       4604            mov     r4, r0
> > c0851fda:       f880 14d5       strb.w  r1, [r0, #1237] ; 0x4d5
> > c0851fde:       462a            mov     r2, r5
> > c0851fe0:       f44f 710b       mov.w   r1, #556        ; 0x22c
> > c0851fe4:       f7ff fe6d       bl      c0851cc2 <write_phy_reg>
> > c0851fe8:       4620            mov     r0, r4
> > c0851fea:       462a            mov     r2, r5
> > c0851fec:       f240 212d       movw    r1, #557        ; 0x22d
> > c0851ff0:       f7ff fe67       bl      c0851cc2 <write_phy_reg>
> > c0851ff4:       4620            mov     r0, r4
> > c0851ff6:       f240 212e       movw    r1, #558        ; 0x22e
> > c0851ffa:       f44f 7270       mov.w   r2, #960        ; 0x3c0
> > c0851ffe:       f196 fedb       bl      c09e8db8 <tpci200_free_irq+0x78>  # <===========
> > c0852002:       4620            mov     r0, r4
> > c0852004:       f240 212f       movw    r1, #559        ; 0x22f
> > c0852008:       f44f 7270       mov.w   r2, #960        ; 0x3c0
> > c085200c:       e8bd 4038       ldmia.w sp!, {r3, r4, r5, lr}
> > c0852010:       f7ff be57       b.w     c0851cc2 <write_phy_reg>
> > 
> > 
> > ... # in tpci200_free_irq:
> > c09e8d9e:       e003            b.n     c09e8da8 <tpci200_free_irq+0x68>
> > c09e8da0:       f06f 0415       mvn.w   r4, #21
> > c09e8da4:       e000            b.n     c09e8da8 <tpci200_free_irq+0x68>
> > c09e8da6:       4c01            ldr     r4, [pc, #4]    ; (c09e8dac <tpci200_free_irq+0x6c>)
> > c09e8da8:       4620            mov     r0, r4
> > c09e8daa:       bdf8            pop     {r3, r4, r5, r6, r7, pc}
> > c09e8dac:       fffffe00                        ; <UNDEFINED> instruction: 0xfffffe00
> > c09e8db0:       f4cf b814       b.w     c06b7ddc <bna_enet_sm_chld_stop_wait_entry>
> > c09e8db4:       f53e bed8       b.w     c0727b68 <gem_do_stop>
> > c09e8db8:       f668 bf83       b.w     c0851cc2 <write_phy_reg>           # <==========
> > c09e8dbc:       d101            bne.n   c09e8dc2 <tpci200_free_irq+0x82>
> > c09e8dbe:       f435 b920       b.w     c061e002 <twl_reset_sequence+0x34c>
> > 
> > It makes no sense to me at all that a function in one driver can just call
> > write_phy_reg a couple of times, but need a veneer in the middle, and put
> > that veneer in a totally unrelated function in another driver!
> 
> I think that if ld inserts a veneer for a function anywhere, branches
> from any object in the link to that target symbol can reuse the same
> veneer as a trampoline, effectively appearing to branch through an
> unrelated location to reach the destination.

That part makes sense, but it doesn't explain why ld would do that just
for the third out of four identical function calls in the example above.

> ld inserts veneers between individual input sections, but I don't
> think they have to go next to the same section the branch originates
> from.  In the above code, it looks like that series of unconditional
> branches after the end of tpci200_free_irq might be a common veneer pool
> for many different destinations.

Yes, exactly. In this build I had six of these nameless symbols, and five
of them were in this one function.

> LTO may also make the expected compilation unit boundaries disappear
> completely.  Anything could end up almost anywhere in that case.
> Files could get intermingled, inlined and generally spread all over the
> place.

I'm not sure we actually want to enable that in the kernel ;-)

In particular in combination with kallsyms, it would make the kallsyms
information rather useless when we can no longer infer a function name
from an address.

> Even so, veneers shouldn't be needed in the common case where we're not
> jumping across .rodata.
> 
> > 
> > If this is a binutils bug or gcc bug, we should probably just fix it, but it
> > might be easier to work around it by changing kallsyms.c some more.
> 
> I haven't found a trivial way to reproduce those nameless symbols.
> I don't know whether they're a bug or not...
> 
> Making kallsyms robust against this might be a good idea anyway.

Maybe we can find a binutils expert next week at Linaro connect to take a
look at the data. I can prepare a test case.

	Arnd


From thomas.petazzoni at free-electrons.com  Fri Jul  5 19:35:47 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 6 Jul 2013 01:35:47 +0200
Subject: [PATCH v6 00/21] MBus DT binding: PCIe strikes back
In-Reply-To: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130706013547.3ce7280b@skate>

Jason, Arnd,

On Fri,  5 Jul 2013 18:39:11 -0300, Ezequiel Garcia wrote:
> See the previous version of this patchset for further context:
> 
> http://www.mail-archive.com/devicetree-discuss at lists.ozlabs.org/msg35753.html
> 
> This new proposal is an attempt to address some issues raised about the PCIe
> 'fake' windows mapping present in the previous version.
> 
> Instead of defining a 'fake' MBUS_ID(0xf0, 0x02) region for the whole
> PCIe memory and IO space, we use real target ID and attribute for the windows.
> 
> See the example below, where a somewhat complete device tree extract is shown:
> 
> 	soc {
> 		compatible = "marvell,armadaxp-mbus", "simple-bus";
> 		controller = <&mbusc>;
> 
> 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
> 			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
> 			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
> 
> 		bootrom {
> 			compatible = "marvell,bootrom";
> 			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
> 		};
> 
> 		devbus-bootcs {
> 			status = "okay";
> 			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;
> 
> 			/* NOR */
> 			nor {
> 				compatible = "cfi-flash";
> 				reg = <0 0x8000000>;
> 				bank-width = <2>;
> 			};
> 		};
> 
> 		pcie-controller {
> 			compatible = "marvell,armada-xp-pcie";
> 			status = "okay";
> 			device_type = "pci";
> 
> 			#address-cells = <3>;
> 			#size-cells = <2>;
> 
> 			ranges =
> 			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
> 				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
> 				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
> 				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
> 				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
> 				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
> 				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>;
> 
> 
> 			pcie at 1,0 {
> 				/* Port 0, Lane 0 */
> 				status = "okay";
> 			};
> 		};
> 
> 		internal-regs {
> 			compatible = "simple-bus";
> 			#address-cells = <1>;
> 			#size-cells = <1>;
> 			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
> 
> 			mbusc: mbus-controller at 20000 {
> 				reg = <0x20000 0x100>, <0x20180 0x20>;
> 			};
> 
> 			interrupt-controller at 20000 {
> 			      reg = <0x20a00 0x2d0>, <0x21070 0x58>;
> 			};
> 		};
> 	};

After a discussion with Arnd on IRC, here is the new DT layout we came
up with:

	soc {
		compatible = "marvell,armadaxp-mbus", "simple-bus";
		controller = <&mbusc>;

		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
		pcie-mem-aperture = <0xe0000000 0x8000000>;
                pcie-io-aperture  = <0xe8000000 0x100000>;

		bootrom {
			compatible = "marvell,bootrom";
			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
		};

		devbus-bootcs {
			status = "okay";
			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;

			/* NOR */
			nor {
				compatible = "cfi-flash";
				reg = <0 0x8000000>;
				bank-width = <2>;
			};
		};

		pcie-controller {
			compatible = "marvell,armada-xp-pcie";
			status = "okay";
			device_type = "pci";

			#address-cells = <3>;
			#size-cells = <2>;

			ranges =
			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
				0x82000000 1 0       MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
				0x81000000 1 0       MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */
                                0x82000000 2 0       MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
                                0x81000000 2 0       MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */>;


                        pcie at 1,0 {
                                device_type = "pci";
                                assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
                                reg = <0x0800 0 0 0 0>;
                                #address-cells = <3>;
                                #size-cells = <2>;
                                #interrupt-cells = <1>;
                                ranges = <0x82000000 0 0 0x82000000 1 0 1 0
                                          0x81000000 0 0 0x81000000 1 0 1 0>;
                                interrupt-map-mask = <0 0 0 0>;
                                interrupt-map = <0 0 0 0 &mpic 58>;
                                marvell,pcie-port = <0>;
                                marvell,pcie-lane = <0>;
                                clocks = <&gateclk 5>;
                                status = "disabled";
                        };

                        pcie at 2,0 {
                                device_type = "pci";
                                assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
                                reg = <0x1000 0 0 0 0>;
                                #address-cells = <3>;
                                #size-cells = <2>;
                                #interrupt-cells = <1>;
                                ranges = <0x82000000 0 0 0x82000000 2 0 1 0
                                          0x81000000 0 0 0x81000000 2 0 1 0>;
                                interrupt-map-mask = <0 0 0 0>;
                                interrupt-map = <0 0 0 0 &mpic 62>;
                                marvell,pcie-port = <1>;
                                marvell,pcie-lane = <0>;
                                clocks = <&gateclk 9>;
                                status = "disabled";
                        };
		};

		internal-regs {
			compatible = "simple-bus";
			#address-cells = <1>;
			#size-cells = <1>;
			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;

			mbusc: mbus-controller at 20000 {
				reg = <0x20000 0x100>, <0x20180 0x20>;
			};

			interrupt-controller at 20000 {
			      reg = <0x20a00 0x2d0>, <0x21070 0x58>;
			};
		};
	};

I.e, the changes are :

 (1) The main soc {} node gains two new additional DT properties:
     pcie-mem-aperture and pcie-io-aperture. The mvebu-mbus reads those
     informations, and provides an API
     mvebu_mbus_alloc_pcie_{mem,io}_aperture(phys_addr_t *base, size_t
     *size) that allows the PCIe driver to get the mem and I/O
     apertures for PCIe. In the future, the mvebu-mbus driver may
     decide to allocate those apertures dynamically rather than have
     values hardcoded in the DT: this is the private business of
     mvebu-mbus. For now, the mvebu-mbus driver will use those static
     values from the DT, as we don't want to do a full dynamic window
     base address allocation for now. This makes sense, as mvebu-mbus
     is the "gake keeper" of what gets mapped in terms of mbus windows.

 (2) The ranges property of the main pcie-controller {} node is changed
     to use 0x82000000 and 0x81000000 for all PCIe interfaces, as requested
     by the OF spec. The second 32 bits word of the child address is used
     to encode the port number (in our example 1 for the first MEM and I/O
     ranges, and 2 for the next MEM and I/O ranges).

 (3) A non-empty range property is added in the child pcie at x,y nodes to
     translate back into regular PCIe addresses the child addresses
     described in the ranges property in pcie-controller. I.e, it
     simply translate (0x82000000 0 0) into (0x8200000 <port> 0).

Arnd, Jason, if you could confirm that you both agree with this DT
binding soon, Ezequiel and I would quickly adapt the code accordingly,
and hopefully converge towards a final patch set.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From tomasz.figa at gmail.com  Fri Jul  5 19:36:57 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Jul 2013 01:36:57 +0200
Subject: [PATCH 1/3] ARM: dts: Put Arndale fixed voltage regulators on a
 simple-bus
In-Reply-To: <1372714599-17588-1-git-send-email-broonie@kernel.org>
References: <1372714599-17588-1-git-send-email-broonie@kernel.org>
Message-ID: <2269980.iUpB0kJaI3@flatron>

Hi Mark,

On Monday 01 of July 2013 22:36:37 Mark Brown wrote:
> From: Mark Brown <broonie at linaro.org>
> 
> Fixed voltage regulators (and other similar free standing things) are
> supposed to go on a simple-bus for DT correctness reasons.
> 
> Signed-off-by: Mark Brown <broonie at linaro.org>
> ---
>  arch/arm/boot/dts/exynos5250-arndale.dts | 28
> +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11
> deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
> b/arch/arm/boot/dts/exynos5250-arndale.dts index abc7272..68a13a6
> 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -429,18 +429,24 @@
>  		vdd-supply = <&ldo8_reg>;
>  	};
> 
> -	mmc_reg: voltage-regulator {
> -		compatible = "regulator-fixed";
> -		regulator-name = "VDD_33ON_2.8V";
> -		regulator-min-microvolt = <2800000>;
> -		regulator-max-microvolt = <2800000>;
> -		gpio = <&gpx1 1 1>;
> -		enable-active-high;
> -	};
> +	regulators {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <0>;

Are the two #properties above really necessary? The regulators that will 
be placed here probably don't need any kind of addressing, so it should be 
possible to omit them.

> +
> +		mmc_reg: voltage-regulator {

I'd suggest suffixing name of this node with an index, like voltage-
regulator-0 to be more future proof, in case of further fixed regulators 
being added.

> +			compatible = "regulator-fixed";
> +			regulator-name = "VDD_33ON_2.8V";
> +			regulator-min-microvolt = <2800000>;
> +			regulator-max-microvolt = <2800000>;
> +			gpio = <&gpx1 1 1>;
> +			enable-active-high;
> +		};
> 
> -	reg_hdmi_en: fixedregulator at 0 {
> -		compatible = "regulator-fixed";
> -		regulator-name = "hdmi-en";
> +		reg_hdmi_en: fixedregulator at 0 {

And here I'd use the same convention of suffixes, renaming the node to 
voltage-regulator-1 for the sake of consistency.

Best regards,
Tomasz

> +			compatible = "regulator-fixed";
> +			regulator-name = "hdmi-en";
> +		};
>  	};
> 
>  	fixed-rate-clocks {


From arnd at arndb.de  Fri Jul  5 19:38:35 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 6 Jul 2013 01:38:35 +0200
Subject: [PATCH v6 00/21] MBus DT binding: PCIe strikes back
In-Reply-To: <20130706013547.3ce7280b@skate>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130706013547.3ce7280b@skate>
Message-ID: <201307060138.36191.arnd@arndb.de>

On Saturday 06 July 2013, Thomas Petazzoni wrote:
> Arnd, Jason, if you could confirm that you both agree with this DT
> binding soon, Ezequiel and I would quickly adapt the code accordingly,
> and hopefully converge towards a final patch set.

Looks all good from what I can tell.

	Arnd


From sboyd at codeaurora.org  Fri Jul  5 19:39:33 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri,  5 Jul 2013 16:39:33 -0700
Subject: [PATCH] irqchip: gic: Don't complain in gic_get_cpumask() if UP system
Message-ID: <1373067573-29946-1-git-send-email-sboyd@codeaurora.org>

In a uniprocessor implementation the interrupt processor targets
registers are read-as-zero/write-ignored (RAZ/WI). Unfortunately
gic_get_cpumask() will print a critical message saying

 GIC CPU mask not found - kernel will fail to boot.

if these registers all read as zero, but there won't actually be
a problem on uniprocessor systems and the kernel will boot just
fine. Skip this check if we're running a UP kernel or if we
detect that the hardware only supports a single processor.

Cc: Nicolas Pitre <nico at linaro.org>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---

Maybe we should just drop the check entirely? It looks like it may
just be debug code that won't ever trigger in practice, even on the
11MPCore that caused this code to be introduced.

 drivers/irqchip/irq-gic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 19ceaa6..589c760 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -368,7 +368,7 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic)
 			break;
 	}
 
-	if (!mask)
+	if (!mask && num_possible_cpus() > 1)
 		pr_crit("GIC CPU mask not found - kernel will fail to boot.\n");
 
 	return mask;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From khilman at linaro.org  Fri Jul  5 19:40:48 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Fri, 5 Jul 2013 16:40:48 -0700
Subject: [PATCH] ARM: Make multi_v7_defconfig usable on hardware
In-Reply-To: <20130626225714.GB911@quad.lixom.net>
References: <1372210565-22962-1-git-send-email-olof@lixom.net>
 <CAOesGMg2du8PsOGy1kdePT4vMsWie1N8hmjCxRqr-LS6RAC07g@mail.gmail.com>
 <20130626225714.GB911@quad.lixom.net>
Message-ID: <CAGa+x85dmDg9a2B8rAPw5wQTYuGDu0Nva=XEgonKgA1+=JAhCw@mail.gmail.com>

On Wed, Jun 26, 2013 at 3:57 PM, Olof Johansson <olof at lixom.net> wrote:
> On Tue, Jun 25, 2013 at 06:38:21PM -0700, Olof Johansson wrote:
>> On Tue, Jun 25, 2013 at 6:36 PM, Olof Johansson <olof at lixom.net> wrote:
>>
>> > +CONFIG_DEBUG_LL=y
>> > +CONFIG_DEBUG_OMAP2PLUS_UART=y
>> > +CONFIG_DEBUG_OMAP4UART3=y
>>
>> Clearly not supposed to be there for the posted version, my bad --
>> will take those out before committing.
>>
>> (this will go on top of next/late, btw).
>
> Actually, this doesn't go nicely on top of any branch right now since
> multi_v7_defconfig is modified in several of the branches.
>
> So, I've applied this on top of for-next (which is unorthodox and unusual), and
> we'll move it over to what will likely be the first, pre-rc1 fixes pull request
> that we send up, once all the other contents has been merged.

Hopefully this can be carefully rebuilt on top of -rc1 with inspection
for any deletions.  For example, I just noticed that this undoes some
of the additions to multi_v7_defconfig which add the network support
for Allwinner/sun4, and so broke network-enabled kernels for my
cubieboard.

[1]
commit fb1c60288a886a28dc7c055449fd1936140fe891
Author: Maxime Ripard <maxime.ripard at free-electrons.com>
Date:   Sun Jun 9 18:13:53 2013 +0200

    ARM: multi_v7: Enable Allwinner EMAC in multi_v7_defconfig

    Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>


From tomasz.figa at gmail.com  Fri Jul  5 19:41:02 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Jul 2013 01:41:02 +0200
Subject: [PATCH] drm/exynos: Add missing includes
In-Reply-To: <20130702150449.GO27646@sirena.org.uk>
References: <1372683355-27460-1-git-send-email-broonie@kernel.org>
 <008a01ce771e$afe02670$0fa07350$%dae@samsung.com>
 <20130702150449.GO27646@sirena.org.uk>
Message-ID: <1504355.0ZFzGzMgKd@flatron>

On Tuesday 02 of July 2013 16:04:49 Mark Brown wrote:
> On Tue, Jul 02, 2013 at 09:21:32PM +0900, Inki Dae wrote:
> > > Ensure that all externally accessed functions are correctly
> > > prototyped
> > > when defined in each file by making sure the headers with the
> > > protoypes
> > > are included in the file with the definition.
> > 
> > I don't see why this patch is needed. it seems like including
> > unnecessary headers so it makes the code size enlarged.
> 
> Well, aside from it being basic good practice and allowing the compiler
> to check for errors in the prototypes this is also something that sparse
> warns about.
> 
> If the resulting binary size is changed by having the headers included
> then that indicates a bug in the headers - they *really* shouldn't be
> doing anything substantial here.  None of the headers in question looked
> at all worrying.

+1

Best regards,
Tomasz



From olof at lixom.net  Fri Jul  5 19:43:54 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 5 Jul 2013 16:43:54 -0700
Subject: [PATCH] ARM: Make multi_v7_defconfig usable on hardware
In-Reply-To: <CAGa+x85dmDg9a2B8rAPw5wQTYuGDu0Nva=XEgonKgA1+=JAhCw@mail.gmail.com>
References: <1372210565-22962-1-git-send-email-olof@lixom.net>
 <CAOesGMg2du8PsOGy1kdePT4vMsWie1N8hmjCxRqr-LS6RAC07g@mail.gmail.com>
 <20130626225714.GB911@quad.lixom.net>
 <CAGa+x85dmDg9a2B8rAPw5wQTYuGDu0Nva=XEgonKgA1+=JAhCw@mail.gmail.com>
Message-ID: <CAOesGMhbcbNTG7666O8Ux9vo1FR1K+MseOY5bUeewF+bRNftkQ@mail.gmail.com>

On Fri, Jul 5, 2013 at 4:40 PM, Kevin Hilman <khilman at linaro.org> wrote:
> On Wed, Jun 26, 2013 at 3:57 PM, Olof Johansson <olof at lixom.net> wrote:
>> On Tue, Jun 25, 2013 at 06:38:21PM -0700, Olof Johansson wrote:
>>> On Tue, Jun 25, 2013 at 6:36 PM, Olof Johansson <olof at lixom.net> wrote:
>>>
>>> > +CONFIG_DEBUG_LL=y
>>> > +CONFIG_DEBUG_OMAP2PLUS_UART=y
>>> > +CONFIG_DEBUG_OMAP4UART3=y
>>>
>>> Clearly not supposed to be there for the posted version, my bad --
>>> will take those out before committing.
>>>
>>> (this will go on top of next/late, btw).
>>
>> Actually, this doesn't go nicely on top of any branch right now since
>> multi_v7_defconfig is modified in several of the branches.
>>
>> So, I've applied this on top of for-next (which is unorthodox and unusual), and
>> we'll move it over to what will likely be the first, pre-rc1 fixes pull request
>> that we send up, once all the other contents has been merged.
>
> Hopefully this can be carefully rebuilt on top of -rc1 with inspection
> for any deletions.  For example, I just noticed that this undoes some
> of the additions to multi_v7_defconfig which add the network support
> for Allwinner/sun4, and so broke network-enabled kernels for my
> cubieboard.
>
> [1]
> commit fb1c60288a886a28dc7c055449fd1936140fe891
> Author: Maxime Ripard <maxime.ripard at free-electrons.com>
> Date:   Sun Jun 9 18:13:53 2013 +0200
>
>     ARM: multi_v7: Enable Allwinner EMAC in multi_v7_defconfig
>
>     Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Grmbl. Yeah, because the driver wasn't in the tree by the time the
defconfig was generated. So technically it wasn't in arm-soc by the
time we picked up the patch either.

Let's sort this out early next week when we're in Dublin. By then
davem's main pull request might be in-tree and that'll make it easier.


-Olof


From tglx at linutronix.de  Fri Jul  5 19:45:09 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sat, 6 Jul 2013 01:45:09 +0200 (CEST)
Subject: [PATCH 3/9] clocksource: dw_apb_timer: quirk for variants with
 64bit counter
In-Reply-To: <201307060053.10182.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
 <201307060053.10182.heiko@sntech.de>
Message-ID: <alpine.DEB.2.02.1307060129340.32106@ionos.tec.linutronix.de>

On Sat, 6 Jul 2013, Heiko St?bner wrote:

> This adds a quirk for IP variants containing two load_count and value
> registers that are used to provide 64bit accuracy on 32bit systems.
> 
> The added accuracy is currently not used, the driver is only adapted to
> handle the different register layout and make it work on affected devices.
> 
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> ---
>  drivers/clocksource/dw_apb_timer.c |   27 +++++++++++++++++++++++++++
>  include/linux/dw_apb_timer.h       |    6 ++++++
>  2 files changed, 33 insertions(+)
> 
> diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
> index f5e7be8..bd45351 100644
> --- a/drivers/clocksource/dw_apb_timer.c
> +++ b/drivers/clocksource/dw_apb_timer.c
> @@ -56,6 +56,17 @@ static void apbt_init_regs(struct dw_apb_timer *timer, int quirks)
>  	timer->reg_control = APBTMR_N_CONTROL;
>  	timer->reg_eoi = APBTMR_N_EOI;
>  	timer->reg_int_status = APBTMR_N_INT_STATUS;
> +
> +	/*
> +	 * On variants with 64bit counters some registers are
> +	 * moved further down.
> +	 */
> +	if (quirks & APBTMR_QUIRK_64BIT_COUNTER) {
> +		timer->reg_current_value += 0x4;
> +		timer->reg_control += 0x8;
> +		timer->reg_eoi += 0x8;
> +		timer->reg_int_status += 0x8;
> +	}
>  }

Oh, no. this is not how we handle these things.

1) We want proper constants for this 64bit IP block 

2) This is not a quirk, it's a property of that particular IP block

You already made the register offsets a part of the timer structure,
so why don't you supply a proper structure filled with that values to
the init function?

That's what we do all over the place. Either we instantiate those
structs at compile time or runtime fed by device tree or any other
configuration mechanism.
  
>  static unsigned long apbt_readl(struct dw_apb_timer *timer, unsigned long offs)
> @@ -145,6 +156,10 @@ static void apbt_set_mode(enum clock_event_mode mode,
>  		udelay(1);
>  		pr_debug("Setting clock period %lu for HZ %d\n", period, HZ);
>  		apbt_writel(timer, period, timer->reg_load_count);
> +
> +		if (timer->quirks & APBTMR_QUIRK_64BIT_COUNTER)
> +			apbt_writel(timer, 0, timer->reg_load_count + 0x4);
> +

No. We are not adding such conditional constructs when we can deal
with them just by providing a proper set of function pointers. And
definitely not with hardcoded magic 0x4 constants involved.

     timer->load_count(timer, value);

Provide a 32 bit and a 64 bit version of that function and be done
with it.

>  		ctrl |= APBTMR_CONTROL_ENABLE;
>  		apbt_writel(timer, ctrl, timer->reg_control);
>  		break;
> @@ -168,6 +183,10 @@ static void apbt_set_mode(enum clock_event_mode mode,
>  		 * running mode.
>  		 */
>  		apbt_writel(timer, ~0, timer->reg_load_count);
> +
> +		if (timer->quirks & APBTMR_QUIRK_64BIT_COUNTER)
> +			apbt_writel(timer, 0, timer->reg_load_count + 0x4);
> +

Makes this copy go away.

>  		ctrl &= ~APBTMR_CONTROL_INT;
>  		ctrl |= APBTMR_CONTROL_ENABLE;
>  		apbt_writel(timer, ctrl, timer->reg_control);
> @@ -199,6 +218,10 @@ static int apbt_next_event(unsigned long delta,
>  	apbt_writel(timer, ctrl, timer->reg_control);
>  	/* write new count */
>  	apbt_writel(timer, delta, timer->reg_load_count);
> +
> +	if (timer->quirks & APBTMR_QUIRK_64BIT_COUNTER)
> +		apbt_writel(timer, 0, timer->reg_load_count + 0x4);
> +

And this one as well.

>  	ctrl |= APBTMR_CONTROL_ENABLE;
>  	apbt_writel(timer, ctrl, timer->reg_control);
>  
> @@ -325,6 +348,10 @@ void dw_apb_clocksource_start(struct dw_apb_clocksource *dw_cs)
>  	ctrl &= ~APBTMR_CONTROL_ENABLE;
>  	apbt_writel(timer, ctrl, timer->reg_control);
>  	apbt_writel(timer, ~0, timer->reg_load_count);
> +
> +	if (timer->quirks & APBTMR_QUIRK_64BIT_COUNTER)
> +		apbt_writel(timer, 0, timer->reg_load_count + 0x4);
> +

Copy and paste is a conveniant thing, right? It just should have a pop
up window assigned which asks at the second instance of copying the
same thing whether you really thought about it.

Thanks,

	tglx

From tomasz.figa at gmail.com  Fri Jul  5 19:45:48 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Jul 2013 01:45:48 +0200
Subject: [PATCH] drm/exynos: exynos_drm_ipp: fix return value check
In-Reply-To: <CAPgLHd9yE7YES-yDFSWfHOKbbay2yLS_VrvF5-QyJumnNFitQw@mail.gmail.com>
References: <CAPgLHd9yE7YES-yDFSWfHOKbbay2yLS_VrvF5-QyJumnNFitQw@mail.gmail.com>
Message-ID: <1543220.nCniYjBE9B@flatron>

On Thursday 04 of July 2013 21:35:00 Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> 
> In case of error, the function ipp_find_obj() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check
> should be replaced with IS_ERR().
> 
> Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From tglx at linutronix.de  Fri Jul  5 19:49:45 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sat, 6 Jul 2013 01:49:45 +0200 (CEST)
Subject: [PATCH 5/9] clocksource: dw_apb_timer: quirk for variants without
 EOI register
In-Reply-To: <201307060054.07784.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
 <201307060054.07784.heiko@sntech.de>
Message-ID: <alpine.DEB.2.02.1307060147070.32106@ionos.tec.linutronix.de>

On Sat, 6 Jul 2013, Heiko St?bner wrote:
> -	dw_ced->eoi = apbt_eoi;
> +	if (quirks & APBTMR_QUIRK_NO_EOI)
> +		dw_ced->eoi = apbt_eoi_int_status;
> +	else
> +		dw_ced->eoi = apbt_eoi;

No again. This has nothing to do with quirks. We use quirks for
workarounds and not for refactoring of code.

Thanks,

	tglx

From tglx at linutronix.de  Fri Jul  5 19:51:54 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sat, 6 Jul 2013 01:51:54 +0200 (CEST)
Subject: [PATCH 6/9] clocksource: dw_apb_timer: quirk for inverted int mask
In-Reply-To: <201307060054.35996.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
 <201307060054.35996.heiko@sntech.de>
Message-ID: <alpine.DEB.2.02.1307060150030.32106@ionos.tec.linutronix.de>

On Sat, 6 Jul 2013, Heiko St?bner wrote:

> Some timer variants use an inverted setting to mask the timer interrupt.
> Therefore add a quirk to handle these variants.

And by that add even more pointless conditionals into critical code
pathes.


From tomasz.figa at gmail.com  Fri Jul  5 19:52:48 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 06 Jul 2013 01:52:48 +0200
Subject: [PATCH 2/3] of/documentation: Update G2D documentation
In-Reply-To: <1373013749-14530-2-git-send-email-sachin.kamat@linaro.org>
References: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
 <1373013749-14530-2-git-send-email-sachin.kamat@linaro.org>
Message-ID: <4264635.Hmig5l0VLj@flatron>

Hi Sachin,

On Friday 05 of July 2013 14:12:28 Sachin Kamat wrote:
> Exynos5250 G2D IP requires only the gate clock. Update the
> binding documentation accordingly.
> 
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> Cc: Inki Dae <inki.dae at samsung.com>
> ---
>  .../devicetree/bindings/gpu/samsung-g2d.txt        |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
> b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt index
> 3f454ff..60ca631 100644
> --- a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
> +++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
> @@ -12,7 +12,9 @@ Required properties:
>    - interrupts : G2D interrupt number to the CPU.
>    - clocks : from common clock binding: handle to G2D clocks.
>    - clock-names : from common clock binding: must contain "sclk_fimg2d"
> and -		  "fimg2d", corresponding to entries in the clocks 
property. +		
>  "fimg2d" for S5PV210 & Exynos4 based SoCs and "fimg2d" for +		 
> Exynos5250 SoC, corresponding to entries in the clocks
> +		  property.

I think this needs to be rephrased, because I can't get any sense from 
this sentence.

Maybe something like:

- clock-names : names of clocks listed in clocks property, in the same 
order, depending on SoC type:
    - for S5PV210 and Exynos4 based SoCs : "fimg2d" and "sclk_fimg2d"
    - for Exynos5250 SoC : "fimg2d".

What do you think?

Best regards,
Tomasz



From tglx at linutronix.de  Fri Jul  5 20:12:24 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sat, 6 Jul 2013 02:12:24 +0200 (CEST)
Subject: [PATCH 9/9] clocksource: dw_apb_timer: special variant for
 rockchip rk3188 timers
In-Reply-To: <201307060056.29370.heiko@sntech.de>
References: <201307060051.09716.heiko@sntech.de>
 <201307060056.29370.heiko@sntech.de>
Message-ID: <alpine.DEB.2.02.1307060153110.32106@ionos.tec.linutronix.de>

On Sat, 6 Jul 2013, Heiko St?bner wrote:
> +	if (of_device_is_compatible(np, "rockchip,rk3188-dw-apb-timer-osc"))
> +		*quirks |= APBTMR_QUIRK_64BIT_COUNTER | APBTMR_QUIRK_NO_EOI |
> +			   APBTMR_QUIRK_INVERSE_INTMASK |
> +			   APBTMR_QUIRK_INVERSE_PERIODIC;

Brilliant. Next time we add

> +	if (of_device_is_compatible(np, "rockchip,rk3188-dw-apb-timer-osc2"))
> +		*quirks |= APBTMR_QUIRK_64BIT_COUNTER | APBTMR_QUIRK_NO_EOI |
> +			   APBTMR_QUIRK_INVERSE_INTMASK |
> +			   APBTMR_QUIRK_INVERSE_PERIODIC | MORE_NONSENSE;

Plus the extra conditionals all over the place

and a week later

> +	if (of_device_is_compatible(np, "rockchip,rk3188-dw-apb-timer-osc3"))
> +		*quirks |= ALLNONSENSE;


This has nothing to do with QUIRKS at all. QUIRKS are our last resort
when we cannot deal with the problem in a sane way.

In this case this is simply the wrong aproach.

We can deal with it in a sane way as I pointed out before and handle
it as simple properties of the IP block. We have all mechanisms in
place to handle such properties, device tree, platform data, static
init structures. It's all there and we really do not need to plaster
the code with random QUIRK conditionals.

Did you ever consider the runtime penalty of this? Probably not,
otherwise you would have spent time on speeding up that code by
caching frequently accessed registers instead of reading them back
over and over for no reason.

Thanks,

	tglx

From r65037 at freescale.com  Fri Jul  5 21:54:04 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Sat, 6 Jul 2013 01:54:04 +0000
Subject: [v3 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <20130705155911.GK516@pengutronix.de>
References: <1373017942-12583-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373017942-12583-4-git-send-email-Hong-Xing.Zhu@freescale.com>,
 <20130705155911.GK516@pengutronix.de>
Message-ID: <0E83723C55F66F43A6041464FE31119D3142E9@039-SN2MPN1-012.039d.mgd.msft.net>

Hi Sascha:
Thanks for your comments.

Best Regards
Richard Zhu
________________________________________
From: Sascha Hauer [s.hauer at pengutronix.de]
Sent: Friday, July 05, 2013 11:59 PM
To: Richard Zhu
Cc: shawn.guo at linaro.org; linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; avorontsov at ru.mvista.com; rob.herring at calxeda.com; linux-ide at vger.kernel.org; Zhu Richard-R65037
Subject: Re: [v3 3/3] sata: imx: add ahci sata support on imx platforms

On Fri, Jul 05, 2013 at 05:52:22PM +0800, Richard Zhu wrote:
> From: Richard Zhu <r65037 at freescale.com>
>
> imx6q contains one Synopsys AHCI SATA controller,
> But it can't shares ahci_platform driver with other
> controllers.
> Because there are some misalignments of the bits
> definitions of the HBA registers and the Vendor
> Specific registers
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>  value is '0', should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the
>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>  should be configured regarding to the frequency of AHB
>  bus clock.
>  - Configurations of the AHCI PHY clock, and the signal
>  parameters of the GPR13
>
> Setup its own ahci sata driver, enable the imx6q ahci
> sata support.
>
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  drivers/ata/Kconfig    |    9 ++
>  drivers/ata/Makefile   |    1 +
>  drivers/ata/sata_imx.c |  230 ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 240 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/ata/sata_imx.c
>
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index a5a3ebc..45ed2f0 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -97,6 +97,15 @@ config SATA_AHCI_PLATFORM
>
>         If unsure, say N.
>
> +config SATA_IMX
> +     tristate "Freescale iMX AHCI SATA support"

It's rather untypical to write iMX. Please write i.MX.
[Richard] Accepted.

> +     depends on SATA_AHCI_PLATFORM
> +     help
> +       This option enables support for the Freescale iMX SoC's
> +       onboard AHCI SATA.
> +
> +       If unsure, say N.
> +
>  config SATA_FSL
>       tristate "Freescale 3.0Gbps SATA support"
>       depends on FSL_SOC
> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
> index c04d0fd..04b1c6c 100644
> --- a/drivers/ata/Makefile
> +++ b/drivers/ata/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_SATA_INIC162X) += sata_inic162x.o
>  obj-$(CONFIG_SATA_SIL24)     += sata_sil24.o
>  obj-$(CONFIG_SATA_DWC)               += sata_dwc_460ex.o
>  obj-$(CONFIG_SATA_HIGHBANK)  += sata_highbank.o libahci.o
> +obj-$(CONFIG_SATA_IMX)               += sata_imx.o
>
>  # SFF w/ custom DMA
>  obj-$(CONFIG_PDC_ADMA)               += pdc_adma.o
> diff --git a/drivers/ata/sata_imx.c b/drivers/ata/sata_imx.c
> new file mode 100644
> index 0000000..a129efb
> --- /dev/null
> +++ b/drivers/ata/sata_imx.c
> @@ -0,0 +1,230 @@
> +/*
> + * Freescale IMX AHCI SATA platform driver
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * based on the AHCI SATA platform driver by Jeff Garzik and Anton Vorontsov
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/kernel.h>
> +#include <linux/gfp.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/device.h>
> +#include <linux/platform_device.h>
> +#include <linux/libata.h>
> +#include <linux/ahci_platform.h>
> +#include <linux/of_device.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
> +#include "ahci.h"
> +#include <linux/clk-private.h>

Do you need anything from clk-private.h? You shouldn't.
[Richard]it would be removed.

> +
> +enum {
> +     HOST_TIMER1MS = 0xe0, /* Timer 1-ms */
> +};
> +
> +/* imx6q ahci module initialization. */
> +static int imx6q_sata_phy_clk(struct device *dev, int enable)
> +{
> +     int ret = 0;
> +     struct clk *sata_ref_clk;
> +
> +     sata_ref_clk = devm_clk_get(dev, "sata_ref_100m");
> +     if (IS_ERR(sata_ref_clk)) {
> +             dev_err(dev, "can't get sata_ref clock.\n");
> +             return PTR_ERR(sata_ref_clk);
> +     }

clk_get must be balanced with clk_put. You need to have some private
data and keep a pointer to the clock.
[Richard] Ok, I can create the private data, and keep a pointer to this clock.

> +     if (enable) {
> +             /* Enable PHY clock */
> +             ret = clk_prepare_enable(sata_ref_clk);
> +             if (ret < 0)
> +                     dev_err(dev, "can't prepare-enable sata_ref clock\n");

When printing error messages it's always helpful to print the error code
aswell.
[Richard] Ok, the return-err code would be added.

> +     } else {
> +             /* Disable PHY clock */

This comment (also the one above enable) doesn't contain any useful
information.
[Richard] ok, they would be removed.

> +             clk_disable_unprepare(sata_ref_clk);
> +     }
> +
> +     return ret;
> +}
> +
> +static int imx6q_sata_init(struct device *dev, void __iomem *mmio)
> +{
> +     int ret = 0;
> +     struct regmap *gpr;
> +     struct clk *ahb_clk;
> +
> +     ret = imx6q_sata_phy_clk(dev, true);
> +     if (ret < 0)
> +             return ret;
> +
> +     gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +     if (IS_ERR(gpr)) {
> +             dev_err(dev, "failed to find fsl,imx6q-iomux-gpr regmap\n");
> +             return PTR_ERR(gpr);
> +     }
> +
> +     /*
> +      * set PHY Paremeters, two steps to configure the GPR13,
> +      * one write for rest of parameters, mask of first write
> +      * is 0x07fffffd, and the other one write for setting
> +      * the mpll_clk_en.
> +      */
> +     regmap_update_bits(gpr, 0x34, IMX6Q_GPR13_SATA_RX_EQ_VAL_MASK
> +                     | IMX6Q_GPR13_SATA_RX_LOS_LVL_MASK
> +                     | IMX6Q_GPR13_SATA_RX_DPLL_MODE_MASK
> +                     | IMX6Q_GPR13_SATA_SPD_MODE_MASK
> +                     | IMX6Q_GPR13_SATA_MPLL_SS_EN
> +                     | IMX6Q_GPR13_SATA_TX_ATTEN_MASK
> +                     | IMX6Q_GPR13_SATA_TX_BOOST_MASK
> +                     | IMX6Q_GPR13_SATA_TX_LVL_MASK
> +                     | IMX6Q_GPR13_SATA_TX_EDGE_RATE
> +                     , IMX6Q_GPR13_SATA_RX_EQ_VAL_3_0_DB
> +                     | IMX6Q_GPR13_SATA_RX_LOS_LVL_SATA2M
> +                     | IMX6Q_GPR13_SATA_RX_DPLL_MODE_2P_4F
> +                     | IMX6Q_GPR13_SATA_SPD_MODE_3P0G
> +                     | IMX6Q_GPR13_SATA_MPLL_SS_EN
> +                     | IMX6Q_GPR13_SATA_TX_ATTEN_9_16
> +                     | IMX6Q_GPR13_SATA_TX_BOOST_3_33_DB
> +                     | IMX6Q_GPR13_SATA_TX_LVL_1_025_V);
> +     regmap_update_bits(gpr, 0x34, IMX6Q_GPR13_SATA_MPLL_CLK_EN,
> +                     IMX6Q_GPR13_SATA_MPLL_CLK_EN);
> +     usleep_range(100, 200);
> +
> +     /*
> +      * Configure the HWINIT bits of the HOST_CAP and HOST_PORTS_IMPL,
> +      * and IP vendor specific register HOST_TIMER1MS.
> +      *
> +      * Configure CAP_SSS (support stagered spin up).
> +      * Implement the port0.
> +      * Get the ahb clock rate, and configure the TIMER1MS register.
> +      */
> +     ret = readl(mmio + HOST_CAP);

You should use a u32 type for storing readl results.
[Richard] Accepted.

> +     if (!(ret & HOST_CAP_SSS))
> +             writel(ret |= HOST_CAP_SSS, mmio + HOST_CAP);

Why do you write this conditionally? Just write it unconditionally.
[Richard]Ok, no problem. Would write it uncontitionally.

> +     ret = readl(mmio + HOST_PORTS_IMPL);
> +     if (!(ret & 0x1))
> +             writel((ret | 0x1), mmio + HOST_PORTS_IMPL);

ditto.

> +
> +     ahb_clk = devm_clk_get(dev, "ahb");
> +     if (IS_ERR(ahb_clk)) {
> +             dev_err(dev, "no ahb clock.\n");
> +             return PTR_ERR(ahb_clk);
> +     }

This leaves the phy clock enabled in the error case.
[Richard] Yes, it is. the phy clock should be disabled.

> +     ret = clk_get_rate(ahb_clk) / 1000;
> +     writel(ret, mmio + HOST_TIMER1MS);
> +     devm_clk_put(dev, ahb_clk);
> +
> +     return 0;
> +}
> +
> +static void imx6q_sata_exit(struct device *dev)
> +{
> +     struct regmap *gpr;
> +
> +     gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +     if (IS_ERR(gpr))
> +             dev_err(dev, "failed to find fsl,imx6q-iomux-gpr regmap\n");
> +
> +     regmap_update_bits(gpr, 0x34, IMX6Q_GPR13_SATA_MPLL_CLK_EN,
> +                     !IMX6Q_GPR13_SATA_MPLL_CLK_EN);
> +
> +     imx6q_sata_phy_clk(dev, false);
> +}
> +
> +static struct ahci_platform_data imx6q_sata_pdata = {
> +     .init = imx6q_sata_init,
> +     .exit = imx6q_sata_exit,
> +};
> +static const struct of_device_id imx_ahci_of_match[] = {
> +     { .compatible = "fsl,imx6q-ahci", .data = &imx6q_sata_pdata},
> +     {},
> +};
> +MODULE_DEVICE_TABLE(of, imx_ahci_of_match);
> +
> +static void imx_ahci_platform_release(struct device *dev)
> +{
> +     return;
> +}
> +
> +static struct platform_device ahci_pdev = {
> +     .name = "ahci",
> +     .id = -1,
> +     .dev = {
> +             .release = imx_ahci_platform_release,
> +     }
> +};
> +
> +static int imx_ahci_probe(struct platform_device *pdev)
> +{
> +     struct device *dev = &pdev->dev;
> +     struct resource *mem, *irq, **res;
> +     const struct of_device_id *of_id;
> +     const struct ahci_platform_data *pdata = NULL;
> +     int ret;
> +
> +     of_id = of_match_device(imx_ahci_of_match, &pdev->dev);
> +     if (of_id)
> +             pdata = of_id->data;
> +     else
> +             return -EINVAL;
> +
> +     mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +     irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +     if (!mem || !irq) {
> +             dev_err(dev, "no mmio/irq resource\n");
> +             return -EINVAL;
> +     }
> +
> +     ahci_pdev.dev.coherent_dma_mask = DMA_BIT_MASK(32);
> +     ahci_pdev.dev.dma_mask = &ahci_pdev.dev.coherent_dma_mask;
> +     ahci_pdev.dev.of_node = pdev->dev.of_node;

No need to make ahci_pdev global. platform_device_add_data makes a copy
anyway and making it global makes this driver broken for multiple
instances.
[Richard]accepted.

> +
> +     res[0] = mem;
> +     res[1] = irq;

You have an uninitalized pointer to a pointer to struct resource which
you treat as an array here. Doesn't the compiler warn you?
[Richard]Compiler doesn't report the warning message, anyway, I would fix it later.

> +     platform_device_add_resources(&ahci_pdev, *res, 2);
> +     platform_device_add_data(&ahci_pdev, pdata, sizeof(*pdata));
> +
> +     ret = platform_device_register(&ahci_pdev);
> +     if (!ret)
> +             return ret;

s/!ret/ret/
[Richard] Would be fixed.

Sascha

--
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |




From r65037 at freescale.com  Fri Jul  5 21:55:19 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Sat, 6 Jul 2013 01:55:19 +0000
Subject: [v3 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <1373040406.217809169@f299.mail.ru>
References: <1373017942-12583-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373017942-12583-4-git-send-email-Hong-Xing.Zhu@freescale.com>
 <20130705155911.GK516@pengutronix.de>,<1373040406.217809169@f299.mail.ru>
Message-ID: <0E83723C55F66F43A6041464FE31119D31430A@039-SN2MPN1-012.039d.mgd.msft.net>

Hi Alexander:
Thanks for your comments.

Best Regards
Richard Zhu
________________________________________
From: Alexander Shiyan [shc_work at mail.ru]
Sent: Saturday, July 06, 2013 12:06 AM
To: Sascha Hauer
Cc: Richard Zhu; Zhu Richard-R65037; shawn.guo at linaro.org; rob.herring at calxeda.com; linux-ide at vger.kernel.org; avorontsov at ru.mvista.com; jgarzik at pobox.com; linux-arm-kernel at lists.infradead.org
Subject: Re[2]: [v3 3/3] sata: imx: add ahci sata support on imx platforms

> On Fri, Jul 05, 2013 at 05:52:22PM +0800, Richard Zhu wrote:
> > From: Richard Zhu <r65037 at freescale.com>
...
> > +   if (!(ret & HOST_CAP_SSS))
> > +           writel(ret |= HOST_CAP_SSS, mmio + HOST_CAP);
>
> Why do you write this conditionally? Just write it unconditionally.

"writel" with assignment is incorrect in any case.
[Richard] would be fixed later.

---



From r65037 at freescale.com  Fri Jul  5 22:03:30 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Sat, 6 Jul 2013 02:03:30 +0000
Subject: [v3 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <20130705174305.GA28088@mtj.dyndns.org>
References: <1373017942-12583-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373017942-12583-4-git-send-email-Hong-Xing.Zhu@freescale.com>,
 <20130705174305.GA28088@mtj.dyndns.org>
Message-ID: <0E83723C55F66F43A6041464FE31119D31432D@039-SN2MPN1-012.039d.mgd.msft.net>

Hi Tejun:
Thanks for your comments.

Best Regards
Richard Zhu
________________________________________
From: linux-ide-owner at vger.kernel.org [linux-ide-owner at vger.kernel.org] on behalf of Tejun Heo [tj at kernel.org]
Sent: Saturday, July 06, 2013 1:43 AM
To: Richard Zhu
Cc: shawn.guo at linaro.org; linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; avorontsov at ru.mvista.com; rob.herring at calxeda.com; s.hauer at pengutronix.de; linux-ide at vger.kernel.org; Zhu Richard-R65037
Subject: Re: [v3 3/3] sata: imx: add ahci sata support on imx platforms

Hello,

On Fri, Jul 05, 2013 at 05:52:22PM +0800, Richard Zhu wrote:
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>  value is '0', should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the
>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>  should be configured regarding to the frequency of AHB
>  bus clock.
>  - Configurations of the AHCI PHY clock, and the signal
>  parameters of the GPR13

Can't you just add a platform specific init callback to ahci_platform?
I don't see how these small differences in init sequence justify a
separate driver.
[Richard] Just like what we dicussed in the previous v1/v2 patch-set.
Shawn has the concerns that the IP speicific codes shouldn't be put in the platform level.
So he suggested that setup a stand-alone driver, contained the imx6q ahci sata specific
codes, and re-use the generic ahci_platform driver as much as possible.
This imx6q standalone ahci sata driver just registers the platform data, and the others would be handled
by ahci_platform driver.

Thanks.

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html




From tj at kernel.org  Fri Jul  5 22:07:37 2013
From: tj at kernel.org (Tejun Heo)
Date: Fri, 5 Jul 2013 19:07:37 -0700
Subject: [v3 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <0E83723C55F66F43A6041464FE31119D31432D@039-SN2MPN1-012.039d.mgd.msft.net>
References: <1373017942-12583-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373017942-12583-4-git-send-email-Hong-Xing.Zhu@freescale.com>
 <20130705174305.GA28088@mtj.dyndns.org>
 <0E83723C55F66F43A6041464FE31119D31432D@039-SN2MPN1-012.039d.mgd.msft.net>
Message-ID: <20130706020737.GA9029@mtj.dyndns.org>

Hello,

On Sat, Jul 06, 2013 at 02:03:30AM +0000, Zhu Richard-R65037 wrote:
> [Richard] Just like what we dicussed in the previous v1/v2
> patch-set.  Shawn has the concerns that the IP speicific codes
> shouldn't be put in the platform level.  So he suggested that setup
> a stand-alone driver, contained the imx6q ahci sata specific codes,
> and re-use the generic ahci_platform driver as much as possible.
> This imx6q standalone ahci sata driver just registers the platform
> data, and the others would be handled by ahci_platform driver.

Oh, I'm not objecting to the ahci specific part not being in platform
code.  I'm wondering whether specific handling for imx6q can be
included into ahci_platform rather than being in its own driver.  It
just seems that there aren't too many differences.  I could be
misreading it so if there are enough differences to warrant a separate
driver, please enlighten me.

Thanks!

-- 
tejun


From tom.leiming at gmail.com  Fri Jul  5 22:21:05 2013
From: tom.leiming at gmail.com (Ming Lei)
Date: Sat, 6 Jul 2013 10:21:05 +0800
Subject: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is
 64-bits
In-Reply-To: <51D71F81.5090503@codeaurora.org>
References: <1367008266-1431-1-git-send-email-lauraa@codeaurora.org>
 <517AF270.8040106@gmail.com>
 <CACVXFVPfkqP+UyoGd-+QFRzndSam_DtU=utrBPYCPjQCGQ_F6g@mail.gmail.com>
 <51D71F81.5090503@codeaurora.org>
Message-ID: <CACVXFVNT3j5o9a+N9FDA07Si+cngqAZkcqh6YYOf3rHsMvRgRg@mail.gmail.com>

On Sat, Jul 6, 2013 at 3:33 AM, Laura Abbott <lauraa at codeaurora.org> wrote:
> On 7/3/2013 7:15 AM, Ming Lei wrote:
>>
>> On Sat, Apr 27, 2013 at 5:32 AM, Rob Herring <robherring2 at gmail.com>
>> wrote:
>>>
>>> On 04/26/2013 03:31 PM, Laura Abbott wrote:
>>>>
>>>> Currently, of_platform_device_create_pdata always sets the
>>>> coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA,
>>>> arm_dma_limit gets set to ~0 or 0xFFFFFFFFFFFFFFFF on LPAE based
>>>> systems. Since arm_dma_limit represents the smallest dma_mask
>>>> on the system, the default of 32 bits prevents any dma_coherent
>>>> allocation from succeeding unless clients manually set the
>>>> dma mask first. Rather than make every client on an LPAE system set
>>>> the mask manually, account for the size of dma_addr_t when setting
>>>> the coherent mask.
>>>>
>>>> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
>>>> ---
>>>>   drivers/of/platform.c |    2 +-
>>>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>>>> index 0970505..5f0ba94 100644
>>>> --- a/drivers/of/platform.c
>>>> +++ b/drivers/of/platform.c
>>>> @@ -214,7 +214,7 @@ struct platform_device
>>>> *of_platform_device_create_pdata(
>>>>   #if defined(CONFIG_MICROBLAZE)
>>>>        dev->archdata.dma_mask = 0xffffffffUL;
>>>>   #endif
>>>> -     dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>>>> +     dev->dev.coherent_dma_mask = DMA_BIT_MASK(sizeof(dma_addr_t) * 8);
>>>
>>>
>>> This is going to change the mask from 32 to 64 bits on 64-bit powerpc
>>> and others possibly. Maybe it doesn't matter. I think it doesn't, but
>>> I'm not sure enough to apply for 3.10. So I'll queue it for 3.11.
>>
>>
>> Without the patch, LPAE enabled board may not boot at all, but looks
>> it still isn't in -next tree.
>>
>> But I am wondering if it is a correct approach, because enabling LPAE
>> doesn't mean the I/O devices can support DMA to/from 64bit address, and
>> it is very probably devices can't do it at all.
>>
>
> The problem is the way the arm_dma_limit is set up, all dma allocations are
> currently broken regardless of if the actual device supports 64-bit
> addresses or not.

Yes, I know, and since arm_dma_limit becomes 0xFFFFFFFFFFFFFFFF
now if LPAE is enabled and ZONE_DMA unset, so we have to set
dev->coherent_dma_mask as so big, otherwise __dma_alloc() can't go
ahead.

But please see below words in Documentation/DMA-API.txt:

           Further, the physical address of the memory must be within the
           dma_mask of the device (the dma_mask represents a bit mask of the
           addressable region for the device.  I.e., if the physical address of
           the memory anded with the dma_mask is still equal to the physical
           address, then the device can perform DMA to the memory).

You may argue that the description is about dev->dma_mask, but the
usage should be same.

In fact, most of devices in ARM SoC(even with LPAE enabled) doesn't
support 64bit DMA, so I don't see the point that the default mask is set
as 64bit.

Also we might need to consider why ppc64 didn't do that previously.

>
>
>> Another way is to always set arm_dma_limit as 0xFFFFFFFF when
>> CONFIG_ZONE_DMA is unset, and let driver override device's dma
>> mask if the device supports 64bit DMA.
>>
>
> I previously asked about the arm_dma_limit and was told that the current
> behavior is the correct approach (see
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-April/032729.html
> and
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-April/032690.html)
>
> The point here is to set the mask to something reasonable such that

Looks the default 64bit mask isn't reasonable, is it?

> allocations can succeed by default. If devices can't use part of the memory
> space they can adjust the limit accordingly.

No, device can't set the mask any more since any other value which is less
than (u64)-1 can't succeed, and looks that is the current problem.

Thanks,
-- 
Ming Lei


From shawn.guo at linaro.org  Fri Jul  5 23:15:59 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sat, 6 Jul 2013 11:15:59 +0800
Subject: [PATCH] ARM: dts: imx27 phyCARD-S remove wrong I2C RTC
In-Reply-To: <1373031909-16178-1-git-send-email-mpa@pengutronix.de>
References: <1372782469.486055292@f129.mail.ru>
 <1373031909-16178-1-git-send-email-mpa@pengutronix.de>
Message-ID: <20130706031557.GA30164@S2101-09.ap.freescale.net>

On Fri, Jul 05, 2013 at 03:45:09PM +0200, Markus Pargmann wrote:
> Fixup of commit 7874d595b78e431f0f661d2fe47625649308a52e

The commit ID is not stable.  I just dropped it and applied the patch.

Shawn

> "ARM: dts: Add device tree support for phycard pca100".
> 
> Remove wrong I2C RTC node.
> 
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> ---
> 
> Thanks, Alexander, you are right. I2C2 has no RTC.
> 
> Regards,
> 
> Markus
> 
>  arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts | 5 -----
>  1 file changed, 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
> index ec52b6d..01ee807 100644
> --- a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
> +++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
> @@ -55,11 +55,6 @@
>  		reg = <0x4a>;
>  	};
>  
> -	rtc at 51 {
> -		compatible = "nxp,pcf8563";
> -		reg = <0x51>;
> -	};
> -
>  	at24 at 52 {
>  		compatible = "at,24c32";
>  		pagesize = <32>;
> -- 
> 1.8.2.1
> 



From shawn.guo at linaro.org  Fri Jul  5 23:26:42 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sat, 6 Jul 2013 11:26:42 +0800
Subject: [PATCH] ARM: dts: imx6dl-wandboard: Add audio support
In-Reply-To: <1372964106-27928-1-git-send-email-fabio.estevam@freescale.com>
References: <1372964106-27928-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <20130706032641.GB30164@S2101-09.ap.freescale.net>

On Thu, Jul 04, 2013 at 03:55:06PM -0300, Fabio Estevam wrote:
> Wandboard has a sgtl5000 codec. 
> 
> Add audio support.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Applied, thanks.



From shc_work at mail.ru  Sat Jul  6 00:57:59 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat,  6 Jul 2013 08:57:59 +0400
Subject: [PATCH 2/3] input: mc13783: Add MC13892 support
In-Reply-To: <1373086680-31444-1-git-send-email-shc_work@mail.ru>
References: <1373086680-31444-1-git-send-email-shc_work@mail.ru>
Message-ID: <1373086680-31444-2-git-send-email-shc_work@mail.ru>


Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 drivers/input/misc/Kconfig             |  6 +++---
 drivers/input/misc/mc13783-pwrbutton.c | 10 +++++++++-
 include/linux/mfd/mc13892.h            |  4 ++++
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 0b541cd..0d83653 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -167,10 +167,10 @@ config INPUT_MAX8997_HAPTIC
 	  module will be called max8997-haptic.
 
 config INPUT_MC13783_PWRBUTTON
-	tristate "MC13783 ON buttons"
-	depends on MFD_MC13783
+	tristate "MC13783/MC13892 ON buttons"
+	depends on MFD_MC13XXX
 	help
-	  Support the ON buttons of MC13783 PMIC as an input device
+	  Support the ON buttons of MC13783/MC13892 PMIC as an input device
 	  reporting power button status.
 
 	  To compile this driver as a module, choose M here: the module
diff --git a/drivers/input/misc/mc13783-pwrbutton.c b/drivers/input/misc/mc13783-pwrbutton.c
index 33613ca..855d576 100644
--- a/drivers/input/misc/mc13783-pwrbutton.c
+++ b/drivers/input/misc/mc13783-pwrbutton.c
@@ -26,6 +26,7 @@
 #include <linux/input.h>
 #include <linux/platform_device.h>
 #include <linux/mfd/mc13783.h>
+#include <linux/mfd/mc13892.h>
 
 struct mc13xxx_button_def {
 	unsigned int	irq;
@@ -194,8 +195,15 @@ static const struct mc13xxx_pwrb_devtype mc13783_pwrb_devtype = {
 	.btn_def[2] = { MC13783_IRQ_ONOFD3, BIT(5) }
 };
 
+static const struct mc13xxx_pwrb_devtype mc13892_pwrb_devtype = {
+	.btn_def[0] = { MC13892_IRQ_ONOFD1, BIT(3) },
+	.btn_def[1] = { MC13892_IRQ_ONOFD2, BIT(4) },
+	.btn_def[2] = { MC13892_IRQ_ONOFD3, BIT(2) }
+};
+
 static const struct platform_device_id mc13xxx_pwrbutton_id_table[] = {
 	{ "mc13783-pwrbutton", (kernel_ulong_t)&mc13783_pwrb_devtype },
+	{ "mc13892-pwrbutton", (kernel_ulong_t)&mc13892_pwrb_devtype },
 	{ }
 };
 MODULE_DEVICE_TABLE(platform, mc13xxx_pwrbutton_id_table);
@@ -209,6 +217,6 @@ static struct platform_driver mc13xxx_pwrbutton_driver = {
 };
 module_platform_driver_probe(mc13xxx_pwrbutton_driver, mc13xxx_pwrbutton_probe);
 
-MODULE_DESCRIPTION("MC13783 Power Button");
+MODULE_DESCRIPTION("MC13XXX Power Button");
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Philippe Retornaz");
diff --git a/include/linux/mfd/mc13892.h b/include/linux/mfd/mc13892.h
index a00f2be..bdc3baf 100644
--- a/include/linux/mfd/mc13892.h
+++ b/include/linux/mfd/mc13892.h
@@ -36,4 +36,8 @@
 #define MC13892_PWGT2SPI	22
 #define MC13892_VCOINCELL	23
 
+#define MC13892_IRQ_ONOFD3	26
+#define MC13892_IRQ_ONOFD1	27
+#define MC13892_IRQ_ONOFD2	28
+
 #endif
-- 
1.8.1.5



From shc_work at mail.ru  Sat Jul  6 00:58:00 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat,  6 Jul 2013 08:58:00 +0400
Subject: [PATCH 3/3] input: mc13783: Add DT probe support
In-Reply-To: <1373086680-31444-1-git-send-email-shc_work@mail.ru>
References: <1373086680-31444-1-git-send-email-shc_work@mail.ru>
Message-ID: <1373086680-31444-3-git-send-email-shc_work@mail.ru>

Patch adds DT support for MC13783/MC13892 PMICs.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 Documentation/devicetree/bindings/mfd/mc13xxx.txt | 12 +++++
 drivers/input/misc/mc13783-pwrbutton.c            | 59 ++++++++++++++++++-----
 2 files changed, 58 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/mc13xxx.txt b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
index abd9e3c..967bed6 100644
--- a/Documentation/devicetree/bindings/mfd/mc13xxx.txt
+++ b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
@@ -10,6 +10,11 @@ Optional properties:
 - fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used
 
 Sub-nodes:
+- buttons : Contain power button nodes. Each button should be declared as
+  "btn<num>" and contain code in "linux,code" property. Optional properties:
+    active-high : Change active button level from 0 to 1.
+    enable-reset: Performs hadware reset through PMIC.
+    debounce    : Debounce value which will be taken from PMIC datasheet.
 - regulators : Contain the regulator nodes. The regulators are bound using
   their names as listed below with their registers and bits for enabling.
 
@@ -89,6 +94,13 @@ ecspi at 70010000 { /* ECSPI1 */
 		interrupt-parent = <&gpio0>;
 		interrupts = <8>;
 
+		buttons {
+			btn1 {
+				linux,code = <0x1f>;
+				debounce = <1>;
+			};
+		};
+
 		regulators {
 			sw1_reg: mc13892__sw1 {
 				regulator-min-microvolt = <600000>;
diff --git a/drivers/input/misc/mc13783-pwrbutton.c b/drivers/input/misc/mc13783-pwrbutton.c
index 855d576..05bb570 100644
--- a/drivers/input/misc/mc13783-pwrbutton.c
+++ b/drivers/input/misc/mc13783-pwrbutton.c
@@ -24,6 +24,7 @@
 #include <linux/kernel.h>
 #include <linux/errno.h>
 #include <linux/input.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/mfd/mc13783.h>
 #include <linux/mfd/mc13892.h>
@@ -121,21 +122,28 @@ static int __init mc13xxx_pwrbutton_probe(struct platform_device *pdev)
 	struct mc13xxx *mc13xxx = dev_get_drvdata(pdev->dev.parent);
 	struct mc13xxx_pwrb_devtype *devtype =
 		(struct mc13xxx_pwrb_devtype *)pdev->id_entry->driver_data;
+	struct device_node *parent, *child;
 	struct mc13xxx_pwrb *priv;
 	int i, reg = 0, ret = -EINVAL;
 
-	if (!pdata) {
+	of_node_get(pdev->dev.parent->of_node);
+	parent = of_find_node_by_name(pdev->dev.parent->of_node, "buttons");
+	if (!pdata && !parent) {
 		dev_err(&pdev->dev, "Missing platform data\n");
 		return -ENODEV;
 	}
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
-	if (!priv)
-		return -ENOMEM;
+	if (!priv) {
+		ret = -ENOMEM;
+		goto out_node_put;
+	}
 
 	priv->input = devm_input_allocate_device(&pdev->dev);
-	if (!priv->input)
-		return -ENOMEM;
+	if (!priv->input) {
+		ret = -ENOMEM;
+		goto out_node_put;
+	}
 
 	priv->mc13xxx = mc13xxx;
 	priv->devtype = devtype;
@@ -143,15 +151,36 @@ static int __init mc13xxx_pwrbutton_probe(struct platform_device *pdev)
 
 	for (i = 0; i < MAX13XXX_NUM_BUTTONS; i++) {
 		u16 code, invert, reset, debounce;
+		const __be32 *prop;
+		char childname[5];
 
-		if (!(pdata->buttons[i].flags & MC13XXX_BUTTON_ENABLE))
-			continue;
-		code = pdata->buttons[i].keycode;
-		invert = !!(pdata->buttons[i].flags &
-			    MC13XXX_BUTTON_POL_INVERT);
-		reset = !!(pdata->buttons[i].flags &
-			   MC13XXX_BUTTON_RESET_EN);
-		debounce = pdata->buttons[i].flags;
+		if (parent) {
+			sprintf(childname, "btn%i", i + 1);
+			child = of_get_child_by_name(parent, childname);
+			if (!child)
+				continue;
+			prop = of_get_property(child, "linux,code", NULL);
+			if (prop)
+				code = be32_to_cpu(*prop) & 0xffff;
+			else {
+				dev_err(&pdev->dev,
+					"Button %i: Missing key code\n", i + 1);
+				continue;
+			}
+			invert = !!of_get_property(child, "active-high", NULL);
+			reset = !!of_get_property(child, "enable-reset", NULL);
+			prop = of_get_property(child, "debounce", NULL);
+			debounce = prop ? be32_to_cpu(*prop) : 0;
+		} else {
+			if (!(pdata->buttons[i].flags & MC13XXX_BUTTON_ENABLE))
+				continue;
+			code = pdata->buttons[i].keycode;
+			invert = !!(pdata->buttons[i].flags &
+				    MC13XXX_BUTTON_POL_INVERT);
+			reset = !!(pdata->buttons[i].flags &
+				   MC13XXX_BUTTON_RESET_EN);
+			debounce = pdata->buttons[i].flags;
+		}
 
 		priv->btn_code[i] = code;
 		if (code != KEY_RESERVED)
@@ -186,6 +215,10 @@ static int __init mc13xxx_pwrbutton_probe(struct platform_device *pdev)
 	if (ret)
 		dev_err(&pdev->dev, "Can't register input device: %i\n", ret);
 
+out_node_put:
+	if (parent)
+		of_node_put(parent);
+
 	return ret;
 }
 
-- 
1.8.1.5



From shc_work at mail.ru  Sat Jul  6 00:57:58 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat,  6 Jul 2013 08:57:58 +0400
Subject: [PATCH 1/3] input: mc13783: Prepare driver to support MC13892 and OF
Message-ID: <1373086680-31444-1-git-send-email-shc_work@mail.ru>

This patch is a preparation mc13xxx powerbutton driver to support
MC13892 and support the probe through the DT.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/mach-imx/mach-mx31moboard.c   |   9 +-
 drivers/input/misc/mc13783-pwrbutton.c | 361 ++++++++++++++-------------------
 include/linux/mfd/mc13xxx.h            |  28 +--
 3 files changed, 173 insertions(+), 225 deletions(-)

diff --git a/arch/arm/mach-imx/mach-mx31moboard.c b/arch/arm/mach-imx/mach-mx31moboard.c
index 6f424ec..2a8aa43 100644
--- a/arch/arm/mach-imx/mach-mx31moboard.c
+++ b/arch/arm/mach-imx/mach-mx31moboard.c
@@ -276,9 +276,12 @@ static struct mc13xxx_leds_platform_data moboard_leds = {
 };
 
 static struct mc13xxx_buttons_platform_data moboard_buttons = {
-	.b1on_flags = MC13783_BUTTON_DBNC_750MS | MC13783_BUTTON_ENABLE |
-			MC13783_BUTTON_POL_INVERT,
-	.b1on_key = KEY_POWER,
+	.buttons[0] = {
+		.keycode	= KEY_POWER,
+		.flags		= MC13XXX_BUTTON_ENABLE |
+				  MC13XXX_BUTTON_DBNC_750MS |
+				  MC13XXX_BUTTON_POL_INVERT,
+	},
 };
 
 static struct mc13xxx_codec_platform_data moboard_codec = {
diff --git a/drivers/input/misc/mc13783-pwrbutton.c b/drivers/input/misc/mc13783-pwrbutton.c
index d0277a7..33613ca 100644
--- a/drivers/input/misc/mc13783-pwrbutton.c
+++ b/drivers/input/misc/mc13783-pwrbutton.c
@@ -24,248 +24,191 @@
 #include <linux/kernel.h>
 #include <linux/errno.h>
 #include <linux/input.h>
-#include <linux/interrupt.h>
 #include <linux/platform_device.h>
 #include <linux/mfd/mc13783.h>
-#include <linux/sched.h>
-#include <linux/slab.h>
-
-struct mc13783_pwrb {
-	struct input_dev *pwr;
-	struct mc13xxx *mc13783;
-#define MC13783_PWRB_B1_POL_INVERT	(1 << 0)
-#define MC13783_PWRB_B2_POL_INVERT	(1 << 1)
-#define MC13783_PWRB_B3_POL_INVERT	(1 << 2)
-	int flags;
-	unsigned short keymap[3];
+
+struct mc13xxx_button_def {
+	unsigned int	irq;
+	unsigned int	sense_bit;
 };
 
-#define MC13783_REG_INTERRUPT_SENSE_1		5
-#define MC13783_IRQSENSE1_ONOFD1S		(1 << 3)
-#define MC13783_IRQSENSE1_ONOFD2S		(1 << 4)
-#define MC13783_IRQSENSE1_ONOFD3S		(1 << 5)
+struct mc13xxx_pwrb_devtype {
+	struct mc13xxx_button_def	btn_def[MAX13XXX_NUM_BUTTONS];
+};
 
-#define MC13783_REG_POWER_CONTROL_2		15
-#define MC13783_POWER_CONTROL_2_ON1BDBNC	4
-#define MC13783_POWER_CONTROL_2_ON2BDBNC	6
-#define MC13783_POWER_CONTROL_2_ON3BDBNC	8
-#define MC13783_POWER_CONTROL_2_ON1BRSTEN	(1 << 1)
-#define MC13783_POWER_CONTROL_2_ON2BRSTEN	(1 << 2)
-#define MC13783_POWER_CONTROL_2_ON3BRSTEN	(1 << 3)
+struct mc13xxx_pwrb {
+	struct mc13xxx_pwrb_devtype	*devtype;
+	unsigned int			enabled;
+	unsigned int			inverted;
+	u16				btn_code[MAX13XXX_NUM_BUTTONS];
+	struct input_dev		*input;
+	struct mc13xxx			*mc13xxx;
+};
 
-static irqreturn_t button_irq(int irq, void *_priv)
-{
-	struct mc13783_pwrb *priv = _priv;
-	int val;
-
-	mc13xxx_irq_ack(priv->mc13783, irq);
-	mc13xxx_reg_read(priv->mc13783, MC13783_REG_INTERRUPT_SENSE_1, &val);
-
-	switch (irq) {
-	case MC13783_IRQ_ONOFD1:
-		val = val & MC13783_IRQSENSE1_ONOFD1S ? 1 : 0;
-		if (priv->flags & MC13783_PWRB_B1_POL_INVERT)
-			val ^= 1;
-		input_report_key(priv->pwr, priv->keymap[0], val);
-		break;
-
-	case MC13783_IRQ_ONOFD2:
-		val = val & MC13783_IRQSENSE1_ONOFD2S ? 1 : 0;
-		if (priv->flags & MC13783_PWRB_B2_POL_INVERT)
-			val ^= 1;
-		input_report_key(priv->pwr, priv->keymap[1], val);
-		break;
-
-	case MC13783_IRQ_ONOFD3:
-		val = val & MC13783_IRQSENSE1_ONOFD3S ? 1 : 0;
-		if (priv->flags & MC13783_PWRB_B3_POL_INVERT)
-			val ^= 1;
-		input_report_key(priv->pwr, priv->keymap[2], val);
-		break;
-	}
+#define MC13XXX_REG_INTERRUPT_SENSE_1	5
+#define MC13XXX_REG_POWER_CONTROL_2	15
 
-	input_sync(priv->pwr);
+static irqreturn_t mc13xxx_pwrbutton_irq(int irq, void *data)
+{
+	struct mc13xxx_pwrb *priv = data;
+	unsigned int i, val;
+
+	mc13xxx_irq_ack(priv->mc13xxx, irq);
+	mc13xxx_reg_read(priv->mc13xxx, MC13XXX_REG_INTERRUPT_SENSE_1, &val);
+ 
+	for (i = 0; i < MAX13XXX_NUM_BUTTONS; i++)
+		if (irq == priv->devtype->btn_def[i].irq) {
+			val = !!(val & priv->devtype->btn_def[i].sense_bit);
+			if (priv->inverted & BIT(i))
+				val = !val;
+			input_report_key(priv->input, priv->btn_code[i], val);
+			input_sync(priv->input);
+			break;
+		}
 
 	return IRQ_HANDLED;
 }
 
-static int mc13783_pwrbutton_probe(struct platform_device *pdev)
+static int mc13xxx_pwrbutton_open(struct input_dev *dev)
 {
-	const struct mc13xxx_buttons_platform_data *pdata;
-	struct mc13xxx *mc13783 = dev_get_drvdata(pdev->dev.parent);
-	struct input_dev *pwr;
-	struct mc13783_pwrb *priv;
-	int err = 0;
-	int reg = 0;
-
-	pdata = dev_get_platdata(&pdev->dev);
-	if (!pdata) {
-		dev_err(&pdev->dev, "missing platform data\n");
-		return -ENODEV;
-	}
-
-	pwr = input_allocate_device();
-	if (!pwr) {
-		dev_dbg(&pdev->dev, "Can't allocate power button\n");
-		return -ENOMEM;
-	}
-
-	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
-	if (!priv) {
-		err = -ENOMEM;
-		dev_dbg(&pdev->dev, "Can't allocate power button\n");
-		goto free_input_dev;
-	}
-
-	reg |= (pdata->b1on_flags & 0x3) << MC13783_POWER_CONTROL_2_ON1BDBNC;
-	reg |= (pdata->b2on_flags & 0x3) << MC13783_POWER_CONTROL_2_ON2BDBNC;
-	reg |= (pdata->b3on_flags & 0x3) << MC13783_POWER_CONTROL_2_ON3BDBNC;
-
-	priv->pwr = pwr;
-	priv->mc13783 = mc13783;
-
-	mc13xxx_lock(mc13783);
-
-	if (pdata->b1on_flags & MC13783_BUTTON_ENABLE) {
-		priv->keymap[0] = pdata->b1on_key;
-		if (pdata->b1on_key != KEY_RESERVED)
-			__set_bit(pdata->b1on_key, pwr->keybit);
-
-		if (pdata->b1on_flags & MC13783_BUTTON_POL_INVERT)
-			priv->flags |= MC13783_PWRB_B1_POL_INVERT;
-
-		if (pdata->b1on_flags & MC13783_BUTTON_RESET_EN)
-			reg |= MC13783_POWER_CONTROL_2_ON1BRSTEN;
-
-		err = mc13xxx_irq_request(mc13783, MC13783_IRQ_ONOFD1,
-					  button_irq, "b1on", priv);
-		if (err) {
-			dev_dbg(&pdev->dev, "Can't request irq\n");
-			goto free_priv;
+	struct mc13xxx_pwrb *priv = input_get_drvdata(dev);
+	int i, ret = 0;
+
+	mc13xxx_lock(priv->mc13xxx);
+
+	for (i = 0; i < MAX13XXX_NUM_BUTTONS; i++)
+		if (priv->enabled & BIT(i)) {
+			ret = mc13xxx_irq_request(priv->mc13xxx,
+						  priv->devtype->btn_def[i].irq,
+						  mc13xxx_pwrbutton_irq, NULL,
+						  priv);
+			if (!ret)
+				continue;
+
+			dev_err(&dev->dev, "Can't request IRQ: %i\n", ret);
+			
+			while (--i >= 0)
+				if (priv->enabled & BIT(i))
+					mc13xxx_irq_free(priv->mc13xxx,
+						 priv->devtype->btn_def[i].irq,
+						 priv);
+			break;
 		}
-	}
-
-	if (pdata->b2on_flags & MC13783_BUTTON_ENABLE) {
-		priv->keymap[1] = pdata->b2on_key;
-		if (pdata->b2on_key != KEY_RESERVED)
-			__set_bit(pdata->b2on_key, pwr->keybit);
 
-		if (pdata->b2on_flags & MC13783_BUTTON_POL_INVERT)
-			priv->flags |= MC13783_PWRB_B2_POL_INVERT;
+	mc13xxx_unlock(priv->mc13xxx);
 
-		if (pdata->b2on_flags & MC13783_BUTTON_RESET_EN)
-			reg |= MC13783_POWER_CONTROL_2_ON2BRSTEN;
-
-		err = mc13xxx_irq_request(mc13783, MC13783_IRQ_ONOFD2,
-					  button_irq, "b2on", priv);
-		if (err) {
-			dev_dbg(&pdev->dev, "Can't request irq\n");
-			goto free_irq_b1;
-		}
-	}
-
-	if (pdata->b3on_flags & MC13783_BUTTON_ENABLE) {
-		priv->keymap[2] = pdata->b3on_key;
-		if (pdata->b3on_key != KEY_RESERVED)
-			__set_bit(pdata->b3on_key, pwr->keybit);
+	return ret;
+}
 
-		if (pdata->b3on_flags & MC13783_BUTTON_POL_INVERT)
-			priv->flags |= MC13783_PWRB_B3_POL_INVERT;
+static void mc13xxx_pwrbutton_close(struct input_dev *dev)
+{
+	struct mc13xxx_pwrb *priv = input_get_drvdata(dev);
+	int i;
+
+	mc13xxx_lock(priv->mc13xxx);
+	for (i = 0; i < MAX13XXX_NUM_BUTTONS; i++)
+		if (priv->enabled & BIT(i))
+			mc13xxx_irq_free(priv->mc13xxx,
+					 priv->devtype->btn_def[i].irq, priv);
+	mc13xxx_unlock(priv->mc13xxx);
+}
 
-		if (pdata->b3on_flags & MC13783_BUTTON_RESET_EN)
-			reg |= MC13783_POWER_CONTROL_2_ON3BRSTEN;
+static int __init mc13xxx_pwrbutton_probe(struct platform_device *pdev)
+{
+	struct mc13xxx_buttons_platform_data *pdata =
+		dev_get_platdata(&pdev->dev);
+	struct mc13xxx *mc13xxx = dev_get_drvdata(pdev->dev.parent);
+	struct mc13xxx_pwrb_devtype *devtype =
+		(struct mc13xxx_pwrb_devtype *)pdev->id_entry->driver_data;
+	struct mc13xxx_pwrb *priv;
+	int i, reg = 0, ret = -EINVAL;
 
-		err = mc13xxx_irq_request(mc13783, MC13783_IRQ_ONOFD3,
-					  button_irq, "b3on", priv);
-		if (err) {
-			dev_dbg(&pdev->dev, "Can't request irq: %d\n", err);
-			goto free_irq_b2;
-		}
+	if (!pdata) {
+		dev_err(&pdev->dev, "Missing platform data\n");
+		return -ENODEV;
 	}
 
-	mc13xxx_reg_rmw(mc13783, MC13783_REG_POWER_CONTROL_2, 0x3FE, reg);
-
-	mc13xxx_unlock(mc13783);
-
-	pwr->name = "mc13783_pwrbutton";
-	pwr->phys = "mc13783_pwrbutton/input0";
-	pwr->dev.parent = &pdev->dev;
-
-	pwr->keycode = priv->keymap;
-	pwr->keycodemax = ARRAY_SIZE(priv->keymap);
-	pwr->keycodesize = sizeof(priv->keymap[0]);
-	__set_bit(EV_KEY, pwr->evbit);
+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
 
-	err = input_register_device(pwr);
-	if (err) {
-		dev_dbg(&pdev->dev, "Can't register power button: %d\n", err);
-		goto free_irq;
-	}
+	priv->input = devm_input_allocate_device(&pdev->dev);
+	if (!priv->input)
+		return -ENOMEM;
 
+	priv->mc13xxx = mc13xxx;
+	priv->devtype = devtype;
 	platform_set_drvdata(pdev, priv);
 
-	return 0;
-
-free_irq:
-	mc13xxx_lock(mc13783);
-
-	if (pdata->b3on_flags & MC13783_BUTTON_ENABLE)
-		mc13xxx_irq_free(mc13783, MC13783_IRQ_ONOFD3, priv);
-
-free_irq_b2:
-	if (pdata->b2on_flags & MC13783_BUTTON_ENABLE)
-		mc13xxx_irq_free(mc13783, MC13783_IRQ_ONOFD2, priv);
-
-free_irq_b1:
-	if (pdata->b1on_flags & MC13783_BUTTON_ENABLE)
-		mc13xxx_irq_free(mc13783, MC13783_IRQ_ONOFD1, priv);
-
-free_priv:
-	mc13xxx_unlock(mc13783);
-	kfree(priv);
-
-free_input_dev:
-	input_free_device(pwr);
+	for (i = 0; i < MAX13XXX_NUM_BUTTONS; i++) {
+		u16 code, invert, reset, debounce;
+
+		if (!(pdata->buttons[i].flags & MC13XXX_BUTTON_ENABLE))
+			continue;
+		code = pdata->buttons[i].keycode;
+		invert = !!(pdata->buttons[i].flags &
+			    MC13XXX_BUTTON_POL_INVERT);
+		reset = !!(pdata->buttons[i].flags &
+			   MC13XXX_BUTTON_RESET_EN);
+		debounce = pdata->buttons[i].flags;
+
+		priv->btn_code[i] = code;
+		if (code != KEY_RESERVED)
+			__set_bit(code, priv->input->keybit);
+
+		priv->enabled |= BIT(i);
+		priv->inverted |= invert << i;
+		reg |= reset << (i + 1);
+		reg |= (debounce & 0x03) << (4 + i * 2);
+	}
 
-	return err;
+	mc13xxx_lock(mc13xxx);
+	mc13xxx_reg_rmw(mc13xxx, MC13XXX_REG_POWER_CONTROL_2, 0x3fe, reg);
+	mc13xxx_unlock(mc13xxx);
+
+	priv->input->name		= "mc13xxx_pwrbutton";
+	priv->input->phys		= "mc13xxx_pwrbutton/input0";
+	priv->input->id.bustype		= BUS_HOST;
+	priv->input->id.vendor		= 0x0001;
+	priv->input->id.product		= 0x0001;
+	priv->input->id.version		= 0x0100;
+	priv->input->keycode		= priv->btn_code;
+	priv->input->keycodemax		= ARRAY_SIZE(priv->btn_code);
+	priv->input->keycodesize	= sizeof(priv->btn_code[0]);
+	priv->input->open		= mc13xxx_pwrbutton_open;
+	priv->input->close		= mc13xxx_pwrbutton_close;
+	__set_bit(EV_KEY, priv->input->evbit);
+
+	input_set_drvdata(priv->input, priv);
+
+	ret = input_register_device(priv->input);
+	if (ret)
+		dev_err(&pdev->dev, "Can't register input device: %i\n", ret);
+
+	return ret;
 }
 
-static int mc13783_pwrbutton_remove(struct platform_device *pdev)
-{
-	struct mc13783_pwrb *priv = platform_get_drvdata(pdev);
-	const struct mc13xxx_buttons_platform_data *pdata;
-
-	pdata = dev_get_platdata(&pdev->dev);
-
-	mc13xxx_lock(priv->mc13783);
-
-	if (pdata->b3on_flags & MC13783_BUTTON_ENABLE)
-		mc13xxx_irq_free(priv->mc13783, MC13783_IRQ_ONOFD3, priv);
-	if (pdata->b2on_flags & MC13783_BUTTON_ENABLE)
-		mc13xxx_irq_free(priv->mc13783, MC13783_IRQ_ONOFD2, priv);
-	if (pdata->b1on_flags & MC13783_BUTTON_ENABLE)
-		mc13xxx_irq_free(priv->mc13783, MC13783_IRQ_ONOFD1, priv);
-
-	mc13xxx_unlock(priv->mc13783);
-
-	input_unregister_device(priv->pwr);
-	kfree(priv);
+static const struct mc13xxx_pwrb_devtype mc13783_pwrb_devtype = {
+	.btn_def[0] = { MC13783_IRQ_ONOFD1, BIT(3) },
+	.btn_def[1] = { MC13783_IRQ_ONOFD2, BIT(4) },
+	.btn_def[2] = { MC13783_IRQ_ONOFD3, BIT(5) }
+};
 
-	return 0;
-}
+static const struct platform_device_id mc13xxx_pwrbutton_id_table[] = {
+	{ "mc13783-pwrbutton", (kernel_ulong_t)&mc13783_pwrb_devtype },
+	{ }
+};
+MODULE_DEVICE_TABLE(platform, mc13xxx_pwrbutton_id_table);
 
-static struct platform_driver mc13783_pwrbutton_driver = {
-	.probe		= mc13783_pwrbutton_probe,
-	.remove		= mc13783_pwrbutton_remove,
-	.driver		= {
-		.name	= "mc13783-pwrbutton",
+static struct platform_driver mc13xxx_pwrbutton_driver = {
+	.driver	= {
+		.name	= "mc13xxx-pwrbutton",
 		.owner	= THIS_MODULE,
 	},
+	.id_table	= mc13xxx_pwrbutton_id_table,
 };
+module_platform_driver_probe(mc13xxx_pwrbutton_driver, mc13xxx_pwrbutton_probe);
 
-module_platform_driver(mc13783_pwrbutton_driver);
-
-MODULE_ALIAS("platform:mc13783-pwrbutton");
 MODULE_DESCRIPTION("MC13783 Power Button");
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Philippe Retornaz");
diff --git a/include/linux/mfd/mc13xxx.h b/include/linux/mfd/mc13xxx.h
index 41ed592..b895538 100644
--- a/include/linux/mfd/mc13xxx.h
+++ b/include/linux/mfd/mc13xxx.h
@@ -142,20 +142,22 @@ struct mc13xxx_leds_platform_data {
 	u32 led_control[MAX_LED_CONTROL_REGS];
 };
 
+#define MAX13XXX_NUM_BUTTONS	3
+
+struct mc13xxx_button {
+	u16		keycode;
+	unsigned int	flags;
+#define MC13XXX_BUTTON_DBNC_0MS		0
+#define MC13XXX_BUTTON_DBNC_30MS	1
+#define MC13XXX_BUTTON_DBNC_150MS	2
+#define MC13XXX_BUTTON_DBNC_750MS	3
+#define MC13XXX_BUTTON_ENABLE		(1 << 2)
+#define MC13XXX_BUTTON_POL_INVERT	(1 << 3)
+#define MC13XXX_BUTTON_RESET_EN		(1 << 4)
+};
+
 struct mc13xxx_buttons_platform_data {
-#define MC13783_BUTTON_DBNC_0MS		0
-#define MC13783_BUTTON_DBNC_30MS	1
-#define MC13783_BUTTON_DBNC_150MS	2
-#define MC13783_BUTTON_DBNC_750MS	3
-#define MC13783_BUTTON_ENABLE		(1 << 2)
-#define MC13783_BUTTON_POL_INVERT	(1 << 3)
-#define MC13783_BUTTON_RESET_EN		(1 << 4)
-	int b1on_flags;
-	unsigned short b1on_key;
-	int b2on_flags;
-	unsigned short b2on_key;
-	int b3on_flags;
-	unsigned short b3on_key;
+	struct mc13xxx_button	buttons[MAX13XXX_NUM_BUTTONS];
 };
 
 struct mc13xxx_ts_platform_data {
-- 
1.8.1.5



From shawn.guo at linaro.org  Sat Jul  6 01:08:05 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sat, 6 Jul 2013 13:08:05 +0800
Subject: [PATCH v3 4/6] ARM: dts: imx6q{dl}: fix the wrong RTS/CTS pad name
In-Reply-To: <1373004752-21302-5-git-send-email-b32955@freescale.com>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>
 <1373004752-21302-5-git-send-email-b32955@freescale.com>
Message-ID: <20130706050803.GC30164@S2101-09.ap.freescale.net>

On Fri, Jul 05, 2013 at 02:12:30PM +0800, Huang Shijie wrote:
> There is something wrong with the RTS/CTS pads:
>   The RTS pad is assigned with the CTS's value;
>   while the CTS pad is assigned with the RTS's value.
> 

So basically, you are saying that select_input should be set up for CTS
rather than RTS.  It seems that the people who generated the macro got
the wrong input from developer.

So imx6sl-pinfunc.h also needs to be fixed up.

Shawn

> In order to fix it, this patch exchanges the RTS/CTS pad name.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>
> ---
>  arch/arm/boot/dts/imx6dl-pinfunc.h |   88 ++++++++++++++++++------------------
>  arch/arm/boot/dts/imx6q-pinfunc.h  |   88 ++++++++++++++++++------------------
>  2 files changed, 88 insertions(+), 88 deletions(-)



From shawn.guo at linaro.org  Sat Jul  6 01:13:45 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sat, 6 Jul 2013 13:13:45 +0800
Subject: [PATCH] dma: imx-sdma: remove the unused completion
In-Reply-To: <1373010655-3800-1-git-send-email-b32955@freescale.com>
References: <1373010655-3800-1-git-send-email-b32955@freescale.com>
Message-ID: <20130706051343.GD30164@S2101-09.ap.freescale.net>

On Fri, Jul 05, 2013 at 03:50:55PM +0800, Huang Shijie wrote:
> After the patch: "2ccaef0 dma: imx-sdma: make channel0 operations atomic",
> the "done" completion is not used any more.
> 
> Just remove it.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>

Acked-by: Shawn Guo <shawn.guo at linaro.org>



From michael.opdenacker at free-electrons.com  Sat Jul  6 01:15:30 2013
From: michael.opdenacker at free-electrons.com (Michael Opdenacker)
Date: Sat,  6 Jul 2013 07:15:30 +0200
Subject: [PATCH] ARM: at91: remove IRQF_DISABLED
Message-ID: <1373087730-19917-1-git-send-email-michael.opdenacker@free-electrons.com>

This flag is a NOOP since 2.6.36 and can be removed.

Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>
---
 arch/arm/mach-at91/at91rm9200_time.c  | 2 +-
 arch/arm/mach-at91/at91sam926x_time.c | 2 +-
 arch/arm/mach-at91/at91x40_time.c     | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-at91/at91rm9200_time.c b/arch/arm/mach-at91/at91rm9200_time.c
index 180b302..f607deb 100644
--- a/arch/arm/mach-at91/at91rm9200_time.c
+++ b/arch/arm/mach-at91/at91rm9200_time.c
@@ -93,7 +93,7 @@ static irqreturn_t at91rm9200_timer_interrupt(int irq, void *dev_id)
 
 static struct irqaction at91rm9200_timer_irq = {
 	.name		= "at91_tick",
-	.flags		= IRQF_SHARED | IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+	.flags		= IRQF_SHARED | IRQF_TIMER | IRQF_IRQPOLL,
 	.handler	= at91rm9200_timer_interrupt,
 	.irq		= NR_IRQS_LEGACY + AT91_ID_SYS,
 };
diff --git a/arch/arm/mach-at91/at91sam926x_time.c b/arch/arm/mach-at91/at91sam926x_time.c
index 3a4bc2e..bb39232 100644
--- a/arch/arm/mach-at91/at91sam926x_time.c
+++ b/arch/arm/mach-at91/at91sam926x_time.c
@@ -171,7 +171,7 @@ static irqreturn_t at91sam926x_pit_interrupt(int irq, void *dev_id)
 
 static struct irqaction at91sam926x_pit_irq = {
 	.name		= "at91_tick",
-	.flags		= IRQF_SHARED | IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+	.flags		= IRQF_SHARED | IRQF_TIMER | IRQF_IRQPOLL,
 	.handler	= at91sam926x_pit_interrupt,
 	.irq		= NR_IRQS_LEGACY + AT91_ID_SYS,
 };
diff --git a/arch/arm/mach-at91/at91x40_time.c b/arch/arm/mach-at91/at91x40_time.c
index 2919eba..c0e637a 100644
--- a/arch/arm/mach-at91/at91x40_time.c
+++ b/arch/arm/mach-at91/at91x40_time.c
@@ -57,7 +57,7 @@ static irqreturn_t at91x40_timer_interrupt(int irq, void *dev_id)
 
 static struct irqaction at91x40_timer_irq = {
 	.name		= "at91_tick",
-	.flags		= IRQF_DISABLED | IRQF_TIMER,
+	.flags		= IRQF_TIMER,
 	.handler	= at91x40_timer_interrupt
 };
 
-- 
1.8.1.2



From michael.opdenacker at free-electrons.com  Sat Jul  6 01:42:20 2013
From: michael.opdenacker at free-electrons.com (Michael Opdenacker)
Date: Sat,  6 Jul 2013 07:42:20 +0200
Subject: [PATCH] ARM: pxa: remove IRQF_DISABLED
Message-ID: <1373089340-20118-1-git-send-email-michael.opdenacker@free-electrons.com>

This flag is a NOOP since 2.6.35 and can be removed.

Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>
---
 arch/arm/mach-pxa/am200epd.c         | 3 +--
 arch/arm/mach-pxa/am300epd.c         | 3 +--
 arch/arm/mach-pxa/em-x270.c          | 3 +--
 arch/arm/mach-pxa/magician.c         | 2 +-
 arch/arm/mach-pxa/mainstone.c        | 2 +-
 arch/arm/mach-pxa/pcm990-baseboard.c | 2 +-
 arch/arm/mach-pxa/sharpsl_pm.c       | 8 ++++----
 arch/arm/mach-pxa/time.c             | 2 +-
 arch/arm/mach-pxa/trizeps4.c         | 3 +--
 arch/arm/plat-pxa/dma.c              | 2 +-
 10 files changed, 13 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-pxa/am200epd.c b/arch/arm/mach-pxa/am200epd.c
index ffa6d81..12fb0f4 100644
--- a/arch/arm/mach-pxa/am200epd.c
+++ b/arch/arm/mach-pxa/am200epd.c
@@ -293,8 +293,7 @@ static int am200_setup_irq(struct fb_info *info)
 	int ret;
 
 	ret = request_irq(PXA_GPIO_TO_IRQ(RDY_GPIO_PIN), am200_handle_irq,
-				IRQF_DISABLED|IRQF_TRIGGER_FALLING,
-				"AM200", info->par);
+				IRQF_TRIGGER_FALLING, "AM200", info->par);
 	if (ret)
 		dev_err(&am200_device->dev, "request_irq failed: %d\n", ret);
 
diff --git a/arch/arm/mach-pxa/am300epd.c b/arch/arm/mach-pxa/am300epd.c
index 3dfec1e..c9f309a 100644
--- a/arch/arm/mach-pxa/am300epd.c
+++ b/arch/arm/mach-pxa/am300epd.c
@@ -241,8 +241,7 @@ static int am300_setup_irq(struct fb_info *info)
 	struct broadsheetfb_par *par = info->par;
 
 	ret = request_irq(PXA_GPIO_TO_IRQ(RDY_GPIO_PIN), am300_handle_irq,
-				IRQF_DISABLED|IRQF_TRIGGER_RISING,
-				"AM300", par);
+				IRQF_TRIGGER_RISING, "AM300", par);
 	if (ret)
 		dev_err(&am300_device->dev, "request_irq failed: %d\n", ret);
 
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index f6726bb..86936d9 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -556,8 +556,7 @@ static int em_x270_mci_init(struct device *dev,
 	}
 
 	err = request_irq(gpio_to_irq(mmc_cd), em_x270_detect_int,
-			      IRQF_DISABLED | IRQF_TRIGGER_RISING |
-			      IRQF_TRIGGER_FALLING,
+			      IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
 			      "MMC card detect", data);
 	if (err) {
 		dev_err(dev, "can't request MMC card detect IRQ: %d\n", err);
diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach-pxa/magician.c
index f44532f..38f544d 100644
--- a/arch/arm/mach-pxa/magician.c
+++ b/arch/arm/mach-pxa/magician.c
@@ -633,7 +633,7 @@ static struct platform_device bq24022 = {
 static int magician_mci_init(struct device *dev,
 				irq_handler_t detect_irq, void *data)
 {
-	return request_irq(IRQ_MAGICIAN_SD, detect_irq, IRQF_DISABLED,
+	return request_irq(IRQ_MAGICIAN_SD, detect_irq, 0,
 			   "mmc card detect", data);
 }
 
diff --git a/arch/arm/mach-pxa/mainstone.c b/arch/arm/mach-pxa/mainstone.c
index d2c6523..1184efa 100644
--- a/arch/arm/mach-pxa/mainstone.c
+++ b/arch/arm/mach-pxa/mainstone.c
@@ -400,7 +400,7 @@ static int mainstone_mci_init(struct device *dev, irq_handler_t mstone_detect_in
 	 */
 	MST_MSCWR1 &= ~MST_MSCWR1_MS_SEL;
 
-	err = request_irq(MAINSTONE_MMC_IRQ, mstone_detect_int, IRQF_DISABLED,
+	err = request_irq(MAINSTONE_MMC_IRQ, mstone_detect_int, 0,
 			     "MMC card detect", data);
 	if (err)
 		printk(KERN_ERR "mainstone_mci_init: MMC/SD: can't request MMC card detect IRQ\n");
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c b/arch/arm/mach-pxa/pcm990-baseboard.c
index fb7f1d1..33f058f 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -326,7 +326,7 @@ static int pcm990_mci_init(struct device *dev, irq_handler_t mci_detect_int,
 {
 	int err;
 
-	err = request_irq(PCM027_MMCDET_IRQ, mci_detect_int, IRQF_DISABLED,
+	err = request_irq(PCM027_MMCDET_IRQ, mci_detect_int,
 			     "MMC card detect", data);
 	if (err)
 		printk(KERN_ERR "pcm990_mci_init: MMC/SD: can't request MMC "
diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
index 0a36d35..051a655 100644
--- a/arch/arm/mach-pxa/sharpsl_pm.c
+++ b/arch/arm/mach-pxa/sharpsl_pm.c
@@ -860,18 +860,18 @@ static int sharpsl_pm_probe(struct platform_device *pdev)
 
 	/* Register interrupt handlers */
 	irq = gpio_to_irq(sharpsl_pm.machinfo->gpio_acin);
-	if (request_irq(irq, sharpsl_ac_isr, IRQF_DISABLED | IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, "AC Input Detect", sharpsl_ac_isr)) {
+	if (request_irq(irq, sharpsl_ac_isr, IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, "AC Input Detect", sharpsl_ac_isr)) {
 		dev_err(sharpsl_pm.dev, "Could not get irq %d.\n", irq);
 	}
 
 	irq = gpio_to_irq(sharpsl_pm.machinfo->gpio_batlock);
-	if (request_irq(irq, sharpsl_fatal_isr, IRQF_DISABLED | IRQF_TRIGGER_FALLING, "Battery Cover", sharpsl_fatal_isr)) {
+	if (request_irq(irq, sharpsl_fatal_isr, IRQF_TRIGGER_FALLING, "Battery Cover", sharpsl_fatal_isr)) {
 		dev_err(sharpsl_pm.dev, "Could not get irq %d.\n", irq);
 	}
 
 	if (sharpsl_pm.machinfo->gpio_fatal) {
 		irq = gpio_to_irq(sharpsl_pm.machinfo->gpio_fatal);
-		if (request_irq(irq, sharpsl_fatal_isr, IRQF_DISABLED | IRQF_TRIGGER_FALLING, "Fatal Battery", sharpsl_fatal_isr)) {
+		if (request_irq(irq, sharpsl_fatal_isr, IRQF_TRIGGER_FALLING, "Fatal Battery", sharpsl_fatal_isr)) {
 			dev_err(sharpsl_pm.dev, "Could not get irq %d.\n", irq);
 		}
 	}
@@ -879,7 +879,7 @@ static int sharpsl_pm_probe(struct platform_device *pdev)
 	if (sharpsl_pm.machinfo->batfull_irq) {
 		/* Register interrupt handler. */
 		irq = gpio_to_irq(sharpsl_pm.machinfo->gpio_batfull);
-		if (request_irq(irq, sharpsl_chrg_full_isr, IRQF_DISABLED | IRQF_TRIGGER_RISING, "CO", sharpsl_chrg_full_isr)) {
+		if (request_irq(irq, sharpsl_chrg_full_isr, IRQF_TRIGGER_RISING, "CO", sharpsl_chrg_full_isr)) {
 			dev_err(sharpsl_pm.dev, "Could not get irq %d.\n", irq);
 		}
 	}
diff --git a/arch/arm/mach-pxa/time.c b/arch/arm/mach-pxa/time.c
index 8f1ee92..e48fc61 100644
--- a/arch/arm/mach-pxa/time.c
+++ b/arch/arm/mach-pxa/time.c
@@ -137,7 +137,7 @@ static struct clock_event_device ckevt_pxa_osmr0 = {
 
 static struct irqaction pxa_ost0_irq = {
 	.name		= "ost0",
-	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+	.flags		= IRQF_TIMER | IRQF_IRQPOLL,
 	.handler	= pxa_ost0_interrupt,
 	.dev_id		= &ckevt_pxa_osmr0,
 };
diff --git a/arch/arm/mach-pxa/trizeps4.c b/arch/arm/mach-pxa/trizeps4.c
index c580434..872dcb2 100644
--- a/arch/arm/mach-pxa/trizeps4.c
+++ b/arch/arm/mach-pxa/trizeps4.c
@@ -332,8 +332,7 @@ static int trizeps4_mci_init(struct device *dev, irq_handler_t mci_detect_int,
 	int err;
 
 	err = request_irq(TRIZEPS4_MMC_IRQ, mci_detect_int,
-			  IRQF_DISABLED | IRQF_TRIGGER_RISING,
-			  "MMC card detect", data);
+			  IRQF_TRIGGER_RISING, "MMC card detect", data);
 	if (err) {
 		printk(KERN_ERR "trizeps4_mci_init: MMC/SD: can't request"
 						"MMC card detect IRQ\n");
diff --git a/arch/arm/plat-pxa/dma.c b/arch/arm/plat-pxa/dma.c
index 79ef102..054fc5a 100644
--- a/arch/arm/plat-pxa/dma.c
+++ b/arch/arm/plat-pxa/dma.c
@@ -377,7 +377,7 @@ int __init pxa_init_dma(int irq, int num_ch)
 		spin_lock_init(&dma_channels[i].lock);
 	}
 
-	ret = request_irq(irq, dma_irq_handler, IRQF_DISABLED, "DMA", NULL);
+	ret = request_irq(irq, dma_irq_handler, 0, "DMA", NULL);
 	if (ret) {
 		printk (KERN_CRIT "Wow!  Can't register IRQ for DMA\n");
 		kfree(dma_channels);
-- 
1.8.1.2



From michael.opdenacker at free-electrons.com  Sat Jul  6 02:03:17 2013
From: michael.opdenacker at free-electrons.com (Michael Opdenacker)
Date: Sat,  6 Jul 2013 08:03:17 +0200
Subject: [PATCH] ARM: imx: remove IRQF_DISABLED
Message-ID: <1373090597-20571-1-git-send-email-michael.opdenacker@free-electrons.com>

This flag is a NOOP since 2.6.35 and can be removed.

Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>
---
 arch/arm/mach-imx/Kconfig             | 2 +-
 arch/arm/mach-imx/epit.c              | 2 +-
 arch/arm/mach-imx/mach-armadillo5x0.c | 3 +--
 arch/arm/mach-imx/mach-mx31_3ds.c     | 2 +-
 arch/arm/mach-imx/mach-pcm037.c       | 3 +--
 arch/arm/mach-imx/mx31lilly-db.c      | 3 +--
 arch/arm/mach-imx/time.c              | 2 +-
 7 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 60661a4..05920fe 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -22,7 +22,7 @@ config MXC_IRQ_PRIOR
 	help
 	  Select this if you want to use prioritized IRQ handling.
 	  This feature prevents higher priority ISR to be interrupted
-	  by lower priority IRQ even IRQF_DISABLED flag is not set.
+	  by lower priority IRQ.
 	  This may be useful in embedded applications, where are strong
 	  requirements for timing.
 	  Say N here, unless you have a specialized requirement.
diff --git a/arch/arm/mach-imx/epit.c b/arch/arm/mach-imx/epit.c
index e02de18..074b1a8 100644
--- a/arch/arm/mach-imx/epit.c
+++ b/arch/arm/mach-imx/epit.c
@@ -171,7 +171,7 @@ static irqreturn_t epit_timer_interrupt(int irq, void *dev_id)
 
 static struct irqaction epit_timer_irq = {
 	.name		= "i.MX EPIT Timer Tick",
-	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+	.flags		= IRQF_TIMER | IRQF_IRQPOLL,
 	.handler	= epit_timer_interrupt,
 };
 
diff --git a/arch/arm/mach-imx/mach-armadillo5x0.c b/arch/arm/mach-imx/mach-armadillo5x0.c
index 368a6e3..58b864a 100644
--- a/arch/arm/mach-imx/mach-armadillo5x0.c
+++ b/arch/arm/mach-imx/mach-armadillo5x0.c
@@ -404,8 +404,7 @@ static int armadillo5x0_sdhc1_init(struct device *dev,
 
 	/* When supported the trigger type have to be BOTH */
 	ret = request_irq(gpio_to_irq(IOMUX_TO_GPIO(MX31_PIN_ATA_DMACK)),
-			  detect_irq,
-			  IRQF_DISABLED | IRQF_TRIGGER_FALLING,
+			  detect_irq, IRQF_TRIGGER_FALLING,
 			  "sdhc-detect", data);
 
 	if (ret)
diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c b/arch/arm/mach-imx/mach-mx31_3ds.c
index 1ed9161..50044a2 100644
--- a/arch/arm/mach-imx/mach-mx31_3ds.c
+++ b/arch/arm/mach-imx/mach-mx31_3ds.c
@@ -311,7 +311,7 @@ static int mx31_3ds_sdhc1_init(struct device *dev,
 	}
 
 	ret = request_irq(gpio_to_irq(IOMUX_TO_GPIO(MX31_PIN_GPIO3_1)),
-			  detect_irq, IRQF_DISABLED |
+			  detect_irq,
 			  IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
 			  "sdhc1-detect", data);
 	if (ret) {
diff --git a/arch/arm/mach-imx/mach-pcm037.c b/arch/arm/mach-imx/mach-pcm037.c
index bc0261e..45303bd6 100644
--- a/arch/arm/mach-imx/mach-pcm037.c
+++ b/arch/arm/mach-imx/mach-pcm037.c
@@ -371,8 +371,7 @@ static int pcm970_sdhc1_init(struct device *dev, irq_handler_t detect_irq,
 #endif
 
 	ret = request_irq(gpio_to_irq(IOMUX_TO_GPIO(MX31_PIN_SCK6)), detect_irq,
-			IRQF_DISABLED | IRQF_TRIGGER_FALLING,
-				"sdhc-detect", data);
+			IRQF_TRIGGER_FALLING, "sdhc-detect", data);
 	if (ret)
 		goto err_gpio_free_2;
 
diff --git a/arch/arm/mach-imx/mx31lilly-db.c b/arch/arm/mach-imx/mx31lilly-db.c
index d4361b8..649fe49 100644
--- a/arch/arm/mach-imx/mx31lilly-db.c
+++ b/arch/arm/mach-imx/mx31lilly-db.c
@@ -130,8 +130,7 @@ static int mxc_mmc1_init(struct device *dev,
 	gpio_direction_input(gpio_wp);
 
 	ret = request_irq(gpio_to_irq(IOMUX_TO_GPIO(MX31_PIN_GPIO1_1)),
-			  detect_irq,
-			  IRQF_DISABLED | IRQF_TRIGGER_FALLING,
+			  detect_irq, IRQF_TRIGGER_FALLING,
 			  "MMC detect", data);
 	if (ret)
 		goto exit_free_wp;
diff --git a/arch/arm/mach-imx/time.c b/arch/arm/mach-imx/time.c
index fea9131..a1cd831 100644
--- a/arch/arm/mach-imx/time.c
+++ b/arch/arm/mach-imx/time.c
@@ -250,7 +250,7 @@ static irqreturn_t mxc_timer_interrupt(int irq, void *dev_id)
 
 static struct irqaction mxc_timer_irq = {
 	.name		= "i.MX Timer Tick",
-	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+	.flags		= IRQF_TIMER | IRQF_IRQPOLL,
 	.handler	= mxc_timer_interrupt,
 };
 
-- 
1.8.1.2



From shawn.guo at linaro.org  Sat Jul  6 02:04:55 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sat, 6 Jul 2013 14:04:55 +0800
Subject: [PATCH 4/4] fb: Add DCU framebuffer driver for Vybrid VF610
 platform
In-Reply-To: <1373010702-9244-5-git-send-email-b18965@freescale.com>
References: <1373010702-9244-1-git-send-email-b18965@freescale.com>
 <1373010702-9244-5-git-send-email-b18965@freescale.com>
Message-ID: <20130706060453.GE30164@S2101-09.ap.freescale.net>

On Fri, Jul 05, 2013 at 03:51:42PM +0800, Alison Wang wrote:
> The Display Controller Unit (DCU) module is a system master that
> fetches graphics stored in internal or external memory and displays
> them on a TFT LCD panel. A wide range of panel sizes is supported
> and the timing of the interface signals is highly configurable.
> Graphics are read directly from memory and then blended in real-time,
> which allows for dynamic content creation with minimal CPU intervention.
> 
> The features:
> 
> (1) Full RGB888 output to TFT LCD panel.
> (2) For the current LCD panel, WQVGA "480x272" is supported.
> (3) Blending of each pixel using up to 4 source layers dependent on size of panel.
> (4) Each graphic layer can be placed with one pixel resolution in either axis.
> (5) Each graphic layer support RGB565 and RGB888 direct colors without alpha channel
> and BGRA8888 direct colors with an alpha channel.
> (6) Each graphic layer support alpha blending with 8-bit resolution.
> 
> This driver has been tested on Vybrid VF610 TOWER board.
> 
> Signed-off-by: Alison Wang <b18965 at freescale.com>
> ---
>  drivers/video/Kconfig      |    9 +
>  drivers/video/Makefile     |    1 +
>  drivers/video/fsl-dcu-fb.c | 1091 ++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 1101 insertions(+)
>  create mode 100644 drivers/video/fsl-dcu-fb.c

You should have a document under Documentation/devicetree/bindings/fb/.

Shawn



From eric.y.miao at gmail.com  Sat Jul  6 02:55:21 2013
From: eric.y.miao at gmail.com (Eric Miao)
Date: Sat, 6 Jul 2013 14:55:21 +0800
Subject: [PATCH] ARM: pxa: remove IRQF_DISABLED
In-Reply-To: <1373089340-20118-1-git-send-email-michael.opdenacker@free-electrons.com>
References: <1373089340-20118-1-git-send-email-michael.opdenacker@free-electrons.com>
Message-ID: <CAMPhdO_=PETk6cd8zJUnt=i5V=65ESr83QeY80Rb4P=1+5NLtw@mail.gmail.com>

On Sat, Jul 6, 2013 at 1:42 PM, Michael Opdenacker
<michael.opdenacker at free-electrons.com> wrote:
> This flag is a NOOP since 2.6.35 and can be removed.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>

Indeed. Acked-by: Eric Miao <eric.y.miao at gmail.com>

> ---
>  arch/arm/mach-pxa/am200epd.c         | 3 +--
>  arch/arm/mach-pxa/am300epd.c         | 3 +--
>  arch/arm/mach-pxa/em-x270.c          | 3 +--
>  arch/arm/mach-pxa/magician.c         | 2 +-
>  arch/arm/mach-pxa/mainstone.c        | 2 +-
>  arch/arm/mach-pxa/pcm990-baseboard.c | 2 +-
>  arch/arm/mach-pxa/sharpsl_pm.c       | 8 ++++----
>  arch/arm/mach-pxa/time.c             | 2 +-
>  arch/arm/mach-pxa/trizeps4.c         | 3 +--
>  arch/arm/plat-pxa/dma.c              | 2 +-
>  10 files changed, 13 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/am200epd.c b/arch/arm/mach-pxa/am200epd.c
> index ffa6d81..12fb0f4 100644
> --- a/arch/arm/mach-pxa/am200epd.c
> +++ b/arch/arm/mach-pxa/am200epd.c
> @@ -293,8 +293,7 @@ static int am200_setup_irq(struct fb_info *info)
>         int ret;
>
>         ret = request_irq(PXA_GPIO_TO_IRQ(RDY_GPIO_PIN), am200_handle_irq,
> -                               IRQF_DISABLED|IRQF_TRIGGER_FALLING,
> -                               "AM200", info->par);
> +                               IRQF_TRIGGER_FALLING, "AM200", info->par);
>         if (ret)
>                 dev_err(&am200_device->dev, "request_irq failed: %d\n", ret);
>
> diff --git a/arch/arm/mach-pxa/am300epd.c b/arch/arm/mach-pxa/am300epd.c
> index 3dfec1e..c9f309a 100644
> --- a/arch/arm/mach-pxa/am300epd.c
> +++ b/arch/arm/mach-pxa/am300epd.c
> @@ -241,8 +241,7 @@ static int am300_setup_irq(struct fb_info *info)
>         struct broadsheetfb_par *par = info->par;
>
>         ret = request_irq(PXA_GPIO_TO_IRQ(RDY_GPIO_PIN), am300_handle_irq,
> -                               IRQF_DISABLED|IRQF_TRIGGER_RISING,
> -                               "AM300", par);
> +                               IRQF_TRIGGER_RISING, "AM300", par);
>         if (ret)
>                 dev_err(&am300_device->dev, "request_irq failed: %d\n", ret);
>
> diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
> index f6726bb..86936d9 100644
> --- a/arch/arm/mach-pxa/em-x270.c
> +++ b/arch/arm/mach-pxa/em-x270.c
> @@ -556,8 +556,7 @@ static int em_x270_mci_init(struct device *dev,
>         }
>
>         err = request_irq(gpio_to_irq(mmc_cd), em_x270_detect_int,
> -                             IRQF_DISABLED | IRQF_TRIGGER_RISING |
> -                             IRQF_TRIGGER_FALLING,
> +                             IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
>                               "MMC card detect", data);
>         if (err) {
>                 dev_err(dev, "can't request MMC card detect IRQ: %d\n", err);
> diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach-pxa/magician.c
> index f44532f..38f544d 100644
> --- a/arch/arm/mach-pxa/magician.c
> +++ b/arch/arm/mach-pxa/magician.c
> @@ -633,7 +633,7 @@ static struct platform_device bq24022 = {
>  static int magician_mci_init(struct device *dev,
>                                 irq_handler_t detect_irq, void *data)
>  {
> -       return request_irq(IRQ_MAGICIAN_SD, detect_irq, IRQF_DISABLED,
> +       return request_irq(IRQ_MAGICIAN_SD, detect_irq, 0,
>                            "mmc card detect", data);
>  }
>
> diff --git a/arch/arm/mach-pxa/mainstone.c b/arch/arm/mach-pxa/mainstone.c
> index d2c6523..1184efa 100644
> --- a/arch/arm/mach-pxa/mainstone.c
> +++ b/arch/arm/mach-pxa/mainstone.c
> @@ -400,7 +400,7 @@ static int mainstone_mci_init(struct device *dev, irq_handler_t mstone_detect_in
>          */
>         MST_MSCWR1 &= ~MST_MSCWR1_MS_SEL;
>
> -       err = request_irq(MAINSTONE_MMC_IRQ, mstone_detect_int, IRQF_DISABLED,
> +       err = request_irq(MAINSTONE_MMC_IRQ, mstone_detect_int, 0,
>                              "MMC card detect", data);
>         if (err)
>                 printk(KERN_ERR "mainstone_mci_init: MMC/SD: can't request MMC card detect IRQ\n");
> diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c b/arch/arm/mach-pxa/pcm990-baseboard.c
> index fb7f1d1..33f058f 100644
> --- a/arch/arm/mach-pxa/pcm990-baseboard.c
> +++ b/arch/arm/mach-pxa/pcm990-baseboard.c
> @@ -326,7 +326,7 @@ static int pcm990_mci_init(struct device *dev, irq_handler_t mci_detect_int,
>  {
>         int err;
>
> -       err = request_irq(PCM027_MMCDET_IRQ, mci_detect_int, IRQF_DISABLED,
> +       err = request_irq(PCM027_MMCDET_IRQ, mci_detect_int,
>                              "MMC card detect", data);
>         if (err)
>                 printk(KERN_ERR "pcm990_mci_init: MMC/SD: can't request MMC "
> diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
> index 0a36d35..051a655 100644
> --- a/arch/arm/mach-pxa/sharpsl_pm.c
> +++ b/arch/arm/mach-pxa/sharpsl_pm.c
> @@ -860,18 +860,18 @@ static int sharpsl_pm_probe(struct platform_device *pdev)
>
>         /* Register interrupt handlers */
>         irq = gpio_to_irq(sharpsl_pm.machinfo->gpio_acin);
> -       if (request_irq(irq, sharpsl_ac_isr, IRQF_DISABLED | IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, "AC Input Detect", sharpsl_ac_isr)) {
> +       if (request_irq(irq, sharpsl_ac_isr, IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, "AC Input Detect", sharpsl_ac_isr)) {
>                 dev_err(sharpsl_pm.dev, "Could not get irq %d.\n", irq);
>         }
>
>         irq = gpio_to_irq(sharpsl_pm.machinfo->gpio_batlock);
> -       if (request_irq(irq, sharpsl_fatal_isr, IRQF_DISABLED | IRQF_TRIGGER_FALLING, "Battery Cover", sharpsl_fatal_isr)) {
> +       if (request_irq(irq, sharpsl_fatal_isr, IRQF_TRIGGER_FALLING, "Battery Cover", sharpsl_fatal_isr)) {
>                 dev_err(sharpsl_pm.dev, "Could not get irq %d.\n", irq);
>         }
>
>         if (sharpsl_pm.machinfo->gpio_fatal) {
>                 irq = gpio_to_irq(sharpsl_pm.machinfo->gpio_fatal);
> -               if (request_irq(irq, sharpsl_fatal_isr, IRQF_DISABLED | IRQF_TRIGGER_FALLING, "Fatal Battery", sharpsl_fatal_isr)) {
> +               if (request_irq(irq, sharpsl_fatal_isr, IRQF_TRIGGER_FALLING, "Fatal Battery", sharpsl_fatal_isr)) {
>                         dev_err(sharpsl_pm.dev, "Could not get irq %d.\n", irq);
>                 }
>         }
> @@ -879,7 +879,7 @@ static int sharpsl_pm_probe(struct platform_device *pdev)
>         if (sharpsl_pm.machinfo->batfull_irq) {
>                 /* Register interrupt handler. */
>                 irq = gpio_to_irq(sharpsl_pm.machinfo->gpio_batfull);
> -               if (request_irq(irq, sharpsl_chrg_full_isr, IRQF_DISABLED | IRQF_TRIGGER_RISING, "CO", sharpsl_chrg_full_isr)) {
> +               if (request_irq(irq, sharpsl_chrg_full_isr, IRQF_TRIGGER_RISING, "CO", sharpsl_chrg_full_isr)) {
>                         dev_err(sharpsl_pm.dev, "Could not get irq %d.\n", irq);
>                 }
>         }
> diff --git a/arch/arm/mach-pxa/time.c b/arch/arm/mach-pxa/time.c
> index 8f1ee92..e48fc61 100644
> --- a/arch/arm/mach-pxa/time.c
> +++ b/arch/arm/mach-pxa/time.c
> @@ -137,7 +137,7 @@ static struct clock_event_device ckevt_pxa_osmr0 = {
>
>  static struct irqaction pxa_ost0_irq = {
>         .name           = "ost0",
> -       .flags          = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
> +       .flags          = IRQF_TIMER | IRQF_IRQPOLL,
>         .handler        = pxa_ost0_interrupt,
>         .dev_id         = &ckevt_pxa_osmr0,
>  };
> diff --git a/arch/arm/mach-pxa/trizeps4.c b/arch/arm/mach-pxa/trizeps4.c
> index c580434..872dcb2 100644
> --- a/arch/arm/mach-pxa/trizeps4.c
> +++ b/arch/arm/mach-pxa/trizeps4.c
> @@ -332,8 +332,7 @@ static int trizeps4_mci_init(struct device *dev, irq_handler_t mci_detect_int,
>         int err;
>
>         err = request_irq(TRIZEPS4_MMC_IRQ, mci_detect_int,
> -                         IRQF_DISABLED | IRQF_TRIGGER_RISING,
> -                         "MMC card detect", data);
> +                         IRQF_TRIGGER_RISING, "MMC card detect", data);
>         if (err) {
>                 printk(KERN_ERR "trizeps4_mci_init: MMC/SD: can't request"
>                                                 "MMC card detect IRQ\n");
> diff --git a/arch/arm/plat-pxa/dma.c b/arch/arm/plat-pxa/dma.c
> index 79ef102..054fc5a 100644
> --- a/arch/arm/plat-pxa/dma.c
> +++ b/arch/arm/plat-pxa/dma.c
> @@ -377,7 +377,7 @@ int __init pxa_init_dma(int irq, int num_ch)
>                 spin_lock_init(&dma_channels[i].lock);
>         }
>
> -       ret = request_irq(irq, dma_irq_handler, IRQF_DISABLED, "DMA", NULL);
> +       ret = request_irq(irq, dma_irq_handler, 0, "DMA", NULL);
>         if (ret) {
>                 printk (KERN_CRIT "Wow!  Can't register IRQ for DMA\n");
>                 kfree(dma_channels);
> --
> 1.8.1.2
>


From shc_work at mail.ru  Sat Jul  6 03:02:22 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat,  6 Jul 2013 11:02:22 +0400
Subject: [PATCH] ARM: dts: i.MX51: Add WEIM node
Message-ID: <1373094142-24173-1-git-send-email-shc_work@mail.ru>

This patch adds the missing (Wireless External Interface Module) WEIM
devicetree node for i.MX51 CPUs.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx51.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 0ca62be..e71976e4 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -745,6 +745,23 @@
 				status = "disabled";
 			};
 
+			weim: weim at 83fda000 {
+				#address-cells = <2>;
+				#size-cells = <1>;
+				compatible = "fsl,imx51-weim";
+				reg = <0x83fda000 0x1000>;
+				clocks = <&clks 0>;
+				ranges = <
+					0 0 0xb0000000 0x08000000
+					1 0 0xb8000000 0x08000000
+					2 0 0xc0000000 0x08000000
+					3 0 0xc8000000 0x04000000
+					4 0 0xcc000000 0x02000000
+					5 0 0xce000000 0x02000000
+				>;
+				status = "disabled";
+			};
+
 			nfc: nand at 83fdb000 {
 				compatible = "fsl,imx51-nand";
 				reg = <0x83fdb000 0x1000 0xcfff0000 0x10000>;
-- 
1.8.1.5



From maxime.ripard at free-electrons.com  Sat Jul  6 04:10:45 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat, 6 Jul 2013 10:10:45 +0200
Subject: [PATCHv4 08/10] clocksource: sun4i: Remove TIMER_SCAL variable
In-Reply-To: <alpine.DEB.2.02.1307060031030.32106@ionos.tec.linutronix.de>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
 <1373062725-19625-9-git-send-email-maxime.ripard@free-electrons.com>
 <alpine.DEB.2.02.1307060031030.32106@ionos.tec.linutronix.de>
Message-ID: <20130706081045.GY2959@lukather>

On Sat, Jul 06, 2013 at 01:17:41AM +0200, Thomas Gleixner wrote:
> I really recommend that you go out for lots of beer/wine NOW and
> resume reading this mail when you recovered from that.
> 
> I definitely appreciate your responsivness to feedback, but please go
> back and read my reply to the previous version of this patch
> carefully. You might eventually find out that I pointed you to another
> redundant clk_get_rate() call in that code.
> 
> After you did this, please go through the other patches in that series
> and check how many new instances of clk_get_rate() calls you add down
> the road. I did not even bother to look whether you cleaned it up
> between v3 and v4, but I'm quite sure you did not. If I'm wrong, I owe
> you a beer at the next conference.

Wow, you really want me to drink, do you? :)

Actually, I did clean up. The other user you spotted that was previously
introduced in the patch 4/10, and if you take a look at it, you'll see
that it actually uses the rate variable like you suggested.

Now, your mail made me realize that patch 10 introduced a direct
clk_get_rate call, that I forgot to cleanup. After applying these
patches, it's the only user left.

I'll send a v5. Do you have any additionnal comments on those patches to
avoid wasting more electrons?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130706/6af8767a/attachment.sig>

From maxime.ripard at free-electrons.com  Sat Jul  6 04:28:04 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat, 6 Jul 2013 10:28:04 +0200
Subject: MTD EEPROM support and driver integration
In-Reply-To: <201307060033.13259.arnd@arndb.de>
References: <20130705201118.GM2959@lukather> <201307052302.40588.arnd@arndb.de>
 <20130705222342.GP2959@lukather> <201307060033.13259.arnd@arndb.de>
Message-ID: <20130706082804.GZ2959@lukather>

On Sat, Jul 06, 2013 at 12:33:13AM +0200, Arnd Bergmann wrote:
> On Saturday 06 July 2013, Maxime Ripard wrote:
> > > My first thought is that it should be more generic than that and not
> > > have the mac address hardcoded as the purpose. We could possibly use
> > > regmap as the in-kernel interface, and come up with a more generic
> > > way of referring to registers in another device node.
> > 
> > Hmm, I maybe wasn't as clear as I wanted. Here mac-storage was just an
> > example. It should indeed be completely generic, and a device could have
> > several "storage source" defined, each driver knowing what property it
> > would need, pretty much like what's done currently for the regulators
> > for example.
> > 
> > We will have such a use case anyway for the Allwinner stuff, since the
> > fuses can be used for several thing, including storing the SoC ID,
> > serial numbers, and so on.
> 
> Ah, I see. In general, we have two ways of expressing the same thing
> here:
> 
> a) like interrupts, regs, dmas, clocks, pinctrl, reset, pwm: fixed property names
> 
> 	regmap = <&at25 0xstart 0xlen>;
> 	regmap-names = "mac-address";
> 
> b) like gpio, regulator: variable property names
> 
> 	mac-storage = <&at25 0xstart 0xlen>;
> 
> It's unfortunate that we already have examples of both. They are largely
> equivalent, but the tendency is towards the first.

I don't have a strong feeling for one against another, so whatever works
best. Both solutions will be a huge improvement anyway :)

Just out of curiosity, is there any advantages besides having a fixed
property name to the first solution?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130706/6293084e/attachment.sig>

From shc_work at mail.ru  Sat Jul  6 04:51:58 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Sat, 06 Jul 2013 12:51:58 +0400
Subject: =?UTF-8?B?UmU6IFtQQVRDSF0gQVJNOiBkdHM6IGlteDI3IHBoeUNBUkQtUyByZW1vdmUg?=
 =?UTF-8?B?d3JvbmcgSTJDIFJUQw==?=
In-Reply-To: <1373031909-16178-1-git-send-email-mpa@pengutronix.de>
References: <1372782469.486055292@f129.mail.ru>
 <1373031909-16178-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1373100718.107651915@f159.i.mail.ru>

> Fixup of commit 7874d595b78e431f0f661d2fe47625649308a52e
> "ARM: dts: Add device tree support for phycard pca100".
> 
> Remove wrong I2C RTC node.
> 
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> ---
> 
> Thanks, Alexander, you are right. I2C2 has no RTC.
...

There are a couple of comments on this file.

I think that the OWIRE should be moved to the RDK.

ioexpander must contain "gpio-controller" at least, and for use it further,
it is necessary to define the label for this node.

Thanks.

---

From arno at natisbad.org  Sat Jul  6 05:00:34 2013
From: arno at natisbad.org (Arnaud Ebalard)
Date: Sat, 06 Jul 2013 11:00:34 +0200
Subject: [PATCHv1] arm: armada: Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <20130705142951.GE2569@titan.lakedaemon.net> (Jason Cooper's
 message of "Fri, 5 Jul 2013 10:29:51 -0400")
References: <878v1mgh4x.fsf@natisbad.org>
 <20130705142951.GE2569@titan.lakedaemon.net>
Message-ID: <87a9m0dpvx.fsf@natisbad.org>

Hi,

Jason Cooper <jason at lakedaemon.net> writes:

> On Thu, Jul 04, 2013 at 11:16:46PM +0200, Arnaud Ebalard wrote:
>> 
>> All hardware parts of the (Armada 370 based) NETGEAR ReadyNAS 102 are
>> supported by mainline kernel (USB 3.0 rear ports, USB 2.0 front port,
>> Gigabit controller and PHY, serial port, leds, buttons, SATA ports,
>> G762 fan controller) except for:
>> 
>>  - the Intersil ISL12057 I2C RTC Chip,
>>  - the Armada NAND controller.
>> 
>> Support for both of those is currently work in progress and does not
>> prevent boot.
>> 
>> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
>> ---
>> Hi Jason and Andrew,
>> 
>> As requested
>> 
>>  - this version is tested against current head of linus tree (+ I2C
>>    fixes for a race condition; for details, see message #94 of
>>    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622325).
>>  - nand layout entry and ISL12057 entry have been removed until support
>>    is available in mainline kernel for eahc of those
>>  - clock, gpio led and keys have been made siblings of soc, memory and
>>    chosen (reported by Sebastian).
>> 
>> Is it still acceptable for current merge window or am I too late?
>
> Unfortunately, it's too late for v3.11.  The arm-soc cutoff is typically
> -rc6 or so.  Which usually means we need to see it on lakml by -rc5.
> So, you're ahead of schedule for v3.12 :-P
>
> However, with any luck, maybe Ezequiel will have something ready for the
> nand driver in time as well...

ok, no problem. That may be better in the end. And regarding the
addition of G762 entries to ReadyNAS Duo v2 .dts file you queued a few
days ago? I was unable to find it in one of your branches and just
wonder where it went and hide. 

Cheers,

a+


From ldewangan at nvidia.com  Sat Jul  6 05:14:29 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Sat, 6 Jul 2013 14:44:29 +0530
Subject: [PATCH V2] ARM: tegra: enable gpio-keys on dalmore
Message-ID: <1373102069-5641-1-git-send-email-ldewangan@nvidia.com>

Dalmore have the keys mounted on board which are connected
to different pins of Tegra.

Add the keys entry in DTS file to enable key functionality.
This will enable KEY_POWER, KEY_HOME, KEY_VOLUMEUP and
KEY_VOLUMEDOWN.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
Changes from V1:
- Reorder the nodes.

 arch/arm/boot/dts/tegra114-dalmore.dts |   30 ++++++++++++++++++++++++++++++
 1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index cb640eb..259b517 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -883,6 +883,35 @@
 		};
 	};
 
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		home {
+			label = "Home";
+			gpios = <&gpio TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
+			linux,code = <102>; /* KEY_HOME */
+		};
+
+		power {
+			label = "Power";
+			gpios = <&gpio TEGRA_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
+			linux,code = <116>; /* KEY_POWER */
+			gpio-key,wakeup;
+		};
+
+		volume_down {
+			label = "VolumeDown";
+			gpios = <&gpio TEGRA_GPIO(R, 1) GPIO_ACTIVE_LOW>;
+			linux,code = <114>; /* KEY_VOLUMEDOWN */
+		};
+
+		volume_up {
+			label = "VolumeUp";
+			gpios = <&gpio TEGRA_GPIO(R, 2) GPIO_ACTIVE_LOW>;
+			linux,code = <115>; /* KEY_VOLUMEUP */
+		};
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -976,4 +1005,5 @@
 			 <&tegra_car TEGRA114_CLK_EXTERN1>;
 		clock-names = "pll_a", "pll_a_out0", "mclk";
 	};
+
 };
-- 
1.7.1.1



From linux at arm.linux.org.uk  Sat Jul  6 05:15:11 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 6 Jul 2013 10:15:11 +0100
Subject: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is
 64-bits
In-Reply-To: <CACVXFVNT3j5o9a+N9FDA07Si+cngqAZkcqh6YYOf3rHsMvRgRg@mail.gmail.com>
References: <1367008266-1431-1-git-send-email-lauraa@codeaurora.org>
 <517AF270.8040106@gmail.com>
 <CACVXFVPfkqP+UyoGd-+QFRzndSam_DtU=utrBPYCPjQCGQ_F6g@mail.gmail.com>
 <51D71F81.5090503@codeaurora.org>
 <CACVXFVNT3j5o9a+N9FDA07Si+cngqAZkcqh6YYOf3rHsMvRgRg@mail.gmail.com>
Message-ID: <20130706091511.GN24642@n2100.arm.linux.org.uk>

On Sat, Jul 06, 2013 at 10:21:05AM +0800, Ming Lei wrote:
> But please see below words in Documentation/DMA-API.txt:
> 
>            Further, the physical address of the memory must be within the
>            dma_mask of the device (the dma_mask represents a bit mask of the
>            addressable region for the device.  I.e., if the physical address of
>            the memory anded with the dma_mask is still equal to the physical
>            address, then the device can perform DMA to the memory).
> 
> You may argue that the description is about dev->dma_mask, but the
> usage should be same.
> 
> In fact, most of devices in ARM SoC(even with LPAE enabled) doesn't
> support 64bit DMA, so I don't see the point that the default mask is set
> as 64bit.

There's another couple of issues there:

(a) Linux assumes that physical memory starts at location zero.  There
    are various places in the kernel that assume that this holds true:

	max_dma_pfn = (dma_mask >> PAGE_SHIFT) + 1

    One notable place is the block layer.  I've suggested to Santosh a
    way to fix this but I need to help him a little more with it.

(b) Device DMA addresses are a *separate* address space to the physical
    address space.  Device DMA addresses are the addresses which need to
    be programmed into the device to perform DMA to the identified
    location.

What (b) means is that if you are ending up with a 64-bit address to be
programmed into a 32-bit only register, there is something very very
wrong.  What this also means is that a 32-bit DMA mask should suffice,
because if the DMA address results in a 32-bit address _for the DMA
device_ then we are within its capabilities.

In any case, the work around is not to set the DMA mask to be 64-bit.
Think about it.  What if you have 8GB of physical memory in a LPAE
system, but your DMA controllers can only be programmed with a 32-bit
address?

Lastly, think about what I said last night about most of the ARM drivers
being rather buggy in that they do not call either dma_set_mask() or
dma_set_coherent_mask().

So, I think we're well past the point where we need to stop assuming that
DMA masks somehow relate to physical addresses, and that they can be used
to indicate a range of physical addresses starting at zero and extending
up to and including the mask value.  To call such a thing a "mask" is
absolutely absurd.


From arnd at arndb.de  Sat Jul  6 05:18:00 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 06 Jul 2013 11:18 +0200
Subject: MTD EEPROM support and driver integration
In-Reply-To: <20130706082804.GZ2959@lukather>
References: <20130705201118.GM2959@lukather>
 <201307060033.13259.arnd@arndb.de> <20130706082804.GZ2959@lukather>
Message-ID: <5811519.oHVuMujf0I@wuerfel>

On Saturday 06 July 2013 10:28:04 Maxime Ripard wrote:
> > a) like interrupts, regs, dmas, clocks, pinctrl, reset, pwm: fixed property names
> > 
> >       regmap = <&at25 0xstart 0xlen>;
> >       regmap-names = "mac-address";
> > 
> > b) like gpio, regulator: variable property names
> > 
> >       mac-storage = <&at25 0xstart 0xlen>;
> > 
> > It's unfortunate that we already have examples of both. They are largely
> > equivalent, but the tendency is towards the first.
> 
> I don't have a strong feeling for one against another, so whatever works
> best. Both solutions will be a huge improvement anyway 
> 
> Just out of curiosity, is there any advantages besides having a fixed
> property name to the first solution?

I think it's mostly for consistency: trying to get most subsystems to
do it the same way to make it easier for people to write dts files.

A lesser point is that it simplifies the driver code if you don't
have to pass a name.


	Arnd


From oliver+list at schinagl.nl  Sat Jul  6 05:16:51 2013
From: oliver+list at schinagl.nl (Oliver Schinagl)
Date: Sat, 06 Jul 2013 11:16:51 +0200
Subject: [linux-sunxi] Re: [PATCHv4 08/10] clocksource: sun4i: Remove
 TIMER_SCAL variable
In-Reply-To: <20130706081045.GY2959@lukather>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
 <1373062725-19625-9-git-send-email-maxime.ripard@free-electrons.com>
 <alpine.DEB.2.02.1307060031030.32106@ionos.tec.linutronix.de>
 <20130706081045.GY2959@lukather>
Message-ID: <51D7E083.1090109@schinagl.nl>

On 06-07-13 10:10, Maxime Ripard wrote:
>
> I'll send a v5. Do you have any additionnal comments on those patches to
> avoid wasting more electrons?
Pff, we all know Maxime's electrons are free
>
> Maxime
>



From broonie at kernel.org  Sat Jul  6 05:19:25 2013
From: broonie at kernel.org (Mark Brown)
Date: Sat, 6 Jul 2013 10:19:25 +0100
Subject: [PATCH 1/3] ARM: dts: Put Arndale fixed voltage regulators on a
 simple-bus
In-Reply-To: <2269980.iUpB0kJaI3@flatron>
References: <1372714599-17588-1-git-send-email-broonie@kernel.org>
 <2269980.iUpB0kJaI3@flatron>
Message-ID: <20130706091925.GL27646@sirena.org.uk>

On Sat, Jul 06, 2013 at 01:36:57AM +0200, Tomasz Figa wrote:
> On Monday 01 of July 2013 22:36:37 Mark Brown wrote:

> > +	regulators {
> > +		compatible = "simple-bus";
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;

> Are the two #properties above really necessary? The regulators that will 
> be placed here probably don't need any kind of addressing, so it should be 
> possible to omit them.

I believe they're required boilerplate for a correct DT bus.

> > +
> > +		mmc_reg: voltage-regulator {

> I'd suggest suffixing name of this node with an index, like voltage-
> regulator-0 to be more future proof, in case of further fixed regulators 
> being added.

If you want to rename things that's a separate thing so should be a
separate patch - this patch is just about moving the existing devices
onto a bus.
-------------- 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/20130706/4f173dbe/attachment.sig>

From jic23 at kernel.org  Sat Jul  6 06:24:04 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sat, 06 Jul 2013 11:24:04 +0100
Subject: [PATCHv3 1/3] iio: Add Nuvoton NAU7802 ADC driver
In-Reply-To: <51D53B72.6020309@metafoo.de>
References: <1372094699-3832-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1372094699-3832-2-git-send-email-alexandre.belloni@free-electrons.com>
 <51D53B72.6020309@metafoo.de>
Message-ID: <51D7F044.9040205@kernel.org>

On 07/04/2013 10:08 AM, Lars-Peter Clausen wrote:
> On 06/24/2013 07:24 PM, Alexandre Belloni wrote:
>> The Nuvoton NAU7802 ADC is a 24-bit 2-channels I2C ADC, with adjustable
>> gain and sampling rates.
>>
>> Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
>> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> 
> Reviewed-by: Lars-Peter Clausen <lars at metafoo.de>
> 
Applied to the togreg branch of iio.git (with a few little tweaks).

There was some fuzz that required manual fixing because of another driver merge so
please check I didn't foul anything up with this or the other bits below.

There were two trivial missing unlocks on error paths in the read_raw function that
I've fixed up (Coccinelle found these for me - if you can I would always advise
running sparse, coccicheck and ideally smatch before submitting patches).

I fixed up the comments because if there is one thing I hate bothering
with it is delightful patches that just fix this stuff. Much better
to do it now given it took 20 secs ;)

> One remark though. Multiline comments should be like
> 
> /*
>  * foo
>  * bar
>  */
> 
> not
> 
> /* foo
>  * bar
>  */
> 
> But not need to resend the patch just for this
> 
> - Lars
> 


From jic23 at kernel.org  Sat Jul  6 06:26:46 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sat, 06 Jul 2013 11:26:46 +0100
Subject: [PATCHv3 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
In-Reply-To: <1372094699-3832-3-git-send-email-alexandre.belloni@free-electrons.com>
References: <1372094699-3832-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1372094699-3832-3-git-send-email-alexandre.belloni@free-electrons.com>
Message-ID: <51D7F0E6.2000008@kernel.org>

On 06/24/2013 06:24 PM, Alexandre Belloni wrote:
> From: Maxime Ripard <maxime.ripard at free-electrons.com>
> 
> The ADCs connected to this bus have been experiencing some timeout
> issues when using the iMX28 i2c controller. Switching back to bitbanging
> solves this.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>

As there are no disadvantages in taking the driver through IIO and these changes
through the appropriate arch trees, I'd not propose to take these through IIO
(even when the discussion is done) unless specifically asked to.

Jonathan
> ---
>  arch/arm/boot/dts/imx28-cfa10049.dts | 108 +++++++++++++++++++++--------------
>  1 file changed, 65 insertions(+), 43 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
> index 05ae549..d3758c2 100644
> --- a/arch/arm/boot/dts/imx28-cfa10049.dts
> +++ b/arch/arm/boot/dts/imx28-cfa10049.dts
> @@ -139,6 +139,17 @@
>  					fsl,pull-up = <0>; /* 0 will enable the keeper */
>  				};
>  
> +				i2c1_pins_cfa10049: i2c1 at 0 {
> +					reg = <0>;
> +					fsl,pinmux-ids = <
> +						0x3103 /* MX28_PAD_PWM0__GPIO */
> +						0x3113 /* MX28_PAD_PWM1__I2C1_SDA */
> +					>;
> +					fsl,drive-strength = <1>;
> +					fsl,voltage = <1>;
> +					fsl,pull-up = <1>;
> +				};
> +
>  				fiq_pins_cfa10049: fiq at 0 {
>  					reg = <0>;
>  					fsl,pinmux-ids = <
> @@ -199,49 +210,6 @@
>  				status = "okay";
>  			};
>  
> -			i2c1: i2c at 8005a000 {
> -				pinctrl-names = "default";
> -				pinctrl-0 = <&i2c1_pins_a>;
> -				status = "okay";
> -			};
> -
> -			i2cmux {
> -				compatible = "i2c-mux-gpio";
> -				#address-cells = <1>;
> -				#size-cells = <0>;
> -				mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
> -				i2c-parent = <&i2c1>;
> -
> -				i2c at 0 {
> -					reg = <0>;
> -				};
> -
> -				i2c at 1 {
> -					reg = <1>;
> -				};
> -
> -				i2c at 2 {
> -					reg = <2>;
> -				};
> -
> -				i2c at 3 {
> -					reg = <3>;
> -					#address-cells = <1>;
> -					#size-cells = <0>;
> -
> -					pca9555: pca9555 at 20 {
> -						compatible = "nxp,pca9555";
> -						interrupt-parent = <&gpio2>;
> -						interrupts = <19 0x2>;
> -						gpio-controller;
> -						#gpio-cells = <2>;
> -						interrupt-controller;
> -						#interrupt-cells = <2>;
> -						reg = <0x20>;
> -					};
> -				};
> -			};
> -
>  			usbphy1: usbphy at 8007e000 {
>  				status = "okay";
>  			};
> @@ -366,6 +334,60 @@
>  		rotary-encoder,relative-axis;
>  	};
>  
> +	i2c1gpio: i2c at 0 {
> +		compatible = "i2c-gpio";
> +		pinctrl-0 = <&i2c1_pins_cfa10049>;
> +		pinctrl-names = "default";
> +		gpios = <
> +			&gpio3 17 0 /* sda */
> +			&gpio3 16 0 /* scl */
> +			 >;
> +		i2c-gpio,delay-us = <2>;	/* ~100 kHz */
> +	};
> +
> +	i2cmux {
> +		compatible = "i2c-mux-gpio";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
> +		i2c-parent = <&i2c1gpio>;
> +
> +		i2c at 0 {
> +			reg = <0>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		i2c at 1 {
> +			reg = <1>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		i2c at 2 {
> +			reg = <2>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		i2c at 3 {
> +			reg = <3>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			pca9555: pca9555 at 20 {
> +				compatible = "nxp,pca9555";
> +				interrupt-parent = <&gpio2>;
> +				interrupts = <19 0x2>;
> +				gpio-controller;
> +				#gpio-cells = <2>;
> +				interrupt-controller;
> +				#interrupt-cells = <2>;
> +				reg = <0x20>;
> +			};
> +		};
> +	};
> +
>  	backlight {
>  		compatible = "pwm-backlight";
>  		pwms = <&pwm 3 5000000>;
> 


From arnd at arndb.de  Sat Jul  6 06:56:56 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 06 Jul 2013 12:56:56 +0200
Subject: [linux-sunxi] Re: [PATCHv4 08/10] clocksource: sun4i: Remove
 TIMER_SCAL variable
In-Reply-To: <51D7E083.1090109@schinagl.nl>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
 <20130706081045.GY2959@lukather> <51D7E083.1090109@schinagl.nl>
Message-ID: <13255064.lFze3iqNa0@wuerfel>

On Saturday 06 July 2013 11:16:51 Oliver Schinagl wrote:
> On 06-07-13 10:10, Maxime Ripard wrote:
> >
> > I'll send a v5. Do you have any additionnal comments on those patches to
> > avoid wasting more electrons?
>
> Pff, we all know Maxime's electrons are free

Only free as in Drude-Sommerfeld, not free as in beer.

	Arnd


From maxime.ripard at free-electrons.com  Sat Jul  6 07:43:10 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat, 6 Jul 2013 13:43:10 +0200
Subject: MTD EEPROM support and driver integration
In-Reply-To: <5811519.oHVuMujf0I@wuerfel>
References: <20130705201118.GM2959@lukather> <201307060033.13259.arnd@arndb.de>
 <20130706082804.GZ2959@lukather> <5811519.oHVuMujf0I@wuerfel>
Message-ID: <20130706114310.GA2959@lukather>

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/20130706/a08f2c8e/attachment.sig>

From maxime.ripard at free-electrons.com  Sat Jul  6 08:01:12 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat, 6 Jul 2013 14:01:12 +0200
Subject: MTD EEPROM support and driver integration
In-Reply-To: <5811519.oHVuMujf0I@wuerfel>
References: <20130705201118.GM2959@lukather> <201307060033.13259.arnd@arndb.de>
 <20130706082804.GZ2959@lukather> <5811519.oHVuMujf0I@wuerfel>
Message-ID: <20130706120112.GA11069@lukather>

Hi,

I'm not exactly sure on what happened to the previous mail that has been
sent empty, but anyway:

On Sat, Jul 06, 2013 at 11:18:00AM +0200, Arnd Bergmann wrote:
> On Saturday 06 July 2013 10:28:04 Maxime Ripard wrote:
> > > a) like interrupts, regs, dmas, clocks, pinctrl, reset, pwm: fixed property names
> > > 
> > >       regmap = <&at25 0xstart 0xlen>;
> > >       regmap-names = "mac-address";
> > > 
> > > b) like gpio, regulator: variable property names
> > > 
> > >       mac-storage = <&at25 0xstart 0xlen>;
> > > 
> > > It's unfortunate that we already have examples of both. They are largely
> > > equivalent, but the tendency is towards the first.
> > 
> > I don't have a strong feeling for one against another, so whatever works
> > best. Both solutions will be a huge improvement anyway 
> > 
> > Just out of curiosity, is there any advantages besides having a fixed
> > property name to the first solution?
> 
> I think it's mostly for consistency: trying to get most subsystems to
> do it the same way to make it easier for people to write dts files.
> 
> A lesser point is that it simplifies the driver code if you don't
> have to pass a name.

So that leave us with mainly one path to achieve this goal:
  - Add a regmap-mtd backend
  - Add DT parsing code for regmap
  - Move the EEPROM drivers from misc to mtd

What other option would we have?

I also thought about writing an EEPROM framework of its own, but the
line is really thin between a large EEPROM and say a small SPI
dataflash, which would make it pretty hard to choose between such a
framework and MTD.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130706/cc19dacb/attachment.sig>

From linux at arm.linux.org.uk  Sat Jul  6 09:10:57 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 6 Jul 2013 14:10:57 +0100
Subject: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c
In-Reply-To: <20130520095447.GR21614@n2100.arm.linux.org.uk>
References: <20130517191304.468.73487.stgit@localhost>
 <20130517191751.468.89202.stgit@localhost>
 <20130520095447.GR21614@n2100.arm.linux.org.uk>
Message-ID: <20130706131057.GU21614@n2100.arm.linux.org.uk>

On Mon, May 20, 2013 at 10:54:47AM +0100, Russell King - ARM Linux wrote:
> On Fri, May 17, 2013 at 12:17:51PM -0700, Tony Lindgren wrote:
> > We can now boot with device tree. If you don't want to update u-boot,
> > you can boot with appended DTB with the following instructions:
> > 
> > 1. Make sure you have the appended DTB support in .config
> > 
> >    CONFIG_ARM_APPENDED_DTB=y
> >    CONFIG_ARM_ATAG_DTB_COMPAT=y
> >    CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y
> > 
> > 2. Build the zImage
> > 
> >    $ ARCH=arm CROSS_COMPILE=... make zImage
> > 
> > 3. Build the device tree blobs
> > 
> >    $ ARCH=arm CROSS_COMPILE=... make dtbs
> > 
> > 4. Append the dtb to zImage
> > 
> >    $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-sdp.dtb > /tmp/appended
> > 
> > 5. Use mkimage to produce the appended device tree uImage
> > 
> >    $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
> >      -n "Linux" -d /tmp/appended /tmp/uImage
> > 
> > Signed-off-by: Tony Lindgren <tony at atomide.com>
> 
> Okay, I'm removing the 4430SDP from the boot test system once this goes
> in, because this will mean rewriting the build system to cope with this
> stuff.

Well, this doesn't work.  I've tried several things, and I think I'm
generating a correct image, but it doesn't boot.

This could be that the current Linus tip plus my stuff plus arm-soc
is broken, but as it boots on the 3430LDP I suspect that isn't the
case.

I've tried with omap4-sdp.dtb and the other omap4-sdp DTB file with no
improvement.  No idea how to even begin to debug this, as there's no
way for the decompressor to produce output, and I've no idea which
OMAP uart to use for debug output (because that information has been
removed from the kernel source.)

And... WTF is the OMAP debug uart selection in its own separate menu
from the main "choice" statement?  This is totally unnecessary complexity
and is just making things more complicated for the hell of it.  Look at
what every other platform does - they put their stuff in the main choice
statement even if they have multiple UARTs.  The hint there is that these
depend on the appropriate support being selected, so in the case of a
kernel only targetting OMAP, as things stand you'll end up with a menu
which lists the OMAP2PLUS, none, icedcc, and semihosting entries followed
by another menu to select which OMAP port you want.  That's utterly
rediculous and broken.  And just think about the two titles for the
menus:

        prompt "Kernel low-level debugging port"
vs
        prompt "Low-level debug console UART"

Oh wait, why don't I get to choose my "debug console UART" on an AT91?
Maybe AT91 should move their debug uart selection into this menu as well,
and maybe the Versatile Express options too, because they're all to do
with selecting the UART to be used.  Please... some sane *thought* would
be *really* good here.

Oh my god, you're not the only ones.  Arnd/Olof, who started this madness
and _why_ haven't you already stepped on it?  Right, I'm fixing this in
this merge window.  Everything is moving under the original choice menu
as it was intended to be.

The attempts are all on the builder website against the (disabled)
omap4430-sdp entry.


From linux at arm.linux.org.uk  Sat Jul  6 09:36:27 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 6 Jul 2013 14:36:27 +0100
Subject: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c
In-Reply-To: <20130706131057.GU21614@n2100.arm.linux.org.uk>
References: <20130517191304.468.73487.stgit@localhost>
 <20130517191751.468.89202.stgit@localhost>
 <20130520095447.GR21614@n2100.arm.linux.org.uk>
 <20130706131057.GU21614@n2100.arm.linux.org.uk>
Message-ID: <20130706133627.GV21614@n2100.arm.linux.org.uk>

On Sat, Jul 06, 2013 at 02:10:57PM +0100, Russell King - ARM Linux wrote:
> Well, this doesn't work.  I've tried several things, and I think I'm
> generating a correct image, but it doesn't boot.
> 
> This could be that the current Linus tip plus my stuff plus arm-soc
> is broken, but as it boots on the 3430LDP I suspect that isn't the
> case.
> 
> I've tried with omap4-sdp.dtb and the other omap4-sdp DTB file with no
> improvement.  No idea how to even begin to debug this, as there's no
> way for the decompressor to produce output, and I've no idea which
> OMAP uart to use for debug output (because that information has been
> removed from the kernel source.)
> 
> And... WTF is the OMAP debug uart selection in its own separate menu
> from the main "choice" statement?  This is totally unnecessary complexity
> and is just making things more complicated for the hell of it.  Look at
> what every other platform does - they put their stuff in the main choice
> statement even if they have multiple UARTs.  The hint there is that these
> depend on the appropriate support being selected, so in the case of a
> kernel only targetting OMAP, as things stand you'll end up with a menu
> which lists the OMAP2PLUS, none, icedcc, and semihosting entries followed
> by another menu to select which OMAP port you want.  That's utterly
> rediculous and broken.  And just think about the two titles for the
> menus:
> 
>         prompt "Kernel low-level debugging port"
> vs
>         prompt "Low-level debug console UART"
> 
> Oh wait, why don't I get to choose my "debug console UART" on an AT91?
> Maybe AT91 should move their debug uart selection into this menu as well,
> and maybe the Versatile Express options too, because they're all to do
> with selecting the UART to be used.  Please... some sane *thought* would
> be *really* good here.
> 
> Oh my god, you're not the only ones.  Arnd/Olof, who started this madness
> and _why_ haven't you already stepped on it?  Right, I'm fixing this in
> this merge window.  Everything is moving under the original choice menu
> as it was intended to be.
> 
> The attempts are all on the builder website against the (disabled)
> omap4430-sdp entry.

Okay, I guessed that the OMAP4430SDP was "blaze" (it's not obvious to
use internal codenames for boards when they're known as "SDP" etc -
especially when they have stickers on them saying that they're "SDP".)

With that worked out, throwing my standard printascii() hack into the
kernel results in boot messages... up to the point where the timer is
calibrated.  So, it looks like either interrupts, clocks, or the OMAP
timers are non-functional with DT based kernels on the SDP board.

Any ideas?


From jason at lakedaemon.net  Sat Jul  6 09:38:48 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Sat, 6 Jul 2013 09:38:48 -0400
Subject: [PATCHv1] arm: armada: Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <87a9m0dpvx.fsf@natisbad.org>
References: <878v1mgh4x.fsf@natisbad.org>
 <20130705142951.GE2569@titan.lakedaemon.net>
 <87a9m0dpvx.fsf@natisbad.org>
Message-ID: <20130706133848.GK2569@titan.lakedaemon.net>

On Sat, Jul 06, 2013 at 11:00:34AM +0200, Arnaud Ebalard wrote:
> Hi,
> 
> Jason Cooper <jason at lakedaemon.net> writes:
> 
> > On Thu, Jul 04, 2013 at 11:16:46PM +0200, Arnaud Ebalard wrote:
> >> 
> >> All hardware parts of the (Armada 370 based) NETGEAR ReadyNAS 102 are
> >> supported by mainline kernel (USB 3.0 rear ports, USB 2.0 front port,
> >> Gigabit controller and PHY, serial port, leds, buttons, SATA ports,
> >> G762 fan controller) except for:
> >> 
> >>  - the Intersil ISL12057 I2C RTC Chip,
> >>  - the Armada NAND controller.
> >> 
> >> Support for both of those is currently work in progress and does not
> >> prevent boot.
> >> 
> >> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
> >> ---
> >> Hi Jason and Andrew,
> >> 
> >> As requested
> >> 
> >>  - this version is tested against current head of linus tree (+ I2C
> >>    fixes for a race condition; for details, see message #94 of
> >>    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622325).
> >>  - nand layout entry and ISL12057 entry have been removed until support
> >>    is available in mainline kernel for eahc of those
> >>  - clock, gpio led and keys have been made siblings of soc, memory and
> >>    chosen (reported by Sebastian).
> >> 
> >> Is it still acceptable for current merge window or am I too late?
> >
> > Unfortunately, it's too late for v3.11.  The arm-soc cutoff is typically
> > -rc6 or so.  Which usually means we need to see it on lakml by -rc5.
> > So, you're ahead of schedule for v3.12 :-P
> >
> > However, with any luck, maybe Ezequiel will have something ready for the
> > nand driver in time as well...
> 
> ok, no problem. That may be better in the end. And regarding the
> addition of G762 entries to ReadyNAS Duo v2 .dts file you queued a few
> days ago? I was unable to find it in one of your branches and just
> wonder where it went and hide. 

It's hiding in ~/.maildir/.TODO.linux-next/ :-)  atm, there's really
nothing stable to base a branch off of.  Once -rc1 lands, I'll create
new branches with all the stuff I have so far for v3.12.  I'll also
rebuild for-next with that same material.

hth,

Jason.


From jason at lakedaemon.net  Sat Jul  6 09:54:33 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Sat, 6 Jul 2013 09:54:33 -0400
Subject: [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
In-Reply-To: <20130705234501.1341f52e@skate>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-4-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo73iSBg+SYwZLea0qdXD1uVc3+Vacd8Tg4CU92vLG=2AQ@mail.gmail.com>
 <20130705234501.1341f52e@skate>
Message-ID: <20130706135433.GL2569@titan.lakedaemon.net>

On Fri, Jul 05, 2013 at 11:45:01PM +0200, Thomas Petazzoni wrote:
> Dear Bjorn Helgaas,
> 
> On Fri, 5 Jul 2013 15:37:33 -0600, Bjorn Helgaas wrote:
> 
> > Acked-by: Bjorn Helgaas <bhelgaas at google.com>
> > 
> > Again, please update the subject line to "PCI: Remove ..."
> > 
> > I doubt that you'll get explicit acks from all the arches you touched,
> > but I think it's reasonable to put at least patches 2 & 3 in -next
> > soon after v3.11-rc1, so we should have time to shake out issues.
> 
> Sure. Which merge strategy do you suggest for this patch series, which
> touches a number of different areas, and has some build-time
> dependencies between the patches (if needed, I can detail those build
> time dependencies to help figuring out the best strategy).

If we end up handling this the same as the of/pci & mvebu-pcie series
(whole series through mvebu -> arm-soc) I can have it up in -next within
a few days of -rc1.  Just let me know.

hth,

Jason.


From viniciusfre at gmail.com  Sat Jul  6 10:39:13 2013
From: viniciusfre at gmail.com (viniciusfre at gmail.com)
Date: Sat, 6 Jul 2013 07:39:13 -0700 (PDT)
Subject: [PATCH v5] ARM: sunxi: New watchdog driver for Allwinner A10/A13
In-Reply-To: <1370547265-24854-1-git-send-email-carlo.caione@gmail.com>
References: <1370547265-24854-1-git-send-email-carlo.caione@gmail.com>
Message-ID: <80d67226-1d83-475a-a94c-cfecc1cd277e@googlegroups.com>

Em quinta-feira, 6 de junho de 2013 16h34min25s UTC-3, Carlo Caione  escreveu:
> This patch adds the driver for the watchdog found in the Allwinner A10 and
> 
> A13 SoCs. It has DT-support and uses the new watchdog framework.
> 
> 
> 
> Signed-off-by: Carlo Caione <carlo.caione at gmail.com>
> 
> ---
> 
>  drivers/watchdog/Kconfig     |  10 ++
> 
>  drivers/watchdog/Makefile    |   1 +
> 
>  drivers/watchdog/sunxi_wdt.c | 231 +++++++++++++++++++++++++++++++++++++++++++
> 
>  3 files changed, 242 insertions(+)
> 
>  create mode 100644 drivers/watchdog/sunxi_wdt.c
> 
> 
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> 
> index e89fc31..8ad2238 100644
> 
> --- a/drivers/watchdog/Kconfig
> 
> +++ b/drivers/watchdog/Kconfig
> 
> @@ -299,6 +299,16 @@ config ORION_WATCHDOG
> 
>  	  To compile this driver as a module, choose M here: the
> 
>  	  module will be called orion_wdt.
> 
>  
> 
> +config SUNXI_WATCHDOG
> 
> +	tristate "Allwinner SoCs watchdog support"
> 
> +	depends on ARCH_SUNXI
> 
> +	select WATCHDOG_CORE
> 
> +	help
> 
> +	  Say Y here to include support for the watchdog timer
> 
> +	  in Allwinner SoCs.
> 
> +	  To compile this driver as a module, choose M here: the
> 
> +	  module will be called sunxi_wdt.
> 
> +
> 
>  config COH901327_WATCHDOG
> 
>  	bool "ST-Ericsson COH 901 327 watchdog"
> 
>  	depends on ARCH_U300
> 
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> 
> index a300b94..5012d5f 100644
> 
> --- a/drivers/watchdog/Makefile
> 
> +++ b/drivers/watchdog/Makefile
> 
> @@ -47,6 +47,7 @@ obj-$(CONFIG_PNX4008_WATCHDOG) += pnx4008_wdt.o
> 
>  obj-$(CONFIG_IOP_WATCHDOG) += iop_wdt.o
> 
>  obj-$(CONFIG_DAVINCI_WATCHDOG) += davinci_wdt.o
> 
>  obj-$(CONFIG_ORION_WATCHDOG) += orion_wdt.o
> 
> +obj-$(CONFIG_SUNXI_WATCHDOG) += sunxi_wdt.o
> 
>  obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
> 
>  obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
> 
>  obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
> 
> diff --git a/drivers/watchdog/sunxi_wdt.c b/drivers/watchdog/sunxi_wdt.c
> 
> new file mode 100644
> 
> index 0000000..69d4d44
> 
> --- /dev/null
> 
> +++ b/drivers/watchdog/sunxi_wdt.c
> 
> @@ -0,0 +1,231 @@
> 
> +/*
> 
> + *      sunxi Watchdog Driver
> 
> + *
> 
> + *      Copyright (c) 2013 Carlo Caione
> 
> + *                    2012 Henrik Nordstrom
> 
> + *
> 
> + *      This program is free software; you can redistribute it and/or
> 
> + *      modify it under the terms of the GNU General Public License
> 
> + *      as published by the Free Software Foundation; either version
> 
> + *      2 of the License, or (at your option) any later version.
> 
> + *
> 
> + *      Based on xen_wdt.c
> 
> + *      (c) Copyright 2010 Novell, Inc.
> 
> + */
> 
> +
> 
> +#include <linux/clk.h>
> 
> +#include <linux/err.h>
> 
> +#include <linux/init.h>
> 
> +#include <linux/io.h>
> 
> +#include <linux/kernel.h>
> 
> +#include <linux/module.h>
> 
> +#include <linux/moduleparam.h>
> 
> +#include <linux/of.h>
> 
> +#include <linux/of_address.h>
> 
> +#include <linux/platform_device.h>
> 
> +#include <linux/types.h>
> 
> +#include <linux/watchdog.h>
> 
> +
> 
> +#define WDT_MAX_TIMEOUT         16
> 
> +#define WDT_MIN_TIMEOUT         1
> 
> +#define WDT_MODE_TIMEOUT(n)     ((n) << 3)
> 
> +#define WDT_TIMEOUT_MASK        WDT_MODE_TIMEOUT(0x0F)
> 
> +
> 
> +#define WDT_CTRL                0x00
> 
> +#define WDT_CTRL_RELOAD         ((1 << 0) | (0x0a57 << 1))
> 
> +
> 
> +#define WDT_MODE                0x04
> 
> +#define WDT_MODE_EN             (1 << 0)
> 
> +#define WDT_MODE_RST_EN         (1 << 1)
> 
> +
> 
> +#define DRV_NAME		"sunxi-wdt"
> 
> +#define DRV_VERSION		"1.0"
> 
> +
> 
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> 
> +static int heartbeat = WDT_MAX_TIMEOUT;
> 
> +
> 
> +struct sunxi_wdt_dev {
> 
> +	struct watchdog_device wdt_dev;
> 
> +	void __iomem *wdt_base;
> 
> +};
> 
> +
> 
> +/*
> 
> + * wdt_timeout_map maps the watchdog timer interval value in seconds to
> 
> + * the value of the register WDT_MODE bit 3:6
> 
> + *
> 
> + * [timeout seconds] = register value
> 
> + *
> 
> + */
> 
> +
> 
> +static const int wdt_timeout_map[] = {
> 
> +	[1] = 0b0001,  /* 1s  */
> 
> +	[2] = 0b0010,  /* 2s  */
> 
> +	[3] = 0b0011,  /* 3s  */
> 
> +	[4] = 0b0100,  /* 4s  */
> 
> +	[5] = 0b0101,  /* 5s  */
> 
> +	[6] = 0b0110,  /* 6s  */
> 
> +	[8] = 0b0111,  /* 8s  */
> 
> +	[10] = 0b1000, /* 10s */
> 
> +	[12] = 0b1001, /* 12s */
> 
> +	[14] = 0b1010, /* 14s */
> 
> +	[16] = 0b1011, /* 16s */
> 
> +};
> 
> +
> 
> +static int sunxi_wdt_ping(struct watchdog_device *wdt_dev)
> 
> +{
> 
> +	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
> 
> +	void __iomem *wdt_base = sunxi_wdt->wdt_base;
> 
> +
> 
> +	iowrite32(WDT_CTRL_RELOAD, wdt_base + WDT_CTRL);
> 
> +
> 
> +	return 0;
> 
> +}
> 
> +
> 
> +static int sunxi_wdt_set_timeout(struct watchdog_device *wdt_dev,
> 
> +		unsigned int timeout)
> 
> +{
> 
> +	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
> 
> +	void __iomem *wdt_base = sunxi_wdt->wdt_base;
> 
> +	u32 reg;
> 
> +
> 
> +	if (timeout > WDT_MAX_TIMEOUT)
> 
> +		return -EINVAL;
> 
> +
> 
> +	if (wdt_timeout_map[timeout] == 0)
> 
> +		timeout++;
> 
> +
> 
> +	sunxi_wdt->wdt_dev.timeout = timeout;
> 
> +
> 
> +	reg = ioread32(wdt_base + WDT_MODE);
> 
> +	reg &= ~WDT_TIMEOUT_MASK;
> 
> +	reg |= WDT_MODE_TIMEOUT(wdt_timeout_map[timeout]);
> 
> +	iowrite32(reg, wdt_base + WDT_MODE);
> 
> +
> 
> +	sunxi_wdt_ping(wdt_dev);
> 
> +
> 
> +	return 0;
> 
> +}
> 
> +
> 
> +static int sunxi_wdt_stop(struct watchdog_device *wdt_dev)
> 
> +{
> 
> +	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
> 
> +	void __iomem *wdt_base = sunxi_wdt->wdt_base;
> 
> +
> 
> +	iowrite32(0, wdt_base + WDT_MODE);
> 
> +
> 
> +	return 0;
> 
> +}
> 
> +
> 
> +static int sunxi_wdt_start(struct watchdog_device *wdt_dev)
> 
> +{
> 
> +	u32 reg;
> 
> +	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
> 
> +	void __iomem *wdt_base = sunxi_wdt->wdt_base;
> 
> +	int ret;
> 
> +
> 
> +	ret = sunxi_wdt_set_timeout(&sunxi_wdt->wdt_dev,
> 
> +			sunxi_wdt->wdt_dev.timeout);
> 
> +	if (ret < 0)
> 
> +		return ret;
> 
> +
> 
> +	reg = ioread32(wdt_base + WDT_MODE);
> 
> +	reg |= (WDT_MODE_RST_EN | WDT_MODE_EN);
> 
> +	iowrite32(reg, wdt_base + WDT_MODE);
> 
> +
> 
> +	return 0;
> 
> +}
> 
> +
> 
> +static const struct watchdog_info sunxi_wdt_info = {
> 
> +	.identity	= DRV_NAME,
> 
> +	.options	= WDIOF_SETTIMEOUT |
> 
> +			  WDIOF_KEEPALIVEPING |
> 
> +			  WDIOF_MAGICCLOSE,
> 
> +};
> 
> +
> 
> +static const struct watchdog_ops sunxi_wdt_ops = {
> 
> +	.owner		= THIS_MODULE,
> 
> +	.start		= sunxi_wdt_start,
> 
> +	.stop		= sunxi_wdt_stop,
> 
> +	.ping		= sunxi_wdt_ping,
> 
> +	.set_timeout	= sunxi_wdt_set_timeout,
> 
> +};
> 
> +
> 
> +static int __init sunxi_wdt_probe(struct platform_device *pdev)
> 
> +{
> 
> +	struct sunxi_wdt_dev *sunxi_wdt;
> 
> +	struct resource *res;
> 
> +	int err;
> 
> +
> 
> +	sunxi_wdt = devm_kzalloc(&pdev->dev, sizeof(*sunxi_wdt), GFP_KERNEL);
> 
> +	if (!sunxi_wdt)
> 
> +		return -EINVAL;
> 
> +
> 
> +	platform_set_drvdata(pdev, sunxi_wdt);
> 
> +
> 
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> 
> +	sunxi_wdt->wdt_base = devm_ioremap_resource(&pdev->dev, res);
> 
> +	if (IS_ERR(sunxi_wdt->wdt_base))
> 
> +		return PTR_ERR(sunxi_wdt->wdt_base);
> 
> +
> 
> +	sunxi_wdt->wdt_dev.info = &sunxi_wdt_info;
> 
> +	sunxi_wdt->wdt_dev.ops = &sunxi_wdt_ops;
> 
> +	sunxi_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
> 
> +	sunxi_wdt->wdt_dev.max_timeout = WDT_MAX_TIMEOUT;
> 
> +	sunxi_wdt->wdt_dev.min_timeout = WDT_MIN_TIMEOUT;
> 
> +	sunxi_wdt->wdt_dev.parent = &pdev->dev;
> 
> +
> 
> +	watchdog_init_timeout(&sunxi_wdt->wdt_dev, heartbeat, &pdev->dev);
> 
> +	watchdog_set_nowayout(&sunxi_wdt->wdt_dev, nowayout);
> 
> +
> 
> +	watchdog_set_drvdata(&sunxi_wdt->wdt_dev, sunxi_wdt);
> 
> +
> 
> +	err = watchdog_register_device(&sunxi_wdt->wdt_dev);
> 
> +	if (unlikely(err))
> 
> +		return err;
> 
> +
> 
> +	dev_info(&pdev->dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)",
> 
> +			sunxi_wdt->wdt_dev.timeout, nowayout);
> 
> +
> 
> +	return 0;
> 
> +}
> 
> +
> 
> +static int __exit sunxi_wdt_remove(struct platform_device *pdev)
> 
> +{
> 
> +	struct sunxi_wdt_dev *sunxi_wdt = platform_get_drvdata(pdev);
> 
> +
> 
> +	watchdog_unregister_device(&sunxi_wdt->wdt_dev);
> 
> +	watchdog_set_drvdata(&sunxi_wdt->wdt_dev, NULL);
> 
> +
> 
> +	return 0;
> 
> +}
> 
> +
> 
> +static const struct of_device_id sunxi_wdt_dt_ids[] = {
> 
> +	{ .compatible = "allwinner,sun4i-wdt" },
> 
> +	{ /* sentinel */ }
> 
> +};
> 
> +MODULE_DEVICE_TABLE(of, sunxi_wdt_dt_ids);
> 
> +
> 
> +static struct platform_driver sunxi_wdt_driver = {
> 
> +	.probe		= sunxi_wdt_probe,
> 
> +	.remove		= sunxi_wdt_remove,
> 
> +	.driver		= {
> 
> +		.owner		= THIS_MODULE,
> 
> +		.name		= DRV_NAME,
> 
> +		.of_match_table	= of_match_ptr(sunxi_wdt_dt_ids)
> 
> +	},
> 
> +};
> 
> +
> 
> +module_platform_driver(sunxi_wdt_driver);
> 
> +
> 
> +module_param(heartbeat, int, 0);
> 
> +MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");
> 
> +
> 
> +module_param(nowayout, bool, 0);
> 
> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
> 
> +		"(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> 
> +
> 
> +MODULE_LICENSE("GPL");
> 
> +MODULE_AUTHOR("Carlo Caione <carlo.caione at gmail.com>");
> 
> +MODULE_AUTHOR("Henrik Nordstrom <henrik at henriknordstrom.net>");
> 
> +MODULE_DESCRIPTION("sunxi WatchDog Timer Driver");
> 
> +MODULE_VERSION(DRV_VERSION);
> 
> -- 
> 
> 1.8.2.3

Hi Carlo,

It is not possible to enable this driver because there is no 'ARCH_SUNXI' in default .config. What you intended to use, 'ARCH_SUNXI' or 'ARCH_SUN4I'? RTC driver presents the same issue.

From bhelgaas at google.com  Sat Jul  6 11:40:55 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Sat, 6 Jul 2013 09:40:55 -0600
Subject: [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
In-Reply-To: <20130706135433.GL2569@titan.lakedaemon.net>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-4-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo73iSBg+SYwZLea0qdXD1uVc3+Vacd8Tg4CU92vLG=2AQ@mail.gmail.com>
 <20130705234501.1341f52e@skate> <20130706135433.GL2569@titan.lakedaemon.net>
Message-ID: <CAErSpo4uN2MifYHbFiUfQ+6TE-hBkbWYdnAvabj8jCTOd5g+1A@mail.gmail.com>

On Sat, Jul 6, 2013 at 7:54 AM, Jason Cooper <jason at lakedaemon.net> wrote:
> On Fri, Jul 05, 2013 at 11:45:01PM +0200, Thomas Petazzoni wrote:
>> Dear Bjorn Helgaas,
>>
>> On Fri, 5 Jul 2013 15:37:33 -0600, Bjorn Helgaas wrote:
>>
>> > Acked-by: Bjorn Helgaas <bhelgaas at google.com>
>> >
>> > Again, please update the subject line to "PCI: Remove ..."
>> >
>> > I doubt that you'll get explicit acks from all the arches you touched,
>> > but I think it's reasonable to put at least patches 2 & 3 in -next
>> > soon after v3.11-rc1, so we should have time to shake out issues.
>>
>> Sure. Which merge strategy do you suggest for this patch series, which
>> touches a number of different areas, and has some build-time
>> dependencies between the patches (if needed, I can detail those build
>> time dependencies to help figuring out the best strategy).
>
> If we end up handling this the same as the of/pci & mvebu-pcie series
> (whole series through mvebu -> arm-soc) I can have it up in -next within
> a few days of -rc1.  Just let me know.

That sounds fine with me.  I don't think it's worth trying to split
out the drivers/pci stuff and trying to coordinate it going through
different trees.


From jason at lakedaemon.net  Sat Jul  6 12:17:43 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Sat, 6 Jul 2013 12:17:43 -0400
Subject: [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
In-Reply-To: <CAErSpo4uN2MifYHbFiUfQ+6TE-hBkbWYdnAvabj8jCTOd5g+1A@mail.gmail.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-4-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo73iSBg+SYwZLea0qdXD1uVc3+Vacd8Tg4CU92vLG=2AQ@mail.gmail.com>
 <20130705234501.1341f52e@skate>
 <20130706135433.GL2569@titan.lakedaemon.net>
 <CAErSpo4uN2MifYHbFiUfQ+6TE-hBkbWYdnAvabj8jCTOd5g+1A@mail.gmail.com>
Message-ID: <20130706161743.GM2569@titan.lakedaemon.net>

On Sat, Jul 06, 2013 at 09:40:55AM -0600, Bjorn Helgaas wrote:
> On Sat, Jul 6, 2013 at 7:54 AM, Jason Cooper <jason at lakedaemon.net> wrote:
> > On Fri, Jul 05, 2013 at 11:45:01PM +0200, Thomas Petazzoni wrote:
> >> Dear Bjorn Helgaas,
> >>
> >> On Fri, 5 Jul 2013 15:37:33 -0600, Bjorn Helgaas wrote:
> >>
> >> > Acked-by: Bjorn Helgaas <bhelgaas at google.com>
> >> >
> >> > Again, please update the subject line to "PCI: Remove ..."
> >> >
> >> > I doubt that you'll get explicit acks from all the arches you touched,
> >> > but I think it's reasonable to put at least patches 2 & 3 in -next
> >> > soon after v3.11-rc1, so we should have time to shake out issues.
> >>
> >> Sure. Which merge strategy do you suggest for this patch series, which
> >> touches a number of different areas, and has some build-time
> >> dependencies between the patches (if needed, I can detail those build
> >> time dependencies to help figuring out the best strategy).
> >
> > If we end up handling this the same as the of/pci & mvebu-pcie series
> > (whole series through mvebu -> arm-soc) I can have it up in -next within
> > a few days of -rc1.  Just let me know.
> 
> That sounds fine with me.  I don't think it's worth trying to split
> out the drivers/pci stuff and trying to coordinate it going through
> different trees.

Ok, will do.

Thomas, I assume there will be one more version to address Bjorn's last
comments?

thx,

Jason.


From thomas.petazzoni at free-electrons.com  Sat Jul  6 12:33:41 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sat, 6 Jul 2013 18:33:41 +0200
Subject: [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
In-Reply-To: <20130706161743.GM2569@titan.lakedaemon.net>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-4-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo73iSBg+SYwZLea0qdXD1uVc3+Vacd8Tg4CU92vLG=2AQ@mail.gmail.com>
 <20130705234501.1341f52e@skate>
 <20130706135433.GL2569@titan.lakedaemon.net>
 <CAErSpo4uN2MifYHbFiUfQ+6TE-hBkbWYdnAvabj8jCTOd5g+1A@mail.gmail.com>
 <20130706161743.GM2569@titan.lakedaemon.net>
Message-ID: <20130706183341.379d2fea@skate>

Dear Jason Cooper,

On Sat, 6 Jul 2013 12:17:43 -0400, Jason Cooper wrote:

> > > If we end up handling this the same as the of/pci & mvebu-pcie series
> > > (whole series through mvebu -> arm-soc) I can have it up in -next within
> > > a few days of -rc1.  Just let me know.
> > 
> > That sounds fine with me.  I don't think it's worth trying to split
> > out the drivers/pci stuff and trying to coordinate it going through
> > different trees.
> 
> Ok, will do.
> 
> Thomas, I assume there will be one more version to address Bjorn's last
> comments?

Yes, indeed. I was waiting to see if Thierry Redding would give some
additional feedback on Bjorn's comment, but if he doesn't, I'll resend
an updated version, most likely next week.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From maxime.ripard at free-electrons.com  Sat Jul  6 12:37:02 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat, 6 Jul 2013 18:37:02 +0200
Subject: [PATCH v5] ARM: sunxi: New watchdog driver for Allwinner A10/A13
In-Reply-To: <80d67226-1d83-475a-a94c-cfecc1cd277e@googlegroups.com>
References: <1370547265-24854-1-git-send-email-carlo.caione@gmail.com>
 <80d67226-1d83-475a-a94c-cfecc1cd277e@googlegroups.com>
Message-ID: <20130706163702.GA11243@lukather>

On Sat, Jul 06, 2013 at 07:39:13AM -0700, viniciusfre at gmail.com wrote:
> Hi Carlo,
> 
> It is not possible to enable this driver because there is no
> 'ARCH_SUNXI' in default .config. What you intended to use,
> 'ARCH_SUNXI' or 'ARCH_SUN4I'? RTC driver presents the same issue.

This driver is intended for the mainline Linux Kernel, where ARCH_SUN4i
doesn't exist, and ARCH_SUNXI actually does.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130706/cc645530/attachment.sig>

From maxime.ripard at free-electrons.com  Sat Jul  6 12:39:53 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat, 6 Jul 2013 18:39:53 +0200
Subject: [linux-sunxi] [PATCH v5] ARM: sunxi: New watchdog driver for
 Allwinner A10/A13
In-Reply-To: <1370547265-24854-1-git-send-email-carlo.caione@gmail.com>
References: <1370547265-24854-1-git-send-email-carlo.caione@gmail.com>
Message-ID: <20130706163953.GB11243@lukather>

Wim,

On Thu, Jun 06, 2013 at 09:34:25PM +0200, Carlo Caione wrote:
> This patch adds the driver for the watchdog found in the Allwinner A10 and
> A13 SoCs. It has DT-support and uses the new watchdog framework.
> 
> Signed-off-by: Carlo Caione <carlo.caione at gmail.com>

This patch has been sent over a month ago now, without any review or
comments from your part.

Do you intend to merge it at some point?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130706/495e7dc7/attachment.sig>

From mpa at pengutronix.de  Sat Jul  6 13:13:23 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 6 Jul 2013 19:13:23 +0200
Subject: [PATCH v9 04/10] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <20130703160637.GQ27646@sirena.org.uk>
References: <1371734429-6081-1-git-send-email-mpa@pengutronix.de>
 <1371734429-6081-5-git-send-email-mpa@pengutronix.de>
 <20130703160637.GQ27646@sirena.org.uk>
Message-ID: <20130706171323.GG16871@s25.your-server.de>

Hi Mark,

On Wed, Jul 03, 2013 at 05:06:37PM +0100, Mark Brown wrote:
> On Thu, Jun 20, 2013 at 03:20:23PM +0200, Markus Pargmann wrote:
> 
> > +	ssi_private->use_dma = !of_property_read_bool(np, "fsl,imx-fiq");
> > +
> 
> This binding should be documented.  I'm not sure it really needs to be
> a binding, though - is it not possible for the driver to just figure out
> that DMA won't work automatically (for example by looking at the CODEC
> in use)?  I'm not sure this is a good name either, it should be saying
> why the FIQ is needed rather than saying that we should use the FIQ.

I think fsl_ssi_startup is the first function in which we know which
codec is connected to fsl-ssi. There we have access to the pcm runtime,
which stores the codec used. But that is too late for the ssi setup.

I could use of_find_compatible_node to search for the wm9712 codec, but
that would assume that there is only one codec attached to the system.

Perhaps "fsl,fiq-filter-codec-stream" is a better name for the binding?

Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From viniciusfre at gmail.com  Sat Jul  6 13:29:44 2013
From: viniciusfre at gmail.com (viniciusfre at gmail.com)
Date: Sat, 6 Jul 2013 10:29:44 -0700 (PDT)
Subject: [PATCH v5] ARM: sunxi: New watchdog driver for Allwinner A10/A13
In-Reply-To: <1370547265-24854-1-git-send-email-carlo.caione@gmail.com>
References: <1370547265-24854-1-git-send-email-carlo.caione@gmail.com>
Message-ID: <09c7fd3c-063b-4af4-bace-e148831a7e50@googlegroups.com>

Em quinta-feira, 6 de junho de 2013 16h34min25s UTC-3, Carlo Caione  escreveu:
> This patch adds the driver for the watchdog found in the Allwinner A10 and
> 
> A13 SoCs. It has DT-support and uses the new watchdog framework.
> 
> 
> 
> Signed-off-by: Carlo Caione <carlo.caione at gmail.com>
> 
> ---
> 
>  drivers/watchdog/Kconfig     |  10 ++
> 
>  drivers/watchdog/Makefile    |   1 +
> 
>  drivers/watchdog/sunxi_wdt.c | 231 +++++++++++++++++++++++++++++++++++++++++++
> 
>  3 files changed, 242 insertions(+)
> 
>  create mode 100644 drivers/watchdog/sunxi_wdt.c
> 
> 
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> 
> index e89fc31..8ad2238 100644
> 
> --- a/drivers/watchdog/Kconfig
> 
> +++ b/drivers/watchdog/Kconfig
> 
> @@ -299,6 +299,16 @@ config ORION_WATCHDOG
> 
>  	  To compile this driver as a module, choose M here: the
> 
>  	  module will be called orion_wdt.
> 
>  
> 
> +config SUNXI_WATCHDOG
> 
> +	tristate "Allwinner SoCs watchdog support"
> 
> +	depends on ARCH_SUNXI
> 
> +	select WATCHDOG_CORE
> 
> +	help
> 
> +	  Say Y here to include support for the watchdog timer
> 
> +	  in Allwinner SoCs.
> 
> +	  To compile this driver as a module, choose M here: the
> 
> +	  module will be called sunxi_wdt.
> 
> +
> 
>  config COH901327_WATCHDOG
> 
>  	bool "ST-Ericsson COH 901 327 watchdog"
> 
>  	depends on ARCH_U300
> 
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> 
> index a300b94..5012d5f 100644
> 
> --- a/drivers/watchdog/Makefile
> 
> +++ b/drivers/watchdog/Makefile
> 
> @@ -47,6 +47,7 @@ obj-$(CONFIG_PNX4008_WATCHDOG) += pnx4008_wdt.o
> 
>  obj-$(CONFIG_IOP_WATCHDOG) += iop_wdt.o
> 
>  obj-$(CONFIG_DAVINCI_WATCHDOG) += davinci_wdt.o
> 
>  obj-$(CONFIG_ORION_WATCHDOG) += orion_wdt.o
> 
> +obj-$(CONFIG_SUNXI_WATCHDOG) += sunxi_wdt.o
> 
>  obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
> 
>  obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
> 
>  obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
> 
> diff --git a/drivers/watchdog/sunxi_wdt.c b/drivers/watchdog/sunxi_wdt.c
> 
> new file mode 100644
> 
> index 0000000..69d4d44
> 
> --- /dev/null
> 
> +++ b/drivers/watchdog/sunxi_wdt.c
> 
> @@ -0,0 +1,231 @@
> 
> +/*
> 
> + *      sunxi Watchdog Driver
> 
> + *
> 
> + *      Copyright (c) 2013 Carlo Caione
> 
> + *                    2012 Henrik Nordstrom
> 
> + *
> 
> + *      This program is free software; you can redistribute it and/or
> 
> + *      modify it under the terms of the GNU General Public License
> 
> + *      as published by the Free Software Foundation; either version
> 
> + *      2 of the License, or (at your option) any later version.
> 
> + *
> 
> + *      Based on xen_wdt.c
> 
> + *      (c) Copyright 2010 Novell, Inc.
> 
> + */
> 
> +
> 
> +#include <linux/clk.h>
> 
> +#include <linux/err.h>
> 
> +#include <linux/init.h>
> 
> +#include <linux/io.h>
> 
> +#include <linux/kernel.h>
> 
> +#include <linux/module.h>
> 
> +#include <linux/moduleparam.h>
> 
> +#include <linux/of.h>
> 
> +#include <linux/of_address.h>
> 
> +#include <linux/platform_device.h>
> 
> +#include <linux/types.h>
> 
> +#include <linux/watchdog.h>
> 
> +
> 
> +#define WDT_MAX_TIMEOUT         16
> 
> +#define WDT_MIN_TIMEOUT         1
> 
> +#define WDT_MODE_TIMEOUT(n)     ((n) << 3)
> 
> +#define WDT_TIMEOUT_MASK        WDT_MODE_TIMEOUT(0x0F)
> 
> +
> 
> +#define WDT_CTRL                0x00
> 
> +#define WDT_CTRL_RELOAD         ((1 << 0) | (0x0a57 << 1))
> 
> +
> 
> +#define WDT_MODE                0x04
> 
> +#define WDT_MODE_EN             (1 << 0)
> 
> +#define WDT_MODE_RST_EN         (1 << 1)
> 
> +
> 
> +#define DRV_NAME		"sunxi-wdt"
> 
> +#define DRV_VERSION		"1.0"
> 
> +
> 
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> 
> +static int heartbeat = WDT_MAX_TIMEOUT;
> 
> +
> 
> +struct sunxi_wdt_dev {
> 
> +	struct watchdog_device wdt_dev;
> 
> +	void __iomem *wdt_base;
> 
> +};
> 
> +
> 
> +/*
> 
> + * wdt_timeout_map maps the watchdog timer interval value in seconds to
> 
> + * the value of the register WDT_MODE bit 3:6
> 
> + *
> 
> + * [timeout seconds] = register value
> 
> + *
> 
> + */
> 
> +
> 
> +static const int wdt_timeout_map[] = {
> 
> +	[1] = 0b0001,  /* 1s  */
> 
> +	[2] = 0b0010,  /* 2s  */
> 
> +	[3] = 0b0011,  /* 3s  */
> 
> +	[4] = 0b0100,  /* 4s  */
> 
> +	[5] = 0b0101,  /* 5s  */
> 
> +	[6] = 0b0110,  /* 6s  */
> 
> +	[8] = 0b0111,  /* 8s  */
> 
> +	[10] = 0b1000, /* 10s */
> 
> +	[12] = 0b1001, /* 12s */
> 
> +	[14] = 0b1010, /* 14s */
> 
> +	[16] = 0b1011, /* 16s */
> 
> +};
> 
> +
> 
> +static int sunxi_wdt_ping(struct watchdog_device *wdt_dev)
> 
> +{
> 
> +	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
> 
> +	void __iomem *wdt_base = sunxi_wdt->wdt_base;
> 
> +
> 
> +	iowrite32(WDT_CTRL_RELOAD, wdt_base + WDT_CTRL);
> 
> +
> 
> +	return 0;
> 
> +}
> 
> +
> 
> +static int sunxi_wdt_set_timeout(struct watchdog_device *wdt_dev,
> 
> +		unsigned int timeout)
> 
> +{
> 
> +	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
> 
> +	void __iomem *wdt_base = sunxi_wdt->wdt_base;
> 
> +	u32 reg;
> 
> +
> 
> +	if (timeout > WDT_MAX_TIMEOUT)
> 
> +		return -EINVAL;
> 
> +
> 
> +	if (wdt_timeout_map[timeout] == 0)
> 
> +		timeout++;
> 
> +
> 
> +	sunxi_wdt->wdt_dev.timeout = timeout;
> 
> +
> 
> +	reg = ioread32(wdt_base + WDT_MODE);
> 
> +	reg &= ~WDT_TIMEOUT_MASK;
> 
> +	reg |= WDT_MODE_TIMEOUT(wdt_timeout_map[timeout]);
> 
> +	iowrite32(reg, wdt_base + WDT_MODE);
> 
> +
> 
> +	sunxi_wdt_ping(wdt_dev);
> 
> +
> 
> +	return 0;
> 
> +}
> 
> +
> 
> +static int sunxi_wdt_stop(struct watchdog_device *wdt_dev)
> 
> +{
> 
> +	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
> 
> +	void __iomem *wdt_base = sunxi_wdt->wdt_base;
> 
> +
> 
> +	iowrite32(0, wdt_base + WDT_MODE);
> 
> +
> 
> +	return 0;
> 
> +}
> 
> +
> 
> +static int sunxi_wdt_start(struct watchdog_device *wdt_dev)
> 
> +{
> 
> +	u32 reg;
> 
> +	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
> 
> +	void __iomem *wdt_base = sunxi_wdt->wdt_base;
> 
> +	int ret;
> 
> +
> 
> +	ret = sunxi_wdt_set_timeout(&sunxi_wdt->wdt_dev,
> 
> +			sunxi_wdt->wdt_dev.timeout);
> 
> +	if (ret < 0)
> 
> +		return ret;
> 
> +
> 
> +	reg = ioread32(wdt_base + WDT_MODE);
> 
> +	reg |= (WDT_MODE_RST_EN | WDT_MODE_EN);
> 
> +	iowrite32(reg, wdt_base + WDT_MODE);
> 
> +
> 
> +	return 0;
> 
> +}
> 
> +
> 
> +static const struct watchdog_info sunxi_wdt_info = {
> 
> +	.identity	= DRV_NAME,
> 
> +	.options	= WDIOF_SETTIMEOUT |
> 
> +			  WDIOF_KEEPALIVEPING |
> 
> +			  WDIOF_MAGICCLOSE,
> 
> +};
> 
> +
> 
> +static const struct watchdog_ops sunxi_wdt_ops = {
> 
> +	.owner		= THIS_MODULE,
> 
> +	.start		= sunxi_wdt_start,
> 
> +	.stop		= sunxi_wdt_stop,
> 
> +	.ping		= sunxi_wdt_ping,
> 
> +	.set_timeout	= sunxi_wdt_set_timeout,
> 
> +};
> 
> +
> 
> +static int __init sunxi_wdt_probe(struct platform_device *pdev)
> 
> +{
> 
> +	struct sunxi_wdt_dev *sunxi_wdt;
> 
> +	struct resource *res;
> 
> +	int err;
> 
> +
> 
> +	sunxi_wdt = devm_kzalloc(&pdev->dev, sizeof(*sunxi_wdt), GFP_KERNEL);
> 
> +	if (!sunxi_wdt)
> 
> +		return -EINVAL;
> 
> +
> 
> +	platform_set_drvdata(pdev, sunxi_wdt);
> 
> +
> 
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> 
> +	sunxi_wdt->wdt_base = devm_ioremap_resource(&pdev->dev, res);
> 
> +	if (IS_ERR(sunxi_wdt->wdt_base))
> 
> +		return PTR_ERR(sunxi_wdt->wdt_base);
> 
> +
> 
> +	sunxi_wdt->wdt_dev.info = &sunxi_wdt_info;
> 
> +	sunxi_wdt->wdt_dev.ops = &sunxi_wdt_ops;
> 
> +	sunxi_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
> 
> +	sunxi_wdt->wdt_dev.max_timeout = WDT_MAX_TIMEOUT;
> 
> +	sunxi_wdt->wdt_dev.min_timeout = WDT_MIN_TIMEOUT;
> 
> +	sunxi_wdt->wdt_dev.parent = &pdev->dev;
> 
> +
> 
> +	watchdog_init_timeout(&sunxi_wdt->wdt_dev, heartbeat, &pdev->dev);
> 
> +	watchdog_set_nowayout(&sunxi_wdt->wdt_dev, nowayout);
> 
> +
> 
> +	watchdog_set_drvdata(&sunxi_wdt->wdt_dev, sunxi_wdt);
> 
> +
> 
> +	err = watchdog_register_device(&sunxi_wdt->wdt_dev);
> 
> +	if (unlikely(err))
> 
> +		return err;
> 
> +
> 
> +	dev_info(&pdev->dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)",
> 
> +			sunxi_wdt->wdt_dev.timeout, nowayout);
> 
> +
> 
> +	return 0;
> 
> +}
> 
> +
> 
> +static int __exit sunxi_wdt_remove(struct platform_device *pdev)
> 
> +{
> 
> +	struct sunxi_wdt_dev *sunxi_wdt = platform_get_drvdata(pdev);
> 
> +
> 
> +	watchdog_unregister_device(&sunxi_wdt->wdt_dev);
> 
> +	watchdog_set_drvdata(&sunxi_wdt->wdt_dev, NULL);
> 
> +
> 
> +	return 0;
> 
> +}
> 
> +
> 
> +static const struct of_device_id sunxi_wdt_dt_ids[] = {
> 
> +	{ .compatible = "allwinner,sun4i-wdt" },
> 
> +	{ /* sentinel */ }
> 
> +};
> 
> +MODULE_DEVICE_TABLE(of, sunxi_wdt_dt_ids);
> 
> +
> 
> +static struct platform_driver sunxi_wdt_driver = {
> 
> +	.probe		= sunxi_wdt_probe,
> 
> +	.remove		= sunxi_wdt_remove,
> 
> +	.driver		= {
> 
> +		.owner		= THIS_MODULE,
> 
> +		.name		= DRV_NAME,
> 
> +		.of_match_table	= of_match_ptr(sunxi_wdt_dt_ids)
> 
> +	},
> 
> +};
> 
> +
> 
> +module_platform_driver(sunxi_wdt_driver);
> 
> +
> 
> +module_param(heartbeat, int, 0);
> 
> +MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");
> 
> +
> 
> +module_param(nowayout, bool, 0);
> 
> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
> 
> +		"(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> 
> +
> 
> +MODULE_LICENSE("GPL");
> 
> +MODULE_AUTHOR("Carlo Caione <carlo.caione at gmail.com>");
> 
> +MODULE_AUTHOR("Henrik Nordstrom <henrik at henriknordstrom.net>");
> 
> +MODULE_DESCRIPTION("sunxi WatchDog Timer Driver");
> 
> +MODULE_VERSION(DRV_VERSION);
> 
> -- 
> 
> 1.8.2.3

Ok, sorry about that. Anyway, this driver can be not used in linux-sunxi?

From maxime.ripard at free-electrons.com  Sat Jul  6 13:43:15 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sat, 6 Jul 2013 19:43:15 +0200
Subject: [PATCH v5] ARM: sunxi: New watchdog driver for Allwinner A10/A13
In-Reply-To: <09c7fd3c-063b-4af4-bace-e148831a7e50@googlegroups.com>
References: <1370547265-24854-1-git-send-email-carlo.caione@gmail.com>
 <09c7fd3c-063b-4af4-bace-e148831a7e50@googlegroups.com>
Message-ID: <20130706174315.GC11243@lukather>

On Sat, Jul 06, 2013 at 10:29:44AM -0700, viniciusfre at gmail.com wrote:
> Ok, sorry about that. Anyway, this driver can be not used in
> linux-sunxi?

It's already in use in linux-sunxi.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130706/63fd904c/attachment.sig>

From arnd at arndb.de  Sat Jul  6 15:06:49 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 06 Jul 2013 21:06:49 +0200
Subject: MTD EEPROM support and driver integration
In-Reply-To: <20130706120112.GA11069@lukather>
References: <20130705201118.GM2959@lukather> <5811519.oHVuMujf0I@wuerfel>
 <20130706120112.GA11069@lukather>
Message-ID: <8997501.Dchyii8uWX@wuerfel>

On Saturday 06 July 2013 14:01:12 Maxime Ripard wrote:
> I'm not exactly sure on what happened to the previous mail that has been
> sent empty, but anyway:
> 
> On Sat, Jul 06, 2013 at 11:18:00AM +0200, Arnd Bergmann wrote:
> > On Saturday 06 July 2013 10:28:04 Maxime Ripard wrote:
> > > > a) like interrupts, regs, dmas, clocks, pinctrl, reset, pwm: fixed property names
> > > > 
> > > >       regmap = <&at25 0xstart 0xlen>;
> > > >       regmap-names = "mac-address";
> > > > 
> > > > b) like gpio, regulator: variable property names
> > > > 
> > > >       mac-storage = <&at25 0xstart 0xlen>;
> > > > 
> > > > It's unfortunate that we already have examples of both. They are largely
> > > > equivalent, but the tendency is towards the first.
> > > 
> > > I don't have a strong feeling for one against another, so whatever works
> > > best. Both solutions will be a huge improvement anyway 
> > > 
> > > Just out of curiosity, is there any advantages besides having a fixed
> > > property name to the first solution?
> > 
> > I think it's mostly for consistency: trying to get most subsystems to
> > do it the same way to make it easier for people to write dts files.
> > 
> > A lesser point is that it simplifies the driver code if you don't
> > have to pass a name.
> 
> So that leave us with mainly one path to achieve this goal:
>   - Add a regmap-mtd backend
>   - Add DT parsing code for regmap
>   - Move the EEPROM drivers from misc to mtd

Yes, I think that would be good. For the last step, we definitely need
buy-in from Wolfgand and Jean, as they are maintaining the current eeprom
drivers.

> What other option would we have?
> 
> I also thought about writing an EEPROM framework of its own, but the
> line is really thin between a large EEPROM and say a small SPI
> dataflash, which would make it pretty hard to choose between such a
> framework and MTD.

Isn't flash by definition block based, while EEPROM can be written
in byte or word units? I think that is a significant difference, although
it doesn't necessarily mean that we can't use MTD for both.

We also have a bunch of OTP drivers spread around the kernel, it probably
makes sense to consolidate them at the same time, at least on the DT binding
side if not the device drivers.

	Arnd


From gregkh at linuxfoundation.org  Sat Jul  6 15:36:46 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Sat, 6 Jul 2013 12:36:46 -0700
Subject: [PATCH 1/2] Initial support for Allwinner's Security ID fuses
In-Reply-To: <51D674BF.9030207@schinagl.nl>
References: <20130617225847.GA9494@kroah.com> <20130624092942.GG26008@lukather>
 <20130624160440.GA15201@kroah.com> <51C87DC7.50005@schinagl.nl>
 <20130624181509.GA8847@kroah.com> <51C8B84C.3020200@schinagl.nl>
 <20130624214615.GA17604@kroah.com> <51CAA709.4060801@schinagl.nl>
 <20130626175144.GC2222@kroah.com> <51D674BF.9030207@schinagl.nl>
Message-ID: <20130706193646.GB9778@kroah.com>

On Fri, Jul 05, 2013 at 09:24:47AM +0200, Oliver Schinagl wrote:
> The other 'broken' drivers that where linked earlier, also use the
> BINARY attributes.
> 
> So Greg, if you could be so kind and give me an example how to
> implement this properly, I am at loss and don't know :(

Ah crap, devices don't have a binary attribute group, like struct class
does.  I'll go add that on Monday and send you the patch to see if that
helps you out.  I'll also go through and fix up all of the binary
attribute drivers to keep them from doing that...

Sorry, I missed that earlier, but thanks for trying and pointing out my
mistake.

greg k-h


From jogo at openwrt.org  Sat Jul  6 15:54:26 2013
From: jogo at openwrt.org (Jonas Gorski)
Date: Sat, 6 Jul 2013 21:54:26 +0200
Subject: Second ethernet on kirkwood does not work when probed through DT
Message-ID: <20130706215426.6e666d6af0dc6c9ea5fe32cd@openwrt.org>

Hello Sebastian,

using your DT patches[1] (on top of 3.10) I can't get the second ethernet to work on my kirkwood board.

in my dts file I use:

&mdio {
        status = "okay";
};

&eth0 {
        status = "okay";
        ethernet0-port at 0 {
                speed = <1000>;
                duplex = <1>;
        };
};

&eth1 {
        status = "okay";
        ethernet1-port at 1 {
                speed = <1000>;
                duplex = <1>;
        };
};

(Both macs are connected to a switch, so use a fixed link, and no phy).

Eth1 gets probed fine, but never gets a link when brought up, and trying to bring it down again hangs the board hard.

Using Florian's older patches, it is brought up fine and works (after adapting the node names of course).

Also I noticed that you named eth1's ethernet1-port node wrongly in (at least) your kirkwood conversion patch[2]; you used

&eth1 {
	status = "okay";
	ethernet1-port at 0 {
           must be @1--^
		phy-handle = <&ethphy1>;
	};
};

which results in a null pointer access on boot:

...
[   12.627136] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address ...
[   12.635955] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   12.644100] pgd = c0004000
[   12.646821] [00000000] *pgd=00000000
[   12.650418] Internal error: Oops: 5 [#1] ARM
[   12.654702] Modules linked in:
[   12.657778] CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0 #10
[   12.663634] task: c7827d60 ti: c782e000 task.ti: c782e000
[   12.669073] PC is at mv643xx_eth_probe+0x98/0x708
...


Regards
Jonas

P.S: I'm not on any ML you posted these patches to, so I could not reply directly.

[1] https://patchwork.kernel.org/patch/2632571/ etc
[2] https://patchwork.kernel.org/patch/2811861/


From khali at linux-fr.org  Sat Jul  6 15:55:26 2013
From: khali at linux-fr.org (Jean Delvare)
Date: Sat, 6 Jul 2013 21:55:26 +0200
Subject: MTD EEPROM support and driver integration
In-Reply-To: <8997501.Dchyii8uWX@wuerfel>
References: <20130705201118.GM2959@lukather> <5811519.oHVuMujf0I@wuerfel>
 <20130706120112.GA11069@lukather> <8997501.Dchyii8uWX@wuerfel>
Message-ID: <20130706215526.7fc3e191@endymion.delvare>

On Sat, 06 Jul 2013 21:06:49 +0200, Arnd Bergmann wrote:
> On Saturday 06 July 2013 14:01:12 Maxime Ripard wrote:
> > So that leave us with mainly one path to achieve this goal:
> >   - Add a regmap-mtd backend
> >   - Add DT parsing code for regmap
> >   - Move the EEPROM drivers from misc to mtd
> 
> Yes, I think that would be good. For the last step, we definitely need
> buy-in from Wolfgand and Jean, as they are maintaining the current eeprom
> drivers.

I am maintaining the legacy eeprom driver, which nobody should be using
in conjunction with DT. So you don't need my approval for anything.

-- 
Jean Delvare


From ulrich.prinz at googlemail.com  Sat Jul  6 16:19:14 2013
From: ulrich.prinz at googlemail.com (Ulrich Prinz)
Date: Sat, 06 Jul 2013 22:19:14 +0200
Subject: [PATCH 3/9] clocksource: dw_apb_timer: quirk for variants with
 64bit counter
In-Reply-To: <alpine.DEB.2.02.1307060129340.32106@ionos.tec.linutronix.de>
References: <201307060051.09716.heiko@sntech.de>
 <201307060053.10182.heiko@sntech.de>
 <alpine.DEB.2.02.1307060129340.32106@ionos.tec.linutronix.de>
Message-ID: <51D87BC2.5060507@googlemail.com>

Hi Thomas,

sorry but it is my first release to the kernel and I was trained to take
as less as possible influence on existing code and reuse as much as
possible existing code.

Sometimes just two rules are to simple...

Am 06.07.2013 01:45, schrieb Thomas Gleixner:
> On Sat, 6 Jul 2013, Heiko St?bner wrote:
> 
>> This adds a quirk for IP variants containing two load_count and value
>> registers that are used to provide 64bit accuracy on 32bit systems.
>>
>> The added accuracy is currently not used, the driver is only adapted to
>> handle the different register layout and make it work on affected devices.
>>
>> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
>> ---
>>  drivers/clocksource/dw_apb_timer.c |   27 +++++++++++++++++++++++++++
>>  include/linux/dw_apb_timer.h       |    6 ++++++
>>  2 files changed, 33 insertions(+)
>>
>> diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
>> index f5e7be8..bd45351 100644
>> --- a/drivers/clocksource/dw_apb_timer.c
>> +++ b/drivers/clocksource/dw_apb_timer.c
>> @@ -56,6 +56,17 @@ static void apbt_init_regs(struct dw_apb_timer *timer, int quirks)
>>  	timer->reg_control = APBTMR_N_CONTROL;
>>  	timer->reg_eoi = APBTMR_N_EOI;
>>  	timer->reg_int_status = APBTMR_N_INT_STATUS;
>> +
>> +	/*
>> +	 * On variants with 64bit counters some registers are
>> +	 * moved further down.
>> +	 */
>> +	if (quirks & APBTMR_QUIRK_64BIT_COUNTER) {
>> +		timer->reg_current_value += 0x4;
>> +		timer->reg_control += 0x8;
>> +		timer->reg_eoi += 0x8;
>> +		timer->reg_int_status += 0x8;
>> +	}
>>  }
> 
> Oh, no. this is not how we handle these things.
> 
> 1) We want proper constants for this 64bit IP block 

ACK
> 
> 2) This is not a quirk, it's a property of that particular IP block

Ok, noted and will be reworked.
> 
> You already made the register offsets a part of the timer structure,
> so why don't you supply a proper structure filled with that values to
> the init function?
> 
> That's what we do all over the place. Either we instantiate those
> structs at compile time or runtime fed by device tree or any other
> configuration mechanism.
>   
Lesson learned, will be reworked. But taking the other comments and
remarks into account this leads to an integration into a single new
patch inheriting this new driver path.

>>  static unsigned long apbt_readl(struct dw_apb_timer *timer, unsigned long offs)
>> @@ -145,6 +156,10 @@ static void apbt_set_mode(enum clock_event_mode mode,
>>  		udelay(1);
>>  		pr_debug("Setting clock period %lu for HZ %d\n", period, HZ);
>>  		apbt_writel(timer, period, timer->reg_load_count);
>> +
>> +		if (timer->quirks & APBTMR_QUIRK_64BIT_COUNTER)
>> +			apbt_writel(timer, 0, timer->reg_load_count + 0x4);
>> +
> 
> No. We are not adding such conditional constructs when we can deal
> with them just by providing a proper set of function pointers. And
> definitely not with hardcoded magic 0x4 constants involved.
> 
>      timer->load_count(timer, value);
> 
> Provide a 32 bit and a 64 bit version of that function and be done
> with it.

For the first version, 64bit will not be supported cause of lack of
information and testing. But is it an option to control the load of
functions by dtsi according this way:

dw-apb-timer-osc: will load standard function to load timer
rk3188-dw-apb-timer-osc: will load 32bit variant of 64bit registers
rk3188-dw-apb-timer64-osc: will load 64bit variant of 64bit registers

> 
> 
> Copy and paste is a conveniant thing, right? It just should have a pop
> up window assigned which asks at the second instance of copying the
> same thing whether you really thought about it.

We thought about and tested a lot. But the problem is that if you find a
bug in one copy of it, you (or anyone else inspecting the code) need to
find all the other copies. In such manor a c'n'p solution is always bad.

Regards,
	Ulrich


From javier.picorel at epfl.ch  Sat Jul  6 16:21:54 2013
From: javier.picorel at epfl.ch (Javier Picorel)
Date: Sat, 6 Jul 2013 20:21:54 +0000
Subject: ARM Cortex A9: LL counters
In-Reply-To: <20130705101208.GC13063@mudshark.cambridge.arm.com>
References: <BFCB49997E59134AAAF17FFE77F8FF06673738BC@REXMD.intranet.epfl.ch>
 <20130704094516.GC8782@mudshark.cambridge.arm.com>
 <BFCB49997E59134AAAF17FFE77F8FF06673759E9@REXMD.intranet.epfl.ch>,
 <20130705101208.GC13063@mudshark.cambridge.arm.com>
Message-ID: <BFCB49997E59134AAAF17FFE77F8FF0667377216@REXMD.intranet.epfl.ch>

That will be perfect. Is there any way to access these memory mapped counters?
________________________________________
From: Will Deacon [will.deacon at arm.com]
Sent: 05 July 2013 12:12
To: Javier Picorel
Cc: linux-arm-kernel at lists.infradead.org; Mark Rutland
Subject: Re: ARM Cortex A9: LL counters

On Fri, Jul 05, 2013 at 12:44:58AM +0100, Javier Picorel wrote:
> Thanks for the clarification! However, correct me if I'm wrong but, doesn't this mean that the "CO_LF_MISS" counter refers to L2 accesses? Thanks!

It will certainly account for some of them, but I wouldn't be surprised if
you can generate L2 accesses in ways other than missing at coherent L1.

You could look at the L2 counters and compare.

Will


From ulrich.prinz at googlemail.com  Sat Jul  6 16:28:52 2013
From: ulrich.prinz at googlemail.com (Ulrich Prinz)
Date: Sat, 06 Jul 2013 22:28:52 +0200
Subject: [PATCH 9/9] clocksource: dw_apb_timer: special variant for
 rockchip rk3188 timers
In-Reply-To: <alpine.DEB.2.02.1307060153110.32106@ionos.tec.linutronix.de>
References: <201307060051.09716.heiko@sntech.de>
 <201307060056.29370.heiko@sntech.de>
 <alpine.DEB.2.02.1307060153110.32106@ionos.tec.linutronix.de>
Message-ID: <51D87E04.3060704@googlemail.com>

Ok, ok...

I got the message. With modifying the existing driver to support more
function pointers in its system struct and assigning them at the
beginning, and using them on runtime, these quirks are obsolete.

Again, this is the first time I provide code to the kernel officially
and I learned from others that I should try it by modifying not too much
code if not needed.

Adding more function pointers to a system relevant structure, doubling
the number of functions and such didn't look non-invasive to me.

But, I totally agree with your argumentation and I even wanted to do it
in the way you explained in your replies. Just the courage was missing I
guess :)

Regards,
	Ulrich


From tglx at linutronix.de  Sat Jul  6 17:00:30 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sat, 6 Jul 2013 23:00:30 +0200 (CEST)
Subject: [PATCH 9/9] clocksource: dw_apb_timer: special variant for
 rockchip rk3188 timers
In-Reply-To: <51D87E04.3060704@googlemail.com>
References: <201307060051.09716.heiko@sntech.de>
 <201307060056.29370.heiko@sntech.de>
 <alpine.DEB.2.02.1307060153110.32106@ionos.tec.linutronix.de>
 <51D87E04.3060704@googlemail.com>
Message-ID: <alpine.DEB.2.02.1307062233480.32106@ionos.tec.linutronix.de>

Ulrich,

On Sat, 6 Jul 2013, Ulrich Prinz wrote:

> I got the message. With modifying the existing driver to support more
> function pointers in its system struct and assigning them at the
> beginning, and using them on runtime, these quirks are obsolete.

Correct.
 
> Again, this is the first time I provide code to the kernel officially

No problem. That's what code review is about. First post or not.

> and I learned from others that I should try it by modifying not too much
> code if not needed.
> 
> Adding more function pointers to a system relevant structure, doubling
> the number of functions and such didn't look non-invasive to me.

Well, it always depends. If there is a single place to deal with some
oddball hardware, a flag is often the simplest way to go.

If you have to add 10 conditionals in several functions then in a
first step converting the existing implementation into function
pointer calls and then in the next step providing new implementations
for your hardware is most of the time simpler and cleaner.

> But, I totally agree with your argumentation and I even wanted to do it
> in the way you explained in your replies. Just the courage was missing I
> guess :)

Gut feelings are often a better guidance than our self-doubting
intellect. :)

But don't worry. I had to learn it the hard way as well and I still
trip over from time to time.

Thanks,

	tglx


From tglx at linutronix.de  Sat Jul  6 17:07:21 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sat, 6 Jul 2013 23:07:21 +0200 (CEST)
Subject: [PATCHv4 08/10] clocksource: sun4i: Remove TIMER_SCAL variable
In-Reply-To: <20130706081045.GY2959@lukather>
References: <1373062725-19625-1-git-send-email-maxime.ripard@free-electrons.com>
 <1373062725-19625-9-git-send-email-maxime.ripard@free-electrons.com>
 <alpine.DEB.2.02.1307060031030.32106@ionos.tec.linutronix.de>
 <20130706081045.GY2959@lukather>
Message-ID: <alpine.DEB.2.02.1307062301481.32106@ionos.tec.linutronix.de>

On Sat, 6 Jul 2013, Maxime Ripard wrote:
> On Sat, Jul 06, 2013 at 01:17:41AM +0200, Thomas Gleixner wrote:
> > I really recommend that you go out for lots of beer/wine NOW and
> > resume reading this mail when you recovered from that.
> > 
> > I definitely appreciate your responsivness to feedback, but please go
> > back and read my reply to the previous version of this patch
> > carefully. You might eventually find out that I pointed you to another
> > redundant clk_get_rate() call in that code.
> > 
> > After you did this, please go through the other patches in that series
> > and check how many new instances of clk_get_rate() calls you add down
> > the road. I did not even bother to look whether you cleaned it up
> > between v3 and v4, but I'm quite sure you did not. If I'm wrong, I owe
> > you a beer at the next conference.
> 
> Wow, you really want me to drink, do you? :)

Taking a break really helps :)

> Actually, I did clean up. The other user you spotted that was previously
> introduced in the patch 4/10, and if you take a look at it, you'll see
> that it actually uses the rate variable like you suggested.

Ah, missed that :)
 
> Now, your mail made me realize that patch 10 introduced a direct
> clk_get_rate call, that I forgot to cleanup. After applying these
> patches, it's the only user left.

So no beer for you!
 
> I'll send a v5. Do you have any additionnal comments on those patches to
> avoid wasting more electrons?

No, I just wanted to make you aware that sending patches faster than I
can review them is not really helpful, unless the fast new version is
perfect. 

Thanks,

	tglx


From sebastian.hesselbarth at gmail.com  Sat Jul  6 17:22:22 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Sat, 06 Jul 2013 23:22:22 +0200
Subject: Second ethernet on kirkwood does not work when probed through DT
In-Reply-To: <20130706215426.6e666d6af0dc6c9ea5fe32cd@openwrt.org>
References: <20130706215426.6e666d6af0dc6c9ea5fe32cd@openwrt.org>
Message-ID: <51D88A8E.1060104@gmail.com>

On 07/06/2013 09:54 PM, Jonas Gorski wrote:
> Hello Sebastian,
>
> using your DT patches[1] (on top of 3.10) I can't get the second
> ethernet to work on my kirkwood board.

Hi Jonas,

next time please name your board, because there are plenty of it.
Kirkwood is just the SoC used on them.

> in my dts file I use:
>
> &mdio { status = "okay"; };
>
> &eth0 { status = "okay"; ethernet0-port at 0 { speed =<1000>; duplex
> =<1>; }; };
>

I guess you are using Iomega IX2 200?

> &eth1 { status = "okay"; ethernet1-port at 1 { speed =<1000>; duplex
> =<1>; }; };
>
> (Both macs are connected to a switch, so use a fixed link, and no
> phy).
>
> Eth1 gets probed fine, but never gets a link when brought up, and
> trying to bring it down again hangs the board hard.
>
> Using Florian's older patches, it is brought up fine and works (after
> adapting the node names of course).
>
> Also I noticed that you named eth1's ethernet1-port node wrongly in
> (at least) your kirkwood conversion patch[2]; you used
>
> &eth1 { status = "okay"; ethernet1-port at 0 { must be @1--^ phy-handle
> =<&ethphy1>; }; };

Can you please try to leave ethernet1-port at 0 and match
the one in kirkwood.dtsi?

Both "ports" need reg = <0> as there is two controllers
with one port at 0 on Kirkwood.

If that works, please address a mail to ARM mailing list
where you describe the issue and propose the patch.

Sebastian

> which results in a null pointer access on boot:
>
> ... [   12.627136] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0
> with MAC address ... [   12.635955] Unable to handle kernel NULL
> pointer dereference at virtual address 00000000 [   12.644100] pgd =
> c0004000 [   12.646821] [00000000] *pgd=00000000 [   12.650418]
> Internal error: Oops: 5 [#1] ARM [   12.654702] Modules linked in: [
> 12.657778] CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0 #10 [
> 12.663634] task: c7827d60 ti: c782e000 task.ti: c782e000 [
> 12.669073] PC is at mv643xx_eth_probe+0x98/0x708 ...
>
>
> Regards Jonas
>
> P.S: I'm not on any ML you posted these patches to, so I could not
> reply directly.
>
> [1] https://patchwork.kernel.org/patch/2632571/ etc [2]
> https://patchwork.kernel.org/patch/2811861/



From arnd at arndb.de  Sat Jul  6 17:36:48 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 6 Jul 2013 23:36:48 +0200
Subject: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c
In-Reply-To: <20130706131057.GU21614@n2100.arm.linux.org.uk>
References: <20130517191304.468.73487.stgit@localhost>
 <20130520095447.GR21614@n2100.arm.linux.org.uk>
 <20130706131057.GU21614@n2100.arm.linux.org.uk>
Message-ID: <201307062336.49066.arnd@arndb.de>

On Saturday 06 July 2013, Russell King - ARM Linux wrote:
> Oh wait, why don't I get to choose my "debug console UART" on an AT91?
> Maybe AT91 should move their debug uart selection into this menu as well,
> and maybe the Versatile Express options too, because they're all to do
> with selecting the UART to be used.  Please... some sane thought would
> be really good here.
> 
> Oh my god, you're not the only ones.  Arnd/Olof, who started this madness
> and why haven't you already stepped on it?  Right, I'm fixing this in
> this merge window.  Everything is moving under the original choice menu
> as it was intended to be.

Sorry, I missed that this was going on, and I absolutely agree with your
sentiment. From what I can tell from the git log, Tegra was the first
to have the separate choice statement, after it just move its
options from mach-tegra/Kconfig into the Kconfig.debug. OMAP followed
with the same method and I think from there people just copied it.

I can understand why one wants to have some more structure in the list,
given that i.MX alone has 37 options for UART addresses, but we first
need to have a consistent method of configuring the addresses.

	Arnd


From jogo at openwrt.org  Sat Jul  6 17:39:12 2013
From: jogo at openwrt.org (Jonas Gorski)
Date: Sat, 6 Jul 2013 23:39:12 +0200
Subject: Second ethernet on kirkwood does not work when probed through DT
In-Reply-To: <51D88A8E.1060104@gmail.com>
References: <20130706215426.6e666d6af0dc6c9ea5fe32cd@openwrt.org>
 <51D88A8E.1060104@gmail.com>
Message-ID: <20130706233912.00004044@unknown>

On Sat, 06 Jul 2013 23:22:22 +0200
Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> wrote:

> On 07/06/2013 09:54 PM, Jonas Gorski wrote:
> > Hello Sebastian,
> >
> > using your DT patches[1] (on top of 3.10) I can't get the second
> > ethernet to work on my kirkwood board.
> 
> Hi Jonas,
> 
> next time please name your board, because there are plenty of it.
> Kirkwood is just the SoC used on them.

Oops, sorry. It's D-Link DIR-665, with a 6281. Currently not upstream,
but mostly supported (the switch isn't supported by DSA but works fine
without it).

 
> > in my dts file I use:
> >
> > &mdio { status = "okay"; };
> >
> > &eth0 { status = "okay"; ethernet0-port at 0 { speed =<1000>; duplex
> > =<1>; }; };
> >
> 
> I guess you are using Iomega IX2 200?
> 
> > &eth1 { status = "okay"; ethernet1-port at 1 { speed =<1000>; duplex
> > =<1>; }; };
> >
> > (Both macs are connected to a switch, so use a fixed link, and no
> > phy).
> >
> > Eth1 gets probed fine, but never gets a link when brought up, and
> > trying to bring it down again hangs the board hard.
> >
> > Using Florian's older patches, it is brought up fine and works (after
> > adapting the node names of course).
> >
> > Also I noticed that you named eth1's ethernet1-port node wrongly in
> > (at least) your kirkwood conversion patch[2]; you used
> >
> > &eth1 { status = "okay"; ethernet1-port at 0 { must be @1--^ phy-handle
> > =<&ethphy1>; }; };
> 
> Can you please try to leave ethernet1-port at 0 and match
> the one in kirkwood.dtsi?
> 
> Both "ports" need reg = <0> as there is two controllers
> with one port at 0 on Kirkwood.

kirkwood.dtsi itself says ethernet1-port at 1 with reg = <1>.

Changing reg to 0 for eth1 brings:

[    9.586915] ------------[ cut here ]------------
[    9.591590] WARNING: at fs/sysfs/dir.c:530 sysfs_add_one+0x88/0xa8()
[    9.597973] sysfs: cannot create duplicate filename '/devices/platform/mv643xx_eth_port.0'
[    9.606286] Modules linked in:
[    9.609366] CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0 #12
[    9.615231] Backtrace:
[    9.617714] [<c001352c>] (dump_backtrace+0x0/0x114) from [<c00136d4>] (show_stack+0x18/0x1c)
[    9.626205]  r6:00000212 r5:c02cd6e0 r4:c782fbe0 r3:00000000
[    9.631972] [<c00136bc>] (show_stack+0x0/0x1c) from [<c010a080>] (dump_stack+0x20/0x28)
[    9.640024] [<c010a060>] (dump_stack+0x0/0x28) from [<c001bdf4>] (warn_slowpath_common+0x58/0x74)
[    9.648958] [<c001bd9c>] (warn_slowpath_common+0x0/0x74) from [<c001beb4>] (warn_slowpath_fmt+0x38/0x40)
[    9.658492]  r8:c780d288 r7:c7823000 r6:c782fc28 r5:c73c1c88 r4:c782fc04
r3:00000009
[    9.666436] [<c001be7c>] (warn_slowpath_fmt+0x0/0x40) from [<c00ccdf4>] (sysfs_add_one+0x88/0xa8)
[    9.675357]  r3:c7823000 r2:c02cd750
[    9.678964]  r4:ffffffef
[    9.681539] [<c00ccd6c>] (sysfs_add_one+0x0/0xa8) from [<c00ccfd4>] (create_dir+0x70/0xc0)
[    9.689836]  r7:c78c64d8 r6:00000000 r5:c73c1c88 r4:00002001
[    9.695577] [<c00ccf64>] (create_dir+0x0/0xc0) from [<c00cd358>] (sysfs_create_dir+0xbc/0xdc)
[    9.704165] [<c00cd29c>] (sysfs_create_dir+0x0/0xdc) from [<c010bde4>] (kobject_add_internal+0xb8/0x1e4)
[    9.713698]  r6:c07ae3b0 r5:c78c64d8 r4:c78c64d8
[    9.718375] [<c010bd2c>] (kobject_add_internal+0x0/0x1e4) from [<c010c1ec>] (kobject_add+0x80/0x98)
[    9.727487] [<c010c16c>] (kobject_add+0x0/0x98) from [<c015f6d0>] (device_add+0xd8/0x54c)
[    9.735708]  r3:00000000 r2:00000000
[    9.739315]  r6:00000000 r5:c78c64d0 r4:c78c64c0
[    9.744002] [<c015f5f8>] (device_add+0x0/0x54c) from [<c0163348>] (platform_device_add+0x14c/0x1e0)
[    9.753117] [<c01631fc>] (platform_device_add+0x0/0x1e0) from [<c0193014>] (mv643xx_eth_shared_of_add_port+0x240/0x2a8)
[    9.763962]  r8:00000e00 r7:c73b1b70 r6:0000003e r5:00000000 r4:c78c64c0
r3:00000000
[    9.771899] [<c0192dd4>] (mv643xx_eth_shared_of_add_port+0x0/0x2a8) from [<c01932a8>] (mv643xx_eth_shared_probe+0x22c/0x318)
[    9.783172]  r5:c08ea74c r4:c08ea89c
[    9.786790] [<c019307c>] (mv643xx_eth_shared_probe+0x0/0x318) from [<c0162ef0>] (platform_drv_probe+0x1c/0x20)
[    9.796860] [<c0162ed4>] (platform_drv_probe+0x0/0x20) from [<c0161df8>] (driver_probe_device+0xe4/0x210)
[    9.806493] [<c0161d14>] (driver_probe_device+0x0/0x210) from [<c0161f8c>] (__driver_attach+0x68/0x8c)
[    9.815853]  r7:00000000 r6:c07b3f64 r5:c785bdb0 r4:c785bde4
[    9.821594] [<c0161f24>] (__driver_attach+0x0/0x8c) from [<c0160714>] (bus_for_each_dev+0x58/0x90)
[    9.830600]  r6:c07b3f64 r5:c0161f24 r4:00000000 r3:00000002
[    9.836329] [<c01606bc>] (bus_for_each_dev+0x0/0x90) from [<c016192c>] (driver_attach+0x20/0x28)
[    9.845162]  r6:c07ae368 r5:c07b3f64 r4:c73ad4a0
[    9.849836] [<c016190c>] (driver_attach+0x0/0x28) from [<c01614ec>] (bus_add_driver+0xb8/0x21c)
[    9.858596] [<c0161434>] (bus_add_driver+0x0/0x21c) from [<c016227c>] (driver_register+0xa8/0x138)
[    9.867606]  r8:0000003e r7:00000000 r6:c07b3f64 r5:c033dd5c r4:c034200c
[    9.874409] [<c01621d4>] (driver_register+0x0/0x138) from [<c016301c>] (platform_driver_register+0x4c/0x60)
[    9.884216] [<c0162fd0>] (platform_driver_register+0x0/0x60) from [<c0335f48>] (mv643xx_eth_init_module+0x14/0x44)
[    9.894633] [<c0335f34>] (mv643xx_eth_init_module+0x0/0x44) from [<c0010b50>] (do_one_initcall+0x9c/0x15c)
[    9.904335]  r4:c034200c r3:00000000
[    9.907956] [<c0010ab4>] (do_one_initcall+0x0/0x15c) from [<c0322938>] (kernel_init_freeable+0xf8/0x1c4)
[    9.917512] [<c0322840>] (kernel_init_freeable+0x0/0x1c4) from [<c000c338>] (kernel_init+0x10/0x104)
[    9.926709] [<c000c328>] (kernel_init+0x0/0x104) from [<c0008a30>] (ret_from_fork+0x14/0x24)
[    9.935196]  r4:00000000 r3:00000000
[    9.938838] ---[ end trace 026e20e7bf6738e2 ]---
[    9.943497] ------------[ cut here ]------------
[    9.948142] WARNING: at lib/kobject.c:196 kobject_add_internal+0x17c/0x1e4()
[    9.955238] kobject_add_internal failed for mv643xx_eth_port.0 with -EEXIST, don't try to register things with the same name in the same directory.
[    9.968521] Modules linked in:
[    9.971611] CPU: 0 PID: 1 Comm: swapper Tainted: G        W    3.10.0 #12
[    9.978423] Backtrace:
[    9.980907] [<c001352c>] (dump_backtrace+0x0/0x114) from [<c00136d4>] (show_stack+0x18/0x1c)
[    9.989377]  r6:000000c4 r5:c02dd9d8 r4:c782fc60 r3:00000000
[    9.995120] [<c00136bc>] (show_stack+0x0/0x1c) from [<c010a080>] (dump_stack+0x20/0x28)
[   10.003181] [<c010a060>] (dump_stack+0x0/0x28) from [<c001bdf4>] (warn_slowpath_common+0x58/0x74)
[   10.012118] [<c001bd9c>] (warn_slowpath_common+0x0/0x74) from [<c001beb4>] (warn_slowpath_fmt+0x38/0x40)
[   10.021654]  r8:c07ae3a8 r7:c07ae3b0 r6:c07ae3b0 r5:c78c64d8 r4:c782fc84
r3:00000009
[   10.029582] [<c001be7c>] (warn_slowpath_fmt+0x0/0x40) from [<c010bea8>] (kobject_add_internal+0x17c/0x1e4)
[   10.039287]  r3:c02dd9c0 r2:c02ddb40
[   10.042911]  r4:c78c64d8
[   10.045470] [<c010bd2c>] (kobject_add_internal+0x0/0x1e4) from [<c010c1ec>] (kobject_add+0x80/0x98)
[   10.054578] [<c010c16c>] (kobject_add+0x0/0x98) from [<c015f6d0>] (device_add+0xd8/0x54c)
[   10.062804]  r3:00000000 r2:00000000
[   10.066411]  r6:00000000 r5:c78c64d0 r4:c78c64c0
[   10.071098] [<c015f5f8>] (device_add+0x0/0x54c) from [<c0163348>] (platform_device_add+0x14c/0x1e0)
[   10.080207] [<c01631fc>] (platform_device_add+0x0/0x1e0) from [<c0193014>] (mv643xx_eth_shared_of_add_port+0x240/0x2a8)
[   10.091049]  r8:00000e00 r7:c73b1b70 r6:0000003e r5:00000000 r4:c78c64c0
r3:00000000
[   10.098977] [<c0192dd4>] (mv643xx_eth_shared_of_add_port+0x0/0x2a8) from [<c01932a8>] (mv643xx_eth_shared_probe+0x22c/0x318)
[   10.110252]  r5:c08ea74c r4:c08ea89c
[   10.113870] [<c019307c>] (mv643xx_eth_shared_probe+0x0/0x318) from [<c0162ef0>] (platform_drv_probe+0x1c/0x20)
[   10.123938] [<c0162ed4>] (platform_drv_probe+0x0/0x20) from [<c0161df8>] (driver_probe_device+0xe4/0x210)
[   10.133571] [<c0161d14>] (driver_probe_device+0x0/0x210) from [<c0161f8c>] (__driver_attach+0x68/0x8c)
[   10.142932]  r7:00000000 r6:c07b3f64 r5:c785bdb0 r4:c785bde4
[   10.148662] [<c0161f24>] (__driver_attach+0x0/0x8c) from [<c0160714>] (bus_for_each_dev+0x58/0x90)
[   10.157670]  r6:c07b3f64 r5:c0161f24 r4:00000000 r3:00000002
[   10.163409] [<c01606bc>] (bus_for_each_dev+0x0/0x90) from [<c016192c>] (driver_attach+0x20/0x28)
[   10.172241]  r6:c07ae368 r5:c07b3f64 r4:c73ad4a0
[   10.176914] [<c016190c>] (driver_attach+0x0/0x28) from [<c01614ec>] (bus_add_driver+0xb8/0x21c)
[   10.185674] [<c0161434>] (bus_add_driver+0x0/0x21c) from [<c016227c>] (driver_register+0xa8/0x138)
[   10.194686]  r8:0000003e r7:00000000 r6:c07b3f64 r5:c033dd5c r4:c034200c
[   10.201497] [<c01621d4>] (driver_register+0x0/0x138) from [<c016301c>] (platform_driver_register+0x4c/0x60)
[   10.211301] [<c0162fd0>] (platform_driver_register+0x0/0x60) from [<c0335f48>] (mv643xx_eth_init_module+0x14/0x44)
[   10.221720] [<c0335f34>] (mv643xx_eth_init_module+0x0/0x44) from [<c0010b50>] (do_one_initcall+0x9c/0x15c)
[   10.231422]  r4:c034200c r3:00000000
[   10.235042] [<c0010ab4>] (do_one_initcall+0x0/0x15c) from [<c0322938>] (kernel_init_freeable+0xf8/0x1c4)
[   10.244588] [<c0322840>] (kernel_init_freeable+0x0/0x1c4) from [<c000c338>] (kernel_init+0x10/0x104)
[   10.253784] [<c000c328>] (kernel_init+0x0/0x104) from [<c0008a30>] (ret_from_fork+0x14/0x24)
[   10.262274]  r4:00000000 r3:00000000
[   10.265882] ---[ end trace 026e20e7bf6738e3 ]---
[   10.270553] mv643xx_eth: probe of f1076000.ethernet-controller failed with error -17



Regards
Jonas


From linux at arm.linux.org.uk  Sat Jul  6 19:37:08 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sun, 7 Jul 2013 00:37:08 +0100
Subject: debugging options (was: Re: [PATCH 1/6] ARM: OMAP2+: Remove
 board-4430sdp.c)
In-Reply-To: <201307062336.49066.arnd@arndb.de>
References: <20130517191304.468.73487.stgit@localhost>
 <20130520095447.GR21614@n2100.arm.linux.org.uk>
 <20130706131057.GU21614@n2100.arm.linux.org.uk>
 <201307062336.49066.arnd@arndb.de>
Message-ID: <20130706233708.GW21614@n2100.arm.linux.org.uk>

Apologies for the topic hijack.

On Sat, Jul 06, 2013 at 11:36:48PM +0200, Arnd Bergmann wrote:
> Sorry, I missed that this was going on, and I absolutely agree with your
> sentiment. From what I can tell from the git log, Tegra was the first
> to have the separate choice statement, after it just move its
> options from mach-tegra/Kconfig into the Kconfig.debug. OMAP followed
> with the same method and I think from there people just copied it.
> 
> I can understand why one wants to have some more structure in the list,
> given that i.MX alone has 37 options for UART addresses, but we first
> need to have a consistent method of configuring the addresses.

I don't have an option with an option after the choice or a set of
options afterwards asking for details about the selected option -
that is logical.

For example, if we were to reduce the 8250-uart based stuff down to
a single "8250-compatible uart" option, and then ask for the address,
register shift and register access size.

... and of course by this time I now have a patch set which does
exactly that... and it can do more by getting rid of that 8250_32.S
file as well with another config option.  The patch below tries
hard not to break anything or lose information as to the details of
the 8250 UART in any platform which they're already known to the
kernel, but they can be trivially overridden.  Eventually (maybe
tomorrow), I expect a load of the choice config statements in
arch/arm/Kconfig.debug to go away, replaced just with a generic
"Kernel low-level debugging messages via 8250 UART" option.

 arch/arm/Kconfig.debug                             |   92 ++++++++++++++++++--
 arch/arm/include/asm/hardware/debug-8250.S         |   29 ------
 arch/arm/include/debug/8250.S                      |   36 ++++++++
 arch/arm/include/debug/mvebu.S                     |   30 -------
 arch/arm/include/debug/nspire.S                    |    9 +--
 arch/arm/include/debug/pxa.S                       |   33 -------
 arch/arm/include/debug/rockchip.S                  |   42 ---------
 arch/arm/include/debug/sunxi.S                     |   27 ------
 arch/arm/mach-dove/include/mach/debug-macro.S      |   19 ----
 arch/arm/mach-ebsa110/include/mach/debug-macro.S   |   22 -----
 .../arm/mach-footbridge/include/mach/debug-macro.S |   15 ---
 arch/arm/mach-gemini/include/mach/debug-macro.S    |   21 -----
 arch/arm/mach-iop13xx/include/mach/debug-macro.S   |   24 -----
 arch/arm/mach-iop32x/include/mach/debug-macro.S    |   21 -----
 arch/arm/mach-iop33x/include/mach/debug-macro.S    |   22 -----
 arch/arm/mach-ixp4xx/include/mach/debug-macro.S    |   26 ------
 arch/arm/mach-kirkwood/include/mach/debug-macro.S  |   19 ----
 arch/arm/mach-lpc32xx/include/mach/debug-macro.S   |   29 ------
 arch/arm/mach-mv78xx0/include/mach/debug-macro.S   |   19 ----
 arch/arm/mach-orion5x/include/mach/debug-macro.S   |   21 -----
 arch/arm/mach-rpc/include/mach/debug-macro.S       |   23 -----
 21 files changed, 121 insertions(+), 458 deletions(-)
 delete mode 100644 arch/arm/include/asm/hardware/debug-8250.S
 create mode 100644 arch/arm/include/debug/8250.S
 delete mode 100644 arch/arm/include/debug/mvebu.S
 delete mode 100644 arch/arm/include/debug/pxa.S
 delete mode 100644 arch/arm/include/debug/rockchip.S
 delete mode 100644 arch/arm/include/debug/sunxi.S
 delete mode 100644 arch/arm/mach-dove/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ebsa110/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-gemini/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop13xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop32x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop33x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ixp4xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-lpc32xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-mv78xx0/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-orion5x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-rpc/include/mach/debug-macro.S



From gregkh at linuxfoundation.org  Sat Jul  6 20:17:58 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Sat, 6 Jul 2013 17:17:58 -0700
Subject: [PATCH 1/2] Initial support for Allwinner's Security ID fuses
In-Reply-To: <20130706193646.GB9778@kroah.com>
References: <20130624092942.GG26008@lukather>
 <20130624160440.GA15201@kroah.com> <51C87DC7.50005@schinagl.nl>
 <20130624181509.GA8847@kroah.com> <51C8B84C.3020200@schinagl.nl>
 <20130624214615.GA17604@kroah.com> <51CAA709.4060801@schinagl.nl>
 <20130626175144.GC2222@kroah.com> <51D674BF.9030207@schinagl.nl>
 <20130706193646.GB9778@kroah.com>
Message-ID: <20130707001758.GA15335@kroah.com>

On Sat, Jul 06, 2013 at 12:36:46PM -0700, Greg KH wrote:
> On Fri, Jul 05, 2013 at 09:24:47AM +0200, Oliver Schinagl wrote:
> > The other 'broken' drivers that where linked earlier, also use the
> > BINARY attributes.
> > 
> > So Greg, if you could be so kind and give me an example how to
> > implement this properly, I am at loss and don't know :(
> 
> Ah crap, devices don't have a binary attribute group, like struct class
> does.  I'll go add that on Monday and send you the patch to see if that
> helps you out.  I'll also go through and fix up all of the binary
> attribute drivers to keep them from doing that...
> 
> Sorry, I missed that earlier, but thanks for trying and pointing out my
> mistake.

Can you try this patch out, with your driver, and see if it works for
you?

thanks,

greg k-h

------------------

Subject: driver core: add binary attributes to struct device

From: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

This lets a device provide a set of default binary attributes, like
normal attributes, that are initialized and torn down by the driver core
at the proper times, so that there are no races with userspace.

Reported-by: : Oliver Schinagl <oliver+list at schinagl.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>


diff --git a/drivers/base/core.c b/drivers/base/core.c
index 2499cef..4040191 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -433,7 +433,7 @@ static void device_remove_attributes(struct device *dev,
 }
 
 static int device_add_bin_attributes(struct device *dev,
-				     struct bin_attribute *attrs)
+				     const struct bin_attribute *attrs)
 {
 	int error = 0;
 	int i;
@@ -452,7 +452,7 @@ static int device_add_bin_attributes(struct device *dev,
 }
 
 static void device_remove_bin_attributes(struct device *dev,
-					 struct bin_attribute *attrs)
+					 const struct bin_attribute *attrs)
 {
 	int i;
 
@@ -516,8 +516,14 @@ static int device_add_attrs(struct device *dev)
 	if (error)
 		goto err_remove_type_groups;
 
+	error = device_add_bin_attributes(dev, dev->bin_attrs);
+	if (error)
+		goto err_remove_groups;
 	return 0;
 
+ err_remove_groups:
+	device_remove_groups(dev, dev->groups);
+
  err_remove_type_groups:
 	if (type)
 		device_remove_groups(dev, type->groups);
@@ -537,6 +543,7 @@ static void device_remove_attrs(struct device *dev)
 	const struct device_type *type = dev->type;
 
 	device_remove_groups(dev, dev->groups);
+	device_remove_bin_attributes(dev, dev->bin_attrs);
 
 	if (type)
 		device_remove_groups(dev, type->groups);
diff --git a/include/linux/device.h b/include/linux/device.h
index c0a1261..6620ad8 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -645,6 +645,7 @@ struct acpi_dev_node {
  * @knode_class: The node used to add the device to the class list.
  * @class:	The class of the device.
  * @groups:	Optional attribute groups.
+ * @bin_attrs:	Optional binary attributes for this device.
  * @release:	Callback to free the device after all references have
  * 		gone away. This should be set by the allocator of the
  * 		device (i.e. the bus driver that discovered the device).
@@ -717,6 +718,7 @@ struct device {
 	struct klist_node	knode_class;
 	struct class		*class;
 	const struct attribute_group **groups;	/* optional groups */
+	const struct bin_attribute *bin_attrs;
 
 	void	(*release)(struct device *dev);
 	struct iommu_group	*iommu_group;


From marex at denx.de  Sat Jul  6 21:10:00 2013
From: marex at denx.de (Marek Vasut)
Date: Sun, 7 Jul 2013 03:10:00 +0200
Subject: Chipidea usb otg support for IMX/MXS (device functionality)
In-Reply-To: <F281D0F91ED19E4D8E63A7504E8A649803EFF551@039-SN2MPN1-023.039d.mgd.msft.net>
References: <51A5A808.2070803@digi.com> <201306281142.51676.marex@denx.de>
 <F281D0F91ED19E4D8E63A7504E8A649803EFF551@039-SN2MPN1-023.039d.mgd.msft.net>
Message-ID: <201307070310.00973.marex@denx.de>

Hi Peter,

> > Where can I measure this?
> > 
> > > Two possible reasons:
> > > 
> > > 1. You have not gpio control for vbus toggle when role switches.
> > 
> > This works well.
> > 
> > > 2. Your hardware has some problems that the vbus can't lower than 0.8v.
> > 
> > How can I check that?
> 
> Just measure the voltage of your otg vbus pin.

It's 2.5 volt for me. What am I supposed to observe happening there?

Best regards,
Marek Vasut


From maxime.ripard at free-electrons.com  Sun Jul  7 03:15:01 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sun, 7 Jul 2013 09:15:01 +0200
Subject: MTD EEPROM support and driver integration
In-Reply-To: <8997501.Dchyii8uWX@wuerfel>
References: <20130705201118.GM2959@lukather> <5811519.oHVuMujf0I@wuerfel>
 <20130706120112.GA11069@lukather> <8997501.Dchyii8uWX@wuerfel>
Message-ID: <20130707071501.GD11243@lukather>

On Sat, Jul 06, 2013 at 09:06:49PM +0200, Arnd Bergmann wrote:
> On Saturday 06 July 2013 14:01:12 Maxime Ripard wrote:
> > What other option would we have?
> > 
> > I also thought about writing an EEPROM framework of its own, but the
> > line is really thin between a large EEPROM and say a small SPI
> > dataflash, which would make it pretty hard to choose between such a
> > framework and MTD.
> 
> Isn't flash by definition block based, while EEPROM can be written
> in byte or word units? I think that is a significant difference, although
> it doesn't necessarily mean that we can't use MTD for both.

Ah, right.

> We also have a bunch of OTP drivers spread around the kernel, it probably
> makes sense to consolidate them at the same time, at least on the DT binding
> side if not the device drivers.

From a quick grep, the only one I've seen so far are:
  - imx6q, that has a hook at machine start to poke into its OCOTP to
    retrieve some frequency scaling parameters it seems. I'm not sure
    how the current solution could improve the situation for this
    use-case, but the DT bindings of the OCOTP is just a DT node, with
    no clients, so we have nothing to worry about here.
  - imx28, that has a hook at machine start to look up the MAC address
    values and patch the ethernet controller nodes to add the right
    local-mac-address property. This one could benefit from the new
    bindings, but we already mentionned it, and I intended to develop
    with an imx28 board anyway.
  - picoxcell-pc3x3 DTSI has a node for a OTP device, but they don't
    seem to be doing anything with it, nor do they seem to have a driver
    for it. So I guess we don't care about migrating for this one
    either.

Did you have other cases in mind?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130707/43d6a3f5/attachment.sig>

From mpa at pengutronix.de  Sun Jul  7 03:19:49 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 7 Jul 2013 09:19:49 +0200
Subject: [PATCH v9 08/10] ASoC: Add phycore-ac97-dt driver
In-Reply-To: <20130703161727.GS27646@sirena.org.uk>
References: <1371734429-6081-1-git-send-email-mpa@pengutronix.de>
 <1371734429-6081-9-git-send-email-mpa@pengutronix.de>
 <20130703161727.GS27646@sirena.org.uk>
Message-ID: <20130707071949.GH16871@s25.your-server.de>

On Wed, Jul 03, 2013 at 05:17:27PM +0100, Mark Brown wrote:
> On Thu, Jun 20, 2013 at 03:20:27PM +0200, Markus Pargmann wrote:
> 
> > Notes:
> >     Changes in v9:
> >      - Fix blank line at end of file.
> >     
> 
> Please don't include enormous changelogs like this, they're just noise.
> 
> > +config SND_SOC_PHYCORE_AC97_DT
> > +	bool "SoC Audio support for Phytec phyCORE (and phyCARD) boards (devicetree only)"
> > +	depends on MACH_PCA100 || MACH_PCM043
> 
> Is there an actual dependency on the machine type?  This seems wrong for
> a DT driver.

No, there is no dependency. Fixed.

> 
> > +static struct snd_soc_ops imx_phycore_hifi_ops = {
> > +};
> > +
> 
> You shouldn't have this if there's nothing in it.

Removed.

> 
> > +static struct platform_device *imx_phycore_snd_device;
> 
> This shouldn't be a global, it should be in driver data.

Moved to driver data.

> 
> > +/*
> > + * Pointer to AC97 reset functions for specific boards
> > + */
> > +#if IS_ENABLED(CONFIG_MACH_PCA100)
> > +extern void pca100_ac97_cold_reset(struct snd_ac97 *ac97);
> > +extern void pca100_ac97_warm_reset(struct snd_ac97 *ac97);
> > +#else
> > +static void pca100_ac97_cold_reset(struct snd_ac97 *ac97) { }
> > +static void pca100_ac97_warm_reset(struct snd_ac97 *ac97) { }
> > +#endif
> 
> > +	if (of_machine_is_compatible("phytec,imx27-pca100")) {
> > +		phycore_ac97_reset = pca100_ac97_cold_reset;
> > +		phycore_ac97_warm_reset = pca100_ac97_warm_reset;
> > +	} else if (of_machine_is_compatible("phytec,imx35-pcm043")) {
> > +		phycore_ac97_reset = pcm043_ac97_cold_reset;
> > +		phycore_ac97_warm_reset = pcm043_ac97_warm_reset;
> > +	} else {
> > +		dev_err(&pdev->dev, "Failed to set AC97 reset functions, unknown board.\n");
> > +		return -EINVAL;
> > +	}
> 
> These functions have no reason to be anywhere except in the driver and
> really you should just be specifying which pins to use there - ideally
> via pinctrl but I don't think i.MX has adopted that yet.

There are no pinctrl driver for imx27(pca100) or imx35(pcm043). The
iomux/pad configure functions are defined inside mach-imx/ including
their headers. Both reset functions have to configure iomux/pad before
and after using gpio. So I think it's not possible to make the reset
based on the gpio pins without the necessary iomux/pad configuration.

Thanks,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From balbi at ti.com  Sun Jul  7 04:35:58 2013
From: balbi at ti.com (Felipe Balbi)
Date: Sun, 7 Jul 2013 11:35:58 +0300
Subject: [PATCH] arm: dts: AM43x: Add usb_otg_hs node
In-Reply-To: <1372401887-19422-1-git-send-email-george.cherian@ti.com>
References: <1372401887-19422-1-git-send-email-george.cherian@ti.com>
Message-ID: <20130707083558.GA12992@arwen.pp.htv.fi>

Hi,

On Fri, Jun 28, 2013 at 12:14:47PM +0530, George Cherian wrote:
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index ddc1df7..e4f5eb8 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -64,5 +64,24 @@
>  			compatible = "ti,am4372-counter32k","ti,omap-counter32k";
>  			reg = <0x44e86000 0x40>;
>  		};
> +
> +		usb_otg_hs1: am4372_dwc3 at 48380000 {
> +			compatible = "ti,am437x-dwc3";
> +			reg = <0x48380000 0x1ff>;
> +			interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			utmi-mode = <1>;
> +			ranges;
> +
> +			dwc3 at 48390000 {
> +				compatible = "synopsys,dwc3";

let's us snps,dwc3. I recently posted a patch converting synopsys to
snps like all other DesignWare drivers. Support for synopsys,dwc3 is
still there, but shouldn't be used.

> +				reg = <0x48390000 0xcfff>;
> +				interrupts = <GIC_SPI  168 IRQ_TYPE_LEVEL_HIGH>;
> +				tx-fifo-resize;

is this flag *really* necessary, I asked you and didn't get an answer.

-- 
balbi
-------------- 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/20130707/cc0b9525/attachment-0001.sig>

From alexandre.belloni at free-electrons.com  Sun Jul  7 04:47:21 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Sun, 07 Jul 2013 10:47:21 +0200
Subject: [PATCHv3 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
In-Reply-To: <51D7F0E6.2000008@kernel.org>
References: <1372094699-3832-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1372094699-3832-3-git-send-email-alexandre.belloni@free-electrons.com>
 <51D7F0E6.2000008@kernel.org>
Message-ID: <51D92B19.8000706@free-electrons.com>

On 06/07/2013 12:26, Jonathan Cameron wrote:
> On 06/24/2013 06:24 PM, Alexandre Belloni wrote:
>> From: Maxime Ripard <maxime.ripard at free-electrons.com>
>>
>> The ADCs connected to this bus have been experiencing some timeout
>> issues when using the iMX28 i2c controller. Switching back to bitbanging
>> solves this.
>>
>> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
>> Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
> 
> As there are no disadvantages in taking the driver through IIO and these changes
> through the appropriate arch trees, I'd not propose to take these through IIO
> (even when the discussion is done) unless specifically asked to.
> 

Sure, especially since, we may finally not move to i2c bitbanging. I'll
probably resend a new version of those patches separately.

Shawn, please wait for the i2c-mxs PIO/DMA mode discussion to end before
applying. If possible, I would prefer not using bitbanging.

Regards,


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From samuel.thibault at ens-lyon.org  Sun Jul  7 06:10:28 2013
From: samuel.thibault at ens-lyon.org (Samuel Thibault)
Date: Sun, 7 Jul 2013 12:10:28 +0200
Subject: [PATCH] Route kbd LEDs through the generic LEDs layer
In-Reply-To: <20121221003449.GA6999@type.youpi.perso.aquilenet.fr>
References: <201011112205.oABM5KVJ005298@imap1.linux-foundation.org>
 <201011111440.07882.dmitry.torokhov@gmail.com>
 <20110102090935.GV32469@atrey.karlin.mff.cuni.cz>
 <20110102103210.GA25662@core.coreip.homeip.net>
 <20110102225741.GX5480@const.famille.thibault.fr>
 <20110112182702.GA9168@core.coreip.homeip.net>
 <20111114040613.GA4992@type.famille.thibault.fr>
 <20121221003449.GA6999@type.youpi.perso.aquilenet.fr>
Message-ID: <20130707101028.GD5651@type.youpi.perso.aquilenet.fr>

This permits to reassign keyboard LEDs to something else than keyboard "leds"
state, by adding keyboard led and modifier triggers connected to a series
of VT input LEDs, themselves connected to VT input triggers, which
per-input device LEDs use by default.  Userland can thus easily change the LED
behavior of (a priori) all input devices, or of particular input devices.

This also permits to fix #7063 from userland by using a modifier to implement
proper CapsLock behavior and have the keyboard caps lock led show that modifier
state.

Signed-off-by: Samuel Thibault <samuel.thibault at ens-lyon.org>
[ebroder at mokafive.com: Rebased to 3.2-rc1 or so, cleaned up some includes, and fixed some constants]
Signed-off-by: Evan Broder <evan at ebroder.net>

diff --exclude .svn -ur linux-3.10-orig/Documentation/leds/leds-class.txt linux-3.10-perso/Documentation/leds/leds-class.txt
--- linux-3.10-orig/Documentation/leds/leds-class.txt	2013-04-29 13:27:16.959258613 +0200
+++ linux-3.10-perso/Documentation/leds/leds-class.txt	2013-07-01 23:51:39.229318781 +0200
@@ -2,9 +2,6 @@
 LED handling under Linux
 ========================
 
-If you're reading this and thinking about keyboard leds, these are
-handled by the input subsystem and the led class is *not* needed.
-
 In its simplest form, the LED class just allows control of LEDs from
 userspace. LEDs appear in /sys/class/leds/. The maximum brightness of the
 LED is defined in max_brightness file. The brightness file will set the brightness
diff --exclude .svn -ur linux-3.10-orig/drivers/input/input.c linux-3.10-perso/drivers/input/input.c
--- linux-3.10-orig/drivers/input/input.c	2013-04-29 13:27:16.959258613 +0200
+++ linux-3.10-perso/drivers/input/input.c	2013-07-01 23:51:39.233318421 +0200
@@ -28,6 +28,7 @@
 #include <linux/mutex.h>
 #include <linux/rcupdate.h>
 #include "input-compat.h"
+#include "leds.h"
 
 MODULE_AUTHOR("Vojtech Pavlik <vojtech at suse.cz>");
 MODULE_DESCRIPTION("Input core");
@@ -708,6 +709,11 @@
 		handle->open = 0;
 
 	spin_unlock_irq(&dev->event_lock);
+
+#ifdef CONFIG_INPUT_LEDS
+	if (is_event_supported(EV_LED, dev->evbit, EV_MAX))
+		input_led_disconnect(dev);
+#endif
 }
 
 /**
@@ -2092,6 +2098,11 @@
 
 	list_add_tail(&dev->node, &input_dev_list);
 
+#ifdef CONFIG_INPUT_LEDS
+	if (is_event_supported(EV_LED, dev->evbit, EV_MAX))
+		input_led_connect(dev);
+#endif
+
 	list_for_each_entry(handler, &input_handler_list, node)
 		input_attach_handler(dev, handler);
 
diff --exclude .svn -ur linux-3.10-orig/drivers/input/Kconfig linux-3.10-perso/drivers/input/Kconfig
--- linux-3.10-orig/drivers/input/Kconfig	2013-04-29 13:32:29.997497163 +0200
+++ linux-3.10-perso/drivers/input/Kconfig	2013-07-01 23:51:39.233318421 +0200
@@ -178,6 +178,15 @@
 
 source "drivers/input/keyboard/Kconfig"
 
+config INPUT_LEDS
+	tristate "LED Support"
+	depends on LEDS_CLASS
+	select LEDS_TRIGGERS
+	default y
+	help
+	  This option enables support for the LEDs on keyboard managed
+	  by the input layer.
+
 source "drivers/input/mouse/Kconfig"
 
 source "drivers/input/joystick/Kconfig"
diff --exclude .svn -ur linux-3.10-orig/drivers/input/Makefile linux-3.10-perso/drivers/input/Makefile
--- linux-3.10-orig/drivers/input/Makefile	2013-04-29 13:27:16.959258613 +0200
+++ linux-3.10-perso/drivers/input/Makefile	2013-07-01 23:51:39.233318421 +0200
@@ -18,6 +18,7 @@
 obj-$(CONFIG_INPUT_EVBUG)	+= evbug.o
 
 obj-$(CONFIG_INPUT_KEYBOARD)	+= keyboard/
+obj-$(CONFIG_INPUT_LEDS)	+= leds.o
 obj-$(CONFIG_INPUT_MOUSE)	+= mouse/
 obj-$(CONFIG_INPUT_JOYSTICK)	+= joystick/
 obj-$(CONFIG_INPUT_TABLET)	+= tablet/
diff --exclude .svn -ur linux-3.10-orig/drivers/leds/Kconfig linux-3.10-perso/drivers/leds/Kconfig
--- linux-3.10-orig/drivers/leds/Kconfig	2013-07-01 01:56:00.335874214 +0200
+++ linux-3.10-perso/drivers/leds/Kconfig	2013-07-01 23:51:39.233318421 +0200
@@ -11,9 +11,6 @@
 	  Say Y to enable Linux LED support.  This allows control of supported
 	  LEDs from both userspace and optionally, by kernel events (triggers).
 
-	  This is not related to standard keyboard LEDs which are controlled
-	  via the input system.
-
 if NEW_LEDS
 
 config LEDS_CLASS
diff --exclude .svn -ur linux-3.10-orig/drivers/tty/Kconfig linux-3.10-perso/drivers/tty/Kconfig
--- linux-3.10-orig/drivers/tty/Kconfig	2013-04-29 13:32:36.353298705 +0200
+++ linux-3.10-perso/drivers/tty/Kconfig	2013-07-01 23:51:39.237318056 +0200
@@ -13,6 +13,10 @@
 	bool "Virtual terminal" if EXPERT
 	depends on !S390 && !UML
 	select INPUT
+	select NEW_LEDS
+	select LEDS_CLASS
+	select LEDS_TRIGGERS
+	select INPUT_LEDS
 	default y
 	---help---
 	  If you say Y here, you will get support for terminal devices with
diff --exclude .svn -ur linux-3.10-orig/drivers/tty/vt/keyboard.c linux-3.10-perso/drivers/tty/vt/keyboard.c
--- linux-3.10-orig/drivers/tty/vt/keyboard.c	2013-04-29 13:32:36.681288463 +0200
+++ linux-3.10-perso/drivers/tty/vt/keyboard.c	2013-07-01 23:51:39.237318056 +0200
@@ -33,6 +33,7 @@
 #include <linux/string.h>
 #include <linux/init.h>
 #include <linux/slab.h>
+#include <linux/leds.h>
 
 #include <linux/kbd_kern.h>
 #include <linux/kbd_diacr.h>
@@ -130,6 +131,7 @@
 static int shift_state = 0;
 
 static unsigned char ledstate = 0xff;			/* undefined */
+static unsigned char lockstate = 0xff;			/* undefined */
 static unsigned char ledioctl;
 
 static struct ledptr {
@@ -967,6 +969,32 @@
 	}
 }
 
+/* We route VT keyboard "leds" through triggers */
+static void kbd_ledstate_trigger_activate(struct led_classdev *cdev);
+static struct led_trigger ledtrig_ledstate[] = {
+#define DEFINE_LEDSTATE_TRIGGER(kbd_led, nam) \
+	[kbd_led] = { .name = nam, .activate = kbd_ledstate_trigger_activate, }
+	DEFINE_LEDSTATE_TRIGGER(VC_SCROLLOCK, "scrollock"),
+	DEFINE_LEDSTATE_TRIGGER(VC_NUMLOCK,   "numlock"),
+	DEFINE_LEDSTATE_TRIGGER(VC_CAPSLOCK,  "capslock"),
+	DEFINE_LEDSTATE_TRIGGER(VC_KANALOCK,  "kanalock"),
+#undef DEFINE_LEDSTATE_TRIGGER
+};
+static void kbd_lockstate_trigger_activate(struct led_classdev *cdev);
+static struct led_trigger ledtrig_lockstate[] = {
+#define DEFINE_LOCKSTATE_TRIGGER(kbd_led, nam) \
+	[kbd_led] = { .name = nam, .activate = kbd_lockstate_trigger_activate, }
+	DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTLOCK,  "shiftlock"),
+	DEFINE_LOCKSTATE_TRIGGER(VC_ALTGRLOCK,  "altgrlock"),
+	DEFINE_LOCKSTATE_TRIGGER(VC_CTRLLOCK,   "ctrllock"),
+	DEFINE_LOCKSTATE_TRIGGER(VC_ALTLOCK,    "altlock"),
+	DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTLLOCK, "shiftllock"),
+	DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTRLOCK, "shiftrlock"),
+	DEFINE_LOCKSTATE_TRIGGER(VC_CTRLLLOCK,  "ctrlllock"),
+	DEFINE_LOCKSTATE_TRIGGER(VC_CTRLRLOCK,  "ctrlrlock"),
+#undef DEFINE_LOCKSTATE_TRIGGER
+};
+
 /*
  * The leds display either (i) the status of NumLock, CapsLock, ScrollLock,
  * or (ii) whatever pattern of lights people want to show using KDSETLED,
@@ -1002,6 +1030,7 @@
 
 	leds = kbd->ledflagstate;
 
+	/* TODO: should be replaced by a LED trigger */
 	if (kbd->ledmode == LED_SHOW_MEM) {
 		for (i = 0; i < 3; i++)
 			if (ledptrs[i].valid) {
@@ -1014,18 +1043,24 @@
 	return leds;
 }
 
-static int kbd_update_leds_helper(struct input_handle *handle, void *data)
+/* Called on trigger connection, to set initial state */
+static void kbd_ledstate_trigger_activate(struct led_classdev *cdev)
 {
-	unsigned char leds = *(unsigned char *)data;
+	struct led_trigger *trigger = cdev->trigger;
+	int led = trigger - ledtrig_ledstate;
 
-	if (test_bit(EV_LED, handle->dev->evbit)) {
-		input_inject_event(handle, EV_LED, LED_SCROLLL, !!(leds & 0x01));
-		input_inject_event(handle, EV_LED, LED_NUML,    !!(leds & 0x02));
-		input_inject_event(handle, EV_LED, LED_CAPSL,   !!(leds & 0x04));
-		input_inject_event(handle, EV_SYN, SYN_REPORT, 0);
-	}
+	tasklet_disable(&keyboard_tasklet);
+	led_trigger_event(trigger, ledstate & (1 << led) ? LED_FULL : LED_OFF);
+	tasklet_enable(&keyboard_tasklet);
+}
+static void kbd_lockstate_trigger_activate(struct led_classdev *cdev)
+{
+	struct led_trigger *trigger = cdev->trigger;
+	int led = trigger - ledtrig_lockstate;
 
-	return 0;
+	tasklet_disable(&keyboard_tasklet);
+	led_trigger_event(trigger, lockstate & (1 << led) ? LED_FULL : LED_OFF);
+	tasklet_enable(&keyboard_tasklet);
 }
 
 /**
@@ -1120,10 +1155,24 @@
 	spin_unlock_irqrestore(&led_lock, flags);
 
 	if (leds != ledstate) {
-		input_handler_for_each_handle(&kbd_handler, &leds,
-					      kbd_update_leds_helper);
+		int i;
+		for (i = 0; i < ARRAY_SIZE(ledtrig_ledstate); i++)
+			if ((leds ^ ledstate) & (1 << i))
+				led_trigger_event(&ledtrig_ledstate[i],
+						leds & (1 << i)
+						? LED_FULL : LED_OFF);
 		ledstate = leds;
 	}
+
+	if (kbd->lockstate != lockstate) {
+		int i;
+		for (i = 0; i < ARRAY_SIZE(ledtrig_lockstate); i++)
+			if ((kbd->lockstate ^ lockstate) & (1 << i))
+				led_trigger_event(&ledtrig_lockstate[i],
+						kbd->lockstate & (1 << i)
+						? LED_FULL : LED_OFF);
+		lockstate = kbd->lockstate;
+	}
 }
 
 DECLARE_TASKLET_DISABLED(keyboard_tasklet, kbd_bh, 0);
@@ -1461,20 +1510,6 @@
 	kfree(handle);
 }
 
-/*
- * Start keyboard handler on the new keyboard by refreshing LED state to
- * match the rest of the system.
- */
-static void kbd_start(struct input_handle *handle)
-{
-	tasklet_disable(&keyboard_tasklet);
-
-	if (ledstate != 0xff)
-		kbd_update_leds_helper(handle, &ledstate);
-
-	tasklet_enable(&keyboard_tasklet);
-}
-
 static const struct input_device_id kbd_ids[] = {
 	{
 		.flags = INPUT_DEVICE_ID_MATCH_EVBIT,
@@ -1496,7 +1531,6 @@
 	.match		= kbd_match,
 	.connect	= kbd_connect,
 	.disconnect	= kbd_disconnect,
-	.start		= kbd_start,
 	.name		= "kbd",
 	.id_table	= kbd_ids,
 };
@@ -1520,6 +1554,11 @@
 	if (error)
 		return error;
 
+	for (i = 0; i < ARRAY_SIZE(ledtrig_ledstate); i++)
+		led_trigger_register(&ledtrig_ledstate[i]);
+	for (i = 0; i < ARRAY_SIZE(ledtrig_lockstate); i++)
+		led_trigger_register(&ledtrig_lockstate[i]);
+
 	tasklet_enable(&keyboard_tasklet);
 	tasklet_schedule(&keyboard_tasklet);
 
diff --exclude .svn -ur linux-3.10-orig/include/linux/input.h linux-3.10-perso/include/linux/input.h
--- linux-3.10-orig/include/linux/input.h	2013-04-29 13:27:16.959258613 +0200
+++ linux-3.10-perso/include/linux/input.h	2013-07-01 23:51:39.241317685 +0200
@@ -164,6 +164,8 @@
 	unsigned long snd[BITS_TO_LONGS(SND_CNT)];
 	unsigned long sw[BITS_TO_LONGS(SW_CNT)];
 
+	struct led_classdev *leds;
+
 	int (*open)(struct input_dev *dev);
 	void (*close)(struct input_dev *dev);
 	int (*flush)(struct input_dev *dev, struct file *file);
--- linux-3.10-orig/drivers/input/leds.h	1970-01-01 01:00:00.000000000 +0100
+++ linux-3.10-perso/drivers/input/leds.h	2011-11-14 02:24:26.738456456 +0100
@@ -0,0 +1,14 @@
+/*
+ * LED support for the input layer
+ *
+ * Copyright 2010-2013 Samuel Thibault <samuel.thibault at ens-lyon.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/input.h>
+
+extern int input_led_connect(struct input_dev *dev);
+extern void input_led_disconnect(struct input_dev *dev);
--- linux-3.10-orig/drivers/input/leds.c	1970-01-01 01:00:00.000000000 +0100
+++ linux-3.10-perso/drivers/input/leds.c	2011-11-14 03:23:07.578469395 +0100
@@ -0,0 +1,243 @@
+/*
+ * LED support for the input layer
+ *
+ * Copyright 2010-2013 Samuel Thibault <samuel.thibault at ens-lyon.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/leds.h>
+#include <linux/input.h>
+
+/*
+ * Keyboard LEDs are propagated by default like the following example:
+ *
+ * VT keyboard numlock trigger
+ * -> vt::numl VT LED
+ * -> vt-numl VT trigger
+ * -> per-device inputx::numl LED
+ *
+ * Userland can however choose the trigger for the vt::numl LED, or
+ * independently choose the trigger for any inputx::numl LED.
+ */
+
+/* VT LED classes and triggers are registered on-demand according to
+ * existing LED devices */
+
+/* Handler for VT LEDs, just triggers the corresponding VT trigger. */
+static void vt_led_set(struct led_classdev *cdev,
+			  enum led_brightness brightness);
+static struct led_classdev vt_leds[LED_CNT] = {
+#define DEFINE_INPUT_LED(vt_led, nam, deftrig) \
+	[vt_led] = { \
+		.name = "vt::"nam, \
+		.max_brightness = 1, \
+		.brightness_set = vt_led_set, \
+		.default_trigger = deftrig, \
+	}
+/* Default triggers for the VT LEDs just correspond to the legacy
+ * usage. */
+	DEFINE_INPUT_LED(LED_NUML, "numl", "numlock"),
+	DEFINE_INPUT_LED(LED_CAPSL, "capsl", "capslock"),
+	DEFINE_INPUT_LED(LED_SCROLLL, "scrolll", "scrollock"),
+	DEFINE_INPUT_LED(LED_COMPOSE, "compose", NULL),
+	DEFINE_INPUT_LED(LED_KANA, "kana", "kanalock"),
+	DEFINE_INPUT_LED(LED_SLEEP, "sleep", NULL),
+	DEFINE_INPUT_LED(LED_SUSPEND, "suspend", NULL),
+	DEFINE_INPUT_LED(LED_MUTE, "mute", NULL),
+	DEFINE_INPUT_LED(LED_MISC, "misc", NULL),
+	DEFINE_INPUT_LED(LED_MAIL, "mail", NULL),
+	DEFINE_INPUT_LED(LED_CHARGING, "charging", NULL),
+};
+static const char *const vt_led_names[LED_CNT] = {
+	[LED_NUML] = "numl",
+	[LED_CAPSL] = "capsl",
+	[LED_SCROLLL] = "scrolll",
+	[LED_COMPOSE] = "compose",
+	[LED_KANA] = "kana",
+	[LED_SLEEP] = "sleep",
+	[LED_SUSPEND] = "suspend",
+	[LED_MUTE] = "mute",
+	[LED_MISC] = "misc",
+	[LED_MAIL] = "mail",
+	[LED_CHARGING] = "charging",
+};
+/* Handler for hotplug initialization */
+static void vt_led_trigger_activate(struct led_classdev *cdev);
+/* VT triggers */
+static struct led_trigger vt_led_triggers[LED_CNT] = {
+#define DEFINE_INPUT_LED_TRIGGER(vt_led, nam) \
+	[vt_led] = { \
+		.name = "vt-"nam, \
+		.activate = vt_led_trigger_activate, \
+	}
+	DEFINE_INPUT_LED_TRIGGER(LED_NUML, "numl"),
+	DEFINE_INPUT_LED_TRIGGER(LED_CAPSL, "capsl"),
+	DEFINE_INPUT_LED_TRIGGER(LED_SCROLLL, "scrolll"),
+	DEFINE_INPUT_LED_TRIGGER(LED_COMPOSE, "compose"),
+	DEFINE_INPUT_LED_TRIGGER(LED_KANA, "kana"),
+	DEFINE_INPUT_LED_TRIGGER(LED_SLEEP, "sleep"),
+	DEFINE_INPUT_LED_TRIGGER(LED_SUSPEND, "suspend"),
+	DEFINE_INPUT_LED_TRIGGER(LED_MUTE, "mute"),
+	DEFINE_INPUT_LED_TRIGGER(LED_MISC, "misc"),
+	DEFINE_INPUT_LED_TRIGGER(LED_MAIL, "mail"),
+	DEFINE_INPUT_LED_TRIGGER(LED_CHARGING, "charging"),
+};
+/* Lock for registration coherency */
+static DEFINE_MUTEX(vt_led_registered_lock);
+/* Which VT LED classes and triggers are registered */
+static unsigned long vt_led_registered[BITS_TO_LONGS(LED_CNT)];
+/* Number of input devices having each LED */
+static int vt_led_references[LED_CNT];
+
+/* VT LED state change, tell the VT trigger.  */
+static void vt_led_set(struct led_classdev *cdev,
+			  enum led_brightness brightness)
+{
+	int led = cdev - vt_leds;
+
+	led_trigger_event(&vt_led_triggers[led], !!brightness);
+}
+
+/* LED state change for some keyboard, notify that keyboard.  */
+static void perdevice_input_led_set(struct led_classdev *cdev,
+			  enum led_brightness brightness)
+{
+	struct input_dev *dev;
+	struct led_classdev *leds;
+	int led;
+
+	dev = cdev->dev->platform_data;
+	if (!dev)
+		/* Still initializing */
+		return;
+	leds = dev->leds;
+	led = cdev - leds;
+
+	input_event(dev, EV_LED, led, !!brightness);
+	input_event(dev, EV_SYN, SYN_REPORT, 0);
+}
+
+/* Keyboard hotplug, initialize its LED status */
+static void vt_led_trigger_activate(struct led_classdev *cdev)
+{
+	struct led_trigger *trigger = cdev->trigger;
+	int led = trigger - vt_led_triggers;
+
+	if (cdev->brightness_set)
+		cdev->brightness_set(cdev, vt_leds[led].brightness);
+}
+
+/* Free led stuff from input device, used at abortion and disconnection.  */
+static void input_led_delete(struct input_dev *dev)
+{
+	if (dev) {
+		struct led_classdev *leds = dev->leds;
+		if (leds) {
+			int i;
+			for (i = 0; i < LED_CNT; i++)
+				kfree(leds[i].name);
+			kfree(leds);
+			dev->leds = NULL;
+		}
+	}
+}
+
+/* A new input device with potential LEDs to connect.  */
+int input_led_connect(struct input_dev *dev)
+{
+	int i, error = 0;
+	struct led_classdev *leds;
+
+	dev->leds = leds = kzalloc(sizeof(*leds) * LED_CNT, GFP_KERNEL);
+	if (!dev->leds)
+		return -ENOMEM;
+
+	/* lazily register missing VT LEDs */
+	mutex_lock(&vt_led_registered_lock);
+	for (i = 0; i < LED_CNT; i++)
+		if (vt_leds[i].name && test_bit(i, dev->ledbit)) {
+			if (!vt_led_references[i]) {
+				led_trigger_register(&vt_led_triggers[i]);
+				/* This keyboard is first to have led i,
+				 * try to register it */
+				if (!led_classdev_register(NULL, &vt_leds[i]))
+					vt_led_references[i] = 1;
+				else
+					led_trigger_unregister(&vt_led_triggers[i]);
+			} else
+				vt_led_references[i]++;
+		}
+	mutex_unlock(&vt_led_registered_lock);
+
+	/* and register this device's LEDs */
+	for (i = 0; i < LED_CNT; i++)
+		if (vt_leds[i].name && test_bit(i, dev->ledbit)) {
+			leds[i].name = kasprintf(GFP_KERNEL, "%s::%s",
+						dev_name(&dev->dev),
+						vt_led_names[i]);
+			if (!leds[i].name) {
+				error = -ENOMEM;
+				goto err;
+			}
+			leds[i].max_brightness = 1;
+			leds[i].brightness_set = perdevice_input_led_set;
+			leds[i].default_trigger = vt_led_triggers[i].name;
+		}
+
+	/* No issue so far, we can register for real.  */
+	for (i = 0; i < LED_CNT; i++)
+		if (leds[i].name) {
+			led_classdev_register(&dev->dev, &leds[i]);
+			leds[i].dev->platform_data = dev;
+			perdevice_input_led_set(&leds[i],
+					vt_leds[i].brightness);
+		}
+
+	return 0;
+
+err:
+	input_led_delete(dev);
+	return error;
+}
+
+/* Disconnected input device. Clean it, and deregister now-useless VT LEDs
+ * and triggers.  */
+extern void input_led_disconnect(struct input_dev *dev)
+{
+	int i;
+	struct led_classdev *leds = dev->leds;
+
+	for (i = 0; i < LED_CNT; i++)
+		if (leds[i].name)
+			led_classdev_unregister(&leds[i]);
+
+	input_led_delete(dev);
+
+	mutex_lock(&vt_led_registered_lock);
+	for (i = 0; i < LED_CNT; i++) {
+		if (!vt_leds[i].name || !test_bit(i, dev->ledbit))
+			continue;
+
+		vt_led_references[i]--;
+		if (vt_led_references[i]) {
+			/* Still some devices needing it */
+			continue;
+		}
+
+		led_classdev_unregister(&vt_leds[i]);
+		led_trigger_unregister(&vt_led_triggers[i]);
+		clear_bit(i, vt_led_registered);
+	}
+	mutex_unlock(&vt_led_registered_lock);
+}
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("User LED support for input layer");
+MODULE_AUTHOR("Samuel Thibault <samuel.thibault at ens-lyon.org>");


From mpa at pengutronix.de  Sun Jul  7 06:22:07 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 7 Jul 2013 12:22:07 +0200
Subject: [PATCH] ARM: dts: imx27 phyCARD-S remove wrong I2C RTC
In-Reply-To: <1373100718.107651915@f159.i.mail.ru>
References: <1372782469.486055292@f129.mail.ru>
 <1373031909-16178-1-git-send-email-mpa@pengutronix.de>
 <1373100718.107651915@f159.i.mail.ru>
Message-ID: <20130707102207.GI16871@s25.your-server.de>

On Sat, Jul 06, 2013 at 12:51:58PM +0400, Alexander Shiyan wrote:
> > Fixup of commit 7874d595b78e431f0f661d2fe47625649308a52e
> > "ARM: dts: Add device tree support for phycard pca100".
> > 
> > Remove wrong I2C RTC node.
> > 
> > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > ---
> > 
> > Thanks, Alexander, you are right. I2C2 has no RTC.
> ...
> 
> There are a couple of comments on this file.
> 
> I think that the OWIRE should be moved to the RDK.

I moved OWIRE and i2c1 to RDK. Both are not used on the SOM.

> ioexpander must contain "gpio-controller" at least, and for use it further,
> it is necessary to define the label for this node.

I checked all I2C devices in the board schematics. There is actually no
ioexpander. I don't know why it was added. I will send some I2C patches
later.

Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From shc_work at mail.ru  Sun Jul  7 06:31:41 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Sun, 07 Jul 2013 14:31:41 +0400
Subject: =?UTF-8?B?UmVbMl06IFtQQVRDSF0gQVJNOiBkdHM6IGlteDI3IHBoeUNBUkQtUyByZW1v?=
 =?UTF-8?B?dmUgd3JvbmcgSTJDIFJUQw==?=
In-Reply-To: <20130707102207.GI16871@s25.your-server.de>
References: <1372782469.486055292@f129.mail.ru>
 <1373100718.107651915@f159.i.mail.ru>
 <20130707102207.GI16871@s25.your-server.de>
Message-ID: <1373193101.622550139@f60.mail.ru>

> On Sat, Jul 06, 2013 at 12:51:58PM +0400, Alexander Shiyan wrote:
> > > Fixup of commit 7874d595b78e431f0f661d2fe47625649308a52e
> > > "ARM: dts: Add device tree support for phycard pca100".
> > > 
> > > Remove wrong I2C RTC node.
> > > 
> > > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > > ---
> > > 
> > > Thanks, Alexander, you are right. I2C2 has no RTC.
> > ...
> > 
> > There are a couple of comments on this file.
> > 
> > I think that the OWIRE should be moved to the RDK.
> 
> I moved OWIRE and i2c1 to RDK. Both are not used on the SOM.
> 
> > ioexpander must contain "gpio-controller" at least, and for use it further,
> > it is necessary to define the label for this node.
> 
> I checked all I2C devices in the board schematics. There is actually no
> ioexpander. I don't know why it was added. I will send some I2C patches
> later.

Perhaps the chip is mounted on the camera module.
A similar IC is exist on PCM-970 camera addon device.
If so, the device should also be moved to RDK.

---

From mpa at pengutronix.de  Sun Jul  7 06:44:52 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 7 Jul 2013 12:44:52 +0200
Subject: [PATCH] ARM: dts: imx27 phyCARD-S remove wrong I2C RTC
In-Reply-To: <1373193101.622550139@f60.mail.ru>
References: <1372782469.486055292@f129.mail.ru>
 <1373100718.107651915@f159.i.mail.ru>
 <20130707102207.GI16871@s25.your-server.de>
 <1373193101.622550139@f60.mail.ru>
Message-ID: <20130707104452.GJ16871@s25.your-server.de>

On Sun, Jul 07, 2013 at 02:31:41PM +0400, Alexander Shiyan wrote:
> > On Sat, Jul 06, 2013 at 12:51:58PM +0400, Alexander Shiyan wrote:
> > > > Fixup of commit 7874d595b78e431f0f661d2fe47625649308a52e
> > > > "ARM: dts: Add device tree support for phycard pca100".
> > > > 
> > > > Remove wrong I2C RTC node.
> > > > 
> > > > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > > > ---
> > > > 
> > > > Thanks, Alexander, you are right. I2C2 has no RTC.
> > > ...
> > > 
> > > There are a couple of comments on this file.
> > > 
> > > I think that the OWIRE should be moved to the RDK.
> > 
> > I moved OWIRE and i2c1 to RDK. Both are not used on the SOM.
> > 
> > > ioexpander must contain "gpio-controller" at least, and for use it further,
> > > it is necessary to define the label for this node.
> > 
> > I checked all I2C devices in the board schematics. There is actually no
> > ioexpander. I don't know why it was added. I will send some I2C patches
> > later.
> 
> Perhaps the chip is mounted on the camera module.
> A similar IC is exist on PCM-970 camera addon device.
> If so, the device should also be moved to RDK.

Yes that's possible. But in that case I think the ioexpander should be
removed from both dts files because the Phytec phyCARD-S RDK does not
include a camera module.

Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From sebastian.hesselbarth at gmail.com  Sun Jul  7 06:52:52 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Sun, 07 Jul 2013 12:52:52 +0200
Subject: Second ethernet on kirkwood does not work when probed through DT
In-Reply-To: <20130706233912.00004044@unknown>
References: <20130706215426.6e666d6af0dc6c9ea5fe32cd@openwrt.org>
 <51D88A8E.1060104@gmail.com> <20130706233912.00004044@unknown>
Message-ID: <51D94884.4000204@gmail.com>

On 07/06/2013 11:39 PM, Jonas Gorski wrote:
> On Sat, 06 Jul 2013 23:22:22 +0200
> Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>  wrote:
>> On 07/06/2013 09:54 PM, Jonas Gorski wrote:
>>> Hello Sebastian,
>>>
>>> using your DT patches[1] (on top of 3.10) I can't get the second
>>> ethernet to work on my kirkwood board.
>>
>> Hi Jonas,
>>
>> next time please name your board, because there are plenty of it.
>> Kirkwood is just the SoC used on them.
>
> Oops, sorry. It's D-Link DIR-665, with a 6281. Currently not upstream,
> but mostly supported (the switch isn't supported by DSA but works fine
> without it).

Jonas,

sorry, I didn't realize you already sent your request on MLs. It was
too late yesterday :P I also added Florian, Jason, and Andrew to the Cc
list.

Ok, so the DIR665 has this switch configuration on both KW ethernet
controllers. Just to make sure, the first one is working but the second
isn't?

>>> (Both macs are connected to a switch, so use a fixed link, and no
>>> phy).
>>>
>>> Eth1 gets probed fine, but never gets a link when brought up, and
>>> trying to bring it down again hangs the board hard.
>>>
>>> Using Florian's older patches, it is brought up fine and works (after
>>> adapting the node names of course).
>>>
>>> Also I noticed that you named eth1's ethernet1-port node wrongly in
>>> (at least) your kirkwood conversion patch[2]; you used
>>>
>>> &eth1 { status = "okay"; ethernet1-port at 0 { must be @1--^ phy-handle
>>> =<&ethphy1>; }; };
>>
>> Can you please try to leave ethernet1-port at 0 and match
>> the one in kirkwood.dtsi?
>>
>> Both "ports" need reg =<0>  as there is two controllers
>> with one port at 0 on Kirkwood.
>
> kirkwood.dtsi itself says ethernet1-port at 1 with reg =<1>.
>
> Changing reg to 0 for eth1 brings:

The error below is a naming issue for the port. As there is only one
port per controller, both reg properties of the port nodes of
kirkwood.dtsi have to be <0> as they determine the register offset
within the controller registers. As mentioned before, KW has a
dual-controller, single port configuration.

So the wrong reg property in kirkwood.dtsi is a bug and I will update
the patch.

Second, mv643xx_eth as in net-next does a
platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number)
which will cause two devices named mv643xx_eth_port.0 if you change
both of the reg property to <0>.

A quick fix would be to change the above to
platform_device_alloc(pnp->name, ppd.port_number)
so the port devices will be named after the device nodes name.

Also, for this I will prepare a patch. But the rename of the port
devices could again raise the clock gating/loosing MAC issue.

(I know again, why I hate this shared/port separation of mv643xx_eth)

Anyway, can you please try to have both ports reg properties set
to <0>, with nodes named ethernet0-port at 0 and ethernet1-port at 0,
and the platform_device_alloc in mv643xx_eth modified?

Sebastian

> [    9.586915] ------------[ cut here ]------------
> [    9.591590] WARNING: at fs/sysfs/dir.c:530 sysfs_add_one+0x88/0xa8()
> [    9.597973] sysfs: cannot create duplicate filename '/devices/platform/mv643xx_eth_port.0'
> [    9.606286] Modules linked in:
> [    9.609366] CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0 #12
> [    9.615231] Backtrace:
> [    9.617714] [<c001352c>] (dump_backtrace+0x0/0x114) from [<c00136d4>] (show_stack+0x18/0x1c)
> [    9.626205]  r6:00000212 r5:c02cd6e0 r4:c782fbe0 r3:00000000
> [    9.631972] [<c00136bc>] (show_stack+0x0/0x1c) from [<c010a080>] (dump_stack+0x20/0x28)
> [    9.640024] [<c010a060>] (dump_stack+0x0/0x28) from [<c001bdf4>] (warn_slowpath_common+0x58/0x74)
> [    9.648958] [<c001bd9c>] (warn_slowpath_common+0x0/0x74) from [<c001beb4>] (warn_slowpath_fmt+0x38/0x40)
> [    9.658492]  r8:c780d288 r7:c7823000 r6:c782fc28 r5:c73c1c88 r4:c782fc04
> r3:00000009
> [    9.666436] [<c001be7c>] (warn_slowpath_fmt+0x0/0x40) from [<c00ccdf4>] (sysfs_add_one+0x88/0xa8)
> [    9.675357]  r3:c7823000 r2:c02cd750
> [    9.678964]  r4:ffffffef
> [    9.681539] [<c00ccd6c>] (sysfs_add_one+0x0/0xa8) from [<c00ccfd4>] (create_dir+0x70/0xc0)
> [    9.689836]  r7:c78c64d8 r6:00000000 r5:c73c1c88 r4:00002001
> [    9.695577] [<c00ccf64>] (create_dir+0x0/0xc0) from [<c00cd358>] (sysfs_create_dir+0xbc/0xdc)
> [    9.704165] [<c00cd29c>] (sysfs_create_dir+0x0/0xdc) from [<c010bde4>] (kobject_add_internal+0xb8/0x1e4)
> [    9.713698]  r6:c07ae3b0 r5:c78c64d8 r4:c78c64d8
> [    9.718375] [<c010bd2c>] (kobject_add_internal+0x0/0x1e4) from [<c010c1ec>] (kobject_add+0x80/0x98)
> [    9.727487] [<c010c16c>] (kobject_add+0x0/0x98) from [<c015f6d0>] (device_add+0xd8/0x54c)
> [    9.735708]  r3:00000000 r2:00000000
> [    9.739315]  r6:00000000 r5:c78c64d0 r4:c78c64c0
> [    9.744002] [<c015f5f8>] (device_add+0x0/0x54c) from [<c0163348>] (platform_device_add+0x14c/0x1e0)
> [    9.753117] [<c01631fc>] (platform_device_add+0x0/0x1e0) from [<c0193014>] (mv643xx_eth_shared_of_add_port+0x240/0x2a8)
> [    9.763962]  r8:00000e00 r7:c73b1b70 r6:0000003e r5:00000000 r4:c78c64c0
> r3:00000000
> [    9.771899] [<c0192dd4>] (mv643xx_eth_shared_of_add_port+0x0/0x2a8) from [<c01932a8>] (mv643xx_eth_shared_probe+0x22c/0x318)
> [    9.783172]  r5:c08ea74c r4:c08ea89c
> [    9.786790] [<c019307c>] (mv643xx_eth_shared_probe+0x0/0x318) from [<c0162ef0>] (platform_drv_probe+0x1c/0x20)
> [    9.796860] [<c0162ed4>] (platform_drv_probe+0x0/0x20) from [<c0161df8>] (driver_probe_device+0xe4/0x210)
> [    9.806493] [<c0161d14>] (driver_probe_device+0x0/0x210) from [<c0161f8c>] (__driver_attach+0x68/0x8c)
> [    9.815853]  r7:00000000 r6:c07b3f64 r5:c785bdb0 r4:c785bde4
> [    9.821594] [<c0161f24>] (__driver_attach+0x0/0x8c) from [<c0160714>] (bus_for_each_dev+0x58/0x90)
> [    9.830600]  r6:c07b3f64 r5:c0161f24 r4:00000000 r3:00000002
> [    9.836329] [<c01606bc>] (bus_for_each_dev+0x0/0x90) from [<c016192c>] (driver_attach+0x20/0x28)
> [    9.845162]  r6:c07ae368 r5:c07b3f64 r4:c73ad4a0
> [    9.849836] [<c016190c>] (driver_attach+0x0/0x28) from [<c01614ec>] (bus_add_driver+0xb8/0x21c)
> [    9.858596] [<c0161434>] (bus_add_driver+0x0/0x21c) from [<c016227c>] (driver_register+0xa8/0x138)
> [    9.867606]  r8:0000003e r7:00000000 r6:c07b3f64 r5:c033dd5c r4:c034200c
> [    9.874409] [<c01621d4>] (driver_register+0x0/0x138) from [<c016301c>] (platform_driver_register+0x4c/0x60)
> [    9.884216] [<c0162fd0>] (platform_driver_register+0x0/0x60) from [<c0335f48>] (mv643xx_eth_init_module+0x14/0x44)
> [    9.894633] [<c0335f34>] (mv643xx_eth_init_module+0x0/0x44) from [<c0010b50>] (do_one_initcall+0x9c/0x15c)
> [    9.904335]  r4:c034200c r3:00000000
> [    9.907956] [<c0010ab4>] (do_one_initcall+0x0/0x15c) from [<c0322938>] (kernel_init_freeable+0xf8/0x1c4)
> [    9.917512] [<c0322840>] (kernel_init_freeable+0x0/0x1c4) from [<c000c338>] (kernel_init+0x10/0x104)
> [    9.926709] [<c000c328>] (kernel_init+0x0/0x104) from [<c0008a30>] (ret_from_fork+0x14/0x24)
> [    9.935196]  r4:00000000 r3:00000000
> [    9.938838] ---[ end trace 026e20e7bf6738e2 ]---
> [    9.943497] ------------[ cut here ]------------
> [    9.948142] WARNING: at lib/kobject.c:196 kobject_add_internal+0x17c/0x1e4()
> [    9.955238] kobject_add_internal failed for mv643xx_eth_port.0 with -EEXIST, don't try to register things with the same name in the same directory.
> [    9.968521] Modules linked in:
> [    9.971611] CPU: 0 PID: 1 Comm: swapper Tainted: G        W    3.10.0 #12
> [    9.978423] Backtrace:
> [    9.980907] [<c001352c>] (dump_backtrace+0x0/0x114) from [<c00136d4>] (show_stack+0x18/0x1c)
> [    9.989377]  r6:000000c4 r5:c02dd9d8 r4:c782fc60 r3:00000000
> [    9.995120] [<c00136bc>] (show_stack+0x0/0x1c) from [<c010a080>] (dump_stack+0x20/0x28)
> [   10.003181] [<c010a060>] (dump_stack+0x0/0x28) from [<c001bdf4>] (warn_slowpath_common+0x58/0x74)
> [   10.012118] [<c001bd9c>] (warn_slowpath_common+0x0/0x74) from [<c001beb4>] (warn_slowpath_fmt+0x38/0x40)
> [   10.021654]  r8:c07ae3a8 r7:c07ae3b0 r6:c07ae3b0 r5:c78c64d8 r4:c782fc84
> r3:00000009
> [   10.029582] [<c001be7c>] (warn_slowpath_fmt+0x0/0x40) from [<c010bea8>] (kobject_add_internal+0x17c/0x1e4)
> [   10.039287]  r3:c02dd9c0 r2:c02ddb40
> [   10.042911]  r4:c78c64d8
> [   10.045470] [<c010bd2c>] (kobject_add_internal+0x0/0x1e4) from [<c010c1ec>] (kobject_add+0x80/0x98)
> [   10.054578] [<c010c16c>] (kobject_add+0x0/0x98) from [<c015f6d0>] (device_add+0xd8/0x54c)
> [   10.062804]  r3:00000000 r2:00000000
> [   10.066411]  r6:00000000 r5:c78c64d0 r4:c78c64c0
> [   10.071098] [<c015f5f8>] (device_add+0x0/0x54c) from [<c0163348>] (platform_device_add+0x14c/0x1e0)
> [   10.080207] [<c01631fc>] (platform_device_add+0x0/0x1e0) from [<c0193014>] (mv643xx_eth_shared_of_add_port+0x240/0x2a8)
> [   10.091049]  r8:00000e00 r7:c73b1b70 r6:0000003e r5:00000000 r4:c78c64c0
> r3:00000000
> [   10.098977] [<c0192dd4>] (mv643xx_eth_shared_of_add_port+0x0/0x2a8) from [<c01932a8>] (mv643xx_eth_shared_probe+0x22c/0x318)
> [   10.110252]  r5:c08ea74c r4:c08ea89c
> [   10.113870] [<c019307c>] (mv643xx_eth_shared_probe+0x0/0x318) from [<c0162ef0>] (platform_drv_probe+0x1c/0x20)
> [   10.123938] [<c0162ed4>] (platform_drv_probe+0x0/0x20) from [<c0161df8>] (driver_probe_device+0xe4/0x210)
> [   10.133571] [<c0161d14>] (driver_probe_device+0x0/0x210) from [<c0161f8c>] (__driver_attach+0x68/0x8c)
> [   10.142932]  r7:00000000 r6:c07b3f64 r5:c785bdb0 r4:c785bde4
> [   10.148662] [<c0161f24>] (__driver_attach+0x0/0x8c) from [<c0160714>] (bus_for_each_dev+0x58/0x90)
> [   10.157670]  r6:c07b3f64 r5:c0161f24 r4:00000000 r3:00000002
> [   10.163409] [<c01606bc>] (bus_for_each_dev+0x0/0x90) from [<c016192c>] (driver_attach+0x20/0x28)
> [   10.172241]  r6:c07ae368 r5:c07b3f64 r4:c73ad4a0
> [   10.176914] [<c016190c>] (driver_attach+0x0/0x28) from [<c01614ec>] (bus_add_driver+0xb8/0x21c)
> [   10.185674] [<c0161434>] (bus_add_driver+0x0/0x21c) from [<c016227c>] (driver_register+0xa8/0x138)
> [   10.194686]  r8:0000003e r7:00000000 r6:c07b3f64 r5:c033dd5c r4:c034200c
> [   10.201497] [<c01621d4>] (driver_register+0x0/0x138) from [<c016301c>] (platform_driver_register+0x4c/0x60)
> [   10.211301] [<c0162fd0>] (platform_driver_register+0x0/0x60) from [<c0335f48>] (mv643xx_eth_init_module+0x14/0x44)
> [   10.221720] [<c0335f34>] (mv643xx_eth_init_module+0x0/0x44) from [<c0010b50>] (do_one_initcall+0x9c/0x15c)
> [   10.231422]  r4:c034200c r3:00000000
> [   10.235042] [<c0010ab4>] (do_one_initcall+0x0/0x15c) from [<c0322938>] (kernel_init_freeable+0xf8/0x1c4)
> [   10.244588] [<c0322840>] (kernel_init_freeable+0x0/0x1c4) from [<c000c338>] (kernel_init+0x10/0x104)
> [   10.253784] [<c000c328>] (kernel_init+0x0/0x104) from [<c0008a30>] (ret_from_fork+0x14/0x24)
> [   10.262274]  r4:00000000 r3:00000000
> [   10.265882] ---[ end trace 026e20e7bf6738e3 ]---
> [   10.270553] mv643xx_eth: probe of f1076000.ethernet-controller failed with error -17
>
>
>
> Regards
> Jonas



From jogo at openwrt.org  Sun Jul  7 07:26:07 2013
From: jogo at openwrt.org (Jonas Gorski)
Date: Sun, 7 Jul 2013 13:26:07 +0200
Subject: Second ethernet on kirkwood does not work when probed through DT
In-Reply-To: <51D94884.4000204@gmail.com>
References: <20130706215426.6e666d6af0dc6c9ea5fe32cd@openwrt.org>
 <51D88A8E.1060104@gmail.com> <20130706233912.00004044@unknown>
 <51D94884.4000204@gmail.com>
Message-ID: <20130707132607.00007188@unknown>

On Sun, 07 Jul 2013 12:52:52 +0200
Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> wrote:

> On 07/06/2013 11:39 PM, Jonas Gorski wrote:
> > On Sat, 06 Jul 2013 23:22:22 +0200
> > Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>  wrote:
> >> On 07/06/2013 09:54 PM, Jonas Gorski wrote:
> >>> Hello Sebastian,
> >>>
> >>> using your DT patches[1] (on top of 3.10) I can't get the second
> >>> ethernet to work on my kirkwood board.
> >>
> >> Hi Jonas,
> >>
> >> next time please name your board, because there are plenty of it.
> >> Kirkwood is just the SoC used on them.
> >
> > Oops, sorry. It's D-Link DIR-665, with a 6281. Currently not upstream,
> > but mostly supported (the switch isn't supported by DSA but works fine
> > without it).
> 
> Jonas,
> 
> sorry, I didn't realize you already sent your request on MLs. It was
> too late yesterday :P I also added Florian, Jason, and Andrew to the Cc
> list.
> 
> Ok, so the DIR665 has this switch configuration on both KW ethernet
> controllers. Just to make sure, the first one is working but the second
> isn't?

Right. Its a 7-Port switch (88E6171R) with two CPU ports, each
connected to one of the ethernet controllers. Then port vlans split the
switch into two groups; (lan1,lan2,lan3,lan4,eth0) and (wan,eth1).

The same setup is used on other kirkwood based routers (e.g. Linksys
EA4500).

> >>> (Both macs are connected to a switch, so use a fixed link, and no
> >>> phy).
> >>>
> >>> Eth1 gets probed fine, but never gets a link when brought up, and
> >>> trying to bring it down again hangs the board hard.
> >>>
> >>> Using Florian's older patches, it is brought up fine and works (after
> >>> adapting the node names of course).
> >>>
> >>> Also I noticed that you named eth1's ethernet1-port node wrongly in
> >>> (at least) your kirkwood conversion patch[2]; you used
> >>>
> >>> &eth1 { status = "okay"; ethernet1-port at 0 { must be @1--^ phy-handle
> >>> =<&ethphy1>; }; };
> >>
> >> Can you please try to leave ethernet1-port at 0 and match
> >> the one in kirkwood.dtsi?
> >>
> >> Both "ports" need reg =<0>  as there is two controllers
> >> with one port at 0 on Kirkwood.
> >
> > kirkwood.dtsi itself says ethernet1-port at 1 with reg =<1>.
> >
> > Changing reg to 0 for eth1 brings:
> 
> The error below is a naming issue for the port. As there is only one
> port per controller, both reg properties of the port nodes of
> kirkwood.dtsi have to be <0> as they determine the register offset
> within the controller registers. As mentioned before, KW has a
> dual-controller, single port configuration.
> 
> So the wrong reg property in kirkwood.dtsi is a bug and I will update
> the patch.
> 
> Second, mv643xx_eth as in net-next does a
> platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number)
> which will cause two devices named mv643xx_eth_port.0 if you change
> both of the reg property to <0>.
> 
> A quick fix would be to change the above to
> platform_device_alloc(pnp->name, ppd.port_number)
> so the port devices will be named after the device nodes name.
>
> Also, for this I will prepare a patch. But the rename of the port
> devices could again raise the clock gating/loosing MAC issue.

In my case it's a non-issue as the studid D-Link U-Boot doesn't even
setup a mac for eth1, so there's nothing to lose ;).

> (I know again, why I hate this shared/port separation of mv643xx_eth)
> 
> Anyway, can you please try to have both ports reg properties set
> to <0>, with nodes named ethernet0-port at 0 and ethernet1-port at 0,
> and the platform_device_alloc in mv643xx_eth modified?

In addition I added a static counter for the allocated devs (to not
overwrite the pointers in port_platdev[]).

That seems to work, as now eth1 comes up and works (successfully got a
IP through DHCP).


Regards
Jonas


From sebastian.hesselbarth at gmail.com  Sun Jul  7 07:36:51 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Sun, 07 Jul 2013 13:36:51 +0200
Subject: Second ethernet on kirkwood does not work when probed through DT
In-Reply-To: <20130707132607.00007188@unknown>
References: <20130706215426.6e666d6af0dc6c9ea5fe32cd@openwrt.org>
 <51D88A8E.1060104@gmail.com> <20130706233912.00004044@unknown>
 <51D94884.4000204@gmail.com> <20130707132607.00007188@unknown>
Message-ID: <51D952D3.8070401@gmail.com>

On 07/07/2013 01:26 PM, Jonas Gorski wrote:
> On Sun, 07 Jul 2013 12:52:52 +0200
> Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>  wrote:
>> The error below is a naming issue for the port. As there is only one
>> port per controller, both reg properties of the port nodes of
>> kirkwood.dtsi have to be<0>  as they determine the register offset
>> within the controller registers. As mentioned before, KW has a
>> dual-controller, single port configuration.
>>
>> So the wrong reg property in kirkwood.dtsi is a bug and I will update
>> the patch.
>>
>> Second, mv643xx_eth as in net-next does a
>> platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number)
>> which will cause two devices named mv643xx_eth_port.0 if you change
>> both of the reg property to<0>.
>>
>> A quick fix would be to change the above to
>> platform_device_alloc(pnp->name, ppd.port_number)
>> so the port devices will be named after the device nodes name.
>>
>> Also, for this I will prepare a patch. But the rename of the port
>> devices could again raise the clock gating/loosing MAC issue.
>
> In my case it's a non-issue as the studid D-Link U-Boot doesn't even
> setup a mac for eth1, so there's nothing to lose ;).
>
>> (I know again, why I hate this shared/port separation of mv643xx_eth)
>>
>> Anyway, can you please try to have both ports reg properties set
>> to<0>, with nodes named ethernet0-port at 0 and ethernet1-port at 0,
>> and the platform_device_alloc in mv643xx_eth modified?
>
> In addition I added a static counter for the allocated devs (to not
> overwrite the pointers in port_platdev[]).

Ok, but that is not required to make it work, is it? IMHO we should
honor what is passed by reg property, even it will be always zero
for KW and the other Orion SoCs. Otherwise, we would implicitly put
the numbering in the order of port nodes.

> That seems to work, as now eth1 comes up and works (successfully got a
> IP through DHCP).

Ok, great. Will prepare a fix for mv643xx_eth on top of net-next. And
an update of the kirkwood conversion patches.

Sebastian


From sebastian.hesselbarth at gmail.com  Sun Jul  7 07:44:11 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Sun, 07 Jul 2013 13:44:11 +0200
Subject: [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer
In-Reply-To: <51B8D310.4050404@linaro.org>
References: <51B8D310.4050404@linaro.org>
Message-ID: <51D9548B.9040907@gmail.com>

On 06/12/2013 09:59 PM, Daniel Lezcano wrote:
>
> The following changes since commit 762cf9695d714d312ef7369bed1b9f9467c9e64e:
>
>    Merge branch 'timers/clockevents' of
> git://git.linaro.org/people/dlezcano/clockevents into timers/core
> (2013-06-08 22:58:27 +0200)
>
> are available in the git repository at:
>
>
>    git://git.linaro.org/people/dlezcano/clockevents.git timers/clockevents
>
> for you to fetch changes up to fbb3cb01505e7365c70a7fe680e10ffff3175160:
>
>    clocksource: Add Marvell Orion SoC timer (2013-06-11 14:41:01 +0200)
>
> ----------------------------------------------------------------
> Sebastian Hesselbarth (1):
>        clocksource: Add Marvell Orion SoC timer

Thomas, John,

with tip timers/core PR sent, I realized that the above did not make it
in. As we have a whole bunch of cleanup and DT conversion patches for
v3.11-rc1 depending on it, would it be ok for you to let Jason Cooper
take it through his ARM sub-branch?

If you are fine with it, I will resend the patch and note that Daniel
can drop it and Jason will take it.

Sebastian

>   .../bindings/timer/marvell,orion-timer.txt         |   17 +++
>   drivers/clocksource/Kconfig                        |    5 +
>   drivers/clocksource/Makefile                       |    1 +
>   drivers/clocksource/time-orion.c                   |  150
> ++++++++++++++++++++
>   4 files changed, 173 insertions(+)
>   create mode 100644
> Documentation/devicetree/bindings/timer/marvell,orion-timer.txt
>   create mode 100644 drivers/clocksource/time-orion.c



From jogo at openwrt.org  Sun Jul  7 07:48:53 2013
From: jogo at openwrt.org (Jonas Gorski)
Date: Sun, 7 Jul 2013 13:48:53 +0200
Subject: Second ethernet on kirkwood does not work when probed through DT
In-Reply-To: <51D952D3.8070401@gmail.com>
References: <20130706215426.6e666d6af0dc6c9ea5fe32cd@openwrt.org>
 <51D88A8E.1060104@gmail.com> <20130706233912.00004044@unknown>
 <51D94884.4000204@gmail.com> <20130707132607.00007188@unknown>
 <51D952D3.8070401@gmail.com>
Message-ID: <20130707134853.00003b9d@unknown>

On Sun, 07 Jul 2013 13:36:51 +0200
Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> wrote:

> On 07/07/2013 01:26 PM, Jonas Gorski wrote:
> > On Sun, 07 Jul 2013 12:52:52 +0200
> > Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>  wrote:
> >> Anyway, can you please try to have both ports reg properties set
> >> to<0>, with nodes named ethernet0-port at 0 and ethernet1-port at 0,
> >> and the platform_device_alloc in mv643xx_eth modified?
> >
> > In addition I added a static counter for the allocated devs (to not
> > overwrite the pointers in port_platdev[]).
> 
> Ok, but that is not required to make it work, is it? IMHO we should
> honor what is passed by reg property, even it will be always zero
> for KW and the other Orion SoCs. Otherwise, we would implicitly put
> the numbering in the order of port nodes.

No, picking the next free "slot" should work, too - it was just the
easiest to fix the name for the alloc to what seems to be expected by
other parts.

> > That seems to work, as now eth1 comes up and works (successfully got a
> > IP through DHCP).
> 
> Ok, great. Will prepare a fix for mv643xx_eth on top of net-next. And
> an update of the kirkwood conversion patches.


Thanks,
Jonas


From LW at KARO-electronics.de  Sun Jul  7 07:51:14 2013
From: LW at KARO-electronics.de (=?utf-8?Q?Lothar_Wa=C3=9Fmann?=)
Date: Sun, 7 Jul 2013 13:51:14 +0200
Subject: [PATCH v3 4/6] ARM: dts: imx6q{dl}: fix the wrong RTS/CTS pad name
In-Reply-To: <20130706050803.GC30164@S2101-09.ap.freescale.net>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>
 <1373004752-21302-5-git-send-email-b32955@freescale.com>
 <20130706050803.GC30164@S2101-09.ap.freescale.net>
Message-ID: <20953.22066.706534.773272@ipc1.ka-ro>

Hi,

Shawn Guo writes:
> On Fri, Jul 05, 2013 at 02:12:30PM +0800, Huang Shijie wrote:
> > There is something wrong with the RTS/CTS pads:
> >   The RTS pad is assigned with the CTS's value;
> >   while the CTS pad is assigned with the RTS's value.
> > 
> 
> So basically, you are saying that select_input should be set up for CTS
> rather than RTS.  It seems that the people who generated the macro got
> the wrong input from developer.
> 
programming 'select_input' only makes sense for inputs, not outputs.
Since CTS is an output signal, select_input only makes sense for the
RTS function of the pads.


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________


From linux at arm.linux.org.uk  Sun Jul  7 08:32:40 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sun, 7 Jul 2013 13:32:40 +0100
Subject: amba-pl08x and 'get_signal' namespace collision/build error
In-Reply-To: <20130705061802.GB10947@intel.com>
References: <51C97F40.5030101@arm.com>
 <20130625184539.GB2718@n2100.arm.linux.org.uk>
 <20130626044842.GR23141@intel.com>
 <20130626081909.GD2718@n2100.arm.linux.org.uk>
 <20130626103930.GS23141@intel.com>
 <20130627094650.GC4283@n2100.arm.linux.org.uk>
 <CAOesGMgSPNggnBm=E3B774m7Ad_QMXdqvcGqRMxhap6dtpNtCg@mail.gmail.com>
 <20130705061802.GB10947@intel.com>
Message-ID: <20130707123240.GO24642@n2100.arm.linux.org.uk>

On Fri, Jul 05, 2013 at 11:48:02AM +0530, Vinod Koul wrote:
> On Wed, Jul 03, 2013 at 11:27:12AM -0700, Olof Johansson wrote:
> > This has now hit the mainline kernel, and several defconfigs (nhk815,
> > lpc32xx and the spear ones) are broken there.
> > 
> > Vinod, when are you sending up your pull request with the fix? It'd be
> > good to see it go in soon.
> It should be on its way by the weekend

It still isn't in the tree.

Personally, I think that the fix should have come via my tree, because
the breakage was caused my the changes in my tree - and for the last week
or more I've not been able to build any of these ARM Ltd devel platforms
because of this bug.

It also means that I'm not able to build test a load of changes I'm
currently working on against a recent kernel (or indeed any v3.10 kernel.)
In other words, the lack of this patch being merged is stopping me from
doing my job properly.  (Consider from your perspective: if I were to
break something you relied upon for a couple of weeks, how would you
feel about it?)

Please get this fix into mainline ASAP - even if you have to send it as a
patch separately to Linus rather than putting it as part of your normal
pull request.

Thanks.


From shawn.guo at linaro.org  Sun Jul  7 08:35:11 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Sun, 7 Jul 2013 20:35:11 +0800
Subject: [PATCH for linux-3.10.y] ARM: dts: imx: cpus/cpu nodes dts updates
Message-ID: <1373200511-18917-1-git-send-email-shawn.guo@linaro.org>

From: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

commit 7925e89f54fc49bcd1e73f0a65c4a3eb35b9cfb1 upstream.

Commit 1ba9bf0 (ARM: 7762/1: kernel: fix arm_dt_init_cpu_maps() to skip
non-cpu nodes) goes into v3.10 with leaving the dts cpu node update to
the next release (v3.11).  This unfortunately causes a regression on
multi-core system, e.g. i.MX6 Quad, that is only one cpu core will be
brought up by kernel.

CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x80538c18 - 0x80538c88
Brought up 1 CPUs
SMP: Total of 1 processors activated (1581.05 BogoMIPS).

Fix the regression by applying the necessary dts updates.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
Greg,

This is a fix for 3.10 stable kernel.  This is my first time to forward
a patch that is already on mainline to stable kernel.  Please let me
know the correct process if what I'm doing here is wrong.

Shawn

 arch/arm/boot/dts/imx23.dtsi  |    8 ++++++--
 arch/arm/boot/dts/imx28.dtsi  |    8 ++++++--
 arch/arm/boot/dts/imx6dl.dtsi |    2 ++
 arch/arm/boot/dts/imx6q.dtsi  |    4 ++++
 4 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 73fd7d0..587ceef 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -23,8 +23,12 @@
 	};
 
 	cpus {
-		cpu at 0 {
-			compatible = "arm,arm926ejs";
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 600f7cb..4c10a19 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -32,8 +32,12 @@
 	};
 
 	cpus {
-		cpu at 0 {
-			compatible = "arm,arm926ejs";
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
 		};
 	};
 
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 5bcdf3a..62dc781 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -18,12 +18,14 @@
 
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <0>;
 			next-level-cache = <&L2>;
 		};
 
 		cpu at 1 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <1>;
 			next-level-cache = <&L2>;
 		};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 21e6758..dc54a72 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -18,6 +18,7 @@
 
 		cpu at 0 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <0>;
 			next-level-cache = <&L2>;
 			operating-points = <
@@ -39,18 +40,21 @@
 
 		cpu at 1 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <1>;
 			next-level-cache = <&L2>;
 		};
 
 		cpu at 2 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <2>;
 			next-level-cache = <&L2>;
 		};
 
 		cpu at 3 {
 			compatible = "arm,cortex-a9";
+			device_type = "cpu";
 			reg = <3>;
 			next-level-cache = <&L2>;
 		};
-- 
1.7.9.5




From linux at arm.linux.org.uk  Sun Jul  7 08:43:27 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sun, 7 Jul 2013 13:43:27 +0100
Subject: [RFC PATCH 0/9] Clean up debugging support
Message-ID: <20130707124326.GP24642@n2100.arm.linux.org.uk>

This patch series cleans up some aspects of the LL debug support by:

- Removing the multi-level choice madness
- Consolidating the 8250 debug UART support
- Consolidating the PL01x debug UART support

The differences between the various 8250 debug UART implementations are:
- Physical/Virtual addresses
- Register offset shift
- Access size
- Flow control

These are now parameterised in the Kconfig.  I've left OMAP because
that's a complex case, but it looks like it can be adapted to it if
some of the unnecessary complexity is eliminated.

Similar is done with the PL01x implementation, except a few complex
cases are left - automatic detection on Versatile Express, and the
Ux500 support which looks like it'll take some picking through header
files to work out what the base addresses are.

The approach I've taken is to consolidate without losing any information
- what that means it that the Kconfig parameters have rather a lot of
dependencies/defaults associated with them, and the main choice
statement keeps all its options.

In the longer run, I want to consolidate that down to just a pair of
"Kernel low-level debugging messages via 8250 UART" and "Kernel
low-level debugging messages via PL01x UART" options, possibly with the
base addresses/shifts/access width/flow control supplied by the user.

I've not really been able to test these because of the current breakage
on ARM devel platforms caused by the "get_signal" saga, so these are
RFC only at the moment.

Nevertheless, even avoiding the loss of information, I think the diffstat
is quite impressive:

 arch/arm/Kconfig.debug                             |  488 +++++++++++++-------
 arch/arm/include/asm/hardware/debug-8250.S         |   29 --
 arch/arm/include/asm/hardware/debug-pl01x.S        |   29 --
 arch/arm/include/debug/8250.S                      |   54 +++
 arch/arm/include/debug/8250_32.S                   |   27 --
 arch/arm/include/debug/bcm2835.S                   |   22 -
 arch/arm/include/debug/cns3xxx.S                   |   19 -
 arch/arm/include/debug/highbank.S                  |   17 -
 arch/arm/include/debug/mvebu.S                     |   30 --
 arch/arm/include/debug/mxs.S                       |   27 --
 arch/arm/include/debug/nomadik.S                   |   20 -
 arch/arm/include/debug/nspire.S                    |   28 --
 arch/arm/include/debug/picoxcell.S                 |   19 -
 arch/arm/include/debug/pl01x.S                     |   36 ++
 arch/arm/include/debug/pxa.S                       |   33 --
 arch/arm/include/debug/rockchip.S                  |   42 --
 arch/arm/include/debug/socfpga.S                   |   21 -
 arch/arm/include/debug/sunxi.S                     |   27 --
 arch/arm/include/debug/u300.S                      |   18 -
 arch/arm/include/debug/ux500.S                     |    2 +-
 arch/arm/include/debug/vexpress.S                  |   48 +--
 arch/arm/mach-dove/include/mach/debug-macro.S      |   19 -
 arch/arm/mach-ebsa110/include/mach/debug-macro.S   |   22 -
 arch/arm/mach-ep93xx/include/mach/debug-macro.S    |   21 -
 .../arm/mach-footbridge/include/mach/debug-macro.S |   15 -
 arch/arm/mach-gemini/include/mach/debug-macro.S    |   21 -
 .../arm/mach-integrator/include/mach/debug-macro.S |   20 -
 arch/arm/mach-iop13xx/include/mach/debug-macro.S   |   24 -
 arch/arm/mach-iop32x/include/mach/debug-macro.S    |   21 -
 arch/arm/mach-iop33x/include/mach/debug-macro.S    |   22 -
 arch/arm/mach-ixp4xx/include/mach/debug-macro.S    |   26 -
 arch/arm/mach-kirkwood/include/mach/debug-macro.S  |   19 -
 arch/arm/mach-lpc32xx/include/mach/debug-macro.S   |   29 --
 arch/arm/mach-mv78xx0/include/mach/debug-macro.S   |   19 -
 arch/arm/mach-orion5x/include/mach/debug-macro.S   |   21 -
 arch/arm/mach-realview/include/mach/debug-macro.S  |   29 --
 arch/arm/mach-rpc/include/mach/debug-macro.S       |   23 -
 arch/arm/mach-versatile/include/mach/debug-macro.S |   21 -
 38 files changed, 423 insertions(+), 985 deletions(-)



From rmk+kernel at arm.linux.org.uk  Sun Jul  7 08:44:29 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Sun, 07 Jul 2013 13:44:29 +0100
Subject: [PATCH RFC 1/9] ARM: debug: fix wording error in DEBUG_LL_UART_NONE
 option help
In-Reply-To: <20130707124326.GP24642@n2100.arm.linux.org.uk>
References: <20130707124326.GP24642@n2100.arm.linux.org.uk>
Message-ID: <E1UvoKL-0006Ha-LV@rmk-PC.arm.linux.org.uk>

The DEBUG_LL_UART_NONE option was moved from the top of the list to
the bottom - unfortunately, it still referred to the options "below"
rather than "above".

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 5b7be8d..2cc4b31 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -579,7 +579,7 @@ choice
 		depends on !ARCH_MULTIPLATFORM
 		help
 		  Say Y here if your platform doesn't provide a UART option
-		  below. This relies on your platform choosing the right UART
+		  above. This relies on your platform choosing the right UART
 		  definition internally in order for low-level debugging to
 		  work.
 
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Sun Jul  7 08:46:30 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Sun, 07 Jul 2013 13:46:30 +0100
Subject: [PATCH RFC 3/9] ARM: debug: provide 8250 debug uart flow control
 configuration option
In-Reply-To: <20130707124326.GP24642@n2100.arm.linux.org.uk>
References: <20130707124326.GP24642@n2100.arm.linux.org.uk>
Message-ID: <E1UvoMI-0006Hj-8e@rmk-PC.arm.linux.org.uk>

Move the definition out of the machine class debug-macro.S header
into the Kconfig files.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug                             |    9 +++++++++
 arch/arm/include/asm/hardware/debug-8250.S         |    2 +-
 arch/arm/mach-ebsa110/include/mach/debug-macro.S   |    1 -
 .../arm/mach-footbridge/include/mach/debug-macro.S |    1 -
 arch/arm/mach-gemini/include/mach/debug-macro.S    |    1 -
 arch/arm/mach-rpc/include/mach/debug-macro.S       |    1 -
 6 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index f9c1fc9..434a22c 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -856,6 +856,15 @@ config DEBUG_LL_INCLUDE
 	default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
 	default "mach/debug-macro.S"
 
+config DEBUG_UART_8250
+	def_bool y
+	depends on ARCH_EBSA110 || (FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
+		ARCH_GEMINI || ARCH_RPC
+
+config DEBUG_UART_8250_FLOW_CONTROL
+	def_bool y if ARCH_EBSA110 || FOOTBRIDGE || ARCH_GEMINI || ARCH_RPC
+	depends on DEBUG_UART_8250
+
 config DEBUG_UNCOMPRESS
 	bool
 	default y if ARCH_MULTIPLATFORM && DEBUG_LL && \
diff --git a/arch/arm/include/asm/hardware/debug-8250.S b/arch/arm/include/asm/hardware/debug-8250.S
index 22c6892..bca3045 100644
--- a/arch/arm/include/asm/hardware/debug-8250.S
+++ b/arch/arm/include/asm/hardware/debug-8250.S
@@ -21,7 +21,7 @@
 		.endm
 
 		.macro	waituart,rd,rx
-#ifdef FLOW_CONTROL
+#ifdef CONFIG_DEBUG_UART_8250_FLOW_CONTROL
 1001:		ldrb	\rd, [\rx, #UART_MSR << UART_SHIFT]
 		tst	\rd, #UART_MSR_CTS
 		beq	1001b
diff --git a/arch/arm/mach-ebsa110/include/mach/debug-macro.S b/arch/arm/mach-ebsa110/include/mach/debug-macro.S
index bb02c05..9b66e79 100644
--- a/arch/arm/mach-ebsa110/include/mach/debug-macro.S
+++ b/arch/arm/mach-ebsa110/include/mach/debug-macro.S
@@ -18,5 +18,4 @@
 		.endm
 
 #define UART_SHIFT	2
-#define FLOW_CONTROL
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-footbridge/include/mach/debug-macro.S b/arch/arm/mach-footbridge/include/mach/debug-macro.S
index c169f0c..18130fe 100644
--- a/arch/arm/mach-footbridge/include/mach/debug-macro.S
+++ b/arch/arm/mach-footbridge/include/mach/debug-macro.S
@@ -23,7 +23,6 @@
 		.endm
 
 #define UART_SHIFT	0
-#define FLOW_CONTROL
 #include <asm/hardware/debug-8250.S>
 
 #else
diff --git a/arch/arm/mach-gemini/include/mach/debug-macro.S b/arch/arm/mach-gemini/include/mach/debug-macro.S
index 8376707..cdee448 100644
--- a/arch/arm/mach-gemini/include/mach/debug-macro.S
+++ b/arch/arm/mach-gemini/include/mach/debug-macro.S
@@ -17,5 +17,4 @@
 	.endm
 
 #define UART_SHIFT	2
-#define FLOW_CONTROL
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-rpc/include/mach/debug-macro.S b/arch/arm/mach-rpc/include/mach/debug-macro.S
index 6d28cc9..a92753d 100644
--- a/arch/arm/mach-rpc/include/mach/debug-macro.S
+++ b/arch/arm/mach-rpc/include/mach/debug-macro.S
@@ -19,5 +19,4 @@
 		.endm
 
 #define UART_SHIFT	2
-#define FLOW_CONTROL
 #include <asm/hardware/debug-8250.S>
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Sun Jul  7 08:45:29 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Sun, 07 Jul 2013 13:45:29 +0100
Subject: [PATCH RFC 2/9] ARM: debug: clean up low level kernel debugging
 selection
In-Reply-To: <20130707124326.GP24642@n2100.arm.linux.org.uk>
References: <20130707124326.GP24642@n2100.arm.linux.org.uk>
Message-ID: <E1UvoLJ-0006He-RH@rmk-PC.arm.linux.org.uk>

It is silly to bury UART selection under multiple levels of choice
statements, where the top level choice statement will only list
about four entries when a single SoC is selected.  Move the UART
selection up into the top level choice statement as it was always
intended to be.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug |  328 ++++++++++++++++++++++++++++--------------------
 1 files changed, 191 insertions(+), 137 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 2cc4b31..f9c1fc9 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -376,12 +376,72 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on TI-NSPIRE CX models.
 
-	config DEBUG_OMAP2PLUS_UART
-		bool "Kernel low-level debugging messages via OMAP2PLUS UART"
+	config DEBUG_OMAP2UART1
+		bool "OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards)"
 		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
 		help
-		  Say Y here if you want kernel low-level debugging support
-		  on OMAP2PLUS based platforms.
+		  This covers at least h4, 2430sdp, 3430sdp, 3630sdp,
+		  omap3 torpedo and 3530 lv som.
+
+	config DEBUG_OMAP2UART2
+		bool "Kernel low-level debugging messages via OMAP2/3/4 UART2"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_OMAP2UART3
+		bool "Kernel low-level debugging messages via OMAP2 UART3 (n8x0)"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_OMAP3UART3
+		bool "Kernel low-level debugging messages via OMAP3 UART3 (most omap3 boards)"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+		help
+		  This covers at least cm_t3x, beagle, crane, devkit8000,
+		  igep00x0, ldp, n900, n9(50), pandora, overo, touchbook,
+		  and 3517evm.
+
+	config DEBUG_OMAP4UART3
+		bool "Kernel low-level debugging messages via OMAP4/5 UART3 (omap4 blaze, panda, omap5 sevm)"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_OMAP3UART4
+		bool "Kernel low-level debugging messages via OMAP36XX UART4"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_OMAP4UART4
+		bool "Kernel low-level debugging messages via OMAP4/5 UART4"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_TI81XXUART1
+		bool "Kernel low-level debugging messages via TI81XX UART1 (ti8148evm)"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_TI81XXUART2
+		bool "Kernel low-level debugging messages via TI81XX UART2"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_TI81XXUART3
+		bool "Kernel low-level debugging messages via TI81XX UART3 (ti8168evm)"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_AM33XXUART1
+		bool "Kernel low-level debugging messages via AM33XX UART1"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_ZOOM_UART
+		bool "Kernel low-level debugging messages via Zoom2/3 UART"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
 
 	config DEBUG_PICOXCELL_UART
 		depends on ARCH_PICOXCELL
@@ -413,9 +473,58 @@ choice
 		  their output to the standard serial port on the RealView
 		  PB1176 platform.
 
-	config DEBUG_ROCKCHIP_UART
-		bool "Kernel low-level debugging messages via Rockchip UART"
+	config DEBUG_RK29_UART0
+		bool "Kernel low-level debugging messages via Rockchip RK29 UART0"
+		depends on ARCH_ROCKCHIP
+		select DEBUG_ROCKCHIP_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Rockchip based platforms.
+
+	config DEBUG_RK29_UART1
+		bool "Kernel low-level debugging messages via Rockchip RK29 UART1"
+		depends on ARCH_ROCKCHIP
+		select DEBUG_ROCKCHIP_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Rockchip based platforms.
+
+	config DEBUG_RK29_UART2
+		bool "Kernel low-level debugging messages via Rockchip RK29 UART2"
+		depends on ARCH_ROCKCHIP
+		select DEBUG_ROCKCHIP_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Rockchip based platforms.
+
+	config DEBUG_RK3X_UART0
+		bool "Kernel low-level debugging messages via Rockchip RK3X UART0"
+		depends on ARCH_ROCKCHIP
+		select DEBUG_ROCKCHIP_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Rockchip based platforms.
+
+	config DEBUG_RK3X_UART1
+		bool "Kernel low-level debugging messages via Rockchip RK3X UART1"
 		depends on ARCH_ROCKCHIP
+		select DEBUG_ROCKCHIP_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Rockchip based platforms.
+
+	config DEBUG_RK3X_UART2
+		bool "Kernel low-level debugging messages via Rockchip RK3X UART2"
+		depends on ARCH_ROCKCHIP
+		select DEBUG_ROCKCHIP_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Rockchip based platforms.
+
+	config DEBUG_RK3X_UART3
+		bool "Kernel low-level debugging messages via Rockchip RK3X UART3"
+		depends on ARCH_ROCKCHIP
+		select DEBUG_ROCKCHIP_UART
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Rockchip based platforms.
@@ -489,9 +598,54 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on Allwinner A1X based platforms on the UART1.
 
-	config DEBUG_TEGRA_UART
+	config TEGRA_DEBUG_UART_AUTO_ODMDATA
+		bool "Kernel low-level debugging messages via Tegra UART via ODMDATA"
 		depends on ARCH_TEGRA
-		bool "Use Tegra UART for low-level debug"
+		select DEBUG_TEGRA_UART
+		help
+		  Automatically determines which UART to use for low-level
+		  debug based on the ODMDATA value. This value is part of
+		  the BCT, and is written to the boot memory device using
+		  nvflash, or other flashing tool.  When bits 19:18 are 3,
+		  then bits 17:15 indicate which UART to use; 0/1/2/3/4
+		  are UART A/B/C/D/E.
+
+	config TEGRA_DEBUG_UARTA
+		bool "Kernel low-level debugging messages via Tegra UART A"
+		depends on ARCH_TEGRA
+		select DEBUG_TEGRA_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Tegra based platforms.
+
+	config TEGRA_DEBUG_UARTB
+		bool "Kernel low-level debugging messages via Tegra UART B"
+		depends on ARCH_TEGRA
+		select DEBUG_TEGRA_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Tegra based platforms.
+
+	config TEGRA_DEBUG_UARTC
+		bool "Kernel low-level debugging messages via Tegra UART C"
+		depends on ARCH_TEGRA
+		select DEBUG_TEGRA_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Tegra based platforms.
+
+	config TEGRA_DEBUG_UARTD
+		bool "Kernel low-level debugging messages via Tegra UART D"
+		depends on ARCH_TEGRA
+		select DEBUG_TEGRA_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Tegra based platforms.
+
+	config TEGRA_DEBUG_UARTE
+		bool "Kernel low-level debugging messages via Tegra UART E"
+		depends on ARCH_TEGRA
+		select DEBUG_TEGRA_UART
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Tegra based platforms.
@@ -564,13 +718,25 @@ choice
 		  This option selects UART0 on VIA/Wondermedia System-on-a-chip
 		  devices, including VT8500, WM8505, WM8650 and WM8850.
 
-	config DEBUG_STI_UART
+	config STIH41X_DEBUG_ASC2
+		bool "Use StiH415/416 ASC2 UART for low-level debug"
+		depends on ARCH_STI
+		select DEBUG_STI_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on STiH415/416 based platforms like b2000, which has
+		  default UART wired up to ASC2.
+
+		  If unsure, say N.
+
+	config STIH41X_DEBUG_SBC_ASC1
+		bool "Use StiH415/416 SBC ASC1 UART for low-level debug"
 		depends on ARCH_STI
-		bool "Use StiH415/416 ASC for low-level debug"
+		select DEBUG_STI_UART
 		help
 		  Say Y here if you want kernel low-level debugging support
-		  on StiH415/416 based platforms like B2000, B2020.
-		  It support UART2 and SBC_UART1.
+		  on STiH415/416 based platforms like b2020. which has
+		  default UART wired up to SBC ASC1.
 
 		  If unsure, say N.
 
@@ -615,6 +781,10 @@ endchoice
 config DEBUG_EXYNOS_UART
 	bool
 
+config DEBUG_OMAP2PLUS_UART
+	bool
+	depends on ARCH_OMAP2PLUS
+
 config DEBUG_IMX_UART_PORT
 	int "i.MX Debug UART Port Selection" if DEBUG_IMX1_UART || \
 						DEBUG_IMX25_UART || \
@@ -631,133 +801,17 @@ config DEBUG_IMX_UART_PORT
 	  Choose UART port on which kernel low-level debug messages
 	  should be output.
 
-choice
-	prompt "Low-level debug console UART"
-	depends on DEBUG_OMAP2PLUS_UART
-
-	config DEBUG_OMAP2UART1
-		bool "OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards)"
-		help
-		  This covers at least h4, 2430sdp, 3430sdp, 3630sdp,
-		  omap3 torpedo and 3530 lv som.
-
-	config DEBUG_OMAP2UART2
-		bool "OMAP2/3/4 UART2"
-
-	config DEBUG_OMAP2UART3
-		bool "OMAP2 UART3 (n8x0)"
-
-	config DEBUG_OMAP3UART3
-		bool "OMAP3 UART3 (most omap3 boards)"
-		help
-		  This covers at least cm_t3x, beagle, crane, devkit8000,
-		  igep00x0, ldp, n900, n9(50), pandora, overo, touchbook,
-		  and 3517evm.
-
-	config DEBUG_OMAP4UART3
-		bool "OMAP4/5 UART3 (omap4 blaze, panda, omap5 sevm)"
-
-	config DEBUG_OMAP3UART4
-		bool "OMAP36XX UART4"
-
-	config DEBUG_OMAP4UART4
-		bool "OMAP4/5 UART4"
-
-	config DEBUG_TI81XXUART1
-		bool "TI81XX UART1 (ti8148evm)"
-
-	config DEBUG_TI81XXUART2
-		bool "TI81XX UART2"
-
-	config DEBUG_TI81XXUART3
-		bool "TI81XX UART3 (ti8168evm)"
-
-	config DEBUG_AM33XXUART1
-		bool "AM33XX UART1"
-
-	config DEBUG_ZOOM_UART
-		bool "Zoom2/3 UART"
-endchoice
-
-choice
-	prompt "Low-level debug console UART"
-	depends on DEBUG_ROCKCHIP_UART
-
-	config DEBUG_RK29_UART0
-		bool "RK29 UART0"
-
-	config DEBUG_RK29_UART1
-		bool "RK29 UART1"
-
-	config DEBUG_RK29_UART2
-		bool "RK29 UART2"
-
-	config DEBUG_RK3X_UART0
-		bool "RK3X UART0"
-
-	config DEBUG_RK3X_UART1
-		bool "RK3X UART1"
-
-	config DEBUG_RK3X_UART2
-		bool "RK3X UART2"
-
-	config DEBUG_RK3X_UART3
-		bool "RK3X UART3"
-endchoice
-
-choice
-	prompt "Low-level debug console UART"
-	depends on DEBUG_LL && DEBUG_TEGRA_UART
-
-	config TEGRA_DEBUG_UART_AUTO_ODMDATA
-	bool "Via ODMDATA"
-	help
-	  Automatically determines which UART to use for low-level debug based
-	  on the ODMDATA value. This value is part of the BCT, and is written
-	  to the boot memory device using nvflash, or other flashing tool.
-	  When bits 19:18 are 3, then bits 17:15 indicate which UART to use;
-	  0/1/2/3/4 are UART A/B/C/D/E.
-
-	config TEGRA_DEBUG_UARTA
-		bool "UART A"
-
-	config TEGRA_DEBUG_UARTB
-		bool "UART B"
-
-	config TEGRA_DEBUG_UARTC
-		bool "UART C"
-
-	config TEGRA_DEBUG_UARTD
-		bool "UART D"
-
-	config TEGRA_DEBUG_UARTE
-		bool "UART E"
-
-endchoice
-
-choice
-	prompt "Low-level debug console UART"
-	depends on DEBUG_LL && DEBUG_STI_UART
-
-	config STIH41X_DEBUG_ASC2
-		bool "ASC2 UART"
-		help
-		  Say Y here if you want kernel low-level debugging support
-		  on STiH415/416 based platforms like b2000, which has
-		  default UART wired up to ASC2.
-
-		  If unsure, say N.
-
-	config STIH41X_DEBUG_SBC_ASC1
-		bool "SBC ASC1 UART"
-		help
-		  Say Y here if you want kernel low-level debugging support
-		  on STiH415/416 based platforms like b2020. which has
-		  default UART wired up to SBC ASC1.
+config DEBUG_ROCKCHIP_UART
+	bool
+	depends on ARCH_ROCKCHIP
 
-		  If unsure, say N.
+config DEBUG_TEGRA_UART
+	bool
+	depends on ARCH_TEGRA
 
-endchoice
+config DEBUG_STI_UART
+	bool
+	depends on ARCH_STI
 
 config DEBUG_LL_INCLUDE
 	string
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Sun Jul  7 08:47:30 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Sun, 07 Jul 2013 13:47:30 +0100
Subject: [PATCH RFC 4/9] ARM: debug: provide 8250 debug uart register shift
 configuration option
In-Reply-To: <20130707124326.GP24642@n2100.arm.linux.org.uk>
References: <20130707124326.GP24642@n2100.arm.linux.org.uk>
Message-ID: <E1UvoNG-0006Ho-N9@rmk-PC.arm.linux.org.uk>

Move the definition of the UART register shift out of the platform
specific header file into the Kconfig files.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug                             |   18 ++++++++++++++++--
 arch/arm/include/asm/hardware/debug-8250.S         |    4 ++++
 arch/arm/include/debug/mvebu.S                     |    1 -
 arch/arm/include/debug/nspire.S                    |    1 -
 arch/arm/include/debug/pxa.S                       |    1 -
 arch/arm/include/debug/rockchip.S                  |    1 -
 arch/arm/include/debug/sunxi.S                     |    1 -
 arch/arm/mach-dove/include/mach/debug-macro.S      |    1 -
 arch/arm/mach-ebsa110/include/mach/debug-macro.S   |    1 -
 .../arm/mach-footbridge/include/mach/debug-macro.S |    1 -
 arch/arm/mach-gemini/include/mach/debug-macro.S    |    1 -
 arch/arm/mach-iop13xx/include/mach/debug-macro.S   |    1 -
 arch/arm/mach-iop32x/include/mach/debug-macro.S    |    1 -
 arch/arm/mach-iop33x/include/mach/debug-macro.S    |    1 -
 arch/arm/mach-ixp4xx/include/mach/debug-macro.S    |    1 -
 arch/arm/mach-kirkwood/include/mach/debug-macro.S  |    1 -
 arch/arm/mach-lpc32xx/include/mach/debug-macro.S   |    1 -
 arch/arm/mach-mv78xx0/include/mach/debug-macro.S   |    1 -
 arch/arm/mach-orion5x/include/mach/debug-macro.S   |    1 -
 arch/arm/mach-rpc/include/mach/debug-macro.S       |    1 -
 20 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 434a22c..bfc310b 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -858,8 +858,22 @@ config DEBUG_LL_INCLUDE
 
 config DEBUG_UART_8250
 	def_bool y
-	depends on ARCH_EBSA110 || (FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
-		ARCH_GEMINI || ARCH_RPC
+	depends on DEBUG_MVEBU_UART || DEBUG_MVEBU_UART_ALTERNATE || \
+		DEBUG_NSPIRE_CLASSIC_UART || \
+		DEBUG_PXA_UART1 || DEBUG_MMP_UART2 || DEBUG_MMP_UART3 || \
+		DEBUG_ROCKCHIP_UART || \
+		DEBUG_SUNXI_UART0 || DEBUG_SUNXI_UART1 || \
+		ARCH_DOVE || ARCH_EBSA110 || \
+		(FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
+		ARCH_GEMINI || ARCH_IOP13XX || ARCH_IOP32X || \
+		ARCH_IOP33X || ARCH_IXP4XX || ARCH_KIRKWOOD || \
+		ARCH_LPC32XX || ARCH_MV78XX0 || ARCH_ORION5X || ARCH_RPC
+
+config DEBUG_UART_8250_SHIFT
+	int "Register offset shift for the 8250 debug UART"
+	depends on DEBUG_UART_8250
+	default 0 if FOOTBRIDGE || ARCH_IOP32X
+	default 2
 
 config DEBUG_UART_8250_FLOW_CONTROL
 	def_bool y if ARCH_EBSA110 || FOOTBRIDGE || ARCH_GEMINI || ARCH_RPC
diff --git a/arch/arm/include/asm/hardware/debug-8250.S b/arch/arm/include/asm/hardware/debug-8250.S
index bca3045..a0e6e17 100644
--- a/arch/arm/include/asm/hardware/debug-8250.S
+++ b/arch/arm/include/asm/hardware/debug-8250.S
@@ -9,6 +9,10 @@
  */
 #include <linux/serial_reg.h>
 
+#ifndef UART_SHIFT
+#define UART_SHIFT CONFIG_DEBUG_UART_8250_SHIFT
+#endif
+
 		.macro	senduart,rd,rx
 		strb	\rd, [\rx, #UART_TX << UART_SHIFT]
 		.endm
diff --git a/arch/arm/include/debug/mvebu.S b/arch/arm/include/debug/mvebu.S
index 6517311..0d0d820 100644
--- a/arch/arm/include/debug/mvebu.S
+++ b/arch/arm/include/debug/mvebu.S
@@ -26,5 +26,4 @@
 	orr	\rv, \rv, #0x00012000
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/nspire.S b/arch/arm/include/debug/nspire.S
index 886fd27..8874636 100644
--- a/arch/arm/include/debug/nspire.S
+++ b/arch/arm/include/debug/nspire.S
@@ -23,6 +23,5 @@
 #endif
 
 #ifdef CONFIG_DEBUG_NSPIRE_CLASSIC_UART
-#define UART_SHIFT 2
 #include <asm/hardware/debug-8250.S>
 #endif
diff --git a/arch/arm/include/debug/pxa.S b/arch/arm/include/debug/pxa.S
index e1e795a..f10fba50 100644
--- a/arch/arm/include/debug/pxa.S
+++ b/arch/arm/include/debug/pxa.S
@@ -29,5 +29,4 @@
 	ldr	\rv, =PXA_UART_REG_VIRT_BASE
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/rockchip.S b/arch/arm/include/debug/rockchip.S
index cfd883e..80ae8ca 100644
--- a/arch/arm/include/debug/rockchip.S
+++ b/arch/arm/include/debug/rockchip.S
@@ -38,5 +38,4 @@
 	ldr	\rv, =ROCKCHIP_UART_DEBUG_VIRT_BASE
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/sunxi.S b/arch/arm/include/debug/sunxi.S
index 04eb56d..65d0981 100644
--- a/arch/arm/include/debug/sunxi.S
+++ b/arch/arm/include/debug/sunxi.S
@@ -23,5 +23,4 @@
 	ldr	\rv, =SUNXI_UART_DEBUG_VIRT_BASE
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-dove/include/mach/debug-macro.S b/arch/arm/mach-dove/include/mach/debug-macro.S
index 5929cbc..182a610 100644
--- a/arch/arm/mach-dove/include/mach/debug-macro.S
+++ b/arch/arm/mach-dove/include/mach/debug-macro.S
@@ -15,5 +15,4 @@
 	orr	\rv, \rv, #0x00012000
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-ebsa110/include/mach/debug-macro.S b/arch/arm/mach-ebsa110/include/mach/debug-macro.S
index 9b66e79..984f0fa 100644
--- a/arch/arm/mach-ebsa110/include/mach/debug-macro.S
+++ b/arch/arm/mach-ebsa110/include/mach/debug-macro.S
@@ -17,5 +17,4 @@
 		mov	\rp, \rv
 		.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-footbridge/include/mach/debug-macro.S b/arch/arm/mach-footbridge/include/mach/debug-macro.S
index 18130fe..a209936 100644
--- a/arch/arm/mach-footbridge/include/mach/debug-macro.S
+++ b/arch/arm/mach-footbridge/include/mach/debug-macro.S
@@ -22,7 +22,6 @@
 		orr	\rp, \rp, #0x7c000000	@ physical
 		.endm
 
-#define UART_SHIFT	0
 #include <asm/hardware/debug-8250.S>
 
 #else
diff --git a/arch/arm/mach-gemini/include/mach/debug-macro.S b/arch/arm/mach-gemini/include/mach/debug-macro.S
index cdee448..2d94ea4 100644
--- a/arch/arm/mach-gemini/include/mach/debug-macro.S
+++ b/arch/arm/mach-gemini/include/mach/debug-macro.S
@@ -16,5 +16,4 @@
 	ldr	\rv, =IO_ADDRESS(GEMINI_UART_BASE)	@ virtual
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop13xx/include/mach/debug-macro.S b/arch/arm/mach-iop13xx/include/mach/debug-macro.S
index d869a6f..4a776ca 100644
--- a/arch/arm/mach-iop13xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-iop13xx/include/mach/debug-macro.S
@@ -20,5 +20,4 @@
 	orr	\rp, \rp, #0x00d80000
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop32x/include/mach/debug-macro.S b/arch/arm/mach-iop32x/include/mach/debug-macro.S
index 363bdf9..a090573 100644
--- a/arch/arm/mach-iop32x/include/mach/debug-macro.S
+++ b/arch/arm/mach-iop32x/include/mach/debug-macro.S
@@ -17,5 +17,4 @@
 		mov	\rv, \rp
 		.endm
 
-#define UART_SHIFT	0
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop33x/include/mach/debug-macro.S b/arch/arm/mach-iop33x/include/mach/debug-macro.S
index 361be1f..894bf7c 100644
--- a/arch/arm/mach-iop33x/include/mach/debug-macro.S
+++ b/arch/arm/mach-iop33x/include/mach/debug-macro.S
@@ -18,5 +18,4 @@
 		orr	\rp, #0xff000000	@ physical
 		.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-ixp4xx/include/mach/debug-macro.S b/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
index ff686cb..403bd35 100644
--- a/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
@@ -22,5 +22,4 @@
                 orr     \rp, \rp, #0xc8000000	@ physical
                 .endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-kirkwood/include/mach/debug-macro.S b/arch/arm/mach-kirkwood/include/mach/debug-macro.S
index f785d40..51eee02 100644
--- a/arch/arm/mach-kirkwood/include/mach/debug-macro.S
+++ b/arch/arm/mach-kirkwood/include/mach/debug-macro.S
@@ -15,5 +15,4 @@
 	orr	\rv, \rv, #0x00012000
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-lpc32xx/include/mach/debug-macro.S b/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
index 351bd6c..11f986e 100644
--- a/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
@@ -25,5 +25,4 @@
 	ldrne	\rv, =0xF4090000
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S b/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
index a7df02b..0fce467 100644
--- a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
+++ b/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
@@ -15,5 +15,4 @@
 	orr	\rv, \rv, #0x00012000
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-orion5x/include/mach/debug-macro.S b/arch/arm/mach-orion5x/include/mach/debug-macro.S
index f340ed8..52f29ef 100644
--- a/arch/arm/mach-orion5x/include/mach/debug-macro.S
+++ b/arch/arm/mach-orion5x/include/mach/debug-macro.S
@@ -17,5 +17,4 @@
 	orr	\rv, \rv, #0x00012000
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-rpc/include/mach/debug-macro.S b/arch/arm/mach-rpc/include/mach/debug-macro.S
index a92753d..fcb5450 100644
--- a/arch/arm/mach-rpc/include/mach/debug-macro.S
+++ b/arch/arm/mach-rpc/include/mach/debug-macro.S
@@ -18,5 +18,4 @@
 		orr	\rp, \rp, #0x03000000	@ physical
 		.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Sun Jul  7 08:48:31 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Sun, 07 Jul 2013 13:48:31 +0100
Subject: [PATCH RFC 5/9] ARM: debug: provide 8250 debug uart phys/virt
 address configuration options
In-Reply-To: <20130707124326.GP24642@n2100.arm.linux.org.uk>
References: <20130707124326.GP24642@n2100.arm.linux.org.uk>
Message-ID: <E1UvoOF-0006Ht-5f@rmk-PC.arm.linux.org.uk>

Move the definition of the UART register addresses out of the platform
specific header file into the Kconfig files.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug                             |   59 ++++++++++++++++++++
 arch/arm/include/asm/hardware/debug-8250.S         |    7 ++
 arch/arm/include/debug/mvebu.S                     |   16 -----
 arch/arm/include/debug/nspire.S                    |    4 +-
 arch/arm/include/debug/pxa.S                       |   19 ------
 arch/arm/include/debug/rockchip.S                  |   29 ----------
 arch/arm/include/debug/sunxi.S                     |   14 -----
 arch/arm/mach-dove/include/mach/debug-macro.S      |   10 ---
 arch/arm/mach-ebsa110/include/mach/debug-macro.S   |    7 --
 .../arm/mach-footbridge/include/mach/debug-macro.S |    9 ---
 arch/arm/mach-gemini/include/mach/debug-macro.S    |    7 --
 arch/arm/mach-iop13xx/include/mach/debug-macro.S   |   10 ---
 arch/arm/mach-iop32x/include/mach/debug-macro.S    |    7 --
 arch/arm/mach-iop33x/include/mach/debug-macro.S    |    8 ---
 arch/arm/mach-ixp4xx/include/mach/debug-macro.S    |   13 ----
 arch/arm/mach-kirkwood/include/mach/debug-macro.S  |   10 ---
 arch/arm/mach-lpc32xx/include/mach/debug-macro.S   |   10 ---
 arch/arm/mach-mv78xx0/include/mach/debug-macro.S   |   10 ---
 arch/arm/mach-orion5x/include/mach/debug-macro.S   |   10 ---
 arch/arm/mach-rpc/include/mach/debug-macro.S       |    8 ---
 20 files changed, 67 insertions(+), 200 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index bfc310b..82ce0ba 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -869,6 +869,65 @@ config DEBUG_UART_8250
 		ARCH_IOP33X || ARCH_IXP4XX || ARCH_KIRKWOOD || \
 		ARCH_LPC32XX || ARCH_MV78XX0 || ARCH_ORION5X || ARCH_RPC
 
+config DEBUG_UART_PHYS
+	hex "Physical base address of debug UART"
+	default 0x01c28000 if DEBUG_SUNXI_UART0
+	default 0x01c28400 if DEBUG_SUNXI_UART1
+	default 0x03010fe0 if ARCH_RPC
+	default 0x10124000 if DEBUG_RK3X_UART0
+	default 0x10126000 if DEBUG_RK3X_UART1
+	default 0x20060000 if DEBUG_RK29_UART0
+	default 0x20064000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
+	default 0x20068000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
+	default 0x40090000 if ARCH_LPC32XX
+	default 0x40100000 if DEBUG_PXA_UART1
+	default 0x42000000 if ARCH_GEMINI
+	default 0x7c0003f8 if FOOTBRIDGE
+	default 0x90020000 if DEBUG_NSPIRE_CLASSIC_UART
+	default 0xc8000000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
+	default 0xc8000003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
+	default 0xd0012000 if DEBUG_MVEBU_UART
+	default 0xd4017000 if DEBUG_MMP_UART2
+	default 0xd4018000 if DEBUG_MMP_UART3
+	default 0xf0000be0 if ARCH_EBSA110
+	default 0xf1012000 if DEBUG_MVEBU_UART_ALTERNATE
+	default 0xf1012000 if ARCH_DOVE || ARCH_KIRKWOOD || ARCH_MV78XX0 || \
+				ARCH_ORION5X
+	default 0xfe800000 if ARCH_IOP32X
+	default 0xffd82340 if ARCH_IOP13XX
+	default 0xfffff700 if ARCH_IOP33X
+	depends on DEBUG_UART_8250
+
+config DEBUG_UART_VIRT
+	hex "Virtual base address of debug UART"
+	default 0xe0010fe0 if ARCH_RPC
+	default 0xf0000be0 if ARCH_EBSA110
+	default 0xf1c28000 if DEBUG_SUNXI_UART0
+	default 0xf1c28400 if DEBUG_SUNXI_UART1
+	default 0xf2100000 if DEBUG_PXA_UART1
+	default 0xf4090000 if ARCH_LPC32XX
+	default 0xf4200000 if ARCH_GEMINI
+	default 0xfd012000 if ARCH_MV78XX0
+	default 0xfde12000 if ARCH_DOVE
+	default 0xfe012000 if ARCH_ORION5X
+	default 0xfe017000 if DEBUG_MMP_UART2
+	default 0xfe018000 if DEBUG_MMP_UART3
+	default 0xfe800000 if ARCH_IOP32X
+	default 0xfeb24000 if DEBUG_RK3X_UART0
+	default 0xfeb26000 if DEBUG_RK3X_UART1
+	default 0xfec12000 if DEBUG_MVEBU_UART || DEBUG_MVEBU_UART_ALTERNATE
+	default 0xfed60000 if DEBUG_RK29_UART0
+	default 0xfed64000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
+	default 0xfed68000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
+	default 0xfed12000 if ARCH_KIRKWOOD
+	default 0xfee003f8 if FOOTBRIDGE
+	default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART
+	default 0xfee82340 if ARCH_IOP13XX
+	default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
+	default 0xfef00003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
+	default 0xfefff700 if ARCH_IOP33X
+	depends on DEBUG_UART_8250
+
 config DEBUG_UART_8250_SHIFT
 	int "Register offset shift for the 8250 debug UART"
 	depends on DEBUG_UART_8250
diff --git a/arch/arm/include/asm/hardware/debug-8250.S b/arch/arm/include/asm/hardware/debug-8250.S
index a0e6e17..4c62f2d 100644
--- a/arch/arm/include/asm/hardware/debug-8250.S
+++ b/arch/arm/include/asm/hardware/debug-8250.S
@@ -9,6 +9,13 @@
  */
 #include <linux/serial_reg.h>
 
+#ifdef CONFIG_DEBUG_UART_PHYS
+		.macro	addruart, rp, rv, tmp
+		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
+		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
+		.endm
+#endif
+
 #ifndef UART_SHIFT
 #define UART_SHIFT CONFIG_DEBUG_UART_8250_SHIFT
 #endif
diff --git a/arch/arm/include/debug/mvebu.S b/arch/arm/include/debug/mvebu.S
index 0d0d820..6309be5 100644
--- a/arch/arm/include/debug/mvebu.S
+++ b/arch/arm/include/debug/mvebu.S
@@ -10,20 +10,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#ifdef CONFIG_DEBUG_MVEBU_UART_ALTERNATE
-#define ARMADA_370_XP_REGS_PHYS_BASE	0xf1000000
-#else
-#define ARMADA_370_XP_REGS_PHYS_BASE	0xd0000000
-#endif
-
-#define ARMADA_370_XP_REGS_VIRT_BASE	0xfec00000
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =ARMADA_370_XP_REGS_PHYS_BASE
-	ldr	\rv, =ARMADA_370_XP_REGS_VIRT_BASE
-	orr	\rp, \rp, #0x00012000
-	orr	\rv, \rv, #0x00012000
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/nspire.S b/arch/arm/include/debug/nspire.S
index 8874636..3e9329a 100644
--- a/arch/arm/include/debug/nspire.S
+++ b/arch/arm/include/debug/nspire.S
@@ -8,7 +8,7 @@
  * published by the Free Software Foundation.
  *
  */
-
+#ifdef CONFIG_DEBUG_NSPIRE_CX_UART
 #define NSPIRE_EARLY_UART_PHYS_BASE	   0x90020000
 #define NSPIRE_EARLY_UART_VIRT_BASE	   0xfee20000
 
@@ -17,8 +17,6 @@
 	ldr \rv, =(NSPIRE_EARLY_UART_VIRT_BASE)		@ virtual base address
 .endm
 
-
-#ifdef CONFIG_DEBUG_NSPIRE_CX_UART
 #include <asm/hardware/debug-pl01x.S>
 #endif
 
diff --git a/arch/arm/include/debug/pxa.S b/arch/arm/include/debug/pxa.S
index f10fba50..09e54f3 100644
--- a/arch/arm/include/debug/pxa.S
+++ b/arch/arm/include/debug/pxa.S
@@ -10,23 +10,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#if defined(CONFIG_DEBUG_PXA_UART1)
-#define PXA_UART_REG_PHYS_BASE	0x40100000
-#define PXA_UART_REG_VIRT_BASE	0xf2100000
-#elif defined(CONFIG_DEBUG_MMP_UART2)
-#define PXA_UART_REG_PHYS_BASE	0xd4017000
-#define PXA_UART_REG_VIRT_BASE	0xfe017000
-#elif defined(CONFIG_DEBUG_MMP_UART3)
-#define PXA_UART_REG_PHYS_BASE	0xd4018000
-#define PXA_UART_REG_VIRT_BASE	0xfe018000
-#else
-#error "Select uart for DEBUG_LL"
-#endif
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =PXA_UART_REG_PHYS_BASE
-	ldr	\rv, =PXA_UART_REG_VIRT_BASE
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/rockchip.S b/arch/arm/include/debug/rockchip.S
index 80ae8ca..3ad0238 100644
--- a/arch/arm/include/debug/rockchip.S
+++ b/arch/arm/include/debug/rockchip.S
@@ -9,33 +9,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#if defined(CONFIG_DEBUG_RK29_UART0)
-#define ROCKCHIP_UART_DEBUG_PHYS_BASE 0x20060000
-#define ROCKCHIP_UART_DEBUG_VIRT_BASE 0xfed60000
-#elif defined(CONFIG_DEBUG_RK29_UART1)
-#define ROCKCHIP_UART_DEBUG_PHYS_BASE 0x20064000
-#define ROCKCHIP_UART_DEBUG_VIRT_BASE 0xfed64000
-#elif defined(CONFIG_DEBUG_RK29_UART2)
-#define ROCKCHIP_UART_DEBUG_PHYS_BASE 0x20068000
-#define ROCKCHIP_UART_DEBUG_VIRT_BASE 0xfed68000
-#elif defined(CONFIG_DEBUG_RK3X_UART0)
-#define ROCKCHIP_UART_DEBUG_PHYS_BASE 0x10124000
-#define ROCKCHIP_UART_DEBUG_VIRT_BASE 0xfeb24000
-#elif defined(CONFIG_DEBUG_RK3X_UART1)
-#define ROCKCHIP_UART_DEBUG_PHYS_BASE 0x10126000
-#define ROCKCHIP_UART_DEBUG_VIRT_BASE 0xfeb26000
-#elif defined(CONFIG_DEBUG_RK3X_UART2)
-#define ROCKCHIP_UART_DEBUG_PHYS_BASE 0x20064000
-#define ROCKCHIP_UART_DEBUG_VIRT_BASE 0xfed64000
-#elif defined(CONFIG_DEBUG_RK3X_UART3)
-#define ROCKCHIP_UART_DEBUG_PHYS_BASE 0x20068000
-#define ROCKCHIP_UART_DEBUG_VIRT_BASE 0xfed68000
-#endif
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =ROCKCHIP_UART_DEBUG_PHYS_BASE
-	ldr	\rv, =ROCKCHIP_UART_DEBUG_VIRT_BASE
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/sunxi.S b/arch/arm/include/debug/sunxi.S
index 65d0981..4c3d89c 100644
--- a/arch/arm/include/debug/sunxi.S
+++ b/arch/arm/include/debug/sunxi.S
@@ -9,18 +9,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#if defined(CONFIG_DEBUG_SUNXI_UART0)
-#define SUNXI_UART_DEBUG_PHYS_BASE 0x01c28000
-#define SUNXI_UART_DEBUG_VIRT_BASE 0xf1c28000
-#elif defined(CONFIG_DEBUG_SUNXI_UART1)
-#define SUNXI_UART_DEBUG_PHYS_BASE 0x01c28400
-#define SUNXI_UART_DEBUG_VIRT_BASE 0xf1c28400
-#endif
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =SUNXI_UART_DEBUG_PHYS_BASE
-	ldr	\rv, =SUNXI_UART_DEBUG_VIRT_BASE
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-dove/include/mach/debug-macro.S b/arch/arm/mach-dove/include/mach/debug-macro.S
index 182a610..9b85a81 100644
--- a/arch/arm/mach-dove/include/mach/debug-macro.S
+++ b/arch/arm/mach-dove/include/mach/debug-macro.S
@@ -5,14 +5,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#include <mach/bridge-regs.h>
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =DOVE_SB_REGS_PHYS_BASE
-	ldr	\rv, =DOVE_SB_REGS_VIRT_BASE
-	orr	\rp, \rp, #0x00012000
-	orr	\rv, \rv, #0x00012000
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-ebsa110/include/mach/debug-macro.S b/arch/arm/mach-ebsa110/include/mach/debug-macro.S
index 984f0fa..0cea548 100644
--- a/arch/arm/mach-ebsa110/include/mach/debug-macro.S
+++ b/arch/arm/mach-ebsa110/include/mach/debug-macro.S
@@ -10,11 +10,4 @@
  * published by the Free Software Foundation.
  *
 **/
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0xf0000000
-		orr	\rp, \rp, #0x00000be0
-		mov	\rp, \rv
-		.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-footbridge/include/mach/debug-macro.S b/arch/arm/mach-footbridge/include/mach/debug-macro.S
index a209936..553c47d 100644
--- a/arch/arm/mach-footbridge/include/mach/debug-macro.S
+++ b/arch/arm/mach-footbridge/include/mach/debug-macro.S
@@ -14,16 +14,7 @@
 #include <asm/hardware/dec21285.h>
 
 #ifndef CONFIG_DEBUG_DC21285_PORT
-	/* For NetWinder debugging */
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0x000003f8
-		orr	\rv, \rp, #0xfe000000	@ virtual
-		orr	\rv, \rv, #0x00e00000	@ virtual
-		orr	\rp, \rp, #0x7c000000	@ physical
-		.endm
-
 #include <asm/hardware/debug-8250.S>
-
 #else
 #include <mach/hardware.h>
 	/* For EBSA285 debugging */
diff --git a/arch/arm/mach-gemini/include/mach/debug-macro.S b/arch/arm/mach-gemini/include/mach/debug-macro.S
index 2d94ea4..9dabd4b 100644
--- a/arch/arm/mach-gemini/include/mach/debug-macro.S
+++ b/arch/arm/mach-gemini/include/mach/debug-macro.S
@@ -9,11 +9,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-#include <mach/hardware.h>
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =GEMINI_UART_BASE			@ physical
-	ldr	\rv, =IO_ADDRESS(GEMINI_UART_BASE)	@ virtual
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop13xx/include/mach/debug-macro.S b/arch/arm/mach-iop13xx/include/mach/debug-macro.S
index 4a776ca..90b5e64 100644
--- a/arch/arm/mach-iop13xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-iop13xx/include/mach/debug-macro.S
@@ -10,14 +10,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-
-	.macro	addruart, rp, rv, tmp
-	mov	\rp, #0x00002300
-	orr	\rp, \rp, #0x00000040
-	orr	\rv, \rp, #0xfe000000	@ virtual
-	orr	\rv, \rv, #0x00e80000
-	orr	\rp, \rp, #0xff000000	@ physical
-	orr	\rp, \rp, #0x00d80000
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop32x/include/mach/debug-macro.S b/arch/arm/mach-iop32x/include/mach/debug-macro.S
index a090573..7ea745e 100644
--- a/arch/arm/mach-iop32x/include/mach/debug-macro.S
+++ b/arch/arm/mach-iop32x/include/mach/debug-macro.S
@@ -10,11 +10,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0xfe000000	@ physical as well as virtual
-		orr	\rp, \rp, #0x00800000	@ location of the UART
-		mov	\rv, \rp
-		.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop33x/include/mach/debug-macro.S b/arch/arm/mach-iop33x/include/mach/debug-macro.S
index 894bf7c..52781ae 100644
--- a/arch/arm/mach-iop33x/include/mach/debug-macro.S
+++ b/arch/arm/mach-iop33x/include/mach/debug-macro.S
@@ -10,12 +10,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0x00ff0000
-		orr	\rp, \rp, #0x0000f700
-		orr	\rv, #0xfe000000	@ virtual
-		orr	\rp, #0xff000000	@ physical
-		.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-ixp4xx/include/mach/debug-macro.S b/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
index 403bd35..ff706fa 100644
--- a/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
@@ -9,17 +9,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-                .macro  addruart, rp, rv, tmp
-#ifdef __ARMEB__
-                mov     \rp, #3         @ Uart regs are at off set of 3 if
-					@ byte writes used - Big Endian.
-#else
-		mov	\rp, #0
-#endif
-		orr	\rv, \rp, #0xfe000000	@ virtual
-		orr	\rv, \rv, #0x00f00000
-                orr     \rp, \rp, #0xc8000000	@ physical
-                .endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-kirkwood/include/mach/debug-macro.S b/arch/arm/mach-kirkwood/include/mach/debug-macro.S
index 51eee02..011ec25 100644
--- a/arch/arm/mach-kirkwood/include/mach/debug-macro.S
+++ b/arch/arm/mach-kirkwood/include/mach/debug-macro.S
@@ -5,14 +5,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#include <mach/bridge-regs.h>
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =KIRKWOOD_REGS_PHYS_BASE
-	ldr	\rv, =KIRKWOOD_REGS_VIRT_BASE
-	orr	\rp, \rp, #0x00012000
-	orr	\rv, \rv, #0x00012000
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-lpc32xx/include/mach/debug-macro.S b/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
index 11f986e..c7bb4bc 100644
--- a/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
@@ -15,14 +15,4 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  */
-
-/*
- * Debug output is hardcoded to standard UART 5
-*/
-
-	.macro	addruart, rp, rv, tmp
-	ldreq	\rp, =0x40090000
-	ldrne	\rv, =0xF4090000
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S b/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
index 0fce467..c8284a2 100644
--- a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
+++ b/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
@@ -5,14 +5,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#include <mach/mv78xx0.h>
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =MV78XX0_REGS_PHYS_BASE
-	ldr	\rv, =MV78XX0_REGS_VIRT_BASE
-	orr	\rp, \rp, #0x00012000
-	orr	\rv, \rv, #0x00012000
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-orion5x/include/mach/debug-macro.S b/arch/arm/mach-orion5x/include/mach/debug-macro.S
index 52f29ef..7489963 100644
--- a/arch/arm/mach-orion5x/include/mach/debug-macro.S
+++ b/arch/arm/mach-orion5x/include/mach/debug-macro.S
@@ -7,14 +7,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#include <mach/orion5x.h>
-
-	.macro  addruart, rp, rv, tmp
-	ldr	\rp, =ORION5X_REGS_PHYS_BASE
-	ldr	\rv, =ORION5X_REGS_VIRT_BASE
-	orr	\rp, \rp, #0x00012000
-	orr	\rv, \rv, #0x00012000
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-rpc/include/mach/debug-macro.S b/arch/arm/mach-rpc/include/mach/debug-macro.S
index fcb5450..88a575e 100644
--- a/arch/arm/mach-rpc/include/mach/debug-macro.S
+++ b/arch/arm/mach-rpc/include/mach/debug-macro.S
@@ -10,12 +10,4 @@
  * published by the Free Software Foundation.
  *
 */
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0x00010000
-		orr	\rp, \rp, #0x00000fe0
-		orr	\rv, \rp, #0xe0000000	@ virtual
-		orr	\rp, \rp, #0x03000000	@ physical
-		.endm
-
 #include <asm/hardware/debug-8250.S>
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Sun Jul  7 08:49:31 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Sun, 07 Jul 2013 13:49:31 +0100
Subject: [PATCH RFC 6/9] ARM: debug: move 8250 debug include into
 arch/arm/include/debug/
In-Reply-To: <20130707124326.GP24642@n2100.arm.linux.org.uk>
References: <20130707124326.GP24642@n2100.arm.linux.org.uk>
Message-ID: <E1UvoPD-0006I1-Jc@rmk-PC.arm.linux.org.uk>

Now that the 8250 debug include can stand alone without requiring
platforms to provide any macros, move it into the debug directory
so it can be directly included.  This allows us to get rid of a lot
of debug-macros include files.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug                             |   10 +----
 arch/arm/include/asm/hardware/debug-8250.S         |   40 --------------------
 arch/arm/include/debug/8250.S                      |   36 ++++++++++++++++++
 arch/arm/include/debug/mvebu.S                     |   13 ------
 arch/arm/include/debug/nspire.S                    |    4 --
 arch/arm/include/debug/pxa.S                       |   13 ------
 arch/arm/include/debug/rockchip.S                  |   12 ------
 arch/arm/include/debug/sunxi.S                     |   12 ------
 arch/arm/mach-dove/include/mach/debug-macro.S      |    8 ----
 arch/arm/mach-ebsa110/include/mach/debug-macro.S   |   13 ------
 .../arm/mach-footbridge/include/mach/debug-macro.S |    4 --
 arch/arm/mach-gemini/include/mach/debug-macro.S    |   12 ------
 arch/arm/mach-iop13xx/include/mach/debug-macro.S   |   13 ------
 arch/arm/mach-iop32x/include/mach/debug-macro.S    |   13 ------
 arch/arm/mach-iop33x/include/mach/debug-macro.S    |   13 ------
 arch/arm/mach-ixp4xx/include/mach/debug-macro.S    |   12 ------
 arch/arm/mach-kirkwood/include/mach/debug-macro.S  |    8 ----
 arch/arm/mach-lpc32xx/include/mach/debug-macro.S   |   18 ---------
 arch/arm/mach-mv78xx0/include/mach/debug-macro.S   |    8 ----
 arch/arm/mach-orion5x/include/mach/debug-macro.S   |   10 -----
 arch/arm/mach-rpc/include/mach/debug-macro.S       |   13 ------
 21 files changed, 38 insertions(+), 247 deletions(-)
 delete mode 100644 arch/arm/include/asm/hardware/debug-8250.S
 create mode 100644 arch/arm/include/debug/8250.S
 delete mode 100644 arch/arm/include/debug/mvebu.S
 delete mode 100644 arch/arm/include/debug/pxa.S
 delete mode 100644 arch/arm/include/debug/rockchip.S
 delete mode 100644 arch/arm/include/debug/sunxi.S
 delete mode 100644 arch/arm/mach-dove/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ebsa110/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-gemini/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop13xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop32x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop33x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ixp4xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-lpc32xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-mv78xx0/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-orion5x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-rpc/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 82ce0ba..defd881 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -815,6 +815,7 @@ config DEBUG_STI_UART
 
 config DEBUG_LL_INCLUDE
 	string
+	default "debug/8250.S" if DEBUG_UART_8250
 	default "debug/bcm2835.S" if DEBUG_BCM2835
 	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
 	default "debug/exynos.S" if DEBUG_EXYNOS_UART
@@ -831,21 +832,14 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX6SL_UART
 	default "debug/keystone.S" if DEBUG_KEYSTONE_UART0 || \
 				      DEBUG_KEYSTONE_UART1
-	default "debug/mvebu.S" if DEBUG_MVEBU_UART || \
-				   DEBUG_MVEBU_UART_ALTERNATE
 	default "debug/mxs.S" if DEBUG_IMX23_UART || DEBUG_IMX28_UART
 	default "debug/nomadik.S" if DEBUG_NOMADIK_UART
-	default "debug/nspire.S" if 	DEBUG_NSPIRE_CX_UART || \
-					DEBUG_NSPIRE_CLASSIC_UART
+	default "debug/nspire.S" if DEBUG_NSPIRE_CX_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 	default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
-	default "debug/pxa.S" if DEBUG_PXA_UART1 || DEBUG_MMP_UART2 || \
-				 DEBUG_MMP_UART3
-	default "debug/rockchip.S" if DEBUG_ROCKCHIP_UART
 	default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
 	default "debug/socfpga.S" if DEBUG_SOCFPGA_UART
 	default "debug/sti.S" if DEBUG_STI_UART
-	default "debug/sunxi.S" if DEBUG_SUNXI_UART0 || DEBUG_SUNXI_UART1
 	default "debug/tegra.S" if DEBUG_TEGRA_UART
 	default "debug/u300.S" if DEBUG_U300_UART
 	default "debug/ux500.S" if DEBUG_UX500_UART
diff --git a/arch/arm/include/asm/hardware/debug-8250.S b/arch/arm/include/asm/hardware/debug-8250.S
deleted file mode 100644
index 4c62f2d..0000000
--- a/arch/arm/include/asm/hardware/debug-8250.S
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- * arch/arm/include/asm/hardware/debug-8250.S
- *
- *  Copyright (C) 1994-1999 Russell King
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <linux/serial_reg.h>
-
-#ifdef CONFIG_DEBUG_UART_PHYS
-		.macro	addruart, rp, rv, tmp
-		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
-		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
-		.endm
-#endif
-
-#ifndef UART_SHIFT
-#define UART_SHIFT CONFIG_DEBUG_UART_8250_SHIFT
-#endif
-
-		.macro	senduart,rd,rx
-		strb	\rd, [\rx, #UART_TX << UART_SHIFT]
-		.endm
-
-		.macro	busyuart,rd,rx
-1002:		ldrb	\rd, [\rx, #UART_LSR << UART_SHIFT]
-		and	\rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
-		teq	\rd, #UART_LSR_TEMT | UART_LSR_THRE
-		bne	1002b
-		.endm
-
-		.macro	waituart,rd,rx
-#ifdef CONFIG_DEBUG_UART_8250_FLOW_CONTROL
-1001:		ldrb	\rd, [\rx, #UART_MSR << UART_SHIFT]
-		tst	\rd, #UART_MSR_CTS
-		beq	1001b
-#endif
-		.endm
diff --git a/arch/arm/include/debug/8250.S b/arch/arm/include/debug/8250.S
new file mode 100644
index 0000000..4df055b
--- /dev/null
+++ b/arch/arm/include/debug/8250.S
@@ -0,0 +1,36 @@
+/*
+ * arch/arm/include/debug/8250.S
+ *
+ *  Copyright (C) 1994-1999 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/serial_reg.h>
+
+		.macro	addruart, rp, rv, tmp
+		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
+		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
+		.endm
+
+#define UART_SHIFT CONFIG_DEBUG_UART_8250_SHIFT
+
+		.macro	senduart,rd,rx
+		strb	\rd, [\rx, #UART_TX << UART_SHIFT]
+		.endm
+
+		.macro	busyuart,rd,rx
+1002:		ldrb	\rd, [\rx, #UART_LSR << UART_SHIFT]
+		and	\rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
+		teq	\rd, #UART_LSR_TEMT | UART_LSR_THRE
+		bne	1002b
+		.endm
+
+		.macro	waituart,rd,rx
+#ifdef CONFIG_DEBUG_UART_8250_FLOW_CONTROL
+1001:		ldrb	\rd, [\rx, #UART_MSR << UART_SHIFT]
+		tst	\rd, #UART_MSR_CTS
+		beq	1001b
+#endif
+		.endm
diff --git a/arch/arm/include/debug/mvebu.S b/arch/arm/include/debug/mvebu.S
deleted file mode 100644
index 6309be5..0000000
--- a/arch/arm/include/debug/mvebu.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/*
- * Early serial output macro for Marvell  SoC
- *
- * Copyright (C) 2012 Marvell
- *
- * Lior Amsalem <alior at marvell.com>
- * Gregory Clement <gregory.clement at free-electrons.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/nspire.S b/arch/arm/include/debug/nspire.S
index 3e9329a..9c2fbec 100644
--- a/arch/arm/include/debug/nspire.S
+++ b/arch/arm/include/debug/nspire.S
@@ -19,7 +19,3 @@
 
 #include <asm/hardware/debug-pl01x.S>
 #endif
-
-#ifdef CONFIG_DEBUG_NSPIRE_CLASSIC_UART
-#include <asm/hardware/debug-8250.S>
-#endif
diff --git a/arch/arm/include/debug/pxa.S b/arch/arm/include/debug/pxa.S
deleted file mode 100644
index 09e54f3..0000000
--- a/arch/arm/include/debug/pxa.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/*
- * Early serial output macro for Marvell PXA/MMP SoC
- *
- * Copyright (C) 1994-1999 Russell King
- * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * Copyright (C) 2013 Haojian Zhuang
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/rockchip.S b/arch/arm/include/debug/rockchip.S
deleted file mode 100644
index 3ad0238..0000000
--- a/arch/arm/include/debug/rockchip.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/*
- * Early serial output macro for Rockchip SoCs
- *
- * Copyright (C) 2012 Maxime Ripard
- *
- * Maxime Ripard <maxime.ripard at free-electrons.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/sunxi.S b/arch/arm/include/debug/sunxi.S
deleted file mode 100644
index 4c3d89c..0000000
--- a/arch/arm/include/debug/sunxi.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/*
- * Early serial output macro for Allwinner A1X SoCs
- *
- * Copyright (C) 2012 Maxime Ripard
- *
- * Maxime Ripard <maxime.ripard at free-electrons.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-dove/include/mach/debug-macro.S b/arch/arm/mach-dove/include/mach/debug-macro.S
deleted file mode 100644
index 9b85a81..0000000
--- a/arch/arm/mach-dove/include/mach/debug-macro.S
+++ /dev/null
@@ -1,8 +0,0 @@
-/*
- * arch/arm/mach-dove/include/mach/debug-macro.S
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-ebsa110/include/mach/debug-macro.S b/arch/arm/mach-ebsa110/include/mach/debug-macro.S
deleted file mode 100644
index 0cea548..0000000
--- a/arch/arm/mach-ebsa110/include/mach/debug-macro.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/* arch/arm/mach-ebsa110/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
-**/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-footbridge/include/mach/debug-macro.S b/arch/arm/mach-footbridge/include/mach/debug-macro.S
index 553c47d..02247f3 100644
--- a/arch/arm/mach-footbridge/include/mach/debug-macro.S
+++ b/arch/arm/mach-footbridge/include/mach/debug-macro.S
@@ -13,9 +13,6 @@
 
 #include <asm/hardware/dec21285.h>
 
-#ifndef CONFIG_DEBUG_DC21285_PORT
-#include <asm/hardware/debug-8250.S>
-#else
 #include <mach/hardware.h>
 	/* For EBSA285 debugging */
 		.equ	dc21285_high, ARMCSR_BASE & 0xff000000
@@ -43,4 +40,3 @@
 
 		.macro	waituart,rd,rx
 		.endm
-#endif
diff --git a/arch/arm/mach-gemini/include/mach/debug-macro.S b/arch/arm/mach-gemini/include/mach/debug-macro.S
deleted file mode 100644
index 9dabd4b..0000000
--- a/arch/arm/mach-gemini/include/mach/debug-macro.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/*
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Copyright (C) 2001-2006 Storlink, Corp.
- *  Copyright (C) 2008-2009 Paulius Zaleckas <paulius.zaleckas at teltonika.lt>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop13xx/include/mach/debug-macro.S b/arch/arm/mach-iop13xx/include/mach/debug-macro.S
deleted file mode 100644
index 90b5e64..0000000
--- a/arch/arm/mach-iop13xx/include/mach/debug-macro.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/*
- * arch/arm/mach-iop13xx/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- * Copyright (C) 1994-1999 Russell King
- * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop32x/include/mach/debug-macro.S b/arch/arm/mach-iop32x/include/mach/debug-macro.S
deleted file mode 100644
index 7ea745e..0000000
--- a/arch/arm/mach-iop32x/include/mach/debug-macro.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/*
- * arch/arm/mach-iop32x/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- * Copyright (C) 1994-1999 Russell King
- * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop33x/include/mach/debug-macro.S b/arch/arm/mach-iop33x/include/mach/debug-macro.S
deleted file mode 100644
index 52781ae..0000000
--- a/arch/arm/mach-iop33x/include/mach/debug-macro.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/*
- * arch/arm/mach-iop33x/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- * Copyright (C) 1994-1999 Russell King
- * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-ixp4xx/include/mach/debug-macro.S b/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
deleted file mode 100644
index ff706fa..0000000
--- a/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/* arch/arm/mach-ixp4xx/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-kirkwood/include/mach/debug-macro.S b/arch/arm/mach-kirkwood/include/mach/debug-macro.S
deleted file mode 100644
index 011ec25..0000000
--- a/arch/arm/mach-kirkwood/include/mach/debug-macro.S
+++ /dev/null
@@ -1,8 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/include/mach/debug-macro.S
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-lpc32xx/include/mach/debug-macro.S b/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
deleted file mode 100644
index c7bb4bc..0000000
--- a/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
+++ /dev/null
@@ -1,18 +0,0 @@
-/*
- * arch/arm/mach-lpc32xx/include/mach/debug-macro.S
- *
- * Author: Kevin Wells <kevin.wells at nxp.com>
- *
- * Copyright (C) 2010 NXP Semiconductors
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This 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.
- */
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S b/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
deleted file mode 100644
index c8284a2..0000000
--- a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
+++ /dev/null
@@ -1,8 +0,0 @@
-/*
- * arch/arm/mach-mv78xx0/include/mach/debug-macro.S
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-orion5x/include/mach/debug-macro.S b/arch/arm/mach-orion5x/include/mach/debug-macro.S
deleted file mode 100644
index 7489963..0000000
--- a/arch/arm/mach-orion5x/include/mach/debug-macro.S
+++ /dev/null
@@ -1,10 +0,0 @@
-/*
- * arch/arm/mach-orion5x/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-rpc/include/mach/debug-macro.S b/arch/arm/mach-rpc/include/mach/debug-macro.S
deleted file mode 100644
index 88a575e..0000000
--- a/arch/arm/mach-rpc/include/mach/debug-macro.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/* arch/arm/mach-rpc/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
-*/
-#include <asm/hardware/debug-8250.S>
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Sun Jul  7 08:50:32 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Sun, 07 Jul 2013 13:50:32 +0100
Subject: [PATCH RFC 7/9] ARM: debug: add support for word accesses to
 debug/8250.S
In-Reply-To: <20130707124326.GP24642@n2100.arm.linux.org.uk>
References: <20130707124326.GP24642@n2100.arm.linux.org.uk>
Message-ID: <E1UvoQC-0006I5-1S@rmk-PC.arm.linux.org.uk>

Add 32-bit word access support to debug/8250.S and convert Picoxcell
and SoCFPGA to this.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug             |   13 ++++++++++---
 arch/arm/include/debug/8250.S      |   24 +++++++++++++++++++++---
 arch/arm/include/debug/8250_32.S   |   27 ---------------------------
 arch/arm/include/debug/picoxcell.S |   19 -------------------
 arch/arm/include/debug/socfpga.S   |   21 ---------------------
 5 files changed, 31 insertions(+), 73 deletions(-)
 delete mode 100644 arch/arm/include/debug/8250_32.S
 delete mode 100644 arch/arm/include/debug/picoxcell.S
 delete mode 100644 arch/arm/include/debug/socfpga.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index defd881..c15177f 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -836,9 +836,7 @@ config DEBUG_LL_INCLUDE
 	default "debug/nomadik.S" if DEBUG_NOMADIK_UART
 	default "debug/nspire.S" if DEBUG_NSPIRE_CX_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
-	default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
 	default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
-	default "debug/socfpga.S" if DEBUG_SOCFPGA_UART
 	default "debug/sti.S" if DEBUG_STI_UART
 	default "debug/tegra.S" if DEBUG_TEGRA_UART
 	default "debug/u300.S" if DEBUG_U300_UART
@@ -855,7 +853,8 @@ config DEBUG_UART_8250
 	depends on DEBUG_MVEBU_UART || DEBUG_MVEBU_UART_ALTERNATE || \
 		DEBUG_NSPIRE_CLASSIC_UART || \
 		DEBUG_PXA_UART1 || DEBUG_MMP_UART2 || DEBUG_MMP_UART3 || \
-		DEBUG_ROCKCHIP_UART || \
+		DEBUG_ROCKCHIP_UART || DEBUG_PICOXCELL_UART || \
+		DEBUG_SOCFPGA_UART || \
 		DEBUG_SUNXI_UART0 || DEBUG_SUNXI_UART1 || \
 		ARCH_DOVE || ARCH_EBSA110 || \
 		(FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
@@ -877,6 +876,7 @@ config DEBUG_UART_PHYS
 	default 0x40100000 if DEBUG_PXA_UART1
 	default 0x42000000 if ARCH_GEMINI
 	default 0x7c0003f8 if FOOTBRIDGE
+	default 0x80230000 if DEBUG_PICOXCELL_UART
 	default 0x90020000 if DEBUG_NSPIRE_CLASSIC_UART
 	default 0xc8000000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
 	default 0xc8000003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
@@ -888,6 +888,7 @@ config DEBUG_UART_PHYS
 	default 0xf1012000 if ARCH_DOVE || ARCH_KIRKWOOD || ARCH_MV78XX0 || \
 				ARCH_ORION5X
 	default 0xfe800000 if ARCH_IOP32X
+	default 0xffc02000 if DEBUG_SOCFPGA_UART
 	default 0xffd82340 if ARCH_IOP13XX
 	default 0xfffff700 if ARCH_IOP33X
 	depends on DEBUG_UART_8250
@@ -906,6 +907,7 @@ config DEBUG_UART_VIRT
 	default 0xfe012000 if ARCH_ORION5X
 	default 0xfe017000 if DEBUG_MMP_UART2
 	default 0xfe018000 if DEBUG_MMP_UART3
+	default 0xfe230000 if DEBUG_PICOXCELL_UART
 	default 0xfe800000 if ARCH_IOP32X
 	default 0xfeb24000 if DEBUG_RK3X_UART0
 	default 0xfeb26000 if DEBUG_RK3X_UART1
@@ -913,6 +915,7 @@ config DEBUG_UART_VIRT
 	default 0xfed60000 if DEBUG_RK29_UART0
 	default 0xfed64000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
 	default 0xfed68000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
+	default 0xfec02000 if DEBUG_SOCFPGA_UART
 	default 0xfed12000 if ARCH_KIRKWOOD
 	default 0xfee003f8 if FOOTBRIDGE
 	default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART
@@ -922,6 +925,10 @@ config DEBUG_UART_VIRT
 	default 0xfefff700 if ARCH_IOP33X
 	depends on DEBUG_UART_8250
 
+config DEBUG_UART_8250_WORD
+	def_bool y if DEBUG_PICOXCELL_UART || DEBUG_SOCFPGA_UART
+	depends on DEBUG_UART_8250
+
 config DEBUG_UART_8250_SHIFT
 	int "Register offset shift for the 8250 debug UART"
 	depends on DEBUG_UART_8250
diff --git a/arch/arm/include/debug/8250.S b/arch/arm/include/debug/8250.S
index 4df055b..cb25bae 100644
--- a/arch/arm/include/debug/8250.S
+++ b/arch/arm/include/debug/8250.S
@@ -14,14 +14,32 @@
 		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
 		.endm
 
+#ifdef CONFIG_DEBUG_UART_8250_WORD
+		.macro	store, rd, rx:vararg
+		str	\rd, \rx
+		.endm
+
+		.macro	load, rd, rx:vararg
+		ldr	\rd, \rx
+		.endm
+#else
+		.macro	store, rd, rx:vararg
+		strb	\rd, \rx
+		.endm
+
+		.macro	load, rd, rx:vararg
+		ldrb	\rd, \rx
+		.endm
+#endif
+
 #define UART_SHIFT CONFIG_DEBUG_UART_8250_SHIFT
 
 		.macro	senduart,rd,rx
-		strb	\rd, [\rx, #UART_TX << UART_SHIFT]
+		store	\rd, [\rx, #UART_TX << UART_SHIFT]
 		.endm
 
 		.macro	busyuart,rd,rx
-1002:		ldrb	\rd, [\rx, #UART_LSR << UART_SHIFT]
+1002:		load	\rd, [\rx, #UART_LSR << UART_SHIFT]
 		and	\rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
 		teq	\rd, #UART_LSR_TEMT | UART_LSR_THRE
 		bne	1002b
@@ -29,7 +47,7 @@
 
 		.macro	waituart,rd,rx
 #ifdef CONFIG_DEBUG_UART_8250_FLOW_CONTROL
-1001:		ldrb	\rd, [\rx, #UART_MSR << UART_SHIFT]
+1001:		load	\rd, [\rx, #UART_MSR << UART_SHIFT]
 		tst	\rd, #UART_MSR_CTS
 		beq	1001b
 #endif
diff --git a/arch/arm/include/debug/8250_32.S b/arch/arm/include/debug/8250_32.S
deleted file mode 100644
index 8db01ee..0000000
--- a/arch/arm/include/debug/8250_32.S
+++ /dev/null
@@ -1,27 +0,0 @@
-/*
- * Copyright (c) 2011 Picochip Ltd., Jamie Iles
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * Derived from arch/arm/mach-davinci/include/mach/debug-macro.S to use 32-bit
- * accesses to the 8250.
- */
-
-#include <linux/serial_reg.h>
-
-		.macro	senduart,rd,rx
-		str	\rd, [\rx, #UART_TX << UART_SHIFT]
-		.endm
-
-		.macro	busyuart,rd,rx
-1002:		ldr	\rd, [\rx, #UART_LSR << UART_SHIFT]
-		and	\rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
-		teq	\rd, #UART_LSR_TEMT | UART_LSR_THRE
-		bne	1002b
-		.endm
-
-		/* The UART's don't have any flow control IO's wired up. */
-		.macro	waituart,rd,rx
-		.endm
diff --git a/arch/arm/include/debug/picoxcell.S b/arch/arm/include/debug/picoxcell.S
deleted file mode 100644
index bc1f07c..0000000
--- a/arch/arm/include/debug/picoxcell.S
+++ /dev/null
@@ -1,19 +0,0 @@
-/*
- * Copyright (c) 2011 Picochip Ltd., Jamie Iles
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#define UART_SHIFT 2
-#define PICOXCELL_UART1_BASE		0x80230000
-#define PHYS_TO_IO(x)			(((x) & 0x00ffffff) | 0xfe000000)
-
-		.macro	addruart, rp, rv, tmp
-		ldr	\rv, =PHYS_TO_IO(PICOXCELL_UART1_BASE)
-		ldr	\rp, =PICOXCELL_UART1_BASE
-		.endm
-
-#include "8250_32.S"
diff --git a/arch/arm/include/debug/socfpga.S b/arch/arm/include/debug/socfpga.S
deleted file mode 100644
index 966b2f9..0000000
--- a/arch/arm/include/debug/socfpga.S
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#define UART_SHIFT 2
-#define DEBUG_LL_UART_OFFSET	0x00002000
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #DEBUG_LL_UART_OFFSET
-		orr	\rp, \rp, #0x00c00000
-		orr	\rv, \rp, #0xfe000000	@ virtual base
-		orr	\rp, \rp, #0xff000000	@ physical base
-		.endm
-
-#include "8250_32.S"
-
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Sun Jul  7 08:51:32 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Sun, 07 Jul 2013 13:51:32 +0100
Subject: [PATCH RFC 8/9] ARM: debug: provide PL01x debug uart phys/virt
 address configuration options
In-Reply-To: <20130707124326.GP24642@n2100.arm.linux.org.uk>
References: <20130707124326.GP24642@n2100.arm.linux.org.uk>
Message-ID: <E1UvoRA-0006IA-FJ@rmk-PC.arm.linux.org.uk>

Move the definition of the UART register addresses out of the platform
specific header files into the Kconfig files.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug                             |   53 ++++++++++++++++++--
 arch/arm/include/asm/hardware/debug-pl01x.S        |    7 +++
 arch/arm/include/debug/bcm2835.S                   |    9 ---
 arch/arm/include/debug/cns3xxx.S                   |    7 ---
 arch/arm/include/debug/highbank.S                  |    6 --
 arch/arm/include/debug/mxs.S                       |   14 -----
 arch/arm/include/debug/nomadik.S                   |    8 ---
 arch/arm/include/debug/nspire.S                    |   10 ----
 arch/arm/include/debug/u300.S                      |   11 ----
 arch/arm/include/debug/vexpress.S                  |   46 -----------------
 arch/arm/mach-ep93xx/include/mach/debug-macro.S    |    9 ---
 .../arm/mach-integrator/include/mach/debug-macro.S |    7 ---
 arch/arm/mach-realview/include/mach/debug-macro.S  |   17 ------
 arch/arm/mach-versatile/include/mach/debug-macro.S |    8 ---
 14 files changed, 56 insertions(+), 156 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index c15177f..cd4edaf 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -848,6 +848,23 @@ config DEBUG_LL_INCLUDE
 	default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
 	default "mach/debug-macro.S"
 
+config DEBUG_UART_PL01X
+	def_bool y
+	depends on \
+		DEBUG_BCM2835 || \
+		DEBUG_CNS3XXX || \
+		DEBUG_HIGHBANK_UART || \
+		DEBUG_IMX23_UART || DEBUG_IMX28_UART || \
+		DEBUG_NOMADIK_UART || \
+		DEBUG_NSPIRE_CX_UART || \
+		DEBUG_REALVIEW_STD_PORT || DEBUG_REALVIEW_PB1176_PORT || \
+		DEBUG_U300_UART || \
+		DEBUG_VEXPRESS_UART0_CA9 || DEBUG_VEXPRESS_UART0_RS1 || \
+		DEBUG_VEXPRESS_UART0_CRX || \
+		ARCH_EP93XX || \
+		ARCH_INTEGRATOR || \
+		ARCH_VERSATILE
+
 config DEBUG_UART_8250
 	def_bool y
 	depends on DEBUG_MVEBU_UART || DEBUG_MVEBU_UART_ALTERNATE || \
@@ -867,17 +884,30 @@ config DEBUG_UART_PHYS
 	default 0x01c28000 if DEBUG_SUNXI_UART0
 	default 0x01c28400 if DEBUG_SUNXI_UART1
 	default 0x03010fe0 if ARCH_RPC
+	default 0x10009000 if DEBUG_REALVIEW_STD_PORT || DEBUG_CNS3XXX || \
+				DEBUG_VEXPRESS_UART0_CA9
+	default 0x1010c000 if DEBUG_REALVIEW_PB1176_PORT
 	default 0x10124000 if DEBUG_RK3X_UART0
 	default 0x10126000 if DEBUG_RK3X_UART1
+	default 0x101f1000 if ARCH_VERSATILE
+	default 0x101fb000 if DEBUG_NOMADIK_UART
+	default 0x16000000 if ARCH_INTEGRATOR
+	default 0x1c090000 if DEBUG_VEXPRESS_UART0_RS1
 	default 0x20060000 if DEBUG_RK29_UART0
 	default 0x20064000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
 	default 0x20068000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
+	default 0x20201000 if DEBUG_BCM2835
 	default 0x40090000 if ARCH_LPC32XX
 	default 0x40100000 if DEBUG_PXA_UART1
 	default 0x42000000 if ARCH_GEMINI
 	default 0x7c0003f8 if FOOTBRIDGE
 	default 0x80230000 if DEBUG_PICOXCELL_UART
-	default 0x90020000 if DEBUG_NSPIRE_CLASSIC_UART
+	default 0x80070000 if DEBUG_IMX23_UART
+	default 0x80074000 if DEBUG_IMX28_UART
+	default 0x808c0000 if ARCH_EP93XX
+	default 0x90020000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART
+	default 0xb0090000 if DEBUG_VEXPRESS_UART0_CRX
+	default 0xc0013000 if DEBUG_U300_UART
 	default 0xc8000000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
 	default 0xc8000003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
 	default 0xd0012000 if DEBUG_MVEBU_UART
@@ -890,23 +920,34 @@ config DEBUG_UART_PHYS
 	default 0xfe800000 if ARCH_IOP32X
 	default 0xffc02000 if DEBUG_SOCFPGA_UART
 	default 0xffd82340 if ARCH_IOP13XX
+	default 0xfff36000 if DEBUG_HIGHBANK_UART
 	default 0xfffff700 if ARCH_IOP33X
-	depends on DEBUG_UART_8250
+	depends on DEBUG_UART_8250 || DEBUG_UART_PL01X
 
 config DEBUG_UART_VIRT
 	hex "Virtual base address of debug UART"
 	default 0xe0010fe0 if ARCH_RPC
 	default 0xf0000be0 if ARCH_EBSA110
+	default 0xf0009000 if DEBUG_CNS3XXX
+	default 0xf01fb000 if DEBUG_NOMADIK_UART
+	default 0xf0201000 if DEBUG_BCM2835
+	default 0xf11f1000 if ARCH_VERSATILE
+	default 0xf1600000 if ARCH_INTEGRATOR
 	default 0xf1c28000 if DEBUG_SUNXI_UART0
 	default 0xf1c28400 if DEBUG_SUNXI_UART1
 	default 0xf2100000 if DEBUG_PXA_UART1
 	default 0xf4090000 if ARCH_LPC32XX
 	default 0xf4200000 if ARCH_GEMINI
+	default 0xf8009000 if DEBUG_VEXPRESS_UART0_CA9
+	default 0xf8090000 if DEBUG_VEXPRESS_UART0_RS1
+	default 0xfb009000 if DEBUG_REALVIEW_STD_PORT
+	default 0xfb10c000 if DEBUG_REALVIEW_PB1176_PORT
 	default 0xfd012000 if ARCH_MV78XX0
 	default 0xfde12000 if ARCH_DOVE
 	default 0xfe012000 if ARCH_ORION5X
 	default 0xfe017000 if DEBUG_MMP_UART2
 	default 0xfe018000 if DEBUG_MMP_UART3
+	default 0xfe100000 if DEBUG_IMX23_UART || DEBUG_IMX28_UART
 	default 0xfe230000 if DEBUG_PICOXCELL_UART
 	default 0xfe800000 if ARCH_IOP32X
 	default 0xfeb24000 if DEBUG_RK3X_UART0
@@ -917,13 +958,17 @@ config DEBUG_UART_VIRT
 	default 0xfed68000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
 	default 0xfec02000 if DEBUG_SOCFPGA_UART
 	default 0xfed12000 if ARCH_KIRKWOOD
+	default 0xfedc0000 if ARCH_EP93XX
 	default 0xfee003f8 if FOOTBRIDGE
-	default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART
+	default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART
+	default 0xfee36000 if DEBUG_HIGHBANK_UART
 	default 0xfee82340 if ARCH_IOP13XX
 	default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
 	default 0xfef00003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
 	default 0xfefff700 if ARCH_IOP33X
-	depends on DEBUG_UART_8250
+	default 0xff003000 if DEBUG_U300_UART
+	default DEBUG_UART_PHYS if !MMU
+	depends on DEBUG_UART_8250 || DEBUG_UART_PL01X
 
 config DEBUG_UART_8250_WORD
 	def_bool y if DEBUG_PICOXCELL_UART || DEBUG_SOCFPGA_UART
diff --git a/arch/arm/include/asm/hardware/debug-pl01x.S b/arch/arm/include/asm/hardware/debug-pl01x.S
index f9fd083..9d1e286 100644
--- a/arch/arm/include/asm/hardware/debug-pl01x.S
+++ b/arch/arm/include/asm/hardware/debug-pl01x.S
@@ -12,6 +12,13 @@
 */
 #include <linux/amba/serial.h>
 
+#ifdef CONFIG_DEBUG_UART_PHYS
+		.macro	addruart, rp, rv, tmp
+		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
+		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
+		.endm
+#endif
+
 		.macro	senduart,rd,rx
 		strb	\rd, [\rx, #UART01x_DR]
 		.endm
diff --git a/arch/arm/include/debug/bcm2835.S b/arch/arm/include/debug/bcm2835.S
index aed9199..726e069 100644
--- a/arch/arm/include/debug/bcm2835.S
+++ b/arch/arm/include/debug/bcm2835.S
@@ -10,13 +10,4 @@
  * published by the Free Software Foundation.
  *
  */
-
-#define BCM2835_DEBUG_PHYS 0x20201000
-#define BCM2835_DEBUG_VIRT 0xf0201000
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =BCM2835_DEBUG_PHYS
-	ldr	\rv, =BCM2835_DEBUG_VIRT
-	.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/cns3xxx.S b/arch/arm/include/debug/cns3xxx.S
index d04c150..2d5fb51 100644
--- a/arch/arm/include/debug/cns3xxx.S
+++ b/arch/arm/include/debug/cns3xxx.S
@@ -9,11 +9,4 @@
  * it under the terms of the GNU General Public License, Version 2, as
  * published by the Free Software Foundation.
  */
-
-		.macro	addruart,rp,rv,tmp
-		mov	\rp, #0x00009000
-		orr	\rv, \rp, #0xf0000000	@ virtual base
-		orr	\rp, \rp, #0x10000000
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/highbank.S b/arch/arm/include/debug/highbank.S
index 8cad432..3c6f63f 100644
--- a/arch/arm/include/debug/highbank.S
+++ b/arch/arm/include/debug/highbank.S
@@ -8,10 +8,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-
-		.macro	addruart,rp,rv,tmp
-		ldr	\rv, =0xfee36000
-		ldr	\rp, =0xfff36000
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/mxs.S b/arch/arm/include/debug/mxs.S
index d869515..8a10ed2 100644
--- a/arch/arm/include/debug/mxs.S
+++ b/arch/arm/include/debug/mxs.S
@@ -10,18 +10,4 @@
  * published by the Free Software Foundation.
  *
  */
-
-#ifdef CONFIG_DEBUG_IMX23_UART
-#define UART_PADDR	0x80070000
-#elif defined (CONFIG_DEBUG_IMX28_UART)
-#define UART_PADDR	0x80074000
-#endif
-
-#define UART_VADDR	0xfe100000
-
-		.macro	addruart, rp, rv, tmp
-		ldr	\rp, =UART_PADDR	@ physical
-		ldr	\rv, =UART_VADDR	@ virtual
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/nomadik.S b/arch/arm/include/debug/nomadik.S
index 7354179..a6d238e 100644
--- a/arch/arm/include/debug/nomadik.S
+++ b/arch/arm/include/debug/nomadik.S
@@ -9,12 +9,4 @@
  * published by the Free Software Foundation.
  *
 */
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0x00100000
-		add	\rp, \rp, #0x000fb000
-		add	\rv, \rp, #0xf0000000	@ virtual base
-		add	\rp, \rp, #0x10000000	@ physical base address
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/nspire.S b/arch/arm/include/debug/nspire.S
index 9c2fbec..fc17e50 100644
--- a/arch/arm/include/debug/nspire.S
+++ b/arch/arm/include/debug/nspire.S
@@ -8,14 +8,4 @@
  * published by the Free Software Foundation.
  *
  */
-#ifdef CONFIG_DEBUG_NSPIRE_CX_UART
-#define NSPIRE_EARLY_UART_PHYS_BASE	   0x90020000
-#define NSPIRE_EARLY_UART_VIRT_BASE	   0xfee20000
-
-.macro	addruart, rp, rv, tmp
-	ldr \rp, =(NSPIRE_EARLY_UART_PHYS_BASE)		@ physical base address
-	ldr \rv, =(NSPIRE_EARLY_UART_VIRT_BASE)		@ virtual base address
-.endm
-
 #include <asm/hardware/debug-pl01x.S>
-#endif
diff --git a/arch/arm/include/debug/u300.S b/arch/arm/include/debug/u300.S
index 6f04f08..58b9d62 100644
--- a/arch/arm/include/debug/u300.S
+++ b/arch/arm/include/debug/u300.S
@@ -4,15 +4,4 @@
  * Debugging macro include header.
  * Author: Linus Walleij <linus.walleij at stericsson.com>
  */
-#define U300_SLOW_PER_PHYS_BASE		0xc0010000
-#define U300_SLOW_PER_VIRT_BASE		0xff000000
-
-	.macro	addruart, rp, rv, tmp
-	/* If we move the address using MMU, use this. */
-	ldr	\rp,	  = U300_SLOW_PER_PHYS_BASE @ MMU off, physical address
-	ldr	\rv,	  = U300_SLOW_PER_VIRT_BASE @ MMU on, virtual address
-	orr	\rp, \rp, #0x00003000
-	orr	\rv, \rv, #0x00003000
-	.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/vexpress.S b/arch/arm/include/debug/vexpress.S
index acafb22..114bf4c 100644
--- a/arch/arm/include/debug/vexpress.S
+++ b/arch/arm/include/debug/vexpress.S
@@ -48,50 +48,4 @@
 		.endm
 
 #include <asm/hardware/debug-pl01x.S>
-
-#elif defined(CONFIG_DEBUG_VEXPRESS_UART0_CA9)
-
-		.macro	addruart,rp,rv,tmp
-		mov	\rp, #DEBUG_LL_UART_OFFSET
-		orr	\rv, \rp, #DEBUG_LL_VIRT_BASE
-		orr	\rp, \rp, #DEBUG_LL_PHYS_BASE
-		.endm
-
-#include <asm/hardware/debug-pl01x.S>
-
-#elif defined(CONFIG_DEBUG_VEXPRESS_UART0_RS1)
-
-		.macro	addruart,rp,rv,tmp
-		mov	\rp, #DEBUG_LL_UART_OFFSET_RS1
-		orr	\rv, \rp, #DEBUG_LL_VIRT_BASE
-		orr	\rp, \rp, #DEBUG_LL_PHYS_BASE_RS1
-		.endm
-
-#include <asm/hardware/debug-pl01x.S>
-
-#elif defined(CONFIG_DEBUG_VEXPRESS_UART0_CRX)
-
-		.macro	addruart,rp,tmp,tmp2
-		ldr	\rp, =DEBUG_LL_UART_PHYS_CRX
-		.endm
-
-#include <asm/hardware/debug-pl01x.S>
-
-#else /* CONFIG_DEBUG_LL_UART_NONE */
-
-		.macro	addruart, rp, rv, tmp
-		/* Safe dummy values */
-		mov	\rp, #0
-		mov	\rv, #DEBUG_LL_VIRT_BASE
-		.endm
-
-		.macro	senduart,rd,rx
-		.endm
-
-		.macro	waituart,rd,rx
-		.endm
-
-		.macro	busyuart,rd,rx
-		.endm
-
 #endif
diff --git a/arch/arm/mach-ep93xx/include/mach/debug-macro.S b/arch/arm/mach-ep93xx/include/mach/debug-macro.S
index af54e43..a1bfe4c 100644
--- a/arch/arm/mach-ep93xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-ep93xx/include/mach/debug-macro.S
@@ -9,13 +9,4 @@
  * the Free Software Foundation; either version 2 of the License, or (at
  * your option) any later version.
  */
-#include <mach/ep93xx-regs.h>
-
-		.macro	addruart, rp, rv, tmp
-		ldr	\rp, =EP93XX_APB_PHYS_BASE	@ Physical base
-		ldr	\rv, =EP93XX_APB_VIRT_BASE	@ virtual base
-		orr	\rp, \rp, #0x000c0000
-		orr	\rv, \rv, #0x000c0000
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/mach-integrator/include/mach/debug-macro.S b/arch/arm/mach-integrator/include/mach/debug-macro.S
index 411b116..03ee0fd 100644
--- a/arch/arm/mach-integrator/include/mach/debug-macro.S
+++ b/arch/arm/mach-integrator/include/mach/debug-macro.S
@@ -10,11 +10,4 @@
  * published by the Free Software Foundation.
  *
 */
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0x16000000	@ physical base address
-		mov	\rv, #0xf0000000	@ virtual base
-		add	\rv, \rv, #0x16000000 >> 4
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/mach-realview/include/mach/debug-macro.S b/arch/arm/mach-realview/include/mach/debug-macro.S
index 8cc372d..99488f4 100644
--- a/arch/arm/mach-realview/include/mach/debug-macro.S
+++ b/arch/arm/mach-realview/include/mach/debug-macro.S
@@ -9,21 +9,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-
-#ifdef CONFIG_DEBUG_REALVIEW_STD_PORT
-#define DEBUG_LL_UART_OFFSET	0x00009000
-#elif defined(CONFIG_DEBUG_REALVIEW_PB1176_PORT)
-#define DEBUG_LL_UART_OFFSET	0x0010c000
-#endif
-
-#ifndef DEBUG_LL_UART_OFFSET
-#error "Unknown RealView platform"
-#endif
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #DEBUG_LL_UART_OFFSET
-		orr	\rv, \rp, #0xfb000000	@ virtual base
-		orr	\rp, \rp, #0x10000000	@ physical base
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/mach-versatile/include/mach/debug-macro.S b/arch/arm/mach-versatile/include/mach/debug-macro.S
index d0fbd7f..c256977 100644
--- a/arch/arm/mach-versatile/include/mach/debug-macro.S
+++ b/arch/arm/mach-versatile/include/mach/debug-macro.S
@@ -10,12 +10,4 @@
  * published by the Free Software Foundation.
  *
 */
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp,      #0x001F0000
-		orr	\rp, \rp, #0x00001000
-		orr	\rv, \rp, #0xf1000000	@ virtual base
-		orr	\rp, \rp,  #0x10000000	@ physical base
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Sun Jul  7 08:52:32 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Sun, 07 Jul 2013 13:52:32 +0100
Subject: [PATCH RFC 9/9] ARM: debug: move PL01X debug include into
 arch/arm/include/debug/
In-Reply-To: <20130707124326.GP24642@n2100.arm.linux.org.uk>
References: <20130707124326.GP24642@n2100.arm.linux.org.uk>
Message-ID: <E1UvoS8-0006IF-TE@rmk-PC.arm.linux.org.uk>

Now that the PL01X debug include can mostly stand alone without
requiring platforms to provide any macros, move it into the debug
directory so it can be directly included.  This allows us to get rid of
a lot of debug-macros include files.

The autodetect case for Versatile Express and the ux500 are left alone;
these are more complicated implementations.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug                             |   12 +-----
 arch/arm/include/asm/hardware/debug-pl01x.S        |   36 --------------------
 arch/arm/include/debug/bcm2835.S                   |   13 -------
 arch/arm/include/debug/cns3xxx.S                   |   12 ------
 arch/arm/include/debug/highbank.S                  |   11 ------
 arch/arm/include/debug/mxs.S                       |   13 -------
 arch/arm/include/debug/nomadik.S                   |   12 ------
 arch/arm/include/debug/nspire.S                    |   11 ------
 arch/arm/include/debug/pl01x.S                     |   36 ++++++++++++++++++++
 arch/arm/include/debug/u300.S                      |    7 ----
 arch/arm/include/debug/ux500.S                     |    2 +-
 arch/arm/include/debug/vexpress.S                  |    2 +-
 arch/arm/mach-ep93xx/include/mach/debug-macro.S    |   12 ------
 .../arm/mach-integrator/include/mach/debug-macro.S |   13 -------
 arch/arm/mach-realview/include/mach/debug-macro.S  |   12 ------
 arch/arm/mach-versatile/include/mach/debug-macro.S |   13 -------
 16 files changed, 40 insertions(+), 177 deletions(-)
 delete mode 100644 arch/arm/include/asm/hardware/debug-pl01x.S
 delete mode 100644 arch/arm/include/debug/bcm2835.S
 delete mode 100644 arch/arm/include/debug/cns3xxx.S
 delete mode 100644 arch/arm/include/debug/highbank.S
 delete mode 100644 arch/arm/include/debug/mxs.S
 delete mode 100644 arch/arm/include/debug/nomadik.S
 delete mode 100644 arch/arm/include/debug/nspire.S
 create mode 100644 arch/arm/include/debug/pl01x.S
 delete mode 100644 arch/arm/include/debug/u300.S
 delete mode 100644 arch/arm/mach-ep93xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-integrator/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-realview/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-versatile/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index cd4edaf..4fff87d 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -816,10 +816,8 @@ config DEBUG_STI_UART
 config DEBUG_LL_INCLUDE
 	string
 	default "debug/8250.S" if DEBUG_UART_8250
-	default "debug/bcm2835.S" if DEBUG_BCM2835
-	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
+	default "debug/pl01x.S" if DEBUG_UART_PL01X
 	default "debug/exynos.S" if DEBUG_EXYNOS_UART
-	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
 	default "debug/icedcc.S" if DEBUG_ICEDCC
 	default "debug/imx.S" if DEBUG_IMX1_UART || \
 				 DEBUG_IMX25_UART || \
@@ -832,18 +830,12 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX6SL_UART
 	default "debug/keystone.S" if DEBUG_KEYSTONE_UART0 || \
 				      DEBUG_KEYSTONE_UART1
-	default "debug/mxs.S" if DEBUG_IMX23_UART || DEBUG_IMX28_UART
-	default "debug/nomadik.S" if DEBUG_NOMADIK_UART
-	default "debug/nspire.S" if DEBUG_NSPIRE_CX_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 	default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
 	default "debug/sti.S" if DEBUG_STI_UART
 	default "debug/tegra.S" if DEBUG_TEGRA_UART
-	default "debug/u300.S" if DEBUG_U300_UART
 	default "debug/ux500.S" if DEBUG_UX500_UART
-	default "debug/vexpress.S" if DEBUG_VEXPRESS_UART0_DETECT || \
-		DEBUG_VEXPRESS_UART0_CA9 || DEBUG_VEXPRESS_UART0_RS1 || \
-		DEBUG_VEXPRESS_UART0_CRX
+	default "debug/vexpress.S" if DEBUG_VEXPRESS_UART0_DETECT
 	default "debug/vt8500.S" if DEBUG_VT8500_UART0
 	default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
 	default "mach/debug-macro.S"
diff --git a/arch/arm/include/asm/hardware/debug-pl01x.S b/arch/arm/include/asm/hardware/debug-pl01x.S
deleted file mode 100644
index 9d1e286..0000000
--- a/arch/arm/include/asm/hardware/debug-pl01x.S
+++ /dev/null
@@ -1,36 +0,0 @@
-/* arch/arm/include/asm/hardware/debug-pl01x.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
-*/
-#include <linux/amba/serial.h>
-
-#ifdef CONFIG_DEBUG_UART_PHYS
-		.macro	addruart, rp, rv, tmp
-		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
-		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
-		.endm
-#endif
-
-		.macro	senduart,rd,rx
-		strb	\rd, [\rx, #UART01x_DR]
-		.endm
-
-		.macro	waituart,rd,rx
-1001:		ldr	\rd, [\rx, #UART01x_FR]
-		tst	\rd, #UART01x_FR_TXFF
-		bne	1001b
-		.endm
-
-		.macro	busyuart,rd,rx
-1001:		ldr	\rd, [\rx, #UART01x_FR]
-		tst	\rd, #UART01x_FR_BUSY
-		bne	1001b
-		.endm
diff --git a/arch/arm/include/debug/bcm2835.S b/arch/arm/include/debug/bcm2835.S
deleted file mode 100644
index 726e069..0000000
--- a/arch/arm/include/debug/bcm2835.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/*
- * Debugging macro include header
- *
- * Copyright (C) 2010 Broadcom
- * Copyright (C) 1994-1999 Russell King
- * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/cns3xxx.S b/arch/arm/include/debug/cns3xxx.S
deleted file mode 100644
index 2d5fb51..0000000
--- a/arch/arm/include/debug/cns3xxx.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/*
- * Debugging macro include header
- *
- * Copyright 1994-1999 Russell King
- * Copyright 2008 Cavium Networks
- * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This file is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License, Version 2, as
- * published by the Free Software Foundation.
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/highbank.S b/arch/arm/include/debug/highbank.S
deleted file mode 100644
index 3c6f63f..0000000
--- a/arch/arm/include/debug/highbank.S
+++ /dev/null
@@ -1,11 +0,0 @@
-/*
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/mxs.S b/arch/arm/include/debug/mxs.S
deleted file mode 100644
index 8a10ed2..0000000
--- a/arch/arm/include/debug/mxs.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/* arch/arm/mach-mxs/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/nomadik.S b/arch/arm/include/debug/nomadik.S
deleted file mode 100644
index a6d238e..0000000
--- a/arch/arm/include/debug/nomadik.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/*
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
-*/
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/nspire.S b/arch/arm/include/debug/nspire.S
deleted file mode 100644
index fc17e50..0000000
--- a/arch/arm/include/debug/nspire.S
+++ /dev/null
@@ -1,11 +0,0 @@
-/*
- *	linux/arch/arm/include/debug/nspire.S
- *
- *	Copyright (C) 2013 Daniel Tang <tangrs at tangrs.id.au>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2, as
- * published by the Free Software Foundation.
- *
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/pl01x.S b/arch/arm/include/debug/pl01x.S
new file mode 100644
index 0000000..37c6895b
--- /dev/null
+++ b/arch/arm/include/debug/pl01x.S
@@ -0,0 +1,36 @@
+/* arch/arm/include/debug/pl01x.S
+ *
+ * Debugging macro include header
+ *
+ *  Copyright (C) 1994-1999 Russell King
+ *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+*/
+#include <linux/amba/serial.h>
+
+#ifdef CONFIG_DEBUG_UART_PHYS
+		.macro	addruart, rp, rv, tmp
+		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
+		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
+		.endm
+#endif
+
+		.macro	senduart,rd,rx
+		strb	\rd, [\rx, #UART01x_DR]
+		.endm
+
+		.macro	waituart,rd,rx
+1001:		ldr	\rd, [\rx, #UART01x_FR]
+		tst	\rd, #UART01x_FR_TXFF
+		bne	1001b
+		.endm
+
+		.macro	busyuart,rd,rx
+1001:		ldr	\rd, [\rx, #UART01x_FR]
+		tst	\rd, #UART01x_FR_BUSY
+		bne	1001b
+		.endm
diff --git a/arch/arm/include/debug/u300.S b/arch/arm/include/debug/u300.S
deleted file mode 100644
index 58b9d62..0000000
--- a/arch/arm/include/debug/u300.S
+++ /dev/null
@@ -1,7 +0,0 @@
-/*
- * Copyright (C) 2006-2013 ST-Ericsson AB
- * License terms: GNU General Public License (GPL) version 2
- * Debugging macro include header.
- * Author: Linus Walleij <linus.walleij at stericsson.com>
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/ux500.S b/arch/arm/include/debug/ux500.S
index fbd24be..aa7f63a 100644
--- a/arch/arm/include/debug/ux500.S
+++ b/arch/arm/include/debug/ux500.S
@@ -45,4 +45,4 @@
 	ldr	\rv, =UART_VIRT_BASE		@ yes, virtual address
 	.endm
 
-#include <asm/hardware/debug-pl01x.S>
+#include <debug/pl01x.S>
diff --git a/arch/arm/include/debug/vexpress.S b/arch/arm/include/debug/vexpress.S
index 114bf4c..524acd5 100644
--- a/arch/arm/include/debug/vexpress.S
+++ b/arch/arm/include/debug/vexpress.S
@@ -47,5 +47,5 @@
 
 		.endm
 
-#include <asm/hardware/debug-pl01x.S>
+#include <debug/pl01x.S>
 #endif
diff --git a/arch/arm/mach-ep93xx/include/mach/debug-macro.S b/arch/arm/mach-ep93xx/include/mach/debug-macro.S
deleted file mode 100644
index a1bfe4c..0000000
--- a/arch/arm/mach-ep93xx/include/mach/debug-macro.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/*
- * arch/arm/mach-ep93xx/include/mach/debug-macro.S
- * Debugging macro include header
- *
- * Copyright (C) 2006 Lennert Buytenhek <buytenh at wantstofly.org>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or (at
- * your option) any later version.
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/mach-integrator/include/mach/debug-macro.S b/arch/arm/mach-integrator/include/mach/debug-macro.S
deleted file mode 100644
index 03ee0fd..0000000
--- a/arch/arm/mach-integrator/include/mach/debug-macro.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/* arch/arm/mach-integrator/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
-*/
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/mach-realview/include/mach/debug-macro.S b/arch/arm/mach-realview/include/mach/debug-macro.S
deleted file mode 100644
index 99488f4..0000000
--- a/arch/arm/mach-realview/include/mach/debug-macro.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/* arch/arm/mach-realview/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/mach-versatile/include/mach/debug-macro.S b/arch/arm/mach-versatile/include/mach/debug-macro.S
deleted file mode 100644
index c256977..0000000
--- a/arch/arm/mach-versatile/include/mach/debug-macro.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/* arch/arm/mach-versatile/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
-*/
-#include <asm/hardware/debug-pl01x.S>
-- 
1.7.4.4



From tglx at linutronix.de  Sun Jul  7 09:10:25 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sun, 7 Jul 2013 15:10:25 +0200 (CEST)
Subject: [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC
 timer
In-Reply-To: <51D9548B.9040907@gmail.com>
References: <51B8D310.4050404@linaro.org> <51D9548B.9040907@gmail.com>
Message-ID: <alpine.DEB.2.02.1307071508030.32106@ionos.tec.linutronix.de>

On Sun, 7 Jul 2013, Sebastian Hesselbarth wrote:
> > ----------------------------------------------------------------
> > Sebastian Hesselbarth (1):
> >        clocksource: Add Marvell Orion SoC timer
> 
> with tip timers/core PR sent, I realized that the above did not make it
> in. As we have a whole bunch of cleanup and DT conversion patches for

Opps. Fell through the cracks.

> v3.11-rc1 depending on it, would it be ok for you to let Jason Cooper
> take it through his ARM sub-branch?

> If you are fine with it, I will resend the patch and note that Daniel
> can drop it and Jason will take it.

Nah, Jason can just pull it from Daniels tree and be done with it.

Thanks,

	tglx


From festevam at gmail.com  Sun Jul  7 09:12:30 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sun,  7 Jul 2013 10:12:30 -0300
Subject: [PATCH] ARM: dts: imx: Add the missing cpus node
Message-ID: <1373202750-10298-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

To make it consistent with the other i.mx SoCs, let's add the cpus nodes.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/imx25.dtsi | 10 ++++++++++
 arch/arm/boot/dts/imx27.dtsi | 10 ++++++++++
 arch/arm/boot/dts/imx31.dtsi | 10 ++++++++++
 arch/arm/boot/dts/imx53.dtsi | 10 ++++++++++
 4 files changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index f590484..1bb9615 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -32,6 +32,16 @@
 		usb1 = &usbhost1;
 	};
 
+	cpus {
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
+		};
+	};
+
 	asic: asic-interrupt-controller at 68000000 {
 		compatible = "fsl,imx25-asic", "fsl,avic";
 		interrupt-controller;
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index a587294..cca29ea 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -32,6 +32,16 @@
 		spi2 = &cspi3;
 	};
 
+	cpus {
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
+		};
+	};
+
 	aitc: aitc-interrupt-controller at e0000000 {
 		compatible = "fsl,imx27-aitc", "fsl,avic";
 		interrupt-controller;
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 8116778..c34f825 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -20,6 +20,16 @@
 		serial4 = &uart5;
 	};
 
+	cpus {
+		#address-cells = <0>;
+		#size-cells = <0>;
+
+		cpu {
+			compatible = "arm,arm1136";
+			device_type = "cpu";
+		};
+	};
+
 	avic: avic-interrupt-controller at 60000000 {
 		compatible = "fsl,imx31-avic", "fsl,avic";
 		interrupt-controller;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index eb21034..34b7266 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -35,6 +35,16 @@
 		spi2 = &cspi;
 	};
 
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a8";
+			reg = <0x0>;
+		};
+	};
+
 	tzic: tz-interrupt-controller at 0fffc000 {
 		compatible = "fsl,imx53-tzic", "fsl,tzic";
 		interrupt-controller;
-- 
1.8.1.2



From mpa at pengutronix.de  Sun Jul  7 09:13:30 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Jul 2013 15:13:30 +0200
Subject: [PATCH 2/3] ARM: dts: imx27 phyCARD-S, move i2c1 and owire to rdk
In-Reply-To: <1373202811-13825-1-git-send-email-mpa@pengutronix.de>
References: <1373202811-13825-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1373202811-13825-3-git-send-email-mpa@pengutronix.de>

Both buses are not used on the phyCARD-S module. This patch moves them
to the rdk file. Remove ioexpander.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts | 13 +++++++++++++
 arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts | 18 ------------------
 2 files changed, 13 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts b/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
index 390d8f2..0514b0a 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
@@ -41,6 +41,19 @@
 	status = "okay";
 };
 
+&i2c1 {
+	status = "okay";
+
+	rtc at 51 {
+		compatible = "nxp,pcf8563";
+		reg = <0x51>;
+	};
+};
+
+&owire {
+	status = "okay";
+};
+
 &sdhci2 {
 	cd-gpios = <&gpio3 29 0>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
index cdff8c7..c8d57d1 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
@@ -33,20 +33,6 @@
 	status = "okay";
 };
 
-&i2c1 {
-	status = "okay";
-
-	ioexpander at 41 {
-		compatible = "nxp,pca9536";
-		reg = <0x41>;
-	};
-
-	rtc at 51 {
-		compatible = "nxp,pcf8563";
-		reg = <0x51>;
-	};
-};
-
 &i2c2 {
 	status = "okay";
 
@@ -56,7 +42,3 @@
 		reg = <0x52>;
 	};
 };
-
-&owire {
-	status = "okay";
-};
-- 
1.8.2.1



From mpa at pengutronix.de  Sun Jul  7 09:13:31 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Jul 2013 15:13:31 +0200
Subject: [PATCH 3/3] ARM: dts: imx27 phyCARD-S, i2c ADC device node
In-Reply-To: <1373202811-13825-1-git-send-email-mpa@pengutronix.de>
References: <1373202811-13825-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1373202811-13825-4-git-send-email-mpa@pengutronix.de>

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts b/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
index 0514b0a..5a31c77 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
@@ -34,6 +34,18 @@
 			};
 		};
 	};
+
+	regulators {
+		compatible = "simple-bus";
+
+		reg_3v3: 3v3 {
+			compatible = "regulator-fixed";
+			regulator-name = "3V3";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
+	};
 };
 
 &fb {
@@ -48,6 +60,12 @@
 		compatible = "nxp,pcf8563";
 		reg = <0x51>;
 	};
+
+	adc at 64 {
+		compatible = "maxim,max1037";
+		vcc-supply = <&reg_3v3>;
+		reg = <0x64>;
+	};
 };
 
 &owire {
-- 
1.8.2.1



From mpa at pengutronix.de  Sun Jul  7 09:13:29 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Jul 2013 15:13:29 +0200
Subject: [PATCH 1/3] ARM: dts: imx27 phyCARD-S SOM remove wrong i2c sensor
In-Reply-To: <1373202811-13825-1-git-send-email-mpa@pengutronix.de>
References: <1373202811-13825-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1373202811-13825-2-git-send-email-mpa@pengutronix.de>

This sensor was introduced in the original pca100 board file, but
phyCARD-S SOM and RDK do not have a temperature sensor.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
index 01ee807..cdff8c7 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
@@ -50,11 +50,6 @@
 &i2c2 {
 	status = "okay";
 
-	lm75 at 4a {
-		compatible = "national,lm75";
-		reg = <0x4a>;
-	};
-
 	at24 at 52 {
 		compatible = "at,24c32";
 		pagesize = <32>;
-- 
1.8.2.1



From mpa at pengutronix.de  Sun Jul  7 09:13:28 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun,  7 Jul 2013 15:13:28 +0200
Subject: [PATCH 0/3] ARM: dts: imx27 phyCARD-S I2C devices
Message-ID: <1373202811-13825-1-git-send-email-mpa@pengutronix.de>

Hi,

here are some I2C device patches for phyCARD-S.

Regards,

Markus


Markus Pargmann (3):
      ARM: dts: imx27 phyCARD-S SOM remove wrong i2c sensor
      ARM: dts: imx27 phyCARD-S, move i2c1 and owire to rdk
      ARM: dts: imx27 phyCARD-S, i2c ADC device node

 arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts | 31 ++++++++++++++++++++++++
 arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts | 23 ------------------
 2 files changed, 31 insertions(+), 23 deletions(-)



From festevam at gmail.com  Sun Jul  7 09:16:30 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sun, 7 Jul 2013 10:16:30 -0300
Subject: [alsa-devel] [PATCH v9 08/10] ASoC: Add phycore-ac97-dt driver
In-Reply-To: <20130707071949.GH16871@s25.your-server.de>
References: <1371734429-6081-1-git-send-email-mpa@pengutronix.de>
 <1371734429-6081-9-git-send-email-mpa@pengutronix.de>
 <20130703161727.GS27646@sirena.org.uk>
 <20130707071949.GH16871@s25.your-server.de>
Message-ID: <CAOMZO5CLWfoQE-9srT8e2kLn3A=iHhk-TbXytV+pdZVaaHwoNg@mail.gmail.com>

Hi Markus,

On Sun, Jul 7, 2013 at 4:19 AM, Markus Pargmann <mpa at pengutronix.de> wrote:

> There are no pinctrl driver for imx27(pca100) or imx35(pcm043). The

For mx35 pinctrl driver is at drivers/pinctrl/pinctrl-imx35.c

Regards,

Fabio Estevam


From shc_work at mail.ru  Sun Jul  7 09:20:28 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Sun, 07 Jul 2013 17:20:28 +0400
Subject: =?UTF-8?B?UmU6IFtQQVRDSF0gQVJNOiBkdHM6IGlteDogQWRkIHRoZSBtaXNzaW5nIGNw?=
 =?UTF-8?B?dXMgbm9kZQ==?=
In-Reply-To: <1373202750-10298-1-git-send-email-festevam@gmail.com>
References: <1373202750-10298-1-git-send-email-festevam@gmail.com>
Message-ID: <1373203228.792969663@f375.mail.ru>

> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> To make it consistent with the other i.mx SoCs, let's add the cpus nodes.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  arch/arm/boot/dts/imx25.dtsi | 10 ++++++++++
>  arch/arm/boot/dts/imx27.dtsi | 10 ++++++++++
>  arch/arm/boot/dts/imx31.dtsi | 10 ++++++++++
>  arch/arm/boot/dts/imx53.dtsi | 10 ++++++++++
>  4 files changed, 40 insertions(+)

i.MX27 have a CPU node already.

---

From vinod.koul at intel.com  Sun Jul  7 09:34:53 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Sun, 7 Jul 2013 19:04:53 +0530
Subject: amba-pl08x and 'get_signal' namespace collision/build error
In-Reply-To: <20130707123240.GO24642@n2100.arm.linux.org.uk>
References: <51C97F40.5030101@arm.com>
 <20130625184539.GB2718@n2100.arm.linux.org.uk>
 <20130626044842.GR23141@intel.com>
 <20130626081909.GD2718@n2100.arm.linux.org.uk>
 <20130626103930.GS23141@intel.com>
 <20130627094650.GC4283@n2100.arm.linux.org.uk>
 <CAOesGMgSPNggnBm=E3B774m7Ad_QMXdqvcGqRMxhap6dtpNtCg@mail.gmail.com>
 <20130705061802.GB10947@intel.com>
 <20130707123240.GO24642@n2100.arm.linux.org.uk>
Message-ID: <20130707133453.GC16653@intel.com>

On Sun, Jul 07, 2013 at 01:32:40PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 05, 2013 at 11:48:02AM +0530, Vinod Koul wrote:
> > On Wed, Jul 03, 2013 at 11:27:12AM -0700, Olof Johansson wrote:
> > > This has now hit the mainline kernel, and several defconfigs (nhk815,
> > > lpc32xx and the spear ones) are broken there.
> > > 
> > > Vinod, when are you sending up your pull request with the fix? It'd be
> > > good to see it go in soon.
> > It should be on its way by the weekend
> 
> It still isn't in the tree.
I sent this morning, depends on how soon can linus merge this
> 
> Personally, I think that the fix should have come via my tree, because
> the breakage was caused my the changes in my tree - and for the last week
> or more I've not been able to build any of these ARM Ltd devel platforms
> because of this bug.
> 
> It also means that I'm not able to build test a load of changes I'm
> currently working on against a recent kernel (or indeed any v3.10 kernel.)
> In other words, the lack of this patch being merged is stopping me from
> doing my job properly.  (Consider from your perspective: if I were to
> break something you relied upon for a couple of weeks, how would you
> feel about it?)
> 
> Please get this fix into mainline ASAP - even if you have to send it as a
> patch separately to Linus rather than putting it as part of your normal
> pull request.
Yes it could have gone thur your tree as well, or you could have merged my tree
to resolve your breakage

--
Thanks
~Vinod


From jason at lakedaemon.net  Sun Jul  7 10:46:45 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Sun, 7 Jul 2013 10:46:45 -0400
Subject: [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer
In-Reply-To: <alpine.DEB.2.02.1307071508030.32106@ionos.tec.linutronix.de>
References: <51B8D310.4050404@linaro.org> <51D9548B.9040907@gmail.com>
 <alpine.DEB.2.02.1307071508030.32106@ionos.tec.linutronix.de>
Message-ID: <20130707144645.GA11908@titan.lakedaemon.net>

Thomas,

On Sun, Jul 07, 2013 at 03:10:25PM +0200, Thomas Gleixner wrote:
> On Sun, 7 Jul 2013, Sebastian Hesselbarth wrote:
> > > ----------------------------------------------------------------
> > > Sebastian Hesselbarth (1):
> > >        clocksource: Add Marvell Orion SoC timer
> > 
> > with tip timers/core PR sent, I realized that the above did not make it
> > in. As we have a whole bunch of cleanup and DT conversion patches for
> 
> Opps. Fell through the cracks.

No problem.

> > v3.11-rc1 depending on it, would it be ok for you to let Jason Cooper
> > take it through his ARM sub-branch?
> 
> > If you are fine with it, I will resend the patch and note that Daniel
> > can drop it and Jason will take it.
> 
> Nah, Jason can just pull it from Daniels tree and be done with it.

Sure, but to be clear, Daniel, please drop this patch from your tree.  I
have no desire to create an out-of-tree dependency if we can avoid it.
It has a habit of going horribly wrong [1].

I'll cherry-pick

  0c1dcfd clocksource: Add Marvell Orion SoC timer

from dlezcano/timers/clockevents to get the Signed-off-by's Tested-by's,
etc.  If I could get an Acked-by from Daniel or Thomas on this, I'd
appreciate it.

Daniel, it looks like you only have cpuidle work going into linux-next.
If you do decide to include timers/clockevents, please drop the patch
before hand.

thx,

Jason.

[1] https://lkml.org/lkml/2013/2/28/725



From shc_work at mail.ru  Sun Jul  7 10:51:02 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sun,  7 Jul 2013 18:51:02 +0400
Subject: [RFC] ARM: dts: imx27: Add core voltages
Message-ID: <1373208662-7350-1-git-send-email-shc_work@mail.ru>

This patch adds core voltages for i.MX27 CPUs. Only 266 and 400 MHz modes
is documented in the datasheet, we add a 266 MHz frequency for conform this.
For 133 MHz CPU frequency minimal voltage is used (1.2V).

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27.dtsi | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index a587294..c9bacca 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -57,13 +57,15 @@
 			device_type = "cpu";
 			compatible = "arm,arm926ej-s";
 			operating-points = <
-				/* kHz  uV (No regulator support) */
-				133000  0
-				399000  0
+				/* kHz uV */
+				133000 1200000
+				266000 1300000
+				399000 1450000
 			>;
 			clock-latency = <61036>; /* two CLK32 periods */
 			clocks = <&clks 18>;
 			clock-names = "cpu";
+			voltage-tolerance = <1>;
 		};
 	};
 
-- 
1.8.1.5



From tglx at linutronix.de  Sun Jul  7 11:30:31 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sun, 7 Jul 2013 17:30:31 +0200 (CEST)
Subject: [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC
 timer
In-Reply-To: <20130707144645.GA11908@titan.lakedaemon.net>
References: <51B8D310.4050404@linaro.org> <51D9548B.9040907@gmail.com>
 <alpine.DEB.2.02.1307071508030.32106@ionos.tec.linutronix.de>
 <20130707144645.GA11908@titan.lakedaemon.net>
Message-ID: <alpine.DEB.2.02.1307071723220.32106@ionos.tec.linutronix.de>

On Sun, 7 Jul 2013, Jason Cooper wrote:
> Sure, but to be clear, Daniel, please drop this patch from your tree.  I
> have no desire to create an out-of-tree dependency if we can avoid it.
> It has a habit of going horribly wrong [1].
> 
> I'll cherry-pick
> 
>   0c1dcfd clocksource: Add Marvell Orion SoC timer

Don't do that. Do a git fetch on that branch and then git merge
0c1dcfd. The patches before that Marvel commit are already in Linus
tree. That way it does not matter who sends first or not.

We don't force others to drop stuff and cherry picking is a nuisance
as well as you end up with two different commits doing the same thing.

Also for the next merge window: Can we please let everything under
drivers/clocksoure go through Daniels and my trees?

I'm starting to be grumpy about anyone thinking that this directory is
a public dump ground with no rules.

Thanks,

	tglx






From daniel.lezcano at linaro.org  Sun Jul  7 12:45:15 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sun, 07 Jul 2013 18:45:15 +0200
Subject: [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer
In-Reply-To: <alpine.DEB.2.02.1307071723220.32106@ionos.tec.linutronix.de>
References: <51B8D310.4050404@linaro.org> <51D9548B.9040907@gmail.com>
 <alpine.DEB.2.02.1307071508030.32106@ionos.tec.linutronix.de>
 <20130707144645.GA11908@titan.lakedaemon.net>
 <alpine.DEB.2.02.1307071723220.32106@ionos.tec.linutronix.de>
Message-ID: <51D99B1B.7050106@linaro.org>

On 07/07/2013 05:30 PM, Thomas Gleixner wrote:
> On Sun, 7 Jul 2013, Jason Cooper wrote:
>> Sure, but to be clear, Daniel, please drop this patch from your tree.  I
>> have no desire to create an out-of-tree dependency if we can avoid it.
>> It has a habit of going horribly wrong [1].
>>
>> I'll cherry-pick
>>
>>   0c1dcfd clocksource: Add Marvell Orion SoC timer
> 
> Don't do that. Do a git fetch on that branch and then git merge
> 0c1dcfd. The patches before that Marvel commit are already in Linus
> tree. That way it does not matter who sends first or not.
> 
> We don't force others to drop stuff and cherry picking is a nuisance
> as well as you end up with two different commits doing the same thing.
> 
> Also for the next merge window: Can we please let everything under
> drivers/clocksoure go through Daniels and my trees?
> 
> I'm starting to be grumpy about anyone thinking that this directory is
> a public dump ground with no rules.

Yes I agree. I will meet John this week and we will sort out this and
define a clear set of rules to prevent that to happen again.

  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From pmeerw at pmeerw.net  Sun Jul  7 13:16:39 2013
From: pmeerw at pmeerw.net (Peter Meerwald)
Date: Sun,  7 Jul 2013 19:16:39 +0200
Subject: [PATCH] clk: fix typos
Message-ID: <1373217399-1541-1-git-send-email-pmeerw@pmeerw.net>

Signed-off-by: Peter Meerwald <pmeerw at pmeerw.net>
---
 drivers/clk/Kconfig |  2 +-
 drivers/clk/clk.c   | 13 +++++++------
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 51380d6..cd49096 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -27,7 +27,7 @@ config COMMON_CLK_DEBUG
 	bool "DebugFS representation of clock tree"
 	select DEBUG_FS
 	---help---
-	  Creates a directory hierchy in debugfs for visualizing the clk
+	  Creates a directory hierarchy in debugfs for visualizing the clk
 	  tree structure.  Each directory contains read-only members
 	  that export information specific to that clk node: clk_rate,
 	  clk_flags, clk_prepare_count, clk_enable_count &
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 54a191c..56a00db 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -702,7 +702,7 @@ void __clk_unprepare(struct clk *clk)
 
 /**
  * clk_unprepare - undo preparation of a clock source
- * @clk: the clk being unprepare
+ * @clk: the clk being unprepared
  *
  * clk_unprepare may sleep, which differentiates it from clk_disable.  In a
  * simple case, clk_unprepare can be used instead of clk_disable to gate a clk
@@ -869,6 +869,7 @@ EXPORT_SYMBOL_GPL(clk_enable);
 /**
  * __clk_round_rate - round the given rate for a clk
  * @clk: round the rate of this clock
+ * @rate: the rate which is to be rounded
  *
  * Caller must hold prepare_lock.  Useful for clk_ops such as .set_rate
  */
@@ -956,7 +957,7 @@ static int __clk_notify(struct clk *clk, unsigned long msg,
  *
  * Walks the subtree of clks starting with clk and recalculates rates as it
  * goes.  Note that if a clk does not implement the .recalc_rate callback then
- * it is assumed that the clock will take on the rate of it's parent.
+ * it is assumed that the clock will take on the rate of its parent.
  *
  * clk_recalc_rates also propagates the POST_RATE_CHANGE notification,
  * if necessary.
@@ -1026,7 +1027,7 @@ EXPORT_SYMBOL_GPL(clk_get_rate);
  * pre-rate change notifications and returns early if no clks in the
  * subtree have subscribed to the notifications.  Note that if a clk does not
  * implement the .recalc_rate callback then it is assumed that the clock will
- * take on the rate of it's parent.
+ * take on the rate of its parent.
  *
  * Caller must hold prepare_lock.
  */
@@ -1198,7 +1199,7 @@ static void clk_change_rate(struct clk *clk)
  * outcome of clk's .round_rate implementation.  If *parent_rate is unchanged
  * after calling .round_rate then upstream parent propagation is ignored.  If
  * *parent_rate comes back with a new rate for clk's parent then we propagate
- * up to clk's parent and set it's rate.  Upward propagation will continue
+ * up to clk's parent and set its rate.  Upward propagation will continue
  * until either a clk does not support the CLK_SET_RATE_PARENT flag or
  * .round_rate stops requesting changes to clk's parent_rate.
  *
@@ -1648,7 +1649,7 @@ int __clk_init(struct device *dev, struct clk *clk)
 	 * The .init callback is not used by any of the basic clock types, but
 	 * exists for weird hardware that must perform initialization magic.
 	 * Please consider other ways of solving initialization problems before
-	 * using this callback, as it's use is discouraged.
+	 * using this callback, as its use is discouraged.
 	 */
 	if (clk->ops->init)
 		clk->ops->init(clk->hw);
@@ -1675,7 +1676,7 @@ out:
  * very large numbers of clocks that need to be statically initialized.  It is
  * a layering violation to include clk-private.h from any code which implements
  * a clock's .ops; as such any statically initialized clock data MUST be in a
- * separate C file from the logic that implements it's operations.  Returns 0
+ * separate C file from the logic that implements its operations.  Returns 0
  * on success, otherwise an error code.
  */
 struct clk *__clk_register(struct device *dev, struct clk_hw *hw)
-- 
1.8.3.2



From olof at lixom.net  Sun Jul  7 14:05:55 2013
From: olof at lixom.net (Olof Johansson)
Date: Sun,  7 Jul 2013 11:05:55 -0700
Subject: [PATCH] dma: iop: fix new warnings
Message-ID: <1373220355-26712-1-git-send-email-olof@lixom.net>

The recent "drivers/dma: remove unused support for MEMSET operations"
change has fallout from lack of build testing by the author. This fixes:

drivers/dma/iop-adma.c:1020:13: warning: unused variable 'dma_addr' [-Wunused-variable]
drivers/dma/iop-adma.c:1519:2: warning: format '%s' expects a matching 'char *' argument [-Wformat=]

Signed-off-by: Olof Johansson <olof at lixom.net>
---
 drivers/dma/iop-adma.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
index c9cc08c..cc727ec 100644
--- a/drivers/dma/iop-adma.c
+++ b/drivers/dma/iop-adma.c
@@ -1017,7 +1017,7 @@ iop_adma_xor_val_self_test(struct iop_adma_device *device)
 	struct page *xor_srcs[IOP_ADMA_NUM_SRC_TEST];
 	struct page *zero_sum_srcs[IOP_ADMA_NUM_SRC_TEST + 1];
 	dma_addr_t dma_srcs[IOP_ADMA_NUM_SRC_TEST + 1];
-	dma_addr_t dma_addr, dest_dma;
+	dma_addr_t dest_dma;
 	struct dma_async_tx_descriptor *tx;
 	struct dma_chan *dma_chan;
 	dma_cookie_t cookie;
@@ -1516,7 +1516,7 @@ static int iop_adma_probe(struct platform_device *pdev)
 			goto err_free_iop_chan;
 	}
 
-	dev_info(&pdev->dev, "Intel(R) IOP: ( %s%s%s%s%s%s%s)\n",
+	dev_info(&pdev->dev, "Intel(R) IOP: ( %s%s%s%s%s%s)\n",
 		 dma_has_cap(DMA_PQ, dma_dev->cap_mask) ? "pq " : "",
 		 dma_has_cap(DMA_PQ_VAL, dma_dev->cap_mask) ? "pq_val " : "",
 		 dma_has_cap(DMA_XOR, dma_dev->cap_mask) ? "xor " : "",
-- 
1.7.10.4



From robherring2 at gmail.com  Sun Jul  7 15:46:36 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Sun, 7 Jul 2013 14:46:36 -0500
Subject: [PATCH v3 2/6] misc: sram: add ability to mark sram sections as
 reserved
In-Reply-To: <201307051441.27605.heiko@sntech.de>
References: <201307051440.19428.heiko@sntech.de>
 <201307051441.27605.heiko@sntech.de>
Message-ID: <CAL_JsqJDDg5Z2sN+VLArDU3vox-fLCVynkPg7Pe0LJjksXaGkw@mail.gmail.com>

On Fri, Jul 5, 2013 at 7:41 AM, Heiko St?bner <heiko at sntech.de> wrote:
> Some SoCs need parts of their sram for special purposes. So while being part
> of the periphal, it should not be part of the genpool controlling the sram.

s/periphal/peripheral/

>
> Threfore add an option mmio-sram-reserved to keep arbitary portions of the

s/Threfore/Therefore/
s/arbitary/arbitrary/

> sram from being part of the pool.
>
> Suggested-by: Rob Herring <robherring2 at gmail.com>
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
> ---
>  Documentation/devicetree/bindings/misc/sram.txt |    8 +++
>  drivers/misc/sram.c                             |   80 +++++++++++++++++++++--
>  2 files changed, 82 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
> index 4d0a00e..eae080e 100644
> --- a/Documentation/devicetree/bindings/misc/sram.txt
> +++ b/Documentation/devicetree/bindings/misc/sram.txt
> @@ -8,9 +8,17 @@ Required properties:
>
>  - reg : SRAM iomem address range
>
> +Optional properties:
> +
> +- mmio-sram-reserved: ordered list of reserved chunks inside the sram that
> +  should not become part of the genalloc pool.

genalloc is linux specific. "should not be used by the OS" would be better.

> +  Format is <base size>, <base size>, ...; with base being relative to the
> +  reg property base.
> +
>  Example:
>
>  sram: sram at 5c000000 {
>         compatible = "mmio-sram";
>         reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
> +       mmio-sram-reserved = <0x0 0x100>; /* reserve 0x5c000000-0x5c000100 */
>  };
> diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
> index afe66571..9131e4a 100644
> --- a/drivers/misc/sram.c
> +++ b/drivers/misc/sram.c
> @@ -42,6 +42,13 @@ static int sram_probe(struct platform_device *pdev)
>         struct sram_dev *sram;
>         struct resource *res;
>         unsigned long size;
> +       const __be32 *reserved_list = NULL;
> +       int reserved_size = 0;
> +       unsigned int cur_start = 0;
> +       unsigned int cur_size;
> +       unsigned int rstart;
> +       unsigned int rsize;

Use one line for each type.

> +       int i;
>         int ret;
>
>         res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -65,12 +72,73 @@ static int sram_probe(struct platform_device *pdev)
>         if (!sram->pool)
>                 return -ENOMEM;
>
> -       ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
> -                               res->start, size, -1);
> -       if (ret < 0) {
> -               if (sram->clk)
> -                       clk_disable_unprepare(sram->clk);
> -               return ret;
> +       if (pdev->dev.of_node) {
> +               reserved_list = of_get_property(pdev->dev.of_node,
> +                                               "mmio-sram-reserved",
> +                                               &reserved_size);
> +               if (reserved_list) {
> +                       reserved_size /= sizeof(*reserved_list);
> +                       if (!reserved_size || reserved_size % 2) {
> +                               dev_warn(&pdev->dev, "wrong number of arguments in mmio-sram-reserved\n");
> +                               reserved_list = NULL;
> +                       }
> +               }
> +       }
> +
> +       if (!reserved_list)
> +               reserved_size = 0;

This can be moved to where you set reserved_list to NULL.

> +
> +       for (i = 0; i < (reserved_size + 2); i += 2) {
> +               if (i < reserved_size) {

This loop is hard to follow. For example, it is not immediate obvious
why you loop an extra time. I think it would be more straight forward
to determine the free regions first and then do the allocations. This
will require a kmalloc or fixed max number of regions, but would
improve readability.

Rob

> +                       /* get the next reserved block */
> +                       rstart = be32_to_cpu(*reserved_list++);
> +                       rsize = be32_to_cpu(*reserved_list++);
> +
> +                       /* catch unsorted list entries */
> +                       if (rstart < cur_start) {
> +                               dev_err(&pdev->dev,
> +                                       "unsorted reserved list (0x%x before current 0x%x)\n",
> +                                       rstart, cur_start);
> +                               if (sram->clk)
> +                                       clk_disable_unprepare(sram->clk);
> +                               return -EINVAL;
> +                       }
> +
> +                       dev_dbg(&pdev->dev,
> +                               "found reserved block 0x%x-0x%x\n",
> +                               rstart, rstart + rsize);
> +               } else {
> +                       /* the last chunk extends to the end of the region */
> +                       rstart = size;
> +                       rsize = 0;
> +               }
> +
> +               /* current start is in a reserved block */
> +               if (rstart <= cur_start) {
> +                       cur_start = rstart + rsize;
> +                       continue;
> +               }
> +
> +               /*
> +                * allocate the space between the current starting
> +                * address and the following reserved block, or the
> +                * end of the region.
> +                */
> +               cur_size = rstart - cur_start;
> +
> +               dev_dbg(&pdev->dev, "adding chunk 0x%x-0x%x\n",
> +                       cur_start, cur_start + cur_size);
> +               ret = gen_pool_add_virt(sram->pool,
> +                               (unsigned long)virt_base + cur_start,
> +                               res->start + cur_start, cur_size, -1);
> +               if (ret < 0) {
> +                       if (sram->clk)
> +                               clk_disable_unprepare(sram->clk);
> +                       return ret;
> +               }
> +
> +               /* next allocation after this reserved block */
> +               cur_start = rstart + rsize;
>         }
>
>         platform_set_drvdata(pdev, sram);
> --
> 1.7.10.4
>


From robherring2 at gmail.com  Sun Jul  7 16:01:24 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Sun, 7 Jul 2013 15:01:24 -0500
Subject: [PATCH RFC 9/9] ARM: debug: move PL01X debug include into
 arch/arm/include/debug/
In-Reply-To: <E1UvoS8-0006IF-TE@rmk-PC.arm.linux.org.uk>
References: <20130707124326.GP24642@n2100.arm.linux.org.uk>
 <E1UvoS8-0006IF-TE@rmk-PC.arm.linux.org.uk>
Message-ID: <CAL_JsqJ_rKOKo=KoAu+bWeX3U+4jeiawQ7xBDbF18XO3_J23Uw@mail.gmail.com>

On Sun, Jul 7, 2013 at 7:52 AM, Russell King
<rmk+kernel at arm.linux.org.uk> wrote:
> Now that the PL01X debug include can mostly stand alone without
> requiring platforms to provide any macros, move it into the debug
> directory so it can be directly included.  This allows us to get rid of
> a lot of debug-macros include files.
>
> The autodetect case for Versatile Express and the ux500 are left alone;
> these are more complicated implementations.
>
> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>

Certainly a move in the right direction. For highbank:

Acked-by: Rob Herring <rob.herring at calxeda.com>


From sebastian.hesselbarth at gmail.com  Sun Jul  7 16:33:51 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Sun,  7 Jul 2013 22:33:51 +0200
Subject: [PATCH] net: mv643xx_eth: fix DT port device name
Message-ID: <1373229231-8838-1-git-send-email-sebastian.hesselbarth@gmail.com>

Device tree support added to Marvell MV643xx ethernet driver registers
port devices from port device nodes found on the corresponding controller
node. The current port device name will cause the second controller to
fail on registration because of two identical device names. This fixes
the issue by taking the device node's name also as port device name.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
Reported-by: Jonas Gorski <jogo at openwrt.org>
---
Cc: Lennert Buytenhek <buytenh at wantstofly.org>
Cc: Jonas Gorski <jogo at openwrt.org>
Cc: netdev at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 drivers/net/ethernet/marvell/mv643xx_eth.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 6495bea..1f3a03d 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2521,7 +2521,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
 		of_property_read_u32(pnp, "duplex", &ppd.duplex);
 	}
 
-	ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
+	ppdev = platform_device_alloc(pnp->name, ppd.port_number);
 	if (!ppdev)
 		return -ENOMEM;
 	ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Sun Jul  7 16:34:56 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Sun,  7 Jul 2013 22:34:56 +0200
Subject: [PATCH v7 2/7] ARM: kirkwood: add gigabit ethernet and mvmdio device
 tree nodes
In-Reply-To: <1372762824-12202-3-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762824-12202-3-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1373229296-8883-1-git-send-email-sebastian.hesselbarth@gmail.com>

This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Kirkwood boards. Phy nodes are also added with reg property set on a
per-board basis.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Changelog:
v6->v7:
- fix ethernet 1 port 0 name in kirkwood.dtsi (Reported by Jonas Gorski)

v5->v6:
- rebase for v3.11-rc1
- also convert Sheevaplug and DB628x

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: netdev at vger.kernel.org
---
 arch/arm/boot/dts/kirkwood-cloudbox.dts            |   16 ++++++
 arch/arm/boot/dts/kirkwood-db.dtsi                 |   16 ++++++
 arch/arm/boot/dts/kirkwood-dnskw.dtsi              |   16 ++++++
 arch/arm/boot/dts/kirkwood-dockstar.dts            |   17 +++++++
 arch/arm/boot/dts/kirkwood-dreamplug.dts           |   28 +++++++++++
 arch/arm/boot/dts/kirkwood-goflexnet.dts           |   16 ++++++
 .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |   30 +++++++++++
 arch/arm/boot/dts/kirkwood-ib62x0.dts              |   16 ++++++
 arch/arm/boot/dts/kirkwood-iconnect.dts            |   16 ++++++
 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts      |   24 +++++++++
 arch/arm/boot/dts/kirkwood-is2.dts                 |    2 +
 arch/arm/boot/dts/kirkwood-km_kirkwood.dts         |   16 ++++++
 arch/arm/boot/dts/kirkwood-lsxl.dtsi               |   28 +++++++++++
 arch/arm/boot/dts/kirkwood-mplcec4.dts             |   27 ++++++++++
 .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  |   16 ++++++
 arch/arm/boot/dts/kirkwood-ns2-common.dtsi         |   16 ++++++
 arch/arm/boot/dts/kirkwood-ns2.dts                 |    2 +
 arch/arm/boot/dts/kirkwood-ns2lite.dts             |    2 +
 arch/arm/boot/dts/kirkwood-ns2max.dts              |    2 +
 arch/arm/boot/dts/kirkwood-ns2mini.dts             |    2 +
 arch/arm/boot/dts/kirkwood-openblocks_a6.dts       |   16 ++++++
 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi  |   16 ++++++
 arch/arm/boot/dts/kirkwood-topkick.dts             |   16 ++++++
 arch/arm/boot/dts/kirkwood-ts219-6281.dts          |    4 +-
 arch/arm/boot/dts/kirkwood-ts219-6282.dts          |    4 +-
 arch/arm/boot/dts/kirkwood-ts219.dtsi              |   16 ++++++
 arch/arm/boot/dts/kirkwood.dtsi                    |   52 ++++++++++++++++++++
 27 files changed, 430 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-cloudbox.dts b/arch/arm/boot/dts/kirkwood-cloudbox.dts
index 00c48d2..85eed62 100644
--- a/arch/arm/boot/dts/kirkwood-cloudbox.dts
+++ b/arch/arm/boot/dts/kirkwood-cloudbox.dts
@@ -89,3 +89,19 @@
 		gpios = <&gpio0 17 0>;
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-db.dtsi b/arch/arm/boot/dts/kirkwood-db.dtsi
index c87cfb8..ca8bf36 100644
--- a/arch/arm/boot/dts/kirkwood-db.dtsi
+++ b/arch/arm/boot/dts/kirkwood-db.dtsi
@@ -87,3 +87,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 8 {
+		device_type = "ethernet-phy";
+		reg = <8>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 0afe1d0..f600ed7 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -219,3 +219,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 8 {
+		device_type = "ethernet-phy";
+		reg = <8>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-dockstar.dts b/arch/arm/boot/dts/kirkwood-dockstar.dts
index 7714742..915aca6 100644
--- a/arch/arm/boot/dts/kirkwood-dockstar.dts
+++ b/arch/arm/boot/dts/kirkwood-dockstar.dts
@@ -90,3 +90,20 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		compatible = "marvell,88e1116";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 36c7ba3..300fbf8 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -99,3 +99,31 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+
+	ethphy1: ethernet-phy at 1 {
+		device_type = "ethernet-phy";
+		reg = <1>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-goflexnet.dts b/arch/arm/boot/dts/kirkwood-goflexnet.dts
index 31caa64..e9ba68e 100644
--- a/arch/arm/boot/dts/kirkwood-goflexnet.dts
+++ b/arch/arm/boot/dts/kirkwood-goflexnet.dts
@@ -170,3 +170,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
index 1e642f3..e696c31 100644
--- a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
+++ b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
@@ -96,3 +96,33 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		compatible = "marvell,88e1121";
+		reg = <0>;
+	};
+
+	ethphy1: ethernet-phy at 1 {
+		device_type = "ethernet-phy";
+		compatible = "marvell,88e1121";
+		reg = <1>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ib62x0.dts b/arch/arm/boot/dts/kirkwood-ib62x0.dts
index 20c4b08..69019b8 100644
--- a/arch/arm/boot/dts/kirkwood-ib62x0.dts
+++ b/arch/arm/boot/dts/kirkwood-ib62x0.dts
@@ -122,3 +122,19 @@
 
 
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 8 {
+		device_type = "ethernet-phy";
+		reg = <8>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-iconnect.dts b/arch/arm/boot/dts/kirkwood-iconnect.dts
index 441204e..3d99164 100644
--- a/arch/arm/boot/dts/kirkwood-iconnect.dts
+++ b/arch/arm/boot/dts/kirkwood-iconnect.dts
@@ -176,3 +176,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 11 {
+		device_type = "ethernet-phy";
+		reg = <11>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
index 00a7bfe..b08c733 100644
--- a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
+++ b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
@@ -194,3 +194,27 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy1: ethernet-phy at 11 {
+		device_type = "ethernet-phy";
+		reg = <11>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		speed = <1000>;
+		duplex = <1>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-is2.dts b/arch/arm/boot/dts/kirkwood-is2.dts
index c3f036b..ff9be45 100644
--- a/arch/arm/boot/dts/kirkwood-is2.dts
+++ b/arch/arm/boot/dts/kirkwood-is2.dts
@@ -30,3 +30,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <8>; };
diff --git a/arch/arm/boot/dts/kirkwood-km_kirkwood.dts b/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
index 5d9f5ea..466280b 100644
--- a/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
+++ b/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
@@ -50,3 +50,19 @@
 		i2c-gpio,delay-us = <2>;	/* ~100 kHz */
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
index 31b17f5..93397b1 100644
--- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
+++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
@@ -207,3 +207,31 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+
+	ethphy1: ethernet-phy at 8 {
+		device_type = "ethernet-phy";
+		reg = <8>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-mplcec4.dts b/arch/arm/boot/dts/kirkwood-mplcec4.dts
index 6179333..def825f 100644
--- a/arch/arm/boot/dts/kirkwood-mplcec4.dts
+++ b/arch/arm/boot/dts/kirkwood-mplcec4.dts
@@ -191,3 +191,30 @@
 	};
 };
 
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 1 {
+		device_type = "ethernet-phy";
+		reg = <1>;
+	};
+
+	ethphy1: ethernet-phy at 2 {
+		device_type = "ethernet-phy";
+		reg = <2>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	ethernet1-port at 0 {
+		phy-handle = <&ethphy1>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
index ad6ade7..716b203 100644
--- a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
+++ b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
@@ -184,3 +184,19 @@
                 };
         };
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2-common.dtsi b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
index 2afac04..e7b8017 100644
--- a/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
@@ -84,3 +84,19 @@
 	};
 
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy {
+		device_type = "ethernet-phy";
+                /* overwrite reg property in board file */
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2.dts b/arch/arm/boot/dts/kirkwood-ns2.dts
index b50e93d..e93276d 100644
--- a/arch/arm/boot/dts/kirkwood-ns2.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2.dts
@@ -30,3 +30,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <8>; };
diff --git a/arch/arm/boot/dts/kirkwood-ns2lite.dts b/arch/arm/boot/dts/kirkwood-ns2lite.dts
index af8259f..34f5e69 100644
--- a/arch/arm/boot/dts/kirkwood-ns2lite.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2lite.dts
@@ -30,3 +30,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <0>; };
diff --git a/arch/arm/boot/dts/kirkwood-ns2max.dts b/arch/arm/boot/dts/kirkwood-ns2max.dts
index 85f24d2..f834c55 100644
--- a/arch/arm/boot/dts/kirkwood-ns2max.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2max.dts
@@ -49,3 +49,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <8>; };
diff --git a/arch/arm/boot/dts/kirkwood-ns2mini.dts b/arch/arm/boot/dts/kirkwood-ns2mini.dts
index 329e530..b6b66ea 100644
--- a/arch/arm/boot/dts/kirkwood-ns2mini.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2mini.dts
@@ -50,3 +50,5 @@
 		};
 	};
 };
+
+&ethphy0 { reg = <0>; };
diff --git a/arch/arm/boot/dts/kirkwood-openblocks_a6.dts b/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
index 38dc851..7235f0c 100644
--- a/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
+++ b/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
@@ -166,3 +166,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
index f7143f1..f55a145 100644
--- a/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
@@ -91,3 +91,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-topkick.dts b/arch/arm/boot/dts/kirkwood-topkick.dts
index f2052d7..184b8c5 100644
--- a/arch/arm/boot/dts/kirkwood-topkick.dts
+++ b/arch/arm/boot/dts/kirkwood-topkick.dts
@@ -203,3 +203,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy at 0 {
+		device_type = "ethernet-phy";
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6281.dts b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
index 6dd1038..222435d 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6281.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
@@ -50,4 +50,6 @@
 			gpios = <&gpio0 16 1>;
 		};
 	};
-};
\ No newline at end of file
+};
+
+&ethphy0 { reg = <8>; };
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
index 6fdc5ff..510c555 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -58,4 +58,6 @@
 			gpios = <&gpio1 5 1>;
 		};
 	};
-};
\ No newline at end of file
+};
+
+&ethphy0 { reg = <0>; };
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
index 0c9a94c..102eaeb 100644
--- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -96,3 +96,19 @@
 		};
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	ethphy0: ethernet-phy {
+		device_type = "ethernet-phy";
+                /* overwrite reg property in board file */
+	};
+};
+
+&eth0 {
+	status = "okay";
+	ethernet0-port at 0 {
+		phy-handle = <&ethphy0>;
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 9809fc1..e3f3f71 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -192,5 +192,57 @@
 			clocks = <&gate_clk 17>;
 			status = "okay";
 		};
+
+		mdio: mdio-bus at 72004 {
+			compatible = "marvell,orion-mdio";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x72004 0x84>;
+			interrupts = <46>;
+			clocks = <&gate_clk 0>;
+			status = "disabled";
+
+			/* add phy nodes in board file */
+		};
+
+		eth0: ethernet-controller at 72000 {
+			compatible = "marvell,kirkwood-eth";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x72000 0x4000>;
+			clocks = <&gate_clk 0>;
+			marvell,tx-checksum-limit = <1600>;
+			status = "disabled";
+
+			ethernet0-port at 0 {
+				device_type = "network";
+				compatible = "marvell,kirkwood-eth-port";
+				reg = <0>;
+				interrupts = <11>;
+				/* overwrite MAC address in bootloader */
+				local-mac-address = [00 00 00 00 00 00];
+				/* set phy-handle property in board file */
+			};
+		};
+
+		eth1: ethernet-controller at 76000 {
+			compatible = "marvell,kirkwood-eth";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x76000 0x4000>;
+			clocks = <&gate_clk 19>;
+			marvell,tx-checksum-limit = <1600>;
+			status = "disabled";
+
+			ethernet1-port at 0 {
+				device_type = "network";
+				compatible = "marvell,kirkwood-eth-port";
+				reg = <0>;
+				interrupts = <15>;
+				/* overwrite MAC address in bootloader */
+				local-mac-address = [00 00 00 00 00 00];
+				/* set phy-handle property in board file */
+			};
+		};
 	};
 };
-- 
1.7.10.4



From cb at sgoc.de  Sun Jul  7 17:19:20 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Sun, 7 Jul 2013 23:19:20 +0200 (CEST)
Subject: [PATCH 0/3] Added support for On Chip OTP in i.MX23/28
In-Reply-To: <20130705073807.GE2959@lukather>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
 <20130705073807.GE2959@lukather>
Message-ID: <1172644674.734029.1373231961041.open-xchange@email.1und1.de>

Hello Maxime,

thanks for all your hints. My approach on porting the Freescale code may have
been a bit too straight forward.
I will do some refactoring and try to follow your comments.


Regards
Christoph


From emilio at elopez.com.ar  Sun Jul  7 17:31:55 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Sun,  7 Jul 2013 18:31:55 -0300
Subject: [PATCH 0/4] A10S-OLinuXino-Micro I2C support
Message-ID: <1373232719-13050-1-git-send-email-emilio@elopez.com.ar>

Hi,

This patchset adds the required DT nodes to get I2C supported and 
working on the OLIMEX A10S-OLinuXino-Micro board.

Patch 1 adds the muxings as seen on the board's schematics. Patch 2 adds 
the DT nodes, based on other sunxi dts, as we don't have an A10S user 
manual so far. Patch 3 enables the controllers, and patch 4 adds a node 
for the AT24 EEPROM found on the board.

I have tested and can see the PMU on I2C-0 using i2cdetect, and can read 
the EEPROM contents on I2C-1. I have not tested I2C-2, but i2cdetect 
reports no devices so I suppose it's working okay too.

Any testing or review will be appreciated :)

Thanks,

Emilio

Emilio L?pez (4):
  ARM: sun5i: dt: Add I2C muxings for sun5i A10S
  ARM: sun5i: dt: Add I2C controller nodes to the A10S dtsi
  ARM: sun5i: dt: Enable I2C controllers on A10S-OLinuXino-Micro
  ARM: sun5i: dt: Add AT24 device on A10S-OLinuXino-Micro

 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 25 +++++++++++
 arch/arm/boot/dts/sun5i-a10s.dtsi                | 54 ++++++++++++++++++++++++
 2 files changed, 79 insertions(+)

-- 
1.8.3.2



From emilio at elopez.com.ar  Sun Jul  7 17:31:56 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Sun,  7 Jul 2013 18:31:56 -0300
Subject: [PATCH 1/4] ARM: sun5i: dt: Add I2C muxings for sun5i A10S
In-Reply-To: <1373232719-13050-1-git-send-email-emilio@elopez.com.ar>
References: <1373232719-13050-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1373232719-13050-2-git-send-email-emilio@elopez.com.ar>

The information has been extracted from the A10S-OLinuXino-Micro
schematics, as we do not have a user manual for A10S yet.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 arch/arm/boot/dts/sun5i-a10s.dtsi | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 2307ce8..7c9f88f 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -229,6 +229,27 @@
 				allwinner,drive = <0>;
 				allwinner,pull = <0>;
 			};
+
+			i2c0_pins_a: i2c0 at 0 {
+				allwinner,pins = "PB0", "PB1";
+				allwinner,function = "i2c0";
+				allwinner,drive = <0>;
+				allwinner,pull = <0>;
+			};
+
+			i2c1_pins_a: i2c1 at 0 {
+				allwinner,pins = "PB15", "PB16";
+				allwinner,function = "i2c1";
+				allwinner,drive = <0>;
+				allwinner,pull = <0>;
+			};
+
+			i2c2_pins_a: i2c2 at 0 {
+				allwinner,pins = "PB17", "PB18";
+				allwinner,function = "i2c2";
+				allwinner,drive = <0>;
+				allwinner,pull = <0>;
+			};
 		};
 
 		timer at 01c20c00 {
-- 
1.8.3.2



From emilio at elopez.com.ar  Sun Jul  7 17:31:57 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Sun,  7 Jul 2013 18:31:57 -0300
Subject: [PATCH 2/4] ARM: sun5i: dt: Add I2C controller nodes to the A10S dtsi
In-Reply-To: <1373232719-13050-1-git-send-email-emilio@elopez.com.ar>
References: <1373232719-13050-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1373232719-13050-3-git-send-email-emilio@elopez.com.ar>

Allwinner A10S has 3 I2C controllers embedded on it. Add them to the
corresponding dtsi.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 arch/arm/boot/dts/sun5i-a10s.dtsi | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 7c9f88f..0f0881a 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -303,5 +303,38 @@
 			clocks = <&apb1_gates 19>;
 			status = "disabled";
 		};
+
+		i2c0: i2c at 01c2ac00 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "allwinner,sun4i-i2c";
+			reg = <0x01c2ac00 0x400>;
+			interrupts = <7>;
+			clocks = <&apb1_gates 0>;
+			clock-frequency = <100000>;
+			status = "disabled";
+		};
+
+		i2c1: i2c at 01c2b000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "allwinner,sun4i-i2c";
+			reg = <0x01c2b000 0x400>;
+			interrupts = <8>;
+			clocks = <&apb1_gates 1>;
+			clock-frequency = <100000>;
+			status = "disabled";
+		};
+
+		i2c2: i2c at 01c2b400 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "allwinner,sun4i-i2c";
+			reg = <0x01c2b400 0x400>;
+			interrupts = <9>;
+			clocks = <&apb1_gates 2>;
+			clock-frequency = <100000>;
+			status = "disabled";
+		};
 	};
 };
-- 
1.8.3.2



From emilio at elopez.com.ar  Sun Jul  7 17:31:58 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Sun,  7 Jul 2013 18:31:58 -0300
Subject: [PATCH 3/4] ARM: sun5i: dt: Enable I2C controllers on
 A10S-OLinuXino-Micro
In-Reply-To: <1373232719-13050-1-git-send-email-emilio@elopez.com.ar>
References: <1373232719-13050-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1373232719-13050-4-git-send-email-emilio@elopez.com.ar>

This board from OLIMEX is using the three I2C controllers present on A10S:
  * I2C-0 connects to the AXP152 PMU
  * I2C-1 holds an AT24C16BN-SH EEPROM with the MAC address for ethernet
  * I2C-2 is used for UEXT modules.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index 64dc0c4..2a69ddf 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -60,6 +60,24 @@
 			pinctrl-0 = <&uart3_pins_a>;
 			status = "okay";
 		};
+
+		i2c0: i2c at 01c2ac00 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&i2c0_pins_a>;
+			status = "okay";
+		};
+
+		i2c1: i2c at 01c2b000 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&i2c1_pins_a>;
+			status = "okay";
+		};
+
+		i2c2: i2c at 01c2b400 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&i2c2_pins_a>;
+			status = "okay";
+		};
 	};
 
 	leds {
-- 
1.8.3.2



From emilio at elopez.com.ar  Sun Jul  7 17:31:59 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Sun,  7 Jul 2013 18:31:59 -0300
Subject: [PATCH 4/4] ARM: sun5i: dt: Add AT24 device on A10S-OLinuXino-Micro
In-Reply-To: <1373232719-13050-1-git-send-email-emilio@elopez.com.ar>
References: <1373232719-13050-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1373232719-13050-5-git-send-email-emilio@elopez.com.ar>

This OLIMEX board has a AT24C16BN-SH EEPROM holding the MAC address.
This patch adds the corresponding device tree node to reflect this.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index 2a69ddf..8ce7951 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -71,6 +71,13 @@
 			pinctrl-names = "default";
 			pinctrl-0 = <&i2c1_pins_a>;
 			status = "okay";
+
+			at24 at 50 {
+				compatible = "at,24c16";
+				pagesize = <16>;
+				reg = <0x50>;
+				read-only;
+			};
 		};
 
 		i2c2: i2c at 01c2b400 {
-- 
1.8.3.2



From jogo at openwrt.org  Sun Jul  7 17:43:41 2013
From: jogo at openwrt.org (Jonas Gorski)
Date: Sun, 7 Jul 2013 23:43:41 +0200
Subject: [PATCH] net: mv643xx_eth: fix DT port device name
In-Reply-To: <1373229231-8838-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1373229231-8838-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130707234341.0000721b@unknown>

On Sun,  7 Jul 2013 22:33:51 +0200
Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> wrote:

> Device tree support added to Marvell MV643xx ethernet driver registers
> port devices from port device nodes found on the corresponding controller
> node. The current port device name will cause the second controller to
> fail on registration because of two identical device names. This fixes
> the issue by taking the device node's name also as port device name.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> Reported-by: Jonas Gorski <jogo at openwrt.org>
> ---
> Cc: Lennert Buytenhek <buytenh at wantstofly.org>
> Cc: Jonas Gorski <jogo at openwrt.org>
> Cc: netdev at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  drivers/net/ethernet/marvell/mv643xx_eth.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index 6495bea..1f3a03d 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -2521,7 +2521,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
>  		of_property_read_u32(pnp, "duplex", &ppd.duplex);
>  	}
>  
> -	ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
> +	ppdev = platform_device_alloc(pnp->name, ppd.port_number);
>  	if (!ppdev)
>  		return -ENOMEM;
>  	ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);

This breaks ethernet completely, as there is no platform driver
registered for pnp->name ("ethernetX-port"), only for MV643XX_ETH_NAME.

Also since I didn't see a patch for it and no mentioning of it:

There's still one further issue from having two ethernet-ports with
port_number 0, it causes a device leak:

static struct platform_device *port_platdev[3];

mv643xx_eth_shared_of_add_port()
{
	...
	port_platdev[ppd.port_number] = ppdev;
	...
}

The second port at 0 will overwrite the first and thus will never be
deleted in

mv643xx_eth_shared_of_remove()
{
	...
	for (n = 0; n < 3; n++) {
		platform_device_del(port_platdev[n]);
		port_platdev[n] = NULL;
	}
}

I doubt a insmod-rmmod-insmod will go well in that case ;-)


Regards
Jonas


From sebastian.hesselbarth at gmail.com  Sun Jul  7 17:58:49 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Sun, 07 Jul 2013 23:58:49 +0200
Subject: [PATCH] net: mv643xx_eth: fix DT port device name
In-Reply-To: <20130707234341.0000721b@unknown>
References: <1373229231-8838-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130707234341.0000721b@unknown>
Message-ID: <51D9E499.5000801@gmail.com>

On 07/07/2013 11:43 PM, Jonas Gorski wrote:
> On Sun,  7 Jul 2013 22:33:51 +0200
> Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>  wrote:
>
>> Device tree support added to Marvell MV643xx ethernet driver registers
>> port devices from port device nodes found on the corresponding controller
>> node. The current port device name will cause the second controller to
>> fail on registration because of two identical device names. This fixes
>> the issue by taking the device node's name also as port device name.
>>
>> Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth at gmail.com>
>> Reported-by: Jonas Gorski<jogo at openwrt.org>
>> ---
>> Cc: Lennert Buytenhek<buytenh at wantstofly.org>
>> Cc: Jonas Gorski<jogo at openwrt.org>
>> Cc: netdev at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> ---
>>   drivers/net/ethernet/marvell/mv643xx_eth.c |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
>> index 6495bea..1f3a03d 100644
>> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
>> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
>> @@ -2521,7 +2521,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
>>   		of_property_read_u32(pnp, "duplex",&ppd.duplex);
>>   	}
>>
>> -	ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
>> +	ppdev = platform_device_alloc(pnp->name, ppd.port_number);
>>   	if (!ppdev)
>>   		return -ENOMEM;
>>   	ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>
> This breaks ethernet completely, as there is no platform driver
> registered for pnp->name ("ethernetX-port"), only for MV643XX_ETH_NAME.

Jonas,

I asked you to test the above earlier today. You said this would fix
the issue. I have no Kirkwood board with two ethernet's available, so
I really needed on your help here.

Please prepare a patch yourself, that fixes the issue.

Sebastian

> Also since I didn't see a patch for it and no mentioning of it:
>
> There's still one further issue from having two ethernet-ports with
> port_number 0, it causes a device leak:
>
> static struct platform_device *port_platdev[3];
>
> mv643xx_eth_shared_of_add_port()
> {
> 	...
> 	port_platdev[ppd.port_number] = ppdev;
> 	...
> }
>
> The second port at 0 will overwrite the first and thus will never be
> deleted in
>
> mv643xx_eth_shared_of_remove()
> {
> 	...
> 	for (n = 0; n<  3; n++) {
> 		platform_device_del(port_platdev[n]);
> 		port_platdev[n] = NULL;
> 	}
> }
>
> I doubt a insmod-rmmod-insmod will go well in that case ;-)
>
>
> Regards
> Jonas



From jogo at openwrt.org  Sun Jul  7 18:05:40 2013
From: jogo at openwrt.org (Jonas Gorski)
Date: Mon, 8 Jul 2013 00:05:40 +0200
Subject: [PATCH] net: mv643xx_eth: fix DT port device name
In-Reply-To: <20130707234341.0000721b@unknown>
References: <1373229231-8838-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130707234341.0000721b@unknown>
Message-ID: <20130708000540.00004b37@unknown>

On Sun, 7 Jul 2013 23:43:41 +0200
Jonas Gorski <jogo at openwrt.org> wrote:

> On Sun,  7 Jul 2013 22:33:51 +0200
> Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> wrote:
> 
> > Device tree support added to Marvell MV643xx ethernet driver registers
> > port devices from port device nodes found on the corresponding controller
> > node. The current port device name will cause the second controller to
> > fail on registration because of two identical device names. This fixes
> > the issue by taking the device node's name also as port device name.
> > 
> > Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> > Reported-by: Jonas Gorski <jogo at openwrt.org>
> > ---
> > Cc: Lennert Buytenhek <buytenh at wantstofly.org>
> > Cc: Jonas Gorski <jogo at openwrt.org>
> > Cc: netdev at vger.kernel.org
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: linux-kernel at vger.kernel.org
> > ---
> >  drivers/net/ethernet/marvell/mv643xx_eth.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> > index 6495bea..1f3a03d 100644
> > --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> > +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> > @@ -2521,7 +2521,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
> >  		of_property_read_u32(pnp, "duplex", &ppd.duplex);
> >  	}
> >  
> > -	ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
> > +	ppdev = platform_device_alloc(pnp->name, ppd.port_number);
> >  	if (!ppdev)
> >  		return -ENOMEM;
> >  	ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> 
> This breaks ethernet completely, as there is no platform driver
> registered for pnp->name ("ethernetX-port"), only for MV643XX_ETH_NAME.

Looking back at our conversation, this is my fault.
I actually did not change this part as you asked, but I saw the
alloc/del issue with port 0, then added the counter and also only
replaced the ppd.port_number in the alloc with it. I had completely
forgotten at that time to replace the device name; else I would
have caught it back then.

I only caught it now because I tried your patch and wondered why there
wasn't anything registered, not because I saw the problem by review.

Sorry for that.

Regards
Jonas


From jogo at openwrt.org  Sun Jul  7 18:44:55 2013
From: jogo at openwrt.org (Jonas Gorski)
Date: Mon,  8 Jul 2013 00:44:55 +0200
Subject: [PATCH] net: mv643xx_eth: do not use port number as platform device id
In-Reply-To: <51D9E499.5000801@gmail.com>
References: <51D9E499.5000801@gmail.com>
Message-ID: <1373237095-28989-1-git-send-email-jogo@openwrt.org>

The port number is only local to the ethernet block, not global, so
there can be two ethernet blocks both using the same port, like
kirkwood with both using port 0.

Fix this by using the array index offset for the allocated platform
devices as the id.

Signed-off-by: Jonas Gorski <jogo at openwrt.org>
---
 drivers/net/ethernet/marvell/mv643xx_eth.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 6495bea..c35db73 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2483,6 +2483,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
 	struct resource res;
 	const char *mac_addr;
 	int ret;
+	int dev_num = 0;
 
 	memset(&ppd, 0, sizeof(ppd));
 	ppd.shared = pdev;
@@ -2503,6 +2504,14 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
 		return -EINVAL;
 	}
 
+	while (dev_num < 3 && port_platdev[dev_num])
+		dev_num++;
+
+	if (dev_num == 3) {
+		dev_err(&pdev->dev, "too many ports registered\n");
+		return -EINVAL;
+	}
+
 	mac_addr = of_get_mac_address(pnp);
 	if (mac_addr)
 		memcpy(ppd.mac_addr, mac_addr, 6);
@@ -2521,7 +2530,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
 		of_property_read_u32(pnp, "duplex", &ppd.duplex);
 	}
 
-	ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
+	ppdev = platform_device_alloc(MV643XX_ETH_NAME, dev_num);
 	if (!ppdev)
 		return -ENOMEM;
 	ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
@@ -2538,7 +2547,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
 	if (ret)
 		goto port_err;
 
-	port_platdev[ppd.port_number] = ppdev;
+	port_platdev[dev_num] = ppdev;
 
 	return 0;
 
-- 
1.8.3.2



From rmallon at gmail.com  Sun Jul  7 19:18:10 2013
From: rmallon at gmail.com (Ryan Mallon)
Date: Mon, 08 Jul 2013 09:18:10 +1000
Subject: [RFC PATCH 0/9] Clean up debugging support
In-Reply-To: <20130707124326.GP24642@n2100.arm.linux.org.uk>
References: <20130707124326.GP24642@n2100.arm.linux.org.uk>
Message-ID: <51D9F732.6010206@gmail.com>

On 07/07/13 22:43, Russell King - ARM Linux wrote:
> This patch series cleans up some aspects of the LL debug support by:
> 
> - Removing the multi-level choice madness
> - Consolidating the 8250 debug UART support
> - Consolidating the PL01x debug UART support
> 
> The differences between the various 8250 debug UART implementations are:
> - Physical/Virtual addresses
> - Register offset shift
> - Access size
> - Flow control
> 

>  arch/arm/mach-ep93xx/include/mach/debug-macro.S    |   21 -

For ep93xx bits:

Acked-by: Ryan Mallon <rmallon at gmail.com>



From jason at lakedaemon.net  Sun Jul  7 19:58:19 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Sun, 7 Jul 2013 19:58:19 -0400
Subject: [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer
In-Reply-To: <alpine.DEB.2.02.1307071723220.32106@ionos.tec.linutronix.de>
References: <51B8D310.4050404@linaro.org> <51D9548B.9040907@gmail.com>
 <alpine.DEB.2.02.1307071508030.32106@ionos.tec.linutronix.de>
 <20130707144645.GA11908@titan.lakedaemon.net>
 <alpine.DEB.2.02.1307071723220.32106@ionos.tec.linutronix.de>
Message-ID: <20130707235819.GB11908@titan.lakedaemon.net>

On Sun, Jul 07, 2013 at 05:30:31PM +0200, Thomas Gleixner wrote:
> On Sun, 7 Jul 2013, Jason Cooper wrote:
> > Sure, but to be clear, Daniel, please drop this patch from your tree.  I
> > have no desire to create an out-of-tree dependency if we can avoid it.
> > It has a habit of going horribly wrong [1].
> > 
> > I'll cherry-pick
> > 
> >   0c1dcfd clocksource: Add Marvell Orion SoC timer
> 
> Don't do that. Do a git fetch on that branch and then git merge
> 0c1dcfd.

> The patches before that Marvel commit are already in Linus tree. That
> way it does not matter who sends first or not.

ahh, ok.  I see your point now, thanks.

Daniel, do you mind tagging that commit, eg 'mvebu-deps-3.12' or
similar?

> Also for the next merge window: Can we please let everything under
> drivers/clocksoure go through Daniels and my trees?

Of course, that's what I've been encouraging:

http://permalink.gmane.org/gmane.linux.ports.arm.kernel/242342

""" Using Thomas Petazzoni's quoting style here :)

Is there a reason why the following breakdown wouldn't work?

>  arch/arm/boot/dts/armada-370-xp.dtsi     |   1 +
>  arch/arm/boot/dts/armada-370.dtsi        |   1 +
>  arch/arm/boot/dts/armada-xp-mv78230.dtsi |   1 +
>  arch/arm/boot/dts/armada-xp-mv78260.dtsi |   1 +
>  arch/arm/boot/dts/armada-xp-mv78460.dtsi |   1 +

through mvebu/arm-soc

>  arch/arm/mach-mvebu/Kconfig              |   1 +

through mvebu/arm-soc after the other three have landed (v3.11-rc1)

>  drivers/irqchip/irq-armada-370-xp.c      | 186 ++++++++++++++++++++++++++++++-

through tglx

>  drivers/pci/host/pci-mvebu.c             |  21 ++++
>  drivers/pci/msi.c                        |  59 +++++++++-
>  drivers/pci/probe.c                      |   1 +
>  include/linux/msi.h                      |  22 ++++
>  include/linux/pci.h                      |   1 +

through Bjorn

I think we should view the manner in which we brought in the initial
mvebu-pcie series (all through arm-soc) as the exception, not the rule.
I have no problem, and in fact, prefer to have them reviewed as a
series, but if at *all* possible, the series should be structured so
relevant maintainers can pick up the relevant patches into their trees.

""" End quote

There's a delicate three-way balance between pushing patches that we
depend on to the appropriate maintainers, avoiding out-of-tree
dependencies for arm-soc, and keeping the ball moving.

I don't mind delaying half of a series so the drivers/ portion can land
in mainline, and the rest can land in the next cycle.  But when things
don't go according to that plan, I'd like a little consideration /
flexibility about solving the problem.  Especially considering I'm
*trying* to do the right thing by pushing to appropriate maintainers
first.

Of course, this is a moot point since, as you clarified above, this
dependency doesn't have the hazards typically associated with
out-of-tree dependencies.

thx,

Jason.


From jason at lakedaemon.net  Sun Jul  7 20:04:01 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Sun, 7 Jul 2013 20:04:01 -0400
Subject: [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer
In-Reply-To: <51D99B1B.7050106@linaro.org>
References: <51B8D310.4050404@linaro.org> <51D9548B.9040907@gmail.com>
 <alpine.DEB.2.02.1307071508030.32106@ionos.tec.linutronix.de>
 <20130707144645.GA11908@titan.lakedaemon.net>
 <alpine.DEB.2.02.1307071723220.32106@ionos.tec.linutronix.de>
 <51D99B1B.7050106@linaro.org>
Message-ID: <20130708000401.GC11908@titan.lakedaemon.net>

On Sun, Jul 07, 2013 at 06:45:15PM +0200, Daniel Lezcano wrote:
> On 07/07/2013 05:30 PM, Thomas Gleixner wrote:
> > On Sun, 7 Jul 2013, Jason Cooper wrote:
> >> Sure, but to be clear, Daniel, please drop this patch from your tree.  I
> >> have no desire to create an out-of-tree dependency if we can avoid it.
> >> It has a habit of going horribly wrong [1].
> >>
> >> I'll cherry-pick
> >>
> >>   0c1dcfd clocksource: Add Marvell Orion SoC timer
> > 
> > Don't do that. Do a git fetch on that branch and then git merge
> > 0c1dcfd. The patches before that Marvel commit are already in Linus
> > tree. That way it does not matter who sends first or not.
> > 
> > We don't force others to drop stuff and cherry picking is a nuisance
> > as well as you end up with two different commits doing the same thing.
> > 
> > Also for the next merge window: Can we please let everything under
> > drivers/clocksoure go through Daniels and my trees?
> > 
> > I'm starting to be grumpy about anyone thinking that this directory is
> > a public dump ground with no rules.
> 
> Yes I agree. I will meet John this week and we will sort out this and
> define a clear set of rules to prevent that to happen again.

Oh god no!  The rules we have are fine.  "Defer to the appropriate
maintainer first."  Which I did (that's why the patch is in your tree
;-) ).  A mistake happened, and we're working together to find the best
solution.

The last thing we need is more bureaucratic crap.

thx,

Jason.


From B29397 at freescale.com  Sun Jul  7 21:21:53 2013
From: B29397 at freescale.com (Chen Peter-B29397)
Date: Mon, 8 Jul 2013 01:21:53 +0000
Subject: Chipidea usb otg support for IMX/MXS (device functionality)
In-Reply-To: <201307070310.00973.marex@denx.de>
References: <51A5A808.2070803@digi.com> <201306281142.51676.marex@denx.de>
 <F281D0F91ED19E4D8E63A7504E8A649803EFF551@039-SN2MPN1-023.039d.mgd.msft.net>
 <201307070310.00973.marex@denx.de>
Message-ID: <F281D0F91ED19E4D8E63A7504E8A649803F28763@039-SN2MPN1-021.039d.mgd.msft.net>

 

> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: Sunday, July 07, 2013 9:10 AM
> To: Chen Peter-B29397
> Cc: shawn.guo at linaro.org; Michael Grzeschik; maxime.ripard at free-
> electrons.com; Hector Palacios; linux-usb at vger.kernel.org;
> s.hauer at pengutronix.de; alexander.shishkin at linux.intel.com; Estevam
> Fabio-R49496; Marc Kleine-Budde; m.grzeschik at pengutronix.de; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: Chipidea usb otg support for IMX/MXS (device functionality)
> 
> Hi Peter,
> 
> > > Where can I measure this?
> > >
> > > > Two possible reasons:
> > > >
> > > > 1. You have not gpio control for vbus toggle when role switches.
> > >
> > > This works well.
> > >
> > > > 2. Your hardware has some problems that the vbus can't lower than
> 0.8v.
> > >
> > > How can I check that?
> >
> > Just measure the voltage of your otg vbus pin.
> 
> It's 2.5 volt for me. What am I supposed to observe happening there?
> 

http://marc.info/?l=linux-usb&m=137242465920952&w=2


Best regards,
Peter



From shawn.guo at linaro.org  Sun Jul  7 21:27:31 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Jul 2013 09:27:31 +0800
Subject: [PATCH] ARM: dts: imx: Add the missing cpus node
In-Reply-To: <1373203228.792969663@f375.mail.ru>
References: <1373202750-10298-1-git-send-email-festevam@gmail.com>
 <1373203228.792969663@f375.mail.ru>
Message-ID: <20130708012729.GA21594@S2101-09.ap.freescale.net>

On Sun, Jul 07, 2013 at 05:20:28PM +0400, Alexander Shiyan wrote:
> > From: Fabio Estevam <fabio.estevam at freescale.com>
> > 
> > To make it consistent with the other i.mx SoCs, let's add the cpus nodes.
> > 
> > Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> > ---
> >  arch/arm/boot/dts/imx25.dtsi | 10 ++++++++++
> >  arch/arm/boot/dts/imx27.dtsi | 10 ++++++++++
> >  arch/arm/boot/dts/imx31.dtsi | 10 ++++++++++
> >  arch/arm/boot/dts/imx53.dtsi | 10 ++++++++++
> >  4 files changed, 40 insertions(+)
> 
> i.MX27 have a CPU node already.

Applied with imx27.dtsi changes left out.

Shawn



From mturquette at linaro.org  Sun Jul  7 21:44:26 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Sun,  7 Jul 2013 18:44:26 -0700
Subject: [PATCH RFC 1/3] clk: notifier handler for dynamic voltage scaling
In-Reply-To: <1373247868-21444-1-git-send-email-mturquette@linaro.org>
References: <1373247868-21444-1-git-send-email-mturquette@linaro.org>
Message-ID: <1373247868-21444-2-git-send-email-mturquette@linaro.org>

This patch provides helper functions for drivers that wish to scale
voltage through the clock rate-change notifiers. The approach taken is
that the driver does not care about the details of the OPP table, nor
does it care about handling the voltage regulator directly. The driver
only has a pointer to the struct clk object; the other details are
hidden in the helper functions.

The assumptions about DT structure mostly come from the cpufreq-cpu0
binding. Since this is a helper function it does not have a binding
document of its own.

A similar patch using platform data instead of DT was proposed in
February[1].

[1] http://patches.linaro.org/15128/

Signed-off-by: Mike Turquette <mturquette at linaro.org>
---
 drivers/clk/Makefile               |   1 +
 drivers/clk/clk-voltage-notifier.c | 135 +++++++++++++++++++++++++++++++++++++
 include/linux/clk.h                |   7 +-
 3 files changed, 142 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/clk-voltage-notifier.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d3c3733..beb39f1 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_COMMON_CLK)	+= clk-fixed-rate.o
 obj-$(CONFIG_COMMON_CLK)	+= clk-gate.o
 obj-$(CONFIG_COMMON_CLK)	+= clk-mux.o
 obj-$(CONFIG_COMMON_CLK)	+= clk-composite.o
+obj-$(CONFIG_COMMON_CLK)	+= clk-voltage-notifier.o
 
 # SoCs specific
 obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
diff --git a/drivers/clk/clk-voltage-notifier.c b/drivers/clk/clk-voltage-notifier.c
new file mode 100644
index 0000000..cb6b85f
--- /dev/null
+++ b/drivers/clk/clk-voltage-notifier.c
@@ -0,0 +1,135 @@
+/*
+ * Copyright (C) 2013 Linaro Ltd <mturquette at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Helper functions for registering clock rate-change notifier handlers
+ * that scale voltage when a clock changes its output frequency.
+ */
+
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/notifier.h>
+#include <linux/of.h>
+#include <linux/opp.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+
+struct volt_scale_data {
+	struct device *dev;
+	struct clk *clk;
+	struct regulator *reg;
+	int tol;
+	struct notifier_block nb;
+};
+
+#define to_volt_scale_data(_nb) container_of(_nb, \
+		struct volt_scale_data, nb)
+
+static int clk_volt_notifier_handler(struct notifier_block *nb,
+		unsigned long flags, void *data)
+{
+	struct clk_notifier_data *cnd = data;
+	struct volt_scale_data *vsd = to_volt_scale_data(nb);
+	int ret, new_volt, old_volt, tol;
+	struct opp *opp;
+	unsigned long old_rate = cnd->old_rate;
+	unsigned long new_rate = cnd->new_rate;
+
+	rcu_read_lock();
+	opp = opp_find_freq_ceil(vsd->dev, &new_rate);
+	if (IS_ERR(opp)) {
+		rcu_read_unlock();
+		dev_err(vsd->dev, "%s: failed to find OPP for %lu\n",
+				__func__, new_rate);
+		return notifier_from_errno(PTR_ERR(opp));
+	}
+	new_volt = opp_get_voltage(opp);
+	rcu_read_unlock();
+
+	tol = new_volt * vsd->tol / 100;
+	old_volt = regulator_get_voltage(vsd->reg);
+
+	/* scaling up? scale voltage before frequency */
+	if (new_rate > old_rate) {
+		ret = regulator_set_voltage_tol(vsd->reg, new_volt, tol);
+		if (ret) {
+			dev_err(vsd->dev, "%s: failed to scale voltage up: %d\n",
+					__func__, ret);
+			return notifier_from_errno(ret);
+		}
+	}
+
+	/* scaling down? scale voltage after frequency */
+	if (new_rate < old_rate) {
+		ret = regulator_set_voltage_tol(vsd->reg, new_volt, tol);
+		if (ret) {
+			dev_err(vsd->dev, "%s: failed to scale voltage down: %d\n",
+					__func__, ret);
+			return notifier_from_errno(ret);
+		}
+	}
+
+	return NOTIFY_OK;
+}
+
+/**
+ * of_clk_volt_notifier_register - register clock notifier to scale voltage
+ * @dev: device that scales clock and voltage regulator
+ * @np: pointer to DeviceTree node
+ * @supply: regulator id string
+ */
+struct notifier_block *of_clk_volt_notifier_register(struct device *dev,
+		struct device_node *np, struct clk *clk, const char *supply,
+		int *voltage_latency)
+{
+	struct volt_scale_data *vsd;
+	int ret;
+
+	vsd = kzalloc(sizeof(struct volt_scale_data), GFP_KERNEL);
+	if (!vsd)
+		return ERR_PTR(-ENOMEM);
+
+	vsd->dev = dev;
+	vsd->clk = clk;
+	vsd->nb.notifier_call = clk_volt_notifier_handler;
+
+	vsd->reg = devm_regulator_get(dev, supply);
+	if (IS_ERR(vsd->reg)) {
+		ret = PTR_ERR(vsd->reg);
+		goto err_free_vsd;
+	}
+
+	of_property_read_u32(np, "voltage-tolerance", &vsd->tol);
+
+	ret = of_init_opp_table(dev);
+	if (ret) {
+		pr_err("%s: failed to init OPP table: %d\n", __func__, ret);
+		goto err_free_vsd;
+	}
+
+	ret = clk_notifier_register(clk, &vsd->nb);
+
+	if (ret)
+		goto err_free_vsd;
+
+	return &vsd->nb;
+
+err_free_vsd:
+	kfree(vsd);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(of_clk_volt_notifier_register);
+
+void of_clk_volt_notifier_unregister(struct notifier_block *nb)
+{
+	struct volt_scale_data *vsd = to_volt_scale_data(nb);
+	struct clk *clk = vsd->clk;
+
+	clk_notifier_unregister(clk, nb);
+	kfree(vsd);
+}
+EXPORT_SYMBOL_GPL(of_clk_volt_notifier_unregister);
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 9a6d045..85ea520 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -15,6 +15,8 @@
 #include <linux/err.h>
 #include <linux/kernel.h>
 #include <linux/notifier.h>
+#include <linux/cpufreq.h>
+#include <linux/device.h>
 
 struct device;
 
@@ -79,8 +81,11 @@ struct clk_notifier_data {
 };
 
 int clk_notifier_register(struct clk *clk, struct notifier_block *nb);
-
 int clk_notifier_unregister(struct clk *clk, struct notifier_block *nb);
+struct notifier_block *of_clk_volt_notifier_register(struct device *dev,
+		struct device_node *np, struct clk *clk, const char *supply,
+		int *voltage_latency);
+void of_clk_volt_notifier_unregister(struct notifier_block *nb);
 
 #endif
 
-- 
1.8.1.2



From mturquette at linaro.org  Sun Jul  7 21:44:28 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Sun,  7 Jul 2013 18:44:28 -0700
Subject: [PATCH RFC 3/3] cpufreq: cpufreq-cpu0: clk rate-change notifiers
In-Reply-To: <1373247868-21444-1-git-send-email-mturquette@linaro.org>
References: <1373247868-21444-1-git-send-email-mturquette@linaro.org>
Message-ID: <1373247868-21444-4-git-send-email-mturquette@linaro.org>

Removes direct handling of OPP tables and voltage regulators by calling
of_clk_cpufreq_notifier_handler, introduced by commit "clk: cpufreq
helper for voltage scaling".

In the future this can help consolidate code found across similar
CPUfreq drivers.

Signed-off-by: Mike Turquette <mturquette at linaro.org>
---
 drivers/cpufreq/cpufreq-cpu0.c | 125 ++++++++---------------------------------
 1 file changed, 22 insertions(+), 103 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..1e8f928 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -16,18 +16,15 @@
 #include <linux/err.h>
 #include <linux/module.h>
 #include <linux/of.h>
-#include <linux/opp.h>
 #include <linux/platform_device.h>
-#include <linux/regulator/consumer.h>
 #include <linux/slab.h>
 
 static unsigned int transition_latency;
-static unsigned int voltage_tolerance; /* in percentage */
 
 static struct device *cpu_dev;
 static struct clk *cpu_clk;
-static struct regulator *cpu_reg;
 static struct cpufreq_frequency_table *freq_table;
+static struct notifier_block *clk_nb;
 
 static int cpu0_verify_speed(struct cpufreq_policy *policy)
 {
@@ -43,8 +40,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
 			   unsigned int target_freq, unsigned int relation)
 {
 	struct cpufreq_freqs freqs;
-	struct opp *opp;
-	unsigned long volt = 0, volt_old = 0, tol = 0;
+	unsigned long volt = 0, volt_old = 0;
 	long freq_Hz, freq_exact;
 	unsigned int index;
 	int ret;
@@ -69,56 +65,16 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
 
 	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
 
-	if (cpu_reg) {
-		rcu_read_lock();
-		opp = opp_find_freq_ceil(cpu_dev, &freq_Hz);
-		if (IS_ERR(opp)) {
-			rcu_read_unlock();
-			pr_err("failed to find OPP for %ld\n", freq_Hz);
-			freqs.new = freqs.old;
-			ret = PTR_ERR(opp);
-			goto post_notify;
-		}
-		volt = opp_get_voltage(opp);
-		rcu_read_unlock();
-		tol = volt * voltage_tolerance / 100;
-		volt_old = regulator_get_voltage(cpu_reg);
-	}
-
 	pr_debug("%u MHz, %ld mV --> %u MHz, %ld mV\n",
 		 freqs.old / 1000, volt_old ? volt_old / 1000 : -1,
 		 freqs.new / 1000, volt ? volt / 1000 : -1);
 
-	/* scaling up?  scale voltage before frequency */
-	if (cpu_reg && freqs.new > freqs.old) {
-		ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
-		if (ret) {
-			pr_err("failed to scale voltage up: %d\n", ret);
-			freqs.new = freqs.old;
-			goto post_notify;
-		}
-	}
-
 	ret = clk_set_rate(cpu_clk, freq_exact);
 	if (ret) {
 		pr_err("failed to set clock rate: %d\n", ret);
-		if (cpu_reg)
-			regulator_set_voltage_tol(cpu_reg, volt_old, tol);
 		freqs.new = freqs.old;
-		goto post_notify;
-	}
-
-	/* scaling down?  scale voltage after frequency */
-	if (cpu_reg && freqs.new < freqs.old) {
-		ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
-		if (ret) {
-			pr_err("failed to scale voltage down: %d\n", ret);
-			clk_set_rate(cpu_clk, freqs.old * 1000);
-			freqs.new = freqs.old;
-		}
 	}
 
-post_notify:
 	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
 
 	return ret;
@@ -175,6 +131,7 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
 static int cpu0_cpufreq_probe(struct platform_device *pdev)
 {
 	struct device_node *np, *parent;
+	unsigned int voltage_latency;
 	int ret;
 
 	parent = of_find_node_by_path("/cpus");
@@ -197,22 +154,6 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
 	cpu_dev = &pdev->dev;
 	cpu_dev->of_node = np;
 
-	cpu_reg = devm_regulator_get(cpu_dev, "cpu0");
-	if (IS_ERR(cpu_reg)) {
-		/*
-		 * If cpu0 regulator supply node is present, but regulator is
-		 * not yet registered, we should try defering probe.
-		 */
-		if (PTR_ERR(cpu_reg) == -EPROBE_DEFER) {
-			dev_err(cpu_dev, "cpu0 regulator not ready, retry\n");
-			ret = -EPROBE_DEFER;
-			goto out_put_node;
-		}
-		pr_warn("failed to get cpu0 regulator: %ld\n",
-			PTR_ERR(cpu_reg));
-		cpu_reg = NULL;
-	}
-
 	cpu_clk = devm_clk_get(cpu_dev, NULL);
 	if (IS_ERR(cpu_clk)) {
 		ret = PTR_ERR(cpu_clk);
@@ -220,60 +161,38 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
 		goto out_put_node;
 	}
 
-	ret = of_init_opp_table(cpu_dev);
-	if (ret) {
-		pr_err("failed to init OPP table: %d\n", ret);
-		goto out_put_node;
-	}
-
-	ret = opp_init_cpufreq_table(cpu_dev, &freq_table);
-	if (ret) {
-		pr_err("failed to init cpufreq table: %d\n", ret);
-		goto out_put_node;
-	}
-
-	of_property_read_u32(np, "voltage-tolerance", &voltage_tolerance);
-
 	if (of_property_read_u32(np, "clock-latency", &transition_latency))
 		transition_latency = CPUFREQ_ETERNAL;
 
-	if (cpu_reg) {
-		struct opp *opp;
-		unsigned long min_uV, max_uV;
-		int i;
-
-		/*
-		 * OPP is maintained in order of increasing frequency, and
-		 * freq_table initialised from OPP is therefore sorted in the
-		 * same order.
-		 */
-		for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
-			;
-		rcu_read_lock();
-		opp = opp_find_freq_exact(cpu_dev,
-				freq_table[0].frequency * 1000, true);
-		min_uV = opp_get_voltage(opp);
-		opp = opp_find_freq_exact(cpu_dev,
-				freq_table[i-1].frequency * 1000, true);
-		max_uV = opp_get_voltage(opp);
-		rcu_read_unlock();
-		ret = regulator_set_voltage_time(cpu_reg, min_uV, max_uV);
-		if (ret > 0)
-			transition_latency += ret * 1000;
+	clk_nb = of_clk_cpufreq_notifier_register(cpu_dev, np, cpu_clk, "cpu0",
+			&freq_table, &voltage_latency);
+
+	if (IS_ERR(clk_nb)) {
+		ret = PTR_ERR(clk_nb);
+		/* defer probe if regulator is not yet registered */
+		if (ret == -EPROBE_DEFER)
+			dev_err(cpu_dev, "cpu0 clock notifier not ready, retry\n");
+		else
+			dev_err(cpu_dev, "failed to register cpu0 clock notifier: %d\n",
+					ret);
+		goto out_put_node;
 	}
 
+	if (voltage_latency > 0)
+		transition_latency += voltage_latency;
+
 	ret = cpufreq_register_driver(&cpu0_cpufreq_driver);
 	if (ret) {
 		pr_err("failed register driver: %d\n", ret);
-		goto out_free_table;
+		goto out_notifier_unregister;
 	}
 
 	of_node_put(np);
 	of_node_put(parent);
 	return 0;
 
-out_free_table:
-	opp_free_cpufreq_table(cpu_dev, &freq_table);
+out_notifier_unregister:
+	of_clk_cpufreq_notifier_unregister(clk_nb, freq_table);
 out_put_node:
 	of_node_put(np);
 out_put_parent:
@@ -283,8 +202,8 @@ out_put_parent:
 
 static int cpu0_cpufreq_remove(struct platform_device *pdev)
 {
+	of_clk_cpufreq_notifier_unregister(clk_nb, freq_table);
 	cpufreq_unregister_driver(&cpu0_cpufreq_driver);
-	opp_free_cpufreq_table(cpu_dev, &freq_table);
 
 	return 0;
 }
-- 
1.8.1.2



From mturquette at linaro.org  Sun Jul  7 21:44:27 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Sun,  7 Jul 2013 18:44:27 -0700
Subject: [PATCH RFC 2/3] clk: cpufreq helper for voltage scaling
In-Reply-To: <1373247868-21444-1-git-send-email-mturquette@linaro.org>
References: <1373247868-21444-1-git-send-email-mturquette@linaro.org>
Message-ID: <1373247868-21444-3-git-send-email-mturquette@linaro.org>

This patch builds on "clk: notifier handler for dynamic voltage scaling"
by adding a CPUfreq-specific helper function for registering a clock
rate-change notifier to scale regulator voltage as a function of clock
rate.

In particular this patch creates an instance of struct
cpufreq_frequency_table and also calculate the voltage scaling latency,
both of which are returned to the caller for use in the CPUfreq driver.

Signed-off-by: Mike Turquette <mturquette at linaro.org>
---
 drivers/clk/clk-voltage-notifier.c | 71 ++++++++++++++++++++++++++++++++++++++
 include/linux/clk.h                |  6 ++++
 2 files changed, 77 insertions(+)

diff --git a/drivers/clk/clk-voltage-notifier.c b/drivers/clk/clk-voltage-notifier.c
index cb6b85f..8e1707f 100644
--- a/drivers/clk/clk-voltage-notifier.c
+++ b/drivers/clk/clk-voltage-notifier.c
@@ -10,6 +10,7 @@
  */
 
 #include <linux/clk.h>
+#include <linux/cpufreq.h>
 #include <linux/device.h>
 #include <linux/module.h>
 #include <linux/notifier.h>
@@ -133,3 +134,73 @@ void of_clk_volt_notifier_unregister(struct notifier_block *nb)
 	kfree(vsd);
 }
 EXPORT_SYMBOL_GPL(of_clk_volt_notifier_unregister);
+
+void of_clk_cpufreq_notifier_unregister(struct notifier_block *nb,
+		struct cpufreq_frequency_table *freq_table)
+{
+	struct volt_scale_data *data = to_volt_scale_data(nb);
+	struct device *dev = data->dev;
+
+	opp_free_cpufreq_table(dev, &freq_table);
+	of_clk_volt_notifier_unregister(nb);
+}
+EXPORT_SYMBOL_GPL(of_clk_cpufreq_notifier_unregister);
+
+/**
+ * of_clk_cpufreq_notifer_register - register clock notifier to scale voltage
+ * @dev: device that owns this scaling operation
+ * @np: pointer to device's DT node
+ * @clk: clock whose rate-change notifier triggers voltage scaling
+ * @supply: regulator id string
+ * @freq_table: pointer to uninitialized CPUfreq frequency scaling table
+ * @voltage_latency: worst case voltage scaling latency
+ */
+struct notifier_block *of_clk_cpufreq_notifier_register(struct device *dev,
+		struct device_node *np, struct clk *clk, const char *supply,
+		struct cpufreq_frequency_table **table,
+		unsigned int *voltage_latency)
+{
+	struct notifier_block *nb;
+	struct volt_scale_data *vsd;
+	struct opp *opp;
+	unsigned long min, max;
+	int ret, i;
+
+	nb = of_clk_volt_notifier_register(dev, np, clk, supply,
+			voltage_latency);
+	if (IS_ERR(nb))
+		return nb;
+
+	vsd = to_volt_scale_data(nb);
+
+	ret = opp_init_cpufreq_table(dev, table);
+	if (ret) {
+		pr_err("failed to init cpufreq table: %d\n", ret);
+		goto err_unregister;
+	}
+
+	/* find the min and max voltages and compute worst-case latency */
+	for (i = 0; table[0][i].frequency != CPUFREQ_TABLE_END; i++)
+		;
+
+	rcu_read_lock();
+	opp = opp_find_freq_exact(dev,
+			table[0][0].frequency * 1000, true);
+	min = opp_get_voltage(opp);
+	opp = opp_find_freq_exact(dev,
+			table[0][i-1].frequency * 1000, true);
+	max = opp_get_voltage(opp);
+	rcu_read_unlock();
+
+	*voltage_latency = regulator_set_voltage_time(vsd->reg, min, max);
+	if (*voltage_latency < 0)
+		pr_warn("%s: failed to calculate voltage latency, %d\n",
+				__func__, ret);
+
+	return nb;
+
+err_unregister:
+	of_clk_volt_notifier_unregister(nb);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(of_clk_cpufreq_notifier_register);
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 85ea520..3104883 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -86,6 +86,12 @@ struct notifier_block *of_clk_volt_notifier_register(struct device *dev,
 		struct device_node *np, struct clk *clk, const char *supply,
 		int *voltage_latency);
 void of_clk_volt_notifier_unregister(struct notifier_block *nb);
+struct notifier_block *of_clk_cpufreq_notifier_register(struct device *dev,
+		struct device_node *np, struct clk *clk, const char *supply,
+		struct cpufreq_frequency_table **table,
+		unsigned int *voltage_latency);
+void of_clk_cpufreq_notifier_unregister(struct notifier_block *nb,
+		struct cpufreq_frequency_table *freq_table);
 
 #endif
 
-- 
1.8.1.2



From mturquette at linaro.org  Sun Jul  7 21:44:25 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Sun,  7 Jul 2013 18:44:25 -0700
Subject: [PATCH RFC 0/3] voltage scaling via clock rate-change notifiers
Message-ID: <1373247868-21444-1-git-send-email-mturquette@linaro.org>

Scaling regulator voltage as a function of clock frequency is a common
power saving technique. It is often referred to as dynamic voltage &
frequency scaling (DVFS). The common clock framework has clock
rate-change notifier (pre & post) which provide a convenient hook for
scaling voltage whenever clk_set_rate is called.

The first patch in the series provides helper functions for drivers that
wish to scale voltage through the clock rate-change notifiers. The
approach taken is that the driver does not care about the details of the
OPP table, nor does it care about handling the voltage regulator
directly. The driver only has a pointer to the struct clk object; the
other details are hidden in the helper functions.

The second patch provides a CPUfreq-centric helper, built on top of the
first one. This is primarly to help with the struct
cpufreq_frequency_table bits and latency calculation.

The final patch in the series converts the cpufreq-cpu0 driver to use
these functions. Other cpufreq drivers can be converted later.

There are not many cases of DVFS usage in the kernel; vendors often keep
these out-of-tree. By providing a common approach using the clock rate
change notifiers this series hopes to consolidate code across drivers
and encourage vendors to upstream their DVFS bits.

Mike Turquette (3):
  clk: notifier handler for dynamic voltage scaling
  clk: cpufreq helper for voltage scaling
  cpufreq: cpufreq-cpu0: clk rate-change notifiers

 drivers/clk/Makefile               |   1 +
 drivers/clk/clk-voltage-notifier.c | 206 +++++++++++++++++++++++++++++++++++++
 drivers/cpufreq/cpufreq-cpu0.c     | 125 ++++------------------
 include/linux/clk.h                |  13 ++-
 4 files changed, 241 insertions(+), 104 deletions(-)
 create mode 100644 drivers/clk/clk-voltage-notifier.c

-- 
1.8.1.2



From shawn.guo at linaro.org  Sun Jul  7 21:53:50 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Jul 2013 09:53:50 +0800
Subject: [RFC] ARM: dts: imx27: Add core voltages
In-Reply-To: <1373208662-7350-1-git-send-email-shc_work@mail.ru>
References: <1373208662-7350-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130708015348.GB21594@S2101-09.ap.freescale.net>

On Sun, Jul 07, 2013 at 06:51:02PM +0400, Alexander Shiyan wrote:
> This patch adds core voltages for i.MX27 CPUs. Only 266 and 400 MHz modes
> is documented in the datasheet, we add a 266 MHz frequency for conform this.
> For 133 MHz CPU frequency minimal voltage is used (1.2V).
> 
Ok, just checked i.MX27 data sheet, it seems that only 266 and 400 MHz
set points are officially supported.  So there is no documented voltage
for 133 MHz.  I'm wondering if we should have 133 MHz set point at all
if it's not officially supported.

Shawn

> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  arch/arm/boot/dts/imx27.dtsi | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
> index a587294..c9bacca 100644
> --- a/arch/arm/boot/dts/imx27.dtsi
> +++ b/arch/arm/boot/dts/imx27.dtsi
> @@ -57,13 +57,15 @@
>  			device_type = "cpu";
>  			compatible = "arm,arm926ej-s";
>  			operating-points = <
> -				/* kHz  uV (No regulator support) */
> -				133000  0
> -				399000  0
> +				/* kHz uV */
> +				133000 1200000
> +				266000 1300000
> +				399000 1450000
>  			>;
>  			clock-latency = <61036>; /* two CLK32 periods */
>  			clocks = <&clks 18>;
>  			clock-names = "cpu";
> +			voltage-tolerance = <1>;
>  		};
>  	};
>  
> -- 
> 1.8.1.5
> 



From shawn.guo at linaro.org  Sun Jul  7 21:54:20 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Jul 2013 09:54:20 +0800
Subject: [PATCH 0/3] ARM: dts: imx27 phyCARD-S I2C devices
In-Reply-To: <1373202811-13825-1-git-send-email-mpa@pengutronix.de>
References: <1373202811-13825-1-git-send-email-mpa@pengutronix.de>
Message-ID: <20130708015419.GC21594@S2101-09.ap.freescale.net>

On Sun, Jul 07, 2013 at 03:13:28PM +0200, Markus Pargmann wrote:
> Markus Pargmann (3):
>       ARM: dts: imx27 phyCARD-S SOM remove wrong i2c sensor
>       ARM: dts: imx27 phyCARD-S, move i2c1 and owire to rdk
>       ARM: dts: imx27 phyCARD-S, i2c ADC device node

All applied, thanks.



From jg1.han at samsung.com  Sun Jul  7 22:04:06 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Mon, 08 Jul 2013 11:04:06 +0900
Subject: [PATCH V4 4/4] video: exynos_dp: Use the generic PHY driver
In-Reply-To: <1441230.DzaqAQ9HHT@flatron>
References: <000d01ce7700$222a35a0$667ea0e0$@samsung.com>
 <1441230.DzaqAQ9HHT@flatron>
Message-ID: <001a01ce7b7f$6d7bdc60$48739520$@samsung.com>

On Saturday, July 06, 2013 8:04 AM, Tomasz Figa wrote:
> 
> Hi Jingoo,
> 
> On Tuesday 02 of July 2013 17:42:49 Jingoo Han wrote:
> > Use the generic PHY API instead of the platform callback to control
> > the DP PHY.
> >
> > Signed-off-by: Jingoo Han <jg1.han at samsung.com>
> > ---
> >  .../devicetree/bindings/video/exynos_dp.txt        |   23
> > +++++--------------- drivers/video/exynos/exynos_dp_core.c
> > |   16 ++++++++++---- drivers/video/exynos/exynos_dp_core.h
> >  |    2 ++
> >  3 files changed, 20 insertions(+), 21 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
> > b/Documentation/devicetree/bindings/video/exynos_dp.txt index
> > 84f10c1..022f4b6 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> > @@ -1,17 +1,6 @@
> >  The Exynos display port interface should be configured based on
> >  the type of panel connected to it.
> >
> > -We use two nodes:
> > -	-dp-controller node
> > -	-dptx-phy node(defined inside dp-controller node)
> > -
> > -For the DP-PHY initialization, we use the dptx-phy node.
> > -Required properties for dptx-phy:
> > -	-reg:
> > -		Base address of DP PHY register.
> > -	-samsung,enable-mask:
> > -		The bit-mask used to enable/disable DP PHY.
> > -
> 
> I wonder if this part shouldn't stay here, just marked as deprecated,
> because compatibility with old dtbs must be preserved (and rest of the
> patch looks like it is).

I would like to remove these properties from Documentation.
But, I will mark it as deprecated as you suggested..


Best regards,
Jingoo Han




From voice.shen at atmel.com  Sun Jul  7 22:01:25 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Mon, 8 Jul 2013 10:01:25 +0800
Subject: [RFC PATCH 08/13] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <CACQ1gAji8KkjXee8o=9jt8O38611LBJ95yXimxbfn1qLaLOcnA@mail.gmail.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-9-git-send-email-richard.genoud@gmail.com>
 <51D2472B.2010407@atmel.com>
 <CACQ1gAji8KkjXee8o=9jt8O38611LBJ95yXimxbfn1qLaLOcnA@mail.gmail.com>
Message-ID: <51DA1D75.2010503@atmel.com>

Hi Richard,

On 7/5/2013 23:15, Richard Genoud wrote:
>>> +       card->dev = &pdev->dev;
>>> >>+       card->owner = THIS_MODULE;
>>> >>+       card->dai_link = dai;
>>> >>+       card->num_links = 1;
>>> >>+       dai->name = "WM8731";
>>> >>+       dai->stream_name = "WM8731 PCM";
>>> >>+       dai->codec_dai_name = "wm8731-hifi";
>>> >>+       dai->init = at91sam9x5ek_wm8731_init;
>>> >>+       card->dapm_widgets = at91sam9x5ek_dapm_widgets;
>>> >>+       card->num_dapm_widgets = ARRAY_SIZE(at91sam9x5ek_dapm_widgets);
>> >
>> >
>> >Will keep these as snd_soc_card and snd_soc_dai_link structure separately?
> I don't really understand what you mean here.
> do you mean that something like that will more explicit ? :
> +       card->dai_link[0].name = "WM8731";
> +       card->dai_link[0].stream_name = "WM8731 PCM";
> +       card->dai_link[0].codec_dai_name = "wm8731-hifi";
> +       card->dai_link[0].init = at91sam9x5ek_wm8731_init;
>

I mean using structure to define snd_soc_card and snd_soc_dai_link, look 
like:
struct snd_soc_dai_link dai_link_name = {
	.name = xxx,
	.stream_name = xxx,
	...
};

struct snd_soc_card card_name = {
	.name = xxxx
	.ower = THIS_MODULE,
	.dai_link = &dai_link_name,
	...
};

In this way, I think it will be more clear than put them in code.

Best Regards,
Bo Shen


From shinya.kuribayashi.px at renesas.com  Sun Jul  7 22:24:25 2013
From: shinya.kuribayashi.px at renesas.com (Shinya Kuribayashi)
Date: Mon, 08 Jul 2013 11:24:25 +0900
Subject: [PATCH] ARM: shmobile: r8a7790 SMP prototype v3
In-Reply-To: <20130701061340.22064.93012.sendpatchset@w520>
References: <20130701061340.22064.93012.sendpatchset@w520>
Message-ID: <51DA22D9.10703@renesas.com>

Magnus,

Thanks for the patch, see my comments below.

On 7/1/2013 3:13 PM, Magnus Damm wrote:
> --- /dev/null
> +++ work/arch/arm/mach-shmobile/smp-r8a7790.c	2013-07-01 13:41:32.000000000 +0900
> @@ -0,0 +1,187 @@

> +#define SYSC	0xe6180000
> +#define SYSCSR  0x0000
> +
> +#define RST	0xe6160000
> +#define CA15BAR	0x6020

CA15BAR and CA15BAR2 addresses in the datasheet v0.5 are simply wrong;
they should be 0x0020 and 0x0024, respectively.

You could confirm it in the documentation errata for v0.5 or in the
latest datasheet v0.6 release.

I believe that this is not related to an uncertain arch_timer issue you
mentioned in the commit log, but we should use proper addresses at least.

> +#define CA15RESCNT 0x0040
> +#define CA7BAR	0x4030

The same applies for CA7BAR and CA7BAR2 as well.

> +#define CA7RESCNT 0x0044
> +#define RESCNT	0x0050
> +
> +#define APMU	0xe6150000
> +#define CA15WUPCR 0x2010
> +#define CA7WUPCR 0x1010
> +
> +#define MERAM	0xe8080000
> +
> +enum { R8A7790_CLST_CA15, R8A7790_CLST_CA7, R8A7790_CLST_NR };
> +
> +static struct {
> +	unsigned int cabar;
> +	unsigned int carescnt;
> +	unsigned int carescnt_magic;
> +	unsigned int rescnt_bit;
> +	unsigned int use_count;
> +} r8a7790_clst[R8A7790_CLST_NR] = {
> +	[R8A7790_CLST_CA15] = {
> +		.cabar = CA15BAR,
> +		.carescnt = CA15RESCNT,
> +		.carescnt_magic = 0xa5a50000,
> +		.rescnt_bit = 1,
> +	},
> +	[R8A7790_CLST_CA7] = {
> +		.cabar = CA7BAR,
> +		.carescnt = CA7RESCNT,
> +		.carescnt_magic = 0x5a5a0000,
> +		.rescnt_bit = 0,
> +	},
> +};
> +
> +#define r8a7790_clst_id(cpu) (cpu_logical_map((cpu)) >> 8)
> +#define r8a7790_cpu_id(cpu) (cpu_logical_map((cpu)) & 0xff)
> +
> +static void r8a7790_deassert_reset(unsigned int cpu)
> +{
> +	void __iomem *p, *carescnt;
> +	u32 bar, mask, magic;
> +	unsigned int clst_id = r8a7790_clst_id(cpu);
> +
> +	/* setup reset vectors */
> +	p = ioremap_nocache(RST, 0x7000);

Therefore ioremap size for RST should be updated accordingly.

> +	bar = (MERAM >> 8) & 0xfffffc00;
> +	__raw_writel(bar, p + r8a7790_clst[clst_id].cabar);
> +	__raw_writel(bar | 0x10, p + r8a7790_clst[clst_id].cabar);
> +
> +	/* enable clocks for cluster */
> +	if (r8a7790_clst[clst_id].use_count++ == 0) {
> +		mask = 1 << r8a7790_clst[clst_id].rescnt_bit;
> +		__raw_writel(__raw_readl(p + RESCNT) & ~mask, p + RESCNT);
> +	}
> +
> +	/* enable per-core clocks */
> +	mask = BIT(3 - r8a7790_cpu_id(cpu));
> +	magic = r8a7790_clst[clst_id].carescnt_magic;
> +	carescnt = p + r8a7790_clst[clst_id].carescnt;
> +	__raw_writel((__raw_readl(carescnt) & ~mask) | magic, carescnt);
> +
> +	iounmap(p);
> +}
> +
> +static void r8a7790_assert_reset(unsigned int cpu)
> +{
> +	void __iomem *p, *carescnt;
> +	u32 mask, magic;
> +	unsigned int clst_id = r8a7790_clst_id(cpu);
> +
> +	p = ioremap_nocache(RST, 0x7000);

Ditto.
--
Shinya Kuribayashi
Renesas Electronics


From minggr at gmail.com  Sun Jul  7 22:27:15 2013
From: minggr at gmail.com (Lin Ming)
Date: Mon, 08 Jul 2013 10:27:15 +0800
Subject: kernel decompressor problem for ARMv7
In-Reply-To: <CAF1ivSbOXknHyDMH3RdmSGK2n5o2wVeR5oohCQnZ2gJrgvo=Hw@mail.gmail.com>
References: <CAF1ivSakn8-HiAf+4_cLRWUUTDP9QBKpAt+hVQoMyAmKZ2-dJA@mail.gmail.com>
 <20130705095757.GA13063@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1307051225240.18597@syhkavp.arg>
 <CAF1ivSbOXknHyDMH3RdmSGK2n5o2wVeR5oohCQnZ2gJrgvo=Hw@mail.gmail.com>
Message-ID: <1373250435.824.6.camel@minggr>

On Sat, 2013-07-06 at 00:58 +0800, Lin Ming wrote:
> On Sat, Jul 6, 2013 at 12:30 AM, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> > On Fri, 5 Jul 2013, Will Deacon wrote:
> >
> >> On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
> >> > Hi all,
> >>
> >> Hello,
> >>
> >> > I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.
> >>
> >> Which specific processor/SoC?
> >>
> >> > But decompressor doesn't work. With a lot of debug, I finally find
> >> > below 2 commits related.
> >> > Kernel uncompress OK with these commits reverted.
> >> >
> >> > dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
> >> > (Introduced in v3.6-rc6)
> >> >
> >> > 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
> >> > v6 and above
> >> > (Introduced in v3.7-rc8)
> >> >
> >> > Any hint to fix it?
> >>
> >> There's not really enough information to go on here. What specifically
> >> fails? Also, do you have to revert *both* of the above changes to get things
> >> working again?
> >
> > Also, what is the bootloader used here?
> 
> uboot.
> 
> >
> > Does the bootloader call the kernel with the MMU off as documented in
> > Documentation/arm/Booting?
> 
> How to check this?
> 
> I'll check uboot code or add debug code in boot/compressed/head.S to
> check it next Monday.

I added below debug code to print the control reg from lowest 4bits to
highest 4bits.

It prints "B7805C". So the control reg is 0x00c5087b.
Seems bootloader calls the kernel with MMU enabled and Alignment fault
checking enabled.

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 32337ff..9434720 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -125,6 +125,23 @@
 		.rept	7
 		mov	r0, r0
 		.endr
+
+		/* Dirty debug code to print control reg from lowest 4bits to highest 4bits */
+		ldr     r2, =0xf0070120		@ UART
+		mrc     p15, 0, r0, c1, c0, 0   @ read control reg
+	1:
+		cmp     r0, #0
+		beq	2f
+		and     r1, r0, #15
+		cmp	r1, #9
+		addgt	r1, r1, #7
+		add	r1, r1, #48
+		str     r1, [r2]
+		asr     r0, r0, #4
+		b	1b
+	2:
+
+
    ARM(		mov	r0, r0		)
    ARM(		b	1f		)
  THUMB(		adr	r12, BSYM(1f)	)


> 
> >
> > Nicolas




From shawn.guo at linaro.org  Sun Jul  7 22:33:06 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Jul 2013 10:33:06 +0800
Subject: [PATCH] ARM: dts: i.MX51: Add WEIM node
In-Reply-To: <1373094142-24173-1-git-send-email-shc_work@mail.ru>
References: <1373094142-24173-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130708023304.GA22636@S2101-09.ap.freescale.net>

On Sat, Jul 06, 2013 at 11:02:22AM +0400, Alexander Shiyan wrote:
> This patch adds the missing (Wireless External Interface Module) WEIM
> devicetree node for i.MX51 CPUs.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  arch/arm/boot/dts/imx51.dtsi | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
> index 0ca62be..e71976e4 100644
> --- a/arch/arm/boot/dts/imx51.dtsi
> +++ b/arch/arm/boot/dts/imx51.dtsi
> @@ -745,6 +745,23 @@
>  				status = "disabled";
>  			};
>  
> +			weim: weim at 83fda000 {
> +				#address-cells = <2>;
> +				#size-cells = <1>;
> +				compatible = "fsl,imx51-weim";
> +				reg = <0x83fda000 0x1000>;
> +				clocks = <&clks 0>;

Is it correct?  I think there should be a physical clock for weim.

Shawn

> +				ranges = <
> +					0 0 0xb0000000 0x08000000
> +					1 0 0xb8000000 0x08000000
> +					2 0 0xc0000000 0x08000000
> +					3 0 0xc8000000 0x04000000
> +					4 0 0xcc000000 0x02000000
> +					5 0 0xce000000 0x02000000
> +				>;
> +				status = "disabled";
> +			};
> +
>  			nfc: nand at 83fdb000 {
>  				compatible = "fsl,imx51-nand";
>  				reg = <0x83fdb000 0x1000 0xcfff0000 0x10000>;
> -- 
> 1.8.1.5
> 



From B18965 at freescale.com  Sun Jul  7 22:39:00 2013
From: B18965 at freescale.com (Wang Huan-B18965)
Date: Mon, 8 Jul 2013 02:39:00 +0000
Subject: [PATCH 4/4] fb: Add DCU framebuffer driver for Vybrid VF610
 platform
In-Reply-To: <20130706060453.GE30164@S2101-09.ap.freescale.net>
References: <1373010702-9244-1-git-send-email-b18965@freescale.com>
 <1373010702-9244-5-git-send-email-b18965@freescale.com>
 <20130706060453.GE30164@S2101-09.ap.freescale.net>
Message-ID: <81BA6E5E0BC2344391CABCEE22D1B6D8393343@039-SN1MPN1-002.039d.mgd.msft.net>

Hi, Shawn,

> On Fri, Jul 05, 2013 at 03:51:42PM +0800, Alison Wang wrote:
> > The Display Controller Unit (DCU) module is a system master that
> > fetches graphics stored in internal or external memory and displays
> > them on a TFT LCD panel. A wide range of panel sizes is supported and
> > the timing of the interface signals is highly configurable.
> > Graphics are read directly from memory and then blended in real-time,
> > which allows for dynamic content creation with minimal CPU
> intervention.
> >
> > The features:
> >
> > (1) Full RGB888 output to TFT LCD panel.
> > (2) For the current LCD panel, WQVGA "480x272" is supported.
> > (3) Blending of each pixel using up to 4 source layers dependent on
> size of panel.
> > (4) Each graphic layer can be placed with one pixel resolution in
> either axis.
> > (5) Each graphic layer support RGB565 and RGB888 direct colors
> without
> > alpha channel and BGRA8888 direct colors with an alpha channel.
> > (6) Each graphic layer support alpha blending with 8-bit resolution.
> >
> > This driver has been tested on Vybrid VF610 TOWER board.
> >
> > Signed-off-by: Alison Wang <b18965 at freescale.com>
> > ---
> >  drivers/video/Kconfig      |    9 +
> >  drivers/video/Makefile     |    1 +
> >  drivers/video/fsl-dcu-fb.c | 1091
> > ++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 1101 insertions(+)
> >  create mode 100644 drivers/video/fsl-dcu-fb.c
> 
> You should have a document under Documentation/devicetree/bindings/fb/.
> 
[Alison Wang] Ok, I will add a document in the next version. Thanks!


Best Regards,
Alison Wang



From shawn.guo at linaro.org  Sun Jul  7 22:42:15 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Jul 2013 10:42:15 +0800
Subject: [PATCH v3 4/6] ARM: dts: imx6q{dl}: fix the wrong RTS/CTS pad name
In-Reply-To: <20953.22066.706534.773272@ipc1.ka-ro>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>
 <1373004752-21302-5-git-send-email-b32955@freescale.com>
 <20130706050803.GC30164@S2101-09.ap.freescale.net>
 <20953.22066.706534.773272@ipc1.ka-ro>
Message-ID: <20130708024214.GB22636@S2101-09.ap.freescale.net>

On Sun, Jul 07, 2013 at 01:51:14PM +0200, Lothar Wa?mann wrote:
> Hi,
> 
> Shawn Guo writes:
> > On Fri, Jul 05, 2013 at 02:12:30PM +0800, Huang Shijie wrote:
> > > There is something wrong with the RTS/CTS pads:
> > >   The RTS pad is assigned with the CTS's value;
> > >   while the CTS pad is assigned with the RTS's value.
> > > 
> > 
> > So basically, you are saying that select_input should be set up for CTS
> > rather than RTS.  It seems that the people who generated the macro got
> > the wrong input from developer.
> > 
> programming 'select_input' only makes sense for inputs, not outputs.
> Since CTS is an output signal, select_input only makes sense for the
> RTS function of the pads.

I'm disregarding the patch, as it looks wrong.

Shawn



From vinod.koul at intel.com  Sun Jul  7 22:04:02 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 8 Jul 2013 07:34:02 +0530
Subject: amba-pl08x and 'get_signal' namespace collision/build error
In-Reply-To: <20130707133453.GC16653@intel.com>
References: <51C97F40.5030101@arm.com>
 <20130625184539.GB2718@n2100.arm.linux.org.uk>
 <20130626044842.GR23141@intel.com>
 <20130626081909.GD2718@n2100.arm.linux.org.uk>
 <20130626103930.GS23141@intel.com>
 <20130627094650.GC4283@n2100.arm.linux.org.uk>
 <CAOesGMgSPNggnBm=E3B774m7Ad_QMXdqvcGqRMxhap6dtpNtCg@mail.gmail.com>
 <20130705061802.GB10947@intel.com>
 <20130707123240.GO24642@n2100.arm.linux.org.uk>
 <20130707133453.GC16653@intel.com>
Message-ID: <20130708020402.GE16653@intel.com>

On Sun, Jul 07, 2013 at 07:04:53PM +0530, Vinod Koul wrote:
> On Sun, Jul 07, 2013 at 01:32:40PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Jul 05, 2013 at 11:48:02AM +0530, Vinod Koul wrote:
> > > On Wed, Jul 03, 2013 at 11:27:12AM -0700, Olof Johansson wrote:
> > > > This has now hit the mainline kernel, and several defconfigs (nhk815,
> > > > lpc32xx and the spear ones) are broken there.
> > > > 
> > > > Vinod, when are you sending up your pull request with the fix? It'd be
> > > > good to see it go in soon.
> > > It should be on its way by the weekend
> > 
> > It still isn't in the tree.
> I sent this morning, depends on how soon can linus merge this
Linus has merged this, so please merge the linus's tree and you should be happy
:)

~Vinod


From B35083 at freescale.com  Sun Jul  7 22:51:30 2013
From: B35083 at freescale.com (Lu Jingchang-B35083)
Date: Mon, 8 Jul 2013 02:51:30 +0000
Subject: [PATCH v4] tty: serial: add Freescale lpuart driver support
In-Reply-To: <20130705123541.GB20040@S2101-09.ap.freescale.net>
References: <1369733161-19168-1-git-send-email-b35083@freescale.com>
 <20130705091449.GA20040@S2101-09.ap.freescale.net>
 <B56CDBE15CE27145A4B77D2D24263E851E5AFC@039-SN1MPN1-005.039d.mgd.msft.net>
 <20130705123541.GB20040@S2101-09.ap.freescale.net>
Message-ID: <B56CDBE15CE27145A4B77D2D24263E851EA368@039-SN1MPN1-005.039d.mgd.msft.net>

>-----Original Message-----
>From: Shawn Guo [mailto:shawn.guo at linaro.org]
>Sent: Friday, July 05, 2013 8:36 PM
>To: Lu Jingchang-B35083
>Cc: linux-serial at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>gregkh at linuxfoundation.org; s.hauer at pengutronix.de
>Subject: Re: [PATCH v4] tty: serial: add Freescale lpuart driver support
>
>On Fri, Jul 05, 2013 at 09:39:03AM +0000, Lu Jingchang-B35083 wrote:
>> I explicitly removed the cr2 restore code on cleaning up the redundant
>code, and find it work well on normal operation.
>> Low level debug is not supported on Vybrid so I didn't notice that
>problem.
>> Will you fixing it? Or I submit a fix on it?
>
>I can send a fix for that.  But before doing that, I would need your help
>to understand why we need to clear those UARTCR2 bits for setting up FIFO
>stuff at all.  From my quick testing, at least console still works fine
>after removing all those UARTCR2 operations from lpuart_setup_watermark().
[Lu Jingchang-B35083] 
The FIFO registers description in the RM says "This register must be written only when C2[RE] and
C2[TE] are cleared/not set and when the data buffer/FIFO is empty." So the code is added.



Best Regards,
Jingchang




From jg1.han at samsung.com  Sun Jul  7 22:54:48 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Mon, 08 Jul 2013 11:54:48 +0900
Subject: [PATCH V5 0/4] Generic PHY driver for the Exynos SoC DP PHY
Message-ID: <001b01ce7b86$828743e0$8795cba0$@samsung.com>

This patch series adds a simple driver for the Samsung Exynos SoC
series DP transmitter PHY, using the generic PHY framework [1].
Previously the DP PHY used an internal DT node to control the PHY
power enable bit.

These patches was tested on Exynos5250.

This PATCH v5 follows:
 * PATCH v4, sent on July, 2nd 2013
 * PATCH v3, sent on July, 1st 2013
 * PATCH v2, sent on June, 28th 2013
 * PATCH v1, sent on June, 28th 2013

Changes between v4 and v5:
  * Marked original bindings as deprecated in 'exynos_dp.txt'
  * Fixed typo of commit message.
  * Added Tomasz Figa's Reviewed-by.

Changes between v3 and v4:
  * Added OF dependancy.
  * Removed redundant local variable 'void __iomem *addr'.
  * Removed unnecessary dev_set_drvdata().
  * Added a patch that remove non-DT support for Exynos
    Display Port driver.
  * Removed unnecessary 'struct exynos_dp_platdata'.
  * Kept supporting the original bindings for DT compatibility.

Changes between v2 and v3:
  * Removed redundant spinlock
  * Removed 'struct phy' from 'struct exynos_dp_video_phy'
  * Updated 'samsung-phy.txt', instead of creating
    'samsung,exynos5250-dp-video-phy.txt'.
  * Removed unnecessary additional specifier from 'phys'
    DT property.
  * Added 'phys', 'phy-names' properties to 'exynos_dp.txt' file.
  * Added Felipe Balbi's Acked-by.

Changes between v1 and v2:
  * Replaced exynos_dp_video_phy_xlate() with of_phy_simple_xlate(),
    as Kishon Vijay Abraham I guided.
  * Set the value of phy-cells as 0, because the phy_provider implements
    only one PHY.
  * Removed unnecessary header include.
  * Added '#ifdef CONFIG_OF' and of_match_ptr macro.

This series depends on the generic PHY framework [1]. These patches
refer to Sylwester Nawrocki's patches about Exynos MIPI [2].

[1] https://lkml.org/lkml/2013/6/26/259
[2] http://www.spinics.net/lists/linux-samsung-soc/msg20098.html

Jingoo Han (4):
  ARM: dts: Add DP PHY node to exynos5250.dtsi
  phy: Add driver for Exynos DP PHY
  video: exynos_dp: remove non-DT support for Exynos Display Port
  video: exynos_dp: Use the generic PHY driver

 .../devicetree/bindings/phy/samsung-phy.txt        |    8 ++
 .../devicetree/bindings/video/exynos_dp.txt        |   18 +++++++++---------
 arch/arm/boot/dts/exynos5250.dtsi                  |   13 ++++++++-----
 drivers/phy/Kconfig                                |    6 ++
 drivers/phy/Makefile                               |    1 +
 drivers/phy/phy-exynos-dp-video.c                  |  111 ++++++++++++++++++++
 drivers/video/exynos/Kconfig                       |    2 +-
 drivers/video/exynos/exynos_dp_core.c              |  132 +++++++----------------------
 drivers/video/exynos/exynos_dp_core.h              |  110 +++++++++++++++++++++++++++
 drivers/video/exynos/exynos_dp_reg.c               |    2 -
 include/video/exynos_dp.h                          |  131 ---------------------------------
 11 files changed, 291 insertions(+), 243 deletions(-) 
 create mode 100644 drivers/phy/phy-exynos-dp-video.c
 delete mode 100644 include/video/exynos_dp.h

--
1.7.10.4



From jg1.han at samsung.com  Sun Jul  7 22:55:45 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Mon, 08 Jul 2013 11:55:45 +0900
Subject: [PATCH V5 1/4] ARM: dts: Add DP PHY node to exynos5250.dtsi
Message-ID: <001c01ce7b86$a4872f00$ed958d00$@samsung.com>

Add PHY provider node for the DP PHY.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/boot/dts/exynos5250.dtsi |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index ef57277..2c1e73c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -614,6 +614,12 @@
 		interrupts = <0 94 0>;
 	};
 
+	dp_phy: video-phy at 10040720 {
+		compatible = "samsung,exynos5250-dp-video-phy";
+		reg = <0x10040720 4>;
+		#phy-cells = <0>;
+	};
+
 	dp-controller {
 		compatible = "samsung,exynos5-dp";
 		reg = <0x145b0000 0x1000>;
@@ -623,11 +629,8 @@
 		clock-names = "dp";
 		#address-cells = <1>;
 		#size-cells = <0>;
-
-		dptx-phy {
-			reg = <0x10040720>;
-			samsung,enable-mask = <1>;
-		};
+		phys = <&dp_phy>;
+		phy-names = "dp";
 	};
 
 	fimd {
-- 
1.7.10.4




From jg1.han at samsung.com  Sun Jul  7 22:56:36 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Mon, 08 Jul 2013 11:56:36 +0900
Subject: [PATCH V5 2/4] phy: Add driver for Exynos DP PHY
Message-ID: <001d01ce7b86$c32b9310$4982b930$@samsung.com>

Add a PHY provider driver for the Samsung Exynos SoC Display Port PHY.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 .../devicetree/bindings/phy/samsung-phy.txt        |    8 ++
 drivers/phy/Kconfig                                |    6 ++
 drivers/phy/Makefile                               |    1 +
 drivers/phy/phy-exynos-dp-video.c                  |  111 ++++++++++++++++++++
 4 files changed, 126 insertions(+)
 create mode 100644 drivers/phy/phy-exynos-dp-video.c

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 5ff208c..c0fccaa 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -12,3 +12,11 @@ the PHY specifier identifies the PHY and its meaning is as follows:
   1 - MIPI DSIM 0,
   2 - MIPI CSIS 1,
   3 - MIPI DSIM 1.
+
+Samsung EXYNOS SoC series Display Port PHY
+-------------------------------------------------
+
+Required properties:
+- compatible : should be "samsung,exynos5250-dp-video-phy";
+- reg : offset and length of the Display Port PHY register set;
+- #phy-cells : from the generic PHY bindings, must be 0;
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 6f446d0..ed0b1b8 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -19,4 +19,10 @@ config PHY_EXYNOS_MIPI_VIDEO
 	help
 	  Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
 	  S5P and EXYNOS SoCs.
+
+config PHY_EXYNOS_DP_VIDEO
+	tristate "EXYNOS SoC series Display Port PHY driver"
+	depends on OF
+	help
+	  Support for Display Port PHY found on Samsung EXYNOS SoCs.
 endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 71d8841..0fd1340 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_GENERIC_PHY)		+= phy-core.o
 obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)	+= phy-exynos-mipi-video.o
+obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)	+= phy-exynos-dp-video.o
diff --git a/drivers/phy/phy-exynos-dp-video.c b/drivers/phy/phy-exynos-dp-video.c
new file mode 100644
index 0000000..3c8e247
--- /dev/null
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -0,0 +1,111 @@
+/*
+ * Samsung EXYNOS SoC series Display Port PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Jingoo Han <jg1.han at samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+
+/* DPTX_PHY_CONTROL register */
+#define EXYNOS_DPTX_PHY_ENABLE		(1 << 0)
+
+struct exynos_dp_video_phy {
+	void __iomem *regs;
+};
+
+static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int on)
+{
+	u32 reg;
+
+	reg = readl(state->regs);
+	if (on)
+		reg |= EXYNOS_DPTX_PHY_ENABLE;
+	else
+		reg &= ~EXYNOS_DPTX_PHY_ENABLE;
+	writel(reg, state->regs);
+
+	return 0;
+}
+
+static int exynos_dp_video_phy_power_on(struct phy *phy)
+{
+	struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+	return __set_phy_state(state, 1);
+}
+
+static int exynos_dp_video_phy_power_off(struct phy *phy)
+{
+	struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+	return __set_phy_state(state, 0);
+}
+
+static struct phy_ops exynos_dp_video_phy_ops = {
+	.power_on	= exynos_dp_video_phy_power_on,
+	.power_off	= exynos_dp_video_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
+static int exynos_dp_video_phy_probe(struct platform_device *pdev)
+{
+	struct exynos_dp_video_phy *state;
+	struct device *dev = &pdev->dev;
+	struct resource *res;
+	struct phy_provider *phy_provider;
+	struct phy *phy;
+
+	state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
+	if (!state)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+	state->regs = devm_ioremap_resource(dev, res);
+	if (IS_ERR(state->regs))
+		return PTR_ERR(state->regs);
+
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	phy = devm_phy_create(dev, 0, &exynos_dp_video_phy_ops, NULL);
+	if (IS_ERR(phy)) {
+		dev_err(dev, "failed to create Display Port PHY\n");
+		return PTR_ERR(phy);
+	}
+	phy_set_drvdata(phy, state);
+
+	return 0;
+}
+
+static const struct of_device_id exynos_dp_video_phy_of_match[] = {
+	{ .compatible = "samsung,exynos5250-dp-video-phy" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, exynos_dp_video_phy_of_match);
+
+static struct platform_driver exynos_dp_video_phy_driver = {
+	.probe	= exynos_dp_video_phy_probe,
+	.driver = {
+		.name	= "exynos-dp-video-phy",
+		.owner	= THIS_MODULE,
+		.of_match_table	= exynos_dp_video_phy_of_match,
+	}
+};
+module_platform_driver(exynos_dp_video_phy_driver);
+
+MODULE_AUTHOR("Jingoo Han <jg1.han at samsung.com>");
+MODULE_DESCRIPTION("Samsung EXYNOS SoC DP PHY driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.10.4




From jg1.han at samsung.com  Sun Jul  7 22:57:43 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Mon, 08 Jul 2013 11:57:43 +0900
Subject: [PATCH V5 3/4] video: exynos_dp: remove non-DT support for Exynos
 Display Port
Message-ID: <001e01ce7b86$eb866290$c29327b0$@samsung.com>

Exynos Display Port can be used only for Exynos SoCs. In addition,
non-DT for EXYNOS SoCs is not supported from v3.11; thus, there is
no need to support non-DT for Exynos Display Port.

The 'include/video/exynos_dp.h' file has been used for non-DT
support and the content of file include/video/exynos_dp.h is moved
to drivers/video/exynos/exynos_dp_core.h. Thus, the 'exynos_dp.h'
file is removed. Also, 'struct exynos_dp_platdata' is removed,
because it is not used any more.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---
 drivers/video/exynos/Kconfig          |    2 +-
 drivers/video/exynos/exynos_dp_core.c |  116 +++++++----------------------
 drivers/video/exynos/exynos_dp_core.h |  109 +++++++++++++++++++++++++++
 drivers/video/exynos/exynos_dp_reg.c  |    2 -
 include/video/exynos_dp.h             |  131 ---------------------------------
 5 files changed, 135 insertions(+), 225 deletions(-)
 delete mode 100644 include/video/exynos_dp.h

diff --git a/drivers/video/exynos/Kconfig b/drivers/video/exynos/Kconfig
index 1b035b2..fab9019 100644
--- a/drivers/video/exynos/Kconfig
+++ b/drivers/video/exynos/Kconfig
@@ -29,7 +29,7 @@ config EXYNOS_LCD_S6E8AX0
 
 config EXYNOS_DP
 	bool "EXYNOS DP driver support"
-	depends on ARCH_EXYNOS
+	depends on OF && ARCH_EXYNOS
 	default n
 	help
 	  This enables support for DP device.
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index 12bbede..05fed7d 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -20,8 +20,6 @@
 #include <linux/delay.h>
 #include <linux/of.h>
 
-#include <video/exynos_dp.h>
-
 #include "exynos_dp_core.h"
 
 static int exynos_dp_init_dp(struct exynos_dp_device *dp)
@@ -894,26 +892,17 @@ static void exynos_dp_hotplug(struct work_struct *work)
 		dev_err(dp->dev, "unable to config video\n");
 }
 
-#ifdef CONFIG_OF
-static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
+static struct video_info *exynos_dp_dt_parse_pdata(struct device *dev)
 {
 	struct device_node *dp_node = dev->of_node;
-	struct exynos_dp_platdata *pd;
 	struct video_info *dp_video_config;
 
-	pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
-	if (!pd) {
-		dev_err(dev, "memory allocation for pdata failed\n");
-		return ERR_PTR(-ENOMEM);
-	}
 	dp_video_config = devm_kzalloc(dev,
 				sizeof(*dp_video_config), GFP_KERNEL);
-
 	if (!dp_video_config) {
 		dev_err(dev, "memory allocation for video config failed\n");
 		return ERR_PTR(-ENOMEM);
 	}
-	pd->video_info = dp_video_config;
 
 	dp_video_config->h_sync_polarity =
 		of_property_read_bool(dp_node, "hsync-active-high");
@@ -960,7 +949,7 @@ static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
 		return ERR_PTR(-EINVAL);
 	}
 
-	return pd;
+	return dp_video_config;
 }
 
 static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
@@ -1003,48 +992,30 @@ err:
 
 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 {
-	u32 reg;
+	if (dp->phy_addr) {
+		u32 reg;
 
-	reg = __raw_readl(dp->phy_addr);
-	reg |= dp->enable_mask;
-	__raw_writel(reg, dp->phy_addr);
+		reg = __raw_readl(dp->phy_addr);
+		reg |= dp->enable_mask;
+		__raw_writel(reg, dp->phy_addr);
+	}
 }
 
 static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
 {
-	u32 reg;
-
-	reg = __raw_readl(dp->phy_addr);
-	reg &= ~(dp->enable_mask);
-	__raw_writel(reg, dp->phy_addr);
-}
-#else
-static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
-{
-	return NULL;
-}
-
-static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
-{
-	return -EINVAL;
-}
-
-static void exynos_dp_phy_init(struct exynos_dp_device *dp)
-{
-	return;
-}
+	if (dp->phy_addr) {
+		u32 reg;
 
-static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
-{
-	return;
+		reg = __raw_readl(dp->phy_addr);
+		reg &= ~(dp->enable_mask);
+		__raw_writel(reg, dp->phy_addr);
+	}
 }
-#endif /* CONFIG_OF */
 
 static int exynos_dp_probe(struct platform_device *pdev)
 {
 	struct resource *res;
 	struct exynos_dp_device *dp;
-	struct exynos_dp_platdata *pdata;
 
 	int ret = 0;
 
@@ -1057,21 +1028,13 @@ static int exynos_dp_probe(struct platform_device *pdev)
 
 	dp->dev = &pdev->dev;
 
-	if (pdev->dev.of_node) {
-		pdata = exynos_dp_dt_parse_pdata(&pdev->dev);
-		if (IS_ERR(pdata))
-			return PTR_ERR(pdata);
+	dp->video_info = exynos_dp_dt_parse_pdata(&pdev->dev);
+	if (IS_ERR(dp->video_info))
+		return PTR_ERR(dp->video_info);
 
-		ret = exynos_dp_dt_parse_phydata(dp);
-		if (ret)
-			return ret;
-	} else {
-		pdata = pdev->dev.platform_data;
-		if (!pdata) {
-			dev_err(&pdev->dev, "no platform data\n");
-			return -EINVAL;
-		}
-	}
+	ret = exynos_dp_dt_parse_phydata(dp);
+	if (ret)
+		return ret;
 
 	dp->clock = devm_clk_get(&pdev->dev, "dp");
 	if (IS_ERR(dp->clock)) {
@@ -1095,15 +1058,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
 
 	INIT_WORK(&dp->hotplug_work, exynos_dp_hotplug);
 
-	dp->video_info = pdata->video_info;
-
-	if (pdev->dev.of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_init(dp);
-	} else {
-		if (pdata->phy_init)
-			pdata->phy_init();
-	}
+	exynos_dp_phy_init(dp);
 
 	exynos_dp_init_dp(dp);
 
@@ -1121,18 +1076,11 @@ static int exynos_dp_probe(struct platform_device *pdev)
 
 static int exynos_dp_remove(struct platform_device *pdev)
 {
-	struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
 	struct exynos_dp_device *dp = platform_get_drvdata(pdev);
 
 	flush_work(&dp->hotplug_work);
 
-	if (pdev->dev.of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_exit(dp);
-	} else {
-		if (pdata->phy_exit)
-			pdata->phy_exit();
-	}
+	exynos_dp_phy_exit(dp);
 
 	clk_disable_unprepare(dp->clock);
 
@@ -1143,20 +1091,13 @@ static int exynos_dp_remove(struct platform_device *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int exynos_dp_suspend(struct device *dev)
 {
-	struct exynos_dp_platdata *pdata = dev->platform_data;
 	struct exynos_dp_device *dp = dev_get_drvdata(dev);
 
 	disable_irq(dp->irq);
 
 	flush_work(&dp->hotplug_work);
 
-	if (dev->of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_exit(dp);
-	} else {
-		if (pdata->phy_exit)
-			pdata->phy_exit();
-	}
+	exynos_dp_phy_exit(dp);
 
 	clk_disable_unprepare(dp->clock);
 
@@ -1165,16 +1106,9 @@ static int exynos_dp_suspend(struct device *dev)
 
 static int exynos_dp_resume(struct device *dev)
 {
-	struct exynos_dp_platdata *pdata = dev->platform_data;
 	struct exynos_dp_device *dp = dev_get_drvdata(dev);
 
-	if (dev->of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_init(dp);
-	} else {
-		if (pdata->phy_init)
-			pdata->phy_init();
-	}
+	exynos_dp_phy_init(dp);
 
 	clk_prepare_enable(dp->clock);
 
@@ -1203,7 +1137,7 @@ static struct platform_driver exynos_dp_driver = {
 		.name	= "exynos-dp",
 		.owner	= THIS_MODULE,
 		.pm	= &exynos_dp_pm_ops,
-		.of_match_table = of_match_ptr(exynos_dp_match),
+		.of_match_table = exynos_dp_match,
 	},
 };
 
diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
index 6c567bbf..56cfec8 100644
--- a/drivers/video/exynos/exynos_dp_core.h
+++ b/drivers/video/exynos/exynos_dp_core.h
@@ -13,6 +13,99 @@
 #ifndef _EXYNOS_DP_CORE_H
 #define _EXYNOS_DP_CORE_H
 
+#define DP_TIMEOUT_LOOP_COUNT 100
+#define MAX_CR_LOOP 5
+#define MAX_EQ_LOOP 5
+
+enum link_rate_type {
+	LINK_RATE_1_62GBPS = 0x06,
+	LINK_RATE_2_70GBPS = 0x0a
+};
+
+enum link_lane_count_type {
+	LANE_COUNT1 = 1,
+	LANE_COUNT2 = 2,
+	LANE_COUNT4 = 4
+};
+
+enum link_training_state {
+	START,
+	CLOCK_RECOVERY,
+	EQUALIZER_TRAINING,
+	FINISHED,
+	FAILED
+};
+
+enum voltage_swing_level {
+	VOLTAGE_LEVEL_0,
+	VOLTAGE_LEVEL_1,
+	VOLTAGE_LEVEL_2,
+	VOLTAGE_LEVEL_3,
+};
+
+enum pre_emphasis_level {
+	PRE_EMPHASIS_LEVEL_0,
+	PRE_EMPHASIS_LEVEL_1,
+	PRE_EMPHASIS_LEVEL_2,
+	PRE_EMPHASIS_LEVEL_3,
+};
+
+enum pattern_set {
+	PRBS7,
+	D10_2,
+	TRAINING_PTN1,
+	TRAINING_PTN2,
+	DP_NONE
+};
+
+enum color_space {
+	COLOR_RGB,
+	COLOR_YCBCR422,
+	COLOR_YCBCR444
+};
+
+enum color_depth {
+	COLOR_6,
+	COLOR_8,
+	COLOR_10,
+	COLOR_12
+};
+
+enum color_coefficient {
+	COLOR_YCBCR601,
+	COLOR_YCBCR709
+};
+
+enum dynamic_range {
+	VESA,
+	CEA
+};
+
+enum pll_status {
+	PLL_UNLOCKED,
+	PLL_LOCKED
+};
+
+enum clock_recovery_m_value_type {
+	CALCULATED_M,
+	REGISTER_M
+};
+
+enum video_timing_recognition_type {
+	VIDEO_TIMING_FROM_CAPTURE,
+	VIDEO_TIMING_FROM_REGISTER
+};
+
+enum analog_power_block {
+	AUX_BLOCK,
+	CH0_BLOCK,
+	CH1_BLOCK,
+	CH2_BLOCK,
+	CH3_BLOCK,
+	ANALOG_TOTAL,
+	POWER_ALL
+};
+
 enum dp_irq_type {
 	DP_IRQ_TYPE_HP_CABLE_IN,
 	DP_IRQ_TYPE_HP_CABLE_OUT,
@@ -20,6 +113,22 @@ enum dp_irq_type {
 	DP_IRQ_TYPE_UNKNOWN,
 };
 
+struct video_info {
+	char *name;
+
+	bool h_sync_polarity;
+	bool v_sync_polarity;
+	bool interlaced;
+
+	enum color_space color_space;
+	enum dynamic_range dynamic_range;
+	enum color_coefficient ycbcr_coeff;
+	enum color_depth color_depth;
+
+	enum link_rate_type link_rate;
+	enum link_lane_count_type lane_count;
+};
+
 struct link_train {
 	int eq_loop;
 	int cr_loop[4];
diff --git a/drivers/video/exynos/exynos_dp_reg.c b/drivers/video/exynos/exynos_dp_reg.c
index 29d9d03..b70da50 100644
--- a/drivers/video/exynos/exynos_dp_reg.c
+++ b/drivers/video/exynos/exynos_dp_reg.c
@@ -14,8 +14,6 @@
 #include <linux/io.h>
 #include <linux/delay.h>
 
-#include <video/exynos_dp.h>
-
 #include "exynos_dp_core.h"
 #include "exynos_dp_reg.h"
 
diff --git a/include/video/exynos_dp.h b/include/video/exynos_dp.h
deleted file mode 100644
index bd8cabd..0000000
--- a/include/video/exynos_dp.h
+++ /dev/null
@@ -1,131 +0,0 @@
-/*
- * Samsung SoC DP device support
- *
- * Copyright (C) 2012 Samsung Electronics Co., Ltd.
- * Author: Jingoo Han <jg1.han at samsung.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef _EXYNOS_DP_H
-#define _EXYNOS_DP_H
-
-#define DP_TIMEOUT_LOOP_COUNT 100
-#define MAX_CR_LOOP 5
-#define MAX_EQ_LOOP 5
-
-enum link_rate_type {
-	LINK_RATE_1_62GBPS = 0x06,
-	LINK_RATE_2_70GBPS = 0x0a
-};
-
-enum link_lane_count_type {
-	LANE_COUNT1 = 1,
-	LANE_COUNT2 = 2,
-	LANE_COUNT4 = 4
-};
-
-enum link_training_state {
-	START,
-	CLOCK_RECOVERY,
-	EQUALIZER_TRAINING,
-	FINISHED,
-	FAILED
-};
-
-enum voltage_swing_level {
-	VOLTAGE_LEVEL_0,
-	VOLTAGE_LEVEL_1,
-	VOLTAGE_LEVEL_2,
-	VOLTAGE_LEVEL_3,
-};
-
-enum pre_emphasis_level {
-	PRE_EMPHASIS_LEVEL_0,
-	PRE_EMPHASIS_LEVEL_1,
-	PRE_EMPHASIS_LEVEL_2,
-	PRE_EMPHASIS_LEVEL_3,
-};
-
-enum pattern_set {
-	PRBS7,
-	D10_2,
-	TRAINING_PTN1,
-	TRAINING_PTN2,
-	DP_NONE
-};
-
-enum color_space {
-	COLOR_RGB,
-	COLOR_YCBCR422,
-	COLOR_YCBCR444
-};
-
-enum color_depth {
-	COLOR_6,
-	COLOR_8,
-	COLOR_10,
-	COLOR_12
-};
-
-enum color_coefficient {
-	COLOR_YCBCR601,
-	COLOR_YCBCR709
-};
-
-enum dynamic_range {
-	VESA,
-	CEA
-};
-
-enum pll_status {
-	PLL_UNLOCKED,
-	PLL_LOCKED
-};
-
-enum clock_recovery_m_value_type {
-	CALCULATED_M,
-	REGISTER_M
-};
-
-enum video_timing_recognition_type {
-	VIDEO_TIMING_FROM_CAPTURE,
-	VIDEO_TIMING_FROM_REGISTER
-};
-
-enum analog_power_block {
-	AUX_BLOCK,
-	CH0_BLOCK,
-	CH1_BLOCK,
-	CH2_BLOCK,
-	CH3_BLOCK,
-	ANALOG_TOTAL,
-	POWER_ALL
-};
-
-struct video_info {
-	char *name;
-
-	bool h_sync_polarity;
-	bool v_sync_polarity;
-	bool interlaced;
-
-	enum color_space color_space;
-	enum dynamic_range dynamic_range;
-	enum color_coefficient ycbcr_coeff;
-	enum color_depth color_depth;
-
-	enum link_rate_type link_rate;
-	enum link_lane_count_type lane_count;
-};
-
-struct exynos_dp_platdata {
-	struct video_info *video_info;
-
-	void (*phy_init)(void);
-	void (*phy_exit)(void);
-};
-
-#endif /* _EXYNOS_DP_H */
-- 
1.7.10.4




From jg1.han at samsung.com  Sun Jul  7 22:58:28 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Mon, 08 Jul 2013 11:58:28 +0900
Subject: [PATCH V5 4/4] video: exynos_dp: Use the generic PHY driver
Message-ID: <001f01ce7b87$05c6f750$1154e5f0$@samsung.com>

Use the generic PHY API to control the DP PHY.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---
 .../devicetree/bindings/video/exynos_dp.txt          |   18 +++++++++---------
 drivers/video/exynos/exynos_dp_core.c                |   16 ++++++++++++----
 drivers/video/exynos/exynos_dp_core.h                |    1 +
 3 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 84f10c1..2f56376 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -6,10 +6,10 @@ We use two nodes:
 	-dptx-phy node(defined inside dp-controller node)
 
 For the DP-PHY initialization, we use the dptx-phy node.
-Required properties for dptx-phy:
-	-reg:
+Required properties for dptx-phy: deprecated, use phys and phy-names
+	-reg: deprecated
 		Base address of DP PHY register.
-	-samsung,enable-mask:
+	-samsung,enable-mask: deprecated
 		The bit-mask used to enable/disable DP PHY.
 
 For the Panel initialization, we read data from dp-controller node.
@@ -25,6 +25,10 @@ Required properties for dp-controller:
 		from common clock binding: handle to dp clock.
 	-clock-names:
 		from common clock binding: Shall be "dp".
+	-phys:
+		from general PHY binding: the phandle for the PHY device.
+	-phy-names:
+		from general PHY binding: Should be "dp".
 	-interrupt-parent:
 		phandle to Interrupt combiner node.
 	-samsung,color-space:
@@ -67,12 +71,8 @@ SOC specific portion:
 		interrupt-parent = <&combiner>;
 		clocks = <&clock 342>;
 		clock-names = "dp";
-
-		dptx-phy {
-			reg = <0x10040720>;
-			samsung,enable-mask = <1>;
-		};
-
+		phys = <&dp_phy>;
+		phy-names = "dp";
 	};
 
 Board Specific portion:
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index 05fed7d..5e1a715 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -19,6 +19,7 @@
 #include <linux/interrupt.h>
 #include <linux/delay.h>
 #include <linux/of.h>
+#include <linux/phy/phy.h>
 
 #include "exynos_dp_core.h"
 
@@ -960,8 +961,11 @@ static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
 
 	dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
 	if (!dp_phy_node) {
-		dev_err(dp->dev, "could not find dptx-phy node\n");
-		return -ENODEV;
+		dp->phy = devm_phy_get(dp->dev, "dp");
+		if (IS_ERR(dp->phy))
+			return PTR_ERR(dp->phy);
+		else
+			return 0;
 	}
 
 	if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
@@ -992,7 +996,9 @@ err:
 
 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 {
-	if (dp->phy_addr) {
+	if (dp->phy) {
+		phy_power_on(dp->phy);
+	} else if (dp->phy_addr) {
 		u32 reg;
 
 		reg = __raw_readl(dp->phy_addr);
@@ -1003,7 +1009,9 @@ static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 
 static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
 {
-	if (dp->phy_addr) {
+	if (dp->phy) {
+		phy_power_off(dp->phy);
+	} else if (dp->phy_addr) {
 		u32 reg;
 
 		reg = __raw_readl(dp->phy_addr);
diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
index 56cfec8..607e36d 100644
--- a/drivers/video/exynos/exynos_dp_core.h
+++ b/drivers/video/exynos/exynos_dp_core.h
@@ -151,6 +151,7 @@ struct exynos_dp_device {
 	struct video_info	*video_info;
 	struct link_train	link_train;
 	struct work_struct	hotplug_work;
+	struct phy		*phy;
 };
 
 /* exynos_dp_reg.c */
-- 
1.7.10.4




From sfr at canb.auug.org.au  Mon Jul  8 00:03:04 2013
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Mon, 8 Jul 2013 14:03:04 +1000
Subject: linux-next: manual merge of the arm-soc tree with Linus' tree
Message-ID: <20130708140304.39c17c16e878a8eb26eaf5a1@canb.auug.org.au>

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap2/Kconfig between commit 4a1b573346ee ("ARM: 7758/1:
introduce config HAS_BANDGAP") from Linus' tree and commit 59d92875a6d9
("ARM: OMAP: build mach-omap code only if needed") from the arm-soc tree.

I fixed it up (the latter moved the "config ARCH_OMAP2PLUS" and included
the "select ARCH_HAS_BANDGAP" despite there being no ARCH_HAS_BANDGAP
config in the arm-soc tree :-() and can carry the fix as necessary (no
action is required).

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130708/a745db71/attachment.sig>

From viresh.kumar at linaro.org  Mon Jul  8 00:10:54 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 8 Jul 2013 09:40:54 +0530
Subject: [PATCH RFC 3/3] cpufreq: cpufreq-cpu0: clk rate-change notifiers
In-Reply-To: <1373247868-21444-4-git-send-email-mturquette@linaro.org>
References: <1373247868-21444-1-git-send-email-mturquette@linaro.org>
 <1373247868-21444-4-git-send-email-mturquette@linaro.org>
Message-ID: <CAOh2x=kAM98Qta5RquVVByR8jJ3=t+6fNZ4o4WSroVCCZi+0Cg@mail.gmail.com>

On Mon, Jul 8, 2013 at 7:14 AM, Mike Turquette <mturquette at linaro.org> wrote:
> Removes direct handling of OPP tables and voltage regulators by calling
> of_clk_cpufreq_notifier_handler, introduced by commit "clk: cpufreq
> helper for voltage scaling".
>
> In the future this can help consolidate code found across similar
> CPUfreq drivers.
>
> Signed-off-by: Mike Turquette <mturquette at linaro.org>
> ---
>  drivers/cpufreq/cpufreq-cpu0.c | 125 ++++++++---------------------------------
>  1 file changed, 22 insertions(+), 103 deletions(-)

Good patch, really gets lots of stuff out from cpufreq drivers.

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>


From shc_work at mail.ru  Mon Jul  8 00:29:43 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Mon, 08 Jul 2013 08:29:43 +0400
Subject: =?UTF-8?B?UmVbMl06IFtQQVRDSF0gQVJNOiBkdHM6IGkuTVg1MTogQWRkIFdFSU0gbm9k?=
 =?UTF-8?B?ZQ==?=
In-Reply-To: <20130708023304.GA22636@S2101-09.ap.freescale.net>
References: <1373094142-24173-1-git-send-email-shc_work@mail.ru>
 <20130708023304.GA22636@S2101-09.ap.freescale.net>
Message-ID: <1373257783.211316847@f137.mail.ru>

> On Sat, Jul 06, 2013 at 11:02:22AM +0400, Alexander Shiyan wrote:
> > This patch adds the missing (Wireless External Interface Module) WEIM
> > devicetree node for i.MX51 CPUs.
> > 
> > Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> > ---
> >  arch/arm/boot/dts/imx51.dtsi | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
> > index 0ca62be..e71976e4 100644
> > --- a/arch/arm/boot/dts/imx51.dtsi
> > +++ b/arch/arm/boot/dts/imx51.dtsi
> > @@ -745,6 +745,23 @@
> >  				status = "disabled";
> >  			};
> >  
> > +			weim: weim at 83fda000 {
> > +				#address-cells = <2>;
> > +				#size-cells = <1>;
> > +				compatible = "fsl,imx51-weim";
> > +				reg = <0x83fda000 0x1000>;
> > +				clocks = <&clks 0>;
> 
> Is it correct?  I think there should be a physical clock for weim.

Yes, but properly clock for weim is missing in the clk subsystem,
so I think at this point it is OK. Adding a properly clock should be a separate patch.
Thanks.

---

From sachin.kamat at linaro.org  Mon Jul  8 00:35:48 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Mon, 8 Jul 2013 10:05:48 +0530
Subject: [PATCH] ARM: pxa: propagate errors from regulator_enable() to
 pxamci
In-Reply-To: <201307051751.20729.arnd@arndb.de>
References: <201307051751.20729.arnd@arndb.de>
Message-ID: <CAK9yfHzVtQR1=cCiE3Se0FUUF68GEK5UeYE2gtOLZpaXaODVvQ@mail.gmail.com>

On 5 July 2013 21:21, Arnd Bergmann <arnd at arndb.de> wrote:
> The em_x270_mci_setpower() and em_x270_usb_hub_init() functions
> call regulator_enable(), which may return an error that must
> be checked.
>
> This changes the em_x270_usb_hub_init() function to bail out
> if it fails, and changes the pxamci_platform_data->setpower
> callback so that the a failed em_x270_mci_setpower call
> can be propagated by the pxamci driver into the mmc core.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Mike Rapoport <mike at compulab.co.il>
> Cc: Paul Gortmaker <paul.gortmaker at windriver.com>
> Cc: Mark Brown <broonie at opensource.wolfsonmicro.com>
> Cc: Haojian Zhuang <haojian.zhuang at gmail.com>
> Cc: Chris Ball <cjb at laptop.org>
>
> diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
> index f6726bb..f8062e4 100644
> --- a/arch/arm/mach-pxa/em-x270.c
> +++ b/arch/arm/mach-pxa/em-x270.c
> @@ -477,16 +477,24 @@ static int em_x270_usb_hub_init(void)
>         /* USB Hub power-on and reset */
>         gpio_direction_output(usb_hub_reset, 1);
>         gpio_direction_output(GPIO9_USB_VBUS_EN, 0);
> -       regulator_enable(em_x270_usb_ldo);
> +       err = regulator_enable(em_x270_usb_ldo);
> +       if (err)
> +               goto err_free_rst_gpio;
> +
>         gpio_set_value(usb_hub_reset, 0);
>         gpio_set_value(usb_hub_reset, 1);
>         regulator_disable(em_x270_usb_ldo);
> -       regulator_enable(em_x270_usb_ldo);
> +       if (err)
> +               goto err_free_rst_gpio;

Shouldn't this check be after the below (regulator_enable) statement?

> +
> +       err = regulator_enable(em_x270_usb_ldo);
>         gpio_set_value(usb_hub_reset, 0);
>         gpio_set_value(GPIO9_USB_VBUS_EN, 1);
>
>         return 0;
>
> +err_free_rst_gpio:
> +       gpio_free(usb_hub_reset);
>  err_free_vbus_gpio:
>         gpio_free(GPIO9_USB_VBUS_EN);
>  err_free_usb_ldo:
> @@ -592,7 +600,7 @@ err_irq:
>         return err;
>  }

-- 
With warm regards,
Sachin


From magnus.damm at gmail.com  Mon Jul  8 00:48:35 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 8 Jul 2013 13:48:35 +0900
Subject: [PATCH] ARM: shmobile: r8a7790 SMP prototype v2
In-Reply-To: <20130627084358.GA4283@n2100.arm.linux.org.uk>
References: <20130626235837.11576.86389.sendpatchset@w520>
 <20130627084358.GA4283@n2100.arm.linux.org.uk>
Message-ID: <CANqRtoTEVVBTr+8cnF-X9Ep=9POjiCQSFEEwy3T=dCB_4p62YA@mail.gmail.com>

On Thu, Jun 27, 2013 at 5:43 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Thu, Jun 27, 2013 at 08:58:37AM +0900, Magnus Damm wrote:
>> +#include <linux/smp.h>
>> +#include <linux/irqchip/arm-gic.h>
>> +#include <asm/cacheflush.h>
>> +#include <asm/io.h>
>
> Please always use linux/io.h

Will do, thanks!

/ magnus


From magnus.damm at gmail.com  Mon Jul  8 00:52:31 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 8 Jul 2013 13:52:31 +0900
Subject: [PATCH] ARM: shmobile: r8a7790 SMP prototype v2
In-Reply-To: <201306271401.13198.arnd@arndb.de>
References: <20130626235837.11576.86389.sendpatchset@w520>
 <201306271401.13198.arnd@arndb.de>
Message-ID: <CANqRtoRR-pyCpXYwKXRYSfVOewv+dXf=ntofJJsKQ0defF5-MQ@mail.gmail.com>

Hi Arnd,

On Thu, Jun 27, 2013 at 9:01 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 27 June 2013, Magnus Damm wrote:
>
>> +#include <asm/cacheflush.h>
>> +#include <asm/cp15.h>
>> +#include <asm/smp_plat.h>
>> +
>> +#define SYSC 0xe6180000
>> +#define SYSCSR  0x0000
>> +
>> +#define RST  0xe6160000
>> +#define CA15BAR      0x6020
>> +#define CA15RESCNT 0x0040
>> +#define CA7BAR       0x4030
>> +#define CA7RESCNT 0x0044
>> +#define RESCNT       0x0050
>> +
>> +#define APMU 0xe6150000
>> +#define CA15WUPCR 0x2010
>> +#define CA7WUPCR 0x1010
>> +
>> +#define MERAM        0xe8080000
>
> Please get the base addresses from device tree if you can,
> using of_iomap().

Yes, that is my plan. Actually, I was hoping of moving out the APMU
and SYSC bits from this file in the future.

>> +#define r8a7790_clst_id(cpu) (cpu_logical_map((cpu)) >> 8)
>> +#define r8a7790_cpu_id(cpu) (cpu_logical_map((cpu)) & 0xff)
>> +
>> +static void r8a7790_deassert_reset(unsigned int cpu)
>> +{
>> +     void __iomem *p, *carescnt;
>> +     u32 bar, mask, magic;
>> +     unsigned int clst_id = r8a7790_clst_id(cpu);
>> +
>> +     /* setup reset vectors */
>> +     p = ioremap_nocache(RST, 0x7000);
>> +     bar = (MERAM >> 8) & 0xfffffc00;
>> +     __raw_writel(bar, p + r8a7790_clst[clst_id].cabar);
>> +     __raw_writel(bar | 0x10, p + r8a7790_clst[clst_id].cabar);
>> +
>> +     /* enable clocks for cluster */
>> +     if (r8a7790_clst[clst_id].use_count++ == 0) {
>> +             mask = 1 << r8a7790_clst[clst_id].rescnt_bit;
>> +             __raw_writel(__raw_readl(p + RESCNT) & ~mask, p + RESCNT);
>> +     }
>
> If you cannot use writel_relaxed() here, add a comment. Otherwise
> change it to writel or writel_relaxed.

Ok, I will git that a go.

>> +static void __init r8a7790_smp_prepare_cpus(unsigned int max_cpus)
>> +{
>> +     void __iomem *p;
>> +     unsigned int k;
>> +
>> +     shmobile_boot_fn = virt_to_phys(shmobile_invalidate_start);
>> +
>> +     /* MERAM for jump stub, because BAR requires 256KB aligned address */
>> +     p = ioremap_nocache(MERAM, 16);
>> +     memcpy(p, shmobile_boot_vector, 16);
>> +     iounmap(p);
>
> On the other hand here you have to use __raw_writel() or
> memcpy_toio() because memcpy cannot operate on __iomem tokens.
>
> Also, if this is actually memory, you probably want to use ioremap_cached
> or ioremap_writecombine.

Yeah, I realize this may be a bit of a mess. So say that I used
ioremap_cached() here, I think I still need to flush the cache to make
sure the secondary processors have valid code available then they
boot. I suppose you're fine with that?

Thanks,

/ magnus


From magnus.damm at gmail.com  Mon Jul  8 00:57:58 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 8 Jul 2013 13:57:58 +0900
Subject: [PATCH] ARM: shmobile: r8a7790 SMP prototype v3
In-Reply-To: <51DA22D9.10703@renesas.com>
References: <20130701061340.22064.93012.sendpatchset@w520>
 <51DA22D9.10703@renesas.com>
Message-ID: <CANqRtoSDxOy+MF+Pns9W7m+6Z6cu8X8AsMB5fMNOA7F7wriEYg@mail.gmail.com>

Hi Kuribayashi-san,

On Mon, Jul 8, 2013 at 11:24 AM, Shinya Kuribayashi
<shinya.kuribayashi.px at renesas.com> wrote:
> Magnus,
>
> Thanks for the patch, see my comments below.
>
> On 7/1/2013 3:13 PM, Magnus Damm wrote:
>> --- /dev/null
>> +++ work/arch/arm/mach-shmobile/smp-r8a7790.c 2013-07-01 13:41:32.000000000 +0900
>> @@ -0,0 +1,187 @@
>
>> +#define SYSC 0xe6180000
>> +#define SYSCSR  0x0000
>> +
>> +#define RST  0xe6160000
>> +#define CA15BAR      0x6020
>
> CA15BAR and CA15BAR2 addresses in the datasheet v0.5 are simply wrong;
> they should be 0x0020 and 0x0024, respectively.
>
> You could confirm it in the documentation errata for v0.5 or in the
> latest datasheet v0.6 release.
>
> I believe that this is not related to an uncertain arch_timer issue you
> mentioned in the commit log, but we should use proper addresses at least.

Thanks for pointing this out. Will fix.

>> +#define CA15RESCNT 0x0040
>> +#define CA7BAR       0x4030
>
> The same applies for CA7BAR and CA7BAR2 as well.

Ok, will fix!

>> +#define CA7RESCNT 0x0044
>> +#define RESCNT       0x0050
>> +
>> +#define APMU 0xe6150000
>> +#define CA15WUPCR 0x2010
>> +#define CA7WUPCR 0x1010
>> +
>> +#define MERAM        0xe8080000
>> +
>> +enum { R8A7790_CLST_CA15, R8A7790_CLST_CA7, R8A7790_CLST_NR };
>> +
>> +static struct {
>> +     unsigned int cabar;
>> +     unsigned int carescnt;
>> +     unsigned int carescnt_magic;
>> +     unsigned int rescnt_bit;
>> +     unsigned int use_count;
>> +} r8a7790_clst[R8A7790_CLST_NR] = {
>> +     [R8A7790_CLST_CA15] = {
>> +             .cabar = CA15BAR,
>> +             .carescnt = CA15RESCNT,
>> +             .carescnt_magic = 0xa5a50000,
>> +             .rescnt_bit = 1,
>> +     },
>> +     [R8A7790_CLST_CA7] = {
>> +             .cabar = CA7BAR,
>> +             .carescnt = CA7RESCNT,
>> +             .carescnt_magic = 0x5a5a0000,
>> +             .rescnt_bit = 0,
>> +     },
>> +};
>> +
>> +#define r8a7790_clst_id(cpu) (cpu_logical_map((cpu)) >> 8)
>> +#define r8a7790_cpu_id(cpu) (cpu_logical_map((cpu)) & 0xff)
>> +
>> +static void r8a7790_deassert_reset(unsigned int cpu)
>> +{
>> +     void __iomem *p, *carescnt;
>> +     u32 bar, mask, magic;
>> +     unsigned int clst_id = r8a7790_clst_id(cpu);
>> +
>> +     /* setup reset vectors */
>> +     p = ioremap_nocache(RST, 0x7000);
>
> Therefore ioremap size for RST should be updated accordingly.

Sure, will do.

>> +     bar = (MERAM >> 8) & 0xfffffc00;
>> +     __raw_writel(bar, p + r8a7790_clst[clst_id].cabar);
>> +     __raw_writel(bar | 0x10, p + r8a7790_clst[clst_id].cabar);
>> +
>> +     /* enable clocks for cluster */
>> +     if (r8a7790_clst[clst_id].use_count++ == 0) {
>> +             mask = 1 << r8a7790_clst[clst_id].rescnt_bit;
>> +             __raw_writel(__raw_readl(p + RESCNT) & ~mask, p + RESCNT);
>> +     }
>> +
>> +     /* enable per-core clocks */
>> +     mask = BIT(3 - r8a7790_cpu_id(cpu));
>> +     magic = r8a7790_clst[clst_id].carescnt_magic;
>> +     carescnt = p + r8a7790_clst[clst_id].carescnt;
>> +     __raw_writel((__raw_readl(carescnt) & ~mask) | magic, carescnt);
>> +
>> +     iounmap(p);
>> +}
>> +
>> +static void r8a7790_assert_reset(unsigned int cpu)
>> +{
>> +     void __iomem *p, *carescnt;
>> +     u32 mask, magic;
>> +     unsigned int clst_id = r8a7790_clst_id(cpu);
>> +
>> +     p = ioremap_nocache(RST, 0x7000);
>
> Ditto.

Sounds good. I will include this together with feedback from Arnd and
RMK in next version.

Thanks,

/ magnus


From george.cherian at ti.com  Mon Jul  8 01:20:35 2013
From: george.cherian at ti.com (George Cherian)
Date: Mon, 8 Jul 2013 10:50:35 +0530
Subject: [PATCH] arm: dts: AM43x: Add usb_otg_hs node
In-Reply-To: <20130707083558.GA12992@arwen.pp.htv.fi>
References: <1372401887-19422-1-git-send-email-george.cherian@ti.com>
 <20130707083558.GA12992@arwen.pp.htv.fi>
Message-ID: <51DA4C23.6050604@ti.com>

On 7/7/2013 2:05 PM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jun 28, 2013 at 12:14:47PM +0530, George Cherian wrote:
>> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
>> index ddc1df7..e4f5eb8 100644
>> --- a/arch/arm/boot/dts/am4372.dtsi
>> +++ b/arch/arm/boot/dts/am4372.dtsi
>> @@ -64,5 +64,24 @@
>>   			compatible = "ti,am4372-counter32k","ti,omap-counter32k";
>>   			reg = <0x44e86000 0x40>;
>>   		};
>> +
>> +		usb_otg_hs1: am4372_dwc3 at 48380000 {
>> +			compatible = "ti,am437x-dwc3";
>> +			reg = <0x48380000 0x1ff>;
>> +			interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +			utmi-mode = <1>;
>> +			ranges;
>> +
>> +			dwc3 at 48390000 {
>> +				compatible = "synopsys,dwc3";
> let's us snps,dwc3. I recently posted a patch converting synopsys to
> snps like all other DesignWare drivers. Support for synopsys,dwc3 is
> still there, but shouldn't be used.
okay
>
>> +				reg = <0x48390000 0xcfff>;
>> +				interrupts = <GIC_SPI  168 IRQ_TYPE_LEVEL_HIGH>;
>> +				tx-fifo-resize;
> is this flag *really* necessary, I asked you and didn't get an answer.
We will not be needing this flag , since each EP has 3K tx fifo size. 
Also given the fact that we will be operating only
in 2.0 mode the default values are only sufficient.
I will re-send the patch with above changes.

Regards,
-George



From jgq516 at gmail.com  Mon Jul  8 01:39:21 2013
From: jgq516 at gmail.com (jgq516 at gmail.com)
Date: Mon, 08 Jul 2013 13:39:21 +0800
Subject: v3.10 - big endian core support
In-Reply-To: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <51DA5089.5080109@gmail.com>

On 07/01/2013 07:03 PM, Ben Dooks wrote:
> The latest big-endian changes, now on:
>
> 	git://git.baserock.org/delta/linux baserock/311/be/core
>
> This has a minor fix from the last version where a rebase missed a change
> in the smp_scu code.
>
Hello Ben,

Thanks for you patches at first. I can boot BE kernel on vexpress a15 tc2
board with LPAE disabled.

However if enable LPAE, kernel seems hang after turn on mmu on since
printascii can't output any character in __mmap_switched.
Did you happen to try BE kernel with LPAE enabled before? or am I missed
something?

Thanks,
Xiao

> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>



From magnus.damm at gmail.com  Mon Jul  8 02:00:30 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 08 Jul 2013 15:00:30 +0900
Subject: [PATCH] ARM: shmobile: KZM9D DT reference implementation
Message-ID: <20130708060030.13607.45725.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Add a DT reference implementation for the KZM9D board.

Only DT devices are used in this case. UART, STI, GPIO
and SMP / GIC are all provided by emev2.dtsi.

There is still a board specific C file used for enabling
legacy SH clocks. This file will be removed after we have
moved over to common clocks.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Written against "renesas-next-20130704v2". Boot tested on KZM9D.

 arch/arm/boot/dts/Makefile                     |    1 
 arch/arm/boot/dts/emev2-kzm9d-reference.dts    |   26 +++++++++++++
 arch/arm/mach-shmobile/Kconfig                 |   12 ++++++
 arch/arm/mach-shmobile/Makefile                |    1 
 arch/arm/mach-shmobile/Makefile.boot           |    1 
 arch/arm/mach-shmobile/board-kzm9d-reference.c |   47 ++++++++++++++++++++++++
 6 files changed, 88 insertions(+)

--- 0001/arch/arm/boot/dts/Makefile
+++ work/arch/arm/boot/dts/Makefile	2013-07-08 14:24:15.000000000 +0900
@@ -160,6 +160,7 @@ dtb-$(CONFIG_ARCH_U8500) += snowball.dtb
 	hrefv60plus.dtb \
 	ccu9540.dtb
 dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
+	emev2-kzm9d-reference.dtb \
 	r8a7740-armadillo800eva.dtb \
 	r8a7778-bockw.dtb \
 	r8a7740-armadillo800eva-reference.dtb \
--- /dev/null
+++ work/arch/arm/boot/dts/emev2-kzm9d-reference.dts	2013-07-08 14:48:50.000000000 +0900
@@ -0,0 +1,26 @@
+/*
+ * Device Tree Source for the KZM9D board
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+/dts-v1/;
+
+/include/ "emev2.dtsi"
+
+/ {
+	model = "EMEV2 KZM9D Board";
+	compatible = "renesas,kzm9d-reference", "renesas,emev2";
+
+	memory {
+		device_type = "memory";
+		reg = <0x40000000 0x8000000>;
+	};
+
+	chosen {
+		bootargs = "console=ttyS1,115200n81 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096";
+	};
+};
--- 0001/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-07-08 14:24:15.000000000 +0900
@@ -167,6 +167,18 @@ config MACH_KZM9D
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select USE_OF
 
+config MACH_KZM9D_REFERENCE
+	bool "KZM9D board - Reference Device Tree Implementation"
+	depends on ARCH_EMEV2
+	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	select USE_OF
+	---help---
+	   Use reference implementation of KZM9D board support
+	   which makes a greater use of device tree at the expense
+	   of not supporting a number of devices.
+
+	   This is intended to aid developers
+
 config MACH_KZM9G
 	bool "KZM-A9-GT board"
 	depends on ARCH_SH73A0
--- 0001/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-07-08 14:24:15.000000000 +0900
@@ -47,6 +47,7 @@ obj-$(CONFIG_MACH_LAGER_REFERENCE)	+= bo
 obj-$(CONFIG_MACH_ARMADILLO800EVA)	+= board-armadillo800eva.o
 obj-$(CONFIG_MACH_ARMADILLO800EVA_REFERENCE)	+= board-armadillo800eva-reference.o
 obj-$(CONFIG_MACH_KZM9D)	+= board-kzm9d.o
+obj-$(CONFIG_MACH_KZM9D_REFERENCE)	+= board-kzm9d-reference.o
 obj-$(CONFIG_MACH_KZM9G)	+= board-kzm9g.o
 obj-$(CONFIG_MACH_KZM9G_REFERENCE)	+= board-kzm9g-reference.o
 
--- 0001/arch/arm/mach-shmobile/Makefile.boot
+++ work/arch/arm/mach-shmobile/Makefile.boot	2013-07-08 14:24:15.000000000 +0900
@@ -7,6 +7,7 @@ loadaddr-$(CONFIG_MACH_ARMADILLO800EVA_R
 loadaddr-$(CONFIG_MACH_BOCKW) += 0x60008000
 loadaddr-$(CONFIG_MACH_KOTA2) += 0x41008000
 loadaddr-$(CONFIG_MACH_KZM9D) += 0x40008000
+loadaddr-$(CONFIG_MACH_KZM9D_REFERENCE) += 0x40008000
 loadaddr-$(CONFIG_MACH_KZM9G) += 0x41008000
 loadaddr-$(CONFIG_MACH_KZM9G_REFERENCE) += 0x41008000
 loadaddr-$(CONFIG_MACH_LAGER) += 0x40008000
--- /dev/null
+++ work/arch/arm/mach-shmobile/board-kzm9d-reference.c	2013-07-08 14:49:41.000000000 +0900
@@ -0,0 +1,47 @@
+/*
+ * kzm9d board support - Reference DT implementation
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <linux/init.h>
+#include <linux/of_platform.h>
+#include <mach/emev2.h>
+#include <mach/common.h>
+#include <asm/mach/arch.h>
+
+static void __init kzm9d_add_standard_devices(void)
+{
+	emev2_clock_init();
+
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char *kzm9d_boards_compat_dt[] __initdata = {
+	"renesas,kzm9d-reference",
+	NULL,
+};
+
+DT_MACHINE_START(KZM9D_DT, "kzm9d")
+	.smp		= smp_ops(emev2_smp_ops),
+	.map_io		= emev2_map_io,
+	.init_early	= emev2_init_delay,
+	.init_machine	= kzm9d_add_standard_devices,
+	.init_late	= shmobile_init_late,
+	.dt_compat	= kzm9d_boards_compat_dt,
+MACHINE_END
+


From magnus.damm at gmail.com  Mon Jul  8 02:16:46 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 08 Jul 2013 15:16:46 +0900
Subject: [PATCH] ARM: shmobile: Minor update for the Lager DT reference code
Message-ID: <20130708061646.25516.97272.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Update the Lager DT reference code to get rid of the redundant
irqchip header and also make lager_add_standard_devices() static.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Written against "renesas-next-20130704v2"

 arch/arm/mach-shmobile/board-lager-reference.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- 0001/arch/arm/mach-shmobile/board-lager-reference.c
+++ work/arch/arm/mach-shmobile/board-lager-reference.c	2013-07-08 15:10:21.000000000 +0900
@@ -19,12 +19,11 @@
  */
 
 #include <linux/init.h>
-#include <linux/irqchip.h>
 #include <linux/of_platform.h>
 #include <mach/r8a7790.h>
 #include <asm/mach/arch.h>
 
-void __init lager_add_standard_devices(void)
+static void __init lager_add_standard_devices(void)
 {
 	/* clocks are setup late during boot in the case of DT */
 	r8a7790_clock_init();


From magnus.damm at gmail.com  Mon Jul  8 02:20:05 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Mon, 08 Jul 2013 15:20:05 +0900
Subject: [PATCH] ARM: shmobile: Fix EMEV2 clock comment typo
Message-ID: <20130708062005.25694.62165.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Update the STI timer frequency comment to 32.768 kHz to
fix 37 kHz typo.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Written against "renesas-next-20130704v2"

 arch/arm/mach-shmobile/clock-emev2.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/clock-emev2.c
+++ work/arch/arm/mach-shmobile/clock-emev2.c	2013-07-08 15:05:16.000000000 +0900
@@ -203,7 +203,7 @@ void __init emev2_clock_init(void)
 	smu_base = ioremap(EMEV2_SMU_BASE, PAGE_SIZE);
 	BUG_ON(!smu_base);
 
-	/* setup STI timer to run on 37.768 kHz and deassert reset */
+	/* setup STI timer to run on 32.768 kHz and deassert reset */
 	emev2_smu_write(0, STI_CLKSEL);
 	emev2_smu_write(1, STI_RSTCTRL);
 


From b32955 at freescale.com  Mon Jul  8 02:31:03 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 8 Jul 2013 14:31:03 +0800
Subject: [PATCH v3 4/6] ARM: dts: imx6q{dl}: fix the wrong RTS/CTS pad name
In-Reply-To: <20953.22066.706534.773272@ipc1.ka-ro>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>	<1373004752-21302-5-git-send-email-b32955@freescale.com>	<20130706050803.GC30164@S2101-09.ap.freescale.net>
 <20953.22066.706534.773272@ipc1.ka-ro>
Message-ID: <51DA5CA7.1050305@freescale.com>

? 2013?07?07? 19:51, Lothar Wa?mann ??:
> Hi,
>
> Shawn Guo writes:
>> On Fri, Jul 05, 2013 at 02:12:30PM +0800, Huang Shijie wrote:
>>> There is something wrong with the RTS/CTS pads:
>>>    The RTS pad is assigned with the CTS's value;
>>>    while the CTS pad is assigned with the RTS's value.
>>>
>> So basically, you are saying that select_input should be set up for CTS
>> rather than RTS.  It seems that the people who generated the macro got
>> the wrong input from developer.
>>
> programming 'select_input' only makes sense for inputs, not outputs.
> Since CTS is an output signal, select_input only makes sense for the
> RTS function of the pads.
Hi Lothar:

In our imx6 Soc, the CTS is used as a input signal, not as a output signal.

I checked two boards, one is imx6q ARM2 armidillo board, one is 
imx6-sabreauto board,
both the boards use the CTS as a input signal.



thanks
Huang Shijie




From m.weisser.m at gmail.com  Mon Jul  8 02:31:01 2013
From: m.weisser.m at gmail.com (=?UTF-8?Q?Matthias_Wei=C3=9Fer?=)
Date: Mon, 8 Jul 2013 08:31:01 +0200
Subject: imx25: How to get frame buffer device in a system using device
 tree
In-Reply-To: <CAOMZO5CgAs+hR41=WdJ=jxS5gZf=opOrCXufixBh_CMP0n2TFA@mail.gmail.com>
References: <CAO8h3eFq9WhvZYbbeFfWgVEXViR8MAcGaztsvvaLpFSW-W6CfA@mail.gmail.com>
 <CAOMZO5Aat-iAN_TJ6BXEopB+WCkKgLjWh67sCXg0jd1DtzmKSQ@mail.gmail.com>
 <CAO8h3eHAfV808izZzvpPc+z6iQPr14q8OmryNs5sC+VcNk+iLg@mail.gmail.com>
 <CAOMZO5CgAs+hR41=WdJ=jxS5gZf=opOrCXufixBh_CMP0n2TFA@mail.gmail.com>
Message-ID: <CAO8h3eGhF8DRO73W9GkepUKAF-6v1EmWdMS_Gq+dA_2v5mJ2aQ@mail.gmail.com>

Hi Fabio

2013/7/5 Fabio Estevam <festevam at gmail.com>:
> Hi Matthias,
>
> On Fri, Jul 5, 2013 at 4:37 AM, Matthias Wei?er <m.weisser.m at gmail.com> wrote:
>
>> Thanks for the links. That made some things clearer for me. But I am
>> still a bit confused about the driver (imxfb.c) itself. From what I
>> can see it is not dt aware as there is no of_device_id structure with
>> the compatible entries. I think I have to add dt support to the
>> framebuffer driver. Am I right?
>
> Yes, you need to apply this one:
> http://marc.info/?l=linux-fbdev&m=136956466617736&w=2

OK. Done that and it works like a charm. Thanks a lot.

> I thought it has already been applied, but it has not reached mainline yet.
>
> Regards,
>
> Fabio Estevam

Regards
Matthias


From sachin.kamat at linaro.org  Mon Jul  8 02:36:28 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Mon, 8 Jul 2013 12:06:28 +0530
Subject: [PATCH 2/3] of/documentation: Update G2D documentation
In-Reply-To: <4264635.Hmig5l0VLj@flatron>
References: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
 <1373013749-14530-2-git-send-email-sachin.kamat@linaro.org>
 <4264635.Hmig5l0VLj@flatron>
Message-ID: <CAK9yfHzG6ZPio9xytLoQpf0WCi9Fk3JnAXmsdjFGMiqGoYmXFA@mail.gmail.com>

Hi Tomasz,

On 6 July 2013 05:22, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> Hi Sachin,
>
> On Friday 05 of July 2013 14:12:28 Sachin Kamat wrote:
>> Exynos5250 G2D IP requires only the gate clock. Update the
>> binding documentation accordingly.
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
>> Cc: Inki Dae <inki.dae at samsung.com>
>> ---
>>  .../devicetree/bindings/gpu/samsung-g2d.txt        |    4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
>> b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt index
>> 3f454ff..60ca631 100644
>> --- a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
>> +++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
>> @@ -12,7 +12,9 @@ Required properties:
>>    - interrupts : G2D interrupt number to the CPU.
>>    - clocks : from common clock binding: handle to G2D clocks.
>>    - clock-names : from common clock binding: must contain "sclk_fimg2d"
>> and -           "fimg2d", corresponding to entries in the clocks
> property. +
>>  "fimg2d" for S5PV210 & Exynos4 based SoCs and "fimg2d" for +
>> Exynos5250 SoC, corresponding to entries in the clocks
>> +               property.
>
> I think this needs to be rephrased, because I can't get any sense from
> this sentence.
>
> Maybe something like:
>
> - clock-names : names of clocks listed in clocks property, in the same
> order, depending on SoC type:
>     - for S5PV210 and Exynos4 based SoCs : "fimg2d" and "sclk_fimg2d"
>     - for Exynos5250 SoC : "fimg2d".
>
> What do you think?

Sure. Will update and re-send.

Thanks for the review.


-- 
With warm regards,
Sachin


From mpa at pengutronix.de  Mon Jul  8 03:19:24 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Mon, 8 Jul 2013 09:19:24 +0200
Subject: [alsa-devel] [PATCH v9 08/10] ASoC: Add phycore-ac97-dt driver
In-Reply-To: <CAOMZO5CLWfoQE-9srT8e2kLn3A=iHhk-TbXytV+pdZVaaHwoNg@mail.gmail.com>
References: <1371734429-6081-1-git-send-email-mpa@pengutronix.de>
 <1371734429-6081-9-git-send-email-mpa@pengutronix.de>
 <20130703161727.GS27646@sirena.org.uk>
 <20130707071949.GH16871@s25.your-server.de>
 <CAOMZO5CLWfoQE-9srT8e2kLn3A=iHhk-TbXytV+pdZVaaHwoNg@mail.gmail.com>
Message-ID: <20130708071924.GP16871@s25.your-server.de>

Hi Fabio,

On Sun, Jul 07, 2013 at 10:16:30AM -0300, Fabio Estevam wrote:
> Hi Markus,
> 
> On Sun, Jul 7, 2013 at 4:19 AM, Markus Pargmann <mpa at pengutronix.de> wrote:
> 
> > There are no pinctrl driver for imx27(pca100) or imx35(pcm043). The
> 
> For mx35 pinctrl driver is at drivers/pinctrl/pinctrl-imx35.c
> 

Thank you.

I will create some pinctrl bindings for pcm043. But I am not sure what
to do with pca100 reset functions.

Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From balbi at ti.com  Mon Jul  8 03:21:09 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 8 Jul 2013 10:21:09 +0300
Subject: [PATCH v3 4/4] USB: OMAP1: Tahvo USB transceiver driver
In-Reply-To: <1371575221-360-5-git-send-email-aaro.koskinen@iki.fi>
References: <1371575221-360-1-git-send-email-aaro.koskinen@iki.fi>
 <1371575221-360-5-git-send-email-aaro.koskinen@iki.fi>
Message-ID: <20130708072109.GA16635@arwen.pp.htv.fi>

Hi,

On Tue, Jun 18, 2013 at 08:07:01PM +0300, Aaro Koskinen wrote:
> +static ssize_t vbus_state_show(struct device *device,
> +			       struct device_attribute *attr, char *buf)
> +{
> +	struct tahvo_usb *tu = dev_get_drvdata(device);
> +	return sprintf(buf, "%d\n", tu->vbus_state);
> +}
> +static DEVICE_ATTR(vbus_state, 0444, vbus_state_show, NULL);

VBUS status sounds generic enough, also, you should be printing on/off
here instead of tahvo-specific values. Some users might not have access
to the docs, or even the kernel sources, to understand what that integer
means.

> +static void tahvo_usb_become_host(struct tahvo_usb *tu)
> +{
> +	struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
> +
> +	extcon_set_cable_state(&tu->extcon, "USB-HOST", true);
> +
> +	/* Power up the transceiver in USB host mode */
> +	retu_write(rdev, TAHVO_REG_USBR, USBR_REGOUT | USBR_NSUSPEND |
> +		   USBR_MASTER_SW2 | USBR_MASTER_SW1);
> +	tu->phy.state = OTG_STATE_A_IDLE;
> +
> +	check_vbus_state(tu);
> +}
> +
> +static void tahvo_usb_stop_host(struct tahvo_usb *tu)
> +{
> +	tu->phy.state = OTG_STATE_A_IDLE;

shouldn't you undo tahvo_usb_become_host() here ? I mean, set the
transceiver to SLAVE ?

> +static int tahvo_usb_set_host(struct usb_otg *otg, struct usb_bus *host)
> +{
> +	struct tahvo_usb *tu = container_of(otg->phy, struct tahvo_usb, phy);
> +
> +	dev_dbg(&tu->pt_dev->dev, "%s %p\n", __func__, host);
> +
> +	if (otg == NULL)
> +		return -ENODEV;
> +
> +	mutex_lock(&tu->serialize);
> +
> +	if (host == NULL) {
> +		if (tu->tahvo_mode == TAHVO_MODE_HOST)
> +			tahvo_usb_power_off(tu);
> +		otg->host = NULL;
> +		mutex_unlock(&tu->serialize);
> +		return 0;
> +	}
> +
> +	if (tu->tahvo_mode == TAHVO_MODE_HOST) {
> +		otg->host = NULL;
> +		tahvo_usb_become_host(tu);
> +	}
> +
> +	otg->host = host;
> +
> +	mutex_unlock(&tu->serialize);
> +
> +	return 0;
> +}
> +
> +static int tahvo_usb_set_peripheral(struct usb_otg *otg,
> +				    struct usb_gadget *gadget)

I want to get rid of the extra 'gadget' and 'host' parameters on
->set_host() and ->set_peripheral(). Nobody really uses them other than:

my_phy->phy.otg->{gadget,host} = {gadget,host};

For that, I need all other PHYs to stop relying on those parameters and
I'll cook patches for that for v3.12 merge window.

> +static ssize_t otg_mode_store(struct device *device,
> +			      struct device_attribute *attr,
> +			      const char *buf, size_t count)
> +{
> +	struct tahvo_usb *tu = dev_get_drvdata(device);
> +	int r;
> +
> +	mutex_lock(&tu->serialize);
> +	if (count >= 4 && strncmp(buf, "host", 4) == 0) {
> +		if (tu->tahvo_mode == TAHVO_MODE_PERIPHERAL)
> +			tahvo_usb_stop_peripheral(tu);
> +		tu->tahvo_mode = TAHVO_MODE_HOST;
> +		if (tu->phy.otg->host) {
> +			dev_info(device, "HOST mode: host controller present\n");
> +			tahvo_usb_become_host(tu);
> +		} else {
> +			dev_info(device, "HOST mode: no host controller, powering off\n");
> +			tahvo_usb_power_off(tu);
> +		}
> +		r = strlen(buf);
> +	} else if (count >= 10 && strncmp(buf, "peripheral", 10) == 0) {
> +		if (tu->tahvo_mode == TAHVO_MODE_HOST)
> +			tahvo_usb_stop_host(tu);
> +		tu->tahvo_mode = TAHVO_MODE_PERIPHERAL;
> +		if (tu->phy.otg->gadget) {
> +			dev_info(device, "PERIPHERAL mode: gadget driver present\n");
> +			tahvo_usb_become_peripheral(tu);
> +		} else {
> +			dev_info(device, "PERIPHERAL mode: no gadget driver, powering off\n");
> +			tahvo_usb_power_off(tu);
> +		}
> +		r = strlen(buf);
> +	} else {
> +		r = -EINVAL;
> +	}
> +	mutex_unlock(&tu->serialize);
> +
> +	return r;
> +}
> +
> +static DEVICE_ATTR(otg_mode, 0644, otg_mode_show, otg_mode_store);

this looks like something which would be very nice if implemented
generically. Since you, anyway miss the documentation in
Documentation/ABI/ and need to respin the patch, how about making this
generic ?

> +static int tahvo_usb_probe(struct platform_device *pdev)
> +{
> +	struct retu_dev *rdev = dev_get_drvdata(pdev->dev.parent);
> +	struct tahvo_usb *tu;
> +	int ret;
> +
> +	tu = devm_kzalloc(&pdev->dev, sizeof(*tu), GFP_KERNEL);
> +	if (!tu)
> +		return -ENOMEM;
> +
> +	tu->phy.otg = devm_kzalloc(&pdev->dev, sizeof(*tu->phy.otg),
> +				   GFP_KERNEL);
> +	if (!tu->phy.otg)
> +		return -ENOMEM;
> +
> +	tu->pt_dev = pdev;
> +
> +	/* Default mode */
> +#ifdef CONFIG_TAHVO_USB_HOST_BY_DEFAULT
> +	tu->tahvo_mode = TAHVO_MODE_HOST;
> +#else
> +	tu->tahvo_mode = TAHVO_MODE_PERIPHERAL;
> +#endif

should you call become_host()/become_peripheral() here ?

> +	mutex_init(&tu->serialize);
> +
> +	tu->ick = devm_clk_get(&pdev->dev, "usb_l4_ick");
> +	if (!IS_ERR(tu->ick))
> +		clk_enable(tu->ick);
> +
> +	/*
> +	 * Set initial state, so that we generate kevents only on state changes.
> +	 */
> +	tu->vbus_state = retu_read(rdev, TAHVO_REG_IDSR) & TAHVO_STAT_VBUS;
> +
> +	tu->extcon.name = DRIVER_NAME;
> +	tu->extcon.supported_cable = tahvo_cable;
> +	ret = extcon_dev_register(&tu->extcon, &pdev->dev);
> +	if (ret) {
> +		dev_err(&pdev->dev, "could not register extcon device: %d\n",
> +			ret);
> +		return ret;
> +	}
> +
> +	/* Set the initial cable state. */
> +	extcon_set_cable_state(&tu->extcon, "USB-HOST",
> +			       tu->tahvo_mode == TAHVO_MODE_HOST);
> +	extcon_set_cable_state(&tu->extcon, "USB", tu->vbus_state);
> +
> +	tu->irq = platform_get_irq(pdev, 0);
> +	ret = request_threaded_irq(tu->irq, NULL, tahvo_usb_vbus_interrupt, 0,
> +				   "tahvo-vbus", tu);

since your hardirq handler is NULL, you *must* pass IRQF_ONESHOT. /Could
also use devm_request_threaded_irq()

> +	if (ret) {
> +		dev_err(&pdev->dev, "could not register tahvo-vbus irq: %d\n",
> +			ret);
> +		goto err_disable_clk;
> +	}
> +
> +	/* Attributes */
> +	ret = device_create_file(&pdev->dev, &dev_attr_vbus_state);
> +	ret |= device_create_file(&pdev->dev, &dev_attr_otg_mode);

heh, Greg wrote a very interesting article recently (look at his blog)
discussing kernel/userland races wrt creation of sysfs files.

> +	/* Create OTG interface */
> +	tahvo_usb_power_off(tu);
> +	tu->phy.dev = &pdev->dev;
> +	tu->phy.state = OTG_STATE_UNDEFINED;
> +	tu->phy.label = DRIVER_NAME;
> +	tu->phy.set_suspend = tahvo_usb_set_suspend;
> +
> +	tu->phy.otg->phy = &tu->phy;
> +	tu->phy.otg->set_host = tahvo_usb_set_host;
> +	tu->phy.otg->set_peripheral = tahvo_usb_set_peripheral;
> +
> +	ret = usb_add_phy(&tu->phy, USB_PHY_TYPE_USB2);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "cannot register USB transceiver: %d\n",
> +			ret);
> +		goto err_free_irq;
> +	}
> +
> +	dev_set_drvdata(&pdev->dev, tu);

what if someone accesses the sysfs file you've already created before
you call dev_set_drvdata? (not sure  if it's possible).

-- 
balbi
-------------- 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/20130708/fbd977f2/attachment.sig>

From t-kristo at ti.com  Mon Jul  8 03:28:56 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Mon, 8 Jul 2013 10:28:56 +0300
Subject: [PATCH 2/4] ARM: OMAP5: clockdomain data: add init file for
 omap54xx
In-Reply-To: <20130628210351.14831.19618@quantum>
References: <1372322299-25046-1-git-send-email-t-kristo@ti.com>
 <1372322299-25046-3-git-send-email-t-kristo@ti.com>
 <20130628210351.14831.19618@quantum>
Message-ID: <51DA6A38.8010503@ti.com>

On 06/29/2013 12:03 AM, Mike Turquette wrote:
> Quoting Tero Kristo (2013-06-27 01:38:17)
>> cclock54xx_data.c now contains only init function and the clkdev mapping
>> that is still needed by some drivers. Eventually most of this file can
>> be removed, once a common location for the clk init can be found, and
>> the clkdev mapping is no longer needed.
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> ---
>>   arch/arm/mach-omap2/cclock54xx_data.c |   80 +++++++++++++++++++++++++++++++++
>>   1 file changed, 80 insertions(+)
>>   create mode 100644 arch/arm/mach-omap2/cclock54xx_data.c
>>
>> diff --git a/arch/arm/mach-omap2/cclock54xx_data.c b/arch/arm/mach-omap2/cclock54xx_data.c
>> new file mode 100644
>
> Why not drivers/clk/omap/clk-omap54xx.c?

Hey Mike,

I can move this over in the next rev. I can do the same for the 
cclock44xx_data.c file in the O4 series.

-Tero

>
> Regards,
> Mike
>
>> index 0000000..f23f44e
>> --- /dev/null
>> +++ b/arch/arm/mach-omap2/cclock54xx_data.c
>> @@ -0,0 +1,74 @@
>> +/*
>> + * OMAP54xx Clock data
>> + *
>> + * Copyright (C) 2013 Texas Instruments, Inc.
>> + *
>> + * Paul Walmsley (paul at pwsan.com)
>> + * Rajendra Nayak (rnayak at ti.com)
>> + * Benoit Cousson (b-cousson at ti.com)
>> + * Mike Turquette (mturquette at linaro.org)
>> + * Tero Kristo (t-kristo at ti.com)
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/list.h>
>> +#include <linux/clkdev.h>
>> +#include <linux/io.h>
>> +#include <linux/clk-provider.h>
>> +#include <linux/clk/omap.h>
>> +
>> +#include "soc.h"
>> +#include "clock.h"
>> +
>> +#define OMAP5_DPLL_ABE_DEFFREQ                         98304000
>> +
>> +/*
>> + * clkdev
>> + */
>> +static struct omap_dt_clk omap54xx_clks[] = {
>> +       DT_CLK(NULL,    "timer_32k_ck", "sys_32k_ck"),
>> +       DT_CLK("omap_timer.1",  "sys_ck",               "sys_clkin"),
>> +       DT_CLK("omap_timer.2",  "sys_ck",               "sys_clkin"),
>> +       DT_CLK("omap_timer.3",  "sys_ck",               "sys_clkin"),
>> +       DT_CLK("omap_timer.4",  "sys_ck",               "sys_clkin"),
>> +       DT_CLK("omap_timer.9",  "sys_ck",               "sys_clkin"),
>> +       DT_CLK("omap_timer.10", "sys_ck",               "sys_clkin"),
>> +       DT_CLK("omap_timer.11", "sys_ck",               "sys_clkin"),
>> +       DT_CLK("omap_timer.5",  "sys_ck",               "dss_syc_gfclk_div"),
>> +       DT_CLK("omap_timer.6",  "sys_ck",               "dss_syc_gfclk_div"),
>> +       DT_CLK("omap_timer.7",  "sys_ck",               "dss_syc_gfclk_div"),
>> +       DT_CLK("omap_timer.8",  "sys_ck",               "dss_syc_gfclk_div"),
>> +};
>> +
>> +int __init omap5xxx_clk_init(void)
>> +{
>> +       struct clk *abe_dpll_ref, *sys_32k_ck, *abe_dpll;
>> +       int rc;
>> +
>> +       /*
>> +        * Must stay commented until all OMAP SoC drivers are
>> +        * converted to runtime PM, or drivers may start crashing
>> +        *
>> +        * omap2_clk_disable_clkdm_control();
>> +        */
>> +       dt_omap_clk_init();
>> +
>> +       omap_dt_clocks_register(omap54xx_clks, ARRAY_SIZE(omap54xx_clks));
>> +
>> +       omap2_clk_disable_autoidle_all();
>> +
>> +       abe_dpll_ref = clk_get_sys(NULL, "abe_dpll_clk_mux");
>> +       sys_32k_ck = clk_get_sys(NULL, "sys_32k_ck");
>> +       rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
>> +       abe_dpll = clk_get_sys(NULL, "dpll_abe_ck");
>> +       if (!rc)
>> +               rc = clk_set_rate(abe_dpll, OMAP5_DPLL_ABE_DEFFREQ);
>> +       if (rc)
>> +               pr_err("%s: failed to configure ABE DPLL!\n", __func__);
>> +
>> +       return 0;
>> +}
>> --
>> 1.7.9.5



From t-kristo at ti.com  Mon Jul  8 03:29:28 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Mon, 8 Jul 2013 10:29:28 +0300
Subject: [PATCH 4/4] ARM: DRA7: clockdomain data: add init file for dra7
In-Reply-To: <20130628210430.14831.99127@quantum>
References: <1372322299-25046-1-git-send-email-t-kristo@ti.com>
 <1372322299-25046-5-git-send-email-t-kristo@ti.com>
 <20130628210430.14831.99127@quantum>
Message-ID: <51DA6A58.3080008@ti.com>

On 06/29/2013 12:04 AM, Mike Turquette wrote:
> Quoting Tero Kristo (2013-06-27 01:38:19)
>> cclock7xx_data.c now contains only init function and the clkdev mapping
>> that is still needed by some drivers. Eventually most of this file can
>> be removed, once a common location for the clk init can be found, and
>> the clkdev mapping is no longer needed.
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> ---
>>   arch/arm/mach-omap2/cclock7xx_data.c |   93 ++++++++++++++++++++++++++++++++++
>>   1 file changed, 93 insertions(+)
>>   create mode 100644 arch/arm/mach-omap2/cclock7xx_data.c
>
> Why not drivers/clk/omap/clk-dra7xx.c?

Hi Mike,

Same as O5, I can move this over in next rev.

-Tero

>
> Regards,
> Mike
>
>>
>> diff --git a/arch/arm/mach-omap2/cclock7xx_data.c b/arch/arm/mach-omap2/cclock7xx_data.c
>> new file mode 100644
>> index 0000000..dba528a
>> --- /dev/null
>> +++ b/arch/arm/mach-omap2/cclock7xx_data.c
>> @@ -0,0 +1,83 @@
>> +/*
>> + * DRA7xx Clock data
>> + *
>> + * Copyright (C) 2013 Texas Instruments, Inc.
>> + *
>> + * Paul Walmsley (paul at pwsan.com)
>> + * Rajendra Nayak (rnayak at ti.com)
>> + * Benoit Cousson (b-cousson at ti.com)
>> + * Mike Turquette (mturquette at linaro.org)
>> + * Tero Kristo (t-kristo at ti.com)
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/list.h>
>> +#include <linux/clk-provider.h>
>> +#include <linux/clkdev.h>
>> +#include <linux/io.h>
>> +#include <linux/clk/omap.h>
>> +
>> +#include "soc.h"
>> +#include "clock.h"
>> +
>> +#define DRA7_DPLL_ABE_DEFFREQ                  361267200
>> +#define DRA7_DPLL_GMAC_DEFFREQ                 1000000000
>> +
>> +/*
>> + * clkdev
>> + */
>> +
>> +static struct omap_dt_clk dra7xx_clks[] = {
>> +       DT_CLK(NULL,    "timer_32k_ck",         "sys_32k_ck"),
>> +       DT_CLK("4ae18000.timer",        "timer_sys_ck",         "sys_clkin2"),
>> +       DT_CLK("48032000.timer",        "timer_sys_ck",         "sys_clkin2"),
>> +       DT_CLK("48034000.timer",        "timer_sys_ck",         "sys_clkin2"),
>> +       DT_CLK("48036000.timer",        "timer_sys_ck",         "sys_clkin2"),
>> +       DT_CLK("4803e000.timer",        "timer_sys_ck",         "sys_clkin2"),
>> +       DT_CLK("48086000.timer",        "timer_sys_ck",         "sys_clkin2"),
>> +       DT_CLK("48088000.timer",        "timer_sys_ck",         "sys_clkin2"),
>> +       DT_CLK("48820000.timer",        "timer_sys_ck",         "timer_sys_clk_div"),
>> +       DT_CLK("48822000.timer",        "timer_sys_ck",         "timer_sys_clk_div"),
>> +       DT_CLK("48824000.timer",        "timer_sys_ck",         "timer_sys_clk_div"),
>> +       DT_CLK("48826000.timer",        "timer_sys_ck",         "timer_sys_clk_div"),
>> +       DT_CLK(NULL,       "sys_clkin",                    "sys_clkin1"),
>> +};
>> +
>> +int __init dra7xx_clk_init(void)
>> +{
>> +       struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck;
>> +       int rc;
>> +       /*
>> +        * Must stay commented until all OMAP SoC drivers are
>> +        * converted to runtime PM, or drivers may start crashing
>> +        *
>> +        * omap2_clk_disable_clkdm_control();
>> +        */
>> +
>> +       dt_omap_clk_init();
>> +
>> +       omap_dt_clocks_register(dra7xx_clks, ARRAY_SIZE(dra7xx_clks));
>> +
>> +       omap2_clk_disable_autoidle_all();
>> +
>> +       abe_dpll_mux = clk_get_sys(NULL, "abe_dpll_sys_clk_mux");
>> +       sys_clkin2 = clk_get_sys(NULL, "sys_clkin2");
>> +       dpll_ck = clk_get_sys(NULL, "dpll_abe_ck");
>> +
>> +       rc = clk_set_parent(abe_dpll_mux, sys_clkin2);
>> +       if (!rc)
>> +               rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ);
>> +       if (rc)
>> +               pr_err("%s: failed to configure ABE DPLL!\n", __func__);
>> +
>> +       dpll_ck = clk_get_sys(NULL, "dpll_gmac_ck");
>> +       rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
>> +       if (rc)
>> +               pr_err("%s: failed to configure GMAC DPLL!\n", __func__);
>> +
>> +       return 0;
>> +}
>> --
>> 1.7.9.5



From LW at KARO-electronics.de  Mon Jul  8 03:32:16 2013
From: LW at KARO-electronics.de (=?utf-8?Q?Lothar_Wa=C3=9Fmann?=)
Date: Mon, 8 Jul 2013 09:32:16 +0200
Subject: [PATCH v3 4/6] ARM: dts: imx6q{dl}: fix the wrong RTS/CTS pad name
In-Reply-To: <51DA5CA7.1050305@freescale.com>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>
 <1373004752-21302-5-git-send-email-b32955@freescale.com>
 <20130706050803.GC30164@S2101-09.ap.freescale.net>
 <20953.22066.706534.773272@ipc1.ka-ro>
 <51DA5CA7.1050305@freescale.com>
Message-ID: <20954.27392.875173.755391@ipc1.ka-ro>

Hi,

Huang Shijie writes:
> ? 2013?07?07? 19:51, Lothar Wa?mann ??:
> > Hi,
> >
> > Shawn Guo writes:
> >> On Fri, Jul 05, 2013 at 02:12:30PM +0800, Huang Shijie wrote:
> >>> There is something wrong with the RTS/CTS pads:
> >>>    The RTS pad is assigned with the CTS's value;
> >>>    while the CTS pad is assigned with the RTS's value.
> >>>
> >> So basically, you are saying that select_input should be set up for CTS
> >> rather than RTS.  It seems that the people who generated the macro got
> >> the wrong input from developer.
> >>
> > programming 'select_input' only makes sense for inputs, not outputs.
> > Since CTS is an output signal, select_input only makes sense for the
> > RTS function of the pads.
> Hi Lothar:
> 
> In our imx6 Soc, the CTS is used as a input signal, not as a output signal.
> 
> I checked two boards, one is imx6q ARM2 armidillo board, one is 
> imx6-sabreauto board,
> both the boards use the CTS as a input signal.
> 
that's the problem with the DTE/DCE mode. Depending on the DCEDTE bit
in the UARTx_UFCR we would need different pad configurations for
RTS/CTS because in DCE mode CTS is an output and in DTE mode it's an
input.
Thus the correct pad config value would need the input_sel on the CTS
pad definition for DTE mode and on the RTS pad definition for DCE
mode. Maybe something like:
#define MX6Q_PAD_EIM_D19__UART1_DCE_CTS_B             0x09c 0x3b0 0x000 0x4 0x0
#define MX6Q_PAD_EIM_D19__UART1_DCE_RTS_B             0x09c 0x3b0 0x91c 0x4 0x0
#define MX6Q_PAD_EIM_D19__UART1_DTE_CTS_B             0x09c 0x3b0 0x91c 0x4 0x0
#define MX6Q_PAD_EIM_D19__UART1_DTE_RTS_B             0x09c 0x3b0 0x000 0x4 0x0


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________


From wni at nvidia.com  Mon Jul  8 03:35:48 2013
From: wni at nvidia.com (Wei Ni)
Date: Mon, 8 Jul 2013 15:35:48 +0800
Subject: [PATCH 1/2] ARM: dt: t30 cardhu: add dt entry for lm90
In-Reply-To: <51D70483.70203@wwwdotorg.org>
References: <1372928979-26938-1-git-send-email-wni@nvidia.com>
 <1372928979-26938-2-git-send-email-wni@nvidia.com>
 <51D70483.70203@wwwdotorg.org>
Message-ID: <51DA6BD4.1040300@nvidia.com>

On 07/06/2013 01:38 AM, Stephen Warren wrote:
> On 07/04/2013 03:09 AM, Wei Ni wrote:
>> Enable thermal sensor lm90 for t30 cardhu.
> 
>> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
> 
>> +		nct1008: nct1008 {
>> +			compatible = "lm90,nct1008";
> 
> "lm90" isn't a valid vendor prefix. I believe the value you want is
> "onnn,nct1008". Same comment for patch 2/2.
> 
The lm90 doesn't support device tree very well. In the DT, we need to
named as "lm90" so that the lm90 driver can be loaded, and we also need
to add "nct1008" to indicate this is the nct1008 device, so that the
lm90 driver can be loaded with the right i2c_device_id->driver_data.

I set the " compatible = "lm90,nct1008" ", this is the simplest way, and
we doesn't need to change the lm90.c.

Thanks.
Wei.


From balbi at ti.com  Mon Jul  8 03:41:33 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 8 Jul 2013 10:41:33 +0300
Subject: [PATCH 1/4] usb: gadget: s3c-hsotg: Allow driver instantiation
 using device tree
In-Reply-To: <1372174706-5459-2-git-send-email-t.figa@samsung.com>
References: <1372174706-5459-1-git-send-email-t.figa@samsung.com>
 <1372174706-5459-2-git-send-email-t.figa@samsung.com>
Message-ID: <20130708074133.GC16635@arwen.pp.htv.fi>

Hi,

On Tue, Jun 25, 2013 at 05:38:23PM +0200, Tomasz Figa wrote:
> This patch adds OF match table to the driver to allow instantiating it
> using device tree.
> 
> Signed-off-by: Tomasz Figa <t.figa at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>

I will take this one only, the others have no dependency on this.

cheers

-- 
balbi
-------------- 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/20130708/d89b23b8/attachment.sig>

From b32955 at freescale.com  Mon Jul  8 03:16:03 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 8 Jul 2013 15:16:03 +0800
Subject: [PATCH] ARM: imx_v6_v7_defconfig: enable WEIM driver
Message-ID: <1373267763-28440-1-git-send-email-b32955@freescale.com>

enable the weim driver.
Since the NOR is connected to the WEIM for imx6q{dl}-sabreauto,
we also enable the MTD_PHYSMAP_OF module.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/configs/imx_v6_v7_defconfig |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f64b6a2..f1662d3 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -68,6 +68,7 @@ CONFIG_NETFILTER=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_STANDALONE is not set
+CONFIG_IMX_WEIM=y
 CONFIG_CONNECTOR=y
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
@@ -78,6 +79,7 @@ CONFIG_MTD_JEDECPROBE=y
 CONFIG_MTD_CFI_INTELEXT=y
 CONFIG_MTD_CFI_AMDSTD=y
 CONFIG_MTD_CFI_STAA=y
+CONFIG_MTD_PHYSMAP_OF=y
 CONFIG_MTD_DATAFLASH=y
 CONFIG_MTD_M25P80=y
 CONFIG_MTD_SST25L=y
-- 
1.7.1




From khali at linux-fr.org  Mon Jul  8 03:50:24 2013
From: khali at linux-fr.org (Jean Delvare)
Date: Mon, 8 Jul 2013 09:50:24 +0200
Subject: [lm-sensors] [PATCH 1/2] ARM: dt: t30 cardhu: add dt entry for
 lm90
In-Reply-To: <51DA6BD4.1040300@nvidia.com>
References: <1372928979-26938-1-git-send-email-wni@nvidia.com>
 <1372928979-26938-2-git-send-email-wni@nvidia.com>
 <51D70483.70203@wwwdotorg.org> <51DA6BD4.1040300@nvidia.com>
Message-ID: <20130708095024.041a6d57@endymion.delvare>

On Mon, 8 Jul 2013 15:35:48 +0800, Wei Ni wrote:
> On 07/06/2013 01:38 AM, Stephen Warren wrote:
> > On 07/04/2013 03:09 AM, Wei Ni wrote:
> >> Enable thermal sensor lm90 for t30 cardhu.
> > 
> >> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
> > 
> >> +		nct1008: nct1008 {
> >> +			compatible = "lm90,nct1008";
> > 
> > "lm90" isn't a valid vendor prefix. I believe the value you want is
> > "onnn,nct1008". Same comment for patch 2/2.
> 
> The lm90 doesn't support device tree very well.

I doubt it, but if this is the case, then please fix it, instead of
working the problem around in a different place.

> In the DT, we need to
> named as "lm90" so that the lm90 driver can be loaded,

Not that I am an expert with regards to DT, but this doesn't make any
sense to me. AFAIK DT is about devices, not which drivers handle them.

> and we also need
> to add "nct1008" to indicate this is the nct1008 device, so that the
> lm90 driver can be loaded with the right i2c_device_id->driver_data.
> 
> I set the " compatible = "lm90,nct1008" ", this is the simplest way, and
> we doesn't need to change the lm90.c.

There's no problem with changing the lm90 driver, if this is the right
thing to do.

-- 
Jean Delvare


From olof at lixom.net  Mon Jul  8 03:52:16 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Jul 2013 00:52:16 -0700
Subject: [PATCH] dmaengine: shdma: fix a build failure on platforms with
 no DMA support
In-Reply-To: <20130705045350.GA10947@intel.com>
References: <Pine.LNX.4.64.1305301650290.29171@axis700.grange>
 <51A77CF1.7040105@ti.com> <20130531024438.GB32564@verge.net.au>
 <CAGa+x8413povhYWx+BSj=TdzQDAuYFXmjF4A2kXvQt+=n+380w@mail.gmail.com>
 <Pine.LNX.4.64.1306192125480.12502@axis700.grange>
 <20130705045350.GA10947@intel.com>
Message-ID: <CAOesGMjp4Ort89z8ZhQT9xAPNyG-0uU-kz9G2f_GzRFF-Y2MxA@mail.gmail.com>

On Thu, Jul 4, 2013 at 9:53 PM, Vinod Koul <vinod.koul at intel.com> wrote:
> On Wed, Jun 19, 2013 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
>> Hi Vinod
>>
>> On Wed, 19 Jun 2013, Kevin Hilman wrote:
>>
>> > On Thu, May 30, 2013 at 7:44 PM, Simon Horman <horms at verge.net.au> wrote:
>> >
>> > [...]
>> >
>> > > thanks for this. I will wait for a refresh (as we discussed earlier today).
>> > > Can I confirm that this is a fix for v3.10? If so, could ou note
>> > > that when you post your revised patch?
>> >
>> > Any progress on this patch?
>> >
>> > The SH-mobile defconfigs are still all failing in linux-next.
>>
>> In
>>
>> https://patchwork.kernel.org/patch/2640061/
> And you havent CC maintainers on this patch, so I dont have it!
>>
>> I proposed a simple immediate fix for this problem. Arnd at the same time
>> developed an alternative solution:
>>
>> https://patchwork.kernel.org/patch/2644121/
>> https://patchwork.kernel.org/patch/2644111/
> Reading these patches I agree with Arnd that client drivers should not depend on
> dma slave drivers. Existing issue need to be fixed
>
> Arnd, Have you merged these changes?

Looks like we now have breakage in linux-next for this again (new
breakage due to the header file move being applied by you on Friday,
Vinod? Are you planning on sending the code in for 3.11? If not, you
shouldn't apply patches right now).

bockw_defconfig, kota2_defconfig, marzen_defconfig and others are
currently broken.

-Olof


From linux at arm.linux.org.uk  Mon Jul  8 03:50:04 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Jul 2013 08:50:04 +0100
Subject: [PATCH v3 4/6] ARM: dts: imx6q{dl}: fix the wrong RTS/CTS pad name
In-Reply-To: <20953.22066.706534.773272@ipc1.ka-ro>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>
 <1373004752-21302-5-git-send-email-b32955@freescale.com>
 <20130706050803.GC30164@S2101-09.ap.freescale.net>
 <20953.22066.706534.773272@ipc1.ka-ro>
Message-ID: <20130708075004.GR24642@n2100.arm.linux.org.uk>

On Sun, Jul 07, 2013 at 01:51:14PM +0200, Lothar Wa?mann wrote:
> Hi,
> 
> Shawn Guo writes:
> > On Fri, Jul 05, 2013 at 02:12:30PM +0800, Huang Shijie wrote:
> > > There is something wrong with the RTS/CTS pads:
> > >   The RTS pad is assigned with the CTS's value;
> > >   while the CTS pad is assigned with the RTS's value.
> > > 
> > 
> > So basically, you are saying that select_input should be set up for CTS
> > rather than RTS.  It seems that the people who generated the macro got
> > the wrong input from developer.
> > 
> programming 'select_input' only makes sense for inputs, not outputs.
> Since CTS is an output signal, select_input only makes sense for the
> RTS function of the pads.

Note: If you are a DTE, then RTS is an output, CTS is an input.  If you
are a DCE, then RTS is an input and CTS is an output (normally on a
standard UART, you just swap the wiring for RTS and CTS but really that's
all that is going on.)  So swapping them in software should be acceptable
too, provided you're not having to disable any auto flow control facilities.


From richard.genoud at gmail.com  Mon Jul  8 03:55:48 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon, 8 Jul 2013 09:55:48 +0200
Subject: [RFC PATCH 08/13] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <51DA1D75.2010503@atmel.com>
References: <1372667978-4718-1-git-send-email-richard.genoud@gmail.com>
 <1372667978-4718-9-git-send-email-richard.genoud@gmail.com>
 <51D2472B.2010407@atmel.com>
 <CACQ1gAji8KkjXee8o=9jt8O38611LBJ95yXimxbfn1qLaLOcnA@mail.gmail.com>
 <51DA1D75.2010503@atmel.com>
Message-ID: <CACQ1gAjYOutkdn1J=HSY3i95TNU-WyJzTZPcb6QLykT53O3a2w@mail.gmail.com>

2013/7/8 Bo Shen <voice.shen at atmel.com>:
> Hi Richard,
>
>
> On 7/5/2013 23:15, Richard Genoud wrote:
>>>>
>>>> +       card->dev = &pdev->dev;
>>>> >>+       card->owner = THIS_MODULE;
>>>> >>+       card->dai_link = dai;
>>>> >>+       card->num_links = 1;
>>>> >>+       dai->name = "WM8731";
>>>> >>+       dai->stream_name = "WM8731 PCM";
>>>> >>+       dai->codec_dai_name = "wm8731-hifi";
>>>> >>+       dai->init = at91sam9x5ek_wm8731_init;
>>>> >>+       card->dapm_widgets = at91sam9x5ek_dapm_widgets;
>>>> >>+       card->num_dapm_widgets =
>>>> >> ARRAY_SIZE(at91sam9x5ek_dapm_widgets);
>>>
>>> >
>>> >
>>> >Will keep these as snd_soc_card and snd_soc_dai_link structure
>>> > separately?
>>
>> I don't really understand what you mean here.
>> do you mean that something like that will more explicit ? :
>> +       card->dai_link[0].name = "WM8731";
>> +       card->dai_link[0].stream_name = "WM8731 PCM";
>> +       card->dai_link[0].codec_dai_name = "wm8731-hifi";
>> +       card->dai_link[0].init = at91sam9x5ek_wm8731_init;
>>
>
> I mean using structure to define snd_soc_card and snd_soc_dai_link, look
> like:
> struct snd_soc_dai_link dai_link_name = {
>         .name = xxx,
>         .stream_name = xxx,
>         ...
> };
>
> struct snd_soc_card card_name = {
>         .name = xxxx
>         .ower = THIS_MODULE,
>         .dai_link = &dai_link_name,
>         ...
> };
>
> In this way, I think it will be more clear than put them in code.

ok, got it !

Thanks !

Richard.


From vinod.koul at intel.com  Mon Jul  8 03:21:14 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 8 Jul 2013 12:51:14 +0530
Subject: [PATCH] dmaengine: shdma: fix a build failure on platforms
 with no DMA support
In-Reply-To: <CAOesGMjp4Ort89z8ZhQT9xAPNyG-0uU-kz9G2f_GzRFF-Y2MxA@mail.gmail.com>
References: <Pine.LNX.4.64.1305301650290.29171@axis700.grange>
 <51A77CF1.7040105@ti.com> <20130531024438.GB32564@verge.net.au>
 <CAGa+x8413povhYWx+BSj=TdzQDAuYFXmjF4A2kXvQt+=n+380w@mail.gmail.com>
 <Pine.LNX.4.64.1306192125480.12502@axis700.grange>
 <20130705045350.GA10947@intel.com>
 <CAOesGMjp4Ort89z8ZhQT9xAPNyG-0uU-kz9G2f_GzRFF-Y2MxA@mail.gmail.com>
Message-ID: <20130708072114.GF16653@intel.com>

On Mon, Jul 08, 2013 at 12:52:16AM -0700, Olof Johansson wrote:
> On Thu, Jul 4, 2013 at 9:53 PM, Vinod Koul <vinod.koul at intel.com> wrote:
> > On Wed, Jun 19, 2013 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
> >> Hi Vinod
> >>
> >> On Wed, 19 Jun 2013, Kevin Hilman wrote:
> >>
> >> > On Thu, May 30, 2013 at 7:44 PM, Simon Horman <horms at verge.net.au> wrote:
> >> >
> >> > [...]
> >> >
> >> > > thanks for this. I will wait for a refresh (as we discussed earlier today).
> >> > > Can I confirm that this is a fix for v3.10? If so, could ou note
> >> > > that when you post your revised patch?
> >> >
> >> > Any progress on this patch?
> >> >
> >> > The SH-mobile defconfigs are still all failing in linux-next.
> >>
> >> In
> >>
> >> https://patchwork.kernel.org/patch/2640061/
> > And you havent CC maintainers on this patch, so I dont have it!
> >>
> >> I proposed a simple immediate fix for this problem. Arnd at the same time
> >> developed an alternative solution:
> >>
> >> https://patchwork.kernel.org/patch/2644121/
> >> https://patchwork.kernel.org/patch/2644111/
> > Reading these patches I agree with Arnd that client drivers should not depend on
> > dma slave drivers. Existing issue need to be fixed
> >
> > Arnd, Have you merged these changes?
> 
> Looks like we now have breakage in linux-next for this again (new
> breakage due to the header file move being applied by you on Friday,
> Vinod? Are you planning on sending the code in for 3.11? If not, you
> shouldn't apply patches right now).
Well they were already in my tree since 18th June. (tree was rebased to fixup for
pull on friday) and now these are in Linus's tree.

Can we have a fix for breakage for now sent to linus for now and then address the
proper way to do this?

~Vinod


From LW at KARO-electronics.de  Mon Jul  8 04:03:49 2013
From: LW at KARO-electronics.de (=?utf-8?Q?Lothar_Wa=C3=9Fmann?=)
Date: Mon, 8 Jul 2013 10:03:49 +0200
Subject: [PATCH v3 4/6] ARM: dts: imx6q{dl}: fix the wrong RTS/CTS pad name
In-Reply-To: <20130708075004.GR24642@n2100.arm.linux.org.uk>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>
 <1373004752-21302-5-git-send-email-b32955@freescale.com>
 <20130706050803.GC30164@S2101-09.ap.freescale.net>
 <20953.22066.706534.773272@ipc1.ka-ro>
 <20130708075004.GR24642@n2100.arm.linux.org.uk>
Message-ID: <20954.29285.732132.959465@ipc1.ka-ro>

Hi,

Russell King - ARM Linux writes:
> On Sun, Jul 07, 2013 at 01:51:14PM +0200, Lothar Wa?mann wrote:
> > Hi,
> > 
> > Shawn Guo writes:
> > > On Fri, Jul 05, 2013 at 02:12:30PM +0800, Huang Shijie wrote:
> > > > There is something wrong with the RTS/CTS pads:
> > > >   The RTS pad is assigned with the CTS's value;
> > > >   while the CTS pad is assigned with the RTS's value.
> > > > 
> > > 
> > > So basically, you are saying that select_input should be set up for CTS
> > > rather than RTS.  It seems that the people who generated the macro got
> > > the wrong input from developer.
> > > 
> > programming 'select_input' only makes sense for inputs, not outputs.
> > Since CTS is an output signal, select_input only makes sense for the
> > RTS function of the pads.
> 
> Note: If you are a DTE, then RTS is an output, CTS is an input.  If you
> are a DCE, then RTS is an input and CTS is an output (normally on a
> standard UART, you just swap the wiring for RTS and CTS but really that's
> all that is going on.)  So swapping them in software should be acceptable
> too, provided you're not having to disable any auto flow control facilities.
>
Freescale had decided to implement their UARTs on the i.MX SoCs as DCE
and later added a bit to switch between DCE and DTE mode. That's where
all the confusion comes from.


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________


From g.liakhovetski at gmx.de  Mon Jul  8 04:13:49 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Mon, 8 Jul 2013 10:13:49 +0200 (CEST)
Subject: [PATCH] dmaengine: shdma: fix a build failure on platforms with
 no DMA support
In-Reply-To: <20130705045350.GA10947@intel.com>
References: <Pine.LNX.4.64.1305301650290.29171@axis700.grange>
 <51A77CF1.7040105@ti.com> <20130531024438.GB32564@verge.net.au>
 <CAGa+x8413povhYWx+BSj=TdzQDAuYFXmjF4A2kXvQt+=n+380w@mail.gmail.com>
 <Pine.LNX.4.64.1306192125480.12502@axis700.grange>
 <20130705045350.GA10947@intel.com>
Message-ID: <Pine.LNX.4.64.1307081004190.19819@axis700.grange>

On Fri, 5 Jul 2013, Vinod Koul wrote:

> On Wed, Jun 19, 2013 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
> > Hi Vinod
> > 
> > On Wed, 19 Jun 2013, Kevin Hilman wrote:
> > 
> > > On Thu, May 30, 2013 at 7:44 PM, Simon Horman <horms at verge.net.au> wrote:
> > > 
> > > [...]
> > > 
> > > > thanks for this. I will wait for a refresh (as we discussed earlier today).
> > > > Can I confirm that this is a fix for v3.10? If so, could ou note
> > > > that when you post your revised patch?
> > > 
> > > Any progress on this patch?
> > > 
> > > The SH-mobile defconfigs are still all failing in linux-next.
> > 
> > In
> > 
> > https://patchwork.kernel.org/patch/2640061/
> And you havent CC maintainers on this patch, so I dont have it!

Ouch, sorry, no idea how I managed not to CC you, my apologies!

> > I proposed a simple immediate fix for this problem. Arnd at the same time 
> > developed an alternative solution:
> > 
> > https://patchwork.kernel.org/patch/2644121/
> > https://patchwork.kernel.org/patch/2644111/
> Reading these patches I agree with Arnd that client drivers should not depend on
> dma slave drivers. Existing issue need to be fixed

I'm not arguing against that. My point is the following: also Arnd's 
patches have to deal with the fact, that the filter function has to be in 
files, which will be compiled with SHDMA enabled or disabled in .config. 
He solves this problem by adding #ifdef's to each .c file. Whereas I think 
it's better to add just one such #ifdef to the header. The actual issue of 
DMA client driver dependency on a specific dmaengine controller driver is 
a different (though related) problem and should be addressed separately.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From srinivas.kandagatla at st.com  Mon Jul  8 04:17:54 2013
From: srinivas.kandagatla at st.com (Srinivas KANDAGATLA)
Date: Mon,  8 Jul 2013 09:17:54 +0100
Subject: [PATCH v1 1/4] ARM: dts: STi: Fix pinconf setup for STiH416 serial2
In-Reply-To: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
References: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
Message-ID: <1373271474-11587-1-git-send-email-srinivas.kandagatla@st.com>

From: Srinivas Kandagatla <srinivas.kandagatla at st.com>

This patch fixes a bug in pinctrl setup of serial2 device, Some of the
pins in the pinctrl node of serial2 do not belong to that
pin-controller. This patch divides them in the pins into there
respective pin controller nodes.

Without this patch serial on StiH416-B2000 Board will not work as it
fails with:

"st-pinctrl pin-controller-rear.3: failed to get pin(99) name
st-pinctrl pin-controller-rear.3: maps: function serial2 group serial2-0
num 4
pinconfig core: failed to register map default (3): no group/pin given"

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at st.com>
---
 arch/arm/boot/dts/stih416-pinctrl.dtsi |   10 +++++++++-
 arch/arm/boot/dts/stih416.dtsi         |    2 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/stih416-pinctrl.dtsi b/arch/arm/boot/dts/stih416-pinctrl.dtsi
index 957b21a..0f246c9 100644
--- a/arch/arm/boot/dts/stih416-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih416-pinctrl.dtsi
@@ -166,6 +166,15 @@
 				reg		= <0x9000 0x100>;
 				st,bank-name	= "PIO31";
 			};
+
+			serial2-oe {
+				pinctrl_serial2_oe: serial2-1 {
+					st,pins {
+						output-enable	= <&PIO11 3 ALT2 OUT>;
+					};
+				};
+			};
+
 		};
 
 		pin-controller-rear {
@@ -218,7 +227,6 @@
 					st,pins {
 						tx	= <&PIO17 4 ALT2 OUT>;
 						rx	= <&PIO17 5 ALT2 IN>;
-						output-enable	= <&PIO11 3 ALT2 OUT>;
 					};
 				};
 			};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 3cecd96..1a0326e 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -79,7 +79,7 @@
 			interrupts	= <0 197 0>;
 			clocks          = <&CLK_S_ICN_REG_0>;
 			pinctrl-names 	= "default";
-			pinctrl-0 	= <&pinctrl_serial2>;
+			pinctrl-0 	= <&pinctrl_serial2 &pinctrl_serial2_oe>;
 		};
 
 		/* SBC_UART1 */
-- 
1.7.6.5



From srinivas.kandagatla at st.com  Mon Jul  8 04:18:06 2013
From: srinivas.kandagatla at st.com (Srinivas KANDAGATLA)
Date: Mon,  8 Jul 2013 09:18:06 +0100
Subject: [PATCH v1 2/4] ARM: STi: Set correct ARM ERRATAs.
In-Reply-To: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
References: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
Message-ID: <1373271486-11631-1-git-send-email-srinivas.kandagatla@st.com>

From: Srinivas Kandagatla <srinivas.kandagatla at st.com>

Some of the ARM_ERRATA selection is not done in the initial SOC support
patches. This patch selects 2 new ARM_ERRATA's and removes one which was
actually fixed.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at st.com>
---
 arch/arm/mach-sti/Kconfig |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
index d04e3bf..c216094 100644
--- a/arch/arm/mach-sti/Kconfig
+++ b/arch/arm/mach-sti/Kconfig
@@ -11,8 +11,9 @@ menuconfig ARCH_STI
 	select HAVE_SMP
 	select HAVE_ARM_SCU if SMP
 	select ARCH_REQUIRE_GPIOLIB
-	select ARM_ERRATA_720789
 	select ARM_ERRATA_754322
+	select ARM_ERRATA_775420
+	select ARM_ERRATA_764369
 	select PL310_ERRATA_753970 if CACHE_PL310
 	select PL310_ERRATA_769419 if CACHE_PL310
 	help
-- 
1.7.6.5



From srinivas.kandagatla at st.com  Mon Jul  8 04:15:01 2013
From: srinivas.kandagatla at st.com (Srinivas KANDAGATLA)
Date: Mon,  8 Jul 2013 09:15:01 +0100
Subject: [PATCH v1 0/4] ARM: STi fixes and ethernet support
Message-ID: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>

From: Srinivas Kandagatla <srinivas.kandagatla at st.com>

This patch series fixes 2 configuration issues and adds ethernet support to
STiH415, STiH416 based B2000, B2020 boards.
With this patchset B2000 and B2020 can have basic ethernet support in
MII and RGMII modes.

Thanks,
srini

Srinivas Kandagatla (4):
  ARM: dts: STi: Fix pinconf setup for STiH416 serial2
  ARM: STi: Set correct ARM ERRATAs.
  ARM: STi: Add STiH415 ethernet support.
  ARM: STi: Add STiH416 ethernet support.

 arch/arm/boot/dts/stih415-pinctrl.dtsi |   82 ++++++++++++++++
 arch/arm/boot/dts/stih415.dtsi         |   34 +++++++
 arch/arm/boot/dts/stih416-pinctrl.dtsi |   92 +++++++++++++++++-
 arch/arm/boot/dts/stih416.dtsi         |   38 +++++++-
 arch/arm/boot/dts/stih41x-b2000.dtsi   |   21 ++++
 arch/arm/boot/dts/stih41x-b2020.dtsi   |   14 +++
 arch/arm/mach-sti/Kconfig              |    3 +-
 arch/arm/mach-sti/Makefile             |    2 +-
 arch/arm/mach-sti/board-dt.c           |    2 +
 arch/arm/mach-sti/stih41x.c            |  166 ++++++++++++++++++++++++++++++++
 arch/arm/mach-sti/stih41x.h            |    4 +
 11 files changed, 454 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/mach-sti/stih41x.c
 create mode 100644 arch/arm/mach-sti/stih41x.h

-- 
1.7.6.5



From srinivas.kandagatla at st.com  Mon Jul  8 04:18:13 2013
From: srinivas.kandagatla at st.com (Srinivas KANDAGATLA)
Date: Mon,  8 Jul 2013 09:18:13 +0100
Subject: [PATCH v1 3/4] ARM: STi: Add STiH415 ethernet support.
In-Reply-To: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
References: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
Message-ID: <1373271493-11672-1-git-send-email-srinivas.kandagatla@st.com>

From: Srinivas Kandagatla <srinivas.kandagatla at st.com>

This patch adds support to STiH415 SOC, which has two ethernet
snps,dwmac controllers version 3.610. With this patch B2000 and B2020
boards can boot with ethernet in MII and RGMII modes.

Tested on both B2020 and B2000.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at st.com>
---
 arch/arm/boot/dts/stih415-pinctrl.dtsi |   82 ++++++++++++++++
 arch/arm/boot/dts/stih415.dtsi         |   34 +++++++
 arch/arm/boot/dts/stih41x-b2000.dtsi   |   21 ++++
 arch/arm/boot/dts/stih41x-b2020.dtsi   |   14 +++
 arch/arm/mach-sti/Makefile             |    2 +-
 arch/arm/mach-sti/board-dt.c           |    2 +
 arch/arm/mach-sti/stih41x.c            |  166 ++++++++++++++++++++++++++++++++
 arch/arm/mach-sti/stih41x.h            |    4 +
 8 files changed, 324 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-sti/stih41x.c
 create mode 100644 arch/arm/mach-sti/stih41x.h

diff --git a/arch/arm/boot/dts/stih415-pinctrl.dtsi b/arch/arm/boot/dts/stih415-pinctrl.dtsi
index 1d322b2..c087af8 100644
--- a/arch/arm/boot/dts/stih415-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih415-pinctrl.dtsi
@@ -86,6 +86,57 @@
 					};
 				};
 			};
+
+			gmac1 {
+				pinctrl_mii1: mii1 {
+						st,pins {
+						 txd0   = <&PIO0 0 ALT1 OUT  SE_NICLK_IO	0	CLK_A>;
+						 txd1   = <&PIO0 1 ALT1 OUT  SE_NICLK_IO	0	CLK_A>;
+						 txd2   = <&PIO0 2 ALT1 OUT  SE_NICLK_IO	0	CLK_A>;
+						 txd3   = <&PIO0 3 ALT1 OUT  SE_NICLK_IO	0	CLK_A>;
+						 txer   = <&PIO0 4 ALT1 OUT  SE_NICLK_IO	0	CLK_A>;
+						 txen   = <&PIO0 5 ALT1 OUT  SE_NICLK_IO	0	CLK_A>;
+						 txclk  = <&PIO0 6 ALT1 IN   NICLK	0	CLK_A>;
+						 col    = <&PIO0 7 ALT1 IN   BYPASS	1000>;
+						 mdio   = <&PIO1 0 ALT1 OUT  BYPASS	0>;
+						 mdc    = <&PIO1 1 ALT1 OUT  NICLK	0	CLK_A>;
+						 crs    = <&PIO1 2 ALT1 IN   BYPASS	1000>;
+						 mdint  = <&PIO1 3 ALT1 IN   BYPASS	0>;
+						 rxd0   = <&PIO1 4 ALT1 IN   SE_NICLK_IO	0	CLK_A>;
+						 rxd1   = <&PIO1 5 ALT1 IN   SE_NICLK_IO	0	CLK_A>;
+						 rxd2   = <&PIO1 6 ALT1 IN   SE_NICLK_IO	0	CLK_A>;
+						 rxd3   = <&PIO1 7 ALT1 IN   SE_NICLK_IO	0	CLK_A>;
+						 rxdv   = <&PIO2 0 ALT1 IN   SE_NICLK_IO	0	CLK_A>;
+						 rx_er  = <&PIO2 1 ALT1 IN   SE_NICLK_IO	0	CLK_A>;
+						 rxclk  = <&PIO2 2 ALT1 IN   NICLK	0	CLK_A>;
+						 phyclk = <&PIO2 3 ALT1 IN   NICLK	1000	CLK_A>;
+					};
+				};
+
+				pinctrl_rgmii1: rgmii1-0 {
+					st,pins {
+						 txd0 =	 <&PIO0 0 ALT1 OUT DE_IO	1000	CLK_A>;
+						 txd1 =	 <&PIO0 1 ALT1 OUT DE_IO	1000	CLK_A>;
+						 txd2 =	 <&PIO0 2 ALT1 OUT DE_IO	1000	CLK_A>;
+						 txd3 =	 <&PIO0 3 ALT1 OUT DE_IO	1000	CLK_A>;
+						 txen =	 <&PIO0 5 ALT1 OUT DE_IO	0	CLK_A>;
+						 txclk = <&PIO0 6 ALT1 IN	NICLK	0	CLK_A>;
+						 mdio =	 <&PIO1 0 ALT1 OUT	BYPASS	0>;
+						 mdc =	 <&PIO1 1 ALT1 OUT	NICLK	0	CLK_A>;
+						 rxd0 =	 <&PIO1 4 ALT1 IN DE_IO	0	CLK_A>;
+						 rxd1 =	 <&PIO1 5 ALT1 IN DE_IO	0	CLK_A>;
+						 rxd2 =	 <&PIO1 6 ALT1 IN DE_IO	0	CLK_A>;
+						 rxd3 =	 <&PIO1 7 ALT1 IN DE_IO	0	CLK_A>;
+
+						 rxdv =	  <&PIO2 0 ALT1 IN DE_IO	500	CLK_A>;
+						 rxclk =  <&PIO2 2 ALT1 IN	NICLK	0	CLK_A>;
+						 phyclk = <&PIO2 3 ALT4 OUT	NICLK	0	CLK_B>;
+
+						 clk125= <&PIO3 7 ALT4 IN 	NICLK	0	CLK_A>;
+					};
+				};
+			};
+
 		};
 
 		pin-controller-front {
@@ -197,6 +248,37 @@
 					};
 				};
 			};
+
+			gmac0{
+				pinctrl_mii0: mii0 {
+					st,pins {
+					 mdint =	<&PIO13 6 ALT2	IN	BYPASS		0>;
+					 txen =		<&PIO13 7 ALT2	OUT	SE_NICLK_IO	0	CLK_A>;
+
+					 txd0 =		<&PIO14 0 ALT2	OUT	SE_NICLK_IO	0	CLK_A>;
+					 txd1 =		<&PIO14 1 ALT2	OUT	SE_NICLK_IO	0	CLK_A>;
+					 txd2 =		<&PIO14 2 ALT2	OUT	SE_NICLK_IO	0	CLK_B>;
+					 txd3 =		<&PIO14 3 ALT2	OUT	SE_NICLK_IO	0	CLK_B>;
+
+					 txclk =	<&PIO15 0 ALT2	IN	NICLK		0	CLK_A>;
+					 txer =		<&PIO15 1 ALT2	OUT	SE_NICLK_IO	0	CLK_A>;
+					 crs =		<&PIO15 2 ALT2	IN	BYPASS		1000>;
+					 col =		<&PIO15 3 ALT2	IN	BYPASS		1000>;
+					 mdio  =        <&PIO15 4 ALT2	OUT	BYPASS 	3000>;
+					 mdc   =        <&PIO15 5 ALT2	OUT     NICLK  	0    	CLK_B>;
+
+					 rxd0 =		<&PIO16 0 ALT2	IN	SE_NICLK_IO	0	CLK_A>;
+					 rxd1 =		<&PIO16 1 ALT2	IN	SE_NICLK_IO	0	CLK_A>;
+					 rxd2 =		<&PIO16 2 ALT2	IN	SE_NICLK_IO	0	CLK_A>;
+					 rxd3 =		<&PIO16 3 ALT2	IN	SE_NICLK_IO	0	CLK_A>;
+					 rxdv =		<&PIO15 6 ALT2	IN	SE_NICLK_IO	0	CLK_A>;
+					 rx_er =	<&PIO15 7 ALT2	IN	SE_NICLK_IO	0	CLK_A>;
+					 rxclk =	<&PIO17 0 ALT2	IN	NICLK		0	CLK_A>;
+					 phyclk =	<&PIO13 5 ALT2	OUT	NICLK	1000	CLK_A>;
+
+					};
+				};
+			};
 		};
 
 		pin-controller-left {
diff --git a/arch/arm/boot/dts/stih415.dtsi b/arch/arm/boot/dts/stih415.dtsi
index 74ab8de..a77939d 100644
--- a/arch/arm/boot/dts/stih415.dtsi
+++ b/arch/arm/boot/dts/stih415.dtsi
@@ -83,5 +83,39 @@
 			pinctrl-names 	= "default";
 			pinctrl-0	= <&pinctrl_sbc_serial1>;
 		};
+
+		ethernet0: ethernet at fe810000{
+			device_type 	= "network";
+			compatible	= "snps,dwmac", "snps,dwmac-3.610";
+			status 		= "disabled";
+			reg 		= <0xfe810000 0x8000>;
+			interrupts 	= <0 147 0>;
+			interrupt-names = "macirq";
+
+			snps,pbl 	= <32>;
+			snps,mixed-burst;
+
+			pinctrl-names 	= "default";
+			pinctrl-0	= <&pinctrl_mii0>;
+			clock-names	= "stmmaceth";
+			clocks		= <&CLKS_ICN_REG_0>;
+		};
+
+		ethernet1: ethernet at fef08000 {
+			device_type = "network";
+			compatible	= "snps,dwmac", "snps,dwmac-3.610";
+			status 		= "disabled";
+			reg		= <0xfef08000 0x8000>;
+			interrupts	= <0 150 0>;
+			interrupt-names = "macirq";
+
+			snps,pbl	= <32>;
+			snps,mixed-burst;
+
+			pinctrl-names 	= "default";
+			pinctrl-0	= <&pinctrl_mii1>;
+			clock-names	= "stmmaceth";
+			clocks		= <&CLKS_ICN_REG_0>;
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/stih41x-b2000.dtsi b/arch/arm/boot/dts/stih41x-b2000.dtsi
index 8e694d2..55e68d3 100644
--- a/arch/arm/boot/dts/stih41x-b2000.dtsi
+++ b/arch/arm/boot/dts/stih41x-b2000.dtsi
@@ -20,6 +20,8 @@
 
 	aliases {
 		ttyAS0 = &serial2;
+		ethernet0 = &ethernet0;
+		ethernet1 = &ethernet1;
 	};
 
 	soc {
@@ -37,5 +39,24 @@
 			};
 		};
 
+		ethernet0: ethernet at fe810000 {
+			status			= "okay";
+			phy-mode		= "mii";
+			snps,phy-addr 		= <0x1>;
+
+			snps,reset-gpio 	= <&PIO106 2>;
+			snps,reset-active-low;
+			snps,reset-delays-us 	= <0 10000 10000>;
+		};
+		ethernet1: ethernet at fef08000 {
+			status			= "okay";
+			phy-mode		= "mii";
+			snps,phy-addr 		= <0x1>;
+
+			snps,reset-gpio 	= <&PIO4 7>;
+			snps,reset-active-low;
+			snps,reset-delays-us 	= <0 10000 10000>;
+		};
+
 	};
 };
diff --git a/arch/arm/boot/dts/stih41x-b2020.dtsi b/arch/arm/boot/dts/stih41x-b2020.dtsi
index 133e181..bc5818d 100644
--- a/arch/arm/boot/dts/stih41x-b2020.dtsi
+++ b/arch/arm/boot/dts/stih41x-b2020.dtsi
@@ -19,6 +19,7 @@
 
 	aliases {
 		ttyAS0 = &sbc_serial1;
+		ethernet1 = &ethernet1;
 	};
 	soc {
 		sbc_serial1: serial at fe531000 {
@@ -38,5 +39,18 @@
 				default-state = "off";
 			};
 		};
+
+		ethernet1: ethernet at fef08000 {
+			status			= "okay";
+			phy-mode		= "rgmii-id";
+			snps,phy-addr 		= <0x1>;
+
+			snps,reset-gpio 	= <&PIO3 0>;
+			snps,reset-active-low;
+			snps,reset-delays-us 	= <0 10000 10000>;
+
+			pinctrl-0	= <&pinctrl_rgmii1>;
+		};
+
 	};
 };
diff --git a/arch/arm/mach-sti/Makefile b/arch/arm/mach-sti/Makefile
index acb3309..daffc49 100644
--- a/arch/arm/mach-sti/Makefile
+++ b/arch/arm/mach-sti/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_SMP)		+= platsmp.o headsmp.o
-obj-$(CONFIG_ARCH_STI) 		+= board-dt.o
+obj-$(CONFIG_ARCH_STI) 		+= board-dt.o stih41x.o
diff --git a/arch/arm/mach-sti/board-dt.c b/arch/arm/mach-sti/board-dt.c
index 8fe6f0c..80080e3 100644
--- a/arch/arm/mach-sti/board-dt.c
+++ b/arch/arm/mach-sti/board-dt.c
@@ -14,6 +14,7 @@
 #include <asm/mach/arch.h>
 
 #include "smp.h"
+#include "stih41x.h"
 
 void __init stih41x_l2x0_init(void)
 {
@@ -43,6 +44,7 @@ static const char *stih41x_dt_match[] __initdata = {
 
 DT_MACHINE_START(STM, "STiH415/416 SoC with Flattened Device Tree")
 	.init_time	= stih41x_timer_init,
+	.init_machine	= stih41x_init_machine,
 	.smp		= smp_ops(sti_smp_ops),
 	.dt_compat	= stih41x_dt_match,
 MACHINE_END
diff --git a/arch/arm/mach-sti/stih41x.c b/arch/arm/mach-sti/stih41x.c
new file mode 100644
index 0000000..c32ac40
--- /dev/null
+++ b/arch/arm/mach-sti/stih41x.c
@@ -0,0 +1,166 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics Limited
+ * Author: Srinivas Kandagatla <srinivas.kandagatla at st.com>
+ *
+ * May be copied or modified under the terms of the GNU General Public
+ * License.  See linux/COPYING for more information.
+ */
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/syscon.h>
+#include <linux/stmmac.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+#include <linux/regmap.h>
+#include <linux/phy.h>
+
+#define STIH415_SYSCFG_SBC(num)			(num*4)
+#define STIH415_SYSCFG_REAR(num)		((num - 300)*4)
+#define STIH415_SYSCFG_FRONT(num)		((num - 100)*4)
+
+#define STIH415_SYSCFG_ETH0_CONFIG_REG		STIH415_SYSCFG_REAR(382)
+#define STIH415_SYSCFG_EN_GMAC0_REG		STIH415_SYSCFG_FRONT(166)
+#define STIH415_SYSCFG_ETH1_CONFIG_REG		STIH415_SYSCFG_SBC(29)
+#define STIH415_SYSCFG_EN_GMAC1_REG		STIH415_SYSCFG_SBC(31)
+
+/* STiH416 */
+#define STIH416_SYSCFG_SBC(num)			(num*4)
+#define STIH416_SYSCFG_REAR(num)		((num - 2000)*4)
+#define STIH416_SYSCFG_FRONT(num)		((num - 1000)*4)
+
+#define STIH416_SYSCFG_EN_GMAC0_REG		STIH416_SYSCFG_FRONT(1539)
+#define STIH416_SYSCFG_ETH0_CONFIG_REG		STIH416_SYSCFG_REAR(2559)
+#define STIH416_SYSCFG_EN_GMAC1_REG		STIH416_SYSCFG_SBC(510)
+#define STIH416_SYSCFG_ETH1_CONFIG_REG		STIH416_SYSCFG_SBC(508)
+
+#define MAX_ETHS		2
+
+struct eth_syscfg {
+	const char *en_syscfg;
+	const char *cfg_syscfg;
+	u32 en_reg;
+	u32 cfg_reg;
+};
+
+struct eth_syscfg stih415_eth_config[MAX_ETHS] = {
+	[0] = {
+		.en_syscfg	= "st,stih415-front-syscfg",
+		.en_reg		= STIH415_SYSCFG_EN_GMAC0_REG,
+		.cfg_syscfg	= "st,stih415-rear-syscfg",
+		.cfg_reg	= STIH415_SYSCFG_ETH0_CONFIG_REG,
+	},
+	[1] = {
+		.en_syscfg	= "st,stih415-sbc-syscfg",
+		.en_reg		= STIH415_SYSCFG_EN_GMAC1_REG,
+		.cfg_syscfg	= "st,stih415-sbc-syscfg",
+		.cfg_reg	= STIH415_SYSCFG_ETH1_CONFIG_REG,
+	}
+};
+
+struct eth_syscfg stih416_eth_config[MAX_ETHS] = {
+	[0] = {
+		.en_syscfg	= "st,stih416-front-syscfg",
+		.en_reg		= STIH416_SYSCFG_EN_GMAC0_REG,
+		.cfg_syscfg	= "st,stih416-rear-syscfg",
+		.cfg_reg	= STIH416_SYSCFG_ETH0_CONFIG_REG,
+	},
+	[1] = {
+		.en_syscfg	= "st,stih416-sbc-syscfg",
+		.en_reg		= STIH416_SYSCFG_EN_GMAC1_REG,
+		.cfg_syscfg	= "st,stih416-sbc-syscfg",
+		.cfg_reg	= STIH416_SYSCFG_ETH1_CONFIG_REG,
+	}
+};
+
+static struct eth_syscfg *stih41x_eth_syscfg;
+
+static u32 eth_configs[] = {
+	[PHY_INTERFACE_MODE_MII]	= 0x060,
+	[PHY_INTERFACE_MODE_GMII]	= 0x020,
+	[PHY_INTERFACE_MODE_RMII]	= 0x1b0,
+	[PHY_INTERFACE_MODE_RGMII]	= 0x024,
+	[PHY_INTERFACE_MODE_RGMII_ID]	= 0x024,
+};
+
+static int stih41x_setup_ethernet(struct plat_stmmacenet_data *plat_data,
+				int ext_phyclk)
+{
+	int phy_mode  = plat_data->interface;
+	int bus_id = plat_data->bus_id;
+	struct regmap *regmap_en, *regmap_cfg;
+	u32 eth_config;
+	struct eth_syscfg *syscfg;
+
+	if (bus_id < 0 || bus_id > MAX_ETHS)
+		return -EINVAL;
+
+	syscfg = &stih41x_eth_syscfg[bus_id];
+
+	if (!syscfg)
+		return -EINVAL;
+
+	regmap_en = syscon_regmap_lookup_by_compatible(syscfg->en_syscfg);
+	regmap_cfg = syscon_regmap_lookup_by_compatible(syscfg->cfg_syscfg);
+
+	if (IS_ERR(regmap_en) || IS_ERR(regmap_cfg))
+		return -EINVAL;
+
+	eth_config = eth_configs[phy_mode];
+	if (!ext_phyclk) /* internal clock */
+		eth_config |= 0x180;
+
+	regmap_write(regmap_en, syscfg->en_reg, 1);
+	regmap_write(regmap_cfg, syscfg->cfg_reg, eth_config);
+	return 0;
+}
+
+static int stih41x_init_ethernet(struct platform_device *pdev)
+{
+	struct plat_stmmacenet_data *plat_data = pdev->dev.platform_data;
+
+	if (stih41x_setup_ethernet(plat_data, 1))
+		return -EINVAL;
+
+	/* Will be used in speed selection */
+	plat_data->bsp_priv = pdev;
+
+	return 0;
+}
+
+static void stih41x_fix_mac_speed(void *priv, unsigned int spd)
+{
+	struct platform_device *pdev = priv;
+	struct plat_stmmacenet_data *plat_data = pdev->dev.platform_data;
+
+	/* On B2020 use internal clock at 25MHz for 100 link in RGMII mode */
+	if (plat_data->interface != PHY_INTERFACE_MODE_MII)
+		stih41x_setup_ethernet(plat_data, (spd == SPEED_1000) ? 1 : 0);
+}
+
+static struct plat_stmmacenet_data stih41x_eth0_pdata = {
+	.init = &stih41x_init_ethernet,
+	.fix_mac_speed = &stih41x_fix_mac_speed,
+};
+
+static struct plat_stmmacenet_data stih41x_eth1_pdata = {
+	.init = &stih41x_init_ethernet,
+	.fix_mac_speed = &stih41x_fix_mac_speed,
+};
+
+struct of_dev_auxdata stih41x_auxdata_lookup[] __initdata = {
+	OF_DEV_AUXDATA("snps,dwmac", 0xfe810000, NULL, &stih41x_eth0_pdata),
+	OF_DEV_AUXDATA("snps,dwmac", 0xfef08000, NULL, &stih41x_eth1_pdata),
+	{}
+};
+
+void __init stih41x_init_machine(void)
+{
+	if (of_machine_is_compatible("st,stih415"))
+		stih41x_eth_syscfg = stih415_eth_config;
+	else if (of_machine_is_compatible("st,stih416"))
+		stih41x_eth_syscfg = stih416_eth_config;
+
+	of_platform_populate(NULL, of_default_bus_match_table,
+			stih41x_auxdata_lookup, NULL);
+}
diff --git a/arch/arm/mach-sti/stih41x.h b/arch/arm/mach-sti/stih41x.h
new file mode 100644
index 0000000..cf2df32
--- /dev/null
+++ b/arch/arm/mach-sti/stih41x.h
@@ -0,0 +1,4 @@
+#ifndef __MACH_STIH41X_H
+#define __MACH_STIH41X_H
+extern void stih41x_init_machine(void);
+#endif /* __MACH_STIH41X_H */
-- 
1.7.6.5



From srinivas.kandagatla at st.com  Mon Jul  8 04:18:20 2013
From: srinivas.kandagatla at st.com (Srinivas KANDAGATLA)
Date: Mon,  8 Jul 2013 09:18:20 +0100
Subject: [PATCH v1 4/4] ARM: STi: Add STiH416 ethernet support.
In-Reply-To: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
References: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
Message-ID: <1373271500-11715-1-git-send-email-srinivas.kandagatla@st.com>

From: Srinivas Kandagatla <srinivas.kandagatla at st.com>

This patch adds support to STiH416 SOC, which has two ethernet
snps,dwmac controllers version 3.710. With this patch B2000 and B2020
boards can boot with ethernet in MII and RGMII modes.

Tested on both B2020 and B2000.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at st.com>
---
 arch/arm/boot/dts/stih416-pinctrl.dtsi |   82 ++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/stih416.dtsi         |   36 ++++++++++++++
 2 files changed, 118 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/stih416-pinctrl.dtsi b/arch/arm/boot/dts/stih416-pinctrl.dtsi
index 0f246c9..c7bbde7 100644
--- a/arch/arm/boot/dts/stih416-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih416-pinctrl.dtsi
@@ -97,6 +97,59 @@
 					};
 				};
 			};
+
+			gmac1 {
+				pinctrl_mii1: mii1 {
+					st,pins {
+						txd0 = <&PIO0 0 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+						txd1 = <&PIO0 1 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+						txd2 = <&PIO0 2 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+						txd3 = <&PIO0 3 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+						txer = <&PIO0 4 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+						txen = <&PIO0 5 ALT1 OUT SE_NICLK_IO 0 CLK_A>;
+						txclk = <&PIO0 6 ALT1 IN NICLK 0 CLK_A>;
+						col =   <&PIO0 7 ALT1 IN BYPASS 1000>;
+
+						mdio =  <&PIO1 0 ALT1 OUT BYPASS 1500>;
+						mdc =   <&PIO1 1 ALT1 OUT NICLK 0 CLK_A>;
+						crs =   <&PIO1 2 ALT1 IN BYPASS 1000>;
+						mdint = <&PIO1 3 ALT1 IN BYPASS 0>;
+						rxd0 =  <&PIO1 4 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+						rxd1 =  <&PIO1 5 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+						rxd2 =  <&PIO1 6 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+						rxd3 =  <&PIO1 7 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+
+						rxdv =  <&PIO2 0 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+						rx_er = <&PIO2 1 ALT1 IN SE_NICLK_IO 0 CLK_A>;
+						rxclk = <&PIO2 2 ALT1 IN NICLK 0 CLK_A>;
+					 	phyclk = <&PIO2 3 ALT1 OUT NICLK 0 CLK_A>;
+					};
+				};
+				pinctrl_rgmii1: rgmii1-0 {
+					st,pins {
+						txd0 =  <&PIO0 0 ALT1 OUT DE_IO 500 CLK_A>;
+						txd1 =  <&PIO0 1 ALT1 OUT DE_IO 500 CLK_A>;
+						txd2 =  <&PIO0 2 ALT1 OUT DE_IO 500 CLK_A>;
+						txd3 =  <&PIO0 3 ALT1 OUT DE_IO 500 CLK_A>;
+						txen =  <&PIO0 5 ALT1 OUT DE_IO 0   CLK_A>;
+						txclk = <&PIO0 6 ALT1 IN  NICLK 0   CLK_A>;
+
+						mdio = <&PIO1 0 ALT1 OUT BYPASS 0>;
+						mdc  = <&PIO1 1 ALT1 OUT NICLK  0 CLK_A>;
+						rxd0 = <&PIO1 4 ALT1 IN DE_IO 500 CLK_A>;
+						rxd1 = <&PIO1 5 ALT1 IN DE_IO 500 CLK_A>;
+						rxd2 = <&PIO1 6 ALT1 IN DE_IO 500 CLK_A>;
+						rxd3 = <&PIO1 7 ALT1 IN DE_IO 500 CLK_A>;
+
+						rxdv   = <&PIO2 0 ALT1 IN  DE_IO 500 CLK_A>;
+						rxclk  = <&PIO2 2 ALT1 IN  NICLK 0   CLK_A>;
+						phyclk = <&PIO2 3 ALT4 OUT NICLK 0   CLK_B>;
+
+						clk125= <&PIO3 7 ALT4 IN NICLK 0 CLK_A>;
+					};
+				};
+			};
+
 		};
 
 		pin-controller-front {
@@ -230,6 +283,35 @@
 					};
 				};
 			};
+
+			gmac0 {
+				pinctrl_mii0: mii0 {
+					st,pins {
+						mdint = <&PIO13 6 ALT2 IN  BYPASS      0>;
+						txen =  <&PIO13 7 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+						txd0 =  <&PIO14 0 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+						txd1 =  <&PIO14 1 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+						txd2 =  <&PIO14 2 ALT2 OUT SE_NICLK_IO 0 CLK_B>;
+						txd3 =  <&PIO14 3 ALT2 OUT SE_NICLK_IO 0 CLK_B>;
+
+						txclk = <&PIO15 0 ALT2 IN  NICLK       0 CLK_A>;
+						txer =  <&PIO15 1 ALT2 OUT SE_NICLK_IO 0 CLK_A>;
+						crs = <&PIO15 2 ALT2 IN  BYPASS 1000>;
+						col = <&PIO15 3 ALT2 IN  BYPASS 1000>;
+						mdio= <&PIO15 4 ALT2 OUT BYPASS 1500>;
+						mdc = <&PIO15 5 ALT2 OUT NICLK  0    CLK_B>;
+
+						rxd0 =  <&PIO16 0 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+						rxd1 =  <&PIO16 1 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+						rxd2 =  <&PIO16 2 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+						rxd3 =  <&PIO16 3 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+						rxdv =  <&PIO15 6 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+						rx_er = <&PIO15 7 ALT2 IN SE_NICLK_IO 0 CLK_A>;
+						rxclk = <&PIO17 0 ALT2 IN NICLK 0 CLK_A>;
+					 	phyclk = <&PIO13 5 ALT2 OUT NICLK 0 CLK_B>;
+					};
+				};
+			};
 		};
 
 		pin-controller-fvdp-fe {
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 1a0326e..f43035b 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -92,5 +92,41 @@
 			pinctrl-0 	= <&pinctrl_sbc_serial1>;
 			clocks          = <&CLK_SYSIN>;
 		};
+
+		ethernet0: ethernet at fe810000{
+			device_type 	= "network";
+			compatible	= "snps,dwmac", "snps,dwmac-3.610";
+			status 		= "disabled";
+			reg 		= <0xfe810000 0x8000>;
+
+			interrupts = <0 133 0>, <0 134 0>, <0 135 0>;
+			interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+
+			snps,pbl 	= <32>;
+			snps,mixed-burst;
+
+			pinctrl-names 	= "default";
+			pinctrl-0	= <&pinctrl_mii0>;
+			clock-names	= "stmmaceth";
+			clocks		= <&CLK_S_ICN_REG_0>;
+		};
+
+		ethernet1: ethernet at fef08000 {
+			device_type = "network";
+			compatible	= "snps,dwmac", "snps,dwmac-3.610";
+			status 		= "disabled";
+			reg		= <0xfef08000 0x8000>;
+			interrupts = <0 136 0>, <0 137 0>, <0 138 0>;
+			interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+
+			snps,pbl	= <32>;
+			snps,mixed-burst;
+
+			pinctrl-names 	= "default";
+			pinctrl-0	= <&pinctrl_mii1>;
+			clock-names	= "stmmaceth";
+			clocks		= <&CLK_S_ICN_REG_0>;
+		};
+
 	};
 };
-- 
1.7.6.5



From tglx at linutronix.de  Mon Jul  8 04:45:47 2013
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 8 Jul 2013 10:45:47 +0200 (CEST)
Subject: [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC
 timer
In-Reply-To: <20130707235819.GB11908@titan.lakedaemon.net>
References: <51B8D310.4050404@linaro.org> <51D9548B.9040907@gmail.com>
 <alpine.DEB.2.02.1307071508030.32106@ionos.tec.linutronix.de>
 <20130707144645.GA11908@titan.lakedaemon.net>
 <alpine.DEB.2.02.1307071723220.32106@ionos.tec.linutronix.de>
 <20130707235819.GB11908@titan.lakedaemon.net>
Message-ID: <alpine.DEB.2.02.1307081041290.32106@ionos.tec.linutronix.de>

On Sun, 7 Jul 2013, Jason Cooper wrote:
> On Sun, Jul 07, 2013 at 05:30:31PM +0200, Thomas Gleixner wrote:
> I don't mind delaying half of a series so the drivers/ portion can land
> in mainline, and the rest can land in the next cycle.  But when things
> don't go according to that plan, I'd like a little consideration /
> flexibility about solving the problem.  Especially considering I'm
> *trying* to do the right thing by pushing to appropriate maintainers
> first.
> 
> Of course, this is a moot point since, as you clarified above, this
> dependency doesn't have the hazards typically associated with
> out-of-tree dependencies.

There is a very simple procedure for stuff like this.

Series has parts which go through tree A and B and another larger part
for tree C which depends on the A and B parts.

So ask the maintainers of A and B to apply this to separate branches,
which are based on some commit in Linus tree. These branches can be
pulled into C and C can apply the depending stuff on top.

Now the maintainers of A and B merge these branches into their main
devel branch, can do further fixups and stuff on top. And the whole
thing just works without glitches during the merge window.

We do this all the time.

Thanks,

	tglx




From will.deacon at arm.com  Mon Jul  8 04:49:11 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 8 Jul 2013 09:49:11 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <51DA5089.5080109@gmail.com>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com>
Message-ID: <20130708084911.GA22057@mudshark.cambridge.arm.com>

On Mon, Jul 08, 2013 at 06:39:21AM +0100, jgq516 at gmail.com wrote:
> On 07/01/2013 07:03 PM, Ben Dooks wrote:
> > The latest big-endian changes, now on:
> >
> > 	git://git.baserock.org/delta/linux baserock/311/be/core
> >
> > This has a minor fix from the last version where a rebase missed a change
> > in the smp_scu code.
> >
> Hello Ben,
> 
> Thanks for you patches at first. I can boot BE kernel on vexpress a15 tc2
> board with LPAE disabled.
> 
> However if enable LPAE, kernel seems hang after turn on mmu on since
> printascii can't output any character in __mmap_switched.
> Did you happen to try BE kernel with LPAE enabled before? or am I missed
> something?

Well, I hacked head.S recently to fix booting with LPAE and BE8, but I was
unable to test early console since I was using virtio-console. It could be
that the page table entries mapping the uart aren't quite right, but no
obvious issues jump out from looking at the code.

How much visibility do you have on your platform? Can you take a look at the
page table entries and check they look ok please?

Cheers,

Will


From b32955 at freescale.com  Mon Jul  8 04:54:08 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 8 Jul 2013 16:54:08 +0800
Subject: [PATCH v3 4/6] ARM: dts: imx6q{dl}: fix the wrong RTS/CTS pad name
In-Reply-To: <20954.27392.875173.755391@ipc1.ka-ro>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>	<1373004752-21302-5-git-send-email-b32955@freescale.com>	<20130706050803.GC30164@S2101-09.ap.freescale.net>	<20953.22066.706534.773272@ipc1.ka-ro>	<51DA5CA7.1050305@freescale.com>
 <20954
Message-ID: <51DA7E30.3040009@freescale.com>

? 2013?07?08? 15:32, Lothar Wa?mann ??:
> Hi,
>
> Huang Shijie writes:
>> ? 2013?07?07? 19:51, Lothar Wa?mann ??:
>>> Hi,
>>>
>>> Shawn Guo writes:
>>>> On Fri, Jul 05, 2013 at 02:12:30PM +0800, Huang Shijie wrote:
>>>>> There is something wrong with the RTS/CTS pads:
>>>>>     The RTS pad is assigned with the CTS's value;
>>>>>     while the CTS pad is assigned with the RTS's value.
>>>>>
>>>> So basically, you are saying that select_input should be set up for CTS
>>>> rather than RTS.  It seems that the people who generated the macro got
>>>> the wrong input from developer.
>>>>
>>> programming 'select_input' only makes sense for inputs, not outputs.
>>> Since CTS is an output signal, select_input only makes sense for the
>>> RTS function of the pads.
>> Hi Lothar:
>>
>> In our imx6 Soc, the CTS is used as a input signal, not as a output signal.
>>
>> I checked two boards, one is imx6q ARM2 armidillo board, one is
>> imx6-sabreauto board,
>> both the boards use the CTS as a input signal.
>>
> that's the problem with the DTE/DCE mode. Depending on the DCEDTE bit
> in the UARTx_UFCR we would need different pad configurations for
> RTS/CTS because in DCE mode CTS is an output and in DTE mode it's an

yes. thanks for explanation.


> input.
> Thus the correct pad config value would need the input_sel on the CTS
> pad definition for DTE mode and on the RTS pad definition for DCE
Since the default pad is used for DCE mode, what we need to do is
add two extra pads for the DTE mode.

thanks
Huang Shijie
> mode. Maybe something like:
> #define MX6Q_PAD_EIM_D19__UART1_DCE_CTS_B             0x09c 0x3b0 0x000 0x4 0x0
> #define MX6Q_PAD_EIM_D19__UART1_DCE_RTS_B             0x09c 0x3b0 0x91c 0x4 0x0
> #define MX6Q_PAD_EIM_D19__UART1_DTE_CTS_B             0x09c 0x3b0 0x91c 0x4 0x0
> #define MX6Q_PAD_EIM_D19__UART1_DTE_RTS_B             0x09c 0x3b0 0x000 0x4 0x0
>
>
> Lothar Wa?mann




From b32955 at freescale.com  Mon Jul  8 04:54:36 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 8 Jul 2013 16:54:36 +0800
Subject: [PATCH v3 4/6] ARM: dts: imx6q{dl}: fix the wrong RTS/CTS pad name
In-Reply-To: <20130708075004.GR24642@n2100.arm.linux.org.uk>
References: <1373004752-21302-1-git-send-email-b32955@freescale.com>
 <1373004752-21302-5-git-send-email-b32955@freescale.com>
 <20130706050803.GC30164@S2101-09.ap.freescale.net>
 <20953.22066.706534.773272@ipc1.ka-ro>
 <20130708075004.GR24642@n2100.arm.linux
Message-ID: <51DA7E4C.4050507@freescale.com>

? 2013?07?08? 15:50, Russell King - ARM Linux ??:
> On Sun, Jul 07, 2013 at 01:51:14PM +0200, Lothar Wa?mann wrote:
>> Hi,
>>
>> Shawn Guo writes:
>>> On Fri, Jul 05, 2013 at 02:12:30PM +0800, Huang Shijie wrote:
>>>> There is something wrong with the RTS/CTS pads:
>>>>    The RTS pad is assigned with the CTS's value;
>>>>    while the CTS pad is assigned with the RTS's value.
>>>>
>>> So basically, you are saying that select_input should be set up for CTS
>>> rather than RTS.  It seems that the people who generated the macro got
>>> the wrong input from developer.
>>>
>> programming 'select_input' only makes sense for inputs, not outputs.
>> Since CTS is an output signal, select_input only makes sense for the
>> RTS function of the pads.
> Note: If you are a DTE, then RTS is an output, CTS is an input.  If you
> are a DCE, then RTS is an input and CTS is an output (normally on a
> standard UART, you just swap the wiring for RTS and CTS but really that's
> all that is going on.)  So swapping them in software should be acceptable
> too, provided you're not having to disable any auto flow control facilities.
>
thanks for explanation.


Huang Shijie



From will.deacon at arm.com  Mon Jul  8 04:53:00 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 8 Jul 2013 09:53:00 +0100
Subject: ARM Cortex A9: LL counters
In-Reply-To: <BFCB49997E59134AAAF17FFE77F8FF0667377216@REXMD.intranet.epfl.ch>
References: <BFCB49997E59134AAAF17FFE77F8FF06673738BC@REXMD.intranet.epfl.ch>
 <20130704094516.GC8782@mudshark.cambridge.arm.com>
 <BFCB49997E59134AAAF17FFE77F8FF06673759E9@REXMD.intranet.epfl.ch>
 <20130705101208.GC13063@mudshark.cambridge.arm.com>
 <BFCB49997E59134AAAF17FFE77F8FF0667377216@REXMD.intranet.epfl.ch>
Message-ID: <20130708085259.GB22057@mudshark.cambridge.arm.com>

[adding Mark]

On Sat, Jul 06, 2013 at 09:21:54PM +0100, Javier Picorel wrote:
> That will be perfect. Is there any way to access these memory mapped counters?

Mark was working on a PMU driver for Perf, which would expose these
counters via the perf system call. Unfortunately, the patches have rotted a
bit since then, so they would need refreshing/rebasing before they can be
reviewed.

Will


From broonie at kernel.org  Mon Jul  8 04:34:26 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 8 Jul 2013 09:34:26 +0100
Subject: MTD EEPROM support and driver integration
In-Reply-To: <8997501.Dchyii8uWX@wuerfel>
References: <20130705201118.GM2959@lukather> <5811519.oHVuMujf0I@wuerfel>
 <20130706120112.GA11069@lukather> <8997501.Dchyii8uWX@wuerfel>
Message-ID: <20130708083426.GO27646@sirena.org.uk>

On Sat, Jul 06, 2013 at 09:06:49PM +0200, Arnd Bergmann wrote:
> On Saturday 06 July 2013 14:01:12 Maxime Ripard wrote:

> > > > > a) like interrupts, regs, dmas, clocks, pinctrl, reset, pwm: fixed property names

> > > > >       regmap = <&at25 0xstart 0xlen>;
> > > > >       regmap-names = "mac-address";

> > > > > b) like gpio, regulator: variable property names

> > > > >       mac-storage = <&at25 0xstart 0xlen>;

> > > > > It's unfortunate that we already have examples of both. They are largely
> > > > > equivalent, but the tendency is towards the first.

> > > > I don't have a strong feeling for one against another, so whatever works
> > > > best. Both solutions will be a huge improvement anyway 

> > > > Just out of curiosity, is there any advantages besides having a fixed
> > > > property name to the first solution?

> > > I think it's mostly for consistency: trying to get most subsystems to
> > > do it the same way to make it easier for people to write dts files.

> > > A lesser point is that it simplifies the driver code if you don't
> > > have to pass a name.

On the other hand something with human readable names is much more
legible if humans ever have to read or write the DT bindings.  This
mostly applies when there are many instances of the property (for
example, many devices have lots of power supplies) or when some
instances of the property are optional (for example, many devices can
use GPIOs for many different functions but usually not all of them are
connected and there's no particular order in which they might get
connected).

> > So that leave us with mainly one path to achieve this goal:
> >   - Add a regmap-mtd backend
> >   - Add DT parsing code for regmap
> >   - Move the EEPROM drivers from misc to mtd

> Yes, I think that would be good. For the last step, we definitely need
> buy-in from Wolfgand and Jean, as they are maintaining the current eeprom
> drivers.

I'd really like to see more discussion of this "DT parsing code for
regmap" idea...  I've missed almost all the context here.

> We also have a bunch of OTP drivers spread around the kernel, it probably
> makes sense to consolidate them at the same time, at least on the DT binding
> side if not the device drivers.

I'm not sure how viable this is, the OTP interfaces aren't that
consistent and are frequently embedded in random PMICs or whatever.
-------------- 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/20130708/b9a08d28/attachment.sig>

From broonie at kernel.org  Mon Jul  8 04:36:14 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 8 Jul 2013 09:36:14 +0100
Subject: MTD EEPROM support and driver integration
In-Reply-To: <20130707071501.GD11243@lukather>
References: <20130705201118.GM2959@lukather> <5811519.oHVuMujf0I@wuerfel>
 <20130706120112.GA11069@lukather> <8997501.Dchyii8uWX@wuerfel>
 <20130707071501.GD11243@lukather>
Message-ID: <20130708083614.GP27646@sirena.org.uk>

On Sun, Jul 07, 2013 at 09:15:01AM +0200, Maxime Ripard wrote:
> On Sat, Jul 06, 2013 at 09:06:49PM +0200, Arnd Bergmann wrote:

> > We also have a bunch of OTP drivers spread around the kernel, it probably
> > makes sense to consolidate them at the same time, at least on the DT binding
> > side if not the device drivers.

> From a quick grep, the only one I've seen so far are:
>   - imx6q, that has a hook at machine start to poke into its OCOTP to
>     retrieve some frequency scaling parameters it seems. I'm not sure
>     how the current solution could improve the situation for this
>     use-case, but the DT bindings of the OCOTP is just a DT node, with
>     no clients, so we have nothing to worry about here.
>   - imx28, that has a hook at machine start to look up the MAC address
>     values and patch the ethernet controller nodes to add the right
>     local-mac-address property. This one could benefit from the new
>     bindings, but we already mentionned it, and I intended to develop
>     with an imx28 board anyway.
>   - picoxcell-pc3x3 DTSI has a node for a OTP device, but they don't
>     seem to be doing anything with it, nor do they seem to have a driver
>     for it. So I guess we don't care about migrating for this one
>     either.

> Did you have other cases in mind?

We have some OTP support in the ab8500 and wm831x MFD drivers too but
they just expose the data.
-------------- 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/20130708/fa862ec8/attachment-0001.sig>

From broonie at kernel.org  Mon Jul  8 04:06:22 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 8 Jul 2013 09:06:22 +0100
Subject: [PATCH v9 08/10] ASoC: Add phycore-ac97-dt driver
In-Reply-To: <20130707071949.GH16871@s25.your-server.de>
References: <1371734429-6081-1-git-send-email-mpa@pengutronix.de>
 <1371734429-6081-9-git-send-email-mpa@pengutronix.de>
 <20130703161727.GS27646@sirena.org.uk>
 <20130707071949.GH16871@s25.your-server.de>
Message-ID: <20130708080622.GN27646@sirena.org.uk>

On Sun, Jul 07, 2013 at 09:19:49AM +0200, Markus Pargmann wrote:
> On Wed, Jul 03, 2013 at 05:17:27PM +0100, Mark Brown wrote:

> > > +extern void pca100_ac97_cold_reset(struct snd_ac97 *ac97);
> > > +extern void pca100_ac97_warm_reset(struct snd_ac97 *ac97);
> > > +#else
> > > +static void pca100_ac97_cold_reset(struct snd_ac97 *ac97) { }
> > > +static void pca100_ac97_warm_reset(struct snd_ac97 *ac97) { }

> > These functions have no reason to be anywhere except in the driver and
> > really you should just be specifying which pins to use there - ideally
> > via pinctrl but I don't think i.MX has adopted that yet.

> There are no pinctrl driver for imx27(pca100) or imx35(pcm043). The
> iomux/pad configure functions are defined inside mach-imx/ including
> their headers. Both reset functions have to configure iomux/pad before
> and after using gpio. So I think it's not possible to make the reset
> based on the gpio pins without the necessary iomux/pad configuration.

That all sounds fixable - either make pinctrl available or make the
headers usefully visible.  You can see the arch headers in the build
of the entire kernel...
-------------- 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/20130708/f61f4aec/attachment.sig>

From broonie at kernel.org  Mon Jul  8 04:04:37 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 8 Jul 2013 09:04:37 +0100
Subject: [PATCH v9 04/10] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <20130706171323.GG16871@s25.your-server.de>
References: <1371734429-6081-1-git-send-email-mpa@pengutronix.de>
 <1371734429-6081-5-git-send-email-mpa@pengutronix.de>
 <20130703160637.GQ27646@sirena.org.uk>
 <20130706171323.GG16871@s25.your-server.de>
Message-ID: <20130708080437.GM27646@sirena.org.uk>

On Sat, Jul 06, 2013 at 07:13:23PM +0200, Markus Pargmann wrote:
> On Wed, Jul 03, 2013 at 05:06:37PM +0100, Mark Brown wrote:
> > On Thu, Jun 20, 2013 at 03:20:23PM +0200, Markus Pargmann wrote:

> > > +	ssi_private->use_dma = !of_property_read_bool(np, "fsl,imx-fiq");

> > This binding should be documented.  I'm not sure it really needs to be
> > a binding, though - is it not possible for the driver to just figure out
> > that DMA won't work automatically (for example by looking at the CODEC
> > in use)?  I'm not sure this is a good name either, it should be saying
> > why the FIQ is needed rather than saying that we should use the FIQ.

> I think fsl_ssi_startup is the first function in which we know which
> codec is connected to fsl-ssi. There we have access to the pcm runtime,
> which stores the codec used. But that is too late for the ssi setup.

> I could use of_find_compatible_node to search for the wm9712 codec, but
> that would assume that there is only one codec attached to the system.

If the SSI is doing anything it will be connected to a CODEC.  If it's
not connected to a CODEC then it doesn't need to be configured at all so
it doesn't really matter.

> Perhaps "fsl,fiq-filter-codec-stream" is a better name for the binding?

Possibly.
-------------- 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/20130708/45225acd/attachment.sig>

From balbi at ti.com  Mon Jul  8 05:02:54 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 8 Jul 2013 12:02:54 +0300
Subject: [PATCH 2/4] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in
 idle mode
In-Reply-To: <20130607214952.18581.90049.stgit@localhost>
References: <20130607214557.18581.75288.stgit@localhost>
 <20130607214952.18581.90049.stgit@localhost>
Message-ID: <20130708090254.GH29100@arwen.pp.htv.fi>

On Fri, Jun 07, 2013 at 02:49:52PM -0700, Tony Lindgren wrote:
> From: Andreas Fenkart <andreas.fenkart at streamunlimited.com>
> 
> Without functional clock the omap_hsmmc module can't forward SDIO IRQs to
> the system. This patch reconfigures dat1 line as a gpio while the fclk is
> off. When the fclk is present it uses the standard SDIO IRQ detection of
> the module.
> 
> The gpio irq is managed via the 'disable_depth' ref counter of the irq
> subsystem, this driver simply calls enable_irq/disable_irq when needed.
> 
>                       sdio irq    sdio irq
>                       unmasked     masked
>    -----------------------------------------
>     runtime default  |    1     |   2
>     runtime suspend  |    0     |   1
> 
>                   irq disable depth
> 
> 
> only when sdio irq is enabled AND the module is idle, the reference
> count drops to zero and the gpio irq is effectively armed.
> 
> Patch was tested on AM335x/Stream800. Test setup was two modules
> with sdio wifi cards. Modules where connected to a dual-band AP, each
> module using a different band. One of module was running iperf as server
> the other as client connecting to the server in a while true loop. Test
> was running for 4+ weeks. There were about 60 Mio. suspend/resume
> transitions. Test was shut down regularly.
> 
> Cc: Andreas Fenkart <afenkart at gmail.com>
> Cc: Balaji T K <balajitk at ti.com>
> Signed-off-by: Andreas Fenkart <andreas.fenkart at streamunlimited.com>
> Reviewed-by: Grant Likely <grant.likely at secretlab.ca>
> [tony at atomide.com: updated and separated out pin muxing]
> Signed-off-by: Tony Lindgren <tony at atomide.com>

right, as I discussed before the gpio part should also be split to a
separate patch. That's a workaround for broken HW anyway.

-- 
balbi
-------------- 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/20130708/faf18bc1/attachment.sig>

From b44548 at freescale.com  Mon Jul  8 04:37:00 2013
From: b44548 at freescale.com (Chao Fu)
Date: Mon, 8 Jul 2013 16:37:00 +0800
Subject: [PATCH 1/3] spi:Add Freescale DSPI driver for Vybrid VF610 platform
Message-ID: <1373272622-29064-1-git-send-email-b44548@freescale.com>

From: Chao Fu <B44548 at freescale.com>

The serial peripheral interface (SPI) module implemented on Freescale Vybrid 
platform provides a synchronous serial bus for communication between Vybrid 
and the external peripheral device. The SPI supports full-duplex, 
three-wire synchronous transfer, has TX/RX FIFO with depth of four entries.

This driver is the SPI master mode driver and has been tested on Vybrid VF610TWR board.

Signed-off-by: Alison Wang <b18965 at freescale.com>
Signed-off-by: Chao Fu  <b44548 at freescale.com>
---
 drivers/spi/Kconfig        |   6 +
 drivers/spi/Makefile       |   1 +
 drivers/spi/spi-fsl-dspi.c | 675 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 682 insertions(+)
 create mode 100644 drivers/spi/spi-fsl-dspi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 89cbbab..068715d 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -248,6 +248,12 @@ config SPI_FSL_SPI
 	  This also enables using the Aeroflex Gaisler GRLIB SPI controller in
 	  master mode.
 
+config SPI_FSL_DSPI
+         tristate "Freescale DSPI controller"
+         help
+         This enables support for the Freescale DSPI controller in master
+         mode.
+
 config SPI_FSL_ESPI
 	bool "Freescale eSPI controller"
 	depends on FSL_SOC
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 33f9c09..78416fd 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_SPI_EP93XX)		+= spi-ep93xx.o
 obj-$(CONFIG_SPI_FALCON)		+= spi-falcon.o
 obj-$(CONFIG_SPI_FSL_CPM)		+= spi-fsl-cpm.o
 obj-$(CONFIG_SPI_FSL_LIB)		+= spi-fsl-lib.o
+obj-$(CONFIG_SPI_FSL_DSPI)		+= spi-fsl-dspi.o
 obj-$(CONFIG_SPI_FSL_ESPI)		+= spi-fsl-espi.o
 obj-$(CONFIG_SPI_FSL_SPI)		+= spi-fsl-spi.o
 obj-$(CONFIG_SPI_GPIO)			+= spi-gpio.o
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
new file mode 100644
index 0000000..67e6c4b
--- /dev/null
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -0,0 +1,675 @@
+/*
+ * drivers/spi/spi-fsl-dspi.c
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Freescale DSPI driver
+ * This file contains a driver for the Freescale DSPI
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/errno.h>
+#include <linux/platform_device.h>
+#include <linux/sched.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/spi/spi.h>
+#include <linux/pm_runtime.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+
+#define DRIVER_NAME "fsl-dspi"
+
+#define TRAN_STATE_RX_VOID		0x01
+#define TRAN_STATE_TX_VOID		0x02
+#define TRAN_STATE_WORD_ODD_NUM		0x04
+
+#define DSPI_FIFO_SIZE			4
+
+#define SPI_MCR			0x00
+#define SPI_TCR			0x08
+
+#define SPI_CTAR(x)		(0x0c + (x * 4))
+#define SPI_CTAR_FMSZ(x)	(((x) & 0x0000000f) << 27)
+#define SPI_CTAR_CPOL(x)	((x) << 26)
+#define SPI_CTAR_CPHA(x)	((x) << 25)
+#define SPI_CTAR_PCSSCR(x)	(((x) & 0x00000003) << 22)
+#define SPI_CTAR_PASC(x)	(((x) & 0x00000003) << 20)
+#define SPI_CTAR_PDT(x)		(((x) & 0x00000003) << 18)
+#define SPI_CTAR_PBR(x)		(((x) & 0x00000003) << 16)
+#define SPI_CTAR_CSSCK(x)	(((x) & 0x0000000f) << 12)
+#define SPI_CTAR_ASC(x)		(((x) & 0x0000000f) << 8)
+#define SPI_CTAR_DT(x)		(((x) & 0x0000000f) << 4)
+#define SPI_CTAR_BR(x)		((x) & 0x0000000f)
+
+#define SPI_CTAR0_SLAVE		0x0c
+
+#define SPI_SR			0x2c
+#define SPI_SR_EOQF		0x10000000
+
+#define SPI_RSER		0x30
+#define SPI_RSER_EOQFE		0x10000000
+
+#define SPI_PUSHR		0x34
+#define SPI_PUSHR_CONT		(1 << 31)
+#define SPI_PUSHR_CTAS(x)	(((x) & 0x00000007) << 28)
+#define SPI_PUSHR_EOQ		(1 << 27)
+#define SPI_PUSHR_CTCNT		(1 << 26)
+#define SPI_PUSHR_PCS(x)	(((1 << x) & 0x0000003f) << 16)
+#define SPI_PUSHR_TXDATA(x)	((x) & 0x0000ffff)
+
+#define SPI_PUSHR_SLAVE		0x34
+
+#define SPI_POPR		0x38
+#define SPI_POPR_RXDATA(x)	((x) & 0x0000ffff)
+
+#define SPI_TXFR0		0x3c
+#define SPI_TXFR1		0x40
+#define SPI_TXFR2		0x44
+#define SPI_TXFR3		0x48
+#define SPI_RXFR0		0x7c
+#define SPI_RXFR1		0x80
+#define SPI_RXFR2		0x84
+#define SPI_RXFR3		0x88
+
+#define SPI_FRAME_BITS		SPI_CTAR_FMSZ(0xf)
+#define SPI_FRAME_BITS_16	SPI_CTAR_FMSZ(0xf)
+#define SPI_FRAME_BITS_8	SPI_CTAR_FMSZ(0x7)
+
+#define SPI_CS_INIT		0x01
+#define SPI_CS_ASSERT		0x02
+#define SPI_CS_DROP		0x04
+
+struct DSPI_MCR {
+	unsigned halt:1;
+	unsigned reserved71:7;
+	unsigned smpl_pt:2;
+	unsigned clr_rxf:1;
+	unsigned clr_tx:1;
+	unsigned dis_rxf:1;
+	unsigned dis_tx:1;
+	unsigned mdis:1;
+	unsigned reserved15:1;
+	unsigned pcsis:8;
+	unsigned rooe:1;
+	unsigned pcsse:1;
+	unsigned mtfe:1;
+	unsigned frz:1;
+	unsigned dconf:2;
+	unsigned cont_scke:1;
+	unsigned master:1;
+};
+
+struct DSPI_CTAR {
+	unsigned br:4;
+	unsigned dt:4;
+	unsigned asc:4;
+	unsigned cssck:4;
+	unsigned pbr:2;
+	unsigned pdt:2;
+	unsigned pasc:2;
+	unsigned pcssck:2;
+	unsigned lsbfe:1;
+	unsigned cpha:1;
+	unsigned cpol:1;
+	unsigned fmsz:4;
+	unsigned dbr:1;
+};
+
+struct chip_data {
+	/* dspi data */
+	union {
+		u32 mcr_val;
+		struct DSPI_MCR mcr;
+	};
+	union {
+		u32 ctar_val;
+		struct DSPI_CTAR ctar;
+	};
+	u16 void_write_data;
+};
+
+struct fsl_dspi {
+	struct platform_device *pdev;
+	struct spi_master *master;
+
+	void *base;
+	int irq;
+	struct clk *clk;
+
+	struct spi_message *cur_msg;
+	struct spi_transfer *cur_transfer;
+	struct chip_data *cur_chip;
+	size_t len;
+	void *tx;
+	void *tx_end;
+	void *rx;
+	void *rx_end;
+	char dataflags;
+	u8 cs;
+	u16 void_write_data;
+	unsigned	cs_change:1;
+
+	wait_queue_head_t waitq;
+	u32 waitflags;
+};
+
+/* SPI local functions */
+static inline int is_word_transfer(struct fsl_dspi *dspi)
+{
+	return ((readl(dspi->base + SPI_CTAR(dspi->cs)) & SPI_FRAME_BITS)
+			== SPI_FRAME_BITS_8) ? 0 : 1;
+}
+
+static void set_8bit_transfer_mode(struct fsl_dspi *dspi)
+{
+	u32 temp;
+
+	temp = readl(dspi->base + SPI_CTAR(dspi->cs));
+	temp &= ~SPI_FRAME_BITS;
+	temp |= SPI_FRAME_BITS_8;
+	writel(temp, dspi->base + SPI_CTAR(dspi->cs));
+}
+
+static void set_16bit_transfer_mode(struct fsl_dspi *dspi)
+{
+	u32 temp;
+
+	temp = readl(dspi->base + SPI_CTAR(dspi->cs));
+	temp &= ~SPI_FRAME_BITS;
+	temp |= SPI_FRAME_BITS_16;
+	writel(temp, dspi->base + SPI_CTAR(dspi->cs));
+}
+
+static unsigned char hz_to_spi_baud(int pbr, int dbr, int speed_hz,
+		unsigned long clkrate)
+{
+	/* Valid baud rate pre-scaler values */
+	int pbr_tbl[4] = {2, 3, 5, 7};
+	int brs[16] = {	2,	4,	6,	8,
+		16,	32,	64,	128,
+		256,	512,	1024,	2048,
+		4096,	8192,	16384,	32768 };
+	int temp, index = 0;
+
+	/* table indexes out of range, go slow */
+	if ((pbr < 0) || (pbr > 3) || (dbr < 0) || (dbr > 1))
+		return 15;
+
+	/* cpu core clk need to check */
+	temp = ((((clkrate / 2) / pbr_tbl[pbr]) * (1 + dbr)) / speed_hz);
+
+	while (temp > brs[index])
+		if (index++ >= 15)
+			break;
+
+	return index;
+}
+
+static void dspi_setup_chip(struct fsl_dspi *dspi)
+{
+	struct chip_data *chip = dspi->cur_chip;
+
+	writel(chip->mcr_val, dspi->base + SPI_MCR);
+	writel(chip->ctar_val, dspi->base + SPI_CTAR(dspi->cs));
+	writel(SPI_RSER_EOQFE, dspi->base + SPI_RSER);
+}
+
+static int dspi_transfer_write(struct fsl_dspi *dspi)
+{
+	int tx_count = 0;
+	int tx_word;
+	u16 d16;
+	u8  d8;
+	u32 dspi_pushr = 0;
+	int first = 1;
+
+	tx_word = is_word_transfer(dspi);
+	/* If we are in word mode, but only have a single byte to transfer
+	 * then switch to byte mode temporarily.  Will switch back at the
+	 * end of the transfer. */
+	if (tx_word && (dspi->len == 1)) {
+		dspi->dataflags |= TRAN_STATE_WORD_ODD_NUM;
+		set_8bit_transfer_mode(dspi);
+		tx_word = 0;
+	}
+	while (dspi->len && (tx_count < DSPI_FIFO_SIZE)) {
+		if (tx_word) {
+			if (dspi->len == 1)
+				break;
+
+			if (!(dspi->dataflags & TRAN_STATE_TX_VOID)) {
+				d16 = *(u16 *)dspi->tx;
+				dspi->tx += 2;
+			} else {
+				d16 = dspi->void_write_data;
+			}
+
+			dspi_pushr = SPI_PUSHR_TXDATA(d16) |
+				SPI_PUSHR_PCS(dspi->cs) |
+				SPI_PUSHR_CTAS(dspi->cs) |
+				SPI_PUSHR_CONT;
+
+			dspi->len -= 2;
+		} else {
+			if (!(dspi->dataflags & TRAN_STATE_TX_VOID)) {
+
+				d8 = *(u8 *)dspi->tx;
+				dspi->tx++;
+			} else {
+				d8 = (u8)dspi->void_write_data;
+			}
+
+			dspi_pushr = SPI_PUSHR_TXDATA(d8) |
+				SPI_PUSHR_PCS(dspi->cs) |
+				SPI_PUSHR_CTAS(dspi->cs) |
+				SPI_PUSHR_CONT;
+
+			dspi->len--;
+		}
+
+		if (dspi->len == 0
+				|| tx_count == DSPI_FIFO_SIZE - 1) {
+			/* last transfer in the queue */
+			dspi_pushr |= SPI_PUSHR_EOQ;
+			if ((dspi->cs_change)
+					&& (!dspi->len))
+				dspi_pushr &= ~SPI_PUSHR_CONT;
+		} else if (tx_word && (dspi->len == 1))
+			dspi_pushr |= SPI_PUSHR_EOQ;
+
+		if (first) {
+			first = 0;
+			dspi_pushr |= SPI_PUSHR_CTCNT; /* clear counter */
+		}
+
+		writel(dspi_pushr, dspi->base + SPI_PUSHR);
+		tx_count++;
+	}
+
+	return tx_count * (tx_word + 1);
+}
+static int dspi_transfer_read(struct fsl_dspi *dspi)
+{
+	int rx_count = 0;
+	int rx_word = is_word_transfer(dspi);
+	u16 d;
+	while ((dspi->rx < dspi->rx_end)
+			&& (rx_count < DSPI_FIFO_SIZE)) {
+		if (rx_word) {
+			if ((dspi->rx_end - dspi->rx) == 1)
+				break;
+
+			d = SPI_POPR_RXDATA(readl(dspi->base + SPI_POPR));
+
+			if (!(dspi->dataflags & TRAN_STATE_RX_VOID))
+				*(u16 *)dspi->rx = d;
+			dspi->rx += 2;
+
+		} else {
+			d = SPI_POPR_RXDATA(readl(dspi->base + SPI_POPR));
+			if (!(dspi->dataflags & TRAN_STATE_RX_VOID))
+				*(u8 *)dspi->rx = d;
+			dspi->rx++;
+		}
+		rx_count++;
+	}
+
+	return rx_count;
+}
+
+static int dspi_transfer_one_message(struct spi_master *master,
+		struct spi_message *message)
+{
+	struct fsl_dspi *dspi = spi_master_get_devdata(master);
+	struct spi_device *spi = message->spi;
+	struct spi_transfer *transfer;
+	int status = 0;
+	message->actual_length = 0;
+
+	list_for_each_entry(transfer, &message->transfers, transfer_list) {
+		dspi->cur_msg = message;
+		dspi->cur_transfer = transfer;
+		dspi->cur_chip = spi_get_ctldata(spi);
+		dspi->cs = spi->chip_select;
+		if (dspi->cur_transfer->transfer_list.next
+				== &dspi->cur_msg->transfers)
+			transfer->cs_change = 1;
+		dspi->cs_change = transfer->cs_change;
+		dspi->void_write_data = dspi->cur_chip->void_write_data;
+
+		dspi_setup_chip(dspi);
+
+		dspi->dataflags = 0;
+		dspi->tx = (void *)transfer->tx_buf;
+		dspi->tx_end = dspi->tx + transfer->len;
+		dspi->rx = transfer->rx_buf;
+		dspi->rx_end = dspi->rx + transfer->len;
+		dspi->len = transfer->len;
+
+		if (!dspi->rx)
+			dspi->dataflags |= TRAN_STATE_RX_VOID;
+
+		if (!dspi->tx)
+			dspi->dataflags |= TRAN_STATE_TX_VOID;
+
+		if (transfer->speed_hz)
+			writel((dspi->cur_chip->ctar_val & ~0xf) |
+				hz_to_spi_baud(dspi->cur_chip->ctar.pbr,
+					dspi->cur_chip->ctar.dbr,
+					transfer->speed_hz,
+					clk_get_rate(dspi->clk)),
+					dspi->base + SPI_CTAR(dspi->cs));
+
+
+		message->actual_length += dspi_transfer_write(dspi);
+
+		wait_event_interruptible(dspi->waitq, dspi->waitflags);
+		dspi->waitflags = 0;
+
+
+		if (transfer->delay_usecs)
+			udelay(transfer->delay_usecs);
+	}
+	message->status = status;
+	spi_finalize_current_message(master);
+
+	return status;
+}
+
+static int dspi_prepare_transfer_hw(struct spi_master *master)
+{
+	struct fsl_dspi *dspi = spi_master_get_devdata(master);
+
+	pm_runtime_get_sync(&dspi->pdev->dev);
+
+	return 0;
+}
+
+static int dspi_unprepare_transfer_hw(struct spi_master *master)
+{
+	struct fsl_dspi *dspi = spi_master_get_devdata(master);
+
+	pm_runtime_put_sync(&dspi->pdev->dev);
+
+	return 0;
+}
+
+static int dspi_setup(struct spi_device *spi)
+{
+	struct chip_data *chip;
+	struct fsl_dspi *dspi = spi_master_get_devdata(spi->master);
+	struct device_node *np = spi->dev.of_node;
+	unsigned char br = 0;
+	unsigned int dbr = 0 , pbr = 0;
+
+	/* Only alloc on first setup */
+	chip = spi_get_ctldata(spi);
+	if (chip == NULL) {
+		chip = kcalloc(1, sizeof(struct chip_data), GFP_KERNEL);
+		if (!chip)
+			return -ENOMEM;
+	}
+
+	chip->mcr.master = 1;
+	chip->mcr.cont_scke = 0;
+	chip->mcr.dconf = 0;
+	chip->mcr.frz = 0;
+	chip->mcr.mtfe = 0;
+	chip->mcr.pcsse = 0;
+	chip->mcr.rooe = 0;
+	chip->mcr.pcsis = 0xFF;
+	chip->mcr.reserved15 = 0;
+	chip->mcr.mdis = 0;
+	chip->mcr.dis_tx = 0;
+	chip->mcr.dis_rxf = 0;
+	chip->mcr.clr_tx = 1;
+	chip->mcr.clr_rxf = 1;
+	chip->mcr.smpl_pt = 0;
+	chip->mcr.reserved71 = 0;
+	chip->mcr.halt = 0;
+
+	if ((spi->bits_per_word >= 4) && (spi->bits_per_word <= 16)) {
+		chip->ctar.fmsz = spi->bits_per_word - 1;
+	} else {
+		printk(KERN_ERR "Invalid wordsize\n");
+		kfree(chip);
+		return -ENODEV;
+	}
+
+	chip->void_write_data = 0;
+	chip->ctar.cpha = (spi->mode & SPI_CPHA) ? 1 : 0;
+	chip->ctar.cpol = (spi->mode & SPI_CPOL) ? 1 : 0;
+	chip->ctar.lsbfe = (spi->mode & SPI_LSB_FIRST) ? 1 : 0;
+	of_property_read_u32(np, "dspi,ctar-dbr", &dbr);
+	of_property_read_u32(np, "dspi,ctar-pbr", &pbr);
+	chip->ctar.dbr = dbr;
+	chip->ctar.pbr = pbr;
+	if (spi->max_speed_hz == 0)
+		return -ENODEV;
+	br = hz_to_spi_baud(chip->ctar.pbr, chip->ctar.dbr,
+			spi->max_speed_hz, clk_get_rate(dspi->clk));
+	chip->ctar.br = br;
+	chip->ctar.pcssck = 0;
+	chip->ctar.pasc = 0;
+	chip->ctar.pdt = 0;
+	chip->ctar.cssck = 0;
+	chip->ctar.asc = 0;
+	chip->ctar.dt = 0;
+
+	spi_set_ctldata(spi, chip);
+
+	return 0;
+}
+
+static void dspi_cleanup(struct spi_device *spi)
+{
+	struct chip_data *chip = spi_get_ctldata((struct spi_device *)spi);
+
+	dev_dbg(&spi->dev, "spi_device %u.%u cleanup\n",
+			spi->master->bus_num, spi->chip_select);
+
+	kfree(chip);
+}
+
+static irqreturn_t dspi_interrupt(int irq, void *dev_id)
+{
+	struct fsl_dspi *dspi = (struct fsl_dspi *)dev_id;
+	struct spi_message *msg = dspi->cur_msg;
+
+	writel(SPI_SR_EOQF, dspi->base + SPI_SR);
+
+	if (!dspi->cur_msg) {
+		u32 irq_status = readl(dspi->base + SPI_SR);
+		printk(KERN_ERR "Bad message or transfer state handler. "
+				"IRQ status = %x\n", irq_status);
+		return IRQ_HANDLED;
+	}
+
+	dspi_transfer_read(dspi);
+
+	if (!dspi->len) {
+		/*
+		 * Finished now - fall through and schedule next
+		 * transfer tasklet
+		 */
+		if (dspi->dataflags & TRAN_STATE_WORD_ODD_NUM)
+			set_16bit_transfer_mode(dspi);
+		dspi->waitflags = 1;
+		wake_up_interruptible(&dspi->waitq);
+
+	} else {
+		/* not finished yet - keep going */
+		msg->actual_length += dspi_transfer_write(dspi);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static struct of_device_id fsl_dspi_dt_ids[] = {
+	{ .compatible = "fsl,vf610-dspi", .data = NULL, },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, fsl_dspi_dt_ids);
+
+#ifdef CONFIG_PM_SLEEP
+static int dspi_suspend(struct device *dev)
+{
+	struct spi_master *master = dev_get_drvdata(dev);
+	struct fsl_dspi *dspi = spi_master_get_devdata(master);
+
+	spi_master_suspend(master);
+	clk_disable_unprepare(dspi->clk);
+
+	return 0;
+}
+
+static int dspi_resume(struct device *dev)
+{
+
+	struct spi_master *master = dev_get_drvdata(dev);
+	struct fsl_dspi *dspi = spi_master_get_devdata(master);
+
+	clk_prepare_enable(dspi->clk);
+	spi_master_resume(master);
+
+	return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops dspi_pm = {
+	SET_SYSTEM_SLEEP_PM_OPS(dspi_suspend, dspi_resume)
+};
+
+static int dspi_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct spi_master *master;
+	struct fsl_dspi *dspi;
+	struct resource *res;
+	int ret = 0, cs_num, bus_num;
+
+	master = spi_alloc_master(&pdev->dev, sizeof(struct fsl_dspi));
+	if (!master)
+		return -ENOMEM;
+
+	dspi = spi_master_get_devdata(master);
+	dspi->master = master;
+
+	master->cleanup = dspi_cleanup;
+	master->setup = dspi_setup;
+	master->transfer = NULL;
+	master->transfer_one_message = dspi_transfer_one_message;
+	master->prepare_transfer_hardware = dspi_prepare_transfer_hw;
+	master->unprepare_transfer_hardware = dspi_unprepare_transfer_hw;
+	master->mode_bits = SPI_CPOL | SPI_CPHA;
+	master->bits_per_word_mask = SPI_BPW_MASK(4) | SPI_BPW_MASK(8) |
+					SPI_BPW_MASK(16);
+	master->dev.of_node = pdev->dev.of_node;
+
+	ret = of_property_read_u32(np, "spi-num-chipselects", &cs_num);
+	if (ret < 0)
+		goto fail;
+	master->num_chipselect = cs_num;
+
+	ret = of_property_read_u32(np, "bus-num", &bus_num);
+	if (ret < 0)
+		goto fail;
+	master->bus_num = bus_num;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(&pdev->dev, "can't get platform resource\n");
+		ret = -ENOMEM;
+		goto fail;
+	}
+
+	dspi->base = devm_ioremap_resource(&pdev->dev, res);
+	if (!dspi->base) {
+		ret = EINVAL;
+		goto fail;
+	}
+
+	dspi->irq = platform_get_irq(pdev, 0);
+	if (dspi->irq < 0) {
+		dev_err(&pdev->dev, "can't get platform irq\n");
+		ret = -ENOMEM;
+		goto fail;
+	}
+
+	ret = devm_request_irq(&pdev->dev, dspi->irq, dspi_interrupt, 0,
+			pdev->name, dspi);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Unable to attach DSPI interrupt\n");
+		goto fail;
+	}
+
+	dspi->clk = devm_clk_get(&pdev->dev, "dspi");
+	if (IS_ERR(dspi->clk)) {
+		dev_err(&pdev->dev, "unable to get clock\n");
+		goto fail;
+	}
+	clk_prepare_enable(dspi->clk);
+
+	init_waitqueue_head(&dspi->waitq);
+
+	/* Register with the SPI framework */
+	platform_set_drvdata(pdev, dspi);
+	ret = spi_register_master(master);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Problem registering DSPI master\n");
+		ret = -EINVAL;
+		goto fail;
+	}
+
+	printk(KERN_INFO "Freescale DSPI master initialized\n");
+	return ret;
+
+fail:
+	spi_master_put(master);
+	return ret;
+}
+
+static int dspi_remove(struct platform_device *pdev)
+{
+	struct fsl_dspi *dspi = platform_get_drvdata(pdev);
+
+	if (!dspi)
+		return 0;
+
+	clk_disable_unprepare(dspi->clk);
+	clk_put(dspi->clk);
+
+	/* Disconnect from the SPI framework */
+	spi_unregister_master(dspi->master);
+	spi_master_put(dspi->master);
+
+	/* Prevent double remove */
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static struct platform_driver fsl_dspi_driver = {
+	.driver.name    = DRIVER_NAME,
+	.driver.of_match_table = fsl_dspi_dt_ids,
+	.driver.owner   = THIS_MODULE,
+	.driver.pm = &dspi_pm,
+	.probe          = dspi_probe,
+	.remove		= dspi_remove,
+};
+module_platform_driver(fsl_dspi_driver);
+
+MODULE_DESCRIPTION("Freescale DSPI Controller Driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:" DRIVER_NAME);
-- 
1.8.0




From b44548 at freescale.com  Mon Jul  8 04:37:02 2013
From: b44548 at freescale.com (Chao Fu)
Date: Mon, 8 Jul 2013 16:37:02 +0800
Subject: [PATCH 3/3] ARM:dts:vf610-twr:Enable DSPI0 devices and Flash
 at26df081a
In-Reply-To: <1373272622-29064-1-git-send-email-b44548@freescale.com>
References: <1373272622-29064-1-git-send-email-b44548@freescale.com>
Message-ID: <1373272622-29064-3-git-send-email-b44548@freescale.com>

From: Chao Fu <B44548 at freescale.com>

This patch enables DSPI0 and at26df081a flash device for Vybrid VF610 TOWER board.

Signed-off-by: Chao Fu <b44548 at freescale.com>
---
 arch/arm/boot/dts/vf610-twr.dts | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index b3905f5..bc5bf9d 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -36,6 +36,28 @@
 
 };
 
+&dspi0 {
+	spi-num-chipselects = <1>;
+	bus-num = <0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_dspi0_1>;
+	status = "okay";
+
+	sflash: at26df081a at 0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "atmel,at26df081a";
+		spi-max-frequency = <16000000>;
+		spi-cpol;
+		spi-cpha;
+		dspi,ctar-dbr = <0>;
+		dspi,ctar-pbr = <0>;
+		reg = <0>;
+		linux,modalias = "m25p80";
+		modal = "at26df081a";
+	};
+};
+
 &fec0 {
 	phy-mode = "rmii";
 	pinctrl-names = "default";
-- 
1.8.0




From b44548 at freescale.com  Mon Jul  8 04:37:01 2013
From: b44548 at freescale.com (Chao Fu)
Date: Mon, 8 Jul 2013 16:37:01 +0800
Subject: [PATCH 2/3] ARM:dts: vf610: Add DSPI nodes
In-Reply-To: <1373272622-29064-1-git-send-email-b44548@freescale.com>
References: <1373272622-29064-1-git-send-email-b44548@freescale.com>
Message-ID: <1373272622-29064-2-git-send-email-b44548@freescale.com>

From: Chao Fu <B44548 at freescale.com>

Add Freescale DSPI node into vf610 dts.

Signed-off-by: Chao Fu <b44548 at freescale.com>
---
 arch/arm/boot/dts/vf610.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index e1eb7da..fc80f4a 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -87,6 +87,17 @@
 				arm,tag-latency = <2 2 2>;
 			};
 
+			dspi0: dspi0 at 4002c000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "fsl,vf610-dspi";
+				reg = <0x4002c000 0x1000>;
+				interrupts = <0 67 0x04>;
+				clocks = <&clks VF610_CLK_DSPI0>;
+				clock-names = "dspi";
+				status = "disabled";
+			};
+
 			uart0: serial at 40027000 {
 				compatible = "fsl,vf610-lpuart";
 				reg = <0x40027000 0x1000>;
-- 
1.8.0




From tony at atomide.com  Mon Jul  8 05:34:11 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Jul 2013 02:34:11 -0700
Subject: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c
In-Reply-To: <20130706133627.GV21614@n2100.arm.linux.org.uk>
References: <20130517191304.468.73487.stgit@localhost>
 <20130517191751.468.89202.stgit@localhost>
 <20130520095447.GR21614@n2100.arm.linux.org.uk>
 <20130706131057.GU21614@n2100.arm.linux.org.uk>
 <20130706133627.GV21614@n2100.arm.linux.org.uk>
Message-ID: <20130708093410.GT5523@atomide.com>

* Russell King - ARM Linux <linux at arm.linux.org.uk> [130706 06:42]:
> 
> Okay, I guessed that the OMAP4430SDP was "blaze" (it's not obvious to
> use internal codenames for boards when they're known as "SDP" etc -
> especially when they have stickers on them saying that they're "SDP".)

Agreed, let's update that.
 
> With that worked out, throwing my standard printascii() hack into the
> kernel results in boot messages... up to the point where the timer is
> calibrated.  So, it looks like either interrupts, clocks, or the OMAP
> timers are non-functional with DT based kernels on the SDP board.

Hey the good news is that you've updated your build system to support
also appended dtb images, thanks for doing that!
 
> Any ideas?

Looks like you need some things updated and added to your .config.

-# CONFIG_OMAP_MUX is not set
+CONFIG_MACH_OMAP_GENERIC=y

That we should nowadays always select though.

CONFIG_REGULATOR_FIXED_VOLTAGE=y

This you will need for Ethernet.

CONFIG_PINCTRL_SINGLE=y

This is good to have, will be needed especially for for UART
wake-up events with deeper idle modes enabled once the pending
pinctrl patches are merged.

Also, can you please add these for NFSroot:

CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_ROOT_NFS=y

That way I can also boot test your .config on regular basis ;)

Then there's a pending patch to change drivers/i2c/busses/i2c-omap.c
to use just a regular module_init, that should remove the i2c timeout
errors as then deferred probe will work properly.

BTW, maybe add a link to your build system to www.arm.linux.org.uk
developer page too? At least I could not find a link to it.

Regards,

Tony


From wni at nvidia.com  Mon Jul  8 05:36:05 2013
From: wni at nvidia.com (Wei Ni)
Date: Mon, 8 Jul 2013 17:36:05 +0800
Subject: [lm-sensors] [PATCH 1/2] ARM: dt: t30 cardhu: add dt entry for
 lm90
In-Reply-To: <20130708095024.041a6d57@endymion.delvare>
References: <1372928979-26938-1-git-send-email-wni@nvidia.com>
 <1372928979-26938-2-git-send-email-wni@nvidia.com>
 <51D70483.70203@wwwdotorg.org>	<51DA6BD4.1040300@nvidia.com>
 <20130708095024.041a6d57@endymion.delvare>
Message-ID: <51DA8805.50709@nvidia.com>

On 07/08/2013 03:50 PM, Jean Delvare wrote:
> On Mon, 8 Jul 2013 15:35:48 +0800, Wei Ni wrote:
>> On 07/06/2013 01:38 AM, Stephen Warren wrote:
>>> On 07/04/2013 03:09 AM, Wei Ni wrote:
>>>> Enable thermal sensor lm90 for t30 cardhu.
>>>
>>>> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
>>>
>>>> +		nct1008: nct1008 {
>>>> +			compatible = "lm90,nct1008";
>>>
>>> "lm90" isn't a valid vendor prefix. I believe the value you want is
>>> "onnn,nct1008". Same comment for patch 2/2.
>>
>> The lm90 doesn't support device tree very well.
> 
> I doubt it, but if this is the case, then please fix it, instead of
> working the problem around in a different place.
> 
>> In the DT, we need to
>> named as "lm90" so that the lm90 driver can be loaded,
> 
> Not that I am an expert with regards to DT, but this doesn't make any
> sense to me. AFAIK DT is about devices, not which drivers handle them.
> 
>> and we also need
>> to add "nct1008" to indicate this is the nct1008 device, so that the
>> lm90 driver can be loaded with the right i2c_device_id->driver_data.
>>
>> I set the " compatible = "lm90,nct1008" ", this is the simplest way, and
>> we doesn't need to change the lm90.c.
> 
> There's no problem with changing the lm90 driver, if this is the right
> thing to do.

Ok, I will add DT support in the lm90.c in my next version patch.

Thanks.
Wei.

> 



From b32955 at freescale.com  Mon Jul  8 05:14:16 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 8 Jul 2013 17:14:16 +0800
Subject: [PATCH v4 0/6] serial: imx: add DMA support for imx6
Message-ID: <1373274862-2695-1-git-send-email-b32955@freescale.com>

(1) This patch set adds the DMA support for the imx serial driver.
    The uart with the dma support is usually used by the Bluetooth.

    For the firmware's limit, i only enable the DMA for imx6 serials.
    If we have proper firmware for imx53 (or other chips), we can also
    enable the DMA for it.

(2) We only enable the DMA support when the following are meet:

    [1] The uart port supports the hardware flow control(CTS/RTS).
      (Some uart port does not support the CTS/RTS.)

    [2] The application enables the CTS/RTS.

    [3] The Soc is imx6 serials.
      For the sdma's firmware limit, we do not support the DMA except
      the imx6 platform.

    [4] The uart is not used as a console.


(3) Tested this patch set by:
	connecting a imx6q-arm2 board(DTE) with a imx53 board(DCE).

v3 --> v4:
	[0] add DTE pad for uart2

v2 --> v3:
	[0] add a new patch to fix the RTS/CTS pad name issue.
	[1] rename the uart DTE pinctrl, remove the "dte" from the pinctrl.
	[2] add a similar UART DTE pinctrl for IMX6DL.
	[3] move the "fsl,imx6q-uart" to the first of the compatible table.

v1 --> v2:
	[0] use the "fsl,imx6q-uart" as the new compatible value.
	[1] move dma_is_inited to imx_uart_dma_init();
	    move dma_is_enabled to imx_enable_dma();
	[2] move imx_disable_dma() to the front place of the imx_shutdown(),
	    just before calls the imx_uart_dma_exit().
	[3] misc    
	

Huang Shijie (6):
  serial: imx: distinguish the imx6q uart from the others
  serial: imx: add DMA support for imx6q
  ARM: dts: imx6sl: add "fsl,imx6q-uart" for uart compatible
  ARM: dts: imx6q{dl}: add DTE pads for uart
  ARM: dts: imx6q{dl}: add a DTE uart pinctrl for uart2
  ARM: dts: enable the uart2 for imx6q-arm2

 arch/arm/boot/dts/imx6dl-pinfunc.h |    4 +
 arch/arm/boot/dts/imx6dl.dtsi      |    9 +
 arch/arm/boot/dts/imx6q-arm2.dts   |   10 +
 arch/arm/boot/dts/imx6q-pinfunc.h  |    4 +
 arch/arm/boot/dts/imx6q.dtsi       |    9 +
 arch/arm/boot/dts/imx6sl.dtsi      |   15 +-
 drivers/tty/serial/imx.c           |  422 +++++++++++++++++++++++++++++++++++-
 7 files changed, 461 insertions(+), 12 deletions(-)




From b32955 at freescale.com  Mon Jul  8 05:14:17 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 8 Jul 2013 17:14:17 +0800
Subject: [PATCH v4 1/6] serial: imx: distinguish the imx6q uart from the others
In-Reply-To: <1373274862-2695-1-git-send-email-b32955@freescale.com>
References: <1373274862-2695-1-git-send-email-b32955@freescale.com>
Message-ID: <1373274862-2695-2-git-send-email-b32955@freescale.com>

We will add the DMA support for the imx uart. For the firmware's limit,
only the imx6 serial chips (including the imx6q, imx6dl, imx6sl) can
support the DMA.

This patch adds the necessary macro and helper to distinguish the
imx6q uart from the other imx uart. Other chips can use the "fsl,imx6q-uart"
to enable the DMA support.

This patch also replaces the check "is_imx21_uart()" with "!is_imx1_uart()".

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 drivers/tty/serial/imx.c |   17 +++++++++++++++--
 1 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 48bace0..a9643ef 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -187,6 +187,7 @@
 enum imx_uart_type {
 	IMX1_UART,
 	IMX21_UART,
+	IMX6Q_UART,
 };
 
 /* device type dependent stuff */
@@ -232,6 +233,10 @@ static struct imx_uart_data imx_uart_devdata[] = {
 		.uts_reg = IMX21_UTS,
 		.devtype = IMX21_UART,
 	},
+	[IMX6Q_UART] = {
+		.uts_reg = IMX21_UTS,
+		.devtype = IMX6Q_UART,
+	},
 };
 
 static struct platform_device_id imx_uart_devtype[] = {
@@ -242,12 +247,16 @@ static struct platform_device_id imx_uart_devtype[] = {
 		.name = "imx21-uart",
 		.driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX21_UART],
 	}, {
+		.name = "imx6q-uart",
+		.driver_data = (kernel_ulong_t) &imx_uart_devdata[IMX6Q_UART],
+	}, {
 		/* sentinel */
 	}
 };
 MODULE_DEVICE_TABLE(platform, imx_uart_devtype);
 
 static struct of_device_id imx_uart_dt_ids[] = {
+	{ .compatible = "fsl,imx6q-uart", .data = &imx_uart_devdata[IMX6Q_UART], },
 	{ .compatible = "fsl,imx1-uart", .data = &imx_uart_devdata[IMX1_UART], },
 	{ .compatible = "fsl,imx21-uart", .data = &imx_uart_devdata[IMX21_UART], },
 	{ /* sentinel */ }
@@ -269,6 +278,10 @@ static inline int is_imx21_uart(struct imx_port *sport)
 	return sport->devdata->devtype == IMX21_UART;
 }
 
+static inline int is_imx6q_uart(struct imx_port *sport)
+{
+	return sport->devdata->devtype == IMX6Q_UART;
+}
 /*
  * Save and restore functions for UCR1, UCR2 and UCR3 registers
  */
@@ -801,7 +814,7 @@ static int imx_startup(struct uart_port *port)
 		}
 	}
 
-	if (is_imx21_uart(sport)) {
+	if (!is_imx1_uart(sport)) {
 		temp = readl(sport->port.membase + UCR3);
 		temp |= IMX21_UCR3_RXDMUXSEL;
 		writel(temp, sport->port.membase + UCR3);
@@ -1044,7 +1057,7 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 	writel(num, sport->port.membase + UBIR);
 	writel(denom, sport->port.membase + UBMR);
 
-	if (is_imx21_uart(sport))
+	if (!is_imx1_uart(sport))
 		writel(sport->port.uartclk / div / 1000,
 				sport->port.membase + IMX21_ONEMS);
 
-- 
1.7.1




From b32955 at freescale.com  Mon Jul  8 05:14:21 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 8 Jul 2013 17:14:21 +0800
Subject: [PATCH v4 5/6] ARM: dts: imx6q{dl}: add a DTE uart pinctrl for uart2
In-Reply-To: <1373274862-2695-1-git-send-email-b32955@freescale.com>
References: <1373274862-2695-1-git-send-email-b32955@freescale.com>
Message-ID: <1373274862-2695-6-git-send-email-b32955@freescale.com>

In the arm2 board, the UART2 works in the dte mode.
So add a pinctrl for both the imx6q{dl} boards.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6dl.dtsi |    9 +++++++++
 arch/arm/boot/dts/imx6q.dtsi  |    9 +++++++++
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 2b5628d..a1302ed 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -223,6 +223,15 @@
 							MX6DL_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
 						>;
 					};
+
+					pinctrl_uart2_2: uart2grp-2 { /* DTE mode */
+						fsl,pins = <
+							MX6DL_PAD_EIM_D26__UART2_RX_DATA   0x1b0b1
+							MX6DL_PAD_EIM_D27__UART2_TX_DATA   0x1b0b1
+							MX6DL_PAD_EIM_D28__UART2_DTE_CTS_B 0x1b0b1
+							MX6DL_PAD_EIM_D29__UART2_DTE_RTS_B 0x1b0b1
+						>;
+					};
 				};
 
 				uart4 {
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 6f4d6ab..e0b7bad 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -266,6 +266,15 @@
 							MX6Q_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
 						>;
 					};
+
+					pinctrl_uart2_2: uart2grp-2 { /* DTE mode */
+						fsl,pins = <
+							MX6Q_PAD_EIM_D26__UART2_RX_DATA   0x1b0b1
+							MX6Q_PAD_EIM_D27__UART2_TX_DATA   0x1b0b1
+							MX6Q_PAD_EIM_D28__UART2_DTE_CTS_B 0x1b0b1
+							MX6Q_PAD_EIM_D29__UART2_DTE_RTS_B 0x1b0b1
+						>;
+					};
 				};
 
 				uart4 {
-- 
1.7.1




From b32955 at freescale.com  Mon Jul  8 05:14:22 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 8 Jul 2013 17:14:22 +0800
Subject: [PATCH v4 6/6] ARM: dts: enable the uart2 for imx6q-arm2
In-Reply-To: <1373274862-2695-1-git-send-email-b32955@freescale.com>
References: <1373274862-2695-1-git-send-email-b32955@freescale.com>
Message-ID: <1373274862-2695-7-git-send-email-b32955@freescale.com>

enable the uart2 for imx6q-arm2 board.
The uart2 works in the DTE mode, with the RTS/CTS and DMA enabled.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6q-arm2.dts |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-arm2.dts b/arch/arm/boot/dts/imx6q-arm2.dts
index 4e54fde..e7e3b56 100644
--- a/arch/arm/boot/dts/imx6q-arm2.dts
+++ b/arch/arm/boot/dts/imx6q-arm2.dts
@@ -97,6 +97,16 @@
 	status = "okay";
 };
 
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2_2>;
+	fsl,dte-mode;
+	fsl,uart-has-rtscts;
+	dma-names = "rx", "tx";
+	dmas = <&sdma 27 4 0>, <&sdma 28 4 0>;
+	status = "okay";
+};
+
 &uart4 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart4_1>;
-- 
1.7.1




From b32955 at freescale.com  Mon Jul  8 05:14:20 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 8 Jul 2013 17:14:20 +0800
Subject: [PATCH v4 4/6] ARM: dts: imx6q{dl}: add DTE pads for uart
In-Reply-To: <1373274862-2695-1-git-send-email-b32955@freescale.com>
References: <1373274862-2695-1-git-send-email-b32955@freescale.com>
Message-ID: <1373274862-2695-5-git-send-email-b32955@freescale.com>

The uart2 in the imx6q-arm2 board is used as a DTE uart,
this patch adds the necessary DTE pads for uart2.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6dl-pinfunc.h |    4 ++++
 arch/arm/boot/dts/imx6q-pinfunc.h  |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl-pinfunc.h b/arch/arm/boot/dts/imx6dl-pinfunc.h
index 9aab950..dc44d0a 100644
--- a/arch/arm/boot/dts/imx6dl-pinfunc.h
+++ b/arch/arm/boot/dts/imx6dl-pinfunc.h
@@ -461,6 +461,8 @@
 #define MX6DL_PAD_EIM_D28__IPU1_CSI1_DATA12        0x174 0x544 0x890 0x3 0x1
 #define MX6DL_PAD_EIM_D28__UART2_CTS_B             0x174 0x544 0x000 0x4 0x0
 #define MX6DL_PAD_EIM_D28__UART2_RTS_B             0x174 0x544 0x900 0x4 0x0
+#define MX6DL_PAD_EIM_D28__UART2_DTE_CTS_B         0x174 0x544 0x900 0x4 0x0
+#define MX6DL_PAD_EIM_D28__UART2_DTE_RTS_B         0x174 0x544 0x000 0x4 0x0
 #define MX6DL_PAD_EIM_D28__GPIO3_IO28              0x174 0x544 0x000 0x5 0x0
 #define MX6DL_PAD_EIM_D28__IPU1_EXT_TRIG           0x174 0x544 0x000 0x6 0x0
 #define MX6DL_PAD_EIM_D28__IPU1_DI0_PIN13          0x174 0x544 0x000 0x7 0x0
@@ -470,6 +472,8 @@
 #define MX6DL_PAD_EIM_D29__ECSPI4_SS0              0x178 0x548 0x808 0x2 0x1
 #define MX6DL_PAD_EIM_D29__UART2_RTS_B             0x178 0x548 0x900 0x4 0x1
 #define MX6DL_PAD_EIM_D29__UART2_CTS_B             0x178 0x548 0x000 0x4 0x0
+#define MX6DL_PAD_EIM_D29__UART2_DTE_RTS_B         0x178 0x548 0x000 0x4 0x0
+#define MX6DL_PAD_EIM_D29__UART2_DTE_CTS_B         0x178 0x548 0x900 0x4 0x1
 #define MX6DL_PAD_EIM_D29__GPIO3_IO29              0x178 0x548 0x000 0x5 0x0
 #define MX6DL_PAD_EIM_D29__IPU1_CSI1_VSYNC         0x178 0x548 0x8bc 0x6 0x0
 #define MX6DL_PAD_EIM_D29__IPU1_DI0_PIN14          0x178 0x548 0x000 0x7 0x0
diff --git a/arch/arm/boot/dts/imx6q-pinfunc.h b/arch/arm/boot/dts/imx6q-pinfunc.h
index faea6e1..01365f7 100644
--- a/arch/arm/boot/dts/imx6q-pinfunc.h
+++ b/arch/arm/boot/dts/imx6q-pinfunc.h
@@ -197,6 +197,8 @@
 #define MX6Q_PAD_EIM_D28__IPU2_CSI1_DATA12        0x0c4 0x3d8 0x8b8 0x3 0x0
 #define MX6Q_PAD_EIM_D28__UART2_CTS_B             0x0c4 0x3d8 0x000 0x4 0x0
 #define MX6Q_PAD_EIM_D28__UART2_RTS_B             0x0c4 0x3d8 0x924 0x4 0x0
+#define MX6Q_PAD_EIM_D28__UART2_DTE_CTS_B         0x0c4 0x3d8 0x924 0x4 0x0
+#define MX6Q_PAD_EIM_D28__UART2_DTE_RTS_B         0x0c4 0x3d8 0x000 0x4 0x0
 #define MX6Q_PAD_EIM_D28__GPIO3_IO28              0x0c4 0x3d8 0x000 0x5 0x0
 #define MX6Q_PAD_EIM_D28__IPU1_EXT_TRIG           0x0c4 0x3d8 0x000 0x6 0x0
 #define MX6Q_PAD_EIM_D28__IPU1_DI0_PIN13          0x0c4 0x3d8 0x000 0x7 0x0
@@ -205,6 +207,8 @@
 #define MX6Q_PAD_EIM_D29__ECSPI4_SS0              0x0c8 0x3dc 0x824 0x2 0x1
 #define MX6Q_PAD_EIM_D29__UART2_RTS_B             0x0c8 0x3dc 0x924 0x4 0x1
 #define MX6Q_PAD_EIM_D29__UART2_CTS_B             0x0c8 0x3dc 0x000 0x4 0x0
+#define MX6Q_PAD_EIM_D29__UART2_DTE_RTS_B         0x0c4 0x3dc 0x000 0x4 0x0
+#define MX6Q_PAD_EIM_D29__UART2_DTE_CTS_B         0x0c4 0x3dc 0x924 0x4 0x1
 #define MX6Q_PAD_EIM_D29__GPIO3_IO29              0x0c8 0x3dc 0x000 0x5 0x0
 #define MX6Q_PAD_EIM_D29__IPU2_CSI1_VSYNC         0x0c8 0x3dc 0x8e4 0x6 0x0
 #define MX6Q_PAD_EIM_D29__IPU1_DI0_PIN14          0x0c8 0x3dc 0x000 0x7 0x0
-- 
1.7.1




From b32955 at freescale.com  Mon Jul  8 05:14:19 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 8 Jul 2013 17:14:19 +0800
Subject: [PATCH v4 3/6] ARM: dts: imx6sl: add "fsl,
 imx6q-uart" for uart compatible
In-Reply-To: <1373274862-2695-1-git-send-email-b32955@freescale.com>
References: <1373274862-2695-1-git-send-email-b32955@freescale.com>
Message-ID: <1373274862-2695-4-git-send-email-b32955@freescale.com>

In order to enable the DMA for some uart port in imx6sl, we add the
"fsl,imx6q-uart" to the uart's compatible property.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6sl.dtsi |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 9138c67..0a297af 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -152,7 +152,8 @@
 				};
 
 				uart5: serial at 02018000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02018000 0x4000>;
 					interrupts = <0 30 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -162,7 +163,8 @@
 				};
 
 				uart1: serial at 02020000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02020000 0x4000>;
 					interrupts = <0 26 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -172,7 +174,8 @@
 				};
 
 				uart2: serial at 02024000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02024000 0x4000>;
 					interrupts = <0 27 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -209,7 +212,8 @@
 				};
 
 				uart3: serial at 02034000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02034000 0x4000>;
 					interrupts = <0 28 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
@@ -219,7 +223,8 @@
 				};
 
 				uart4: serial at 02038000 {
-					compatible = "fsl,imx6sl-uart", "fsl,imx21-uart";
+					compatible = "fsl,imx6sl-uart",
+						   "fsl,imx6q-uart", "fsl,imx21-uart";
 					reg = <0x02038000 0x4000>;
 					interrupts = <0 29 0x04>;
 					clocks = <&clks IMX6SL_CLK_UART>,
-- 
1.7.1




From b32955 at freescale.com  Mon Jul  8 05:14:18 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 8 Jul 2013 17:14:18 +0800
Subject: [PATCH v4 2/6] serial: imx: add DMA support for imx6q
In-Reply-To: <1373274862-2695-1-git-send-email-b32955@freescale.com>
References: <1373274862-2695-1-git-send-email-b32955@freescale.com>
Message-ID: <1373274862-2695-3-git-send-email-b32955@freescale.com>

We only enable the DMA support when the following are meet:

  [1] The uart port supports the hardware flow control(CTS/RTS).
      (Some uart port does not support the CTS/RTS.)

  [2] The application enables the CTS/RTS.

  [3] The Soc is imx6q.
      For the sdma's firmware limit, we do not support the DMA except
      the imx6q platform.

  [4] The uart is not used as a console.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 drivers/tty/serial/imx.c |  405 +++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 400 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index a9643ef..d04a09e 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -49,9 +49,11 @@
 #include <linux/of_device.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/io.h>
+#include <linux/dma-mapping.h>
 
 #include <asm/irq.h>
 #include <linux/platform_data/serial-imx.h>
+#include <linux/platform_data/dma-imx.h>
 
 /* Register definitions */
 #define URXD0 0x0  /* Receiver Register */
@@ -83,6 +85,7 @@
 #define UCR1_ADBR	(1<<14) /* Auto detect baud rate */
 #define UCR1_TRDYEN	(1<<13) /* Transmitter ready interrupt enable */
 #define UCR1_IDEN	(1<<12) /* Idle condition interrupt */
+#define UCR1_ICD_REG(x) (((x) & 3) << 10) /* idle condition detect */
 #define UCR1_RRDYEN	(1<<9)	/* Recv ready interrupt enable */
 #define UCR1_RDMAEN	(1<<8)	/* Recv ready DMA enable */
 #define UCR1_IREN	(1<<7)	/* Infrared interface enable */
@@ -91,6 +94,7 @@
 #define UCR1_SNDBRK	(1<<4)	/* Send break */
 #define UCR1_TDMAEN	(1<<3)	/* Transmitter ready DMA enable */
 #define IMX1_UCR1_UARTCLKEN (1<<2) /* UART clock enabled, i.mx1 only */
+#define UCR1_ATDMAEN    (1<<2)  /* Aging DMA Timer Enable */
 #define UCR1_DOZE	(1<<1)	/* Doze */
 #define UCR1_UARTEN	(1<<0)	/* UART enabled */
 #define UCR2_ESCI	(1<<15)	/* Escape seq interrupt enable */
@@ -126,6 +130,7 @@
 #define UCR4_ENIRI	(1<<8)	/* Serial infrared interrupt enable */
 #define UCR4_WKEN	(1<<7)	/* Wake interrupt enable */
 #define UCR4_REF16	(1<<6)	/* Ref freq 16 MHz */
+#define UCR4_IDDMAEN    (1<<6)  /* DMA IDLE Condition Detected */
 #define UCR4_IRSC	(1<<5)	/* IR special case */
 #define UCR4_TCEN	(1<<3)	/* Transmit complete interrupt enable */
 #define UCR4_BKEN	(1<<2)	/* Break condition interrupt enable */
@@ -210,6 +215,19 @@ struct imx_port {
 	struct clk		*clk_ipg;
 	struct clk		*clk_per;
 	const struct imx_uart_data *devdata;
+
+	/* DMA fields */
+	unsigned int		dma_is_inited:1;
+	unsigned int		dma_is_enabled:1;
+	unsigned int		dma_is_rxing:1;
+	unsigned int		dma_is_txing:1;
+	struct dma_chan		*dma_chan_rx, *dma_chan_tx;
+	struct scatterlist	rx_sgl, tx_sgl[2];
+	void			*rx_buf;
+	unsigned int		rx_bytes, tx_bytes;
+	struct work_struct	tsk_dma_rx, tsk_dma_tx;
+	unsigned int		dma_tx_nents;
+	wait_queue_head_t	dma_wait;
 };
 
 struct imx_port_ucrs {
@@ -400,6 +418,13 @@ static void imx_stop_tx(struct uart_port *port)
 		return;
 	}
 
+	/*
+	 * We are maybe in the SMP context, so if the DMA TX thread is running
+	 * on other cpu, we have to wait for it to finish.
+	 */
+	if (sport->dma_is_enabled && sport->dma_is_txing)
+		return;
+
 	temp = readl(sport->port.membase + UCR1);
 	writel(temp & ~UCR1_TXMPTYEN, sport->port.membase + UCR1);
 }
@@ -412,6 +437,13 @@ static void imx_stop_rx(struct uart_port *port)
 	struct imx_port *sport = (struct imx_port *)port;
 	unsigned long temp;
 
+	/*
+	 * We are maybe in the SMP context, so if the DMA TX thread is running
+	 * on other cpu, we have to wait for it to finish.
+	 */
+	if (sport->dma_is_enabled && sport->dma_is_rxing)
+		return;
+
 	temp = readl(sport->port.membase + UCR2);
 	writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
 }
@@ -447,6 +479,95 @@ static inline void imx_transmit_buffer(struct imx_port *sport)
 		imx_stop_tx(&sport->port);
 }
 
+static void dma_tx_callback(void *data)
+{
+	struct imx_port *sport = data;
+	struct scatterlist *sgl = &sport->tx_sgl[0];
+	struct circ_buf *xmit = &sport->port.state->xmit;
+	unsigned long flags;
+
+	dma_unmap_sg(sport->port.dev, sgl, sport->dma_tx_nents, DMA_TO_DEVICE);
+
+	sport->dma_is_txing = 0;
+
+	/* update the stat */
+	spin_lock_irqsave(&sport->port.lock, flags);
+	xmit->tail = (xmit->tail + sport->tx_bytes) & (UART_XMIT_SIZE - 1);
+	sport->port.icount.tx += sport->tx_bytes;
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+
+	dev_dbg(sport->port.dev, "we finish the TX DMA.\n");
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(&sport->port);
+
+	if (waitqueue_active(&sport->dma_wait)) {
+		wake_up(&sport->dma_wait);
+		dev_dbg(sport->port.dev, "exit in %s.\n", __func__);
+		return;
+	}
+
+	schedule_work(&sport->tsk_dma_tx);
+}
+
+static void dma_tx_work(struct work_struct *w)
+{
+	struct imx_port *sport = container_of(w, struct imx_port, tsk_dma_tx);
+	struct circ_buf *xmit = &sport->port.state->xmit;
+	struct scatterlist *sgl = sport->tx_sgl;
+	struct dma_async_tx_descriptor *desc;
+	struct dma_chan	*chan = sport->dma_chan_tx;
+	struct device *dev = sport->port.dev;
+	enum dma_status status;
+	unsigned long flags;
+	int ret;
+
+	status = chan->device->device_tx_status(chan, (dma_cookie_t)0, NULL);
+	if (DMA_IN_PROGRESS == status)
+		return;
+
+	spin_lock_irqsave(&sport->port.lock, flags);
+	sport->tx_bytes = uart_circ_chars_pending(xmit);
+	if (sport->tx_bytes == 0) {
+		spin_unlock_irqrestore(&sport->port.lock, flags);
+		return;
+	}
+
+	if (xmit->tail > xmit->head) {
+		sport->dma_tx_nents = 2;
+		sg_init_table(sgl, 2);
+		sg_set_buf(sgl, xmit->buf + xmit->tail,
+				UART_XMIT_SIZE - xmit->tail);
+		sg_set_buf(sgl + 1, xmit->buf, xmit->head);
+	} else {
+		sport->dma_tx_nents = 1;
+		sg_init_one(sgl, xmit->buf + xmit->tail, sport->tx_bytes);
+	}
+	spin_unlock_irqrestore(&sport->port.lock, flags);
+
+	ret = dma_map_sg(dev, sgl, sport->dma_tx_nents, DMA_TO_DEVICE);
+	if (ret == 0) {
+		dev_err(dev, "DMA mapping error for TX.\n");
+		return;
+	}
+	desc = dmaengine_prep_slave_sg(chan, sgl, sport->dma_tx_nents,
+					DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT);
+	if (!desc) {
+		dev_err(dev, "We cannot prepare for the TX slave dma!\n");
+		return;
+	}
+	desc->callback = dma_tx_callback;
+	desc->callback_param = sport;
+
+	dev_dbg(dev, "TX: prepare to send %lu bytes by DMA.\n",
+			uart_circ_chars_pending(xmit));
+	/* fire it */
+	sport->dma_is_txing = 1;
+	dmaengine_submit(desc);
+	dma_async_issue_pending(chan);
+	return;
+}
+
 /*
  * interrupts disabled on entry
  */
@@ -473,8 +594,10 @@ static void imx_start_tx(struct uart_port *port)
 	temp |= UCR4_OREN;
 	writel(temp, sport->port.membase + UCR4);
 
-	temp = readl(sport->port.membase + UCR1);
-	writel(temp | UCR1_TXMPTYEN, sport->port.membase + UCR1);
+	if (!sport->dma_is_enabled) {
+		temp = readl(sport->port.membase + UCR1);
+		writel(temp | UCR1_TXMPTYEN, sport->port.membase + UCR1);
+	}
 
 	if (USE_IRDA(sport)) {
 		temp = readl(sport->port.membase + UCR1);
@@ -486,6 +609,15 @@ static void imx_start_tx(struct uart_port *port)
 		writel(temp, sport->port.membase + UCR4);
 	}
 
+	if (sport->dma_is_enabled) {
+		/*
+		 * We may in the interrupt context, so arise a work_struct to
+		 * do the real job.
+		 */
+		schedule_work(&sport->tsk_dma_tx);
+		return;
+	}
+
 	if (readl(sport->port.membase + uts_reg(sport)) & UTS_TXEMPTY)
 		imx_transmit_buffer(sport);
 }
@@ -601,6 +733,28 @@ out:
 	return IRQ_HANDLED;
 }
 
+/*
+ * If the RXFIFO is filled with some data, and then we
+ * arise a DMA operation to receive them.
+ */
+static void imx_dma_rxint(struct imx_port *sport)
+{
+	unsigned long temp;
+
+	temp = readl(sport->port.membase + USR2);
+	if ((temp & USR2_RDR) && !sport->dma_is_rxing) {
+		sport->dma_is_rxing = 1;
+
+		/* disable the `Recerver Ready Interrrupt` */
+		temp = readl(sport->port.membase + UCR1);
+		temp &= ~(UCR1_RRDYEN);
+		writel(temp, sport->port.membase + UCR1);
+
+		/* tell the DMA to receive the data. */
+		schedule_work(&sport->tsk_dma_rx);
+	}
+}
+
 static irqreturn_t imx_int(int irq, void *dev_id)
 {
 	struct imx_port *sport = dev_id;
@@ -609,8 +763,12 @@ static irqreturn_t imx_int(int irq, void *dev_id)
 
 	sts = readl(sport->port.membase + USR1);
 
-	if (sts & USR1_RRDY)
-		imx_rxint(irq, dev_id);
+	if (sts & USR1_RRDY) {
+		if (sport->dma_is_enabled)
+			imx_dma_rxint(sport);
+		else
+			imx_rxint(irq, dev_id);
+	}
 
 	if (sts & USR1_TRDY &&
 			readl(sport->port.membase + UCR1) & UCR1_TXMPTYEN)
@@ -667,7 +825,8 @@ static void imx_set_mctrl(struct uart_port *port, unsigned int mctrl)
 	temp = readl(sport->port.membase + UCR2) & ~UCR2_CTS;
 
 	if (mctrl & TIOCM_RTS)
-		temp |= UCR2_CTS;
+		if (!sport->dma_is_enabled)
+			temp |= UCR2_CTS;
 
 	writel(temp, sport->port.membase + UCR2);
 }
@@ -706,6 +865,226 @@ static int imx_setup_ufcr(struct imx_port *sport, unsigned int mode)
 	return 0;
 }
 
+#define RX_BUF_SIZE	(PAGE_SIZE)
+static int start_rx_dma(struct imx_port *sport);
+static void dma_rx_work(struct work_struct *w)
+{
+	struct imx_port *sport = container_of(w, struct imx_port, tsk_dma_rx);
+	struct tty_port *port = &sport->port.state->port;
+
+	if (sport->rx_bytes) {
+		tty_insert_flip_string(port, sport->rx_buf, sport->rx_bytes);
+		tty_flip_buffer_push(port);
+		sport->rx_bytes = 0;
+	}
+
+	if (sport->dma_is_rxing)
+		start_rx_dma(sport);
+}
+
+static void imx_rx_dma_done(struct imx_port *sport)
+{
+	unsigned long temp;
+
+	/* Enable this interrupt when the RXFIFO is empty. */
+	temp = readl(sport->port.membase + UCR1);
+	temp |= UCR1_RRDYEN;
+	writel(temp, sport->port.membase + UCR1);
+
+	sport->dma_is_rxing = 0;
+
+	/* Is the shutdown waiting for us? */
+	if (waitqueue_active(&sport->dma_wait))
+		wake_up(&sport->dma_wait);
+}
+
+/*
+ * There are three kinds of RX DMA interrupts(such as in the MX6Q):
+ *   [1] the RX DMA buffer is full.
+ *   [2] the Aging timer expires(wait for 8 bytes long)
+ *   [3] the Idle Condition Detect(enabled the UCR4_IDDMAEN).
+ *
+ * The [2] is trigger when a character was been sitting in the FIFO
+ * meanwhile [3] can wait for 32 bytes long when the RX line is
+ * on IDLE state and RxFIFO is empty.
+ */
+static void dma_rx_callback(void *data)
+{
+	struct imx_port *sport = data;
+	struct dma_chan	*chan = sport->dma_chan_rx;
+	struct scatterlist *sgl = &sport->rx_sgl;
+	struct dma_tx_state state;
+	enum dma_status status;
+	unsigned int count;
+
+	/* unmap it first */
+	dma_unmap_sg(sport->port.dev, sgl, 1, DMA_FROM_DEVICE);
+
+	status = chan->device->device_tx_status(chan, (dma_cookie_t)0, &state);
+	count = RX_BUF_SIZE - state.residue;
+	dev_dbg(sport->port.dev, "We get %d bytes.\n", count);
+
+	if (count) {
+		sport->rx_bytes = count;
+		schedule_work(&sport->tsk_dma_rx);
+	} else
+		imx_rx_dma_done(sport);
+}
+
+static int start_rx_dma(struct imx_port *sport)
+{
+	struct scatterlist *sgl = &sport->rx_sgl;
+	struct dma_chan	*chan = sport->dma_chan_rx;
+	struct device *dev = sport->port.dev;
+	struct dma_async_tx_descriptor *desc;
+	int ret;
+
+	sg_init_one(sgl, sport->rx_buf, RX_BUF_SIZE);
+	ret = dma_map_sg(dev, sgl, 1, DMA_FROM_DEVICE);
+	if (ret == 0) {
+		dev_err(dev, "DMA mapping error for RX.\n");
+		return -EINVAL;
+	}
+	desc = dmaengine_prep_slave_sg(chan, sgl, 1, DMA_DEV_TO_MEM,
+					DMA_PREP_INTERRUPT);
+	if (!desc) {
+		dev_err(dev, "We cannot prepare for the RX slave dma!\n");
+		return -EINVAL;
+	}
+	desc->callback = dma_rx_callback;
+	desc->callback_param = sport;
+
+	dev_dbg(dev, "RX: prepare for the DMA.\n");
+	dmaengine_submit(desc);
+	dma_async_issue_pending(chan);
+	return 0;
+}
+
+static void imx_uart_dma_exit(struct imx_port *sport)
+{
+	if (sport->dma_chan_rx) {
+		dma_release_channel(sport->dma_chan_rx);
+		sport->dma_chan_rx = NULL;
+
+		kfree(sport->rx_buf);
+		sport->rx_buf = NULL;
+	}
+
+	if (sport->dma_chan_tx) {
+		dma_release_channel(sport->dma_chan_tx);
+		sport->dma_chan_tx = NULL;
+	}
+
+	sport->dma_is_inited = 0;
+}
+
+static int imx_uart_dma_init(struct imx_port *sport)
+{
+	struct dma_slave_config slave_config;
+	struct device *dev = sport->port.dev;
+	int ret;
+
+	/* Prepare for RX : */
+	sport->dma_chan_rx = dma_request_slave_channel(dev, "rx");
+	if (!sport->dma_chan_rx) {
+		dev_dbg(dev, "cannot get the DMA channel.\n");
+		ret = -EINVAL;
+		goto err;
+	}
+
+	slave_config.direction = DMA_DEV_TO_MEM;
+	slave_config.src_addr = sport->port.mapbase + URXD0;
+	slave_config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	slave_config.src_maxburst = RXTL;
+	ret = dmaengine_slave_config(sport->dma_chan_rx, &slave_config);
+	if (ret) {
+		dev_err(dev, "error in RX dma configuration.\n");
+		goto err;
+	}
+
+	sport->rx_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
+	if (!sport->rx_buf) {
+		dev_err(dev, "cannot alloc DMA buffer.\n");
+		ret = -ENOMEM;
+		goto err;
+	}
+	sport->rx_bytes = 0;
+
+	/* Prepare for TX : */
+	sport->dma_chan_tx = dma_request_slave_channel(dev, "tx");
+	if (!sport->dma_chan_tx) {
+		dev_err(dev, "cannot get the TX DMA channel!\n");
+		ret = -EINVAL;
+		goto err;
+	}
+
+	slave_config.direction = DMA_MEM_TO_DEV;
+	slave_config.dst_addr = sport->port.mapbase + URTX0;
+	slave_config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	slave_config.dst_maxburst = TXTL;
+	ret = dmaengine_slave_config(sport->dma_chan_tx, &slave_config);
+	if (ret) {
+		dev_err(dev, "error in TX dma configuration.");
+		goto err;
+	}
+
+	sport->dma_is_inited = 1;
+
+	return 0;
+err:
+	imx_uart_dma_exit(sport);
+	return ret;
+}
+
+static void imx_enable_dma(struct imx_port *sport)
+{
+	unsigned long temp;
+	struct tty_port *port = &sport->port.state->port;
+
+	port->low_latency = 1;
+	INIT_WORK(&sport->tsk_dma_tx, dma_tx_work);
+	INIT_WORK(&sport->tsk_dma_rx, dma_rx_work);
+	init_waitqueue_head(&sport->dma_wait);
+
+	/* set UCR1 */
+	temp = readl(sport->port.membase + UCR1);
+	temp |= UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN |
+		/* wait for 32 idle frames for IDDMA interrupt */
+		UCR1_ICD_REG(3);
+	writel(temp, sport->port.membase + UCR1);
+
+	/* set UCR4 */
+	temp = readl(sport->port.membase + UCR4);
+	temp |= UCR4_IDDMAEN;
+	writel(temp, sport->port.membase + UCR4);
+
+	sport->dma_is_enabled = 1;
+}
+
+static void imx_disable_dma(struct imx_port *sport)
+{
+	unsigned long temp;
+	struct tty_port *port = &sport->port.state->port;
+
+	/* clear UCR1 */
+	temp = readl(sport->port.membase + UCR1);
+	temp &= ~(UCR1_RDMAEN | UCR1_TDMAEN | UCR1_ATDMAEN);
+	writel(temp, sport->port.membase + UCR1);
+
+	/* clear UCR2 */
+	temp = readl(sport->port.membase + UCR2);
+	temp &= ~(UCR2_CTSC | UCR2_CTS);
+	writel(temp, sport->port.membase + UCR2);
+
+	/* clear UCR4 */
+	temp = readl(sport->port.membase + UCR4);
+	temp &= ~UCR4_IDDMAEN;
+	writel(temp, sport->port.membase + UCR4);
+
+	sport->dma_is_enabled = 0;
+	port->low_latency = 0;
+}
+
 /* half the RX buffer size */
 #define CTSTL 16
 
@@ -870,6 +1249,15 @@ static void imx_shutdown(struct uart_port *port)
 	unsigned long temp;
 	unsigned long flags;
 
+	if (sport->dma_is_enabled) {
+		/* We have to wait for the DMA to finish. */
+		wait_event(sport->dma_wait,
+			!sport->dma_is_rxing && !sport->dma_is_txing);
+		imx_stop_rx(port);
+		imx_disable_dma(sport);
+		imx_uart_dma_exit(sport);
+	}
+
 	spin_lock_irqsave(&sport->port.lock, flags);
 	temp = readl(sport->port.membase + UCR2);
 	temp &= ~(UCR2_TXEN);
@@ -956,6 +1344,11 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 		if (sport->have_rtscts) {
 			ucr2 &= ~UCR2_IRTS;
 			ucr2 |= UCR2_CTSC;
+
+			/* Can we enable the DMA support? */
+			if (is_imx6q_uart(sport) && !uart_console(port)
+				&& !sport->dma_is_inited)
+				imx_uart_dma_init(sport);
 		} else {
 			termios->c_cflag &= ~CRTSCTS;
 		}
@@ -1069,6 +1462,8 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 	if (UART_ENABLE_MS(&sport->port, termios->c_cflag))
 		imx_enable_ms(&sport->port);
 
+	if (sport->dma_is_inited && !sport->dma_is_enabled)
+		imx_enable_dma(sport);
 	spin_unlock_irqrestore(&sport->port.lock, flags);
 }
 
-- 
1.7.1




From jgq516 at gmail.com  Mon Jul  8 05:51:59 2013
From: jgq516 at gmail.com (jgq516 at gmail.com)
Date: Mon, 08 Jul 2013 17:51:59 +0800
Subject: v3.10 - big endian core support
In-Reply-To: <20130708084911.GA22057@mudshark.cambridge.arm.com>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com>
 <20130708084911.GA22057@mudshark.cambridge.arm.com>
Message-ID: <51DA8BBF.7080104@gmail.com>

On 07/08/2013 04:49 PM, Will Deacon wrote:
> On Mon, Jul 08, 2013 at 06:39:21AM +0100, jgq516 at gmail.com wrote:
>> On 07/01/2013 07:03 PM, Ben Dooks wrote:
>>> The latest big-endian changes, now on:
>>>
>>> 	git://git.baserock.org/delta/linux baserock/311/be/core
>>>
>>> This has a minor fix from the last version where a rebase missed a change
>>> in the smp_scu code.
>>>
>> Hello Ben,
>>
>> Thanks for you patches at first. I can boot BE kernel on vexpress a15 tc2
>> board with LPAE disabled.
>>
>> However if enable LPAE, kernel seems hang after turn on mmu on since
>> printascii can't output any character in __mmap_switched.
>> Did you happen to try BE kernel with LPAE enabled before? or am I missed
>> something?
> Well, I hacked head.S recently to fix booting with LPAE and BE8, but I was
> unable to test early console since I was using virtio-console. It could be
> that the page table entries mapping the uart aren't quite right, but no
> obvious issues jump out from looking at the code.
Good to know you tried LPAE and BE8, and I can test the hack code if you 
wish.
> How much visibility do you have on your platform?
The printascii can output before "b __enable_mmu", after move it to
__mmap_switched, nothing can be printed. But if disable LPAE, printascii
works again in __mmap_switched.
>   Can you take a look at the page table entries and check they look ok please?
Sorry, do you mean the section of __create_page_tables? could you please 
elaborate it?

Thanks,
Xiao

> Cheers,
>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>



From ben.dooks at codethink.co.uk  Mon Jul  8 05:58:14 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 08 Jul 2013 10:58:14 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <51DA5089.5080109@gmail.com>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com>
Message-ID: <51DA8D36.7010006@codethink.co.uk>

On 08/07/13 06:39, jgq516 at gmail.com wrote:
> On 07/01/2013 07:03 PM, Ben Dooks wrote:
>> The latest big-endian changes, now on:
>>
>> git://git.baserock.org/delta/linux baserock/311/be/core
>>
>> This has a minor fix from the last version where a rebase missed a change
>> in the smp_scu code.
>>
> Hello Ben,
>
> Thanks for you patches at first. I can boot BE kernel on vexpress a15 tc2
> board with LPAE disabled.
>
> However if enable LPAE, kernel seems hang after turn on mmu on since
> printascii can't output any character in __mmap_switched.
> Did you happen to try BE kernel with LPAE enabled before? or am I missed
> something?

I thought I did try the vexpress with LPAE, however it may have been
with a previous revision of the patches.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From Dave.Martin at arm.com  Mon Jul  8 05:59:40 2013
From: Dave.Martin at arm.com (Dave P Martin)
Date: Mon, 8 Jul 2013 10:59:40 +0100
Subject: scripts/kallsyms: Avoid ARM veneer symbols
In-Reply-To: <201307060134.56933.arnd@arndb.de>
References: <2983817.Xe2505Drlj@wuerfel> <201307051842.44721.arnd@arndb.de>
 <20130705172659.GJ2932@localhost.localdomain>
 <201307060134.56933.arnd@arndb.de>
Message-ID: <20130708095940.GB2906@localhost.localdomain>

On Sat, Jul 06, 2013 at 01:34:56AM +0200, Arnd Bergmann wrote:
> On Friday 05 July 2013, Dave P Martin wrote:
> > On Fri, Jul 05, 2013 at 05:42:44PM +0100, Arnd Bergmann wrote:
> > > On Friday 05 July 2013, Dave P Martin wrote:
> > > > On Wed, Jul 03, 2013 at 06:03:04PM +0200, Arnd Bergmann wrote:
> > 
> > I think there are a small number of patterns to check for.
> > 
> > __*_veneer, __*_from_arm and __*_from_thumb should cover most cases.
> 
> Ok.
> 
> > > * There are actually symbols without a name on ARM, which screws up the
> > >   kallsyms.c parser. These also seem to be veneers, but attached to some
> > >   random function:
> > 
> > Hmmm, I don't what those are.  By default, we should probably ignore those
> > too.  Maybe they have something to do with link-time relocation processing.
> 
> Definitely link-time. It only shows up after the final link, and only
> with ld.bfd not with ld.gold as I found out now.
> 
> > > $ nm obj-tmp/.tmp_vmlinux1 | head
> > > c09e8db1 t 
> > > c09e8db5 t 
> > > c09e8db9 t    # <==========
> > > c09e8dbd t 
> > > c0abfc29 t 
> > > c0008000 t $a
> > > c0f7b640 t $a
> > > 
> > > $ objdump -Dr obj-tmp/.tmp_vmlinux1 | grep -C 30 c09e8db.
> > > c0851fcc <wlc_phy_edcrs_lock>:
> > > c0851fcc:       b538            push    {r3, r4, r5, lr}
> > > c0851fce:       b500            push    {lr}
> > > c0851fd0:       f7bb d8dc       bl      c000d18c <__gnu_mcount_nc>
> > > c0851fd4:       f240 456b       movw    r5, #1131       ; 0x46b
> > > c0851fd8:       4604            mov     r4, r0
> > > c0851fda:       f880 14d5       strb.w  r1, [r0, #1237] ; 0x4d5
> > > c0851fde:       462a            mov     r2, r5
> > > c0851fe0:       f44f 710b       mov.w   r1, #556        ; 0x22c
> > > c0851fe4:       f7ff fe6d       bl      c0851cc2 <write_phy_reg>
> > > c0851fe8:       4620            mov     r0, r4
> > > c0851fea:       462a            mov     r2, r5
> > > c0851fec:       f240 212d       movw    r1, #557        ; 0x22d
> > > c0851ff0:       f7ff fe67       bl      c0851cc2 <write_phy_reg>
> > > c0851ff4:       4620            mov     r0, r4
> > > c0851ff6:       f240 212e       movw    r1, #558        ; 0x22e
> > > c0851ffa:       f44f 7270       mov.w   r2, #960        ; 0x3c0
> > > c0851ffe:       f196 fedb       bl      c09e8db8 <tpci200_free_irq+0x78>  # <===========
> > > c0852002:       4620            mov     r0, r4
> > > c0852004:       f240 212f       movw    r1, #559        ; 0x22f
> > > c0852008:       f44f 7270       mov.w   r2, #960        ; 0x3c0
> > > c085200c:       e8bd 4038       ldmia.w sp!, {r3, r4, r5, lr}
> > > c0852010:       f7ff be57       b.w     c0851cc2 <write_phy_reg>
> > > 
> > > 
> > > ... # in tpci200_free_irq:
> > > c09e8d9e:       e003            b.n     c09e8da8 <tpci200_free_irq+0x68>
> > > c09e8da0:       f06f 0415       mvn.w   r4, #21
> > > c09e8da4:       e000            b.n     c09e8da8 <tpci200_free_irq+0x68>
> > > c09e8da6:       4c01            ldr     r4, [pc, #4]    ; (c09e8dac <tpci200_free_irq+0x6c>)
> > > c09e8da8:       4620            mov     r0, r4
> > > c09e8daa:       bdf8            pop     {r3, r4, r5, r6, r7, pc}
> > > c09e8dac:       fffffe00                        ; <UNDEFINED> instruction: 0xfffffe00
> > > c09e8db0:       f4cf b814       b.w     c06b7ddc <bna_enet_sm_chld_stop_wait_entry>
> > > c09e8db4:       f53e bed8       b.w     c0727b68 <gem_do_stop>
> > > c09e8db8:       f668 bf83       b.w     c0851cc2 <write_phy_reg>           # <==========
> > > c09e8dbc:       d101            bne.n   c09e8dc2 <tpci200_free_irq+0x82>
> > > c09e8dbe:       f435 b920       b.w     c061e002 <twl_reset_sequence+0x34c>
> > > 
> > > It makes no sense to me at all that a function in one driver can just call
> > > write_phy_reg a couple of times, but need a veneer in the middle, and put
> > > that veneer in a totally unrelated function in another driver!
> > 
> > I think that if ld inserts a veneer for a function anywhere, branches
> > from any object in the link to that target symbol can reuse the same
> > veneer as a trampoline, effectively appearing to branch through an
> > unrelated location to reach the destination.
> 
> That part makes sense, but it doesn't explain why ld would do that just
> for the third out of four identical function calls in the example above.
> 
> > ld inserts veneers between individual input sections, but I don't
> > think they have to go next to the same section the branch originates
> > from.  In the above code, it looks like that series of unconditional
> > branches after the end of tpci200_free_irq might be a common veneer pool
> > for many different destinations.
> 
> Yes, exactly. In this build I had six of these nameless symbols, and five
> of them were in this one function.
> 
> > LTO may also make the expected compilation unit boundaries disappear
> > completely.  Anything could end up almost anywhere in that case.
> > Files could get intermingled, inlined and generally spread all over the
> > place.
> 
> I'm not sure we actually want to enable that in the kernel ;-)
> 
> In particular in combination with kallsyms, it would make the kallsyms
> information rather useless when we can no longer infer a function name
> from an address.

Well, indeed.  But that's a separate discussion -- I don't think we want
to block it needlessly just due to an obscure feature of the ARM toolchain.

Ignoring veneers and nameless symbols in kallsyms sounds like a reasonable
approach for now, even if it's not a perfect.

> > Even so, veneers shouldn't be needed in the common case where we're not
> > jumping across .rodata.
> > 
> > > 
> > > If this is a binutils bug or gcc bug, we should probably just fix it, but it
> > > might be easier to work around it by changing kallsyms.c some more.
> > 
> > I haven't found a trivial way to reproduce those nameless symbols.
> > I don't know whether they're a bug or not...
> > 
> > Making kallsyms robust against this might be a good idea anyway.
> 
> Maybe we can find a binutils expert next week at Linaro connect to take a
> look at the data. I can prepare a test case.

Sure, that could be worth a try.

Cheers
---Dave


From jgq516 at gmail.com  Mon Jul  8 06:03:27 2013
From: jgq516 at gmail.com (jgq516 at gmail.com)
Date: Mon, 08 Jul 2013 18:03:27 +0800
Subject: v3.10 - big endian core support
In-Reply-To: <51DA8D36.7010006@codethink.co.uk>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com> <51DA8D36.7010006@codethink.co.uk>
Message-ID: <51DA8E6F.60507@gmail.com>

On 07/08/2013 05:58 PM, Ben Dooks wrote:
> On 08/07/13 06:39, jgq516 at gmail.com wrote:
>> On 07/01/2013 07:03 PM, Ben Dooks wrote:
>>> The latest big-endian changes, now on:
>>>
>>> git://git.baserock.org/delta/linux baserock/311/be/core
>>>
>>> This has a minor fix from the last version where a rebase missed a 
>>> change
>>> in the smp_scu code.
>>>
>> Hello Ben,
>>
>> Thanks for you patches at first. I can boot BE kernel on vexpress a15 
>> tc2
>> board with LPAE disabled.
>>
>> However if enable LPAE, kernel seems hang after turn on mmu on since
>> printascii can't output any character in __mmap_switched.
>> Did you happen to try BE kernel with LPAE enabled before? or am I missed
>> something?
>
> I thought I did try the vexpress with LPAE, however it may have been
> with a previous revision of the patches.
>
Which revision? does it also existed in your tree? I want to give it a 
try :)

Thanks,
Xiao


From tom.leiming at gmail.com  Mon Jul  8 06:03:57 2013
From: tom.leiming at gmail.com (Ming Lei)
Date: Mon, 8 Jul 2013 18:03:57 +0800
Subject: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is
 64-bits
In-Reply-To: <20130706091511.GN24642@n2100.arm.linux.org.uk>
References: <1367008266-1431-1-git-send-email-lauraa@codeaurora.org>
 <517AF270.8040106@gmail.com>
 <CACVXFVPfkqP+UyoGd-+QFRzndSam_DtU=utrBPYCPjQCGQ_F6g@mail.gmail.com>
 <51D71F81.5090503@codeaurora.org>
 <CACVXFVNT3j5o9a+N9FDA07Si+cngqAZkcqh6YYOf3rHsMvRgRg@mail.gmail.com>
 <20130706091511.GN24642@n2100.arm.linux.org.uk>
Message-ID: <CACVXFVNF0ZukAw5d1Uv_d0oE6arci7AyVtVEPRb0=hx+0dX6pA@mail.gmail.com>

On Sat, Jul 6, 2013 at 5:15 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Sat, Jul 06, 2013 at 10:21:05AM +0800, Ming Lei wrote:
>> But please see below words in Documentation/DMA-API.txt:
>>
>>            Further, the physical address of the memory must be within the
>>            dma_mask of the device (the dma_mask represents a bit mask of the
>>            addressable region for the device.  I.e., if the physical address of
>>            the memory anded with the dma_mask is still equal to the physical
>>            address, then the device can perform DMA to the memory).
>>
>> You may argue that the description is about dev->dma_mask, but the
>> usage should be same.
>>
>> In fact, most of devices in ARM SoC(even with LPAE enabled) doesn't
>> support 64bit DMA, so I don't see the point that the default mask is set
>> as 64bit.
>
> There's another couple of issues there:
>
> (a) Linux assumes that physical memory starts at location zero.  There
>     are various places in the kernel that assume that this holds true:
>
>         max_dma_pfn = (dma_mask >> PAGE_SHIFT) + 1
>
>     One notable place is the block layer.  I've suggested to Santosh a
>     way to fix this but I need to help him a little more with it.
>
> (b) Device DMA addresses are a *separate* address space to the physical
>     address space.  Device DMA addresses are the addresses which need to
>     be programmed into the device to perform DMA to the identified
>     location.
>
> What (b) means is that if you are ending up with a 64-bit address to be
> programmed into a 32-bit only register, there is something very very
> wrong.  What this also means is that a 32-bit DMA mask should suffice,
> because if the DMA address results in a 32-bit address _for the DMA
> device_ then we are within its capabilities.
>
> In any case, the work around is not to set the DMA mask to be 64-bit.

So how about working around the problem by setting arm_dma_limit as
(phys_addr_t)0xffffffff if CONFIG_ZONE_DMA is unset? Or other better
solutions?

Otherwise enabling LPAE may cause system boot failure because
mmc card may not work when arm_dma_limit becomes (u64)-1.

> Think about it.  What if you have 8GB of physical memory in a LPAE
> system, but your DMA controllers can only be programmed with a 32-bit
> address?
>
> Lastly, think about what I said last night about most of the ARM drivers
> being rather buggy in that they do not call either dma_set_mask() or
> dma_set_coherent_mask().
>
> So, I think we're well past the point where we need to stop assuming that
> DMA masks somehow relate to physical addresses, and that they can be used
> to indicate a range of physical addresses starting at zero and extending
> up to and including the mask value.  To call such a thing a "mask" is
> absolutely absurd.


Thanks,
-- 
Ming Lei


From linux at arm.linux.org.uk  Mon Jul  8 06:42:55 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Jul 2013 11:42:55 +0100
Subject: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is
 64-bits
In-Reply-To: <51D71F81.5090503@codeaurora.org>
References: <1367008266-1431-1-git-send-email-lauraa@codeaurora.org>
 <517AF270.8040106@gmail.com>
 <CACVXFVPfkqP+UyoGd-+QFRzndSam_DtU=utrBPYCPjQCGQ_F6g@mail.gmail.com>
 <51D71F81.5090503@codeaurora.org>
Message-ID: <20130708104254.GS24642@n2100.arm.linux.org.uk>

On Fri, Jul 05, 2013 at 12:33:21PM -0700, Laura Abbott wrote:
> On 7/3/2013 7:15 AM, Ming Lei wrote:
>> On Sat, Apr 27, 2013 at 5:32 AM, Rob Herring <robherring2 at gmail.com> wrote:
>>> On 04/26/2013 03:31 PM, Laura Abbott wrote:
>>>> Currently, of_platform_device_create_pdata always sets the
>>>> coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA,
>>>> arm_dma_limit gets set to ~0 or 0xFFFFFFFFFFFFFFFF on LPAE based
>>>> systems. Since arm_dma_limit represents the smallest dma_mask
>>>> on the system, the default of 32 bits prevents any dma_coherent
>>>> allocation from succeeding unless clients manually set the
>>>> dma mask first. Rather than make every client on an LPAE system set
>>>> the mask manually, account for the size of dma_addr_t when setting
>>>> the coherent mask.
>>>>
>>>> Signed-off-by: Laura Abbott <lauraa at codeaurora.org>
>>>> ---
>>>>   drivers/of/platform.c |    2 +-
>>>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>>>> index 0970505..5f0ba94 100644
>>>> --- a/drivers/of/platform.c
>>>> +++ b/drivers/of/platform.c
>>>> @@ -214,7 +214,7 @@ struct platform_device *of_platform_device_create_pdata(
>>>>   #if defined(CONFIG_MICROBLAZE)
>>>>        dev->archdata.dma_mask = 0xffffffffUL;
>>>>   #endif
>>>> -     dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>>>> +     dev->dev.coherent_dma_mask = DMA_BIT_MASK(sizeof(dma_addr_t) * 8);
>>>
>>> This is going to change the mask from 32 to 64 bits on 64-bit powerpc
>>> and others possibly. Maybe it doesn't matter. I think it doesn't, but
>>> I'm not sure enough to apply for 3.10. So I'll queue it for 3.11.
>>
>> Without the patch, LPAE enabled board may not boot at all, but looks
>> it still isn't in -next tree.
>>
>> But I am wondering if it is a correct approach, because enabling LPAE
>> doesn't mean the I/O devices can support DMA to/from 64bit address, and
>> it is very probably devices can't do it at all.
>>
>
> The problem is the way the arm_dma_limit is set up, all dma allocations  
> are currently broken regardless of if the actual device supports 64-bit  
> addresses or not.

Please explain this statement.

> I previously asked about the arm_dma_limit and was told that the current  
> behavior is the correct approach (see  
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-April/032729.html 
> and  
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-April/032690.html) 
>
> The point here is to set the mask to something reasonable such that  
> allocations can succeed by default. If devices can't use part of the  
> memory space they can adjust the limit accordingly.

The point is arm_dma_limit is that it sets the limit of the memory you
get from the page allocators when you ask for a GFP_DMA allocation.

In the case of no GFP_DMA zone, all memory is available for allocations.
Hence, arm_dma_limit is set to the absolute maximum physical memory
address which an allocator could return.

In the case of a 32-bit only system, this is 32-bits.  In the case of a
LPAE system, it is 64-bit.  (This follows because arm_dma_limit is
phys_addr_t, and the size of this follows the bit size of the system.)

The only questionable case is where we have a LPAE system with a GFP_DMA
zone and arm_dma_limit is set to 0xfffffffff - this limit is probably
too low.

Now the reason for the arm_dma_limit is very simple: if the streaming
APIs are passed a buffer outside of the DMA mask, we must reallocate
that memory.  We must have a way to get memory which is within the DMA
mask.  That's what passing GFP_DMA does.  If you have no GFP_DMA zone,
then any memory could be returned.  In the case of a LPAE system with
memory both above and below the 32-bit address range, and you try to
allocate a buffer which happens to be above the 32-bit boundary, what
do you do?  Do you just retry the allocation and hope for the best?
What if that allocation also came out above the 32-bit boundary?  Do
you continue gobbling up system memory until you get a page which you
can DMA do and then free all those buffers you unsuccesfully obtained?

We have a massive problem with DMA masks in the Linux kernel, because
of the x86-ism of assuming that physical memory always starts at
address zero.  This assumption simply is not true on ARM, even more so
with LPAE, which is why people are starting to see a problem.

Consider this case: you have an existing 32-bit DMA controller.  This
controller sets a 32-bit DMA mask, because that's all it is capable of
addressing.  It gets used on 32-bit systems, and it works fine.

It gets put onto a LPAE system where memory starts at the 4GB boundary.
The DMA controller can address the first 4GB of memory because that's
how it's wired up.  The DMA controller still has a 32-bit DMA mask
because as far as the DMA controller is concerned, nothing has changed.
But now things fail because the kernel assumes that a DMA mask is
something to do with a physical address.

The solution to this is to fix the DMA masks and such like.  The problem
is getting the traction throughout the architectures, drivers, subsystem
maintainers etc to accept a change - and working out a way to do the
change without causing a lot of breakage.


From linux at arm.linux.org.uk  Mon Jul  8 06:44:36 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Jul 2013 11:44:36 +0100
Subject: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is
 64-bits
In-Reply-To: <CACVXFVNF0ZukAw5d1Uv_d0oE6arci7AyVtVEPRb0=hx+0dX6pA@mail.gmail.com>
References: <1367008266-1431-1-git-send-email-lauraa@codeaurora.org>
 <517AF270.8040106@gmail.com>
 <CACVXFVPfkqP+UyoGd-+QFRzndSam_DtU=utrBPYCPjQCGQ_F6g@mail.gmail.com>
 <51D71F81.5090503@codeaurora.org>
 <CACVXFVNT3j5o9a+N9FDA07Si+cngqAZkcqh6YYOf3rHsMvRgRg@mail.gmail.com>
 <20130706091511.GN24642@n2100.arm.linux.org.uk>
 <CACVXFVNF0ZukAw5d1Uv_d0oE6arci7AyVtVEPRb0=hx+0dX6pA@mail.gmail.com>
Message-ID: <20130708104436.GT24642@n2100.arm.linux.org.uk>

On Mon, Jul 08, 2013 at 06:03:57PM +0800, Ming Lei wrote:
> On Sat, Jul 6, 2013 at 5:15 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Sat, Jul 06, 2013 at 10:21:05AM +0800, Ming Lei wrote:
> >> But please see below words in Documentation/DMA-API.txt:
> >>
> >>            Further, the physical address of the memory must be within the
> >>            dma_mask of the device (the dma_mask represents a bit mask of the
> >>            addressable region for the device.  I.e., if the physical address of
> >>            the memory anded with the dma_mask is still equal to the physical
> >>            address, then the device can perform DMA to the memory).
> >>
> >> You may argue that the description is about dev->dma_mask, but the
> >> usage should be same.
> >>
> >> In fact, most of devices in ARM SoC(even with LPAE enabled) doesn't
> >> support 64bit DMA, so I don't see the point that the default mask is set
> >> as 64bit.
> >
> > There's another couple of issues there:
> >
> > (a) Linux assumes that physical memory starts at location zero.  There
> >     are various places in the kernel that assume that this holds true:
> >
> >         max_dma_pfn = (dma_mask >> PAGE_SHIFT) + 1
> >
> >     One notable place is the block layer.  I've suggested to Santosh a
> >     way to fix this but I need to help him a little more with it.
> >
> > (b) Device DMA addresses are a *separate* address space to the physical
> >     address space.  Device DMA addresses are the addresses which need to
> >     be programmed into the device to perform DMA to the identified
> >     location.
> >
> > What (b) means is that if you are ending up with a 64-bit address to be
> > programmed into a 32-bit only register, there is something very very
> > wrong.  What this also means is that a 32-bit DMA mask should suffice,
> > because if the DMA address results in a 32-bit address _for the DMA
> > device_ then we are within its capabilities.
> >
> > In any case, the work around is not to set the DMA mask to be 64-bit.
> 
> So how about working around the problem by setting arm_dma_limit as
> (phys_addr_t)0xffffffff if CONFIG_ZONE_DMA is unset? Or other better
> solutions?
> 
> Otherwise enabling LPAE may cause system boot failure because
> mmc card may not work when arm_dma_limit becomes (u64)-1.

Well, working around it by bodging it means that the bodges will stay
and the problem will become even worse later, and we won't have the
weight of people saying it doesn't work to use as leverage to persuade
people that DMA masks need to change.  Sorry.


From g.liakhovetski at gmx.de  Mon Jul  8 06:49:47 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Mon, 8 Jul 2013 12:49:47 +0200 (CEST)
Subject: [PATCH/RFC 2/3] ethernet: add a PHY reset GPIO DT binding to
 sh_eth
In-Reply-To: <20130125182137.GB7393@obsidianresearch.com>
References: <1359043653-11374-1-git-send-email-g.liakhovetski@gmx.de>
 <1359043653-11374-3-git-send-email-g.liakhovetski@gmx.de>
 <7921225.sfO3PIeLVS@avalon>
 <Pine.LNX.4.64.1301251127460.17518@axis700.grange>
 <20130125182137.GB7393@obsidianresearch.com>
Message-ID: <Pine.LNX.4.64.1307081247530.19819@axis700.grange>

Hi Jason

Sorry for resuming an old thread, but I'd like to get this solved 
eventually.

On Fri, 25 Jan 2013, Jason Gunthorpe wrote:

> On Fri, Jan 25, 2013 at 11:34:55AM +0100, Guennadi Liakhovetski wrote:
> 
> > > Is there no need to reset the phy at runtime ?
> > 
> > No idea, I'm not developing the driver, I'm just porting one specific 
> > feature from one API to another with no functional changes (apart from 
> > postponing setting the GPIO).
> 
> Generally Linux relies on resetting the phy via the inband MDIO method,
> which is what Linux does. It is pretty much never required to reset
> via the hard pin - but you do need to generate a robust reset edge on
> the reset pin once after power up.

This all sounds good. So, is there a preferred way to do that? Where in 
the ethernet framework would you propose to hook up such a reset edge 
generation?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From will.deacon at arm.com  Mon Jul  8 07:02:02 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 8 Jul 2013 12:02:02 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <51DA8BBF.7080104@gmail.com>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com>
 <20130708084911.GA22057@mudshark.cambridge.arm.com>
 <51DA8BBF.7080104@gmail.com>
Message-ID: <20130708110202.GD22057@mudshark.cambridge.arm.com>

On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
> On 07/08/2013 04:49 PM, Will Deacon wrote:
> > Well, I hacked head.S recently to fix booting with LPAE and BE8, but I was
> > unable to test early console since I was using virtio-console. It could be
> > that the page table entries mapping the uart aren't quite right, but no
> > obvious issues jump out from looking at the code.
> Good to know you tried LPAE and BE8, and I can test the hack code if you 
> wish.

The hack got merged, since it fixed booting (which I managed to test), I
just couldn't test earlyprintk. Maybe I can try and get something up and
running on the model.

> > How much visibility do you have on your platform?
> The printascii can output before "b __enable_mmu", after move it to
> __mmap_switched, nothing can be printed. But if disable LPAE, printascii
> works again in __mmap_switched.

Ok, so the page tables are broken. The code is there to swap the two words,
but perhaps something ends up being off-by-4 or the like. I'll try and take
a look.

Will


From ben.dooks at codethink.co.uk  Mon Jul  8 07:10:00 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 08 Jul 2013 12:10:00 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <51DA8E6F.60507@gmail.com>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com> <51DA8D36.7010006@codethink.co.uk>
 <51DA8E6F.60507@gmail.com>
Message-ID: <51DA9E08.2030707@codethink.co.uk>

On 08/07/13 11:03, jgq516 at gmail.com wrote:
> On 07/08/2013 05:58 PM, Ben Dooks wrote:
>> On 08/07/13 06:39, jgq516 at gmail.com wrote:
>>> On 07/01/2013 07:03 PM, Ben Dooks wrote:
>>>> The latest big-endian changes, now on:
>>>>
>>>> git://git.baserock.org/delta/linux baserock/311/be/core
>>>>
>>>> This has a minor fix from the last version where a rebase missed a
>>>> change
>>>> in the smp_scu code.
>>>>
>>> Hello Ben,
>>>
>>> Thanks for you patches at first. I can boot BE kernel on vexpress a15
>>> tc2
>>> board with LPAE disabled.
>>>
>>> However if enable LPAE, kernel seems hang after turn on mmu on since
>>> printascii can't output any character in __mmap_switched.
>>> Did you happen to try BE kernel with LPAE enabled before? or am I missed
>>> something?
>>
>> I thought I did try the vexpress with LPAE, however it may have been
>> with a previous revision of the patches.
>>
> Which revision? does it also existed in your tree? I want to give it a
> try :)

My notes show I did a custom 3.5 backport for a customer's kernel
so was not testing with the latest. I think I tried 3.9 with LPAE
but cannot find confirmation in my notes that this actually happened.


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From kishon at ti.com  Mon Jul  8 07:14:14 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 8 Jul 2013 16:44:14 +0530
Subject: [PATCH v2 1/4] arm: omap: Add phy binding info for musb in plat data
In-Reply-To: <1373282057-20181-1-git-send-email-kishon@ti.com>
References: <1373282057-20181-1-git-send-email-kishon@ti.com>
Message-ID: <1373282057-20181-2-git-send-email-kishon@ti.com>

In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy label) should be added in the platform
data of the controller.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/usb-musb.c |    3 +++
 include/linux/usb/musb.h       |    3 +++
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 8c4de27..20b42de 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,6 +85,9 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
 	musb_plat.mode = board_data->mode;
 	musb_plat.extvbus = board_data->extvbus;
 
+	if (cpu_is_omap34xx())
+		musb_plat.phy_name = "twl4030";
+
 	if (soc_is_am35xx()) {
 		oh_name = "am35x_otg_hs";
 		name = "musb-am35x";
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..c05d46d 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
 	/* for clk_get() */
 	const char	*clock;
 
+	/* phy device label */
+	const char	*phy_name;
+
 	/* (HOST or OTG) switch VBUS on/off */
 	int		(*set_vbus)(struct device *dev, int is_on);
 
-- 
1.7.10.4



From kishon at ti.com  Mon Jul  8 07:14:13 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 8 Jul 2013 16:44:13 +0530
Subject: [PATCH v2 0/4] usb: musb: fix USB enumeration issue in OMAP3 platform
Message-ID: <1373282057-20181-1-git-send-email-kishon@ti.com>

This series fixes the USB enumeration issue caused because of the controller
not able to get a reference to the PHY because of incorrect binding in the
board file.

In the case of non-dt boot, the platform specific initialization file
(board file) will do usb_bind_phy that binds the usb controller with the
PHY using device names. After the device names are created using 
PLATFORM_DEVID_AUTO, our original method of binding by device names doesn't
work reliably (since the device name changes). Hence the usb controller
is made to use labels for getting the PHY.

Here the PHY name is added in the plat data of USB controller device which
should be used by the controller driver to get the PHY.
Two new APIs usb_get_phy_by_name and devm_usb_get_phy_by_name are added to
be used by the controller to get the PHY by name.

Changes from v1:
*) Rebased to the latest mainline kernel

Changes from RFC
*) Changed the signature of usb_get_phy_by_name() not to use struct device *

Kishon Vijay Abraham I (4):
  arm: omap: Add phy binding info for musb in plat data
  usb: phy: add a new API to get PHY ref by label
  usb: musb: omap: use the new API to get PHY reference by label
  arm: omap: remove using usb_bind_phy for binding musb and phy

 arch/arm/mach-omap2/board-2430sdp.c          |    1 -
 arch/arm/mach-omap2/board-3430sdp.c          |    1 -
 arch/arm/mach-omap2/board-cm-t35.c           |    1 -
 arch/arm/mach-omap2/board-devkit8000.c       |    1 -
 arch/arm/mach-omap2/board-igep0020.c         |    1 -
 arch/arm/mach-omap2/board-ldp.c              |    1 -
 arch/arm/mach-omap2/board-omap3beagle.c      |    1 -
 arch/arm/mach-omap2/board-omap3evm.c         |    1 -
 arch/arm/mach-omap2/board-omap3logic.c       |    1 -
 arch/arm/mach-omap2/board-omap3pandora.c     |    1 -
 arch/arm/mach-omap2/board-omap3stalker.c     |    1 -
 arch/arm/mach-omap2/board-omap3touchbook.c   |    1 -
 arch/arm/mach-omap2/board-overo.c            |    1 -
 arch/arm/mach-omap2/board-rm680.c            |    1 -
 arch/arm/mach-omap2/board-rx51.c             |    1 -
 arch/arm/mach-omap2/board-zoom-peripherals.c |    1 -
 arch/arm/mach-omap2/usb-musb.c               |    3 +
 drivers/usb/musb/musb_core.c                 |    1 +
 drivers/usb/musb/musb_core.h                 |    1 +
 drivers/usb/musb/omap2430.c                  |    2 +-
 drivers/usb/phy/phy.c                        |   77 ++++++++++++++++++++++++++
 include/linux/usb/musb.h                     |    3 +
 include/linux/usb/phy.h                      |   14 +++++
 23 files changed, 100 insertions(+), 17 deletions(-)

-- 
1.7.10.4



From kishon at ti.com  Mon Jul  8 07:14:16 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 8 Jul 2013 16:44:16 +0530
Subject: [PATCH v2 3/4] usb: musb: omap: use the new API to get PHY reference
 by label
In-Reply-To: <1373282057-20181-1-git-send-email-kishon@ti.com>
References: <1373282057-20181-1-git-send-email-kishon@ti.com>
Message-ID: <1373282057-20181-4-git-send-email-kishon@ti.com>

After the devices are created using PLATFORM_DEVID_AUTO,
devm_usb_get_phy_dev and usb_get_phy_dev can't be used reliably
as it relies on the device_names passed in usb_bind_phy. So used the
new API devm_usb_get_phy_by_name to get the PHY reference.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 drivers/usb/musb/musb_core.c |    1 +
 drivers/usb/musb/musb_core.h |    1 +
 drivers/usb/musb/omap2430.c  |    2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 29a24ce..5eb6cd7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1814,6 +1814,7 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
 	musb->min_power = plat->min_power;
 	musb->ops = plat->platform_ops;
 	musb->port_mode = plat->mode;
+	musb->phy_name = plat->phy_name;
 
 	/* The musb_platform_init() call:
 	 *   - adjusts musb->mregs
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7d341c3..1f0863b 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -424,6 +424,7 @@ struct musb {
 	unsigned                double_buffer_not_ok:1;
 
 	struct musb_hdrc_config	*config;
+	const char		*phy_name;
 
 #ifdef MUSB_CONFIG_PROC_FS
 	struct proc_dir_entry *proc_entry;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 6708a3b..5b6113a 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -352,7 +352,7 @@ static int omap2430_musb_init(struct musb *musb)
 		musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
 		    "usb-phy", 0);
 	else
-		musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+		musb->xceiv = devm_usb_get_phy_by_name(dev, musb->phy_name);
 
 	if (IS_ERR(musb->xceiv)) {
 		status = PTR_ERR(musb->xceiv);
-- 
1.7.10.4



From kishon at ti.com  Mon Jul  8 07:14:15 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 8 Jul 2013 16:44:15 +0530
Subject: [PATCH v2 2/4] usb: phy: add a new API to get PHY ref by label
In-Reply-To: <1373282057-20181-1-git-send-email-kishon@ti.com>
References: <1373282057-20181-1-git-send-email-kishon@ti.com>
Message-ID: <1373282057-20181-3-git-send-email-kishon@ti.com>

After the devices are created using PLATFORM_DEVID_AUTO,
devm_usb_get_phy_dev and usb_get_phy_dev can't be used reliably
as it relies on the device_names passed in usb_bind_phy. So
added a new API to get the PHY reference by PHY label (PHY label
should be filled which creating the PHY).

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 drivers/usb/phy/phy.c   |   77 +++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/usb/phy.h |   14 +++++++++
 2 files changed, 91 insertions(+)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index a9984c7..92bba2f 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -55,6 +55,21 @@ static struct usb_phy *__usb_find_phy_dev(struct device *dev,
 	return ERR_PTR(-ENODEV);
 }
 
+static struct usb_phy *__usb_find_phy_by_name(struct list_head *list,
+	const char *name)
+{
+	struct usb_phy	*phy = NULL;
+
+	list_for_each_entry(phy, list, head) {
+		if (strcmp(name, phy->label))
+			continue;
+
+		return phy;
+	}
+
+	return ERR_PTR(-ENODEV);
+}
+
 static struct usb_phy *__of_usb_find_phy(struct device_node *node)
 {
 	struct usb_phy  *phy;
@@ -272,6 +287,68 @@ struct usb_phy *devm_usb_get_phy_dev(struct device *dev, u8 index)
 EXPORT_SYMBOL_GPL(devm_usb_get_phy_dev);
 
 /**
+ * usb_get_phy_by_name - find the USB PHY using device ptr and phy label
+ * @name - the name of the phy
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy.  The caller is responsible for
+ * calling usb_put_phy() to release that count.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *usb_get_phy_by_name(const char *name)
+{
+	struct usb_phy	*phy = NULL;
+	unsigned long	flags;
+
+	spin_lock_irqsave(&phy_lock, flags);
+
+	phy = __usb_find_phy_by_name(&phy_list, name);
+	if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {
+		pr_err("unable to find transceiver\n");
+		goto err0;
+	}
+
+	get_device(phy->dev);
+
+err0:
+	spin_unlock_irqrestore(&phy_lock, flags);
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(usb_get_phy_by_name);
+
+/**
+ * devm_usb_get_phy_by_name - find the USB PHY using device ptr and phy label
+ * @dev - device that requests this phy
+ * @name - the label of the phy
+ *
+ * Gets the phy using usb_get_phy_by_name(), and associates a device with it
+ * using devres. On driver detach, release function is invoked on the devres
+ * data, then, devres data is freed.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *devm_usb_get_phy_by_name(struct device *dev, const char *name)
+{
+	struct usb_phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return NULL;
+
+	phy = usb_get_phy_by_name(name);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else
+		devres_free(ptr);
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_usb_get_phy_by_name);
+
+/**
  * devm_usb_put_phy - release the USB PHY
  * @dev - device that wants to release this phy
  * @phy - the phy returned by devm_usb_get_phy()
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 4403680..2adb782 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -197,6 +197,9 @@ extern struct usb_phy *devm_usb_get_phy(struct device *dev,
 	enum usb_phy_type type);
 extern struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index);
 extern struct usb_phy *devm_usb_get_phy_dev(struct device *dev, u8 index);
+extern struct usb_phy *usb_get_phy_by_name(const char *name);
+extern struct usb_phy *devm_usb_get_phy_by_name(struct device *dev,
+	const char *name);
 extern struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
 	const char *phandle, u8 index);
 extern void usb_put_phy(struct usb_phy *);
@@ -225,6 +228,17 @@ static inline struct usb_phy *devm_usb_get_phy_dev(struct device *dev, u8 index)
 	return ERR_PTR(-ENXIO);
 }
 
+static inline struct usb_phy *usb_get_phy_by_name(const char *name)
+{
+	return ERR_PTR(-ENXIO);
+}
+
+static inline struct usb_phy *devm_usb_get_phy_by_name(struct device *dev,
+	const char *name)
+{
+	return ERR_PTR(-ENXIO);
+}
+
 static inline struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
 	const char *phandle, u8 index)
 {
-- 
1.7.10.4



From kishon at ti.com  Mon Jul  8 07:14:17 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 8 Jul 2013 16:44:17 +0530
Subject: [PATCH v2 4/4] arm: omap: remove using usb_bind_phy for binding musb
 and phy
In-Reply-To: <1373282057-20181-1-git-send-email-kishon@ti.com>
References: <1373282057-20181-1-git-send-email-kishon@ti.com>
Message-ID: <1373282057-20181-5-git-send-email-kishon@ti.com>

Now that MUSB for OMAP started using devm_usb_get_phy_by_name
which does not require PHY library to already have the binding
information, removed usb_bind_phy calls that binds the MUSB controller
with the PHY from the board files.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/board-2430sdp.c          |    1 -
 arch/arm/mach-omap2/board-3430sdp.c          |    1 -
 arch/arm/mach-omap2/board-cm-t35.c           |    1 -
 arch/arm/mach-omap2/board-devkit8000.c       |    1 -
 arch/arm/mach-omap2/board-igep0020.c         |    1 -
 arch/arm/mach-omap2/board-ldp.c              |    1 -
 arch/arm/mach-omap2/board-omap3beagle.c      |    1 -
 arch/arm/mach-omap2/board-omap3evm.c         |    1 -
 arch/arm/mach-omap2/board-omap3logic.c       |    1 -
 arch/arm/mach-omap2/board-omap3pandora.c     |    1 -
 arch/arm/mach-omap2/board-omap3stalker.c     |    1 -
 arch/arm/mach-omap2/board-omap3touchbook.c   |    1 -
 arch/arm/mach-omap2/board-overo.c            |    1 -
 arch/arm/mach-omap2/board-rm680.c            |    1 -
 arch/arm/mach-omap2/board-rx51.c             |    1 -
 arch/arm/mach-omap2/board-zoom-peripherals.c |    1 -
 16 files changed, 16 deletions(-)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
index 244d8a5..30d81f2 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -233,7 +233,6 @@ static void __init omap_2430sdp_init(void)
 	omap_hsmmc_init(mmc);
 
 	omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 
 	board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index 23b004a..7f431b4 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -590,7 +590,6 @@ static void __init omap_3430sdp_init(void)
 	omap_ads7846_init(1, gpio_pendown, 310, NULL);
 	omap_serial_init();
 	omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 	board_smc91x_init();
 	board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index d4622ed..c776c66 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -691,7 +691,6 @@ static void __init cm_t3x_common_init(void)
 	cm_t35_init_display();
 	omap_twl4030_audio_init("cm-t3x", NULL);
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 	cm_t35_init_usbh();
 	cm_t35_init_camera();
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index f1d91ba..2da5fd9 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -594,7 +594,6 @@ static void __init devkit8000_init(void)
 
 	omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL);
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 	usbhs_init(&usbhs_bdata);
 	board_nand_init(devkit8000_nand_partitions,
diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index b54562d..5451c9c 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -628,7 +628,6 @@ static void __init igep_init(void)
 	omap_serial_init();
 	omap_sdrc_init(m65kxxxxam_sdrc_params,
 				  m65kxxxxam_sdrc_params);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 
 	igep_flash_init();
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 62e4f70..ff2892d 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -377,7 +377,6 @@ static void __init omap_ldp_init(void)
 	omap_ads7846_init(1, 54, 310, NULL);
 	omap_serial_init();
 	omap_sdrc_init(NULL, NULL);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 	board_nand_init(ldp_nand_partitions, ARRAY_SIZE(ldp_nand_partitions),
 			ZOOM_NAND_CS, 0, nand_default_timings);
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 04c1165..47d7dd7 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -551,7 +551,6 @@ static void __init omap3_beagle_init(void)
 	omap_sdrc_init(mt46h32m32lf6_sdrc_params,
 				  mt46h32m32lf6_sdrc_params);
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 
 	usbhs_init(&usbhs_bdata);
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 8c02626..9bfc99f 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -706,7 +706,6 @@ static void __init omap3_evm_init(void)
 		omap_mux_init_gpio(135, OMAP_PIN_OUTPUT);
 		phy_data[0].reset_gpio = 135;
 	}
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(&musb_board_data);
 
 	usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
diff --git a/arch/arm/mach-omap2/board-omap3logic.c b/arch/arm/mach-omap2/board-omap3logic.c
index bab51e6..16e4e2a 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -216,7 +216,6 @@ static void __init omap3logic_init(void)
 	board_mmc_init();
 	board_smsc911x_init();
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 
 	/* Ensure SDRC pins are mux'd for self-refresh */
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index b1547a0..f058f43 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -611,7 +611,6 @@ static void __init omap3pandora_init(void)
 	usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
 	usbhs_init(&usbhs_bdata);
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 	gpmc_nand_init(&pandora_nand_data, NULL);
 
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index d37e6b1..6f6fc92 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -394,7 +394,6 @@ static void __init omap3_stalker_init(void)
 
 	omap_serial_init();
 	omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 
 	usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c b/arch/arm/mach-omap2/board-omap3touchbook.c
index 7da48bc..bbff6de 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -367,7 +367,6 @@ static void __init omap3_touchbook_init(void)
 
 	/* Touchscreen and accelerometer */
 	omap_ads7846_init(4, OMAP3_TS_GPIO, 310, &ads7846_pdata);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 
 	usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 5748b5d..6c2bb5a 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -473,7 +473,6 @@ static void __init overo_init(void)
 				  mt46h32m32lf6_sdrc_params);
 	board_nand_init(overo_nand_partitions,
 			ARRAY_SIZE(overo_nand_partitions), NAND_CS, 0, NULL);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 
 	usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c
index 345e8c4..cadeb5c 100644
--- a/arch/arm/mach-omap2/board-rm680.c
+++ b/arch/arm/mach-omap2/board-rm680.c
@@ -135,7 +135,6 @@ static void __init rm680_init(void)
 	sdrc_params = nokia_get_sdram_timings();
 	omap_sdrc_init(sdrc_params, sdrc_params);
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 	rm680_peripherals_init();
 }
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index d2ea68e..0d16d37 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -99,7 +99,6 @@ static void __init rx51_init(void)
 	sdrc_params = nokia_get_sdram_timings();
 	omap_sdrc_init(sdrc_params, sdrc_params);
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(&musb_board_data);
 	rx51_peripherals_init();
 
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
index a90375d..d05db2d 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -353,7 +353,6 @@ void __init zoom_peripherals_init(void)
 	omap_i2c_init();
 	pwm_add_table(zoom_pwm_lookup, ARRAY_SIZE(zoom_pwm_lookup));
 	platform_add_devices(zoom_devices, ARRAY_SIZE(zoom_devices));
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 	enable_board_wakeup_source();
 	omap_serial_init();
-- 
1.7.10.4



From thomas.petazzoni at free-electrons.com  Mon Jul  8 07:23:35 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 8 Jul 2013 13:23:35 +0200
Subject: [PATCHv4 05/11] of: pci: add registry of MSI chips
In-Reply-To: <1372686136-1370-6-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-6-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130708132335.37ff4ad4@skate>

Grant, Rob,

Would it be possible to get your feeling about the below patch? Are you
ok with the idea of this msi_chip registry, based on device_node
pointer? This is the last piece of this patch set that needs an
approval in terms of general approach.

I am at Linaro Connect this week, so if you want to discuss this live,
do not hesitate to ping me.

Thanks a lot,

Thomas

On Mon,  1 Jul 2013 15:42:10 +0200, Thomas Petazzoni wrote:
> This commit adds a very basic registry of msi_chip structures, so that
> an IRQ controller driver can register an msi_chip, and a PCIe host
> controller can find it, based on a 'struct device_node'.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  drivers/of/of_pci.c    | 40 ++++++++++++++++++++++++++++++++++++++++
>  include/linux/msi.h    |  2 ++
>  include/linux/of_pci.h | 12 ++++++++++++
>  3 files changed, 54 insertions(+)
> 
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 42c687a..f516632 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -89,3 +89,43 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
> +
> +#ifdef CONFIG_PCI_MSI
> +
> +static LIST_HEAD(msi_chip_list);
> +static DEFINE_MUTEX(msi_chip_mutex);
> +
> +int of_msi_chip_add(struct msi_chip *chip)
> +{
> +	if (! of_property_read_bool(chip->of_node, "msi-controller"))
> +		return -EINVAL;
> +
> +	mutex_lock(&msi_chip_mutex);
> +	list_add(&chip->list, &msi_chip_list);
> +	mutex_unlock(&msi_chip_mutex);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_msi_chip_add);
> +
> +void of_msi_chip_remove(struct msi_chip *chip)
> +{
> +	mutex_lock(&msi_chip_mutex);
> +	list_del(&chip->list);
> +	mutex_unlock(&msi_chip_mutex);
> +}
> +EXPORT_SYMBOL_GPL(of_msi_chip_remove);
> +
> +struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node)
> +{
> +	struct msi_chip *c;
> +	list_for_each_entry(c, &msi_chip_list, list) {
> +		if (c->of_node == of_node)
> +			return c;
> +	}
> +
> +	return NULL;
> +}
> +EXPORT_SYMBOL_GPL(of_find_msi_chip_by_node);
> +
> +#endif /* CONFIG_PCI_MSI */
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index 5b357d92..9e1a44b 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -66,6 +66,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);
>  struct msi_chip {
>  	struct module *owner;
>  	struct device *dev;
> +	struct device_node *of_node;
> +	struct list_head list;
>  
>  	int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
>  			 struct msi_desc *desc);
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index 7a04826..99e4361 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -2,6 +2,7 @@
>  #define __OF_PCI_H
>  
>  #include <linux/pci.h>
> +#include <linux/msi.h>
>  
>  struct pci_dev;
>  struct of_irq;
> @@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
>  int of_pci_get_devfn(struct device_node *np);
>  int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
>  
> +#if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
> +int of_msi_chip_add(struct msi_chip *chip);
> +void of_msi_chip_remove(struct msi_chip *chip);
> +struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node);
> +#else
> +static inline int of_msi_chip_add(struct msi_chip *chip) { return -EINVAL; }
> +static inline void of_msi_chip_remove(struct msi_chip *chip) { }
> +static inline struct msi_chip *
> +of_find_msi_chip_by_node(struct device_node *of_node) { return NULL };
> +#endif
> +
>  #endif



-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From satish.patel at ti.com  Mon Jul  8 07:24:49 2013
From: satish.patel at ti.com (Patel, Satish)
Date: Mon, 8 Jul 2013 11:24:49 +0000
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <20130704101216.GD4830@arwen.pp.htv.fi>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
 <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com>
 <51D54694.20203@ti.com> <20130704101216.GD4830@arwen.pp.htv.fi>
Message-ID: <780E789C2E067A4BB8F69D0BB9EC4F253E9764D5@DBDE04.ent.ti.com>

Hi,


> -----Original Message-----
> From: Balbi, Felipe
> Sent: Thursday, July 04, 2013 3:42 PM
> To: ABRAHAM, KISHON VIJAY
> Cc: Patel, Satish; Balbi, Felipe; grant.likely at linaro.org;
> tony at atomide.com; arnd at arndb.de; swarren at nvidia.com;
> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> foundation.org; rob.herring at calxeda.com; rob at landley.net;
> linux at arm.linux.org.uk; benoit.cousson at linaro.org; mchehab at redhat.com;
> cesarb at cesarb.net; davem at davemloft.net; Nayak, Rajendra;
> shawn.guo at linaro.org; Shilimkar, Santosh; devicetree-
> discuss at lists.ozlabs.org; linux-doc at vger.kernel.org; Nori, Sekhar;
> Krishnamoorthy, Balaji T; Cherian, George; Mankad, Maulik Ojas
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> On Thu, Jul 04, 2013 at 03:25:32PM +0530, Kishon Vijay Abraham I
> wrote:
> > On Thursday 04 July 2013 02:51 PM, Patel, Satish wrote:
> > >Hi,
> > >
> > >>-----Original Message-----
> > >>From: Balbi, Felipe
> > >>Sent: Wednesday, July 03, 2013 6:51 PM
> > >>To: ABRAHAM, KISHON VIJAY
> > >>Cc: Patel, Satish; grant.likely at linaro.org; tony at atomide.com;
> Balbi,
> > >>Felipe; arnd at arndb.de; swarren at nvidia.com;
> > >>sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
> > >>omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> > >>usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> > >>foundation.org; rob.herring at calxeda.com; rob at landley.net;
> > >>linux at arm.linux.org.uk; benoit.cousson at linaro.org;
> mchehab at redhat.com;
> > >>cesarb at cesarb.net; davem at davemloft.net; Nayak, Rajendra;
> > >>shawn.guo at linaro.org; Shilimkar, Santosh; devicetree-
> > >>discuss at lists.ozlabs.org; linux-doc at vger.kernel.org; Nori, Sekhar;
> > >>Krishnamoorthy, Balaji T; Cherian, George
> > >>Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> > >>
> > >>Hi,
> > >>
> > >>On Wed, Jul 03, 2013 at 03:35:39PM +0530, Kishon Vijay Abraham I
> > >>wrote:
> > >>>On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote:
> > >>>>Hi Kishon,
> > >>>>
> > >>>>>-----Original Message-----
> > >>>>>From: ABRAHAM, KISHON VIJAY
> > >>>>>Sent: Wednesday, June 26, 2013 5:17 PM
> > >>>>>To: grant.likely at linaro.org; tony at atomide.com; Balbi, Felipe;
> > >>ABRAHAM,
> > >>>>>KISHON VIJAY; arnd at arndb.de; swarren at nvidia.com;
> > >>>>>sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org;
> linux-
> > >>>>>omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-
> > >>>>>usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> > >>>>>foundation.org
> > >>>>>Cc: rob.herring at calxeda.com; rob at landley.net;
> > >>linux at arm.linux.org.uk;
> > >>>>>benoit.cousson at linaro.org; mchehab at redhat.com;
> cesarb at cesarb.net;
> > >>>>>davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org;
> > >>Shilimkar,
> > >>>>>Santosh; devicetree-discuss at lists.ozlabs.org; linux-
> > >>>>>doc at vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T;
> > >>Cherian,
> > >>>>>George
> > >>>>>Subject: [PATCH v9 0/8] Generic PHY Framework
> > >>>>>
> > >>>>>Added a generic PHY framework that provides a set of APIs for
> the
> > >>PHY
> > >>>>>drivers
> > >>>>>to create/destroy a PHY and APIs for the PHY users to obtain a
> > >>>>>reference to
> > >>>>>the PHY with or without using phandle.
> > >>>>>
> > >>>>>This framework will be of use only to devices that uses
> external
> > >>PHY
> > >>>>>(PHY
> > >>>>>functionality is not embedded within the controller).
> > >>>>>
> > >>>>>The intention of creating this framework is to bring the phy
> > >>drivers
> > >>>>>spread
> > >>>>>all over the Linux kernel to drivers/phy to increase code re-
> use
> > >>and
> > >>>>>to
> > >>>>>increase code maintainability.
> > >>>>
> > >>>>I would like to use this framework for a smart-card controller
> > >>connected to a
> > >>>>smart-card phy. I have some questions and would like to get
> > >>feedback on the same.
> > >>>
> > >>>glad to know that :-)
> > >>>>
> > >>>>I am using ?TDA8026" Smartcard PHY from NXP. Here is the link
> for
> > >>datasheet
> > >>>>and app note for the same. The smart card controller is inside
> the
> > >>TI SoC
> > >>>>I am working with.
> > >>>>
> > >>>>Datasheet :
> > >>>>www.nxp.com/documents/data_sheet/TDA8026.pdf?
> > >>>>
> > >>>>Appnote :
> > >>>>http://www.nxp.com/documents/application_note/AN10724.pdf
> > >>>>
> > >>>>The TI SoC details are not public (yet). I can provide details
> to
> > >>you offline.
> > >>>>
> > >>>>Brief about operation:
> > >>>>-	The controller can work with and without a PHY
> > >>>>-	When not using PHY, it is limited to talking to a single
> > >>>>	smart card. There is also a need to put external de-activation
> > >>logic
> > >>>>	on card removal for this case.
> > >>>>-	With a PHY you can use more than one smart card.
> > >>>>-	Phy has 5 slots :  1 for smart card (credit/debit/other
> card
> > >>with chip)
> > >>>>       and others for SAM ? SIM like modules
> > >>>>- 	Once the PHY is initialized, there are some operations
> that the
> > >>controller
> > >>>>	can request of the PHY like:
> > >>>>	- Card configurations  - set voltage
> > >>>>	- Activation of card
> > >>>>	- ATR ? Answer to reset
> > >>>>	- Warm reset
> > >>>>	- ADPU exchange
> > >>>>	- Deactivation ( Normal/Emergency)
> > >>>
> > >>>hmm.. We should think about extending the phy_ops to include
> these
> > >>>operations (something like phy_smart_card_ops so that other
> > >>>smart_card PHYs will also be able to use it).
> > >>
> > >>let's try to avoid use-case specific additions. set_voltage sounds
> > >>like
> > >>a regulator thing, but the regulator is controlled through the
> PHY. I
> > >>guess it makes sense to have a generic phy_set_voltage() call
> since
> > >>even
> > >>USB can make use of that.
> > >>
> > >>For card activation, it sounds like phy_init()/phy_shutdown()
> would
> > >>cover it.
> > >>
> > >>For warm reset perhaps a phy_reset() callback ? Although that
> could,
> > >>easily, get abused.
> > >>
> > >>For deactivation, that's phy_shutdown().
> > >>
> > >>ATR and ADPU needs more thought, I guess.
> > >>
> > >>>>- 	In the mode when smartcard controller talks directly to
> the
> > >>card without the need
> > >>>>	for a PHY, all the above operations will be carried out by the
> > >>controller itself
> > >>>>
> > >>>>My current thought process is to make the controller driver
> provide
> > >>the user interface
> > >>>>and talk to the PHY using the generic PHY framework you
> proposed.
> > >>In the case where there
> > >>>>is no PHY, my idea is to create a "dummy" PHY which uses the
> > >>controller functionality itself.
> > >>>
> > >>>right. And in the case where you actually have a PHY, create a
> PHY
> > >>>driver and implement the phy_smart_card_ops and register with the
> > >>PHY
> > >>>framework.
> > >>
> > >>I would try to avoid that. Otherwise we will have phy_usb_ops,
> > >>phy_sata_ops, phy_network_ops, phy_pci_ops, etc etc etc. It would
> > >>easily
> > >>blow up.
> > >>
> > >
> > >- I do agree with you. Creating Phy specific ops will blow up whole
> > >   concept of generic phy f/w.
> > >- Can we have interface like phy_setconfig - with parameter like
> > >   phy_setconfig(int param, void *value)
> > >	- Here param can be enum of available config parameters for
> > >	  specific phy.
> > >Phy can perform different operation/set internal state based on
> > >param selection and value passed by.
> > >
> > >e.x in case of smartcard
> > >	enum set_config {
> > >		SET_VOLATAGE,
> > >		SET_ACTIVATE,
> > >		SET_WARMRESET,
> > >		SET_ATR,
> > >		SET_DEACTIVE,
> > >		....
> > >	};
> >
> > hmm.. this looks similar to ioctl and can be abused easily IMO :s
> 
> +1
> 
> What we need is to come up with generic ways to model those, if we
> need
> set voltage, then add a phy_set_voltage() kinda thing, perhaps add
> capability flags to enable/disable support fort those (just like mmc
> does).
> 
> But adding something which can handle "anything" like
> phy_set_config(),
> it's the same as adding use-case specific ops.
> 

We have two options over here

Option 1: 

Defining generic api to which can be mapped over multiple phys
For smartcard case, I have can thought of following mapping with new 
generic apis as suggested.

Smartcard_poweron -> power_on
Smartcard_powerdown -> power_off
Smartcard_set_voltage -> phy_set_voltage
Smartcard_activate_card -> phy_activate_slot
Smartcard_deactivate_card -> phy_deactivate_slot
Smartcard_set_c4/c8/rst/io -> phy_set_pin
Smartcard_warm_reset -> phy_warmreset
Smartcard_set_clkdiv -> phy_set_clock
Smartcard_get_clkdiv -> phy_get_clock
Smartcard_set_atr_mute_timeout -> ??
Smartcard_set_atr_early_timeout -> ??	
Smartcard_get_isr_status -> phy_get_status
Smartcard_get_version -> phy_get_version


- Pros:
	- smartcard phy can make use of generic phy f/w
- cons:
	- does not confirm whether above APIs will capable of including requirements
	  of other available phys
	- list might gets extended for other phys like ethernet, sensor phy etc.
	- any change in single api needs to validated for all existing phy which has
	  bind to generic f/w 
	
Option 2:
We can have set/get config or generic ops kind of implementation

- pros:
	- all phy can be pluged-in to this f/w. The word "generic phy" will be justified
	- no cost of maintaining or defining apis for unknown phy capabilities at present

- cons:
	- factor of getting abused by community.

My recommendation is to see the problem as generic logical level rather than thinking what 
already exits and what cannot be repeated - because interface looks like user space or kernel
space communication.

Where we should make our call ??

-
satish

> --
> balbi

From tony at atomide.com  Mon Jul  8 07:25:54 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Jul 2013 04:25:54 -0700
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
References: <51D577E6.5010507@newflow.co.uk> <51D59146.3070002@newflow.co.uk>
 <51D59C0E.8080003@newflow.co.uk>
 <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
Message-ID: <20130708112553.GU5523@atomide.com>

* Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 06:37]:
> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
> > Hi Tony,
> > 
> > On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> > > * Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 01:17]:
> > > > 
> > > > I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> > > > provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> > > > that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> > > > also results in the console UART getting reset and idled during bootup and that's where
> > > > the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> > > > the system booting fine. 
> > > > 
> > > > I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> > > > omap_serial_early_init() to get earlyprintk working again.
> > > 
> > > Hmm nothing should get idled while earlyprintk is running, and then when the
> > > serial driver kicks in it should not idle anything by default. And for DT based
> > > booting we should not have mach-omap2/serial.c initialize anything.
> > > 
> > 
> > If I add in the HWMOD flags without any reverts I get to the point where the serial driver
> > comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
> > just like Mark reported.
> > 
> 
> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.

It sounds like something needs to be fixed for am33xx as omap3 and omap4
won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
be needed at all for am33xx, and the bug is somewhere else.
 
> > > I wonder if this is because the timeouts get now initialized to 0 instead
> > > of -1 for the serial driver?
> > > 
> > 
> > You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> > am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.

OK

Regards,

Tony


From olof at lixom.net  Mon Jul  8 07:34:33 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Jul 2013 04:34:33 -0700
Subject: [PATCH 4/8] ARM: OMAP: build mach-omap code only if needed
In-Reply-To: <CAOesGMg2f2iRuanVkDOR6m459oQou6J8oJC3Enm_rrS2WMM3hA@mail.gmail.com>
References: <1373041417-217728-1-git-send-email-arnd@arndb.de>
 <1373041417-217728-5-git-send-email-arnd@arndb.de>
 <CAOesGMg2f2iRuanVkDOR6m459oQou6J8oJC3Enm_rrS2WMM3hA@mail.gmail.com>
Message-ID: <CAOesGMjAp-myzFbMh9dyaaz_xCVtAo7z9FJh7pweVMqPK=wKoQ@mail.gmail.com>

[fixed linux-arm-kernel address]

On Mon, Jul 8, 2013 at 4:31 AM, Olof Johansson <olof at lixom.net> wrote:
> Hi,
>
> I think this broke multi_v7_defconfig in last night's linux-next, due
> to TI_PRIV_EDMA no longer being selected. Looks like you missed it
> when moving the options around:
>
> On Fri, Jul 5, 2013 at 9:23 AM, Arnd Bergmann <arnd at arndb.de> wrote:
>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>> index 1f8127a..5c14051 100644
>> --- a/arch/arm/mach-omap2/Kconfig
>> +++ b/arch/arm/mach-omap2/Kconfig
>> @@ -1,62 +1,10 @@
>>  config ARCH_OMAP
>>         bool
>>
>> -config ARCH_OMAP2PLUS
>> -       bool "TI OMAP2/3/4/5 SoCs with device tree support" if (ARCH_MULTI_V6 || ARCH_MULTI_V7)
>> -       select ARCH_HAS_CPUFREQ
>> -       select ARCH_HAS_HOLES_MEMORYMODEL
>> -       select ARCH_OMAP
>> -       select ARCH_REQUIRE_GPIOLIB
>> -       select CLKDEV_LOOKUP
>> -       select CLKSRC_MMIO
>> -       select GENERIC_CLOCKEVENTS
>> -       select GENERIC_IRQ_CHIP
>> -       select HAVE_CLK
>> -       select OMAP_DM_TIMER
>> -       select PINCTRL
>> -       select PROC_DEVICETREE if PROC_FS
>> -       select SOC_BUS
>> -       select SPARSE_IRQ
>> -       select TI_PRIV_EDMA
>> -       select USE_OF
>> -       help
>> -         Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
> [...]
>> +config ARCH_OMAP2PLUS
>> +       bool
>> +       select ARCH_HAS_BANDGAP
>> +       select ARCH_HAS_CPUFREQ
>> +       select ARCH_HAS_HOLES_MEMORYMODEL
>> +       select ARCH_OMAP
>> +       select ARCH_REQUIRE_GPIOLIB
>> +       select CLKDEV_LOOKUP
>> +       select CLKSRC_MMIO
>> +       select GENERIC_CLOCKEVENTS
>> +       select GENERIC_IRQ_CHIP
>> +       select HAVE_CLK
>> +       select OMAP_DM_TIMER
>> +       select PINCTRL
>> +       select PROC_DEVICETREE if PROC_FS
>> +       select SOC_BUS
>> +       select SPARSE_IRQ
>> +       select USE_OF
>> +       help
>> +         Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
>
>
> -Olof


From broonie at kernel.org  Mon Jul  8 07:35:33 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 8 Jul 2013 12:35:33 +0100
Subject: [PATCH 2/3] ARM:dts: vf610: Add DSPI nodes
In-Reply-To: <1373272622-29064-2-git-send-email-b44548@freescale.com>
References: <1373272622-29064-1-git-send-email-b44548@freescale.com>
 <1373272622-29064-2-git-send-email-b44548@freescale.com>
Message-ID: <20130708113533.GT27646@sirena.org.uk>

On Mon, Jul 08, 2013 at 04:37:01PM +0800, Chao Fu wrote:
> From: Chao Fu <B44548 at freescale.com>
> 
> Add Freescale DSPI node into vf610 dts.
> 
> Signed-off-by: Chao Fu <b44548 at freescale.com>

Acked-by: Mark Brown <broonie at linaro.org>

This should be fine to merge via arm-soc, it's no real dependency on the
driver itself or driver specific bindings.
-------------- 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/20130708/6012ee64/attachment.sig>

From broonie at kernel.org  Mon Jul  8 07:36:01 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 8 Jul 2013 12:36:01 +0100
Subject: [PATCH 3/3] ARM:dts:vf610-twr:Enable DSPI0 devices and Flash
 at26df081a
In-Reply-To: <1373272622-29064-3-git-send-email-b44548@freescale.com>
References: <1373272622-29064-1-git-send-email-b44548@freescale.com>
 <1373272622-29064-3-git-send-email-b44548@freescale.com>
Message-ID: <20130708113600.GU27646@sirena.org.uk>

On Mon, Jul 08, 2013 at 04:37:02PM +0800, Chao Fu wrote:
> From: Chao Fu <B44548 at freescale.com>
> 
> This patch enables DSPI0 and at26df081a flash device for Vybrid VF610 TOWER board.

Acked-by: Mark Brown <broonie at linaro.org>

This should be fine to merge via arm-soc, it's no real dependency on the
actual SPI driver.
-------------- 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/20130708/b9f66886/attachment.sig>

From tony at atomide.com  Mon Jul  8 07:54:06 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Jul 2013 04:54:06 -0700
Subject: [PATCH RFC 2/9] ARM: debug: clean up low level kernel
 debugging selection
In-Reply-To: <E1UvoLJ-0006He-RH@rmk-PC.arm.linux.org.uk>
References: <20130707124326.GP24642@n2100.arm.linux.org.uk>
 <E1UvoLJ-0006He-RH@rmk-PC.arm.linux.org.uk>
Message-ID: <20130708115406.GV5523@atomide.com>

* Russell King <rmk+kernel at arm.linux.org.uk> [130707 05:57]:
> It is silly to bury UART selection under multiple levels of choice
> statements, where the top level choice statement will only list
> about four entries when a single SoC is selected.  Move the UART
> selection up into the top level choice statement as it was always
> intended to be.
> 
> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>

Nice, works for me:

Acked-by: Tony Lindgren <tony at atomide.com>


From pavel at ucw.cz  Mon Jul  8 08:04:43 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Mon, 8 Jul 2013 14:04:43 +0200
Subject: pali's n900 tree: fix compilation
Message-ID: <20130708120443.GA2158@amd.pavel.ucw.cz>

Hi!

This fixes compilation w/o CONFIG_TWL4030_MADC.

Please apply :-).

Signed-off-by: Pavel Machek <pavel at ucw.cz>

diff --git a/arch/arm/mach-omap2/board-rx51-compat.c b/arch/arm/mach-omap2/board-rx51-compat.c
index ceabe8b..f3a82a3 100644
--- a/arch/arm/mach-omap2/board-rx51-compat.c
+++ b/arch/arm/mach-omap2/board-rx51-compat.c
@@ -125,6 +125,7 @@ static long twl4030_madc_ioctl(struct file *filp, unsigned int cmd,
 	}
 
 	switch (cmd) {
+#ifdef CONFIG_TWL4030_MADC
 	case TWL4030_MADC_IOCX_ADC_RAW_READ: {
 		struct twl4030_madc_request req;
 		if (par.channel >= TWL4030_MADC_MAX_CHANNELS)
@@ -148,6 +149,7 @@ static long twl4030_madc_ioctl(struct file *filp, unsigned int cmd,
 		}
 		break;
 	}
+#endif
 	default:
 		return -EINVAL;
 	}

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From jonas.jensen at gmail.com  Mon Jul  8 08:09:10 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Mon, 8 Jul 2013 14:09:10 +0200
Subject: [PATCH v3 4/4] ARM: reinsert ARCH_MULTI_V4 Kconfig option
In-Reply-To: <1372949142-8260-1-git-send-email-jonas.jensen@gmail.com>
References: <1372949142-8260-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <CACmBeS3Ges44HxOGZns+G=jQhSmGjVmZBir2_ZBXT1i2nrNQwg@mail.gmail.com>

Arnd suggested removing one (or many) of the options:

CPU_ABRT_EV4T
CPU_CACHE_V4WT
CPU_COPY_V4WB
CPU_TLB_V4WBI

However boot is still broken after removing all including CPU_32v4T.

Selecting CPU_SA1100 instead, it boots normally and init works.

The idea is, If you can help figure out what exactly breaks boot, the
patch can be dropped.

>From these tests, I have created two branches ( arch/arm/mm have
replacements for calls to no longer compiled in ):

http://code.google.com/p/linux-next-20130703-moxart/source/detail?r=a88f33ad22d3f9a31fe126f1c95568e5b2e8f32d&name=multi_V4_test_arm920t
http://code.google.com/p/linux-next-20130703-moxart/source/detail?r=9f4c21f1123a122c51792cd374217ce6e426e74a&name=multi_V4_test_sa1100

Best regards,
Jonas


From tony at atomide.com  Mon Jul  8 08:16:36 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Jul 2013 05:16:36 -0700
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130708112553.GU5523@atomide.com>
References: <51D577E6.5010507@newflow.co.uk> <51D59146.3070002@newflow.co.uk>
 <51D59C0E.8080003@newflow.co.uk>
 <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com>
Message-ID: <20130708121635.GZ5523@atomide.com>

* Tony Lindgren <tony at atomide.com> [130708 04:32]:
> * Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 06:37]:
> > On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
> > > Hi Tony,
> > > 
> > > On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> > > > * Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 01:17]:
> > > > > 
> > > > > I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> > > > > provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> > > > > that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> > > > > also results in the console UART getting reset and idled during bootup and that's where
> > > > > the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> > > > > the system booting fine. 
> > > > > 
> > > > > I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> > > > > omap_serial_early_init() to get earlyprintk working again.
> > > > 
> > > > Hmm nothing should get idled while earlyprintk is running, and then when the
> > > > serial driver kicks in it should not idle anything by default. And for DT based
> > > > booting we should not have mach-omap2/serial.c initialize anything.
> > > > 
> > > 
> > > If I add in the HWMOD flags without any reverts I get to the point where the serial driver
> > > comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
> > > just like Mark reported.
> > > 
> > 
> > Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
> 
> It sounds like something needs to be fixed for am33xx as omap3 and omap4
> won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
> be needed at all for am33xx, and the bug is somewhere else.

Oops, sorry correction: I'm seeing it, I did not have console=ttyO
earlier in my cmdline. It seems that omap-serial.c console suspends
the hardware while earlyprintk is still trying to access it?

Regards,

Tony


From kishon at ti.com  Mon Jul  8 08:17:21 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 8 Jul 2013 17:47:21 +0530
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <780E789C2E067A4BB8F69D0BB9EC4F253E9764D5@DBDE04.ent.ti.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
 <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com>
 <51D54694.20203@ti.com> <20130704101216.GD4830@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E9764D5@DBDE04.ent.ti.com>
Message-ID: <51DAADD1.3060302@ti.com>

Hi,

On Monday 08 July 2013 04:54 PM, Patel, Satish wrote:
> Hi,
>
>
>> -----Original Message-----
>> From: Balbi, Felipe
>> Sent: Thursday, July 04, 2013 3:42 PM
>> To: ABRAHAM, KISHON VIJAY
>> Cc: Patel, Satish; Balbi, Felipe; grant.likely at linaro.org;
>> tony at atomide.com; arnd at arndb.de; swarren at nvidia.com;
>> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
>> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
>> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
>> foundation.org; rob.herring at calxeda.com; rob at landley.net;
>> linux at arm.linux.org.uk; benoit.cousson at linaro.org; mchehab at redhat.com;
>> cesarb at cesarb.net; davem at davemloft.net; Nayak, Rajendra;
>> shawn.guo at linaro.org; Shilimkar, Santosh; devicetree-
>> discuss at lists.ozlabs.org; linux-doc at vger.kernel.org; Nori, Sekhar;
>> Krishnamoorthy, Balaji T; Cherian, George; Mankad, Maulik Ojas
>> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
>>
>> On Thu, Jul 04, 2013 at 03:25:32PM +0530, Kishon Vijay Abraham I
>> wrote:
>>> On Thursday 04 July 2013 02:51 PM, Patel, Satish wrote:
>>>> Hi,
>>>>
>>>>> -----Original Message-----
>>>>> From: Balbi, Felipe
>>>>> Sent: Wednesday, July 03, 2013 6:51 PM
>>>>> To: ABRAHAM, KISHON VIJAY
>>>>> Cc: Patel, Satish; grant.likely at linaro.org; tony at atomide.com;
>> Balbi,
>>>>> Felipe; arnd at arndb.de; swarren at nvidia.com;
>>>>> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
>>>>> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
>>>>> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
>>>>> foundation.org; rob.herring at calxeda.com; rob at landley.net;
>>>>> linux at arm.linux.org.uk; benoit.cousson at linaro.org;
>> mchehab at redhat.com;
>>>>> cesarb at cesarb.net; davem at davemloft.net; Nayak, Rajendra;
>>>>> shawn.guo at linaro.org; Shilimkar, Santosh; devicetree-
>>>>> discuss at lists.ozlabs.org; linux-doc at vger.kernel.org; Nori, Sekhar;
>>>>> Krishnamoorthy, Balaji T; Cherian, George
>>>>> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Wed, Jul 03, 2013 at 03:35:39PM +0530, Kishon Vijay Abraham I
>>>>> wrote:
>>>>>> On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote:
>>>>>>> Hi Kishon,
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: ABRAHAM, KISHON VIJAY
>>>>>>>> Sent: Wednesday, June 26, 2013 5:17 PM
>>>>>>>> To: grant.likely at linaro.org; tony at atomide.com; Balbi, Felipe;
>>>>> ABRAHAM,
>>>>>>>> KISHON VIJAY; arnd at arndb.de; swarren at nvidia.com;
>>>>>>>> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org;
>> linux-
>>>>>>>> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>> linux-
>>>>>>>> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
>>>>>>>> foundation.org
>>>>>>>> Cc: rob.herring at calxeda.com; rob at landley.net;
>>>>> linux at arm.linux.org.uk;
>>>>>>>> benoit.cousson at linaro.org; mchehab at redhat.com;
>> cesarb at cesarb.net;
>>>>>>>> davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org;
>>>>> Shilimkar,
>>>>>>>> Santosh; devicetree-discuss at lists.ozlabs.org; linux-
>>>>>>>> doc at vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T;
>>>>> Cherian,
>>>>>>>> George
>>>>>>>> Subject: [PATCH v9 0/8] Generic PHY Framework
>>>>>>>>
>>>>>>>> Added a generic PHY framework that provides a set of APIs for
>> the
>>>>> PHY
>>>>>>>> drivers
>>>>>>>> to create/destroy a PHY and APIs for the PHY users to obtain a
>>>>>>>> reference to
>>>>>>>> the PHY with or without using phandle.
>>>>>>>>
>>>>>>>> This framework will be of use only to devices that uses
>> external
>>>>> PHY
>>>>>>>> (PHY
>>>>>>>> functionality is not embedded within the controller).
>>>>>>>>
>>>>>>>> The intention of creating this framework is to bring the phy
>>>>> drivers
>>>>>>>> spread
>>>>>>>> all over the Linux kernel to drivers/phy to increase code re-
>> use
>>>>> and
>>>>>>>> to
>>>>>>>> increase code maintainability.
>>>>>>>
>>>>>>> I would like to use this framework for a smart-card controller
>>>>> connected to a
>>>>>>> smart-card phy. I have some questions and would like to get
>>>>> feedback on the same.
>>>>>>
>>>>>> glad to know that :-)
>>>>>>>
>>>>>>> I am using ?TDA8026" Smartcard PHY from NXP. Here is the link
>> for
>>>>> datasheet
>>>>>>> and app note for the same. The smart card controller is inside
>> the
>>>>> TI SoC
>>>>>>> I am working with.
>>>>>>>
>>>>>>> Datasheet :
>>>>>>> www.nxp.com/documents/data_sheet/TDA8026.pdf?
>>>>>>>
>>>>>>> Appnote :
>>>>>>> http://www.nxp.com/documents/application_note/AN10724.pdf
>>>>>>>
>>>>>>> The TI SoC details are not public (yet). I can provide details
>> to
>>>>> you offline.
>>>>>>>
>>>>>>> Brief about operation:
>>>>>>> -	The controller can work with and without a PHY
>>>>>>> -	When not using PHY, it is limited to talking to a single
>>>>>>> 	smart card. There is also a need to put external de-activation
>>>>> logic
>>>>>>> 	on card removal for this case.
>>>>>>> -	With a PHY you can use more than one smart card.
>>>>>>> -	Phy has 5 slots :  1 for smart card (credit/debit/other
>> card
>>>>> with chip)
>>>>>>>        and others for SAM ? SIM like modules
>>>>>>> - 	Once the PHY is initialized, there are some operations
>> that the
>>>>> controller
>>>>>>> 	can request of the PHY like:
>>>>>>> 	- Card configurations  - set voltage
>>>>>>> 	- Activation of card
>>>>>>> 	- ATR ? Answer to reset
>>>>>>> 	- Warm reset
>>>>>>> 	- ADPU exchange
>>>>>>> 	- Deactivation ( Normal/Emergency)
>>>>>>
>>>>>> hmm.. We should think about extending the phy_ops to include
>> these
>>>>>> operations (something like phy_smart_card_ops so that other
>>>>>> smart_card PHYs will also be able to use it).
>>>>>
>>>>> let's try to avoid use-case specific additions. set_voltage sounds
>>>>> like
>>>>> a regulator thing, but the regulator is controlled through the
>> PHY. I
>>>>> guess it makes sense to have a generic phy_set_voltage() call
>> since
>>>>> even
>>>>> USB can make use of that.
>>>>>
>>>>> For card activation, it sounds like phy_init()/phy_shutdown()
>> would
>>>>> cover it.
>>>>>
>>>>> For warm reset perhaps a phy_reset() callback ? Although that
>> could,
>>>>> easily, get abused.
>>>>>
>>>>> For deactivation, that's phy_shutdown().
>>>>>
>>>>> ATR and ADPU needs more thought, I guess.
>>>>>
>>>>>>> - 	In the mode when smartcard controller talks directly to
>> the
>>>>> card without the need
>>>>>>> 	for a PHY, all the above operations will be carried out by the
>>>>> controller itself
>>>>>>>
>>>>>>> My current thought process is to make the controller driver
>> provide
>>>>> the user interface
>>>>>>> and talk to the PHY using the generic PHY framework you
>> proposed.
>>>>> In the case where there
>>>>>>> is no PHY, my idea is to create a "dummy" PHY which uses the
>>>>> controller functionality itself.
>>>>>>
>>>>>> right. And in the case where you actually have a PHY, create a
>> PHY
>>>>>> driver and implement the phy_smart_card_ops and register with the
>>>>> PHY
>>>>>> framework.
>>>>>
>>>>> I would try to avoid that. Otherwise we will have phy_usb_ops,
>>>>> phy_sata_ops, phy_network_ops, phy_pci_ops, etc etc etc. It would
>>>>> easily
>>>>> blow up.
>>>>>
>>>>
>>>> - I do agree with you. Creating Phy specific ops will blow up whole
>>>>    concept of generic phy f/w.
>>>> - Can we have interface like phy_setconfig - with parameter like
>>>>    phy_setconfig(int param, void *value)
>>>> 	- Here param can be enum of available config parameters for
>>>> 	  specific phy.
>>>> Phy can perform different operation/set internal state based on
>>>> param selection and value passed by.
>>>>
>>>> e.x in case of smartcard
>>>> 	enum set_config {
>>>> 		SET_VOLATAGE,
>>>> 		SET_ACTIVATE,
>>>> 		SET_WARMRESET,
>>>> 		SET_ATR,
>>>> 		SET_DEACTIVE,
>>>> 		....
>>>> 	};
>>>
>>> hmm.. this looks similar to ioctl and can be abused easily IMO :s
>>
>> +1
>>
>> What we need is to come up with generic ways to model those, if we
>> need
>> set voltage, then add a phy_set_voltage() kinda thing, perhaps add
>> capability flags to enable/disable support fort those (just like mmc
>> does).
>>
>> But adding something which can handle "anything" like
>> phy_set_config(),
>> it's the same as adding use-case specific ops.
>>
>
> We have two options over here
>
> Option 1:
>
> Defining generic api to which can be mapped over multiple phys
> For smartcard case, I have can thought of following mapping with new
> generic apis as suggested.
>
> Smartcard_poweron -> power_on
> Smartcard_powerdown -> power_off
> Smartcard_set_voltage -> phy_set_voltage
> Smartcard_activate_card -> phy_activate_slot
> Smartcard_deactivate_card -> phy_deactivate_slot

how is activate/deactivate different from poweron/poweroff in this
use case?
> Smartcard_set_c4/c8/rst/io -> phy_set_pin

Whats should be exactly done here? Looks to me like it should be
part of init. Does these pin settings need to be changed dynamically?
> Smartcard_warm_reset -> phy_warmreset

Again looks to me like it should be part of init.
> Smartcard_set_clkdiv -> phy_set_clock
> Smartcard_get_clkdiv -> phy_get_clock

Why would the smartcard give clock to the PHY? Shouldn't the driver
of the PHY driver be doing that by itself?

> Smartcard_set_atr_mute_timeout -> ??
> Smartcard_set_atr_early_timeout -> ??	
> Smartcard_get_isr_status -> phy_get_status

Why? Is it like the detection of an external event? Then the PHY
driver should use *extcon* for event detection and passing.

> Smartcard_get_version -> phy_get_version

Again why? Why would the smartcard need the version of the PHY?

Thanks
Kishon


From pali.rohar at gmail.com  Mon Jul  8 08:19:21 2013
From: pali.rohar at gmail.com (Pali =?utf-8?q?Roh=C3=A1r?=)
Date: Mon, 8 Jul 2013 14:19:21 +0200
Subject: pali's n900 tree: fix compilation
In-Reply-To: <20130708120443.GA2158@amd.pavel.ucw.cz>
References: <20130708120443.GA2158@amd.pavel.ucw.cz>
Message-ID: <201307081419.21572@pali>

On Monday 08 July 2013 14:04:43 Pavel Machek wrote:
> Hi!
> 
> This fixes compilation w/o CONFIG_TWL4030_MADC.
> 
> Please apply :-).
> 
> Signed-off-by: Pavel Machek <pavel at ucw.cz>
> 
> diff --git a/arch/arm/mach-omap2/board-rx51-compat.c
> b/arch/arm/mach-omap2/board-rx51-compat.c index
> ceabe8b..f3a82a3 100644

Commited to branch v3.10-n900:
https://gitorious.org/linux-n900/linux-n900/commit/d5da1f5357345ad270a491ce285c78dcf901a7ff

File board-rx51-compat.c contains only maemo5 specified userspace
interfaces. Nothing which can go to upstream. Once if all these interfaces
are removed from maemo5 (CSSU), I will remove them also from my git tree.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130708/f0c8a6f8/attachment.sig>

From rnayak at ti.com  Mon Jul  8 08:41:56 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 8 Jul 2013 18:11:56 +0530
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130708112553.GU5523@atomide.com>
References: <51D577E6.5010507@newflow.co.uk> <51D59146.3070002@newflow.co.uk>
 <51D59C0E.8080003@newflow.co.uk>
 <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com>
Message-ID: <51DAB394.3050104@ti.com>

On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
> * Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 06:37]:
>> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
>>> Hi Tony,
>>>
>>> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
>>>> * Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 01:17]:
>>>>>
>>>>> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
>>>>> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
>>>>> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
>>>>> also results in the console UART getting reset and idled during bootup and that's where
>>>>> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
>>>>> the system booting fine. 
>>>>>
>>>>> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
>>>>> omap_serial_early_init() to get earlyprintk working again.
>>>>
>>>> Hmm nothing should get idled while earlyprintk is running, and then when the
>>>> serial driver kicks in it should not idle anything by default. And for DT based
>>>> booting we should not have mach-omap2/serial.c initialize anything.
>>>>
>>>
>>> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
>>> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
>>> just like Mark reported.
>>>
>>
>> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
> 
> It sounds like something needs to be fixed for am33xx as omap3 and omap4
> won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
> be needed at all for am33xx, and the bug is somewhere else.

Tony, I spent some time on this today and there seem to 2 issues.

Issue 1: Causing boot to stop much earlier as reported (this is during hmwod setup)

The commit 'e97f03cb36e9ec8a2ccaa3e4bee5297fe48156fd' 
"ARM: OMAP2+: Fix serial init for device tree based booting" stubbed out omap_serial_early_init()
for DT case thinking its doing the port inits. But that does not seem to be true, the port inits happen
as part of omap_serial_init_port(). What omap_serial_early_init() was doing instead was adding the
HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags which would tell hmwod not to reset and then idle the
console UART. With this not happening now for the DT case, it causes an issue.

The issue was seen on am33xx and not on some other platforms because some platforms still have these
statically defined in the hwmod data files. I could see these set for uart3 in case of omap4 and omap5.
So I feel the above commit should be reverted and these static flags should be removed from the data
files.

>  
>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>> of -1 for the serial driver?
>>>>
>>>
>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> 
> OK

Issue 2: Causing boot to stop when serial driver is initialized. (After Issue 1 is fixed)

I could narrow this down to the change done to return -EINVAL instead of 0 in serial_omap_get_context_loss_count()
as part of commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap: Fix device tree based PM runtime"

What this change in turn seems to do is cause a serial_omap_restore_context() to get called as part of
serial_omap_runtime_resume() which was not the case when serial_omap_get_context_loss_count() returned 0

from serial_omap_runtime_resume():
-----
        int loss_cnt = serial_omap_get_context_loss_count(up);

        if (loss_cnt < 0) {
                dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
                        loss_cnt);
                serial_omap_restore_context(up);
        } else if (up->context_loss_cnt != loss_cnt) {
                serial_omap_restore_context(up);
        }
-----

I am still working on why a serial_omap_restore_context() could have caused console to die. I will work with
Sourav on this and post the fixes for both issue 1 and issue2 once its clear on whats really causing issue 2.

Let me know if the fix I listed for Issue 1: makes sense.

regards,
Rajendra

> 
> Regards,
> 
> Tony
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 



From s.nawrocki at samsung.com  Mon Jul  8 08:52:51 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 08 Jul 2013 14:52:51 +0200
Subject: [PATCH v3 07/13] ARM: dts: Add AK8975 device node for Exynos4412
 TRATS2 board
In-Reply-To: <1491290.c836bFtNe2@flatron>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
 <1372692155-17653-8-git-send-email-s.nawrocki@samsung.com>
 <1491290.c836bFtNe2@flatron>
Message-ID: <51DAB623.1010404@samsung.com>

Hi Tomasz,

On 07/06/2013 01:18 AM, Tomasz Figa wrote:
> On Monday 01 of July 2013 17:22:29 Sylwester Nawrocki wrote:
>> From: Jacek Anaszewski <j.anaszewski at samsung.com>
>>
>> This patch adds AK8975 magnetometer node and corresponding
>> i2c-gpio bus node for TRATS2 board.
>>
>> Signed-off-by: Jacek Anaszewski <j.anaszewski at samsung.com>
>> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
>> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
>> ---
>>  arch/arm/boot/dts/exynos4412-trats2.dts |   19 +++++++++++++++++++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
>> b/arch/arm/boot/dts/exynos4412-trats2.dts index 056b835..b9de3b5 100644
>> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
>> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
>> @@ -19,6 +19,10 @@
>>  	model = "Samsung Trats 2 based on Exynos4412";
>>  	compatible = "samsung,trats2", "samsung,exynos4412";
>>
>> +	aliases {
>> +		i2c8 = &i2c_ak8975;
>> +	};
>> +
>>  	memory {
>>  		reg =  <0x40000000 0x40000000>;
>>  	};
>> @@ -453,4 +457,19 @@
>>  	serial at 13830000 {
>>  		status = "okay";
>>  	};
>> +
>> +	i2c_ak8975: i2c-gpio at 0 {
> 
> I think this @0 is slightly incorrect here, as it seems like there is no 
> reg property present inside the node and so the device isn't located at 
> any address.
> 
> For logical indices like in this case I would rather use i2c-gpio-0 
> instead.

Indeed, using "-<N>" postfix sounds like a better alternative. I'll change
it and repost the series after 3.11-rc1 is released.

>> +		compatible = "i2c-gpio";
>> +		gpios = <&gpy2 4 0>, <&gpy2 5 0>;
>> +		i2c-gpio,delay-us = <2>;
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +		status = "okay";
>> +
>> +		ak8975 at 0c {
>> +			compatible = "asahi-kasei,ak8975";
>> +			reg = <0x0c>;
>> +			gpios = <&gpj0 7 0>;
>> +		};
>> +	};
>>  };
> 
> Otherwise looks good.
> 
> Reviewed-by: Tomasz Figa <t.figa at samsung.com>

--
Thanks,
Sylwester


From tony at atomide.com  Mon Jul  8 09:10:33 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Jul 2013 06:10:33 -0700
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51DAB394.3050104@ti.com>
References: <51D577E6.5010507@newflow.co.uk> <51D59146.3070002@newflow.co.uk>
 <51D59C0E.8080003@newflow.co.uk>
 <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
Message-ID: <20130708131033.GA5523@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130708 05:48]:
> On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
> > * Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 06:37]:
> >> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
> >>> Hi Tony,
> >>>
> >>> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> >>>> * Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 01:17]:
> >>>>>
> >>>>> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> >>>>> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> >>>>> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> >>>>> also results in the console UART getting reset and idled during bootup and that's where
> >>>>> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> >>>>> the system booting fine. 
> >>>>>
> >>>>> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> >>>>> omap_serial_early_init() to get earlyprintk working again.
> >>>>
> >>>> Hmm nothing should get idled while earlyprintk is running, and then when the
> >>>> serial driver kicks in it should not idle anything by default. And for DT based
> >>>> booting we should not have mach-omap2/serial.c initialize anything.
> >>>>
> >>>
> >>> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
> >>> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
> >>> just like Mark reported.
> >>>
> >>
> >> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
> > 
> > It sounds like something needs to be fixed for am33xx as omap3 and omap4
> > won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
> > be needed at all for am33xx, and the bug is somewhere else.
> 
> Tony, I spent some time on this today and there seem to 2 issues.
> 
> Issue 1: Causing boot to stop much earlier as reported (this is during hmwod setup)
> 
> The commit 'e97f03cb36e9ec8a2ccaa3e4bee5297fe48156fd' 
> "ARM: OMAP2+: Fix serial init for device tree based booting" stubbed out omap_serial_early_init()
> for DT case thinking its doing the port inits. But that does not seem to be true, the port inits happen
> as part of omap_serial_init_port(). What omap_serial_early_init() was doing instead was adding the
> HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags which would tell hmwod not to reset and then idle the
> console UART. With this not happening now for the DT case, it causes an issue.
> 
> The issue was seen on am33xx and not on some other platforms because some platforms still have these
> statically defined in the hwmod data files. I could see these set for uart3 in case of omap4 and omap5.
> So I feel the above commit should be reverted and these static flags should be removed from the data
> files.

Oh OK. That's starting to make a bit more sense then. 
  
> >>>> I wonder if this is because the timeouts get now initialized to 0 instead
> >>>> of -1 for the serial driver?
> >>>>
> >>>
> >>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> >>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> > 
> > OK
> 
> Issue 2: Causing boot to stop when serial driver is initialized. (After Issue 1 is fixed)
> 
> I could narrow this down to the change done to return -EINVAL instead of 0 in serial_omap_get_context_loss_count()
> as part of commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap: Fix device tree based PM runtime"
> 
> What this change in turn seems to do is cause a serial_omap_restore_context() to get called as part of
> serial_omap_runtime_resume() which was not the case when serial_omap_get_context_loss_count() returned 0
> 
> from serial_omap_runtime_resume():
> -----
>         int loss_cnt = serial_omap_get_context_loss_count(up);
> 
>         if (loss_cnt < 0) {
>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>                         loss_cnt);
>                 serial_omap_restore_context(up);
>         } else if (up->context_loss_cnt != loss_cnt) {
>                 serial_omap_restore_context(up);
>         }
> -----
> 
> I am still working on why a serial_omap_restore_context() could have caused console to die. I will work with
> Sourav on this and post the fixes for both issue 1 and issue2 once its clear on whats really causing issue 2.

That's because we don't have the omap specific pdata callbacks for
context loss any longer. We may be able to detect when the context
was really lost in the serial driver, and only then call the
serial_omap_restore_context().
 
> Let me know if the fix I listed for Issue 1: makes sense.

Yes makes sense as a fix, but IMHO we should not need any workarounds
like that. Is the hwmod code idling the the uarts early? If so, then
it should only do that in a late_initcall if no drivers are registered.

Regards,

Tony


From s.nawrocki at samsung.com  Mon Jul  8 09:13:27 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 08 Jul 2013 15:13:27 +0200
Subject: [PATCH v3 08/13] ARM: dts: Add camera device nodes for Exynos4412
 TRATS2 board
In-Reply-To: <1996184.tcirO0Du7j@flatron>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
 <1372692155-17653-9-git-send-email-s.nawrocki@samsung.com>
 <1996184.tcirO0Du7j@flatron>
Message-ID: <51DABAF7.5000201@samsung.com>

On 07/06/2013 01:23 AM, Tomasz Figa wrote:
> On Monday 01 of July 2013 17:22:30 Sylwester Nawrocki wrote:
>> This patch enables the front camera using the internal
>> camera ISP (FIMC-IS).
>>
>> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
>> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
>> ---
>>  arch/arm/boot/dts/exynos4412-trats2.dts |   91
>> +++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
>> b/arch/arm/boot/dts/exynos4412-trats2.dts index b9de3b5..e9fb3de 100644
>> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
>> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
>> @@ -62,6 +62,15 @@
>>  			enable-active-high;
>>  		};
>>
>> +		cam_io_reg: voltage-regulator at 3 {
> 
> Same comment here as for patch 7/13. This is not an address of this 
> regulator, so I would rather use -3 prefix.

Yes, and this is the convention already used in this 'regulators' node.
I'll rename that node to 'voltage-regulator-1'.

>> +			compatible = "regulator-fixed";
>> +			regulator-name = "CAM_SENSOR_A";
>> +			regulator-min-microvolt = <2800000>;
>> +			regulator-max-microvolt = <2800000>;
>> +			gpio = <&gpm0 2 0>;
>> +			enable-active-high;
>> +		};
>> +
>>  		/* More to come */
>>  	};
>>
>> @@ -472,4 +481,86 @@
>>  			gpios = <&gpj0 7 0>;
>>  		};
>>  	};
>> +
>> +	camera {
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&cam_port_b_clk_active>;
>> +		status = "okay";
>> +
>> +		fimc_0: fimc at 11800000 {
>> +			clock-frequency = <160000000>;
>> +			status = "okay";
>> +		};
>> +
>> +		fimc_1: fimc at 11810000 {
>> +			clock-frequency = <160000000>;
>> +			status = "okay";
>> +		};
>> +
>> +		fimc_2: fimc at 11820000 {
>> +			clock-frequency = <160000000>;
>> +			status = "okay";
>> +		};
>> +
>> +		fimc_3: fimc at 11830000 {
>> +			clock-frequency = <160000000>;
>> +			status = "okay";
>> +		};
>> +
>> +		csis_1: csis at 11890000 {
>> +			vddcore-supply = <&ldo8_reg>;
>> +			vddio-supply = <&ldo10_reg>;
>> +			clock-frequency = <160000000>;
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
> 
> Hmm. Couldn't the two #properties above be moved to exynos4.dtsi instead?

Normally the port/endpoint nodes are board specific. But since the binding
requires at least one port and endpoint node, these properties will always
need to be specified. Thus it's a good idea to move them to exynos4.dtsi.

--
Thanks,
Sylwester


From linux at roeck-us.net  Mon Jul  8 09:14:21 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 8 Jul 2013 06:14:21 -0700
Subject: [lm-sensors] [PATCH 1/2] ARM: dt: t30 cardhu: add dt entry for
 lm90
In-Reply-To: <51DA8805.50709@nvidia.com>
References: <1372928979-26938-1-git-send-email-wni@nvidia.com>
 <1372928979-26938-2-git-send-email-wni@nvidia.com>
 <51D70483.70203@wwwdotorg.org> <51DA6BD4.1040300@nvidia.com>
 <20130708095024.041a6d57@endymion.delvare>
 <51DA8805.50709@nvidia.com>
Message-ID: <20130708131421.GB21638@roeck-us.net>

On Mon, Jul 08, 2013 at 05:36:05PM +0800, Wei Ni wrote:
> On 07/08/2013 03:50 PM, Jean Delvare wrote:
> > On Mon, 8 Jul 2013 15:35:48 +0800, Wei Ni wrote:
> >> On 07/06/2013 01:38 AM, Stephen Warren wrote:
> >>> On 07/04/2013 03:09 AM, Wei Ni wrote:
> >>>> Enable thermal sensor lm90 for t30 cardhu.
> >>>
> >>>> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
> >>>
> >>>> +		nct1008: nct1008 {
> >>>> +			compatible = "lm90,nct1008";
> >>>
> >>> "lm90" isn't a valid vendor prefix. I believe the value you want is
> >>> "onnn,nct1008". Same comment for patch 2/2.
> >>
> >> The lm90 doesn't support device tree very well.
> > 
> > I doubt it, but if this is the case, then please fix it, instead of
> > working the problem around in a different place.
> > 
> >> In the DT, we need to
> >> named as "lm90" so that the lm90 driver can be loaded,
> > 
> > Not that I am an expert with regards to DT, but this doesn't make any
> > sense to me. AFAIK DT is about devices, not which drivers handle them.
> > 
> >> and we also need
> >> to add "nct1008" to indicate this is the nct1008 device, so that the
> >> lm90 driver can be loaded with the right i2c_device_id->driver_data.
> >>
> >> I set the " compatible = "lm90,nct1008" ", this is the simplest way, and
> >> we doesn't need to change the lm90.c.
> > 
> > There's no problem with changing the lm90 driver, if this is the right
> > thing to do.
> 
> Ok, I will add DT support in the lm90.c in my next version patch.
> 
Only if you can show that it is necessary.

Guenter


From rnayak at ti.com  Mon Jul  8 09:20:01 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 8 Jul 2013 18:50:01 +0530
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130708131033.GA5523@atomide.com>
References: <51D577E6.5010507@newflow.co.uk> <51D59146.3070002@newflow.co.uk>
 <51D59C0E.8080003@newflow.co.uk>
 <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com>
Message-ID: <51DABC81.3080409@ti.com>

On Monday 08 July 2013 06:40 PM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak at ti.com> [130708 05:48]:
>> On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
>>> * Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 06:37]:
>>>> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
>>>>> Hi Tony,
>>>>>
>>>>> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
>>>>>> * Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 01:17]:
>>>>>>>
>>>>>>> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
>>>>>>> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
>>>>>>> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
>>>>>>> also results in the console UART getting reset and idled during bootup and that's where
>>>>>>> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
>>>>>>> the system booting fine. 
>>>>>>>
>>>>>>> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
>>>>>>> omap_serial_early_init() to get earlyprintk working again.
>>>>>>
>>>>>> Hmm nothing should get idled while earlyprintk is running, and then when the
>>>>>> serial driver kicks in it should not idle anything by default. And for DT based
>>>>>> booting we should not have mach-omap2/serial.c initialize anything.
>>>>>>
>>>>>
>>>>> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
>>>>> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
>>>>> just like Mark reported.
>>>>>
>>>>
>>>> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
>>>
>>> It sounds like something needs to be fixed for am33xx as omap3 and omap4
>>> won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
>>> be needed at all for am33xx, and the bug is somewhere else.
>>
>> Tony, I spent some time on this today and there seem to 2 issues.
>>
>> Issue 1: Causing boot to stop much earlier as reported (this is during hmwod setup)
>>
>> The commit 'e97f03cb36e9ec8a2ccaa3e4bee5297fe48156fd' 
>> "ARM: OMAP2+: Fix serial init for device tree based booting" stubbed out omap_serial_early_init()
>> for DT case thinking its doing the port inits. But that does not seem to be true, the port inits happen
>> as part of omap_serial_init_port(). What omap_serial_early_init() was doing instead was adding the
>> HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags which would tell hmwod not to reset and then idle the
>> console UART. With this not happening now for the DT case, it causes an issue.
>>
>> The issue was seen on am33xx and not on some other platforms because some platforms still have these
>> statically defined in the hwmod data files. I could see these set for uart3 in case of omap4 and omap5.
>> So I feel the above commit should be reverted and these static flags should be removed from the data
>> files.
> 
> Oh OK. That's starting to make a bit more sense then. 
>   
>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>> of -1 for the serial driver?
>>>>>>
>>>>>
>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>
>>> OK
>>
>> Issue 2: Causing boot to stop when serial driver is initialized. (After Issue 1 is fixed)
>>
>> I could narrow this down to the change done to return -EINVAL instead of 0 in serial_omap_get_context_loss_count()
>> as part of commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap: Fix device tree based PM runtime"
>>
>> What this change in turn seems to do is cause a serial_omap_restore_context() to get called as part of
>> serial_omap_runtime_resume() which was not the case when serial_omap_get_context_loss_count() returned 0
>>
>> from serial_omap_runtime_resume():
>> -----
>>         int loss_cnt = serial_omap_get_context_loss_count(up);
>>
>>         if (loss_cnt < 0) {
>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>                         loss_cnt);
>>                 serial_omap_restore_context(up);
>>         } else if (up->context_loss_cnt != loss_cnt) {
>>                 serial_omap_restore_context(up);
>>         }
>> -----
>>
>> I am still working on why a serial_omap_restore_context() could have caused console to die. I will work with
>> Sourav on this and post the fixes for both issue 1 and issue2 once its clear on whats really causing issue 2.
> 
> That's because we don't have the omap specific pdata callbacks for
> context loss any longer. We may be able to detect when the context
> was really lost in the serial driver, and only then call the
> serial_omap_restore_context().

Right, but calling serial_omap_restore_context() even when the context is not lost, should not
ideally cause an issue.

>  
>> Let me know if the fix I listed for Issue 1: makes sense.
> 
> Yes makes sense as a fix, but IMHO we should not need any workarounds
> like that. Is the hwmod code idling the the uarts early? If so, then
> it should only do that in a late_initcall if no drivers are registered.

hwmod as part of its setup (early) enables/resets and idles all modules.
These flags are used to tell hwmod to avoid a reset and idle and leave the
module enabled (in this case console uart)

regards
Rajendra

> 
> Regards,
> 
> Tony
> 



From rnayak at ti.com  Mon Jul  8 09:25:41 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 8 Jul 2013 18:55:41 +0530
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51DABC81.3080409@ti.com>
References: <51D577E6.5010507@newflow.co.uk> <51D59146.3070002@newflow.co.uk>
 <51D59C0E.8080003@newflow.co.uk>
 <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
Message-ID: <51DABDD5.3060601@ti.com>

On Monday 08 July 2013 06:50 PM, Rajendra Nayak wrote:
> On Monday 08 July 2013 06:40 PM, Tony Lindgren wrote:
>> * Rajendra Nayak <rnayak at ti.com> [130708 05:48]:
>>> On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
>>>> * Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 06:37]:
>>>>> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
>>>>>> Hi Tony,
>>>>>>
>>>>>> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
>>>>>>> * Bedia, Vaibhav <vaibhav.bedia at ti.com> [130705 01:17]:
>>>>>>>>
>>>>>>>> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
>>>>>>>> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
>>>>>>>> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
>>>>>>>> also results in the console UART getting reset and idled during bootup and that's where
>>>>>>>> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
>>>>>>>> the system booting fine. 
>>>>>>>>
>>>>>>>> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
>>>>>>>> omap_serial_early_init() to get earlyprintk working again.
>>>>>>>
>>>>>>> Hmm nothing should get idled while earlyprintk is running, and then when the
>>>>>>> serial driver kicks in it should not idle anything by default. And for DT based
>>>>>>> booting we should not have mach-omap2/serial.c initialize anything.
>>>>>>>
>>>>>>
>>>>>> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
>>>>>> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
>>>>>> just like Mark reported.
>>>>>>
>>>>>
>>>>> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
>>>>
>>>> It sounds like something needs to be fixed for am33xx as omap3 and omap4
>>>> won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
>>>> be needed at all for am33xx, and the bug is somewhere else.
>>>
>>> Tony, I spent some time on this today and there seem to 2 issues.
>>>
>>> Issue 1: Causing boot to stop much earlier as reported (this is during hmwod setup)
>>>
>>> The commit 'e97f03cb36e9ec8a2ccaa3e4bee5297fe48156fd' 
>>> "ARM: OMAP2+: Fix serial init for device tree based booting" stubbed out omap_serial_early_init()
>>> for DT case thinking its doing the port inits. But that does not seem to be true, the port inits happen
>>> as part of omap_serial_init_port(). What omap_serial_early_init() was doing instead was adding the
>>> HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags which would tell hmwod not to reset and then idle the
>>> console UART. With this not happening now for the DT case, it causes an issue.
>>>
>>> The issue was seen on am33xx and not on some other platforms because some platforms still have these
>>> statically defined in the hwmod data files. I could see these set for uart3 in case of omap4 and omap5.
>>> So I feel the above commit should be reverted and these static flags should be removed from the data
>>> files.
>>
>> Oh OK. That's starting to make a bit more sense then. 
>>   
>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>>> of -1 for the serial driver?
>>>>>>>
>>>>>>
>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>>
>>>> OK
>>>
>>> Issue 2: Causing boot to stop when serial driver is initialized. (After Issue 1 is fixed)
>>>
>>> I could narrow this down to the change done to return -EINVAL instead of 0 in serial_omap_get_context_loss_count()
>>> as part of commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap: Fix device tree based PM runtime"
>>>
>>> What this change in turn seems to do is cause a serial_omap_restore_context() to get called as part of
>>> serial_omap_runtime_resume() which was not the case when serial_omap_get_context_loss_count() returned 0
>>>
>>> from serial_omap_runtime_resume():
>>> -----
>>>         int loss_cnt = serial_omap_get_context_loss_count(up);
>>>
>>>         if (loss_cnt < 0) {
>>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>>                         loss_cnt);
>>>                 serial_omap_restore_context(up);
>>>         } else if (up->context_loss_cnt != loss_cnt) {
>>>                 serial_omap_restore_context(up);
>>>         }
>>> -----
>>>
>>> I am still working on why a serial_omap_restore_context() could have caused console to die. I will work with
>>> Sourav on this and post the fixes for both issue 1 and issue2 once its clear on whats really causing issue 2.
>>
>> That's because we don't have the omap specific pdata callbacks for
>> context loss any longer. We may be able to detect when the context
>> was really lost in the serial driver, and only then call the
>> serial_omap_restore_context().
> 
> Right, but calling serial_omap_restore_context() even when the context is not lost, should not
> ideally cause an issue.

So looking some more into this, it turns out a lot of what serial_omap_restore_context() restores
gets set as part of serial_omap_set_termios() which infact gets called much later and any call to
serial_omap_restore_context before a call to serial_omap_set_termios() ends up restoring junk?

> 
>>  
>>> Let me know if the fix I listed for Issue 1: makes sense.
>>
>> Yes makes sense as a fix, but IMHO we should not need any workarounds
>> like that. Is the hwmod code idling the the uarts early? If so, then
>> it should only do that in a late_initcall if no drivers are registered.
> 
> hwmod as part of its setup (early) enables/resets and idles all modules.
> These flags are used to tell hwmod to avoid a reset and idle and leave the
> module enabled (in this case console uart)
> 
> regards
> Rajendra
> 
>>
>> Regards,
>>
>> Tony
>>
> 



From balbi at ti.com  Mon Jul  8 09:26:34 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 8 Jul 2013 16:26:34 +0300
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <780E789C2E067A4BB8F69D0BB9EC4F253E9764D5@DBDE04.ent.ti.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
 <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com>
 <51D54694.20203@ti.com> <20130704101216.GD4830@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E9764D5@DBDE04.ent.ti.com>
Message-ID: <20130708132634.GC31221@arwen.pp.htv.fi>

Hi,

On Mon, Jul 08, 2013 at 01:24:49PM +0200, Patel, Satish wrote:

[ big snip ]

> We have two options over here
> 
> Option 1: 
> 
> Defining generic api to which can be mapped over multiple phys
> For smartcard case, I have can thought of following mapping with new 
> generic apis as suggested.
> 
> Smartcard_poweron -> power_on
> Smartcard_powerdown -> power_off
> Smartcard_set_voltage -> phy_set_voltage

these three are generic enough

> Smartcard_activate_card -> phy_activate_slot
> Smartcard_deactivate_card -> phy_deactivate_slot

this looks unnecessary, why can't you always activate the card when you
phy_poweron ?

> Smartcard_set_c4/c8/rst/io -> phy_set_pin

why do you want to control each pin separately ? looks like something we
don't want to allow, in order to prevent users fiddling with the HW
directly.

> Smartcard_warm_reset -> phy_warmreset

phy_reset()

> Smartcard_set_clkdiv -> phy_set_clock
> Smartcard_get_clkdiv -> phy_get_clock

why do you need to control the clock like that ? That should be
something in the clock framework and, hey, it already exists:

clk_set_rate()
clk_get_rate()

> Smartcard_set_atr_mute_timeout -> ??
> Smartcard_set_atr_early_timeout -> ??	
> Smartcard_get_isr_status -> phy_get_status
> Smartcard_get_version -> phy_get_version

these look unnecessary. Why does any other entity need to know about the
PHY version and Interrupt status ?

-- 
balbi
-------------- 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/20130708/f80e2ded/attachment.sig>

From ldewangan at nvidia.com  Mon Jul  8 09:38:08 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 8 Jul 2013 19:08:08 +0530
Subject: [PATCH] ARM: tegra: enable palmas device for dalmore
Message-ID: <1373290688-2257-1-git-send-email-ldewangan@nvidia.com>

Make the entry of Dalmore Power Management Unit device TPS65913
in dalmore DTS file. The Palma driver support this device.

Enable following submodule of the TPS65913:
- GPIO driver
- RTC driver.
- Power regulator driver.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 arch/arm/boot/dts/tegra114-dalmore.dts |  183 +++++++++++++++++++++++++++++++-
 1 files changed, 182 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index 886b66d..53f30c0 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -791,7 +791,7 @@
 					regulator-boot-on;
 				};
 
-				dcdc3 {
+				tps65090_dcdc3_reg: dcdc3 {
 					regulator-name = "vdd-ao";
 					regulator-always-on;
 					regulator-boot-on;
@@ -836,6 +836,177 @@
 				};
 			};
 		};
+
+		palmas: tps65913 at 58 {
+			compatible = "ti,palmas";
+			reg = <0x58>;
+			interrupts = <0 86 0x4>;
+
+			#interrupt-cells = <2>;
+			interrupt-controller;
+
+			palmas_gpio: palmas_gpio {
+				compatible = "ti,palmas-gpio";
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			palmas_rtc {
+				compatible = "ti,palmas-rtc";
+				interrupt-parent = <&palmas>;
+				interrupts = <8 0>;
+			};
+
+			palmas_pmic {
+			    compatible = "ti,tps65913-pmic", "ti,palmas-pmic";
+			    smps1-in-supply = <&tps65090_dcdc3_reg>;
+			    smps3-in-supply = <&tps65090_dcdc3_reg>;
+			    smps4-in-supply = <&tps65090_dcdc2_reg>;
+			    smps7-in-supply = <&tps65090_dcdc2_reg>;
+			    smps8-in-supply = <&tps65090_dcdc2_reg>;
+			    smps9-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo1-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo2-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo3-in-supply = <&palmas_smps3_reg>;
+			    ldo4-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo5-in-supply = <&vdd_ac_bat_reg>;
+			    ldo6-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo7-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo8-in-supply = <&tps65090_dcdc3_reg>;
+			    ldo9-in-supply = <&palmas_smps9_reg>;
+			    ldoln-in-supply = <&tps65090_dcdc1_reg>;
+			    ldousb-in-supply = <&tps65090_dcdc1_reg>;
+			    regulators {
+				smps12 {
+					regulator-name = "vddio-ddr";
+					regulator-min-microvolt = <1350000>;
+					regulator-max-microvolt = <1350000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				palmas_smps3_reg: smps3 {
+					regulator-name = "vddio-1v8";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				smps45 {
+					regulator-name = "vdd-core";
+					regulator-min-microvolt = <900000>;
+					regulator-max-microvolt = <1400000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				smps457 {
+					regulator-name = "vdd-core";
+					regulator-min-microvolt = <900000>;
+					regulator-max-microvolt = <1400000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				smps8 {
+					regulator-name = "avdd-pll";
+					regulator-min-microvolt = <1050000>;
+					regulator-max-microvolt = <1050000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				palmas_smps9_reg: smps9 {
+					regulator-name = "sdhci-vdd-sd-slot";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+					regulator-always-on;
+				};
+
+				ldo1 {
+					regulator-name = "avdd-cam1";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo2 {
+					regulator-name = "avdd-cam2";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo3 {
+					regulator-name = "avdd-dsi-csi";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				ldo4 {
+					regulator-name = "vpp-fuse";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+				};
+
+				ldo6 {
+					regulator-name = "vdd-sensor-2v85";
+					regulator-min-microvolt = <2850000>;
+					regulator-max-microvolt = <2850000>;
+				};
+
+				ldo7 {
+					regulator-name = "vdd-af-cam1";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo8 {
+					regulator-name = "vdd-rtc";
+					regulator-min-microvolt = <900000>;
+					regulator-max-microvolt = <900000>;
+					regulator-always-on;
+					regulator-boot-on;
+					ti,enable-ldo8-tracking;
+				};
+
+				ldo9 {
+					regulator-name = "vddio-sdmmc-2";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldoln {
+					regulator-name = "hvdd-usb";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldousb {
+					regulator-name = "avdd-usb";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				regen1 {
+					regulator-name = "rail-3v3";
+					regulator-max-microvolt = <3300000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				regen2 {
+					regulator-name = "rail-5v0";
+					regulator-max-microvolt = <5000000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+			    };
+			};
+		};
 	};
 
 	spi at 7000da00 {
@@ -951,6 +1122,16 @@
 			gpio = <&gpio TEGRA_GPIO(K, 1) GPIO_ACTIVE_HIGH>;
 			vin-supply = <&tps65090_dcdc1_reg>;
 		};
+
+		vdd_cam_1v8_reg: regulator at 6 {
+			compatible = "regulator-fixed";
+			reg = <6>;
+			regulator-name = "vdd_cam_1v8_reg";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			enable-active-high;
+			gpio = <&palmas_gpio 6 0>; /* Palmas GPIO6 */
+		};
 	};
 
 	sound {
-- 
1.7.1.1



From richard.genoud at gmail.com  Mon Jul  8 09:29:48 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  8 Jul 2013 15:29:48 +0200
Subject: [PATCH v2 0/5] Sound support for at91sam9x5-wm8731 based boards
Message-ID: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>

Hi,

This patchset add sound on the at91sam9x5ek board.
It's based on Nicolas Ferre's work in the 2.6.39 atmel patch for sam9x5:
https://github.com/linux4sam/linux-at91/commit/0aa157c9e71ccccf3abc30fa37eb5c95b392978d

It needs Bo Chen's patchset on the generic dmaengine (topic/atmel branch
on Mark's sound tree) and the SSC interrupts disabled (cf
http://www.spinics.net/lists/arm-kernel/msg256901.html)


Tested on at91sam9g35ek.

patches applies on next-20130708

[I let the original signed-off from Nicolas and Uwe in place, I don't
know if I should replace them by something like "originaly-signed-off-by"
since the code has been changed.]

[Sorry if it's too late for 3.11]

Changes from V1-RFC:
 * drop patches on SSC since Bo Chen already did the work
 * reorder patches to have the machine driver first
 * drop code already handled by the ASoC framework
 * drop unneeded SND_ATMEL_SOC_PDC config selection
 * use static snd_soc_card and  snd_soc_dai_link structures.

Best regards,
Richard.

Nicolas Ferre (1):
  sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards

Richard Genoud (4):
  ARM: AT91: DTS: sam9x5: add SSC DMA parameters
  ARM: AT91: DTS: sam9x5ek: add WM8731 codec
  ARM: AT91: DTS: sam9x5ek: add sound configuration
  ARM: AT91: DTS: sam9x5ek: enable SSC

 arch/arm/boot/dts/at91sam9x5.dtsi   |    3 +
 arch/arm/boot/dts/at91sam9x5ek.dtsi |   27 +++++
 sound/soc/atmel/Kconfig             |   10 ++
 sound/soc/atmel/Makefile            |    2 +
 sound/soc/atmel/sam9x5_wm8731.c     |  206 +++++++++++++++++++++++++++++++++++
 5 files changed, 248 insertions(+)
 create mode 100644 sound/soc/atmel/sam9x5_wm8731.c

-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  8 09:29:50 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  8 Jul 2013 15:29:50 +0200
Subject: [PATCH v2 2/5] ARM: AT91: DTS: sam9x5: add SSC DMA parameters
In-Reply-To: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373290193-25300-3-git-send-email-richard.genoud@gmail.com>

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5.dtsi |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 57d45f5..cf78ac0 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -542,6 +542,9 @@
 				compatible = "atmel,at91sam9g45-ssc";
 				reg = <0xf0010000 0x4000>;
 				interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
+				dmas = <&dma0 1 AT91_DMA_CFG_PER_ID(13)>,
+				       <&dma0 1 AT91_DMA_CFG_PER_ID(14)>;
+				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
 				status = "disabled";
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  8 09:29:52 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  8 Jul 2013 15:29:52 +0200
Subject: [PATCH v2 4/5] ARM: AT91: DTS: sam9x5ek: add sound configuration
In-Reply-To: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373290193-25300-5-git-send-email-richard.genoud@gmail.com>

The sam9x5ek board has 2 jacks:
headphone wired on RHPOUT/LHPOUT of the wm8731
line in wired on LLINEIN/RLINEIN of the wm8731

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index e6fb309..bd0f7b8 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -109,4 +109,22 @@
 			status = "okay";
 		};
 	};
+
+	sound {
+		compatible = "atmel,sam9x5-audio-wm8731";
+
+		atmel,model = "wm8731 @ AT91SAM9X5EK";
+
+		atmel,audio-routing =
+			"Headphone Jack", "RHPOUT",
+			"Headphone Jack", "LHPOUT",
+			"LLINEIN", "Line In Jack",
+			"RLINEIN", "Line In Jack";
+
+		atmel,ssc-controller = <&ssc0>;
+		atmel,audio-codec = <&wm8731>;
+		atmel,format = "i2s";
+		atmel,bitclock-master;
+		atmel,frame-master;
+	};
 };
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  8 09:29:49 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  8 Jul 2013 15:29:49 +0200
Subject: [PATCH v2 1/5] sound: sam9x5_wm8731: machine driver for at91sam9x5
 wm8731 boards
In-Reply-To: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373290193-25300-2-git-send-email-richard.genoud@gmail.com>

From: Nicolas Ferre <nicolas.ferre at atmel.com>

Description of the Asoc machine driver for an at91sam9x5 based board
with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
master on the SSC/I2S interface. Its connections are a headphone jack
and an Line input jack.

[Richard: this is based on an old patch from Nicolas that I forward
ported and reworked to use only device tree]

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 sound/soc/atmel/Kconfig         |   10 ++
 sound/soc/atmel/Makefile        |    2 +
 sound/soc/atmel/sam9x5_wm8731.c |  206 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 218 insertions(+)
 create mode 100644 sound/soc/atmel/sam9x5_wm8731.c

diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 1c0b185..9eb8c49 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -33,6 +33,16 @@ config SND_AT91_SOC_SAM9G20_WM8731
 	  Say Y if you want to add support for SoC audio on WM8731-based
 	  AT91sam9g20 evaluation board.
 
+config SND_AT91_SOC_SAM9X5_WM8731
+	tristate "SoC Audio support for WM8731-based at91sam9x5 board"
+	depends on ATMEL_SSC && SND_ATMEL_SOC && SOC_AT91SAM9X5
+	select SND_ATMEL_SOC_SSC
+	select SND_ATMEL_SOC_DMA
+	select SND_SOC_WM8731
+	help
+	  Say Y if you want to add support for audio SoC on an
+	  at91sam9x5 based board that is using WM8731 codec.
+
 config SND_AT91_SOC_AFEB9260
 	tristate "SoC Audio support for AFEB9260 board"
 	depends on ARCH_AT91 && ATMEL_SSC && ARCH_AT91 && MACH_AFEB9260 && SND_ATMEL_SOC
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index 41967cc..7784c09 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -11,6 +11,8 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
 
 # AT91 Machine Support
 snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
+snd-soc-sam9x5-wm8731-objs := sam9x5_wm8731.o
 
 obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
+obj-$(CONFIG_SND_AT91_SOC_SAM9X5_WM8731) += snd-soc-sam9x5-wm8731.o
 obj-$(CONFIG_SND_AT91_SOC_AFEB9260) += snd-soc-afeb9260.o
diff --git a/sound/soc/atmel/sam9x5_wm8731.c b/sound/soc/atmel/sam9x5_wm8731.c
new file mode 100644
index 0000000..3e5a9f6
--- /dev/null
+++ b/sound/soc/atmel/sam9x5_wm8731.c
@@ -0,0 +1,206 @@
+/*
+ * sam9x5_wm8731   --	SoC audio for AT91SAM9X5-based boards
+ *			that are using WM8731 as codec.
+ *
+ *  Copyright (C) 2011 Atmel,
+ *		  Nicolas Ferre <nicolas.ferre at atmel.com>
+ *
+ * Based on sam9g20_wm8731.c by:
+ * Sedji Gaouaou <sedji.gaouaou at atmel.com>
+ *
+ * GPL
+ */
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/kernel.h>
+#include <linux/clk.h>
+#include <linux/timer.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/i2c.h>
+
+#include <linux/atmel-ssc.h>
+
+#include <sound/core.h>
+#include <sound/pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+
+#include <asm/mach-types.h>
+#include <mach/hardware.h>
+#include <mach/gpio.h>
+
+#include "../codecs/wm8731.h"
+#include "atmel-pcm.h"
+#include "atmel_ssc_dai.h"
+
+#define MCLK_RATE 12288000
+
+#define DRV_NAME "sam9x5-snd-wm8731"
+
+/*
+ * Logic for a wm8731 as connected on a at91sam9x5 based board.
+ */
+static int at91sam9x5ek_wm8731_init(struct snd_soc_pcm_runtime *rtd)
+{
+	struct snd_soc_codec *codec = rtd->codec;
+	struct snd_soc_dai *codec_dai = rtd->codec_dai;
+	struct snd_soc_dapm_context *dapm = &codec->dapm;
+	struct device *dev = rtd->dev;
+	int ret;
+
+	dev_dbg(dev, "ASoC: %s called\n", __func__);
+
+	codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 |
+		SNDRV_PCM_RATE_32000 |
+		SNDRV_PCM_RATE_48000 |
+		SNDRV_PCM_RATE_96000;
+	codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 |
+		SNDRV_PCM_RATE_32000 |
+		SNDRV_PCM_RATE_48000 |
+		SNDRV_PCM_RATE_96000;
+
+	/* set the codec system clock for DAC and ADC */
+	ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
+				     MCLK_RATE, SND_SOC_CLOCK_IN);
+	if (ret < 0) {
+		dev_err(dev, "ASoC: Failed to set WM8731 SYSCLK: %d\n", ret);
+		return ret;
+	}
+
+	/* signal a DAPM event */
+	snd_soc_dapm_sync(dapm);
+	return 0;
+}
+
+/*
+ * Audio paths on at91sam9x5ek board:
+ *
+ *  |A| ------------> |      | ---R----> Headphone Jack
+ *  |T| <----\        |  WM  | ---L--/
+ *  |9| ---> CLK <--> | 8751 | <--R----- Line In Jack
+ *  |1| <------------ |      | <--L--/
+ */
+static const struct snd_soc_dapm_widget at91sam9x5ek_dapm_widgets[] = {
+	SND_SOC_DAPM_HP("Headphone Jack", NULL),
+	SND_SOC_DAPM_LINE("Line In Jack", NULL),
+};
+
+static struct snd_soc_dai_link at91sam9x5ek_dai = {
+	.name = "WM8731",
+	.stream_name = "WM8731 PCM",
+	.codec_dai_name = "wm8731-hifi",
+	.init = at91sam9x5ek_wm8731_init,
+};
+
+static struct snd_soc_card snd_soc_at91sam9x5ek = {
+	.owner = THIS_MODULE,
+	.dai_link = &at91sam9x5ek_dai,
+	.num_links = 1,
+	.dapm_widgets = at91sam9x5ek_dapm_widgets,
+	.num_dapm_widgets = ARRAY_SIZE(at91sam9x5ek_dapm_widgets),
+};
+
+static int sam9x5_wm8731_driver_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *codec_np, *cpu_np;
+	int ret;
+
+	if (!np) {
+		dev_err(&pdev->dev, "No device node supplied\n");
+		return -EINVAL;
+	}
+
+	ret = atmel_ssc_set_audio(0);
+	if (ret != 0) {
+		dev_err(&pdev->dev,
+			"ASoC: Failed to set SSC 0 for audio: %d\n", ret);
+		return ret;
+	}
+
+	snd_soc_at91sam9x5ek.dev = &pdev->dev;
+
+	ret = snd_soc_of_parse_card_name(&snd_soc_at91sam9x5ek, "atmel,model");
+	if (ret)
+		goto out;
+
+	ret = snd_soc_of_parse_audio_routing(&snd_soc_at91sam9x5ek,
+					     "atmel,audio-routing");
+	if (ret)
+		goto out;
+
+	codec_np = of_parse_phandle(np, "atmel,audio-codec", 0);
+	if (!codec_np) {
+		dev_err(&pdev->dev, "codec info missing\n");
+		ret = -EINVAL;
+		goto out;
+	}
+
+	at91sam9x5ek_dai.codec_of_node = codec_np;
+
+	cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
+	if (!cpu_np) {
+		dev_err(&pdev->dev, "ssc controller node missing\n");
+		ret = -EINVAL;
+		goto out;
+	}
+	at91sam9x5ek_dai.cpu_of_node = cpu_np;
+	at91sam9x5ek_dai.platform_of_node = cpu_np;
+
+	of_node_put(codec_np);
+	of_node_put(cpu_np);
+
+	at91sam9x5ek_dai.dai_fmt = snd_soc_of_parse_daifmt(np, "atmel,");
+
+	ret = snd_soc_register_card(&snd_soc_at91sam9x5ek);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"ASoC: Platform device allocation failed\n");
+		goto out;
+	}
+
+	platform_set_drvdata(pdev, &snd_soc_at91sam9x5ek);
+
+	dev_dbg(&pdev->dev, "ASoC: %s ok\n", __func__);
+
+	return ret;
+
+out:
+	atmel_ssc_put_audio(0);
+	return ret;
+}
+
+static int sam9x5_wm8731_driver_remove(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = platform_get_drvdata(pdev);
+
+	snd_soc_unregister_card(card);
+	atmel_ssc_put_audio(0);
+
+	return 0;
+}
+
+static const struct of_device_id sam9x5_wm8731_of_match[] = {
+	{ .compatible = "atmel,sam9x5-audio-wm8731", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sam9x5_wm8731_of_match);
+
+static struct platform_driver sam9x5_wm8731_driver = {
+	.driver = {
+		.name = DRV_NAME,
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(sam9x5_wm8731_of_match),
+	},
+	.probe = sam9x5_wm8731_driver_probe,
+	.remove = sam9x5_wm8731_driver_remove,
+};
+module_platform_driver(sam9x5_wm8731_driver);
+
+/* Module information */
+MODULE_AUTHOR("Nicolas Ferre <nicolas.ferre at atmel.com>");
+MODULE_AUTHOR("Richard Genoud <richard.genoud at gmail.com>");
+MODULE_DESCRIPTION("ALSA SoC machine driver for AT91SAM9x5 - WM8731");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:" DRV_NAME);
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  8 09:29:51 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  8 Jul 2013 15:29:51 +0200
Subject: [PATCH v2 3/5] ARM: AT91: DTS: sam9x5ek: add WM8731 codec
In-Reply-To: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373290193-25300-4-git-send-email-richard.genoud@gmail.com>

The WM8731 codec on sam9x5ek board is on i2c, address 1A

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index d107241..e6fb309 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -59,6 +59,11 @@
 
 			i2c0: i2c at f8010000 {
 				status = "okay";
+
+				wm8731: wm8731 at 1a {
+					compatible = "wm8731";
+					reg = <0x1a>;
+				};
 			};
 
 			pinctrl at fffff400 {
-- 
1.7.10.4



From richard.genoud at gmail.com  Mon Jul  8 09:29:53 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon,  8 Jul 2013 15:29:53 +0200
Subject: [PATCH v2 5/5] ARM: AT91: DTS: sam9x5ek: enable SSC
In-Reply-To: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373290193-25300-6-git-send-email-richard.genoud@gmail.com>

Enable the SSC needed for the WM8731 codec

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index bd0f7b8..6684d4b 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -95,6 +95,10 @@
 			watchdog at fffffe40 {
 				status = "okay";
 			};
+
+			ssc0: ssc at f0010000 {
+				status = "okay";
+			};
 		};
 
 		usb0: ohci at 00600000 {
-- 
1.7.10.4



From linux at roeck-us.net  Mon Jul  8 09:12:47 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 8 Jul 2013 06:12:47 -0700
Subject: [lm-sensors] [PATCH 1/2] ARM: dt: t30 cardhu: add dt entry for
 lm90
In-Reply-To: <51DA6BD4.1040300@nvidia.com>
References: <1372928979-26938-1-git-send-email-wni@nvidia.com>
 <1372928979-26938-2-git-send-email-wni@nvidia.com>
 <51D70483.70203@wwwdotorg.org> <51DA6BD4.1040300@nvidia.com>
Message-ID: <20130708131247.GA21638@roeck-us.net>

On Mon, Jul 08, 2013 at 03:35:48PM +0800, Wei Ni wrote:
> On 07/06/2013 01:38 AM, Stephen Warren wrote:
> > On 07/04/2013 03:09 AM, Wei Ni wrote:
> >> Enable thermal sensor lm90 for t30 cardhu.
> > 
> >> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
> > 
> >> +		nct1008: nct1008 {
> >> +			compatible = "lm90,nct1008";
> > 
> > "lm90" isn't a valid vendor prefix. I believe the value you want is
> > "onnn,nct1008". Same comment for patch 2/2.
> > 
> The lm90 doesn't support device tree very well. In the DT, we need to
> named as "lm90" so that the lm90 driver can be loaded, and we also need
> to add "nct1008" to indicate this is the nct1008 device, so that the
> lm90 driver can be loaded with the right i2c_device_id->driver_data.
> 
> I set the " compatible = "lm90,nct1008" ", this is the simplest way, and
> we doesn't need to change the lm90.c.
> 
Did you really test "onn,nct1008" or, for that matter, "anything,nct1008" ?

I have been using 
	maxim,max1137
	maxim,max1139
	maxim,max6697
	dallas,ds1621
	linear,ltc3880
	linear,ltc2978
	intersil,zl2006
	ti,tmp421
	ti,tmp431

without problems, and without having to add code to the respective drivers.
I would be quite surprised if "onn,nct1008" would not work.

Guenter


From balbi at ti.com  Mon Jul  8 09:35:12 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 8 Jul 2013 16:35:12 +0300
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51DABC81.3080409@ti.com>
References: <51D59146.3070002@newflow.co.uk> <51D59C0E.8080003@newflow.co.uk>
 <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
Message-ID: <20130708133512.GD31221@arwen.pp.htv.fi>

Hi,

On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
> >>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
> >>>>>> of -1 for the serial driver?
> >>>>>>
> >>>>>
> >>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> >>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> >>>
> >>> OK
> >>
> >> Issue 2: Causing boot to stop when serial driver is initialized.
> >> (After Issue 1 is fixed)
> >>
> >> I could narrow this down to the change done to return -EINVAL
> >> instead of 0 in serial_omap_get_context_loss_count() as part of
> >> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
> >> Fix device tree based PM runtime"
> >>
> >> What this change in turn seems to do is cause a
> >> serial_omap_restore_context() to get called as part of
> >> serial_omap_runtime_resume() which was not the case when
> >> serial_omap_get_context_loss_count() returned 0
> >>
> >> from serial_omap_runtime_resume():
> >> -----
> >>         int loss_cnt = serial_omap_get_context_loss_count(up);
> >>
> >>         if (loss_cnt < 0) {
> >>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
> >>                         loss_cnt);
> >>                 serial_omap_restore_context(up);
> >>         } else if (up->context_loss_cnt != loss_cnt) {
> >>                 serial_omap_restore_context(up);
> >>         }
> >> -----
> >>
> >> I am still working on why a serial_omap_restore_context() could
> >> have caused console to die. I will work with Sourav on this and
> >> post the fixes for both issue 1 and issue2 once its clear on whats
> >> really causing issue 2.
> > 
> > That's because we don't have the omap specific pdata callbacks for
> > context loss any longer. We may be able to detect when the context
> > was really lost in the serial driver, and only then call the
> > serial_omap_restore_context().
> 
> Right, but calling serial_omap_restore_context() even when the context
> is not lost, should not ideally cause an issue.

it does in one condition. If context hasn't been saved before. And that
can happen in the case of wrong pm runtime status for that device.

Imagine the device is marked as suspended even though it's fully enabled
(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
your context structure is all zeroes (context has never been saved
before) then when you call pm_runtime_get_sync() on probe() your
->runtime_resume() will get called, which will restore context,
essentially undoing anything which was configured by u-boot.

Am I missing something ?

> >> Let me know if the fix I listed for Issue 1: makes sense.
> > 
> > Yes makes sense as a fix, but IMHO we should not need any workarounds
> > like that. Is the hwmod code idling the the uarts early? If so, then
> > it should only do that in a late_initcall if no drivers are registered.
> 
> hwmod as part of its setup (early) enables/resets and idles all modules.
> These flags are used to tell hwmod to avoid a reset and idle and leave the
> module enabled (in this case console uart)

then it needs to call pm_runtime_set_active() for those devices which
have that flag set, right ?

(completely untested, didn't even try to compile, just to illustrate)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7341eff..d8dca68 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
 	    (postsetup_state == _HWMOD_STATE_IDLE)) {
 		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
 		postsetup_state = _HWMOD_STATE_ENABLED;
+
+		/* tell pm_runtime this device is already active */
+		pm_runtime_set_active(&oh->od->pdev->dev);
+	} else {
+		/* tell pm_runtime this device is trully suspended */
+		pm_runtime_set_suspended(&oh->od->pdev->dev);
 	}
 
 	if (postsetup_state == _HWMOD_STATE_IDLE)

-- 
balbi
-------------- 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/20130708/37396e9a/attachment-0001.sig>

From nicolas.ferre at atmel.com  Mon Jul  8 09:53:43 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 8 Jul 2013 15:53:43 +0200
Subject: [PATCH v2 0/5] Sound support for at91sam9x5-wm8731 based boards
In-Reply-To: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <51DAC467.8060504@atmel.com>

On 08/07/2013 15:29, Richard Genoud :
> Hi,
>
> This patchset add sound on the at91sam9x5ek board.
> It's based on Nicolas Ferre's work in the 2.6.39 atmel patch for sam9x5:
> https://github.com/linux4sam/linux-at91/commit/0aa157c9e71ccccf3abc30fa37eb5c95b392978d
>
> It needs Bo Chen's patchset on the generic dmaengine (topic/atmel branch
> on Mark's sound tree) and the SSC interrupts disabled (cf
> http://www.spinics.net/lists/arm-kernel/msg256901.html)
>
>
> Tested on at91sam9g35ek.
>
> patches applies on next-20130708
>
> [I let the original signed-off from Nicolas and Uwe in place, I don't
> know if I should replace them by something like "originaly-signed-off-by"
> since the code has been changed.]

I am happy to give my "signed-off" to this patch. I guess that Uwe's one 
was more an integration signed-off when he imported the code to his git 
tree.

> [Sorry if it's too late for 3.11]

Do not be sorry. Good work is always appreciated at any time!

> Changes from V1-RFC:
>   * drop patches on SSC since Bo Chen already did the work
>   * reorder patches to have the machine driver first
>   * drop code already handled by the ASoC framework
>   * drop unneeded SND_ATMEL_SOC_PDC config selection
>   * use static snd_soc_card and  snd_soc_dai_link structures.
>
> Best regards,
> Richard.
>
> Nicolas Ferre (1):
>    sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards
>
> Richard Genoud (4):
>    ARM: AT91: DTS: sam9x5: add SSC DMA parameters
>    ARM: AT91: DTS: sam9x5ek: add WM8731 codec
>    ARM: AT91: DTS: sam9x5ek: add sound configuration
>    ARM: AT91: DTS: sam9x5ek: enable SSC

Maybe we will have to split the series and let these DT patches go with 
arm-soc.

>   arch/arm/boot/dts/at91sam9x5.dtsi   |    3 +
>   arch/arm/boot/dts/at91sam9x5ek.dtsi |   27 +++++
>   sound/soc/atmel/Kconfig             |   10 ++
>   sound/soc/atmel/Makefile            |    2 +
>   sound/soc/atmel/sam9x5_wm8731.c     |  206 +++++++++++++++++++++++++++++++++++
>   5 files changed, 248 insertions(+)
>   create mode 100644 sound/soc/atmel/sam9x5_wm8731.c
>

Thanks, bye,
-- 
Nicolas Ferre


From s.nawrocki at samsung.com  Mon Jul  8 10:12:56 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 08 Jul 2013 16:12:56 +0200
Subject: [PATCH v3 12/13] ARM: dts: Add S5K5BA sensor regulator definitions
 for Trats board
In-Reply-To: <11736061.3CXfgF4Q9h@flatron>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
 <1372692155-17653-13-git-send-email-s.nawrocki@samsung.com>
 <11736061.3CXfgF4Q9h@flatron>
Message-ID: <51DAC8E8.2070405@samsung.com>

Hi,

On 07/06/2013 01:26 AM, Tomasz Figa wrote:
> On Monday 01 of July 2013 17:22:34 Sylwester Nawrocki wrote:
>> From: Andrzej Hajda <a.hajda at samsung.com>
>>
>> Add MAX8998 LDO12 and fixed voltage regulator nodes. While at it,
>> all fixed voltage regulator nodes are grouped in a 'regulators' node.
>>
>> Signed-off-by: Andrzej Hajda <a.hajda at samsung.com>
>> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
>> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
>> ---
>>  arch/arm/boot/dts/exynos4210-trats.dts |   80
>> +++++++++++++++++++++++++------- 1 file changed, 64 insertions(+), 16
>> deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
>> b/arch/arm/boot/dts/exynos4210-trats.dts index 6b1568e..f62e299 100644
>> --- a/arch/arm/boot/dts/exynos4210-trats.dts
>> +++ b/arch/arm/boot/dts/exynos4210-trats.dts
>> @@ -30,13 +30,64 @@
>>  		bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 
> rootwait
>> earlyprintk panic=5"; };
>>
>> -	vemmc_reg: voltage-regulator at 0 {
>> -	        compatible = "regulator-fixed";
>> -		regulator-name = "VMEM_VDD_2.8V";
>> -		regulator-min-microvolt = <2800000>;
>> -		regulator-max-microvolt = <2800000>;
>> -		gpio = <&gpk0 2 0>;
>> -		enable-active-high;
>> +	regulators {
>> +		compatible = "simple-bus";
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
> 
> I don't think any addressing is needed for these regulators, so I'd 
> suggest removing those #properties and replacing @N with -N suffix.

Originally there were also 'reg' properties in the individual regulator
nodes, but these were unused and I've removed them before posting. Just
missed to get rid of #size/address-cells as well. Please note you
similarly use such properties in patch [1].

I suppose it is correct to have something like:

regulators {
	compatible = "simple-bus";
	regulator-0 {
		...
	};

	regulator-1 {
		...
	};
	...
};

rather than:

regulators {
	compatible = "simple-bus";
	#address-cells = <1>;
	#size-cells = <0>;

	regulator at 0 {
		reg = <...>;
		...
	};

	regulator at 1 {
		reg = <...>;
		...
	};
};

Both patterns seem to be used in existing *.dts files.

I'm going to use the first option in the next iteration, unless
someone suggest otherwise.

[1] http://www.spinics.net/lists/arm-kernel/msg253184.html

> Otherwise looks good.
> 
> Best regards,
> Tomasz
> 
>> +
>> +		vemmc_reg: regulator at 0 {
>> +			compatible = "regulator-fixed";
>> +			regulator-name = "VMEM_VDD_2.8V";
>> +			regulator-min-microvolt = <2800000>;
>> +			regulator-max-microvolt = <2800000>;
>> +			gpio = <&gpk0 2 0>;
>> +			enable-active-high;
>> +		};
>> +
>> +		tsp_reg: regulator at 1 {
>> +			compatible = "regulator-fixed";
>> +			regulator-name = "TSP_FIXED_VOLTAGES";
>> +			regulator-min-microvolt = <2800000>;
>> +			regulator-max-microvolt = <2800000>;
>> +			gpio = <&gpl0 3 0>;
>> +			enable-active-high;
>> +		};
>> +
>> +		cam_af_28v_reg: regulator at 2 {
>> +			compatible = "regulator-fixed";
>> +			regulator-name = "8M_AF_2.8V_EN";
>> +			regulator-min-microvolt = <2800000>;
>> +			regulator-max-microvolt = <2800000>;
>> +			gpio = <&gpk1 1 0>;
>> +			enable-active-high;
>> +		};
>> +
>> +		cam_io_en_reg: regulator at 3 {
>> +			compatible = "regulator-fixed";
>> +			regulator-name = "CAM_IO_EN";
>> +			regulator-min-microvolt = <2800000>;
>> +			regulator-max-microvolt = <2800000>;
>> +			gpio = <&gpe2 1 0>;
>> +			enable-active-high;
>> +		};
>> +
>> +		cam_io_12v_reg: regulator at 4 {
>> +			compatible = "regulator-fixed";
>> +			regulator-name = "8M_1.2V_EN";
>> +			regulator-min-microvolt = <1200000>;
>> +			regulator-max-microvolt = <1200000>;
>> +			gpio = <&gpe2 5 0>;
>> +			enable-active-high;
>> +		};
>> +
>> +		vt_core_15v_reg: regulator at 5 {
>> +			compatible = "regulator-fixed";
>> +			regulator-name = "VT_CORE_1.5V";
>> +			regulator-min-microvolt = <1500000>;
>> +			regulator-max-microvolt = <1500000>;
>> +			gpio = <&gpe2 2 0>;
>> +			enable-active-high;
>> +		};
>>  	};

Thanks,
Sylwester


From tomasz.figa at gmail.com  Mon Jul  8 10:19:28 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 08 Jul 2013 16:19:28 +0200
Subject: [PATCH v3 12/13] ARM: dts: Add S5K5BA sensor regulator
 definitions for Trats board
In-Reply-To: <51DAC8E8.2070405@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
 <11736061.3CXfgF4Q9h@flatron> <51DAC8E8.2070405@samsung.com>
Message-ID: <5262209.9MjIZ8EmKh@thinkpad>

On Monday 08 of July 2013 16:12:56 Sylwester Nawrocki wrote:
> Hi,
> 
> On 07/06/2013 01:26 AM, Tomasz Figa wrote:
> > On Monday 01 of July 2013 17:22:34 Sylwester Nawrocki wrote:
> >> From: Andrzej Hajda <a.hajda at samsung.com>
> >> 
> >> Add MAX8998 LDO12 and fixed voltage regulator nodes. While at it,
> >> all fixed voltage regulator nodes are grouped in a 'regulators' node.
> >> 
> >> Signed-off-by: Andrzej Hajda <a.hajda at samsung.com>
> >> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> >> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> >> ---
> >> 
> >>  arch/arm/boot/dts/exynos4210-trats.dts |   80
> >> 
> >> +++++++++++++++++++++++++------- 1 file changed, 64 insertions(+), 16
> >> deletions(-)
> >> 
> >> diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
> >> b/arch/arm/boot/dts/exynos4210-trats.dts index 6b1568e..f62e299 100644
> >> --- a/arch/arm/boot/dts/exynos4210-trats.dts
> >> +++ b/arch/arm/boot/dts/exynos4210-trats.dts
> >> @@ -30,13 +30,64 @@
> >> 
> >>  		bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5
> > 
> > rootwait
> > 
> >> earlyprintk panic=5"; };
> >> 
> >> -	vemmc_reg: voltage-regulator at 0 {
> >> -	        compatible = "regulator-fixed";
> >> -		regulator-name = "VMEM_VDD_2.8V";
> >> -		regulator-min-microvolt = <2800000>;
> >> -		regulator-max-microvolt = <2800000>;
> >> -		gpio = <&gpk0 2 0>;
> >> -		enable-active-high;
> >> +	regulators {
> >> +		compatible = "simple-bus";
> >> +		#address-cells = <1>;
> >> +		#size-cells = <0>;
> > 
> > I don't think any addressing is needed for these regulators, so I'd
> > suggest removing those #properties and replacing @N with -N suffix.
> 
> Originally there were also 'reg' properties in the individual regulator
> nodes, but these were unused and I've removed them before posting. Just
> missed to get rid of #size/address-cells as well. Please note you
> similarly use such properties in patch [1].

Oh, you got me here. I must have forgotten to remove them as well.

As we already noticed some time ago, mistakes propagate much faster than 
correct solutions. ;)

> I suppose it is correct to have something like:
> 
> regulators {
> 	compatible = "simple-bus";
> 	regulator-0 {
> 		...
> 	};
> 
> 	regulator-1 {
> 		...
> 	};
> 	...
> };
> 
> rather than:
> 
> regulators {
> 	compatible = "simple-bus";
> 	#address-cells = <1>;
> 	#size-cells = <0>;
> 
> 	regulator at 0 {
> 		reg = <...>;
> 		...
> 	};
> 
> 	regulator at 1 {
> 		reg = <...>;
> 		...
> 	};
> };
> 
> Both patterns seem to be used in existing *.dts files.

Both patterns are correct, I guess. I'm not sure if it makes sense to specify 
address of something that is not addressable and so approach 1 makes more 
sense to me.

> I'm going to use the first option in the next iteration, unless
> someone suggest otherwise.

OK.

Best regards,
Tomasz



From shawn.guo at linaro.org  Mon Jul  8 10:23:01 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Jul 2013 22:23:01 +0800
Subject: [PATCH 1/2] ARM: imx: let L2 initialization be a common function
In-Reply-To: <1373293383-15128-1-git-send-email-shawn.guo@linaro.org>
References: <1373293383-15128-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1373293383-15128-2-git-send-email-shawn.guo@linaro.org>

Move imx6q L2 initialization function imx6q_init_l2cache() into
system.c, and rename it imx_init_l2cache(), so that other platforms
other than imx6q can also use the function.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/mach-imx/common.h     |    6 ++++++
 arch/arm/mach-imx/mach-imx6q.c |   37 +------------------------------------
 arch/arm/mach-imx/system.c     |   33 +++++++++++++++++++++++++++++++++
 3 files changed, 40 insertions(+), 36 deletions(-)

diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index ee78847..32c751d 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -159,6 +159,12 @@ extern int mx51_neon_fixup(void);
 static inline int mx51_neon_fixup(void) { return 0; }
 #endif
 
+#ifdef CONFIG_CACHE_L2X0
+extern void imx_init_l2cache(void);
+#else
+static inline void imx_init_l2cache(void) {}
+#endif
+
 extern struct smp_operations imx_smp_ops;
 
 #endif
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 5d3f76b..400e66b 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -31,7 +31,6 @@
 #include <linux/micrel_phy.h>
 #include <linux/mfd/syscon.h>
 #include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
-#include <asm/hardware/cache-l2x0.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <asm/system_misc.h>
@@ -351,44 +350,10 @@ static void __init imx6q_map_io(void)
 	imx_scu_map_io();
 }
 
-#ifdef CONFIG_CACHE_L2X0
-static void __init imx6q_init_l2cache(void)
-{
-	void __iomem *l2x0_base;
-	struct device_node *np;
-	unsigned int val;
-
-	np = of_find_compatible_node(NULL, NULL, "arm,pl310-cache");
-	if (!np)
-		goto out;
-
-	l2x0_base = of_iomap(np, 0);
-	if (!l2x0_base) {
-		of_node_put(np);
-		goto out;
-	}
-
-	/* Configure the L2 PREFETCH and POWER registers */
-	val = readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
-	val |= 0x70800000;
-	writel_relaxed(val, l2x0_base + L2X0_PREFETCH_CTRL);
-	val = L2X0_DYNAMIC_CLK_GATING_EN | L2X0_STNDBY_MODE_EN;
-	writel_relaxed(val, l2x0_base + L2X0_POWER_CTRL);
-
-	iounmap(l2x0_base);
-	of_node_put(np);
-
-out:
-	l2x0_of_init(0, ~0UL);
-}
-#else
-static inline void imx6q_init_l2cache(void) {}
-#endif
-
 static void __init imx6q_init_irq(void)
 {
 	imx6q_init_revision();
-	imx6q_init_l2cache();
+	imx_init_l2cache();
 	imx_src_init();
 	imx_gpc_init();
 	irqchip_init();
diff --git a/arch/arm/mach-imx/system.c b/arch/arm/mach-imx/system.c
index 7cdc79a..f8211f5 100644
--- a/arch/arm/mach-imx/system.c
+++ b/arch/arm/mach-imx/system.c
@@ -27,6 +27,7 @@
 #include <asm/system_misc.h>
 #include <asm/proc-fns.h>
 #include <asm/mach-types.h>
+#include <asm/hardware/cache-l2x0.h>
 
 #include "common.h"
 #include "hardware.h"
@@ -95,3 +96,35 @@ void __init mxc_arch_reset_init_dt(void)
 
 	clk_prepare(wdog_clk);
 }
+
+#ifdef CONFIG_CACHE_L2X0
+static void __init imx_init_l2cache(void)
+{
+	void __iomem *l2x0_base;
+	struct device_node *np;
+	unsigned int val;
+
+	np = of_find_compatible_node(NULL, NULL, "arm,pl310-cache");
+	if (!np)
+		goto out;
+
+	l2x0_base = of_iomap(np, 0);
+	if (!l2x0_base) {
+		of_node_put(np);
+		goto out;
+	}
+
+	/* Configure the L2 PREFETCH and POWER registers */
+	val = readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
+	val |= 0x70800000;
+	writel_relaxed(val, l2x0_base + L2X0_PREFETCH_CTRL);
+	val = L2X0_DYNAMIC_CLK_GATING_EN | L2X0_STNDBY_MODE_EN;
+	writel_relaxed(val, l2x0_base + L2X0_POWER_CTRL);
+
+	iounmap(l2x0_base);
+	of_node_put(np);
+
+out:
+	l2x0_of_init(0, ~0UL);
+}
+#endif
-- 
1.7.9.5




From shawn.guo at linaro.org  Mon Jul  8 10:23:00 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Jul 2013 22:23:00 +0800
Subject: [PATCH 0/2] Optimize L2 setting on imx6sl
Message-ID: <1373293383-15128-1-git-send-email-shawn.guo@linaro.org>

The series leverages the L2 optimization done on imx6q/dl for imx6sl,
by moving imx6q_init_l2cache() out from mach-imx6q.c into system.c and
renaming it imx_init_l2cache().

Shawn Guo (2):
  ARM: imx: let L2 initialization be a common function
  ARM: imx: use imx specific L2 init function on imx6sl

 arch/arm/mach-imx/common.h      |    6 ++++++
 arch/arm/mach-imx/mach-imx6q.c  |   37 +------------------------------------
 arch/arm/mach-imx/mach-imx6sl.c |    3 +--
 arch/arm/mach-imx/system.c      |   33 +++++++++++++++++++++++++++++++++
 4 files changed, 41 insertions(+), 38 deletions(-)

-- 
1.7.9.5




From shawn.guo at linaro.org  Mon Jul  8 10:23:02 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 8 Jul 2013 22:23:02 +0800
Subject: [PATCH 2/2] ARM: imx: use imx specific L2 init function on imx6sl
In-Reply-To: <1373293383-15128-1-git-send-email-shawn.guo@linaro.org>
References: <1373293383-15128-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1373293383-15128-3-git-send-email-shawn.guo@linaro.org>

The optimized L2 prefect and power setting done in imx_init_l2cache()
can also benefit imx6sl, so let's call the function on imx6sl as well.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/mach-imx/mach-imx6sl.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/mach-imx6sl.c b/arch/arm/mach-imx/mach-imx6sl.c
index 132db260..0d75dc5 100644
--- a/arch/arm/mach-imx/mach-imx6sl.c
+++ b/arch/arm/mach-imx/mach-imx6sl.c
@@ -11,7 +11,6 @@
 #include <linux/irqchip.h>
 #include <linux/of.h>
 #include <linux/of_platform.h>
-#include <asm/hardware/cache-l2x0.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 
@@ -26,7 +25,7 @@ static void __init imx6sl_init_machine(void)
 
 static void __init imx6sl_init_irq(void)
 {
-	l2x0_of_init(0, ~0UL);
+	imx_init_l2cache();
 	imx_src_init();
 	imx_gpc_init();
 	irqchip_init();
-- 
1.7.9.5




From linux at arm.linux.org.uk  Mon Jul  8 10:21:03 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Jul 2013 15:21:03 +0100
Subject: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c
In-Reply-To: <20130708093410.GT5523@atomide.com>
References: <20130517191304.468.73487.stgit@localhost>
 <20130517191751.468.89202.stgit@localhost>
 <20130520095447.GR21614@n2100.arm.linux.org.uk>
 <20130706131057.GU21614@n2100.arm.linux.org.uk>
 <20130706133627.GV21614@n2100.arm.linux.org.uk>
 <20130708093410.GT5523@atomide.com>
Message-ID: <20130708142103.GX21614@n2100.arm.linux.org.uk>

On Mon, Jul 08, 2013 at 02:34:11AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux at arm.linux.org.uk> [130706 06:42]:
> > 
> > Okay, I guessed that the OMAP4430SDP was "blaze" (it's not obvious to
> > use internal codenames for boards when they're known as "SDP" etc -
> > especially when they have stickers on them saying that they're "SDP".)
> 
> Agreed, let's update that.
>  
> > With that worked out, throwing my standard printascii() hack into the
> > kernel results in boot messages... up to the point where the timer is
> > calibrated.  So, it looks like either interrupts, clocks, or the OMAP
> > timers are non-functional with DT based kernels on the SDP board.
> 
> Hey the good news is that you've updated your build system to support
> also appended dtb images, thanks for doing that!

It was far from trivial - there's many places in the build process
which do things quite differently depending on whether it's a DTB
build or not.

> > Any ideas?
> 
> Looks like you need some things updated and added to your .config.
> 
> -# CONFIG_OMAP_MUX is not set
> +CONFIG_MACH_OMAP_GENERIC=y
> 
> That we should nowadays always select though.
> 
> CONFIG_REGULATOR_FIXED_VOLTAGE=y
> 
> This you will need for Ethernet.
> 
> CONFIG_PINCTRL_SINGLE=y
> 
> This is good to have, will be needed especially for for UART
> wake-up events with deeper idle modes enabled once the pending
> pinctrl patches are merged.

That probably explains why there was no output.

> Then there's a pending patch to change drivers/i2c/busses/i2c-omap.c
> to use just a regular module_init, that should remove the i2c timeout
> errors as then deferred probe will work properly.

It seems that - yet again - the mmc devices have swapped themselves.
Also looks like the nonfunctional video stuff is even more nonfunctional
than usual:

omapdss DSI error: can't get VDDS_DSI regulator
omapdss HDMI error: can't get VDDA_HDMI_DAC regulator

ASoC looks dead too:

omap-abe-twl6040 sound.10: ASoC: CPU DAI (null) not registered
omap-abe-twl6040 sound.10: snd_soc_register_card() failed: -517

> BTW, maybe add a link to your build system to www.arm.linux.org.uk
> developer page too? At least I could not find a link to it.

Hmm, I thought I had, but it looks like I never pushed the change to
the main site.  I'll do that at some point.


From broonie at kernel.org  Mon Jul  8 10:36:20 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 8 Jul 2013 15:36:20 +0100
Subject: [alsa-devel] [PATCH v2 3/5] ARM: AT91: DTS: sam9x5ek: add WM8731
 codec
In-Reply-To: <1373290193-25300-4-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373290193-25300-4-git-send-email-richard.genoud@gmail.com>
Message-ID: <20130708143620.GF27646@sirena.org.uk>

On Mon, Jul 08, 2013 at 03:29:51PM +0200, Richard Genoud wrote:
> The WM8731 codec on sam9x5ek board is on i2c, address 1A
> 
> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>

Acked-by: Mark Brown <broonie at linaro.org>

This should go via arm-soc.
-------------- 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/20130708/77e2db73/attachment.sig>

From lars at metafoo.de  Mon Jul  8 10:39:17 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Mon, 08 Jul 2013 16:39:17 +0200
Subject: [alsa-devel] [PATCH v2 1/5] sound: sam9x5_wm8731: machine driver
 for at91sam9x5 wm8731 boards
In-Reply-To: <1373290193-25300-2-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373290193-25300-2-git-send-email-richard.genoud@gmail.com>
Message-ID: <51DACF15.9080303@metafoo.de>

On 07/08/2013 03:29 PM, Richard Genoud wrote:
[...]
> +/*
> + * Logic for a wm8731 as connected on a at91sam9x5 based board.
> + */
> +static int at91sam9x5ek_wm8731_init(struct snd_soc_pcm_runtime *rtd)
> +{
[...]
> +	codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 |
> +		SNDRV_PCM_RATE_32000 |
> +		SNDRV_PCM_RATE_48000 |
> +		SNDRV_PCM_RATE_96000;
> +	codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 |
> +		SNDRV_PCM_RATE_32000 |
> +		SNDRV_PCM_RATE_48000 |
> +		SNDRV_PCM_RATE_96000;

That's not right. The driver structure is shared between all instances of
the codec, a single instance should not modify it. If you need to constrain
the list of supported rates use snd_pcm_hw_constraint_list().

> +
> +	/* set the codec system clock for DAC and ADC */
> +	ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
> +				     MCLK_RATE, SND_SOC_CLOCK_IN);
> +	if (ret < 0) {
> +		dev_err(dev, "ASoC: Failed to set WM8731 SYSCLK: %d\n", ret);
> +		return ret;
> +	}
> +
> +	/* signal a DAPM event */
> +	snd_soc_dapm_sync(dapm);

This should not be necessary.

> +	return 0;
> +}



From thomas.petazzoni at free-electrons.com  Mon Jul  8 10:51:49 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 8 Jul 2013 16:51:49 +0200
Subject: [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <CAErSpo4aodspFnC0uR87yYAgswQQdmU48uoX5NA43UZjbCpOuw@mail.gmail.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-5-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo4aodspFnC0uR87yYAgswQQdmU48uoX5NA43UZjbCpOuw@mail.gmail.com>
Message-ID: <20130708165149.55499b8e@skate>

Dear Bjorn Helgaas,

On Fri, 5 Jul 2013 15:51:10 -0600, Bjorn Helgaas wrote:

> >  int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
> >  {
> > +       struct msi_chip *chip = dev->bus->msi;
> > +
> > +       if (chip && chip->setup_irq) {
> > +               int err;
> > +
> > +               err = chip->setup_irq(chip, dev, desc);
> > +               if (err < 0)
> > +                       return err;
> > +
> > +               irq_set_chip_data(desc->irq, chip);
> > +               return err;
> > +       }
> > +
> >         return -EINVAL;
> 
> It's sub-optimal to indent the whole body of a function like this.  I
> think this is a bit more readable:
> 
>     if (!chip || !chip->setup_irq)
>         return -EINVAL
> 
>     err = chip->setup_irq(...);
>     ...
>     return err;
> 
> The return value of ->setup_irq() (and hence of arch_setup_msi_irq())
> is a bit unclear.  Apparently it can return negative values (errors)
> or positive values (not sure what they mean), or zero (again, not
> sure).  A comment would clear this up.

I've changed ->setup_irq() to simply return 0 on success, and a
negative error code on failure.

Apparently, according to the default implementation
of arch_msi_setup_irqs(), the arch_msi_setup_irq() hook is supposed to
return:
 * A negative value on error, the value being an error code that is
   propagated to the caller.
 * A positive value on some other errors, in which case the -ENOSPC
   error value is returned. To me, it doesn't make a lot of sense, as
   arch_msi_setup_irq() could just as well return -ENOSPC directly.
 * A 0 value on success.

> It might even be worth introducing a no-op chip with pointers to no-op
> functions so we don't have to do these checks ("if (chip &&
> chip->xxx)" everywhere.  I'm not sure if there's a Linux consensus on
> that -- certainly there are many examples of code that *does* make
> these checks everywhere -- so I'll ack it either way.

The problem with this is that I'm not sure where in the PCI code this
association to the default implementation should be done. And there are
also two levels to take into account here:

 * The PCI driver may not specify any msi_chip structure for a
   particular pci_bus. This would have to be detected by the PCI core
   when the bus is registered, and bus->msi would be set to the special
   no-op msi_chip.

 * The PCI driver may specify an msi_chip structure, but without
   necessarily implementation all the methods. This could be solved by
   offering a pci_msi_chip_assign(struct pci_bus *, struct msi_chip *)
   function to be used by PCI drivers to assign their msi_chip to a
   given pci_bus, and this function would fill in the missing msi_chip
   operations with the default implementation.

I am not sure it is really worth doing at this point, but I'm open to
suggestions on this.

> >  int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> >  {
> > +       struct msi_chip *chip = dev->bus->msi;
> > +
> > +       if (chip && chip->check_device)
> > +               return chip->check_device(chip, dev, nvec, type);
> > +
> 
> These functions are poorly named.  They give no clue what
> "check_device" means.  Are we checking that it exists, that it
> supports some property, that it's enabled, ... ?

Well the naming clearly doesn't come from this commit. The
arch_msi_check_device() hook was around before this commit, and the
reason the operation is named ->check_device() is just because it used
the same terminology as the existing arch_msi_check_device() call.

This hook is only used in one place, the PowerPC architecture, in
arch/powerpc/kernel/msi.c, to actually check whether the given device
supports MSI.

I can rename if to arch_msi_device_supports_msi() and
->device_supports_msi(), or arch_msi_device_has_msi() and
->device_has_msi(), but that a change that relatively unrelated to this
commit, I'd say.

Here as well, I'm open to suggestions,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From festevam at gmail.com  Mon Jul  8 11:14:44 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon,  8 Jul 2013 12:14:44 -0300
Subject: [PATCH 2/2] ARM: dts: imx6dl-wandboard: Add support for UART3
In-Reply-To: <1373296484-29847-1-git-send-email-festevam@gmail.com>
References: <1373296484-29847-1-git-send-email-festevam@gmail.com>
Message-ID: <1373296484-29847-2-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Wandboard has a bluetooth device connected to UART3, so add support for it.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/imx6dl-wandboard.dts |  7 +++++++
 arch/arm/boot/dts/imx6dl.dtsi          | 18 ++++++++++++++++++
 2 files changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts b/arch/arm/boot/dts/imx6dl-wandboard.dts
index 027ece5..2654b32 100644
--- a/arch/arm/boot/dts/imx6dl-wandboard.dts
+++ b/arch/arm/boot/dts/imx6dl-wandboard.dts
@@ -108,6 +108,13 @@
 	status = "okay";
 };
 
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart3_2>;
+	fsl,uart-has-rtscts;
+	status = "okay";
+};
+
 &usbh1 {
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index e08c54c..c9850fc 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -232,6 +232,24 @@
 					};
 				};
 
+				uart3 {
+					pinctrl_uart3_1: uart3grp-1 {
+						fsl,pins = <
+							MX6DL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
+							MX6DL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
+						>;
+					};
+
+					pinctrl_uart3_2: uart3grp-2 {
+						fsl,pins = <
+							MX6DL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
+							MX6DL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
+							MX6DL_PAD_EIM_D23__UART3_CTS_B 0x1b0b1
+							MX6DL_PAD_EIM_EB3__UART3_RTS_B 0x1b0b1
+						>;
+					};
+				};
+
 				uart4 {
 					pinctrl_uart4_1: uart4grp-1 {
 						fsl,pins = <
-- 
1.8.1.2



From festevam at gmail.com  Mon Jul  8 11:14:43 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon,  8 Jul 2013 12:14:43 -0300
Subject: [PATCH 1/2] ARM: dts: imx6dl-wandboard: Add SDHC1 and SDHC2 ports
Message-ID: <1373296484-29847-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Wandboard has a SD card slot on the baseboard connected to SDHC1 and a
BCM4329 (Wifi + Bluetooth chip) connected to SDHC2.

Add support for these ports.

While at it, provide the card detect gpio on SDHC3.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/imx6dl-wandboard.dts | 17 +++++++++++++++++
 arch/arm/boot/dts/imx6dl.dtsi          | 29 +++++++++++++++++++++++++++++
 2 files changed, 46 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts b/arch/arm/boot/dts/imx6dl-wandboard.dts
index ab6a053..027ece5 100644
--- a/arch/arm/boot/dts/imx6dl-wandboard.dts
+++ b/arch/arm/boot/dts/imx6dl-wandboard.dts
@@ -83,6 +83,8 @@
 		pinctrl_hog: hoggrp {
 			fsl,pins = <
 				MX6DL_PAD_GPIO_0__CCM_CLKO1    0x130b0
+				MX6DL_PAD_GPIO_2__GPIO1_IO02	0x80000000
+				MX6DL_PAD_EIM_DA9__GPIO3_IO09	0x80000000
 			>;
 		};
 	};
@@ -110,8 +112,23 @@
 	status = "okay";
 };
 
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1_2>;
+	cd-gpios = <&gpio1 2 0>;
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2_2>;
+	non-removable;
+	status = "okay";
+};
+
 &usdhc3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usdhc3_2>;
+	cd-gpios = <&gpio3 9 0>;
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 4505109..e08c54c 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -255,6 +255,35 @@
 					};
 				};
 
+				usdhc1 {
+					pinctrl_usdhc1_1: usdhc1grp-1 {
+						fsl,pins = <
+							MX6DL_PAD_SD1_CMD__SD1_CMD    0x17059
+							MX6DL_PAD_SD1_CLK__SD1_CLK    0x10059
+							MX6DL_PAD_SD1_DAT0__SD1_DATA0 0x17059
+							MX6DL_PAD_SD1_DAT1__SD1_DATA1 0x17059
+							MX6DL_PAD_SD1_DAT2__SD1_DATA2 0x17059
+							MX6DL_PAD_SD1_DAT3__SD1_DATA3 0x17059
+							MX6DL_PAD_NANDF_D0__SD1_DATA4 0x17059
+							MX6DL_PAD_NANDF_D1__SD1_DATA5 0x17059
+							MX6DL_PAD_NANDF_D2__SD1_DATA6 0x17059
+							MX6DL_PAD_NANDF_D3__SD1_DATA7 0x17059
+						>;
+					};
+
+					pinctrl_usdhc1_2: usdhc1grp-2 {
+						fsl,pins = <
+							MX6DL_PAD_SD1_CMD__SD1_CMD    0x17059
+							MX6DL_PAD_SD1_CLK__SD1_CLK    0x10059
+							MX6DL_PAD_SD1_DAT0__SD1_DATA0 0x17059
+							MX6DL_PAD_SD1_DAT1__SD1_DATA1 0x17059
+							MX6DL_PAD_SD1_DAT2__SD1_DATA2 0x17059
+							MX6DL_PAD_SD1_DAT3__SD1_DATA3 0x17059
+						>;
+					};
+				};
+
+
 				usdhc2 {
 					pinctrl_usdhc2_1: usdhc2grp-1 {
 						fsl,pins = <
-- 
1.8.1.2



From dinguyen at altera.com  Mon Jul  8 11:22:10 2013
From: dinguyen at altera.com (Dinh Nguyen)
Date: Mon, 8 Jul 2013 10:22:10 -0500
Subject: socfpga: mmc problems
In-Reply-To: <51D532D2.1030709@communistcode.co.uk>
References: <51D43CB0.4070104@communistcode.co.uk>
 <1372864190.9525.6.camel@linux-builds1>
 <51D532D2.1030709@communistcode.co.uk>
Message-ID: <1373296930.22692.2.camel@linux-builds1>

Hi Jack,

On Thu, 2013-07-04 at 09:31 +0100, Jack Mitchell wrote:
> Morning Dinh,
> 
> On 03/07/13 16:09, Dinh Nguyen wrote:
> > Hi Jack,
> >
> > On Wed, 2013-07-03 at 16:01 +0100, Jack Mitchell wrote:
> >> Having received one of the new Arrow SoCkit boards at a recent training
> >> day I set about seeing how far mainline was in successfully booting this
> >> board.
> >>
> >> As I wanted to boot from mmc, I first checked out linux-next [1] in
> >> order to get the newly merged mmc driver, I then applied the device-tree
> >> enablement series [2] on top before finally attempting to boot. I then
> >> found that the standard socfpga_defconfig didn't enable the MMC drivers,
> >> which I also did (should this be part of the socfpga_defconfig...?).
> >
> > I was going to update this when I enable ethernet as well to avoid less
> > churn on the defconfig.
> 
> That's great!
> 
> >
> >>
> >> However, the boot hangs at:
> >>
> >> Synopsys Designware Multimedia Card Interface Driver
> >> dwmmc_socfpga ff704000.dwmmc0: Using internal DMA controller.
> >> dwmmc_socfpga ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host
> >> data width, 1024 deep fifo
> >>
> >> To fix this I checked out the diff between the Altera vendor mmc driver
> >> and the mainline driver and found that if I added this small change:
> >>
> >>
> >>     if (of_property_read_u32(dev->of_node, "pwr-en", &pwr_en)) {
> >>       dev_info(dev, "couldn't determine pwr-en, assuming pwr-en = 0\n");
> >>       pwr_en = 0;
> >>     }
> >>
> >>     /* Set PWREN bit */
> >>     mci_writel(host, PWREN, pwr_en);
> >
> > I tested this on my devkit, which was not made by Arrow, but is _almost_
> > the same. I'll try to see if I can get my hands on an Arrow board to
> > reproduce.
> 
> Now, I think I made a _slight_ mistake, in that I accidentally copied 
> the Altera vendor kernel onto the sdcard instead of the linux-next 
> kernel. Re-testing this morning with a fresh mind, I checked the config 
> again and now I find the Arrow board still won't boot from MMC, even 
> with the above change, with the code hanging at the same place.
> 
> I know you don't have an Arrow board, but if you have a tree which I 
> could pull from with your amalgamated changes; that would rule out me 
> missing any patches and it actually being a board problem. I can't seem 
> to see if the V8 device tree patches were pulled into anyones tree, 
> otherwise I would just wait till they appeared in 3.11-rc1...?

Unfortunately, the device tree bindings for the SD/MMC did not make it
into the arm-soc tree for 3.11, only the sd/mmc platform driver. Will
try for 3.12.

I'm sure you have seen git.rocketboards.org?

Dinh
> 
> Sorry for the confusion!
> 
> >
> >>
> >> In the dw_mci_socfpga_priv_init function, the board would boot.
> >>
> >> Synopsys Designware Multimedia Card Interface Driver
> >> dwmmc_socfpga ff704000.dwmmc0: couldn't determine pwr-en, assuming
> >> pwr-en = 0
> >> dwmmc_socfpga ff704000.dwmmc0: Using internal DMA controller.
> >> dwmmc_socfpga ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host
> >> data width, 1024 deep fifo
> >> mmc_host mmc0: Bus speed (slot 0) = 100000000Hz (slot req 400000Hz,
> >> actual 400000HZ div = 125)
> >> dwmmc_socfpga ff704000.dwmmc0: 1 slots initialized
> >> dwmmc_socfpga ff704000.dwmmc0: Version ID is 240a
> >> .....
> >> .....
> >> .....
> >>
> >>
> >> Has this been overlooked, or are there some other changes elsewhere that
> >> I haven't yet come across which addresses this?
> >
> > I'm not aware of any other changes.
> >
> > Dinh
> >>
> >> Cheers,
> >>
> >> [1] fa1383200d289afdff2f5678eb89483daa537465
> >> [2] http://comments.gmane.org/gmane.linux.ports.arm.kernel/243529
> >>
> >
> >
> >
> 
> 





From jason at lakedaemon.net  Mon Jul  8 11:28:05 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 8 Jul 2013 11:28:05 -0400
Subject: managing out-of-tree deps for arm-soc in a single window was: Re:
 [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer
In-Reply-To: <alpine.DEB.2.02.1307081041290.32106@ionos.tec.linutronix.de>
References: <51B8D310.4050404@linaro.org> <51D9548B.9040907@gmail.com>
 <alpine.DEB.2.02.1307071508030.32106@ionos.tec.linutronix.de>
 <20130707144645.GA11908@titan.lakedaemon.net>
 <alpine.DEB.2.02.1307071723220.32106@ionos.tec.linutronix.de>
 <20130707235819.GB11908@titan.lakedaemon.net>
 <alpine.DEB.2.02.1307081041290.32106@ionos.tec.linutronix.de>
Message-ID: <20130708152805.GD11908@titan.lakedaemon.net>

On Mon, Jul 08, 2013 at 10:45:47AM +0200, Thomas Gleixner wrote:
> On Sun, 7 Jul 2013, Jason Cooper wrote:
> > On Sun, Jul 07, 2013 at 05:30:31PM +0200, Thomas Gleixner wrote:
> > I don't mind delaying half of a series so the drivers/ portion can land
> > in mainline, and the rest can land in the next cycle.  But when things
> > don't go according to that plan, I'd like a little consideration /
> > flexibility about solving the problem.  Especially considering I'm
> > *trying* to do the right thing by pushing to appropriate maintainers
> > first.
> > 
> > Of course, this is a moot point since, as you clarified above, this
> > dependency doesn't have the hazards typically associated with
> > out-of-tree dependencies.
> 
> There is a very simple procedure for stuff like this.
> 
> Series has parts which go through tree A and B and another larger part
> for tree C which depends on the A and B parts.
> 
> So ask the maintainers of A and B to apply this to separate branches,
> which are based on some commit in Linus tree. These branches can be
> pulled into C and C can apply the depending stuff on top.
> 
> Now the maintainers of A and B merge these branches into their main
> devel branch, can do further fixups and stuff on top. And the whole
> thing just works without glitches during the merge window.
> 
> We do this all the time.

Wow, I wish I had known this (or thought of it) months ago!  Thanks for
taking the time to explain it to me.

Arnd, Olof,

Does this address your concerns about out of tree dependencies?  I think
it does, but I'm not the one who has to manage it after I set it up and
send the PR...

thx,

Jason.


From u.kleine-koenig at pengutronix.de  Mon Jul  8 11:29:17 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Mon, 8 Jul 2013 17:29:17 +0200
Subject: [PATCH] ARM: ARMv7-M: Fix name of NVIC handler function
In-Reply-To: <1372238855-26112-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1372238855-26112-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <20130708152917.GE29556@pengutronix.de>

Hi Russell,

On Wed, Jun 26, 2013 at 11:27:35AM +0200, Uwe Kleine-K?nig wrote:
> The name changed in response to review comments for the nvic irqchip
> driver when the original name was already accepted into Russell King's
> tree.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
> Hello,
> 
> this patch was part of the irqchip patch v4, but I split it out for
> being easier to merge in v5. It applies on top of Russell's devel-stable
> branch.
> 
> Russell: I put it on top of my for-next branch (
> 
> 	git://git.pengutronix.de/git/ukl/linux.git for-next
> 
> ) that you merged into your devel-stable some time ago. So assuming
> you're fine with the patch, you can just repull or I can put it into
> your patch tracker if you prefer it. In the latter case please tell me.
The mismatch hit Linus' tree now. How should this patch get to him?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From sboyd at codeaurora.org  Mon Jul  8 11:35:29 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 8 Jul 2013 08:35:29 -0700
Subject: [GIT PULL] Remove ARM local timer API
In-Reply-To: <20130628000853.GB11547@quad.lixom.net>
References: <20130625200211.GA11625@codeaurora.org>
 <20130628000853.GB11547@quad.lixom.net>
Message-ID: <20130708153528.GB830@codeaurora.org>

On 06/27, Olof Johansson wrote:
> On Tue, Jun 25, 2013 at 01:02:12PM -0700, Stephen Boyd wrote:
> > Olof/Arnd,
> > 
> > These patches remove the ARM local timer API. The ARM architected
> > timers have already moved away from this API so this series
> > migrates the rest of the users allowing us to remove the API
> > entirely. Thomas has been kind enough to take the first two
> > patches into timers/core in the tip tree (thanks Thomas!) so I've
> > merged that into v3.10-rc1 and then applied the rest of the
> > patches on top. Let me know if this is acceptable.
> 
> We need guarantees from Thomas that the branch is stable and will never be
> rebased before it hit Linus tree, or we'll be in a world of pain for
> dependencies like these.
> 
> Thomas, is this branch stable or do you anticipate a rebase?
> 

This branch has merged into Linus' tree. Can this go through the
arm-soc tree now?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From swarren at wwwdotorg.org  Mon Jul  8 11:51:08 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 08 Jul 2013 09:51:08 -0600
Subject: [PATCH V2] ARM: tegra: enable gpio-keys on dalmore
In-Reply-To: <1373102069-5641-1-git-send-email-ldewangan@nvidia.com>
References: <1373102069-5641-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <51DADFEC.1050901@wwwdotorg.org>

On 07/06/2013 03:14 AM, Laxman Dewangan wrote:
> Dalmore have the keys mounted on board which are connected
> to different pins of Tegra.
> 
> Add the keys entry in DTS file to enable key functionality.
> This will enable KEY_POWER, KEY_HOME, KEY_VOLUMEUP and
> KEY_VOLUMEDOWN.

> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts

> @@ -976,4 +1005,5 @@
>  			 <&tegra_car TEGRA114_CLK_EXTERN1>;
>  		clock-names = "pll_a", "pll_a_out0", "mclk";
>  	};
> +
>  };

What's that? I'll try to remember to fix this up when applying, but
proof-reading would help.


From ml at communistcode.co.uk  Mon Jul  8 12:00:43 2013
From: ml at communistcode.co.uk (Jack Mitchell)
Date: Mon, 08 Jul 2013 17:00:43 +0100
Subject: socfpga: mmc problems
In-Reply-To: <1373296930.22692.2.camel@linux-builds1>
References: <51D43CB0.4070104@communistcode.co.uk>
 <1372864190.9525.6.camel@linux-builds1>
 <51D532D2.1030709@communistcode.co.uk>
 <1373296930.22692.2.camel@linux-builds1>
Message-ID: <51DAE22B.6000201@communistcode.co.uk>

Hi Dinh,

On 08/07/13 16:22, Dinh Nguyen wrote:
> Hi Jack,
>
> On Thu, 2013-07-04 at 09:31 +0100, Jack Mitchell wrote:
>> Morning Dinh,
>>
>> On 03/07/13 16:09, Dinh Nguyen wrote:
>>> Hi Jack,
>>>
>>> On Wed, 2013-07-03 at 16:01 +0100, Jack Mitchell wrote:
>>>> Having received one of the new Arrow SoCkit boards at a recent training
>>>> day I set about seeing how far mainline was in successfully booting this
>>>> board.
>>>>
>>>> As I wanted to boot from mmc, I first checked out linux-next [1] in
>>>> order to get the newly merged mmc driver, I then applied the device-tree
>>>> enablement series [2] on top before finally attempting to boot. I then
>>>> found that the standard socfpga_defconfig didn't enable the MMC drivers,
>>>> which I also did (should this be part of the socfpga_defconfig...?).
>>>
>>> I was going to update this when I enable ethernet as well to avoid less
>>> churn on the defconfig.
>>
>> That's great!
>>
>>>
>>>>
>>>> However, the boot hangs at:
>>>>
>>>> Synopsys Designware Multimedia Card Interface Driver
>>>> dwmmc_socfpga ff704000.dwmmc0: Using internal DMA controller.
>>>> dwmmc_socfpga ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host
>>>> data width, 1024 deep fifo
>>>>
>>>> To fix this I checked out the diff between the Altera vendor mmc driver
>>>> and the mainline driver and found that if I added this small change:
>>>>
>>>>
>>>>      if (of_property_read_u32(dev->of_node, "pwr-en", &pwr_en)) {
>>>>        dev_info(dev, "couldn't determine pwr-en, assuming pwr-en = 0\n");
>>>>        pwr_en = 0;
>>>>      }
>>>>
>>>>      /* Set PWREN bit */
>>>>      mci_writel(host, PWREN, pwr_en);
>>>
>>> I tested this on my devkit, which was not made by Arrow, but is _almost_
>>> the same. I'll try to see if I can get my hands on an Arrow board to
>>> reproduce.
>>
>> Now, I think I made a _slight_ mistake, in that I accidentally copied
>> the Altera vendor kernel onto the sdcard instead of the linux-next
>> kernel. Re-testing this morning with a fresh mind, I checked the config
>> again and now I find the Arrow board still won't boot from MMC, even
>> with the above change, with the code hanging at the same place.
>>
>> I know you don't have an Arrow board, but if you have a tree which I
>> could pull from with your amalgamated changes; that would rule out me
>> missing any patches and it actually being a board problem. I can't seem
>> to see if the V8 device tree patches were pulled into anyones tree,
>> otherwise I would just wait till they appeared in 3.11-rc1...?
>
> Unfortunately, the device tree bindings for the SD/MMC did not make it
> into the arm-soc tree for 3.11, only the sd/mmc platform driver. Will
> try for 3.12.
>
> I'm sure you have seen git.rocketboards.org?

Yes, I have the 3.9 rocketboards kernel compiling and working so I'm not 
stuck; just interested in keeping up to date with how mainline is 
progressing and helping with testing (and nit picking!).

Cheers,
Jack.

>
> Dinh
>>
>> Sorry for the confusion!
>>
>>>
>>>>
>>>> In the dw_mci_socfpga_priv_init function, the board would boot.
>>>>
>>>> Synopsys Designware Multimedia Card Interface Driver
>>>> dwmmc_socfpga ff704000.dwmmc0: couldn't determine pwr-en, assuming
>>>> pwr-en = 0
>>>> dwmmc_socfpga ff704000.dwmmc0: Using internal DMA controller.
>>>> dwmmc_socfpga ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host
>>>> data width, 1024 deep fifo
>>>> mmc_host mmc0: Bus speed (slot 0) = 100000000Hz (slot req 400000Hz,
>>>> actual 400000HZ div = 125)
>>>> dwmmc_socfpga ff704000.dwmmc0: 1 slots initialized
>>>> dwmmc_socfpga ff704000.dwmmc0: Version ID is 240a
>>>> .....
>>>> .....
>>>> .....
>>>>
>>>>
>>>> Has this been overlooked, or are there some other changes elsewhere that
>>>> I haven't yet come across which addresses this?
>>>
>>> I'm not aware of any other changes.
>>>
>>> Dinh
>>>>
>>>> Cheers,
>>>>
>>>> [1] fa1383200d289afdff2f5678eb89483daa537465
>>>> [2] http://comments.gmane.org/gmane.linux.ports.arm.kernel/243529
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>


-- 

   Jack Mitchell (jack at embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--


From ohaugan at codeaurora.org  Mon Jul  8 12:20:25 2013
From: ohaugan at codeaurora.org (Olav Haugan)
Date: Mon, 08 Jul 2013 09:20:25 -0700
Subject: [PATCH] documentation: iommu: add description of ARM System MMU
 binding
In-Reply-To: <20130513090724.GA10369@alberich>
References: <20130408092535.GA17476@mudshark.cambridge.arm.com>
 <5162F87A.7070409@codeaurora.org>
 <20130410173732.GQ26992@mudshark.cambridge.arm.com>
 <5169C7D1.8070300@codeaurora.org>
 <20130415131341.GG9827@mudshark.cambridge.arm.com>
 <516D9602.2010404@codeaurora.org>
 <20130418190131.GA12344@mudshark.cambridge.arm.com>
 <5177113D.7060300@codeaurora.org>
 <20130424095501.GC21850@mudshark.cambridge.arm.com>
 <5189635A.8090504@codeaurora.org> <20130513090724.GA10369@alberich>
Message-ID: <51DAE6C9.1000106@codeaurora.org>

Hi Andreas,

On 5/13/2013 2:07 AM, Andreas Herrmann wrote:
> On Tue, May 07, 2013 at 04:26:02PM -0400, Olav Haugan wrote:
>>
>>>>> If a master needs to be in two address spaces at once, then it will need to
>>>>> attach it's StreamIDs to different domains. You can't place a single
>>>>> StreamID in two address spaces (this is an architectural constraint).
>>>>
>>>> Yes, you would have a separate domain. I am just wondering how I would
>>>> model this in DT using the bindings that you are proposing? How does it
>>>> work? The bindings specify bus masters to StreamIDs. So if I call attach
>>>> with the master device you will allocate a context bank and program the
>>>> StreamIDs as specified in the DT. So now if I want to have another
>>>> context bank associated with the same master device what do I do? I call
>>>> into attach with a new domain but with the same master device but the
>>>> master device is already attached to a context/domain.
>>>
>>> Why would you want to place a StreamID into two domains? That doesn't make
>>> any sense and isn't even supported by the architecture (things like
>>> conflicting SMR entries may not even be reported).
>>
>> I think you misunderstood me. I am talking about having for example 1
>> master with two (2) context banks so that StreamID "1" goes to CB0 and
>> StreamID "2" goes to CB1. This means that the master device is attached
>> to two different domains. How do I model this with the the device tree
>> bindings?
> 
> Hi Olav,
> 
> I think with the proposed device tree binding you can't model this.
> 
> Do we have such use cases already? Or what future use cases would
> require this?
> 
> I can imagine of multiple contexts per device for stuff similar to
> what PASID in PCI Express are used for.
> 
> But in such a case you probably want to have some configurable bits in
> the StreamID (that should be set by an SMMU driver). And the DT
> binding should contain the number of contexts that a master device can
> support.
> 

Sorry for the late reply.

The only real use case at this time for a master having more than 1 CB
is for content protection I believe. I understand that this driver does
not currently support content protection or anything related to security.

Thanks,

Olav Haugan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From broonie at kernel.org  Mon Jul  8 11:07:56 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 8 Jul 2013 16:07:56 +0100
Subject: [PATCH v2 2/5] ARM: AT91: DTS: sam9x5: add SSC DMA parameters
In-Reply-To: <1373290193-25300-3-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373290193-25300-3-git-send-email-richard.genoud@gmail.com>
Message-ID: <20130708150756.GL27646@sirena.org.uk>

On Mon, Jul 08, 2013 at 03:29:50PM +0200, Richard Genoud wrote:
> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
> ---
>  arch/arm/boot/dts/at91sam9x5.dtsi |    3 +++

There was no binding document in your first patch - there should be one
for any new DT bindings.
-------------- 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/20130708/c0d916e9/attachment.sig>

From soren.brinkmann at xilinx.com  Mon Jul  8 12:27:40 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Mon, 8 Jul 2013 09:27:40 -0700
Subject: [PATCH] clocksource/cadence_ttc: Reuse clocksource as sched_clock
In-Reply-To: <alpine.DEB.2.02.1307051819530.32106@ionos.tec.linutronix.de>
References: <1372888216-10726-1-git-send-email-soren.brinkmann@xilinx.com>
 <alpine.DEB.2.02.1307050819000.11637@ionos.tec.linutronix.de>
 <fbeb6f36-f07a-4518-b6f2-0b8e36028fe9@CH1EHSMHS012.ehs.local>
 <alpine.DEB.2.02.1307051802560.32106@ionos.tec.linutronix.de>
 <e55e70b7-7e63-4718-ad48-f5d4479b5326@DB9EHSMHS006.ehs.local>
 <alpine.DEB.2.02.1307051819530.32106@ionos.tec.linutronix.de>
Message-ID: <ad28a9ee-541e-4b28-8b4e-9ebb2e1c4283@TX2EHSMHS015.ehs.local>

On Fri, Jul 05, 2013 at 06:23:19PM +0200, Thomas Gleixner wrote:
> On Fri, 5 Jul 2013, S?ren Brinkmann wrote:
> > On Fri, Jul 05, 2013 at 06:05:14PM +0200, Thomas Gleixner wrote:
> > > On Fri, 5 Jul 2013, S?ren Brinkmann wrote:
> > > > On Fri, Jul 05, 2013 at 08:30:47AM +0200, Thomas Gleixner wrote:
> > > > > On Wed, 3 Jul 2013, Soren Brinkmann wrote:
> > > > > 
> > > > > > Reuse the TTC clocksource timer as sched clock, too. Since only a single
> > > > > > sched clock is supported in Linux, this feature optional and can be
> > > > > > selected through Kconfig.
> > > > > 
> > > > > This changelog doesn't make sense.
> > > > > 
> > > > > There can be only one active sched_clock, but that does no mean, that
> > > > > you cannot have different implementations compiled in.
> > > > > 
> > > > > So if you disable this config which sched_clock is your kernel using?
> > > > Jiffies
> > > > 
> > > > > And if you enable it, how is guaranteed that you end up with the ttc
> > > > > sched_clock as the active one? Just due to initcall ordering?
> > > > I assumed so. Is there a different mechanism?
> > > 
> > > jiffies is the default one. If you setup an explicit sched clock then
> > > this is used. initcall ordering only matters if you have two possible
> > > sched clocks which might replace jiffies. The one which gets
> > > registered last wins.
> > > 
> > > So the question is, why you want to disable your sched clock at
> > > compile time.
> > The timer drivers I have seen unconditionally register themselves as
> > sched_clock. There does not seem to be a runtime mechanism to choose the
> > best one - I might miss it though.
> > I was thinking about this due to the arm_global_timer driver which has
> > been dicussed on lkml recently, which seemed to do it this way too. And since
> > that timer would be an alternative sched_clock for Zynq too, I thought I
> > follow the same approach for the TTC.
> 
> Hmm, ok. So there is a generic one as well. If we end up with multiple
> choices for that sched_clock, then there should be a mechanism to
> avoid that #ifdeffery and have it runtime selected.
> 
> Having a setup call with a rating argument would be a first step. So
> the one with the highest rating wins. If people want to have it
> selectable from the kernel commandline, it would need some string
> matching as well.
I revisited the code:
My original reason for adding the Kconfig option was that I hit this
warning when I had multiple sched_clock providers:
	arch/arm/kernel/sched_clock.c:setup_sched_clock():
		WARN_ON(read_sched_clock != jiffy_sched_clock_read);

That code is gone in the lates Linux tree.

Furthermore the now used setup_sched_clock routine, only updates the
sched clock provider, if the new one is faster than the old one:
	if (cd.rate > rate)                                                      
                return;

Which is good enough in terms of a rating mechanism, at least for this case.

So, I'll remove all the #ifdefs and Kconfig stuff and send a v2.

	S?ren




From ohaugan at codeaurora.org  Mon Jul  8 12:34:23 2013
From: ohaugan at codeaurora.org (Olav Haugan)
Date: Mon, 08 Jul 2013 09:34:23 -0700
Subject: [PATCH v2 2/3] iommu: add support for ARM Ltd. System MMU
 architecture
In-Reply-To: <1372095086-15681-3-git-send-email-will.deacon@arm.com>
References: <1372095086-15681-1-git-send-email-will.deacon@arm.com>
 <1372095086-15681-3-git-send-email-will.deacon@arm.com>
Message-ID: <51DAEA0F.2030808@codeaurora.org>

On 6/24/2013 10:31 AM, Will Deacon wrote:
> This patch adds support for SMMUs implementing the ARM System MMU
> architecture versions 1 or 2. Both arm and arm64 are supported, although
> the v7s descriptor format is not used.
> 
> Cc: Rob Herring <robherring2 at gmail.com>
> Cc: Andreas Herrmann <andreas.herrmann at calxeda.com>
> Cc: Olav Haugan <ohaugan at codeaurora.org>
> Cc: Joerg Roedel <joro at 8bytes.org>
> Signed-off-by: Will Deacon <will.deacon at arm.com>
> ---
> +/* Maximum number of stream IDs assigned to a single device */
> +#define MAX_MASTER_STREAMIDS		8
> +

Hi Will,

We have designs that require more than 8 Stream IDs. Instead of hard
coding it to max of 8 can you make this dynamic?

Thanks,

Olav Haugan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From jgunthorpe at obsidianresearch.com  Mon Jul  8 12:42:25 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Mon, 8 Jul 2013 10:42:25 -0600
Subject: [PATCH v6 00/21] MBus DT binding: PCIe strikes back
In-Reply-To: <201307060138.36191.arnd@arndb.de>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130706013547.3ce7280b@skate> <201307060138.36191.arnd@arndb.de>
Message-ID: <20130708164225.GA26618@obsidianresearch.com>

On Sat, Jul 06, 2013 at 01:38:35AM +0200, Arnd Bergmann wrote:
> On Saturday 06 July 2013, Thomas Petazzoni wrote:
> > Arnd, Jason, if you could confirm that you both agree with this DT
> > binding soon, Ezequiel and I would quickly adapt the code accordingly,
> > and hopefully converge towards a final patch set.
> 
> Looks all good from what I can tell.

It also looks fine to me.

Regards,
Jsaon


From soren.brinkmann at xilinx.com  Mon Jul  8 12:51:37 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Mon,  8 Jul 2013 09:51:37 -0700
Subject: [PATCH v2 1/2] clocksource/cadence_ttc: Remove unused header
In-Reply-To: <1373302298-27957-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1373302298-27957-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <1373302298-27957-2-git-send-email-soren.brinkmann@xilinx.com>

The clk-provider.h header is not required by this driver.

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
---
 drivers/clocksource/cadence_ttc_timer.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/clocksource/cadence_ttc_timer.c b/drivers/clocksource/cadence_ttc_timer.c
index 4cbe28c..0eefc8d 100644
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@ -21,7 +21,6 @@
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 #include <linux/slab.h>
-#include <linux/clk-provider.h>
 
 /*
  * This driver configures the 2 16-bit count-up timers as follows:
-- 
1.8.3.2



From soren.brinkmann at xilinx.com  Mon Jul  8 12:51:38 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Mon,  8 Jul 2013 09:51:38 -0700
Subject: [PATCH v2 2/2] clocksource/cadence_ttc: Reuse clocksource as
 sched_clock
In-Reply-To: <1373302298-27957-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1373302298-27957-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <1373302298-27957-3-git-send-email-soren.brinkmann@xilinx.com>

Reuse the TTC clocksource timer as sched clock provider.

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
---
v2:
 - #include linux/sched_clock.h instead of asm/sched_clock.h
 - remove Kconfig options and #ifdefs around sched_clock related code
    The reasons for having those are obsolete, since ARM deprecated its
    custom sched_clock framework and migrated to the common one.

 drivers/clocksource/cadence_ttc_timer.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/clocksource/cadence_ttc_timer.c b/drivers/clocksource/cadence_ttc_timer.c
index 0eefc8d..b2bb3a4b 100644
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@ -21,6 +21,7 @@
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 #include <linux/slab.h>
+#include <linux/sched_clock.h>
 
 /*
  * This driver configures the 2 16-bit count-up timers as follows:
@@ -94,6 +95,8 @@ struct ttc_timer_clockevent {
 #define to_ttc_timer_clkevent(x) \
 		container_of(x, struct ttc_timer_clockevent, ce)
 
+static void __iomem *ttc_sched_clock_val_reg;
+
 /**
  * ttc_set_interval - Set the timer interval value
  *
@@ -155,6 +158,11 @@ static cycle_t __ttc_clocksource_read(struct clocksource *cs)
 				TTC_COUNT_VAL_OFFSET);
 }
 
+static u32 notrace ttc_sched_clock_read(void)
+{
+	return __raw_readl(ttc_sched_clock_val_reg);
+}
+
 /**
  * ttc_set_next_event - Sets the time interval for next event
  *
@@ -296,6 +304,10 @@ static void __init ttc_setup_clocksource(struct clk *clk, void __iomem *base)
 		kfree(ttccs);
 		return;
 	}
+
+	ttc_sched_clock_val_reg = base + TTC_COUNT_VAL_OFFSET;
+	setup_sched_clock(ttc_sched_clock_read, 16,
+			clk_get_rate(ttccs->ttc.clk) / PRESCALE);
 }
 
 static int ttc_rate_change_clockevent_cb(struct notifier_block *nb,
-- 
1.8.3.2



From soren.brinkmann at xilinx.com  Mon Jul  8 12:51:36 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Mon,  8 Jul 2013 09:51:36 -0700
Subject: [PATCH v2 0/2] clocksource/cadence_ttc: Add sched_clock functionality
Message-ID: <1373302298-27957-1-git-send-email-soren.brinkmann@xilinx.com>

I updated the original patch according to the discussion with Thomas and Baruch.
Furthermore, I noticed that the driver includes the clk-provider header for no
apparent reason and removed it.

	S?ren

v2:
 - adding patch to remove unused header to the series
 - #include linux/sched_clock.h instead of asm/sched_clock.h
 - remove Kconfig options and #ifdefs around sched_clock related code
    The reasons for having those are obsolete, since ARM deprecated its
    custom sched_clock framework and migrated to the common one.


Soren Brinkmann (2):
  clocksource/cadence_ttc: Remove unused header
  clocksource/cadence_ttc: Reuse clocksource as sched_clock

 drivers/clocksource/cadence_ttc_timer.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

-- 
1.8.3.2



From will.deacon at arm.com  Mon Jul  8 13:03:53 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 8 Jul 2013 18:03:53 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <20130708110202.GD22057@mudshark.cambridge.arm.com>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com>
 <20130708084911.GA22057@mudshark.cambridge.arm.com>
 <51DA8BBF.7080104@gmail.com>
 <20130708110202.GD22057@mudshark.cambridge.arm.com>
Message-ID: <20130708170352.GA24361@mudshark.cambridge.arm.com>

On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
> > The printascii can output before "b __enable_mmu", after move it to
> > __mmap_switched, nothing can be printed. But if disable LPAE, printascii
> > works again in __mmap_switched.
> 
> Ok, so the page tables are broken. The code is there to swap the two words,
> but perhaps something ends up being off-by-4 or the like. I'll try and take
> a look.

Right, I managed to have a quick play with a 3.10 kernel and the good news
is that the page tables are fine. The bad part is that using
CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the FDT
results in a NULL command line, so I don't see any output. If I hardcode the
command line in the kernel image, things work fine.

What kernel are you using, and how are you passing your command line?

Will


From ldewangan at nvidia.com  Mon Jul  8 13:12:46 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 8 Jul 2013 22:42:46 +0530
Subject: [PATCH V2] ARM: tegra: enable gpio-keys on dalmore
In-Reply-To: <51DADFEC.1050901@wwwdotorg.org>
References: <1373102069-5641-1-git-send-email-ldewangan@nvidia.com>
 <51DADFEC.1050901@wwwdotorg.org>
Message-ID: <51DAF30E.9000101@nvidia.com>

On Monday 08 July 2013 09:21 PM, Stephen Warren wrote:
> On 07/06/2013 03:14 AM, Laxman Dewangan wrote:
>
>> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
>> @@ -976,4 +1005,5 @@
>>   			 <&tegra_car TEGRA114_CLK_EXTERN1>;
>>   		clock-names = "pll_a", "pll_a_out0", "mclk";
>>   	};
>> +
>>   };
> What's that? I'll try to remember to fix this up when applying, but
> proof-reading would help.

Oops.. My bad.. Did not see the bottom when doing patch review.

Let me know if I need to send V4 if it is easy for you to handle?



From nm at ti.com  Mon Jul  8 13:22:36 2013
From: nm at ti.com (Nishanth Menon)
Date: Mon, 8 Jul 2013 12:22:36 -0500
Subject: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control
 PMIC over VC/VP
In-Reply-To: <20130705174727.GF27646@sirena.org.uk>
References: <1371849949-12649-1-git-send-email-nm@ti.com>
 <1371849949-12649-2-git-send-email-nm@ti.com>
 <20130704154105.GD27646@sirena.org.uk> <20130705135507.GA17439@kahuna>
 <20130705140828.GA27646@sirena.org.uk> <51D6DD3A.1030002@ti.com>
 <20130705165235.GC27646@sirena.org.uk> <51D70356.30707@ti.com>
 <20130705174727.GF27646@sirena.org.uk>
Message-ID: <51DAF55C.5040502@ti.com>

On 07/05/2013 12:47 PM, Mark Brown wrote:
> On Fri, Jul 05, 2013 at 12:33:10PM -0500, Nishanth Menon wrote:
>
>> Taking an example of twl-regulator and omap_pmic, are you suggesting
>> omap_pmic to be a user twl-regulator using
>> include/linux/regulator/consumer.h? or are you suggesting that
>> omap_pmic should not be a regulator at all?
>
> No, I'm suggesting that omap_pmic find the TWL driver data at runtime
> (eg, using the device tree to locate the relevant regulator) and get the
> information out of the regulator driver that way.  It can then tell the
> hardware about the data that way without having to explictly add every
> single regulator both standalone and to the OMAP driver.

Apologies on delayed response, I had spend sometime thinking about 
this(and try some prototype code), here it goes:

case #1 - TPS62361 has a single SMPS and a single generic i2c bus, one 
can talk on. In this case, you'd associate the regulator device in one 
place - i2cX or on custom SoC hardware interface.

When used with custom SoC hardware interface, generic tps62361 regulator 
which talks regular i2c wont even probe for omap_pmic to get the 
regulator data from tps62361 regulator driver. Even if we were to define 
the generic TPS62361 in dts nodes, it will fail probe as it cant access 
any of it's registers using generic i2c.

case #2 - TWL6030/2 has a multiple SMPS and LDOs and a two i2c bus one 
can talk on. however, SMPS meant for SoC can only be controlled by 
custom SoC hardware. In this case, we'd not even have a 
regulator_register taking place for SMPS controlled by custom hardware.

I am lost as to how we can even do this?

All the dts node tells for an SMPS today is:
vaux3: regulator-vaux3 {
         compatible = "ti,twl6030-vaux3";
} as an example.
the slew data is embedded inside the twl-regulator data structures - if 
it never gets probed, it wont make that data available in regulator core 
information.

so doing something like:
omap_pmic_vdd_mpu {
	pmic-supply = <&vcore1>;
};
wont work, unless we define a phandle vcore1.
vcore1: regulator-vcore1 {
	compatible="ti,twl6030-vcore1";
};
wont help us either, because this wont be an SMPS that twl-regulator can 
even try to control.

So, how would omap_pmic find vcore1 twl driver data when it does not 
even twl6030 does not even probe vcore1? and making twl-regulator.c 
probe vcore1 (aka making it probe for a device that it cannot manage) is 
conceptually wrong, no (not to mention wrong definition of two device 
nodes in dt blob for the same device)?


>
>>> There's no information about how to use this register in your
>>> bindings...  but anyway, can't be too hard to add this if it's actually
>>> used.
>
>> Yes it is, and also happens to be how OMAPs achieve maximum power
>> savings - when low power modes are achieved in OMAP(automatic
>> hardware assisted commands are send to the specific command
>> registers in PMIC and viceversa on wakeup) - but this also happens
>> to be very specific to OMAP way of handling things. I can refer to
>> the Reference Manual as to how it actually works, but that'd be an
>> overkill, I will try to expand on the bindings a little more, I
>> guess.
>
> OK, so this is a register defined by the OMAP architecture?  I think

I might say yes, but that will only be because I just know OMAP 
architecture alone, Have'nt had enough indepth knowledge of other 
architectures to make a broader statement :(

> it's reasonable to add something to allow this to be obtained to the
> core, using a DT property seems yucky since every board usingt this is
> going to have to cut'n'paste the value.  Some sort of custom parameter
> readback thing perhaps, it doesn't have to be too generic.

custom of->match data parameter is how it is done today in this patch

>
>>> Anything that implements a custom set_voltage() won't work with your
>>> data structure either...
>
>> It would not work with OMAP either ;). But that said, drivers do
>
> Yes, that's kind of my point - as with the code Paul was implementing it
> doesn't matter if you can't support every single regualtor since the
> hardware design constrains what the regulator can do.  The regualtor
> framework already has helpers which factor out the code for anything
> which has the limiations the OMAP hardware has (or where it doesn't we
> could add them) so there shouldn't be any need for a driver to provide
> custom callbacks.

custom callback context was as follows: if we force the SoC generic 
regulators to use OMAP custom interfaces, then we have a need for custom 
callbacks, else w.r.t PMIC data, covered above, we do not need any 
custom callbacks, agreed.

>> freely implement custom set_voltage/get_voltage primarily because
>> there are ranges in supported voltages that are non-linear and try
>> to be generic to work on non-OMAP platforms as well. However, within
>> the supported range, only the linear ranges are used with OMAP.
>
> OK, that's a bit more interesting but I expect such regulators will
> actually work with the linear ranges helpers I added the other day
> (Marvell had a PMIC using them and I realised that the same pattern can
> be applied to a bunch of other devices).  Do you think that'd cover the
> cases you're aware of?
>
> Another option is for the drivers to provide the data and use the
> helpers for their linear ranges as part of a more complex
> implementation.

Having looked at a few regulator driver implementations, there seems to 
be the following combinations:
a) drivers which have n ranges of linear voltages for incremental selector
b) drivers with 1 range of linear voltages only for all ranges of selectors
c) drivers with 1 range of linear voltages and nonlinear voltage values 
for other vsels.


>
>>>> OMAP VC hardware has no idea about how long to wait before giving up
>>>> on an ongoing i2c transaction. This may depend on PMIC and what it
>>>> does before acking on i2c.
>
>>> So pick a high number (it's only for error cases...)?
>
>> from hardware perspective yeah, if it does not lockup (based on
>> erratas on specific devices ;) ). it also controls in part, the
>> latency of response to Voltage processor from Voltage controller
>> also needed for computing SmartReflex latencies (as it should
>> consider worst case conditions)
>
> OK, that's a bit more fun but I think the kernel wants that information
> in general anyway since a software cpufreq driver or something might
> want to make the same latency decisions.  This is what set_voltage_time()
> is for in part.  But to a first approximation is there really much
> variation in the numbers?

between PMICs? yep, twl4030 does 4mV/uSec, 6030 can do 6mV/uSec, 
TPS62361 can do 32mV/uSec, TWL6035/37 does 0.220mV/uSec

For a given PMIC, voltage X to Y time will vary ofcourse. SmartReflex 
AVS is something cpufreq wont know about -> completely different topic 
of its own :)

What we are representing is data for PMIC supported on specific SoC 
hardware controller interface meant just for PMIC - IMHO, it is similar 
to data that twl-regulator stores for the SMPS/LDOs that it can control 
- given these are starting to become legacy platforms (OMAP3,4,5) and 
the fact that it is a one-off(at this point in time) knwon custom 
hardware doing stuff like this, we would'nt expect too much churn either 
there(new PMICs added etc). On the flip side, I do understand your 
concern with scalability and ease of re-use here. but given that we 
have'nt seen much of a churn in this data for years on the go now, I'd 
expect lesser in the future. This dedicated interface has been dropped 
in our future chips precisely due to the lack of scalability to PMIC 
choices such as those using SPI.

just my 2 cents.
-- 
Regards,
Nishanth Menon


From swarren at wwwdotorg.org  Mon Jul  8 13:36:21 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 08 Jul 2013 11:36:21 -0600
Subject: CPU hotplug issue w/ 0647065 clocksource: Add generic dummy timer
 driver
Message-ID: <51DAF895.1020700@wwwdotorg.org>

CPU hotplug (replug) on Tegra HW seems to be occasionally broken due to
commit 0647065 "clocksource: Add generic dummy timer driver" in
linux-next. Reverting that commit solves the issue.

The symptom is that ~10% of the time, when re-plugging CPU1 (in a 2-core
system, after unplugging it about 1 second before), I'll see the
following WARN trigger in clockevents_program_event():

> int clockevents_program_event(struct clock_event_device *dev, ktime_t expires,
> 			      bool force)
> {
> 	unsigned long long clc;
> 	int64_t delta;
> 	int rc;
> 
> 	if (unlikely(expires.tv64 < 0)) {
> 		WARN_ON_ONCE(1);
> 		return -ETIME;
> 	}

This appears to be because in tick_handle_periodic_broadcast(),
dev->next_event == KTIME_MAX. The system then hangs; I think that loop
just keeps adding tick_period onto next_event, which doesn't manage to
get to an acceptable value for a long time, if ever!

Do you have any idea why this could happen? I assume that during
switching between the dummy timer added by that patch, and the real
Tegra timer (drivers/clocksource/tegra20_timer.c) the Tegra timer's
dev->next_event is temporarily set to KTIME_MAX, but somehow the timer
IRQ handling goes off while the device is in this temporary state? The
timer core seems to take steps to prevent this though, i.e. callilng
spin_lock_irqsave() in places.

If I modify tick_handle_periodic_broadcast() to check for a negative
dev->next_event and simply return in that case, the system seems to work
fine, and I do see tick_handle_periodic_broadcast() being called at a
later time, so obviously something is coming along later and programming
the HW to generate additional events. On this HW, I believe struct
clock_event_device.set_next_event is being used to emulate the periodic
broadcast using a one-shot timer, rather than using the HW's native
periodic capability, probably due to CONFIG_NO_HZ.

Any hints greatly appreciated!


From festevam at gmail.com  Mon Jul  8 13:58:36 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon,  8 Jul 2013 14:58:36 -0300
Subject: [PATCH 1/3] ARM: imx: Select CACHE_L2X0
Message-ID: <1373306318-15604-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Select CACHE_L2X0 for mx31/35/51/53/6q/6sl.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/mach-imx/Kconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index f546560..f864af2 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -122,6 +122,7 @@ config SOC_IMX27
 
 config SOC_IMX31
 	bool
+	select CACHE_L2X0
 	select COMMON_CLK
 	select CPU_V6
 	select IMX_HAVE_PLATFORM_MXC_RNGA
@@ -131,6 +132,7 @@ config SOC_IMX31
 config SOC_IMX35
 	bool
 	select ARCH_MXC_IOMUX_V3
+	select CACHE_L2X0
 	select COMMON_CLK
 	select CPU_V6K
 	select HAVE_EPIT
@@ -142,6 +144,7 @@ config SOC_IMX5
 	select ARCH_HAS_CPUFREQ
 	select ARCH_HAS_OPP
 	select ARCH_MXC_IOMUX_V3
+	select CACHE_L2X0
 	select COMMON_CLK
 	select CPU_V7
 	select MXC_TZIC
@@ -785,6 +788,7 @@ config SOC_IMX6Q
 	bool "i.MX6 Quad/DualLite support"
 	select ARCH_HAS_CPUFREQ
 	select ARCH_HAS_OPP
+	select CACHE_L2X0
 	select ARM_CPU_SUSPEND if PM
 	select ARM_ERRATA_754322
 	select ARM_ERRATA_764369 if SMP
@@ -815,6 +819,7 @@ config SOC_IMX6SL
 	select ARM_ERRATA_754322
 	select ARM_ERRATA_775420
 	select ARM_GIC
+	select CACHE_L2X0
 	select CPU_V7
 	select HAVE_IMX_ANATOP
 	select HAVE_IMX_GPC
-- 
1.8.1.2



From festevam at gmail.com  Mon Jul  8 13:58:38 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon,  8 Jul 2013 14:58:38 -0300
Subject: [PATCH 3/3] ARM: imx: mm-imx3: Free l2x0_base
In-Reply-To: <1373306318-15604-1-git-send-email-festevam@gmail.com>
References: <1373306318-15604-1-git-send-email-festevam@gmail.com>
Message-ID: <1373306318-15604-3-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

After l2x0_base has been used, we should free it.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/mach-imx/mm-imx3.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-imx/mm-imx3.c b/arch/arm/mach-imx/mm-imx3.c
index 0884ca9..3143f5e 100644
--- a/arch/arm/mach-imx/mm-imx3.c
+++ b/arch/arm/mach-imx/mm-imx3.c
@@ -113,6 +113,7 @@ static void __init imx3_init_l2x0(void)
 	}
 
 	l2x0_init(l2x0_base, 0x00030024, 0x00000000);
+	iounmap(l2x0_base);
 #endif
 }
 
-- 
1.8.1.2



From festevam at gmail.com  Mon Jul  8 13:58:37 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon,  8 Jul 2013 14:58:37 -0300
Subject: [PATCH 2/3] ARM: mx3: Select ARM_ERRATA_411920
In-Reply-To: <1373306318-15604-1-git-send-email-festevam@gmail.com>
References: <1373306318-15604-1-git-send-email-festevam@gmail.com>
Message-ID: <1373306318-15604-2-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

ARM_ERRATA_411920 affects mx31 and mx35, so let's enable it:

ARM_ERRATA_411920:
	  Invalidation of the Instruction Cache operation can
	  fail. This erratum is present in 1136 (before r1p4), 1156 and 1176.
	  It does not affect the MPCore. This option enables the ARM Ltd.
	  recommended workaround.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/mach-imx/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index f864af2..a0a89c4 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -122,6 +122,7 @@ config SOC_IMX27
 
 config SOC_IMX31
 	bool
+	select ARM_ERRATA_411920
 	select CACHE_L2X0
 	select COMMON_CLK
 	select CPU_V6
@@ -132,6 +133,7 @@ config SOC_IMX31
 config SOC_IMX35
 	bool
 	select ARCH_MXC_IOMUX_V3
+	select ARM_ERRATA_411920
 	select CACHE_L2X0
 	select COMMON_CLK
 	select CPU_V6K
-- 
1.8.1.2



From shc_work at mail.ru  Mon Jul  8 14:06:55 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Mon, 08 Jul 2013 22:06:55 +0400
Subject: =?UTF-8?B?UmU6IFtQQVRDSCAyLzNdIEFSTTogbXgzOiBTZWxlY3QgQVJNX0VSUkFUQV80?=
 =?UTF-8?B?MTE5MjA=?=
In-Reply-To: <1373306318-15604-2-git-send-email-festevam@gmail.com>
References: <1373306318-15604-1-git-send-email-festevam@gmail.com>
 <1373306318-15604-2-git-send-email-festevam@gmail.com>
Message-ID: <1373306815.761097891@f229.i.mail.ru>

> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> ARM_ERRATA_411920 affects mx31 and mx35, so let's enable it:
> 
> ARM_ERRATA_411920:
> 	  Invalidation of the Instruction Cache operation can
> 	  fail. This erratum is present in 1136 (before r1p4), 1156 and 1176.
> 	  It does not affect the MPCore. This option enables the ARM Ltd.
> 	  recommended workaround.

IMHO, enabling any errata for multiplatform kernel is not a good idea.

---

From festevam at gmail.com  Mon Jul  8 14:16:34 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 8 Jul 2013 15:16:34 -0300
Subject: Handling ARM_ERRATA_364296 when CONFIG_SMP=y
Message-ID: <CAOMZO5AVpQ6DUja=usBCDzRH0NyNqbXsHNNOJSAY=8OvgHHTmA@mail.gmail.com>

Hi Catalin,

On commit 145e10e1 (ARM: 7015/1: ARM errata: Possible cache data
corruption with hit-under-miss enabled) you added support for
ARM_ERRATA_364296 option:

+config ARM_ERRATA_364296
+       bool "ARM errata: Possible cache data corruption with
hit-under-miss enabled"
+       depends on CPU_V6 && !SMP
+       help

As this erratum affects mx31/mx35, I would like to enable it, but I am
not allowed to do it because mx31/mx35 share the same config file as
mx6 (imx_v6_v7_defconfig), which has SMP turned on.

What would be the correct approach for applying this erratum?

Is it safe to do "depends on CPU_V6" only or should this erratum be
handled in the bootloader?

Regards,

Fabio Estevam


From w at 1wt.eu  Mon Jul  8 14:22:12 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Mon, 8 Jul 2013 20:22:12 +0200
Subject: Handling ARM_ERRATA_364296 when CONFIG_SMP=y
In-Reply-To: <CAOMZO5AVpQ6DUja=usBCDzRH0NyNqbXsHNNOJSAY=8OvgHHTmA@mail.gmail.com>
References: <CAOMZO5AVpQ6DUja=usBCDzRH0NyNqbXsHNNOJSAY=8OvgHHTmA@mail.gmail.com>
Message-ID: <20130708182212.GF3621@1wt.eu>

On Mon, Jul 08, 2013 at 03:16:34PM -0300, Fabio Estevam wrote:
> Hi Catalin,
> 
> On commit 145e10e1 (ARM: 7015/1: ARM errata: Possible cache data
> corruption with hit-under-miss enabled) you added support for
> ARM_ERRATA_364296 option:
> 
> +config ARM_ERRATA_364296
> +       bool "ARM errata: Possible cache data corruption with
> hit-under-miss enabled"
> +       depends on CPU_V6 && !SMP
> +       help
> 
> As this erratum affects mx31/mx35, I would like to enable it, but I am
> not allowed to do it because mx31/mx35 share the same config file as
> mx6 (imx_v6_v7_defconfig), which has SMP turned on.
> 
> What would be the correct approach for applying this erratum?
> 
> Is it safe to do "depends on CPU_V6" only or should this erratum be
> handled in the bootloader?

Or maybe fix the config so that it does not force SMP on a CPU which
only exists as a single core ?

Regards,
Willy



From stern at rowland.harvard.edu  Mon Jul  8 14:27:26 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Mon, 8 Jul 2013 14:27:26 -0400 (EDT)
Subject: [PATCH 1/2] USB: OHCI: make ohci-ep93xx a separate driver
In-Reply-To: <CAJFYCKH4xMgG7XTy_Fz8J6F8ussR_NtfKJ1CnOG-N9xG1CcYKA@mail.gmail.com>
Message-ID: <Pine.LNX.4.44L0.1307081424310.879-100000@iolanthe.rowland.org>

On Mon, 8 Jul 2013, Manjunath Goudar wrote:

> > > @@ -79,7 +93,10 @@ static int usb_hcd_ep93xx_probe(const struct
> > hc_driver *driver,
> > >
> > >       ep93xx_start_hc(&pdev->dev);
> > >
> > > -     ohci_hcd_init(hcd_to_ohci(hcd));
> > > +     ohci = hcd_to_ohci(hcd);
> > > +     ohci->next_statechange = jiffies;
> > > +     spin_lock_init(&ohci->lock);
> > > +     INIT_LIST_HEAD(&ohci->pending);
> > >
> > >       retval = usb_add_hcd(hcd, pdev->resource[1].start, 0);
> > >       if (retval == 0)
> >
> 
> Instead of ohci_hcd_ini() function call,wrote above code.

You ought to be aware that usb_add_hcd() will call ohci_setup(), which
calls ohci_hcd_init() -- after all, _you_ wrote ohci_setup()!

So what reason is there for doing these things a second time?

Alan Stern



From stern at rowland.harvard.edu  Mon Jul  8 14:34:30 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Mon, 8 Jul 2013 14:34:30 -0400 (EDT)
Subject: [PATCH 2/2] USB: OHCI: make ohci-pxa27x a separate driver
In-Reply-To: <CAJFYCKHwHFVqC022iwAEGoncGykZD+wAoveq7XDvUk4_tSMqVQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.44L0.1307081429380.879-100000@iolanthe.rowland.org>

On Mon, 8 Jul 2013, Manjunath Goudar wrote:

> > Several aspects of this are strange.  For example, consider how you
> > used the private part of the ohci_hcd structure and how the variable
> > names are inconsistent with the other OHCI glue drivers.
> >
> >
> Here we are considering private date like "clk" and "*mmio_base". These are
> keeping separate from general ohci_hcd using pxa27x_ohci struct (As EHCI).
> 
> In this glue already used ohci as pxa27x_ohci variable that is what I used
> pxaohci as
> variable of  pxa27x_ohci struct.

You should make this driver look like all the other glue drivers.  That 
means you should change it so that "ohci" is the name of the struct 
ohci_hcd variable.  You can call the private structure "pxa_ohci".  And 
don't forget the '_' character; without it the variable's name is 
unreadable.

Also, you should store the private data in the ohci->private region.  
Change the current code so that it works like the other glue drivers.

Alan Stern



From broonie at kernel.org  Mon Jul  8 11:07:21 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 8 Jul 2013 16:07:21 +0100
Subject: [PATCH v2 1/5] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <1373290193-25300-2-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373290193-25300-2-git-send-email-richard.genoud@gmail.com>
Message-ID: <20130708150721.GK27646@sirena.org.uk>

On Mon, Jul 08, 2013 at 03:29:49PM +0200, Richard Genoud wrote:

> + *		  Nicolas Ferre <nicolas.ferre at atmel.com>
> + *
> + * Based on sam9g20_wm8731.c by:
> + * Sedji Gaouaou <sedji.gaouaou at atmel.com>

The obvious question here is of course if we can use the same driver for
both of them.

> +	codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 |
> +		SNDRV_PCM_RATE_32000 |
> +		SNDRV_PCM_RATE_48000 |
> +		SNDRV_PCM_RATE_96000;
> +	codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 |
> +		SNDRV_PCM_RATE_32000 |
> +		SNDRV_PCM_RATE_48000 |
> +		SNDRV_PCM_RATE_96000;

You definitely shouldn't be fiddling with a driver's constant static
data.  You want to be using snd_pcm_hw_constraint() APIs to set
additional constraints intead.
-------------- 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/20130708/77d68cbb/attachment.sig>

From aaro.koskinen at iki.fi  Mon Jul  8 15:44:02 2013
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Mon, 8 Jul 2013 22:44:02 +0300
Subject: [PATCH v3 4/4] USB: OMAP1: Tahvo USB transceiver driver
In-Reply-To: <20130708072109.GA16635@arwen.pp.htv.fi>
References: <1371575221-360-1-git-send-email-aaro.koskinen@iki.fi>
 <1371575221-360-5-git-send-email-aaro.koskinen@iki.fi>
 <20130708072109.GA16635@arwen.pp.htv.fi>
Message-ID: <20130708194402.GA8516@blackmetal.musicnaut.iki.fi>

Hi,

On Mon, Jul 08, 2013 at 10:21:09AM +0300, Felipe Balbi wrote:
> On Tue, Jun 18, 2013 at 08:07:01PM +0300, Aaro Koskinen wrote:
> > +static ssize_t vbus_state_show(struct device *device,
> > +			       struct device_attribute *attr, char *buf)
> > +{
> > +	struct tahvo_usb *tu = dev_get_drvdata(device);
> > +	return sprintf(buf, "%d\n", tu->vbus_state);
> > +}
> > +static DEVICE_ATTR(vbus_state, 0444, vbus_state_show, NULL);
> 
> VBUS status sounds generic enough, also, you should be printing on/off
> here instead of tahvo-specific values. Some users might not have access
> to the docs, or even the kernel sources, to understand what that integer
> means.

Ok, I'll fix.

> > +static void tahvo_usb_become_host(struct tahvo_usb *tu)
> > +{
> > +	struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
> > +
> > +	extcon_set_cable_state(&tu->extcon, "USB-HOST", true);
> > +
> > +	/* Power up the transceiver in USB host mode */
> > +	retu_write(rdev, TAHVO_REG_USBR, USBR_REGOUT | USBR_NSUSPEND |
> > +		   USBR_MASTER_SW2 | USBR_MASTER_SW1);
> > +	tu->phy.state = OTG_STATE_A_IDLE;
> > +
> > +	check_vbus_state(tu);
> > +}
> > +
> > +static void tahvo_usb_stop_host(struct tahvo_usb *tu)
> > +{
> > +	tu->phy.state = OTG_STATE_A_IDLE;
> 
> shouldn't you undo tahvo_usb_become_host() here ? I mean, set the
> transceiver to SLAVE ?

tahvo_usb_become_peripheral() (or power_off) is always called after this
function. Actually, these stop functions can be eliminated altogether
as they are only called from a single place...

> > +static int tahvo_usb_set_host(struct usb_otg *otg, struct usb_bus *host)
> > +{
> > +	struct tahvo_usb *tu = container_of(otg->phy, struct tahvo_usb, phy);
> > +
> > +	dev_dbg(&tu->pt_dev->dev, "%s %p\n", __func__, host);
> > +
> > +	if (otg == NULL)
> > +		return -ENODEV;
> > +
> > +	mutex_lock(&tu->serialize);
> > +
> > +	if (host == NULL) {
> > +		if (tu->tahvo_mode == TAHVO_MODE_HOST)
> > +			tahvo_usb_power_off(tu);
> > +		otg->host = NULL;
> > +		mutex_unlock(&tu->serialize);
> > +		return 0;
> > +	}
> > +
> > +	if (tu->tahvo_mode == TAHVO_MODE_HOST) {
> > +		otg->host = NULL;
> > +		tahvo_usb_become_host(tu);
> > +	}
> > +
> > +	otg->host = host;
> > +
> > +	mutex_unlock(&tu->serialize);
> > +
> > +	return 0;
> > +}
> > +
> > +static int tahvo_usb_set_peripheral(struct usb_otg *otg,
> > +				    struct usb_gadget *gadget)
> 
> I want to get rid of the extra 'gadget' and 'host' parameters on
> ->set_host() and ->set_peripheral(). Nobody really uses them other than:
> 
> my_phy->phy.otg->{gadget,host} = {gadget,host};
> 
> For that, I need all other PHYs to stop relying on those parameters and
> I'll cook patches for that for v3.12 merge window.

How will the PHY know if there is a host/gadget driver present? I guess
I will need to wait for those patches...

> > +static ssize_t otg_mode_store(struct device *device,
> > +			      struct device_attribute *attr,
> > +			      const char *buf, size_t count)
> > +{
> > +	struct tahvo_usb *tu = dev_get_drvdata(device);
> > +	int r;
> > +
> > +	mutex_lock(&tu->serialize);
> > +	if (count >= 4 && strncmp(buf, "host", 4) == 0) {
> > +		if (tu->tahvo_mode == TAHVO_MODE_PERIPHERAL)
> > +			tahvo_usb_stop_peripheral(tu);
> > +		tu->tahvo_mode = TAHVO_MODE_HOST;
> > +		if (tu->phy.otg->host) {
> > +			dev_info(device, "HOST mode: host controller present\n");
> > +			tahvo_usb_become_host(tu);
> > +		} else {
> > +			dev_info(device, "HOST mode: no host controller, powering off\n");
> > +			tahvo_usb_power_off(tu);
> > +		}
> > +		r = strlen(buf);
> > +	} else if (count >= 10 && strncmp(buf, "peripheral", 10) == 0) {
> > +		if (tu->tahvo_mode == TAHVO_MODE_HOST)
> > +			tahvo_usb_stop_host(tu);
> > +		tu->tahvo_mode = TAHVO_MODE_PERIPHERAL;
> > +		if (tu->phy.otg->gadget) {
> > +			dev_info(device, "PERIPHERAL mode: gadget driver present\n");
> > +			tahvo_usb_become_peripheral(tu);
> > +		} else {
> > +			dev_info(device, "PERIPHERAL mode: no gadget driver, powering off\n");
> > +			tahvo_usb_power_off(tu);
> > +		}
> > +		r = strlen(buf);
> > +	} else {
> > +		r = -EINVAL;
> > +	}
> > +	mutex_unlock(&tu->serialize);
> > +
> > +	return r;
> > +}
> > +
> > +static DEVICE_ATTR(otg_mode, 0644, otg_mode_show, otg_mode_store);
> 
> this looks like something which would be very nice if implemented
> generically. Since you, anyway miss the documentation in
> Documentation/ABI/ and need to respin the patch, how about making this
> generic ?

Ok, I'll try to come up with something...

> > +static int tahvo_usb_probe(struct platform_device *pdev)
> > +{
> > +	struct retu_dev *rdev = dev_get_drvdata(pdev->dev.parent);
> > +	struct tahvo_usb *tu;
> > +	int ret;
> > +
> > +	tu = devm_kzalloc(&pdev->dev, sizeof(*tu), GFP_KERNEL);
> > +	if (!tu)
> > +		return -ENOMEM;
> > +
> > +	tu->phy.otg = devm_kzalloc(&pdev->dev, sizeof(*tu->phy.otg),
> > +				   GFP_KERNEL);
> > +	if (!tu->phy.otg)
> > +		return -ENOMEM;
> > +
> > +	tu->pt_dev = pdev;
> > +
> > +	/* Default mode */
> > +#ifdef CONFIG_TAHVO_USB_HOST_BY_DEFAULT
> > +	tu->tahvo_mode = TAHVO_MODE_HOST;
> > +#else
> > +	tu->tahvo_mode = TAHVO_MODE_PERIPHERAL;
> > +#endif
> 
> should you call become_host()/become_peripheral() here ?

Not needed. Once the PHY is registered, the framework will call set_host /
set_peripheral and the HW gets set to correct state.

> > +	mutex_init(&tu->serialize);
> > +
> > +	tu->ick = devm_clk_get(&pdev->dev, "usb_l4_ick");
> > +	if (!IS_ERR(tu->ick))
> > +		clk_enable(tu->ick);
> > +
> > +	/*
> > +	 * Set initial state, so that we generate kevents only on state changes.
> > +	 */
> > +	tu->vbus_state = retu_read(rdev, TAHVO_REG_IDSR) & TAHVO_STAT_VBUS;
> > +
> > +	tu->extcon.name = DRIVER_NAME;
> > +	tu->extcon.supported_cable = tahvo_cable;
> > +	ret = extcon_dev_register(&tu->extcon, &pdev->dev);
> > +	if (ret) {
> > +		dev_err(&pdev->dev, "could not register extcon device: %d\n",
> > +			ret);
> > +		return ret;
> > +	}
> > +
> > +	/* Set the initial cable state. */
> > +	extcon_set_cable_state(&tu->extcon, "USB-HOST",
> > +			       tu->tahvo_mode == TAHVO_MODE_HOST);
> > +	extcon_set_cable_state(&tu->extcon, "USB", tu->vbus_state);
> > +
> > +	tu->irq = platform_get_irq(pdev, 0);
> > +	ret = request_threaded_irq(tu->irq, NULL, tahvo_usb_vbus_interrupt, 0,
> > +				   "tahvo-vbus", tu);
> 
> since your hardirq handler is NULL, you *must* pass IRQF_ONESHOT.

Ok.

> /Could also use devm_request_threaded_irq()

Does not really help much, since the IRQ has to be freed manually anyway
(to ensure it's disabled before usb_remove_phy(); also looks like it's
currently enabled too early...).

> > +	if (ret) {
> > +		dev_err(&pdev->dev, "could not register tahvo-vbus irq: %d\n",
> > +			ret);
> > +		goto err_disable_clk;
> > +	}
> > +
> > +	/* Attributes */
> > +	ret = device_create_file(&pdev->dev, &dev_attr_vbus_state);
> > +	ret |= device_create_file(&pdev->dev, &dev_attr_otg_mode);
> 
> heh, Greg wrote a very interesting article recently (look at his blog)
> discussing kernel/userland races wrt creation of sysfs files.

[...]

> what if someone accesses the sysfs file you've already created before
> you call dev_set_drvdata? (not sure  if it's possible).

Yes, that's a bug, will fix.

Thanks for comments,

A.


From ezequiel.garcia at free-electrons.com  Mon Jul  8 15:52:25 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 8 Jul 2013 16:52:25 -0300
Subject: [PATCH v6 00/21] MBus DT binding: PCIe strikes back
In-Reply-To: <20130708164225.GA26618@obsidianresearch.com>
References: <1373060372-32357-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130706013547.3ce7280b@skate> <201307060138.36191.arnd@arndb.de>
 <20130708164225.GA26618@obsidianresearch.com>
Message-ID: <20130708195224.GA2322@localhost>

On Mon, Jul 08, 2013 at 10:42:25AM -0600, Jason Gunthorpe wrote:
> On Sat, Jul 06, 2013 at 01:38:35AM +0200, Arnd Bergmann wrote:
> > On Saturday 06 July 2013, Thomas Petazzoni wrote:
> > > Arnd, Jason, if you could confirm that you both agree with this DT
> > > binding soon, Ezequiel and I would quickly adapt the code accordingly,
> > > and hopefully converge towards a final patch set.
> > 
> > Looks all good from what I can tell.
> 
> It also looks fine to me.
> 

Ok, great. I'll see if I can rework it and submit something today.

So, as far as I can tell, that would be v7 and would be ready for
inclusion.

Thanks a lot!
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From maxime.ripard at free-electrons.com  Mon Jul  8 16:25:38 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 8 Jul 2013 22:25:38 +0200
Subject: MTD EEPROM support and driver integration
In-Reply-To: <20130708083426.GO27646@sirena.org.uk>
References: <20130705201118.GM2959@lukather> <5811519.oHVuMujf0I@wuerfel>
 <20130706120112.GA11069@lukather> <8997501.Dchyii8uWX@wuerfel>
 <20130708083426.GO27646@sirena.org.uk>
Message-ID: <20130708202538.GK11243@lukather>

On Mon, Jul 08, 2013 at 09:34:26AM +0100, Mark Brown wrote:
> On Sat, Jul 06, 2013 at 09:06:49PM +0200, Arnd Bergmann wrote:
> > On Saturday 06 July 2013 14:01:12 Maxime Ripard wrote:
> 
> > > > > > a) like interrupts, regs, dmas, clocks, pinctrl, reset, pwm: fixed property names
> 
> > > > > >       regmap = <&at25 0xstart 0xlen>;
> > > > > >       regmap-names = "mac-address";
> 
> > > > > > b) like gpio, regulator: variable property names
> 
> > > > > >       mac-storage = <&at25 0xstart 0xlen>;
> 
> > > > > > It's unfortunate that we already have examples of both. They are largely
> > > > > > equivalent, but the tendency is towards the first.
> 
> > > > > I don't have a strong feeling for one against another, so whatever works
> > > > > best. Both solutions will be a huge improvement anyway 
> 
> > > > > Just out of curiosity, is there any advantages besides having a fixed
> > > > > property name to the first solution?
> 
> > > > I think it's mostly for consistency: trying to get most subsystems to
> > > > do it the same way to make it easier for people to write dts files.
> 
> > > > A lesser point is that it simplifies the driver code if you don't
> > > > have to pass a name.
> 
> On the other hand something with human readable names is much more
> legible if humans ever have to read or write the DT bindings.  This
> mostly applies when there are many instances of the property (for
> example, many devices have lots of power supplies) or when some
> instances of the property are optional (for example, many devices can
> use GPIOs for many different functions but usually not all of them are
> connected and there's no particular order in which they might get
> connected).

I guess we would have only a few of these in our cases, so it doesn't
really qualify for the "many instances" I guess, but I do find the
GPIO/regulator-like properties more intuitive and more readable as
well.

> > > So that leave us with mainly one path to achieve this goal:
> > >   - Add a regmap-mtd backend
> > >   - Add DT parsing code for regmap
> > >   - Move the EEPROM drivers from misc to mtd
> 
> > Yes, I think that would be good. For the last step, we definitely need
> > buy-in from Wolfgand and Jean, as they are maintaining the current eeprom
> > drivers.
> 
> I'd really like to see more discussion of this "DT parsing code for
> regmap" idea...  I've missed almost all the context here.

The context was that I found we lack a way to simply express the need
for one driver to get a value from an EEPROM-like device, for example to
get a MAC Address, or a serial number, in a generic way, without having
to poke directly with some custom function that would be exported by the
EEPROM driver.

And the lack of infrastructure/framework to handle the EEPROM right now
only make the thing a bit harder.

What we've been discussing so far is that:
  - To have a common framework we could base our work on, we could move
    the EEPROM drivers from drivers/misc/eeprom to MTD
  - To declare the ranges that needed to be used by a driver that was
    needing a value from one of those MTD drivers, we would use regmap
    with a MTD backend
  - And since we actually need to declare which ranges and in which
    device one driver would have to retrieve this value from, we were
    actually in need of DT bindings.

This is pretty much the only context involved, and we are at the early
stage of the discussion, so any comment is very welcome :)

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130708/9469b2a1/attachment.sig>

From festevam at gmail.com  Mon Jul  8 16:29:34 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 8 Jul 2013 17:29:34 -0300
Subject: Handling ARM_ERRATA_364296 when CONFIG_SMP=y
In-Reply-To: <20130708182212.GF3621@1wt.eu>
References: <CAOMZO5AVpQ6DUja=usBCDzRH0NyNqbXsHNNOJSAY=8OvgHHTmA@mail.gmail.com>
 <20130708182212.GF3621@1wt.eu>
Message-ID: <CAOMZO5AeqO_AmLp1=BwrMxOd4sh-omN6vG-R5f4EgpmzqCfhrg@mail.gmail.com>

Hi Willy,

On Mon, Jul 8, 2013 at 3:22 PM, Willy Tarreau <w at 1wt.eu> wrote:

> Or maybe fix the config so that it does not force SMP on a CPU which
> only exists as a single core ?

The original config is imx_v6_v7_defconfig and it selects by default
both mx6 (quad core) and other single core CPUs.

That's the reason why CONFIG_SMP=y for this config by default.

Regards,

Fabio Estevam


From marex at denx.de  Mon Jul  8 16:56:38 2013
From: marex at denx.de (Marek Vasut)
Date: Mon, 8 Jul 2013 22:56:38 +0200
Subject: Chipidea usb otg support for IMX/MXS (device functionality)
In-Reply-To: <F281D0F91ED19E4D8E63A7504E8A649803F28763@039-SN2MPN1-021.039d.mgd.msft.net>
References: <51A5A808.2070803@digi.com> <201307070310.00973.marex@denx.de>
 <F281D0F91ED19E4D8E63A7504E8A649803F28763@039-SN2MPN1-021.039d.mgd.msft.net>
Message-ID: <201307082256.38642.marex@denx.de>

Hi Peter,

> > -----Original Message-----
> > From: Marek Vasut [mailto:marex at denx.de]
> > Sent: Sunday, July 07, 2013 9:10 AM
> > To: Chen Peter-B29397
> > Cc: shawn.guo at linaro.org; Michael Grzeschik; maxime.ripard at free-
> > electrons.com; Hector Palacios; linux-usb at vger.kernel.org;
> > s.hauer at pengutronix.de; alexander.shishkin at linux.intel.com; Estevam
> > Fabio-R49496; Marc Kleine-Budde; m.grzeschik at pengutronix.de; linux-arm-
> > kernel at lists.infradead.org
> > Subject: Re: Chipidea usb otg support for IMX/MXS (device functionality)
> > 
> > Hi Peter,
> > 
> > > > Where can I measure this?
> > > > 
> > > > > Two possible reasons:
> > > > > 
> > > > > 1. You have not gpio control for vbus toggle when role switches.
> > > > 
> > > > This works well.
> > > > 
> > > > > 2. Your hardware has some problems that the vbus can't lower than
> > 
> > 0.8v.
> > 
> > > > How can I check that?
> > > 
> > > Just measure the voltage of your otg vbus pin.
> > 
> > It's 2.5 volt for me. What am I supposed to observe happening there?
> 
> http://marc.info/?l=linux-usb&m=137242465920952&w=2

Dang, must have missed that one, sorry.

The VBUS is slowly discharging from around 5V to 2.5V , what does that tell me?

Best regards,
Marek Vasut


From javier.picorel at epfl.ch  Mon Jul  8 17:02:30 2013
From: javier.picorel at epfl.ch (javier.picorel at epfl.ch)
Date: Mon, 08 Jul 2013 23:02:30 +0200
Subject: ARM Cortex A9: User/Kernel filter events
Message-ID: <20130708230230.23643s488884h59i@webmail.epfl.ch>

Dear all,

Is there any reason why ARM Cortex A9 cannot filter user/kernel events?

arch/arm/kernel/perf_event_v7.c

1144/*
1145 * Add an event filter to a given event. This will only work for  
PMUv2 PMUs.
1146 */
1147static int armv7pmu_set_event_filter(struct hw_perf_event *event,
1148                                     struct perf_event_attr *attr)
1149{
1150        unsigned long config_base = 0;
1151
1152        if (attr->exclude_idle)
1153                return -EPERM;
1154        if (attr->exclude_user)
1155                config_base |= ARMV7_EXCLUDE_USER;
1156        if (attr->exclude_kernel)
1157                config_base |= ARMV7_EXCLUDE_PL1;
1158        if (!attr->exclude_hv)
1159                config_base |= ARMV7_INCLUDE_HYP;
1160
1161        /*
1162         * Install the filter into config_base as this is used to
1163         * construct the event type.
1164         */
1165        event->config_base = config_base;
1166
1167        return 0;
1168}

It seems that only A15 and A7 are able to do it. Is it a limitation  
A9's PMU? Thank you!

Best Regards,
Javier


From maxime.ripard at free-electrons.com  Mon Jul  8 17:04:52 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 8 Jul 2013 23:04:52 +0200
Subject: MTD EEPROM support and driver integration
In-Reply-To: <20130708083614.GP27646@sirena.org.uk>
References: <20130705201118.GM2959@lukather> <5811519.oHVuMujf0I@wuerfel>
 <20130706120112.GA11069@lukather> <8997501.Dchyii8uWX@wuerfel>
 <20130707071501.GD11243@lukather>
 <20130708083614.GP27646@sirena.org.uk>
Message-ID: <20130708210452.GL11243@lukather>

On Mon, Jul 08, 2013 at 09:36:14AM +0100, Mark Brown wrote:
> On Sun, Jul 07, 2013 at 09:15:01AM +0200, Maxime Ripard wrote:
> > On Sat, Jul 06, 2013 at 09:06:49PM +0200, Arnd Bergmann wrote:
> 
> > > We also have a bunch of OTP drivers spread around the kernel, it probably
> > > makes sense to consolidate them at the same time, at least on the DT binding
> > > side if not the device drivers.
> 
> > From a quick grep, the only one I've seen so far are:
> >   - imx6q, that has a hook at machine start to poke into its OCOTP to
> >     retrieve some frequency scaling parameters it seems. I'm not sure
> >     how the current solution could improve the situation for this
> >     use-case, but the DT bindings of the OCOTP is just a DT node, with
> >     no clients, so we have nothing to worry about here.
> >   - imx28, that has a hook at machine start to look up the MAC address
> >     values and patch the ethernet controller nodes to add the right
> >     local-mac-address property. This one could benefit from the new
> >     bindings, but we already mentionned it, and I intended to develop
> >     with an imx28 board anyway.
> >   - picoxcell-pc3x3 DTSI has a node for a OTP device, but they don't
> >     seem to be doing anything with it, nor do they seem to have a driver
> >     for it. So I guess we don't care about migrating for this one
> >     either.
> 
> > Did you have other cases in mind?
> 
> We have some OTP support in the ab8500 and wm831x MFD drivers too but
> they just expose the data.

I guess you mean ab8100, right?

Anyway, thanks for pointing this out

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130708/9dd335e5/attachment.sig>

From w at 1wt.eu  Mon Jul  8 17:10:40 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Mon, 8 Jul 2013 23:10:40 +0200
Subject: Handling ARM_ERRATA_364296 when CONFIG_SMP=y
In-Reply-To: <CAOMZO5AeqO_AmLp1=BwrMxOd4sh-omN6vG-R5f4EgpmzqCfhrg@mail.gmail.com>
References: <CAOMZO5AVpQ6DUja=usBCDzRH0NyNqbXsHNNOJSAY=8OvgHHTmA@mail.gmail.com>
 <20130708182212.GF3621@1wt.eu>
 <CAOMZO5AeqO_AmLp1=BwrMxOd4sh-omN6vG-R5f4EgpmzqCfhrg@mail.gmail.com>
Message-ID: <20130708211040.GG3621@1wt.eu>

Hi Fabio,

On Mon, Jul 08, 2013 at 05:29:34PM -0300, Fabio Estevam wrote:
> Hi Willy,
> 
> On Mon, Jul 8, 2013 at 3:22 PM, Willy Tarreau <w at 1wt.eu> wrote:
> 
> > Or maybe fix the config so that it does not force SMP on a CPU which
> > only exists as a single core ?
> 
> The original config is imx_v6_v7_defconfig and it selects by default
> both mx6 (quad core) and other single core CPUs.
> 
> That's the reason why CONFIG_SMP=y for this config by default.

OK, so if it's just a default, it's not really a problem, I understand
better now. So probably your solution to make the workaround not depend
on !SMP makes sense.

Regards,
Willy



From festevam at gmail.com  Mon Jul  8 17:38:09 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon,  8 Jul 2013 18:38:09 -0300
Subject: [PATCH] ARM: Kconfig: Let ARM_ERRATA_364296 not depend on CONFIG_SMP
Message-ID: <1373319489-9467-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

imx_v6_v7_defconfig handles both multi-core and single-core SoCs, and it has 
CONFIG_SMP=y selected by default.

With such config we cannot select ARM_ERRATA_364296, as it depends on !SMP.

Let ARM_ERRATA_364296 be undependent on CONFIG_SMP, so that we can select
this erratum for the ARM1136 SoCs, even if CONFIG_SMP=y is enabled.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0ac9be6..ba412e0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1316,7 +1316,7 @@ config ARM_ERRATA_754327
 
 config ARM_ERRATA_364296
 	bool "ARM errata: Possible cache data corruption with hit-under-miss enabled"
-	depends on CPU_V6 && !SMP
+	depends on CPU_V6
 	help
 	  This options enables the workaround for the 364296 ARM1136
 	  r0p2 erratum (possible cache data corruption with
-- 
1.8.1.2



From linux at arm.linux.org.uk  Mon Jul  8 17:53:20 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Jul 2013 22:53:20 +0100
Subject: [PATCH] ARM: Kconfig: Let ARM_ERRATA_364296 not depend on
 CONFIG_SMP
In-Reply-To: <1373319489-9467-1-git-send-email-festevam@gmail.com>
References: <1373319489-9467-1-git-send-email-festevam@gmail.com>
Message-ID: <20130708215320.GU24642@n2100.arm.linux.org.uk>

On Mon, Jul 08, 2013 at 06:38:09PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> imx_v6_v7_defconfig handles both multi-core and single-core SoCs, and it has 
> CONFIG_SMP=y selected by default.
> 
> With such config we cannot select ARM_ERRATA_364296, as it depends on !SMP.
> 
> Let ARM_ERRATA_364296 be undependent on CONFIG_SMP, so that we can select
> this erratum for the ARM1136 SoCs, even if CONFIG_SMP=y is enabled.

I'll wait for ARM Ltd folk to comment on this (they're at Linaro Connect
at the moment which has extremely poor 'net connectivity from what I've
been hearing).  We might need to bypass the workaround code in the non-SMP
case.


From ard.biesheuvel at linaro.org  Mon Jul  8 18:11:56 2013
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  8 Jul 2013 23:11:56 +0100
Subject: [PATCH v3 0/5] kernel mode NEON support
Message-ID: <1373321521-15485-1-git-send-email-ard.biesheuvel@linaro.org>

This is version 3 of the kernel mode NEON patch set.

Changes since v2:
- revert to using plain preempt_disable()/preempt_enable() rather than fiddling
  with the preempt count directly; we will keep the ability to spot violations
  of the no sleep rule even on non-PREEMPT builds with CONFIG_DEBUG_ATOMIC_SLEEP
  disabled, as sleeping disables the VFP, causing subsequent VFP instructions to
  hit the kernel mode VFP exception handler;
- modified the kernel mode VFP exception handler:
  * improved the error messages and comments to help identify the condition
    above
  * dropped the BUG() as we are already on a code path that will result in an
    oops anyway

Changes since v1:
- changed the order of the patches, so kernel_neon_begin() does not
  appear before the required fixes are in place
- don't use might_sleep() to enforce that kernel_neon_begin() should
  not be called from interrupt context, as it also prevents it from
  being called with preemption disabled, which is perfectly acceptable
- prefer inc_preempt_count() over preempt_disable() so sleeping after
  calling kernel_neon_begin() gets flagged even with kernel preemption
  disabled in Kconfig
- made the RAID6 patch suitable for both arm and arm64

Ard Biesheuvel (5):
  ARM: move VFP init to an earlier boot stage
  ARM: be strict about FP exceptions in kernel mode
  ARM: add support for kernel mode NEON
  ARM: crypto: add NEON accelerated XOR implementation
  lib/raid6: add ARM-NEON accelerated syndrome calculation

 arch/arm/Kconfig            |  7 ++++
 arch/arm/include/asm/neon.h | 36 ++++++++++++++++++++
 arch/arm/include/asm/xor.h  | 73 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/lib/Makefile       |  6 ++++
 arch/arm/lib/xor-neon.c     | 42 ++++++++++++++++++++++++
 arch/arm/vfp/vfphw.S        |  5 +++
 arch/arm/vfp/vfpmodule.c    | 69 +++++++++++++++++++++++++++++++++++++-
 include/linux/raid/pq.h     |  5 +++
 lib/raid6/.gitignore        |  1 +
 lib/raid6/Makefile          | 40 +++++++++++++++++++++++
 lib/raid6/algos.c           |  6 ++++
 lib/raid6/neon.c            | 58 ++++++++++++++++++++++++++++++++
 lib/raid6/neon.uc           | 80 +++++++++++++++++++++++++++++++++++++++++++++
 lib/raid6/test/Makefile     | 26 ++++++++++++++-
 14 files changed, 452 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/include/asm/neon.h
 create mode 100644 arch/arm/lib/xor-neon.c
 create mode 100644 lib/raid6/neon.c
 create mode 100644 lib/raid6/neon.uc

-- 
1.8.1.2



From ard.biesheuvel at linaro.org  Mon Jul  8 18:11:57 2013
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  8 Jul 2013 23:11:57 +0100
Subject: [PATCH v3 1/5] ARM: move VFP init to an earlier boot stage
In-Reply-To: <1373321521-15485-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1373321521-15485-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1373321521-15485-2-git-send-email-ard.biesheuvel@linaro.org>

In order to use the NEON unit in the kernel, we should
initialize it a bit earlier in the boot process so NEON users
that like to do a quick benchmark at load time (like the
xor_blocks or RAID-6 code) find the NEON/VFP unit already
enabled.

Replaced late_initcall() with core_initcall().

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Acked-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/vfp/vfpmodule.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 5dfbb0b..791993a 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -731,4 +731,4 @@ static int __init vfp_init(void)
 	return 0;
 }
 
-late_initcall(vfp_init);
+core_initcall(vfp_init);
-- 
1.8.1.2



From ard.biesheuvel at linaro.org  Mon Jul  8 18:11:59 2013
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  8 Jul 2013 23:11:59 +0100
Subject: [PATCH v3 3/5] ARM: add support for kernel mode NEON
In-Reply-To: <1373321521-15485-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1373321521-15485-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1373321521-15485-4-git-send-email-ard.biesheuvel@linaro.org>

In order to safely support the use of NEON instructions in
kernel mode, some precautions need to be taken:
- the userland context that may be present in the registers (even
  if the NEON/VFP is currently disabled) must be stored under the
  correct task (which may not be 'current' in the UP case),
- to avoid having to keep track of additional vfpstates for the
  kernel side, disallow the use of NEON in interrupt context
  and run with preemption disabled,
- after use, re-enable preemption and re-enable the lazy restore
  machinery by disabling the NEON/VFP unit.

This patch adds the functions kernel_neon_begin() and
kernel_neon_end() which take care of the above. It also adds
the Kconfig symbol KERNEL_MODE_NEON to enable it.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Acked-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/Kconfig            |  7 +++++++
 arch/arm/include/asm/neon.h | 36 ++++++++++++++++++++++++++++++++++
 arch/arm/vfp/vfpmodule.c    | 47 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 90 insertions(+)
 create mode 100644 arch/arm/include/asm/neon.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 136f263..d6068b4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2197,6 +2197,13 @@ config NEON
 	  Say Y to include support code for NEON, the ARMv7 Advanced SIMD
 	  Extension.
 
+config KERNEL_MODE_NEON
+	bool "Support for NEON in kernel mode"
+	default n
+	depends on NEON
+	help
+	  Say Y to include support for NEON in kernel mode.
+
 endmenu
 
 menu "Userspace binary formats"
diff --git a/arch/arm/include/asm/neon.h b/arch/arm/include/asm/neon.h
new file mode 100644
index 0000000..8f730fe
--- /dev/null
+++ b/arch/arm/include/asm/neon.h
@@ -0,0 +1,36 @@
+/*
+ * linux/arch/arm/include/asm/neon.h
+ *
+ * Copyright (C) 2013 Linaro Ltd <ard.biesheuvel at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <asm/hwcap.h>
+
+#define cpu_has_neon()		(!!(elf_hwcap & HWCAP_NEON))
+
+#ifdef __ARM_NEON__
+
+/*
+ * If you are affected by the BUILD_BUG below, it probably means that you are
+ * using NEON code /and/ calling the kernel_neon_begin() function from the same
+ * compilation unit. To prevent issues that may arise from GCC reordering or
+ * generating(1) NEON instructions outside of these begin/end functions, the
+ * only supported way of using NEON code in the kernel is by isolating it in a
+ * separate compilation unit, and calling it from another unit from inside a
+ * kernel_neon_begin/kernel_neon_end pair.
+ *
+ * (1) Current GCC (4.7) might generate NEON instructions at O3 level if
+ *     -mpfu=neon is set.
+ */
+
+#define kernel_neon_begin() \
+	BUILD_BUG_ON_MSG(1, "kernel_neon_begin() called from NEON code")
+
+#else
+void kernel_neon_begin(void);
+#endif
+void kernel_neon_end(void);
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 7620831..52b8f40 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -20,6 +20,7 @@
 #include <linux/init.h>
 #include <linux/uaccess.h>
 #include <linux/user.h>
+#include <linux/export.h>
 
 #include <asm/cp15.h>
 #include <asm/cputype.h>
@@ -668,6 +669,52 @@ void vfp_kmode_exception(void)
 		pr_crit("BUG: FP instruction issued in kernel mode with FP unit disabled\n");
 }
 
+#ifdef CONFIG_KERNEL_MODE_NEON
+
+/*
+ * Kernel-side NEON support functions
+ */
+void kernel_neon_begin(void)
+{
+	struct thread_info *thread = current_thread_info();
+	unsigned int cpu;
+	u32 fpexc;
+
+	/*
+	 * Kernel mode NEON is only allowed outside of interrupt context
+	 * with preemption disabled. This will make sure that the kernel
+	 * mode NEON register contents never need to be preserved.
+	 */
+	BUG_ON(in_interrupt());
+	cpu = get_cpu();
+
+	fpexc = fmrx(FPEXC) | FPEXC_EN;
+	fmxr(FPEXC, fpexc);
+
+	/*
+	 * Save the userland NEON/VFP state. Under UP,
+	 * the owner could be a task other than 'current'
+	 */
+	if (vfp_state_in_hw(cpu, thread))
+		vfp_save_state(&thread->vfpstate, fpexc);
+#ifndef CONFIG_SMP
+	else if (vfp_current_hw_state[cpu] != NULL)
+		vfp_save_state(vfp_current_hw_state[cpu], fpexc);
+#endif
+	vfp_current_hw_state[cpu] = NULL;
+}
+EXPORT_SYMBOL(kernel_neon_begin);
+
+void kernel_neon_end(void)
+{
+	/* Disable the NEON/VFP unit. */
+	fmxr(FPEXC, fmrx(FPEXC) & ~FPEXC_EN);
+	put_cpu();
+}
+EXPORT_SYMBOL(kernel_neon_end);
+
+#endif /* CONFIG_KERNEL_MODE_NEON */
+
 /*
  * VFP support code initialisation.
  */
-- 
1.8.1.2



From ard.biesheuvel at linaro.org  Mon Jul  8 18:12:00 2013
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  8 Jul 2013 23:12:00 +0100
Subject: [PATCH v3 4/5] ARM: crypto: add NEON accelerated XOR implementation
In-Reply-To: <1373321521-15485-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1373321521-15485-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1373321521-15485-5-git-send-email-ard.biesheuvel@linaro.org>

Add a source file xor-neon.c (which is really just the reference
C implementation passed through the GCC vectorizer) and hook it
up to the XOR framework.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Acked-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/include/asm/xor.h | 73 ++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm/lib/Makefile      |  6 ++++
 arch/arm/lib/xor-neon.c    | 42 ++++++++++++++++++++++++++
 3 files changed, 121 insertions(+)
 create mode 100644 arch/arm/lib/xor-neon.c

diff --git a/arch/arm/include/asm/xor.h b/arch/arm/include/asm/xor.h
index 7604673..4ffb26d 100644
--- a/arch/arm/include/asm/xor.h
+++ b/arch/arm/include/asm/xor.h
@@ -7,7 +7,10 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+#include <linux/hardirq.h>
 #include <asm-generic/xor.h>
+#include <asm/hwcap.h>
+#include <asm/neon.h>
 
 #define __XOR(a1, a2) a1 ^= a2
 
@@ -138,4 +141,74 @@ static struct xor_block_template xor_block_arm4regs = {
 		xor_speed(&xor_block_arm4regs);	\
 		xor_speed(&xor_block_8regs);	\
 		xor_speed(&xor_block_32regs);	\
+		NEON_TEMPLATES;			\
 	} while (0)
+
+#ifdef CONFIG_KERNEL_MODE_NEON
+
+extern struct xor_block_template const xor_block_neon_inner;
+
+static void
+xor_neon_2(unsigned long bytes, unsigned long *p1, unsigned long *p2)
+{
+	if (in_interrupt()) {
+		xor_arm4regs_2(bytes, p1, p2);
+	} else {
+		kernel_neon_begin();
+		xor_block_neon_inner.do_2(bytes, p1, p2);
+		kernel_neon_end();
+	}
+}
+
+static void
+xor_neon_3(unsigned long bytes, unsigned long *p1, unsigned long *p2,
+		unsigned long *p3)
+{
+	if (in_interrupt()) {
+		xor_arm4regs_3(bytes, p1, p2, p3);
+	} else {
+		kernel_neon_begin();
+		xor_block_neon_inner.do_3(bytes, p1, p2, p3);
+		kernel_neon_end();
+	}
+}
+
+static void
+xor_neon_4(unsigned long bytes, unsigned long *p1, unsigned long *p2,
+		unsigned long *p3, unsigned long *p4)
+{
+	if (in_interrupt()) {
+		xor_arm4regs_4(bytes, p1, p2, p3, p4);
+	} else {
+		kernel_neon_begin();
+		xor_block_neon_inner.do_4(bytes, p1, p2, p3, p4);
+		kernel_neon_end();
+	}
+}
+
+static void
+xor_neon_5(unsigned long bytes, unsigned long *p1, unsigned long *p2,
+		unsigned long *p3, unsigned long *p4, unsigned long *p5)
+{
+	if (in_interrupt()) {
+		xor_arm4regs_5(bytes, p1, p2, p3, p4, p5);
+	} else {
+		kernel_neon_begin();
+		xor_block_neon_inner.do_5(bytes, p1, p2, p3, p4, p5);
+		kernel_neon_end();
+	}
+}
+
+static struct xor_block_template xor_block_neon = {
+	.name	= "neon",
+	.do_2	= xor_neon_2,
+	.do_3	= xor_neon_3,
+	.do_4	= xor_neon_4,
+	.do_5	= xor_neon_5
+};
+
+#define NEON_TEMPLATES	\
+	do { if (cpu_has_neon()) xor_speed(&xor_block_neon); } while (0)
+#else
+#define NEON_TEMPLATES
+#endif
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index af72969..aaf3a87 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -45,3 +45,9 @@ lib-$(CONFIG_ARCH_SHARK)	+= io-shark.o
 
 $(obj)/csumpartialcopy.o:	$(obj)/csumpartialcopygeneric.S
 $(obj)/csumpartialcopyuser.o:	$(obj)/csumpartialcopygeneric.S
+
+ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
+  NEON_FLAGS			:= -mfloat-abi=softfp -mfpu=neon
+  CFLAGS_xor-neon.o		+= $(NEON_FLAGS)
+  lib-$(CONFIG_XOR_BLOCKS)	+= xor-neon.o
+endif
diff --git a/arch/arm/lib/xor-neon.c b/arch/arm/lib/xor-neon.c
new file mode 100644
index 0000000..f485e5a
--- /dev/null
+++ b/arch/arm/lib/xor-neon.c
@@ -0,0 +1,42 @@
+/*
+ * linux/arch/arm/lib/xor-neon.c
+ *
+ * Copyright (C) 2013 Linaro Ltd <ard.biesheuvel at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/raid/xor.h>
+
+#ifndef __ARM_NEON__
+#error You should compile this file with '-mfloat-abi=softfp -mfpu=neon'
+#endif
+
+/*
+ * Pull in the reference implementations while instructing GCC (through
+ * -ftree-vectorize) to attempt to exploit implicit parallelism and emit
+ * NEON instructions.
+ */
+#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
+#pragma GCC optimize "tree-vectorize"
+#else
+/*
+ * While older versions of GCC do not generate incorrect code, they fail to
+ * recognize the parallel nature of these functions, and emit plain ARM code,
+ * which is known to be slower than the optimized ARM code in asm-arm/xor.h.
+ */
+#warning This code requires at least version 4.6 of GCC
+#endif
+
+#pragma GCC diagnostic ignored "-Wunused-variable"
+#include <asm-generic/xor.h>
+
+struct xor_block_template const xor_block_neon_inner = {
+	.name	= "__inner_neon__",
+	.do_2	= xor_8regs_2,
+	.do_3	= xor_8regs_3,
+	.do_4	= xor_8regs_4,
+	.do_5	= xor_8regs_5,
+};
-- 
1.8.1.2



From ard.biesheuvel at linaro.org  Mon Jul  8 18:11:58 2013
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  8 Jul 2013 23:11:58 +0100
Subject: [PATCH v3 2/5] ARM: be strict about FP exceptions in kernel mode
In-Reply-To: <1373321521-15485-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1373321521-15485-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1373321521-15485-3-git-send-email-ard.biesheuvel@linaro.org>

The support code in vfp_support_entry does not care whether the
exception that caused it to be invoked occurred in kernel mode or
in user mode. However, neither condition that could trigger this
exception (lazy restore and VFP bounce to support code) is
currently allowable in kernel mode.

In either case, print a message describing the condition before
letting the undefined instruction handler run its course and trigger
an oops.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Acked-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/vfp/vfphw.S     |  5 +++++
 arch/arm/vfp/vfpmodule.c | 20 ++++++++++++++++++++
 2 files changed, 25 insertions(+)

diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
index 8d10dc8..3e5d311 100644
--- a/arch/arm/vfp/vfphw.S
+++ b/arch/arm/vfp/vfphw.S
@@ -78,6 +78,11 @@
 ENTRY(vfp_support_entry)
 	DBGSTR3	"instr %08x pc %08x state %p", r0, r2, r10
 
+	ldr	r3, [sp, #S_PSR]	@ Neither lazy restore nor FP exceptions
+	and	r3, r3, #MODE_MASK	@ are supported in kernel mode
+	teq	r3, #USR_MODE
+	bne	vfp_kmode_exception	@ Returns through lr
+
 	VFPFMRX	r1, FPEXC		@ Is the VFP enabled?
 	DBGSTR1	"fpexc %08x", r1
 	tst	r1, #FPEXC_EN
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 791993a..7620831 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -648,6 +648,26 @@ static int vfp_hotplug(struct notifier_block *b, unsigned long action,
 	return NOTIFY_OK;
 }
 
+void vfp_kmode_exception(void)
+{
+	/*
+	 * If we reach this point, a floating point exception has been raised
+	 * while running in kernel mode. If the NEON/VFP unit was enabled at the
+	 * time, it means a VFP instruction has been issued that requires
+	 * software assistance to complete, something which is not currently
+	 * supported in kernel mode.
+	 * If the NEON/VFP unit was disabled, and the location pointed to below
+	 * is properly preceded by a call to kernel_neon_begin(), something has
+	 * caused the task to be scheduled out and back in again. In this case,
+	 * rebuilding and running with CONFIG_DEBUG_ATOMIC_SLEEP enabled should
+	 * be helpful in localizing the problem.
+	 */
+	if (fmrx(FPEXC) & FPEXC_EN)
+		pr_crit("BUG: unsupported FP instruction in kernel mode\n");
+	else
+		pr_crit("BUG: FP instruction issued in kernel mode with FP unit disabled\n");
+}
+
 /*
  * VFP support code initialisation.
  */
-- 
1.8.1.2



From ard.biesheuvel at linaro.org  Mon Jul  8 18:12:01 2013
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  8 Jul 2013 23:12:01 +0100
Subject: [PATCH v3 5/5] lib/raid6: add ARM-NEON accelerated syndrome
 calculation
In-Reply-To: <1373321521-15485-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1373321521-15485-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1373321521-15485-6-git-send-email-ard.biesheuvel@linaro.org>

Rebased/reworked a patch contributed by Rob Herring that uses
NEON intrinsics to perform the RAID-6 syndrome calculations.
It uses the existing unroll.awk code to generate several
unrolled versions of which the best performing one is selected
at boot time.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Acked-by: Nicolas Pitre <nico at linaro.org>
Cc: hpa at linux.intel.com
---
 include/linux/raid/pq.h |  5 ++++
 lib/raid6/.gitignore    |  1 +
 lib/raid6/Makefile      | 40 +++++++++++++++++++++++++
 lib/raid6/algos.c       |  6 ++++
 lib/raid6/neon.c        | 58 +++++++++++++++++++++++++++++++++++
 lib/raid6/neon.uc       | 80 +++++++++++++++++++++++++++++++++++++++++++++++++
 lib/raid6/test/Makefile | 26 +++++++++++++++-
 7 files changed, 215 insertions(+), 1 deletion(-)
 create mode 100644 lib/raid6/neon.c
 create mode 100644 lib/raid6/neon.uc

diff --git a/include/linux/raid/pq.h b/include/linux/raid/pq.h
index 8dfaa2c..0f42469 100644
--- a/include/linux/raid/pq.h
+++ b/include/linux/raid/pq.h
@@ -114,6 +114,11 @@ extern const struct raid6_recov_calls raid6_recov_intx1;
 extern const struct raid6_recov_calls raid6_recov_ssse3;
 extern const struct raid6_recov_calls raid6_recov_avx2;
 
+extern const struct raid6_calls raid6_neonx1;
+extern const struct raid6_calls raid6_neonx2;
+extern const struct raid6_calls raid6_neonx4;
+extern const struct raid6_calls raid6_neonx8;
+
 /* Algorithm list */
 extern const struct raid6_calls * const raid6_algos[];
 extern const struct raid6_recov_calls *const raid6_recov_algos[];
diff --git a/lib/raid6/.gitignore b/lib/raid6/.gitignore
index 162beca..0a7e494 100644
--- a/lib/raid6/.gitignore
+++ b/lib/raid6/.gitignore
@@ -2,3 +2,4 @@ mktables
 altivec*.c
 int*.c
 tables.c
+neon?.c
diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
index 9f7c184..b462578 100644
--- a/lib/raid6/Makefile
+++ b/lib/raid6/Makefile
@@ -5,6 +5,7 @@ raid6_pq-y	+= algos.o recov.o tables.o int1.o int2.o int4.o \
 
 raid6_pq-$(CONFIG_X86) += recov_ssse3.o recov_avx2.o mmx.o sse1.o sse2.o avx2.o
 raid6_pq-$(CONFIG_ALTIVEC) += altivec1.o altivec2.o altivec4.o altivec8.o
+raid6_pq-$(CONFIG_KERNEL_MODE_NEON) += neon.o neon1.o neon2.o neon4.o neon8.o
 
 hostprogs-y	+= mktables
 
@@ -16,6 +17,21 @@ ifeq ($(CONFIG_ALTIVEC),y)
 altivec_flags := -maltivec -mabi=altivec
 endif
 
+# The GCC option -ffreestanding is required in order to compile code containing
+# ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)
+ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
+NEON_FLAGS := -ffreestanding
+ifeq ($(ARCH),arm)
+NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon
+endif
+ifeq ($(ARCH),arm64)
+CFLAGS_REMOVE_neon1.o += -mgeneral-regs-only
+CFLAGS_REMOVE_neon2.o += -mgeneral-regs-only
+CFLAGS_REMOVE_neon4.o += -mgeneral-regs-only
+CFLAGS_REMOVE_neon8.o += -mgeneral-regs-only
+endif
+endif
+
 targets += int1.c
 $(obj)/int1.c:   UNROLL := 1
 $(obj)/int1.c:   $(src)/int.uc $(src)/unroll.awk FORCE
@@ -70,6 +86,30 @@ $(obj)/altivec8.c:   UNROLL := 8
 $(obj)/altivec8.c:   $(src)/altivec.uc $(src)/unroll.awk FORCE
 	$(call if_changed,unroll)
 
+CFLAGS_neon1.o += $(NEON_FLAGS)
+targets += neon1.c
+$(obj)/neon1.c:   UNROLL := 1
+$(obj)/neon1.c:   $(src)/neon.uc $(src)/unroll.awk FORCE
+	$(call if_changed,unroll)
+
+CFLAGS_neon2.o += $(NEON_FLAGS)
+targets += neon2.c
+$(obj)/neon2.c:   UNROLL := 2
+$(obj)/neon2.c:   $(src)/neon.uc $(src)/unroll.awk FORCE
+	$(call if_changed,unroll)
+
+CFLAGS_neon4.o += $(NEON_FLAGS)
+targets += neon4.c
+$(obj)/neon4.c:   UNROLL := 4
+$(obj)/neon4.c:   $(src)/neon.uc $(src)/unroll.awk FORCE
+	$(call if_changed,unroll)
+
+CFLAGS_neon8.o += $(NEON_FLAGS)
+targets += neon8.c
+$(obj)/neon8.c:   UNROLL := 8
+$(obj)/neon8.c:   $(src)/neon.uc $(src)/unroll.awk FORCE
+	$(call if_changed,unroll)
+
 quiet_cmd_mktable = TABLE   $@
       cmd_mktable = $(obj)/mktables > $@ || ( rm -f $@ && exit 1 )
 
diff --git a/lib/raid6/algos.c b/lib/raid6/algos.c
index 6d7316f..74e6f56 100644
--- a/lib/raid6/algos.c
+++ b/lib/raid6/algos.c
@@ -70,6 +70,12 @@ const struct raid6_calls * const raid6_algos[] = {
 	&raid6_intx2,
 	&raid6_intx4,
 	&raid6_intx8,
+#ifdef CONFIG_KERNEL_MODE_NEON
+	&raid6_neonx1,
+	&raid6_neonx2,
+	&raid6_neonx4,
+	&raid6_neonx8,
+#endif
 	NULL
 };
 
diff --git a/lib/raid6/neon.c b/lib/raid6/neon.c
new file mode 100644
index 0000000..36ad470
--- /dev/null
+++ b/lib/raid6/neon.c
@@ -0,0 +1,58 @@
+/*
+ * linux/lib/raid6/neon.c - RAID6 syndrome calculation using ARM NEON intrinsics
+ *
+ * Copyright (C) 2013 Linaro Ltd <ard.biesheuvel at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/raid/pq.h>
+
+#ifdef __KERNEL__
+#include <asm/neon.h>
+#else
+#define kernel_neon_begin()
+#define kernel_neon_end()
+#define cpu_has_neon()		(1)
+#endif
+
+/*
+ * There are 2 reasons these wrappers are kept in a separate compilation unit
+ * from the actual implementations in neonN.c (generated from neon.uc by
+ * unroll.awk):
+ * - the actual implementations use NEON intrinsics, and the GCC support header
+ *   (arm_neon.h) is not fully compatible (type wise) with the kernel;
+ * - the neonN.c files are compiled with -mfpu=neon and optimization enabled,
+ *   and we have to make sure that we never use *any* NEON/VFP instructions
+ *   outside a kernel_neon_begin()/kernel_neon_end() pair.
+ */
+
+#define RAID6_NEON_WRAPPER(_n)						\
+	static void raid6_neon ## _n ## _gen_syndrome(int disks,	\
+					size_t bytes, void **ptrs)	\
+	{								\
+		void raid6_neon ## _n  ## _gen_syndrome_real(int,	\
+						unsigned long, void**);	\
+		kernel_neon_begin();					\
+		raid6_neon ## _n ## _gen_syndrome_real(disks,		\
+					(unsigned long)bytes, ptrs);	\
+		kernel_neon_end();					\
+	}								\
+	struct raid6_calls const raid6_neonx ## _n = {			\
+		raid6_neon ## _n ## _gen_syndrome,			\
+		raid6_have_neon,					\
+		"neonx" #_n,						\
+		0							\
+	}
+
+static int raid6_have_neon(void)
+{
+	return cpu_has_neon();
+}
+
+RAID6_NEON_WRAPPER(1);
+RAID6_NEON_WRAPPER(2);
+RAID6_NEON_WRAPPER(4);
+RAID6_NEON_WRAPPER(8);
diff --git a/lib/raid6/neon.uc b/lib/raid6/neon.uc
new file mode 100644
index 0000000..1b9ed79
--- /dev/null
+++ b/lib/raid6/neon.uc
@@ -0,0 +1,80 @@
+/* -----------------------------------------------------------------------
+ *
+ *   neon.uc - RAID-6 syndrome calculation using ARM NEON instructions
+ *
+ *   Copyright (C) 2012 Rob Herring
+ *
+ *   Based on altivec.uc:
+ *     Copyright 2002-2004 H. Peter Anvin - All Rights Reserved
+ *
+ *   This program is free software; you can redistribute it and/or modify
+ *   it under the terms of the GNU General Public License as published by
+ *   the Free Software Foundation, Inc., 53 Temple Place Ste 330,
+ *   Boston MA 02111-1307, USA; either version 2 of the License, or
+ *   (at your option) any later version; incorporated herein by reference.
+ *
+ * ----------------------------------------------------------------------- */
+
+/*
+ * neon$#.c
+ *
+ * $#-way unrolled NEON intrinsics math RAID-6 instruction set
+ *
+ * This file is postprocessed using unroll.awk
+ */
+
+#include <arm_neon.h>
+
+typedef uint8x16_t unative_t;
+
+#define NBYTES(x) ((unative_t){x,x,x,x, x,x,x,x, x,x,x,x, x,x,x,x})
+#define NSIZE	sizeof(unative_t)
+
+/*
+ * The SHLBYTE() operation shifts each byte left by 1, *not*
+ * rolling over into the next byte
+ */
+static inline unative_t SHLBYTE(unative_t v)
+{
+	return vshlq_n_u8(v, 1);
+}
+
+/*
+ * The MASK() operation returns 0xFF in any byte for which the high
+ * bit is 1, 0x00 for any byte for which the high bit is 0.
+ */
+static inline unative_t MASK(unative_t v)
+{
+	const uint8x16_t temp = NBYTES(0);
+	return (unative_t)vcltq_s8((int8x16_t)v, (int8x16_t)temp);
+}
+
+void raid6_neon$#_gen_syndrome_real(int disks, unsigned long bytes, void **ptrs)
+{
+	uint8_t **dptr = (uint8_t **)ptrs;
+	uint8_t *p, *q;
+	int d, z, z0;
+
+	register unative_t wd$$, wq$$, wp$$, w1$$, w2$$;
+	const unative_t x1d = NBYTES(0x1d);
+
+	z0 = disks - 3;		/* Highest data disk */
+	p = dptr[z0+1];		/* XOR parity */
+	q = dptr[z0+2];		/* RS syndrome */
+
+	for ( d = 0 ; d < bytes ; d += NSIZE*$# ) {
+		wq$$ = wp$$ = vld1q_u8(&dptr[z0][d+$$*NSIZE]);
+		for ( z = z0-1 ; z >= 0 ; z-- ) {
+			wd$$ = vld1q_u8(&dptr[z][d+$$*NSIZE]);
+			wp$$ = veorq_u8(wp$$, wd$$);
+			w2$$ = MASK(wq$$);
+			w1$$ = SHLBYTE(wq$$);
+
+			w2$$ = vandq_u8(w2$$, x1d);
+			w1$$ = veorq_u8(w1$$, w2$$);
+			wq$$ = veorq_u8(w1$$, wd$$);
+		}
+		vst1q_u8(&p[d+NSIZE*$$], wp$$);
+		vst1q_u8(&q[d+NSIZE*$$], wq$$);
+	}
+}
diff --git a/lib/raid6/test/Makefile b/lib/raid6/test/Makefile
index 087332d..28afa1a 100644
--- a/lib/raid6/test/Makefile
+++ b/lib/raid6/test/Makefile
@@ -22,11 +22,23 @@ ifeq ($(ARCH),x86_64)
         IS_X86 = yes
 endif
 
+ifeq ($(ARCH),arm)
+        CFLAGS += -I../../../arch/arm/include -mfpu=neon
+        HAS_NEON = yes
+endif
+ifeq ($(ARCH),arm64)
+        CFLAGS += -I../../../arch/arm64/include
+        HAS_NEON = yes
+endif
+
 ifeq ($(IS_X86),yes)
         OBJS   += mmx.o sse1.o sse2.o avx2.o recov_ssse3.o recov_avx2.o
         CFLAGS += $(shell echo "vpbroadcastb %xmm0, %ymm1" |	\
                     gcc -c -x assembler - >&/dev/null &&	\
                     rm ./-.o && echo -DCONFIG_AS_AVX2=1)
+else ifeq ($(HAS_NEON),yes)
+        OBJS   += neon.o neon1.o neon2.o neon4.o neon8.o
+        CFLAGS += -DCONFIG_KERNEL_MODE_NEON=1
 else
         HAS_ALTIVEC := $(shell echo -e '\#include <altivec.h>\nvector int a;' |\
                          gcc -c -x c - >&/dev/null && \
@@ -55,6 +67,18 @@ raid6.a: $(OBJS)
 raid6test: test.c raid6.a
 	$(CC) $(CFLAGS) -o raid6test $^
 
+neon1.c: neon.uc ../unroll.awk
+	$(AWK) ../unroll.awk -vN=1 < neon.uc > $@
+
+neon2.c: neon.uc ../unroll.awk
+	$(AWK) ../unroll.awk -vN=2 < neon.uc > $@
+
+neon4.c: neon.uc ../unroll.awk
+	$(AWK) ../unroll.awk -vN=4 < neon.uc > $@
+
+neon8.c: neon.uc ../unroll.awk
+	$(AWK) ../unroll.awk -vN=8 < neon.uc > $@
+
 altivec1.c: altivec.uc ../unroll.awk
 	$(AWK) ../unroll.awk -vN=1 < altivec.uc > $@
 
@@ -89,7 +113,7 @@ tables.c: mktables
 	./mktables > tables.c
 
 clean:
-	rm -f *.o *.a mktables mktables.c *.uc int*.c altivec*.c tables.c raid6test
+	rm -f *.o *.a mktables mktables.c *.uc int*.c altivec*.c neon*.c tables.c raid6test
 
 spotless: clean
 	rm -f *~
-- 
1.8.1.2



From hpa at linux.intel.com  Mon Jul  8 18:16:14 2013
From: hpa at linux.intel.com (H. Peter Anvin)
Date: Mon, 08 Jul 2013 15:16:14 -0700
Subject: [PATCH v3 5/5] lib/raid6: add ARM-NEON accelerated syndrome
 calculation
In-Reply-To: <1373321521-15485-6-git-send-email-ard.biesheuvel@linaro.org>
References: <1373321521-15485-1-git-send-email-ard.biesheuvel@linaro.org>
 <1373321521-15485-6-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <51DB3A2E.9070409@linux.intel.com>

On 07/08/2013 03:12 PM, Ard Biesheuvel wrote:
> Rebased/reworked a patch contributed by Rob Herring that uses
> NEON intrinsics to perform the RAID-6 syndrome calculations.
> It uses the existing unroll.awk code to generate several
> unrolled versions of which the best performing one is selected
> at boot time.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> Acked-by: Nicolas Pitre <nico at linaro.org>
> Cc: hpa at linux.intel.com

I can't comment on the correctness of the code since I'm not familiar
with the Neon instruction set, but I don't see anything inherently
problematic with the patchset either.

	-hpa




From ard.biesheuvel at linaro.org  Mon Jul  8 18:23:11 2013
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 8 Jul 2013 23:23:11 +0100
Subject: [GIT PULL] ARM: kernel mode NEON support
Message-ID: <CAKv+Gu_0XXdCw4-V6LLHCiaH4Wc+=4DTzP6gwgV_h-Qb90gYTA@mail.gmail.com>

The following changes since commit 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376:

  Linux 3.10 (2013-06-30 15:13:29 -0700)

are available in the git repository at:

  git://git.linaro.org/people/ardbiesheuvel/linux-arm.git for-rmk

for you to fetch changes up to 7d11965ddb9b9b1e0a5d13c58345ada1ccbc663b:

  lib/raid6: add ARM-NEON accelerated syndrome calculation (2013-07-08
22:09:18 +0100)

----------------------------------------------------------------
Ard Biesheuvel (5):
      ARM: move VFP init to an earlier boot stage
      ARM: be strict about FP exceptions in kernel mode
      ARM: add support for kernel mode NEON
      ARM: crypto: add NEON accelerated XOR implementation
      lib/raid6: add ARM-NEON accelerated syndrome calculation

 arch/arm/Kconfig            |  7 +++++++
 arch/arm/include/asm/neon.h | 36 ++++++++++++++++++++++++++++++++++++
 arch/arm/include/asm/xor.h  | 73
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm/lib/Makefile       |  6 ++++++
 arch/arm/lib/xor-neon.c     | 42 ++++++++++++++++++++++++++++++++++++++++++
 arch/arm/vfp/vfphw.S        |  5 +++++
 arch/arm/vfp/vfpmodule.c    | 69
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 include/linux/raid/pq.h     |  5 +++++
 lib/raid6/.gitignore        |  1 +
 lib/raid6/Makefile          | 40 ++++++++++++++++++++++++++++++++++++++++
 lib/raid6/algos.c           |  6 ++++++
 lib/raid6/neon.c            | 58
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 lib/raid6/neon.uc           | 80
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 lib/raid6/test/Makefile     | 26 +++++++++++++++++++++++++-
 14 files changed, 452 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/include/asm/neon.h
 create mode 100644 arch/arm/lib/xor-neon.c
 create mode 100644 lib/raid6/neon.c
 create mode 100644 lib/raid6/neon.uc


From festevam at gmail.com  Mon Jul  8 18:36:45 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 8 Jul 2013 19:36:45 -0300
Subject: mx6q boot on linux-next 20130703
In-Reply-To: <20130704064149.GD14617@S2101-09.ap.freescale.net>
References: <CAOMZO5DgAu2-cknESp4a675KP5gDrJxM2A_FqUgAZav83Db=fw@mail.gmail.com>
 <CAOMZO5AvXJJHmoEu3BMN=EYCxS4O1-2ivsSzS2eCuyPeiw_brQ@mail.gmail.com>
 <20130704064149.GD14617@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5ALV-cMaMfcgy6QD2=nA=R8xAGMmd=jbm1uWVFsvs-0vA@mail.gmail.com>

On Thu, Jul 4, 2013 at 3:41 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> On Thu, Jul 04, 2013 at 01:08:13AM -0300, Fabio Estevam wrote:
>> On Wed, Jul 3, 2013 at 8:52 PM, Fabio Estevam <festevam at gmail.com> wrote:
>> > Hi,
>> >
>> > I am running linux-next 20130703 on a mx6q board, and seeing a strange
>> > behaviour.
>> >
>> > Only if I enable DEBUG_LL + earlyprintk and disable
>
> Yes, I see the issue here too, and turning on earlyprintk can remove the
> issue.

linux-next 20130708 does not have this issue anymore.


From swarren at wwwdotorg.org  Mon Jul  8 18:44:55 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon,  8 Jul 2013 16:44:55 -0600
Subject: [PATCH] ARM: mm: restrict early_alloc_aligned to legal area
Message-ID: <1373323495-10087-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

When early_alloc_aligned() is called, it appears that only memory in the
first memory bank is mapped for CPU access. However, memblock_alloc() is
called to allocate the RAM, and that can return RAM that is part of any
valid memory bank, which hence could be inaccessible to the CPU. If this
happens, the subsequent memset() will hang or crash.

Solve this by calling memblock_alloc_base() instead of memblock_alloc().
This function takes an explicit max address. Use the end of the first
memory bank as the address.

As an example, this issue can be triggered as follows:

* Total of 512MB system RAM, so it is all lowmem not highmem. Without this,
  subsequent banks may be ignored by map_lowmem() due to being highmem.
* RAM is split into multiple banks, due to some RAM somewhere in the
  middle having been allocated for purposes other than Linux, e.g. an LCD
  frame-buffer of for a co-processor.
* Some bank is not section-aligned, so that alloc_init_pte() is called
  rather than __map_init_section().

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mm/mmu.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index d7229d2..0849741 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -585,7 +585,10 @@ EXPORT_SYMBOL(phys_mem_access_prot);
 
 static void __init *early_alloc_aligned(unsigned long sz, unsigned long align)
 {
-	void *ptr = __va(memblock_alloc(sz, align));
+	phys_addr_t max_pa = memblock.memory.regions[0].base +
+				memblock.memory.regions[0].size;
+	phys_addr_t pa = memblock_alloc_base(sz, align, max_pa);
+	void *ptr = __va(pa);
 	memset(ptr, 0, sz);
 	return ptr;
 }
-- 
1.8.1.5



From arnd at arndb.de  Mon Jul  8 19:03:27 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Jul 2013 01:03:27 +0200
Subject: [PATCH v3 4/4] ARM: reinsert ARCH_MULTI_V4 Kconfig option
In-Reply-To: <CACmBeS3Ges44HxOGZns+G=jQhSmGjVmZBir2_ZBXT1i2nrNQwg@mail.gmail.com>
References: <1372949142-8260-1-git-send-email-jonas.jensen@gmail.com>
 <CACmBeS3Ges44HxOGZns+G=jQhSmGjVmZBir2_ZBXT1i2nrNQwg@mail.gmail.com>
Message-ID: <201307090103.27296.arnd@arndb.de>

On Monday 08 July 2013, Jonas Jensen wrote:
> Arnd suggested removing one (or many) of the options:
> 
> CPU_ABRT_EV4T
> CPU_CACHE_V4WT
> CPU_COPY_V4WB
> CPU_TLB_V4WBI
> 
> However boot is still broken after removing all including CPU_32v4T.
> 
> Selecting CPU_SA1100 instead, it boots normally and init works.
> 
> The idea is, If you can help figure out what exactly breaks boot, the
> patch can be dropped.
> 
> From these tests, I have created two branches ( arch/arm/mm have
> replacements for calls to no longer compiled in ):
> 
> http://code.google.com/p/linux-next-20130703-moxart/source/detail?r=a88f33ad22d3f9a31fe126f1c95568e5b2e8f32d&name=multi_V4_test_arm920t
> http://code.google.com/p/linux-next-20130703-moxart/source/detail?r=9f4c21f1123a122c51792cd374217ce6e426e74a&name=multi_V4_test_sa1100

It looks like you select CPU_ARM926T but change the entry for CPU_ARM920T
instead, which would have no effect then.

	Arnd


From eduardo.valentin at ti.com  Mon Jul  8 19:12:44 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Mon, 8 Jul 2013 19:12:44 -0400
Subject: [PATCH v4] thermal: add imx thermal driver support
In-Reply-To: <1372055444-5286-1-git-send-email-shawn.guo@linaro.org>
References: <1372055444-5286-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <51DB476C.6090803@ti.com>

On 24-06-2013 02:30, Shawn Guo wrote:
> This is based on the initial imx thermal work done by
> Rob Lee <rob.lee at linaro.org> (Not sure if the email address is still
> valid).  Since he is no longer interested in the work and I have
> rewritten a significant amount of the code, I just took the authorship
> over from him.
> 
> It adds the imx thermal support using Temperature Monitor (TEMPMON)
> block found on some Freescale i.MX SoCs.  The driver uses syscon regmap
> interface to access TEMPMON control registers and calibration data, and
> supports cpufreq as the cooling device.
> 
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>

Merged on linux-soc-thermal, branch for_3.12/imx. It will be queued on
next merge window. To late for this one.

> ---
> Changes since v3:
>  * Fix a couple of typos
>  * Use "GPL v2" for MODULE_LICENSE()
> 
>  .../devicetree/bindings/thermal/imx-thermal.txt    |   17 +
>  drivers/thermal/Kconfig                            |   11 +
>  drivers/thermal/Makefile                           |    1 +
>  drivers/thermal/imx_thermal.c                      |  397 ++++++++++++++++++++
>  4 files changed, 426 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/thermal/imx-thermal.txt
>  create mode 100644 drivers/thermal/imx_thermal.c
> 
> diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.txt b/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> new file mode 100644
> index 0000000..541c25e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> @@ -0,0 +1,17 @@
> +* Temperature Monitor (TEMPMON) on Freescale i.MX SoCs
> +
> +Required properties:
> +- compatible : "fsl,imx6q-thermal"
> +- fsl,tempmon : phandle pointer to system controller that contains TEMPMON
> +  control registers, e.g. ANATOP on imx6q.
> +- fsl,tempmon-data : phandle pointer to fuse controller that contains TEMPMON
> +  calibration data, e.g. OCOTP on imx6q.  The details about calibration data
> +  can be found in SoC Reference Manual.
> +
> +Example:
> +
> +tempmon {
> +	compatible = "fsl,imx6q-tempmon";
> +	fsl,tempmon = <&anatop>;
> +	fsl,tempmon-data = <&ocotp>;
> +};
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index b13c2bc..22a702e 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -91,6 +91,17 @@ config THERMAL_EMULATION
>  	  because userland can easily disable the thermal policy by simply
>  	  flooding this sysfs node with low temperature values.
>  
> +config IMX_THERMAL
> +	tristate "Temperature sensor driver for Freescale i.MX SoCs"
> +	depends on CPU_THERMAL
> +	depends on MFD_SYSCON
> +	depends on OF
> +	help
> +	  Support for Temperature Monitor (TEMPMON) found on Freescale i.MX SoCs.
> +	  It supports one critical trip point and one passive trip point.  The
> +	  cpufreq is used as the cooling device to throttle CPUs when the
> +	  passive trip is crossed.
> +
>  config SPEAR_THERMAL
>  	bool "SPEAr thermal sensor driver"
>  	depends on PLAT_SPEAR
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 67184a2..dff19c6 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_EXYNOS_THERMAL)	+= exynos_thermal.o
>  obj-$(CONFIG_DOVE_THERMAL)  	+= dove_thermal.o
>  obj-$(CONFIG_DB8500_THERMAL)	+= db8500_thermal.o
>  obj-$(CONFIG_ARMADA_THERMAL)	+= armada_thermal.o
> +obj-$(CONFIG_IMX_THERMAL)	+= imx_thermal.o
>  obj-$(CONFIG_DB8500_CPUFREQ_COOLING)	+= db8500_cpufreq_cooling.o
>  obj-$(CONFIG_INTEL_POWERCLAMP)	+= intel_powerclamp.o
>  obj-$(CONFIG_X86_PKG_TEMP_THERMAL)	+= x86_pkg_temp_thermal.o
> diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
> new file mode 100644
> index 0000000..d16c33c
> --- /dev/null
> +++ b/drivers/thermal/imx_thermal.c
> @@ -0,0 +1,397 @@
> +/*
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include <linux/cpu_cooling.h>
> +#include <linux/cpufreq.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/thermal.h>
> +#include <linux/types.h>
> +
> +#define REG_SET		0x4
> +#define REG_CLR		0x8
> +#define REG_TOG		0xc
> +
> +#define MISC0				0x0150
> +#define MISC0_REFTOP_SELBIASOFF		(1 << 3)
> +
> +#define TEMPSENSE0			0x0180
> +#define TEMPSENSE0_TEMP_CNT_SHIFT	8
> +#define TEMPSENSE0_TEMP_CNT_MASK	(0xfff << TEMPSENSE0_TEMP_CNT_SHIFT)
> +#define TEMPSENSE0_FINISHED		(1 << 2)
> +#define TEMPSENSE0_MEASURE_TEMP		(1 << 1)
> +#define TEMPSENSE0_POWER_DOWN		(1 << 0)
> +
> +#define TEMPSENSE1			0x0190
> +#define TEMPSENSE1_MEASURE_FREQ		0xffff
> +
> +#define OCOTP_ANA1			0x04e0
> +
> +/* The driver supports 1 passive trip point and 1 critical trip point */
> +enum imx_thermal_trip {
> +	IMX_TRIP_PASSIVE,
> +	IMX_TRIP_CRITICAL,
> +	IMX_TRIP_NUM,
> +};
> +
> +/*
> + * It defines the temperature in millicelsius for passive trip point
> + * that will trigger cooling action when crossed.
> + */
> +#define IMX_TEMP_PASSIVE		85000
> +
> +/*
> + * The maximum die temperature on imx parts is 105C, let's give some cushion
> + * for noise and possible temperature rise between measurements.
> + */
> +#define IMX_TEMP_CRITICAL		100000
> +
> +#define IMX_POLLING_DELAY		2000 /* millisecond */
> +#define IMX_PASSIVE_DELAY		1000
> +
> +struct imx_thermal_data {
> +	struct thermal_zone_device *tz;
> +	struct thermal_cooling_device *cdev;
> +	enum thermal_device_mode mode;
> +	struct regmap *tempmon;
> +	int c1, c2; /* See formula in imx_get_sensor_data() */
> +};
> +
> +static int imx_get_temp(struct thermal_zone_device *tz, unsigned long *temp)
> +{
> +	struct imx_thermal_data *data = tz->devdata;
> +	struct regmap *map = data->tempmon;
> +	static unsigned long last_temp;
> +	unsigned int n_meas;
> +	u32 val;
> +
> +	/*
> +	 * Every time we measure the temperature, we will power on the
> +	 * temperature sensor, enable measurements, take a reading,
> +	 * disable measurements, power off the temperature sensor.
> +	 */
> +	regmap_write(map, TEMPSENSE0 + REG_CLR, TEMPSENSE0_POWER_DOWN);
> +	regmap_write(map, TEMPSENSE0 + REG_SET, TEMPSENSE0_MEASURE_TEMP);
> +
> +	/*
> +	 * According to the temp sensor designers, it may require up to ~17us
> +	 * to complete a measurement.
> +	 */
> +	usleep_range(20, 50);
> +
> +	regmap_read(map, TEMPSENSE0, &val);
> +	regmap_write(map, TEMPSENSE0 + REG_CLR, TEMPSENSE0_MEASURE_TEMP);
> +	regmap_write(map, TEMPSENSE0 + REG_SET, TEMPSENSE0_POWER_DOWN);
> +
> +	if ((val & TEMPSENSE0_FINISHED) == 0) {
> +		dev_dbg(&tz->device, "temp measurement never finished\n");
> +		return -EAGAIN;
> +	}
> +
> +	n_meas = (val & TEMPSENSE0_TEMP_CNT_MASK) >> TEMPSENSE0_TEMP_CNT_SHIFT;
> +
> +	/* See imx_get_sensor_data() for formula derivation */
> +	*temp = data->c2 + data->c1 * n_meas;
> +
> +	if (*temp != last_temp) {
> +		dev_dbg(&tz->device, "millicelsius: %ld\n", *temp);
> +		last_temp = *temp;
> +	}
> +
> +	return 0;
> +}
> +
> +static int imx_get_mode(struct thermal_zone_device *tz,
> +			enum thermal_device_mode *mode)
> +{
> +	struct imx_thermal_data *data = tz->devdata;
> +
> +	*mode = data->mode;
> +
> +	return 0;
> +}
> +
> +static int imx_set_mode(struct thermal_zone_device *tz,
> +			enum thermal_device_mode mode)
> +{
> +	struct imx_thermal_data *data = tz->devdata;
> +
> +	if (mode == THERMAL_DEVICE_ENABLED) {
> +		tz->polling_delay = IMX_POLLING_DELAY;
> +		tz->passive_delay = IMX_PASSIVE_DELAY;
> +	} else {
> +		tz->polling_delay = 0;
> +		tz->passive_delay = 0;
> +	}
> +
> +	data->mode = mode;
> +	thermal_zone_device_update(tz);
> +
> +	return 0;
> +}
> +
> +static int imx_get_trip_type(struct thermal_zone_device *tz, int trip,
> +			     enum thermal_trip_type *type)
> +{
> +	*type = (trip == IMX_TRIP_PASSIVE) ? THERMAL_TRIP_PASSIVE :
> +					     THERMAL_TRIP_CRITICAL;
> +	return 0;
> +}
> +
> +static int imx_get_crit_temp(struct thermal_zone_device *tz,
> +			     unsigned long *temp)
> +{
> +	*temp = IMX_TEMP_CRITICAL;
> +	return 0;
> +}
> +
> +static int imx_get_trip_temp(struct thermal_zone_device *tz, int trip,
> +			     unsigned long *temp)
> +{
> +	*temp = (trip == IMX_TRIP_PASSIVE) ? IMX_TEMP_PASSIVE :
> +					     IMX_TEMP_CRITICAL;
> +	return 0;
> +}
> +
> +static int imx_bind(struct thermal_zone_device *tz,
> +		    struct thermal_cooling_device *cdev)
> +{
> +	int ret;
> +
> +	ret = thermal_zone_bind_cooling_device(tz, IMX_TRIP_PASSIVE, cdev,
> +					       THERMAL_NO_LIMIT,
> +					       THERMAL_NO_LIMIT);
> +	if (ret) {
> +		dev_err(&tz->device,
> +			"binding zone %s with cdev %s failed:%d\n",
> +			tz->type, cdev->type, ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int imx_unbind(struct thermal_zone_device *tz,
> +		      struct thermal_cooling_device *cdev)
> +{
> +	int ret;
> +
> +	ret = thermal_zone_unbind_cooling_device(tz, IMX_TRIP_PASSIVE, cdev);
> +	if (ret) {
> +		dev_err(&tz->device,
> +			"unbinding zone %s with cdev %s failed:%d\n",
> +			tz->type, cdev->type, ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct thermal_zone_device_ops imx_tz_ops = {
> +	.bind = imx_bind,
> +	.unbind = imx_unbind,
> +	.get_temp = imx_get_temp,
> +	.get_mode = imx_get_mode,
> +	.set_mode = imx_set_mode,
> +	.get_trip_type = imx_get_trip_type,
> +	.get_trip_temp = imx_get_trip_temp,
> +	.get_crit_temp = imx_get_crit_temp,
> +};
> +
> +static int imx_get_sensor_data(struct platform_device *pdev)
> +{
> +	struct imx_thermal_data *data = platform_get_drvdata(pdev);
> +	struct regmap *map;
> +	int t1, t2, n1, n2;
> +	int ret;
> +	u32 val;
> +
> +	map = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> +					      "fsl,tempmon-data");
> +	if (IS_ERR(map)) {
> +		ret = PTR_ERR(map);
> +		dev_err(&pdev->dev, "failed to get sensor regmap: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = regmap_read(map, OCOTP_ANA1, &val);
> +	if (ret) {
> +		dev_err(&pdev->dev, "failed to read sensor data: %d\n", ret);
> +		return ret;
> +	}
> +
> +	if (val == 0 || val == ~0) {
> +		dev_err(&pdev->dev, "invalid sensor calibration data\n");
> +		return -EINVAL;
> +	}
> +
> +	/*
> +	 * Sensor data layout:
> +	 *   [31:20] - sensor value @ 25C
> +	 *    [19:8] - sensor value of hot
> +	 *     [7:0] - hot temperature value
> +	 */
> +	n1 = val >> 20;
> +	n2 = (val & 0xfff00) >> 8;
> +	t2 = val & 0xff;
> +	t1 = 25; /* t1 always 25C */
> +
> +	/*
> +	 * Derived from linear interpolation,
> +	 * Tmeas = T2 + (Nmeas - N2) * (T1 - T2) / (N1 - N2)
> +	 * We want to reduce this down to the minimum computation necessary
> +	 * for each temperature read.  Also, we want Tmeas in millicelsius
> +	 * and we don't want to lose precision from integer division. So...
> +	 * milli_Tmeas = 1000 * T2 + 1000 * (Nmeas - N2) * (T1 - T2) / (N1 - N2)
> +	 * Let constant c1 = 1000 * (T1 - T2) / (N1 - N2)
> +	 * milli_Tmeas = (1000 * T2) + c1 * (Nmeas - N2)
> +	 * milli_Tmeas = (1000 * T2) + (c1 * Nmeas) - (c1 * N2)
> +	 * Let constant c2 = (1000 * T2) - (c1 * N2)
> +	 * milli_Tmeas = c2 + (c1 * Nmeas)
> +	 */
> +	data->c1 = 1000 * (t1 - t2) / (n1 - n2);
> +	data->c2 = 1000 * t2 - data->c1 * n2;
> +
> +	return 0;
> +}
> +
> +static int imx_thermal_probe(struct platform_device *pdev)
> +{
> +	struct imx_thermal_data *data;
> +	struct cpumask clip_cpus;
> +	struct regmap *map;
> +	int ret;
> +
> +	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	map = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "fsl,tempmon");
> +	if (IS_ERR(map)) {
> +		ret = PTR_ERR(map);
> +		dev_err(&pdev->dev, "failed to get tempmon regmap: %d\n", ret);
> +		return ret;
> +	}
> +	data->tempmon = map;
> +
> +	platform_set_drvdata(pdev, data);
> +
> +	ret = imx_get_sensor_data(pdev);
> +	if (ret) {
> +		dev_err(&pdev->dev, "failed to get sensor data\n");
> +		return ret;
> +	}
> +
> +	/* Make sure sensor is in known good state for measurements */
> +	regmap_write(map, TEMPSENSE0 + REG_CLR, TEMPSENSE0_POWER_DOWN);
> +	regmap_write(map, TEMPSENSE0 + REG_CLR, TEMPSENSE0_MEASURE_TEMP);
> +	regmap_write(map, TEMPSENSE1 + REG_CLR, TEMPSENSE1_MEASURE_FREQ);
> +	regmap_write(map, MISC0 + REG_SET, MISC0_REFTOP_SELBIASOFF);
> +	regmap_write(map, TEMPSENSE0 + REG_SET, TEMPSENSE0_POWER_DOWN);
> +
> +	cpumask_set_cpu(0, &clip_cpus);
> +	data->cdev = cpufreq_cooling_register(&clip_cpus);
> +	if (IS_ERR(data->cdev)) {
> +		ret = PTR_ERR(data->cdev);
> +		dev_err(&pdev->dev,
> +			"failed to register cpufreq cooling device: %d\n", ret);
> +		return ret;
> +	}
> +
> +	data->tz = thermal_zone_device_register("imx_thermal_zone",
> +						IMX_TRIP_NUM, 0, data,
> +						&imx_tz_ops, NULL,
> +						IMX_PASSIVE_DELAY,
> +						IMX_POLLING_DELAY);
> +	if (IS_ERR(data->tz)) {
> +		ret = PTR_ERR(data->tz);
> +		dev_err(&pdev->dev,
> +			"failed to register thermal zone device %d\n", ret);
> +		cpufreq_cooling_unregister(data->cdev);
> +		return ret;
> +	}
> +
> +	data->mode = THERMAL_DEVICE_ENABLED;
> +
> +	return 0;
> +}
> +
> +static int imx_thermal_remove(struct platform_device *pdev)
> +{
> +	struct imx_thermal_data *data = platform_get_drvdata(pdev);
> +
> +	thermal_zone_device_unregister(data->tz);
> +	cpufreq_cooling_unregister(data->cdev);
> +
> +	return 0;
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int imx_thermal_suspend(struct device *dev)
> +{
> +	struct imx_thermal_data *data = dev_get_drvdata(dev);
> +	struct regmap *map = data->tempmon;
> +	u32 val;
> +
> +	regmap_read(map, TEMPSENSE0, &val);
> +	if ((val & TEMPSENSE0_POWER_DOWN) == 0) {
> +		/*
> +		 * If a measurement is taking place, wait for a long enough
> +		 * time for it to finish, and then check again.  If it still
> +		 * does not finish, something must go wrong.
> +		 */
> +		udelay(50);
> +		regmap_read(map, TEMPSENSE0, &val);
> +		if ((val & TEMPSENSE0_POWER_DOWN) == 0)
> +			return -ETIMEDOUT;
> +	}
> +
> +	return 0;
> +}
> +
> +static int imx_thermal_resume(struct device *dev)
> +{
> +	/* Nothing to do for now */
> +	return 0;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(imx_thermal_pm_ops,
> +			 imx_thermal_suspend, imx_thermal_resume);
> +
> +static const struct of_device_id of_imx_thermal_match[] = {
> +	{ .compatible = "fsl,imx6q-tempmon", },
> +	{ /* end */ }
> +};
> +
> +static struct platform_driver imx_thermal = {
> +	.driver = {
> +		.name	= "imx_thermal",
> +		.owner  = THIS_MODULE,
> +		.pm	= &imx_thermal_pm_ops,
> +		.of_match_table = of_imx_thermal_match,
> +	},
> +	.probe		= imx_thermal_probe,
> +	.remove		= imx_thermal_remove,
> +};
> +module_platform_driver(imx_thermal);
> +
> +MODULE_AUTHOR("Freescale Semiconductor, Inc.");
> +MODULE_DESCRIPTION("Thermal driver for Freescale i.MX SoCs");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:imx-thermal");
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 295 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130708/40bce35d/attachment-0001.sig>

From arnd at arndb.de  Mon Jul  8 19:18:06 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Jul 2013 01:18:06 +0200
Subject: [PATCH v1 0/4] ARM: STi fixes and ethernet support
In-Reply-To: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
References: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
Message-ID: <201307090118.06715.arnd@arndb.de>

On Monday 08 July 2013, Srinivas KANDAGATLA wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla at st.com>
> 
> This patch series fixes 2 configuration issues and adds ethernet support to
> STiH415, STiH416 based B2000, B2020 boards.
> With this patchset B2000 and B2020 can have basic ethernet support in
> MII and RGMII modes.
> 
> Thanks,
> srini
> 
> Srinivas Kandagatla (4):
>   ARM: dts: STi: Fix pinconf setup for STiH416 serial2
>   ARM: STi: Set correct ARM ERRATAs.
>   ARM: STi: Add STiH415 ethernet support.
>   ARM: STi: Add STiH416 ethernet support.

Hi Srini,

You really have to send those things separately, as the bug fixes should
probably go into 3.11, while the rest is new features and needs to be
reviewed for merging into 3.12.

I'm also puzzled by the fact that you add auxdata and callback
functions for the ether part in the platform code. Those should
probably all be properties added to the stmmac binding.

	Arnd


From arnd at arndb.de  Mon Jul  8 19:21:50 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Jul 2013 01:21:50 +0200
Subject: [PATCH] ARM: shmobile: r8a7790 SMP prototype v2
In-Reply-To: <CANqRtoRR-pyCpXYwKXRYSfVOewv+dXf=ntofJJsKQ0defF5-MQ@mail.gmail.com>
References: <20130626235837.11576.86389.sendpatchset@w520>
 <201306271401.13198.arnd@arndb.de>
 <CANqRtoRR-pyCpXYwKXRYSfVOewv+dXf=ntofJJsKQ0defF5-MQ@mail.gmail.com>
Message-ID: <201307090121.50685.arnd@arndb.de>

On Monday 08 July 2013, Magnus Damm wrote:
> >> +static void __init r8a7790_smp_prepare_cpus(unsigned int max_cpus)
> >> +{
> >> +     void __iomem *p;
> >> +     unsigned int k;
> >> +
> >> +     shmobile_boot_fn = virt_to_phys(shmobile_invalidate_start);
> >> +
> >> +     /* MERAM for jump stub, because BAR requires 256KB aligned address */
> >> +     p = ioremap_nocache(MERAM, 16);
> >> +     memcpy(p, shmobile_boot_vector, 16);
> >> +     iounmap(p);
> >
> > On the other hand here you have to use __raw_writel() or
> > memcpy_toio() because memcpy cannot operate on __iomem tokens.
> >
> > Also, if this is actually memory, you probably want to use ioremap_cached
> > or ioremap_writecombine.
> 
> Yeah, I realize this may be a bit of a mess. So say that I used
> ioremap_cached() here, I think I still need to flush the cache to make
> sure the secondary processors have valid code available then they
> boot. I suppose you're fine with that?

Is that required to get the data from dcache to icache? If so, that
sounds right.

	Arnd


From heiko at sntech.de  Mon Jul  8 20:12:31 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Tue, 9 Jul 2013 02:12:31 +0200
Subject: [PATCH] gpio: samsung: more generic pinctrl exclude ifdef
Message-ID: <201307090212.31422.heiko@sntech.de>

The exclude check should run any time when either the PINCTRL_SAMSUNG
or PINCTRL_EXYNOS5440 are selected.

As the real check for the presence of a pinctrl driver is done via a
dt lookup it's not necessary to specifiy every pinctrl option in the
ifdef individually.

This fixes a breakage on s3c2416, when both the legacy and
dt boards are selected.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
Extracted from Tomasz pinctrl series, as it fixes a bug in the current
3.11 development.

 drivers/gpio/gpio-samsung.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index a1392f4..ceb7971 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -2949,7 +2949,7 @@ static __init int samsung_gpiolib_init(void)
 	int i, nr_chips;
 	int group = 0;
 
-#if defined(CONFIG_PINCTRL_EXYNOS) || defined(CONFIG_PINCTRL_EXYNOS5440)
+#if defined(CONFIG_PINCTRL_SAMSUNG) || defined(CONFIG_PINCTRL_EXYNOS5440)
 	/*
 	* This gpio driver includes support for device tree support and there
 	* are platforms using it. In order to maintain compatibility with those
-- 
1.7.10.4



From sboyd at codeaurora.org  Mon Jul  8 20:58:37 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 8 Jul 2013 17:58:37 -0700
Subject: CPU hotplug issue w/ 0647065 clocksource: Add generic dummy
 timer driver
In-Reply-To: <51DAF895.1020700@wwwdotorg.org>
References: <51DAF895.1020700@wwwdotorg.org>
Message-ID: <20130709005837.GC830@codeaurora.org>

On 07/08, Stephen Warren wrote:
> CPU hotplug (replug) on Tegra HW seems to be occasionally broken due to
> commit 0647065 "clocksource: Add generic dummy timer driver" in
> linux-next. Reverting that commit solves the issue.

We found some breakage during boot that has been fixed by two
commits in linus' tree already. Do you know if you have these two
patches

1f73a9806bdd07a5106409bbcab3884078bd34fe
07bd1172902e782f288e4d44b1fde7dec0f08b6f

?

> 
> The symptom is that ~10% of the time, when re-plugging CPU1 (in a 2-core
> system, after unplugging it about 1 second before), I'll see the
> following WARN trigger in clockevents_program_event():
> 
> > int clockevents_program_event(struct clock_event_device *dev, ktime_t expires,
> > 			      bool force)
> > {
> > 	unsigned long long clc;
> > 	int64_t delta;
> > 	int rc;
> > 
> > 	if (unlikely(expires.tv64 < 0)) {
> > 		WARN_ON_ONCE(1);
> > 		return -ETIME;
> > 	}
> 
> This appears to be because in tick_handle_periodic_broadcast(),
> dev->next_event == KTIME_MAX. The system then hangs; I think that loop
> just keeps adding tick_period onto next_event, which doesn't manage to
> get to an acceptable value for a long time, if ever!
> 
> Do you have any idea why this could happen? I assume that during
> switching between the dummy timer added by that patch, and the real
> Tegra timer (drivers/clocksource/tegra20_timer.c) the Tegra timer's
> dev->next_event is temporarily set to KTIME_MAX, but somehow the timer
> IRQ handling goes off while the device is in this temporary state? The
> timer core seems to take steps to prevent this though, i.e. callilng
> spin_lock_irqsave() in places.

If you have the TWD then the dummy should only be used when you
notify clockevents core about hitting "C3". Are you seeing this
during idle or only during hotplug?

> 
> If I modify tick_handle_periodic_broadcast() to check for a negative
> dev->next_event and simply return in that case, the system seems to work
> fine, and I do see tick_handle_periodic_broadcast() being called at a
> later time, so obviously something is coming along later and programming
> the HW to generate additional events. On this HW, I believe struct
> clock_event_device.set_next_event is being used to emulate the periodic
> broadcast using a one-shot timer, rather than using the HW's native
> periodic capability, probably due to CONFIG_NO_HZ.

This sounds very much like the bug that was fixed. I don't see
why your broadcast timer would be emulating periodic mode instead
of just using oneshot mode unless it was started before the
system ever hit C3.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From B29397 at freescale.com  Mon Jul  8 21:05:31 2013
From: B29397 at freescale.com (Chen Peter-B29397)
Date: Tue, 9 Jul 2013 01:05:31 +0000
Subject: Chipidea usb otg support for IMX/MXS (device functionality)
In-Reply-To: <201307082256.38642.marex@denx.de>
References: <51A5A808.2070803@digi.com> <201307070310.00973.marex@denx.de>
 <F281D0F91ED19E4D8E63A7504E8A649803F28763@039-SN2MPN1-021.039d.mgd.msft.net>
 <201307082256.38642.marex@denx.de>
Message-ID: <F281D0F91ED19E4D8E63A7504E8A649803F39B98@039-SN2MPN1-022.039d.mgd.msft.net>

 
> 
> > > -----Original Message-----
> > > From: Marek Vasut [mailto:marex at denx.de]
> > > Sent: Sunday, July 07, 2013 9:10 AM
> > > To: Chen Peter-B29397
> > > Cc: shawn.guo at linaro.org; Michael Grzeschik; maxime.ripard at free-
> > > electrons.com; Hector Palacios; linux-usb at vger.kernel.org;
> > > s.hauer at pengutronix.de; alexander.shishkin at linux.intel.com; Estevam
> > > Fabio-R49496; Marc Kleine-Budde; m.grzeschik at pengutronix.de; linux-
> arm-
> > > kernel at lists.infradead.org
> > > Subject: Re: Chipidea usb otg support for IMX/MXS (device
> functionality)
> > >
> > > Hi Peter,
> > >
> > > > > Where can I measure this?
> > > > >
> > > > > > Two possible reasons:
> > > > > >
> > > > > > 1. You have not gpio control for vbus toggle when role switches.
> > > > >
> > > > > This works well.
> > > > >
> > > > > > 2. Your hardware has some problems that the vbus can't lower
> than
> > >
> > > 0.8v.
> > >
> > > > > How can I check that?
> > > >
> > > > Just measure the voltage of your otg vbus pin.
> > >
> > > It's 2.5 volt for me. What am I supposed to observe happening there?
> >
> > http://marc.info/?l=linux-usb&m=137242465920952&w=2
> 
> Dang, must have missed that one, sorry.
> 
> The VBUS is slowly discharging from around 5V to 2.5V , what does that
> tell me?
> 

It needs to check your hardware, it is probably there is a high capacitance at
vbus pin. Besides, the vbus should be lower than 0.8v if it is disconnected from
pc.

Best regards,
Peter




From minggr at gmail.com  Mon Jul  8 21:09:13 2013
From: minggr at gmail.com (Lin Ming)
Date: Tue, 9 Jul 2013 09:09:13 +0800
Subject: kernel decompressor problem for ARMv7
In-Reply-To: <1373250435.824.6.camel@minggr>
References: <CAF1ivSakn8-HiAf+4_cLRWUUTDP9QBKpAt+hVQoMyAmKZ2-dJA@mail.gmail.com>
 <20130705095757.GA13063@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1307051225240.18597@syhkavp.arg>
 <CAF1ivSbOXknHyDMH3RdmSGK2n5o2wVeR5oohCQnZ2gJrgvo=Hw@mail.gmail.com>
 <1373250435.824.6.camel@minggr>
Message-ID: <CAF1ivSbk70UnNc-09C2w-CdgaFBXe_k6K6n8Qr3L-jCLiTGqow@mail.gmail.com>

On Mon, Jul 8, 2013 at 10:27 AM, Lin Ming <minggr at gmail.com> wrote:
> On Sat, 2013-07-06 at 00:58 +0800, Lin Ming wrote:
>> On Sat, Jul 6, 2013 at 12:30 AM, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
>> > On Fri, 5 Jul 2013, Will Deacon wrote:
>> >
>> >> On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
>> >> > Hi all,
>> >>
>> >> Hello,
>> >>
>> >> > I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.
>> >>
>> >> Which specific processor/SoC?
>> >>
>> >> > But decompressor doesn't work. With a lot of debug, I finally find
>> >> > below 2 commits related.
>> >> > Kernel uncompress OK with these commits reverted.
>> >> >
>> >> > dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
>> >> > (Introduced in v3.6-rc6)
>> >> >
>> >> > 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
>> >> > v6 and above
>> >> > (Introduced in v3.7-rc8)
>> >> >
>> >> > Any hint to fix it?
>> >>
>> >> There's not really enough information to go on here. What specifically
>> >> fails? Also, do you have to revert *both* of the above changes to get things
>> >> working again?
>> >
>> > Also, what is the bootloader used here?
>>
>> uboot.
>>
>> >
>> > Does the bootloader call the kernel with the MMU off as documented in
>> > Documentation/arm/Booting?
>>
>> How to check this?
>>
>> I'll check uboot code or add debug code in boot/compressed/head.S to
>> check it next Monday.
>
> I added below debug code to print the control reg from lowest 4bits to
> highest 4bits.
>
> It prints "B7805C". So the control reg is 0x00c5087b.
> Seems bootloader calls the kernel with MMU enabled and Alignment fault
> checking enabled.

Hi Nicolas,

Is this information useful?
Or any other information needed for further debug?

Thanks,
Lin Ming

>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 32337ff..9434720 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -125,6 +125,23 @@
>                 .rept   7
>                 mov     r0, r0
>                 .endr
> +
> +               /* Dirty debug code to print control reg from lowest 4bits to highest 4bits */
> +               ldr     r2, =0xf0070120         @ UART
> +               mrc     p15, 0, r0, c1, c0, 0   @ read control reg
> +       1:
> +               cmp     r0, #0
> +               beq     2f
> +               and     r1, r0, #15
> +               cmp     r1, #9
> +               addgt   r1, r1, #7
> +               add     r1, r1, #48
> +               str     r1, [r2]
> +               asr     r0, r0, #4
> +               b       1b
> +       2:
> +
> +
>     ARM(                mov     r0, r0          )
>     ARM(                b       1f              )
>   THUMB(                adr     r12, BSYM(1f)   )
>
>
>>
>> >
>> > Nicolas
>
>


From jgq516 at gmail.com  Mon Jul  8 21:18:51 2013
From: jgq516 at gmail.com (jgq516 at gmail.com)
Date: Tue, 09 Jul 2013 09:18:51 +0800
Subject: v3.10 - big endian core support
In-Reply-To: <20130708170352.GA24361@mudshark.cambridge.arm.com>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com>
 <20130708084911.GA22057@mudshark.cambridge.arm.com>
 <51DA8BBF.7080104@gmail.com>
 <20130708110202.GD22057@mudshark.cambridge.arm.com>
 <20130708170352.GA24361@mudshark.cambridge.arm.com>
Message-ID: <51DB64FB.8030208@gmail.com>

On 07/09/2013 01:03 AM, Will Deacon wrote:
> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
>>> The printascii can output before "b __enable_mmu", after move it to
>>> __mmap_switched, nothing can be printed. But if disable LPAE, printascii
>>> works again in __mmap_switched.
>> Ok, so the page tables are broken. The code is there to swap the two words,
>> but perhaps something ends up being off-by-4 or the like. I'll try and take
>> a look.
> Right, I managed to have a quick play with a 3.10 kernel and the good news
> is that the page tables are fine. The bad part is that using
> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the FDT
> results in a NULL command line, so I don't see any output. If I hardcode the
> command line in the kernel image, things work fine.
>
> What kernel are you using, and how are you passing your command line?
3.4 kernel and command line is passed from uboot, I will try 3.10 
kernel, then cherry pick
some related patches from 3.10 if 3.10 works.

Thanks,
Xiao
> Will



From magnus.damm at gmail.com  Mon Jul  8 21:29:14 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 9 Jul 2013 10:29:14 +0900
Subject: [PATCH] ARM: shmobile: r8a7790 SMP prototype v2
In-Reply-To: <201307090121.50685.arnd@arndb.de>
References: <20130626235837.11576.86389.sendpatchset@w520>
 <201306271401.13198.arnd@arndb.de>
 <CANqRtoRR-pyCpXYwKXRYSfVOewv+dXf=ntofJJsKQ0defF5-MQ@mail.gmail.com>
 <201307090121.50685.arnd@arndb.de>
Message-ID: <CANqRtoR5tgHBg_kgb7-jde6VLwXyCe5XhPs-v_PDtO12GqGM-Q@mail.gmail.com>

On Tue, Jul 9, 2013 at 8:21 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Monday 08 July 2013, Magnus Damm wrote:
>> >> +static void __init r8a7790_smp_prepare_cpus(unsigned int max_cpus)
>> >> +{
>> >> +     void __iomem *p;
>> >> +     unsigned int k;
>> >> +
>> >> +     shmobile_boot_fn = virt_to_phys(shmobile_invalidate_start);
>> >> +
>> >> +     /* MERAM for jump stub, because BAR requires 256KB aligned address */
>> >> +     p = ioremap_nocache(MERAM, 16);
>> >> +     memcpy(p, shmobile_boot_vector, 16);
>> >> +     iounmap(p);
>> >
>> > On the other hand here you have to use __raw_writel() or
>> > memcpy_toio() because memcpy cannot operate on __iomem tokens.
>> >
>> > Also, if this is actually memory, you probably want to use ioremap_cached
>> > or ioremap_writecombine.
>>
>> Yeah, I realize this may be a bit of a mess. So say that I used
>> ioremap_cached() here, I think I still need to flush the cache to make
>> sure the secondary processors have valid code available then they
>> boot. I suppose you're fine with that?
>
> Is that required to get the data from dcache to icache? If so, that
> sounds right.

Good point. I sort of assumed that the secondary CPU cores booted with
cache disabled, but I may be wrong.

Thanks,

/ magnus


From satish.patel at ti.com  Mon Jul  8 22:23:29 2013
From: satish.patel at ti.com (Patel, Satish)
Date: Tue, 9 Jul 2013 02:23:29 +0000
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <51DAADD1.3060302@ti.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
 <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com>
 <51D54694.20203@ti.com> <20130704101216.GD4830@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E9764D5@DBDE04.ent.ti.com>
 <51DAADD1.3060302@ti.com>
Message-ID: <780E789C2E067A4BB8F69D0BB9EC4F253E976575@DBDE04.ent.ti.com>

Hi,

> -----Original Message-----
> From: ABRAHAM, KISHON VIJAY
> Sent: Monday, July 08, 2013 5:47 PM
> To: Patel, Satish
> Cc: Balbi, Felipe; grant.likely at linaro.org; tony at atomide.com;
> arnd at arndb.de; swarren at nvidia.com; sylvester.nawrocki at gmail.com;
> linux-kernel at vger.kernel.org; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-usb at vger.kernel.org;
> gregkh at linuxfoundation.org; akpm at linux-foundation.org;
> rob.herring at calxeda.com; rob at landley.net; linux at arm.linux.org.uk;
> benoit.cousson at linaro.org; mchehab at redhat.com; cesarb at cesarb.net;
> davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org; Shilimkar,
> Santosh; devicetree-discuss at lists.ozlabs.org; linux-
> doc at vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T; Cherian,
> George; Mankad, Maulik Ojas; Srinivasan, Nageswari; Sundareson,
> Prabindh
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> Hi,
> 
> On Monday 08 July 2013 04:54 PM, Patel, Satish wrote:
> > Hi,
> >
> >
> >> -----Original Message-----
> >> From: Balbi, Felipe
> >> Sent: Thursday, July 04, 2013 3:42 PM
> >> To: ABRAHAM, KISHON VIJAY
> >> Cc: Patel, Satish; Balbi, Felipe; grant.likely at linaro.org;
> >> tony at atomide.com; arnd at arndb.de; swarren at nvidia.com;
> >> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
> >> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> >> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> >> foundation.org; rob.herring at calxeda.com; rob at landley.net;
> >> linux at arm.linux.org.uk; benoit.cousson at linaro.org;
> mchehab at redhat.com;
> >> cesarb at cesarb.net; davem at davemloft.net; Nayak, Rajendra;
> >> shawn.guo at linaro.org; Shilimkar, Santosh; devicetree-
> >> discuss at lists.ozlabs.org; linux-doc at vger.kernel.org; Nori, Sekhar;
> >> Krishnamoorthy, Balaji T; Cherian, George; Mankad, Maulik Ojas
> >> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> >>
> >> On Thu, Jul 04, 2013 at 03:25:32PM +0530, Kishon Vijay Abraham I
> >> wrote:
> >>> On Thursday 04 July 2013 02:51 PM, Patel, Satish wrote:
> >>>> Hi,
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Balbi, Felipe
> >>>>> Sent: Wednesday, July 03, 2013 6:51 PM
> >>>>> To: ABRAHAM, KISHON VIJAY
> >>>>> Cc: Patel, Satish; grant.likely at linaro.org; tony at atomide.com;
> >> Balbi,
> >>>>> Felipe; arnd at arndb.de; swarren at nvidia.com;
> >>>>> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org;
> linux-
> >>>>> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-
> >>>>> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> >>>>> foundation.org; rob.herring at calxeda.com; rob at landley.net;
> >>>>> linux at arm.linux.org.uk; benoit.cousson at linaro.org;
> >> mchehab at redhat.com;
> >>>>> cesarb at cesarb.net; davem at davemloft.net; Nayak, Rajendra;
> >>>>> shawn.guo at linaro.org; Shilimkar, Santosh; devicetree-
> >>>>> discuss at lists.ozlabs.org; linux-doc at vger.kernel.org; Nori,
> Sekhar;
> >>>>> Krishnamoorthy, Balaji T; Cherian, George
> >>>>> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> On Wed, Jul 03, 2013 at 03:35:39PM +0530, Kishon Vijay Abraham I
> >>>>> wrote:
> >>>>>> On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote:
> >>>>>>> Hi Kishon,
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: ABRAHAM, KISHON VIJAY
> >>>>>>>> Sent: Wednesday, June 26, 2013 5:17 PM
> >>>>>>>> To: grant.likely at linaro.org; tony at atomide.com; Balbi, Felipe;
> >>>>> ABRAHAM,
> >>>>>>>> KISHON VIJAY; arnd at arndb.de; swarren at nvidia.com;
> >>>>>>>> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org;
> >> linux-
> >>>>>>>> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> >> linux-
> >>>>>>>> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> >>>>>>>> foundation.org
> >>>>>>>> Cc: rob.herring at calxeda.com; rob at landley.net;
> >>>>> linux at arm.linux.org.uk;
> >>>>>>>> benoit.cousson at linaro.org; mchehab at redhat.com;
> >> cesarb at cesarb.net;
> >>>>>>>> davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org;
> >>>>> Shilimkar,
> >>>>>>>> Santosh; devicetree-discuss at lists.ozlabs.org; linux-
> >>>>>>>> doc at vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T;
> >>>>> Cherian,
> >>>>>>>> George
> >>>>>>>> Subject: [PATCH v9 0/8] Generic PHY Framework
> >>>>>>>>
> >>>>>>>> Added a generic PHY framework that provides a set of APIs for
> >> the
> >>>>> PHY
> >>>>>>>> drivers
> >>>>>>>> to create/destroy a PHY and APIs for the PHY users to obtain
> a
> >>>>>>>> reference to
> >>>>>>>> the PHY with or without using phandle.
> >>>>>>>>
> >>>>>>>> This framework will be of use only to devices that uses
> >> external
> >>>>> PHY
> >>>>>>>> (PHY
> >>>>>>>> functionality is not embedded within the controller).
> >>>>>>>>
> >>>>>>>> The intention of creating this framework is to bring the phy
> >>>>> drivers
> >>>>>>>> spread
> >>>>>>>> all over the Linux kernel to drivers/phy to increase code re-
> >> use
> >>>>> and
> >>>>>>>> to
> >>>>>>>> increase code maintainability.
> >>>>>>>
> >>>>>>> I would like to use this framework for a smart-card controller
> >>>>> connected to a
> >>>>>>> smart-card phy. I have some questions and would like to get
> >>>>> feedback on the same.
> >>>>>>
> >>>>>> glad to know that :-)
> >>>>>>>
> >>>>>>> I am using ?TDA8026" Smartcard PHY from NXP. Here is the link
> >> for
> >>>>> datasheet
> >>>>>>> and app note for the same. The smart card controller is inside
> >> the
> >>>>> TI SoC
> >>>>>>> I am working with.
> >>>>>>>
> >>>>>>> Datasheet :
> >>>>>>> www.nxp.com/documents/data_sheet/TDA8026.pdf?
> >>>>>>>
> >>>>>>> Appnote :
> >>>>>>> http://www.nxp.com/documents/application_note/AN10724.pdf
> >>>>>>>
> >>>>>>> The TI SoC details are not public (yet). I can provide details
> >> to
> >>>>> you offline.
> >>>>>>>
> >>>>>>> Brief about operation:
> >>>>>>> -	The controller can work with and without a PHY
> >>>>>>> -	When not using PHY, it is limited to talking to a single
> >>>>>>> 	smart card. There is also a need to put external de-
> activation
> >>>>> logic
> >>>>>>> 	on card removal for this case.
> >>>>>>> -	With a PHY you can use more than one smart card.
> >>>>>>> -	Phy has 5 slots :  1 for smart card (credit/debit/other
> >> card
> >>>>> with chip)
> >>>>>>>        and others for SAM ? SIM like modules
> >>>>>>> - 	Once the PHY is initialized, there are some operations
> >> that the
> >>>>> controller
> >>>>>>> 	can request of the PHY like:
> >>>>>>> 	- Card configurations  - set voltage
> >>>>>>> 	- Activation of card
> >>>>>>> 	- ATR ? Answer to reset
> >>>>>>> 	- Warm reset
> >>>>>>> 	- ADPU exchange
> >>>>>>> 	- Deactivation ( Normal/Emergency)
> >>>>>>
> >>>>>> hmm.. We should think about extending the phy_ops to include
> >> these
> >>>>>> operations (something like phy_smart_card_ops so that other
> >>>>>> smart_card PHYs will also be able to use it).
> >>>>>
> >>>>> let's try to avoid use-case specific additions. set_voltage
> sounds
> >>>>> like
> >>>>> a regulator thing, but the regulator is controlled through the
> >> PHY. I
> >>>>> guess it makes sense to have a generic phy_set_voltage() call
> >> since
> >>>>> even
> >>>>> USB can make use of that.
> >>>>>
> >>>>> For card activation, it sounds like phy_init()/phy_shutdown()
> >> would
> >>>>> cover it.
> >>>>>
> >>>>> For warm reset perhaps a phy_reset() callback ? Although that
> >> could,
> >>>>> easily, get abused.
> >>>>>
> >>>>> For deactivation, that's phy_shutdown().
> >>>>>
> >>>>> ATR and ADPU needs more thought, I guess.
> >>>>>
> >>>>>>> - 	In the mode when smartcard controller talks directly to
> >> the
> >>>>> card without the need
> >>>>>>> 	for a PHY, all the above operations will be carried out
> by the
> >>>>> controller itself
> >>>>>>>
> >>>>>>> My current thought process is to make the controller driver
> >> provide
> >>>>> the user interface
> >>>>>>> and talk to the PHY using the generic PHY framework you
> >> proposed.
> >>>>> In the case where there
> >>>>>>> is no PHY, my idea is to create a "dummy" PHY which uses the
> >>>>> controller functionality itself.
> >>>>>>
> >>>>>> right. And in the case where you actually have a PHY, create a
> >> PHY
> >>>>>> driver and implement the phy_smart_card_ops and register with
> the
> >>>>> PHY
> >>>>>> framework.
> >>>>>
> >>>>> I would try to avoid that. Otherwise we will have phy_usb_ops,
> >>>>> phy_sata_ops, phy_network_ops, phy_pci_ops, etc etc etc. It
> would
> >>>>> easily
> >>>>> blow up.
> >>>>>
> >>>>
> >>>> - I do agree with you. Creating Phy specific ops will blow up
> whole
> >>>>    concept of generic phy f/w.
> >>>> - Can we have interface like phy_setconfig - with parameter like
> >>>>    phy_setconfig(int param, void *value)
> >>>> 	- Here param can be enum of available config parameters for
> >>>> 	  specific phy.
> >>>> Phy can perform different operation/set internal state based on
> >>>> param selection and value passed by.
> >>>>
> >>>> e.x in case of smartcard
> >>>> 	enum set_config {
> >>>> 		SET_VOLATAGE,
> >>>> 		SET_ACTIVATE,
> >>>> 		SET_WARMRESET,
> >>>> 		SET_ATR,
> >>>> 		SET_DEACTIVE,
> >>>> 		....
> >>>> 	};
> >>>
> >>> hmm.. this looks similar to ioctl and can be abused easily IMO :s
> >>
> >> +1
> >>
> >> What we need is to come up with generic ways to model those, if we
> >> need
> >> set voltage, then add a phy_set_voltage() kinda thing, perhaps add
> >> capability flags to enable/disable support fort those (just like
> mmc
> >> does).
> >>
> >> But adding something which can handle "anything" like
> >> phy_set_config(),
> >> it's the same as adding use-case specific ops.
> >>
> >
> > We have two options over here
> >
> > Option 1:
> >
> > Defining generic api to which can be mapped over multiple phys
> > For smartcard case, I have can thought of following mapping with new
> > generic apis as suggested.
> >
> > Smartcard_poweron -> power_on
> > Smartcard_powerdown -> power_off
> > Smartcard_set_voltage -> phy_set_voltage
> > Smartcard_activate_card -> phy_activate_slot
> > Smartcard_deactivate_card -> phy_deactivate_slot
> 
> how is activate/deactivate different from poweron/poweroff in this
> use case?

power on/off normal power sequence. While activate/de-activate will be 
called during card transaction.

Brief on how it works:
- when system start, execute power on for phy
- smartcard controller and phy is connected through i2c, clock lines and 
i/o lines
- clock will be supplied by controller to phy to get data sync on i/o lines

Operation:
 
Once the card gets inserted into the slot, user application can initiate
activate sequence anytime, it is not mandatory that activation has to be called
Immediately. It all depends whether other connections ( network, printer) are proper.
User application can do some checks and then dynamically activate the card

There are 2 sequence of activation - normal activation and warm reset. If first
fails then warm reset should be executed, if card does not response to both then
deactivation will be carried out

- For activation there are some timing parameters ( called ATR - Answer to reset timings)
Has to be set to the phy

- on activation card will respond with some initial characters (ATR), which will be verified
by application, in case of error user application will de-activate the card not the phy module

- After activation, use application initiate normal tx/rx

- Once tx/rx is done, it will initiate deactivation of card not the phy module.


> > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> 
> Whats should be exactly done here? Looks to me like it should be
> part of init. Does these pin settings need to be changed dynamically?

These are all phy pins which will be physically come in contact with smart card 
When inserted. In case of synchronous card, these pins will be toggled manually
by s/w bit bang algorithm


> > Smartcard_warm_reset -> phy_warmreset
>
Explained above.
 
> Again looks to me like it should be part of init.
> > Smartcard_set_clkdiv -> phy_set_clock
> > Smartcard_get_clkdiv -> phy_get_clock
> 
> Why would the smartcard give clock to the PHY? Shouldn't the driver
> of the PHY driver be doing that by itself?
> 
Source of clock to the  phy is from smart card controller

> > Smartcard_set_atr_mute_timeout -> ??
> > Smartcard_set_atr_early_timeout -> ??
> > Smartcard_get_isr_status -> phy_get_status
> 

ATR timeout parameter has to be configured for activation. This will
differ for various smart card segments.

> Why? Is it like the detection of an external event? Then the PHY
> driver should use *extcon* for event detection and passing.
>

Smartcard controller need a way to ready isr status ( like card presence,
Card inserted in to which slot, removed from which slot ) to maintain its
Internal state machine.
 
> > Smartcard_get_version -> phy_get_version
> 
> Again why? Why would the smartcard need the version of the PHY?
> 

Can be omitted. This is for the test suite reference.
> Thanks
> Kishon

From lauraa at codeaurora.org  Mon Jul  8 22:38:58 2013
From: lauraa at codeaurora.org (Laura Abbott)
Date: Mon, 08 Jul 2013 19:38:58 -0700
Subject: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is
 64-bits
In-Reply-To: <20130708104254.GS24642@n2100.arm.linux.org.uk>
References: <1367008266-1431-1-git-send-email-lauraa@codeaurora.org>
 <517AF270.8040106@gmail.com>
 <CACVXFVPfkqP+UyoGd-+QFRzndSam_DtU=utrBPYCPjQCGQ_F6g@mail.gmail.com>
 <51D71F81.5090503@codeaurora.org>
 <20130708104254.GS24642@n2100.arm.linux.org.uk>
Message-ID: <51DB77C2.4060705@codeaurora.org>

On 7/8/2013 3:42 AM, Russell King - ARM Linux wrote:
>>
>> The problem is the way the arm_dma_limit is set up, all dma allocations
>> are currently broken regardless of if the actual device supports 64-bit
>> addresses or not.
>
> Please explain this statement.
>

The statement was a bit shortsighted given recent discussions. My point 
was that on LPAE systems right now without ZONE_DMA, the allocation 
fails by default (i.e. no call to set_mask) even if the device could 
support 64-bit physical memory. Based on this thread though, drivers 
should stop assuming the dma_mask will be set up properly and always set 
the mask appropriately.

The conclusion also seems to be that if devices on an LPAE system can't 
handle > 32-bit addresses and want to limit via mask, ZONE_DMA must be 
set up.

Please correct me if I misunderstood anything.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From shawn.guo at linaro.org  Mon Jul  8 23:27:33 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Jul 2013 11:27:33 +0800
Subject: [PATCH] ARM: dts: i.MX51: Add WEIM node
In-Reply-To: <1373257783.211316847@f137.mail.ru>
References: <1373094142-24173-1-git-send-email-shc_work@mail.ru>
 <20130708023304.GA22636@S2101-09.ap.freescale.net>
 <1373257783.211316847@f137.mail.ru>
Message-ID: <20130709032731.GA16656@S2101-09.ap.freescale.net>

On Mon, Jul 08, 2013 at 08:29:43AM +0400, Alexander Shiyan wrote:
> > > @@ -745,6 +745,23 @@
> > >  				status = "disabled";
> > >  			};
> > >  
> > > +			weim: weim at 83fda000 {
> > > +				#address-cells = <2>;
> > > +				#size-cells = <1>;
> > > +				compatible = "fsl,imx51-weim";
> > > +				reg = <0x83fda000 0x1000>;
> > > +				clocks = <&clks 0>;
> > 
> > Is it correct?  I think there should be a physical clock for weim.
> 
> Yes, but properly clock for weim is missing in the clk subsystem,
> so I think at this point it is OK. Adding a properly clock should be a separate patch.

I've seen emi_slow and emi_fast clocks implemented in clk-imx51-imx53.c.
Neither is the clock for weim?

Shawn



From shawn.guo at linaro.org  Mon Jul  8 23:28:13 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Jul 2013 11:28:13 +0800
Subject: [RFC] ARM: dts: imx27: Add core voltages
In-Reply-To: <1373258044.869611579@f137.mail.ru>
References: <1373208662-7350-1-git-send-email-shc_work@mail.ru>
 <20130708015348.GB21594@S2101-09.ap.freescale.net>
 <1373258044.869611579@f137.mail.ru>
Message-ID: <20130709032811.GB16656@S2101-09.ap.freescale.net>

On Mon, Jul 08, 2013 at 08:34:04AM +0400, Alexander Shiyan wrote:
> > On Sun, Jul 07, 2013 at 06:51:02PM +0400, Alexander Shiyan wrote:
> > > This patch adds core voltages for i.MX27 CPUs. Only 266 and 400 MHz modes
> > > is documented in the datasheet, we add a 266 MHz frequency for conform this.
> > > For 133 MHz CPU frequency minimal voltage is used (1.2V).
> > > 
> > Ok, just checked i.MX27 data sheet, it seems that only 266 and 400 MHz
> > set points are officially supported.  So there is no documented voltage
> > for 133 MHz.  I'm wondering if we should have 133 MHz set point at all
> > if it's not officially supported.
> 
> Then how about removing the frequency of 133MHz, and increase tolerance
> of up to 5% in order to be able to play voltages for devices demanding low
> power consumption?

Sounds good to me.

Shawn



From jgq516 at gmail.com  Mon Jul  8 23:34:45 2013
From: jgq516 at gmail.com (jgq516 at gmail.com)
Date: Tue, 09 Jul 2013 11:34:45 +0800
Subject: v3.10 - big endian core support
In-Reply-To: <51DB64FB.8030208@gmail.com>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com>
 <20130708084911.GA22057@mudshark.cambridge.arm.com>
 <51DA8BBF.7080104@gmail.com>
 <20130708110202.GD22057@mudshark.cambridge.arm.com>
 <20130708170352.GA24361@mudshark.cambridge.arm.com>
 <51DB64FB.8030208@gmail.com>
Message-ID: <51DB84D5.3000700@gmail.com>

On 07/09/2013 09:18 AM, jgq516 at gmail.com wrote:
> On 07/09/2013 01:03 AM, Will Deacon wrote:
>> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
>>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
>>>> The printascii can output before "b __enable_mmu", after move it to
>>>> __mmap_switched, nothing can be printed. But if disable LPAE, 
>>>> printascii
>>>> works again in __mmap_switched.
>>> Ok, so the page tables are broken. The code is there to swap the two 
>>> words,
>>> but perhaps something ends up being off-by-4 or the like. I'll try 
>>> and take
>>> a look.
>> Right, I managed to have a quick play with a 3.10 kernel and the good 
>> news
>> is that the page tables are fine. The bad part is that using
>> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the 
>> FDT
>> results in a NULL command line, so I don't see any output. If I 
>> hardcode the
>> command line in the kernel image, things work fine.
>>
Hi Will,

Which kernel tree are you used? I tried latest mainline kernel (used 
vexpress_defconfig
and vexpress-v2p-ca15_a7.dtb) without any modification, but it hangs as 
follows.

## Booting kernel from Legacy Image at 80000000 ...
    Image Name:   Linux-3.10.0+
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2857168 Bytes = 2.7 MiB
    Load Address: 60008000
    Entry Point:  60008000
    Verifying Checksum ... OK
## Flattened Device Tree blob at 81f00000
    Booting using the fdt blob at 0x81f00000
    Loading Kernel Image ... OK
OK
    reserving fdt memory region: addr=ff000000 size=1000000
    Loading Device Tree to 9fee9000, end 9feee0a9 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpuset
Linux version 3.10.0+ (gjiang at gjiang-desktop) (gcc version 4.6.3 
(Sourcery CodeBench Lite 2012.03-57) ) #1 SMP Tue Jul 9 11:18:52 CST 2013
CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine: ARM-Versatile Express, model: V2P-CA15_CA7
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writealloc
------------[ cut here ]------------
WARNING: at arch/arm/kernel/devtree.c:147 arm_dt_init_cpu_maps+0x134/0x1bc()
DT /cpu 5 nodes greater than max cores 4, capping them
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0+ #1
[<80015b0c>] (unwind_backtrace+0x0/0xf8) from [<80011f20>] 
(show_stack+0x10/0x14)
[<80011f20>] (show_stack+0x10/0x14) from [<803a9c08>] (dump_stack+0x70/0x88)
[<803a9c08>] (dump_stack+0x70/0x88) from [<80021c10>] 
(warn_slowpath_common+0x54/0x68)
[<80021c10>] (warn_slowpath_common+0x54/0x68) from [<80021cb8>] 
(warn_slowpath_fmt+0x30/0x40)
[<80021cb8>] (warn_slowpath_fmt+0x30/0x40) from [<804d0cac>] 
(arm_dt_init_cpu_maps+0x134/0x1bc)
[<804d0cac>] (arm_dt_init_cpu_maps+0x134/0x1bc) from [<804cfd1c>] 
(setup_arch+0x680/0x898)
[<804cfd1c>] (setup_arch+0x680/0x898) from [<804cd640>] 
(start_kernel+0x90/0x310)
[<804cd640>] (start_kernel+0x90/0x310) from [<80008074>] (0x80008074)
---[ end trace 1b75b31a2719ed1c ]---
SMP: 5 cores greater than maximum (4), clipping
PERCPU: Embedded 7 pages/cpu @80d56000 s7296 r8192 d13184 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: root=/dev/nfs console=ttyAMA0,38400n8 rw 
init=/linuxrc nfsroot=128.224.163.23:/home/gjiang/work/a15fs ip=dhcp 
earlyprintk
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1033984K/1048576K available (3867K kernel code, 166K rwdata, 
1012K rodata, 199K init, 137K bss, 14592K reserved)
Virtual kernel memory layout:
     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
     modules : 0x7f000000 - 0x80000000   (  16 MB)
       .text : 0x80008000 - 0x804cc208   (4881 kB)
       .init : 0x804cd000 - 0x804fec80   ( 200 kB)
       .data : 0x80500000 - 0x80529a60   ( 167 kB)
        .bss : 0x80529a60 - 0x8054c0bc   ( 138 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
Failed to obtain parent clocks for SP810!
sp804: arm,sp804 clock not found: -2
sp804: clock not found: -2
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
Console: colour dummy device 80x30
Calibrating delay loop...

Thanks,
Xiao
>> What kernel are you using, and how are you passing your command line?
> 3.4 kernel and command line is passed from uboot, I will try 3.10 
> kernel, then cherry pick
> some related patches from 3.10 if 3.10 works.
>
> Thanks,
> Xiao
>> Will
>



From shawn.guo at linaro.org  Mon Jul  8 23:48:32 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Jul 2013 11:48:32 +0800
Subject: [PATCH] ARM: imx_v6_v7_defconfig: enable WEIM driver
In-Reply-To: <1373267763-28440-1-git-send-email-b32955@freescale.com>
References: <1373267763-28440-1-git-send-email-b32955@freescale.com>
Message-ID: <20130709034830.GC16656@S2101-09.ap.freescale.net>

On Mon, Jul 08, 2013 at 03:16:03PM +0800, Huang Shijie wrote:
> enable the weim driver.
> Since the NOR is connected to the WEIM for imx6q{dl}-sabreauto,
> we also enable the MTD_PHYSMAP_OF module.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>

Applied, thanks.



From michael.opdenacker at free-electrons.com  Tue Jul  9 00:18:10 2013
From: michael.opdenacker at free-electrons.com (Michael Opdenacker)
Date: Tue,  9 Jul 2013 06:18:10 +0200
Subject: [PATCH] ARM: footbridge: remove obsolete IRQF_DISABLED
Message-ID: <1373343490-4658-1-git-send-email-michael.opdenacker@free-electrons.com>

This patch proposes to remove the IRQF_DISABLED flag from footbridge
code. It's a NOOP since 2.6.35.

Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>
---
 arch/arm/mach-footbridge/dc21285-timer.c |  2 +-
 arch/arm/mach-footbridge/dc21285.c       | 10 +++++-----
 arch/arm/mach-footbridge/isa-timer.c     |  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-footbridge/dc21285-timer.c b/arch/arm/mach-footbridge/dc21285-timer.c
index 9ee78f7..892d550 100644
--- a/arch/arm/mach-footbridge/dc21285-timer.c
+++ b/arch/arm/mach-footbridge/dc21285-timer.c
@@ -86,7 +86,7 @@ static irqreturn_t timer1_interrupt(int irq, void *dev_id)
 static struct irqaction footbridge_timer_irq = {
 	.name		= "dc21285_timer1",
 	.handler	= timer1_interrupt,
-	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+	.flags		= IRQF_TIMER | IRQF_IRQPOLL,
 	.dev_id		= &ckevt_dc21285,
 };
 
diff --git a/arch/arm/mach-footbridge/dc21285.c b/arch/arm/mach-footbridge/dc21285.c
index a7cd2cf..d5ad2aa 100644
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -338,15 +338,15 @@ void __init dc21285_preinit(void)
 	/*
 	 * We don't care if these fail.
 	 */
-	dc21285_request_irq(IRQ_PCI_SERR, dc21285_serr_irq, IRQF_DISABLED,
+	dc21285_request_irq(IRQ_PCI_SERR, dc21285_serr_irq, 0,
 			    "PCI system error", &serr_timer);
-	dc21285_request_irq(IRQ_PCI_PERR, dc21285_parity_irq, IRQF_DISABLED,
+	dc21285_request_irq(IRQ_PCI_PERR, dc21285_parity_irq, 0,
 			    "PCI parity error", &perr_timer);
-	dc21285_request_irq(IRQ_PCI_ABORT, dc21285_abort_irq, IRQF_DISABLED,
+	dc21285_request_irq(IRQ_PCI_ABORT, dc21285_abort_irq, 0,
 			    "PCI abort", NULL);
-	dc21285_request_irq(IRQ_DISCARD_TIMER, dc21285_discard_irq, IRQF_DISABLED,
+	dc21285_request_irq(IRQ_DISCARD_TIMER, dc21285_discard_irq, 0,
 			    "Discard timer", NULL);
-	dc21285_request_irq(IRQ_PCI_DPERR, dc21285_dparity_irq, IRQF_DISABLED,
+	dc21285_request_irq(IRQ_PCI_DPERR, dc21285_dparity_irq, 0,
 			    "PCI data parity", NULL);
 
 	if (cfn_mode) {
diff --git a/arch/arm/mach-footbridge/isa-timer.c b/arch/arm/mach-footbridge/isa-timer.c
index d9301dd..b73f52e 100644
--- a/arch/arm/mach-footbridge/isa-timer.c
+++ b/arch/arm/mach-footbridge/isa-timer.c
@@ -27,7 +27,7 @@ static irqreturn_t pit_timer_interrupt(int irq, void *dev_id)
 static struct irqaction pit_timer_irq = {
 	.name		= "pit",
 	.handler	= pit_timer_interrupt,
-	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+	.flags		= IRQF_TIMER | IRQF_IRQPOLL,
 	.dev_id		= &i8253_clockevent,
 };
 
-- 
1.8.1.2



From magnus.damm at gmail.com  Tue Jul  9 00:26:54 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 13:26:54 +0900
Subject: [PATCH] ARM: shmobile: Add SMSC ethernet chip to KZM9D DT reference
Message-ID: <20130709042654.13658.20164.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Add support for the SMSC ethernet controller found
on the KZM9D board to the KZM9D DT Reference code.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Built on top of renesas-next-20130704v2 and
 [PATCH] ARM: shmobile: KZM9D DT reference implementation

 arch/arm/boot/dts/emev2-kzm9d-reference.dts |   31 +++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

--- 0002/arch/arm/boot/dts/emev2-kzm9d-reference.dts
+++ work/arch/arm/boot/dts/emev2-kzm9d-reference.dts	2013-07-09 13:06:47.000000000 +0900
@@ -23,4 +23,35 @@
 	chosen {
 		bootargs = "console=ttyS1,115200n81 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096";
 	};
+
+	reg_1p8v: regulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "fixed-1.8V";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	reg_3p3v: regulator at 1 {
+		compatible = "regulator-fixed";
+		regulator-name = "fixed-3.3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	lan9220 at 20000000 {
+		compatible = "smsc,lan9220", "smsc,lan9115";
+		reg = <0x20000000 0x10000>;
+		phy-mode = "mii";
+		interrupt-parent = <&gpio0>;
+		interrupts = <1 1>;	/* active high */
+		reg-io-width = <4>;
+		smsc,irq-active-high;
+		smsc,irq-push-pull;
+		vddvario-supply = <&reg_1p8v>;
+		vdd33a-supply = <&reg_3p3v>;
+	};
 };


From thierry.reding at gmail.com  Tue Jul  9 01:05:13 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 9 Jul 2013 07:05:13 +0200
Subject: [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <20130708165149.55499b8e@skate>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-5-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo4aodspFnC0uR87yYAgswQQdmU48uoX5NA43UZjbCpOuw@mail.gmail.com>
 <20130708165149.55499b8e@skate>
Message-ID: <20130709050511.GB16232@mithrandir>

On Mon, Jul 08, 2013 at 04:51:49PM +0200, Thomas Petazzoni wrote:
> Dear Bjorn Helgaas,

Sorry for chiming in so late, I've had bad internet connectivity and
email access for a few days.

> On Fri, 5 Jul 2013 15:51:10 -0600, Bjorn Helgaas wrote:
>
> > >  int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
> > >  {
> > > +       struct msi_chip *chip = dev->bus->msi;
> > > +
> > > +       if (chip && chip->setup_irq) {
> > > +               int err;
> > > +
> > > +               err = chip->setup_irq(chip, dev, desc);
> > > +               if (err < 0)
> > > +                       return err;
> > > +
> > > +               irq_set_chip_data(desc->irq, chip);
> > > +               return err;
> > > +       }
> > > +
> > >         return -EINVAL;
> > 
> > It's sub-optimal to indent the whole body of a function like this.  I
> > think this is a bit more readable:
> > 
> >     if (!chip || !chip->setup_irq)
> >         return -EINVAL
> > 
> >     err = chip->setup_irq(...);
> >     ...
> >     return err;
> > 
> > The return value of ->setup_irq() (and hence of arch_setup_msi_irq())
> > is a bit unclear.  Apparently it can return negative values (errors)
> > or positive values (not sure what they mean), or zero (again, not
> > sure).  A comment would clear this up.
>
> I've changed ->setup_irq() to simply return 0 on success, and a
> negative error code on failure.
>
> Apparently, according to the default implementation
> of arch_msi_setup_irqs(), the arch_msi_setup_irq() hook is supposed to
> return:
>  * A negative value on error, the value being an error code that is
>    propagated to the caller.
>  * A positive value on some other errors, in which case the -ENOSPC
>    error value is returned. To me, it doesn't make a lot of sense, as
>    arch_msi_setup_irq() could just as well return -ENOSPC directly.
>  * A 0 value on success.

Yes, I think that'd be much more straightforward. Having > 0 as a
special case isn't useful here.

> > It might even be worth introducing a no-op chip with pointers to no-op
> > functions so we don't have to do these checks ("if (chip &&
> > chip->xxx)" everywhere.  I'm not sure if there's a Linux consensus on
> > that -- certainly there are many examples of code that *does* make
> > these checks everywhere -- so I'll ack it either way.
>
> The problem with this is that I'm not sure where in the PCI code this
> association to the default implementation should be done. And there are
> also two levels to take into account here:
>
>  * The PCI driver may not specify any msi_chip structure for a
>    particular pci_bus. This would have to be detected by the PCI core
>    when the bus is registered, and bus->msi would be set to the special
>    no-op msi_chip.

You could check if bus->msi was set after the call to pcibios_bus_add()
but that's a bit wonky because it may break once the first architecture
appears that assigns it in a different place.

>  * The PCI driver may specify an msi_chip structure, but without
>    necessarily implementation all the methods. This could be solved by
>    offering a pci_msi_chip_assign(struct pci_bus *, struct msi_chip *)
>    function to be used by PCI drivers to assign their msi_chip to a
>    given pci_bus, and this function would fill in the missing msi_chip
>    operations with the default implementation.
>
> I am not sure it is really worth doing at this point, but I'm open to
> suggestions on this.

I think these extra calls aren't that bad given how other alternatives
are much easier to break things. Perhaps checking for the methods could
be dropped, therefore making them mandatory (by crashing if they're not
implemented).

> > >  int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> > >  {
> > > +       struct msi_chip *chip = dev->bus->msi;
> > > +
> > > +       if (chip && chip->check_device)
> > > +               return chip->check_device(chip, dev, nvec, type);
> > > +
> > 
> > These functions are poorly named.  They give no clue what
> > "check_device" means.  Are we checking that it exists, that it
> > supports some property, that it's enabled, ... ?
>
> Well the naming clearly doesn't come from this commit. The
> arch_msi_check_device() hook was around before this commit, and the
> reason the operation is named ->check_device() is just because it used
> the same terminology as the existing arch_msi_check_device() call.
>
> This hook is only used in one place, the PowerPC architecture, in
> arch/powerpc/kernel/msi.c, to actually check whether the given device
> supports MSI.
>
> I can rename if to arch_msi_device_supports_msi() and
> ->device_supports_msi(), or arch_msi_device_has_msi() and
> ->device_has_msi(), but that a change that relatively unrelated to this
> commit, I'd say.
>
> Here as well, I'm open to suggestions,

I don't think *_check_device() is all that bad. Some of the
implementations in PowerPC only use it to output a debug message, others
do some more checking. Some of the checks look generic enough to move
them into the core.

If you rename it to *_has_msi() or *_supports_msi() then I'd expect it
to return a boolean and you loose the advantage of being able to return
a more meaningful value. Although I'm not sure how useful that error
code really is. It is passed all the way up to the caller of
pci_enable_msi(), so a driver could use it to construct a better error
message based on the error code. From a quick glance a few of them seem
to do that.

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/20130709/d850b288/attachment.sig>

From dirk.behme at de.bosch.com  Tue Jul  9 01:24:05 2013
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Tue, 9 Jul 2013 07:24:05 +0200
Subject: [PATCH 0/2] Optimize L2 setting on imx6sl
In-Reply-To: <1373293383-15128-1-git-send-email-shawn.guo@linaro.org>
References: <1373293383-15128-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <51DB9E75.7030008@de.bosch.com>

On 08.07.2013 16:23, Shawn Guo wrote:
> The series leverages the L2 optimization done on imx6q/dl for imx6sl,
> by moving imx6q_init_l2cache() out from mach-imx6q.c into system.c and
> renaming it imx_init_l2cache().
>
> Shawn Guo (2):
>    ARM: imx: let L2 initialization be a common function
>    ARM: imx: use imx specific L2 init function on imx6sl
>
>   arch/arm/mach-imx/common.h      |    6 ++++++
>   arch/arm/mach-imx/mach-imx6q.c  |   37 +------------------------------------
>   arch/arm/mach-imx/mach-imx6sl.c |    3 +--
>   arch/arm/mach-imx/system.c      |   33 +++++++++++++++++++++++++++++++++
>   4 files changed, 41 insertions(+), 38 deletions(-)

Whole series:

Acked-by: Dirk Behme <dirk.behme at de.bosch.com>

Thanks

Dirk






From shawn.guo at linaro.org  Tue Jul  9 01:29:27 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Jul 2013 13:29:27 +0800
Subject: [PATCH 3/3] ARM:dts:vf610-twr:Enable DSPI0 devices and Flash
 at26df081a
In-Reply-To: <20130708113600.GU27646@sirena.org.uk>
References: <1373272622-29064-1-git-send-email-b44548@freescale.com>
 <1373272622-29064-3-git-send-email-b44548@freescale.com>
 <20130708113600.GU27646@sirena.org.uk>
Message-ID: <20130709052925.GD16656@S2101-09.ap.freescale.net>

On Mon, Jul 08, 2013 at 12:36:01PM +0100, Mark Brown wrote:
> On Mon, Jul 08, 2013 at 04:37:02PM +0800, Chao Fu wrote:
> > From: Chao Fu <B44548 at freescale.com>
> > 
> > This patch enables DSPI0 and at26df081a flash device for Vybrid VF610 TOWER board.
> 
> Acked-by: Mark Brown <broonie at linaro.org>
> 
> This should be fine to merge via arm-soc, it's no real dependency on the
> actual SPI driver.

It has dependency on the actual SPI driver where the DT bindings are
defined, so I would only take the patches after the driver parts gets
accepted.

Shawn



From rnayak at ti.com  Tue Jul  9 01:33:54 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 11:03:54 +0530
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130708133512.GD31221@arwen.pp.htv.fi>
References: <51D59146.3070002@newflow.co.uk> <51D59C0E.8080003@newflow.co.uk>
 <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi>
Message-ID: <51DBA0C2.6030003@ti.com>

On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
>>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>>>> of -1 for the serial driver?
>>>>>>>>
>>>>>>>
>>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>>>
>>>>> OK
>>>>
>>>> Issue 2: Causing boot to stop when serial driver is initialized.
>>>> (After Issue 1 is fixed)
>>>>
>>>> I could narrow this down to the change done to return -EINVAL
>>>> instead of 0 in serial_omap_get_context_loss_count() as part of
>>>> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
>>>> Fix device tree based PM runtime"
>>>>
>>>> What this change in turn seems to do is cause a
>>>> serial_omap_restore_context() to get called as part of
>>>> serial_omap_runtime_resume() which was not the case when
>>>> serial_omap_get_context_loss_count() returned 0
>>>>
>>>> from serial_omap_runtime_resume():
>>>> -----
>>>>         int loss_cnt = serial_omap_get_context_loss_count(up);
>>>>
>>>>         if (loss_cnt < 0) {
>>>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>>>                         loss_cnt);
>>>>                 serial_omap_restore_context(up);
>>>>         } else if (up->context_loss_cnt != loss_cnt) {
>>>>                 serial_omap_restore_context(up);
>>>>         }
>>>> -----
>>>>
>>>> I am still working on why a serial_omap_restore_context() could
>>>> have caused console to die. I will work with Sourav on this and
>>>> post the fixes for both issue 1 and issue2 once its clear on whats
>>>> really causing issue 2.
>>>
>>> That's because we don't have the omap specific pdata callbacks for
>>> context loss any longer. We may be able to detect when the context
>>> was really lost in the serial driver, and only then call the
>>> serial_omap_restore_context().
>>
>> Right, but calling serial_omap_restore_context() even when the context
>> is not lost, should not ideally cause an issue.
> 
> it does in one condition. If context hasn't been saved before. And that
> can happen in the case of wrong pm runtime status for that device.
> 
> Imagine the device is marked as suspended even though it's fully enabled
> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> your context structure is all zeroes (context has never been saved
> before) then when you call pm_runtime_get_sync() on probe() your
> ->runtime_resume() will get called, which will restore context,
> essentially undoing anything which was configured by u-boot.

This could be a problem for drivers which do a save context in ->runtime_suspend()
but from what I see with omap serial, there is no save context done as part of
->runtime_suspend.

> 
> Am I missing something ?
> 
>>>> Let me know if the fix I listed for Issue 1: makes sense.
>>>
>>> Yes makes sense as a fix, but IMHO we should not need any workarounds
>>> like that. Is the hwmod code idling the the uarts early? If so, then
>>> it should only do that in a late_initcall if no drivers are registered.
>>
>> hwmod as part of its setup (early) enables/resets and idles all modules.
>> These flags are used to tell hwmod to avoid a reset and idle and leave the
>> module enabled (in this case console uart)
> 
> then it needs to call pm_runtime_set_active() for those devices which
> have that flag set, right ?
> 
> (completely untested, didn't even try to compile, just to illustrate)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 7341eff..d8dca68 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
>  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
>  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
>  		postsetup_state = _HWMOD_STATE_ENABLED;
> +
> +		/* tell pm_runtime this device is already active */
> +		pm_runtime_set_active(&oh->od->pdev->dev);
> +	} else {
> +		/* tell pm_runtime this device is trully suspended */
> +		pm_runtime_set_suspended(&oh->od->pdev->dev);
>  	}
>  
>  	if (postsetup_state == _HWMOD_STATE_IDLE)
> 



From magnus.damm at gmail.com  Tue Jul  9 01:43:31 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 14:43:31 +0900
Subject: [PATCH 00/04] ARM: shmobile: ARCH_MULTIPLATFORM for EMEV2 and KZM9D
Message-ID: <20130709054331.14007.66068.sendpatchset@w520>

ARM: shmobile: ARCH_MULTIPLATFORM for EMEV2 and KZM9D

[PATCH 01/04] ARM: shmobile: Only build clocks when COMMON_CLK=n
[PATCH 02/04] ARM: shmobile: Introduce ARCH_SHMOBILE_MULTI
[PATCH 03/04] ARM: shmobile: Add EMEV2 and KZM9D to ARCH_SHMOBILE_MULTI
[PATCH 04/04] ARM: shmobile: Allow ARCH_SHMOBILE_MULTI timer configuration

This patch set extends mach-shmobile to allow a subset of SoCs and
boards to be built for ARCH_MULTIPLATFORM. With this series applied
the EMEV2 SoC and the KZM9D board can be built in two ways - either
as good old ARCH_SHMOBILE or new ARCH_SHMOBILE_MULTI. The latter
requires common clock framework for proper run time operation.

The goal is to over time move all DT reference implementations from
ARCH_SHMOBILE to ARCH_SHMOBILE_MULTI. Until CCF is available for a
certain SoC it is to me acceptable for a DT reference board to allow
build in both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI. The reason for
this is to allow incremental development and easy testing during
development of CCF for a certain SoC. The KZM9D board is now in this
state while it is waiting for common clocks to become ready.

In the near future a prototype hack will be posted that comments
out the clock framework bits on EMEV2 and will allow boot of KZM9D
in the case of ARCH_SHMOBILE_MULTI even though CCF is not yet
available.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Built on top of renesas-next-20130704v2 and
 [PATCH] ARM: shmobile: KZM9D DT reference implementation

 arch/arm/Makefile                    |    1 
 arch/arm/boot/dts/Makefile           |    1 
 arch/arm/mach-shmobile/Kconfig       |   52 ++++++++++++++++++++++++++++++----
 arch/arm/mach-shmobile/Makefile      |   32 +++++++++++++++-----
 arch/arm/mach-shmobile/setup-emev2.c |    5 +++
 5 files changed, 77 insertions(+), 14 deletions(-)


From magnus.damm at gmail.com  Tue Jul  9 01:43:41 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 14:43:41 +0900
Subject: [PATCH 01/04] ARM: shmobile: Only build clocks when COMMON_CLK=n
In-Reply-To: <20130709054331.14007.66068.sendpatchset@w520>
References: <20130709054331.14007.66068.sendpatchset@w520>
Message-ID: <20130709054341.14007.99736.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Move shared clock.c file and per-SoC clock-xxx.c files
to only build when CONFIG_COMMON_CLK != y.

The regular ARCH_SHMOBILE case with legacy SH clock framework
will build just as before with this patch applied, however
the case when COMMON_CLK=y will exclude all the clock files.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/Makefile |   30 +++++++++++++++++++++---------
 1 file changed, 21 insertions(+), 9 deletions(-)

--- 0002/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-07-09 12:21:29.000000000 +0900
@@ -3,17 +3,28 @@
 #
 
 # Common objects
-obj-y				:= timer.o console.o clock.o
+obj-y				:= timer.o console.o
 
 # CPU objects
-obj-$(CONFIG_ARCH_SH7372)	+= setup-sh7372.o clock-sh7372.o intc-sh7372.o
-obj-$(CONFIG_ARCH_SH73A0)	+= setup-sh73a0.o clock-sh73a0.o intc-sh73a0.o
-obj-$(CONFIG_ARCH_R8A73A4)	+= setup-r8a73a4.o clock-r8a73a4.o
-obj-$(CONFIG_ARCH_R8A7740)	+= setup-r8a7740.o clock-r8a7740.o intc-r8a7740.o
-obj-$(CONFIG_ARCH_R8A7778)	+= setup-r8a7778.o clock-r8a7778.o
-obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o clock-r8a7779.o intc-r8a7779.o
-obj-$(CONFIG_ARCH_R8A7790)	+= setup-r8a7790.o clock-r8a7790.o
-obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o clock-emev2.o
+obj-$(CONFIG_ARCH_SH7372)	+= setup-sh7372.o intc-sh7372.o
+obj-$(CONFIG_ARCH_SH73A0)	+= setup-sh73a0.o intc-sh73a0.o
+obj-$(CONFIG_ARCH_R8A73A4)	+= setup-r8a73a4.o
+obj-$(CONFIG_ARCH_R8A7740)	+= setup-r8a7740.o intc-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7778)	+= setup-r8a7778.o
+obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o intc-r8a7779.o
+obj-$(CONFIG_ARCH_R8A7790)	+= setup-r8a7790.o
+obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o
+
+# Clock objects
+clk-y				:= clock.o
+clk-$(CONFIG_ARCH_SH7372)	+= clock-sh7372.o
+clk-$(CONFIG_ARCH_SH73A0)	+= clock-sh73a0.o
+clk-$(CONFIG_ARCH_R8A73A4)	+= clock-r8a73a4.o
+clk-$(CONFIG_ARCH_R8A7740)	+= clock-r8a7740.o
+clk-$(CONFIG_ARCH_R8A7778)	+= clock-r8a7778.o
+clk-$(CONFIG_ARCH_R8A7779)	+= clock-r8a7779.o
+clk-$(CONFIG_ARCH_R8A7790)	+= clock-r8a7790.o
+clk-$(CONFIG_ARCH_EMEV2)	+= clock-emev2.o
 
 # SMP objects
 smp-y				:= platsmp.o headsmp.o
@@ -53,3 +64,4 @@ obj-$(CONFIG_MACH_KZM9G_REFERENCE)	+= bo
 
 # Framework support
 obj-$(CONFIG_SMP)		+= $(smp-y)
+obj-y				+= $(clk-y$(CONFIG_COMMON_CLK))


From magnus.damm at gmail.com  Tue Jul  9 01:43:50 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 14:43:50 +0900
Subject: [PATCH 02/04] ARM: shmobile: Introduce ARCH_SHMOBILE_MULTI
In-Reply-To: <20130709054331.14007.66068.sendpatchset@w520>
References: <20130709054331.14007.66068.sendpatchset@w520>
Message-ID: <20130709054350.14007.24354.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Add ARCH_SHMOBILE_MULTI to mach-shmobile that can be used
to enable ARCH_MULTIPLATFORM on selected SoCs and boards.

The headers stay under arch/arm/mach-shmobile/include/mach/
for now, they can and will be migrated independently over time.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/Makefile               |    1 +
 arch/arm/mach-shmobile/Kconfig  |   21 +++++++++++++++++++++
 arch/arm/mach-shmobile/Makefile |    2 ++
 3 files changed, 24 insertions(+)

--- 0001/arch/arm/Makefile
+++ work/arch/arm/Makefile	2013-07-08 19:17:00.000000000 +0900
@@ -181,6 +181,7 @@ machine-$(CONFIG_ARCH_EXYNOS)		+= exynos
 machine-$(CONFIG_ARCH_SA1100)		+= sa1100
 machine-$(CONFIG_ARCH_SHARK)		+= shark
 machine-$(CONFIG_ARCH_SHMOBILE) 	+= shmobile
+machine-$(CONFIG_ARCH_SHMOBILE_MULTI) 	+= shmobile
 machine-$(CONFIG_ARCH_TEGRA)		+= tegra
 machine-$(CONFIG_ARCH_U300)		+= u300
 machine-$(CONFIG_ARCH_U8500)		+= ux500
--- 0002/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-07-08 19:19:21.000000000 +0900
@@ -1,3 +1,24 @@
+config ARCH_SHMOBILE_MULTI
+	bool "SH-Mobile Series" if ARCH_MULTI_V7
+	depends on MMU
+	select CPU_V7
+	select GENERIC_CLOCKEVENTS
+	select HAVE_ARM_SCU if SMP
+	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_SMP
+	select ARM_GIC
+	select MIGHT_HAVE_CACHE_L2X0
+	select NO_IOPORT
+	select PINCTRL
+	select ARCH_REQUIRE_GPIOLIB
+	select CLKDEV_LOOKUP
+
+if ARCH_SHMOBILE_MULTI
+
+comment "SH-Mobile System Type"
+
+endif
+
 if ARCH_SHMOBILE
 
 comment "SH-Mobile System Type"
--- 0003/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-07-08 19:18:20.000000000 +0900
@@ -2,6 +2,8 @@
 # Makefile for the linux kernel.
 #
 
+ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/arch/arm/mach-shmobile/include
+
 # Common objects
 obj-y				:= timer.o console.o
 


From magnus.damm at gmail.com  Tue Jul  9 01:43:59 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 14:43:59 +0900
Subject: [PATCH 03/04] ARM: shmobile: Add EMEV2 and KZM9D to
 ARCH_SHMOBILE_MULTI
In-Reply-To: <20130709054331.14007.66068.sendpatchset@w520>
References: <20130709054331.14007.66068.sendpatchset@w520>
Message-ID: <20130709054359.14007.23619.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Enable build of EMEV2 and KZM9D DT Reference in
case of ARCH_MULTIPLATFORM and ARCH_SHMOBILE_MULTI.

A weak symbol covers the case when the clock-emev2.c
file is not built when COMMON_CLK=y.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/boot/dts/Makefile           |    1 +
 arch/arm/mach-shmobile/Kconfig       |   15 +++++++++++++++
 arch/arm/mach-shmobile/setup-emev2.c |    5 +++++
 3 files changed, 21 insertions(+)

--- 0002/arch/arm/boot/dts/Makefile
+++ work/arch/arm/boot/dts/Makefile	2013-07-09 13:10:52.000000000 +0900
@@ -171,6 +171,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm
 	sh73a0-kzm9g-reference.dtb \
 	r8a73a4-ape6evm.dtb \
 	sh7372-mackerel.dtb
+dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += emev2-kzm9d-reference.dtb
 dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_cyclone5.dtb \
 	socfpga_vt.dtb
 dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb \
--- 0004/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-07-09 13:03:45.000000000 +0900
@@ -17,6 +17,21 @@ if ARCH_SHMOBILE_MULTI
 
 comment "SH-Mobile System Type"
 
+config ARCH_EMEV2
+	bool "Emma Mobile EV2"
+
+comment "SH-Mobile Board Type"
+
+config MACH_KZM9D_REFERENCE
+	bool "KZM9D board - Reference Device Tree Implementation"
+	depends on ARCH_EMEV2
+	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	---help---
+	   Use reference implementation of KZM9D board support
+	   which makes a greater use of device tree at the expense
+	   of not supporting a number of devices.
+
+	   This is intended to aid developers
 endif
 
 if ARCH_SHMOBILE
--- 0001/arch/arm/mach-shmobile/setup-emev2.c
+++ work/arch/arm/mach-shmobile/setup-emev2.c	2013-07-09 13:03:45.000000000 +0900
@@ -190,6 +190,11 @@ void __init emev2_add_standard_devices(v
 	emev2_register_pmu();
 }
 
+void __init __weak emev2_clock_init(void)
+{
+	/* in case legacy clocks are disabled then do nothing */
+}
+
 void __init emev2_init_delay(void)
 {
 	shmobile_setup_delay(533, 1, 3); /* Cortex-A9 @ 533MHz */


From magnus.damm at gmail.com  Tue Jul  9 01:44:09 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 14:44:09 +0900
Subject: [PATCH 04/04] ARM: shmobile: Allow ARCH_SHMOBILE_MULTI timer
 configuration
In-Reply-To: <20130709054331.14007.66068.sendpatchset@w520>
References: <20130709054331.14007.66068.sendpatchset@w520>
Message-ID: <20130709054409.14007.23571.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Move the timer configuration bits to allow use in
case of ARCH_SHMOBILE or ARCH_SHMOBILE_MULTI.

The timers all make use of the regular driver model
so they are safe to enable for ARCH_MULTIPLATFORM.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/Kconfig |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

--- 0005/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-07-09 12:07:23.000000000 +0900
@@ -30,6 +30,8 @@ config MACH_KZM9D_REFERENCE
 	   of not supporting a number of devices.
 
 	   This is intended to aid developers
+
+comment "SH-Mobile System Configuration"
 endif
 
 if ARCH_SHMOBILE
@@ -243,6 +245,15 @@ config CPU_HAS_INTEVT
         bool
 	default y
 
+config SH_CLK_CPG
+	bool
+
+source "drivers/sh/Kconfig"
+
+endif
+
+if ARCH_SHMOBILE || ARCH_SHMOBILE_MULTI
+
 menu "Timer and clock configuration"
 
 config SHMOBILE_TIMER_HZ
@@ -277,9 +288,4 @@ config EM_TIMER_STI
 
 endmenu
 
-config SH_CLK_CPG
-	bool
-
-source "drivers/sh/Kconfig"
-
 endif


From thierry.reding at gmail.com  Tue Jul  9 02:04:49 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 9 Jul 2013 08:04:49 +0200
Subject: [PATCH V2] ARM: tegra: enable gpio-keys on dalmore
In-Reply-To: <1373102069-5641-1-git-send-email-ldewangan@nvidia.com>
References: <1373102069-5641-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <20130709060447.GA17499@mithrandir>

On Sat, Jul 06, 2013 at 02:44:29PM +0530, Laxman Dewangan wrote:
> Dalmore have the keys mounted on board which are connected
> to different pins of Tegra.
> 
> Add the keys entry in DTS file to enable key functionality.
> This will enable KEY_POWER, KEY_HOME, KEY_VOLUMEUP and
> KEY_VOLUMEDOWN.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> ---
> Changes from V1:
> - Reorder the nodes.
> 
>  arch/arm/boot/dts/tegra114-dalmore.dts |   30 ++++++++++++++++++++++++++++++
>  1 files changed, 30 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
> index cb640eb..259b517 100644
> --- a/arch/arm/boot/dts/tegra114-dalmore.dts
> +++ b/arch/arm/boot/dts/tegra114-dalmore.dts
> @@ -883,6 +883,35 @@
>  		};
>  	};
>  
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +
> +		home {
> +			label = "Home";
> +			gpios = <&gpio TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
> +			linux,code = <102>; /* KEY_HOME */

I wonder if these should maybe go into a header file as well so that
symbolic names can be used. That'll make the value self-descriptive and
allow the comment to be dropped.

> +		volume_down {
> +			label = "VolumeDown";
> +			gpios = <&gpio TEGRA_GPIO(R, 1) GPIO_ACTIVE_LOW>;
> +			linux,code = <114>; /* KEY_VOLUMEDOWN */
> +		};
> +
> +		volume_up {
> +			label = "VolumeUp";
> +			gpios = <&gpio TEGRA_GPIO(R, 2) GPIO_ACTIVE_LOW>;
> +			linux,code = <115>; /* KEY_VOLUMEUP */
> +		};
> +	};

Nit: Perhaps the labels should be "Volume Down" and "Volume Up" here?

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/20130709/75068339/attachment.sig>

From shawn.guo at linaro.org  Tue Jul  9 02:12:21 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Jul 2013 14:12:21 +0800
Subject: [PATCH v4 0/6] serial: imx: add DMA support for imx6
In-Reply-To: <1373274862-2695-1-git-send-email-b32955@freescale.com>
References: <1373274862-2695-1-git-send-email-b32955@freescale.com>
Message-ID: <20130709061219.GE16656@S2101-09.ap.freescale.net>

On Mon, Jul 08, 2013 at 05:14:16PM +0800, Huang Shijie wrote:
>   ARM: dts: imx6sl: add "fsl,imx6q-uart" for uart compatible
>   ARM: dts: imx6q{dl}: add DTE pads for uart
>   ARM: dts: imx6q{dl}: add a DTE uart pinctrl for uart2
>   ARM: dts: enable the uart2 for imx6q-arm2

Applied these 4, thanks.



From shawn.guo at linaro.org  Tue Jul  9 02:17:44 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Jul 2013 14:17:44 +0800
Subject: [PATCH 1/2] ARM: dts: imx6dl-wandboard: Add SDHC1 and SDHC2 ports
In-Reply-To: <1373296484-29847-1-git-send-email-festevam@gmail.com>
References: <1373296484-29847-1-git-send-email-festevam@gmail.com>
Message-ID: <20130709061742.GF16656@S2101-09.ap.freescale.net>

On Mon, Jul 08, 2013 at 12:14:43PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Wandboard has a SD card slot on the baseboard connected to SDHC1 and a
> BCM4329 (Wifi + Bluetooth chip) connected to SDHC2.
> 
> Add support for these ports.
> 
> While at it, provide the card detect gpio on SDHC3.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  arch/arm/boot/dts/imx6dl-wandboard.dts | 17 +++++++++++++++++
>  arch/arm/boot/dts/imx6dl.dtsi          | 29 +++++++++++++++++++++++++++++
>  2 files changed, 46 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts b/arch/arm/boot/dts/imx6dl-wandboard.dts
> index ab6a053..027ece5 100644
> --- a/arch/arm/boot/dts/imx6dl-wandboard.dts
> +++ b/arch/arm/boot/dts/imx6dl-wandboard.dts
> @@ -83,6 +83,8 @@
>  		pinctrl_hog: hoggrp {
>  			fsl,pins = <
>  				MX6DL_PAD_GPIO_0__CCM_CLKO1    0x130b0
> +				MX6DL_PAD_GPIO_2__GPIO1_IO02	0x80000000
> +				MX6DL_PAD_EIM_DA9__GPIO3_IO09	0x80000000
>  			>;
>  		};
>  	};
> @@ -110,8 +112,23 @@
>  	status = "okay";
>  };
>  
> +&usdhc1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usdhc1_2>;
> +	cd-gpios = <&gpio1 2 0>;
> +	status = "okay";
> +};
> +
> +&usdhc2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usdhc2_2>;
> +	non-removable;
> +	status = "okay";
> +};
> +
>  &usdhc3 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_usdhc3_2>;
> +	cd-gpios = <&gpio3 9 0>;
>  	status = "okay";
>  };
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index 4505109..e08c54c 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boot/dts/imx6dl.dtsi
> @@ -255,6 +255,35 @@
>  					};
>  				};
>  
> +				usdhc1 {
> +					pinctrl_usdhc1_1: usdhc1grp-1 {
> +						fsl,pins = <
> +							MX6DL_PAD_SD1_CMD__SD1_CMD    0x17059
> +							MX6DL_PAD_SD1_CLK__SD1_CLK    0x10059
> +							MX6DL_PAD_SD1_DAT0__SD1_DATA0 0x17059
> +							MX6DL_PAD_SD1_DAT1__SD1_DATA1 0x17059
> +							MX6DL_PAD_SD1_DAT2__SD1_DATA2 0x17059
> +							MX6DL_PAD_SD1_DAT3__SD1_DATA3 0x17059
> +							MX6DL_PAD_NANDF_D0__SD1_DATA4 0x17059
> +							MX6DL_PAD_NANDF_D1__SD1_DATA5 0x17059
> +							MX6DL_PAD_NANDF_D2__SD1_DATA6 0x17059
> +							MX6DL_PAD_NANDF_D3__SD1_DATA7 0x17059
> +						>;
> +					};
> +
> +					pinctrl_usdhc1_2: usdhc1grp-2 {
> +						fsl,pins = <
> +							MX6DL_PAD_SD1_CMD__SD1_CMD    0x17059
> +							MX6DL_PAD_SD1_CLK__SD1_CLK    0x10059
> +							MX6DL_PAD_SD1_DAT0__SD1_DATA0 0x17059
> +							MX6DL_PAD_SD1_DAT1__SD1_DATA1 0x17059
> +							MX6DL_PAD_SD1_DAT2__SD1_DATA2 0x17059
> +							MX6DL_PAD_SD1_DAT3__SD1_DATA3 0x17059
> +						>;
> +					};
> +				};
> +
> +

Because imx6q and imx6dl are pin-to-pin compatible, from now on, I would
require that any pin function group addition for either imx6q or imx6dl
be added as a couple for both, with the same label name.

Shawn

>  				usdhc2 {
>  					pinctrl_usdhc2_1: usdhc2grp-1 {
>  						fsl,pins = <
> -- 
> 1.8.1.2
> 



From thierry.reding at gmail.com  Tue Jul  9 02:21:14 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 9 Jul 2013 08:21:14 +0200
Subject: [lm-sensors] [PATCH 1/2] ARM: dt: t30 cardhu: add dt entry for
 lm90
In-Reply-To: <20130708131421.GB21638@roeck-us.net>
References: <1372928979-26938-1-git-send-email-wni@nvidia.com>
 <1372928979-26938-2-git-send-email-wni@nvidia.com>
 <51D70483.70203@wwwdotorg.org> <51DA6BD4.1040300@nvidia.com>
 <20130708095024.041a6d57@endymion.delvare>
 <51DA8805.50709@nvidia.com> <20130708131421.GB21638@roeck-us.net>
Message-ID: <20130709062112.GC17499@mithrandir>

On Mon, Jul 08, 2013 at 06:14:21AM -0700, Guenter Roeck wrote:
> On Mon, Jul 08, 2013 at 05:36:05PM +0800, Wei Ni wrote:
> > On 07/08/2013 03:50 PM, Jean Delvare wrote:
> > > On Mon, 8 Jul 2013 15:35:48 +0800, Wei Ni wrote:
> > >> On 07/06/2013 01:38 AM, Stephen Warren wrote:
> > >>> On 07/04/2013 03:09 AM, Wei Ni wrote:
> > >>>> Enable thermal sensor lm90 for t30 cardhu.
> > >>>
> > >>>> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
> > >>>
> > >>>> +		nct1008: nct1008 {
> > >>>> +			compatible = "lm90,nct1008";
> > >>>
> > >>> "lm90" isn't a valid vendor prefix. I believe the value you want is
> > >>> "onnn,nct1008". Same comment for patch 2/2.
> > >>
> > >> The lm90 doesn't support device tree very well.
> > > 
> > > I doubt it, but if this is the case, then please fix it, instead of
> > > working the problem around in a different place.
> > > 
> > >> In the DT, we need to
> > >> named as "lm90" so that the lm90 driver can be loaded,
> > > 
> > > Not that I am an expert with regards to DT, but this doesn't make any
> > > sense to me. AFAIK DT is about devices, not which drivers handle them.
> > > 
> > >> and we also need
> > >> to add "nct1008" to indicate this is the nct1008 device, so that the
> > >> lm90 driver can be loaded with the right i2c_device_id->driver_data.
> > >>
> > >> I set the " compatible = "lm90,nct1008" ", this is the simplest way, and
> > >> we doesn't need to change the lm90.c.
> > > 
> > > There's no problem with changing the lm90 driver, if this is the right
> > > thing to do.
> > 
> > Ok, I will add DT support in the lm90.c in my next version patch.
> > 
> Only if you can show that it is necessary.

It should work out of the box. As a matter of fact the same chip is used
on Tamonten and the DTS files use "onnn,nct1008". That used to work. If
it no longer does then that's a regression.

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/20130709/e5ffac6e/attachment.sig>

From shawn.guo at linaro.org  Tue Jul  9 02:24:15 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Jul 2013 14:24:15 +0800
Subject: [PATCH 3/3] ARM: imx: mm-imx3: Free l2x0_base
In-Reply-To: <1373306318-15604-3-git-send-email-festevam@gmail.com>
References: <1373306318-15604-1-git-send-email-festevam@gmail.com>
 <1373306318-15604-3-git-send-email-festevam@gmail.com>
Message-ID: <20130709062414.GG16656@S2101-09.ap.freescale.net>

On Mon, Jul 08, 2013 at 02:58:38PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> After l2x0_base has been used, we should free it.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  arch/arm/mach-imx/mm-imx3.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-imx/mm-imx3.c b/arch/arm/mach-imx/mm-imx3.c
> index 0884ca9..3143f5e 100644
> --- a/arch/arm/mach-imx/mm-imx3.c
> +++ b/arch/arm/mach-imx/mm-imx3.c
> @@ -113,6 +113,7 @@ static void __init imx3_init_l2x0(void)
>  	}
>  
>  	l2x0_init(l2x0_base, 0x00030024, 0x00000000);
> +	iounmap(l2x0_base);

Are you sure?  I think cache-l2x0 driver still needs the mapping after
that.

Shawn

>  #endif
>  }
>  
> -- 
> 1.8.1.2
> 



From shawn.guo at linaro.org  Tue Jul  9 02:26:53 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Jul 2013 14:26:53 +0800
Subject: [PATCH 1/3] ARM: imx: Select CACHE_L2X0
In-Reply-To: <1373306318-15604-1-git-send-email-festevam@gmail.com>
References: <1373306318-15604-1-git-send-email-festevam@gmail.com>
Message-ID: <20130709062651.GH16656@S2101-09.ap.freescale.net>

On Mon, Jul 08, 2013 at 02:58:36PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Select CACHE_L2X0 for mx31/35/51/53/6q/6sl.
> 
We should select the option from defconfig, so that the support can be
disabled for whatever purpose, e.g. debugging, from menuconfig.

Shawn

> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  arch/arm/mach-imx/Kconfig | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index f546560..f864af2 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -122,6 +122,7 @@ config SOC_IMX27
>  
>  config SOC_IMX31
>  	bool
> +	select CACHE_L2X0
>  	select COMMON_CLK
>  	select CPU_V6
>  	select IMX_HAVE_PLATFORM_MXC_RNGA
> @@ -131,6 +132,7 @@ config SOC_IMX31
>  config SOC_IMX35
>  	bool
>  	select ARCH_MXC_IOMUX_V3
> +	select CACHE_L2X0
>  	select COMMON_CLK
>  	select CPU_V6K
>  	select HAVE_EPIT
> @@ -142,6 +144,7 @@ config SOC_IMX5
>  	select ARCH_HAS_CPUFREQ
>  	select ARCH_HAS_OPP
>  	select ARCH_MXC_IOMUX_V3
> +	select CACHE_L2X0
>  	select COMMON_CLK
>  	select CPU_V7
>  	select MXC_TZIC
> @@ -785,6 +788,7 @@ config SOC_IMX6Q
>  	bool "i.MX6 Quad/DualLite support"
>  	select ARCH_HAS_CPUFREQ
>  	select ARCH_HAS_OPP
> +	select CACHE_L2X0
>  	select ARM_CPU_SUSPEND if PM
>  	select ARM_ERRATA_754322
>  	select ARM_ERRATA_764369 if SMP
> @@ -815,6 +819,7 @@ config SOC_IMX6SL
>  	select ARM_ERRATA_754322
>  	select ARM_ERRATA_775420
>  	select ARM_GIC
> +	select CACHE_L2X0
>  	select CPU_V7
>  	select HAVE_IMX_ANATOP
>  	select HAVE_IMX_GPC
> -- 
> 1.8.1.2
> 



From sachin.kamat at linaro.org  Tue Jul  9 02:12:44 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Tue,  9 Jul 2013 11:42:44 +0530
Subject: [PATCH v2 3/3] of/documentation: Update G2D documentation
Message-ID: <1373350364-2952-1-git-send-email-sachin.kamat@linaro.org>

Exynos5250 G2D IP requires only the gate clock. Update the
binding documentation accordingly.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
Cc: Inki Dae <inki.dae at samsung.com>
---
Updated the description of clock-names as suggested by Tomasz Figa.
---
 .../devicetree/bindings/gpu/samsung-g2d.txt        |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
index 3f454ff..c4f358d 100644
--- a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
+++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
@@ -11,8 +11,11 @@ Required properties:
 
   - interrupts : G2D interrupt number to the CPU.
   - clocks : from common clock binding: handle to G2D clocks.
-  - clock-names : from common clock binding: must contain "sclk_fimg2d" and
-		  "fimg2d", corresponding to entries in the clocks property.
+  - clock-names : names of clocks listed in clocks property, in the same
+		  order, depending on SoC type:
+		  - for S5PV210 and Exynos4 based SoCs: "fimg2d" and
+		    "sclk_fimg2d"
+		  - for Exynos5250 SoC: "fimg2d".
 
 Example:
 	g2d at 12800000 {
-- 
1.7.9.5



From elen.song at atmel.com  Tue Jul  9 02:33:39 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 9 Jul 2013 14:33:39 +0800
Subject: [PATCH 0/7] serial: at91: make usart and uart support dma transfer
Message-ID: <1373351626-30143-1-git-send-email-elen.song@atmel.com>

After at91sam9g45 socs, the usart only support dma transfer.
This patch serial focus on:
1) distinguish pdc and dma transfer
2) support usart dma rx and tx transfer
3) distinguish usart and uart
4) support uart dma rx and tx transfer

For those only support PDC transfer socs, we use "atmel,use-pdc-rx", "atmel,use-pdc-tx" to establish a PDC transfer.
So we switch the name from "use-dma" to "use-pdc" to state more clearly.
For those only support DMA transfer socs, we use dma binding to establish a DMA transfer, detail see the last patch.
We also distinguish usart and uart by read ip name, the dbgu is regard as a uart.
Because uart lack timeout function, we use software timer to trigger rx.

Elen Song (7):
  serial: at91: correct definition from DMA to PDC
  serial: at91: add tx dma support
  serial: at91: add rx dma support
  serial: at91: make DBGU support dma and pdc transfers
  serial: at91: distinguish usart and uart
  serial: at91: modify UART to use software timer to trigger rx
  serial: at91: add dma support in usart binding descriptions

 Documentation/devicetree/bindings/serial/rs485.txt |    4 +-
 .../devicetree/bindings/tty/serial/atmel-usart.txt |   29 +-
 arch/arm/boot/dts/at91rm9200.dtsi                  |   16 +-
 arch/arm/boot/dts/at91sam9260.dtsi                 |   24 +-
 arch/arm/boot/dts/at91sam9263.dtsi                 |   12 +-
 arch/arm/boot/dts/at91sam9g45.dtsi                 |   16 +-
 arch/arm/mach-at91/at91rm9200_devices.c            |   20 +-
 arch/arm/mach-at91/at91sam9260_devices.c           |   28 +-
 arch/arm/mach-at91/at91sam9261_devices.c           |   16 +-
 arch/arm/mach-at91/at91sam9263_devices.c           |   16 +-
 arch/arm/mach-at91/at91sam9g45_devices.c           |   20 +-
 arch/arm/mach-at91/at91sam9rl_devices.c            |   20 +-
 drivers/tty/serial/atmel_serial.c                  |  582 ++++++++++++++++++--
 include/linux/atmel_serial.h                       |    2 +
 include/linux/platform_data/atmel.h                |    2 +
 15 files changed, 665 insertions(+), 142 deletions(-)

-- 
1.7.9.5



From elen.song at atmel.com  Tue Jul  9 02:33:40 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 9 Jul 2013 14:33:40 +0800
Subject: [PATCH 1/7] serial: at91: correct definition from DMA to PDC
In-Reply-To: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373351626-30143-2-git-send-email-elen.song@atmel.com>

The DMA is available since at91sam9x5 socs, before that, we use PDC.

Signed-off-by: Elen Song <elen.song at atmel.com>
---
 Documentation/devicetree/bindings/serial/rs485.txt |    4 +-
 .../devicetree/bindings/tty/serial/atmel-usart.txt |   12 ++--
 arch/arm/boot/dts/at91rm9200.dtsi                  |   16 ++---
 arch/arm/boot/dts/at91sam9260.dtsi                 |   24 +++----
 arch/arm/boot/dts/at91sam9263.dtsi                 |   12 ++--
 arch/arm/boot/dts/at91sam9g45.dtsi                 |   16 ++---
 arch/arm/mach-at91/at91rm9200_devices.c            |   20 +++---
 arch/arm/mach-at91/at91sam9260_devices.c           |   28 ++++----
 arch/arm/mach-at91/at91sam9261_devices.c           |   16 ++---
 arch/arm/mach-at91/at91sam9263_devices.c           |   16 ++---
 arch/arm/mach-at91/at91sam9g45_devices.c           |   20 +++---
 arch/arm/mach-at91/at91sam9rl_devices.c            |   20 +++---
 drivers/tty/serial/atmel_serial.c                  |   74 ++++++++++----------
 include/linux/platform_data/atmel.h                |    4 +-
 14 files changed, 141 insertions(+), 141 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/rs485.txt b/Documentation/devicetree/bindings/serial/rs485.txt
index 1e753c6..7c8581e 100644
--- a/Documentation/devicetree/bindings/serial/rs485.txt
+++ b/Documentation/devicetree/bindings/serial/rs485.txt
@@ -23,8 +23,8 @@ RS485 example for Atmel USART:
 		compatible = "atmel,at91sam9260-usart";
 		reg = <0xfff8c000 0x4000>;
 		interrupts = <7>;
-		atmel,use-dma-rx;
-		atmel,use-dma-tx;
+		atmel,use-pdc-rx;
+		atmel,use-pdc-tx;
 		linux,rs485-enabled-at-boot-time;
 		rs485-rts-delay = <0 200>;		// in milliseconds
 	};
diff --git a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
index a49d9a1..82f45ec 100644
--- a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
@@ -8,8 +8,8 @@ Required properties:
 - interrupts: Should contain interrupt
 
 Optional properties:
-- atmel,use-dma-rx: use of PDC or DMA for receiving data
-- atmel,use-dma-tx: use of PDC or DMA for transmitting data
+- atmel,use-pdc-rx: use of PDC for receiving data
+- atmel,use-pdc-tx: use of PDC for transmitting data
 
 <chip> compatible description:
 - at91rm9200:  legacy USART support
@@ -19,9 +19,9 @@ Example:
 
 	usart0: serial at fff8c000 {
 		compatible = "atmel,at91sam9260-usart";
-		reg = <0xfff8c000 0x4000>;
-		interrupts = <7>;
-		atmel,use-dma-rx;
-		atmel,use-dma-tx;
+		reg = <0xfff8c000 0x200>;
+		interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
+		atmel,use-pdc-rx;
+		atmel,use-pdc-tx;
 	};
 
diff --git a/arch/arm/boot/dts/at91rm9200.dtsi b/arch/arm/boot/dts/at91rm9200.dtsi
index 1fc645e..2dcef27 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -537,8 +537,8 @@
 				compatible = "atmel,at91rm9200-usart";
 				reg = <0xfffc0000 0x200>;
 				interrupts = <6 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_uart0>;
 				status = "disabled";
@@ -548,8 +548,8 @@
 				compatible = "atmel,at91rm9200-usart";
 				reg = <0xfffc4000 0x200>;
 				interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_uart1>;
 				status = "disabled";
@@ -559,8 +559,8 @@
 				compatible = "atmel,at91rm9200-usart";
 				reg = <0xfffc8000 0x200>;
 				interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_uart2>;
 				status = "disabled";
@@ -570,8 +570,8 @@
 				compatible = "atmel,at91rm9200-usart";
 				reg = <0xfffcc000 0x200>;
 				interrupts = <23 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_uart3>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index 899a7cf..1fcf6f6 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -475,8 +475,8 @@
 				compatible = "atmel,at91sam9260-usart";
 				reg = <0xfffb0000 0x200>;
 				interrupts = <6 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart0>;
 				status = "disabled";
@@ -486,8 +486,8 @@
 				compatible = "atmel,at91sam9260-usart";
 				reg = <0xfffb4000 0x200>;
 				interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart1>;
 				status = "disabled";
@@ -497,8 +497,8 @@
 				compatible = "atmel,at91sam9260-usart";
 				reg = <0xfffb8000 0x200>;
 				interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart2>;
 				status = "disabled";
@@ -508,8 +508,8 @@
 				compatible = "atmel,at91sam9260-usart";
 				reg = <0xfffd0000 0x200>;
 				interrupts = <23 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart3>;
 				status = "disabled";
@@ -519,8 +519,8 @@
 				compatible = "atmel,at91sam9260-usart";
 				reg = <0xfffd4000 0x200>;
 				interrupts = <24 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_uart0>;
 				status = "disabled";
@@ -530,8 +530,8 @@
 				compatible = "atmel,at91sam9260-usart";
 				reg = <0xfffd8000 0x200>;
 				interrupts = <25 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_uart1>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
index ff63811..eb1dac2 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -426,8 +426,8 @@
 				compatible = "atmel,at91sam9260-usart";
 				reg = <0xfff8c000 0x200>;
 				interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart0>;
 				status = "disabled";
@@ -437,8 +437,8 @@
 				compatible = "atmel,at91sam9260-usart";
 				reg = <0xfff90000 0x200>;
 				interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart1>;
 				status = "disabled";
@@ -448,8 +448,8 @@
 				compatible = "atmel,at91sam9260-usart";
 				reg = <0xfff94000 0x200>;
 				interrupts = <9 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart2>;
 				status = "disabled";
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index cb44bbb..13c7682 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -485,8 +485,8 @@
 				compatible = "atmel,at91sam9260-usart";
 				reg = <0xfff8c000 0x200>;
 				interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart0>;
 				status = "disabled";
@@ -496,8 +496,8 @@
 				compatible = "atmel,at91sam9260-usart";
 				reg = <0xfff90000 0x200>;
 				interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart1>;
 				status = "disabled";
@@ -507,8 +507,8 @@
 				compatible = "atmel,at91sam9260-usart";
 				reg = <0xfff94000 0x200>;
 				interrupts = <9 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart2>;
 				status = "disabled";
@@ -518,8 +518,8 @@
 				compatible = "atmel,at91sam9260-usart";
 				reg = <0xfff98000 0x200>;
 				interrupts = <10 IRQ_TYPE_LEVEL_HIGH 5>;
-				atmel,use-dma-rx;
-				atmel,use-dma-tx;
+				atmel,use-pdc-rx;
+				atmel,use-pdc-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart3>;
 				status = "disabled";
diff --git a/arch/arm/mach-at91/at91rm9200_devices.c b/arch/arm/mach-at91/at91rm9200_devices.c
index 3ebc979..6766d17 100644
--- a/arch/arm/mach-at91/at91rm9200_devices.c
+++ b/arch/arm/mach-at91/at91rm9200_devices.c
@@ -920,8 +920,8 @@ static struct resource dbgu_resources[] = {
 };
 
 static struct atmel_uart_data dbgu_data = {
-	.use_dma_tx	= 0,
-	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
+	.use_pdc_tx	= 0,
+	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
 };
 
 static u64 dbgu_dmamask = DMA_BIT_MASK(32);
@@ -958,8 +958,8 @@ static struct resource uart0_resources[] = {
 };
 
 static struct atmel_uart_data uart0_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart0_dmamask = DMA_BIT_MASK(32);
@@ -1007,8 +1007,8 @@ static struct resource uart1_resources[] = {
 };
 
 static struct atmel_uart_data uart1_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart1_dmamask = DMA_BIT_MASK(32);
@@ -1058,8 +1058,8 @@ static struct resource uart2_resources[] = {
 };
 
 static struct atmel_uart_data uart2_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart2_dmamask = DMA_BIT_MASK(32);
@@ -1101,8 +1101,8 @@ static struct resource uart3_resources[] = {
 };
 
 static struct atmel_uart_data uart3_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart3_dmamask = DMA_BIT_MASK(32);
diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
index eda8d16..0a087a7c 100644
--- a/arch/arm/mach-at91/at91sam9260_devices.c
+++ b/arch/arm/mach-at91/at91sam9260_devices.c
@@ -817,8 +817,8 @@ static struct resource dbgu_resources[] = {
 };
 
 static struct atmel_uart_data dbgu_data = {
-	.use_dma_tx	= 0,
-	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
+	.use_pdc_tx	= 0,
+	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
 };
 
 static u64 dbgu_dmamask = DMA_BIT_MASK(32);
@@ -855,8 +855,8 @@ static struct resource uart0_resources[] = {
 };
 
 static struct atmel_uart_data uart0_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart0_dmamask = DMA_BIT_MASK(32);
@@ -906,8 +906,8 @@ static struct resource uart1_resources[] = {
 };
 
 static struct atmel_uart_data uart1_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart1_dmamask = DMA_BIT_MASK(32);
@@ -949,8 +949,8 @@ static struct resource uart2_resources[] = {
 };
 
 static struct atmel_uart_data uart2_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart2_dmamask = DMA_BIT_MASK(32);
@@ -992,8 +992,8 @@ static struct resource uart3_resources[] = {
 };
 
 static struct atmel_uart_data uart3_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart3_dmamask = DMA_BIT_MASK(32);
@@ -1035,8 +1035,8 @@ static struct resource uart4_resources[] = {
 };
 
 static struct atmel_uart_data uart4_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart4_dmamask = DMA_BIT_MASK(32);
@@ -1073,8 +1073,8 @@ static struct resource uart5_resources[] = {
 };
 
 static struct atmel_uart_data uart5_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart5_dmamask = DMA_BIT_MASK(32);
diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c
index 629ea5f..fcaae28 100644
--- a/arch/arm/mach-at91/at91sam9261_devices.c
+++ b/arch/arm/mach-at91/at91sam9261_devices.c
@@ -878,8 +878,8 @@ static struct resource dbgu_resources[] = {
 };
 
 static struct atmel_uart_data dbgu_data = {
-	.use_dma_tx	= 0,
-	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
+	.use_pdc_tx	= 0,
+	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
 };
 
 static u64 dbgu_dmamask = DMA_BIT_MASK(32);
@@ -916,8 +916,8 @@ static struct resource uart0_resources[] = {
 };
 
 static struct atmel_uart_data uart0_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart0_dmamask = DMA_BIT_MASK(32);
@@ -959,8 +959,8 @@ static struct resource uart1_resources[] = {
 };
 
 static struct atmel_uart_data uart1_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart1_dmamask = DMA_BIT_MASK(32);
@@ -1002,8 +1002,8 @@ static struct resource uart2_resources[] = {
 };
 
 static struct atmel_uart_data uart2_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart2_dmamask = DMA_BIT_MASK(32);
diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
index 858c8aa..a62216b 100644
--- a/arch/arm/mach-at91/at91sam9263_devices.c
+++ b/arch/arm/mach-at91/at91sam9263_devices.c
@@ -1322,8 +1322,8 @@ static struct resource dbgu_resources[] = {
 };
 
 static struct atmel_uart_data dbgu_data = {
-	.use_dma_tx	= 0,
-	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
+	.use_pdc_tx	= 0,
+	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
 };
 
 static u64 dbgu_dmamask = DMA_BIT_MASK(32);
@@ -1360,8 +1360,8 @@ static struct resource uart0_resources[] = {
 };
 
 static struct atmel_uart_data uart0_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart0_dmamask = DMA_BIT_MASK(32);
@@ -1403,8 +1403,8 @@ static struct resource uart1_resources[] = {
 };
 
 static struct atmel_uart_data uart1_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart1_dmamask = DMA_BIT_MASK(32);
@@ -1446,8 +1446,8 @@ static struct resource uart2_resources[] = {
 };
 
 static struct atmel_uart_data uart2_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart2_dmamask = DMA_BIT_MASK(32);
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index acb703e..4c81fd1 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -1585,8 +1585,8 @@ static struct resource dbgu_resources[] = {
 };
 
 static struct atmel_uart_data dbgu_data = {
-	.use_dma_tx	= 0,
-	.use_dma_rx	= 0,
+	.use_pdc_tx	= 0,
+	.use_pdc_rx	= 0,
 };
 
 static u64 dbgu_dmamask = DMA_BIT_MASK(32);
@@ -1623,8 +1623,8 @@ static struct resource uart0_resources[] = {
 };
 
 static struct atmel_uart_data uart0_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart0_dmamask = DMA_BIT_MASK(32);
@@ -1666,8 +1666,8 @@ static struct resource uart1_resources[] = {
 };
 
 static struct atmel_uart_data uart1_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart1_dmamask = DMA_BIT_MASK(32);
@@ -1709,8 +1709,8 @@ static struct resource uart2_resources[] = {
 };
 
 static struct atmel_uart_data uart2_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart2_dmamask = DMA_BIT_MASK(32);
@@ -1752,8 +1752,8 @@ static struct resource uart3_resources[] = {
 };
 
 static struct atmel_uart_data uart3_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart3_dmamask = DMA_BIT_MASK(32);
diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
index 352468f..5cd8c76 100644
--- a/arch/arm/mach-at91/at91sam9rl_devices.c
+++ b/arch/arm/mach-at91/at91sam9rl_devices.c
@@ -954,8 +954,8 @@ static struct resource dbgu_resources[] = {
 };
 
 static struct atmel_uart_data dbgu_data = {
-	.use_dma_tx	= 0,
-	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
+	.use_pdc_tx	= 0,
+	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
 };
 
 static u64 dbgu_dmamask = DMA_BIT_MASK(32);
@@ -992,8 +992,8 @@ static struct resource uart0_resources[] = {
 };
 
 static struct atmel_uart_data uart0_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart0_dmamask = DMA_BIT_MASK(32);
@@ -1043,8 +1043,8 @@ static struct resource uart1_resources[] = {
 };
 
 static struct atmel_uart_data uart1_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart1_dmamask = DMA_BIT_MASK(32);
@@ -1086,8 +1086,8 @@ static struct resource uart2_resources[] = {
 };
 
 static struct atmel_uart_data uart2_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart2_dmamask = DMA_BIT_MASK(32);
@@ -1129,8 +1129,8 @@ static struct resource uart3_resources[] = {
 };
 
 static struct atmel_uart_data uart3_data = {
-	.use_dma_tx	= 1,
-	.use_dma_rx	= 1,
+	.use_pdc_tx	= 1,
+	.use_pdc_rx	= 1,
 };
 
 static u64 uart3_dmamask = DMA_BIT_MASK(32);
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 3467462..ab9de8a 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -140,11 +140,11 @@ struct atmel_uart_port {
 	u32			backup_imr;	/* IMR saved during suspend */
 	int			break_active;	/* break being received */
 
-	short			use_dma_rx;	/* enable PDC receiver */
+	short			use_pdc_rx;	/* enable PDC receiver */
 	short			pdc_rx_idx;	/* current PDC RX buffer */
 	struct atmel_dma_buffer	pdc_rx[2];	/* PDC receier */
 
-	short			use_dma_tx;	/* enable PDC transmitter */
+	short			use_pdc_tx;	/* enable PDC transmitter */
 	struct atmel_dma_buffer	pdc_tx;		/* PDC transmitter */
 
 	struct tasklet_struct	tasklet;
@@ -181,26 +181,26 @@ to_atmel_uart_port(struct uart_port *uart)
 }
 
 #ifdef CONFIG_SERIAL_ATMEL_PDC
-static bool atmel_use_dma_rx(struct uart_port *port)
+static bool atmel_use_pdc_rx(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	return atmel_port->use_dma_rx;
+	return atmel_port->use_pdc_rx;
 }
 
-static bool atmel_use_dma_tx(struct uart_port *port)
+static bool atmel_use_pdc_tx(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	return atmel_port->use_dma_tx;
+	return atmel_port->use_pdc_tx;
 }
 #else
-static bool atmel_use_dma_rx(struct uart_port *port)
+static bool atmel_use_pdc_rx(struct uart_port *port)
 {
 	return false;
 }
 
-static bool atmel_use_dma_tx(struct uart_port *port)
+static bool atmel_use_pdc_tx(struct uart_port *port)
 {
 	return false;
 }
@@ -233,7 +233,7 @@ void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
 		mode |= ATMEL_US_USMODE_RS485;
 	} else {
 		dev_dbg(port->dev, "Setting UART to RS232\n");
-		if (atmel_use_dma_tx(port))
+		if (atmel_use_pdc_tx(port))
 			atmel_port->tx_done_mask = ATMEL_US_ENDTX |
 				ATMEL_US_TXBUFE;
 		else
@@ -345,7 +345,7 @@ static void atmel_stop_tx(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		/* disable PDC transmit */
 		UART_PUT_PTCR(port, ATMEL_PDC_TXTDIS);
 	}
@@ -364,7 +364,7 @@ static void atmel_start_tx(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		if (UART_GET_PTSR(port) & ATMEL_PDC_TXTEN)
 			/* The transmitter is already running.  Yes, we
 			   really need this.*/
@@ -390,7 +390,7 @@ static void atmel_start_rx(struct uart_port *port)
 
 	UART_PUT_CR(port, ATMEL_US_RXEN);
 
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		/* enable PDC controller */
 		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
 			port->read_status_mask);
@@ -407,7 +407,7 @@ static void atmel_stop_rx(struct uart_port *port)
 {
 	UART_PUT_CR(port, ATMEL_US_RXDIS);
 
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		/* disable PDC receive */
 		UART_PUT_PTCR(port, ATMEL_PDC_RXTDIS);
 		UART_PUT_IDR(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
@@ -572,7 +572,7 @@ atmel_handle_receive(struct uart_port *port, unsigned int pending)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		/*
 		 * PDC receive. Just schedule the tasklet and let it
 		 * figure out the details.
@@ -661,7 +661,7 @@ static irqreturn_t atmel_interrupt(int irq, void *dev_id)
 /*
  * Called from tasklet with ENDTX and TXBUFE interrupts disabled.
  */
-static void atmel_tx_dma(struct uart_port *port)
+static void atmel_tx_pdc(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 	struct circ_buf *xmit = &port->state->xmit;
@@ -778,7 +778,7 @@ static void atmel_rx_from_ring(struct uart_port *port)
 	spin_lock(&port->lock);
 }
 
-static void atmel_rx_from_dma(struct uart_port *port)
+static void atmel_rx_from_pdc(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 	struct tty_port *tport = &port->state->port;
@@ -868,8 +868,8 @@ static void atmel_tasklet_func(unsigned long data)
 	/* The interrupt handler does not take the lock */
 	spin_lock(&port->lock);
 
-	if (atmel_use_dma_tx(port))
-		atmel_tx_dma(port);
+	if (atmel_use_pdc_tx(port))
+		atmel_tx_pdc(port);
 	else
 		atmel_tx_chars(port);
 
@@ -893,8 +893,8 @@ static void atmel_tasklet_func(unsigned long data)
 		atmel_port->irq_status_prev = status;
 	}
 
-	if (atmel_use_dma_rx(port))
-		atmel_rx_from_dma(port);
+	if (atmel_use_pdc_rx(port))
+		atmel_rx_from_pdc(port);
 	else
 		atmel_rx_from_ring(port);
 
@@ -930,7 +930,7 @@ static int atmel_startup(struct uart_port *port)
 	/*
 	 * Initialize DMA (if necessary)
 	 */
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		int i;
 
 		for (i = 0; i < 2; i++) {
@@ -964,7 +964,7 @@ static int atmel_startup(struct uart_port *port)
 		UART_PUT_RNPR(port, atmel_port->pdc_rx[1].dma_addr);
 		UART_PUT_RNCR(port, PDC_BUFFER_SIZE);
 	}
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
 		struct circ_buf *xmit = &port->state->xmit;
 
@@ -1000,7 +1000,7 @@ static int atmel_startup(struct uart_port *port)
 	/* enable xmit & rcvr */
 	UART_PUT_CR(port, ATMEL_US_TXEN | ATMEL_US_RXEN);
 
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		/* set UART timeout */
 		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
 		UART_PUT_CR(port, ATMEL_US_STTTO);
@@ -1031,7 +1031,7 @@ static void atmel_shutdown(struct uart_port *port)
 	/*
 	 * Shut-down the DMA.
 	 */
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		int i;
 
 		for (i = 0; i < 2; i++) {
@@ -1044,7 +1044,7 @@ static void atmel_shutdown(struct uart_port *port)
 			kfree(pdc->buf);
 		}
 	}
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
 
 		dma_unmap_single(port->dev,
@@ -1080,7 +1080,7 @@ static void atmel_flush_buffer(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		UART_PUT_TCR(port, 0);
 		atmel_port->pdc_tx.ofs = 0;
 	}
@@ -1193,7 +1193,7 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
 	if (termios->c_iflag & (BRKINT | PARMRK))
 		port->read_status_mask |= ATMEL_US_RXBRK;
 
-	if (atmel_use_dma_rx(port))
+	if (atmel_use_pdc_rx(port))
 		/* need to enable error interrupts */
 		UART_PUT_IER(port, port->read_status_mask);
 
@@ -1429,14 +1429,14 @@ static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
 	u32 rs485_delay[2];
 
 	/* DMA/PDC usage specification */
-	if (of_get_property(np, "atmel,use-dma-rx", NULL))
-		atmel_port->use_dma_rx	= 1;
+	if (of_get_property(np, "atmel,use-pdc-rx", NULL))
+		atmel_port->use_pdc_rx	= 1;
 	else
-		atmel_port->use_dma_rx	= 0;
-	if (of_get_property(np, "atmel,use-dma-tx", NULL))
-		atmel_port->use_dma_tx	= 1;
+		atmel_port->use_pdc_rx	= 0;
+	if (of_get_property(np, "atmel,use-pdc-tx", NULL))
+		atmel_port->use_pdc_tx	= 1;
 	else
-		atmel_port->use_dma_tx	= 0;
+		atmel_port->use_pdc_tx	= 0;
 
 	/* rs485 properties */
 	if (of_property_read_u32_array(np, "rs485-rts-delay",
@@ -1467,8 +1467,8 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 	if (pdev->dev.of_node) {
 		atmel_of_init_port(atmel_port, pdev->dev.of_node);
 	} else {
-		atmel_port->use_dma_rx	= pdata->use_dma_rx;
-		atmel_port->use_dma_tx	= pdata->use_dma_tx;
+		atmel_port->use_pdc_rx	= pdata->use_pdc_rx;
+		atmel_port->use_pdc_tx	= pdata->use_pdc_tx;
 		atmel_port->rs485	= pdata->rs485;
 	}
 
@@ -1505,7 +1505,7 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 	/* Use TXEMPTY for interrupt when rs485 else TXRDY or ENDTX|TXBUFE */
 	if (atmel_port->rs485.flags & SER_RS485_ENABLED)
 		atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
-	else if (atmel_use_dma_tx(port)) {
+	else if (atmel_use_pdc_tx(port)) {
 		port->fifosize = PDC_BUFFER_SIZE;
 		atmel_port->tx_done_mask = ATMEL_US_ENDTX | ATMEL_US_TXBUFE;
 	} else {
@@ -1794,7 +1794,7 @@ static int atmel_serial_probe(struct platform_device *pdev)
 		goto err;
 	}
 
-	if (!atmel_use_dma_rx(&port->uart)) {
+	if (!atmel_use_pdc_rx(&port->uart)) {
 		ret = -ENOMEM;
 		data = kmalloc(sizeof(struct atmel_uart_char)
 				* ATMEL_SERIAL_RINGSIZE, GFP_KERNEL);
diff --git a/include/linux/platform_data/atmel.h b/include/linux/platform_data/atmel.h
index 6a293b7..8965fed 100644
--- a/include/linux/platform_data/atmel.h
+++ b/include/linux/platform_data/atmel.h
@@ -76,8 +76,8 @@ struct atmel_nand_data {
  /* Serial */
 struct atmel_uart_data {
 	int			num;		/* port num */
-	short			use_dma_tx;	/* use transmit DMA? */
-	short			use_dma_rx;	/* use receive DMA? */
+	short			use_pdc_tx;	/* use transmit PDC? */
+	short			use_pdc_rx;	/* use receive PDC? */
 	void __iomem		*regs;		/* virt. base address, if any */
 	struct serial_rs485	rs485;		/* rs485 settings */
 };
-- 
1.7.9.5



From elen.song at atmel.com  Tue Jul  9 02:33:41 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 9 Jul 2013 14:33:41 +0800
Subject: [PATCH 2/7] serial: at91: add tx dma support
In-Reply-To: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373351626-30143-3-git-send-email-elen.song@atmel.com>

Request a slave dma channel for tx dma use. Tx dma will setup a single transfer,
when transfer complete, it will call atmel_dma_tx_complete to do finish stuff.

Signed-off-by: Elen Song <elen.song at atmel.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/tty/serial/atmel_serial.c   |  200 +++++++++++++++++++++++++++++++++++
 include/linux/platform_data/atmel.h |    1 +
 2 files changed, 201 insertions(+)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index ab9de8a..c20312d 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -144,9 +144,15 @@ struct atmel_uart_port {
 	short			pdc_rx_idx;	/* current PDC RX buffer */
 	struct atmel_dma_buffer	pdc_rx[2];	/* PDC receier */
 
+	short                   use_dma_tx;     /* enable DMA transmitter */
 	short			use_pdc_tx;	/* enable PDC transmitter */
 	struct atmel_dma_buffer	pdc_tx;		/* PDC transmitter */
 
+	spinlock_t			lock_tx;	/* port lock */
+	struct dma_chan			*chan_tx;
+	struct dma_async_tx_descriptor	*desc_tx;
+	dma_cookie_t			cookie_tx;
+	struct scatterlist		sg_tx;
 	struct tasklet_struct	tasklet;
 	unsigned int		irq_status;
 	unsigned int		irq_status_prev;
@@ -206,6 +212,13 @@ static bool atmel_use_pdc_tx(struct uart_port *port)
 }
 #endif
 
+static bool atmel_use_dma_tx(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+	return atmel_port->use_dma_tx;
+}
+
 /* Enable or disable the rs485 support */
 void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
 {
@@ -564,6 +577,186 @@ static void atmel_tx_chars(struct uart_port *port)
 		UART_PUT_IER(port, atmel_port->tx_done_mask);
 }
 
+static void atmel_dma_tx_complete(void *arg)
+{
+	struct atmel_uart_port *atmel_port = arg;
+	struct uart_port *port = &atmel_port->uart;
+	struct circ_buf *xmit = &port->state->xmit;
+	struct dma_chan *chan = atmel_port->chan_tx;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	if (chan)
+		dmaengine_terminate_all(chan);
+	xmit->tail += sg_dma_len(&atmel_port->sg_tx);
+	xmit->tail &= UART_XMIT_SIZE - 1;
+
+	port->icount.tx += sg_dma_len(&atmel_port->sg_tx);
+
+	spin_lock_irq(&atmel_port->lock_tx);
+	async_tx_ack(atmel_port->desc_tx);
+	atmel_port->cookie_tx = -EINVAL;
+	atmel_port->desc_tx = NULL;
+	spin_unlock_irq(&atmel_port->lock_tx);
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+
+	/* Do we really need this? */
+	if (!uart_circ_empty(xmit))
+		tasklet_schedule(&atmel_port->tasklet);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static void atmel_tx_dma_release(struct atmel_uart_port *atmel_port)
+{
+	struct dma_chan *chan = atmel_port->chan_tx;
+	struct uart_port *port = &(atmel_port->uart);
+
+	if (chan) {
+		dmaengine_terminate_all(chan);
+		dma_release_channel(chan);
+		dma_unmap_sg(port->dev, &atmel_port->sg_tx, 1,
+				DMA_MEM_TO_DEV);
+	}
+
+	atmel_port->desc_tx = NULL;
+	atmel_port->chan_tx = NULL;
+	atmel_port->cookie_tx = -EINVAL;
+}
+
+/*
+ * Called from tasklet with TXRDY interrupt is disabled.
+ */
+static void atmel_tx_dma(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct circ_buf *xmit = &port->state->xmit;
+	struct dma_chan *chan = atmel_port->chan_tx;
+	struct dma_async_tx_descriptor *desc;
+	struct scatterlist *sg = &atmel_port->sg_tx;
+
+	/* Make sure we have an idle channel */
+	if (atmel_port->desc_tx != NULL)
+		return;
+
+	if (!uart_circ_empty(xmit) && !uart_tx_stopped(port)) {
+		/*
+		 * DMA is idle now.
+		 * Port xmit buffer is already mapped,
+		 * and it is one page... Just adjust
+		 * offsets and lengths. Since it is a circular buffer,
+		 * we have to transmit till the end, and then the rest.
+		 * Take the port lock to get a
+		 * consistent xmit buffer state.
+		 */
+		sg->offset = xmit->tail & (UART_XMIT_SIZE - 1);
+		sg_dma_address(sg) = (sg_dma_address(sg) &
+					~(UART_XMIT_SIZE - 1))
+					+ sg->offset;
+		sg_dma_len(sg) = CIRC_CNT_TO_END(xmit->head,
+						xmit->tail,
+						UART_XMIT_SIZE);
+		BUG_ON(!sg_dma_len(sg));
+
+		desc = dmaengine_prep_slave_sg(chan,
+						sg,
+						1,
+						DMA_MEM_TO_DEV,
+						DMA_PREP_INTERRUPT |
+						DMA_CTRL_ACK);
+		if (!desc) {
+			dev_err(port->dev, "Failed to send via dma!\n");
+			return;
+		}
+
+		dma_sync_sg_for_device(port->dev, sg, 1, DMA_MEM_TO_DEV);
+
+		atmel_port->desc_tx = desc;
+		desc->callback = atmel_dma_tx_complete;
+		desc->callback_param = atmel_port;
+		atmel_port->cookie_tx = dmaengine_submit(desc);
+
+	} else {
+		if (atmel_port->rs485.flags & SER_RS485_ENABLED) {
+			/* DMA done, stop TX, start RX for RS485 */
+			atmel_start_rx(port);
+		}
+	}
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+}
+
+static void atmel_tx_request_dma(struct atmel_uart_port *atmel_port)
+{
+	struct uart_port	*port;
+	dma_cap_mask_t		mask;
+	struct dma_slave_config config;
+	int ret, nent;
+
+	if (atmel_port == NULL)
+		return;
+
+	port = &(atmel_port->uart);
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+
+	atmel_port->chan_tx = dma_request_slave_channel(port->dev, "tx");
+	if (atmel_port->chan_tx == NULL)
+		goto chan_err;
+	dev_info(port->dev, "using %s for tx DMA transfers\n",
+		dma_chan_name(atmel_port->chan_tx));
+	atmel_port->use_dma_tx = 1;
+
+	spin_lock_init(&atmel_port->lock_tx);
+	sg_init_table(&atmel_port->sg_tx, 1);
+	/* UART circular tx buffer is an aligned page. */
+	BUG_ON((int)port->state->xmit.buf & ~PAGE_MASK);
+	sg_set_page(&atmel_port->sg_tx,
+			virt_to_page(port->state->xmit.buf),
+			UART_XMIT_SIZE,
+			(int)port->state->xmit.buf & ~PAGE_MASK);
+			nent = dma_map_sg(port->dev,
+					&atmel_port->sg_tx,
+					1,
+					DMA_MEM_TO_DEV);
+
+	if (!nent)
+		dev_dbg(port->dev, "need to release resource of dma\n");
+	else
+		dev_dbg(port->dev, "%s: mapped %d@%p to %x\n", __func__,
+			sg_dma_len(&atmel_port->sg_tx),
+			port->state->xmit.buf,
+			sg_dma_address(&atmel_port->sg_tx));
+
+	/* Configure the slave DMA */
+	memset(&config, 0, sizeof(config));
+	config.direction = DMA_MEM_TO_DEV;
+	config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	config.dst_addr = port->mapbase + ATMEL_US_THR;
+
+	ret = dmaengine_device_control(atmel_port->chan_tx,
+					DMA_SLAVE_CONFIG,
+					(unsigned long)&config);
+	if (ret) {
+		dev_err(port->dev, "DMA tx slave configuration failed\n");
+		goto chan_err;
+	}
+
+	return;
+
+chan_err:
+	dev_err(port->dev, "TX channel not available, switch to pio\n");
+	atmel_port->use_dma_tx = 0;
+	if (atmel_port->chan_tx)
+		atmel_tx_dma_release(atmel_port);
+	return;
+}
+
 /*
  * receive interrupt handler.
  */
@@ -870,6 +1063,8 @@ static void atmel_tasklet_func(unsigned long data)
 
 	if (atmel_use_pdc_tx(port))
 		atmel_tx_pdc(port);
+	else if (atmel_use_dma_tx(port))
+		atmel_tx_dma(port);
 	else
 		atmel_tx_chars(port);
 
@@ -977,6 +1172,8 @@ static int atmel_startup(struct uart_port *port)
 		pdc->ofs = 0;
 	}
 
+	atmel_tx_request_dma(atmel_port);
+
 	/*
 	 * If there is a specific "open" function (to register
 	 * control line interrupts)
@@ -1053,6 +1250,8 @@ static void atmel_shutdown(struct uart_port *port)
 				 DMA_TO_DEVICE);
 	}
 
+	if (atmel_use_dma_tx(port))
+		atmel_tx_dma_release(atmel_port);
 	/*
 	 * Disable all interrupts, port and break condition.
 	 */
@@ -1469,6 +1668,7 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 	} else {
 		atmel_port->use_pdc_rx	= pdata->use_pdc_rx;
 		atmel_port->use_pdc_tx	= pdata->use_pdc_tx;
+		atmel_port->use_dma_tx	= 0;
 		atmel_port->rs485	= pdata->rs485;
 	}
 
diff --git a/include/linux/platform_data/atmel.h b/include/linux/platform_data/atmel.h
index 8965fed..6f5a7c6 100644
--- a/include/linux/platform_data/atmel.h
+++ b/include/linux/platform_data/atmel.h
@@ -78,6 +78,7 @@ struct atmel_uart_data {
 	int			num;		/* port num */
 	short			use_pdc_tx;	/* use transmit PDC? */
 	short			use_pdc_rx;	/* use receive PDC? */
+	short			use_dma_tx;	/* use transmit DMA? */
 	void __iomem		*regs;		/* virt. base address, if any */
 	struct serial_rs485	rs485;		/* rs485 settings */
 };
-- 
1.7.9.5



From elen.song at atmel.com  Tue Jul  9 02:33:42 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 9 Jul 2013 14:33:42 +0800
Subject: [PATCH 3/7] serial: at91: add rx dma support
In-Reply-To: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373351626-30143-4-git-send-email-elen.song@atmel.com>

Request a cyclic dma channel for rx dma use. Use cyclic transfer is to prevent
receive data overrun.

atmel_allocate_desc will allocate a cycle dma cookie after request channel,
after that, enable uart timeout interrupt in startup stage, when data successful
received, the timeout callback will check the residual bytes and insert
receiving datas into the framework during the transfer interval.

When current descriptor finished, the dma callback will also check the residual
bytes and filp the receiving data.

Signed-off-by: Elen Song <elen.song at atmel.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/tty/serial/atmel_serial.c   |  236 +++++++++++++++++++++++++++++++++++
 include/linux/platform_data/atmel.h |    1 +
 2 files changed, 237 insertions(+)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index c20312d..a425ff2 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -140,6 +140,7 @@ struct atmel_uart_port {
 	u32			backup_imr;	/* IMR saved during suspend */
 	int			break_active;	/* break being received */
 
+	short			use_dma_rx;	/* enable DMA receiver */
 	short			use_pdc_rx;	/* enable PDC receiver */
 	short			pdc_rx_idx;	/* current PDC RX buffer */
 	struct atmel_dma_buffer	pdc_rx[2];	/* PDC receier */
@@ -149,10 +150,15 @@ struct atmel_uart_port {
 	struct atmel_dma_buffer	pdc_tx;		/* PDC transmitter */
 
 	spinlock_t			lock_tx;	/* port lock */
+	spinlock_t			lock_rx;	/* port lock */
 	struct dma_chan			*chan_tx;
+	struct dma_chan			*chan_rx;
 	struct dma_async_tx_descriptor	*desc_tx;
+	struct dma_async_tx_descriptor	*desc_rx;
 	dma_cookie_t			cookie_tx;
+	dma_cookie_t			cookie_rx;
 	struct scatterlist		sg_tx;
+	struct scatterlist		sg_rx;
 	struct tasklet_struct	tasklet;
 	unsigned int		irq_status;
 	unsigned int		irq_status_prev;
@@ -219,6 +225,13 @@ static bool atmel_use_dma_tx(struct uart_port *port)
 	return atmel_port->use_dma_tx;
 }
 
+static bool atmel_use_dma_rx(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+	return atmel_port->use_dma_rx;
+}
+
 /* Enable or disable the rs485 support */
 void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
 {
@@ -757,6 +770,204 @@ chan_err:
 	return;
 }
 
+static void atmel_rx_dma_flip_buffer(struct uart_port *port,
+					char *buf, size_t count)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct tty_port *tport = &port->state->port;
+
+	dma_sync_sg_for_cpu(port->dev,
+				&atmel_port->sg_rx,
+				1,
+				DMA_DEV_TO_MEM);
+
+	tty_insert_flip_string(tport, buf, count);
+
+	dma_sync_sg_for_device(port->dev,
+				&atmel_port->sg_rx,
+				1,
+				DMA_DEV_TO_MEM);
+	/*
+	 * Drop the lock here since it might end up calling
+	 * uart_start(), which takes the lock.
+	 */
+	spin_unlock(&port->lock);
+	tty_flip_buffer_push(tport);
+	spin_lock(&port->lock);
+}
+
+static void atmel_dma_rx_complete(void *arg)
+{
+	struct uart_port *port = arg;
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+	tasklet_schedule(&atmel_port->tasklet);
+}
+
+static void atmel_rx_dma_release(struct atmel_uart_port *atmel_port)
+{
+	struct dma_chan *chan = atmel_port->chan_rx;
+	struct uart_port *port = &(atmel_port->uart);
+
+	if (chan) {
+		dmaengine_terminate_all(chan);
+		dma_release_channel(chan);
+		dma_unmap_sg(port->dev, &atmel_port->sg_rx, 1,
+				DMA_DEV_TO_MEM);
+	}
+
+	atmel_port->desc_rx = NULL;
+	atmel_port->chan_rx = NULL;
+	atmel_port->cookie_rx = -EINVAL;
+}
+
+static void atmel_rx_from_dma(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct circ_buf *ring = &atmel_port->rx_ring;
+	struct dma_chan *chan = atmel_port->chan_rx;
+	struct dma_tx_state state;
+	enum dma_status dmastat;
+	size_t pending, count;
+
+
+	/* Reset the UART timeout early so that we don't miss one */
+	UART_PUT_CR(port, ATMEL_US_STTTO);
+	dmastat = dmaengine_tx_status(chan,
+				atmel_port->cookie_rx,
+				&state);
+	/* Restart a new tasklet if DMA status is error */
+	if (dmastat == DMA_ERROR) {
+		dev_dbg(port->dev, "Get residue error, restart tasklet\n");
+		UART_PUT_IER(port, ATMEL_US_TIMEOUT);
+		tasklet_schedule(&atmel_port->tasklet);
+		return;
+	}
+	/* current transfer size should no larger than dma buffer */
+	pending = sg_dma_len(&atmel_port->sg_rx) - state.residue;
+	BUG_ON(pending > sg_dma_len(&atmel_port->sg_rx));
+
+	/*
+	 * This will take the chars we have so far,
+	 * ring->head will record the transfer size, only new bytes come
+	 * will insert into the framework.
+	 */
+	if (pending > ring->head) {
+		count = pending - ring->head;
+
+		atmel_rx_dma_flip_buffer(port, ring->buf + ring->head, count);
+
+		ring->head += count;
+		if (ring->head == sg_dma_len(&atmel_port->sg_rx))
+			ring->head = 0;
+
+		port->icount.rx += count;
+	}
+
+	UART_PUT_IER(port, ATMEL_US_TIMEOUT);
+}
+
+static void atmel_rx_request_dma(struct atmel_uart_port *atmel_port)
+{
+	struct uart_port	*port;
+	dma_cap_mask_t		mask;
+	struct dma_slave_config config;
+	struct circ_buf		*ring;
+	int ret, nent;
+
+	if (atmel_port == NULL)
+		return;
+
+	ring = &atmel_port->rx_ring;
+	port = &(atmel_port->uart);
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_CYCLIC, mask);
+
+	atmel_port->chan_rx = dma_request_slave_channel(port->dev, "rx");
+	if (atmel_port->chan_rx == NULL)
+		goto chan_err;
+	dev_info(port->dev, "using %s for rx DMA transfers\n",
+		dma_chan_name(atmel_port->chan_rx));
+	atmel_port->use_dma_rx = 1;
+
+	spin_lock_init(&atmel_port->lock_rx);
+	sg_init_table(&atmel_port->sg_rx, 1);
+	/* UART circular rx buffer is an aligned page. */
+	BUG_ON((int)port->state->xmit.buf & ~PAGE_MASK);
+	sg_set_page(&atmel_port->sg_rx,
+			virt_to_page(ring->buf),
+			ATMEL_SERIAL_RINGSIZE,
+			(int)ring->buf & ~PAGE_MASK);
+			nent = dma_map_sg(port->dev,
+					&atmel_port->sg_rx,
+					1,
+					DMA_DEV_TO_MEM);
+
+	if (!nent)
+		dev_dbg(port->dev, "need to release resource of dma\n");
+	else
+		dev_dbg(port->dev, "%s: mapped %d@%p to %x\n", __func__,
+			sg_dma_len(&atmel_port->sg_rx),
+			ring->buf,
+			sg_dma_address(&atmel_port->sg_rx));
+
+	/* Configure the slave DMA */
+	memset(&config, 0, sizeof(config));
+	config.direction = DMA_DEV_TO_MEM;
+	config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	config.src_addr = port->mapbase + ATMEL_US_RHR;
+
+	ret = dmaengine_device_control(atmel_port->chan_rx,
+					DMA_SLAVE_CONFIG,
+					(unsigned long)&config);
+	if (ret) {
+		dev_err(port->dev, "DMA rx slave configuration failed\n");
+		goto chan_err;
+	}
+
+	return;
+
+chan_err:
+	dev_err(port->dev, "RX channel not available, switch to pio\n");
+	atmel_port->use_dma_rx = 0;
+	if (atmel_port->chan_rx)
+		atmel_rx_dma_release(atmel_port);
+	return;
+}
+
+static int atmel_allocate_desc(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct dma_async_tx_descriptor *desc;
+	struct dma_chan *chan = atmel_port->chan_rx;
+
+	if (!chan) {
+		dev_warn(port->dev, "No channel available\n");
+		goto err_dma;
+	}
+	/*
+	 * Prepare a cyclic dma transfer, assign 2 descriptors,
+	 * each one is half ring buffer size
+	 */
+	desc = dmaengine_prep_dma_cyclic(chan,
+				sg_dma_address(&atmel_port->sg_rx),
+				sg_dma_len(&atmel_port->sg_rx),
+				sg_dma_len(&atmel_port->sg_rx)/2,
+				DMA_DEV_TO_MEM,
+				DMA_PREP_INTERRUPT);
+	desc->callback = atmel_dma_rx_complete;
+	desc->callback_param = port;
+	atmel_port->desc_rx = desc;
+	atmel_port->cookie_rx = dmaengine_submit(desc);
+
+	return 0;
+
+err_dma:
+	atmel_rx_dma_release(atmel_port);
+	return -EINVAL;
+}
+
 /*
  * receive interrupt handler.
  */
@@ -784,6 +995,13 @@ atmel_handle_receive(struct uart_port *port, unsigned int pending)
 			atmel_pdc_rxerr(port, pending);
 	}
 
+	if (atmel_use_dma_rx(port)) {
+		if (pending & ATMEL_US_TIMEOUT) {
+			UART_PUT_IDR(port, ATMEL_US_TIMEOUT);
+			tasklet_schedule(&atmel_port->tasklet);
+		}
+	}
+
 	/* Interrupt receive */
 	if (pending & ATMEL_US_RXRDY)
 		atmel_rx_chars(port);
@@ -1090,6 +1308,8 @@ static void atmel_tasklet_func(unsigned long data)
 
 	if (atmel_use_pdc_rx(port))
 		atmel_rx_from_pdc(port);
+	else if (atmel_use_dma_rx(port))
+		atmel_rx_from_dma(port);
 	else
 		atmel_rx_from_ring(port);
 
@@ -1173,6 +1393,11 @@ static int atmel_startup(struct uart_port *port)
 	}
 
 	atmel_tx_request_dma(atmel_port);
+	atmel_rx_request_dma(atmel_port);
+	if (atmel_use_dma_rx(port)) {
+		if (atmel_allocate_desc(port))
+			return -EINVAL;
+	}
 
 	/*
 	 * If there is a specific "open" function (to register
@@ -1205,6 +1430,12 @@ static int atmel_startup(struct uart_port *port)
 		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
 		/* enable PDC controller */
 		UART_PUT_PTCR(port, ATMEL_PDC_RXTEN);
+	} else if (atmel_use_dma_rx(port)) {
+		/* set UART timeout */
+		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
+		UART_PUT_CR(port, ATMEL_US_STTTO);
+
+		UART_PUT_IER(port, ATMEL_US_TIMEOUT);
 	} else {
 		/* enable receive only */
 		UART_PUT_IER(port, ATMEL_US_RXRDY);
@@ -1252,6 +1483,10 @@ static void atmel_shutdown(struct uart_port *port)
 
 	if (atmel_use_dma_tx(port))
 		atmel_tx_dma_release(atmel_port);
+
+	if (atmel_use_dma_rx(port))
+		atmel_rx_dma_release(atmel_port);
+
 	/*
 	 * Disable all interrupts, port and break condition.
 	 */
@@ -1668,6 +1903,7 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 	} else {
 		atmel_port->use_pdc_rx	= pdata->use_pdc_rx;
 		atmel_port->use_pdc_tx	= pdata->use_pdc_tx;
+		atmel_port->use_dma_rx	= 0;
 		atmel_port->use_dma_tx	= 0;
 		atmel_port->rs485	= pdata->rs485;
 	}
diff --git a/include/linux/platform_data/atmel.h b/include/linux/platform_data/atmel.h
index 6f5a7c6..167a6fa 100644
--- a/include/linux/platform_data/atmel.h
+++ b/include/linux/platform_data/atmel.h
@@ -79,6 +79,7 @@ struct atmel_uart_data {
 	short			use_pdc_tx;	/* use transmit PDC? */
 	short			use_pdc_rx;	/* use receive PDC? */
 	short			use_dma_tx;	/* use transmit DMA? */
+	short			use_dma_rx;	/* use receive DMA? */
 	void __iomem		*regs;		/* virt. base address, if any */
 	struct serial_rs485	rs485;		/* rs485 settings */
 };
-- 
1.7.9.5



From elen.song at atmel.com  Tue Jul  9 02:33:43 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 9 Jul 2013 14:33:43 +0800
Subject: [PATCH 4/7] serial: at91: make DBGU support dma and pdc transfers
In-Reply-To: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373351626-30143-5-git-send-email-elen.song@atmel.com>

Because the DBGU lack of receive timeout register, so we use a timer to trigger
data receive.

Signed-off-by: Elen Song <elen.song at atmel.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |   51 ++++++++++++++++++++++++++++++-------
 1 file changed, 42 insertions(+), 9 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index a425ff2..52beb7e 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -41,6 +41,7 @@
 #include <linux/uaccess.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/platform_data/atmel.h>
+#include <linux/timer.h>
 
 #include <asm/io.h>
 #include <asm/ioctls.h>
@@ -167,6 +168,7 @@ struct atmel_uart_port {
 
 	struct serial_rs485	rs485;		/* rs485 settings */
 	unsigned int		tx_done_mask;
+	struct timer_list 	uart_timer;	/* dbgu timer */
 };
 
 static struct atmel_uart_port atmel_ports[ATMEL_MAX_UART];
@@ -968,6 +970,15 @@ err_dma:
 	return -EINVAL;
 }
 
+static void atmel_uart_timer_callback(unsigned long data)
+{
+	struct uart_port *port = (void *)data;
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+	tasklet_schedule(&atmel_port->tasklet);
+	mod_timer(&atmel_port->uart_timer, jiffies + uart_poll_timeout(port));
+}
+
 /*
  * receive interrupt handler.
  */
@@ -1424,18 +1435,34 @@ static int atmel_startup(struct uart_port *port)
 
 	if (atmel_use_pdc_rx(port)) {
 		/* set UART timeout */
-		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
-		UART_PUT_CR(port, ATMEL_US_STTTO);
-
-		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
+		if (port->line == 0) {
+			setup_timer(&atmel_port->uart_timer,
+				    atmel_uart_timer_callback,
+				    (unsigned long)port);
+			mod_timer(&atmel_port->uart_timer,
+				  jiffies + uart_poll_timeout(port));
+		} else {
+			UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
+			UART_PUT_CR(port, ATMEL_US_STTTO);
+
+			UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
+		}
 		/* enable PDC controller */
 		UART_PUT_PTCR(port, ATMEL_PDC_RXTEN);
 	} else if (atmel_use_dma_rx(port)) {
 		/* set UART timeout */
-		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
-		UART_PUT_CR(port, ATMEL_US_STTTO);
-
-		UART_PUT_IER(port, ATMEL_US_TIMEOUT);
+		if (port->line == 0) {
+			setup_timer(&atmel_port->uart_timer,
+				    atmel_uart_timer_callback,
+				    (unsigned long)port);
+			mod_timer(&atmel_port->uart_timer,
+				  jiffies + uart_poll_timeout(port));
+		} else {
+			UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
+			UART_PUT_CR(port, ATMEL_US_STTTO);
+
+			UART_PUT_IER(port, ATMEL_US_TIMEOUT);
+		}
 	} else {
 		/* enable receive only */
 		UART_PUT_IER(port, ATMEL_US_RXRDY);
@@ -1471,6 +1498,9 @@ static void atmel_shutdown(struct uart_port *port)
 					 DMA_FROM_DEVICE);
 			kfree(pdc->buf);
 		}
+
+		if (port->line == 0)
+			del_timer_sync(&atmel_port->uart_timer);
 	}
 	if (atmel_use_pdc_tx(port)) {
 		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
@@ -1484,8 +1514,11 @@ static void atmel_shutdown(struct uart_port *port)
 	if (atmel_use_dma_tx(port))
 		atmel_tx_dma_release(atmel_port);
 
-	if (atmel_use_dma_rx(port))
+	if (atmel_use_dma_rx(port)) {
 		atmel_rx_dma_release(atmel_port);
+		if (port->line == 0)
+			del_timer_sync(&atmel_port->uart_timer);
+	}
 
 	/*
 	 * Disable all interrupts, port and break condition.
-- 
1.7.9.5



From elen.song at atmel.com  Tue Jul  9 02:33:44 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 9 Jul 2013 14:33:44 +0800
Subject: [PATCH 5/7] serial: at91: distinguish usart and uart
In-Reply-To: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373351626-30143-6-git-send-email-elen.song@atmel.com>

Distinguish usart and uart by read ip name register,
dbgu regards as uart.

Signed-off-by: Elen Song <elen.song at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |   35 +++++++++++++++++++++++++++++++++++
 include/linux/atmel_serial.h      |    2 ++
 2 files changed, 37 insertions(+)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 52beb7e..5762244 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -99,6 +99,7 @@ static void atmel_stop_rx(struct uart_port *port);
 #define UART_PUT_BRGR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_BRGR)
 #define UART_PUT_RTOR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_RTOR)
 #define UART_PUT_TTGR(port, v)	__raw_writel(v, (port)->membase + ATMEL_US_TTGR)
+#define UART_GET_IP_NAME(port)	__raw_readl((port)->membase + ATMEL_US_NAME)
 
  /* PDC registers */
 #define UART_PUT_PTCR(port,v)	__raw_writel(v, (port)->membase + ATMEL_PDC_PTCR)
@@ -169,6 +170,7 @@ struct atmel_uart_port {
 	struct serial_rs485	rs485;		/* rs485 settings */
 	unsigned int		tx_done_mask;
 	struct timer_list 	uart_timer;	/* dbgu timer */
+	bool			is_usart;	/* usart or uart */
 };
 
 static struct atmel_uart_port atmel_ports[ATMEL_MAX_UART];
@@ -1328,6 +1330,34 @@ static void atmel_tasklet_func(unsigned long data)
 }
 
 /*
+ * Get ip name usart or uart
+ */
+static inline unsigned int atmel_get_ip_name(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	unsigned int name = cpu_to_be32(UART_GET_IP_NAME(port));
+	char *ip_name = (char *)&name;
+	char *usart = "USAR";
+	char *uart = "DBGU";
+
+	atmel_port->is_usart = false;
+
+	/* USAR is regards as usart, DBGU is regards as uart */
+	if (!strncmp(ip_name, usart, 4)) {
+		dev_dbg(port->dev, "This is usart\n");
+		atmel_port->is_usart = true;
+	} else if (!strncmp(ip_name, uart, 4)) {
+		dev_dbg(port->dev, "This is uart\n");
+		atmel_port->is_usart = false;
+	} else {
+		dev_err(port->dev, "Not supported ip name, set to uart\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/*
  * Perform initialization and enable port for reception
  */
 static int atmel_startup(struct uart_port *port)
@@ -1354,6 +1384,11 @@ static int atmel_startup(struct uart_port *port)
 	}
 
 	/*
+	 * Get port name of usart or uart
+	 */
+	atmel_get_ip_name(port);
+
+	/*
 	 * Initialize DMA (if necessary)
 	 */
 	if (atmel_use_pdc_rx(port)) {
diff --git a/include/linux/atmel_serial.h b/include/linux/atmel_serial.h
index fd68337..be201ca 100644
--- a/include/linux/atmel_serial.h
+++ b/include/linux/atmel_serial.h
@@ -124,4 +124,6 @@
 #define ATMEL_US_NER		0x44			/* Number of Errors Register */
 #define ATMEL_US_IF		0x4c			/* IrDA Filter Register */
 
+#define ATMEL_US_NAME		0xf0			/* Ip Name */
+
 #endif
-- 
1.7.9.5



From sachin.kamat at linaro.org  Tue Jul  9 02:41:17 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Tue, 9 Jul 2013 12:11:17 +0530
Subject: [PATCH v2 3/3] of/documentation: Update G2D documentation
In-Reply-To: <1373350364-2952-1-git-send-email-sachin.kamat@linaro.org>
References: <1373350364-2952-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <CAK9yfHw-Ry0NTKhrbVApz6-7r4R1jhnh34+fFHmA3FPgvdyTWQ@mail.gmail.com>

On 9 July 2013 11:42, Sachin Kamat <sachin.kamat at linaro.org> wrote:
> Exynos5250 G2D IP requires only the gate clock. Update the
> binding documentation accordingly.
>
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> Cc: Inki Dae <inki.dae at samsung.com>
> ---
> Updated the description of clock-names as suggested by Tomasz Figa.
> ---
>  .../devicetree/bindings/gpu/samsung-g2d.txt        |    7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
> index 3f454ff..c4f358d 100644
> --- a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
> +++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
> @@ -11,8 +11,11 @@ Required properties:
>
>    - interrupts : G2D interrupt number to the CPU.
>    - clocks : from common clock binding: handle to G2D clocks.
> -  - clock-names : from common clock binding: must contain "sclk_fimg2d" and
> -                 "fimg2d", corresponding to entries in the clocks property.
> +  - clock-names : names of clocks listed in clocks property, in the same
> +                 order, depending on SoC type:
> +                 - for S5PV210 and Exynos4 based SoCs: "fimg2d" and
> +                   "sclk_fimg2d"
> +                 - for Exynos5250 SoC: "fimg2d".
>
>  Example:
>         g2d at 12800000 {
> --
> 1.7.9.5
>

Please ignore this patch. Will re-send. Sorry for the noise.

-- 
With warm regards,
Sachin


From elen.song at atmel.com  Tue Jul  9 02:33:45 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 9 Jul 2013 14:33:45 +0800
Subject: [PATCH 6/7] serial: at91: modify UART to use software timer to
 trigger rx
In-Reply-To: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373351626-30143-7-git-send-email-elen.song@atmel.com>

Signed-off-by: Elen Song <elen.song at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 5762244..5beddad 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1470,7 +1470,7 @@ static int atmel_startup(struct uart_port *port)
 
 	if (atmel_use_pdc_rx(port)) {
 		/* set UART timeout */
-		if (port->line == 0) {
+		if (!atmel_port->is_usart) {
 			setup_timer(&atmel_port->uart_timer,
 				    atmel_uart_timer_callback,
 				    (unsigned long)port);
@@ -1486,7 +1486,7 @@ static int atmel_startup(struct uart_port *port)
 		UART_PUT_PTCR(port, ATMEL_PDC_RXTEN);
 	} else if (atmel_use_dma_rx(port)) {
 		/* set UART timeout */
-		if (port->line == 0) {
+		if (!atmel_port->is_usart) {
 			setup_timer(&atmel_port->uart_timer,
 				    atmel_uart_timer_callback,
 				    (unsigned long)port);
@@ -1534,7 +1534,7 @@ static void atmel_shutdown(struct uart_port *port)
 			kfree(pdc->buf);
 		}
 
-		if (port->line == 0)
+		if (!atmel_port->is_usart)
 			del_timer_sync(&atmel_port->uart_timer);
 	}
 	if (atmel_use_pdc_tx(port)) {
@@ -1551,7 +1551,7 @@ static void atmel_shutdown(struct uart_port *port)
 
 	if (atmel_use_dma_rx(port)) {
 		atmel_rx_dma_release(atmel_port);
-		if (port->line == 0)
+		if (!atmel_port->is_usart)
 			del_timer_sync(&atmel_port->uart_timer);
 	}
 
-- 
1.7.9.5



From balbi at ti.com  Tue Jul  9 02:42:12 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 9 Jul 2013 09:42:12 +0300
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51DBA0C2.6030003@ti.com>
References: <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <51DBA0C2.6030003@ti.com>
Message-ID: <20130709064212.GB5552@arwen.pp.htv.fi>

Hi,

On Tue, Jul 09, 2013 at 11:03:54AM +0530, Rajendra Nayak wrote:
> On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
> >>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
> >>>>>>>> of -1 for the serial driver?
> >>>>>>>>
> >>>>>>>
> >>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> >>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> >>>>>
> >>>>> OK
> >>>>
> >>>> Issue 2: Causing boot to stop when serial driver is initialized.
> >>>> (After Issue 1 is fixed)
> >>>>
> >>>> I could narrow this down to the change done to return -EINVAL
> >>>> instead of 0 in serial_omap_get_context_loss_count() as part of
> >>>> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
> >>>> Fix device tree based PM runtime"
> >>>>
> >>>> What this change in turn seems to do is cause a
> >>>> serial_omap_restore_context() to get called as part of
> >>>> serial_omap_runtime_resume() which was not the case when
> >>>> serial_omap_get_context_loss_count() returned 0
> >>>>
> >>>> from serial_omap_runtime_resume():
> >>>> -----
> >>>>         int loss_cnt = serial_omap_get_context_loss_count(up);
> >>>>
> >>>>         if (loss_cnt < 0) {
> >>>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
> >>>>                         loss_cnt);
> >>>>                 serial_omap_restore_context(up);
> >>>>         } else if (up->context_loss_cnt != loss_cnt) {
> >>>>                 serial_omap_restore_context(up);
> >>>>         }
> >>>> -----
> >>>>
> >>>> I am still working on why a serial_omap_restore_context() could
> >>>> have caused console to die. I will work with Sourav on this and
> >>>> post the fixes for both issue 1 and issue2 once its clear on whats
> >>>> really causing issue 2.
> >>>
> >>> That's because we don't have the omap specific pdata callbacks for
> >>> context loss any longer. We may be able to detect when the context
> >>> was really lost in the serial driver, and only then call the
> >>> serial_omap_restore_context().
> >>
> >> Right, but calling serial_omap_restore_context() even when the context
> >> is not lost, should not ideally cause an issue.
> > 
> > it does in one condition. If context hasn't been saved before. And that
> > can happen in the case of wrong pm runtime status for that device.
> > 
> > Imagine the device is marked as suspended even though it's fully enabled
> > (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> > your context structure is all zeroes (context has never been saved
> > before) then when you call pm_runtime_get_sync() on probe() your
> > ->runtime_resume() will get called, which will restore context,
> > essentially undoing anything which was configured by u-boot.
> 
> This could be a problem for drivers which do a save context in ->runtime_suspend()
> but from what I see with omap serial, there is no save context done as part of
> ->runtime_suspend.

right, because context is "saved" in set_termios. probe() will get
called much before set_termios() has a chance to run, right ?

Same problem will trigger in that case.

I still think patch below is necessary

> > (completely untested, didn't even try to compile, just to illustrate)
> > 
> > diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> > index 7341eff..d8dca68 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod.c
> > @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
> >  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
> >  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
> >  		postsetup_state = _HWMOD_STATE_ENABLED;
> > +
> > +		/* tell pm_runtime this device is already active */
> > +		pm_runtime_set_active(&oh->od->pdev->dev);
> > +	} else {
> > +		/* tell pm_runtime this device is trully suspended */
> > +		pm_runtime_set_suspended(&oh->od->pdev->dev);
> >  	}
> >  
> >  	if (postsetup_state == _HWMOD_STATE_IDLE)

-- 
balbi
-------------- 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/20130709/1fb8a557/attachment.sig>

From zhangwm at marvell.com  Tue Jul  9 02:42:43 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Tue, 9 Jul 2013 14:42:43 +0800
Subject: [PATCH V3 0/3] bring up pxa988 with DT
Message-ID: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>

This patch is supposed to bring up pxa988 SMP.

ChangeLog
V3:
1. change all Marvell prefix to 'marvell'
2. Support CLOCKSOURCE for mmp timer
3. Modify the bring up patch according to Arnd's comments.

V2:
1. use early_init call for handler init.
2. Add sanity check for maximum core count.

Neil Zhang (3):
  dts: change Marvell prefix to 'marvell'
  clocksource: mmp: support CLOCKSOURCE OF DECLARE
  ARM: mmp: bring up pxa988 with device tree support

 .../devicetree/bindings/arm/mrvl/intc.txt          |   16 +-
 .../devicetree/bindings/arm/mrvl/mrvl.txt          |    6 +-
 .../devicetree/bindings/arm/mrvl/timer.txt         |    4 +-
 Documentation/devicetree/bindings/i2c/i2c-pxa.txt  |   14 +-
 .../devicetree/bindings/mmc/sdhci-pxa.txt          |    8 +-
 .../devicetree/bindings/rtc/sa1100-rtc.txt         |    4 +-
 .../devicetree/bindings/serial/mrvl-serial.txt     |    2 +-
 arch/arm/boot/dts/mmp2-brownstone.dts              |    2 +-
 arch/arm/boot/dts/mmp2.dtsi                        |   56 +++---
 arch/arm/boot/dts/pxa168-aspenite.dts              |    2 +-
 arch/arm/boot/dts/pxa168.dtsi                      |   24 ++--
 arch/arm/boot/dts/pxa2xx.dtsi                      |   16 +-
 arch/arm/boot/dts/pxa3xx.dtsi                      |    2 +-
 arch/arm/boot/dts/pxa910-dkb.dts                   |    2 +-
 arch/arm/boot/dts/pxa910.dtsi                      |   27 ++--
 .../dts/{pxa168-aspenite.dts => pxa988-dkb.dts}    |   12 +-
 arch/arm/boot/dts/pxa988.dtsi                      |  190 ++++++++++++++++++++
 arch/arm/mach-mmp/Kconfig                          |   18 ++
 arch/arm/mach-mmp/Makefile                         |    1 +
 arch/arm/mach-mmp/common.c                         |   11 +-
 arch/arm/mach-mmp/common.h                         |    2 +
 arch/arm/mach-mmp/headsmp.S                        |  104 +++++++++++
 arch/arm/mach-mmp/include/mach/addr-map.h          |    6 +
 arch/arm/mach-mmp/irq.c                            |   16 +-
 arch/arm/mach-mmp/mmp-dt.c                         |   33 ++--
 arch/arm/mach-mmp/mmp2-dt.c                        |   60 +++++-
 arch/arm/mach-mmp/platsmp.c                        |  167 +++++++++++++++++
 arch/arm/mach-mmp/reset.c                          |   66 +++++++
 arch/arm/mach-mmp/reset.h                          |   29 +++
 arch/arm/mach-mmp/time.c                           |   15 +--
 arch/arm/mach-pxa/pxa-dt.c                         |   14 +-
 drivers/clk/mmp/Makefile                           |    1 +
 drivers/i2c/busses/i2c-pxa.c                       |   10 +-
 drivers/mmc/host/sdhci-pxav2.c                     |    4 +-
 drivers/mmc/host/sdhci-pxav3.c                     |    4 +-
 drivers/rtc/rtc-sa1100.c                           |    4 +-
 drivers/tty/serial/pxa.c                           |    4 +-
 37 files changed, 788 insertions(+), 168 deletions(-)
 copy arch/arm/boot/dts/{pxa168-aspenite.dts => pxa988-dkb.dts} (74%)
 create mode 100644 arch/arm/boot/dts/pxa988.dtsi
 create mode 100644 arch/arm/mach-mmp/headsmp.S
 create mode 100644 arch/arm/mach-mmp/platsmp.c
 create mode 100644 arch/arm/mach-mmp/reset.c
 create mode 100644 arch/arm/mach-mmp/reset.h

-- 
1.7.4.1



From elen.song at atmel.com  Tue Jul  9 02:33:46 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 9 Jul 2013 14:33:46 +0800
Subject: [PATCH 7/7] serial: at91: add dma support in usart binding
 descriptions
In-Reply-To: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373351626-30143-8-git-send-email-elen.song@atmel.com>

Signed-off-by: Elen Song <elen.song at atmel.com>
---
 .../devicetree/bindings/tty/serial/atmel-usart.txt |   21 +++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
index 82f45ec..fb50023 100644
--- a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
@@ -8,15 +8,21 @@ Required properties:
 - interrupts: Should contain interrupt
 
 Optional properties:
-- atmel,use-pdc-rx: use of PDC for receiving data
-- atmel,use-pdc-tx: use of PDC for transmitting data
+- for those only support PDC transfer socs:
+	- atmel,use-pdc-rx: use of PDC for receiving data
+	- atmel,use-pdc-tx: use of PDC for transmitting data
+- for those only support DMA transfer socs:
+	- dmas: DMA specifier, consisting of a phandle to DMA controller node,
+	  memory peripheral interface and USART DMA channel ID, FIFO configuration.
+	  Refer to dma.txt and atmel-dma.txt for details.
+	- dma-names: "rx" for RX channel, "tx" for TX channel.
 
 <chip> compatible description:
 - at91rm9200:  legacy USART support
 - at91sam9260: generic USART implementation for SAM9 SoCs
 
 Example:
-
+- use PDC:
 	usart0: serial at fff8c000 {
 		compatible = "atmel,at91sam9260-usart";
 		reg = <0xfff8c000 0x200>;
@@ -25,3 +31,12 @@ Example:
 		atmel,use-pdc-tx;
 	};
 
+- use DMA:
+	usart0: serial at f001c000 {
+		compatible = "atmel,at91sam9260-usart";
+		reg = <0xf001c000 0x100>;
+		interrupts = <12 IRQ_TYPE_LEVEL_HIGH 5>;
+		dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(3)>,
+		       <&dma0 2 (AT91_DMA_CFG_PER_ID(4) | AT91_DMA_CFG_FIFOCFG_ASAP)>;
+		dma-names = "tx", "rx";
+	};
-- 
1.7.9.5



From zhangwm at marvell.com  Tue Jul  9 02:42:45 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Tue, 9 Jul 2013 14:42:45 +0800
Subject: [PATCH V3 2/3] clocksource: mmp: support CLOCKSOURCE OF DECLARE
In-Reply-To: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
Message-ID: <1373352166-10064-3-git-send-email-zhangwm@marvell.com>

support CLOCKSOURCE OF DECLARE for mmp timer.

Signed-off-by: Neil Zhang <zhangwm at marvell.com>
---
 arch/arm/mach-mmp/mmp-dt.c  |    5 ++---
 arch/arm/mach-mmp/mmp2-dt.c |    3 +--
 arch/arm/mach-mmp/time.c    |   15 ++-------------
 3 files changed, 5 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-mmp/mmp-dt.c b/arch/arm/mach-mmp/mmp-dt.c
index 62c5adb..87ab5ff 100644
--- a/arch/arm/mach-mmp/mmp-dt.c
+++ b/arch/arm/mach-mmp/mmp-dt.c
@@ -20,7 +20,6 @@
 #include "common.h"
 
 extern void __init mmp_dt_irq_init(void);
-extern void __init mmp_dt_init_timer(void);
 
 static const struct of_dev_auxdata pxa168_auxdata_lookup[] __initconst = {
 	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
@@ -65,7 +64,7 @@ static const char *mmp_dt_board_compat[] __initdata = {
 DT_MACHINE_START(PXA168_DT, "Marvell PXA168 (Device Tree Support)")
 	.map_io		= mmp_map_io,
 	.init_irq	= mmp_dt_irq_init,
-	.init_time	= mmp_dt_init_timer,
+	.init_time	= clocksource_of_init,
 	.init_machine	= pxa168_dt_init,
 	.dt_compat	= mmp_dt_board_compat,
 MACHINE_END
@@ -73,7 +72,7 @@ MACHINE_END
 DT_MACHINE_START(PXA910_DT, "Marvell PXA910 (Device Tree Support)")
 	.map_io		= mmp_map_io,
 	.init_irq	= mmp_dt_irq_init,
-	.init_time	= mmp_dt_init_timer,
+	.init_time	= clocksource_of_init,
 	.init_machine	= pxa910_dt_init,
 	.dt_compat	= mmp_dt_board_compat,
 MACHINE_END
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index 6523ecf..0ce46f1 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -22,7 +22,6 @@
 #include "common.h"
 
 extern void __init mmp_dt_irq_init(void);
-extern void __init mmp_dt_init_timer(void);
 
 static const struct of_dev_auxdata mmp2_auxdata_lookup[] __initconst = {
 	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4030000, "pxa2xx-uart.0", NULL),
@@ -50,7 +49,7 @@ static const char *mmp2_dt_board_compat[] __initdata = {
 DT_MACHINE_START(MMP2_DT, "Marvell MMP2 (Device Tree Support)")
 	.map_io		= mmp_map_io,
 	.init_irq	= mmp_dt_irq_init,
-	.init_time	= mmp_dt_init_timer,
+	.init_time	= clocksource_of_init,
 	.init_machine	= mmp2_dt_init,
 	.dt_compat	= mmp2_dt_board_compat,
 MACHINE_END
diff --git a/arch/arm/mach-mmp/time.c b/arch/arm/mach-mmp/time.c
index 67e7d5c..8f5d612 100644
--- a/arch/arm/mach-mmp/time.c
+++ b/arch/arm/mach-mmp/time.c
@@ -207,22 +207,10 @@ void __init timer_init(int irq)
 }
 
 #ifdef CONFIG_OF
-static struct of_device_id mmp_timer_dt_ids[] = {
-	{ .compatible = "marvell,mmp-timer", },
-	{}
-};
-
-void __init mmp_dt_init_timer(void)
+static void __init mmp_of_init_timer(struct device_node *np)
 {
-	struct device_node *np;
 	int irq, ret;
 
-	np = of_find_matching_node(NULL, mmp_timer_dt_ids);
-	if (!np) {
-		ret = -ENODEV;
-		goto out;
-	}
-
 	irq = irq_of_parse_and_map(np, 0);
 	if (!irq) {
 		ret = -EINVAL;
@@ -238,4 +226,5 @@ void __init mmp_dt_init_timer(void)
 out:
 	pr_err("Failed to get timer from device tree with error:%d\n", ret);
 }
+CLOCKSOURCE_OF_DECLARE(mmp_timer, "marvell,mmp-timer", mmp_of_init_timer);
 #endif
-- 
1.7.4.1



From zhangwm at marvell.com  Tue Jul  9 02:42:44 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Tue, 9 Jul 2013 14:42:44 +0800
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
Message-ID: <1373352166-10064-2-git-send-email-zhangwm@marvell.com>

The documented vendor prefix for Marvell is 'marvell', not 'mrvl', so
let's change it.

Signed-off-by: Neil Zhang <zhangwm at marvell.com>
---
 .../devicetree/bindings/arm/mrvl/intc.txt          |   16 +++---
 .../devicetree/bindings/arm/mrvl/mrvl.txt          |    6 +-
 .../devicetree/bindings/arm/mrvl/timer.txt         |    4 +-
 Documentation/devicetree/bindings/i2c/i2c-pxa.txt  |   14 +++---
 .../devicetree/bindings/mmc/sdhci-pxa.txt          |    8 ++--
 .../devicetree/bindings/rtc/sa1100-rtc.txt         |    4 +-
 .../devicetree/bindings/serial/mrvl-serial.txt     |    2 +-
 arch/arm/boot/dts/mmp2-brownstone.dts              |    2 +-
 arch/arm/boot/dts/mmp2.dtsi                        |   56 ++++++++++----------
 arch/arm/boot/dts/pxa168-aspenite.dts              |    2 +-
 arch/arm/boot/dts/pxa168.dtsi                      |   24 ++++----
 arch/arm/boot/dts/pxa2xx.dtsi                      |   16 +++---
 arch/arm/boot/dts/pxa3xx.dtsi                      |    2 +-
 arch/arm/boot/dts/pxa910-dkb.dts                   |    2 +-
 arch/arm/boot/dts/pxa910.dtsi                      |   27 +++++-----
 arch/arm/mach-mmp/irq.c                            |   16 +++---
 arch/arm/mach-mmp/mmp-dt.c                         |   28 +++++-----
 arch/arm/mach-mmp/mmp2-dt.c                        |   16 +++---
 arch/arm/mach-mmp/time.c                           |    2 +-
 arch/arm/mach-pxa/pxa-dt.c                         |   14 +++---
 drivers/i2c/busses/i2c-pxa.c                       |   10 ++--
 drivers/mmc/host/sdhci-pxav2.c                     |    4 +-
 drivers/mmc/host/sdhci-pxav3.c                     |    4 +-
 drivers/rtc/rtc-sa1100.c                           |    4 +-
 drivers/tty/serial/pxa.c                           |    4 +-
 25 files changed, 144 insertions(+), 143 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 8b53273..ad27548 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -1,8 +1,8 @@
 * Marvell MMP Interrupt controller
 
 Required properties:
-- compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or
-  "mrvl,mmp2-mux-intc"
+- compatible : Should be "marvell,mmp-intc", "marvell,mmp2-intc" or
+  "marvell,mmp2-mux-intc"
 - reg : Address and length of the register set of the interrupt controller.
   If the interrupt controller is intc, address and length means the range
   of the whold interrupt controller. If the interrupt controller is mux-intc,
@@ -15,28 +15,28 @@ Required properties:
 - interrupt-controller : Identifies the node as an interrupt controller.
 - #interrupt-cells : Specifies the number of cells needed to encode an
   interrupt source.
-- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
+- marvell,intc-nr-irqs : Specifies the number of interrupts in the interrupt
   controller.
-- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
+- marvell,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
   detection first.
 
 Example:
 	intc: interrupt-controller at d4282000 {
-		compatible = "mrvl,mmp2-intc";
+		compatible = "marvell,mmp2-intc";
 		interrupt-controller;
 		#interrupt-cells = <1>;
 		reg = <0xd4282000 0x1000>;
-		mrvl,intc-nr-irqs = <64>;
+		marvell,intc-nr-irqs = <64>;
 	};
 
 	intcmux4 at d4282150 {
-		compatible = "mrvl,mmp2-mux-intc";
+		compatible = "marvell,mmp2-mux-intc";
 		interrupts = <4>;
 		interrupt-controller;
 		#interrupt-cells = <1>;
 		reg = <0x150 0x4>, <0x168 0x4>;
 		reg-names = "mux status", "mux mask";
-		mrvl,intc-nr-irqs = <2>;
+		marvell,intc-nr-irqs = <2>;
 	};
 
 * Marvell Orion Interrupt controller
diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
index 117d741..87f1d42 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
@@ -3,12 +3,12 @@ Marvell Platforms Device Tree Bindings
 
 PXA168 Aspenite Board
 Required root node properties:
-	- compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
+	- compatible = "marvell,pxa168-aspenite", "marvell,pxa168";
 
 PXA910 DKB Board
 Required root node properties:
-	- compatible = "mrvl,pxa910-dkb";
+	- compatible = "marvell,pxa910-dkb";
 
 MMP2 Brownstone Board
 Required root node properties:
-	- compatible = "mrvl,mmp2-brownstone";
+	- compatible = "marvell,mmp2-brownstone";
diff --git a/Documentation/devicetree/bindings/arm/mrvl/timer.txt b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
index 9a6e251..1304526 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/timer.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
@@ -1,13 +1,13 @@
 * Marvell MMP Timer controller
 
 Required properties:
-- compatible : Should be "mrvl,mmp-timer".
+- compatible : Should be "marvell,mmp-timer".
 - reg : Address and length of the register set of timer controller.
 - interrupts : Should be the interrupt number.
 
 Example:
 	timer0: timer at d4014000 {
-		compatible = "mrvl,mmp-timer";
+		compatible = "marvell,mmp-timer";
 		reg = <0xd4014000 0x100>;
 		interrupts = <13>;
 	};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..34fdf5d 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -3,9 +3,9 @@
 Required properties :
 
  - reg : Offset and length of the register set for the device
- - compatible : should be "mrvl,mmp-twsi" where mmp is the name of a
+ - compatible : should be "marvell,mmp-twsi" where mmp is the name of a
    compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
-   For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
+   For the pxa2xx/pxa3xx, an additional node "marvell,pxa-i2c" is required
    as shown in the example below.
 
 Recommended properties :
@@ -14,20 +14,20 @@ Recommended properties :
  - interrupt-parent : the phandle for the interrupt controller that
    services interrupts for this device. If the parent is the default
    interrupt controller in device tree, it could be ignored.
- - mrvl,i2c-polling : Disable interrupt of i2c controller. Polling
+ - marvell,i2c-polling : Disable interrupt of i2c controller. Polling
    status register of i2c controller instead.
- - mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
+ - marvell,i2c-fast-mode : Enable fast mode of i2c controller.
 
 Examples:
 	twsi1: i2c at d4011000 {
-		compatible = "mrvl,mmp-twsi";
+		compatible = "marvell,mmp-twsi";
 		reg = <0xd4011000 0x1000>;
 		interrupts = <7>;
-		mrvl,i2c-fast-mode;
+		marvell,i2c-fast-mode;
 	};
 	
 	twsi2: i2c at d4025000 {
-		compatible = "mrvl,mmp-twsi";
+		compatible = "marvell,mmp-twsi";
 		reg = <0xd4025000 0x1000>;
 		interrupts = <58>;
 	};
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
index dbe98a3..d603a3e 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
@@ -4,18 +4,18 @@ This file documents differences between the core properties in mmc.txt
 and the properties used by the sdhci-pxav2 and sdhci-pxav3 drivers.
 
 Required properties:
-- compatible: Should be "mrvl,pxav2-mmc" or "mrvl,pxav3-mmc".
+- compatible: Should be "marvell,pxav2-mmc" or "marvell,pxav3-mmc".
 
 Optional properties:
-- mrvl,clk-delay-cycles: Specify a number of cycles to delay for tuning.
+- marvell,clk-delay-cycles: Specify a number of cycles to delay for tuning.
 
 Example:
 
 sdhci at d4280800 {
-	compatible = "mrvl,pxav3-mmc";
+	compatible = "marvell,pxav3-mmc";
 	reg = <0xd4280800 0x800>;
 	bus-width = <8>;
 	interrupts = <27>;
 	non-removable;
-	mrvl,clk-delay-cycles = <31>;
+	marvell,clk-delay-cycles = <31>;
 };
diff --git a/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt b/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
index 0cda19a..886fe15 100644
--- a/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
@@ -1,7 +1,7 @@
 * Marvell Real Time Clock controller
 
 Required properties:
-- compatible: should be "mrvl,sa1100-rtc"
+- compatible: should be "marvell,sa1100-rtc"
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: Should be two. The first interrupt number is the rtc alarm
@@ -10,7 +10,7 @@ Required properties:
 
 Example:
 	rtc: rtc at d4010000 {
-		compatible = "mrvl,mmp-rtc";
+		compatible = "marvell,mmp-rtc";
 		reg = <0xd4010000 0x1000>;
 		interrupts = <5>, <6>;
 		interrupt-name = "rtc 1Hz", "rtc alarm";
diff --git a/Documentation/devicetree/bindings/serial/mrvl-serial.txt b/Documentation/devicetree/bindings/serial/mrvl-serial.txt
index d744340..659d35e 100644
--- a/Documentation/devicetree/bindings/serial/mrvl-serial.txt
+++ b/Documentation/devicetree/bindings/serial/mrvl-serial.txt
@@ -1,4 +1,4 @@
 PXA UART controller
 
 Required properties:
-- compatible : should be "mrvl,mmp-uart" or "mrvl,pxa-uart".
+- compatible : should be "marvell,mmp-uart" or "marvell,pxa-uart".
diff --git a/arch/arm/boot/dts/mmp2-brownstone.dts b/arch/arm/boot/dts/mmp2-brownstone.dts
index 7f70a39..26abfde 100644
--- a/arch/arm/boot/dts/mmp2-brownstone.dts
+++ b/arch/arm/boot/dts/mmp2-brownstone.dts
@@ -12,7 +12,7 @@
 
 / {
 	model = "Marvell MMP2 Brownstone Development Board";
-	compatible = "mrvl,mmp2-brownstone", "mrvl,mmp2";
+	compatible = "marvell,mmp2-brownstone", "marvell,mmp2";
 
 	chosen {
 		bootargs = "console=ttyS2,38400 root=/dev/nfs nfsroot=192.168.1.100:/nfsroot/ ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 4e8b08c..ac13654 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -32,128 +32,128 @@
 		};
 
 		axi at d4200000 {	/* AXI */
-			compatible = "mrvl,axi-bus", "simple-bus";
+			compatible = "marvell,axi-bus", "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
 			reg = <0xd4200000 0x00200000>;
 			ranges;
 
 			intc: interrupt-controller at d4282000 {
-				compatible = "mrvl,mmp2-intc";
+				compatible = "marvell,mmp2-intc";
 				interrupt-controller;
 				#interrupt-cells = <1>;
 				reg = <0xd4282000 0x1000>;
-				mrvl,intc-nr-irqs = <64>;
+				marvell,intc-nr-irqs = <64>;
 			};
 
 			intcmux4: interrupt-controller at d4282150 {
-				compatible = "mrvl,mmp2-mux-intc";
+				compatible = "marvell,mmp2-mux-intc";
 				interrupts = <4>;
 				interrupt-controller;
 				#interrupt-cells = <1>;
 				reg = <0x150 0x4>, <0x168 0x4>;
 				reg-names = "mux status", "mux mask";
-				mrvl,intc-nr-irqs = <2>;
+				marvell,intc-nr-irqs = <2>;
 			};
 
 			intcmux5: interrupt-controller at d4282154 {
-				compatible = "mrvl,mmp2-mux-intc";
+				compatible = "marvell,mmp2-mux-intc";
 				interrupts = <5>;
 				interrupt-controller;
 				#interrupt-cells = <1>;
 				reg = <0x154 0x4>, <0x16c 0x4>;
 				reg-names = "mux status", "mux mask";
-				mrvl,intc-nr-irqs = <2>;
-				mrvl,clr-mfp-irq = <1>;
+				marvell,intc-nr-irqs = <2>;
+				marvell,clr-mfp-irq = <1>;
 			};
 
 			intcmux9: interrupt-controller at d4282180 {
-				compatible = "mrvl,mmp2-mux-intc";
+				compatible = "marvell,mmp2-mux-intc";
 				interrupts = <9>;
 				interrupt-controller;
 				#interrupt-cells = <1>;
 				reg = <0x180 0x4>, <0x17c 0x4>;
 				reg-names = "mux status", "mux mask";
-				mrvl,intc-nr-irqs = <3>;
+				marvell,intc-nr-irqs = <3>;
 			};
 
 			intcmux17: interrupt-controller at d4282158 {
-				compatible = "mrvl,mmp2-mux-intc";
+				compatible = "marvell,mmp2-mux-intc";
 				interrupts = <17>;
 				interrupt-controller;
 				#interrupt-cells = <1>;
 				reg = <0x158 0x4>, <0x170 0x4>;
 				reg-names = "mux status", "mux mask";
-				mrvl,intc-nr-irqs = <5>;
+				marvell,intc-nr-irqs = <5>;
 			};
 
 			intcmux35: interrupt-controller at d428215c {
-				compatible = "mrvl,mmp2-mux-intc";
+				compatible = "marvell,mmp2-mux-intc";
 				interrupts = <35>;
 				interrupt-controller;
 				#interrupt-cells = <1>;
 				reg = <0x15c 0x4>, <0x174 0x4>;
 				reg-names = "mux status", "mux mask";
-				mrvl,intc-nr-irqs = <15>;
+				marvell,intc-nr-irqs = <15>;
 			};
 
 			intcmux51: interrupt-controller at d4282160 {
-				compatible = "mrvl,mmp2-mux-intc";
+				compatible = "marvell,mmp2-mux-intc";
 				interrupts = <51>;
 				interrupt-controller;
 				#interrupt-cells = <1>;
 				reg = <0x160 0x4>, <0x178 0x4>;
 				reg-names = "mux status", "mux mask";
-				mrvl,intc-nr-irqs = <2>;
+				marvell,intc-nr-irqs = <2>;
 			};
 
 			intcmux55: interrupt-controller at d4282188 {
-				compatible = "mrvl,mmp2-mux-intc";
+				compatible = "marvell,mmp2-mux-intc";
 				interrupts = <55>;
 				interrupt-controller;
 				#interrupt-cells = <1>;
 				reg = <0x188 0x4>, <0x184 0x4>;
 				reg-names = "mux status", "mux mask";
-				mrvl,intc-nr-irqs = <2>;
+				marvell,intc-nr-irqs = <2>;
 			};
 		};
 
 		apb at d4000000 {	/* APB */
-			compatible = "mrvl,apb-bus", "simple-bus";
+			compatible = "marvell,apb-bus", "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
 			reg = <0xd4000000 0x00200000>;
 			ranges;
 
 			timer0: timer at d4014000 {
-				compatible = "mrvl,mmp-timer";
+				compatible = "marvell,mmp-timer";
 				reg = <0xd4014000 0x100>;
 				interrupts = <13>;
 			};
 
 			uart1: uart at d4030000 {
-				compatible = "mrvl,mmp-uart";
+				compatible = "marvell,mmp-uart";
 				reg = <0xd4030000 0x1000>;
 				interrupts = <27>;
 				status = "disabled";
 			};
 
 			uart2: uart at d4017000 {
-				compatible = "mrvl,mmp-uart";
+				compatible = "marvell,mmp-uart";
 				reg = <0xd4017000 0x1000>;
 				interrupts = <28>;
 				status = "disabled";
 			};
 
 			uart3: uart at d4018000 {
-				compatible = "mrvl,mmp-uart";
+				compatible = "marvell,mmp-uart";
 				reg = <0xd4018000 0x1000>;
 				interrupts = <24>;
 				status = "disabled";
 			};
 
 			uart4: uart at d4016000 {
-				compatible = "mrvl,mmp-uart";
+				compatible = "marvell,mmp-uart";
 				reg = <0xd4016000 0x1000>;
 				interrupts = <46>;
 				status = "disabled";
@@ -198,24 +198,24 @@
 			};
 
 			twsi1: i2c at d4011000 {
-				compatible = "mrvl,mmp-twsi";
+				compatible = "marvell,mmp-twsi";
 				reg = <0xd4011000 0x1000>;
 				interrupts = <7>;
 				#address-cells = <1>;
 				#size-cells = <0>;
-				mrvl,i2c-fast-mode;
+				marvell,i2c-fast-mode;
 				status = "disabled";
 			};
 
 			twsi2: i2c at d4025000 {
-				compatible = "mrvl,mmp-twsi";
+				compatible = "marvell,mmp-twsi";
 				reg = <0xd4025000 0x1000>;
 				interrupts = <58>;
 				status = "disabled";
 			};
 
 			rtc: rtc at d4010000 {
-				compatible = "mrvl,mmp-rtc";
+				compatible = "marvell,mmp-rtc";
 				reg = <0xd4010000 0x1000>;
 				interrupts = <1 0>;
 				interrupt-names = "rtc 1Hz", "rtc alarm";
diff --git a/arch/arm/boot/dts/pxa168-aspenite.dts b/arch/arm/boot/dts/pxa168-aspenite.dts
index e762fac..1e2ac17 100644
--- a/arch/arm/boot/dts/pxa168-aspenite.dts
+++ b/arch/arm/boot/dts/pxa168-aspenite.dts
@@ -12,7 +12,7 @@
 
 / {
 	model = "Marvell PXA168 Aspenite Development Board";
-	compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
+	compatible = "marvell,pxa168-aspenite", "marvell,pxa168";
 
 	chosen {
 		bootargs = "console=ttyS0,115200 root=/dev/nfs nfsroot=192.168.1.100:/nfsroot/ ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
diff --git a/arch/arm/boot/dts/pxa168.dtsi b/arch/arm/boot/dts/pxa168.dtsi
index 975dad2..c08f5fc 100644
--- a/arch/arm/boot/dts/pxa168.dtsi
+++ b/arch/arm/boot/dts/pxa168.dtsi
@@ -26,51 +26,51 @@
 		ranges;
 
 		axi at d4200000 {	/* AXI */
-			compatible = "mrvl,axi-bus", "simple-bus";
+			compatible = "marvell,axi-bus", "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
 			reg = <0xd4200000 0x00200000>;
 			ranges;
 
 			intc: interrupt-controller at d4282000 {
-				compatible = "mrvl,mmp-intc";
+				compatible = "marvell,mmp-intc";
 				interrupt-controller;
 				#interrupt-cells = <1>;
 				reg = <0xd4282000 0x1000>;
-				mrvl,intc-nr-irqs = <64>;
+				marvell,intc-nr-irqs = <64>;
 			};
 
 		};
 
 		apb at d4000000 {	/* APB */
-			compatible = "mrvl,apb-bus", "simple-bus";
+			compatible = "marvell,apb-bus", "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
 			reg = <0xd4000000 0x00200000>;
 			ranges;
 
 			timer0: timer at d4014000 {
-				compatible = "mrvl,mmp-timer";
+				compatible = "marvell,mmp-timer";
 				reg = <0xd4014000 0x100>;
 				interrupts = <13>;
 			};
 
 			uart1: uart at d4017000 {
-				compatible = "mrvl,mmp-uart";
+				compatible = "marvell,mmp-uart";
 				reg = <0xd4017000 0x1000>;
 				interrupts = <27>;
 				status = "disabled";
 			};
 
 			uart2: uart at d4018000 {
-				compatible = "mrvl,mmp-uart";
+				compatible = "marvell,mmp-uart";
 				reg = <0xd4018000 0x1000>;
 				interrupts = <28>;
 				status = "disabled";
 			};
 
 			uart3: uart at d4026000 {
-				compatible = "mrvl,mmp-uart";
+				compatible = "marvell,mmp-uart";
 				reg = <0xd4026000 0x1000>;
 				interrupts = <29>;
 				status = "disabled";
@@ -107,22 +107,22 @@
 			};
 
 			twsi1: i2c at d4011000 {
-				compatible = "mrvl,mmp-twsi";
+				compatible = "marvell,mmp-twsi";
 				reg = <0xd4011000 0x1000>;
 				interrupts = <7>;
-				mrvl,i2c-fast-mode;
+				marvell,i2c-fast-mode;
 				status = "disabled";
 			};
 
 			twsi2: i2c at d4025000 {
-				compatible = "mrvl,mmp-twsi";
+				compatible = "marvell,mmp-twsi";
 				reg = <0xd4025000 0x1000>;
 				interrupts = <58>;
 				status = "disabled";
 			};
 
 			rtc: rtc at d4010000 {
-				compatible = "mrvl,mmp-rtc";
+				compatible = "marvell,mmp-rtc";
 				reg = <0xd4010000 0x1000>;
 				interrupts = <5 6>;
 				interrupt-names = "rtc 1Hz", "rtc alarm";
diff --git a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx.dtsi
index a5e90f0..c426b1e 100644
--- a/arch/arm/boot/dts/pxa2xx.dtsi
+++ b/arch/arm/boot/dts/pxa2xx.dtsi
@@ -47,7 +47,7 @@
 		};
 
 		gpio: gpio at 40e00000 {
-			compatible = "mrvl,pxa-gpio";
+			compatible = "marvell,pxa-gpio";
 			#address-cells = <0x1>;
 			#size-cells = <0x1>;
 			reg = <0x40e00000 0x10000>;
@@ -76,35 +76,35 @@
 		};
 
 		ffuart: uart at 40100000 {
-			compatible = "mrvl,pxa-uart";
+			compatible = "marvell,pxa-uart";
 			reg = <0x40100000 0x30>;
 			interrupts = <22>;
 			status = "disabled";
 		};
 
 		btuart: uart at 40200000 {
-			compatible = "mrvl,pxa-uart";
+			compatible = "marvell,pxa-uart";
 			reg = <0x40200000 0x30>;
 			interrupts = <21>;
 			status = "disabled";
 		};
 
 		stuart: uart at 40700000 {
-			compatible = "mrvl,pxa-uart";
+			compatible = "marvell,pxa-uart";
 			reg = <0x40700000 0x30>;
 			interrupts = <20>;
 			status = "disabled";
 		};
 
 		hwuart: uart at 41100000 {
-			compatible = "mrvl,pxa-uart";
+			compatible = "marvell,pxa-uart";
 			reg = <0x41100000 0x30>;
 			interrupts = <7>;
 			status = "disabled";
 		};
 
 		pxai2c1: i2c at 40301680 {
-			compatible = "mrvl,pxa-i2c";
+			compatible = "marvell,pxa-i2c";
 			reg = <0x40301680 0x30>;
 			interrupts = <18>;
 			#address-cells = <0x1>;
@@ -113,14 +113,14 @@
 		};
 
 		usb0: ohci at 4c000000 {
-			compatible = "mrvl,pxa-ohci";
+			compatible = "marvell,pxa-ohci";
 			reg = <0x4c000000 0x10000>;
 			interrupts = <3>;
 			status = "disabled";
 		};
 
 		mmc0: mmc at 41100000 {
-			compatible = "mrvl,pxa-mmc";
+			compatible = "marvell,pxa-mmc";
 			reg = <0x41100000 0x1000>;
 			interrupts = <23>;
 			status = "disabled";
diff --git a/arch/arm/boot/dts/pxa3xx.dtsi b/arch/arm/boot/dts/pxa3xx.dtsi
index f9d92da..0798031 100644
--- a/arch/arm/boot/dts/pxa3xx.dtsi
+++ b/arch/arm/boot/dts/pxa3xx.dtsi
@@ -7,7 +7,7 @@
 
 	pxabus {
 		pwri2c: i2c at 40f500c0 {
-			compatible = "mrvl,pwri2c";
+			compatible = "marvell,pwri2c";
 			reg = <0x40f500c0 0x30>;
 			interrupts = <6>;
 			#address-cells = <0x1>;
diff --git a/arch/arm/boot/dts/pxa910-dkb.dts b/arch/arm/boot/dts/pxa910-dkb.dts
index 595492a..7384254 100644
--- a/arch/arm/boot/dts/pxa910-dkb.dts
+++ b/arch/arm/boot/dts/pxa910-dkb.dts
@@ -12,7 +12,7 @@
 
 / {
 	model = "Marvell PXA910 DKB Development Board";
-	compatible = "mrvl,pxa910-dkb", "mrvl,pxa910";
+	compatible = "marvell,pxa910-dkb", "marvell,pxa910";
 
 	chosen {
 		bootargs = "console=ttyS0,115200 root=/dev/nfs nfsroot=192.168.1.100:/nfsroot/ ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
diff --git a/arch/arm/boot/dts/pxa910.dtsi b/arch/arm/boot/dts/pxa910.dtsi
index 0247c62..b5594a0 100644
--- a/arch/arm/boot/dts/pxa910.dtsi
+++ b/arch/arm/boot/dts/pxa910.dtsi
@@ -31,58 +31,59 @@
 		};
 
 		axi at d4200000 {	/* AXI */
-			compatible = "mrvl,axi-bus", "simple-bus";
+			compatible = "marvell,axi-bus", "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
 			reg = <0xd4200000 0x00200000>;
 			ranges;
 
 			intc: interrupt-controller at d4282000 {
-				compatible = "mrvl,mmp-intc";
+				compatible = "marvell,mmp-intc";
 				interrupt-controller;
 				#interrupt-cells = <1>;
 				reg = <0xd4282000 0x1000>;
-				mrvl,intc-nr-irqs = <64>;
+				marvell,intc-nr-irqs = <64>;
+
 			};
 
 		};
 
 		apb at d4000000 {	/* APB */
-			compatible = "mrvl,apb-bus", "simple-bus";
+			compatible = "marvell,apb-bus", "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
 			reg = <0xd4000000 0x00200000>;
 			ranges;
 
 			timer0: timer at d4014000 {
-				compatible = "mrvl,mmp-timer";
+				compatible = "marvell,mmp-timer";
 				reg = <0xd4014000 0x100>;
 				interrupts = <13>;
 			};
 
 			timer1: timer at d4016000 {
-				compatible = "mrvl,mmp-timer";
+				compatible = "marvell,mmp-timer";
 				reg = <0xd4016000 0x100>;
 				interrupts = <29>;
 				status = "disabled";
 			};
 
 			uart1: uart at d4017000 {
-				compatible = "mrvl,mmp-uart";
+				compatible = "marvell,mmp-uart";
 				reg = <0xd4017000 0x1000>;
 				interrupts = <27>;
 				status = "disabled";
 			};
 
 			uart2: uart at d4018000 {
-				compatible = "mrvl,mmp-uart";
+				compatible = "marvell,mmp-uart";
 				reg = <0xd4018000 0x1000>;
 				interrupts = <28>;
 				status = "disabled";
 			};
 
 			uart3: uart at d4036000 {
-				compatible = "mrvl,mmp-uart";
+				compatible = "marvell,mmp-uart";
 				reg = <0xd4036000 0x1000>;
 				interrupts = <59>;
 				status = "disabled";
@@ -119,17 +120,17 @@
 			};
 
 			twsi1: i2c at d4011000 {
-				compatible = "mrvl,mmp-twsi";
+				compatible = "marvell,mmp-twsi";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				reg = <0xd4011000 0x1000>;
 				interrupts = <7>;
-				mrvl,i2c-fast-mode;
+				marvell,i2c-fast-mode;
 				status = "disabled";
 			};
 
 			twsi2: i2c at d4037000 {
-				compatible = "mrvl,mmp-twsi";
+				compatible = "marvell,mmp-twsi";
 				#address-cells = <1>;
 				#size-cells = <0>;
 				reg = <0xd4037000 0x1000>;
@@ -138,7 +139,7 @@
 			};
 
 			rtc: rtc at d4010000 {
-				compatible = "mrvl,mmp-rtc";
+				compatible = "marvell,mmp-rtc";
 				reg = <0xd4010000 0x1000>;
 				interrupts = <5 6>;
 				interrupt-names = "rtc 1Hz", "rtc alarm";
diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c
index 3c71246..a7a53611 100644
--- a/arch/arm/mach-mmp/irq.c
+++ b/arch/arm/mach-mmp/irq.c
@@ -327,13 +327,13 @@ void __init mmp2_init_icu(void)
 
 #ifdef CONFIG_OF
 static const struct of_device_id intc_ids[] __initconst = {
-	{ .compatible = "mrvl,mmp-intc", .data = &mmp_conf },
-	{ .compatible = "mrvl,mmp2-intc", .data = &mmp2_conf },
+	{ .compatible = "marvell,mmp-intc", .data = &mmp_conf },
+	{ .compatible = "marvell,mmp2-intc", .data = &mmp2_conf },
 	{}
 };
 
 static const struct of_device_id mmp_mux_irq_match[] __initconst = {
-	{ .compatible = "mrvl,mmp2-mux-intc" },
+	{ .compatible = "marvell,mmp2-mux-intc" },
 	{}
 };
 
@@ -352,10 +352,10 @@ int __init mmp2_mux_init(struct device_node *parent)
 		if (!node)
 			break;
 		of_id = of_match_node(&mmp_mux_irq_match[0], node);
-		ret = of_property_read_u32(node, "mrvl,intc-nr-irqs",
+		ret = of_property_read_u32(node, "marvell,intc-nr-irqs",
 					   &nr_irqs);
 		if (ret) {
-			pr_err("Not found mrvl,intc-nr-irqs property\n");
+			pr_err("Not found marvell,intc-nr-irqs property\n");
 			ret = -EINVAL;
 			goto err;
 		}
@@ -385,7 +385,7 @@ int __init mmp2_mux_init(struct device_node *parent)
 			ret = irq_base;
 			goto err;
 		}
-		if (!of_property_read_u32(node, "mrvl,clr-mfp-irq",
+		if (!of_property_read_u32(node, "marvell,clr-mfp-irq",
 					  &mfp_irq)) {
 			icu_data[i].clr_mfp_irq_base = irq_base;
 			icu_data[i].clr_mfp_hwirq = mfp_irq;
@@ -424,9 +424,9 @@ void __init mmp_dt_irq_init(void)
 	of_id = of_match_node(intc_ids, node);
 	conf = of_id->data;
 
-	ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", &nr_irqs);
+	ret = of_property_read_u32(node, "marvell,intc-nr-irqs", &nr_irqs);
 	if (ret) {
-		pr_err("Not found mrvl,intc-nr-irqs property\n");
+		pr_err("Not found marvell,intc-nr-irqs property\n");
 		return;
 	}
 
diff --git a/arch/arm/mach-mmp/mmp-dt.c b/arch/arm/mach-mmp/mmp-dt.c
index b37915d..62c5adb 100644
--- a/arch/arm/mach-mmp/mmp-dt.c
+++ b/arch/arm/mach-mmp/mmp-dt.c
@@ -23,24 +23,24 @@ extern void __init mmp_dt_irq_init(void);
 extern void __init mmp_dt_init_timer(void);
 
 static const struct of_dev_auxdata pxa168_auxdata_lookup[] __initconst = {
-	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4026000, "pxa2xx-uart.2", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4026000, "pxa2xx-uart.2", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1", NULL),
 	OF_DEV_AUXDATA("marvell,mmp-gpio", 0xd4019000, "mmp-gpio", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
 	{}
 };
 
 static const struct of_dev_auxdata pxa910_auxdata_lookup[] __initconst = {
-	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4036000, "pxa2xx-uart.2", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4037000, "pxa2xx-i2c.1", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4036000, "pxa2xx-uart.2", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4037000, "pxa2xx-i2c.1", NULL),
 	OF_DEV_AUXDATA("marvell,mmp-gpio", 0xd4019000, "mmp-gpio", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
 	{}
 };
 
@@ -57,8 +57,8 @@ static void __init pxa910_dt_init(void)
 }
 
 static const char *mmp_dt_board_compat[] __initdata = {
-	"mrvl,pxa168-aspenite",
-	"mrvl,pxa910-dkb",
+	"marvell,pxa168-aspenite",
+	"marvell,pxa910-dkb",
 	NULL,
 };
 
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index 4ac2567..6523ecf 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -25,14 +25,14 @@ extern void __init mmp_dt_irq_init(void);
 extern void __init mmp_dt_init_timer(void);
 
 static const struct of_dev_auxdata mmp2_auxdata_lookup[] __initconst = {
-	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4030000, "pxa2xx-uart.0", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.1", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.2", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4016000, "pxa2xx-uart.3", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4030000, "pxa2xx-uart.0", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4017000, "pxa2xx-uart.1", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4018000, "pxa2xx-uart.2", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4016000, "pxa2xx-uart.3", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1", NULL),
 	OF_DEV_AUXDATA("marvell,mmp-gpio", 0xd4019000, "mmp2-gpio", NULL),
-	OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
 	{}
 };
 
@@ -43,7 +43,7 @@ static void __init mmp2_dt_init(void)
 }
 
 static const char *mmp2_dt_board_compat[] __initdata = {
-	"mrvl,mmp2-brownstone",
+	"marvell,mmp2-brownstone",
 	NULL,
 };
 
diff --git a/arch/arm/mach-mmp/time.c b/arch/arm/mach-mmp/time.c
index 7ac41e8..67e7d5c 100644
--- a/arch/arm/mach-mmp/time.c
+++ b/arch/arm/mach-mmp/time.c
@@ -208,7 +208,7 @@ void __init timer_init(int irq)
 
 #ifdef CONFIG_OF
 static struct of_device_id mmp_timer_dt_ids[] = {
-	{ .compatible = "mrvl,mmp-timer", },
+	{ .compatible = "marvell,mmp-timer", },
 	{}
 };
 
diff --git a/arch/arm/mach-pxa/pxa-dt.c b/arch/arm/mach-pxa/pxa-dt.c
index 3835979..b679367 100644
--- a/arch/arm/mach-pxa/pxa-dt.c
+++ b/arch/arm/mach-pxa/pxa-dt.c
@@ -23,15 +23,15 @@
 extern void __init pxa3xx_dt_init_irq(void);
 
 static const struct of_dev_auxdata pxa3xx_auxdata_lookup[] __initconst = {
-	OF_DEV_AUXDATA("mrvl,pxa-uart",		0x40100000, "pxa2xx-uart.0", NULL),
-	OF_DEV_AUXDATA("mrvl,pxa-uart",		0x40200000, "pxa2xx-uart.1", NULL),
-	OF_DEV_AUXDATA("mrvl,pxa-uart",		0x40700000, "pxa2xx-uart.2", NULL),
-	OF_DEV_AUXDATA("mrvl,pxa-uart",		0x41600000, "pxa2xx-uart.3", NULL),
+	OF_DEV_AUXDATA("marvell,pxa-uart",	0x40100000, "pxa2xx-uart.0", NULL),
+	OF_DEV_AUXDATA("marvell,pxa-uart",	0x40200000, "pxa2xx-uart.1", NULL),
+	OF_DEV_AUXDATA("marvell,pxa-uart",	0x40700000, "pxa2xx-uart.2", NULL),
+	OF_DEV_AUXDATA("marvell,pxa-uart",	0x41600000, "pxa2xx-uart.3", NULL),
 	OF_DEV_AUXDATA("marvell,pxa-mmc",	0x41100000, "pxa2xx-mci.0", NULL),
-	OF_DEV_AUXDATA("mrvl,pxa-gpio",		0x40e00000, "pxa-gpio", NULL),
+	OF_DEV_AUXDATA("marvell,pxa-gpio",	0x40e00000, "pxa-gpio", NULL),
 	OF_DEV_AUXDATA("marvell,pxa-ohci",	0x4c000000, "pxa27x-ohci", NULL),
-	OF_DEV_AUXDATA("mrvl,pxa-i2c",		0x40301680, "pxa2xx-i2c.0", NULL),
-	OF_DEV_AUXDATA("mrvl,pwri2c",		0x40f500c0, "pxa3xx-i2c.1", NULL),
+	OF_DEV_AUXDATA("marvell,pxa-i2c",	0x40301680, "pxa2xx-i2c.0", NULL),
+	OF_DEV_AUXDATA("marvell,pwri2c",	0x40f500c0, "pxa3xx-i2c.1", NULL),
 	OF_DEV_AUXDATA("marvell,pxa3xx-nand",	0x43100000, "pxa3xx-nand", NULL),
 	{}
 };
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index fbafed2..6f2b17d 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1040,9 +1040,9 @@ static const struct i2c_algorithm i2c_pxa_pio_algorithm = {
 };
 
 static struct of_device_id i2c_pxa_dt_ids[] = {
-	{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
-	{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
-	{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA2XX },
+	{ .compatible = "marvell,pxa-i2c", .data = (void *)REGS_PXA2XX },
+	{ .compatible = "marvell,pwri2c", .data = (void *)REGS_PXA3XX },
+	{ .compatible = "marvell,mmp-twsi", .data = (void *)REGS_PXA2XX },
 	{}
 };
 MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
@@ -1060,9 +1060,9 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
 	/* For device tree we always use the dynamic or alias-assigned ID */
 	i2c->adap.nr = -1;
 
-	if (of_get_property(np, "mrvl,i2c-polling", NULL))
+	if (of_get_property(np, "marvell,i2c-polling", NULL))
 		i2c->use_pio = 1;
-	if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
+	if (of_get_property(np, "marvell,i2c-fast-mode", NULL))
 		i2c->fast_mode = 1;
 	*i2c_types = (u32)(of_id->data);
 	return 0;
diff --git a/drivers/mmc/host/sdhci-pxav2.c b/drivers/mmc/host/sdhci-pxav2.c
index 6a3f702..1dd6500 100644
--- a/drivers/mmc/host/sdhci-pxav2.c
+++ b/drivers/mmc/host/sdhci-pxav2.c
@@ -120,7 +120,7 @@ static const struct sdhci_ops pxav2_sdhci_ops = {
 #ifdef CONFIG_OF
 static const struct of_device_id sdhci_pxav2_of_match[] = {
 	{
-		.compatible = "mrvl,pxav2-mmc",
+		.compatible = "marvell,pxav2-mmc",
 	},
 	{},
 };
@@ -144,7 +144,7 @@ static struct sdhci_pxa_platdata *pxav2_get_mmc_pdata(struct device *dev)
 	if (bus_width == 8)
 		pdata->flags |= PXA_FLAG_SD_8_BIT_CAPABLE_SLOT;
 
-	of_property_read_u32(np, "mrvl,clk-delay-cycles", &clk_delay_cycles);
+	of_property_read_u32(np, "marvell,clk-delay-cycles", &clk_delay_cycles);
 	if (clk_delay_cycles > 0) {
 		pdata->clk_delay_sel = 1;
 		pdata->clk_delay_cycles = clk_delay_cycles;
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 1ae358e..a88974b 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -185,7 +185,7 @@ static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
 #ifdef CONFIG_OF
 static const struct of_device_id sdhci_pxav3_of_match[] = {
 	{
-		.compatible = "mrvl,pxav3-mmc",
+		.compatible = "marvell,pxav3-mmc",
 	},
 	{},
 };
@@ -201,7 +201,7 @@ static struct sdhci_pxa_platdata *pxav3_get_mmc_pdata(struct device *dev)
 	if (!pdata)
 		return NULL;
 
-	of_property_read_u32(np, "mrvl,clk-delay-cycles", &clk_delay_cycles);
+	of_property_read_u32(np, "marvell,clk-delay-cycles", &clk_delay_cycles);
 	if (clk_delay_cycles > 0)
 		pdata->clk_delay_cycles = clk_delay_cycles;
 
diff --git a/drivers/rtc/rtc-sa1100.c b/drivers/rtc/rtc-sa1100.c
index 0f7adeb..307dd37 100644
--- a/drivers/rtc/rtc-sa1100.c
+++ b/drivers/rtc/rtc-sa1100.c
@@ -339,8 +339,8 @@ static SIMPLE_DEV_PM_OPS(sa1100_rtc_pm_ops, sa1100_rtc_suspend,
 
 #ifdef CONFIG_OF
 static struct of_device_id sa1100_rtc_dt_ids[] = {
-	{ .compatible = "mrvl,sa1100-rtc", },
-	{ .compatible = "mrvl,mmp-rtc", },
+	{ .compatible = "marvell,sa1100-rtc", },
+	{ .compatible = "marvell,mmp-rtc", },
 	{}
 };
 MODULE_DEVICE_TABLE(of, sa1100_rtc_dt_ids);
diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
index 05f504e..cb1a439 100644
--- a/drivers/tty/serial/pxa.c
+++ b/drivers/tty/serial/pxa.c
@@ -852,8 +852,8 @@ static const struct dev_pm_ops serial_pxa_pm_ops = {
 #endif
 
 static struct of_device_id serial_pxa_dt_ids[] = {
-	{ .compatible = "mrvl,pxa-uart", },
-	{ .compatible = "mrvl,mmp-uart", },
+	{ .compatible = "marvell,pxa-uart", },
+	{ .compatible = "marvell,mmp-uart", },
 	{}
 };
 MODULE_DEVICE_TABLE(of, serial_pxa_dt_ids);
-- 
1.7.4.1



From sachin.kamat at linaro.org  Tue Jul  9 02:29:15 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Tue,  9 Jul 2013 11:59:15 +0530
Subject: [PATCH v2 Resend 2/3] of/documentation: Update G2D documentation
Message-ID: <1373351355-27444-1-git-send-email-sachin.kamat@linaro.org>

Exynos5250 G2D IP requires only the gate clock. Update the
binding documentation accordingly.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
Cc: Inki Dae <inki.dae at samsung.com>
---
Updated the description of clock-names as suggested by Tomasz Figa.
---
 .../devicetree/bindings/gpu/samsung-g2d.txt        |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
index 3f454ff..c4f358d 100644
--- a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
+++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
@@ -11,8 +11,11 @@ Required properties:
 
   - interrupts : G2D interrupt number to the CPU.
   - clocks : from common clock binding: handle to G2D clocks.
-  - clock-names : from common clock binding: must contain "sclk_fimg2d" and
-		  "fimg2d", corresponding to entries in the clocks property.
+  - clock-names : names of clocks listed in clocks property, in the same
+		  order, depending on SoC type:
+		  - for S5PV210 and Exynos4 based SoCs: "fimg2d" and
+		    "sclk_fimg2d"
+		  - for Exynos5250 SoC: "fimg2d".
 
 Example:
 	g2d at 12800000 {
-- 
1.7.9.5



From zhangwm at marvell.com  Tue Jul  9 02:42:46 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Tue, 9 Jul 2013 14:42:46 +0800
Subject: [PATCH V3 3/3] ARM: mmp: bring up pxa988 with device tree support
In-Reply-To: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
Message-ID: <1373352166-10064-4-git-send-email-zhangwm@marvell.com>

bring up pxa988 with device tree support.

Signed-off-by: Neil Zhang <zhangwm at marvell.com>
Signed-off-by: Chao Xie <chao.xie at marvell.com>
---
 arch/arm/boot/dts/pxa988-dkb.dts          |   36 ++++++
 arch/arm/boot/dts/pxa988.dtsi             |  190 +++++++++++++++++++++++++++++
 arch/arm/mach-mmp/Kconfig                 |   18 +++
 arch/arm/mach-mmp/Makefile                |    1 +
 arch/arm/mach-mmp/common.c                |   11 ++-
 arch/arm/mach-mmp/common.h                |    2 +
 arch/arm/mach-mmp/headsmp.S               |  104 ++++++++++++++++
 arch/arm/mach-mmp/include/mach/addr-map.h |    6 +
 arch/arm/mach-mmp/mmp2-dt.c               |   41 ++++++
 arch/arm/mach-mmp/platsmp.c               |  167 +++++++++++++++++++++++++
 arch/arm/mach-mmp/reset.c                 |   66 ++++++++++
 arch/arm/mach-mmp/reset.h                 |   29 +++++
 drivers/clk/mmp/Makefile                  |    1 +
 13 files changed, 671 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/boot/dts/pxa988-dkb.dts
 create mode 100644 arch/arm/boot/dts/pxa988.dtsi
 create mode 100644 arch/arm/mach-mmp/headsmp.S
 create mode 100644 arch/arm/mach-mmp/platsmp.c
 create mode 100644 arch/arm/mach-mmp/reset.c
 create mode 100644 arch/arm/mach-mmp/reset.h

diff --git a/arch/arm/boot/dts/pxa988-dkb.dts b/arch/arm/boot/dts/pxa988-dkb.dts
new file mode 100644
index 0000000..891c78a
--- /dev/null
+++ b/arch/arm/boot/dts/pxa988-dkb.dts
@@ -0,0 +1,36 @@
+/*
+ *  Copyright (C) 2012 Marvell Technology Group Ltd.
+ *  Author: Haojian Zhuang <haojian.zhuang at marvell.com>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  publishhed by the Free Software Foundation.
+ */
+
+/dts-v1/;
+/include/ "pxa988.dtsi"
+
+/ {
+	model = "Marvell PXA988 DKB Development Board";
+	compatible = "marvell,pxa988-dkb", "marvell,pxa988";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 root=/dev/nfs nfsroot=192.168.1.100:/nfsroot/ ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
+	};
+
+	memory {
+		reg = <0x00000000 0x10000000>;
+	};
+
+	soc {
+		apb at d4000000 {
+			uart1: uart at d4017000 {
+				status = "okay";
+			};
+
+			rtc: rtc at d4010000 {
+				status = "okay";
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/pxa988.dtsi b/arch/arm/boot/dts/pxa988.dtsi
new file mode 100644
index 0000000..f69bf77
--- /dev/null
+++ b/arch/arm/boot/dts/pxa988.dtsi
@@ -0,0 +1,190 @@
+/*
+ *  Copyright (C) 2013 Marvell Technology Group Ltd.
+ *  Author: Chao Xie <chao.xie at marvell.com>
+ *	    Neil Zhang <zhangwm at marvell.com>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  publishhed by the Free Software Foundation.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	interrupt-parent = <&gic>;
+
+	aliases {
+		serial0 = &uart1;
+		serial1 = &uart2;
+		serial2 = &uart3;
+		i2c0 = &twsi1;
+		i2c1 = &twsi2;
+	};
+
+	cpus {
+		cpu at 0 {
+			compatible = "arm,cortex-a9";
+			next-level-cache = <&L2>;
+		};
+		cpu at 1 {
+			compatible = "arm,cortex-a9";
+			next-level-cache = <&L2>;
+		};
+	};
+
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		interrupt-parent = <&gic>;
+		ranges;
+
+		gic: interrupt-controller at d1dfe100 {
+			compatible = "arm,cortex-a9-gic";
+			#interrupt-cells = <3>;
+			#address-cells = <1>;
+			interrupt-controller;
+			reg = <0xd1dff000 0x1000>,
+			      <0xd1dfe100 0x0100>;
+		};
+
+		L2: l2-cache-controller at d1dfb000 {
+			compatible = "arm,pl310-cache";
+			reg = <0xd1dfb000 0x1000>;
+			arm,data-latency = <2 1 1>;
+			arm,tag-latency = <2 1 1>;
+			arm,pwr-dynamic-clk-gating;
+			arm,pwr-standby-mode;
+			cache-unified;
+			cache-level = <2>;
+		};
+
+		local-timer at d1dfe600 {
+			compatible = "arm,cortex-a9-twd-timer";
+			reg = <0xd1dfe600 0x20>;
+			interrupts = <1 13 0x304>;
+		};
+
+		axi at d4200000 {	/* AXI */
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0xd4200000 0xd4200000 0x00200000>;
+
+			intc: wakeupgen at d4282000 {
+				compatible = "marvell,mmp-intc";
+				reg = <0xd4282000 0x1000>;
+				marvell,intc-wakeup = <0x114 0x3
+						    0x144 0x3>;
+			};
+
+		};
+
+		apb at d4000000 {	/* APB */
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0xd4000000 0xd4000000 0x00200000>;
+
+			timer0: timer at d4014000 {
+				compatible = "marvell,mmp-timer";
+				reg = <0xd4014000 0x100>;
+				interrupts = <0 13 0x4>;
+			};
+
+			uart1: uart at d4017000 {
+				compatible = "marvell,mmp-uart";
+				reg = <0xd4017000 0x1000>;
+				interrupts = <0 27 0x4>;
+				status = "disabled";
+			};
+
+			uart2: uart at d4018000 {
+				compatible = "marvell,mmp-uart";
+				reg = <0xd4018000 0x1000>;
+				interrupts = <0 28 0x4>;
+				status = "disabled";
+			};
+
+			uart3: uart at d4036000 {
+				compatible = "marvell,mmp-uart";
+				reg = <0xd4036000 0x1000>;
+				interrupts = <0 59 0x4>;
+				status = "disabled";
+			};
+
+			gpio at d4019000 {
+				compatible = "marvell,mmp-gpio";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				reg = <0xd4019000 0x1000>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupts = <49>;
+				interrupt-names = "gpio_mux";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+				ranges;
+
+				gcb0: gpio at d4019000 {
+					reg = <0xd4019000 0x4>;
+				};
+
+				gcb1: gpio at d4019004 {
+					reg = <0xd4019004 0x4>;
+				};
+
+				gcb2: gpio at d4019008 {
+					reg = <0xd4019008 0x4>;
+				};
+
+				gcb3: gpio at d4019100 {
+					reg = <0xd4019100 0x4>;
+				};
+			};
+
+			twsi1: i2c at d4011000 {
+				compatible = "marvell,mmp-twsi";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <0xd4011000 0x1000>;
+				interrupts = <0 7 0x4>;
+				marvell,i2c-fast-mode;
+				status = "disabled";
+			};
+
+			twsi2: i2c at d4037000 {
+				compatible = "marvell,mmp-twsi";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <0xd4037000 0x1000>;
+				interrupts = <0 54 0x4>;
+				status = "disabled";
+			};
+
+			rtc: rtc at d4010000 {
+				compatible = "marvell,mmp-rtc";
+				reg = <0xd4010000 0x1000>;
+				interrupts = <0 5 0x4>,<0 6 0x4>;
+				interrupt-names = "rtc 1Hz", "rtc alarm";
+				status = "disabled";
+			};
+			pmx: pinmux at d401e000 {
+				compatible = "pinconf-single";
+				reg = <0xd401e000 0x330>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				#gpio-range-cells = <3>;
+				ranges;
+
+				pinctrl-single,register-width = <32>;
+				pinctrl-single,function-mask = <7>;
+
+				range: gpio-range {
+					#pinctrl-single,gpio-range-cells = <3>;
+				};
+			};
+		};
+	};
+};
diff --git a/arch/arm/mach-mmp/Kconfig b/arch/arm/mach-mmp/Kconfig
index ebdda83..ee2904e 100644
--- a/arch/arm/mach-mmp/Kconfig
+++ b/arch/arm/mach-mmp/Kconfig
@@ -100,6 +100,7 @@ config MACH_MMP2_DT
 	bool "Support MMP2 (ARMv7) platforms from device tree"
 	depends on !CPU_MOHAWK
 	select CPU_MMP2
+	select CPU_PXA988
 	select USE_OF
 	select PINCTRL
 	select PINCTRL_SINGLE
@@ -123,6 +124,23 @@ config CPU_PXA910
 	help
 	  Select code specific to PXA910
 
+config CPU_PXA988
+	bool
+	select CPU_V7
+	select ARM_GIC
+	select HAVE_SMP
+	select HAVE_ARM_SCU
+	select LOCAL_TIMERS
+	select HAVE_ARM_TWD
+	select COMMON_CLK
+	select CLKSRC_OF
+	select MIGHT_HAVE_CACHE_L2X0
+	help
+	  Say 'Y' here if you want to support the Marvell pxa988-base
+	  platforms.
+	  PXA988 is an SoC with dual-core Cotex-A9 and comunication
+	  processor, code name "Emei".
+
 config CPU_MMP2
 	bool
 	select COMMON_CLK
diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
index 095c155..e5885ef 100644
--- a/arch/arm/mach-mmp/Makefile
+++ b/arch/arm/mach-mmp/Makefile
@@ -8,6 +8,7 @@ obj-y				+= common.o devices.o time.o irq.o
 obj-$(CONFIG_CPU_PXA168)	+= pxa168.o
 obj-$(CONFIG_CPU_PXA910)	+= pxa910.o
 obj-$(CONFIG_CPU_MMP2)		+= mmp2.o sram.o
+obj-$(CONFIG_CPU_PXA988)	+= platsmp.o headsmp.o reset.o
 
 ifeq ($(CONFIG_COMMON_CLK), )
 obj-y				+= clock.o
diff --git a/arch/arm/mach-mmp/common.c b/arch/arm/mach-mmp/common.c
index 9292b79..0c621bc 100644
--- a/arch/arm/mach-mmp/common.c
+++ b/arch/arm/mach-mmp/common.c
@@ -11,6 +11,10 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/of.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/of_address.h>
 
 #include <asm/page.h>
 #include <asm/mach/map.h>
@@ -36,7 +40,12 @@ static struct map_desc standard_io_desc[] __initdata = {
 		.virtual	= (unsigned long)AXI_VIRT_BASE,
 		.length		= AXI_PHYS_SIZE,
 		.type		= MT_DEVICE,
-	},
+	}, {
+		.pfn		= __phys_to_pfn(MMP_CORE_PERIPH_PHYS_BASE),
+		.virtual	= (unsigned long)MMP_CORE_PERIPH_VIRT_BASE,
+		.length		= MMP_CORE_PERIPH_PHYS_SIZE,
+		.type		= MT_DEVICE,
+	}
 };
 
 void __init mmp_map_io(void)
diff --git a/arch/arm/mach-mmp/common.h b/arch/arm/mach-mmp/common.h
index 0bdc50b..ea0225f 100644
--- a/arch/arm/mach-mmp/common.h
+++ b/arch/arm/mach-mmp/common.h
@@ -1,5 +1,7 @@
 #define ARRAY_AND_SIZE(x)	(x), ARRAY_SIZE(x)
 
+extern struct smp_operations mmp_smp_ops;
+
 extern void timer_init(int irq);
 
 extern void __init icu_init_irq(void);
diff --git a/arch/arm/mach-mmp/headsmp.S b/arch/arm/mach-mmp/headsmp.S
new file mode 100644
index 0000000..2b6177e
--- /dev/null
+++ b/arch/arm/mach-mmp/headsmp.S
@@ -0,0 +1,104 @@
+/*
+ * linux/arch/arm/mach-mmp/headsmp.S
+ *
+ * Copyright (C) 2012 Marvell, Inc.
+ *
+ * Author: Neil Zhang <zhangwm at marvell.com>
+ *
+ * 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.
+ *
+ */
+#include <linux/linkage.h>
+#include <linux/init.h>
+#include <asm/memory.h>
+#include <asm/cache.h>
+#include <asm/assembler.h>
+#include <mach/addr-map.h>
+
+	__CPUINIT
+
+/*
+ * Marvell specific entry point for secondary CPUs.
+ * The secondary kernel init calls v7_flush_dcache_all before it enables
+ * the L1; however, the L1 comes out of reset in an undefined state, so
+ * the clean + invalidate performed by v7_flush_dcache_all causes a bunch
+ * of cache lines with uninitialized data and uninitialized tags to get
+ * written out to memory, which does really unpleasant things to the main
+ * processor.  We fix this by performing an invalidate, rather than a
+ * clean + invalidate for secondary core, before jumping into the kernel.
+ *
+ * This funciton is cloned from arch/arm/mach-tegra/headsmp.S, and needs
+ * to be called for both secondary cores startup and primary core resume
+ * procedures.
+ */
+	.align L1_CACHE_SHIFT
+
+
+/*
+ * PXA specific entry point for secondary CPUs.  This provides
+ * a "holding pen" into which all secondary cores are held until we're
+ * ready for them to initialise.
+ */
+ENTRY(mmp_secondary_startup)
+	mrc	p15, 0, r0, c0, c0, 5
+	and	r0, r0, #15
+	adr	r4, 1f
+	ldmia	r4, {r5, r6}
+	sub	r4, r4, r5
+	add	r6, r6, r4
+pen:	ldr	r7, [r6]
+	cmp	r7, r0
+	bne	pen
+
+	/*
+	 * we've been released from the holding pen: secondary_stack
+	 * should now contain the SVC stack for this core
+	 */
+	bl	v7_invalidate_l1
+	b	secondary_startup
+ENDPROC(mmp_secondary_startup)
+
+	.align	2
+1:	.long	.
+	.long	pen_release
+
+
+/*
+ * Note: The following code is located into the .data section. This is to
+ *       allow sw_reset_flag and cpu_plugin_handler to be accessed with a
+ *       relative load while we can't rely on any MMU translation.
+ *       Reference from: arch/arm/kernel/sleep.S
+ */
+
+	.data
+	.align
+
+/*
+ * ROM code jumps to this function while waking up from CPU
+ * OFF or software reset state. Physical address of the function is
+ * stored at CA9_WARM_RESET_VECTOR while system is bring up.
+ */
+ENTRY(mmp_cpu_reset_entry)
+	adr	r1, mmp_entry_vectors
+	mrc	p15, 0, r0, c0, c0, 5
+	and	r0, r0, #15		@ fetch CPUID
+1:
+	ldr	r2, [r1, r0, lsl #2]    @ get the handler addr for this core
+	cmp	r2, #0
+	movne	pc, r2			@ jump to the handler
+	beq	1b
+ENDPROC(mmp_cpu_reset_entry)
+
+	/* Point to the address that save handlers for each core */
+	.global mmp_entry_vectors
+mmp_entry_vectors:
+	.rept   CONFIG_NR_CPUS
+        .long   0                               @ preserve stack phys ptr here
+	.endr
diff --git a/arch/arm/mach-mmp/include/mach/addr-map.h b/arch/arm/mach-mmp/include/mach/addr-map.h
index f88a44c..092005b 100644
--- a/arch/arm/mach-mmp/include/mach/addr-map.h
+++ b/arch/arm/mach-mmp/include/mach/addr-map.h
@@ -25,6 +25,10 @@
 #define AXI_VIRT_BASE		IOMEM(0xfe200000)
 #define AXI_PHYS_SIZE		0x00200000
 
+#define MMP_CORE_PERIPH_PHYS_BASE	0xd1dfe000
+#define MMP_CORE_PERIPH_VIRT_BASE	IOMEM(0xfe400000)
+#define MMP_CORE_PERIPH_PHYS_SIZE	0x00002000
+
 /* Static Memory Controller - Chip Select 0 and 1 */
 #define SMC_CS0_PHYS_BASE	0x80000000
 #define SMC_CS0_PHYS_SIZE	0x10000000
@@ -43,4 +47,6 @@
 #define CIU_VIRT_BASE		(AXI_VIRT_BASE + 0x82c00)
 #define CIU_REG(x)		(CIU_VIRT_BASE + (x))
 
+#define SCU_VIRT_BASE		(MMP_CORE_PERIPH_VIRT_BASE)
+
 #endif /* __ASM_MACH_ADDR_MAP_H */
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index 0ce46f1..56df68c 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -11,15 +11,19 @@
 
 #include <linux/io.h>
 #include <linux/irq.h>
+#include <linux/irqchip.h>
 #include <linux/irqdomain.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
+#include <linux/clocksource.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
+#include <asm/hardware/cache-l2x0.h>
 #include <mach/irqs.h>
 #include <mach/regs-apbc.h>
 
 #include "common.h"
+#include "reset.h"
 
 extern void __init mmp_dt_irq_init(void);
 
@@ -35,14 +39,41 @@ static const struct of_dev_auxdata mmp2_auxdata_lookup[] __initconst = {
 	{}
 };
 
+static const struct of_dev_auxdata pxa988_auxdata_lookup[] __initconst = {
+	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4036000, "pxa2xx-uart.2", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4037000, "pxa2xx-i2c.1", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-gpio", 0xd4019000, "pxa-gpio", NULL),
+	OF_DEV_AUXDATA("marvell,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
+	{}
+};
+
 static void __init mmp2_dt_init(void)
 {
 	of_platform_populate(NULL, of_default_bus_match_table,
 			     mmp2_auxdata_lookup, NULL);
 }
 
+static void __init pxa988_dt_init_early(void)
+{
+	mmp_entry_vector_init();
+}
+
+static void __init pxa988_dt_init_machine(void)
+{
+	l2x0_of_init(0x30800000, 0xFE7FFFFF);
+
+	pxa910_clk_init();
+
+	of_platform_populate(NULL, of_default_bus_match_table,
+				pxa988_auxdata_lookup, NULL);
+}
+
 static const char *mmp2_dt_board_compat[] __initdata = {
 	"marvell,mmp2-brownstone",
+	"marvell,pxa988-dkb",
 	NULL,
 };
 
@@ -53,3 +84,13 @@ DT_MACHINE_START(MMP2_DT, "Marvell MMP2 (Device Tree Support)")
 	.init_machine	= mmp2_dt_init,
 	.dt_compat	= mmp2_dt_board_compat,
 MACHINE_END
+
+DT_MACHINE_START(PXA988_DT, "Marvell PXA988 (Device Tree Support)")
+	.smp		= smp_ops(mmp_smp_ops),
+	.map_io		= mmp_map_io,
+	.init_early	= pxa988_dt_init_early,
+	.init_irq	= irqchip_init,
+	.init_time	= clocksource_of_init,
+	.init_machine	= pxa988_dt_init_machine,
+	.dt_compat	= mmp2_dt_board_compat,
+MACHINE_END
diff --git a/arch/arm/mach-mmp/platsmp.c b/arch/arm/mach-mmp/platsmp.c
new file mode 100644
index 0000000..f341a67
--- /dev/null
+++ b/arch/arm/mach-mmp/platsmp.c
@@ -0,0 +1,167 @@
+/*
+ *  linux/arch/arm/mach-mmp/platsmp.c
+ *
+ *  Copyright (C) 2002 ARM Ltd.
+ *  All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/jiffies.h>
+#include <linux/smp.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+
+#include <asm/cacheflush.h>
+#include <mach/hardware.h>
+#include <linux/irqchip/arm-gic.h>
+#include <asm/mach-types.h>
+#include <asm/localtimer.h>
+#include <asm/smp_scu.h>
+
+#include <mach/irqs.h>
+#include <mach/addr-map.h>
+
+#include "common.h"
+#include "reset.h"
+
+/*
+ * Write pen_release in a way that is guaranteed to be visible to all
+ * observers, irrespective of whether they're taking part in coherency
+ * or not.  This is necessary for the hotplug code to work reliably.
+ */
+static void __cpuinit write_pen_release(int val)
+{
+	pen_release = val;
+	smp_wmb();
+	__cpuc_flush_dcache_area((void *)&pen_release, sizeof(pen_release));
+	outer_clean_range(__pa(&pen_release), __pa(&pen_release + 1));
+}
+
+#ifdef CONFIG_HAVE_ARM_SCU
+static void __iomem *scu_get_base_addr(void)
+{
+	return SCU_VIRT_BASE;
+}
+#endif
+
+static inline unsigned int get_core_count(void)
+{
+	u32 ret = 1;
+#ifdef CONFIG_HAVE_ARM_SCU
+	ret = scu_get_core_count(scu_get_base_addr());
+#endif
+
+	return ret;
+}
+
+static DEFINE_SPINLOCK(boot_lock);
+
+static void __cpuinit mmp_secondary_init(unsigned int cpu)
+{
+	/*
+	 * let the primary processor know we're out of the
+	 * pen, then head off into the C entry point
+	 */
+	write_pen_release(-1);
+
+	/*
+	 * Synchronise with the boot thread.
+	 */
+	spin_lock(&boot_lock);
+	spin_unlock(&boot_lock);
+}
+
+static int __cpuinit mmp_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+	unsigned long timeout;
+
+	/*
+	 * Avoid timer calibration on slave cpus. Use the value calibrated
+	 * on master cpu. Referenced from tegra3
+	 */
+	preset_lpj = loops_per_jiffy;
+
+	/*
+	 * set synchronisation state between this boot processor
+	 * and the secondary one
+	 */
+
+	spin_lock(&boot_lock);
+
+	/*
+	 * The secondary processor is waiting to be released from
+	 * the holding pen - release it, then wait for it to flag
+	 * that it has been released by resetting pen_release.
+	 *
+	 * Note that "pen_release" is the hardware CPU ID, whereas
+	 * "cpu" is Linux's internal ID.
+	 */
+	write_pen_release(cpu);
+
+	/* reset the cpu, let it branch to the kernel entry */
+	mmp_cpu_power_up(cpu);
+
+	timeout = jiffies + (1 * HZ);
+	while (time_before(jiffies, timeout)) {
+		smp_rmb();
+		if (pen_release == -1)
+			break;
+
+		udelay(10);
+	}
+
+	/*
+	 * now the secondary core is starting up let it run its
+	 * calibrations, then wait for it to finish
+	 */
+	spin_unlock(&boot_lock);
+
+	return pen_release != -1 ? -ENOSYS : 0;
+}
+
+/*
+ * Initialise the CPU possible map early - this describes the CPUs
+ * which may be present or become present in the system.
+ */
+static void __init mmp_smp_init_cpus(void)
+{
+	unsigned int i, ncores = get_core_count();
+
+	if (ncores > nr_cpu_ids) {
+		pr_warn("SMP: %u cores greater than maximum (%u), clipping\n",
+			ncores, nr_cpu_ids);
+		ncores = nr_cpu_ids;
+	}
+
+	for (i = 0; i < ncores; i++)
+		set_cpu_possible(i, true);
+}
+
+static void __init mmp_smp_prepare_cpus(unsigned int max_cpus)
+{
+	int i;
+
+	/*
+	 * Initialise the present map, which describes the set of CPUs
+	 * actually populated at the present time.
+	 */
+	for (i = 0; i < max_cpus; i++)
+		set_cpu_present(i, true);
+
+#ifdef CONFIG_HAVE_ARM_SCU
+	scu_enable(scu_get_base_addr());
+#endif
+}
+
+struct smp_operations mmp_smp_ops __initdata = {
+	.smp_init_cpus		= mmp_smp_init_cpus,
+	.smp_prepare_cpus	= mmp_smp_prepare_cpus,
+	.smp_secondary_init	= mmp_secondary_init,
+	.smp_boot_secondary	= mmp_boot_secondary,
+};
diff --git a/arch/arm/mach-mmp/reset.c b/arch/arm/mach-mmp/reset.c
new file mode 100644
index 0000000..b90ec54
--- /dev/null
+++ b/arch/arm/mach-mmp/reset.c
@@ -0,0 +1,66 @@
+/*
+ * linux/arch/arm/mach-mmp/reset.c
+ *
+ * Author:	Neil Zhang <zhangwm at marvell.com>
+ * Copyright:	(C) 2012 Marvell International Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/smp.h>
+
+#include <asm/io.h>
+#include <asm/cacheflush.h>
+#include <asm/mach/map.h>
+
+#include <mach/addr-map.h>
+
+#include "reset.h"
+
+#define PMU_CC2_AP			APMU_REG(0x0100)
+#define CIU_CA9_WARM_RESET_VECTOR	CIU_REG(0x00d8)
+
+/*
+ * This function is called from boot_secondary to bootup the secondary cpu.
+ */
+void mmp_cpu_power_up(u32 cpu)
+{
+	u32 tmp;
+
+	BUG_ON(cpu == 0);
+
+	tmp = readl(PMU_CC2_AP);
+	if (tmp & CPU_CORE_RST(cpu)) {
+		/* Release secondary core from reset */
+		tmp &= ~(CPU_CORE_RST(cpu)
+			| CPU_DBG_RST(cpu) | CPU_WDOG_RST(cpu));
+		writel(tmp, PMU_CC2_AP);
+	}
+}
+
+void mmp_set_entry_vector(u32 cpu, u32 addr)
+{
+	BUG_ON(cpu >= nr_cpu_ids);
+
+	mmp_entry_vectors[cpu] = addr;
+	smp_wmb();
+	__cpuc_flush_dcache_area((void *)&mmp_entry_vectors[cpu],
+				sizeof(mmp_entry_vectors[cpu]));
+	outer_clean_range(__pa(&mmp_entry_vectors[cpu]),
+				__pa(&mmp_entry_vectors[cpu + 1]));
+}
+
+void __init mmp_entry_vector_init(void)
+{
+	int cpu;
+
+	/* We will reset from DDR directly by default */
+	writel(__pa(mmp_cpu_reset_entry), CIU_CA9_WARM_RESET_VECTOR);
+
+	for (cpu = 1; cpu < nr_cpu_ids; cpu++)
+		mmp_set_entry_vector(cpu, __pa(mmp_secondary_startup));
+}
diff --git a/arch/arm/mach-mmp/reset.h b/arch/arm/mach-mmp/reset.h
new file mode 100644
index 0000000..78d5486
--- /dev/null
+++ b/arch/arm/mach-mmp/reset.h
@@ -0,0 +1,29 @@
+/*
+ * linux/arch/arm/mach-mmp/include/mach/reset.h
+ *
+ * Author:	Neil Zhang <zhangwm at marvell.com>
+ * Copyright:	(C) 2012 Marvell International Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __RESET_PXA988_H__
+#define __RESET_PXA988_H__
+
+#define CPU_CORE_RST(n)	(1 << ((n) * 4 + 16))
+#define CPU_DBG_RST(n)	(1 << ((n) * 4 + 18))
+#define CPU_WDOG_RST(n)	(1 << ((n) * 4 + 19))
+
+extern u32 mmp_entry_vectors[CONFIG_NR_CPUS];
+
+void mmp_secondary_startup(void);
+void mmp_cpu_reset_entry(void);
+
+void mmp_cpu_power_up(u32 cpu);
+void mmp_set_entry_vector(u32 cpu, u32 addr);
+void __init mmp_entry_vector_init(void);
+
+#endif /* __RESET_PXA988_H__ */
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 392d780..59a3f9f7 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -7,3 +7,4 @@ obj-y += clk-apbc.o clk-apmu.o clk-frac.o
 obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
 obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
 obj-$(CONFIG_CPU_MMP2) += clk-mmp2.o
+obj-$(CONFIG_CPU_PXA988) += clk-pxa910.o
-- 
1.7.4.1



From s.hauer at pengutronix.de  Tue Jul  9 03:05:41 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 9 Jul 2013 09:05:41 +0200
Subject: [PATCH] of: match the compatible in the order set by the dts file
In-Reply-To: <1373013818-11365-1-git-send-email-b32955@freescale.com>
References: <1373013818-11365-1-git-send-email-b32955@freescale.com>
Message-ID: <20130709070541.GQ516@pengutronix.de>

On Fri, Jul 05, 2013 at 04:43:38PM +0800, Huang Shijie wrote:
> If we set the uart compatible in the dts file like this:
>    ------------------------------------------------------
>     compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
>    ------------------------------------------------------
> 
> and we set the uart compatible in the uart driver like this:
>    ------------------------------------------------------
> 	{ .compatible = "fsl,imx1-uart", ... },
> 	{ .compatible = "fsl,imx21-uart", ... },
> 	{ .compatible = "fsl,imx6q-uart", ... },
> 	{ /* sentinel */ }
>    ------------------------------------------------------
> 
> the current code will match the "fsl,imx21-uart" in the end.
> 
> Of course, this is not what we want. We want it to match the "fsl,imx6q-uart".
> 
> This patch rewrites the match code, and make it to check the compatible
> in the order set by the DTS file.

Why don't you set the matching order in the driver the way you want it
to be, i.e.:

	{ .compatible = "fsl,imx6q-uart", ... },
	{ .compatible = "fsl,imx21-uart", ... },
	{ .compatible = "fsl,imx1-uart", ... },

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From srinivas.kandagatla at st.com  Tue Jul  9 03:05:13 2013
From: srinivas.kandagatla at st.com (Srinivas KANDAGATLA)
Date: Tue, 09 Jul 2013 08:05:13 +0100
Subject: [PATCH v1 0/4] ARM: STi fixes and ethernet support
In-Reply-To: <201307090118.06715.arnd@arndb.de>
References: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
 <201307090118.06715.arnd@arndb.de>
Message-ID: <51DBB629.1050000@st.com>

Thanks Arnd,
On 09/07/13 00:18, Arnd Bergmann wrote:
> On Monday 08 July 2013, Srinivas KANDAGATLA wrote:
>> From: Srinivas Kandagatla <srinivas.kandagatla at st.com>
>>
>> This patch series fixes 2 configuration issues and adds ethernet support to
>> STiH415, STiH416 based B2000, B2020 boards.
> 
> Hi Srini,
> 
> You really have to send those things separately, as the bug fixes should
> probably go into 3.11, while the rest is new features and needs to be
> reviewed for merging into 3.12.
Yes, I will resend the fixes separately.
> 
> I'm also puzzled by the fact that you add auxdata and callback
> functions for the ether part in the platform code. Those should
> probably all be properties added to the stmmac binding.

stmmac (aka "dwmac" a synopsis IP) driver is integrated in to kernel
sometime in 2.6 series I think :-), and Is used by more than 4 platforms
in 3.10 kernel. The driver is more generic than it sounds.
So adding properties/hooks specific to STiH41x SOCs in driver seemed to
incorrect. Instead doing platform specific bits in the mach via
callbacks was the only choice I had.

Thanks,
srini

> 
> 	Arnd
> 



From rnayak at ti.com  Tue Jul  9 03:19:10 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 12:49:10 +0530
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130709064212.GB5552@arwen.pp.htv.fi>
References: <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <51DBA0C2.6030003@ti.com>
 <20130709064212.GB5552@arwen.pp.htv.fi>
Message-ID: <51DBB96E.90600@ti.com>

On Tuesday 09 July 2013 12:12 PM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 09, 2013 at 11:03:54AM +0530, Rajendra Nayak wrote:
>> On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
>>>>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>>>>>> of -1 for the serial driver?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>>>>>
>>>>>>> OK
>>>>>>
>>>>>> Issue 2: Causing boot to stop when serial driver is initialized.
>>>>>> (After Issue 1 is fixed)
>>>>>>
>>>>>> I could narrow this down to the change done to return -EINVAL
>>>>>> instead of 0 in serial_omap_get_context_loss_count() as part of
>>>>>> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
>>>>>> Fix device tree based PM runtime"
>>>>>>
>>>>>> What this change in turn seems to do is cause a
>>>>>> serial_omap_restore_context() to get called as part of
>>>>>> serial_omap_runtime_resume() which was not the case when
>>>>>> serial_omap_get_context_loss_count() returned 0
>>>>>>
>>>>>> from serial_omap_runtime_resume():
>>>>>> -----
>>>>>>         int loss_cnt = serial_omap_get_context_loss_count(up);
>>>>>>
>>>>>>         if (loss_cnt < 0) {
>>>>>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>>>>>                         loss_cnt);
>>>>>>                 serial_omap_restore_context(up);
>>>>>>         } else if (up->context_loss_cnt != loss_cnt) {
>>>>>>                 serial_omap_restore_context(up);
>>>>>>         }
>>>>>> -----
>>>>>>
>>>>>> I am still working on why a serial_omap_restore_context() could
>>>>>> have caused console to die. I will work with Sourav on this and
>>>>>> post the fixes for both issue 1 and issue2 once its clear on whats
>>>>>> really causing issue 2.
>>>>>
>>>>> That's because we don't have the omap specific pdata callbacks for
>>>>> context loss any longer. We may be able to detect when the context
>>>>> was really lost in the serial driver, and only then call the
>>>>> serial_omap_restore_context().
>>>>
>>>> Right, but calling serial_omap_restore_context() even when the context
>>>> is not lost, should not ideally cause an issue.
>>>
>>> it does in one condition. If context hasn't been saved before. And that
>>> can happen in the case of wrong pm runtime status for that device.
>>>
>>> Imagine the device is marked as suspended even though it's fully enabled
>>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
>>> your context structure is all zeroes (context has never been saved
>>> before) then when you call pm_runtime_get_sync() on probe() your
>>> ->runtime_resume() will get called, which will restore context,
>>> essentially undoing anything which was configured by u-boot.
>>
>> This could be a problem for drivers which do a save context in ->runtime_suspend()
>> but from what I see with omap serial, there is no save context done as part of
>> ->runtime_suspend.
> 
> right, because context is "saved" in set_termios. probe() will get
> called much before set_termios() has a chance to run, right ?
> 
> Same problem will trigger in that case.
> 
> I still think patch below is necessary

Right, I'll try some on those lines. Looks like a pm_runtime_set_active() is done
for the console in the non DT case in omap_serial_init_port(). It seems to be
missing in the DT case.

Although I feel this should fix the issue we have right now, I wonder if there could
ever be a case with uart being suspended and having to resume again before a
set_termios? What I mean to ask is, if the omap serial driver assuming a resume to
happen only post a set_termios is always valid.

> 
>>> (completely untested, didn't even try to compile, just to illustrate)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
>>> index 7341eff..d8dca68 100644
>>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>>> @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
>>>  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
>>>  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
>>>  		postsetup_state = _HWMOD_STATE_ENABLED;
>>> +
>>> +		/* tell pm_runtime this device is already active */
>>> +		pm_runtime_set_active(&oh->od->pdev->dev);
>>> +	} else {
>>> +		/* tell pm_runtime this device is trully suspended */
>>> +		pm_runtime_set_suspended(&oh->od->pdev->dev);
>>>  	}
>>>  
>>>  	if (postsetup_state == _HWMOD_STATE_IDLE)
> 



From rnayak at ti.com  Tue Jul  9 03:27:45 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 12:57:45 +0530
Subject: [PATCH 0/8] DRA7xx core support
Message-ID: <1373354873-12359-1-git-send-email-rnayak@ti.com>

DRA7xx based SoCs' are high-performance, infotainment application devices,
based on enhanced OMAP architecture integrated on a 28nm
technology.

The DRA7xx family is composed of DRA75x and DRA74x devices.
The current device for which the patches add support is the
DRA752 SoC.

Most of the core IPs are similar to those found on the OMAP5
devices, including the dual cortex-A15 based MPU subsystem,
which has helped quite some reuse from existing OMAP5 support.

This series contains only core support patches and the PRCM,
DT and hwmod data needed for the device will be posted as a
seperate patch series.

The bootloader support for the platform is already available
in mainline u-boot.

The patches are available at:
git://github.com/rrnayak/linux.git for-3.12/dra-core

R Sricharan (6):
  ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
  ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
  ARM: DRA7: Reuse io tables and add a new .init_early
  ARM: DRA7: Resue the clocksource, clockevent support
  ARM: DRA7: board-generic: Add basic DT support
  ARM: DRA7: Kconfig: Increase the default gpio count

Rajendra Nayak (2):
  ARM: DRA7: Update SRAM details
  ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5

 .../devicetree/bindings/arm/omap/omap.txt          |    3 ++
 arch/arm/Kconfig                                   |    2 +-
 arch/arm/mach-omap1/include/mach/soc.h             |    1 +
 arch/arm/mach-omap2/Kconfig                        |    2 +-
 arch/arm/mach-omap2/Makefile                       |    8 ++++
 arch/arm/mach-omap2/board-generic.c                |   18 +++++++++
 arch/arm/mach-omap2/common.h                       |    1 +
 arch/arm/mach-omap2/id.c                           |   30 ++++++++++++++-
 arch/arm/mach-omap2/io.c                           |   22 ++++++++++-
 arch/arm/mach-omap2/omap54xx.h                     |    4 ++
 arch/arm/mach-omap2/omap_hwmod.c                   |    2 +-
 arch/arm/mach-omap2/soc.h                          |   39 ++++++++++++++++++++
 arch/arm/mach-omap2/sram.c                         |    7 ++++
 arch/arm/mach-omap2/timer.c                        |    3 +-
 14 files changed, 134 insertions(+), 8 deletions(-)

-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:27:46 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 12:57:46 +0530
Subject: [PATCH 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based
 SoCs'
In-Reply-To: <1373354873-12359-1-git-send-email-rnayak@ti.com>
References: <1373354873-12359-1-git-send-email-rnayak@ti.com>
Message-ID: <1373354873-12359-2-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

The DRA7xx is a high-performance, infotainment application device,
based on enhanced OMAP architecture integrated on a 28-nm technology.

DRA7xx family is composed of DRA75x and DRA74x devices.

Adding the DRA752 ES1.0 cpu revision detection support.

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap1/include/mach/soc.h |    1 +
 arch/arm/mach-omap2/id.c               |   30 ++++++++++++++++++++++--
 arch/arm/mach-omap2/soc.h              |   39 ++++++++++++++++++++++++++++++++
 3 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap1/include/mach/soc.h b/arch/arm/mach-omap1/include/mach/soc.h
index 6cf9c1c..612bd1c 100644
--- a/arch/arm/mach-omap1/include/mach/soc.h
+++ b/arch/arm/mach-omap1/include/mach/soc.h
@@ -195,6 +195,7 @@ IS_OMAP_TYPE(1710, 0x1710)
 #define cpu_is_omap34xx()		0
 #define cpu_is_omap44xx()		0
 #define soc_is_omap54xx()		0
+#define soc_is_dra7xx()			0
 #define soc_is_am33xx()			0
 #define cpu_class_is_omap1()		1
 #define cpu_class_is_omap2()		0
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2dc62a2..332ae95 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -61,7 +61,7 @@ int omap_type(void)
 		val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
 	} else if (cpu_is_omap44xx()) {
 		val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
-	} else if (soc_is_omap54xx()) {
+	} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
 		val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
 		val &= OMAP5_DEVICETYPE_MASK;
 		val >>= 6;
@@ -116,7 +116,7 @@ static u16 tap_prod_id;
 
 void omap_get_die_id(struct omap_die_id *odi)
 {
-	if (cpu_is_omap44xx() || soc_is_omap54xx()) {
+	if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
 		odi->id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0);
 		odi->id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1);
 		odi->id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2);
@@ -606,6 +606,32 @@ void __init omap5xxx_check_revision(void)
 	pr_info("%s %s\n", soc_name, soc_rev);
 }
 
+void __init dra7xx_check_revision(void)
+{
+	u32 idcode;
+	u16 hawkeye;
+	u8 rev;
+
+	idcode = read_tap_reg(OMAP_TAP_IDCODE);
+	hawkeye = (idcode >> 12) & 0xffff;
+	rev = (idcode >> 28) & 0xff;
+	switch (hawkeye) {
+	case 0xb990:
+		switch (rev) {
+		case 0:
+		default:
+			omap_revision = DRA752_REV_ES1_0;
+		}
+		break;
+	default:
+		/* Unknown. Default to latest silicon revision */
+		omap_revision = DRA752_REV_ES1_0;
+	}
+
+	pr_info("DRA%03x ES%d.%d\n", omap_rev() >> 16,
+		((omap_rev() >> 12) & 0xf), ((omap_rev() >> 8) & 0xf));
+}
+
 /*
  * Set up things for map_io and processor detection later on. Gets called
  * pretty much first thing from board init. For multi-omap, this gets
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 8c616e4..0d242f1 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -8,6 +8,7 @@
  * Written by Tony Lindgren <tony.lindgren at nokia.com>
  *
  * Added OMAP4/5 specific defines - Santosh Shilimkar<santosh.shilimkar at ti.com>
+ * Added DRA7xxx specific defines - Sricharan R<r.sricharan at ti.com>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -105,6 +106,15 @@
 # endif
 #endif
 
+#ifdef CONFIG_SOC_DRA7XX
+# ifdef OMAP_NAME
+#  undef MULTI_OMAP2
+#  define MULTI_OMAP2
+# else
+#  define OMAP_NAME DRA7XX
+# endif
+#endif
+
 /*
  * Omap device type i.e. EMU/HS/TST/GP/BAD
  */
@@ -145,6 +155,7 @@ static inline int soc_is_omap(void)
  * cpu_is_omap446x():	True for OMAP4460
  * cpu_is_omap447x():	True for OMAP4470
  * soc_is_omap543x():	True for OMAP5430, OMAP5432
+ * soc_is_dra75x():	True for DRA752, DRA754, DRA756
  */
 #define GET_OMAP_CLASS	(omap_rev() & 0xff)
 
@@ -170,6 +181,12 @@ static inline int is_ti ##class (void)		\
 	return (GET_TI_CLASS == (id)) ? 1 : 0;	\
 }
 
+#define IS_DRA_CLASS(class, id)				\
+static inline int is_dra ##class(void)			\
+{							\
+	return (GET_OMAP_CLASS == (id)) ? 1 : 0;	\
+}
+
 #define GET_OMAP_SUBCLASS	((omap_rev() >> 20) & 0x0fff)
 
 #define IS_OMAP_SUBCLASS(subclass, id)			\
@@ -190,6 +207,12 @@ static inline int is_am ##subclass (void)		\
 	return (GET_OMAP_SUBCLASS == (id)) ? 1 : 0;	\
 }
 
+#define IS_DRA_SUBCLASS(subclass, id)			\
+static inline int is_dra ##subclass(void)		\
+{							\
+	return (GET_OMAP_SUBCLASS == (id)) ? 1 : 0;	\
+}
+
 IS_OMAP_CLASS(24xx, 0x24)
 IS_OMAP_CLASS(34xx, 0x34)
 IS_OMAP_CLASS(44xx, 0x44)
@@ -197,6 +220,7 @@ IS_AM_CLASS(35xx, 0x35)
 IS_OMAP_CLASS(54xx, 0x54)
 IS_AM_CLASS(33xx, 0x33)
 IS_AM_CLASS(43xx, 0x43)
+IS_DRA_CLASS(7xx, 0x7)
 
 IS_TI_CLASS(81xx, 0x81)
 
@@ -213,6 +237,8 @@ IS_TI_SUBCLASS(816x, 0x816)
 IS_TI_SUBCLASS(814x, 0x814)
 IS_AM_SUBCLASS(335x, 0x335)
 IS_AM_SUBCLASS(437x, 0x437)
+IS_DRA_SUBCLASS(75x, 0x75)
+IS_DRA_SUBCLASS(74x, 0x74)
 
 #define cpu_is_omap24xx()		0
 #define cpu_is_omap242x()		0
@@ -233,6 +259,8 @@ IS_AM_SUBCLASS(437x, 0x437)
 #define cpu_is_omap447x()		0
 #define soc_is_omap54xx()		0
 #define soc_is_omap543x()		0
+#define soc_is_dra7xx()			0
+#define soc_is_dra75x()			0
 
 #if defined(MULTI_OMAP2)
 # if defined(CONFIG_ARCH_OMAP2)
@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
 # define soc_is_omap543x()		is_omap543x()
 #endif
 
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()		is_dra7xx()
+# define soc_is_dra75x()		is_dra75x()
+#endif
+
 /* Various silicon revisions for omap2 */
 #define OMAP242X_CLASS		0x24200024
 #define OMAP2420_REV_ES1_0	OMAP242X_CLASS
@@ -443,6 +478,9 @@ IS_OMAP_TYPE(3430, 0x3430)
 #define OMAP5432_REV_ES1_0	(OMAP54XX_CLASS | (0x32 << 16) | (0x10 << 8))
 #define OMAP5432_REV_ES2_0	(OMAP54XX_CLASS | (0x32 << 16) | (0x20 << 8))
 
+#define DRA7XX_CLASS		0x07000007
+#define DRA752_REV_ES1_0	(DRA7XX_CLASS | (0x52 << 16) | (0x10 << 8))
+
 void omap2xxx_check_revision(void);
 void omap3xxx_check_revision(void);
 void omap4xxx_check_revision(void);
@@ -451,6 +489,7 @@ void omap3xxx_check_features(void);
 void ti81xx_check_features(void);
 void am33xx_check_features(void);
 void omap4xxx_check_features(void);
+void dra7xx_check_revision(void);
 
 /*
  * Runtime detection of OMAP3 features
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:27:48 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 12:57:48 +0530
Subject: [PATCH 3/8] ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5
In-Reply-To: <1373354873-12359-1-git-send-email-rnayak@ti.com>
References: <1373354873-12359-1-git-send-email-rnayak@ti.com>
Message-ID: <1373354873-12359-4-git-send-email-rnayak@ti.com>

The soc_ops for dra7xx devices can be completed reused
from the ones used for omap4 and omap5 devices.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
Signed-off-by: R Sricharan <r.sricharan at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7341eff..f6eb29b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -4113,7 +4113,7 @@ void __init omap_hwmod_init(void)
 		soc_ops.assert_hardreset = _omap2_assert_hardreset;
 		soc_ops.deassert_hardreset = _omap2_deassert_hardreset;
 		soc_ops.is_hardreset_asserted = _omap2_is_hardreset_asserted;
-	} else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
+	} else if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
 		soc_ops.enable_module = _omap4_enable_module;
 		soc_ops.disable_module = _omap4_disable_module;
 		soc_ops.wait_target_ready = _omap4_wait_target_ready;
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:27:47 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 12:57:47 +0530
Subject: [PATCH 2/8] ARM: DRA7: Update SRAM details
In-Reply-To: <1373354873-12359-1-git-send-email-rnayak@ti.com>
References: <1373354873-12359-1-git-send-email-rnayak@ti.com>
Message-ID: <1373354873-12359-3-git-send-email-rnayak@ti.com>

DRA7xx devices have 512K of SRAM for both secure and non-secure
devices.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
Signed-off-by: R Sricharan <r.sricharan at ti.com>
---
 arch/arm/mach-omap2/sram.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index 4bd0968..67d4277 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -38,6 +38,7 @@
 #define OMAP4_SRAM_PUB_PA	(OMAP4_SRAM_PA + 0x4000)
 #endif
 #define OMAP5_SRAM_PA		0x40300000
+#define DRA7_SRAM_PA		OMAP4_SRAM_PA
 
 #define SRAM_BOOTLOADER_SZ	0x00
 
@@ -111,6 +112,9 @@ static void __init omap_detect_sram(void)
 		} else if (soc_is_omap54xx()) {
 			omap_sram_start = OMAP5_SRAM_PA;
 			omap_sram_size = SZ_128K; /* 128KB */
+		} else if (soc_is_dra7xx()) {
+			omap_sram_start = DRA7_SRAM_PA;
+			omap_sram_size = SZ_512K; /* 512KB */
 		} else {
 			omap_sram_start = OMAP2_SRAM_PUB_PA;
 			omap_sram_size = 0x800; /* 2K */
@@ -131,6 +135,9 @@ static void __init omap_detect_sram(void)
 		} else if (soc_is_omap54xx()) {
 			omap_sram_start = OMAP5_SRAM_PA;
 			omap_sram_size = SZ_128K; /* 128KB */
+		} else if (soc_is_dra7xx()) {
+			omap_sram_start = DRA7_SRAM_PA;
+			omap_sram_size = SZ_512K; /* 512KB */
 		} else {
 			omap_sram_start = OMAP2_SRAM_PA;
 			if (cpu_is_omap242x())
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:27:49 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 12:57:49 +0530
Subject: [PATCH 4/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
In-Reply-To: <1373354873-12359-1-git-send-email-rnayak@ti.com>
References: <1373354873-12359-1-git-send-email-rnayak@ti.com>
Message-ID: <1373354873-12359-5-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

The PRCM and MPUSS parts of DRA7 devices are quite identical
to OMAP5 so as to reuse all the existing infrastructure around it.
Makefile updates to do just that.

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/Makefile |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ea5a27f..dbcd73f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common)
 obj-$(CONFIG_SOC_AM33XX) += irq.o $(hwmod-common)
 obj-$(CONFIG_SOC_OMAP5)	 += prm44xx.o $(hwmod-common) $(secure-common)
 obj-$(CONFIG_SOC_AM43XX) += $(hwmod-common) $(secure-common)
+obj-$(CONFIG_SOC_DRA7XX) += prm44xx.o $(hwmod-common) $(secure-common)
 
 ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),)
 obj-y += mcbsp.o
@@ -39,6 +40,7 @@ omap-4-5-common				=  omap4-common.o omap-wakeupgen.o
 obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-4-5-common) $(smp-y) sleep44xx.o
 obj-$(CONFIG_SOC_OMAP5)			+= $(omap-4-5-common) $(smp-y) sleep44xx.o
 obj-$(CONFIG_SOC_AM43XX)		+= $(omap-4-5-common)
+obj-$(CONFIG_SOC_DRA7XX)		+= $(omap-4-5-common) $(smp-y)
 
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_omap-headsmp.o			:=-Wa,-march=armv7-a$(plus_sec)
@@ -87,6 +89,7 @@ obj-$(CONFIG_ARCH_OMAP2)		+= sleep24xx.o
 obj-$(CONFIG_ARCH_OMAP3)		+= pm34xx.o sleep34xx.o
 obj-$(CONFIG_ARCH_OMAP4)		+= pm44xx.o omap-mpuss-lowpower.o
 obj-$(CONFIG_SOC_OMAP5)			+= omap-mpuss-lowpower.o
+obj-$(CONFIG_SOC_DRA7XX)		+= omap-mpuss-lowpower.o
 obj-$(CONFIG_PM_DEBUG)			+= pm-debug.o
 
 obj-$(CONFIG_POWER_AVS_OMAP)		+= sr_device.o
@@ -118,6 +121,7 @@ omap-prcm-4-5-common			=  cminst44xx.o cm44xx.o prm44xx.o \
 					   vc44xx_data.o vp44xx_data.o
 obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-prcm-4-5-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(omap-prcm-4-5-common)
+obj-$(CONFIG_SOC_DRA7XX)		+= $(omap-prcm-4-5-common)
 
 # OMAP voltage domains
 voltagedomain-common			:= voltage.o vc.o vp.o
@@ -147,6 +151,7 @@ obj-$(CONFIG_SOC_AM33XX)		+= powerdomains33xx_data.o
 obj-$(CONFIG_SOC_AM43XX)		+= $(powerdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(powerdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= powerdomains54xx_data.o
+obj-$(CONFIG_SOC_DRA7XX)		+= $(powerdomain-common)
 
 # PRCM clockdomain control
 clockdomain-common			+= clockdomain.o
@@ -164,6 +169,7 @@ obj-$(CONFIG_SOC_AM33XX)		+= clockdomains33xx_data.o
 obj-$(CONFIG_SOC_AM43XX)		+= $(clockdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(clockdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= clockdomains54xx_data.o
+obj-$(CONFIG_SOC_DRA7XX)		+= $(clockdomain-common)
 
 # Clock framework
 obj-$(CONFIG_ARCH_OMAP2)		+= $(clock-common) clock2xxx.o
@@ -185,6 +191,8 @@ obj-$(CONFIG_SOC_AM33XX)		+= $(clock-common) dpll3xxx.o
 obj-$(CONFIG_SOC_AM33XX)		+= cclock33xx_data.o
 obj-$(CONFIG_SOC_OMAP5)			+= $(clock-common)
 obj-$(CONFIG_SOC_OMAP5)			+= dpll3xxx.o dpll44xx.o
+obj-$(CONFIG_SOC_DRA7XX)		+= $(clock-common)
+obj-$(CONFIG_SOC_DRA7XX)		+= dpll3xxx.o dpll44xx.o
 
 # OMAP2 clock rate set data (old "OPP" data)
 obj-$(CONFIG_SOC_OMAP2420)		+= opp2420_data.o
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:27:50 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 12:57:50 +0530
Subject: [PATCH 5/8] ARM: DRA7: Reuse io tables and add a new .init_early
In-Reply-To: <1373354873-12359-1-git-send-email-rnayak@ti.com>
References: <1373354873-12359-1-git-send-email-rnayak@ti.com>
Message-ID: <1373354873-12359-6-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

The IO descriptor tables for DRA7 are a complete reuse from OMAP5.
A new dra7xx_init_early() does the base address inits.

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/common.h   |    1 +
 arch/arm/mach-omap2/io.c       |   22 ++++++++++++++++++++--
 arch/arm/mach-omap2/omap54xx.h |    4 ++++
 3 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 72cab3f..d226661 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -109,6 +109,7 @@ void omap3630_init_late(void);
 void am35xx_init_late(void);
 void ti81xx_init_late(void);
 int omap2_common_pm_late_init(void);
+void dra7xx_init_early(void);
 
 #ifdef CONFIG_SOC_BUS
 void omap_soc_device_init(void);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index fe3253a..542e6bd 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -251,7 +251,7 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
 };
 #endif
 
-#ifdef	CONFIG_SOC_OMAP5
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
 static struct map_desc omap54xx_io_desc[] __initdata = {
 	{
 		.virtual	= L3_54XX_VIRT,
@@ -333,7 +333,7 @@ void __init omap4_map_io(void)
 }
 #endif
 
-#ifdef CONFIG_SOC_OMAP5
+#if defined(CONFIG_SOC_OMAP5) ||  defined(CONFIG_SOC_DRA7XX)
 void __init omap5_map_io(void)
 {
 	iotable_init(omap54xx_io_desc, ARRAY_SIZE(omap54xx_io_desc));
@@ -653,6 +653,24 @@ void __init omap5_init_early(void)
 }
 #endif
 
+#ifdef CONFIG_SOC_DRA7XX
+void __init dra7xx_init_early(void)
+{
+	omap2_set_globals_tap(DRA7XX_CLASS,
+			      OMAP2_L4_IO_ADDRESS(DRA7XX_TAP_BASE));
+	omap2_set_globals_control(OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
+				  OMAP2_L4_IO_ADDRESS(DRA7XX_CTRL_BASE));
+	omap2_set_globals_prm(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE));
+	omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(DRA7XX_CM_CORE_AON_BASE),
+			     OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE));
+	omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
+	omap_prm_base_init();
+	omap_cm_base_init();
+	dra7xx_check_revision();
+}
+#endif
+
+
 void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
 				      struct omap_sdrc_params *sdrc_cs1)
 {
diff --git a/arch/arm/mach-omap2/omap54xx.h b/arch/arm/mach-omap2/omap54xx.h
index a086ba1..2d35c57 100644
--- a/arch/arm/mach-omap2/omap54xx.h
+++ b/arch/arm/mach-omap2/omap54xx.h
@@ -30,4 +30,8 @@
 #define OMAP54XX_CTRL_BASE		0x4a002800
 #define OMAP54XX_SAR_RAM_BASE		0x4ae26000
 
+#define DRA7XX_CM_CORE_AON_BASE		0x4a005000
+#define DRA7XX_CTRL_BASE		0x4a003400
+#define DRA7XX_TAP_BASE			0x4ae0c000
+
 #endif /* __ASM_SOC_OMAP555554XX_H */
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:27:51 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 12:57:51 +0530
Subject: [PATCH 6/8] ARM: DRA7: Resue the clocksource, clockevent support
In-Reply-To: <1373354873-12359-1-git-send-email-rnayak@ti.com>
References: <1373354873-12359-1-git-send-email-rnayak@ti.com>
Message-ID: <1373354873-12359-7-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

All of OMAP5 timer support for clocksource and clockevent is completely
reused across DRA7.

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/Kconfig |    2 +-
 arch/arm/mach-omap2/timer.c |    3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index c7b32a9..bd34483 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -50,7 +50,7 @@ config SOC_HAS_OMAP2_SDRC
 
 config SOC_HAS_REALTIME_COUNTER
 	bool "Real time free running counter"
-	depends on SOC_OMAP5
+	depends on SOC_OMAP5 || SOC_DRA7XX
 	default y
 
 config ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 29ac667..fc01704 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -594,7 +594,8 @@ OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL,
 		       1, "timer_sys_ck", "ti,timer-alwon");
 #endif
 
-#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
+	defined(CONFIG_SOC_DRA7XX)
 static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
 			       2, "sys_clkin_ck", NULL);
 #endif
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:27:52 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 12:57:52 +0530
Subject: [PATCH 7/8] ARM: DRA7: board-generic: Add basic DT support
In-Reply-To: <1373354873-12359-1-git-send-email-rnayak@ti.com>
References: <1373354873-12359-1-git-send-email-rnayak@ti.com>
Message-ID: <1373354873-12359-8-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

Describe minimal DT boot machine details for DRA7xx based SoC's. DRA7xx
family is based on dual core ARM CORTEX A15 using GIC as the interrupt controller.
The PRCM and timer infrastructure is reused from OMAP5 and so are the io
descriptor tables.

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 .../devicetree/bindings/arm/omap/omap.txt          |    3 +++
 arch/arm/mach-omap2/board-generic.c                |   18 ++++++++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 6d498c7..91b7049 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -59,3 +59,6 @@ Boards:
 
 - AM43x EPOS EVM
   compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
+
+- DRA7 EVM:  Software Developement Board for DRA7XX
+  compatible = "ti,dra7-evm", "ti,dra7"
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index e5fbfed..92f8dd3 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -201,3 +201,21 @@ DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device Tree)")
 	.dt_compat	= am43_boards_compat,
 MACHINE_END
 #endif
+
+#ifdef CONFIG_SOC_DRA7XX
+static const char *dra7xx_boards_compat[] __initdata = {
+	"ti,dra7",
+	NULL,
+};
+
+DT_MACHINE_START(DRA7XX_DT, "Generic DRA7XX (Flattened Device Tree)")
+	.reserve	= omap_reserve,
+	.smp		= smp_ops(omap4_smp_ops),
+	.map_io		= omap5_map_io,
+	.init_early	= dra7xx_init_early,
+	.init_irq	= omap_gic_of_init,
+	.init_machine	= omap_generic_init,
+	.init_time	= omap5_realtime_timer_init,
+	.dt_compat	= dra7xx_boards_compat,
+MACHINE_END
+#endif
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:27:53 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 12:57:53 +0530
Subject: [PATCH 8/8] ARM: DRA7: Kconfig: Increase the default gpio count
In-Reply-To: <1373354873-12359-1-git-send-email-rnayak@ti.com>
References: <1373354873-12359-1-git-send-email-rnayak@ti.com>
Message-ID: <1373354873-12359-9-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

DRA7xx has 8 GPIO banks so that there are 32x8 = 256 GPIOs.
In order for the gpiolib to detect and initialize these
additional GPIOs and other TWL GPIOs, ARCH_NR_GPIO is set
to 512 instead of present 256.

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ef7af0..9faed52 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1599,7 +1599,7 @@ config LOCAL_TIMERS
 config ARCH_NR_GPIO
 	int
 	default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
-	default 512 if SOC_OMAP5
+	default 512 if SOC_OMAP5 || SOC_DRA7XX
 	default 512 if ARCH_KEYSTONE
 	default 392 if ARCH_U8500
 	default 352 if ARCH_VT8500
-- 
1.7.9.5



From ludovic.desroches at atmel.com  Tue Jul  9 03:31:55 2013
From: ludovic.desroches at atmel.com (Ludovic Desroches)
Date: Tue, 9 Jul 2013 09:31:55 +0200
Subject: [PATCH 1/7] serial: at91: correct definition from DMA to PDC
In-Reply-To: <1373351626-30143-2-git-send-email-elen.song@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
 <1373351626-30143-2-git-send-email-elen.song@atmel.com>
Message-ID: <20130709073155.GB4013@ludovic.desroches@atmel.com>

Hi Elen,

One comment below:

On Tue, Jul 09, 2013 at 02:33:40PM +0800, Elen Song wrote:

[...]

> diff --git a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> index a49d9a1..82f45ec 100644
> --- a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> +++ b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> @@ -8,8 +8,8 @@ Required properties:
>  - interrupts: Should contain interrupt
>  
>  Optional properties:
> -- atmel,use-dma-rx: use of PDC or DMA for receiving data
> -- atmel,use-dma-tx: use of PDC or DMA for transmitting data
> +- atmel,use-pdc-rx: use of PDC for receiving data
> +- atmel,use-pdc-tx: use of PDC for transmitting data
>  
>  <chip> compatible description:
>  - at91rm9200:  legacy USART support
> @@ -19,9 +19,9 @@ Example:
>  
>  	usart0: serial at fff8c000 {
>  		compatible = "atmel,at91sam9260-usart";
> -		reg = <0xfff8c000 0x4000>;
> -		interrupts = <7>;
> -		atmel,use-dma-rx;
> -		atmel,use-dma-tx;
> +		reg = <0xfff8c000 0x200>;
> +		interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;

Maybe put these changes into an other patch since it is not in relation with
the purpose of your patch.

Moreover, I am not sure that macros should be used in the documentation. From
the top of my head, there was a discussion about that and the status was to not
use macros in documentation since it is Linux dependant.

> +		atmel,use-pdc-rx;
> +		atmel,use-pdc-tx;
>  	};
>  

[...]


From rnayak at ti.com  Tue Jul  9 03:32:07 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 13:02:07 +0530
Subject: [PATCH 00/12] DRA7xx PRCM, hwmod and DT data 
Message-ID: <1373355139-12487-1-git-send-email-rnayak@ti.com>

This series adds the data files for DRA7xx devices for
PRCM, hwmod and DT. This is dependent on the core support [1]
patches for DRA7xx and leaves out the clock data since its
on its way to DT [2]

The regbit headers for prm and cm are cleaned up post the
autogeneration as 95% was seen to be currently unused
(prm-regbits-7xx.h was 100% unused and hence removed)

These patches along with the core support patches are available at:
git://github.com/rrnayak/linux.git for-3.12/dra-core-data

[1] http://marc.info/?l=linux-omap&m=137335492102004&w=2

[2] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg91318.html

Ambresh K (7):
  ARM: DRA7: PRM: Add DRA7XX register definitions
  ARM: DRA7: CM: Add DRA7XX register defines
  ARM: DRA7: PRCM: Add DRA7XX local MPU PRCM regsiters
  ARM: DRA7: clockdomain: Add DRA7XX data and update header
  ARM: DRA7: powerdomain: Add DRA7XX data and update header
  ARM: DRA7: hwmod: Create initial DRA7XX SoC data
  ARM: DRA7: Enable PM framework initializations

R Sricharan (2):
  ARM: DRA7: Add the build support in omap2plus
  ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board

Rajendra Nayak (3):
  ARM: DRA7: CM: Add minimal regbit shifts
  ARM: DRA7: powerdomain: Handle missing vc/vp
  ARM: DRA7: Reuse the omap44xx_restart and fix the device instance

 arch/arm/boot/dts/Makefile                 |    3 +-
 arch/arm/boot/dts/dra7-evm.dts             |   20 +
 arch/arm/boot/dts/dra7.dtsi                |  488 +++++
 arch/arm/configs/omap2plus_defconfig       |    1 +
 arch/arm/mach-omap2/Kconfig                |   10 +-
 arch/arm/mach-omap2/Makefile               |    4 +
 arch/arm/mach-omap2/board-generic.c        |    1 +
 arch/arm/mach-omap2/clockdomain.h          |    1 +
 arch/arm/mach-omap2/clockdomains7xx_data.c |  739 ++++++++
 arch/arm/mach-omap2/cm-regbits-7xx.h       |   50 +
 arch/arm/mach-omap2/cm1_7xx.h              |  323 ++++
 arch/arm/mach-omap2/cm2_7xx.h              |  512 ++++++
 arch/arm/mach-omap2/io.c                   |    5 +
 arch/arm/mach-omap2/omap_hwmod.h           |    1 +
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 2724 ++++++++++++++++++++++++++++
 arch/arm/mach-omap2/powerdomain.h          |    1 +
 arch/arm/mach-omap2/powerdomains7xx_data.c |  453 +++++
 arch/arm/mach-omap2/prcm44xx.h             |    5 +
 arch/arm/mach-omap2/prcm_mpu7xx.h          |   77 +
 arch/arm/mach-omap2/prm44xx.c              |   12 +-
 arch/arm/mach-omap2/prm7xx.h               |  677 +++++++
 arch/arm/mach-omap2/prminst44xx.c          |   20 +-
 arch/arm/plat-omap/Kconfig                 |    2 +-
 23 files changed, 6121 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/boot/dts/dra7-evm.dts
 create mode 100644 arch/arm/boot/dts/dra7.dtsi
 create mode 100644 arch/arm/mach-omap2/clockdomains7xx_data.c
 create mode 100644 arch/arm/mach-omap2/cm-regbits-7xx.h
 create mode 100644 arch/arm/mach-omap2/cm1_7xx.h
 create mode 100644 arch/arm/mach-omap2/cm2_7xx.h
 create mode 100644 arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 create mode 100644 arch/arm/mach-omap2/powerdomains7xx_data.c
 create mode 100644 arch/arm/mach-omap2/prcm_mpu7xx.h
 create mode 100644 arch/arm/mach-omap2/prm7xx.h

-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:32:08 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 13:02:08 +0530
Subject: [PATCH 01/12] ARM: DRA7: PRM: Add DRA7XX register definitions
In-Reply-To: <1373355139-12487-1-git-send-email-rnayak@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
Message-ID: <1373355139-12487-2-git-send-email-rnayak@ti.com>

From: Ambresh K <ambresh at ti.com>

Add the new defines for DRA7xx prm module registers.

Signed-off-by: Ambresh K <ambresh at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/prm7xx.h |  677 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 677 insertions(+)
 create mode 100644 arch/arm/mach-omap2/prm7xx.h

diff --git a/arch/arm/mach-omap2/prm7xx.h b/arch/arm/mach-omap2/prm7xx.h
new file mode 100644
index 0000000..6c6db25
--- /dev/null
+++ b/arch/arm/mach-omap2/prm7xx.h
@@ -0,0 +1,677 @@
+/*
+ * DRA7xx PRM instance offset macros
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Paul Walmsley (paul at pwsan.com)
+ * Rajendra Nayak (rnayak at ti.com)
+ * Benoit Cousson (b-cousson at ti.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_PRM7XX_H
+#define __ARCH_ARM_MACH_OMAP2_PRM7XX_H
+
+#include "prm44xx_54xx.h"
+#include "prcm-common.h"
+#include "prm.h"
+
+#define DRA7XX_PRM_BASE		0x4ae06000
+
+#define DRA7XX_PRM_REGADDR(inst, reg)				\
+	OMAP2_L4_IO_ADDRESS(DRA7XX_PRM_BASE + (inst) + (reg))
+
+
+/* PRM instances */
+#define DRA7XX_PRM_OCP_SOCKET_INST	0x0000
+#define DRA7XX_PRM_CKGEN_INST		0x0100
+#define DRA7XX_PRM_MPU_INST		0x0300
+#define DRA7XX_PRM_DSP1_INST		0x0400
+#define DRA7XX_PRM_IPU_INST		0x0500
+#define DRA7XX_PRM_COREAON_INST		0x0628
+#define DRA7XX_PRM_CORE_INST		0x0700
+#define DRA7XX_PRM_IVA_INST		0x0f00
+#define DRA7XX_PRM_CAM_INST		0x1000
+#define DRA7XX_PRM_DSS_INST		0x1100
+#define DRA7XX_PRM_GPU_INST		0x1200
+#define DRA7XX_PRM_L3INIT_INST		0x1300
+#define DRA7XX_PRM_L4PER_INST		0x1400
+#define DRA7XX_PRM_CUSTEFUSE_INST	0x1600
+#define DRA7XX_PRM_WKUPAON_INST		0x1724
+#define DRA7XX_PRM_WKUPAON_CM_INST	0x1800
+#define DRA7XX_PRM_EMU_INST		0x1900
+#define DRA7XX_PRM_EMU_CM_INST		0x1a00
+#define DRA7XX_PRM_DSP2_INST		0x1b00
+#define DRA7XX_PRM_EVE1_INST		0x1b40
+#define DRA7XX_PRM_EVE2_INST		0x1b80
+#define DRA7XX_PRM_EVE3_INST		0x1bc0
+#define DRA7XX_PRM_EVE4_INST		0x1c00
+#define DRA7XX_PRM_RTC_INST		0x1c60
+#define DRA7XX_PRM_VPE_INST		0x1c80
+#define DRA7XX_PRM_DEVICE_INST		0x1d00
+#define DRA7XX_PRM_INSTR_INST		0x1f00
+
+/* PRM clockdomain register offsets (from instance start) */
+#define DRA7XX_PRM_WKUPAON_CM_WKUPAON_CDOFFS	0x0000
+#define DRA7XX_PRM_EMU_CM_EMU_CDOFFS		0x0000
+
+/* PRM */
+
+/* PRM.OCP_SOCKET_PRM register offsets */
+#define DRA7XX_REVISION_PRM_OFFSET				0x0000
+#define DRA7XX_PRM_IRQSTATUS_MPU_OFFSET				0x0010
+#define DRA7XX_PRM_IRQSTATUS_MPU_2_OFFSET			0x0014
+#define DRA7XX_PRM_IRQENABLE_MPU_OFFSET				0x0018
+#define DRA7XX_PRM_IRQENABLE_MPU_2_OFFSET			0x001c
+#define DRA7XX_PRM_IRQSTATUS_IPU2_OFFSET			0x0020
+#define DRA7XX_PRM_IRQENABLE_IPU2_OFFSET			0x0028
+#define DRA7XX_PRM_IRQSTATUS_DSP1_OFFSET			0x0030
+#define DRA7XX_PRM_IRQENABLE_DSP1_OFFSET			0x0038
+#define DRA7XX_CM_PRM_PROFILING_CLKCTRL_OFFSET			0x0040
+#define DRA7XX_CM_PRM_PROFILING_CLKCTRL				DRA7XX_PRM_REGADDR(DRA7XX_PRM_OCP_SOCKET_INST, 0x0040)
+#define DRA7XX_PRM_IRQENABLE_DSP2_OFFSET			0x0044
+#define DRA7XX_PRM_IRQENABLE_EVE1_OFFSET			0x0048
+#define DRA7XX_PRM_IRQENABLE_EVE2_OFFSET			0x004c
+#define DRA7XX_PRM_IRQENABLE_EVE3_OFFSET			0x0050
+#define DRA7XX_PRM_IRQENABLE_EVE4_OFFSET			0x0054
+#define DRA7XX_PRM_IRQENABLE_IPU1_OFFSET			0x0058
+#define DRA7XX_PRM_IRQSTATUS_DSP2_OFFSET			0x005c
+#define DRA7XX_PRM_IRQSTATUS_EVE1_OFFSET			0x0060
+#define DRA7XX_PRM_IRQSTATUS_EVE2_OFFSET			0x0064
+#define DRA7XX_PRM_IRQSTATUS_EVE3_OFFSET			0x0068
+#define DRA7XX_PRM_IRQSTATUS_EVE4_OFFSET			0x006c
+#define DRA7XX_PRM_IRQSTATUS_IPU1_OFFSET			0x0070
+#define DRA7XX_PRM_DEBUG_CFG1_OFFSET				0x00e4
+#define DRA7XX_PRM_DEBUG_CFG2_OFFSET				0x00e8
+#define DRA7XX_PRM_DEBUG_CFG3_OFFSET				0x00ec
+#define DRA7XX_PRM_DEBUG_OUT_OFFSET				0x00f4
+
+/* PRM.CKGEN_PRM register offsets */
+#define DRA7XX_CM_CLKSEL_SYSCLK1_OFFSET				0x0000
+#define DRA7XX_CM_CLKSEL_SYSCLK1				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0000)
+#define DRA7XX_CM_CLKSEL_WKUPAON_OFFSET				0x0008
+#define DRA7XX_CM_CLKSEL_WKUPAON				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0008)
+#define DRA7XX_CM_CLKSEL_ABE_PLL_REF_OFFSET			0x000c
+#define DRA7XX_CM_CLKSEL_ABE_PLL_REF				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x000c)
+#define DRA7XX_CM_CLKSEL_SYS_OFFSET				0x0010
+#define DRA7XX_CM_CLKSEL_SYS					DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0010)
+#define DRA7XX_CM_CLKSEL_ABE_PLL_BYPAS_OFFSET			0x0014
+#define DRA7XX_CM_CLKSEL_ABE_PLL_BYPAS				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0014)
+#define DRA7XX_CM_CLKSEL_ABE_PLL_SYS_OFFSET			0x0018
+#define DRA7XX_CM_CLKSEL_ABE_PLL_SYS				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0018)
+#define DRA7XX_CM_CLKSEL_ABE_24M_OFFSET				0x001c
+#define DRA7XX_CM_CLKSEL_ABE_24M				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x001c)
+#define DRA7XX_CM_CLKSEL_ABE_SYS_OFFSET				0x0020
+#define DRA7XX_CM_CLKSEL_ABE_SYS				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0020)
+#define DRA7XX_CM_CLKSEL_HDMI_MCASP_AUX_OFFSET			0x0024
+#define DRA7XX_CM_CLKSEL_HDMI_MCASP_AUX				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0024)
+#define DRA7XX_CM_CLKSEL_HDMI_TIMER_OFFSET			0x0028
+#define DRA7XX_CM_CLKSEL_HDMI_TIMER				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0028)
+#define DRA7XX_CM_CLKSEL_MCASP_SYS_OFFSET			0x002c
+#define DRA7XX_CM_CLKSEL_MCASP_SYS				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x002c)
+#define DRA7XX_CM_CLKSEL_MLBP_MCASP_OFFSET			0x0030
+#define DRA7XX_CM_CLKSEL_MLBP_MCASP				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0030)
+#define DRA7XX_CM_CLKSEL_MLB_MCASP_OFFSET			0x0034
+#define DRA7XX_CM_CLKSEL_MLB_MCASP				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0034)
+#define DRA7XX_CM_CLKSEL_PER_ABE_X1_GFCLK_MCASP_AUX_OFFSET	0x0038
+#define DRA7XX_CM_CLKSEL_PER_ABE_X1_GFCLK_MCASP_AUX		DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0038)
+#define DRA7XX_CM_CLKSEL_SYS_CLK1_32K_OFFSET			0x0040
+#define DRA7XX_CM_CLKSEL_SYS_CLK1_32K				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0040)
+#define DRA7XX_CM_CLKSEL_TIMER_SYS_OFFSET			0x0044
+#define DRA7XX_CM_CLKSEL_TIMER_SYS				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0044)
+#define DRA7XX_CM_CLKSEL_VIDEO1_MCASP_AUX_OFFSET		0x0048
+#define DRA7XX_CM_CLKSEL_VIDEO1_MCASP_AUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0048)
+#define DRA7XX_CM_CLKSEL_VIDEO1_TIMER_OFFSET			0x004c
+#define DRA7XX_CM_CLKSEL_VIDEO1_TIMER				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x004c)
+#define DRA7XX_CM_CLKSEL_VIDEO2_MCASP_AUX_OFFSET		0x0050
+#define DRA7XX_CM_CLKSEL_VIDEO2_MCASP_AUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0050)
+#define DRA7XX_CM_CLKSEL_VIDEO2_TIMER_OFFSET			0x0054
+#define DRA7XX_CM_CLKSEL_VIDEO2_TIMER				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0054)
+#define DRA7XX_CM_CLKSEL_CLKOUTMUX0_OFFSET			0x0058
+#define DRA7XX_CM_CLKSEL_CLKOUTMUX0				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0058)
+#define DRA7XX_CM_CLKSEL_CLKOUTMUX1_OFFSET			0x005c
+#define DRA7XX_CM_CLKSEL_CLKOUTMUX1				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x005c)
+#define DRA7XX_CM_CLKSEL_CLKOUTMUX2_OFFSET			0x0060
+#define DRA7XX_CM_CLKSEL_CLKOUTMUX2				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0060)
+#define DRA7XX_CM_CLKSEL_HDMI_PLL_SYS_OFFSET			0x0064
+#define DRA7XX_CM_CLKSEL_HDMI_PLL_SYS				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0064)
+#define DRA7XX_CM_CLKSEL_VIDEO1_PLL_SYS_OFFSET			0x0068
+#define DRA7XX_CM_CLKSEL_VIDEO1_PLL_SYS				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0068)
+#define DRA7XX_CM_CLKSEL_VIDEO2_PLL_SYS_OFFSET			0x006c
+#define DRA7XX_CM_CLKSEL_VIDEO2_PLL_SYS				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x006c)
+#define DRA7XX_CM_CLKSEL_ABE_CLK_DIV_OFFSET			0x0070
+#define DRA7XX_CM_CLKSEL_ABE_CLK_DIV				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0070)
+#define DRA7XX_CM_CLKSEL_ABE_GICLK_DIV_OFFSET			0x0074
+#define DRA7XX_CM_CLKSEL_ABE_GICLK_DIV				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0074)
+#define DRA7XX_CM_CLKSEL_AESS_FCLK_DIV_OFFSET			0x0078
+#define DRA7XX_CM_CLKSEL_AESS_FCLK_DIV				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0078)
+#define DRA7XX_CM_CLKSEL_EVE_CLK_OFFSET				0x0080
+#define DRA7XX_CM_CLKSEL_EVE_CLK				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0080)
+#define DRA7XX_CM_CLKSEL_USB_OTG_CLK_CLKOUTMUX_OFFSET		0x0084
+#define DRA7XX_CM_CLKSEL_USB_OTG_CLK_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0084)
+#define DRA7XX_CM_CLKSEL_CORE_DPLL_OUT_CLK_CLKOUTMUX_OFFSET	0x0088
+#define DRA7XX_CM_CLKSEL_CORE_DPLL_OUT_CLK_CLKOUTMUX		DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0088)
+#define DRA7XX_CM_CLKSEL_DSP_GFCLK_CLKOUTMUX_OFFSET		0x008c
+#define DRA7XX_CM_CLKSEL_DSP_GFCLK_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x008c)
+#define DRA7XX_CM_CLKSEL_EMIF_PHY_GCLK_CLKOUTMUX_OFFSET		0x0090
+#define DRA7XX_CM_CLKSEL_EMIF_PHY_GCLK_CLKOUTMUX		DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0090)
+#define DRA7XX_CM_CLKSEL_EMU_CLK_CLKOUTMUX_OFFSET		0x0094
+#define DRA7XX_CM_CLKSEL_EMU_CLK_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0094)
+#define DRA7XX_CM_CLKSEL_FUNC_96M_AON_CLK_CLKOUTMUX_OFFSET	0x0098
+#define DRA7XX_CM_CLKSEL_FUNC_96M_AON_CLK_CLKOUTMUX		DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x0098)
+#define DRA7XX_CM_CLKSEL_GMAC_250M_CLK_CLKOUTMUX_OFFSET		0x009c
+#define DRA7XX_CM_CLKSEL_GMAC_250M_CLK_CLKOUTMUX		DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x009c)
+#define DRA7XX_CM_CLKSEL_GPU_GCLK_CLKOUTMUX_OFFSET		0x00a0
+#define DRA7XX_CM_CLKSEL_GPU_GCLK_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00a0)
+#define DRA7XX_CM_CLKSEL_HDMI_CLK_CLKOUTMUX_OFFSET		0x00a4
+#define DRA7XX_CM_CLKSEL_HDMI_CLK_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00a4)
+#define DRA7XX_CM_CLKSEL_IVA_GCLK_CLKOUTMUX_OFFSET		0x00a8
+#define DRA7XX_CM_CLKSEL_IVA_GCLK_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00a8)
+#define DRA7XX_CM_CLKSEL_L3INIT_480M_GFCLK_CLKOUTMUX_OFFSET	0x00ac
+#define DRA7XX_CM_CLKSEL_L3INIT_480M_GFCLK_CLKOUTMUX		DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00ac)
+#define DRA7XX_CM_CLKSEL_MPU_GCLK_CLKOUTMUX_OFFSET		0x00b0
+#define DRA7XX_CM_CLKSEL_MPU_GCLK_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00b0)
+#define DRA7XX_CM_CLKSEL_PCIE1_CLK_CLKOUTMUX_OFFSET		0x00b4
+#define DRA7XX_CM_CLKSEL_PCIE1_CLK_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00b4)
+#define DRA7XX_CM_CLKSEL_PCIE2_CLK_CLKOUTMUX_OFFSET		0x00b8
+#define DRA7XX_CM_CLKSEL_PCIE2_CLK_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00b8)
+#define DRA7XX_CM_CLKSEL_PER_ABE_X1_CLK_CLKOUTMUX_OFFSET	0x00bc
+#define DRA7XX_CM_CLKSEL_PER_ABE_X1_CLK_CLKOUTMUX		DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00bc)
+#define DRA7XX_CM_CLKSEL_SATA_CLK_CLKOUTMUX_OFFSET		0x00c0
+#define DRA7XX_CM_CLKSEL_SATA_CLK_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00c0)
+#define DRA7XX_CM_CLKSEL_SECURE_32K_CLK_CLKOUTMUX_OFFSET	0x00c4
+#define DRA7XX_CM_CLKSEL_SECURE_32K_CLK_CLKOUTMUX		DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00c4)
+#define DRA7XX_CM_CLKSEL_SYS_CLK1_CLKOUTMUX_OFFSET		0x00c8
+#define DRA7XX_CM_CLKSEL_SYS_CLK1_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00c8)
+#define DRA7XX_CM_CLKSEL_SYS_CLK2_CLKOUTMUX_OFFSET		0x00cc
+#define DRA7XX_CM_CLKSEL_SYS_CLK2_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00cc)
+#define DRA7XX_CM_CLKSEL_VIDEO1_CLK_CLKOUTMUX_OFFSET		0x00d0
+#define DRA7XX_CM_CLKSEL_VIDEO1_CLK_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00d0)
+#define DRA7XX_CM_CLKSEL_VIDEO2_CLK_CLKOUTMUX_OFFSET		0x00d4
+#define DRA7XX_CM_CLKSEL_VIDEO2_CLK_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00d4)
+#define DRA7XX_CM_CLKSEL_ABE_LP_CLK_OFFSET			0x00d8
+#define DRA7XX_CM_CLKSEL_ABE_LP_CLK				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00d8)
+#define DRA7XX_CM_CLKSEL_ADC_GFCLK_OFFSET			0x00dc
+#define DRA7XX_CM_CLKSEL_ADC_GFCLK				DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00dc)
+#define DRA7XX_CM_CLKSEL_EVE_GFCLK_CLKOUTMUX_OFFSET		0x00e0
+#define DRA7XX_CM_CLKSEL_EVE_GFCLK_CLKOUTMUX			DRA7XX_PRM_REGADDR(DRA7XX_PRM_CKGEN_INST, 0x00e0)
+
+/* PRM.MPU_PRM register offsets */
+#define DRA7XX_PM_MPU_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_MPU_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_MPU_MPU_CONTEXT_OFFSET			0x0024
+
+/* PRM.DSP1_PRM register offsets */
+#define DRA7XX_PM_DSP1_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_DSP1_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_DSP1_RSTCTRL_OFFSET				0x0010
+#define DRA7XX_RM_DSP1_RSTST_OFFSET				0x0014
+#define DRA7XX_RM_DSP1_DSP1_CONTEXT_OFFSET			0x0024
+
+/* PRM.IPU_PRM register offsets */
+#define DRA7XX_PM_IPU_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_IPU_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_IPU1_RSTCTRL_OFFSET				0x0010
+#define DRA7XX_RM_IPU1_RSTST_OFFSET				0x0014
+#define DRA7XX_RM_IPU1_IPU1_CONTEXT_OFFSET			0x0024
+#define DRA7XX_PM_IPU_MCASP1_WKDEP_OFFSET			0x0050
+#define DRA7XX_RM_IPU_MCASP1_CONTEXT_OFFSET			0x0054
+#define DRA7XX_PM_IPU_TIMER5_WKDEP_OFFSET			0x0058
+#define DRA7XX_RM_IPU_TIMER5_CONTEXT_OFFSET			0x005c
+#define DRA7XX_PM_IPU_TIMER6_WKDEP_OFFSET			0x0060
+#define DRA7XX_RM_IPU_TIMER6_CONTEXT_OFFSET			0x0064
+#define DRA7XX_PM_IPU_TIMER7_WKDEP_OFFSET			0x0068
+#define DRA7XX_RM_IPU_TIMER7_CONTEXT_OFFSET			0x006c
+#define DRA7XX_PM_IPU_TIMER8_WKDEP_OFFSET			0x0070
+#define DRA7XX_RM_IPU_TIMER8_CONTEXT_OFFSET			0x0074
+#define DRA7XX_PM_IPU_I2C5_WKDEP_OFFSET				0x0078
+#define DRA7XX_RM_IPU_I2C5_CONTEXT_OFFSET			0x007c
+#define DRA7XX_PM_IPU_UART6_WKDEP_OFFSET			0x0080
+#define DRA7XX_RM_IPU_UART6_CONTEXT_OFFSET			0x0084
+
+/* PRM.COREAON_PRM register offsets */
+#define DRA7XX_PM_COREAON_SMARTREFLEX_MPU_WKDEP_OFFSET		0x0000
+#define DRA7XX_RM_COREAON_SMARTREFLEX_MPU_CONTEXT_OFFSET	0x0004
+#define DRA7XX_PM_COREAON_SMARTREFLEX_CORE_WKDEP_OFFSET		0x0010
+#define DRA7XX_RM_COREAON_SMARTREFLEX_CORE_CONTEXT_OFFSET	0x0014
+#define DRA7XX_PM_COREAON_SMARTREFLEX_GPU_WKDEP_OFFSET		0x0030
+#define DRA7XX_RM_COREAON_SMARTREFLEX_GPU_CONTEXT_OFFSET	0x0034
+#define DRA7XX_PM_COREAON_SMARTREFLEX_DSPEVE_WKDEP_OFFSET	0x0040
+#define DRA7XX_RM_COREAON_SMARTREFLEX_DSPEVE_CONTEXT_OFFSET	0x0044
+#define DRA7XX_PM_COREAON_SMARTREFLEX_IVAHD_WKDEP_OFFSET	0x0050
+#define DRA7XX_RM_COREAON_SMARTREFLEX_IVAHD_CONTEXT_OFFSET	0x0054
+#define DRA7XX_RM_COREAON_DUMMY_MODULE1_CONTEXT_OFFSET		0x0084
+#define DRA7XX_RM_COREAON_DUMMY_MODULE2_CONTEXT_OFFSET		0x0094
+#define DRA7XX_RM_COREAON_DUMMY_MODULE3_CONTEXT_OFFSET		0x00a4
+#define DRA7XX_RM_COREAON_DUMMY_MODULE4_CONTEXT_OFFSET		0x00b4
+
+/* PRM.CORE_PRM register offsets */
+#define DRA7XX_PM_CORE_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_CORE_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_L3MAIN1_L3_MAIN_1_CONTEXT_OFFSET		0x0024
+#define DRA7XX_RM_L3MAIN1_GPMC_CONTEXT_OFFSET			0x002c
+#define DRA7XX_RM_L3MAIN1_MMU_EDMA_CONTEXT_OFFSET		0x0034
+#define DRA7XX_PM_L3MAIN1_OCMC_RAM1_WKDEP_OFFSET		0x0050
+#define DRA7XX_RM_L3MAIN1_OCMC_RAM1_CONTEXT_OFFSET		0x0054
+#define DRA7XX_PM_L3MAIN1_OCMC_RAM2_WKDEP_OFFSET		0x0058
+#define DRA7XX_RM_L3MAIN1_OCMC_RAM2_CONTEXT_OFFSET		0x005c
+#define DRA7XX_PM_L3MAIN1_OCMC_RAM3_WKDEP_OFFSET		0x0060
+#define DRA7XX_RM_L3MAIN1_OCMC_RAM3_CONTEXT_OFFSET		0x0064
+#define DRA7XX_RM_L3MAIN1_OCMC_ROM_CONTEXT_OFFSET		0x006c
+#define DRA7XX_PM_L3MAIN1_TPCC_WKDEP_OFFSET			0x0070
+#define DRA7XX_RM_L3MAIN1_TPCC_CONTEXT_OFFSET			0x0074
+#define DRA7XX_PM_L3MAIN1_TPTC1_WKDEP_OFFSET			0x0078
+#define DRA7XX_RM_L3MAIN1_TPTC1_CONTEXT_OFFSET			0x007c
+#define DRA7XX_PM_L3MAIN1_TPTC2_WKDEP_OFFSET			0x0080
+#define DRA7XX_RM_L3MAIN1_TPTC2_CONTEXT_OFFSET			0x0084
+#define DRA7XX_RM_L3MAIN1_VCP1_CONTEXT_OFFSET			0x008c
+#define DRA7XX_RM_L3MAIN1_VCP2_CONTEXT_OFFSET			0x0094
+#define DRA7XX_RM_L3MAIN1_SPARE_CME_CONTEXT_OFFSET		0x009c
+#define DRA7XX_RM_L3MAIN1_SPARE_HDMI_CONTEXT_OFFSET		0x00a4
+#define DRA7XX_RM_L3MAIN1_SPARE_ICM_CONTEXT_OFFSET		0x00ac
+#define DRA7XX_RM_L3MAIN1_SPARE_IVA2_CONTEXT_OFFSET		0x00b4
+#define DRA7XX_RM_L3MAIN1_SPARE_SATA2_CONTEXT_OFFSET		0x00bc
+#define DRA7XX_RM_L3MAIN1_SPARE_UNKNOWN4_CONTEXT_OFFSET		0x00c4
+#define DRA7XX_RM_L3MAIN1_SPARE_UNKNOWN5_CONTEXT_OFFSET		0x00cc
+#define DRA7XX_RM_L3MAIN1_SPARE_UNKNOWN6_CONTEXT_OFFSET		0x00d4
+#define DRA7XX_RM_L3MAIN1_SPARE_VIDEOPLL1_CONTEXT_OFFSET	0x00dc
+#define DRA7XX_RM_L3MAIN1_SPARE_VIDEOPLL2_CONTEXT_OFFSET	0x00f4
+#define DRA7XX_RM_L3MAIN1_SPARE_VIDEOPLL3_CONTEXT_OFFSET	0x00fc
+#define DRA7XX_RM_IPU2_RSTCTRL_OFFSET				0x0210
+#define DRA7XX_RM_IPU2_RSTST_OFFSET				0x0214
+#define DRA7XX_RM_IPU2_IPU2_CONTEXT_OFFSET			0x0224
+#define DRA7XX_RM_DMA_DMA_SYSTEM_CONTEXT_OFFSET			0x0324
+#define DRA7XX_RM_EMIF_DMM_CONTEXT_OFFSET			0x0424
+#define DRA7XX_RM_EMIF_EMIF_OCP_FW_CONTEXT_OFFSET		0x042c
+#define DRA7XX_RM_EMIF_EMIF1_CONTEXT_OFFSET			0x0434
+#define DRA7XX_RM_EMIF_EMIF2_CONTEXT_OFFSET			0x043c
+#define DRA7XX_RM_EMIF_EMIF_DLL_CONTEXT_OFFSET			0x0444
+#define DRA7XX_RM_ATL_ATL_CONTEXT_OFFSET			0x0524
+#define DRA7XX_RM_L4CFG_L4_CFG_CONTEXT_OFFSET			0x0624
+#define DRA7XX_RM_L4CFG_SPINLOCK_CONTEXT_OFFSET			0x062c
+#define DRA7XX_RM_L4CFG_MAILBOX1_CONTEXT_OFFSET			0x0634
+#define DRA7XX_RM_L4CFG_SAR_ROM_CONTEXT_OFFSET			0x063c
+#define DRA7XX_RM_L4CFG_OCP2SCP2_CONTEXT_OFFSET			0x0644
+#define DRA7XX_RM_L4CFG_MAILBOX2_CONTEXT_OFFSET			0x064c
+#define DRA7XX_RM_L4CFG_MAILBOX3_CONTEXT_OFFSET			0x0654
+#define DRA7XX_RM_L4CFG_MAILBOX4_CONTEXT_OFFSET			0x065c
+#define DRA7XX_RM_L4CFG_MAILBOX5_CONTEXT_OFFSET			0x0664
+#define DRA7XX_RM_L4CFG_MAILBOX6_CONTEXT_OFFSET			0x066c
+#define DRA7XX_RM_L4CFG_MAILBOX7_CONTEXT_OFFSET			0x0674
+#define DRA7XX_RM_L4CFG_MAILBOX8_CONTEXT_OFFSET			0x067c
+#define DRA7XX_RM_L4CFG_MAILBOX9_CONTEXT_OFFSET			0x0684
+#define DRA7XX_RM_L4CFG_MAILBOX10_CONTEXT_OFFSET		0x068c
+#define DRA7XX_RM_L4CFG_MAILBOX11_CONTEXT_OFFSET		0x0694
+#define DRA7XX_RM_L4CFG_MAILBOX12_CONTEXT_OFFSET		0x069c
+#define DRA7XX_RM_L4CFG_MAILBOX13_CONTEXT_OFFSET		0x06a4
+#define DRA7XX_RM_L4CFG_SPARE_SMARTREFLEX_RTC_CONTEXT_OFFSET	0x06ac
+#define DRA7XX_RM_L4CFG_SPARE_SMARTREFLEX_SDRAM_CONTEXT_OFFSET	0x06b4
+#define DRA7XX_RM_L4CFG_SPARE_SMARTREFLEX_WKUP_CONTEXT_OFFSET	0x06bc
+#define DRA7XX_RM_L4CFG_IO_DELAY_BLOCK_CONTEXT_OFFSET		0x06c4
+#define DRA7XX_RM_L3INSTR_L3_MAIN_2_CONTEXT_OFFSET		0x0724
+#define DRA7XX_RM_L3INSTR_L3_INSTR_CONTEXT_OFFSET		0x072c
+#define DRA7XX_RM_L3INSTR_OCP_WP_NOC_CONTEXT_OFFSET		0x0744
+
+/* PRM.IVA_PRM register offsets */
+#define DRA7XX_PM_IVA_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_IVA_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_IVA_RSTCTRL_OFFSET				0x0010
+#define DRA7XX_RM_IVA_RSTST_OFFSET				0x0014
+#define DRA7XX_RM_IVA_IVA_CONTEXT_OFFSET			0x0024
+#define DRA7XX_RM_IVA_SL2_CONTEXT_OFFSET			0x002c
+
+/* PRM.CAM_PRM register offsets */
+#define DRA7XX_PM_CAM_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_CAM_PWRSTST_OFFSET				0x0004
+#define DRA7XX_PM_CAM_VIP1_WKDEP_OFFSET				0x0020
+#define DRA7XX_RM_CAM_VIP1_CONTEXT_OFFSET			0x0024
+#define DRA7XX_PM_CAM_VIP2_WKDEP_OFFSET				0x0028
+#define DRA7XX_RM_CAM_VIP2_CONTEXT_OFFSET			0x002c
+#define DRA7XX_PM_CAM_VIP3_WKDEP_OFFSET				0x0030
+#define DRA7XX_RM_CAM_VIP3_CONTEXT_OFFSET			0x0034
+#define DRA7XX_RM_CAM_LVDSRX_CONTEXT_OFFSET			0x003c
+#define DRA7XX_RM_CAM_CSI1_CONTEXT_OFFSET			0x0044
+#define DRA7XX_RM_CAM_CSI2_CONTEXT_OFFSET			0x004c
+
+/* PRM.DSS_PRM register offsets */
+#define DRA7XX_PM_DSS_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_DSS_PWRSTST_OFFSET				0x0004
+#define DRA7XX_PM_DSS_DSS_WKDEP_OFFSET				0x0020
+#define DRA7XX_RM_DSS_DSS_CONTEXT_OFFSET			0x0024
+#define DRA7XX_PM_DSS_DSS2_WKDEP_OFFSET				0x0028
+#define DRA7XX_RM_DSS_BB2D_CONTEXT_OFFSET			0x0034
+#define DRA7XX_RM_DSS_SDVENC_CONTEXT_OFFSET			0x003c
+
+/* PRM.GPU_PRM register offsets */
+#define DRA7XX_PM_GPU_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_GPU_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_GPU_GPU_CONTEXT_OFFSET			0x0024
+
+/* PRM.L3INIT_PRM register offsets */
+#define DRA7XX_PM_L3INIT_PWRSTCTRL_OFFSET			0x0000
+#define DRA7XX_PM_L3INIT_PWRSTST_OFFSET				0x0004
+#define DRA7XX_PM_L3INIT_MMC1_WKDEP_OFFSET			0x0028
+#define DRA7XX_RM_L3INIT_MMC1_CONTEXT_OFFSET			0x002c
+#define DRA7XX_PM_L3INIT_MMC2_WKDEP_OFFSET			0x0030
+#define DRA7XX_RM_L3INIT_MMC2_CONTEXT_OFFSET			0x0034
+#define DRA7XX_PM_L3INIT_USB_OTG_SS2_WKDEP_OFFSET		0x0040
+#define DRA7XX_RM_L3INIT_USB_OTG_SS2_CONTEXT_OFFSET		0x0044
+#define DRA7XX_PM_L3INIT_USB_OTG_SS3_WKDEP_OFFSET		0x0048
+#define DRA7XX_RM_L3INIT_USB_OTG_SS3_CONTEXT_OFFSET		0x004c
+#define DRA7XX_PM_L3INIT_USB_OTG_SS4_WKDEP_OFFSET		0x0050
+#define DRA7XX_RM_L3INIT_USB_OTG_SS4_CONTEXT_OFFSET		0x0054
+#define DRA7XX_RM_L3INIT_MLB_SS_CONTEXT_OFFSET			0x005c
+#define DRA7XX_RM_L3INIT_IEEE1500_2_OCP_CONTEXT_OFFSET		0x007c
+#define DRA7XX_PM_L3INIT_SATA_WKDEP_OFFSET			0x0088
+#define DRA7XX_RM_L3INIT_SATA_CONTEXT_OFFSET			0x008c
+#define DRA7XX_RM_GMAC_GMAC_CONTEXT_OFFSET			0x00d4
+#define DRA7XX_RM_L3INIT_OCP2SCP1_CONTEXT_OFFSET		0x00e4
+#define DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET		0x00ec
+#define DRA7XX_PM_L3INIT_USB_OTG_SS1_WKDEP_OFFSET		0x00f0
+#define DRA7XX_RM_L3INIT_USB_OTG_SS1_CONTEXT_OFFSET		0x00f4
+
+/* PRM.L4PER_PRM register offsets */
+#define DRA7XX_PM_L4PER_PWRSTCTRL_OFFSET			0x0000
+#define DRA7XX_PM_L4PER_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_L4PER2_L4PER2_CONTEXT_OFFSET			0x000c
+#define DRA7XX_RM_L4PER3_L4PER3_CONTEXT_OFFSET			0x0014
+#define DRA7XX_RM_L4PER2_PRUSS1_CONTEXT_OFFSET			0x001c
+#define DRA7XX_RM_L4PER2_PRUSS2_CONTEXT_OFFSET			0x0024
+#define DRA7XX_PM_L4PER_TIMER10_WKDEP_OFFSET			0x0028
+#define DRA7XX_RM_L4PER_TIMER10_CONTEXT_OFFSET			0x002c
+#define DRA7XX_PM_L4PER_TIMER11_WKDEP_OFFSET			0x0030
+#define DRA7XX_RM_L4PER_TIMER11_CONTEXT_OFFSET			0x0034
+#define DRA7XX_PM_L4PER_TIMER2_WKDEP_OFFSET			0x0038
+#define DRA7XX_RM_L4PER_TIMER2_CONTEXT_OFFSET			0x003c
+#define DRA7XX_PM_L4PER_TIMER3_WKDEP_OFFSET			0x0040
+#define DRA7XX_RM_L4PER_TIMER3_CONTEXT_OFFSET			0x0044
+#define DRA7XX_PM_L4PER_TIMER4_WKDEP_OFFSET			0x0048
+#define DRA7XX_RM_L4PER_TIMER4_CONTEXT_OFFSET			0x004c
+#define DRA7XX_PM_L4PER_TIMER9_WKDEP_OFFSET			0x0050
+#define DRA7XX_RM_L4PER_TIMER9_CONTEXT_OFFSET			0x0054
+#define DRA7XX_RM_L4PER_ELM_CONTEXT_OFFSET			0x005c
+#define DRA7XX_PM_L4PER_GPIO2_WKDEP_OFFSET			0x0060
+#define DRA7XX_RM_L4PER_GPIO2_CONTEXT_OFFSET			0x0064
+#define DRA7XX_PM_L4PER_GPIO3_WKDEP_OFFSET			0x0068
+#define DRA7XX_RM_L4PER_GPIO3_CONTEXT_OFFSET			0x006c
+#define DRA7XX_PM_L4PER_GPIO4_WKDEP_OFFSET			0x0070
+#define DRA7XX_RM_L4PER_GPIO4_CONTEXT_OFFSET			0x0074
+#define DRA7XX_PM_L4PER_GPIO5_WKDEP_OFFSET			0x0078
+#define DRA7XX_RM_L4PER_GPIO5_CONTEXT_OFFSET			0x007c
+#define DRA7XX_PM_L4PER_GPIO6_WKDEP_OFFSET			0x0080
+#define DRA7XX_RM_L4PER_GPIO6_CONTEXT_OFFSET			0x0084
+#define DRA7XX_RM_L4PER_HDQ1W_CONTEXT_OFFSET			0x008c
+#define DRA7XX_RM_L4PER2_PWMSS2_CONTEXT_OFFSET			0x0094
+#define DRA7XX_RM_L4PER2_PWMSS3_CONTEXT_OFFSET			0x009c
+#define DRA7XX_PM_L4PER_I2C1_WKDEP_OFFSET			0x00a0
+#define DRA7XX_RM_L4PER_I2C1_CONTEXT_OFFSET			0x00a4
+#define DRA7XX_PM_L4PER_I2C2_WKDEP_OFFSET			0x00a8
+#define DRA7XX_RM_L4PER_I2C2_CONTEXT_OFFSET			0x00ac
+#define DRA7XX_PM_L4PER_I2C3_WKDEP_OFFSET			0x00b0
+#define DRA7XX_RM_L4PER_I2C3_CONTEXT_OFFSET			0x00b4
+#define DRA7XX_PM_L4PER_I2C4_WKDEP_OFFSET			0x00b8
+#define DRA7XX_RM_L4PER_I2C4_CONTEXT_OFFSET			0x00bc
+#define DRA7XX_RM_L4PER_L4PER1_CONTEXT_OFFSET			0x00c0
+#define DRA7XX_RM_L4PER2_PWMSS1_CONTEXT_OFFSET			0x00c4
+#define DRA7XX_PM_L4PER_TIMER13_WKDEP_OFFSET			0x00c8
+#define DRA7XX_RM_L4PER3_TIMER13_CONTEXT_OFFSET			0x00cc
+#define DRA7XX_PM_L4PER_TIMER14_WKDEP_OFFSET			0x00d0
+#define DRA7XX_RM_L4PER3_TIMER14_CONTEXT_OFFSET			0x00d4
+#define DRA7XX_PM_L4PER_TIMER15_WKDEP_OFFSET			0x00d8
+#define DRA7XX_RM_L4PER3_TIMER15_CONTEXT_OFFSET			0x00dc
+#define DRA7XX_PM_L4PER_MCSPI1_WKDEP_OFFSET			0x00f0
+#define DRA7XX_RM_L4PER_MCSPI1_CONTEXT_OFFSET			0x00f4
+#define DRA7XX_PM_L4PER_MCSPI2_WKDEP_OFFSET			0x00f8
+#define DRA7XX_RM_L4PER_MCSPI2_CONTEXT_OFFSET			0x00fc
+#define DRA7XX_PM_L4PER_MCSPI3_WKDEP_OFFSET			0x0100
+#define DRA7XX_RM_L4PER_MCSPI3_CONTEXT_OFFSET			0x0104
+#define DRA7XX_PM_L4PER_MCSPI4_WKDEP_OFFSET			0x0108
+#define DRA7XX_RM_L4PER_MCSPI4_CONTEXT_OFFSET			0x010c
+#define DRA7XX_PM_L4PER_GPIO7_WKDEP_OFFSET			0x0110
+#define DRA7XX_RM_L4PER_GPIO7_CONTEXT_OFFSET			0x0114
+#define DRA7XX_PM_L4PER_GPIO8_WKDEP_OFFSET			0x0118
+#define DRA7XX_RM_L4PER_GPIO8_CONTEXT_OFFSET			0x011c
+#define DRA7XX_PM_L4PER_MMC3_WKDEP_OFFSET			0x0120
+#define DRA7XX_RM_L4PER_MMC3_CONTEXT_OFFSET			0x0124
+#define DRA7XX_PM_L4PER_MMC4_WKDEP_OFFSET			0x0128
+#define DRA7XX_RM_L4PER_MMC4_CONTEXT_OFFSET			0x012c
+#define DRA7XX_PM_L4PER_TIMER16_WKDEP_OFFSET			0x0130
+#define DRA7XX_RM_L4PER3_TIMER16_CONTEXT_OFFSET			0x0134
+#define DRA7XX_PM_L4PER2_QSPI_WKDEP_OFFSET			0x0138
+#define DRA7XX_RM_L4PER2_QSPI_CONTEXT_OFFSET			0x013c
+#define DRA7XX_PM_L4PER_UART1_WKDEP_OFFSET			0x0140
+#define DRA7XX_RM_L4PER_UART1_CONTEXT_OFFSET			0x0144
+#define DRA7XX_PM_L4PER_UART2_WKDEP_OFFSET			0x0148
+#define DRA7XX_RM_L4PER_UART2_CONTEXT_OFFSET			0x014c
+#define DRA7XX_PM_L4PER_UART3_WKDEP_OFFSET			0x0150
+#define DRA7XX_RM_L4PER_UART3_CONTEXT_OFFSET			0x0154
+#define DRA7XX_PM_L4PER_UART4_WKDEP_OFFSET			0x0158
+#define DRA7XX_RM_L4PER_UART4_CONTEXT_OFFSET			0x015c
+#define DRA7XX_PM_L4PER2_MCASP2_WKDEP_OFFSET			0x0160
+#define DRA7XX_RM_L4PER2_MCASP2_CONTEXT_OFFSET			0x0164
+#define DRA7XX_PM_L4PER2_MCASP3_WKDEP_OFFSET			0x0168
+#define DRA7XX_RM_L4PER2_MCASP3_CONTEXT_OFFSET			0x016c
+#define DRA7XX_PM_L4PER_UART5_WKDEP_OFFSET			0x0170
+#define DRA7XX_RM_L4PER_UART5_CONTEXT_OFFSET			0x0174
+#define DRA7XX_PM_L4PER2_MCASP5_WKDEP_OFFSET			0x0178
+#define DRA7XX_RM_L4PER2_MCASP5_CONTEXT_OFFSET			0x017c
+#define DRA7XX_PM_L4PER2_MCASP6_WKDEP_OFFSET			0x0180
+#define DRA7XX_RM_L4PER2_MCASP6_CONTEXT_OFFSET			0x0184
+#define DRA7XX_PM_L4PER2_MCASP7_WKDEP_OFFSET			0x0188
+#define DRA7XX_RM_L4PER2_MCASP7_CONTEXT_OFFSET			0x018c
+#define DRA7XX_PM_L4PER2_MCASP8_WKDEP_OFFSET			0x0190
+#define DRA7XX_RM_L4PER2_MCASP8_CONTEXT_OFFSET			0x0194
+#define DRA7XX_PM_L4PER2_MCASP4_WKDEP_OFFSET			0x0198
+#define DRA7XX_RM_L4PER2_MCASP4_CONTEXT_OFFSET			0x019c
+#define DRA7XX_RM_L4SEC_AES1_CONTEXT_OFFSET			0x01a4
+#define DRA7XX_RM_L4SEC_AES2_CONTEXT_OFFSET			0x01ac
+#define DRA7XX_RM_L4SEC_DES3DES_CONTEXT_OFFSET			0x01b4
+#define DRA7XX_RM_L4SEC_FPKA_CONTEXT_OFFSET			0x01bc
+#define DRA7XX_RM_L4SEC_RNG_CONTEXT_OFFSET			0x01c4
+#define DRA7XX_RM_L4SEC_SHA2MD51_CONTEXT_OFFSET			0x01cc
+#define DRA7XX_PM_L4PER2_UART7_WKDEP_OFFSET			0x01d0
+#define DRA7XX_RM_L4PER2_UART7_CONTEXT_OFFSET			0x01d4
+#define DRA7XX_RM_L4SEC_DMA_CRYPTO_CONTEXT_OFFSET		0x01dc
+#define DRA7XX_PM_L4PER2_UART8_WKDEP_OFFSET			0x01e0
+#define DRA7XX_RM_L4PER2_UART8_CONTEXT_OFFSET			0x01e4
+#define DRA7XX_PM_L4PER2_UART9_WKDEP_OFFSET			0x01e8
+#define DRA7XX_RM_L4PER2_UART9_CONTEXT_OFFSET			0x01ec
+#define DRA7XX_PM_L4PER2_DCAN2_WKDEP_OFFSET			0x01f0
+#define DRA7XX_RM_L4PER2_DCAN2_CONTEXT_OFFSET			0x01f4
+#define DRA7XX_RM_L4SEC_SHA2MD52_CONTEXT_OFFSET			0x01fc
+
+/* PRM.CUSTEFUSE_PRM register offsets */
+#define DRA7XX_PM_CUSTEFUSE_PWRSTCTRL_OFFSET			0x0000
+#define DRA7XX_PM_CUSTEFUSE_PWRSTST_OFFSET			0x0004
+#define DRA7XX_RM_CUSTEFUSE_EFUSE_CTRL_CUST_CONTEXT_OFFSET	0x0024
+
+/* PRM.WKUPAON_PRM register offsets */
+#define DRA7XX_RM_WKUPAON_L4_WKUP_CONTEXT_OFFSET		0x0000
+#define DRA7XX_PM_WKUPAON_WD_TIMER1_WKDEP_OFFSET		0x0004
+#define DRA7XX_RM_WKUPAON_WD_TIMER1_CONTEXT_OFFSET		0x0008
+#define DRA7XX_PM_WKUPAON_WD_TIMER2_WKDEP_OFFSET		0x000c
+#define DRA7XX_RM_WKUPAON_WD_TIMER2_CONTEXT_OFFSET		0x0010
+#define DRA7XX_PM_WKUPAON_GPIO1_WKDEP_OFFSET			0x0014
+#define DRA7XX_RM_WKUPAON_GPIO1_CONTEXT_OFFSET			0x0018
+#define DRA7XX_PM_WKUPAON_TIMER1_WKDEP_OFFSET			0x001c
+#define DRA7XX_RM_WKUPAON_TIMER1_CONTEXT_OFFSET			0x0020
+#define DRA7XX_PM_WKUPAON_TIMER12_WKDEP_OFFSET			0x0024
+#define DRA7XX_RM_WKUPAON_TIMER12_CONTEXT_OFFSET		0x0028
+#define DRA7XX_RM_WKUPAON_COUNTER_32K_CONTEXT_OFFSET		0x0030
+#define DRA7XX_RM_WKUPAON_SAR_RAM_CONTEXT_OFFSET		0x0040
+#define DRA7XX_PM_WKUPAON_KBD_WKDEP_OFFSET			0x0054
+#define DRA7XX_RM_WKUPAON_KBD_CONTEXT_OFFSET			0x0058
+#define DRA7XX_PM_WKUPAON_UART10_WKDEP_OFFSET			0x005c
+#define DRA7XX_RM_WKUPAON_UART10_CONTEXT_OFFSET			0x0060
+#define DRA7XX_PM_WKUPAON_DCAN1_WKDEP_OFFSET			0x0064
+#define DRA7XX_RM_WKUPAON_DCAN1_CONTEXT_OFFSET			0x0068
+#define DRA7XX_PM_WKUPAON_ADC_WKDEP_OFFSET				0x007c
+#define DRA7XX_RM_WKUPAON_ADC_CONTEXT_OFFSET			0x0080
+#define DRA7XX_RM_WKUPAON_SPARE_SAFETY1_CONTEXT_OFFSET		0x0090
+#define DRA7XX_RM_WKUPAON_SPARE_SAFETY2_CONTEXT_OFFSET		0x0098
+#define DRA7XX_RM_WKUPAON_SPARE_SAFETY3_CONTEXT_OFFSET		0x00a0
+#define DRA7XX_RM_WKUPAON_SPARE_SAFETY4_CONTEXT_OFFSET		0x00a8
+#define DRA7XX_RM_WKUPAON_SPARE_UNKNOWN2_CONTEXT_OFFSET		0x00b0
+#define DRA7XX_RM_WKUPAON_SPARE_UNKNOWN3_CONTEXT_OFFSET		0x00b8
+
+/* PRM.WKUPAON_CM register offsets */
+#define DRA7XX_CM_WKUPAON_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_WKUPAON_L4_WKUP_CLKCTRL_OFFSET		0x0020
+#define DRA7XX_CM_WKUPAON_L4_WKUP_CLKCTRL			DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x0020)
+#define DRA7XX_CM_WKUPAON_WD_TIMER1_CLKCTRL_OFFSET		0x0028
+#define DRA7XX_CM_WKUPAON_WD_TIMER1_CLKCTRL			DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x0028)
+#define DRA7XX_CM_WKUPAON_WD_TIMER2_CLKCTRL_OFFSET		0x0030
+#define DRA7XX_CM_WKUPAON_WD_TIMER2_CLKCTRL			DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x0030)
+#define DRA7XX_CM_WKUPAON_GPIO1_CLKCTRL_OFFSET			0x0038
+#define DRA7XX_CM_WKUPAON_GPIO1_CLKCTRL				DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x0038)
+#define DRA7XX_CM_WKUPAON_TIMER1_CLKCTRL_OFFSET			0x0040
+#define DRA7XX_CM_WKUPAON_TIMER1_CLKCTRL			DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x0040)
+#define DRA7XX_CM_WKUPAON_TIMER12_CLKCTRL_OFFSET		0x0048
+#define DRA7XX_CM_WKUPAON_TIMER12_CLKCTRL			DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x0048)
+#define DRA7XX_CM_WKUPAON_COUNTER_32K_CLKCTRL_OFFSET		0x0050
+#define DRA7XX_CM_WKUPAON_COUNTER_32K_CLKCTRL			DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x0050)
+#define DRA7XX_CM_WKUPAON_SAR_RAM_CLKCTRL_OFFSET		0x0060
+#define DRA7XX_CM_WKUPAON_SAR_RAM_CLKCTRL			DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x0060)
+#define DRA7XX_CM_WKUPAON_KBD_CLKCTRL_OFFSET			0x0078
+#define DRA7XX_CM_WKUPAON_KBD_CLKCTRL				DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x0078)
+#define DRA7XX_CM_WKUPAON_UART10_CLKCTRL_OFFSET			0x0080
+#define DRA7XX_CM_WKUPAON_UART10_CLKCTRL			DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x0080)
+#define DRA7XX_CM_WKUPAON_DCAN1_CLKCTRL_OFFSET			0x0088
+#define DRA7XX_CM_WKUPAON_DCAN1_CLKCTRL				DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x0088)
+#define DRA7XX_CM_WKUPAON_SCRM_CLKCTRL_OFFSET			0x0090
+#define DRA7XX_CM_WKUPAON_SCRM_CLKCTRL				DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x0090)
+#define DRA7XX_CM_WKUPAON_IO_SRCOMP_CLKCTRL_OFFSET		0x0098
+#define DRA7XX_CM_WKUPAON_IO_SRCOMP_CLKCTRL			DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x0098)
+#define DRA7XX_CM_WKUPAON_ADC_CLKCTRL_OFFSET			0x00a0
+#define DRA7XX_CM_WKUPAON_ADC_CLKCTRL				DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x00a0)
+#define DRA7XX_CM_WKUPAON_SPARE_SAFETY1_CLKCTRL_OFFSET		0x00b0
+#define DRA7XX_CM_WKUPAON_SPARE_SAFETY1_CLKCTRL			DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x00b0)
+#define DRA7XX_CM_WKUPAON_SPARE_SAFETY2_CLKCTRL_OFFSET		0x00b8
+#define DRA7XX_CM_WKUPAON_SPARE_SAFETY2_CLKCTRL			DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x00b8)
+#define DRA7XX_CM_WKUPAON_SPARE_SAFETY3_CLKCTRL_OFFSET		0x00c0
+#define DRA7XX_CM_WKUPAON_SPARE_SAFETY3_CLKCTRL			DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x00c0)
+#define DRA7XX_CM_WKUPAON_SPARE_SAFETY4_CLKCTRL_OFFSET		0x00c8
+#define DRA7XX_CM_WKUPAON_SPARE_SAFETY4_CLKCTRL			DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x00c8)
+#define DRA7XX_CM_WKUPAON_SPARE_UNKNOWN2_CLKCTRL_OFFSET		0x00d0
+#define DRA7XX_CM_WKUPAON_SPARE_UNKNOWN2_CLKCTRL		DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x00d0)
+#define DRA7XX_CM_WKUPAON_SPARE_UNKNOWN3_CLKCTRL_OFFSET		0x00d8
+#define DRA7XX_CM_WKUPAON_SPARE_UNKNOWN3_CLKCTRL		DRA7XX_PRM_REGADDR(DRA7XX_PRM_WKUPAON_CM_INST, 0x00d8)
+
+/* PRM.EMU_PRM register offsets */
+#define DRA7XX_PM_EMU_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_EMU_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_EMU_DEBUGSS_CONTEXT_OFFSET			0x0024
+
+/* PRM.EMU_CM register offsets */
+#define DRA7XX_CM_EMU_CLKSTCTRL_OFFSET				0x0000
+#define DRA7XX_CM_EMU_DEBUGSS_CLKCTRL_OFFSET			0x0004
+#define DRA7XX_CM_EMU_DEBUGSS_CLKCTRL				DRA7XX_PRM_REGADDR(DRA7XX_PRM_EMU_CM_INST, 0x0004)
+#define DRA7XX_CM_EMU_DYNAMICDEP_OFFSET				0x0008
+#define DRA7XX_CM_EMU_MPU_EMU_DBG_CLKCTRL_OFFSET		0x000c
+#define DRA7XX_CM_EMU_MPU_EMU_DBG_CLKCTRL			DRA7XX_PRM_REGADDR(DRA7XX_PRM_EMU_CM_INST, 0x000c)
+
+/* PRM.DSP2_PRM register offsets */
+#define DRA7XX_PM_DSP2_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_DSP2_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_DSP2_RSTCTRL_OFFSET				0x0010
+#define DRA7XX_RM_DSP2_RSTST_OFFSET				0x0014
+#define DRA7XX_RM_DSP2_DSP2_CONTEXT_OFFSET			0x0024
+
+/* PRM.EVE1_PRM register offsets */
+#define DRA7XX_PM_EVE1_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_EVE1_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_EVE1_RSTCTRL_OFFSET				0x0010
+#define DRA7XX_RM_EVE1_RSTST_OFFSET				0x0014
+#define DRA7XX_PM_EVE1_EVE1_WKDEP_OFFSET			0x0020
+#define DRA7XX_RM_EVE1_EVE1_CONTEXT_OFFSET			0x0024
+
+/* PRM.EVE2_PRM register offsets */
+#define DRA7XX_PM_EVE2_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_EVE2_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_EVE2_RSTCTRL_OFFSET				0x0010
+#define DRA7XX_RM_EVE2_RSTST_OFFSET				0x0014
+#define DRA7XX_PM_EVE2_EVE2_WKDEP_OFFSET			0x0020
+#define DRA7XX_RM_EVE2_EVE2_CONTEXT_OFFSET			0x0024
+
+/* PRM.EVE3_PRM register offsets */
+#define DRA7XX_PM_EVE3_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_EVE3_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_EVE3_RSTCTRL_OFFSET				0x0010
+#define DRA7XX_RM_EVE3_RSTST_OFFSET				0x0014
+#define DRA7XX_PM_EVE3_EVE3_WKDEP_OFFSET			0x0020
+#define DRA7XX_RM_EVE3_EVE3_CONTEXT_OFFSET			0x0024
+
+/* PRM.EVE4_PRM register offsets */
+#define DRA7XX_PM_EVE4_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_EVE4_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_EVE4_RSTCTRL_OFFSET				0x0010
+#define DRA7XX_RM_EVE4_RSTST_OFFSET				0x0014
+#define DRA7XX_PM_EVE4_EVE4_WKDEP_OFFSET			0x0020
+#define DRA7XX_RM_EVE4_EVE4_CONTEXT_OFFSET			0x0024
+
+/* PRM.RTC_PRM register offsets */
+#define DRA7XX_PM_RTC_RTCSS_WKDEP_OFFSET			0x0000
+#define DRA7XX_RM_RTC_RTCSS_CONTEXT_OFFSET			0x0004
+
+/* PRM.VPE_PRM register offsets */
+#define DRA7XX_PM_VPE_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_VPE_PWRSTST_OFFSET				0x0004
+#define DRA7XX_PM_VPE_VPE_WKDEP_OFFSET				0x0020
+#define DRA7XX_RM_VPE_VPE_CONTEXT_OFFSET			0x0024
+
+/* PRM.DEVICE_PRM register offsets */
+#define DRA7XX_PRM_RSTCTRL_OFFSET				0x0000
+#define DRA7XX_PRM_RSTST_OFFSET					0x0004
+#define DRA7XX_PRM_RSTTIME_OFFSET				0x0008
+#define DRA7XX_PRM_CLKREQCTRL_OFFSET				0x000c
+#define DRA7XX_PRM_VOLTCTRL_OFFSET				0x0010
+#define DRA7XX_PRM_PWRREQCTRL_OFFSET				0x0014
+#define DRA7XX_PRM_PSCON_COUNT_OFFSET				0x0018
+#define DRA7XX_PRM_IO_COUNT_OFFSET				0x001c
+#define DRA7XX_PRM_IO_PMCTRL_OFFSET				0x0020
+#define DRA7XX_PRM_VOLTSETUP_WARMRESET_OFFSET			0x0024
+#define DRA7XX_PRM_VOLTSETUP_CORE_OFF_OFFSET			0x0028
+#define DRA7XX_PRM_VOLTSETUP_MPU_OFF_OFFSET			0x002c
+#define DRA7XX_PRM_VOLTSETUP_MM_OFF_OFFSET			0x0030
+#define DRA7XX_PRM_VOLTSETUP_CORE_RET_SLEEP_OFFSET		0x0034
+#define DRA7XX_PRM_VOLTSETUP_MPU_RET_SLEEP_OFFSET		0x0038
+#define DRA7XX_PRM_VOLTSETUP_MM_RET_SLEEP_OFFSET		0x003c
+#define DRA7XX_PRM_SRAM_COUNT_OFFSET				0x00bc
+#define DRA7XX_PRM_SRAM_WKUP_SETUP_OFFSET			0x00c0
+#define DRA7XX_PRM_SLDO_CORE_SETUP_OFFSET			0x00c4
+#define DRA7XX_PRM_SLDO_CORE_CTRL_OFFSET			0x00c8
+#define DRA7XX_PRM_SLDO_MPU_SETUP_OFFSET			0x00cc
+#define DRA7XX_PRM_SLDO_MPU_CTRL_OFFSET				0x00d0
+#define DRA7XX_PRM_SLDO_GPU_SETUP_OFFSET			0x00d4
+#define DRA7XX_PRM_SLDO_GPU_CTRL_OFFSET				0x00d8
+#define DRA7XX_PRM_ABBLDO_MPU_SETUP_OFFSET			0x00dc
+#define DRA7XX_PRM_ABBLDO_MPU_CTRL_OFFSET			0x00e0
+#define DRA7XX_PRM_ABBLDO_GPU_SETUP_OFFSET			0x00e4
+#define DRA7XX_PRM_ABBLDO_GPU_CTRL_OFFSET			0x00e8
+#define DRA7XX_PRM_BANDGAP_SETUP_OFFSET				0x00ec
+#define DRA7XX_PRM_DEVICE_OFF_CTRL_OFFSET			0x00f0
+#define DRA7XX_PRM_PHASE1_CNDP_OFFSET				0x00f4
+#define DRA7XX_PRM_PHASE2A_CNDP_OFFSET				0x00f8
+#define DRA7XX_PRM_PHASE2B_CNDP_OFFSET				0x00fc
+#define DRA7XX_PRM_MODEM_IF_CTRL_OFFSET				0x0100
+#define DRA7XX_PRM_VOLTST_MPU_OFFSET				0x0110
+#define DRA7XX_PRM_VOLTST_MM_OFFSET				0x0114
+#define DRA7XX_PRM_SLDO_DSPEVE_SETUP_OFFSET			0x0118
+#define DRA7XX_PRM_SLDO_IVA_SETUP_OFFSET			0x011c
+#define DRA7XX_PRM_ABBLDO_DSPEVE_CTRL_OFFSET			0x0120
+#define DRA7XX_PRM_ABBLDO_IVA_CTRL_OFFSET			0x0124
+#define DRA7XX_PRM_SLDO_DSPEVE_CTRL_OFFSET			0x0128
+#define DRA7XX_PRM_SLDO_IVA_CTRL_OFFSET				0x012c
+#define DRA7XX_PRM_ABBLDO_DSPEVE_SETUP_OFFSET			0x0130
+#define DRA7XX_PRM_ABBLDO_IVA_SETUP_OFFSET			0x0134
+
+#endif
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:32:10 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 13:02:10 +0530
Subject: [PATCH 03/12] ARM: DRA7: CM: Add minimal regbit shifts
In-Reply-To: <1373355139-12487-1-git-send-email-rnayak@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
Message-ID: <1373355139-12487-4-git-send-email-rnayak@ti.com>

This header contains minimal regbits that are currently used in code.
This header has traditionally been autogenerated on OMAP4+ devices but
the autogenerated contents are largely (95%) unused and hence to reduce
unsued data in the kernel this header has been cut down (from the autogen
output) to whatever is currently needed. This is done by running a cleanup
script on top of the existing autogen script.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
Signed-off-by: Ambresh K <ambresh at ti.com>
---
 arch/arm/mach-omap2/cm-regbits-7xx.h |   50 ++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 arch/arm/mach-omap2/cm-regbits-7xx.h

diff --git a/arch/arm/mach-omap2/cm-regbits-7xx.h b/arch/arm/mach-omap2/cm-regbits-7xx.h
new file mode 100644
index 0000000..674c9f4
--- /dev/null
+++ b/arch/arm/mach-omap2/cm-regbits-7xx.h
@@ -0,0 +1,50 @@
+/*
+ * DRA7xx Clock Management register bits
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Paul Walmsley (paul at pwsan.com)
+ * Rajendra Nayak (rnayak at ti.com)
+ * Benoit Cousson (b-cousson at ti.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_CM_REGBITS_7XX_H
+#define __ARCH_ARM_MACH_OMAP2_CM_REGBITS_7XX_H
+
+#define DRA7XX_ATL_STATDEP_SHIFT				30
+#define DRA7XX_CAM_STATDEP_SHIFT				9
+#define DRA7XX_DSP1_STATDEP_SHIFT				1
+#define DRA7XX_DSP2_STATDEP_SHIFT				18
+#define DRA7XX_DSS_STATDEP_SHIFT				8
+#define DRA7XX_EMIF_STATDEP_SHIFT				4
+#define DRA7XX_EVE1_STATDEP_SHIFT				19
+#define DRA7XX_EVE2_STATDEP_SHIFT				20
+#define DRA7XX_EVE3_STATDEP_SHIFT				21
+#define DRA7XX_EVE4_STATDEP_SHIFT				22
+#define DRA7XX_GMAC_STATDEP_SHIFT				25
+#define DRA7XX_GPU_STATDEP_SHIFT				10
+#define DRA7XX_IPU1_STATDEP_SHIFT				23
+#define DRA7XX_IPU2_STATDEP_SHIFT				0
+#define DRA7XX_IPU_STATDEP_SHIFT				24
+#define DRA7XX_IVA_STATDEP_SHIFT				2
+#define DRA7XX_L3INIT_STATDEP_SHIFT				7
+#define DRA7XX_L3MAIN1_STATDEP_SHIFT				5
+#define DRA7XX_L4CFG_STATDEP_SHIFT				12
+#define DRA7XX_L4PER2_STATDEP_SHIFT				26
+#define DRA7XX_L4PER3_STATDEP_SHIFT				27
+#define DRA7XX_L4PER_STATDEP_SHIFT				13
+#define DRA7XX_L4SEC_STATDEP_SHIFT				14
+#define DRA7XX_PCIE_STATDEP_SHIFT				29
+#define DRA7XX_VPE_STATDEP_SHIFT				28
+#define DRA7XX_WKUPAON_STATDEP_SHIFT				15
+#endif
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:32:11 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 13:02:11 +0530
Subject: [PATCH 04/12] ARM: DRA7: PRCM: Add DRA7XX local MPU PRCM regsiters
In-Reply-To: <1373355139-12487-1-git-send-email-rnayak@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
Message-ID: <1373355139-12487-5-git-send-email-rnayak@ti.com>

From: Ambresh K <ambresh at ti.com>

Add the PRCM MPU registers for DRA7XX platforms

Signed-off-by: Ambresh K <ambresh at ti.com>
Signed-off-by: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/prcm44xx.h    |    5 +++
 arch/arm/mach-omap2/prcm_mpu7xx.h |   77 +++++++++++++++++++++++++++++++++++++
 2 files changed, 82 insertions(+)
 create mode 100644 arch/arm/mach-omap2/prcm_mpu7xx.h

diff --git a/arch/arm/mach-omap2/prcm44xx.h b/arch/arm/mach-omap2/prcm44xx.h
index f429cdd..4fea2cf 100644
--- a/arch/arm/mach-omap2/prcm44xx.h
+++ b/arch/arm/mach-omap2/prcm44xx.h
@@ -38,6 +38,11 @@
 #define OMAP54XX_SCRM_PARTITION			4
 #define OMAP54XX_PRCM_MPU_PARTITION		5
 
+#define DRA7XX_PRM_PARTITION                   1
+#define DRA7XX_CM_CORE_AON_PARTITION           2
+#define DRA7XX_CM_CORE_PARTITION               3
+#define DRA7XX_MPU_PRCM_PARTITION              5
+
 /*
  * OMAP4_MAX_PRCM_PARTITIONS: set to the highest value of the PRCM partition
  * IDs, plus one
diff --git a/arch/arm/mach-omap2/prcm_mpu7xx.h b/arch/arm/mach-omap2/prcm_mpu7xx.h
new file mode 100644
index 0000000..67c4b6b
--- /dev/null
+++ b/arch/arm/mach-omap2/prcm_mpu7xx.h
@@ -0,0 +1,77 @@
+/*
+ * DRA7xx PRCM MPU instance offset macros
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Paul Walmsley (paul at pwsan.com)
+ * Rajendra Nayak (rnayak at ti.com)
+ * Benoit Cousson (b-cousson at ti.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_PRCM_MPU7XX_H
+#define __ARCH_ARM_MACH_OMAP2_PRCM_MPU7XX_H
+
+#include "prcm_mpu_44xx_54xx.h"
+
+#define DRA7XX_PRCM_MPU_BASE			0x48243000
+
+#define DRA7XX_PRCM_MPU_REGADDR(inst, reg)				\
+	OMAP2_L4_IO_ADDRESS(DRA7XX_PRCM_MPU_BASE + (inst) + (reg))
+
+/* MPU_PRCM instances */
+#define DRA7XX_MPU_PRCM_OCP_SOCKET_INST	0x0000
+#define DRA7XX_MPU_PRCM_DEVICE_INST	0x0200
+#define DRA7XX_MPU_PRCM_PRM_C0_INST	0x0400
+#define DRA7XX_MPU_PRCM_CM_C0_INST	0x0600
+#define DRA7XX_MPU_PRCM_PRM_C1_INST	0x0800
+#define DRA7XX_MPU_PRCM_CM_C1_INST	0x0a00
+
+/* PRCM_MPU clockdomain register offsets (from instance start) */
+#define DRA7XX_MPU_PRCM_CM_C0_CPU0_CDOFFS	0x0000
+#define DRA7XX_MPU_PRCM_CM_C1_CPU1_CDOFFS	0x0000
+
+
+/* MPU_PRCM */
+
+/* MPU_PRCM.PRCM_MPU_OCP_SOCKET register offsets */
+#define DRA7XX_REVISION_PRCM_MPU_OFFSET				0x0000
+
+/* MPU_PRCM.PRCM_MPU_DEVICE register offsets */
+#define DRA7XX_PRM_FRAC_INCREMENTER_NUMERATOR_OFFSET		0x0010
+#define DRA7XX_PRM_FRAC_INCREMENTER_DENUMERATOR_RELOAD_OFFSET	0x0014
+
+/* MPU_PRCM.PRCM_MPU_PRM_C0 register offsets */
+#define DRA7XX_PM_CPU0_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_CPU0_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_CPU0_CPU0_RSTCTRL_OFFSET			0x0010
+#define DRA7XX_RM_CPU0_CPU0_RSTST_OFFSET			0x0014
+#define DRA7XX_RM_CPU0_CPU0_CONTEXT_OFFSET			0x0024
+
+/* MPU_PRCM.PRCM_MPU_CM_C0 register offsets */
+#define DRA7XX_CM_CPU0_CLKSTCTRL_OFFSET				0x0000
+#define DRA7XX_CM_CPU0_CPU0_CLKCTRL_OFFSET			0x0020
+#define DRA7XX_CM_CPU0_CPU0_CLKCTRL				DRA7XX_MPU_PRCM_REGADDR(DRA7XX_MPU_PRCM_CM_C0_INST, 0x0020)
+
+/* MPU_PRCM.PRCM_MPU_PRM_C1 register offsets */
+#define DRA7XX_PM_CPU1_PWRSTCTRL_OFFSET				0x0000
+#define DRA7XX_PM_CPU1_PWRSTST_OFFSET				0x0004
+#define DRA7XX_RM_CPU1_CPU1_RSTCTRL_OFFSET			0x0010
+#define DRA7XX_RM_CPU1_CPU1_RSTST_OFFSET			0x0014
+#define DRA7XX_RM_CPU1_CPU1_CONTEXT_OFFSET			0x0024
+
+/* MPU_PRCM.PRCM_MPU_CM_C1 register offsets */
+#define DRA7XX_CM_CPU1_CLKSTCTRL_OFFSET				0x0000
+#define DRA7XX_CM_CPU1_CPU1_CLKCTRL_OFFSET			0x0020
+#define DRA7XX_CM_CPU1_CPU1_CLKCTRL				DRA7XX_MPU_PRCM_REGADDR(DRA7XX_MPU_PRCM_CM_C1_INST, 0x0020)
+
+#endif
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:32:14 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 13:02:14 +0530
Subject: [PATCH 07/12] ARM: DRA7: powerdomain: Handle missing vc/vp
In-Reply-To: <1373355139-12487-1-git-send-email-rnayak@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
Message-ID: <1373355139-12487-8-git-send-email-rnayak@ti.com>

DRA7 belongs to the omap4plus devices which reuse the omap4_pwrdm_operations
ops for powerdomain control. DRA7 however has no VC/VP while all the
earlier omap4plus devices did.

So use the .pwrdm_has_voltdm() ops to pass this info on to the core.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/prm44xx.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 415c7e0..15271b6 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -620,6 +620,15 @@ static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
 	return 0;
 }
 
+static int omap4_check_vcvp(void)
+{
+	/* No VC/VP on dra7xx devices */
+	if (soc_is_dra7xx())
+		return 0;
+
+	return 1;
+}
+
 struct pwrdm_ops omap4_pwrdm_operations = {
 	.pwrdm_set_next_pwrst	= omap4_pwrdm_set_next_pwrst,
 	.pwrdm_read_next_pwrst	= omap4_pwrdm_read_next_pwrst,
@@ -637,6 +646,7 @@ struct pwrdm_ops omap4_pwrdm_operations = {
 	.pwrdm_set_mem_onst	= omap4_pwrdm_set_mem_onst,
 	.pwrdm_set_mem_retst	= omap4_pwrdm_set_mem_retst,
 	.pwrdm_wait_transition	= omap4_pwrdm_wait_transition,
+	.pwrdm_has_voltdm	= omap4_check_vcvp,
 };
 
 /*
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:32:13 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 13:02:13 +0530
Subject: [PATCH 06/12] ARM: DRA7: powerdomain: Add DRA7XX data and update
 header
In-Reply-To: <1373355139-12487-1-git-send-email-rnayak@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
Message-ID: <1373355139-12487-7-git-send-email-rnayak@ti.com>

From: Ambresh K <ambresh at ti.com>

Add the data file to describe all power domains inside the DRA7XX SoC.

Signed-off-by: Ambresh K <ambresh at ti.com>
Signed-off-by: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/Makefile               |    1 +
 arch/arm/mach-omap2/powerdomain.h          |    1 +
 arch/arm/mach-omap2/powerdomains7xx_data.c |  453 ++++++++++++++++++++++++++++
 3 files changed, 455 insertions(+)
 create mode 100644 arch/arm/mach-omap2/powerdomains7xx_data.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f5576e0..d0a9d15 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -152,6 +152,7 @@ obj-$(CONFIG_SOC_AM43XX)		+= $(powerdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(powerdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= powerdomains54xx_data.o
 obj-$(CONFIG_SOC_DRA7XX)		+= $(powerdomain-common)
+obj-$(CONFIG_SOC_DRA7XX)		+= powerdomains7xx_data.o
 
 # PRCM clockdomain control
 clockdomain-common			+= clockdomain.o
diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h
index e4d7bd6..baf3d8b 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -256,6 +256,7 @@ extern void omap3xxx_powerdomains_init(void);
 extern void am33xx_powerdomains_init(void);
 extern void omap44xx_powerdomains_init(void);
 extern void omap54xx_powerdomains_init(void);
+extern void dra7xx_powerdomains_init(void);
 
 extern struct pwrdm_ops omap2_pwrdm_operations;
 extern struct pwrdm_ops omap3_pwrdm_operations;
diff --git a/arch/arm/mach-omap2/powerdomains7xx_data.c b/arch/arm/mach-omap2/powerdomains7xx_data.c
new file mode 100644
index 0000000..882b794
--- /dev/null
+++ b/arch/arm/mach-omap2/powerdomains7xx_data.c
@@ -0,0 +1,453 @@
+/*
+ * DRA7xx Power domains framework
+ *
+ * Copyright (C) 2009-2013 Texas Instruments, Inc.
+ * Copyright (C) 2009-2011 Nokia Corporation
+ *
+ * Abhijit Pagare (abhijitpagare at ti.com)
+ * Benoit Cousson (b-cousson at ti.com)
+ * Paul Walmsley (paul at pwsan.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+
+#include "powerdomain.h"
+
+#include "prcm-common.h"
+#include "prcm44xx.h"
+#include "prm7xx.h"
+#include "prcm_mpu7xx.h"
+
+/* iva_7xx_pwrdm: IVA-HD power domain */
+static struct powerdomain iva_7xx_pwrdm = {
+	.name		  = "iva_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_IVA_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF,
+	.banks		  = 4,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* hwa_mem */
+		[1] = PWRSTS_OFF_RET,	/* sl2_mem */
+		[2] = PWRSTS_OFF_RET,	/* tcm1_mem */
+		[3] = PWRSTS_OFF_RET,	/* tcm2_mem */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* hwa_mem */
+		[1] = PWRSTS_OFF_RET,	/* sl2_mem */
+		[2] = PWRSTS_OFF_RET,	/* tcm1_mem */
+		[3] = PWRSTS_OFF_RET,	/* tcm2_mem */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* rtc_7xx_pwrdm:  */
+static struct powerdomain rtc_7xx_pwrdm = {
+	.name		  = "rtc_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_RTC_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_ON,
+};
+
+/* custefuse_7xx_pwrdm: Customer efuse controller power domain */
+static struct powerdomain custefuse_7xx_pwrdm = {
+	.name		  = "custefuse_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_CUSTEFUSE_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* ipu_7xx_pwrdm: Audio back end power domain */
+static struct powerdomain ipu_7xx_pwrdm = {
+	.name		  = "ipu_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_IPU_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF,
+	.banks		  = 2,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* aessmem */
+		[1] = PWRSTS_OFF_RET,	/* periphmem */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* aessmem */
+		[1] = PWRSTS_OFF_RET,	/* periphmem */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* dss_7xx_pwrdm: Display subsystem power domain */
+static struct powerdomain dss_7xx_pwrdm = {
+	.name		  = "dss_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_DSS_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* dss_mem */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* dss_mem */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* l4per_7xx_pwrdm: Target peripherals power domain */
+static struct powerdomain l4per_7xx_pwrdm = {
+	.name		  = "l4per_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_L4PER_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 2,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* nonretained_bank */
+		[1] = PWRSTS_OFF_RET,	/* retained_bank */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* nonretained_bank */
+		[1] = PWRSTS_OFF_RET,	/* retained_bank */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* gpu_7xx_pwrdm: 3D accelerator power domain */
+static struct powerdomain gpu_7xx_pwrdm = {
+	.name		  = "gpu_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_GPU_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* gpu_mem */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* gpu_mem */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* wkupaon_7xx_pwrdm: Wake-up power domain */
+static struct powerdomain wkupaon_7xx_pwrdm = {
+	.name		  = "wkupaon_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_WKUPAON_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_ON,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_ON,	/* wkup_bank */
+	},
+};
+
+/* core_7xx_pwrdm: CORE power domain */
+static struct powerdomain core_7xx_pwrdm = {
+	.name		  = "core_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_CORE_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 5,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* core_nret_bank */
+		[1] = PWRSTS_OFF_RET,	/* core_ocmram */
+		[2] = PWRSTS_OFF_RET,	/* core_other_bank */
+		[3] = PWRSTS_OFF_RET,	/* ipu_l2ram */
+		[4] = PWRSTS_OFF_RET,	/* ipu_unicache */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* core_nret_bank */
+		[1] = PWRSTS_OFF_RET,	/* core_ocmram */
+		[2] = PWRSTS_OFF_RET,	/* core_other_bank */
+		[3] = PWRSTS_OFF_RET,	/* ipu_l2ram */
+		[4] = PWRSTS_OFF_RET,	/* ipu_unicache */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* coreaon_7xx_pwrdm: Always ON logic that sits in VDD_CORE voltage domain */
+static struct powerdomain coreaon_7xx_pwrdm = {
+	.name		  = "coreaon_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_COREAON_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_ON,
+};
+
+/* cpu0_7xx_pwrdm: MPU0 processor and Neon coprocessor power domain */
+static struct powerdomain cpu0_7xx_pwrdm = {
+	.name		  = "cpu0_pwrdm",
+	.prcm_offs	  = DRA7XX_MPU_PRCM_PRM_C0_INST,
+	.prcm_partition	  = DRA7XX_MPU_PRCM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* cpu0_l1 */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_ON,	/* cpu0_l1 */
+	},
+};
+
+/* cpu1_7xx_pwrdm: MPU1 processor and Neon coprocessor power domain */
+static struct powerdomain cpu1_7xx_pwrdm = {
+	.name		  = "cpu1_pwrdm",
+	.prcm_offs	  = DRA7XX_MPU_PRCM_PRM_C1_INST,
+	.prcm_partition	  = DRA7XX_MPU_PRCM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* cpu1_l1 */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_ON,	/* cpu1_l1 */
+	},
+};
+
+/* vpe_7xx_pwrdm:  */
+static struct powerdomain vpe_7xx_pwrdm = {
+	.name		  = "vpe_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_VPE_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* vpe_bank */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* vpe_bank */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* mpu_7xx_pwrdm: Modena processor and the Neon coprocessor power domain */
+static struct powerdomain mpu_7xx_pwrdm = {
+	.name		  = "mpu_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_MPU_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 2,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* mpu_l2 */
+		[1] = PWRSTS_RET,	/* mpu_ram */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* mpu_l2 */
+		[1] = PWRSTS_OFF_RET,	/* mpu_ram */
+	},
+};
+
+/* l3init_7xx_pwrdm: L3 initators pheripherals power domain  */
+static struct powerdomain l3init_7xx_pwrdm = {
+	.name		  = "l3init_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_L3INIT_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 3,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* gmac_bank */
+		[1] = PWRSTS_OFF_RET,	/* l3init_bank1 */
+		[2] = PWRSTS_OFF_RET,	/* l3init_bank2 */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* gmac_bank */
+		[1] = PWRSTS_OFF_RET,	/* l3init_bank1 */
+		[2] = PWRSTS_OFF_RET,	/* l3init_bank2 */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* eve3_7xx_pwrdm:  */
+static struct powerdomain eve3_7xx_pwrdm = {
+	.name		  = "eve3_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_EVE3_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* eve3_bank */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* eve3_bank */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* emu_7xx_pwrdm: Emulation power domain */
+static struct powerdomain emu_7xx_pwrdm = {
+	.name		  = "emu_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_EMU_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* emu_bank */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* emu_bank */
+	},
+};
+
+/* dsp2_7xx_pwrdm:  */
+static struct powerdomain dsp2_7xx_pwrdm = {
+	.name		  = "dsp2_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_DSP2_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.banks		  = 3,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* dsp2_edma */
+		[1] = PWRSTS_OFF_RET,	/* dsp2_l1 */
+		[2] = PWRSTS_OFF_RET,	/* dsp2_l2 */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* dsp2_edma */
+		[1] = PWRSTS_OFF_RET,	/* dsp2_l1 */
+		[2] = PWRSTS_OFF_RET,	/* dsp2_l2 */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* dsp1_7xx_pwrdm: Tesla processor power domain */
+static struct powerdomain dsp1_7xx_pwrdm = {
+	.name		  = "dsp1_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_DSP1_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.banks		  = 3,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* dsp1_edma */
+		[1] = PWRSTS_OFF_RET,	/* dsp1_l1 */
+		[2] = PWRSTS_OFF_RET,	/* dsp1_l2 */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* dsp1_edma */
+		[1] = PWRSTS_OFF_RET,	/* dsp1_l1 */
+		[2] = PWRSTS_OFF_RET,	/* dsp1_l2 */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* cam_7xx_pwrdm: Camera subsystem power domain */
+static struct powerdomain cam_7xx_pwrdm = {
+	.name		  = "cam_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_CAM_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* vip_bank */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* vip_bank */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* eve4_7xx_pwrdm:  */
+static struct powerdomain eve4_7xx_pwrdm = {
+	.name		  = "eve4_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_EVE4_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* eve4_bank */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* eve4_bank */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* eve2_7xx_pwrdm:  */
+static struct powerdomain eve2_7xx_pwrdm = {
+	.name		  = "eve2_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_EVE2_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* eve2_bank */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* eve2_bank */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/* eve1_7xx_pwrdm:  */
+static struct powerdomain eve1_7xx_pwrdm = {
+	.name		  = "eve1_pwrdm",
+	.prcm_offs	  = DRA7XX_PRM_EVE1_INST,
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* eve1_bank */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* eve1_bank */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+/*
+ * The following power domains are not under SW control
+ *
+ * mpuaon
+ * mmaon
+ */
+
+/* As powerdomains are added or removed above, this list must also be changed */
+static struct powerdomain *powerdomains_dra7xx[] __initdata = {
+	&iva_7xx_pwrdm,
+	&rtc_7xx_pwrdm,
+	&custefuse_7xx_pwrdm,
+	&ipu_7xx_pwrdm,
+	&dss_7xx_pwrdm,
+	&l4per_7xx_pwrdm,
+	&gpu_7xx_pwrdm,
+	&wkupaon_7xx_pwrdm,
+	&core_7xx_pwrdm,
+	&coreaon_7xx_pwrdm,
+	&cpu0_7xx_pwrdm,
+	&cpu1_7xx_pwrdm,
+	&vpe_7xx_pwrdm,
+	&mpu_7xx_pwrdm,
+	&l3init_7xx_pwrdm,
+	&eve3_7xx_pwrdm,
+	&emu_7xx_pwrdm,
+	&dsp2_7xx_pwrdm,
+	&dsp1_7xx_pwrdm,
+	&cam_7xx_pwrdm,
+	&eve4_7xx_pwrdm,
+	&eve2_7xx_pwrdm,
+	&eve1_7xx_pwrdm,
+	NULL
+};
+
+void __init dra7xx_powerdomains_init(void)
+{
+	pwrdm_register_platform_funcs(&omap4_pwrdm_operations);
+	pwrdm_register_pwrdms(powerdomains_dra7xx);
+	pwrdm_complete_init();
+}
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:32:17 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 13:02:17 +0530
Subject: [PATCH 10/12] ARM: DRA7: Enable PM framework initializations
In-Reply-To: <1373355139-12487-1-git-send-email-rnayak@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
Message-ID: <1373355139-12487-11-git-send-email-rnayak@ti.com>

From: Ambresh K <ambresh at ti.com>

Initialise powerdomains, clockdomains, and hwmod frameworks.

Signed-off-by: Ambresh K <ambresh at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/io.c      |    5 +++++
 arch/arm/mach-omap2/prm44xx.c |    2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 542e6bd..09115e7 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -667,6 +667,11 @@ void __init dra7xx_init_early(void)
 	omap_prm_base_init();
 	omap_cm_base_init();
 	dra7xx_check_revision();
+	omap44xx_prm_init();
+	dra7xx_powerdomains_init();
+	dra7xx_clockdomains_init();
+	dra7xx_hwmod_init();
+	omap_hwmod_init_postsetup();
 }
 #endif
 
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 15271b6..03a6034 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -660,7 +660,7 @@ static struct prm_ll_data omap44xx_prm_ll_data = {
 
 int __init omap44xx_prm_init(void)
 {
-	if (!cpu_is_omap44xx() && !soc_is_omap54xx())
+	if (!cpu_is_omap44xx() && !soc_is_omap54xx() && !soc_is_dra7xx())
 		return 0;
 
 	return prm_register(&omap44xx_prm_ll_data);
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:32:15 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 13:02:15 +0530
Subject: [PATCH 08/12] ARM: DRA7: Reuse the omap44xx_restart and fix the
 device instance
In-Reply-To: <1373355139-12487-1-git-send-email-rnayak@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
Message-ID: <1373355139-12487-9-git-send-email-rnayak@ti.com>

The omap44xx_restart used on omap4 and omap5 devices can be reused
on dra7 devices as well. The device instance however is different
across omap5 and dra7 as compared to omap4. So fix this for omap5
as well as dra7.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
Signed-off-by: R Sricharan <r.sricharan at ti.com>
---
 arch/arm/mach-omap2/Makefile        |    1 +
 arch/arm/mach-omap2/board-generic.c |    1 +
 arch/arm/mach-omap2/prminst44xx.c   |   20 ++++++++++++++++----
 3 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d0a9d15..137c9e4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_SOC_AM33XX)		+= am33xx-restart.o
 obj-$(CONFIG_ARCH_OMAP3)		+= omap3-restart.o
 obj-$(CONFIG_ARCH_OMAP4)		+= omap4-restart.o
 obj-$(CONFIG_SOC_OMAP5)			+= omap4-restart.o
+obj-$(CONFIG_SOC_DRA7XX)		+= omap4-restart.o
 
 # Pin multiplexing
 obj-$(CONFIG_SOC_OMAP2420)		+= mux2420.o
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 92f8dd3..55d3ee8 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -217,5 +217,6 @@ DT_MACHINE_START(DRA7XX_DT, "Generic DRA7XX (Flattened Device Tree)")
 	.init_machine	= omap_generic_init,
 	.init_time	= omap5_realtime_timer_init,
 	.dt_compat	= dra7xx_boards_compat,
+	.restart	= omap44xx_restart,
 MACHINE_END
 #endif
diff --git a/arch/arm/mach-omap2/prminst44xx.c b/arch/arm/mach-omap2/prminst44xx.c
index c12320c..6334b96 100644
--- a/arch/arm/mach-omap2/prminst44xx.c
+++ b/arch/arm/mach-omap2/prminst44xx.c
@@ -20,10 +20,13 @@
 #include "common.h"
 #include "prcm-common.h"
 #include "prm44xx.h"
+#include "prm54xx.h"
+#include "prm7xx.h"
 #include "prminst44xx.h"
 #include "prm-regbits-44xx.h"
 #include "prcm44xx.h"
 #include "prcm_mpu44xx.h"
+#include "soc.h"
 
 static void __iomem *_prm_bases[OMAP4_MAX_PRCM_PARTITIONS];
 
@@ -165,10 +168,19 @@ int omap4_prminst_deassert_hardreset(u8 shift, u8 part, s16 inst,
 void omap4_prminst_global_warm_sw_reset(void)
 {
 	u32 v;
-
-	v = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
-				    OMAP4430_PRM_DEVICE_INST,
-				    OMAP4_PRM_RSTCTRL_OFFSET);
+	s16 dev_inst;
+
+	if (cpu_is_omap44xx())
+		dev_inst = OMAP4430_PRM_DEVICE_INST;
+	else if (soc_is_omap54xx())
+		dev_inst = OMAP54XX_PRM_DEVICE_INST;
+	else if (soc_is_dra7xx())
+		dev_inst = DRA7XX_PRM_DEVICE_INST;
+	else
+		return;
+
+	v = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION, dev_inst,
+					OMAP4_PRM_RSTCTRL_OFFSET);
 	v |= OMAP4430_RST_GLOBAL_WARM_SW_MASK;
 	omap4_prminst_write_inst_reg(v, OMAP4430_PRM_PARTITION,
 				 OMAP4430_PRM_DEVICE_INST,
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:32:12 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 13:02:12 +0530
Subject: [PATCH 05/12] ARM: DRA7: clockdomain: Add DRA7XX data and update
 header
In-Reply-To: <1373355139-12487-1-git-send-email-rnayak@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
Message-ID: <1373355139-12487-6-git-send-email-rnayak@ti.com>

From: Ambresh K <ambresh at ti.com>

Add the data file to describe all clock domains inside the DRA7XX SoC

Signed-off-by: Ambresh K <ambresh at ti.com>
Signed-off-by: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/Makefile               |    1 +
 arch/arm/mach-omap2/clockdomain.h          |    1 +
 arch/arm/mach-omap2/clockdomains7xx_data.c |  739 ++++++++++++++++++++++++++++
 3 files changed, 741 insertions(+)
 create mode 100644 arch/arm/mach-omap2/clockdomains7xx_data.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index dbcd73f..f5576e0 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -170,6 +170,7 @@ obj-$(CONFIG_SOC_AM43XX)		+= $(clockdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(clockdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= clockdomains54xx_data.o
 obj-$(CONFIG_SOC_DRA7XX)		+= $(clockdomain-common)
+obj-$(CONFIG_SOC_DRA7XX)		+= clockdomains7xx_data.o
 
 # Clock framework
 obj-$(CONFIG_ARCH_OMAP2)		+= $(clock-common) clock2xxx.o
diff --git a/arch/arm/mach-omap2/clockdomain.h b/arch/arm/mach-omap2/clockdomain.h
index daeecf1..4b03394 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -217,6 +217,7 @@ extern void __init omap3xxx_clockdomains_init(void);
 extern void __init am33xx_clockdomains_init(void);
 extern void __init omap44xx_clockdomains_init(void);
 extern void __init omap54xx_clockdomains_init(void);
+extern void __init dra7xx_clockdomains_init(void);
 
 extern void clkdm_add_autodeps(struct clockdomain *clkdm);
 extern void clkdm_del_autodeps(struct clockdomain *clkdm);
diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c b/arch/arm/mach-omap2/clockdomains7xx_data.c
new file mode 100644
index 0000000..a7d25d3
--- /dev/null
+++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
@@ -0,0 +1,739 @@
+/*
+ * DRA7xx Clock domains framework
+ *
+ * Copyright (C) 2009-2013 Texas Instruments, Inc.
+ * Copyright (C) 2009-2011 Nokia Corporation
+ *
+ * Abhijit Pagare (abhijitpagare at ti.com)
+ * Benoit Cousson (b-cousson at ti.com)
+ * Paul Walmsley (paul at pwsan.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/io.h>
+
+#include "clockdomain.h"
+#include "cm1_7xx.h"
+#include "cm2_7xx.h"
+
+#include "cm-regbits-7xx.h"
+#include "prm7xx.h"
+#include "prcm44xx.h"
+#include "prcm_mpu7xx.h"
+
+/* Static Dependencies for DRA7xx Clock Domains */
+
+static struct clkdm_dep cam_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep dma_wkup_sleep_deps[] = {
+	{ .clkdm_name = "dss_clkdm" },
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "ipu_clkdm" },
+	{ .clkdm_name = "ipu1_clkdm" },
+	{ .clkdm_name = "ipu2_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3init_clkdm" },
+	{ .clkdm_name = "l4cfg_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ .clkdm_name = "l4per2_clkdm" },
+	{ .clkdm_name = "l4per3_clkdm" },
+	{ .clkdm_name = "l4sec_clkdm" },
+	{ .clkdm_name = "pcie_clkdm" },
+	{ .clkdm_name = "wkupaon_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep dsp1_wkup_sleep_deps[] = {
+	{ .clkdm_name = "atl_clkdm" },
+	{ .clkdm_name = "cam_clkdm" },
+	{ .clkdm_name = "dsp2_clkdm" },
+	{ .clkdm_name = "dss_clkdm" },
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "eve1_clkdm" },
+	{ .clkdm_name = "eve2_clkdm" },
+	{ .clkdm_name = "eve3_clkdm" },
+	{ .clkdm_name = "eve4_clkdm" },
+	{ .clkdm_name = "gmac_clkdm" },
+	{ .clkdm_name = "gpu_clkdm" },
+	{ .clkdm_name = "ipu_clkdm" },
+	{ .clkdm_name = "ipu1_clkdm" },
+	{ .clkdm_name = "ipu2_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3init_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ .clkdm_name = "l4per2_clkdm" },
+	{ .clkdm_name = "l4per3_clkdm" },
+	{ .clkdm_name = "l4sec_clkdm" },
+	{ .clkdm_name = "pcie_clkdm" },
+	{ .clkdm_name = "vpe_clkdm" },
+	{ .clkdm_name = "wkupaon_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep dsp2_wkup_sleep_deps[] = {
+	{ .clkdm_name = "atl_clkdm" },
+	{ .clkdm_name = "cam_clkdm" },
+	{ .clkdm_name = "dsp1_clkdm" },
+	{ .clkdm_name = "dss_clkdm" },
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "eve1_clkdm" },
+	{ .clkdm_name = "eve2_clkdm" },
+	{ .clkdm_name = "eve3_clkdm" },
+	{ .clkdm_name = "eve4_clkdm" },
+	{ .clkdm_name = "gmac_clkdm" },
+	{ .clkdm_name = "gpu_clkdm" },
+	{ .clkdm_name = "ipu_clkdm" },
+	{ .clkdm_name = "ipu1_clkdm" },
+	{ .clkdm_name = "ipu2_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3init_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ .clkdm_name = "l4per2_clkdm" },
+	{ .clkdm_name = "l4per3_clkdm" },
+	{ .clkdm_name = "l4sec_clkdm" },
+	{ .clkdm_name = "pcie_clkdm" },
+	{ .clkdm_name = "vpe_clkdm" },
+	{ .clkdm_name = "wkupaon_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep dss_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep eve1_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "eve2_clkdm" },
+	{ .clkdm_name = "eve3_clkdm" },
+	{ .clkdm_name = "eve4_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep eve2_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "eve1_clkdm" },
+	{ .clkdm_name = "eve3_clkdm" },
+	{ .clkdm_name = "eve4_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep eve3_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "eve1_clkdm" },
+	{ .clkdm_name = "eve2_clkdm" },
+	{ .clkdm_name = "eve4_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep eve4_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "eve1_clkdm" },
+	{ .clkdm_name = "eve2_clkdm" },
+	{ .clkdm_name = "eve3_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep gmac_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "l4per2_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep gpu_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep ipu1_wkup_sleep_deps[] = {
+	{ .clkdm_name = "atl_clkdm" },
+	{ .clkdm_name = "dsp1_clkdm" },
+	{ .clkdm_name = "dsp2_clkdm" },
+	{ .clkdm_name = "dss_clkdm" },
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "eve1_clkdm" },
+	{ .clkdm_name = "eve2_clkdm" },
+	{ .clkdm_name = "eve3_clkdm" },
+	{ .clkdm_name = "eve4_clkdm" },
+	{ .clkdm_name = "gmac_clkdm" },
+	{ .clkdm_name = "gpu_clkdm" },
+	{ .clkdm_name = "ipu_clkdm" },
+	{ .clkdm_name = "ipu2_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3init_clkdm" },
+	{ .clkdm_name = "l3main1_clkdm" },
+	{ .clkdm_name = "l4cfg_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ .clkdm_name = "l4per2_clkdm" },
+	{ .clkdm_name = "l4per3_clkdm" },
+	{ .clkdm_name = "l4sec_clkdm" },
+	{ .clkdm_name = "pcie_clkdm" },
+	{ .clkdm_name = "vpe_clkdm" },
+	{ .clkdm_name = "wkupaon_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep ipu2_wkup_sleep_deps[] = {
+	{ .clkdm_name = "atl_clkdm" },
+	{ .clkdm_name = "dsp1_clkdm" },
+	{ .clkdm_name = "dsp2_clkdm" },
+	{ .clkdm_name = "dss_clkdm" },
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "eve1_clkdm" },
+	{ .clkdm_name = "eve2_clkdm" },
+	{ .clkdm_name = "eve3_clkdm" },
+	{ .clkdm_name = "eve4_clkdm" },
+	{ .clkdm_name = "gmac_clkdm" },
+	{ .clkdm_name = "gpu_clkdm" },
+	{ .clkdm_name = "ipu_clkdm" },
+	{ .clkdm_name = "ipu1_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3init_clkdm" },
+	{ .clkdm_name = "l3main1_clkdm" },
+	{ .clkdm_name = "l4cfg_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ .clkdm_name = "l4per2_clkdm" },
+	{ .clkdm_name = "l4per3_clkdm" },
+	{ .clkdm_name = "l4sec_clkdm" },
+	{ .clkdm_name = "pcie_clkdm" },
+	{ .clkdm_name = "vpe_clkdm" },
+	{ .clkdm_name = "wkupaon_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep iva_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep l3init_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l4cfg_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ .clkdm_name = "l4per3_clkdm" },
+	{ .clkdm_name = "l4sec_clkdm" },
+	{ .clkdm_name = "wkupaon_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep l4per2_wkup_sleep_deps[] = {
+	{ .clkdm_name = "dsp1_clkdm" },
+	{ .clkdm_name = "dsp2_clkdm" },
+	{ .clkdm_name = "ipu1_clkdm" },
+	{ .clkdm_name = "ipu2_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep l4sec_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep mpu_wkup_sleep_deps[] = {
+	{ .clkdm_name = "cam_clkdm" },
+	{ .clkdm_name = "dsp1_clkdm" },
+	{ .clkdm_name = "dsp2_clkdm" },
+	{ .clkdm_name = "dss_clkdm" },
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "eve1_clkdm" },
+	{ .clkdm_name = "eve2_clkdm" },
+	{ .clkdm_name = "eve3_clkdm" },
+	{ .clkdm_name = "eve4_clkdm" },
+	{ .clkdm_name = "gmac_clkdm" },
+	{ .clkdm_name = "gpu_clkdm" },
+	{ .clkdm_name = "ipu_clkdm" },
+	{ .clkdm_name = "ipu1_clkdm" },
+	{ .clkdm_name = "ipu2_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3init_clkdm" },
+	{ .clkdm_name = "l3main1_clkdm" },
+	{ .clkdm_name = "l4cfg_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ .clkdm_name = "l4per2_clkdm" },
+	{ .clkdm_name = "l4per3_clkdm" },
+	{ .clkdm_name = "l4sec_clkdm" },
+	{ .clkdm_name = "pcie_clkdm" },
+	{ .clkdm_name = "vpe_clkdm" },
+	{ .clkdm_name = "wkupaon_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep pcie_wkup_sleep_deps[] = {
+	{ .clkdm_name = "atl_clkdm" },
+	{ .clkdm_name = "cam_clkdm" },
+	{ .clkdm_name = "dsp1_clkdm" },
+	{ .clkdm_name = "dsp2_clkdm" },
+	{ .clkdm_name = "dss_clkdm" },
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "eve1_clkdm" },
+	{ .clkdm_name = "eve2_clkdm" },
+	{ .clkdm_name = "eve3_clkdm" },
+	{ .clkdm_name = "eve4_clkdm" },
+	{ .clkdm_name = "gmac_clkdm" },
+	{ .clkdm_name = "gpu_clkdm" },
+	{ .clkdm_name = "ipu_clkdm" },
+	{ .clkdm_name = "ipu1_clkdm" },
+	{ .clkdm_name = "iva_clkdm" },
+	{ .clkdm_name = "l3init_clkdm" },
+	{ .clkdm_name = "l4cfg_clkdm" },
+	{ .clkdm_name = "l4per_clkdm" },
+	{ .clkdm_name = "l4per2_clkdm" },
+	{ .clkdm_name = "l4per3_clkdm" },
+	{ .clkdm_name = "l4sec_clkdm" },
+	{ .clkdm_name = "vpe_clkdm" },
+	{ NULL },
+};
+
+static struct clkdm_dep vpe_wkup_sleep_deps[] = {
+	{ .clkdm_name = "emif_clkdm" },
+	{ .clkdm_name = "l4per3_clkdm" },
+	{ NULL },
+};
+
+static struct clockdomain l4per3_7xx_clkdm = {
+	.name		  = "l4per3_clkdm",
+	.pwrdm		  = { .name = "l4per_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_L4PER_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_L4PER_L4PER3_CDOFFS,
+	.dep_bit	  = DRA7XX_L4PER3_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain l4per2_7xx_clkdm = {
+	.name		  = "l4per2_clkdm",
+	.pwrdm		  = { .name = "l4per_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_L4PER_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_L4PER_L4PER2_CDOFFS,
+	.dep_bit	  = DRA7XX_L4PER2_STATDEP_SHIFT,
+	.wkdep_srcs	  = l4per2_wkup_sleep_deps,
+	.sleepdep_srcs	  = l4per2_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain mpu0_7xx_clkdm = {
+	.name		  = "mpu0_clkdm",
+	.pwrdm		  = { .name = "cpu0_pwrdm" },
+	.prcm_partition	  = DRA7XX_MPU_PRCM_PARTITION,
+	.cm_inst	  = DRA7XX_MPU_PRCM_CM_C0_INST,
+	.clkdm_offs	  = DRA7XX_MPU_PRCM_CM_C0_CPU0_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain iva_7xx_clkdm = {
+	.name		  = "iva_clkdm",
+	.pwrdm		  = { .name = "iva_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_IVA_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_IVA_IVA_CDOFFS,
+	.dep_bit	  = DRA7XX_IVA_STATDEP_SHIFT,
+	.wkdep_srcs	  = iva_wkup_sleep_deps,
+	.sleepdep_srcs	  = iva_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain coreaon_7xx_clkdm = {
+	.name		  = "coreaon_clkdm",
+	.pwrdm		  = { .name = "coreaon_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_COREAON_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_COREAON_COREAON_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain ipu1_7xx_clkdm = {
+	.name		  = "ipu1_clkdm",
+	.pwrdm		  = { .name = "ipu_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_AON_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_AON_IPU_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_AON_IPU_IPU1_CDOFFS,
+	.dep_bit	  = DRA7XX_IPU1_STATDEP_SHIFT,
+	.wkdep_srcs	  = ipu1_wkup_sleep_deps,
+	.sleepdep_srcs	  = ipu1_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain ipu2_7xx_clkdm = {
+	.name		  = "ipu2_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_CORE_IPU2_CDOFFS,
+	.dep_bit	  = DRA7XX_IPU2_STATDEP_SHIFT,
+	.wkdep_srcs	  = ipu2_wkup_sleep_deps,
+	.sleepdep_srcs	  = ipu2_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain l3init_7xx_clkdm = {
+	.name		  = "l3init_clkdm",
+	.pwrdm		  = { .name = "l3init_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_L3INIT_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_L3INIT_L3INIT_CDOFFS,
+	.dep_bit	  = DRA7XX_L3INIT_STATDEP_SHIFT,
+	.wkdep_srcs	  = l3init_wkup_sleep_deps,
+	.sleepdep_srcs	  = l3init_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain l4sec_7xx_clkdm = {
+	.name		  = "l4sec_clkdm",
+	.pwrdm		  = { .name = "l4per_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_L4PER_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_L4PER_L4SEC_CDOFFS,
+	.dep_bit	  = DRA7XX_L4SEC_STATDEP_SHIFT,
+	.wkdep_srcs	  = l4sec_wkup_sleep_deps,
+	.sleepdep_srcs	  = l4sec_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain l3main1_7xx_clkdm = {
+	.name		  = "l3main1_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_CORE_L3MAIN1_CDOFFS,
+	.dep_bit	  = DRA7XX_L3MAIN1_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain vpe_7xx_clkdm = {
+	.name		  = "vpe_clkdm",
+	.pwrdm		  = { .name = "vpe_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_AON_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_AON_VPE_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_AON_VPE_VPE_CDOFFS,
+	.dep_bit	  = DRA7XX_VPE_STATDEP_SHIFT,
+	.wkdep_srcs	  = vpe_wkup_sleep_deps,
+	.sleepdep_srcs	  = vpe_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain mpu_7xx_clkdm = {
+	.name		  = "mpu_clkdm",
+	.pwrdm		  = { .name = "mpu_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_AON_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_AON_MPU_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_AON_MPU_MPU_CDOFFS,
+	.wkdep_srcs	  = mpu_wkup_sleep_deps,
+	.sleepdep_srcs	  = mpu_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain custefuse_7xx_clkdm = {
+	.name		  = "custefuse_clkdm",
+	.pwrdm		  = { .name = "custefuse_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_CUSTEFUSE_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_CUSTEFUSE_CUSTEFUSE_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain ipu_7xx_clkdm = {
+	.name		  = "ipu_clkdm",
+	.pwrdm		  = { .name = "ipu_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_AON_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_AON_IPU_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_AON_IPU_IPU_CDOFFS,
+	.dep_bit	  = DRA7XX_IPU_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain mpu1_7xx_clkdm = {
+	.name		  = "mpu1_clkdm",
+	.pwrdm		  = { .name = "cpu1_pwrdm" },
+	.prcm_partition	  = DRA7XX_MPU_PRCM_PARTITION,
+	.cm_inst	  = DRA7XX_MPU_PRCM_CM_C1_INST,
+	.clkdm_offs	  = DRA7XX_MPU_PRCM_CM_C1_CPU1_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain gmac_7xx_clkdm = {
+	.name		  = "gmac_clkdm",
+	.pwrdm		  = { .name = "l3init_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_L3INIT_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_L3INIT_GMAC_CDOFFS,
+	.dep_bit	  = DRA7XX_GMAC_STATDEP_SHIFT,
+	.wkdep_srcs	  = gmac_wkup_sleep_deps,
+	.sleepdep_srcs	  = gmac_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain l4cfg_7xx_clkdm = {
+	.name		  = "l4cfg_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_CORE_L4CFG_CDOFFS,
+	.dep_bit	  = DRA7XX_L4CFG_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain dma_7xx_clkdm = {
+	.name		  = "dma_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_CORE_DMA_CDOFFS,
+	.wkdep_srcs	  = dma_wkup_sleep_deps,
+	.sleepdep_srcs	  = dma_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain rtc_7xx_clkdm = {
+	.name		  = "rtc_clkdm",
+	.pwrdm		  = { .name = "rtc_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_AON_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_AON_RTC_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_AON_RTC_RTC_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain pcie_7xx_clkdm = {
+	.name		  = "pcie_clkdm",
+	.pwrdm		  = { .name = "l3init_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_L3INIT_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_L3INIT_PCIE_CDOFFS,
+	.dep_bit	  = DRA7XX_PCIE_STATDEP_SHIFT,
+	.wkdep_srcs	  = pcie_wkup_sleep_deps,
+	.sleepdep_srcs	  = pcie_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain atl_7xx_clkdm = {
+	.name		  = "atl_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_CORE_ATL_CDOFFS,
+	.dep_bit	  = DRA7XX_ATL_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain l3instr_7xx_clkdm = {
+	.name		  = "l3instr_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_CORE_L3INSTR_CDOFFS,
+};
+
+static struct clockdomain dss_7xx_clkdm = {
+	.name		  = "dss_clkdm",
+	.pwrdm		  = { .name = "dss_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_DSS_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_DSS_DSS_CDOFFS,
+	.dep_bit	  = DRA7XX_DSS_STATDEP_SHIFT,
+	.wkdep_srcs	  = dss_wkup_sleep_deps,
+	.sleepdep_srcs	  = dss_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain emif_7xx_clkdm = {
+	.name		  = "emif_clkdm",
+	.pwrdm		  = { .name = "core_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_CORE_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_CORE_EMIF_CDOFFS,
+	.dep_bit	  = DRA7XX_EMIF_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain emu_7xx_clkdm = {
+	.name		  = "emu_clkdm",
+	.pwrdm		  = { .name = "emu_pwrdm" },
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.cm_inst	  = DRA7XX_PRM_EMU_CM_INST,
+	.clkdm_offs	  = DRA7XX_PRM_EMU_CM_EMU_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain dsp2_7xx_clkdm = {
+	.name		  = "dsp2_clkdm",
+	.pwrdm		  = { .name = "dsp2_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_AON_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_AON_DSP2_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_AON_DSP2_DSP2_CDOFFS,
+	.dep_bit	  = DRA7XX_DSP2_STATDEP_SHIFT,
+	.wkdep_srcs	  = dsp2_wkup_sleep_deps,
+	.sleepdep_srcs	  = dsp2_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain dsp1_7xx_clkdm = {
+	.name		  = "dsp1_clkdm",
+	.pwrdm		  = { .name = "dsp1_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_AON_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_AON_DSP1_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_AON_DSP1_DSP1_CDOFFS,
+	.dep_bit	  = DRA7XX_DSP1_STATDEP_SHIFT,
+	.wkdep_srcs	  = dsp1_wkup_sleep_deps,
+	.sleepdep_srcs	  = dsp1_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain cam_7xx_clkdm = {
+	.name		  = "cam_clkdm",
+	.pwrdm		  = { .name = "cam_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_CAM_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_CAM_CAM_CDOFFS,
+	.dep_bit	  = DRA7XX_CAM_STATDEP_SHIFT,
+	.wkdep_srcs	  = cam_wkup_sleep_deps,
+	.sleepdep_srcs	  = cam_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain l4per_7xx_clkdm = {
+	.name		  = "l4per_clkdm",
+	.pwrdm		  = { .name = "l4per_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_L4PER_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_L4PER_L4PER_CDOFFS,
+	.dep_bit	  = DRA7XX_L4PER_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain gpu_7xx_clkdm = {
+	.name		  = "gpu_clkdm",
+	.pwrdm		  = { .name = "gpu_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_GPU_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_GPU_GPU_CDOFFS,
+	.dep_bit	  = DRA7XX_GPU_STATDEP_SHIFT,
+	.wkdep_srcs	  = gpu_wkup_sleep_deps,
+	.sleepdep_srcs	  = gpu_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain eve4_7xx_clkdm = {
+	.name		  = "eve4_clkdm",
+	.pwrdm		  = { .name = "eve4_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_AON_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_AON_EVE4_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_AON_EVE4_EVE4_CDOFFS,
+	.dep_bit	  = DRA7XX_EVE4_STATDEP_SHIFT,
+	.wkdep_srcs	  = eve4_wkup_sleep_deps,
+	.sleepdep_srcs	  = eve4_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain eve2_7xx_clkdm = {
+	.name		  = "eve2_clkdm",
+	.pwrdm		  = { .name = "eve2_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_AON_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_AON_EVE2_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_AON_EVE2_EVE2_CDOFFS,
+	.dep_bit	  = DRA7XX_EVE2_STATDEP_SHIFT,
+	.wkdep_srcs	  = eve2_wkup_sleep_deps,
+	.sleepdep_srcs	  = eve2_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain eve3_7xx_clkdm = {
+	.name		  = "eve3_clkdm",
+	.pwrdm		  = { .name = "eve3_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_AON_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_AON_EVE3_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_AON_EVE3_EVE3_CDOFFS,
+	.dep_bit	  = DRA7XX_EVE3_STATDEP_SHIFT,
+	.wkdep_srcs	  = eve3_wkup_sleep_deps,
+	.sleepdep_srcs	  = eve3_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain wkupaon_7xx_clkdm = {
+	.name		  = "wkupaon_clkdm",
+	.pwrdm		  = { .name = "wkupaon_pwrdm" },
+	.prcm_partition	  = DRA7XX_PRM_PARTITION,
+	.cm_inst	  = DRA7XX_PRM_WKUPAON_CM_INST,
+	.clkdm_offs	  = DRA7XX_PRM_WKUPAON_CM_WKUPAON_CDOFFS,
+	.dep_bit	  = DRA7XX_WKUPAON_STATDEP_SHIFT,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_HWSUP,
+};
+
+static struct clockdomain eve1_7xx_clkdm = {
+	.name		  = "eve1_clkdm",
+	.pwrdm		  = { .name = "eve1_pwrdm" },
+	.prcm_partition	  = DRA7XX_CM_CORE_AON_PARTITION,
+	.cm_inst	  = DRA7XX_CM_CORE_AON_EVE1_INST,
+	.clkdm_offs	  = DRA7XX_CM_CORE_AON_EVE1_EVE1_CDOFFS,
+	.dep_bit	  = DRA7XX_EVE1_STATDEP_SHIFT,
+	.wkdep_srcs	  = eve1_wkup_sleep_deps,
+	.sleepdep_srcs	  = eve1_wkup_sleep_deps,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+/* As clockdomains are added or removed above, this list must also be changed */
+static struct clockdomain *clockdomains_dra7xx[] __initdata = {
+	&l4per3_7xx_clkdm,
+	&l4per2_7xx_clkdm,
+	&mpu0_7xx_clkdm,
+	&iva_7xx_clkdm,
+	&coreaon_7xx_clkdm,
+	&ipu1_7xx_clkdm,
+	&ipu2_7xx_clkdm,
+	&l3init_7xx_clkdm,
+	&l4sec_7xx_clkdm,
+	&l3main1_7xx_clkdm,
+	&vpe_7xx_clkdm,
+	&mpu_7xx_clkdm,
+	&custefuse_7xx_clkdm,
+	&ipu_7xx_clkdm,
+	&mpu1_7xx_clkdm,
+	&gmac_7xx_clkdm,
+	&l4cfg_7xx_clkdm,
+	&dma_7xx_clkdm,
+	&rtc_7xx_clkdm,
+	&pcie_7xx_clkdm,
+	&atl_7xx_clkdm,
+	&l3instr_7xx_clkdm,
+	&dss_7xx_clkdm,
+	&emif_7xx_clkdm,
+	&emu_7xx_clkdm,
+	&dsp2_7xx_clkdm,
+	&dsp1_7xx_clkdm,
+	&cam_7xx_clkdm,
+	&l4per_7xx_clkdm,
+	&gpu_7xx_clkdm,
+	&eve4_7xx_clkdm,
+	&eve2_7xx_clkdm,
+	&eve3_7xx_clkdm,
+	&wkupaon_7xx_clkdm,
+	&eve1_7xx_clkdm,
+	NULL
+};
+
+void __init dra7xx_clockdomains_init(void)
+{
+	clkdm_register_platform_funcs(&omap4_clkdm_operations);
+	clkdm_register_clkdms(clockdomains_dra7xx);
+	clkdm_complete_init();
+}
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:32:18 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 13:02:18 +0530
Subject: [PATCH 11/12] ARM: DRA7: Add the build support in omap2plus
In-Reply-To: <1373355139-12487-1-git-send-email-rnayak@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
Message-ID: <1373355139-12487-12-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

Now that all the needed pieces for DRA7 based SoCs' is present, enable
the build support in omap2plus_defconfig

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/configs/omap2plus_defconfig |    1 +
 arch/arm/mach-omap2/Kconfig          |   10 +++++++++-
 arch/arm/plat-omap/Kconfig           |    2 +-
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 2ac0ffb..8b17466 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -286,3 +286,4 @@ CONFIG_SOC_OMAP5=y
 CONFIG_TI_DAVINCI_MDIO=y
 CONFIG_TI_DAVINCI_CPDMA=y
 CONFIG_TI_CPSW=y
+CONFIG_SOC_DRA7XX=y
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index bd34483..e85d430 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -36,7 +36,7 @@ config ARCH_OMAP2PLUS_TYPICAL
 	select I2C
 	select I2C_OMAP
 	select MENELAUS if ARCH_OMAP2
-	select NEON if ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5
+	select NEON if CPU_V7
 	select PM_RUNTIME
 	select REGULATOR
 	select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
@@ -115,6 +115,14 @@ config SOC_OMAP5
 	select COMMON_CLK
 	select HAVE_ARM_ARCH_TIMER
 
+config SOC_DRA7XX
+	bool "TI DRA7XX"
+	select ARM_ARCH_TIMER
+	select CPU_V7
+	select ARM_GIC
+	select HAVE_SMP
+	select COMMON_CLK
+
 comment "OMAP Core Type"
 	depends on ARCH_OMAP2
 
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index f82bae2..436ea97 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -106,7 +106,7 @@ config OMAP_32K_TIMER
 	  This timer saves power compared to the OMAP_MPU_TIMER, and has
 	  support for no tick during idle. The 32KHz timer provides less
 	  intra-tick resolution than OMAP_MPU_TIMER. The 32KHz timer is
-	  currently only available for OMAP16XX, 24XX, 34XX and OMAP4/5.
+	  currently only available for OMAP16XX, 24XX, 34XX, OMAP4/5 and DRA7XX.
 
 	  On OMAP2PLUS this value is only used for CONFIG_HZ and
 	  CLOCK_TICK_RATE compile time calculation.
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:32:09 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 13:02:09 +0530
Subject: [PATCH 02/12] ARM: DRA7: CM: Add DRA7XX register defines
In-Reply-To: <1373355139-12487-1-git-send-email-rnayak@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
Message-ID: <1373355139-12487-3-git-send-email-rnayak@ti.com>

From: Ambresh K <ambresh at ti.com>

Add the new defines for DRA7XX CM registers.

Signed-off-by: Ambresh K <ambresh at ti.com>
Signed-off-by: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/cm1_7xx.h |  323 ++++++++++++++++++++++++++
 arch/arm/mach-omap2/cm2_7xx.h |  512 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 835 insertions(+)
 create mode 100644 arch/arm/mach-omap2/cm1_7xx.h
 create mode 100644 arch/arm/mach-omap2/cm2_7xx.h

diff --git a/arch/arm/mach-omap2/cm1_7xx.h b/arch/arm/mach-omap2/cm1_7xx.h
new file mode 100644
index 0000000..2aae8c2
--- /dev/null
+++ b/arch/arm/mach-omap2/cm1_7xx.h
@@ -0,0 +1,323 @@
+/*
+ * DRA7xx CM1 instance offset macros
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Paul Walmsley (paul at pwsan.com)
+ * Rajendra Nayak (rnayak at ti.com)
+ * Benoit Cousson (b-cousson at ti.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_CM1_7XX_H
+#define __ARCH_ARM_MACH_OMAP2_CM1_7XX_H
+
+#include "cm_44xx_54xx.h"
+
+/* CM1 base address */
+#define DRA7XX_CM_CORE_AON_BASE		0x4a005000
+
+#define DRA7XX_CM_CORE_AON_REGADDR(inst, reg)				\
+	OMAP2_L4_IO_ADDRESS(DRA7XX_CM_CORE_AON_BASE + (inst) + (reg))
+
+/* CM_CORE_AON instances */
+#define DRA7XX_CM_CORE_AON_OCP_SOCKET_INST	0x0000
+#define DRA7XX_CM_CORE_AON_CKGEN_INST		0x0100
+#define DRA7XX_CM_CORE_AON_MPU_INST		0x0300
+#define DRA7XX_CM_CORE_AON_DSP1_INST		0x0400
+#define DRA7XX_CM_CORE_AON_IPU_INST		0x0500
+#define DRA7XX_CM_CORE_AON_DSP2_INST		0x0600
+#define DRA7XX_CM_CORE_AON_EVE1_INST		0x0640
+#define DRA7XX_CM_CORE_AON_EVE2_INST		0x0680
+#define DRA7XX_CM_CORE_AON_EVE3_INST		0x06c0
+#define DRA7XX_CM_CORE_AON_EVE4_INST		0x0700
+#define DRA7XX_CM_CORE_AON_RTC_INST		0x0740
+#define DRA7XX_CM_CORE_AON_VPE_INST		0x0760
+#define DRA7XX_CM_CORE_AON_RESTORE_INST		0x0e00
+#define DRA7XX_CM_CORE_AON_INSTR_INST		0x0f00
+
+/* CM_CORE_AON clockdomain register offsets (from instance start) */
+#define DRA7XX_CM_CORE_AON_MPU_MPU_CDOFFS	0x0000
+#define DRA7XX_CM_CORE_AON_DSP1_DSP1_CDOFFS	0x0000
+#define DRA7XX_CM_CORE_AON_IPU_IPU1_CDOFFS	0x0000
+#define DRA7XX_CM_CORE_AON_IPU_IPU_CDOFFS	0x0040
+#define DRA7XX_CM_CORE_AON_DSP2_DSP2_CDOFFS	0x0000
+#define DRA7XX_CM_CORE_AON_EVE1_EVE1_CDOFFS	0x0000
+#define DRA7XX_CM_CORE_AON_EVE2_EVE2_CDOFFS	0x0000
+#define DRA7XX_CM_CORE_AON_EVE3_EVE3_CDOFFS	0x0000
+#define DRA7XX_CM_CORE_AON_EVE4_EVE4_CDOFFS	0x0000
+#define DRA7XX_CM_CORE_AON_RTC_RTC_CDOFFS	0x0000
+#define DRA7XX_CM_CORE_AON_VPE_VPE_CDOFFS	0x0000
+
+/* CM_CORE_AON */
+
+/* CM_CORE_AON.OCP_SOCKET_CM_CORE_AON register offsets */
+#define DRA7XX_REVISION_CM_CORE_AON_OFFSET		0x0000
+#define DRA7XX_CM_CM_CORE_AON_PROFILING_CLKCTRL_OFFSET	0x0040
+#define DRA7XX_CM_CM_CORE_AON_PROFILING_CLKCTRL		DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_OCP_SOCKET_INST, 0x0040)
+#define DRA7XX_CM_CORE_AON_DEBUG_OUT_OFFSET		0x00ec
+#define DRA7XX_CM_CORE_AON_DEBUG_CFG0_OFFSET		0x00f0
+#define DRA7XX_CM_CORE_AON_DEBUG_CFG1_OFFSET		0x00f4
+#define DRA7XX_CM_CORE_AON_DEBUG_CFG2_OFFSET		0x00f8
+#define DRA7XX_CM_CORE_AON_DEBUG_CFG3_OFFSET		0x00fc
+
+/* CM_CORE_AON.CKGEN_CM_CORE_AON register offsets */
+#define DRA7XX_CM_CLKSEL_CORE_OFFSET			0x0000
+#define DRA7XX_CM_CLKSEL_CORE				DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0000)
+#define DRA7XX_CM_CLKSEL_ABE_OFFSET			0x0008
+#define DRA7XX_CM_CLKSEL_ABE				DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0008)
+#define DRA7XX_CM_DLL_CTRL_OFFSET			0x0010
+#define DRA7XX_CM_CLKMODE_DPLL_CORE_OFFSET		0x0020
+#define DRA7XX_CM_CLKMODE_DPLL_CORE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0020)
+#define DRA7XX_CM_IDLEST_DPLL_CORE_OFFSET		0x0024
+#define DRA7XX_CM_IDLEST_DPLL_CORE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0024)
+#define DRA7XX_CM_AUTOIDLE_DPLL_CORE_OFFSET		0x0028
+#define DRA7XX_CM_AUTOIDLE_DPLL_CORE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0028)
+#define DRA7XX_CM_CLKSEL_DPLL_CORE_OFFSET		0x002c
+#define DRA7XX_CM_CLKSEL_DPLL_CORE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x002c)
+#define DRA7XX_CM_DIV_M2_DPLL_CORE_OFFSET		0x0030
+#define DRA7XX_CM_DIV_M2_DPLL_CORE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0030)
+#define DRA7XX_CM_DIV_M3_DPLL_CORE_OFFSET		0x0034
+#define DRA7XX_CM_DIV_M3_DPLL_CORE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0034)
+#define DRA7XX_CM_DIV_H11_DPLL_CORE_OFFSET		0x0038
+#define DRA7XX_CM_DIV_H11_DPLL_CORE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0038)
+#define DRA7XX_CM_DIV_H12_DPLL_CORE_OFFSET		0x003c
+#define DRA7XX_CM_DIV_H12_DPLL_CORE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x003c)
+#define DRA7XX_CM_DIV_H13_DPLL_CORE_OFFSET		0x0040
+#define DRA7XX_CM_DIV_H13_DPLL_CORE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0040)
+#define DRA7XX_CM_DIV_H14_DPLL_CORE_OFFSET		0x0044
+#define DRA7XX_CM_DIV_H14_DPLL_CORE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0044)
+#define DRA7XX_CM_SSC_DELTAMSTEP_DPLL_CORE_OFFSET	0x0048
+#define DRA7XX_CM_SSC_MODFREQDIV_DPLL_CORE_OFFSET	0x004c
+#define DRA7XX_CM_DIV_H21_DPLL_CORE_OFFSET		0x0050
+#define DRA7XX_CM_DIV_H21_DPLL_CORE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0050)
+#define DRA7XX_CM_DIV_H22_DPLL_CORE_OFFSET		0x0054
+#define DRA7XX_CM_DIV_H22_DPLL_CORE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0054)
+#define DRA7XX_CM_DIV_H23_DPLL_CORE_OFFSET		0x0058
+#define DRA7XX_CM_DIV_H23_DPLL_CORE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0058)
+#define DRA7XX_CM_DIV_H24_DPLL_CORE_OFFSET		0x005c
+#define DRA7XX_CM_DIV_H24_DPLL_CORE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x005c)
+#define DRA7XX_CM_CLKMODE_DPLL_MPU_OFFSET		0x0060
+#define DRA7XX_CM_CLKMODE_DPLL_MPU			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0060)
+#define DRA7XX_CM_IDLEST_DPLL_MPU_OFFSET		0x0064
+#define DRA7XX_CM_IDLEST_DPLL_MPU			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0064)
+#define DRA7XX_CM_AUTOIDLE_DPLL_MPU_OFFSET		0x0068
+#define DRA7XX_CM_AUTOIDLE_DPLL_MPU			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0068)
+#define DRA7XX_CM_CLKSEL_DPLL_MPU_OFFSET		0x006c
+#define DRA7XX_CM_CLKSEL_DPLL_MPU			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x006c)
+#define DRA7XX_CM_DIV_M2_DPLL_MPU_OFFSET		0x0070
+#define DRA7XX_CM_DIV_M2_DPLL_MPU			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0070)
+#define DRA7XX_CM_SSC_DELTAMSTEP_DPLL_MPU_OFFSET	0x0088
+#define DRA7XX_CM_SSC_MODFREQDIV_DPLL_MPU_OFFSET	0x008c
+#define DRA7XX_CM_BYPCLK_DPLL_MPU_OFFSET		0x009c
+#define DRA7XX_CM_BYPCLK_DPLL_MPU			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x009c)
+#define DRA7XX_CM_CLKMODE_DPLL_IVA_OFFSET		0x00a0
+#define DRA7XX_CM_CLKMODE_DPLL_IVA			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x00a0)
+#define DRA7XX_CM_IDLEST_DPLL_IVA_OFFSET		0x00a4
+#define DRA7XX_CM_IDLEST_DPLL_IVA			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x00a4)
+#define DRA7XX_CM_AUTOIDLE_DPLL_IVA_OFFSET		0x00a8
+#define DRA7XX_CM_AUTOIDLE_DPLL_IVA			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x00a8)
+#define DRA7XX_CM_CLKSEL_DPLL_IVA_OFFSET		0x00ac
+#define DRA7XX_CM_CLKSEL_DPLL_IVA			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x00ac)
+#define DRA7XX_CM_DIV_M2_DPLL_IVA_OFFSET		0x00b0
+#define DRA7XX_CM_DIV_M2_DPLL_IVA			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x00b0)
+#define DRA7XX_CM_DIV_M3_DPLL_IVA_OFFSET		0x00b4
+#define DRA7XX_CM_DIV_M3_DPLL_IVA			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x00b4)
+#define DRA7XX_CM_SSC_DELTAMSTEP_DPLL_IVA_OFFSET	0x00c8
+#define DRA7XX_CM_SSC_MODFREQDIV_DPLL_IVA_OFFSET	0x00cc
+#define DRA7XX_CM_BYPCLK_DPLL_IVA_OFFSET		0x00dc
+#define DRA7XX_CM_BYPCLK_DPLL_IVA			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x00dc)
+#define DRA7XX_CM_CLKMODE_DPLL_ABE_OFFSET		0x00e0
+#define DRA7XX_CM_CLKMODE_DPLL_ABE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x00e0)
+#define DRA7XX_CM_IDLEST_DPLL_ABE_OFFSET		0x00e4
+#define DRA7XX_CM_IDLEST_DPLL_ABE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x00e4)
+#define DRA7XX_CM_AUTOIDLE_DPLL_ABE_OFFSET		0x00e8
+#define DRA7XX_CM_AUTOIDLE_DPLL_ABE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x00e8)
+#define DRA7XX_CM_CLKSEL_DPLL_ABE_OFFSET		0x00ec
+#define DRA7XX_CM_CLKSEL_DPLL_ABE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x00ec)
+#define DRA7XX_CM_DIV_M2_DPLL_ABE_OFFSET		0x00f0
+#define DRA7XX_CM_DIV_M2_DPLL_ABE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x00f0)
+#define DRA7XX_CM_DIV_M3_DPLL_ABE_OFFSET		0x00f4
+#define DRA7XX_CM_DIV_M3_DPLL_ABE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x00f4)
+#define DRA7XX_CM_SSC_DELTAMSTEP_DPLL_ABE_OFFSET	0x0108
+#define DRA7XX_CM_SSC_MODFREQDIV_DPLL_ABE_OFFSET	0x010c
+#define DRA7XX_CM_CLKMODE_DPLL_DDR_OFFSET		0x0110
+#define DRA7XX_CM_CLKMODE_DPLL_DDR			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0110)
+#define DRA7XX_CM_IDLEST_DPLL_DDR_OFFSET		0x0114
+#define DRA7XX_CM_IDLEST_DPLL_DDR			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0114)
+#define DRA7XX_CM_AUTOIDLE_DPLL_DDR_OFFSET		0x0118
+#define DRA7XX_CM_AUTOIDLE_DPLL_DDR			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0118)
+#define DRA7XX_CM_CLKSEL_DPLL_DDR_OFFSET		0x011c
+#define DRA7XX_CM_CLKSEL_DPLL_DDR			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x011c)
+#define DRA7XX_CM_DIV_M2_DPLL_DDR_OFFSET		0x0120
+#define DRA7XX_CM_DIV_M2_DPLL_DDR			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0120)
+#define DRA7XX_CM_DIV_M3_DPLL_DDR_OFFSET		0x0124
+#define DRA7XX_CM_DIV_M3_DPLL_DDR			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0124)
+#define DRA7XX_CM_DIV_H11_DPLL_DDR_OFFSET		0x0128
+#define DRA7XX_CM_DIV_H11_DPLL_DDR			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0128)
+#define DRA7XX_CM_SSC_DELTAMSTEP_DPLL_DDR_OFFSET	0x012c
+#define DRA7XX_CM_SSC_MODFREQDIV_DPLL_DDR_OFFSET	0x0130
+#define DRA7XX_CM_CLKMODE_DPLL_DSP_OFFSET		0x0134
+#define DRA7XX_CM_CLKMODE_DPLL_DSP			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0134)
+#define DRA7XX_CM_IDLEST_DPLL_DSP_OFFSET		0x0138
+#define DRA7XX_CM_IDLEST_DPLL_DSP			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0138)
+#define DRA7XX_CM_AUTOIDLE_DPLL_DSP_OFFSET		0x013c
+#define DRA7XX_CM_AUTOIDLE_DPLL_DSP			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x013c)
+#define DRA7XX_CM_CLKSEL_DPLL_DSP_OFFSET		0x0140
+#define DRA7XX_CM_CLKSEL_DPLL_DSP			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0140)
+#define DRA7XX_CM_DIV_M2_DPLL_DSP_OFFSET		0x0144
+#define DRA7XX_CM_DIV_M2_DPLL_DSP			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0144)
+#define DRA7XX_CM_DIV_M3_DPLL_DSP_OFFSET		0x0148
+#define DRA7XX_CM_DIV_M3_DPLL_DSP			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0148)
+#define DRA7XX_CM_SSC_DELTAMSTEP_DPLL_DSP_OFFSET	0x014c
+#define DRA7XX_CM_SSC_MODFREQDIV_DPLL_DSP_OFFSET	0x0150
+#define DRA7XX_CM_BYPCLK_DPLL_DSP_OFFSET		0x0154
+#define DRA7XX_CM_BYPCLK_DPLL_DSP			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0154)
+#define DRA7XX_CM_SHADOW_FREQ_CONFIG1_OFFSET		0x0160
+#define DRA7XX_CM_SHADOW_FREQ_CONFIG2_OFFSET		0x0164
+#define DRA7XX_CM_DYN_DEP_PRESCAL_OFFSET		0x0170
+#define DRA7XX_CM_RESTORE_ST_OFFSET			0x0180
+#define DRA7XX_CM_CLKMODE_DPLL_EVE_OFFSET		0x0184
+#define DRA7XX_CM_CLKMODE_DPLL_EVE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0184)
+#define DRA7XX_CM_IDLEST_DPLL_EVE_OFFSET		0x0188
+#define DRA7XX_CM_IDLEST_DPLL_EVE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0188)
+#define DRA7XX_CM_AUTOIDLE_DPLL_EVE_OFFSET		0x018c
+#define DRA7XX_CM_AUTOIDLE_DPLL_EVE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x018c)
+#define DRA7XX_CM_CLKSEL_DPLL_EVE_OFFSET		0x0190
+#define DRA7XX_CM_CLKSEL_DPLL_EVE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0190)
+#define DRA7XX_CM_DIV_M2_DPLL_EVE_OFFSET		0x0194
+#define DRA7XX_CM_DIV_M2_DPLL_EVE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0194)
+#define DRA7XX_CM_DIV_M3_DPLL_EVE_OFFSET		0x0198
+#define DRA7XX_CM_DIV_M3_DPLL_EVE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x0198)
+#define DRA7XX_CM_SSC_DELTAMSTEP_DPLL_EVE_OFFSET	0x019c
+#define DRA7XX_CM_SSC_MODFREQDIV_DPLL_EVE_OFFSET	0x01a0
+#define DRA7XX_CM_BYPCLK_DPLL_EVE_OFFSET		0x01a4
+#define DRA7XX_CM_BYPCLK_DPLL_EVE			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01a4)
+#define DRA7XX_CM_CLKMODE_DPLL_GMAC_OFFSET		0x01a8
+#define DRA7XX_CM_CLKMODE_DPLL_GMAC			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01a8)
+#define DRA7XX_CM_IDLEST_DPLL_GMAC_OFFSET		0x01ac
+#define DRA7XX_CM_IDLEST_DPLL_GMAC			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01ac)
+#define DRA7XX_CM_AUTOIDLE_DPLL_GMAC_OFFSET		0x01b0
+#define DRA7XX_CM_AUTOIDLE_DPLL_GMAC			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01b0)
+#define DRA7XX_CM_CLKSEL_DPLL_GMAC_OFFSET		0x01b4
+#define DRA7XX_CM_CLKSEL_DPLL_GMAC			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01b4)
+#define DRA7XX_CM_DIV_M2_DPLL_GMAC_OFFSET		0x01b8
+#define DRA7XX_CM_DIV_M2_DPLL_GMAC			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01b8)
+#define DRA7XX_CM_DIV_M3_DPLL_GMAC_OFFSET		0x01bc
+#define DRA7XX_CM_DIV_M3_DPLL_GMAC			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01bc)
+#define DRA7XX_CM_DIV_H11_DPLL_GMAC_OFFSET		0x01c0
+#define DRA7XX_CM_DIV_H11_DPLL_GMAC			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01c0)
+#define DRA7XX_CM_DIV_H12_DPLL_GMAC_OFFSET		0x01c4
+#define DRA7XX_CM_DIV_H12_DPLL_GMAC			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01c4)
+#define DRA7XX_CM_DIV_H13_DPLL_GMAC_OFFSET		0x01c8
+#define DRA7XX_CM_DIV_H13_DPLL_GMAC			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01c8)
+#define DRA7XX_CM_DIV_H14_DPLL_GMAC_OFFSET		0x01cc
+#define DRA7XX_CM_DIV_H14_DPLL_GMAC			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01cc)
+#define DRA7XX_CM_SSC_DELTAMSTEP_DPLL_GMAC_OFFSET	0x01d0
+#define DRA7XX_CM_SSC_MODFREQDIV_DPLL_GMAC_OFFSET	0x01d4
+#define DRA7XX_CM_CLKMODE_DPLL_GPU_OFFSET		0x01d8
+#define DRA7XX_CM_CLKMODE_DPLL_GPU			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01d8)
+#define DRA7XX_CM_IDLEST_DPLL_GPU_OFFSET		0x01dc
+#define DRA7XX_CM_IDLEST_DPLL_GPU			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01dc)
+#define DRA7XX_CM_AUTOIDLE_DPLL_GPU_OFFSET		0x01e0
+#define DRA7XX_CM_AUTOIDLE_DPLL_GPU			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01e0)
+#define DRA7XX_CM_CLKSEL_DPLL_GPU_OFFSET		0x01e4
+#define DRA7XX_CM_CLKSEL_DPLL_GPU			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01e4)
+#define DRA7XX_CM_DIV_M2_DPLL_GPU_OFFSET		0x01e8
+#define DRA7XX_CM_DIV_M2_DPLL_GPU			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01e8)
+#define DRA7XX_CM_DIV_M3_DPLL_GPU_OFFSET		0x01ec
+#define DRA7XX_CM_DIV_M3_DPLL_GPU			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_CKGEN_INST, 0x01ec)
+#define DRA7XX_CM_SSC_DELTAMSTEP_DPLL_GPU_OFFSET	0x01f0
+#define DRA7XX_CM_SSC_MODFREQDIV_DPLL_GPU_OFFSET	0x01f4
+
+/* CM_CORE_AON.MPU_CM_CORE_AON register offsets */
+#define DRA7XX_CM_MPU_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_MPU_STATICDEP_OFFSET			0x0004
+#define DRA7XX_CM_MPU_DYNAMICDEP_OFFSET			0x0008
+#define DRA7XX_CM_MPU_MPU_CLKCTRL_OFFSET		0x0020
+#define DRA7XX_CM_MPU_MPU_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_MPU_INST, 0x0020)
+#define DRA7XX_CM_MPU_MPU_MPU_DBG_CLKCTRL_OFFSET	0x0028
+#define DRA7XX_CM_MPU_MPU_MPU_DBG_CLKCTRL		DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_MPU_INST, 0x0028)
+
+/* CM_CORE_AON.DSP1_CM_CORE_AON register offsets */
+#define DRA7XX_CM_DSP1_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_DSP1_STATICDEP_OFFSET			0x0004
+#define DRA7XX_CM_DSP1_DYNAMICDEP_OFFSET		0x0008
+#define DRA7XX_CM_DSP1_DSP1_CLKCTRL_OFFSET		0x0020
+#define DRA7XX_CM_DSP1_DSP1_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_DSP1_INST, 0x0020)
+
+/* CM_CORE_AON.IPU_CM_CORE_AON register offsets */
+#define DRA7XX_CM_IPU1_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_IPU1_STATICDEP_OFFSET			0x0004
+#define DRA7XX_CM_IPU1_DYNAMICDEP_OFFSET		0x0008
+#define DRA7XX_CM_IPU1_IPU1_CLKCTRL_OFFSET		0x0020
+#define DRA7XX_CM_IPU1_IPU1_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_IPU_INST, 0x0020)
+#define DRA7XX_CM_IPU_CLKSTCTRL_OFFSET			0x0040
+#define DRA7XX_CM_IPU_MCASP1_CLKCTRL_OFFSET		0x0050
+#define DRA7XX_CM_IPU_MCASP1_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_IPU_INST, 0x0050)
+#define DRA7XX_CM_IPU_TIMER5_CLKCTRL_OFFSET		0x0058
+#define DRA7XX_CM_IPU_TIMER5_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_IPU_INST, 0x0058)
+#define DRA7XX_CM_IPU_TIMER6_CLKCTRL_OFFSET		0x0060
+#define DRA7XX_CM_IPU_TIMER6_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_IPU_INST, 0x0060)
+#define DRA7XX_CM_IPU_TIMER7_CLKCTRL_OFFSET		0x0068
+#define DRA7XX_CM_IPU_TIMER7_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_IPU_INST, 0x0068)
+#define DRA7XX_CM_IPU_TIMER8_CLKCTRL_OFFSET		0x0070
+#define DRA7XX_CM_IPU_TIMER8_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_IPU_INST, 0x0070)
+#define DRA7XX_CM_IPU_I2C5_CLKCTRL_OFFSET		0x0078
+#define DRA7XX_CM_IPU_I2C5_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_IPU_INST, 0x0078)
+#define DRA7XX_CM_IPU_UART6_CLKCTRL_OFFSET		0x0080
+#define DRA7XX_CM_IPU_UART6_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_IPU_INST, 0x0080)
+
+/* CM_CORE_AON.DSP2_CM_CORE_AON register offsets */
+#define DRA7XX_CM_DSP2_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_DSP2_STATICDEP_OFFSET			0x0004
+#define DRA7XX_CM_DSP2_DYNAMICDEP_OFFSET		0x0008
+#define DRA7XX_CM_DSP2_DSP2_CLKCTRL_OFFSET		0x0020
+#define DRA7XX_CM_DSP2_DSP2_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_DSP2_INST, 0x0020)
+
+/* CM_CORE_AON.EVE1_CM_CORE_AON register offsets */
+#define DRA7XX_CM_EVE1_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_EVE1_STATICDEP_OFFSET			0x0004
+#define DRA7XX_CM_EVE1_EVE1_CLKCTRL_OFFSET		0x0020
+#define DRA7XX_CM_EVE1_EVE1_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_EVE1_INST, 0x0020)
+
+/* CM_CORE_AON.EVE2_CM_CORE_AON register offsets */
+#define DRA7XX_CM_EVE2_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_EVE2_STATICDEP_OFFSET			0x0004
+#define DRA7XX_CM_EVE2_EVE2_CLKCTRL_OFFSET		0x0020
+#define DRA7XX_CM_EVE2_EVE2_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_EVE2_INST, 0x0020)
+
+/* CM_CORE_AON.EVE3_CM_CORE_AON register offsets */
+#define DRA7XX_CM_EVE3_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_EVE3_STATICDEP_OFFSET			0x0004
+#define DRA7XX_CM_EVE3_EVE3_CLKCTRL_OFFSET		0x0020
+#define DRA7XX_CM_EVE3_EVE3_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_EVE3_INST, 0x0020)
+
+/* CM_CORE_AON.EVE4_CM_CORE_AON register offsets */
+#define DRA7XX_CM_EVE4_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_EVE4_STATICDEP_OFFSET			0x0004
+#define DRA7XX_CM_EVE4_EVE4_CLKCTRL_OFFSET		0x0020
+#define DRA7XX_CM_EVE4_EVE4_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_EVE4_INST, 0x0020)
+
+/* CM_CORE_AON.RTC_CM_CORE_AON register offsets */
+#define DRA7XX_CM_RTC_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_RTC_RTCSS_CLKCTRL_OFFSET		0x0004
+#define DRA7XX_CM_RTC_RTCSS_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_RTC_INST, 0x0004)
+
+/* CM_CORE_AON.VPE_CM_CORE_AON register offsets */
+#define DRA7XX_CM_VPE_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_VPE_VPE_CLKCTRL_OFFSET		0x0004
+#define DRA7XX_CM_VPE_VPE_CLKCTRL			DRA7XX_CM_CORE_AON_REGADDR(DRA7XX_CM_CORE_AON_VPE_INST, 0x0004)
+#define DRA7XX_CM_VPE_STATICDEP_OFFSET			0x0008
+
+#endif
diff --git a/arch/arm/mach-omap2/cm2_7xx.h b/arch/arm/mach-omap2/cm2_7xx.h
new file mode 100644
index 0000000..881d52b
--- /dev/null
+++ b/arch/arm/mach-omap2/cm2_7xx.h
@@ -0,0 +1,512 @@
+/*
+ * DRA7xx CM2 instance offset macros
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Paul Walmsley (paul at pwsan.com)
+ * Rajendra Nayak (rnayak at ti.com)
+ * Benoit Cousson (b-cousson at ti.com)
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_CM2_7XX_H
+#define __ARCH_ARM_MACH_OMAP2_CM2_7XX_H
+
+#include "cm_44xx_54xx.h"
+
+/* CM2 base address */
+#define DRA7XX_CM_CORE_BASE		0x4a008000
+
+#define DRA7XX_CM_CORE_REGADDR(inst, reg)				\
+	OMAP2_L4_IO_ADDRESS(DRA7XX_CM_CORE_BASE + (inst) + (reg))
+
+/* CM_CORE instances */
+#define DRA7XX_CM_CORE_OCP_SOCKET_INST	0x0000
+#define DRA7XX_CM_CORE_CKGEN_INST	0x0104
+#define DRA7XX_CM_CORE_COREAON_INST	0x0600
+#define DRA7XX_CM_CORE_CORE_INST	0x0700
+#define DRA7XX_CM_CORE_IVA_INST		0x0f00
+#define DRA7XX_CM_CORE_CAM_INST		0x1000
+#define DRA7XX_CM_CORE_DSS_INST		0x1100
+#define DRA7XX_CM_CORE_GPU_INST		0x1200
+#define DRA7XX_CM_CORE_L3INIT_INST	0x1300
+#define DRA7XX_CM_CORE_CUSTEFUSE_INST	0x1600
+#define DRA7XX_CM_CORE_L4PER_INST	0x1700
+#define DRA7XX_CM_CORE_RESTORE_INST	0x1e18
+
+/* CM_CORE clockdomain register offsets (from instance start) */
+#define DRA7XX_CM_CORE_COREAON_COREAON_CDOFFS		0x0000
+#define DRA7XX_CM_CORE_CORE_L3MAIN1_CDOFFS		0x0000
+#define DRA7XX_CM_CORE_CORE_IPU2_CDOFFS			0x0200
+#define DRA7XX_CM_CORE_CORE_DMA_CDOFFS			0x0300
+#define DRA7XX_CM_CORE_CORE_EMIF_CDOFFS			0x0400
+#define DRA7XX_CM_CORE_CORE_ATL_CDOFFS			0x0520
+#define DRA7XX_CM_CORE_CORE_L4CFG_CDOFFS		0x0600
+#define DRA7XX_CM_CORE_CORE_L3INSTR_CDOFFS		0x0700
+#define DRA7XX_CM_CORE_IVA_IVA_CDOFFS			0x0000
+#define DRA7XX_CM_CORE_CAM_CAM_CDOFFS			0x0000
+#define DRA7XX_CM_CORE_DSS_DSS_CDOFFS			0x0000
+#define DRA7XX_CM_CORE_GPU_GPU_CDOFFS			0x0000
+#define DRA7XX_CM_CORE_L3INIT_L3INIT_CDOFFS		0x0000
+#define DRA7XX_CM_CORE_L3INIT_PCIE_CDOFFS		0x00a0
+#define DRA7XX_CM_CORE_L3INIT_GMAC_CDOFFS		0x00c0
+#define DRA7XX_CM_CORE_CUSTEFUSE_CUSTEFUSE_CDOFFS	0x0000
+#define DRA7XX_CM_CORE_L4PER_L4PER_CDOFFS		0x0000
+#define DRA7XX_CM_CORE_L4PER_L4SEC_CDOFFS		0x0180
+#define DRA7XX_CM_CORE_L4PER_L4PER2_CDOFFS		0x01fc
+#define DRA7XX_CM_CORE_L4PER_L4PER3_CDOFFS		0x0210
+
+/* CM_CORE */
+
+/* CM_CORE.OCP_SOCKET_CM_CORE register offsets */
+#define DRA7XX_REVISION_CM_CORE_OFFSET				0x0000
+#define DRA7XX_CM_CM_CORE_PROFILING_CLKCTRL_OFFSET		0x0040
+#define DRA7XX_CM_CM_CORE_PROFILING_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_OCP_SOCKET_INST, 0x0040)
+#define DRA7XX_CM_CORE_DEBUG_CFG_OFFSET				0x00f0
+
+/* CM_CORE.CKGEN_CM_CORE register offsets */
+#define DRA7XX_CM_CLKSEL_USB_60MHZ_OFFSET			0x0000
+#define DRA7XX_CM_CLKSEL_USB_60MHZ				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0000)
+#define DRA7XX_CM_CLKMODE_DPLL_PER_OFFSET			0x003c
+#define DRA7XX_CM_CLKMODE_DPLL_PER				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x003c)
+#define DRA7XX_CM_IDLEST_DPLL_PER_OFFSET			0x0040
+#define DRA7XX_CM_IDLEST_DPLL_PER				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0040)
+#define DRA7XX_CM_AUTOIDLE_DPLL_PER_OFFSET			0x0044
+#define DRA7XX_CM_AUTOIDLE_DPLL_PER				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0044)
+#define DRA7XX_CM_CLKSEL_DPLL_PER_OFFSET			0x0048
+#define DRA7XX_CM_CLKSEL_DPLL_PER				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0048)
+#define DRA7XX_CM_DIV_M2_DPLL_PER_OFFSET			0x004c
+#define DRA7XX_CM_DIV_M2_DPLL_PER				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x004c)
+#define DRA7XX_CM_DIV_M3_DPLL_PER_OFFSET			0x0050
+#define DRA7XX_CM_DIV_M3_DPLL_PER				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0050)
+#define DRA7XX_CM_DIV_H11_DPLL_PER_OFFSET			0x0054
+#define DRA7XX_CM_DIV_H11_DPLL_PER				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0054)
+#define DRA7XX_CM_DIV_H12_DPLL_PER_OFFSET			0x0058
+#define DRA7XX_CM_DIV_H12_DPLL_PER				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0058)
+#define DRA7XX_CM_DIV_H13_DPLL_PER_OFFSET			0x005c
+#define DRA7XX_CM_DIV_H13_DPLL_PER				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x005c)
+#define DRA7XX_CM_DIV_H14_DPLL_PER_OFFSET			0x0060
+#define DRA7XX_CM_DIV_H14_DPLL_PER				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0060)
+#define DRA7XX_CM_SSC_DELTAMSTEP_DPLL_PER_OFFSET		0x0064
+#define DRA7XX_CM_SSC_MODFREQDIV_DPLL_PER_OFFSET		0x0068
+#define DRA7XX_CM_CLKMODE_DPLL_USB_OFFSET			0x007c
+#define DRA7XX_CM_CLKMODE_DPLL_USB				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x007c)
+#define DRA7XX_CM_IDLEST_DPLL_USB_OFFSET			0x0080
+#define DRA7XX_CM_IDLEST_DPLL_USB				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0080)
+#define DRA7XX_CM_AUTOIDLE_DPLL_USB_OFFSET			0x0084
+#define DRA7XX_CM_AUTOIDLE_DPLL_USB				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0084)
+#define DRA7XX_CM_CLKSEL_DPLL_USB_OFFSET			0x0088
+#define DRA7XX_CM_CLKSEL_DPLL_USB				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0088)
+#define DRA7XX_CM_DIV_M2_DPLL_USB_OFFSET			0x008c
+#define DRA7XX_CM_DIV_M2_DPLL_USB				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x008c)
+#define DRA7XX_CM_SSC_DELTAMSTEP_DPLL_USB_OFFSET		0x00a4
+#define DRA7XX_CM_SSC_MODFREQDIV_DPLL_USB_OFFSET		0x00a8
+#define DRA7XX_CM_CLKDCOLDO_DPLL_USB_OFFSET			0x00b0
+#define DRA7XX_CM_CLKDCOLDO_DPLL_USB				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x00b0)
+#define DRA7XX_CM_CLKMODE_DPLL_PCIE_REF_OFFSET			0x00fc
+#define DRA7XX_CM_CLKMODE_DPLL_PCIE_REF				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x00fc)
+#define DRA7XX_CM_IDLEST_DPLL_PCIE_REF_OFFSET			0x0100
+#define DRA7XX_CM_IDLEST_DPLL_PCIE_REF				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0100)
+#define DRA7XX_CM_AUTOIDLE_DPLL_PCIE_REF_OFFSET			0x0104
+#define DRA7XX_CM_AUTOIDLE_DPLL_PCIE_REF			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0104)
+#define DRA7XX_CM_CLKSEL_DPLL_PCIE_REF_OFFSET			0x0108
+#define DRA7XX_CM_CLKSEL_DPLL_PCIE_REF				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0108)
+#define DRA7XX_CM_DIV_M2_DPLL_PCIE_REF_OFFSET			0x010c
+#define DRA7XX_CM_DIV_M2_DPLL_PCIE_REF				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x010c)
+#define DRA7XX_CM_SSC_DELTAMSTEP_DPLL_PCIE_REF_OFFSET		0x0110
+#define DRA7XX_CM_SSC_MODFREQDIV_DPLL_PCIE_REF_OFFSET		0x0114
+#define DRA7XX_CM_CLKMODE_APLL_PCIE_OFFSET			0x0118
+#define DRA7XX_CM_CLKMODE_APLL_PCIE				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0118)
+#define DRA7XX_CM_IDLEST_APLL_PCIE_OFFSET			0x011c
+#define DRA7XX_CM_IDLEST_APLL_PCIE				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x011c)
+#define DRA7XX_CM_DIV_M2_APLL_PCIE_OFFSET			0x0120
+#define DRA7XX_CM_DIV_M2_APLL_PCIE				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0120)
+#define DRA7XX_CM_CLKVCOLDO_APLL_PCIE_OFFSET			0x0124
+#define DRA7XX_CM_CLKVCOLDO_APLL_PCIE				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CKGEN_INST, 0x0124)
+
+/* CM_CORE.COREAON_CM_CORE register offsets */
+#define DRA7XX_CM_COREAON_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_COREAON_SMARTREFLEX_MPU_CLKCTRL_OFFSET	0x0028
+#define DRA7XX_CM_COREAON_SMARTREFLEX_MPU_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_COREAON_INST, 0x0028)
+#define DRA7XX_CM_COREAON_SMARTREFLEX_CORE_CLKCTRL_OFFSET	0x0038
+#define DRA7XX_CM_COREAON_SMARTREFLEX_CORE_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_COREAON_INST, 0x0038)
+#define DRA7XX_CM_COREAON_USB_PHY1_CORE_CLKCTRL_OFFSET		0x0040
+#define DRA7XX_CM_COREAON_USB_PHY1_CORE_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_COREAON_INST, 0x0040)
+#define DRA7XX_CM_COREAON_IO_SRCOMP_CLKCTRL_OFFSET		0x0050
+#define DRA7XX_CM_COREAON_IO_SRCOMP_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_COREAON_INST, 0x0050)
+#define DRA7XX_CM_COREAON_SMARTREFLEX_GPU_CLKCTRL_OFFSET	0x0058
+#define DRA7XX_CM_COREAON_SMARTREFLEX_GPU_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_COREAON_INST, 0x0058)
+#define DRA7XX_CM_COREAON_SMARTREFLEX_DSPEVE_CLKCTRL_OFFSET	0x0068
+#define DRA7XX_CM_COREAON_SMARTREFLEX_DSPEVE_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_COREAON_INST, 0x0068)
+#define DRA7XX_CM_COREAON_SMARTREFLEX_IVAHD_CLKCTRL_OFFSET	0x0078
+#define DRA7XX_CM_COREAON_SMARTREFLEX_IVAHD_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_COREAON_INST, 0x0078)
+#define DRA7XX_CM_COREAON_USB_PHY2_CORE_CLKCTRL_OFFSET		0x0088
+#define DRA7XX_CM_COREAON_USB_PHY2_CORE_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_COREAON_INST, 0x0088)
+#define DRA7XX_CM_COREAON_USB_PHY3_CORE_CLKCTRL_OFFSET		0x0098
+#define DRA7XX_CM_COREAON_USB_PHY3_CORE_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_COREAON_INST, 0x0098)
+#define DRA7XX_CM_COREAON_DUMMY_MODULE1_CLKCTRL_OFFSET		0x00a0
+#define DRA7XX_CM_COREAON_DUMMY_MODULE1_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_COREAON_INST, 0x00a0)
+#define DRA7XX_CM_COREAON_DUMMY_MODULE2_CLKCTRL_OFFSET		0x00b0
+#define DRA7XX_CM_COREAON_DUMMY_MODULE2_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_COREAON_INST, 0x00b0)
+#define DRA7XX_CM_COREAON_DUMMY_MODULE3_CLKCTRL_OFFSET		0x00c0
+#define DRA7XX_CM_COREAON_DUMMY_MODULE3_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_COREAON_INST, 0x00c0)
+#define DRA7XX_CM_COREAON_DUMMY_MODULE4_CLKCTRL_OFFSET		0x00d0
+#define DRA7XX_CM_COREAON_DUMMY_MODULE4_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_COREAON_INST, 0x00d0)
+
+/* CM_CORE.CORE_CM_CORE register offsets */
+#define DRA7XX_CM_L3MAIN1_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_L3MAIN1_DYNAMICDEP_OFFSET			0x0008
+#define DRA7XX_CM_L3MAIN1_L3_MAIN_1_CLKCTRL_OFFSET		0x0020
+#define DRA7XX_CM_L3MAIN1_L3_MAIN_1_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0020)
+#define DRA7XX_CM_L3MAIN1_GPMC_CLKCTRL_OFFSET			0x0028
+#define DRA7XX_CM_L3MAIN1_GPMC_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0028)
+#define DRA7XX_CM_L3MAIN1_MMU_EDMA_CLKCTRL_OFFSET		0x0030
+#define DRA7XX_CM_L3MAIN1_MMU_EDMA_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0030)
+#define DRA7XX_CM_L3MAIN1_OCMC_RAM1_CLKCTRL_OFFSET		0x0050
+#define DRA7XX_CM_L3MAIN1_OCMC_RAM1_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0050)
+#define DRA7XX_CM_L3MAIN1_OCMC_RAM2_CLKCTRL_OFFSET		0x0058
+#define DRA7XX_CM_L3MAIN1_OCMC_RAM2_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0058)
+#define DRA7XX_CM_L3MAIN1_OCMC_RAM3_CLKCTRL_OFFSET		0x0060
+#define DRA7XX_CM_L3MAIN1_OCMC_RAM3_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0060)
+#define DRA7XX_CM_L3MAIN1_OCMC_ROM_CLKCTRL_OFFSET		0x0068
+#define DRA7XX_CM_L3MAIN1_OCMC_ROM_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0068)
+#define DRA7XX_CM_L3MAIN1_TPCC_CLKCTRL_OFFSET			0x0070
+#define DRA7XX_CM_L3MAIN1_TPCC_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0070)
+#define DRA7XX_CM_L3MAIN1_TPTC1_CLKCTRL_OFFSET			0x0078
+#define DRA7XX_CM_L3MAIN1_TPTC1_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0078)
+#define DRA7XX_CM_L3MAIN1_TPTC2_CLKCTRL_OFFSET			0x0080
+#define DRA7XX_CM_L3MAIN1_TPTC2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0080)
+#define DRA7XX_CM_L3MAIN1_VCP1_CLKCTRL_OFFSET			0x0088
+#define DRA7XX_CM_L3MAIN1_VCP1_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0088)
+#define DRA7XX_CM_L3MAIN1_VCP2_CLKCTRL_OFFSET			0x0090
+#define DRA7XX_CM_L3MAIN1_VCP2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0090)
+#define DRA7XX_CM_L3MAIN1_SPARE_CME_CLKCTRL_OFFSET		0x0098
+#define DRA7XX_CM_L3MAIN1_SPARE_CME_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0098)
+#define DRA7XX_CM_L3MAIN1_SPARE_HDMI_CLKCTRL_OFFSET		0x00a0
+#define DRA7XX_CM_L3MAIN1_SPARE_HDMI_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x00a0)
+#define DRA7XX_CM_L3MAIN1_SPARE_ICM_CLKCTRL_OFFSET		0x00a8
+#define DRA7XX_CM_L3MAIN1_SPARE_ICM_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x00a8)
+#define DRA7XX_CM_L3MAIN1_SPARE_IVA2_CLKCTRL_OFFSET		0x00b0
+#define DRA7XX_CM_L3MAIN1_SPARE_IVA2_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x00b0)
+#define DRA7XX_CM_L3MAIN1_SPARE_SATA2_CLKCTRL_OFFSET		0x00b8
+#define DRA7XX_CM_L3MAIN1_SPARE_SATA2_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x00b8)
+#define DRA7XX_CM_L3MAIN1_SPARE_UNKNOWN4_CLKCTRL_OFFSET		0x00c0
+#define DRA7XX_CM_L3MAIN1_SPARE_UNKNOWN4_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x00c0)
+#define DRA7XX_CM_L3MAIN1_SPARE_UNKNOWN5_CLKCTRL_OFFSET		0x00c8
+#define DRA7XX_CM_L3MAIN1_SPARE_UNKNOWN5_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x00c8)
+#define DRA7XX_CM_L3MAIN1_SPARE_UNKNOWN6_CLKCTRL_OFFSET		0x00d0
+#define DRA7XX_CM_L3MAIN1_SPARE_UNKNOWN6_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x00d0)
+#define DRA7XX_CM_L3MAIN1_SPARE_VIDEOPLL1_CLKCTRL_OFFSET	0x00d8
+#define DRA7XX_CM_L3MAIN1_SPARE_VIDEOPLL1_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x00d8)
+#define DRA7XX_CM_L3MAIN1_SPARE_VIDEOPLL2_CLKCTRL_OFFSET	0x00f0
+#define DRA7XX_CM_L3MAIN1_SPARE_VIDEOPLL2_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x00f0)
+#define DRA7XX_CM_L3MAIN1_SPARE_VIDEOPLL3_CLKCTRL_OFFSET	0x00f8
+#define DRA7XX_CM_L3MAIN1_SPARE_VIDEOPLL3_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x00f8)
+#define DRA7XX_CM_IPU2_CLKSTCTRL_OFFSET				0x0200
+#define DRA7XX_CM_IPU2_STATICDEP_OFFSET				0x0204
+#define DRA7XX_CM_IPU2_DYNAMICDEP_OFFSET			0x0208
+#define DRA7XX_CM_IPU2_IPU2_CLKCTRL_OFFSET			0x0220
+#define DRA7XX_CM_IPU2_IPU2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0220)
+#define DRA7XX_CM_DMA_CLKSTCTRL_OFFSET				0x0300
+#define DRA7XX_CM_DMA_STATICDEP_OFFSET				0x0304
+#define DRA7XX_CM_DMA_DYNAMICDEP_OFFSET				0x0308
+#define DRA7XX_CM_DMA_DMA_SYSTEM_CLKCTRL_OFFSET			0x0320
+#define DRA7XX_CM_DMA_DMA_SYSTEM_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0320)
+#define DRA7XX_CM_EMIF_CLKSTCTRL_OFFSET				0x0400
+#define DRA7XX_CM_EMIF_DMM_CLKCTRL_OFFSET			0x0420
+#define DRA7XX_CM_EMIF_DMM_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0420)
+#define DRA7XX_CM_EMIF_EMIF_OCP_FW_CLKCTRL_OFFSET		0x0428
+#define DRA7XX_CM_EMIF_EMIF_OCP_FW_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0428)
+#define DRA7XX_CM_EMIF_EMIF1_CLKCTRL_OFFSET			0x0430
+#define DRA7XX_CM_EMIF_EMIF1_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0430)
+#define DRA7XX_CM_EMIF_EMIF2_CLKCTRL_OFFSET			0x0438
+#define DRA7XX_CM_EMIF_EMIF2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0438)
+#define DRA7XX_CM_EMIF_EMIF_DLL_CLKCTRL_OFFSET			0x0440
+#define DRA7XX_CM_EMIF_EMIF_DLL_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0440)
+#define DRA7XX_CM_ATL_ATL_CLKCTRL_OFFSET			0x0500
+#define DRA7XX_CM_ATL_ATL_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0500)
+#define DRA7XX_CM_ATL_CLKSTCTRL_OFFSET				0x0520
+#define DRA7XX_CM_L4CFG_CLKSTCTRL_OFFSET			0x0600
+#define DRA7XX_CM_L4CFG_DYNAMICDEP_OFFSET			0x0608
+#define DRA7XX_CM_L4CFG_L4_CFG_CLKCTRL_OFFSET			0x0620
+#define DRA7XX_CM_L4CFG_L4_CFG_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0620)
+#define DRA7XX_CM_L4CFG_SPINLOCK_CLKCTRL_OFFSET			0x0628
+#define DRA7XX_CM_L4CFG_SPINLOCK_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0628)
+#define DRA7XX_CM_L4CFG_MAILBOX1_CLKCTRL_OFFSET			0x0630
+#define DRA7XX_CM_L4CFG_MAILBOX1_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0630)
+#define DRA7XX_CM_L4CFG_SAR_ROM_CLKCTRL_OFFSET			0x0638
+#define DRA7XX_CM_L4CFG_SAR_ROM_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0638)
+#define DRA7XX_CM_L4CFG_OCP2SCP2_CLKCTRL_OFFSET			0x0640
+#define DRA7XX_CM_L4CFG_OCP2SCP2_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0640)
+#define DRA7XX_CM_L4CFG_MAILBOX2_CLKCTRL_OFFSET			0x0648
+#define DRA7XX_CM_L4CFG_MAILBOX2_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0648)
+#define DRA7XX_CM_L4CFG_MAILBOX3_CLKCTRL_OFFSET			0x0650
+#define DRA7XX_CM_L4CFG_MAILBOX3_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0650)
+#define DRA7XX_CM_L4CFG_MAILBOX4_CLKCTRL_OFFSET			0x0658
+#define DRA7XX_CM_L4CFG_MAILBOX4_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0658)
+#define DRA7XX_CM_L4CFG_MAILBOX5_CLKCTRL_OFFSET			0x0660
+#define DRA7XX_CM_L4CFG_MAILBOX5_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0660)
+#define DRA7XX_CM_L4CFG_MAILBOX6_CLKCTRL_OFFSET			0x0668
+#define DRA7XX_CM_L4CFG_MAILBOX6_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0668)
+#define DRA7XX_CM_L4CFG_MAILBOX7_CLKCTRL_OFFSET			0x0670
+#define DRA7XX_CM_L4CFG_MAILBOX7_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0670)
+#define DRA7XX_CM_L4CFG_MAILBOX8_CLKCTRL_OFFSET			0x0678
+#define DRA7XX_CM_L4CFG_MAILBOX8_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0678)
+#define DRA7XX_CM_L4CFG_MAILBOX9_CLKCTRL_OFFSET			0x0680
+#define DRA7XX_CM_L4CFG_MAILBOX9_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0680)
+#define DRA7XX_CM_L4CFG_MAILBOX10_CLKCTRL_OFFSET		0x0688
+#define DRA7XX_CM_L4CFG_MAILBOX10_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0688)
+#define DRA7XX_CM_L4CFG_MAILBOX11_CLKCTRL_OFFSET		0x0690
+#define DRA7XX_CM_L4CFG_MAILBOX11_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0690)
+#define DRA7XX_CM_L4CFG_MAILBOX12_CLKCTRL_OFFSET		0x0698
+#define DRA7XX_CM_L4CFG_MAILBOX12_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0698)
+#define DRA7XX_CM_L4CFG_MAILBOX13_CLKCTRL_OFFSET		0x06a0
+#define DRA7XX_CM_L4CFG_MAILBOX13_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x06a0)
+#define DRA7XX_CM_L4CFG_SPARE_SMARTREFLEX_RTC_CLKCTRL_OFFSET	0x06a8
+#define DRA7XX_CM_L4CFG_SPARE_SMARTREFLEX_RTC_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x06a8)
+#define DRA7XX_CM_L4CFG_SPARE_SMARTREFLEX_SDRAM_CLKCTRL_OFFSET	0x06b0
+#define DRA7XX_CM_L4CFG_SPARE_SMARTREFLEX_SDRAM_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x06b0)
+#define DRA7XX_CM_L4CFG_SPARE_SMARTREFLEX_WKUP_CLKCTRL_OFFSET	0x06b8
+#define DRA7XX_CM_L4CFG_SPARE_SMARTREFLEX_WKUP_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x06b8)
+#define DRA7XX_CM_L4CFG_IO_DELAY_BLOCK_CLKCTRL_OFFSET		0x06c0
+#define DRA7XX_CM_L4CFG_IO_DELAY_BLOCK_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x06c0)
+#define DRA7XX_CM_L3INSTR_CLKSTCTRL_OFFSET			0x0700
+#define DRA7XX_CM_L3INSTR_L3_MAIN_2_CLKCTRL_OFFSET		0x0720
+#define DRA7XX_CM_L3INSTR_L3_MAIN_2_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0720)
+#define DRA7XX_CM_L3INSTR_L3_INSTR_CLKCTRL_OFFSET		0x0728
+#define DRA7XX_CM_L3INSTR_L3_INSTR_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0728)
+#define DRA7XX_CM_L3INSTR_OCP_WP_NOC_CLKCTRL_OFFSET		0x0740
+#define DRA7XX_CM_L3INSTR_OCP_WP_NOC_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0740)
+#define DRA7XX_CM_L3INSTR_DLL_AGING_CLKCTRL_OFFSET		0x0748
+#define DRA7XX_CM_L3INSTR_DLL_AGING_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0748)
+#define DRA7XX_CM_L3INSTR_CTRL_MODULE_BANDGAP_CLKCTRL_OFFSET	0x0750
+#define DRA7XX_CM_L3INSTR_CTRL_MODULE_BANDGAP_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CORE_INST, 0x0750)
+
+/* CM_CORE.IVA_CM_CORE register offsets */
+#define DRA7XX_CM_IVA_CLKSTCTRL_OFFSET				0x0000
+#define DRA7XX_CM_IVA_STATICDEP_OFFSET				0x0004
+#define DRA7XX_CM_IVA_DYNAMICDEP_OFFSET				0x0008
+#define DRA7XX_CM_IVA_IVA_CLKCTRL_OFFSET			0x0020
+#define DRA7XX_CM_IVA_IVA_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_IVA_INST, 0x0020)
+#define DRA7XX_CM_IVA_SL2_CLKCTRL_OFFSET			0x0028
+#define DRA7XX_CM_IVA_SL2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_IVA_INST, 0x0028)
+
+/* CM_CORE.CAM_CM_CORE register offsets */
+#define DRA7XX_CM_CAM_CLKSTCTRL_OFFSET				0x0000
+#define DRA7XX_CM_CAM_STATICDEP_OFFSET				0x0004
+#define DRA7XX_CM_CAM_VIP1_CLKCTRL_OFFSET			0x0020
+#define DRA7XX_CM_CAM_VIP1_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CAM_INST, 0x0020)
+#define DRA7XX_CM_CAM_VIP2_CLKCTRL_OFFSET			0x0028
+#define DRA7XX_CM_CAM_VIP2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CAM_INST, 0x0028)
+#define DRA7XX_CM_CAM_VIP3_CLKCTRL_OFFSET			0x0030
+#define DRA7XX_CM_CAM_VIP3_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CAM_INST, 0x0030)
+#define DRA7XX_CM_CAM_LVDSRX_CLKCTRL_OFFSET			0x0038
+#define DRA7XX_CM_CAM_LVDSRX_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CAM_INST, 0x0038)
+#define DRA7XX_CM_CAM_CSI1_CLKCTRL_OFFSET			0x0040
+#define DRA7XX_CM_CAM_CSI1_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CAM_INST, 0x0040)
+#define DRA7XX_CM_CAM_CSI2_CLKCTRL_OFFSET			0x0048
+#define DRA7XX_CM_CAM_CSI2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CAM_INST, 0x0048)
+
+/* CM_CORE.DSS_CM_CORE register offsets */
+#define DRA7XX_CM_DSS_CLKSTCTRL_OFFSET				0x0000
+#define DRA7XX_CM_DSS_STATICDEP_OFFSET				0x0004
+#define DRA7XX_CM_DSS_DYNAMICDEP_OFFSET				0x0008
+#define DRA7XX_CM_DSS_DSS_CLKCTRL_OFFSET			0x0020
+#define DRA7XX_CM_DSS_DSS_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_DSS_INST, 0x0020)
+#define DRA7XX_CM_DSS_BB2D_CLKCTRL_OFFSET			0x0030
+#define DRA7XX_CM_DSS_BB2D_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_DSS_INST, 0x0030)
+#define DRA7XX_CM_DSS_SDVENC_CLKCTRL_OFFSET			0x003c
+#define DRA7XX_CM_DSS_SDVENC_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_DSS_INST, 0x003c)
+
+/* CM_CORE.GPU_CM_CORE register offsets */
+#define DRA7XX_CM_GPU_CLKSTCTRL_OFFSET				0x0000
+#define DRA7XX_CM_GPU_STATICDEP_OFFSET				0x0004
+#define DRA7XX_CM_GPU_DYNAMICDEP_OFFSET				0x0008
+#define DRA7XX_CM_GPU_GPU_CLKCTRL_OFFSET			0x0020
+#define DRA7XX_CM_GPU_GPU_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_GPU_INST, 0x0020)
+
+/* CM_CORE.L3INIT_CM_CORE register offsets */
+#define DRA7XX_CM_L3INIT_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_L3INIT_STATICDEP_OFFSET			0x0004
+#define DRA7XX_CM_L3INIT_DYNAMICDEP_OFFSET			0x0008
+#define DRA7XX_CM_L3INIT_MMC1_CLKCTRL_OFFSET			0x0028
+#define DRA7XX_CM_L3INIT_MMC1_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x0028)
+#define DRA7XX_CM_L3INIT_MMC2_CLKCTRL_OFFSET			0x0030
+#define DRA7XX_CM_L3INIT_MMC2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x0030)
+#define DRA7XX_CM_L3INIT_USB_OTG_SS2_CLKCTRL_OFFSET		0x0040
+#define DRA7XX_CM_L3INIT_USB_OTG_SS2_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x0040)
+#define DRA7XX_CM_L3INIT_USB_OTG_SS3_CLKCTRL_OFFSET		0x0048
+#define DRA7XX_CM_L3INIT_USB_OTG_SS3_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x0048)
+#define DRA7XX_CM_L3INIT_USB_OTG_SS4_CLKCTRL_OFFSET		0x0050
+#define DRA7XX_CM_L3INIT_USB_OTG_SS4_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x0050)
+#define DRA7XX_CM_L3INIT_MLB_SS_CLKCTRL_OFFSET			0x0058
+#define DRA7XX_CM_L3INIT_MLB_SS_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x0058)
+#define DRA7XX_CM_L3INIT_IEEE1500_2_OCP_CLKCTRL_OFFSET		0x0078
+#define DRA7XX_CM_L3INIT_IEEE1500_2_OCP_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x0078)
+#define DRA7XX_CM_L3INIT_SATA_CLKCTRL_OFFSET			0x0088
+#define DRA7XX_CM_L3INIT_SATA_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x0088)
+#define DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET				0x00a0
+#define DRA7XX_CM_PCIE_STATICDEP_OFFSET				0x00a4
+#define DRA7XX_CM_GMAC_CLKSTCTRL_OFFSET				0x00c0
+#define DRA7XX_CM_GMAC_STATICDEP_OFFSET				0x00c4
+#define DRA7XX_CM_GMAC_DYNAMICDEP_OFFSET			0x00c8
+#define DRA7XX_CM_GMAC_GMAC_CLKCTRL_OFFSET			0x00d0
+#define DRA7XX_CM_GMAC_GMAC_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x00d0)
+#define DRA7XX_CM_L3INIT_OCP2SCP1_CLKCTRL_OFFSET		0x00e0
+#define DRA7XX_CM_L3INIT_OCP2SCP1_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x00e0)
+#define DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET		0x00e8
+#define DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x00e8)
+#define DRA7XX_CM_L3INIT_USB_OTG_SS1_CLKCTRL_OFFSET		0x00f0
+#define DRA7XX_CM_L3INIT_USB_OTG_SS1_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x00f0)
+
+/* CM_CORE.CUSTEFUSE_CM_CORE register offsets */
+#define DRA7XX_CM_CUSTEFUSE_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_CUSTEFUSE_EFUSE_CTRL_CUST_CLKCTRL_OFFSET	0x0020
+#define DRA7XX_CM_CUSTEFUSE_EFUSE_CTRL_CUST_CLKCTRL		DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_CUSTEFUSE_INST, 0x0020)
+
+/* CM_CORE.L4PER_CM_CORE register offsets */
+#define DRA7XX_CM_L4PER_CLKSTCTRL_OFFSET			0x0000
+#define DRA7XX_CM_L4PER_DYNAMICDEP_OFFSET			0x0008
+#define DRA7XX_CM_L4PER2_L4_PER2_CLKCTRL_OFFSET			0x000c
+#define DRA7XX_CM_L4PER2_L4_PER2_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x000c)
+#define DRA7XX_CM_L4PER3_L4_PER3_CLKCTRL_OFFSET			0x0014
+#define DRA7XX_CM_L4PER3_L4_PER3_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0014)
+#define DRA7XX_CM_L4PER2_PRUSS1_CLKCTRL_OFFSET			0x0018
+#define DRA7XX_CM_L4PER2_PRUSS1_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0018)
+#define DRA7XX_CM_L4PER2_PRUSS2_CLKCTRL_OFFSET			0x0020
+#define DRA7XX_CM_L4PER2_PRUSS2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0020)
+#define DRA7XX_CM_L4PER_TIMER10_CLKCTRL_OFFSET			0x0028
+#define DRA7XX_CM_L4PER_TIMER10_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0028)
+#define DRA7XX_CM_L4PER_TIMER11_CLKCTRL_OFFSET			0x0030
+#define DRA7XX_CM_L4PER_TIMER11_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0030)
+#define DRA7XX_CM_L4PER_TIMER2_CLKCTRL_OFFSET			0x0038
+#define DRA7XX_CM_L4PER_TIMER2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0038)
+#define DRA7XX_CM_L4PER_TIMER3_CLKCTRL_OFFSET			0x0040
+#define DRA7XX_CM_L4PER_TIMER3_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0040)
+#define DRA7XX_CM_L4PER_TIMER4_CLKCTRL_OFFSET			0x0048
+#define DRA7XX_CM_L4PER_TIMER4_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0048)
+#define DRA7XX_CM_L4PER_TIMER9_CLKCTRL_OFFSET			0x0050
+#define DRA7XX_CM_L4PER_TIMER9_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0050)
+#define DRA7XX_CM_L4PER_ELM_CLKCTRL_OFFSET			0x0058
+#define DRA7XX_CM_L4PER_ELM_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0058)
+#define DRA7XX_CM_L4PER_GPIO2_CLKCTRL_OFFSET			0x0060
+#define DRA7XX_CM_L4PER_GPIO2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0060)
+#define DRA7XX_CM_L4PER_GPIO3_CLKCTRL_OFFSET			0x0068
+#define DRA7XX_CM_L4PER_GPIO3_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0068)
+#define DRA7XX_CM_L4PER_GPIO4_CLKCTRL_OFFSET			0x0070
+#define DRA7XX_CM_L4PER_GPIO4_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0070)
+#define DRA7XX_CM_L4PER_GPIO5_CLKCTRL_OFFSET			0x0078
+#define DRA7XX_CM_L4PER_GPIO5_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0078)
+#define DRA7XX_CM_L4PER_GPIO6_CLKCTRL_OFFSET			0x0080
+#define DRA7XX_CM_L4PER_GPIO6_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0080)
+#define DRA7XX_CM_L4PER_HDQ1W_CLKCTRL_OFFSET			0x0088
+#define DRA7XX_CM_L4PER_HDQ1W_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0088)
+#define DRA7XX_CM_L4PER2_PWMSS2_CLKCTRL_OFFSET			0x0090
+#define DRA7XX_CM_L4PER2_PWMSS2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0090)
+#define DRA7XX_CM_L4PER2_PWMSS3_CLKCTRL_OFFSET			0x0098
+#define DRA7XX_CM_L4PER2_PWMSS3_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0098)
+#define DRA7XX_CM_L4PER_I2C1_CLKCTRL_OFFSET			0x00a0
+#define DRA7XX_CM_L4PER_I2C1_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x00a0)
+#define DRA7XX_CM_L4PER_I2C2_CLKCTRL_OFFSET			0x00a8
+#define DRA7XX_CM_L4PER_I2C2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x00a8)
+#define DRA7XX_CM_L4PER_I2C3_CLKCTRL_OFFSET			0x00b0
+#define DRA7XX_CM_L4PER_I2C3_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x00b0)
+#define DRA7XX_CM_L4PER_I2C4_CLKCTRL_OFFSET			0x00b8
+#define DRA7XX_CM_L4PER_I2C4_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x00b8)
+#define DRA7XX_CM_L4PER_L4_PER1_CLKCTRL_OFFSET			0x00c0
+#define DRA7XX_CM_L4PER_L4_PER1_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x00c0)
+#define DRA7XX_CM_L4PER2_PWMSS1_CLKCTRL_OFFSET			0x00c4
+#define DRA7XX_CM_L4PER2_PWMSS1_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x00c4)
+#define DRA7XX_CM_L4PER3_TIMER13_CLKCTRL_OFFSET			0x00c8
+#define DRA7XX_CM_L4PER3_TIMER13_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x00c8)
+#define DRA7XX_CM_L4PER3_TIMER14_CLKCTRL_OFFSET			0x00d0
+#define DRA7XX_CM_L4PER3_TIMER14_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x00d0)
+#define DRA7XX_CM_L4PER3_TIMER15_CLKCTRL_OFFSET			0x00d8
+#define DRA7XX_CM_L4PER3_TIMER15_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x00d8)
+#define DRA7XX_CM_L4PER_MCSPI1_CLKCTRL_OFFSET			0x00f0
+#define DRA7XX_CM_L4PER_MCSPI1_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x00f0)
+#define DRA7XX_CM_L4PER_MCSPI2_CLKCTRL_OFFSET			0x00f8
+#define DRA7XX_CM_L4PER_MCSPI2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x00f8)
+#define DRA7XX_CM_L4PER_MCSPI3_CLKCTRL_OFFSET			0x0100
+#define DRA7XX_CM_L4PER_MCSPI3_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0100)
+#define DRA7XX_CM_L4PER_MCSPI4_CLKCTRL_OFFSET			0x0108
+#define DRA7XX_CM_L4PER_MCSPI4_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0108)
+#define DRA7XX_CM_L4PER_GPIO7_CLKCTRL_OFFSET			0x0110
+#define DRA7XX_CM_L4PER_GPIO7_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0110)
+#define DRA7XX_CM_L4PER_GPIO8_CLKCTRL_OFFSET			0x0118
+#define DRA7XX_CM_L4PER_GPIO8_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0118)
+#define DRA7XX_CM_L4PER_MMC3_CLKCTRL_OFFSET			0x0120
+#define DRA7XX_CM_L4PER_MMC3_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0120)
+#define DRA7XX_CM_L4PER_MMC4_CLKCTRL_OFFSET			0x0128
+#define DRA7XX_CM_L4PER_MMC4_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0128)
+#define DRA7XX_CM_L4PER3_TIMER16_CLKCTRL_OFFSET			0x0130
+#define DRA7XX_CM_L4PER3_TIMER16_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0130)
+#define DRA7XX_CM_L4PER2_QSPI_CLKCTRL_OFFSET			0x0138
+#define DRA7XX_CM_L4PER2_QSPI_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0138)
+#define DRA7XX_CM_L4PER_UART1_CLKCTRL_OFFSET			0x0140
+#define DRA7XX_CM_L4PER_UART1_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0140)
+#define DRA7XX_CM_L4PER_UART2_CLKCTRL_OFFSET			0x0148
+#define DRA7XX_CM_L4PER_UART2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0148)
+#define DRA7XX_CM_L4PER_UART3_CLKCTRL_OFFSET			0x0150
+#define DRA7XX_CM_L4PER_UART3_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0150)
+#define DRA7XX_CM_L4PER_UART4_CLKCTRL_OFFSET			0x0158
+#define DRA7XX_CM_L4PER_UART4_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0158)
+#define DRA7XX_CM_L4PER2_MCASP2_CLKCTRL_OFFSET			0x0160
+#define DRA7XX_CM_L4PER2_MCASP2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0160)
+#define DRA7XX_CM_L4PER2_MCASP3_CLKCTRL_OFFSET			0x0168
+#define DRA7XX_CM_L4PER2_MCASP3_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0168)
+#define DRA7XX_CM_L4PER_UART5_CLKCTRL_OFFSET			0x0170
+#define DRA7XX_CM_L4PER_UART5_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0170)
+#define DRA7XX_CM_L4PER2_MCASP5_CLKCTRL_OFFSET			0x0178
+#define DRA7XX_CM_L4PER2_MCASP5_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0178)
+#define DRA7XX_CM_L4SEC_CLKSTCTRL_OFFSET			0x0180
+#define DRA7XX_CM_L4SEC_STATICDEP_OFFSET			0x0184
+#define DRA7XX_CM_L4SEC_DYNAMICDEP_OFFSET			0x0188
+#define DRA7XX_CM_L4PER2_MCASP8_CLKCTRL_OFFSET			0x0190
+#define DRA7XX_CM_L4PER2_MCASP8_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0190)
+#define DRA7XX_CM_L4PER2_MCASP4_CLKCTRL_OFFSET			0x0198
+#define DRA7XX_CM_L4PER2_MCASP4_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0198)
+#define DRA7XX_CM_L4SEC_AES1_CLKCTRL_OFFSET			0x01a0
+#define DRA7XX_CM_L4SEC_AES1_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x01a0)
+#define DRA7XX_CM_L4SEC_AES2_CLKCTRL_OFFSET			0x01a8
+#define DRA7XX_CM_L4SEC_AES2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x01a8)
+#define DRA7XX_CM_L4SEC_DES3DES_CLKCTRL_OFFSET			0x01b0
+#define DRA7XX_CM_L4SEC_DES3DES_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x01b0)
+#define DRA7XX_CM_L4SEC_FPKA_CLKCTRL_OFFSET			0x01b8
+#define DRA7XX_CM_L4SEC_FPKA_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x01b8)
+#define DRA7XX_CM_L4SEC_RNG_CLKCTRL_OFFSET			0x01c0
+#define DRA7XX_CM_L4SEC_RNG_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x01c0)
+#define DRA7XX_CM_L4SEC_SHA2MD51_CLKCTRL_OFFSET			0x01c8
+#define DRA7XX_CM_L4SEC_SHA2MD51_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x01c8)
+#define DRA7XX_CM_L4PER2_UART7_CLKCTRL_OFFSET			0x01d0
+#define DRA7XX_CM_L4PER2_UART7_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x01d0)
+#define DRA7XX_CM_L4SEC_DMA_CRYPTO_CLKCTRL_OFFSET		0x01d8
+#define DRA7XX_CM_L4SEC_DMA_CRYPTO_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x01d8)
+#define DRA7XX_CM_L4PER2_UART8_CLKCTRL_OFFSET			0x01e0
+#define DRA7XX_CM_L4PER2_UART8_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x01e0)
+#define DRA7XX_CM_L4PER2_UART9_CLKCTRL_OFFSET			0x01e8
+#define DRA7XX_CM_L4PER2_UART9_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x01e8)
+#define DRA7XX_CM_L4PER2_DCAN2_CLKCTRL_OFFSET			0x01f0
+#define DRA7XX_CM_L4PER2_DCAN2_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x01f0)
+#define DRA7XX_CM_L4SEC_SHA2MD52_CLKCTRL_OFFSET			0x01f8
+#define DRA7XX_CM_L4SEC_SHA2MD52_CLKCTRL			DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x01f8)
+#define DRA7XX_CM_L4PER2_CLKSTCTRL_OFFSET			0x01fc
+#define DRA7XX_CM_L4PER2_DYNAMICDEP_OFFSET			0x0200
+#define DRA7XX_CM_L4PER2_MCASP6_CLKCTRL_OFFSET			0x0204
+#define DRA7XX_CM_L4PER2_MCASP6_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0204)
+#define DRA7XX_CM_L4PER2_MCASP7_CLKCTRL_OFFSET			0x0208
+#define DRA7XX_CM_L4PER2_MCASP7_CLKCTRL				DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L4PER_INST, 0x0208)
+#define DRA7XX_CM_L4PER2_STATICDEP_OFFSET			0x020c
+#define DRA7XX_CM_L4PER3_CLKSTCTRL_OFFSET			0x0210
+#define DRA7XX_CM_L4PER3_DYNAMICDEP_OFFSET			0x0214
+
+#endif
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:32:19 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 13:02:19 +0530
Subject: [PATCH 12/12] ARM: DRA7: dts: Add the dts files for dra7 SoC and
 dra7-evm board
In-Reply-To: <1373355139-12487-1-git-send-email-rnayak@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
Message-ID: <1373355139-12487-13-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved.

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/boot/dts/Makefile     |    3 +-
 arch/arm/boot/dts/dra7-evm.dts |   20 ++
 arch/arm/boot/dts/dra7.dtsi    |  488 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 510 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/dra7-evm.dts
 create mode 100644 arch/arm/boot/dts/dra7.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..e2f8566 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -173,7 +173,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
 	am335x-bone.dtb \
 	am3517-evm.dtb \
 	am3517_mt_ventoux.dtb \
-	am43x-epos-evm.dtb
+	am43x-epos-evm.dtb \
+	dra7-evm.dtb
 dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
 dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
 dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
new file mode 100644
index 0000000..cb0703c
--- /dev/null
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -0,0 +1,20 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "dra7.dtsi"
+
+/ {
+	model = "TI DRA7";
+	compatible = "ti,dra7-evm", "ti,dra7";
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x60000000>; /* 1536 MB */
+	};
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
new file mode 100644
index 0000000..8a0c08e
--- /dev/null
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -0,0 +1,488 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * Based on "omap4.dtsi"
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "ti,dra7xx";
+	interrupt-parent = <&gic>;
+
+	aliases {
+		serial0 = &uart1;
+		serial1 = &uart2;
+		serial2 = &uart3;
+		serial3 = &uart4;
+		serial4 = &uart5;
+		serial5 = &uart6;
+	};
+
+	cpus {
+		cpu at 0 {
+			compatible = "arm,cortex-a15";
+			timer {
+				compatible = "arm,armv7-timer";
+				/*
+				 * PPI secure/nonsecure IRQ,
+				 * active low level-sensitive
+				 */
+				interrupts = <1 13 0x308>,
+					     <1 14 0x308>;
+				clock-frequency = <6144000>;
+			};
+		};
+		cpu at 1 {
+			compatible = "arm,cortex-a15";
+			timer {
+				compatible = "arm,armv7-timer";
+				/*
+				 * PPI secure/nonsecure IRQ,
+				 * active low level-sensitive
+				 */
+				interrupts = <1 13 0x308>,
+					     <1 14 0x308>;
+				clock-frequency = <6144000>;
+			};
+		};
+	};
+
+	gic: interrupt-controller at 48211000 {
+		compatible = "arm,cortex-a15-gic";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		reg = <0x48211000 0x1000>,
+		      <0x48212000 0x1000>;
+	};
+
+	/*
+	 * The soc node represents the soc top level view. It is uses for IPs
+	 * that are not memory mapped in the MPU view or for the MPU itself.
+	 */
+	soc {
+		compatible = "ti,omap-infra";
+		mpu {
+			compatible = "ti,omap5-mpu";
+			ti,hwmods = "mpu";
+		};
+	};
+
+	/*
+	 * XXX: Use a flat representation of the SOC interconnect.
+	 * The real OMAP interconnect network is quite complex.
+	 * Since that will not bring real advantage to represent that in DT for
+	 * the moment, just use a fake OCP bus entry to represent the whole bus
+	 * hierarchy.
+	 */
+	ocp {
+		compatible = "ti,omap4-l3-noc", "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		ti,hwmods = "l3_main_1", "l3_main_2";
+
+		counter32k: counter at 4ae04000 {
+			compatible = "ti,omap-counter32k";
+			reg = <0x4ae04000 0x40>;
+			ti,hwmods = "counter_32k";
+		};
+
+		dra7_pmx_core: pinmux at 4a003400 {
+			compatible = "pinctrl-single";
+			reg = <0x4a003400 0x0464>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			pinctrl-single,register-width = <32>;
+			pinctrl-single,function-mask = <0x3fffffff>;
+		};
+
+		sdma: dma-controller at 4a056000 {
+			compatible = "ti,omap4430-sdma";
+			reg = <0x4a056000 0x1000>;
+			interrupts = <0 12 0x4>,
+				     <0 13 0x4>,
+				     <0 14 0x4>,
+				     <0 15 0x4>;
+			#dma-cells = <1>;
+			#dma-channels = <32>;
+			#dma-requests = <127>;
+		};
+
+		gpio1: gpio at 4ae10000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x4ae10000 0x200>;
+			interrupts = <0 29 0x4>;
+			ti,hwmods = "gpio1";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio2: gpio at 48055000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48055000 0x200>;
+			interrupts = <0 30 0x4>;
+			ti,hwmods = "gpio2";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio3: gpio at 48057000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48057000 0x200>;
+			interrupts = <0 31 0x4>;
+			ti,hwmods = "gpio3";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio4: gpio at 48059000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48059000 0x200>;
+			interrupts = <0 32 0x4>;
+			ti,hwmods = "gpio4";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio5: gpio at 4805b000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x4805b000 0x200>;
+			interrupts = <0 33 0x4>;
+			ti,hwmods = "gpio5";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio6: gpio at 4805d000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x4805d000 0x200>;
+			interrupts = <0 34 0x4>;
+			ti,hwmods = "gpio6";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio7: gpio at 48051000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48051000 0x200>;
+			interrupts = <0 35 0x4>;
+			ti,hwmods = "gpio7";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio8: gpio at 48053000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48053000 0x200>;
+			interrupts = <0 121 0x4>;
+			ti,hwmods = "gpio8";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		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,omap4-uart";
+			reg = <0x48066000 0x100>;
+			interrupts = <0 105 0x4>;
+			ti,hwmods = "uart5";
+			clock-frequency = <48000000>;
+		};
+
+		uart6: serial at 48068000 {
+			compatible = "ti,omap4-uart";
+			reg = <0x48068000 0x100>;
+			interrupts = <0 106 0x4>;
+			ti,hwmods = "uart6";
+			clock-frequency = <48000000>;
+		};
+
+		timer1: timer at 4ae18000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x4ae18000 0x80>;
+			interrupts = <0 37 0x4>;
+			ti,hwmods = "timer1";
+			ti,timer-alwon;
+		};
+
+		timer2: timer at 48032000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48032000 0x80>;
+			interrupts = <0 38 0x4>;
+			ti,hwmods = "timer2";
+		};
+
+		timer3: timer at 48034000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48034000 0x80>;
+			interrupts = <0 39 0x4>;
+			ti,hwmods = "timer3";
+		};
+
+		timer4: timer at 48036000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48036000 0x80>;
+			interrupts = <0 40 0x4>;
+			ti,hwmods = "timer4";
+		};
+
+		timer5: timer at 48820000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48820000 0x80>;
+			interrupts = <0 41 0x4>;
+			ti,hwmods = "timer5";
+			ti,timer-dsp;
+		};
+
+		timer6: timer at 48822000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48822000 0x80>;
+			interrupts = <0 42 0x4>;
+			ti,hwmods = "timer6";
+			ti,timer-dsp;
+			ti,timer-pwm;
+		};
+
+		timer7: timer at 48824000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48824000 0x80>;
+			interrupts = <0 43 0x4>;
+			ti,hwmods = "timer7";
+			ti,timer-dsp;
+		};
+
+		timer8: timer at 48826000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48826000 0x80>;
+			interrupts = <0 44 0x4>;
+			ti,hwmods = "timer8";
+			ti,timer-dsp;
+			ti,timer-pwm;
+		};
+
+		timer9: timer at 4803e000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x4803e000 0x80>;
+			interrupts = <0 45 0x4>;
+			ti,hwmods = "timer9";
+		};
+
+		timer10: timer at 48086000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48086000 0x80>;
+			interrupts = <0 46 0x4>;
+			ti,hwmods = "timer10";
+		};
+
+		timer11: timer at 48088000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48088000 0x80>;
+			interrupts = <0 47 0x4>;
+			ti,hwmods = "timer11";
+			ti,timer-pwm;
+		};
+
+		wdt2: wdt at 4ae14000 {
+			compatible = "ti,omap4-wdt";
+			reg = <0x4ae14000 0x80>;
+			interrupts = <0 80 0x4>;
+			ti,hwmods = "wd_timer2";
+		};
+
+		i2c1: i2c at 48070000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x48070000 0x100>;
+			interrupts = <0 56 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c1";
+		};
+
+		i2c2: i2c at 48072000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x48072000 0x100>;
+			interrupts = <0 57 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c2";
+		};
+
+		i2c3: i2c at 48060000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x48060000 0x100>;
+			interrupts = <0 61 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c3";
+		};
+
+		i2c4: i2c at 4807a000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x4807a000 0x100>;
+			interrupts = <0 62 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c4";
+		};
+
+		i2c5: i2c at 4807c000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x4807c000 0x100>;
+			interrupts = <0 60 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c5";
+		};
+
+		mmc1: mmc at 4809c000 {
+			compatible = "ti,omap4-hsmmc";
+			reg = <0x4809c000 0x400>;
+			interrupts = <0 83 0x4>;
+			ti,hwmods = "mmc1";
+			ti,dual-volt;
+			ti,needs-special-reset;
+			dmas = <&sdma 61>, <&sdma 62>;
+			dma-names = "tx", "rx";
+		};
+
+		mmc2: mmc at 480b4000 {
+			compatible = "ti,omap4-hsmmc";
+			reg = <0x480b4000 0x400>;
+			interrupts = <0 86 0x4>;
+			ti,hwmods = "mmc2";
+			ti,needs-special-reset;
+			dmas = <&sdma 47>, <&sdma 48>;
+			dma-names = "tx", "rx";
+		};
+
+		mmc3: mmc at 480ad000 {
+			compatible = "ti,omap4-hsmmc";
+			reg = <0x480ad000 0x400>;
+			interrupts = <0 94 0x4>;
+			ti,hwmods = "mmc3";
+			ti,needs-special-reset;
+			dmas = <&sdma 77>, <&sdma 78>;
+			dma-names = "tx", "rx";
+		};
+
+		mmc4: mmc at 480d1000 {
+			compatible = "ti,omap4-hsmmc";
+			reg = <0x480d1000 0x400>;
+			interrupts = <0 96 0x4>;
+			ti,hwmods = "mmc4";
+			ti,needs-special-reset;
+			dmas = <&sdma 57>, <&sdma 58>;
+			dma-names = "tx", "rx";
+		};
+
+		mcspi1: spi at 48098000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x48098000 0x200>;
+			interrupts = <0 65 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi1";
+			ti,spi-num-cs = <4>;
+			dmas = <&sdma 35>,
+			       <&sdma 36>,
+			       <&sdma 37>,
+			       <&sdma 38>,
+			       <&sdma 39>,
+			       <&sdma 40>,
+			       <&sdma 41>,
+			       <&sdma 42>;
+			dma-names = "tx0", "rx0", "tx1", "rx1",
+				    "tx2", "rx2", "tx3", "rx3";
+		};
+
+		mcspi2: spi at 4809a000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x4809a000 0x200>;
+			interrupts = <0 66 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi2";
+			ti,spi-num-cs = <2>;
+			dmas = <&sdma 43>,
+			       <&sdma 44>,
+			       <&sdma 45>,
+			       <&sdma 46>;
+			dma-names = "tx0", "rx0", "tx1", "rx1";
+		};
+
+		mcspi3: spi at 480b8000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x480b8000 0x200>;
+			interrupts = <0 91 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi3";
+			ti,spi-num-cs = <2>;
+			dmas = <&sdma 15>, <&sdma 16>;
+			dma-names = "tx0", "rx0";
+		};
+
+		mcspi4: spi at 480ba000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x480ba000 0x200>;
+			interrupts = <0 48 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi4";
+			ti,spi-num-cs = <1>;
+			dmas = <&sdma 70>, <&sdma 71>;
+			dma-names = "tx0", "rx0";
+		};
+	};
+};
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul  9 03:32:16 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 13:02:16 +0530
Subject: [PATCH 09/12] ARM: DRA7: hwmod: Create initial DRA7XX SoC data
In-Reply-To: <1373355139-12487-1-git-send-email-rnayak@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
Message-ID: <1373355139-12487-10-git-send-email-rnayak@ti.com>

From: Ambresh K <ambresh at ti.com>

Adding the hwmod data for DRA7XX platforms.

Signed-off-by: Ambresh K <ambresh at ti.com>
Signed-off-by: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/Makefile              |    1 +
 arch/arm/mach-omap2/omap_hwmod.h          |    1 +
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2724 +++++++++++++++++++++++++++++
 3 files changed, 2726 insertions(+)
 create mode 100644 arch/arm/mach-omap2/omap_hwmod_7xx_data.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 137c9e4..6ed1eb1 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -218,6 +218,7 @@ obj-$(CONFIG_ARCH_OMAP3)		+= omap_hwmod_3xxx_data.o
 obj-$(CONFIG_SOC_AM33XX)		+= omap_hwmod_33xx_data.o
 obj-$(CONFIG_ARCH_OMAP4)		+= omap_hwmod_44xx_data.o
 obj-$(CONFIG_SOC_OMAP5)			+= omap_hwmod_54xx_data.o
+obj-$(CONFIG_SOC_DRA7XX)		+= omap_hwmod_7xx_data.o
 
 # EMU peripherals
 obj-$(CONFIG_OMAP3_EMU)			+= emu.o
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index aab33fd..85eff28 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -701,6 +701,7 @@ extern int omap3xxx_hwmod_init(void);
 extern int omap44xx_hwmod_init(void);
 extern int omap54xx_hwmod_init(void);
 extern int am33xx_hwmod_init(void);
+extern int dra7xx_hwmod_init(void);
 
 extern int __init omap_hwmod_register_links(struct omap_hwmod_ocp_if **ois);
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
new file mode 100644
index 0000000..db32d53
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -0,0 +1,2724 @@
+/*
+ * Hardware modules present on the DRA7xx chips
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Paul Walmsley
+ * Benoit Cousson
+ *
+ * This file is automatically generated from the OMAP hardware databases.
+ * We respectfully ask that any modifications to this file be coordinated
+ * with the public linux-omap at vger.kernel.org mailing list and the
+ * authors above to ensure that the autogeneration scripts are kept
+ * up-to-date with the file contents.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/platform_data/gpio-omap.h>
+#include <linux/power/smartreflex.h>
+#include <linux/i2c-omap.h>
+
+#include <linux/omap-dma.h>
+#include <linux/platform_data/spi-omap2-mcspi.h>
+#include <linux/platform_data/asoc-ti-mcbsp.h>
+#include <plat/dmtimer.h>
+
+#include "omap_hwmod.h"
+#include "omap_hwmod_common_data.h"
+#include "cm1_7xx.h"
+#include "cm2_7xx.h"
+#include "prm7xx.h"
+#include "i2c.h"
+#include "mmc.h"
+#include "wd_timer.h"
+
+/* Base offset for all DRA7XX interrupts external to MPUSS */
+#define DRA7XX_IRQ_GIC_START	32
+
+/* Base offset for all DRA7XX dma requests */
+#define DRA7XX_DMA_REQ_START	1
+
+
+/*
+ * IP blocks
+ */
+
+/*
+ * 'l3' class
+ * instance(s): l3_instr, l3_main_1, l3_main_2
+ */
+static struct omap_hwmod_class dra7xx_l3_hwmod_class = {
+	.name	= "l3",
+};
+
+/* l3_instr */
+static struct omap_hwmod dra7xx_l3_instr_hwmod = {
+	.name		= "l3_instr",
+	.class		= &dra7xx_l3_hwmod_class,
+	.clkdm_name	= "l3instr_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L3INSTR_L3_INSTR_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3INSTR_L3_INSTR_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/* l3_main_1 */
+static struct omap_hwmod dra7xx_l3_main_1_hwmod = {
+	.name		= "l3_main_1",
+	.class		= &dra7xx_l3_hwmod_class,
+	.clkdm_name	= "l3main1_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L3MAIN1_L3_MAIN_1_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3MAIN1_L3_MAIN_1_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/* l3_main_2 */
+static struct omap_hwmod dra7xx_l3_main_2_hwmod = {
+	.name		= "l3_main_2",
+	.class		= &dra7xx_l3_hwmod_class,
+	.clkdm_name	= "l3instr_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L3INSTR_L3_MAIN_2_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3INSTR_L3_MAIN_2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/*
+ * 'l4' class
+ * instance(s): l4_cfg, l4_per1, l4_per2, l4_per3, l4_wkup
+ */
+static struct omap_hwmod_class dra7xx_l4_hwmod_class = {
+	.name	= "l4",
+};
+
+/* l4_cfg */
+static struct omap_hwmod dra7xx_l4_cfg_hwmod = {
+	.name		= "l4_cfg",
+	.class		= &dra7xx_l4_hwmod_class,
+	.clkdm_name	= "l4cfg_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4CFG_L4_CFG_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4CFG_L4_CFG_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/* l4_per1 */
+static struct omap_hwmod dra7xx_l4_per1_hwmod = {
+	.name		= "l4_per1",
+	.class		= &dra7xx_l4_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_L4_PER1_CLKCTRL_OFFSET,
+			.flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+		},
+	},
+};
+
+/* l4_per2 */
+static struct omap_hwmod dra7xx_l4_per2_hwmod = {
+	.name		= "l4_per2",
+	.class		= &dra7xx_l4_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER2_L4_PER2_CLKCTRL_OFFSET,
+			.flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+		},
+	},
+};
+
+/* l4_per3 */
+static struct omap_hwmod dra7xx_l4_per3_hwmod = {
+	.name		= "l4_per3",
+	.class		= &dra7xx_l4_hwmod_class,
+	.clkdm_name	= "l4per3_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER3_L4_PER3_CLKCTRL_OFFSET,
+			.flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+		},
+	},
+};
+
+/* l4_wkup */
+static struct omap_hwmod dra7xx_l4_wkup_hwmod = {
+	.name		= "l4_wkup",
+	.class		= &dra7xx_l4_hwmod_class,
+	.clkdm_name	= "wkupaon_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_WKUPAON_L4_WKUP_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_WKUPAON_L4_WKUP_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
+ * 'atl' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_atl_hwmod_class = {
+	.name	= "atl",
+};
+
+/* atl */
+static struct omap_hwmod dra7xx_atl_hwmod = {
+	.name		= "atl",
+	.class		= &dra7xx_atl_hwmod_class,
+	.clkdm_name	= "atl_clkdm",
+	.main_clk	= "atl_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_ATL_ATL_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_ATL_ATL_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/*
+ * 'bb2d' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_bb2d_hwmod_class = {
+	.name	= "bb2d",
+};
+
+/* bb2d */
+static struct omap_hwmod dra7xx_bb2d_hwmod = {
+	.name		= "bb2d",
+	.class		= &dra7xx_bb2d_hwmod_class,
+	.clkdm_name	= "dss_clkdm",
+	.main_clk	= "dpll_core_h24x2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_DSS_BB2D_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_DSS_BB2D_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/*
+ * 'counter' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_counter_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= SYSC_HAS_SIDLEMODE,
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dra7xx_counter_hwmod_class = {
+	.name	= "counter",
+	.sysc	= &dra7xx_counter_sysc,
+};
+
+/* counter_32k */
+static struct omap_hwmod dra7xx_counter_32k_hwmod = {
+	.name		= "counter_32k",
+	.class		= &dra7xx_counter_hwmod_class,
+	.clkdm_name	= "wkupaon_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE,
+	.main_clk	= "wkupaon_iclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_WKUPAON_COUNTER_32K_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_WKUPAON_COUNTER_32K_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
+ * 'ctrl_module' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_ctrl_module_hwmod_class = {
+	.name	= "ctrl_module",
+};
+
+/* ctrl_module_wkup */
+static struct omap_hwmod dra7xx_ctrl_module_wkup_hwmod = {
+	.name		= "ctrl_module_wkup",
+	.class		= &dra7xx_ctrl_module_hwmod_class,
+	.clkdm_name	= "wkupaon_clkdm",
+	.prcm = {
+		.omap4 = {
+			.flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+		},
+	},
+};
+
+/*
+ * 'dcan' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_dcan_hwmod_class = {
+	.name	= "dcan",
+};
+
+/* dcan1 */
+static struct omap_hwmod dra7xx_dcan1_hwmod = {
+	.name		= "dcan1",
+	.class		= &dra7xx_dcan_hwmod_class,
+	.clkdm_name	= "wkupaon_clkdm",
+	.main_clk	= "dcan1_sys_clk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_WKUPAON_DCAN1_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_WKUPAON_DCAN1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* dcan2 */
+static struct omap_hwmod dra7xx_dcan2_hwmod = {
+	.name		= "dcan2",
+	.class		= &dra7xx_dcan_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "sys_clkin1",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER2_DCAN2_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER2_DCAN2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/*
+ * 'dma' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_dma_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x002c,
+	.syss_offs	= 0x0028,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+			   SYSC_HAS_EMUFREE | SYSC_HAS_MIDLEMODE |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+			   SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+			   MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dra7xx_dma_hwmod_class = {
+	.name	= "dma",
+	.sysc	= &dra7xx_dma_sysc,
+};
+
+/* dma dev_attr */
+static struct omap_dma_dev_attr dma_dev_attr = {
+	.dev_caps	= RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+			  IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+	.lch_count	= 32,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info dra7xx_dma_system_irqs[] = {
+	{ .name = "0", .irq = 12 + DRA7XX_IRQ_GIC_START },
+	{ .name = "1", .irq = 13 + DRA7XX_IRQ_GIC_START },
+	{ .name = "2", .irq = 14 + DRA7XX_IRQ_GIC_START },
+	{ .name = "3", .irq = 15 + DRA7XX_IRQ_GIC_START },
+	{ .irq = -1 }
+};
+
+static struct omap_hwmod dra7xx_dma_system_hwmod = {
+	.name		= "dma_system",
+	.class		= &dra7xx_dma_hwmod_class,
+	.clkdm_name	= "dma_clkdm",
+	.mpu_irqs	= dra7xx_dma_system_irqs,
+	.main_clk	= "l3_iclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_DMA_DMA_SYSTEM_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_DMA_DMA_SYSTEM_CONTEXT_OFFSET,
+		},
+	},
+	.dev_attr	= &dma_dev_attr,
+};
+
+/*
+ * 'dss' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_dss_sysc = {
+	.rev_offs	= 0x0000,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= SYSS_HAS_RESET_STATUS,
+};
+
+static struct omap_hwmod_class dra7xx_dss_hwmod_class = {
+	.name	= "dss",
+	.sysc	= &dra7xx_dss_sysc,
+	.reset	= omap_dss_reset,
+};
+
+/* dss */
+static struct omap_hwmod_dma_info dra7xx_dss_sdma_reqs[] = {
+	{ .dma_req = 75 + DRA7XX_DMA_REQ_START },
+	{ .dma_req = -1 }
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+	{ .role = "dss_clk", .clk = "dss_dss_clk" },
+	{ .role = "hdmi_phy_clk", .clk = "dss_48mhz_clk" },
+	{ .role = "32khz_clk", .clk = "dss_32khz_clk" },
+	{ .role = "video2_clk", .clk = "dss_video2_clk" },
+	{ .role = "video1_clk", .clk = "dss_video1_clk" },
+	{ .role = "hdmi_clk", .clk = "dss_hdmi_clk" },
+};
+
+static struct omap_hwmod dra7xx_dss_hwmod = {
+	.name		= "dss_core",
+	.class		= &dra7xx_dss_hwmod_class,
+	.clkdm_name	= "dss_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.sdma_reqs	= dra7xx_dss_sdma_reqs,
+	.main_clk	= "dss_dss_clk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_DSS_DSS_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= dss_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(dss_opt_clks),
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_dispc_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+			   SYSC_HAS_ENAWAKEUP | SYSC_HAS_MIDLEMODE |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+			   SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dra7xx_dispc_hwmod_class = {
+	.name	= "dispc",
+	.sysc	= &dra7xx_dispc_sysc,
+};
+
+/* dss_dispc */
+/* dss_dispc dev_attr */
+static struct omap_dss_dispc_dev_attr dss_dispc_dev_attr = {
+	.has_framedonetv_irq	= 1,
+	.manager_count		= 4,
+};
+
+static struct omap_hwmod dra7xx_dss_dispc_hwmod = {
+	.name		= "dss_dispc",
+	.class		= &dra7xx_dispc_hwmod_class,
+	.clkdm_name	= "dss_clkdm",
+	.main_clk	= "dss_dss_clk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+			.flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+		},
+	},
+	.dev_attr	= &dss_dispc_dev_attr,
+};
+
+/*
+ * 'hdmi' class
+ * hdmi controller
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_hdmi_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class dra7xx_hdmi_hwmod_class = {
+	.name	= "hdmi",
+	.sysc	= &dra7xx_hdmi_sysc,
+};
+
+/* dss_hdmi */
+
+static struct omap_hwmod_opt_clk dss_hdmi_opt_clks[] = {
+	{ .role = "sys_clk", .clk = "dss_hdmi_clk" },
+};
+
+static struct omap_hwmod dra7xx_dss_hdmi_hwmod = {
+	.name		= "dss_hdmi",
+	.class		= &dra7xx_hdmi_hwmod_class,
+	.clkdm_name	= "dss_clkdm",
+	.main_clk	= "dss_48mhz_clk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+			.flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+		},
+	},
+	.opt_clks	= dss_hdmi_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(dss_hdmi_opt_clks),
+};
+
+/*
+ * 'elm' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_elm_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+			   SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dra7xx_elm_hwmod_class = {
+	.name	= "elm",
+	.sysc	= &dra7xx_elm_sysc,
+};
+
+/* elm */
+
+static struct omap_hwmod dra7xx_elm_hwmod = {
+	.name		= "elm",
+	.class		= &dra7xx_elm_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "l3_iclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_ELM_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_ELM_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
+ * 'gpio' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_gpio_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0114,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+			   SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dra7xx_gpio_hwmod_class = {
+	.name	= "gpio",
+	.sysc	= &dra7xx_gpio_sysc,
+	.rev	= 2,
+};
+
+/* gpio dev_attr */
+static struct omap_gpio_dev_attr gpio_dev_attr = {
+	.bank_width	= 32,
+	.dbck_flag	= true,
+};
+
+/* gpio1 */
+static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio1_dbclk" },
+};
+
+static struct omap_hwmod dra7xx_gpio1_hwmod = {
+	.name		= "gpio1",
+	.class		= &dra7xx_gpio_hwmod_class,
+	.clkdm_name	= "wkupaon_clkdm",
+	.main_clk	= "wkupaon_iclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_WKUPAON_GPIO1_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_WKUPAON_GPIO1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio1_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio1_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/* gpio2 */
+static struct omap_hwmod_opt_clk gpio2_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio2_dbclk" },
+};
+
+static struct omap_hwmod dra7xx_gpio2_hwmod = {
+	.name		= "gpio2",
+	.class		= &dra7xx_gpio_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.main_clk	= "l3_iclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_GPIO2_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_GPIO2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio2_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio2_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/* gpio3 */
+static struct omap_hwmod_opt_clk gpio3_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio3_dbclk" },
+};
+
+static struct omap_hwmod dra7xx_gpio3_hwmod = {
+	.name		= "gpio3",
+	.class		= &dra7xx_gpio_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.main_clk	= "l3_iclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_GPIO3_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_GPIO3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio3_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio3_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/* gpio4 */
+static struct omap_hwmod_opt_clk gpio4_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio4_dbclk" },
+};
+
+static struct omap_hwmod dra7xx_gpio4_hwmod = {
+	.name		= "gpio4",
+	.class		= &dra7xx_gpio_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.main_clk	= "l3_iclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_GPIO4_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_GPIO4_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio4_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio4_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/* gpio5 */
+static struct omap_hwmod_opt_clk gpio5_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio5_dbclk" },
+};
+
+static struct omap_hwmod dra7xx_gpio5_hwmod = {
+	.name		= "gpio5",
+	.class		= &dra7xx_gpio_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.main_clk	= "l3_iclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_GPIO5_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_GPIO5_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio5_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio5_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/* gpio6 */
+static struct omap_hwmod_opt_clk gpio6_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio6_dbclk" },
+};
+
+static struct omap_hwmod dra7xx_gpio6_hwmod = {
+	.name		= "gpio6",
+	.class		= &dra7xx_gpio_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.main_clk	= "l3_iclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_GPIO6_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_GPIO6_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio6_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio6_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/* gpio7 */
+static struct omap_hwmod_opt_clk gpio7_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio7_dbclk" },
+};
+
+static struct omap_hwmod dra7xx_gpio7_hwmod = {
+	.name		= "gpio7",
+	.class		= &dra7xx_gpio_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.main_clk	= "l3_iclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_GPIO7_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_GPIO7_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio7_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio7_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/* gpio8 */
+static struct omap_hwmod_opt_clk gpio8_opt_clks[] = {
+	{ .role = "dbclk", .clk = "gpio8_dbclk" },
+};
+
+static struct omap_hwmod dra7xx_gpio8_hwmod = {
+	.name		= "gpio8",
+	.class		= &dra7xx_gpio_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.main_clk	= "l3_iclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_GPIO8_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_GPIO8_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= gpio8_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(gpio8_opt_clks),
+	.dev_attr	= &gpio_dev_attr,
+};
+
+/*
+ * 'gpmc' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_gpmc_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dra7xx_gpmc_hwmod_class = {
+	.name	= "gpmc",
+	.sysc	= &dra7xx_gpmc_sysc,
+};
+
+/* gpmc */
+
+static struct omap_hwmod dra7xx_gpmc_hwmod = {
+	.name		= "gpmc",
+	.class		= &dra7xx_gpmc_hwmod_class,
+	.clkdm_name	= "l3main1_clkdm",
+	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+	.main_clk	= "l3_iclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L3MAIN1_GPMC_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3MAIN1_GPMC_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/*
+ * 'hdq1w' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_hdq1w_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0014,
+	.syss_offs	= 0x0018,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SOFTRESET |
+			   SYSS_HAS_RESET_STATUS),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dra7xx_hdq1w_hwmod_class = {
+	.name	= "hdq1w",
+	.sysc	= &dra7xx_hdq1w_sysc,
+};
+
+/* hdq1w */
+
+static struct omap_hwmod dra7xx_hdq1w_hwmod = {
+	.name		= "hdq1w",
+	.class		= &dra7xx_hdq1w_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_INIT_NO_RESET,
+	.main_clk	= "func_12m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_HDQ1W_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_HDQ1W_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/*
+ * 'i2c' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_i2c_sysc = {
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0090,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+			   SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.clockact	= CLOCKACT_TEST_ICLK,
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dra7xx_i2c_hwmod_class = {
+	.name	= "i2c",
+	.sysc	= &dra7xx_i2c_sysc,
+	.reset	= &omap_i2c_reset,
+	.rev	= OMAP_I2C_IP_VERSION_2,
+};
+
+/* i2c dev_attr */
+static struct omap_i2c_dev_attr i2c_dev_attr = {
+	.flags	= OMAP_I2C_FLAG_BUS_SHIFT_NONE,
+};
+
+/* i2c1 */
+static struct omap_hwmod dra7xx_i2c1_hwmod = {
+	.name		= "i2c1",
+	.class		= &dra7xx_i2c_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
+	.main_clk	= "func_96m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_I2C1_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_I2C1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &i2c_dev_attr,
+};
+
+/* i2c2 */
+static struct omap_hwmod dra7xx_i2c2_hwmod = {
+	.name		= "i2c2",
+	.class		= &dra7xx_i2c_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
+	.main_clk	= "func_96m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_I2C2_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_I2C2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &i2c_dev_attr,
+};
+
+/* i2c3 */
+static struct omap_hwmod dra7xx_i2c3_hwmod = {
+	.name		= "i2c3",
+	.class		= &dra7xx_i2c_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
+	.main_clk	= "func_96m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_I2C3_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_I2C3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &i2c_dev_attr,
+};
+
+/* i2c4 */
+static struct omap_hwmod dra7xx_i2c4_hwmod = {
+	.name		= "i2c4",
+	.class		= &dra7xx_i2c_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
+	.main_clk	= "func_96m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_I2C4_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_I2C4_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &i2c_dev_attr,
+};
+
+/* i2c5 */
+static struct omap_hwmod dra7xx_i2c5_hwmod = {
+	.name		= "i2c5",
+	.class		= &dra7xx_i2c_hwmod_class,
+	.clkdm_name	= "ipu_clkdm",
+	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
+	.main_clk	= "func_96m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_IPU_I2C5_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_IPU_I2C5_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &i2c_dev_attr,
+};
+
+/*
+ * 'mcspi' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_mcspi_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class dra7xx_mcspi_hwmod_class = {
+	.name	= "mcspi",
+	.sysc	= &dra7xx_mcspi_sysc,
+	.rev	= OMAP4_MCSPI_REV,
+};
+
+/* mcspi1 */
+/* mcspi1 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi1_dev_attr = {
+	.num_chipselect	= 4,
+};
+
+static struct omap_hwmod dra7xx_mcspi1_hwmod = {
+	.name		= "mcspi1",
+	.class		= &dra7xx_mcspi_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_MCSPI1_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_MCSPI1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &mcspi1_dev_attr,
+};
+
+/* mcspi2 */
+/* mcspi2 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi2_dev_attr = {
+	.num_chipselect	= 2,
+};
+
+static struct omap_hwmod dra7xx_mcspi2_hwmod = {
+	.name		= "mcspi2",
+	.class		= &dra7xx_mcspi_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_MCSPI2_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_MCSPI2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &mcspi2_dev_attr,
+};
+
+/* mcspi3 */
+/* mcspi3 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi3_dev_attr = {
+	.num_chipselect	= 2,
+};
+
+static struct omap_hwmod dra7xx_mcspi3_hwmod = {
+	.name		= "mcspi3",
+	.class		= &dra7xx_mcspi_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_MCSPI3_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_MCSPI3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &mcspi3_dev_attr,
+};
+
+/* mcspi4 */
+/* mcspi4 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi4_dev_attr = {
+	.num_chipselect	= 1,
+};
+
+static struct omap_hwmod dra7xx_mcspi4_hwmod = {
+	.name		= "mcspi4",
+	.class		= &dra7xx_mcspi_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_MCSPI4_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_MCSPI4_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &mcspi4_dev_attr,
+};
+
+/*
+ * 'mmc' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_mmc_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_EMUFREE | SYSC_HAS_MIDLEMODE |
+			   SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+			   MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class dra7xx_mmc_hwmod_class = {
+	.name	= "mmc",
+	.sysc	= &dra7xx_mmc_sysc,
+};
+
+/* mmc1 */
+static struct omap_hwmod_opt_clk mmc1_opt_clks[] = {
+	{ .role = "clk32k", .clk = "mmc1_clk32k" },
+};
+
+/* mmc1 dev_attr */
+static struct omap_mmc_dev_attr mmc1_dev_attr = {
+	.flags	= OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
+};
+
+static struct omap_hwmod dra7xx_mmc1_hwmod = {
+	.name		= "mmc1",
+	.class		= &dra7xx_mmc_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.main_clk	= "mmc1_fclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L3INIT_MMC1_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3INIT_MMC1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mmc1_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mmc1_opt_clks),
+	.dev_attr	= &mmc1_dev_attr,
+};
+
+/* mmc2 */
+static struct omap_hwmod_opt_clk mmc2_opt_clks[] = {
+	{ .role = "clk32k", .clk = "mmc2_clk32k" },
+};
+
+static struct omap_hwmod dra7xx_mmc2_hwmod = {
+	.name		= "mmc2",
+	.class		= &dra7xx_mmc_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.main_clk	= "mmc2_fclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L3INIT_MMC2_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3INIT_MMC2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mmc2_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mmc2_opt_clks),
+};
+
+/* mmc3 */
+static struct omap_hwmod_opt_clk mmc3_opt_clks[] = {
+	{ .role = "clk32k", .clk = "mmc3_clk32k" },
+};
+
+static struct omap_hwmod dra7xx_mmc3_hwmod = {
+	.name		= "mmc3",
+	.class		= &dra7xx_mmc_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "mmc3_gfclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_MMC3_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_MMC3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mmc3_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mmc3_opt_clks),
+};
+
+/* mmc4 */
+static struct omap_hwmod_opt_clk mmc4_opt_clks[] = {
+	{ .role = "clk32k", .clk = "mmc4_clk32k" },
+};
+
+static struct omap_hwmod dra7xx_mmc4_hwmod = {
+	.name		= "mmc4",
+	.class		= &dra7xx_mmc_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "mmc4_gfclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_MMC4_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_MMC4_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mmc4_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mmc4_opt_clks),
+};
+
+/*
+ * 'mpu' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_mpu_hwmod_class = {
+	.name	= "mpu",
+};
+
+/* mpu */
+static struct omap_hwmod dra7xx_mpu_hwmod = {
+	.name		= "mpu",
+	.class		= &dra7xx_mpu_hwmod_class,
+	.clkdm_name	= "mpu_clkdm",
+	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+	.main_clk	= "dpll_mpu_m2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_MPU_MPU_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_MPU_MPU_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
+ * 'ocp2scp' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_ocp2scp_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dra7xx_ocp2scp_hwmod_class = {
+	.name	= "ocp2scp",
+	.sysc	= &dra7xx_ocp2scp_sysc,
+};
+
+/* ocp2scp1 */
+static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
+	.name		= "ocp2scp1",
+	.class		= &dra7xx_ocp2scp_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.main_clk	= "l4_root_clk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L3INIT_OCP2SCP1_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3INIT_OCP2SCP1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/*
+ * 'qspi' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_qspi_sysc = {
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= SYSC_HAS_SIDLEMODE,
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class dra7xx_qspi_hwmod_class = {
+	.name	= "qspi",
+	.sysc	= &dra7xx_qspi_sysc,
+};
+
+/* qspi */
+static struct omap_hwmod dra7xx_qspi_hwmod = {
+	.name		= "qspi",
+	.class		= &dra7xx_qspi_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "qspi_gfclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER2_QSPI_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER2_QSPI_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/*
+ * 'sata' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_sata_sysc = {
+	.sysc_offs	= 0x0000,
+	.sysc_flags	= (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+			   MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class dra7xx_sata_hwmod_class = {
+	.name	= "sata",
+	.sysc	= &dra7xx_sata_sysc,
+};
+
+/* sata */
+static struct omap_hwmod_opt_clk sata_opt_clks[] = {
+	{ .role = "ref_clk", .clk = "sata_ref_clk" },
+};
+
+static struct omap_hwmod dra7xx_sata_hwmod = {
+	.name		= "sata",
+	.class		= &dra7xx_sata_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+	.main_clk	= "func_48m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3INIT_SATA_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= sata_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(sata_opt_clks),
+};
+
+/*
+ * 'smartreflex' class
+ *
+ */
+
+/* The IP is not compliant to type1 / type2 scheme */
+static struct omap_hwmod_sysc_fields omap_hwmod_sysc_type_smartreflex = {
+	.sidle_shift	= 24,
+	.enwkup_shift	= 26,
+};
+
+static struct omap_hwmod_class_sysconfig dra7xx_smartreflex_sysc = {
+	.sysc_offs	= 0x0038,
+	.sysc_flags	= (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type_smartreflex,
+};
+
+static struct omap_hwmod_class dra7xx_smartreflex_hwmod_class = {
+	.name	= "smartreflex",
+	.sysc	= &dra7xx_smartreflex_sysc,
+	.rev	= 2,
+};
+
+/* smartreflex_core */
+/* smartreflex_core dev_attr */
+static struct omap_smartreflex_dev_attr smartreflex_core_dev_attr = {
+	.sensor_voltdm_name	= "core",
+};
+
+static struct omap_hwmod dra7xx_smartreflex_core_hwmod = {
+	.name		= "smartreflex_core",
+	.class		= &dra7xx_smartreflex_hwmod_class,
+	.clkdm_name	= "coreaon_clkdm",
+	.main_clk	= "wkupaon_iclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_COREAON_SMARTREFLEX_CORE_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_COREAON_SMARTREFLEX_CORE_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &smartreflex_core_dev_attr,
+};
+
+/* smartreflex_mpu */
+/* smartreflex_mpu dev_attr */
+static struct omap_smartreflex_dev_attr smartreflex_mpu_dev_attr = {
+	.sensor_voltdm_name	= "mpu",
+};
+
+static struct omap_hwmod dra7xx_smartreflex_mpu_hwmod = {
+	.name		= "smartreflex_mpu",
+	.class		= &dra7xx_smartreflex_hwmod_class,
+	.clkdm_name	= "coreaon_clkdm",
+	.main_clk	= "wkupaon_iclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_COREAON_SMARTREFLEX_MPU_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_COREAON_SMARTREFLEX_MPU_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &smartreflex_mpu_dev_attr,
+};
+
+/*
+ * 'spinlock' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_spinlock_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+			   SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dra7xx_spinlock_hwmod_class = {
+	.name	= "spinlock",
+	.sysc	= &dra7xx_spinlock_sysc,
+};
+
+/* spinlock */
+static struct omap_hwmod dra7xx_spinlock_hwmod = {
+	.name		= "spinlock",
+	.class		= &dra7xx_spinlock_hwmod_class,
+	.clkdm_name	= "l4cfg_clkdm",
+	.main_clk	= "l3_iclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4CFG_SPINLOCK_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4CFG_SPINLOCK_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
+ * 'timer' class
+ *
+ * This class contains several variants: ['timer_1ms', 'timer_secure',
+ * 'timer']
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_timer_1ms_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class dra7xx_timer_1ms_hwmod_class = {
+	.name	= "timer",
+	.sysc	= &dra7xx_timer_1ms_sysc,
+};
+
+static struct omap_hwmod_class_sysconfig dra7xx_timer_secure_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class dra7xx_timer_secure_hwmod_class = {
+	.name	= "timer",
+	.sysc	= &dra7xx_timer_secure_sysc,
+};
+
+static struct omap_hwmod_class_sysconfig dra7xx_timer_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class dra7xx_timer_hwmod_class = {
+	.name	= "timer",
+	.sysc	= &dra7xx_timer_sysc,
+};
+
+/* timer1 */
+static struct omap_hwmod dra7xx_timer1_hwmod = {
+	.name		= "timer1",
+	.class		= &dra7xx_timer_1ms_hwmod_class,
+	.clkdm_name	= "wkupaon_clkdm",
+	.main_clk	= "timer1_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_WKUPAON_TIMER1_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_WKUPAON_TIMER1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer2 */
+static struct omap_hwmod dra7xx_timer2_hwmod = {
+	.name		= "timer2",
+	.class		= &dra7xx_timer_1ms_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "timer2_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_TIMER2_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_TIMER2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer3 */
+static struct omap_hwmod dra7xx_timer3_hwmod = {
+	.name		= "timer3",
+	.class		= &dra7xx_timer_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "timer3_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_TIMER3_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_TIMER3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer4 */
+static struct omap_hwmod dra7xx_timer4_hwmod = {
+	.name		= "timer4",
+	.class		= &dra7xx_timer_secure_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "timer4_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_TIMER4_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_TIMER4_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer5 */
+static struct omap_hwmod dra7xx_timer5_hwmod = {
+	.name		= "timer5",
+	.class		= &dra7xx_timer_hwmod_class,
+	.clkdm_name	= "ipu_clkdm",
+	.main_clk	= "timer5_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_IPU_TIMER5_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_IPU_TIMER5_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer6 */
+static struct omap_hwmod dra7xx_timer6_hwmod = {
+	.name		= "timer6",
+	.class		= &dra7xx_timer_hwmod_class,
+	.clkdm_name	= "ipu_clkdm",
+	.main_clk	= "timer6_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_IPU_TIMER6_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_IPU_TIMER6_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer7 */
+static struct omap_hwmod dra7xx_timer7_hwmod = {
+	.name		= "timer7",
+	.class		= &dra7xx_timer_hwmod_class,
+	.clkdm_name	= "ipu_clkdm",
+	.main_clk	= "timer7_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_IPU_TIMER7_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_IPU_TIMER7_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer8 */
+static struct omap_hwmod dra7xx_timer8_hwmod = {
+	.name		= "timer8",
+	.class		= &dra7xx_timer_hwmod_class,
+	.clkdm_name	= "ipu_clkdm",
+	.main_clk	= "timer8_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_IPU_TIMER8_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_IPU_TIMER8_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer9 */
+static struct omap_hwmod dra7xx_timer9_hwmod = {
+	.name		= "timer9",
+	.class		= &dra7xx_timer_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "timer9_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_TIMER9_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_TIMER9_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer10 */
+static struct omap_hwmod dra7xx_timer10_hwmod = {
+	.name		= "timer10",
+	.class		= &dra7xx_timer_1ms_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "timer10_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_TIMER10_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_TIMER10_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* timer11 */
+static struct omap_hwmod dra7xx_timer11_hwmod = {
+	.name		= "timer11",
+	.class		= &dra7xx_timer_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "timer11_gfclk_mux",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_TIMER11_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_TIMER11_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/*
+ * 'uart' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_uart_sysc = {
+	.rev_offs	= 0x0050,
+	.sysc_offs	= 0x0054,
+	.syss_offs	= 0x0058,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+			   SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dra7xx_uart_hwmod_class = {
+	.name	= "uart",
+	.sysc	= &dra7xx_uart_sysc,
+};
+
+/* uart1 */
+static struct omap_hwmod dra7xx_uart1_hwmod = {
+	.name		= "uart1",
+	.class		= &dra7xx_uart_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "uart1_gfclk_mux",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_UART1_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_UART1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* uart2 */
+static struct omap_hwmod dra7xx_uart2_hwmod = {
+	.name		= "uart2",
+	.class		= &dra7xx_uart_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "uart2_gfclk_mux",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_UART2_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_UART2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* uart3 */
+static struct omap_hwmod dra7xx_uart3_hwmod = {
+	.name		= "uart3",
+	.class		= &dra7xx_uart_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "uart3_gfclk_mux",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_UART3_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_UART3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* uart4 */
+static struct omap_hwmod dra7xx_uart4_hwmod = {
+	.name		= "uart4",
+	.class		= &dra7xx_uart_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "uart4_gfclk_mux",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_UART4_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_UART4_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* uart5 */
+static struct omap_hwmod dra7xx_uart5_hwmod = {
+	.name		= "uart5",
+	.class		= &dra7xx_uart_hwmod_class,
+	.clkdm_name	= "l4per_clkdm",
+	.main_clk	= "uart5_gfclk_mux",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER_UART5_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER_UART5_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* uart6 */
+static struct omap_hwmod dra7xx_uart6_hwmod = {
+	.name		= "uart6",
+	.class		= &dra7xx_uart_hwmod_class,
+	.clkdm_name	= "ipu_clkdm",
+	.main_clk	= "uart6_gfclk_mux",
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_IPU_UART6_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_IPU_UART6_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/*
+ * 'usb_otg_ss' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_usb_otg_ss_hwmod_class = {
+	.name	= "usb_otg_ss",
+};
+
+/* usb_otg_ss1 */
+static struct omap_hwmod_opt_clk usb_otg_ss1_opt_clks[] = {
+	{ .role = "refclk960m", .clk = "usb_otg_ss1_refclk960m" },
+};
+
+static struct omap_hwmod dra7xx_usb_otg_ss1_hwmod = {
+	.name		= "usb_otg_ss1",
+	.class		= &dra7xx_usb_otg_ss_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.main_clk	= "dpll_core_h13x2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS1_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3INIT_USB_OTG_SS1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= usb_otg_ss1_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(usb_otg_ss1_opt_clks),
+};
+
+/* usb_otg_ss2 */
+static struct omap_hwmod_opt_clk usb_otg_ss2_opt_clks[] = {
+	{ .role = "refclk960m", .clk = "usb_otg_ss2_refclk960m" },
+};
+
+static struct omap_hwmod dra7xx_usb_otg_ss2_hwmod = {
+	.name		= "usb_otg_ss2",
+	.class		= &dra7xx_usb_otg_ss_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.main_clk	= "dpll_core_h13x2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS2_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3INIT_USB_OTG_SS2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= usb_otg_ss2_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(usb_otg_ss2_opt_clks),
+};
+
+/* usb_otg_ss3 */
+static struct omap_hwmod dra7xx_usb_otg_ss3_hwmod = {
+	.name		= "usb_otg_ss3",
+	.class		= &dra7xx_usb_otg_ss_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.main_clk	= "dpll_core_h13x2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS3_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3INIT_USB_OTG_SS3_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/* usb_otg_ss4 */
+static struct omap_hwmod dra7xx_usb_otg_ss4_hwmod = {
+	.name		= "usb_otg_ss4",
+	.class		= &dra7xx_usb_otg_ss_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.main_clk	= "dpll_core_h13x2_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS4_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3INIT_USB_OTG_SS4_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/*
+ * 'vcp' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_vcp_hwmod_class = {
+	.name	= "vcp",
+};
+
+/* vcp1 */
+static struct omap_hwmod dra7xx_vcp1_hwmod = {
+	.name		= "vcp1",
+	.class		= &dra7xx_vcp_hwmod_class,
+	.clkdm_name	= "l3main1_clkdm",
+	.main_clk	= "l3_iclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L3MAIN1_VCP1_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3MAIN1_VCP1_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/* vcp2 */
+static struct omap_hwmod dra7xx_vcp2_hwmod = {
+	.name		= "vcp2",
+	.class		= &dra7xx_vcp_hwmod_class,
+	.clkdm_name	= "l3main1_clkdm",
+	.main_clk	= "l3_iclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L3MAIN1_VCP2_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3MAIN1_VCP2_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
+ * 'wd_timer' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_wd_timer_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_EMUFREE | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dra7xx_wd_timer_hwmod_class = {
+	.name		= "wd_timer",
+	.sysc		= &dra7xx_wd_timer_sysc,
+	.pre_shutdown	= &omap2_wd_timer_disable,
+	.reset		= &omap2_wd_timer_reset,
+};
+
+/* wd_timer2 */
+static struct omap_hwmod dra7xx_wd_timer2_hwmod = {
+	.name		= "wd_timer2",
+	.class		= &dra7xx_wd_timer_hwmod_class,
+	.clkdm_name	= "wkupaon_clkdm",
+	.main_clk	= "sys_32k_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_WKUPAON_WD_TIMER2_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_WKUPAON_WD_TIMER2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+
+/*
+ * Interfaces
+ */
+
+/* l3_main_2 -> l3_instr */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_2__l3_instr = {
+	.master		= &dra7xx_l3_main_2_hwmod,
+	.slave		= &dra7xx_l3_instr_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg -> l3_main_1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__l3_main_1 = {
+	.master		= &dra7xx_l4_cfg_hwmod,
+	.slave		= &dra7xx_l3_main_1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mpu -> l3_main_1 */
+static struct omap_hwmod_ocp_if dra7xx_mpu__l3_main_1 = {
+	.master		= &dra7xx_mpu_hwmod,
+	.slave		= &dra7xx_l3_main_1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU,
+};
+
+/* l3_main_1 -> l3_main_2 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__l3_main_2 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_l3_main_2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU,
+};
+
+/* l4_cfg -> l3_main_2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__l3_main_2 = {
+	.master		= &dra7xx_l4_cfg_hwmod,
+	.slave		= &dra7xx_l3_main_2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> l4_cfg */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__l4_cfg = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_l4_cfg_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> l4_per1 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__l4_per1 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_l4_per1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> l4_per2 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__l4_per2 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_l4_per2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> l4_per3 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__l4_per3 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_l4_per3_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> l4_wkup */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__l4_wkup = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_l4_wkup_hwmod,
+	.clk		= "wkupaon_iclk_mux",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per2 -> atl */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__atl = {
+	.master		= &dra7xx_l4_per2_hwmod,
+	.slave		= &dra7xx_atl_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> bb2d */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__bb2d = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_bb2d_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> counter_32k */
+static struct omap_hwmod_ocp_if dra7xx_l4_wkup__counter_32k = {
+	.master		= &dra7xx_l4_wkup_hwmod,
+	.slave		= &dra7xx_counter_32k_hwmod,
+	.clk		= "wkupaon_iclk_mux",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> ctrl_module_wkup */
+static struct omap_hwmod_ocp_if dra7xx_l4_wkup__ctrl_module_wkup = {
+	.master		= &dra7xx_l4_wkup_hwmod,
+	.slave		= &dra7xx_ctrl_module_wkup_hwmod,
+	.clk		= "wkupaon_iclk_mux",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> dcan1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_wkup__dcan1 = {
+	.master		= &dra7xx_l4_wkup_hwmod,
+	.slave		= &dra7xx_dcan1_hwmod,
+	.clk		= "wkupaon_iclk_mux",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per2 -> dcan2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__dcan2 = {
+	.master		= &dra7xx_l4_per2_hwmod,
+	.slave		= &dra7xx_dcan2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space dra7xx_dma_system_addrs[] = {
+	{
+		.pa_start	= 0x4a056000,
+		.pa_end		= 0x4a056fff,
+		.flags		= ADDR_TYPE_RT
+	},
+	{ }
+};
+
+/* l4_cfg -> dma_system */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__dma_system = {
+	.master		= &dra7xx_l4_cfg_hwmod,
+	.slave		= &dra7xx_dma_system_hwmod,
+	.clk		= "l3_iclk_div",
+	.addr		= dra7xx_dma_system_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space dra7xx_dss_addrs[] = {
+	{
+		.name		= "family",
+		.pa_start	= 0x58000000,
+		.pa_end		= 0x5800007f,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l3_main_1 -> dss */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__dss = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_dss_hwmod,
+	.clk		= "l3_iclk_div",
+	.addr		= dra7xx_dss_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space dra7xx_dss_dispc_addrs[] = {
+	{
+		.name		= "dispc",
+		.pa_start	= 0x58001000,
+		.pa_end		= 0x58001fff,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l3_main_1 -> dispc */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__dispc = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_dss_dispc_hwmod,
+	.clk		= "l3_iclk_div",
+	.addr		= dra7xx_dss_dispc_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space dra7xx_dss_hdmi_addrs[] = {
+	{
+		.name		= "hdmi_wp",
+		.pa_start	= 0x58040000,
+		.pa_end		= 0x580400ff,
+		.flags		= ADDR_TYPE_RT
+	},
+	{ }
+};
+
+/* l3_main_1 -> dispc */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_dss_hdmi_hwmod,
+	.clk		= "l3_iclk_div",
+	.addr		= dra7xx_dss_hdmi_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
+	{
+		.pa_start	= 0x48078000,
+		.pa_end		= 0x48078fff,
+		.flags		= ADDR_TYPE_RT
+	},
+	{ }
+};
+
+/* l4_per1 -> elm */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__elm = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_elm_hwmod,
+	.clk		= "l3_iclk_div",
+	.addr		= dra7xx_elm_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> gpio1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_wkup__gpio1 = {
+	.master		= &dra7xx_l4_wkup_hwmod,
+	.slave		= &dra7xx_gpio1_hwmod,
+	.clk		= "wkupaon_iclk_mux",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> gpio2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio2 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_gpio2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> gpio3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio3 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_gpio3_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> gpio4 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio4 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_gpio4_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> gpio5 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio5 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_gpio5_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> gpio6 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio6 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_gpio6_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> gpio7 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio7 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_gpio7_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> gpio8 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio8 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_gpio8_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space dra7xx_gpmc_addrs[] = {
+	{
+		.pa_start	= 0x50000000,
+		.pa_end		= 0x500003ff,
+		.flags		= ADDR_TYPE_RT
+	},
+	{ }
+};
+
+/* l3_main_1 -> gpmc */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__gpmc = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_gpmc_hwmod,
+	.clk		= "l3_iclk_div",
+	.addr		= dra7xx_gpmc_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space dra7xx_hdq1w_addrs[] = {
+	{
+		.pa_start	= 0x480b2000,
+		.pa_end		= 0x480b201f,
+		.flags		= ADDR_TYPE_RT
+	},
+	{ }
+};
+
+/* l4_per1 -> hdq1w */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__hdq1w = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_hdq1w_hwmod,
+	.clk		= "l3_iclk_div",
+	.addr		= dra7xx_hdq1w_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> i2c1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__i2c1 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_i2c1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> i2c2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__i2c2 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_i2c2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> i2c3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__i2c3 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_i2c3_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> i2c4 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__i2c4 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_i2c4_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> i2c5 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__i2c5 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_i2c5_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> mcspi1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__mcspi1 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_mcspi1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> mcspi2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__mcspi2 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_mcspi2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> mcspi3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__mcspi3 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_mcspi3_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> mcspi4 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__mcspi4 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_mcspi4_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> mmc1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__mmc1 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_mmc1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> mmc2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__mmc2 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_mmc2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> mmc3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__mmc3 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_mmc3_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> mmc4 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__mmc4 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_mmc4_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg -> mpu */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__mpu = {
+	.master		= &dra7xx_l4_cfg_hwmod,
+	.slave		= &dra7xx_mpu_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space dra7xx_ocp2scp1_addrs[] = {
+	{
+		.pa_start	= 0x4a080000,
+		.pa_end		= 0x4a08001f,
+		.flags		= ADDR_TYPE_RT
+	},
+	{ }
+};
+
+/* l4_cfg -> ocp2scp1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp1 = {
+	.master		= &dra7xx_l4_cfg_hwmod,
+	.slave		= &dra7xx_ocp2scp1_hwmod,
+	.clk		= "l4_root_clk_div",
+	.addr		= dra7xx_ocp2scp1_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space dra7xx_qspi_addrs[] = {
+	{
+		.pa_start	= 0x4b300000,
+		.pa_end		= 0x4b30007f,
+		.flags		= ADDR_TYPE_RT
+	},
+	{ }
+};
+
+/* l3_main_1 -> qspi */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__qspi = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_qspi_hwmod,
+	.clk		= "l3_iclk_div",
+	.addr		= dra7xx_qspi_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space dra7xx_sata_addrs[] = {
+	{
+		.name		= "sysc",
+		.pa_start	= 0x4a141100,
+		.pa_end		= 0x4a141107,
+		.flags		= ADDR_TYPE_RT
+	},
+	{ }
+};
+
+/* l4_cfg -> sata */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__sata = {
+	.master		= &dra7xx_l4_cfg_hwmod,
+	.slave		= &dra7xx_sata_hwmod,
+	.clk		= "l3_iclk_div",
+	.addr		= dra7xx_sata_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space dra7xx_smartreflex_core_addrs[] = {
+	{
+		.pa_start	= 0x4a0dd000,
+		.pa_end		= 0x4a0dd07f,
+		.flags		= ADDR_TYPE_RT
+	},
+	{ }
+};
+
+/* l4_cfg -> smartreflex_core */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__smartreflex_core = {
+	.master		= &dra7xx_l4_cfg_hwmod,
+	.slave		= &dra7xx_smartreflex_core_hwmod,
+	.clk		= "l4_root_clk_div",
+	.addr		= dra7xx_smartreflex_core_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space dra7xx_smartreflex_mpu_addrs[] = {
+	{
+		.pa_start	= 0x4a0d9000,
+		.pa_end		= 0x4a0d907f,
+		.flags		= ADDR_TYPE_RT
+	},
+	{ }
+};
+
+/* l4_cfg -> smartreflex_mpu */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__smartreflex_mpu = {
+	.master		= &dra7xx_l4_cfg_hwmod,
+	.slave		= &dra7xx_smartreflex_mpu_hwmod,
+	.clk		= "l4_root_clk_div",
+	.addr		= dra7xx_smartreflex_mpu_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_addr_space dra7xx_spinlock_addrs[] = {
+	{
+		.pa_start	= 0x4a0f6000,
+		.pa_end		= 0x4a0f6fff,
+		.flags		= ADDR_TYPE_RT
+	},
+	{ }
+};
+
+/* l4_cfg -> spinlock */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__spinlock = {
+	.master		= &dra7xx_l4_cfg_hwmod,
+	.slave		= &dra7xx_spinlock_hwmod,
+	.clk		= "l3_iclk_div",
+	.addr		= dra7xx_spinlock_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> timer1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_wkup__timer1 = {
+	.master		= &dra7xx_l4_wkup_hwmod,
+	.slave		= &dra7xx_timer1_hwmod,
+	.clk		= "wkupaon_iclk_mux",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> timer2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__timer2 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_timer2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> timer3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__timer3 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_timer3_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> timer4 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__timer4 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_timer4_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per3 -> timer5 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__timer5 = {
+	.master		= &dra7xx_l4_per3_hwmod,
+	.slave		= &dra7xx_timer5_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per3 -> timer6 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__timer6 = {
+	.master		= &dra7xx_l4_per3_hwmod,
+	.slave		= &dra7xx_timer6_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per3 -> timer7 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__timer7 = {
+	.master		= &dra7xx_l4_per3_hwmod,
+	.slave		= &dra7xx_timer7_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per3 -> timer8 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__timer8 = {
+	.master		= &dra7xx_l4_per3_hwmod,
+	.slave		= &dra7xx_timer8_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> timer9 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__timer9 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_timer9_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> timer10 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__timer10 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_timer10_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> timer11 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__timer11 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_timer11_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> uart1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__uart1 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_uart1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> uart2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__uart2 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_uart2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> uart3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__uart3 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_uart3_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> uart4 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__uart4 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_uart4_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> uart5 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__uart5 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_uart5_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per1 -> uart6 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per1__uart6 = {
+	.master		= &dra7xx_l4_per1_hwmod,
+	.slave		= &dra7xx_uart6_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per3 -> usb_otg_ss1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__usb_otg_ss1 = {
+	.master		= &dra7xx_l4_per3_hwmod,
+	.slave		= &dra7xx_usb_otg_ss1_hwmod,
+	.clk		= "dpll_core_h13x2_ck",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per3 -> usb_otg_ss2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__usb_otg_ss2 = {
+	.master		= &dra7xx_l4_per3_hwmod,
+	.slave		= &dra7xx_usb_otg_ss2_hwmod,
+	.clk		= "dpll_core_h13x2_ck",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per3 -> usb_otg_ss3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__usb_otg_ss3 = {
+	.master		= &dra7xx_l4_per3_hwmod,
+	.slave		= &dra7xx_usb_otg_ss3_hwmod,
+	.clk		= "dpll_core_h13x2_ck",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per3 -> usb_otg_ss4 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__usb_otg_ss4 = {
+	.master		= &dra7xx_l4_per3_hwmod,
+	.slave		= &dra7xx_usb_otg_ss4_hwmod,
+	.clk		= "dpll_core_h13x2_ck",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> vcp1 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__vcp1 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_vcp1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per2 -> vcp1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__vcp1 = {
+	.master		= &dra7xx_l4_per2_hwmod,
+	.slave		= &dra7xx_vcp1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> vcp2 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__vcp2 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_vcp2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per2 -> vcp2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__vcp2 = {
+	.master		= &dra7xx_l4_per2_hwmod,
+	.slave		= &dra7xx_vcp2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_wkup -> wd_timer2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_wkup__wd_timer2 = {
+	.master		= &dra7xx_l4_wkup_hwmod,
+	.slave		= &dra7xx_wd_timer2_hwmod,
+	.clk		= "wkupaon_iclk_mux",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
+	&dra7xx_l3_main_2__l3_instr,
+	&dra7xx_l4_cfg__l3_main_1,
+	&dra7xx_mpu__l3_main_1,
+	&dra7xx_l3_main_1__l3_main_2,
+	&dra7xx_l4_cfg__l3_main_2,
+	&dra7xx_l3_main_1__l4_cfg,
+	&dra7xx_l3_main_1__l4_per1,
+	&dra7xx_l3_main_1__l4_per2,
+	&dra7xx_l3_main_1__l4_per3,
+	&dra7xx_l3_main_1__l4_wkup,
+	&dra7xx_l4_per2__atl,
+	&dra7xx_l3_main_1__bb2d,
+	&dra7xx_l4_wkup__counter_32k,
+	&dra7xx_l4_wkup__ctrl_module_wkup,
+	&dra7xx_l4_wkup__dcan1,
+	&dra7xx_l4_per2__dcan2,
+	&dra7xx_l4_cfg__dma_system,
+	&dra7xx_l3_main_1__dss,
+	&dra7xx_l3_main_1__dispc,
+	&dra7xx_l3_main_1__hdmi,
+	&dra7xx_l4_per1__elm,
+	&dra7xx_l4_wkup__gpio1,
+	&dra7xx_l4_per1__gpio2,
+	&dra7xx_l4_per1__gpio3,
+	&dra7xx_l4_per1__gpio4,
+	&dra7xx_l4_per1__gpio5,
+	&dra7xx_l4_per1__gpio6,
+	&dra7xx_l4_per1__gpio7,
+	&dra7xx_l4_per1__gpio8,
+	&dra7xx_l3_main_1__gpmc,
+	&dra7xx_l4_per1__hdq1w,
+	&dra7xx_l4_per1__i2c1,
+	&dra7xx_l4_per1__i2c2,
+	&dra7xx_l4_per1__i2c3,
+	&dra7xx_l4_per1__i2c4,
+	&dra7xx_l4_per1__i2c5,
+	&dra7xx_l4_per1__mcspi1,
+	&dra7xx_l4_per1__mcspi2,
+	&dra7xx_l4_per1__mcspi3,
+	&dra7xx_l4_per1__mcspi4,
+	&dra7xx_l4_per1__mmc1,
+	&dra7xx_l4_per1__mmc2,
+	&dra7xx_l4_per1__mmc3,
+	&dra7xx_l4_per1__mmc4,
+	&dra7xx_l4_cfg__mpu,
+	&dra7xx_l4_cfg__ocp2scp1,
+	&dra7xx_l3_main_1__qspi,
+	&dra7xx_l4_cfg__sata,
+	&dra7xx_l4_cfg__smartreflex_core,
+	&dra7xx_l4_cfg__smartreflex_mpu,
+	&dra7xx_l4_cfg__spinlock,
+	&dra7xx_l4_wkup__timer1,
+	&dra7xx_l4_per1__timer2,
+	&dra7xx_l4_per1__timer3,
+	&dra7xx_l4_per1__timer4,
+	&dra7xx_l4_per3__timer5,
+	&dra7xx_l4_per3__timer6,
+	&dra7xx_l4_per3__timer7,
+	&dra7xx_l4_per3__timer8,
+	&dra7xx_l4_per1__timer9,
+	&dra7xx_l4_per1__timer10,
+	&dra7xx_l4_per1__timer11,
+	&dra7xx_l4_per1__uart1,
+	&dra7xx_l4_per1__uart2,
+	&dra7xx_l4_per1__uart3,
+	&dra7xx_l4_per1__uart4,
+	&dra7xx_l4_per1__uart5,
+	&dra7xx_l4_per1__uart6,
+	&dra7xx_l4_per3__usb_otg_ss1,
+	&dra7xx_l4_per3__usb_otg_ss2,
+	&dra7xx_l4_per3__usb_otg_ss3,
+	&dra7xx_l4_per3__usb_otg_ss4,
+	&dra7xx_l3_main_1__vcp1,
+	&dra7xx_l4_per2__vcp1,
+	&dra7xx_l3_main_1__vcp2,
+	&dra7xx_l4_per2__vcp2,
+	&dra7xx_l4_wkup__wd_timer2,
+	NULL,
+};
+
+int __init dra7xx_hwmod_init(void)
+{
+	omap_hwmod_init();
+	return omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs);
+}
-- 
1.7.9.5



From srinivas.kandagatla at st.com  Tue Jul  9 03:26:33 2013
From: srinivas.kandagatla at st.com (Srinivas KANDAGATLA)
Date: Tue,  9 Jul 2013 08:26:33 +0100
Subject: [PATCH v2 2/2] ARM: STi: Set correct ARM ERRATAs.
In-Reply-To: <1373354752-26292-1-git-send-email-srinivas.kandagatla@st.com>
References: <1373354752-26292-1-git-send-email-srinivas.kandagatla@st.com>
Message-ID: <1373354793-26400-1-git-send-email-srinivas.kandagatla@st.com>

From: Srinivas Kandagatla <srinivas.kandagatla at st.com>

Some of the ARM_ERRATA selection is not done in the initial SOC support
patches. This patch selects 2 new ARM_ERRATA's and removes one which was
actually fixed.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at st.com>
---
 arch/arm/mach-sti/Kconfig |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
index d04e3bf..c216094 100644
--- a/arch/arm/mach-sti/Kconfig
+++ b/arch/arm/mach-sti/Kconfig
@@ -11,8 +11,9 @@ menuconfig ARCH_STI
 	select HAVE_SMP
 	select HAVE_ARM_SCU if SMP
 	select ARCH_REQUIRE_GPIOLIB
-	select ARM_ERRATA_720789
 	select ARM_ERRATA_754322
+	select ARM_ERRATA_775420
+	select ARM_ERRATA_764369
 	select PL310_ERRATA_753970 if CACHE_PL310
 	select PL310_ERRATA_769419 if CACHE_PL310
 	help
-- 
1.7.6.5



From srinivas.kandagatla at st.com  Tue Jul  9 03:25:52 2013
From: srinivas.kandagatla at st.com (Srinivas KANDAGATLA)
Date: Tue,  9 Jul 2013 08:25:52 +0100
Subject: [PATCH v2 0/2] ARM: STi Fixes
Message-ID: <1373354752-26292-1-git-send-email-srinivas.kandagatla@st.com>

From: Srinivas Kandagatla <srinivas.kandagatla at st.com>

This patch series fixes 2 configuration issues related to serial
setup on STiH416 and ARM ERRATA selection.

Changes since v1:
	- Split out fixes in seperate patch set.

Srinivas Kandagatla (2):
  ARM: dts: STi: Fix pinconf setup for STiH416 serial2
  ARM: STi: Set correct ARM ERRATAs.

 arch/arm/boot/dts/stih416-pinctrl.dtsi |   10 +++++++++-
 arch/arm/boot/dts/stih416.dtsi         |    2 +-
 arch/arm/mach-sti/Kconfig              |    3 ++-
 3 files changed, 12 insertions(+), 3 deletions(-)

-- 
1.7.6.5



From arnd at arndb.de  Tue Jul  9 03:37:29 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Jul 2013 09:37:29 +0200
Subject: [PATCH 03/04] ARM: shmobile: Add EMEV2 and KZM9D to
 ARCH_SHMOBILE_MULTI
In-Reply-To: <20130709054359.14007.23619.sendpatchset@w520>
References: <20130709054331.14007.66068.sendpatchset@w520>
 <20130709054359.14007.23619.sendpatchset@w520>
Message-ID: <201307090937.29805.arnd@arndb.de>

On Tuesday 09 July 2013, Magnus Damm wrote:
> +void __init __weak emev2_clock_init(void)
> +{
> +       /* in case legacy clocks are disabled then do nothing */
> +}

Nitpicking:

I don't like the __weak symbols too much, in general I prefer
doing either

	if (IS_ENABLED(CONFIG_SHMOBILE_CLOCKS)
		emev2_clock_init()

or using an inline alternative in the header file.

	Arnd


From richard.genoud at gmail.com  Tue Jul  9 03:37:31 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 9 Jul 2013 09:37:31 +0200
Subject: [alsa-devel] [PATCH v2 1/5] sound: sam9x5_wm8731: machine driver
 for at91sam9x5 wm8731 boards
In-Reply-To: <51DACF15.9080303@metafoo.de>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373290193-25300-2-git-send-email-richard.genoud@gmail.com>
 <51DACF15.9080303@metafoo.de>
Message-ID: <CACQ1gAh2Cy8VTx4Mgdv2NdrjdX1M7m-5M+8LqY6ncz3kS16O6g@mail.gmail.com>

2013/7/8 Lars-Peter Clausen <lars at metafoo.de>:
> On 07/08/2013 03:29 PM, Richard Genoud wrote:
> [...]
>> +/*
>> + * Logic for a wm8731 as connected on a at91sam9x5 based board.
>> + */
>> +static int at91sam9x5ek_wm8731_init(struct snd_soc_pcm_runtime *rtd)
>> +{
> [...]
>> +     codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 |
>> +             SNDRV_PCM_RATE_32000 |
>> +             SNDRV_PCM_RATE_48000 |
>> +             SNDRV_PCM_RATE_96000;
>> +     codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 |
>> +             SNDRV_PCM_RATE_32000 |
>> +             SNDRV_PCM_RATE_48000 |
>> +             SNDRV_PCM_RATE_96000;
>
> That's not right. The driver structure is shared between all instances of
> the codec, a single instance should not modify it. If you need to constrain
> the list of supported rates use snd_pcm_hw_constraint_list().
Ok, I'll do that.

>
>> +
>> +     /* set the codec system clock for DAC and ADC */
>> +     ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
>> +                                  MCLK_RATE, SND_SOC_CLOCK_IN);
>> +     if (ret < 0) {
>> +             dev_err(dev, "ASoC: Failed to set WM8731 SYSCLK: %d\n", ret);
>> +             return ret;
>> +     }
>> +
>> +     /* signal a DAPM event */
>> +     snd_soc_dapm_sync(dapm);
>
> This should not be necessary.
ok
>
>> +     return 0;
>> +}
>

Thanks !

-- 
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?


From nicolas.pitre at linaro.org  Tue Jul  9 03:39:30 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 9 Jul 2013 08:39:30 +0100 (IST)
Subject: kernel decompressor problem for ARMv7
In-Reply-To: <CAF1ivSbk70UnNc-09C2w-CdgaFBXe_k6K6n8Qr3L-jCLiTGqow@mail.gmail.com>
References: <CAF1ivSakn8-HiAf+4_cLRWUUTDP9QBKpAt+hVQoMyAmKZ2-dJA@mail.gmail.com>
 <20130705095757.GA13063@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1307051225240.18597@syhkavp.arg>
 <CAF1ivSbOXknHyDMH3RdmSGK2n5o2wVeR5oohCQnZ2gJrgvo=Hw@mail.gmail.com>
 <1373250435.824.6.camel@minggr>
 <CAF1ivSbk70UnNc-09C2w-CdgaFBXe_k6K6n8Qr3L-jCLiTGqow@mail.gmail.com>
Message-ID: <alpine.LFD.2.03.1307090837230.28525@syhkavp.arg>

On Tue, 9 Jul 2013, Lin Ming wrote:

> On Mon, Jul 8, 2013 at 10:27 AM, Lin Ming <minggr at gmail.com> wrote:
> > On Sat, 2013-07-06 at 00:58 +0800, Lin Ming wrote:
> >> On Sat, Jul 6, 2013 at 12:30 AM, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> >> > On Fri, 5 Jul 2013, Will Deacon wrote:
> >> >
> >> >> On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
> >> >> > Hi all,
> >> >>
> >> >> Hello,
> >> >>
> >> >> > I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.
> >> >>
> >> >> Which specific processor/SoC?
> >> >>
> >> >> > But decompressor doesn't work. With a lot of debug, I finally find
> >> >> > below 2 commits related.
> >> >> > Kernel uncompress OK with these commits reverted.
> >> >> >
> >> >> > dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
> >> >> > (Introduced in v3.6-rc6)
> >> >> >
> >> >> > 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
> >> >> > v6 and above
> >> >> > (Introduced in v3.7-rc8)
> >> >> >
> >> >> > Any hint to fix it?
> >> >>
> >> >> There's not really enough information to go on here. What specifically
> >> >> fails? Also, do you have to revert *both* of the above changes to get things
> >> >> working again?
> >> >
> >> > Also, what is the bootloader used here?
> >>
> >> uboot.
> >>
> >> >
> >> > Does the bootloader call the kernel with the MMU off as documented in
> >> > Documentation/arm/Booting?
> >>
> >> How to check this?
> >>
> >> I'll check uboot code or add debug code in boot/compressed/head.S to
> >> check it next Monday.
> >
> > I added below debug code to print the control reg from lowest 4bits to
> > highest 4bits.
> >
> > It prints "B7805C". So the control reg is 0x00c5087b.
> > Seems bootloader calls the kernel with MMU enabled and Alignment fault
> > checking enabled.
> 
> Hi Nicolas,
> 
> Is this information useful?
> Or any other information needed for further debug?

No more info needed.  The kernel has to be booted with the MMU disabled 
as per the booting protocol documentation. You therefore have to fix 
your 
bootloader.


Nicolas


From balbi at ti.com  Tue Jul  9 03:40:05 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 9 Jul 2013 10:40:05 +0300
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51DBB96E.90600@ti.com>
References: <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <51DBA0C2.6030003@ti.com>
 <20130709064212.GB5552@arwen.pp.htv.fi> <51DBB96E.90600@ti.com>
Message-ID: <20130709074005.GG5552@arwen.pp.htv.fi>

Hi,

On Tue, Jul 09, 2013 at 12:49:10PM +0530, Rajendra Nayak wrote:
> >>>> Right, but calling serial_omap_restore_context() even when the context
> >>>> is not lost, should not ideally cause an issue.
> >>>
> >>> it does in one condition. If context hasn't been saved before. And that
> >>> can happen in the case of wrong pm runtime status for that device.
> >>>
> >>> Imagine the device is marked as suspended even though it's fully enabled
> >>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> >>> your context structure is all zeroes (context has never been saved
> >>> before) then when you call pm_runtime_get_sync() on probe() your
> >>> ->runtime_resume() will get called, which will restore context,
> >>> essentially undoing anything which was configured by u-boot.
> >>
> >> This could be a problem for drivers which do a save context in ->runtime_suspend()
> >> but from what I see with omap serial, there is no save context done as part of
> >> ->runtime_suspend.
> > 
> > right, because context is "saved" in set_termios. probe() will get
> > called much before set_termios() has a chance to run, right ?
> > 
> > Same problem will trigger in that case.
> > 
> > I still think patch below is necessary
> 
> Right, I'll try some on those lines. Looks like a
> pm_runtime_set_active() is done for the console in the non DT case in
> omap_serial_init_port(). It seems to be missing in the DT case.

yeah, based on conversation I had with Alan Stern a while back,
pm_runtime_set_*() is best called by the underlying 'bus' and I tend to
agree with him on that.

Our HWMOD being our 'bus' (not really, but still), is the entity which
knows if the device is powered or not and should make sure to call
pm_runtime_set_*() for all devices.

> Although I feel this should fix the issue we have right now, I wonder
> if there could ever be a case with uart being suspended and having to
> resume again before a set_termios? What I mean to ask is, if the omap
> serial driver assuming a resume to happen only post a set_termios is
> always valid.

Meaning, probe() -> suspend() -> resume() ? I don't think that would
ever happen. ->set_termios() would always get called and that's actually
what triggers the resume.

-- 
balbi
-------------- 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/20130709/b1c30c1f/attachment.sig>

From ludovic.desroches at atmel.com  Tue Jul  9 03:40:59 2013
From: ludovic.desroches at atmel.com (Ludovic Desroches)
Date: Tue, 9 Jul 2013 09:40:59 +0200
Subject: [PATCH 7/7] serial: at91: add dma support in usart binding
 descriptions
In-Reply-To: <1373351626-30143-8-git-send-email-elen.song@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
 <1373351626-30143-8-git-send-email-elen.song@atmel.com>
Message-ID: <20130709074059.GC4013@ludovic.desroches@atmel.com>

On Tue, Jul 09, 2013 at 02:33:46PM +0800, Elen Song wrote:

[...]

>  Example:
> -
> +- use PDC:
>  	usart0: serial at fff8c000 {
>  		compatible = "atmel,at91sam9260-usart";
>  		reg = <0xfff8c000 0x200>;
> @@ -25,3 +31,12 @@ Example:
>  		atmel,use-pdc-tx;
>  	};
>  
> +- use DMA:
> +	usart0: serial at f001c000 {
> +		compatible = "atmel,at91sam9260-usart";
> +		reg = <0xf001c000 0x100>;
> +		interrupts = <12 IRQ_TYPE_LEVEL_HIGH 5>;
> +		dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(3)>,
> +		       <&dma0 2 (AT91_DMA_CFG_PER_ID(4) | AT91_DMA_CFG_FIFOCFG_ASAP)>;

Same comment than patch 1/7. Maybe wait for confirmation by someone else before
correcting it.

> +		dma-names = "tx", "rx";
> +	};
> -- 
> 1.7.9.5
> 


From arnd at arndb.de  Tue Jul  9 03:43:07 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Jul 2013 09:43:07 +0200
Subject: [PATCH 01/04] ARM: shmobile: Only build clocks when COMMON_CLK=n
In-Reply-To: <20130709054341.14007.99736.sendpatchset@w520>
References: <20130709054331.14007.66068.sendpatchset@w520>
 <20130709054341.14007.99736.sendpatchset@w520>
Message-ID: <201307090943.07898.arnd@arndb.de>

On Tuesday 09 July 2013, Magnus Damm wrote:
> +obj-y                          += $(clk-y$(CONFIG_COMMON_CLK))

It took me a bit to understand the Makefile trick you are using here.
I assume other readers will have the same problem. How about just
doing

+ifndef CONFIG_COMMON_CLK
 obj-$(CONFIG_ARCH_SH7372)      += setup-sh7372.o intc-sh7372.o
 obj-$(CONFIG_ARCH_SH73A0)      += setup-sh73a0.o intc-sh73a0.o
 obj-$(CONFIG_ARCH_R8A73A4)     += setup-r8a73a4.o
 obj-$(CONFIG_ARCH_R8A7740)     += setup-r8a7740.o intc-r8a7740.o
 obj-$(CONFIG_ARCH_R8A7778)     += setup-r8a7778.o
 obj-$(CONFIG_ARCH_R8A7779)     += setup-r8a7779.o intc-r8a7779.o
 obj-$(CONFIG_ARCH_R8A7790)     += setup-r8a7790.o
 obj-$(CONFIG_ARCH_EMEV2)       += setup-emev2.o
+endif

	Arnd


From b32955 at freescale.com  Tue Jul  9 03:46:34 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 9 Jul 2013 15:46:34 +0800
Subject: [PATCH] of: match the compatible in the order set by the dts file
In-Reply-To: <20130709070541.GQ516@pengutronix.de>
References: <1373013818-11365-1-git-send-email-b32955@freescale.com>
 <20130709070541.GQ516@pengutronix.de>
Message-ID: <51DBBFDA.70302@freescale.com>

? 2013?07?09? 15:05, Sascha Hauer ??:
> Why don't you set the matching order in the driver the way you want it
> to be, i.e.:
>
> 	{ .compatible = "fsl,imx6q-uart", ... },
> 	{ .compatible = "fsl,imx21-uart", ... },
> 	{ .compatible = "fsl,imx1-uart", ... },
>
yes. i can set it like this.

but this method looks like a ugly workaround.

thanks
Huang Shijie



From laurent.pinchart at ideasonboard.com  Tue Jul  9 03:45:58 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 09 Jul 2013 09:45:58 +0200
Subject: [PATCH 01/04] ARM: shmobile: Only build clocks when COMMON_CLK=n
In-Reply-To: <201307090943.07898.arnd@arndb.de>
References: <20130709054331.14007.66068.sendpatchset@w520>
 <20130709054341.14007.99736.sendpatchset@w520>
 <201307090943.07898.arnd@arndb.de>
Message-ID: <1774541.9WRl3VrJqz@avalon>

Hi Arnd and Magnus,

On Tuesday 09 July 2013 09:43:07 Arnd Bergmann wrote:
> On Tuesday 09 July 2013, Magnus Damm wrote:
> > +obj-y                          += $(clk-y$(CONFIG_COMMON_CLK))
> 
> It took me a bit to understand the Makefile trick you are using here.
> I assume other readers will have the same problem. How about just
> doing
> 
> +ifndef CONFIG_COMMON_CLK
>  obj-$(CONFIG_ARCH_SH7372)      += setup-sh7372.o intc-sh7372.o
>  obj-$(CONFIG_ARCH_SH73A0)      += setup-sh73a0.o intc-sh73a0.o
>  obj-$(CONFIG_ARCH_R8A73A4)     += setup-r8a73a4.o
>  obj-$(CONFIG_ARCH_R8A7740)     += setup-r8a7740.o intc-r8a7740.o
>  obj-$(CONFIG_ARCH_R8A7778)     += setup-r8a7778.o
>  obj-$(CONFIG_ARCH_R8A7779)     += setup-r8a7779.o intc-r8a7779.o
>  obj-$(CONFIG_ARCH_R8A7790)     += setup-r8a7790.o
>  obj-$(CONFIG_ARCH_EMEV2)       += setup-emev2.o
> +endif

I was about to mention the same, so I think that would be a good idea.

-- 
Regards,

Laurent Pinchart



From arnd at arndb.de  Tue Jul  9 03:45:36 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Jul 2013 09:45:36 +0200
Subject: [PATCH 00/04] ARM: shmobile: ARCH_MULTIPLATFORM for EMEV2 and
 KZM9D
In-Reply-To: <20130709054331.14007.66068.sendpatchset@w520>
References: <20130709054331.14007.66068.sendpatchset@w520>
Message-ID: <201307090945.36314.arnd@arndb.de>

On Tuesday 09 July 2013, Magnus Damm wrote:
> ARM: shmobile: ARCH_MULTIPLATFORM for EMEV2 and KZM9D
> 
> [PATCH 01/04] ARM: shmobile: Only build clocks when COMMON_CLK=n
> [PATCH 02/04] ARM: shmobile: Introduce ARCH_SHMOBILE_MULTI
> [PATCH 03/04] ARM: shmobile: Add EMEV2 and KZM9D to ARCH_SHMOBILE_MULTI
> [PATCH 04/04] ARM: shmobile: Allow ARCH_SHMOBILE_MULTI timer configuration
> 
> This patch set extends mach-shmobile to allow a subset of SoCs and
> boards to be built for ARCH_MULTIPLATFORM. With this series applied
> the EMEV2 SoC and the KZM9D board can be built in two ways - either
> as good old ARCH_SHMOBILE or new ARCH_SHMOBILE_MULTI. The latter
> requires common clock framework for proper run time operation.
> 
> The goal is to over time move all DT reference implementations from
> ARCH_SHMOBILE to ARCH_SHMOBILE_MULTI. Until CCF is available for a
> certain SoC it is to me acceptable for a DT reference board to allow
> build in both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI. The reason for
> this is to allow incremental development and easy testing during
> development of CCF for a certain SoC. The KZM9D board is now in this
> state while it is waiting for common clocks to become ready.
> 
> In the near future a prototype hack will be posted that comments
> out the clock framework bits on EMEV2 and will allow boot of KZM9D
> in the case of ARCH_SHMOBILE_MULTI even though CCF is not yet
> available.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

Great stuff, very glad you got this far!

I have two small style comments, nothing important.

	Arnd


From will.deacon at arm.com  Tue Jul  9 03:45:54 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Jul 2013 08:45:54 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <51DB84D5.3000700@gmail.com>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com>
 <20130708084911.GA22057@mudshark.cambridge.arm.com>
 <51DA8BBF.7080104@gmail.com>
 <20130708110202.GD22057@mudshark.cambridge.arm.com>
 <20130708170352.GA24361@mudshark.cambridge.arm.com>
 <51DB64FB.8030208@gmail.com> <51DB84D5.3000700@gmail.com>
Message-ID: <20130709074553.GA25885@mudshark.cambridge.arm.com>

On Tue, Jul 09, 2013 at 04:34:45AM +0100, jgq516 at gmail.com wrote:
> On 07/09/2013 09:18 AM, jgq516 at gmail.com wrote:
> > On 07/09/2013 01:03 AM, Will Deacon wrote:
> >> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
> >>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
> >>>> The printascii can output before "b __enable_mmu", after move it to
> >>>> __mmap_switched, nothing can be printed. But if disable LPAE, 
> >>>> printascii
> >>>> works again in __mmap_switched.
> >>> Ok, so the page tables are broken. The code is there to swap the two 
> >>> words,
> >>> but perhaps something ends up being off-by-4 or the like. I'll try 
> >>> and take
> >>> a look.
> >> Right, I managed to have a quick play with a 3.10 kernel and the good 
> >> news
> >> is that the page tables are fine. The bad part is that using
> >> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the 
> >> FDT
> >> results in a NULL command line, so I don't see any output. If I 
> >> hardcode the
> >> command line in the kernel image, things work fine.
> >>
> Hi Will,
> 
> Which kernel tree are you used? I tried latest mainline kernel (used 
> vexpress_defconfig
> and vexpress-v2p-ca15_a7.dtb) without any modification, but it hangs as 
> follows.

Just try 3.10 at the moment -- we're currently in the middle of the merge
window and I know that there is some timer breakage that people have been
talking about.

Will


From will.deacon at arm.com  Tue Jul  9 03:48:37 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Jul 2013 08:48:37 +0100
Subject: [PATCH v2 2/3] iommu: add support for ARM Ltd. System MMU
 architecture
In-Reply-To: <51DAEA0F.2030808@codeaurora.org>
References: <1372095086-15681-1-git-send-email-will.deacon@arm.com>
 <1372095086-15681-3-git-send-email-will.deacon@arm.com>
 <51DAEA0F.2030808@codeaurora.org>
Message-ID: <20130709074837.GB25885@mudshark.cambridge.arm.com>

On Mon, Jul 08, 2013 at 05:34:23PM +0100, Olav Haugan wrote:
> On 6/24/2013 10:31 AM, Will Deacon wrote:
> > This patch adds support for SMMUs implementing the ARM System MMU
> > architecture versions 1 or 2. Both arm and arm64 are supported, although
> > the v7s descriptor format is not used.
> > 
> > Cc: Rob Herring <robherring2 at gmail.com>
> > Cc: Andreas Herrmann <andreas.herrmann at calxeda.com>
> > Cc: Olav Haugan <ohaugan at codeaurora.org>
> > Cc: Joerg Roedel <joro at 8bytes.org>
> > Signed-off-by: Will Deacon <will.deacon at arm.com>
> > ---
> > +/* Maximum number of stream IDs assigned to a single device */
> > +#define MAX_MASTER_STREAMIDS		8
> > +
> 
> Hi Will,

Hi Olav,

> We have designs that require more than 8 Stream IDs. Instead of hard
> coding it to max of 8 can you make this dynamic?

Sure, we can change this if necessary. Care to send a patch? ;)

Will


From wni at nvidia.com  Tue Jul  9 03:48:40 2013
From: wni at nvidia.com (Wei Ni)
Date: Tue, 9 Jul 2013 15:48:40 +0800
Subject: [lm-sensors] [PATCH 1/2] ARM: dt: t30 cardhu: add dt entry for
 lm90
In-Reply-To: <20130709062112.GC17499@mithrandir>
References: <1372928979-26938-1-git-send-email-wni@nvidia.com>
 <1372928979-26938-2-git-send-email-wni@nvidia.com>
 <51D70483.70203@wwwdotorg.org> <51DA6BD4.1040300@nvidia.com>
 <20130708095024.041a6d57@endymion.delvare> <51DA8805.50709@nvidia.com>
 <20130708131421.GB21638@roeck-us.net> <20130709062112.GC17499@mithrandir>
Message-ID: <51DBC058.2040904@nvidia.com>

On 07/09/2013 02:21 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Mon, Jul 08, 2013 at 06:14:21AM -0700, Guenter Roeck wrote:
>> On Mon, Jul 08, 2013 at 05:36:05PM +0800, Wei Ni wrote:
>>> On 07/08/2013 03:50 PM, Jean Delvare wrote:
>>>> On Mon, 8 Jul 2013 15:35:48 +0800, Wei Ni wrote:
>>>>> On 07/06/2013 01:38 AM, Stephen Warren wrote:
>>>>>> On 07/04/2013 03:09 AM, Wei Ni wrote:
>>>>>>> Enable thermal sensor lm90 for t30 cardhu.
>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
>>>>>>
>>>>>>> +		nct1008: nct1008 {
>>>>>>> +			compatible = "lm90,nct1008";
>>>>>>
>>>>>> "lm90" isn't a valid vendor prefix. I believe the value you want is
>>>>>> "onnn,nct1008". Same comment for patch 2/2.
>>>>>
>>>>> The lm90 doesn't support device tree very well.
>>>>
>>>> I doubt it, but if this is the case, then please fix it, instead of
>>>> working the problem around in a different place.
>>>>
>>>>> In the DT, we need to
>>>>> named as "lm90" so that the lm90 driver can be loaded,
>>>>
>>>> Not that I am an expert with regards to DT, but this doesn't make any
>>>> sense to me. AFAIK DT is about devices, not which drivers handle them.
>>>>
>>>>> and we also need
>>>>> to add "nct1008" to indicate this is the nct1008 device, so that the
>>>>> lm90 driver can be loaded with the right i2c_device_id->driver_data.
>>>>>
>>>>> I set the " compatible = "lm90,nct1008" ", this is the simplest way, and
>>>>> we doesn't need to change the lm90.c.
>>>>
>>>> There's no problem with changing the lm90 driver, if this is the right
>>>> thing to do.
>>>
>>> Ok, I will add DT support in the lm90.c in my next version patch.
>>>
>> Only if you can show that it is necessary.
> 
> It should work out of the box. As a matter of fact the same chip is used
> on Tamonten and the DTS files use "onnn,nct1008". That used to work. If
> it no longer does then that's a regression.

I synced the linux-next from:
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
and use the tag v3.10-rc7, but in the lm90.c it doesn't have DT support,
such as "onnn,nct1008".
I googled it and found there has patch:
[PATCH] hwmon: (lm90) Add device tree support , which is in:
http://lists.lm-sensors.org/pipermail/lm-sensors/2013-February/038099.html
, but it didn't be merged into the linux-next.

which git repository and branch should I use ?

Thanks.
Wei.

> 
> Thierry
> 
> * Unknown Key
> * 0x7F3EB3A1
> 



From s.hauer at pengutronix.de  Tue Jul  9 03:51:24 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 9 Jul 2013 09:51:24 +0200
Subject: [PATCH] of: match the compatible in the order set by the dts file
In-Reply-To: <51DBBFDA.70302@freescale.com>
References: <1373013818-11365-1-git-send-email-b32955@freescale.com>
 <20130709070541.GQ516@pengutronix.de>
 <51DBBFDA.70302@freescale.com>
Message-ID: <20130709075124.GR516@pengutronix.de>

On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
> ? 2013?07?09? 15:05, Sascha Hauer ??:
> >Why don't you set the matching order in the driver the way you want it
> >to be, i.e.:
> >
> >	{ .compatible = "fsl,imx6q-uart", ... },
> >	{ .compatible = "fsl,imx21-uart", ... },
> >	{ .compatible = "fsl,imx1-uart", ... },
> >
> yes. i can set it like this.
> 
> but this method looks like a ugly workaround.

If a driver has different ways of supporting a single device, then
putting the preferred or most feature rich on top doesn't look very ugly
to me.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From minggr at gmail.com  Tue Jul  9 03:53:05 2013
From: minggr at gmail.com (Lin Ming)
Date: Tue, 9 Jul 2013 15:53:05 +0800
Subject: kernel decompressor problem for ARMv7
In-Reply-To: <alpine.LFD.2.03.1307090837230.28525@syhkavp.arg>
References: <CAF1ivSakn8-HiAf+4_cLRWUUTDP9QBKpAt+hVQoMyAmKZ2-dJA@mail.gmail.com>
 <20130705095757.GA13063@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1307051225240.18597@syhkavp.arg>
 <CAF1ivSbOXknHyDMH3RdmSGK2n5o2wVeR5oohCQnZ2gJrgvo=Hw@mail.gmail.com>
 <1373250435.824.6.camel@minggr>
 <CAF1ivSbk70UnNc-09C2w-CdgaFBXe_k6K6n8Qr3L-jCLiTGqow@mail.gmail.com>
 <alpine.LFD.2.03.1307090837230.28525@syhkavp.arg>
Message-ID: <CAF1ivSZK8c4zSz5E-=P4032jFJxFrmwHForbCjLTVcJs4xOWkg@mail.gmail.com>

On Tue, Jul 9, 2013 at 3:39 PM, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> On Tue, 9 Jul 2013, Lin Ming wrote:
>
>> On Mon, Jul 8, 2013 at 10:27 AM, Lin Ming <minggr at gmail.com> wrote:
>> > On Sat, 2013-07-06 at 00:58 +0800, Lin Ming wrote:
>> >> On Sat, Jul 6, 2013 at 12:30 AM, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
>> >> > On Fri, 5 Jul 2013, Will Deacon wrote:
>> >> >
>> >> >> On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
>> >> >> > Hi all,
>> >> >>
>> >> >> Hello,
>> >> >>
>> >> >> > I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.
>> >> >>
>> >> >> Which specific processor/SoC?
>> >> >>
>> >> >> > But decompressor doesn't work. With a lot of debug, I finally find
>> >> >> > below 2 commits related.
>> >> >> > Kernel uncompress OK with these commits reverted.
>> >> >> >
>> >> >> > dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
>> >> >> > (Introduced in v3.6-rc6)
>> >> >> >
>> >> >> > 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
>> >> >> > v6 and above
>> >> >> > (Introduced in v3.7-rc8)
>> >> >> >
>> >> >> > Any hint to fix it?
>> >> >>
>> >> >> There's not really enough information to go on here. What specifically
>> >> >> fails? Also, do you have to revert *both* of the above changes to get things
>> >> >> working again?
>> >> >
>> >> > Also, what is the bootloader used here?
>> >>
>> >> uboot.
>> >>
>> >> >
>> >> > Does the bootloader call the kernel with the MMU off as documented in
>> >> > Documentation/arm/Booting?
>> >>
>> >> How to check this?
>> >>
>> >> I'll check uboot code or add debug code in boot/compressed/head.S to
>> >> check it next Monday.
>> >
>> > I added below debug code to print the control reg from lowest 4bits to
>> > highest 4bits.
>> >
>> > It prints "B7805C". So the control reg is 0x00c5087b.
>> > Seems bootloader calls the kernel with MMU enabled and Alignment fault
>> > checking enabled.
>>
>> Hi Nicolas,
>>
>> Is this information useful?
>> Or any other information needed for further debug?
>
> No more info needed.  The kernel has to be booted with the MMU disabled
> as per the booting protocol documentation. You therefore have to fix
> your
> bootloader.

OK.

But I have to also revert below commit to make decompressor work.

commit 5010192:
ARM: 7583/1: decompressor: Enable unaligned memory access for v6 and above

It seems like caused by bootloader has Alignment fault checking enabled.
Any suggestion how to fix it?

Thanks.

>
>
> Nicolas


From khali at linux-fr.org  Tue Jul  9 03:55:25 2013
From: khali at linux-fr.org (Jean Delvare)
Date: Tue, 9 Jul 2013 09:55:25 +0200
Subject: [lm-sensors] [PATCH 1/2] ARM: dt: t30 cardhu: add dt entry for
 lm90
In-Reply-To: <51DBC058.2040904@nvidia.com>
References: <1372928979-26938-1-git-send-email-wni@nvidia.com>
 <1372928979-26938-2-git-send-email-wni@nvidia.com>
 <51D70483.70203@wwwdotorg.org> <51DA6BD4.1040300@nvidia.com>
 <20130708095024.041a6d57@endymion.delvare>
 <51DA8805.50709@nvidia.com> <20130708131421.GB21638@roeck-us.net>
 <20130709062112.GC17499@mithrandir> <51DBC058.2040904@nvidia.com>
Message-ID: <20130709095525.5158a0a5@endymion.delvare>

On Tue, 9 Jul 2013 15:48:40 +0800, Wei Ni wrote:
> On 07/09/2013 02:21 PM, Thierry Reding wrote:
> > It should work out of the box. As a matter of fact the same chip is used
> > on Tamonten and the DTS files use "onnn,nct1008". That used to work. If
> > it no longer does then that's a regression.
> 
> I synced the linux-next from:
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> and use the tag v3.10-rc7, but in the lm90.c it doesn't have DT support,
> such as "onnn,nct1008".
> I googled it and found there has patch:
> [PATCH] hwmon: (lm90) Add device tree support , which is in:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2013-February/038099.html
> , but it didn't be merged into the linux-next.

It was not, because of the next reply in the same thread:
http://lists.lm-sensors.org/pipermail/lm-sensors/2013-February/038100.html

> which git repository and branch should I use ?

It is supposed to just work. What doesn't work for you exactly?

-- 
Jean Delvare


From arnd at arndb.de  Tue Jul  9 03:56:02 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Jul 2013 09:56:02 +0200
Subject: [PATCH v1 0/4] ARM: STi fixes and ethernet support
In-Reply-To: <51DBB629.1050000@st.com>
References: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
 <201307090118.06715.arnd@arndb.de> <51DBB629.1050000@st.com>
Message-ID: <201307090956.03191.arnd@arndb.de>

On Tuesday 09 July 2013, Srinivas KANDAGATLA wrote:
> stmmac (aka "dwmac" a synopsis IP) driver is integrated in to kernel
> sometime in 2.6 series I think :-), and Is used by more than 4 platforms
> in 3.10 kernel. The driver is more generic than it sounds.
> So adding properties/hooks specific to STiH41x SOCs in driver seemed to
> incorrect. Instead doing platform specific bits in the mach via
> callbacks was the only choice I had.

No, you should be using generic interfaces to do the things you need.

I believe what you are missing is an ethernet phy driver that is specific
to your SoC.

	Arnd


From elen.song at atmel.com  Tue Jul  9 03:57:02 2013
From: elen.song at atmel.com (elen.song)
Date: Tue, 9 Jul 2013 15:57:02 +0800
Subject: [PATCH 1/7] serial: at91: correct definition from DMA to PDC
In-Reply-To: <20130709073155.GB4013@ludovic.desroches@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
 <1373351626-30143-2-git-send-email-elen.song@atmel.com>
 <20130709073155.GB4013@ludovic.desroches@atmel.com>
Message-ID: <51DBC24E.9060601@atmel.com>

On 7/9/2013 3:31 PM, Ludovic Desroches wrote:
> Hi Elen,
>
> One comment below:
>
> On Tue, Jul 09, 2013 at 02:33:40PM +0800, Elen Song wrote:
>
> [...]
>
>> diff --git a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
>> index a49d9a1..82f45ec 100644
>> --- a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
>> +++ b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
>> @@ -8,8 +8,8 @@ Required properties:
>>   - interrupts: Should contain interrupt
>>   
>>   Optional properties:
>> -- atmel,use-dma-rx: use of PDC or DMA for receiving data
>> -- atmel,use-dma-tx: use of PDC or DMA for transmitting data
>> +- atmel,use-pdc-rx: use of PDC for receiving data
>> +- atmel,use-pdc-tx: use of PDC for transmitting data
>>   
>>   <chip> compatible description:
>>   - at91rm9200:  legacy USART support
>> @@ -19,9 +19,9 @@ Example:
>>   
>>   	usart0: serial at fff8c000 {
>>   		compatible = "atmel,at91sam9260-usart";
>> -		reg = <0xfff8c000 0x4000>;
>> -		interrupts = <7>;
>> -		atmel,use-dma-rx;
>> -		atmel,use-dma-tx;
>> +		reg = <0xfff8c000 0x200>;
>> +		interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
> Maybe put these changes into an other patch since it is not in relation with
> the purpose of your patch.
>
> Moreover, I am not sure that macros should be used in the documentation. From
> the top of my head, there was a discussion about that and the status was to not
> use macros in documentation since it is Linux dependant.

Ok, I will not involve the macros in the document now.
So I will move all the document changes into the last patch, right?
>
>> +		atmel,use-pdc-rx;
>> +		atmel,use-pdc-tx;
>>   	};
>>   
> [...]



From jg1.han at samsung.com  Tue Jul  9 04:03:35 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Tue, 09 Jul 2013 17:03:35 +0900
Subject: [PATCH V6 0/4] Generic PHY driver for the Exynos SoC DP PHY
Message-ID: <003d01ce7c7a$d04043d0$70c0cb70$@samsung.com>

This patch series adds a simple driver for the Samsung Exynos SoC
series DP transmitter PHY, using the generic PHY framework [1].
Previously the DP PHY used an internal DT node to control the PHY
power enable bit.

These patches was tested on Exynos5250.

This PATCH v6 follows:
 * PATCH v5, sent on July, 8th 2013
 * PATCH v4, sent on July, 2nd 2013
 * PATCH v3, sent on July, 1st 2013
 * PATCH v2, sent on June, 28th 2013
 * PATCH v1, sent on June, 28th 2013

Changes between v5 and v6:
  * Re-based on git://gitorious.org/linuxphy/linuxphy.git

Changes between v4 and v5:
  * Marked original bindings as deprecated in 'exynos_dp.txt'
  * Fixed typo of commit message.
  * Added Tomasz Figa's Reviewed-by.

Changes between v3 and v4:
  * Added OF dependancy.
  * Removed redundant local variable 'void __iomem *addr'.
  * Removed unnecessary dev_set_drvdata().
  * Added a patch that remove non-DT support for Exynos
    Display Port driver.
  * Removed unnecessary 'struct exynos_dp_platdata'.
  * Kept supporting the original bindings for DT compatibility.

Changes between v2 and v3:
  * Removed redundant spinlock
  * Removed 'struct phy' from 'struct exynos_dp_video_phy'
  * Updated 'samsung-phy.txt', instead of creating
    'samsung,exynos5250-dp-video-phy.txt'.
  * Removed unnecessary additional specifier from 'phys'
    DT property.
  * Added 'phys', 'phy-names' properties to 'exynos_dp.txt' file.
  * Added Felipe Balbi's Acked-by.

Changes between v1 and v2:
  * Replaced exynos_dp_video_phy_xlate() with of_phy_simple_xlate(),
    as Kishon Vijay Abraham I guided.
  * Set the value of phy-cells as 0, because the phy_provider implements
    only one PHY.
  * Removed unnecessary header include.
  * Added '#ifdef CONFIG_OF' and of_match_ptr macro.

This series depends on the generic PHY framework [1]. These patches
refer to Sylwester Nawrocki's patches about Exynos MIPI [2].

[1] https://lkml.org/lkml/2013/6/26/259
[2] http://www.spinics.net/lists/linux-samsung-soc/msg20098.html

Jingoo Han (4):
  ARM: dts: Add DP PHY node to exynos5250.dtsi
  phy: Add driver for Exynos DP PHY
  video: exynos_dp: remove non-DT support for Exynos Display Port
  video: exynos_dp: Use the generic PHY driver

 .../devicetree/bindings/phy/samsung-phy.txt        |    8 ++
 .../devicetree/bindings/video/exynos_dp.txt        |   18 +++++++++---------
 arch/arm/boot/dts/exynos5250.dtsi                  |   13 ++++++++-----
 drivers/phy/Kconfig                                |    6 ++
 drivers/phy/Makefile                               |    1 +
 drivers/phy/phy-exynos-dp-video.c                  |  111 ++++++++++++++++++++
 drivers/video/exynos/Kconfig                       |    2 +-
 drivers/video/exynos/exynos_dp_core.c              |  132 +++++++----------------------
 drivers/video/exynos/exynos_dp_core.h              |  110 +++++++++++++++++++++++++++
 drivers/video/exynos/exynos_dp_reg.c               |    2 -
 include/video/exynos_dp.h                          |  131 ---------------------------------
 11 files changed, 291 insertions(+), 243 deletions(-) 
 create mode 100644 drivers/phy/phy-exynos-dp-video.c
 delete mode 100644 include/video/exynos_dp.h

--
1.7.10.4



From will.deacon at arm.com  Tue Jul  9 04:03:54 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Jul 2013 09:03:54 +0100
Subject: ARM Cortex A9: User/Kernel filter events
In-Reply-To: <BFCB49997E59134AAAF17FFE77F8FF0667378D28@REXMD.intranet.epfl.ch>
References: <BFCB49997E59134AAAF17FFE77F8FF0667378D28@REXMD.intranet.epfl.ch>
Message-ID: <20130709080354.GA26169@mudshark.cambridge.arm.com>

On Mon, Jul 08, 2013 at 09:58:17PM +0100, Javier Picorel wrote:
> Dear all,
> 
> Is there any reason why ARM Cortex A9 cannot filter user/kernel events?
> 
> arch/arm/kernel/perf_event_v7.c
> 
> 1144/*
> 1145 * Add an event filter to a given event. This will only work for PMUv2 PMUs.
> 1146 */
> 1147static int armv7pmu_set_event_filter(struct hw_perf_event *event,
> 1148                                     struct perf_event_attr *attr)
> 1149{
> 1150        unsigned long config_base = 0;
> 1151
> 1152        if (attr->exclude_idle)
> 1153                return -EPERM;
> 1154        if (attr->exclude_user)
> 1155                config_base |= ARMV7_EXCLUDE_USER;
> 1156        if (attr->exclude_kernel)
> 1157                config_base |= ARMV7_EXCLUDE_PL1;
> 1158        if (!attr->exclude_hv)
> 1159                config_base |= ARMV7_INCLUDE_HYP;
> 1160
> 1161        /*
> 1162         * Install the filter into config_base as this is used to
> 1163         * construct the event type.
> 1164         */
> 1165        event->config_base = config_base;
> 1166
> 1167        return 0;
> 1168}
> 
> It seems that only A15 and A7 are able to do it. Is it a limitation A9's PMU? Thank you!

Event filtering requires hardware support in the PMU, as described in the
comment above ("This will only work for PMUv2 PMUs"). A9 doesn't support
this feature.

One interesting thing would be to see if we can plumb into the new
context-tracking stuff from Kevin, which does keep track of transitions
between user and kernel space. That would allow a `poor man's' event
filtering for hardware that doesn't support it.

Will


From jg1.han at samsung.com  Tue Jul  9 04:04:10 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Tue, 09 Jul 2013 17:04:10 +0900
Subject: [PATCH V6 1/4] ARM: dts: Add DP PHY node to exynos5250.dtsi
Message-ID: <003e01ce7c7a$e519a300$af4ce900$@samsung.com>

Add PHY provider node for the DP PHY.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/boot/dts/exynos5250.dtsi |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index fc9fb3d..c326c06 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -616,6 +616,12 @@
 		interrupts = <0 94 0>;
 	};
 
+	dp_phy: video-phy at 10040720 {
+		compatible = "samsung,exynos5250-dp-video-phy";
+		reg = <0x10040720 4>;
+		#phy-cells = <0>;
+	};
+
 	dp-controller {
 		compatible = "samsung,exynos5-dp";
 		reg = <0x145b0000 0x1000>;
@@ -623,11 +629,8 @@
 		interrupt-parent = <&combiner>;
 		#address-cells = <1>;
 		#size-cells = <0>;
-
-		dptx-phy {
-			reg = <0x10040720>;
-			samsung,enable-mask = <1>;
-		};
+		phys = <&dp_phy>;
+		phy-names = "dp";
 	};
 
 	fimd {
-- 
1.7.10.4




From jg1.han at samsung.com  Tue Jul  9 04:04:40 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Tue, 09 Jul 2013 17:04:40 +0900
Subject: [PATCH V6 2/4] phy: Add driver for Exynos DP PHY
Message-ID: <003f01ce7c7a$f6ef5f20$e4ce1d60$@samsung.com>

Add a PHY provider driver for the Samsung Exynos SoC Display Port PHY.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 .../devicetree/bindings/phy/samsung-phy.txt        |    8 ++
 drivers/phy/Kconfig                                |    6 ++
 drivers/phy/Makefile                               |    1 +
 drivers/phy/phy-exynos-dp-video.c                  |  111 ++++++++++++++++++++
 4 files changed, 126 insertions(+)
 create mode 100644 drivers/phy/phy-exynos-dp-video.c

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 5ff208c..c0fccaa 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -12,3 +12,11 @@ the PHY specifier identifies the PHY and its meaning is as follows:
   1 - MIPI DSIM 0,
   2 - MIPI CSIS 1,
   3 - MIPI DSIM 1.
+
+Samsung EXYNOS SoC series Display Port PHY
+-------------------------------------------------
+
+Required properties:
+- compatible : should be "samsung,exynos5250-dp-video-phy";
+- reg : offset and length of the Display Port PHY register set;
+- #phy-cells : from the generic PHY bindings, must be 0;
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 6f446d0..ed0b1b8 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -19,4 +19,10 @@ config PHY_EXYNOS_MIPI_VIDEO
 	help
 	  Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
 	  S5P and EXYNOS SoCs.
+
+config PHY_EXYNOS_DP_VIDEO
+	tristate "EXYNOS SoC series Display Port PHY driver"
+	depends on OF
+	help
+	  Support for Display Port PHY found on Samsung EXYNOS SoCs.
 endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 71d8841..0fd1340 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_GENERIC_PHY)		+= phy-core.o
 obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)	+= phy-exynos-mipi-video.o
+obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)	+= phy-exynos-dp-video.o
diff --git a/drivers/phy/phy-exynos-dp-video.c b/drivers/phy/phy-exynos-dp-video.c
new file mode 100644
index 0000000..3c8e247
--- /dev/null
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -0,0 +1,111 @@
+/*
+ * Samsung EXYNOS SoC series Display Port PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Jingoo Han <jg1.han at samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+
+/* DPTX_PHY_CONTROL register */
+#define EXYNOS_DPTX_PHY_ENABLE		(1 << 0)
+
+struct exynos_dp_video_phy {
+	void __iomem *regs;
+};
+
+static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int on)
+{
+	u32 reg;
+
+	reg = readl(state->regs);
+	if (on)
+		reg |= EXYNOS_DPTX_PHY_ENABLE;
+	else
+		reg &= ~EXYNOS_DPTX_PHY_ENABLE;
+	writel(reg, state->regs);
+
+	return 0;
+}
+
+static int exynos_dp_video_phy_power_on(struct phy *phy)
+{
+	struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+	return __set_phy_state(state, 1);
+}
+
+static int exynos_dp_video_phy_power_off(struct phy *phy)
+{
+	struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+	return __set_phy_state(state, 0);
+}
+
+static struct phy_ops exynos_dp_video_phy_ops = {
+	.power_on	= exynos_dp_video_phy_power_on,
+	.power_off	= exynos_dp_video_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
+static int exynos_dp_video_phy_probe(struct platform_device *pdev)
+{
+	struct exynos_dp_video_phy *state;
+	struct device *dev = &pdev->dev;
+	struct resource *res;
+	struct phy_provider *phy_provider;
+	struct phy *phy;
+
+	state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
+	if (!state)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+	state->regs = devm_ioremap_resource(dev, res);
+	if (IS_ERR(state->regs))
+		return PTR_ERR(state->regs);
+
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	phy = devm_phy_create(dev, 0, &exynos_dp_video_phy_ops, NULL);
+	if (IS_ERR(phy)) {
+		dev_err(dev, "failed to create Display Port PHY\n");
+		return PTR_ERR(phy);
+	}
+	phy_set_drvdata(phy, state);
+
+	return 0;
+}
+
+static const struct of_device_id exynos_dp_video_phy_of_match[] = {
+	{ .compatible = "samsung,exynos5250-dp-video-phy" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, exynos_dp_video_phy_of_match);
+
+static struct platform_driver exynos_dp_video_phy_driver = {
+	.probe	= exynos_dp_video_phy_probe,
+	.driver = {
+		.name	= "exynos-dp-video-phy",
+		.owner	= THIS_MODULE,
+		.of_match_table	= exynos_dp_video_phy_of_match,
+	}
+};
+module_platform_driver(exynos_dp_video_phy_driver);
+
+MODULE_AUTHOR("Jingoo Han <jg1.han at samsung.com>");
+MODULE_DESCRIPTION("Samsung EXYNOS SoC DP PHY driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.10.4




From jg1.han at samsung.com  Tue Jul  9 04:05:12 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Tue, 09 Jul 2013 17:05:12 +0900
Subject: [PATCH V6 3/4] video: exynos_dp: remove non-DT support for Exynos
 Display Port
Message-ID: <004001ce7c7b$09b87bf0$1d2973d0$@samsung.com>

Exynos Display Port can be used only for Exynos SoCs. In addition,
non-DT for EXYNOS SoCs is not supported from v3.11; thus, there is
no need to support non-DT for Exynos Display Port.

The 'include/video/exynos_dp.h' file has been used for non-DT
support and the content of file include/video/exynos_dp.h is moved
to drivers/video/exynos/exynos_dp_core.h. Thus, the 'exynos_dp.h'
file is removed. Also, 'struct exynos_dp_platdata' is removed,
because it is not used any more.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---
 drivers/video/exynos/Kconfig          |    2 +-
 drivers/video/exynos/exynos_dp_core.c |  116 +++++++----------------------
 drivers/video/exynos/exynos_dp_core.h |  109 +++++++++++++++++++++++++++
 drivers/video/exynos/exynos_dp_reg.c  |    2 -
 include/video/exynos_dp.h             |  131 ---------------------------------
 5 files changed, 135 insertions(+), 225 deletions(-)
 delete mode 100644 include/video/exynos_dp.h

diff --git a/drivers/video/exynos/Kconfig b/drivers/video/exynos/Kconfig
index 1b035b2..fab9019 100644
--- a/drivers/video/exynos/Kconfig
+++ b/drivers/video/exynos/Kconfig
@@ -29,7 +29,7 @@ config EXYNOS_LCD_S6E8AX0
 
 config EXYNOS_DP
 	bool "EXYNOS DP driver support"
-	depends on ARCH_EXYNOS
+	depends on OF && ARCH_EXYNOS
 	default n
 	help
 	  This enables support for DP device.
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index 12bbede..05fed7d 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -20,8 +20,6 @@
 #include <linux/delay.h>
 #include <linux/of.h>
 
-#include <video/exynos_dp.h>
-
 #include "exynos_dp_core.h"
 
 static int exynos_dp_init_dp(struct exynos_dp_device *dp)
@@ -894,26 +892,17 @@ static void exynos_dp_hotplug(struct work_struct *work)
 		dev_err(dp->dev, "unable to config video\n");
 }
 
-#ifdef CONFIG_OF
-static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
+static struct video_info *exynos_dp_dt_parse_pdata(struct device *dev)
 {
 	struct device_node *dp_node = dev->of_node;
-	struct exynos_dp_platdata *pd;
 	struct video_info *dp_video_config;
 
-	pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
-	if (!pd) {
-		dev_err(dev, "memory allocation for pdata failed\n");
-		return ERR_PTR(-ENOMEM);
-	}
 	dp_video_config = devm_kzalloc(dev,
 				sizeof(*dp_video_config), GFP_KERNEL);
-
 	if (!dp_video_config) {
 		dev_err(dev, "memory allocation for video config failed\n");
 		return ERR_PTR(-ENOMEM);
 	}
-	pd->video_info = dp_video_config;
 
 	dp_video_config->h_sync_polarity =
 		of_property_read_bool(dp_node, "hsync-active-high");
@@ -960,7 +949,7 @@ static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
 		return ERR_PTR(-EINVAL);
 	}
 
-	return pd;
+	return dp_video_config;
 }
 
 static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
@@ -1003,48 +992,30 @@ err:
 
 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 {
-	u32 reg;
+	if (dp->phy_addr) {
+		u32 reg;
 
-	reg = __raw_readl(dp->phy_addr);
-	reg |= dp->enable_mask;
-	__raw_writel(reg, dp->phy_addr);
+		reg = __raw_readl(dp->phy_addr);
+		reg |= dp->enable_mask;
+		__raw_writel(reg, dp->phy_addr);
+	}
 }
 
 static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
 {
-	u32 reg;
-
-	reg = __raw_readl(dp->phy_addr);
-	reg &= ~(dp->enable_mask);
-	__raw_writel(reg, dp->phy_addr);
-}
-#else
-static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
-{
-	return NULL;
-}
-
-static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
-{
-	return -EINVAL;
-}
-
-static void exynos_dp_phy_init(struct exynos_dp_device *dp)
-{
-	return;
-}
+	if (dp->phy_addr) {
+		u32 reg;
 
-static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
-{
-	return;
+		reg = __raw_readl(dp->phy_addr);
+		reg &= ~(dp->enable_mask);
+		__raw_writel(reg, dp->phy_addr);
+	}
 }
-#endif /* CONFIG_OF */
 
 static int exynos_dp_probe(struct platform_device *pdev)
 {
 	struct resource *res;
 	struct exynos_dp_device *dp;
-	struct exynos_dp_platdata *pdata;
 
 	int ret = 0;
 
@@ -1057,21 +1028,13 @@ static int exynos_dp_probe(struct platform_device *pdev)
 
 	dp->dev = &pdev->dev;
 
-	if (pdev->dev.of_node) {
-		pdata = exynos_dp_dt_parse_pdata(&pdev->dev);
-		if (IS_ERR(pdata))
-			return PTR_ERR(pdata);
+	dp->video_info = exynos_dp_dt_parse_pdata(&pdev->dev);
+	if (IS_ERR(dp->video_info))
+		return PTR_ERR(dp->video_info);
 
-		ret = exynos_dp_dt_parse_phydata(dp);
-		if (ret)
-			return ret;
-	} else {
-		pdata = pdev->dev.platform_data;
-		if (!pdata) {
-			dev_err(&pdev->dev, "no platform data\n");
-			return -EINVAL;
-		}
-	}
+	ret = exynos_dp_dt_parse_phydata(dp);
+	if (ret)
+		return ret;
 
 	dp->clock = devm_clk_get(&pdev->dev, "dp");
 	if (IS_ERR(dp->clock)) {
@@ -1095,15 +1058,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
 
 	INIT_WORK(&dp->hotplug_work, exynos_dp_hotplug);
 
-	dp->video_info = pdata->video_info;
-
-	if (pdev->dev.of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_init(dp);
-	} else {
-		if (pdata->phy_init)
-			pdata->phy_init();
-	}
+	exynos_dp_phy_init(dp);
 
 	exynos_dp_init_dp(dp);
 
@@ -1121,18 +1076,11 @@ static int exynos_dp_probe(struct platform_device *pdev)
 
 static int exynos_dp_remove(struct platform_device *pdev)
 {
-	struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
 	struct exynos_dp_device *dp = platform_get_drvdata(pdev);
 
 	flush_work(&dp->hotplug_work);
 
-	if (pdev->dev.of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_exit(dp);
-	} else {
-		if (pdata->phy_exit)
-			pdata->phy_exit();
-	}
+	exynos_dp_phy_exit(dp);
 
 	clk_disable_unprepare(dp->clock);
 
@@ -1143,20 +1091,13 @@ static int exynos_dp_remove(struct platform_device *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int exynos_dp_suspend(struct device *dev)
 {
-	struct exynos_dp_platdata *pdata = dev->platform_data;
 	struct exynos_dp_device *dp = dev_get_drvdata(dev);
 
 	disable_irq(dp->irq);
 
 	flush_work(&dp->hotplug_work);
 
-	if (dev->of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_exit(dp);
-	} else {
-		if (pdata->phy_exit)
-			pdata->phy_exit();
-	}
+	exynos_dp_phy_exit(dp);
 
 	clk_disable_unprepare(dp->clock);
 
@@ -1165,16 +1106,9 @@ static int exynos_dp_suspend(struct device *dev)
 
 static int exynos_dp_resume(struct device *dev)
 {
-	struct exynos_dp_platdata *pdata = dev->platform_data;
 	struct exynos_dp_device *dp = dev_get_drvdata(dev);
 
-	if (dev->of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_init(dp);
-	} else {
-		if (pdata->phy_init)
-			pdata->phy_init();
-	}
+	exynos_dp_phy_init(dp);
 
 	clk_prepare_enable(dp->clock);
 
@@ -1203,7 +1137,7 @@ static struct platform_driver exynos_dp_driver = {
 		.name	= "exynos-dp",
 		.owner	= THIS_MODULE,
 		.pm	= &exynos_dp_pm_ops,
-		.of_match_table = of_match_ptr(exynos_dp_match),
+		.of_match_table = exynos_dp_match,
 	},
 };
 
diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
index 6c567bbf..56cfec8 100644
--- a/drivers/video/exynos/exynos_dp_core.h
+++ b/drivers/video/exynos/exynos_dp_core.h
@@ -13,6 +13,99 @@
 #ifndef _EXYNOS_DP_CORE_H
 #define _EXYNOS_DP_CORE_H
 
+#define DP_TIMEOUT_LOOP_COUNT 100
+#define MAX_CR_LOOP 5
+#define MAX_EQ_LOOP 5
+
+enum link_rate_type {
+	LINK_RATE_1_62GBPS = 0x06,
+	LINK_RATE_2_70GBPS = 0x0a
+};
+
+enum link_lane_count_type {
+	LANE_COUNT1 = 1,
+	LANE_COUNT2 = 2,
+	LANE_COUNT4 = 4
+};
+
+enum link_training_state {
+	START,
+	CLOCK_RECOVERY,
+	EQUALIZER_TRAINING,
+	FINISHED,
+	FAILED
+};
+
+enum voltage_swing_level {
+	VOLTAGE_LEVEL_0,
+	VOLTAGE_LEVEL_1,
+	VOLTAGE_LEVEL_2,
+	VOLTAGE_LEVEL_3,
+};
+
+enum pre_emphasis_level {
+	PRE_EMPHASIS_LEVEL_0,
+	PRE_EMPHASIS_LEVEL_1,
+	PRE_EMPHASIS_LEVEL_2,
+	PRE_EMPHASIS_LEVEL_3,
+};
+
+enum pattern_set {
+	PRBS7,
+	D10_2,
+	TRAINING_PTN1,
+	TRAINING_PTN2,
+	DP_NONE
+};
+
+enum color_space {
+	COLOR_RGB,
+	COLOR_YCBCR422,
+	COLOR_YCBCR444
+};
+
+enum color_depth {
+	COLOR_6,
+	COLOR_8,
+	COLOR_10,
+	COLOR_12
+};
+
+enum color_coefficient {
+	COLOR_YCBCR601,
+	COLOR_YCBCR709
+};
+
+enum dynamic_range {
+	VESA,
+	CEA
+};
+
+enum pll_status {
+	PLL_UNLOCKED,
+	PLL_LOCKED
+};
+
+enum clock_recovery_m_value_type {
+	CALCULATED_M,
+	REGISTER_M
+};
+
+enum video_timing_recognition_type {
+	VIDEO_TIMING_FROM_CAPTURE,
+	VIDEO_TIMING_FROM_REGISTER
+};
+
+enum analog_power_block {
+	AUX_BLOCK,
+	CH0_BLOCK,
+	CH1_BLOCK,
+	CH2_BLOCK,
+	CH3_BLOCK,
+	ANALOG_TOTAL,
+	POWER_ALL
+};
+
 enum dp_irq_type {
 	DP_IRQ_TYPE_HP_CABLE_IN,
 	DP_IRQ_TYPE_HP_CABLE_OUT,
@@ -20,6 +113,22 @@ enum dp_irq_type {
 	DP_IRQ_TYPE_UNKNOWN,
 };
 
+struct video_info {
+	char *name;
+
+	bool h_sync_polarity;
+	bool v_sync_polarity;
+	bool interlaced;
+
+	enum color_space color_space;
+	enum dynamic_range dynamic_range;
+	enum color_coefficient ycbcr_coeff;
+	enum color_depth color_depth;
+
+	enum link_rate_type link_rate;
+	enum link_lane_count_type lane_count;
+};
+
 struct link_train {
 	int eq_loop;
 	int cr_loop[4];
diff --git a/drivers/video/exynos/exynos_dp_reg.c b/drivers/video/exynos/exynos_dp_reg.c
index 29d9d03..b70da50 100644
--- a/drivers/video/exynos/exynos_dp_reg.c
+++ b/drivers/video/exynos/exynos_dp_reg.c
@@ -14,8 +14,6 @@
 #include <linux/io.h>
 #include <linux/delay.h>
 
-#include <video/exynos_dp.h>
-
 #include "exynos_dp_core.h"
 #include "exynos_dp_reg.h"
 
diff --git a/include/video/exynos_dp.h b/include/video/exynos_dp.h
deleted file mode 100644
index bd8cabd..0000000
--- a/include/video/exynos_dp.h
+++ /dev/null
@@ -1,131 +0,0 @@
-/*
- * Samsung SoC DP device support
- *
- * Copyright (C) 2012 Samsung Electronics Co., Ltd.
- * Author: Jingoo Han <jg1.han at samsung.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef _EXYNOS_DP_H
-#define _EXYNOS_DP_H
-
-#define DP_TIMEOUT_LOOP_COUNT 100
-#define MAX_CR_LOOP 5
-#define MAX_EQ_LOOP 5
-
-enum link_rate_type {
-	LINK_RATE_1_62GBPS = 0x06,
-	LINK_RATE_2_70GBPS = 0x0a
-};
-
-enum link_lane_count_type {
-	LANE_COUNT1 = 1,
-	LANE_COUNT2 = 2,
-	LANE_COUNT4 = 4
-};
-
-enum link_training_state {
-	START,
-	CLOCK_RECOVERY,
-	EQUALIZER_TRAINING,
-	FINISHED,
-	FAILED
-};
-
-enum voltage_swing_level {
-	VOLTAGE_LEVEL_0,
-	VOLTAGE_LEVEL_1,
-	VOLTAGE_LEVEL_2,
-	VOLTAGE_LEVEL_3,
-};
-
-enum pre_emphasis_level {
-	PRE_EMPHASIS_LEVEL_0,
-	PRE_EMPHASIS_LEVEL_1,
-	PRE_EMPHASIS_LEVEL_2,
-	PRE_EMPHASIS_LEVEL_3,
-};
-
-enum pattern_set {
-	PRBS7,
-	D10_2,
-	TRAINING_PTN1,
-	TRAINING_PTN2,
-	DP_NONE
-};
-
-enum color_space {
-	COLOR_RGB,
-	COLOR_YCBCR422,
-	COLOR_YCBCR444
-};
-
-enum color_depth {
-	COLOR_6,
-	COLOR_8,
-	COLOR_10,
-	COLOR_12
-};
-
-enum color_coefficient {
-	COLOR_YCBCR601,
-	COLOR_YCBCR709
-};
-
-enum dynamic_range {
-	VESA,
-	CEA
-};
-
-enum pll_status {
-	PLL_UNLOCKED,
-	PLL_LOCKED
-};
-
-enum clock_recovery_m_value_type {
-	CALCULATED_M,
-	REGISTER_M
-};
-
-enum video_timing_recognition_type {
-	VIDEO_TIMING_FROM_CAPTURE,
-	VIDEO_TIMING_FROM_REGISTER
-};
-
-enum analog_power_block {
-	AUX_BLOCK,
-	CH0_BLOCK,
-	CH1_BLOCK,
-	CH2_BLOCK,
-	CH3_BLOCK,
-	ANALOG_TOTAL,
-	POWER_ALL
-};
-
-struct video_info {
-	char *name;
-
-	bool h_sync_polarity;
-	bool v_sync_polarity;
-	bool interlaced;
-
-	enum color_space color_space;
-	enum dynamic_range dynamic_range;
-	enum color_coefficient ycbcr_coeff;
-	enum color_depth color_depth;
-
-	enum link_rate_type link_rate;
-	enum link_lane_count_type lane_count;
-};
-
-struct exynos_dp_platdata {
-	struct video_info *video_info;
-
-	void (*phy_init)(void);
-	void (*phy_exit)(void);
-};
-
-#endif /* _EXYNOS_DP_H */
-- 
1.7.10.4




From will.deacon at arm.com  Tue Jul  9 04:05:24 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Jul 2013 09:05:24 +0100
Subject: kernel decompressor problem for ARMv7
In-Reply-To: <CAF1ivSZK8c4zSz5E-=P4032jFJxFrmwHForbCjLTVcJs4xOWkg@mail.gmail.com>
References: <CAF1ivSakn8-HiAf+4_cLRWUUTDP9QBKpAt+hVQoMyAmKZ2-dJA@mail.gmail.com>
 <20130705095757.GA13063@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1307051225240.18597@syhkavp.arg>
 <CAF1ivSbOXknHyDMH3RdmSGK2n5o2wVeR5oohCQnZ2gJrgvo=Hw@mail.gmail.com>
 <1373250435.824.6.camel@minggr>
 <CAF1ivSbk70UnNc-09C2w-CdgaFBXe_k6K6n8Qr3L-jCLiTGqow@mail.gmail.com>
 <alpine.LFD.2.03.1307090837230.28525@syhkavp.arg>
 <CAF1ivSZK8c4zSz5E-=P4032jFJxFrmwHForbCjLTVcJs4xOWkg@mail.gmail.com>
Message-ID: <20130709080524.GB26169@mudshark.cambridge.arm.com>

On Tue, Jul 09, 2013 at 08:53:05AM +0100, Lin Ming wrote:
> On Tue, Jul 9, 2013 at 3:39 PM, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> > No more info needed.  The kernel has to be booted with the MMU disabled
> > as per the booting protocol documentation. You therefore have to fix
> > your
> > bootloader.
> 
> OK.
> 
> But I have to also revert below commit to make decompressor work.
> 
> commit 5010192:
> ARM: 7583/1: decompressor: Enable unaligned memory access for v6 and above
> 
> It seems like caused by bootloader has Alignment fault checking enabled.
> Any suggestion how to fix it?

Well step 1 is to disable the MMU. Once you've done that, you really don't
want to be issuing unaligned accesses (since memory will be treated as
strongly-ordered), so the value of the alignment trap bit is irrelevant.

Will


From jg1.han at samsung.com  Tue Jul  9 04:05:48 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Tue, 09 Jul 2013 17:05:48 +0900
Subject: [PATCH V6 4/4] video: exynos_dp: Use the generic PHY driver
Message-ID: <004101ce7c7b$1f306510$5d912f30$@samsung.com>

Use the generic PHY API to control the DP PHY.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---
 .../devicetree/bindings/video/exynos_dp.txt          |   18 +++++++++---------
 drivers/video/exynos/exynos_dp_core.c                |   16 ++++++++++++----
 drivers/video/exynos/exynos_dp_core.h                |    1 +
 3 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
index c60da67..e2874ae 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -6,10 +6,10 @@ We use two nodes:
 	-dptx-phy node(defined inside dp-controller node)
 
 For the DP-PHY initialization, we use the dptx-phy node.
-Required properties for dptx-phy:
-	-reg:
+Required properties for dptx-phy: deprecated, use phys and phy-names
+	-reg: deprecated
 		Base address of DP PHY register.
-	-samsung,enable-mask:
+	-samsung,enable-mask: deprecated
 		The bit-mask used to enable/disable DP PHY.
 
 For the Panel initialization, we read data from dp-controller node.
@@ -21,6 +21,10 @@ Required properties for dp-controller:
 		of memory mapped region.
 	-interrupts:
 		interrupt combiner values.
+	-phys:
+		from general PHY binding: the phandle for the PHY device.
+	-phy-names:
+		from general PHY binding: Should be "dp".
 	-interrupt-parent:
 		phandle to Interrupt combiner node.
 	-samsung,color-space:
@@ -61,12 +65,8 @@ SOC specific portion:
 		reg = <0x145b0000 0x10000>;
 		interrupts = <10 3>;
 		interrupt-parent = <&combiner>;
-
-		dptx-phy {
-			reg = <0x10040720>;
-			samsung,enable-mask = <1>;
-		};
-
+		phys = <&dp_phy>;
+		phy-names = "dp";
 	};
 
 Board Specific portion:
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index 05fed7d..5e1a715 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -19,6 +19,7 @@
 #include <linux/interrupt.h>
 #include <linux/delay.h>
 #include <linux/of.h>
+#include <linux/phy/phy.h>
 
 #include "exynos_dp_core.h"
 
@@ -960,8 +961,11 @@ static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
 
 	dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
 	if (!dp_phy_node) {
-		dev_err(dp->dev, "could not find dptx-phy node\n");
-		return -ENODEV;
+		dp->phy = devm_phy_get(dp->dev, "dp");
+		if (IS_ERR(dp->phy))
+			return PTR_ERR(dp->phy);
+		else
+			return 0;
 	}
 
 	if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
@@ -992,7 +996,9 @@ err:
 
 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 {
-	if (dp->phy_addr) {
+	if (dp->phy) {
+		phy_power_on(dp->phy);
+	} else if (dp->phy_addr) {
 		u32 reg;
 
 		reg = __raw_readl(dp->phy_addr);
@@ -1003,7 +1009,9 @@ static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 
 static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
 {
-	if (dp->phy_addr) {
+	if (dp->phy) {
+		phy_power_off(dp->phy);
+	} else if (dp->phy_addr) {
 		u32 reg;
 
 		reg = __raw_readl(dp->phy_addr);
diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
index 56cfec8..607e36d 100644
--- a/drivers/video/exynos/exynos_dp_core.h
+++ b/drivers/video/exynos/exynos_dp_core.h
@@ -151,6 +151,7 @@ struct exynos_dp_device {
 	struct video_info	*video_info;
 	struct link_train	link_train;
 	struct work_struct	hotplug_work;
+	struct phy		*phy;
 };
 
 /* exynos_dp_reg.c */
-- 
1.7.10.4




From srinivas.kandagatla at st.com  Tue Jul  9 03:26:24 2013
From: srinivas.kandagatla at st.com (Srinivas KANDAGATLA)
Date: Tue,  9 Jul 2013 08:26:24 +0100
Subject: [PATCH v2 1/2] ARM: dts: STi: Fix pinconf setup for STiH416 serial2
In-Reply-To: <1373354752-26292-1-git-send-email-srinivas.kandagatla@st.com>
References: <1373354752-26292-1-git-send-email-srinivas.kandagatla@st.com>
Message-ID: <1373354784-26357-1-git-send-email-srinivas.kandagatla@st.com>

From: Srinivas Kandagatla <srinivas.kandagatla at st.com>

This patch fixes a bug in pinctrl setup of serial2 device, Some of the
pins in the pinctrl node of serial2 do not belong to that
pin-controller. This patch divides them in the pins into there
respective pin controller nodes.

Without this patch serial on StiH416-B2000 Board will not work as it
fails with:

"st-pinctrl pin-controller-rear.3: failed to get pin(99) name
st-pinctrl pin-controller-rear.3: maps: function serial2 group serial2-0
num 4
pinconfig core: failed to register map default (3): no group/pin given"

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at st.com>
---
 arch/arm/boot/dts/stih416-pinctrl.dtsi |   10 +++++++++-
 arch/arm/boot/dts/stih416.dtsi         |    2 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/stih416-pinctrl.dtsi b/arch/arm/boot/dts/stih416-pinctrl.dtsi
index 957b21a..0f246c9 100644
--- a/arch/arm/boot/dts/stih416-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih416-pinctrl.dtsi
@@ -166,6 +166,15 @@
 				reg		= <0x9000 0x100>;
 				st,bank-name	= "PIO31";
 			};
+
+			serial2-oe {
+				pinctrl_serial2_oe: serial2-1 {
+					st,pins {
+						output-enable	= <&PIO11 3 ALT2 OUT>;
+					};
+				};
+			};
+
 		};
 
 		pin-controller-rear {
@@ -218,7 +227,6 @@
 					st,pins {
 						tx	= <&PIO17 4 ALT2 OUT>;
 						rx	= <&PIO17 5 ALT2 IN>;
-						output-enable	= <&PIO11 3 ALT2 OUT>;
 					};
 				};
 			};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 3cecd96..1a0326e 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -79,7 +79,7 @@
 			interrupts	= <0 197 0>;
 			clocks          = <&CLK_S_ICN_REG_0>;
 			pinctrl-names 	= "default";
-			pinctrl-0 	= <&pinctrl_serial2>;
+			pinctrl-0 	= <&pinctrl_serial2 &pinctrl_serial2_oe>;
 		};
 
 		/* SBC_UART1 */
-- 
1.7.6.5



From b32955 at freescale.com  Tue Jul  9 04:10:53 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 9 Jul 2013 16:10:53 +0800
Subject: [PATCH] of: match the compatible in the order set by the dts file
In-Reply-To: <20130709075124.GR516@pengutronix.de>
References: <1373013818-11365-1-git-send-email-b32955@freescale.com>
 <20130709070541.GQ516@pengutronix.de> <51DBBFDA.70302@freescale.com>
 <20130709075124.GR516@pengutronix.de>
Message-ID: <51DBC58D.90002@freescale.com>

? 2013?07?09? 15:51, Sascha Hauer ??:
> On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
>> ? 2013?07?09? 15:05, Sascha Hauer ??:
>>> Why don't you set the matching order in the driver the way you want it
>>> to be, i.e.:
>>>
>>> 	{ .compatible = "fsl,imx6q-uart", ... },
>>> 	{ .compatible = "fsl,imx21-uart", ... },
>>> 	{ .compatible = "fsl,imx1-uart", ... },
>>>
>> yes. i can set it like this.
>>
>> but this method looks like a ugly workaround.
> If a driver has different ways of supporting a single device, then
> putting the preferred or most feature rich on top doesn't look very ugly
> to me.
this method makes it much _coupled_ between the driver and the dts file.

IMHO, it's an unnecessary _burden_ to the driver programmer:
    he should puts the most feature compatible on the top.

it's much graceful if we let the driver programmer be transparent about 
this.

thanks
Huang Shijie









From richard.genoud at gmail.com  Tue Jul  9 04:19:45 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 9 Jul 2013 10:19:45 +0200
Subject: [PATCH v2 1/5] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <20130708150721.GK27646@sirena.org.uk>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373290193-25300-2-git-send-email-richard.genoud@gmail.com>
 <20130708150721.GK27646@sirena.org.uk>
Message-ID: <CACQ1gAgJyTSdxAKK7uwG-ybE2ddC90podM3+tOAqQwZUspsU8Q@mail.gmail.com>

2013/7/8 Mark Brown <broonie at kernel.org>:
> On Mon, Jul 08, 2013 at 03:29:49PM +0200, Richard Genoud wrote:
>
>> + *             Nicolas Ferre <nicolas.ferre at atmel.com>
>> + *
>> + * Based on sam9g20_wm8731.c by:
>> + * Sedji Gaouaou <sedji.gaouaou at atmel.com>
>
> The obvious question here is of course if we can use the same driver for
> both of them.
I haven't got a g20 to test that, but that's the goal.
For now, g20 is still non-DT, so I think it's best to have a DT-only
driver like this one for the 9x5 family (9g15, 9g25, 9x25, 9g35,
9x25).
When the g20 will move to DT completely, we can drop sam9g20_wm8731.c
and adjust sam9x5_wm8731.c (mainly master clock and widgets it seems)
By the way, maybe g45 could use that also (and SAMA5 ?)

>
>> +     codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 |
>> +             SNDRV_PCM_RATE_32000 |
>> +             SNDRV_PCM_RATE_48000 |
>> +             SNDRV_PCM_RATE_96000;
>> +     codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 |
>> +             SNDRV_PCM_RATE_32000 |
>> +             SNDRV_PCM_RATE_48000 |
>> +             SNDRV_PCM_RATE_96000;
>
> You definitely shouldn't be fiddling with a driver's constant static
> data.  You want to be using snd_pcm_hw_constraint() APIs to set
> additional constraints intead.
Ok, I'll change that.


Thanks !

-- 
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?


From minggr at gmail.com  Tue Jul  9 04:21:49 2013
From: minggr at gmail.com (Lin Ming)
Date: Tue, 9 Jul 2013 16:21:49 +0800
Subject: kernel decompressor problem for ARMv7
In-Reply-To: <20130709080524.GB26169@mudshark.cambridge.arm.com>
References: <CAF1ivSakn8-HiAf+4_cLRWUUTDP9QBKpAt+hVQoMyAmKZ2-dJA@mail.gmail.com>
 <20130705095757.GA13063@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1307051225240.18597@syhkavp.arg>
 <CAF1ivSbOXknHyDMH3RdmSGK2n5o2wVeR5oohCQnZ2gJrgvo=Hw@mail.gmail.com>
 <1373250435.824.6.camel@minggr>
 <CAF1ivSbk70UnNc-09C2w-CdgaFBXe_k6K6n8Qr3L-jCLiTGqow@mail.gmail.com>
 <alpine.LFD.2.03.1307090837230.28525@syhkavp.arg>
 <CAF1ivSZK8c4zSz5E-=P4032jFJxFrmwHForbCjLTVcJs4xOWkg@mail.gmail.com>
 <20130709080524.GB26169@mudshark.cambridge.arm.com>
Message-ID: <CAF1ivSZxC=QtgK0k+5gpOWuVQjCf1W8j2mBoT11BQuatDgwnrg@mail.gmail.com>

On Tue, Jul 9, 2013 at 4:05 PM, Will Deacon <will.deacon at arm.com> wrote:
> On Tue, Jul 09, 2013 at 08:53:05AM +0100, Lin Ming wrote:
>> On Tue, Jul 9, 2013 at 3:39 PM, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
>> > No more info needed.  The kernel has to be booted with the MMU disabled
>> > as per the booting protocol documentation. You therefore have to fix
>> > your
>> > bootloader.
>>
>> OK.
>>
>> But I have to also revert below commit to make decompressor work.
>>
>> commit 5010192:
>> ARM: 7583/1: decompressor: Enable unaligned memory access for v6 and above
>>
>> It seems like caused by bootloader has Alignment fault checking enabled.
>> Any suggestion how to fix it?
>
> Well step 1 is to disable the MMU. Once you've done that, you really don't
> want to be issuing unaligned accesses (since memory will be treated as
> strongly-ordered), so the value of the alignment trap bit is irrelevant.

Thanks. Will try it.

>
> Will


From tony at atomide.com  Tue Jul  9 04:23:04 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Jul 2013 01:23:04 -0700
Subject: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c
In-Reply-To: <20130708142103.GX21614@n2100.arm.linux.org.uk>
References: <20130517191304.468.73487.stgit@localhost>
 <20130517191751.468.89202.stgit@localhost>
 <20130520095447.GR21614@n2100.arm.linux.org.uk>
 <20130706131057.GU21614@n2100.arm.linux.org.uk>
 <20130706133627.GV21614@n2100.arm.linux.org.uk>
 <20130708093410.GT5523@atomide.com>
 <20130708142103.GX21614@n2100.arm.linux.org.uk>
Message-ID: <20130709082304.GB5523@atomide.com>

* Russell King - ARM Linux <linux at arm.linux.org.uk> [130708 07:27]:
> On Mon, Jul 08, 2013 at 02:34:11AM -0700, Tony Lindgren wrote:
> > 
> > Hey the good news is that you've updated your build system to support
> > also appended dtb images, thanks for doing that!
> 
> It was far from trivial - there's many places in the build process
> which do things quite differently depending on whether it's a DTB
> build or not.

Yes that's too bad. We can make it slightly easier to update from custom
.config files by always building in support for board-generic.c.
 
> It seems that - yet again - the mmc devices have swapped themselves.

Hmm they also seem to swap depending if there's a card plugged in.

> Also looks like the nonfunctional video stuff is even more nonfunctional
> than usual:
> 
> omapdss DSI error: can't get VDDS_DSI regulator
> omapdss HDMI error: can't get VDDA_HDMI_DAC regulator

Tomi?
 
> ASoC looks dead too:
> 
> omap-abe-twl6040 sound.10: ASoC: CPU DAI (null) not registered
> omap-abe-twl6040 sound.10: snd_soc_register_card() failed: -517

Peter, I think you've had audio working with devicetree for at least
a year or something?

Regards,

Tony


From richard.genoud at gmail.com  Tue Jul  9 04:27:53 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 9 Jul 2013 10:27:53 +0200
Subject: [PATCH v2 2/5] ARM: AT91: DTS: sam9x5: add SSC DMA parameters
In-Reply-To: <20130708150756.GL27646@sirena.org.uk>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373290193-25300-3-git-send-email-richard.genoud@gmail.com>
 <20130708150756.GL27646@sirena.org.uk>
Message-ID: <CACQ1gAgnRBr6Eu7sgbzNF2kmm18-zn_dGKZN45RaxXGd1kwL-Q@mail.gmail.com>

2013/7/8 Mark Brown <broonie at kernel.org>:
> On Mon, Jul 08, 2013 at 03:29:50PM +0200, Richard Genoud wrote:
>> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
>> ---
>>  arch/arm/boot/dts/at91sam9x5.dtsi |    3 +++
>
> There was no binding document in your first patch - there should be one
> for any new DT bindings.
The dma binding is documented here
Documentation/devicetree/bindings/dma/atmel-dma.txt
But you're right, I shoud update
Documentation/devicetree/bindings/misc/atmel-ssc.txt.

Thanks



-- 
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?


From Dave.Martin at arm.com  Tue Jul  9 04:30:29 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Tue, 9 Jul 2013 09:30:29 +0100
Subject: [PATCH] ARM: Kconfig: Let ARM_ERRATA_364296 not depend on
 CONFIG_SMP
In-Reply-To: <1373319489-9467-1-git-send-email-festevam@gmail.com>
References: <1373319489-9467-1-git-send-email-festevam@gmail.com>
Message-ID: <20130709083023.GA2911@localhost.localdomain>

On Mon, Jul 08, 2013 at 06:38:09PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> imx_v6_v7_defconfig handles both multi-core and single-core SoCs, and it has 
> CONFIG_SMP=y selected by default.
> 
> With such config we cannot select ARM_ERRATA_364296, as it depends on !SMP.
> 
> Let ARM_ERRATA_364296 be undependent on CONFIG_SMP, so that we can select
> this erratum for the ARM1136 SoCs, even if CONFIG_SMP=y is enabled.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

This looks sensible.  The enabled code checks for the specific
affected CPU ID in the CP15 Main ID Register, so it shouldn't get
activated on any other kind of CPU even if the option is enabled.

1136 can't be deployed as SMP, so the patch shouldn't break any existing
configuration.

Strictly speaking, && !SMP may be incorrect, since it is valid (if not
very useful) to build a v6 kernel with SMP and SMP_ON_UP, and run it on
1136 hardware, even if the kernel is non-multiplatform.

Reviewed-by: Dave Martin <Dave.Martin at arm.com>

> ---
>  arch/arm/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 0ac9be6..ba412e0 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1316,7 +1316,7 @@ config ARM_ERRATA_754327
>  
>  config ARM_ERRATA_364296
>  	bool "ARM errata: Possible cache data corruption with hit-under-miss enabled"
> -	depends on CPU_V6 && !SMP
> +	depends on CPU_V6
>  	help
>  	  This options enables the workaround for the 364296 ARM1136
>  	  r0p2 erratum (possible cache data corruption with
> -- 
> 1.8.1.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From tony at atomide.com  Tue Jul  9 04:31:53 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Jul 2013 01:31:53 -0700
Subject: [PATCH 09/12] ARM: DRA7: hwmod: Create initial DRA7XX SoC data
In-Reply-To: <1373355139-12487-10-git-send-email-rnayak@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
 <1373355139-12487-10-git-send-email-rnayak@ti.com>
Message-ID: <20130709083152.GC5523@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130709 00:39]:
> From: Ambresh K <ambresh at ti.com>

> --- /dev/null
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
...

> +/* dma_system */
> +static struct omap_hwmod_irq_info dra7xx_dma_system_irqs[] = {
> +	{ .name = "0", .irq = 12 + DRA7XX_IRQ_GIC_START },
> +	{ .name = "1", .irq = 13 + DRA7XX_IRQ_GIC_START },
> +	{ .name = "2", .irq = 14 + DRA7XX_IRQ_GIC_START },
> +	{ .name = "3", .irq = 15 + DRA7XX_IRQ_GIC_START },
> +	{ .irq = -1 }
> +};

I think these should no longer be needed?

In general, we must move the hwmod stuff to drivers/bus and start
parsing the data from device tree along the lines Tero is doing
for the clock data.

What's the plan for doing that?

Regards,

Tony


From tony at atomide.com  Tue Jul  9 04:36:14 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Jul 2013 01:36:14 -0700
Subject: [PATCH 2/8] ARM: DRA7: Update SRAM details
In-Reply-To: <1373354873-12359-3-git-send-email-rnayak@ti.com>
References: <1373354873-12359-1-git-send-email-rnayak@ti.com>
 <1373354873-12359-3-git-send-email-rnayak@ti.com>
Message-ID: <20130709083613.GD5523@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130709 00:34]:
> DRA7xx devices have 512K of SRAM for both secure and non-secure
> devices.
> 
> Signed-off-by: Rajendra Nayak <rnayak at ti.com>
> Signed-off-by: R Sricharan <r.sricharan at ti.com>
> ---
>  arch/arm/mach-omap2/sram.c |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
> index 4bd0968..67d4277 100644
> --- a/arch/arm/mach-omap2/sram.c
> +++ b/arch/arm/mach-omap2/sram.c
> @@ -38,6 +38,7 @@
>  #define OMAP4_SRAM_PUB_PA	(OMAP4_SRAM_PA + 0x4000)
>  #endif
>  #define OMAP5_SRAM_PA		0x40300000
> +#define DRA7_SRAM_PA		OMAP4_SRAM_PA
>  
>  #define SRAM_BOOTLOADER_SZ	0x00
>  
> @@ -111,6 +112,9 @@ static void __init omap_detect_sram(void)
>  		} else if (soc_is_omap54xx()) {
>  			omap_sram_start = OMAP5_SRAM_PA;
>  			omap_sram_size = SZ_128K; /* 128KB */
> +		} else if (soc_is_dra7xx()) {
> +			omap_sram_start = DRA7_SRAM_PA;
> +			omap_sram_size = SZ_512K; /* 512KB */
>  		} else {
>  			omap_sram_start = OMAP2_SRAM_PUB_PA;
>  			omap_sram_size = 0x800; /* 2K */
> @@ -131,6 +135,9 @@ static void __init omap_detect_sram(void)
>  		} else if (soc_is_omap54xx()) {
>  			omap_sram_start = OMAP5_SRAM_PA;
>  			omap_sram_size = SZ_128K; /* 128KB */
> +		} else if (soc_is_dra7xx()) {
> +			omap_sram_start = DRA7_SRAM_PA;
> +			omap_sram_size = SZ_512K; /* 512KB */
>  		} else {
>  			omap_sram_start = OMAP2_SRAM_PA;
>  			if (cpu_is_omap242x())

This again reminds me that we should move omaps to use
drivers/misc/sram.c. Other than that, this set looks good
to me.

Regards,

Tony


From will.deacon at arm.com  Tue Jul  9 04:37:13 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Jul 2013 09:37:13 +0100
Subject: [PATCH] ARM: Kconfig: Let ARM_ERRATA_364296 not depend on
 CONFIG_SMP
In-Reply-To: <20130708215320.GU24642@n2100.arm.linux.org.uk>
References: <1373319489-9467-1-git-send-email-festevam@gmail.com>
 <20130708215320.GU24642@n2100.arm.linux.org.uk>
Message-ID: <20130709083713.GA26895@mudshark.cambridge.arm.com>

On Mon, Jul 08, 2013 at 10:53:20PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 08, 2013 at 06:38:09PM -0300, Fabio Estevam wrote:
> > From: Fabio Estevam <fabio.estevam at freescale.com>
> > 
> > imx_v6_v7_defconfig handles both multi-core and single-core SoCs, and it has 
> > CONFIG_SMP=y selected by default.
> > 
> > With such config we cannot select ARM_ERRATA_364296, as it depends on !SMP.
> > 
> > Let ARM_ERRATA_364296 be undependent on CONFIG_SMP, so that we can select
> > this erratum for the ARM1136 SoCs, even if CONFIG_SMP=y is enabled.
> 
> I'll wait for ARM Ltd folk to comment on this (they're at Linaro Connect
> at the moment which has extremely poor 'net connectivity from what I've
> been hearing).  We might need to bypass the workaround code in the non-SMP
> case.

The workaround (in proc-v6.S) checks the midr specifically for 1136 r0p2, so
it should be fine to remove the CONFIG_SMP dependency given that the 1136 is
UP only.

Will


From voice.shen at atmel.com  Tue Jul  9 04:37:36 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Tue, 9 Jul 2013 16:37:36 +0800
Subject: [PATCH v2 1/5] sound: sam9x5_wm8731: machine driver for at91sam9x5
 wm8731 boards
In-Reply-To: <CACQ1gAgJyTSdxAKK7uwG-ybE2ddC90podM3+tOAqQwZUspsU8Q@mail.gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373290193-25300-2-git-send-email-richard.genoud@gmail.com>
 <20130708150721.GK27646@sirena.org.uk>
 <CACQ1gAgJyTSdxAKK7uwG-ybE2ddC90podM3+tOAqQwZUspsU8Q@mail.gmail.com>
Message-ID: <51DBCBD0.8060901@atmel.com>

Hi Richard,

On 7/9/2013 16:19, Richard Genoud wrote:
> 2013/7/8 Mark Brown <broonie at kernel.org>:
>> On Mon, Jul 08, 2013 at 03:29:49PM +0200, Richard Genoud wrote:
>>
>>> + *             Nicolas Ferre <nicolas.ferre at atmel.com>
>>> + *
>>> + * Based on sam9g20_wm8731.c by:
>>> + * Sedji Gaouaou <sedji.gaouaou at atmel.com>
>>
>> The obvious question here is of course if we can use the same driver for
>> both of them.
> I haven't got a g20 to test that, but that's the goal.
> For now, g20 is still non-DT, so I think it's best to have a DT-only
> driver like this one for the 9x5 family (9g15, 9g25, 9x25, 9g35,
> 9x25).
> When the g20 will move to DT completely, we can drop sam9g20_wm8731.c
> and adjust sam9x5_wm8731.c (mainly master clock and widgets it seems)

The at91sam9g20ek board can work in DT mode, and the sound has support 
in DT mode already.

Sure, the mainly thing we need deal with is the master clock and 
widgets. If put them together will make code ugly or need many many 
#ifdef, I suggest to keep them separately.

> By the way, maybe g45 could use that also (and SAMA5 ?)

For g45ek board, it use AC97 interface, not the case.

>>
>>> +     codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 |
>>> +             SNDRV_PCM_RATE_32000 |
>>> +             SNDRV_PCM_RATE_48000 |
>>> +             SNDRV_PCM_RATE_96000;
>>> +     codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 |
>>> +             SNDRV_PCM_RATE_32000 |
>>> +             SNDRV_PCM_RATE_48000 |
>>> +             SNDRV_PCM_RATE_96000;
>>
>> You definitely shouldn't be fiddling with a driver's constant static
>> data.  You want to be using snd_pcm_hw_constraint() APIs to set
>> additional constraints intead.
> Ok, I'll change that.
>
>
> Thanks !
>

Best Regards,
Bo Shen


From olof at lixom.net  Tue Jul  9 04:37:34 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue,  9 Jul 2013 01:37:34 -0700
Subject: [PATCH] ARM: omap2: add select of TI_PRIV_EDMA
Message-ID: <1373359054-5007-1-git-send-email-olof@lixom.net>

"ARM: OMAP: build mach-omap code only if needed" moved around the
ARCH_OMAP2PLUS stanza, but accidentally dropped the seleciton of
TI_PRIV_EDMA in the process. Add it back.

Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Tony Lindgren <tony at atomide.com>
Signed-off-by: Olof Johansson <olof at lixom.net>

---

I noticed the original patch was a bit down in the fixes branch, so
instead of rebasing I checked this in on top.

-Olof

 arch/arm/mach-omap2/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 5c14051..58152b1 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -99,6 +99,7 @@ config ARCH_OMAP2PLUS
 	select PROC_DEVICETREE if PROC_FS
 	select SOC_BUS
 	select SPARSE_IRQ
+	select TI_PRIV_EDMA
 	select USE_OF
 	help
 	  Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
-- 
1.8.1.192.gc4361b8



From s.nawrocki at samsung.com  Tue Jul  9 04:50:26 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Tue, 09 Jul 2013 10:50:26 +0200
Subject: [PATCH V6 0/4] Generic PHY driver for the Exynos SoC DP PHY
In-Reply-To: <003d01ce7c7a$d04043d0$70c0cb70$@samsung.com>
References: <003d01ce7c7a$d04043d0$70c0cb70$@samsung.com>
Message-ID: <51DBCED2.7010102@samsung.com>

On 07/09/2013 10:03 AM, Jingoo Han wrote:
> This patch series adds a simple driver for the Samsung Exynos SoC
> series DP transmitter PHY, using the generic PHY framework [1].
> Previously the DP PHY used an internal DT node to control the PHY
> power enable bit.
> 
> These patches was tested on Exynos5250.
> 
> This PATCH v6 follows:
>  * PATCH v5, sent on July, 8th 2013
>  * PATCH v4, sent on July, 2nd 2013
>  * PATCH v3, sent on July, 1st 2013
>  * PATCH v2, sent on June, 28th 2013
>  * PATCH v1, sent on June, 28th 2013
> 
> Changes between v5 and v6:
>   * Re-based on git://gitorious.org/linuxphy/linuxphy.git

I'm not sure if we really need to keep the documentation of the
original binding. Anyway, for the whole series, please feel free
to ad my

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>

--
Thanks,
Sylwester



From wni at nvidia.com  Tue Jul  9 04:58:51 2013
From: wni at nvidia.com (Wei Ni)
Date: Tue, 9 Jul 2013 16:58:51 +0800
Subject: [lm-sensors] [PATCH 1/2] ARM: dt: t30 cardhu: add dt entry for
 lm90
In-Reply-To: <20130709095525.5158a0a5@endymion.delvare>
References: <1372928979-26938-1-git-send-email-wni@nvidia.com>
 <1372928979-26938-2-git-send-email-wni@nvidia.com>
 <51D70483.70203@wwwdotorg.org>	<51DA6BD4.1040300@nvidia.com>
 <20130708095024.041a6d57@endymion.delvare>	<51DA8805.50709@nvidia.com>
 <20130708131421.GB21638@roeck-us.net>	<20130709062112.GC17499@mithrandir>
 <51DBC058.2040904@nvidia.com> <20130709095525.5158a0a5@endymion.delvare>
Message-ID: <51DBD0CB.2000504@nvidia.com>

On 07/09/2013 03:55 PM, Jean Delvare wrote:
> On Tue, 9 Jul 2013 15:48:40 +0800, Wei Ni wrote:
>> On 07/09/2013 02:21 PM, Thierry Reding wrote:
>>> It should work out of the box. As a matter of fact the same chip is used
>>> on Tamonten and the DTS files use "onnn,nct1008". That used to work. If
>>> it no longer does then that's a regression.
>>
>> I synced the linux-next from:
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>> and use the tag v3.10-rc7, but in the lm90.c it doesn't have DT support,
>> such as "onnn,nct1008".
>> I googled it and found there has patch:
>> [PATCH] hwmon: (lm90) Add device tree support , which is in:
>> http://lists.lm-sensors.org/pipermail/lm-sensors/2013-February/038099.html
>> , but it didn't be merged into the linux-next.
> 
> It was not, because of the next reply in the same thread:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2013-February/038100.html
> 
>> which git repository and branch should I use ?
> 
> It is supposed to just work. What doesn't work for you exactly?
> 

Oh, yes, the "onnn,nct1008" can work. I read the i2c driver and the
of_i2c.c carefully, I understand why the lm90 can be loaded by setting
"onnn,nct1008". Indeed, we can set the vendor string to anything, even
"xxx,nct1008", the lm90 also can be loaded correctly.

Anyway, I will use the "onnn,nct1008" in my next version.

Thanks for your comments.
Wei.





From magnus.damm at gmail.com  Tue Jul  9 05:09:22 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 9 Jul 2013 18:09:22 +0900
Subject: [PATCH 01/04] ARM: shmobile: Only build clocks when COMMON_CLK=n
In-Reply-To: <1774541.9WRl3VrJqz@avalon>
References: <20130709054331.14007.66068.sendpatchset@w520>
 <20130709054341.14007.99736.sendpatchset@w520>
 <201307090943.07898.arnd@arndb.de> <1774541.9WRl3VrJqz@avalon>
Message-ID: <CANqRtoRJhrbT4NMv4e7NwvXj0JoO001ShtjSwdquv7x-7dxKeA@mail.gmail.com>

Hi Laurent and Arnd,

On Tue, Jul 9, 2013 at 4:45 PM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> Hi Arnd and Magnus,
>
> On Tuesday 09 July 2013 09:43:07 Arnd Bergmann wrote:
>> On Tuesday 09 July 2013, Magnus Damm wrote:
>> > +obj-y                          += $(clk-y$(CONFIG_COMMON_CLK))
>>
>> It took me a bit to understand the Makefile trick you are using here.
>> I assume other readers will have the same problem. How about just
>> doing
>>
>> +ifndef CONFIG_COMMON_CLK
>>  obj-$(CONFIG_ARCH_SH7372)      += setup-sh7372.o intc-sh7372.o
>>  obj-$(CONFIG_ARCH_SH73A0)      += setup-sh73a0.o intc-sh73a0.o
>>  obj-$(CONFIG_ARCH_R8A73A4)     += setup-r8a73a4.o
>>  obj-$(CONFIG_ARCH_R8A7740)     += setup-r8a7740.o intc-r8a7740.o
>>  obj-$(CONFIG_ARCH_R8A7778)     += setup-r8a7778.o
>>  obj-$(CONFIG_ARCH_R8A7779)     += setup-r8a7779.o intc-r8a7779.o
>>  obj-$(CONFIG_ARCH_R8A7790)     += setup-r8a7790.o
>>  obj-$(CONFIG_ARCH_EMEV2)       += setup-emev2.o
>> +endif
>
> I was about to mention the same, so I think that would be a good idea.

Sure, that may be a more common way to handle this. =)

To be clear, I assume you wanted that ifndef to cover the clock-xxx.c
files instead of setup-xxx.c. So I will do that in next version.

Thanks for your comments!

Cheers,

/ magnus


From magnus.damm at gmail.com  Tue Jul  9 05:11:09 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 9 Jul 2013 18:11:09 +0900
Subject: [PATCH 00/04] ARM: shmobile: ARCH_MULTIPLATFORM for EMEV2 and
 KZM9D
In-Reply-To: <201307090945.36314.arnd@arndb.de>
References: <20130709054331.14007.66068.sendpatchset@w520>
 <201307090945.36314.arnd@arndb.de>
Message-ID: <CANqRtoRpMC+D4OHTLkrmgrZ+HZdFcGuBQti3kkDeiT_vrCduvA@mail.gmail.com>

On Tue, Jul 9, 2013 at 4:45 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Tuesday 09 July 2013, Magnus Damm wrote:
>> ARM: shmobile: ARCH_MULTIPLATFORM for EMEV2 and KZM9D
>>
>> [PATCH 01/04] ARM: shmobile: Only build clocks when COMMON_CLK=n
>> [PATCH 02/04] ARM: shmobile: Introduce ARCH_SHMOBILE_MULTI
>> [PATCH 03/04] ARM: shmobile: Add EMEV2 and KZM9D to ARCH_SHMOBILE_MULTI
>> [PATCH 04/04] ARM: shmobile: Allow ARCH_SHMOBILE_MULTI timer configuration
>>
>> This patch set extends mach-shmobile to allow a subset of SoCs and
>> boards to be built for ARCH_MULTIPLATFORM. With this series applied
>> the EMEV2 SoC and the KZM9D board can be built in two ways - either
>> as good old ARCH_SHMOBILE or new ARCH_SHMOBILE_MULTI. The latter
>> requires common clock framework for proper run time operation.
>>
>> The goal is to over time move all DT reference implementations from
>> ARCH_SHMOBILE to ARCH_SHMOBILE_MULTI. Until CCF is available for a
>> certain SoC it is to me acceptable for a DT reference board to allow
>> build in both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI. The reason for
>> this is to allow incremental development and easy testing during
>> development of CCF for a certain SoC. The KZM9D board is now in this
>> state while it is waiting for common clocks to become ready.
>>
>> In the near future a prototype hack will be posted that comments
>> out the clock framework bits on EMEV2 and will allow boot of KZM9D
>> in the case of ARCH_SHMOBILE_MULTI even though CCF is not yet
>> available.
>>
>> Signed-off-by: Magnus Damm <damm at opensource.se>
>
> Great stuff, very glad you got this far!

Thanks, I'm happy to hear that!

> I have two small style comments, nothing important.

Sure, I will fix up and resend. Thanks for your feedback!

/ magnus


From magnus.damm at gmail.com  Tue Jul  9 05:15:46 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 9 Jul 2013 18:15:46 +0900
Subject: [PATCH 03/04] ARM: shmobile: Add EMEV2 and KZM9D to
 ARCH_SHMOBILE_MULTI
In-Reply-To: <201307090937.29805.arnd@arndb.de>
References: <20130709054331.14007.66068.sendpatchset@w520>
 <20130709054359.14007.23619.sendpatchset@w520>
 <201307090937.29805.arnd@arndb.de>
Message-ID: <CANqRtoTcqYxCTWRok4cuzRWbCBULxwGYhgPyiVH_FgxBLtx7SQ@mail.gmail.com>

Hi Arnd,

On Tue, Jul 9, 2013 at 4:37 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Tuesday 09 July 2013, Magnus Damm wrote:
>> +void __init __weak emev2_clock_init(void)
>> +{
>> +       /* in case legacy clocks are disabled then do nothing */
>> +}
>
> Nitpicking:
>
> I don't like the __weak symbols too much, in general I prefer
> doing either
>
>         if (IS_ENABLED(CONFIG_SHMOBILE_CLOCKS)
>                 emev2_clock_init()
>
> or using an inline alternative in the header file.

Sure, good idea. I plan on using the following if you don't mind:

         if (!IS_ENABLED(CONFIG_COMMON_CLK)
                 emev2_clock_init()

Cheers,

/ magnus


From ludovic.desroches at atmel.com  Tue Jul  9 05:17:00 2013
From: ludovic.desroches at atmel.com (Ludovic Desroches)
Date: Tue, 9 Jul 2013 11:17:00 +0200
Subject: [PATCH 1/7] serial: at91: correct definition from DMA to PDC
In-Reply-To: <51DBC24E.9060601@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
 <1373351626-30143-2-git-send-email-elen.song@atmel.com>
 <20130709073155.GB4013@ludovic.desroches@atmel.com>
 <51DBC24E.9060601@atmel.com>
Message-ID: <20130709091700.GD4013@ludovic.desroches@atmel.com>

On Tue, Jul 09, 2013 at 03:57:02PM +0800, elen.song wrote:
> On 7/9/2013 3:31 PM, Ludovic Desroches wrote:
> >Hi Elen,
> >
> >One comment below:
> >
> >On Tue, Jul 09, 2013 at 02:33:40PM +0800, Elen Song wrote:
> >
> >[...]
> >
> >>diff --git a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> >>index a49d9a1..82f45ec 100644
> >>--- a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> >>+++ b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> >>@@ -8,8 +8,8 @@ Required properties:
> >>  - interrupts: Should contain interrupt
> >>  Optional properties:
> >>-- atmel,use-dma-rx: use of PDC or DMA for receiving data
> >>-- atmel,use-dma-tx: use of PDC or DMA for transmitting data
> >>+- atmel,use-pdc-rx: use of PDC for receiving data
> >>+- atmel,use-pdc-tx: use of PDC for transmitting data
> >>  <chip> compatible description:
> >>  - at91rm9200:  legacy USART support
> >>@@ -19,9 +19,9 @@ Example:
> >>  	usart0: serial at fff8c000 {
> >>  		compatible = "atmel,at91sam9260-usart";
> >>-		reg = <0xfff8c000 0x4000>;
> >>-		interrupts = <7>;
> >>-		atmel,use-dma-rx;
> >>-		atmel,use-dma-tx;
> >>+		reg = <0xfff8c000 0x200>;
> >>+		interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
> >Maybe put these changes into an other patch since it is not in relation with
> >the purpose of your patch.
> >
> >Moreover, I am not sure that macros should be used in the documentation. From
> >the top of my head, there was a discussion about that and the status was to not
> >use macros in documentation since it is Linux dependant.
> 
> Ok, I will not involve the macros in the document now.
> So I will move all the document changes into the last patch, right?

Documentation update is ok excepting the reg field change which should be in a
fixup patch since it is not related to the introduction of use-pdc-*.

> >
> >>+		atmel,use-pdc-rx;
> >>+		atmel,use-pdc-tx;
> >>  	};
> >[...]
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From george.cherian at ti.com  Tue Jul  9 05:17:26 2013
From: george.cherian at ti.com (George Cherian)
Date: Tue, 9 Jul 2013 14:47:26 +0530
Subject: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
Message-ID: <1373361446-30050-1-git-send-email-george.cherian@ti.com>

Adds device node for HS USB Host module for AM437x

changes from v1

renamed synopsis to snps
removed flag tx-fifo-resize

Signed-off-by: George Cherian <george.cherian at ti.com>
---
 arch/arm/boot/dts/am4372.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..c9e0da8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,23 @@
 			compatible = "ti,am4372-counter32k","ti,omap-counter32k";
 			reg = <0x44e86000 0x40>;
 		};
+
+		usb_otg_hs1: am4372_dwc3 at 48380000 {
+			compatible = "ti,am437x-dwc3";
+			reg = <0x48380000 0x1ff>;
+			interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			utmi-mode = <1>;
+			ranges;
+
+			dwc3 at 48390000 {
+				compatible = "snps,dwc3";
+				reg = <0x48390000 0xcfff>;
+				interrupts = <GIC_SPI  168 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+		};
+		
 	};
 };
-- 
1.8.1.4



From elen.song at atmel.com  Tue Jul  9 05:19:02 2013
From: elen.song at atmel.com (elen.song)
Date: Tue, 9 Jul 2013 17:19:02 +0800
Subject: [PATCH 1/7] serial: at91: correct definition from DMA to PDC
In-Reply-To: <20130709091700.GD4013@ludovic.desroches@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
 <1373351626-30143-2-git-send-email-elen.song@atmel.com>
 <20130709073155.GB4013@ludovic.desroches@atmel.com>
 <51DBC24E.9060601@atmel.com>
 <20130709091700.GD4013@ludovic.desroches@atmel.com>
Message-ID: <51DBD586.2040806@atmel.com>

On 7/9/2013 5:17 PM, Ludovic Desroches wrote:
> On Tue, Jul 09, 2013 at 03:57:02PM +0800, elen.song wrote:
>> On 7/9/2013 3:31 PM, Ludovic Desroches wrote:
>>> Hi Elen,
>>>
>>> One comment below:
>>>
>>> On Tue, Jul 09, 2013 at 02:33:40PM +0800, Elen Song wrote:
>>>
>>> [...]
>>>
>>>> diff --git a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
>>>> index a49d9a1..82f45ec 100644
>>>> --- a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
>>>> +++ b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
>>>> @@ -8,8 +8,8 @@ Required properties:
>>>>   - interrupts: Should contain interrupt
>>>>   Optional properties:
>>>> -- atmel,use-dma-rx: use of PDC or DMA for receiving data
>>>> -- atmel,use-dma-tx: use of PDC or DMA for transmitting data
>>>> +- atmel,use-pdc-rx: use of PDC for receiving data
>>>> +- atmel,use-pdc-tx: use of PDC for transmitting data
>>>>   <chip> compatible description:
>>>>   - at91rm9200:  legacy USART support
>>>> @@ -19,9 +19,9 @@ Example:
>>>>   	usart0: serial at fff8c000 {
>>>>   		compatible = "atmel,at91sam9260-usart";
>>>> -		reg = <0xfff8c000 0x4000>;
>>>> -		interrupts = <7>;
>>>> -		atmel,use-dma-rx;
>>>> -		atmel,use-dma-tx;
>>>> +		reg = <0xfff8c000 0x200>;
>>>> +		interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
>>> Maybe put these changes into an other patch since it is not in relation with
>>> the purpose of your patch.
>>>
>>> Moreover, I am not sure that macros should be used in the documentation. From
>>> the top of my head, there was a discussion about that and the status was to not
>>> use macros in documentation since it is Linux dependant.
>> Ok, I will not involve the macros in the document now.
>> So I will move all the document changes into the last patch, right?
> Documentation update is ok excepting the reg field change which should be in a
> fixup patch since it is not related to the introduction of use-pdc-*.

ok, thanks.
>
>>>> +		atmel,use-pdc-rx;
>>>> +		atmel,use-pdc-tx;
>>>>   	};
>>> [...]
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From broonie at kernel.org  Tue Jul  9 05:29:17 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Jul 2013 10:29:17 +0100
Subject: [PATCH v2 1/5] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <CACQ1gAgJyTSdxAKK7uwG-ybE2ddC90podM3+tOAqQwZUspsU8Q@mail.gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373290193-25300-2-git-send-email-richard.genoud@gmail.com>
 <20130708150721.GK27646@sirena.org.uk>
 <CACQ1gAgJyTSdxAKK7uwG-ybE2ddC90podM3+tOAqQwZUspsU8Q@mail.gmail.com>
Message-ID: <20130709092917.GO27646@sirena.org.uk>

On Tue, Jul 09, 2013 at 10:19:45AM +0200, Richard Genoud wrote:
> 2013/7/8 Mark Brown <broonie at kernel.org>:

> > The obvious question here is of course if we can use the same driver for
> > both of them.

> I haven't got a g20 to test that, but that's the goal.

I think I do somewhere.

> For now, g20 is still non-DT, so I think it's best to have a DT-only
> driver like this one for the 9x5 family (9g15, 9g25, 9x25, 9g35,
> 9x25).
> When the g20 will move to DT completely, we can drop sam9g20_wm8731.c
> and adjust sam9x5_wm8731.c (mainly master clock and widgets it seems)
> By the way, maybe g45 could use that also (and SAMA5 ?)

If this is the goal then this driver needs a more generic name.
-------------- 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/20130709/c646adba/attachment.sig>

From broonie at kernel.org  Tue Jul  9 05:32:54 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Jul 2013 10:32:54 +0100
Subject: [PATCH v2 2/5] ARM: AT91: DTS: sam9x5: add SSC DMA parameters
In-Reply-To: <CACQ1gAgnRBr6Eu7sgbzNF2kmm18-zn_dGKZN45RaxXGd1kwL-Q@mail.gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373290193-25300-3-git-send-email-richard.genoud@gmail.com>
 <20130708150756.GL27646@sirena.org.uk>
 <CACQ1gAgnRBr6Eu7sgbzNF2kmm18-zn_dGKZN45RaxXGd1kwL-Q@mail.gmail.com>
Message-ID: <20130709093254.GP27646@sirena.org.uk>

On Tue, Jul 09, 2013 at 10:27:53AM +0200, Richard Genoud wrote:

> The dma binding is documented here
> Documentation/devicetree/bindings/dma/atmel-dma.txt
> But you're right, I shoud update
> Documentation/devicetree/bindings/misc/atmel-ssc.txt.

No, you need to write a binding for this machine driver - the DMA and
SSC need to be documented as well but so too does the audio driver that
pulls them together with the CODEC.
-------------- 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/20130709/b95f65f1/attachment.sig>

From richard.genoud at gmail.com  Tue Jul  9 05:46:03 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 9 Jul 2013 11:46:03 +0200
Subject: [PATCH v2 2/5] ARM: AT91: DTS: sam9x5: add SSC DMA parameters
In-Reply-To: <20130709093254.GP27646@sirena.org.uk>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373290193-25300-3-git-send-email-richard.genoud@gmail.com>
 <20130708150756.GL27646@sirena.org.uk>
 <CACQ1gAgnRBr6Eu7sgbzNF2kmm18-zn_dGKZN45RaxXGd1kwL-Q@mail.gmail.com>
 <20130709093254.GP27646@sirena.org.uk>
Message-ID: <CACQ1gAhNAnyfaDSCxqAv11KZA2bGTdcfgcBjprAu3Ecw1y02mg@mail.gmail.com>

2013/7/9 Mark Brown <broonie at kernel.org>:
> On Tue, Jul 09, 2013 at 10:27:53AM +0200, Richard Genoud wrote:
>
>> The dma binding is documented here
>> Documentation/devicetree/bindings/dma/atmel-dma.txt
>> But you're right, I shoud update
>> Documentation/devicetree/bindings/misc/atmel-ssc.txt.
>
> No, you need to write a binding for this machine driver - the DMA and
> SSC need to be documented as well but so too does the audio driver that
> pulls them together with the CODEC.
Ok, I understand !

Richard.


From jgq516 at gmail.com  Tue Jul  9 05:53:11 2013
From: jgq516 at gmail.com (jgq516 at gmail.com)
Date: Tue, 09 Jul 2013 17:53:11 +0800
Subject: v3.10 - big endian core support
In-Reply-To: <51DA9E08.2030707@codethink.co.uk>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com> <51DA8D36.7010006@codethink.co.uk>
 <51DA8E6F.60507@gmail.com> <51DA9E08.2030707@codethink.co.uk>
Message-ID: <51DBDD87.6030902@gmail.com>


> My notes show I did a custom 3.5 backport for a customer's kernel
> so was not testing with the latest. I think I tried 3.9 with LPAE
> but cannot find confirmation in my notes that this actually happened.
>
>
Thanks for your feedback, it give me more confidence to make it work with
3.4 kernel, actually it works now :)

Xiao


From jgq516 at gmail.com  Tue Jul  9 05:55:05 2013
From: jgq516 at gmail.com (jgq516 at gmail.com)
Date: Tue, 09 Jul 2013 17:55:05 +0800
Subject: v3.10 - big endian core support
In-Reply-To: <20130709074553.GA25885@mudshark.cambridge.arm.com>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com>
 <20130708084911.GA22057@mudshark.cambridge.arm.com>
 <51DA8BBF.7080104@gmail.com>
 <20130708110202.GD22057@mudshark.cambridge.arm.com>
 <20130708170352.GA24361@mudshark.cambridge.arm.com>
 <51DB64FB.8030208@gmail.com> <51DB84D5.3000700@gmail.com>
 <20130709074553.GA25885@mudshark.cambridge.arm.com>
Message-ID: <51DBDDF9.6020708@gmail.com>

On 07/09/2013 03:45 PM, Will Deacon wrote:
> On Tue, Jul 09, 2013 at 04:34:45AM +0100, jgq516 at gmail.com wrote:
>> On 07/09/2013 09:18 AM, jgq516 at gmail.com wrote:
>>> On 07/09/2013 01:03 AM, Will Deacon wrote:
>>>> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
>>>>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
>>>>>> The printascii can output before "b __enable_mmu", after move it to
>>>>>> __mmap_switched, nothing can be printed. But if disable LPAE,
>>>>>> printascii
>>>>>> works again in __mmap_switched.
>>>>> Ok, so the page tables are broken. The code is there to swap the two
>>>>> words,
>>>>> but perhaps something ends up being off-by-4 or the like. I'll try
>>>>> and take
>>>>> a look.
>>>> Right, I managed to have a quick play with a 3.10 kernel and the good
>>>> news
>>>> is that the page tables are fine. The bad part is that using
>>>> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the
>>>> FDT
>>>> results in a NULL command line, so I don't see any output. If I
>>>> hardcode the
>>>> command line in the kernel image, things work fine.
>>>>
>> Hi Will,
>>
>> Which kernel tree are you used? I tried latest mainline kernel (used
>> vexpress_defconfig
>> and vexpress-v2p-ca15_a7.dtb) without any modification, but it hangs as
>> follows.
> Just try 3.10 at the moment -- we're currently in the middle of the merge
> window and I know that there is some timer breakage that people have been
> talking about.
Thanks a lot, it works after cherry pick patches from 3.10 kernel.

Thanks,
Xiao
> Will



From ludovic.desroches at atmel.com  Tue Jul  9 05:57:04 2013
From: ludovic.desroches at atmel.com (Ludovic Desroches)
Date: Tue, 9 Jul 2013 11:57:04 +0200
Subject: [PATCH 2/7] serial: at91: add tx dma support
In-Reply-To: <1373351626-30143-3-git-send-email-elen.song@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
 <1373351626-30143-3-git-send-email-elen.song@atmel.com>
Message-ID: <20130709095704.GE4013@ludovic.desroches@atmel.com>

On Tue, Jul 09, 2013 at 02:33:41PM +0800, Elen Song wrote:

[...]
  
> @@ -977,6 +1172,8 @@ static int atmel_startup(struct uart_port *port)
>  		pdc->ofs = 0;
>  	}
>  
> +	atmel_tx_request_dma(atmel_port);
> +
>  	/*
>  	 * If there is a specific "open" function (to register
>  	 * control line interrupts)

Here we can have both use_pdc_tx and use_dma_tx set to true. To avoid this, we
can do:

if (atmel_use_pdc_tx(port)) {

} else {
	atmel_tx_request_dma(atmel_port);
}

or force use_pdc_tx to 0 in atmel_tx_request_dma function when we set
use_dma_tx to 1.

I prefer the second one since using dma has a higher priority than using pdc
contrary to the first one.


Regards

Ludovic


From ben.dooks at codethink.co.uk  Tue Jul  9 05:59:33 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Tue, 09 Jul 2013 10:59:33 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <51DBDD87.6030902@gmail.com>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com> <51DA8D36.7010006@codethink.co.uk>
 <51DA8E6F.60507@gmail.com> <51DA9E08.2030707@codethink.co.uk>
 <51DBDD87.6030902@gmail.com>
Message-ID: <51DBDF05.3060700@codethink.co.uk>

On 09/07/13 10:53, jgq516 at gmail.com wrote:
>
>> My notes show I did a custom 3.5 backport for a customer's kernel
>> so was not testing with the latest. I think I tried 3.9 with LPAE
>> but cannot find confirmation in my notes that this actually happened.
>>
>>
> Thanks for your feedback, it give me more confidence to make it work with
> 3.4 kernel, actually it works now :)

There where several fixes done pre v3.10 which sorted out some kernel
bugs where endian-ness was assumed.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From jgq516 at gmail.com  Tue Jul  9 06:04:34 2013
From: jgq516 at gmail.com (jgq516 at gmail.com)
Date: Tue, 09 Jul 2013 18:04:34 +0800
Subject: v3.10 - big endian core support
In-Reply-To: <51DBDDF9.6020708@gmail.com>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com>
 <20130708084911.GA22057@mudshark.cambridge.arm.com>
 <51DA8BBF.7080104@gmail.com>
 <20130708110202.GD22057@mudshark.cambridge.arm.com>
 <20130708170352.GA24361@mudshark.cambridge.arm.com>
 <51DB64FB.8030208@gmail.com> <51DB84D5.3000700@gmail.com>
 <20130709074553.GA25885@mudshark.cambridge.arm.com>
 <51DBDDF9.6020708@gmail.com>
Message-ID: <51DBE032.7040607@gmail.com>

On 07/09/2013 05:55 PM, jgq516 at gmail.com wrote:
> On 07/09/2013 03:45 PM, Will Deacon wrote:
>> On Tue, Jul 09, 2013 at 04:34:45AM +0100, jgq516 at gmail.com wrote:
>>> On 07/09/2013 09:18 AM, jgq516 at gmail.com wrote:
>>>> On 07/09/2013 01:03 AM, Will Deacon wrote:
>>>>> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
>>>>>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
>>>>>>> The printascii can output before "b __enable_mmu", after move it to
>>>>>>> __mmap_switched, nothing can be printed. But if disable LPAE,
>>>>>>> printascii
>>>>>>> works again in __mmap_switched.
>>>>>> Ok, so the page tables are broken. The code is there to swap the two
>>>>>> words,
>>>>>> but perhaps something ends up being off-by-4 or the like. I'll try
>>>>>> and take
>>>>>> a look.
>>>>> Right, I managed to have a quick play with a 3.10 kernel and the good
>>>>> news
>>>>> is that the page tables are fine. The bad part is that using
>>>>> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the
>>>>> FDT
>>>>> results in a NULL command line, so I don't see any output. If I
>>>>> hardcode the
>>>>> command line in the kernel image, things work fine.
>>>>>
>>> Hi Will,
>>>
>>> Which kernel tree are you used? I tried latest mainline kernel (used
>>> vexpress_defconfig
>>> and vexpress-v2p-ca15_a7.dtb) without any modification, but it hangs as
>>> follows.
>> Just try 3.10 at the moment -- we're currently in the middle of the 
>> merge
>> window and I know that there is some timer breakage that people have 
>> been
>> talking about.
Forget to say, 3.10 kernel (vexpress_defconfig + 
vexpress-v2p-ca15_a7.dtb) still has
the same problem as the newest mainline kernel.

## Booting kernel from Legacy Image at 80000000 ...
    Image Name:   Linux-3.10.0
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2843016 Bytes = 2.7 MiB
    Load Address: 60008000
    Entry Point:  60008000
    Verifying Checksum ... OK
## Flattened Device Tree blob at 81f00000
    Booting using the fdt blob at 0x81f00000
    Loading Kernel Image ... OK
OK
    reserving fdt memory region: addr=ff000000 size=1000000
    Loading Device Tree to 9fee9000, end 9feee0a9 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpuset
Linux version 3.10.0 (gjiang at gjiang-desktop) (gcc version 4.6.3 
(Sourcery CodeBench Lite 2012.03-57) ) #2 SMP Tue Jul 9 17:56:53 CST 2013
CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine: ARM-Versatile Express, model: V2P-CA15_CA7
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writealloc
------------[ cut here ]------------
WARNING: at arch/arm/kernel/devtree.c:147 arm_dt_init_cpu_maps+0x134/0x1bc()
DT /cpu 5 nodes greater than max cores 4, capping them
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0 #2
[<80014e5c>] (unwind_backtrace+0x0/0xf8) from [<80011e94>] 
(show_stack+0x10/0x14)
[<80011e94>] (show_stack+0x10/0x14) from [<800209a8>] 
(warn_slowpath_common+0x54/0x68)
[<800209a8>] (warn_slowpath_common+0x54/0x68) from [<80020a50>] 
(warn_slowpath_fmt+0x30/0x40)
[<80020a50>] (warn_slowpath_fmt+0x30/0x40) from [<804cac80>] 
(arm_dt_init_cpu_maps+0x134/0x1bc)
[<804cac80>] (arm_dt_init_cpu_maps+0x134/0x1bc) from [<804ca190>] 
(setup_arch+0x658/0x6e4)
[<804ca190>] (setup_arch+0x658/0x6e4) from [<804c759c>] 
(start_kernel+0x90/0x30c)
[<804c759c>] (start_kernel+0x90/0x30c) from [<80008074>] (0x80008074)
---[ end trace 1b75b31a2719ed1c ]---
SMP: 5 cores greater than maximum (4), clipping
PERCPU: Embedded 7 pages/cpu @80d4f000 s7040 r8192 d13440 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: root=/dev/nfs console=ttyAMA0,38400n8 rw 
init=/linuxrc nfsroot=128.224.163.23:/home/gjiang/work/a15fs ip=dhcp 
earlyprintk
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1024MB = 1024MB total
Memory: 1034012k/1034012k available, 14564k reserved, 0K highmem
Virtual kernel memory layout:
     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
     modules : 0x7f000000 - 0x80000000   (  16 MB)
       .text : 0x80008000 - 0x804c6fe0   (4860 kB)
       .init : 0x804c7000 - 0x804f8b80   ( 199 kB)
       .data : 0x804fa000 - 0x80523780   ( 166 kB)
        .bss : 0x80523780 - 0x80545b7c   ( 137 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
Failed to obtain parent clocks for SP810!
sp804: arm,sp804 clock not found: -2
sp804: clock not found: -2
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
Console: colour dummy device 80x30
Calibrating delay loop...

Thanks,
Xiao



From broonie at kernel.org  Tue Jul  9 06:07:23 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Jul 2013 11:07:23 +0100
Subject: [PATCH 3/3] ARM:dts:vf610-twr:Enable DSPI0 devices and Flash
 at26df081a
In-Reply-To: <20130709052925.GD16656@S2101-09.ap.freescale.net>
References: <1373272622-29064-1-git-send-email-b44548@freescale.com>
 <1373272622-29064-3-git-send-email-b44548@freescale.com>
 <20130708113600.GU27646@sirena.org.uk>
 <20130709052925.GD16656@S2101-09.ap.freescale.net>
Message-ID: <20130709100723.GS27646@sirena.org.uk>

On Tue, Jul 09, 2013 at 01:29:27PM +0800, Shawn Guo wrote:
> On Mon, Jul 08, 2013 at 12:36:01PM +0100, Mark Brown wrote:

> > This should be fine to merge via arm-soc, it's no real dependency on the
> > actual SPI driver.

> It has dependency on the actual SPI driver where the DT bindings are
> defined, so I would only take the patches after the driver parts gets
> accepted.

The bindings are all totally generic ones for a SPI controller, there's
nothing controversial or even device specific about them so I'm happy to
say the bindings are fine as-is.
-------------- 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/20130709/06099851/attachment.sig>

From rnayak at ti.com  Tue Jul  9 06:14:58 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 9 Jul 2013 15:44:58 +0530
Subject: [PATCH 09/12] ARM: DRA7: hwmod: Create initial DRA7XX SoC data
In-Reply-To: <20130709083152.GC5523@atomide.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
 <1373355139-12487-10-git-send-email-rnayak@ti.com>
 <20130709083152.GC5523@atomide.com>
Message-ID: <51DBE2A2.2040403@ti.com>

On Tuesday 09 July 2013 02:01 PM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak at ti.com> [130709 00:39]:
>> From: Ambresh K <ambresh at ti.com>
> 
>> --- /dev/null
>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> ...
> 
>> +/* dma_system */
>> +static struct omap_hwmod_irq_info dra7xx_dma_system_irqs[] = {
>> +	{ .name = "0", .irq = 12 + DRA7XX_IRQ_GIC_START },
>> +	{ .name = "1", .irq = 13 + DRA7XX_IRQ_GIC_START },
>> +	{ .name = "2", .irq = 14 + DRA7XX_IRQ_GIC_START },
>> +	{ .name = "3", .irq = 15 + DRA7XX_IRQ_GIC_START },
>> +	{ .irq = -1 }
>> +};
> 
> I think these should no longer be needed?

These are needed only for dma because mach-omap2/dma.c still creates
devices from hmwod and which are used by plat/dma.c.
These irqs for sdma exist even in the cleaned up omap4 and omap5 hmwod files.
I'll try and get rid of that dependency of plat/dma on mach/dma to create devices.

> 
> In general, we must move the hwmod stuff to drivers/bus and start
> parsing the data from device tree along the lines Tero is doing
> for the clock data.

We already have irq/dma and iospace moved to DT (some iospace info still
exists because of non-DT drivers). With Teros patches to move clock data we
should be able to pass the main_clk and all interface level clock info too
from DT.

> 
> What's the plan for doing that?
> 
> Regards,
> 
> Tony
> 



From balbi at ti.com  Tue Jul  9 06:20:22 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 9 Jul 2013 13:20:22 +0300
Subject: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
In-Reply-To: <1373361446-30050-1-git-send-email-george.cherian@ti.com>
References: <1373361446-30050-1-git-send-email-george.cherian@ti.com>
Message-ID: <20130709102022.GH5552@arwen.pp.htv.fi>

On Tue, Jul 09, 2013 at 02:47:26PM +0530, George Cherian wrote:
> Adds device node for HS USB Host module for AM437x
> 
> changes from v1
> 
> renamed synopsis to snps
> removed flag tx-fifo-resize

the patch revision changes don't need to go to the commit log,
they should be placed after the tearline (---) and before the diffstat.

> Signed-off-by: George Cherian <george.cherian at ti.com>
> ---
>  arch/arm/boot/dts/am4372.dtsi | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index ddc1df7..c9e0da8 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -64,5 +64,23 @@
>  			compatible = "ti,am4372-counter32k","ti,omap-counter32k";
>  			reg = <0x44e86000 0x40>;
>  		};
> +
> +		usb_otg_hs1: am4372_dwc3 at 48380000 {

dtsi should always have status = "disabled"; no ?

> +			compatible = "ti,am437x-dwc3";
> +			reg = <0x48380000 0x1ff>;

weird size, shouldn't this be 0x200 ?

> +			interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			utmi-mode = <1>;
> +			ranges;
> +
> +			dwc3 at 48390000 {

dtsi should always have status = "disabled"; no ?

> +				compatible = "snps,dwc3";
> +				reg = <0x48390000 0xcfff>;

weird size, shouldn't this be 0xd000 then the size would be exactly
52KiB

> +				interrupts = <GIC_SPI  168 IRQ_TYPE_LEVEL_HIGH>;
> +			};
> +
> +		};
> +		

there two trailing tabs on this line.

Another thing: am437x has 4 instances of this IP, why are you adding
only one ? And why aren't you pasing the PHY nodes here ? The device
won't work without its PHYs.

-- 
balbi
-------------- 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/20130709/29ec9e9f/attachment.sig>

From elen.song at atmel.com  Tue Jul  9 06:24:44 2013
From: elen.song at atmel.com (elen.song)
Date: Tue, 9 Jul 2013 18:24:44 +0800
Subject: [PATCH 2/7] serial: at91: add tx dma support
In-Reply-To: <20130709095704.GE4013@ludovic.desroches@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
 <1373351626-30143-3-git-send-email-elen.song@atmel.com>
 <20130709095704.GE4013@ludovic.desroches@atmel.com>
Message-ID: <51DBE4EC.9090701@atmel.com>

On 7/9/2013 5:57 PM, Ludovic Desroches wrote:
> On Tue, Jul 09, 2013 at 02:33:41PM +0800, Elen Song wrote:
>
> [...]
>    
>> @@ -977,6 +1172,8 @@ static int atmel_startup(struct uart_port *port)
>>   		pdc->ofs = 0;
>>   	}
>>   
>> +	atmel_tx_request_dma(atmel_port);
>> +
>>   	/*
>>   	 * If there is a specific "open" function (to register
>>   	 * control line interrupts)
> Here we can have both use_pdc_tx and use_dma_tx set to true. To avoid this, we
> can do:
>
> if (atmel_use_pdc_tx(port)) {
>
> } else {
> 	atmel_tx_request_dma(atmel_port);
> }
>
> or force use_pdc_tx to 0 in atmel_tx_request_dma function when we set
> use_dma_tx to 1.
>
> I prefer the second one since using dma has a higher priority than using pdc
> contrary to the first one.
>

Well ,yes, I have a better idea:

In atmel_startup:
Move "atmel_tx_request_dma" forward, just before "if 
(atmel_use_pdc_rx(port))",
meanwhile, force use_pdc_tx to 0  when request a dma channel.

In this case, we will not go into "if (atmel_use_pdc_rx(port))" when dma 
and pdc both enable and
dma have higher priority.
> Regards
>
> Ludovic



From richard.genoud at gmail.com  Tue Jul  9 06:27:41 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 9 Jul 2013 12:27:41 +0200
Subject: [PATCH v2 1/5] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <20130709092917.GO27646@sirena.org.uk>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373290193-25300-2-git-send-email-richard.genoud@gmail.com>
 <20130708150721.GK27646@sirena.org.uk>
 <CACQ1gAgJyTSdxAKK7uwG-ybE2ddC90podM3+tOAqQwZUspsU8Q@mail.gmail.com>
 <20130709092917.GO27646@sirena.org.uk>
Message-ID: <CACQ1gAi6C8A-=sONar7jiXWbJM9_x_MGkFh--wD9fH97bV+YJg@mail.gmail.com>

2013/7/9 Mark Brown <broonie at kernel.org>:
> On Tue, Jul 09, 2013 at 10:19:45AM +0200, Richard Genoud wrote:
>> 2013/7/8 Mark Brown <broonie at kernel.org>:
>
>> > The obvious question here is of course if we can use the same driver for
>> > both of them.
>
>> I haven't got a g20 to test that, but that's the goal.
>
> I think I do somewhere.
>
>> For now, g20 is still non-DT, so I think it's best to have a DT-only
>> driver like this one for the 9x5 family (9g15, 9g25, 9x25, 9g35,
>> 9x25).
>> When the g20 will move to DT completely, we can drop sam9g20_wm8731.c
>> and adjust sam9x5_wm8731.c (mainly master clock and widgets it seems)
>> By the way, maybe g45 could use that also (and SAMA5 ?)
>
> If this is the goal then this driver needs a more generic name.
Hum. I guess we could call it atmel-ssc-sound.c, since the ultimate
goal would be to make it codec agnostic, but there's quite some work
to achieve that (handle the widgets, mclk and rates by DT).
But I really don't know if it's better to keep this name as long as
g20 is not supported, and change it after or have a name that is not
reflecting what the machine driver is doing right now.
Maybe Bo or Nicolas can give their feeling on that (since I'm not
Atmel, I don't know every SoC or what their Big Plan is for sound
machine drivers)

Richard.

-- 
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?


From afzal at ti.com  Tue Jul  9 06:32:19 2013
From: afzal at ti.com (Mohammed, Afzal)
Date: Tue, 9 Jul 2013 10:32:19 +0000
Subject: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
In-Reply-To: <1373361446-30050-1-git-send-email-george.cherian@ti.com>
References: <1373361446-30050-1-git-send-email-george.cherian@ti.com>
Message-ID: <C8443D0743D26F4388EA172BF4E2A7A93EB30355@DBDE04.ent.ti.com>

Hi George,

On Tue, Jul 09, 2013 at 14:47:26, Cherian, George wrote:

> +		usb_otg_hs1: am4372_dwc3 at 48380000 {

Wouldn't "usb" a better node name ?

> +			compatible = "ti,am437x-dwc3";

Usage of wild card is discouraged per DT documentation.

Regards
Afzal



From marex at denx.de  Tue Jul  9 06:38:44 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 9 Jul 2013 12:38:44 +0200
Subject: Chipidea usb otg support for IMX/MXS (device functionality)
In-Reply-To: <F281D0F91ED19E4D8E63A7504E8A649803F39B98@039-SN2MPN1-022.039d.mgd.msft.net>
References: <51A5A808.2070803@digi.com> <201307082256.38642.marex@denx.de>
 <F281D0F91ED19E4D8E63A7504E8A649803F39B98@039-SN2MPN1-022.039d.mgd.msft.net>
Message-ID: <201307091238.45019.marex@denx.de>

Hi Peter,
[...]

> 
> It needs to check your hardware, it is probably there is a high capacitance
> at vbus pin. Besides, the vbus should be lower than 0.8v if it is
> disconnected from pc.

I just wonder why I can no longer use device mode only after I plug in the 
adaptor for host device. Before that, I can plug in the device mode cable from 
PC all I want and this works. Then I plug in the host adaptor, that works as 
well , but if I plug in the device cable, this works no longer.

I rather suspect it might be something going on in the driver that's not right. 
I will check the hardware too, thanks.

Best regards,
Marek Vasut


From magnus.damm at gmail.com  Tue Jul  9 06:39:44 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 19:39:44 +0900
Subject: [PATCH 00/04] ARM: shmobile: Random header and makefile cleanups
Message-ID: <20130709103944.1891.67462.sendpatchset@w520>

ARM: shmobile: Random header and makefile cleanups

[PATCH 01/04] ARM: shmobile: No need to use INTC header on r8a7779
[PATCH 02/04] ARM: shmobile: Use pm-rmobile on sh7372 and r8a7740 only
[PATCH 03/04] ARM: shmobile: No need to use INTC demux on r8a7740
[PATCH 04/04] ARM: shmobile: Remove unused mach/dma.h

Remove pointless header files and unnecessary use of header files,
and only link in bits that are actually needed.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Built on top of renesas-next-20130704v2

 arch/arm/mach-shmobile/Makefile           |    8 +++-----
 arch/arm/mach-shmobile/include/mach/dma.h |    1 -
 arch/arm/mach-shmobile/intc-r8a7779.c     |    1 -
 arch/arm/mach-shmobile/setup-r8a7779.c    |    1 -
 4 files changed, 3 insertions(+), 8 deletions(-)


From magnus.damm at gmail.com  Tue Jul  9 06:39:52 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 19:39:52 +0900
Subject: [PATCH 01/04] ARM: shmobile: No need to use INTC header on r8a7779
In-Reply-To: <20130709103944.1891.67462.sendpatchset@w520>
References: <20130709103944.1891.67462.sendpatchset@w520>
Message-ID: <20130709103952.1891.92697.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Now when the intc-irqpin driver is used for external
IRQ pins on r8a7779 it possible to get rid of unused
INTC headers mach/intc.h and linux/sh_intc.h.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/intc-r8a7779.c  |    1 -
 arch/arm/mach-shmobile/setup-r8a7779.c |    1 -
 2 files changed, 2 deletions(-)

--- 0001/arch/arm/mach-shmobile/intc-r8a7779.c
+++ work/arch/arm/mach-shmobile/intc-r8a7779.c	2013-07-09 18:42:08.000000000 +0900
@@ -27,7 +27,6 @@
 #include <linux/platform_data/irq-renesas-intc-irqpin.h>
 #include <linux/irqchip.h>
 #include <mach/common.h>
-#include <mach/intc.h>
 #include <mach/irqs.h>
 #include <mach/r8a7779.h>
 #include <asm/mach-types.h>
--- 0001/arch/arm/mach-shmobile/setup-r8a7779.c
+++ work/arch/arm/mach-shmobile/setup-r8a7779.c	2013-07-09 18:42:25.000000000 +0900
@@ -29,7 +29,6 @@
 #include <linux/input.h>
 #include <linux/io.h>
 #include <linux/serial_sci.h>
-#include <linux/sh_intc.h>
 #include <linux/sh_timer.h>
 #include <linux/dma-mapping.h>
 #include <linux/usb/otg.h>


From magnus.damm at gmail.com  Tue Jul  9 06:40:01 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 19:40:01 +0900
Subject: [PATCH 02/04] ARM: shmobile: Use pm-rmobile on sh7372 and r8a7740 only
In-Reply-To: <20130709103944.1891.67462.sendpatchset@w520>
References: <20130709103944.1891.67462.sendpatchset@w520>
Message-ID: <20130709104001.1891.16375.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

The functions in pm-rmobile.c are only used on sh7372 and
r8a7740, so adjust the Makefile to only link in that file
in case those SoCs are selected.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/Makefile |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

--- 0001/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-07-09 18:50:08.000000000 +0900
@@ -28,11 +28,10 @@ obj-$(CONFIG_ARCH_R8A7740)	+= entry-intc
 # PM objects
 obj-$(CONFIG_SUSPEND)		+= suspend.o
 obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
-obj-$(CONFIG_ARCH_SHMOBILE)	+= pm-rmobile.o
-obj-$(CONFIG_ARCH_SH7372)	+= pm-sh7372.o sleep-sh7372.o
-obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o
-obj-$(CONFIG_ARCH_R8A7779)	+= pm-r8a7779.o
+obj-$(CONFIG_ARCH_SH7372)	+= pm-sh7372.o sleep-sh7372.o pm-rmobile.o
 obj-$(CONFIG_ARCH_SH73A0)	+= pm-sh73a0.o
+obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o pm-rmobile.o
+obj-$(CONFIG_ARCH_R8A7779)	+= pm-r8a7779.o
 
 # Board objects
 obj-$(CONFIG_MACH_AG5EVM)	+= board-ag5evm.o


From magnus.damm at gmail.com  Tue Jul  9 06:40:08 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 19:40:08 +0900
Subject: [PATCH 03/04] ARM: shmobile: No need to use INTC demux on r8a7740
In-Reply-To: <20130709103944.1891.67462.sendpatchset@w520>
References: <20130709103944.1891.67462.sendpatchset@w520>
Message-ID: <20130709104008.1891.17746.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Now when the r8a7740 code has been converted to make use of
GIC instead of INTC for root interrupt controller it is
possible to exclude the low level INTC demux function
shmobile_handle_irq_intc from linking. 

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/Makefile |    1 -
 1 file changed, 1 deletion(-)

--- 0003/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-07-09 18:54:03.000000000 +0900
@@ -23,7 +23,6 @@ smp-$(CONFIG_ARCH_EMEV2)	+= smp-emev2.o
 
 # IRQ objects
 obj-$(CONFIG_ARCH_SH7372)	+= entry-intc.o
-obj-$(CONFIG_ARCH_R8A7740)	+= entry-intc.o
 
 # PM objects
 obj-$(CONFIG_SUSPEND)		+= suspend.o


From magnus.damm at gmail.com  Tue Jul  9 06:40:16 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 19:40:16 +0900
Subject: [PATCH 04/04] ARM: shmobile: Remove unused mach/dma.h
In-Reply-To: <20130709103944.1891.67462.sendpatchset@w520>
References: <20130709103944.1891.67462.sendpatchset@w520>
Message-ID: <20130709104016.1891.68682.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove mach-shmobile mach/dma.h since it only
seems to be used on non-mach-shmobile platforms.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/include/mach/dma.h |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/include/mach/dma.h
+++ /dev/null	2013-06-03 21:41:10.638032047 +0900
@@ -1 +0,0 @@
-/* empty */


From haojian.zhuang at gmail.com  Tue Jul  9 06:41:46 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Tue, 9 Jul 2013 18:41:46 +0800
Subject: [V3 2/7] ARM: mmp: remove the legacy rbswap setting for ttc_dkb
 platform
In-Reply-To: <1372332524-6772-1-git-send-email-jtzhou@marvell.com>
References: <1372332524-6772-1-git-send-email-jtzhou@marvell.com>
Message-ID: <CAN1soZyfnPd4VBjhYUt8Lm=S+CKey2YVU8ZQRgO7KYsj=_J90A@mail.gmail.com>

On Thu, Jun 27, 2013 at 7:28 PM, Jett.Zhou <jtzhou at marvell.com> wrote:
> According to new rbswap scheme of mmp_display, it support appropriate
> rbswap setting based specific pix_fmt, then we can remove the legacy
> rbswap setting for ttc_dkb platform.
>
> Signed-off-by: Jett.Zhou <jtzhou at marvell.com>
> ---
>  arch/arm/mach-mmp/ttc_dkb.c |    4 +---
>  1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
> index 8483906..cb08485 100644
> --- a/arch/arm/mach-mmp/ttc_dkb.c
> +++ b/arch/arm/mach-mmp/ttc_dkb.c
> @@ -191,7 +191,6 @@ static struct pxa3xx_nand_platform_data dkb_nand_info = {
>  #define SCLK_SOURCE_SELECT(x)  (x << 30) /* 0x0 ~ 0x3 */
>  /* link config */
>  #define CFG_DUMBMODE(mode)     (mode << 28) /* 0x0 ~ 0x6*/
> -#define CFG_GRA_SWAPRB(x)      (x << 0) /* 1: rbswap enabled */
>  static struct mmp_mach_path_config dkb_disp_config[] = {
>         [0] = {
>                 .name = "mmp-parallel",
> @@ -199,8 +198,7 @@ static struct mmp_mach_path_config dkb_disp_config[] = {
>                 .output_type = PATH_OUT_PARALLEL,
>                 .path_config = CFG_IOPADMODE(0x1)
>                         | SCLK_SOURCE_SELECT(0x1),
> -               .link_config = CFG_DUMBMODE(0x2)
> -                       | CFG_GRA_SWAPRB(0x1),
> +               .link_config = CFG_DUMBMODE(0x2),
>         },
>  };
>
> --
> 1.7.0.4
>

Acked-by: Haojian Zhuang <haojian.zhuang at gmail.com>


From srinivas.kandagatla at st.com  Tue Jul  9 06:34:00 2013
From: srinivas.kandagatla at st.com (Srinivas KANDAGATLA)
Date: Tue, 09 Jul 2013 11:34:00 +0100
Subject: [PATCH v1 0/4] ARM: STi fixes and ethernet support
In-Reply-To: <201307090956.03191.arnd@arndb.de>
References: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
 <201307090118.06715.arnd@arndb.de> <51DBB629.1050000@st.com>
 <201307090956.03191.arnd@arndb.de>
Message-ID: <51DBE718.2080007@st.com>

On 09/07/13 08:56, Arnd Bergmann wrote:
> No, you should be using generic interfaces to do the things you need.
> 
> I believe what you are missing is an ethernet phy driver that is specific
> to your SoC.
It looks interesting way to solve the issue.

Did you mean "Ethernet PHY"?

Ethernet PHY is not integrated in the STiH41x SoC, We use an external
ICPLUS phy ( drivers/net/phy/icplus.c) for both B2000 and B2020 boards.
As we can't have  two Ethernet phy drivers at the same time, I think the
suggestion might not work in this case.

The callbacks in the mach level are setting up two SOC specific System
Configuration registers which configures the MAC (like PHY interface
selection, which is sampled during MAC reset assertion).

MAC used in STiH41x supports multiple PHY interfaces, so the PHY
interface selection is driven by external signals wired up to System
Configuration registers. The MAC driver is not aware of these System
Configuration registers. So for non-DT case, stmmac driver provided
callbacks to do things like this.

For DT case, At the moment I think callbacks at MACH level is one
possible solution. But am open for any discussions.


Thanks,
srini


> 
> 	Arnd



From magnus.damm at gmail.com  Tue Jul  9 06:46:16 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 19:46:16 +0900
Subject: [PATCH] ARM: shmobile: MULTIPLATFORM KZM9D with no clocks prototype
 hack
Message-ID: <20130709104616.1929.47755.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Ugly prototype hack to allow boot of KZM9D without clock framework
in case of ARCH_SHMOBILE_MULTI. Obviously not for upstream merge,
but may be useful for people working on common clock framework.

Not-even-remotely-signed-off-by: Magnus Damm <damm at opensource.se>
---

 drivers/clocksource/em_sti.c      |   14 ++++++++++----
 drivers/tty/serial/8250/8250_em.c |   13 ++++++++++---
 2 files changed, 20 insertions(+), 7 deletions(-)

--- 0001/drivers/clocksource/em_sti.c
+++ work/drivers/clocksource/em_sti.c	2013-07-09 13:04:04.000000000 +0900
@@ -77,6 +77,7 @@ static int em_sti_enable(struct em_sti_p
 {
 	int ret;
 
+#if 0
 	/* enable clock */
 	ret = clk_enable(p->clk);
 	if (ret) {
@@ -86,7 +87,9 @@ static int em_sti_enable(struct em_sti_p
 
 	/* configure channel, periodic mode and maximum timeout */
 	p->rate = clk_get_rate(p->clk);
-
+#else
+	p->rate = 32768;
+#endif
 	/* reset the counter */
 	em_sti_write(p, STI_SET_H, 0x40000000);
 	em_sti_write(p, STI_SET_L, 0x00000000);
@@ -105,9 +108,10 @@ static void em_sti_disable(struct em_sti
 {
 	/* mask interrupts */
 	em_sti_write(p, STI_INTENCLR, 3);
-
+#if 0
 	/* stop clock */
 	clk_disable(p->clk);
+#endif
 }
 
 static cycle_t em_sti_count(struct em_sti_priv *p)
@@ -348,7 +352,7 @@ static int em_sti_probe(struct platform_
 		ret = -ENXIO;
 		goto err0;
 	}
-
+#if 0
 	/* get hold of clock */
 	p->clk = clk_get(&pdev->dev, "sclk");
 	if (IS_ERR(p->clk)) {
@@ -356,7 +360,7 @@ static int em_sti_probe(struct platform_
 		ret = PTR_ERR(p->clk);
 		goto err1;
 	}
-
+#endif
 	if (request_irq(irq, em_sti_interrupt,
 			IRQF_TIMER | IRQF_IRQPOLL | IRQF_NOBALANCING,
 			dev_name(&pdev->dev), p)) {
@@ -371,7 +375,9 @@ static int em_sti_probe(struct platform_
 	return 0;
 
 err2:
+#if 0
 	clk_put(p->clk);
+#endif
 err1:
 	iounmap(p->base);
 err0:
--- 0001/drivers/tty/serial/8250/8250_em.c
+++ work/drivers/tty/serial/8250/8250_em.c	2013-07-09 13:04:04.000000000 +0900
@@ -108,14 +108,14 @@ static int serial8250_em_probe(struct pl
 		ret = -ENOMEM;
 		goto err0;
 	}
-
+#if 0
 	priv->sclk = clk_get(&pdev->dev, "sclk");
 	if (IS_ERR(priv->sclk)) {
 		dev_err(&pdev->dev, "unable to get clock\n");
 		ret = PTR_ERR(priv->sclk);
 		goto err1;
 	}
-
+#endif
 	memset(&up, 0, sizeof(up));
 	up.port.mapbase = regs->start;
 	up.port.irq = irq->start;
@@ -123,9 +123,12 @@ static int serial8250_em_probe(struct pl
 	up.port.flags = UPF_BOOT_AUTOCONF | UPF_FIXED_PORT | UPF_IOREMAP;
 	up.port.dev = &pdev->dev;
 	up.port.private_data = priv;
-
+#if 0
 	clk_enable(priv->sclk);
 	up.port.uartclk = clk_get_rate(priv->sclk);
+#else
+	up.port.uartclk = 114688000;
+#endif
 
 	up.port.iotype = UPIO_MEM32;
 	up.port.serial_in = serial8250_em_serial_in;
@@ -144,8 +147,10 @@ static int serial8250_em_probe(struct pl
 	return 0;
 
  err2:
+#if 0
 	clk_disable(priv->sclk);
 	clk_put(priv->sclk);
+#endif
  err1:
 	kfree(priv);
  err0:
@@ -157,8 +162,10 @@ static int serial8250_em_remove(struct p
 	struct serial8250_em_priv *priv = platform_get_drvdata(pdev);
 
 	serial8250_unregister_port(priv->line);
+#if 0
 	clk_disable(priv->sclk);
 	clk_put(priv->sclk);
+#endif
 	kfree(priv);
 	return 0;
 }


From shc_work at mail.ru  Tue Jul  9 07:18:36 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Tue, 09 Jul 2013 15:18:36 +0400
Subject: =?UTF-8?B?UmU6IFtQQVRDSF0gQVJNOiBkdHM6IGkuTVg1MTogQWRkIFdFSU0gbm9kZQ==?=
In-Reply-To: <20130709032731.GA16656@S2101-09.ap.freescale.net>
References: <1373094142-24173-1-git-send-email-shc_work@mail.ru>
 <1373257783.211316847@f137.mail.ru>
 <20130709032731.GA16656@S2101-09.ap.freescale.net>
Message-ID: <1373368716.383283965@f290.mail.ru>

> On Mon, Jul 08, 2013 at 08:29:43AM +0400, Alexander Shiyan wrote:
> > > > @@ -745,6 +745,23 @@
> > > >  				status = "disabled";
> > > >  			};
> > > >  
> > > > +			weim: weim at 83fda000 {
> > > > +				#address-cells = <2>;
> > > > +				#size-cells = <1>;
> > > > +				compatible = "fsl,imx51-weim";
> > > > +				reg = <0x83fda000 0x1000>;
> > > > +				clocks = <&clks 0>;
> > > 
> > > Is it correct?  I think there should be a physical clock for weim.
> > 
> > Yes, but properly clock for weim is missing in the clk subsystem,
> > so I think at this point it is OK. Adding a properly clock should be a separate patch.
> 
> I've seen emi_slow and emi_fast clocks implemented in clk-imx51-imx53.c.
> Neither is the clock for weim?

I reviewed the documentation, emi_fast clock is used for DDR, emi_slow for WEIM,
so will post the revised patch.
Thanks.

---

From george.cherian at ti.com  Tue Jul  9 07:21:35 2013
From: george.cherian at ti.com (George Cherian)
Date: Tue, 9 Jul 2013 16:51:35 +0530
Subject: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
In-Reply-To: <20130709102022.GH5552@arwen.pp.htv.fi>
References: <1373361446-30050-1-git-send-email-george.cherian@ti.com>
 <20130709102022.GH5552@arwen.pp.htv.fi>
Message-ID: <51DBF23F.20103@ti.com>

On 7/9/2013 3:50 PM, Felipe Balbi wrote:
> On Tue, Jul 09, 2013 at 02:47:26PM +0530, George Cherian wrote:
>> Adds device node for HS USB Host module for AM437x
>>
>> changes from v1
>>
>> renamed synopsis to snps
>> removed flag tx-fifo-resize
> the patch revision changes don't need to go to the commit log,
> they should be placed after the tearline (---) and before the diffstat.
>
>> Signed-off-by: George Cherian <george.cherian at ti.com>
>> ---
>>   arch/arm/boot/dts/am4372.dtsi | 18 ++++++++++++++++++
>>   1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
>> index ddc1df7..c9e0da8 100644
>> --- a/arch/arm/boot/dts/am4372.dtsi
>> +++ b/arch/arm/boot/dts/am4372.dtsi
>> @@ -64,5 +64,23 @@
>>   			compatible = "ti,am4372-counter32k","ti,omap-counter32k";
>>   			reg = <0x44e86000 0x40>;
>>   		};
>> +
>> +		usb_otg_hs1: am4372_dwc3 at 48380000 {
> dtsi should always have status = "disabled"; no ?
>
>> +			compatible = "ti,am437x-dwc3";
>> +			reg = <0x48380000 0x1ff>;
> weird size, shouldn't this be 0x200 ?
okay
>> +			interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +			utmi-mode = <1>;
>> +			ranges;
>> +
>> +			dwc3 at 48390000 {
> dtsi should always have status = "disabled"; no ?
okay
>
>> +				compatible = "snps,dwc3";
>> +				reg = <0x48390000 0xcfff>;
> weird size, shouldn't this be 0xd000 then the size would be exactly
> 52KiB

okay
>> +				interrupts = <GIC_SPI  168 IRQ_TYPE_LEVEL_HIGH>;
>> +			};
>> +
>> +		};
>> +		
> there two trailing tabs on this line.
>
> Another thing: am437x has 4 instances of this IP, why are you adding
> only one ?

AM437x has got only 2 instances. I have verified only one on HAPS so 
adding only one.

> And why aren't you pasing the PHY nodes here ? The device
> won't work without its PHYs.

Yes true, again in HAPS I  didnt have any PHY configuration to be done.
>


-- 
-George



From plagnioj at jcrosoft.com  Tue Jul  9 07:21:52 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 9 Jul 2013 13:21:52 +0200
Subject: [PATCH 1/7] serial: at91: correct definition from DMA to PDC
In-Reply-To: <20130709073155.GB4013@ludovic.desroches@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
 <1373351626-30143-2-git-send-email-elen.song@atmel.com>
 <20130709073155.GB4013@ludovic.desroches@atmel.com>
Message-ID: <20130709112152.GA18012@ns203013.ovh.net>

On 09:31 Tue 09 Jul     , Ludovic Desroches wrote:
> Hi Elen,
> 
> One comment below:
> 
> On Tue, Jul 09, 2013 at 02:33:40PM +0800, Elen Song wrote:
> 
> [...]
> 
> > diff --git a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> > index a49d9a1..82f45ec 100644
> > --- a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> > +++ b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> > @@ -8,8 +8,8 @@ Required properties:
> >  - interrupts: Should contain interrupt
> >  
> >  Optional properties:
> > -- atmel,use-dma-rx: use of PDC or DMA for receiving data
> > -- atmel,use-dma-tx: use of PDC or DMA for transmitting data
> > +- atmel,use-pdc-rx: use of PDC for receiving data
> > +- atmel,use-pdc-tx: use of PDC for transmitting data
> >  
> >  <chip> compatible description:
> >  - at91rm9200:  legacy USART support
> > @@ -19,9 +19,9 @@ Example:
> >  
> >  	usart0: serial at fff8c000 {
> >  		compatible = "atmel,at91sam9260-usart";
> > -		reg = <0xfff8c000 0x4000>;
> > -		interrupts = <7>;
> > -		atmel,use-dma-rx;
> > -		atmel,use-dma-tx;
> > +		reg = <0xfff8c000 0x200>;
> > +		interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;

> 
> Maybe put these changes into an other patch since it is not in relation with
> the purpose of your patch.
> 
> Moreover, I am not sure that macros should be used in the documentation. From
> the top of my head, there was a discussion about that and the status was to not
> use macros in documentation since it is Linux dependant.

yes you are right

Best Regards,
J.
> 
> > +		atmel,use-pdc-rx;
> > +		atmel,use-pdc-tx;
> >  	};
> >  
> 
> [...]


From plagnioj at jcrosoft.com  Tue Jul  9 07:22:38 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 9 Jul 2013 13:22:38 +0200
Subject: [PATCH 1/7] serial: at91: correct definition from DMA to PDC
In-Reply-To: <1373351626-30143-2-git-send-email-elen.song@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
 <1373351626-30143-2-git-send-email-elen.song@atmel.com>
Message-ID: <20130709112238.GB18012@ns203013.ovh.net>

On 14:33 Tue 09 Jul     , Elen Song wrote:
> The DMA is available since at91sam9x5 socs, before that, we use PDC.
> 
> Signed-off-by: Elen Song <elen.song at atmel.com>
> ---
>  Documentation/devicetree/bindings/serial/rs485.txt |    4 +-
>  .../devicetree/bindings/tty/serial/atmel-usart.txt |   12 ++--
>  arch/arm/boot/dts/at91rm9200.dtsi                  |   16 ++---
>  arch/arm/boot/dts/at91sam9260.dtsi                 |   24 +++----
>  arch/arm/boot/dts/at91sam9263.dtsi                 |   12 ++--
>  arch/arm/boot/dts/at91sam9g45.dtsi                 |   16 ++---
>  arch/arm/mach-at91/at91rm9200_devices.c            |   20 +++---
>  arch/arm/mach-at91/at91sam9260_devices.c           |   28 ++++----
>  arch/arm/mach-at91/at91sam9261_devices.c           |   16 ++---
>  arch/arm/mach-at91/at91sam9263_devices.c           |   16 ++---
>  arch/arm/mach-at91/at91sam9g45_devices.c           |   20 +++---
>  arch/arm/mach-at91/at91sam9rl_devices.c            |   20 +++---
>  drivers/tty/serial/atmel_serial.c                  |   74 ++++++++++----------
>  include/linux/platform_data/atmel.h                |    4 +-
>  14 files changed, 141 insertions(+), 141 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/serial/rs485.txt b/Documentation/devicetree/bindings/serial/rs485.txt
> index 1e753c6..7c8581e 100644
> --- a/Documentation/devicetree/bindings/serial/rs485.txt
> +++ b/Documentation/devicetree/bindings/serial/rs485.txt
> @@ -23,8 +23,8 @@ RS485 example for Atmel USART:
>  		compatible = "atmel,at91sam9260-usart";
>  		reg = <0xfff8c000 0x4000>;
>  		interrupts = <7>;
> -		atmel,use-dma-rx;
> -		atmel,use-dma-tx;
> +		atmel,use-pdc-rx;
> +		atmel,use-pdc-tx;

you break dt compatibility this is not acceptable

Best Regards,
J.
>  		linux,rs485-enabled-at-boot-time;
>  		rs485-rts-delay = <0 200>;		// in milliseconds
>  	};
> diff --git a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> index a49d9a1..82f45ec 100644
> --- a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> +++ b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> @@ -8,8 +8,8 @@ Required properties:
>  - interrupts: Should contain interrupt
>  
>  Optional properties:
> -- atmel,use-dma-rx: use of PDC or DMA for receiving data
> -- atmel,use-dma-tx: use of PDC or DMA for transmitting data
> +- atmel,use-pdc-rx: use of PDC for receiving data
> +- atmel,use-pdc-tx: use of PDC for transmitting data
>  
>  <chip> compatible description:
>  - at91rm9200:  legacy USART support
> @@ -19,9 +19,9 @@ Example:
>  
>  	usart0: serial at fff8c000 {
>  		compatible = "atmel,at91sam9260-usart";
> -		reg = <0xfff8c000 0x4000>;
> -		interrupts = <7>;
> -		atmel,use-dma-rx;
> -		atmel,use-dma-tx;
> +		reg = <0xfff8c000 0x200>;
> +		interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
> +		atmel,use-pdc-rx;
> +		atmel,use-pdc-tx;
>  	};
>  
> diff --git a/arch/arm/boot/dts/at91rm9200.dtsi b/arch/arm/boot/dts/at91rm9200.dtsi
> index 1fc645e..2dcef27 100644
> --- a/arch/arm/boot/dts/at91rm9200.dtsi
> +++ b/arch/arm/boot/dts/at91rm9200.dtsi
> @@ -537,8 +537,8 @@
>  				compatible = "atmel,at91rm9200-usart";
>  				reg = <0xfffc0000 0x200>;
>  				interrupts = <6 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_uart0>;
>  				status = "disabled";
> @@ -548,8 +548,8 @@
>  				compatible = "atmel,at91rm9200-usart";
>  				reg = <0xfffc4000 0x200>;
>  				interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_uart1>;
>  				status = "disabled";
> @@ -559,8 +559,8 @@
>  				compatible = "atmel,at91rm9200-usart";
>  				reg = <0xfffc8000 0x200>;
>  				interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_uart2>;
>  				status = "disabled";
> @@ -570,8 +570,8 @@
>  				compatible = "atmel,at91rm9200-usart";
>  				reg = <0xfffcc000 0x200>;
>  				interrupts = <23 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_uart3>;
>  				status = "disabled";
> diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
> index 899a7cf..1fcf6f6 100644
> --- a/arch/arm/boot/dts/at91sam9260.dtsi
> +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> @@ -475,8 +475,8 @@
>  				compatible = "atmel,at91sam9260-usart";
>  				reg = <0xfffb0000 0x200>;
>  				interrupts = <6 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_usart0>;
>  				status = "disabled";
> @@ -486,8 +486,8 @@
>  				compatible = "atmel,at91sam9260-usart";
>  				reg = <0xfffb4000 0x200>;
>  				interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_usart1>;
>  				status = "disabled";
> @@ -497,8 +497,8 @@
>  				compatible = "atmel,at91sam9260-usart";
>  				reg = <0xfffb8000 0x200>;
>  				interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_usart2>;
>  				status = "disabled";
> @@ -508,8 +508,8 @@
>  				compatible = "atmel,at91sam9260-usart";
>  				reg = <0xfffd0000 0x200>;
>  				interrupts = <23 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_usart3>;
>  				status = "disabled";
> @@ -519,8 +519,8 @@
>  				compatible = "atmel,at91sam9260-usart";
>  				reg = <0xfffd4000 0x200>;
>  				interrupts = <24 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_uart0>;
>  				status = "disabled";
> @@ -530,8 +530,8 @@
>  				compatible = "atmel,at91sam9260-usart";
>  				reg = <0xfffd8000 0x200>;
>  				interrupts = <25 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_uart1>;
>  				status = "disabled";
> diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
> index ff63811..eb1dac2 100644
> --- a/arch/arm/boot/dts/at91sam9263.dtsi
> +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> @@ -426,8 +426,8 @@
>  				compatible = "atmel,at91sam9260-usart";
>  				reg = <0xfff8c000 0x200>;
>  				interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_usart0>;
>  				status = "disabled";
> @@ -437,8 +437,8 @@
>  				compatible = "atmel,at91sam9260-usart";
>  				reg = <0xfff90000 0x200>;
>  				interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_usart1>;
>  				status = "disabled";
> @@ -448,8 +448,8 @@
>  				compatible = "atmel,at91sam9260-usart";
>  				reg = <0xfff94000 0x200>;
>  				interrupts = <9 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_usart2>;
>  				status = "disabled";
> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> index cb44bbb..13c7682 100644
> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> @@ -485,8 +485,8 @@
>  				compatible = "atmel,at91sam9260-usart";
>  				reg = <0xfff8c000 0x200>;
>  				interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_usart0>;
>  				status = "disabled";
> @@ -496,8 +496,8 @@
>  				compatible = "atmel,at91sam9260-usart";
>  				reg = <0xfff90000 0x200>;
>  				interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_usart1>;
>  				status = "disabled";
> @@ -507,8 +507,8 @@
>  				compatible = "atmel,at91sam9260-usart";
>  				reg = <0xfff94000 0x200>;
>  				interrupts = <9 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_usart2>;
>  				status = "disabled";
> @@ -518,8 +518,8 @@
>  				compatible = "atmel,at91sam9260-usart";
>  				reg = <0xfff98000 0x200>;
>  				interrupts = <10 IRQ_TYPE_LEVEL_HIGH 5>;
> -				atmel,use-dma-rx;
> -				atmel,use-dma-tx;
> +				atmel,use-pdc-rx;
> +				atmel,use-pdc-tx;
>  				pinctrl-names = "default";
>  				pinctrl-0 = <&pinctrl_usart3>;
>  				status = "disabled";
> diff --git a/arch/arm/mach-at91/at91rm9200_devices.c b/arch/arm/mach-at91/at91rm9200_devices.c
> index 3ebc979..6766d17 100644
> --- a/arch/arm/mach-at91/at91rm9200_devices.c
> +++ b/arch/arm/mach-at91/at91rm9200_devices.c
> @@ -920,8 +920,8 @@ static struct resource dbgu_resources[] = {
>  };
>  
>  static struct atmel_uart_data dbgu_data = {
> -	.use_dma_tx	= 0,
> -	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
> +	.use_pdc_tx	= 0,
> +	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
>  };
>  
>  static u64 dbgu_dmamask = DMA_BIT_MASK(32);
> @@ -958,8 +958,8 @@ static struct resource uart0_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart0_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart0_dmamask = DMA_BIT_MASK(32);
> @@ -1007,8 +1007,8 @@ static struct resource uart1_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart1_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart1_dmamask = DMA_BIT_MASK(32);
> @@ -1058,8 +1058,8 @@ static struct resource uart2_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart2_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart2_dmamask = DMA_BIT_MASK(32);
> @@ -1101,8 +1101,8 @@ static struct resource uart3_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart3_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart3_dmamask = DMA_BIT_MASK(32);
> diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
> index eda8d16..0a087a7c 100644
> --- a/arch/arm/mach-at91/at91sam9260_devices.c
> +++ b/arch/arm/mach-at91/at91sam9260_devices.c
> @@ -817,8 +817,8 @@ static struct resource dbgu_resources[] = {
>  };
>  
>  static struct atmel_uart_data dbgu_data = {
> -	.use_dma_tx	= 0,
> -	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
> +	.use_pdc_tx	= 0,
> +	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
>  };
>  
>  static u64 dbgu_dmamask = DMA_BIT_MASK(32);
> @@ -855,8 +855,8 @@ static struct resource uart0_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart0_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart0_dmamask = DMA_BIT_MASK(32);
> @@ -906,8 +906,8 @@ static struct resource uart1_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart1_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart1_dmamask = DMA_BIT_MASK(32);
> @@ -949,8 +949,8 @@ static struct resource uart2_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart2_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart2_dmamask = DMA_BIT_MASK(32);
> @@ -992,8 +992,8 @@ static struct resource uart3_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart3_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart3_dmamask = DMA_BIT_MASK(32);
> @@ -1035,8 +1035,8 @@ static struct resource uart4_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart4_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart4_dmamask = DMA_BIT_MASK(32);
> @@ -1073,8 +1073,8 @@ static struct resource uart5_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart5_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart5_dmamask = DMA_BIT_MASK(32);
> diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c
> index 629ea5f..fcaae28 100644
> --- a/arch/arm/mach-at91/at91sam9261_devices.c
> +++ b/arch/arm/mach-at91/at91sam9261_devices.c
> @@ -878,8 +878,8 @@ static struct resource dbgu_resources[] = {
>  };
>  
>  static struct atmel_uart_data dbgu_data = {
> -	.use_dma_tx	= 0,
> -	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
> +	.use_pdc_tx	= 0,
> +	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
>  };
>  
>  static u64 dbgu_dmamask = DMA_BIT_MASK(32);
> @@ -916,8 +916,8 @@ static struct resource uart0_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart0_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart0_dmamask = DMA_BIT_MASK(32);
> @@ -959,8 +959,8 @@ static struct resource uart1_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart1_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart1_dmamask = DMA_BIT_MASK(32);
> @@ -1002,8 +1002,8 @@ static struct resource uart2_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart2_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart2_dmamask = DMA_BIT_MASK(32);
> diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
> index 858c8aa..a62216b 100644
> --- a/arch/arm/mach-at91/at91sam9263_devices.c
> +++ b/arch/arm/mach-at91/at91sam9263_devices.c
> @@ -1322,8 +1322,8 @@ static struct resource dbgu_resources[] = {
>  };
>  
>  static struct atmel_uart_data dbgu_data = {
> -	.use_dma_tx	= 0,
> -	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
> +	.use_pdc_tx	= 0,
> +	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
>  };
>  
>  static u64 dbgu_dmamask = DMA_BIT_MASK(32);
> @@ -1360,8 +1360,8 @@ static struct resource uart0_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart0_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart0_dmamask = DMA_BIT_MASK(32);
> @@ -1403,8 +1403,8 @@ static struct resource uart1_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart1_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart1_dmamask = DMA_BIT_MASK(32);
> @@ -1446,8 +1446,8 @@ static struct resource uart2_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart2_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart2_dmamask = DMA_BIT_MASK(32);
> diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
> index acb703e..4c81fd1 100644
> --- a/arch/arm/mach-at91/at91sam9g45_devices.c
> +++ b/arch/arm/mach-at91/at91sam9g45_devices.c
> @@ -1585,8 +1585,8 @@ static struct resource dbgu_resources[] = {
>  };
>  
>  static struct atmel_uart_data dbgu_data = {
> -	.use_dma_tx	= 0,
> -	.use_dma_rx	= 0,
> +	.use_pdc_tx	= 0,
> +	.use_pdc_rx	= 0,
>  };
>  
>  static u64 dbgu_dmamask = DMA_BIT_MASK(32);
> @@ -1623,8 +1623,8 @@ static struct resource uart0_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart0_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart0_dmamask = DMA_BIT_MASK(32);
> @@ -1666,8 +1666,8 @@ static struct resource uart1_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart1_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart1_dmamask = DMA_BIT_MASK(32);
> @@ -1709,8 +1709,8 @@ static struct resource uart2_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart2_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart2_dmamask = DMA_BIT_MASK(32);
> @@ -1752,8 +1752,8 @@ static struct resource uart3_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart3_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart3_dmamask = DMA_BIT_MASK(32);
> diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
> index 352468f..5cd8c76 100644
> --- a/arch/arm/mach-at91/at91sam9rl_devices.c
> +++ b/arch/arm/mach-at91/at91sam9rl_devices.c
> @@ -954,8 +954,8 @@ static struct resource dbgu_resources[] = {
>  };
>  
>  static struct atmel_uart_data dbgu_data = {
> -	.use_dma_tx	= 0,
> -	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
> +	.use_pdc_tx	= 0,
> +	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
>  };
>  
>  static u64 dbgu_dmamask = DMA_BIT_MASK(32);
> @@ -992,8 +992,8 @@ static struct resource uart0_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart0_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart0_dmamask = DMA_BIT_MASK(32);
> @@ -1043,8 +1043,8 @@ static struct resource uart1_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart1_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart1_dmamask = DMA_BIT_MASK(32);
> @@ -1086,8 +1086,8 @@ static struct resource uart2_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart2_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart2_dmamask = DMA_BIT_MASK(32);
> @@ -1129,8 +1129,8 @@ static struct resource uart3_resources[] = {
>  };
>  
>  static struct atmel_uart_data uart3_data = {
> -	.use_dma_tx	= 1,
> -	.use_dma_rx	= 1,
> +	.use_pdc_tx	= 1,
> +	.use_pdc_rx	= 1,
>  };
>  
>  static u64 uart3_dmamask = DMA_BIT_MASK(32);
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 3467462..ab9de8a 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -140,11 +140,11 @@ struct atmel_uart_port {
>  	u32			backup_imr;	/* IMR saved during suspend */
>  	int			break_active;	/* break being received */
>  
> -	short			use_dma_rx;	/* enable PDC receiver */
> +	short			use_pdc_rx;	/* enable PDC receiver */
>  	short			pdc_rx_idx;	/* current PDC RX buffer */
>  	struct atmel_dma_buffer	pdc_rx[2];	/* PDC receier */
>  
> -	short			use_dma_tx;	/* enable PDC transmitter */
> +	short			use_pdc_tx;	/* enable PDC transmitter */
>  	struct atmel_dma_buffer	pdc_tx;		/* PDC transmitter */
>  
>  	struct tasklet_struct	tasklet;
> @@ -181,26 +181,26 @@ to_atmel_uart_port(struct uart_port *uart)
>  }
>  
>  #ifdef CONFIG_SERIAL_ATMEL_PDC
> -static bool atmel_use_dma_rx(struct uart_port *port)
> +static bool atmel_use_pdc_rx(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  
> -	return atmel_port->use_dma_rx;
> +	return atmel_port->use_pdc_rx;
>  }
>  
> -static bool atmel_use_dma_tx(struct uart_port *port)
> +static bool atmel_use_pdc_tx(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  
> -	return atmel_port->use_dma_tx;
> +	return atmel_port->use_pdc_tx;
>  }
>  #else
> -static bool atmel_use_dma_rx(struct uart_port *port)
> +static bool atmel_use_pdc_rx(struct uart_port *port)
>  {
>  	return false;
>  }
>  
> -static bool atmel_use_dma_tx(struct uart_port *port)
> +static bool atmel_use_pdc_tx(struct uart_port *port)
>  {
>  	return false;
>  }
> @@ -233,7 +233,7 @@ void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
>  		mode |= ATMEL_US_USMODE_RS485;
>  	} else {
>  		dev_dbg(port->dev, "Setting UART to RS232\n");
> -		if (atmel_use_dma_tx(port))
> +		if (atmel_use_pdc_tx(port))
>  			atmel_port->tx_done_mask = ATMEL_US_ENDTX |
>  				ATMEL_US_TXBUFE;
>  		else
> @@ -345,7 +345,7 @@ static void atmel_stop_tx(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  
> -	if (atmel_use_dma_tx(port)) {
> +	if (atmel_use_pdc_tx(port)) {
>  		/* disable PDC transmit */
>  		UART_PUT_PTCR(port, ATMEL_PDC_TXTDIS);
>  	}
> @@ -364,7 +364,7 @@ static void atmel_start_tx(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  
> -	if (atmel_use_dma_tx(port)) {
> +	if (atmel_use_pdc_tx(port)) {
>  		if (UART_GET_PTSR(port) & ATMEL_PDC_TXTEN)
>  			/* The transmitter is already running.  Yes, we
>  			   really need this.*/
> @@ -390,7 +390,7 @@ static void atmel_start_rx(struct uart_port *port)
>  
>  	UART_PUT_CR(port, ATMEL_US_RXEN);
>  
> -	if (atmel_use_dma_rx(port)) {
> +	if (atmel_use_pdc_rx(port)) {
>  		/* enable PDC controller */
>  		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
>  			port->read_status_mask);
> @@ -407,7 +407,7 @@ static void atmel_stop_rx(struct uart_port *port)
>  {
>  	UART_PUT_CR(port, ATMEL_US_RXDIS);
>  
> -	if (atmel_use_dma_rx(port)) {
> +	if (atmel_use_pdc_rx(port)) {
>  		/* disable PDC receive */
>  		UART_PUT_PTCR(port, ATMEL_PDC_RXTDIS);
>  		UART_PUT_IDR(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
> @@ -572,7 +572,7 @@ atmel_handle_receive(struct uart_port *port, unsigned int pending)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  
> -	if (atmel_use_dma_rx(port)) {
> +	if (atmel_use_pdc_rx(port)) {
>  		/*
>  		 * PDC receive. Just schedule the tasklet and let it
>  		 * figure out the details.
> @@ -661,7 +661,7 @@ static irqreturn_t atmel_interrupt(int irq, void *dev_id)
>  /*
>   * Called from tasklet with ENDTX and TXBUFE interrupts disabled.
>   */
> -static void atmel_tx_dma(struct uart_port *port)
> +static void atmel_tx_pdc(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  	struct circ_buf *xmit = &port->state->xmit;
> @@ -778,7 +778,7 @@ static void atmel_rx_from_ring(struct uart_port *port)
>  	spin_lock(&port->lock);
>  }
>  
> -static void atmel_rx_from_dma(struct uart_port *port)
> +static void atmel_rx_from_pdc(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  	struct tty_port *tport = &port->state->port;
> @@ -868,8 +868,8 @@ static void atmel_tasklet_func(unsigned long data)
>  	/* The interrupt handler does not take the lock */
>  	spin_lock(&port->lock);
>  
> -	if (atmel_use_dma_tx(port))
> -		atmel_tx_dma(port);
> +	if (atmel_use_pdc_tx(port))
> +		atmel_tx_pdc(port);
>  	else
>  		atmel_tx_chars(port);
>  
> @@ -893,8 +893,8 @@ static void atmel_tasklet_func(unsigned long data)
>  		atmel_port->irq_status_prev = status;
>  	}
>  
> -	if (atmel_use_dma_rx(port))
> -		atmel_rx_from_dma(port);
> +	if (atmel_use_pdc_rx(port))
> +		atmel_rx_from_pdc(port);
>  	else
>  		atmel_rx_from_ring(port);
>  
> @@ -930,7 +930,7 @@ static int atmel_startup(struct uart_port *port)
>  	/*
>  	 * Initialize DMA (if necessary)
>  	 */
> -	if (atmel_use_dma_rx(port)) {
> +	if (atmel_use_pdc_rx(port)) {
>  		int i;
>  
>  		for (i = 0; i < 2; i++) {
> @@ -964,7 +964,7 @@ static int atmel_startup(struct uart_port *port)
>  		UART_PUT_RNPR(port, atmel_port->pdc_rx[1].dma_addr);
>  		UART_PUT_RNCR(port, PDC_BUFFER_SIZE);
>  	}
> -	if (atmel_use_dma_tx(port)) {
> +	if (atmel_use_pdc_tx(port)) {
>  		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
>  		struct circ_buf *xmit = &port->state->xmit;
>  
> @@ -1000,7 +1000,7 @@ static int atmel_startup(struct uart_port *port)
>  	/* enable xmit & rcvr */
>  	UART_PUT_CR(port, ATMEL_US_TXEN | ATMEL_US_RXEN);
>  
> -	if (atmel_use_dma_rx(port)) {
> +	if (atmel_use_pdc_rx(port)) {
>  		/* set UART timeout */
>  		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
>  		UART_PUT_CR(port, ATMEL_US_STTTO);
> @@ -1031,7 +1031,7 @@ static void atmel_shutdown(struct uart_port *port)
>  	/*
>  	 * Shut-down the DMA.
>  	 */
> -	if (atmel_use_dma_rx(port)) {
> +	if (atmel_use_pdc_rx(port)) {
>  		int i;
>  
>  		for (i = 0; i < 2; i++) {
> @@ -1044,7 +1044,7 @@ static void atmel_shutdown(struct uart_port *port)
>  			kfree(pdc->buf);
>  		}
>  	}
> -	if (atmel_use_dma_tx(port)) {
> +	if (atmel_use_pdc_tx(port)) {
>  		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
>  
>  		dma_unmap_single(port->dev,
> @@ -1080,7 +1080,7 @@ static void atmel_flush_buffer(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  
> -	if (atmel_use_dma_tx(port)) {
> +	if (atmel_use_pdc_tx(port)) {
>  		UART_PUT_TCR(port, 0);
>  		atmel_port->pdc_tx.ofs = 0;
>  	}
> @@ -1193,7 +1193,7 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
>  	if (termios->c_iflag & (BRKINT | PARMRK))
>  		port->read_status_mask |= ATMEL_US_RXBRK;
>  
> -	if (atmel_use_dma_rx(port))
> +	if (atmel_use_pdc_rx(port))
>  		/* need to enable error interrupts */
>  		UART_PUT_IER(port, port->read_status_mask);
>  
> @@ -1429,14 +1429,14 @@ static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
>  	u32 rs485_delay[2];
>  
>  	/* DMA/PDC usage specification */
> -	if (of_get_property(np, "atmel,use-dma-rx", NULL))
> -		atmel_port->use_dma_rx	= 1;
> +	if (of_get_property(np, "atmel,use-pdc-rx", NULL))
> +		atmel_port->use_pdc_rx	= 1;
>  	else
> -		atmel_port->use_dma_rx	= 0;
> -	if (of_get_property(np, "atmel,use-dma-tx", NULL))
> -		atmel_port->use_dma_tx	= 1;
> +		atmel_port->use_pdc_rx	= 0;
> +	if (of_get_property(np, "atmel,use-pdc-tx", NULL))
> +		atmel_port->use_pdc_tx	= 1;
>  	else
> -		atmel_port->use_dma_tx	= 0;
> +		atmel_port->use_pdc_tx	= 0;
>  
>  	/* rs485 properties */
>  	if (of_property_read_u32_array(np, "rs485-rts-delay",
> @@ -1467,8 +1467,8 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
>  	if (pdev->dev.of_node) {
>  		atmel_of_init_port(atmel_port, pdev->dev.of_node);
>  	} else {
> -		atmel_port->use_dma_rx	= pdata->use_dma_rx;
> -		atmel_port->use_dma_tx	= pdata->use_dma_tx;
> +		atmel_port->use_pdc_rx	= pdata->use_pdc_rx;
> +		atmel_port->use_pdc_tx	= pdata->use_pdc_tx;
>  		atmel_port->rs485	= pdata->rs485;
>  	}
>  
> @@ -1505,7 +1505,7 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
>  	/* Use TXEMPTY for interrupt when rs485 else TXRDY or ENDTX|TXBUFE */
>  	if (atmel_port->rs485.flags & SER_RS485_ENABLED)
>  		atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
> -	else if (atmel_use_dma_tx(port)) {
> +	else if (atmel_use_pdc_tx(port)) {
>  		port->fifosize = PDC_BUFFER_SIZE;
>  		atmel_port->tx_done_mask = ATMEL_US_ENDTX | ATMEL_US_TXBUFE;
>  	} else {
> @@ -1794,7 +1794,7 @@ static int atmel_serial_probe(struct platform_device *pdev)
>  		goto err;
>  	}
>  
> -	if (!atmel_use_dma_rx(&port->uart)) {
> +	if (!atmel_use_pdc_rx(&port->uart)) {
>  		ret = -ENOMEM;
>  		data = kmalloc(sizeof(struct atmel_uart_char)
>  				* ATMEL_SERIAL_RINGSIZE, GFP_KERNEL);
> diff --git a/include/linux/platform_data/atmel.h b/include/linux/platform_data/atmel.h
> index 6a293b7..8965fed 100644
> --- a/include/linux/platform_data/atmel.h
> +++ b/include/linux/platform_data/atmel.h
> @@ -76,8 +76,8 @@ struct atmel_nand_data {
>   /* Serial */
>  struct atmel_uart_data {
>  	int			num;		/* port num */
> -	short			use_dma_tx;	/* use transmit DMA? */
> -	short			use_dma_rx;	/* use receive DMA? */
> +	short			use_pdc_tx;	/* use transmit PDC? */
> +	short			use_pdc_rx;	/* use receive PDC? */
>  	void __iomem		*regs;		/* virt. base address, if any */
>  	struct serial_rs485	rs485;		/* rs485 settings */
>  };
> -- 
> 1.7.9.5
> 


From plagnioj at jcrosoft.com  Tue Jul  9 07:25:00 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 9 Jul 2013 13:25:00 +0200
Subject: [PATCH 5/7] serial: at91: distinguish usart and uart
In-Reply-To: <1373351626-30143-6-git-send-email-elen.song@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
 <1373351626-30143-6-git-send-email-elen.song@atmel.com>
Message-ID: <20130709112500.GC18012@ns203013.ovh.net>

On 14:33 Tue 09 Jul     , Elen Song wrote:
> Distinguish usart and uart by read ip name register,
> dbgu regards as uart.
> 
> Signed-off-by: Elen Song <elen.song at atmel.com>
> ---
>  drivers/tty/serial/atmel_serial.c |   35 +++++++++++++++++++++++++++++++++++
>  include/linux/atmel_serial.h      |    2 ++
>  2 files changed, 37 insertions(+)
> 
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 52beb7e..5762244 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -99,6 +99,7 @@ static void atmel_stop_rx(struct uart_port *port);
>  #define UART_PUT_BRGR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_BRGR)
>  #define UART_PUT_RTOR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_RTOR)
>  #define UART_PUT_TTGR(port, v)	__raw_writel(v, (port)->membase + ATMEL_US_TTGR)
> +#define UART_GET_IP_NAME(port)	__raw_readl((port)->membase + ATMEL_US_NAME)
>  
>   /* PDC registers */
>  #define UART_PUT_PTCR(port,v)	__raw_writel(v, (port)->membase + ATMEL_PDC_PTCR)
> @@ -169,6 +170,7 @@ struct atmel_uart_port {
>  	struct serial_rs485	rs485;		/* rs485 settings */
>  	unsigned int		tx_done_mask;
>  	struct timer_list 	uart_timer;	/* dbgu timer */
> +	bool			is_usart;	/* usart or uart */
>  };
>  
>  static struct atmel_uart_port atmel_ports[ATMEL_MAX_UART];
> @@ -1328,6 +1330,34 @@ static void atmel_tasklet_func(unsigned long data)
>  }
>  
>  /*
> + * Get ip name usart or uart
> + */
> +static inline unsigned int atmel_get_ip_name(struct uart_port *port)
> +{
> +	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> +	unsigned int name = cpu_to_be32(UART_GET_IP_NAME(port));
> +	char *ip_name = (char *)&name;
> +	char *usart = "USAR";
> +	char *uart = "DBGU";
> +
> +	atmel_port->is_usart = false;
> +
> +	/* USAR is regards as usart, DBGU is regards as uart */
> +	if (!strncmp(ip_name, usart, 4)) {
> +		dev_dbg(port->dev, "This is usart\n");
> +		atmel_port->is_usart = true;
> +	} else if (!strncmp(ip_name, uart, 4)) {
> +		dev_dbg(port->dev, "This is uart\n");
> +		atmel_port->is_usart = false;
do not use string just value
> +	} else {
> +		dev_err(port->dev, "Not supported ip name, set to uart\n");
> +		return -EINVAL;
> +	}

> +
> +	return 0;
> +}
> +
> +/*
>   * Perform initialization and enable port for reception
>   */
>  static int atmel_startup(struct uart_port *port)
> @@ -1354,6 +1384,11 @@ static int atmel_startup(struct uart_port *port)
>  	}
>  
>  	/*
> +	 * Get port name of usart or uart
> +	 */
> +	atmel_get_ip_name(port);
> +
> +	/*
>  	 * Initialize DMA (if necessary)
>  	 */
>  	if (atmel_use_pdc_rx(port)) {
> diff --git a/include/linux/atmel_serial.h b/include/linux/atmel_serial.h
> index fd68337..be201ca 100644
> --- a/include/linux/atmel_serial.h
> +++ b/include/linux/atmel_serial.h
> @@ -124,4 +124,6 @@
>  #define ATMEL_US_NER		0x44			/* Number of Errors Register */
>  #define ATMEL_US_IF		0x4c			/* IrDA Filter Register */
>  
> +#define ATMEL_US_NAME		0xf0			/* Ip Name */
> +
>  #endif
> -- 
> 1.7.9.5
> 


From balbi at ti.com  Tue Jul  9 07:27:51 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 9 Jul 2013 14:27:51 +0300
Subject: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
In-Reply-To: <51DBF23F.20103@ti.com>
References: <1373361446-30050-1-git-send-email-george.cherian@ti.com>
 <20130709102022.GH5552@arwen.pp.htv.fi> <51DBF23F.20103@ti.com>
Message-ID: <20130709112751.GI5552@arwen.pp.htv.fi>

Hi,

On Tue, Jul 09, 2013 at 04:51:35PM +0530, George Cherian wrote:
> >>+				compatible = "snps,dwc3";
> >>+				reg = <0x48390000 0xcfff>;
> >weird size, shouldn't this be 0xd000 then the size would be exactly
> >52KiB
> 
> okay

btw, the reason here is that when you call devm_ioremap_resource(), that
will call resource_size() which does:

	size = res->end - res->start - 1;

so you need this extra 1 on the size when passing it via DT.

> >Another thing: am437x has 4 instances of this IP, why are you adding
> >only one ?
> 
> AM437x has got only 2 instances. I have verified only one on HAPS so
> adding only one.

weird, on my TRM I see for dwc3 but 2 PHYs.

> >And why aren't you pasing the PHY nodes here ? The device
> >won't work without its PHYs.
> 
> Yes true, again in HAPS I  didnt have any PHY configuration to be done.

alright, but we should still pass the PHY right ? once silicon comes,
we want this to work without any further changers.

-- 
balbi
-------------- 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/20130709/0b64e433/attachment.sig>

From balbi at ti.com  Tue Jul  9 07:34:14 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 9 Jul 2013 14:34:14 +0300
Subject: [PATCH v3 4/4] USB: OMAP1: Tahvo USB transceiver driver
In-Reply-To: <20130708194402.GA8516@blackmetal.musicnaut.iki.fi>
References: <1371575221-360-1-git-send-email-aaro.koskinen@iki.fi>
 <1371575221-360-5-git-send-email-aaro.koskinen@iki.fi>
 <20130708072109.GA16635@arwen.pp.htv.fi>
 <20130708194402.GA8516@blackmetal.musicnaut.iki.fi>
Message-ID: <20130709113414.GK5552@arwen.pp.htv.fi>

Hi,

On Mon, Jul 08, 2013 at 10:44:02PM +0300, Aaro Koskinen wrote:
> > > +static void tahvo_usb_become_host(struct tahvo_usb *tu)
> > > +{
> > > +	struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
> > > +
> > > +	extcon_set_cable_state(&tu->extcon, "USB-HOST", true);
> > > +
> > > +	/* Power up the transceiver in USB host mode */
> > > +	retu_write(rdev, TAHVO_REG_USBR, USBR_REGOUT | USBR_NSUSPEND |
> > > +		   USBR_MASTER_SW2 | USBR_MASTER_SW1);
> > > +	tu->phy.state = OTG_STATE_A_IDLE;
> > > +
> > > +	check_vbus_state(tu);
> > > +}
> > > +
> > > +static void tahvo_usb_stop_host(struct tahvo_usb *tu)
> > > +{
> > > +	tu->phy.state = OTG_STATE_A_IDLE;
> > 
> > shouldn't you undo tahvo_usb_become_host() here ? I mean, set the
> > transceiver to SLAVE ?
> 
> tahvo_usb_become_peripheral() (or power_off) is always called after this
> function. Actually, these stop functions can be eliminated altogether
> as they are only called from a single place...

alright, I guess GCC is already inlining them anyway, your choice.

> > > +static int tahvo_usb_set_host(struct usb_otg *otg, struct usb_bus *host)
> > > +{
> > > +	struct tahvo_usb *tu = container_of(otg->phy, struct tahvo_usb, phy);
> > > +
> > > +	dev_dbg(&tu->pt_dev->dev, "%s %p\n", __func__, host);
> > > +
> > > +	if (otg == NULL)
> > > +		return -ENODEV;
> > > +
> > > +	mutex_lock(&tu->serialize);
> > > +
> > > +	if (host == NULL) {
> > > +		if (tu->tahvo_mode == TAHVO_MODE_HOST)
> > > +			tahvo_usb_power_off(tu);
> > > +		otg->host = NULL;
> > > +		mutex_unlock(&tu->serialize);
> > > +		return 0;
> > > +	}
> > > +
> > > +	if (tu->tahvo_mode == TAHVO_MODE_HOST) {
> > > +		otg->host = NULL;
> > > +		tahvo_usb_become_host(tu);
> > > +	}
> > > +
> > > +	otg->host = host;
> > > +
> > > +	mutex_unlock(&tu->serialize);
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int tahvo_usb_set_peripheral(struct usb_otg *otg,
> > > +				    struct usb_gadget *gadget)
> > 
> > I want to get rid of the extra 'gadget' and 'host' parameters on
> > ->set_host() and ->set_peripheral(). Nobody really uses them other than:
> > 
> > my_phy->phy.otg->{gadget,host} = {gadget,host};
> > 
> > For that, I need all other PHYs to stop relying on those parameters and
> > I'll cook patches for that for v3.12 merge window.
> 
> How will the PHY know if there is a host/gadget driver present? I guess
> I will need to wait for those patches...

It won't. We're assuming that if the link asks to become a host, it
should already know that there is a host side available :-)

> > > +static int tahvo_usb_probe(struct platform_device *pdev)
> > > +{
> > > +	struct retu_dev *rdev = dev_get_drvdata(pdev->dev.parent);
> > > +	struct tahvo_usb *tu;
> > > +	int ret;
> > > +
> > > +	tu = devm_kzalloc(&pdev->dev, sizeof(*tu), GFP_KERNEL);
> > > +	if (!tu)
> > > +		return -ENOMEM;
> > > +
> > > +	tu->phy.otg = devm_kzalloc(&pdev->dev, sizeof(*tu->phy.otg),
> > > +				   GFP_KERNEL);
> > > +	if (!tu->phy.otg)
> > > +		return -ENOMEM;
> > > +
> > > +	tu->pt_dev = pdev;
> > > +
> > > +	/* Default mode */
> > > +#ifdef CONFIG_TAHVO_USB_HOST_BY_DEFAULT
> > > +	tu->tahvo_mode = TAHVO_MODE_HOST;
> > > +#else
> > > +	tu->tahvo_mode = TAHVO_MODE_PERIPHERAL;
> > > +#endif
> > 
> > should you call become_host()/become_peripheral() here ?
> 
> Not needed. Once the PHY is registered, the framework will call set_host /
> set_peripheral and the HW gets set to correct state.

ok good, thanks

> > /Could also use devm_request_threaded_irq()
> 
> Does not really help much, since the IRQ has to be freed manually anyway
> (to ensure it's disabled before usb_remove_phy(); also looks like it's
> currently enabled too early...).

you miss a free() in the error path. Switching to
devm_request_threaded_irq() would save you the trouble of having to call
that explicitly.

-- 
balbi
-------------- 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/20130709/213b3138/attachment.sig>

From tony at atomide.com  Tue Jul  9 07:36:57 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Jul 2013 04:36:57 -0700
Subject: [PATCH 09/12] ARM: DRA7: hwmod: Create initial DRA7XX SoC data
In-Reply-To: <51DBE2A2.2040403@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
 <1373355139-12487-10-git-send-email-rnayak@ti.com>
 <20130709083152.GC5523@atomide.com> <51DBE2A2.2040403@ti.com>
Message-ID: <20130709113657.GF5523@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130709 03:21]:
> On Tuesday 09 July 2013 02:01 PM, Tony Lindgren wrote:
> > * Rajendra Nayak <rnayak at ti.com> [130709 00:39]:
> >> From: Ambresh K <ambresh at ti.com>
> > 
> >> --- /dev/null
> >> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> > ...
> > 
> >> +/* dma_system */
> >> +static struct omap_hwmod_irq_info dra7xx_dma_system_irqs[] = {
> >> +	{ .name = "0", .irq = 12 + DRA7XX_IRQ_GIC_START },
> >> +	{ .name = "1", .irq = 13 + DRA7XX_IRQ_GIC_START },
> >> +	{ .name = "2", .irq = 14 + DRA7XX_IRQ_GIC_START },
> >> +	{ .name = "3", .irq = 15 + DRA7XX_IRQ_GIC_START },
> >> +	{ .irq = -1 }
> >> +};
> > 
> > I think these should no longer be needed?
> 
> These are needed only for dma because mach-omap2/dma.c still creates
> devices from hmwod and which are used by plat/dma.c.
> These irqs for sdma exist even in the cleaned up omap4 and omap5 hmwod files.
> I'll try and get rid of that dependency of plat/dma on mach/dma to create devices.

OK great.
 
> > In general, we must move the hwmod stuff to drivers/bus and start
> > parsing the data from device tree along the lines Tero is doing
> > for the clock data.
> 
> We already have irq/dma and iospace moved to DT (some iospace info still
> exists because of non-DT drivers). With Teros patches to move clock data we
> should be able to pass the main_clk and all interface level clock info too
> from DT.

OK.

Tony


From balbi at ti.com  Tue Jul  9 07:44:16 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 9 Jul 2013 14:44:16 +0300
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <780E789C2E067A4BB8F69D0BB9EC4F253E976575@DBDE04.ent.ti.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
 <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com>
 <51D54694.20203@ti.com> <20130704101216.GD4830@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E9764D5@DBDE04.ent.ti.com>
 <51DAADD1.3060302@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E976575@DBDE04.ent.ti.com>
Message-ID: <20130709114416.GL5552@arwen.pp.htv.fi>

Hi,

On Tue, Jul 09, 2013 at 04:23:29AM +0200, Patel, Satish wrote:
> > > We have two options over here
> > >
> > > Option 1:
> > >
> > > Defining generic api to which can be mapped over multiple phys
> > > For smartcard case, I have can thought of following mapping with new
> > > generic apis as suggested.
> > >
> > > Smartcard_poweron -> power_on
> > > Smartcard_powerdown -> power_off
> > > Smartcard_set_voltage -> phy_set_voltage
> > > Smartcard_activate_card -> phy_activate_slot
> > > Smartcard_deactivate_card -> phy_deactivate_slot
> > 
> > how is activate/deactivate different from poweron/poweroff in this
> > use case?
> 
> power on/off normal power sequence. While activate/de-activate will be 
> called during card transaction.

why can't you implement activate/deactivate with suspend/resume ?

> Brief on how it works:
> - when system start, execute power on for phy
> - smartcard controller and phy is connected through i2c, clock lines and 
> i/o lines
> - clock will be supplied by controller to phy to get data sync on i/o lines

fair enough.

> Operation:
>
> Once the card gets inserted into the slot, user application can
> initiate activate sequence anytime, it is not mandatory that
> activation has to be called Immediately. It all depends whether other
> connections ( network, printer) are proper.  User application can do
> some checks and then dynamically activate the card

The card or the phy ? Who actually activates ? Is the activation
handling part of the PHY or part of the smartcard controller ?

> There are 2 sequence of activation - normal activation and warm reset.
> If first fails then warm reset should be executed, if card does not
> response to both then deactivation will be carried out

ret = phy_resume(phy);
if (ret == -EINVAL) { /* perhaps there's a better error code */
	ret = phy_reset(phy);
	if (ret)
		phy_suspend(phy);
}

????

> - For activation there are some timing parameters ( called ATR -
> Answer to reset timings) Has to be set to the phy

does that change in runtime or is it something which is set during probe
and never touched again ?

> - on activation card will respond with some initial characters (ATR),
> which will be verified by application, in case of error user
> application will de-activate the card not the phy module
> 
> - After activation, use application initiate normal tx/rx
> 
> - Once tx/rx is done, it will initiate deactivation of card not the
> phy module.

then that has nothing to do with the PHY framework, right ?

> > > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> > 
> > Whats should be exactly done here? Looks to me like it should be
> > part of init. Does these pin settings need to be changed dynamically?
> 
> These are all phy pins which will be physically come in contact with
> smart card When inserted. In case of synchronous card, these pins will
> be toggled manually by s/w bit bang algorithm

is that a requirement or just something that everybody does ?

In any case, you can hide that under some gpio calls, or something
similar.

> > Why? Is it like the detection of an external event? Then the PHY
> > driver should use *extcon* for event detection and passing.
> >
> 
> Smartcard controller need a way to ready isr status ( like card presence,
> Card inserted in to which slot, removed from which slot ) to maintain its
> Internal state machine.

register an interrupt handler with devm_request_threaded_irq(), what's
the problem ?

> > > Smartcard_get_version -> phy_get_version
> > 
> > Again why? Why would the smartcard need the version of the PHY?
> > 
> 
> Can be omitted. This is for the test suite reference.

if it's for testsuite, it sounds like something that should be done
through userland and, as such, should be implemented by a set of debugfs
files which expose the necessary information. That has nothing to do
with the PHY framework.

-- 
balbi
-------------- 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/20130709/b8472db6/attachment-0001.sig>

From sergei.shtylyov at cogentembedded.com  Tue Jul  9 07:45:17 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 09 Jul 2013 15:45:17 +0400
Subject: [PATCH] ARM: shmobile: Add SMSC ethernet chip to KZM9D DT
 reference
In-Reply-To: <20130709042654.13658.20164.sendpatchset@w520>
References: <20130709042654.13658.20164.sendpatchset@w520>
Message-ID: <51DBF7CD.8040009@cogentembedded.com>

Hello.

On 09-07-2013 8:26, Magnus Damm wrote:

> From: Magnus Damm <damm at opensource.se>

> Add support for the SMSC ethernet controller found
> on the KZM9D board to the KZM9D DT Reference code.

> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---

>   Built on top of renesas-next-20130704v2 and
>   [PATCH] ARM: shmobile: KZM9D DT reference implementation

>   arch/arm/boot/dts/emev2-kzm9d-reference.dts |   31 +++++++++++++++++++++++++++
>   1 file changed, 31 insertions(+)

> --- 0002/arch/arm/boot/dts/emev2-kzm9d-reference.dts
> +++ work/arch/arm/boot/dts/emev2-kzm9d-reference.dts	2013-07-09 13:06:47.000000000 +0900
> @@ -23,4 +23,35 @@
[...]
> +	lan9220 at 20000000 {

    Shouldn't all the Ethernet nodes be called "ethernet"?

> +		compatible = "smsc,lan9220", "smsc,lan9115";
> +		reg = <0x20000000 0x10000>;
> +		phy-mode = "mii";
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <1 1>;	/* active high */
> +		reg-io-width = <4>;
> +		smsc,irq-active-high;
> +		smsc,irq-push-pull;
> +		vddvario-supply = <&reg_1p8v>;
> +		vdd33a-supply = <&reg_3p3v>;
> +	};
>   };

WBR, Sergei




From george.cherian at ti.com  Tue Jul  9 07:52:43 2013
From: george.cherian at ti.com (George Cherian)
Date: Tue, 9 Jul 2013 17:22:43 +0530
Subject: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
In-Reply-To: <20130709112751.GI5552@arwen.pp.htv.fi>
References: <1373361446-30050-1-git-send-email-george.cherian@ti.com>
 <20130709102022.GH5552@arwen.pp.htv.fi> <51DBF23F.20103@ti.com>
 <20130709112751.GI5552@arwen.pp.htv.fi>
Message-ID: <51DBF98B.1050104@ti.com>

On 7/9/2013 4:57 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 09, 2013 at 04:51:35PM +0530, George Cherian wrote:
>>>> +				compatible = "snps,dwc3";
>>>> +				reg = <0x48390000 0xcfff>;
>>> weird size, shouldn't this be 0xd000 then the size would be exactly
>>> 52KiB
>> okay
> btw, the reason here is that when you call devm_ioremap_resource(), that
> will call resource_size() which does:
>
> 	size = res->end - res->start - 1;
>
> so you need this extra 1 on the size when passing it via DT.

agreed.
>>> Another thing: am437x has 4 instances of this IP, why are you adding
>>> only one ?
>> AM437x has got only 2 instances. I have verified only one on HAPS so
>> adding only one.
> weird, on my TRM I see for dwc3 but 2 PHYs.

Please confirm whether you are looking at am437x TRM or dra7x TRM?
dra7x has 4 dwc3 and 2 internal  phys and 2 external phys
>>> And why aren't you pasing the PHY nodes here ? The device
>>> won't work without its PHYs.
>> Yes true, again in HAPS I  didnt have any PHY configuration to be done.
> alright, but we should still pass the PHY right ? once silicon comes,
> we want this to work without any further changers.

okay will add phy nodes and 2 instances of dwc3.



-- 
-George



From robherring2 at gmail.com  Tue Jul  9 08:03:14 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 9 Jul 2013 07:03:14 -0500
Subject: [PATCH] of: match the compatible in the order set by the dts file
In-Reply-To: <51DBC58D.90002@freescale.com>
References: <1373013818-11365-1-git-send-email-b32955@freescale.com>
 <20130709070541.GQ516@pengutronix.de>
 <51DBBFDA.70302@freescale.com>
 <20130709075124.GR516@pengutronix.de>
 <51DBC58D.90002@freescale.com>
Message-ID: <CAL_JsqL4ABJCQXveSAMZKOiHwJi=w8zFYjg3DV7kqEEcCXQJcw@mail.gmail.com>

On Tue, Jul 9, 2013 at 3:10 AM, Huang Shijie <b32955 at freescale.com> wrote:
> ? 2013?07?09? 15:51, Sascha Hauer ??:
>
>> On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
>>>
>>> ? 2013?07?09? 15:05, Sascha Hauer ??:
>>>>
>>>> Why don't you set the matching order in the driver the way you want it
>>>> to be, i.e.:
>>>>
>>>>         { .compatible = "fsl,imx6q-uart", ... },
>>>>         { .compatible = "fsl,imx21-uart", ... },
>>>>         { .compatible = "fsl,imx1-uart", ... },
>>>>
>>> yes. i can set it like this.
>>>
>>> but this method looks like a ugly workaround.
>>
>> If a driver has different ways of supporting a single device, then
>> putting the preferred or most feature rich on top doesn't look very ugly
>> to me.
>
> this method makes it much _coupled_ between the driver and the dts file.
>
> IMHO, it's an unnecessary _burden_ to the driver programmer:
>    he should puts the most feature compatible on the top.
>
> it's much graceful if we let the driver programmer be transparent about
> this.

The dts requires compatible strings to be most specific to least
specific. There is no reason that driver match tables should not be
the same and that is the assumption. Matching is not just based on
compatible properties and your patch does not handle the other cases.

Rob



>
>
> thanks
> Huang Shijie
>
>
>
>
>
>
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss


From balbi at ti.com  Tue Jul  9 08:03:54 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 9 Jul 2013 15:03:54 +0300
Subject: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
In-Reply-To: <51DBF98B.1050104@ti.com>
References: <1373361446-30050-1-git-send-email-george.cherian@ti.com>
 <20130709102022.GH5552@arwen.pp.htv.fi> <51DBF23F.20103@ti.com>
 <20130709112751.GI5552@arwen.pp.htv.fi> <51DBF98B.1050104@ti.com>
Message-ID: <20130709120354.GP5552@arwen.pp.htv.fi>

Hi,

On Tue, Jul 09, 2013 at 05:22:43PM +0530, George Cherian wrote:
> >>>Another thing: am437x has 4 instances of this IP, why are you adding
> >>>only one ?
> >>AM437x has got only 2 instances. I have verified only one on HAPS so
> >>adding only one.
> >weird, on my TRM I see for dwc3 but 2 PHYs.
> 
> Please confirm whether you are looking at am437x TRM or dra7x TRM?
> dra7x has 4 dwc3 and 2 internal  phys and 2 external phys

guilty as charged :-)

> >>>And why aren't you pasing the PHY nodes here ? The device
> >>>won't work without its PHYs.
> >>Yes true, again in HAPS I  didnt have any PHY configuration to be done.
> >alright, but we should still pass the PHY right ? once silicon comes,
> >we want this to work without any further changers.
> 
> okay will add phy nodes and 2 instances of dwc3.

thanks

-- 
balbi
-------------- 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/20130709/1efa2643/attachment.sig>

From richard.genoud at gmail.com  Tue Jul  9 08:28:43 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 14:28:43 +0200
Subject: [PATCH v3 1/7] sound: sam9x5_wm8731: machine driver for at91sam9x5
 wm8731 boards
In-Reply-To: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373372929-17800-2-git-send-email-richard.genoud@gmail.com>

From: Nicolas Ferre <nicolas.ferre at atmel.com>

Description of the Asoc machine driver for an at91sam9x5 based board
with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
master on the SSC/I2S interface. Its connections are a headphone jack
and an Line input jack.

[Richard: this is based on an old patch from Nicolas that I forward
ported and reworked to use only device tree]

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 sound/soc/atmel/Kconfig         |   10 ++
 sound/soc/atmel/Makefile        |    2 +
 sound/soc/atmel/sam9x5_wm8731.c |  238 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 250 insertions(+)
 create mode 100644 sound/soc/atmel/sam9x5_wm8731.c

diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 1c0b185..9eb8c49 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -33,6 +33,16 @@ config SND_AT91_SOC_SAM9G20_WM8731
 	  Say Y if you want to add support for SoC audio on WM8731-based
 	  AT91sam9g20 evaluation board.
 
+config SND_AT91_SOC_SAM9X5_WM8731
+	tristate "SoC Audio support for WM8731-based at91sam9x5 board"
+	depends on ATMEL_SSC && SND_ATMEL_SOC && SOC_AT91SAM9X5
+	select SND_ATMEL_SOC_SSC
+	select SND_ATMEL_SOC_DMA
+	select SND_SOC_WM8731
+	help
+	  Say Y if you want to add support for audio SoC on an
+	  at91sam9x5 based board that is using WM8731 codec.
+
 config SND_AT91_SOC_AFEB9260
 	tristate "SoC Audio support for AFEB9260 board"
 	depends on ARCH_AT91 && ATMEL_SSC && ARCH_AT91 && MACH_AFEB9260 && SND_ATMEL_SOC
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index 41967cc..7784c09 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -11,6 +11,8 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
 
 # AT91 Machine Support
 snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
+snd-soc-sam9x5-wm8731-objs := sam9x5_wm8731.o
 
 obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
+obj-$(CONFIG_SND_AT91_SOC_SAM9X5_WM8731) += snd-soc-sam9x5-wm8731.o
 obj-$(CONFIG_SND_AT91_SOC_AFEB9260) += snd-soc-afeb9260.o
diff --git a/sound/soc/atmel/sam9x5_wm8731.c b/sound/soc/atmel/sam9x5_wm8731.c
new file mode 100644
index 0000000..c56e36b
--- /dev/null
+++ b/sound/soc/atmel/sam9x5_wm8731.c
@@ -0,0 +1,238 @@
+/*
+ * sam9x5_wm8731   --	SoC audio for AT91SAM9X5-based boards
+ *			that are using WM8731 as codec.
+ *
+ *  Copyright (C) 2011 Atmel,
+ *		  Nicolas Ferre <nicolas.ferre at atmel.com>
+ *
+ *  Copyright (C) 2013 Paratronic,
+ *		  Richard Genoud <richard.genoud at gmail.com>
+ *
+ * Based on sam9g20_wm8731.c by:
+ * Sedji Gaouaou <sedji.gaouaou at atmel.com>
+ *
+ *  This program is free software; you can redistribute  it and/or modify it
+ *  under  the terms of  the GNU General  Public License as published by the
+ *  Free Software Foundation;  either version 2 of the  License, or (at your
+ *  option) any later version.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/kernel.h>
+#include <linux/clk.h>
+#include <linux/timer.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/i2c.h>
+
+#include <linux/atmel-ssc.h>
+
+#include <sound/core.h>
+#include <sound/pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+
+#include <asm/mach-types.h>
+#include <mach/hardware.h>
+#include <mach/gpio.h>
+
+#include "../codecs/wm8731.h"
+#include "atmel-pcm.h"
+#include "atmel_ssc_dai.h"
+
+#define MCLK_RATE 12288000
+
+#define DRV_NAME "sam9x5-snd-wm8731"
+
+/*
+ * Authorized rates are:
+ * Rate = MCLK_RATE / (n * 2)
+ * Where n is in [1..4095]
+ * (cf register SSC_CMR)
+ */
+static unsigned int rates[] = {
+	8000,
+	16000,
+	32000,
+	48000,
+	64000,
+	96000,
+};
+
+static struct snd_pcm_hw_constraint_list hw_rates = {
+	.count = ARRAY_SIZE(rates),
+	.list = rates,
+};
+
+/*
+ * Logic for a wm8731 as connected on a at91sam9x5 based board.
+ */
+static int at91sam9x5ek_wm8731_init(struct snd_soc_pcm_runtime *rtd)
+{
+	struct snd_soc_dai *codec_dai = rtd->codec_dai;
+	struct device *dev = rtd->dev;
+	int ret;
+
+	dev_dbg(dev, "ASoC: %s called\n", __func__);
+
+	/* set the codec system clock for DAC and ADC */
+	ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
+				     MCLK_RATE, SND_SOC_CLOCK_IN);
+	if (ret < 0) {
+		dev_err(dev, "ASoC: Failed to set WM8731 SYSCLK: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int sam9x5ek_wm8731_startup(struct snd_pcm_substream *substream)
+{
+	struct snd_pcm_runtime *runtime = substream->runtime;
+
+	runtime->hw.rate_min = hw_rates.list[0];
+	runtime->hw.rate_max = hw_rates.list[hw_rates.count - 1];
+	runtime->hw.rates = SNDRV_PCM_RATE_KNOT;
+
+	return snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
+					  &hw_rates);
+}
+
+/*
+ * Audio paths on at91sam9x5ek board:
+ *
+ *  |A| ------------> |      | ---R----> Headphone Jack
+ *  |T| <----\        |  WM  | ---L--/
+ *  |9| ---> CLK <--> | 8731 | <--R----- Line In Jack
+ *  |1| <------------ |      | <--L--/
+ */
+static const struct snd_soc_dapm_widget at91sam9x5ek_dapm_widgets[] = {
+	SND_SOC_DAPM_HP("Headphone Jack", NULL),
+	SND_SOC_DAPM_LINE("Line In Jack", NULL),
+};
+
+static struct snd_soc_ops sam9x5ek_wm8731_ops = {
+	.startup = sam9x5ek_wm8731_startup,
+};
+
+static struct snd_soc_dai_link at91sam9x5ek_dai = {
+	.name = "WM8731",
+	.stream_name = "WM8731 PCM",
+	.codec_dai_name = "wm8731-hifi",
+	.init = at91sam9x5ek_wm8731_init,
+	.ops = &sam9x5ek_wm8731_ops,
+};
+
+static struct snd_soc_card snd_soc_at91sam9x5ek = {
+	.owner = THIS_MODULE,
+	.dai_link = &at91sam9x5ek_dai,
+	.num_links = 1,
+	.dapm_widgets = at91sam9x5ek_dapm_widgets,
+	.num_dapm_widgets = ARRAY_SIZE(at91sam9x5ek_dapm_widgets),
+};
+
+static int sam9x5_wm8731_driver_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *codec_np, *cpu_np;
+	int ret;
+
+	if (!np) {
+		dev_err(&pdev->dev, "No device node supplied\n");
+		return -EINVAL;
+	}
+
+	ret = atmel_ssc_set_audio(0);
+	if (ret != 0) {
+		dev_err(&pdev->dev,
+			"ASoC: Failed to set SSC 0 for audio: %d\n", ret);
+		return ret;
+	}
+
+	snd_soc_at91sam9x5ek.dev = &pdev->dev;
+
+	ret = snd_soc_of_parse_card_name(&snd_soc_at91sam9x5ek, "atmel,model");
+	if (ret)
+		goto out;
+
+	ret = snd_soc_of_parse_audio_routing(&snd_soc_at91sam9x5ek,
+					     "atmel,audio-routing");
+	if (ret)
+		goto out;
+
+	codec_np = of_parse_phandle(np, "atmel,audio-codec", 0);
+	if (!codec_np) {
+		dev_err(&pdev->dev, "codec info missing\n");
+		ret = -EINVAL;
+		goto out;
+	}
+
+	at91sam9x5ek_dai.codec_of_node = codec_np;
+
+	cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
+	if (!cpu_np) {
+		dev_err(&pdev->dev, "ssc controller node missing\n");
+		ret = -EINVAL;
+		goto out;
+	}
+	at91sam9x5ek_dai.cpu_of_node = cpu_np;
+	at91sam9x5ek_dai.platform_of_node = cpu_np;
+
+	of_node_put(codec_np);
+	of_node_put(cpu_np);
+
+	at91sam9x5ek_dai.dai_fmt = snd_soc_of_parse_daifmt(np, "atmel,");
+
+	ret = snd_soc_register_card(&snd_soc_at91sam9x5ek);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"ASoC: Platform device allocation failed\n");
+		goto out;
+	}
+
+	platform_set_drvdata(pdev, &snd_soc_at91sam9x5ek);
+
+	dev_dbg(&pdev->dev, "ASoC: %s ok\n", __func__);
+
+	return ret;
+
+out:
+	atmel_ssc_put_audio(0);
+	return ret;
+}
+
+static int sam9x5_wm8731_driver_remove(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = platform_get_drvdata(pdev);
+
+	snd_soc_unregister_card(card);
+	atmel_ssc_put_audio(0);
+
+	return 0;
+}
+
+static const struct of_device_id sam9x5_wm8731_of_match[] = {
+	{ .compatible = "atmel,sam9x5-wm8731-audio", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sam9x5_wm8731_of_match);
+
+static struct platform_driver sam9x5_wm8731_driver = {
+	.driver = {
+		.name = DRV_NAME,
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(sam9x5_wm8731_of_match),
+	},
+	.probe = sam9x5_wm8731_driver_probe,
+	.remove = sam9x5_wm8731_driver_remove,
+};
+module_platform_driver(sam9x5_wm8731_driver);
+
+/* Module information */
+MODULE_AUTHOR("Nicolas Ferre <nicolas.ferre at atmel.com>");
+MODULE_AUTHOR("Richard Genoud <richard.genoud at gmail.com>");
+MODULE_DESCRIPTION("ALSA SoC machine driver for AT91SAM9x5 - WM8731");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:" DRV_NAME);
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul  9 08:28:44 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 14:28:44 +0200
Subject: [PATCH v3 2/7] Documentation: DT: add sam9x5ek-wm8731 machine driver
In-Reply-To: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373372929-17800-3-git-send-email-richard.genoud@gmail.com>

This add the sound DT binding for sam9x5ek-wm8731 machine driver

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 .../bindings/sound/atmel-sam9x5-wm8731-audio.txt   |   30 ++++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt

diff --git a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
new file mode 100644
index 0000000..fd03dfd
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
@@ -0,0 +1,30 @@
+* Atmel at91sam9x5ek wm8731 audio complex
+
+Required properties:
+  - compatible: "atmel,at91sam9x5ek-wm8731-audio"
+  - atmel,model: The user-visible name of this sound complex.
+  - atmel,audio-routing: A list of the connections between audio components.
+  - atmel,ssc-controller: The phandle of the SSC controller
+  - atmel,audio-codec: The phandle of the WM8731 audio codec
+  - atmel,format: DAI format. Must be "i2s"
+  - atmel,bitclock-master:  DAI clock master
+  - atmel,frame-master: DAI frame master
+
+Example:
+sound {
+	compatible = "atmel,sam9x5-wm8731-audio";
+
+	atmel,model = "wm8731 @ AT91SAM9X5EK";
+
+	atmel,audio-routing =
+		"Headphone Jack", "RHPOUT",
+		"Headphone Jack", "LHPOUT",
+		"LLINEIN", "Line In Jack",
+		"RLINEIN", "Line In Jack";
+
+	atmel,ssc-controller = <&ssc0>;
+	atmel,audio-codec = <&wm8731>;
+	atmel,format = "i2s";
+	atmel,bitclock-master;
+	atmel,frame-master;
+};
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul  9 08:28:45 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 14:28:45 +0200
Subject: [PATCH v3 3/7] Documentation: DT: update atmel SSC with DMA binding
In-Reply-To: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373372929-17800-4-git-send-email-richard.genoud@gmail.com>

As atmel-ssc can be used with DMA, the documentation should be updated.
Also, a configuration DMA example is given.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 .../devicetree/bindings/misc/atmel-ssc.txt         |   24 ++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
index 38e51ad..96958ca 100644
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -6,10 +6,30 @@ Required properties:
 	- atmel,at91sam9g45-ssc: support dma transfer
 - reg: Should contain SSC registers location and length
 - interrupts: Should contain SSC interrupt
+For dma transfer:
+- dmas: DMA specifier, consisting of a phandle to DMA controller node,
+  the memory interface and SSC DMA channel ID (for tx and rx).
+  See Documentation/devicetree/bindings/dma/atmel-dma.txt for details.
+- dma-names: Must be "tx", "rx".
 
-Example:
+
+Examples:
 ssc0: ssc at fffbc000 {
 	compatible = "atmel,at91rm9200-ssc";
 	reg = <0xfffbc000 0x4000>;
-	interrupts = <14 4 5>;
+	interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>;
 };
+
+
+ssc0: ssc at f0010000 {
+      compatible = "atmel,at91sam9g45-ssc";
+      reg = <0xf0010000 0x4000>;
+      interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
+      dmas = <&dma0 1 AT91_DMA_CFG_PER_ID(13)>,
+	     <&dma0 1 AT91_DMA_CFG_PER_ID(14)>;
+      dma-names = "tx", "rx";
+      pinctrl-names = "default";
+      pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+      status = "disabled";
+};
+
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul  9 08:28:46 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 14:28:46 +0200
Subject: [PATCH v3 4/7] ARM: AT91: DTS: sam9x5: add SSC DMA parameters
In-Reply-To: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373372929-17800-5-git-send-email-richard.genoud@gmail.com>

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5.dtsi |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 57d45f5..cf78ac0 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -542,6 +542,9 @@
 				compatible = "atmel,at91sam9g45-ssc";
 				reg = <0xf0010000 0x4000>;
 				interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
+				dmas = <&dma0 1 AT91_DMA_CFG_PER_ID(13)>,
+				       <&dma0 1 AT91_DMA_CFG_PER_ID(14)>;
+				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
 				status = "disabled";
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul  9 08:28:47 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 14:28:47 +0200
Subject: [PATCH v3 5/7] ARM: AT91: DTS: sam9x5ek: add WM8731 codec
In-Reply-To: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373372929-17800-6-git-send-email-richard.genoud@gmail.com>

The WM8731 codec on sam9x5ek board is on i2c, address 1A

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
Acked-by: Mark Brown <broonie at linaro.org>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index d107241..e6fb309 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -59,6 +59,11 @@
 
 			i2c0: i2c at f8010000 {
 				status = "okay";
+
+				wm8731: wm8731 at 1a {
+					compatible = "wm8731";
+					reg = <0x1a>;
+				};
 			};
 
 			pinctrl at fffff400 {
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul  9 08:28:48 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 14:28:48 +0200
Subject: [PATCH v3 6/7] ARM: AT91: DTS: sam9x5ek: add sound configuration
In-Reply-To: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373372929-17800-7-git-send-email-richard.genoud@gmail.com>

The sam9x5ek board has 2 jacks:
headphone wired on RHPOUT/LHPOUT of the wm8731
line in wired on LLINEIN/RLINEIN of the wm8731

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index e6fb309..2bf51cc 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -109,4 +109,22 @@
 			status = "okay";
 		};
 	};
+
+	sound {
+		compatible = "atmel,sam9x5-wm8731-audio";
+
+		atmel,model = "wm8731 @ AT91SAM9X5EK";
+
+		atmel,audio-routing =
+			"Headphone Jack", "RHPOUT",
+			"Headphone Jack", "LHPOUT",
+			"LLINEIN", "Line In Jack",
+			"RLINEIN", "Line In Jack";
+
+		atmel,ssc-controller = <&ssc0>;
+		atmel,audio-codec = <&wm8731>;
+		atmel,format = "i2s";
+		atmel,bitclock-master;
+		atmel,frame-master;
+	};
 };
-- 
1.7.10.4



From satish.patel at ti.com  Tue Jul  9 08:33:58 2013
From: satish.patel at ti.com (Patel, Satish)
Date: Tue, 9 Jul 2013 12:33:58 +0000
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <20130709114416.GL5552@arwen.pp.htv.fi>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com>
 <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com>
 <51D54694.20203@ti.com> <20130704101216.GD4830@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E9764D5@DBDE04.ent.ti.com>
 <51DAADD1.3060302@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E976575@DBDE04.ent.ti.com>
 <20130709114416.GL5552@arwen.pp.htv.fi>
Message-ID: <780E789C2E067A4BB8F69D0BB9EC4F253E97670D@DBDE04.ent.ti.com>

Hi,

> -----Original Message-----
> From: Balbi, Felipe
> Sent: Tuesday, July 09, 2013 5:14 PM
> To: Patel, Satish
> Cc: ABRAHAM, KISHON VIJAY; Balbi, Felipe; grant.likely at linaro.org;
> tony at atomide.com; arnd at arndb.de; swarren at nvidia.com;
> sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> foundation.org; rob.herring at calxeda.com; rob at landley.net;
> linux at arm.linux.org.uk; benoit.cousson at linaro.org; mchehab at redhat.com;
> cesarb at cesarb.net; davem at davemloft.net; Nayak, Rajendra;
> shawn.guo at linaro.org; Shilimkar, Santosh; devicetree-
> discuss at lists.ozlabs.org; linux-doc at vger.kernel.org; Nori, Sekhar;
> Krishnamoorthy, Balaji T; Cherian, George; Mankad, Maulik Ojas;
> Srinivasan, Nageswari; Sundareson, Prabindh
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> Hi,
> 
> On Tue, Jul 09, 2013 at 04:23:29AM +0200, Patel, Satish wrote:
> > > > We have two options over here
> > > >
> > > > Option 1:
> > > >
> > > > Defining generic api to which can be mapped over multiple phys
> > > > For smartcard case, I have can thought of following mapping with
> new
> > > > generic apis as suggested.
> > > >
> > > > Smartcard_poweron -> power_on
> > > > Smartcard_powerdown -> power_off
> > > > Smartcard_set_voltage -> phy_set_voltage
> > > > Smartcard_activate_card -> phy_activate_slot
> > > > Smartcard_deactivate_card -> phy_deactivate_slot
> > >
> > > how is activate/deactivate different from poweron/poweroff in this
> > > use case?
> >
> > power on/off normal power sequence. While activate/de-activate will
> be
> > called during card transaction.
> 
> why can't you implement activate/deactivate with suspend/resume ?
> 
> > Brief on how it works:
> > - when system start, execute power on for phy
> > - smartcard controller and phy is connected through i2c, clock lines
> and
> > i/o lines
> > - clock will be supplied by controller to phy to get data sync on
> i/o lines
> 
> fair enough.
> 
> > Operation:
> >
> > Once the card gets inserted into the slot, user application can
> > initiate activate sequence anytime, it is not mandatory that
> > activation has to be called Immediately. It all depends whether
> other
> > connections ( network, printer) are proper.  User application can do
> > some checks and then dynamically activate the card
> 
> The card or the phy ? Who actually activates ? Is the activation
> handling part of the PHY or part of the smartcard controller ?
> 

It?s a activation of smart card which is inserted into the phy slot. 
Smart card activation will by done phy but initiated by user application
Handling of activation should be done at both the side - controller as well
As phy. Phy will raise certain signals and check timeout while activation
, while controller will store data coming from smart card to FIFO. Its
Controller which will give command to phy to initiate activation sequence when it
is ready. 

Which means, both controller and phy has role to play while activation.
Also it is applicable while deactivation.


> > There are 2 sequence of activation - normal activation and warm
> reset.
> > If first fails then warm reset should be executed, if card does not
> > response to both then deactivation will be carried out
> 
> ret = phy_resume(phy);
> if (ret == -EINVAL) { /* perhaps there's a better error code */
> 	ret = phy_reset(phy);
> 	if (ret)
> 		phy_suspend(phy);
> }
>

Its not like this. There are the cases, when during normal activation card respond
With some characters, but they might not be valid or error prone - This check will be 
done by user application as only application knows how to decode characters as per protocol.

It there is any error in characters/timeout paratmeters, user application will ask to initiate
Warm reset.
 
> ????
> 
> > - For activation there are some timing parameters ( called ATR -
> > Answer to reset timings) Has to be set to the phy
> 
> does that change in runtime or is it something which is set during
> probe
> and never touched again ?
> 
> > - on activation card will respond with some initial characters
> (ATR),
> > which will be verified by application, in case of error user
> > application will de-activate the card not the phy module
> >
> > - After activation, use application initiate normal tx/rx
> >
> > - Once tx/rx is done, it will initiate deactivation of card not the
> > phy module.
> 
> then that has nothing to do with the PHY framework, right ?

But all such sequence will be initiated by PHY by raising certain signals
and only controller can give the push when to start.
> 
> > > > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> > >
> > > Whats should be exactly done here? Looks to me like it should be
> > > part of init. Does these pin settings need to be changed
> dynamically?
> >
> > These are all phy pins which will be physically come in contact with
> > smart card When inserted. In case of synchronous card, these pins
> will
> > be toggled manually by s/w bit bang algorithm
> 
> is that a requirement or just something that everybody does ?
>

Its requirement for synchronous card. At present there is no open driver
Which does this thing.
 
> In any case, you can hide that under some gpio calls, or something
> similar.

Can't be done using GPIO as pin can be toggled only which i2c read/write
to the phy.
> 
> > > Why? Is it like the detection of an external event? Then the PHY
> > > driver should use *extcon* for event detection and passing.
> > >
> >
> > Smartcard controller need a way to ready isr status ( like card
> presence,
> > Card inserted in to which slot, removed from which slot ) to
> maintain its
> > Internal state machine.
> 
> register an interrupt handler with devm_request_threaded_irq(), what's
> the problem ?
> 
> > > > Smartcard_get_version -> phy_get_version
> > >
> > > Again why? Why would the smartcard need the version of the PHY?
> > >
> >
> > Can be omitted. This is for the test suite reference.
> 
> if it's for testsuite, it sounds like something that should be done
> through userland and, as such, should be implemented by a set of
> debugfs
> files which expose the necessary information. That has nothing to do
> with the PHY framework.
> 
Agree.. can be omitted.


I am ok to give internal webex presentation (TI team) to brief 
on phy and smart card controller interface.


> --
> balbi


From richard.genoud at gmail.com  Tue Jul  9 08:28:49 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 14:28:49 +0200
Subject: [PATCH v3 7/7] ARM: AT91: DTS: sam9x5ek: enable SSC
In-Reply-To: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373372929-17800-8-git-send-email-richard.genoud@gmail.com>

Enable the SSC needed for the WM8731 codec

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index 2bf51cc..0534c58 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -95,6 +95,10 @@
 			watchdog at fffffe40 {
 				status = "okay";
 			};
+
+			ssc0: ssc at f0010000 {
+				status = "okay";
+			};
 		};
 
 		usb0: ohci at 00600000 {
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul  9 08:28:42 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 14:28:42 +0200
Subject: [PATCH v3 0/7] Sound support for at91sam9x5-wm8731 based boards
In-Reply-To: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>

Hi,

This patchset add sound on the at91sam9x5ek board.
It's based on Nicolas Ferre's work in the 2.6.39 atmel patch for sam9x5:
https://github.com/linux4sam/linux-at91/commit/0aa157c9e71ccccf3abc30fa37eb5c95b392978d

It needs Bo Chen's patchset on the generic dmaengine (topic/atmel branch
on Mark's sound tree) and the SSC interrupts disabled (cf
http://www.spinics.net/lists/arm-kernel/msg256901.html)

Outstanding issue:
If this machine driver will support more SoCs maybe we should name it differently.


It has been tested on at91sam9g35ek, and should work on g15, g25, x25 and x35 also.

patches applies on next-20130708

[I let the original signed-off from Nicolas and Uwe in place, I don't
know if I should replace them by something like "originaly-signed-off-by"
since the code has been changed.]

Changes from v2:
 * Change atmel,sam9x5-audio-wm8731 to atmel,sam9x5-wm8731-audio for
consistency with sam9g20 machine driver.
 * Use the snd_pcm_hw_constraint() API as suggested by Mark and Lars-Peter.
 * Remove the unnecessary snd_soc_dapm_sync() call as Lars-Peter suggested.
 * Add documentation for machine driver DT binding.
 * Update atmel-ssc DT binding documentation.
 * Add GPL license instead of just the "GPL" word (hope that's ok !)

Changes from v1-RFC:
 * drop patches on SSC since Bo Chen already did the work
 * reorder patches to have the machine driver first
 * drop code already handled by the ASoC framework
 * drop unneeded SND_ATMEL_SOC_PDC config selection
 * use static snd_soc_card and  snd_soc_dai_link structures.

Best regards,
Richard.

Nicolas Ferre (1):
  sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards

Richard Genoud (6):
  Documentation: DT: add sam9x5ek-wm8731 machine driver
  Documentation: DT: update atmel SSC with DMA binding
  ARM: AT91: DTS: sam9x5: add SSC DMA parameters
  ARM: AT91: DTS: sam9x5ek: add WM8731 codec
  ARM: AT91: DTS: sam9x5ek: add sound configuration
  ARM: AT91: DTS: sam9x5ek: enable SSC

 .../devicetree/bindings/misc/atmel-ssc.txt         |   24 +-
 .../bindings/sound/atmel-sam9x5-wm8731-audio.txt   |   30 +++
 arch/arm/boot/dts/at91sam9x5.dtsi                  |    3 +
 arch/arm/boot/dts/at91sam9x5ek.dtsi                |   27 +++
 sound/soc/atmel/Kconfig                            |   10 +
 sound/soc/atmel/Makefile                           |    2 +
 sound/soc/atmel/sam9x5_wm8731.c                    |  238 ++++++++++++++++++++
 7 files changed, 332 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
 create mode 100644 sound/soc/atmel/sam9x5_wm8731.c

-- 
1.7.10.4




From jason at lakedaemon.net  Tue Jul  9 08:49:00 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 9 Jul 2013 08:49:00 -0400
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
Message-ID: <20130709124900.GG11908@titan.lakedaemon.net>

Neil,

On Tue, Jul 09, 2013 at 02:42:44PM +0800, Neil Zhang wrote:
> The documented vendor prefix for Marvell is 'marvell', not 'mrvl', so
> let's change it.
> 
> Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> ---
>  .../devicetree/bindings/arm/mrvl/intc.txt          |   16 +++---
>  .../devicetree/bindings/arm/mrvl/mrvl.txt          |    6 +-
>  .../devicetree/bindings/arm/mrvl/timer.txt         |    4 +-
>  Documentation/devicetree/bindings/i2c/i2c-pxa.txt  |   14 +++---
>  .../devicetree/bindings/mmc/sdhci-pxa.txt          |    8 ++--
>  .../devicetree/bindings/rtc/sa1100-rtc.txt         |    4 +-
>  .../devicetree/bindings/serial/mrvl-serial.txt     |    2 +-
>  arch/arm/boot/dts/mmp2-brownstone.dts              |    2 +-
>  arch/arm/boot/dts/mmp2.dtsi                        |   56 ++++++++++----------
>  arch/arm/boot/dts/pxa168-aspenite.dts              |    2 +-
>  arch/arm/boot/dts/pxa168.dtsi                      |   24 ++++----
>  arch/arm/boot/dts/pxa2xx.dtsi                      |   16 +++---
>  arch/arm/boot/dts/pxa3xx.dtsi                      |    2 +-
>  arch/arm/boot/dts/pxa910-dkb.dts                   |    2 +-
>  arch/arm/boot/dts/pxa910.dtsi                      |   27 +++++-----
>  arch/arm/mach-mmp/irq.c                            |   16 +++---
>  arch/arm/mach-mmp/mmp-dt.c                         |   28 +++++-----
>  arch/arm/mach-mmp/mmp2-dt.c                        |   16 +++---
>  arch/arm/mach-mmp/time.c                           |    2 +-
>  arch/arm/mach-pxa/pxa-dt.c                         |   14 +++---
>  drivers/i2c/busses/i2c-pxa.c                       |   10 ++--
>  drivers/mmc/host/sdhci-pxav2.c                     |    4 +-
>  drivers/mmc/host/sdhci-pxav3.c                     |    4 +-
>  drivers/rtc/rtc-sa1100.c                           |    4 +-
>  drivers/tty/serial/pxa.c                           |    4 +-
>  25 files changed, 144 insertions(+), 143 deletions(-)

I agree with the need to change, however, this has been in the binding
documentation since v3.5.  I wish we had caught this when we decided
against using stock ticker symbols (not all stock markets use
alphabetical abbreviated names, not all companies are listed on any
stock exchange).

To do this properly, the drivers are going to have to be compatible with
the old and the new names, and the binding docs updated to reflect the
legacy name and the preferred name.

thx,

Jason.

> diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> index 8b53273..ad27548 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> @@ -1,8 +1,8 @@
>  * Marvell MMP Interrupt controller
>  
>  Required properties:
> -- compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or
> -  "mrvl,mmp2-mux-intc"
> +- compatible : Should be "marvell,mmp-intc", "marvell,mmp2-intc" or
> +  "marvell,mmp2-mux-intc"
>  - reg : Address and length of the register set of the interrupt controller.
>    If the interrupt controller is intc, address and length means the range
>    of the whold interrupt controller. If the interrupt controller is mux-intc,
> @@ -15,28 +15,28 @@ Required properties:
>  - interrupt-controller : Identifies the node as an interrupt controller.
>  - #interrupt-cells : Specifies the number of cells needed to encode an
>    interrupt source.
> -- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
> +- marvell,intc-nr-irqs : Specifies the number of interrupts in the interrupt
>    controller.
> -- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
> +- marvell,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
>    detection first.
>  
>  Example:
>  	intc: interrupt-controller at d4282000 {
> -		compatible = "mrvl,mmp2-intc";
> +		compatible = "marvell,mmp2-intc";
>  		interrupt-controller;
>  		#interrupt-cells = <1>;
>  		reg = <0xd4282000 0x1000>;
> -		mrvl,intc-nr-irqs = <64>;
> +		marvell,intc-nr-irqs = <64>;
>  	};
>  
>  	intcmux4 at d4282150 {
> -		compatible = "mrvl,mmp2-mux-intc";
> +		compatible = "marvell,mmp2-mux-intc";
>  		interrupts = <4>;
>  		interrupt-controller;
>  		#interrupt-cells = <1>;
>  		reg = <0x150 0x4>, <0x168 0x4>;
>  		reg-names = "mux status", "mux mask";
> -		mrvl,intc-nr-irqs = <2>;
> +		marvell,intc-nr-irqs = <2>;
>  	};
>  
>  * Marvell Orion Interrupt controller
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> index 117d741..87f1d42 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> @@ -3,12 +3,12 @@ Marvell Platforms Device Tree Bindings
>  
>  PXA168 Aspenite Board
>  Required root node properties:
> -	- compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
> +	- compatible = "marvell,pxa168-aspenite", "marvell,pxa168";
>  
>  PXA910 DKB Board
>  Required root node properties:
> -	- compatible = "mrvl,pxa910-dkb";
> +	- compatible = "marvell,pxa910-dkb";
>  
>  MMP2 Brownstone Board
>  Required root node properties:
> -	- compatible = "mrvl,mmp2-brownstone";
> +	- compatible = "marvell,mmp2-brownstone";
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/timer.txt b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> index 9a6e251..1304526 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> @@ -1,13 +1,13 @@
>  * Marvell MMP Timer controller
>  
>  Required properties:
> -- compatible : Should be "mrvl,mmp-timer".
> +- compatible : Should be "marvell,mmp-timer".
>  - reg : Address and length of the register set of timer controller.
>  - interrupts : Should be the interrupt number.
>  
>  Example:
>  	timer0: timer at d4014000 {
> -		compatible = "mrvl,mmp-timer";
> +		compatible = "marvell,mmp-timer";
>  		reg = <0xd4014000 0x100>;
>  		interrupts = <13>;
>  	};
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> index 12b78ac..34fdf5d 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> @@ -3,9 +3,9 @@
>  Required properties :
>  
>   - reg : Offset and length of the register set for the device
> - - compatible : should be "mrvl,mmp-twsi" where mmp is the name of a
> + - compatible : should be "marvell,mmp-twsi" where mmp is the name of a
>     compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
> -   For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
> +   For the pxa2xx/pxa3xx, an additional node "marvell,pxa-i2c" is required
>     as shown in the example below.
>  
>  Recommended properties :
> @@ -14,20 +14,20 @@ Recommended properties :
>   - interrupt-parent : the phandle for the interrupt controller that
>     services interrupts for this device. If the parent is the default
>     interrupt controller in device tree, it could be ignored.
> - - mrvl,i2c-polling : Disable interrupt of i2c controller. Polling
> + - marvell,i2c-polling : Disable interrupt of i2c controller. Polling
>     status register of i2c controller instead.
> - - mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
> + - marvell,i2c-fast-mode : Enable fast mode of i2c controller.
>  
>  Examples:
>  	twsi1: i2c at d4011000 {
> -		compatible = "mrvl,mmp-twsi";
> +		compatible = "marvell,mmp-twsi";
>  		reg = <0xd4011000 0x1000>;
>  		interrupts = <7>;
> -		mrvl,i2c-fast-mode;
> +		marvell,i2c-fast-mode;
>  	};
>  	
>  	twsi2: i2c at d4025000 {
> -		compatible = "mrvl,mmp-twsi";
> +		compatible = "marvell,mmp-twsi";
>  		reg = <0xd4025000 0x1000>;
>  		interrupts = <58>;
>  	};
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
> index dbe98a3..d603a3e 100644
> --- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
> @@ -4,18 +4,18 @@ This file documents differences between the core properties in mmc.txt
>  and the properties used by the sdhci-pxav2 and sdhci-pxav3 drivers.
>  
>  Required properties:
> -- compatible: Should be "mrvl,pxav2-mmc" or "mrvl,pxav3-mmc".
> +- compatible: Should be "marvell,pxav2-mmc" or "marvell,pxav3-mmc".
>  
>  Optional properties:
> -- mrvl,clk-delay-cycles: Specify a number of cycles to delay for tuning.
> +- marvell,clk-delay-cycles: Specify a number of cycles to delay for tuning.
>  
>  Example:
>  
>  sdhci at d4280800 {
> -	compatible = "mrvl,pxav3-mmc";
> +	compatible = "marvell,pxav3-mmc";
>  	reg = <0xd4280800 0x800>;
>  	bus-width = <8>;
>  	interrupts = <27>;
>  	non-removable;
> -	mrvl,clk-delay-cycles = <31>;
> +	marvell,clk-delay-cycles = <31>;
>  };
> diff --git a/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt b/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
> index 0cda19a..886fe15 100644
> --- a/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
> +++ b/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
> @@ -1,7 +1,7 @@
>  * Marvell Real Time Clock controller
>  
>  Required properties:
> -- compatible: should be "mrvl,sa1100-rtc"
> +- compatible: should be "marvell,sa1100-rtc"
>  - reg: physical base address of the controller and length of memory mapped
>    region.
>  - interrupts: Should be two. The first interrupt number is the rtc alarm
> @@ -10,7 +10,7 @@ Required properties:
>  
>  Example:
>  	rtc: rtc at d4010000 {
> -		compatible = "mrvl,mmp-rtc";
> +		compatible = "marvell,mmp-rtc";
>  		reg = <0xd4010000 0x1000>;
>  		interrupts = <5>, <6>;
>  		interrupt-name = "rtc 1Hz", "rtc alarm";
> diff --git a/Documentation/devicetree/bindings/serial/mrvl-serial.txt b/Documentation/devicetree/bindings/serial/mrvl-serial.txt
> index d744340..659d35e 100644
> --- a/Documentation/devicetree/bindings/serial/mrvl-serial.txt
> +++ b/Documentation/devicetree/bindings/serial/mrvl-serial.txt
> @@ -1,4 +1,4 @@
>  PXA UART controller
>  
>  Required properties:
> -- compatible : should be "mrvl,mmp-uart" or "mrvl,pxa-uart".
> +- compatible : should be "marvell,mmp-uart" or "marvell,pxa-uart".
> diff --git a/arch/arm/boot/dts/mmp2-brownstone.dts b/arch/arm/boot/dts/mmp2-brownstone.dts
> index 7f70a39..26abfde 100644
> --- a/arch/arm/boot/dts/mmp2-brownstone.dts
> +++ b/arch/arm/boot/dts/mmp2-brownstone.dts
> @@ -12,7 +12,7 @@
>  
>  / {
>  	model = "Marvell MMP2 Brownstone Development Board";
> -	compatible = "mrvl,mmp2-brownstone", "mrvl,mmp2";
> +	compatible = "marvell,mmp2-brownstone", "marvell,mmp2";
>  
>  	chosen {
>  		bootargs = "console=ttyS2,38400 root=/dev/nfs nfsroot=192.168.1.100:/nfsroot/ ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
> diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
> index 4e8b08c..ac13654 100644
> --- a/arch/arm/boot/dts/mmp2.dtsi
> +++ b/arch/arm/boot/dts/mmp2.dtsi
> @@ -32,128 +32,128 @@
>  		};
>  
>  		axi at d4200000 {	/* AXI */
> -			compatible = "mrvl,axi-bus", "simple-bus";
> +			compatible = "marvell,axi-bus", "simple-bus";
>  			#address-cells = <1>;
>  			#size-cells = <1>;
>  			reg = <0xd4200000 0x00200000>;
>  			ranges;
>  
>  			intc: interrupt-controller at d4282000 {
> -				compatible = "mrvl,mmp2-intc";
> +				compatible = "marvell,mmp2-intc";
>  				interrupt-controller;
>  				#interrupt-cells = <1>;
>  				reg = <0xd4282000 0x1000>;
> -				mrvl,intc-nr-irqs = <64>;
> +				marvell,intc-nr-irqs = <64>;
>  			};
>  
>  			intcmux4: interrupt-controller at d4282150 {
> -				compatible = "mrvl,mmp2-mux-intc";
> +				compatible = "marvell,mmp2-mux-intc";
>  				interrupts = <4>;
>  				interrupt-controller;
>  				#interrupt-cells = <1>;
>  				reg = <0x150 0x4>, <0x168 0x4>;
>  				reg-names = "mux status", "mux mask";
> -				mrvl,intc-nr-irqs = <2>;
> +				marvell,intc-nr-irqs = <2>;
>  			};
>  
>  			intcmux5: interrupt-controller at d4282154 {
> -				compatible = "mrvl,mmp2-mux-intc";
> +				compatible = "marvell,mmp2-mux-intc";
>  				interrupts = <5>;
>  				interrupt-controller;
>  				#interrupt-cells = <1>;
>  				reg = <0x154 0x4>, <0x16c 0x4>;
>  				reg-names = "mux status", "mux mask";
> -				mrvl,intc-nr-irqs = <2>;
> -				mrvl,clr-mfp-irq = <1>;
> +				marvell,intc-nr-irqs = <2>;
> +				marvell,clr-mfp-irq = <1>;
>  			};
>  
>  			intcmux9: interrupt-controller at d4282180 {
> -				compatible = "mrvl,mmp2-mux-intc";
> +				compatible = "marvell,mmp2-mux-intc";
>  				interrupts = <9>;
>  				interrupt-controller;
>  				#interrupt-cells = <1>;
>  				reg = <0x180 0x4>, <0x17c 0x4>;
>  				reg-names = "mux status", "mux mask";
> -				mrvl,intc-nr-irqs = <3>;
> +				marvell,intc-nr-irqs = <3>;
>  			};
>  
>  			intcmux17: interrupt-controller at d4282158 {
> -				compatible = "mrvl,mmp2-mux-intc";
> +				compatible = "marvell,mmp2-mux-intc";
>  				interrupts = <17>;
>  				interrupt-controller;
>  				#interrupt-cells = <1>;
>  				reg = <0x158 0x4>, <0x170 0x4>;
>  				reg-names = "mux status", "mux mask";
> -				mrvl,intc-nr-irqs = <5>;
> +				marvell,intc-nr-irqs = <5>;
>  			};
>  
>  			intcmux35: interrupt-controller at d428215c {
> -				compatible = "mrvl,mmp2-mux-intc";
> +				compatible = "marvell,mmp2-mux-intc";
>  				interrupts = <35>;
>  				interrupt-controller;
>  				#interrupt-cells = <1>;
>  				reg = <0x15c 0x4>, <0x174 0x4>;
>  				reg-names = "mux status", "mux mask";
> -				mrvl,intc-nr-irqs = <15>;
> +				marvell,intc-nr-irqs = <15>;
>  			};
>  
>  			intcmux51: interrupt-controller at d4282160 {
> -				compatible = "mrvl,mmp2-mux-intc";
> +				compatible = "marvell,mmp2-mux-intc";
>  				interrupts = <51>;
>  				interrupt-controller;
>  				#interrupt-cells = <1>;
>  				reg = <0x160 0x4>, <0x178 0x4>;
>  				reg-names = "mux status", "mux mask";
> -				mrvl,intc-nr-irqs = <2>;
> +				marvell,intc-nr-irqs = <2>;
>  			};
>  
>  			intcmux55: interrupt-controller at d4282188 {
> -				compatible = "mrvl,mmp2-mux-intc";
> +				compatible = "marvell,mmp2-mux-intc";
>  				interrupts = <55>;
>  				interrupt-controller;
>  				#interrupt-cells = <1>;
>  				reg = <0x188 0x4>, <0x184 0x4>;
>  				reg-names = "mux status", "mux mask";
> -				mrvl,intc-nr-irqs = <2>;
> +				marvell,intc-nr-irqs = <2>;
>  			};
>  		};
>  
>  		apb at d4000000 {	/* APB */
> -			compatible = "mrvl,apb-bus", "simple-bus";
> +			compatible = "marvell,apb-bus", "simple-bus";
>  			#address-cells = <1>;
>  			#size-cells = <1>;
>  			reg = <0xd4000000 0x00200000>;
>  			ranges;
>  
>  			timer0: timer at d4014000 {
> -				compatible = "mrvl,mmp-timer";
> +				compatible = "marvell,mmp-timer";
>  				reg = <0xd4014000 0x100>;
>  				interrupts = <13>;
>  			};
>  
>  			uart1: uart at d4030000 {
> -				compatible = "mrvl,mmp-uart";
> +				compatible = "marvell,mmp-uart";
>  				reg = <0xd4030000 0x1000>;
>  				interrupts = <27>;
>  				status = "disabled";
>  			};
>  
>  			uart2: uart at d4017000 {
> -				compatible = "mrvl,mmp-uart";
> +				compatible = "marvell,mmp-uart";
>  				reg = <0xd4017000 0x1000>;
>  				interrupts = <28>;
>  				status = "disabled";
>  			};
>  
>  			uart3: uart at d4018000 {
> -				compatible = "mrvl,mmp-uart";
> +				compatible = "marvell,mmp-uart";
>  				reg = <0xd4018000 0x1000>;
>  				interrupts = <24>;
>  				status = "disabled";
>  			};
>  
>  			uart4: uart at d4016000 {
> -				compatible = "mrvl,mmp-uart";
> +				compatible = "marvell,mmp-uart";
>  				reg = <0xd4016000 0x1000>;
>  				interrupts = <46>;
>  				status = "disabled";
> @@ -198,24 +198,24 @@
>  			};
>  
>  			twsi1: i2c at d4011000 {
> -				compatible = "mrvl,mmp-twsi";
> +				compatible = "marvell,mmp-twsi";
>  				reg = <0xd4011000 0x1000>;
>  				interrupts = <7>;
>  				#address-cells = <1>;
>  				#size-cells = <0>;
> -				mrvl,i2c-fast-mode;
> +				marvell,i2c-fast-mode;
>  				status = "disabled";
>  			};
>  
>  			twsi2: i2c at d4025000 {
> -				compatible = "mrvl,mmp-twsi";
> +				compatible = "marvell,mmp-twsi";
>  				reg = <0xd4025000 0x1000>;
>  				interrupts = <58>;
>  				status = "disabled";
>  			};
>  
>  			rtc: rtc at d4010000 {
> -				compatible = "mrvl,mmp-rtc";
> +				compatible = "marvell,mmp-rtc";
>  				reg = <0xd4010000 0x1000>;
>  				interrupts = <1 0>;
>  				interrupt-names = "rtc 1Hz", "rtc alarm";
> diff --git a/arch/arm/boot/dts/pxa168-aspenite.dts b/arch/arm/boot/dts/pxa168-aspenite.dts
> index e762fac..1e2ac17 100644
> --- a/arch/arm/boot/dts/pxa168-aspenite.dts
> +++ b/arch/arm/boot/dts/pxa168-aspenite.dts
> @@ -12,7 +12,7 @@
>  
>  / {
>  	model = "Marvell PXA168 Aspenite Development Board";
> -	compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
> +	compatible = "marvell,pxa168-aspenite", "marvell,pxa168";
>  
>  	chosen {
>  		bootargs = "console=ttyS0,115200 root=/dev/nfs nfsroot=192.168.1.100:/nfsroot/ ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
> diff --git a/arch/arm/boot/dts/pxa168.dtsi b/arch/arm/boot/dts/pxa168.dtsi
> index 975dad2..c08f5fc 100644
> --- a/arch/arm/boot/dts/pxa168.dtsi
> +++ b/arch/arm/boot/dts/pxa168.dtsi
> @@ -26,51 +26,51 @@
>  		ranges;
>  
>  		axi at d4200000 {	/* AXI */
> -			compatible = "mrvl,axi-bus", "simple-bus";
> +			compatible = "marvell,axi-bus", "simple-bus";
>  			#address-cells = <1>;
>  			#size-cells = <1>;
>  			reg = <0xd4200000 0x00200000>;
>  			ranges;
>  
>  			intc: interrupt-controller at d4282000 {
> -				compatible = "mrvl,mmp-intc";
> +				compatible = "marvell,mmp-intc";
>  				interrupt-controller;
>  				#interrupt-cells = <1>;
>  				reg = <0xd4282000 0x1000>;
> -				mrvl,intc-nr-irqs = <64>;
> +				marvell,intc-nr-irqs = <64>;
>  			};
>  
>  		};
>  
>  		apb at d4000000 {	/* APB */
> -			compatible = "mrvl,apb-bus", "simple-bus";
> +			compatible = "marvell,apb-bus", "simple-bus";
>  			#address-cells = <1>;
>  			#size-cells = <1>;
>  			reg = <0xd4000000 0x00200000>;
>  			ranges;
>  
>  			timer0: timer at d4014000 {
> -				compatible = "mrvl,mmp-timer";
> +				compatible = "marvell,mmp-timer";
>  				reg = <0xd4014000 0x100>;
>  				interrupts = <13>;
>  			};
>  
>  			uart1: uart at d4017000 {
> -				compatible = "mrvl,mmp-uart";
> +				compatible = "marvell,mmp-uart";
>  				reg = <0xd4017000 0x1000>;
>  				interrupts = <27>;
>  				status = "disabled";
>  			};
>  
>  			uart2: uart at d4018000 {
> -				compatible = "mrvl,mmp-uart";
> +				compatible = "marvell,mmp-uart";
>  				reg = <0xd4018000 0x1000>;
>  				interrupts = <28>;
>  				status = "disabled";
>  			};
>  
>  			uart3: uart at d4026000 {
> -				compatible = "mrvl,mmp-uart";
> +				compatible = "marvell,mmp-uart";
>  				reg = <0xd4026000 0x1000>;
>  				interrupts = <29>;
>  				status = "disabled";
> @@ -107,22 +107,22 @@
>  			};
>  
>  			twsi1: i2c at d4011000 {
> -				compatible = "mrvl,mmp-twsi";
> +				compatible = "marvell,mmp-twsi";
>  				reg = <0xd4011000 0x1000>;
>  				interrupts = <7>;
> -				mrvl,i2c-fast-mode;
> +				marvell,i2c-fast-mode;
>  				status = "disabled";
>  			};
>  
>  			twsi2: i2c at d4025000 {
> -				compatible = "mrvl,mmp-twsi";
> +				compatible = "marvell,mmp-twsi";
>  				reg = <0xd4025000 0x1000>;
>  				interrupts = <58>;
>  				status = "disabled";
>  			};
>  
>  			rtc: rtc at d4010000 {
> -				compatible = "mrvl,mmp-rtc";
> +				compatible = "marvell,mmp-rtc";
>  				reg = <0xd4010000 0x1000>;
>  				interrupts = <5 6>;
>  				interrupt-names = "rtc 1Hz", "rtc alarm";
> diff --git a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx.dtsi
> index a5e90f0..c426b1e 100644
> --- a/arch/arm/boot/dts/pxa2xx.dtsi
> +++ b/arch/arm/boot/dts/pxa2xx.dtsi
> @@ -47,7 +47,7 @@
>  		};
>  
>  		gpio: gpio at 40e00000 {
> -			compatible = "mrvl,pxa-gpio";
> +			compatible = "marvell,pxa-gpio";
>  			#address-cells = <0x1>;
>  			#size-cells = <0x1>;
>  			reg = <0x40e00000 0x10000>;
> @@ -76,35 +76,35 @@
>  		};
>  
>  		ffuart: uart at 40100000 {
> -			compatible = "mrvl,pxa-uart";
> +			compatible = "marvell,pxa-uart";
>  			reg = <0x40100000 0x30>;
>  			interrupts = <22>;
>  			status = "disabled";
>  		};
>  
>  		btuart: uart at 40200000 {
> -			compatible = "mrvl,pxa-uart";
> +			compatible = "marvell,pxa-uart";
>  			reg = <0x40200000 0x30>;
>  			interrupts = <21>;
>  			status = "disabled";
>  		};
>  
>  		stuart: uart at 40700000 {
> -			compatible = "mrvl,pxa-uart";
> +			compatible = "marvell,pxa-uart";
>  			reg = <0x40700000 0x30>;
>  			interrupts = <20>;
>  			status = "disabled";
>  		};
>  
>  		hwuart: uart at 41100000 {
> -			compatible = "mrvl,pxa-uart";
> +			compatible = "marvell,pxa-uart";
>  			reg = <0x41100000 0x30>;
>  			interrupts = <7>;
>  			status = "disabled";
>  		};
>  
>  		pxai2c1: i2c at 40301680 {
> -			compatible = "mrvl,pxa-i2c";
> +			compatible = "marvell,pxa-i2c";
>  			reg = <0x40301680 0x30>;
>  			interrupts = <18>;
>  			#address-cells = <0x1>;
> @@ -113,14 +113,14 @@
>  		};
>  
>  		usb0: ohci at 4c000000 {
> -			compatible = "mrvl,pxa-ohci";
> +			compatible = "marvell,pxa-ohci";
>  			reg = <0x4c000000 0x10000>;
>  			interrupts = <3>;
>  			status = "disabled";
>  		};
>  
>  		mmc0: mmc at 41100000 {
> -			compatible = "mrvl,pxa-mmc";
> +			compatible = "marvell,pxa-mmc";
>  			reg = <0x41100000 0x1000>;
>  			interrupts = <23>;
>  			status = "disabled";
> diff --git a/arch/arm/boot/dts/pxa3xx.dtsi b/arch/arm/boot/dts/pxa3xx.dtsi
> index f9d92da..0798031 100644
> --- a/arch/arm/boot/dts/pxa3xx.dtsi
> +++ b/arch/arm/boot/dts/pxa3xx.dtsi
> @@ -7,7 +7,7 @@
>  
>  	pxabus {
>  		pwri2c: i2c at 40f500c0 {
> -			compatible = "mrvl,pwri2c";
> +			compatible = "marvell,pwri2c";
>  			reg = <0x40f500c0 0x30>;
>  			interrupts = <6>;
>  			#address-cells = <0x1>;
> diff --git a/arch/arm/boot/dts/pxa910-dkb.dts b/arch/arm/boot/dts/pxa910-dkb.dts
> index 595492a..7384254 100644
> --- a/arch/arm/boot/dts/pxa910-dkb.dts
> +++ b/arch/arm/boot/dts/pxa910-dkb.dts
> @@ -12,7 +12,7 @@
>  
>  / {
>  	model = "Marvell PXA910 DKB Development Board";
> -	compatible = "mrvl,pxa910-dkb", "mrvl,pxa910";
> +	compatible = "marvell,pxa910-dkb", "marvell,pxa910";
>  
>  	chosen {
>  		bootargs = "console=ttyS0,115200 root=/dev/nfs nfsroot=192.168.1.100:/nfsroot/ ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
> diff --git a/arch/arm/boot/dts/pxa910.dtsi b/arch/arm/boot/dts/pxa910.dtsi
> index 0247c62..b5594a0 100644
> --- a/arch/arm/boot/dts/pxa910.dtsi
> +++ b/arch/arm/boot/dts/pxa910.dtsi
> @@ -31,58 +31,59 @@
>  		};
>  
>  		axi at d4200000 {	/* AXI */
> -			compatible = "mrvl,axi-bus", "simple-bus";
> +			compatible = "marvell,axi-bus", "simple-bus";
>  			#address-cells = <1>;
>  			#size-cells = <1>;
>  			reg = <0xd4200000 0x00200000>;
>  			ranges;
>  
>  			intc: interrupt-controller at d4282000 {
> -				compatible = "mrvl,mmp-intc";
> +				compatible = "marvell,mmp-intc";
>  				interrupt-controller;
>  				#interrupt-cells = <1>;
>  				reg = <0xd4282000 0x1000>;
> -				mrvl,intc-nr-irqs = <64>;
> +				marvell,intc-nr-irqs = <64>;
> +
>  			};
>  
>  		};
>  
>  		apb at d4000000 {	/* APB */
> -			compatible = "mrvl,apb-bus", "simple-bus";
> +			compatible = "marvell,apb-bus", "simple-bus";
>  			#address-cells = <1>;
>  			#size-cells = <1>;
>  			reg = <0xd4000000 0x00200000>;
>  			ranges;
>  
>  			timer0: timer at d4014000 {
> -				compatible = "mrvl,mmp-timer";
> +				compatible = "marvell,mmp-timer";
>  				reg = <0xd4014000 0x100>;
>  				interrupts = <13>;
>  			};
>  
>  			timer1: timer at d4016000 {
> -				compatible = "mrvl,mmp-timer";
> +				compatible = "marvell,mmp-timer";
>  				reg = <0xd4016000 0x100>;
>  				interrupts = <29>;
>  				status = "disabled";
>  			};
>  
>  			uart1: uart at d4017000 {
> -				compatible = "mrvl,mmp-uart";
> +				compatible = "marvell,mmp-uart";
>  				reg = <0xd4017000 0x1000>;
>  				interrupts = <27>;
>  				status = "disabled";
>  			};
>  
>  			uart2: uart at d4018000 {
> -				compatible = "mrvl,mmp-uart";
> +				compatible = "marvell,mmp-uart";
>  				reg = <0xd4018000 0x1000>;
>  				interrupts = <28>;
>  				status = "disabled";
>  			};
>  
>  			uart3: uart at d4036000 {
> -				compatible = "mrvl,mmp-uart";
> +				compatible = "marvell,mmp-uart";
>  				reg = <0xd4036000 0x1000>;
>  				interrupts = <59>;
>  				status = "disabled";
> @@ -119,17 +120,17 @@
>  			};
>  
>  			twsi1: i2c at d4011000 {
> -				compatible = "mrvl,mmp-twsi";
> +				compatible = "marvell,mmp-twsi";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
>  				reg = <0xd4011000 0x1000>;
>  				interrupts = <7>;
> -				mrvl,i2c-fast-mode;
> +				marvell,i2c-fast-mode;
>  				status = "disabled";
>  			};
>  
>  			twsi2: i2c at d4037000 {
> -				compatible = "mrvl,mmp-twsi";
> +				compatible = "marvell,mmp-twsi";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
>  				reg = <0xd4037000 0x1000>;
> @@ -138,7 +139,7 @@
>  			};
>  
>  			rtc: rtc at d4010000 {
> -				compatible = "mrvl,mmp-rtc";
> +				compatible = "marvell,mmp-rtc";
>  				reg = <0xd4010000 0x1000>;
>  				interrupts = <5 6>;
>  				interrupt-names = "rtc 1Hz", "rtc alarm";
> diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c
> index 3c71246..a7a53611 100644
> --- a/arch/arm/mach-mmp/irq.c
> +++ b/arch/arm/mach-mmp/irq.c
> @@ -327,13 +327,13 @@ void __init mmp2_init_icu(void)
>  
>  #ifdef CONFIG_OF
>  static const struct of_device_id intc_ids[] __initconst = {
> -	{ .compatible = "mrvl,mmp-intc", .data = &mmp_conf },
> -	{ .compatible = "mrvl,mmp2-intc", .data = &mmp2_conf },
> +	{ .compatible = "marvell,mmp-intc", .data = &mmp_conf },
> +	{ .compatible = "marvell,mmp2-intc", .data = &mmp2_conf },
>  	{}
>  };
>  
>  static const struct of_device_id mmp_mux_irq_match[] __initconst = {
> -	{ .compatible = "mrvl,mmp2-mux-intc" },
> +	{ .compatible = "marvell,mmp2-mux-intc" },
>  	{}
>  };
>  
> @@ -352,10 +352,10 @@ int __init mmp2_mux_init(struct device_node *parent)
>  		if (!node)
>  			break;
>  		of_id = of_match_node(&mmp_mux_irq_match[0], node);
> -		ret = of_property_read_u32(node, "mrvl,intc-nr-irqs",
> +		ret = of_property_read_u32(node, "marvell,intc-nr-irqs",
>  					   &nr_irqs);
>  		if (ret) {
> -			pr_err("Not found mrvl,intc-nr-irqs property\n");
> +			pr_err("Not found marvell,intc-nr-irqs property\n");
>  			ret = -EINVAL;
>  			goto err;
>  		}
> @@ -385,7 +385,7 @@ int __init mmp2_mux_init(struct device_node *parent)
>  			ret = irq_base;
>  			goto err;
>  		}
> -		if (!of_property_read_u32(node, "mrvl,clr-mfp-irq",
> +		if (!of_property_read_u32(node, "marvell,clr-mfp-irq",
>  					  &mfp_irq)) {
>  			icu_data[i].clr_mfp_irq_base = irq_base;
>  			icu_data[i].clr_mfp_hwirq = mfp_irq;
> @@ -424,9 +424,9 @@ void __init mmp_dt_irq_init(void)
>  	of_id = of_match_node(intc_ids, node);
>  	conf = of_id->data;
>  
> -	ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", &nr_irqs);
> +	ret = of_property_read_u32(node, "marvell,intc-nr-irqs", &nr_irqs);
>  	if (ret) {
> -		pr_err("Not found mrvl,intc-nr-irqs property\n");
> +		pr_err("Not found marvell,intc-nr-irqs property\n");
>  		return;
>  	}
>  
> diff --git a/arch/arm/mach-mmp/mmp-dt.c b/arch/arm/mach-mmp/mmp-dt.c
> index b37915d..62c5adb 100644
> --- a/arch/arm/mach-mmp/mmp-dt.c
> +++ b/arch/arm/mach-mmp/mmp-dt.c
> @@ -23,24 +23,24 @@ extern void __init mmp_dt_irq_init(void);
>  extern void __init mmp_dt_init_timer(void);
>  
>  static const struct of_dev_auxdata pxa168_auxdata_lookup[] __initconst = {
> -	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4026000, "pxa2xx-uart.2", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4026000, "pxa2xx-uart.2", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1", NULL),
>  	OF_DEV_AUXDATA("marvell,mmp-gpio", 0xd4019000, "mmp-gpio", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
>  	{}
>  };
>  
>  static const struct of_dev_auxdata pxa910_auxdata_lookup[] __initconst = {
> -	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4036000, "pxa2xx-uart.2", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4037000, "pxa2xx-i2c.1", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4036000, "pxa2xx-uart.2", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4037000, "pxa2xx-i2c.1", NULL),
>  	OF_DEV_AUXDATA("marvell,mmp-gpio", 0xd4019000, "mmp-gpio", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
>  	{}
>  };
>  
> @@ -57,8 +57,8 @@ static void __init pxa910_dt_init(void)
>  }
>  
>  static const char *mmp_dt_board_compat[] __initdata = {
> -	"mrvl,pxa168-aspenite",
> -	"mrvl,pxa910-dkb",
> +	"marvell,pxa168-aspenite",
> +	"marvell,pxa910-dkb",
>  	NULL,
>  };
>  
> diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
> index 4ac2567..6523ecf 100644
> --- a/arch/arm/mach-mmp/mmp2-dt.c
> +++ b/arch/arm/mach-mmp/mmp2-dt.c
> @@ -25,14 +25,14 @@ extern void __init mmp_dt_irq_init(void);
>  extern void __init mmp_dt_init_timer(void);
>  
>  static const struct of_dev_auxdata mmp2_auxdata_lookup[] __initconst = {
> -	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4030000, "pxa2xx-uart.0", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.1", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.2", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4016000, "pxa2xx-uart.3", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4030000, "pxa2xx-uart.0", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4017000, "pxa2xx-uart.1", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4018000, "pxa2xx-uart.2", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4016000, "pxa2xx-uart.3", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1", NULL),
>  	OF_DEV_AUXDATA("marvell,mmp-gpio", 0xd4019000, "mmp2-gpio", NULL),
> -	OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
> +	OF_DEV_AUXDATA("marvell,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
>  	{}
>  };
>  
> @@ -43,7 +43,7 @@ static void __init mmp2_dt_init(void)
>  }
>  
>  static const char *mmp2_dt_board_compat[] __initdata = {
> -	"mrvl,mmp2-brownstone",
> +	"marvell,mmp2-brownstone",
>  	NULL,
>  };
>  
> diff --git a/arch/arm/mach-mmp/time.c b/arch/arm/mach-mmp/time.c
> index 7ac41e8..67e7d5c 100644
> --- a/arch/arm/mach-mmp/time.c
> +++ b/arch/arm/mach-mmp/time.c
> @@ -208,7 +208,7 @@ void __init timer_init(int irq)
>  
>  #ifdef CONFIG_OF
>  static struct of_device_id mmp_timer_dt_ids[] = {
> -	{ .compatible = "mrvl,mmp-timer", },
> +	{ .compatible = "marvell,mmp-timer", },
>  	{}
>  };
>  
> diff --git a/arch/arm/mach-pxa/pxa-dt.c b/arch/arm/mach-pxa/pxa-dt.c
> index 3835979..b679367 100644
> --- a/arch/arm/mach-pxa/pxa-dt.c
> +++ b/arch/arm/mach-pxa/pxa-dt.c
> @@ -23,15 +23,15 @@
>  extern void __init pxa3xx_dt_init_irq(void);
>  
>  static const struct of_dev_auxdata pxa3xx_auxdata_lookup[] __initconst = {
> -	OF_DEV_AUXDATA("mrvl,pxa-uart",		0x40100000, "pxa2xx-uart.0", NULL),
> -	OF_DEV_AUXDATA("mrvl,pxa-uart",		0x40200000, "pxa2xx-uart.1", NULL),
> -	OF_DEV_AUXDATA("mrvl,pxa-uart",		0x40700000, "pxa2xx-uart.2", NULL),
> -	OF_DEV_AUXDATA("mrvl,pxa-uart",		0x41600000, "pxa2xx-uart.3", NULL),
> +	OF_DEV_AUXDATA("marvell,pxa-uart",	0x40100000, "pxa2xx-uart.0", NULL),
> +	OF_DEV_AUXDATA("marvell,pxa-uart",	0x40200000, "pxa2xx-uart.1", NULL),
> +	OF_DEV_AUXDATA("marvell,pxa-uart",	0x40700000, "pxa2xx-uart.2", NULL),
> +	OF_DEV_AUXDATA("marvell,pxa-uart",	0x41600000, "pxa2xx-uart.3", NULL),
>  	OF_DEV_AUXDATA("marvell,pxa-mmc",	0x41100000, "pxa2xx-mci.0", NULL),
> -	OF_DEV_AUXDATA("mrvl,pxa-gpio",		0x40e00000, "pxa-gpio", NULL),
> +	OF_DEV_AUXDATA("marvell,pxa-gpio",	0x40e00000, "pxa-gpio", NULL),
>  	OF_DEV_AUXDATA("marvell,pxa-ohci",	0x4c000000, "pxa27x-ohci", NULL),
> -	OF_DEV_AUXDATA("mrvl,pxa-i2c",		0x40301680, "pxa2xx-i2c.0", NULL),
> -	OF_DEV_AUXDATA("mrvl,pwri2c",		0x40f500c0, "pxa3xx-i2c.1", NULL),
> +	OF_DEV_AUXDATA("marvell,pxa-i2c",	0x40301680, "pxa2xx-i2c.0", NULL),
> +	OF_DEV_AUXDATA("marvell,pwri2c",	0x40f500c0, "pxa3xx-i2c.1", NULL),
>  	OF_DEV_AUXDATA("marvell,pxa3xx-nand",	0x43100000, "pxa3xx-nand", NULL),
>  	{}
>  };
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index fbafed2..6f2b17d 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -1040,9 +1040,9 @@ static const struct i2c_algorithm i2c_pxa_pio_algorithm = {
>  };
>  
>  static struct of_device_id i2c_pxa_dt_ids[] = {
> -	{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
> -	{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
> -	{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA2XX },
> +	{ .compatible = "marvell,pxa-i2c", .data = (void *)REGS_PXA2XX },
> +	{ .compatible = "marvell,pwri2c", .data = (void *)REGS_PXA3XX },
> +	{ .compatible = "marvell,mmp-twsi", .data = (void *)REGS_PXA2XX },
>  	{}
>  };
>  MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
> @@ -1060,9 +1060,9 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
>  	/* For device tree we always use the dynamic or alias-assigned ID */
>  	i2c->adap.nr = -1;
>  
> -	if (of_get_property(np, "mrvl,i2c-polling", NULL))
> +	if (of_get_property(np, "marvell,i2c-polling", NULL))
>  		i2c->use_pio = 1;
> -	if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
> +	if (of_get_property(np, "marvell,i2c-fast-mode", NULL))
>  		i2c->fast_mode = 1;
>  	*i2c_types = (u32)(of_id->data);
>  	return 0;
> diff --git a/drivers/mmc/host/sdhci-pxav2.c b/drivers/mmc/host/sdhci-pxav2.c
> index 6a3f702..1dd6500 100644
> --- a/drivers/mmc/host/sdhci-pxav2.c
> +++ b/drivers/mmc/host/sdhci-pxav2.c
> @@ -120,7 +120,7 @@ static const struct sdhci_ops pxav2_sdhci_ops = {
>  #ifdef CONFIG_OF
>  static const struct of_device_id sdhci_pxav2_of_match[] = {
>  	{
> -		.compatible = "mrvl,pxav2-mmc",
> +		.compatible = "marvell,pxav2-mmc",
>  	},
>  	{},
>  };
> @@ -144,7 +144,7 @@ static struct sdhci_pxa_platdata *pxav2_get_mmc_pdata(struct device *dev)
>  	if (bus_width == 8)
>  		pdata->flags |= PXA_FLAG_SD_8_BIT_CAPABLE_SLOT;
>  
> -	of_property_read_u32(np, "mrvl,clk-delay-cycles", &clk_delay_cycles);
> +	of_property_read_u32(np, "marvell,clk-delay-cycles", &clk_delay_cycles);
>  	if (clk_delay_cycles > 0) {
>  		pdata->clk_delay_sel = 1;
>  		pdata->clk_delay_cycles = clk_delay_cycles;
> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
> index 1ae358e..a88974b 100644
> --- a/drivers/mmc/host/sdhci-pxav3.c
> +++ b/drivers/mmc/host/sdhci-pxav3.c
> @@ -185,7 +185,7 @@ static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
>  #ifdef CONFIG_OF
>  static const struct of_device_id sdhci_pxav3_of_match[] = {
>  	{
> -		.compatible = "mrvl,pxav3-mmc",
> +		.compatible = "marvell,pxav3-mmc",
>  	},
>  	{},
>  };
> @@ -201,7 +201,7 @@ static struct sdhci_pxa_platdata *pxav3_get_mmc_pdata(struct device *dev)
>  	if (!pdata)
>  		return NULL;
>  
> -	of_property_read_u32(np, "mrvl,clk-delay-cycles", &clk_delay_cycles);
> +	of_property_read_u32(np, "marvell,clk-delay-cycles", &clk_delay_cycles);
>  	if (clk_delay_cycles > 0)
>  		pdata->clk_delay_cycles = clk_delay_cycles;
>  
> diff --git a/drivers/rtc/rtc-sa1100.c b/drivers/rtc/rtc-sa1100.c
> index 0f7adeb..307dd37 100644
> --- a/drivers/rtc/rtc-sa1100.c
> +++ b/drivers/rtc/rtc-sa1100.c
> @@ -339,8 +339,8 @@ static SIMPLE_DEV_PM_OPS(sa1100_rtc_pm_ops, sa1100_rtc_suspend,
>  
>  #ifdef CONFIG_OF
>  static struct of_device_id sa1100_rtc_dt_ids[] = {
> -	{ .compatible = "mrvl,sa1100-rtc", },
> -	{ .compatible = "mrvl,mmp-rtc", },
> +	{ .compatible = "marvell,sa1100-rtc", },
> +	{ .compatible = "marvell,mmp-rtc", },
>  	{}
>  };
>  MODULE_DEVICE_TABLE(of, sa1100_rtc_dt_ids);
> diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
> index 05f504e..cb1a439 100644
> --- a/drivers/tty/serial/pxa.c
> +++ b/drivers/tty/serial/pxa.c
> @@ -852,8 +852,8 @@ static const struct dev_pm_ops serial_pxa_pm_ops = {
>  #endif
>  
>  static struct of_device_id serial_pxa_dt_ids[] = {
> -	{ .compatible = "mrvl,pxa-uart", },
> -	{ .compatible = "mrvl,mmp-uart", },
> +	{ .compatible = "marvell,pxa-uart", },
> +	{ .compatible = "marvell,mmp-uart", },
>  	{}
>  };
>  MODULE_DEVICE_TABLE(of, serial_pxa_dt_ids);
> -- 
> 1.7.4.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From magnus.damm at gmail.com  Tue Jul  9 08:50:07 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 21:50:07 +0900
Subject: [PATCH 00/02] ARM: shmobile: r8a7790 arch timer frequency update
Message-ID: <20130709125007.4388.15701.sendpatchset@w520>

ARM: shmobile: r8a7790 arch timer frequency update

[PATCH 01/02] ARM: shmobile: Introduce r8a7790_read_mode_pins()
[PATCH 02/02] ARM: shmobile: Setup r8a7790 arch timer based on MD pins

Add code to setup r8a7790 arch timer frequency dynamically at boot time
based on the EXTAL frequency pointed out by the boot mode pins.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Built on top of renesas-next-20130704v2

 arch/arm/mach-shmobile/clock-r8a7790.c        |   11 ----
 arch/arm/mach-shmobile/include/mach/r8a7790.h |    3 +
 arch/arm/mach-shmobile/setup-r8a7790.c        |   63 +++++++++++++++++++++++--
 3 files changed, 63 insertions(+), 14 deletions(-)


From magnus.damm at gmail.com  Tue Jul  9 08:50:16 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 21:50:16 +0900
Subject: [PATCH 01/02] ARM: shmobile: Introduce r8a7790_read_mode_pins()
In-Reply-To: <20130709125007.4388.15701.sendpatchset@w520>
References: <20130709125007.4388.15701.sendpatchset@w520>
Message-ID: <20130709125016.4388.47414.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Break out the r8a7790 boot mode code into a separate
function so it can be shared by multiple users.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/clock-r8a7790.c        |   11 ++---------
 arch/arm/mach-shmobile/include/mach/r8a7790.h |    3 +++
 arch/arm/mach-shmobile/setup-r8a7790.c        |   14 ++++++++++++++
 3 files changed, 19 insertions(+), 9 deletions(-)

--- 0001/arch/arm/mach-shmobile/clock-r8a7790.c
+++ work/arch/arm/mach-shmobile/clock-r8a7790.c	2013-07-09 20:03:09.000000000 +0900
@@ -24,6 +24,7 @@
 #include <linux/clkdev.h>
 #include <mach/clock.h>
 #include <mach/common.h>
+#include <mach/r8a7790.h>
 
 /*
  *   MD		EXTAL		PLL0	PLL1	PLL3
@@ -42,8 +43,6 @@
  *	see "p1 / 2" on R8A7790_CLOCK_ROOT() below
  */
 
-#define MD(nr)	(1 << nr)
-
 #define CPG_BASE 0xe6150000
 #define CPG_LEN 0x1000
 
@@ -53,7 +52,6 @@
 #define SMSTPCR5 0xe6150144
 #define SMSTPCR7 0xe615014c
 
-#define MODEMR		0xE6160060
 #define SDCKCR		0xE6150074
 #define SD2CKCR		0xE6150078
 #define SD3CKCR		0xE615007C
@@ -288,14 +286,9 @@ static struct clk_lookup lookups[] = {
 
 void __init r8a7790_clock_init(void)
 {
-	void __iomem *modemr = ioremap_nocache(MODEMR, PAGE_SIZE);
-	u32 mode;
+	u32 mode = r8a7790_read_mode_pins();
 	int k, ret = 0;
 
-	BUG_ON(!modemr);
-	mode = ioread32(modemr);
-	iounmap(modemr);
-
 	switch (mode & (MD(14) | MD(13))) {
 	case 0:
 		R8A7790_CLOCK_ROOT(15, &extal_clk, 172, 208, 106, 88);
--- 0001/arch/arm/mach-shmobile/include/mach/r8a7790.h
+++ work/arch/arm/mach-shmobile/include/mach/r8a7790.h	2013-07-09 20:02:34.000000000 +0900
@@ -8,4 +8,7 @@ void r8a7790_pinmux_init(void);
 void r8a7790_init_delay(void);
 void r8a7790_timer_init(void);
 
+#define MD(nr) BIT(nr)
+u32 r8a7790_read_mode_pins(void);
+
 #endif /* __ASM_R8A7790_H__ */
--- 0001/arch/arm/mach-shmobile/setup-r8a7790.c
+++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-07-09 19:59:37.000000000 +0900
@@ -201,6 +201,20 @@ void __init r8a7790_add_standard_devices
 	r8a7790_register_thermal();
 }
 
+#define MODEMR 0xe6160060
+
+u32 __init r8a7790_read_mode_pins(void)
+{
+	void __iomem *modemr = ioremap_nocache(MODEMR, PAGE_SIZE);
+	u32 mode;
+
+	BUG_ON(!modemr);
+	mode = ioread32(modemr);
+	iounmap(modemr);
+
+	return mode;
+}
+
 void __init r8a7790_timer_init(void)
 {
 	void __iomem *cntcr;


From magnus.damm at gmail.com  Tue Jul  9 08:50:24 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 09 Jul 2013 21:50:24 +0900
Subject: [PATCH 02/02] ARM: shmobile: Setup r8a7790 arch timer based on MD pins
In-Reply-To: <20130709125007.4388.15701.sendpatchset@w520>
References: <20130709125007.4388.15701.sendpatchset@w520>
Message-ID: <20130709125024.4388.50953.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Update the r8a7790 arch timer setup code to configure the
frequency dynamically at boot time. This means that the arch
timer driver will be able to detect a timer frequency that
has been calculated based on the MD pins instead of a fixed
and potentially incorrect 13 MHz.

With this patch applied the Linux kernel will correctly
support the r8a7790 Lager board that uses a 20 Mhz EXTAL.
The arch timer will operate on 10 MHz and the Linux arch
timer driver will be correctly configured to use 10 MHz.

Without this patch the 20 MHz EXTAL will be used to drive
the arch timer at 10 MHz, but the Linux arch timer driver
will believe it is counting at 13 Mhz.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-r8a7790.c |   49 ++++++++++++++++++++++++++++----
 1 file changed, 44 insertions(+), 5 deletions(-)

--- 0006/arch/arm/mach-shmobile/setup-r8a7790.c
+++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-07-09 21:29:18.000000000 +0900
@@ -215,14 +215,53 @@ u32 __init r8a7790_read_mode_pins(void)
 	return mode;
 }
 
+#define CNTCR 0
+#define CNTFID0 0x20
+
 void __init r8a7790_timer_init(void)
 {
-	void __iomem *cntcr;
+#ifdef CONFIG_ARM_ARCH_TIMER
+	u32 mode = r8a7790_read_mode_pins();
+	void __iomem *base;
+	int extal_mhz = 0;
+	u32 freq;
+
+	/* At Linux boot time the r8a7790 arch timer comes up
+	 * with the counter disabled. Moreover, it may also report
+	 * a potentially incorrect fixed 13 MHz frequency. To be
+	 * correct these registers need to be updated to use the
+	 * frequency EXTAL / 2 which can be determined by the MD pins.
+	 */
+
+	switch (mode & (MD(14) | MD(13))) {
+	case 0:
+		extal_mhz = 15;
+		break;
+	case MD(13):
+		extal_mhz = 20;
+		break;
+	case MD(14):
+		extal_mhz = 26;
+		break;
+	case MD(13) | MD(14):
+		extal_mhz = 30;
+		break;
+	}
+
+	/* The arch timer frequency equals EXTAL / 2 */
+	freq = extal_mhz * (1000000 / 2);
+
+	/* Remap "armgcnt address map" space */
+	base = ioremap(0xe6080000, PAGE_SIZE);
+
+	/* Update registers with correct frequency */
+	iowrite32(freq, base + CNTFID0);
+	asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
 
-	/* make sure arch timer is started by setting bit 0 of CNTCT */
-	cntcr = ioremap(0xe6080000, PAGE_SIZE);
-	iowrite32(1, cntcr);
-	iounmap(cntcr);
+	/* make sure arch timer is started by setting bit 0 of CNTCR */
+	iowrite32(1, base + CNTCR);
+	iounmap(base);
+#endif /* CONFIG_ARM_ARCH_TIMER */
 
 	shmobile_timer_init();
 }


From shawn.guo at linaro.org  Tue Jul  9 08:52:41 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Jul 2013 20:52:41 +0800
Subject: [PATCH 3/3] ARM:dts:vf610-twr:Enable DSPI0 devices and Flash
 at26df081a
In-Reply-To: <20130709100723.GS27646@sirena.org.uk>
References: <1373272622-29064-1-git-send-email-b44548@freescale.com>
 <1373272622-29064-3-git-send-email-b44548@freescale.com>
 <20130708113600.GU27646@sirena.org.uk>
 <20130709052925.GD16656@S2101-09.ap.freescale.net>
 <20130709100723.GS27646@sirena.org.uk>
Message-ID: <20130709125239.GA2813@S2101-09.ap.freescale.net>

On Tue, Jul 09, 2013 at 11:07:23AM +0100, Mark Brown wrote:
> On Tue, Jul 09, 2013 at 01:29:27PM +0800, Shawn Guo wrote:
> > On Mon, Jul 08, 2013 at 12:36:01PM +0100, Mark Brown wrote:
> 
> > > This should be fine to merge via arm-soc, it's no real dependency on the
> > > actual SPI driver.
> 
> > It has dependency on the actual SPI driver where the DT bindings are
> > defined, so I would only take the patches after the driver parts gets
> > accepted.
> 
> The bindings are all totally generic ones for a SPI controller, there's
> nothing controversial or even device specific about them so I'm happy to
> say the bindings are fine as-is.

Am I missing something?  I do not even see a bindings doc in patch #1.
How can I think the bindings are fine?

Shawn



From sergei.shtylyov at cogentembedded.com  Tue Jul  9 08:57:09 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 09 Jul 2013 16:57:09 +0400
Subject: [PATCH 01/02] ARM: shmobile: Introduce r8a7790_read_mode_pins()
In-Reply-To: <20130709125016.4388.47414.sendpatchset@w520>
References: <20130709125007.4388.15701.sendpatchset@w520>
 <20130709125016.4388.47414.sendpatchset@w520>
Message-ID: <51DC08A5.2080705@cogentembedded.com>

Hello.

On 09-07-2013 16:50, Magnus Damm wrote:

> From: Magnus Damm <damm at opensource.se>

> Break out the r8a7790 boot mode code into a separate
> function so it can be shared by multiple users.

> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---

[...]

> --- 0001/arch/arm/mach-shmobile/setup-r8a7790.c
> +++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-07-09 19:59:37.000000000 +0900
> @@ -201,6 +201,20 @@ void __init r8a7790_add_standard_devices
>   	r8a7790_register_thermal();
>   }
>
> +#define MODEMR 0xe6160060
> +
> +u32 __init r8a7790_read_mode_pins(void)
> +{
> +	void __iomem *modemr = ioremap_nocache(MODEMR, PAGE_SIZE);

    Why ioremap the whole page if you only need 4 bytes, and the address 
is not aligned to page?

> +	u32 mode;
> +
> +	BUG_ON(!modemr);
> +	mode = ioread32(modemr);
> +	iounmap(modemr);
> +
> +	return mode;
> +}
> +

WBR, Sergei



From sr at denx.de  Tue Jul  9 09:02:31 2013
From: sr at denx.de (Stefan Roese)
Date: Tue, 09 Jul 2013 15:02:31 +0200
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <1366024808-4691-1-git-send-email-rogerq@ti.com>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
Message-ID: <51DC09E7.1070302@denx.de>

Roger,

On 04/15/2013 01:20 PM, Roger Quadros wrote:
> On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
> reversed when compared to other revisions i.e. it is
> active high instead of active low.
> 
> Use the beagle_config.usb_pwr_level flag correctly so that
> the power regulator can be configured at runtime.
> 
> Signed-off-by: Roger Quadros <rogerq at ti.com>

I'm currently trying to use an SMSC95xx USB ethernet adapter on the
OMAP3 Beagleboard (old one "Beagle Rev C1/C2/C3") via the OMAP EHCI
controller. And am testing this by trying to mount the rootfs via NFS.
What I see is that the NFS mounting stalls/hangs most of the time quite
early in the mount process:

[    6.425689] VFS: Mounted root (nfs filesystem) on device 0:12.
[    6.435485] devtmpfs: mounted
[    6.440002] Freeing unused kernel memory: 384K (c077a000 - c07da000)
INIT: version 2.88 booting
Starting udev
[  188.311309] nfs: server 10.0.0.152 not responding, still trying
[  188.317687] nfs: server 10.0.0.152 not responding, still trying
...

Only very seldom the rootfs can be mounted successfully to the prompt.

I'm using latest kernel.org for this (git ID d2b4a646 also tested with
v3.10 release). This is with DT-enabled booting and without-DT (same
problem). I also tested some older Linux kernel versions and it fails
there as well. Only v3.2.40 seems to be able to mount this rootfs via
NFS reliably (approx. 10 times success).

Is this a known issue on the Beagleboard? Do you have any ideas what
might cause such an issue (unreliable USB connection, hangup of NFS
mounting)? Any hints/links appretiated.

Thanks,
Stefan



From magnus.damm at gmail.com  Tue Jul  9 09:03:19 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 9 Jul 2013 22:03:19 +0900
Subject: [PATCH] ARM: shmobile: Add SMSC ethernet chip to KZM9D DT
 reference
In-Reply-To: <51DBF7CD.8040009@cogentembedded.com>
References: <20130709042654.13658.20164.sendpatchset@w520>
 <51DBF7CD.8040009@cogentembedded.com>
Message-ID: <CANqRtoQfkk9KFggw5dadqih-kqNTCGC+kVCKkOUO8G=1w+kh6g@mail.gmail.com>

Hi Sergei,

On Tue, Jul 9, 2013 at 8:45 PM, Sergei Shtylyov
<sergei.shtylyov at cogentembedded.com> wrote:
> Hello.
>
>
> On 09-07-2013 8:26, Magnus Damm wrote:
>
>> From: Magnus Damm <damm at opensource.se>
>
>
>> Add support for the SMSC ethernet controller found
>> on the KZM9D board to the KZM9D DT Reference code.
>
>
>> Signed-off-by: Magnus Damm <damm at opensource.se>
>> ---
>
>
>>   Built on top of renesas-next-20130704v2 and
>>   [PATCH] ARM: shmobile: KZM9D DT reference implementation
>
>
>>   arch/arm/boot/dts/emev2-kzm9d-reference.dts |   31
>> +++++++++++++++++++++++++++
>>   1 file changed, 31 insertions(+)
>
>
>> --- 0002/arch/arm/boot/dts/emev2-kzm9d-reference.dts
>> +++ work/arch/arm/boot/dts/emev2-kzm9d-reference.dts    2013-07-09
>> 13:06:47.000000000 +0900
>> @@ -23,4 +23,35 @@
>
> [...]
>>
>> +       lan9220 at 20000000 {
>
>
>    Shouldn't all the Ethernet nodes be called "ethernet"?

Good question. Grepping in arch/arm/boot/dts shows various ways to
name the Ethernet nodes. Exactly what is correct or not I can't really
say.

Thanks for your feedback.

Cheers,

/ magnus


From magnus.damm at gmail.com  Tue Jul  9 09:05:15 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 9 Jul 2013 22:05:15 +0900
Subject: [PATCH 01/02] ARM: shmobile: Introduce r8a7790_read_mode_pins()
In-Reply-To: <51DC08A5.2080705@cogentembedded.com>
References: <20130709125007.4388.15701.sendpatchset@w520>
 <20130709125016.4388.47414.sendpatchset@w520>
 <51DC08A5.2080705@cogentembedded.com>
Message-ID: <CANqRtoTvSGvNWwBQ9XD43CtdJNJCebzC2xtXUQcFSXxATkuNpQ@mail.gmail.com>

Hi Sergei,

On Tue, Jul 9, 2013 at 9:57 PM, Sergei Shtylyov
<sergei.shtylyov at cogentembedded.com> wrote:
> Hello.
>
>
> On 09-07-2013 16:50, Magnus Damm wrote:
>
>> From: Magnus Damm <damm at opensource.se>
>
>
>> Break out the r8a7790 boot mode code into a separate
>> function so it can be shared by multiple users.
>
>
>> Signed-off-by: Magnus Damm <damm at opensource.se>
>> ---
>
>
> [...]
>
>
>> --- 0001/arch/arm/mach-shmobile/setup-r8a7790.c
>> +++ work/arch/arm/mach-shmobile/setup-r8a7790.c 2013-07-09
>> 19:59:37.000000000 +0900
>> @@ -201,6 +201,20 @@ void __init r8a7790_add_standard_devices
>>         r8a7790_register_thermal();
>>   }
>>
>> +#define MODEMR 0xe6160060
>> +
>> +u32 __init r8a7790_read_mode_pins(void)
>> +{
>> +       void __iomem *modemr = ioremap_nocache(MODEMR, PAGE_SIZE);
>
>
>    Why ioremap the whole page if you only need 4 bytes, and the address is
> not aligned to page?

Because the original code did so. =)

But yes, indeed, using two pages seems kind of pointless.

/ magnus


From sergei.shtylyov at cogentembedded.com  Tue Jul  9 09:09:52 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 09 Jul 2013 17:09:52 +0400
Subject: [PATCH] ARM: shmobile: Add SMSC ethernet chip to KZM9D DT
 reference
In-Reply-To: <CANqRtoQfkk9KFggw5dadqih-kqNTCGC+kVCKkOUO8G=1w+kh6g@mail.gmail.com>
References: <20130709042654.13658.20164.sendpatchset@w520>
 <51DBF7CD.8040009@cogentembedded.com>
 <CANqRtoQfkk9KFggw5dadqih-kqNTCGC+kVCKkOUO8G=1w+kh6g@mail.gmail.com>
Message-ID: <51DC0BA0.2060306@cogentembedded.com>

Hello.

On 09-07-2013 17:03, Magnus Damm wrote:

>>> From: Magnus Damm <damm at opensource.se>

>>> Add support for the SMSC ethernet controller found
>>> on the KZM9D board to the KZM9D DT Reference code.

>>> Signed-off-by: Magnus Damm <damm at opensource.se>
>>> ---

>>>    Built on top of renesas-next-20130704v2 and
>>>    [PATCH] ARM: shmobile: KZM9D DT reference implementation

>>>    arch/arm/boot/dts/emev2-kzm9d-reference.dts |   31
>>> +++++++++++++++++++++++++++
>>>    1 file changed, 31 insertions(+)

>>> --- 0002/arch/arm/boot/dts/emev2-kzm9d-reference.dts
>>> +++ work/arch/arm/boot/dts/emev2-kzm9d-reference.dts    2013-07-09
>>> 13:06:47.000000000 +0900
>>> @@ -23,4 +23,35 @@

>> [...]

>>> +       lan9220 at 20000000 {

>>     Shouldn't all the Ethernet nodes be called "ethernet"?

> Good question. Grepping in arch/arm/boot/dts shows various ways to
> name the Ethernet nodes. Exactly what is correct or not I can't really
> say.

    See "Node Names" section of [1].

[1] http://www.devicetree.org/Device_Tree_Usage

> Thanks for your feedback.

> Cheers,

> / magnus

WBR, Sergei



From ard.biesheuvel at linaro.org  Tue Jul  9 09:18:12 2013
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  9 Jul 2013 14:18:12 +0100
Subject: [PATCH v2] arm64: add support for kernel mode NEON
Message-ID: <1373375892-25390-1-git-send-email-ard.biesheuvel@linaro.org>

Add <asm/neon.h> containing kernel_neon_begin/kernel_neon_end function
declarations and corresponding definitions in fpsimd.c

These are needed to wrap uses of NEON in kernel mode. The names are
identical to the ones used in arm/ so code using intrinsics or
vectorized by GCC can be shared between arm and arm64.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/Kconfig            |  3 +++
 arch/arm64/include/asm/neon.h | 14 ++++++++++++++
 arch/arm64/kernel/fpsimd.c    | 28 ++++++++++++++++++++++++++++
 3 files changed, 45 insertions(+)
 create mode 100644 arch/arm64/include/asm/neon.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 56b3f6d..46ba680 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -95,6 +95,9 @@ config SWIOTLB
 config IOMMU_HELPER
 	def_bool SWIOTLB
 
+config KERNEL_MODE_NEON
+	def_bool y
+
 source "init/Kconfig"
 
 source "kernel/Kconfig.freezer"
diff --git a/arch/arm64/include/asm/neon.h b/arch/arm64/include/asm/neon.h
new file mode 100644
index 0000000..b0cc58a9
--- /dev/null
+++ b/arch/arm64/include/asm/neon.h
@@ -0,0 +1,14 @@
+/*
+ * linux/arch/arm64/include/asm/neon.h
+ *
+ * Copyright (C) 2013 Linaro Ltd <ard.biesheuvel at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define cpu_has_neon()		(1)
+
+void kernel_neon_begin(void);
+void kernel_neon_end(void);
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index e8b8357..1f2e4d5 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -21,6 +21,7 @@
 #include <linux/init.h>
 #include <linux/sched.h>
 #include <linux/signal.h>
+#include <linux/hardirq.h>
 
 #include <asm/fpsimd.h>
 #include <asm/cputype.h>
@@ -83,6 +84,33 @@ void fpsimd_flush_thread(void)
 	fpsimd_load_state(&current->thread.fpsimd_state);
 }
 
+#ifdef CONFIG_KERNEL_MODE_NEON
+
+/*
+ * Kernel-side NEON support functions
+ */
+void kernel_neon_begin(void)
+{
+	/* Avoid using the NEON in interrupt context */
+	BUG_ON(in_interrupt());
+	preempt_disable();
+
+	if (current->mm)
+		fpsimd_save_state(&current->thread.fpsimd_state);
+}
+EXPORT_SYMBOL(kernel_neon_begin);
+
+void kernel_neon_end(void)
+{
+	if (current->mm)
+		fpsimd_load_state(&current->thread.fpsimd_state);
+
+	preempt_enable();
+}
+EXPORT_SYMBOL(kernel_neon_end);
+
+#endif /* CONFIG_KERNEL_MODE_NEON */
+
 /*
  * FP/SIMD support code initialisation.
  */
-- 
1.8.1.2



From richard.genoud at gmail.com  Tue Jul  9 09:19:09 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 9 Jul 2013 15:19:09 +0200
Subject: [PATCH v3 3/7] Documentation: DT: update atmel SSC with DMA
 binding
In-Reply-To: <1373372929-17800-4-git-send-email-richard.genoud@gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373372929-17800-4-git-send-email-richard.genoud@gmail.com>
Message-ID: <CACQ1gAg8WQTaz4XkXJCH+-bNU_U3s_1pgmQYoQR3v-KHOzzBTA@mail.gmail.com>

2013/7/9 Richard Genoud <richard.genoud at gmail.com>:
> As atmel-ssc can be used with DMA, the documentation should be updated.
> Also, a configuration DMA example is given.
>
> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
> ---
>  .../devicetree/bindings/misc/atmel-ssc.txt         |   24 ++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
> index 38e51ad..96958ca 100644
> --- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
> +++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
> @@ -6,10 +6,30 @@ Required properties:
>         - atmel,at91sam9g45-ssc: support dma transfer
>  - reg: Should contain SSC registers location and length
>  - interrupts: Should contain SSC interrupt
> +For dma transfer:
> +- dmas: DMA specifier, consisting of a phandle to DMA controller node,
> +  the memory interface and SSC DMA channel ID (for tx and rx).
> +  See Documentation/devicetree/bindings/dma/atmel-dma.txt for details.
> +- dma-names: Must be "tx", "rx".
>
> -Example:
> +
> +Examples:
>  ssc0: ssc at fffbc000 {
>         compatible = "atmel,at91rm9200-ssc";
>         reg = <0xfffbc000 0x4000>;
> -       interrupts = <14 4 5>;
> +       interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>;
maybe I should not use macro in the documentation (not sure if I should or not).
>  };
> +
> +
> +ssc0: ssc at f0010000 {
> +      compatible = "atmel,at91sam9g45-ssc";
> +      reg = <0xf0010000 0x4000>;
> +      interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
> +      dmas = <&dma0 1 AT91_DMA_CFG_PER_ID(13)>,
> +            <&dma0 1 AT91_DMA_CFG_PER_ID(14)>;
same here
> +      dma-names = "tx", "rx";
> +      pinctrl-names = "default";
> +      pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
> +      status = "disabled";
> +};
> +
> --
> 1.7.10.4
>



-- 
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?


From nicolas.ferre at atmel.com  Tue Jul  9 09:20:38 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 9 Jul 2013 15:20:38 +0200
Subject: [PATCH v3 3/7] Documentation: DT: update atmel SSC with DMA
 binding
In-Reply-To: <CACQ1gAg8WQTaz4XkXJCH+-bNU_U3s_1pgmQYoQR3v-KHOzzBTA@mail.gmail.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373372929-17800-4-git-send-email-richard.genoud@gmail.com>
 <CACQ1gAg8WQTaz4XkXJCH+-bNU_U3s_1pgmQYoQR3v-KHOzzBTA@mail.gmail.com>
Message-ID: <51DC0E26.7080508@atmel.com>

On 09/07/2013 15:19, Richard Genoud :
> 2013/7/9 Richard Genoud <richard.genoud at gmail.com>:
>> As atmel-ssc can be used with DMA, the documentation should be updated.
>> Also, a configuration DMA example is given.
>>
>> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
>> ---
>>   .../devicetree/bindings/misc/atmel-ssc.txt         |   24 ++++++++++++++++++--
>>   1 file changed, 22 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
>> index 38e51ad..96958ca 100644
>> --- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
>> +++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
>> @@ -6,10 +6,30 @@ Required properties:
>>          - atmel,at91sam9g45-ssc: support dma transfer
>>   - reg: Should contain SSC registers location and length
>>   - interrupts: Should contain SSC interrupt
>> +For dma transfer:
>> +- dmas: DMA specifier, consisting of a phandle to DMA controller node,
>> +  the memory interface and SSC DMA channel ID (for tx and rx).
>> +  See Documentation/devicetree/bindings/dma/atmel-dma.txt for details.
>> +- dma-names: Must be "tx", "rx".
>>
>> -Example:
>> +
>> +Examples:
>>   ssc0: ssc at fffbc000 {
>>          compatible = "atmel,at91rm9200-ssc";
>>          reg = <0xfffbc000 0x4000>;
>> -       interrupts = <14 4 5>;
>> +       interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>;
> maybe I should not use macro in the documentation (not sure if I should or not).

absolutely.

>>   };
>> +
>> +
>> +ssc0: ssc at f0010000 {
>> +      compatible = "atmel,at91sam9g45-ssc";
>> +      reg = <0xf0010000 0x4000>;
>> +      interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
>> +      dmas = <&dma0 1 AT91_DMA_CFG_PER_ID(13)>,
>> +            <&dma0 1 AT91_DMA_CFG_PER_ID(14)>;
> same here
>> +      dma-names = "tx", "rx";
>> +      pinctrl-names = "default";
>> +      pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
>> +      status = "disabled";
>> +};
>> +
>> --
>> 1.7.10.4
>>
>
>
>


-- 
Nicolas Ferre


From plagnioj at jcrosoft.com  Tue Jul  9 09:26:10 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 9 Jul 2013 15:26:10 +0200
Subject: [PATCH 4/7] serial: at91: make DBGU support dma and pdc transfers
In-Reply-To: <1373351626-30143-5-git-send-email-elen.song@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
 <1373351626-30143-5-git-send-email-elen.song@atmel.com>
Message-ID: <20130709132610.GD18012@ns203013.ovh.net>

On 14:33 Tue 09 Jul     , Elen Song wrote:
> Because the DBGU lack of receive timeout register, so we use a timer to trigger
> data receive.
> 
> Signed-off-by: Elen Song <elen.song at atmel.com>
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
> ---
>  drivers/tty/serial/atmel_serial.c |   51 ++++++++++++++++++++++++++++++-------
>  1 file changed, 42 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index a425ff2..52beb7e 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -41,6 +41,7 @@
>  #include <linux/uaccess.h>
>  #include <linux/pinctrl/consumer.h>
>  #include <linux/platform_data/atmel.h>
> +#include <linux/timer.h>
>  
>  #include <asm/io.h>
>  #include <asm/ioctls.h>
> @@ -167,6 +168,7 @@ struct atmel_uart_port {
>  
>  	struct serial_rs485	rs485;		/* rs485 settings */
>  	unsigned int		tx_done_mask;
> +	struct timer_list 	uart_timer;	/* dbgu timer */
>  };
>  
>  static struct atmel_uart_port atmel_ports[ATMEL_MAX_UART];
> @@ -968,6 +970,15 @@ err_dma:
>  	return -EINVAL;
>  }
>  
> +static void atmel_uart_timer_callback(unsigned long data)
> +{
> +	struct uart_port *port = (void *)data;
> +	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> +
> +	tasklet_schedule(&atmel_port->tasklet);
> +	mod_timer(&atmel_port->uart_timer, jiffies + uart_poll_timeout(port));
> +}
> +
>  /*
>   * receive interrupt handler.
>   */
> @@ -1424,18 +1435,34 @@ static int atmel_startup(struct uart_port *port)
>  
>  	if (atmel_use_pdc_rx(port)) {
>  		/* set UART timeout */
> -		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
> -		UART_PUT_CR(port, ATMEL_US_STTTO);
> -
> -		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
> +		if (port->line == 0) {
> +			setup_timer(&atmel_port->uart_timer,
> +				    atmel_uart_timer_callback,
> +				    (unsigned long)port);
> +			mod_timer(&atmel_port->uart_timer,
> +				  jiffies + uart_poll_timeout(port));
> +		} else {
> +			UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
> +			UART_PUT_CR(port, ATMEL_US_STTTO);
> +
> +			UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
> +		}
>  		/* enable PDC controller */
>  		UART_PUT_PTCR(port, ATMEL_PDC_RXTEN);
>  	} else if (atmel_use_dma_rx(port)) {
>  		/* set UART timeout */
> -		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
> -		UART_PUT_CR(port, ATMEL_US_STTTO);
> -
> -		UART_PUT_IER(port, ATMEL_US_TIMEOUT);
> +		if (port->line == 0) {
> +			setup_timer(&atmel_port->uart_timer,
> +				    atmel_uart_timer_callback,
> +				    (unsigned long)port);
> +			mod_timer(&atmel_port->uart_timer,
> +				  jiffies + uart_poll_timeout(port));
> +		} else {
> +			UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
> +			UART_PUT_CR(port, ATMEL_US_STTTO);
> +
> +			UART_PUT_IER(port, ATMEL_US_TIMEOUT);
> +		}
>  	} else {
>  		/* enable receive only */
>  		UART_PUT_IER(port, ATMEL_US_RXRDY);
> @@ -1471,6 +1498,9 @@ static void atmel_shutdown(struct uart_port *port)
>  					 DMA_FROM_DEVICE);
>  			kfree(pdc->buf);
>  		}
> +
> +		if (port->line == 0)
> +			del_timer_sync(&atmel_port->uart_timer);
>  	}
>  	if (atmel_use_pdc_tx(port)) {
>  		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
> @@ -1484,8 +1514,11 @@ static void atmel_shutdown(struct uart_port *port)
>  	if (atmel_use_dma_tx(port))
>  		atmel_tx_dma_release(atmel_port);
>  
> -	if (atmel_use_dma_rx(port))
> +	if (atmel_use_dma_rx(port)) {
>  		atmel_rx_dma_release(atmel_port);
> +		if (port->line == 0)
> +			del_timer_sync(&atmel_port->uart_timer);
> +	}

use function pointer to seperate the code this will simplify the code and
easier the maintainance by droping all of those if(xx) else

Best Regards,
J.
>  
>  	/*
>  	 * Disable all interrupts, port and break condition.
> -- 
> 1.7.9.5
> 


From richard.genoud at gmail.com  Tue Jul  9 09:31:52 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 9 Jul 2013 15:31:52 +0200
Subject: [PATCH v3 3/7] Documentation: DT: update atmel SSC with DMA
 binding
In-Reply-To: <51DC0E26.7080508@atmel.com>
References: <1373290193-25300-1-git-send-email-richard.genoud@gmail.com>
 <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373372929-17800-4-git-send-email-richard.genoud@gmail.com>
 <CACQ1gAg8WQTaz4XkXJCH+-bNU_U3s_1pgmQYoQR3v-KHOzzBTA@mail.gmail.com>
 <51DC0E26.7080508@atmel.com>
Message-ID: <CACQ1gAhr3gm_O1UyYSUdg8mmnGriAU=kjY6zXwMirojc78dOgg@mail.gmail.com>

2013/7/9 Nicolas Ferre <nicolas.ferre at atmel.com>:
> On 09/07/2013 15:19, Richard Genoud :
>
>> 2013/7/9 Richard Genoud <richard.genoud at gmail.com>:
>>>
>>> As atmel-ssc can be used with DMA, the documentation should be updated.
>>> Also, a configuration DMA example is given.
>>>
>>> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
>>> ---
>>>   .../devicetree/bindings/misc/atmel-ssc.txt         |   24
>>> ++++++++++++++++++--
>>>   1 file changed, 22 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
>>> b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
>>> index 38e51ad..96958ca 100644
>>> --- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
>>> +++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
>>> @@ -6,10 +6,30 @@ Required properties:
>>>          - atmel,at91sam9g45-ssc: support dma transfer
>>>   - reg: Should contain SSC registers location and length
>>>   - interrupts: Should contain SSC interrupt
>>> +For dma transfer:
>>> +- dmas: DMA specifier, consisting of a phandle to DMA controller node,
>>> +  the memory interface and SSC DMA channel ID (for tx and rx).
>>> +  See Documentation/devicetree/bindings/dma/atmel-dma.txt for details.
>>> +- dma-names: Must be "tx", "rx".
>>>
>>> -Example:
>>> +
>>> +Examples:
>>>   ssc0: ssc at fffbc000 {
>>>          compatible = "atmel,at91rm9200-ssc";
>>>          reg = <0xfffbc000 0x4000>;
>>> -       interrupts = <14 4 5>;
>>> +       interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>;
>>
>> maybe I should not use macro in the documentation (not sure if I should or
>> not).
>
>
> absolutely.
ok, thanks, changing that in next version.


From plagnioj at jcrosoft.com  Tue Jul  9 09:34:13 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 9 Jul 2013 15:34:13 +0200
Subject: [PATCH 1/7] serial: at91: correct definition from DMA to PDC
In-Reply-To: <20130709112238.GB18012@ns203013.ovh.net>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
 <1373351626-30143-2-git-send-email-elen.song@atmel.com>
 <20130709112238.GB18012@ns203013.ovh.net>
Message-ID: <20130709133413.GE18012@ns203013.ovh.net>

On 13:22 Tue 09 Jul     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 14:33 Tue 09 Jul     , Elen Song wrote:
> > The DMA is available since at91sam9x5 socs, before that, we use PDC.
> > 
> > Signed-off-by: Elen Song <elen.song at atmel.com>
> > ---
> >  Documentation/devicetree/bindings/serial/rs485.txt |    4 +-
> >  .../devicetree/bindings/tty/serial/atmel-usart.txt |   12 ++--
> >  arch/arm/boot/dts/at91rm9200.dtsi                  |   16 ++---
> >  arch/arm/boot/dts/at91sam9260.dtsi                 |   24 +++----
> >  arch/arm/boot/dts/at91sam9263.dtsi                 |   12 ++--
> >  arch/arm/boot/dts/at91sam9g45.dtsi                 |   16 ++---
> >  arch/arm/mach-at91/at91rm9200_devices.c            |   20 +++---
> >  arch/arm/mach-at91/at91sam9260_devices.c           |   28 ++++----
> >  arch/arm/mach-at91/at91sam9261_devices.c           |   16 ++---
> >  arch/arm/mach-at91/at91sam9263_devices.c           |   16 ++---
> >  arch/arm/mach-at91/at91sam9g45_devices.c           |   20 +++---
> >  arch/arm/mach-at91/at91sam9rl_devices.c            |   20 +++---
> >  drivers/tty/serial/atmel_serial.c                  |   74 ++++++++++----------
> >  include/linux/platform_data/atmel.h                |    4 +-
> >  14 files changed, 141 insertions(+), 141 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/serial/rs485.txt b/Documentation/devicetree/bindings/serial/rs485.txt
> > index 1e753c6..7c8581e 100644
> > --- a/Documentation/devicetree/bindings/serial/rs485.txt
> > +++ b/Documentation/devicetree/bindings/serial/rs485.txt
> > @@ -23,8 +23,8 @@ RS485 example for Atmel USART:
> >  		compatible = "atmel,at91sam9260-usart";
> >  		reg = <0xfff8c000 0x4000>;
> >  		interrupts = <7>;
> > -		atmel,use-dma-rx;
> > -		atmel,use-dma-tx;
> > +		atmel,use-pdc-rx;
> > +		atmel,use-pdc-tx;
> 
> you break dt compatibility this is not acceptable

current the use-dma-r/tx just mean you want to use the DMA for rx or tx
keep it as is

to detect if you want to use PDC or DMA just check the presence of the dmas
property
	dmas = <&dma0 1 9>,
as example

This way you do not break the dt compatibility

Best Regards,
J.
> 
> Best Regards,
> J.
> >  		linux,rs485-enabled-at-boot-time;
> >  		rs485-rts-delay = <0 200>;		// in milliseconds
> >  	};
> > diff --git a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> > index a49d9a1..82f45ec 100644
> > --- a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> > +++ b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
> > @@ -8,8 +8,8 @@ Required properties:
> >  - interrupts: Should contain interrupt
> >  
> >  Optional properties:
> > -- atmel,use-dma-rx: use of PDC or DMA for receiving data
> > -- atmel,use-dma-tx: use of PDC or DMA for transmitting data
> > +- atmel,use-pdc-rx: use of PDC for receiving data
> > +- atmel,use-pdc-tx: use of PDC for transmitting data
> >  
> >  <chip> compatible description:
> >  - at91rm9200:  legacy USART support
> > @@ -19,9 +19,9 @@ Example:
> >  
> >  	usart0: serial at fff8c000 {
> >  		compatible = "atmel,at91sam9260-usart";
> > -		reg = <0xfff8c000 0x4000>;
> > -		interrupts = <7>;
> > -		atmel,use-dma-rx;
> > -		atmel,use-dma-tx;
> > +		reg = <0xfff8c000 0x200>;
> > +		interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
> > +		atmel,use-pdc-rx;
> > +		atmel,use-pdc-tx;
> >  	};
> >  
> > diff --git a/arch/arm/boot/dts/at91rm9200.dtsi b/arch/arm/boot/dts/at91rm9200.dtsi
> > index 1fc645e..2dcef27 100644
> > --- a/arch/arm/boot/dts/at91rm9200.dtsi
> > +++ b/arch/arm/boot/dts/at91rm9200.dtsi
> > @@ -537,8 +537,8 @@
> >  				compatible = "atmel,at91rm9200-usart";
> >  				reg = <0xfffc0000 0x200>;
> >  				interrupts = <6 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_uart0>;
> >  				status = "disabled";
> > @@ -548,8 +548,8 @@
> >  				compatible = "atmel,at91rm9200-usart";
> >  				reg = <0xfffc4000 0x200>;
> >  				interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_uart1>;
> >  				status = "disabled";
> > @@ -559,8 +559,8 @@
> >  				compatible = "atmel,at91rm9200-usart";
> >  				reg = <0xfffc8000 0x200>;
> >  				interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_uart2>;
> >  				status = "disabled";
> > @@ -570,8 +570,8 @@
> >  				compatible = "atmel,at91rm9200-usart";
> >  				reg = <0xfffcc000 0x200>;
> >  				interrupts = <23 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_uart3>;
> >  				status = "disabled";
> > diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
> > index 899a7cf..1fcf6f6 100644
> > --- a/arch/arm/boot/dts/at91sam9260.dtsi
> > +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> > @@ -475,8 +475,8 @@
> >  				compatible = "atmel,at91sam9260-usart";
> >  				reg = <0xfffb0000 0x200>;
> >  				interrupts = <6 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_usart0>;
> >  				status = "disabled";
> > @@ -486,8 +486,8 @@
> >  				compatible = "atmel,at91sam9260-usart";
> >  				reg = <0xfffb4000 0x200>;
> >  				interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_usart1>;
> >  				status = "disabled";
> > @@ -497,8 +497,8 @@
> >  				compatible = "atmel,at91sam9260-usart";
> >  				reg = <0xfffb8000 0x200>;
> >  				interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_usart2>;
> >  				status = "disabled";
> > @@ -508,8 +508,8 @@
> >  				compatible = "atmel,at91sam9260-usart";
> >  				reg = <0xfffd0000 0x200>;
> >  				interrupts = <23 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_usart3>;
> >  				status = "disabled";
> > @@ -519,8 +519,8 @@
> >  				compatible = "atmel,at91sam9260-usart";
> >  				reg = <0xfffd4000 0x200>;
> >  				interrupts = <24 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_uart0>;
> >  				status = "disabled";
> > @@ -530,8 +530,8 @@
> >  				compatible = "atmel,at91sam9260-usart";
> >  				reg = <0xfffd8000 0x200>;
> >  				interrupts = <25 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_uart1>;
> >  				status = "disabled";
> > diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
> > index ff63811..eb1dac2 100644
> > --- a/arch/arm/boot/dts/at91sam9263.dtsi
> > +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> > @@ -426,8 +426,8 @@
> >  				compatible = "atmel,at91sam9260-usart";
> >  				reg = <0xfff8c000 0x200>;
> >  				interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_usart0>;
> >  				status = "disabled";
> > @@ -437,8 +437,8 @@
> >  				compatible = "atmel,at91sam9260-usart";
> >  				reg = <0xfff90000 0x200>;
> >  				interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_usart1>;
> >  				status = "disabled";
> > @@ -448,8 +448,8 @@
> >  				compatible = "atmel,at91sam9260-usart";
> >  				reg = <0xfff94000 0x200>;
> >  				interrupts = <9 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_usart2>;
> >  				status = "disabled";
> > diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> > index cb44bbb..13c7682 100644
> > --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> > +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> > @@ -485,8 +485,8 @@
> >  				compatible = "atmel,at91sam9260-usart";
> >  				reg = <0xfff8c000 0x200>;
> >  				interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_usart0>;
> >  				status = "disabled";
> > @@ -496,8 +496,8 @@
> >  				compatible = "atmel,at91sam9260-usart";
> >  				reg = <0xfff90000 0x200>;
> >  				interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_usart1>;
> >  				status = "disabled";
> > @@ -507,8 +507,8 @@
> >  				compatible = "atmel,at91sam9260-usart";
> >  				reg = <0xfff94000 0x200>;
> >  				interrupts = <9 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_usart2>;
> >  				status = "disabled";
> > @@ -518,8 +518,8 @@
> >  				compatible = "atmel,at91sam9260-usart";
> >  				reg = <0xfff98000 0x200>;
> >  				interrupts = <10 IRQ_TYPE_LEVEL_HIGH 5>;
> > -				atmel,use-dma-rx;
> > -				atmel,use-dma-tx;
> > +				atmel,use-pdc-rx;
> > +				atmel,use-pdc-tx;
> >  				pinctrl-names = "default";
> >  				pinctrl-0 = <&pinctrl_usart3>;
> >  				status = "disabled";
> > diff --git a/arch/arm/mach-at91/at91rm9200_devices.c b/arch/arm/mach-at91/at91rm9200_devices.c
> > index 3ebc979..6766d17 100644
> > --- a/arch/arm/mach-at91/at91rm9200_devices.c
> > +++ b/arch/arm/mach-at91/at91rm9200_devices.c
> > @@ -920,8 +920,8 @@ static struct resource dbgu_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data dbgu_data = {
> > -	.use_dma_tx	= 0,
> > -	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
> > +	.use_pdc_tx	= 0,
> > +	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
> >  };
> >  
> >  static u64 dbgu_dmamask = DMA_BIT_MASK(32);
> > @@ -958,8 +958,8 @@ static struct resource uart0_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart0_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart0_dmamask = DMA_BIT_MASK(32);
> > @@ -1007,8 +1007,8 @@ static struct resource uart1_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart1_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart1_dmamask = DMA_BIT_MASK(32);
> > @@ -1058,8 +1058,8 @@ static struct resource uart2_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart2_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart2_dmamask = DMA_BIT_MASK(32);
> > @@ -1101,8 +1101,8 @@ static struct resource uart3_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart3_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart3_dmamask = DMA_BIT_MASK(32);
> > diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
> > index eda8d16..0a087a7c 100644
> > --- a/arch/arm/mach-at91/at91sam9260_devices.c
> > +++ b/arch/arm/mach-at91/at91sam9260_devices.c
> > @@ -817,8 +817,8 @@ static struct resource dbgu_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data dbgu_data = {
> > -	.use_dma_tx	= 0,
> > -	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
> > +	.use_pdc_tx	= 0,
> > +	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
> >  };
> >  
> >  static u64 dbgu_dmamask = DMA_BIT_MASK(32);
> > @@ -855,8 +855,8 @@ static struct resource uart0_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart0_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart0_dmamask = DMA_BIT_MASK(32);
> > @@ -906,8 +906,8 @@ static struct resource uart1_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart1_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart1_dmamask = DMA_BIT_MASK(32);
> > @@ -949,8 +949,8 @@ static struct resource uart2_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart2_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart2_dmamask = DMA_BIT_MASK(32);
> > @@ -992,8 +992,8 @@ static struct resource uart3_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart3_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart3_dmamask = DMA_BIT_MASK(32);
> > @@ -1035,8 +1035,8 @@ static struct resource uart4_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart4_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart4_dmamask = DMA_BIT_MASK(32);
> > @@ -1073,8 +1073,8 @@ static struct resource uart5_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart5_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart5_dmamask = DMA_BIT_MASK(32);
> > diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c
> > index 629ea5f..fcaae28 100644
> > --- a/arch/arm/mach-at91/at91sam9261_devices.c
> > +++ b/arch/arm/mach-at91/at91sam9261_devices.c
> > @@ -878,8 +878,8 @@ static struct resource dbgu_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data dbgu_data = {
> > -	.use_dma_tx	= 0,
> > -	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
> > +	.use_pdc_tx	= 0,
> > +	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
> >  };
> >  
> >  static u64 dbgu_dmamask = DMA_BIT_MASK(32);
> > @@ -916,8 +916,8 @@ static struct resource uart0_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart0_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart0_dmamask = DMA_BIT_MASK(32);
> > @@ -959,8 +959,8 @@ static struct resource uart1_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart1_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart1_dmamask = DMA_BIT_MASK(32);
> > @@ -1002,8 +1002,8 @@ static struct resource uart2_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart2_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart2_dmamask = DMA_BIT_MASK(32);
> > diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
> > index 858c8aa..a62216b 100644
> > --- a/arch/arm/mach-at91/at91sam9263_devices.c
> > +++ b/arch/arm/mach-at91/at91sam9263_devices.c
> > @@ -1322,8 +1322,8 @@ static struct resource dbgu_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data dbgu_data = {
> > -	.use_dma_tx	= 0,
> > -	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
> > +	.use_pdc_tx	= 0,
> > +	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
> >  };
> >  
> >  static u64 dbgu_dmamask = DMA_BIT_MASK(32);
> > @@ -1360,8 +1360,8 @@ static struct resource uart0_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart0_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart0_dmamask = DMA_BIT_MASK(32);
> > @@ -1403,8 +1403,8 @@ static struct resource uart1_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart1_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart1_dmamask = DMA_BIT_MASK(32);
> > @@ -1446,8 +1446,8 @@ static struct resource uart2_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart2_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart2_dmamask = DMA_BIT_MASK(32);
> > diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
> > index acb703e..4c81fd1 100644
> > --- a/arch/arm/mach-at91/at91sam9g45_devices.c
> > +++ b/arch/arm/mach-at91/at91sam9g45_devices.c
> > @@ -1585,8 +1585,8 @@ static struct resource dbgu_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data dbgu_data = {
> > -	.use_dma_tx	= 0,
> > -	.use_dma_rx	= 0,
> > +	.use_pdc_tx	= 0,
> > +	.use_pdc_rx	= 0,
> >  };
> >  
> >  static u64 dbgu_dmamask = DMA_BIT_MASK(32);
> > @@ -1623,8 +1623,8 @@ static struct resource uart0_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart0_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart0_dmamask = DMA_BIT_MASK(32);
> > @@ -1666,8 +1666,8 @@ static struct resource uart1_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart1_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart1_dmamask = DMA_BIT_MASK(32);
> > @@ -1709,8 +1709,8 @@ static struct resource uart2_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart2_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart2_dmamask = DMA_BIT_MASK(32);
> > @@ -1752,8 +1752,8 @@ static struct resource uart3_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart3_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart3_dmamask = DMA_BIT_MASK(32);
> > diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c
> > index 352468f..5cd8c76 100644
> > --- a/arch/arm/mach-at91/at91sam9rl_devices.c
> > +++ b/arch/arm/mach-at91/at91sam9rl_devices.c
> > @@ -954,8 +954,8 @@ static struct resource dbgu_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data dbgu_data = {
> > -	.use_dma_tx	= 0,
> > -	.use_dma_rx	= 0,		/* DBGU not capable of receive DMA */
> > +	.use_pdc_tx	= 0,
> > +	.use_pdc_rx	= 0,		/* DBGU not capable of receive PDC */
> >  };
> >  
> >  static u64 dbgu_dmamask = DMA_BIT_MASK(32);
> > @@ -992,8 +992,8 @@ static struct resource uart0_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart0_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart0_dmamask = DMA_BIT_MASK(32);
> > @@ -1043,8 +1043,8 @@ static struct resource uart1_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart1_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart1_dmamask = DMA_BIT_MASK(32);
> > @@ -1086,8 +1086,8 @@ static struct resource uart2_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart2_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart2_dmamask = DMA_BIT_MASK(32);
> > @@ -1129,8 +1129,8 @@ static struct resource uart3_resources[] = {
> >  };
> >  
> >  static struct atmel_uart_data uart3_data = {
> > -	.use_dma_tx	= 1,
> > -	.use_dma_rx	= 1,
> > +	.use_pdc_tx	= 1,
> > +	.use_pdc_rx	= 1,
> >  };
> >  
> >  static u64 uart3_dmamask = DMA_BIT_MASK(32);
> > diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> > index 3467462..ab9de8a 100644
> > --- a/drivers/tty/serial/atmel_serial.c
> > +++ b/drivers/tty/serial/atmel_serial.c
> > @@ -140,11 +140,11 @@ struct atmel_uart_port {
> >  	u32			backup_imr;	/* IMR saved during suspend */
> >  	int			break_active;	/* break being received */
> >  
> > -	short			use_dma_rx;	/* enable PDC receiver */
> > +	short			use_pdc_rx;	/* enable PDC receiver */
> >  	short			pdc_rx_idx;	/* current PDC RX buffer */
> >  	struct atmel_dma_buffer	pdc_rx[2];	/* PDC receier */
> >  
> > -	short			use_dma_tx;	/* enable PDC transmitter */
> > +	short			use_pdc_tx;	/* enable PDC transmitter */
> >  	struct atmel_dma_buffer	pdc_tx;		/* PDC transmitter */
> >  
> >  	struct tasklet_struct	tasklet;
> > @@ -181,26 +181,26 @@ to_atmel_uart_port(struct uart_port *uart)
> >  }
> >  
> >  #ifdef CONFIG_SERIAL_ATMEL_PDC
> > -static bool atmel_use_dma_rx(struct uart_port *port)
> > +static bool atmel_use_pdc_rx(struct uart_port *port)
> >  {
> >  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> >  
> > -	return atmel_port->use_dma_rx;
> > +	return atmel_port->use_pdc_rx;
> >  }
> >  
> > -static bool atmel_use_dma_tx(struct uart_port *port)
> > +static bool atmel_use_pdc_tx(struct uart_port *port)
> >  {
> >  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> >  
> > -	return atmel_port->use_dma_tx;
> > +	return atmel_port->use_pdc_tx;
> >  }
> >  #else
> > -static bool atmel_use_dma_rx(struct uart_port *port)
> > +static bool atmel_use_pdc_rx(struct uart_port *port)
> >  {
> >  	return false;
> >  }
> >  
> > -static bool atmel_use_dma_tx(struct uart_port *port)
> > +static bool atmel_use_pdc_tx(struct uart_port *port)
> >  {
> >  	return false;
> >  }
> > @@ -233,7 +233,7 @@ void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
> >  		mode |= ATMEL_US_USMODE_RS485;
> >  	} else {
> >  		dev_dbg(port->dev, "Setting UART to RS232\n");
> > -		if (atmel_use_dma_tx(port))
> > +		if (atmel_use_pdc_tx(port))
> >  			atmel_port->tx_done_mask = ATMEL_US_ENDTX |
> >  				ATMEL_US_TXBUFE;
> >  		else
> > @@ -345,7 +345,7 @@ static void atmel_stop_tx(struct uart_port *port)
> >  {
> >  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> >  
> > -	if (atmel_use_dma_tx(port)) {
> > +	if (atmel_use_pdc_tx(port)) {
> >  		/* disable PDC transmit */
> >  		UART_PUT_PTCR(port, ATMEL_PDC_TXTDIS);
> >  	}
> > @@ -364,7 +364,7 @@ static void atmel_start_tx(struct uart_port *port)
> >  {
> >  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> >  
> > -	if (atmel_use_dma_tx(port)) {
> > +	if (atmel_use_pdc_tx(port)) {
> >  		if (UART_GET_PTSR(port) & ATMEL_PDC_TXTEN)
> >  			/* The transmitter is already running.  Yes, we
> >  			   really need this.*/
> > @@ -390,7 +390,7 @@ static void atmel_start_rx(struct uart_port *port)
> >  
> >  	UART_PUT_CR(port, ATMEL_US_RXEN);
> >  
> > -	if (atmel_use_dma_rx(port)) {
> > +	if (atmel_use_pdc_rx(port)) {
> >  		/* enable PDC controller */
> >  		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
> >  			port->read_status_mask);
> > @@ -407,7 +407,7 @@ static void atmel_stop_rx(struct uart_port *port)
> >  {
> >  	UART_PUT_CR(port, ATMEL_US_RXDIS);
> >  
> > -	if (atmel_use_dma_rx(port)) {
> > +	if (atmel_use_pdc_rx(port)) {
> >  		/* disable PDC receive */
> >  		UART_PUT_PTCR(port, ATMEL_PDC_RXTDIS);
> >  		UART_PUT_IDR(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
> > @@ -572,7 +572,7 @@ atmel_handle_receive(struct uart_port *port, unsigned int pending)
> >  {
> >  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> >  
> > -	if (atmel_use_dma_rx(port)) {
> > +	if (atmel_use_pdc_rx(port)) {
> >  		/*
> >  		 * PDC receive. Just schedule the tasklet and let it
> >  		 * figure out the details.
> > @@ -661,7 +661,7 @@ static irqreturn_t atmel_interrupt(int irq, void *dev_id)
> >  /*
> >   * Called from tasklet with ENDTX and TXBUFE interrupts disabled.
> >   */
> > -static void atmel_tx_dma(struct uart_port *port)
> > +static void atmel_tx_pdc(struct uart_port *port)
> >  {
> >  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> >  	struct circ_buf *xmit = &port->state->xmit;
> > @@ -778,7 +778,7 @@ static void atmel_rx_from_ring(struct uart_port *port)
> >  	spin_lock(&port->lock);
> >  }
> >  
> > -static void atmel_rx_from_dma(struct uart_port *port)
> > +static void atmel_rx_from_pdc(struct uart_port *port)
> >  {
> >  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> >  	struct tty_port *tport = &port->state->port;
> > @@ -868,8 +868,8 @@ static void atmel_tasklet_func(unsigned long data)
> >  	/* The interrupt handler does not take the lock */
> >  	spin_lock(&port->lock);
> >  
> > -	if (atmel_use_dma_tx(port))
> > -		atmel_tx_dma(port);
> > +	if (atmel_use_pdc_tx(port))
> > +		atmel_tx_pdc(port);
> >  	else
> >  		atmel_tx_chars(port);
> >  
> > @@ -893,8 +893,8 @@ static void atmel_tasklet_func(unsigned long data)
> >  		atmel_port->irq_status_prev = status;
> >  	}
> >  
> > -	if (atmel_use_dma_rx(port))
> > -		atmel_rx_from_dma(port);
> > +	if (atmel_use_pdc_rx(port))
> > +		atmel_rx_from_pdc(port);
> >  	else
> >  		atmel_rx_from_ring(port);
> >  
> > @@ -930,7 +930,7 @@ static int atmel_startup(struct uart_port *port)
> >  	/*
> >  	 * Initialize DMA (if necessary)
> >  	 */
> > -	if (atmel_use_dma_rx(port)) {
> > +	if (atmel_use_pdc_rx(port)) {
> >  		int i;
> >  
> >  		for (i = 0; i < 2; i++) {
> > @@ -964,7 +964,7 @@ static int atmel_startup(struct uart_port *port)
> >  		UART_PUT_RNPR(port, atmel_port->pdc_rx[1].dma_addr);
> >  		UART_PUT_RNCR(port, PDC_BUFFER_SIZE);
> >  	}
> > -	if (atmel_use_dma_tx(port)) {
> > +	if (atmel_use_pdc_tx(port)) {
> >  		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
> >  		struct circ_buf *xmit = &port->state->xmit;
> >  
> > @@ -1000,7 +1000,7 @@ static int atmel_startup(struct uart_port *port)
> >  	/* enable xmit & rcvr */
> >  	UART_PUT_CR(port, ATMEL_US_TXEN | ATMEL_US_RXEN);
> >  
> > -	if (atmel_use_dma_rx(port)) {
> > +	if (atmel_use_pdc_rx(port)) {
> >  		/* set UART timeout */
> >  		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
> >  		UART_PUT_CR(port, ATMEL_US_STTTO);
> > @@ -1031,7 +1031,7 @@ static void atmel_shutdown(struct uart_port *port)
> >  	/*
> >  	 * Shut-down the DMA.
> >  	 */
> > -	if (atmel_use_dma_rx(port)) {
> > +	if (atmel_use_pdc_rx(port)) {
> >  		int i;
> >  
> >  		for (i = 0; i < 2; i++) {
> > @@ -1044,7 +1044,7 @@ static void atmel_shutdown(struct uart_port *port)
> >  			kfree(pdc->buf);
> >  		}
> >  	}
> > -	if (atmel_use_dma_tx(port)) {
> > +	if (atmel_use_pdc_tx(port)) {
> >  		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
> >  
> >  		dma_unmap_single(port->dev,
> > @@ -1080,7 +1080,7 @@ static void atmel_flush_buffer(struct uart_port *port)
> >  {
> >  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> >  
> > -	if (atmel_use_dma_tx(port)) {
> > +	if (atmel_use_pdc_tx(port)) {
> >  		UART_PUT_TCR(port, 0);
> >  		atmel_port->pdc_tx.ofs = 0;
> >  	}
> > @@ -1193,7 +1193,7 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> >  	if (termios->c_iflag & (BRKINT | PARMRK))
> >  		port->read_status_mask |= ATMEL_US_RXBRK;
> >  
> > -	if (atmel_use_dma_rx(port))
> > +	if (atmel_use_pdc_rx(port))
> >  		/* need to enable error interrupts */
> >  		UART_PUT_IER(port, port->read_status_mask);
> >  
> > @@ -1429,14 +1429,14 @@ static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
> >  	u32 rs485_delay[2];
> >  
> >  	/* DMA/PDC usage specification */
> > -	if (of_get_property(np, "atmel,use-dma-rx", NULL))
> > -		atmel_port->use_dma_rx	= 1;
> > +	if (of_get_property(np, "atmel,use-pdc-rx", NULL))
> > +		atmel_port->use_pdc_rx	= 1;
> >  	else
> > -		atmel_port->use_dma_rx	= 0;
> > -	if (of_get_property(np, "atmel,use-dma-tx", NULL))
> > -		atmel_port->use_dma_tx	= 1;
> > +		atmel_port->use_pdc_rx	= 0;
> > +	if (of_get_property(np, "atmel,use-pdc-tx", NULL))
> > +		atmel_port->use_pdc_tx	= 1;
> >  	else
> > -		atmel_port->use_dma_tx	= 0;
> > +		atmel_port->use_pdc_tx	= 0;
> >  
> >  	/* rs485 properties */
> >  	if (of_property_read_u32_array(np, "rs485-rts-delay",
> > @@ -1467,8 +1467,8 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
> >  	if (pdev->dev.of_node) {
> >  		atmel_of_init_port(atmel_port, pdev->dev.of_node);
> >  	} else {
> > -		atmel_port->use_dma_rx	= pdata->use_dma_rx;
> > -		atmel_port->use_dma_tx	= pdata->use_dma_tx;
> > +		atmel_port->use_pdc_rx	= pdata->use_pdc_rx;
> > +		atmel_port->use_pdc_tx	= pdata->use_pdc_tx;
> >  		atmel_port->rs485	= pdata->rs485;
> >  	}
> >  
> > @@ -1505,7 +1505,7 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
> >  	/* Use TXEMPTY for interrupt when rs485 else TXRDY or ENDTX|TXBUFE */
> >  	if (atmel_port->rs485.flags & SER_RS485_ENABLED)
> >  		atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
> > -	else if (atmel_use_dma_tx(port)) {
> > +	else if (atmel_use_pdc_tx(port)) {
> >  		port->fifosize = PDC_BUFFER_SIZE;
> >  		atmel_port->tx_done_mask = ATMEL_US_ENDTX | ATMEL_US_TXBUFE;
> >  	} else {
> > @@ -1794,7 +1794,7 @@ static int atmel_serial_probe(struct platform_device *pdev)
> >  		goto err;
> >  	}
> >  
> > -	if (!atmel_use_dma_rx(&port->uart)) {
> > +	if (!atmel_use_pdc_rx(&port->uart)) {
> >  		ret = -ENOMEM;
> >  		data = kmalloc(sizeof(struct atmel_uart_char)
> >  				* ATMEL_SERIAL_RINGSIZE, GFP_KERNEL);
> > diff --git a/include/linux/platform_data/atmel.h b/include/linux/platform_data/atmel.h
> > index 6a293b7..8965fed 100644
> > --- a/include/linux/platform_data/atmel.h
> > +++ b/include/linux/platform_data/atmel.h
> > @@ -76,8 +76,8 @@ struct atmel_nand_data {
> >   /* Serial */
> >  struct atmel_uart_data {
> >  	int			num;		/* port num */
> > -	short			use_dma_tx;	/* use transmit DMA? */
> > -	short			use_dma_rx;	/* use receive DMA? */
> > +	short			use_pdc_tx;	/* use transmit PDC? */
> > +	short			use_pdc_rx;	/* use receive PDC? */
> >  	void __iomem		*regs;		/* virt. base address, if any */
> >  	struct serial_rs485	rs485;		/* rs485 settings */
> >  };
> > -- 
> > 1.7.9.5
> > 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From plagnioj at jcrosoft.com  Tue Jul  9 09:39:18 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 9 Jul 2013 15:39:18 +0200
Subject: [V3 0/7] Enhance mmp display driver
In-Reply-To: <1372332473-6584-1-git-send-email-jtzhou@marvell.com>
References: <1372332473-6584-1-git-send-email-jtzhou@marvell.com>
Message-ID: <20130709133918.GC18477@ns203013.ovh.net>

HI,

	please rebase on the for-next branch as it does not apply

Best Regards,
J.
On 19:27 Thu 27 Jun     , Jett.Zhou wrote:
> Changelog:
> 1 Add more comments for the mmp_display rbswap usage 
> according to Daniel's comments;
> 2 Add fix patch for ttc_dkb on rbswap;
> 3 Add more comments on the pitch usage and definition;
> 4 Combine the modification on pitch of graphic and video layer
> in one patch.
> 
> Guoqing Li (2):
>   video: mmp: rb swap setting update for mmp display
>   video: mmp: optimize some register setting code
> 
> Jett.Zhou (1):
>   ARM: mmp: remove the legacy rbswap setting for ttc_dkb platform
> 
> Jing Xiang (4):
>   video: mmp: fix graphics/video layer enable/mask issue
>   video: mmp: fix memcpy wrong size for mmp_addr issue
>   video: mmp: calculate pitch value when fb set win
>   video: mmp: add pitch info in mmp_win structure
> 
>  arch/arm/mach-mmp/ttc_dkb.c     |    4 +-
>  drivers/video/mmp/fb/mmpfb.c    |   34 +++++++++++------
>  drivers/video/mmp/hw/mmp_ctrl.c |   79 ++++++++++++++++++++++-----------------
>  drivers/video/mmp/hw/mmp_ctrl.h |    5 ++
>  include/video/mmp_disp.h        |    6 +++
>  5 files changed, 79 insertions(+), 49 deletions(-)
> 


From plagnioj at jcrosoft.com  Tue Jul  9 09:41:49 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 9 Jul 2013 15:41:49 +0200
Subject: [PATCH v6] video: imxfb: Add DT support
In-Reply-To: <CAOMZO5A-1gacTOSrpZ4HKfwq13mug+uNCS3m4gyFp1WT21_JeQ@mail.gmail.com>
References: <1369564538-21835-1-git-send-email-mpa@pengutronix.de>
 <20130528110927.GA23653@game.jcrosoft.org>
 <CAOMZO5A-1gacTOSrpZ4HKfwq13mug+uNCS3m4gyFp1WT21_JeQ@mail.gmail.com>
Message-ID: <20130709134149.GE18477@ns203013.ovh.net>

On 09:09 Fri 05 Jul     , Fabio Estevam wrote:
> Hi Jean-Christophe,
> 
> On Tue, May 28, 2013 at 8:09 AM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj at jcrosoft.com> wrote:
> > On 12:35 Sun 26 May     , Markus Pargmann wrote:
> >> Add devicetree support for imx framebuffer driver. It uses the generic
> >> display bindings and helper functions.
> >>
> >> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> >> Cc: Fabio Estevam <festevam at gmail.com>
> >> Cc: Mark Rutland <mark.rutland at arm.com>
> >> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> >
> > Applied thanks
> 
> Still don't see this patch in linux-next. Could you please check?
in the pull to Linus

Best Regards,
J.


From robherring2 at gmail.com  Tue Jul  9 09:43:36 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 9 Jul 2013 08:43:36 -0500
Subject: [PATCHv4 05/11] of: pci: add registry of MSI chips
In-Reply-To: <1372686136-1370-6-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-6-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAL_Jsq+h=y5SNo4qO5-5u_w8rW++9MKDZK8rASNjhtVcjh-iyQ@mail.gmail.com>

On Mon, Jul 1, 2013 at 8:42 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> This commit adds a very basic registry of msi_chip structures, so that
> an IRQ controller driver can register an msi_chip, and a PCIe host
> controller can find it, based on a 'struct device_node'.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  drivers/of/of_pci.c    | 40 ++++++++++++++++++++++++++++++++++++++++
>  include/linux/msi.h    |  2 ++
>  include/linux/of_pci.h | 12 ++++++++++++
>  3 files changed, 54 insertions(+)
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 42c687a..f516632 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -89,3 +89,43 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
>         return 0;
>  }
>  EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
> +
> +#ifdef CONFIG_PCI_MSI
> +
> +static LIST_HEAD(msi_chip_list);
> +static DEFINE_MUTEX(msi_chip_mutex);
> +
> +int of_msi_chip_add(struct msi_chip *chip)

Perhaps of_pci_msi_chip_add instead.

> +{
> +       if (! of_property_read_bool(chip->of_node, "msi-controller"))
> +               return -EINVAL;
> +
> +       mutex_lock(&msi_chip_mutex);
> +       list_add(&chip->list, &msi_chip_list);
> +       mutex_unlock(&msi_chip_mutex);
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_msi_chip_add);
> +
> +void of_msi_chip_remove(struct msi_chip *chip)

ditto

> +{
> +       mutex_lock(&msi_chip_mutex);
> +       list_del(&chip->list);
> +       mutex_unlock(&msi_chip_mutex);
> +}
> +EXPORT_SYMBOL_GPL(of_msi_chip_remove);
> +
> +struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node)

ditto.

> +{
> +       struct msi_chip *c;
> +       list_for_each_entry(c, &msi_chip_list, list) {

Need the safe variant here?

Rob

> +               if (c->of_node == of_node)
> +                       return c;
> +       }
> +
> +       return NULL;
> +}
> +EXPORT_SYMBOL_GPL(of_find_msi_chip_by_node);
> +
> +#endif /* CONFIG_PCI_MSI */
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index 5b357d92..9e1a44b 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -66,6 +66,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);
>  struct msi_chip {
>         struct module *owner;
>         struct device *dev;
> +       struct device_node *of_node;
> +       struct list_head list;
>
>         int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
>                          struct msi_desc *desc);
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index 7a04826..99e4361 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -2,6 +2,7 @@
>  #define __OF_PCI_H
>
>  #include <linux/pci.h>
> +#include <linux/msi.h>
>
>  struct pci_dev;
>  struct of_irq;
> @@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
>  int of_pci_get_devfn(struct device_node *np);
>  int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
>
> +#if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
> +int of_msi_chip_add(struct msi_chip *chip);
> +void of_msi_chip_remove(struct msi_chip *chip);
> +struct msi_chip *of_find_msi_chip_by_node(struct device_node *of_node);
> +#else
> +static inline int of_msi_chip_add(struct msi_chip *chip) { return -EINVAL; }
> +static inline void of_msi_chip_remove(struct msi_chip *chip) { }
> +static inline struct msi_chip *
> +of_find_msi_chip_by_node(struct device_node *of_node) { return NULL };
> +#endif
> +
>  #endif
> --
> 1.8.1.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From rogerq at ti.com  Tue Jul  9 09:55:23 2013
From: rogerq at ti.com (Roger Quadros)
Date: Tue, 9 Jul 2013 16:55:23 +0300
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51DC09E7.1070302@denx.de>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de>
Message-ID: <51DC164B.5010608@ti.com>

Hi Stefan,

On 07/09/2013 04:02 PM, Stefan Roese wrote:
> Roger,
> 
> On 04/15/2013 01:20 PM, Roger Quadros wrote:
>> On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
>> reversed when compared to other revisions i.e. it is
>> active high instead of active low.
>>
>> Use the beagle_config.usb_pwr_level flag correctly so that
>> the power regulator can be configured at runtime.
>>
>> Signed-off-by: Roger Quadros <rogerq at ti.com>
> 
> I'm currently trying to use an SMSC95xx USB ethernet adapter on the
> OMAP3 Beagleboard (old one "Beagle Rev C1/C2/C3") via the OMAP EHCI
> controller. And am testing this by trying to mount the rootfs via NFS.
> What I see is that the NFS mounting stalls/hangs most of the time quite
> early in the mount process:
> 
> [    6.425689] VFS: Mounted root (nfs filesystem) on device 0:12.
> [    6.435485] devtmpfs: mounted
> [    6.440002] Freeing unused kernel memory: 384K (c077a000 - c07da000)
> INIT: version 2.88 booting
> Starting udev
> [  188.311309] nfs: server 10.0.0.152 not responding, still trying
> [  188.317687] nfs: server 10.0.0.152 not responding, still trying
> ...
> 
> Only very seldom the rootfs can be mounted successfully to the prompt.
> 
> I'm using latest kernel.org for this (git ID d2b4a646 also tested with
> v3.10 release). This is with DT-enabled booting and without-DT (same
> problem). I also tested some older Linux kernel versions and it fails
> there as well. Only v3.2.40 seems to be able to mount this rootfs via
> NFS reliably (approx. 10 times success).

I can't really tell at the moment where the problem is.

Did you compile in all the necessary drivers required for NFS booting?
In the beagle case that would mean NOP_USB_XCEIV, USB_EHCI_HCD, USB_EHCI_HCD_OMAP
and the smsc95xx driver.

If you can paste your full kernel boot log we can check if all these show up
before the kernel tries to look up for the NFS server.
> 
> Is this a known issue on the Beagleboard? Do you have any ideas what
> might cause such an issue (unreliable USB connection, hangup of NFS
> mounting)? Any hints/links appretiated.
> 

I have been too lazy to setup NFS :). But I will give it a shot soon to see what's going
wrong.

cheers,
-roger


From mturquette at linaro.org  Tue Jul  9 09:58:08 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 09 Jul 2013 06:58:08 -0700
Subject: [PATCH v3 3/5] clk: dt: binding for basic multiplexer clock
In-Reply-To: <20130626084058.GA10833@e106331-lin.cambridge.arm.com>
References: <1371795256-16703-1-git-send-email-mturquette@linaro.org>
 <1371795256-16703-4-git-send-email-mturquette@linaro.org>
 <20130626084058.GA10833@e106331-lin.cambridge.arm.com>
Message-ID: <20130709135808.10823.84545@quantum>

Quoting Mark Rutland (2013-06-26 01:40:58)
> Hi,
> 
> I have a couple of minor comments.
> 
> On Fri, Jun 21, 2013 at 07:14:14AM +0100, Mike Turquette wrote:
> > Device Tree binding for the basic clock multiplexer, plus the setup
> > function to register the clock.  Based on the existing fixed-clock
> > binding.
> > 
> > Includes minor beautification of clk-provider.h where some whitespace is
> > added and of_fixed_factor_clock_setup is relocated to maintain a
> > consistent style.
> > 
> > Tero Kristo contributed helpful bug fixes to this patch.
> > 
> > Signed-off-by: Mike Turquette <mturquette at linaro.org>
> > ---
> > Changes since v2:
> > * added hiword-mask property to the binding
> > * changed bit-shift property from u8 to u32 in the dt binding
> > 
> > Changes since v1:
> > * pass shift value into clk_register_mux_table
> > * s/multiplexor/multiplexer/
> > * removed debug prints
> > * mask is u32, shift is u8
> > * DT property names use dashes instead of underscores
> > * DT property names are more verbose
> > * shift property is optional in binding and can be auto-generated from a
> >   full 32-bit mask
> > 
> >  .../devicetree/bindings/clock/mux-clock.txt        | 79 ++++++++++++++++++++++
> >  drivers/clk/clk-mux.c                              | 65 +++++++++++++++++-
> >  include/linux/clk-provider.h                       |  5 +-
> >  3 files changed, 147 insertions(+), 2 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/clock/mux-clock.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/clock/mux-clock.txt b/Documentation/devicetree/bindings/clock/mux-clock.txt
> > new file mode 100644
> > index 0000000..54cb8d1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/mux-clock.txt
> > @@ -0,0 +1,79 @@
> > +Binding for simple mux clock.
> > +
> > +This binding uses the common clock binding[1].  It assumes a
> > +register-mapped multiplexer with multiple input clock signals or
> > +parents, one of which can be selected as output.  This clock does not
> > +gate or adjust the parent rate via a divider or multiplier.
> > +
> > +By default the "clocks" property lists the parents in the same order
> > +as they are programmed into the regster.  E.g:
> > +
> > +     clocks = <&foo_clock>, <&bar_clock>, <&baz_clock>;
> > +
> > +results in programming the register as follows:
> > +
> > +register value               selected parent clock
> > +0                    foo_clock
> > +1                    bar_clock
> > +2                    baz_clock
> > +
> > +Some clock controller IPs do not allow a value of zero to be programmed
> > +into the register, instead indexing begins at 1.  The optional property
> > +"index_one" modified the scheme as follows:
> 
> I assume this is meant to be "index-starts-at-one", given the code and
> changelog?
> 
> > +
> > +register value               selected clock parent
> > +1                    foo_clock
> > +2                    bar_clock
> > +3                    baz_clock
> > +
> > +Additionally an optional table of bit and parent pairs may be supplied
> > +like so:
> > +
> > +     table = <&foo_clock 0x0>, <&bar_clock, 0x2>, <&baz_clock, 0x4>;
> > +
> > +where the first value in the pair is the parent clock and the second
> > +value is the bitfield to be programmed into the register.
> > +
> > +The binding must provide the register to control the mux and the mask
> > +for the corresponding control bits.  Optionally the number of bits to
> > +shift that mask if necessary.  If the shift value is missing it is the
> > +same as supplying a zero shift.
> > +
> > +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +
> > +Required properties:
> > +- compatible : shall be "mux-clock".
> > +- #clock-cells : from common clock binding; shall be set to 0.
> > +- clocks : link phandles of parent clocks
> > +- reg : base address for register controlling adjustable mux
> > +- bit-mask : arbitrary bitmask for programming the adjustable mux
> > +
> > +Optional properties:
> > +- clock-output-names : From common clock binding.
> > +- table : array of integer pairs defining parents & bitfield values
> > +- bit-shift : number of bits to shift the bit-mask, defaults to
> > +  (ffs(mask) - 1) if not present
> > +- index-starts-at-one : valid input select programming starts at 1, not
> > +  zero
> > +- hiword-mask : lower half of the register programs the mux, upper half
> > +  of the register indicates bits that were updated in the lower half
> > +
> > +Examples:
> > +     clock: clock at 4a008100 {
> > +             compatible = "mux-clock";
> > +             #clock-cells = <0>;
> > +             clocks = <&clock_foo>, <&clock_bar>, <&clock_baz>;
> > +             reg = <0x4a008100 0x4>
> > +             mask = <0x3>;
> > +             index_one;
> 
> And here too?
> 
> [...]
> 
> > +/**
> > + * of_mux_clk_setup() - Setup function for simple mux rate clock
> > + */
> > +void of_mux_clk_setup(struct device_node *node)
> > +{
> > +     struct clk *clk;
> > +     const char *clk_name = node->name;
> > +     void __iomem *reg;
> > +     int num_parents;
> > +     const char **parent_names;
> > +     int i;
> > +     u8 clk_mux_flags = 0;
> > +     u32 mask = 0;
> > +     u32 shift = 0;
> > +
> > +     of_property_read_string(node, "clock-output-names", &clk_name);
> > +
> > +     num_parents = of_clk_get_parent_count(node);
> > +     if (num_parents < 1) {
> > +             pr_err("%s: mux-clock %s must have parent(s)\n",
> > +                             __func__, node->name);
> > +             return;
> > +     }
> > +
> > +     parent_names = kzalloc((sizeof(char*) * num_parents),
> > +                     GFP_KERNEL);
> > +
> > +     for (i = 0; i < num_parents; i++)
> > +             parent_names[i] = of_clk_get_parent_name(node, i);
> > +
> > +     reg = of_iomap(node, 0);
> 
> Would it not be a good idea to check this isn't NULL before we pass it
> to clk_register_mux_table later?
> 
> > +
> > +     if (of_property_read_u32(node, "bit-mask", &mask)) {
> > +             pr_err("%s: missing bit-mask property for %s\n", __func__, node->name);
> > +             return;
> > +     }
> > +
> > +     if (of_property_read_u32(node, "bit-shift", &shift)) {
> > +             shift = __ffs(mask);
> > +             pr_debug("%s: bit-shift property defaults to 0x%x for %s\n",
> > +                             __func__, shift, node->name);
> > +     }
> > +
> > +     if (of_property_read_bool(node, "index-starts-at-one"))
> > +             clk_mux_flags |= CLK_MUX_INDEX_ONE;
> > +
> > +     if (of_property_read_bool(node, "hiword-mask"))
> > +             clk_mux_flags |= CLK_MUX_HIWORD_MASK;
> > +
> > +     clk = clk_register_mux_table(NULL, clk_name, parent_names, num_parents,
> > +                     0, reg, (u8) shift, mask, clk_mux_flags,
> > +                     NULL, NULL);
> 
> Why do you need the (u8) cast on shift? Isn't that implicit?

All of your suggestions are good. I'll roll them into the next version.

Regards,
Mike
> 
> Thanks,
> Mark.


From rogerq at ti.com  Tue Jul  9 09:58:42 2013
From: rogerq at ti.com (Roger Quadros)
Date: Tue, 9 Jul 2013 16:58:42 +0300
Subject: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during
 bus suspend
In-Reply-To: <Pine.LNX.4.44L0.1306281346430.1047-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1306281346430.1047-100000@iolanthe.rowland.org>
Message-ID: <51DC1712.30401@ti.com>

On 06/28/2013 10:06 PM, Alan Stern wrote:
> On Fri, 28 Jun 2013, Roger Quadros wrote:
> 
>>> That's not what I meant.  Never mind the pinctrl; I was asking about
>>> the EHCI controller itself.  Under what circumstances does the
>>> controller assert its wakeup signal?  And how do you tell it to stop
>>> asserting that signal?
>>
>> I believe this would be through the EHCI Interrupt enable register (USBINTR).
>> I'm not aware of any other mechanism.
> 
> That's strange, because ehci_suspend() sets the intr_enable register to 
> 0.  So how do you ever get any wakeup interrupts at all?
> 
>> Right. It seems the external hub has signaled remote wakeup but the kernel doesn't
>> resume the root hub's port it is connected to.
>>
>> By observing the detailed logs below you can see that the root hub does not generate
>> an INTerrupt transaction to notify the port status change event. I've captured the pstatus
>> and GetPortStatus info as well.
> 
> We don't need an interrupt.  The driver is supposed to detect the
> remote wakeup sent by the external hub all by itself.
> 
>> Failing case
>> ------------
>>
>> [   16.108032] usb usb1: usb auto-resume
>> [   16.108062] ehci-omap 48064800.ehci: resume root hub
>> [   16.108154] hub 1-0:1.0: hub_resume
>> [   16.108398] ehci_hub_control GetPortStatus, port 1 temp = 0x1000
>> [   16.108459] ehci_hub_control GetPortStatus, port 2 temp = 0x14c5
> 
> Here's where we should detect it.  Look at the GetPortStatus case in
> ehci_hub_control(); the PORT_RESUME bit (0x0040) is set in temp, so the
> "Remote Wakeup received?" code should run.  In particular, these lines
> should run:
> 
> 			/* resume signaling for 20 msec */
> 			ehci->reset_done[wIndex] = jiffies
> 					+ msecs_to_jiffies(20);
> 			usb_hcd_start_port_resume(&hcd->self, wIndex);
> 			/* check the port again */
> 			mod_timer(&ehci_to_hcd(ehci)->rh_timer,
> 					ehci->reset_done[wIndex]);
> 
> Therefore 20 ms later, around timestamp 16.128459,
> ehci_hub_status_data() should have been called.  At that time, the
> root-hub port should have been fully resumed.
> 
>> [   16.108551] hub 1-0:1.0: port 2: status 0507 change 0000
>> [   16.108612] ehci_hub_control GetPortStatus, port 3 temp = 0x1000
>> [   16.108642] hub 1-0:1.0: hub_activate submitting urb
>> [   16.109222] ehci_irq port 3 pstatus 0x1000
>> [   16.109222] ehci_irq port 2 pstatus 0x14c5
>> [   16.109252] ehci_irq port 1 pstatus 0x1000
>> [   16.109374] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> 
> But apparently nothing happened.  Why not?  Did the rh_timer get reset?  
> Maybe you can find out what went wrong.
> 
> (Hmmm, we seem to be missing a
> 
> 			set_bit(wIndex, &ehci->resuming_ports);
> 
> line in there...)
> 

Right. This is indeed the problem. I've cooked up a patch for that and will send
it separately in a moment.

cheers,
-roger


From thomas.petazzoni at free-electrons.com  Tue Jul  9 10:01:32 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 9 Jul 2013 16:01:32 +0200
Subject: [PATCHv4 05/11] of: pci: add registry of MSI chips
In-Reply-To: <CAL_Jsq+h=y5SNo4qO5-5u_w8rW++9MKDZK8rASNjhtVcjh-iyQ@mail.gmail.com>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAL_Jsq+h=y5SNo4qO5-5u_w8rW++9MKDZK8rASNjhtVcjh-iyQ@mail.gmail.com>
Message-ID: <20130709160132.7f5e7a8e@skate>

Rob,

On Tue, 9 Jul 2013 08:43:36 -0500, Rob Herring wrote:

> > +int of_msi_chip_add(struct msi_chip *chip)
> 
> Perhaps of_pci_msi_chip_add instead.

Sure, makes sense.

> > +{
> > +       struct msi_chip *c;
> > +       list_for_each_entry(c, &msi_chip_list, list) {
> 
> Need the safe variant here?

As suggested by Bjorn, I've changed this function to grab the
msi_chip_mutex while traversing the list.

Does your e-mail implies that the general approach seems ok? If so,
I'll resend an updated v5 version taking into account the comments
that I have received on this v4.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From alexandre.belloni at free-electrons.com  Tue Jul  9 10:04:08 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Tue, 09 Jul 2013 16:04:08 +0200
Subject: [PATCHv3 1/3] iio: Add Nuvoton NAU7802 ADC driver
In-Reply-To: <51D7F044.9040205@kernel.org>
References: <1372094699-3832-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1372094699-3832-2-git-send-email-alexandre.belloni@free-electrons.com>
 <51D53B72.6020309@metafoo.de> <51D7F044.9040205@kernel.org>
Message-ID: <51DC1858.8010008@free-electrons.com>

Hi Jonathan,

I don't actually see it in iio.git on kernel.org, am I doing something
wrong ?

On 06/07/2013 12:24, Jonathan Cameron wrote:
> On 07/04/2013 10:08 AM, Lars-Peter Clausen wrote:
>> On 06/24/2013 07:24 PM, Alexandre Belloni wrote:
>>> The Nuvoton NAU7802 ADC is a 24-bit 2-channels I2C ADC, with adjustable
>>> gain and sampling rates.
>>>
>>> Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
>>> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
>> Reviewed-by: Lars-Peter Clausen <lars at metafoo.de>
>>
> Applied to the togreg branch of iio.git (with a few little tweaks).
>
> There was some fuzz that required manual fixing because of another driver merge so
> please check I didn't foul anything up with this or the other bits below.
>
> There were two trivial missing unlocks on error paths in the read_raw function that
> I've fixed up (Coccinelle found these for me - if you can I would always advise
> running sparse, coccicheck and ideally smatch before submitting patches).
>
> I fixed up the comments because if there is one thing I hate bothering
> with it is delightful patches that just fix this stuff. Much better
> to do it now given it took 20 secs ;)
>
>> One remark though. Multiline comments should be like
>>
>> /*
>>  * foo
>>  * bar
>>  */
>>
>> not
>>
>> /* foo
>>  * bar
>>  */
>>
>> But not need to resend the patch just for this
>>
>> - Lars
>>


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com



From sergei.shtylyov at cogentembedded.com  Tue Jul  9 10:07:51 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 09 Jul 2013 18:07:51 +0400
Subject: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
In-Reply-To: <1373361446-30050-1-git-send-email-george.cherian@ti.com>
References: <1373361446-30050-1-git-send-email-george.cherian@ti.com>
Message-ID: <51DC1937.9080302@cogentembedded.com>

Hello.

On 09-07-2013 13:17, George Cherian wrote:

> Adds device node for HS USB Host module for AM437x

> changes from v1

> renamed synopsis to snps
> removed flag tx-fifo-resize

> Signed-off-by: George Cherian <george.cherian at ti.com>
> ---
>   arch/arm/boot/dts/am4372.dtsi | 18 ++++++++++++++++++
>   1 file changed, 18 insertions(+)

> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index ddc1df7..c9e0da8 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -64,5 +64,23 @@
>   			compatible = "ti,am4372-counter32k","ti,omap-counter32k";
>   			reg = <0x44e86000 0x40>;
>   		};
> +
> +		usb_otg_hs1: am4372_dwc3 at 48380000 {

    See http://www.devicetree.org/Device_Tree_Usage, "Node Names" section.

> +			compatible = "ti,am437x-dwc3";
> +			reg = <0x48380000 0x1ff>;
> +			interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			utmi-mode = <1>;
> +			ranges;
> +
> +			dwc3 at 48390000 {

    The same comment.

> +				compatible = "snps,dwc3";
> +				reg = <0x48390000 0xcfff>;
> +				interrupts = <GIC_SPI  168 IRQ_TYPE_LEVEL_HIGH>;
> +			};
> +
> +		};
> +		

WBR, Sergei




From mark.rutland at arm.com  Tue Jul  9 10:16:03 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue,  9 Jul 2013 15:16:03 +0100
Subject: [PATCH 0/3] arm/arm64: a trio of boot mode detection fixes
Message-ID: <1373379366-15689-1-git-send-email-mark.rutland@arm.com>

The following patches fix a couple of issues in the boot mode detection
code where in the case of mismatched boot modes we can corrupt a small
portion of memory or fail to detect the fact we've booted CPUs with
mismatched modes due to the boot mode being logged incoherently.

Thanks,
Mark.

Mark Rutland (3):
  arm: hyp: fix macro parameterisation
  arm: virt: ensure visibility of __boot_cpu_mode
  arm64: virt: ensure visibility of __boot_cpu_mode

 arch/arm/include/asm/virt.h   | 12 ++++++++++++
 arch/arm/kernel/hyp-stub.S    |  4 ++--
 arch/arm/kernel/setup.c       |  2 ++
 arch/arm64/include/asm/virt.h | 13 +++++++++++++
 4 files changed, 29 insertions(+), 2 deletions(-)

-- 
1.8.1.1



From mark.rutland at arm.com  Tue Jul  9 10:16:05 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue,  9 Jul 2013 15:16:05 +0100
Subject: [PATCH 2/3] arm: virt: ensure visibility of __boot_cpu_mode
In-Reply-To: <1373379366-15689-1-git-send-email-mark.rutland@arm.com>
References: <1373379366-15689-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1373379366-15689-3-git-send-email-mark.rutland@arm.com>

Secondary CPUs write to __boot_cpu_mode with caches disabled, and thus a
cached value of __boot_cpu_mode may be incoherent with that in memory.
This could lead to a failure to detect mismatched boot modes.

This patch adds flushing to ensure that writes by secondaries to
__boot_cpu_mode are made visible before we test against it.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: Dave Martin <dave.martin at arm.com>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/include/asm/virt.h | 12 ++++++++++++
 arch/arm/kernel/setup.c     |  2 ++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
index 50af92b..4371f45 100644
--- a/arch/arm/include/asm/virt.h
+++ b/arch/arm/include/asm/virt.h
@@ -29,6 +29,7 @@
 #define BOOT_CPU_MODE_MISMATCH	PSR_N_BIT
 
 #ifndef __ASSEMBLY__
+#include <asm/cacheflush.h>
 
 #ifdef CONFIG_ARM_VIRT_EXT
 /*
@@ -41,10 +42,21 @@
  */
 extern int __boot_cpu_mode;
 
+static inline void sync_boot_mode(void)
+{
+	/*
+	 * As secondaries write to __boot_cpu_mode with caches disabled, we
+	 * must flush the corresponding cache entries to ensure the visibility
+	 * of their writes.
+	 */
+	sync_cache_r(&__boot_cpu_mode);
+}
+
 void __hyp_set_vectors(unsigned long phys_vector_base);
 unsigned long __hyp_get_vectors(void);
 #else
 #define __boot_cpu_mode	(SVC_MODE)
+#define sync_boot_mode()
 #endif
 
 #ifndef ZIMAGE
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index b4b1d39..4af9b38 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -744,6 +744,8 @@ static int __init meminfo_cmp(const void *_a, const void *_b)
 void __init hyp_mode_check(void)
 {
 #ifdef CONFIG_ARM_VIRT_EXT
+	sync_boot_mode();
+
 	if (is_hyp_mode_available()) {
 		pr_info("CPU: All CPU(s) started in HYP mode.\n");
 		pr_info("CPU: Virtualization extensions available.\n");
-- 
1.8.1.1



From mark.rutland at arm.com  Tue Jul  9 10:16:06 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue,  9 Jul 2013 15:16:06 +0100
Subject: [PATCH 3/3] arm64: virt: ensure visibility of __boot_cpu_mode
In-Reply-To: <1373379366-15689-1-git-send-email-mark.rutland@arm.com>
References: <1373379366-15689-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1373379366-15689-4-git-send-email-mark.rutland@arm.com>

Secondary CPUs write to __boot_cpu_mode with caches disabled, and thus a
cached value of __boot_cpu_mode may be incoherent with that in memory.
This could lead to a failure to detect mismatched boot modes.

This patch adds flushing to ensure that writes by secondaries to
__boot_cpu_mode are made visible before we test against it.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm64/include/asm/virt.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 4398272..24f0ae9 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -21,6 +21,7 @@
 #define BOOT_CPU_MODE_EL2	(0x0e12b007)
 
 #ifndef __ASSEMBLY__
+#include <asm/cacheflush.h>
 
 /*
  * __boot_cpu_mode records what mode CPUs were booted in.
@@ -36,9 +37,20 @@ extern u32 __boot_cpu_mode[2];
 void __hyp_set_vectors(phys_addr_t phys_vector_base);
 phys_addr_t __hyp_get_vectors(void);
 
+static inline void sync_boot_mode(void)
+{
+	/*
+	 * As secondaries write to __boot_cpu_mode with caches disabled, we
+	 * must flush the corresponding cache entries to ensure the visibility
+	 * of their writes.
+	 */
+	__flush_dcache_area(__boot_cpu_mode, sizeof(__boot_cpu_mode));
+}
+
 /* Reports the availability of HYP mode */
 static inline bool is_hyp_mode_available(void)
 {
+	sync_boot_mode();
 	return (__boot_cpu_mode[0] == BOOT_CPU_MODE_EL2 &&
 		__boot_cpu_mode[1] == BOOT_CPU_MODE_EL2);
 }
@@ -46,6 +58,7 @@ static inline bool is_hyp_mode_available(void)
 /* Check if the bootloader has booted CPUs in different modes */
 static inline bool is_hyp_mode_mismatched(void)
 {
+	sync_boot_mode();
 	return __boot_cpu_mode[0] != __boot_cpu_mode[1];
 }
 
-- 
1.8.1.1



From mark.rutland at arm.com  Tue Jul  9 10:16:04 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue,  9 Jul 2013 15:16:04 +0100
Subject: [PATCH 1/3] arm: hyp: fix macro parameterisation
In-Reply-To: <1373379366-15689-1-git-send-email-mark.rutland@arm.com>
References: <1373379366-15689-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1373379366-15689-2-git-send-email-mark.rutland@arm.com>

Currently, compare_cpu_mode_with_primary uses a mixture of macro
arguments and hardcoded registers, and does so incorrectly, as it
stores (__boot_cpu_mode_offset | BOOT_CPU_MODE_MISMATCH) to
(__boot_cpu_mode + &__boot_cpu_mode_offset), which could corrupt an
arbitrary portion of memory.

This patch fixes up compare_cpu_mode_with_primary to use the macro
arguments, correctly updating __boot_cpu_mode.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: Dave Martin <dave.martin at arm.com>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: Christoffer Dall <cdall at cs.columbia.edu>
---
 arch/arm/kernel/hyp-stub.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
index 1315c4c..bda76ce 100644
--- a/arch/arm/kernel/hyp-stub.S
+++ b/arch/arm/kernel/hyp-stub.S
@@ -56,8 +56,8 @@ ENTRY(__boot_cpu_mode)
 	ldr	\reg3, [\reg2]
 	ldr	\reg1, [\reg2, \reg3]
 	cmp	\mode, \reg1		@ matches primary CPU boot mode?
-	orrne	r7, r7, #BOOT_CPU_MODE_MISMATCH
-	strne	r7, [r5, r6]		@ record what happened and give up
+	orrne	\reg1, \reg1, #BOOT_CPU_MODE_MISMATCH
+	strne	\reg1, [\reg2, \reg3]	@ record what happened and give up
 	.endm
 
 #else	/* ZIMAGE */
-- 
1.8.1.1



From richard.genoud at gmail.com  Tue Jul  9 10:25:26 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 16:25:26 +0200
Subject: [PATCH v4 0/7] Sound support for at91sam9x5-wm8731 based boards
In-Reply-To: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>

[I've just seen that I forgot to cc Uwe to the cover letter, sorry for that.]

Hi,

This patchset add sound on the at91sam9x5ek board.
It's based on Nicolas Ferre's work in the 2.6.39 atmel patch for sam9x5:
https://github.com/linux4sam/linux-at91/commit/0aa157c9e71ccccf3abc30fa37eb5c95b392978d

It needs Bo Chen's patchset on the generic dmaengine (topic/atmel branch
on Mark's sound tree) and the SSC interrupts disabled (cf
http://www.spinics.net/lists/arm-kernel/msg256901.html)

Outstanding issue:
If this machine driver will support more SoCs maybe we should name it differently.


It has been tested on at91sam9g35ek, and should work on g15, g25, x25 and x35 also.

patches applies on next-20130708

[I let the original signed-off from Nicolas and Uwe in place, I don't
know if I should replace them by something like "originaly-signed-off-by"
since the code has been changed.]

Changes from v3:
 * Remove the use of macros in device tree documentation.

Changes from v2:
 * Change atmel,sam9x5-audio-wm8731 to atmel,sam9x5-wm8731-audio for
consistency with sam9g20 machine driver.
 * Use the snd_pcm_hw_constraint() API as suggested by Mark and Lars-Peter.
 * Remove the unnecessary snd_soc_dapm_sync() call as Lars-Peter suggested.
 * Add documentation for machine driver DT binding.
 * Update atmel-ssc DT binding documentation.
 * Add GPL license instead of just the "GPL" word (hope that's ok !)

Changes from v1-RFC:
 * drop patches on SSC since Bo Chen already did the work
 * reorder patches to have the machine driver first
 * drop code already handled by the ASoC framework
 * drop unneeded SND_ATMEL_SOC_PDC config selection
 * use static snd_soc_card and  snd_soc_dai_link structures.

Best regards,
Richard.

Nicolas Ferre (1):
  sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards

Richard Genoud (6):
  Documentation: DT: add sam9x5ek-wm8731 machine driver
  Documentation: DT: update atmel SSC with DMA binding
  ARM: AT91: DTS: sam9x5: add SSC DMA parameters
  ARM: AT91: DTS: sam9x5ek: add WM8731 codec
  ARM: AT91: DTS: sam9x5ek: add sound configuration
  ARM: AT91: DTS: sam9x5ek: enable SSC

 .../devicetree/bindings/misc/atmel-ssc.txt         |   20 +-
 .../bindings/sound/atmel-sam9x5-wm8731-audio.txt   |   30 +++
 arch/arm/boot/dts/at91sam9x5.dtsi                  |    3 +
 arch/arm/boot/dts/at91sam9x5ek.dtsi                |   27 +++
 sound/soc/atmel/Kconfig                            |   10 +
 sound/soc/atmel/Makefile                           |    2 +
 sound/soc/atmel/sam9x5_wm8731.c                    |  238 ++++++++++++++++++++
 7 files changed, 329 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
 create mode 100644 sound/soc/atmel/sam9x5_wm8731.c

-- 
1.7.10.4




From richard.genoud at gmail.com  Tue Jul  9 10:25:29 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 16:25:29 +0200
Subject: [PATCH v4 3/7] Documentation: DT: update atmel SSC with DMA binding
In-Reply-To: <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373379933-32749-4-git-send-email-richard.genoud@gmail.com>

As atmel-ssc can be used with DMA, the documentation should be updated.
Also, a configuration DMA example is given.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 .../devicetree/bindings/misc/atmel-ssc.txt         |   20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
index 38e51ad..7c320da 100644
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -6,10 +6,28 @@ Required properties:
 	- atmel,at91sam9g45-ssc: support dma transfer
 - reg: Should contain SSC registers location and length
 - interrupts: Should contain SSC interrupt
+For dma transfer:
+- dmas: DMA specifier, consisting of a phandle to DMA controller node,
+  the memory interface and SSC DMA channel ID (for tx and rx).
+  See Documentation/devicetree/bindings/dma/atmel-dma.txt for details.
+- dma-names: Must be "tx", "rx".
 
-Example:
+Examples:
 ssc0: ssc at fffbc000 {
 	compatible = "atmel,at91rm9200-ssc";
 	reg = <0xfffbc000 0x4000>;
 	interrupts = <14 4 5>;
 };
+
+
+ssc0: ssc at f0010000 {
+      compatible = "atmel,at91sam9g45-ssc";
+      reg = <0xf0010000 0x4000>;
+      interrupts = <28 4 5>;
+      dmas = <&dma0 1 13>,
+	     <&dma0 1 14>;
+      dma-names = "tx", "rx";
+      pinctrl-names = "default";
+      pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+      status = "disabled";
+};
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul  9 10:25:28 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 16:25:28 +0200
Subject: [PATCH v4 2/7] Documentation: DT: add sam9x5ek-wm8731 machine driver
In-Reply-To: <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373379933-32749-3-git-send-email-richard.genoud@gmail.com>

This add the sound DT binding for sam9x5ek-wm8731 machine driver

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 .../bindings/sound/atmel-sam9x5-wm8731-audio.txt   |   30 ++++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt

diff --git a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
new file mode 100644
index 0000000..fd03dfd
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
@@ -0,0 +1,30 @@
+* Atmel at91sam9x5ek wm8731 audio complex
+
+Required properties:
+  - compatible: "atmel,at91sam9x5ek-wm8731-audio"
+  - atmel,model: The user-visible name of this sound complex.
+  - atmel,audio-routing: A list of the connections between audio components.
+  - atmel,ssc-controller: The phandle of the SSC controller
+  - atmel,audio-codec: The phandle of the WM8731 audio codec
+  - atmel,format: DAI format. Must be "i2s"
+  - atmel,bitclock-master:  DAI clock master
+  - atmel,frame-master: DAI frame master
+
+Example:
+sound {
+	compatible = "atmel,sam9x5-wm8731-audio";
+
+	atmel,model = "wm8731 @ AT91SAM9X5EK";
+
+	atmel,audio-routing =
+		"Headphone Jack", "RHPOUT",
+		"Headphone Jack", "LHPOUT",
+		"LLINEIN", "Line In Jack",
+		"RLINEIN", "Line In Jack";
+
+	atmel,ssc-controller = <&ssc0>;
+	atmel,audio-codec = <&wm8731>;
+	atmel,format = "i2s";
+	atmel,bitclock-master;
+	atmel,frame-master;
+};
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul  9 10:25:27 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 16:25:27 +0200
Subject: [PATCH v4 1/7] sound: sam9x5_wm8731: machine driver for at91sam9x5
 wm8731 boards
In-Reply-To: <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373379933-32749-2-git-send-email-richard.genoud@gmail.com>

From: Nicolas Ferre <nicolas.ferre at atmel.com>

Description of the Asoc machine driver for an at91sam9x5 based board
with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
master on the SSC/I2S interface. Its connections are a headphone jack
and an Line input jack.

[Richard: this is based on an old patch from Nicolas that I forward
ported and reworked to use only device tree]

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 sound/soc/atmel/Kconfig         |   10 ++
 sound/soc/atmel/Makefile        |    2 +
 sound/soc/atmel/sam9x5_wm8731.c |  238 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 250 insertions(+)
 create mode 100644 sound/soc/atmel/sam9x5_wm8731.c

diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 1c0b185..9eb8c49 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -33,6 +33,16 @@ config SND_AT91_SOC_SAM9G20_WM8731
 	  Say Y if you want to add support for SoC audio on WM8731-based
 	  AT91sam9g20 evaluation board.
 
+config SND_AT91_SOC_SAM9X5_WM8731
+	tristate "SoC Audio support for WM8731-based at91sam9x5 board"
+	depends on ATMEL_SSC && SND_ATMEL_SOC && SOC_AT91SAM9X5
+	select SND_ATMEL_SOC_SSC
+	select SND_ATMEL_SOC_DMA
+	select SND_SOC_WM8731
+	help
+	  Say Y if you want to add support for audio SoC on an
+	  at91sam9x5 based board that is using WM8731 codec.
+
 config SND_AT91_SOC_AFEB9260
 	tristate "SoC Audio support for AFEB9260 board"
 	depends on ARCH_AT91 && ATMEL_SSC && ARCH_AT91 && MACH_AFEB9260 && SND_ATMEL_SOC
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index 41967cc..7784c09 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -11,6 +11,8 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
 
 # AT91 Machine Support
 snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
+snd-soc-sam9x5-wm8731-objs := sam9x5_wm8731.o
 
 obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
+obj-$(CONFIG_SND_AT91_SOC_SAM9X5_WM8731) += snd-soc-sam9x5-wm8731.o
 obj-$(CONFIG_SND_AT91_SOC_AFEB9260) += snd-soc-afeb9260.o
diff --git a/sound/soc/atmel/sam9x5_wm8731.c b/sound/soc/atmel/sam9x5_wm8731.c
new file mode 100644
index 0000000..c56e36b
--- /dev/null
+++ b/sound/soc/atmel/sam9x5_wm8731.c
@@ -0,0 +1,238 @@
+/*
+ * sam9x5_wm8731   --	SoC audio for AT91SAM9X5-based boards
+ *			that are using WM8731 as codec.
+ *
+ *  Copyright (C) 2011 Atmel,
+ *		  Nicolas Ferre <nicolas.ferre at atmel.com>
+ *
+ *  Copyright (C) 2013 Paratronic,
+ *		  Richard Genoud <richard.genoud at gmail.com>
+ *
+ * Based on sam9g20_wm8731.c by:
+ * Sedji Gaouaou <sedji.gaouaou at atmel.com>
+ *
+ *  This program is free software; you can redistribute  it and/or modify it
+ *  under  the terms of  the GNU General  Public License as published by the
+ *  Free Software Foundation;  either version 2 of the  License, or (at your
+ *  option) any later version.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/kernel.h>
+#include <linux/clk.h>
+#include <linux/timer.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/i2c.h>
+
+#include <linux/atmel-ssc.h>
+
+#include <sound/core.h>
+#include <sound/pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+
+#include <asm/mach-types.h>
+#include <mach/hardware.h>
+#include <mach/gpio.h>
+
+#include "../codecs/wm8731.h"
+#include "atmel-pcm.h"
+#include "atmel_ssc_dai.h"
+
+#define MCLK_RATE 12288000
+
+#define DRV_NAME "sam9x5-snd-wm8731"
+
+/*
+ * Authorized rates are:
+ * Rate = MCLK_RATE / (n * 2)
+ * Where n is in [1..4095]
+ * (cf register SSC_CMR)
+ */
+static unsigned int rates[] = {
+	8000,
+	16000,
+	32000,
+	48000,
+	64000,
+	96000,
+};
+
+static struct snd_pcm_hw_constraint_list hw_rates = {
+	.count = ARRAY_SIZE(rates),
+	.list = rates,
+};
+
+/*
+ * Logic for a wm8731 as connected on a at91sam9x5 based board.
+ */
+static int at91sam9x5ek_wm8731_init(struct snd_soc_pcm_runtime *rtd)
+{
+	struct snd_soc_dai *codec_dai = rtd->codec_dai;
+	struct device *dev = rtd->dev;
+	int ret;
+
+	dev_dbg(dev, "ASoC: %s called\n", __func__);
+
+	/* set the codec system clock for DAC and ADC */
+	ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
+				     MCLK_RATE, SND_SOC_CLOCK_IN);
+	if (ret < 0) {
+		dev_err(dev, "ASoC: Failed to set WM8731 SYSCLK: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int sam9x5ek_wm8731_startup(struct snd_pcm_substream *substream)
+{
+	struct snd_pcm_runtime *runtime = substream->runtime;
+
+	runtime->hw.rate_min = hw_rates.list[0];
+	runtime->hw.rate_max = hw_rates.list[hw_rates.count - 1];
+	runtime->hw.rates = SNDRV_PCM_RATE_KNOT;
+
+	return snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
+					  &hw_rates);
+}
+
+/*
+ * Audio paths on at91sam9x5ek board:
+ *
+ *  |A| ------------> |      | ---R----> Headphone Jack
+ *  |T| <----\        |  WM  | ---L--/
+ *  |9| ---> CLK <--> | 8731 | <--R----- Line In Jack
+ *  |1| <------------ |      | <--L--/
+ */
+static const struct snd_soc_dapm_widget at91sam9x5ek_dapm_widgets[] = {
+	SND_SOC_DAPM_HP("Headphone Jack", NULL),
+	SND_SOC_DAPM_LINE("Line In Jack", NULL),
+};
+
+static struct snd_soc_ops sam9x5ek_wm8731_ops = {
+	.startup = sam9x5ek_wm8731_startup,
+};
+
+static struct snd_soc_dai_link at91sam9x5ek_dai = {
+	.name = "WM8731",
+	.stream_name = "WM8731 PCM",
+	.codec_dai_name = "wm8731-hifi",
+	.init = at91sam9x5ek_wm8731_init,
+	.ops = &sam9x5ek_wm8731_ops,
+};
+
+static struct snd_soc_card snd_soc_at91sam9x5ek = {
+	.owner = THIS_MODULE,
+	.dai_link = &at91sam9x5ek_dai,
+	.num_links = 1,
+	.dapm_widgets = at91sam9x5ek_dapm_widgets,
+	.num_dapm_widgets = ARRAY_SIZE(at91sam9x5ek_dapm_widgets),
+};
+
+static int sam9x5_wm8731_driver_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *codec_np, *cpu_np;
+	int ret;
+
+	if (!np) {
+		dev_err(&pdev->dev, "No device node supplied\n");
+		return -EINVAL;
+	}
+
+	ret = atmel_ssc_set_audio(0);
+	if (ret != 0) {
+		dev_err(&pdev->dev,
+			"ASoC: Failed to set SSC 0 for audio: %d\n", ret);
+		return ret;
+	}
+
+	snd_soc_at91sam9x5ek.dev = &pdev->dev;
+
+	ret = snd_soc_of_parse_card_name(&snd_soc_at91sam9x5ek, "atmel,model");
+	if (ret)
+		goto out;
+
+	ret = snd_soc_of_parse_audio_routing(&snd_soc_at91sam9x5ek,
+					     "atmel,audio-routing");
+	if (ret)
+		goto out;
+
+	codec_np = of_parse_phandle(np, "atmel,audio-codec", 0);
+	if (!codec_np) {
+		dev_err(&pdev->dev, "codec info missing\n");
+		ret = -EINVAL;
+		goto out;
+	}
+
+	at91sam9x5ek_dai.codec_of_node = codec_np;
+
+	cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
+	if (!cpu_np) {
+		dev_err(&pdev->dev, "ssc controller node missing\n");
+		ret = -EINVAL;
+		goto out;
+	}
+	at91sam9x5ek_dai.cpu_of_node = cpu_np;
+	at91sam9x5ek_dai.platform_of_node = cpu_np;
+
+	of_node_put(codec_np);
+	of_node_put(cpu_np);
+
+	at91sam9x5ek_dai.dai_fmt = snd_soc_of_parse_daifmt(np, "atmel,");
+
+	ret = snd_soc_register_card(&snd_soc_at91sam9x5ek);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"ASoC: Platform device allocation failed\n");
+		goto out;
+	}
+
+	platform_set_drvdata(pdev, &snd_soc_at91sam9x5ek);
+
+	dev_dbg(&pdev->dev, "ASoC: %s ok\n", __func__);
+
+	return ret;
+
+out:
+	atmel_ssc_put_audio(0);
+	return ret;
+}
+
+static int sam9x5_wm8731_driver_remove(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = platform_get_drvdata(pdev);
+
+	snd_soc_unregister_card(card);
+	atmel_ssc_put_audio(0);
+
+	return 0;
+}
+
+static const struct of_device_id sam9x5_wm8731_of_match[] = {
+	{ .compatible = "atmel,sam9x5-wm8731-audio", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sam9x5_wm8731_of_match);
+
+static struct platform_driver sam9x5_wm8731_driver = {
+	.driver = {
+		.name = DRV_NAME,
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(sam9x5_wm8731_of_match),
+	},
+	.probe = sam9x5_wm8731_driver_probe,
+	.remove = sam9x5_wm8731_driver_remove,
+};
+module_platform_driver(sam9x5_wm8731_driver);
+
+/* Module information */
+MODULE_AUTHOR("Nicolas Ferre <nicolas.ferre at atmel.com>");
+MODULE_AUTHOR("Richard Genoud <richard.genoud at gmail.com>");
+MODULE_DESCRIPTION("ALSA SoC machine driver for AT91SAM9x5 - WM8731");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:" DRV_NAME);
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul  9 10:25:30 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 16:25:30 +0200
Subject: [PATCH v4 4/7] ARM: AT91: DTS: sam9x5: add SSC DMA parameters
In-Reply-To: <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373379933-32749-5-git-send-email-richard.genoud@gmail.com>

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5.dtsi |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 57d45f5..cf78ac0 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -542,6 +542,9 @@
 				compatible = "atmel,at91sam9g45-ssc";
 				reg = <0xf0010000 0x4000>;
 				interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
+				dmas = <&dma0 1 AT91_DMA_CFG_PER_ID(13)>,
+				       <&dma0 1 AT91_DMA_CFG_PER_ID(14)>;
+				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
 				status = "disabled";
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul  9 10:25:31 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 16:25:31 +0200
Subject: [PATCH v4 5/7] ARM: AT91: DTS: sam9x5ek: add WM8731 codec
In-Reply-To: <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373379933-32749-6-git-send-email-richard.genoud@gmail.com>

The WM8731 codec on sam9x5ek board is on i2c, address 1A

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
Acked-by: Mark Brown <broonie at linaro.org>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index d107241..e6fb309 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -59,6 +59,11 @@
 
 			i2c0: i2c at f8010000 {
 				status = "okay";
+
+				wm8731: wm8731 at 1a {
+					compatible = "wm8731";
+					reg = <0x1a>;
+				};
 			};
 
 			pinctrl at fffff400 {
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul  9 10:25:33 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 16:25:33 +0200
Subject: [PATCH v4 7/7] ARM: AT91: DTS: sam9x5ek: enable SSC
In-Reply-To: <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373379933-32749-8-git-send-email-richard.genoud@gmail.com>

Enable the SSC needed for the WM8731 codec

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index 2bf51cc..0534c58 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -95,6 +95,10 @@
 			watchdog at fffffe40 {
 				status = "okay";
 			};
+
+			ssc0: ssc at f0010000 {
+				status = "okay";
+			};
 		};
 
 		usb0: ohci at 00600000 {
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul  9 10:25:32 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue,  9 Jul 2013 16:25:32 +0200
Subject: [PATCH v4 6/7] ARM: AT91: DTS: sam9x5ek: add sound configuration
In-Reply-To: <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373379933-32749-7-git-send-email-richard.genoud@gmail.com>

The sam9x5ek board has 2 jacks:
headphone wired on RHPOUT/LHPOUT of the wm8731
line in wired on LLINEIN/RLINEIN of the wm8731

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index e6fb309..2bf51cc 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -109,4 +109,22 @@
 			status = "okay";
 		};
 	};
+
+	sound {
+		compatible = "atmel,sam9x5-wm8731-audio";
+
+		atmel,model = "wm8731 @ AT91SAM9X5EK";
+
+		atmel,audio-routing =
+			"Headphone Jack", "RHPOUT",
+			"Headphone Jack", "LHPOUT",
+			"LLINEIN", "Line In Jack",
+			"RLINEIN", "Line In Jack";
+
+		atmel,ssc-controller = <&ssc0>;
+		atmel,audio-codec = <&wm8731>;
+		atmel,format = "i2s";
+		atmel,bitclock-master;
+		atmel,frame-master;
+	};
 };
-- 
1.7.10.4



From swarren at wwwdotorg.org  Tue Jul  9 10:27:00 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 09 Jul 2013 08:27:00 -0600
Subject: [PATCH] of: match the compatible in the order set by the dts file
In-Reply-To: <20130709070541.GQ516@pengutronix.de>
References: <1373013818-11365-1-git-send-email-b32955@freescale.com>
 <20130709070541.GQ516@pengutronix.de>
Message-ID: <51DC1DB4.3050802@wwwdotorg.org>

On 07/09/2013 01:05 AM, Sascha Hauer wrote:
> On Fri, Jul 05, 2013 at 04:43:38PM +0800, Huang Shijie wrote:
>> If we set the uart compatible in the dts file like this:
>>    ------------------------------------------------------
>>     compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
>>    ------------------------------------------------------
>>
>> and we set the uart compatible in the uart driver like this:
>>    ------------------------------------------------------
>> 	{ .compatible = "fsl,imx1-uart", ... },
>> 	{ .compatible = "fsl,imx21-uart", ... },
>> 	{ .compatible = "fsl,imx6q-uart", ... },
>> 	{ /* sentinel */ }
>>    ------------------------------------------------------
>>
>> the current code will match the "fsl,imx21-uart" in the end.
>>
>> Of course, this is not what we want. We want it to match the "fsl,imx6q-uart".
>>
>> This patch rewrites the match code, and make it to check the compatible
>> in the order set by the DTS file.
> 
> Why don't you set the matching order in the driver the way you want it
> to be, i.e.:
> 
> 	{ .compatible = "fsl,imx6q-uart", ... },
> 	{ .compatible = "fsl,imx21-uart", ... },
> 	{ .compatible = "fsl,imx1-uart", ... },

DT semantics are that earlier entries in the compatible property are
supposed to be matched first, irrespective of how the driver is constructed.



From lee.jones at linaro.org  Tue Jul  9 10:37:53 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  9 Jul 2013 15:37:53 +0100
Subject: [PATCH 0/3] DMA: shdma: changes to ***** in DMA ****
Message-ID: <1373380677-450-1-git-send-email-lee.jones@linaro.org>

Dear Vinod,

This pathc 



From lee.jones at linaro.org  Tue Jul  9 10:37:54 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  9 Jul 2013 15:37:54 +0100
Subject: [PATCH 1/3] DMA: shdma: (cosmetic) don't re-calculate a pointer
In-Reply-To: <1373380677-450-1-git-send-email-lee.jones@linaro.org>
References: <1373380677-450-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1373380677-450-2-git-send-email-lee.jones@linaro.org>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Use an existing pointer instead of retrieving it again.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Signed-off-by: Vinod Koul <vinod.koul at intel.com>
---
 drivers/dma/sh/shdma.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
index b70709b..a5a1887 100644
--- a/drivers/dma/sh/shdma.c
+++ b/drivers/dma/sh/shdma.c
@@ -729,7 +729,7 @@ static int sh_dmae_probe(struct platform_device *pdev)
 		goto eshdma;
 
 	/* platform data */
-	shdev->pdata = pdev->dev.platform_data;
+	shdev->pdata = pdata;
 
 	if (pdata->chcr_offset)
 		shdev->chcr_offset = pdata->chcr_offset;
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Jul  9 10:37:55 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  9 Jul 2013 15:37:55 +0100
Subject: [PATCH 2/3] DMA: shdma: shdma_chan_filter() has to be in shdma-base.h
In-Reply-To: <1373380677-450-1-git-send-email-lee.jones@linaro.org>
References: <1373380677-450-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1373380677-450-3-git-send-email-lee.jones@linaro.org>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

shdma_chan_filter() is a function, provided by the shdma-base.c module,
move its declaration to the appropriate header.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Signed-off-by: Vinod Koul <vinod.koul at intel.com>
---
 include/linux/sh_dma.h     |    2 --
 include/linux/shdma-base.h |    1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
index b64d6be..4e83f3e 100644
--- a/include/linux/sh_dma.h
+++ b/include/linux/sh_dma.h
@@ -99,6 +99,4 @@ struct sh_dmae_pdata {
 #define CHCR_TE	0x00000002
 #define CHCR_IE	0x00000004
 
-bool shdma_chan_filter(struct dma_chan *chan, void *arg);
-
 #endif
diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
index a3728bf..9a93897 100644
--- a/include/linux/shdma-base.h
+++ b/include/linux/shdma-base.h
@@ -122,5 +122,6 @@ void shdma_chan_remove(struct shdma_chan *schan);
 int shdma_init(struct device *dev, struct shdma_dev *sdev,
 		    int chan_num);
 void shdma_cleanup(struct shdma_dev *sdev);
+bool shdma_chan_filter(struct dma_chan *chan, void *arg);
 
 #endif
-- 
1.7.10.4



From lee.jones at linaro.org  Tue Jul  9 10:37:56 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  9 Jul 2013 15:37:56 +0100
Subject: [PATCH 3/3] DMA: shdma: add DT support
In-Reply-To: <1373380677-450-1-git-send-email-lee.jones@linaro.org>
References: <1373380677-450-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1373380677-450-4-git-send-email-lee.jones@linaro.org>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

This patch adds Device Tree support to the shdma driver. No special DT
properties are used, only standard DMA DT bindings are implemented. Since
shdma controllers reside on SoCs, their configuration is SoC-specific and
shall be passed to the driver from the SoC platform data, using the
auxdata procedure.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Vinod Koul <vinod.koul at intel.com>
---
 Documentation/devicetree/bindings/dma/shdma.txt |   75 +++++++++++++++++++++
 drivers/dma/sh/Makefile                         |    2 +-
 drivers/dma/sh/shdma-base.c                     |   26 +++++--
 drivers/dma/sh/shdma-of.c                       |   82 +++++++++++++++++++++++
 drivers/dma/sh/shdma.c                          |   31 +++++++--
 include/linux/shdma-base.h                      |    2 +
 6 files changed, 205 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/shdma.txt
 create mode 100644 drivers/dma/sh/shdma-of.c

diff --git a/Documentation/devicetree/bindings/dma/shdma.txt b/Documentation/devicetree/bindings/dma/shdma.txt
new file mode 100644
index 0000000..c15994a
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/shdma.txt
@@ -0,0 +1,75 @@
+* SHDMA Device Tree bindings
+
+Sh-/r-mobile and r-car systems often have multiple identical DMA controller
+instances, capable of serving any of a common set of DMA slave devices, using
+the same configuration. To describe this topology we require all compatible
+SHDMA DT nodes to be placed under a DMA multiplexer node. All such compatible
+DMAC instances have the same number of channels and use the same DMA
+descriptors. Therefore respective DMA DT bindings can also all be placed in the
+multiplexer node. Even if there is only one such DMAC instance on a system, it
+still has to be placed under such a multiplexer node.
+
+* DMA multiplexer
+
+Required properties:
+- compatible:	should be "renesas,shdma-mux"
+- #dma-cells:	should be <1>, see "dmas" property below
+
+Optional properties (currently unused):
+- dma-channels:	number of DMA channels
+- dma-requests:	number of DMA request signals
+
+* DMA controller
+
+Required properties:
+- compatible:	should be "renesas,shdma"
+
+Example:
+	dmac: dma-mux0 {
+		compatible = "renesas,shdma-mux";
+		#dma-cells = <1>;
+		dma-channels = <6>;
+		dma-requests = <256>;
+		reg = <0 0>;	/* Needed for AUXDATA */
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		dma0: shdma at fe008020 {
+			compatible = "renesas,shdma";
+			reg = <0xfe008020 0x270>,
+				<0xfe009000 0xc>;
+			interrupt-parent = <&gic>;
+			interrupts = <0 34 4
+					0 28 4
+					0 29 4
+					0 30 4
+					0 31 4
+					0 32 4
+					0 33 4>;
+			interrupt-names = "error",
+					"ch0", "ch1", "ch2", "ch3",
+					"ch4", "ch5";
+		};
+
+		dma1: shdma at fe018020 {
+			...
+		};
+
+		dma2: shdma at fe028020 {
+			...
+		};
+	};
+
+* DMA client
+
+Required properties:
+- dmas:		a list of <[DMA multiplexer phandle] [MID/RID value]> pairs,
+		where MID/RID values are fixed handles, specified in the SoC
+		manual
+- dma-names:	a list of DMA channel names, one per "dmas" entry
+
+Example:
+	dmas = <&dmac 0xd1
+		&dmac 0xd2>;
+	dma-names = "tx", "rx";
diff --git a/drivers/dma/sh/Makefile b/drivers/dma/sh/Makefile
index c07ca46..c962138 100644
--- a/drivers/dma/sh/Makefile
+++ b/drivers/dma/sh/Makefile
@@ -1,3 +1,3 @@
-obj-$(CONFIG_SH_DMAE_BASE) += shdma-base.o
+obj-$(CONFIG_SH_DMAE_BASE) += shdma-base.o shdma-of.o
 obj-$(CONFIG_SH_DMAE) += shdma.o
 obj-$(CONFIG_SUDMAC) += sudmac.o
diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c
index 4acb85a..28ca361 100644
--- a/drivers/dma/sh/shdma-base.c
+++ b/drivers/dma/sh/shdma-base.c
@@ -175,7 +175,18 @@ static int shdma_setup_slave(struct shdma_chan *schan, int slave_id)
 {
 	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
 	const struct shdma_ops *ops = sdev->ops;
-	int ret;
+	int ret, match;
+
+	if (schan->dev->of_node) {
+		match = schan->hw_req;
+		ret = ops->set_slave(schan, match, true);
+		if (ret < 0)
+			return ret;
+
+		slave_id = schan->slave_id;
+	} else {
+		match = slave_id;
+	}
 
 	if (slave_id < 0 || slave_id >= slave_num)
 		return -EINVAL;
@@ -183,7 +194,7 @@ static int shdma_setup_slave(struct shdma_chan *schan, int slave_id)
 	if (test_and_set_bit(slave_id, shdma_slave_used))
 		return -EBUSY;
 
-	ret = ops->set_slave(schan, slave_id, false);
+	ret = ops->set_slave(schan, match, false);
 	if (ret < 0) {
 		clear_bit(slave_id, shdma_slave_used);
 		return ret;
@@ -206,23 +217,26 @@ static int shdma_setup_slave(struct shdma_chan *schan, int slave_id)
  * services would have to provide their own filters, which first would check
  * the device driver, similar to how other DMAC drivers, e.g., sa11x0-dma.c, do
  * this, and only then, in case of a match, call this common filter.
+ * NOTE 2: This filter function is also used in the DT case by shdma_of_xlate().
+ * In that case the MID-RID value is used for slave channel filtering and is
+ * passed to this function in the "arg" parameter.
  */
 bool shdma_chan_filter(struct dma_chan *chan, void *arg)
 {
 	struct shdma_chan *schan = to_shdma_chan(chan);
 	struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
 	const struct shdma_ops *ops = sdev->ops;
-	int slave_id = (int)arg;
+	int match = (int)arg;
 	int ret;
 
-	if (slave_id < 0)
+	if (match < 0)
 		/* No slave requested - arbitrary channel */
 		return true;
 
-	if (slave_id >= slave_num)
+	if (!schan->dev->of_node && match >= slave_num)
 		return false;
 
-	ret = ops->set_slave(schan, slave_id, true);
+	ret = ops->set_slave(schan, match, true);
 	if (ret < 0)
 		return false;
 
diff --git a/drivers/dma/sh/shdma-of.c b/drivers/dma/sh/shdma-of.c
new file mode 100644
index 0000000..11bcb05
--- /dev/null
+++ b/drivers/dma/sh/shdma-of.c
@@ -0,0 +1,82 @@
+/*
+ * SHDMA Device Tree glue
+ *
+ * Copyright (C) 2013 Renesas Electronics Inc.
+ * Author: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/dmaengine.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_dma.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/shdma-base.h>
+
+#define to_shdma_chan(c) container_of(c, struct shdma_chan, dma_chan)
+
+static struct dma_chan *shdma_of_xlate(struct of_phandle_args *dma_spec,
+				       struct of_dma *ofdma)
+{
+	u32 id = dma_spec->args[0];
+	dma_cap_mask_t mask;
+	struct dma_chan *chan;
+
+	if (dma_spec->args_count != 1)
+		return NULL;
+
+	dma_cap_zero(mask);
+	/* Only slave DMA channels can be allocated via DT */
+	dma_cap_set(DMA_SLAVE, mask);
+
+	chan = dma_request_channel(mask, shdma_chan_filter, (void *)id);
+	if (chan)
+		to_shdma_chan(chan)->hw_req = id;
+
+	return chan;
+}
+
+static int shdma_of_probe(struct platform_device *pdev)
+{
+	const struct of_dev_auxdata *lookup = pdev->dev.platform_data;
+	int ret;
+
+	if (!lookup)
+		return -EINVAL;
+
+	ret = of_dma_controller_register(pdev->dev.of_node,
+					 shdma_of_xlate, pdev);
+	if (ret < 0)
+		return ret;
+
+	ret = of_platform_populate(pdev->dev.of_node, NULL, lookup, &pdev->dev);
+	if (ret < 0)
+		of_dma_controller_free(pdev->dev.of_node);
+
+	return ret;
+}
+
+static const struct of_device_id shdma_of_match[] = {
+	{ .compatible = "renesas,shdma-mux", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, sh_dmae_of_match);
+
+static struct platform_driver shdma_of = {
+	.driver		= {
+		.owner	= THIS_MODULE,
+		.name	= "shdma-of",
+		.of_match_table = shdma_of_match,
+	},
+	.probe		= shdma_of_probe,
+};
+
+module_platform_driver(shdma_of);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("SH-DMA driver DT glue");
+MODULE_AUTHOR("Guennadi Liakhovetski <g.liakhovetski at gmx.de>");
diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
index a5a1887..b67f45f 100644
--- a/drivers/dma/sh/shdma.c
+++ b/drivers/dma/sh/shdma.c
@@ -301,20 +301,32 @@ static void sh_dmae_setup_xfer(struct shdma_chan *schan,
 	}
 }
 
+/*
+ * Find a slave channel configuration from the contoller list by either a slave
+ * ID in the non-DT case, or by a MID/RID value in the DT case
+ */
 static const struct sh_dmae_slave_config *dmae_find_slave(
-	struct sh_dmae_chan *sh_chan, int slave_id)
+	struct sh_dmae_chan *sh_chan, int match)
 {
 	struct sh_dmae_device *shdev = to_sh_dev(sh_chan);
 	struct sh_dmae_pdata *pdata = shdev->pdata;
 	const struct sh_dmae_slave_config *cfg;
 	int i;
 
-	if (slave_id >= SH_DMA_SLAVE_NUMBER)
-		return NULL;
+	if (!sh_chan->shdma_chan.dev->of_node) {
+		if (match >= SH_DMA_SLAVE_NUMBER)
+			return NULL;
 
-	for (i = 0, cfg = pdata->slave; i < pdata->slave_num; i++, cfg++)
-		if (cfg->slave_id == slave_id)
-			return cfg;
+		for (i = 0, cfg = pdata->slave; i < pdata->slave_num; i++, cfg++)
+			if (cfg->slave_id == match)
+				return cfg;
+	} else {
+		for (i = 0, cfg = pdata->slave; i < pdata->slave_num; i++, cfg++)
+			if (cfg->mid_rid == match) {
+				sh_chan->shdma_chan.slave_id = cfg->slave_id;
+				return cfg;
+			}
+	}
 
 	return NULL;
 }
@@ -920,11 +932,18 @@ static int sh_dmae_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id sh_dmae_of_match[] = {
+	{ .compatible = "renesas,shdma", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, sh_dmae_of_match);
+
 static struct platform_driver sh_dmae_driver = {
 	.driver 	= {
 		.owner	= THIS_MODULE,
 		.pm	= &sh_dmae_pm,
 		.name	= SH_DMAE_DRV_NAME,
+		.of_match_table = sh_dmae_of_match,
 	},
 	.remove		= sh_dmae_remove,
 	.shutdown	= sh_dmae_shutdown,
diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
index 9a93897..382cf71 100644
--- a/include/linux/shdma-base.h
+++ b/include/linux/shdma-base.h
@@ -68,6 +68,8 @@ struct shdma_chan {
 	int id;				/* Raw id of this channel */
 	int irq;			/* Channel IRQ */
 	int slave_id;			/* Client ID for slave DMA */
+	int hw_req;			/* DMA request line for slave DMA - same
+					 * as MID/RID, used with DT */
 	enum shdma_pm_state pm_state;
 };
 
-- 
1.7.10.4



From swarren at wwwdotorg.org  Tue Jul  9 10:40:26 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 09 Jul 2013 08:40:26 -0600
Subject: [PATCH] of: match the compatible in the order set by the dts file
In-Reply-To: <CAL_JsqL4ABJCQXveSAMZKOiHwJi=w8zFYjg3DV7kqEEcCXQJcw@mail.gmail.com>
References: <1373013818-11365-1-git-send-email-b32955@freescale.com>
 <20130709070541.GQ516@pengutronix.de> <51DBBFDA.70302@freescale.com>
 <20130709075124.GR516@pengutronix.de> <51DBC58D.90002@freescale.com>
 <CAL_JsqL4ABJCQXveSAMZKOiHwJi=w8zFYjg3DV7kqEEcCXQJcw@mail.gmail.com>
Message-ID: <51DC20DA.7050802@wwwdotorg.org>

On 07/09/2013 06:03 AM, Rob Herring wrote:
> On Tue, Jul 9, 2013 at 3:10 AM, Huang Shijie <b32955 at freescale.com> wrote:
>> ? 2013?07?09? 15:51, Sascha Hauer ??:
>>
>>> On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
>>>>
>>>> ? 2013?07?09? 15:05, Sascha Hauer ??:
>>>>>
>>>>> Why don't you set the matching order in the driver the way you want it
>>>>> to be, i.e.:
>>>>>
>>>>>         { .compatible = "fsl,imx6q-uart", ... },
>>>>>         { .compatible = "fsl,imx21-uart", ... },
>>>>>         { .compatible = "fsl,imx1-uart", ... },
>>>>>
>>>> yes. i can set it like this.
>>>>
>>>> but this method looks like a ugly workaround.
>>>
>>> If a driver has different ways of supporting a single device, then
>>> putting the preferred or most feature rich on top doesn't look very ugly
>>> to me.
>>
>> this method makes it much _coupled_ between the driver and the dts file.
>>
>> IMHO, it's an unnecessary _burden_ to the driver programmer:
>>    he should puts the most feature compatible on the top.
>>
>> it's much graceful if we let the driver programmer be transparent about
>> this.
> 
> The dts requires compatible strings to be most specific to least
> specific. There is no reason that driver match tables should not be
> the same and that is the assumption. Matching is not just based on
> compatible properties and your patch does not handle the other cases.

Well, that may be true, but the only way to guarantee that the DT
compatible property is matched correctly is to match it in the order
it's written. Forcing driver writers to write the of_match table in a
particular order is quite a hack, and doesn't guarantee the correct
match order in all cases, only typical cases.


From broonie at kernel.org  Tue Jul  9 10:42:37 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Jul 2013 15:42:37 +0100
Subject: [PATCH v4 0/7] Sound support for at91sam9x5-wm8731 based boards
In-Reply-To: <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <20130709144237.GW27646@sirena.org.uk>

On Tue, Jul 09, 2013 at 04:25:26PM +0200, Richard Genoud wrote:
> [I've just seen that I forgot to cc Uwe to the cover letter, sorry for that.]

This is the second or third copy of this patch set I've been sent
*today*.  Worse, everything seems to be being sent in reply to the same
thread increasing the nesting substantially.  Please slow down, it's
flooding my mailbox and discouraging me from looking since it seems
likely that there will just be another resend.
-------------- 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/20130709/072ec8b4/attachment.sig>

From broonie at kernel.org  Tue Jul  9 10:44:25 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Jul 2013 15:44:25 +0100
Subject: [PATCH 3/3] ARM:dts:vf610-twr:Enable DSPI0 devices and Flash
 at26df081a
In-Reply-To: <20130709125239.GA2813@S2101-09.ap.freescale.net>
References: <1373272622-29064-1-git-send-email-b44548@freescale.com>
 <1373272622-29064-3-git-send-email-b44548@freescale.com>
 <20130708113600.GU27646@sirena.org.uk>
 <20130709052925.GD16656@S2101-09.ap.freescale.net>
 <20130709100723.GS27646@sirena.org.uk>
 <20130709125239.GA2813@S2101-09.ap.freescale.net>
Message-ID: <20130709144425.GX27646@sirena.org.uk>

On Tue, Jul 09, 2013 at 08:52:41PM +0800, Shawn Guo wrote:
> On Tue, Jul 09, 2013 at 11:07:23AM +0100, Mark Brown wrote:

> > The bindings are all totally generic ones for a SPI controller, there's
> > nothing controversial or even device specific about them so I'm happy to
> > say the bindings are fine as-is.

> Am I missing something?  I do not even see a bindings doc in patch #1.
> How can I think the bindings are fine?

Hrm, I was sure I was seeing one...  though in any case there's nothing
here except for interrupt and DMA hookup so any additional properties
aren't going to affect this patch.
-------------- 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/20130709/6540129f/attachment.sig>

From richard.genoud at gmail.com  Tue Jul  9 10:52:47 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 9 Jul 2013 16:52:47 +0200
Subject: [PATCH v4 0/7] Sound support for at91sam9x5-wm8731 based boards
In-Reply-To: <20130709144237.GW27646@sirena.org.uk>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
 <20130709144237.GW27646@sirena.org.uk>
Message-ID: <CACQ1gAhp97rxEgM23TvzxtFdMtrrKyqXL5eVvJbHkSE5Zq-0=A@mail.gmail.com>

2013/7/9 Mark Brown <broonie at kernel.org>:
> On Tue, Jul 09, 2013 at 04:25:26PM +0200, Richard Genoud wrote:
>> [I've just seen that I forgot to cc Uwe to the cover letter, sorry for that.]
>
> This is the second or third copy of this patch set I've been sent
> *today*.  Worse, everything seems to be being sent in reply to the same
> thread increasing the nesting substantially.  Please slow down, it's
> flooding my mailbox and discouraging me from looking since it seems
> likely that there will just be another resend.
Sorry Mark, I didn't want to be pushy...
I still need to learn what should and what shouldn't be done on a linux-ML

Best regards,
Richard.


From broonie at kernel.org  Tue Jul  9 10:55:10 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Jul 2013 15:55:10 +0100
Subject: MTD EEPROM support and driver integration
In-Reply-To: <20130708202538.GK11243@lukather>
References: <20130705201118.GM2959@lukather> <5811519.oHVuMujf0I@wuerfel>
 <20130706120112.GA11069@lukather> <8997501.Dchyii8uWX@wuerfel>
 <20130708083426.GO27646@sirena.org.uk>
 <20130708202538.GK11243@lukather>
Message-ID: <20130709145510.GZ27646@sirena.org.uk>

On Mon, Jul 08, 2013 at 10:25:38PM +0200, Maxime Ripard wrote:
> On Mon, Jul 08, 2013 at 09:34:26AM +0100, Mark Brown wrote:

> > I'd really like to see more discussion of this "DT parsing code for
> > regmap" idea...  I've missed almost all the context here.

> The context was that I found we lack a way to simply express the need
> for one driver to get a value from an EEPROM-like device, for example to
> get a MAC Address, or a serial number, in a generic way, without having
> to poke directly with some custom function that would be exported by the
> EEPROM driver.

This sort of information is often stored in places like flash partitions
too.  Are we sure that regmap is a good place to be hooking in here?
The use case is sane, and being able to use regmap to do some of it
seems sensible (I've seen people use OTP in PMICs for similar purposes)
but perhaps an additional layer of abstraction on top makes sense.

> What we've been discussing so far is that:
>   - To have a common framework we could base our work on, we could move
>     the EEPROM drivers from drivers/misc/eeprom to MTD
>   - To declare the ranges that needed to be used by a driver that was
>     needing a value from one of those MTD drivers, we would use regmap
>     with a MTD backend
>   - And since we actually need to declare which ranges and in which
>     device one driver would have to retrieve this value from, we were
>     actually in need of DT bindings.

> This is pretty much the only context involved, and we are at the early
> stage of the discussion, so any comment is very welcome :)

If this stuff is being represented in MTD doesn't MTD already have
adequate abstractions for saying "this region in flash".  But otherwise
this seems fine, it's not a generic regmap DT binding but instead rather
more specific than that.
-------------- 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/20130709/bc394b59/attachment.sig>

From broonie at kernel.org  Tue Jul  9 10:59:17 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Jul 2013 15:59:17 +0100
Subject: [PATCH v4 1/7] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <1373379933-32749-2-git-send-email-richard.genoud@gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-2-git-send-email-richard.genoud@gmail.com>
Message-ID: <20130709145917.GA27646@sirena.org.uk>

On Tue, Jul 09, 2013 at 04:25:27PM +0200, Richard Genoud wrote:

> +/*
> + * Authorized rates are:
> + * Rate = MCLK_RATE / (n * 2)
> + * Where n is in [1..4095]
> + * (cf register SSC_CMR)
> + */
> +static unsigned int rates[] = {
> +	8000,
> +	16000,
> +	32000,
> +	48000,
> +	64000,
> +	96000,
> +};

Shouldn't the SSC driver be enforcing this constraint if it comes from
the SSC hardware?  If the clock is reprogrammable the usual convention
for drivers is to not constrain if the clock is set to zero so a machine
driver could remove the constraint.

> +	ret = atmel_ssc_set_audio(0);
> +	if (ret != 0) {
> +		dev_err(&pdev->dev,
> +			"ASoC: Failed to set SSC 0 for audio: %d\n", ret);
> +		return ret;
> +	}

Shouldn't this be a parameter in the DT too?

> +	cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
> +	if (!cpu_np) {
> +		dev_err(&pdev->dev, "ssc controller node missing\n");
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	at91sam9x5ek_dai.cpu_of_node = cpu_np;
> +	at91sam9x5ek_dai.platform_of_node = cpu_np;

After all we're looking things up in the DT...

> +	at91sam9x5ek_dai.dai_fmt = snd_soc_of_parse_daifmt(np, "atmel,");

Is this really something that machines would want to reconfigure?  If so
why?
-------------- 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/20130709/8c5f9fd6/attachment.sig>

From sbabic at denx.de  Tue Jul  9 10:59:57 2013
From: sbabic at denx.de (Stefano Babic)
Date: Tue, 09 Jul 2013 16:59:57 +0200
Subject: [PATCH] ARM: dts: imx: add tempmon node for imx6q thermal support
In-Reply-To: <1370330226-6030-1-git-send-email-shawn.guo@linaro.org>
References: <1370330008-5982-1-git-send-email-shawn.guo@linaro.org>
 <1370330226-6030-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <51DC256D.6040204@denx.de>

Hi Shawn,

On 04/06/2013 09:17, Shawn Guo wrote:
> Mark ocotp as a syscon node and add tempmon for imx6q thermal support.
> 
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> ---
>  arch/arm/boot/dts/imx6qdl.dtsi |   11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index 9e8296e..13e1d7f 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -489,6 +489,13 @@
>  				};
>  			};
>  
> +			tempmon: tempmon {
> +				compatible = "fsl,imx6q-tempmon";
> +				interrupts = <0 49 0x04>;
> +				fsl,tempmon = <&anatop>;
> +				fsl,tempmon-data = <&ocotp>;
> +			};
> +
>  			usbphy1: usbphy at 020c9000 {
>  				compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy";
>  				reg = <0x020c9000 0x1000>;
> @@ -747,8 +754,8 @@
>  				interrupts = <0 14 0x04>;
>  			};
>  
> -			ocotp at 021bc000 {
> -				compatible = "fsl,imx6q-ocotp";
> +			ocotp: ocotp at 021bc000 {
> +				compatible = "fsl,imx6q-ocotp", "syscon";
>  				reg = <0x021bc000 0x4000>;

Sorry to check this very late - is ocotp at 021bc000 the right address for
the thermal data ? According to User Manual (Table 62.3), the start
address is 0x20C8180. Using your patch, by loading the driver I get :

imx_thermal tempmon.7: invalid sensor calibration data
imx_thermal tempmon.7: failed to get sensor data
imx_thermal: probe of tempmon.7 failed with error -22

The driver is loaded successfully if I changed the tempdata to point to
020C8180. Not sure if I get the right values from temp1_crit and
temp1_input, but no error at the initialisation. Am I missing something ?

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================


From shawn.guo at linaro.org  Tue Jul  9 11:02:04 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 9 Jul 2013 23:02:04 +0800
Subject: [PATCH 3/3] ARM:dts:vf610-twr:Enable DSPI0 devices and Flash
 at26df081a
In-Reply-To: <20130709144425.GX27646@sirena.org.uk>
References: <1373272622-29064-1-git-send-email-b44548@freescale.com>
 <1373272622-29064-3-git-send-email-b44548@freescale.com>
 <20130708113600.GU27646@sirena.org.uk>
 <20130709052925.GD16656@S2101-09.ap.freescale.net>
 <20130709100723.GS27646@sirena.org.uk>
 <20130709125239.GA2813@S2101-09.ap.freescale.net>
 <20130709144425.GX27646@sirena.org.uk>
Message-ID: <20130709150202.GB2813@S2101-09.ap.freescale.net>

On Tue, Jul 09, 2013 at 03:44:25PM +0100, Mark Brown wrote:
> On Tue, Jul 09, 2013 at 08:52:41PM +0800, Shawn Guo wrote:
> > On Tue, Jul 09, 2013 at 11:07:23AM +0100, Mark Brown wrote:
> 
> > > The bindings are all totally generic ones for a SPI controller, there's
> > > nothing controversial or even device specific about them so I'm happy to
> > > say the bindings are fine as-is.
> 
> > Am I missing something?  I do not even see a bindings doc in patch #1.
> > How can I think the bindings are fine?
> 
> Hrm, I was sure I was seeing one...  though in any case there's nothing
> here except for interrupt and DMA hookup so any additional properties
> aren't going to affect this patch.

You are probably talking about patch #2.  But this patch does add two
properties "spi-num-chipselects" and "bus-num".

Shawn



From broonie at kernel.org  Tue Jul  9 11:01:14 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Jul 2013 16:01:14 +0100
Subject: [PATCH v4 2/7] Documentation: DT: add sam9x5ek-wm8731 machine
 driver
In-Reply-To: <1373379933-32749-3-git-send-email-richard.genoud@gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-3-git-send-email-richard.genoud@gmail.com>
Message-ID: <20130709150114.GB27646@sirena.org.uk>

On Tue, Jul 09, 2013 at 04:25:28PM +0200, Richard Genoud wrote:
> This add the sound DT binding for sam9x5ek-wm8731 machine driver
> 
> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
> ---
>  .../bindings/sound/atmel-sam9x5-wm8731-audio.txt   |   30 ++++++++++++++++++++

Put new binding documents in the same patch that reads them, this makes
review easier.

> +  - atmel,audio-routing: A list of the connections between audio components.

This needs to be more specific and list the available board specific
nodes for routing.  For the CODEC you can just refer to the CODEC
binding documentation.

> +  - atmel,format: DAI format. Must be "i2s"

So why not just omit this then?

> +  - atmel,bitclock-master:  DAI clock master
> +  - atmel,frame-master: DAI frame master

The driver isn't handling these and there's no information on how to set
them.
-------------- 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/20130709/dcbf9701/attachment.sig>

From sergei.shtylyov at cogentembedded.com  Tue Jul  9 11:01:23 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 09 Jul 2013 19:01:23 +0400
Subject: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node
In-Reply-To: <51DC1937.9080302@cogentembedded.com>
References: <1373361446-30050-1-git-send-email-george.cherian@ti.com>
 <51DC1937.9080302@cogentembedded.com>
Message-ID: <51DC25C3.6000901@cogentembedded.com>

Hello.

On 07/09/2013 06:07 PM, Sergei Shtylyov wrote:

>> Adds device node for HS USB Host module for AM437x

>> changes from v1

>> renamed synopsis to snps
>> removed flag tx-fifo-resize

>> Signed-off-by: George Cherian <george.cherian at ti.com>
>> ---
>>   arch/arm/boot/dts/am4372.dtsi | 18 ++++++++++++++++++
>>   1 file changed, 18 insertions(+)

>> diff --git a/arch/arm/boot/dts/am4372.dtsi
>> b/arch/arm/boot/dts/am4372.dtsi
>> index ddc1df7..c9e0da8 100644
>> --- a/arch/arm/boot/dts/am4372.dtsi
>> +++ b/arch/arm/boot/dts/am4372.dtsi
>> @@ -64,5 +64,23 @@
>>               compatible = "ti,am4372-counter32k","ti,omap-counter32k";
>>               reg = <0x44e86000 0x40>;
>>           };
>> +
>> +        usb_otg_hs1: am4372_dwc3 at 48380000 {
>
>     See http://www.devicetree.org/Device_Tree_Usage, "Node Names" section.
>
>> +            compatible = "ti,am437x-dwc3";
>> +            reg = <0x48380000 0x1ff>;

    And I bet this should be 0x200, not 0x1ff. This is length, not upper 
limit.

>> +            interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
>> +            #address-cells = <1>;
>> +            #size-cells = <1>;
>> +            utmi-mode = <1>;
>> +            ranges;
>> +
>> +            dwc3 at 48390000 {

>     The same comment.

>> +                compatible = "snps,dwc3";
>> +                reg = <0x48390000 0xcfff>;

    The same, this should be 0xd000, not 0xcfff.

>> +                interrupts = <GIC_SPI  168 IRQ_TYPE_LEVEL_HIGH>;
>> +            };
>> +
>> +        };
>> +

WBR, Sergei




From broonie at kernel.org  Tue Jul  9 11:02:42 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Jul 2013 16:02:42 +0100
Subject: [PATCH 1/3] spi:Add Freescale DSPI driver for Vybrid VF610
 platform
In-Reply-To: <1373272622-29064-1-git-send-email-b44548@freescale.com>
References: <1373272622-29064-1-git-send-email-b44548@freescale.com>
Message-ID: <20130709150242.GC27646@sirena.org.uk>

On Mon, Jul 08, 2013 at 04:37:00PM +0800, Chao Fu wrote:

>  drivers/spi/Kconfig        |   6 +
>  drivers/spi/Makefile       |   1 +
>  drivers/spi/spi-fsl-dspi.c | 675 +++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 682 insertions(+)

There is no binding documentation here.  Binding documentation is
mandatory for any new bindings.
-------------- 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/20130709/46480b04/attachment.sig>

From broonie at kernel.org  Tue Jul  9 11:05:43 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Jul 2013 16:05:43 +0100
Subject: [PATCH v4 3/7] Documentation: DT: update atmel SSC with DMA
 binding
In-Reply-To: <1373379933-32749-4-git-send-email-richard.genoud@gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-4-git-send-email-richard.genoud@gmail.com>
Message-ID: <20130709150543.GE27646@sirena.org.uk>

On Tue, Jul 09, 2013 at 04:25:29PM +0200, Richard Genoud wrote:

>  - reg: Should contain SSC registers location and length
>  - interrupts: Should contain SSC interrupt
> +For dma transfer:
> +- dmas: DMA specifier, consisting of a phandle to DMA controller node,
> +  the memory interface and SSC DMA channel ID (for tx and rx).
> +  See Documentation/devicetree/bindings/dma/atmel-dma.txt for details.
> +- dma-names: Must be "tx", "rx".

This is added as a required property so...

> -Example:
> +Examples:
>  ssc0: ssc at fffbc000 {
>  	compatible = "atmel,at91rm9200-ssc";
>  	reg = <0xfffbc000 0x4000>;
>  	interrupts = <14 4 5>;
>  };

...this first example is now invalid and should probably just be being
extended with the new required properties.
-------------- 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/20130709/614c2105/attachment.sig>

From marex at denx.de  Tue Jul  9 11:07:03 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 9 Jul 2013 17:07:03 +0200
Subject: Chipidea usb otg support for IMX/MXS (device functionality)
In-Reply-To: <F281D0F91ED19E4D8E63A7504E8A649803EFB072@039-SN2MPN1-023.039d.mgd.msft.net>
References: <51A5A808.2070803@digi.com> <201306221529.53043.marex@denx.de>
 <F281D0F91ED19E4D8E63A7504E8A649803EFB072@039-SN2MPN1-023.039d.mgd.msft.net>
Message-ID: <201307091707.03749.marex@denx.de>

Hi Peter,

> > Hi Peter,
> > 
> > > > Peter, I dunno if you are already aware of it, but the USB peripheral
> > > > mode hangs
> > > > on MX233. It's easy to replicate for example if you try to run CDC
> > > > ethernet over
> > > > the USB peripheral mode, then telnet into the board and run "dmesg" .
> > > > This will
> > > > trigger a "larger" data transfer which will make the UDC driver hang.
> > > > This
> > > > doesn't happen on MX28 so it must be some MX233-specific thing.
> > > 
> > > Marek, Have you tried below?
> > > 
> > > http://marc.info/?l=linux-usb&m=136537318510847&w=2
> > > 
> > > It may not the USB itself problem, the mx23's usb is almost
> > > the same with mx28's.
> > 
> > This also happens on a different MX23-based board for me. This other
> > board I
> > tried has mDDR DRAM and the DRAM is operating correctly. The 96MHz thing
> > people
> > complained about in the Olimex forum is resolved now.
> 
> Add shawn.
> 
> Marek, have you tried mx23 evk?

Ok, I just tried the MX23EVK. Running "dmesg" via telnet connection resulted in 
a hang of the USB driver (likely), but since I have serial connection to the 
board, I was able to verify the board itself didn't crash. I can still operate 
the board via serial console, it's only the USB in peripheral mode ethernet that 
is hung.

> Shawn, marek reported the udc function at mx23 works abnormal, but it works
> good at mx28. Have you tried mx23 udc recently?
> 
> Best regards,
> Peter

Best regards,
Marek Vasut


From broonie at kernel.org  Tue Jul  9 11:29:54 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Jul 2013 16:29:54 +0100
Subject: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to
 control PMIC over VC/VP
In-Reply-To: <51DAF55C.5040502@ti.com>
References: <1371849949-12649-1-git-send-email-nm@ti.com>
 <1371849949-12649-2-git-send-email-nm@ti.com>
 <20130704154105.GD27646@sirena.org.uk>
 <20130705135507.GA17439@kahuna>
 <20130705140828.GA27646@sirena.org.uk> <51D6DD3A.1030002@ti.com>
 <20130705165235.GC27646@sirena.org.uk> <51D70356.30707@ti.com>
 <20130705174727.GF27646@sirena.org.uk> <51DAF55C.5040502@ti.com>
Message-ID: <20130709152954.GF27646@sirena.org.uk>

On Mon, Jul 08, 2013 at 12:22:36PM -0500, Nishanth Menon wrote:

> case #1 - TPS62361 has a single SMPS and a single generic i2c bus,
> one can talk on. In this case, you'd associate the regulator device
> in one place - i2cX or on custom SoC hardware interface.

> When used with custom SoC hardware interface, generic tps62361
> regulator which talks regular i2c wont even probe for omap_pmic to
> get the regulator data from tps62361 regulator driver. Even if we
> were to define the generic TPS62361 in dts nodes, it will fail probe
> as it cant access any of it's registers using generic i2c.

This seems like something we should be able to cope with by for example
adding a bus for the custom PMIC interface or otherwise finding a way to
get to the data at runtime based on the compatible string.  This would
need some custom code in the regulators but would have the advantage of
keeping the data the same at least.  Hrm.

> >Another option is for the drivers to provide the data and use the
> >helpers for their linear ranges as part of a more complex
> >implementation.

> Having looked at a few regulator driver implementations, there seems
> to be the following combinations:
> a) drivers which have n ranges of linear voltages for incremental selector
> b) drivers with 1 range of linear voltages only for all ranges of selectors
> c) drivers with 1 range of linear voltages and nonlinear voltage
> values for other vsels.

Everything else is just a special case of option a - either there's just
a single range or there's a bunch of ranges each with a single value.  I
suspect that ranges will be the most useful thing for any hardware which
can practically be used by these regulators anyway.

> >OK, that's a bit more fun but I think the kernel wants that information
> >in general anyway since a software cpufreq driver or something might
> >want to make the same latency decisions.  This is what set_voltage_time()
> >is for in part.  But to a first approximation is there really much
> >variation in the numbers?

> between PMICs? yep, twl4030 does 4mV/uSec, 6030 can do 6mV/uSec,
> TPS62361 can do 32mV/uSec, TWL6035/37 does 0.220mV/uSec

Those are ramp rates, they're not I2C I/O limits.  Ramp rates we already
know about.  I think what you're saying here is that this latency value
is actually about worst case ramp times?
-------------- 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/20130709/3dbf5b82/attachment.sig>

From thomas.petazzoni at free-electrons.com  Tue Jul  9 11:36:06 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 9 Jul 2013 17:36:06 +0200
Subject: v3.10 - big endian core support
In-Reply-To: <20130708170352.GA24361@mudshark.cambridge.arm.com>
References: <1372676648-9254-1-git-send-email-ben.dooks@codethink.co.uk>
 <51DA5089.5080109@gmail.com>
 <20130708084911.GA22057@mudshark.cambridge.arm.com>
 <51DA8BBF.7080104@gmail.com>
 <20130708110202.GD22057@mudshark.cambridge.arm.com>
 <20130708170352.GA24361@mudshark.cambridge.arm.com>
Message-ID: <20130709173606.488fe85b@skate>

Dear Will Deacon,

On Mon, 8 Jul 2013 18:03:53 +0100, Will Deacon wrote:
> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
> > On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
> > > The printascii can output before "b __enable_mmu", after move it to
> > > __mmap_switched, nothing can be printed. But if disable LPAE, printascii
> > > works again in __mmap_switched.
> > 
> > Ok, so the page tables are broken. The code is there to swap the two words,
> > but perhaps something ends up being off-by-4 or the like. I'll try and take
> > a look.
> 
> Right, I managed to have a quick play with a 3.10 kernel and the good news
> is that the page tables are fine. The bad part is that using
> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the FDT
> results in a NULL command line, so I don't see any output. If I hardcode the
> command line in the kernel image, things work fine.

Ben Dooks has a separate branch on top of this base branch for
big-endian support, that adds atags compat code to convert the ATAGs
data from LE to BE. See the baserock/311/be/atags branch in
git://git.baserock.org/delta/linux. Or
http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From sboyd at codeaurora.org  Tue Jul  9 11:36:57 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue,  9 Jul 2013 08:36:57 -0700
Subject: [PATCH] ARM: Fix deadlock scenario with smp_send_stop()
Message-ID: <1373384217-26307-1-git-send-email-sboyd@codeaurora.org>

If one process calls sys_reboot and that process then stops other
CPUs while those CPUs are within a spin_lock() region we can
potentially encounter a deadlock scenario like below.

CPU 0                   CPU 1
-----                   -----
                        spin_lock(my_lock)
smp_send_stop()
 <send IPI>             handle_IPI()
                         disable_preemption/irqs
                          while(1);
 <PREEMPT>
spin_lock(my_lock) <--- Waits forever

We shouldn't attempt to run any other tasks after we send a stop
IPI to a CPU so disable preemption so that this task runs to
completion.

Reported-by: Sundarajan Srinivasan <sundaraj at codeaurora.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---

Resending this patch now that the context has changed.

 arch/arm/kernel/process.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 7f1efcd..8bc12d7 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -206,6 +206,7 @@ void machine_shutdown(void)
  */
 void machine_halt(void)
 {
+	preempt_disable();
 	smp_send_stop();
 
 	local_irq_disable();
@@ -220,6 +221,7 @@ void machine_halt(void)
  */
 void machine_power_off(void)
 {
+	preempt_disable();
 	smp_send_stop();
 
 	if (pm_power_off)
@@ -239,6 +241,7 @@ void machine_power_off(void)
  */
 void machine_restart(char *cmd)
 {
+	preempt_disable();
 	smp_send_stop();
 
 	arm_pm_restart(reboot_mode, cmd);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From thomas.petazzoni at free-electrons.com  Tue Jul  9 11:45:53 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 9 Jul 2013 17:45:53 +0200
Subject: Analysis of Cortex-A9 r4 erratas
Message-ID: <20130709174553.426dfaa1@skate>

Will, Catalin, Russell,

As Marvell is starting to run Linux on their latest Cortex-A9 based
SoC
(http://www.marvell.com/company/news/pressDetail.do?releaseID=4038), we
are having a look at the list of erratas affecting the Cortex-A9 r4
core, and see which ones have been fixed in the kernel, which ones
don't need to be fixed, and which ones should maybe have a fix, but
don't have one at this point.

I've listed below all the erratas affecting the Cortex-A9 r4, as of
"ARM UAN 0009B", together with a short analysis from me (which may very
well be wrong). After doing this analysis, I'm mostly concerned by the
following erratas, about which I'd appreciate to have your opinion:

 * 761319 Possible inconsistent sequencing of read accesses to the same
   memory location

 * 794072 A short loop including a DMB instruction might cause a denial
   of service on another processor which executes a CP15 broadcast
   operation

 * 794074 A write request to Uncacheable, Shareable normal memory
   region might be executed twice, possibly causing a software
   synchronisation issue

 * 754323 Repeated Store in the same cache line might delay the
   visibility of the Store.

All the other erratas seem to be either fixed, or not have any
consequence on the normal operation of the kernel, but I'm also
interested in your opinion about this.

Thanks!

Thomas

Complete list of erratas, with my (stupid?) comments

Category A

761319 Title:  Possible inconsistent sequencing of read accesses to the
               same memory location
       Status: Should be handled at the toolchain level, not the
       	       kernel, except in assembly code. Not sure if gcc has
       	       been patched to fix the issue.

Category B

740657 Title:  Global Timer can send two interrupts for the same event
       Status: No driver in mainline for the A9 global timer, but the
               proposed patch '[PATCH v3 02/10]
               clocksource:arm_global_timer: Add ARM global timer
               support.' takes care of this errata.

751476 Title:  Missed watchpoint on the second part of an unaligned
               access crossing a page boundary
       Status: Only related to debugging/watchpoint, not affecting
               normal kernel code.

754322 Title:  Faulty MMU translations following ASID switch
       Status: Handled in the kernel, ARM_ERRATA_754322

764369 Title:  Data or unified cache line maintenance by MVA fails on
       	       Inner Shareable memory
       Status: Handled in the kernel, ARM_ERRATA_764369

794072 Title:  A short loop including a DMB instruction might cause a
       	       denial of service on another processor which executes a
       	       CP15 broadcast operation
       Status: Not sure. Can this denial of service be trigerred from
               userspace?

794073 Title:  Speculative instruction fetches with MMU disabled might
       	       not comply with architectural requirements
       Status: Problem happens only when the MMU has been enabled,
               gets disabled, and the branch prediction array has some
               entries. Within the context of Linux, the MMU is only
               turned on, never turned back off. Bootloaders may turn
               on and then off the MMU before entering Linux, so it
               would be the bootloader's job of implementing the
               proposed workaround.

794074 Title:  A write request to Uncacheable, Shareable normal memory
       	       region might be executed twice, possibly causing a
       	       software synchronisation issue
       Status: Not sure.

Category C

725631 Title:  ISB is counted in Performance Monitor events 0x0C and 0x0D
       Status: Only affects performance counters, not critical for
               normal system operation.

729817 Title:  Main ID register alias addresses are not mapped on Debug
       	       APB interface
       Status: Only affects the APB debug interface, not critical for
               normal system operation.


729818 Title:  In debug state, next instruction is stalled when SDABORT
       	       flag is set, instead of being discarded

       Status: Only affects DCC stall mode, use for debugging only,
               not critical for normal system operation.

751471 Title:  DBGPCSR format is incorrect
       Status: Only affects the DBGPCSR, used by debugger tools, not
       	       critical for normal system operation.

752519 Title:  An imprecise abort might be reported twice on non-cacheable reads
       Status: Only happens when an imprecise abort is trigerred,
               which is by itself already a sign of something's going
               really wrong in the system, so having a second
               imprecise abort reported is not going to have any major
               consequence, as the system has most likely already been
               halted due to the first imprecise abort.

754323 Title:  Repeated Store in the same cache line might delay the
       	       visibility of the Store
       Status: Not sure.

756421 Title:  Sticky Pipeline Advance bit cannot be cleared from debug
       	       APB accesses
       Status: APB related, access to debugging specific registers,
       	       not affecting normal system operation.

757119 Title:  Some Unallocated memory hint instructions generate an
       	       Undefined Instruction exception instead of being
       	       treated as NOP
       Status: Compiler-related, not kernel-related, and affected
               instructions are unlikely to be generated by compilers.

761321 Title:  MRC and MCR are not counted in event 0x68
       Status: Performance counters related, not affecting normal
               system operation, only incorrect statistics.

764319 Title:  Read accesses to DBGPRSR and DBGOSLSR may generate an
       	       unexpected Undefined Instruction exception
       Status: As stated in the erratum, "This is unlikely to cause
       	       any significant issue in Cortex-A9 based systems
       	       because these accesses are mainly intended to be used
       	       as part of debug over powerdown sequences, and the
       	       Cortex-A9 does not support this feature."

771224 Title:  Visibility of Debug Enable access rights to
       	       enable/disable tracing is not ensured by an ISB
       Status: Related to debugging features only, not affecting
               normal system operation.

775419 Title:  PMU event 0x0A (exception return) might count twice the
       	       LDM PC ^ instructions with base address register
       	       write-back
       Status: Performance counters related, not affecting normal
               system operation, only incorrect statistics.

-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From swarren at wwwdotorg.org  Tue Jul  9 12:03:15 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 09 Jul 2013 10:03:15 -0600
Subject: [PATCH] ARM: mm: restrict early_alloc_aligned to legal area
In-Reply-To: <1373323495-10087-1-git-send-email-swarren@wwwdotorg.org>
References: <1373323495-10087-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <51DC3443.3060408@wwwdotorg.org>

On 07/08/2013 04:44 PM, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> When early_alloc_aligned() is called, it appears that only memory in the
> first memory bank is mapped for CPU access. However, memblock_alloc() is
> called to allocate the RAM, and that can return RAM that is part of any
> valid memory bank, which hence could be inaccessible to the CPU. If this
> happens, the subsequent memset() will hang or crash.
> 
> Solve this by calling memblock_alloc_base() instead of memblock_alloc().
> This function takes an explicit max address. Use the end of the first
> memory bank as the address.

Scratch this; it causes problems on systems with highmem.

> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c

>  static void __init *early_alloc_aligned(unsigned long sz, unsigned long align)
>  {
> -	void *ptr = __va(memblock_alloc(sz, align));
> +	phys_addr_t max_pa = memblock.memory.regions[0].base +
> +				memblock.memory.regions[0].size;

Perhaps that needs to be min(memblock 0 end, end of lowmem). I'll try
that...


From nm at ti.com  Tue Jul  9 12:04:23 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 9 Jul 2013 11:04:23 -0500
Subject: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control
 PMIC over VC/VP
In-Reply-To: <20130709152954.GF27646@sirena.org.uk>
References: <1371849949-12649-1-git-send-email-nm@ti.com>
 <1371849949-12649-2-git-send-email-nm@ti.com>
 <20130704154105.GD27646@sirena.org.uk> <20130705135507.GA17439@kahuna>
 <20130705140828.GA27646@sirena.org.uk> <51D6DD3A.1030002@ti.com>
 <20130705165235.GC27646@sirena.org.uk> <51D70356.30707@ti.com>
 <20130705174727.GF27646@sirena.org.uk> <51DAF55C.5040502@ti.com>
 <20130709152954.GF27646@sirena.org.uk>
Message-ID: <51DC3487.2080503@ti.com>

On 07/09/2013 10:29 AM, Mark Brown wrote:
> On Mon, Jul 08, 2013 at 12:22:36PM -0500, Nishanth Menon wrote:
>
>> case #1 - TPS62361 has a single SMPS and a single generic i2c bus,
>> one can talk on. In this case, you'd associate the regulator device
>> in one place - i2cX or on custom SoC hardware interface.
>
>> When used with custom SoC hardware interface, generic tps62361
>> regulator which talks regular i2c wont even probe for omap_pmic to
>> get the regulator data from tps62361 regulator driver. Even if we
>> were to define the generic TPS62361 in dts nodes, it will fail probe
>> as it cant access any of it's registers using generic i2c.
>
> This seems like something we should be able to cope with by for example
> adding a bus for the custom PMIC interface or otherwise finding a way to

I had considered introducing a custom bus for custom PMIC interface, but 
as you stated below, standard regulators will probably need some custom 
monkeying around.

> get to the data at runtime based on the compatible string.  This would
> need some custom code in the regulators but would have the advantage of
> keeping the data the same at least.  Hrm.

Ofcourse,this will be to add custom set/get_voltage implementation using 
this "custom API" which we discussed was'nt that good an idea.

I am at a stalemate as to where we should go from here.

>
>>> Another option is for the drivers to provide the data and use the
>>> helpers for their linear ranges as part of a more complex
>>> implementation.
>
>> Having looked at a few regulator driver implementations, there seems
>> to be the following combinations:
>> a) drivers which have n ranges of linear voltages for incremental selector
>> b) drivers with 1 range of linear voltages only for all ranges of selectors
>> c) drivers with 1 range of linear voltages and nonlinear voltage
>> values for other vsels.
>
> Everything else is just a special case of option a - either there's just
> a single range or there's a bunch of ranges each with a single value.  I
> suspect that ranges will be the most useful thing for any hardware which
> can practically be used by these regulators anyway.

True, but slightly different topic though.

>
>>> OK, that's a bit more fun but I think the kernel wants that information
>>> in general anyway since a software cpufreq driver or something might
>>> want to make the same latency decisions.  This is what set_voltage_time()
>>> is for in part.  But to a first approximation is there really much
>>> variation in the numbers?
>
>> between PMICs? yep, twl4030 does 4mV/uSec, 6030 can do 6mV/uSec,
>> TPS62361 can do 32mV/uSec, TWL6035/37 does 0.220mV/uSec
>
> Those are ramp rates, they're not I2C I/O limits.  Ramp rates we already
> know about.  I think what you're saying here is that this latency value
> is actually about worst case ramp times?
Arrgh.. my bad. I confused ramp time with I2C transfer timeout 
parameter. I know that I2C bus can be held[1] by PMIC as long as it is 
busy. Some custom ASIC can do some weird stuff I suppose. I dont seem to 
have clear data points in the sketchy TRMs for 6030/2 , 6035, 5030, for 
these other than to state it is i2c specification compliant (/me 
grumbles). So, I just have emperical value which is a bit conservative 
and seem to work on the devices.


[1] http://www.i2c-bus.org/clock-generation-stretching-arbitration/
-- 
Regards,
Nishanth Menon


From swarren at wwwdotorg.org  Tue Jul  9 12:05:01 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 09 Jul 2013 10:05:01 -0600
Subject: CPU hotplug issue w/ 0647065 clocksource: Add generic dummy timer
 driver
In-Reply-To: <20130709005837.GC830@codeaurora.org>
References: <51DAF895.1020700@wwwdotorg.org>
 <20130709005837.GC830@codeaurora.org>
Message-ID: <51DC34AD.30009@wwwdotorg.org>

On 07/08/2013 06:58 PM, Stephen Boyd wrote:
> On 07/08, Stephen Warren wrote:
>> CPU hotplug (replug) on Tegra HW seems to be occasionally broken due to
>> commit 0647065 "clocksource: Add generic dummy timer driver" in
>> linux-next. Reverting that commit solves the issue.
> 
> We found some breakage during boot that has been fixed by two
> commits in linus' tree already. Do you know if you have these two
> patches
> 
> 1f73a9806bdd07a5106409bbcab3884078bd34fe
> 07bd1172902e782f288e4d44b1fde7dec0f08b6f

I didn't before since I was using next-20130705, but I just tried
next-20130709 which does have those two commits, and I still see the issue.



From nicolas.ferre at atmel.com  Tue Jul  9 12:07:28 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 9 Jul 2013 18:07:28 +0200
Subject: [PATCH 1/7] serial: at91: correct definition from DMA to PDC
In-Reply-To: <1373351626-30143-2-git-send-email-elen.song@atmel.com>
References: <1373351626-30143-1-git-send-email-elen.song@atmel.com>
 <1373351626-30143-2-git-send-email-elen.song@atmel.com>
Message-ID: <51DC3540.5010902@atmel.com>

One little comment.

On 09/07/2013 08:33, Elen Song :

[..]

> @@ -19,9 +19,9 @@ Example:
>
>   	usart0: serial at fff8c000 {
>   		compatible = "atmel,at91sam9260-usart";
> -		reg = <0xfff8c000 0x4000>;
> -		interrupts = <7>;
> -		atmel,use-dma-rx;
> -		atmel,use-dma-tx;
> +		reg = <0xfff8c000 0x200>;
> +		interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;

This is not related to this patch topic: please remove.

> +		atmel,use-pdc-rx;
> +		atmel,use-pdc-tx;
>   	};

[..]

-- 
Nicolas Ferre


From thomas.petazzoni at free-electrons.com  Tue Jul  9 12:14:34 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 9 Jul 2013 18:14:34 +0200
Subject: [PATCH V3 2/3] clocksource: mmp: support CLOCKSOURCE OF DECLARE
In-Reply-To: <1373352166-10064-3-git-send-email-zhangwm@marvell.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-3-git-send-email-zhangwm@marvell.com>
Message-ID: <20130709181434.76f6216d@skate>

Dear Neil Zhang,

On Tue, 9 Jul 2013 14:42:45 +0800, Neil Zhang wrote:
> support CLOCKSOURCE OF DECLARE for mmp timer.
> 
> Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> ---
>  arch/arm/mach-mmp/mmp-dt.c  |    5 ++---
>  arch/arm/mach-mmp/mmp2-dt.c |    3 +--
>  arch/arm/mach-mmp/time.c    |   15 ++-------------
>  3 files changed, 5 insertions(+), 18 deletions(-)

Maybe it would be good to take this opportunity to move
arch/arm/mach-mmp/time.c into drivers/clocksource/.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From Dave.Martin at arm.com  Tue Jul  9 12:29:56 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Tue, 9 Jul 2013 17:29:56 +0100
Subject: [PATCH 1/3] arm: hyp: fix macro parameterisation
In-Reply-To: <1373379366-15689-2-git-send-email-mark.rutland@arm.com>
References: <1373379366-15689-1-git-send-email-mark.rutland@arm.com>
 <1373379366-15689-2-git-send-email-mark.rutland@arm.com>
Message-ID: <20130709162956.GB2911@localhost.localdomain>

On Tue, Jul 09, 2013 at 03:16:04PM +0100, Mark Rutland wrote:
> Currently, compare_cpu_mode_with_primary uses a mixture of macro
> arguments and hardcoded registers, and does so incorrectly, as it
> stores (__boot_cpu_mode_offset | BOOT_CPU_MODE_MISMATCH) to
> (__boot_cpu_mode + &__boot_cpu_mode_offset), which could corrupt an
> arbitrary portion of memory.
> 
> This patch fixes up compare_cpu_mode_with_primary to use the macro
> arguments, correctly updating __boot_cpu_mode.
> 
> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> Cc: Dave Martin <dave.martin at arm.com>
> Cc: Marc Zyngier <marc.zyngier at arm.com>
> Cc: Christoffer Dall <cdall at cs.columbia.edu>

May bad originally my the looks of it.  Thanks for spotting this.

Acked-by: Dave Martin <Dave.Martin at arm.com>

> ---
>  arch/arm/kernel/hyp-stub.S | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
> index 1315c4c..bda76ce 100644
> --- a/arch/arm/kernel/hyp-stub.S
> +++ b/arch/arm/kernel/hyp-stub.S
> @@ -56,8 +56,8 @@ ENTRY(__boot_cpu_mode)
>  	ldr	\reg3, [\reg2]
>  	ldr	\reg1, [\reg2, \reg3]
>  	cmp	\mode, \reg1		@ matches primary CPU boot mode?
> -	orrne	r7, r7, #BOOT_CPU_MODE_MISMATCH
> -	strne	r7, [r5, r6]		@ record what happened and give up
> +	orrne	\reg1, \reg1, #BOOT_CPU_MODE_MISMATCH
> +	strne	\reg1, [\reg2, \reg3]	@ record what happened and give up
>  	.endm
>  
>  #else	/* ZIMAGE */
> -- 
> 1.8.1.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From bhelgaas at google.com  Tue Jul  9 12:30:42 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Tue, 9 Jul 2013 10:30:42 -0600
Subject: [PATCHv4 05/11] of: pci: add registry of MSI chips
In-Reply-To: <20130709160132.7f5e7a8e@skate>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAL_Jsq+h=y5SNo4qO5-5u_w8rW++9MKDZK8rASNjhtVcjh-iyQ@mail.gmail.com>
 <20130709160132.7f5e7a8e@skate>
Message-ID: <CAErSpo6cnHbE3RSu8HFn09SY66tOZZG95JEvKFmzHieXYV0NYg@mail.gmail.com>

On Tue, Jul 9, 2013 at 8:01 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> On Tue, 9 Jul 2013 08:43:36 -0500, Rob Herring wrote:
>> > +{
>> > +       struct msi_chip *c;
>> > +       list_for_each_entry(c, &msi_chip_list, list) {
>>
>> Need the safe variant here?
>
> As suggested by Bjorn, I've changed this function to grab the
> msi_chip_mutex while traversing the list.

The "safe" list functions don't do any mutual exclusion.  The only
safety they provide is that we won't go in the weeds if the body of
the loop deletes the current list entry.  This loop doesn't delete
entries, so we don't need the safe variant.

Bjorn


From Dave.Martin at arm.com  Tue Jul  9 12:32:18 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Tue, 9 Jul 2013 17:32:18 +0100
Subject: [PATCH 2/3] arm: virt: ensure visibility of __boot_cpu_mode
In-Reply-To: <1373379366-15689-3-git-send-email-mark.rutland@arm.com>
References: <1373379366-15689-1-git-send-email-mark.rutland@arm.com>
 <1373379366-15689-3-git-send-email-mark.rutland@arm.com>
Message-ID: <20130709163217.GC2911@localhost.localdomain>

On Tue, Jul 09, 2013 at 03:16:05PM +0100, Mark Rutland wrote:
> Secondary CPUs write to __boot_cpu_mode with caches disabled, and thus a
> cached value of __boot_cpu_mode may be incoherent with that in memory.
> This could lead to a failure to detect mismatched boot modes.
> 
> This patch adds flushing to ensure that writes by secondaries to
> __boot_cpu_mode are made visible before we test against it.
> 
> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> Cc: Dave Martin <dave.martin at arm.com>
> Cc: Marc Zyngier <marc.zyngier at arm.com>
> Cc: Christoffer Dall <cdall at cs.columbia.edu>

Acked-by: Dave Martin <Dave.Martin at arm.com>

> ---
>  arch/arm/include/asm/virt.h | 12 ++++++++++++
>  arch/arm/kernel/setup.c     |  2 ++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
> index 50af92b..4371f45 100644
> --- a/arch/arm/include/asm/virt.h
> +++ b/arch/arm/include/asm/virt.h
> @@ -29,6 +29,7 @@
>  #define BOOT_CPU_MODE_MISMATCH	PSR_N_BIT
>  
>  #ifndef __ASSEMBLY__
> +#include <asm/cacheflush.h>
>  
>  #ifdef CONFIG_ARM_VIRT_EXT
>  /*
> @@ -41,10 +42,21 @@
>   */
>  extern int __boot_cpu_mode;
>  
> +static inline void sync_boot_mode(void)
> +{
> +	/*
> +	 * As secondaries write to __boot_cpu_mode with caches disabled, we
> +	 * must flush the corresponding cache entries to ensure the visibility
> +	 * of their writes.
> +	 */
> +	sync_cache_r(&__boot_cpu_mode);
> +}
> +
>  void __hyp_set_vectors(unsigned long phys_vector_base);
>  unsigned long __hyp_get_vectors(void);
>  #else
>  #define __boot_cpu_mode	(SVC_MODE)
> +#define sync_boot_mode()
>  #endif
>  
>  #ifndef ZIMAGE
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index b4b1d39..4af9b38 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -744,6 +744,8 @@ static int __init meminfo_cmp(const void *_a, const void *_b)
>  void __init hyp_mode_check(void)
>  {
>  #ifdef CONFIG_ARM_VIRT_EXT
> +	sync_boot_mode();
> +
>  	if (is_hyp_mode_available()) {
>  		pr_info("CPU: All CPU(s) started in HYP mode.\n");
>  		pr_info("CPU: Virtualization extensions available.\n");
> -- 
> 1.8.1.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From bhelgaas at google.com  Tue Jul  9 12:34:08 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Tue, 9 Jul 2013 10:34:08 -0600
Subject: [PATCHv4 04/11] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <20130708165149.55499b8e@skate>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-5-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAErSpo4aodspFnC0uR87yYAgswQQdmU48uoX5NA43UZjbCpOuw@mail.gmail.com>
 <20130708165149.55499b8e@skate>
Message-ID: <CAErSpo6rDAdN4UVReYx7EAXuOtFutyPK-gT2Vd4j2OGEUCzNsQ@mail.gmail.com>

On Mon, Jul 8, 2013 at 8:51 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Dear Bjorn Helgaas,
>
> On Fri, 5 Jul 2013 15:51:10 -0600, Bjorn Helgaas wrote:
>
>> >  int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
>> >  {
>> > +       struct msi_chip *chip = dev->bus->msi;
>> > +
>> > +       if (chip && chip->setup_irq) {
>> > +               int err;
>> > +
>> > +               err = chip->setup_irq(chip, dev, desc);
>> > +               if (err < 0)
>> > +                       return err;
>> > +
>> > +               irq_set_chip_data(desc->irq, chip);
>> > +               return err;
>> > +       }
>> > +
>> >         return -EINVAL;
>>
>> It's sub-optimal to indent the whole body of a function like this.  I
>> think this is a bit more readable:
>>
>>     if (!chip || !chip->setup_irq)
>>         return -EINVAL
>>
>>     err = chip->setup_irq(...);
>>     ...
>>     return err;
>>
>> The return value of ->setup_irq() (and hence of arch_setup_msi_irq())
>> is a bit unclear.  Apparently it can return negative values (errors)
>> or positive values (not sure what they mean), or zero (again, not
>> sure).  A comment would clear this up.
>
> I've changed ->setup_irq() to simply return 0 on success, and a
> negative error code on failure.

Perfect.

> Apparently, according to the default implementation
> of arch_msi_setup_irqs(), the arch_msi_setup_irq() hook is supposed to
> return:
>  * A negative value on error, the value being an error code that is
>    propagated to the caller.
>  * A positive value on some other errors, in which case the -ENOSPC
>    error value is returned. To me, it doesn't make a lot of sense, as
>    arch_msi_setup_irq() could just as well return -ENOSPC directly.
>  * A 0 value on success.
>
>> It might even be worth introducing a no-op chip with pointers to no-op
>> functions so we don't have to do these checks ("if (chip &&
>> chip->xxx)" everywhere.  I'm not sure if there's a Linux consensus on
>> that -- certainly there are many examples of code that *does* make
>> these checks everywhere -- so I'll ack it either way.
>
> The problem with this is that I'm not sure where in the PCI code this
> association to the default implementation should be done. And there are
> also two levels to take into account here:
>
>  * The PCI driver may not specify any msi_chip structure for a
>    particular pci_bus. This would have to be detected by the PCI core
>    when the bus is registered, and bus->msi would be set to the special
>    no-op msi_chip.
>
>  * The PCI driver may specify an msi_chip structure, but without
>    necessarily implementation all the methods. This could be solved by
>    offering a pci_msi_chip_assign(struct pci_bus *, struct msi_chip *)
>    function to be used by PCI drivers to assign their msi_chip to a
>    given pci_bus, and this function would fill in the missing msi_chip
>    operations with the default implementation.
>
> I am not sure it is really worth doing at this point, but I'm open to
> suggestions on this.

Sounds like it's not worth doing.  Thanks for checking into it.

>> >  int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
>> >  {
>> > +       struct msi_chip *chip = dev->bus->msi;
>> > +
>> > +       if (chip && chip->check_device)
>> > +               return chip->check_device(chip, dev, nvec, type);
>> > +
>>
>> These functions are poorly named.  They give no clue what
>> "check_device" means.  Are we checking that it exists, that it
>> supports some property, that it's enabled, ... ?
>
> Well the naming clearly doesn't come from this commit. The
> arch_msi_check_device() hook was around before this commit, and the
> reason the operation is named ->check_device() is just because it used
> the same terminology as the existing arch_msi_check_device() call.
>
> This hook is only used in one place, the PowerPC architecture, in
> arch/powerpc/kernel/msi.c, to actually check whether the given device
> supports MSI.
>
> I can rename if to arch_msi_device_supports_msi() and
> ->device_supports_msi(), or arch_msi_device_has_msi() and
> ->device_has_msi(), but that a change that relatively unrelated to this
> commit, I'd say.
>
> Here as well, I'm open to suggestions,

You're right, you didn't make that mess, so I guess it's OK if you
don't clean it up here.  I spent a fair amount of time yesterday
analyzing the return values, and lost interest before all became
clear.  So I stand by my assertion that it is hard to read, but I'm OK
with leaving it as-is for now.

Bjorn


From sboyd at codeaurora.org  Tue Jul  9 12:35:18 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 9 Jul 2013 09:35:18 -0700
Subject: CPU hotplug issue w/ 0647065 clocksource: Add generic dummy
 timer driver
In-Reply-To: <51DC34AD.30009@wwwdotorg.org>
References: <51DAF895.1020700@wwwdotorg.org>
 <20130709005837.GC830@codeaurora.org>
 <51DC34AD.30009@wwwdotorg.org>
Message-ID: <20130709163518.GD830@codeaurora.org>

On 07/09, Stephen Warren wrote:
> On 07/08/2013 06:58 PM, Stephen Boyd wrote:
> > On 07/08, Stephen Warren wrote:
> >> CPU hotplug (replug) on Tegra HW seems to be occasionally broken due to
> >> commit 0647065 "clocksource: Add generic dummy timer driver" in
> >> linux-next. Reverting that commit solves the issue.
> > 
> > We found some breakage during boot that has been fixed by two
> > commits in linus' tree already. Do you know if you have these two
> > patches
> > 
> > 1f73a9806bdd07a5106409bbcab3884078bd34fe
> > 07bd1172902e782f288e4d44b1fde7dec0f08b6f
> 
> I didn't before since I was using next-20130705, but I just tried
> next-20130709 which does have those two commits, and I still see the issue.
> 

Ok can you get the output of /proc/timer_list and send it back
please? I assume you have TWD and those should all be in the
per-cpu slots and the broadcast timer should be your tegra specific
timer.

The odd thing is that you're seeing periodic mode for the
broadcast which doesn't make any sense. I would expect oneshot
mode and tick_handle_oneshot_broadcast to be the handler.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From swarren at wwwdotorg.org  Tue Jul  9 12:38:08 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue,  9 Jul 2013 10:38:08 -0600
Subject: [PATCH V2] ARM: mm: restrict early_alloc_aligned to legal area
Message-ID: <1373387888-4137-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

When early_alloc_aligned() is called, it appears that only memory in the
first memory bank is mapped for CPU access. However, memblock_alloc() is
called to allocate the RAM, and that can return RAM that is part of any
valid memory bank, which hence could be inaccessible to the CPU. If this
happens, the subsequent memset() will hang or crash.

Solve this by calling memblock_alloc_base() instead of memblock_alloc().
This function takes an explicit max address. Use the minimum of the end
of the first memory bank and arm_lowmem_limit as the address.

As an example, this issue can be triggered as follows:

* Total of 512MB system RAM, so it is all lowmem not highmem. Without this,
  subsequent banks may be ignored by map_lowmem() due to being highmem.
* RAM is split into multiple banks, due to some RAM somewhere in the
  middle having been allocated for purposes other than Linux, e.g. an LCD
  frame-buffer of for a co-processor.
* Some bank is not section-aligned, so that alloc_init_pte() is called
  rather than __map_init_section().

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
v2: Limit early_alloc_aligned() to arm_lowmem_limit as well.
---
 arch/arm/mm/mmu.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index d7229d2..3c8f4ac 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -585,7 +585,11 @@ EXPORT_SYMBOL(phys_mem_access_prot);
 
 static void __init *early_alloc_aligned(unsigned long sz, unsigned long align)
 {
-	void *ptr = __va(memblock_alloc(sz, align));
+	phys_addr_t max_pa = min(memblock.memory.regions[0].base +
+					memblock.memory.regions[0].size,
+				arm_lowmem_limit);
+	phys_addr_t pa = memblock_alloc_base(sz, align, max_pa);
+	void *ptr = __va(pa);
 	memset(ptr, 0, sz);
 	return ptr;
 }
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:02 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:02 -0300
Subject: [PATCH v7 00/22] MBus DT binding: The return of PCIe
Message-ID: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>

Here's the new MBus DT binding, implementing the changes proposed
by Thomas when we discussed the previous patchset:

  http://www.spinics.net/lists/arm-kernel/msg257170.html

As far as I know, this round fixes *all* the concerns raised in the past
and therefore I'd like to get Acked-by's from all the parties involved
on the respective patches.

If there's anything left to review, we'll be glad to fix it quickly,
so don't hesitate in providing your feedback!

I guess many of you are dying to test this new MBus thing, so to make
it easier for those courageous enough, I've pushed a public branch:

  https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v7

@Jason:

As previously agreed this should be taken by you entirely.

The patchset is based on linux-next next-20130705 and will probably
apply with no conflicts to v3.11-rc1. I'll rebase it and resend it
on v3.11-rc1 if you need me to.

Changelog
---------

v7:

 * Add two optional properties pcie-{mem,io}-aperture to the MBus node
   defining the PCIe mem and IO region apertures.

 * Encode the PCIe port in the second cell of the ranges entries, using
   the PCIe slot; and remove such encoding from the first cell, since it
   was violating the specification.

   Quoting Jason Gunthorpe:
   """ [...] the OF spec says that the phys.hi fields of the child address
   spaces in the "ranges" property for PCI does not contain the same
   information as "reg" property entries within PCI nodes. The only information
   that is present in "ranges" phys.hi entries are the non-relocatable,
   prefetchable and the PCI address space bits for which the entry applies.
   I.e., only the n, p and ss bits are present; the bbbbbbbb, ddddd, fff and
   rrrrrrrr fields are 0."""

v6:

 * Change the PCIe ranges translations encoding, removing the big fake
   window encoded as MBUS_ID(0xf0, 0x02) by an array of entries representing
   the PCIe real windows with full 4 GiB size.

 * The corresponding PCIe port is selected by encoding the bus in the first cell
   of the PCIe controller node ranges entry.

 * Remove the name-based MBus window allocation API, replacing it by an
   ID-based API.

v5:

 * Add a required a 'controller' property to specify a phandle containing
   the MBus controller MMIO registers.

v4:

 * Fixed the pcie-controller to mbus address space translations, to match
   a 1:1 mapping between the PCI and CPU busses.

 * Fixed the binding documentation with suggestions from Arnd Bergmann.

 * Added a BootROM sanity check on AXP SMP initialization, as suggested
   by Jason Gunthorpe. This also implied changing slightly the bootrom
   node.

 * Changed the first cell format for the MBus address space.

v3:

 * Replaced the PCIe mapping with 0xffff0002, to avoid using a representation
   that might correspond to a possible window id.

 * Remove every mbus-node 'ranges' property from the dtsi files. Having them
   on the per-board dts files only makes maintaince less painful.

 * Declare children window size, in the children 'ranges' property, as large
   as possible (4 GiB size) and move the property to the dtsi files.
   The per-board dts, does not need to declare that property now.

 * The MBus driver now creates the decoding window using the base address and
   size specified in the mbus-node, instead of using the children entries.

v2:

 * Use the preprocessor on the DT and define a macro for the window ID.

 * Changed the way the address spaces were declared: the window's base
   addresses are only present in the mbus-node ranges property.
   This makes sense since that information belongs only to the MBus
   address space.

 * Drop the ranges dynamic update, since now the DT translations are complete.

 * Replaced the internal register first cell mapping with 0xffff0001, to avoid
   clashing when using 0x00000000.

 * Replaced the PCIe mapping with 0xffff0000.

v1:

  * Initial proposal

Example
-------

Here's an example showing how the MBus DT binding looks now:

soc {
	compatible = "marvell,armadaxp-mbus", "simple-bus";
	controller = <&mbusc>;
	pcie-mem-aperture = <0xe0000000 0x8000000>;
	pcie-io-aperture  = <0xe8000000 0x100000>;

	ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
		  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
		  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;

	bootrom {
		compatible = "marvell,bootrom";
		reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
	};

	devbus-bootcs {
		status = "okay";
		ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;

		/* NOR */
		nor {
			compatible = "cfi-flash";
			reg = <0 0x8000000>;
			bank-width = <2>;
		};
	};

	pcie-controller {
		compatible = "marvell,armada-xp-pcie";
		status = "okay";
		device_type = "pci";
		#address-cells = <3>;
		#size-cells = <2>;

		ranges =
			<0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
			0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
			0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
			0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
			0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
			0x82000000 0x1 0       MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
			0x81000000 0x1 0       MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */
			0x82000000 0x2 0       MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
			0x81000000 0x2 0       MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */>;


		pcie at 1,0 {
			device_type = "pci";
			assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
			reg = <0x0800 0 0 0 0>;
			#address-cells = <3>;
			#size-cells = <2>;
			#interrupt-cells = <1>;
			ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
				  0x81000000 0 0 0x81000000 0x1 0 1 0>;
			interrupt-map-mask = <0 0 0 0>;
			interrupt-map = <0 0 0 0 &mpic 58>;
			marvell,pcie-port = <0>;
			marvell,pcie-lane = <0>;
			clocks = <&gateclk 5>;
			status = "disabled";
		};

		pcie at 2,0 {
			device_type = "pci";
			assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
			reg = <0x1000 0 0 0 0>;
			#address-cells = <3>;
			#size-cells = <2>;
			#interrupt-cells = <1>;
			ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
				  0x81000000 0 0 0x81000000 0x2 0 1 0>;
			interrupt-map-mask = <0 0 0 0>;
			interrupt-map = <0 0 0 0 &mpic 62>;
			marvell,pcie-port = <1>;
			marvell,pcie-lane = <0>;
			clocks = <&gateclk 9>;
			status = "disabled";
		};
	};

	internal-regs {
		compatible = "simple-bus";
		#address-cells = <1>;
		#size-cells = <1>;
		ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;

		mbusc: mbus-controller at 20000 {
			reg = <0x20000 0x100>, <0x20180 0x20>;
		};

		interrupt-controller at 20000 {
			reg = <0x20a00 0x2d0>, <0x21070 0x58>;
		};
	};
};

Ezequiel Garcia (12):
  memory: mvebu-devbus: Remove address decoding window workaround
  bus: mvebu-mbus: Factor out initialization details
  bus: mvebu-mbus: Introduce device tree binding
  bus: mvebu-mbus: Add static window allocation to the DT binding
  bus: mvebu-mbus: Add new API for the PCIe memory and IO aperture
  ARM: mvebu: Remove the harcoded BootROM window allocation
  ARM: mvebu: Initialize MBus using the DT binding
  ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
  ARM: mvebu: Add MBus to Armada 370/XP device tree
  ARM: mvebu: Add BootROM to Armada 370/XP device tree
  ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
  ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes

Thomas Petazzoni (10):
  bus: mvebu-mbus: Add new API for window creation
  ARM: kirkwood: Move to ID based MBus window creation
  ARM: mv78xx0: Move to ID based window creation
  ARM: orion5x: Move to ID based window creation
  ARM: dove: Move to ID based window creation
  PCI: mvebu: Adapt to the new device tree layout
  bus: mvebu-mbus: Remove the no longer used name-based API
  bus: mvebu-mbus: Remove name -> target, attribute mapping tables
  bus: mvebu-mbus: Update main description
  bus: mvebu-mbus: Factorize Armada 370/XP data structures

 .../devicetree/bindings/bus/mvebu-mbus.txt         | 267 +++++++++++++
 .../devicetree/bindings/pci/mvebu-pci.txt          | 145 +++++--
 arch/arm/boot/dts/armada-370-db.dts                |   5 +-
 arch/arm/boot/dts/armada-370-mirabox.dts           |  37 +-
 arch/arm/boot/dts/armada-370-rd.dts                |   5 +-
 arch/arm/boot/dts/armada-370-xp.dtsi               | 111 +++---
 arch/arm/boot/dts/armada-370.dtsi                  | 112 +++---
 arch/arm/boot/dts/armada-xp-db.dts                 | 131 +++----
 arch/arm/boot/dts/armada-xp-gp.dts                 | 107 +++--
 arch/arm/boot/dts/armada-xp-mv78230.dtsi           | 222 ++++++-----
 arch/arm/boot/dts/armada-xp-mv78260.dtsi           | 263 +++++++------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi           | 411 ++++++++++---------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |  88 ++---
 arch/arm/boot/dts/armada-xp.dtsi                   |   9 +-
 arch/arm/mach-dove/common.c                        |  68 ++--
 arch/arm/mach-kirkwood/common.c                    |  18 +-
 arch/arm/mach-kirkwood/pcie.c                      |  40 +-
 arch/arm/mach-mv78xx0/pcie.c                       |  23 +-
 arch/arm/mach-mvebu/armada-370-xp.c                |  34 +-
 arch/arm/mach-mvebu/platsmp.c                      |  25 +-
 arch/arm/mach-orion5x/common.c                     |  36 +-
 arch/arm/mach-orion5x/common.h                     |  17 +
 arch/arm/mach-orion5x/d2net-setup.c                |   6 +-
 arch/arm/mach-orion5x/db88f5281-setup.c            |  24 +-
 arch/arm/mach-orion5x/dns323-setup.c               |   6 +-
 arch/arm/mach-orion5x/edmini_v2-setup.c            |   6 +-
 arch/arm/mach-orion5x/kurobox_pro-setup.c          |  12 +-
 arch/arm/mach-orion5x/ls-chl-setup.c               |   6 +-
 arch/arm/mach-orion5x/ls_hgl-setup.c               |   6 +-
 arch/arm/mach-orion5x/lsmini-setup.c               |   6 +-
 arch/arm/mach-orion5x/mss2-setup.c                 |   6 +-
 arch/arm/mach-orion5x/mv2120-setup.c               |   6 +-
 arch/arm/mach-orion5x/net2big-setup.c              |   6 +-
 arch/arm/mach-orion5x/pci.c                        |   9 +-
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c       |   6 +-
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c        |   6 +-
 arch/arm/mach-orion5x/rd88f5182-setup.c            |  13 +-
 arch/arm/mach-orion5x/terastation_pro2-setup.c     |   6 +-
 arch/arm/mach-orion5x/ts209-setup.c                |   6 +-
 arch/arm/mach-orion5x/ts409-setup.c                |   6 +-
 arch/arm/mach-orion5x/wnr854t-setup.c              |   6 +-
 arch/arm/mach-orion5x/wrt350n-v2-setup.c           |   6 +-
 drivers/bus/mvebu-mbus.c                           | 435 ++++++++++++---------
 drivers/memory/mvebu-devbus.c                      |  64 +--
 drivers/pci/host/pci-mvebu.c                       | 113 ++++--
 include/linux/mbus.h                               |  16 +-
 46 files changed, 1775 insertions(+), 1181 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt

-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:04 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:04 -0300
Subject: [PATCH v7 02/22] bus: mvebu-mbus: Add new API for window creation
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-3-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

We add an API to create MBus address decoding windows from the target
ID and attribute. This function will be used later and deprecate the
current name based scheme.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 33 +++++++++++++++++++++++++--------
 include/linux/mbus.h     |  6 ++++++
 2 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 33c6947..827468a 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -748,6 +748,22 @@ static const struct of_device_id of_mvebu_mbus_ids[] = {
 /*
  * Public API of the driver
  */
+int mvebu_mbus_add_window_remap_by_id(unsigned int target,
+				      unsigned int attribute,
+				      phys_addr_t base, size_t size,
+				      phys_addr_t remap)
+{
+	struct mvebu_mbus_state *s = &mbus_state;
+
+	if (!mvebu_mbus_window_conflicts(s, base, size, target, attribute)) {
+		pr_err("cannot add window '%x:%x', conflicts with another window\n",
+		       target, attribute);
+		return -EINVAL;
+	}
+
+	return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
+}
+
 int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 				      size_t size, phys_addr_t remap,
 				      unsigned int flags)
@@ -776,14 +792,8 @@ int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 	else if (flags == MVEBU_MBUS_PCI_WA)
 		attr |= 0x28;
 
-	if (!mvebu_mbus_window_conflicts(s, base, size, target, attr)) {
-		pr_err("cannot add window '%s', conflicts with another window\n",
-		       devname);
-		return -EINVAL;
-	}
-
-	return mvebu_mbus_alloc_window(s, base, size, remap, target, attr);
-
+	return mvebu_mbus_add_window_remap_by_id(target, attr, base,
+						 size, remap);
 }
 
 int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
@@ -792,6 +802,13 @@ int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
 						 MVEBU_MBUS_NO_REMAP, 0);
 }
 
+int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
+				phys_addr_t base, size_t size)
+{
+	return mvebu_mbus_add_window_remap_by_id(target, attribute, base,
+						 size, MVEBU_MBUS_NO_REMAP);
+}
+
 int mvebu_mbus_del_window(phys_addr_t base, size_t size)
 {
 	int win;
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index dba482e..9245b66 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -62,8 +62,14 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
 int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 				      size_t size, phys_addr_t remap,
 				      unsigned int flags);
+int mvebu_mbus_add_window_remap_by_id(unsigned int target,
+				      unsigned int attribute,
+				      phys_addr_t base, size_t size,
+				      phys_addr_t remap);
 int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
 			  size_t size);
+int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
+				phys_addr_t base, size_t size);
 int mvebu_mbus_del_window(phys_addr_t base, size_t size);
 int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
 		    size_t mbus_size, phys_addr_t sdram_phys_base,
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:03 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:03 -0300
Subject: [PATCH v7 01/22] memory: mvebu-devbus: Remove address decoding window
 workaround
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-2-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus device tree binding has been introduced, remove the address
decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in
the device tree, as described by the mbus binding documentation.

Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/memory/mvebu-devbus.c | 64 ++-----------------------------------------
 1 file changed, 2 insertions(+), 62 deletions(-)

diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
index 978e8e3..94c9248 100644
--- a/drivers/memory/mvebu-devbus.c
+++ b/drivers/memory/mvebu-devbus.c
@@ -208,16 +208,11 @@ static int mvebu_devbus_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct device_node *node = pdev->dev.of_node;
-	struct device_node *parent;
 	struct devbus *devbus;
 	struct resource *res;
 	struct clk *clk;
 	unsigned long rate;
-	const __be32 *ranges;
-	int err, cs;
-	int addr_cells, p_addr_cells, size_cells;
-	int ranges_len, tuple_len;
-	u32 base, size;
+	int err;
 
 	devbus = devm_kzalloc(&pdev->dev, sizeof(struct devbus), GFP_KERNEL);
 	if (!devbus)
@@ -248,68 +243,13 @@ static int mvebu_devbus_probe(struct platform_device *pdev)
 		return err;
 
 	/*
-	 * Allocate an address window for this device.
-	 * If the device probing fails, then we won't be able to
-	 * remove the allocated address decoding window.
-	 *
-	 * FIXME: This is only a temporary hack! We need to do this here
-	 * because we still don't have device tree bindings for mbus.
-	 * Once that support is added, we will declare these address windows
-	 * statically in the device tree, and remove the window configuration
-	 * from here.
-	 */
-
-	/*
-	 * Get the CS to choose the window string.
-	 * This is a bit hacky, but it will be removed once the
-	 * address windows are declared in the device tree.
-	 */
-	cs = (((unsigned long)devbus->base) % 0x400) / 8;
-
-	/*
-	 * Parse 'ranges' property to obtain a (base,size) window tuple.
-	 * This will be removed once the address windows
-	 * are declared in the device tree.
-	 */
-	parent = of_get_parent(node);
-	if (!parent)
-		return -EINVAL;
-
-	p_addr_cells = of_n_addr_cells(parent);
-	of_node_put(parent);
-
-	addr_cells = of_n_addr_cells(node);
-	size_cells = of_n_size_cells(node);
-	tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
-
-	ranges = of_get_property(node, "ranges", &ranges_len);
-	if (ranges == NULL || ranges_len != tuple_len)
-		return -EINVAL;
-
-	base = of_translate_address(node, ranges + addr_cells);
-	if (base == OF_BAD_ADDR)
-		return -EINVAL;
-	size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
-
-	/*
-	 * Create an mbus address windows.
-	 * FIXME: Remove this, together with the above code, once the
-	 * address windows are declared in the device tree.
-	 */
-	err = mvebu_mbus_add_window(devbus_wins[cs], base, size);
-	if (err < 0)
-		return err;
-
-	/*
 	 * We need to create a child device explicitly from here to
 	 * guarantee that the child will be probed after the timing
 	 * parameters for the bus are written.
 	 */
 	err = of_platform_populate(node, NULL, NULL, dev);
-	if (err < 0) {
-		mvebu_mbus_del_window(base, size);
+	if (err < 0)
 		return err;
-	}
 
 	return 0;
 }
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:05 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:05 -0300
Subject: [PATCH v7 03/22] ARM: kirkwood: Move to ID based MBus window creation
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-4-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-kirkwood/common.c | 18 ++++++++++++++----
 arch/arm/mach-kirkwood/pcie.c   | 40 ++++++++++++++++++++++++----------------
 2 files changed, 38 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index e9238b5..165e751 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -37,6 +37,12 @@
 #include <linux/platform_data/dma-mv_xor.h>
 #include "common.h"
 
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_NAND_TARGET 0x01
+#define KIRKWOOD_MBUS_NAND_ATTR   0x2f
+#define KIRKWOOD_MBUS_SRAM_TARGET 0x03
+#define KIRKWOOD_MBUS_SRAM_ATTR   0x01
+
 /*****************************************************************************
  * I/O Address Mapping
  ****************************************************************************/
@@ -672,10 +678,14 @@ char * __init kirkwood_id(void)
 
 void __init kirkwood_setup_wins(void)
 {
-	mvebu_mbus_add_window("nand", KIRKWOOD_NAND_MEM_PHYS_BASE,
-			      KIRKWOOD_NAND_MEM_SIZE);
-	mvebu_mbus_add_window("sram", KIRKWOOD_SRAM_PHYS_BASE,
-			      KIRKWOOD_SRAM_SIZE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_NAND_TARGET,
+				    KIRKWOOD_MBUS_NAND_ATTR,
+				    KIRKWOOD_NAND_MEM_PHYS_BASE,
+				    KIRKWOOD_NAND_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_SRAM_TARGET,
+				    KIRKWOOD_MBUS_SRAM_ATTR,
+				    KIRKWOOD_SRAM_PHYS_BASE,
+				    KIRKWOOD_SRAM_SIZE);
 }
 
 void __init kirkwood_l2_init(void)
diff --git a/arch/arm/mach-kirkwood/pcie.c b/arch/arm/mach-kirkwood/pcie.c
index ddcb09f..12d86f3 100644
--- a/arch/arm/mach-kirkwood/pcie.c
+++ b/arch/arm/mach-kirkwood/pcie.c
@@ -20,6 +20,16 @@
 #include <mach/bridge-regs.h>
 #include "common.h"
 
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_PCIE0_MEM_TARGET    0x4
+#define KIRKWOOD_MBUS_PCIE0_MEM_ATTR      0xe8
+#define KIRKWOOD_MBUS_PCIE0_IO_TARGET     0x4
+#define KIRKWOOD_MBUS_PCIE0_IO_ATTR       0xe0
+#define KIRKWOOD_MBUS_PCIE1_MEM_TARGET    0x4
+#define KIRKWOOD_MBUS_PCIE1_MEM_ATTR      0xd8
+#define KIRKWOOD_MBUS_PCIE1_IO_TARGET     0x4
+#define KIRKWOOD_MBUS_PCIE1_IO_ATTR       0xd0
+
 static void kirkwood_enable_pcie_clk(const char *port)
 {
 	struct clk *clk;
@@ -254,26 +264,24 @@ static void __init add_pcie_port(int index, void __iomem *base)
 
 void __init kirkwood_pcie_init(unsigned int portmask)
 {
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
+	mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE0_IO_TARGET,
+					  KIRKWOOD_MBUS_PCIE0_IO_ATTR,
 					  KIRKWOOD_PCIE_IO_PHYS_BASE,
 					  KIRKWOOD_PCIE_IO_SIZE,
-					  KIRKWOOD_PCIE_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
-					  KIRKWOOD_PCIE_MEM_PHYS_BASE,
-					  KIRKWOOD_PCIE_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
+					  KIRKWOOD_PCIE_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_PCIE0_MEM_TARGET,
+				    KIRKWOOD_MBUS_PCIE0_MEM_ATTR,
+				    KIRKWOOD_PCIE_MEM_PHYS_BASE,
+				    KIRKWOOD_PCIE_MEM_SIZE);
+	mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE1_IO_TARGET,
+					  KIRKWOOD_MBUS_PCIE1_IO_ATTR,
 					  KIRKWOOD_PCIE1_IO_PHYS_BASE,
 					  KIRKWOOD_PCIE1_IO_SIZE,
-					  KIRKWOOD_PCIE1_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
-					  KIRKWOOD_PCIE1_MEM_PHYS_BASE,
-					  KIRKWOOD_PCIE1_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+					  KIRKWOOD_PCIE1_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_PCIE1_MEM_TARGET,
+				    KIRKWOOD_MBUS_PCIE1_MEM_ATTR,
+				    KIRKWOOD_PCIE1_MEM_PHYS_BASE,
+				    KIRKWOOD_PCIE1_MEM_SIZE);
 
 	vga_base = KIRKWOOD_PCIE_MEM_PHYS_BASE;
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:06 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:06 -0300
Subject: [PATCH v7 04/22] ARM: mv78xx0: Move to ID based window creation
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-5-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-mv78xx0/pcie.c | 23 +++++++++++------------
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-mv78xx0/pcie.c b/arch/arm/mach-mv78xx0/pcie.c
index dc26a65..397afde 100644
--- a/arch/arm/mach-mv78xx0/pcie.c
+++ b/arch/arm/mach-mv78xx0/pcie.c
@@ -18,6 +18,11 @@
 #include <mach/mv78xx0.h>
 #include "common.h"
 
+#define MV78XX0_MBUS_PCIE_MEM_TARGET(port,lane) ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_MEM_ATTR(port,lane)   (0xf8 & ~(0x10 << (lane)))
+#define MV78XX0_MBUS_PCIE_IO_TARGET(port,lane)  ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_IO_ATTR(port,lane)    (0xf0 & ~(0x10 << (lane)))
+
 struct pcie_port {
 	u8			maj;
 	u8			min;
@@ -71,7 +76,6 @@ static void __init mv78xx0_pcie_preinit(void)
 	start = MV78XX0_PCIE_MEM_PHYS_BASE;
 	for (i = 0; i < num_pcie_ports; i++) {
 		struct pcie_port *pp = pcie_port + i;
-		char winname[MVEBU_MBUS_MAX_WINNAME_SZ];
 
 		snprintf(pp->mem_space_name, sizeof(pp->mem_space_name),
 			"PCIe %d.%d MEM", pp->maj, pp->min);
@@ -85,17 +89,12 @@ static void __init mv78xx0_pcie_preinit(void)
 		if (request_resource(&iomem_resource, &pp->res))
 			panic("can't allocate PCIe MEM sub-space");
 
-		snprintf(winname, sizeof(winname), "pcie%d.%d",
-			 pp->maj, pp->min);
-
-		mvebu_mbus_add_window_remap_flags(winname,
-						  pp->res.start,
-						  resource_size(&pp->res),
-						  MVEBU_MBUS_NO_REMAP,
-						  MVEBU_MBUS_PCI_MEM);
-		mvebu_mbus_add_window_remap_flags(winname,
-						  i * SZ_64K, SZ_64K,
-						  0, MVEBU_MBUS_PCI_IO);
+		mvebu_mbus_add_window_by_id(MV78XX0_MBUS_PCIE_MEM_TARGET(pp->maj, pp->min),
+					    MV78XX0_MBUS_PCIE_MEM_ATTR(pp->maj, pp->min),
+					    pp->res.start, resource_size(&pp->res));
+		mvebu_mbus_add_window_remap_by_id(MV78XX0_MBUS_PCIE_IO_TARGET(pp->maj, pp->min),
+						  MV78XX0_MBUS_PCIE_IO_ATTR(pp->maj, pp->min),
+						  i * SZ_64K, SZ_64K, 0);
 	}
 }
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:07 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:07 -0300
Subject: [PATCH v7 05/22] ARM: orion5x: Move to ID based window creation
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-6-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-orion5x/common.c                 | 36 ++++++++++++++------------
 arch/arm/mach-orion5x/common.h                 | 17 ++++++++++++
 arch/arm/mach-orion5x/d2net-setup.c            |  6 +++--
 arch/arm/mach-orion5x/db88f5281-setup.c        | 24 +++++++++++------
 arch/arm/mach-orion5x/dns323-setup.c           |  6 +++--
 arch/arm/mach-orion5x/edmini_v2-setup.c        |  6 +++--
 arch/arm/mach-orion5x/kurobox_pro-setup.c      | 12 ++++++---
 arch/arm/mach-orion5x/ls-chl-setup.c           |  6 +++--
 arch/arm/mach-orion5x/ls_hgl-setup.c           |  6 +++--
 arch/arm/mach-orion5x/lsmini-setup.c           |  6 +++--
 arch/arm/mach-orion5x/mss2-setup.c             |  6 +++--
 arch/arm/mach-orion5x/mv2120-setup.c           |  6 +++--
 arch/arm/mach-orion5x/net2big-setup.c          |  6 +++--
 arch/arm/mach-orion5x/pci.c                    |  9 +++----
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c   |  6 +++--
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c    |  6 +++--
 arch/arm/mach-orion5x/rd88f5182-setup.c        | 13 ++++++----
 arch/arm/mach-orion5x/terastation_pro2-setup.c |  6 +++--
 arch/arm/mach-orion5x/ts209-setup.c            |  6 +++--
 arch/arm/mach-orion5x/ts409-setup.c            |  6 +++--
 arch/arm/mach-orion5x/wnr854t-setup.c          |  6 +++--
 arch/arm/mach-orion5x/wrt350n-v2-setup.c       |  6 +++--
 22 files changed, 137 insertions(+), 70 deletions(-)

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index b41599f..91a5852 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -174,8 +174,10 @@ void __init orion5x_xor_init(void)
  ****************************************************************************/
 static void __init orion5x_crypto_init(void)
 {
-	mvebu_mbus_add_window("sram", ORION5X_SRAM_PHYS_BASE,
-			      ORION5X_SRAM_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_SRAM_TARGET,
+				    ORION_MBUS_SRAM_ATTR,
+				    ORION5X_SRAM_PHYS_BASE,
+				    ORION5X_SRAM_SIZE);
 	orion_crypto_init(ORION5X_CRYPTO_PHYS_BASE, ORION5X_SRAM_PHYS_BASE,
 			  SZ_8K, IRQ_ORION5X_CESA);
 }
@@ -222,22 +224,24 @@ void orion5x_setup_wins(void)
 	 * The PCIe windows will no longer be statically allocated
 	 * here once Orion5x is migrated to the pci-mvebu driver.
 	 */
-	mvebu_mbus_add_window_remap_flags("pcie0.0", ORION5X_PCIE_IO_PHYS_BASE,
+	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
+					  ORION_MBUS_PCIE_IO_ATTR,
+					  ORION5X_PCIE_IO_PHYS_BASE,
 					  ORION5X_PCIE_IO_SIZE,
-					  ORION5X_PCIE_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0", ORION5X_PCIE_MEM_PHYS_BASE,
-					  ORION5X_PCIE_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pci0.0", ORION5X_PCI_IO_PHYS_BASE,
+					  ORION5X_PCIE_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
+				    ORION_MBUS_PCIE_MEM_ATTR,
+				    ORION5X_PCIE_MEM_PHYS_BASE,
+				    ORION5X_PCIE_MEM_SIZE);
+	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
+					  ORION_MBUS_PCI_IO_ATTR,
+					  ORION5X_PCI_IO_PHYS_BASE,
 					  ORION5X_PCI_IO_SIZE,
-					  ORION5X_PCI_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pci0.0", ORION5X_PCI_MEM_PHYS_BASE,
-					  ORION5X_PCI_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+					  ORION5X_PCI_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
+				    ORION_MBUS_PCI_MEM_ATTR,
+				    ORION5X_PCI_MEM_PHYS_BASE,
+				    ORION5X_PCI_MEM_SIZE);
 }
 
 int orion5x_tclk;
diff --git a/arch/arm/mach-orion5x/common.h b/arch/arm/mach-orion5x/common.h
index a909afb..f565f99 100644
--- a/arch/arm/mach-orion5x/common.h
+++ b/arch/arm/mach-orion5x/common.h
@@ -7,6 +7,23 @@ struct dsa_platform_data;
 struct mv643xx_eth_platform_data;
 struct mv_sata_platform_data;
 
+#define ORION_MBUS_PCIE_MEM_TARGET    0x04
+#define ORION_MBUS_PCIE_MEM_ATTR      0x59
+#define ORION_MBUS_PCIE_IO_TARGET     0x04
+#define ORION_MBUS_PCIE_IO_ATTR       0x51
+#define ORION_MBUS_PCIE_WA_TARGET     0x04
+#define ORION_MBUS_PCIE_WA_ATTR       0x79
+#define ORION_MBUS_PCI_MEM_TARGET     0x03
+#define ORION_MBUS_PCI_MEM_ATTR       0x59
+#define ORION_MBUS_PCI_IO_TARGET      0x03
+#define ORION_MBUS_PCI_IO_ATTR        0x51
+#define ORION_MBUS_DEVBUS_BOOT_TARGET 0x01
+#define ORION_MBUS_DEVBUS_BOOT_ATTR   0x0f
+#define ORION_MBUS_DEVBUS_TARGET(cs)  0x01
+#define ORION_MBUS_DEVBUS_ATTR(cs)    (~(1 << cs))
+#define ORION_MBUS_SRAM_TARGET        0x00
+#define ORION_MBUS_SRAM_ATTR          0x00
+
 /*
  * Basic Orion init functions used early by machine-setup.
  */
diff --git a/arch/arm/mach-orion5x/d2net-setup.c b/arch/arm/mach-orion5x/d2net-setup.c
index 16c88bb..8f68b74 100644
--- a/arch/arm/mach-orion5x/d2net-setup.c
+++ b/arch/arm/mach-orion5x/d2net-setup.c
@@ -317,8 +317,10 @@ static void __init d2net_init(void)
 	d2net_sata_power_init();
 	orion5x_sata_init(&d2net_sata_data);
 
-	mvebu_mbus_add_window("devbus-boot", D2NET_NOR_BOOT_BASE,
-			      D2NET_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    D2NET_NOR_BOOT_BASE,
+				    D2NET_NOR_BOOT_SIZE);
 	platform_device_register(&d2net_nor_flash);
 
 	platform_device_register(&d2net_gpio_buttons);
diff --git a/arch/arm/mach-orion5x/db88f5281-setup.c b/arch/arm/mach-orion5x/db88f5281-setup.c
index 4e1263d..4b2aefd 100644
--- a/arch/arm/mach-orion5x/db88f5281-setup.c
+++ b/arch/arm/mach-orion5x/db88f5281-setup.c
@@ -340,19 +340,27 @@ static void __init db88f5281_init(void)
 	orion5x_uart0_init();
 	orion5x_uart1_init();
 
-	mvebu_mbus_add_window("devbus-boot", DB88F5281_NOR_BOOT_BASE,
-			      DB88F5281_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    DB88F5281_NOR_BOOT_BASE,
+				    DB88F5281_NOR_BOOT_SIZE);
 	platform_device_register(&db88f5281_boot_flash);
 
-	mvebu_mbus_add_window("devbus-cs0", DB88F5281_7SEG_BASE,
-			      DB88F5281_7SEG_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(0),
+				    ORION_MBUS_DEVBUS_ATTR(0),
+				    DB88F5281_7SEG_BASE,
+				    DB88F5281_7SEG_SIZE);
 
-	mvebu_mbus_add_window("devbus-cs1", DB88F5281_NOR_BASE,
-			      DB88F5281_NOR_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(1),
+				    ORION_MBUS_DEVBUS_ATTR(1),
+				    DB88F5281_NOR_BASE,
+				    DB88F5281_NOR_SIZE);
 	platform_device_register(&db88f5281_nor_flash);
 
-	mvebu_mbus_add_window("devbus-cs2", DB88F5281_NAND_BASE,
-			      DB88F5281_NAND_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(2),
+				    ORION_MBUS_DEVBUS_ATTR(2),
+				    DB88F5281_NAND_BASE,
+				    DB88F5281_NAND_SIZE);
 	platform_device_register(&db88f5281_nand_flash);
 
 	i2c_register_board_info(0, &db88f5281_i2c_rtc, 1);
diff --git a/arch/arm/mach-orion5x/dns323-setup.c b/arch/arm/mach-orion5x/dns323-setup.c
index 9e6baf5..7097473 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -611,8 +611,10 @@ static void __init dns323_init(void)
 	/* setup flash mapping
 	 * CS3 holds a 8 MB Spansion S29GL064M90TFIR4
 	 */
-	mvebu_mbus_add_window("devbus-boot", DNS323_NOR_BOOT_BASE,
-			      DNS323_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    DNS323_NOR_BOOT_BASE,
+				    DNS323_NOR_BOOT_SIZE);
 	platform_device_register(&dns323_nor_flash);
 
 	/* Sort out LEDs, Buttons and i2c devices */
diff --git a/arch/arm/mach-orion5x/edmini_v2-setup.c b/arch/arm/mach-orion5x/edmini_v2-setup.c
index 1476155..0fc33c5 100644
--- a/arch/arm/mach-orion5x/edmini_v2-setup.c
+++ b/arch/arm/mach-orion5x/edmini_v2-setup.c
@@ -154,8 +154,10 @@ void __init edmini_v2_init(void)
 	orion5x_ehci0_init();
 	orion5x_eth_init(&edmini_v2_eth_data);
 
-	mvebu_mbus_add_window("devbus-boot", EDMINI_V2_NOR_BOOT_BASE,
-			      EDMINI_V2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    EDMINI_V2_NOR_BOOT_BASE,
+				    EDMINI_V2_NOR_BOOT_SIZE);
 	platform_device_register(&edmini_v2_nor_flash);
 
 	pr_notice("edmini_v2: USB device port, flash write and power-off "
diff --git a/arch/arm/mach-orion5x/kurobox_pro-setup.c b/arch/arm/mach-orion5x/kurobox_pro-setup.c
index aae10e4..fe6a48a 100644
--- a/arch/arm/mach-orion5x/kurobox_pro-setup.c
+++ b/arch/arm/mach-orion5x/kurobox_pro-setup.c
@@ -359,13 +359,17 @@ static void __init kurobox_pro_init(void)
 	orion5x_uart1_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", KUROBOX_PRO_NOR_BOOT_BASE,
-			      KUROBOX_PRO_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    KUROBOX_PRO_NOR_BOOT_BASE,
+				    KUROBOX_PRO_NOR_BOOT_SIZE);
 	platform_device_register(&kurobox_pro_nor_flash);
 
 	if (machine_is_kurobox_pro()) {
-		mvebu_mbus_add_window("devbus-cs0", KUROBOX_PRO_NAND_BASE,
-				      KUROBOX_PRO_NAND_SIZE);
+		mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(0),
+					    ORION_MBUS_DEVBUS_ATTR(0),
+					    KUROBOX_PRO_NAND_BASE,
+					    KUROBOX_PRO_NAND_SIZE);
 		platform_device_register(&kurobox_pro_nand_flash);
 	}
 
diff --git a/arch/arm/mach-orion5x/ls-chl-setup.c b/arch/arm/mach-orion5x/ls-chl-setup.c
index 6234977..028ea03 100644
--- a/arch/arm/mach-orion5x/ls-chl-setup.c
+++ b/arch/arm/mach-orion5x/ls-chl-setup.c
@@ -294,8 +294,10 @@ static void __init lschl_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LSCHL_NOR_BOOT_BASE,
-			      LSCHL_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LSCHL_NOR_BOOT_BASE,
+				    LSCHL_NOR_BOOT_SIZE);
 	platform_device_register(&lschl_nor_flash);
 
 	platform_device_register(&lschl_leds);
diff --git a/arch/arm/mach-orion5x/ls_hgl-setup.c b/arch/arm/mach-orion5x/ls_hgl-setup.c
index fe04c4b..32b7129 100644
--- a/arch/arm/mach-orion5x/ls_hgl-setup.c
+++ b/arch/arm/mach-orion5x/ls_hgl-setup.c
@@ -243,8 +243,10 @@ static void __init ls_hgl_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LS_HGL_NOR_BOOT_BASE,
-			      LS_HGL_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LS_HGL_NOR_BOOT_BASE,
+				    LS_HGL_NOR_BOOT_SIZE);
 	platform_device_register(&ls_hgl_nor_flash);
 
 	platform_device_register(&ls_hgl_button_device);
diff --git a/arch/arm/mach-orion5x/lsmini-setup.c b/arch/arm/mach-orion5x/lsmini-setup.c
index ca4dbe9..a6493e7 100644
--- a/arch/arm/mach-orion5x/lsmini-setup.c
+++ b/arch/arm/mach-orion5x/lsmini-setup.c
@@ -244,8 +244,10 @@ static void __init lsmini_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LSMINI_NOR_BOOT_BASE,
-			      LSMINI_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LSMINI_NOR_BOOT_BASE,
+				    LSMINI_NOR_BOOT_SIZE);
 	platform_device_register(&lsmini_nor_flash);
 
 	platform_device_register(&lsmini_button_device);
diff --git a/arch/arm/mach-orion5x/mss2-setup.c b/arch/arm/mach-orion5x/mss2-setup.c
index 827acba..e105130 100644
--- a/arch/arm/mach-orion5x/mss2-setup.c
+++ b/arch/arm/mach-orion5x/mss2-setup.c
@@ -241,8 +241,10 @@ static void __init mss2_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", MSS2_NOR_BOOT_BASE,
-			      MSS2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    MSS2_NOR_BOOT_BASE,
+				    MSS2_NOR_BOOT_SIZE);
 	platform_device_register(&mss2_nor_flash);
 
 	platform_device_register(&mss2_button_device);
diff --git a/arch/arm/mach-orion5x/mv2120-setup.c b/arch/arm/mach-orion5x/mv2120-setup.c
index 92600ae..e032f01 100644
--- a/arch/arm/mach-orion5x/mv2120-setup.c
+++ b/arch/arm/mach-orion5x/mv2120-setup.c
@@ -204,8 +204,10 @@ static void __init mv2120_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", MV2120_NOR_BOOT_BASE,
-			      MV2120_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    MV2120_NOR_BOOT_BASE,
+				    MV2120_NOR_BOOT_SIZE);
 	platform_device_register(&mv2120_nor_flash);
 
 	platform_device_register(&mv2120_button_device);
diff --git a/arch/arm/mach-orion5x/net2big-setup.c b/arch/arm/mach-orion5x/net2big-setup.c
index dd0641a..ba73dc7 100644
--- a/arch/arm/mach-orion5x/net2big-setup.c
+++ b/arch/arm/mach-orion5x/net2big-setup.c
@@ -397,8 +397,10 @@ static void __init net2big_init(void)
 	net2big_sata_power_init();
 	orion5x_sata_init(&net2big_sata_data);
 
-	mvebu_mbus_add_window("devbus-boot", NET2BIG_NOR_BOOT_BASE,
-			      NET2BIG_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    NET2BIG_NOR_BOOT_BASE,
+				    NET2BIG_NOR_BOOT_SIZE);
 	platform_device_register(&net2big_nor_flash);
 
 	platform_device_register(&net2big_gpio_buttons);
diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion5x/pci.c
index 5033680..7fab670 100644
--- a/arch/arm/mach-orion5x/pci.c
+++ b/arch/arm/mach-orion5x/pci.c
@@ -157,11 +157,10 @@ static int __init pcie_setup(struct pci_sys_data *sys)
 	if (dev == MV88F5181_DEV_ID || dev == MV88F5182_DEV_ID) {
 		printk(KERN_NOTICE "Applying Orion-1/Orion-NAS PCIe config "
 				   "read transaction workaround\n");
-		mvebu_mbus_add_window_remap_flags("pcie0.0",
-						  ORION5X_PCIE_WA_PHYS_BASE,
-						  ORION5X_PCIE_WA_SIZE,
-						  MVEBU_MBUS_NO_REMAP,
-						  MVEBU_MBUS_PCI_WA);
+		mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_WA_TARGET,
+					    ORION_MBUS_PCIE_WA_ATTR,
+					    ORION5X_PCIE_WA_PHYS_BASE,
+					    ORION5X_PCIE_WA_SIZE);
 		pcie_ops.read = pcie_rd_conf_wa;
 	}
 
diff --git a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
index 1c4498b..213b3e1 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
@@ -123,8 +123,10 @@ static void __init rd88f5181l_fxo_init(void)
 	orion5x_eth_switch_init(&rd88f5181l_fxo_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5181L_FXO_NOR_BOOT_BASE,
-			      RD88F5181L_FXO_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5181L_FXO_NOR_BOOT_BASE,
+				    RD88F5181L_FXO_NOR_BOOT_SIZE);
 	platform_device_register(&rd88f5181l_fxo_nor_boot_flash);
 }
 
diff --git a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
index adabe34..594800e 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
@@ -130,8 +130,10 @@ static void __init rd88f5181l_ge_init(void)
 	orion5x_i2c_init();
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5181L_GE_NOR_BOOT_BASE,
-			      RD88F5181L_GE_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5181L_GE_NOR_BOOT_BASE,
+				    RD88F5181L_GE_NOR_BOOT_SIZE);
 	platform_device_register(&rd88f5181l_ge_nor_boot_flash);
 
 	i2c_register_board_info(0, &rd88f5181l_ge_i2c_rtc, 1);
diff --git a/arch/arm/mach-orion5x/rd88f5182-setup.c b/arch/arm/mach-orion5x/rd88f5182-setup.c
index 66e77ec..b1cf684 100644
--- a/arch/arm/mach-orion5x/rd88f5182-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5182-setup.c
@@ -264,11 +264,14 @@ static void __init rd88f5182_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5182_NOR_BOOT_BASE,
-			      RD88F5182_NOR_BOOT_SIZE);
-
-	mvebu_mbus_add_window("devbus-cs1", RD88F5182_NOR_BASE,
-			      RD88F5182_NOR_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5182_NOR_BOOT_BASE,
+				    RD88F5182_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(1),
+				    ORION_MBUS_DEVBUS_ATTR(1),
+				    RD88F5182_NOR_BASE,
+				    RD88F5182_NOR_SIZE);
 	platform_device_register(&rd88f5182_nor_flash);
 	platform_device_register(&rd88f5182_gpio_leds);
 
diff --git a/arch/arm/mach-orion5x/terastation_pro2-setup.c b/arch/arm/mach-orion5x/terastation_pro2-setup.c
index a0bfa53..7e90648 100644
--- a/arch/arm/mach-orion5x/terastation_pro2-setup.c
+++ b/arch/arm/mach-orion5x/terastation_pro2-setup.c
@@ -329,8 +329,10 @@ static void __init tsp2_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", TSP2_NOR_BOOT_BASE,
-			      TSP2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    TSP2_NOR_BOOT_BASE,
+				    TSP2_NOR_BOOT_SIZE);
 	platform_device_register(&tsp2_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/ts209-setup.c b/arch/arm/mach-orion5x/ts209-setup.c
index 80174f0..e90c061 100644
--- a/arch/arm/mach-orion5x/ts209-setup.c
+++ b/arch/arm/mach-orion5x/ts209-setup.c
@@ -286,8 +286,10 @@ static void __init qnap_ts209_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", QNAP_TS209_NOR_BOOT_BASE,
-			      QNAP_TS209_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    QNAP_TS209_NOR_BOOT_BASE,
+				    QNAP_TS209_NOR_BOOT_SIZE);
 	platform_device_register(&qnap_ts209_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/ts409-setup.c b/arch/arm/mach-orion5x/ts409-setup.c
index 9259279..5c079d3 100644
--- a/arch/arm/mach-orion5x/ts409-setup.c
+++ b/arch/arm/mach-orion5x/ts409-setup.c
@@ -277,8 +277,10 @@ static void __init qnap_ts409_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", QNAP_TS409_NOR_BOOT_BASE,
-			      QNAP_TS409_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    QNAP_TS409_NOR_BOOT_BASE,
+				    QNAP_TS409_NOR_BOOT_SIZE);
 	platform_device_register(&qnap_ts409_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/wnr854t-setup.c b/arch/arm/mach-orion5x/wnr854t-setup.c
index 6b84863..80a56ee 100644
--- a/arch/arm/mach-orion5x/wnr854t-setup.c
+++ b/arch/arm/mach-orion5x/wnr854t-setup.c
@@ -127,8 +127,10 @@ static void __init wnr854t_init(void)
 	orion5x_eth_switch_init(&wnr854t_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", WNR854T_NOR_BOOT_BASE,
-			      WNR854T_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    WNR854T_NOR_BOOT_BASE,
+				    WNR854T_NOR_BOOT_SIZE);
 	platform_device_register(&wnr854t_nor_flash);
 }
 
diff --git a/arch/arm/mach-orion5x/wrt350n-v2-setup.c b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
index fae684b..670e30d 100644
--- a/arch/arm/mach-orion5x/wrt350n-v2-setup.c
+++ b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
@@ -213,8 +213,10 @@ static void __init wrt350n_v2_init(void)
 	orion5x_eth_switch_init(&wrt350n_v2_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", WRT350N_V2_NOR_BOOT_BASE,
-			      WRT350N_V2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    WRT350N_V2_NOR_BOOT_BASE,
+				    WRT350N_V2_NOR_BOOT_SIZE);
 	platform_device_register(&wrt350n_v2_nor_flash);
 	platform_device_register(&wrt350n_v2_leds);
 	platform_device_register(&wrt350n_v2_button_device);
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:08 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:08 -0300
Subject: [PATCH v7 06/22] ARM: dove: Move to ID based window creation
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-7-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-dove/common.c | 68 ++++++++++++++++++++++++++++++---------------
 1 file changed, 45 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 00247c7..bc22056 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -27,6 +27,22 @@
 #include <plat/time.h>
 #include "common.h"
 
+/* These can go away once Dove uses the mvebu-mbus DT binding */
+#define DOVE_MBUS_PCIE0_MEM_TARGET    0x4
+#define DOVE_MBUS_PCIE0_MEM_ATTR      0xe8
+#define DOVE_MBUS_PCIE0_IO_TARGET     0x4
+#define DOVE_MBUS_PCIE0_IO_ATTR       0xe0
+#define DOVE_MBUS_PCIE1_MEM_TARGET    0x8
+#define DOVE_MBUS_PCIE1_MEM_ATTR      0xe8
+#define DOVE_MBUS_PCIE1_IO_TARGET     0x8
+#define DOVE_MBUS_PCIE1_IO_ATTR       0xe0
+#define DOVE_MBUS_CESA_TARGET         0x3
+#define DOVE_MBUS_CESA_ATTR           0x1
+#define DOVE_MBUS_BOOTROM_TARGET      0x1
+#define DOVE_MBUS_BOOTROM_ATTR        0xfd
+#define DOVE_MBUS_SCRATCHPAD_TARGET   0xd
+#define DOVE_MBUS_SCRATCHPAD_ATTR     0x0
+
 /*****************************************************************************
  * I/O Address Mapping
  ****************************************************************************/
@@ -332,34 +348,40 @@ void __init dove_setup_cpu_wins(void)
 {
 	/*
 	 * The PCIe windows will no longer be statically allocated
-	 * here once Dove is migrated to the pci-mvebu driver.
+	 * here once Dove is migrated to the pci-mvebu driver. The
+	 * non-PCIe windows will no longer be created here once Dove
+	 * fully moves to DT.
 	 */
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
+	mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE0_IO_TARGET,
+					  DOVE_MBUS_PCIE0_IO_ATTR,
 					  DOVE_PCIE0_IO_PHYS_BASE,
 					  DOVE_PCIE0_IO_SIZE,
-					  DOVE_PCIE0_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
+					  DOVE_PCIE0_IO_BUS_BASE);
+	mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE1_IO_TARGET,
+					  DOVE_MBUS_PCIE1_IO_ATTR,
 					  DOVE_PCIE1_IO_PHYS_BASE,
 					  DOVE_PCIE1_IO_SIZE,
-					  DOVE_PCIE1_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
-					  DOVE_PCIE0_MEM_PHYS_BASE,
-					  DOVE_PCIE0_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
-					  DOVE_PCIE1_MEM_PHYS_BASE,
-					  DOVE_PCIE1_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window("cesa", DOVE_CESA_PHYS_BASE,
-			      DOVE_CESA_SIZE);
-	mvebu_mbus_add_window("bootrom", DOVE_BOOTROM_PHYS_BASE,
-			      DOVE_BOOTROM_SIZE);
-	mvebu_mbus_add_window("scratchpad", DOVE_SCRATCHPAD_PHYS_BASE,
-			      DOVE_SCRATCHPAD_SIZE);
+					  DOVE_PCIE1_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE0_MEM_TARGET,
+				    DOVE_MBUS_PCIE0_MEM_ATTR,
+				    DOVE_PCIE0_MEM_PHYS_BASE,
+				    DOVE_PCIE0_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE1_MEM_TARGET,
+				    DOVE_MBUS_PCIE1_MEM_ATTR,
+				    DOVE_PCIE1_MEM_PHYS_BASE,
+				    DOVE_PCIE1_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_CESA_TARGET,
+				    DOVE_MBUS_CESA_ATTR,
+				    DOVE_CESA_PHYS_BASE,
+				    DOVE_CESA_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_BOOTROM_TARGET,
+				    DOVE_MBUS_BOOTROM_ATTR,
+				    DOVE_BOOTROM_PHYS_BASE,
+				    DOVE_BOOTROM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_SCRATCHPAD_TARGET,
+				    DOVE_MBUS_SCRATCHPAD_ATTR,
+				    DOVE_SCRATCHPAD_PHYS_BASE,
+				    DOVE_SCRATCHPAD_SIZE);
 }
 
 void __init dove_init(void)
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:09 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:09 -0300
Subject: [PATCH v7 07/22] bus: mvebu-mbus: Factor out initialization details
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-8-git-send-email-ezequiel.garcia@free-electrons.com>

We introduce a common initialization function mvebu_mbus_common_init()
that will be used by both legacy and device-tree initialization code.
This patch is an intermediate step, which will allow to introduce the
DT binding for this driver in a less intrusive way.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 47 ++++++++++++++++++++++++++++++-----------------
 1 file changed, 30 insertions(+), 17 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 827468a..1b17954 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -847,26 +847,14 @@ static __init int mvebu_mbus_debugfs_init(void)
 }
 fs_initcall(mvebu_mbus_debugfs_init);
 
-int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
-			   size_t mbuswins_size,
-			   phys_addr_t sdramwins_phys_base,
-			   size_t sdramwins_size)
+static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
+					 phys_addr_t mbuswins_phys_base,
+					 size_t mbuswins_size,
+					 phys_addr_t sdramwins_phys_base,
+					 size_t sdramwins_size)
 {
-	struct mvebu_mbus_state *mbus = &mbus_state;
-	const struct of_device_id *of_id;
 	int win;
 
-	for (of_id = of_mvebu_mbus_ids; of_id->compatible; of_id++)
-		if (!strcmp(of_id->compatible, soc))
-			break;
-
-	if (!of_id->compatible) {
-		pr_err("could not find a matching SoC family\n");
-		return -ENODEV;
-	}
-
-	mbus->soc = of_id->data;
-
 	mbus->mbuswins_base = ioremap(mbuswins_phys_base, mbuswins_size);
 	if (!mbus->mbuswins_base)
 		return -ENOMEM;
@@ -887,3 +875,28 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 
 	return 0;
 }
+
+int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
+			   size_t mbuswins_size,
+			   phys_addr_t sdramwins_phys_base,
+			   size_t sdramwins_size)
+{
+	const struct of_device_id *of_id;
+
+	for (of_id = of_mvebu_mbus_ids; of_id->compatible; of_id++)
+		if (!strcmp(of_id->compatible, soc))
+			break;
+
+	if (!of_id->compatible) {
+		pr_err("could not find a matching SoC family\n");
+		return -ENODEV;
+	}
+
+	mbus_state.soc = of_id->data;
+
+	return mvebu_mbus_common_init(&mbus_state,
+			mbuswins_phys_base,
+			mbuswins_size,
+			sdramwins_phys_base,
+			sdramwins_size);
+}
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:11 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:11 -0300
Subject: [PATCH v7 09/22] bus: mvebu-mbus: Add static window allocation to the
 DT binding
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-10-git-send-email-ezequiel.garcia@free-electrons.com>

This patch adds static window allocation to the device tree binding.
Each first-child of the mbus-compatible node, with a suitable 'ranges'
property, declaring an address translation, will trigger an address
decoding window allocation.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 .../devicetree/bindings/bus/mvebu-mbus.txt         | 253 +++++++++++++++++++++
 drivers/bus/mvebu-mbus.c                           | 121 +++++++++-
 2 files changed, 373 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt

diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
new file mode 100644
index 0000000..cce863f
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -0,0 +1,253 @@
+
+* Marvell MBus
+
+Required properties:
+
+- compatible:	 Should be set to one of the following:
+		 marvell,armada370-mbus
+		 marvell,armadaxp-mbus
+
+- address-cells: Must be '2'. The first cell for the MBus ID encoding,
+                 the second cell for the address offset within the window.
+
+- size-cells:    Must be '1'.
+
+- ranges:        Must be set up to provide a proper translation for each child.
+	         See the examples below.
+
+- controller:    Contains a single phandle referring to the MBus controller
+                 node. This allows to specify the node that contains the
+		 registers that control the MBus, which is typically contained
+		 within the internal register window (see below).
+
+* Marvell MBus controller
+
+Required properties:
+
+- compatible:	Should be set to "marvell,mbus-controller".
+
+- reg:          Device's register space.
+		Two entries are expected (see the examples below):
+		the first one controls the devices decoding window and
+		the second one controls the SDRAM decoding window.
+
+Example:
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+
+		internal-regs {
+			compatible = "simple-bus";
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* more children ...*/
+		};
+	};
+
+** MBus address decoding window specification
+
+The MBus children address space is comprised of two cells: the first one for
+the window ID and the second one for the offset within the window.
+In order to allow to describe valid and non-valid window entries, the
+following encoding is used:
+
+  0xSIAA0000 0x00oooooo
+
+Where:
+
+  S = 0x0 for a MBus valid window
+  S = 0xf for a non-valid window (see below)
+
+If S = 0x0, then:
+
+   I = 4-bit window target ID
+  AA = windpw attribute
+
+If S = 0xf, then:
+
+   I = don't care
+   AA = 1 for internal register
+
+Following the above encoding, for each ranges entry for a MBus valid window
+(S = 0x0), an address decoding window is allocated. On the other side,
+entries for translation that do not correspond to valid windows (S = 0xf)
+are skipped.
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+
+		ranges = <0xf0010000 0 0 0xd0000000 0x100000
+			  0x01e00000 0 0 0xfff00000 0x100000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <0x01e00000 0 0x100000>;
+		};
+
+		/* other children */
+		...
+
+		internal-regs {
+			compatible = "simple-bus";
+			ranges = <0 0xf0010000 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* more children ...*/
+		};
+	};
+
+In the shown example, the translation entry in the 'ranges' property is what
+makes the MBus driver create a static decoding window for the corresponding
+given child device. Note that the binding does not require child nodes to be
+present. Of course, child nodes are needed to probe the devices.
+
+Since each window is identified by its target ID and attribute ID there's
+a special macro that can be use to simplify the translation entries:
+
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
+Using this macro, the above example would be:
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+
+		ranges = < MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			   MBUS_ID(0x01, 0xe0) 0 0 0xfff00000 0x100000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
+		};
+
+		/* other children */
+		...
+
+		internal-regs {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* other children */
+			...
+		};
+	};
+
+
+** About the window base address
+
+Remember the MBus controller allows a great deal of flexibility for choosing
+the decoding window base address. When planning the device tree layout it's
+possible to choose any address as the base address, provided of course there's
+a region large enough available, and with the required alignment.
+
+Yet in other words: there's nothing preventing us from setting a base address
+of 0xf0000000, or 0xd0000000 for the NOR device shown above, if such region is
+unused.
+
+** Window allocation policy
+
+The mbus-node ranges property defines a set of mbus windows that are expected
+to be set by the operating system and that are guaranteed to be free of overlaps
+with one another or with the system memory ranges.
+
+Each entry in the property refers to exactly one window. If the operating system
+choses to use a different set of mbus windows, it must ensure that any address
+translations performed from downstream devices are adapted accordingly.
+
+The operating system may insert additional mbus windows that do not conflict
+with the ones listed in the ranges, e.g. for mapping PCIe devices.
+As a special case, the internal register window must be set up by the boot
+loader at the address listed in the ranges property, since access to that region
+is needed to set up the other windows.
+
+** Example
+
+See the example below, where a more complete device tree is shown:
+
+	soc {
+		compatible = "marvell,armadaxp-mbus", "simple-bus";
+		controller = <&mbusc>;
+
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
+		};
+
+		devbus-bootcs {
+			status = "okay";
+			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;
+
+			/* NOR */
+			nor {
+				compatible = "cfi-flash";
+				reg = <0 0x8000000>;
+				bank-width = <2>;
+			};
+		};
+
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "okay";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
+				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>;
+
+
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+		};
+
+		internal-regs {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			interrupt-controller at 20000 {
+			      reg = <0x20a00 0x2d0>, <0x21070 0x58>;
+			};
+		};
+	};
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 44a07c4..8aa3b45 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -902,6 +902,121 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 }
 
 #ifdef CONFIG_OF
+/*
+ * The window IDs in the ranges DT property have the following format:
+ *  - bits 28 to 31: MBus custom field
+ *  - bits 24 to 27: window target ID
+ *  - bits 16 to 23: window attribute ID
+ *  - bits  0 to 15: unused
+ */
+#define CUSTOM(id) (((id) & 0xF0000000) >> 24)
+#define TARGET(id) (((id) & 0x0F000000) >> 24)
+#define ATTR(id)   (((id) & 0x00FF0000) >> 16)
+
+static int __init mbus_dt_setup_win(struct mvebu_mbus_state *mbus,
+				    u32 base, u32 size,
+				    u8 target, u8 attr)
+{
+	const struct mvebu_mbus_mapping *map = mbus->soc->map;
+	const char *name;
+	int i;
+
+	/* Search for a suitable window in the existing mappings */
+	for (i = 0; map[i].name; i++)
+		if (map[i].target == target &&
+		    map[i].attr == (attr & map[i].attrmask))
+			break;
+
+	name = map[i].name;
+	if (!name) {
+		pr_err("window 0x%x:0x%x is unknown, skipping\n",
+		       target, attr);
+		return -EINVAL;
+	}
+
+	if (!mvebu_mbus_window_conflicts(mbus, base, size, target, attr)) {
+		pr_err("cannot add window '%s', conflicts with another window\n",
+		       name);
+		return -EBUSY;
+	}
+
+	if (mvebu_mbus_alloc_window(mbus, base, size, MVEBU_MBUS_NO_REMAP,
+				    target, attr)) {
+		pr_err("cannot add window '%s', too many windows\n",
+		       name);
+		return -ENOMEM;
+	}
+	return 0;
+}
+
+static int __init
+mbus_parse_ranges(struct device_node *node,
+		  int *addr_cells, int *c_addr_cells, int *c_size_cells,
+		  int *cell_count, const __be32 **ranges_start,
+		  const __be32 **ranges_end)
+{
+	const __be32 *prop;
+	int ranges_len, tuple_len;
+
+	*addr_cells = of_n_addr_cells(node);
+
+	prop = of_get_property(node, "#address-cells", NULL);
+	*c_addr_cells = be32_to_cpup(prop);
+
+	prop = of_get_property(node, "#size-cells", NULL);
+	*c_size_cells = be32_to_cpup(prop);
+
+	*cell_count = *addr_cells + *c_addr_cells + *c_size_cells;
+	tuple_len = (*cell_count) * sizeof(__be32);
+
+	*ranges_start = of_get_property(node, "ranges", &ranges_len);
+	*ranges_end = *ranges_start + ranges_len / sizeof(__be32);
+
+	if (*ranges_start == NULL || ranges_len % tuple_len) {
+		pr_warn("malformed ranges entry '%s'\n", node->name);
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static int __init mbus_dt_setup(struct mvebu_mbus_state *mbus,
+				struct device_node *np)
+{
+	int addr_cells, c_addr_cells, c_size_cells;
+	int i, ret, cell_count;
+	const __be32 *r, *ranges_start, *ranges_end;
+
+	ret = mbus_parse_ranges(np, &addr_cells, &c_addr_cells,
+				&c_size_cells, &cell_count,
+				&ranges_start, &ranges_end);
+	if (ret < 0)
+		return ret;
+
+	for (i = 0, r = ranges_start; r < ranges_end; r += cell_count, i++) {
+		u32 windowid, base, size;
+		u8 target, attr;
+
+		/*
+		 * An entry with a non-zero custom field do not
+		 * correspond to a static window, so skip it.
+		 */
+		windowid = of_read_number(r, 1);
+		if (CUSTOM(windowid))
+			continue;
+
+		target = TARGET(windowid);
+		attr = ATTR(windowid);
+
+		base = of_read_number(r + c_addr_cells, addr_cells);
+		size = of_read_number(r + c_addr_cells + addr_cells,
+				      c_size_cells);
+		ret = mbus_dt_setup_win(mbus, base, size, target, attr);
+		if (ret < 0)
+			return ret;
+	}
+	return 0;
+}
+
 int __init mvebu_mbus_dt_init(void)
 {
 	struct resource mbuswins_res, sdramwins_res;
@@ -946,6 +1061,10 @@ int __init mvebu_mbus_dt_init(void)
 				     resource_size(&mbuswins_res),
 				     sdramwins_res.start,
 				     resource_size(&sdramwins_res));
-	return ret;
+	if (ret)
+		return ret;
+
+	/* Setup statically declared windows in the DT */
+	return mbus_dt_setup(&mbus_state, np);
 }
 #endif
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:10 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:10 -0300
Subject: [PATCH v7 08/22] bus: mvebu-mbus: Introduce device tree binding
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-9-git-send-email-ezequiel.garcia@free-electrons.com>

This patch adds the most fundamental device-tree initialization.
We only introduce what's required to be able to probe the mvebu-mbus
driver from the DT. Follow-up patches will extend the device tree binding,
allowing to describe static address decoding windows.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mbus.h     |  1 +
 2 files changed, 50 insertions(+)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 1b17954..44a07c4 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -900,3 +900,52 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 			sdramwins_phys_base,
 			sdramwins_size);
 }
+
+#ifdef CONFIG_OF
+int __init mvebu_mbus_dt_init(void)
+{
+	struct resource mbuswins_res, sdramwins_res;
+	struct device_node *np, *controller;
+	const struct of_device_id *of_id;
+	const __be32 *prop;
+	int ret;
+
+	np = of_find_matching_node(NULL, of_mvebu_mbus_ids);
+	if (!np) {
+		pr_err("could not find a matching SoC family\n");
+		return -ENODEV;
+	}
+
+	of_id = of_match_node(of_mvebu_mbus_ids, np);
+	mbus_state.soc = of_id->data;
+
+	prop = of_get_property(np, "controller", NULL);
+	if (!prop) {
+		pr_err("required 'controller' property missing\n");
+		return -EINVAL;
+	}
+
+	controller = of_find_node_by_phandle(be32_to_cpup(prop));
+	if (!controller) {
+		pr_err("could not find an 'mbus-controller' node\n");
+		return -ENODEV;
+	}
+
+	if (of_address_to_resource(controller, 0, &mbuswins_res)) {
+		pr_err("cannot get MBUS register address\n");
+		return -EINVAL;
+	}
+
+	if (of_address_to_resource(controller, 1, &sdramwins_res)) {
+		pr_err("cannot get SDRAM register address\n");
+		return -EINVAL;
+	}
+
+	ret = mvebu_mbus_common_init(&mbus_state,
+				     mbuswins_res.start,
+				     resource_size(&mbuswins_res),
+				     sdramwins_res.start,
+				     resource_size(&sdramwins_res));
+	return ret;
+}
+#endif
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 9245b66..eadefd6 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -74,5 +74,6 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size);
 int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
 		    size_t mbus_size, phys_addr_t sdram_phys_base,
 		    size_t sdram_size);
+int mvebu_mbus_dt_init(void);
 
 #endif /* __LINUX_MBUS_H */
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:13 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:13 -0300
Subject: [PATCH v7 11/22] PCI: mvebu: Adapt to the new device tree layout
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-12-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

The new device tree layout encodes the window's target ID and attribute
in the PCIe controller node's ranges property. This allows to parse
such entries to obtain such information and use the recently introduced
MBus API to create the windows, instead of using the current name based
scheme.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../devicetree/bindings/pci/mvebu-pci.txt          | 145 ++++++++++++++++-----
 drivers/pci/host/pci-mvebu.c                       | 113 +++++++++++-----
 2 files changed, 193 insertions(+), 65 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index f8d4058..9556e2f 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -1,6 +1,7 @@
 * Marvell EBU PCIe interfaces
 
 Mandatory properties:
+
 - compatible: one of the following values:
     marvell,armada-370-pcie
     marvell,armada-xp-pcie
@@ -10,11 +11,49 @@ Mandatory properties:
 - #interrupt-cells, set to <1>
 - bus-range: PCI bus numbers covered
 - device_type, set to "pci"
-- ranges: ranges for the PCI memory and I/O regions, as well as the
-  MMIO registers to control the PCIe interfaces.
+- ranges: ranges describing the MMIO registers to control the PCIe
+  interfaces, and ranges describing the MBus windows needed to access
+  the memory and I/O regions of each PCIe interface.
+
+The ranges describing the MMIO registers have the following layout:
+
+    0x82000000 0 r MBUS_ID(0xf0, 0x01) r 0 s
+
+where:
+
+  * r is a 32-bits value that gives the offset of the MMIO
+  registers of this PCIe interface, from the base of the internal
+  registers.
+
+  * s is a 32-bits value that give the size of this MMIO
+  registers area. This range entry translates the '0x82000000 0 r' PCI
+  address into the 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part
+  of the internal register window (as identified by MBUS_ID(0xf0,
+  0x01)).
+
+The ranges describing the MBus windows have the following layout:
+
+    0x8t000000 s 0     MBUS_ID(w, a) 0 1 0
+
+where:
+
+   * t is the type of the MBus window (as defined by the standard PCI DT
+   bindings), 1 for I/O and 2 for memory.
 
-In addition, the Device Tree node must have sub-nodes describing each
+   * s is the PCI slot that corresponds to this PCIe interface
+
+   * w is the 'target ID' value for the MBus window
+
+   * a the 'attribute' value for the MBus window.
+
+Since the location and size of the different MBus windows is not fixed in
+hardware, and only determined in runtime, those ranges cover the full first
+4 GB of the physical address space, and do not translate into a valid CPU
+address.
+
+In addition, the device tree node must have sub-nodes describing each
 PCIe interface, having the following mandatory properties:
+
 - reg: used only for interrupt mapping, so only the first four bytes
   are used to refer to the correct bus number and device number.
 - assigned-addresses: reference to the MMIO registers used to control
@@ -26,7 +65,8 @@ PCIe interface, having the following mandatory properties:
 - #address-cells, set to <3>
 - #size-cells, set to <2>
 - #interrupt-cells, set to <1>
-- ranges, empty property.
+- ranges, translating the MBus windows ranges of the parent node into
+  standard PCI addresses.
 - interrupt-map-mask and interrupt-map, standard PCI properties to
   define the mapping of the PCIe interface to interrupt numbers.
 
@@ -47,27 +87,50 @@ pcie-controller {
 
 	bus-range = <0x00 0xff>;
 
-	ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
-		  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
-		  0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
-		  0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
-		  0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
-		  0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
-		  0x82000000 0 0xd0082000 0xd0082000 0 0x00002000   /* Port 3.0 registers */
-		  0x82000000 0 0xd0084000 0xd0084000 0 0x00002000   /* Port 1.1 registers */
-		  0x82000000 0 0xd0088000 0xd0088000 0 0x00002000   /* Port 1.2 registers */
-		  0x82000000 0 0xd008c000 0xd008c000 0 0x00002000   /* Port 1.3 registers */
-		  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-		  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
+	ranges =
+	       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000	/* Port 0.0 registers */
+		0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000	/* Port 2.0 registers */
+		0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000	/* Port 0.1 registers */
+		0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000	/* Port 0.2 registers */
+		0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000	/* Port 0.3 registers */
+		0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000	/* Port 1.0 registers */
+		0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000	/* Port 3.0 registers */
+		0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000	/* Port 1.1 registers */
+		0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000	/* Port 1.2 registers */
+		0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000	/* Port 1.3 registers */
+		0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+		0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+		0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+		0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+		0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+		0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+		0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+		0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+
+		0x82000000 0x5 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
+		0x81000000 0x5 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
+		0x82000000 0x6 0     MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */
+		0x81000000 0x6 0     MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO  */
+		0x82000000 0x7 0     MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */
+		0x81000000 0x7 0     MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO  */
+		0x82000000 0x8 0     MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */
+		0x81000000 0x8 0     MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO  */
+
+		0x82000000 0x9 0     MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
+		0x81000000 0x9 0     MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */
+
+		0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
+		0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
 
 	pcie at 1,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+		assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
 		reg = <0x0800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+			  0x81000000 0 0 0x81000000 0x1 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 58>;
 		marvell,pcie-port = <0>;
@@ -78,12 +141,13 @@ pcie-controller {
 
 	pcie at 2,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>;
+		assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
 		reg = <0x1000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+			  0x81000000 0 0 0x81000000 0x2 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 59>;
 		marvell,pcie-port = <0>;
@@ -94,12 +158,13 @@ pcie-controller {
 
 	pcie at 3,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>;
+		assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
 		reg = <0x1800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+			  0x81000000 0 0 0x81000000 0x3 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 60>;
 		marvell,pcie-port = <0>;
@@ -110,12 +175,13 @@ pcie-controller {
 
 	pcie at 4,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>;
+		assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
 		reg = <0x2000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+			  0x81000000 0 0 0x81000000 0x4 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 61>;
 		marvell,pcie-port = <0>;
@@ -126,12 +192,13 @@ pcie-controller {
 
 	pcie at 5,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
+		assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
 		reg = <0x2800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
+			  0x81000000 0 0 0x81000000 0x5 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 62>;
 		marvell,pcie-port = <1>;
@@ -142,12 +209,13 @@ pcie-controller {
 
 	pcie at 6,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>;
+		assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
 		reg = <0x3000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0
+			  0x81000000 0 0 0x81000000 0x6 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 63>;
 		marvell,pcie-port = <1>;
@@ -158,12 +226,13 @@ pcie-controller {
 
 	pcie at 7,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>;
+		assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
 		reg = <0x3800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0
+			  0x81000000 0 0 0x81000000 0x7 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 64>;
 		marvell,pcie-port = <1>;
@@ -174,12 +243,13 @@ pcie-controller {
 
 	pcie at 8,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>;
+		assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
 		reg = <0x4000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0
+			  0x81000000 0 0 0x81000000 0x8 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 65>;
 		marvell,pcie-port = <1>;
@@ -187,14 +257,16 @@ pcie-controller {
 		clocks = <&gateclk 12>;
 		status = "disabled";
 	};
+
 	pcie at 9,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>;
+		assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
 		reg = <0x4800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+			  0x81000000 0 0 0x81000000 0x9 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 99>;
 		marvell,pcie-port = <2>;
@@ -205,12 +277,13 @@ pcie-controller {
 
 	pcie at 10,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>;
+		assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
 		reg = <0x5000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
+			  0x81000000 0 0 0x81000000 0xa 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 103>;
 		marvell,pcie-port = <3>;
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 13a633b..424a7b8 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -123,6 +123,10 @@ struct mvebu_pcie_port {
 	u32 port;
 	u32 lane;
 	int devfn;
+	unsigned int mem_target;
+	unsigned int mem_attr;
+	unsigned int io_target;
+	unsigned int io_attr;
 	struct clk *clk;
 	struct mvebu_sw_pci_bridge bridge;
 	struct device_node *dn;
@@ -307,10 +311,9 @@ static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port *port)
 			    (port->bridge.iolimitupper << 16)) -
 			    iobase);
 
-	mvebu_mbus_add_window_remap_flags(port->name, port->iowin_base,
-					  port->iowin_size,
-					  iobase,
-					  MVEBU_MBUS_PCI_IO);
+	mvebu_mbus_add_window_remap_by_id(port->io_target, port->io_attr,
+					  port->iowin_base, port->iowin_size,
+					  iobase);
 
 	pci_ioremap_io(iobase, port->iowin_base);
 }
@@ -342,10 +345,8 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
 		(((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) -
 		port->memwin_base;
 
-	mvebu_mbus_add_window_remap_flags(port->name, port->memwin_base,
-					  port->memwin_size,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+	mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr,
+				    port->memwin_base, port->memwin_size);
 }
 
 /*
@@ -755,12 +756,54 @@ mvebu_pcie_map_registers(struct platform_device *pdev,
 	return devm_request_and_ioremap(&pdev->dev, &regs);
 }
 
+#define DT_FLAGS_TO_TYPE(flags)       (((flags) >> 24) & 0x03)
+#define    DT_TYPE_IO                 0x1
+#define    DT_TYPE_MEM32              0x2
+#define DT_CPUADDR_TO_TARGET(cpuaddr) (((cpuaddr) >> 56) & 0xFF)
+#define DT_CPUADDR_TO_ATTR(cpuaddr)   (((cpuaddr) >> 48) & 0xFF)
+
+static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
+			      unsigned long type, int *tgt, int *attr)
+{
+	const int na = 3, ns = 2;
+	const __be32 *range;
+	int rlen, nranges, rangesz, pna, i;
+
+	range = of_get_property(np, "ranges", &rlen);
+	if (!range)
+		return -EINVAL;
+
+	pna = of_n_addr_cells(np);
+	rangesz = pna + na + ns;
+	nranges = rlen / sizeof(__be32) / rangesz;
+
+	for (i = 0; i < nranges; i++) {
+		u32 flags = of_read_number(range, 1);
+		u32 slot = of_read_number(range, 2);
+		u64 cpuaddr = of_read_number(range + na, pna);
+		unsigned long rtype;
+
+		if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_IO)
+			rtype = IORESOURCE_IO;
+		else if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_MEM32)
+			rtype = IORESOURCE_MEM;
+
+		if (slot == PCI_SLOT(devfn) && type == rtype) {
+			*tgt = DT_CPUADDR_TO_TARGET(cpuaddr);
+			*attr = DT_CPUADDR_TO_ATTR(cpuaddr);
+			return 0;
+		}
+
+		range += rangesz;
+	}
+
+	return -ENOENT;
+}
+
 static int __init mvebu_pcie_probe(struct platform_device *pdev)
 {
 	struct mvebu_pcie *pcie;
 	struct device_node *np = pdev->dev.of_node;
-	struct of_pci_range range;
-	struct of_pci_range_parser parser;
 	struct device_node *child;
 	int i, ret;
 
@@ -771,29 +814,25 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
 
 	pcie->pdev = pdev;
 
-	if (of_pci_range_parser_init(&parser, np))
+	/* Get the PCIe memory and I/O aperture */
+	mvebu_mbus_get_pcie_mem_aperture(&pcie->mem);
+	if (resource_size(&pcie->mem) == 0) {
+		dev_err(&pdev->dev, "invalid memory aperture size\n");
 		return -EINVAL;
+	}
 
-	/* Get the I/O and memory ranges from DT */
-	for_each_of_pci_range(&parser, &range) {
-		unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
-		if (restype == IORESOURCE_IO) {
-			of_pci_range_to_resource(&range, np, &pcie->io);
-			of_pci_range_to_resource(&range, np, &pcie->realio);
-			pcie->io.name = "I/O";
-			pcie->realio.start = max_t(resource_size_t,
-						   PCIBIOS_MIN_IO,
-						   range.pci_addr);
-			pcie->realio.end = min_t(resource_size_t,
-						 IO_SPACE_LIMIT,
-						 range.pci_addr + range.size);
-		}
-		if (restype == IORESOURCE_MEM) {
-			of_pci_range_to_resource(&range, np, &pcie->mem);
-			pcie->mem.name = "MEM";
-		}
+	mvebu_mbus_get_pcie_io_aperture(&pcie->io);
+	if (resource_size(&pcie->io) == 0) {
+		dev_err(&pdev->dev, "invalid I/O aperture size\n");
+		return -EINVAL;
 	}
 
+	pcie->realio.flags = pcie->io.flags;
+	pcie->realio.start = PCIBIOS_MIN_IO;
+	pcie->realio.end = min_t(resource_size_t,
+				  IO_SPACE_LIMIT,
+				  resource_size(&pcie->io));
+
 	/* Get the bus range */
 	ret = of_pci_parse_bus_range(np, &pcie->busn);
 	if (ret) {
@@ -841,6 +880,22 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
 		if (port->devfn < 0)
 			continue;
 
+		ret = mvebu_get_tgt_attr(np, port->devfn, IORESOURCE_MEM,
+					 &port->mem_target, &port->mem_attr);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "PCIe%d.%d: cannot get tgt/attr for mem window\n",
+				port->port, port->lane);
+			continue;
+		}
+
+		ret = mvebu_get_tgt_attr(np, port->devfn, IORESOURCE_IO,
+					 &port->io_target, &port->io_attr);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "PCIe%d.%d: cannot get tgt/attr for io window\n",
+				port->port, port->lane);
+			continue;
+		}
+
 		port->base = mvebu_pcie_map_registers(pdev, child, port);
 		if (!port->base) {
 			dev_err(&pdev->dev, "PCIe%d.%d: cannot map registers\n",
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:12 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:12 -0300
Subject: [PATCH v7 10/22] bus: mvebu-mbus: Add new API for the PCIe memory and
 IO aperture
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-11-git-send-email-ezequiel.garcia@free-electrons.com>

We add two optional properties to the MBus DT binding, to encode
the PCIe memory and IO aperture. This allows such information to
be retrieved by -for instance- the pci driver to allocate the
MBus decoding windows.

Correspondingly, and in order to retrieve this information,
we add two new APIs.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 .../devicetree/bindings/bus/mvebu-mbus.txt         | 14 +++++++
 drivers/bus/mvebu-mbus.c                           | 49 ++++++++++++++++++++++
 include/linux/mbus.h                               |  4 ++
 3 files changed, 67 insertions(+)

diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
index cce863f..960186f 100644
--- a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -20,6 +20,18 @@ Required properties:
 		 registers that control the MBus, which is typically contained
 		 within the internal register window (see below).
 
+Optional properties:
+
+- pcie-mem-aperture:	This optional property contains the aperture for
+			the memory region of the PCIe driver.
+			If it's defined, it must encode the base address and
+			size for the address decoding windows allocated for
+			the PCIe memory region.
+
+- pcie-io-aperture:	Just as explained for the above property, this
+			optional property contains the aperture for the
+			I/O region of the PCIe driver.
+
 * Marvell MBus controller
 
 Required properties:
@@ -38,6 +50,8 @@ Example:
 		#address-cells = <2>;
 		#size-cells = <1>;
 		controller = <&mbusc>;
+		pcie-mem-aperture = <0xe0000000 0x8000000>;
+		pcie-io-aperture  = <0xe8000000 0x100000>;
 
 		internal-regs {
 			compatible = "simple-bus";
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 8aa3b45..5f0bfa3 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -142,6 +142,8 @@ struct mvebu_mbus_state {
 	struct dentry *debugfs_root;
 	struct dentry *debugfs_sdram;
 	struct dentry *debugfs_devs;
+	struct resource pcie_mem_aperture;
+	struct resource pcie_io_aperture;
 	const struct mvebu_mbus_soc_data *soc;
 	int hw_io_coherency;
 };
@@ -821,6 +823,20 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size)
 	return 0;
 }
 
+void mvebu_mbus_get_pcie_mem_aperture(struct resource *res)
+{
+	if (!res)
+		return;
+	*res = mbus_state.pcie_mem_aperture;
+}
+
+void mvebu_mbus_get_pcie_io_aperture(struct resource *res)
+{
+	if (!res)
+		return;
+	*res = mbus_state.pcie_io_aperture;
+}
+
 static __init int mvebu_mbus_debugfs_init(void)
 {
 	struct mvebu_mbus_state *s = &mbus_state;
@@ -1017,6 +1033,35 @@ static int __init mbus_dt_setup(struct mvebu_mbus_state *mbus,
 	return 0;
 }
 
+static void __init mvebu_mbus_get_pcie_resources(struct device_node *np,
+						 struct resource *mem,
+						 struct resource *io)
+{
+	u32 reg[2];
+	int ret;
+
+	/*
+	 * These are optional, so we clear them and they'll
+	 * be zero if they are missing from the DT.
+	 */
+	memset(mem, 0, sizeof(struct resource));
+	memset(io, 0, sizeof(struct resource));
+
+	ret = of_property_read_u32_array(np, "pcie-mem-aperture", reg, ARRAY_SIZE(reg));
+	if (!ret) {
+		mem->start = reg[0];
+		mem->end = mem->start + reg[1];
+		mem->flags = IORESOURCE_MEM;
+	}
+
+	ret = of_property_read_u32_array(np, "pcie-io-aperture", reg, ARRAY_SIZE(reg));
+	if (!ret) {
+		io->start = reg[0];
+		io->end = io->start + reg[1];
+		io->flags = IORESOURCE_IO;
+	}
+}
+
 int __init mvebu_mbus_dt_init(void)
 {
 	struct resource mbuswins_res, sdramwins_res;
@@ -1056,6 +1101,10 @@ int __init mvebu_mbus_dt_init(void)
 		return -EINVAL;
 	}
 
+	/* Get optional pcie-{mem,io}-aperture properties */
+	mvebu_mbus_get_pcie_resources(np, &mbus_state.pcie_mem_aperture,
+					  &mbus_state.pcie_io_aperture);
+
 	ret = mvebu_mbus_common_init(&mbus_state,
 				     mbuswins_res.start,
 				     resource_size(&mbuswins_res),
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index eadefd6..650bc15 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -11,6 +11,8 @@
 #ifndef __LINUX_MBUS_H
 #define __LINUX_MBUS_H
 
+struct resource;
+
 struct mbus_dram_target_info
 {
 	/*
@@ -59,6 +61,8 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
 }
 #endif
 
+void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
+void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
 int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 				      size_t size, phys_addr_t remap,
 				      unsigned int flags);
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:14 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:14 -0300
Subject: [PATCH v7 12/22] bus: mvebu-mbus: Remove the no longer used
 name-based API
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-13-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Now that every user of the deprecated name-based API has been
converted to using the ID-based API, let's remove the former one.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 38 --------------------------------------
 include/linux/mbus.h     |  5 -----
 2 files changed, 43 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 5f0bfa3..9aee344 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -766,44 +766,6 @@ int mvebu_mbus_add_window_remap_by_id(unsigned int target,
 	return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
 }
 
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
-				      size_t size, phys_addr_t remap,
-				      unsigned int flags)
-{
-	struct mvebu_mbus_state *s = &mbus_state;
-	u8 target, attr;
-	int i;
-
-	if (!s->soc->map)
-		return -ENODEV;
-
-	for (i = 0; s->soc->map[i].name; i++)
-		if (!strcmp(s->soc->map[i].name, devname))
-			break;
-
-	if (!s->soc->map[i].name) {
-		pr_err("unknown device '%s'\n", devname);
-		return -ENODEV;
-	}
-
-	target = s->soc->map[i].target;
-	attr   = s->soc->map[i].attr;
-
-	if (flags == MVEBU_MBUS_PCI_MEM)
-		attr |= 0x8;
-	else if (flags == MVEBU_MBUS_PCI_WA)
-		attr |= 0x28;
-
-	return mvebu_mbus_add_window_remap_by_id(target, attr, base,
-						 size, remap);
-}
-
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
-{
-	return mvebu_mbus_add_window_remap_flags(devname, base, size,
-						 MVEBU_MBUS_NO_REMAP, 0);
-}
-
 int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
 				phys_addr_t base, size_t size)
 {
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 650bc15..345b8c5 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -63,15 +63,10 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
 
 void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
 void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
-				      size_t size, phys_addr_t remap,
-				      unsigned int flags);
 int mvebu_mbus_add_window_remap_by_id(unsigned int target,
 				      unsigned int attribute,
 				      phys_addr_t base, size_t size,
 				      phys_addr_t remap);
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
-			  size_t size);
 int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
 				phys_addr_t base, size_t size);
 int mvebu_mbus_del_window(phys_addr_t base, size_t size);
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:15 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:15 -0300
Subject: [PATCH v7 13/22] bus: mvebu-mbus: Remove name -> target,
 attribute mapping tables
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-14-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

This tables were used together with the name-based MBus window
creation API. Since that's has been removed, we can also remove
the tables.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 150 +++--------------------------------------------
 1 file changed, 7 insertions(+), 143 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 9aee344..e13d475 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -97,33 +97,6 @@
 
 #define DOVE_DDR_BASE_CS_OFF(n) ((n) << 4)
 
-struct mvebu_mbus_mapping {
-	const char *name;
-	u8 target;
-	u8 attr;
-	u8 attrmask;
-};
-
-/*
- * Masks used for the 'attrmask' field of mvebu_mbus_mapping. They
- * allow to get the real attribute value, discarding the special bits
- * used to select a PCI MEM region or a PCI WA region. This allows the
- * debugfs code to reverse-match the name of a device from its
- * target/attr values.
- *
- * For all devices except PCI, all bits of 'attr' must be
- * considered. For most SoCs, only bit 3 should be ignored (it allows
- * to select between PCI MEM and PCI I/O). On Orion5x however, there
- * is the special bit 5 to select a PCI WA region.
- */
-#define MAPDEF_NOMASK       0xff
-#define MAPDEF_PCIMASK      0xf7
-#define MAPDEF_ORIONPCIMASK 0xd7
-
-/* Macro used to define one mvebu_mbus_mapping entry */
-#define MAPDEF(__n, __t, __a, __m) \
-	{ .name = __n, .target = __t, .attr = __a, .attrmask = __m }
-
 struct mvebu_mbus_state;
 
 struct mvebu_mbus_soc_data {
@@ -133,7 +106,6 @@ struct mvebu_mbus_soc_data {
 	void (*setup_cpu_target)(struct mvebu_mbus_state *s);
 	int (*show_cpu_target)(struct mvebu_mbus_state *s,
 			       struct seq_file *seq, void *v);
-	const struct mvebu_mbus_mapping *map;
 };
 
 struct mvebu_mbus_state {
@@ -430,8 +402,7 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void *v)
 		u64 wbase, wremap;
 		u32 wsize;
 		u8 wtarget, wattr;
-		int enabled, i;
-		const char *name;
+		int enabled;
 
 		mvebu_mbus_read_window(mbus, win,
 				       &enabled, &wbase, &wsize,
@@ -442,18 +413,9 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void *v)
 			continue;
 		}
 
-
-		for (i = 0; mbus->soc->map[i].name; i++)
-			if (mbus->soc->map[i].target == wtarget &&
-			    mbus->soc->map[i].attr ==
-			    (wattr & mbus->soc->map[i].attrmask))
-				break;
-
-		name = mbus->soc->map[i].name ?: "unknown";
-
-		seq_printf(seq, "[%02d] %016llx - %016llx : %s",
+		seq_printf(seq, "[%02d] %016llx - %016llx : %04x:%04x",
 			   win, (unsigned long long)wbase,
-			   (unsigned long long)(wbase + wsize), name);
+			   (unsigned long long)(wbase + wsize), wtarget, wattr);
 
 		if (win < mbus->soc->num_remappable_wins) {
 			seq_printf(seq, " (remap %016llx)\n",
@@ -578,45 +540,12 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
 	mvebu_mbus_dram_info.num_cs = cs;
 }
 
-static const struct mvebu_mbus_mapping armada_370_map[] = {
-	MAPDEF("bootrom",     1, 0xe0, MAPDEF_NOMASK),
-	MAPDEF("devbus-boot", 1, 0x2f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x3e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x3d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x3b, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs3",  1, 0x37, MAPDEF_NOMASK),
-	MAPDEF("pcie0.0",     4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",     8, 0xe0, MAPDEF_PCIMASK),
-	{},
-};
-
 static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
 	.num_wins            = 20,
 	.num_remappable_wins = 8,
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = armada_370_map,
-};
-
-static const struct mvebu_mbus_mapping armada_xp_map[] = {
-	MAPDEF("bootrom",     1, 0x1d, MAPDEF_NOMASK),
-	MAPDEF("devbus-boot", 1, 0x2f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x3e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x3d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x3b, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs3",  1, 0x37, MAPDEF_NOMASK),
-	MAPDEF("pcie0.0",     4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.1",     4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.2",     4, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.3",     4, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",     8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.1",     8, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.2",     8, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.3",     8, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie2.0",     4, 0xf0, MAPDEF_PCIMASK),
-	MAPDEF("pcie3.0",     8, 0xf0, MAPDEF_PCIMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
@@ -625,15 +554,6 @@ static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = armada_xp_map,
-};
-
-static const struct mvebu_mbus_mapping kirkwood_map[] = {
-	MAPDEF("pcie0.0", 4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0", 4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("sram",    3, 0x01, MAPDEF_NOMASK),
-	MAPDEF("nand",    1, 0x2f, MAPDEF_NOMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data kirkwood_mbus_data = {
@@ -642,16 +562,6 @@ static const struct mvebu_mbus_soc_data kirkwood_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = kirkwood_map,
-};
-
-static const struct mvebu_mbus_mapping dove_map[] = {
-	MAPDEF("pcie0.0",    0x4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",    0x8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("cesa",       0x3, 0x01, MAPDEF_NOMASK),
-	MAPDEF("bootrom",    0x1, 0xfd, MAPDEF_NOMASK),
-	MAPDEF("scratchpad", 0xd, 0x0, MAPDEF_NOMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data dove_mbus_data = {
@@ -660,18 +570,6 @@ static const struct mvebu_mbus_soc_data dove_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_dove_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_dove,
-	.map                 = dove_map,
-};
-
-static const struct mvebu_mbus_mapping orion5x_map[] = {
-	MAPDEF("pcie0.0",     4, 0x51, MAPDEF_ORIONPCIMASK),
-	MAPDEF("pci0.0",      3, 0x51, MAPDEF_ORIONPCIMASK),
-	MAPDEF("devbus-boot", 1, 0x0f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x1e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x1d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x1b, MAPDEF_NOMASK),
-	MAPDEF("sram",        0, 0x00, MAPDEF_NOMASK),
-	{},
 };
 
 /*
@@ -684,7 +582,6 @@ static const struct mvebu_mbus_soc_data orion5x_4win_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = orion5x_map,
 };
 
 static const struct mvebu_mbus_soc_data orion5x_2win_mbus_data = {
@@ -693,21 +590,6 @@ static const struct mvebu_mbus_soc_data orion5x_2win_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = orion5x_map,
-};
-
-static const struct mvebu_mbus_mapping mv78xx0_map[] = {
-	MAPDEF("pcie0.0", 4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.1", 4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.2", 4, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.3", 4, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0", 8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.1", 8, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.2", 8, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.3", 8, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie2.0", 4, 0xf0, MAPDEF_PCIMASK),
-	MAPDEF("pcie3.0", 8, 0xf0, MAPDEF_PCIMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
@@ -716,7 +598,6 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
 	.win_cfg_offset      = mv78xx0_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = mv78xx0_map,
 };
 
 /*
@@ -895,33 +776,16 @@ static int __init mbus_dt_setup_win(struct mvebu_mbus_state *mbus,
 				    u32 base, u32 size,
 				    u8 target, u8 attr)
 {
-	const struct mvebu_mbus_mapping *map = mbus->soc->map;
-	const char *name;
-	int i;
-
-	/* Search for a suitable window in the existing mappings */
-	for (i = 0; map[i].name; i++)
-		if (map[i].target == target &&
-		    map[i].attr == (attr & map[i].attrmask))
-			break;
-
-	name = map[i].name;
-	if (!name) {
-		pr_err("window 0x%x:0x%x is unknown, skipping\n",
-		       target, attr);
-		return -EINVAL;
-	}
-
 	if (!mvebu_mbus_window_conflicts(mbus, base, size, target, attr)) {
-		pr_err("cannot add window '%s', conflicts with another window\n",
-		       name);
+		pr_err("cannot add window '%04x:%04x', conflicts with another window\n",
+		       target, attr);
 		return -EBUSY;
 	}
 
 	if (mvebu_mbus_alloc_window(mbus, base, size, MVEBU_MBUS_NO_REMAP,
 				    target, attr)) {
-		pr_err("cannot add window '%s', too many windows\n",
-		       name);
+		pr_err("cannot add window '%04x:%04x', too many windows\n",
+		       target, attr);
 		return -ENOMEM;
 	}
 	return 0;
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:16 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:16 -0300
Subject: [PATCH v7 14/22] bus: mvebu-mbus: Update main description
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-15-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

After replacing the MBus name-based by the new ID-based API
let's fix the general description of the driver at the beginning
of the file.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index e13d475..f6e9192 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -35,13 +35,9 @@
  *
  * - Provides an API for platform code or device drivers to
  *   dynamically add or remove address decoding windows for the CPU ->
- *   device accesses. This API is mvebu_mbus_add_window(),
- *   mvebu_mbus_add_window_remap_flags() and
- *   mvebu_mbus_del_window(). Since the (target, attribute) values
- *   differ from one SoC family to another, the API uses a 'const char
- *   *' string to identify devices, and this driver is responsible for
- *   knowing the mapping between the name of a device and its
- *   corresponding (target, attribute) in the current SoC family.
+ *   device accesses. This API is mvebu_mbus_add_window_by_id(),
+ *   mvebu_mbus_add_window_remap_by_id() and
+ *   mvebu_mbus_del_window().
  *
  * - Provides a debugfs interface in /sys/kernel/debug/mvebu-mbus/ to
  *   see the list of CPU -> SDRAM windows and their configuration
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:17 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:17 -0300
Subject: [PATCH v7 15/22] bus: mvebu-mbus: Factorize Armada 370/XP data
 structures
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-16-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

These structures were only different in the mapping tables.
Now that those tables have been removed, it doesn't make any sense
to keep different structures.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index f6e9192..d0a61ce 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -536,15 +536,7 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
 	mvebu_mbus_dram_info.num_cs = cs;
 }
 
-static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
-	.num_wins            = 20,
-	.num_remappable_wins = 8,
-	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
-	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
-	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-};
-
-static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
+static const struct mvebu_mbus_soc_data armada_370_xp_mbus_data = {
 	.num_wins            = 20,
 	.num_remappable_wins = 8,
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
@@ -604,9 +596,9 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
  */
 static const struct of_device_id of_mvebu_mbus_ids[] = {
 	{ .compatible = "marvell,armada370-mbus",
-	  .data = &armada_370_mbus_data, },
+	  .data = &armada_370_xp_mbus_data, },
 	{ .compatible = "marvell,armadaxp-mbus",
-	  .data = &armada_xp_mbus_data, },
+	  .data = &armada_370_xp_mbus_data, },
 	{ .compatible = "marvell,kirkwood-mbus",
 	  .data = &kirkwood_mbus_data, },
 	{ .compatible = "marvell,dove-mbus",
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:19 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:19 -0300
Subject: [PATCH v7 17/22] ARM: mvebu: Initialize MBus using the DT binding
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-18-git-send-email-ezequiel.garcia@free-electrons.com>

Now that the mbus device tree binding has been introduced, we can
switch over to it.

Also, and since the initialization of the mbus driver is quite
fundamental for the system to work properly, this patch adds a BUG()
in case mbus fails to initialize.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/mach-mvebu/armada-370-xp.c | 34 +---------------------------------
 1 file changed, 1 insertion(+), 33 deletions(-)

diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 97cbb80..829b573 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -34,44 +34,12 @@ static void __init armada_370_xp_map_io(void)
 	debug_ll_io_init();
 }
 
-/*
- * This initialization will be replaced by a DT-based
- * initialization once the mvebu-mbus driver gains DT support.
- */
-
-#define ARMADA_370_XP_MBUS_WINS_OFFS   0x20000
-#define ARMADA_370_XP_MBUS_WINS_SIZE   0x100
-#define ARMADA_370_XP_SDRAM_WINS_OFFS  0x20180
-#define ARMADA_370_XP_SDRAM_WINS_SIZE  0x20
-
-static void __init armada_370_xp_mbus_init(void)
-{
-	char *mbus_soc_name;
-	struct device_node *dn;
-	const __be32 mbus_wins_offs = cpu_to_be32(ARMADA_370_XP_MBUS_WINS_OFFS);
-	const __be32 sdram_wins_offs = cpu_to_be32(ARMADA_370_XP_SDRAM_WINS_OFFS);
-
-	if (of_machine_is_compatible("marvell,armada370"))
-		mbus_soc_name = "marvell,armada370-mbus";
-	else
-		mbus_soc_name = "marvell,armadaxp-mbus";
-
-	dn = of_find_node_by_name(NULL, "internal-regs");
-	BUG_ON(!dn);
-
-	mvebu_mbus_init(mbus_soc_name,
-			of_translate_address(dn, &mbus_wins_offs),
-			ARMADA_370_XP_MBUS_WINS_SIZE,
-			of_translate_address(dn, &sdram_wins_offs),
-			ARMADA_370_XP_SDRAM_WINS_SIZE);
-}
-
 static void __init armada_370_xp_timer_and_clk_init(void)
 {
 	of_clk_init(NULL);
 	armada_370_xp_timer_init();
 	coherency_init();
-	armada_370_xp_mbus_init();
+	BUG_ON(mvebu_mbus_dt_init());
 #ifdef CONFIG_CACHE_L2X0
 	l2x0_of_init(0, ~0UL);
 #endif
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:18 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:18 -0300
Subject: [PATCH v7 16/22] ARM: mvebu: Remove the harcoded BootROM window
 allocation
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-17-git-send-email-ezequiel.garcia@free-electrons.com>

The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/mach-mvebu/platsmp.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index ce81d30..7be1ec2 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -21,6 +21,7 @@
 #include <linux/smp.h>
 #include <linux/clk.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/mbus.h>
 #include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
@@ -29,6 +30,9 @@
 #include "pmsu.h"
 #include "coherency.h"
 
+#define AXP_BOOTROM_BASE 0xfff00000
+#define AXP_BOOTROM_SIZE 0x100000
+
 void __init set_secondary_cpus_clock(void)
 {
 	int thiscpu;
@@ -114,10 +118,29 @@ static void __init armada_xp_smp_init_cpus(void)
 
 void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
 {
+	struct device_node *node;
+	struct resource res;
+	int err;
+
 	set_secondary_cpus_clock();
 	flush_cache_all();
 	set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
-	mvebu_mbus_add_window("bootrom", 0xfff00000, SZ_1M);
+
+	/*
+	 * In order to boot the secondary CPUs we need to ensure
+	 * the bootROM is mapped at the correct address.
+	 */
+	node = of_find_compatible_node(NULL, NULL, "marvell,bootrom");
+	if (!node)
+		panic("Cannot find 'marvell,bootrom' compatible node");
+
+	err = of_address_to_resource(node, 0, &res);
+	if (err < 0)
+		panic("Cannot get 'bootrom' node address");
+
+	if (res.start != AXP_BOOTROM_BASE||
+	    resource_size(&res) != AXP_BOOTROM_SIZE)
+		panic("The address for the BootROM is incorrect");
 }
 
 struct smp_operations armada_xp_smp_ops __initdata = {
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:20 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:20 -0300
Subject: [PATCH v7 18/22] ARM: mvebu: Use the preprocessor on Armada 370/XP
 device tree files
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-19-git-send-email-ezequiel.garcia@free-electrons.com>

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              | 2 +-
 arch/arm/boot/dts/armada-370-mirabox.dts         | 2 +-
 arch/arm/boot/dts/armada-370-rd.dts              | 2 +-
 arch/arm/boot/dts/armada-370.dtsi                | 2 +-
 arch/arm/boot/dts/armada-xp-db.dts               | 2 +-
 arch/arm/boot/dts/armada-xp-gp.dts               | 2 +-
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         | 2 +-
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         | 2 +-
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 2 +-
 arch/arm/boot/dts/armada-xp.dtsi                 | 2 +-
 10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index beee169..55b986c 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Marvell Armada 370 Evaluation Board";
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 45b1077..37530af 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -9,7 +9,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Globalscale Mirabox";
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index a3a2fed..7aa2171 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -12,7 +12,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Marvell Armada 370 Reference Design";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..08ec6e3 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -15,7 +15,7 @@
  * common to all Armada SoCs.
  */
 
-/include/ "armada-370-xp.dtsi"
+#include "armada-370-xp.dtsi"
 /include/ "skeleton.dtsi"
 
 / {
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index e28e68f..a9bd766 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78460.dtsi"
+#include "armada-xp-mv78460.dtsi"
 
 / {
 	model = "Marvell Armada XP Evaluation Board";
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index c87b2de..54843e5 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78460.dtsi"
+#include "armada-xp-mv78460.dtsi"
 
 / {
 	model = "Marvell Armada XP Development Board DB-MV784MP-GP";
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2d9335d..985373a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -13,7 +13,7 @@
  * common to all Armada XP SoCs.
  */
 
-/include/ "armada-xp.dtsi"
+#include "armada-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP MV78260 SoC";
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index c7b1f4d..f8bf25a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -13,7 +13,7 @@
  * common to all Armada XP SoCs.
  */
 
-/include/ "armada-xp.dtsi"
+#include "armada-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP MV78460 SoC";
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 8f51045..d090264 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -11,7 +11,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78260.dtsi"
+#include "armada-xp-mv78260.dtsi"
 
 / {
 	model = "PlatHome OpenBlocks AX3-4 board";
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 416eb94..8c07bfe 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -16,7 +16,7 @@
  * common to all Armada SoCs.
  */
 
-/include/ "armada-370-xp.dtsi"
+#include "armada-370-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP family SoC";
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:21 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:21 -0300
Subject: [PATCH v7 19/22] ARM: mvebu: Add MBus to Armada 370/XP device tree
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-20-git-send-email-ezequiel.garcia@free-electrons.com>

The Armada 370/XP SoC family has a completely configurable address
space handled by the MBus controller.

This patch introduces the device tree layout of MBus, making the
'soc' node as mbus-compatible.
Since every peripheral/controller is a child of this 'soc' node,
this makes all of them sit behind the mbus, thus describing the
hardware accurately.

A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              |  2 ++
 arch/arm/boot/dts/armada-370-mirabox.dts         |  2 ++
 arch/arm/boot/dts/armada-370-rd.dts              |  2 ++
 arch/arm/boot/dts/armada-370-xp.dtsi             | 15 ++++++++++-----
 arch/arm/boot/dts/armada-370.dtsi                |  4 ++--
 arch/arm/boot/dts/armada-xp-db.dts               |  4 +---
 arch/arm/boot/dts/armada-xp-gp.dts               |  4 +---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  4 +---
 arch/arm/boot/dts/armada-xp.dtsi                 |  2 ++
 9 files changed, 23 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 55b986c..5920b4e 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,6 +30,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 37530af..a4202b6 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,6 +25,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index 7aa2171..dd0ba01 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,6 +28,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 90b1176..62639b4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -18,6 +18,8 @@
 
 /include/ "skeleton64.dtsi"
 
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
 / {
 	model = "Marvell Armada 370 and XP SoC";
 	compatible = "marvell,armada-370-xp";
@@ -38,18 +40,21 @@
 	};
 
 	soc {
-		#address-cells = <1>;
+		#address-cells = <2>;
 		#size-cells = <1>;
-		compatible = "simple-bus";
+		controller = <&mbusc>;
 		interrupt-parent = <&mpic>;
-		ranges = <0          0 0xd0000000 0x0100000 /* internal registers */
-			  0xe0000000 0 0xe0000000 0x8100000 /* PCIe */>;
 
 		internal-regs {
 			compatible = "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
-			ranges;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
 
 			mpic: interrupt-controller at 20000 {
 				compatible = "marvell,mpic";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 08ec6e3..4b54e51 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -29,8 +29,8 @@
 	};
 
 	soc {
-		ranges = <0          0xd0000000 0x0100000 /* internal registers */
-			  0xe0000000 0xe0000000 0x8100000 /* PCIe */>;
+		compatible = "marvell,armada370-mbus", "simple-bus";
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index a9bd766..0d4ce54 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,9 +30,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000	/* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000     /* PCIe */
-			  0xf0000000 0 0xf0000000 0x1000000>;	/* Device Bus, NOR 16MiB   */
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 54843e5..2fa9209 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,9 +39,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000  /* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000 /* PCIe */
-			  0xf0000000 0 0xf0000000 0x1000000 /* Device Bus, NOR 16MiB  */>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index d090264..a3e3a12 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,9 +27,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000	/* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000     /* PCIe */
-			  0xf0000000 0 0xf0000000 0x8000000     /* Device Bus, NOR 128MiB   */>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 8c07bfe..8033824 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -27,6 +27,8 @@
 	};
 
 	soc {
+		compatible = "marvell,armadaxp-mbus", "simple-bus";
+
 		internal-regs {
 			L2: l2-cache {
 				compatible = "marvell,aurora-system-cache";
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:22 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:22 -0300
Subject: [PATCH v7 20/22] ARM: mvebu: Add BootROM to Armada 370/XP device tree
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-21-git-send-email-ezequiel.garcia@free-electrons.com>

In order to access the SoC BootROM, we need to declare a mapping
(through a ranges property). The mbus driver will use this property
to allocate a suitable address decoding window.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              | 3 ++-
 arch/arm/boot/dts/armada-370-mirabox.dts         | 3 ++-
 arch/arm/boot/dts/armada-370-rd.dts              | 3 ++-
 arch/arm/boot/dts/armada-370.dtsi                | 5 +++++
 arch/arm/boot/dts/armada-xp-db.dts               | 3 ++-
 arch/arm/boot/dts/armada-xp-gp.dts               | 3 ++-
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 3 ++-
 arch/arm/boot/dts/armada-xp.dtsi                 | 5 +++++
 8 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 5920b4e..90ce29d 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,7 +30,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index a4202b6..19341d2 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,7 +25,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index dd0ba01..0b3acf3 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,7 +28,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 4b54e51..bd21d49 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -31,6 +31,11 @@
 	soc {
 		compatible = "marvell,armada370-mbus", "simple-bus";
 
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
+		};
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 0d4ce54..857f272 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,7 +30,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 2fa9209..934dc46 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,7 +39,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index a3e3a12..1700f6f 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,7 +27,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 8033824..7ba99ce 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -29,6 +29,11 @@
 	soc {
 		compatible = "marvell,armadaxp-mbus", "simple-bus";
 
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
+		};
+
 		internal-regs {
 			L2: l2-cache {
 				compatible = "marvell,aurora-system-cache";
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:24 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:24 -0300
Subject: [PATCH v7 22/22] ARM: mvebu: Relocate Armada 370/XP PCIe device tree
 nodes
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-23-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.

Moving the PCIe nodes, we now need to introduce an extra cell to
encode the window target ID and attribute. Since this depends on
the PCIe port, we split the ranges translation entries, to correspond
to each MBus window.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-mirabox.dts         |  32 +-
 arch/arm/boot/dts/armada-370-xp.dtsi             |   2 +
 arch/arm/boot/dts/armada-370.dtsi                | 101 +++---
 arch/arm/boot/dts/armada-xp-db.dts               |  67 ++--
 arch/arm/boot/dts/armada-xp-gp.dts               |  42 +--
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         | 222 ++++++------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         | 261 ++++++++-------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         | 409 ++++++++++++-----------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  18 +-
 9 files changed, 612 insertions(+), 542 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 19341d2..2471d9d 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -28,6 +28,22 @@
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
 			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
+		pcie-controller {
+			status = "okay";
+
+			/* Internal mini-PCIe connector */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+
+			/* Connected on the PCB to a USB 3.0 XHCI controller */
+			pcie at 2,0 {
+				/* Port 1, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
@@ -123,22 +139,6 @@
 					reg = <0x25>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/* Internal mini-PCIe connector */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-
-				/* Connected on the PCB to a USB 3.0 XHCI controller */
-				pcie at 2,0 {
-					/* Port 1, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 073dd20..e984ce6 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -44,6 +44,8 @@
 		#size-cells = <1>;
 		controller = <&mbusc>;
 		interrupt-parent = <&mpic>;
+		pcie-mem-aperture = <0xe0000000 0x8000000>;
+		pcie-io-aperture  = <0xe8000000 0x100000>;
 
 		devbus-bootcs {
 			compatible = "marvell,mvebu-devbus";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index bd21d49..648e530 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -36,6 +36,59 @@
 			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
 		};
 
+		pcie-controller {
+			compatible = "marvell,armada-370-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0       1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0       1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0     MBUS_ID(0x08, 0xe8) 0       1 0 /* Port 1.0 MEM */
+				0x81000000 0x2 0     MBUS_ID(0x08, 0xe0) 0       1 0 /* Port 1.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+                                ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+                                          0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+                                ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+                                          0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 62>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 9>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
@@ -174,54 +227,6 @@
 					0x18304 0x4>;
 				status = "okay";
 			};
-
-			pcie-controller {
-				compatible = "marvell,armada-370-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 62>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 9>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 76ae1a9..bcf6d79 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -62,6 +62,39 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+
+			/*
+			 * All 6 slots are physically present as
+			 * standard PCIe slots on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+			pcie at 2,0 {
+				/* Port 0, Lane 1 */
+				status = "okay";
+			};
+			pcie at 3,0 {
+				/* Port 0, Lane 2 */
+				status = "okay";
+			};
+			pcie at 4,0 {
+				/* Port 0, Lane 3 */
+				status = "okay";
+			};
+			pcie at 9,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+			pcie at 10,0 {
+				/* Port 3, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -155,40 +188,6 @@
 					spi-max-frequency = <20000000>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/*
-				 * All 6 slots are physically present as
-				 * standard PCIe slots on the board.
-				 */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-				pcie at 2,0 {
-					/* Port 0, Lane 1 */
-					status = "okay";
-				};
-				pcie at 3,0 {
-					/* Port 0, Lane 2 */
-					status = "okay";
-				};
-				pcie at 4,0 {
-					/* Port 0, Lane 3 */
-					status = "okay";
-				};
-				pcie at 9,0 {
-					/* Port 2, Lane 0 */
-					status = "okay";
-				};
-				pcie at 10,0 {
-					/* Port 3, Lane 0 */
-					status = "okay";
-				};
-			};
-
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 8c0de20..2298e4a 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -71,6 +71,27 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+
+			/*
+			 * The 3 slots are physically present as
+			 * standard PCIe slots on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+			pcie at 9,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+			pcie at 10,0 {
+				/* Port 3, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -154,27 +175,6 @@
 					spi-max-frequency = <108000000>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/*
-				 * The 3 slots are physically present as
-				 * standard PCIe slots on the board.
-				 */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-				pcie at 9,0 {
-					/* Port 2, Lane 0 */
-					status = "okay";
-				};
-				pcie at 10,0 {
-					/* Port 3, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f8eaa38..f093e39 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -44,6 +44,124 @@
 	};
 
 	soc {
+		/*
+		 * MV78230 has 2 PCIe units Gen2.0: One unit can be
+		 * configured as x4 or quad x1 lanes. One unit is
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000000 0x1 0       MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0       MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0       MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+				0x81000000 0x2 0       MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+				0x82000000 0x3 0       MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+				0x81000000 0x3 0       MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+				0x82000000 0x4 0       MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+				0x81000000 0x4 0       MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+				0x82000000 0x9 0       MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
+				0x81000000 0x9 0       MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+					  0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+					  0x81000000 0 0 0x81000000 0x3 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+					  0x81000000 0 0 0x81000000 0x4 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+					  0x81000000 0 0 0x81000000 0x9 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78230-pinctrl";
@@ -77,110 +195,6 @@
 				#interrupts-cells = <2>;
 				interrupts = <87>, <88>, <89>;
 			};
-
-			/*
-			 * MV78230 has 2 PCIe units Gen2.0: One unit can be
-			 * configured as x4 or quad x1 lanes. One unit is
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-#address-cells = <3>;
-#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 985373a..6dc3921 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -45,6 +45,145 @@
 	};
 
 	soc {
+		/*
+		 * MV78260 has 3 PCIe units Gen2.0: Two units can be
+		 * configured as x4 or quad x1 lanes. One unit is
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000   /* Port 1.0 registers */
+				0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000   /* Port 3.0 registers */
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+				0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+				0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+				0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+				0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+				0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+				0x82000000 0x9 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
+				0x81000000 0x9 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
+				0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
+				0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+                                ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+                                          0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+					  0x81000000 0 0 0x81000000 0x3 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+					  0x81000000 0 0 0x81000000 0x4 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+					  0x81000000 0 0 0x81000000 0x9 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+
+			pcie at 10,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x82000 0 0x2000>;
+				reg = <0x5000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
+					  0x81000000 0 0 0x81000000 0xa 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 103>;
+				marvell,pcie-port = <3>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 27>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78260-pinctrl";
@@ -97,128 +236,6 @@
 				clocks = <&gateclk 1>;
 				status = "disabled";
 			};
-
-			/*
-			 * MV78260 has 3 PCIe units Gen2.0: Two units can be
-			 * configured as x4 or quad x1 lanes. One unit is
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-
-				pcie at 10,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x82000 0 0x2000>;
-					reg = <0x5000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 103>;
-					marvell,pcie-port = <3>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 27>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index f8bf25a..a6661e3 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -61,6 +61,227 @@
 	};
 
 	soc {
+		/*
+		 * MV78460 has 4 PCIe units Gen2.0: Two units can be
+		 * configured as x4 or quad x1 lanes. Two units are
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000   /* Port 1.0 registers */
+				0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000   /* Port 3.0 registers */
+				0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000   /* Port 1.1 registers */
+				0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000   /* Port 1.2 registers */
+				0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000   /* Port 1.3 registers */
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+				0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+				0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+				0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+				0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+				0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+
+				0x82000000 0x5 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
+				0x81000000 0x5 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
+				0x82000000 0x6 0     MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */
+				0x81000000 0x6 0     MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO  */
+				0x82000000 0x7 0     MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */
+				0x81000000 0x7 0     MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO  */
+				0x82000000 0x8 0     MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */
+				0x81000000 0x8 0     MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO  */
+
+				0x82000000 0x9 0     MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
+				0x81000000 0x9 0     MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */
+
+				0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
+				0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+					  0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+					  0x81000000 0 0 0x81000000 0x3 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+					  0x81000000 0 0 0x81000000 0x4 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 5,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
+				reg = <0x2800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
+					  0x81000000 0 0 0x81000000 0x5 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 62>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 9>;
+				status = "disabled";
+			};
+
+			pcie at 6,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
+				reg = <0x3000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0
+					  0x81000000 0 0 0x81000000 0x6 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 63>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 10>;
+				status = "disabled";
+			};
+
+			pcie at 7,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
+				reg = <0x3800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0
+					  0x81000000 0 0 0x81000000 0x7 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 64>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 11>;
+				status = "disabled";
+			};
+
+			pcie at 8,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
+				reg = <0x4000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0
+					  0x81000000 0 0 0x81000000 0x8 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 65>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 12>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+					  0x81000000 0 0 0x81000000 0x9 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+
+			pcie at 10,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
+				reg = <0x5000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
+					  0x81000000 0 0 0x81000000 0xa 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 103>;
+				marvell,pcie-port = <3>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 27>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78460-pinctrl";
@@ -113,194 +334,6 @@
 				clocks = <&gateclk 1>;
 				status = "disabled";
 			};
-
-			/*
-			 * MV78460 has 4 PCIe units Gen2.0: Two units can be
-			 * configured as x4 or quad x1 lanes. Two units are
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
-					0x82000000 0 0x84000 0x84000 0 0x00002000   /* Port 1.1 registers */
-					0x82000000 0 0x88000 0x88000 0 0x00002000   /* Port 1.2 registers */
-					0x82000000 0 0x8c000 0x8c000 0 0x00002000   /* Port 1.3 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 5,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
-					reg = <0x2800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 62>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 9>;
-					status = "disabled";
-				};
-
-				pcie at 6,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
-					reg = <0x3000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 63>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 10>;
-					status = "disabled";
-				};
-
-				pcie at 7,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
-					reg = <0x3800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 64>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 11>;
-					status = "disabled";
-				};
-
-				pcie at 8,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
-					reg = <0x4000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 65>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 12>;
-					status = "disabled";
-				};
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-
-				pcie at 10,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
-					reg = <0x5000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 103>;
-					marvell,pcie-port = <3>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 27>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 2b60ee0..5695afc 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -59,6 +59,15 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+			/* Internal mini-PCIe connector */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -176,15 +185,6 @@
 			usb at 51000 {
 				status = "okay";
 			};
-
-			pcie-controller {
-				status = "okay";
-				/* Internal mini-PCIe connector */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul  9 12:41:23 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue,  9 Jul 2013 13:41:23 -0300
Subject: [PATCH v7 21/22] ARM: mvebu: Relocate Armada 370/XP DeviceBus device
 tree nodes
In-Reply-To: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373388084-29520-22-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus has been added to the device tree, it's possible to
move the DeviceBus out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the hardware.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi             | 94 +++++++++++++-----------
 arch/arm/boot/dts/armada-xp-db.dts               | 59 +++++++--------
 arch/arm/boot/dts/armada-xp-gp.dts               | 60 +++++++--------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 65 ++++++++--------
 4 files changed, 140 insertions(+), 138 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 62639b4..073dd20 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -45,6 +45,56 @@
 		controller = <&mbusc>;
 		interrupt-parent = <&mpic>;
 
+		devbus-bootcs {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs0 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs1 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs2 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs3 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
 		internal-regs {
 			compatible = "simple-bus";
 			#address-cells = <1>;
@@ -200,50 +250,6 @@
 				status = "disabled";
 			};
 
-			devbus-bootcs at 10400 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10400 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs0 at 10408 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10408 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs1 at 10410 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10410 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs2 at 10418 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10418 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs3 at 10420 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10420 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
 		};
 	};
  };
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 857f272..76ae1a9 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -31,7 +31,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x1000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -160,34 +189,6 @@
 				};
 			};
 
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x1000000>;
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 16 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x1000000>;
-					bank-width = <2>;
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 934dc46..8c0de20 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -40,7 +40,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x1000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -126,35 +155,6 @@
 				};
 			};
 
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf000000, size 0x1000000 */
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 16 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x1000000>;
-					bank-width = <2>;
-				};
-			};
-
 			pcie-controller {
 				status = "okay";
 
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 1700f6f..2b60ee0 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -28,7 +28,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 128 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x8000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -148,40 +177,6 @@
 				status = "okay";
 			};
 
-			/* USB interface in the mini-PCIe connector */
-			usb at 52000 {
-				status = "okay";
-			};
-
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x8000000>; /* @addr 0xf000000, size 0x8000000 */
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 128 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x8000000>;
-					bank-width = <2>;
-				};
-			};
-
 			pcie-controller {
 				status = "okay";
 				/* Internal mini-PCIe connector */
-- 
1.8.1.5



From swarren at wwwdotorg.org  Tue Jul  9 12:52:34 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 09 Jul 2013 10:52:34 -0600
Subject: CPU hotplug issue w/ 0647065 clocksource: Add generic dummy timer
 driver
In-Reply-To: <20130709163518.GD830@codeaurora.org>
References: <51DAF895.1020700@wwwdotorg.org>
 <20130709005837.GC830@codeaurora.org> <51DC34AD.30009@wwwdotorg.org>
 <20130709163518.GD830@codeaurora.org>
Message-ID: <51DC3FD2.9070308@wwwdotorg.org>

On 07/09/2013 10:35 AM, Stephen Boyd wrote:
> On 07/09, Stephen Warren wrote:
>> On 07/08/2013 06:58 PM, Stephen Boyd wrote:
>>> On 07/08, Stephen Warren wrote:
>>>> CPU hotplug (replug) on Tegra HW seems to be occasionally broken due to
>>>> commit 0647065 "clocksource: Add generic dummy timer driver" in
>>>> linux-next. Reverting that commit solves the issue.
>>>
>>> We found some breakage during boot that has been fixed by two
>>> commits in linus' tree already. Do you know if you have these two
>>> patches
>>>
>>> 1f73a9806bdd07a5106409bbcab3884078bd34fe
>>> 07bd1172902e782f288e4d44b1fde7dec0f08b6f
>>
>> I didn't before since I was using next-20130705, but I just tried
>> next-20130709 which does have those two commits, and I still see the issue.
>>
> 
> Ok can you get the output of /proc/timer_list and send it back

Sure, it's below. I took another snapshot after unplugging then
re-plugging CPU1, and there was no difference except in the actual time
values and list of queued events (at ~line 12). The set of timers,
modes, etc. were all the same.

> Timer List Version: v0.7
> HRTIMER_MAX_CLOCK_BASES: 4
> now at 75889089000 nsecs
> 
> cpu: 0
>  clock 0:
>   .base:       c0c376a0
>   .index:      0
>   .resolution: 1 nsecs
>   .get_time:   ktime_get
>   .offset:     0 nsecs
> active timers:
>  #0: <c0c384c0>, menu_hrtimer_notify, S:01, hrtimer_start, swapper/0/0
>  # expires at 75889183000-75889183000 nsecs [in 94000 to 94000 nsecs]
>  #1: <c0c379a8>, tick_sched_timer, S:01, hrtimer_start_range_ns, swapper/0/0
>  # expires at 75890000000-75890000000 nsecs [in 911000 to 911000 nsecs]
>  #2: <def3a550>, ehci_hrtimer_func, S:01, hrtimer_start_range_ns, swapper/0/0
>  # expires at 75921594000-75922594000 nsecs [in 32505000 to 33505000 nsecs]
>  #3: <def3ad50>, ehci_hrtimer_func, S:01, hrtimer_start_range_ns, setfont/436
>  # expires at 75921599000-75922599000 nsecs [in 32510000 to 33510000 nsecs]
>  #4: <defd3990>, it_real_fn, S:01, hrtimer_start, syslogd/590
>  # expires at 102888764000-102888764000 nsecs [in 26999675000 to 26999675000 nsecs]
>  #5: <defd3990>, it_real_fn, S:01, hrtimer_start, syslogd/590
>  # expires at 102888764000-102888764000 nsecs [in 26999675000 to 26999675000 nsecs]
>  #6: <df7c1b30>, hrtimer_wakeup, S:01, hrtimer_start_range_ns, avahi-daemon/352
>  # expires at 117911912000-117961554999 nsecs [in 42022823000 to 42072465999 nsecs]
>  #7: <dd857a90>, hrtimer_wakeup, S:01, hrtimer_start_range_ns, dhclient/690
>  # expires at 267143504000-267243504000 nsecs [in 191254415000 to 191354415000 nsecs]
>  #8: <de8eff28>, hrtimer_wakeup, S:01, hrtimer_start_range_ns, atd/557
>  # expires at 3611972607000-3611972657000 nsecs [in 3536083518000 to 3536083568000 nsecs]
>  clock 1:
>   .base:       c0c376d8
>   .index:      1
>   .resolution: 1 nsecs
>   .get_time:   ktime_get_real
>   .offset:     24375428000 nsecs
> active timers:
>  clock 2:
>   .base:       c0c37710
>   .index:      2
>   .resolution: 1 nsecs
>   .get_time:   ktime_get_boottime
>   .offset:     0 nsecs
> active timers:
>  clock 3:
>   .base:       c0c37748
>   .index:      3
>   .resolution: 1 nsecs
>   .get_time:   ktime_get_clocktai
>   .offset:     24375428000 nsecs
> active timers:
>   .expires_next   : 75889329000 nsecs
>   .hres_active    : 1
>   .nr_events      : 4712
>   .nr_retries     : 2
>   .nr_hangs       : 0
>   .max_hang_time  : 0 nsecs
>   .nohz_mode      : 2
>   .last_tick      : 75740000000 nsecs
>   .tick_stopped   : 0
>   .idle_jiffies   : 4294944869
>   .idle_calls     : 13615
>   .idle_sleeps    : 5374
>   .idle_entrytime : 75889188000 nsecs
>   .idle_waketime  : 75881026000 nsecs
>   .idle_exittime  : 75881243000 nsecs
>   .idle_sleeptime : 61747543000 nsecs
>   .iowait_sleeptime: 7327300000 nsecs
>   .last_jiffies   : 4294944884
>   .next_jiffies   : 4294944885
>   .idle_expires   : 75930000000 nsecs
> jiffies: 4294944884
> 
> cpu: 1
>  clock 0:
>   .base:       c0c3f6a0
>   .index:      0
>   .resolution: 1 nsecs
>   .get_time:   ktime_get
>   .offset:     0 nsecs
> active timers:
>  #0: <c0c3f9a8>, tick_sched_timer, S:01, hrtimer_start_range_ns, swapper/1/0
>  # expires at 75900000000-75900000000 nsecs [in 10911000 to 10911000 nsecs]
>  #1: <de835b30>, hrtimer_wakeup, S:01, hrtimer_start_range_ns, console-kit-dae/734
>  # expires at 79000444000-79026433999 nsecs [in 3111355000 to 3137344999 nsecs]
>  #2: <de833b30>, hrtimer_wakeup, S:01, hrtimer_start_range_ns, rpcbind/487
>  # expires at 101235760000-101265759998 nsecs [in 25346671000 to 25376670998 nsecs]
>  #3: <debdff28>, hrtimer_wakeup, S:01, hrtimer_start_range_ns, rwhod/668
>  # expires at 193712567000-193712617000 nsecs [in 117823478000 to 117823528000 nsecs]
>  #4: <de9abb30>, hrtimer_wakeup, S:01, hrtimer_start_range_ns, NetworkManager/543
>  # expires at 313000895000-313100895000 nsecs [in 237111806000 to 237211806000 nsecs]
>  clock 1:
>   .base:       c0c3f6d8
>   .index:      1
>   .resolution: 1 nsecs
>   .get_time:   ktime_get_real
>   .offset:     24375428000 nsecs
> active timers:
>  clock 2:
>   .base:       c0c3f710
>   .index:      2
>   .resolution: 1 nsecs
>   .get_time:   ktime_get_boottime
>   .offset:     0 nsecs
> active timers:
>  clock 3:
>   .base:       c0c3f748
>   .index:      3
>   .resolution: 1 nsecs
>   .get_time:   ktime_get_clocktai
>   .offset:     24375428000 nsecs
> active timers:
>   .expires_next   : 75900000000 nsecs
>   .hres_active    : 1
>   .nr_events      : 4578
>   .nr_retries     : 1
>   .nr_hangs       : 0
>   .max_hang_time  : 0 nsecs
>   .nohz_mode      : 2
>   .last_tick      : 75890000000 nsecs
>   .tick_stopped   : 0
>   .idle_jiffies   : 4294944884
>   .idle_calls     : 6538
>   .idle_sleeps    : 1104
>   .idle_entrytime : 75891066000 nsecs
>   .idle_waketime  : 75821610000 nsecs
>   .idle_exittime  : 75887089000 nsecs
>   .idle_sleeptime : 67621307000 nsecs
>   .iowait_sleeptime: 4203885000 nsecs
>   .last_jiffies   : 4294944885
>   .next_jiffies   : 4294944886
>   .idle_expires   : 120710000000 nsecs
> jiffies: 4294944885
> 
> Tick Device: mode:     1
> Broadcast device
> Clock Event Device: timer0
>  max_delta_ns:   536870948000
>  min_delta_ns:   1000
>  mult:           4294967
>  shift:          32
>  mode:           3
>  next_event:     75922594000 nsecs
>  set_next_event: tegra_timer_set_next_event
>  set_mode:       tegra_timer_set_mode
>  event_handler:  tick_handle_oneshot_broadcast
>  retries:        0
> 
> tick_broadcast_mask: 00000000
> tick_broadcast_oneshot_mask: 00000000
> 
> Tick Device: mode:     1
> Per CPU device: 0
> Clock Event Device: local_timer
>  max_delta_ns:   17179869180
>  min_delta_ns:   1000
>  mult:           536870912
>  shift:          31
>  mode:           3
>  next_event:     75900000000 nsecs
>  set_next_event: twd_set_next_event
>  set_mode:       twd_set_mode
>  event_handler:  hrtimer_interrupt
>  retries:        0
> 
> Tick Device: mode:     1
> Per CPU device: 1
> Clock Event Device: local_timer
>  max_delta_ns:   17179869180
>  min_delta_ns:   1000
>  mult:           536870912
>  shift:          31
>  mode:           3
>  next_event:     75900000000 nsecs
>  set_next_event: twd_set_next_event
>  set_mode:       twd_set_mode
>  event_handler:  hrtimer_interrupt
>  retries:        0



From swarren at wwwdotorg.org  Tue Jul  9 12:57:36 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 09 Jul 2013 10:57:36 -0600
Subject: [PATCH] ARM: tegra: enable palmas device for dalmore
In-Reply-To: <1373290688-2257-1-git-send-email-ldewangan@nvidia.com>
References: <1373290688-2257-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <51DC4100.4050309@wwwdotorg.org>

On 07/08/2013 07:38 AM, Laxman Dewangan wrote:
> Make the entry of Dalmore Power Management Unit device TPS65913
> in dalmore DTS file. The Palma driver support this device.
> 
> Enable following submodule of the TPS65913:
> - GPIO driver
> - RTC driver.
> - Power regulator driver.

> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts

> +		palmas: tps65913 at 58 {

I assume there's only one TPS65913 in the system, so that node name
doesn't need to contain the unit address to make it unique; the node can
simply be named "tps65913".

> +			palmas_gpio: palmas_gpio {
> +			palmas_rtc {
> +			palmas_pmic {

I don't think those node names need "palmas" in them; they can simply be
"gpio", "rtc", "pmic".


> +			    ldousb-in-supply = <&tps65090_dcdc1_reg>;
> +			    regulators {

You'd usually leave a blank line between properties and nodes.

> +		vdd_cam_1v8_reg: regulator at 6 {
...
> +			gpio = <&palmas_gpio 6 0>; /* Palmas GPIO6 */

That comment probably isn't worthwhile; I only insisted on them for
Tegra GPIOs so that the GPIO name could be included somewhere, whereas
for devices with just a small handful of GPIOs without any other names,
there's no point putting a comment, since it's obvious from the cell
content.


From swarren at wwwdotorg.org  Tue Jul  9 13:03:48 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 09 Jul 2013 11:03:48 -0600
Subject: [PATCH V2 10/11] ARM: dts: tegra114: dalmore: add GPIO power
 key support
In-Reply-To: <1372845047-25147-11-git-send-email-josephl@nvidia.com>
References: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
 <1372845047-25147-11-git-send-email-josephl@nvidia.com>
Message-ID: <51DC4274.8040607@wwwdotorg.org>

On 07/03/2013 03:50 AM, Joseph Lo wrote:
> Adding the GPIO power key and enabling the wake up function.

I think I'll skip this one patch, because Laxman posted a more complete
patch "[PATCH V2] ARM: tegra: enable gpio-keys on dalmore". which
includes this change, plus defines another 3 keys.


From rogerq at ti.com  Tue Jul  9 13:20:39 2013
From: rogerq at ti.com (Roger Quadros)
Date: Tue, 9 Jul 2013 20:20:39 +0300
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51DC1B47.7070504@denx.de>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de>
Message-ID: <51DC4667.3030305@ti.com>

On 07/09/2013 05:16 PM, Stefan Roese wrote:
> Hi Roger,
> 
> On 07/09/2013 03:55 PM, Roger Quadros wrote:
>>> I'm using latest kernel.org for this (git ID d2b4a646 also tested with
>>> v3.10 release). This is with DT-enabled booting and without-DT (same
>>> problem). I also tested some older Linux kernel versions and it fails
>>> there as well. Only v3.2.40 seems to be able to mount this rootfs via
>>> NFS reliably (approx. 10 times success).
>>
>> I can't really tell at the moment where the problem is.
>>
>> Did you compile in all the necessary drivers required for NFS booting?
>> In the beagle case that would mean NOP_USB_XCEIV, USB_EHCI_HCD, USB_EHCI_HCD_OMAP
>> and the smsc95xx driver.
> 
> Yes, sure. Otherwise no USB/NFS mount would have been possible.
> 
>> If you can paste your full kernel boot log we can check if all these show up
>> before the kernel tries to look up for the NFS server.
> 
> Please find it attached (one log for the NFS mount working and one for
> failing - both with exact the same kernel/dtb). Also my current .config.
> 

Thanks for the logs. Configuration part seems OK. NFS root has been mounted
in failing case as well. Then it fails. I'll need to investigate more what
happens. 

cheers,
-roger


From dianders at chromium.org  Tue Jul  9 13:31:09 2013
From: dianders at chromium.org (Doug Anderson)
Date: Tue,  9 Jul 2013 10:31:09 -0700
Subject: [PATCH 3/5] mmc: dw_mmc: Add exynos resume callback to clear
 WAKEUP_INT
In-Reply-To: <1373391071-6312-1-git-send-email-dianders@chromium.org>
References: <1373391071-6312-1-git-send-email-dianders@chromium.org>
Message-ID: <1373391071-6312-4-git-send-email-dianders@chromium.org>

If the WAKEUP_INT is asserted at wakeup and not cleared, we'll end up
looping around forever.

Signed-off-by: Doug Anderson <dianders at chromium.org>
---
 drivers/mmc/host/dw_mmc-exynos.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index f013e7e..84d3b78 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -30,6 +30,7 @@
 #define SDMMC_CLKSEL_TIMING(x, y, z)	(SDMMC_CLKSEL_CCLK_SAMPLE(x) |	\
 					SDMMC_CLKSEL_CCLK_DRIVE(y) |	\
 					SDMMC_CLKSEL_CCLK_DIVIDER(z))
+#define SDMMC_CLKSEL_WAKEUP_INT		BIT(11)
 
 #define SDMMC_CMD_USE_HOLD_REG		BIT(29)
 
@@ -102,6 +103,27 @@ static int dw_mci_exynos_setup_clock(struct dw_mci *host)
 	return 0;
 }
 
+/**
+ * dw_mci_exynos_resume - Exynos-specific resume code
+ *
+ * We have seen cases (at least on the exynos5420) where turning off the INT
+ * power rail during suspend will leave the WAKEUP_INT bit in the CLKSEL
+ * register asserted.  This bit is 1 to indicate that it fired and we can
+ * clear it by writing a 1 back.  Clear it to prevent interrupts from going off
+ * constantly.
+ */
+
+static int dw_mci_exynos_resume(struct dw_mci *host)
+{
+	u32 clksel;
+
+	clksel = mci_readl(host, CLKSEL);
+	if (clksel & SDMMC_CLKSEL_WAKEUP_INT)
+		mci_writel(host, CLKSEL, clksel);
+
+	return 0;
+}
+
 static void dw_mci_exynos_prepare_command(struct dw_mci *host, u32 *cmdr)
 {
 	/*
@@ -165,6 +187,7 @@ static const struct dw_mci_drv_data exynos_drv_data = {
 	.caps			= exynos_dwmmc_caps,
 	.init			= dw_mci_exynos_priv_init,
 	.setup_clock		= dw_mci_exynos_setup_clock,
+	.resume			= dw_mci_exynos_resume,
 	.prepare_command	= dw_mci_exynos_prepare_command,
 	.set_ios		= dw_mci_exynos_set_ios,
 	.parse_dt		= dw_mci_exynos_parse_dt,
-- 
1.8.3



From balbi at ti.com  Tue Jul  9 13:34:29 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 9 Jul 2013 20:34:29 +0300
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <780E789C2E067A4BB8F69D0BB9EC4F253E97670D@DBDE04.ent.ti.com>
References: <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com>
 <51D54694.20203@ti.com> <20130704101216.GD4830@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E9764D5@DBDE04.ent.ti.com>
 <51DAADD1.3060302@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E976575@DBDE04.ent.ti.com>
 <20130709114416.GL5552@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E97670D@DBDE04.ent.ti.com>
Message-ID: <20130709173429.GE10776@arwen.pp.htv.fi>

Hi,

On Tue, Jul 09, 2013 at 02:33:58PM +0200, Patel, Satish wrote:
> > > Operation:
> > >
> > > Once the card gets inserted into the slot, user application can
> > > initiate activate sequence anytime, it is not mandatory that
> > > activation has to be called Immediately. It all depends whether
> > other
> > > connections ( network, printer) are proper.  User application can do
> > > some checks and then dynamically activate the card
> > 
> > The card or the phy ? Who actually activates ? Is the activation
> > handling part of the PHY or part of the smartcard controller ?
> > 
> 
> It?s a activation of smart card which is inserted into the phy slot. 
> Smart card activation will by done phy but initiated by user application
> Handling of activation should be done at both the side - controller as well
> As phy. Phy will raise certain signals and check timeout while activation
> , while controller will store data coming from smart card to FIFO. Its
> Controller which will give command to phy to initiate activation sequence when it
> is ready. 
> 
> Which means, both controller and phy has role to play while activation.
> Also it is applicable while deactivation.

right, so when the smartcard device is opened, you want to powerup the
PHY, powerup the smartcard controller and get things going, which means
that all your activation logic can, and should, be hidden by
phy_power_on() and phy_power_off()

Perhaps you also want to delay phy_init() and phy_shutdown() to that
very time, which would mean that we wouldn't even need
phy_power_{on,off}() calls whatsoever.

> > > There are 2 sequence of activation - normal activation and warm
> > reset.
> > > If first fails then warm reset should be executed, if card does not
> > > response to both then deactivation will be carried out
> > 
> > ret = phy_resume(phy);
> > if (ret == -EINVAL) { /* perhaps there's a better error code */
> > 	ret = phy_reset(phy);
> > 	if (ret)
> > 		phy_suspend(phy);
> > }
> >
> 
> Its not like this. There are the cases, when during normal activation
> card respond With some characters, but they might not be valid or
> error prone - This check will be done by user application as only
> application knows how to decode characters as per protocol.

sure, and if the characters are invalid, the application needs to tell
the kernel, perhaps it would be enough to send and IOCTL or, even
easier, close the device and reopen it.

> It there is any error in characters/timeout paratmeters, user
> application will ask to initiate Warm reset.

and for that we can use an IOCTL which is implemented by smart card
layer. I mean, I'm assuming the smartcard would be seen as a char dev by
userland so it would be something like this:

ret = read(fd, buf, SIZE);
if (ret < 0)
	boom();

ret = process_buffer(buf, ret);
if (ret == -EINVAL) { /* we have received invalid characters */
	ret = ioctl(fd, IOCTL_SMARTCARD_WARM_RESET);
	if (ret < 0)
		handle_error();
}

in kernel space we would have an ioctl handler like so:

static int smart_card_ioctl(struct file *fd, unsigned code, usigned long v)
{
	struct smart_card *sc = fd->private_data;
	unsigned long flags;
	int ret;

	spin_lock_irqsave(&sc->lock, flags);
	switch (v)
	case SMART_CARD_WARM_RESET:
		ret = phy_shutdown(sc->phy);
		if (ret < 0)
			boom();

		ret = smart_card_reset(sc);
		if (ret < 0)
			boom();

		ret = phy_init(sc->phy);
		if (ret < 0)
			boom();
		break;
	[ ... ]
	}

	spin_unlock_irqrestore(&sc->lock, flags);

	return ret;
}

see, we don't need to add a bunch of stuff in the PHY framework, because
you shouldn't expose the PHY directly to userland. You *must* have an
abstraction to userland with an in-kernel usage of the PHY layer.

> > > - on activation card will respond with some initial characters
> > (ATR),
> > > which will be verified by application, in case of error user
> > > application will de-activate the card not the phy module
> > >
> > > - After activation, use application initiate normal tx/rx
> > >
> > > - Once tx/rx is done, it will initiate deactivation of card not the
> > > phy module.
> > 
> > then that has nothing to do with the PHY framework, right ?
> 
> But all such sequence will be initiated by PHY by raising certain
> signals and only controller can give the push when to start.

sure, that's fair. But you don't need to expose every single detail of
the PHY. You need to use abstractions to make accesses to the PHY easy
to maintain. See the example above.

> > > > > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> > > >
> > > > Whats should be exactly done here? Looks to me like it should be
> > > > part of init. Does these pin settings need to be changed
> > dynamically?
> > >
> > > These are all phy pins which will be physically come in contact with
> > > smart card When inserted. In case of synchronous card, these pins
> > will
> > > be toggled manually by s/w bit bang algorithm
> > 
> > is that a requirement or just something that everybody does ?
> >
> 
> Its requirement for synchronous card. At present there is no open driver
> Which does this thing.

alright, so you need to tell the PHY in which mode it should work and
the PHY driver needs to be smart enough to choose proper callbacks
depending on the mode.

> > In any case, you can hide that under some gpio calls, or something
> > similar.
> 
> Can't be done using GPIO as pin can be toggled only which i2c read/write
> to the phy.

so ? look at the numerous I2C GPIO expanders we have in the kernel ;-)

> > > > > Smartcard_get_version -> phy_get_version
> > > >
> > > > Again why? Why would the smartcard need the version of the PHY?
> > > >
> > >
> > > Can be omitted. This is for the test suite reference.
> > 
> > if it's for testsuite, it sounds like something that should be done
> > through userland and, as such, should be implemented by a set of
> > debugfs
> > files which expose the necessary information. That has nothing to do
> > with the PHY framework.
> > 
> Agree.. can be omitted.
> 
> 
> I am ok to give internal webex presentation (TI team) to brief 
> on phy and smart card controller interface.

let's try to cut down on internal agreements and let the community help
defining a proper way to handle the PHY :-)

Still, if you want to point me and Kishon (privately) to some internal
documentation, we can certainly read through it :-)

cheers

-- 
balbi
-------------- 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/20130709/9c264c9a/attachment.sig>

From dianders at chromium.org  Tue Jul  9 13:31:06 2013
From: dianders at chromium.org (Doug Anderson)
Date: Tue,  9 Jul 2013 10:31:06 -0700
Subject: [PATCH 0/5] mmc: dw_mmc: fixes for suspend/resume on exynos
Message-ID: <1373391071-6312-1-git-send-email-dianders@chromium.org>

This series of patches addresses some suspend/resume problems with
dw_mmc on exynos platforms.  Since suspend/resume is not fully working
on ToT Linux (3.10) on exynos5250-snow, this series was tested against
the current ToT ChromeOS 3.8 tree.  I have confirmed basic booting
and eMMC / SD card usage (and compiling, honest!) against ToT Linux.


Doug Anderson (5):
  mmc: dw_mmc: Invalidate cache of current_speed after suspend/resume
  mmc: dw_mmc: Add suspend/resume callbacks; disable irq during suspend
  mmc: dw_mmc: Add exynos resume callback to clear WAKEUP_INT
  mmc: dw_mmc: Always setup the bus after suspend/resume
  mmc: dw_mmc: Set timeout to max upon resume

 drivers/mmc/host/dw_mmc-exynos.c | 23 +++++++++++++++++++++++
 drivers/mmc/host/dw_mmc.c        | 26 ++++++++++++++++++++++----
 drivers/mmc/host/dw_mmc.h        |  4 ++++
 3 files changed, 49 insertions(+), 4 deletions(-)

-- 
1.8.3



From jic23 at kernel.org  Tue Jul  9 13:43:16 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Tue, 09 Jul 2013 18:43:16 +0100
Subject: [PATCHv3 1/3] iio: Add Nuvoton NAU7802 ADC driver
In-Reply-To: <51DC1858.8010008@free-electrons.com>
References: <1372094699-3832-1-git-send-email-alexandre.belloni@free-electrons.com>
 <1372094699-3832-2-git-send-email-alexandre.belloni@free-electrons.com>
 <51D53B72.6020309@metafoo.de> <51D7F044.9040205@kernel.org>
 <51DC1858.8010008@free-electrons.com>
Message-ID: <51DC4BB4.6060506@kernel.org>

Sorry, looks like I forgot to push the tree out.
Anyhow should be there shortly.

On 07/09/2013 03:04 PM, Alexandre Belloni wrote:
> Hi Jonathan,
> 
> I don't actually see it in iio.git on kernel.org, am I doing something
> wrong ?
> 
> On 06/07/2013 12:24, Jonathan Cameron wrote:
>> On 07/04/2013 10:08 AM, Lars-Peter Clausen wrote:
>>> On 06/24/2013 07:24 PM, Alexandre Belloni wrote:
>>>> The Nuvoton NAU7802 ADC is a 24-bit 2-channels I2C ADC, with adjustable
>>>> gain and sampling rates.
>>>>
>>>> Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
>>>> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
>>> Reviewed-by: Lars-Peter Clausen <lars at metafoo.de>
>>>
>> Applied to the togreg branch of iio.git (with a few little tweaks).
>>
>> There was some fuzz that required manual fixing because of another driver merge so
>> please check I didn't foul anything up with this or the other bits below.
>>
>> There were two trivial missing unlocks on error paths in the read_raw function that
>> I've fixed up (Coccinelle found these for me - if you can I would always advise
>> running sparse, coccicheck and ideally smatch before submitting patches).
>>
>> I fixed up the comments because if there is one thing I hate bothering
>> with it is delightful patches that just fix this stuff. Much better
>> to do it now given it took 20 secs ;)
>>
>>> One remark though. Multiline comments should be like
>>>
>>> /*
>>>  * foo
>>>  * bar
>>>  */
>>>
>>> not
>>>
>>> /* foo
>>>  * bar
>>>  */
>>>
>>> But not need to resend the patch just for this
>>>
>>> - Lars
>>>
> 
> 


From festevam at gmail.com  Tue Jul  9 14:16:00 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 9 Jul 2013 15:16:00 -0300
Subject: [PATCH 3/3] ARM: imx: mm-imx3: Free l2x0_base
In-Reply-To: <20130709062414.GG16656@S2101-09.ap.freescale.net>
References: <1373306318-15604-1-git-send-email-festevam@gmail.com>
 <1373306318-15604-3-git-send-email-festevam@gmail.com>
 <20130709062414.GG16656@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5D4ivbqYovVA2CpXEemrAq8Nyn5By8-iL3SAnw=mpJ+og@mail.gmail.com>

On Tue, Jul 9, 2013 at 3:24 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> On Mon, Jul 08, 2013 at 02:58:38PM -0300, Fabio Estevam wrote:
>> From: Fabio Estevam <fabio.estevam at freescale.com>
>>
>> After l2x0_base has been used, we should free it.
>>
>> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
>> ---
>>  arch/arm/mach-imx/mm-imx3.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/mach-imx/mm-imx3.c b/arch/arm/mach-imx/mm-imx3.c
>> index 0884ca9..3143f5e 100644
>> --- a/arch/arm/mach-imx/mm-imx3.c
>> +++ b/arch/arm/mach-imx/mm-imx3.c
>> @@ -113,6 +113,7 @@ static void __init imx3_init_l2x0(void)
>>       }
>>
>>       l2x0_init(l2x0_base, 0x00030024, 0x00000000);
>> +     iounmap(l2x0_base);
>
> Are you sure?  I think cache-l2x0 driver still needs the mapping after
> that.

l2x0_base is a local variable of the static imx3_init_l2x0() function,
so we should iounmap it.


From jason at lakedaemon.net  Tue Jul  9 14:20:26 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 9 Jul 2013 14:20:26 -0400
Subject: [PATCH v7 11/22] PCI: mvebu: Adapt to the new device tree layout
In-Reply-To: <1373388084-29520-12-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1373388084-29520-12-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130709182026.GJ11908@titan.lakedaemon.net>

Bjorn,

On Tue, Jul 09, 2013 at 01:41:13PM -0300, Ezequiel Garcia wrote:
> From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> 
> The new device tree layout encodes the window's target ID and attribute
> in the PCIe controller node's ranges property. This allows to parse
> such entries to obtain such information and use the recently introduced
> MBus API to create the windows, instead of using the current name based
> scheme.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  .../devicetree/bindings/pci/mvebu-pci.txt          | 145 ++++++++++++++++-----
>  drivers/pci/host/pci-mvebu.c                       | 113 +++++++++++-----
>  2 files changed, 193 insertions(+), 65 deletions(-)

After my conversation with tglx a few days ago [1], I'm even more
inclined to push patches like this to the correct maintainers.  However,
looking at how this patch fits into the series, it may be better if we
take it through mvebu/arm-soc with your Ack.

It depends on the patches before it, and the patches after it depend on
it.  Unless I'm reading this wrong, I would have a branch that you would
pull and base this patch on, which I would then pull and base the rest
of the series on. Reshuffling the series to alleviate this wouldn't work
in this case. :-/

Are you ok with that?  (fwiw, the code changes are isolated to
pci-mvebu.c)

thx,

Jason.

[1] http://www.spinics.net/lists/arm-kernel/msg257447.html

> 
> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> index f8d4058..9556e2f 100644
> --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> @@ -1,6 +1,7 @@
>  * Marvell EBU PCIe interfaces
>  
>  Mandatory properties:
> +
>  - compatible: one of the following values:
>      marvell,armada-370-pcie
>      marvell,armada-xp-pcie
> @@ -10,11 +11,49 @@ Mandatory properties:
>  - #interrupt-cells, set to <1>
>  - bus-range: PCI bus numbers covered
>  - device_type, set to "pci"
> -- ranges: ranges for the PCI memory and I/O regions, as well as the
> -  MMIO registers to control the PCIe interfaces.
> +- ranges: ranges describing the MMIO registers to control the PCIe
> +  interfaces, and ranges describing the MBus windows needed to access
> +  the memory and I/O regions of each PCIe interface.
> +
> +The ranges describing the MMIO registers have the following layout:
> +
> +    0x82000000 0 r MBUS_ID(0xf0, 0x01) r 0 s
> +
> +where:
> +
> +  * r is a 32-bits value that gives the offset of the MMIO
> +  registers of this PCIe interface, from the base of the internal
> +  registers.
> +
> +  * s is a 32-bits value that give the size of this MMIO
> +  registers area. This range entry translates the '0x82000000 0 r' PCI
> +  address into the 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part
> +  of the internal register window (as identified by MBUS_ID(0xf0,
> +  0x01)).
> +
> +The ranges describing the MBus windows have the following layout:
> +
> +    0x8t000000 s 0     MBUS_ID(w, a) 0 1 0
> +
> +where:
> +
> +   * t is the type of the MBus window (as defined by the standard PCI DT
> +   bindings), 1 for I/O and 2 for memory.
>  
> -In addition, the Device Tree node must have sub-nodes describing each
> +   * s is the PCI slot that corresponds to this PCIe interface
> +
> +   * w is the 'target ID' value for the MBus window
> +
> +   * a the 'attribute' value for the MBus window.
> +
> +Since the location and size of the different MBus windows is not fixed in
> +hardware, and only determined in runtime, those ranges cover the full first
> +4 GB of the physical address space, and do not translate into a valid CPU
> +address.
> +
> +In addition, the device tree node must have sub-nodes describing each
>  PCIe interface, having the following mandatory properties:
> +
>  - reg: used only for interrupt mapping, so only the first four bytes
>    are used to refer to the correct bus number and device number.
>  - assigned-addresses: reference to the MMIO registers used to control
> @@ -26,7 +65,8 @@ PCIe interface, having the following mandatory properties:
>  - #address-cells, set to <3>
>  - #size-cells, set to <2>
>  - #interrupt-cells, set to <1>
> -- ranges, empty property.
> +- ranges, translating the MBus windows ranges of the parent node into
> +  standard PCI addresses.
>  - interrupt-map-mask and interrupt-map, standard PCI properties to
>    define the mapping of the PCIe interface to interrupt numbers.
>  
> @@ -47,27 +87,50 @@ pcie-controller {
>  
>  	bus-range = <0x00 0xff>;
>  
> -	ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
> -		  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
> -		  0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
> -		  0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
> -		  0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
> -		  0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
> -		  0x82000000 0 0xd0082000 0xd0082000 0 0x00002000   /* Port 3.0 registers */
> -		  0x82000000 0 0xd0084000 0xd0084000 0 0x00002000   /* Port 1.1 registers */
> -		  0x82000000 0 0xd0088000 0xd0088000 0 0x00002000   /* Port 1.2 registers */
> -		  0x82000000 0 0xd008c000 0xd008c000 0 0x00002000   /* Port 1.3 registers */
> -		  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
> -		  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
> +	ranges =
> +	       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000	/* Port 0.0 registers */
> +		0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000	/* Port 2.0 registers */
> +		0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000	/* Port 0.1 registers */
> +		0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000	/* Port 0.2 registers */
> +		0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000	/* Port 0.3 registers */
> +		0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000	/* Port 1.0 registers */
> +		0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000	/* Port 3.0 registers */
> +		0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000	/* Port 1.1 registers */
> +		0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000	/* Port 1.2 registers */
> +		0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000	/* Port 1.3 registers */
> +		0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
> +		0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
> +		0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
> +		0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
> +		0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
> +		0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
> +		0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
> +		0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
> +
> +		0x82000000 0x5 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
> +		0x81000000 0x5 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
> +		0x82000000 0x6 0     MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */
> +		0x81000000 0x6 0     MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO  */
> +		0x82000000 0x7 0     MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */
> +		0x81000000 0x7 0     MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO  */
> +		0x82000000 0x8 0     MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */
> +		0x81000000 0x8 0     MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO  */
> +
> +		0x82000000 0x9 0     MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
> +		0x81000000 0x9 0     MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */
> +
> +		0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
> +		0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
>  
>  	pcie at 1,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
> +		assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
>  		reg = <0x0800 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
> +			  0x81000000 0 0 0x81000000 0x1 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 58>;
>  		marvell,pcie-port = <0>;
> @@ -78,12 +141,13 @@ pcie-controller {
>  
>  	pcie at 2,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>;
> +		assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
>  		reg = <0x1000 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
> +			  0x81000000 0 0 0x81000000 0x2 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 59>;
>  		marvell,pcie-port = <0>;
> @@ -94,12 +158,13 @@ pcie-controller {
>  
>  	pcie at 3,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>;
> +		assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
>  		reg = <0x1800 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
> +			  0x81000000 0 0 0x81000000 0x3 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 60>;
>  		marvell,pcie-port = <0>;
> @@ -110,12 +175,13 @@ pcie-controller {
>  
>  	pcie at 4,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>;
> +		assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
>  		reg = <0x2000 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
> +			  0x81000000 0 0 0x81000000 0x4 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 61>;
>  		marvell,pcie-port = <0>;
> @@ -126,12 +192,13 @@ pcie-controller {
>  
>  	pcie at 5,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
> +		assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
>  		reg = <0x2800 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
> +			  0x81000000 0 0 0x81000000 0x5 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 62>;
>  		marvell,pcie-port = <1>;
> @@ -142,12 +209,13 @@ pcie-controller {
>  
>  	pcie at 6,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>;
> +		assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
>  		reg = <0x3000 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0
> +			  0x81000000 0 0 0x81000000 0x6 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 63>;
>  		marvell,pcie-port = <1>;
> @@ -158,12 +226,13 @@ pcie-controller {
>  
>  	pcie at 7,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>;
> +		assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
>  		reg = <0x3800 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0
> +			  0x81000000 0 0 0x81000000 0x7 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 64>;
>  		marvell,pcie-port = <1>;
> @@ -174,12 +243,13 @@ pcie-controller {
>  
>  	pcie at 8,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>;
> +		assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
>  		reg = <0x4000 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0
> +			  0x81000000 0 0 0x81000000 0x8 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 65>;
>  		marvell,pcie-port = <1>;
> @@ -187,14 +257,16 @@ pcie-controller {
>  		clocks = <&gateclk 12>;
>  		status = "disabled";
>  	};
> +
>  	pcie at 9,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>;
> +		assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
>  		reg = <0x4800 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
> +			  0x81000000 0 0 0x81000000 0x9 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 99>;
>  		marvell,pcie-port = <2>;
> @@ -205,12 +277,13 @@ pcie-controller {
>  
>  	pcie at 10,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>;
> +		assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
>  		reg = <0x5000 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
> +			  0x81000000 0 0 0x81000000 0xa 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 103>;
>  		marvell,pcie-port = <3>;
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index 13a633b..424a7b8 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -123,6 +123,10 @@ struct mvebu_pcie_port {
>  	u32 port;
>  	u32 lane;
>  	int devfn;
> +	unsigned int mem_target;
> +	unsigned int mem_attr;
> +	unsigned int io_target;
> +	unsigned int io_attr;
>  	struct clk *clk;
>  	struct mvebu_sw_pci_bridge bridge;
>  	struct device_node *dn;
> @@ -307,10 +311,9 @@ static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port *port)
>  			    (port->bridge.iolimitupper << 16)) -
>  			    iobase);
>  
> -	mvebu_mbus_add_window_remap_flags(port->name, port->iowin_base,
> -					  port->iowin_size,
> -					  iobase,
> -					  MVEBU_MBUS_PCI_IO);
> +	mvebu_mbus_add_window_remap_by_id(port->io_target, port->io_attr,
> +					  port->iowin_base, port->iowin_size,
> +					  iobase);
>  
>  	pci_ioremap_io(iobase, port->iowin_base);
>  }
> @@ -342,10 +345,8 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
>  		(((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) -
>  		port->memwin_base;
>  
> -	mvebu_mbus_add_window_remap_flags(port->name, port->memwin_base,
> -					  port->memwin_size,
> -					  MVEBU_MBUS_NO_REMAP,
> -					  MVEBU_MBUS_PCI_MEM);
> +	mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr,
> +				    port->memwin_base, port->memwin_size);
>  }
>  
>  /*
> @@ -755,12 +756,54 @@ mvebu_pcie_map_registers(struct platform_device *pdev,
>  	return devm_request_and_ioremap(&pdev->dev, &regs);
>  }
>  
> +#define DT_FLAGS_TO_TYPE(flags)       (((flags) >> 24) & 0x03)
> +#define    DT_TYPE_IO                 0x1
> +#define    DT_TYPE_MEM32              0x2
> +#define DT_CPUADDR_TO_TARGET(cpuaddr) (((cpuaddr) >> 56) & 0xFF)
> +#define DT_CPUADDR_TO_ATTR(cpuaddr)   (((cpuaddr) >> 48) & 0xFF)
> +
> +static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
> +			      unsigned long type, int *tgt, int *attr)
> +{
> +	const int na = 3, ns = 2;
> +	const __be32 *range;
> +	int rlen, nranges, rangesz, pna, i;
> +
> +	range = of_get_property(np, "ranges", &rlen);
> +	if (!range)
> +		return -EINVAL;
> +
> +	pna = of_n_addr_cells(np);
> +	rangesz = pna + na + ns;
> +	nranges = rlen / sizeof(__be32) / rangesz;
> +
> +	for (i = 0; i < nranges; i++) {
> +		u32 flags = of_read_number(range, 1);
> +		u32 slot = of_read_number(range, 2);
> +		u64 cpuaddr = of_read_number(range + na, pna);
> +		unsigned long rtype;
> +
> +		if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_IO)
> +			rtype = IORESOURCE_IO;
> +		else if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_MEM32)
> +			rtype = IORESOURCE_MEM;
> +
> +		if (slot == PCI_SLOT(devfn) && type == rtype) {
> +			*tgt = DT_CPUADDR_TO_TARGET(cpuaddr);
> +			*attr = DT_CPUADDR_TO_ATTR(cpuaddr);
> +			return 0;
> +		}
> +
> +		range += rangesz;
> +	}
> +
> +	return -ENOENT;
> +}
> +
>  static int __init mvebu_pcie_probe(struct platform_device *pdev)
>  {
>  	struct mvebu_pcie *pcie;
>  	struct device_node *np = pdev->dev.of_node;
> -	struct of_pci_range range;
> -	struct of_pci_range_parser parser;
>  	struct device_node *child;
>  	int i, ret;
>  
> @@ -771,29 +814,25 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
>  
>  	pcie->pdev = pdev;
>  
> -	if (of_pci_range_parser_init(&parser, np))
> +	/* Get the PCIe memory and I/O aperture */
> +	mvebu_mbus_get_pcie_mem_aperture(&pcie->mem);
> +	if (resource_size(&pcie->mem) == 0) {
> +		dev_err(&pdev->dev, "invalid memory aperture size\n");
>  		return -EINVAL;
> +	}
>  
> -	/* Get the I/O and memory ranges from DT */
> -	for_each_of_pci_range(&parser, &range) {
> -		unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
> -		if (restype == IORESOURCE_IO) {
> -			of_pci_range_to_resource(&range, np, &pcie->io);
> -			of_pci_range_to_resource(&range, np, &pcie->realio);
> -			pcie->io.name = "I/O";
> -			pcie->realio.start = max_t(resource_size_t,
> -						   PCIBIOS_MIN_IO,
> -						   range.pci_addr);
> -			pcie->realio.end = min_t(resource_size_t,
> -						 IO_SPACE_LIMIT,
> -						 range.pci_addr + range.size);
> -		}
> -		if (restype == IORESOURCE_MEM) {
> -			of_pci_range_to_resource(&range, np, &pcie->mem);
> -			pcie->mem.name = "MEM";
> -		}
> +	mvebu_mbus_get_pcie_io_aperture(&pcie->io);
> +	if (resource_size(&pcie->io) == 0) {
> +		dev_err(&pdev->dev, "invalid I/O aperture size\n");
> +		return -EINVAL;
>  	}
>  
> +	pcie->realio.flags = pcie->io.flags;
> +	pcie->realio.start = PCIBIOS_MIN_IO;
> +	pcie->realio.end = min_t(resource_size_t,
> +				  IO_SPACE_LIMIT,
> +				  resource_size(&pcie->io));
> +
>  	/* Get the bus range */
>  	ret = of_pci_parse_bus_range(np, &pcie->busn);
>  	if (ret) {
> @@ -841,6 +880,22 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
>  		if (port->devfn < 0)
>  			continue;
>  
> +		ret = mvebu_get_tgt_attr(np, port->devfn, IORESOURCE_MEM,
> +					 &port->mem_target, &port->mem_attr);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev, "PCIe%d.%d: cannot get tgt/attr for mem window\n",
> +				port->port, port->lane);
> +			continue;
> +		}
> +
> +		ret = mvebu_get_tgt_attr(np, port->devfn, IORESOURCE_IO,
> +					 &port->io_target, &port->io_attr);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev, "PCIe%d.%d: cannot get tgt/attr for io window\n",
> +				port->port, port->lane);
> +			continue;
> +		}
> +
>  		port->base = mvebu_pcie_map_registers(pdev, child, port);
>  		if (!port->base) {
>  			dev_err(&pdev->dev, "PCIe%d.%d: cannot map registers\n",
> -- 
> 1.8.1.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From s.hauer at pengutronix.de  Tue Jul  9 14:20:46 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 9 Jul 2013 20:20:46 +0200
Subject: [PATCH 3/3] ARM: imx: mm-imx3: Free l2x0_base
In-Reply-To: <CAOMZO5D4ivbqYovVA2CpXEemrAq8Nyn5By8-iL3SAnw=mpJ+og@mail.gmail.com>
References: <1373306318-15604-1-git-send-email-festevam@gmail.com>
 <1373306318-15604-3-git-send-email-festevam@gmail.com>
 <20130709062414.GG16656@S2101-09.ap.freescale.net>
 <CAOMZO5D4ivbqYovVA2CpXEemrAq8Nyn5By8-iL3SAnw=mpJ+og@mail.gmail.com>
Message-ID: <20130709182046.GD516@pengutronix.de>

On Tue, Jul 09, 2013 at 03:16:00PM -0300, Fabio Estevam wrote:
> On Tue, Jul 9, 2013 at 3:24 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> > On Mon, Jul 08, 2013 at 02:58:38PM -0300, Fabio Estevam wrote:
> >> From: Fabio Estevam <fabio.estevam at freescale.com>
> >>
> >> After l2x0_base has been used, we should free it.
> >>
> >> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> >> ---
> >>  arch/arm/mach-imx/mm-imx3.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/arch/arm/mach-imx/mm-imx3.c b/arch/arm/mach-imx/mm-imx3.c
> >> index 0884ca9..3143f5e 100644
> >> --- a/arch/arm/mach-imx/mm-imx3.c
> >> +++ b/arch/arm/mach-imx/mm-imx3.c
> >> @@ -113,6 +113,7 @@ static void __init imx3_init_l2x0(void)
> >>       }
> >>
> >>       l2x0_init(l2x0_base, 0x00030024, 0x00000000);
> >> +     iounmap(l2x0_base);
> >
> > Are you sure?  I think cache-l2x0 driver still needs the mapping after
> > that.
> 
> l2x0_base is a local variable of the static imx3_init_l2x0() function,
> so we should iounmap it.

l2x0_base is passed to l2x0_init which uses it for the outer cache
maintenance operations. I wonder this doesn't crash your kernel.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From bhelgaas at google.com  Tue Jul  9 14:50:47 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Tue, 9 Jul 2013 12:50:47 -0600
Subject: [PATCH v7 11/22] PCI: mvebu: Adapt to the new device tree layout
In-Reply-To: <20130709182026.GJ11908@titan.lakedaemon.net>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1373388084-29520-12-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130709182026.GJ11908@titan.lakedaemon.net>
Message-ID: <CAErSpo5uhDRWNnEvTewU=RnV7VW_em=PbvyQZh2PkEy8pCsGwg@mail.gmail.com>

On Tue, Jul 9, 2013 at 12:20 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> Bjorn,
>
> On Tue, Jul 09, 2013 at 01:41:13PM -0300, Ezequiel Garcia wrote:
>> From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>>
>> The new device tree layout encodes the window's target ID and attribute
>> in the PCIe controller node's ranges property. This allows to parse
>> such entries to obtain such information and use the recently introduced
>> MBus API to create the windows, instead of using the current name based
>> scheme.
>>
>> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>> ---
>>  .../devicetree/bindings/pci/mvebu-pci.txt          | 145 ++++++++++++++++-----
>>  drivers/pci/host/pci-mvebu.c                       | 113 +++++++++++-----
>>  2 files changed, 193 insertions(+), 65 deletions(-)
>
> After my conversation with tglx a few days ago [1], I'm even more
> inclined to push patches like this to the correct maintainers.  However,
> looking at how this patch fits into the series, it may be better if we
> take it through mvebu/arm-soc with your Ack.
>
> It depends on the patches before it, and the patches after it depend on
> it.  Unless I'm reading this wrong, I would have a branch that you would
> pull and base this patch on, which I would then pull and base the rest
> of the series on. Reshuffling the series to alleviate this wouldn't work
> in this case. :-/
>
> Are you ok with that?  (fwiw, the code changes are isolated to
> pci-mvebu.c)

Yep, that makes sense to me.  With dependencies both ways, it just
seems much simpler to have you push it via mvebu/arm-soc.

Acked-by: Bjorn Helgaas <bhelgaas at google.com>

> thx,
>
> Jason.
>
> [1] http://www.spinics.net/lists/arm-kernel/msg257447.html
>
>>
>> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
>> index f8d4058..9556e2f 100644
>> --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
>> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
>> @@ -1,6 +1,7 @@
>>  * Marvell EBU PCIe interfaces
>>
>>  Mandatory properties:
>> +
>>  - compatible: one of the following values:
>>      marvell,armada-370-pcie
>>      marvell,armada-xp-pcie
>> @@ -10,11 +11,49 @@ Mandatory properties:
>>  - #interrupt-cells, set to <1>
>>  - bus-range: PCI bus numbers covered
>>  - device_type, set to "pci"
>> -- ranges: ranges for the PCI memory and I/O regions, as well as the
>> -  MMIO registers to control the PCIe interfaces.
>> +- ranges: ranges describing the MMIO registers to control the PCIe
>> +  interfaces, and ranges describing the MBus windows needed to access
>> +  the memory and I/O regions of each PCIe interface.
>> +
>> +The ranges describing the MMIO registers have the following layout:
>> +
>> +    0x82000000 0 r MBUS_ID(0xf0, 0x01) r 0 s
>> +
>> +where:
>> +
>> +  * r is a 32-bits value that gives the offset of the MMIO
>> +  registers of this PCIe interface, from the base of the internal
>> +  registers.
>> +
>> +  * s is a 32-bits value that give the size of this MMIO
>> +  registers area. This range entry translates the '0x82000000 0 r' PCI
>> +  address into the 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part
>> +  of the internal register window (as identified by MBUS_ID(0xf0,
>> +  0x01)).
>> +
>> +The ranges describing the MBus windows have the following layout:
>> +
>> +    0x8t000000 s 0     MBUS_ID(w, a) 0 1 0
>> +
>> +where:
>> +
>> +   * t is the type of the MBus window (as defined by the standard PCI DT
>> +   bindings), 1 for I/O and 2 for memory.
>>
>> -In addition, the Device Tree node must have sub-nodes describing each
>> +   * s is the PCI slot that corresponds to this PCIe interface
>> +
>> +   * w is the 'target ID' value for the MBus window
>> +
>> +   * a the 'attribute' value for the MBus window.
>> +
>> +Since the location and size of the different MBus windows is not fixed in
>> +hardware, and only determined in runtime, those ranges cover the full first
>> +4 GB of the physical address space, and do not translate into a valid CPU
>> +address.
>> +
>> +In addition, the device tree node must have sub-nodes describing each
>>  PCIe interface, having the following mandatory properties:
>> +
>>  - reg: used only for interrupt mapping, so only the first four bytes
>>    are used to refer to the correct bus number and device number.
>>  - assigned-addresses: reference to the MMIO registers used to control
>> @@ -26,7 +65,8 @@ PCIe interface, having the following mandatory properties:
>>  - #address-cells, set to <3>
>>  - #size-cells, set to <2>
>>  - #interrupt-cells, set to <1>
>> -- ranges, empty property.
>> +- ranges, translating the MBus windows ranges of the parent node into
>> +  standard PCI addresses.
>>  - interrupt-map-mask and interrupt-map, standard PCI properties to
>>    define the mapping of the PCIe interface to interrupt numbers.
>>
>> @@ -47,27 +87,50 @@ pcie-controller {
>>
>>       bus-range = <0x00 0xff>;
>>
>> -     ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
>> -               0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
>> -               0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
>> -               0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
>> -               0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
>> -               0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
>> -               0x82000000 0 0xd0082000 0xd0082000 0 0x00002000   /* Port 3.0 registers */
>> -               0x82000000 0 0xd0084000 0xd0084000 0 0x00002000   /* Port 1.1 registers */
>> -               0x82000000 0 0xd0088000 0xd0088000 0 0x00002000   /* Port 1.2 registers */
>> -               0x82000000 0 0xd008c000 0xd008c000 0 0x00002000   /* Port 1.3 registers */
>> -               0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
>> -               0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
>> +     ranges =
>> +            <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
>> +             0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
>> +             0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
>> +             0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
>> +             0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
>> +             0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000   /* Port 1.0 registers */
>> +             0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000   /* Port 3.0 registers */
>> +             0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000   /* Port 1.1 registers */
>> +             0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000   /* Port 1.2 registers */
>> +             0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000   /* Port 1.3 registers */
>> +             0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
>> +             0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
>> +             0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
>> +             0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
>> +             0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
>> +             0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
>> +             0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
>> +             0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
>> +
>> +             0x82000000 0x5 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
>> +             0x81000000 0x5 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
>> +             0x82000000 0x6 0     MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */
>> +             0x81000000 0x6 0     MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO  */
>> +             0x82000000 0x7 0     MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */
>> +             0x81000000 0x7 0     MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO  */
>> +             0x82000000 0x8 0     MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */
>> +             0x81000000 0x8 0     MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO  */
>> +
>> +             0x82000000 0x9 0     MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
>> +             0x81000000 0x9 0     MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */
>> +
>> +             0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
>> +             0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
>>
>>       pcie at 1,0 {
>>               device_type = "pci";
>> -             assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
>> +             assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
>>               reg = <0x0800 0 0 0 0>;
>>               #address-cells = <3>;
>>               #size-cells = <2>;
>>               #interrupt-cells = <1>;
>> -             ranges;
>> +             ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
>> +                       0x81000000 0 0 0x81000000 0x1 0 1 0>;
>>               interrupt-map-mask = <0 0 0 0>;
>>               interrupt-map = <0 0 0 0 &mpic 58>;
>>               marvell,pcie-port = <0>;
>> @@ -78,12 +141,13 @@ pcie-controller {
>>
>>       pcie at 2,0 {
>>               device_type = "pci";
>> -             assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>;
>> +             assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
>>               reg = <0x1000 0 0 0 0>;
>>               #address-cells = <3>;
>>               #size-cells = <2>;
>>               #interrupt-cells = <1>;
>> -             ranges;
>> +             ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
>> +                       0x81000000 0 0 0x81000000 0x2 0 1 0>;
>>               interrupt-map-mask = <0 0 0 0>;
>>               interrupt-map = <0 0 0 0 &mpic 59>;
>>               marvell,pcie-port = <0>;
>> @@ -94,12 +158,13 @@ pcie-controller {
>>
>>       pcie at 3,0 {
>>               device_type = "pci";
>> -             assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>;
>> +             assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
>>               reg = <0x1800 0 0 0 0>;
>>               #address-cells = <3>;
>>               #size-cells = <2>;
>>               #interrupt-cells = <1>;
>> -             ranges;
>> +             ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
>> +                       0x81000000 0 0 0x81000000 0x3 0 1 0>;
>>               interrupt-map-mask = <0 0 0 0>;
>>               interrupt-map = <0 0 0 0 &mpic 60>;
>>               marvell,pcie-port = <0>;
>> @@ -110,12 +175,13 @@ pcie-controller {
>>
>>       pcie at 4,0 {
>>               device_type = "pci";
>> -             assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>;
>> +             assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
>>               reg = <0x2000 0 0 0 0>;
>>               #address-cells = <3>;
>>               #size-cells = <2>;
>>               #interrupt-cells = <1>;
>> -             ranges;
>> +             ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
>> +                       0x81000000 0 0 0x81000000 0x4 0 1 0>;
>>               interrupt-map-mask = <0 0 0 0>;
>>               interrupt-map = <0 0 0 0 &mpic 61>;
>>               marvell,pcie-port = <0>;
>> @@ -126,12 +192,13 @@ pcie-controller {
>>
>>       pcie at 5,0 {
>>               device_type = "pci";
>> -             assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
>> +             assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
>>               reg = <0x2800 0 0 0 0>;
>>               #address-cells = <3>;
>>               #size-cells = <2>;
>>               #interrupt-cells = <1>;
>> -             ranges;
>> +             ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
>> +                       0x81000000 0 0 0x81000000 0x5 0 1 0>;
>>               interrupt-map-mask = <0 0 0 0>;
>>               interrupt-map = <0 0 0 0 &mpic 62>;
>>               marvell,pcie-port = <1>;
>> @@ -142,12 +209,13 @@ pcie-controller {
>>
>>       pcie at 6,0 {
>>               device_type = "pci";
>> -             assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>;
>> +             assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
>>               reg = <0x3000 0 0 0 0>;
>>               #address-cells = <3>;
>>               #size-cells = <2>;
>>               #interrupt-cells = <1>;
>> -             ranges;
>> +             ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0
>> +                       0x81000000 0 0 0x81000000 0x6 0 1 0>;
>>               interrupt-map-mask = <0 0 0 0>;
>>               interrupt-map = <0 0 0 0 &mpic 63>;
>>               marvell,pcie-port = <1>;
>> @@ -158,12 +226,13 @@ pcie-controller {
>>
>>       pcie at 7,0 {
>>               device_type = "pci";
>> -             assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>;
>> +             assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
>>               reg = <0x3800 0 0 0 0>;
>>               #address-cells = <3>;
>>               #size-cells = <2>;
>>               #interrupt-cells = <1>;
>> -             ranges;
>> +             ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0
>> +                       0x81000000 0 0 0x81000000 0x7 0 1 0>;
>>               interrupt-map-mask = <0 0 0 0>;
>>               interrupt-map = <0 0 0 0 &mpic 64>;
>>               marvell,pcie-port = <1>;
>> @@ -174,12 +243,13 @@ pcie-controller {
>>
>>       pcie at 8,0 {
>>               device_type = "pci";
>> -             assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>;
>> +             assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
>>               reg = <0x4000 0 0 0 0>;
>>               #address-cells = <3>;
>>               #size-cells = <2>;
>>               #interrupt-cells = <1>;
>> -             ranges;
>> +             ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0
>> +                       0x81000000 0 0 0x81000000 0x8 0 1 0>;
>>               interrupt-map-mask = <0 0 0 0>;
>>               interrupt-map = <0 0 0 0 &mpic 65>;
>>               marvell,pcie-port = <1>;
>> @@ -187,14 +257,16 @@ pcie-controller {
>>               clocks = <&gateclk 12>;
>>               status = "disabled";
>>       };
>> +
>>       pcie at 9,0 {
>>               device_type = "pci";
>> -             assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>;
>> +             assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
>>               reg = <0x4800 0 0 0 0>;
>>               #address-cells = <3>;
>>               #size-cells = <2>;
>>               #interrupt-cells = <1>;
>> -             ranges;
>> +             ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
>> +                       0x81000000 0 0 0x81000000 0x9 0 1 0>;
>>               interrupt-map-mask = <0 0 0 0>;
>>               interrupt-map = <0 0 0 0 &mpic 99>;
>>               marvell,pcie-port = <2>;
>> @@ -205,12 +277,13 @@ pcie-controller {
>>
>>       pcie at 10,0 {
>>               device_type = "pci";
>> -             assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>;
>> +             assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
>>               reg = <0x5000 0 0 0 0>;
>>               #address-cells = <3>;
>>               #size-cells = <2>;
>>               #interrupt-cells = <1>;
>> -             ranges;
>> +             ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
>> +                       0x81000000 0 0 0x81000000 0xa 0 1 0>;
>>               interrupt-map-mask = <0 0 0 0>;
>>               interrupt-map = <0 0 0 0 &mpic 103>;
>>               marvell,pcie-port = <3>;
>> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
>> index 13a633b..424a7b8 100644
>> --- a/drivers/pci/host/pci-mvebu.c
>> +++ b/drivers/pci/host/pci-mvebu.c
>> @@ -123,6 +123,10 @@ struct mvebu_pcie_port {
>>       u32 port;
>>       u32 lane;
>>       int devfn;
>> +     unsigned int mem_target;
>> +     unsigned int mem_attr;
>> +     unsigned int io_target;
>> +     unsigned int io_attr;
>>       struct clk *clk;
>>       struct mvebu_sw_pci_bridge bridge;
>>       struct device_node *dn;
>> @@ -307,10 +311,9 @@ static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port *port)
>>                           (port->bridge.iolimitupper << 16)) -
>>                           iobase);
>>
>> -     mvebu_mbus_add_window_remap_flags(port->name, port->iowin_base,
>> -                                       port->iowin_size,
>> -                                       iobase,
>> -                                       MVEBU_MBUS_PCI_IO);
>> +     mvebu_mbus_add_window_remap_by_id(port->io_target, port->io_attr,
>> +                                       port->iowin_base, port->iowin_size,
>> +                                       iobase);
>>
>>       pci_ioremap_io(iobase, port->iowin_base);
>>  }
>> @@ -342,10 +345,8 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
>>               (((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) -
>>               port->memwin_base;
>>
>> -     mvebu_mbus_add_window_remap_flags(port->name, port->memwin_base,
>> -                                       port->memwin_size,
>> -                                       MVEBU_MBUS_NO_REMAP,
>> -                                       MVEBU_MBUS_PCI_MEM);
>> +     mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr,
>> +                                 port->memwin_base, port->memwin_size);
>>  }
>>
>>  /*
>> @@ -755,12 +756,54 @@ mvebu_pcie_map_registers(struct platform_device *pdev,
>>       return devm_request_and_ioremap(&pdev->dev, &regs);
>>  }
>>
>> +#define DT_FLAGS_TO_TYPE(flags)       (((flags) >> 24) & 0x03)
>> +#define    DT_TYPE_IO                 0x1
>> +#define    DT_TYPE_MEM32              0x2
>> +#define DT_CPUADDR_TO_TARGET(cpuaddr) (((cpuaddr) >> 56) & 0xFF)
>> +#define DT_CPUADDR_TO_ATTR(cpuaddr)   (((cpuaddr) >> 48) & 0xFF)
>> +
>> +static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
>> +                           unsigned long type, int *tgt, int *attr)
>> +{
>> +     const int na = 3, ns = 2;
>> +     const __be32 *range;
>> +     int rlen, nranges, rangesz, pna, i;
>> +
>> +     range = of_get_property(np, "ranges", &rlen);
>> +     if (!range)
>> +             return -EINVAL;
>> +
>> +     pna = of_n_addr_cells(np);
>> +     rangesz = pna + na + ns;
>> +     nranges = rlen / sizeof(__be32) / rangesz;
>> +
>> +     for (i = 0; i < nranges; i++) {
>> +             u32 flags = of_read_number(range, 1);
>> +             u32 slot = of_read_number(range, 2);
>> +             u64 cpuaddr = of_read_number(range + na, pna);
>> +             unsigned long rtype;
>> +
>> +             if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_IO)
>> +                     rtype = IORESOURCE_IO;
>> +             else if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_MEM32)
>> +                     rtype = IORESOURCE_MEM;
>> +
>> +             if (slot == PCI_SLOT(devfn) && type == rtype) {
>> +                     *tgt = DT_CPUADDR_TO_TARGET(cpuaddr);
>> +                     *attr = DT_CPUADDR_TO_ATTR(cpuaddr);
>> +                     return 0;
>> +             }
>> +
>> +             range += rangesz;
>> +     }
>> +
>> +     return -ENOENT;
>> +}
>> +
>>  static int __init mvebu_pcie_probe(struct platform_device *pdev)
>>  {
>>       struct mvebu_pcie *pcie;
>>       struct device_node *np = pdev->dev.of_node;
>> -     struct of_pci_range range;
>> -     struct of_pci_range_parser parser;
>>       struct device_node *child;
>>       int i, ret;
>>
>> @@ -771,29 +814,25 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
>>
>>       pcie->pdev = pdev;
>>
>> -     if (of_pci_range_parser_init(&parser, np))
>> +     /* Get the PCIe memory and I/O aperture */
>> +     mvebu_mbus_get_pcie_mem_aperture(&pcie->mem);
>> +     if (resource_size(&pcie->mem) == 0) {
>> +             dev_err(&pdev->dev, "invalid memory aperture size\n");
>>               return -EINVAL;
>> +     }
>>
>> -     /* Get the I/O and memory ranges from DT */
>> -     for_each_of_pci_range(&parser, &range) {
>> -             unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
>> -             if (restype == IORESOURCE_IO) {
>> -                     of_pci_range_to_resource(&range, np, &pcie->io);
>> -                     of_pci_range_to_resource(&range, np, &pcie->realio);
>> -                     pcie->io.name = "I/O";
>> -                     pcie->realio.start = max_t(resource_size_t,
>> -                                                PCIBIOS_MIN_IO,
>> -                                                range.pci_addr);
>> -                     pcie->realio.end = min_t(resource_size_t,
>> -                                              IO_SPACE_LIMIT,
>> -                                              range.pci_addr + range.size);
>> -             }
>> -             if (restype == IORESOURCE_MEM) {
>> -                     of_pci_range_to_resource(&range, np, &pcie->mem);
>> -                     pcie->mem.name = "MEM";
>> -             }
>> +     mvebu_mbus_get_pcie_io_aperture(&pcie->io);
>> +     if (resource_size(&pcie->io) == 0) {
>> +             dev_err(&pdev->dev, "invalid I/O aperture size\n");
>> +             return -EINVAL;
>>       }
>>
>> +     pcie->realio.flags = pcie->io.flags;
>> +     pcie->realio.start = PCIBIOS_MIN_IO;
>> +     pcie->realio.end = min_t(resource_size_t,
>> +                               IO_SPACE_LIMIT,
>> +                               resource_size(&pcie->io));
>> +
>>       /* Get the bus range */
>>       ret = of_pci_parse_bus_range(np, &pcie->busn);
>>       if (ret) {
>> @@ -841,6 +880,22 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
>>               if (port->devfn < 0)
>>                       continue;
>>
>> +             ret = mvebu_get_tgt_attr(np, port->devfn, IORESOURCE_MEM,
>> +                                      &port->mem_target, &port->mem_attr);
>> +             if (ret < 0) {
>> +                     dev_err(&pdev->dev, "PCIe%d.%d: cannot get tgt/attr for mem window\n",
>> +                             port->port, port->lane);
>> +                     continue;
>> +             }
>> +
>> +             ret = mvebu_get_tgt_attr(np, port->devfn, IORESOURCE_IO,
>> +                                      &port->io_target, &port->io_attr);
>> +             if (ret < 0) {
>> +                     dev_err(&pdev->dev, "PCIe%d.%d: cannot get tgt/attr for io window\n",
>> +                             port->port, port->lane);
>> +                     continue;
>> +             }
>> +
>>               port->base = mvebu_pcie_map_registers(pdev, child, port);
>>               if (!port->base) {
>>                       dev_err(&pdev->dev, "PCIe%d.%d: cannot map registers\n",
>> --
>> 1.8.1.5
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From jason at lakedaemon.net  Tue Jul  9 14:54:00 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 9 Jul 2013 14:54:00 -0400
Subject: [PATCH v7 11/22] PCI: mvebu: Adapt to the new device tree layout
In-Reply-To: <CAErSpo5uhDRWNnEvTewU=RnV7VW_em=PbvyQZh2PkEy8pCsGwg@mail.gmail.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1373388084-29520-12-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130709182026.GJ11908@titan.lakedaemon.net>
 <CAErSpo5uhDRWNnEvTewU=RnV7VW_em=PbvyQZh2PkEy8pCsGwg@mail.gmail.com>
Message-ID: <20130709185400.GM11908@titan.lakedaemon.net>

On Tue, Jul 09, 2013 at 12:50:47PM -0600, Bjorn Helgaas wrote:
> On Tue, Jul 9, 2013 at 12:20 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> > Bjorn,
> >
> > On Tue, Jul 09, 2013 at 01:41:13PM -0300, Ezequiel Garcia wrote:
> >> From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> >>
> >> The new device tree layout encodes the window's target ID and attribute
> >> in the PCIe controller node's ranges property. This allows to parse
> >> such entries to obtain such information and use the recently introduced
> >> MBus API to create the windows, instead of using the current name based
> >> scheme.
> >>
> >> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> >> ---
> >>  .../devicetree/bindings/pci/mvebu-pci.txt          | 145 ++++++++++++++++-----
> >>  drivers/pci/host/pci-mvebu.c                       | 113 +++++++++++-----
> >>  2 files changed, 193 insertions(+), 65 deletions(-)
> >
> > After my conversation with tglx a few days ago [1], I'm even more
> > inclined to push patches like this to the correct maintainers.  However,
> > looking at how this patch fits into the series, it may be better if we
> > take it through mvebu/arm-soc with your Ack.
> >
> > It depends on the patches before it, and the patches after it depend on
> > it.  Unless I'm reading this wrong, I would have a branch that you would
> > pull and base this patch on, which I would then pull and base the rest
> > of the series on. Reshuffling the series to alleviate this wouldn't work
> > in this case. :-/
> >
> > Are you ok with that?  (fwiw, the code changes are isolated to
> > pci-mvebu.c)
> 
> Yep, that makes sense to me.  With dependencies both ways, it just
> seems much simpler to have you push it via mvebu/arm-soc.
> 
> Acked-by: Bjorn Helgaas <bhelgaas at google.com>

Will do, thanks Bjorn!

thx,

Jason.


From grygorii.strashko at ti.com  Tue Jul  9 14:59:28 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Tue, 9 Jul 2013 21:59:28 +0300
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130709064212.GB5552@arwen.pp.htv.fi>
References: <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <51DBA0C2.6030003@ti.com>
 <20130709064212.GB5552@arwen.pp.htv.fi>
Message-ID: <51DC5D90.1010603@ti.com>

Hi,

On 07/09/2013 09:42 AM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 09, 2013 at 11:03:54AM +0530, Rajendra Nayak wrote:
>> On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
>>>>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>>>>>> of -1 for the serial driver?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>>>>>
>>>>>>> OK
>>>>>>
>>>>>> Issue 2: Causing boot to stop when serial driver is initialized.
>>>>>> (After Issue 1 is fixed)
>>>>>>
>>>>>> I could narrow this down to the change done to return -EINVAL
>>>>>> instead of 0 in serial_omap_get_context_loss_count() as part of
>>>>>> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
>>>>>> Fix device tree based PM runtime"
>>>>>>
>>>>>> What this change in turn seems to do is cause a
>>>>>> serial_omap_restore_context() to get called as part of
>>>>>> serial_omap_runtime_resume() which was not the case when
>>>>>> serial_omap_get_context_loss_count() returned 0
>>>>>>
>>>>>> from serial_omap_runtime_resume():
>>>>>> -----
>>>>>>          int loss_cnt = serial_omap_get_context_loss_count(up);
>>>>>>
>>>>>>          if (loss_cnt < 0) {
>>>>>>                  dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>>>>>                          loss_cnt);
>>>>>>                  serial_omap_restore_context(up);
>>>>>>          } else if (up->context_loss_cnt != loss_cnt) {
>>>>>>                  serial_omap_restore_context(up);
>>>>>>          }
>>>>>> -----
>>>>>>
>>>>>> I am still working on why a serial_omap_restore_context() could
>>>>>> have caused console to die. I will work with Sourav on this and
>>>>>> post the fixes for both issue 1 and issue2 once its clear on whats
>>>>>> really causing issue 2.
>>>>>
>>>>> That's because we don't have the omap specific pdata callbacks for
>>>>> context loss any longer. We may be able to detect when the context
>>>>> was really lost in the serial driver, and only then call the
>>>>> serial_omap_restore_context().
>>>>
>>>> Right, but calling serial_omap_restore_context() even when the context
>>>> is not lost, should not ideally cause an issue.
>>>
>>> it does in one condition. If context hasn't been saved before. And that
>>> can happen in the case of wrong pm runtime status for that device.
>>>
>>> Imagine the device is marked as suspended even though it's fully enabled
>>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
>>> your context structure is all zeroes (context has never been saved
>>> before) then when you call pm_runtime_get_sync() on probe() your
>>> ->runtime_resume() will get called, which will restore context,
>>> essentially undoing anything which was configured by u-boot.
>>
>> This could be a problem for drivers which do a save context in ->runtime_suspend()
>> but from what I see with omap serial, there is no save context done as part of
>> ->runtime_suspend.
>
> right, because context is "saved" in set_termios. probe() will get
> called much before set_termios() has a chance to run, right ?
>
> Same problem will trigger in that case.
>
> I still think patch below is necessary
>
>>> (completely untested, didn't even try to compile, just to illustrate)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
>>> index 7341eff..d8dca68 100644
>>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>>> @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
>>>   	    (postsetup_state == _HWMOD_STATE_IDLE)) {
>>>   		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
>>>   		postsetup_state = _HWMOD_STATE_ENABLED;
>>> +
>>> +		/* tell pm_runtime this device is already active */
>>> +		pm_runtime_set_active(&oh->od->pdev->dev);
>>> +	} else {
>>> +		/* tell pm_runtime this device is trully suspended */
>>> +		pm_runtime_set_suspended(&oh->od->pdev->dev);
>>>   	}
>>>
>>>   	if (postsetup_state == _HWMOD_STATE_IDLE)
>

This will not work - _setup_postsetup() is called from core_initcall 
level and OMAP devices have not been created at this moment yet 
(of_platform_populate() is called from
customize_machine->init_machine->omap_generic_init() at arch_initcall time)

More over, I don't recommend to depend on hwmod->od field - it's been 
created to support OPPs and it's obsolete now in case of DT use.

Seems, This issue need to be handled in driver for DT boot use case, 
possibly cmdline need to be parsed in the same way as it's done in
omap_serial_early_init().

Regards,
-grygorii



From swarren at wwwdotorg.org  Tue Jul  9 15:07:26 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 09 Jul 2013 13:07:26 -0600
Subject: [PATCH v7 11/22] PCI: mvebu: Adapt to the new device tree layout
In-Reply-To: <20130709182026.GJ11908@titan.lakedaemon.net>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1373388084-29520-12-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130709182026.GJ11908@titan.lakedaemon.net>
Message-ID: <51DC5F6E.2080304@wwwdotorg.org>

On 07/09/2013 12:20 PM, Jason Cooper wrote:
> Bjorn,
> 
> On Tue, Jul 09, 2013 at 01:41:13PM -0300, Ezequiel Garcia wrote:
>> From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>>
>> The new device tree layout encodes the window's target ID and attribute
>> in the PCIe controller node's ranges property. This allows to parse
>> such entries to obtain such information and use the recently introduced
>> MBus API to create the windows, instead of using the current name based
>> scheme.
>>
>> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>> ---
>>  .../devicetree/bindings/pci/mvebu-pci.txt          | 145 ++++++++++++++++-----
>>  drivers/pci/host/pci-mvebu.c                       | 113 +++++++++++-----
>>  2 files changed, 193 insertions(+), 65 deletions(-)
> 
> After my conversation with tglx a few days ago [1], I'm even more
> inclined to push patches like this to the correct maintainers.  However,
> looking at how this patch fits into the series, it may be better if we
> take it through mvebu/arm-soc with your Ack.
> 
> It depends on the patches before it, and the patches after it depend on
> it.  Unless I'm reading this wrong, I would have a branch that you would
> pull and base this patch on, which I would then pull and base the rest
> of the series on. Reshuffling the series to alleviate this wouldn't work
> in this case. :-/

My experience has been:

The create-a-topic-branch-and-merge-it-multiple-places process is more
useful when you've got a series that does:

1) Create some new common infra-structure.
2) Something that uses the new infra-structure.

... and you expect that other patches will come along (or already exist)
that use the new common infra-structure too; we'll call those (3). This
applies especially when (2) and (3) will want to go in through different
trees.

Then, you'd typically create a topic branch for (1) above, and merge
that both wherever (2) and (3) will be applied.

For simpler cases, acks are much more common.


From dianders at chromium.org  Tue Jul  9 15:09:42 2013
From: dianders at chromium.org (Doug Anderson)
Date: Tue, 9 Jul 2013 12:09:42 -0700
Subject: [PATCH 3/5] mmc: dw_mmc: Add exynos resume callback to clear
 WAKEUP_INT
In-Reply-To: <1373391071-6312-4-git-send-email-dianders@chromium.org>
References: <1373391071-6312-1-git-send-email-dianders@chromium.org>
 <1373391071-6312-4-git-send-email-dianders@chromium.org>
Message-ID: <CAD=FV=XLp_2t83JfUBryaSvqLZr5OHEZeFZDRmQ1T=XA1MRkHg@mail.gmail.com>

Hi,

On Tue, Jul 9, 2013 at 10:31 AM, Doug Anderson <dianders at chromium.org> wrote:
> If the WAKEUP_INT is asserted at wakeup and not cleared, we'll end up
> looping around forever.
>
> Signed-off-by: Doug Anderson <dianders at chromium.org>
> ---
>  drivers/mmc/host/dw_mmc-exynos.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)

Grant just pointed out that the WAKEUP_INT is supposed to only be
enabled if bits 8, 9, or 10 are 1.  Our driver never sets those so we
_should_ never get a WAKEUP_INT.  Bits 8-10 are marked as RESERVED on
the exynos5420 manual, so the current guess is that they're broken on
that silicon but that sometimes the interrupt fires anyway.

In any case, it is still a reasonable thing to clear this interrupt at
wakeup if it has fired, even if we're on an exynos device without any
problems.

-Doug


From linux at arm.linux.org.uk  Tue Jul  9 15:13:51 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 9 Jul 2013 20:13:51 +0100
Subject: [PATCH V2] ARM: mm: restrict early_alloc_aligned to legal area
In-Reply-To: <1373387888-4137-1-git-send-email-swarren@wwwdotorg.org>
References: <1373387888-4137-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130709191350.GV24642@n2100.arm.linux.org.uk>

On Tue, Jul 09, 2013 at 10:38:08AM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> When early_alloc_aligned() is called, it appears that only memory in the
> first memory bank is mapped for CPU access. However, memblock_alloc() is
> called to allocate the RAM, and that can return RAM that is part of any
> valid memory bank, which hence could be inaccessible to the CPU. If this
> happens, the subsequent memset() will hang or crash.

Let me also be clear that historically, we never permitted non-section
mappings of normal memory; however OMAP needed to be able to map SRAM
using normal memory with executable attributes, but prevent speculative
prefetches to the secure region of SRAM, which thus had to remain unmapped.
Therefore, page mappings of normal memory were added only to allow OMAP
to make those mappings: it was *never* intended to permit standard
system memory to be mapped using page mappings, nor to permit non-
section sized mappings of system memory.

Moreover, I can assume from your patch that you haven't read the memblock
code, otherwise you'll known that memblock_alloc() has a built-in limit
which it allocates from in a top-down manner, and that limit can be
set by the architecture code (and we do already set it to the top of
lowmem.)

Lastly, the reason this happens is because at the point we encounter the
need for a page-based mapping of normal memory, the area which we allocate
from has not been made accessible.

Let me give you a variation of your problem:

- Your first chunk of memory starts a few pages in to a section
  boundary (anything within the first 16K).

The issue here is that map_lowmem() will start off by wanting to allocate
a L2 page table, but we haven't even mapped the first chunk of memory
yet (we only have a partial mapping which is sufficiently large in terms
of sections for the kernel only.)

The problem here is that if you bring the memblock limit down to that,
you will probably run out of memory you can allocate from, especially
if the end of the kernel is near to the section boundary.

Realistically, I don't think that is solvable.

Second problem:

- Your first chunk of memory doesn't finish on a section boundary.

The issue here is that even with your patch, you start allocating from
the top of the first chunk of memory, which in this case itself won't
be mapped at the time that you need to gain access to that page.
This can be worked around by rounding the limit down to a section
boundary.

However, should we be penalising other systems for this behaviour by
placing the memblock allocation at the end of the first chunk of memory,
which might be (a) in precious DMA memory on platforms with limited
DMA capabilities and (b) might be rather small because it also houses
the kernel image, especially where memory is broken up across several
sparsemem sections.

What I would like to see is a patch which modifies sanity_check_meminfo()
to deal with this and set the memblock limit appropriately.  Note that
paging_init() also calls memblock_set_current_limit(), but I think
that call can be removed now as memblock_init() has been removed (used
to be called from arm_memblock_init() - see fe091c208a) which used to
reset the limit.

So something like this (untested):

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 08b37c4..ce74fa2 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -988,6 +988,7 @@ phys_addr_t arm_lowmem_limit __initdata = 0;
 
 void __init sanity_check_meminfo(void)
 {
+	phys_addr_t memblock_limit = 0;
 	int i, j, highmem = 0;
 
 	for (i = 0, j = 0; i < meminfo.nr_banks; i++) {
@@ -1067,9 +1068,20 @@ void __init sanity_check_meminfo(void)
 			bank->size = newsize;
 		}
 #endif
-		if (!bank->highmem && bank->start + bank->size > arm_lowmem_limit)
-			arm_lowmem_limit = bank->start + bank->size;
+		if (!bank->highmem) {
+			if (bank->start + bank->size > arm_lowmem_limit)
+				arm_lowmem_limit = bank->start + bank->size;
 
+			/*
+			 * Find the first bank of memory which starts
+			 * on a section boundary, but doesn't finish
+			 * on a section boundary.
+			 */
+			if (memblock_limit == 0 &&
+			    IS_ALIGNED(bank->start, SECTION_SIZE) &&
+			    !IS_ALIGNED(bank->start + size, SECTION_SIZE))
+				memblock_limit = bank->start + bank->size;
+		}
 		j++;
 	}
 #ifdef CONFIG_HIGHMEM
@@ -1094,7 +1106,18 @@ void __init sanity_check_meminfo(void)
 #endif
 	meminfo.nr_banks = j;
 	high_memory = __va(arm_lowmem_limit - 1) + 1;
-	memblock_set_current_limit(arm_lowmem_limit);
+
+	/*
+	 * Round the memblock limit down to a section size.  This
+	 * helps to ensure that we will allocate memory from the
+	 * last full section, which should be mapped.
+	 */
+	if (memblock_limit)
+		memblock_limit = round_down(memblock_limit, SECTION_SIZE);
+	if (memblock_limit == 0)
+		memblock_limit = arm_lowmem_limit;
+
+	memblock_set_current_limit(memblock_limit);
 }
 
 static inline void prepare_page_table(void)
@@ -1297,8 +1320,6 @@ void __init paging_init(struct machine_desc *mdesc)
 {
 	void *zero_page;
 
-	memblock_set_current_limit(arm_lowmem_limit);
-
 	build_mem_type_table();
 	prepare_page_table();
 	map_lowmem();



From andrew at lunn.ch  Tue Jul  9 15:36:05 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 9 Jul 2013 21:36:05 +0200
Subject: NSA310 + DT
In-Reply-To: <51DC564A.8050002@harsszegi.com>
References: <51DC564A.8050002@harsszegi.com>
Message-ID: <20130709193605.GC26223@lunn.ch>

On Tue, Jul 09, 2013 at 08:28:26PM +0200, Tibor Harsszegi wrote:
> Hello Andrew,
> 
> sorry to bug you, but honestly couldn't find better way than this :(

Hi Tibor

Its not a problem to bug me, but please also CC: the arm kernel
mailing list. This board port was contributed by Tero Jaasko
<tero.jaasko at gmail.com>, so its good to also ask him.

> I have some issues.

A basic question to start with. Are you using the default kernel
configuration for kirkwood? Which kernel version are you using?
 
> a.) With the current NSA310 .dts the sensors are not working (at
> least on my NSA310). The reason is that the i2c sensors is a lm85
> kind

Do you know what address it is using on the i2c bus? It looks like it
would be one of: 0x2c, 0x2d, 0x2e. Does you board also have the
adt7476?

You will need to edit arch/arm/boot/dts/kirkwood-nsa310.dts and add
something like:

                        lm85: lm85 at 2c {
                                compatible = "lm85";
                                reg = <0x2c>;
                        };

inside the i2c at 11000 node.

> b.) uart0 is not recognized at all during boot, I cannot see that
> 8250 would recognize the UART at the mmaped area, however the .DTS
> config seems fine

Do you see anything like:

Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
console [ttyS0] enabled
f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A

> c.) LEDs are also not working, this is also strange, as the .DTS
> seems to be just fine as well.

How do you mean not working? Is /sys/class/leds/ empty? Or when you
change the brightness value, nothing happens?

       Andrew


From balbi at ti.com  Tue Jul  9 15:41:31 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 9 Jul 2013 22:41:31 +0300
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51DC5D90.1010603@ti.com>
References: <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <51DBA0C2.6030003@ti.com>
 <20130709064212.GB5552@arwen.pp.htv.fi> <51DC5D90.1010603@ti.com>
Message-ID: <20130709194131.GA12523@arwen.pp.htv.fi>

Hi,

On Tue, Jul 09, 2013 at 09:59:28PM +0300, Grygorii Strashko wrote:
> >>>Imagine the device is marked as suspended even though it's fully enabled
> >>>(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> >>>your context structure is all zeroes (context has never been saved
> >>>before) then when you call pm_runtime_get_sync() on probe() your
> >>>->runtime_resume() will get called, which will restore context,
> >>>essentially undoing anything which was configured by u-boot.
> >>
> >>This could be a problem for drivers which do a save context in ->runtime_suspend()
> >>but from what I see with omap serial, there is no save context done as part of
> >>->runtime_suspend.
> >
> >right, because context is "saved" in set_termios. probe() will get
> >called much before set_termios() has a chance to run, right ?
> >
> >Same problem will trigger in that case.
> >
> >I still think patch below is necessary
> >
> >>>(completely untested, didn't even try to compile, just to illustrate)
> >>>
> >>>diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> >>>index 7341eff..d8dca68 100644
> >>>--- a/arch/arm/mach-omap2/omap_hwmod.c
> >>>+++ b/arch/arm/mach-omap2/omap_hwmod.c
> >>>@@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
> >>>  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
> >>>  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
> >>>  		postsetup_state = _HWMOD_STATE_ENABLED;
> >>>+
> >>>+		/* tell pm_runtime this device is already active */
> >>>+		pm_runtime_set_active(&oh->od->pdev->dev);
> >>>+	} else {
> >>>+		/* tell pm_runtime this device is trully suspended */
> >>>+		pm_runtime_set_suspended(&oh->od->pdev->dev);
> >>>  	}
> >>>
> >>>  	if (postsetup_state == _HWMOD_STATE_IDLE)
> >
> 
> This will not work - _setup_postsetup() is called from core_initcall
> level and OMAP devices have not been created at this moment yet
> (of_platform_populate() is called from
> customize_machine->init_machine->omap_generic_init() at arch_initcall time)

fair enough, but something *like* that needs to be done. If pm_runtime
doesn't know the state of the device by the time pm_runtime_enable() is
called, the wrong assumptions might be made and we will forever have
such problems as our ->runtime_resume() callback being called when it
shouldn't.

> More over, I don't recommend to depend on hwmod->od field - it's been
> created to support OPPs and it's obsolete now in case of DT use.

that's alright, but still we need something similar.

But in any case, if on DT boot that's not used, than *what* uses
HWMOD_INIT_NO_IDLE during DT boot ?

There's a single place in kernel source which checks if
HWMOD_INIT_NO_IDLE is set, and that's the place which I patched.

We, certainly, need a way to tell pm_runtime if the device is active or
suspended by the time we reach our probe() function. Either we assume
*all* devices are active and we blindly call pm_runtime_set_active() for
all devices, or we assume *all* devices are suspended as we call
pm_runtime_set_suspend() for all devices, or we figure out which ones
are active and which are not and call pm_runtime_set_{active,suspend}()
conditionally.

> Seems, This issue need to be handled in driver for DT boot use case,
> possibly cmdline need to be parsed in the same way as it's done in
> omap_serial_early_init().

so you want *every* single driver to parse their own cmdline ? How big
would the cmdline become ? This makes no sense.

-- 
balbi
-------------- 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/20130709/d9ed7f62/attachment.sig>

From ezequiel.garcia at free-electrons.com  Tue Jul  9 16:22:03 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 9 Jul 2013 17:22:03 -0300
Subject: [PATCH v7 11/22] PCI: mvebu: Adapt to the new device tree layout
In-Reply-To: <CAErSpo5uhDRWNnEvTewU=RnV7VW_em=PbvyQZh2PkEy8pCsGwg@mail.gmail.com>
References: <1373388084-29520-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1373388084-29520-12-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130709182026.GJ11908@titan.lakedaemon.net>
 <CAErSpo5uhDRWNnEvTewU=RnV7VW_em=PbvyQZh2PkEy8pCsGwg@mail.gmail.com>
Message-ID: <20130709202201.GC2340@localhost>

On Tue, Jul 09, 2013 at 12:50:47PM -0600, Bjorn Helgaas wrote:
> On Tue, Jul 9, 2013 at 12:20 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> > On Tue, Jul 09, 2013 at 01:41:13PM -0300, Ezequiel Garcia wrote:
> >> From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> >>
> >> The new device tree layout encodes the window's target ID and attribute
> >> in the PCIe controller node's ranges property. This allows to parse
> >> such entries to obtain such information and use the recently introduced
> >> MBus API to create the windows, instead of using the current name based
> >> scheme.
> >>
> >> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> >> ---
> >>  .../devicetree/bindings/pci/mvebu-pci.txt          | 145 ++++++++++++++++-----
> >>  drivers/pci/host/pci-mvebu.c                       | 113 +++++++++++-----
> >>  2 files changed, 193 insertions(+), 65 deletions(-)
> >
> > After my conversation with tglx a few days ago [1], I'm even more
> > inclined to push patches like this to the correct maintainers.  However,
> > looking at how this patch fits into the series, it may be better if we
> > take it through mvebu/arm-soc with your Ack.
> >
> > It depends on the patches before it, and the patches after it depend on
> > it.  Unless I'm reading this wrong, I would have a branch that you would
> > pull and base this patch on, which I would then pull and base the rest
> > of the series on. Reshuffling the series to alleviate this wouldn't work
> > in this case. :-/
> >
> > Are you ok with that?  (fwiw, the code changes are isolated to
> > pci-mvebu.c)
> 
> Yep, that makes sense to me.  With dependencies both ways, it just
> seems much simpler to have you push it via mvebu/arm-soc.
> 
> Acked-by: Bjorn Helgaas <bhelgaas at google.com>
> 

Great, Thanks!

Arnd, Jason (Gunthorpe):

So, how does this look? If there isn't anything left, would you mind
acking this so Jason (Cooper) can queue it somewhere?

Thanks!
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From andrew at lunn.ch  Tue Jul  9 16:21:43 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 9 Jul 2013 22:21:43 +0200
Subject: NSA310 + DT
In-Reply-To: <20130709193605.GC26223@lunn.ch>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
Message-ID: <20130709202143.GD26223@lunn.ch>

On Tue, Jul 09, 2013 at 09:36:05PM +0200, Andrew Lunn wrote:
> On Tue, Jul 09, 2013 at 08:28:26PM +0200, Tibor Harsszegi wrote:
> > Hello Andrew,
> > 
> > sorry to bug you, but honestly couldn't find better way than this :(
> 
> Hi Tibor
> 
> Its not a problem to bug me, but please also CC: the arm kernel
> mailing list. This board port was contributed by Tero Jaasko
> <tero.jaasko at gmail.com>, so its good to also ask him.
> 
> > I have some issues.
> 
> A basic question to start with. Are you using the default kernel
> configuration for kirkwood? Which kernel version are you using?
>  
> > a.) With the current NSA310 .dts the sensors are not working (at
> > least on my NSA310). The reason is that the i2c sensors is a lm85
> > kind

Hi Tibor

Which NSA310 do you actually have? Apparently there are actually two
variants:

http://zyxel.nas-central.org/wiki/Category:NSA-310

It could be yours is actually the rebranded TDC Homedisk. If so, we
should add a new .dts file for it.

       Andrew


From arnd at arndb.de  Tue Jul  9 17:06:37 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Jul 2013 23:06:37 +0200
Subject: [PATCH 01/04] ARM: shmobile: Only build clocks when COMMON_CLK=n
In-Reply-To: <CANqRtoRJhrbT4NMv4e7NwvXj0JoO001ShtjSwdquv7x-7dxKeA@mail.gmail.com>
References: <20130709054331.14007.66068.sendpatchset@w520>
 <1774541.9WRl3VrJqz@avalon>
 <CANqRtoRJhrbT4NMv4e7NwvXj0JoO001ShtjSwdquv7x-7dxKeA@mail.gmail.com>
Message-ID: <201307092306.38004.arnd@arndb.de>

On Tuesday 09 July 2013, Magnus Damm wrote:
> >>
> >> +ifndef CONFIG_COMMON_CLK
> >>  obj-$(CONFIG_ARCH_SH7372)      += setup-sh7372.o intc-sh7372.o
> >>  obj-$(CONFIG_ARCH_SH73A0)      += setup-sh73a0.o intc-sh73a0.o
> >>  obj-$(CONFIG_ARCH_R8A73A4)     += setup-r8a73a4.o
> >>  obj-$(CONFIG_ARCH_R8A7740)     += setup-r8a7740.o intc-r8a7740.o
> >>  obj-$(CONFIG_ARCH_R8A7778)     += setup-r8a7778.o
> >>  obj-$(CONFIG_ARCH_R8A7779)     += setup-r8a7779.o intc-r8a7779.o
> >>  obj-$(CONFIG_ARCH_R8A7790)     += setup-r8a7790.o
> >>  obj-$(CONFIG_ARCH_EMEV2)       += setup-emev2.o
> >> +endif
> >
> > I was about to mention the same, so I think that would be a good idea.
> 
> Sure, that may be a more common way to handle this. =)
> 
> To be clear, I assume you wanted that ifndef to cover the clock-xxx.c
> files instead of setup-xxx.c. So I will do that in next version.
> 

Yes, that's right, sorry for screwing up the example.

	Arnd


From arnd at arndb.de  Tue Jul  9 17:07:03 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Jul 2013 23:07:03 +0200
Subject: [PATCH 03/04] ARM: shmobile: Add EMEV2 and KZM9D to
 ARCH_SHMOBILE_MULTI
In-Reply-To: <CANqRtoTcqYxCTWRok4cuzRWbCBULxwGYhgPyiVH_FgxBLtx7SQ@mail.gmail.com>
References: <20130709054331.14007.66068.sendpatchset@w520>
 <201307090937.29805.arnd@arndb.de>
 <CANqRtoTcqYxCTWRok4cuzRWbCBULxwGYhgPyiVH_FgxBLtx7SQ@mail.gmail.com>
Message-ID: <201307092307.03502.arnd@arndb.de>

On Tuesday 09 July 2013, Magnus Damm wrote:
> Sure, good idea. I plan on using the following if you don't mind:
> 
>          if (!IS_ENABLED(CONFIG_COMMON_CLK)
>                  emev2_clock_init()
> 

Yes, looks good.

	Arnd


From arnd at arndb.de  Tue Jul  9 17:16:20 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Jul 2013 23:16:20 +0200
Subject: [PATCH V3 2/3] clocksource: mmp: support CLOCKSOURCE OF DECLARE
In-Reply-To: <20130709181434.76f6216d@skate>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-3-git-send-email-zhangwm@marvell.com>
 <20130709181434.76f6216d@skate>
Message-ID: <201307092316.20905.arnd@arndb.de>

On Tuesday 09 July 2013, Thomas Petazzoni wrote:
> Dear Neil Zhang,
> 
> On Tue, 9 Jul 2013 14:42:45 +0800, Neil Zhang wrote:
> > support CLOCKSOURCE OF DECLARE for mmp timer.
> > 
> > Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> > ---
> >  arch/arm/mach-mmp/mmp-dt.c  |    5 ++---
> >  arch/arm/mach-mmp/mmp2-dt.c |    3 +--
> >  arch/arm/mach-mmp/time.c    |   15 ++-------------
> >  3 files changed, 5 insertions(+), 18 deletions(-)
> 
> Maybe it would be good to take this opportunity to move
> arch/arm/mach-mmp/time.c into drivers/clocksource/.

+1

Or we might want to have a more coordinated move of all clocksource
drivers in arch/arm to drivers/clocksource now, as we have done for some
other subsystems.

	Arnd


From arnd at arndb.de  Tue Jul  9 17:15:05 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 9 Jul 2013 23:15:05 +0200
Subject: [PATCH v1 0/4] ARM: STi fixes and ethernet support
In-Reply-To: <51DBE718.2080007@st.com>
References: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
 <201307090956.03191.arnd@arndb.de> <51DBE718.2080007@st.com>
Message-ID: <201307092315.06131.arnd@arndb.de>

On Tuesday 09 July 2013, Srinivas KANDAGATLA wrote:
> On 09/07/13 08:56, Arnd Bergmann wrote:
> > No, you should be using generic interfaces to do the things you need.
> > 
> > I believe what you are missing is an ethernet phy driver that is specific
> > to your SoC.
> It looks interesting way to solve the issue.
> 
> Did you mean "Ethernet PHY"?
> 
> Ethernet PHY is not integrated in the STiH41x SoC, We use an external
> ICPLUS phy ( drivers/net/phy/icplus.c) for both B2000 and B2020 boards.
> As we can't have  two Ethernet phy drivers at the same time, I think the
> suggestion might not work in this case.
> 
> The callbacks in the mach level are setting up two SOC specific System
> Configuration registers which configures the MAC (like PHY interface
> selection, which is sampled during MAC reset assertion).

Ah, right.

> MAC used in STiH41x supports multiple PHY interfaces, so the PHY
> interface selection is driven by external signals wired up to System
> Configuration registers. The MAC driver is not aware of these System
> Configuration registers. So for non-DT case, stmmac driver provided
> callbacks to do things like this.
> 
> For DT case, At the moment I think callbacks at MACH level is one
> possible solution. But am open for any discussions.

Ok, so a PHY driver might not be the best place to put this, but it's
one option, since the PHY driver already has to know about the
interface speed you are setting.

Having a global "*_setup_ethernet" callback is definitely not the
right way to go. Please describe what the function actually does
so we can come up with the right subsystem to move that functionality
to. If you are setting clocks, you should use the clock subsystem,
for taking the device out of reset, you should use the reset controller
subsystem and for setting up the phy, you should use the phy subsystem,
etc.

	Arnd


From arnd at arndb.de  Tue Jul  9 18:05:21 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Jul 2013 00:05:21 +0200
Subject: [PATCH V3 3/3] ARM: mmp: bring up pxa988 with device tree support
In-Reply-To: <1373352166-10064-4-git-send-email-zhangwm@marvell.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-4-git-send-email-zhangwm@marvell.com>
Message-ID: <201307100005.21769.arnd@arndb.de>

On Tuesday 09 July 2013, Neil Zhang wrote:
> +	soc {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		interrupt-parent = <&gic>;
> +		ranges;
> +
> +		gic: interrupt-controller at d1dfe100 {
> +			compatible = "arm,cortex-a9-gic";
> +			#interrupt-cells = <3>;
> +			#address-cells = <1>;
> +			interrupt-controller;
> +			reg = <0xd1dff000 0x1000>,
> +			      <0xd1dfe100 0x0100>;
> +		};
> +
> +		L2: l2-cache-controller at d1dfb000 {
> +			compatible = "arm,pl310-cache";
> +			reg = <0xd1dfb000 0x1000>;
> +			arm,data-latency = <2 1 1>;
> +			arm,tag-latency = <2 1 1>;
> +			arm,pwr-dynamic-clk-gating;
> +			arm,pwr-standby-mode;
> +			cache-unified;
> +			cache-level = <2>;
> +		};
> +
> +		local-timer at d1dfe600 {
> +			compatible = "arm,cortex-a9-twd-timer";
> +			reg = <0xd1dfe600 0x20>;
> +			interrupts = <1 13 0x304>;
> +		};
> +
> +		axi at d4200000 {	/* AXI */
> +			compatible = "simple-bus";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			ranges = <0xd4200000 0xd4200000 0x00200000>;
> +
> +			intc: wakeupgen at d4282000 {
> +				compatible = "marvell,mmp-intc";
> +				reg = <0xd4282000 0x1000>;
> +				marvell,intc-wakeup = <0x114 0x3
> +						    0x144 0x3>;
> +			};
> +		};

I am guessing that the structure does not actually reflect the hardware.

Shouldn't AXI be the top-level bus, with the other stuff under it?

> +
> +
> +			uart1: uart at d4017000 {
> +				compatible = "marvell,mmp-uart";
> +				reg = <0xd4017000 0x1000>;
> +				interrupts = <0 27 0x4>;
> +				status = "disabled";
> +			};

The uart node should be called "serial at d4017000" instead of "uart at d4017000".

> diff --git a/arch/arm/mach-mmp/reset.c b/arch/arm/mach-mmp/reset.c
> new file mode 100644
> index 0000000..b90ec54
> --- /dev/null
> +++ b/arch/arm/mach-mmp/reset.c
> @@ -0,0 +1,66 @@
> +/*
> + * linux/arch/arm/mach-mmp/reset.c

I think this could just be part of the smp.c file.

> + *
> + * Author:	Neil Zhang <zhangwm at marvell.com>
> + * Copyright:	(C) 2012 Marvell International Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/smp.h>
> +
> +#include <asm/io.h>
> +#include <asm/cacheflush.h>
> +#include <asm/mach/map.h>
> +
> +#include <mach/addr-map.h>
> +
> +#include "reset.h"
> +
> +#define PMU_CC2_AP			APMU_REG(0x0100)
> +#define CIU_CA9_WARM_RESET_VECTOR	CIU_REG(0x00d8)

You should not hardcode the addresses here, better find them from the device tree.
> +
> +#define CPU_CORE_RST(n)	(1 << ((n) * 4 + 16))
> +#define CPU_DBG_RST(n)	(1 << ((n) * 4 + 18))
> +#define CPU_WDOG_RST(n)	(1 << ((n) * 4 + 19))

This should probably go into a reset controller driver, in drivers/reset/

	Arnd


From robherring2 at gmail.com  Tue Jul  9 18:52:14 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 09 Jul 2013 17:52:14 -0500
Subject: [PATCHv4 05/11] of: pci: add registry of MSI chips
In-Reply-To: <20130709160132.7f5e7a8e@skate>
References: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1372686136-1370-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAL_Jsq+h=y5SNo4qO5-5u_w8rW++9MKDZK8rASNjhtVcjh-iyQ@mail.gmail.com>
 <20130709160132.7f5e7a8e@skate>
Message-ID: <51DC941E.60007@gmail.com>

On 07/09/2013 09:01 AM, Thomas Petazzoni wrote:
> Rob,
> 
> On Tue, 9 Jul 2013 08:43:36 -0500, Rob Herring wrote:
> 
>>> +int of_msi_chip_add(struct msi_chip *chip)
>>
>> Perhaps of_pci_msi_chip_add instead.
> 
> Sure, makes sense.
> 
>>> +{
>>> +       struct msi_chip *c;
>>> +       list_for_each_entry(c, &msi_chip_list, list) {
>>
>> Need the safe variant here?
> 
> As suggested by Bjorn, I've changed this function to grab the
> msi_chip_mutex while traversing the list.
> 
> Does your e-mail implies that the general approach seems ok? If so,
> I'll resend an updated v5 version taking into account the comments
> that I have received on this v4.

Yes. Since it is only trivial comments, you can add my ack.

Acked-by: Rob Herring <rob.herring at calxeda.com>

Rob

> 
> Thanks!
> 
> Thomas
> 



From heiko at sntech.de  Tue Jul  9 18:57:05 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Wed, 10 Jul 2013 00:57:05 +0200
Subject: [PATCH v2 0/6] Convert S3C2416 ad S3C2443 to common clock framework
Message-ID: <201307100057.06061.heiko@sntech.de>

This series provides a clock driver for s3c2416, s3c2443 and s3c2450, which
share a common clock tree, but differ fundamentally from earlier s3c24xx
SoCs, and converts the mentioned SoCs to use it.

The clock driver itself follows the same scheme established by all other
Samsung clock drivers.

It depends on the pwm cleanup series from Tomasz Figa, which gets rid of the
declarations of the pwm-internal clocks.

Test on both non-dt and dt s3c2416.

Heiko Stuebner (6):
  clk: samsung: move common plls registration into separate function
  clk: samsung: fix error handling in pll register functions
  clk: samsung: add plls used in s3c2416 and s3c2443
  ARM: S3C24XX: enable legacy clock code only when SAMSUNG_CLOCK
    selected
  clk: samsung: add clock-driver for s3c2416, s3c2443 and s3c2450
  ARM: S3C24XX: Convert s3c2416 and s3c2443 to common clock framework

 .../bindings/clock/samsung,s3c2443-clock.txt       |   48 ++
 arch/arm/boot/dts/s3c2416-smdk2416.dts             |    7 +
 arch/arm/boot/dts/s3c2416.dtsi                     |   42 ++
 arch/arm/mach-s3c24xx/Kconfig                      |   14 +-
 arch/arm/mach-s3c24xx/Makefile                     |    5 +-
 arch/arm/mach-s3c24xx/clock-s3c2416.c              |  171 -----
 arch/arm/mach-s3c24xx/clock-s3c2443.c              |  212 ------
 arch/arm/mach-s3c24xx/common-s3c2443.c             |  675 --------------------
 arch/arm/mach-s3c24xx/common.c                     |   20 +-
 arch/arm/mach-s3c24xx/common.h                     |    8 +
 arch/arm/mach-s3c24xx/mach-s3c2416-dt.c            |   45 +-
 arch/arm/mach-s3c24xx/mach-smdk2416.c              |    9 +-
 arch/arm/mach-s3c24xx/mach-smdk2443.c              |    9 +-
 drivers/clk/Kconfig                                |    1 +
 drivers/clk/samsung/Kconfig                        |    2 +
 drivers/clk/samsung/Makefile                       |    1 +
 drivers/clk/samsung/clk-pll.c                      |  374 +++++++++--
 drivers/clk/samsung/clk-pll.h                      |    8 +
 drivers/clk/samsung/clk-s3c2443.c                  |  422 ++++++++++++
 include/dt-bindings/clock/samsung,s3c2443-clock.h  |   96 +++
 20 files changed, 998 insertions(+), 1171 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt
 delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2416.c
 delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2443.c
 delete mode 100644 arch/arm/mach-s3c24xx/common-s3c2443.c
 create mode 100644 drivers/clk/samsung/Kconfig
 create mode 100644 drivers/clk/samsung/clk-s3c2443.c
 create mode 100644 include/dt-bindings/clock/samsung,s3c2443-clock.h

-- 
1.7.10.4



From heiko at sntech.de  Tue Jul  9 18:57:47 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Wed, 10 Jul 2013 00:57:47 +0200
Subject: [PATCH v2 1/6] clk: samsung: move common plls registration into
 separate function
In-Reply-To: <201307100057.06061.heiko@sntech.de>
References: <201307100057.06061.heiko@sntech.de>
Message-ID: <201307100057.48265.heiko@sntech.de>

All Samsung PLLs use similar code to register the clocks and clkdev lookups.
Therefore move these into a separate function to reduce code duplication.

Suggested-by: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 drivers/clk/samsung/clk-pll.c |   68 +++++++++++++++++------------------------
 1 file changed, 28 insertions(+), 40 deletions(-)

diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 362f12d..9153e46 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -13,6 +13,24 @@
 #include "clk.h"
 #include "clk-pll.h"
 
+static inline struct clk *samsung_register_pll(struct clk_hw *hw)
+{
+	struct clk *clk;
+	const char *name = hw->init->name;
+
+	clk = clk_register(NULL, hw);
+	if (IS_ERR(clk)) {
+		pr_err("%s: failed to register pll clock %s\n", __func__,
+				name);
+		return clk;
+	}
+
+	if (clk_register_clkdev(clk, name, NULL))
+		pr_err("%s: failed to register lookup for %s", __func__, name);
+
+	return clk;
+}
+
 /*
  * PLL35xx Clock Type
  */
@@ -75,15 +93,9 @@ struct clk * __init samsung_clk_register_pll35xx(const char *name,
 	pll->hw.init = &init;
 	pll->con_reg = con_reg;
 
-	clk = clk_register(NULL, &pll->hw);
-	if (IS_ERR(clk)) {
-		pr_err("%s: failed to register pll clock %s\n", __func__,
-				name);
+	clk = samsung_register_pll(&pll->hw);
+	if (IS_ERR(clk))
 		kfree(pll);
-	}
-
-	if (clk_register_clkdev(clk, name, NULL))
-		pr_err("%s: failed to register lookup for %s", __func__, name);
 
 	return clk;
 }
@@ -155,15 +167,9 @@ struct clk * __init samsung_clk_register_pll36xx(const char *name,
 	pll->hw.init = &init;
 	pll->con_reg = con_reg;
 
-	clk = clk_register(NULL, &pll->hw);
-	if (IS_ERR(clk)) {
-		pr_err("%s: failed to register pll clock %s\n", __func__,
-				name);
+	clk = samsung_register_pll(&pll->hw);
+	if (IS_ERR(clk))
 		kfree(pll);
-	}
-
-	if (clk_register_clkdev(clk, name, NULL))
-		pr_err("%s: failed to register lookup for %s", __func__, name);
 
 	return clk;
 }
@@ -236,15 +242,9 @@ struct clk * __init samsung_clk_register_pll45xx(const char *name,
 	pll->con_reg = con_reg;
 	pll->type = type;
 
-	clk = clk_register(NULL, &pll->hw);
-	if (IS_ERR(clk)) {
-		pr_err("%s: failed to register pll clock %s\n", __func__,
-				name);
+	clk = samsung_register_pll(&pll->hw);
+	if (IS_ERR(clk))
 		kfree(pll);
-	}
-
-	if (clk_register_clkdev(clk, name, NULL))
-		pr_err("%s: failed to register lookup for %s", __func__, name);
 
 	return clk;
 }
@@ -323,15 +323,9 @@ struct clk * __init samsung_clk_register_pll46xx(const char *name,
 	pll->con_reg = con_reg;
 	pll->type = type;
 
-	clk = clk_register(NULL, &pll->hw);
-	if (IS_ERR(clk)) {
-		pr_err("%s: failed to register pll clock %s\n", __func__,
-				name);
+	clk = samsung_register_pll(&pll->hw);
+	if (IS_ERR(clk))
 		kfree(pll);
-	}
-
-	if (clk_register_clkdev(clk, name, NULL))
-		pr_err("%s: failed to register lookup for %s", __func__, name);
 
 	return clk;
 }
@@ -406,15 +400,9 @@ struct clk * __init samsung_clk_register_pll2550x(const char *name,
 	pll->reg_base = reg_base;
 	pll->offset = offset;
 
-	clk = clk_register(NULL, &pll->hw);
-	if (IS_ERR(clk)) {
-		pr_err("%s: failed to register pll clock %s\n", __func__,
-				name);
+	clk = samsung_register_pll(&pll->hw);
+	if (IS_ERR(clk))
 		kfree(pll);
-	}
-
-	if (clk_register_clkdev(clk, name, NULL))
-		pr_err("%s: failed to register lookup for %s", __func__, name);
 
 	return clk;
 }
-- 
1.7.10.4



From heiko at sntech.de  Tue Jul  9 18:58:13 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Wed, 10 Jul 2013 00:58:13 +0200
Subject: [PATCH v2 2/6] clk: samsung: fix error handling in pll register
 functions
In-Reply-To: <201307100057.06061.heiko@sntech.de>
References: <201307100057.06061.heiko@sntech.de>
Message-ID: <201307100058.13941.heiko@sntech.de>

kmalloc has its own error reporting when the allocation fails and
the register functions also should return the correct ERR_PTR(-ENOMEM)
when it happens.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 drivers/clk/samsung/clk-pll.c |   30 ++++++++++--------------------
 1 file changed, 10 insertions(+), 20 deletions(-)

diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 9153e46..0afaec6 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -79,10 +79,8 @@ struct clk * __init samsung_clk_register_pll35xx(const char *name,
 	struct clk_init_data init;
 
 	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
-	if (!pll) {
-		pr_err("%s: could not allocate pll clk %s\n", __func__, name);
-		return NULL;
-	}
+	if (!pll)
+		return ERR_PTR(-ENOMEM);
 
 	init.name = name;
 	init.ops = &samsung_pll35xx_clk_ops;
@@ -153,10 +151,8 @@ struct clk * __init samsung_clk_register_pll36xx(const char *name,
 	struct clk_init_data init;
 
 	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
-	if (!pll) {
-		pr_err("%s: could not allocate pll clk %s\n", __func__, name);
-		return NULL;
-	}
+	if (!pll)
+		return ERR_PTR(-ENOMEM);
 
 	init.name = name;
 	init.ops = &samsung_pll36xx_clk_ops;
@@ -227,10 +223,8 @@ struct clk * __init samsung_clk_register_pll45xx(const char *name,
 	struct clk_init_data init;
 
 	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
-	if (!pll) {
-		pr_err("%s: could not allocate pll clk %s\n", __func__, name);
-		return NULL;
-	}
+	if (!pll)
+		return ERR_PTR(-ENOMEM);
 
 	init.name = name;
 	init.ops = &samsung_pll45xx_clk_ops;
@@ -308,10 +302,8 @@ struct clk * __init samsung_clk_register_pll46xx(const char *name,
 	struct clk_init_data init;
 
 	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
-	if (!pll) {
-		pr_err("%s: could not allocate pll clk %s\n", __func__, name);
-		return NULL;
-	}
+	if (!pll)
+		return ERR_PTR(-ENOMEM);
 
 	init.name = name;
 	init.ops = &samsung_pll46xx_clk_ops;
@@ -385,10 +377,8 @@ struct clk * __init samsung_clk_register_pll2550x(const char *name,
 	struct clk_init_data init;
 
 	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
-	if (!pll) {
-		pr_err("%s: could not allocate pll clk %s\n", __func__, name);
-		return NULL;
-	}
+	if (!pll)
+		return ERR_PTR(-ENOMEM);
 
 	init.name = name;
 	init.ops = &samsung_pll2550x_clk_ops;
-- 
1.7.10.4



From heiko at sntech.de  Tue Jul  9 18:59:08 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Wed, 10 Jul 2013 00:59:08 +0200
Subject: [PATCH v2 3/6] clk: samsung: add plls used in s3c2416 and s3c2443
In-Reply-To: <201307100057.06061.heiko@sntech.de>
References: <201307100057.06061.heiko@sntech.de>
Message-ID: <201307100059.08621.heiko@sntech.de>

This adds support for pll2126x, pll3000x, pll6552x and pll6553x.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 drivers/clk/samsung/clk-pll.c |  280 +++++++++++++++++++++++++++++++++++++++++
 drivers/clk/samsung/clk-pll.h |    8 ++
 2 files changed, 288 insertions(+)

diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 0afaec6..35c15a1 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -323,6 +323,73 @@ struct clk * __init samsung_clk_register_pll46xx(const char *name,
 }
 
 /*
+ * PLL2126x Clock Type
+ */
+
+#define PLL2126X_MDIV_MASK	(0xFF)
+#define PLL2126X_PDIV_MASK	(0x3)
+#define PLL2126X_SDIV_MASK	(0x3)
+#define PLL2126X_MDIV_SHIFT	(16)
+#define PLL2126X_PDIV_SHIFT	(8)
+#define PLL2126X_SDIV_SHIFT	(0)
+
+struct samsung_clk_pll2126x {
+	struct clk_hw		hw;
+	const void __iomem	*con_reg;
+};
+
+#define to_clk_pll2126x(_hw) container_of(_hw, struct samsung_clk_pll2126x, hw)
+
+static unsigned long samsung_pll2126x_recalc_rate(struct clk_hw *hw,
+				unsigned long parent_rate)
+{
+	struct samsung_clk_pll2126x *pll = to_clk_pll2126x(hw);
+	u32 pll_con, mdiv, pdiv, sdiv;
+	u64 fvco = parent_rate;
+
+	pll_con = __raw_readl(pll->con_reg);
+	mdiv = (pll_con >> PLL2126X_MDIV_SHIFT) & PLL2126X_MDIV_MASK;
+	pdiv = (pll_con >> PLL2126X_PDIV_SHIFT) & PLL2126X_PDIV_MASK;
+	sdiv = (pll_con >> PLL2126X_SDIV_SHIFT) & PLL2126X_SDIV_MASK;
+
+	fvco *= (mdiv + 8);
+	do_div(fvco, (pdiv + 2) << sdiv);
+
+	return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll2126x_clk_ops = {
+	.recalc_rate = samsung_pll2126x_recalc_rate,
+};
+
+struct clk * __init samsung_clk_register_pll2126x(const char *name,
+			const char *pname, const void __iomem *con_reg)
+{
+	struct samsung_clk_pll2126x *pll;
+	struct clk *clk;
+	struct clk_init_data init;
+
+	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+	if (!pll)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &samsung_pll2126x_clk_ops;
+	init.flags = CLK_GET_RATE_NOCACHE;
+	init.parent_names = &pname;
+	init.num_parents = 1;
+
+	pll->hw.init = &init;
+	pll->con_reg = con_reg;
+
+	clk = samsung_register_pll(&pll->hw);
+	if (IS_ERR(clk))
+		kfree(pll);
+
+	return clk;
+}
+
+/*
  * PLL2550x Clock Type
  */
 
@@ -396,3 +463,216 @@ struct clk * __init samsung_clk_register_pll2550x(const char *name,
 
 	return clk;
 }
+
+/*
+ * PLL3000x Clock Type
+ */
+
+#define PLL3000X_MDIV_MASK	(0xFF)
+#define PLL3000X_PDIV_MASK	(0x3)
+#define PLL3000X_SDIV_MASK	(0x3)
+#define PLL3000X_MDIV_SHIFT	(16)
+#define PLL3000X_PDIV_SHIFT	(8)
+#define PLL3000X_SDIV_SHIFT	(0)
+
+struct samsung_clk_pll3000x {
+	struct clk_hw		hw;
+	const void __iomem	*con_reg;
+};
+
+#define to_clk_pll3000x(_hw) container_of(_hw, struct samsung_clk_pll3000x, hw)
+
+static unsigned long samsung_pll3000x_recalc_rate(struct clk_hw *hw,
+				unsigned long parent_rate)
+{
+	struct samsung_clk_pll3000x *pll = to_clk_pll3000x(hw);
+	u32 pll_con, mdiv, pdiv, sdiv;
+	u64 fvco = parent_rate;
+
+	pll_con = __raw_readl(pll->con_reg);
+	mdiv = (pll_con >> PLL3000X_MDIV_SHIFT) & PLL3000X_MDIV_MASK;
+	pdiv = (pll_con >> PLL3000X_PDIV_SHIFT) & PLL3000X_PDIV_MASK;
+	sdiv = (pll_con >> PLL3000X_SDIV_SHIFT) & PLL3000X_SDIV_MASK;
+
+	fvco *= (2 * (mdiv + 8));
+	do_div(fvco, pdiv << sdiv);
+
+	return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll3000x_clk_ops = {
+	.recalc_rate = samsung_pll3000x_recalc_rate,
+};
+
+struct clk * __init samsung_clk_register_pll3000x(const char *name,
+			const char *pname, const void __iomem *con_reg)
+{
+	struct samsung_clk_pll3000x *pll;
+	struct clk *clk;
+	struct clk_init_data init;
+
+	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+	if (!pll)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &samsung_pll3000x_clk_ops;
+	init.flags = CLK_GET_RATE_NOCACHE;
+	init.parent_names = &pname;
+	init.num_parents = 1;
+
+	pll->hw.init = &init;
+	pll->con_reg = con_reg;
+
+	clk = samsung_register_pll(&pll->hw);
+	if (IS_ERR(clk))
+		kfree(pll);
+
+	return clk;
+}
+
+/*
+ * PLL6552x Clock Type
+ */
+
+#define PLL6552X_MDIV_MASK	(0x3FF)
+#define PLL6552X_PDIV_MASK	(0x3F)
+#define PLL6552X_SDIV_MASK	(0x7)
+#define PLL6552X_MDIV_SHIFT	(14)
+#define PLL6552X_PDIV_SHIFT	(5)
+#define PLL6552X_SDIV_SHIFT	(0)
+
+struct samsung_clk_pll6552x {
+	struct clk_hw		hw;
+	const void __iomem	*con_reg;
+};
+
+#define to_clk_pll6552x(_hw) container_of(_hw, struct samsung_clk_pll6552x, hw)
+
+static unsigned long samsung_pll6552x_recalc_rate(struct clk_hw *hw,
+				unsigned long parent_rate)
+{
+	struct samsung_clk_pll6552x *pll = to_clk_pll6552x(hw);
+	u32 pll_con, mdiv, pdiv, sdiv;
+	u64 fvco = parent_rate;
+
+	pll_con = __raw_readl(pll->con_reg);
+	mdiv = (pll_con >> PLL6552X_MDIV_SHIFT) & PLL6552X_MDIV_MASK;
+	pdiv = (pll_con >> PLL6552X_PDIV_SHIFT) & PLL6552X_PDIV_MASK;
+	sdiv = (pll_con >> PLL6552X_SDIV_SHIFT) & PLL6552X_SDIV_MASK;
+
+	fvco *= mdiv;
+	do_div(fvco, (pdiv << sdiv));
+
+	return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6552x_clk_ops = {
+	.recalc_rate = samsung_pll6552x_recalc_rate,
+};
+
+struct clk * __init samsung_clk_register_pll6552x(const char *name,
+			const char *pname, const void __iomem *con_reg)
+{
+	struct samsung_clk_pll6552x *pll;
+	struct clk *clk;
+	struct clk_init_data init;
+
+	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+	if (!pll)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &samsung_pll6552x_clk_ops;
+	init.flags = CLK_GET_RATE_NOCACHE;
+	init.parent_names = &pname;
+	init.num_parents = 1;
+
+	pll->hw.init = &init;
+	pll->con_reg = con_reg;
+
+	clk = samsung_register_pll(&pll->hw);
+	if (IS_ERR(clk))
+		kfree(pll);
+
+	return clk;
+}
+
+/*
+ * PLL6553x Clock Type
+ */
+
+#define PLL6553X_MDIV_MASK	(0x7F)
+#define PLL6553X_PDIV_MASK	(0x1F)
+#define PLL6553X_SDIV_MASK	(0x3)
+#define PLL6553X_KDIV_MASK	(0xFFFF)
+#define PLL6553X_MDIV_SHIFT	(16)
+#define PLL6553X_PDIV_SHIFT	(8)
+#define PLL6553X_SDIV_SHIFT	(0)
+
+struct samsung_clk_pll6553x {
+	struct clk_hw		hw;
+	const void __iomem	*con_reg;
+};
+
+#define to_clk_pll6553x(_hw) container_of(_hw, struct samsung_clk_pll6553x, hw)
+
+static unsigned long samsung_pll6553x_recalc_rate(struct clk_hw *hw,
+				unsigned long parent_rate)
+{
+	struct samsung_clk_pll6553x *pll = to_clk_pll6553x(hw);
+	u32 pll_con0, pll_con1, mdiv, pdiv, sdiv, kdiv;
+	u64 fvco = parent_rate;
+
+	pll_con0 = __raw_readl(pll->con_reg);
+	pll_con1 = __raw_readl(pll->con_reg + 4);
+	mdiv = (pll_con0 >> PLL6553X_MDIV_SHIFT) & PLL6553X_MDIV_MASK;
+	pdiv = (pll_con0 >> PLL6553X_PDIV_SHIFT) & PLL6553X_PDIV_MASK;
+	sdiv = (pll_con0 >> PLL6553X_SDIV_SHIFT) & PLL6553X_SDIV_MASK;
+	kdiv = pll_con1 & PLL6553X_KDIV_MASK;
+
+	/*
+	 * We need to multiple parent_rate by mdiv (the integer part) and kdiv
+	 * which is in 2^16ths, so shift mdiv up (does not overflow) and
+	 * add kdiv before multiplying. The use of tmp is to avoid any
+	 * overflows before shifting bac down into result when multipling
+	 * by the mdiv and kdiv pair.
+	 */
+
+	fvco *= (mdiv << 16) + kdiv;
+	do_div(fvco, (pdiv << sdiv));
+	fvco >>= 16;
+
+	return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6553x_clk_ops = {
+	.recalc_rate = samsung_pll6553x_recalc_rate,
+};
+
+struct clk * __init samsung_clk_register_pll6553x(const char *name,
+			const char *pname, const void __iomem *con_reg)
+{
+	struct samsung_clk_pll6553x *pll;
+	struct clk *clk;
+	struct clk_init_data init;
+
+	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+	if (!pll)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &samsung_pll6553x_clk_ops;
+	init.flags = CLK_GET_RATE_NOCACHE;
+	init.parent_names = &pname;
+	init.num_parents = 1;
+
+	pll->hw.init = &init;
+	pll->con_reg = con_reg;
+
+	clk = samsung_register_pll(&pll->hw);
+	if (IS_ERR(clk))
+		kfree(pll);
+
+	return clk;
+}
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
index f33786e..465ee6f 100644
--- a/drivers/clk/samsung/clk-pll.h
+++ b/drivers/clk/samsung/clk-pll.h
@@ -34,8 +34,16 @@ extern struct clk * __init samsung_clk_register_pll45xx(const char *name,
 extern struct clk * __init samsung_clk_register_pll46xx(const char *name,
 			const char *pname, const void __iomem *con_reg,
 			enum pll46xx_type type);
+extern struct clk * __init samsung_clk_register_pll2126x(const char *name,
+			const char *pname, const void __iomem *con_reg);
 extern struct clk * __init samsung_clk_register_pll2550x(const char *name,
 			const char *pname, const void __iomem *reg_base,
 			const unsigned long offset);
+extern struct clk * __init samsung_clk_register_pll3000x(const char *name,
+			const char *pname, const void __iomem *con_reg);
+extern struct clk * __init samsung_clk_register_pll6552x(const char *name,
+			const char *pname, const void __iomem *con_reg);
+extern struct clk * __init samsung_clk_register_pll6553x(const char *name,
+			const char *pname, const void __iomem *con_reg);
 
 #endif /* __SAMSUNG_CLK_PLL_H */
-- 
1.7.10.4



From heiko at sntech.de  Tue Jul  9 18:59:32 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Wed, 10 Jul 2013 00:59:32 +0200
Subject: [PATCH v2 4/6] ARM: S3C24XX: enable legacy clock code only when
 SAMSUNG_CLOCK selected
In-Reply-To: <201307100057.06061.heiko@sntech.de>
References: <201307100057.06061.heiko@sntech.de>
Message-ID: <201307100059.32401.heiko@sntech.de>

This enables a smooth transition, as not all S3C24XX SoCs need to be
converted at the same time and can instead simply exchange their
select SAMSUNG_CLOCK with a select COMMON_CLK after the conversion.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 arch/arm/mach-s3c24xx/common-s3c2443.c |    2 ++
 arch/arm/mach-s3c24xx/common.c         |    2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/arm/mach-s3c24xx/common-s3c2443.c b/arch/arm/mach-s3c24xx/common-s3c2443.c
index f6b9f2e..b5bbeb7 100644
--- a/arch/arm/mach-s3c24xx/common-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/common-s3c2443.c
@@ -28,6 +28,7 @@
 #include <plat/cpu-freq.h>
 
 
+#ifdef CONFIG_SAMSUNG_CLOCK
 static int s3c2443_gate(void __iomem *reg, struct clk *clk, int enable)
 {
 	u32 ctrlbit = clk->ctrlbit;
@@ -673,3 +674,4 @@ void __init s3c2443_common_init_clocks(int xtal, pll_fn get_mpll,
 
 	s3c2443_common_setup_clocks(get_mpll);
 }
+#endif
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 457261c..0fe0254 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -317,6 +317,7 @@ struct s3c24xx_uart_resources s3c2410_uart_resources[] __initdata = {
 
 /* initialise all the clocks */
 
+#ifdef CONFIG_SAMSUNG_CLOCK
 void __init_or_cpufreq s3c24xx_setup_clocks(unsigned long fclk,
 					   unsigned long hclk,
 					   unsigned long pclk)
@@ -329,3 +330,4 @@ void __init_or_cpufreq s3c24xx_setup_clocks(unsigned long fclk,
 	clk_p.rate = pclk;
 	clk_f.rate = fclk;
 }
+#endif
-- 
1.7.10.4



From heiko at sntech.de  Tue Jul  9 19:00:00 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Wed, 10 Jul 2013 01:00:00 +0200
Subject: [PATCH v2 5/6] clk: samsung: add clock-driver for s3c2416,
 s3c2443 and s3c2450
In-Reply-To: <201307100057.06061.heiko@sntech.de>
References: <201307100057.06061.heiko@sntech.de>
Message-ID: <201307100100.00872.heiko@sntech.de>

The three SoCs share a common clock tree which only differs in the
existence of some special clocks.

As with all parts common to these three SoCs the driver is named
after the s3c2443, as it was the first SoC introducing this structure
and there exists no other label to describe this s3c24xx epoch.

The clock structure is built according to the manuals of the included
SoCs and might include changes in comparison to the previous clock
structure. As an example the sclk_uart gate was never handled previously
and the div_uart was made to be the clock used by the serial driver.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 .../bindings/clock/samsung,s3c2443-clock.txt       |   48 +++
 drivers/clk/Kconfig                                |    1 +
 drivers/clk/samsung/Kconfig                        |    2 +
 drivers/clk/samsung/Makefile                       |    1 +
 drivers/clk/samsung/clk-s3c2443.c                  |  422 ++++++++++++++++++++
 include/dt-bindings/clock/samsung,s3c2443-clock.h  |   96 +++++
 6 files changed, 570 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt
 create mode 100644 drivers/clk/samsung/Kconfig
 create mode 100644 drivers/clk/samsung/clk-s3c2443.c
 create mode 100644 include/dt-bindings/clock/samsung,s3c2443-clock.h

diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt
new file mode 100644
index 0000000..a61d8d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt
@@ -0,0 +1,48 @@
+* Samsung S3C2443 Clock Controller
+
+The S3C2443 clock controller generates and supplies clock to various controllers
+within the SoC. The clock binding described here is applicable to all SoCs in
+the s3c24x family starting with the s3c2443.
+
+Required Properties:
+
+- comptible: should be one of the following.
+  - "samsung,s3c2416-clock" - controller compatible with S3C2416 SoC.
+  - "samsung,s3c2443-clock" - controller compatible with S3C2443 SoC.
+  - "samsung,s3c2450-clock" - controller compatible with S3C2450 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Some of the clocks are available only
+on a particular SoC.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/samsung,s3c2443-clock.h header and can be used in device
+tree sources.
+
+Example: Clock controller node:
+
+	clocks: clock-controller at 4c000000 {
+		compatible = "samsung,s3c2416-clock";
+		reg = <0x4c000000 0x40>;
+		#clock-cells = <1>;
+	};
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller (refer to the standard clock bindings for information about
+  "clocks" and "clock-names" properties):
+
+	serial at 50004000 {
+		compatible = "samsung,s3c2440-uart";
+		reg = <0x50004000 0x4000>;
+		interrupts = <1 23 3 4>, <1 23 4 4>;
+		clock-names = "uart", "clk_uart_baud2",
+				"clk_uart_baud3";
+		clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>,
+				<&clocks SCLK_UART>;
+		status = "disabled";
+	};
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 0357ac4..b2fdd68 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -84,3 +84,4 @@ config COMMON_CLK_AXI_CLKGEN
 endmenu
 
 source "drivers/clk/mvebu/Kconfig"
+source "drivers/clk/samsung/Kconfig"
diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
new file mode 100644
index 0000000..0cfbb29
--- /dev/null
+++ b/drivers/clk/samsung/Kconfig
@@ -0,0 +1,2 @@
+config COMMON_CLK_S3C2443
+       bool
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 5d4d432..1c7932c 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_SOC_EXYNOS5250)	+= clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5420)	+= clk-exynos5420.o
 obj-$(CONFIG_SOC_EXYNOS5440)	+= clk-exynos5440.o
 obj-$(CONFIG_ARCH_EXYNOS)	+= clk-exynos-audss.o
+obj-$(CONFIG_COMMON_CLK_S3C2443)+= clk-s3c2443.o
diff --git a/drivers/clk/samsung/clk-s3c2443.c b/drivers/clk/samsung/clk-s3c2443.c
new file mode 100644
index 0000000..7d57b08
--- /dev/null
+++ b/drivers/clk/samsung/clk-s3c2443.c
@@ -0,0 +1,422 @@
+/*
+ * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Common Clock Framework support for S3C2443 and following SoCs.
+ */
+
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+#include <dt-bindings/clock/samsung,s3c2443-clock.h>
+
+#include "clk.h"
+#include "clk-pll.h"
+
+/* S3C2416 clock controller register offsets */
+#define MPLLCON		0x10
+#define EPLLCON		0x18
+#define EPLLCON_K	0x1C
+#define CLKSRC		0x20
+#define CLKDIV0		0x24
+#define CLKDIV1		0x28
+#define CLKDIV2		0x2C
+#define HCLKCON		0x30
+#define PCLKCON		0x34
+#define SCLKCON		0x38
+
+/* the soc types */
+enum supported_socs {
+	S3C2416,
+	S3C2443,
+	S3C2450,
+};
+
+/*
+ * list of controller registers to be saved and restored during a
+ * suspend/resume cycle.
+ */
+static __initdata unsigned long s3c2443_clk_regs[] = {
+	MPLLCON,
+	EPLLCON,
+	EPLLCON_K,
+	CLKSRC,
+	CLKDIV0,
+	CLKDIV1,
+	CLKDIV2,
+	PCLKCON,
+	HCLKCON,
+	SCLKCON,
+};
+
+PNAME(epllref_p) = { "mpllref", "mpllref", "xti", "ext" };
+PNAME(esysclk_p) = { "epllref", "epll" };
+PNAME(msysclk_p) = { "mpllref, mdivclk", "mpll", "mpll" };
+PNAME(armclk_p) = { "armdiv" , "hclk" };
+PNAME(i2s0_p) = { "div_i2s0", "ext_i2s", "epllref", "epllref" };
+
+/* fixed rate clocks generated outside the soc */
+struct samsung_fixed_rate_clock s3c2443_common_frate_clks[] __initdata = {
+	FRATE(XTI, "xti", NULL, CLK_IS_ROOT, 0),
+	FRATE(EXT, "ext", NULL, CLK_IS_ROOT, 0),
+	FRATE(EXT_I2S, "ext_i2s", NULL, CLK_IS_ROOT, 0),
+	FRATE(EXT_UART, "ext_uart", NULL, CLK_IS_ROOT, 0),
+};
+
+/* mpllref is a direct descendant of clk_xtal by default, but it is not
+ * elided as the EPLL can be either sourced by the XTAL or EXTCLK and as
+ * such directly equating the two source clocks is impossible.
+ */
+struct samsung_fixed_factor_clock s3c2443_common_ffactor[] __initdata = {
+	FFACTOR(0, "mpllref", "xti", 1, 1, 0),
+};
+
+struct samsung_mux_clock s3c2443_common_muxes[] __initdata = {
+	MUX(0, "epllref", epllref_p, CLKSRC, 7, 2),
+	MUX(ESYSCLK, "esysclk", esysclk_p, CLKSRC, 6, 1),
+	MUX_A(MSYSCLK, "msysclk", msysclk_p, CLKSRC, 3, 2, "msysclk"),
+	MUX_A(ARMCLK, "armclk", armclk_p, CLKDIV0, 13, 1, "armclk"),
+	MUX(0, "mux_i2s0", i2s0_p, CLKSRC, 14, 2),
+};
+
+static struct clk_div_table hclk_d[] = {
+	{ .val = 0, .div = 1 },
+	{ .val = 1, .div = 2 },
+	{ .val = 3, .div = 4 },
+	{ .div = 0 },
+};
+
+static struct clk_div_table mdivclk_d[] = {
+	{ .val = 0, .div = 1 },
+	{ .val = 1, .div = 3 },
+	{ .val = 2, .div = 5 },
+	{ .val = 3, .div = 7 },
+	{ .val = 4, .div = 9 },
+	{ .val = 5, .div = 11 },
+	{ .val = 6, .div = 13 },
+	{ .val = 7, .div = 15 },
+	{ .div = 0 },
+};
+
+struct samsung_div_clock s3c2443_common_dividers[] __initdata = {
+	DIV_T(0, "mdivclk", "mpllref", CLKDIV0, 6, 3, mdivclk_d),
+	DIV(0, "prediv", "msysclk", CLKDIV0, 4, 2),
+	DIV_T(HCLK, "hclk", "prediv", CLKDIV0, 0, 2, hclk_d),
+	DIV(PCLK, "pclk", "hclk", CLKDIV0, 2, 1),
+	DIV(0, "div_hsspi0_epll", "esysclk", CLKDIV1, 24, 2),
+	DIV(0, "div_fimd", "esysclk", CLKDIV1, 16, 8),
+	DIV(0, "div_i2s0", "esysclk", CLKDIV1, 12, 4),
+	DIV(0, "div_uart", "esysclk", CLKDIV1, 8, 4),
+	DIV(0, "div_hsmmc1", "esysclk", CLKDIV1, 6, 2),
+	DIV(0, "div_usbhost", "esysclk", CLKDIV1, 4, 2),
+};
+
+struct samsung_gate_clock s3c2443_common_gates[] __initdata = {
+	GATE(SCLK_HSMMC_EXT, "sclk_hsmmcext", "ext", SCLKCON, 13, 0, 0),
+	GATE(SCLK_HSMMC1, "sclk_hsmmc1", "div_hsmmc1", SCLKCON, 12, 0, 0),
+	GATE(SCLK_FIMD, "sclk_fimd", "div_fimd", SCLKCON, 10, 0, 0),
+	GATE(SCLK_I2S0, "sclk_i2s0", "mux_i2s0", SCLKCON, 9, 0, 0),
+	GATE(SCLK_UART, "sclk_uart", "div_uart", SCLKCON, 8, 0, 0),
+	GATE(SCLK_USBH, "sclk_usbhost", "div_usbhost", SCLKCON, 1, 0, 0),
+	GATE(HCLK_DRAM, "dram", "hclk", HCLKCON, 19, CLK_IGNORE_UNUSED, 0),
+	GATE(HCLK_SSMC, "ssmc", "hclk", HCLKCON, 18, CLK_IGNORE_UNUSED, 0),
+	GATE(HCLK_HSMMC1, "hsmmc1", "hclk", HCLKCON, 16, 0, 0),
+	GATE(HCLK_USBD, "usb-device", "hclk", HCLKCON, 12, 0, 0),
+	GATE(HCLK_USBH, "usb-host", "hclk", HCLKCON, 11, 0, 0),
+	GATE(HCLK_LCD, "lcd", "hclk", HCLKCON, 9, 0, 0),
+	GATE(HCLK_DMA5, "dma5", "hclk", HCLKCON, 5, CLK_IGNORE_UNUSED, 0),
+	GATE(HCLK_DMA4, "dma4", "hclk", HCLKCON, 4, CLK_IGNORE_UNUSED, 0),
+	GATE(HCLK_DMA3, "dma3", "hclk", HCLKCON, 3, CLK_IGNORE_UNUSED, 0),
+	GATE(HCLK_DMA2, "dma2", "hclk", HCLKCON, 2, CLK_IGNORE_UNUSED, 0),
+	GATE(HCLK_DMA1, "dma1", "hclk", HCLKCON, 1, CLK_IGNORE_UNUSED, 0),
+	GATE(HCLK_DMA0, "dma0", "hclk", HCLKCON, 0, CLK_IGNORE_UNUSED, 0),
+	GATE(PCLK_GPIO, "gpio", "pclk", PCLKCON, 13, CLK_IGNORE_UNUSED, 0),
+	GATE(PCLK_RTC, "rtc", "pclk", PCLKCON, 12, 0, 0),
+	GATE(PCLK_WDT, "wdt", "pclk", PCLKCON, 11, 0, 0),
+	GATE(PCLK_PWM, "pwm", "pclk", PCLKCON, 10, 0, 0),
+	GATE(PCLK_I2S0, "i2s0", "pclk", PCLKCON, 9, 0, 0),
+	GATE(PCLK_AC97, "ac97", "pclk", PCLKCON, 8, 0, 0),
+	GATE(PCLK_ADC, "adc", "pclk", PCLKCON, 7, 0, 0),
+	GATE(PCLK_SPI0, "spi0", "pclk", PCLKCON, 6, 0, 0),
+	GATE(PCLK_I2C0, "i2c0", "pclk", PCLKCON, 4, 0, 0),
+	GATE(PCLK_UART3, "uart3", "pclk", PCLKCON, 3, 0, 0),
+	GATE(PCLK_UART2, "uart2", "pclk", PCLKCON, 2, 0, 0),
+	GATE(PCLK_UART1, "uart1", "pclk", PCLKCON, 1, 0, 0),
+	GATE(PCLK_UART0, "uart0", "pclk", PCLKCON, 0, 0, 0),
+};
+
+struct samsung_clock_alias s3c2443_common_aliases[] __initdata = {
+	ALIAS(HCLK, NULL, "hclk"),
+	ALIAS(HCLK_SSMC, NULL, "nand"),
+	ALIAS(PCLK_UART0, "s3c2440-uart.0", "uart"),
+	ALIAS(PCLK_UART1, "s3c2440-uart.1", "uart"),
+	ALIAS(PCLK_UART2, "s3c2440-uart.2", "uart"),
+	ALIAS(PCLK_UART3, "s3c2440-uart.3", "uart"),
+	ALIAS(EXT_UART, NULL, "clk_uart_baud1"),
+	ALIAS(PCLK_UART0, "s3c2440-uart.0", "clk_uart_baud2"),
+	ALIAS(PCLK_UART1, "s3c2440-uart.1", "clk_uart_baud2"),
+	ALIAS(PCLK_UART2, "s3c2440-uart.2", "clk_uart_baud2"),
+	ALIAS(PCLK_UART3, "s3c2440-uart.3", "clk_uart_baud2"),
+	ALIAS(SCLK_UART, NULL, "clk_uart_baud3"),
+	ALIAS(PCLK_PWM, NULL, "timers"),
+	ALIAS(PCLK_RTC, NULL, "rtc"),
+	ALIAS(PCLK_WDT, NULL, "watchdog"),
+	ALIAS(PCLK_ADC, NULL, "adc"),
+	ALIAS(PCLK_I2C0, "s3c2410-i2c.0", "i2c"),
+	ALIAS(HCLK_USBD, NULL, "usb-device"),
+	ALIAS(HCLK_USBH, NULL, "usb-host"),
+	ALIAS(SCLK_USBH, NULL, "usb-bus-host"),
+	ALIAS(PCLK_SPI0, "s3c2443-spi.0", "spi"),
+	ALIAS(PCLK_SPI0, "s3c2443-spi.0", "spi_busclk0"),
+	ALIAS(HCLK_HSMMC1, "s3c-sdhci.1", "hsmmc"),
+	ALIAS(HCLK_HSMMC1, "s3c-sdhci.1", "mmc_busclk.0"),
+	ALIAS(PCLK_I2S0, "samsung-i2s.0", "iis"),
+	ALIAS(SCLK_I2S0, NULL, "i2s-if"),
+	ALIAS(HCLK_LCD, NULL, "lcd"),
+	ALIAS(SCLK_FIMD, NULL, "sclk_fimd"),
+};
+
+/* S3C2416 specific clocks */
+
+PNAME(s3c2416_hsmmc0_p) = { "sclk_hsmmc0", "sclk_hsmmcext" };
+PNAME(s3c2416_hsmmc1_p) = { "sclk_hsmmc1", "sclk_hsmmcext" };
+PNAME(s3c2416_hsspi0_p) = { "hsspi0_epll", "hsspi0_mpll" };
+
+static struct clk_div_table armdiv_s3c2416_d[] = {
+	{ .val = 0, .div = 1 },
+	{ .val = 1, .div = 2 },
+	{ .val = 2, .div = 3 },
+	{ .val = 3, .div = 4 },
+	{ .val = 5, .div = 6 },
+	{ .val = 7, .div = 8 },
+	{ .div = 0 },
+};
+
+struct samsung_div_clock s3c2416_dividers[] __initdata = {
+	DIV_T(ARMDIV, "armdiv", "msysclk", CLKDIV0, 9, 3, armdiv_s3c2416_d),
+	DIV(0, "div_hsspi0_mpll", "msysclk", CLKDIV2, 0, 4),
+	DIV(0, "div_hsmmc0", "esysclk", CLKDIV2, 6, 2),
+};
+
+struct samsung_mux_clock s3c2416_muxes[] __initdata = {
+	MUX(MUX_HSMMC0, "mux_hsmmc0", s3c2416_hsmmc0_p, CLKSRC, 16, 1),
+	MUX(MUX_HSMMC1, "mux_hsmmc1", s3c2416_hsmmc1_p, CLKSRC, 17, 1),
+	MUX(MUX_HSSPI0, "mux_hsspi0", s3c2416_hsspi0_p, CLKSRC, 18, 1),
+};
+
+struct samsung_gate_clock s3c2416_gates[] __initdata = {
+	GATE(0, "hsspi0_mpll", "div_hsspi0_mpll", SCLKCON, 19, 0, 0),
+	GATE(0, "hsspi0_epll", "div_hsspi0_epll", SCLKCON, 14, 0, 0),
+	GATE(0, "sclk_hsmmc0", "div_hsmmc0", SCLKCON, 6, 0, 0),
+	GATE(HCLK_2D, "2d", "hclk", HCLKCON, 20, 0, 0),
+	GATE(HCLK_HSMMC0, "hsmmc0", "hclk", HCLKCON, 15, 0, 0),
+	GATE(HCLK_IROM, "irom", "hclk", HCLKCON, 13, CLK_IGNORE_UNUSED, 0),
+	GATE(PCLK_PCM, "pcm", "pclk", PCLKCON, 19, 0, 0),
+};
+
+struct samsung_clock_alias s3c2416_aliases[] __initdata = {
+	ALIAS(HCLK_HSMMC0, "s3c-sdhci.0", "hsmmc"),
+	ALIAS(HCLK_HSMMC0, "s3c-sdhci.0", "mmc_busclk.0"),
+	ALIAS(MUX_HSMMC0, "s3c-sdhci.0", "mmc_busclk.2"),
+	ALIAS(MUX_HSMMC1, "s3c-sdhci.1", "mmc_busclk.2"),
+	ALIAS(MUX_HSSPI0, "s3c2443-spi.0", "spi_busclk2"),
+	ALIAS(ARMDIV, NULL, "armdiv"),
+};
+
+/* S3C2443 specific clocks */
+
+static struct clk_div_table armdiv_s3c2443_d[] = {
+	{ .val = 0, .div = 1 },
+	{ .val = 8, .div = 2 },
+	{ .val = 2, .div = 3 },
+	{ .val = 9, .div = 4 },
+	{ .val = 10, .div = 6 },
+	{ .val = 11, .div = 8 },
+	{ .val = 13, .div = 12 },
+	{ .val = 15, .div = 16 },
+	{ .div = 0 },
+};
+
+struct samsung_div_clock s3c2443_dividers[] __initdata = {
+	DIV_T(ARMDIV, "armdiv", "msysclk", CLKDIV0, 9, 4, armdiv_s3c2443_d),
+	DIV(0, "div_cam", "esysclk", CLKDIV1, 26, 4),
+};
+
+struct samsung_gate_clock s3c2443_gates[] __initdata = {
+	GATE(SCLK_HSSPI0, "sclk_hsspi0", "div_hsspi0_epll", SCLKCON, 14, 0, 0),
+	GATE(SCLK_CAM, "sclk_cam", "div_cam", SCLKCON, 11, 0, 0),
+	GATE(HCLK_CFC, "cfc", "hclk", HCLKCON, 17, CLK_IGNORE_UNUSED, 0),
+	GATE(HCLK_CAM, "cam", "hclk", HCLKCON, 8, 0, 0),
+	GATE(PCLK_SPI1, "spi1", "pclk", PCLKCON, 15, 0, 0),
+	GATE(PCLK_SDI, "sdi", "pclk", PCLKCON, 5, 0, 0),
+};
+
+struct samsung_clock_alias s3c2443_aliases[] __initdata = {
+	ALIAS(SCLK_HSSPI0, "s3c2443-spi.0", "spi_busclk2"),
+	ALIAS(SCLK_HSMMC1, "s3c-sdhci.1", "mmc_busclk.2"),
+	ALIAS(SCLK_CAM, NULL, "camif-upll"),
+	ALIAS(PCLK_SPI1, "s3c2410-spi.0", "spi"),
+	ALIAS(PCLK_SDI, NULL, "sdi"),
+	ALIAS(HCLK_CFC, NULL, "cfc"),
+	ALIAS(ARMDIV, NULL, "armdiv"),
+};
+
+/* S3C2450 specific clocks */
+
+PNAME(s3c2450_cam_p) = { "div_cam", "hclk" };
+PNAME(s3c2450_hsspi1_p) = { "hsspi1_epll", "hsspi1_mpll" };
+PNAME(i2s1_p) = { "div_i2s1", "ext_i2s", "epllref", "epllref" };
+
+struct samsung_div_clock s3c2450_dividers[] __initdata = {
+	DIV(0, "div_cam", "esysclk", CLKDIV1, 26, 4),
+	DIV(0, "div_hsspi1_epll", "esysclk", CLKDIV2, 24, 2),
+	DIV(0, "div_hsspi1_mpll", "msysclk", CLKDIV2, 16, 4),
+	DIV(0, "div_i2s1", "esysclk", CLKDIV2, 12, 4),
+};
+
+struct samsung_mux_clock s3c2450_muxes[] __initdata = {
+	MUX(0, "mux_cam", s3c2450_cam_p, CLKSRC, 20, 1),
+	MUX(MUX_HSSPI1, "mux_hsspi1", s3c2450_hsspi1_p, CLKSRC, 19, 1),
+	MUX(0, "mux_i2s1", i2s1_p, CLKSRC, 12, 2),
+};
+
+struct samsung_gate_clock s3c2450_gates[] __initdata = {
+	GATE(SCLK_I2S1, "sclk_i2s1", "div_i2s1", SCLKCON, 5, 0, 0),
+	GATE(HCLK_CFC, "cfc", "hclk", HCLKCON, 17, 0, 0),
+	GATE(HCLK_CAM, "cam", "hclk", HCLKCON, 8, 0, 0),
+	GATE(HCLK_DMA7, "dma7", "hclk", HCLKCON, 7, CLK_IGNORE_UNUSED, 0),
+	GATE(HCLK_DMA6, "dma6", "hclk", HCLKCON, 6, CLK_IGNORE_UNUSED, 0),
+	GATE(PCLK_I2S1, "i2s1", "pclk", PCLKCON, 17, 0, 0),
+	GATE(PCLK_I2C1, "i2c1", "pclk", PCLKCON, 16, 0, 0),
+	GATE(PCLK_SPI1, "spi1", "pclk", PCLKCON, 14, 0, 0),
+};
+
+struct samsung_clock_alias s3c2450_aliases[] __initdata = {
+	ALIAS(PCLK_SPI1, "s3c2443-spi.1", "spi"),
+	ALIAS(PCLK_SPI1, "s3c2443-spi.1", "spi_busclk0"),
+	ALIAS(MUX_HSSPI1, "s3c2443-spi.1", "spi_busclk2"),
+	ALIAS(PCLK_I2C1, "s3c2410-i2c.1", "i2c"),
+};
+
+/*
+ * This function allows non-dt platforms to specify the clock speed of the
+ * xti and ext clocks.
+ */
+void __init s3c2443_clk_register_fixed_ext(unsigned long xti_f,
+				unsigned long ext_f, unsigned long i2s_f,
+				unsigned long uart_f)
+{
+	s3c2443_common_frate_clks[0].fixed_rate = xti_f;
+	s3c2443_common_frate_clks[1].fixed_rate = ext_f;
+	s3c2443_common_frate_clks[2].fixed_rate = i2s_f;
+	s3c2443_common_frate_clks[3].fixed_rate = uart_f;
+
+	samsung_clk_register_fixed_rate(s3c2443_common_frate_clks,
+			ARRAY_SIZE(s3c2443_common_frate_clks));
+}
+
+static __initdata struct of_device_id ext_clk_match[] = {
+	{ .compatible = "samsung,clock-xti", .data = (void *)0, },
+	{ .compatible = "samsung,clock-ext", .data = (void *)1, },
+	{ .compatible = "samsung,clock-ext-i2s", .data = (void *)2, },
+	{ .compatible = "samsung,clock-ext-uart", .data = (void *)3, },
+	{},
+};
+
+void __init s3c2443_common_clk_init(struct device_node *np, int current_soc,
+			     void __iomem *reg_base)
+{
+	struct clk *mpll, *epll;
+
+	if (np) {
+		reg_base = of_iomap(np, 0);
+		if (!reg_base)
+			panic("%s: failed to map registers\n", __func__);
+	}
+
+	samsung_clk_init(np, reg_base, NR_CLKS,
+		s3c2443_clk_regs, ARRAY_SIZE(s3c2443_clk_regs), NULL, 0);
+
+	if (np)
+		samsung_clk_of_register_fixed_ext(s3c2443_common_frate_clks,
+			ARRAY_SIZE(s3c2443_common_frate_clks),
+			ext_clk_match);
+
+	samsung_clk_register_fixed_factor(s3c2443_common_ffactor,
+			ARRAY_SIZE(s3c2443_common_ffactor));
+
+	if (current_soc == S3C2416 || current_soc == S3C2450) {
+		mpll = samsung_clk_register_pll6552x("mpll", "mpllref",
+					reg_base + MPLLCON);
+		epll = samsung_clk_register_pll6553x("epll", "epllref",
+					reg_base + EPLLCON);
+	} else {
+		mpll = samsung_clk_register_pll3000x("mpll", "mpllref",
+					reg_base + MPLLCON);
+		epll = samsung_clk_register_pll2126x("epll", "epllref",
+					reg_base + EPLLCON);
+	}
+
+	samsung_clk_register_mux(s3c2443_common_muxes,
+			ARRAY_SIZE(s3c2443_common_muxes));
+	samsung_clk_register_div(s3c2443_common_dividers,
+			ARRAY_SIZE(s3c2443_common_dividers));
+	samsung_clk_register_gate(s3c2443_common_gates,
+		ARRAY_SIZE(s3c2443_common_gates));
+	samsung_clk_register_alias(s3c2443_common_aliases,
+		ARRAY_SIZE(s3c2443_common_aliases));
+
+	if (current_soc == S3C2416 || current_soc == S3C2450) {
+		samsung_clk_register_div(s3c2416_dividers,
+				ARRAY_SIZE(s3c2416_dividers));
+		samsung_clk_register_mux(s3c2416_muxes,
+				ARRAY_SIZE(s3c2416_muxes));
+		samsung_clk_register_gate(s3c2416_gates,
+				ARRAY_SIZE(s3c2416_gates));
+		samsung_clk_register_alias(s3c2416_aliases,
+				ARRAY_SIZE(s3c2416_aliases));
+	} else {
+		samsung_clk_register_div(s3c2443_dividers,
+				ARRAY_SIZE(s3c2443_dividers));
+		samsung_clk_register_gate(s3c2443_gates,
+				ARRAY_SIZE(s3c2443_gates));
+		samsung_clk_register_alias(s3c2443_aliases,
+				ARRAY_SIZE(s3c2443_aliases));
+	}
+
+	/* s3c2450 extends the s3c2416 clocks */
+	if (current_soc == S3C2450) {
+		samsung_clk_register_div(s3c2450_dividers,
+				ARRAY_SIZE(s3c2450_dividers));
+		samsung_clk_register_mux(s3c2450_muxes,
+				ARRAY_SIZE(s3c2450_muxes));
+		samsung_clk_register_gate(s3c2450_gates,
+				ARRAY_SIZE(s3c2450_gates));
+		samsung_clk_register_alias(s3c2450_aliases,
+				ARRAY_SIZE(s3c2450_aliases));
+	}
+}
+
+static void __init s3c2416_clk_init(struct device_node *np)
+{
+	s3c2443_common_clk_init(np, S3C2416, 0);
+}
+CLK_OF_DECLARE(s3c2416_clk, "samsung,s3c2416-clock", s3c2416_clk_init);
+
+static void __init s3c2443_clk_init(struct device_node *np)
+{
+	s3c2443_common_clk_init(np, S3C2443, 0);
+}
+CLK_OF_DECLARE(s3c2443_clk, "samsung,s3c2416-clock", s3c2443_clk_init);
+
+static void __init s3c2450_clk_init(struct device_node *np)
+{
+	s3c2443_common_clk_init(np, S3C2450, 0);
+}
+CLK_OF_DECLARE(s3c2450_clk, "samsung,s3c2416-clock", s3c2450_clk_init);
diff --git a/include/dt-bindings/clock/samsung,s3c2443-clock.h b/include/dt-bindings/clock/samsung,s3c2443-clock.h
new file mode 100644
index 0000000..bc2fa79
--- /dev/null
+++ b/include/dt-bindings/clock/samsung,s3c2443-clock.h
@@ -0,0 +1,96 @@
+/*
+ * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Device Tree binding constants clock controllers of Samsung S3C2443 and later.
+ */
+
+#ifndef _DT_BINDINGS_CLOCK_SAMSUNG_S3C2443_CLOCK_H
+#define _DT_BINDINGS_CLOCK_SAMSUNG_S3C2443_CLOCK_H
+
+/*
+ * Let each exported clock get a unique index, which is used on DT-enabled
+ * platforms to lookup the clock from a clock specifier. These indices are
+ * therefore considered an ABI and so must not be changed. This implies
+ * that new clocks should be added either in free spaces between clock groups
+ * or at the end.
+ */
+
+/* Core clocks. */
+#define XTI			1
+#define EXT			2
+#define EXT_I2S			3
+#define EXT_UART		4
+#define MSYSCLK			5
+#define ESYSCLK			6
+#define ARMDIV			7
+#define ARMCLK			8
+#define HCLK			9
+#define PCLK			10
+
+/* Special clocks */
+#define SCLK_HSSPI0		32
+#define SCLK_FIMD		33
+#define SCLK_I2S0		34
+#define SCLK_I2S1		35
+#define SCLK_HSMMC1		36
+#define SCLK_HSMMC_EXT		37
+#define SCLK_CAM		38
+#define SCLK_UART		39
+#define SCLK_USBH		40
+
+/* Muxes */
+#define MUX_HSSPI0		64
+#define MUX_HSSPI1		65
+#define MUX_HSMMC0		66
+#define MUX_HSMMC1		67
+
+/* hclk-gates */
+#define HCLK_DMA0		96
+#define HCLK_DMA1		97
+#define HCLK_DMA2		98
+#define HCLK_DMA3		99
+#define HCLK_DMA4		100
+#define HCLK_DMA5		101
+#define HCLK_DMA6		102
+#define HCLK_DMA7		103
+#define HCLK_CAM		104
+#define HCLK_LCD		105
+#define HCLK_USBH		106
+#define HCLK_USBD		107
+#define HCLK_IROM		108
+#define HCLK_HSMMC0		109
+#define HCLK_HSMMC1		110
+#define HCLK_CFC		111
+#define HCLK_SSMC		112
+#define HCLK_DRAM		113
+#define HCLK_2D			114
+
+/* pclk-gates */
+#define PCLK_UART0		128
+#define PCLK_UART1		129
+#define PCLK_UART2		130
+#define PCLK_UART3		131
+#define PCLK_I2C0		132
+#define PCLK_SDI		133
+#define PCLK_SPI0		134
+#define PCLK_ADC		135
+#define PCLK_AC97		136
+#define PCLK_I2S0		137
+#define PCLK_PWM		138
+#define PCLK_WDT		139
+#define PCLK_RTC		140
+#define PCLK_GPIO		141
+#define PCLK_SPI1		142
+#define PCLK_CHIPID		143
+#define PCLK_I2C1		144
+#define PCLK_I2S1		145
+#define PCLK_PCM		146
+
+/* Total number of clocks. */
+#define NR_CLKS			(PCLK_PCM + 1)
+
+#endif /* _DT_BINDINGS_CLOCK_SAMSUNG_S3C2443_CLOCK_H */
-- 
1.7.10.4



From heiko at sntech.de  Tue Jul  9 19:00:28 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Wed, 10 Jul 2013 01:00:28 +0200
Subject: [PATCH v2 6/6] ARM: S3C24XX: Convert s3c2416 and s3c2443 to common
 clock framework
In-Reply-To: <201307100057.06061.heiko@sntech.de>
References: <201307100057.06061.heiko@sntech.de>
Message-ID: <201307100100.28992.heiko@sntech.de>

This converts the mentioned platforms to use the newly introduced driver
for the common clock framework for them.

With this the whole legacy clock structure can go away too.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 arch/arm/boot/dts/s3c2416-smdk2416.dts  |    7 +
 arch/arm/boot/dts/s3c2416.dtsi          |   42 ++
 arch/arm/mach-s3c24xx/Kconfig           |   14 +-
 arch/arm/mach-s3c24xx/Makefile          |    5 +-
 arch/arm/mach-s3c24xx/clock-s3c2416.c   |  171 --------
 arch/arm/mach-s3c24xx/clock-s3c2443.c   |  212 ----------
 arch/arm/mach-s3c24xx/common-s3c2443.c  |  677 -------------------------------
 arch/arm/mach-s3c24xx/common.c          |   18 +-
 arch/arm/mach-s3c24xx/common.h          |    8 +
 arch/arm/mach-s3c24xx/mach-s3c2416-dt.c |   45 +-
 arch/arm/mach-s3c24xx/mach-smdk2416.c   |    9 +-
 arch/arm/mach-s3c24xx/mach-smdk2443.c   |    9 +-
 12 files changed, 102 insertions(+), 1115 deletions(-)
 delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2416.c
 delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2443.c
 delete mode 100644 arch/arm/mach-s3c24xx/common-s3c2443.c

diff --git a/arch/arm/boot/dts/s3c2416-smdk2416.dts b/arch/arm/boot/dts/s3c2416-smdk2416.dts
index 59594cf..9caeb89 100644
--- a/arch/arm/boot/dts/s3c2416-smdk2416.dts
+++ b/arch/arm/boot/dts/s3c2416-smdk2416.dts
@@ -19,6 +19,13 @@
 		reg =  <0x30000000 0x4000000>;
 	};
 
+	fixed-rate-clocks {
+		xti {
+			compatible = "samsung,clock-xti";
+			clock-frequency = <12000000>;
+		};
+	};
+
 	serial at 50000000 {
 		status = "okay";
 		pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/s3c2416.dtsi b/arch/arm/boot/dts/s3c2416.dtsi
index e6555bd..c19d99c 100644
--- a/arch/arm/boot/dts/s3c2416.dtsi
+++ b/arch/arm/boot/dts/s3c2416.dtsi
@@ -8,6 +8,7 @@
  * published by the Free Software Foundation.
  */
 
+#include <dt-bindings/clock/samsung,s3c2443-clock.h>
 #include "s3c24xx.dtsi"
 #include "s3c2416-pinctrl.dtsi"
 
@@ -28,26 +29,53 @@
 		compatible = "samsung,s3c2416-irq";
 	};
 
+	clocks: clock-controller at 0x4c000000 {
+		compatible = "samsung,s3c2416-clock";
+		reg = <0x4c000000 0x40>;
+		#clock-cells = <1>;
+	};
+
 	pinctrl at 56000000 {
 		compatible = "samsung,s3c2416-pinctrl";
 	};
 
+	timer at 51000000 {
+		clocks = <&clocks PCLK_PWM>;
+		clock-names = "timers";
+	};
+
 	serial at 50000000 {
 		compatible = "samsung,s3c2440-uart";
+		clock-names = "uart", "clk_uart_baud2",
+				"clk_uart_baud3";
+		clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>,
+				<&clocks SCLK_UART>;
 	};
 
 	serial at 50004000 {
 		compatible = "samsung,s3c2440-uart";
+		clock-names = "uart", "clk_uart_baud2",
+				"clk_uart_baud3";
+		clocks = <&clocks PCLK_UART1>, <&clocks PCLK_UART1>,
+				<&clocks SCLK_UART>;
 	};
 
 	serial at 50008000 {
 		compatible = "samsung,s3c2440-uart";
+		clock-names = "uart", "clk_uart_baud2",
+				"clk_uart_baud3";
+		clocks = <&clocks PCLK_UART2>, <&clocks PCLK_UART2>,
+				<&clocks SCLK_UART>;
 	};
 
 	serial at 5000C000 {
 		compatible = "samsung,s3c2440-uart";
 		reg = <0x5000C000 0x4000>;
 		interrupts = <1 18 24 4>, <1 18 25 4>;
+		clock-names = "uart", "clk_uart_baud2",
+				"clk_uart_baud3";
+		clocks = <&clocks PCLK_UART3>, <&clocks PCLK_UART3>,
+				<&clocks SCLK_UART>;
 		status = "disabled";
 	};
 
@@ -55,6 +83,10 @@
 		compatible = "samsung,s3c6410-sdhci";
 		reg = <0x4AC00000 0x100>;
 		interrupts = <0 0 21 3>;
+		clock-names = "hsmmc", "mmc_busclk.0",
+				"mmc_busclk.2";
+		clocks = <&clocks HCLK_HSMMC0>, <&clocks HCLK_HSMMC0>,
+				<&clocks MUX_HSMMC0>;
 		status = "disabled";
 	};
 
@@ -62,18 +94,28 @@
 		compatible = "samsung,s3c6410-sdhci";
 		reg = <0x4A800000 0x100>;
 		interrupts = <0 0 20 3>;
+		clock-names = "hsmmc", "mmc_busclk.0",
+				"mmc_busclk.2";
+		clocks = <&clocks HCLK_HSMMC1>, <&clocks HCLK_HSMMC1>,
+				<&clocks MUX_HSMMC1>;
 		status = "disabled";
 	};
 
 	watchdog at 53000000 {
 		interrupts = <1 9 27 3>;
+		clocks = <&clocks PCLK_WDT>;
+		clock-names = "watchdog";
 	};
 
 	rtc at 57000000 {
 		compatible = "samsung,s3c2416-rtc";
+		clocks = <&clocks PCLK_RTC>;
+		clock-names = "rtc";
 	};
 
 	i2c at 54000000 {
 		compatible = "samsung,s3c2440-i2c";
+		clocks = <&clocks PCLK_I2C0>;
+		clock-names = "i2c";
 	};
 };
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index b8ec0ec..37cbe5f 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -49,9 +49,9 @@ config CPU_S3C2416
 	select CPU_ARM926T
 	select CPU_LLSERIAL_S3C2440
 	select S3C2416_PM if PM
-	select S3C2443_COMMON
 	select S3C2443_DMA if S3C24XX_DMA
-	select SAMSUNG_CLKSRC
+	select COMMON_CLK
+	select COMMON_CLK_S3C2443
 	help
 	  Support for the S3C2416 SoC from the S3C24XX line
 
@@ -83,9 +83,9 @@ config CPU_S3C2443
 	bool "SAMSUNG S3C2443"
 	select CPU_ARM920T
 	select CPU_LLSERIAL_S3C2440
-	select S3C2443_COMMON
 	select S3C2443_DMA if S3C24XX_DMA
-	select SAMSUNG_CLKSRC
+	select COMMON_CLK
+	select COMMON_CLK_S3C2443
 	help
 	  Support for the S3C2443 SoC from the S3C24XX line
 
@@ -663,12 +663,6 @@ endif	# CPU_S3C2442
 
 if CPU_S3C2443 || CPU_S3C2416
 
-config S3C2443_COMMON
-	bool
-	help
-	  Common code for the S3C2443 and similar processors, which includes
-	  the S3C2416 and S3C2450.
-
 config S3C2443_DMA
 	bool
 	help
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 7f54e5b..ba0e547 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -26,7 +26,7 @@ obj-$(CONFIG_S3C2412_DMA)	+= dma-s3c2412.o
 obj-$(CONFIG_S3C2412_PM)	+= pm-s3c2412.o
 obj-$(CONFIG_S3C2412_PM_SLEEP)	+= sleep-s3c2412.o
 
-obj-$(CONFIG_CPU_S3C2416)	+= s3c2416.o clock-s3c2416.o
+obj-$(CONFIG_CPU_S3C2416)	+= s3c2416.o
 obj-$(CONFIG_S3C2416_PM)	+= pm-s3c2416.o
 
 obj-$(CONFIG_CPU_S3C2440)	+= s3c2440.o clock-s3c2440.o
@@ -36,7 +36,7 @@ obj-$(CONFIG_S3C2440_DMA)	+= dma-s3c2440.o
 obj-$(CONFIG_S3C2440_PLL_12000000) += pll-s3c2440-12000000.o
 obj-$(CONFIG_S3C2440_PLL_16934400) += pll-s3c2440-16934400.o
 
-obj-$(CONFIG_CPU_S3C2443)	+= s3c2443.o clock-s3c2443.o
+obj-$(CONFIG_CPU_S3C2443)	+= s3c2443.o
 
 # PM
 
@@ -53,7 +53,6 @@ obj-$(CONFIG_S3C2410_CPUFREQ_UTILS) += cpufreq-utils.o
 obj-$(CONFIG_S3C2410_IOTIMING)	+= iotiming-s3c2410.o
 obj-$(CONFIG_S3C2412_IOTIMING)	+= iotiming-s3c2412.o
 
-obj-$(CONFIG_S3C2443_COMMON)	+= common-s3c2443.o
 obj-$(CONFIG_S3C2443_DMA)	+= dma-s3c2443.o
 
 #
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2416.c b/arch/arm/mach-s3c24xx/clock-s3c2416.c
deleted file mode 100644
index d421a72..0000000
--- a/arch/arm/mach-s3c24xx/clock-s3c2416.c
+++ /dev/null
@@ -1,171 +0,0 @@
-/* linux/arch/arm/mach-s3c2416/clock.c
- *
- * Copyright (c) 2010 Simtec Electronics
- * Copyright (c) 2010 Ben Dooks <ben-linux at fluff.org>
- *
- * S3C2416 Clock control support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include <linux/init.h>
-#include <linux/clk.h>
-
-#include <plat/clock.h>
-#include <plat/clock-clksrc.h>
-#include <plat/cpu.h>
-
-#include <plat/cpu-freq.h>
-#include <plat/pll.h>
-
-#include <asm/mach/map.h>
-
-#include <mach/regs-clock.h>
-#include <mach/regs-s3c2443-clock.h>
-
-/* armdiv
- *
- * this clock is sourced from msysclk and can have a number of
- * divider values applied to it to then be fed into armclk.
- * The real clock definition is done in s3c2443-clock.c,
- * only the armdiv divisor table must be defined here.
-*/
-
-static unsigned int armdiv[8] = {
-	[0] = 1,
-	[1] = 2,
-	[2] = 3,
-	[3] = 4,
-	[5] = 6,
-	[7] = 8,
-};
-
-static struct clksrc_clk hsspi_eplldiv = {
-	.clk = {
-		.name	= "hsspi-eplldiv",
-		.parent	= &clk_esysclk.clk,
-		.ctrlbit = (1 << 14),
-		.enable = s3c2443_clkcon_enable_s,
-	},
-	.reg_div = { .reg = S3C2443_CLKDIV1, .size = 2, .shift = 24 },
-};
-
-static struct clk *hsspi_sources[] = {
-	[0] = &hsspi_eplldiv.clk,
-	[1] = NULL, /* to fix */
-};
-
-static struct clksrc_clk hsspi_mux = {
-	.clk	= {
-		.name	= "hsspi-if",
-	},
-	.sources = &(struct clksrc_sources) {
-		.sources = hsspi_sources,
-		.nr_sources = ARRAY_SIZE(hsspi_sources),
-	},
-	.reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 18 },
-};
-
-static struct clksrc_clk hsmmc_div[] = {
-	[0] = {
-		.clk = {
-			.name	= "hsmmc-div",
-			.devname	= "s3c-sdhci.0",
-			.parent	= &clk_esysclk.clk,
-		},
-		.reg_div = { .reg = S3C2416_CLKDIV2, .size = 2, .shift = 6 },
-	},
-	[1] = {
-		.clk = {
-			.name	= "hsmmc-div",
-			.devname	= "s3c-sdhci.1",
-			.parent	= &clk_esysclk.clk,
-		},
-		.reg_div = { .reg = S3C2443_CLKDIV1, .size = 2, .shift = 6 },
-	},
-};
-
-static struct clksrc_clk hsmmc_mux0 = {
-	.clk	= {
-		.name		= "hsmmc-if",
-		.devname	= "s3c-sdhci.0",
-		.ctrlbit	= (1 << 6),
-		.enable		= s3c2443_clkcon_enable_s,
-	},
-	.sources	= &(struct clksrc_sources) {
-		.nr_sources	= 2,
-		.sources	= (struct clk * []) {
-			[0]	= &hsmmc_div[0].clk,
-			[1]	= NULL, /* to fix */
-		},
-	},
-	.reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 16 },
-};
-
-static struct clksrc_clk hsmmc_mux1 = {
-	.clk	= {
-		.name		= "hsmmc-if",
-		.devname	= "s3c-sdhci.1",
-		.ctrlbit	= (1 << 12),
-		.enable		= s3c2443_clkcon_enable_s,
-	},
-	.sources	= &(struct clksrc_sources) {
-		.nr_sources	= 2,
-		.sources	= (struct clk * []) {
-			[0]	= &hsmmc_div[1].clk,
-			[1]	= NULL, /* to fix */
-		},
-	},
-	.reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 17 },
-};
-
-static struct clk hsmmc0_clk = {
-	.name		= "hsmmc",
-	.devname	= "s3c-sdhci.0",
-	.parent		= &clk_h,
-	.enable		= s3c2443_clkcon_enable_h,
-	.ctrlbit	= S3C2416_HCLKCON_HSMMC0,
-};
-
-static struct clksrc_clk *clksrcs[] __initdata = {
-	&hsspi_eplldiv,
-	&hsspi_mux,
-	&hsmmc_div[0],
-	&hsmmc_div[1],
-	&hsmmc_mux0,
-	&hsmmc_mux1,
-};
-
-static struct clk_lookup s3c2416_clk_lookup[] = {
-	CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.0", &hsmmc0_clk),
-	CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.2", &hsmmc_mux0.clk),
-	CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2", &hsmmc_mux1.clk),
-	/* s3c2443-spi.0 is used on s3c2416 and s3c2450 as well */
-	CLKDEV_INIT("s3c2443-spi.0", "spi_busclk2", &hsspi_mux.clk),
-};
-
-void __init s3c2416_init_clocks(int xtal)
-{
-	u32 epllcon = __raw_readl(S3C2443_EPLLCON);
-	u32 epllcon1 = __raw_readl(S3C2443_EPLLCON+4);
-	int ptr;
-
-	/* s3c2416 EPLL compatible with s3c64xx */
-	clk_epll.rate = s3c_get_pll6553x(xtal, epllcon, epllcon1);
-
-	clk_epll.parent = &clk_epllref.clk;
-
-	s3c2443_common_init_clocks(xtal, s3c2416_get_pll,
-				   armdiv, ARRAY_SIZE(armdiv),
-				   S3C2416_CLKDIV0_ARMDIV_MASK);
-
-	for (ptr = 0; ptr < ARRAY_SIZE(clksrcs); ptr++)
-		s3c_register_clksrc(clksrcs[ptr], 1);
-
-	s3c24xx_register_clock(&hsmmc0_clk);
-	clkdev_add_table(s3c2416_clk_lookup, ARRAY_SIZE(s3c2416_clk_lookup));
-
-}
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2443.c b/arch/arm/mach-s3c24xx/clock-s3c2443.c
deleted file mode 100644
index 76cd31f..0000000
--- a/arch/arm/mach-s3c24xx/clock-s3c2443.c
+++ /dev/null
@@ -1,212 +0,0 @@
-/* linux/arch/arm/mach-s3c2443/clock.c
- *
- * Copyright (c) 2007, 2010 Simtec Electronics
- *	Ben Dooks <ben at simtec.co.uk>
- *
- * S3C2443 Clock control support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
-*/
-
-#include <linux/init.h>
-
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/list.h>
-#include <linux/errno.h>
-#include <linux/err.h>
-#include <linux/device.h>
-#include <linux/clk.h>
-#include <linux/mutex.h>
-#include <linux/serial_core.h>
-#include <linux/io.h>
-
-#include <asm/mach/map.h>
-
-#include <mach/hardware.h>
-
-#include <mach/regs-s3c2443-clock.h>
-
-#include <plat/cpu-freq.h>
-
-#include <plat/clock.h>
-#include <plat/clock-clksrc.h>
-#include <plat/cpu.h>
-
-/* We currently have to assume that the system is running
- * from the XTPll input, and that all ***REFCLKs are being
- * fed from it, as we cannot read the state of OM[4] from
- * software.
- *
- * It would be possible for each board initialisation to
- * set the correct muxing at initialisation
-*/
-
-/* clock selections */
-
-/* armdiv
- *
- * this clock is sourced from msysclk and can have a number of
- * divider values applied to it to then be fed into armclk.
- * The real clock definition is done in s3c2443-clock.c,
- * only the armdiv divisor table must be defined here.
-*/
-
-static unsigned int armdiv[16] = {
-	[S3C2443_CLKDIV0_ARMDIV_1 >> S3C2443_CLKDIV0_ARMDIV_SHIFT]	= 1,
-	[S3C2443_CLKDIV0_ARMDIV_2 >> S3C2443_CLKDIV0_ARMDIV_SHIFT]	= 2,
-	[S3C2443_CLKDIV0_ARMDIV_3 >> S3C2443_CLKDIV0_ARMDIV_SHIFT]	= 3,
-	[S3C2443_CLKDIV0_ARMDIV_4 >> S3C2443_CLKDIV0_ARMDIV_SHIFT]	= 4,
-	[S3C2443_CLKDIV0_ARMDIV_6 >> S3C2443_CLKDIV0_ARMDIV_SHIFT]	= 6,
-	[S3C2443_CLKDIV0_ARMDIV_8 >> S3C2443_CLKDIV0_ARMDIV_SHIFT]	= 8,
-	[S3C2443_CLKDIV0_ARMDIV_12 >> S3C2443_CLKDIV0_ARMDIV_SHIFT]	= 12,
-	[S3C2443_CLKDIV0_ARMDIV_16 >> S3C2443_CLKDIV0_ARMDIV_SHIFT]	= 16,
-};
-
-/* hsspi
- *
- * high-speed spi clock, sourced from esysclk
-*/
-
-static struct clksrc_clk clk_hsspi = {
-	.clk	= {
-		.name		= "hsspi-if",
-		.parent		= &clk_esysclk.clk,
-		.ctrlbit	= S3C2443_SCLKCON_HSSPICLK,
-		.enable		= s3c2443_clkcon_enable_s,
-	},
-	.reg_div = { .reg = S3C2443_CLKDIV1, .size = 2, .shift = 4 },
-};
-
-
-/* clk_hsmcc_div
- *
- * this clock is sourced from epll, and is fed through a divider,
- * to a mux controlled by sclkcon where either it or a extclk can
- * be fed to the hsmmc block
-*/
-
-static struct clksrc_clk clk_hsmmc_div = {
-	.clk	= {
-		.name		= "hsmmc-div",
-		.devname	= "s3c-sdhci.1",
-		.parent		= &clk_esysclk.clk,
-	},
-	.reg_div = { .reg = S3C2443_CLKDIV1, .size = 2, .shift = 6 },
-};
-
-static int s3c2443_setparent_hsmmc(struct clk *clk, struct clk *parent)
-{
-	unsigned long clksrc = __raw_readl(S3C2443_SCLKCON);
-
-	clksrc &= ~(S3C2443_SCLKCON_HSMMCCLK_EXT |
-		    S3C2443_SCLKCON_HSMMCCLK_EPLL);
-
-	if (parent == &clk_epll)
-		clksrc |= S3C2443_SCLKCON_HSMMCCLK_EPLL;
-	else if (parent == &clk_ext)
-		clksrc |= S3C2443_SCLKCON_HSMMCCLK_EXT;
-	else
-		return -EINVAL;
-
-	if (clk->usage > 0) {
-		__raw_writel(clksrc, S3C2443_SCLKCON);
-	}
-
-	clk->parent = parent;
-	return 0;
-}
-
-static int s3c2443_enable_hsmmc(struct clk *clk, int enable)
-{
-	return s3c2443_setparent_hsmmc(clk, clk->parent);
-}
-
-static struct clk clk_hsmmc = {
-	.name		= "hsmmc-if",
-	.devname	= "s3c-sdhci.1",
-	.parent		= &clk_hsmmc_div.clk,
-	.enable		= s3c2443_enable_hsmmc,
-	.ops		= &(struct clk_ops) {
-		.set_parent	= s3c2443_setparent_hsmmc,
-	},
-};
-
-/* standard clock definitions */
-
-static struct clk init_clocks_off[] = {
-	{
-		.name		= "sdi",
-		.parent		= &clk_p,
-		.enable		= s3c2443_clkcon_enable_p,
-		.ctrlbit	= S3C2443_PCLKCON_SDI,
-	}, {
-		.name		= "spi",
-		.devname	= "s3c2410-spi.0",
-		.parent		= &clk_p,
-		.enable		= s3c2443_clkcon_enable_p,
-		.ctrlbit	= S3C2443_PCLKCON_SPI1,
-	}
-};
-
-/* clocks to add straight away */
-
-static struct clksrc_clk *clksrcs[] __initdata = {
-	&clk_hsspi,
-	&clk_hsmmc_div,
-};
-
-static struct clk *clks[] __initdata = {
-	&clk_hsmmc,
-};
-
-static struct clk_lookup s3c2443_clk_lookup[] = {
-	CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2", &clk_hsmmc),
-	CLKDEV_INIT("s3c2443-spi.0", "spi_busclk2", &clk_hsspi.clk),
-};
-
-void __init s3c2443_init_clocks(int xtal)
-{
-	unsigned long epllcon = __raw_readl(S3C2443_EPLLCON);
-	int ptr;
-
-	clk_epll.rate = s3c2443_get_epll(epllcon, xtal);
-	clk_epll.parent = &clk_epllref.clk;
-
-	s3c2443_common_init_clocks(xtal, s3c2443_get_mpll,
-				   armdiv, ARRAY_SIZE(armdiv),
-				   S3C2443_CLKDIV0_ARMDIV_MASK);
-
-	s3c24xx_register_clocks(clks, ARRAY_SIZE(clks));
-
-	for (ptr = 0; ptr < ARRAY_SIZE(clksrcs); ptr++)
-		s3c_register_clksrc(clksrcs[ptr], 1);
-
-	/* We must be careful disabling the clocks we are not intending to
-	 * be using at boot time, as subsystems such as the LCD which do
-	 * their own DMA requests to the bus can cause the system to lockup
-	 * if they where in the middle of requesting bus access.
-	 *
-	 * Disabling the LCD clock if the LCD is active is very dangerous,
-	 * and therefore the bootloader should be careful to not enable
-	 * the LCD clock if it is not needed.
-	*/
-
-	/* install (and disable) the clocks we do not need immediately */
-
-	s3c_register_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
-	s3c_disable_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
-	clkdev_add_table(s3c2443_clk_lookup, ARRAY_SIZE(s3c2443_clk_lookup));
-}
diff --git a/arch/arm/mach-s3c24xx/common-s3c2443.c b/arch/arm/mach-s3c24xx/common-s3c2443.c
deleted file mode 100644
index b5bbeb7..0000000
--- a/arch/arm/mach-s3c24xx/common-s3c2443.c
+++ /dev/null
@@ -1,677 +0,0 @@
-/*
- * Common code for SoCs starting with the S3C2443
- *
- * Copyright (c) 2007, 2010 Simtec Electronics
- *	Ben Dooks <ben at simtec.co.uk>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This 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.
- */
-
-#include <linux/init.h>
-#include <linux/clk.h>
-#include <linux/io.h>
-
-#include <mach/regs-s3c2443-clock.h>
-
-#include <plat/clock.h>
-#include <plat/clock-clksrc.h>
-#include <plat/cpu.h>
-
-#include <plat/cpu-freq.h>
-
-
-#ifdef CONFIG_SAMSUNG_CLOCK
-static int s3c2443_gate(void __iomem *reg, struct clk *clk, int enable)
-{
-	u32 ctrlbit = clk->ctrlbit;
-	u32 con = __raw_readl(reg);
-
-	if (enable)
-		con |= ctrlbit;
-	else
-		con &= ~ctrlbit;
-
-	__raw_writel(con, reg);
-	return 0;
-}
-
-int s3c2443_clkcon_enable_h(struct clk *clk, int enable)
-{
-	return s3c2443_gate(S3C2443_HCLKCON, clk, enable);
-}
-
-int s3c2443_clkcon_enable_p(struct clk *clk, int enable)
-{
-	return s3c2443_gate(S3C2443_PCLKCON, clk, enable);
-}
-
-int s3c2443_clkcon_enable_s(struct clk *clk, int enable)
-{
-	return s3c2443_gate(S3C2443_SCLKCON, clk, enable);
-}
-
-/* mpllref is a direct descendant of clk_xtal by default, but it is not
- * elided as the EPLL can be either sourced by the XTAL or EXTCLK and as
- * such directly equating the two source clocks is impossible.
- */
-static struct clk clk_mpllref = {
-	.name		= "mpllref",
-	.parent		= &clk_xtal,
-};
-
-static struct clk *clk_epllref_sources[] = {
-	[0] = &clk_mpllref,
-	[1] = &clk_mpllref,
-	[2] = &clk_xtal,
-	[3] = &clk_ext,
-};
-
-struct clksrc_clk clk_epllref = {
-	.clk	= {
-		.name		= "epllref",
-	},
-	.sources = &(struct clksrc_sources) {
-		.sources = clk_epllref_sources,
-		.nr_sources = ARRAY_SIZE(clk_epllref_sources),
-	},
-	.reg_src = { .reg = S3C2443_CLKSRC, .size = 2, .shift = 7 },
-};
-
-/* esysclk
- *
- * this is sourced from either the EPLL or the EPLLref clock
-*/
-
-static struct clk *clk_sysclk_sources[] = {
-	[0] = &clk_epllref.clk,
-	[1] = &clk_epll,
-};
-
-struct clksrc_clk clk_esysclk = {
-	.clk	= {
-		.name		= "esysclk",
-		.parent		= &clk_epll,
-	},
-	.sources = &(struct clksrc_sources) {
-		.sources = clk_sysclk_sources,
-		.nr_sources = ARRAY_SIZE(clk_sysclk_sources),
-	},
-	.reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 6 },
-};
-
-static unsigned long s3c2443_getrate_mdivclk(struct clk *clk)
-{
-	unsigned long parent_rate = clk_get_rate(clk->parent);
-	unsigned long div = __raw_readl(S3C2443_CLKDIV0);
-
-	div  &= S3C2443_CLKDIV0_EXTDIV_MASK;
-	div >>= (S3C2443_CLKDIV0_EXTDIV_SHIFT-1);	/* x2 */
-
-	return parent_rate / (div + 1);
-}
-
-static struct clk clk_mdivclk = {
-	.name		= "mdivclk",
-	.parent		= &clk_mpllref,
-	.ops		= &(struct clk_ops) {
-		.get_rate	= s3c2443_getrate_mdivclk,
-	},
-};
-
-static struct clk *clk_msysclk_sources[] = {
-	[0] = &clk_mpllref,
-	[1] = &clk_mpll,
-	[2] = &clk_mdivclk,
-	[3] = &clk_mpllref,
-};
-
-static struct clksrc_clk clk_msysclk = {
-	.clk	= {
-		.name		= "msysclk",
-		.parent		= &clk_xtal,
-	},
-	.sources = &(struct clksrc_sources) {
-		.sources = clk_msysclk_sources,
-		.nr_sources = ARRAY_SIZE(clk_msysclk_sources),
-	},
-	.reg_src = { .reg = S3C2443_CLKSRC, .size = 2, .shift = 3 },
-};
-
-/* prediv
- *
- * this divides the msysclk down to pass to h/p/etc.
- */
-
-static unsigned long s3c2443_prediv_getrate(struct clk *clk)
-{
-	unsigned long rate = clk_get_rate(clk->parent);
-	unsigned long clkdiv0 = __raw_readl(S3C2443_CLKDIV0);
-
-	clkdiv0 &= S3C2443_CLKDIV0_PREDIV_MASK;
-	clkdiv0 >>= S3C2443_CLKDIV0_PREDIV_SHIFT;
-
-	return rate / (clkdiv0 + 1);
-}
-
-static struct clk clk_prediv = {
-	.name		= "prediv",
-	.parent		= &clk_msysclk.clk,
-	.ops		= &(struct clk_ops) {
-		.get_rate	= s3c2443_prediv_getrate,
-	},
-};
-
-/* hclk divider
- *
- * divides the prediv and provides the hclk.
- */
-
-static unsigned long s3c2443_hclkdiv_getrate(struct clk *clk)
-{
-	unsigned long rate = clk_get_rate(clk->parent);
-	unsigned long clkdiv0 = __raw_readl(S3C2443_CLKDIV0);
-
-	clkdiv0 &= S3C2443_CLKDIV0_HCLKDIV_MASK;
-
-	return rate / (clkdiv0 + 1);
-}
-
-static struct clk_ops clk_h_ops = {
-	.get_rate	= s3c2443_hclkdiv_getrate,
-};
-
-/* pclk divider
- *
- * divides the hclk and provides the pclk.
- */
-
-static unsigned long s3c2443_pclkdiv_getrate(struct clk *clk)
-{
-	unsigned long rate = clk_get_rate(clk->parent);
-	unsigned long clkdiv0 = __raw_readl(S3C2443_CLKDIV0);
-
-	clkdiv0 = ((clkdiv0 & S3C2443_CLKDIV0_HALF_PCLK) ? 1 : 0);
-
-	return rate / (clkdiv0 + 1);
-}
-
-static struct clk_ops clk_p_ops = {
-	.get_rate	= s3c2443_pclkdiv_getrate,
-};
-
-/* armdiv
- *
- * this clock is sourced from msysclk and can have a number of
- * divider values applied to it to then be fed into armclk.
-*/
-
-static unsigned int *armdiv;
-static int nr_armdiv;
-static int armdivmask;
-
-static unsigned long s3c2443_armclk_roundrate(struct clk *clk,
-					      unsigned long rate)
-{
-	unsigned long parent = clk_get_rate(clk->parent);
-	unsigned long calc;
-	unsigned best = 256; /* bigger than any value */
-	unsigned div;
-	int ptr;
-
-	if (!nr_armdiv)
-		return -EINVAL;
-
-	for (ptr = 0; ptr < nr_armdiv; ptr++) {
-		div = armdiv[ptr];
-		if (div) {
-			/* cpufreq provides 266mhz as 266666000 not 266666666 */
-			calc = (parent / div / 1000) * 1000;
-			if (calc <= rate && div < best)
-				best = div;
-		}
-	}
-
-	return parent / best;
-}
-
-static unsigned long s3c2443_armclk_getrate(struct clk *clk)
-{
-	unsigned long rate = clk_get_rate(clk->parent);
-	unsigned long clkcon0;
-	int val;
-
-	if (!nr_armdiv || !armdivmask)
-		return -EINVAL;
-
-	clkcon0 = __raw_readl(S3C2443_CLKDIV0);
-	clkcon0 &= armdivmask;
-	val = clkcon0 >> S3C2443_CLKDIV0_ARMDIV_SHIFT;
-
-	return rate / armdiv[val];
-}
-
-static int s3c2443_armclk_setrate(struct clk *clk, unsigned long rate)
-{
-	unsigned long parent = clk_get_rate(clk->parent);
-	unsigned long calc;
-	unsigned div;
-	unsigned best = 256; /* bigger than any value */
-	int ptr;
-	int val = -1;
-
-	if (!nr_armdiv || !armdivmask)
-		return -EINVAL;
-
-	for (ptr = 0; ptr < nr_armdiv; ptr++) {
-		div = armdiv[ptr];
-		if (div) {
-			/* cpufreq provides 266mhz as 266666000 not 266666666 */
-			calc = (parent / div / 1000) * 1000;
-			if (calc <= rate && div < best) {
-				best = div;
-				val = ptr;
-			}
-		}
-	}
-
-	if (val >= 0) {
-		unsigned long clkcon0;
-
-		clkcon0 = __raw_readl(S3C2443_CLKDIV0);
-		clkcon0 &= ~armdivmask;
-		clkcon0 |= val << S3C2443_CLKDIV0_ARMDIV_SHIFT;
-		__raw_writel(clkcon0, S3C2443_CLKDIV0);
-	}
-
-	return (val == -1) ? -EINVAL : 0;
-}
-
-static struct clk clk_armdiv = {
-	.name		= "armdiv",
-	.parent		= &clk_msysclk.clk,
-	.ops		= &(struct clk_ops) {
-		.round_rate = s3c2443_armclk_roundrate,
-		.get_rate = s3c2443_armclk_getrate,
-		.set_rate = s3c2443_armclk_setrate,
-	},
-};
-
-/* armclk
- *
- * this is the clock fed into the ARM core itself, from armdiv or from hclk.
- */
-
-static struct clk *clk_arm_sources[] = {
-	[0] = &clk_armdiv,
-	[1] = &clk_h,
-};
-
-static struct clksrc_clk clk_arm = {
-	.clk	= {
-		.name		= "armclk",
-	},
-	.sources = &(struct clksrc_sources) {
-		.sources = clk_arm_sources,
-		.nr_sources = ARRAY_SIZE(clk_arm_sources),
-	},
-	.reg_src = { .reg = S3C2443_CLKDIV0, .size = 1, .shift = 13 },
-};
-
-/* usbhost
- *
- * usb host bus-clock, usually 48MHz to provide USB bus clock timing
-*/
-
-static struct clksrc_clk clk_usb_bus_host = {
-	.clk	= {
-		.name		= "usb-bus-host-parent",
-		.parent		= &clk_esysclk.clk,
-		.ctrlbit	= S3C2443_SCLKCON_USBHOST,
-		.enable		= s3c2443_clkcon_enable_s,
-	},
-	.reg_div = { .reg = S3C2443_CLKDIV1, .size = 2, .shift = 4 },
-};
-
-/* common clksrc clocks */
-
-static struct clksrc_clk clksrc_clks[] = {
-	{
-		/* camera interface bus-clock, divided down from esysclk */
-		.clk	= {
-			.name		= "camif-upll",	/* same as 2440 name */
-			.parent		= &clk_esysclk.clk,
-			.ctrlbit	= S3C2443_SCLKCON_CAMCLK,
-			.enable		= s3c2443_clkcon_enable_s,
-		},
-		.reg_div = { .reg = S3C2443_CLKDIV1, .size = 4, .shift = 26 },
-	}, {
-		.clk	= {
-			.name		= "display-if",
-			.parent		= &clk_esysclk.clk,
-			.ctrlbit	= S3C2443_SCLKCON_DISPCLK,
-			.enable		= s3c2443_clkcon_enable_s,
-		},
-		.reg_div = { .reg = S3C2443_CLKDIV1, .size = 8, .shift = 16 },
-	},
-};
-
-static struct clksrc_clk clk_esys_uart = {
-	/* ART baud-rate clock sourced from esysclk via a divisor */
-	.clk	= {
-		.name		= "uartclk",
-		.parent		= &clk_esysclk.clk,
-	},
-	.reg_div = { .reg = S3C2443_CLKDIV1, .size = 4, .shift = 8 },
-};
-
-static struct clk clk_i2s_ext = {
-	.name		= "i2s-ext",
-};
-
-/* i2s_eplldiv
- *
- * This clock is the output from the I2S divisor of ESYSCLK, and is separate
- * from the mux that comes after it (cannot merge into one single clock)
-*/
-
-static struct clksrc_clk clk_i2s_eplldiv = {
-	.clk	= {
-		.name		= "i2s-eplldiv",
-		.parent		= &clk_esysclk.clk,
-	},
-	.reg_div = { .reg = S3C2443_CLKDIV1, .size = 4, .shift = 12, },
-};
-
-/* i2s-ref
- *
- * i2s bus reference clock, selectable from external, esysclk or epllref
- *
- * Note, this used to be two clocks, but was compressed into one.
-*/
-
-static struct clk *clk_i2s_srclist[] = {
-	[0] = &clk_i2s_eplldiv.clk,
-	[1] = &clk_i2s_ext,
-	[2] = &clk_epllref.clk,
-	[3] = &clk_epllref.clk,
-};
-
-static struct clksrc_clk clk_i2s = {
-	.clk	= {
-		.name		= "i2s-if",
-		.ctrlbit	= S3C2443_SCLKCON_I2SCLK,
-		.enable		= s3c2443_clkcon_enable_s,
-
-	},
-	.sources = &(struct clksrc_sources) {
-		.sources = clk_i2s_srclist,
-		.nr_sources = ARRAY_SIZE(clk_i2s_srclist),
-	},
-	.reg_src = { .reg = S3C2443_CLKSRC, .size = 2, .shift = 14 },
-};
-
-static struct clk init_clocks_off[] = {
-	{
-		.name		= "iis",
-		.parent		= &clk_p,
-		.enable		= s3c2443_clkcon_enable_p,
-		.ctrlbit	= S3C2443_PCLKCON_IIS,
-	}, {
-		.name		= "adc",
-		.parent		= &clk_p,
-		.enable		= s3c2443_clkcon_enable_p,
-		.ctrlbit	= S3C2443_PCLKCON_ADC,
-	}, {
-		.name		= "i2c",
-		.parent		= &clk_p,
-		.enable		= s3c2443_clkcon_enable_p,
-		.ctrlbit	= S3C2443_PCLKCON_IIC,
-	}
-};
-
-static struct clk init_clocks[] = {
-	{
-		.name		= "dma",
-		.parent		= &clk_h,
-		.enable		= s3c2443_clkcon_enable_h,
-		.ctrlbit	= S3C2443_HCLKCON_DMA0,
-	}, {
-		.name		= "dma",
-		.parent		= &clk_h,
-		.enable		= s3c2443_clkcon_enable_h,
-		.ctrlbit	= S3C2443_HCLKCON_DMA1,
-	}, {
-		.name		= "dma",
-		.parent		= &clk_h,
-		.enable		= s3c2443_clkcon_enable_h,
-		.ctrlbit	= S3C2443_HCLKCON_DMA2,
-	}, {
-		.name		= "dma",
-		.parent		= &clk_h,
-		.enable		= s3c2443_clkcon_enable_h,
-		.ctrlbit	= S3C2443_HCLKCON_DMA3,
-	}, {
-		.name		= "dma",
-		.parent		= &clk_h,
-		.enable		= s3c2443_clkcon_enable_h,
-		.ctrlbit	= S3C2443_HCLKCON_DMA4,
-	}, {
-		.name		= "dma",
-		.parent		= &clk_h,
-		.enable		= s3c2443_clkcon_enable_h,
-		.ctrlbit	= S3C2443_HCLKCON_DMA5,
-	}, {
-		.name		= "gpio",
-		.parent		= &clk_p,
-		.enable		= s3c2443_clkcon_enable_p,
-		.ctrlbit	= S3C2443_PCLKCON_GPIO,
-	}, {
-		.name		= "usb-host",
-		.parent		= &clk_h,
-		.enable		= s3c2443_clkcon_enable_h,
-		.ctrlbit	= S3C2443_HCLKCON_USBH,
-	}, {
-		.name		= "usb-device",
-		.parent		= &clk_h,
-		.enable		= s3c2443_clkcon_enable_h,
-		.ctrlbit	= S3C2443_HCLKCON_USBD,
-	}, {
-		.name		= "lcd",
-		.parent		= &clk_h,
-		.enable		= s3c2443_clkcon_enable_h,
-		.ctrlbit	= S3C2443_HCLKCON_LCDC,
-
-	}, {
-		.name		= "timers",
-		.parent		= &clk_p,
-		.enable		= s3c2443_clkcon_enable_p,
-		.ctrlbit	= S3C2443_PCLKCON_PWMT,
-	}, {
-		.name		= "cfc",
-		.parent		= &clk_h,
-		.enable		= s3c2443_clkcon_enable_h,
-		.ctrlbit	= S3C2443_HCLKCON_CFC,
-	}, {
-		.name		= "ssmc",
-		.parent		= &clk_h,
-		.enable		= s3c2443_clkcon_enable_h,
-		.ctrlbit	= S3C2443_HCLKCON_SSMC,
-	}, {
-		.name		= "uart",
-		.devname	= "s3c2440-uart.0",
-		.parent		= &clk_p,
-		.enable		= s3c2443_clkcon_enable_p,
-		.ctrlbit	= S3C2443_PCLKCON_UART0,
-	}, {
-		.name		= "uart",
-		.devname	= "s3c2440-uart.1",
-		.parent		= &clk_p,
-		.enable		= s3c2443_clkcon_enable_p,
-		.ctrlbit	= S3C2443_PCLKCON_UART1,
-	}, {
-		.name		= "uart",
-		.devname	= "s3c2440-uart.2",
-		.parent		= &clk_p,
-		.enable		= s3c2443_clkcon_enable_p,
-		.ctrlbit	= S3C2443_PCLKCON_UART2,
-	}, {
-		.name		= "uart",
-		.devname	= "s3c2440-uart.3",
-		.parent		= &clk_p,
-		.enable		= s3c2443_clkcon_enable_p,
-		.ctrlbit	= S3C2443_PCLKCON_UART3,
-	}, {
-		.name		= "rtc",
-		.parent		= &clk_p,
-		.enable		= s3c2443_clkcon_enable_p,
-		.ctrlbit	= S3C2443_PCLKCON_RTC,
-	}, {
-		.name		= "watchdog",
-		.parent		= &clk_p,
-		.ctrlbit	= S3C2443_PCLKCON_WDT,
-	}, {
-		.name		= "ac97",
-		.parent		= &clk_p,
-		.ctrlbit	= S3C2443_PCLKCON_AC97,
-	}, {
-		.name		= "nand",
-		.parent		= &clk_h,
-	}, {
-		.name		= "usb-bus-host",
-		.parent		= &clk_usb_bus_host.clk,
-	}
-};
-
-static struct clk hsmmc1_clk = {
-	.name		= "hsmmc",
-	.devname	= "s3c-sdhci.1",
-	.parent		= &clk_h,
-	.enable		= s3c2443_clkcon_enable_h,
-	.ctrlbit	= S3C2443_HCLKCON_HSMMC,
-};
-
-static struct clk hsspi_clk = {
-	.name		= "spi",
-	.devname	= "s3c2443-spi.0",
-	.parent		= &clk_p,
-	.enable		= s3c2443_clkcon_enable_p,
-	.ctrlbit	= S3C2443_PCLKCON_HSSPI,
-};
-
-/* EPLLCON compatible enough to get on/off information */
-
-void __init_or_cpufreq s3c2443_common_setup_clocks(pll_fn get_mpll)
-{
-	unsigned long epllcon = __raw_readl(S3C2443_EPLLCON);
-	unsigned long mpllcon = __raw_readl(S3C2443_MPLLCON);
-	struct clk *xtal_clk;
-	unsigned long xtal;
-	unsigned long pll;
-	int ptr;
-
-	xtal_clk = clk_get(NULL, "xtal");
-	xtal = clk_get_rate(xtal_clk);
-	clk_put(xtal_clk);
-
-	pll = get_mpll(mpllcon, xtal);
-	clk_msysclk.clk.rate = pll;
-	clk_mpll.rate = pll;
-
-	printk("CPU: MPLL %s %ld.%03ld MHz, cpu %ld.%03ld MHz, mem %ld.%03ld MHz, pclk %ld.%03ld MHz\n",
-	       (mpllcon & S3C2443_PLLCON_OFF) ? "off" : "on",
-	       print_mhz(pll), print_mhz(clk_get_rate(&clk_armdiv)),
-	       print_mhz(clk_get_rate(&clk_h)),
-	       print_mhz(clk_get_rate(&clk_p)));
-
-	for (ptr = 0; ptr < ARRAY_SIZE(clksrc_clks); ptr++)
-		s3c_set_clksrc(&clksrc_clks[ptr], true);
-
-	/* ensure usb bus clock is within correct rate of 48MHz */
-
-	if (clk_get_rate(&clk_usb_bus_host.clk) != (48 * 1000 * 1000)) {
-		printk(KERN_INFO "Warning: USB host bus not at 48MHz\n");
-		clk_set_rate(&clk_usb_bus_host.clk, 48*1000*1000);
-	}
-
-	printk("CPU: EPLL %s %ld.%03ld MHz, usb-bus %ld.%03ld MHz\n",
-	       (epllcon & S3C2443_PLLCON_OFF) ? "off" : "on",
-	       print_mhz(clk_get_rate(&clk_epll)),
-	       print_mhz(clk_get_rate(&clk_usb_bus)));
-}
-
-static struct clk *clks[] __initdata = {
-	&clk_prediv,
-	&clk_mpllref,
-	&clk_mdivclk,
-	&clk_ext,
-	&clk_epll,
-	&clk_usb_bus,
-	&clk_armdiv,
-	&hsmmc1_clk,
-	&hsspi_clk,
-};
-
-static struct clksrc_clk *clksrcs[] __initdata = {
-	&clk_i2s_eplldiv,
-	&clk_i2s,
-	&clk_usb_bus_host,
-	&clk_epllref,
-	&clk_esysclk,
-	&clk_msysclk,
-	&clk_arm,
-};
-
-static struct clk_lookup s3c2443_clk_lookup[] = {
-	CLKDEV_INIT(NULL, "clk_uart_baud1", &s3c24xx_uclk),
-	CLKDEV_INIT(NULL, "clk_uart_baud2", &clk_p),
-	CLKDEV_INIT(NULL, "clk_uart_baud3", &clk_esys_uart.clk),
-	CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.0", &hsmmc1_clk),
-	CLKDEV_INIT("s3c2443-spi.0", "spi_busclk0", &hsspi_clk),
-};
-
-void __init s3c2443_common_init_clocks(int xtal, pll_fn get_mpll,
-				       unsigned int *divs, int nr_divs,
-				       int divmask)
-{
-	int ptr;
-
-	armdiv = divs;
-	nr_armdiv = nr_divs;
-	armdivmask = divmask;
-
-	/* s3c2443 parents h clock from prediv */
-	clk_h.parent = &clk_prediv;
-	clk_h.ops = &clk_h_ops;
-
-	/* and p clock from h clock */
-	clk_p.parent = &clk_h;
-	clk_p.ops = &clk_p_ops;
-
-	clk_usb_bus.parent = &clk_usb_bus_host.clk;
-	clk_epll.parent = &clk_epllref.clk;
-
-	s3c24xx_register_baseclocks(xtal);
-	s3c24xx_register_clocks(clks, ARRAY_SIZE(clks));
-
-	for (ptr = 0; ptr < ARRAY_SIZE(clksrcs); ptr++)
-		s3c_register_clksrc(clksrcs[ptr], 1);
-
-	s3c_register_clksrc(clksrc_clks, ARRAY_SIZE(clksrc_clks));
-	s3c_register_clocks(init_clocks, ARRAY_SIZE(init_clocks));
-
-	/* See s3c2443/etc notes on disabling clocks at init time */
-	s3c_register_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
-	s3c_disable_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
-	clkdev_add_table(s3c2443_clk_lookup, ARRAY_SIZE(s3c2443_clk_lookup));
-
-	s3c2443_common_setup_clocks(get_mpll);
-}
-#endif
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 0fe0254..6eae7a1 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -143,7 +143,6 @@ static struct cpu_table cpu_ids[] __initdata = {
 		.idcode		= 0x32450003,
 		.idmask		= 0xffffffff,
 		.map_io		= s3c2416_map_io,
-		.init_clocks	= s3c2416_init_clocks,
 		.init_uarts	= s3c2416_init_uarts,
 		.init		= s3c2416_init,
 		.name		= name_s3c2416,
@@ -152,7 +151,6 @@ static struct cpu_table cpu_ids[] __initdata = {
 		.idcode		= 0x32443001,
 		.idmask		= 0xffffffff,
 		.map_io		= s3c2443_map_io,
-		.init_clocks	= s3c2443_init_clocks,
 		.init_uarts	= s3c2443_init_uarts,
 		.init		= s3c2443_init,
 		.name		= name_s3c2443,
@@ -331,3 +329,19 @@ void __init_or_cpufreq s3c24xx_setup_clocks(unsigned long fclk,
 	clk_f.rate = fclk;
 }
 #endif
+
+#if defined(CONFIG_COMMON_CLK) && defined(CONFIG_CPU_S3C2416)
+void __init s3c2416_init_clocks(int xtal)
+{
+	s3c2443_common_clk_init(NULL, 0, S3C24XX_VA_CLKPWR);
+	s3c2443_clk_register_fixed_ext(xtal, 0, 0, 0);
+}
+#endif
+
+#if defined(CONFIG_COMMON_CLK) && defined(CONFIG_CPU_S3C2443)
+void __init s3c2443_init_clocks(int xtal)
+{
+	s3c2443_common_clk_init(NULL, 1, S3C24XX_VA_CLKPWR);
+	s3c2443_clk_register_fixed_ext(xtal, 0, 0, 0);
+}
+#endif
diff --git a/arch/arm/mach-s3c24xx/common.h b/arch/arm/mach-s3c24xx/common.h
index 307c371..2cbcec3 100644
--- a/arch/arm/mach-s3c24xx/common.h
+++ b/arch/arm/mach-s3c24xx/common.h
@@ -107,4 +107,12 @@ extern void s3c2443_init_irq(void);
 
 extern struct syscore_ops s3c24xx_irq_syscore_ops;
 
+#ifdef CONFIG_COMMON_CLK_S3C2443
+extern void s3c2443_clk_register_fixed_ext(unsigned long xti_f,
+				unsigned long ext_f, unsigned long i2s_f,
+				unsigned long uart_f);
+void __init s3c2443_common_clk_init(struct device_node *np, int current_soc,
+			     void __iomem *reg_base);
+#endif
+
 #endif /* __ARCH_ARM_MACH_S3C24XX_COMMON_H */
diff --git a/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
index f50454a..fc6823a 100644
--- a/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
+++ b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
@@ -19,6 +19,7 @@
 #include <linux/irqchip.h>
 #include <linux/of_platform.h>
 #include <linux/serial_core.h>
+#include <linux/clk-provider.h>
 
 #include <asm/mach/arch.h>
 #include <mach/map.h>
@@ -29,48 +30,20 @@
 
 #include "common.h"
 
-/*
- * The following lookup table is used to override device names when devices
- * are registered from device tree. This is temporarily added to enable
- * device tree support addition for the S3C2416 architecture.
- *
- * For drivers that require platform data to be provided from the machine
- * file, a platform data pointer can also be supplied along with the
- * devices names. Usually, the platform data elements that cannot be parsed
- * from the device tree by the drivers (example: function pointers) are
- * supplied. But it should be noted that this is a temporary mechanism and
- * at some point, the drivers should be capable of parsing all the platform
- * data from the device tree.
- */
-static const struct of_dev_auxdata s3c2416_auxdata_lookup[] __initconst = {
-	OF_DEV_AUXDATA("samsung,s3c2440-uart", S3C24XX_PA_UART,
-				"s3c2440-uart.0", NULL),
-	OF_DEV_AUXDATA("samsung,s3c2440-uart", S3C24XX_PA_UART + 0x4000,
-				"s3c2440-uart.1", NULL),
-	OF_DEV_AUXDATA("samsung,s3c2440-uart", S3C24XX_PA_UART + 0x8000,
-				"s3c2440-uart.2", NULL),
-	OF_DEV_AUXDATA("samsung,s3c2440-uart", S3C24XX_PA_UART + 0xC000,
-				"s3c2440-uart.3", NULL),
-	OF_DEV_AUXDATA("samsung,s3c6410-sdhci", S3C_PA_HSMMC0,
-				"s3c-sdhci.0", NULL),
-	OF_DEV_AUXDATA("samsung,s3c6410-sdhci", S3C_PA_HSMMC1,
-				"s3c-sdhci.1", NULL),
-	OF_DEV_AUXDATA("samsung,s3c2440-i2c", S3C_PA_IIC,
-				"s3c2440-i2c.0", NULL),
-	{},
-};
-
 static void __init s3c2416_dt_map_io(void)
 {
 	s3c24xx_init_io(NULL, 0);
-	s3c24xx_init_clocks(12000000);
 }
 
-static void __init s3c2416_dt_machine_init(void)
+static void __init s3c2416_dt_init_time(void)
 {
-	of_platform_populate(NULL, of_default_bus_match_table,
-				s3c2416_auxdata_lookup, NULL);
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
 
+static void __init s3c2416_dt_machine_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 	s3c_pm_init();
 }
 
@@ -86,6 +59,6 @@ DT_MACHINE_START(S3C2416_DT, "Samsung S3C2416 (Flattened Device Tree)")
 	.map_io		= s3c2416_dt_map_io,
 	.init_irq	= irqchip_init,
 	.init_machine	= s3c2416_dt_machine_init,
-	 .init_time	= clocksource_of_init,
+	.init_time	= s3c2416_dt_init_time,
 	.restart	= s3c2416_restart,
 MACHINE_END
diff --git a/arch/arm/mach-s3c24xx/mach-smdk2416.c b/arch/arm/mach-s3c24xx/mach-smdk2416.c
index cb46847..077d44c 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2416.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2416.c
@@ -217,10 +217,15 @@ static struct platform_device *smdk2416_devices[] __initdata = {
 	&s3c_device_usb_hsudc,
 };
 
+static void __init smdk2416_init_time(void)
+{
+	s3c2416_init_clocks(12000000);
+	samsung_timer_init();
+}
+
 static void __init smdk2416_map_io(void)
 {
 	s3c24xx_init_io(smdk2416_iodesc, ARRAY_SIZE(smdk2416_iodesc));
-	s3c24xx_init_clocks(12000000);
 	s3c24xx_init_uarts(smdk2416_uartcfgs, ARRAY_SIZE(smdk2416_uartcfgs));
 	samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
 }
@@ -255,6 +260,6 @@ MACHINE_START(SMDK2416, "SMDK2416")
 	.init_irq	= s3c2416_init_irq,
 	.map_io		= smdk2416_map_io,
 	.init_machine	= smdk2416_machine_init,
-	.init_time	= samsung_timer_init,
+	.init_time	= smdk2416_init_time,
 	.restart	= s3c2416_restart,
 MACHINE_END
diff --git a/arch/arm/mach-s3c24xx/mach-smdk2443.c b/arch/arm/mach-s3c24xx/mach-smdk2443.c
index 9435c3b..0dbf470 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2443.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2443.c
@@ -120,11 +120,16 @@ static struct platform_device *smdk2443_devices[] __initdata = {
 static void __init smdk2443_map_io(void)
 {
 	s3c24xx_init_io(smdk2443_iodesc, ARRAY_SIZE(smdk2443_iodesc));
-	s3c24xx_init_clocks(12000000);
 	s3c24xx_init_uarts(smdk2443_uartcfgs, ARRAY_SIZE(smdk2443_uartcfgs));
 	samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
 }
 
+static void __init smdk2443_init_time(void)
+{
+	s3c2443_init_clocks(12000000);
+	samsung_timer_init();
+}
+
 static void __init smdk2443_machine_init(void)
 {
 	s3c_i2c0_set_platdata(NULL);
@@ -144,6 +149,6 @@ MACHINE_START(SMDK2443, "SMDK2443")
 	.init_irq	= s3c2443_init_irq,
 	.map_io		= smdk2443_map_io,
 	.init_machine	= smdk2443_machine_init,
-	.init_time	= samsung_timer_init,
+	.init_time	= smdk2443_init_time,
 	.restart	= s3c2443_restart,
 MACHINE_END
-- 
1.7.10.4



From sboyd at codeaurora.org  Tue Jul  9 19:05:28 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 9 Jul 2013 16:05:28 -0700
Subject: CPU hotplug issue w/ 0647065 clocksource: Add generic dummy
 timer driver
In-Reply-To: <51DC3FD2.9070308@wwwdotorg.org>
References: <51DAF895.1020700@wwwdotorg.org>
 <20130709005837.GC830@codeaurora.org>
 <51DC34AD.30009@wwwdotorg.org>
 <20130709163518.GD830@codeaurora.org>
 <51DC3FD2.9070308@wwwdotorg.org>
Message-ID: <20130709230528.GE830@codeaurora.org>

On 07/09, Stephen Warren wrote:
> On 07/09/2013 10:35 AM, Stephen Boyd wrote:
> > On 07/09, Stephen Warren wrote:
> >> On 07/08/2013 06:58 PM, Stephen Boyd wrote:
> >>> On 07/08, Stephen Warren wrote:
> >>>> CPU hotplug (replug) on Tegra HW seems to be occasionally broken due to
> >>>> commit 0647065 "clocksource: Add generic dummy timer driver" in
> >>>> linux-next. Reverting that commit solves the issue.
> >>>
> >>> We found some breakage during boot that has been fixed by two
> >>> commits in linus' tree already. Do you know if you have these two
> >>> patches
> >>>
> >>> 1f73a9806bdd07a5106409bbcab3884078bd34fe
> >>> 07bd1172902e782f288e4d44b1fde7dec0f08b6f
> >>
> >> I didn't before since I was using next-20130705, but I just tried
> >> next-20130709 which does have those two commits, and I still see the issue.
> >>
> > 
> > Ok can you get the output of /proc/timer_list and send it back
> 
> Sure, it's below. I took another snapshot after unplugging then
> re-plugging CPU1, and there was no difference except in the actual time
> values and list of queued events (at ~line 12). The set of timers,
> modes, etc. were all the same.

Ok I think I understand the problem now. The dummy timer is
registered with the cpu hotplug notifier first. Then the TWD is
registered, so what we get is a clockevent_register(dummy)
followed by a clockevent_register(twd) on every hotplug (probably
something we should optimize later). Regardless, when we hotplug
out the CPU, the broadcast device is in oneshot mode. When we
hotplug back in the CPU, the dummy event gets added first and
fills in the per-cpu tickdevice slot for CPU1.

When this happens we have to start the broadcast timer and the
code there just forces the broadcast device to use the periodic
broadcast handler (see tick_device_uses_broadcast()) without
checking to see if the mode is periodic. Once that event handler
is assigned to periodic broadcast we're in danger of getting an
interrupt and trying to emulate oneshot mode when we shouldn't
be.

Can you try this patch?


diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 6d3f916..218bcb5 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -157,7 +157,10 @@ int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu)
 		dev->event_handler = tick_handle_periodic;
 		tick_device_setup_broadcast_func(dev);
 		cpumask_set_cpu(cpu, tick_broadcast_mask);
-		tick_broadcast_start_periodic(bc);
+		if (tick_broadcast_device.mode == TICKDEV_MODE_PERIODIC)
+			tick_broadcast_start_periodic(bc);
+		else
+			tick_broadcast_setup_oneshot(bc);
 		ret = 1;
 	} else {
 		/*

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From dianders at chromium.org  Tue Jul  9 19:19:16 2013
From: dianders at chromium.org (Doug Anderson)
Date: Tue,  9 Jul 2013 16:19:16 -0700
Subject: [PATCH v2 0/5] mmc: dw_mmc: fixes for suspend/resume on exynos
In-Reply-To: <1373391071-6312-1-git-send-email-dianders@chromium.org>
References: <1373391071-6312-1-git-send-email-dianders@chromium.org>
Message-ID: <1373411961-23812-1-git-send-email-dianders@chromium.org>

This series of patches addresses some suspend/resume problems with
dw_mmc on exynos platforms.  Since suspend/resume is not fully working
on ToT Linux (3.10) on exynos5250-snow, this series was tested against
the current ToT ChromeOS 3.8 tree.  I have confirmed basic booting
and eMMC / SD card usage (and compiling, honest!) against ToT Linux.

Changes in v2:
- Fix typo (some -> come)
- Use ~0 instead of 0xFFFFFFFF; add comment about value
- Use suspend_noirq as per James Hogan.

Doug Anderson (5):
  mmc: dw_mmc: Invalidate cache of current_speed after suspend/resume
  mmc: dw_mmc: Add suspend_noirq/resume_noirq callbacks for dw_mmc-pltfm
  mmc: dw_mmc: Add exynos resume_noirq callback to clear WAKEUP_INT
  mmc: dw_mmc: Always setup the bus after suspend/resume
  mmc: dw_mmc: Set timeout to max upon resume

 drivers/mmc/host/dw_mmc-exynos.c | 23 +++++++++++++++++++++++
 drivers/mmc/host/dw_mmc-pltfm.c  | 37 ++++++++++++++++++++++++++++++++++---
 drivers/mmc/host/dw_mmc.c        | 15 +++++++++++----
 drivers/mmc/host/dw_mmc.h        |  4 ++++
 4 files changed, 72 insertions(+), 7 deletions(-)

-- 
1.8.3



From dianders at chromium.org  Tue Jul  9 19:19:19 2013
From: dianders at chromium.org (Doug Anderson)
Date: Tue,  9 Jul 2013 16:19:19 -0700
Subject: [PATCH v2 3/5] mmc: dw_mmc: Add exynos resume_noirq callback to clear
 WAKEUP_INT
In-Reply-To: <1373411961-23812-1-git-send-email-dianders@chromium.org>
References: <1373391071-6312-1-git-send-email-dianders@chromium.org>
 <1373411961-23812-1-git-send-email-dianders@chromium.org>
Message-ID: <1373411961-23812-4-git-send-email-dianders@chromium.org>

If the WAKEUP_INT is asserted at wakeup and not cleared, we'll end up
looping around forever.  This has been seen to happen on exynos5420
silicon despite the fact that we haven't enabled any wakeup events.

Signed-off-by: Doug Anderson <dianders at chromium.org>
---
Changes in v2:
- Use suspend_noirq as per James Hogan.

 drivers/mmc/host/dw_mmc-exynos.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index f013e7e..36b9620 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -30,6 +30,7 @@
 #define SDMMC_CLKSEL_TIMING(x, y, z)	(SDMMC_CLKSEL_CCLK_SAMPLE(x) |	\
 					SDMMC_CLKSEL_CCLK_DRIVE(y) |	\
 					SDMMC_CLKSEL_CCLK_DIVIDER(z))
+#define SDMMC_CLKSEL_WAKEUP_INT		BIT(11)
 
 #define SDMMC_CMD_USE_HOLD_REG		BIT(29)
 
@@ -102,6 +103,27 @@ static int dw_mci_exynos_setup_clock(struct dw_mci *host)
 	return 0;
 }
 
+/**
+ * dw_mci_exynos_resume_noirq - Exynos-specific resume code
+ *
+ * We have seen cases (at least on the exynos5420) where turning off the INT
+ * power rail during suspend will leave the WAKEUP_INT bit in the CLKSEL
+ * register asserted.  This bit is 1 to indicate that it fired and we can
+ * clear it by writing a 1 back.  Clear it to prevent interrupts from going off
+ * constantly.
+ */
+
+static int dw_mci_exynos_resume_noirq(struct dw_mci *host)
+{
+	u32 clksel;
+
+	clksel = mci_readl(host, CLKSEL);
+	if (clksel & SDMMC_CLKSEL_WAKEUP_INT)
+		mci_writel(host, CLKSEL, clksel);
+
+	return 0;
+}
+
 static void dw_mci_exynos_prepare_command(struct dw_mci *host, u32 *cmdr)
 {
 	/*
@@ -165,6 +187,7 @@ static const struct dw_mci_drv_data exynos_drv_data = {
 	.caps			= exynos_dwmmc_caps,
 	.init			= dw_mci_exynos_priv_init,
 	.setup_clock		= dw_mci_exynos_setup_clock,
+	.resume_noirq		= dw_mci_exynos_resume_noirq,
 	.prepare_command	= dw_mci_exynos_prepare_command,
 	.set_ios		= dw_mci_exynos_set_ios,
 	.parse_dt		= dw_mci_exynos_parse_dt,
-- 
1.8.3



From toddpoynor at google.com  Tue Jul  9 20:47:39 2013
From: toddpoynor at google.com (Todd Poynor)
Date: Tue,  9 Jul 2013 17:47:39 -0700
Subject: [PATCH] ARM: kgdb: ignore breakpoint instructions from user mode
Message-ID: <1373417259-22098-1-git-send-email-toddpoynor@google.com>

Avoid conflicts with user mode usage of the same instructions, as with
Clang -ftrapv, and avoid a potential denial of service.

Signed-off-by: Todd Poynor <toddpoynor at google.com>
---
 arch/arm/kernel/kgdb.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index 778c2f7..b321c8f 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -144,6 +144,8 @@ int kgdb_arch_handle_exception(int exception_vector, int signo,
 
 static int kgdb_brk_fn(struct pt_regs *regs, unsigned int instr)
 {
+	if (user_mode(regs))
+		return -1;
 	kgdb_handle_exception(1, SIGTRAP, 0, regs);
 
 	return 0;
@@ -151,6 +153,8 @@ static int kgdb_brk_fn(struct pt_regs *regs, unsigned int instr)
 
 static int kgdb_compiled_brk_fn(struct pt_regs *regs, unsigned int instr)
 {
+	if (user_mode(regs))
+		return -1;
 	compiled_break = 1;
 	kgdb_handle_exception(1, SIGTRAP, 0, regs);
 
-- 
1.8.3



From horms at verge.net.au  Tue Jul  9 20:50:08 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 09:50:08 +0900
Subject: [PATCH] ARM: shmobile: KZM9D DT reference implementation
In-Reply-To: <20130708060030.13607.45725.sendpatchset@w520>
References: <20130708060030.13607.45725.sendpatchset@w520>
Message-ID: <20130710005007.GB32603@verge.net.au>

On Mon, Jul 08, 2013 at 03:00:30PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Add a DT reference implementation for the KZM9D board.
> 
> Only DT devices are used in this case. UART, STI, GPIO
> and SMP / GIC are all provided by emev2.dtsi.
> 
> There is still a board specific C file used for enabling
> legacy SH clocks. This file will be removed after we have
> moved over to common clocks.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  Written against "renesas-next-20130704v2". Boot tested on KZM9D.
> 
>  arch/arm/boot/dts/Makefile                     |    1 
>  arch/arm/boot/dts/emev2-kzm9d-reference.dts    |   26 +++++++++++++
>  arch/arm/mach-shmobile/Kconfig                 |   12 ++++++
>  arch/arm/mach-shmobile/Makefile                |    1 
>  arch/arm/mach-shmobile/Makefile.boot           |    1 
>  arch/arm/mach-shmobile/board-kzm9d-reference.c |   47 ++++++++++++++++++++++++

Thanks, I have queued this up for v3.12 in the dt branch with a minor
change noted below.  It should appear in renesas-next-20130710

>  6 files changed, 88 insertions(+)
> 
> --- 0001/arch/arm/boot/dts/Makefile
> +++ work/arch/arm/boot/dts/Makefile	2013-07-08 14:24:15.000000000 +0900
> @@ -160,6 +160,7 @@ dtb-$(CONFIG_ARCH_U8500) += snowball.dtb
>  	hrefv60plus.dtb \
>  	ccu9540.dtb
>  dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
> +	emev2-kzm9d-reference.dtb \
>  	r8a7740-armadillo800eva.dtb \
>  	r8a7778-bockw.dtb \
>  	r8a7740-armadillo800eva-reference.dtb \
> --- /dev/null
> +++ work/arch/arm/boot/dts/emev2-kzm9d-reference.dts	2013-07-08 14:48:50.000000000 +0900
> @@ -0,0 +1,26 @@
> +/*
> + * Device Tree Source for the KZM9D board
> + *
> + * Copyright (C) 2013 Renesas Solutions Corp.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +/dts-v1/;
> +
> +/include/ "emev2.dtsi"
> +
> +/ {
> +	model = "EMEV2 KZM9D Board";
> +	compatible = "renesas,kzm9d-reference", "renesas,emev2";
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x40000000 0x8000000>;
> +	};
> +
> +	chosen {
> +		bootargs = "console=ttyS1,115200n81 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096";
> +	};
> +};
> --- 0001/arch/arm/mach-shmobile/Kconfig
> +++ work/arch/arm/mach-shmobile/Kconfig	2013-07-08 14:24:15.000000000 +0900
> @@ -167,6 +167,18 @@ config MACH_KZM9D
>  	select REGULATOR_FIXED_VOLTAGE if REGULATOR
>  	select USE_OF
>  
> +config MACH_KZM9D_REFERENCE
> +	bool "KZM9D board - Reference Device Tree Implementation"
> +	depends on ARCH_EMEV2
> +	select REGULATOR_FIXED_VOLTAGE if REGULATOR
> +	select USE_OF
> +	---help---
> +	   Use reference implementation of KZM9D board support
> +	   which makes a greater use of device tree at the expense
> +	   of not supporting a number of devices.
> +
> +	   This is intended to aid developers
> +
>  config MACH_KZM9G
>  	bool "KZM-A9-GT board"
>  	depends on ARCH_SH73A0
> --- 0001/arch/arm/mach-shmobile/Makefile
> +++ work/arch/arm/mach-shmobile/Makefile	2013-07-08 14:24:15.000000000 +0900
> @@ -47,6 +47,7 @@ obj-$(CONFIG_MACH_LAGER_REFERENCE)	+= bo
>  obj-$(CONFIG_MACH_ARMADILLO800EVA)	+= board-armadillo800eva.o
>  obj-$(CONFIG_MACH_ARMADILLO800EVA_REFERENCE)	+= board-armadillo800eva-reference.o
>  obj-$(CONFIG_MACH_KZM9D)	+= board-kzm9d.o
> +obj-$(CONFIG_MACH_KZM9D_REFERENCE)	+= board-kzm9d-reference.o
>  obj-$(CONFIG_MACH_KZM9G)	+= board-kzm9g.o
>  obj-$(CONFIG_MACH_KZM9G_REFERENCE)	+= board-kzm9g-reference.o
>  
> --- 0001/arch/arm/mach-shmobile/Makefile.boot
> +++ work/arch/arm/mach-shmobile/Makefile.boot	2013-07-08 14:24:15.000000000 +0900
> @@ -7,6 +7,7 @@ loadaddr-$(CONFIG_MACH_ARMADILLO800EVA_R
>  loadaddr-$(CONFIG_MACH_BOCKW) += 0x60008000
>  loadaddr-$(CONFIG_MACH_KOTA2) += 0x41008000
>  loadaddr-$(CONFIG_MACH_KZM9D) += 0x40008000
> +loadaddr-$(CONFIG_MACH_KZM9D_REFERENCE) += 0x40008000
>  loadaddr-$(CONFIG_MACH_KZM9G) += 0x41008000
>  loadaddr-$(CONFIG_MACH_KZM9G_REFERENCE) += 0x41008000
>  loadaddr-$(CONFIG_MACH_LAGER) += 0x40008000
> --- /dev/null
> +++ work/arch/arm/mach-shmobile/board-kzm9d-reference.c	2013-07-08 14:49:41.000000000 +0900
> @@ -0,0 +1,47 @@
> +/*
> + * kzm9d board support - Reference DT implementation
> + *
> + * Copyright (C) 2013  Renesas Solutions Corp.
> + * Copyright (C) 2013  Magnus Damm
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
> + */
> +
> +#include <linux/init.h>
> +#include <linux/of_platform.h>
> +#include <mach/emev2.h>
> +#include <mach/common.h>
> +#include <asm/mach/arch.h>
> +
> +static void __init kzm9d_add_standard_devices(void)
> +{
> +	emev2_clock_init();
> +
> +	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +}
> +
> +static const char *kzm9d_boards_compat_dt[] __initdata = {
> +	"renesas,kzm9d-reference",
> +	NULL,
> +};
> +
> +DT_MACHINE_START(KZM9D_DT, "kzm9d")
> +	.smp		= smp_ops(emev2_smp_ops),
> +	.map_io		= emev2_map_io,
> +	.init_early	= emev2_init_delay,
> +	.init_machine	= kzm9d_add_standard_devices,
> +	.init_late	= shmobile_init_late,
> +	.dt_compat	= kzm9d_boards_compat_dt,
> +MACHINE_END
> +
> 

git complained about a trailing blank line at the end of
board-kzm9d-reference.c so I have removed it.


From horms at verge.net.au  Tue Jul  9 20:51:43 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 09:51:43 +0900
Subject: [PATCH] ARM: shmobile: Minor update for the Lager DT reference
 code
In-Reply-To: <20130708061646.25516.97272.sendpatchset@w520>
References: <20130708061646.25516.97272.sendpatchset@w520>
Message-ID: <20130710005143.GC32603@verge.net.au>

On Mon, Jul 08, 2013 at 03:16:46PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Update the Lager DT reference code to get rid of the redundant
> irqchip header and also make lager_add_standard_devices() static.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  Written against "renesas-next-20130704v2"
> 
>  arch/arm/mach-shmobile/board-lager-reference.c |    3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Thanks, I have queued this up for v3.12 in the dt-lager branch.
It should appear in renesas-next-20130710


From horms at verge.net.au  Tue Jul  9 20:52:49 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 09:52:49 +0900
Subject: [PATCH] ARM: shmobile: Fix EMEV2 clock comment typo
In-Reply-To: <20130708062005.25694.62165.sendpatchset@w520>
References: <20130708062005.25694.62165.sendpatchset@w520>
Message-ID: <20130710005248.GD32603@verge.net.au>

On Mon, Jul 08, 2013 at 03:20:05PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Update the STI timer frequency comment to 32.768 kHz to
> fix 37 kHz typo.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  Written against "renesas-next-20130704v2"
> 
>  arch/arm/mach-shmobile/clock-emev2.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks, I have queued this up for v3.12 in the cleanup branch.
It should appear in renesas-next-20130710


From tibor at harsszegi.com  Tue Jul  9 20:53:44 2013
From: tibor at harsszegi.com (tibor at harsszegi.com)
Date: Wed, 10 Jul 2013 02:53:44 +0200
Subject: NSA310 + DT
In-Reply-To: <20130709202143.GD26223@lunn.ch>
References: <51DC564A.8050002@harsszegi.com>
 <20130709193605.GC26223@lunn.ch> <20130709202143.GD26223@lunn.ch>
Message-ID: <2544f179ed4349545a25aa60d52a664a@harsszegi.com>

Hello guys,

> Hi Tibor
> 
> Which NSA310 do you actually have? Apparently there are actually two
> variants:
> 
> http://zyxel.nas-central.org/wiki/Category:NSA-310
> 
> It could be yours is actually the rebranded TDC Homedisk. If so, we
> should add a new .dts file for it.
> 
> Andrew

Well that's a good one. Hohestly have zero idea :(
Here is lspci and cpuinfo.

root at nsa310:~# lspci
00:00.0 Host bridge: Marvell Technology Group Ltd. 88F6281 [Kirkwood] 
ARM SoC (rev 03)
00:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
root at nsa310:~# cat /proc/cpuinfo
processor       : 0
model name      : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1196.85
Features        : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Hardware        : Marvell Kirkwood (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000

I was using the patches from here, they worked
flawlessly (until pre DT kernels)

https://github.com/peeter123/NSA310-320-debian

Cheers,
Tibor


From tibor at harsszegi.com  Tue Jul  9 21:01:22 2013
From: tibor at harsszegi.com (tibor at harsszegi.com)
Date: Wed, 10 Jul 2013 03:01:22 +0200
Subject: NSA310 + DT
In-Reply-To: <20130709193605.GC26223@lunn.ch>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
Message-ID: <1a9bcb9094ae695c6707c4835417dd5b@harsszegi.com>

Hello guys,

> A basic question to start with. Are you using the default kernel
> configuration for kirkwood? Which kernel version are you using?
> 

standard kernels, have been trying 3.9.8,3.9.9 and 3.10

> Do you know what address it is using on the i2c bus? It looks like it
> would be one of: 0x2c, 0x2d, 0x2e. Does you board also have the
> adt7476?

The address is the same as the adt ones' but it is
recognized as a lm85. Sorry was a bit misleading. I could
make my sensors work via simply changing the type
from adt7476 to lm85

> b.) uart0 is not recognized at all during boot, I cannot see that
> 8250 would recognize the UART at the mmaped area, however the .DTS
> config seems fine
> 
> Do you see anything like:
> 
> Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
> console [ttyS0] enabled
> f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A
> 

None at all. I only see the first "Serial:" line, then
nothing else, seems like the UART0 is stucked, badly mapped/initialized
at that time.

> c.) LEDs are also not working, this is also strange, as the .DTS
> seems to be just fine as well.
> 
> How do you mean not working? Is /sys/class/leds/ empty? Or when you
> change the brightness value, nothing happens?
> 
Sorry lame me, wasn't clear again :)
All the LEDs remain "uninitialized", all
remains green after bootup, haven't tried setting
them yet :(

Cheers,
Tibor


From horms at verge.net.au  Tue Jul  9 21:03:17 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 10:03:17 +0900
Subject: [PATCH] ARM: shmobile: Add SMSC ethernet chip to KZM9D DT
 reference
In-Reply-To: <51DC0BA0.2060306@cogentembedded.com>
References: <20130709042654.13658.20164.sendpatchset@w520>
 <51DBF7CD.8040009@cogentembedded.com>
 <CANqRtoQfkk9KFggw5dadqih-kqNTCGC+kVCKkOUO8G=1w+kh6g@mail.gmail.com>
 <51DC0BA0.2060306@cogentembedded.com>
Message-ID: <20130710010317.GG32603@verge.net.au>

On Tue, Jul 09, 2013 at 05:09:52PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 09-07-2013 17:03, Magnus Damm wrote:
> 
> >>>From: Magnus Damm <damm at opensource.se>
> 
> >>>Add support for the SMSC ethernet controller found
> >>>on the KZM9D board to the KZM9D DT Reference code.
> 
> >>>Signed-off-by: Magnus Damm <damm at opensource.se>
> >>>---
> 
> >>>   Built on top of renesas-next-20130704v2 and
> >>>   [PATCH] ARM: shmobile: KZM9D DT reference implementation
> 
> >>>   arch/arm/boot/dts/emev2-kzm9d-reference.dts |   31
> >>>+++++++++++++++++++++++++++
> >>>   1 file changed, 31 insertions(+)
> 
> >>>--- 0002/arch/arm/boot/dts/emev2-kzm9d-reference.dts
> >>>+++ work/arch/arm/boot/dts/emev2-kzm9d-reference.dts    2013-07-09
> >>>13:06:47.000000000 +0900
> >>>@@ -23,4 +23,35 @@
> 
> >>[...]
> 
> >>>+       lan9220 at 20000000 {
> 
> >>    Shouldn't all the Ethernet nodes be called "ethernet"?
> 
> >Good question. Grepping in arch/arm/boot/dts shows various ways to
> >name the Ethernet nodes. Exactly what is correct or not I can't really
> >say.
> 
>    See "Node Names" section of [1].
> 
> [1] http://www.devicetree.org/Device_Tree_Usage

I will queue up this patch for v3.12 in the dt branch and
it should appear in renesas-next-20130710.

If there is a desire to consistently name nodes as "ethernet" for shmobile
then I would appreciate a cleanup patches to fix all the relevant dts and
dtsi files. One SoC or board per patch.


From josephl at nvidia.com  Tue Jul  9 21:06:49 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 10 Jul 2013 09:06:49 +0800
Subject: [PATCH V2 10/11] ARM: dts: tegra114: dalmore: add GPIO power
 key support
In-Reply-To: <51DC4274.8040607@wwwdotorg.org>
References: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
 <1372845047-25147-11-git-send-email-josephl@nvidia.com>
 <51DC4274.8040607@wwwdotorg.org>
Message-ID: <1373418409.1755.1.camel@jlo-ubuntu-64.nvidia.com>

On Wed, 2013-07-10 at 01:03 +0800, Stephen Warren wrote:
> On 07/03/2013 03:50 AM, Joseph Lo wrote:
> > Adding the GPIO power key and enabling the wake up function.
> 
> I think I'll skip this one patch, because Laxman posted a more complete
> patch "[PATCH V2] ARM: tegra: enable gpio-keys on dalmore". which
> includes this change, plus defines another 3 keys.

OK, I agree your decision.

Thanks,
Joseph




From horms at verge.net.au  Tue Jul  9 21:12:45 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 10:12:45 +0900
Subject: [PATCH 01/04] ARM: shmobile: No need to use INTC header on r8a7779
In-Reply-To: <20130709103952.1891.92697.sendpatchset@w520>
References: <20130709103944.1891.67462.sendpatchset@w520>
 <20130709103952.1891.92697.sendpatchset@w520>
Message-ID: <20130710011244.GL32603@verge.net.au>

On Tue, Jul 09, 2013 at 07:39:52PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Now when the intc-irqpin driver is used for external
> IRQ pins on r8a7779 it possible to get rid of unused
> INTC headers mach/intc.h and linux/sh_intc.h.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

Thanks, I have queued this up for v3.12 in the cleanup branch.
It should appear in renesas-next-20130710


From horms at verge.net.au  Tue Jul  9 21:13:28 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 10:13:28 +0900
Subject: [PATCH 02/04] ARM: shmobile: Use pm-rmobile on sh7372 and
 r8a7740 only
In-Reply-To: <20130709104001.1891.16375.sendpatchset@w520>
References: <20130709103944.1891.67462.sendpatchset@w520>
 <20130709104001.1891.16375.sendpatchset@w520>
Message-ID: <20130710011327.GM32603@verge.net.au>

On Tue, Jul 09, 2013 at 07:40:01PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> The functions in pm-rmobile.c are only used on sh7372 and
> r8a7740, so adjust the Makefile to only link in that file
> in case those SoCs are selected.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

Thanks, I have queued this up for v3.12 in the cleanup branch.
It should appear in renesas-next-20130710


From horms at verge.net.au  Tue Jul  9 21:13:45 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 10:13:45 +0900
Subject: [PATCH 03/04] ARM: shmobile: No need to use INTC demux on r8a7740
In-Reply-To: <20130709104008.1891.17746.sendpatchset@w520>
References: <20130709103944.1891.67462.sendpatchset@w520>
 <20130709104008.1891.17746.sendpatchset@w520>
Message-ID: <20130710011344.GN32603@verge.net.au>

On Tue, Jul 09, 2013 at 07:40:08PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Now when the r8a7740 code has been converted to make use of
> GIC instead of INTC for root interrupt controller it is
> possible to exclude the low level INTC demux function
> shmobile_handle_irq_intc from linking. 
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  arch/arm/mach-shmobile/Makefile |    1 -
>  1 file changed, 1 deletion(-)

Thanks, I have queued this up for v3.12 in the cleanup branch.
It should appear in renesas-next-20130710


From horms at verge.net.au  Tue Jul  9 21:14:05 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 10:14:05 +0900
Subject: [PATCH 04/04] ARM: shmobile: Remove unused mach/dma.h
In-Reply-To: <20130709104016.1891.68682.sendpatchset@w520>
References: <20130709103944.1891.67462.sendpatchset@w520>
 <20130709104016.1891.68682.sendpatchset@w520>
Message-ID: <20130710011404.GO32603@verge.net.au>

On Tue, Jul 09, 2013 at 07:40:16PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Remove mach-shmobile mach/dma.h since it only
> seems to be used on non-mach-shmobile platforms.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  arch/arm/mach-shmobile/include/mach/dma.h |    1 -
>  1 file changed, 1 deletion(-)

Thanks, I have queued this up for v3.12 in the cleanup branch.
It should appear in renesas-next-20130710


From horms at verge.net.au  Tue Jul  9 21:23:10 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 10:23:10 +0900
Subject: [PATCH 01/02] ARM: shmobile: Introduce r8a7790_read_mode_pins()
In-Reply-To: <CANqRtoTvSGvNWwBQ9XD43CtdJNJCebzC2xtXUQcFSXxATkuNpQ@mail.gmail.com>
References: <20130709125007.4388.15701.sendpatchset@w520>
 <20130709125016.4388.47414.sendpatchset@w520>
 <51DC08A5.2080705@cogentembedded.com>
 <CANqRtoTvSGvNWwBQ9XD43CtdJNJCebzC2xtXUQcFSXxATkuNpQ@mail.gmail.com>
Message-ID: <20130710012309.GS32603@verge.net.au>

On Tue, Jul 09, 2013 at 10:05:15PM +0900, Magnus Damm wrote:
> Hi Sergei,
> 
> On Tue, Jul 9, 2013 at 9:57 PM, Sergei Shtylyov
> <sergei.shtylyov at cogentembedded.com> wrote:
> > Hello.
> >
> >
> > On 09-07-2013 16:50, Magnus Damm wrote:
> >
> >> From: Magnus Damm <damm at opensource.se>
> >
> >
> >> Break out the r8a7790 boot mode code into a separate
> >> function so it can be shared by multiple users.
> >
> >
> >> Signed-off-by: Magnus Damm <damm at opensource.se>
> >> ---
> >
> >
> > [...]
> >
> >
> >> --- 0001/arch/arm/mach-shmobile/setup-r8a7790.c
> >> +++ work/arch/arm/mach-shmobile/setup-r8a7790.c 2013-07-09
> >> 19:59:37.000000000 +0900
> >> @@ -201,6 +201,20 @@ void __init r8a7790_add_standard_devices
> >>         r8a7790_register_thermal();
> >>   }
> >>
> >> +#define MODEMR 0xe6160060
> >> +
> >> +u32 __init r8a7790_read_mode_pins(void)
> >> +{
> >> +       void __iomem *modemr = ioremap_nocache(MODEMR, PAGE_SIZE);
> >
> >
> >    Why ioremap the whole page if you only need 4 bytes, and the address is
> > not aligned to page?
> 
> Because the original code did so. =)
> 
> But yes, indeed, using two pages seems kind of pointless.

Lets fix that up in another patch, it seems orthogonal to this change.


From horms at verge.net.au  Tue Jul  9 21:23:47 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 10:23:47 +0900
Subject: [PATCH 00/02] ARM: shmobile: r8a7790 arch timer frequency update
In-Reply-To: <20130709125007.4388.15701.sendpatchset@w520>
References: <20130709125007.4388.15701.sendpatchset@w520>
Message-ID: <20130710012346.GT32603@verge.net.au>

On Tue, Jul 09, 2013 at 09:50:07PM +0900, Magnus Damm wrote:
> ARM: shmobile: r8a7790 arch timer frequency update
> 
> [PATCH 01/02] ARM: shmobile: Introduce r8a7790_read_mode_pins()
> [PATCH 02/02] ARM: shmobile: Setup r8a7790 arch timer based on MD pins
> 
> Add code to setup r8a7790 arch timer frequency dynamically at boot time
> based on the EXTAL frequency pointed out by the boot mode pins.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  Built on top of renesas-next-20130704v2
> 
>  arch/arm/mach-shmobile/clock-r8a7790.c        |   11 ----
>  arch/arm/mach-shmobile/include/mach/r8a7790.h |    3 +
>  arch/arm/mach-shmobile/setup-r8a7790.c        |   63 +++++++++++++++++++++++--
>  3 files changed, 63 insertions(+), 14 deletions(-)

Hi Magnus,

could you please let me know if/when these patches are ready to queue-up
for v3.12?


From koba at kmckk.co.jp  Tue Jul  9 21:56:36 2013
From: koba at kmckk.co.jp (Tetsuyuki Kobayashi)
Date: Wed, 10 Jul 2013 10:56:36 +0900
Subject: [PATCH 2/3] ARM: shmobile: Force ARM mode to compile reset vector for
 secondary CPUs
In-Reply-To: <1373421397-1786-1-git-send-email-koba@kmckk.co.jp>
References: <1373421397-1786-1-git-send-email-koba@kmckk.co.jp>
Message-ID: <1373421397-1786-3-git-send-email-koba@kmckk.co.jp>

Instructions start from boot vector must be ARM mode.
This patch specify ARM mode explicitly and use 'bx' instruction to be
able to change to Thumb mode.

Signed-off-by: Tetsuyuki Kobayashi <koba at kmckk.co.jp>
---
 arch/arm/mach-shmobile/headsmp.S |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index 559d1ce..afed58e 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -26,10 +26,13 @@ ENDPROC(shmobile_invalidate_start)
  * This will be mapped at address 0 by SBAR register.
  * We need _long_ jump to the physical address.
  */
+	.arm
 	.align  12
 ENTRY(shmobile_boot_vector)
 	ldr     r0, 2f
-	ldr     pc, 1f
+	ldr     r1, 1f
+	bx	r1
+
 ENDPROC(shmobile_boot_vector)
 
 	.globl	shmobile_boot_fn
-- 
1.7.9.5



From koba at kmckk.co.jp  Tue Jul  9 21:56:34 2013
From: koba at kmckk.co.jp (Tetsuyuki Kobayashi)
Date: Wed, 10 Jul 2013 10:56:34 +0900
Subject: [PATCH 0/3] ARM: shmobile: enable SMP Thumb2 kernel
Message-ID: <1373421397-1786-1-git-send-email-koba@kmckk.co.jp>

Hello,

I try to build SMP kernel for KZM-A9-GT board in CONFIG_THUMB2_KERNEL=y.
After some modification it successully boots in Thumb2 kernel.
In my case, Thumb2 kernel is 23% smaller than usual ARM kernel.

   text	   data	    bss	    dec	    hex	filename
4763561	 251580	 196164	5211305	 4f84a9	out.kzm9g/vmlinux

   text	   data	    bss	    dec	    hex	filename
3595265	 251668	 196164	4043097	 3db159	out.kzm9g_thumb/vmlinux


Useful info for Thumb2 kernel
https://wiki.linaro.org/WorkingGroups/KernelArchived/Thumb2Guide

This patch set is based on arm-soc git repositry, 
remotes/origin/renesas/soc-cleanup branch
53332005bfde9d2e3c9a66030c0e8c2598eaa1d5 ARM: shmobile: Remove Bonito board support

Tetsuyuki Kobayashi (3):
  ARM: shmobile: fix compile error when CONFIG_THUMB2_KERNEL=y
  ARM: shmobile: Force ARM mode to compile reset vector for secondary
    CPUs
  ARM: shmobile: Insert align directives before 4 bytes data

 arch/arm/mach-shmobile/headsmp-scu.S  |    4 +++-
 arch/arm/mach-shmobile/headsmp.S      |    6 +++++-
 arch/arm/mach-shmobile/sleep-sh7372.S |    2 ++
 3 files changed, 10 insertions(+), 2 deletions(-)

-- 
1.7.9.5



From koba at kmckk.co.jp  Tue Jul  9 21:56:35 2013
From: koba at kmckk.co.jp (Tetsuyuki Kobayashi)
Date: Wed, 10 Jul 2013 10:56:35 +0900
Subject: [PATCH 1/3] ARM: shmobile: fix compile error when
 CONFIG_THUMB2_KERNEL=y
In-Reply-To: <1373421397-1786-1-git-send-email-koba@kmckk.co.jp>
References: <1373421397-1786-1-git-send-email-koba@kmckk.co.jp>
Message-ID: <1373421397-1786-2-git-send-email-koba@kmckk.co.jp>

On KZM-A9-GT board (SMP), when CONFIG_THUMB2_KERNEL=y it fails to compile
 
  AS      arch/arm/mach-shmobile/headsmp-scu.o
/proj/koba/kernel/arm-soc/arch/arm/mach-shmobile/headsmp-scu.S: Assembler messages:
/proj/koba/kernel/arm-soc/arch/arm/mach-shmobile/headsmp-scu.S:41: Error: shift must be constant -- `bic r2,r2,r3,lsl r1'
make[2]: *** [arch/arm/mach-shmobile/headsmp-scu.o] Error 1
make[1]: *** [arch/arm/mach-shmobile] Error 2
make: *** [sub-make] Error 2

Instruction `bic r2,r2,r3,lsl r1' is not supported in thumb mode. This patch split it into 2 instructions.

Signed-off-by: Tetsuyuki Kobayashi <koba at kmckk.co.jp>
---
 arch/arm/mach-shmobile/headsmp-scu.S |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/headsmp-scu.S b/arch/arm/mach-shmobile/headsmp-scu.S
index 6f98654..5ce416c 100644
--- a/arch/arm/mach-shmobile/headsmp-scu.S
+++ b/arch/arm/mach-shmobile/headsmp-scu.S
@@ -38,7 +38,8 @@ ENTRY(shmobile_boot_scu)
 	lsl	r1, r1, #3		@ we will shift by cpu_id * 8 bits
 	ldr	r2, [r0, #8]		@ SCU Power Status Register
 	mov	r3, #3
-	bic	r2, r2, r3, lsl r1	@ Clear bits of our CPU (Run Mode)
+	lsl	r3, r3, r1
+	bic	r2, r2, r3		@ Clear bits of our CPU (Run Mode)
 	str	r2, [r0, #8]		@ write back
 
 	b	shmobile_invalidate_start
-- 
1.7.9.5



From koba at kmckk.co.jp  Tue Jul  9 21:56:37 2013
From: koba at kmckk.co.jp (Tetsuyuki Kobayashi)
Date: Wed, 10 Jul 2013 10:56:37 +0900
Subject: [PATCH 3/3] ARM: shmobile: Insert align directives before 4 bytes data
In-Reply-To: <1373421397-1786-1-git-send-email-koba@kmckk.co.jp>
References: <1373421397-1786-1-git-send-email-koba@kmckk.co.jp>
Message-ID: <1373421397-1786-4-git-send-email-koba@kmckk.co.jp>

In thumb2 mode instructions are not align to 4 byte. This patch insert
align directives before putting 4 byte data.

Signed-off-by: Tetsuyuki Kobayashi <koba at kmckk.co.jp>
---
 arch/arm/mach-shmobile/headsmp-scu.S  |    1 +
 arch/arm/mach-shmobile/headsmp.S      |    1 +
 arch/arm/mach-shmobile/sleep-sh7372.S |    2 ++
 3 files changed, 4 insertions(+)

diff --git a/arch/arm/mach-shmobile/headsmp-scu.S b/arch/arm/mach-shmobile/headsmp-scu.S
index 5ce416c..0a77488 100644
--- a/arch/arm/mach-shmobile/headsmp-scu.S
+++ b/arch/arm/mach-shmobile/headsmp-scu.S
@@ -46,6 +46,7 @@ ENTRY(shmobile_boot_scu)
 ENDPROC(shmobile_boot_scu)
 
 	.text
+	.align	2
 	.globl	shmobile_scu_base
 shmobile_scu_base:
 	.space	4
diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index afed58e..dfb41df 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -35,6 +35,7 @@ ENTRY(shmobile_boot_vector)
 
 ENDPROC(shmobile_boot_vector)
 
+	.align	2
 	.globl	shmobile_boot_fn
 shmobile_boot_fn:
 1:	.space	4
diff --git a/arch/arm/mach-shmobile/sleep-sh7372.S b/arch/arm/mach-shmobile/sleep-sh7372.S
index 53f4840..9782862 100644
--- a/arch/arm/mach-shmobile/sleep-sh7372.S
+++ b/arch/arm/mach-shmobile/sleep-sh7372.S
@@ -41,6 +41,7 @@
 sh7372_resume_core_standby_sysc:
 	ldr     pc, 1f
 
+	.align	2
 	.globl	sh7372_cpu_resume
 sh7372_cpu_resume:
 1:	.space	4
@@ -96,6 +97,7 @@ sh7372_do_idle_sysc:
 1:
 	b      1b
 
+	.align	2
 kernel_flush:
 	.word v7_flush_dcache_all
 #endif
-- 
1.7.9.5



From horms+renesas at verge.net.au  Tue Jul  9 22:09:12 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 11:09:12 +0900
Subject: [PATCH] dmaengine: shdma: fix a build failure on platforms with no
 DMA support
Message-ID: <1373422152-29976-1-git-send-email-horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

On platforms with no support for the shdma dmaengine driver build is
currently failing with

drivers/built-in.o: In function `sh_mobile_sdhi_probe':
drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference to`shdma_chan_filter'

Fix the breakage by defining shdma_chan_filter to NULL in such
configurations.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
[horms+renesas at verge.net.au: Apply change to shdma-base.h instead of sh_dma.h]
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 include/linux/shdma-base.h | 4 ++++
 1 file changed, 4 insertions(+)

Hi Vinod,

please consider this fix from Guennadi for v3.11 which I have rebased on top of
next-20130709. It fixes a build problem on a number of shmobile defconfigs
including bockw.

diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
index 382cf71..5b1c984 100644
--- a/include/linux/shdma-base.h
+++ b/include/linux/shdma-base.h
@@ -124,6 +124,10 @@ void shdma_chan_remove(struct shdma_chan *schan);
 int shdma_init(struct device *dev, struct shdma_dev *sdev,
 		    int chan_num);
 void shdma_cleanup(struct shdma_dev *sdev);
+#if IS_ENABLED(CONFIG_SH_DMAE_BASE)
 bool shdma_chan_filter(struct dma_chan *chan, void *arg);
+#else
+#define shdma_chan_filter NULL
+#endif
 
 #endif
-- 
1.8.2.1



From horms at verge.net.au  Tue Jul  9 22:09:47 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 11:09:47 +0900
Subject: [PATCH] dmaengine: shdma: fix a build failure on platforms with
 no DMA support
In-Reply-To: <20130708072114.GF16653@intel.com>
References: <Pine.LNX.4.64.1305301650290.29171@axis700.grange>
 <51A77CF1.7040105@ti.com> <20130531024438.GB32564@verge.net.au>
 <CAGa+x8413povhYWx+BSj=TdzQDAuYFXmjF4A2kXvQt+=n+380w@mail.gmail.com>
 <Pine.LNX.4.64.1306192125480.12502@axis700.grange>
 <20130705045350.GA10947@intel.com>
 <CAOesGMjp4Ort89z8ZhQT9xAPNyG-0uU-kz9G2f_GzRFF-Y2MxA@mail.gmail.com>
 <20130708072114.GF16653@intel.com>
Message-ID: <20130710020947.GP32603@verge.net.au>

On Mon, Jul 08, 2013 at 12:51:14PM +0530, Vinod Koul wrote:
> On Mon, Jul 08, 2013 at 12:52:16AM -0700, Olof Johansson wrote:
> > On Thu, Jul 4, 2013 at 9:53 PM, Vinod Koul <vinod.koul at intel.com> wrote:
> > > On Wed, Jun 19, 2013 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
> > >> Hi Vinod
> > >>
> > >> On Wed, 19 Jun 2013, Kevin Hilman wrote:
> > >>
> > >> > On Thu, May 30, 2013 at 7:44 PM, Simon Horman <horms at verge.net.au> wrote:
> > >> >
> > >> > [...]
> > >> >
> > >> > > thanks for this. I will wait for a refresh (as we discussed earlier today).
> > >> > > Can I confirm that this is a fix for v3.10? If so, could ou note
> > >> > > that when you post your revised patch?
> > >> >
> > >> > Any progress on this patch?
> > >> >
> > >> > The SH-mobile defconfigs are still all failing in linux-next.
> > >>
> > >> In
> > >>
> > >> https://patchwork.kernel.org/patch/2640061/
> > > And you havent CC maintainers on this patch, so I dont have it!
> > >>
> > >> I proposed a simple immediate fix for this problem. Arnd at the same time
> > >> developed an alternative solution:
> > >>
> > >> https://patchwork.kernel.org/patch/2644121/
> > >> https://patchwork.kernel.org/patch/2644111/
> > > Reading these patches I agree with Arnd that client drivers should not depend on
> > > dma slave drivers. Existing issue need to be fixed
> > >
> > > Arnd, Have you merged these changes?
> > 
> > Looks like we now have breakage in linux-next for this again (new
> > breakage due to the header file move being applied by you on Friday,
> > Vinod? Are you planning on sending the code in for 3.11? If not, you
> > shouldn't apply patches right now).
> Well they were already in my tree since 18th June. (tree was rebased to fixup for
> pull on friday) and now these are in Linus's tree.
> 
> Can we have a fix for breakage for now sent to linus for now and then address the
> proper way to do this?

That is my preferred approach.

I will repost the patch at the link
https://patchwork.kernel.org/patch/2640061/ above, rebased for the header
file rename.

Vinod, can you take things from there?


From magnus.damm at gmail.com  Tue Jul  9 22:12:25 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 10 Jul 2013 11:12:25 +0900
Subject: [PATCH 00/02] ARM: shmobile: r8a7790 arch timer frequency update
In-Reply-To: <20130710012346.GT32603@verge.net.au>
References: <20130709125007.4388.15701.sendpatchset@w520>
 <20130710012346.GT32603@verge.net.au>
Message-ID: <CANqRtoSHk_LJ6AyFqHYPy6w-As3XN=3Peku08gDMoEcz5MoRHQ@mail.gmail.com>

On Wed, Jul 10, 2013 at 10:23 AM, Simon Horman <horms at verge.net.au> wrote:
> On Tue, Jul 09, 2013 at 09:50:07PM +0900, Magnus Damm wrote:
>> ARM: shmobile: r8a7790 arch timer frequency update
>>
>> [PATCH 01/02] ARM: shmobile: Introduce r8a7790_read_mode_pins()
>> [PATCH 02/02] ARM: shmobile: Setup r8a7790 arch timer based on MD pins
>>
>> Add code to setup r8a7790 arch timer frequency dynamically at boot time
>> based on the EXTAL frequency pointed out by the boot mode pins.
>>
>> Signed-off-by: Magnus Damm <damm at opensource.se>
>> ---
>>
>>  Built on top of renesas-next-20130704v2
>>
>>  arch/arm/mach-shmobile/clock-r8a7790.c        |   11 ----
>>  arch/arm/mach-shmobile/include/mach/r8a7790.h |    3 +
>>  arch/arm/mach-shmobile/setup-r8a7790.c        |   63 +++++++++++++++++++++++--
>>  3 files changed, 63 insertions(+), 14 deletions(-)
>
> Hi Magnus,

Hi Simon,

Thanks for your help picking up patches.

> could you please let me know if/when these patches are ready to queue-up
> for v3.12?

There are two things to consider:
1) Patch 1/2 needs to be updated to handle feedback from Sergei.
2) I'd like the series to be tested by Ulrich to see if they actually help!

I can resend 1/2 today or tomorrow and I think Ulrich can most likely
help us with testing sometime this week.

Cheers,

/ magnus


From horms at verge.net.au  Tue Jul  9 22:21:04 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 11:21:04 +0900
Subject: [PATCH 00/02] ARM: shmobile: r8a7790 arch timer frequency update
In-Reply-To: <CANqRtoSHk_LJ6AyFqHYPy6w-As3XN=3Peku08gDMoEcz5MoRHQ@mail.gmail.com>
References: <20130709125007.4388.15701.sendpatchset@w520>
 <20130710012346.GT32603@verge.net.au>
 <CANqRtoSHk_LJ6AyFqHYPy6w-As3XN=3Peku08gDMoEcz5MoRHQ@mail.gmail.com>
Message-ID: <20130710022103.GR32603@verge.net.au>

On Wed, Jul 10, 2013 at 11:12:25AM +0900, Magnus Damm wrote:
> On Wed, Jul 10, 2013 at 10:23 AM, Simon Horman <horms at verge.net.au> wrote:
> > On Tue, Jul 09, 2013 at 09:50:07PM +0900, Magnus Damm wrote:
> >> ARM: shmobile: r8a7790 arch timer frequency update
> >>
> >> [PATCH 01/02] ARM: shmobile: Introduce r8a7790_read_mode_pins()
> >> [PATCH 02/02] ARM: shmobile: Setup r8a7790 arch timer based on MD pins
> >>
> >> Add code to setup r8a7790 arch timer frequency dynamically at boot time
> >> based on the EXTAL frequency pointed out by the boot mode pins.
> >>
> >> Signed-off-by: Magnus Damm <damm at opensource.se>
> >> ---
> >>
> >>  Built on top of renesas-next-20130704v2
> >>
> >>  arch/arm/mach-shmobile/clock-r8a7790.c        |   11 ----
> >>  arch/arm/mach-shmobile/include/mach/r8a7790.h |    3 +
> >>  arch/arm/mach-shmobile/setup-r8a7790.c        |   63 +++++++++++++++++++++++--
> >>  3 files changed, 63 insertions(+), 14 deletions(-)
> >
> > Hi Magnus,
> 
> Hi Simon,
> 
> Thanks for your help picking up patches.
> 
> > could you please let me know if/when these patches are ready to queue-up
> > for v3.12?
> 
> There are two things to consider:
> 1) Patch 1/2 needs to be updated to handle feedback from Sergei.
> 2) I'd like the series to be tested by Ulrich to see if they actually help!
> 
> I can resend 1/2 today or tomorrow and I think Ulrich can most likely
> help us with testing sometime this week.

Thanks, I'll wait for your repost and feedback from Ulrich.


From b32955 at freescale.com  Tue Jul  9 22:58:26 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 10 Jul 2013 10:58:26 +0800
Subject: [PATCH] of: match the compatible in the order set by the dts file
In-Reply-To: <CAL_JsqL4ABJCQXveSAMZKOiHwJi=w8zFYjg3DV7kqEEcCXQJcw@mail.gmail.com>
References: <1373013818-11365-1-git-send-email-b32955@freescale.com>	<20130709070541.GQ516@pengutronix.de>	<51DBBFDA.70302@freescale.com>	<20130709075124.GR516@pengutronix.de>	<51DBC58D.90002@freescale.com>
 <CAL_JsqL4ABJCQXveSAMZKOiHwJi=w8zFYjg3DV7kqEEcCXQJcw@mail.gmail.com>
Message-ID: <51DCCDD2.707@freescale.com>

? 2013?07?09? 20:03, Rob Herring ??:
> the same and that is the assumption. Matching is not just based on
> compatible properties and your patch does not handle the other cases.
Could you show a example of "the other cases"?

After this patch,

[1] the matching will first check the @match->type and @match->name,
if we can match the @match->type or @match->name, return the match
immediately.

[2] If [1] fails, we will check the compatible properties.



thanks
Huang Shijie





From magnus.damm at gmail.com  Tue Jul  9 23:44:26 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 10 Jul 2013 12:44:26 +0900
Subject: [PATCH 0/3] ARM: shmobile: enable SMP Thumb2 kernel
In-Reply-To: <1373421397-1786-1-git-send-email-koba@kmckk.co.jp>
References: <1373421397-1786-1-git-send-email-koba@kmckk.co.jp>
Message-ID: <CANqRtoSK9WoJJ2LOB-dRCjz5fQy8b5Cm+B+Fz9Mv3E5P6oFLQw@mail.gmail.com>

Hi Kobayashi-san,

Your patch series looks fine to me. Thanks for your contribution.

Acked-by: Magnus Damm <damm at opensource.se>

On Wed, Jul 10, 2013 at 10:56 AM, Tetsuyuki Kobayashi <koba at kmckk.co.jp> wrote:
> Hello,
>
> I try to build SMP kernel for KZM-A9-GT board in CONFIG_THUMB2_KERNEL=y.
> After some modification it successully boots in Thumb2 kernel.
> In my case, Thumb2 kernel is 23% smaller than usual ARM kernel.
>
>    text    data     bss     dec     hex filename
> 4763561  251580  196164 5211305  4f84a9 out.kzm9g/vmlinux
>
>    text    data     bss     dec     hex filename
> 3595265  251668  196164 4043097  3db159 out.kzm9g_thumb/vmlinux
>
>
> Useful info for Thumb2 kernel
> https://wiki.linaro.org/WorkingGroups/KernelArchived/Thumb2Guide
>
> This patch set is based on arm-soc git repositry,
> remotes/origin/renesas/soc-cleanup branch
> 53332005bfde9d2e3c9a66030c0e8c2598eaa1d5 ARM: shmobile: Remove Bonito board support
>
> Tetsuyuki Kobayashi (3):
>   ARM: shmobile: fix compile error when CONFIG_THUMB2_KERNEL=y
>   ARM: shmobile: Force ARM mode to compile reset vector for secondary
>     CPUs
>   ARM: shmobile: Insert align directives before 4 bytes data
>
>  arch/arm/mach-shmobile/headsmp-scu.S  |    4 +++-
>  arch/arm/mach-shmobile/headsmp.S      |    6 +++++-
>  arch/arm/mach-shmobile/sleep-sh7372.S |    2 ++
>  3 files changed, 10 insertions(+), 2 deletions(-)
>
> --
> 1.7.9.5
>


From haojian.zhuang at gmail.com  Wed Jul 10 01:58:39 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Wed, 10 Jul 2013 13:58:39 +0800
Subject: [PATCH V3 2/3] clocksource: mmp: support CLOCKSOURCE OF DECLARE
In-Reply-To: <201307092316.20905.arnd@arndb.de>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-3-git-send-email-zhangwm@marvell.com>
 <20130709181434.76f6216d@skate> <201307092316.20905.arnd@arndb.de>
Message-ID: <CAN1soZyFztVR1XSw9bDS5JexK0Mdbpr6yevatVf+MnBohwCj1Q@mail.gmail.com>

On Wed, Jul 10, 2013 at 5:16 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Tuesday 09 July 2013, Thomas Petazzoni wrote:
>> Dear Neil Zhang,
>>
>> On Tue, 9 Jul 2013 14:42:45 +0800, Neil Zhang wrote:
>> > support CLOCKSOURCE OF DECLARE for mmp timer.
>> >
>> > Signed-off-by: Neil Zhang <zhangwm at marvell.com>
>> > ---
>> >  arch/arm/mach-mmp/mmp-dt.c  |    5 ++---
>> >  arch/arm/mach-mmp/mmp2-dt.c |    3 +--
>> >  arch/arm/mach-mmp/time.c    |   15 ++-------------
>> >  3 files changed, 5 insertions(+), 18 deletions(-)
>>
>> Maybe it would be good to take this opportunity to move
>> arch/arm/mach-mmp/time.c into drivers/clocksource/.
>
> +1
>
> Or we might want to have a more coordinated move of all clocksource
> drivers in arch/arm to drivers/clocksource now, as we have done for some
> other subsystems.
>
>         Arnd

I already sent some patches on this. But I didn't get response yet. I'll rebase
them and send them again. I hope that they could be merged in this cycle.

Regards
Haojian


From voice.shen at atmel.com  Wed Jul 10 02:11:48 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Wed, 10 Jul 2013 14:11:48 +0800
Subject: [PATCH v4 1/7] sound: sam9x5_wm8731: machine driver for at91sam9x5
 wm8731 boards
In-Reply-To: <1373379933-32749-2-git-send-email-richard.genoud@gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-2-git-send-email-richard.genoud@gmail.com>
Message-ID: <51DCFB24.4080107@atmel.com>

Hi Richard,

On 7/9/2013 22:25, Richard Genoud wrote:
[snip]

> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/kernel.h>
> +#include <linux/clk.h>
> +#include <linux/timer.h>
> +#include <linux/interrupt.h>
> +#include <linux/platform_device.h>
> +#include <linux/i2c.h>
> +
> +#include <linux/atmel-ssc.h>
> +
> +#include <sound/core.h>
> +#include <sound/pcm.h>
> +#include <sound/pcm_params.h>
> +#include <sound/soc.h>
> +
> +#include <asm/mach-types.h>
> +#include <mach/hardware.h>
> +#include <mach/gpio.h>
> +
> +#include "../codecs/wm8731.h"
> +#include "atmel-pcm.h"
> +#include "atmel_ssc_dai.h"

I think some of the header file include is not needed. I keep them as 
simple as following:
---8>---
#include <linux/clk.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/pinctrl/consumer.h>

#include <sound/soc.h>

#include "../codecs/wm8731.h"
#include "atmel_ssc_dai.h"
---<8---

> +#define MCLK_RATE 12288000
> +
> +#define DRV_NAME "sam9x5-snd-wm8731"
> +
> +/*
> + * Authorized rates are:
> + * Rate = MCLK_RATE / (n * 2)
> + * Where n is in [1..4095]
> + * (cf register SSC_CMR)
> + */
> +static unsigned int rates[] = {
> +	8000,
> +	16000,
> +	32000,
> +	48000,
> +	64000,
> +	96000,
> +};

This is decided by the codec, while not ssc when ssc in slave mode.

> +static struct snd_pcm_hw_constraint_list hw_rates = {
> +	.count = ARRAY_SIZE(rates),
> +	.list = rates,
> +};
> +

[snip]

> +
> +	at91sam9x5ek_dai.dai_fmt = snd_soc_of_parse_daifmt(np, "atmel,");

We can put this into at91sam9x5ek_dai directly, not need to parse it 
then. example as following:
---8>---
.dai_fmt = SND_SOC_DAIFMT_I2S
                 | SND_SOC_DAIFMT_NB_NF
                 | SND_SOC_DAIFMT_CBM_CFM,
---<8---

Best Regards,
Bo Shen



From andrew at lunn.ch  Wed Jul 10 02:23:33 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 10 Jul 2013 08:23:33 +0200
Subject: NSA310 + DT
In-Reply-To: <2544f179ed4349545a25aa60d52a664a@harsszegi.com>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <20130709202143.GD26223@lunn.ch>
 <2544f179ed4349545a25aa60d52a664a@harsszegi.com>
Message-ID: <20130710062333.GE26223@lunn.ch>

On Wed, Jul 10, 2013 at 02:53:44AM +0200, tibor at harsszegi.com wrote:
> Hello guys,
> 
> >Hi Tibor
> >
> >Which NSA310 do you actually have? Apparently there are actually two
> >variants:
> >
> >http://zyxel.nas-central.org/wiki/Category:NSA-310
> >
> >It could be yours is actually the rebranded TDC Homedisk. If so, we
> >should add a new .dts file for it.
> >
> >Andrew
> 
> Well that's a good one. Hohestly have zero idea :(

Hi Tibor

How does it compare to the pictures on the website?

    Andrew


From shawn.guo at linaro.org  Wed Jul 10 02:33:31 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 10 Jul 2013 14:33:31 +0800
Subject: [PATCH] ARM: imx: fix vf610 enet module clock selection
Message-ID: <1373438011-12779-1-git-send-email-shawn.guo@linaro.org>

The fec/enet driver calculates MDC rate with the formula below.

  ref_freq / ((MII_SPEED + 1) x 2)

The ref_freq here is the fec internal module clock, which is missing
from clk-vf610 clock driver right now.  And clk-vf610 driver mistakenly
supplies RMII clock (50 MHz) as the source to fec.  This results in the
situation that fec driver gets ref_freq as 50 MHz, while physically it
runs at 66 MHz (fec module clock physically sources from ipg which runs
at 66 MHz).  That's why software expects MDC runs at 2.5 MHz, while the
measurement tells it runs at 3.3 MHz.  And this causes the PHY KSZ8041
keeps swithing between Full and Half mode as below.

  libphy: 400d0000.etherne:00 - Link is Up - 100/Full
  libphy: 400d0000.etherne:00 - Link is Up - 100/Half
  libphy: 400d0000.etherne:00 - Link is Up - 100/Full
  libphy: 400d0000.etherne:00 - Link is Up - 100/Half
  libphy: 400d0000.etherne:00 - Link is Up - 100/Full
  libphy: 400d0000.etherne:00 - Link is Up - 100/Half

Add the missing module clock for ENET0 and ENET1, and correct the clock
supplying in device tree to fix above issue.

Thanks to Alison Wang <b18965 at freescale.com> for debugging the issue.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/vf610.dtsi            |    8 ++++----
 arch/arm/mach-imx/clk-vf610.c           |    2 ++
 include/dt-bindings/clock/vf610-clock.h |    4 +++-
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index e1eb7da..67d929c 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -442,8 +442,8 @@
 				compatible = "fsl,mvf600-fec";
 				reg = <0x400d0000 0x1000>;
 				interrupts = <0 78 0x04>;
-				clocks = <&clks VF610_CLK_ENET>,
-					<&clks VF610_CLK_ENET>,
+				clocks = <&clks VF610_CLK_ENET0>,
+					<&clks VF610_CLK_ENET0>,
 					<&clks VF610_CLK_ENET>;
 				clock-names = "ipg", "ahb", "ptp";
 				status = "disabled";
@@ -453,8 +453,8 @@
 				compatible = "fsl,mvf600-fec";
 				reg = <0x400d1000 0x1000>;
 				interrupts = <0 79 0x04>;
-				clocks = <&clks VF610_CLK_ENET>,
-					<&clks VF610_CLK_ENET>,
+				clocks = <&clks VF610_CLK_ENET1>,
+					<&clks VF610_CLK_ENET1>,
 					<&clks VF610_CLK_ENET>;
 				clock-names = "ipg", "ahb", "ptp";
 				status = "disabled";
diff --git a/arch/arm/mach-imx/clk-vf610.c b/arch/arm/mach-imx/clk-vf610.c
index d617c0b..b169a39 100644
--- a/arch/arm/mach-imx/clk-vf610.c
+++ b/arch/arm/mach-imx/clk-vf610.c
@@ -183,6 +183,8 @@ static void __init vf610_clocks_init(struct device_node *ccm_node)
 	clk[VF610_CLK_ENET_TS_SEL] = imx_clk_mux("enet_ts_sel", CCM_CSCMR2, 0, 3, enet_ts_sels, 7);
 	clk[VF610_CLK_ENET] = imx_clk_gate("enet", "enet_sel", CCM_CSCDR1, 24);
 	clk[VF610_CLK_ENET_TS] = imx_clk_gate("enet_ts", "enet_ts_sel", CCM_CSCDR1, 23);
+	clk[VF610_CLK_ENET0] = imx_clk_gate2("enet0", "ipg_bus", CCM_CCGR9, CCM_CCGRx_CGn(0));
+	clk[VF610_CLK_ENET1] = imx_clk_gate2("enet1", "ipg_bus", CCM_CCGR9, CCM_CCGRx_CGn(1));
 
 	clk[VF610_CLK_PIT] = imx_clk_gate2("pit", "ipg_bus", CCM_CCGR1, CCM_CCGRx_CGn(7));
 
diff --git a/include/dt-bindings/clock/vf610-clock.h b/include/dt-bindings/clock/vf610-clock.h
index 15e997f..4aa2b48 100644
--- a/include/dt-bindings/clock/vf610-clock.h
+++ b/include/dt-bindings/clock/vf610-clock.h
@@ -158,6 +158,8 @@
 #define VF610_CLK_GPU_SEL		145
 #define VF610_CLK_GPU_EN		146
 #define VF610_CLK_GPU2D			147
-#define VF610_CLK_END			148
+#define VF610_CLK_ENET0			148
+#define VF610_CLK_ENET1			149
+#define VF610_CLK_END			150
 
 #endif /* __DT_BINDINGS_CLOCK_VF610_H */
-- 
1.7.9.5




From ldewangan at nvidia.com  Wed Jul 10 03:00:43 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 10 Jul 2013 12:30:43 +0530
Subject: [PATCH V3] ARM: tegra: enable gpio-keys on dalmore
Message-ID: <1373439643-16633-1-git-send-email-ldewangan@nvidia.com>

Dalmore have the keys mounted on board which are connected
to different pins of Tegra.

Add the keys entry in DTS file to enable key functionality.
This will enable KEY_POWER, KEY_HOME, KEY_VOLUMEUP and
KEY_VOLUMEDOWN.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
Changes from V1:
- Reorder the nodes

Changes from V2:
- Remove unwanted line insertion.
- Rename VolumeUP/Volume down lables.

 arch/arm/boot/dts/tegra114-dalmore.dts |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index cb640eb..a42bfa4 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -883,6 +883,35 @@
 		};
 	};
 
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		home {
+			label = "Home";
+			gpios = <&gpio TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
+			linux,code = <102>; /* KEY_HOME */
+		};
+
+		power {
+			label = "Power";
+			gpios = <&gpio TEGRA_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
+			linux,code = <116>; /* KEY_POWER */
+			gpio-key,wakeup;
+		};
+
+		volume_down {
+			label = "Volume Down";
+			gpios = <&gpio TEGRA_GPIO(R, 1) GPIO_ACTIVE_LOW>;
+			linux,code = <114>; /* KEY_VOLUMEDOWN */
+		};
+
+		volume_up {
+			label = "Volume Up";
+			gpios = <&gpio TEGRA_GPIO(R, 2) GPIO_ACTIVE_LOW>;
+			linux,code = <115>; /* KEY_VOLUMEUP */
+		};
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
-- 
1.7.1.1



From ldewangan at nvidia.com  Wed Jul 10 03:03:51 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 10 Jul 2013 12:33:51 +0530
Subject: [PATCH V2] ARM: tegra: enable gpio-keys on dalmore
In-Reply-To: <20130709060447.GA17499@mithrandir>
References: <1373102069-5641-1-git-send-email-ldewangan@nvidia.com>
 <20130709060447.GA17499@mithrandir>
Message-ID: <51DD0757.8060406@nvidia.com>

On Tuesday 09 July 2013 11:34 AM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Sat, Jul 06, 2013 at 02:44:29PM +0530, Laxman Dewangan wrote:
>> D
>> +
>> +		home {
>> +			label = "Home";
>> +			gpios = <&gpio TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
>> +			linux,code = <102>; /* KEY_HOME */
> I wonder if these should maybe go into a header file as well so that
> symbolic names can be used. That'll make the value self-descriptive and
> allow the comment to be dropped.
>
Currently there is no header for input.h in dt-binding include. We need 
to add them first and then use it.
Probably it can be done along with all cleanups on dts file atleast for 
Tegra.
I can start this if no one faster than me for this activity but for this 
patch, I like to go on legacy way.



From shawn.guo at linaro.org  Wed Jul 10 03:09:17 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 10 Jul 2013 15:09:17 +0800
Subject: [PATCH] ARM: dts: imx: add tempmon node for imx6q thermal support
In-Reply-To: <51DC256D.6040204@denx.de>
References: <1370330008-5982-1-git-send-email-shawn.guo@linaro.org>
 <1370330226-6030-1-git-send-email-shawn.guo@linaro.org>
 <51DC256D.6040204@denx.de>
Message-ID: <20130710070915.GA12605@S2101-09.ap.freescale.net>

Hi Stefano,

On Tue, Jul 09, 2013 at 04:59:57PM +0200, Stefano Babic wrote:
> > -			ocotp at 021bc000 {
> > -				compatible = "fsl,imx6q-ocotp";
> > +			ocotp: ocotp at 021bc000 {
> > +				compatible = "fsl,imx6q-ocotp", "syscon";
> >  				reg = <0x021bc000 0x4000>;
> 
> Sorry to check this very late - is ocotp at 021bc000 the right address for
> the thermal data ? According to User Manual (Table 62.3), the start
> address is 0x20C8180. Using your patch, by loading the driver I get :

Address 0x20C8180 is where TEMPMON control registers are - they are
embedded in ANATOP block, while calibration data is stored in OCOTP fuse
block.

> imx_thermal tempmon.7: invalid sensor calibration data
> imx_thermal tempmon.7: failed to get sensor data
> imx_thermal: probe of tempmon.7 failed with error -22

What's your chip revision?  Early revisions may not have the calibration
data.  TO1.2 should have, I think.

> The driver is loaded successfully if I changed the tempdata to point to
> 020C8180. Not sure if I get the right values from temp1_crit and
> temp1_input, but no error at the initialisation. Am I missing something ?

It reads some data but that's not calibration data, so it should not work.

Also, you need a cpu_cooling fix [1], if you want to play the thermal
patches on imx6q.

Shawn

[1] http://thread.gmane.org/gmane.linux.power-management.general/34389



From oleksandr.kozaruk at ti.com  Wed Jul 10 03:08:53 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Wed, 10 Jul 2013 10:08:53 +0300
Subject: [PATCH v2 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <1373440134-30118-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1373440134-30118-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1373440134-30118-2-git-send-email-oleksandr.kozaruk@ti.com>

GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.

Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 arch/arm/boot/dts/twl6030.dtsi |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..434842c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
 		compatible = "ti,twl6030-pwmled";
 		#pwm-cells = <2>;
 	};
+
+	gpadc: twl6030_gpadc {
+		compatible = "ti,twl6030_gpadc";
+		interrupts = <3>;
+		#io-channel-cells = <1>;
+	};
 };
-- 
1.7.9.5



From oleksandr.kozaruk at ti.com  Wed Jul 10 03:08:52 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Wed, 10 Jul 2013 10:08:52 +0300
Subject: [PATCH v2 0/2] TWL6030, TWL6032 GPADC driver
Message-ID: <1373440134-30118-1-git-send-email-oleksandr.kozaruk@ti.com>

Hello,

This is version 2 - the driver put in drivers/iio, and
converted using iio facilities as suggested by Graeme.

TWL603[02] GPADC is used to measure battery voltage,
battery temperature, battery presence ID, and could
be used to measure twl603[02] die temperature.
This is used on TI blaze, blaze tablet platforms.

The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19
channels respectively. Some channels have current
source and are used for measuring voltage drop
on resistive load for detecting battery ID resistance,
or measuring voltage drop on NTC resistors for external
temperature measurements, other channels measure voltage,
(i.e. battery voltage), and have inbuilt voltage dividers,
thus, capable to scale voltage. Some channels are dedicated
for measuring die temperature.

Some channels could be calibrated in 2 points, having
offsets from ideal values in trim registers.

The difference between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i. e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

The driver exports function returning converted value for
requested channels.

Sysfs entries are added to start and read conversion result
in millivolts for chosen channel.

The driver is derived from git://git.omapzoom.org/kernel/omap.git
The original driver's authors and contributors are Balaji T K,
Graeme Gregory, Ambresh K, Girish S Ghongdemath.

The changes to the original driver:
- device tree adaptation;
- drop ioctl support - never been used;
- unified measurement method for both devices;
- get rid of "if (device == X)" code style to data driven;
- drop polling end of conversion and use interrupt instead;
- iio framework is used

Tested with on blaze tablet 2 with OMAP4430(twl6030), and
OMAP4470(twl6032) SOMs.

The patches were tested against 3.10-rc7

Oleksandr Kozaruk (2):
  ARM: dts: twl: Add GPADC data to device tree
  iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

 arch/arm/boot/dts/twl6030.dtsi  |    6 +
 drivers/iio/adc/Kconfig         |    8 +
 drivers/iio/adc/Makefile        |    1 +
 drivers/iio/adc/twl6030-gpadc.c | 1019 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 1034 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

-- 
1.7.9.5



From oleksandr.kozaruk at ti.com  Wed Jul 10 03:08:54 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Wed, 10 Jul 2013 10:08:54 +0300
Subject: [PATCH v2 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <1373440134-30118-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1373440134-30118-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1373440134-30118-3-git-send-email-oleksandr.kozaruk@ti.com>

The GPADC is general purpose ADC found on TWL6030,
and TWL6032 PMIC, known also as Phoenix and PhoenixLite.

The TWL6030 and TWL6032 have GPADC with 17 and 19
channels respectively. Some channels have current
source and are used for measuring voltage drop
on resistive load for detecting battery ID resistance,
or measuring voltage drop on NTC resistors for external
temperature measurements. Some channels measure voltage,
(i.e. battery voltage), and have voltage dividers,
thus, capable to scale voltage. Some channels are dedicated
for measuring die temperature.

Some channels are calibrated in 2 points, having
offsets from ideal values kept in trim registers. This
is used to correct measurements.

The differences between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i. e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

The driver exports function returning converted value for
requested channels.

Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
Girish S Ghongdemath.

Signed-off-by: Balaji T K <balajitk at ti.com>
Graeme Gregory <gg at slimlogic.co.uk>
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 drivers/iio/adc/Kconfig         |    8 +
 drivers/iio/adc/Makefile        |    1 +
 drivers/iio/adc/twl6030-gpadc.c | 1019 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 1028 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index ab0767e6..87d699e 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -157,4 +157,12 @@ config VIPERBOARD_ADC
 	  Say yes here to access the ADC part of the Nano River
 	  Technologies Viperboard.
 
+config TWL6030_GPADC
+	tristate "TWL6030 GPADC (General Purpose A/D Convertor) Support"
+	depends on TWL4030_CORE
+	default n
+	help
+	  Say yes here if you want support for the TWL6030 General Purpose
+	  A/D Convertor.
+
 endmenu
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 0a825be..8b05633 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
 obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
 obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
+obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
new file mode 100644
index 0000000..d9529a9
--- /dev/null
+++ b/drivers/iio/adc/twl6030-gpadc.c
@@ -0,0 +1,1019 @@
+/*
+ * TWL6030 GPADC module driver
+ *
+ * Copyright (C) 2009-2013 Texas Instruments Inc.
+ * Nishant Kamat <nskamat at ti.com>
+ * Balaji T K <balajitk at ti.com>
+ * Graeme Gregory <gg at slimlogic.co.uk>
+ * Girish S Ghongdemath <girishsg at ti.com>
+ * Ambresh K <ambresh at ti.com>
+ * Oleksandr Kozaruk <oleksandr.kozaruk at ti.com
+ *
+ * Based on twl4030-madc.c
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen <mikko.k.ylinen at nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of_platform.h>
+#include <linux/i2c/twl.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define DRIVER_NAME		"twl6030_gpadc"
+
+#define TWL6030_GPADC_MAX_CHANNELS 17
+#define TWL6032_GPADC_MAX_CHANNELS 19
+/* Define this as the biggest of all chips using this driver */
+#define GPADC_MAX_CHANNELS TWL6032_GPADC_MAX_CHANNELS
+
+#define TWL6030_GPADC_CTRL			0x00    /* 0x2e */
+#define TWL6030_GPADC_CTRL2			0x01	/* 0x2f */
+
+#define TWL6030_GPADC_CTRL_P1			0x05
+#define TWL6030_GPADC_CTRL_P2			0x06
+
+#define TWL6032_GPADC_GPSELECT_ISB		0x07
+#define TWL6032_GPADC_CTRL_P1			0x08
+
+#define TWL6032_GPADC_RTCH0_LSB			0x09
+#define TWL6032_GPADC_RTCH0_MSB			0x0a
+#define TWL6032_GPADC_RTCH1_LSB			0x0b
+#define TWL6032_GPADC_RTCH1_MSB			0x0c
+#define TWL6032_GPADC_GPCH0_LSB			0x0d
+#define TWL6032_GPADC_GPCH0_MSB			0x0e
+
+#define TWL6030_GPADC_CTRL_P1_SP1		BIT(3)
+#define TWL6030_GPADC_CTRL_P1_EOCRT		BIT(2)
+#define TWL6030_GPADC_CTRL_P1_EOCP1		BIT(1)
+#define TWL6030_GPADC_CTRL_P1_BUSY		BIT(0)
+
+#define TWL6030_GPADC_CTRL_P2_SP2		BIT(2)
+#define TWL6030_GPADC_CTRL_P2_EOCP2		BIT(1)
+#define TWL6030_GPADC_CTRL_P1_BUSY		BIT(0)
+
+#define TWL6030_GPADC_EOC_SW			BIT(1)
+#define TWL6030_GPADC_BUSY			BIT(0)
+
+#define TWL6030_GPADC_RTCH0_LSB			(0x07)
+#define TWL6030_GPADC_GPCH0_LSB			(0x29)
+
+/* Fixed channels */
+#define TWL6030_GPADC_CTRL_TEMP1_EN		BIT(0)    /* input ch 1 */
+#define TWL6030_GPADC_CTRL_TEMP2_EN		BIT(1)    /* input ch 4 */
+#define TWL6030_GPADC_CTRL_SCALER_EN		BIT(2)    /* input ch 2 */
+#define TWL6030_GPADC_CTRL_SCALER_DIV4		BIT(3)
+#define TWL6030_GPADC_CTRL_SCALER_EN_CH11	BIT(4)    /* input ch 11 */
+#define TWL6030_GPADC_CTRL_TEMP1_EN_MONITOR	BIT(5)
+#define TWL6030_GPADC_CTRL_TEMP2_EN_MONITOR	BIT(6)
+#define TWL6030_GPADC_CTRL_ISOURCE_EN		BIT(7)
+
+#define TWL6030_GPADC_CTRL2_REMSENSE_0		BIT(0)
+#define TWL6030_GPADC_CTRL2_REMSENSE_1		BIT(1)
+#define TWL6030_GPADC_CTRL2_SCALER_EN_CH18	BIT(2)
+#define TWL6030_GPADC_CTRL2_VBAT_SCALER_DIV4	BIT(3)
+
+#define TWL6030_GPADC_RT_SW1_EOC_MASK		BIT(5)
+#define TWL6030_GPADC_SW2_EOC_MASK		BIT(6)
+
+#define TWL6032_GPADC_RT_EOC_MASK		BIT(4)
+#define TWL6032_GPADC_SW_EOC_MASK		BIT(5)
+
+#define TWL6030_GPADC_TRIM1			0xCD
+
+#define TWL6030_REG_TOGGLE1			0x90
+#define TWL6030_GPADCS				BIT(1)
+#define TWL6030_GPADCR				BIT(0)
+
+/**
+ * struct twl6030_chnl_calib - channel calibration
+ * @gain:		slope coefficient for ideal curve
+ * @gain_error:		gain error
+ * @offset_error:	offset of the real curve
+ */
+struct twl6030_chnl_calib {
+	s32 gain;
+	s32 gain_error;
+	s32 offset_error;
+};
+
+/**
+ * struct twl6030_ideal_code - GPADC calibration parameters
+ * GPADC is calibrated in two points: close to the beginning and
+ * to the and of the measurable input range
+ *
+ * @code1:	ideal code for the input at the beginning
+ * @code2:	ideal code for at the end of the range
+ * @v1:		voltage input at the beginning(low voltage)
+ * @v2:		voltage input at the end(high voltage)
+ */
+struct twl6030_ideal_code {
+	u16 code1;
+	u16 code2;
+	u16 v1;
+	u16 v2;
+};
+
+struct twl6030_gpadc_data;
+
+/**
+ * struct twl6030_gpadc_platform_data - platform specific data
+ * @nchannels:		number of GPADC channels
+ * @iio_channels:	iio channels
+ * @twl6030_ideal:	pointer to calibration parameters
+ * @start_conversion:	pointer to ADC start conversion function
+ * @channel_to_reg	pointer to ADC function to convert channel to
+ * 			register address for reading conversion result
+ * @calibrate:		pointer to calibration function
+ */
+struct twl6030_gpadc_platform_data {
+	const int nchannels;
+	const struct iio_chan_spec *iio_channels;
+	const struct twl6030_ideal_code *ideal;
+	int (*start_conversion)(int channel);
+	u8 (*channel_to_reg)(int channel);
+	int (*calibrate)(struct twl6030_gpadc_data *gpadc);
+};
+
+/**
+ * struct twl6030_gpadc_data - GPADC data
+ * @dev:		device pointer
+ * @lock:		mutual exclusion lock for the structure
+ * @irq_complete:	completion to signal end of conversion
+ * @twl6030_cal_tbl:	pointer to calibration data for each
+ * 			channel with gain error and offset
+ * @pdata:		pointer to device specific data
+ */
+struct twl6030_gpadc_data {
+	struct device	*dev;
+	struct mutex	lock;
+	struct completion	irq_complete;
+	struct twl6030_chnl_calib	*twl6030_cal_tbl;
+	const struct twl6030_gpadc_platform_data *pdata;
+};
+
+/*
+ * channels 11, 12, 13, 15 and 16 have no calibration data
+ * calibration offset is same for channels 1, 3, 4, 5
+ *
+ * The data is taken from GPADC_TRIM registers description.
+ * GPADC_TRIM registers keeps difference between the code measured
+ * at v1 and v2 input voltages and corresponding code1 and code2
+ */
+static const struct twl6030_ideal_code
+	twl6030_ideal[TWL6030_GPADC_MAX_CHANNELS] = {
+	{ /* ch 0, external, battery type, resistor value */
+		.code1 = 116,
+		.code2 = 745,
+		.v1 = 141,
+		.v2 = 910,
+	},
+	{ /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 82,
+		.code2 = 900,
+		.v1 = 100,
+		.v2 = 1100,
+	},
+	{ /* ch 2, external, audio accessory/general purpose */
+		.code1 = 55,
+		.code2 = 818,
+		.v1 = 101,
+		.v2 = 1499,
+	},
+	{ /* ch 3, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.v1 = 100,
+		.v2 = 1100,
+	},
+	{ /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.v1 = 100,
+		.v2 = 1100,
+	},
+	{ /* ch 5, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.v1 = 100,
+		.v2 = 1100,
+	},
+	{ /* ch 6, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.v1 = 100,
+		.v2 = 1100,
+	},
+	{ /* ch 7, internal, main battery */
+		.code1 = 614,
+		.code2 = 941,
+		.v1 = 3001,
+		.v2 = 4599,
+	},
+	{ /* ch 8, internal, backup battery */
+		.code1 = 82,
+		.code2 = 688,
+		.v1 = 501,
+		.v2 = 4203,
+	},
+	{ /* ch 9, internal, external charger input */
+		.code1 = 182,
+		.code2 = 818,
+		.v1 = 2001,
+		.v2 = 8996,
+	},
+	{ /* ch 10, internal, VBUS */
+		.code1 = 149,
+		.code2 = 818,
+		.v1 = 1001,
+		.v2 = 5497,
+	},
+	{},	/* ch 11, internal, VBUS charging current */
+	{},	/* ch 12, internal, Die temperature */
+	{},	/* ch 13, internal, Die temperature */
+	{ /* ch 14, internal, USB ID line */
+		.code1 = 48,
+		.code2 = 714,
+		.v1 = 323,
+		.v2 = 4800,
+	},
+	{},	/* ch 15, internal, test network */
+	{},	/* ch 16, internal, test network */
+};
+
+static const struct twl6030_ideal_code
+			twl6032_ideal[TWL6032_GPADC_MAX_CHANNELS] = {
+	{ /* ch 0, external, battery type, resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch 2, external, audio accessory/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 660,
+		.v2 = 1500,
+	},
+	{ /* ch 3, external, temperature with external diode/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch 5, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch 6, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch7, internal, system supply */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 2200,
+		.v2 = 5000,
+	},
+	{ /* ch8, internal, backup battery */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 2200,
+		.v2 = 5000,
+	},
+	{ /* ch 9, internal, external charger input */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 3960,
+		.v2 = 9000,
+	},
+	{ /* ch10, internal, VBUS */
+		.code1 = 150,
+		.code2 = 751,
+		.v1 = 1000,
+		.v2 = 5000,
+	},
+	{ /* ch 11, internal, VBUS DC-DC output current */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 660,
+		.v2 = 1500,
+	},
+	{ /* ch 12, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch 13, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch 14, internal, USB ID line */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 2420,
+		.v2 = 5500,
+	},
+	{},	/* ch 15, internal, test network */
+	{},	/* ch 16, internal, test network */
+	{},	/* ch 17, internal, battery charging current */
+	{ /* ch 18, internal, battery voltage */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 2200,
+		.v2 = 5000,
+	},
+};
+
+static inline int twl6030_gpadc_write(u8 reg, u8 val)
+{
+	return twl_i2c_write_u8(TWL6030_MODULE_GPADC, val, reg);
+}
+
+static inline int twl6030_gpadc_read(u8 *val, u8 reg)
+{
+
+	return twl_i2c_read(TWL6030_MODULE_GPADC, val, reg, 2);
+}
+
+static int twl6030_gpadc_enable_irq(u8 mask)
+{
+	int ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_LINE_B);
+	ret |= twl6030_interrupt_unmask(mask, REG_INT_MSK_STS_B);
+
+	return ret;
+}
+
+static void twl6030_gpadc_disable_irq(u8 mask)
+{
+	twl6030_interrupt_mask(mask, REG_INT_MSK_LINE_B);
+	twl6030_interrupt_mask(mask, REG_INT_MSK_STS_B);
+}
+
+static irqreturn_t twl6030_gpadc_irq_handler(int irq, void *_gpadc)
+{
+	struct twl6030_gpadc_data *gpadc = _gpadc;
+
+	complete(&gpadc->irq_complete);
+
+	return IRQ_HANDLED;
+}
+
+static int twl6030_start_conversion(int channel)
+{
+	return twl6030_gpadc_write(TWL6030_GPADC_CTRL_P1,
+					TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static int twl6032_start_conversion(int channel)
+{
+	int ret;
+
+	ret = twl6030_gpadc_write(TWL6032_GPADC_GPSELECT_ISB, channel);
+	if (ret)
+		return ret;
+
+	return twl6030_gpadc_write(TWL6032_GPADC_CTRL_P1,
+						TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static u8 twl6030_channel_to_reg(int channel)
+{
+	return TWL6030_GPADC_GPCH0_LSB + 2 * channel;
+}
+
+static u8 twl6032_channel_to_reg(int channel)
+{
+	return TWL6032_GPADC_GPCH0_LSB;
+}
+
+static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
+		int channel, int *res)
+{
+	u8 reg = gpadc->pdata->channel_to_reg(channel);
+	u8 val[2];
+	int ret;
+
+	ret = twl6030_gpadc_read(val, reg);
+	if (ret) {
+		dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
+		return ret;
+	}
+
+	*res = (val[1] << 8) | val[0];
+
+	return ret;
+}
+
+static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
+		int channel, int *val)
+{
+	int raw_code;
+	int corrected_code;
+	int channel_value;
+	int ret;
+
+	ret = twl6030_gpadc_get_raw(gpadc, channel, &raw_code);
+	if (ret)
+		return ret;
+
+	corrected_code = ((raw_code * 1000) -
+		gpadc->twl6030_cal_tbl[channel].offset_error) /
+		gpadc->twl6030_cal_tbl[channel].gain_error;
+
+	channel_value = corrected_code *
+			gpadc->twl6030_cal_tbl[channel].gain;
+
+	/* Shift back into mV range */
+	channel_value /= 1000;
+
+	dev_dbg(gpadc->dev, "GPADC raw: %d", raw_code);
+	dev_dbg(gpadc->dev, "GPADC cor: %d", corrected_code);
+	dev_dbg(gpadc->dev, "GPADC val: %d", channel_value);
+
+	*val = channel_value;
+
+	return ret;
+}
+
+static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
+			     const struct iio_chan_spec *chan,
+			     int *val, int *val2, long mask)
+{
+	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
+	int ret = -EINVAL;
+
+	mutex_lock(&gpadc->lock);
+
+	ret = gpadc->pdata->start_conversion(chan->channel);
+	if (ret) {
+		dev_err(gpadc->dev, "failed to start conversion\n", __func__);
+		goto err;
+	}
+	/* wait for conversion to complete */
+	wait_for_completion_interruptible_timeout(&gpadc->irq_complete,
+						msecs_to_jiffies(5000));
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	case IIO_CHAN_INFO_PROCESSED:
+		ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	default:
+		break;
+	}
+err:
+	mutex_unlock(&gpadc->lock);
+
+	return ret;
+}
+
+static void twl6030_calibrate_channel(struct twl6030_gpadc_data *gpadc,
+					int channel, int d1, int d2)
+{
+	int b, k, gain, x1, x2;
+	const struct twl6030_ideal_code *ideal = gpadc->pdata->ideal;
+
+	/* Gain */
+	gain = ((ideal[channel].v2 - ideal[channel].v1) * 1000) /
+		(ideal[channel].code2 - ideal[channel].code1);
+
+	x1 = ideal[channel].code1;
+	x2 = ideal[channel].code2;
+
+	/* k */
+	k = 1000 + (((d2 - d1) * 1000) / (x2 - x1));
+
+	/* b */
+	b = (d1 * 1000) - (k - 1000) * x1;
+
+	gpadc->twl6030_cal_tbl[channel].gain = gain;
+	gpadc->twl6030_cal_tbl[channel].gain_error = k;
+	gpadc->twl6030_cal_tbl[channel].offset_error = b;
+
+	dev_dbg(gpadc->dev, "GPADC d1   for Chn: %d = %d\n", channel, d1);
+	dev_dbg(gpadc->dev, "GPADC d2   for Chn: %d = %d\n", channel, d2);
+	dev_dbg(gpadc->dev, "GPADC x1   for Chn: %d = %d\n", channel, x1);
+	dev_dbg(gpadc->dev, "GPADC x2   for Chn: %d = %d\n", channel, x2);
+	dev_dbg(gpadc->dev, "GPADC Gain for Chn: %d = %d\n", channel, gain);
+	dev_dbg(gpadc->dev, "GPADC k    for Chn: %d = %d\n", channel, k);
+	dev_dbg(gpadc->dev, "GPADC b    for Chn: %d = %d\n", channel, b);
+}
+
+static inline int twl6030_gpadc_get_trim_offset(s8 d)
+{
+	int sign;
+
+	/*
+	 * XXX NOTE!
+	 * bit 0 - sign, bit 7 - reserved, 6..1 - trim value
+	 * though, the documentation states that trim value
+	 * is absolute value, the correct conversion results are
+	 * obtained if the value is interpreted as 2's complement.
+	 */
+	sign = d & 1;
+	d = (d & 0x7f) >> 1;
+
+	return sign ? (d | 0xc0) : d;
+}
+
+static int twl6030_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int ret;
+	int chn;
+	u8 trim_regs[TWL6030_GPADC_MAX_CHANNELS];
+	s8 d1, d2;
+
+	/*
+	 * for calibration two measurements have been performed at
+	 * factory, for some channels, during the production test and
+	 * have been stored in registers. This two stored values are
+	 * used to correct the measurements. The values represent
+	 * offsets for the given input from the output on ideal curve.
+	 */
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs,
+			TWL6030_GPADC_TRIM1, 16);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	for (chn = 0; chn < TWL6030_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+			d1 = trim_regs[0];
+			d2 = trim_regs[1];
+			break;
+		case 1:
+			d1 = trim_regs[4];
+			d2 = trim_regs[5];
+			break;
+		case 2:
+			d1 = trim_regs[12];
+			d2 = trim_regs[13];
+			break;
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+			d1 = trim_regs[4];
+			d2 = trim_regs[5];
+			break;
+		case 7:
+			d1 = trim_regs[6];
+			d2 = trim_regs[7];
+			break;
+		case 8:
+			d1 = trim_regs[2];
+			d2 = trim_regs[3];
+			break;
+		case 9:
+			d1 = trim_regs[8];
+			d2 = trim_regs[9];
+			break;
+		case 10:
+			d1 = trim_regs[10];
+			d2 = trim_regs[11];
+			break;
+		case 14:
+			d1 = trim_regs[14];
+			d2 = trim_regs[15];
+			break;
+		default:
+			continue;
+		}
+
+		d1 = twl6030_gpadc_get_trim_offset(d1);
+		d2 = twl6030_gpadc_get_trim_offset(d2);
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int chn, d1 = 0, d2 = 0, temp;
+	u8 trim_regs[17];
+	int ret;
+
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
+			TWL6030_GPADC_TRIM1, 16);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	/* Loop to calculate the value needed for returning voltages from
+	 * GPADC not values.
+	 *
+	 * gain is calculated to 3 decimal places fixed point.
+	 */
+	for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+		case 1:
+		case 2:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+		case 11:
+		case 12:
+		case 13:
+		case 14:
+			/* D1 */
+			d1 = (trim_regs[3] & 0x1F) << 2;
+			d1 |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				d1 = -d1;
+
+			/* D2 */
+			d2 = (trim_regs[4] & 0x3F) << 2;
+			d2 |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				d2 = -d2;
+			break;
+		case 8:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[8] & 0x18) << 1;
+			d1 |= (trim_regs[7] & 0x1E) >> 1;
+			if (trim_regs[7] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[10] & 0x1F) << 2;
+			d2 |= (trim_regs[8] & 0x06) >> 1;
+			if (trim_regs[8] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		case 9:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[14] & 0x18) << 1;
+			d1 |= (trim_regs[12] & 0x1E) >> 1;
+			if (trim_regs[12] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[16] & 0x1F) << 2;
+			d2 |= (trim_regs[14] & 0x06) >> 1;
+			if (trim_regs[14] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+		case 10:
+			/* D1 */
+			d1 = (trim_regs[11] & 0x0F) << 3;
+			d1 |= (trim_regs[9] & 0x0E) >> 1;
+			if (trim_regs[9] & 0x01)
+				d1 = -d1;
+
+			/* D2 */
+			d2 = (trim_regs[15] & 0x0F) << 3;
+			d2 |= (trim_regs[13] & 0x0E) >> 1;
+			if (trim_regs[13] & 0x01)
+				d2 = -d2;
+			break;
+		case 7:
+		case 18:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[5] & 0x7E) >> 1;
+			if (trim_regs[5] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[6] & 0xFE) >> 1;
+			if (trim_regs[6] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		default:
+			/* No data for other channels */
+			continue;
+		}
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+#define TWL6030_GPADC_CHAN(chn, chan_info) {		\
+	.type = IIO_VOLTAGE,				\
+	.channel = chn,					\
+	.scan_type = {					\
+		.sign = 'u',				\
+		.storagebits = 16,			\
+	},						\
+	.info_mask = BIT(chan_info),			\
+	.info_mask_separate = BIT(chan_info), 		\
+	.indexed = 1,					\
+}
+
+static const struct iio_chan_spec twl6030_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(2, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(5, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(12, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(13, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(14, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(15, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(16, IIO_CHAN_INFO_RAW),
+};
+
+static const struct iio_chan_spec twl6032_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(2, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(5, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(12, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(13, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(14, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(15, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(16, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(17, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(18, IIO_CHAN_INFO_PROCESSED),
+};
+
+static const struct iio_info twl6030_gpadc_iio_info = {
+	.read_raw = &twl6030_gpadc_read_raw,
+	.driver_module = THIS_MODULE,
+};
+
+static const struct twl6030_gpadc_platform_data twl6030_pdata = {
+	.iio_channels = twl6030_gpadc_iio_channels,
+	.nchannels = TWL6030_GPADC_MAX_CHANNELS,
+	.ideal = twl6030_ideal,
+	.start_conversion = twl6030_start_conversion,
+	.channel_to_reg = twl6030_channel_to_reg,
+	.calibrate = twl6030_calibration,
+};
+
+static const struct twl6030_gpadc_platform_data twl6032_pdata = {
+	.iio_channels = twl6032_gpadc_iio_channels,
+	.nchannels = TWL6032_GPADC_MAX_CHANNELS,
+	.ideal = twl6032_ideal,
+	.start_conversion = twl6032_start_conversion,
+	.channel_to_reg = twl6032_channel_to_reg,
+	.calibrate = twl6032_calibration,
+};
+
+static const struct of_device_id of_twl6030_match_tbl[] = {
+	{
+		.compatible = "ti,twl6030_gpadc",
+		.data = &twl6030_pdata,
+	},
+	{
+		.compatible = "ti,twl6032_gpadc",
+		.data = &twl6032_pdata,
+	},
+	{ /* end */ }
+};
+
+static int twl6030_gpadc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct twl6030_gpadc_data *gpadc;
+	const struct twl6030_gpadc_platform_data *pdata;
+	const struct of_device_id *match;
+	struct iio_dev *indio_dev;
+	int irq;
+	int ret = 0;
+
+	match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
+	pdata = match ? match->data : dev->platform_data;
+
+	if (!pdata)
+		return -EINVAL;
+
+	indio_dev = iio_device_alloc(sizeof(struct twl6030_gpadc_data));
+	if (!indio_dev) {
+		dev_err(dev, "failed allocating iio device\n");
+		ret = -ENOMEM;
+	}
+
+	gpadc = iio_priv(indio_dev);
+
+	gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
+					sizeof(struct twl6030_chnl_calib) *
+					pdata->nchannels, GFP_KERNEL);
+	if (!gpadc->twl6030_cal_tbl)
+		goto err;
+
+	gpadc->dev = dev;
+	gpadc->pdata = pdata;
+
+	platform_set_drvdata(pdev, indio_dev);
+	mutex_init(&gpadc->lock);
+	init_completion(&gpadc->irq_complete);
+
+	ret = pdata->calibrate(gpadc);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to read calibration registers\n");
+		goto err;
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "failed to get irq\n");
+		goto err;
+	}
+
+	ret = devm_request_threaded_irq(dev, irq, NULL,
+					twl6030_gpadc_irq_handler,
+					IRQF_ONESHOT, "twl6030_gpadc", gpadc);
+	if (ret) {
+		dev_dbg(&pdev->dev, "could not request irq\n");
+		goto err;
+	}
+
+	ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
+		goto err;
+	}
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+					TWL6030_REG_TOGGLE1);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC module\n");
+		goto err;
+	}
+
+	indio_dev->name = DRIVER_NAME;
+	indio_dev->dev.parent = dev;
+	indio_dev->info = &twl6030_gpadc_iio_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->channels = pdata->iio_channels;
+	indio_dev->num_channels = pdata->nchannels;
+
+	ret = iio_device_register(indio_dev);
+	if (ret)
+		goto err;
+
+	return ret;
+err:
+	iio_device_free(indio_dev);
+	return ret;
+}
+
+static int twl6030_gpadc_remove(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+
+	twl6030_gpadc_disable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	iio_device_unregister(indio_dev);
+	iio_device_free(indio_dev);
+
+	return 0;
+}
+
+static int twl6030_gpadc_suspend(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCR,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error reseting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+
+static int twl6030_gpadc_resume(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error setting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+
+static const struct dev_pm_ops twl6030_gpadc_pm_ops = {
+	.suspend = twl6030_gpadc_suspend,
+	.resume = twl6030_gpadc_resume,
+};
+
+static struct platform_driver twl6030_gpadc_driver = {
+	.probe		= twl6030_gpadc_probe,
+	.remove		= twl6030_gpadc_remove,
+	.driver		= {
+		.name	= DRIVER_NAME,
+		.owner	= THIS_MODULE,
+		.pm	= &twl6030_gpadc_pm_ops,
+		.of_match_table = of_twl6030_match_tbl,
+	},
+};
+
+module_platform_driver(twl6030_gpadc_driver);
+
+MODULE_ALIAS("platform: " DRIVER_NAME);
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_DESCRIPTION("twl6030 ADC driver");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5



From zhangwm at marvell.com  Wed Jul 10 03:25:17 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Wed, 10 Jul 2013 00:25:17 -0700
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <20130709124900.GG11908@titan.lakedaemon.net>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
Message-ID: <175CCF5F49938B4D99B2E3EF7F558EBE3DBC97FA8F@SC-VEXCH4.marvell.com>

Jason,

> -----Original Message-----
> From: Jason Cooper [mailto:jason at lakedaemon.net]
> Sent: 2013?7?9? 20:49
> To: Neil Zhang
> Cc: grant.likely at linaro.org; haojian.zhuang at gmail.com; arnd at arndb.de;
> devicetree-discuss at lists.ozlabs.org; linux-kernel at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
>
> Neil,
>
> On Tue, Jul 09, 2013 at 02:42:44PM +0800, Neil Zhang wrote:
> > The documented vendor prefix for Marvell is 'marvell', not 'mrvl', so
> > let's change it.
> >
> > Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> > ---
> >  .../devicetree/bindings/arm/mrvl/intc.txt          |   16 +++---
> >  .../devicetree/bindings/arm/mrvl/mrvl.txt          |    6 +-
> >  .../devicetree/bindings/arm/mrvl/timer.txt         |    4 +-
> >  Documentation/devicetree/bindings/i2c/i2c-pxa.txt  |   14 +++---
> >  .../devicetree/bindings/mmc/sdhci-pxa.txt          |    8 ++--
> >  .../devicetree/bindings/rtc/sa1100-rtc.txt         |    4 +-
> >  .../devicetree/bindings/serial/mrvl-serial.txt     |    2 +-
> >  arch/arm/boot/dts/mmp2-brownstone.dts              |    2 +-
> >  arch/arm/boot/dts/mmp2.dtsi                        |   56
> ++++++++++----------
> >  arch/arm/boot/dts/pxa168-aspenite.dts              |    2 +-
> >  arch/arm/boot/dts/pxa168.dtsi                      |   24
> ++++----
> >  arch/arm/boot/dts/pxa2xx.dtsi                      |   16 +++---
> >  arch/arm/boot/dts/pxa3xx.dtsi                      |    2 +-
> >  arch/arm/boot/dts/pxa910-dkb.dts                   |    2 +-
> >  arch/arm/boot/dts/pxa910.dtsi                      |   27
> +++++-----
> >  arch/arm/mach-mmp/irq.c                            |   16
> +++---
> >  arch/arm/mach-mmp/mmp-dt.c                         |   28
> +++++-----
> >  arch/arm/mach-mmp/mmp2-dt.c                        |   16
> +++---
> >  arch/arm/mach-mmp/time.c                           |    2 +-
> >  arch/arm/mach-pxa/pxa-dt.c                         |   14
> +++---
> >  drivers/i2c/busses/i2c-pxa.c                       |   10 ++--
> >  drivers/mmc/host/sdhci-pxav2.c                     |    4 +-
> >  drivers/mmc/host/sdhci-pxav3.c                     |    4 +-
> >  drivers/rtc/rtc-sa1100.c                           |    4 +-
> >  drivers/tty/serial/pxa.c                           |    4 +-
> >  25 files changed, 144 insertions(+), 143 deletions(-)
>
> I agree with the need to change, however, this has been in the binding
> documentation since v3.5.  I wish we had caught this when we decided
> against using stock ticker symbols (not all stock markets use alphabetical
> abbreviated names, not all companies are listed on any stock exchange).
>
> To do this properly, the drivers are going to have to be compatible with the
> old and the new names, and the binding docs updated to reflect the legacy
> name and the preferred name.
>
Do you mean it's better to support both legacy and preferred name at the same time?

> thx,
>
> Jason.
>
> > diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> > b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> > index 8b53273..ad27548 100644
> > --- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> > +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> > @@ -1,8 +1,8 @@
> >  * Marvell MMP Interrupt controller
> >
> >  Required properties:
> > -- compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or
> > -  "mrvl,mmp2-mux-intc"
> > +- compatible : Should be "marvell,mmp-intc", "marvell,mmp2-intc" or
> > +  "marvell,mmp2-mux-intc"
> >  - reg : Address and length of the register set of the interrupt controller.
> >    If the interrupt controller is intc, address and length means the range
> >    of the whold interrupt controller. If the interrupt controller is
> > mux-intc, @@ -15,28 +15,28 @@ Required properties:
> >  - interrupt-controller : Identifies the node as an interrupt controller.
> >  - #interrupt-cells : Specifies the number of cells needed to encode an
> >    interrupt source.
> > -- mrvl,intc-nr-irqs : Specifies the number of interrupts in the
> > interrupt
> > +- marvell,intc-nr-irqs : Specifies the number of interrupts in the
> > +interrupt
> >    controller.
> > -- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP
> > edge
> > +- marvell,clr-mfp-irq : Specifies the interrupt that needs to clear
> > +MFP edge
> >    detection first.
> >
> >  Example:
> >     intc: interrupt-controller at d4282000 {
> > -           compatible = "mrvl,mmp2-intc";
> > +           compatible = "marvell,mmp2-intc";
> >             interrupt-controller;
> >             #interrupt-cells = <1>;
> >             reg = <0xd4282000 0x1000>;
> > -           mrvl,intc-nr-irqs = <64>;
> > +           marvell,intc-nr-irqs = <64>;
> >     };
> >
> >     intcmux4 at d4282150 {
> > -           compatible = "mrvl,mmp2-mux-intc";
> > +           compatible = "marvell,mmp2-mux-intc";
> >             interrupts = <4>;
> >             interrupt-controller;
> >             #interrupt-cells = <1>;
> >             reg = <0x150 0x4>, <0x168 0x4>;
> >             reg-names = "mux status", "mux mask";
> > -           mrvl,intc-nr-irqs = <2>;
> > +           marvell,intc-nr-irqs = <2>;
> >     };
> >
> >  * Marvell Orion Interrupt controller
> > diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> > b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> > index 117d741..87f1d42 100644
> > --- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> > +++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> > @@ -3,12 +3,12 @@ Marvell Platforms Device Tree Bindings
> >
> >  PXA168 Aspenite Board
> >  Required root node properties:
> > -   - compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
> > +   - compatible = "marvell,pxa168-aspenite", "marvell,pxa168";
> >
> >  PXA910 DKB Board
> >  Required root node properties:
> > -   - compatible = "mrvl,pxa910-dkb";
> > +   - compatible = "marvell,pxa910-dkb";
> >
> >  MMP2 Brownstone Board
> >  Required root node properties:
> > -   - compatible = "mrvl,mmp2-brownstone";
> > +   - compatible = "marvell,mmp2-brownstone";
> > diff --git a/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> > b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> > index 9a6e251..1304526 100644
> > --- a/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> > +++ b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> > @@ -1,13 +1,13 @@
> >  * Marvell MMP Timer controller
> >
> >  Required properties:
> > -- compatible : Should be "mrvl,mmp-timer".
> > +- compatible : Should be "marvell,mmp-timer".
> >  - reg : Address and length of the register set of timer controller.
> >  - interrupts : Should be the interrupt number.
> >
> >  Example:
> >     timer0: timer at d4014000 {
> > -           compatible = "mrvl,mmp-timer";
> > +           compatible = "marvell,mmp-timer";
> >             reg = <0xd4014000 0x100>;
> >             interrupts = <13>;
> >     };
> > diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> > b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> > index 12b78ac..34fdf5d 100644
> > --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> > +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> > @@ -3,9 +3,9 @@
> >  Required properties :
> >
> >   - reg : Offset and length of the register set for the device
> > - - compatible : should be "mrvl,mmp-twsi" where mmp is the name of a
> > + - compatible : should be "marvell,mmp-twsi" where mmp is the name of
> > + a
> >     compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
> > -   For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
> > +   For the pxa2xx/pxa3xx, an additional node "marvell,pxa-i2c" is
> > + required
> >     as shown in the example below.
> >
> >  Recommended properties :
> > @@ -14,20 +14,20 @@ Recommended properties :
> >   - interrupt-parent : the phandle for the interrupt controller that
> >     services interrupts for this device. If the parent is the default
> >     interrupt controller in device tree, it could be ignored.
> > - - mrvl,i2c-polling : Disable interrupt of i2c controller. Polling
> > + - marvell,i2c-polling : Disable interrupt of i2c controller. Polling
> >     status register of i2c controller instead.
> > - - mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
> > + - marvell,i2c-fast-mode : Enable fast mode of i2c controller.
> >
> >  Examples:
> >     twsi1: i2c at d4011000 {
> > -           compatible = "mrvl,mmp-twsi";
> > +           compatible = "marvell,mmp-twsi";
> >             reg = <0xd4011000 0x1000>;
> >             interrupts = <7>;
> > -           mrvl,i2c-fast-mode;
> > +           marvell,i2c-fast-mode;
> >     };
> >
> >     twsi2: i2c at d4025000 {
> > -           compatible = "mrvl,mmp-twsi";
> > +           compatible = "marvell,mmp-twsi";
> >             reg = <0xd4025000 0x1000>;
> >             interrupts = <58>;
> >     };
> > diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
> > b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
> > index dbe98a3..d603a3e 100644
> > --- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
> > +++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
> > @@ -4,18 +4,18 @@ This file documents differences between the core
> > properties in mmc.txt  and the properties used by the sdhci-pxav2 and
> sdhci-pxav3 drivers.
> >
> >  Required properties:
> > -- compatible: Should be "mrvl,pxav2-mmc" or "mrvl,pxav3-mmc".
> > +- compatible: Should be "marvell,pxav2-mmc" or "marvell,pxav3-mmc".
> >
> >  Optional properties:
> > -- mrvl,clk-delay-cycles: Specify a number of cycles to delay for tuning.
> > +- marvell,clk-delay-cycles: Specify a number of cycles to delay for tuning.
> >
> >  Example:
> >
> >  sdhci at d4280800 {
> > -   compatible = "mrvl,pxav3-mmc";
> > +   compatible = "marvell,pxav3-mmc";
> >     reg = <0xd4280800 0x800>;
> >     bus-width = <8>;
> >     interrupts = <27>;
> >     non-removable;
> > -   mrvl,clk-delay-cycles = <31>;
> > +   marvell,clk-delay-cycles = <31>;
> >  };
> > diff --git a/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
> > b/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
> > index 0cda19a..886fe15 100644
> > --- a/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
> > +++ b/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
> > @@ -1,7 +1,7 @@
> >  * Marvell Real Time Clock controller
> >
> >  Required properties:
> > -- compatible: should be "mrvl,sa1100-rtc"
> > +- compatible: should be "marvell,sa1100-rtc"
> >  - reg: physical base address of the controller and length of memory
> mapped
> >    region.
> >  - interrupts: Should be two. The first interrupt number is the rtc
> > alarm @@ -10,7 +10,7 @@ Required properties:
> >
> >  Example:
> >     rtc: rtc at d4010000 {
> > -           compatible = "mrvl,mmp-rtc";
> > +           compatible = "marvell,mmp-rtc";
> >             reg = <0xd4010000 0x1000>;
> >             interrupts = <5>, <6>;
> >             interrupt-name = "rtc 1Hz", "rtc alarm"; diff --git
> > a/Documentation/devicetree/bindings/serial/mrvl-serial.txt
> > b/Documentation/devicetree/bindings/serial/mrvl-serial.txt
> > index d744340..659d35e 100644
> > --- a/Documentation/devicetree/bindings/serial/mrvl-serial.txt
> > +++ b/Documentation/devicetree/bindings/serial/mrvl-serial.txt
> > @@ -1,4 +1,4 @@
> >  PXA UART controller
> >
> >  Required properties:
> > -- compatible : should be "mrvl,mmp-uart" or "mrvl,pxa-uart".
> > +- compatible : should be "marvell,mmp-uart" or "marvell,pxa-uart".
> > diff --git a/arch/arm/boot/dts/mmp2-brownstone.dts
> > b/arch/arm/boot/dts/mmp2-brownstone.dts
> > index 7f70a39..26abfde 100644
> > --- a/arch/arm/boot/dts/mmp2-brownstone.dts
> > +++ b/arch/arm/boot/dts/mmp2-brownstone.dts
> > @@ -12,7 +12,7 @@
> >
> >  / {
> >     model = "Marvell MMP2 Brownstone Development Board";
> > -   compatible = "mrvl,mmp2-brownstone", "mrvl,mmp2";
> > +   compatible = "marvell,mmp2-brownstone", "marvell,mmp2";
> >
> >     chosen {
> >             bootargs = "console=ttyS2,38400 root=/dev/nfs
> > nfsroot=192.168.1.100:/nfsroot/
> > ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
> > diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
> > index 4e8b08c..ac13654 100644
> > --- a/arch/arm/boot/dts/mmp2.dtsi
> > +++ b/arch/arm/boot/dts/mmp2.dtsi
> > @@ -32,128 +32,128 @@
> >             };
> >
> >             axi at d4200000 {  /* AXI */
> > -                   compatible = "mrvl,axi-bus", "simple-bus";
> > +                   compatible = "marvell,axi-bus", "simple-bus";
> >                     #address-cells = <1>;
> >                     #size-cells = <1>;
> >                     reg = <0xd4200000 0x00200000>;
> >                     ranges;
> >
> >                     intc: interrupt-controller at d4282000 {
> > -                           compatible = "mrvl,mmp2-intc";
> > +                           compatible = "marvell,mmp2-intc";
> >                             interrupt-controller;
> >                             #interrupt-cells = <1>;
> >                             reg = <0xd4282000 0x1000>;
> > -                           mrvl,intc-nr-irqs = <64>;
> > +                           marvell,intc-nr-irqs = <64>;
> >                     };
> >
> >                     intcmux4: interrupt-controller at d4282150 {
> > -                           compatible = "mrvl,mmp2-mux-intc";
> > +                           compatible = "marvell,mmp2-mux-intc";
> >                             interrupts = <4>;
> >                             interrupt-controller;
> >                             #interrupt-cells = <1>;
> >                             reg = <0x150 0x4>, <0x168 0x4>;
> >                             reg-names = "mux status", "mux mask";
> > -                           mrvl,intc-nr-irqs = <2>;
> > +                           marvell,intc-nr-irqs = <2>;
> >                     };
> >
> >                     intcmux5: interrupt-controller at d4282154 {
> > -                           compatible = "mrvl,mmp2-mux-intc";
> > +                           compatible = "marvell,mmp2-mux-intc";
> >                             interrupts = <5>;
> >                             interrupt-controller;
> >                             #interrupt-cells = <1>;
> >                             reg = <0x154 0x4>, <0x16c 0x4>;
> >                             reg-names = "mux status", "mux mask";
> > -                           mrvl,intc-nr-irqs = <2>;
> > -                           mrvl,clr-mfp-irq = <1>;
> > +                           marvell,intc-nr-irqs = <2>;
> > +                           marvell,clr-mfp-irq = <1>;
> >                     };
> >
> >                     intcmux9: interrupt-controller at d4282180 {
> > -                           compatible = "mrvl,mmp2-mux-intc";
> > +                           compatible = "marvell,mmp2-mux-intc";
> >                             interrupts = <9>;
> >                             interrupt-controller;
> >                             #interrupt-cells = <1>;
> >                             reg = <0x180 0x4>, <0x17c 0x4>;
> >                             reg-names = "mux status", "mux mask";
> > -                           mrvl,intc-nr-irqs = <3>;
> > +                           marvell,intc-nr-irqs = <3>;
> >                     };
> >
> >                     intcmux17: interrupt-controller at d4282158 {
> > -                           compatible = "mrvl,mmp2-mux-intc";
> > +                           compatible = "marvell,mmp2-mux-intc";
> >                             interrupts = <17>;
> >                             interrupt-controller;
> >                             #interrupt-cells = <1>;
> >                             reg = <0x158 0x4>, <0x170 0x4>;
> >                             reg-names = "mux status", "mux mask";
> > -                           mrvl,intc-nr-irqs = <5>;
> > +                           marvell,intc-nr-irqs = <5>;
> >                     };
> >
> >                     intcmux35: interrupt-controller at d428215c {
> > -                           compatible = "mrvl,mmp2-mux-intc";
> > +                           compatible = "marvell,mmp2-mux-intc";
> >                             interrupts = <35>;
> >                             interrupt-controller;
> >                             #interrupt-cells = <1>;
> >                             reg = <0x15c 0x4>, <0x174 0x4>;
> >                             reg-names = "mux status", "mux mask";
> > -                           mrvl,intc-nr-irqs = <15>;
> > +                           marvell,intc-nr-irqs = <15>;
> >                     };
> >
> >                     intcmux51: interrupt-controller at d4282160 {
> > -                           compatible = "mrvl,mmp2-mux-intc";
> > +                           compatible = "marvell,mmp2-mux-intc";
> >                             interrupts = <51>;
> >                             interrupt-controller;
> >                             #interrupt-cells = <1>;
> >                             reg = <0x160 0x4>, <0x178 0x4>;
> >                             reg-names = "mux status", "mux mask";
> > -                           mrvl,intc-nr-irqs = <2>;
> > +                           marvell,intc-nr-irqs = <2>;
> >                     };
> >
> >                     intcmux55: interrupt-controller at d4282188 {
> > -                           compatible = "mrvl,mmp2-mux-intc";
> > +                           compatible = "marvell,mmp2-mux-intc";
> >                             interrupts = <55>;
> >                             interrupt-controller;
> >                             #interrupt-cells = <1>;
> >                             reg = <0x188 0x4>, <0x184 0x4>;
> >                             reg-names = "mux status", "mux mask";
> > -                           mrvl,intc-nr-irqs = <2>;
> > +                           marvell,intc-nr-irqs = <2>;
> >                     };
> >             };
> >
> >             apb at d4000000 {  /* APB */
> > -                   compatible = "mrvl,apb-bus", "simple-bus";
> > +                   compatible = "marvell,apb-bus", "simple-bus";
> >                     #address-cells = <1>;
> >                     #size-cells = <1>;
> >                     reg = <0xd4000000 0x00200000>;
> >                     ranges;
> >
> >                     timer0: timer at d4014000 {
> > -                           compatible = "mrvl,mmp-timer";
> > +                           compatible = "marvell,mmp-timer";
> >                             reg = <0xd4014000 0x100>;
> >                             interrupts = <13>;
> >                     };
> >
> >                     uart1: uart at d4030000 {
> > -                           compatible = "mrvl,mmp-uart";
> > +                           compatible = "marvell,mmp-uart";
> >                             reg = <0xd4030000 0x1000>;
> >                             interrupts = <27>;
> >                             status = "disabled";
> >                     };
> >
> >                     uart2: uart at d4017000 {
> > -                           compatible = "mrvl,mmp-uart";
> > +                           compatible = "marvell,mmp-uart";
> >                             reg = <0xd4017000 0x1000>;
> >                             interrupts = <28>;
> >                             status = "disabled";
> >                     };
> >
> >                     uart3: uart at d4018000 {
> > -                           compatible = "mrvl,mmp-uart";
> > +                           compatible = "marvell,mmp-uart";
> >                             reg = <0xd4018000 0x1000>;
> >                             interrupts = <24>;
> >                             status = "disabled";
> >                     };
> >
> >                     uart4: uart at d4016000 {
> > -                           compatible = "mrvl,mmp-uart";
> > +                           compatible = "marvell,mmp-uart";
> >                             reg = <0xd4016000 0x1000>;
> >                             interrupts = <46>;
> >                             status = "disabled";
> > @@ -198,24 +198,24 @@
> >                     };
> >
> >                     twsi1: i2c at d4011000 {
> > -                           compatible = "mrvl,mmp-twsi";
> > +                           compatible = "marvell,mmp-twsi";
> >                             reg = <0xd4011000 0x1000>;
> >                             interrupts = <7>;
> >                             #address-cells = <1>;
> >                             #size-cells = <0>;
> > -                           mrvl,i2c-fast-mode;
> > +                           marvell,i2c-fast-mode;
> >                             status = "disabled";
> >                     };
> >
> >                     twsi2: i2c at d4025000 {
> > -                           compatible = "mrvl,mmp-twsi";
> > +                           compatible = "marvell,mmp-twsi";
> >                             reg = <0xd4025000 0x1000>;
> >                             interrupts = <58>;
> >                             status = "disabled";
> >                     };
> >
> >                     rtc: rtc at d4010000 {
> > -                           compatible = "mrvl,mmp-rtc";
> > +                           compatible = "marvell,mmp-rtc";
> >                             reg = <0xd4010000 0x1000>;
> >                             interrupts = <1 0>;
> >                             interrupt-names = "rtc 1Hz", "rtc alarm"; diff --git
> > a/arch/arm/boot/dts/pxa168-aspenite.dts
> > b/arch/arm/boot/dts/pxa168-aspenite.dts
> > index e762fac..1e2ac17 100644
> > --- a/arch/arm/boot/dts/pxa168-aspenite.dts
> > +++ b/arch/arm/boot/dts/pxa168-aspenite.dts
> > @@ -12,7 +12,7 @@
> >
> >  / {
> >     model = "Marvell PXA168 Aspenite Development Board";
> > -   compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
> > +   compatible = "marvell,pxa168-aspenite", "marvell,pxa168";
> >
> >     chosen {
> >             bootargs = "console=ttyS0,115200 root=/dev/nfs
> > nfsroot=192.168.1.100:/nfsroot/
> > ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
> > diff --git a/arch/arm/boot/dts/pxa168.dtsi
> > b/arch/arm/boot/dts/pxa168.dtsi index 975dad2..c08f5fc 100644
> > --- a/arch/arm/boot/dts/pxa168.dtsi
> > +++ b/arch/arm/boot/dts/pxa168.dtsi
> > @@ -26,51 +26,51 @@
> >             ranges;
> >
> >             axi at d4200000 {  /* AXI */
> > -                   compatible = "mrvl,axi-bus", "simple-bus";
> > +                   compatible = "marvell,axi-bus", "simple-bus";
> >                     #address-cells = <1>;
> >                     #size-cells = <1>;
> >                     reg = <0xd4200000 0x00200000>;
> >                     ranges;
> >
> >                     intc: interrupt-controller at d4282000 {
> > -                           compatible = "mrvl,mmp-intc";
> > +                           compatible = "marvell,mmp-intc";
> >                             interrupt-controller;
> >                             #interrupt-cells = <1>;
> >                             reg = <0xd4282000 0x1000>;
> > -                           mrvl,intc-nr-irqs = <64>;
> > +                           marvell,intc-nr-irqs = <64>;
> >                     };
> >
> >             };
> >
> >             apb at d4000000 {  /* APB */
> > -                   compatible = "mrvl,apb-bus", "simple-bus";
> > +                   compatible = "marvell,apb-bus", "simple-bus";
> >                     #address-cells = <1>;
> >                     #size-cells = <1>;
> >                     reg = <0xd4000000 0x00200000>;
> >                     ranges;
> >
> >                     timer0: timer at d4014000 {
> > -                           compatible = "mrvl,mmp-timer";
> > +                           compatible = "marvell,mmp-timer";
> >                             reg = <0xd4014000 0x100>;
> >                             interrupts = <13>;
> >                     };
> >
> >                     uart1: uart at d4017000 {
> > -                           compatible = "mrvl,mmp-uart";
> > +                           compatible = "marvell,mmp-uart";
> >                             reg = <0xd4017000 0x1000>;
> >                             interrupts = <27>;
> >                             status = "disabled";
> >                     };
> >
> >                     uart2: uart at d4018000 {
> > -                           compatible = "mrvl,mmp-uart";
> > +                           compatible = "marvell,mmp-uart";
> >                             reg = <0xd4018000 0x1000>;
> >                             interrupts = <28>;
> >                             status = "disabled";
> >                     };
> >
> >                     uart3: uart at d4026000 {
> > -                           compatible = "mrvl,mmp-uart";
> > +                           compatible = "marvell,mmp-uart";
> >                             reg = <0xd4026000 0x1000>;
> >                             interrupts = <29>;
> >                             status = "disabled";
> > @@ -107,22 +107,22 @@
> >                     };
> >
> >                     twsi1: i2c at d4011000 {
> > -                           compatible = "mrvl,mmp-twsi";
> > +                           compatible = "marvell,mmp-twsi";
> >                             reg = <0xd4011000 0x1000>;
> >                             interrupts = <7>;
> > -                           mrvl,i2c-fast-mode;
> > +                           marvell,i2c-fast-mode;
> >                             status = "disabled";
> >                     };
> >
> >                     twsi2: i2c at d4025000 {
> > -                           compatible = "mrvl,mmp-twsi";
> > +                           compatible = "marvell,mmp-twsi";
> >                             reg = <0xd4025000 0x1000>;
> >                             interrupts = <58>;
> >                             status = "disabled";
> >                     };
> >
> >                     rtc: rtc at d4010000 {
> > -                           compatible = "mrvl,mmp-rtc";
> > +                           compatible = "marvell,mmp-rtc";
> >                             reg = <0xd4010000 0x1000>;
> >                             interrupts = <5 6>;
> >                             interrupt-names = "rtc 1Hz", "rtc alarm"; diff --git
> > a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx.dtsi index
> > a5e90f0..c426b1e 100644
> > --- a/arch/arm/boot/dts/pxa2xx.dtsi
> > +++ b/arch/arm/boot/dts/pxa2xx.dtsi
> > @@ -47,7 +47,7 @@
> >             };
> >
> >             gpio: gpio at 40e00000 {
> > -                   compatible = "mrvl,pxa-gpio";
> > +                   compatible = "marvell,pxa-gpio";
> >                     #address-cells = <0x1>;
> >                     #size-cells = <0x1>;
> >                     reg = <0x40e00000 0x10000>;
> > @@ -76,35 +76,35 @@
> >             };
> >
> >             ffuart: uart at 40100000 {
> > -                   compatible = "mrvl,pxa-uart";
> > +                   compatible = "marvell,pxa-uart";
> >                     reg = <0x40100000 0x30>;
> >                     interrupts = <22>;
> >                     status = "disabled";
> >             };
> >
> >             btuart: uart at 40200000 {
> > -                   compatible = "mrvl,pxa-uart";
> > +                   compatible = "marvell,pxa-uart";
> >                     reg = <0x40200000 0x30>;
> >                     interrupts = <21>;
> >                     status = "disabled";
> >             };
> >
> >             stuart: uart at 40700000 {
> > -                   compatible = "mrvl,pxa-uart";
> > +                   compatible = "marvell,pxa-uart";
> >                     reg = <0x40700000 0x30>;
> >                     interrupts = <20>;
> >                     status = "disabled";
> >             };
> >
> >             hwuart: uart at 41100000 {
> > -                   compatible = "mrvl,pxa-uart";
> > +                   compatible = "marvell,pxa-uart";
> >                     reg = <0x41100000 0x30>;
> >                     interrupts = <7>;
> >                     status = "disabled";
> >             };
> >
> >             pxai2c1: i2c at 40301680 {
> > -                   compatible = "mrvl,pxa-i2c";
> > +                   compatible = "marvell,pxa-i2c";
> >                     reg = <0x40301680 0x30>;
> >                     interrupts = <18>;
> >                     #address-cells = <0x1>;
> > @@ -113,14 +113,14 @@
> >             };
> >
> >             usb0: ohci at 4c000000 {
> > -                   compatible = "mrvl,pxa-ohci";
> > +                   compatible = "marvell,pxa-ohci";
> >                     reg = <0x4c000000 0x10000>;
> >                     interrupts = <3>;
> >                     status = "disabled";
> >             };
> >
> >             mmc0: mmc at 41100000 {
> > -                   compatible = "mrvl,pxa-mmc";
> > +                   compatible = "marvell,pxa-mmc";
> >                     reg = <0x41100000 0x1000>;
> >                     interrupts = <23>;
> >                     status = "disabled";
> > diff --git a/arch/arm/boot/dts/pxa3xx.dtsi
> > b/arch/arm/boot/dts/pxa3xx.dtsi index f9d92da..0798031 100644
> > --- a/arch/arm/boot/dts/pxa3xx.dtsi
> > +++ b/arch/arm/boot/dts/pxa3xx.dtsi
> > @@ -7,7 +7,7 @@
> >
> >     pxabus {
> >             pwri2c: i2c at 40f500c0 {
> > -                   compatible = "mrvl,pwri2c";
> > +                   compatible = "marvell,pwri2c";
> >                     reg = <0x40f500c0 0x30>;
> >                     interrupts = <6>;
> >                     #address-cells = <0x1>;
> > diff --git a/arch/arm/boot/dts/pxa910-dkb.dts
> > b/arch/arm/boot/dts/pxa910-dkb.dts
> > index 595492a..7384254 100644
> > --- a/arch/arm/boot/dts/pxa910-dkb.dts
> > +++ b/arch/arm/boot/dts/pxa910-dkb.dts
> > @@ -12,7 +12,7 @@
> >
> >  / {
> >     model = "Marvell PXA910 DKB Development Board";
> > -   compatible = "mrvl,pxa910-dkb", "mrvl,pxa910";
> > +   compatible = "marvell,pxa910-dkb", "marvell,pxa910";
> >
> >     chosen {
> >             bootargs = "console=ttyS0,115200 root=/dev/nfs
> > nfsroot=192.168.1.100:/nfsroot/
> > ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
> > diff --git a/arch/arm/boot/dts/pxa910.dtsi
> > b/arch/arm/boot/dts/pxa910.dtsi index 0247c62..b5594a0 100644
> > --- a/arch/arm/boot/dts/pxa910.dtsi
> > +++ b/arch/arm/boot/dts/pxa910.dtsi
> > @@ -31,58 +31,59 @@
> >             };
> >
> >             axi at d4200000 {  /* AXI */
> > -                   compatible = "mrvl,axi-bus", "simple-bus";
> > +                   compatible = "marvell,axi-bus", "simple-bus";
> >                     #address-cells = <1>;
> >                     #size-cells = <1>;
> >                     reg = <0xd4200000 0x00200000>;
> >                     ranges;
> >
> >                     intc: interrupt-controller at d4282000 {
> > -                           compatible = "mrvl,mmp-intc";
> > +                           compatible = "marvell,mmp-intc";
> >                             interrupt-controller;
> >                             #interrupt-cells = <1>;
> >                             reg = <0xd4282000 0x1000>;
> > -                           mrvl,intc-nr-irqs = <64>;
> > +                           marvell,intc-nr-irqs = <64>;
> > +
> >                     };
> >
> >             };
> >
> >             apb at d4000000 {  /* APB */
> > -                   compatible = "mrvl,apb-bus", "simple-bus";
> > +                   compatible = "marvell,apb-bus", "simple-bus";
> >                     #address-cells = <1>;
> >                     #size-cells = <1>;
> >                     reg = <0xd4000000 0x00200000>;
> >                     ranges;
> >
> >                     timer0: timer at d4014000 {
> > -                           compatible = "mrvl,mmp-timer";
> > +                           compatible = "marvell,mmp-timer";
> >                             reg = <0xd4014000 0x100>;
> >                             interrupts = <13>;
> >                     };
> >
> >                     timer1: timer at d4016000 {
> > -                           compatible = "mrvl,mmp-timer";
> > +                           compatible = "marvell,mmp-timer";
> >                             reg = <0xd4016000 0x100>;
> >                             interrupts = <29>;
> >                             status = "disabled";
> >                     };
> >
> >                     uart1: uart at d4017000 {
> > -                           compatible = "mrvl,mmp-uart";
> > +                           compatible = "marvell,mmp-uart";
> >                             reg = <0xd4017000 0x1000>;
> >                             interrupts = <27>;
> >                             status = "disabled";
> >                     };
> >
> >                     uart2: uart at d4018000 {
> > -                           compatible = "mrvl,mmp-uart";
> > +                           compatible = "marvell,mmp-uart";
> >                             reg = <0xd4018000 0x1000>;
> >                             interrupts = <28>;
> >                             status = "disabled";
> >                     };
> >
> >                     uart3: uart at d4036000 {
> > -                           compatible = "mrvl,mmp-uart";
> > +                           compatible = "marvell,mmp-uart";
> >                             reg = <0xd4036000 0x1000>;
> >                             interrupts = <59>;
> >                             status = "disabled";
> > @@ -119,17 +120,17 @@
> >                     };
> >
> >                     twsi1: i2c at d4011000 {
> > -                           compatible = "mrvl,mmp-twsi";
> > +                           compatible = "marvell,mmp-twsi";
> >                             #address-cells = <1>;
> >                             #size-cells = <0>;
> >                             reg = <0xd4011000 0x1000>;
> >                             interrupts = <7>;
> > -                           mrvl,i2c-fast-mode;
> > +                           marvell,i2c-fast-mode;
> >                             status = "disabled";
> >                     };
> >
> >                     twsi2: i2c at d4037000 {
> > -                           compatible = "mrvl,mmp-twsi";
> > +                           compatible = "marvell,mmp-twsi";
> >                             #address-cells = <1>;
> >                             #size-cells = <0>;
> >                             reg = <0xd4037000 0x1000>;
> > @@ -138,7 +139,7 @@
> >                     };
> >
> >                     rtc: rtc at d4010000 {
> > -                           compatible = "mrvl,mmp-rtc";
> > +                           compatible = "marvell,mmp-rtc";
> >                             reg = <0xd4010000 0x1000>;
> >                             interrupts = <5 6>;
> >                             interrupt-names = "rtc 1Hz", "rtc alarm"; diff --git
> > a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c index
> > 3c71246..a7a53611 100644
> > --- a/arch/arm/mach-mmp/irq.c
> > +++ b/arch/arm/mach-mmp/irq.c
> > @@ -327,13 +327,13 @@ void __init mmp2_init_icu(void)
> >
> >  #ifdef CONFIG_OF
> >  static const struct of_device_id intc_ids[] __initconst = {
> > -   { .compatible = "mrvl,mmp-intc", .data = &mmp_conf },
> > -   { .compatible = "mrvl,mmp2-intc", .data = &mmp2_conf },
> > +   { .compatible = "marvell,mmp-intc", .data = &mmp_conf },
> > +   { .compatible = "marvell,mmp2-intc", .data = &mmp2_conf },
> >     {}
> >  };
> >
> >  static const struct of_device_id mmp_mux_irq_match[] __initconst = {
> > -   { .compatible = "mrvl,mmp2-mux-intc" },
> > +   { .compatible = "marvell,mmp2-mux-intc" },
> >     {}
> >  };
> >
> > @@ -352,10 +352,10 @@ int __init mmp2_mux_init(struct device_node
> *parent)
> >             if (!node)
> >                     break;
> >             of_id = of_match_node(&mmp_mux_irq_match[0], node);
> > -           ret = of_property_read_u32(node, "mrvl,intc-nr-irqs",
> > +           ret = of_property_read_u32(node, "marvell,intc-nr-irqs",
> >                                        &nr_irqs);
> >             if (ret) {
> > -                   pr_err("Not found mrvl,intc-nr-irqs property\n");
> > +                   pr_err("Not found marvell,intc-nr-irqs property\n");
> >                     ret = -EINVAL;
> >                     goto err;
> >             }
> > @@ -385,7 +385,7 @@ int __init mmp2_mux_init(struct device_node
> *parent)
> >                     ret = irq_base;
> >                     goto err;
> >             }
> > -           if (!of_property_read_u32(node, "mrvl,clr-mfp-irq",
> > +           if (!of_property_read_u32(node, "marvell,clr-mfp-irq",
> >                                       &mfp_irq)) {
> >                     icu_data[i].clr_mfp_irq_base = irq_base;
> >                     icu_data[i].clr_mfp_hwirq = mfp_irq; @@ -424,9 +424,9 @@
> void
> > __init mmp_dt_irq_init(void)
> >     of_id = of_match_node(intc_ids, node);
> >     conf = of_id->data;
> >
> > -   ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", &nr_irqs);
> > +   ret = of_property_read_u32(node, "marvell,intc-nr-irqs", &nr_irqs);
> >     if (ret) {
> > -           pr_err("Not found mrvl,intc-nr-irqs property\n");
> > +           pr_err("Not found marvell,intc-nr-irqs property\n");
> >             return;
> >     }
> >
> > diff --git a/arch/arm/mach-mmp/mmp-dt.c
> b/arch/arm/mach-mmp/mmp-dt.c
> > index b37915d..62c5adb 100644
> > --- a/arch/arm/mach-mmp/mmp-dt.c
> > +++ b/arch/arm/mach-mmp/mmp-dt.c
> > @@ -23,24 +23,24 @@ extern void __init mmp_dt_irq_init(void);  extern
> > void __init mmp_dt_init_timer(void);
> >
> >  static const struct of_dev_auxdata pxa168_auxdata_lookup[] __initconst
> = {
> > -   OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.0",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.1",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4026000, "pxa2xx-uart.2",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4017000, "pxa2xx-uart.0",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4018000, "pxa2xx-uart.1",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4026000, "pxa2xx-uart.2",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1",
> > +NULL),
> >     OF_DEV_AUXDATA("marvell,mmp-gpio", 0xd4019000, "mmp-gpio",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-rtc", 0xd4010000, "sa1100-rtc",
> NULL),
> >     {}
> >  };
> >
> >  static const struct of_dev_auxdata pxa910_auxdata_lookup[] __initconst
> = {
> > -   OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.0",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.1",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4036000, "pxa2xx-uart.2",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4037000, "pxa2xx-i2c.1",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4017000, "pxa2xx-uart.0",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4018000, "pxa2xx-uart.1",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4036000, "pxa2xx-uart.2",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4037000, "pxa2xx-i2c.1",
> > +NULL),
> >     OF_DEV_AUXDATA("marvell,mmp-gpio", 0xd4019000, "mmp-gpio",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-rtc", 0xd4010000, "sa1100-rtc",
> NULL),
> >     {}
> >  };
> >
> > @@ -57,8 +57,8 @@ static void __init pxa910_dt_init(void)  }
> >
> >  static const char *mmp_dt_board_compat[] __initdata = {
> > -   "mrvl,pxa168-aspenite",
> > -   "mrvl,pxa910-dkb",
> > +   "marvell,pxa168-aspenite",
> > +   "marvell,pxa910-dkb",
> >     NULL,
> >  };
> >
> > diff --git a/arch/arm/mach-mmp/mmp2-dt.c
> b/arch/arm/mach-mmp/mmp2-dt.c
> > index 4ac2567..6523ecf 100644
> > --- a/arch/arm/mach-mmp/mmp2-dt.c
> > +++ b/arch/arm/mach-mmp/mmp2-dt.c
> > @@ -25,14 +25,14 @@ extern void __init mmp_dt_irq_init(void);  extern
> > void __init mmp_dt_init_timer(void);
> >
> >  static const struct of_dev_auxdata mmp2_auxdata_lookup[] __initconst
> = {
> > -   OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4030000, "pxa2xx-uart.0",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.1",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.2",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4016000, "pxa2xx-uart.3",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4030000, "pxa2xx-uart.0",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4017000, "pxa2xx-uart.1",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4018000, "pxa2xx-uart.2",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-uart", 0xd4016000, "pxa2xx-uart.3",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-twsi", 0xd4025000, "pxa2xx-i2c.1",
> > +NULL),
> >     OF_DEV_AUXDATA("marvell,mmp-gpio", 0xd4019000, "mmp2-gpio",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd4010000, "sa1100-rtc", NULL),
> > +   OF_DEV_AUXDATA("marvell,mmp-rtc", 0xd4010000, "sa1100-rtc",
> NULL),
> >     {}
> >  };
> >
> > @@ -43,7 +43,7 @@ static void __init mmp2_dt_init(void)  }
> >
> >  static const char *mmp2_dt_board_compat[] __initdata = {
> > -   "mrvl,mmp2-brownstone",
> > +   "marvell,mmp2-brownstone",
> >     NULL,
> >  };
> >
> > diff --git a/arch/arm/mach-mmp/time.c b/arch/arm/mach-mmp/time.c
> index
> > 7ac41e8..67e7d5c 100644
> > --- a/arch/arm/mach-mmp/time.c
> > +++ b/arch/arm/mach-mmp/time.c
> > @@ -208,7 +208,7 @@ void __init timer_init(int irq)
> >
> >  #ifdef CONFIG_OF
> >  static struct of_device_id mmp_timer_dt_ids[] = {
> > -   { .compatible = "mrvl,mmp-timer", },
> > +   { .compatible = "marvell,mmp-timer", },
> >     {}
> >  };
> >
> > diff --git a/arch/arm/mach-pxa/pxa-dt.c b/arch/arm/mach-pxa/pxa-dt.c
> > index 3835979..b679367 100644
> > --- a/arch/arm/mach-pxa/pxa-dt.c
> > +++ b/arch/arm/mach-pxa/pxa-dt.c
> > @@ -23,15 +23,15 @@
> >  extern void __init pxa3xx_dt_init_irq(void);
> >
> >  static const struct of_dev_auxdata pxa3xx_auxdata_lookup[] __initconst
> = {
> > -   OF_DEV_AUXDATA("mrvl,pxa-uart",         0x40100000,
> "pxa2xx-uart.0", NULL),
> > -   OF_DEV_AUXDATA("mrvl,pxa-uart",         0x40200000,
> "pxa2xx-uart.1", NULL),
> > -   OF_DEV_AUXDATA("mrvl,pxa-uart",         0x40700000,
> "pxa2xx-uart.2", NULL),
> > -   OF_DEV_AUXDATA("mrvl,pxa-uart",         0x41600000,
> "pxa2xx-uart.3", NULL),
> > +   OF_DEV_AUXDATA("marvell,pxa-uart",      0x40100000,
> "pxa2xx-uart.0", NULL),
> > +   OF_DEV_AUXDATA("marvell,pxa-uart",      0x40200000,
> "pxa2xx-uart.1", NULL),
> > +   OF_DEV_AUXDATA("marvell,pxa-uart",      0x40700000,
> "pxa2xx-uart.2", NULL),
> > +   OF_DEV_AUXDATA("marvell,pxa-uart",      0x41600000,
> "pxa2xx-uart.3", NULL),
> >     OF_DEV_AUXDATA("marvell,pxa-mmc",       0x41100000, "pxa2xx-mci.0",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,pxa-gpio",         0x40e00000, "pxa-gpio",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,pxa-gpio",      0x40e00000, "pxa-gpio",
> NULL),
> >     OF_DEV_AUXDATA("marvell,pxa-ohci",      0x4c000000, "pxa27x-ohci",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,pxa-i2c",          0x40301680, "pxa2xx-i2c.0",
> NULL),
> > -   OF_DEV_AUXDATA("mrvl,pwri2c",           0x40f500c0, "pxa3xx-i2c.1",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,pxa-i2c",       0x40301680, "pxa2xx-i2c.0",
> NULL),
> > +   OF_DEV_AUXDATA("marvell,pwri2c",        0x40f500c0, "pxa3xx-i2c.1",
> NULL),
> >     OF_DEV_AUXDATA("marvell,pxa3xx-nand",   0x43100000, "pxa3xx-nand",
> NULL),
> >     {}
> >  };
> > diff --git a/drivers/i2c/busses/i2c-pxa.c
> > b/drivers/i2c/busses/i2c-pxa.c index fbafed2..6f2b17d 100644
> > --- a/drivers/i2c/busses/i2c-pxa.c
> > +++ b/drivers/i2c/busses/i2c-pxa.c
> > @@ -1040,9 +1040,9 @@ static const struct i2c_algorithm
> > i2c_pxa_pio_algorithm = {  };
> >
> >  static struct of_device_id i2c_pxa_dt_ids[] = {
> > -   { .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
> > -   { .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
> > -   { .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA2XX },
> > +   { .compatible = "marvell,pxa-i2c", .data = (void *)REGS_PXA2XX },
> > +   { .compatible = "marvell,pwri2c", .data = (void *)REGS_PXA3XX },
> > +   { .compatible = "marvell,mmp-twsi", .data = (void *)REGS_PXA2XX },
> >     {}
> >  };
> >  MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids); @@ -1060,9 +1060,9 @@
> static
> > int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
> >     /* For device tree we always use the dynamic or alias-assigned ID */
> >     i2c->adap.nr = -1;
> >
> > -   if (of_get_property(np, "mrvl,i2c-polling", NULL))
> > +   if (of_get_property(np, "marvell,i2c-polling", NULL))
> >             i2c->use_pio = 1;
> > -   if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
> > +   if (of_get_property(np, "marvell,i2c-fast-mode", NULL))
> >             i2c->fast_mode = 1;
> >     *i2c_types = (u32)(of_id->data);
> >     return 0;
> > diff --git a/drivers/mmc/host/sdhci-pxav2.c
> > b/drivers/mmc/host/sdhci-pxav2.c index 6a3f702..1dd6500 100644
> > --- a/drivers/mmc/host/sdhci-pxav2.c
> > +++ b/drivers/mmc/host/sdhci-pxav2.c
> > @@ -120,7 +120,7 @@ static const struct sdhci_ops pxav2_sdhci_ops = {
> > #ifdef CONFIG_OF  static const struct of_device_id
> > sdhci_pxav2_of_match[] = {
> >     {
> > -           .compatible = "mrvl,pxav2-mmc",
> > +           .compatible = "marvell,pxav2-mmc",
> >     },
> >     {},
> >  };
> > @@ -144,7 +144,7 @@ static struct sdhci_pxa_platdata
> *pxav2_get_mmc_pdata(struct device *dev)
> >     if (bus_width == 8)
> >             pdata->flags |= PXA_FLAG_SD_8_BIT_CAPABLE_SLOT;
> >
> > -   of_property_read_u32(np, "mrvl,clk-delay-cycles", &clk_delay_cycles);
> > +   of_property_read_u32(np, "marvell,clk-delay-cycles",
> > +&clk_delay_cycles);
> >     if (clk_delay_cycles > 0) {
> >             pdata->clk_delay_sel = 1;
> >             pdata->clk_delay_cycles = clk_delay_cycles; diff --git
> > a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
> > index 1ae358e..a88974b 100644
> > --- a/drivers/mmc/host/sdhci-pxav3.c
> > +++ b/drivers/mmc/host/sdhci-pxav3.c
> > @@ -185,7 +185,7 @@ static struct sdhci_pltfm_data sdhci_pxav3_pdata
> =
> > {  #ifdef CONFIG_OF  static const struct of_device_id
> > sdhci_pxav3_of_match[] = {
> >     {
> > -           .compatible = "mrvl,pxav3-mmc",
> > +           .compatible = "marvell,pxav3-mmc",
> >     },
> >     {},
> >  };
> > @@ -201,7 +201,7 @@ static struct sdhci_pxa_platdata
> *pxav3_get_mmc_pdata(struct device *dev)
> >     if (!pdata)
> >             return NULL;
> >
> > -   of_property_read_u32(np, "mrvl,clk-delay-cycles", &clk_delay_cycles);
> > +   of_property_read_u32(np, "marvell,clk-delay-cycles",
> > +&clk_delay_cycles);
> >     if (clk_delay_cycles > 0)
> >             pdata->clk_delay_cycles = clk_delay_cycles;
> >
> > diff --git a/drivers/rtc/rtc-sa1100.c b/drivers/rtc/rtc-sa1100.c index
> > 0f7adeb..307dd37 100644
> > --- a/drivers/rtc/rtc-sa1100.c
> > +++ b/drivers/rtc/rtc-sa1100.c
> > @@ -339,8 +339,8 @@ static SIMPLE_DEV_PM_OPS(sa1100_rtc_pm_ops,
> > sa1100_rtc_suspend,
> >
> >  #ifdef CONFIG_OF
> >  static struct of_device_id sa1100_rtc_dt_ids[] = {
> > -   { .compatible = "mrvl,sa1100-rtc", },
> > -   { .compatible = "mrvl,mmp-rtc", },
> > +   { .compatible = "marvell,sa1100-rtc", },
> > +   { .compatible = "marvell,mmp-rtc", },
> >     {}
> >  };
> >  MODULE_DEVICE_TABLE(of, sa1100_rtc_dt_ids); diff --git
> > a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c index
> > 05f504e..cb1a439 100644
> > --- a/drivers/tty/serial/pxa.c
> > +++ b/drivers/tty/serial/pxa.c
> > @@ -852,8 +852,8 @@ static const struct dev_pm_ops
> serial_pxa_pm_ops =
> > {  #endif
> >
> >  static struct of_device_id serial_pxa_dt_ids[] = {
> > -   { .compatible = "mrvl,pxa-uart", },
> > -   { .compatible = "mrvl,mmp-uart", },
> > +   { .compatible = "marvell,pxa-uart", },
> > +   { .compatible = "marvell,mmp-uart", },
> >     {}
> >  };
> >  MODULE_DEVICE_TABLE(of, serial_pxa_dt_ids);
> > --
> > 1.7.4.1
> >
> >

Best Regards,
Neil Zhang


> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

From ldewangan at nvidia.com  Wed Jul 10 03:37:32 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 10 Jul 2013 13:07:32 +0530
Subject: [PATCH V2] ARM: tegra: enable palmas device for dalmore
Message-ID: <1373441852-27176-1-git-send-email-ldewangan@nvidia.com>

Make the entry of Dalmore Power Management Unit device TPS65913
in dalmore DTS file. The Palma driver support this device.

Enable following submodule of the TPS65913:
- GPIO driver
- RTC driver.
- Power regulator driver.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
Changes from V1:
- renames nodes from palams_* to simple as gpio, rtc, pmic etc.
- Added line gap properly.
- Remove comment for palams-gpio reference as the entry itself explain.
- Remove unit address for tps65913.

 arch/arm/boot/dts/tegra114-dalmore.dts |  184 +++++++++++++++++++++++++++++++-
 1 files changed, 183 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index a42bfa4..7bdad77 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -791,7 +791,7 @@
 					regulator-boot-on;
 				};
 
-				dcdc3 {
+				tps65090_dcdc3_reg: dcdc3 {
 					regulator-name = "vdd-ao";
 					regulator-always-on;
 					regulator-boot-on;
@@ -836,6 +836,178 @@
 				};
 			};
 		};
+
+		palmas: tps65913 {
+			compatible = "ti,palmas";
+			reg = <0x58>;
+			interrupts = <0 86 0x4>;
+
+			#interrupt-cells = <2>;
+			interrupt-controller;
+
+			palmas_gpio: gpio {
+				compatible = "ti,palmas-gpio";
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			rtc {
+				compatible = "ti,palmas-rtc";
+				interrupt-parent = <&palmas>;
+				interrupts = <8 0>;
+			};
+
+			pmic {
+			    compatible = "ti,tps65913-pmic", "ti,palmas-pmic";
+			    smps1-in-supply = <&tps65090_dcdc3_reg>;
+			    smps3-in-supply = <&tps65090_dcdc3_reg>;
+			    smps4-in-supply = <&tps65090_dcdc2_reg>;
+			    smps7-in-supply = <&tps65090_dcdc2_reg>;
+			    smps8-in-supply = <&tps65090_dcdc2_reg>;
+			    smps9-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo1-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo2-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo3-in-supply = <&palmas_smps3_reg>;
+			    ldo4-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo5-in-supply = <&vdd_ac_bat_reg>;
+			    ldo6-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo7-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo8-in-supply = <&tps65090_dcdc3_reg>;
+			    ldo9-in-supply = <&palmas_smps9_reg>;
+			    ldoln-in-supply = <&tps65090_dcdc1_reg>;
+			    ldousb-in-supply = <&tps65090_dcdc1_reg>;
+
+			    regulators {
+				smps12 {
+					regulator-name = "vddio-ddr";
+					regulator-min-microvolt = <1350000>;
+					regulator-max-microvolt = <1350000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				palmas_smps3_reg: smps3 {
+					regulator-name = "vddio-1v8";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				smps45 {
+					regulator-name = "vdd-core";
+					regulator-min-microvolt = <900000>;
+					regulator-max-microvolt = <1400000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				smps457 {
+					regulator-name = "vdd-core";
+					regulator-min-microvolt = <900000>;
+					regulator-max-microvolt = <1400000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				smps8 {
+					regulator-name = "avdd-pll";
+					regulator-min-microvolt = <1050000>;
+					regulator-max-microvolt = <1050000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				palmas_smps9_reg: smps9 {
+					regulator-name = "sdhci-vdd-sd-slot";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+					regulator-always-on;
+				};
+
+				ldo1 {
+					regulator-name = "avdd-cam1";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo2 {
+					regulator-name = "avdd-cam2";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo3 {
+					regulator-name = "avdd-dsi-csi";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				ldo4 {
+					regulator-name = "vpp-fuse";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+				};
+
+				ldo6 {
+					regulator-name = "vdd-sensor-2v85";
+					regulator-min-microvolt = <2850000>;
+					regulator-max-microvolt = <2850000>;
+				};
+
+				ldo7 {
+					regulator-name = "vdd-af-cam1";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo8 {
+					regulator-name = "vdd-rtc";
+					regulator-min-microvolt = <900000>;
+					regulator-max-microvolt = <900000>;
+					regulator-always-on;
+					regulator-boot-on;
+					ti,enable-ldo8-tracking;
+				};
+
+				ldo9 {
+					regulator-name = "vddio-sdmmc-2";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldoln {
+					regulator-name = "hvdd-usb";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldousb {
+					regulator-name = "avdd-usb";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				regen1 {
+					regulator-name = "rail-3v3";
+					regulator-max-microvolt = <3300000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				regen2 {
+					regulator-name = "rail-5v0";
+					regulator-max-microvolt = <5000000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+			    };
+			};
+		};
 	};
 
 	spi at 7000da00 {
@@ -980,6 +1152,16 @@
 			gpio = <&gpio TEGRA_GPIO(K, 1) GPIO_ACTIVE_HIGH>;
 			vin-supply = <&tps65090_dcdc1_reg>;
 		};
+
+		vdd_cam_1v8_reg: regulator at 6 {
+			compatible = "regulator-fixed";
+			reg = <6>;
+			regulator-name = "vdd_cam_1v8_reg";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			enable-active-high;
+			gpio = <&palmas_gpio 6 0>;
+		};
 	};
 
 	sound {
-- 
1.7.1.1



From andrew at lunn.ch  Wed Jul 10 03:37:06 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 10 Jul 2013 09:37:06 +0200
Subject: NSA310 + DT
In-Reply-To: <1a9bcb9094ae695c6707c4835417dd5b@harsszegi.com>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <1a9bcb9094ae695c6707c4835417dd5b@harsszegi.com>
Message-ID: <20130710073706.GA28212@lunn.ch>

> >b.) uart0 is not recognized at all during boot, I cannot see that
> >8250 would recognize the UART at the mmaped area, however the .DTS
> >config seems fine
> >
> >Do you see anything like:
> >
> >Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> >f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
> >console [ttyS0] enabled
> >f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A
> >
> 
> None at all. I only see the first "Serial:" line, then
> nothing else, seems like the UART0 is stucked, badly mapped/initialized
> at that time.

This suggests you are missing SERIAL_OF_PLATFORM.

Try

make kirkwood_defconfig
make

and see if that kernel works any better.

> >c.) LEDs are also not working, this is also strange, as the .DTS
> >seems to be just fine as well.
> >
> >How do you mean not working? Is /sys/class/leds/ empty? Or when you
> >change the brightness value, nothing happens?
> >
> Sorry lame me, wasn't clear again :)
> All the LEDs remain "uninitialized", all
> remains green after bootup, haven't tried setting
> them yet :(

Looking through the patch you pointed out, i think you will find some
work, some don't, and some have the wrong meaning.

We are going to need to add a new DTS file for this board. I can work
on this soon.

   Andrew


From tony at atomide.com  Wed Jul 10 03:50:17 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Jul 2013 00:50:17 -0700
Subject: [PATCH] ARM: omap2: add select of TI_PRIV_EDMA
In-Reply-To: <1373359054-5007-1-git-send-email-olof@lixom.net>
References: <1373359054-5007-1-git-send-email-olof@lixom.net>
Message-ID: <20130710075017.GM5523@atomide.com>

* Olof Johansson <olof at lixom.net> [130709 01:44]:
> "ARM: OMAP: build mach-omap code only if needed" moved around the
> ARCH_OMAP2PLUS stanza, but accidentally dropped the seleciton of
> TI_PRIV_EDMA in the process. Add it back.
> 
> Cc: Arnd Bergmann <arnd at arndb.de>

Acked-by: Tony Lindgren <tony at atomide.com>

> Signed-off-by: Olof Johansson <olof at lixom.net>
> 
> ---
> 
> I noticed the original patch was a bit down in the fixes branch, so
> instead of rebasing I checked this in on top.
> 
> -Olof
> 
>  arch/arm/mach-omap2/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 5c14051..58152b1 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -99,6 +99,7 @@ config ARCH_OMAP2PLUS
>  	select PROC_DEVICETREE if PROC_FS
>  	select SOC_BUS
>  	select SPARSE_IRQ
> +	select TI_PRIV_EDMA
>  	select USE_OF
>  	help
>  	  Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
> -- 
> 1.8.1.192.gc4361b8
> 


From tony at atomide.com  Wed Jul 10 04:02:41 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Jul 2013 01:02:41 -0700
Subject: [GIT PULL] omap fixes for v3.11 merge window
Message-ID: <20130710080241.GN5523@atomide.com>

The following changes since commit ddcf6600b133697adbafd96e080818bdc0dfd028:

  Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging (2013-07-03 19:56:35 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/fixes-for-merge-window

for you to fetch changes up to c24a6ae18abde53b048372b066b93b71b1b91154:

  ARM: OMAP2+: omap2plus_defconfig: Enable appended DTB support (2013-07-04 05:11:57 -0700)

----------------------------------------------------------------
Omap fixes and minor defconfig updates that would be good to
get in before -rc1.

----------------------------------------------------------------
Afzal Mohammed (1):
      ARM: OMAP2+: timer: initialize before using oh_name

Eduardo Valentin (2):
      ARM: OMAP2+: omap2plus_defconfig: enable TI bandgap driver
      ARM: OMAP2+: omap2plus_defconfig: enable DRA752 thermal support by default

Enric Balletbo i Serra (1):
      ARM: OMAP3: igep0020: Set DSS pins in correct mux mode.

Joel Fernandes (1):
      ARM: OMAP2+: Enable TI_EDMA in omap2plus_defconfig

Nishanth Menon (2):
      ARM: OMAP4: sleep: build OMAP4 specific functions only for OMAP4
      ARM: scu: provide inline dummy functions when SCU is not present

Paul Bolle (1):
      ARM: OMAP2+: Remove obsolete Makefile line

Pavel Machek (1):
      ARM: OMAP2+: N900: enable N900-specific drivers even if device tree is enabled

Santosh Shilimkar (1):
      ARM: OMAP5: Enable Cortex A15 errata 798181

Thomas Meyer (1):
      ARM: OMAP2+: Cocci spatch "ptr_ret.spatch"

Tom Rini (1):
      ARM: OMAP2+: omap2plus_defconfig: Enable appended DTB support

Wei Yongjun (1):
      ARM: OMAP2+: devices: remove duplicated include from devices.c

 arch/arm/configs/omap2plus_defconfig   | 15 +++++++++++++++
 arch/arm/include/asm/smp_scu.h         | 13 ++++++++++++-
 arch/arm/mach-omap2/Kconfig            |  1 +
 arch/arm/mach-omap2/Makefile           |  4 ----
 arch/arm/mach-omap2/board-igep0020.c   | 31 +++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/board-rx51-video.c |  2 +-
 arch/arm/mach-omap2/devices.c          |  5 ++---
 arch/arm/mach-omap2/fb.c               |  5 +----
 arch/arm/mach-omap2/gpmc.c             |  2 +-
 arch/arm/mach-omap2/pmu.c              |  5 +----
 arch/arm/mach-omap2/sleep44xx.S        |  6 +++++-
 arch/arm/mach-omap2/timer.c            |  2 +-
 sound/soc/omap/rx51.c                  |  2 +-
 13 files changed, 72 insertions(+), 21 deletions(-)


From sbabic at denx.de  Wed Jul 10 04:10:00 2013
From: sbabic at denx.de (Stefano Babic)
Date: Wed, 10 Jul 2013 10:10:00 +0200
Subject: [PATCH] ARM: dts: imx: add tempmon node for imx6q thermal support
In-Reply-To: <20130710070915.GA12605@S2101-09.ap.freescale.net>
References: <1370330008-5982-1-git-send-email-shawn.guo@linaro.org>
 <1370330226-6030-1-git-send-email-shawn.guo@linaro.org>
 <51DC256D.6040204@denx.de> <20130710070915.GA12605@S2101-09.ap.freescale.net>
Message-ID: <51DD16D8.8070803@denx.de>

Hi Shawn,

On 10/07/2013 09:09, Shawn Guo wrote:

> Address 0x20C8180 is where TEMPMON control registers are - they are
> embedded in ANATOP block, while calibration data is stored in OCOTP fuse
> block.
> 

Thanks, it is clear now.

>> imx_thermal tempmon.7: invalid sensor calibration data
>> imx_thermal tempmon.7: failed to get sensor data
>> imx_thermal: probe of tempmon.7 failed with error -22
> 
> What's your chip revision?  Early revisions may not have the calibration
> data.  TO1.2 should have, I think.

That is the point - on the board I tested there is a T01.0 running.

> 
>> The driver is loaded successfully if I changed the tempdata to point to
>> 020C8180. Not sure if I get the right values from temp1_crit and
>> temp1_input, but no error at the initialisation. Am I missing something ?
> 
> It reads some data but that's not calibration data, so it should not work.
> 
> Also, you need a cpu_cooling fix [1], if you want to play the thermal
> patches on imx6q.

Understood, thanks.

Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================


From geert at linux-m68k.org  Wed Jul 10 04:12:46 2013
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 10 Jul 2013 10:12:46 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130506095124.GA22041@pd.tnic>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130506095124.GA22041@pd.tnic>
Message-ID: <CAMuHMdWH9w5fj6HRXi+9QcBJym4dukAFsPVGZVqSSk3yTZJUcA@mail.gmail.com>

On Mon, May 6, 2013 at 11:51 AM, Borislav Petkov <bp at alien8.de> wrote:
> On Mon, May 06, 2013 at 05:42:55PM +0900, Kyungsik Lee wrote:
>> LZ4 has been updated with LZ4 Streaming Format specification(v1.3).
>> lz4demo is replaced by lz4c. lz4c supports both the new streaming and
>> legacy format with -l option.
>>
>> This patch makes use of lz4c to support legacy format which is
>> used for LZ4 De/compression in the linux kernel.
>>
>> Link: https://code.google.com/p/lz4/source/checkout
>> Signed-off-by: Kyungsik Lee <kyungsik.lee at lge.com>
>> Cc: "H. Peter Anvin" <hpa at zytor.com>
>> Cc: Ingo Molnar <mingo at elte.hu>
>> Cc: Thomas Gleixner <tglx at linutronix.de>
>> Cc: Russell King <rmk at arm.linux.org.uk>
>> Cc: Borislav Petkov <bp at alien8.de>
>> Cc: Florian Fainelli <florian at openwrt.org>
>> Cc: Yann Collet <yann.collet.73 at gmail.com>
>> Cc: Chanho Min <chanho.min at lge.com>
>> ---
>>  scripts/Makefile.lib | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
>> index a0ab6d7..c9bfbb0 100644
>> --- a/scripts/Makefile.lib
>> +++ b/scripts/Makefile.lib
>> @@ -313,7 +313,7 @@ cmd_lzo = (cat $(filter-out FORCE,$^) | \
>>
>>  quiet_cmd_lz4 = LZ4     $@
>>  cmd_lz4 = (cat $(filter-out FORCE,$^) | \
>> -     lz4demo -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
>> +     lz4c -l -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
>
> You probably want to check for the presence of lz4c on the system and
> bail with an informative message if absent.

Yep, x86_64-randconfig
(http://kisskb.ellerman.id.au/kisskb/buildresult/9110794/):

  LZ4     arch/x86/boot/compressed/vmlinux.bin.lz4
/bin/sh: lz4c: command not found

Also, several of the blackfin builds started failing due to a
compression-related
issue, e.g. http://kisskb.ellerman.id.au/kisskb/buildresult/9101322/:

  UIMAGE  arch/blackfin/boot/uImage.lzma

Invalid Compression Type - valid names are: none, bzip2, gzip
Usage: /usr/local/bin/mkimage -l image
          -l ==> list image header information
       /usr/local/bin/mkimage [-x] -A arch -O os -T type -C comp -a
addr -e ep -n name -d data_file[:data_file...] image
          -A ==> set architecture to 'arch'
          -O ==> set operating system to 'os'
          -T ==> set image type to 'type'
          -C ==> set compression type 'comp'
          -a ==> set load address to 'addr' (hex)
          -e ==> set entry point to 'ep' (hex)
          -n ==> set image name to 'name'
          -d ==> use image data from 'datafile'
          -x ==> set XIP (execute in place)
make[2]: *** [arch/blackfin/boot/uImage.lzma] Error 1

May be unrelated, though.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From george.cherian at ti.com  Wed Jul 10 04:14:42 2013
From: george.cherian at ti.com (George Cherian)
Date: Wed, 10 Jul 2013 13:44:42 +0530
Subject: [PATCH v3] arm: dts: AM43x: Add usb DT nodes for AM4372
Message-ID: <1373444082-4169-1-git-send-email-george.cherian@ti.com>

This patch adds
	- HS USB nodes
	- phy nodes
	- usb control module nodes.

Signed-off-by: George Cherian <george.cherian at ti.com>
---

changes from v2
change synopsis to snps 
use simple node names
add both USB and PHY instances
add usbctrl node 

changes from v1
renamed synopsis to snps
removed flag tx-fifo-resize

 arch/arm/boot/dts/am4372.dtsi | 58 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..37f196f 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,63 @@
 			compatible = "ti,am4372-counter32k","ti,omap-counter32k";
 			reg = <0x44e86000 0x40>;
 		};
+
+		phy1: usbphy1 {
+			compatible = "ti,am4372-usb2";
+			#phy-cells = <0>;
+			id = <0>;
+			status = "disabled";
+		};
+
+		phy2: usbphy2 {
+			compatible = "ti,am4372-usb2";
+			#phy-cells = <0>;
+			id = <1>;
+			status = "disabled";
+		};
+
+		usbctrl: omap-control-usb at 44e10620 {
+			compatible = "ti,omap-control-usb";
+			reg = <0x44e10620 0x10>;
+			reg-names = "control_dev_conf";
+			ti,type = <3>;
+			status = "disabled";
+		};
+
+		usb1: am4372_dwc3 at 48380000 {
+			status = "disabled";
+			compatible = "ti,am4372-dwc3";
+			reg = <0x48380000 0x200>;
+			interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			utmi-mode = <1>;
+			ranges;
+			dwc3 at 48390000 {
+				compatible = "snps,dwc3";
+				reg = <0x48390000 0xd000>;
+				interrupts = <GIC_SPI  168 IRQ_TYPE_LEVEL_HIGH>;
+				phys = <&phy1>;
+				phy-names = "am4372-usb1";
+			};
+		};
+
+		usb2: am4372_dwc3 at 483c0000 {
+			status = "disabled";
+			compatible = "ti,am4372-dwc3";
+			reg = <0x483c0000 0x200>;
+			interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			utmi-mode = <1>;
+			ranges;
+			dwc3 at 483d0000 {
+				compatible = "snps,dwc3";
+				reg = <0x483d0000 0xd000>;
+				interrupts = <GIC_SPI  174 IRQ_TYPE_LEVEL_HIGH>;
+				phys = <&phy2>;
+				phy-names = "am4372-usb2";
+			};
+		};
 	};
 };
-- 
1.8.1.4



From haojian.zhuang at gmail.com  Wed Jul 10 04:19:46 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Wed, 10 Jul 2013 16:19:46 +0800
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <20130709124900.GG11908@titan.lakedaemon.net>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
Message-ID: <CAN1soZxiOh6TpbUOCUzK8gNwmvjbT3ihkUWaw8tuZ7md+NVA2g@mail.gmail.com>

On Tue, Jul 9, 2013 at 8:49 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> Neil,
>
> On Tue, Jul 09, 2013 at 02:42:44PM +0800, Neil Zhang wrote:
>> The documented vendor prefix for Marvell is 'marvell', not 'mrvl', so
>> let's change it.
>>
>> Signed-off-by: Neil Zhang <zhangwm at marvell.com>
>> ---
>>  .../devicetree/bindings/arm/mrvl/intc.txt          |   16 +++---
>>  .../devicetree/bindings/arm/mrvl/mrvl.txt          |    6 +-
>>  .../devicetree/bindings/arm/mrvl/timer.txt         |    4 +-
>>  Documentation/devicetree/bindings/i2c/i2c-pxa.txt  |   14 +++---
>>  .../devicetree/bindings/mmc/sdhci-pxa.txt          |    8 ++--
>>  .../devicetree/bindings/rtc/sa1100-rtc.txt         |    4 +-
>>  .../devicetree/bindings/serial/mrvl-serial.txt     |    2 +-
>>  arch/arm/boot/dts/mmp2-brownstone.dts              |    2 +-
>>  arch/arm/boot/dts/mmp2.dtsi                        |   56 ++++++++++----------
>>  arch/arm/boot/dts/pxa168-aspenite.dts              |    2 +-
>>  arch/arm/boot/dts/pxa168.dtsi                      |   24 ++++----
>>  arch/arm/boot/dts/pxa2xx.dtsi                      |   16 +++---
>>  arch/arm/boot/dts/pxa3xx.dtsi                      |    2 +-
>>  arch/arm/boot/dts/pxa910-dkb.dts                   |    2 +-
>>  arch/arm/boot/dts/pxa910.dtsi                      |   27 +++++-----
>>  arch/arm/mach-mmp/irq.c                            |   16 +++---
>>  arch/arm/mach-mmp/mmp-dt.c                         |   28 +++++-----
>>  arch/arm/mach-mmp/mmp2-dt.c                        |   16 +++---
>>  arch/arm/mach-mmp/time.c                           |    2 +-
>>  arch/arm/mach-pxa/pxa-dt.c                         |   14 +++---
>>  drivers/i2c/busses/i2c-pxa.c                       |   10 ++--
>>  drivers/mmc/host/sdhci-pxav2.c                     |    4 +-
>>  drivers/mmc/host/sdhci-pxav3.c                     |    4 +-
>>  drivers/rtc/rtc-sa1100.c                           |    4 +-
>>  drivers/tty/serial/pxa.c                           |    4 +-
>>  25 files changed, 144 insertions(+), 143 deletions(-)
>
> I agree with the need to change, however, this has been in the binding
> documentation since v3.5.  I wish we had caught this when we decided
> against using stock ticker symbols (not all stock markets use
> alphabetical abbreviated names, not all companies are listed on any
> stock exchange).
>
> To do this properly, the drivers are going to have to be compatible with
> the old and the new names, and the binding docs updated to reflect the
> legacy name and the preferred name.
>

It's better to only use the new names.

Neil,

Could you split your patches according to different subsystem?

Regards
Haojian


From khilman at linaro.org  Wed Jul 10 04:22:42 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Wed, 10 Jul 2013 09:22:42 +0100
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130708133512.GD31221@arwen.pp.htv.fi> (Felipe Balbi's message
 of "Mon, 8 Jul 2013 16:35:12 +0300")
References: <51D59146.3070002@newflow.co.uk> <51D59C0E.8080003@newflow.co.uk>
 <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi>
Message-ID: <87mwpuakod.fsf@linaro.org>

Felipe Balbi <balbi at ti.com> writes:

> Hi,
>
> On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
>> >>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>> >>>>>> of -1 for the serial driver?
>> >>>>>>
>> >>>>>
>> >>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>> >>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>> >>>
>> >>> OK
>> >>
>> >> Issue 2: Causing boot to stop when serial driver is initialized.
>> >> (After Issue 1 is fixed)
>> >>
>> >> I could narrow this down to the change done to return -EINVAL
>> >> instead of 0 in serial_omap_get_context_loss_count() as part of
>> >> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
>> >> Fix device tree based PM runtime"
>> >>
>> >> What this change in turn seems to do is cause a
>> >> serial_omap_restore_context() to get called as part of
>> >> serial_omap_runtime_resume() which was not the case when
>> >> serial_omap_get_context_loss_count() returned 0
>> >>
>> >> from serial_omap_runtime_resume():
>> >> -----
>> >>         int loss_cnt = serial_omap_get_context_loss_count(up);
>> >>
>> >>         if (loss_cnt < 0) {
>> >>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>> >>                         loss_cnt);
>> >>                 serial_omap_restore_context(up);
>> >>         } else if (up->context_loss_cnt != loss_cnt) {
>> >>                 serial_omap_restore_context(up);
>> >>         }
>> >> -----
>> >>
>> >> I am still working on why a serial_omap_restore_context() could
>> >> have caused console to die. I will work with Sourav on this and
>> >> post the fixes for both issue 1 and issue2 once its clear on whats
>> >> really causing issue 2.
>> > 
>> > That's because we don't have the omap specific pdata callbacks for
>> > context loss any longer. We may be able to detect when the context
>> > was really lost in the serial driver, and only then call the
>> > serial_omap_restore_context().
>> 
>> Right, but calling serial_omap_restore_context() even when the context
>> is not lost, should not ideally cause an issue.
>
> it does in one condition. If context hasn't been saved before. And that
> can happen in the case of wrong pm runtime status for that device.
>
> Imagine the device is marked as suspended even though it's fully enabled
> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> your context structure is all zeroes (context has never been saved
> before) then when you call pm_runtime_get_sync() on probe() your
> ->runtime_resume() will get called, which will restore context,
> essentially undoing anything which was configured by u-boot.
>
> Am I missing something ?

You're right, the _set_active() is crucial in the case when we prevent
the console UART from idling during boot (though that shouldn't be
happening in mainline unless the fix for "Issue 1" is done.)

Kevin


From richard.zhuhongxing at gmail.com  Wed Jul 10 04:35:52 2013
From: richard.zhuhongxing at gmail.com (Richard Zhu)
Date: Wed, 10 Jul 2013 16:35:52 +0800
Subject: [PATCH v4 0/3] ahci: enable ahci sata support on imx6q
Message-ID: <1373445355-11453-1-git-send-email-Hong-Xing.Zhu@freescale.com>

V4: add imx6q specific ahci sata support
  Thanks for the review comments provided by Sascha, and Alexander.
  - Use the private data and keep a pointer to the PHY clock.
  - Don't use the global platform device variable, because that
  it would make the driver broken for mutiple instances.
  - Don't do the "writel" with assignment.
  - Other minor changes, such as print the error code when printing
  error message, use a u32 type to store readl results, and so on.

v3: http://www.spinics.net/lists/linux-ide/msg45688.html
  - Keep arch/arm and ahci_platform driver clean.
  - Add the sata_imx standalone driver contained all the
  specific setup
  - Add the release function, support the loadable module
  driver.
  - Tested on imx6q sd board.

v2: http://www.spinics.net/lists/linux-ide/msg45666.html 
 - Setup standalone imx ahci sata driver, because of
 the misalignments of the bits definition of the HBA register.
 - Replace the node by the label in the board dts.
 - 

v1: http://www.spinics.net/lists/linux-ide/msg45581.html
 - add imx6q specific ahci sata support to arch/arm/mach-imx/mach-imx6q.c

These patches is based on imx/dt branch of
"http://git.linaro.org/git-ro/people/shawnguo/linux-2.6.git"

[v4 1/3] ARM: dtsi: enable ahci sata on imx6q platforms
[v4 2/3] ARM: imx6q: update the sata bits definitions of gpr13
[v4 3/3] sata: imx: add ahci sata support on imx platforms

arch/arm/boot/dts/imx6q-sabreauto.dts       |    4 +
arch/arm/boot/dts/imx6q-sabrelite.dts       |    4 +
arch/arm/boot/dts/imx6q-sabresd.dts         |    4 +
arch/arm/boot/dts/imx6q.dtsi                |    9 +
drivers/ata/Kconfig                         |    9 +
drivers/ata/Makefile                        |    1 +
drivers/ata/sata_imx.c                      |  237 +++++++++++++++++++++++++++
include/linux/mfd/syscon/imx6q-iomuxc-gpr.h |  121 ++++++++++----
8 files changed, 352 insertions(+), 37 deletions(-)



From tibor at harsszegi.com  Wed Jul 10 04:42:52 2013
From: tibor at harsszegi.com (tibor at harsszegi.com)
Date: Wed, 10 Jul 2013 10:42:52 +0200
Subject: NSA310 + DT
In-Reply-To: <20130710062333.GE26223@lunn.ch>
References: <51DC564A.8050002@harsszegi.com>
 <20130709193605.GC26223@lunn.ch> <20130709202143.GD26223@lunn.ch>
 <2544f179ed4349545a25aa60d52a664a@harsszegi.com>
 <20130710062333.GE26223@lunn.ch>
Message-ID: <b8ae2a5db1f12269d523e4f2d0356e67@harsszegi.com>

Hello,

> Hello guys,
> 
> >Hi Tibor
> >
> >Which NSA310 do you actually have? Apparently there are actually two
> >variants:
> >
> >http://zyxel.nas-central.org/wiki/Category:NSA-310
> >
> >It could be yours is actually the rebranded TDC Homedisk. If so, we
> >should add a new .dts file for it.
> >
> >Andrew
> 
> Well that's a good one. Hohestly have zero idea :(
> 
> Hi Tibor
> 
> How does it compare to the pictures on the website?
> 

I have the one on the topmost picture, not the one labelled as "TDC".
Cheers,

Tibor


From tibor at harsszegi.com  Wed Jul 10 04:43:48 2013
From: tibor at harsszegi.com (tibor at harsszegi.com)
Date: Wed, 10 Jul 2013 10:43:48 +0200
Subject: NSA310 + DT
In-Reply-To: <20130710073706.GA28212@lunn.ch>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <1a9bcb9094ae695c6707c4835417dd5b@harsszegi.com>
 <20130710073706.GA28212@lunn.ch>
Message-ID: <612950b985ba081d587637b2c728f5a6@harsszegi.com>

Hi,

> >b.) uart0 is not recognized at all during boot, I cannot see that
> >8250 would recognize the UART at the mmaped area, however the .DTS
> >config seems fine
> >
> >Do you see anything like:
> >
> >Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> >f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
> >console [ttyS0] enabled
> >f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A
> >
> 
> None at all. I only see the first "Serial:" line, then
> nothing else, seems like the UART0 is stucked, badly mapped/initialized
> at that time.
> 
> This suggests you are missing SERIAL_OF_PLATFORM.
> 
> Try
> 
> make kirkwood_defconfig
> make
> 
> and see if that kernel works any better.
> 

Aok, will keep you posted.
Thanks a lot!!
Cheers,
t.


From thomas.abraham at linaro.org  Wed Jul 10 04:47:29 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Wed, 10 Jul 2013 14:17:29 +0530
Subject: [PATCH v2 0/6] Convert S3C2416 ad S3C2443 to common clock
 framework
In-Reply-To: <201307100057.06061.heiko@sntech.de>
References: <201307100057.06061.heiko@sntech.de>
Message-ID: <CAJuYYwT73KnjFmX0+r+b1_-tggPft=Fko9oHaL3yVUdY7ov5=Q@mail.gmail.com>

On 10 July 2013 04:27, Heiko St?bner <heiko at sntech.de> wrote:
> This series provides a clock driver for s3c2416, s3c2443 and s3c2450, which
> share a common clock tree, but differ fundamentally from earlier s3c24xx
> SoCs, and converts the mentioned SoCs to use it.
>
> The clock driver itself follows the same scheme established by all other
> Samsung clock drivers.
>
> It depends on the pwm cleanup series from Tomasz Figa, which gets rid of the
> declarations of the pwm-internal clocks.
>
> Test on both non-dt and dt s3c2416.
>
> Heiko Stuebner (6):
>   clk: samsung: move common plls registration into separate function
>   clk: samsung: fix error handling in pll register functions
>   clk: samsung: add plls used in s3c2416 and s3c2443
>   ARM: S3C24XX: enable legacy clock code only when SAMSUNG_CLOCK
>     selected
>   clk: samsung: add clock-driver for s3c2416, s3c2443 and s3c2450
>   ARM: S3C24XX: Convert s3c2416 and s3c2443 to common clock framework
>
>  .../bindings/clock/samsung,s3c2443-clock.txt       |   48 ++
>  arch/arm/boot/dts/s3c2416-smdk2416.dts             |    7 +
>  arch/arm/boot/dts/s3c2416.dtsi                     |   42 ++
>  arch/arm/mach-s3c24xx/Kconfig                      |   14 +-
>  arch/arm/mach-s3c24xx/Makefile                     |    5 +-
>  arch/arm/mach-s3c24xx/clock-s3c2416.c              |  171 -----
>  arch/arm/mach-s3c24xx/clock-s3c2443.c              |  212 ------
>  arch/arm/mach-s3c24xx/common-s3c2443.c             |  675 --------------------
>  arch/arm/mach-s3c24xx/common.c                     |   20 +-
>  arch/arm/mach-s3c24xx/common.h                     |    8 +
>  arch/arm/mach-s3c24xx/mach-s3c2416-dt.c            |   45 +-
>  arch/arm/mach-s3c24xx/mach-smdk2416.c              |    9 +-
>  arch/arm/mach-s3c24xx/mach-smdk2443.c              |    9 +-
>  drivers/clk/Kconfig                                |    1 +
>  drivers/clk/samsung/Kconfig                        |    2 +
>  drivers/clk/samsung/Makefile                       |    1 +
>  drivers/clk/samsung/clk-pll.c                      |  374 +++++++++--
>  drivers/clk/samsung/clk-pll.h                      |    8 +
>  drivers/clk/samsung/clk-s3c2443.c                  |  422 ++++++++++++
>  include/dt-bindings/clock/samsung,s3c2443-clock.h  |   96 +++
>  20 files changed, 998 insertions(+), 1171 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt
>  delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2416.c
>  delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2443.c
>  delete mode 100644 arch/arm/mach-s3c24xx/common-s3c2443.c
>  create mode 100644 drivers/clk/samsung/Kconfig
>  create mode 100644 drivers/clk/samsung/clk-s3c2443.c
>  create mode 100644 include/dt-bindings/clock/samsung,s3c2443-clock.h
>
> --
> 1.7.10.4
>

Thanks for consolidating pll registrations.
For patches 1 to 3:
Reviewed-by: Thomas Abraham <thomas.abraham at linaro.org>


From jonas.jensen at gmail.com  Wed Jul 10 04:51:03 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 10 Jul 2013 10:51:03 +0200
Subject: [PATCH] dmaengine: Add MOXA ART DMA engine driver
Message-ID: <1373446263-7772-1-git-send-email-jonas.jensen@gmail.com>

Add dmaengine driver for MOXA ART SoCs based on virt_dma.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130703
    
    The MMC driver I plan to submit next can use this
    (falls back to PIO if unavailable).
    
    Nothing else uses DMA on UC-7112-LX.

 drivers/dma/Kconfig      |   9 +
 drivers/dma/Makefile     |   1 +
 drivers/dma/moxart-dma.c | 473 +++++++++++++++++++++++++++++++++++++++++++++++
 drivers/dma/moxart-dma.h | 188 +++++++++++++++++++
 4 files changed, 671 insertions(+)
 create mode 100644 drivers/dma/moxart-dma.c
 create mode 100644 drivers/dma/moxart-dma.h

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..d4ba42b 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -300,6 +300,15 @@ config DMA_JZ4740
 	select DMA_ENGINE
 	select DMA_VIRTUAL_CHANNELS
 
+config MOXART_DMA
+	tristate "MOXART DMA support"
+	depends on ARCH_MOXART
+	select DMA_ENGINE
+	select DMA_VIRTUAL_CHANNELS
+	default n
+	help
+	  Enable support for the MOXA ART SoC DMA controller.
+
 config DMA_ENGINE
 	bool
 
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 5e0f2ef..470c11b 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_MMP_TDMA) += mmp_tdma.o
 obj-$(CONFIG_DMA_OMAP) += omap-dma.o
 obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o
 obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
+obj-$(CONFIG_MOXART_DMA) += moxart-dma.o
diff --git a/drivers/dma/moxart-dma.c b/drivers/dma/moxart-dma.c
new file mode 100644
index 0000000..3f1e771
--- /dev/null
+++ b/drivers/dma/moxart-dma.c
@@ -0,0 +1,473 @@
+/*
+ * MOXA ART SoCs DMA Engine support.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/irq.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+
+#include <asm/cacheflush.h>
+
+#include "dmaengine.h"
+#include "virt-dma.h"
+#include "moxart-dma.h"
+
+static DEFINE_SPINLOCK(dma_lock);
+
+struct moxart_dma_chan {
+	struct virt_dma_chan		vchan;
+	int				ch_num;
+	bool				allocated;
+	int				error_flag;
+	struct moxart_dma_reg		*reg;
+	void				(*callback)(void *param);
+	void				*callback_param;
+	struct completion		dma_complete;
+	struct dma_slave_config		cfg;
+	struct dma_async_tx_descriptor	tx_desc;
+};
+
+struct moxart_dma_container {
+	int			ctlr;
+	struct dma_device	dma_slave;
+	struct moxart_dma_chan	slave_chans[APB_DMA_MAX_CHANNEL];
+};
+
+struct moxart_dma_container *mdc;
+
+static struct device *chan2dev(struct dma_chan *chan)
+{
+	return &chan->dev->device;
+}
+
+static inline struct moxart_dma_container
+*to_moxart_dma_container(struct dma_device *d)
+{
+	return container_of(d, struct moxart_dma_container, dma_slave);
+}
+
+static inline struct moxart_dma_chan *to_moxart_dma_chan(struct dma_chan *c)
+{
+	return container_of(c, struct moxart_dma_chan, vchan.chan);
+}
+
+static int moxart_terminate_all(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+
+	dev_dbg(chan2dev(chan), "%s: mchan=%p\n", __func__, mchan);
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.ul &= ~(APB_DMA_ENABLE | APB_DMA_FIN_INT_EN | APB_DMA_ERR_INT_EN);
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return 0;
+}
+
+static int moxart_slave_config(struct dma_chan *chan,
+			       struct dma_slave_config *cfg)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+	unsigned int data_width, data_inc;
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	memcpy(&mchan->cfg, cfg, sizeof(mchan->cfg));
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.bits.burst = APB_DMAB_BURST_MODE;
+
+	switch (mchan->cfg.src_addr_width) {
+	case DMA_SLAVE_BUSWIDTH_1_BYTE:
+		data_width = APB_DMAB_DATA_WIDTH_1;
+		data_inc = APB_DMAB_DEST_INC_1_4;
+		break;
+	case DMA_SLAVE_BUSWIDTH_2_BYTES:
+		data_width = APB_DMAB_DATA_WIDTH_2;
+		data_inc = APB_DMAB_DEST_INC_2_8;
+		break;
+	default:
+		data_width = APB_DMAB_DATA_WIDTH_4;
+		data_inc = APB_DMAB_DEST_INC_4_16;
+		break;
+	}
+
+	if (mchan->cfg.direction == DMA_MEM_TO_DEV) {
+		mcfg.bits.data_width = data_width;
+		mcfg.bits.dest_sel = APB_DMAB_DEST_APB;
+		mcfg.bits.dest_inc = APB_DMAB_DEST_INC_0;
+		mcfg.bits.source_sel = APB_DMAB_SOURCE_AHB;
+		mcfg.bits.source_inc = data_inc;
+
+		mcfg.bits.dest_req_no = mchan->cfg.slave_id;
+		mcfg.bits.source_req_no = 0;
+	} else {
+		mcfg.bits.data_width = data_width;
+		mcfg.bits.dest_sel = APB_DMAB_SOURCE_AHB;
+		mcfg.bits.dest_inc = data_inc;
+		mcfg.bits.source_sel = APB_DMAB_DEST_APB;
+		mcfg.bits.source_inc = APB_DMAB_DEST_INC_0;
+
+		mcfg.bits.dest_req_no = 0;
+		mcfg.bits.source_req_no = mchan->cfg.slave_id;
+	}
+
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return 0;
+}
+
+static int moxart_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
+			  unsigned long arg)
+{
+	int ret = 0;
+	struct dma_slave_config *config;
+
+	switch (cmd) {
+	case DMA_TERMINATE_ALL:
+		moxart_terminate_all(chan);
+		break;
+	case DMA_SLAVE_CONFIG:
+		config = (struct dma_slave_config *)arg;
+		ret = moxart_slave_config(chan, config);
+		break;
+	default:
+		ret = -ENOSYS;
+	}
+
+	return ret;
+}
+
+static dma_cookie_t moxart_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(tx->chan);
+	dma_cookie_t cookie;
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+
+	mchan->callback = tx->callback;
+	mchan->callback_param = tx->callback_param;
+	mchan->error_flag = 0;
+
+	dev_dbg(chan2dev(tx->chan), "%s: mchan=%p mchan->ch_num=%d mchan->reg=%p\n",
+		__func__, mchan, mchan->ch_num, mchan->reg);
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	cookie = dma_cookie_assign(tx);
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.ul |= (APB_DMA_FIN_INT_EN | APB_DMA_ERR_INT_EN);
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return cookie;
+}
+
+static struct dma_async_tx_descriptor
+*moxart_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
+		      unsigned int sg_len,
+		      enum dma_transfer_direction direction,
+		      unsigned long tx_flags, void *context)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	unsigned long flags;
+	union moxart_dma_reg_cfg mcfg;
+	unsigned int size, adr_width;
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	if (direction == DMA_MEM_TO_DEV) {
+		writel(virt_to_phys((void *)sg_dma_address(&sgl[0])),
+		       &mchan->reg->source_addr);
+		writel(mchan->cfg.dst_addr, &mchan->reg->dest_addr);
+		adr_width = mchan->cfg.src_addr_width;
+	} else {
+		writel(mchan->cfg.src_addr, &mchan->reg->source_addr);
+		writel(virt_to_phys((void *)sg_dma_address(&sgl[0])),
+		       &mchan->reg->dest_addr);
+		adr_width = mchan->cfg.dst_addr_width;
+	}
+
+	size = sgl->length >> adr_width;
+
+	/*
+	 * size is 4 on 64 bytes copied, i.e. once cycle copies 16 bytes
+	 * ( when data_width == APB_DMAB_DATA_WIDTH_4 )
+	 */
+	writel(size, &mchan->reg->cycles);
+
+	dev_dbg(chan2dev(chan), "%s: set %d DMA cycles (sgl->length=%d adr_width=%d)\n",
+		__func__, size, sgl->length, adr_width);
+
+	dev_dbg(chan2dev(chan), "%s: mcfg.ul=%x read from &mchan->reg->cfg.ul=%x\n",
+		__func__, mcfg.ul, (unsigned int)&mchan->reg->cfg.ul);
+
+	dma_async_tx_descriptor_init(&mchan->tx_desc, chan);
+	mchan->tx_desc.tx_submit = moxart_tx_submit;
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return &mchan->tx_desc;
+}
+
+static struct platform_driver moxart_driver;
+
+bool moxart_filter_fn(struct dma_chan *chan, void *param)
+{
+	if (chan->device->dev->driver == &moxart_driver.driver) {
+		struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+		unsigned int ch_req = *(unsigned int *)param;
+		dev_dbg(chan2dev(chan), "%s: mchan=%p ch_req=%d mchan->ch_num=%d\n",
+			__func__, mchan, ch_req, mchan->ch_num);
+		return ch_req == mchan->ch_num;
+	} else {
+		dev_dbg(chan2dev(chan), "%s: device not registered to this DMA engine\n",
+			__func__);
+		return false;
+	}
+}
+EXPORT_SYMBOL(moxart_filter_fn);
+
+static int moxart_alloc_chan_resources(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	int i;
+	bool found = false;
+
+	for (i = 0; i < APB_DMA_MAX_CHANNEL; i++) {
+		if (i == mchan->ch_num
+			&& !mchan->allocated) {
+			dev_dbg(chan2dev(chan), "%s: allocating channel #%d\n",
+				__func__, mchan->ch_num);
+			mchan->allocated = true;
+			found = true;
+			break;
+		}
+	}
+
+	if (!found)
+		return -ENODEV;
+
+	return 0;
+}
+
+static void moxart_free_chan_resources(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+
+	mchan->allocated = false;
+
+	dev_dbg(chan2dev(chan), "%s: freeing channel #%u\n",
+		__func__, mchan->ch_num);
+}
+
+static void moxart_issue_pending(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+
+	dev_dbg(chan2dev(chan), "%s: mchan=%p\n", __func__, mchan);
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.ul |= APB_DMA_ENABLE;
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+}
+
+static enum dma_status moxart_tx_status(struct dma_chan *chan,
+					dma_cookie_t cookie,
+					struct dma_tx_state *txstate)
+{
+	enum dma_status ret;
+
+	ret = dma_cookie_status(chan, cookie, txstate);
+	if (ret == DMA_SUCCESS || !txstate)
+		return ret;
+
+	return ret;
+}
+
+static void moxart_dma_init(struct dma_device *dma, struct device *dev)
+{
+	dma->device_prep_slave_sg		= moxart_prep_slave_sg;
+	dma->device_alloc_chan_resources	= moxart_alloc_chan_resources;
+	dma->device_free_chan_resources		= moxart_free_chan_resources;
+	dma->device_issue_pending		= moxart_issue_pending;
+	dma->device_tx_status			= moxart_tx_status;
+	dma->device_control			= moxart_control;
+	dma->dev				= dev;
+
+	INIT_LIST_HEAD(&dma->channels);
+}
+
+static irqreturn_t moxart_dma_interrupt(int irq, void *devid)
+{
+	struct device *dev = devid;
+	struct moxart_dma_chan *mchan = &mdc->slave_chans[0];
+	unsigned int i;
+	union moxart_dma_reg_cfg mcfg;
+
+	dev_dbg(dev, "%s\n", __func__);
+
+	for (i = 0; i < APB_DMA_MAX_CHANNEL; i++, mchan++) {
+		if (mchan->allocated) {
+			mcfg.ul = readl(&mchan->reg->cfg.ul);
+			if (mcfg.ul & APB_DMA_FIN_INT_STS) {
+				mcfg.ul &= ~APB_DMA_FIN_INT_STS;
+				dma_cookie_complete(&mchan->tx_desc);
+			}
+			if (mcfg.ul & APB_DMA_ERR_INT_STS) {
+				mcfg.ul &= ~APB_DMA_ERR_INT_STS;
+				mchan->error_flag = 1;
+			}
+			if (mchan->callback) {
+				dev_dbg(dev, "%s: call callback for mchan=%p\n",
+					__func__, mchan);
+				mchan->callback(mchan->callback_param);
+			}
+			mchan->error_flag = 0;
+			writel(mcfg.ul, &mchan->reg->cfg.ul);
+		}
+	}
+
+	return IRQ_HANDLED;
+}
+
+static struct irqaction moxart_dma_irq = {
+	.name       = "moxart-dma-engine",
+	.flags      = IRQF_DISABLED,
+	.handler    = moxart_dma_interrupt,
+};
+
+static int moxart_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct resource res_dma;
+	static void __iomem *dma_base_addr;
+	int ret, i;
+	unsigned int irq;
+	struct moxart_dma_chan *mchan;
+
+	mdc = devm_kzalloc(dev, sizeof(*mdc), GFP_KERNEL);
+	if (!mdc) {
+		dev_err(dev, "can't allocate DMA container\n");
+		return -ENOMEM;
+	}
+
+	ret = of_address_to_resource(node, 0, &res_dma);
+	if (ret) {
+		dev_err(dev, "can't get DMA base resource\n");
+		return ret;
+	}
+
+	irq = irq_of_parse_and_map(node, 0);
+
+	dma_base_addr = devm_ioremap_resource(dev, &res_dma);
+	if (IS_ERR(dma_base_addr)) {
+		dev_err(dev, "devm_ioremap_resource failed\n");
+		return PTR_ERR(dma_base_addr);
+	}
+
+	mdc->ctlr = pdev->id;
+
+	dma_cap_zero(mdc->dma_slave.cap_mask);
+	dma_cap_set(DMA_SLAVE, mdc->dma_slave.cap_mask);
+
+	moxart_dma_init(&mdc->dma_slave, dev);
+
+	mchan = &mdc->slave_chans[0];
+	for (i = 0; i < APB_DMA_MAX_CHANNEL; i++, mchan++) {
+		mchan->ch_num = i;
+		mchan->reg = (struct moxart_dma_reg *)(dma_base_addr + 0x80
+			     + i * sizeof(struct moxart_dma_reg));
+		mchan->callback = NULL;
+		mchan->allocated = 0;
+		mchan->callback_param = NULL;
+		vchan_init(&mchan->vchan, &mdc->dma_slave);
+		dev_dbg(dev, "%s: mchans[%d]: mchan->ch_num=%d mchan->reg=%p\n",
+			__func__, i, mchan->ch_num, mchan->reg);
+	}
+
+	ret = dma_async_device_register(&mdc->dma_slave);
+	platform_set_drvdata(pdev, mdc);
+
+	moxart_dma_irq.dev_id = dev;
+	setup_irq(irq, &moxart_dma_irq);
+
+	dev_dbg(dev, "%s: IRQ=%d\n", __func__, irq);
+
+	return ret;
+}
+
+static int moxart_remove(struct platform_device *pdev)
+{
+	struct moxart_dma_container *m = dev_get_drvdata(&pdev->dev);
+	dma_async_device_unregister(&m->dma_slave);
+	return 0;
+}
+
+static const struct of_device_id moxart_dma_match[] = {
+	{ .compatible = "moxa,moxart-dma" },
+	{ }
+};
+
+static struct platform_driver moxart_driver = {
+	.probe	= moxart_probe,
+	.remove	= moxart_remove,
+	.driver = {
+		.name		= "moxart-dma-engine",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_dma_match,
+	},
+};
+
+static int moxart_init(void)
+{
+	return platform_driver_register(&moxart_driver);
+}
+subsys_initcall(moxart_init);
+
+static void __exit moxart_exit(void)
+{
+	platform_driver_unregister(&moxart_driver);
+}
+module_exit(moxart_exit);
+
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
+MODULE_DESCRIPTION("MOXART DMA engine driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/dma/moxart-dma.h b/drivers/dma/moxart-dma.h
new file mode 100644
index 0000000..358c006
--- /dev/null
+++ b/drivers/dma/moxart-dma.h
@@ -0,0 +1,188 @@
+/*
+ * MOXA ART SoCs DMA Engine support.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __DMA_MOXART_H
+#define __DMA_MOXART_H
+
+#define APB_DMA_MAX_CHANNEL			4
+
+union moxart_dma_reg_cfg {
+
+#define APB_DMA_ENABLE				(1<<0)
+#define APB_DMA_FIN_INT_STS			(1<<1)
+#define APB_DMA_FIN_INT_EN			(1<<2)
+#define APB_DMA_BURST_MODE			(1<<3)
+#define APB_DMA_ERR_INT_STS			(1<<4)
+#define APB_DMA_ERR_INT_EN			(1<<5)
+#define APB_DMA_SOURCE_AHB			(1<<6)
+#define APB_DMA_SOURCE_APB			0
+#define APB_DMA_DEST_AHB			(1<<7)
+#define APB_DMA_DEST_APB			0
+#define APB_DMA_SOURCE_INC_0			0
+#define APB_DMA_SOURCE_INC_1_4			(1<<8)
+#define APB_DMA_SOURCE_INC_2_8			(2<<8)
+#define APB_DMA_SOURCE_INC_4_16			(3<<8)
+#define APB_DMA_SOURCE_DEC_1_4			(5<<8)
+#define APB_DMA_SOURCE_DEC_2_8			(6<<8)
+#define APB_DMA_SOURCE_DEC_4_16			(7<<8)
+#define APB_DMA_SOURCE_INC_MASK			(7<<8)
+#define APB_DMA_DEST_INC_0			0
+#define APB_DMA_DEST_INC_1_4			(1<<12)
+#define APB_DMA_DEST_INC_2_8			(2<<12)
+#define APB_DMA_DEST_INC_4_16			(3<<12)
+#define APB_DMA_DEST_DEC_1_4			(5<<12)
+#define APB_DMA_DEST_DEC_2_8			(6<<12)
+#define APB_DMA_DEST_DEC_4_16			(7<<12)
+#define APB_DMA_DEST_INC_MASK			(7<<12)
+#define APB_DMA_DEST_REQ_NO_MASK		(15<<16)
+#define APB_DMA_DATA_WIDTH_MASK			(3<<20)
+#define APB_DMA_DATA_WIDTH_4			0
+#define APB_DMA_DATA_WIDTH_2			(1<<20)
+#define APB_DMA_DATA_WIDTH_1			(2<<20)
+#define APB_DMA_SOURCE_REQ_NO_MASK		(15<<24)
+	unsigned int ul;
+
+	struct {
+
+#define APB_DMAB_ENABLE				1
+		/* enable DMA */
+		unsigned int enable:1;
+
+#define APB_DMAB_FIN_INT_STS			1
+		/* finished interrupt status */
+		unsigned int fin_int_sts:1;
+
+#define APB_DMAB_FIN_INT_EN			1
+		/* finished interrupt enable */
+		unsigned int fin_int_en:1;
+
+#define APB_DMAB_BURST_MODE			1
+		/* burst mode */
+		unsigned int burst:1;
+
+#define APB_DMAB_ERR_INT_STS			1
+		/* error interrupt status */
+		unsigned int err_int_sts:1;
+
+#define APB_DMAB_ERR_INT_EN			1
+		/* error interrupt enable */
+		unsigned int err_int_en:1;
+
+#define APB_DMAB_SOURCE_AHB			1
+#define APB_DMAB_SOURCE_APB			0
+		/* 0:APB (device), 1:AHB (RAM) */
+		unsigned int source_sel:1;
+
+#define APB_DMAB_DEST_AHB			1
+#define APB_DMAB_DEST_APB			0
+		/* 0:APB, 1:AHB */
+		unsigned int dest_sel:1;
+
+#define APB_DMAB_SOURCE_INC_0			0
+#define APB_DMAB_SOURCE_INC_1_4			1
+#define APB_DMAB_SOURCE_INC_2_8			2
+#define APB_DMAB_SOURCE_INC_4_16		3
+#define APB_DMAB_SOURCE_DEC_1_4			5
+#define APB_DMAB_SOURCE_DEC_2_8			6
+#define APB_DMAB_SOURCE_DEC_4_16		7
+#define APB_DMAB_SOURCE_INC_MASK		7
+		/*
+		 * 000: no increment
+		 * 001: +1 (busrt=0), +4  (burst=1)
+		 * 010: +2 (burst=0), +8  (burst=1)
+		 * 011: +4 (burst=0), +16 (burst=1)
+		 * 101: -1 (burst=0), -4  (burst=1)
+		 * 110: -2 (burst=0), -8  (burst=1)
+		 * 111: -4 (burst=0), -16 (burst=1)
+		 */
+		unsigned int source_inc:3;
+
+		unsigned int reserved1:1;
+
+#define APB_DMAB_DEST_INC_0			0
+#define APB_DMAB_DEST_INC_1_4			1
+#define APB_DMAB_DEST_INC_2_8			2
+#define APB_DMAB_DEST_INC_4_16			3
+#define APB_DMAB_DEST_DEC_1_4			5
+#define APB_DMAB_DEST_DEC_2_8			6
+#define APB_DMAB_DEST_DEC_4_16			7
+#define APB_DMAB_DEST_INC_MASK			7
+		/*
+		 * 000: no increment
+		 * 001: +1 (busrt=0), +4  (burst=1)
+		 * 010: +2 (burst=0), +8  (burst=1)
+		 * 011: +4 (burst=0), +16 (burst=1)
+		 * 101: -1 (burst=0), -4  (burst=1)
+		 * 110: -2 (burst=0), -8  (burst=1)
+		 * 111: -4 (burst=0), -16 (burst=1)
+		*/
+		unsigned int dest_inc:3;
+
+		unsigned int reserved2:1;
+
+#define APB_DMAB_DEST_REQ_NO_MASK		15
+		/*
+		 * request signal select of destination
+		 * address for DMA hardware handshake
+		 *
+		 * the request line number is a property of
+		 * the DMA controller itself, e.g. MMC must
+		 * always request channels where
+		 * dma_slave_config->slave_id == 5
+		 *
+		 * 0:	 no request / grant signal
+		 * 1-15: request / grant signal
+		 */
+		unsigned int dest_req_no:4;
+
+#define APB_DMAB_DATA_WIDTH_MASK		3
+#define APB_DMAB_DATA_WIDTH_4			0
+#define APB_DMAB_DATA_WIDTH_2			1
+#define APB_DMAB_DATA_WIDTH_1			2
+		/*
+		 * data width of transfer
+		 * 00: word
+		 * 01: half
+		 * 10: byte
+		 */
+		unsigned int data_width:2;
+
+		unsigned int reserved3:2;
+
+#define APB_DMAB_SOURCE_REQ_NO_MASK		15
+		/*
+		 * request signal select of source
+		 * address for DMA hardware handshake
+		 *
+		 * the request line number is a property of
+		 * the DMA controller itself, e.g. MMC must
+		 * always request channels where
+		 * dma_slave_config->slave_id == 5
+		 *
+		 * 0:	 no request / grant signal
+		 * 1-15: request / grant signal
+		 */
+		unsigned int source_req_no:4;
+
+		unsigned int reserved4:4;
+	} bits;
+};
+
+struct moxart_dma_reg {
+	unsigned int source_addr;
+	unsigned int dest_addr;
+#define APB_DMA_CYCLES_MASK			0x00ffffff
+	unsigned int cycles;	/* depend on burst mode */
+	union moxart_dma_reg_cfg cfg;
+};
+
+#endif
-- 
1.8.2.1



From richard.genoud at gmail.com  Wed Jul 10 05:25:37 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Wed, 10 Jul 2013 11:25:37 +0200
Subject: [PATCH v4 1/7] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <20130709145917.GA27646@sirena.org.uk>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-2-git-send-email-richard.genoud@gmail.com>
 <20130709145917.GA27646@sirena.org.uk>
Message-ID: <CACQ1gAgHuAcBAAgYaP-n9grrM6X0L9b1mFFfkRg0HH_RnRuXMg@mail.gmail.com>

2013/7/9 Mark Brown <broonie at kernel.org>:
> On Tue, Jul 09, 2013 at 04:25:27PM +0200, Richard Genoud wrote:
>
>> +/*
>> + * Authorized rates are:
>> + * Rate = MCLK_RATE / (n * 2)
>> + * Where n is in [1..4095]
>> + * (cf register SSC_CMR)
>> + */
>> +static unsigned int rates[] = {
>> +     8000,
>> +     16000,
>> +     32000,
>> +     48000,
>> +     64000,
>> +     96000,
>> +};
>
> Shouldn't the SSC driver be enforcing this constraint if it comes from
> the SSC hardware?  If the clock is reprogrammable the usual convention
> for drivers is to not constrain if the clock is set to zero so a machine
> driver could remove the constraint.
Actually, my comment is buggy here (or at least, unrelated to the
authorized rates).
The "MCLK_RATE" is the master clock of the wm8731 codec (a 12.288MHz crystal).
According to the datasheet of wm8731, when a 12.288 crystal is used,
the authorized rates are 8, 32, 48 and 96kHz (I have to remove 16 and
64kHz).

So, is this the right place for the rates ?

>> +     ret = atmel_ssc_set_audio(0);
>> +     if (ret != 0) {
>> +             dev_err(&pdev->dev,
>> +                     "ASoC: Failed to set SSC 0 for audio: %d\n", ret);
>> +             return ret;
>> +     }
>
> Shouldn't this be a parameter in the DT too?
Yes, I'll add that to the DT.

>> +     cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
>> +     if (!cpu_np) {
>> +             dev_err(&pdev->dev, "ssc controller node missing\n");
>> +             ret = -EINVAL;
>> +             goto out;
>> +     }
>> +     at91sam9x5ek_dai.cpu_of_node = cpu_np;
>> +     at91sam9x5ek_dai.platform_of_node = cpu_np;
>
> After all we're looking things up in the DT...
>
>> +     at91sam9x5ek_dai.dai_fmt = snd_soc_of_parse_daifmt(np, "atmel,");
>
> Is this really something that machines would want to reconfigure?  If so
> why?
That's right. There's no point reconfiguring that because I2S is the
only possible interface.


Thanks for your comments !


Richard.


From jonas.jensen at gmail.com  Wed Jul 10 05:28:53 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 10 Jul 2013 11:28:53 +0200
Subject: [PATCH] mmc: sdhci-moxart: Add MOXA ART SDHCI driver
Message-ID: <1373448533-9401-1-git-send-email-jonas.jensen@gmail.com>

Add SDHCI driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130703
    
    I know this is a large chunk and there are many pitfalls with
    the controller. I give you my word it does work / seem to be stable,
    with or without DMA. Any feedback is appreciated.
    
    Tested by creating multiple directories/files and moving the card
    back and forth to different reader.
    
    IRQF_DISABLED is now pointless, remove it from request_irq?

 drivers/mmc/host/Kconfig        |   9 +
 drivers/mmc/host/Makefile       |   1 +
 drivers/mmc/host/sdhci-moxart.c | 786 ++++++++++++++++++++++++++++++++++++++++
 drivers/mmc/host/sdhci-moxart.h | 155 ++++++++
 4 files changed, 951 insertions(+)
 create mode 100644 drivers/mmc/host/sdhci-moxart.c
 create mode 100644 drivers/mmc/host/sdhci-moxart.h

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1be2289..fb401c4 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -260,6 +260,15 @@ config MMC_SDHCI_BCM2835
 
 	  If unsure, say N.
 
+config MMC_SDHCI_MOXART
+	tristate "MOXART SD Host Controller Interface support"
+	depends on ARCH_MOXART && MMC
+	help
+	  This selects the MOXART SD Host Controller Interface.
+	  MOXA provides one multi-functional card reader which can
+	  be found on some embedded hardware such as UC-7112-LX.
+	  If you have a controller with this interface, say Y here.
+
 config MMC_OMAP
 	tristate "TI OMAP Multimedia Card Interface support"
 	depends on ARCH_OMAP
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 67718c1..274199a 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_MMC_SDHCI_TEGRA)		+= sdhci-tegra.o
 obj-$(CONFIG_MMC_SDHCI_OF_ESDHC)	+= sdhci-of-esdhc.o
 obj-$(CONFIG_MMC_SDHCI_OF_HLWD)		+= sdhci-of-hlwd.o
 obj-$(CONFIG_MMC_SDHCI_BCM2835)		+= sdhci-bcm2835.o
+obj-$(CONFIG_MMC_SDHCI_MOXART)		+= sdhci-moxart.o
 
 ifeq ($(CONFIG_CB710_DEBUG),y)
 	CFLAGS-cb710-mmc	+= -DDEBUG
diff --git a/drivers/mmc/host/sdhci-moxart.c b/drivers/mmc/host/sdhci-moxart.c
new file mode 100644
index 0000000..f5aaea6
--- /dev/null
+++ b/drivers/mmc/host/sdhci-moxart.c
@@ -0,0 +1,786 @@
+/*
+ * MOXA ART MMC host driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/blkdev.h>
+#include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
+#include <linux/mmc/host.h>
+#include <linux/mmc/sd.h>
+#include <linux/mmc/mmc.h>
+#include <linux/sched.h>
+#include <linux/io.h>
+#include <linux/gpio.h>
+#include <linux/sizes.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/clk.h>
+
+#include <asm/dma.h>
+#include <asm/irq.h>
+
+#include "sdhci-moxart.h"
+
+#define DMA_FIFO_LEN_FORCE		0
+#define APB_DMA_SD_REQ_NO		5
+#define MIN_POWER (MMC_VDD_360 - MSD_SD_POWER_MASK)
+
+static inline void moxart_init_sg(struct moxart_host *host,
+				  struct mmc_data *data)
+{
+	host->cur_sg = data->sg;
+	host->num_sg = data->sg_len;
+	host->remain = host->cur_sg->length;
+
+	if (host->remain > host->size)
+		host->remain = host->size;
+
+	data->error = MMC_ERR_NONE;
+}
+
+static inline int moxart_next_sg(struct moxart_host *host)
+{
+	int remain;
+	struct mmc_data *data = host->mrq->cmd->data;
+
+	host->cur_sg++;
+	host->num_sg--;
+
+	if (host->num_sg > 0) {
+		host->remain = host->cur_sg->length;
+		remain = host->size - data->bytes_xfered;
+		if (remain > 0 && remain < host->remain)
+			host->remain = remain;
+	}
+
+	return host->num_sg;
+}
+
+static void moxart_send_command(struct moxart_host *host,
+	struct mmc_command *cmd)
+{
+	unsigned int status, cmdctrl;
+	int retry = 0;
+
+	dev_dbg(mmc_dev(host->mmc), "%s: cmd->opcode=%d\n",
+		__func__, cmd->opcode);
+
+	cmd->error = MMC_ERR_TIMEOUT;
+
+	writel(MSD_RSP_TIMEOUT | MSD_RSP_CRC_OK |
+	       MSD_RSP_CRC_FAIL | MSD_CMD_SENT, &host->reg->clear);
+	writel(cmd->arg, &host->reg->argument);
+
+	cmdctrl = cmd->opcode & MSD_CMD_IDX_MASK;
+	if (cmdctrl == SD_APP_SET_BUS_WIDTH || cmdctrl == SD_APP_OP_COND ||
+	    cmdctrl == SD_APP_SEND_SCR || cmdctrl == SD_APP_SD_STATUS ||
+	    cmdctrl == SD_APP_SEND_NUM_WR_BLKS)
+		cmdctrl |= MSD_APP_CMD;
+
+	if (cmd->flags & MMC_RSP_136)
+		cmdctrl |= (MSD_LONG_RSP | MSD_NEED_RSP);
+	else
+		cmdctrl |= MSD_NEED_RSP;
+
+	writel(cmdctrl | MSD_CMD_EN, &host->reg->command);
+
+	while (retry++ < MSD_RETRY_COUNT) {
+		udelay(10);
+		status = readl(&host->reg->status);
+		if (status & MSD_CARD_DETECT) {
+			dev_dbg(mmc_dev(host->mmc), "%s: MSD_CARD_DETECT\n",
+				__func__);
+			cmd->error = MMC_ERR_TIMEOUT;
+			break;
+		}
+		if (cmdctrl & MSD_NEED_RSP) {
+			dev_dbg(mmc_dev(host->mmc), "%s: MSD_NEED_RSP\n",
+				__func__);
+			if (status & MSD_RSP_TIMEOUT) {
+				dev_dbg(mmc_dev(host->mmc), "%s: MSD_RSP_TIMEOUT\n",
+					__func__);
+				writel(MSD_RSP_TIMEOUT, &host->reg->clear);
+				cmd->error = MMC_ERR_TIMEOUT;
+				break;
+			}
+			if ((cmd->flags & MMC_RSP_CRC) &&
+				(status & MSD_RSP_CRC_FAIL)) {
+				dev_dbg(mmc_dev(host->mmc), "%s: MSD_RSP_CRC_FAIL\n",
+					__func__);
+				writel(MSD_RSP_CRC_FAIL, &host->reg->clear);
+				cmd->error = MMC_ERR_BADCRC;
+				break;
+			}
+			if (status & MSD_RSP_CRC_OK) {
+				dev_dbg(mmc_dev(host->mmc), "%s: MSD_RSP_CRC_OK\n",
+					__func__);
+				writel(MSD_RSP_CRC_OK, &host->reg->clear);
+
+				if (cmd->flags & MMC_RSP_136) {
+					cmd->resp[3] =
+						readl(&host->reg->response0);
+					cmd->resp[2] =
+						readl(&host->reg->response1);
+					cmd->resp[1] =
+						readl(&host->reg->response2);
+					cmd->resp[0] =
+						readl(&host->reg->response3);
+				} else {
+					cmd->resp[0] =
+						readl(&host->reg->response0);
+				}
+
+				cmd->error = MMC_ERR_NONE;
+				break;
+			}
+		} else {
+			dev_dbg(mmc_dev(host->mmc), "%s: !(cmdctrl & MSD_NEED_RSP)\n",
+				__func__);
+			if (status & MSD_CMD_SENT) {
+				writel(MSD_CMD_SENT, &host->reg->clear);
+				cmd->error = MMC_ERR_NONE;
+				break;
+			}
+		}
+	}
+
+	if (retry >= (MSD_RETRY_COUNT - 1)) {
+		/*
+		 * this seems to happen a lot on or after CMD25
+		 * (MMC_WRITE_MULTIPLE_BLOCK) with more than 4 blocks
+		 * (>4096), possibly because the transfer is too big
+		 * or takes too long to complete.
+		 * when this happens the controller is usually rendered
+		 * unresponsive and can only be recovered with reboot.
+		 */
+		dev_dbg(mmc_dev(host->mmc), "%s: WARNING! no valid status found!\n",
+			__func__);
+	}
+}
+
+static void moxart_dma_complete(void *param)
+{
+	struct moxart_host *host = param;
+
+	dev_dbg(mmc_dev(host->mmc), "%s: host=%p\n", __func__, host);
+	complete(&host->dma_complete);
+}
+
+static void moxart_transfer_dma(struct mmc_data *data, struct moxart_host *host)
+{
+	unsigned int len, direction_dev;
+	struct dma_async_tx_descriptor *desc = NULL;
+
+	if (host->size == data->bytes_xfered)
+		return;
+
+	direction_dev = (data->flags & MMC_DATA_WRITE) ?
+			DMA_MEM_TO_DEV : DMA_DEV_TO_MEM;
+
+	/*
+	 * because dma_map_sg takes both sg and sg_len as arguments
+	 * (and maps the entire list of buffers) data->sg does not
+	 * have to be incremented between calls (as is required
+	 * in moxart_transfer_pio)
+	 */
+	len = dma_map_sg(host->dma_chan_cur->device->dev, data->sg,
+			 data->sg_len, host->dma_direction);
+
+	if (len > 0) {
+		/* host->dma_active = true;*/
+		desc = dmaengine_prep_slave_sg(host->dma_chan_cur, data->sg,
+					       len, direction_dev,
+					       DMA_PREP_INTERRUPT |
+					       DMA_CTRL_ACK);
+	} else {
+		pr_err("%s: dma_map_sg returned zero length\n",
+			__func__);
+	}
+
+	if (desc) {
+		desc->callback = moxart_dma_complete;
+		desc->callback_param = host;
+		dmaengine_submit(desc);
+		dma_async_issue_pending(host->dma_chan_cur);
+	}
+
+	data->bytes_xfered += host->remain;
+}
+
+/* when DMA is available this is used only for SD_APP_SEND_SCR */
+static void moxart_transfer_pio(struct moxart_host *host)
+{
+	unsigned char *buffer;
+	unsigned int wcnt, i;
+	struct mmc_data *data = host->mrq->cmd->data;
+
+	if (host->size == data->bytes_xfered)
+		goto transfer_complete;
+
+	buffer = sg_virt(host->cur_sg);
+	wcnt = host->remain >> 2;
+
+	if (data->flags & MMC_DATA_WRITE) {
+		for (i = 0; i < wcnt; i++, buffer += 4) {
+			writel(*(unsigned int *)buffer,
+			       &host->reg->data_window);
+			udelay(10);
+		}
+	} else {
+		for (i = 0; i < wcnt; i++, buffer += 4) {
+			/* byte order reversed only when reading SCR */
+			if (data->mrq->cmd->opcode == SD_APP_SEND_SCR) {
+				*(unsigned int *)buffer = ioread32be(
+					&host->reg->data_window);
+			} else {
+				*(unsigned int *)buffer =
+					readl(&host->reg->data_window);
+			}
+			udelay(10);
+		}
+	}
+	wcnt <<= 2;
+	host->remain -= wcnt;
+	data->bytes_xfered += wcnt;
+
+	if (host->size != data->bytes_xfered) {
+		moxart_next_sg(host);
+		/*
+		 * used to goto "transfer_start" label here,
+		 * there is no need, this function will be
+		 * called again from interrupt.
+		 *
+		 * compare with DMA where sg increment is
+		 * redundant thanks to dma_map_sg
+		 */
+	} else {
+		complete(&host->pio_complete);
+	}
+
+transfer_complete:
+	dev_dbg(mmc_dev(host->mmc), "%s: host->size=%d host->remain=%u\n",
+		__func__, host->size, host->remain);
+}
+
+static void moxart_prepare_data(struct moxart_host *host)
+{
+	struct mmc_data *data = host->mrq->cmd->data;
+	unsigned int timeout, datactrl;
+	int blksz_bits;
+
+	dev_dbg(mmc_dev(host->mmc), "%s\n", __func__);
+
+	if (!data)
+		return;
+
+	host->size = data->blocks * data->blksz;
+	blksz_bits = ffs(data->blksz) - 1;
+	BUG_ON(1 << blksz_bits != data->blksz);
+
+	moxart_init_sg(host, data);
+
+	timeout = (host->mmc->f_max / 1000) * (data->timeout_ns / 1000);
+	timeout *= 2;
+
+	datactrl = (blksz_bits & MSD_BLK_SIZE_MASK) | MSD_DATA_EN;
+
+	if (data->flags & MMC_DATA_WRITE)
+		datactrl |= MSD_DATA_WRITE;
+
+	if (((host->size > MSD_FIFO_LENB) || DMA_FIFO_LEN_FORCE)
+	    && host->have_dma) {
+		datactrl |= MSD_DMA_EN;
+	}
+
+	dev_dbg(mmc_dev(host->mmc), "%s: blocks=%d blksz=%d datactrl=0x%08x\n",
+		__func__, data->blocks,	data->blksz, datactrl);
+	dev_dbg(mmc_dev(host->mmc), "%s: timeout=%u timeout_ns=%u\n",
+		__func__, timeout, data->timeout_ns);
+
+	writel(timeout, &host->reg->data_timer);
+	writel(host->size, &host->reg->data_length);
+	writel(datactrl, &host->reg->data_control);
+}
+
+static void moxart_transfer_check(struct mmc_data *data,
+				  struct moxart_host *host)
+{
+	unsigned int status, count = 0;
+
+	dev_dbg(mmc_dev(host->mmc), "%s\n", __func__);
+
+	while (1) {
+		udelay(10);
+		status = readl(&host->reg->status);
+		if (status & (MSD_DATA_CRC_OK | MSD_DATA_CRC_FAIL
+			| MSD_DATA_END)	|| count > 10)
+			break;
+		dev_dbg(mmc_dev(host->mmc), "%s: waiting for status=%08x ..\n",
+			__func__, status);
+		count++;
+	}
+	if (status & MSD_DATA_CRC_OK) {
+		dev_dbg(mmc_dev(host->mmc), "%s: MSD_DATA_CRC_OK\n", __func__);
+		writel(MSD_DATA_CRC_OK, &host->reg->clear);
+	}
+	if (status & MSD_DATA_CRC_FAIL) {
+		dev_dbg(mmc_dev(host->mmc), "%s: MSD_DATA_CRC_FAIL\n",
+			__func__);
+		writel(MSD_DATA_CRC_FAIL, &host->reg->clear);
+		data->error = MMC_ERR_TIMEOUT;
+	}
+	if (status & MSD_DATA_END) {
+		dev_dbg(mmc_dev(host->mmc), "%s: MSD_DATA_END\n",
+			__func__);
+		writel(MSD_DATA_END, &host->reg->clear);
+	}
+	if (status & MSD_DATA_TIMEOUT) {
+		dev_dbg(mmc_dev(host->mmc), "%s: MSD_DATA_TIMEOUT\n",
+			__func__);
+		writel(MSD_DATA_TIMEOUT, &host->reg->clear);
+	}
+}
+
+static void moxart_card_change(struct moxart_host *host)
+{
+	int delay;
+	unsigned long flags;
+
+	spin_lock_irqsave(&host->lock, flags);
+
+	if (readl(&host->reg->status) & MSD_CARD_DETECT) {
+		dev_dbg(mmc_dev(host->mmc), "%s: card removed\n", __func__);
+		if (host->have_dma && host->size > MSD_FIFO_LENB) {
+			dev_dbg(mmc_dev(host->mmc), "%s: call dmaengine_terminate_all\n",
+				__func__);
+			dmaengine_terminate_all(host->dma_chan_rx);
+			dmaengine_terminate_all(host->dma_chan_tx);
+		}
+		host->removed = true;
+		delay = 0;
+	} else {
+		dev_dbg(mmc_dev(host->mmc), "%s: card inserted\n", __func__);
+		host->removed = false;
+		delay = 500;
+	}
+
+	/*
+	 * clearing FIFO interrupts here does not stop a follow up
+	 * MSD_FIFO_*RUN after MSD_CARD_CHANGE. instead, check
+	 * host->mrq != NULL in moxart_irq to avoid unnecessary calls
+	 * to moxart_transfer_pio
+	 * if this happens during transfer the mmc_request in
+	 * moxart_request should still be valid
+	 * (which is why host->mrq can be set NULL here)
+	 */
+	host->mrq = NULL;
+	writel(MSD_CARD_CHANGE | MSD_FIFO_ORUN | MSD_FIFO_URUN,
+	       &host->reg->clear);
+	writel(MSD_CARD_CHANGE, &host->reg->interrupt_mask);
+
+	spin_unlock_irqrestore(&host->lock, flags);
+	dev_dbg(mmc_dev(host->mmc), "%s: call mmc_detect_change\n", __func__);
+	mmc_detect_change(host->mmc, msecs_to_jiffies(delay));
+}
+
+static void moxart_request(struct mmc_host *mmc, struct mmc_request *mrq)
+{
+	struct moxart_host *host = mmc_priv(mmc);
+	unsigned long dma_time, pio_time, flags;
+	unsigned int status;
+
+	dev_dbg(mmc_dev(host->mmc), "%s\n", __func__);
+
+	spin_lock_irqsave(&host->lock, flags);
+
+	init_completion(&host->dma_complete);
+	init_completion(&host->pio_complete);
+
+	host->mrq = mrq;
+
+	if (readl(&host->reg->status) & MSD_CARD_DETECT) {
+		mrq->cmd->error = MMC_ERR_TIMEOUT;
+		goto request_done;
+	}
+
+	moxart_prepare_data(host);
+	moxart_send_command(host, host->mrq->cmd);
+
+	if (mrq->cmd->data) {
+		/* only use DMA/PIO (and wait) when there is data */
+		if (((host->size > MSD_FIFO_LENB) || DMA_FIFO_LEN_FORCE)
+			&& host->have_dma) {
+
+			writel(MSD_CARD_CHANGE, &host->reg->interrupt_mask);
+
+			spin_unlock_irqrestore(&host->lock, flags);
+
+			host->dma_direction = (mrq->cmd->data->flags
+					      & MMC_DATA_WRITE) ?
+					      DMA_TO_DEVICE : DMA_FROM_DEVICE;
+			host->dma_chan_cur = (mrq->cmd->data->flags
+					     & MMC_DATA_WRITE) ?
+					     host->dma_chan_tx :
+					     host->dma_chan_rx;
+			moxart_transfer_dma(mrq->cmd->data, host);
+
+			dma_time = wait_for_completion_interruptible_timeout(
+				   &host->dma_complete, host->timeout);
+			dev_dbg(mmc_dev(host->mmc), "%s: dma_time=%lu (DMA wait time)\n",
+				__func__, dma_time);
+
+			dma_unmap_sg(host->dma_chan_cur->device->dev,
+				     mrq->cmd->data->sg, mrq->cmd->data->sg_len,
+				     host->dma_direction);
+
+			spin_lock_irqsave(&host->lock, flags);
+		} else {
+
+			writel(MSD_FIFO_URUN | MSD_FIFO_ORUN | MSD_CARD_CHANGE,
+			       &host->reg->interrupt_mask);
+
+			status = readl(&host->reg->status);
+			dev_dbg(mmc_dev(host->mmc), "%s: status=%08x\n",
+				__func__, status);
+
+			spin_unlock_irqrestore(&host->lock, flags);
+
+			/* PIO transfer started from interrupt */
+			pio_time = wait_for_completion_interruptible_timeout(
+				   &host->pio_complete, host->timeout);
+			dev_dbg(mmc_dev(host->mmc), "%s: pio_time=%lu (PIO wait time)\n",
+				__func__, pio_time);
+
+			spin_lock_irqsave(&host->lock, flags);
+		}
+
+		/* removed during transfer? (interrupts were just enabled..) */
+		if (host->removed) {
+			dev_dbg(mmc_dev(host->mmc), "%s: host removed during transfer!\n",
+				__func__);
+			mrq->cmd->error = MMC_ERR_TIMEOUT;
+		}
+
+		moxart_transfer_check(mrq->cmd->data, host);
+
+		if (mrq->cmd->data->stop)
+			moxart_send_command(host, mrq->cmd->data->stop);
+	}
+
+request_done:
+	spin_unlock_irqrestore(&host->lock, flags);
+	mmc_request_done(host->mmc, mrq);
+}
+
+static irqreturn_t moxart_irq(int irq, void *devid)
+{
+	struct moxart_host *host = (struct moxart_host *)devid;
+	unsigned int status;
+	unsigned long flags;
+
+	status = readl(&host->reg->status);
+
+	dev_dbg(mmc_dev(host->mmc), "%s: host=%p status=%08x\n",
+		__func__, host, status);
+
+	if (status & MSD_CARD_CHANGE) {
+		dev_dbg(mmc_dev(host->mmc), "%s: call moxart_card_change\n",
+			__func__);
+		moxart_card_change(host);
+	}
+	if (status & (MSD_FIFO_ORUN | MSD_FIFO_URUN) && host->mrq) {
+		writel(status & (MSD_FIFO_ORUN | MSD_FIFO_URUN),
+		       &host->reg->clear);
+		dev_dbg(mmc_dev(host->mmc), "%s: call moxart_transfer_pio\n",
+			__func__);
+		spin_lock_irqsave(&host->lock, flags);
+		moxart_transfer_pio(host);
+		spin_unlock_irqrestore(&host->lock, flags);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static void moxart_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
+{
+	struct moxart_host *host = mmc_priv(mmc);
+	unsigned long flags;
+	unsigned short power;
+	int div;
+
+	spin_lock_irqsave(&host->lock, flags);
+	if (ios->clock) {
+		div = (host->sysclk / (host->mmc->f_max * 2)) - 1;
+
+		if (div > MSD_CLK_DIV_MASK)
+			div = MSD_CLK_DIV_MASK;
+		else if (div < 0)
+			div = 0;
+
+		div |= MSD_CLK_SD;
+		writel(div, &host->reg->clock_control);
+	} else if (!(readl(&host->reg->clock_control) & MSD_CLK_DIS)) {
+		writel(readl(&host->reg->clock_control) | MSD_CLK_DIS,
+		       &host->reg->clock_control);
+	}
+
+	if (ios->power_mode == MMC_POWER_OFF) {
+		writel(readl(&host->reg->power_control) & ~MSD_SD_POWER_ON,
+		       &host->reg->power_control);
+	} else {
+		if (ios->vdd < MIN_POWER)
+			power = 0;
+		else
+			power = ios->vdd - MIN_POWER;
+
+		writel(MSD_SD_POWER_ON | (unsigned int) power,
+		       &host->reg->power_control);
+	}
+
+	if (ios->bus_width == MMC_BUS_WIDTH_1)
+		writel(MSD_SINGLE_BUS, &host->reg->bus_width);
+	else
+		writel(MSD_WIDE_BUS, &host->reg->bus_width);
+
+	spin_unlock_irqrestore(&host->lock, flags);
+}
+
+
+static int moxart_get_ro(struct mmc_host *mmc)
+{
+	int ret;
+	struct moxart_host *host = mmc_priv(mmc);
+
+	(readl(&host->reg->status) & MSD_WRITE_PROT) ? (ret = 1) : (ret = 0);
+	return ret;
+}
+
+static struct mmc_host_ops moxart_ops = {
+	.request = moxart_request,
+	.set_ios = moxart_set_ios,
+	.get_ro = moxart_get_ro,
+};
+
+static int moxart_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct resource res_mmc;
+	struct mmc_host *mmc;
+	struct moxart_host *host = NULL;
+	void __iomem *reg_mmc;
+	dma_cap_mask_t mask;
+	int ret;
+	struct dma_slave_config cfg;
+	unsigned int irq;
+	struct clk *clk;
+	unsigned int dma_chan_rx_req = 1;
+	unsigned int dma_chan_tx_req = 0;
+
+	mmc = mmc_alloc_host(sizeof(struct moxart_host), dev);
+	if (!mmc) {
+		dev_err(dev, "%s: mmc_alloc_host failed\n", __func__);
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	ret = of_address_to_resource(node, 0, &res_mmc);
+	if (ret) {
+		dev_err(dev, "%s: could not get MMC base resource\n", __func__);
+		goto out;
+	}
+
+	irq = irq_of_parse_and_map(node, 0);
+
+	reg_mmc = devm_ioremap_resource(dev, &res_mmc);
+	if (IS_ERR(reg_mmc)) {
+		dev_err(dev, "%s: devm_ioremap_resource res_mmc failed\n",
+			__func__);
+		return PTR_ERR(reg_mmc);
+	}
+
+	mmc->ops = &moxart_ops;
+
+	/*
+	 * hardware does not support MMC_CAP_SD_HIGHSPEED
+	 * CMD6 will timeout and make things not work
+	 */
+	mmc->caps = MMC_CAP_4_BIT_DATA;
+
+	mmc->f_min = 400000;
+	mmc->f_max = 25000000;
+	mmc->ocr_avail = 0xffff00;	/* support 2.0v - 3.6v power */
+	mmc->max_segs = 32;
+	mmc->max_blk_size = 512;
+	mmc->max_blk_count = mmc->max_req_size / mmc->max_blk_size;
+	mmc->max_seg_size = mmc->max_req_size;
+
+	host = mmc_priv(mmc);
+	host->mmc = mmc;
+	host->reg = (struct moxart_reg *)reg_mmc;
+	host->reg_phys = res_mmc.start;
+	host->timeout = msecs_to_jiffies(1000);
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk)) {
+		dev_err(dev, "%s: of_clk_get failed\n", __func__);
+		return PTR_ERR(clk);
+	}
+	host->sysclk = clk_get_rate(clk);
+
+	spin_lock_init(&host->lock);
+
+	/* disable all interrupt */
+	writel(0, &host->reg->interrupt_mask);
+
+	/* reset chip */
+	writel(MSD_SDC_RST, &host->reg->command);
+
+	/* wait for reset finished */
+	while (readl(&host->reg->command) & MSD_SDC_RST)
+		udelay(10);
+
+	host->dma_chan_tx = dma_request_channel(mask, moxart_filter_fn,
+						(void *)&dma_chan_tx_req);
+	host->dma_chan_rx = dma_request_channel(mask, moxart_filter_fn,
+						(void *)&dma_chan_rx_req);
+	dev_dbg(dev, "%s: using 2 DMA channels rx=%p tx=%p\n",
+		__func__, host->dma_chan_rx, host->dma_chan_tx);
+
+	if (!host->dma_chan_rx || !host->dma_chan_tx) {
+		host->have_dma = false;
+		mmc->max_blk_count = 1;
+	} else {
+		cfg.slave_id = APB_DMA_SD_REQ_NO;
+		cfg.direction = DMA_MEM_TO_DEV;
+		cfg.src_addr = 0;
+		cfg.dst_addr = (unsigned int)host->reg_phys + MSD_DATA_WIN_REG;
+		cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+		dmaengine_slave_config(host->dma_chan_tx, &cfg);
+
+		cfg.slave_id = APB_DMA_SD_REQ_NO;
+		cfg.direction = DMA_DEV_TO_MEM;
+		cfg.src_addr = (unsigned int)host->reg_phys + MSD_DATA_WIN_REG;
+		cfg.dst_addr = 0;
+		cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+		dmaengine_slave_config(host->dma_chan_rx, &cfg);
+
+		host->have_dma = true;
+
+		/*
+		 * there seems to be a max size on transfers so
+		 * set max_blk_count low for both DMA and PIO
+		 *
+		 * sending large chunks result either in timeout
+		 * or render the MMC controller unresponsive
+		 * (status register 0 on consecutive read retries,
+		 * also see comments in moxart_send_command)
+		 *
+		 * obviously, DMA is quicker and can handle
+		 * larger chunks but setting it higher than 16
+		 * can still bug the controller
+		 */
+		mmc->max_blk_count = 16;
+	}
+
+	ret = request_irq(irq, moxart_irq,
+			  IRQF_DISABLED, "moxart-mmc", host);
+
+	if (ret)
+		goto out;
+
+	dev_set_drvdata(dev, mmc);
+	mmc_add_host(mmc);
+
+	dev_dbg(dev, "%s: IRQ=%d\n", __func__, irq);
+
+	return 0;
+
+out:
+	if (mmc)
+		mmc_free_host(mmc);
+	return ret;
+}
+
+static void moxart_release_dma(struct moxart_host *host)
+{
+	if (host->dma_chan_tx) {
+		struct dma_chan *chan = host->dma_chan_tx;
+		host->dma_chan_tx = NULL;
+		dma_release_channel(chan);
+	}
+	if (host->dma_chan_rx) {
+		struct dma_chan *chan = host->dma_chan_rx;
+		host->dma_chan_rx = NULL;
+		dma_release_channel(chan);
+	}
+}
+
+static int moxart_remove(struct platform_device *pdev)
+{
+	struct mmc_host *mmc = dev_get_drvdata(&pdev->dev);
+	struct moxart_host *host = mmc_priv(mmc);
+	struct resource *res_irq;
+
+	res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 2);
+
+	dev_set_drvdata(&pdev->dev, NULL);
+
+	if (mmc) {
+		moxart_release_dma(host);
+		mmc_remove_host(mmc);
+
+		writel(0, &host->reg->interrupt_mask);
+		writel(0, &host->reg->power_control);
+		writel(readl(&host->reg->clock_control) | MSD_CLK_DIS,
+		       &host->reg->clock_control);
+
+		free_irq(res_irq->start, host);
+
+		mmc_free_host(mmc);
+	}
+	return 0;
+}
+
+static const struct of_device_id moxart_mmc_match[] = {
+	{ .compatible = "moxa,moxart-mmc" },
+	{ }
+};
+
+static struct platform_driver moxart_mmc_driver = {
+	.probe      = moxart_probe,
+	.remove     = moxart_remove,
+	.driver     = {
+		.name		= "sdhci-moxart",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_mmc_match,
+	},
+};
+module_platform_driver(moxart_mmc_driver);
+
+MODULE_ALIAS("platform:sdhci-moxart");
+MODULE_DESCRIPTION("MOXART SDHCI driver");
+MODULE_VERSION("1.0");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
diff --git a/drivers/mmc/host/sdhci-moxart.h b/drivers/mmc/host/sdhci-moxart.h
new file mode 100644
index 0000000..f60bed1
--- /dev/null
+++ b/drivers/mmc/host/sdhci-moxart.h
@@ -0,0 +1,155 @@
+/*
+ * MOXA ART MMC host driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _SDHCI_MOXART_H
+#define _SDHCI_MOXART_H
+
+extern bool moxart_filter_fn(struct dma_chan *chan, void *param);
+
+#define MSD_CMD_REG		0
+#define MSD_ARG_REG		4
+#define MSD_RESP0_REG		8
+#define MSD_RESP1_REG		0x0c
+#define MSD_RESP2_REG		0x10
+#define MSD_RESP3_REG		0x14
+#define MSD_RESP_CMD_REG	0x18
+#define MSD_DATA_CTRL_REG	0x1c
+#define MSD_DATA_TIMER_REG	0x20
+#define MSD_DATA_LEN_REG	0x24
+#define MSD_STATUS_REG		0x28
+#define MSD_CLEAR_REG		0x2c
+#define MSD_INT_MASK_REG	0x30
+#define MSD_POWER_CTRL_REG	0x34
+#define MSD_CLOCK_CTRL_REG	0x38
+#define MSD_BUS_WIDTH_REG	0x3c
+#define MSD_DATA_WIN_REG	0x40
+#define MSD_FEATURE_REG		0x44
+#define MSD_REVISION_REG	0x48
+
+#define MMC_RSP_SHORT		(1 << 0)
+#define MMC_RSP_LONG		(2 << 0)
+#define MMC_RSP_MASK		(3 << 0)
+#define MMC_ERR_NONE		0
+#define MMC_ERR_TIMEOUT		1
+#define MMC_MODE_MMC		0
+#define MMC_MODE_SD		1
+#define MMC_ERR_BADCRC		2
+#define MMC_VDD_360		23
+
+#define MSD_RETRY_COUNT		10
+
+struct moxart_reg {
+
+#define MSD_SDC_RST		(1<<10)
+#define MSD_CMD_EN		(1<<9)
+#define MSD_APP_CMD		(1<<8)
+#define MSD_LONG_RSP		(1<<7)
+#define MSD_NEED_RSP		(1<<6)
+#define MSD_CMD_IDX_MASK	0x3f
+	unsigned int	command;
+
+	unsigned int	argument;
+	unsigned int	response0;
+	unsigned int	response1;
+	unsigned int	response2;
+	unsigned int	response3;
+
+#define MSD_RSP_CMD_APP		(1<<6)
+#define MSD_RSP_CMD_IDX_MASK	0x3f
+	unsigned int	response_command;
+
+#define MSD_DATA_EN		(1<<6)
+#define MSD_DMA_EN		(1<<5)
+#define MSD_DATA_WRITE		(1<<4)
+#define MSD_BLK_SIZE_MASK	0x0f
+	unsigned int	data_control;
+
+	unsigned int	data_timer;
+
+#define MSD_DATA_LEN_MASK	0xffffff
+	unsigned int	data_length;
+
+#define MSD_WRITE_PROT		(1<<12)
+#define MSD_CARD_DETECT		(1<<11)
+/* 1-10 below can be sent to interrupt or clear register */
+#define MSD_CARD_CHANGE		(1<<10)
+#define MSD_FIFO_ORUN		(1<<9)
+#define MSD_FIFO_URUN		(1<<8)
+#define MSD_DATA_END		(1<<7)
+#define MSD_CMD_SENT		(1<<6)
+#define MSD_DATA_CRC_OK		(1<<5)
+#define MSD_RSP_CRC_OK		(1<<4)
+#define MSD_DATA_TIMEOUT	(1<<3)
+#define MSD_RSP_TIMEOUT		(1<<2)
+#define MSD_DATA_CRC_FAIL	(1<<1)
+#define MSD_RSP_CRC_FAIL	(1<<0)
+	unsigned int	status;
+
+	unsigned int	clear;
+	unsigned int	interrupt_mask;
+
+#define MSD_SD_POWER_ON		(1<<4)
+#define MSD_SD_POWER_MASK	0x0f
+	unsigned int	power_control;
+
+#define MSD_CLK_DIS		(1<<8)
+#define MSD_CLK_SD		(1<<7)
+#define MSD_CLK_DIV_MASK	0x7f
+	unsigned int	clock_control;
+
+#define MSD_WIDE_BUS_SUPPORT	(1<<3)
+#define MSD_WIDE_BUS		(1<<2)	/* bus width is 4 bytes */
+#define MSD_SINGLE_BUS		(1<<0)	/* bus width is 1 byte */
+	unsigned int	bus_width;
+
+	unsigned int	data_window;
+
+#define MSD_CPRM_FUNCTION	(1<<8)
+	unsigned int	feature;
+
+	unsigned int	revision;
+};
+
+struct moxart_host {
+	spinlock_t		lock;
+	struct moxart_reg	*reg;
+	phys_addr_t		reg_phys;
+
+	struct dma_chan		*dma_chan_rx;
+	struct dma_chan		*dma_chan_tx;
+	struct dma_chan		*dma_chan_cur;
+	unsigned int		dma_direction;
+	bool			have_dma;
+	struct completion	dma_complete;
+	struct completion	pio_complete;
+
+	struct mmc_host		*mmc;
+	struct mmc_request	*mrq;
+
+	struct scatterlist	*cur_sg;
+	unsigned int		num_sg;
+	unsigned int		remain;
+	int			size;
+
+	unsigned int		wait_for;
+	unsigned int		timeout;
+	long			sysclk;
+	bool			removed;
+};
+
+#define MSD_FIFO_LENW	4	/* 4 words, total 4 * 4 = 16 bytes */
+#define MSD_FIFO_LENB	16	/* 16 bytes */
+
+#endif	/* _SDHCI_MOXART_H */
-- 
1.8.2.1



From richard.genoud at gmail.com  Wed Jul 10 05:30:24 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Wed, 10 Jul 2013 11:30:24 +0200
Subject: [PATCH v4 1/7] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <51DCFB24.4080107@atmel.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-2-git-send-email-richard.genoud@gmail.com>
 <51DCFB24.4080107@atmel.com>
Message-ID: <CACQ1gAjEvrKQ8Amb_fKj-VUJqmbtGuRm6=9zdtVj9MBsVcn18Q@mail.gmail.com>

2013/7/10 Bo Shen <voice.shen at atmel.com>:
> Hi Richard,
Hi !

> On 7/9/2013 22:25, Richard Genoud wrote:
> [snip]
>
>
>> +#include <linux/module.h>
>> +#include <linux/moduleparam.h>
>> +#include <linux/kernel.h>
>> +#include <linux/clk.h>
>> +#include <linux/timer.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/i2c.h>
>> +
>> +#include <linux/atmel-ssc.h>
>> +
>> +#include <sound/core.h>
>> +#include <sound/pcm.h>
>> +#include <sound/pcm_params.h>
>> +#include <sound/soc.h>
>> +
>> +#include <asm/mach-types.h>
>> +#include <mach/hardware.h>
>> +#include <mach/gpio.h>
>> +
>> +#include "../codecs/wm8731.h"
>> +#include "atmel-pcm.h"
>> +#include "atmel_ssc_dai.h"
>
>
> I think some of the header file include is not needed. I keep them as simple
> as following:
> ---8>---
> #include <linux/clk.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_device.h>
> #include <linux/pinctrl/consumer.h>
>
> #include <sound/soc.h>
>
> #include "../codecs/wm8731.h"
> #include "atmel_ssc_dai.h"
> ---<8---
ooopps ! I forgot to do some cleaning in those after the file rework. Thanks !

>
>> +#define MCLK_RATE 12288000
>> +
>> +#define DRV_NAME "sam9x5-snd-wm8731"
>> +
>> +/*
>> + * Authorized rates are:
>> + * Rate = MCLK_RATE / (n * 2)
>> + * Where n is in [1..4095]
>> + * (cf register SSC_CMR)
>> + */
>> +static unsigned int rates[] = {
>> +       8000,
>> +       16000,
>> +       32000,
>> +       48000,
>> +       64000,
>> +       96000,
>> +};
>
>
> This is decided by the codec, while not ssc when ssc in slave mode.
yes.

>> +static struct snd_pcm_hw_constraint_list hw_rates = {
>> +       .count = ARRAY_SIZE(rates),
>> +       .list = rates,
>> +};
>> +
>
>
> [snip]
>
>
>> +
>> +       at91sam9x5ek_dai.dai_fmt = snd_soc_of_parse_daifmt(np, "atmel,");
>
>
> We can put this into at91sam9x5ek_dai directly, not need to parse it then.
> example as following:
> ---8>---
> .dai_fmt = SND_SOC_DAIFMT_I2S
>                 | SND_SOC_DAIFMT_NB_NF
>                 | SND_SOC_DAIFMT_CBM_CFM,
> ---<8---
yes, I removed that for the older machine driver, without thinking that much.
It's better hardcorded like that.


Thanks for your comments !


From linux at arm.linux.org.uk  Wed Jul 10 05:30:55 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Jul 2013 10:30:55 +0100
Subject: [PATCH] dmaengine: Add MOXA ART DMA engine driver
In-Reply-To: <1373446263-7772-1-git-send-email-jonas.jensen@gmail.com>
References: <1373446263-7772-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <20130710093055.GW24642@n2100.arm.linux.org.uk>

On Wed, Jul 10, 2013 at 10:51:03AM +0200, Jonas Jensen wrote:
> +#include "virt-dma.h"
...
> +struct moxart_dma_chan {
> +	struct virt_dma_chan		vchan;
...
> +static inline struct moxart_dma_chan *to_moxart_dma_chan(struct dma_chan *c)
> +{
> +	return container_of(c, struct moxart_dma_chan, vchan.chan);
> +}
...
> +	for (i = 0; i < APB_DMA_MAX_CHANNEL; i++, mchan++) {
> +		mchan->ch_num = i;
> +		mchan->reg = (struct moxart_dma_reg *)(dma_base_addr + 0x80
> +			     + i * sizeof(struct moxart_dma_reg));
> +		mchan->callback = NULL;
> +		mchan->allocated = 0;
> +		mchan->callback_param = NULL;
> +		vchan_init(&mchan->vchan, &mdc->dma_slave);

Do you actually make any use what so ever of the vchan support?


From richard.genoud at gmail.com  Wed Jul 10 05:32:42 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Wed, 10 Jul 2013 11:32:42 +0200
Subject: [PATCH v4 2/7] Documentation: DT: add sam9x5ek-wm8731 machine
 driver
In-Reply-To: <20130709150114.GB27646@sirena.org.uk>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-3-git-send-email-richard.genoud@gmail.com>
 <20130709150114.GB27646@sirena.org.uk>
Message-ID: <CACQ1gAjxWYVrOM8wvq7emArO7s_bion-ZgnB9tx3DN5htoV2qw@mail.gmail.com>

2013/7/9 Mark Brown <broonie at kernel.org>:
> On Tue, Jul 09, 2013 at 04:25:28PM +0200, Richard Genoud wrote:
>> This add the sound DT binding for sam9x5ek-wm8731 machine driver
>>
>> Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
>> ---
>>  .../bindings/sound/atmel-sam9x5-wm8731-audio.txt   |   30 ++++++++++++++++++++
>
> Put new binding documents in the same patch that reads them, this makes
> review easier.
ok, I'll squash it with patch 1

>> +  - atmel,audio-routing: A list of the connections between audio components.
>
> This needs to be more specific and list the available board specific
> nodes for routing.  For the CODEC you can just refer to the CODEC
> binding documentation.
Ok, I'll do that.

>> +  - atmel,format: DAI format. Must be "i2s"
>
> So why not just omit this then?
Will be removed.

>
>> +  - atmel,bitclock-master:  DAI clock master
>> +  - atmel,frame-master: DAI frame master
>
> The driver isn't handling these and there's no information on how to set
> them.
They will also go away.


Thanks !


From bp at alien8.de  Wed Jul 10 05:36:42 2013
From: bp at alien8.de (Borislav Petkov)
Date: Wed, 10 Jul 2013 11:36:42 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <CAMuHMdWH9w5fj6HRXi+9QcBJym4dukAFsPVGZVqSSk3yTZJUcA@mail.gmail.com>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130506095124.GA22041@pd.tnic>
 <CAMuHMdWH9w5fj6HRXi+9QcBJym4dukAFsPVGZVqSSk3yTZJUcA@mail.gmail.com>
Message-ID: <20130710093642.GC14873@pd.tnic>

On Wed, Jul 10, 2013 at 10:12:46AM +0200, Geert Uytterhoeven wrote:
> >> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> >> index a0ab6d7..c9bfbb0 100644
> >> --- a/scripts/Makefile.lib
> >> +++ b/scripts/Makefile.lib
> >> @@ -313,7 +313,7 @@ cmd_lzo = (cat $(filter-out FORCE,$^) | \
> >>
> >>  quiet_cmd_lz4 = LZ4     $@
> >>  cmd_lz4 = (cat $(filter-out FORCE,$^) | \
> >> -     lz4demo -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
> >> +     lz4c -l -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
> >
> > You probably want to check for the presence of lz4c on the system and
> > bail with an informative message if absent.
> 
> Yep, x86_64-randconfig
> (http://kisskb.ellerman.id.au/kisskb/buildresult/9110794/):
> 
>   LZ4     arch/x86/boot/compressed/vmlinux.bin.lz4
> /bin/sh: lz4c: command not found

Sure, it had to be 2 months and to hit upstream for there still to be no
fix. Geez...

Anyone reading this and willing to try his skills with an
introductory-level patch, feel free to address this. I'll help testing
and upstreaming it.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--


From jonas.jensen at gmail.com  Wed Jul 10 05:48:19 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 10 Jul 2013 11:48:19 +0200
Subject: [PATCH] dmaengine: Add MOXA ART DMA engine driver
In-Reply-To: <20130710093055.GW24642@n2100.arm.linux.org.uk>
References: <1373446263-7772-1-git-send-email-jonas.jensen@gmail.com>
 <20130710093055.GW24642@n2100.arm.linux.org.uk>
Message-ID: <CACmBeS1SQ=nuYqrMiQmSr6ANfZD9cGyeHQ1+zZyfPeTjoFtgQQ@mail.gmail.com>

On 10 July 2013 11:30, Russell King - ARM Linux <linux at arm.linux.org.uk> wrote:
> Do you actually make any use what so ever of the vchan support?

Only because it was inspired by the edma driver:

static inline struct moxart_dma_chan *to_moxart_dma_chan(struct dma_chan *c)
{
        return container_of(c, struct moxart_dma_chan, vchan.chan);
}

It could use struct dma_chan instead I think.


Best regards,
Jonas


From richard.genoud at gmail.com  Wed Jul 10 05:48:27 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Wed, 10 Jul 2013 11:48:27 +0200
Subject: [PATCH v4 3/7] Documentation: DT: update atmel SSC with DMA
 binding
In-Reply-To: <20130709150543.GE27646@sirena.org.uk>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-4-git-send-email-richard.genoud@gmail.com>
 <20130709150543.GE27646@sirena.org.uk>
Message-ID: <CACQ1gAhK2yN2uhewq8XGOidLCDfOhgRvzE1o0b1krK1DjYj-dA@mail.gmail.com>

2013/7/9 Mark Brown <broonie at kernel.org>:
> On Tue, Jul 09, 2013 at 04:25:29PM +0200, Richard Genoud wrote:
>
>>  - reg: Should contain SSC registers location and length
>>  - interrupts: Should contain SSC interrupt
>> +For dma transfer:
>> +- dmas: DMA specifier, consisting of a phandle to DMA controller node,
>> +  the memory interface and SSC DMA channel ID (for tx and rx).
>> +  See Documentation/devicetree/bindings/dma/atmel-dma.txt for details.
>> +- dma-names: Must be "tx", "rx".
>
> This is added as a required property so...
>
>> -Example:
>> +Examples:
>>  ssc0: ssc at fffbc000 {
>>       compatible = "atmel,at91rm9200-ssc";
>>       reg = <0xfffbc000 0x4000>;
>>       interrupts = <14 4 5>;
>>  };
>
> ...this first example is now invalid and should probably just be being
> extended with the new required properties.

Well, I have to rewrite that to make it clearer.
The thing is:
with "atmel,at91rm9200-ssc" the SSC doesn't work with DMA.
with "atmel,at91sam9g45-ssc", the SSC work ONLY with DMA.

So the dmas/dma-names properties are only required for g45-ssc, and
useless for rm9200-ssc

Maybe the best will be to write a paragraph for g45-ssc and another
for rm9200-ssc, even if there's some identical lines between them.


Thanks !

Richard.


From broonie at kernel.org  Wed Jul 10 05:19:52 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 10 Jul 2013 10:19:52 +0100
Subject: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to
 control PMIC over VC/VP
In-Reply-To: <51DC3487.2080503@ti.com>
References: <20130704154105.GD27646@sirena.org.uk>
 <20130705135507.GA17439@kahuna>
 <20130705140828.GA27646@sirena.org.uk> <51D6DD3A.1030002@ti.com>
 <20130705165235.GC27646@sirena.org.uk> <51D70356.30707@ti.com>
 <20130705174727.GF27646@sirena.org.uk> <51DAF55C.5040502@ti.com>
 <20130709152954.GF27646@sirena.org.uk> <51DC3487.2080503@ti.com>
Message-ID: <20130710091952.GF3179@sirena.org.uk>

On Tue, Jul 09, 2013 at 11:04:23AM -0500, Nishanth Menon wrote:
> On 07/09/2013 10:29 AM, Mark Brown wrote:

> >This seems like something we should be able to cope with by for example
> >adding a bus for the custom PMIC interface or otherwise finding a way to

> I had considered introducing a custom bus for custom PMIC interface,
> but as you stated below, standard regulators will probably need some
> custom monkeying around.

We should just be able to use the platform bus here.

> >get to the data at runtime based on the compatible string.  This would
> >need some custom code in the regulators but would have the advantage of
> >keeping the data the same at least.  Hrm.

> Ofcourse,this will be to add custom set/get_voltage implementation
> using this "custom API" which we discussed was'nt that good an idea.

No, if the regulator isn't being interacted with directly then it
doesn't need to export any operations - just data.  The operations would
come from the magic SoC hardware that controls the regulator.  The code
in the drivers should be very small, if it isn't there's no point in
doing this.

> >>between PMICs? yep, twl4030 does 4mV/uSec, 6030 can do 6mV/uSec,
> >>TPS62361 can do 32mV/uSec, TWL6035/37 does 0.220mV/uSec

> >Those are ramp rates, they're not I2C I/O limits.  Ramp rates we already
> >know about.  I think what you're saying here is that this latency value
> >is actually about worst case ramp times?

> Arrgh.. my bad. I confused ramp time with I2C transfer timeout
> parameter. I know that I2C bus can be held[1] by PMIC as long as it
> is busy. Some custom ASIC can do some weird stuff I suppose. I dont
> seem to have clear data points in the sketchy TRMs for 6030/2 ,
> 6035, 5030, for these other than to state it is i2c specification
> compliant (/me grumbles). So, I just have emperical value which is a
> bit conservative and seem to work on the devices.

OK, no problem - like we said further up the thread I think adding
something to get the data
-------------- 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/20130710/c6ebfb65/attachment-0001.sig>

From voice.shen at atmel.com  Wed Jul 10 05:51:06 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Wed, 10 Jul 2013 17:51:06 +0800
Subject: [PATCH 0/3] arm: atmel: at91sam9n12: add i2c pinctrl and qt1070
 support
Message-ID: <1373449869-5083-1-git-send-email-voice.shen@atmel.com>

this patch is based on linux master branch, implementation as following:
  - add the i2c pinctrl which needed for using at91sam9n12 TWI
  - enable qt1070
  - trivial fix for the gpio-key pin number


Bo Shen (3):
  arm: atmel: at91sam9n12: add pinctrl of TWI
  arm: atmel: at91sam9n12: add qt1070 support
  arm: atmel: at91sam9n12: correct pin number of gpio-key

 arch/arm/boot/dts/at91sam9n12.dtsi  |   20 ++++++++++++++++++++
 arch/arm/boot/dts/at91sam9n12ek.dts |   18 +++++++++++++++++-
 2 files changed, 37 insertions(+), 1 deletion(-)

-- 
1.7.9.5



From voice.shen at atmel.com  Wed Jul 10 05:51:08 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Wed, 10 Jul 2013 17:51:08 +0800
Subject: [PATCH 2/3] arm: atmel: at91sam9n12: add qt1070 support
In-Reply-To: <1373449869-5083-1-git-send-email-voice.shen@atmel.com>
References: <1373449869-5083-1-git-send-email-voice.shen@atmel.com>
Message-ID: <1373449869-5083-3-git-send-email-voice.shen@atmel.com>

add qt1070 support on at91sam9n12ek board

Signed-off-by: Bo Shen <voice.shen at atmel.com>
---
 arch/arm/boot/dts/at91sam9n12ek.dts |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts b/arch/arm/boot/dts/at91sam9n12ek.dts
index d59b70c..3acac62 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -40,6 +40,15 @@
 
 			i2c0: i2c at f8010000 {
 				status = "okay";
+
+				qt1070: keyboard at 1b {
+					compatible = "qt1070";
+					reg = <0x1b>;
+					interrupt-parent = <&pioA>;
+					interrupts = <2 0x0>;
+					pinctrl-names = "default";
+					pinctrl-0 = <&pinctrl_qt1070_irq>;
+				};
 			};
 
 			i2c1: i2c at f8014000 {
@@ -66,6 +75,13 @@
 							<AT91_PIOA 7 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;	/* PA7 gpio CD pin pull up and deglitch */
 					};
 				};
+
+				qt1070 {
+					pinctrl_qt1070_irq: qt1070_irq {
+						atmel,pins =
+							<AT91_PIOA 2 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PA2 GPIO with pull up deglith */
+					};
+				};
 			};
 
 			spi0: spi at f0000000 {
-- 
1.7.9.5



From voice.shen at atmel.com  Wed Jul 10 05:51:07 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Wed, 10 Jul 2013 17:51:07 +0800
Subject: [PATCH 1/3] arm: atmel: at91sam9n12: add pinctrl of TWI
In-Reply-To: <1373449869-5083-1-git-send-email-voice.shen@atmel.com>
References: <1373449869-5083-1-git-send-email-voice.shen@atmel.com>
Message-ID: <1373449869-5083-2-git-send-email-voice.shen@atmel.com>

add pinctrl of TWI for at91sam9n12 SoC

Signed-off-by: Bo Shen <voice.shen at atmel.com>
---
 arch/arm/boot/dts/at91sam9n12.dtsi |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index bb7f564..3db62f6 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -291,6 +291,22 @@
 					};
 				};
 
+				i2c0 {
+					pinctrl_i2c0: i2c0-0 {
+						atmel,pins =
+							<AT91_PIOA 30 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA30 periph A I2C0 data */
+							 AT91_PIOA 31 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PA31 periph A I2C0 clock */
+					};
+				};
+
+				i2c1 {
+					pinctrl_i2c1: i2c1-0 {
+						atmel,pins =
+							<AT91_PIOC 0 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC0 periph C I2C1 data */
+							 AT91_PIOC 1 AT91_PERIPH_C AT91_PINCTRL_NONE>;	/* PC1 periph C I2C1 clock */
+					};
+				};
+
 				tcb0 {
 					pinctrl_tcb0_tclk0: tcb0_tclk0-0 {
 						atmel,pins = <AT91_PIOA 24 AT91_PERIPH_A AT91_PINCTRL_NONE>;
@@ -471,6 +487,8 @@
 				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_i2c0>;
 				status = "disabled";
 			};
 
@@ -483,6 +501,8 @@
 				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_i2c1>;
 				status = "disabled";
 			};
 
-- 
1.7.9.5



From voice.shen at atmel.com  Wed Jul 10 05:51:09 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Wed, 10 Jul 2013 17:51:09 +0800
Subject: [PATCH 3/3] arm: atmel: at91sam9n12: correct pin number of gpio-key
In-Reply-To: <1373449869-5083-1-git-send-email-voice.shen@atmel.com>
References: <1373449869-5083-1-git-send-email-voice.shen@atmel.com>
Message-ID: <1373449869-5083-4-git-send-email-voice.shen@atmel.com>

correct pin number of gpio-key for at91sam9n12ek board
the pioB4 is connect to LED, the pioB3 use as gpio-key

Signed-off-by: Bo Shen <voice.shen at atmel.com>

---
 arch/arm/boot/dts/at91sam9n12ek.dts |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts b/arch/arm/boot/dts/at91sam9n12ek.dts
index 3acac62..9f4c601 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -137,7 +137,7 @@
 
 		enter {
 			label = "Enter";
-			gpios = <&pioB 4 GPIO_ACTIVE_LOW>;
+			gpios = <&pioB 3 GPIO_ACTIVE_LOW>;
 			linux,code = <28>;
 			gpio-key,wakeup;
 		};
-- 
1.7.9.5



From broonie at kernel.org  Wed Jul 10 06:00:20 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 10 Jul 2013 11:00:20 +0100
Subject: [PATCH v4 1/7] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <CACQ1gAgHuAcBAAgYaP-n9grrM6X0L9b1mFFfkRg0HH_RnRuXMg@mail.gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-2-git-send-email-richard.genoud@gmail.com>
 <20130709145917.GA27646@sirena.org.uk>
 <CACQ1gAgHuAcBAAgYaP-n9grrM6X0L9b1mFFfkRg0HH_RnRuXMg@mail.gmail.com>
Message-ID: <20130710100020.GA24508@sirena.org.uk>

On Wed, Jul 10, 2013 at 11:25:37AM +0200, Richard Genoud wrote:
> 2013/7/9 Mark Brown <broonie at kernel.org>:

> > Shouldn't the SSC driver be enforcing this constraint if it comes from
> > the SSC hardware?  If the clock is reprogrammable the usual convention
> > for drivers is to not constrain if the clock is set to zero so a machine
> > driver could remove the constraint.

> Actually, my comment is buggy here (or at least, unrelated to the
> authorized rates).
> The "MCLK_RATE" is the master clock of the wm8731 codec (a 12.288MHz crystal).
> According to the datasheet of wm8731, when a 12.288 crystal is used,
> the authorized rates are 8, 32, 48 and 96kHz (I have to remove 16 and
> 64kHz).

> So, is this the right place for the rates ?

No, the CODEC driver should be enforcing the restrictions if that's
where they come from.
-------------- 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/20130710/45362626/attachment.sig>

From broonie at kernel.org  Wed Jul 10 06:01:50 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 10 Jul 2013 11:01:50 +0100
Subject: [PATCH v4 3/7] Documentation: DT: update atmel SSC with DMA
 binding
In-Reply-To: <CACQ1gAhK2yN2uhewq8XGOidLCDfOhgRvzE1o0b1krK1DjYj-dA@mail.gmail.com>
References: <1373372929-17800-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-1-git-send-email-richard.genoud@gmail.com>
 <1373379933-32749-4-git-send-email-richard.genoud@gmail.com>
 <20130709150543.GE27646@sirena.org.uk>
 <CACQ1gAhK2yN2uhewq8XGOidLCDfOhgRvzE1o0b1krK1DjYj-dA@mail.gmail.com>
Message-ID: <20130710100150.GB24508@sirena.org.uk>

On Wed, Jul 10, 2013 at 11:48:27AM +0200, Richard Genoud wrote:
> 2013/7/9 Mark Brown <broonie at kernel.org>:

> > ...this first example is now invalid and should probably just be being
> > extended with the new required properties.

> Well, I have to rewrite that to make it clearer.
> The thing is:
> with "atmel,at91rm9200-ssc" the SSC doesn't work with DMA.
> with "atmel,at91sam9g45-ssc", the SSC work ONLY with DMA.

> So the dmas/dma-names properties are only required for g45-ssc, and
> useless for rm9200-ssc

> Maybe the best will be to write a paragraph for g45-ssc and another
> for rm9200-ssc, even if there's some identical lines between them.

OK, or just write a section "Required for devices with compatible X".
-------------- 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/20130710/2065b88d/attachment.sig>

From b32955 at freescale.com  Wed Jul 10 05:40:26 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 10 Jul 2013 17:40:26 +0800
Subject: [PATCH 1/2] ARM: dts: imx6q{dl}: add a new pinctrl for uart3
Message-ID: <1373449227-11740-1-git-send-email-b32955@freescale.com>

Add the a new pinctrl for uart3. In the imx6q{dl}-sabreauto boards,
the uart3 is used for Bluetooth.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6dl.dtsi |   11 +++++++++++
 arch/arm/boot/dts/imx6q.dtsi  |   11 +++++++++++
 2 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index a1302ed..d818ced 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -234,6 +234,17 @@
 					};
 				};
 
+				uart3 {
+					pinctrl_uart3_1: uart3grp-1 {
+						fsl,pins = <
+							MX6DL_PAD_SD4_CLK__UART3_RX_DATA 0x1b0b1
+							MX6DL_PAD_SD4_CMD__UART3_TX_DATA 0x1b0b1
+							MX6DL_PAD_EIM_D30__UART3_CTS_B   0x1b0b1
+							MX6DL_PAD_EIM_EB3__UART3_RTS_B   0x1b0b1
+						>;
+					};
+				};
+
 				uart4 {
 					pinctrl_uart4_1: uart4grp-1 {
 						fsl,pins = <
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index e0b7bad..1984ca4 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -277,6 +277,17 @@
 					};
 				};
 
+				uart3 {
+					pinctrl_uart3_1: uart3grp-1 {
+						fsl,pins = <
+							MX6Q_PAD_SD4_CLK__UART3_RX_DATA 0x1b0b1
+							MX6Q_PAD_SD4_CMD__UART3_TX_DATA 0x1b0b1
+							MX6Q_PAD_EIM_D30__UART3_CTS_B   0x1b0b1
+							MX6Q_PAD_EIM_EB3__UART3_RTS_B   0x1b0b1
+						>;
+					};
+				};
+
 				uart4 {
 					pinctrl_uart4_1: uart4grp-1 {
 						fsl,pins = <
-- 
1.7.1




From b32955 at freescale.com  Wed Jul 10 05:40:27 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 10 Jul 2013 17:40:27 +0800
Subject: [PATCH 2/2] ARM: dts: imx6q{dl}-sabreauto: add a DT node for uart3
In-Reply-To: <1373449227-11740-1-git-send-email-b32955@freescale.com>
References: <1373449227-11740-1-git-send-email-b32955@freescale.com>
Message-ID: <1373449227-11740-2-git-send-email-b32955@freescale.com>

Add a dt node for uart3, in the imx6q{dl}-sabreauto boards,
the uart3 is used by Bluetooth.

Since the uart3 has pin conflict with gpmi and weim nor, we keep it
disabled by default.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index e994011..765c9d5 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -45,6 +45,15 @@
 	status = "okay";
 };
 
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart3_1>;
+	fsl,uart-has-rtscts;
+	dma-names = "rx", "tx";
+	dmas = <&sdma 29 4 0>, <&sdma 30 4 0>;
+	status = "disabled"; /* used by the BT, pin conflict with gpmi and weim NOR */
+};
+
 &uart4 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart4_1>;
-- 
1.7.1




From gerlando.falauto at keymile.com  Wed Jul 10 06:29:07 2013
From: gerlando.falauto at keymile.com (Gerlando Falauto)
Date: Wed, 10 Jul 2013 12:29:07 +0200
Subject: [PATCH] net: mv643xx_eth: fix DT port device name
In-Reply-To: <20130708000540.00004b37@unknown>
References: <1373229231-8838-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130707234341.0000721b@unknown> <20130708000540.00004b37@unknown>
Message-ID: <51DD3773.1050408@keymile.com>

Hi Sebastian, Jonas,

first of all thank you for your HUGE efforts in this area.

On 07/08/2013 12:05 AM, Jonas Gorski wrote:
> On Sun, 7 Jul 2013 23:43:41 +0200
> Jonas Gorski <jogo at openwrt.org> wrote:
>
>> On Sun,  7 Jul 2013 22:33:51 +0200
>> Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> wrote:
>>
>>> Device tree support added to Marvell MV643xx ethernet driver registers
>>> port devices from port device nodes found on the corresponding controller
>>> node. The current port device name will cause the second controller to
>>> fail on registration because of two identical device names. This fixes
>>> the issue by taking the device node's name also as port device name.
>>>
>>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
>>> Reported-by: Jonas Gorski <jogo at openwrt.org>
>>> ---
>>> Cc: Lennert Buytenhek <buytenh at wantstofly.org>
>>> Cc: Jonas Gorski <jogo at openwrt.org>
>>> Cc: netdev at vger.kernel.org
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: linux-kernel at vger.kernel.org
>>> ---
>>>   drivers/net/ethernet/marvell/mv643xx_eth.c |    2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
>>> index 6495bea..1f3a03d 100644
>>> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
>>> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
>>> @@ -2521,7 +2521,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
>>>   		of_property_read_u32(pnp, "duplex", &ppd.duplex);
>>>   	}
>>>
>>> -	ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
>>> +	ppdev = platform_device_alloc(pnp->name, ppd.port_number);
>>>   	if (!ppdev)
>>>   		return -ENOMEM;
>>>   	ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>>
>> This breaks ethernet completely, as there is no platform driver
>> registered for pnp->name ("ethernetX-port"), only for MV643XX_ETH_NAME.
>
> Looking back at our conversation, this is my fault.
> I actually did not change this part as you asked, but I saw the
> alloc/del issue with port 0, then added the counter and also only
> replaced the ppd.port_number in the alloc with it. I had completely
> forgotten at that time to replace the device name; else I would
> have caught it back then.
>
> I only caught it now because I tried your patch and wondered why there
> wasn't anything registered, not because I saw the problem by review.
>

The way I understand it, you are "manually" creating platform devices 
off the port subnodes (which, incidentally, have a compatible = 
"marvell,kirkwood-eth-port" property), but matching with the driver is 
indeed performed by device name.
Hence Sebastian's first patch breaks everything and Jonas' latest one 
fixes it. Is that correct? Is there any more work ongoing in this area?

One more question: if my understanding above is correct, what's the 
reason for NOT having an of_device_id[] table, which looks like was 
present in Florian Fainelli's first proposal [1]?

I'm also willing to help testing your present/future kirkwood patches if 
you like. Please just put me on Cc:

Thank you,
Gerlando

[1] http://lists.openwall.net/netdev/2013/04/04/42

> Sorry for that.
>
> Regards
> Jonas
>



From srinivas.kandagatla at st.com  Wed Jul 10 06:27:24 2013
From: srinivas.kandagatla at st.com (Srinivas KANDAGATLA)
Date: Wed, 10 Jul 2013 11:27:24 +0100
Subject: [PATCH v1 0/4] ARM: STi fixes and ethernet support
In-Reply-To: <201307092315.06131.arnd@arndb.de>
References: <1373271301-11060-1-git-send-email-srinivas.kandagatla@st.com>
 <201307090956.03191.arnd@arndb.de> <51DBE718.2080007@st.com>
 <201307092315.06131.arnd@arndb.de>
Message-ID: <51DD370C.20902@st.com>

Hi Arnd,
On 09/07/13 22:15, Arnd Bergmann wrote:
>> For DT case, At the moment I think callbacks at MACH level is one
>> > possible solution. But am open for any discussions.
> Ok, so a PHY driver might not be the best place to put this, but it's
> one option, since the PHY driver already has to know about the
> interface speed you are setting.
> 
> Having a global "*_setup_ethernet" callback is definitely not the
> right way to go. Please describe what the function actually does
> so we can come up with the right subsystem to move that functionality
> to. If you are setting clocks, you should use the clock subsystem,
> for taking the device out of reset, you should use the reset controller
> subsystem and for setting up the phy, you should use the phy subsystem,
> etc.

The purpose of this callback is to do three things.

	1> Configuring the MAC signals to select particular PHY interface mode.
MAC signals(wires) are wired up to this Ethernet Configuration register.

	2> Select synchronisation clock for data lines retiming. On High speed
interfaces track length/layouts on the boards can directly influence the
signal quality and introduce bit shifts or other errors. So SoC has
additional logic to retime these signals and improve the data
reliability. As there is possibility of multiple clock sources (MAC,
PHY) a correct choice of synchronization clock is made in Ethernet
configuration register. For 125 Mhz clock in Gbit mode, reference clock
is provided by the PHY in other case like 100bit and 10bit, 50MHz, 25MHz
clocks is provide by the MAC.
So this bits depend/driven based on the PHYMODEs and Link Speed.

	3> Ethernet Soft reset in Ethernet control register.
		Which can probably go into via reset controller driver.


For point 1 and 2, there is no subsystem in the kernel which can
accommodate these kind of SOC specific bits setup. Am not sure if other
platforms have similar SoC setup use cases?

For point 3, I can go for reset controller API.

Just for your reference (Sorry and Please ignore if Its too detailed),
Ethernet configuration register looks like:
Bit to configure signals connected to MAC.
	[5] ENMII1: when 1, MII mode
		when 0, Reverse MII mode
	[4:2] MII1_PHY_SEL:
		000: GMII/MII (default)
		001: RGMII
		010: SGMII
		100: RMII

Bit to configure retiming clock for retiming data lines:
	[8] ETH1_SEL_TX_RETIMING_CLK: Selection of the clock used to retime TX data
		0: clock selected by ETH1_SEL_TXCLK_NOT_CLK125 bit
		1: clock fed to or provided by MII_PHYCLK depending
		on eth1_sel_internal_notext_phyclk setting
	[7] ETH1_SEL_INTERNAL_NOTEXT_PHYCLK: Selection of internal clock or
external clock from MII_PHYCLK for retiming in RMII mode
		0: external clock (Beware that eth1_sel_tx_retiming_clk
		bit must also be programmed).
		1: internal clock (from clockgenA)
	[6] ETH1_SEL_TXCLK_NOT_CLK125: Selection of the clock used to
	retime TX data
		0: MII1_CLK_125 (beware that eth1_sel_tx_retiming_clk bit must also be
programmed)
		1: MII1_TXCLK

Thanks,
srini


From magnus.damm at gmail.com  Wed Jul 10 06:41:51 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 10 Jul 2013 19:41:51 +0900
Subject: [PATCH] ARM: shmobile: r8a7790 SMP prototype v4
Message-ID: <20130710104151.20742.56398.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Add SMP prototype support for r8a7790 by enabling
one cluster of either 4 x Cortex-A7 or 4 x Cortex-A15.

This patch only adds support for booting, at this point
no CPU Hotplug is included. In v4 both the big and the
LITTLE clusters are working with either architected timers
(in physical mode only for CA7) or CMT and broadcast timer.

On r8a7790 the MD6 pin control boot processor, and on the
Lager board SW8.7 can be used to select big or LITTLE.

In big boot mode the CPU cores will be configured as:
 - CPU0, CPU1, CPU2, CPU3: enabled (CA15)
 - CPU4, CPU5, CPU6, CPU7: disabled (CA7)

In LITTLE boot mode the CPU cores will be configured as:
 - CPU0, CPU5, CPU6, CPU7: enabled (CA7)
 - CPU1, CPU2, CPU3, CPU4: disabled (CA15)

Base addresses for RST and APMU are still hard coded
but DT will be used for them in future versions.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Changes since v3:
 - Use linux/io.h and clean up headers in general - thanks RMK!
 - Use readl/writel_relaxed() and memcpy_toio() - thanks Arnd!
 - Instead of cached memory and cache flush use uncached ioremap for MERAM.
 - Use correct addr for CABAR7/15, adjust RST size - thanks Kuribayashi-san!
 - Remove SYSC as it apparently does not need to be polled after all.
 - Add SMP ops for Lager DT Reference

 Written against kernel.org renesas git tag renesas-next-20130710

 arch/arm/boot/dts/r8a7790.dtsi                 |   49 +++++++
 arch/arm/mach-shmobile/Makefile                |    1 
 arch/arm/mach-shmobile/board-lager-reference.c |    1 
 arch/arm/mach-shmobile/board-lager.c           |    1 
 arch/arm/mach-shmobile/include/mach/common.h   |    1 
 arch/arm/mach-shmobile/include/mach/r8a7790.h  |    1 
 arch/arm/mach-shmobile/setup-r8a7790.c         |    1 
 arch/arm/mach-shmobile/smp-r8a7790.c           |  166 ++++++++++++++++++++++++
 8 files changed, 221 insertions(+)

--- 0001/arch/arm/boot/dts/r8a7790.dtsi
+++ work/arch/arm/boot/dts/r8a7790.dtsi	2013-07-10 19:18:36.000000000 +0900
@@ -24,6 +24,55 @@
 			reg = <0>;
 			clock-frequency = <1300000000>;
 		};
+
+		cpu1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <1>;
+			clock-frequency = <1300000000>;
+		};
+
+		cpu2: cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <2>;
+			clock-frequency = <1300000000>;
+		};
+
+		cpu3: cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <3>;
+			clock-frequency = <1300000000>;
+		};
+
+		cpu4: cpu at 4 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x100>;
+			clock-frequency = <780000000>;
+		};
+
+		cpu5: cpu at 5 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x101>;
+			clock-frequency = <780000000>;
+		};
+
+		cpu6: cpu at 6 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x102>;
+			clock-frequency = <780000000>;
+		};
+
+		cpu7: cpu at 7 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x103>;
+			clock-frequency = <780000000>;
+		};
 	};
 
 	gic: interrupt-controller at f1001000 {
--- 0001/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-07-10 19:18:36.000000000 +0900
@@ -19,6 +19,7 @@ obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.
 smp-y				:= platsmp.o headsmp.o
 smp-$(CONFIG_ARCH_SH73A0)	+= smp-sh73a0.o headsmp-scu.o
 smp-$(CONFIG_ARCH_R8A7779)	+= smp-r8a7779.o headsmp-scu.o
+smp-$(CONFIG_ARCH_R8A7790)	+= smp-r8a7790.o
 smp-$(CONFIG_ARCH_EMEV2)	+= smp-emev2.o headsmp-scu.o
 
 # IRQ objects
--- 0001/arch/arm/mach-shmobile/board-lager-reference.c
+++ work/arch/arm/mach-shmobile/board-lager-reference.c	2013-07-10 19:18:36.000000000 +0900
@@ -38,6 +38,7 @@ static const char *lager_boards_compat_d
 };
 
 DT_MACHINE_START(LAGER_DT, "lager")
+	.smp		= smp_ops(r8a7790_smp_ops),
 	.init_early	= r8a7790_init_delay,
 	.init_machine	= lager_add_standard_devices,
 	.init_time	= r8a7790_timer_init,
--- 0001/arch/arm/mach-shmobile/board-lager.c
+++ work/arch/arm/mach-shmobile/board-lager.c	2013-07-10 19:18:36.000000000 +0900
@@ -133,6 +133,7 @@ static const char *lager_boards_compat_d
 };
 
 DT_MACHINE_START(LAGER_DT, "lager")
+	.smp		= smp_ops(r8a7790_smp_ops),
 	.init_early	= r8a7790_init_delay,
 	.init_time	= r8a7790_timer_init,
 	.init_machine	= lager_add_standard_devices,
--- 0001/arch/arm/mach-shmobile/include/mach/common.h
+++ work/arch/arm/mach-shmobile/include/mach/common.h	2013-07-10 19:18:36.000000000 +0900
@@ -11,6 +11,7 @@ extern void shmobile_boot_vector(void);
 extern unsigned long shmobile_boot_fn;
 extern unsigned long shmobile_boot_arg;
 extern void shmobile_boot_scu(void);
+extern void shmobile_invalidate_start(void);
 struct clk;
 extern int shmobile_clk_init(void);
 extern void shmobile_handle_irq_intc(struct pt_regs *);
--- 0001/arch/arm/mach-shmobile/include/mach/r8a7790.h
+++ work/arch/arm/mach-shmobile/include/mach/r8a7790.h	2013-07-10 19:18:36.000000000 +0900
@@ -7,5 +7,6 @@ void r8a7790_clock_init(void);
 void r8a7790_pinmux_init(void);
 void r8a7790_init_delay(void);
 void r8a7790_timer_init(void);
+extern struct smp_operations r8a7790_smp_ops;
 
 #endif /* __ASM_R8A7790_H__ */
--- 0001/arch/arm/mach-shmobile/setup-r8a7790.c
+++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-07-10 19:18:36.000000000 +0900
@@ -228,6 +228,7 @@ static const char *r8a7790_boards_compat
 };
 
 DT_MACHINE_START(R8A7790_DT, "Generic R8A7790 (Flattened Device Tree)")
+	.smp		= smp_ops(r8a7790_smp_ops),
 	.init_early	= r8a7790_init_delay,
 	.init_time	= r8a7790_timer_init,
 	.dt_compat	= r8a7790_boards_compat_dt,
--- /dev/null
+++ work/arch/arm/mach-shmobile/smp-r8a7790.c	2013-07-10 19:20:50.000000000 +0900
@@ -0,0 +1,166 @@
+/*
+ * SMP support for r8a7790
+ *
+ * Copyright (C) 2012-2013 Renesas Solutions Corp.
+ * Copyright (C) 2012 Takashi Yoshii <takashi.yoshii.ze at renesas.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/smp.h>
+#include <linux/io.h>
+#include <asm/smp_plat.h>
+#include <mach/common.h>
+
+#define RST	0xe6160000
+#define CA15BAR	0x0020
+#define CA7BAR	0x0030
+#define CA15RESCNT 0x0040
+#define CA7RESCNT 0x0044
+#define RESCNT	0x0050
+
+#define APMU	0xe6150000
+#define CA15WUPCR 0x2010
+#define CA7WUPCR 0x1010
+
+#define MERAM	0xe8080000
+
+enum { R8A7790_CLST_CA15, R8A7790_CLST_CA7, R8A7790_CLST_NR };
+
+static struct {
+	unsigned int cabar;
+	unsigned int carescnt;
+	unsigned int carescnt_magic;
+	unsigned int rescnt_bit;
+	unsigned int use_count;
+} r8a7790_clst[R8A7790_CLST_NR] = {
+	[R8A7790_CLST_CA15] = {
+		.cabar = CA15BAR,
+		.carescnt = CA15RESCNT,
+		.carescnt_magic = 0xa5a50000,
+		.rescnt_bit = 1,
+	},
+	[R8A7790_CLST_CA7] = {
+		.cabar = CA7BAR,
+		.carescnt = CA7RESCNT,
+		.carescnt_magic = 0x5a5a0000,
+		.rescnt_bit = 0,
+	},
+};
+
+#define r8a7790_clst_id(cpu) (cpu_logical_map((cpu)) >> 8)
+#define r8a7790_cpu_id(cpu) (cpu_logical_map((cpu)) & 0xff)
+
+static void r8a7790_deassert_reset(unsigned int cpu)
+{
+	void __iomem *p, *carescnt;
+	u32 bar, mask, magic;
+	unsigned int clst_id = r8a7790_clst_id(cpu);
+
+	/* setup reset vectors */
+	p = ioremap_nocache(RST, 0x63);
+	bar = (MERAM >> 8) & 0xfffffc00;
+	writel_relaxed(bar, p + r8a7790_clst[clst_id].cabar);
+	writel_relaxed(bar | 0x10, p + r8a7790_clst[clst_id].cabar);
+
+	/* enable clocks for cluster */
+	if (r8a7790_clst[clst_id].use_count++ == 0) {
+		mask = 1 << r8a7790_clst[clst_id].rescnt_bit;
+		writel_relaxed(readl_relaxed(p + RESCNT) & ~mask, p + RESCNT);
+	}
+
+	/* enable per-core clocks */
+	mask = BIT(3 - r8a7790_cpu_id(cpu));
+	magic = r8a7790_clst[clst_id].carescnt_magic;
+	carescnt = p + r8a7790_clst[clst_id].carescnt;
+	writel_relaxed((readl_relaxed(carescnt) & ~mask) | magic, carescnt);
+
+	iounmap(p);
+}
+
+static void r8a7790_assert_reset(unsigned int cpu)
+{
+	void __iomem *p, *carescnt;
+	u32 mask, magic;
+	unsigned int clst_id = r8a7790_clst_id(cpu);
+
+	p = ioremap_nocache(RST, 0x63);
+
+	/* disable per-core clocks */
+	mask = BIT(3 - r8a7790_cpu_id(cpu));
+	magic = r8a7790_clst[clst_id].carescnt_magic;
+	carescnt = p + r8a7790_clst[clst_id].carescnt;
+	writel_relaxed((readl_relaxed(carescnt) | mask) | magic, carescnt);
+
+	/* disable clocks for cluster */
+	if (r8a7790_clst[clst_id].use_count == 1) {
+		mask = 1 << r8a7790_clst[clst_id].rescnt_bit;
+		writel_relaxed(readl_relaxed(p + RESCNT) | mask, p + RESCNT);
+	}
+
+	if (r8a7790_clst[clst_id].use_count > 0)
+		r8a7790_clst[clst_id].use_count--;
+
+	iounmap(p);
+}
+
+static void r8a7790_power_on(unsigned int cpu)
+{
+	void __iomem *p, *cawupcr;
+
+	/* wake up CPU core via APMU */
+	p = ioremap_nocache(APMU, 0x3000);
+	cawupcr = p + (r8a7790_clst_id(cpu) ? CA7WUPCR : CA15WUPCR);
+	writel_relaxed(BIT(r8a7790_cpu_id(cpu)), cawupcr);
+
+	/* wait for APMU to finish */
+	while (readl_relaxed(cawupcr) != 0)
+		;
+
+	iounmap(p);
+}
+
+static void __init r8a7790_smp_prepare_cpus(unsigned int max_cpus)
+{
+	void __iomem *p;
+	unsigned int k;
+
+	shmobile_boot_fn = virt_to_phys(shmobile_invalidate_start);
+
+	/* MERAM for jump stub, because BAR requires 256KB aligned address */
+	p = ioremap_nocache(MERAM, 16);
+	memcpy_toio(p, shmobile_boot_vector, 16);
+	iounmap(p);
+
+	/* keep secondary CPU cores in reset, but powered on */
+	for (k = 1; k < 8; k++) {
+		r8a7790_assert_reset(k);
+		r8a7790_power_on(k);
+	}
+
+	r8a7790_deassert_reset(0);
+}
+
+static int __cpuinit r8a7790_boot_secondary(unsigned int cpu,
+					    struct task_struct *idle)
+{
+	/* only allow a single cluster for now */
+	if (r8a7790_clst_id(cpu) != r8a7790_clst_id(0))
+		return -ENOTSUPP;
+
+	r8a7790_deassert_reset(cpu);
+	return 0;
+}
+
+struct smp_operations r8a7790_smp_ops __initdata = {
+	.smp_prepare_cpus	= r8a7790_smp_prepare_cpus,
+	.smp_boot_secondary	= r8a7790_boot_secondary,
+};


From ashishsangwan2 at gmail.com  Wed Jul 10 06:42:25 2013
From: ashishsangwan2 at gmail.com (Ashish Sangwan)
Date: Wed, 10 Jul 2013 19:42:25 +0900
Subject: Seg fault occurs when running statically compiled binary from
 kernel using call_usermodehelper
In-Reply-To: <CAOiN93=Nx77RkbNuEJMV617MjV5+GmorF0G3vyLy1SwQcuCs+g@mail.gmail.com>
References: <CAOiN93mGTu9w9rVNCrbbH1sccXY9VJhaCmg+dS7Rk9mMgKHBaA@mail.gmail.com>
 <CAOiN93=Nx77RkbNuEJMV617MjV5+GmorF0G3vyLy1SwQcuCs+g@mail.gmail.com>
Message-ID: <CAOiN93nH9fyHoz4yrZmJ-OKCy6ogdt5bYartXCBgP5eHMUBPdw@mail.gmail.com>

Any heads up on this?

or could someone just advice what can we do to debug this?

The ret_from_fork currently looks like following:
/*
 * This is how we return from a fork.
 */
ENTRY(ret_from_fork)
        bl      schedule_tail
        cmp     r5, #0
        movne   r0, r4
        adrne   lr, BSYM(1f)
        movne   pc, r5
1:      get_thread_info tsk
        b       ret_slow_syscall
ENDPROC(ret_from_fork)

Is this a real issue? Because we are getting this just for static binaries.

On Mon, Jul 8, 2013 at 10:46 AM, Ashish Sangwan
<ashishsangwan2 at gmail.com> wrote:
> Forget to mention, we are using ARM
>
> On Mon, Jul 8, 2013 at 10:45 AM, Ashish Sangwan
> <ashishsangwan2 at gmail.com> wrote:
>> On kernel version 3.8.13, when we try to execute a statically compiled
>> binary from kernel, it is giving segfault:
>>
>> insmod /mnt/module2.ko
>> [   35.560000] sample.static: unhandled page fault (11) at 0x00000000,
>> code 0x80000007
>> [   36.440000] Pid: 257, comm:        sample.static
>> [   36.444000] CPU: 3    Tainted: G        W  O  (3.8.13+ #35)
>> [   36.448000] PC is at 0x0
>> [   36.452000] LR is at 0xa420
>> [   36.456000] pc : [<00000000>]    lr : [<0000a420>]    psr: 60000030
>> [   36.456000] sp : beb30d70  ip : 00000004  fp : 00000000
>> [   36.464000] r10: 0000a004  r9 : 0000a0a4  r8 : 00000001
>> [   36.472000] r7 : 00000001  r6 : 0008be5c  r5 : 00000000  r4 : 0008ce80
>> [   36.476000] r3 : 00000001  r2 : 00000001  r1 : 00000000  r0 : 00000000
>> [   36.484000] Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA Thumb
>> Segment user
>> [   36.492000] Control: 10c53c7d  Table: 7b1f806a  DAC: 00000015
>> [   36.496000] Backtrace:
>> [   36.500000] [<c00171f8>] (dump_backtrace+0x0/0x11c) from
>> [<c03e8a54>] (dump_stack+0x20/0x24)
>> [   36.508000]  r6:e514dd80 r5:00000000 r4:e5175fb0 r3:271ae511
>> [   36.516000] [<c03e8a34>] (dump_stack+0x0/0x24) from [<c0014174>]
>> (show_regs+0x58/0x5c)
>> [   36.524000] [<c001411c>] (show_regs+0x0/0x5c) from [<c001794c>]
>> (show_info+0xe0/0x14c)
>> [   36.532000]  r4:00000000 r3:00000000
>> [   36.532000] [<c001786c>] (show_info+0x0/0x14c) from [<c001dfb4>]
>> (__do_user_fault+0x78/0xc8)
>> [   36.540000]  r7:80000007 r6:0000000b r5:00000000 r4:e514dd80
>> [   36.548000] [<c001df3c>] (__do_user_fault+0x0/0xc8) from
>> [<c03f4574>] (do_page_fault+0x360/0x3d4)
>> [   36.556000] [<c03f4214>] (do_page_fault+0x0/0x3d4) from
>> [<c0008470>] (do_PrefetchAbort+0x44/0xa8)
>> [   36.564000] [<c000842c>] (do_PrefetchAbort+0x0/0xa8) from
>> [<c03f2bbc>] (ret_from_exception+0x0/0x10)
>> [   36.572000] Exception stack(0xe5175fb0 to 0xe5175ff8)
>> [   36.960000] do_init_module: 'module2'->init suspiciously returned
>> 11, it should follow 0/-E convention
>> [   36.960000] do_init_module: loading module anyway...
>> [   36.964000] Backtrace:
>> [   36.968000] [<c00171f8>] (dump_backtrace+0x0/0x11c) from
>> [<c03e8a54>] (dump_stack+0x20/0x24)
>> [   36.972000]  r6:bf000090 r5:bf00009c r4:e51d7f48 r3:00000000
>> [   36.980000] [<c03e8a34>] (dump_stack+0x0/0x24) from [<c008ae88>]
>> (load_module+0x1a90/0x1eb4)
>> [   36.984000] [<c00893f8>] (load_module+0x0/0x1eb4) from [<c008b3b0>]
>> (sys_init_module+0xe8/0xf8)
>> [   36.988000] [<c008b2c8>] (sys_init_module+0x0/0xf8) from
>> [<c0012dc0>] (ret_fast_syscall+0x0/0x48)
>> [   36.992000]  r6:bea51a14 r5:bea51b7c r4:00006ee4
>> [   36.996000] module2 mod ld
>>
>> module2.c =>
>> #include <linux/module.h>
>> #include <linux/init.h>
>> #include <linux/kmod.h>
>> MODULE_LICENSE( "GPL" );
>> static int test( void )
>> {
>>   char *argv[] = { "/mnt/sample.static", NULL };
>>   static char *envp[] = {
>>         "HOME=/",
>>         "TERM=linux",
>>         "PATH=/sbin:/bin:/usr/sbin:/usr/bin", NULL };
>>   return call_usermodehelper(argv[0], argv, envp, UMH_WAIT_PROC );
>> }
>> static int __init mod_entry_func( void )
>> {
>>   return test();
>> }
>>
>> static void __exit mod_exit_func( void )
>> {
>>   return;
>> }
>> module_init( mod_entry_func );
>> module_exit( mod_exit_func );
>>
>>
>> sample.static is a simple "Hello_world" program.
>>
>> However, there is no problem in executing dynamically compiled binaries.
>>
>> When we revert commit 9fff2fa0db911b0b75ec1f9bec72460c0a676ef5 (arm:
>> switch to saner kernel_execve() semantics), there is no problem.
>>
>> OR
>>
>> for kernel 3.8.13 (which is just a plain revert when arch specific
>> kernel_execve was present), then also no problem =>
>>
>> diff --git a/kernel/kmod.c b/kernel/kmod.c
>> index 0023a87..9cf6e15 100644
>> --- a/kernel/kmod.c
>> +++ b/kernel/kmod.c
>> @@ -184,6 +184,10 @@ static int ____call_usermodehelper(void *data)
>>         struct subprocess_info *sub_info = data;
>>         struct cred *new;
>>         int retval;
>> +#ifdef ARM
>> +       struct pt_regs regs;
>> +       struct pt_regs *curr_ptr;
>> +#endif
>>         spin_lock_irq(&current->sighand->siglock);
>>         flush_signal_handlers(current, 1);
>> @@ -222,6 +226,36 @@ static int ____call_usermodehelper(void *data)
>>         retval = do_execve(sub_info->path,
>>                            (const char __user *const __user *)sub_info->argv,
>>                            (const char __user *const __user *)sub_info->envp);
>> +
>> +#ifdef ARM
>> +       if (retval)
>> +               goto fail;
>> +       curr_ptr = current_pt_regs();
>> +       memcpy(&regs, curr_ptr, sizeof(struct pt_regs));
>> +       /*
>> +        * Save argc to the register structure for userspace.
>> +        */
>> +       regs.ARM_r0 = retval;
>> +
>> +       /*
>> +        * We were successful.  We won't be returning to our caller, but
>> +        * instead to user space by manipulating the kernel stack.
>> +        */
>> +       asm(    "add    r0, %0, %1\n\t"
>> +               "mov    r1, %2\n\t"
>> +               "mov    r2, %3\n\t"
>> +               "bl     memmove\n\t"    /* copy regs to top of stack */
>> +               "mov    r8, #0\n\t"     /* not a syscall */
>> +               "mov    r9, %0\n\t"     /* thread structure */
>> +               "mov    sp, r0\n\t"     /* reposition stack pointer */
>> +               "b      ret_to_user"
>> +               :
>> +               : "r" (current_thread_info()),
>> +                 "Ir" (THREAD_START_SP - sizeof(regs)),
>> +                 "r" (&regs),
>> +                 "Ir" (sizeof(regs))
>> +               : "r0", "r1", "r2", "r3", "r8", "r9", "ip", "lr", "memory");
>> +#endif
>>         if (!retval)
>>                 return 0;
>> --
>>
>> Please suggest a proper solution.
>>
>> Regards,
>> Ashish


From inki.dae at samsung.com  Wed Jul 10 07:58:45 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Wed, 10 Jul 2013 20:58:45 +0900
Subject: [RFC PATCH v4 0/2] Introduce buffer synchronization framework
Message-ID: <1373457527-28263-1-git-send-email-inki.dae@samsung.com>

Hi all,

This patch set introduces a buffer synchronization framework based
on DMA BUF[1] and reservation[2] to use dma-buf resource, and based
on ww-mutexes[3] for lock mechanism.

The purpose of this framework is to provide not only buffer access
control to CPU and CPU, and CPU and DMA, and DMA and DMA but also
easy-to-use interfaces for device drivers and user application.
In addtion, this patch set suggests a way for enhancing performance.

to implement generic user mode interface, we have used fcntl system
call[4]. As you know, user application sees a buffer object as
a dma-buf file descriptor. So fcntl() call with the file descriptor
means to lock some buffer region being managed by the dma-buf object.
For more detail, you can refer to the dma-buf-sync.txt in Documentation/

Moreover, we had tried to find how we could utilize limited hardware
resources more using buffer synchronization mechanism. And finally,
we have realized that it could enhance performance using multi threads
with this buffer synchronization mechanism: DMA and CPU works individually
so CPU could perform other works while DMA is performing some works,
and vise versa.

However, in the conventional way, that is not easy to do so because DMA
operation is depend on CPU operation, and vice versa.

Conventional way:
	User                                     Kernel
	---------------------------------------------------------------------
	CPU writes something to src
	send the src to driver------------------------->
	                                         update DMA register
	request DMA start(1)--------------------------->
						 DMA start
		<---------completion signal(2)----------
	CPU accesses dst

	(1) Request DMA start after the CPU access to src buffer is completed.
	(2) Access dst buffer after DMA access to the dst buffer is completed.

On the other hand, if there is something to control buffer access between CPU
and DMA? The below shows that:

	User(thread a)          User(thread b)            Kernel
	---------------------------------------------------------------------
	send a src to driver---------------------------------->
		                                          update DMA register
        lock the src
	                        request DMA start(1)---------->
	CPU acccess to src
	unlock the src		                          lock src and dst
							  DMA start
		<-------------completion signal(2)-------------
	lock dst	                                  DMA completion
	CPU access to dst				  unlock src and dst
	unlock DST

	(1) Try to start DMA operation while CPU is accessing the src buffer.
	(2) Try CPU access to dst buffer while DMA is accessing the dst buffer.

	This means that CPU or DMA could do more works.

	In the same way, we could reduce hand shaking overhead between
	two processes when those processes need to share a shared buffer.
	There may be other cases that we could reduce overhead as well.


References:
[1] http://lwn.net/Articles/470339/
[2] http://lwn.net/Articles/532616/
[3] https://patchwork.kernel.org/patch/2625361/
[4] http://linux.die.net/man/2/fcntl

Inki Dae (2):
  dmabuf-sync: Introduce buffer synchronization framework
  dma-buf: add lock callback for fcntl system call.

 Documentation/dma-buf-sync.txt |  283 +++++++++++++++++
 drivers/base/Kconfig           |    7 +
 drivers/base/Makefile          |    1 +
 drivers/base/dma-buf.c         |   34 ++
 drivers/base/dmabuf-sync.c     |  661 ++++++++++++++++++++++++++++++++++++++++
 include/linux/dma-buf.h        |   14 +
 include/linux/dmabuf-sync.h    |  132 ++++++++
 include/linux/reservation.h    |    9 +
 8 files changed, 1141 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sync.txt
 create mode 100644 drivers/base/dmabuf-sync.c
 create mode 100644 include/linux/dmabuf-sync.h

-- 
1.7.5.4



From inki.dae at samsung.com  Wed Jul 10 07:58:46 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Wed, 10 Jul 2013 20:58:46 +0900
Subject: [RFC PATCH v4 1/2] dmabuf-sync: Introduce buffer synchronization
 framework
In-Reply-To: <1373457527-28263-1-git-send-email-inki.dae@samsung.com>
References: <1373457527-28263-1-git-send-email-inki.dae@samsung.com>
Message-ID: <1373457527-28263-2-git-send-email-inki.dae@samsung.com>

This patch adds a buffer synchronization framework based on DMA BUF[1]
and reservation[2] to use dma-buf resource, and based on ww-mutexes[3]
for lock mechanism.

The purpose of this framework is to provide not only buffer access control
to CPU and DMA but also easy-to-use interfaces for device drivers and
user application. This framework can be used for all dma devices using
system memory as dma buffer, especially for most ARM based SoCs.

Changelog v4:
- Add user side interface for buffer synchronization mechanism and update
  descriptions related to the user side interface.

Changelog v3:
- remove cache operation relevant codes and update document file.

Changelog v2:
- use atomic_add_unless to avoid potential bug.
- add a macro for checking valid access type.
- code clean.

The mechanism of this framework has the following steps,
    1. Register dmabufs to a sync object - A task gets a new sync object and
    can add one or more dmabufs that the task wants to access.
    This registering should be performed when a device context or an event
    context such as a page flip event is created or before CPU accesses a shared
    buffer.

	dma_buf_sync_get(a sync object, a dmabuf);

    2. Lock a sync object - A task tries to lock all dmabufs added in its own
    sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead
    lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA
    and DMA. Taking a lock means that others cannot access all locked dmabufs
    until the task that locked the corresponding dmabufs, unlocks all the locked
    dmabufs.
    This locking should be performed before DMA or CPU accesses these dmabufs.

	dma_buf_sync_lock(a sync object);

    3. Unlock a sync object - The task unlocks all dmabufs added in its own sync
    object. The unlock means that the DMA or CPU accesses to the dmabufs have
    been completed so that others may access them.
    This unlocking should be performed after DMA or CPU has completed accesses
    to the dmabufs.

	dma_buf_sync_unlock(a sync object);

    4. Unregister one or all dmabufs from a sync object - A task unregisters
    the given dmabufs from the sync object. This means that the task dosen't
    want to lock the dmabufs.
    The unregistering should be performed after DMA or CPU has completed
    accesses to the dmabufs or when dma_buf_sync_lock() is failed.

	dma_buf_sync_put(a sync object, a dmabuf);
	dma_buf_sync_put_all(a sync object);

    The described steps may be summarized as:
	get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put

This framework includes the following two features.
    1. read (shared) and write (exclusive) locks - A task is required to declare
    the access type when the task tries to register a dmabuf;
    READ, WRITE, READ DMA, or WRITE DMA.

    The below is example codes,
	struct dmabuf_sync *sync;

	sync = dmabuf_sync_init(NULL, "test sync");

	dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R);
	...

	And the below can be used as access types:
		DMA_BUF_ACCESS_R - CPU will access a buffer for read.
		DMA_BUF_ACCESS_W - CPU will access a buffer for read or write.
		DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read
		DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or
					write.

    2. Mandatory resource releasing - a task cannot hold a lock indefinitely.
    A task may never try to unlock a buffer after taking a lock to the buffer.
    In this case, a timer handler to the corresponding sync object is called
    in five (default) seconds and then the timed-out buffer is unlocked by work
    queue handler to avoid lockups and to enforce resources of the buffer.


The below is how to use for device driver:
	1. Allocate and Initialize a sync object:
		struct dmabuf_sync *sync;

		sync = dmabuf_sync_init(NULL, "test sync");
		...

	2. Add a dmabuf to the sync object when setting up dma buffer relevant
	   registers:
		dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ);
		...

	3. Lock all dmabufs of the sync object before DMA or CPU accesses
	   the dmabufs:
		dmabuf_sync_lock(sync);
		...

	4. Now CPU or DMA can access all dmabufs locked in step 3.

	5. Unlock all dmabufs added in a sync object after DMA or CPU access
	   to these dmabufs is completed:
		dmabuf_sync_unlock(sync);

	   And call the following functions to release all resources,
		dmabuf_sync_put_all(sync);
		dmabuf_sync_fini(sync);

	You can refer to actual example codes:
		https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/
		commit/?h=dmabuf-sync&id=4030bdee9bab5841ad32faade528d04cc0c5fc94

		https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/
		commit/?h=dmabuf-sync&id=6ca548e9ea9e865592719ef6b1cde58366af9f5c

And this framework includes fcntl system call[4] as interfaces exported
to user. As you know, user sees a buffer object as a dma-buf file descriptor.
So fcntl() call with the file descriptor means to lock some buffer region being
managed by the dma-buf object.

The below is how to use for user application:
	struct flock filelock;

	1. Lock a dma buf:
		filelock.l_type = F_WRLCK or F_RDLCK;

		/* lock entire region to the dma buf. */
		filelock.lwhence = SEEK_CUR;
		filelock.l_start = 0;
		filelock.l_len = 0;

		fcntl(dmabuf fd, F_SETLKW or F_SETLK, &filelock);
		...
		CPU access to the dma buf

	2. Unlock a dma buf:
		filelock.l_type = F_UNLCK;

		fcntl(dmabuf fd, F_SETLKW or F_SETLK, &filelock);

		close(dmabuf fd) call would also unlock the dma buf. And for more
		detail, please refer to [4]


References:
[1] http://lwn.net/Articles/470339/
[2] http://lwn.net/Articles/532616/
[3] https://patchwork.kernel.org/patch/2625361/
[4] http://linux.die.net/man/2/fcntl

Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 Documentation/dma-buf-sync.txt |  283 +++++++++++++++++
 drivers/base/Kconfig           |    7 +
 drivers/base/Makefile          |    1 +
 drivers/base/dmabuf-sync.c     |  661 ++++++++++++++++++++++++++++++++++++++++
 include/linux/dma-buf.h        |   14 +
 include/linux/dmabuf-sync.h    |  132 ++++++++
 include/linux/reservation.h    |    9 +
 7 files changed, 1107 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sync.txt
 create mode 100644 drivers/base/dmabuf-sync.c
 create mode 100644 include/linux/dmabuf-sync.h

diff --git a/Documentation/dma-buf-sync.txt b/Documentation/dma-buf-sync.txt
new file mode 100644
index 0000000..9d12d00
--- /dev/null
+++ b/Documentation/dma-buf-sync.txt
@@ -0,0 +1,283 @@
+                    DMA Buffer Synchronization Framework
+                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+                                  Inki Dae
+                      <inki dot dae at samsung dot com>
+                          <daeinki at gmail dot com>
+
+This document is a guide for device-driver writers describing the DMA buffer
+synchronization API. This document also describes how to use the API to
+use buffer synchronization mechanism between DMA and DMA, CPU and DMA, and
+CPU and CPU.
+
+The DMA Buffer synchronization API provides buffer synchronization mechanism;
+i.e., buffer access control to CPU and DMA, and easy-to-use interfaces for
+device drivers and user application. And this API can be used for all dma
+devices using system memory as dma buffer, especially for most ARM based SoCs.
+
+
+Motivation
+----------
+
+Buffer synchronization issue between DMA and DMA:
+	Sharing a buffer, a device cannot be aware of when the other device
+	will access the shared buffer: a device may access a buffer containing
+	wrong data if the device accesses the shared buffer while another
+	device is still accessing the shared buffer.
+	Therefore, a user process should have waited for the completion of DMA
+	access by another device before a device tries to access the shared
+	buffer.
+
+Buffer synchronization issue between CPU and DMA:
+	A user process should consider that when having to send a buffer, filled
+	by CPU, to a device driver for the device driver to access the buffer as
+	a input buffer while CPU and DMA are sharing the buffer.
+	This means that the user process needs to understand how the device
+	driver is worked. Hence, the conventional mechanism not only makes
+	user application complicated but also incurs performance overhead.
+
+Buffer synchronization issue between CPU and CPU:
+	In case that two processes share one buffer; shared with DMA also,
+	they may need some mechanism to allow process B to access the shared
+	buffer after the completion of CPU access by process A.
+	Therefore, process B should have waited for the completion of CPU access
+	by process A using the mechanism before trying to access the shared
+	buffer.
+
+What is the best way to solve these buffer synchronization issues?
+	We may need a common object that a device driver and a user process
+	notify the common object of when they try to access a shared buffer.
+	That way we could decide when we have to allow or not to allow for CPU
+	or DMA to access the shared buffer through the common object.
+	If so, what could become the common object? Right, that's a dma-buf[1].
+	Now we have already been using the dma-buf to share one buffer with
+	other drivers.
+
+How we can utilize multi threads for more performance?
+	DMA and CPU works individually. So CPU could perform other works while
+	DMA is performing some works, and vise versa. However, in conventional
+	way, that is not easy to do so because DMA operation is depend on CPU
+	operation, and vice versa.
+
+	conventional way:
+	User                                     Kernel
+	---------------------------------------------------------------------
+	CPU writes something to src
+	send the src to driver------------------------->
+	                                         update DMA register
+	request DMA start------------------------------>
+	                                         DMA start
+		<-----------completion signal-------
+	CPU accesses dst
+
+	And with dmabuf-sync:
+	User(thread a)          User(thread b)            Kernel
+	---------------------------------------------------------------------
+	send a src to driver---------------------------------->
+	                                                  update DMA register
+        lock the src
+	                        request DMA start(1)---------->
+	CPU acccess to src
+	unlock the src		                          lock src and dst
+							  DMA start
+		<-------------completion signal(2)-------------
+	lock dst	                                  DMA completion
+	CPU access to dst				  unlock src and dst
+	unlock DST
+
+	In above,
+	(1) Try to start DMA operation while CPU is accessing the src buffer.
+	(2) Try CPU access to dst buffer while DMA is accessing the dst buffer.
+
+	With same approach, we could reduce hand shaking overhead between
+	two processes in addition. There may be other cases that we could
+	reduce overhead as well.
+
+
+Basic concept
+-------------
+
+The mechanism of this framework has the following steps,
+    1. Register dmabufs to a sync object - A task gets a new sync object and
+    can add one or more dmabufs that the task wants to access.
+    This registering should be performed when a device context or an event
+    context such as a page flip event is created or before CPU accesses a shared
+    buffer.
+
+	dma_buf_sync_get(a sync object, a dmabuf);
+
+    2. Lock a sync object - A task tries to lock all dmabufs added in its own
+    sync object. Basically, the lock mechanism uses ww-mutexes[2] to avoid dead
+    lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA
+    and DMA. Taking a lock means that others cannot access all locked dmabufs
+    until the task that locked the corresponding dmabufs, unlocks all the locked
+    dmabufs.
+    This locking should be performed before DMA or CPU accesses these dmabufs.
+
+	dma_buf_sync_lock(a sync object);
+
+    3. Unlock a sync object - The task unlocks all dmabufs added in its own sync
+    object. The unlock means that the DMA or CPU accesses to the dmabufs have
+    been completed so that others may access them.
+    This unlocking should be performed after DMA or CPU has completed accesses
+    to the dmabufs.
+
+	dma_buf_sync_unlock(a sync object);
+
+    4. Unregister one or all dmabufs from a sync object - A task unregisters
+    the given dmabufs from the sync object. This means that the task dosen't
+    want to lock the dmabufs.
+    The unregistering should be performed after DMA or CPU has completed
+    accesses to the dmabufs or when dma_buf_sync_lock() is failed.
+
+	dma_buf_sync_put(a sync object, a dmabuf);
+	dma_buf_sync_put_all(a sync object);
+
+    The described steps may be summarized as:
+	get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put
+
+This framework includes the following two features.
+    1. read (shared) and write (exclusive) locks - A task is required to declare
+    the access type when the task tries to register a dmabuf;
+    READ, WRITE, READ DMA, or WRITE DMA.
+
+    The below is example codes,
+	struct dmabuf_sync *sync;
+
+	sync = dmabuf_sync_init(NULL, "test sync");
+
+	dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R);
+	...
+
+    2. Mandatory resource releasing - a task cannot hold a lock indefinitely.
+    A task may never try to unlock a buffer after taking a lock to the buffer.
+    In this case, a timer handler to the corresponding sync object is called
+    in five (default) seconds and then the timed-out buffer is unlocked by work
+    queue handler to avoid lockups and to enforce resources of the buffer.
+
+
+Access types
+------------
+
+DMA_BUF_ACCESS_R - CPU will access a buffer for read.
+DMA_BUF_ACCESS_W - CPU will access a buffer for read or write.
+DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read
+DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or write.
+
+
+Generic user interfaces
+-----------------------
+
+The DMA-BUF Sync mechanism includes fcntl system call[3] as interfaces exported
+to user. As you know, user sees a buffer object as a dma-buf file descriptor.
+So fcntl() call with the file descriptor means to lock some buffer region being
+managed by the dma-buf object.
+
+
+API set
+-------
+
+bool is_dmabuf_sync_supported(void)
+	- Check if dmabuf sync is supported or not.
+
+struct dmabuf_sync *dmabuf_sync_init(void *priv, const char *name)
+	- Allocate and initialize a new sync object. The caller can get a new
+	sync object for buffer synchronization. priv is used to set caller's
+	private data and name is the name of sync object.
+
+void dmabuf_sync_fini(struct dmabuf_sync *sync)
+	- Release all resources to the sync object.
+
+int dmabuf_sync_get(struct dmabuf_sync *sync, void *sync_buf,
+			unsigned int type)
+	- Add a dmabuf to a sync object. The caller can group multiple dmabufs
+	by calling this function several times. Internally, this function also
+	takes a reference to a dmabuf.
+
+void dmabuf_sync_put(struct dmabuf_sync *sync, struct dma_buf *dmabuf)
+	- Remove a given dmabuf from a sync object. Internally, this function
+	also release every reference to the given dmabuf.
+
+void dmabuf_sync_put_all(struct dmabuf_sync *sync)
+	- Remove all dmabufs added in a sync object. Internally, this function
+	also release every reference to the dmabufs of the sync object.
+
+int dmabuf_sync_lock(struct dmabuf_sync *sync)
+	- Lock all dmabufs added in a sync object. The caller should call this
+	function prior to CPU or DMA access to the dmabufs so that others can
+	not access the dmabufs. Internally, this function avoids dead lock
+	issue with ww-mutexes.
+
+int dmabuf_sync_single_lock(struct dma_buf *dmabuf)
+	- Lock a dmabuf. The caller should call this
+	function prior to CPU or DMA access to the dmabuf so that others can
+	not access the dmabuf.
+
+int dmabuf_sync_unlock(struct dmabuf_sync *sync)
+	- Unlock all dmabufs added in a sync object. The caller should call
+	this function after CPU or DMA access to the dmabufs is completed so
+	that others can access the dmabufs.
+
+void dmabuf_sync_single_unlock(struct dma_buf *dmabuf)
+	- Unlock a dmabuf. The caller should call this function after CPU or
+	DMA access to the dmabuf is completed so that others can access
+	the dmabuf.
+
+
+Tutorial for device driver
+--------------------------
+
+1. Allocate and Initialize a sync object:
+	struct dmabuf_sync *sync;
+
+	sync = dmabuf_sync_init(NULL, "test sync");
+	...
+
+2. Add a dmabuf to the sync object when setting up dma buffer relevant registers:
+	dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ);
+	...
+
+3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs:
+	dmabuf_sync_lock(sync);
+	...
+
+4. Now CPU or DMA can access all dmabufs locked in step 3.
+
+5. Unlock all dmabufs added in a sync object after DMA or CPU access to these
+   dmabufs is completed:
+	dmabuf_sync_unlock(sync);
+
+   And call the following functions to release all resources,
+	dmabuf_sync_put_all(sync);
+	dmabuf_sync_fini(sync);
+
+
+Tutorial for user application
+-----------------------------
+	struct flock filelock;
+
+1. Lock a dma buf:
+	filelock.l_type = F_WRLCK or F_RDLCK;
+
+	/* lock entire region to the dma buf. */
+	filelock.lwhence = SEEK_CUR;
+	filelock.l_start = 0;
+	filelock.l_len = 0;
+
+	fcntl(dmabuf fd, F_SETLKW or F_SETLK, &filelock);
+	...
+	CPU access to the dma buf
+
+2. Unlock a dma buf:
+	filelock.l_type = F_UNLCK;
+
+	fcntl(dmabuf fd, F_SETLKW or F_SETLK, &filelock);
+
+	close(dmabuf fd) call would also unlock the dma buf. And for more
+	detail, please refer to [3]
+
+
+References:
+[1] http://lwn.net/Articles/470339/
+[2] https://patchwork.kernel.org/patch/2625361/
+[3] http://linux.die.net/man/2/fcntl
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 5ccf182..54a1d5a 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -212,6 +212,13 @@ config FENCE_TRACE
 	  lockup related problems for dma-buffers shared across multiple
 	  devices.
 
+config DMABUF_SYNC
+	bool "DMABUF Synchronization Framework"
+	depends on DMA_SHARED_BUFFER
+	help
+	  This option enables dmabuf sync framework for buffer synchronization between
+	  DMA and DMA, CPU and DMA, and CPU and CPU.
+
 config CMA
 	bool "Contiguous Memory Allocator"
 	depends on HAVE_DMA_CONTIGUOUS && HAVE_MEMBLOCK
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 8a55cb9..599f6c90 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -11,6 +11,7 @@ obj-y			+= power/
 obj-$(CONFIG_HAS_DMA)	+= dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
 obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o fence.o reservation.o
+obj-$(CONFIG_DMABUF_SYNC) += dmabuf-sync.o
 obj-$(CONFIG_ISA)	+= isa.o
 obj-$(CONFIG_FW_LOADER)	+= firmware_class.o
 obj-$(CONFIG_NUMA)	+= node.o
diff --git a/drivers/base/dmabuf-sync.c b/drivers/base/dmabuf-sync.c
new file mode 100644
index 0000000..437a46e
--- /dev/null
+++ b/drivers/base/dmabuf-sync.c
@@ -0,0 +1,661 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics Co.Ltd
+ * Authors:
+ *	Inki Dae <inki.dae at samsung.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/debugfs.h>
+#include <linux/uaccess.h>
+
+#include <linux/dmabuf-sync.h>
+
+#define MAX_SYNC_TIMEOUT	5 /* Second. */
+
+int dmabuf_sync_enabled = 1;
+
+MODULE_PARM_DESC(enabled, "Check if dmabuf sync is supported or not");
+module_param_named(enabled, dmabuf_sync_enabled, int, 0444);
+
+static void dmabuf_sync_timeout_worker(struct work_struct *work)
+{
+	struct dmabuf_sync *sync = container_of(work, struct dmabuf_sync, work);
+	struct dmabuf_sync_object *sobj;
+
+	mutex_lock(&sync->lock);
+
+	list_for_each_entry(sobj, &sync->syncs, head) {
+		if (WARN_ON(!sobj->robj))
+			continue;
+
+		mutex_lock(&sobj->robj->r_lock);
+
+		printk(KERN_WARNING "%s: timeout = 0x%x [type = %d, " \
+					"refcnt = %d, locked = %d]\n",
+					sync->name, (u32)sobj->dmabuf,
+					sobj->access_type,
+					atomic_read(&sobj->robj->shared_cnt),
+					sobj->robj->locked);
+
+		/* unlock only valid sync object. */
+		if (!sobj->robj->locked) {
+			mutex_unlock(&sobj->robj->r_lock);
+			continue;
+		}
+
+		if (sobj->robj->shared &&
+		    atomic_add_unless(&sobj->robj->shared_cnt, -1, 1)) {
+			mutex_unlock(&sobj->robj->r_lock);
+			continue;
+		}
+
+		mutex_unlock(&sobj->robj->r_lock);
+
+		ww_mutex_unlock(&sobj->robj->lock);
+
+		mutex_lock(&sobj->robj->r_lock);
+
+		if (sobj->access_type & DMA_BUF_ACCESS_R)
+			printk(KERN_WARNING "%s: r-unlocked = 0x%x\n",
+					sync->name, (u32)sobj->dmabuf);
+		else
+			printk(KERN_WARNING "%s: w-unlocked = 0x%x\n",
+					sync->name, (u32)sobj->dmabuf);
+
+		mutex_unlock(&sobj->robj->r_lock);
+	}
+
+	sync->status = 0;
+	mutex_unlock(&sync->lock);
+
+	dmabuf_sync_put_all(sync);
+	dmabuf_sync_fini(sync);
+}
+
+static void dmabuf_sync_lock_timeout(unsigned long arg)
+{
+	struct dmabuf_sync *sync = (struct dmabuf_sync *)arg;
+
+	schedule_work(&sync->work);
+}
+
+static int dmabuf_sync_lock_objs(struct dmabuf_sync *sync,
+					struct ww_acquire_ctx *ctx)
+{
+	struct dmabuf_sync_object *contended_sobj = NULL;
+	struct dmabuf_sync_object *res_sobj = NULL;
+	struct dmabuf_sync_object *sobj = NULL;
+	int ret;
+
+	if (ctx)
+		ww_acquire_init(ctx, &reservation_ww_class);
+
+retry:
+	list_for_each_entry(sobj, &sync->syncs, head) {
+		if (WARN_ON(!sobj->robj))
+			continue;
+
+		mutex_lock(&sobj->robj->r_lock);
+
+		/* Don't lock in case of read and read. */
+		if (sobj->robj->accessed_type & DMA_BUF_ACCESS_R &&
+		    sobj->access_type & DMA_BUF_ACCESS_R) {
+			atomic_inc(&sobj->robj->shared_cnt);
+			sobj->robj->shared = true;
+			mutex_unlock(&sobj->robj->r_lock);
+			continue;
+		}
+
+		if (sobj == res_sobj) {
+			res_sobj = NULL;
+			mutex_unlock(&sobj->robj->r_lock);
+			continue;
+		}
+
+		mutex_unlock(&sobj->robj->r_lock);
+
+		ret = ww_mutex_lock(&sobj->robj->lock, ctx);
+		if (ret < 0) {
+			contended_sobj = sobj;
+
+			if (ret == -EDEADLK)
+				printk(KERN_WARNING"%s: deadlock = 0x%x\n",
+					sync->name, (u32)sobj->dmabuf);
+			goto err;
+		}
+
+		mutex_lock(&sobj->robj->r_lock);
+		sobj->robj->locked = true;
+
+		mutex_unlock(&sobj->robj->r_lock);
+	}
+
+	if (ctx)
+		ww_acquire_done(ctx);
+
+	init_timer(&sync->timer);
+
+	sync->timer.data = (unsigned long)sync;
+	sync->timer.function = dmabuf_sync_lock_timeout;
+	sync->timer.expires = jiffies + (HZ * MAX_SYNC_TIMEOUT);
+
+	add_timer(&sync->timer);
+
+	return 0;
+
+err:
+	list_for_each_entry_continue_reverse(sobj, &sync->syncs, head) {
+		mutex_lock(&sobj->robj->r_lock);
+
+		/* Don't need to unlock in case of read and read. */
+		if (atomic_add_unless(&sobj->robj->shared_cnt, -1, 1)) {
+			mutex_unlock(&sobj->robj->r_lock);
+			continue;
+		}
+
+		ww_mutex_unlock(&sobj->robj->lock);
+		sobj->robj->locked = false;
+
+		mutex_unlock(&sobj->robj->r_lock);
+	}
+
+	if (res_sobj) {
+		mutex_lock(&res_sobj->robj->r_lock);
+
+		if (!atomic_add_unless(&res_sobj->robj->shared_cnt, -1, 1)) {
+			ww_mutex_unlock(&res_sobj->robj->lock);
+			res_sobj->robj->locked = false;
+		}
+
+		mutex_unlock(&res_sobj->robj->r_lock);
+	}
+
+	if (ret == -EDEADLK) {
+		ww_mutex_lock_slow(&contended_sobj->robj->lock, ctx);
+		res_sobj = contended_sobj;
+
+		goto retry;
+	}
+
+	if (ctx)
+		ww_acquire_fini(ctx);
+
+	return ret;
+}
+
+static void dmabuf_sync_unlock_objs(struct dmabuf_sync *sync,
+					struct ww_acquire_ctx *ctx)
+{
+	struct dmabuf_sync_object *sobj;
+
+	if (list_empty(&sync->syncs))
+		return;
+
+	mutex_lock(&sync->lock);
+
+	list_for_each_entry(sobj, &sync->syncs, head) {
+		mutex_lock(&sobj->robj->r_lock);
+
+		if (sobj->robj->shared) {
+			if (atomic_add_unless(&sobj->robj->shared_cnt, -1,
+						1)) {
+				mutex_unlock(&sobj->robj->r_lock);
+				continue;
+			}
+
+			mutex_unlock(&sobj->robj->r_lock);
+
+			ww_mutex_unlock(&sobj->robj->lock);
+
+			mutex_lock(&sobj->robj->r_lock);
+			sobj->robj->shared = false;
+			sobj->robj->locked = false;
+		} else {
+			mutex_unlock(&sobj->robj->r_lock);
+
+			ww_mutex_unlock(&sobj->robj->lock);
+
+			mutex_lock(&sobj->robj->r_lock);
+			sobj->robj->locked = false;
+		}
+
+		mutex_unlock(&sobj->robj->r_lock);
+	}
+
+	mutex_unlock(&sync->lock);
+
+	if (ctx)
+		ww_acquire_fini(ctx);
+
+	del_timer(&sync->timer);
+}
+
+/**
+ * is_dmabuf_sync_supported - Check if dmabuf sync is supported or not.
+ */
+bool is_dmabuf_sync_supported(void)
+{
+	return dmabuf_sync_enabled == 1;
+}
+EXPORT_SYMBOL(is_dmabuf_sync_supported);
+
+/**
+ * dmabuf_sync_init - Allocate and initialize a dmabuf sync.
+ *
+ * @priv: A device private data.
+ * @name: A sync object name.
+ *
+ * This function should be called when a device context or an event
+ * context such as a page flip event is created. And the created
+ * dmabuf_sync object should be set to the context.
+ * The caller can get a new sync object for buffer synchronization
+ * through this function.
+ */
+struct dmabuf_sync *dmabuf_sync_init(void *priv, const char *name)
+{
+	struct dmabuf_sync *sync;
+
+	sync = kzalloc(sizeof(*sync), GFP_KERNEL);
+	if (!sync)
+		return ERR_PTR(-ENOMEM);
+
+	strncpy(sync->name, name, ARRAY_SIZE(sync->name) - 1);
+
+	sync->priv = priv;
+	INIT_LIST_HEAD(&sync->syncs);
+	mutex_init(&sync->lock);
+	INIT_WORK(&sync->work, dmabuf_sync_timeout_worker);
+
+	return sync;
+}
+EXPORT_SYMBOL(dmabuf_sync_init);
+
+/**
+ * dmabuf_sync_fini - Release a given dmabuf sync.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ *
+ * This function should be called if some operation is failed after
+ * dmabuf_sync_init call to release relevant resources, and after
+ * dmabuf_sync_unlock function is called.
+ */
+void dmabuf_sync_fini(struct dmabuf_sync *sync)
+{
+	if (WARN_ON(!sync))
+		return;
+
+	kfree(sync);
+}
+EXPORT_SYMBOL(dmabuf_sync_fini);
+
+/*
+ * dmabuf_sync_get_obj - Add a given object to syncs list.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ * @dmabuf: An object to dma_buf structure.
+ * @type: A access type to a dma buf.
+ *	The DMA_BUF_ACCESS_R means that this dmabuf could be accessed by
+ *	others for read access. On the other hand, the DMA_BUF_ACCESS_W
+ *	means that this dmabuf couldn't be accessed by others but would be
+ *	accessed by caller's dma exclusively. And the DMA_BUF_ACCESS_DMA can be
+ *	combined.
+ *
+ * This function creates and initializes a new dmabuf sync object and it adds
+ * the dmabuf sync object to syncs list to track and manage all dmabufs.
+ */
+static int dmabuf_sync_get_obj(struct dmabuf_sync *sync, struct dma_buf *dmabuf,
+					unsigned int type)
+{
+	struct dmabuf_sync_object *sobj;
+
+	if (!dmabuf->resv) {
+		WARN_ON(1);
+		return -EFAULT;
+	}
+
+	if (!IS_VALID_DMA_BUF_ACCESS_TYPE(type))
+		return -EINVAL;
+
+	if ((type & DMA_BUF_ACCESS_RW) == DMA_BUF_ACCESS_RW)
+		type &= ~DMA_BUF_ACCESS_R;
+
+	sobj = kzalloc(sizeof(*sobj), GFP_KERNEL);
+	if (!sobj) {
+		WARN_ON(1);
+		return -ENOMEM;
+	}
+
+	sobj->dmabuf = dmabuf;
+	sobj->robj = dmabuf->resv;
+
+	mutex_lock(&sync->lock);
+	list_add_tail(&sobj->head, &sync->syncs);
+	mutex_unlock(&sync->lock);
+
+	get_dma_buf(dmabuf);
+
+	mutex_lock(&sobj->robj->r_lock);
+	sobj->access_type = type;
+	mutex_unlock(&sobj->robj->r_lock);
+
+	return 0;
+}
+
+/*
+ * dmabuf_sync_put_obj - Release a given sync object.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ *
+ * This function should be called if some operation is failed after
+ * dmabuf_sync_get_obj call to release a given sync object.
+ */
+static void dmabuf_sync_put_obj(struct dmabuf_sync *sync,
+					struct dma_buf *dmabuf)
+{
+	struct dmabuf_sync_object *sobj;
+
+	mutex_lock(&sync->lock);
+
+	list_for_each_entry(sobj, &sync->syncs, head) {
+		if (sobj->dmabuf != dmabuf)
+			continue;
+
+		dma_buf_put(sobj->dmabuf);
+
+		list_del_init(&sobj->head);
+		kfree(sobj);
+		break;
+	}
+
+	if (list_empty(&sync->syncs))
+		sync->status = 0;
+
+	mutex_unlock(&sync->lock);
+}
+
+/*
+ * dmabuf_sync_put_objs - Release all sync objects of dmabuf_sync.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ *
+ * This function should be called if some operation is failed after
+ * dmabuf_sync_get_obj call to release all sync objects.
+ */
+static void dmabuf_sync_put_objs(struct dmabuf_sync *sync)
+{
+	struct dmabuf_sync_object *sobj, *next;
+
+	mutex_lock(&sync->lock);
+
+	list_for_each_entry_safe(sobj, next, &sync->syncs, head) {
+		dma_buf_put(sobj->dmabuf);
+
+		list_del_init(&sobj->head);
+		kfree(sobj);
+	}
+
+	mutex_unlock(&sync->lock);
+
+	sync->status = 0;
+}
+
+/**
+ * dmabuf_sync_lock - lock all dmabufs added to syncs list.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ *
+ * The caller should call this function prior to CPU or DMA access to
+ * the dmabufs so that others can not access the dmabufs.
+ * Internally, this function avoids dead lock issue with ww-mutex.
+ */
+int dmabuf_sync_lock(struct dmabuf_sync *sync)
+{
+	int ret;
+
+	if (!sync) {
+		WARN_ON(1);
+		return -EFAULT;
+	}
+
+	if (list_empty(&sync->syncs))
+		return -EINVAL;
+
+	if (sync->status != DMABUF_SYNC_GOT)
+		return -EINVAL;
+
+	ret = dmabuf_sync_lock_objs(sync, &sync->ctx);
+	if (ret < 0) {
+		WARN_ON(1);
+		return ret;
+	}
+
+	sync->status = DMABUF_SYNC_LOCKED;
+
+	return ret;
+}
+EXPORT_SYMBOL(dmabuf_sync_lock);
+
+/**
+ * dmabuf_sync_unlock - unlock all objects added to syncs list.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ *
+ * The caller should call this function after CPU or DMA access to
+ * the dmabufs is completed so that others can access the dmabufs.
+ */
+int dmabuf_sync_unlock(struct dmabuf_sync *sync)
+{
+	if (!sync) {
+		WARN_ON(1);
+		return -EFAULT;
+	}
+
+	/* If current dmabuf sync object wasn't reserved then just return. */
+	if (sync->status != DMABUF_SYNC_LOCKED)
+		return -EAGAIN;
+
+	dmabuf_sync_unlock_objs(sync, &sync->ctx);
+
+	return 0;
+}
+EXPORT_SYMBOL(dmabuf_sync_unlock);
+
+/**
+ * dmabuf_sync_single_lock - lock a dma buf.
+ *
+ * @dmabuf: A dma buf object that tries to lock.
+ * @type: A access type to a dma buf.
+ *	The DMA_BUF_ACCESS_R means that this dmabuf could be accessed by
+ *	others for read access. On the other hand, the DMA_BUF_ACCESS_W
+ *	means that this dmabuf couldn't be accessed by others but would be
+ *	accessed by caller's dma exclusively. And the DMA_BUF_ACCESS_DMA can
+ *	be combined
+ * @wait: Indicate whether caller is blocked or not.
+ *	true means that caller will be blocked, and false means that this
+ *	function will return -EAGAIN if this caller can't take the lock
+ *	right now.
+ *
+ * The caller should call this function prior to CPU or DMA access to the dmabuf
+ * so that others cannot access the dmabuf.
+ */
+int dmabuf_sync_single_lock(struct dma_buf *dmabuf, unsigned int type,
+				bool wait)
+{
+	struct reservation_object *robj;
+
+	if (!dmabuf->resv) {
+		WARN_ON(1);
+		return -EFAULT;
+	}
+
+	if (!IS_VALID_DMA_BUF_ACCESS_TYPE(type)) {
+		WARN_ON(1);
+		return -EINVAL;
+	}
+
+	get_dma_buf(dmabuf);
+	robj = dmabuf->resv;
+
+	mutex_lock(&robj->r_lock);
+
+	/* Don't lock in case of read and read. */
+	if (robj->accessed_type & DMA_BUF_ACCESS_R && type & DMA_BUF_ACCESS_R) {
+		atomic_inc(&robj->shared_cnt);
+		robj->shared = true;
+		mutex_unlock(&robj->r_lock);
+		return 0;
+	}
+
+	/*
+	 * In case of F_SETLK, just return -EAGAIN if this dmabuf has already
+	 * been locked.
+	 */
+	if (!wait && robj->locked) {
+		mutex_unlock(&robj->r_lock);
+		dma_buf_put(dmabuf);
+		return -EAGAIN;
+	}
+
+	mutex_unlock(&robj->r_lock);
+
+	mutex_lock(&robj->lock.base);
+
+	mutex_lock(&robj->r_lock);
+	robj->locked = true;
+	mutex_unlock(&robj->r_lock);
+
+	return 0;
+}
+EXPORT_SYMBOL(dmabuf_sync_single_lock);
+
+/**
+ * dmabuf_sync_single_unlock - unlock a dma buf.
+ *
+ * @dmabuf: A dma buf object that tries to unlock.
+ *
+ * The caller should call this function after CPU or DMA access to
+ * the dmabuf is completed so that others can access the dmabuf.
+ */
+void dmabuf_sync_single_unlock(struct dma_buf *dmabuf)
+{
+	struct reservation_object *robj;
+
+	if (!dmabuf->resv) {
+		WARN_ON(1);
+		return;
+	}
+
+	robj = dmabuf->resv;
+
+	mutex_lock(&robj->r_lock);
+
+	if (robj->shared) {
+		if (atomic_add_unless(&robj->shared_cnt, -1 , 1)) {
+			mutex_unlock(&robj->r_lock);
+			return;
+		}
+
+		robj->shared = false;
+	}
+
+	mutex_unlock(&robj->r_lock);
+
+	mutex_unlock(&robj->lock.base);
+
+	mutex_lock(&robj->r_lock);
+	robj->locked = false;
+	mutex_unlock(&robj->r_lock);
+
+	dma_buf_put(dmabuf);
+
+	return;
+}
+EXPORT_SYMBOL(dmabuf_sync_single_unlock);
+
+/**
+ * dmabuf_sync_get - initialize reservation entry and update
+ *				dmabuf sync.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ * @sync_buf: A dma_buf object pointer that we want to be synchronized
+ *	with others.
+ *
+ * This function should be called after dmabuf_sync_init function is called.
+ * The caller can group multiple dmabufs by calling this function several
+ * times. Internally, this function also takes a reference to a dmabuf.
+ */
+int dmabuf_sync_get(struct dmabuf_sync *sync, void *sync_buf, unsigned int type)
+{
+	int ret;
+
+	if (!sync || !sync_buf) {
+		WARN_ON(1);
+		return -EFAULT;
+	}
+
+	ret = dmabuf_sync_get_obj(sync, sync_buf, type);
+	if (ret < 0) {
+		WARN_ON(1);
+		return ret;
+	}
+
+	sync->status = DMABUF_SYNC_GOT;
+
+	return 0;
+}
+EXPORT_SYMBOL(dmabuf_sync_get);
+
+/**
+ * dmabuf_sync_put - Release a given dmabuf.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ * @dmabuf: An object to dma_buf structure.
+ *
+ * This function should be called if some operation is failed after
+ * dmabuf_sync_get function is called to release the dmabuf, or
+ * dmabuf_sync_unlock function is called.
+ */
+void dmabuf_sync_put(struct dmabuf_sync *sync, struct dma_buf *dmabuf)
+{
+	if (!sync || !dmabuf) {
+		WARN_ON(1);
+		return;
+	}
+
+	if (list_empty(&sync->syncs))
+		return;
+
+	dmabuf_sync_put_obj(sync, dmabuf);
+}
+EXPORT_SYMBOL(dmabuf_sync_put);
+
+/**
+ * dmabuf_sync_put_all - Release all sync objects
+ *
+ * @sync: An object to dmabuf_sync structure.
+ *
+ * This function should be called if some operation is failed after
+ * dmabuf_sync_get function is called to release all sync objects, or
+ * dmabuf_sync_unlock function is called.
+ */
+void dmabuf_sync_put_all(struct dmabuf_sync *sync)
+{
+	if (!sync) {
+		WARN_ON(1);
+		return;
+	}
+
+	if (list_empty(&sync->syncs))
+		return;
+
+	dmabuf_sync_put_objs(sync);
+}
+EXPORT_SYMBOL(dmabuf_sync_put_all);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 34cfbac..ae0c87b 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -150,6 +150,20 @@ struct dma_buf_attachment {
 	void *priv;
 };
 
+#define	DMA_BUF_ACCESS_R	0x1
+#define DMA_BUF_ACCESS_W	0x2
+#define DMA_BUF_ACCESS_DMA	0x4
+#define DMA_BUF_ACCESS_RW	(DMA_BUF_ACCESS_R | DMA_BUF_ACCESS_W)
+#define DMA_BUF_ACCESS_DMA_R	(DMA_BUF_ACCESS_R | DMA_BUF_ACCESS_DMA)
+#define DMA_BUF_ACCESS_DMA_W	(DMA_BUF_ACCESS_W | DMA_BUF_ACCESS_DMA)
+#define DMA_BUF_ACCESS_DMA_RW	(DMA_BUF_ACCESS_DMA_R | DMA_BUF_ACCESS_DMA_W)
+#define IS_VALID_DMA_BUF_ACCESS_TYPE(t)	(t == DMA_BUF_ACCESS_R || \
+					 t == DMA_BUF_ACCESS_W || \
+					 t == DMA_BUF_ACCESS_DMA_R || \
+					 t == DMA_BUF_ACCESS_DMA_W || \
+					 t == DMA_BUF_ACCESS_RW || \
+					 t == DMA_BUF_ACCESS_DMA_RW)
+
 /**
  * get_dma_buf - convenience wrapper for get_file.
  * @dmabuf:	[in]	pointer to dma_buf
diff --git a/include/linux/dmabuf-sync.h b/include/linux/dmabuf-sync.h
new file mode 100644
index 0000000..d5ccfa7
--- /dev/null
+++ b/include/linux/dmabuf-sync.h
@@ -0,0 +1,132 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics Co.Ltd
+ * Authors:
+ *	Inki Dae <inki.dae at samsung.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include <linux/mutex.h>
+#include <linux/sched.h>
+#include <linux/dma-buf.h>
+#include <linux/reservation.h>
+
+enum dmabuf_sync_status {
+	DMABUF_SYNC_GOT		= 1,
+	DMABUF_SYNC_LOCKED,
+};
+
+/*
+ * A structure for dmabuf_sync_object.
+ *
+ * @head: A list head to be added to syncs list.
+ * @robj: A reservation_object object.
+ * @dma_buf: A dma_buf object.
+ * @access_type: Indicate how a current task tries to access
+ *	a given buffer.
+ */
+struct dmabuf_sync_object {
+	struct list_head		head;
+	struct reservation_object	*robj;
+	struct dma_buf			*dmabuf;
+	unsigned int			access_type;
+};
+
+/*
+ * A structure for dmabuf_sync.
+ *
+ * @syncs: A list head to sync object and this is global to system.
+ * @list: A list entry used as committed list node
+ * @lock: A mutex lock to current sync object.
+ * @ctx: A current context for ww mutex.
+ * @work: A work struct to release resources at timeout.
+ * @priv: A private data.
+ * @name: A string to dmabuf sync owner.
+ * @timer: A timer list to avoid lockup and release resources.
+ * @status: Indicate current status (DMABUF_SYNC_GOT or DMABUF_SYNC_LOCKED).
+ */
+struct dmabuf_sync {
+	struct list_head	syncs;
+	struct list_head	list;
+	struct mutex		lock;
+	struct ww_acquire_ctx	ctx;
+	struct work_struct	work;
+	void			*priv;
+	char			name[64];
+	struct timer_list	timer;
+	unsigned int		status;
+};
+
+#ifdef CONFIG_DMABUF_SYNC
+extern bool is_dmabuf_sync_supported(void);
+
+extern struct dmabuf_sync *dmabuf_sync_init(void *priv, const char *name);
+
+extern void dmabuf_sync_fini(struct dmabuf_sync *sync);
+
+extern int dmabuf_sync_lock(struct dmabuf_sync *sync);
+
+extern int dmabuf_sync_unlock(struct dmabuf_sync *sync);
+
+int dmabuf_sync_single_lock(struct dma_buf *dmabuf, unsigned int type,
+				bool wait);
+
+void dmabuf_sync_single_unlock(struct dma_buf *dmabuf);
+
+extern int dmabuf_sync_get(struct dmabuf_sync *sync, void *sync_buf,
+				unsigned int type);
+
+extern void dmabuf_sync_put(struct dmabuf_sync *sync, struct dma_buf *dmabuf);
+
+extern void dmabuf_sync_put_all(struct dmabuf_sync *sync);
+
+#else
+static inline bool is_dmabuf_sync_supported(void) { return false; }
+
+static inline struct dmabuf_sync *dmabuf_sync_init(void *priv,
+					const char *names)
+{
+	return ERR_PTR(0);
+}
+
+static inline void dmabuf_sync_fini(struct dmabuf_sync *sync) { }
+
+static inline int dmabuf_sync_lock(struct dmabuf_sync *sync)
+{
+	return 0;
+}
+
+static inline int dmabuf_sync_unlock(struct dmabuf_sync *sync)
+{
+	return 0;
+}
+
+static inline int dmabuf_sync_single_lock(struct dma_buf *dmabuf,
+						unsigned int type,
+						bool wait)
+{
+	return 0;
+}
+
+static inline void dmabuf_sync_single_unlock(struct dma_buf *dmabuf)
+{
+	return;
+}
+
+static inline int dmabuf_sync_get(struct dmabuf_sync *sync,
+					void *sync_buf,
+					unsigned int type)
+{
+	return 0;
+}
+
+static inline void dmabuf_sync_put(struct dmabuf_sync *sync,
+					struct dma_buf *dmabuf) { }
+
+static inline void dmabuf_sync_put_all(struct dmabuf_sync *sync) { }
+
+#endif
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 80050e2..51b7b96 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -50,6 +50,12 @@ struct reservation_object {
 	struct fence *fence_excl;
 	struct fence **fence_shared;
 	u32 fence_shared_count, fence_shared_max;
+
+	struct mutex		r_lock;
+	atomic_t		shared_cnt;
+	unsigned int		accessed_type;
+	unsigned int		shared;
+	unsigned int		locked;
 };
 
 static inline void
@@ -60,6 +66,9 @@ reservation_object_init(struct reservation_object *obj)
 	obj->fence_shared_count = obj->fence_shared_max = 0;
 	obj->fence_shared = NULL;
 	obj->fence_excl = NULL;
+
+	mutex_init(&obj->r_lock);
+	atomic_set(&obj->shared_cnt, 1);
 }
 
 static inline void
-- 
1.7.5.4



From inki.dae at samsung.com  Wed Jul 10 07:58:47 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Wed, 10 Jul 2013 20:58:47 +0900
Subject: [RFC PATCH v1 2/2] dma-buf: add lock callback for fcntl system call.
In-Reply-To: <1373457527-28263-1-git-send-email-inki.dae@samsung.com>
References: <1373457527-28263-1-git-send-email-inki.dae@samsung.com>
Message-ID: <1373457527-28263-3-git-send-email-inki.dae@samsung.com>

This patch adds lock callback to dma buf file operations,
and this callback will be called by fcntl system call.

With this patch, fcntl system call can be used for buffer
synchronization between CPU and CPU, and CPU and DMA in user mode.

Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/base/dma-buf.c |   34 ++++++++++++++++++++++++++++++++++
 1 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index fe39120..cd71447 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -31,6 +31,7 @@
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
 #include <linux/reservation.h>
+#include <linux/dmabuf-sync.h>
 
 static inline int is_dma_buf_file(struct file *);
 
@@ -82,9 +83,42 @@ static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
 	return dmabuf->ops->mmap(dmabuf, vma);
 }
 
+static int dma_buf_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+	struct dma_buf *dmabuf;
+	unsigned int type;
+	bool wait = false;
+
+	if (!is_dma_buf_file(file))
+		return -EINVAL;
+
+	dmabuf = file->private_data;
+
+	if ((fl->fl_type & F_UNLCK) == F_UNLCK) {
+		dmabuf_sync_single_unlock(dmabuf);
+		return 0;
+	}
+
+	/* convert flock type to dmabuf sync type. */
+	if ((fl->fl_type & F_WRLCK) == F_WRLCK)
+		type = DMA_BUF_ACCESS_W;
+	else if ((fl->fl_type & F_RDLCK) == F_RDLCK)
+		type = DMA_BUF_ACCESS_R;
+	else
+		return -EINVAL;
+
+	if (fl->fl_flags & FL_SLEEP)
+		wait = true;
+
+	/* TODO. the locking to certain region should also be considered. */
+
+	return dmabuf_sync_single_lock(dmabuf, type, wait);
+}
+
 static const struct file_operations dma_buf_fops = {
 	.release	= dma_buf_release,
 	.mmap		= dma_buf_mmap_internal,
+	.lock		= dma_buf_lock,
 };
 
 /*
-- 
1.7.5.4



From padma.v at samsung.com  Wed Jul 10 08:11:49 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Wed, 10 Jul 2013 17:41:49 +0530
Subject: [PATCH 0/4] clk: Samsung: audss: Add support for Exynos5420
Message-ID: <1373458313-18970-1-git-send-email-padma.v@samsung.com>

This patch set adds support for audio subsystem clks on Exynos5420. Exynos5420
audio subsystem has a gate bit for ADMA controller and the some of parent clks
for mout_i2s are also different from Exynos5250. So this patch adds provision
for supporting both the platforms by passing the parent clk names through
device tree.

Andrew Bresticker (3):
  clk: exynos-audss: add support for Exynos 5420
  clk: exynos-audss: allow input clocks to be specified in device tree
  ARM: dts: exynos5420: add audio clock controller

Padmavathi Venna (1):
  ARM: dts: Correct the /include entry on exynos5420 dtsi file

 .../devicetree/bindings/clock/clk-exynos-audss.txt |   38 +++++++++++++++++--
 arch/arm/boot/dts/exynos5420.dtsi                  |   13 ++++++-
 drivers/clk/samsung/clk-exynos-audss.c             |   36 ++++++++++++++++--
 include/dt-bindings/clk/exynos-audss-clk.h         |    3 +-
 4 files changed, 80 insertions(+), 10 deletions(-)

-- 
1.7.4.4



From padma.v at samsung.com  Wed Jul 10 08:11:51 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Wed, 10 Jul 2013 17:41:51 +0530
Subject: [PATCH 2/4] clk: exynos-audss: allow input clocks to be specified in
 device tree
In-Reply-To: <1373458313-18970-1-git-send-email-padma.v@samsung.com>
References: <1373458313-18970-1-git-send-email-padma.v@samsung.com>
Message-ID: <1373458313-18970-3-git-send-email-padma.v@samsung.com>

From: Andrew Bresticker <abrestic at chromium.org>

This allows the input clocks to the Exynos AudioSS block to be specified
via device-tree bindings.  Default names will be used when an input clock
is not given.  This will be useful when adding support for the Exynos5420
where the audio bus clock is called "sclk_maudio0" instead of "sclk_audio0".

Signed-off-by: Andrew Bresticker <abrestic at chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57833
Reviewed-by: Simon Glass <sjg at chromium.org>
---
 .../devicetree/bindings/clock/clk-exynos-audss.txt |   31 ++++++++++++++++++-
 drivers/clk/samsung/clk-exynos-audss.c             |   28 +++++++++++++++--
 2 files changed, 53 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
index 3115930..66d4662 100644
--- a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
+++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
@@ -16,6 +16,21 @@ Required Properties:
 
 - #clock-cells: should be 1.
 
+Optional Properties:
+
+- clocks:
+  - pll_ref: Fixed rate PLL reference clock, parent of mout_audss. "fin_pll"
+    is used if not specified.
+  - pll_in: Input PLL to the AudioSS block, parent of mout_audss. "fout_epll"
+    is used if not specified.
+  - cdclk: External i2s clock, parent of mout_i2s. "cdclk0" is used if not
+    specified.
+  - sclk_audio: Audio bus clock, parent of mout_i2s. "sclk_audio0" is used if
+    not specified.
+
+- clock-names: Aliases for the above clocks. They should be "pll_ref",
+  "pll_in", "cdclk", and "sclk_audio", respectively.
+
 The following is the list of clocks generated by the controller. Each clock is
 assigned an identifier and client nodes use this identifier to specify the
 clock which they consume. Some of the clocks are available only on a particular
@@ -38,15 +53,27 @@ pcm_bus         8
 sclk_pcm        9
 adma            10      Exynos5420
 
-Example 1: An example of a clock controller node is listed below.
+Example 1: An example of a clock controller node using the default input
+	   clock names is listed below.
+
+clock_audss: audss-clock-controller at 3810000 {
+	compatible = "samsung,exynos5250-audss-clock";
+	reg = <0x03810000 0x0C>;
+	#clock-cells = <1>;
+};
+
+Example 2: An example of a clock controller node with audio bus input clock
+	   specified is listed below.
 
 clock_audss: audss-clock-controller at 3810000 {
 	compatible = "samsung,exynos5250-audss-clock";
 	reg = <0x03810000 0x0C>;
 	#clock-cells = <1>;
+	clocks = <&clock 148>;
+	clock-names = "sclk_audio";
 };
 
-Example 2: I2S controller node that consumes the clock generated by the clock
+Example 3: I2S controller node that consumes the clock generated by the clock
            controller. Refer to the standard clock bindings for information
            about 'clocks' and 'clock-names' property.
 
diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
index 86d2606..39d3383 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -32,10 +32,6 @@ static unsigned long reg_save[][2] = {
 	{ASS_CLK_GATE, 0},
 };
 
-/* list of all parent clock list */
-static const char *mout_audss_p[] = { "fin_pll", "fout_epll" };
-static const char *mout_i2s_p[] = { "mout_audss", "cdclk0", "sclk_audio0" };
-
 #ifdef CONFIG_PM_SLEEP
 static int exynos_audss_clk_suspend(void)
 {
@@ -64,6 +60,10 @@ static struct syscore_ops exynos_audss_clk_syscore_ops = {
 /* register exynos_audss clocks */
 void __init exynos_audss_clk_init(struct device_node *np)
 {
+	const char *mout_audss_p[] = {"fin_pll", "fout_epll"};
+	const char *mout_i2s_p[] = {"mout_audss", "cdclk0", "sclk_audio0"};
+	struct clk *pll_ref, *pll_in, *cdclk, *sclk_audio;
+
 	reg_base = of_iomap(np, 0);
 	if (!reg_base) {
 		pr_err("%s: failed to map audss registers\n", __func__);
@@ -81,10 +81,30 @@ void __init exynos_audss_clk_init(struct device_node *np)
 	clk_data.clk_num = EXYNOS_AUDSS_MAX_CLKS;
 	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
 
+	pll_ref = of_clk_get_by_name(np, "pll_ref");
+	pll_in = of_clk_get_by_name(np, "pll_in");
+	if (!IS_ERR(pll_ref)) {
+		mout_audss_p[0] = __clk_get_name(pll_ref);
+		clk_put(pll_ref);
+	}
+	if (!IS_ERR(pll_in)) {
+		mout_audss_p[1] = __clk_get_name(pll_in);
+		clk_put(pll_in);
+	}
 	clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, "mout_audss",
 				mout_audss_p, ARRAY_SIZE(mout_audss_p), 0,
 				reg_base + ASS_CLK_SRC, 0, 1, 0, &lock);
 
+	cdclk = of_clk_get_by_name(np, "cdclk");
+	sclk_audio = of_clk_get_by_name(np, "sclk_audio");
+	if (!IS_ERR(cdclk)) {
+		mout_i2s_p[1] = __clk_get_name(cdclk);
+		clk_put(cdclk);
+	}
+	if (!IS_ERR(sclk_audio)) {
+		mout_i2s_p[2] = __clk_get_name(sclk_audio);
+		clk_put(sclk_audio);
+	}
 	clk_table[EXYNOS_MOUT_I2S] = clk_register_mux(NULL, "mout_i2s",
 				mout_i2s_p, ARRAY_SIZE(mout_i2s_p), 0,
 				reg_base + ASS_CLK_SRC, 2, 2, 0, &lock);
-- 
1.7.4.4



From padma.v at samsung.com  Wed Jul 10 08:11:52 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Wed, 10 Jul 2013 17:41:52 +0530
Subject: [PATCH 3/4] ARM: dts: Correct the /include entry on exynos5420 dtsi
 file
In-Reply-To: <1373458313-18970-1-git-send-email-padma.v@samsung.com>
References: <1373458313-18970-1-git-send-email-padma.v@samsung.com>
Message-ID: <1373458313-18970-4-git-send-email-padma.v@samsung.com>

This patch corrects the /include to #include on exynos5420

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---
 arch/arm/boot/dts/exynos5420.dtsi |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 8c54c4b..da55160 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -14,7 +14,7 @@
  */
 
 #include "exynos5.dtsi"
-/include/ "exynos5420-pinctrl.dtsi"
+#include "exynos5420-pinctrl.dtsi"
 / {
 	compatible = "samsung,exynos5420";
 
-- 
1.7.4.4



From padma.v at samsung.com  Wed Jul 10 08:11:53 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Wed, 10 Jul 2013 17:41:53 +0530
Subject: [PATCH 4/4] ARM: dts: exynos5420: add audio clock controller
In-Reply-To: <1373458313-18970-1-git-send-email-padma.v@samsung.com>
References: <1373458313-18970-1-git-send-email-padma.v@samsung.com>
Message-ID: <1373458313-18970-5-git-send-email-padma.v@samsung.com>

From: Andrew Bresticker <abrestic at chromium.org>

This adds device-tree bindings for the audio subsystem clock controller
on Exynos 5420.

Signed-off-by: Andrew Bresticker <abrestic at chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57712
Reviewed-by: Simon Glass <sjg at chromium.org>
Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---
 arch/arm/boot/dts/exynos5420.dtsi |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index da55160..a84f5f1 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -15,6 +15,9 @@
 
 #include "exynos5.dtsi"
 #include "exynos5420-pinctrl.dtsi"
+
+#include <dt-bindings/clk/exynos-audss-clk.h>
+
 / {
 	compatible = "samsung,exynos5420";
 
@@ -65,6 +68,14 @@
 		#clock-cells = <1>;
 	};
 
+	clock_audss: audss-clock-controller at 3810000 {
+		compatible = "samsung,exynos5420-audss-clock";
+		reg = <0x03810000 0x0C>;
+		#clock-cells = <1>;
+		clocks = <&clock 148>;
+		clock-names = "sclk_audio";
+	};
+
 	mct at 101C0000 {
 		compatible = "samsung,exynos4210-mct";
 		reg = <0x101C0000 0x800>;
-- 
1.7.4.4



From padma.v at samsung.com  Wed Jul 10 08:11:50 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Wed, 10 Jul 2013 17:41:50 +0530
Subject: [PATCH 1/4] clk: exynos-audss: add support for Exynos 5420
In-Reply-To: <1373458313-18970-1-git-send-email-padma.v@samsung.com>
References: <1373458313-18970-1-git-send-email-padma.v@samsung.com>
Message-ID: <1373458313-18970-2-git-send-email-padma.v@samsung.com>

From: Andrew Bresticker <abrestic at chromium.org>

The AudioSS block on Exynos 5420 has an additional clock gate for the
ADMA bus clock.

Signed-off-by: Andrew Bresticker <abrestic at chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57711
Reviewed-by: Simon Glass <sjg at chromium.org>
---
 .../devicetree/bindings/clock/clk-exynos-audss.txt |    7 +++++--
 drivers/clk/samsung/clk-exynos-audss.c             |    8 ++++++++
 include/dt-bindings/clk/exynos-audss-clk.h         |    3 ++-
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
index a120180..3115930 100644
--- a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
+++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
@@ -8,8 +8,10 @@ Required Properties:
 
 - compatible: should be one of the following:
   - "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4 SoCs.
-  - "samsung,exynos5250-audss-clock" - controller compatible with all Exynos5 SoCs.
-
+  - "samsung,exynos5250-audss-clock" - controller compatible with Exynos5250
+    SoCs.
+  - "samsung,exynos5420-audss-clock" - controller compatible with Exynos5420
+    SoCs.
 - reg: physical base address and length of the controller's register set.
 
 - #clock-cells: should be 1.
@@ -34,6 +36,7 @@ i2s_bus         6
 sclk_i2s        7
 pcm_bus         8
 sclk_pcm        9
+adma            10      Exynos5420
 
 Example 1: An example of a clock controller node is listed below.
 
diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
index 9b1bbd5..86d2606 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -121,6 +121,12 @@ void __init exynos_audss_clk_init(struct device_node *np)
 				"div_pcm0", CLK_SET_RATE_PARENT,
 				reg_base + ASS_CLK_GATE, 5, 0, &lock);
 
+	if (of_device_is_compatible(np, "samsung,exynos5420-audss-clock")) {
+		clk_table[EXYNOS_ADMA] = clk_register_gate(NULL, "adma",
+				"dout_srp", CLK_SET_RATE_PARENT,
+				reg_base + ASS_CLK_GATE, 9, 0, &lock);
+	}
+
 #ifdef CONFIG_PM_SLEEP
 	register_syscore_ops(&exynos_audss_clk_syscore_ops);
 #endif
@@ -131,3 +137,5 @@ CLK_OF_DECLARE(exynos4210_audss_clk, "samsung,exynos4210-audss-clock",
 		exynos_audss_clk_init);
 CLK_OF_DECLARE(exynos5250_audss_clk, "samsung,exynos5250-audss-clock",
 		exynos_audss_clk_init);
+CLK_OF_DECLARE(exynos5420_audss_clk, "samsung,exynos5420-audss-clock",
+		exynos_audss_clk_init);
diff --git a/include/dt-bindings/clk/exynos-audss-clk.h b/include/dt-bindings/clk/exynos-audss-clk.h
index 8279f42..0ae6f5a 100644
--- a/include/dt-bindings/clk/exynos-audss-clk.h
+++ b/include/dt-bindings/clk/exynos-audss-clk.h
@@ -19,7 +19,8 @@
 #define EXYNOS_SCLK_I2S	7
 #define EXYNOS_PCM_BUS		8
 #define EXYNOS_SCLK_PCM	9
+#define EXYNOS_ADMA		10
 
-#define EXYNOS_AUDSS_MAX_CLKS	10
+#define EXYNOS_AUDSS_MAX_CLKS	11
 
 #endif
-- 
1.7.4.4



From padma.v at samsung.com  Wed Jul 10 08:14:08 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Wed, 10 Jul 2013 17:44:08 +0530
Subject: [PATCH 1/2] ARM: dts: Move the common DMA controller nodes to
 exynos5.dtsi
In-Reply-To: <1373458449-19039-1-git-send-email-padma.v@samsung.com>
References: <1373458449-19039-1-git-send-email-padma.v@samsung.com>
Message-ID: <1373458449-19039-2-git-send-email-padma.v@samsung.com>

exynos5250 and exynos5420 has 4 DMA controllers in common. So this patch
moves these nodes to common file keeping the dma controllers clk info in
the exynos5250 dtsi file.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---
 arch/arm/boot/dts/exynos5.dtsi    |   44 +++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/exynos5250.dtsi |   30 -------------------------
 2 files changed, 44 insertions(+), 30 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index f65e124..cac35c8 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -50,6 +50,50 @@
 		interrupts = <1 9 0xf04>;
 	};
 
+	amba {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "arm,amba-bus";
+		interrupt-parent = <&gic>;
+		ranges;
+
+		pdma0: pdma at 121A0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x121A0000 0x1000>;
+			interrupts = <0 34 0>;
+			#dma-cells = <1>;
+			#dma-channels = <8>;
+			#dma-requests = <32>;
+		};
+
+		pdma1: pdma at 121B0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x121B0000 0x1000>;
+			interrupts = <0 35 0>;
+			#dma-cells = <1>;
+			#dma-channels = <8>;
+			#dma-requests = <32>;
+		};
+
+		mdma0: mdma at 10800000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x10800000 0x1000>;
+			interrupts = <0 33 0>;
+			#dma-cells = <1>;
+			#dma-channels = <8>;
+			#dma-requests = <1>;
+		};
+
+		mdma1: mdma at 11C10000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x11C10000 0x1000>;
+			interrupts = <0 124 0>;
+			#dma-cells = <1>;
+			#dma-channels = <8>;
+			#dma-requests = <1>;
+		};
+	};
+
 	dwmmc_0: dwmmc0 at 12200000 {
 		compatible = "samsung,exynos5250-dw-mshc";
 		interrupts = <0 75 0>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 41cd625..3a474c4 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -511,54 +511,24 @@
 	};
 
 	amba {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		compatible = "arm,amba-bus";
-		interrupt-parent = <&gic>;
-		ranges;
-
 		pdma0: pdma at 121A0000 {
-			compatible = "arm,pl330", "arm,primecell";
-			reg = <0x121A0000 0x1000>;
-			interrupts = <0 34 0>;
 			clocks = <&clock 275>;
 			clock-names = "apb_pclk";
-			#dma-cells = <1>;
-			#dma-channels = <8>;
-			#dma-requests = <32>;
 		};
 
 		pdma1: pdma at 121B0000 {
-			compatible = "arm,pl330", "arm,primecell";
-			reg = <0x121B0000 0x1000>;
-			interrupts = <0 35 0>;
 			clocks = <&clock 276>;
 			clock-names = "apb_pclk";
-			#dma-cells = <1>;
-			#dma-channels = <8>;
-			#dma-requests = <32>;
 		};
 
 		mdma0: mdma at 10800000 {
-			compatible = "arm,pl330", "arm,primecell";
-			reg = <0x10800000 0x1000>;
-			interrupts = <0 33 0>;
 			clocks = <&clock 271>;
 			clock-names = "apb_pclk";
-			#dma-cells = <1>;
-			#dma-channels = <8>;
-			#dma-requests = <1>;
 		};
 
 		mdma1: mdma at 11C10000 {
-			compatible = "arm,pl330", "arm,primecell";
-			reg = <0x11C10000 0x1000>;
-			interrupts = <0 124 0>;
 			clocks = <&clock 271>;
 			clock-names = "apb_pclk";
-			#dma-cells = <1>;
-			#dma-channels = <8>;
-			#dma-requests = <1>;
 		};
 	};
 
-- 
1.7.4.4



From padma.v at samsung.com  Wed Jul 10 08:14:07 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Wed, 10 Jul 2013 17:44:07 +0530
Subject: [PATCH 0/2] Move comon DMA nodes to exynos5.dtsi and
Message-ID: <1373458449-19039-1-git-send-email-padma.v@samsung.com>

Exynos5250 and Exynos5420 has 4 DMA controllers in common. So this patch
set moved the common nodes to exynos.dtsi keeping the clk info seperate
for both the platforms. Exynos5420 has a separate DMA controller for audio
IPs. So this patch set also adds the ADMA node on Exynos5420.

Padmavathi Venna (2):
  ARM: dts: Move the common DMA controller nodes to exynos5.dtsi
  ARM: dts: Add DMA controller node info on Exynos5420.

 arch/arm/boot/dts/exynos5.dtsi    |   44 +++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/exynos5250.dtsi |   30 -------------------------
 arch/arm/boot/dts/exynos5420.dtsi |   33 +++++++++++++++++++++++++++
 3 files changed, 77 insertions(+), 30 deletions(-)

-- 
1.7.4.4



From padma.v at samsung.com  Wed Jul 10 08:14:09 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Wed, 10 Jul 2013 17:44:09 +0530
Subject: [PATCH 2/2] ARM: dts: Add DMA controller node info on Exynos5420.
In-Reply-To: <1373458449-19039-1-git-send-email-padma.v@samsung.com>
References: <1373458449-19039-1-git-send-email-padma.v@samsung.com>
Message-ID: <1373458449-19039-3-git-send-email-padma.v@samsung.com>

Exynos5420 has one separate DMA controller for I2S0 and PCM0. This patch
adds the same node on exynos5420 dtsi and adds the DMA clk info for the
remaining DMA controllers.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---
 arch/arm/boot/dts/exynos5420.dtsi |   33 +++++++++++++++++++++++++++++++++
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index a84f5f1..7035a4b 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -137,6 +137,39 @@
 		interrupts = <0 47 0>;
 	};
 
+	amba {
+		pdma0: pdma at 121A0000 {
+			clocks = <&clock 362>;
+			clock-names = "apb_pclk";
+		};
+
+		pdma1: pdma at 121B0000 {
+			clocks = <&clock 363>;
+			clock-names = "apb_pclk";
+		};
+
+		mdma0: mdma at 10800000 {
+			clocks = <&clock 473>;
+			clock-names = "apb_pclk";
+		};
+
+		mdma1: mdma at 11C10000 {
+			clocks = <&clock 442>;
+			clock-names = "apb_pclk";
+		};
+
+		adma: adma at 03880000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x03880000 0x1000>;
+			interrupts = <0 110 0>;
+			clocks = <&clock_audss EXYNOS_ADMA>;
+			clock-names = "apb_pclk";
+			#dma-cells = <1>;
+			#dma-channels = <6>;
+			#dma-requests = <16>;
+		};
+	};
+
 	serial at 12C00000 {
 		clocks = <&clock 257>, <&clock 128>;
 		clock-names = "uart", "clk_uart_baud0";
-- 
1.7.4.4



From rogerq at ti.com  Wed Jul 10 08:10:24 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 10 Jul 2013 15:10:24 +0300
Subject: [PATCH 0/4] pinctrl single support for SoC specific features
In-Reply-To: <20130607203936.16513.57494.stgit@localhost>
References: <20130607203936.16513.57494.stgit@localhost>
Message-ID: <51DD4F30.7050603@ti.com>

Hi Tony,

On 06/07/2013 11:50 PM, Tony Lindgren wrote:
> Hi all,
> 
> Here are few patches to add support for SoC specific features
> to pinctrl-single. This is needed at least for omaps to support
> IO chain wake-up events from deeper idle states.
> 
> With this patch series, device drivers can request named pinctrl
> states like active and idle from the PM runtime suspend and resume
> calls to set the wake enable bits for selected pins. Further
> the device driver can toggle the wake-up feature as needed based on
> the device_may_wakeup() state set by the standard sysfs
> power/wakeup entry.
> 
> This is implemented in a separate pinctrl-single-omap driver that
> works together with pinctrl-single. This way the SoC specific
> are separated from the common pinctrl-single, and allows a relatively
> easy way to implement SoC specific things like wake-up events,
> pin interrupts, and GPIO.

What's the status of this? Would be nice to get it in 3.12. I'm basing
the OMAP USB host wakeup support on this.

cheers,
-roger


From tony at atomide.com  Wed Jul 10 08:10:37 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Jul 2013 05:10:37 -0700
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <87mwpuakod.fsf@linaro.org>
References: <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi>
 <87mwpuakod.fsf@linaro.org>
Message-ID: <20130710121037.GS5523@atomide.com>

* Kevin Hilman <khilman at linaro.org> [130710 01:29]:
> Felipe Balbi <balbi at ti.com> writes:
> 
> > Hi,
> >
> > On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
> >> >>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
> >> >>>>>> of -1 for the serial driver?
> >> >>>>>>
> >> >>>>>
> >> >>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> >> >>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> >> >>>
> >> >>> OK
> >> >>
> >> >> Issue 2: Causing boot to stop when serial driver is initialized.
> >> >> (After Issue 1 is fixed)
> >> >>
> >> >> I could narrow this down to the change done to return -EINVAL
> >> >> instead of 0 in serial_omap_get_context_loss_count() as part of
> >> >> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
> >> >> Fix device tree based PM runtime"
> >> >>
> >> >> What this change in turn seems to do is cause a
> >> >> serial_omap_restore_context() to get called as part of
> >> >> serial_omap_runtime_resume() which was not the case when
> >> >> serial_omap_get_context_loss_count() returned 0
> >> >>
> >> >> from serial_omap_runtime_resume():
> >> >> -----
> >> >>         int loss_cnt = serial_omap_get_context_loss_count(up);
> >> >>
> >> >>         if (loss_cnt < 0) {
> >> >>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
> >> >>                         loss_cnt);
> >> >>                 serial_omap_restore_context(up);
> >> >>         } else if (up->context_loss_cnt != loss_cnt) {
> >> >>                 serial_omap_restore_context(up);
> >> >>         }
> >> >> -----
> >> >>
> >> >> I am still working on why a serial_omap_restore_context() could
> >> >> have caused console to die. I will work with Sourav on this and
> >> >> post the fixes for both issue 1 and issue2 once its clear on whats
> >> >> really causing issue 2.
> >> > 
> >> > That's because we don't have the omap specific pdata callbacks for
> >> > context loss any longer. We may be able to detect when the context
> >> > was really lost in the serial driver, and only then call the
> >> > serial_omap_restore_context().
> >> 
> >> Right, but calling serial_omap_restore_context() even when the context
> >> is not lost, should not ideally cause an issue.
> >
> > it does in one condition. If context hasn't been saved before. And that
> > can happen in the case of wrong pm runtime status for that device.
> >
> > Imagine the device is marked as suspended even though it's fully enabled
> > (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> > your context structure is all zeroes (context has never been saved
> > before) then when you call pm_runtime_get_sync() on probe() your
> > ->runtime_resume() will get called, which will restore context,
> > essentially undoing anything which was configured by u-boot.
> >
> > Am I missing something ?
> 
> You're right, the _set_active() is crucial in the case when we prevent
> the console UART from idling during boot (though that shouldn't be
> happening in mainline unless the fix for "Issue 1" is done.)

OK so how should we fix this?

If the problem is hwmod automatically resetting things early while
earlycon is running, then the reset should happen later.

If the problem is omap-serial.c idling things while earlycon is
running, then omap-serial.c should be fixed.

In any case we want mach-omap2/serial.c out of the way completely
for DT based booting.

Regards,

Tony


From grygorii.strashko at ti.com  Wed Jul 10 08:16:54 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Wed, 10 Jul 2013 15:16:54 +0300
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130709194131.GA12523@arwen.pp.htv.fi>
References: <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <51DBA0C2.6030003@ti.com>
 <20130709064212.GB5552@arwen.pp.htv.fi> <51DC5D90.1010603@ti.com>
 <20130709194131.GA12523@arwen.pp.htv.fi>
Message-ID: <51DD50B6.5030604@ti.com>

On 07/09/2013 10:41 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 09, 2013 at 09:59:28PM +0300, Grygorii Strashko wrote:
>>>>> Imagine the device is marked as suspended even though it's fully enabled
>>>>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
>>>>> your context structure is all zeroes (context has never been saved
>>>>> before) then when you call pm_runtime_get_sync() on probe() your
>>>>> ->runtime_resume() will get called, which will restore context,
>>>>> essentially undoing anything which was configured by u-boot.
>>>>
>>>> This could be a problem for drivers which do a save context in ->runtime_suspend()
>>>> but from what I see with omap serial, there is no save context done as part of
>>>> ->runtime_suspend.
>>>
>>> right, because context is "saved" in set_termios. probe() will get
>>> called much before set_termios() has a chance to run, right ?
>>>
>>> Same problem will trigger in that case.
>>>
>>> I still think patch below is necessary
>>>
>>>>> (completely untested, didn't even try to compile, just to illustrate)
>>>>>
>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
>>>>> index 7341eff..d8dca68 100644
>>>>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>>>>> @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
>>>>>   	    (postsetup_state == _HWMOD_STATE_IDLE)) {
>>>>>   		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
>>>>>   		postsetup_state = _HWMOD_STATE_ENABLED;
>>>>> +
>>>>> +		/* tell pm_runtime this device is already active */
>>>>> +		pm_runtime_set_active(&oh->od->pdev->dev);
>>>>> +	} else {
>>>>> +		/* tell pm_runtime this device is trully suspended */
>>>>> +		pm_runtime_set_suspended(&oh->od->pdev->dev);
>>>>>   	}
>>>>>
>>>>>   	if (postsetup_state == _HWMOD_STATE_IDLE)
>>>
>>
>> This will not work - _setup_postsetup() is called from core_initcall
>> level and OMAP devices have not been created at this moment yet
>> (of_platform_populate() is called from
>> customize_machine->init_machine->omap_generic_init() at arch_initcall time)
>
> fair enough, but something *like* that needs to be done. If pm_runtime
> doesn't know the state of the device by the time pm_runtime_enable() is
> called, the wrong assumptions might be made and we will forever have
> such problems as our ->runtime_resume() callback being called when it
> shouldn't.
>
>> More over, I don't recommend to depend on hwmod->od field - it's been
>> created to support OPPs and it's obsolete now in case of DT use.
>
> that's alright, but still we need something similar.
>
> But in any case, if on DT boot that's not used, than *what* uses
> HWMOD_INIT_NO_IDLE during DT boot ?
>
> There's a single place in kernel source which checks if
> HWMOD_INIT_NO_IDLE is set, and that's the place which I patched.
>
> We, certainly, need a way to tell pm_runtime if the device is active or
> suspended by the time we reach our probe() function. Either we assume
> *all* devices are active and we blindly call pm_runtime_set_active() for
> all devices, or we assume *all* devices are suspended as we call
> pm_runtime_set_suspend() for all devices, or we figure out which ones
> are active and which are not and call pm_runtime_set_{active,suspend}()
> conditionally.
>
>> Seems, This issue need to be handled in driver for DT boot use case,
>> possibly cmdline need to be parsed in the same way as it's done in
>> omap_serial_early_init().
>
> so you want *every* single driver to parse their own cmdline ? How big
> would the cmdline become ? This makes no sense.
>

Agree here. Seems there two similar issues:
- this one with omap_serial
- GPIO reset issue http://www.spinics.net/lists/linux-omap/msg84186.html
   (similar issue is observed on OMAP4460+TPS6236x)

And I think, that HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags can't 
be treated as
SoC (IP) specific parameters any more - they should be board specific.

I think, some kind of board_layout {} DT definition need to be created 
to solve these issues (just an idea). For example:

Board DTS file:
board_layout {
  ti,hwmods-init-no-reset = "gpio1", "uart3";
  ti,hwmods-init-no-idle = "uart3";
}

Then above DT parameters can be used in omap_hwmod_setup_all()->_setup()
and omap_device_build_from_dt().
- omap_hwmod_setup_all()->_setup() will configure hwmod's flags
- omap_device_build_from_dt() will check for HWMOD_INIT_NO_IDLE and
   call pm_runtime_set_active() if needed (this is the valid place for that)

NOTE. "ti,hwmods-init-no-reset" and "ti,hwmods-init-no-idle" can't be 
defined per device, because HWMOD framework will work 
(init/reset/setup/idle) with IP even if corresponding IP is not defined 
in DT.

More over, board_layout{} section can be used to define some common for 
OMAP2+ boards properties or enable/disable PM features, like:
- Setup clksetup/clkshoutdown time for oscillator
- enable/disable OFF-mode

Regards,
-grygorii



From jason at lakedaemon.net  Wed Jul 10 08:20:23 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 10 Jul 2013 08:20:23 -0400
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <175CCF5F49938B4D99B2E3EF7F558EBE3DBC97FA8F@SC-VEXCH4.marvell.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <175CCF5F49938B4D99B2E3EF7F558EBE3DBC97FA8F@SC-VEXCH4.marvell.com>
Message-ID: <20130710122023.GN11908@titan.lakedaemon.net>

Neil,

On Wed, Jul 10, 2013 at 12:25:17AM -0700, Neil Zhang wrote:
> Jason,
> 
> > -----Original Message-----
> > From: Jason Cooper [mailto:jason at lakedaemon.net]
> > Sent: 2013?7?9? 20:49
> > To: Neil Zhang
> > Cc: grant.likely at linaro.org; haojian.zhuang at gmail.com; arnd at arndb.de;
> > devicetree-discuss at lists.ozlabs.org; linux-kernel at vger.kernel.org;
> > linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
> >
> > Neil,
> >
> > On Tue, Jul 09, 2013 at 02:42:44PM +0800, Neil Zhang wrote:
> > > The documented vendor prefix for Marvell is 'marvell', not 'mrvl', so
> > > let's change it.
> > >
> > > Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> > > ---
> > >  .../devicetree/bindings/arm/mrvl/intc.txt          |   16 +++---
> > >  .../devicetree/bindings/arm/mrvl/mrvl.txt          |    6 +-
> > >  .../devicetree/bindings/arm/mrvl/timer.txt         |    4 +-
> > >  Documentation/devicetree/bindings/i2c/i2c-pxa.txt  |   14 +++---
> > >  .../devicetree/bindings/mmc/sdhci-pxa.txt          |    8 ++--
> > >  .../devicetree/bindings/rtc/sa1100-rtc.txt         |    4 +-
> > >  .../devicetree/bindings/serial/mrvl-serial.txt     |    2 +-
> > >  arch/arm/boot/dts/mmp2-brownstone.dts              |    2 +-
> > >  arch/arm/boot/dts/mmp2.dtsi                        |   56
> > ++++++++++----------
> > >  arch/arm/boot/dts/pxa168-aspenite.dts              |    2 +-
> > >  arch/arm/boot/dts/pxa168.dtsi                      |   24
> > ++++----
> > >  arch/arm/boot/dts/pxa2xx.dtsi                      |   16 +++---
> > >  arch/arm/boot/dts/pxa3xx.dtsi                      |    2 +-
> > >  arch/arm/boot/dts/pxa910-dkb.dts                   |    2 +-
> > >  arch/arm/boot/dts/pxa910.dtsi                      |   27
> > +++++-----
> > >  arch/arm/mach-mmp/irq.c                            |   16
> > +++---
> > >  arch/arm/mach-mmp/mmp-dt.c                         |   28
> > +++++-----
> > >  arch/arm/mach-mmp/mmp2-dt.c                        |   16
> > +++---
> > >  arch/arm/mach-mmp/time.c                           |    2 +-
> > >  arch/arm/mach-pxa/pxa-dt.c                         |   14
> > +++---
> > >  drivers/i2c/busses/i2c-pxa.c                       |   10 ++--
> > >  drivers/mmc/host/sdhci-pxav2.c                     |    4 +-
> > >  drivers/mmc/host/sdhci-pxav3.c                     |    4 +-
> > >  drivers/rtc/rtc-sa1100.c                           |    4 +-
> > >  drivers/tty/serial/pxa.c                           |    4 +-
> > >  25 files changed, 144 insertions(+), 143 deletions(-)
> >
> > I agree with the need to change, however, this has been in the binding
> > documentation since v3.5.  I wish we had caught this when we decided
> > against using stock ticker symbols (not all stock markets use alphabetical
> > abbreviated names, not all companies are listed on any stock exchange).
> >
> > To do this properly, the drivers are going to have to be compatible with the
> > old and the new names, and the binding docs updated to reflect the legacy
> > name and the preferred name.
> >
> Do you mean it's better to support both legacy and preferred name at the same time?

Please keep in mind that the DT is supposed to be tied to the hardware,
*not* the kernel.  iow, a dtb comes with a board, and the user/OS
upgrades the kernel as needed w/o upgrading or changing the dtb.

So the question you need to ask yourself is: Are there any users (since
v3.5) that are doing this?  If so, they have "mrvl,..." compatible
strings in their dtbs.  You don't want to break their systems on kernel
upgrade, right?

So you can change the binding to say the correct string is
"marvell,...", but that driver X must have an extra compatible entry for
"mrvl,..." so as not to break dtbs generated from v3.5 to v3.10.

You might even be able to get away with just adding a comment beside the
"mrvl,..." string in the driver.

Does that make sense?

thx,

Jason.


From tony at atomide.com  Wed Jul 10 08:24:17 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Jul 2013 05:24:17 -0700
Subject: [PATCH 0/4] pinctrl single support for SoC specific features
In-Reply-To: <51DD4F30.7050603@ti.com>
References: <20130607203936.16513.57494.stgit@localhost>
 <51DD4F30.7050603@ti.com>
Message-ID: <20130710122417.GT5523@atomide.com>

* Roger Quadros <rogerq at ti.com> [130710 05:16]:
> Hi Tony,
> 
> On 06/07/2013 11:50 PM, Tony Lindgren wrote:
> > Hi all,
> > 
> > Here are few patches to add support for SoC specific features
> > to pinctrl-single. This is needed at least for omaps to support
> > IO chain wake-up events from deeper idle states.
> > 
> > With this patch series, device drivers can request named pinctrl
> > states like active and idle from the PM runtime suspend and resume
> > calls to set the wake enable bits for selected pins. Further
> > the device driver can toggle the wake-up feature as needed based on
> > the device_may_wakeup() state set by the standard sysfs
> > power/wakeup entry.
> > 
> > This is implemented in a separate pinctrl-single-omap driver that
> > works together with pinctrl-single. This way the SoC specific
> > are separated from the common pinctrl-single, and allows a relatively
> > easy way to implement SoC specific things like wake-up events,
> > pin interrupts, and GPIO.
> 
> What's the status of this? Would be nice to get it in 3.12. I'm basing
> the OMAP USB host wakeup support on this.

How about I'll push an immutable branch against v3.11-rc1 when it's
tagged and send a pull request to Linus W for the first three patches?

That way we can base other branches on this if needed.

Linus, does that sound OK to you?

Regards,

Tony


From jason at lakedaemon.net  Wed Jul 10 08:24:33 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 10 Jul 2013 08:24:33 -0400
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <CAN1soZxiOh6TpbUOCUzK8gNwmvjbT3ihkUWaw8tuZ7md+NVA2g@mail.gmail.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <CAN1soZxiOh6TpbUOCUzK8gNwmvjbT3ihkUWaw8tuZ7md+NVA2g@mail.gmail.com>
Message-ID: <20130710122433.GO11908@titan.lakedaemon.net>

On Wed, Jul 10, 2013 at 04:19:46PM +0800, Haojian Zhuang wrote:
> On Tue, Jul 9, 2013 at 8:49 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> > Neil,
> >
> > On Tue, Jul 09, 2013 at 02:42:44PM +0800, Neil Zhang wrote:
> >> The documented vendor prefix for Marvell is 'marvell', not 'mrvl', so
> >> let's change it.
> >>
> >> Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> >> ---
> >>  .../devicetree/bindings/arm/mrvl/intc.txt          |   16 +++---
> >>  .../devicetree/bindings/arm/mrvl/mrvl.txt          |    6 +-
> >>  .../devicetree/bindings/arm/mrvl/timer.txt         |    4 +-
> >>  Documentation/devicetree/bindings/i2c/i2c-pxa.txt  |   14 +++---
> >>  .../devicetree/bindings/mmc/sdhci-pxa.txt          |    8 ++--
> >>  .../devicetree/bindings/rtc/sa1100-rtc.txt         |    4 +-
> >>  .../devicetree/bindings/serial/mrvl-serial.txt     |    2 +-
> >>  arch/arm/boot/dts/mmp2-brownstone.dts              |    2 +-
> >>  arch/arm/boot/dts/mmp2.dtsi                        |   56 ++++++++++----------
> >>  arch/arm/boot/dts/pxa168-aspenite.dts              |    2 +-
> >>  arch/arm/boot/dts/pxa168.dtsi                      |   24 ++++----
> >>  arch/arm/boot/dts/pxa2xx.dtsi                      |   16 +++---
> >>  arch/arm/boot/dts/pxa3xx.dtsi                      |    2 +-
> >>  arch/arm/boot/dts/pxa910-dkb.dts                   |    2 +-
> >>  arch/arm/boot/dts/pxa910.dtsi                      |   27 +++++-----
> >>  arch/arm/mach-mmp/irq.c                            |   16 +++---
> >>  arch/arm/mach-mmp/mmp-dt.c                         |   28 +++++-----
> >>  arch/arm/mach-mmp/mmp2-dt.c                        |   16 +++---
> >>  arch/arm/mach-mmp/time.c                           |    2 +-
> >>  arch/arm/mach-pxa/pxa-dt.c                         |   14 +++---
> >>  drivers/i2c/busses/i2c-pxa.c                       |   10 ++--
> >>  drivers/mmc/host/sdhci-pxav2.c                     |    4 +-
> >>  drivers/mmc/host/sdhci-pxav3.c                     |    4 +-
> >>  drivers/rtc/rtc-sa1100.c                           |    4 +-
> >>  drivers/tty/serial/pxa.c                           |    4 +-
> >>  25 files changed, 144 insertions(+), 143 deletions(-)
> >
> > I agree with the need to change, however, this has been in the binding
> > documentation since v3.5.  I wish we had caught this when we decided
> > against using stock ticker symbols (not all stock markets use
> > alphabetical abbreviated names, not all companies are listed on any
> > stock exchange).
> >
> > To do this properly, the drivers are going to have to be compatible with
> > the old and the new names, and the binding docs updated to reflect the
> > legacy name and the preferred name.
> >
> 
> It's better to only use the new names.

In the dts{i}, yes.  But we don't want to break systems in the field
with "mrvl,..." compatible strings.  Therefore, at least the drivers
need an extra compatible string to support "mrvl,...".

If it had just been since v3.9, it'd be different/simpler.  However,
several vendors have opted to use kernels newer than v3.5, which makes
this scenario a real possibility.

thx,

Jason.


From balbi at ti.com  Wed Jul 10 08:25:16 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 10 Jul 2013 15:25:16 +0300
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51DD50B6.5030604@ti.com>
References: <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <51DBA0C2.6030003@ti.com>
 <20130709064212.GB5552@arwen.pp.htv.fi> <51DC5D90.1010603@ti.com>
 <20130709194131.GA12523@arwen.pp.htv.fi> <51DD50B6.5030604@ti.com>
Message-ID: <20130710122516.GE18966@arwen.pp.htv.fi>

Hi,

On Wed, Jul 10, 2013 at 03:16:54PM +0300, Grygorii Strashko wrote:
> >>>>>Imagine the device is marked as suspended even though it's fully enabled
> >>>>>(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> >>>>>your context structure is all zeroes (context has never been saved
> >>>>>before) then when you call pm_runtime_get_sync() on probe() your
> >>>>>->runtime_resume() will get called, which will restore context,
> >>>>>essentially undoing anything which was configured by u-boot.
> >>>>
> >>>>This could be a problem for drivers which do a save context in ->runtime_suspend()
> >>>>but from what I see with omap serial, there is no save context done as part of
> >>>>->runtime_suspend.
> >>>
> >>>right, because context is "saved" in set_termios. probe() will get
> >>>called much before set_termios() has a chance to run, right ?
> >>>
> >>>Same problem will trigger in that case.
> >>>
> >>>I still think patch below is necessary
> >>>
> >>>>>(completely untested, didn't even try to compile, just to illustrate)
> >>>>>
> >>>>>diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> >>>>>index 7341eff..d8dca68 100644
> >>>>>--- a/arch/arm/mach-omap2/omap_hwmod.c
> >>>>>+++ b/arch/arm/mach-omap2/omap_hwmod.c
> >>>>>@@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
> >>>>>  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
> >>>>>  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
> >>>>>  		postsetup_state = _HWMOD_STATE_ENABLED;
> >>>>>+
> >>>>>+		/* tell pm_runtime this device is already active */
> >>>>>+		pm_runtime_set_active(&oh->od->pdev->dev);
> >>>>>+	} else {
> >>>>>+		/* tell pm_runtime this device is trully suspended */
> >>>>>+		pm_runtime_set_suspended(&oh->od->pdev->dev);
> >>>>>  	}
> >>>>>
> >>>>>  	if (postsetup_state == _HWMOD_STATE_IDLE)
> >>>
> >>
> >>This will not work - _setup_postsetup() is called from core_initcall
> >>level and OMAP devices have not been created at this moment yet
> >>(of_platform_populate() is called from
> >>customize_machine->init_machine->omap_generic_init() at arch_initcall time)
> >
> >fair enough, but something *like* that needs to be done. If pm_runtime
> >doesn't know the state of the device by the time pm_runtime_enable() is
> >called, the wrong assumptions might be made and we will forever have
> >such problems as our ->runtime_resume() callback being called when it
> >shouldn't.
> >
> >>More over, I don't recommend to depend on hwmod->od field - it's been
> >>created to support OPPs and it's obsolete now in case of DT use.
> >
> >that's alright, but still we need something similar.
> >
> >But in any case, if on DT boot that's not used, than *what* uses
> >HWMOD_INIT_NO_IDLE during DT boot ?
> >
> >There's a single place in kernel source which checks if
> >HWMOD_INIT_NO_IDLE is set, and that's the place which I patched.
> >
> >We, certainly, need a way to tell pm_runtime if the device is active or
> >suspended by the time we reach our probe() function. Either we assume
> >*all* devices are active and we blindly call pm_runtime_set_active() for
> >all devices, or we assume *all* devices are suspended as we call
> >pm_runtime_set_suspend() for all devices, or we figure out which ones
> >are active and which are not and call pm_runtime_set_{active,suspend}()
> >conditionally.
> >
> >>Seems, This issue need to be handled in driver for DT boot use case,
> >>possibly cmdline need to be parsed in the same way as it's done in
> >>omap_serial_early_init().
> >
> >so you want *every* single driver to parse their own cmdline ? How big
> >would the cmdline become ? This makes no sense.
> >
> 
> Agree here. Seems there two similar issues:
> - this one with omap_serial
> - GPIO reset issue http://www.spinics.net/lists/linux-omap/msg84186.html
>   (similar issue is observed on OMAP4460+TPS6236x)
> 
> And I think, that HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags
> can't be treated as
> SoC (IP) specific parameters any more - they should be board specific.
> 
> I think, some kind of board_layout {} DT definition need to be
> created to solve these issues (just an idea). For example:
> 
> Board DTS file:
> board_layout {
>  ti,hwmods-init-no-reset = "gpio1", "uart3";
>  ti,hwmods-init-no-idle = "uart3";
> }

nah... if we go down the path of passing this info via DT, all you need
to pass is some information if the IP should be reset/idled or not
during initialization.

-- 
balbi
-------------- 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/20130710/dcf07749/attachment.sig>

From tony at atomide.com  Wed Jul 10 08:27:44 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Jul 2013 05:27:44 -0700
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130710121037.GS5523@atomide.com>
References: <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi>
 <87mwpuakod.fsf@linaro.org> <20130710121037.GS5523@atomide.com>
Message-ID: <20130710122744.GU5523@atomide.com>

* Tony Lindgren <tony at atomide.com> [130710 05:17]:
> * Kevin Hilman <khilman at linaro.org> [130710 01:29]:
> 
> If the problem is omap-serial.c idling things while earlycon is
> running, then omap-serial.c should be fixed.

If this is the case, then delaying the idling in omap-serial.c
should take care of the issue as earlycon gets disabled when
the real console has been initialized.

Regards,

Tony


From jonas.jensen at gmail.com  Wed Jul 10 08:43:59 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 10 Jul 2013 14:43:59 +0200
Subject: [PATCH v2] dmaengine: Add MOXA ART DMA engine driver
In-Reply-To: <1373446263-7772-1-git-send-email-jonas.jensen@gmail.com>
References: <1373446263-7772-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1373460239-20102-1-git-send-email-jonas.jensen@gmail.com>

Add dmaengine driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130703
    
    Changes since v1:
    
    1. remove use of vchan support

 drivers/dma/Kconfig      |   9 +
 drivers/dma/Makefile     |   1 +
 drivers/dma/moxart-dma.c | 477 +++++++++++++++++++++++++++++++++++++++++++++++
 drivers/dma/moxart-dma.h | 188 +++++++++++++++++++
 4 files changed, 675 insertions(+)
 create mode 100644 drivers/dma/moxart-dma.c
 create mode 100644 drivers/dma/moxart-dma.h

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..d4ba42b 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -300,6 +300,15 @@ config DMA_JZ4740
 	select DMA_ENGINE
 	select DMA_VIRTUAL_CHANNELS
 
+config MOXART_DMA
+	tristate "MOXART DMA support"
+	depends on ARCH_MOXART
+	select DMA_ENGINE
+	select DMA_VIRTUAL_CHANNELS
+	default n
+	help
+	  Enable support for the MOXA ART SoC DMA controller.
+
 config DMA_ENGINE
 	bool
 
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 5e0f2ef..470c11b 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_MMP_TDMA) += mmp_tdma.o
 obj-$(CONFIG_DMA_OMAP) += omap-dma.o
 obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o
 obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
+obj-$(CONFIG_MOXART_DMA) += moxart-dma.o
diff --git a/drivers/dma/moxart-dma.c b/drivers/dma/moxart-dma.c
new file mode 100644
index 0000000..16fddf4
--- /dev/null
+++ b/drivers/dma/moxart-dma.c
@@ -0,0 +1,477 @@
+/*
+ * MOXA ART SoCs DMA Engine support.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/irq.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+
+#include <asm/cacheflush.h>
+
+#include "dmaengine.h"
+#include "moxart-dma.h"
+
+static DEFINE_SPINLOCK(dma_lock);
+
+struct moxart_dma_chan {
+	struct dma_chan			chan;
+	int				ch_num;
+	bool				allocated;
+	int				error_flag;
+	struct moxart_dma_reg		*reg;
+	void				(*callback)(void *param);
+	void				*callback_param;
+	struct completion		dma_complete;
+	struct dma_slave_config		cfg;
+	struct dma_async_tx_descriptor	tx_desc;
+};
+
+struct moxart_dma_container {
+	int			ctlr;
+	struct dma_device	dma_slave;
+	struct moxart_dma_chan	slave_chans[APB_DMA_MAX_CHANNEL];
+};
+
+struct moxart_dma_container *mdc;
+
+static struct device *chan2dev(struct dma_chan *chan)
+{
+	return &chan->dev->device;
+}
+
+static inline struct moxart_dma_container
+*to_moxart_dma_container(struct dma_device *d)
+{
+	return container_of(d, struct moxart_dma_container, dma_slave);
+}
+
+static inline struct moxart_dma_chan *to_moxart_dma_chan(struct dma_chan *c)
+{
+	return container_of(c, struct moxart_dma_chan, chan);
+}
+
+static int moxart_terminate_all(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+
+	dev_dbg(chan2dev(chan), "%s: mchan=%p\n", __func__, mchan);
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.ul &= ~(APB_DMA_ENABLE | APB_DMA_FIN_INT_EN | APB_DMA_ERR_INT_EN);
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return 0;
+}
+
+static int moxart_slave_config(struct dma_chan *chan,
+			       struct dma_slave_config *cfg)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+	unsigned int data_width, data_inc;
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	memcpy(&mchan->cfg, cfg, sizeof(mchan->cfg));
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.bits.burst = APB_DMAB_BURST_MODE;
+
+	switch (mchan->cfg.src_addr_width) {
+	case DMA_SLAVE_BUSWIDTH_1_BYTE:
+		data_width = APB_DMAB_DATA_WIDTH_1;
+		data_inc = APB_DMAB_DEST_INC_1_4;
+		break;
+	case DMA_SLAVE_BUSWIDTH_2_BYTES:
+		data_width = APB_DMAB_DATA_WIDTH_2;
+		data_inc = APB_DMAB_DEST_INC_2_8;
+		break;
+	default:
+		data_width = APB_DMAB_DATA_WIDTH_4;
+		data_inc = APB_DMAB_DEST_INC_4_16;
+		break;
+	}
+
+	if (mchan->cfg.direction == DMA_MEM_TO_DEV) {
+		mcfg.bits.data_width = data_width;
+		mcfg.bits.dest_sel = APB_DMAB_DEST_APB;
+		mcfg.bits.dest_inc = APB_DMAB_DEST_INC_0;
+		mcfg.bits.source_sel = APB_DMAB_SOURCE_AHB;
+		mcfg.bits.source_inc = data_inc;
+
+		mcfg.bits.dest_req_no = mchan->cfg.slave_id;
+		mcfg.bits.source_req_no = 0;
+	} else {
+		mcfg.bits.data_width = data_width;
+		mcfg.bits.dest_sel = APB_DMAB_SOURCE_AHB;
+		mcfg.bits.dest_inc = data_inc;
+		mcfg.bits.source_sel = APB_DMAB_DEST_APB;
+		mcfg.bits.source_inc = APB_DMAB_DEST_INC_0;
+
+		mcfg.bits.dest_req_no = 0;
+		mcfg.bits.source_req_no = mchan->cfg.slave_id;
+	}
+
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return 0;
+}
+
+static int moxart_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
+			  unsigned long arg)
+{
+	int ret = 0;
+	struct dma_slave_config *config;
+
+	switch (cmd) {
+	case DMA_TERMINATE_ALL:
+		moxart_terminate_all(chan);
+		break;
+	case DMA_SLAVE_CONFIG:
+		config = (struct dma_slave_config *)arg;
+		ret = moxart_slave_config(chan, config);
+		break;
+	default:
+		ret = -ENOSYS;
+	}
+
+	return ret;
+}
+
+static dma_cookie_t moxart_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(tx->chan);
+	dma_cookie_t cookie;
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+
+	mchan->callback = tx->callback;
+	mchan->callback_param = tx->callback_param;
+	mchan->error_flag = 0;
+
+	dev_dbg(chan2dev(tx->chan), "%s: mchan=%p mchan->ch_num=%d mchan->reg=%p\n",
+		__func__, mchan, mchan->ch_num, mchan->reg);
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	cookie = dma_cookie_assign(tx);
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.ul |= (APB_DMA_FIN_INT_EN | APB_DMA_ERR_INT_EN);
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return cookie;
+}
+
+static struct dma_async_tx_descriptor
+*moxart_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
+		      unsigned int sg_len,
+		      enum dma_transfer_direction direction,
+		      unsigned long tx_flags, void *context)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	unsigned long flags;
+	union moxart_dma_reg_cfg mcfg;
+	unsigned int size, adr_width;
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	if (direction == DMA_MEM_TO_DEV) {
+		writel(virt_to_phys((void *)sg_dma_address(&sgl[0])),
+		       &mchan->reg->source_addr);
+		writel(mchan->cfg.dst_addr, &mchan->reg->dest_addr);
+		adr_width = mchan->cfg.src_addr_width;
+	} else {
+		writel(mchan->cfg.src_addr, &mchan->reg->source_addr);
+		writel(virt_to_phys((void *)sg_dma_address(&sgl[0])),
+		       &mchan->reg->dest_addr);
+		adr_width = mchan->cfg.dst_addr_width;
+	}
+
+	size = sgl->length >> adr_width;
+
+	/*
+	 * size is 4 on 64 bytes copied, i.e. once cycle copies 16 bytes
+	 * ( when data_width == APB_DMAB_DATA_WIDTH_4 )
+	 */
+	writel(size, &mchan->reg->cycles);
+
+	dev_dbg(chan2dev(chan), "%s: set %d DMA cycles (sgl->length=%d adr_width=%d)\n",
+		__func__, size, sgl->length, adr_width);
+
+	dev_dbg(chan2dev(chan), "%s: mcfg.ul=%x read from &mchan->reg->cfg.ul=%x\n",
+		__func__, mcfg.ul, (unsigned int)&mchan->reg->cfg.ul);
+
+	dma_async_tx_descriptor_init(&mchan->tx_desc, chan);
+	mchan->tx_desc.tx_submit = moxart_tx_submit;
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return &mchan->tx_desc;
+}
+
+static struct platform_driver moxart_driver;
+
+bool moxart_filter_fn(struct dma_chan *chan, void *param)
+{
+	if (chan->device->dev->driver == &moxart_driver.driver) {
+		struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+		unsigned int ch_req = *(unsigned int *)param;
+		dev_dbg(chan2dev(chan), "%s: mchan=%p ch_req=%d mchan->ch_num=%d\n",
+			__func__, mchan, ch_req, mchan->ch_num);
+		return ch_req == mchan->ch_num;
+	} else {
+		dev_dbg(chan2dev(chan), "%s: device not registered to this DMA engine\n",
+			__func__);
+		return false;
+	}
+}
+EXPORT_SYMBOL(moxart_filter_fn);
+
+static int moxart_alloc_chan_resources(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	int i;
+	bool found = false;
+
+	for (i = 0; i < APB_DMA_MAX_CHANNEL; i++) {
+		if (i == mchan->ch_num
+			&& !mchan->allocated) {
+			dev_dbg(chan2dev(chan), "%s: allocating channel #%d\n",
+				__func__, mchan->ch_num);
+			mchan->allocated = true;
+			found = true;
+			break;
+		}
+	}
+
+	if (!found)
+		return -ENODEV;
+
+	return 0;
+}
+
+static void moxart_free_chan_resources(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+
+	mchan->allocated = false;
+
+	dev_dbg(chan2dev(chan), "%s: freeing channel #%u\n",
+		__func__, mchan->ch_num);
+}
+
+static void moxart_issue_pending(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+
+	dev_dbg(chan2dev(chan), "%s: mchan=%p\n", __func__, mchan);
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.ul |= APB_DMA_ENABLE;
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+}
+
+static enum dma_status moxart_tx_status(struct dma_chan *chan,
+					dma_cookie_t cookie,
+					struct dma_tx_state *txstate)
+{
+	enum dma_status ret;
+
+	ret = dma_cookie_status(chan, cookie, txstate);
+	if (ret == DMA_SUCCESS || !txstate)
+		return ret;
+
+	return ret;
+}
+
+static void moxart_dma_init(struct dma_device *dma, struct device *dev)
+{
+	dma->device_prep_slave_sg		= moxart_prep_slave_sg;
+	dma->device_alloc_chan_resources	= moxart_alloc_chan_resources;
+	dma->device_free_chan_resources		= moxart_free_chan_resources;
+	dma->device_issue_pending		= moxart_issue_pending;
+	dma->device_tx_status			= moxart_tx_status;
+	dma->device_control			= moxart_control;
+	dma->dev				= dev;
+
+	INIT_LIST_HEAD(&dma->channels);
+}
+
+static irqreturn_t moxart_dma_interrupt(int irq, void *devid)
+{
+	struct device *dev = devid;
+	struct moxart_dma_chan *mchan = &mdc->slave_chans[0];
+	unsigned int i;
+	union moxart_dma_reg_cfg mcfg;
+
+	dev_dbg(dev, "%s\n", __func__);
+
+	for (i = 0; i < APB_DMA_MAX_CHANNEL; i++, mchan++) {
+		if (mchan->allocated) {
+			mcfg.ul = readl(&mchan->reg->cfg.ul);
+			if (mcfg.ul & APB_DMA_FIN_INT_STS) {
+				mcfg.ul &= ~APB_DMA_FIN_INT_STS;
+				dma_cookie_complete(&mchan->tx_desc);
+			}
+			if (mcfg.ul & APB_DMA_ERR_INT_STS) {
+				mcfg.ul &= ~APB_DMA_ERR_INT_STS;
+				mchan->error_flag = 1;
+			}
+			if (mchan->callback) {
+				dev_dbg(dev, "%s: call callback for mchan=%p\n",
+					__func__, mchan);
+				mchan->callback(mchan->callback_param);
+			}
+			mchan->error_flag = 0;
+			writel(mcfg.ul, &mchan->reg->cfg.ul);
+		}
+	}
+
+	return IRQ_HANDLED;
+}
+
+static struct irqaction moxart_dma_irq = {
+	.name       = "moxart-dma-engine",
+	.flags      = IRQF_DISABLED,
+	.handler    = moxart_dma_interrupt,
+};
+
+static int moxart_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct resource res_dma;
+	static void __iomem *dma_base_addr;
+	int ret, i;
+	unsigned int irq;
+	struct moxart_dma_chan *mchan;
+
+	mdc = devm_kzalloc(dev, sizeof(*mdc), GFP_KERNEL);
+	if (!mdc) {
+		dev_err(dev, "can't allocate DMA container\n");
+		return -ENOMEM;
+	}
+
+	ret = of_address_to_resource(node, 0, &res_dma);
+	if (ret) {
+		dev_err(dev, "can't get DMA base resource\n");
+		return ret;
+	}
+
+	irq = irq_of_parse_and_map(node, 0);
+
+	dma_base_addr = devm_ioremap_resource(dev, &res_dma);
+	if (IS_ERR(dma_base_addr)) {
+		dev_err(dev, "devm_ioremap_resource failed\n");
+		return PTR_ERR(dma_base_addr);
+	}
+
+	mdc->ctlr = pdev->id;
+
+	dma_cap_zero(mdc->dma_slave.cap_mask);
+	dma_cap_set(DMA_SLAVE, mdc->dma_slave.cap_mask);
+
+	moxart_dma_init(&mdc->dma_slave, dev);
+
+	mchan = &mdc->slave_chans[0];
+	for (i = 0; i < APB_DMA_MAX_CHANNEL; i++, mchan++) {
+		mchan->ch_num = i;
+		mchan->reg = (struct moxart_dma_reg *)(dma_base_addr + 0x80
+			     + i * sizeof(struct moxart_dma_reg));
+		mchan->callback = NULL;
+		mchan->allocated = 0;
+		mchan->callback_param = NULL;
+
+		dma_cookie_init(&mchan->chan);
+		mchan->chan.device = &mdc->dma_slave;
+		list_add_tail(&mchan->chan.device_node,
+			      &mdc->dma_slave.channels);
+
+		dev_dbg(dev, "%s: mchans[%d]: mchan->ch_num=%d mchan->reg=%p\n",
+			__func__, i, mchan->ch_num, mchan->reg);
+	}
+
+	ret = dma_async_device_register(&mdc->dma_slave);
+	platform_set_drvdata(pdev, mdc);
+
+	moxart_dma_irq.dev_id = dev;
+	setup_irq(irq, &moxart_dma_irq);
+
+	dev_dbg(dev, "%s: IRQ=%d\n", __func__, irq);
+
+	return ret;
+}
+
+static int moxart_remove(struct platform_device *pdev)
+{
+	struct moxart_dma_container *m = dev_get_drvdata(&pdev->dev);
+	dma_async_device_unregister(&m->dma_slave);
+	return 0;
+}
+
+static const struct of_device_id moxart_dma_match[] = {
+	{ .compatible = "moxa,moxart-dma" },
+	{ }
+};
+
+static struct platform_driver moxart_driver = {
+	.probe	= moxart_probe,
+	.remove	= moxart_remove,
+	.driver = {
+		.name		= "moxart-dma-engine",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_dma_match,
+	},
+};
+
+static int moxart_init(void)
+{
+	return platform_driver_register(&moxart_driver);
+}
+subsys_initcall(moxart_init);
+
+static void __exit moxart_exit(void)
+{
+	platform_driver_unregister(&moxart_driver);
+}
+module_exit(moxart_exit);
+
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
+MODULE_DESCRIPTION("MOXART DMA engine driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/dma/moxart-dma.h b/drivers/dma/moxart-dma.h
new file mode 100644
index 0000000..358c006
--- /dev/null
+++ b/drivers/dma/moxart-dma.h
@@ -0,0 +1,188 @@
+/*
+ * MOXA ART SoCs DMA Engine support.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __DMA_MOXART_H
+#define __DMA_MOXART_H
+
+#define APB_DMA_MAX_CHANNEL			4
+
+union moxart_dma_reg_cfg {
+
+#define APB_DMA_ENABLE				(1<<0)
+#define APB_DMA_FIN_INT_STS			(1<<1)
+#define APB_DMA_FIN_INT_EN			(1<<2)
+#define APB_DMA_BURST_MODE			(1<<3)
+#define APB_DMA_ERR_INT_STS			(1<<4)
+#define APB_DMA_ERR_INT_EN			(1<<5)
+#define APB_DMA_SOURCE_AHB			(1<<6)
+#define APB_DMA_SOURCE_APB			0
+#define APB_DMA_DEST_AHB			(1<<7)
+#define APB_DMA_DEST_APB			0
+#define APB_DMA_SOURCE_INC_0			0
+#define APB_DMA_SOURCE_INC_1_4			(1<<8)
+#define APB_DMA_SOURCE_INC_2_8			(2<<8)
+#define APB_DMA_SOURCE_INC_4_16			(3<<8)
+#define APB_DMA_SOURCE_DEC_1_4			(5<<8)
+#define APB_DMA_SOURCE_DEC_2_8			(6<<8)
+#define APB_DMA_SOURCE_DEC_4_16			(7<<8)
+#define APB_DMA_SOURCE_INC_MASK			(7<<8)
+#define APB_DMA_DEST_INC_0			0
+#define APB_DMA_DEST_INC_1_4			(1<<12)
+#define APB_DMA_DEST_INC_2_8			(2<<12)
+#define APB_DMA_DEST_INC_4_16			(3<<12)
+#define APB_DMA_DEST_DEC_1_4			(5<<12)
+#define APB_DMA_DEST_DEC_2_8			(6<<12)
+#define APB_DMA_DEST_DEC_4_16			(7<<12)
+#define APB_DMA_DEST_INC_MASK			(7<<12)
+#define APB_DMA_DEST_REQ_NO_MASK		(15<<16)
+#define APB_DMA_DATA_WIDTH_MASK			(3<<20)
+#define APB_DMA_DATA_WIDTH_4			0
+#define APB_DMA_DATA_WIDTH_2			(1<<20)
+#define APB_DMA_DATA_WIDTH_1			(2<<20)
+#define APB_DMA_SOURCE_REQ_NO_MASK		(15<<24)
+	unsigned int ul;
+
+	struct {
+
+#define APB_DMAB_ENABLE				1
+		/* enable DMA */
+		unsigned int enable:1;
+
+#define APB_DMAB_FIN_INT_STS			1
+		/* finished interrupt status */
+		unsigned int fin_int_sts:1;
+
+#define APB_DMAB_FIN_INT_EN			1
+		/* finished interrupt enable */
+		unsigned int fin_int_en:1;
+
+#define APB_DMAB_BURST_MODE			1
+		/* burst mode */
+		unsigned int burst:1;
+
+#define APB_DMAB_ERR_INT_STS			1
+		/* error interrupt status */
+		unsigned int err_int_sts:1;
+
+#define APB_DMAB_ERR_INT_EN			1
+		/* error interrupt enable */
+		unsigned int err_int_en:1;
+
+#define APB_DMAB_SOURCE_AHB			1
+#define APB_DMAB_SOURCE_APB			0
+		/* 0:APB (device), 1:AHB (RAM) */
+		unsigned int source_sel:1;
+
+#define APB_DMAB_DEST_AHB			1
+#define APB_DMAB_DEST_APB			0
+		/* 0:APB, 1:AHB */
+		unsigned int dest_sel:1;
+
+#define APB_DMAB_SOURCE_INC_0			0
+#define APB_DMAB_SOURCE_INC_1_4			1
+#define APB_DMAB_SOURCE_INC_2_8			2
+#define APB_DMAB_SOURCE_INC_4_16		3
+#define APB_DMAB_SOURCE_DEC_1_4			5
+#define APB_DMAB_SOURCE_DEC_2_8			6
+#define APB_DMAB_SOURCE_DEC_4_16		7
+#define APB_DMAB_SOURCE_INC_MASK		7
+		/*
+		 * 000: no increment
+		 * 001: +1 (busrt=0), +4  (burst=1)
+		 * 010: +2 (burst=0), +8  (burst=1)
+		 * 011: +4 (burst=0), +16 (burst=1)
+		 * 101: -1 (burst=0), -4  (burst=1)
+		 * 110: -2 (burst=0), -8  (burst=1)
+		 * 111: -4 (burst=0), -16 (burst=1)
+		 */
+		unsigned int source_inc:3;
+
+		unsigned int reserved1:1;
+
+#define APB_DMAB_DEST_INC_0			0
+#define APB_DMAB_DEST_INC_1_4			1
+#define APB_DMAB_DEST_INC_2_8			2
+#define APB_DMAB_DEST_INC_4_16			3
+#define APB_DMAB_DEST_DEC_1_4			5
+#define APB_DMAB_DEST_DEC_2_8			6
+#define APB_DMAB_DEST_DEC_4_16			7
+#define APB_DMAB_DEST_INC_MASK			7
+		/*
+		 * 000: no increment
+		 * 001: +1 (busrt=0), +4  (burst=1)
+		 * 010: +2 (burst=0), +8  (burst=1)
+		 * 011: +4 (burst=0), +16 (burst=1)
+		 * 101: -1 (burst=0), -4  (burst=1)
+		 * 110: -2 (burst=0), -8  (burst=1)
+		 * 111: -4 (burst=0), -16 (burst=1)
+		*/
+		unsigned int dest_inc:3;
+
+		unsigned int reserved2:1;
+
+#define APB_DMAB_DEST_REQ_NO_MASK		15
+		/*
+		 * request signal select of destination
+		 * address for DMA hardware handshake
+		 *
+		 * the request line number is a property of
+		 * the DMA controller itself, e.g. MMC must
+		 * always request channels where
+		 * dma_slave_config->slave_id == 5
+		 *
+		 * 0:	 no request / grant signal
+		 * 1-15: request / grant signal
+		 */
+		unsigned int dest_req_no:4;
+
+#define APB_DMAB_DATA_WIDTH_MASK		3
+#define APB_DMAB_DATA_WIDTH_4			0
+#define APB_DMAB_DATA_WIDTH_2			1
+#define APB_DMAB_DATA_WIDTH_1			2
+		/*
+		 * data width of transfer
+		 * 00: word
+		 * 01: half
+		 * 10: byte
+		 */
+		unsigned int data_width:2;
+
+		unsigned int reserved3:2;
+
+#define APB_DMAB_SOURCE_REQ_NO_MASK		15
+		/*
+		 * request signal select of source
+		 * address for DMA hardware handshake
+		 *
+		 * the request line number is a property of
+		 * the DMA controller itself, e.g. MMC must
+		 * always request channels where
+		 * dma_slave_config->slave_id == 5
+		 *
+		 * 0:	 no request / grant signal
+		 * 1-15: request / grant signal
+		 */
+		unsigned int source_req_no:4;
+
+		unsigned int reserved4:4;
+	} bits;
+};
+
+struct moxart_dma_reg {
+	unsigned int source_addr;
+	unsigned int dest_addr;
+#define APB_DMA_CYCLES_MASK			0x00ffffff
+	unsigned int cycles;	/* depend on burst mode */
+	union moxart_dma_reg_cfg cfg;
+};
+
+#endif
-- 
1.8.2.1



From pali.rohar at gmail.com  Wed Jul 10 08:59:03 2013
From: pali.rohar at gmail.com (=?UTF-8?q?Pali=20Roh=C3=A1r?=)
Date: Wed, 10 Jul 2013 14:59:03 +0200
Subject: [PATCH v2 0/2] arm: omap: RX-51: ARM errata 430973 workaround
In-Reply-To: <1362044548-5398-1-git-send-email-pali.rohar@gmail.com>
References: <1362044548-5398-1-git-send-email-pali.rohar@gmail.com>
Message-ID: <1373461145-9812-1-git-send-email-pali.rohar@gmail.com>

This patch adds RX-51 specific SMC support and sets IBE bit in ACTLR during
board init code for ARM errata 430973 workaround.

This is second version of patch which simplifing API and moving all board
functions to one file board-rx51.c. Wrapper around smc #1 instruction is in
omap-smc.S file because some other board may use it too.

Pali Roh?r (2):
  ARM: OMAP: Add secure function omap_smc3() which calling instruction
    smc #1
  RX-51: ARM errata 430973 workaround

 arch/arm/mach-omap2/board-rx51.c  |   78 +++++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/omap-secure.h |    1 +
 arch/arm/mach-omap2/omap-smc.S    |   22 ++++++++++-
 3 files changed, 100 insertions(+), 1 deletion(-)

-- 
1.7.10.4



From pali.rohar at gmail.com  Wed Jul 10 08:59:04 2013
From: pali.rohar at gmail.com (=?UTF-8?q?Pali=20Roh=C3=A1r?=)
Date: Wed, 10 Jul 2013 14:59:04 +0200
Subject: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3() which
 calling instruction smc #1
In-Reply-To: <1373461145-9812-1-git-send-email-pali.rohar@gmail.com>
References: <1362044548-5398-1-git-send-email-pali.rohar@gmail.com>
 <1373461145-9812-1-git-send-email-pali.rohar@gmail.com>
Message-ID: <1373461145-9812-2-git-send-email-pali.rohar@gmail.com>

Other secure functions omap_smc1() and omap_smc2() calling instruction smc #0
but Nokia RX-51 board needs to call smc #1 for PPA access.

Signed-off-by: Ivaylo Dimitrov <freemangordon at abv.bg>
Signed-off-by: Pali Roh?r <pali.rohar at gmail.com>
---
 arch/arm/mach-omap2/omap-secure.h |    1 +
 arch/arm/mach-omap2/omap-smc.S    |   22 +++++++++++++++++++++-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 0e72917..c4586f4 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,7 @@
 extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
 				u32 arg1, u32 arg2, u32 arg3, u32 arg4);
 extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
 extern phys_addr_t omap_secure_ram_mempool_base(void);
 extern int omap_secure_ram_reserve_memblock(void);
 
diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
index f6441c1..5c02b8d 100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -1,9 +1,11 @@
 /*
- * OMAP44xx secure APIs file.
+ * OMAP34xx and OMAP44xx secure APIs file.
  *
  * Copyright (C) 2010 Texas Instruments, Inc.
  * Written by Santosh Shilimkar <santosh.shilimkar at ti.com>
  *
+ * Copyright (C) 2012 Ivaylo Dimitrov <freemangordon at abv.bg>
+ * Copyright (C) 2013 Pali Roh?r <pali.rohar at gmail.com>
  *
  * This program is free software,you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -54,6 +56,24 @@ ENTRY(omap_smc2)
 	ldmfd   sp!, {r4-r12, pc}
 ENDPROC(omap_smc2)
 
+/**
+ * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
+ * Low level common routine for secure HAL and PPA APIs via smc #1
+ * r0 - @service_id: Secure Service ID
+ * r1 - @process_id: Process ID
+ * r2 - @flag: Flag to indicate the criticality of operation
+ * r3 - @pargs: Physical address of parameter list
+ */
+ENTRY(omap_smc3)
+	stmfd	sp!, {r4-r12, lr}
+	mov	r12, r0		@ Copy the secure service ID
+	mov	r6, #0xff	@ Indicate new Task call
+	dsb
+	dmb
+	smc	#1		@ call PPA service
+	ldmfd	sp!, {r4-r12, pc}
+ENDPROC(omap_smc3)
+
 ENTRY(omap_modify_auxcoreboot0)
 	stmfd   sp!, {r1-r12, lr}
 	ldr	r12, =0x104
-- 
1.7.10.4



From pali.rohar at gmail.com  Wed Jul 10 08:59:05 2013
From: pali.rohar at gmail.com (=?UTF-8?q?Pali=20Roh=C3=A1r?=)
Date: Wed, 10 Jul 2013 14:59:05 +0200
Subject: [PATCH v2 2/2] RX-51: ARM errata 430973 workaround
In-Reply-To: <1373461145-9812-1-git-send-email-pali.rohar@gmail.com>
References: <1362044548-5398-1-git-send-email-pali.rohar@gmail.com>
 <1373461145-9812-1-git-send-email-pali.rohar@gmail.com>
Message-ID: <1373461145-9812-3-git-send-email-pali.rohar@gmail.com>

Closed and signed Nokia X-Loader bootloader stored in RX-51 nand does not set
IBE bit in ACTLR and starting kernel in non-secure mode. So direct write to
ACTLR by our kernel does not working and the code for ARM errata 430973 in
commit 7ce236fcd6fd45b0441a2d49acb2ceb2de2e8a47 that sets IBE bit is a noop.

In order to have workaround for ARM errata 430973 from non-secure world on
RX-51 we needs Secure Monitor Call to set IBE BIT in ACTLR.

This patch adds RX-51 specific SMC support and sets IBE bit in ACTLR during
board init code for ARM errata 430973 workaround.

ARM errata 430973 workaround is needed for thumb-2 ISA compiled userspace
binaries. Without this workaround thumb-2 binaries crashing. So with this
patch it is possible to recompile and run applications/binaries with thumb-2
ISA on RX-51.

Signed-off-by: Ivaylo Dimitrov <freemangordon at abv.bg>
Signed-off-by: Pali Roh?r <pali.rohar at gmail.com>
---
 arch/arm/mach-omap2/board-rx51.c |   78 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 78 insertions(+)

diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 03663c2..f234dee 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -2,6 +2,8 @@
  * Board support file for Nokia N900 (aka RX-51).
  *
  * Copyright (C) 2007, 2008 Nokia
+ * Copyright (C) 2012 Ivaylo Dimitrov <freemangordon at abv.bg>
+ * Copyright (C) 2013 Pali Roh?r <pali.rohar at gmail.com>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -21,6 +23,7 @@
 #include <linux/usb/musb.h>
 #include <linux/platform_data/spi-omap2-mcspi.h>
 
+#include <asm/cacheflush.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
@@ -31,7 +34,14 @@
 #include "mux.h"
 #include "gpmc.h"
 #include "pm.h"
+#include "soc.h"
 #include "sdram-nokia.h"
+#include "omap-secure.h"
+
+/* Secure PPA (Primary Protected Application) APIs */
+#define RX51_PPA_HWRNG			29
+#define RX51_PPA_L2_INVAL		40
+#define RX51_PPA_WRITE_ACR		42
 
 #define RX51_GPIO_SLEEP_IND 162
 
@@ -90,6 +100,66 @@ static struct omap_musb_board_data musb_board_data = {
 	.power			= 0,
 };
 
+/**
+ * rx51_secure_dispatcher: Routine to dispatch secure PPA API calls
+ * @idx: The PPA API index
+ * @process: Process ID
+ * @flag: The flag indicating criticality of operation
+ * @nargs: Number of valid arguments out of four.
+ * @arg1, arg2, arg3 args4: Parameters passed to secure API
+ *
+ * Return the non-zero error value on failure.
+ */
+static u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs,
+			   u32 arg1, u32 arg2, u32 arg3, u32 arg4)
+{
+	u32 ret;
+	u32 param[5];
+
+	param[0] = nargs+1; /* RX-51 needs number of arguments + 1 */
+	param[1] = arg1;
+	param[2] = arg2;
+	param[3] = arg3;
+	param[4] = arg4;
+
+	/*
+	 * Secure API needs physical address
+	 * pointer for the parameters
+	 */
+	local_irq_disable();
+	local_fiq_disable();
+	flush_cache_all();
+	outer_clean_range(__pa(param), __pa(param + 5));
+	ret = omap_smc3(idx, process, flag, __pa(param));
+	flush_cache_all();
+	local_fiq_enable();
+	local_irq_enable();
+
+	return ret;
+}
+
+/**
+ * rx51_secure_update_aux_cr: Routine to modify the contents of Auxiliary Control Register
+ *  @set_bits: bits to set in ACR
+ *  @clr_bits: bits to clear in ACR
+ *
+ * Return the non-zero error value on failure.
+*/
+static u32 rx51_secure_update_aux_cr(u32 set_bits, u32 clear_bits)
+{
+	u32 acr;
+
+	/* Read ACR */
+	asm volatile ("mrc p15, 0, %0, c1, c0, 1" : "=r" (acr));
+	acr &= ~clear_bits;
+	acr |= set_bits;
+
+	return rx51_secure_dispatcher(RX51_PPA_WRITE_ACR,
+				      0,
+				      FLAG_START_CRITICAL,
+				      1, acr, 0, 0, 0);
+}
+
 static void __init rx51_init(void)
 {
 	struct omap_sdrc_params *sdrc_params;
@@ -105,6 +175,14 @@ static void __init rx51_init(void)
 	rx51_peripherals_init();
 	rx51_camera_init();
 
+	if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
+#ifdef CONFIG_ARM_ERRATA_430973
+		pr_info("RX-51: Enabling ARM errata 430973 workaround\n");
+		/* set IBE to 1 */
+		rx51_secure_update_aux_cr(BIT(6), 0);
+#endif
+	}
+
 	/* 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);
-- 
1.7.10.4



From fabio.estevam at freescale.com  Wed Jul 10 09:10:13 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Wed, 10 Jul 2013 10:10:13 -0300
Subject: [PATCH v2 1/2] ARM: imx: system: Do not declare imx_init_l2cache() as
 static
Message-ID: <1373461814-8844-1-git-send-email-fabio.estevam@freescale.com>

commit 879ec1cee (ARM: imx: let L2 initialization be a common function) breaks 
the build when CONFIG_CACHE_L2X0=y:

arch/arm/mach-imx/system.c:101:20: error: static declaration of 'imx_init_l2cache' follows non-static declaration
In file included from arch/arm/mach-imx/system.c:32:0:
arch/arm/mach-imx/common.h:165:13: note: previous declaration of 'imx_init_l2cache' was here
arch/arm/mach-imx/system.c:101:20: warning: 'imx_init_l2cache' defined but not used [-Wunused-function]

imx_init_l2cache() is a common function now, so it cannot be declared as static 
anymore.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- Newly introduced in this series

 arch/arm/mach-imx/system.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/system.c b/arch/arm/mach-imx/system.c
index e5592ca..64ff37e 100644
--- a/arch/arm/mach-imx/system.c
+++ b/arch/arm/mach-imx/system.c
@@ -98,7 +98,7 @@ void __init mxc_arch_reset_init_dt(void)
 }
 
 #ifdef CONFIG_CACHE_L2X0
-static void __init imx_init_l2cache(void)
+void __init imx_init_l2cache(void)
 {
 	void __iomem *l2x0_base;
 	struct device_node *np;
-- 
1.8.1.2




From fabio.estevam at freescale.com  Wed Jul 10 09:10:14 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Wed, 10 Jul 2013 10:10:14 -0300
Subject: [PATCH v2 2/2] ARM: imx: Select MIGHT_HAVE_CACHE_L2X0
In-Reply-To: <1373461814-8844-1-git-send-email-fabio.estevam@freescale.com>
References: <1373461814-8844-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <1373461814-8844-2-git-send-email-fabio.estevam@freescale.com>

Select MIGHT_HAVE_CACHE_L2X0 for mx31/35/51/53/6q/6sl/vf610

By selecting MIGHT_HAVE_CACHE_L2X0, the user still has the possibility to 
disable CACHE_L2X0 selection via menuconfig.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- Use MIGHT_HAVE_CACHE_L2X0 instead of CACHE_L2X0, to allow users to still
disable L2 cache via menuconfig if they want to
- Also select L2 cache for vf610

 arch/arm/mach-imx/Kconfig | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index f546560..cc6961d 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -125,6 +125,7 @@ config SOC_IMX31
 	select COMMON_CLK
 	select CPU_V6
 	select IMX_HAVE_PLATFORM_MXC_RNGA
+	select MIGHT_HAVE_CACHE_L2X0
 	select MXC_AVIC
 	select SMP_ON_UP if SMP
 
@@ -134,6 +135,7 @@ config SOC_IMX35
 	select COMMON_CLK
 	select CPU_V6K
 	select HAVE_EPIT
+	select MIGHT_HAVE_CACHE_L2X0
 	select MXC_AVIC
 	select SMP_ON_UP if SMP
 
@@ -144,6 +146,7 @@ config SOC_IMX5
 	select ARCH_MXC_IOMUX_V3
 	select COMMON_CLK
 	select CPU_V7
+	select MIGHT_HAVE_CACHE_L2X0
 	select MXC_TZIC
 
 config	SOC_IMX51
@@ -799,6 +802,7 @@ config SOC_IMX6Q
 	select HAVE_IMX_MMDC
 	select HAVE_IMX_SRC
 	select HAVE_SMP
+	select MIGHT_HAVE_CACHE_L2X0
 	select MFD_SYSCON
 	select PINCTRL
 	select PINCTRL_IMX6Q
@@ -820,6 +824,7 @@ config SOC_IMX6SL
 	select HAVE_IMX_GPC
 	select HAVE_IMX_MMDC
 	select HAVE_IMX_SRC
+	select MIGHT_HAVE_CACHE_L2X0
 	select MFD_SYSCON
 	select PINCTRL
 	select PINCTRL_IMX6SL
@@ -835,6 +840,7 @@ config SOC_VF610
 	select CPU_V7
 	select ARM_GIC
 	select CLKSRC_OF
+	select MIGHT_HAVE_CACHE_L2X0
 	select PINCTRL
 	select PINCTRL_VF610
 	select VF_PIT_TIMER
-- 
1.8.1.2




From rogerq at ti.com  Wed Jul 10 09:14:21 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 10 Jul 2013 16:14:21 +0300
Subject: [PATCH 0/4] pinctrl single support for SoC specific features
In-Reply-To: <20130710122417.GT5523@atomide.com>
References: <20130607203936.16513.57494.stgit@localhost>
 <51DD4F30.7050603@ti.com> <20130710122417.GT5523@atomide.com>
Message-ID: <51DD5E2D.50504@ti.com>

On 07/10/2013 03:24 PM, Tony Lindgren wrote:
> * Roger Quadros <rogerq at ti.com> [130710 05:16]:
>> Hi Tony,
>>
>> On 06/07/2013 11:50 PM, Tony Lindgren wrote:
>>> Hi all,
>>>
>>> Here are few patches to add support for SoC specific features
>>> to pinctrl-single. This is needed at least for omaps to support
>>> IO chain wake-up events from deeper idle states.
>>>
>>> With this patch series, device drivers can request named pinctrl
>>> states like active and idle from the PM runtime suspend and resume
>>> calls to set the wake enable bits for selected pins. Further
>>> the device driver can toggle the wake-up feature as needed based on
>>> the device_may_wakeup() state set by the standard sysfs
>>> power/wakeup entry.
>>>
>>> This is implemented in a separate pinctrl-single-omap driver that
>>> works together with pinctrl-single. This way the SoC specific
>>> are separated from the common pinctrl-single, and allows a relatively
>>> easy way to implement SoC specific things like wake-up events,
>>> pin interrupts, and GPIO.
>>
>> What's the status of this? Would be nice to get it in 3.12. I'm basing
>> the OMAP USB host wakeup support on this.
> 
> How about I'll push an immutable branch against v3.11-rc1 when it's
> tagged and send a pull request to Linus W for the first three patches?
> 
> That way we can base other branches on this if needed.

Looks good to me. Thanks.

cheers,
-roger


From horms at verge.net.au  Wed Jul 10 09:20:54 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 22:20:54 +0900
Subject: [PATCH 1/3] ARM: shmobile: fix compile error when
 CONFIG_THUMB2_KERNEL=y
In-Reply-To: <1373421397-1786-2-git-send-email-koba@kmckk.co.jp>
References: <1373421397-1786-1-git-send-email-koba@kmckk.co.jp>
 <1373421397-1786-2-git-send-email-koba@kmckk.co.jp>
Message-ID: <20130710132054.GB13716@verge.net.au>

On Wed, Jul 10, 2013 at 10:56:35AM +0900, Tetsuyuki Kobayashi wrote:
> On KZM-A9-GT board (SMP), when CONFIG_THUMB2_KERNEL=y it fails to compile
>  
>   AS      arch/arm/mach-shmobile/headsmp-scu.o
> /proj/koba/kernel/arm-soc/arch/arm/mach-shmobile/headsmp-scu.S: Assembler messages:
> /proj/koba/kernel/arm-soc/arch/arm/mach-shmobile/headsmp-scu.S:41: Error: shift must be constant -- `bic r2,r2,r3,lsl r1'
> make[2]: *** [arch/arm/mach-shmobile/headsmp-scu.o] Error 1
> make[1]: *** [arch/arm/mach-shmobile] Error 2
> make: *** [sub-make] Error 2
> 
> Instruction `bic r2,r2,r3,lsl r1' is not supported in thumb mode. This patch split it into 2 instructions.
> 
> Signed-off-by: Tetsuyuki Kobayashi <koba at kmckk.co.jp>
> ---
>  arch/arm/mach-shmobile/headsmp-scu.S |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Thanks, I have queued this up with Magnus's ack in the thumb-fixes
branch of my renesas tree on kernel.org. It should be
included in the renesas-next-20130710v2 tag.


From horms at verge.net.au  Wed Jul 10 09:20:59 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 22:20:59 +0900
Subject: [PATCH 2/3] ARM: shmobile: Force ARM mode to compile reset
 vector for secondary CPUs
In-Reply-To: <1373421397-1786-3-git-send-email-koba@kmckk.co.jp>
References: <1373421397-1786-1-git-send-email-koba@kmckk.co.jp>
 <1373421397-1786-3-git-send-email-koba@kmckk.co.jp>
Message-ID: <20130710132059.GC13716@verge.net.au>

On Wed, Jul 10, 2013 at 10:56:36AM +0900, Tetsuyuki Kobayashi wrote:
> Instructions start from boot vector must be ARM mode.
> This patch specify ARM mode explicitly and use 'bx' instruction to be
> able to change to Thumb mode.
> 
> Signed-off-by: Tetsuyuki Kobayashi <koba at kmckk.co.jp>
> ---
>  arch/arm/mach-shmobile/headsmp.S |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)

Thanks, I have queued this up with Magnus's ack in the thumb-fixes
branch of my renesas tree on kernel.org. It should be
included in the renesas-next-20130710v2 tag.


From horms at verge.net.au  Wed Jul 10 09:21:04 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Jul 2013 22:21:04 +0900
Subject: [PATCH 3/3] ARM: shmobile: Insert align directives before 4
 bytes data
In-Reply-To: <1373421397-1786-4-git-send-email-koba@kmckk.co.jp>
References: <1373421397-1786-1-git-send-email-koba@kmckk.co.jp>
 <1373421397-1786-4-git-send-email-koba@kmckk.co.jp>
Message-ID: <20130710132104.GD13716@verge.net.au>

On Wed, Jul 10, 2013 at 10:56:37AM +0900, Tetsuyuki Kobayashi wrote:
> In thumb2 mode instructions are not align to 4 byte. This patch insert
> align directives before putting 4 byte data.
> 
> Signed-off-by: Tetsuyuki Kobayashi <koba at kmckk.co.jp>
> ---
>  arch/arm/mach-shmobile/headsmp-scu.S  |    1 +
>  arch/arm/mach-shmobile/headsmp.S      |    1 +
>  arch/arm/mach-shmobile/sleep-sh7372.S |    2 ++
>  3 files changed, 4 insertions(+)

Thanks, I have queued this up with Magnus's ack in the thumb-fixes
branch of my renesas tree on kernel.org. It should be
included in the renesas-next-20130710v2 tag.


From andrew at lunn.ch  Wed Jul 10 09:41:19 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 10 Jul 2013 15:41:19 +0200
Subject: NSA310 + DT
In-Reply-To: <2544f179ed4349545a25aa60d52a664a@harsszegi.com>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <20130709202143.GD26223@lunn.ch>
 <2544f179ed4349545a25aa60d52a664a@harsszegi.com>
Message-ID: <20130710134119.GA30885@lunn.ch>

Hi Tibor

I created a DTS file based on the tree you gave me.

Please could you try

https://github.com/lunn/linux.git branch v3.10-nsa310-tdc

and the DTS file arch/arm/boot/dts/kirkwood-nsa310-tdc.dts

Please use 

make kirkwood_defconfig
make

and it should have the lm85 built in.

The two different NSA310 are mostly similar, just a few different gpio
LEDs and buttons, so i might actually refactor the two dts files with
what is shared. But lets get your box working first.

     Andrew


From jonas.jensen at gmail.com  Wed Jul 10 09:49:18 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 10 Jul 2013 15:49:18 +0200
Subject: [PATCH] gpio: Add MOXA ART GPIO driver
Message-ID: <1373464158-27881-1-git-send-email-jonas.jensen@gmail.com>

Add GPIO driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130703

 drivers/gpio/Kconfig       |   7 ++
 drivers/gpio/Makefile      |   1 +
 drivers/gpio/gpio-moxart.c | 168 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 176 insertions(+)
 create mode 100644 drivers/gpio/gpio-moxart.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b2450ba..521fd97 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -714,6 +714,13 @@ config GPIO_MSIC
 	  Enable support for GPIO on intel MSIC controllers found in
 	  intel MID devices
 
+config GPIO_MOXART
+	bool "MOXART GPIO support"
+	depends on ARCH_MOXART
+	help
+	  Select this option to enable GPIO driver for
+	  MOXA ART SoC devices.
+
 comment "USB GPIO expanders:"
 
 config GPIO_VIPERBOARD
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index ef3e983..44b0de4 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_GPIO_MC9S08DZ60)	+= gpio-mc9s08dz60.o
 obj-$(CONFIG_GPIO_MCP23S08)	+= gpio-mcp23s08.o
 obj-$(CONFIG_GPIO_ML_IOH)	+= gpio-ml-ioh.o
 obj-$(CONFIG_GPIO_MM_LANTIQ)	+= gpio-mm-lantiq.o
+obj-$(CONFIG_GPIO_MOXART)	+= gpio-moxart.o
 obj-$(CONFIG_GPIO_MPC5200)	+= gpio-mpc5200.o
 obj-$(CONFIG_GPIO_MPC8XXX)	+= gpio-mpc8xxx.o
 obj-$(CONFIG_GPIO_MSIC)		+= gpio-msic.o
diff --git a/drivers/gpio/gpio-moxart.c b/drivers/gpio/gpio-moxart.c
new file mode 100644
index 0000000..21d26c1
--- /dev/null
+++ b/drivers/gpio/gpio-moxart.c
@@ -0,0 +1,168 @@
+/*
+ * MOXA ART SoCs GPIO driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/io.h>
+#include <linux/gpio.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/delay.h>
+#include <linux/timer.h>
+
+#define SW_READY_GPIO		(27)
+#define SW_RESET_GPIO		(25)
+
+#define GPIO_DATA_OUT		0x00
+#define GPIO_DATA_IN		0x04
+#define GPIO_PIN_DIRECTION	0x08
+
+static void __iomem *moxart_pincontrol_base;
+static void __iomem *moxart_gpio_base;
+
+void moxart_gpio_enable(u32 gpio)
+{
+	writel(readl(moxart_pincontrol_base) | gpio, moxart_pincontrol_base);
+}
+
+void moxart_gpio_disable(u32 gpio)
+{
+	writel(readl(moxart_pincontrol_base) & ~gpio, moxart_pincontrol_base);
+}
+
+static int moxart_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+	moxart_gpio_enable(1 << offset);
+	return pinctrl_request_gpio(offset);
+}
+
+static void moxart_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+	pinctrl_free_gpio(offset);
+	moxart_gpio_disable(1 << offset);
+}
+
+static int moxart_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+	void __iomem *ioaddr = moxart_gpio_base + GPIO_PIN_DIRECTION;
+
+	writel(readl(ioaddr) & ~(1 << offset), ioaddr);
+	return 0;
+}
+
+static int moxart_gpio_direction_output(struct gpio_chip *chip,
+					unsigned offset, int value)
+{
+	void __iomem *ioaddr = moxart_gpio_base + GPIO_PIN_DIRECTION;
+
+	writel(readl(ioaddr) | (1 << offset), ioaddr);
+	return 0;
+}
+
+static void moxart_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+	void __iomem *ioaddr = moxart_gpio_base + GPIO_DATA_OUT;
+	u32 reg = readl(ioaddr);
+
+	(value) ?	writel(reg | (1 << offset), ioaddr) :
+			writel(reg & ~(1 << offset), ioaddr);
+}
+
+static int moxart_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+	u32 ret = readl(moxart_gpio_base + GPIO_PIN_DIRECTION);
+
+	if (ret & (1 << offset))
+		ret = readl(moxart_gpio_base + GPIO_DATA_OUT) & (1 << offset);
+	else
+		ret = readl(moxart_gpio_base + GPIO_DATA_IN) & (1 << offset);
+
+	return ret;
+}
+
+static struct gpio_chip moxart_gpio_chip = {
+	.label			= "moxart-gpio",
+	.request		= moxart_gpio_request,
+	.free			= moxart_gpio_free,
+	.direction_input	= moxart_gpio_direction_input,
+	.direction_output	= moxart_gpio_direction_output,
+	.set			= moxart_gpio_set,
+	.get			= moxart_gpio_get,
+	.base			= 0,
+	.ngpio			= 32,
+	.can_sleep		= 0,
+};
+
+static int moxart_gpio_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct resource *res;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	moxart_gpio_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_gpio_base)) {
+		dev_err(dev, "%s: devm_ioremap_resource res_gpio failed\n",
+			dev->of_node->full_name);
+		return PTR_ERR(moxart_gpio_base);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	moxart_pincontrol_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_pincontrol_base)) {
+		dev_err(dev, "%s: devm_ioremap_resource res_pmu failed\n",
+			dev->of_node->full_name);
+		return PTR_ERR(moxart_pincontrol_base);
+	}
+
+	gpiochip_add(&moxart_gpio_chip);
+
+	moxart_gpio_enable(SW_READY_GPIO | SW_RESET_GPIO);
+
+	moxart_gpio_direction_input(&moxart_gpio_chip, SW_RESET_GPIO);
+
+	/*
+	 * SW_READY_GPIO=0 ready LED on
+	 * SW_READY_GPIO=1 ready LED off
+	 */
+	moxart_gpio_direction_output(&moxart_gpio_chip, SW_READY_GPIO, 0);
+	moxart_gpio_set(&moxart_gpio_chip, SW_READY_GPIO, 0);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_gpio_match[] = {
+	{ .compatible = "moxa,moxart-gpio" },
+	{ }
+};
+
+static struct platform_driver moxart_gpio_driver = {
+	.driver	= {
+		.name		= "moxart-gpio",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_gpio_match,
+	},
+	.probe	= moxart_gpio_probe,
+};
+
+static int __init moxart_gpio_init(void)
+{
+	return platform_driver_register(&moxart_gpio_driver);
+}
+
+postcore_initcall(moxart_gpio_init);
+
+MODULE_DESCRIPTION("MOXART GPIO chip driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From festevam at gmail.com  Wed Jul 10 09:49:44 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 10 Jul 2013 10:49:44 -0300
Subject: [PATCH V2 01/12] spi/mxs: Always set LOCK_CS
In-Reply-To: <201304030118.42976.marex@denx.de>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
 <201304030118.42976.marex@denx.de>
Message-ID: <CAOMZO5AEU3D3o-8fKLQJvsRSwBMNn0jfwZFC6R93TKaUpxffSw@mail.gmail.com>

On Tue, Apr 2, 2013 at 8:18 PM, Marek Vasut <marex at denx.de> wrote:
> Dear Trent Piepho,
>
>> There are two bits which control the CS line in the CTRL0 register:
>> LOCK_CS and IGNORE_CRC.  The latter would be better named DEASSERT_CS
>> in SPI mode.
>>
>> LOCK_CS keeps CS asserted though the entire transfer.  This should
>> always be set.  The DMA code will always set it, explicitly on the
>> first segment of the first transfer, and then implicitly on all the
>> rest by never clearing the bit from the value read from the ctrl0
>> register.
>>
>> The only reason to not set LOCK_CS would be to attempt an altered
>> protocol where CS pulses between each word.  Though don't get your
>> hopes up if you want to do this, as the hardware doesn't appear to do
>> this in any sane manner.
>
> Can you please elaborate on this part above? The description is very vague.
>
> Fabio, can you review this too please?

Sure, it would be nice if Trent could resend this series and copy the
SPI maintainer, Mark Brown.


From jonas.jensen at gmail.com  Wed Jul 10 10:00:48 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 10 Jul 2013 16:00:48 +0200
Subject: [PATCH] rtc: Add MOXA ART RTC driver
Message-ID: <1373464848-28146-1-git-send-email-jonas.jensen@gmail.com>

Add RTC driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130703

 drivers/rtc/Kconfig      |   9 ++
 drivers/rtc/Makefile     |   1 +
 drivers/rtc/rtc-moxart.c | 335 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 345 insertions(+)
 create mode 100644 drivers/rtc/rtc-moxart.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index b983813..7035955 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1233,6 +1233,15 @@ config RTC_DRV_SNVS
 	   This driver can also be built as a module, if so, the module
 	   will be called "rtc-snvs".
 
+config RTC_DRV_MOXART
+	tristate "MOXA ART RTC"
+	help
+	   If you say yes here you get support for the MOXA ART
+	   RTC module.
+
+	   This driver can also be built as a module. If so, the module
+	   will be called rtc-moxart
+
 comment "HID Sensor RTC drivers"
 
 config RTC_DRV_HID_SENSOR_TIME
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index c33f86f..c0381fd 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -77,6 +77,7 @@ obj-$(CONFIG_RTC_DRV_MAX6902)	+= rtc-max6902.o
 obj-$(CONFIG_RTC_DRV_MAX77686)	+= rtc-max77686.o
 obj-$(CONFIG_RTC_DRV_MC13XXX)	+= rtc-mc13xxx.o
 obj-$(CONFIG_RTC_DRV_MSM6242)	+= rtc-msm6242.o
+obj-$(CONFIG_RTC_DRV_MOXART)	+= rtc-moxart.o
 obj-$(CONFIG_RTC_DRV_MPC5121)	+= rtc-mpc5121.o
 obj-$(CONFIG_RTC_DRV_MV)	+= rtc-mv.o
 obj-$(CONFIG_RTC_DRV_NUC900)	+= rtc-nuc900.o
diff --git a/drivers/rtc/rtc-moxart.c b/drivers/rtc/rtc-moxart.c
new file mode 100644
index 0000000..cfdbedc
--- /dev/null
+++ b/drivers/rtc/rtc-moxart.c
@@ -0,0 +1,335 @@
+/*
+ * MOXA ART RTC driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/rtc.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/gpio.h>
+
+#define GPIO_EM1240_HIGH			1
+#define GPIO_EM1240_LOW				0
+#define GPIO_EM1240_OUTPUT			1
+#define GPIO_EM1240_INPUT			0
+
+#define GPIO_RTC_SCLK				(5)
+#define GPIO_RTC_DATA				(6)
+#define GPIO_RTC_RESET				(7)
+
+#define GPIO_RTC_RESERVED			0x0C
+#define GPIO_RTC_DATA_SET			0x10
+#define GPIO_RTC_DATA_CLEAR			0x14
+#define GPIO_RTC_PIN_PULL_ENABLE		0x18
+#define GPIO_RTC_PIN_PULL_TYPE			0x1C
+#define GPIO_RTC_INT_ENABLE			0x20
+#define GPIO_RTC_INT_RAW_STATE			0x24
+#define GPIO_RTC_INT_MASKED_STATE		0x28
+#define GPIO_RTC_INT_MASK			0x2C
+#define GPIO_RTC_INT_CLEAR			0x30
+#define GPIO_RTC_INT_TRIGGER			0x34
+#define GPIO_RTC_INT_BOTH			0x38
+#define GPIO_RTC_INT_RISE_NEG			0x3C
+#define GPIO_RTC_BOUNCE_ENABLE			0x40
+#define GPIO_RTC_BOUNCE_PRE_SCALE		0x44
+
+#define GPIO_RTC_PROTECT_W			0x8E
+#define GPIO_RTC_PROTECT_R			0x8F
+#define GPIO_RTC_YEAR_W				0x8C
+#define GPIO_RTC_YEAR_R				0x8D
+#define GPIO_RTC_DAY_W				0x8A
+#define GPIO_RTC_DAY_R				0x8B
+#define GPIO_RTC_MONTH_W			0x88
+#define GPIO_RTC_MONTH_R			0x89
+#define GPIO_RTC_DATE_W				0x86
+#define GPIO_RTC_DATE_R				0x87
+#define GPIO_RTC_HOURS_W			0x84
+#define GPIO_RTC_HOURS_R			0x85
+#define GPIO_RTC_MINUTES_W			0x82
+#define GPIO_RTC_MINUTES_R			0x83
+#define GPIO_RTC_SECONDS_W			0x80
+#define GPIO_RTC_SECONDS_R			0x81
+#define GPIO_RTC_DELAY_TIME			8	/* 8 usecond */
+#define GPIO_RTC_IS_OPEN			0x01	/* /dev/rtc in use */
+#define GPIO_PIO(x)				(1 << x)
+
+struct rtc_plat_data {
+	struct rtc_device *rtc;
+};
+
+static spinlock_t rtc_lock;
+static int day_of_year[12] =	{ 0, 31, 59, 90, 120, 151, 181,
+				  212, 243, 273, 304, 334 };
+
+void moxart_rtc_write_byte(u8 data)
+{
+	int i;
+
+	for (i = 0; i < 8; i++, data >>= 1) {
+		gpio_set_value(GPIO_RTC_SCLK, GPIO_EM1240_LOW);
+		gpio_set_value(GPIO_RTC_DATA, ((data & 1) == 1));
+		udelay(GPIO_RTC_DELAY_TIME);
+		gpio_set_value(GPIO_RTC_SCLK, GPIO_EM1240_HIGH);
+		udelay(GPIO_RTC_DELAY_TIME);
+	}
+}
+
+u8 moxart_rtc_read_byte(void)
+{
+	int i;
+	u8 data = 0;
+
+	for (i = 0; i < 8; i++) {
+		gpio_set_value(GPIO_RTC_SCLK, GPIO_EM1240_LOW);
+		udelay(GPIO_RTC_DELAY_TIME);
+		gpio_set_value(GPIO_RTC_SCLK, GPIO_EM1240_HIGH);
+		if (gpio_get_value(GPIO_RTC_DATA))
+			data |= (1 << i);
+		udelay(GPIO_RTC_DELAY_TIME);
+	}
+	return data;
+}
+
+static u8 moxart_rtc_read_register(u8 cmd)
+{
+	u8 data;
+	unsigned long flags;
+
+	local_irq_save(flags);
+
+	gpio_direction_output(GPIO_RTC_DATA, 0);
+	gpio_set_value(GPIO_RTC_RESET, GPIO_EM1240_HIGH);
+	udelay(GPIO_RTC_DELAY_TIME);
+	moxart_rtc_write_byte(cmd);
+	gpio_direction_input(GPIO_RTC_DATA);
+	udelay(GPIO_RTC_DELAY_TIME);
+	data = moxart_rtc_read_byte();
+	gpio_set_value(GPIO_RTC_SCLK, GPIO_EM1240_LOW);
+	gpio_set_value(GPIO_RTC_RESET, GPIO_EM1240_LOW);
+	udelay(GPIO_RTC_DELAY_TIME);
+
+	local_irq_restore(flags);
+
+	return data;
+}
+
+static void moxart_rtc_write_register(u8 cmd, u8 data)
+{
+	unsigned long flags;
+
+	local_irq_save(flags);
+
+	gpio_direction_output(GPIO_RTC_DATA, 0);
+	gpio_set_value(GPIO_RTC_RESET, GPIO_EM1240_HIGH);
+	udelay(GPIO_RTC_DELAY_TIME);
+	moxart_rtc_write_byte(cmd);
+	moxart_rtc_write_byte(data);
+	gpio_set_value(GPIO_RTC_SCLK, GPIO_EM1240_LOW);
+	gpio_set_value(GPIO_RTC_RESET, GPIO_EM1240_LOW);
+	udelay(GPIO_RTC_DELAY_TIME);
+
+	local_irq_restore(flags);
+}
+
+static int moxart_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+	spin_lock_irq(&rtc_lock);
+
+	moxart_rtc_write_register(GPIO_RTC_PROTECT_W, 0);
+	moxart_rtc_write_register(GPIO_RTC_YEAR_W,
+				  (((tm->tm_year - 100) / 10) << 4) |
+				  ((tm->tm_year - 100) % 10));
+
+	moxart_rtc_write_register(GPIO_RTC_MONTH_W,
+				  (((tm->tm_mon + 1) / 10) << 4) |
+				  ((tm->tm_mon + 1) % 10));
+
+	moxart_rtc_write_register(GPIO_RTC_DATE_W,
+				  ((tm->tm_mday / 10) << 4) |
+				  (tm->tm_mday % 10));
+
+	moxart_rtc_write_register(GPIO_RTC_HOURS_W,
+				  ((tm->tm_hour / 10) << 4) |
+				  (tm->tm_hour % 10));
+
+	moxart_rtc_write_register(GPIO_RTC_MINUTES_W,
+				  ((tm->tm_min / 10) << 4) |
+				  (tm->tm_min % 10));
+
+	moxart_rtc_write_register(GPIO_RTC_SECONDS_W,
+				  ((tm->tm_sec / 10) << 4) |
+				  (tm->tm_sec % 10));
+
+	moxart_rtc_write_register(GPIO_RTC_PROTECT_W, 0x80);
+
+	spin_unlock_irq(&rtc_lock);
+
+	dev_dbg(dev, "%s: success tm_year=%d tm_mon=%d\n"
+		"tm_mday=%d tm_hour=%d tm_min=%d tm_sec=%d\n",
+		__func__, tm->tm_year, tm->tm_mon, tm->tm_mday,
+		tm->tm_hour, tm->tm_min, tm->tm_sec);
+
+	return 0;
+}
+
+static int moxart_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+	unsigned char v;
+
+	spin_lock_irq(&rtc_lock);
+
+	v = moxart_rtc_read_register(GPIO_RTC_SECONDS_R);
+	tm->tm_sec = (((v & 0x70) >> 4) * 10) + (v & 0x0F);
+
+	v = moxart_rtc_read_register(GPIO_RTC_MINUTES_R);
+	tm->tm_min = (((v & 0x70) >> 4) * 10) + (v & 0x0F);
+
+	v = moxart_rtc_read_register(GPIO_RTC_HOURS_R);
+	if (v & 0x80) { /* 12-hour mode */
+		tm->tm_hour = (((v & 0x10) >> 4) * 10) + (v & 0x0F);
+		if (v & 0x20) { /* PM mode */
+			tm->tm_hour += 12;
+			if (tm->tm_hour >= 24)
+				tm->tm_hour = 0;
+		}
+	} else { /* 24-hour mode */
+		tm->tm_hour = (((v & 0x30) >> 4) * 10) + (v & 0x0F);
+	}
+
+	v = moxart_rtc_read_register(GPIO_RTC_DATE_R);
+	tm->tm_mday = (((v & 0x30) >> 4) * 10) + (v & 0x0F);
+
+	v = moxart_rtc_read_register(GPIO_RTC_MONTH_R);
+	tm->tm_mon = (((v & 0x10) >> 4) * 10) + (v & 0x0F);
+	tm->tm_mon--;
+
+	v = moxart_rtc_read_register(GPIO_RTC_YEAR_R);
+	tm->tm_year = (((v & 0xF0) >> 4) * 10) + (v & 0x0F);
+	tm->tm_year += 100;
+	if (tm->tm_year <= 69)
+		tm->tm_year += 100;
+
+	v = moxart_rtc_read_register(GPIO_RTC_DAY_R);
+	tm->tm_wday = (v & 0x0f) - 1;
+	tm->tm_yday = day_of_year[tm->tm_mon];
+	tm->tm_yday += (tm->tm_mday - 1);
+	if (tm->tm_mon >= 2) {
+		if (!(tm->tm_year % 4) && (tm->tm_year % 100))
+			tm->tm_yday++;
+	}
+
+	tm->tm_isdst = 0;
+
+	spin_unlock_irq(&rtc_lock);
+
+	return 0;
+}
+
+static int moxart_rtc_ioctl(struct device *dev, unsigned int cmd,
+	unsigned long arg)
+{
+	switch (cmd) {
+	default:
+		return -ENOIOCTLCMD;
+	}
+
+	return 0;
+}
+
+static const struct rtc_class_ops moxart_rtc_ops = {
+	.read_time	= moxart_rtc_read_time,
+	.set_time	= moxart_rtc_set_time,
+	.ioctl		= moxart_rtc_ioctl,
+};
+
+static int moxart_rtc_probe(struct platform_device *pdev)
+{
+	struct rtc_device *rtc;
+	struct rtc_plat_data *pdata = NULL;
+	int ret = 0;
+
+	pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata) {
+		dev_err(&pdev->dev, "devm_kzalloc failed\n");
+		return -ENOMEM;
+	}
+
+	spin_lock_init(&rtc_lock);
+
+	gpio_request(GPIO_RTC_DATA, "rtc_data");
+	gpio_request(GPIO_RTC_SCLK, "rtc_sclk");
+	gpio_request(GPIO_RTC_RESET, "rtc_reset");
+
+	gpio_direction_output(GPIO_RTC_RESET, 0);
+	gpio_direction_output(GPIO_RTC_SCLK, 0);
+
+	rtc = rtc_device_register(pdev->name, &pdev->dev,
+		&moxart_rtc_ops, THIS_MODULE);
+	if (IS_ERR(rtc)) {
+		ret = PTR_ERR(rtc);
+		goto out;
+	}
+
+	pdata->rtc = rtc;
+	platform_set_drvdata(pdev, pdata);
+
+	dev_dbg(&pdev->dev, "%s\n", __func__);
+
+	if (ret)
+		goto out;
+
+	return 0;
+
+ out:
+	if (pdata->rtc)
+		rtc_device_unregister(pdata->rtc);
+	devm_kfree(&pdev->dev, pdata);
+	return ret;
+}
+
+static int moxart_rtc_remove(struct platform_device *pdev)
+{
+	struct rtc_plat_data *pdata = platform_get_drvdata(pdev);
+
+	gpio_free(GPIO_RTC_DATA);
+	gpio_free(GPIO_RTC_SCLK);
+	gpio_free(GPIO_RTC_RESET);
+
+	rtc_device_unregister(pdata->rtc);
+	devm_kfree(&pdev->dev, pdata);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_rtc_match[] = {
+	{ .compatible = "moxa,moxart-rtc" },
+	{ },
+};
+
+static struct platform_driver moxart_rtc_driver = {
+	.probe	= moxart_rtc_probe,
+	.remove	= moxart_rtc_remove,
+	.driver	= {
+		.name		= "moxart-rtc",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_rtc_match,
+	},
+};
+module_platform_driver(moxart_rtc_driver);
+
+MODULE_DESCRIPTION("MOXART RTC driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From haojian.zhuang at gmail.com  Wed Jul 10 10:08:50 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Wed, 10 Jul 2013 22:08:50 +0800
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <20130710122433.GO11908@titan.lakedaemon.net>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <CAN1soZxiOh6TpbUOCUzK8gNwmvjbT3ihkUWaw8tuZ7md+NVA2g@mail.gmail.com>
 <20130710122433.GO11908@titan.lakedaemon.net>
Message-ID: <CAN1soZzMvront1-jcBW6-uRKNs0OZNGnmiOjKGZSM28bViB_8A@mail.gmail.com>

On Wed, Jul 10, 2013 at 8:24 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> On Wed, Jul 10, 2013 at 04:19:46PM +0800, Haojian Zhuang wrote:
>> On Tue, Jul 9, 2013 at 8:49 PM, Jason Cooper <jason at lakedaemon.net> wrote:
>> > Neil,
>> >
>> > On Tue, Jul 09, 2013 at 02:42:44PM +0800, Neil Zhang wrote:
>> >> The documented vendor prefix for Marvell is 'marvell', not 'mrvl', so
>> >> let's change it.
>> >>
>> >> Signed-off-by: Neil Zhang <zhangwm at marvell.com>
>> >> ---
>> >>  .../devicetree/bindings/arm/mrvl/intc.txt          |   16 +++---
>> >>  .../devicetree/bindings/arm/mrvl/mrvl.txt          |    6 +-
>> >>  .../devicetree/bindings/arm/mrvl/timer.txt         |    4 +-
>> >>  Documentation/devicetree/bindings/i2c/i2c-pxa.txt  |   14 +++---
>> >>  .../devicetree/bindings/mmc/sdhci-pxa.txt          |    8 ++--
>> >>  .../devicetree/bindings/rtc/sa1100-rtc.txt         |    4 +-
>> >>  .../devicetree/bindings/serial/mrvl-serial.txt     |    2 +-
>> >>  arch/arm/boot/dts/mmp2-brownstone.dts              |    2 +-
>> >>  arch/arm/boot/dts/mmp2.dtsi                        |   56 ++++++++++----------
>> >>  arch/arm/boot/dts/pxa168-aspenite.dts              |    2 +-
>> >>  arch/arm/boot/dts/pxa168.dtsi                      |   24 ++++----
>> >>  arch/arm/boot/dts/pxa2xx.dtsi                      |   16 +++---
>> >>  arch/arm/boot/dts/pxa3xx.dtsi                      |    2 +-
>> >>  arch/arm/boot/dts/pxa910-dkb.dts                   |    2 +-
>> >>  arch/arm/boot/dts/pxa910.dtsi                      |   27 +++++-----
>> >>  arch/arm/mach-mmp/irq.c                            |   16 +++---
>> >>  arch/arm/mach-mmp/mmp-dt.c                         |   28 +++++-----
>> >>  arch/arm/mach-mmp/mmp2-dt.c                        |   16 +++---
>> >>  arch/arm/mach-mmp/time.c                           |    2 +-
>> >>  arch/arm/mach-pxa/pxa-dt.c                         |   14 +++---
>> >>  drivers/i2c/busses/i2c-pxa.c                       |   10 ++--
>> >>  drivers/mmc/host/sdhci-pxav2.c                     |    4 +-
>> >>  drivers/mmc/host/sdhci-pxav3.c                     |    4 +-
>> >>  drivers/rtc/rtc-sa1100.c                           |    4 +-
>> >>  drivers/tty/serial/pxa.c                           |    4 +-
>> >>  25 files changed, 144 insertions(+), 143 deletions(-)
>> >
>> > I agree with the need to change, however, this has been in the binding
>> > documentation since v3.5.  I wish we had caught this when we decided
>> > against using stock ticker symbols (not all stock markets use
>> > alphabetical abbreviated names, not all companies are listed on any
>> > stock exchange).
>> >
>> > To do this properly, the drivers are going to have to be compatible with
>> > the old and the new names, and the binding docs updated to reflect the
>> > legacy name and the preferred name.
>> >
>>
>> It's better to only use the new names.
>
> In the dts{i}, yes.  But we don't want to break systems in the field
> with "mrvl,..." compatible strings.  Therefore, at least the drivers
> need an extra compatible string to support "mrvl,...".
>
> If it had just been since v3.9, it'd be different/simpler.  However,
> several vendors have opted to use kernels newer than v3.5, which makes
> this scenario a real possibility.
>
> thx,
>
> Jason.

Is there any vendor using DT for this Marvell chip? I think the answer is no.
Only Marvell guys are still moving to DT. They didn't deliver their kernel
as reference. So there's no problem on this.

Regards
Haojian


From tony at atomide.com  Wed Jul 10 10:26:34 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Jul 2013 07:26:34 -0700
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <87mwpuakod.fsf@linaro.org>
References: <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi>
 <87mwpuakod.fsf@linaro.org>
Message-ID: <20130710142633.GV5523@atomide.com>

* Kevin Hilman <khilman at linaro.org> [130710 01:29]:
> Felipe Balbi <balbi at ti.com> writes:
> >> 
> >> Right, but calling serial_omap_restore_context() even when the context
> >> is not lost, should not ideally cause an issue.
> >
> > it does in one condition. If context hasn't been saved before. And that
> > can happen in the case of wrong pm runtime status for that device.
> >
> > Imagine the device is marked as suspended even though it's fully enabled
> > (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> > your context structure is all zeroes (context has never been saved
> > before) then when you call pm_runtime_get_sync() on probe() your
> > ->runtime_resume() will get called, which will restore context,
> > essentially undoing anything which was configured by u-boot.
> >
> > Am I missing something ?
> 
> You're right, the _set_active() is crucial in the case when we prevent
> the console UART from idling during boot (though that shouldn't be
> happening in mainline unless the fix for "Issue 1" is done.)

Felipe is right, looks like all we need is to check if context is
initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.

After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
works for me. We could also check for some combination of the context
save registers being NULL if somebody has a good idea which ones
should never be 0.

Regards,

Tony


--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -161,6 +161,7 @@ struct uart_omap_port {
 	u32			calc_latency;
 	struct work_struct	qos_work;
 	struct pinctrl		*pins;
+	bool			initialized;
 	bool			is_suspending;
 };
 
@@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
 
 	pm_runtime_mark_last_busy(up->dev);
 	pm_runtime_put_autosuspend(up->dev);
+	up->initialized = true;
+
 	return 0;
 
 err_add_port:
@@ -1584,6 +1587,9 @@ static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
 #ifdef CONFIG_PM_RUNTIME
 static void serial_omap_restore_context(struct uart_omap_port *up)
 {
+	if (!up->initialized)
+		return;
+
 	if (up->errata & UART_ERRATA_i202_MDR1_ACCESS)
 		serial_omap_mdr1_errataset(up, UART_OMAP_MDR1_DISABLE);
 	else


From nsekhar at ti.com  Wed Jul 10 10:28:57 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 10 Jul 2013 19:58:57 +0530
Subject: [PATCH] ARM: omap2: add select of TI_PRIV_EDMA
In-Reply-To: <20130710075017.GM5523@atomide.com>
References: <1373359054-5007-1-git-send-email-olof@lixom.net>
 <20130710075017.GM5523@atomide.com>
Message-ID: <51DD6FA9.8080908@ti.com>

On 7/10/2013 1:20 PM, Tony Lindgren wrote:
> * Olof Johansson <olof at lixom.net> [130709 01:44]:
>> "ARM: OMAP: build mach-omap code only if needed" moved around the
>> ARCH_OMAP2PLUS stanza, but accidentally dropped the seleciton of
>> TI_PRIV_EDMA in the process. Add it back.
>>
>> Cc: Arnd Bergmann <arnd at arndb.de>
> 
> Acked-by: Tony Lindgren <tony at atomide.com>
> 
>> Signed-off-by: Olof Johansson <olof at lixom.net>

Thinking more, I do not think we should be selecting TI_PRIV_EDMA for
OMAP2PLUS. There is no part of mach-omap2 that depends directly on
TI_PRIV_EDMA being enabled.

Instead, TI_PRIV_EDMA should be selected by the DMA engine driver as
done in the patch here:

http://www.spinics.net/lists/kernel/msg1563777.html

Its the DMA engine driver which makes the private DMA calls so this
patch is better.

Thanks,
Sekhar

>>
>> ---
>>
>> I noticed the original patch was a bit down in the fixes branch, so
>> instead of rebasing I checked this in on top.
>>
>> -Olof
>>
>>  arch/arm/mach-omap2/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>> index 5c14051..58152b1 100644
>> --- a/arch/arm/mach-omap2/Kconfig
>> +++ b/arch/arm/mach-omap2/Kconfig
>> @@ -99,6 +99,7 @@ config ARCH_OMAP2PLUS
>>  	select PROC_DEVICETREE if PROC_FS
>>  	select SOC_BUS
>>  	select SPARSE_IRQ
>> +	select TI_PRIV_EDMA
>>  	select USE_OF
>>  	help
>>  	  Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
>> -- 
>> 1.8.1.192.gc4361b8
>>
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From shawn.guo at linaro.org  Wed Jul 10 10:30:53 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 10 Jul 2013 22:30:53 +0800
Subject: [PATCH linux-next] ARM: imx: fix imx_init_l2cache storage class
In-Reply-To: <1373449546-1040-1-git-send-email-vincent.stehle@freescale.com>
References: <1373449546-1040-1-git-send-email-vincent.stehle@freescale.com>
Message-ID: <20130710143051.GA24654@S2101-09.ap.freescale.net>

Vincent,

Sorry.  I was not aware of that imx_v6_v7_defconfig does not have
CACHE_L2X0 enabled, so I did not catch it with my testing.  Thanks for
fixing it.

On Wed, Jul 10, 2013 at 11:45:46AM +0200, Vincent Stehl? wrote:
> Commit 879ec1ceeac21285d62606c1e96520887efcd9bc makes imx_init_l2cache a common
> function and updates the header declaration accordingly. Fix function storage
> class, too.
> 
The commit ID is not stable, and I dropped it and applied the patch.

Shawn

> This fixes the following compilation error:
> 
>   arch/arm/mach-imx/system.c:101:123: error: static declaration of ?imx_init_l2cache? follows non-static declaration
>   In file included from arch/arm/mach-imx/system.c:32:0:
>   arch/arm/mach-imx/common.h:165:13: note: previous declaration of ?imx_init_l2cache? was here
>   arch/arm/mach-imx/system.c:101:123: warning: ?imx_init_l2cache? defined but not used [-Wunused-function]
> 
> Signed-off-by: Vincent Stehl? <vincent.stehle at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> Cc: Sascha Hauer <kernel at pengutronix.de>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: trivial at kernel.org
> ---
> 
> 
> Hi,
> 
> Linux next-20130710 breaks compilation of ARM multi_v7_defconfig. This patch fixes it.
> 
> (Note: this patch is necessary for the link, too: http://www.spinics.net/lists/kernel/msg1563777.html)
> 
> Best regards,
> 
> V.
> 
> 
>  arch/arm/mach-imx/system.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-imx/system.c b/arch/arm/mach-imx/system.c
> index e5592ca..64ff37e 100644
> --- a/arch/arm/mach-imx/system.c
> +++ b/arch/arm/mach-imx/system.c
> @@ -98,7 +98,7 @@ void __init mxc_arch_reset_init_dt(void)
>  }
>  
>  #ifdef CONFIG_CACHE_L2X0
> -static void __init imx_init_l2cache(void)
> +void __init imx_init_l2cache(void)
>  {
>  	void __iomem *l2x0_base;
>  	struct device_node *np;
> -- 
> 1.7.10.4
> 
> 
> 



From shawn.guo at linaro.org  Wed Jul 10 10:35:01 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 10 Jul 2013 22:35:01 +0800
Subject: [PATCH v2 1/2] ARM: imx: system: Do not declare
 imx_init_l2cache() as static
In-Reply-To: <1373461814-8844-1-git-send-email-fabio.estevam@freescale.com>
References: <1373461814-8844-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <20130710143459.GB24654@S2101-09.ap.freescale.net>

On Wed, Jul 10, 2013 at 10:10:13AM -0300, Fabio Estevam wrote:
> commit 879ec1cee (ARM: imx: let L2 initialization be a common function) breaks 
> the build when CONFIG_CACHE_L2X0=y:
> 
> arch/arm/mach-imx/system.c:101:20: error: static declaration of 'imx_init_l2cache' follows non-static declaration
> In file included from arch/arm/mach-imx/system.c:32:0:
> arch/arm/mach-imx/common.h:165:13: note: previous declaration of 'imx_init_l2cache' was here
> arch/arm/mach-imx/system.c:101:20: warning: 'imx_init_l2cache' defined but not used [-Wunused-function]
> 
> imx_init_l2cache() is a common function now, so it cannot be declared as static 
> anymore.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Thanks for the fixing.  I just applied a fix [1] from Vincent.

Shawn

[1]
http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg465491.html

> ---
> Changes since v1:
> - Newly introduced in this series
> 
>  arch/arm/mach-imx/system.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-imx/system.c b/arch/arm/mach-imx/system.c
> index e5592ca..64ff37e 100644
> --- a/arch/arm/mach-imx/system.c
> +++ b/arch/arm/mach-imx/system.c
> @@ -98,7 +98,7 @@ void __init mxc_arch_reset_init_dt(void)
>  }
>  
>  #ifdef CONFIG_CACHE_L2X0
> -static void __init imx_init_l2cache(void)
> +void __init imx_init_l2cache(void)
>  {
>  	void __iomem *l2x0_base;
>  	struct device_node *np;
> -- 
> 1.8.1.2
> 
> 



From shawn.guo at linaro.org  Wed Jul 10 10:36:27 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 10 Jul 2013 22:36:27 +0800
Subject: [PATCH v2 2/2] ARM: imx: Select MIGHT_HAVE_CACHE_L2X0
In-Reply-To: <1373461814-8844-2-git-send-email-fabio.estevam@freescale.com>
References: <1373461814-8844-1-git-send-email-fabio.estevam@freescale.com>
 <1373461814-8844-2-git-send-email-fabio.estevam@freescale.com>
Message-ID: <20130710143626.GC24654@S2101-09.ap.freescale.net>

On Wed, Jul 10, 2013 at 10:10:14AM -0300, Fabio Estevam wrote:
> Select MIGHT_HAVE_CACHE_L2X0 for mx31/35/51/53/6q/6sl/vf610
> 
So maybe we can just do the following for config ARCH_MXC?

	select MIGHT_HAVE_CACHE_L2X0 if ARCH_MULTI_V6_V7

Shawn

> By selecting MIGHT_HAVE_CACHE_L2X0, the user still has the possibility to 
> disable CACHE_L2X0 selection via menuconfig.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
> Changes since v1:
> - Use MIGHT_HAVE_CACHE_L2X0 instead of CACHE_L2X0, to allow users to still
> disable L2 cache via menuconfig if they want to
> - Also select L2 cache for vf610
> 
>  arch/arm/mach-imx/Kconfig | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index f546560..cc6961d 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -125,6 +125,7 @@ config SOC_IMX31
>  	select COMMON_CLK
>  	select CPU_V6
>  	select IMX_HAVE_PLATFORM_MXC_RNGA
> +	select MIGHT_HAVE_CACHE_L2X0
>  	select MXC_AVIC
>  	select SMP_ON_UP if SMP
>  
> @@ -134,6 +135,7 @@ config SOC_IMX35
>  	select COMMON_CLK
>  	select CPU_V6K
>  	select HAVE_EPIT
> +	select MIGHT_HAVE_CACHE_L2X0
>  	select MXC_AVIC
>  	select SMP_ON_UP if SMP
>  
> @@ -144,6 +146,7 @@ config SOC_IMX5
>  	select ARCH_MXC_IOMUX_V3
>  	select COMMON_CLK
>  	select CPU_V7
> +	select MIGHT_HAVE_CACHE_L2X0
>  	select MXC_TZIC
>  
>  config	SOC_IMX51
> @@ -799,6 +802,7 @@ config SOC_IMX6Q
>  	select HAVE_IMX_MMDC
>  	select HAVE_IMX_SRC
>  	select HAVE_SMP
> +	select MIGHT_HAVE_CACHE_L2X0
>  	select MFD_SYSCON
>  	select PINCTRL
>  	select PINCTRL_IMX6Q
> @@ -820,6 +824,7 @@ config SOC_IMX6SL
>  	select HAVE_IMX_GPC
>  	select HAVE_IMX_MMDC
>  	select HAVE_IMX_SRC
> +	select MIGHT_HAVE_CACHE_L2X0
>  	select MFD_SYSCON
>  	select PINCTRL
>  	select PINCTRL_IMX6SL
> @@ -835,6 +840,7 @@ config SOC_VF610
>  	select CPU_V7
>  	select ARM_GIC
>  	select CLKSRC_OF
> +	select MIGHT_HAVE_CACHE_L2X0
>  	select PINCTRL
>  	select PINCTRL_VF610
>  	select VF_PIT_TIMER
> -- 
> 1.8.1.2
> 
> 



From arnd at arndb.de  Wed Jul 10 10:36:57 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Jul 2013 16:36:57 +0200
Subject: [PATCH] ARM: omap2: add select of TI_PRIV_EDMA
In-Reply-To: <51DD6FA9.8080908@ti.com>
References: <1373359054-5007-1-git-send-email-olof@lixom.net>
 <20130710075017.GM5523@atomide.com> <51DD6FA9.8080908@ti.com>
Message-ID: <201307101636.57623.arnd@arndb.de>

On Wednesday 10 July 2013, Sekhar Nori wrote:
> On 7/10/2013 1:20 PM, Tony Lindgren wrote:
> > * Olof Johansson <olof at lixom.net> [130709 01:44]:
> >> "ARM: OMAP: build mach-omap code only if needed" moved around the
> >> ARCH_OMAP2PLUS stanza, but accidentally dropped the seleciton of
> >> TI_PRIV_EDMA in the process. Add it back.
> >>
> >> Cc: Arnd Bergmann <arnd at arndb.de>
> > 
> > Acked-by: Tony Lindgren <tony at atomide.com>
> > 
> >> Signed-off-by: Olof Johansson <olof at lixom.net>
> 
> Thinking more, I do not think we should be selecting TI_PRIV_EDMA for
> OMAP2PLUS. There is no part of mach-omap2 that depends directly on
> TI_PRIV_EDMA being enabled.
> 
> Instead, TI_PRIV_EDMA should be selected by the DMA engine driver as
> done in the patch here:
> 
> http://www.spinics.net/lists/kernel/msg1563777.html
> 
> Its the DMA engine driver which makes the private DMA calls so this
> patch is better.

I would have done 'depends on TI_PRIV_EDMA' instead, but any of the three
solutions is fine with me.

	Arnd


From plagnioj at jcrosoft.com  Wed Jul 10 10:38:35 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 10 Jul 2013 16:38:35 +0200
Subject: [PATCH 2/3] arm: atmel: at91sam9n12: add qt1070 support
In-Reply-To: <1373449869-5083-3-git-send-email-voice.shen@atmel.com>
References: <1373449869-5083-1-git-send-email-voice.shen@atmel.com>
 <1373449869-5083-3-git-send-email-voice.shen@atmel.com>
Message-ID: <20130710143835.GG18012@ns203013.ovh.net>

On 17:51 Wed 10 Jul     , Bo Shen wrote:
> add qt1070 support on at91sam9n12ek board
> 
> Signed-off-by: Bo Shen <voice.shen at atmel.com>
> ---
>  arch/arm/boot/dts/at91sam9n12ek.dts |   16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts b/arch/arm/boot/dts/at91sam9n12ek.dts
> index d59b70c..3acac62 100644
> --- a/arch/arm/boot/dts/at91sam9n12ek.dts
> +++ b/arch/arm/boot/dts/at91sam9n12ek.dts
> @@ -40,6 +40,15 @@
>  
>  			i2c0: i2c at f8010000 {
>  				status = "okay";
> +
> +				qt1070: keyboard at 1b {
> +					compatible = "qt1070";
> +					reg = <0x1b>;
> +					interrupt-parent = <&pioA>;
> +					interrupts = <2 0x0>;
use the macro
> +					pinctrl-names = "default";
> +					pinctrl-0 = <&pinctrl_qt1070_irq>;
> +				};
>  			};
>  
>  			i2c1: i2c at f8014000 {
> @@ -66,6 +75,13 @@
>  							<AT91_PIOA 7 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;	/* PA7 gpio CD pin pull up and deglitch */
>  					};
>  				};
> +
> +				qt1070 {
> +					pinctrl_qt1070_irq: qt1070_irq {
> +						atmel,pins =
> +							<AT91_PIOA 2 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PA2 GPIO with pull up deglith */
drop the comment as we use macro
> +					};
> +				};
>  			};
>  
>  			spi0: spi at f0000000 {
> -- 

Best Regards,
J.


From plagnioj at jcrosoft.com  Wed Jul 10 10:39:23 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 10 Jul 2013 16:39:23 +0200
Subject: [PATCH 1/3] arm: atmel: at91sam9n12: add pinctrl of TWI
In-Reply-To: <1373449869-5083-2-git-send-email-voice.shen@atmel.com>
References: <1373449869-5083-1-git-send-email-voice.shen@atmel.com>
 <1373449869-5083-2-git-send-email-voice.shen@atmel.com>
Message-ID: <20130710143923.GH18012@ns203013.ovh.net>

On 17:51 Wed 10 Jul     , Bo Shen wrote:
> add pinctrl of TWI for at91sam9n12 SoC
> 
> Signed-off-by: Bo Shen <voice.shen at atmel.com>
> ---
>  arch/arm/boot/dts/at91sam9n12.dtsi |   20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
> index bb7f564..3db62f6 100644
> --- a/arch/arm/boot/dts/at91sam9n12.dtsi
> +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
> @@ -291,6 +291,22 @@
>  					};
>  				};
>  
> +				i2c0 {
> +					pinctrl_i2c0: i2c0-0 {
> +						atmel,pins =
> +							<AT91_PIOA 30 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA30 periph A I2C0 data */
> +							 AT91_PIOA 31 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PA31 periph A I2C0 clock */
> +					};
> +				};
> +
> +				i2c1 {
> +					pinctrl_i2c1: i2c1-0 {
> +						atmel,pins =
> +							<AT91_PIOC 0 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC0 periph C I2C1 data */
> +							 AT91_PIOC 1 AT91_PERIPH_C AT91_PINCTRL_NONE>;	/* PC1 periph C I2C1 clock */
drop  the comment as we use macro
> +					};
> +				};
> +
>  				tcb0 {
>  					pinctrl_tcb0_tclk0: tcb0_tclk0-0 {
>  						atmel,pins = <AT91_PIOA 24 AT91_PERIPH_A AT91_PINCTRL_NONE>;
> @@ -471,6 +487,8 @@
>  				dma-names = "tx", "rx";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&pinctrl_i2c0>;
>  				status = "disabled";
>  			};
>  
> @@ -483,6 +501,8 @@
>  				dma-names = "tx", "rx";
>  				#address-cells = <1>;
>  				#size-cells = <0>;
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&pinctrl_i2c1>;
>  				status = "disabled";
>  			};
>  
> -- 
> 1.7.9.5
> 


From dsd at laptop.org  Wed Jul 10 10:41:03 2013
From: dsd at laptop.org (Daniel Drake)
Date: Wed, 10 Jul 2013 08:41:03 -0600
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <20130710122023.GN11908@titan.lakedaemon.net>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <175CCF5F49938B4D99B2E3EF7F558EBE3DBC97FA8F@SC-VEXCH4.marvell.com>
 <20130710122023.GN11908@titan.lakedaemon.net>
Message-ID: <CAMLZHHQre=juBmWJ2ZouLJGUW0owJd4GrOVur=ea2BPvMWjMbA@mail.gmail.com>

On Wed, Jul 10, 2013 at 6:20 AM, Jason Cooper <jason at lakedaemon.net> wrote:
> Please keep in mind that the DT is supposed to be tied to the hardware,
> *not* the kernel.  iow, a dtb comes with a board, and the user/OS
> upgrades the kernel as needed w/o upgrading or changing the dtb.

Thank you for making this position clear to those trying to break
compatibility...

This will affect OLPC where the dtb comes from the firmware
(OpenFirmware), which is similar to the dtb coming "with the board" as
you describe. We run on Marvell SoCs.

> So the question you need to ask yourself is: Are there any users (since
> v3.5) that are doing this?  If so, they have "mrvl,..." compatible
> strings in their dtbs.  You don't want to break their systems on kernel
> upgrade, right?

In the OLPC case, the devicetree currently exported from the firmware
is unfortunately quite insufficient to boot mainline kernels. So we
are currently in a state of flux where we must break firmware/OS
compatibility in significant ways in order to support mainline
kernels. We are heading in this direction despite the pains.

Therefore right now its OK for us if we break compatibility during our
in-flux major firmware/DT restructuring, as this patch does.

However, once we have stabilised in the near future, it will no longer
be possible to break compatibility like this.

My vote would be to maintain the old names (in addition to the new) in
case there are people that will be affected by this that haven't seen
this thread. We were recently hit by another backwards-incompatible
change in Marvell's Linux gpio drivers where the compatible strings
recognised were changed (f87311743eaf85). This is not a big problem in
our current state however it cost me about 3 hours of changelog
skimming, glancing around in the code, and finally running a git
bisect, before I managed to figure out why things had suddenly stopped
working. That was irritating.

Thanks
Daniel


From nsekhar at ti.com  Wed Jul 10 10:41:34 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 10 Jul 2013 20:11:34 +0530
Subject: [PATCH] ARM: omap2: add select of TI_PRIV_EDMA
In-Reply-To: <201307101636.57623.arnd@arndb.de>
References: <1373359054-5007-1-git-send-email-olof@lixom.net>
 <20130710075017.GM5523@atomide.com> <51DD6FA9.8080908@ti.com>
 <201307101636.57623.arnd@arndb.de>
Message-ID: <51DD729E.9060402@ti.com>

On 7/10/2013 8:06 PM, Arnd Bergmann wrote:
> On Wednesday 10 July 2013, Sekhar Nori wrote:
>> On 7/10/2013 1:20 PM, Tony Lindgren wrote:
>>> * Olof Johansson <olof at lixom.net> [130709 01:44]:
>>>> "ARM: OMAP: build mach-omap code only if needed" moved around the
>>>> ARCH_OMAP2PLUS stanza, but accidentally dropped the seleciton of
>>>> TI_PRIV_EDMA in the process. Add it back.
>>>>
>>>> Cc: Arnd Bergmann <arnd at arndb.de>
>>>
>>> Acked-by: Tony Lindgren <tony at atomide.com>
>>>
>>>> Signed-off-by: Olof Johansson <olof at lixom.net>
>>
>> Thinking more, I do not think we should be selecting TI_PRIV_EDMA for
>> OMAP2PLUS. There is no part of mach-omap2 that depends directly on
>> TI_PRIV_EDMA being enabled.
>>
>> Instead, TI_PRIV_EDMA should be selected by the DMA engine driver as
>> done in the patch here:
>>
>> http://www.spinics.net/lists/kernel/msg1563777.html
>>
>> Its the DMA engine driver which makes the private DMA calls so this
>> patch is better.
> 
> I would have done 'depends on TI_PRIV_EDMA' instead, but any of the three
> solutions is fine with me.

TI_PRIV_EDMA is not a user selectable option so if 'depends on' is used,
then the select in mach-omap2 is needed as well.

Thanks,
Sekhar


From tgih.jun at samsung.com  Wed Jul 10 10:54:47 2013
From: tgih.jun at samsung.com (Seungwon Jeon)
Date: Wed, 10 Jul 2013 23:54:47 +0900
Subject: [PATCH v2 3/5] mmc: dw_mmc: Add exynos resume_noirq callback to
 clear WAKEUP_INT
In-Reply-To: <1373411961-23812-4-git-send-email-dianders@chromium.org>
References: <1373391071-6312-1-git-send-email-dianders@chromium.org>
 <1373411961-23812-1-git-send-email-dianders@chromium.org>
 <1373411961-23812-4-git-send-email-dianders@chromium.org>
Message-ID: <002a01ce7d7d$6bd9e870$438db950$%jun@samsung.com>

On Wed, July 10, 2013, Doug Anderson wrote:
> If the WAKEUP_INT is asserted at wakeup and not cleared, we'll end up
> looping around forever.  This has been seen to happen on exynos5420
> silicon despite the fact that we haven't enabled any wakeup events.
> 
> Signed-off-by: Doug Anderson <dianders at chromium.org>
> ---
> Changes in v2:
> - Use suspend_noirq as per James Hogan.
> 
>  drivers/mmc/host/dw_mmc-exynos.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
> index f013e7e..36b9620 100644
> --- a/drivers/mmc/host/dw_mmc-exynos.c
> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> @@ -30,6 +30,7 @@
>  #define SDMMC_CLKSEL_TIMING(x, y, z)	(SDMMC_CLKSEL_CCLK_SAMPLE(x) |	\
>  					SDMMC_CLKSEL_CCLK_DRIVE(y) |	\
>  					SDMMC_CLKSEL_CCLK_DIVIDER(z))
> +#define SDMMC_CLKSEL_WAKEUP_INT		BIT(11)
> 
>  #define SDMMC_CMD_USE_HOLD_REG		BIT(29)
> 
> @@ -102,6 +103,27 @@ static int dw_mci_exynos_setup_clock(struct dw_mci *host)
>  	return 0;
>  }
> 
> +/**
> + * dw_mci_exynos_resume_noirq - Exynos-specific resume code
> + *
> + * We have seen cases (at least on the exynos5420) where turning off the INT
> + * power rail during suspend will leave the WAKEUP_INT bit in the CLKSEL
> + * register asserted.  This bit is 1 to indicate that it fired and we can
> + * clear it by writing a 1 back.  Clear it to prevent interrupts from going off
> + * constantly.
> + */
As I know this bit is auto-cleared.
Did you find the cause of this problem?
How about your GPIO setting in sleep?
Currently, we don't know why the problem is happened.
At least, we should make it clear.

Thanks,
Seungwon Jeon

> +
> +static int dw_mci_exynos_resume_noirq(struct dw_mci *host)
> +{
> +	u32 clksel;
> +
> +	clksel = mci_readl(host, CLKSEL);
> +	if (clksel & SDMMC_CLKSEL_WAKEUP_INT)
> +		mci_writel(host, CLKSEL, clksel);
> +
> +	return 0;
> +}
> +
>  static void dw_mci_exynos_prepare_command(struct dw_mci *host, u32 *cmdr)
>  {
>  	/*
> @@ -165,6 +187,7 @@ static const struct dw_mci_drv_data exynos_drv_data = {
>  	.caps			= exynos_dwmmc_caps,
>  	.init			= dw_mci_exynos_priv_init,
>  	.setup_clock		= dw_mci_exynos_setup_clock,
> +	.resume_noirq		= dw_mci_exynos_resume_noirq,
>  	.prepare_command	= dw_mci_exynos_prepare_command,
>  	.set_ios		= dw_mci_exynos_set_ios,
>  	.parse_dt		= dw_mci_exynos_parse_dt,
> --
> 1.8.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From dianders at chromium.org  Wed Jul 10 11:05:01 2013
From: dianders at chromium.org (Doug Anderson)
Date: Wed, 10 Jul 2013 08:05:01 -0700
Subject: [PATCH v2 3/5] mmc: dw_mmc: Add exynos resume_noirq callback to
 clear WAKEUP_INT
In-Reply-To: <002a01ce7d7d$6bd9e870$438db950$%jun@samsung.com>
References: <1373391071-6312-1-git-send-email-dianders@chromium.org>
 <1373411961-23812-1-git-send-email-dianders@chromium.org>
 <1373411961-23812-4-git-send-email-dianders@chromium.org>
 <002a01ce7d7d$6bd9e870$438db950$%jun@samsung.com>
Message-ID: <CAD=FV=UtX0Z1ABdi5h270ks8Py2o1iPK4DonOHJH3N0Q1YShTQ@mail.gmail.com>

Seungwon,

On Wed, Jul 10, 2013 at 7:54 AM, Seungwon Jeon <tgih.jun at samsung.com> wrote:
> On Wed, July 10, 2013, Doug Anderson wrote:
>> If the WAKEUP_INT is asserted at wakeup and not cleared, we'll end up
>> looping around forever.  This has been seen to happen on exynos5420
>> silicon despite the fact that we haven't enabled any wakeup events.
>>
>> Signed-off-by: Doug Anderson <dianders at chromium.org>
>> ---
>> Changes in v2:
>> - Use suspend_noirq as per James Hogan.
>>
>>  drivers/mmc/host/dw_mmc-exynos.c | 23 +++++++++++++++++++++++
>>  1 file changed, 23 insertions(+)
>>
>> diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
>> index f013e7e..36b9620 100644
>> --- a/drivers/mmc/host/dw_mmc-exynos.c
>> +++ b/drivers/mmc/host/dw_mmc-exynos.c
>> @@ -30,6 +30,7 @@
>>  #define SDMMC_CLKSEL_TIMING(x, y, z) (SDMMC_CLKSEL_CCLK_SAMPLE(x) |  \
>>                                       SDMMC_CLKSEL_CCLK_DRIVE(y) |    \
>>                                       SDMMC_CLKSEL_CCLK_DIVIDER(z))
>> +#define SDMMC_CLKSEL_WAKEUP_INT              BIT(11)
>>
>>  #define SDMMC_CMD_USE_HOLD_REG               BIT(29)
>>
>> @@ -102,6 +103,27 @@ static int dw_mci_exynos_setup_clock(struct dw_mci *host)
>>       return 0;
>>  }
>>
>> +/**
>> + * dw_mci_exynos_resume_noirq - Exynos-specific resume code
>> + *
>> + * We have seen cases (at least on the exynos5420) where turning off the INT
>> + * power rail during suspend will leave the WAKEUP_INT bit in the CLKSEL
>> + * register asserted.  This bit is 1 to indicate that it fired and we can
>> + * clear it by writing a 1 back.  Clear it to prevent interrupts from going off
>> + * constantly.
>> + */
> As I know this bit is auto-cleared.
> Did you find the cause of this problem?
> How about your GPIO setting in sleep?
> Currently, we don't know why the problem is happened.
> At least, we should make it clear.

Yes, the documentation that I have says that this bit is "auto
cleared" as well but doesn't indicate under what conditions it is auto
cleared.  From testing how this bit reacts I have found that writing a
1 to it clears the bit--in other words it behaves like bits in
RINTSTS.  That's a terrible design for a bit in a register with shared
config but appears to be how it works.

Note: in a sense it will be "auto cleared" because doing a
read-modify-write of any other bits in this register will clear the
interrupt.

I have asked for official confirmation.

We have found that on exynos5420 bits 8-10 of CLKSEL are marked as
RESERVED.  Those bits are documented to enable the WAKEUP_INT on
exynos5250.  My best guess is that these bits are not used on
exynos5420 and the WAKEUP_INT line is left floating, which means it
can fire randomly.  I have also asked for official confirmation about
this.


I will likely merge this change locally in our kernel tree while
waiting for a response.  If you would like to wait before Acking
that's very reasonable.  Do you have any other problems with this
change assuming my understanding above is correct?

-Doug


From shawn.guo at linaro.org  Wed Jul 10 11:21:59 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 10 Jul 2013 23:21:59 +0800
Subject: [PATCH 0/3] ARM: imx6: fix up buggy CCM_CSCMR1 register
Message-ID: <1373469722-32514-1-git-send-email-shawn.guo@linaro.org>

There is a defect in bits 22 and 21 of i.MX6 CCM_CSCMR1 register.  These
two bits are inverted between read and write.  That said, bit field
CCM_CSCMR1[22-20] (aclk/emi_podf on imx6q/dl and lcdif_pix_podf on
imx6sl) will be something as below between read and write.

  read    write    divider
   000     110       1
   001     111       2
   010     100       3
   011     101       4
   100     010       5
   101     011       6
   110     000       7
   111     001       8

To work around this hardware defect, every single read/modify/write
sequence on the register will require a fix-up (invert bits 22 and 21)
before writing the value into register.  As there are dividers and
multiplexers defined in the register, we choose to inherit the basic
clk-divider and clk-mux and override the functions which writes register
with a fix-up hooked in.

Shawn

Liu Ying (3):
  ARM: imx: add common clock support for fixup div
  ARM: imx: add common clock support for fixup mux
  ARM: imx6: change some clocks to fixup clocks

 arch/arm/mach-imx/Makefile        |    3 +-
 arch/arm/mach-imx/clk-fixup-div.c |  129 +++++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/clk-fixup-mux.c |  107 ++++++++++++++++++++++++++++++
 arch/arm/mach-imx/clk-imx6q.c     |   24 +++----
 arch/arm/mach-imx/clk-imx6sl.c    |   20 +++---
 arch/arm/mach-imx/clk.c           |   26 ++++++++
 arch/arm/mach-imx/clk.h           |   10 +++
 7 files changed, 296 insertions(+), 23 deletions(-)
 create mode 100644 arch/arm/mach-imx/clk-fixup-div.c
 create mode 100644 arch/arm/mach-imx/clk-fixup-mux.c

-- 
1.7.9.5




From shawn.guo at linaro.org  Wed Jul 10 11:22:02 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 10 Jul 2013 23:22:02 +0800
Subject: [PATCH 3/3] ARM: imx6: change some clocks to fixup clocks
In-Reply-To: <1373469722-32514-1-git-send-email-shawn.guo@linaro.org>
References: <1373469722-32514-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1373469722-32514-4-git-send-email-shawn.guo@linaro.org>

From: Liu Ying <Ying.Liu at freescale.com>

All the clocks controlled by the register 'CCM Serial Clock
Multiplexer Register 1' should be fixup clocks. This patch
changes those clocks from basic multiplexer or divider clocks
to fixup clocks.

Signed-off-by: Liu Ying <Ying.Liu at freescale.com>
Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/mach-imx/clk-imx6q.c  |   24 ++++++++++++------------
 arch/arm/mach-imx/clk-imx6sl.c |   20 ++++++++++----------
 arch/arm/mach-imx/clk.c        |   26 ++++++++++++++++++++++++++
 arch/arm/mach-imx/clk.h        |    2 ++
 4 files changed, 50 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 82a85ce..db9f8f5 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -384,16 +384,16 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[ipu2_di1_sel]     = imx_clk_mux("ipu2_di1_sel",     base + 0x38, 9,  3, ipu2_di1_sels,     ARRAY_SIZE(ipu2_di1_sels));
 	clk[hsi_tx_sel]       = imx_clk_mux("hsi_tx_sel",       base + 0x30, 28, 1, hsi_tx_sels,       ARRAY_SIZE(hsi_tx_sels));
 	clk[pcie_axi_sel]     = imx_clk_mux("pcie_axi_sel",     base + 0x18, 10, 1, pcie_axi_sels,     ARRAY_SIZE(pcie_axi_sels));
-	clk[ssi1_sel]         = imx_clk_mux("ssi1_sel",         base + 0x1c, 10, 2, ssi_sels,          ARRAY_SIZE(ssi_sels));
-	clk[ssi2_sel]         = imx_clk_mux("ssi2_sel",         base + 0x1c, 12, 2, ssi_sels,          ARRAY_SIZE(ssi_sels));
-	clk[ssi3_sel]         = imx_clk_mux("ssi3_sel",         base + 0x1c, 14, 2, ssi_sels,          ARRAY_SIZE(ssi_sels));
-	clk[usdhc1_sel]       = imx_clk_mux("usdhc1_sel",       base + 0x1c, 16, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels));
-	clk[usdhc2_sel]       = imx_clk_mux("usdhc2_sel",       base + 0x1c, 17, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels));
-	clk[usdhc3_sel]       = imx_clk_mux("usdhc3_sel",       base + 0x1c, 18, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels));
-	clk[usdhc4_sel]       = imx_clk_mux("usdhc4_sel",       base + 0x1c, 19, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels));
+	clk[ssi1_sel]         = imx_clk_fixup_mux("ssi1_sel",   base + 0x1c, 10, 2, ssi_sels,          ARRAY_SIZE(ssi_sels),          imx_cscmr1_fixup);
+	clk[ssi2_sel]         = imx_clk_fixup_mux("ssi2_sel",   base + 0x1c, 12, 2, ssi_sels,          ARRAY_SIZE(ssi_sels),          imx_cscmr1_fixup);
+	clk[ssi3_sel]         = imx_clk_fixup_mux("ssi3_sel",   base + 0x1c, 14, 2, ssi_sels,          ARRAY_SIZE(ssi_sels),          imx_cscmr1_fixup);
+	clk[usdhc1_sel]       = imx_clk_fixup_mux("usdhc1_sel", base + 0x1c, 16, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels),        imx_cscmr1_fixup);
+	clk[usdhc2_sel]       = imx_clk_fixup_mux("usdhc2_sel", base + 0x1c, 17, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels),        imx_cscmr1_fixup);
+	clk[usdhc3_sel]       = imx_clk_fixup_mux("usdhc3_sel", base + 0x1c, 18, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels),        imx_cscmr1_fixup);
+	clk[usdhc4_sel]       = imx_clk_fixup_mux("usdhc4_sel", base + 0x1c, 19, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels),        imx_cscmr1_fixup);
 	clk[enfc_sel]         = imx_clk_mux("enfc_sel",         base + 0x2c, 16, 2, enfc_sels,         ARRAY_SIZE(enfc_sels));
-	clk[emi_sel]          = imx_clk_mux("emi_sel",          base + 0x1c, 27, 2, emi_sels,          ARRAY_SIZE(emi_sels));
-	clk[emi_slow_sel]     = imx_clk_mux("emi_slow_sel",     base + 0x1c, 29, 2, emi_slow_sels,     ARRAY_SIZE(emi_slow_sels));
+	clk[emi_sel]          = imx_clk_fixup_mux("emi_sel",      base + 0x1c, 27, 2, emi_sels,        ARRAY_SIZE(emi_sels),          imx_cscmr1_fixup);
+	clk[emi_slow_sel]     = imx_clk_fixup_mux("emi_slow_sel", base + 0x1c, 29, 2, emi_slow_sels,   ARRAY_SIZE(emi_slow_sels),     imx_cscmr1_fixup);
 	clk[vdo_axi_sel]      = imx_clk_mux("vdo_axi_sel",      base + 0x18, 11, 1, vdo_axi_sels,      ARRAY_SIZE(vdo_axi_sels));
 	clk[vpu_axi_sel]      = imx_clk_mux("vpu_axi_sel",      base + 0x18, 14, 2, vpu_axi_sels,      ARRAY_SIZE(vpu_axi_sels));
 	clk[cko1_sel]         = imx_clk_mux("cko1_sel",         base + 0x60, 0,  4, cko1_sels,         ARRAY_SIZE(cko1_sels));
@@ -406,7 +406,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[periph_clk2]      = imx_clk_divider("periph_clk2",      "periph_clk2_sel",   base + 0x14, 27, 3);
 	clk[periph2_clk2]     = imx_clk_divider("periph2_clk2",     "periph2_clk2_sel",  base + 0x14, 0,  3);
 	clk[ipg]              = imx_clk_divider("ipg",              "ahb",               base + 0x14, 8,  2);
-	clk[ipg_per]          = imx_clk_divider("ipg_per",          "ipg",               base + 0x1c, 0,  6);
+	clk[ipg_per]          = imx_clk_fixup_divider("ipg_per",    "ipg",               base + 0x1c, 0,  6, imx_cscmr1_fixup);
 	clk[esai_pred]        = imx_clk_divider("esai_pred",        "esai_sel",          base + 0x28, 9,  3);
 	clk[esai_podf]        = imx_clk_divider("esai_podf",        "esai_pred",         base + 0x28, 25, 3);
 	clk[asrc_pred]        = imx_clk_divider("asrc_pred",        "asrc_sel",          base + 0x30, 12, 3);
@@ -442,8 +442,8 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[usdhc4_podf]      = imx_clk_divider("usdhc4_podf",      "usdhc4_sel",        base + 0x24, 22, 3);
 	clk[enfc_pred]        = imx_clk_divider("enfc_pred",        "enfc_sel",          base + 0x2c, 18, 3);
 	clk[enfc_podf]        = imx_clk_divider("enfc_podf",        "enfc_pred",         base + 0x2c, 21, 6);
-	clk[emi_podf]         = imx_clk_divider("emi_podf",         "emi_sel",           base + 0x1c, 20, 3);
-	clk[emi_slow_podf]    = imx_clk_divider("emi_slow_podf",    "emi_slow_sel",      base + 0x1c, 23, 3);
+	clk[emi_podf]         = imx_clk_fixup_divider("emi_podf",   "emi_sel",           base + 0x1c, 20, 3, imx_cscmr1_fixup);
+	clk[emi_slow_podf]    = imx_clk_fixup_divider("emi_slow_podf", "emi_slow_sel",   base + 0x1c, 23, 3, imx_cscmr1_fixup);
 	clk[vpu_axi_podf]     = imx_clk_divider("vpu_axi_podf",     "vpu_axi_sel",       base + 0x24, 25, 3);
 	clk[cko1_podf]        = imx_clk_divider("cko1_podf",        "cko1_sel",          base + 0x60, 4,  3);
 
diff --git a/arch/arm/mach-imx/clk-imx6sl.c b/arch/arm/mach-imx/clk-imx6sl.c
index a307ac2..a5c3c5d 100644
--- a/arch/arm/mach-imx/clk-imx6sl.c
+++ b/arch/arm/mach-imx/clk-imx6sl.c
@@ -138,14 +138,14 @@ static void __init imx6sl_clocks_init(struct device_node *ccm_node)
 	clks[IMX6SL_CLK_PERIPH_CLK2_SEL]  = imx_clk_mux("periph_clk2_sel",  base + 0x18, 12, 2, periph_clk2_sels,  ARRAY_SIZE(periph_clk2_sels));
 	clks[IMX6SL_CLK_CSI_SEL]          = imx_clk_mux("csi_sel",          base + 0x3c, 9,  2, csi_lcdif_sels,    ARRAY_SIZE(csi_lcdif_sels));
 	clks[IMX6SL_CLK_LCDIF_AXI_SEL]    = imx_clk_mux("lcdif_axi_sel",    base + 0x3c, 14, 2, csi_lcdif_sels,    ARRAY_SIZE(csi_lcdif_sels));
-	clks[IMX6SL_CLK_USDHC1_SEL]       = imx_clk_mux("usdhc1_sel",       base + 0x1c, 16, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels));
-	clks[IMX6SL_CLK_USDHC2_SEL]       = imx_clk_mux("usdhc2_sel",       base + 0x1c, 17, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels));
-	clks[IMX6SL_CLK_USDHC3_SEL]       = imx_clk_mux("usdhc3_sel",       base + 0x1c, 18, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels));
-	clks[IMX6SL_CLK_USDHC4_SEL]       = imx_clk_mux("usdhc4_sel",       base + 0x1c, 19, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels));
-	clks[IMX6SL_CLK_SSI1_SEL]         = imx_clk_mux("ssi1_sel",         base + 0x1c, 10, 2, ssi_sels,          ARRAY_SIZE(ssi_sels));
-	clks[IMX6SL_CLK_SSI2_SEL]         = imx_clk_mux("ssi2_sel",         base + 0x1c, 12, 2, ssi_sels,          ARRAY_SIZE(ssi_sels));
-	clks[IMX6SL_CLK_SSI3_SEL]         = imx_clk_mux("ssi3_sel",         base + 0x1c, 14, 2, ssi_sels,          ARRAY_SIZE(ssi_sels));
-	clks[IMX6SL_CLK_PERCLK_SEL]       = imx_clk_mux("perclk_sel",       base + 0x1c, 6,  1, perclk_sels,       ARRAY_SIZE(perclk_sels));
+	clks[IMX6SL_CLK_USDHC1_SEL]       = imx_clk_fixup_mux("usdhc1_sel", base + 0x1c, 16, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels),  imx_cscmr1_fixup);
+	clks[IMX6SL_CLK_USDHC2_SEL]       = imx_clk_fixup_mux("usdhc2_sel", base + 0x1c, 17, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels),  imx_cscmr1_fixup);
+	clks[IMX6SL_CLK_USDHC3_SEL]       = imx_clk_fixup_mux("usdhc3_sel", base + 0x1c, 18, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels),  imx_cscmr1_fixup);
+	clks[IMX6SL_CLK_USDHC4_SEL]       = imx_clk_fixup_mux("usdhc4_sel", base + 0x1c, 19, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels),  imx_cscmr1_fixup);
+	clks[IMX6SL_CLK_SSI1_SEL]         = imx_clk_fixup_mux("ssi1_sel",   base + 0x1c, 10, 2, ssi_sels,          ARRAY_SIZE(ssi_sels),    imx_cscmr1_fixup);
+	clks[IMX6SL_CLK_SSI2_SEL]         = imx_clk_fixup_mux("ssi2_sel",   base + 0x1c, 12, 2, ssi_sels,          ARRAY_SIZE(ssi_sels),    imx_cscmr1_fixup);
+	clks[IMX6SL_CLK_SSI3_SEL]         = imx_clk_fixup_mux("ssi3_sel",   base + 0x1c, 14, 2, ssi_sels,          ARRAY_SIZE(ssi_sels),    imx_cscmr1_fixup);
+	clks[IMX6SL_CLK_PERCLK_SEL]       = imx_clk_fixup_mux("perclk_sel", base + 0x1c, 6,  1, perclk_sels,       ARRAY_SIZE(perclk_sels), imx_cscmr1_fixup);
 	clks[IMX6SL_CLK_PXP_AXI_SEL]      = imx_clk_mux("pxp_axi_sel",      base + 0x34, 6,  3, epdc_pxp_sels,     ARRAY_SIZE(epdc_pxp_sels));
 	clks[IMX6SL_CLK_EPDC_AXI_SEL]     = imx_clk_mux("epdc_axi_sel",     base + 0x34, 15, 3, epdc_pxp_sels,     ARRAY_SIZE(epdc_pxp_sels));
 	clks[IMX6SL_CLK_GPU2D_OVG_SEL]    = imx_clk_mux("gpu2d_ovg_sel",    base + 0x18, 4,  2, gpu2d_ovg_sels,    ARRAY_SIZE(gpu2d_ovg_sels));
@@ -179,14 +179,14 @@ static void __init imx6sl_clocks_init(struct device_node *ccm_node)
 	clks[IMX6SL_CLK_SSI2_PODF]         = imx_clk_divider("ssi2_podf",         "ssi2_pred",         base + 0x2c, 0,  6);
 	clks[IMX6SL_CLK_SSI3_PRED]         = imx_clk_divider("ssi3_pred",         "ssi3_sel",          base + 0x28, 22, 3);
 	clks[IMX6SL_CLK_SSI3_PODF]         = imx_clk_divider("ssi3_podf",         "ssi3_pred",         base + 0x28, 16, 6);
-	clks[IMX6SL_CLK_PERCLK]            = imx_clk_divider("perclk",            "perclk_sel",        base + 0x1c, 0,  6);
+	clks[IMX6SL_CLK_PERCLK]            = imx_clk_fixup_divider("perclk",      "perclk_sel",        base + 0x1c, 0,  6, imx_cscmr1_fixup);
 	clks[IMX6SL_CLK_PXP_AXI_PODF]      = imx_clk_divider("pxp_axi_podf",      "pxp_axi_sel",       base + 0x34, 3,  3);
 	clks[IMX6SL_CLK_EPDC_AXI_PODF]     = imx_clk_divider("epdc_axi_podf",     "epdc_axi_sel",      base + 0x34, 12, 3);
 	clks[IMX6SL_CLK_GPU2D_OVG_PODF]    = imx_clk_divider("gpu2d_ovg_podf",    "gpu2d_ovg_sel",     base + 0x18, 26, 3);
 	clks[IMX6SL_CLK_GPU2D_PODF]        = imx_clk_divider("gpu2d_podf",        "gpu2d_sel",         base + 0x18, 29, 3);
 	clks[IMX6SL_CLK_LCDIF_PIX_PRED]    = imx_clk_divider("lcdif_pix_pred",    "lcdif_pix_sel",     base + 0x38, 3,  3);
 	clks[IMX6SL_CLK_EPDC_PIX_PRED]     = imx_clk_divider("epdc_pix_pred",     "epdc_pix_sel",      base + 0x38, 12, 3);
-	clks[IMX6SL_CLK_LCDIF_PIX_PODF]    = imx_clk_divider("lcdif_pix_podf",    "lcdif_pix_pred",    base + 0x1c, 20, 3);
+	clks[IMX6SL_CLK_LCDIF_PIX_PODF]    = imx_clk_fixup_divider("lcdif_pix_podf", "lcdif_pix_pred", base + 0x1c, 20, 3, imx_cscmr1_fixup);
 	clks[IMX6SL_CLK_EPDC_PIX_PODF]     = imx_clk_divider("epdc_pix_podf",     "epdc_pix_pred",     base + 0x18, 23, 3);
 	clks[IMX6SL_CLK_SPDIF0_PRED]       = imx_clk_divider("spdif0_pred",       "spdif0_sel",        base + 0x30, 25, 3);
 	clks[IMX6SL_CLK_SPDIF0_PODF]       = imx_clk_divider("spdif0_podf",       "spdif0_pred",       base + 0x30, 22, 3);
diff --git a/arch/arm/mach-imx/clk.c b/arch/arm/mach-imx/clk.c
index 55bc80a..edc35df 100644
--- a/arch/arm/mach-imx/clk.c
+++ b/arch/arm/mach-imx/clk.c
@@ -37,3 +37,29 @@ struct clk * __init imx_obtain_fixed_clock(
 		clk = imx_clk_fixed(name, rate);
 	return clk;
 }
+
+/*
+ * This fixups the register CCM_CSCMR1 write value.
+ * The write/read/divider values of the aclk_podf field
+ * of that register have the relationship described by
+ * the following table:
+ *
+ * write value       read value        divider
+ * 3b'000            3b'110            7
+ * 3b'001            3b'111            8
+ * 3b'010            3b'100            5
+ * 3b'011            3b'101            6
+ * 3b'100            3b'010            3
+ * 3b'101            3b'011            4
+ * 3b'110            3b'000            1
+ * 3b'111            3b'001            2(default)
+ *
+ * That's why we do the xor operation below.
+ */
+#define CSCMR1_FIXUP	0x00600000
+
+void imx_cscmr1_fixup(u32 *val)
+{
+	*val ^= CSCMR1_FIXUP;
+	return;
+}
diff --git a/arch/arm/mach-imx/clk.h b/arch/arm/mach-imx/clk.h
index 2534359..3451f1f 100644
--- a/arch/arm/mach-imx/clk.h
+++ b/arch/arm/mach-imx/clk.h
@@ -6,6 +6,8 @@
 
 extern spinlock_t imx_ccm_lock;
 
+extern void imx_cscmr1_fixup(u32 *val);
+
 struct clk *imx_clk_pllv1(const char *name, const char *parent,
 		void __iomem *base);
 
-- 
1.7.9.5




From shawn.guo at linaro.org  Wed Jul 10 11:22:00 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 10 Jul 2013 23:22:00 +0800
Subject: [PATCH 1/3] ARM: imx: add common clock support for fixup div
In-Reply-To: <1373469722-32514-1-git-send-email-shawn.guo@linaro.org>
References: <1373469722-32514-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1373469722-32514-2-git-send-email-shawn.guo@linaro.org>

From: Liu Ying <Ying.Liu at freescale.com>

One register may have several fields to control some clocks. It
is possible that the read/write values of some fields may map to
different real functional values, so writing to the other fields
in the same register may break a working clock tree. A real case
is the aclk_podf field in the register 'CCM Serial Clock Multiplexer
Register 1' of i.MX6Q/SDL SoC. This patch introduces a fixup hook
for divider clock which is called before writing a value to clock
registers to support this kind of divider clocks.

Signed-off-by: Liu Ying <Ying.Liu at freescale.com>
Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/mach-imx/Makefile        |    3 +-
 arch/arm/mach-imx/clk-fixup-div.c |  129 +++++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/clk.h           |    4 ++
 3 files changed, 135 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-imx/clk-fixup-div.c

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index e20f22d..92b91a2 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -15,7 +15,8 @@ imx5-pm-$(CONFIG_PM) += pm-imx5.o
 obj-$(CONFIG_SOC_IMX5) += cpu-imx5.o mm-imx5.o clk-imx51-imx53.o ehci-imx5.o $(imx5-pm-y)
 
 obj-$(CONFIG_COMMON_CLK) += clk-pllv1.o clk-pllv2.o clk-pllv3.o clk-gate2.o \
-			    clk-pfd.o clk-busy.o clk.o
+			    clk-pfd.o clk-busy.o clk.o \
+			    clk-fixup-div.o
 
 obj-$(CONFIG_IMX_HAVE_IOMUX_V1) += iomux-v1.o
 obj-$(CONFIG_ARCH_MXC_IOMUX_V3) += iomux-v3.o
diff --git a/arch/arm/mach-imx/clk-fixup-div.c b/arch/arm/mach-imx/clk-fixup-div.c
new file mode 100644
index 0000000..21db020
--- /dev/null
+++ b/arch/arm/mach-imx/clk-fixup-div.c
@@ -0,0 +1,129 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include "clk.h"
+
+#define to_clk_div(_hw) container_of(_hw, struct clk_divider, hw)
+#define div_mask(d)	((1 << (d->width)) - 1)
+
+/**
+ * struct clk_fixup_div - imx integer fixup divider clock
+ * @divider: the parent class
+ * @ops: pointer to clk_ops of parent class
+ * @fixup: a hook to fixup the write value
+ *
+ * The imx fixup divider clock is a subclass of basic clk_divider
+ * with an addtional fixup hook.
+ */
+struct clk_fixup_div {
+	struct clk_divider divider;
+	const struct clk_ops *ops;
+	void (*fixup)(u32 *val);
+};
+
+static inline struct clk_fixup_div *to_clk_fixup_div(struct clk_hw *hw)
+{
+	struct clk_divider *divider = to_clk_div(hw);
+
+	return container_of(divider, struct clk_fixup_div, divider);
+}
+
+static unsigned long clk_fixup_div_recalc_rate(struct clk_hw *hw,
+					 unsigned long parent_rate)
+{
+	struct clk_fixup_div *fixup_div = to_clk_fixup_div(hw);
+
+	return fixup_div->ops->recalc_rate(&fixup_div->divider.hw, parent_rate);
+}
+
+static long clk_fixup_div_round_rate(struct clk_hw *hw, unsigned long rate,
+			       unsigned long *prate)
+{
+	struct clk_fixup_div *fixup_div = to_clk_fixup_div(hw);
+
+	return fixup_div->ops->round_rate(&fixup_div->divider.hw, rate, prate);
+}
+
+static int clk_fixup_div_set_rate(struct clk_hw *hw, unsigned long rate,
+			    unsigned long parent_rate)
+{
+	struct clk_fixup_div *fixup_div = to_clk_fixup_div(hw);
+	struct clk_divider *div = to_clk_div(hw);
+	unsigned int divider, value;
+	unsigned long flags = 0;
+	u32 val;
+
+	divider = parent_rate / rate;
+
+	/* Zero based divider */
+	value = divider - 1;
+
+	if (value > div_mask(div))
+		value = div_mask(div);
+
+	spin_lock_irqsave(div->lock, flags);
+
+	val = readl(div->reg);
+	val &= ~(div_mask(div) << div->shift);
+	val |= value << div->shift;
+	fixup_div->fixup(&val);
+	writel(val, div->reg);
+
+	spin_unlock_irqrestore(div->lock, flags);
+
+	return 0;
+}
+
+static const struct clk_ops clk_fixup_div_ops = {
+	.recalc_rate = clk_fixup_div_recalc_rate,
+	.round_rate = clk_fixup_div_round_rate,
+	.set_rate = clk_fixup_div_set_rate,
+};
+
+struct clk *imx_clk_fixup_divider(const char *name, const char *parent,
+				  void __iomem *reg, u8 shift, u8 width,
+				  void (*fixup)(u32 *val))
+{
+	struct clk_fixup_div *fixup_div;
+	struct clk *clk;
+	struct clk_init_data init;
+
+	if (!fixup)
+		return ERR_PTR(-EINVAL);
+
+	fixup_div = kzalloc(sizeof(*fixup_div), GFP_KERNEL);
+	if (!fixup_div)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &clk_fixup_div_ops;
+	init.flags = CLK_SET_RATE_PARENT;
+	init.parent_names = parent ? &parent : NULL;
+	init.num_parents = parent ? 1 : 0;
+
+	fixup_div->divider.reg = reg;
+	fixup_div->divider.shift = shift;
+	fixup_div->divider.width = width;
+	fixup_div->divider.lock = &imx_ccm_lock;
+	fixup_div->divider.hw.init = &init;
+	fixup_div->ops = &clk_divider_ops;
+	fixup_div->fixup = fixup;
+
+	clk = clk_register(NULL, &fixup_div->divider.hw);
+	if (IS_ERR(clk))
+		kfree(fixup_div);
+
+	return clk;
+}
diff --git a/arch/arm/mach-imx/clk.h b/arch/arm/mach-imx/clk.h
index 0e4e8bb..51eb3853 100644
--- a/arch/arm/mach-imx/clk.h
+++ b/arch/arm/mach-imx/clk.h
@@ -49,6 +49,10 @@ struct clk *imx_clk_busy_mux(const char *name, void __iomem *reg, u8 shift,
 			     u8 width, void __iomem *busy_reg, u8 busy_shift,
 			     const char **parent_names, int num_parents);
 
+struct clk *imx_clk_fixup_divider(const char *name, const char *parent,
+				  void __iomem *reg, u8 shift, u8 width,
+				  void (*fixup)(u32 *val));
+
 static inline struct clk *imx_clk_fixed(const char *name, int rate)
 {
 	return clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
-- 
1.7.9.5




From shawn.guo at linaro.org  Wed Jul 10 11:22:01 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 10 Jul 2013 23:22:01 +0800
Subject: [PATCH 2/3] ARM: imx: add common clock support for fixup mux
In-Reply-To: <1373469722-32514-1-git-send-email-shawn.guo@linaro.org>
References: <1373469722-32514-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1373469722-32514-3-git-send-email-shawn.guo@linaro.org>

From: Liu Ying <Ying.Liu at freescale.com>

One register may have several fields to control some clocks. It
is possible that the read/write values of some fields may map to
different real functional values, so writing to the other fields
in the same register may break a working clock tree. A real case
is the aclk_podf field in the register 'CCM Serial Clock Multiplexer
Register 1' of i.MX6Q/SDL SoC. This patch introduces a fixup hook
for multiplexer clock which is called before writing a value to
clock registers to support this kind of multiplexer clocks.

Signed-off-by: Liu Ying <Ying.Liu at freescale.com>
Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/mach-imx/Makefile        |    2 +-
 arch/arm/mach-imx/clk-fixup-mux.c |  107 +++++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/clk.h           |    4 ++
 3 files changed, 112 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-imx/clk-fixup-mux.c

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 92b91a2..5383c58 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -16,7 +16,7 @@ obj-$(CONFIG_SOC_IMX5) += cpu-imx5.o mm-imx5.o clk-imx51-imx53.o ehci-imx5.o $(i
 
 obj-$(CONFIG_COMMON_CLK) += clk-pllv1.o clk-pllv2.o clk-pllv3.o clk-gate2.o \
 			    clk-pfd.o clk-busy.o clk.o \
-			    clk-fixup-div.o
+			    clk-fixup-div.o clk-fixup-mux.o
 
 obj-$(CONFIG_IMX_HAVE_IOMUX_V1) += iomux-v1.o
 obj-$(CONFIG_ARCH_MXC_IOMUX_V3) += iomux-v3.o
diff --git a/arch/arm/mach-imx/clk-fixup-mux.c b/arch/arm/mach-imx/clk-fixup-mux.c
new file mode 100644
index 0000000..deb4b80
--- /dev/null
+++ b/arch/arm/mach-imx/clk-fixup-mux.c
@@ -0,0 +1,107 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include "clk.h"
+
+#define to_clk_mux(_hw) container_of(_hw, struct clk_mux, hw)
+
+/**
+ * struct clk_fixup_mux - imx integer fixup multiplexer clock
+ * @mux: the parent class
+ * @ops: pointer to clk_ops of parent class
+ * @fixup: a hook to fixup the write value
+ *
+ * The imx fixup multiplexer clock is a subclass of basic clk_mux
+ * with an addtional fixup hook.
+ */
+struct clk_fixup_mux {
+	struct clk_mux mux;
+	const struct clk_ops *ops;
+	void (*fixup)(u32 *val);
+};
+
+static inline struct clk_fixup_mux *to_clk_fixup_mux(struct clk_hw *hw)
+{
+	struct clk_mux *mux = to_clk_mux(hw);
+
+	return container_of(mux, struct clk_fixup_mux, mux);
+}
+
+static u8 clk_fixup_mux_get_parent(struct clk_hw *hw)
+{
+	struct clk_fixup_mux *fixup_mux = to_clk_fixup_mux(hw);
+
+	return fixup_mux->ops->get_parent(&fixup_mux->mux.hw);
+}
+
+static int clk_fixup_mux_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct clk_fixup_mux *fixup_mux = to_clk_fixup_mux(hw);
+	struct clk_mux *mux = to_clk_mux(hw);
+	unsigned long flags = 0;
+	u32 val;
+
+	spin_lock_irqsave(mux->lock, flags);
+
+	val = readl(mux->reg);
+	val &= ~(mux->mask << mux->shift);
+	val |= index << mux->shift;
+	fixup_mux->fixup(&val);
+	writel(val, mux->reg);
+
+	spin_unlock_irqrestore(mux->lock, flags);
+
+	return 0;
+}
+
+static const struct clk_ops clk_fixup_mux_ops = {
+	.get_parent = clk_fixup_mux_get_parent,
+	.set_parent = clk_fixup_mux_set_parent,
+};
+
+struct clk *imx_clk_fixup_mux(const char *name, void __iomem *reg,
+			      u8 shift, u8 width, const char **parents,
+			      int num_parents, void (*fixup)(u32 *val))
+{
+	struct clk_fixup_mux *fixup_mux;
+	struct clk *clk;
+	struct clk_init_data init;
+
+	if (!fixup)
+		return ERR_PTR(-EINVAL);
+
+	fixup_mux = kzalloc(sizeof(*fixup_mux), GFP_KERNEL);
+	if (!fixup_mux)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &clk_fixup_mux_ops;
+	init.parent_names = parents;
+	init.num_parents = num_parents;
+
+	fixup_mux->mux.reg = reg;
+	fixup_mux->mux.shift = shift;
+	fixup_mux->mux.mask = BIT(width) - 1;
+	fixup_mux->mux.lock = &imx_ccm_lock;
+	fixup_mux->mux.hw.init = &init;
+	fixup_mux->ops = &clk_mux_ops;
+	fixup_mux->fixup = fixup;
+
+	clk = clk_register(NULL, &fixup_mux->mux.hw);
+	if (IS_ERR(clk))
+		kfree(fixup_mux);
+
+	return clk;
+}
diff --git a/arch/arm/mach-imx/clk.h b/arch/arm/mach-imx/clk.h
index 51eb3853..2534359 100644
--- a/arch/arm/mach-imx/clk.h
+++ b/arch/arm/mach-imx/clk.h
@@ -53,6 +53,10 @@ struct clk *imx_clk_fixup_divider(const char *name, const char *parent,
 				  void __iomem *reg, u8 shift, u8 width,
 				  void (*fixup)(u32 *val));
 
+struct clk *imx_clk_fixup_mux(const char *name, void __iomem *reg,
+			      u8 shift, u8 width, const char **parents,
+			      int num_parents, void (*fixup)(u32 *val));
+
 static inline struct clk *imx_clk_fixed(const char *name, int rate)
 {
 	return clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
-- 
1.7.9.5




From LW at KARO-electronics.de  Wed Jul 10 11:29:26 2013
From: LW at KARO-electronics.de (=?utf-8?Q?Lothar_Wa=C3=9Fmann?=)
Date: Wed, 10 Jul 2013 17:29:26 +0200
Subject: [PATCH V2 01/12] spi/mxs: Always set LOCK_CS
In-Reply-To: <CAOMZO5AEU3D3o-8fKLQJvsRSwBMNn0jfwZFC6R93TKaUpxffSw@mail.gmail.com>
References: <1364905195-24286-1-git-send-email-tpiepho@gmail.com>
 <201304030118.42976.marex@denx.de>
 <CAOMZO5AEU3D3o-8fKLQJvsRSwBMNn0jfwZFC6R93TKaUpxffSw@mail.gmail.com>
Message-ID: <20957.32214.721252.361301@ipc1.ka-ro>

Hi,

Fabio Estevam writes:
> On Tue, Apr 2, 2013 at 8:18 PM, Marek Vasut <marex at denx.de> wrote:
> > Dear Trent Piepho,
> >
> >> There are two bits which control the CS line in the CTRL0 register:
> >> LOCK_CS and IGNORE_CRC.  The latter would be better named DEASSERT_CS
> >> in SPI mode.
> >>
> >> LOCK_CS keeps CS asserted though the entire transfer.  This should
> >> always be set.  The DMA code will always set it, explicitly on the
> >> first segment of the first transfer, and then implicitly on all the
> >> rest by never clearing the bit from the value read from the ctrl0
> >> register.
> >>
> >> The only reason to not set LOCK_CS would be to attempt an altered
> >> protocol where CS pulses between each word.  Though don't get your
> >> hopes up if you want to do this, as the hardware doesn't appear to do
> >> this in any sane manner.
> >
> > Can you please elaborate on this part above? The description is very vague.
> >
>From my experience the HW deasserts CS whenever the output fifo runs
empty.


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________


From ohad at wizery.com  Wed Jul 10 11:29:44 2013
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Wed, 10 Jul 2013 18:29:44 +0300
Subject: [GIT PULL] remoteproc fixes
In-Reply-To: <CAK=WgbbJesp2Yg0mXOyxzhnQxwvoNLdt7GsY5v2yN+SAc2=WZQ@mail.gmail.com>
References: <CAK=WgbbJesp2Yg0mXOyxzhnQxwvoNLdt7GsY5v2yN+SAc2=WZQ@mail.gmail.com>
Message-ID: <CAK=WgbYHzYdSsuFa0K=q8iUS3ykXy-5=XifxweCx8Uqrg-CYAg@mail.gmail.com>

With the lists this time

On Wed, Jul 10, 2013 at 6:17 PM, Ohad Ben-Cohen <ohad at wizery.com> wrote:
> The following changes since commit 9e895ace5d82df8929b16f58e9f515f6d54ab82d:
>
>   Linux 3.10-rc7 (2013-06-22 09:47:31 -1000)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
> tags/remoteproc-3.11-fixes
>
> for you to fetch changes up to 95cee62cb4776a65229a6b6d5969be56589d95c1:
>
>   remoteproc: Cocci spatch "memdup.spatch" (2013-07-01 17:23:58 +0300)
>
> ----------------------------------------------------------------
> Trivial remoteproc fixes by Suman Anna, Wei Yongjun and Thomas Meyer.
>
> ----------------------------------------------------------------
> Suman Anna (3):
>       remoteproc: fix checkpatch errors in remoteproc code
>       remoteproc/omap: fix a sparse warning
>       remoteproc: free carveout memories only after unmapping them
>
> Thomas Meyer (1):
>       remoteproc: Cocci spatch "memdup.spatch"
>
> Wei Yongjun (1):
>       remoteproc: fix error return code in rproc_fw_boot()
>
>  drivers/remoteproc/remoteproc_core.c          | 24 ++++++++++++------------
>  drivers/remoteproc/remoteproc_debugfs.c       |  3 +--
>  drivers/remoteproc/remoteproc_internal.h      |  4 ++--
>  include/linux/platform_data/remoteproc-omap.h |  2 +-
>  4 files changed, 16 insertions(+), 17 deletions(-)


From fabio.estevam at freescale.com  Wed Jul 10 11:30:16 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Wed, 10 Jul 2013 12:30:16 -0300
Subject: [PATCH v3] ARM: imx: Select MIGHT_HAVE_CACHE_L2X0
Message-ID: <1373470216-12996-1-git-send-email-fabio.estevam@freescale.com>

Select MIGHT_HAVE_CACHE_L2X0 for armv6 and armv7 i.MX SoCs.

By selecting MIGHT_HAVE_CACHE_L2X0, the user still has the possibility to 
disable CACHE_L2X0 selection via menuconfig.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v2:
- Simplify the Kconfig
Changes since v1:
- Use MIGHT_HAVE_CACHE_L2X0 instead of CACHE_L2X0, to allow users to still
disable L2 cache via menuconfig if they want to
- Also select L2 cache for vf610

 arch/arm/mach-imx/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index f546560..f7a5ad1 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -8,6 +8,7 @@ config ARCH_MXC
 	select GENERIC_ALLOCATOR
 	select GENERIC_CLOCKEVENTS
 	select GENERIC_IRQ_CHIP
+	select MIGHT_HAVE_CACHE_L2X0 if ARCH_MULTI_V6_V7
 	select MULTI_IRQ_HANDLER
 	select SPARSE_IRQ
 	select USE_OF
-- 
1.8.1.2




From wsa at the-dreams.de  Wed Jul 10 11:33:55 2013
From: wsa at the-dreams.de (Wolfram Sang)
Date: Wed, 10 Jul 2013 16:33:55 +0100
Subject: [RFC 0/2] replace INIT_COMPLETION with reinit_completion
Message-ID: <1373470437-16908-1-git-send-email-wsa@the-dreams.de>

I had this on my mind for a bit of time now... Never liked INIT_COMPLETION
because of inconsistencies. See patch 1 to see why I think a replacement is
proper. I wonder what to do about the old INIT_COMPLETION, though. We could

a) remove it right away (bad luck for out-of-tree users, still my favourite)
b) keep it, but discourage its use (then we have cruft)
c) convert it to an inline function and mark that deprecated and remove it later

This series is based on linus-master as of today and I was able to compile test
60 out of 76 files, for the others I didn't have configs/compilers. Tested on
an AT91 board. More testing welcome.

Looking forward to opinions. If accepted, I'd think it is probably best if this
gets in in one go via Linus directly?

Thanks,

   Wolfram


Wolfram Sang (2):
  sched: replace INIT_COMPLETION with reinit_completion
  tree-wide: use reinit_completion instead of INIT_COMPLETION

 arch/arm/mach-tegra/apbio.c                      |    2 +-
 arch/powerpc/platforms/powermac/low_i2c.c        |    6 +++---
 arch/powerpc/platforms/pseries/suspend.c         |    2 +-
 crypto/af_alg.c                                  |    2 +-
 crypto/tcrypt.c                                  |    4 ++--
 crypto/testmgr.c                                 |   12 ++++++------
 drivers/ata/libata-eh.c                          |    2 +-
 drivers/base/power/main.c                        |    4 ++--
 drivers/block/amiflop.c                          |    2 +-
 drivers/block/cciss.c                            |    4 ++--
 drivers/char/hw_random/timeriomem-rng.c          |    2 +-
 drivers/crypto/tegra-aes.c                       |    2 +-
 drivers/firewire/core-transaction.c              |    2 +-
 drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c       |    2 +-
 drivers/hwmon/jz4740-hwmon.c                     |    2 +-
 drivers/i2c/busses/i2c-at91.c                    |    2 +-
 drivers/i2c/busses/i2c-bcm2835.c                 |    2 +-
 drivers/i2c/busses/i2c-davinci.c                 |    2 +-
 drivers/i2c/busses/i2c-designware-core.c         |    2 +-
 drivers/i2c/busses/i2c-ismt.c                    |    2 +-
 drivers/i2c/busses/i2c-mxs.c                     |    2 +-
 drivers/i2c/busses/i2c-omap.c                    |    2 +-
 drivers/i2c/busses/i2c-tegra.c                   |    2 +-
 drivers/i2c/busses/i2c-wmt.c                     |    4 ++--
 drivers/iio/adc/ad_sigma_delta.c                 |    6 +++---
 drivers/input/touchscreen/cyttsp_core.c          |    2 +-
 drivers/md/dm-crypt.c                            |    2 +-
 drivers/media/platform/blackfin/bfin_capture.c   |    2 +-
 drivers/media/platform/coda.c                    |    2 +-
 drivers/media/radio/radio-wl1273.c               |   10 +++++-----
 drivers/media/radio/si470x/radio-si470x-common.c |    4 ++--
 drivers/media/rc/iguanair.c                      |    2 +-
 drivers/memstick/core/memstick.c                 |    2 +-
 drivers/memstick/host/r592.c                     |    2 +-
 drivers/misc/ti-st/st_kim.c                      |   12 ++++++------
 drivers/mtd/nand/mxc_nand.c                      |    2 +-
 drivers/mtd/nand/r852.c                          |    2 +-
 drivers/mtd/onenand/omap2.c                      |   10 +++++-----
 drivers/net/ieee802154/at86rf230.c               |    2 +-
 drivers/net/ieee802154/mrf24j40.c                |    2 +-
 drivers/net/wireless/ath/carl9170/usb.c          |    2 +-
 drivers/net/wireless/ath/wil6210/main.c          |    2 +-
 drivers/net/wireless/brcm80211/brcmfmac/p2p.c    |    4 ++--
 drivers/net/wireless/zd1211rw/zd_usb.c           |    2 +-
 drivers/parport/parport_ip32.c                   |    4 ++--
 drivers/platform/x86/apple-gmux.c                |    2 +-
 drivers/power/ab8500_fg.c                        |    4 ++--
 drivers/power/jz4740-battery.c                   |    2 +-
 drivers/rtc/rtc-hid-sensor-time.c                |    2 +-
 drivers/spi/spi-bcm2835.c                        |    2 +-
 drivers/spi/spi-clps711x.c                       |    2 +-
 drivers/spi/spi-davinci.c                        |    2 +-
 drivers/spi/spi-fsl-espi.c                       |    2 +-
 drivers/spi/spi-fsl-spi.c                        |    2 +-
 drivers/spi/spi-mpc512x-psc.c                    |    2 +-
 drivers/spi/spi-mxs.c                            |    2 +-
 drivers/spi/spi-s3c64xx.c                        |    2 +-
 drivers/spi/spi-sh-msiof.c                       |    2 +-
 drivers/spi/spi-sirf.c                           |    2 +-
 drivers/spi/spi-tegra114.c                       |    6 +++---
 drivers/spi/spi-tegra20-sflash.c                 |    2 +-
 drivers/spi/spi-tegra20-slink.c                  |    6 +++---
 drivers/spi/spi-xilinx.c                         |    2 +-
 drivers/staging/iio/adc/mxs-lradc.c              |    2 +-
 drivers/staging/media/solo6x10/solo6x10-p2m.c    |    2 +-
 drivers/staging/tidspbridge/core/sync.c          |    4 ++--
 drivers/staging/tidspbridge/rmgr/drv_interface.c |    6 +++---
 drivers/tty/metag_da.c                           |    2 +-
 drivers/usb/c67x00/c67x00-sched.c                |    2 +-
 drivers/usb/gadget/f_fs.c                        |    2 +-
 drivers/usb/serial/mos7720.c                     |    2 +-
 drivers/video/exynos/exynos_mipi_dsi_common.c    |    4 ++--
 fs/ecryptfs/crypto.c                             |    4 ++--
 fs/nfs/nfs4state.c                               |    2 +-
 fs/ocfs2/dlmglue.c                               |    4 ++--
 include/linux/completion.h                       |   14 +++++++++++++-
 sound/soc/samsung/ac97.c                         |    6 +++---
 77 files changed, 131 insertions(+), 119 deletions(-)

-- 
1.7.10.4



From shawn.guo at linaro.org  Wed Jul 10 11:37:06 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 10 Jul 2013 23:37:06 +0800
Subject: [PATCH v3] ARM: imx: Select MIGHT_HAVE_CACHE_L2X0
In-Reply-To: <1373470216-12996-1-git-send-email-fabio.estevam@freescale.com>
References: <1373470216-12996-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <20130710153704.GD24654@S2101-09.ap.freescale.net>

On Wed, Jul 10, 2013 at 12:30:16PM -0300, Fabio Estevam wrote:
> Select MIGHT_HAVE_CACHE_L2X0 for armv6 and armv7 i.MX SoCs.
> 
> By selecting MIGHT_HAVE_CACHE_L2X0, the user still has the possibility to 
> disable CACHE_L2X0 selection via menuconfig.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Applied, thanks.



From dianders at chromium.org  Wed Jul 10 11:42:01 2013
From: dianders at chromium.org (Doug Anderson)
Date: Wed, 10 Jul 2013 08:42:01 -0700
Subject: [PATCH v3 0/5] mmc: dw_mmc: fixes for suspend/resume on exynos
In-Reply-To: <1373411961-23812-1-git-send-email-dianders@chromium.org>
References: <1373411961-23812-1-git-send-email-dianders@chromium.org>
Message-ID: <1373470926-19314-1-git-send-email-dianders@chromium.org>

This series of patches addresses some suspend/resume problems with
dw_mmc on exynos platforms.  Since suspend/resume is not fully working
on ToT Linux (3.10) on exynos5250-snow, this series was tested against
the current ToT ChromeOS 3.8 tree.  I have confirmed basic booting
and eMMC / SD card usage (and compiling, honest!) against ToT Linux.

Changes in v3:
- Add freeze/thaw and poweroff/restore noirq entries.

Changes in v2:
- Fix typo (some -> come)
- Use ~0 instead of 0xFFFFFFFF; add comment about value
- Use suspend_noirq as per James Hogan.

Doug Anderson (5):
  mmc: dw_mmc: Invalidate cache of current_speed after suspend/resume
  mmc: dw_mmc: Add suspend_noirq/resume_noirq callbacks for dw_mmc-pltfm
  mmc: dw_mmc: Add exynos resume_noirq callback to clear WAKEUP_INT
  mmc: dw_mmc: Always setup the bus after suspend/resume
  mmc: dw_mmc: Set timeout to max upon resume

 drivers/mmc/host/dw_mmc-exynos.c | 23 ++++++++++++++++++++++
 drivers/mmc/host/dw_mmc-pltfm.c  | 41 +++++++++++++++++++++++++++++++++++++---
 drivers/mmc/host/dw_mmc.c        | 15 +++++++++++----
 drivers/mmc/host/dw_mmc.h        |  4 ++++
 4 files changed, 76 insertions(+), 7 deletions(-)

-- 
1.8.3



From dianders at chromium.org  Wed Jul 10 11:42:04 2013
From: dianders at chromium.org (Doug Anderson)
Date: Wed, 10 Jul 2013 08:42:04 -0700
Subject: [PATCH v3 3/5] mmc: dw_mmc: Add exynos resume_noirq callback to clear
 WAKEUP_INT
In-Reply-To: <1373470926-19314-1-git-send-email-dianders@chromium.org>
References: <1373411961-23812-1-git-send-email-dianders@chromium.org>
 <1373470926-19314-1-git-send-email-dianders@chromium.org>
Message-ID: <1373470926-19314-4-git-send-email-dianders@chromium.org>

If the WAKEUP_INT is asserted at wakeup and not cleared, we'll end up
looping around forever.  This has been seen to happen on exynos5420
silicon despite the fact that we haven't enabled any wakeup events.

Signed-off-by: Doug Anderson <dianders at chromium.org>
---
Changes in v3: None
Changes in v2:
- Use suspend_noirq as per James Hogan.

 drivers/mmc/host/dw_mmc-exynos.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index f013e7e..36b9620 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -30,6 +30,7 @@
 #define SDMMC_CLKSEL_TIMING(x, y, z)	(SDMMC_CLKSEL_CCLK_SAMPLE(x) |	\
 					SDMMC_CLKSEL_CCLK_DRIVE(y) |	\
 					SDMMC_CLKSEL_CCLK_DIVIDER(z))
+#define SDMMC_CLKSEL_WAKEUP_INT		BIT(11)
 
 #define SDMMC_CMD_USE_HOLD_REG		BIT(29)
 
@@ -102,6 +103,27 @@ static int dw_mci_exynos_setup_clock(struct dw_mci *host)
 	return 0;
 }
 
+/**
+ * dw_mci_exynos_resume_noirq - Exynos-specific resume code
+ *
+ * We have seen cases (at least on the exynos5420) where turning off the INT
+ * power rail during suspend will leave the WAKEUP_INT bit in the CLKSEL
+ * register asserted.  This bit is 1 to indicate that it fired and we can
+ * clear it by writing a 1 back.  Clear it to prevent interrupts from going off
+ * constantly.
+ */
+
+static int dw_mci_exynos_resume_noirq(struct dw_mci *host)
+{
+	u32 clksel;
+
+	clksel = mci_readl(host, CLKSEL);
+	if (clksel & SDMMC_CLKSEL_WAKEUP_INT)
+		mci_writel(host, CLKSEL, clksel);
+
+	return 0;
+}
+
 static void dw_mci_exynos_prepare_command(struct dw_mci *host, u32 *cmdr)
 {
 	/*
@@ -165,6 +187,7 @@ static const struct dw_mci_drv_data exynos_drv_data = {
 	.caps			= exynos_dwmmc_caps,
 	.init			= dw_mci_exynos_priv_init,
 	.setup_clock		= dw_mci_exynos_setup_clock,
+	.resume_noirq		= dw_mci_exynos_resume_noirq,
 	.prepare_command	= dw_mci_exynos_prepare_command,
 	.set_ios		= dw_mci_exynos_set_ios,
 	.parse_dt		= dw_mci_exynos_parse_dt,
-- 
1.8.3



From wsa at the-dreams.de  Wed Jul 10 11:57:39 2013
From: wsa at the-dreams.de (Wolfram Sang)
Date: Wed, 10 Jul 2013 16:57:39 +0100
Subject: [PATCH 04/12] drivers/mmc/host: don't use
 devm_pinctrl_get_select_default() in probe
In-Reply-To: <1373471889-18107-1-git-send-email-wsa@the-dreams.de>
References: <1373471889-18107-1-git-send-email-wsa@the-dreams.de>
Message-ID: <1373471889-18107-4-git-send-email-wsa@the-dreams.de>

Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.

Acked-by: Linus Walleij <linus.walleij at linaro.org> (personally at LCE13)
Signed-off-by: Wolfram Sang <wsa at the-dreams.de>
---
 drivers/mmc/host/mvsdio.c          |    6 ------
 drivers/mmc/host/mxs-mmc.c         |    8 --------
 drivers/mmc/host/omap_hsmmc.c      |    7 -------
 drivers/mmc/host/sdhci-esdhc-imx.c |    8 --------
 drivers/mmc/host/sdhci-sirf.c      |    8 --------
 5 files changed, 37 deletions(-)

diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c
index 8960fc8..ed5edc2 100644
--- a/drivers/mmc/host/mvsdio.c
+++ b/drivers/mmc/host/mvsdio.c
@@ -25,7 +25,6 @@
 #include <linux/of_irq.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/slot-gpio.h>
-#include <linux/pinctrl/consumer.h>
 
 #include <asm/sizes.h>
 #include <asm/unaligned.h>
@@ -686,7 +685,6 @@ static int __init mvsd_probe(struct platform_device *pdev)
 	struct resource *r;
 	int ret, irq;
 	int gpio_card_detect, gpio_write_protect;
-	struct pinctrl *pinctrl;
 
 	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	irq = platform_get_irq(pdev, 0);
@@ -703,10 +701,6 @@ static int __init mvsd_probe(struct platform_device *pdev)
 	host->mmc = mmc;
 	host->dev = &pdev->dev;
 
-	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
-	if (IS_ERR(pinctrl))
-		dev_warn(&pdev->dev, "no pins associated\n");
-
 	/*
 	 * Some non-DT platforms do not pass a clock, and the clock
 	 * frequency is passed through platform_data. On DT platforms,
diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index 4278a17..1eb3224 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -41,7 +41,6 @@
 #include <linux/gpio.h>
 #include <linux/regulator/consumer.h>
 #include <linux/module.h>
-#include <linux/pinctrl/consumer.h>
 #include <linux/stmp_device.h>
 #include <linux/spi/mxs-spi.h>
 
@@ -580,7 +579,6 @@ static int mxs_mmc_probe(struct platform_device *pdev)
 	struct mxs_mmc_host *host;
 	struct mmc_host *mmc;
 	struct resource *iores;
-	struct pinctrl *pinctrl;
 	int ret = 0, irq_err;
 	struct regulator *reg_vmmc;
 	enum of_gpio_flags flags;
@@ -620,12 +618,6 @@ static int mxs_mmc_probe(struct platform_device *pdev)
 		}
 	}
 
-	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
-	if (IS_ERR(pinctrl)) {
-		ret = PTR_ERR(pinctrl);
-		goto out_mmc_free;
-	}
-
 	ssp->clk = clk_get(&pdev->dev, NULL);
 	if (IS_ERR(ssp->clk)) {
 		ret = PTR_ERR(ssp->clk);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index eccedc7..332ce51 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -37,7 +37,6 @@
 #include <linux/io.h>
 #include <linux/gpio.h>
 #include <linux/regulator/consumer.h>
-#include <linux/pinctrl/consumer.h>
 #include <linux/pm_runtime.h>
 #include <linux/platform_data/mmc-omap.h>
 
@@ -1776,7 +1775,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
 	const struct of_device_id *match;
 	dma_cap_mask_t mask;
 	unsigned tx_req, rx_req;
-	struct pinctrl *pinctrl;
 
 	match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev);
 	if (match) {
@@ -1995,11 +1993,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
 
 	omap_hsmmc_disable_irq(host);
 
-	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
-	if (IS_ERR(pinctrl))
-		dev_warn(&pdev->dev,
-			"pins are not configured from the driver\n");
-
 	omap_hsmmc_protect_card(host);
 
 	mmc_add_host(mmc);
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index d5f0d59..0880e3a 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -25,7 +25,6 @@
 #include <linux/of.h>
 #include <linux/of_device.h>
 #include <linux/of_gpio.h>
-#include <linux/pinctrl/consumer.h>
 #include <linux/platform_data/mmc-esdhc-imx.h>
 #include "sdhci-pltfm.h"
 #include "sdhci-esdhc.h"
@@ -80,7 +79,6 @@ struct pltfm_imx_data {
 	int flags;
 	u32 scratchpad;
 	enum imx_esdhc_type devtype;
-	struct pinctrl *pinctrl;
 	struct esdhc_platform_data boarddata;
 	struct clk *clk_ipg;
 	struct clk *clk_ahb;
@@ -544,12 +542,6 @@ static int sdhci_esdhc_imx_probe(struct platform_device *pdev)
 	clk_prepare_enable(imx_data->clk_ipg);
 	clk_prepare_enable(imx_data->clk_ahb);
 
-	imx_data->pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
-	if (IS_ERR(imx_data->pinctrl)) {
-		err = PTR_ERR(imx_data->pinctrl);
-		goto disable_clk;
-	}
-
 	host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
 
 	if (is_imx25_esdhc(imx_data) || is_imx35_esdhc(imx_data))
diff --git a/drivers/mmc/host/sdhci-sirf.c b/drivers/mmc/host/sdhci-sirf.c
index 09805af..ccf12dd 100644
--- a/drivers/mmc/host/sdhci-sirf.c
+++ b/drivers/mmc/host/sdhci-sirf.c
@@ -13,7 +13,6 @@
 #include <linux/of.h>
 #include <linux/of_gpio.h>
 #include <linux/mmc/slot-gpio.h>
-#include <linux/pinctrl/consumer.h>
 #include "sdhci-pltfm.h"
 
 struct sdhci_sirf_priv {
@@ -46,15 +45,8 @@ static int sdhci_sirf_probe(struct platform_device *pdev)
 	struct sdhci_host *host;
 	struct sdhci_pltfm_host *pltfm_host;
 	struct sdhci_sirf_priv *priv;
-	struct pinctrl *pinctrl;
 	int ret;
 
-	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
-	if (IS_ERR(pinctrl)) {
-		dev_err(&pdev->dev, "unable to get pinmux");
-		return PTR_ERR(pinctrl);
-	}
-
 	priv = devm_kzalloc(&pdev->dev, sizeof(struct sdhci_sirf_priv),
 		GFP_KERNEL);
 	if (!priv) {
-- 
1.7.10.4



From balbi at ti.com  Wed Jul 10 12:07:04 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 10 Jul 2013 19:07:04 +0300
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130710142633.GV5523@atomide.com>
References: <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi>
 <87mwpuakod.fsf@linaro.org> <20130710142633.GV5523@atomide.com>
Message-ID: <20130710160704.GH18966@arwen.pp.htv.fi>

Hi,

On Wed, Jul 10, 2013 at 07:26:34AM -0700, Tony Lindgren wrote:
> * Kevin Hilman <khilman at linaro.org> [130710 01:29]:
> > Felipe Balbi <balbi at ti.com> writes:
> > >> 
> > >> Right, but calling serial_omap_restore_context() even when the context
> > >> is not lost, should not ideally cause an issue.
> > >
> > > it does in one condition. If context hasn't been saved before. And that
> > > can happen in the case of wrong pm runtime status for that device.
> > >
> > > Imagine the device is marked as suspended even though it's fully enabled
> > > (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> > > your context structure is all zeroes (context has never been saved
> > > before) then when you call pm_runtime_get_sync() on probe() your
> > > ->runtime_resume() will get called, which will restore context,
> > > essentially undoing anything which was configured by u-boot.
> > >
> > > Am I missing something ?
> > 
> > You're right, the _set_active() is crucial in the case when we prevent
> > the console UART from idling during boot (though that shouldn't be
> > happening in mainline unless the fix for "Issue 1" is done.)
> 
> Felipe is right, looks like all we need is to check if context is
> initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
> 
> After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
> works for me. We could also check for some combination of the context
> save registers being NULL if somebody has a good idea which ones
> should never be 0.
> 
> Regards,
> 
> Tony
> 
> 
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -161,6 +161,7 @@ struct uart_omap_port {
>  	u32			calc_latency;
>  	struct work_struct	qos_work;
>  	struct pinctrl		*pins;
> +	bool			initialized;
>  	bool			is_suspending;
>  };
>  
> @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
>  
>  	pm_runtime_mark_last_busy(up->dev);
>  	pm_runtime_put_autosuspend(up->dev);
> +	up->initialized = true;
> +
>  	return 0;
>  
>  err_add_port:
> @@ -1584,6 +1587,9 @@ static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
>  #ifdef CONFIG_PM_RUNTIME
>  static void serial_omap_restore_context(struct uart_omap_port *up)
>  {
> +	if (!up->initialized)
> +		return;
> +
>  	if (up->errata & UART_ERRATA_i202_MDR1_ACCESS)
>  		serial_omap_mdr1_errataset(up, UART_OMAP_MDR1_DISABLE);
>  	else

how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
->runtime_resume() from being called on first pm_runtime_get*() done
during probe.

This is similar to what PCI bus does (if you look at pci_pm_init()).

commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
Author: Felipe Balbi <balbi at ti.com>
Date:   Wed Jul 10 18:50:16 2013 +0300

    arm: omap2plus: unidle devices which are about to probe
    
    in order to make HWMOD and pm_runtime agree on the
    initial state of the device, we will unidle the device
    and call pm_runtime_set_active() to tell pm_runtime
    that the device is really active.
    
    By the time driver's probe() is reached, a call to
    pm_runtime_get_sync() will not cause driver's
    ->runtime_resume() method to be called at first, only
    after a successful ->runtime_suspend().
    
    Signed-off-by: Felipe Balbi <balbi at ti.com>

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index e6d2307..1cedf3a 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -181,6 +181,26 @@ odbfd_exit:
 	return ret;
 }
 
+static void omap_device_pm_init(struct platform_device *pdev);
+{
+	/*
+	 * if we reach this function, it's because the device is about to be
+	 * probed. In such cases, we will enable the device, and call
+	 * pm_runtime_set_active() so that the device driver and runtime PM
+	 * framework agree on initial state of the device.
+	 */
+	omap_device_enable(pdev);
+	pm_runtime_set_active(&pdev->dev);
+	device_enable_async_suspend(&pdev->dev);
+}
+
+static void omap_device_pm_exit(struct platform_device *pdev);
+{
+	device_disable_async_suspend(&pdev->dev);
+	pm_runtime_set_suspended(&pdev->dev);
+	omap_device_idle(pdev);
+}
+
 static int _omap_device_notifier_call(struct notifier_block *nb,
 				      unsigned long event, void *dev)
 {
@@ -192,6 +212,12 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
 		if (pdev->archdata.od)
 			omap_device_delete(pdev->archdata.od);
 		break;
+	case BUS_NOTIFY_BIND_DRIVER:
+		omap_device_pm_init(pdev);
+		break;
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+		omap_device_pm_exit(pdev);
+		break;
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdev->dev.of_node)
 			omap_device_build_from_dt(pdev);

-- 
balbi
-------------- 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/20130710/5f849a70/attachment.sig>

From swarren at wwwdotorg.org  Wed Jul 10 12:09:17 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Jul 2013 10:09:17 -0600
Subject: CPU hotplug issue w/ 0647065 clocksource: Add generic dummy timer
 driver
In-Reply-To: <20130709230528.GE830@codeaurora.org>
References: <51DAF895.1020700@wwwdotorg.org>
 <20130709005837.GC830@codeaurora.org> <51DC34AD.30009@wwwdotorg.org>
 <20130709163518.GD830@codeaurora.org> <51DC3FD2.9070308@wwwdotorg.org>
 <20130709230528.GE830@codeaurora.org>
Message-ID: <51DD872D.7020101@wwwdotorg.org>

On 07/09/2013 05:05 PM, Stephen Boyd wrote:
> On 07/09, Stephen Warren wrote:
>> On 07/09/2013 10:35 AM, Stephen Boyd wrote:
>>> On 07/09, Stephen Warren wrote:
>>>> On 07/08/2013 06:58 PM, Stephen Boyd wrote:
>>>>> On 07/08, Stephen Warren wrote:
>>>>>> CPU hotplug (replug) on Tegra HW seems to be occasionally broken due to
>>>>>> commit 0647065 "clocksource: Add generic dummy timer driver" in
>>>>>> linux-next. Reverting that commit solves the issue.
...
> Can you try this patch?

That seems to work great, thanks! I successfully unpugged/replugged CPU1
about 200 times, whereas without the patch I'd usually see the problem
about 10% of replug attempts.

Tested-by: Stephen Warren <swarren at nvidia.com>

> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
> index 6d3f916..218bcb5 100644
> --- a/kernel/time/tick-broadcast.c
> +++ b/kernel/time/tick-broadcast.c
> @@ -157,7 +157,10 @@ int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu)
>  		dev->event_handler = tick_handle_periodic;
>  		tick_device_setup_broadcast_func(dev);
>  		cpumask_set_cpu(cpu, tick_broadcast_mask);
> -		tick_broadcast_start_periodic(bc);
> +		if (tick_broadcast_device.mode == TICKDEV_MODE_PERIODIC)
> +			tick_broadcast_start_periodic(bc);
> +		else
> +			tick_broadcast_setup_oneshot(bc);
>  		ret = 1;
>  	} else {
>  		/*
> 



From fabio.estevam at freescale.com  Wed Jul 10 12:11:52 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Wed, 10 Jul 2013 13:11:52 -0300
Subject: [PATCH] ARM: imx_v6_v7_defconfig: Select ARM1136 related errata
Message-ID: <1373472712-22295-1-git-send-email-fabio.estevam@freescale.com>

CONFIG_ARM_ERRATA_411920 and CONFIG_ARM_ERRATA_364296 should be selected for
ARM1136 SoCs.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/configs/imx_v6_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f1662d3..ee84e82 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -40,6 +40,8 @@ CONFIG_SOC_IMX6Q=y
 CONFIG_SOC_IMX6SL=y
 CONFIG_SOC_VF610=y
 CONFIG_MXC_PWM=y
+CONFIG_ARM_ERRATA_411920=y
+CONFIG_ARM_ERRATA_364296=y
 CONFIG_SMP=y
 CONFIG_VMSPLIT_2G=y
 CONFIG_PREEMPT_VOLUNTARY=y
-- 
1.8.1.2




From balbi at ti.com  Wed Jul 10 12:11:58 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 10 Jul 2013 19:11:58 +0300
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130710160704.GH18966@arwen.pp.htv.fi>
References: <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi>
 <87mwpuakod.fsf@linaro.org> <20130710142633.GV5523@atomide.com>
 <20130710160704.GH18966@arwen.pp.htv.fi>
Message-ID: <20130710161158.GA19716@arwen.pp.htv.fi>

Hi,

On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
> how about something like below ? It makes omap_device/hwmod and
> pm_runtime agree on the initial state of the device and will prevent
> ->runtime_resume() from being called on first pm_runtime_get*() done
> during probe.
> 
> This is similar to what PCI bus does (if you look at pci_pm_init()).
> 
> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
> Author: Felipe Balbi <balbi at ti.com>
> Date:   Wed Jul 10 18:50:16 2013 +0300
> 
>     arm: omap2plus: unidle devices which are about to probe
>     
>     in order to make HWMOD and pm_runtime agree on the
>     initial state of the device, we will unidle the device
>     and call pm_runtime_set_active() to tell pm_runtime
>     that the device is really active.
>     
>     By the time driver's probe() is reached, a call to
>     pm_runtime_get_sync() will not cause driver's
>     ->runtime_resume() method to be called at first, only
>     after a successful ->runtime_suspend().
>     
>     Signed-off-by: Felipe Balbi <balbi at ti.com>

btw, this is RFC, haven't tested at all.

-- 
balbi
-------------- 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/20130710/18f596e3/attachment.sig>

From gerlando.falauto at keymile.com  Wed Jul 10 12:15:32 2013
From: gerlando.falauto at keymile.com (Gerlando Falauto)
Date: Wed, 10 Jul 2013 18:15:32 +0200
Subject: pci-mvebu driver on km_kirkwood
Message-ID: <51DD88A4.1030506@keymile.com>

Hi Thomas,

I am trying to use the pci-mvebu driver on one of our km_kirkwood 
boards. The board is based on Marvell's 98dx4122, which should 
essentially be 6281 compatible.

So I copied the following block from kirkwood-6281.dtsi into
kirkwood-98dx4122.dtsi:

		pcie-controller {
			compatible = "marvell,kirkwood-pcie";
			status = "disabled";
			device_type = "pci";

			#address-cells = <3>;
			#size-cells = <2>;

			bus-range = <0x00 0xff>;

			ranges = <0x82000000 0 0x00040000 0x00040000 0 0x00002000   /* Port 
0.0 registers */
				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* 
non-prefetchable memory */
			          0x81000000 0 0          0xe8000000 0 0x00100000>; /* 
downstream I/O */

			pcie at 1,0 {
				device_type = "pci";
				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
				reg = <0x0800 0 0 0 0>;
				#address-cells = <3>;
				#size-cells = <2>;
				#interrupt-cells = <1>;
				ranges;
				interrupt-map-mask = <0 0 0 0>;
				interrupt-map = <0 0 0 0 &intc 9>;
				marvell,pcie-port = <0>;
				marvell,pcie-lane = <0>;
				clocks = <&gate_clk 2>;
				status = "disabled";
			};
		};

And added the following block to kirkwood-km_kirkwood.dts:

		pcie-controller {
			status = "okay";

			pcie at 1,0 {
				status = "okay";
			};
		};

The code I took from jcooper's repo:

   http://git.infradead.org/users/jcooper/linux.git

I took the tag

   dt-3.11-6

on top of which I merged:

   mvebu/pcie
   mvebu/pcie_bridge
   mvebu/pcie_kirkwood

Only with the latest merge did I get some conflict on
kirkwood.dtsi:

<<<<<<< HEAD
		ranges = <0x00000000 0xf1000000 0x0100000		
		          0xf4000000 0xf4000000 0x0000400
=======
		ranges = <0x00000000 0xf1000000 0x4000000
		          0xe0000000 0xe0000000 0x8100000
 >>>>>>> jcooper/mvebu/pcie_kirkwood

tried both variants, (almost) the same result:

<<<<<<< HEAD
Kirkwood: MV88F6281-A0, TCLK=200000000.
Feroceon L2: Cache support initialised, in WT override mode.
mvebu-pcie pcie-controller.1: PCIe0.0: link up
mvebu-pcie pcie-controller.1: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xffffffff-0x07fffffe]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci 0000:00:01.0: [11ab:7846] type 01 class 0x060400
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0000:01:00.0: [10ee:0008] type 00 class 0x050000
pci 0000:01:00.0: reg 10: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: reg 14: [mem 0x00000000-0x07ffffff]
pci 0000:01:00.0: reg 18: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: reg 1c: [mem 0x00000000-0x007fffff]
pci 0000:01:00.0: reg 20: [mem 0x00000000-0x00001fff]
pci 0000:01:00.0: reg 24: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: supports D1 D2
pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot
PCI: bus1: Fast back to back transfers disabled
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci 0000:00:01.0: BAR 8: can't assign mem (size 0xc000000)
pci 0000:01:00.0: BAR 1: can't assign mem (size 0x8000000)
pci 0000:01:00.0: BAR 3: can't assign mem (size 0x800000)
pci 0000:01:00.0: BAR 4: can't assign mem (size 0x2000)
pci 0000:01:00.0: BAR 0: can't assign mem (size 0x1000)
pci 0000:01:00.0: BAR 2: can't assign mem (size 0x1000)
pci 0000:01:00.0: BAR 5: can't assign mem (size 0x1000)
pci 0000:00:01.0: PCI bridge to [bus 01]
=======
Kirkwood: MV88F6281-A0, TCLK=200000000.
Feroceon L2: Cache support initialised, in WT override mode.
mvebu-pcie pcie-controller.2: PCIe0.0: link up
mvebu-pcie pcie-controller.2: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci 0000:00:01.0: [11ab:7846] type 01 class 0x060400
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0000:01:00.0: [10ee:0008] type 00 class 0x050000
pci 0000:01:00.0: reg 10: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: reg 14: [mem 0x00000000-0x07ffffff]
pci 0000:01:00.0: reg 18: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: reg 1c: [mem 0x00000000-0x007fffff]
pci 0000:01:00.0: reg 20: [mem 0x00000000-0x00001fff]
pci 0000:01:00.0: reg 24: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: supports D1 D2
pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot
PCI: bus1: Fast back to back transfers disabled
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci 0000:00:01.0: BAR 8: can't assign mem (size 0xc000000)
pci 0000:01:00.0: BAR 1: can't assign mem (size 0x8000000)
pci 0000:01:00.0: BAR 3: can't assign mem (size 0x800000)
pci 0000:01:00.0: BAR 4: can't assign mem (size 0x2000)
pci 0000:01:00.0: BAR 0: can't assign mem (size 0x1000)
pci 0000:01:00.0: BAR 2: can't assign mem (size 0x1000)
pci 0000:01:00.0: BAR 5: can't assign mem (size 0x1000)
pci 0000:00:01.0: PCI bridge to [bus 01]

 >>>>>>> jcooper/mvebu/pcie_kirkwood

Compared to a working configuration, here I see a spurious

   pci 0000:00:01.0: BAR 8: can't assign mem (size 0xc000000)

which I don't understand, plus all others which are failing.

It's weird how with the second configuration:

   mvebu-pcie pcie-controller.2: PCIe0.0: link up
   mvebu-pcie pcie-controller.2: PCI host bridge to bus 0000:00
   pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
   pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]

I get a second mvebu-pcie pcie-controller.2, although with a more 
reasonable memory range.

Needless to say, I did try several other combinations of your recent and 
not-so-recent patches (from May 23rd onwards), with essentially the same 
results.

It *must* be something trivial. Any hints?

Thanks a lot!
Gerlando


From rogerq at ti.com  Wed Jul 10 12:17:55 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 10 Jul 2013 19:17:55 +0300
Subject: [PATCH 0/6] USB: Implement runtime idling and remote wakeup for OMAP
 EHCI controller
Message-ID: <1373473081-27181-1-git-send-email-rogerq@ti.com>

Hi,

This series implements suspend/resume for the OMAP EHCI host controller during
runtime idle. This will cause its parent, the OMAP USB Host Module as well
as the USB TLL Module to be put in suspend and hence allow the USB power domain
to be put in a lower power state. Then we no longer prevent the rest of the OMAP
SoC from entering lower power states like RETention or OFF mode when
USB (or system) is suspended. This was one of the main reason why EHCI_OMAP
is still not enabled in OMAP2 defconfig.

In order for remote wakeup or hub events (connect/disconnect) to be detected
while in suspend, we need to rely on the IO daisy chaining mechanism on OMAP.
This is nothing but configuring a pin to be wakeup capable and triggering an
interrupt on any pin activity while the hardware module or the entire SoC is
in sleep state. For this to work, we rely on the wakeup feature added to the
omap-pinctrl-single driver in [1]. This takes care of routing IO pad wakeup
interrupt to the right driver's interrupt handler (i.e. ehci_irq in our case).

The pin state information for DEFAULT and IDLE is specified for the omap3beagle-xm
board in patch 2. So this is tested only on omap3beagle-xm board.

Patch 4 takes care of switching the pin states between DEFAULT and IDLE during
idle/active mode using the pinctrl framework.

Patch 5 takes care of handling the wakeup IRQ when the USB controller is suspended
and Hardware is not accessible.

Patch 6 implements runtime and system suspend/resume for the OMAP EHCI controller

Changelog:
v1:
- addressed review comments on RFC patchset
- Special case handling of controllers that can generate wakeup IRQ when
suspended is done in HCD core instead of ehci-hcd.
- Patches based on linus/master commit 496322bc91e35007ed754184dcd447a02b6dd685
with the following patches on top

[1] - OMAP pinctrl wakeup support
http://thread.gmane.org/gmane.linux.ports.arm.omap/99010/focus=99041
This does not apply cleanly though. Tony has agreed to post a revision anytime soon.

[2] - [PATCH v5 0/2] ARM: dts: Add USB host support for Beagle-xm
http://thread.gmane.org/gmane.linux.drivers.devicetree/39291

[3] - USB-EHCI-Fix-resume-signalling-on-remote-wakeup.patch
http://thread.gmane.org/gmane.linux.usb.general/89608

cheers,
-roger

---
Roger Quadros (6):
  ARM: OMAP3: Enable Hardware Save and Restore for USB Host
  ARM: dts: omap3beagle-xm: Add idle state pins for USB host
  mfd: omap-usb-host: move initialization to module_init()
  mfd: omap-usb-host: Put pins in IDLE state on suspend
  USB: Support wakeup IRQ for suspended controllers
  USB: ehci-omap: Implement suspend/resume

 arch/arm/boot/dts/omap3-beagle-xm.dts       |   29 ++++++++++---
 arch/arm/mach-omap2/powerdomains3xxx_data.c |    8 +---
 drivers/mfd/omap-usb-host.c                 |   45 ++++++++++--------
 drivers/mfd/omap-usb-tll.c                  |   20 +--------
 drivers/usb/core/hcd.c                      |   21 ++++++++-
 drivers/usb/host/ehci-omap.c                |   64 ++++++++++++++++++++++++++-
 include/linux/usb/hcd.h                     |    3 +
 7 files changed, 136 insertions(+), 54 deletions(-)

-- 
1.7.4.1



From rogerq at ti.com  Wed Jul 10 12:17:56 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 10 Jul 2013 19:17:56 +0300
Subject: [PATCH 1/6] ARM: OMAP3: Enable Hardware Save and Restore for USB Host
In-Reply-To: <1373473081-27181-1-git-send-email-rogerq@ti.com>
References: <1373473081-27181-1-git-send-email-rogerq@ti.com>
Message-ID: <1373473081-27181-2-git-send-email-rogerq@ti.com>

To ensure hardware context is restored while resuming from
OFF mode we need to enable the Hardware SAR bit for the
USB Host power domain.

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/mach-omap2/powerdomains3xxx_data.c |    8 +-------
 1 files changed, 1 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index e2d4bd8..7b44d1f 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -289,13 +289,7 @@ static struct powerdomain usbhost_pwrdm = {
 	.prcm_offs	  = OMAP3430ES2_USBHOST_MOD,
 	.pwrsts		  = PWRSTS_OFF_RET_ON,
 	.pwrsts_logic_ret = PWRSTS_RET,
-	/*
-	 * REVISIT: Enabling usb host save and restore mechanism seems to
-	 * leave the usb host domain permanently in ACTIVE mode after
-	 * changing the usb host power domain state from OFF to active once.
-	 * Disabling for now.
-	 */
-	/*.flags	  = PWRDM_HAS_HDWR_SAR,*/ /* for USBHOST ctrlr only */
+	.flags		  = PWRDM_HAS_HDWR_SAR, /* for USBHOST ctrlr only */
 	.banks		  = 1,
 	.pwrsts_mem_ret	  = {
 		[0] = PWRSTS_RET, /* MEMRETSTATE */
-- 
1.7.4.1



From rogerq at ti.com  Wed Jul 10 12:22:18 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 10 Jul 2013 19:22:18 +0300
Subject: [PATCH 2/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
In-Reply-To: <1373473081-27181-1-git-send-email-rogerq@ti.com>
References: <1373473081-27181-1-git-send-email-rogerq@ti.com>
Message-ID: <1373473338-27433-1-git-send-email-rogerq@ti.com>

Add the Idle state pins for USB host and enable WAKEUP on
DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
sleep on any USB activity (e.g. remote wakeup or connect/disconnect).

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/boot/dts/omap3-beagle-xm.dts |   29 +++++++++++++++++++++++------
 1 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 371b1e2..91d19fa 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -113,11 +113,6 @@
 };
 
 &omap3_pmx_core {
-	pinctrl-names = "default";
-	pinctrl-0 = <
-			&hsusbb2_pins
-	>;
-
 	uart3_pins: pinmux_uart3_pins {
 		pinctrl-single,pins = <
 			0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */
@@ -125,7 +120,7 @@
 		>;
 	};
 
-	hsusbb2_pins: pinmux_hsusbb2_pins {
+	hsusb2_pins: pinmux_hsusb2_pins {
 		pinctrl-single,pins = <
 			0x5c0 (PIN_OUTPUT | MUX_MODE3)		/* etk_d10.hsusb2_clk */
 			0x5c2 (PIN_OUTPUT | MUX_MODE3)		/* etk_d11.hsusb2_stp */
@@ -141,6 +136,25 @@
 			0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_cs1.hsusb2_data3 */
 		>;
 	};
+
+	/* WAKEUP enabled on DIR, DAT0-3 */
+	hsusb2_idle_pins: pinmux_hsusb2_idle_pins {
+		pinctrl-single,pins = <
+			0x5c0 (PIN_OUTPUT | MUX_MODE3)		/* etk_d10.hsusb2_clk */
+			0x5c2 (PIN_OUTPUT | MUX_MODE3)		/* etk_d11.hsusb2_stp */
+			0x5c4 (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)	/* etk_d12.hsusb2_dir */
+			0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3)			/* etk_d13.hsusb2_nxt */
+			0x5c8 (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)	/* etk_d14.hsusb2_data0 */
+			0x5cA (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)	/* etk_d15.hsusb2_data1 */
+			0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi1_cs3.hsusb2_data2 */
+			0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_clk.hsusb2_data7 */
+			0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_simo.hsusb2_data4 */
+			0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_somi.hsusb2_data5 */
+			0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_cs0.hsusb2_data6 */
+			0x1ae (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)	/* mcspi2_cs1.hsusb2_data3 */
+		>;
+		interrupts = <77>; /* route padconf wakeup to EHCI IRQ */
+	};
 };
 
 &i2c1 {
@@ -223,6 +237,9 @@
 };
 
 &usbhshost {
+	pinctrl-names = "default", "idle";
+	pinctrl-0 = <&hsusb2_pins>;
+	pinctrl-1 = <&hsusb2_idle_pins>;
 	port2-mode = "ehci-phy";
 };
 
-- 
1.7.4.1



From rogerq at ti.com  Wed Jul 10 12:22:48 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 10 Jul 2013 19:22:48 +0300
Subject: [PATCH 3/6] mfd: omap-usb-host: move initialization to module_init()
In-Reply-To: <1373473081-27181-1-git-send-email-rogerq@ti.com>
References: <1373473081-27181-1-git-send-email-rogerq@ti.com>
Message-ID: <1373473368-27476-1-git-send-email-rogerq@ti.com>

We no longer need to be initialized in any particular order
so move driver initialization to the standard place i.e. module_init()

CC: Samuel Ortiz <sameo at linux.intel.com>
Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 drivers/mfd/omap-usb-host.c |   23 +++--------------------
 drivers/mfd/omap-usb-tll.c  |   20 ++------------------
 2 files changed, 5 insertions(+), 38 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 759fae3..fb2b3d8 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -895,31 +895,14 @@ static struct platform_driver usbhs_omap_driver = {
 		.pm		= &usbhsomap_dev_pm_ops,
 		.of_match_table = of_match_ptr(usbhs_omap_dt_ids),
 	},
+	.probe		= usbhs_omap_probe,
 	.remove		= usbhs_omap_remove,
 };
 
+module_platform_driver(usbhs_omap_driver);
+
 MODULE_AUTHOR("Keshava Munegowda <keshava_mgowda at ti.com>");
 MODULE_AUTHOR("Roger Quadros <rogerq at ti.com>");
 MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
 MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("usb host common core driver for omap EHCI and OHCI");
-
-static int __init omap_usbhs_drvinit(void)
-{
-	return platform_driver_probe(&usbhs_omap_driver, usbhs_omap_probe);
-}
-
-/*
- * init before ehci and ohci drivers;
- * The usbhs core driver should be initialized much before
- * the omap ehci and ohci probe functions are called.
- * This usbhs core driver should be initialized after
- * usb tll driver
- */
-fs_initcall_sync(omap_usbhs_drvinit);
-
-static void __exit omap_usbhs_drvexit(void)
-{
-	platform_driver_unregister(&usbhs_omap_driver);
-}
-module_exit(omap_usbhs_drvexit);
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index e59ac4c..1a3a26f 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -326,6 +326,8 @@ static struct platform_driver usbtll_omap_driver = {
 	.remove		= usbtll_omap_remove,
 };
 
+module_platform_driver(usbtll_omap_driver);
+
 int omap_tll_init(struct usbhs_omap_platform_data *pdata)
 {
 	int i;
@@ -477,21 +479,3 @@ MODULE_AUTHOR("Roger Quadros <rogerq at ti.com>");
 MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
 MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("usb tll driver for TI OMAP EHCI and OHCI controllers");
-
-static int __init omap_usbtll_drvinit(void)
-{
-	return platform_driver_register(&usbtll_omap_driver);
-}
-
-/*
- * init before usbhs core driver;
- * The usbtll driver should be initialized before
- * the usbhs core driver probe function is called.
- */
-fs_initcall(omap_usbtll_drvinit);
-
-static void __exit omap_usbtll_drvexit(void)
-{
-	platform_driver_unregister(&usbtll_omap_driver);
-}
-module_exit(omap_usbtll_drvexit);
-- 
1.7.4.1



From rogerq at ti.com  Wed Jul 10 12:23:00 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 10 Jul 2013 19:23:00 +0300
Subject: [PATCH 4/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
In-Reply-To: <1373473081-27181-1-git-send-email-rogerq@ti.com>
References: <1373473081-27181-1-git-send-email-rogerq@ti.com>
Message-ID: <1373473380-27515-1-git-send-email-rogerq@ti.com>

In order to support wake up from suspend use the pinctrl
framework to put the USB host pins in IDLE state during suspend.

CC: Samuel Ortiz <sameo at linux.intel.com>
Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 drivers/mfd/omap-usb-host.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index fb2b3d8..3734d16 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -31,6 +31,7 @@
 #include <linux/of.h>
 #include <linux/of_platform.h>
 #include <linux/err.h>
+#include <linux/pinctrl/consumer.h>
 
 #include "omap-usb.h"
 
@@ -111,6 +112,7 @@ struct usbhs_hcd_omap {
 	struct usbhs_omap_platform_data	*pdata;
 
 	u32				usbhs_rev;
+	bool				no_idle;
 };
 /*-------------------------------------------------------------------------*/
 
@@ -325,6 +327,7 @@ static int usbhs_runtime_resume(struct device *dev)
 
 	dev_dbg(dev, "usbhs_runtime_resume\n");
 
+	pinctrl_pm_select_default_state(dev);
 	omap_tll_enable(pdata);
 
 	if (!IS_ERR(omap->ehci_logic_fck))
@@ -378,6 +381,12 @@ static int usbhs_runtime_suspend(struct device *dev)
 
 	dev_dbg(dev, "usbhs_runtime_suspend\n");
 
+	if (omap->no_idle) {
+		dev_dbg(dev, "%s: Not suspending as IDLE pins not available\n",
+					__func__);
+		return -EBUSY;
+	}
+
 	for (i = 0; i < omap->nports; i++) {
 		switch (pdata->port_mode[i]) {
 		case OMAP_EHCI_PORT_MODE_HSIC:
@@ -401,6 +410,7 @@ static int usbhs_runtime_suspend(struct device *dev)
 		clk_disable(omap->ehci_logic_fck);
 
 	omap_tll_disable(pdata);
+	pinctrl_pm_select_idle_state(dev);
 
 	return 0;
 }
@@ -608,6 +618,14 @@ static int usbhs_omap_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
+	if (!dev->pins || !dev->pins->idle_state) {
+		/* If IDLE pins are not available, we can't remote wakeup,
+		 * so prevent idling in that case.
+		 */
+		omap->no_idle = true;
+		dev_info(dev, "No IDLE pins so runtime idle disabled\n");
+	}
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	omap->uhh_base = devm_ioremap_resource(dev, res);
 	if (IS_ERR(omap->uhh_base))
@@ -796,6 +814,8 @@ static int usbhs_omap_probe(struct platform_device *pdev)
 		}
 	}
 
+	pinctrl_pm_select_default_state(dev);
+
 	return 0;
 
 err_alloc:
@@ -872,6 +892,8 @@ static int usbhs_omap_remove(struct platform_device *pdev)
 
 	/* remove children */
 	device_for_each_child(&pdev->dev, NULL, usbhs_omap_remove_child);
+	pinctrl_pm_select_idle_state(&pdev->dev);
+
 	return 0;
 }
 
-- 
1.7.4.1



From rogerq at ti.com  Wed Jul 10 12:23:13 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 10 Jul 2013 19:23:13 +0300
Subject: [PATCH 5/6] USB: Support wakeup IRQ for suspended controllers
In-Reply-To: <1373473081-27181-1-git-send-email-rogerq@ti.com>
References: <1373473081-27181-1-git-send-email-rogerq@ti.com>
Message-ID: <1373473393-27552-1-git-send-email-rogerq@ti.com>

Some platforms e.g. ehci-omap can generate an interrupt
(i.e. remote wakeup) even when the controller is suspended i.e.
HW_ACCESSIBLE is cleared.

Introduce a flag "has_wakeup_irq" in struct usb_hcd to indicate
such cases.

We tackle this case by disabling the IRQ, scheduling a
hub resume and enabling back the IRQ after the controller has
resumed. This ensures that the IRQ handler runs only after the
controller is accessible.

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 drivers/usb/core/hcd.c  |   21 ++++++++++++++++++++-
 include/linux/usb/hcd.h |    3 +++
 2 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 014dc99..933d8f1 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2161,6 +2161,11 @@ static void hcd_resume_work(struct work_struct *work)
 	usb_lock_device(udev);
 	usb_remote_wakeup(udev);
 	usb_unlock_device(udev);
+	if (HCD_IRQ_DISABLED(hcd)) {
+		/* We can now process IRQs so enable IRQ */
+		clear_bit(HCD_FLAG_IRQ_DISABLED, &hcd->flags);
+		enable_irq(hcd->irq);
+	}
 }
 
 /**
@@ -2248,7 +2253,21 @@ irqreturn_t usb_hcd_irq (int irq, void *__hcd)
 	 */
 	local_irq_save(flags);
 
-	if (unlikely(HCD_DEAD(hcd) || !HCD_HW_ACCESSIBLE(hcd)))
+	if (unlikely(HCD_DEAD(hcd)))
+		rc = IRQ_NONE;
+	else if (unlikely(!HCD_HW_ACCESSIBLE(hcd) && hcd->has_wakeup_irq)) {
+		/*
+		 * We got a wakeup interrupt while the controller was
+		 * suspending or suspended.  We can't handle it now, so
+		 * disable the IRQ and resume the root hub (and hence
+		 * the controller too).
+		 */
+		disable_irq_nosync(hcd->irq);
+		set_bit(HCD_FLAG_IRQ_DISABLED, &hcd->flags);
+		usb_hcd_resume_root_hub(hcd);
+
+		rc = IRQ_HANDLED;
+	} else if (unlikely(!HCD_HW_ACCESSIBLE(hcd)))
 		rc = IRQ_NONE;
 	else if (hcd->driver->irq(hcd) == IRQ_NONE)
 		rc = IRQ_NONE;
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 1e88377..5eb9f85 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -110,6 +110,7 @@ struct usb_hcd {
 #define HCD_FLAG_WAKEUP_PENDING		4	/* root hub is resuming? */
 #define HCD_FLAG_RH_RUNNING		5	/* root hub is running? */
 #define HCD_FLAG_DEAD			6	/* controller has died? */
+#define HCD_FLAG_IRQ_DISABLED		7	/* Interrupt was disabled */
 
 	/* The flags can be tested using these macros; they are likely to
 	 * be slightly faster than test_bit().
@@ -120,6 +121,7 @@ struct usb_hcd {
 #define HCD_WAKEUP_PENDING(hcd)	((hcd)->flags & (1U << HCD_FLAG_WAKEUP_PENDING))
 #define HCD_RH_RUNNING(hcd)	((hcd)->flags & (1U << HCD_FLAG_RH_RUNNING))
 #define HCD_DEAD(hcd)		((hcd)->flags & (1U << HCD_FLAG_DEAD))
+#define HCD_IRQ_DISABLED(hcd)	((hcd)->flags & (1U << HCD_FLAG_IRQ_DISABLED))
 
 	/* Flags that get set only during HCD registration or removal. */
 	unsigned		rh_registered:1;/* is root hub registered? */
@@ -132,6 +134,7 @@ struct usb_hcd {
 	unsigned		wireless:1;	/* Wireless USB HCD */
 	unsigned		authorized_default:1;
 	unsigned		has_tt:1;	/* Integrated TT in root hub */
+	unsigned		has_wakeup_irq:1; /* Can IRQ when suspended */
 
 	unsigned int		irq;		/* irq allocated */
 	void __iomem		*regs;		/* device memory/io */
-- 
1.7.4.1



From rogerq at ti.com  Wed Jul 10 12:23:25 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 10 Jul 2013 19:23:25 +0300
Subject: [PATCH 6/6] USB: ehci-omap: Implement suspend/resume
In-Reply-To: <1373473081-27181-1-git-send-email-rogerq@ti.com>
References: <1373473081-27181-1-git-send-email-rogerq@ti.com>
Message-ID: <1373473405-27589-1-git-send-email-rogerq@ti.com>

Call ehci_suspend/resume() during runtime suspend/resume
as well as system suspend/resume.

Use a flag "bound" to indicate that the HCD structures are valid.
This is only true between usb_add_hcd() and usb_remove_hcd() calls.

The flag can be used by omap_ehci_runtime_suspend/resume() handlers
to avoid calling ehci_suspend/resume() when we are no longer bound
to the HCD e.g. during probe() and remove();

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 drivers/usb/host/ehci-omap.c |   64 ++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 9bd7dfe..6d1fde97 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -69,6 +69,7 @@ static const char hcd_name[] = "ehci-omap";
 struct omap_hcd {
 	struct usb_phy *phy[OMAP3_HS_USB_PORTS]; /* one PHY for each port */
 	int nports;
+	bool bound;	/* HCD structures are valid */
 };
 
 static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
@@ -159,6 +160,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
 	hcd->rsrc_start = res->start;
 	hcd->rsrc_len = resource_size(res);
 	hcd->regs = regs;
+	hcd->has_wakeup_irq = true;
 	hcd_to_ehci(hcd)->caps = regs;
 
 	omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
@@ -216,6 +218,8 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
 		goto err_pm_runtime;
 	}
 
+	omap->bound = true;
+
 	/*
 	 * Bring PHYs out of reset for non PHY modes.
 	 * Even though HSIC mode is a PHY-less mode, the reset
@@ -232,6 +236,8 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
 		usb_phy_set_suspend(omap->phy[i], 0);
 	}
 
+	pm_runtime_put_sync(dev);
+
 	return 0;
 
 err_pm_runtime:
@@ -264,7 +270,9 @@ static int ehci_hcd_omap_remove(struct platform_device *pdev)
 	struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
 	int i;
 
+	pm_runtime_get_sync(dev);
 	usb_remove_hcd(hcd);
+	omap->bound = false;
 
 	for (i = 0; i < omap->nports; i++) {
 		if (omap->phy[i])
@@ -293,15 +301,67 @@ static const struct of_device_id omap_ehci_dt_ids[] = {
 
 MODULE_DEVICE_TABLE(of, omap_ehci_dt_ids);
 
+static int omap_ehci_suspend(struct device *dev)
+{
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
+
+	dev_dbg(dev, "%s\n", __func__);
+
+	return ehci_suspend(hcd, true);
+}
+
+static int omap_ehci_resume(struct device *dev)
+{
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
+
+	dev_dbg(dev, "%s\n", __func__);
+
+	return ehci_resume(hcd, false);
+}
+
+static int omap_ehci_runtime_suspend(struct device *dev)
+{
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
+	struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
+	bool do_wakeup = device_may_wakeup(dev);
+
+	dev_dbg(dev, "%s\n", __func__);
+
+	if (omap->bound)
+		ehci_suspend(hcd, do_wakeup);
+
+	return 0;
+}
+
+static int omap_ehci_runtime_resume(struct device *dev)
+{
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
+	struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
+
+	dev_dbg(dev, "%s\n", __func__);
+
+	if (omap->bound)
+		ehci_resume(hcd, false);
+
+	return 0;
+}
+
+
+static const struct dev_pm_ops omap_ehci_pm_ops = {
+	.suspend = omap_ehci_suspend,
+	.resume = omap_ehci_resume,
+	.runtime_suspend = omap_ehci_runtime_suspend,
+	.runtime_resume = omap_ehci_runtime_resume,
+};
+
 static struct platform_driver ehci_hcd_omap_driver = {
 	.probe			= ehci_hcd_omap_probe,
 	.remove			= ehci_hcd_omap_remove,
 	.shutdown		= ehci_hcd_omap_shutdown,
-	/*.suspend		= ehci_hcd_omap_suspend, */
-	/*.resume		= ehci_hcd_omap_resume, */
 	.driver = {
 		.name		= hcd_name,
 		.of_match_table = omap_ehci_dt_ids,
+		.pm		= &omap_ehci_pm_ops,
 	}
 };
 
-- 
1.7.4.1



From will.deacon at arm.com  Wed Jul 10 12:34:11 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Jul 2013 17:34:11 +0100
Subject: Seg fault occurs when running statically compiled binary from
 kernel using call_usermodehelper
In-Reply-To: <CAOiN93nH9fyHoz4yrZmJ-OKCy6ogdt5bYartXCBgP5eHMUBPdw@mail.gmail.com>
References: <CAOiN93mGTu9w9rVNCrbbH1sccXY9VJhaCmg+dS7Rk9mMgKHBaA@mail.gmail.com>
 <CAOiN93=Nx77RkbNuEJMV617MjV5+GmorF0G3vyLy1SwQcuCs+g@mail.gmail.com>
 <CAOiN93nH9fyHoz4yrZmJ-OKCy6ogdt5bYartXCBgP5eHMUBPdw@mail.gmail.com>
Message-ID: <20130710163410.GA30514@mudshark.cambridge.arm.com>

On Wed, Jul 10, 2013 at 11:42:25AM +0100, Ashish Sangwan wrote:
> Any heads up on this?
> 
> or could someone just advice what can we do to debug this?
> 
> The ret_from_fork currently looks like following:
> /*
>  * This is how we return from a fork.
>  */
> ENTRY(ret_from_fork)
>         bl      schedule_tail
>         cmp     r5, #0
>         movne   r0, r4
>         adrne   lr, BSYM(1f)
>         movne   pc, r5
> 1:      get_thread_info tsk
>         b       ret_slow_syscall
> ENDPROC(ret_from_fork)
> 
> Is this a real issue? Because we are getting this just for static binaries.

Ok, I've finally got to the bottom of this, but I'm not sure on the best way
to fix it. The issue is that libc expects r0 to contain a function pointer
to be invoked at exit (rtld_fini), to clean up after a dynamic linker. If
this pointer is NULL, then it is ignored. We actually zero this pointer in
our ELF_PLAT_INIT macro.

At the same time, we have this strange code called next from the ARM ELF
loader:

	regs->ARM_r2 = stack[2];	/* r2 (envp) */			\
	regs->ARM_r1 = stack[1];	/* r1 (argv) */			\
	regs->ARM_r0 = stack[0];	/* r0 (argc) */			\

which puts argc into r0. Usually this gets overwritten by the return value
of execve (0), so everything hangs together. With kernel threads this is
different since we do the exec from ____call_usermodehelper on the stack and
then return to the new application via ret_from_fork, which takes the
slowpath; popping r0 from pt_regs and making argc visible to the library.

When the application exits and libc starts running its exit functions, we
jump to hyperspace.

My inclination would be to remove the stack popping above (patch below),
but it's a user-visible change and I'm not sure if something like OABI
requires it.

Will

--->8

diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 06e7d50..413f387 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -54,7 +54,6 @@ struct thread_struct {
 
 #define start_thread(regs,pc,sp)                                       \
 ({                                                                     \
-       unsigned long *stack = (unsigned long *)sp;                     \
        memset(regs->uregs, 0, sizeof(regs->uregs));                    \
        if (current->personality & ADDR_LIMIT_32BIT)                    \
                regs->ARM_cpsr = USR_MODE;                              \
@@ -65,9 +64,6 @@ struct thread_struct {
        regs->ARM_cpsr |= PSR_ENDSTATE;                                 \
        regs->ARM_pc = pc & ~1;         /* pc */                        \
        regs->ARM_sp = sp;              /* sp */                        \
-       regs->ARM_r2 = stack[2];        /* r2 (envp) */                 \
-       regs->ARM_r1 = stack[1];        /* r1 (argv) */                 \
-       regs->ARM_r0 = stack[0];        /* r0 (argc) */                 \
        nommu_start_thread(regs);                                       \
 })
 


From tibor at harsszegi.com  Wed Jul 10 12:44:16 2013
From: tibor at harsszegi.com (Tibor Harsszegi)
Date: Wed, 10 Jul 2013 18:44:16 +0200
Subject: NSA310 + DT
In-Reply-To: <51DD8E8B.2040505@harsszegi.com>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <20130709202143.GD26223@lunn.ch>
 <2544f179ed4349545a25aa60d52a664a@harsszegi.com>
 <20130710134119.GA30885@lunn.ch> <51DD8E8B.2040505@harsszegi.com>
Message-ID: <51DD8F60.8040708@harsszegi.com>

Hello,

just attached a bootlog for a working 2.5 (same /dev/sda2 as the rootfs):
          __  __                      _ _
         |  \/  | __ _ _ ____   _____| | |
         | |\/| |/ _` | '__\ \ / / _ \ | |
         | |  | | (_| | |   \ V /  __/ | |
         |_|  |_|\__,_|_|    \_/ \___|_|_|
  _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
  \___/    |____/ \___/ \___/ \__|
  ** MARVELL BOARD: RD-88F6281A LE

U-Boot 1.1.4 (Feb 22 2011 - 10:31:35) Marvell version: 3.4.19

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFEE0

Soc: 88F6281 A1 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB
DRAM Total size 256MB  16bit width
Addresses 10M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (10M - 7M): Done
NAND:128 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)
Kernel address is 0xc80000.

Streaming disabled
Write allocate disabled

Module 0 is RGMII
Module 1 is TDM

USB 0: host mode
PEX 0: PCI Express Root Complex Interface
PEX interface detected Link X1
Net:   egiga0, egiga1 [PRIME]
Hit any key to stop autoboot:  0
NSA310>> setenv bootargs 'console=ttyS0,115200 root=/dev/sda2 
rootfstype=ext4'
NSA310>> bootm
## Booting image at 02000000 ...
Bad Magic Number
NSA310>> saveenv
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done
NSA310>> reboot
Unknown command 'reboot' - try 'help'
NSA310>> bootm 0x800000
## Booting image at 00800000 ...
Bad Magic Number
NSA310>> ?
          __  __                      _ _
         |  \/  | __ _ _ ____   _____| | |
         | |\/| |/ _` | '__\ \ / / _ \ | |
         | |  | | (_| | |   \ V /  __/ | |
         |_|  |_|\__,_|_|    \_/ \___|_|_|
  _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
  \___/    |____/ \___/ \___/ \__|
  ** MARVELL BOARD: RD-88F6281A LE

U-Boot 1.1.4 (Feb 22 2011 - 10:31:35) Marvell version: 3.4.19

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFEE0

Soc: 88F6281 A1 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB
DRAM Total size 256MB  16bit width
Addresses 10M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (10M - 7M): Done
NAND:128 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)
Kernel address is 0xc80000.

Streaming disabled
Write allocate disabled

Module 0 is RGMII
Module 1 is TDM

USB 0: host mode
PEX 0: PCI Express Root Complex Interface
PEX interface detected Link X1
Net:   egiga0, egiga1 [PRIME]
Hit any key to stop autoboot:  0

Reset IDE:
Marvell Serial ATA Adapter
Integrated Sata device found
[0 0 0]: Enable DMA mode (6)
   Device 0 @ 0 0:
Model: SAMSUNG HN-M500MBB                       Firm: 2AR10001 Ser#: 
S2R7J9CB602267
             Type: Hard Disk
             Supports 48-bit addressing
             Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)


2869242 bytes read
## Booting image at 00800000 ...
    Image Name:   Linux-3.10.0-77487-g7693569-dirt
    Created:      2013-07-10  16:32:23 UTC
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2869178 Bytes =  2.7 MB
    Load Address: 00008000
    Entry Point:  00008000
    Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.10.0-77487-g7693569-dirty (root at harsszegi.com) (gcc 
version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #3 PREEMPT Wed Jul 10 
18:28:53 CEST 2013
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Marvell Kirkwood (Flattened Device Tree), model: ZyXEL NSA310 TDC
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: console=ttyS0,115200 root=/dev/sda2 rootfstype=ext4
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256MB = 256MB total
Memory: 253636k/253636k available, 8508k reserved, 0K highmem
Virtual kernel memory layout:
     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
     modules : 0xbf000000 - 0xc0000000   (  16 MB)
       .text : 0xc0008000 - 0xc050f2e4   (5149 kB)
       .init : 0xc0510000 - 0xc0535770   ( 150 kB)
       .data : 0xc0536000 - 0xc0572fa0   ( 244 kB)
        .bss : 0xc0572fa0 - 0xc060c2c4   ( 613 kB)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:114
sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms
Console: colour dummy device 80x30
Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc03d1068 - 0xc03d10a4
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
Kirkwood: MV88F6281-A1, TCLK=200000000.
Feroceon L2: Enabling L2
Feroceon L2: Cache support initialised.
Kirkwood PCIe port 0: link up
PCI: bus0 uses PCIe port 0
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
pci_bus 0000:00: root bus resource [io  0x1000-0xffff]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: BAR 6: assigned [mem 0xe0000000-0xe000ffff pref]
pci 0000:00:01.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref]
pci 0000:00:01.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref]
pci 0000:00:01.0: BAR 0: assigned [io  0x1000-0x10ff]
bio: create slab <bio-0> at 0
USB Power Off: Failed to request enable GPIO21: -517
reg-fixed-voltage 1.regulator: Failed to register regulator: -517
platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
cfg80211: Calling CRDA to update world regulatory domain
Switching to clocksource orion_clocksource
NET: Registered protocol family 2
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP: reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
msgmni has been set to 495
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
mv_xor f1060800.xor: Marvell shared XOR driver
mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
mv_xor f1060800.xor: Marvell XOR: ( xor fill cpy )
mv_xor f1060900.xor: Marvell shared XOR driver
mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
mv_xor f1060900.xor: Marvell XOR: ( xor fill cpy )
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
console [ttyS0] enabled
loop: module loaded
sata_mv f1080000.sata: slots 32 ports 2
scsi0 : sata_mv
scsi1 : sata_mv
ata1: SATA max UDMA/133 irq 21
ata2: SATA max UDMA/133 irq 21
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 
3,3V 8-bit), 128MiB, page size: 2048, OOB size: 64
Scanning device for bad blocks
9 ofpart partitions found on MTD device orion_nand
Creating 9 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "uboot"
0x000000100000-0x000000180000 : "uboot_env"
0x000000180000-0x000000200000 : "key_store"
0x000000200000-0x000000280000 : "info"
0x000000280000-0x000000c80000 : "etc"
0x000000c80000-0x000001680000 : "kernel_1"
0x000001680000-0x000004640000 : "rootfs1"
0x000004640000-0x000005040000 : "kernel_2"
0x000005040000-0x000008000000 : "rootfs2"
libertas_sdio: Libertas SDIO driver
libertas_sdio: Copyright Pierre Ossman
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-orion: EHCI orion driver
orion-ehci f1050000.ehci: EHCI Host Controller
orion-ehci f1050000.ehci: new USB bus registered, assigned bus number 1
orion-ehci f1050000.ehci: irq 19, io mem 0xf1050000
orion-ehci f1050000.ehci: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
usbcore: registered new interface driver ums-datafab
usbcore: registered new interface driver ums-freecom
usbcore: registered new interface driver ums-jumpshot
usbcore: registered new interface driver ums-sddr09
usbcore: registered new interface driver ums-sddr55
mousedev: PS/2 mouse device common for all mice
rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0
i2c /dev entries driver
gpio_poweroff_probe: Could not get GPIO 48
platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
hwmon_vid: Unknown VRM version of your CPU
lm85 0-002e: Starting monitoring
orion_wdt: Initial timeout 21 sec
cpuidle: using governor ladder
cpuidle: using governor menu
leds-gpio gpio-leds.2: pins are not configured from the driver
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: no performance counters
oprofile: using timer interrupt.
TCP: cubic registered
NET: Registered protocol family 17
lib80211: common routines for IEEE802.11 drivers
USB Power Off: Failed to request enable GPIO21: -517
reg-fixed-voltage 1.regulator: Failed to register regulator: -517
platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
gpio_poweroff_probe: Could not get GPIO 48
platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
gpio-keys gpio_keys.1: Failed to request GPIO 46, error -517
platform gpio_keys.1: Driver gpio-keys requests probe deferral
rtc-mv f1010300.rtc: setting system clock to 2013-07-10 16:37:24 UTC 
(1373474244)
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
ata1.00: ATA-8: SAMSUNG HN-M500MBB, 2AR10001, max UDMA/133
ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
usb 1-1: new high-speed USB device number 2 using orion-ehci
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access     ATA      SAMSUNG HN-M500M 2AR1 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
sd 0:0:0:0: [sda] Write Protect is off
USB Power Off: Failed to request enable GPIO21: -517
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA
reg-fixed-voltage 1.regulator: Failed to register regulator: -517
platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
gpio_poweroff_probe: Could not get GPIO 48
platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
gpio-keys gpio_keys.1: Failed to request GPIO 46, error -517
platform gpio_keys.1: Driver gpio-keys requests probe deferral
  sda: sda1 sda2 sda3 < sda5 sda6 >
sd 0:0:0:0: [sda] Attached SCSI disk
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
USB Power Off: Failed to request enable GPIO21: -517
reg-fixed-voltage 1.regulator: Failed to register regulator: -517
platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
gpio_poweroff_probe: Could not get GPIO 48
platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
gpio-keys gpio_keys.1: Failed to request GPIO 46, error -517
platform gpio_keys.1: Driver gpio-keys requests probe deferral
ata2: SATA link down (SStatus 0 SControl F300)
VFS: Cannot open root device "sda2" or unknown-block(8,2): error -19
Please append a correct "root=" boot option; here are the available 
partitions:
1f00            1024 mtdblock0  (driver?)
1f01             512 mtdblock1  (driver?)
1f02             512 mtdblock2 usb 1-1.2: new high-speed USB device 
number 3 using orion-ehci
  (driver?)
1f03             512 mtdblock3  (driver?)
1f04           10240 mtdblock4  (driver?)
1f05           10240 mtdblock5  (driver?)
1f06           48896 mtdblock6  (driver?)
1f07           10240 mtdblock7  (driver?)
1f08           48896 mtdblock8  (driver?)
0800       488386584 sda  driver: sd
   0801          145408 sda1 0004cbfe-01
   0802         9765888 sda2 0004cbfe-02
   0803               1 sda3
   0805          487424 sda5 0004cbfe-05
   0806       477984768 sda6 0004cbfe-06
Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(8,2)
CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-77487-g7693569-dirty #3
[<c000cf6c>] (unwind_backtrace+0x0/0xf0) from [<c000adec>] 
(show_stack+0x10/0x14)
[<c000adec>] (show_stack+0x10/0x14) from [<c03c7514>] (panic+0x9c/0x1ec)
[<c03c7514>] (panic+0x9c/0x1ec) from [<c0510c58>] 
(mount_block_root+0x1a0/0x258)
[<c0510c58>] (mount_block_root+0x1a0/0x258) from [<c0510e00>] 
(mount_root+0xf0/0x118)
[<c0510e00>] (mount_root+0xf0/0x118) from [<c0510f48>] 
(prepare_namespace+0x120/0x174)
[<c0510f48>] (prepare_namespace+0x120/0x174) from [<c05108dc>] 
(kernel_init_freeable+0x16c/0x1b0)
[<c05108dc>] (kernel_init_freeable+0x16c/0x1b0) from [<c03c566c>] 
(kernel_init+0x8/0xe4)
[<c03c566c>] (kernel_init+0x8/0xe4) from [<c0008d10>] 
(ret_from_fork+0x14/0x24)
?
          __  __                      _ _
         |  \/  | __ _ _ ____   _____| | |
         | |\/| |/ _` | '__\ \ / / _ \ | |
         | |  | | (_| | |   \ V /  __/ | |
         |_|  |_|\__,_|_|    \_/ \___|_|_|
  _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
  \___/    |____/ \___/ \___/ \__|
  ** MARVELL BOARD: RD-88F6281A LE

U-Boot 1.1.4 (Feb 22 2011 - 10:31:35) Marvell version: 3.4.19

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFEE0

Soc: 88F6281 A1 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB
DRAM Total size 256MB  16bit width
Addresses 10M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (10M - 7M): Done
NAND:128 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)
Kernel address is 0xc80000.

Streaming disabled
Write allocate disabled

Module 0 is RGMII
Module 1 is TDM

USB 0: host mode
PEX 0: PCI Express Root Complex Interface
PEX interface detected Link X1
Net:   egiga0, egiga1 [PRIME]
Hit any key to stop autoboot:  0
NSA310>> usb start
(Re)start USB...
USB:   scanning bus for devices... 3 USB Device(s) found
        scanning bus for storage devices... 1 Storage Device(s) found
NSA310>> fatload usb 0 0x800000 uImage
reading uImage
.
....................................................................................................................................................................................................

3002408 bytes read
NSA310>> setenv bootargs 'console=ttyS0,115200 root=/dev/sda2'
NSA310>> bootm 0x800000
## Booting image at 00800000 ...
    Image Name:   Linux-3.5.1
    Created:      2012-09-24  17:18:17 UTC
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    3002344 Bytes =  2.9 MB
    Load Address: 00008000
    Entry Point:  00008000
    Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0
Initializing cgroup subsys cpu
Linux version 3.5.1 (peter at Ubuntu) (gcc version 4.6.3 (Ubuntu/Linaro 
4.6.3-1ubuntu5) ) #1 Mon Sep 24 19:17:28 CEST 2012
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Zyxel NSA-310
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: console=ttyS0,115200 root=/dev/sda2
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256MB = 256MB total
Memory: 253896k/253896k available, 8248k reserved, 0K highmem
Virtual kernel memory layout:
     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
     modules : 0xbf000000 - 0xc0000000   (  16 MB)
       .text : 0xc0008000 - 0xc0536930   (5307 kB)
       .init : 0xc0537000 - 0xc055c524   ( 150 kB)
       .data : 0xc055e000 - 0xc058f3a0   ( 197 kB)
        .bss : 0xc058f3c4 - 0xc05d19e0   ( 266 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:114
sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms
Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Initializing cgroup subsys blkio
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x464778 - 0x4647b4
devtmpfs: initialized
NET: Registered protocol family 16
Kirkwood: MV88F6281-A1, TCLK=200000000.
Feroceon L2: Enabling L2
Feroceon L2: Cache support initialised.
NSA310: Power resume enabled
NSA310: Power-off GPIO enabled
Kirkwood PCIe port 0:
link up
PCI: bus0 uses PCIe port 0
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: BAR 6: assigned [mem 0xe0000000-0xe000ffff pref]
pci 0000:00:01.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref]
pci 0000:00:01.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref]
pci 0000:00:01.0: BAR 0: assigned [io  0x1000-0x10ff]
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Advanced Linux Sound Architecture Driver Version 1.0.25.
Switching to clocksource orion_clocksource
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
NetWinder Floating Point Emulator V0.97 (double precision)
Installing knfsd (copyright (C) 1996 okir at monad.swb.de).
Key type cifs.spnego registered
NTFS driver 2.1.30 [Flags: R/W].
fuse init (API version 7.19)
Btrfs loaded
msgmni has been set to 495
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered (default)
io scheduler cfq registered
mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver
mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver
mv_xor mv_xor.0: Marvell XOR: ( xor cpy )
mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy )
mv_xor mv_xor.2: Marvell XOR: ( xor cpy )
mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy )
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
console [ttyS0] enabled
brd: module loaded
loop: module loaded
Loading iSCSI transport class v2.0-870.
iscsi: registered transport (tcp)
sata_mv sata_mv.0: cannot get optional clkdev
sata_mv sata_mv.0: slots 32 ports 2
scsi0 : sata_mv
scsi1 : sata_mv
ata1: SATA max UDMA/133 irq 21
ata2: SATA max UDMA/133 irq 21
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 
3,3V 8-bit), page size: 2048, OOB size: 64
Scanning device for bad blocks
Creating 9 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "uboot"
0x000000100000-0x000000180000 : "uboot_env"
0x000000180000-0x000000200000 : "key_store"
0x000000200000-0x000000280000 : "info"
0x000000280000-0x000000c80000 : "etc"
0x000000c80000-0x000001680000 : "kernel_1"
0x000001680000-0x000004640000 : "rootfs1"
0x000004640000-0x000005040000 : "kernel_2"
0x000005040000-0x000008000000 : "rootfs2"
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk at qualcomm.com>
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:00:01.0: eth0: RTL8168d/8111d at 0xd0806000, 
00:00:00:00:00:30, XID 083000c0 IRQ 9
r8169 0000:00:01.0: eth0: jumbo features [frames: 9200 bytes, tx 
checksumming: ko]
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
orion-ehci orion-ehci.0: Marvell Orion EHCI
orion-ehci orion-ehci.0: new USB bus registered, assigned bus number 1
orion-ehci orion-ehci.0: irq 19, io mem 0xf1050000
orion-ehci orion-ehci.0: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: Marvell Orion EHCI
usb usb1: Manufacturer: Linux 3.5.1 ehci_hcd
usb usb1: SerialNumber: orion-ehci.0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
rtc-mv rtc-mv: rtc core: registered rtc-mv as rtc0
i2c /dev entries driver
hwmon_vid: Unknown VRM version of your CPU
lm85 0-002e: Starting monitoring
orion_wdt: Initial timeout 21 sec
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usbcore: registered new interface driver snd-usb-audio
TCP: cubic registered
NET: Registered protocol family 10
sit: IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
Key type dns_resolver registered
registered taskstats version 1
input: gpio-keys as /devices/platform/gpio-keys/input/input0
rtc-mv rtc-mv: setting system clock to 2013-07-10 16:41:21 UTC (1373474481)
ALSA device list:
   No soundcards found.
usb 1-1: new high-speed USB device number 2 using orion-ehci
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
ata1.00: ATA-8: SAMSUNG HN-M500MBB, 2AR10001, max UDMA/133
ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access     ATA      SAMSUNG HN-M500M 2AR1 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA
usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-1: Product: USB2.0 Hub
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
ata2: SATA link down (SStatus 0 SControl F300)
usb 1-1.2: new high-speed USB device number 3 using orion-ehci
  sda: sda1 sda2 sda3 < sda5 sda6 >
sd 0:0:0:0: [sda] Attached SCSI disk
EXT2-fs (sda2): error: couldn't mount because of unsupported optional 
features (240)
usb 1-1.2: New USB device found, idVendor=0951, idProduct=1607
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.2: Product: DataTraveler 2.0
usb 1-1.2: Manufacturer: Kingston
usb 1-1.2: SerialNumber: 5B7C15001BF2
scsi2 : usb-storage 1-1.2:1.0
EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) on device 8:2.
devtmpfs: mounted
Freeing init memory: 148K
INIT: version 2.88 booting
scsi 2:0:0:0: Direct-Access     Kingston DataTraveler 2.0 PMAP PQ: 0 
ANSI: 0 CCS
sd 2:0:0:0: [sdb] 1953792 512-byte logical blocks: (1.00 GB/954 MiB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] No Caching mode page present
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sd 2:0:0:0: [sdb] No Caching mode page present
sd 2:0:0:0: [sdb] Assuming drive cache: write through
  sdb: sdb1
sd 2:0:0:0: [sdb] No Caching mode page present
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sd 2:0:0:0: [sdb] Attached SCSI removable disk
[info] Using makefile-style concurrent boot in runlevel S.
findfs: unable to resolve 'UUID=07ec974b-3603-488f-91d9-da5dcb3a76f8'
[....] Starting the hotplug events dispatcher: udevdudevd[693]: starting 
version 175
. ok
[....] Synthesizing the initial hotplug events...done.
[....] Waiting for /dev to be fully populated...done.
[....] Setting preliminary keymap...done.
[....] Setting parameters of disc: (none). ok
[....] Activating swap...Adding 487420k swap on /dev/sda5. Priority:-1 
extents:1 across:487420k
done.
EXT4-fs (sda2): re-mounted. Opts: (null)
[....] Checking root file system...fsck from util-linux 2.20.1
Debian: clean, 83959/610800 files, 479183/2441472 blocks
done.
EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
[....] Cleaning up temporary files... /tmp /run/shm. ok
[....] Loading kernel modules...done.
[....] Activating lvm and md swap...done.
[....] Checking file systems...fsck from util-linux 2.20.1
boot: clean, 16/72720 files, 27148/145408 blocks
home has been mounted 27 times without being checked, check forced.
NSA310: USB power enabled==================================    - 93.2%
home: 24/29876224 files (0.0% non-contiguous), 2222043/119496192 blocks
done.
[....] Mounting local filesystems...EXT4-fs (sda6): mounted filesystem 
with ordered data mode. Opts: (null)
done.
[....] Activating swapfile swap...done.
[....] Cleaning up temporary files.... ok
[....] Setting kernel variables ...done.
[....] Configuring network interfaces...r8169 0000:00:01.0: eth0: unable 
to load firmware patch rtl_nic/rtl8168d-2.fw (-2)
r8169 0000:00:01.0: eth0: link down
r8169 0000:00:01.0: eth0: link down
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
r8169 0000:00:01.0: eth0: link up
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
done.
[....] Starting rpcbind daemon.... ok
[....] Starting NFS common utilities: statd idmapd. ok
[....] Cleaning up temporary files.... ok
[info] Setting console screen modes.
[info] Skipping font and keymap setup (handled by console-setup).
[....] Setting up console font and keymap...done.
[....] Setting sensors limits. ok
INIT: Entering runlevel: 2
[info] Using makefile-style concurrent boot in runlevel 2.
[....] Starting rpcbind daemon...[....] Already running.. ok
[....] Starting NFS common utilities: statd idmapd. ok
[....] Not starting NFS kernel daemon: no exports. ... (warning).
[....] Starting enhanced syslogd: rsyslogd. ok
[....] Starting ACPI services...RTNETLINK1 answers: No such file or 
directory
acpid: error talking to the kernel via netlink
. ok
[....] Starting anac(h)ronistic cron: anacron. ok
[....] Starting deferred execution scheduler: atd. ok
[....] Starting periodic command scheduler: cron. ok
[....] Starting system message bus: dbus. ok
[....] Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon. ok
[....] Starting MTA:[....] Starting bluetooth: bluetoothd. ok
  exim4. ok
[....] Starting internet superserver: inetd. ok
[....] Starting Common Unix Printing System: cupsd. ok
[....] Starting Samba daemons: nmbdsaned disabled; edit /etc/default/saned
[....] Starting OpenBSD Secure Shell server: sshd. ok
  smbd. ok
[....] Starting the Winbind daemon: winbind. ok
r8169 0000:00:01.0: eth0: link down
r8169 0000:00:01.0: eth0: link down
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
100000
r8169 0000:00:01.0: eth0: link up
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Debian GNU/Linux 7 nsa310 ttyS0

nsa310 login:

> Hello Andrew,
>
> I did a:
>
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make clean
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make kirkwood_defconfig
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make zImage
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make dtbs
> cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-nsa310-tdc.dtb > 
> /tmp/X
> mv /tmp/X arch/arm/boot/zImage
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make modules
>
> [attached .config]
>
> copied the uImage over the NSA310, rebooted.
> Good news: console is back
> Bad news: LEDs still don't work (all green), kernel stops (tried 
> forcing rootfstype=ext4, didn't help)
> Bootlog:
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 3.10.0-77487-g7693569-dirty (root at harsszegi.com) (gcc 
> version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #3 PREEMPT Wed Jul 10 
> 18:28:53 CEST 2013
> CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
> CPU: VIVT data cache, VIVT instruction cache
> Machine: Marvell Kirkwood (Flattened Device Tree), model: ZyXEL NSA310 
> TDC
> Memory policy: ECC disabled, Data cache writeback
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
> Kernel command line: console=ttyS0,115200 root=/dev/sda2 rootfstype=ext4
> PID hash table entries: 1024 (order: 0, 4096 bytes)
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 256MB = 256MB total
> Memory: 253636k/253636k available, 8508k reserved, 0K highmem
> Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
> vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
> lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
> modules : 0xbf000000 - 0xc0000000 ( 16 MB)
> .text : 0xc0008000 - 0xc050f2e4 (5149 kB)
> .init : 0xc0510000 - 0xc0535770 ( 150 kB)
> .data : 0xc0536000 - 0xc0572fa0 ( 244 kB)
> .bss : 0xc0572fa0 - 0xc060c2c4 ( 613 kB)
> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> Preemptible hierarchical RCU implementation.
> NR_IRQS:114
> sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms
> Console: colour dummy device 80x30
> Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> Setting up static identity map for 0xc03d1068 - 0xc03d10a4
> pinctrl core: initialized pinctrl subsystem
> regulator-dummy: no parameters
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> Kirkwood: MV88F6281-A1, TCLK=200000000.
> Feroceon L2: Enabling L2
> Feroceon L2: Cache support initialised.
> Kirkwood PCIe port 0: link up
> PCI: bus0 uses PCIe port 0
> PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
> pci_bus 0000:00: root bus resource [io 0x1000-0xffff]
> pci_bus 0000:00: No busn resource found for root bus, will use [bus 
> 00-ff]
> PCI: bus0: Fast back to back transfers disabled
> pci 0000:00:01.0: BAR 6: assigned [mem 0xe0000000-0xe000ffff pref]
> pci 0000:00:01.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref]
> pci 0000:00:01.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref]
> pci 0000:00:01.0: BAR 0: assigned [io 0x1000-0x10ff]
> bio: create slab <bio-0> at 0
> USB Power Off: Failed to request enable GPIO21: -517
> reg-fixed-voltage 1.regulator: Failed to register regulator: -517
> platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
> vgaarb: loaded
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> cfg80211: Calling CRDA to update world regulatory domain
> Switching to clocksource orion_clocksource
> NET: Registered protocol family 2
> TCP established hash table entries: 2048 (order: 2, 16384 bytes)
> TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
> TCP: Hash tables configured (established 2048 bind 2048)
> TCP: reno registered
> UDP hash table entries: 256 (order: 0, 4096 bytes)
> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> NET: Registered protocol family 1
> RPC: Registered named UNIX socket transport module.
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
> msgmni has been set to 495
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> mv_xor f1060800.xor: Marvell shared XOR driver
> mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
> mv_xor f1060800.xor: Marvell XOR: ( xor fill cpy )
> mv_xor f1060900.xor: Marvell shared XOR driver
> mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
> mv_xor f1060900.xor: Marvell XOR: ( xor fill cpy )
> Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
> console [ttyS0] enabled
> loop: module loaded
> sata_mv f1080000.sata: slots 32 ports 2
> scsi0 : sata_mv
> scsi1 : sata_mv
> ata1: SATA max UDMA/133 irq 21
> ata2: SATA max UDMA/133 irq 21
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 
> 3,3V 8-bit), 128MiB, page size: 2048, OOB size: 64
> Scanning device for bad blocks
> 9 ofpart partitions found on MTD device orion_nand
> Creating 9 MTD partitions on "orion_nand":
> 0x000000000000-0x000000100000 : "uboot"
> 0x000000100000-0x000000180000 : "uboot_env"
> 0x000000180000-0x000000200000 : "key_store"
> 0x000000200000-0x000000280000 : "info"
> 0x000000280000-0x000000c80000 : "etc"
> 0x000000c80000-0x000001680000 : "kernel_1"
> 0x000001680000-0x000004640000 : "rootfs1"
> 0x000004640000-0x000005040000 : "kernel_2"
> 0x000005040000-0x000008000000 : "rootfs2"
> libertas_sdio: Libertas SDIO driver
> libertas_sdio: Copyright Pierre Ossman
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-pci: EHCI PCI platform driver
> ehci-orion: EHCI orion driver
> orion-ehci f1050000.ehci: EHCI Host Controller
> orion-ehci f1050000.ehci: new USB bus registered, assigned bus number 1
> orion-ehci f1050000.ehci: irq 19, io mem 0xf1050000
> orion-ehci f1050000.ehci: USB 2.0 started, EHCI 1.00
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> usbcore: registered new interface driver usb-storage
> usbcore: registered new interface driver ums-datafab
> usbcore: registered new interface driver ums-freecom
> usbcore: registered new interface driver ums-jumpshot
> usbcore: registered new interface driver ums-sddr09
> usbcore: registered new interface driver ums-sddr55
> mousedev: PS/2 mouse device common for all mice
> rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0
> i2c /dev entries driver
> gpio_poweroff_probe: Could not get GPIO 48
> platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
> hwmon_vid: Unknown VRM version of your CPU
> lm85 0-002e: Starting monitoring
> orion_wdt: Initial timeout 21 sec
> cpuidle: using governor ladder
> cpuidle: using governor menu
> leds-gpio gpio-leds.2: pins are not configured from the driver
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> oprofile: no performance counters
> oprofile: using timer interrupt.
> TCP: cubic registered
> NET: Registered protocol family 17
> lib80211: common routines for IEEE802.11 drivers
> USB Power Off: Failed to request enable GPIO21: -517
> reg-fixed-voltage 1.regulator: Failed to register regulator: -517
> platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
> gpio_poweroff_probe: Could not get GPIO 48
> platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
> gpio-keys gpio_keys.1: Failed to request GPIO 46, error -517
> platform gpio_keys.1: Driver gpio-keys requests probe deferral
> rtc-mv f1010300.rtc: setting system clock to 2013-07-10 16:37:24 UTC 
> (1373474244)
> ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
> ata1.00: ATA-8: SAMSUNG HN-M500MBB, 2AR10001, max UDMA/133
> ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
> usb 1-1: new high-speed USB device number 2 using orion-ehci
> ata1.00: configured for UDMA/133
> scsi 0:0:0:0: Direct-Access ATA SAMSUNG HN-M500M 2AR1 PQ: 0 ANSI: 5
> sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
> sd 0:0:0:0: [sda] Write Protect is off
> USB Power Off: Failed to request enable GPIO21: -517
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
> support DPO or FUA
> reg-fixed-voltage 1.regulator: Failed to register regulator: -517
> platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
> gpio_poweroff_probe: Could not get GPIO 48
> platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
> gpio-keys gpio_keys.1: Failed to request GPIO 46, error -517
> platform gpio_keys.1: Driver gpio-keys requests probe deferral
> sda: sda1 sda2 sda3 < sda5 sda6 >
> sd 0:0:0:0: [sda] Attached SCSI disk
> hub 1-1:1.0: USB hub found
> hub 1-1:1.0: 4 ports detected
> USB Power Off: Failed to request enable GPIO21: -517
> reg-fixed-voltage 1.regulator: Failed to register regulator: -517
> platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
> gpio_poweroff_probe: Could not get GPIO 48
> platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
> gpio-keys gpio_keys.1: Failed to request GPIO 46, error -517
> platform gpio_keys.1: Driver gpio-keys requests probe deferral
> ata2: SATA link down (SStatus 0 SControl F300)
> VFS: Cannot open root device "sda2" or unknown-block(8,2): error -19
> Please append a correct "root=" boot option; here are the available 
> partitions:
> 1f00 1024 mtdblock0 (driver?)
> 1f01 512 mtdblock1 (driver?)
> 1f02 512 mtdblock2 usb 1-1.2: new high-speed USB device number 3 using 
> orion-ehci
> (driver?)
> 1f03 512 mtdblock3 (driver?)
> 1f04 10240 mtdblock4 (driver?)
> 1f05 10240 mtdblock5 (driver?)
> 1f06 48896 mtdblock6 (driver?)
> 1f07 10240 mtdblock7 (driver?)
> 1f08 48896 mtdblock8 (driver?)
> 0800 488386584 sda driver: sd
> 0801 145408 sda1 0004cbfe-01
> 0802 9765888 sda2 0004cbfe-02
> 0803 1 sda3
> 0805 487424 sda5 0004cbfe-05
> 0806 477984768 sda6 0004cbfe-06
> Kernel panic - not syncing: VFS: Unable to mount root fs on 
> unknown-block(8,2)
> CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-77487-g7693569-dirty #3
> [<c000cf6c>] (unwind_backtrace+0x0/0xf0) from [<c000adec>] 
> (show_stack+0x10/0x14)
> [<c000adec>] (show_stack+0x10/0x14) from [<c03c7514>] (panic+0x9c/0x1ec)
> [<c03c7514>] (panic+0x9c/0x1ec) from [<c0510c58>] 
> (mount_block_root+0x1a0/0x258)
> [<c0510c58>] (mount_block_root+0x1a0/0x258) from [<c0510e00>] 
> (mount_root+0xf0/0x118)
> [<c0510e00>] (mount_root+0xf0/0x118) from [<c0510f48>] 
> (prepare_namespace+0x120/0x174)
> [<c0510f48>] (prepare_namespace+0x120/0x174) from [<c05108dc>] 
> (kernel_init_freeable+0x16c/0x1b0)
> [<c05108dc>] (kernel_init_freeable+0x16c/0x1b0) from [<c03c566c>] 
> (kernel_init+0x8/0xe4)
> [<c03c566c>] (kernel_init+0x8/0xe4) from [<c0008d10>] 
> (ret_from_fork+0x14/0x24)
>
>> Hi Tibor
>>
>> I created a DTS file based on the tree you gave me.
>>
>> Please could you try
>>
>> https://github.com/lunn/linux.git branch v3.10-nsa310-tdc
>>
>> and the DTS file arch/arm/boot/dts/kirkwood-nsa310-tdc.dts
>>
>> Please use
>>
>> make kirkwood_defconfig
>> make
>>
>> and it should have the lm85 built in.
>>
>> The two different NSA310 are mostly similar, just a few different gpio
>> LEDs and buttons, so i might actually refactor the two dts files with
>> what is shared. But lets get your box working first.
>>
>>       Andrew
>



From festevam at gmail.com  Wed Jul 10 12:53:01 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 10 Jul 2013 13:53:01 -0300
Subject: [PATCH 3/3] ARM: imx: mm-imx3: Free l2x0_base
In-Reply-To: <20130709182046.GD516@pengutronix.de>
References: <1373306318-15604-1-git-send-email-festevam@gmail.com>
 <1373306318-15604-3-git-send-email-festevam@gmail.com>
 <20130709062414.GG16656@S2101-09.ap.freescale.net>
 <CAOMZO5D4ivbqYovVA2CpXEemrAq8Nyn5By8-iL3SAnw=mpJ+og@mail.gmail.com>
 <20130709182046.GD516@pengutronix.de>
Message-ID: <CAOMZO5AeJVRL3VhLdYPtAq7-9+Dh3o=ntwhqYOrZZeR7TbBDyQ@mail.gmail.com>

Hi Sascha,

On Tue, Jul 9, 2013 at 3:20 PM, Sascha Hauer <s.hauer at pengutronix.de> wrote:

> l2x0_base is passed to l2x0_init which uses it for the outer cache
> maintenance operations. I wonder this doesn't crash your kernel.

l2x0_init() is called from arch/arm/mach-imx/mm-imx3.c first and then
from arch/arm/mm/cache-l2x0.c
later.

Why do we need to call it twice?

Can't we just do:

diff --git a/arch/arm/mach-imx/mm-imx3.c b/arch/arm/mach-imx/mm-imx3.c
index 0884ca9..94f3b4f 100644
--- a/arch/arm/mach-imx/mm-imx3.c
+++ b/arch/arm/mach-imx/mm-imx3.c
@@ -85,7 +85,6 @@ static void __iomem *imx3_ioremap_caller(phys_addr_t
phys_addr, size_t size,
 static void __init imx3_init_l2x0(void)
 {
 #ifdef CONFIG_CACHE_L2X0
-	void __iomem *l2x0_base;
 	void __iomem *clkctl_base;

 /*
@@ -105,14 +104,6 @@ static void __init imx3_init_l2x0(void)
 	} else {
 		pr_err("L2 cache: Cannot fix timing. Trying to continue without\n");
 	}
-
-	l2x0_base = ioremap(MX3x_L2CC_BASE_ADDR, 4096);
-	if (!l2x0_base) {
-		printk(KERN_ERR "remapping L2 cache area failed\n");
-		return;
-	}
-
-	l2x0_init(l2x0_base, 0x00030024, 0x00000000);
 #endif
 }


From andrew at lunn.ch  Wed Jul 10 12:53:42 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 10 Jul 2013 18:53:42 +0200
Subject: NSA310 + DT
In-Reply-To: <51DD8E8B.2040505@harsszegi.com>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <20130709202143.GD26223@lunn.ch>
 <2544f179ed4349545a25aa60d52a664a@harsszegi.com>
 <20130710134119.GA30885@lunn.ch> <51DD8E8B.2040505@harsszegi.com>
Message-ID: <20130710165342.GA31692@lunn.ch>

On Wed, Jul 10, 2013 at 06:40:43PM +0200, Tibor Harsszegi wrote:
> Hello Andrew,
> 
> I did a:
> 
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make clean
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make kirkwood_defconfig
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make zImage
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make dtbs
> cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-nsa310-tdc.dtb > /tmp/X
> mv /tmp/X arch/arm/boot/zImage
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make modules
> 
> [attached .config]
> 
> copied the uImage over the NSA310, rebooted.
> Good news: console is back

Great. Probably was OF_SERIAL_PLATFORM

> Bad news: LEDs still don't work (all green), kernel stops (tried
> forcing rootfstype=ext4, didn't help)

Ah, O.k. EXT4 is not part of kirkwood_defconfig. Hence it cannot mount
the root fs.

Please could you use make menuconfig and include it into the kernel
image. I will also update the patch later.

LEDs are not working because the GPIO driver is not loading.
I will see if i can spot an obvious typo etc.

  Andrew


From thomas.petazzoni at free-electrons.com  Wed Jul 10 12:57:06 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Jul 2013 18:57:06 +0200
Subject: pci-mvebu driver on km_kirkwood
In-Reply-To: <51DD88A4.1030506@keymile.com>
References: <51DD88A4.1030506@keymile.com>
Message-ID: <20130710185706.72b124a4@skate>

Gerlando,

On Wed, 10 Jul 2013 18:15:32 +0200, Gerlando Falauto wrote:

> I am trying to use the pci-mvebu driver on one of our km_kirkwood 
> boards. The board is based on Marvell's 98dx4122, which should 
> essentially be 6281 compatible.

Was this platform working with the old PCIe driver in mach-kirkwood/ ?


> The code I took from jcooper's repo:
> 
>    http://git.infradead.org/users/jcooper/linux.git
> 
> I took the tag
> 
>    dt-3.11-6
> 
> on top of which I merged:
> 
>    mvebu/pcie
>    mvebu/pcie_bridge
>    mvebu/pcie_kirkwood

Could you instead use the latest master from Linus tree? That would
avoid merge conflicts, and ensure you have all the necessary pieces.

> Only with the latest merge did I get some conflict on
> kirkwood.dtsi:
> 
> <<<<<<< HEAD
> 		ranges = <0x00000000 0xf1000000 0x0100000		
> 		          0xf4000000 0xf4000000 0x0000400
> =======
> 		ranges = <0x00000000 0xf1000000 0x4000000
> 		          0xe0000000 0xe0000000 0x8100000

The first cannot work, because it lacks the range for the PCIe. The
second should work. The correct merge should be:

 		ranges = <0x00000000 0xf1000000 0x0100000		
 		          0xf4000000 0xf4000000 0x0000400
 		          0xe0000000 0xe0000000 0x8100000>;

i.e, we've added the PCIe range (last line) and splitted the SRAM into
its own range (or something like that, don't remember the details, but
Ezequiel can confirm).

> <<<<<<< HEAD
> Kirkwood: MV88F6281-A0, TCLK=200000000.
> Feroceon L2: Cache support initialised, in WT override mode.
> mvebu-pcie pcie-controller.1: PCIe0.0: link up
> mvebu-pcie pcie-controller.1: PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
> pci_bus 0000:00: root bus resource [mem 0xffffffff-0x07fffffe]
> pci_bus 0000:00: root bus resource [bus 00-ff]
> pci 0000:00:01.0: [11ab:7846] type 01 class 0x060400
> PCI: bus0: Fast back to back transfers disabled
> pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> pci 0000:01:00.0: [10ee:0008] type 00 class 0x050000
> pci 0000:01:00.0: reg 10: [mem 0x00000000-0x00000fff]
> pci 0000:01:00.0: reg 14: [mem 0x00000000-0x07ffffff]
> pci 0000:01:00.0: reg 18: [mem 0x00000000-0x00000fff]
> pci 0000:01:00.0: reg 1c: [mem 0x00000000-0x007fffff]
> pci 0000:01:00.0: reg 20: [mem 0x00000000-0x00001fff]
> pci 0000:01:00.0: reg 24: [mem 0x00000000-0x00000fff]
> pci 0000:01:00.0: supports D1 D2
> pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot
> PCI: bus1: Fast back to back transfers disabled
> pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
> pci 0000:00:01.0: BAR 8: can't assign mem (size 0xc000000)
> pci 0000:01:00.0: BAR 1: can't assign mem (size 0x8000000)
> pci 0000:01:00.0: BAR 3: can't assign mem (size 0x800000)
> pci 0000:01:00.0: BAR 4: can't assign mem (size 0x2000)
> pci 0000:01:00.0: BAR 0: can't assign mem (size 0x1000)
> pci 0000:01:00.0: BAR 2: can't assign mem (size 0x1000)
> pci 0000:01:00.0: BAR 5: can't assign mem (size 0x1000)
> pci 0000:00:01.0: PCI bridge to [bus 01]

The first test you did cannot work at all, due to the incorrect ranges.

If you have the PCIe working with the old driver, can you pastebin
somewhere the complete boot log, as well as the output of "lspci
-vvv" ?

> Compared to a working configuration, here I see a spurious
> 
>    pci 0000:00:01.0: BAR 8: can't assign mem (size 0xc000000)
> 
> which I don't understand, plus all others which are failing.
> 
> It's weird how with the second configuration:
> 
>    mvebu-pcie pcie-controller.2: PCIe0.0: link up
>    mvebu-pcie pcie-controller.2: PCI host bridge to bus 0000:00
>    pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
>    pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
> 
> I get a second mvebu-pcie pcie-controller.2, although with a more 
> reasonable memory range.

A second mvebu-pcie controller? Is your Device Tree correct?

I'm not really sure to understand what's going on here. Can you post
the complete boot log, and test with the latest Linus git tree, where
all the PCIe support got merged?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From tibor at harsszegi.com  Wed Jul 10 12:57:16 2013
From: tibor at harsszegi.com (Tibor Harsszegi)
Date: Wed, 10 Jul 2013 18:57:16 +0200
Subject: NSA310 + DT
In-Reply-To: <20130710165342.GA31692@lunn.ch>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <20130709202143.GD26223@lunn.ch>
 <2544f179ed4349545a25aa60d52a664a@harsszegi.com>
 <20130710134119.GA30885@lunn.ch> <51DD8E8B.2040505@harsszegi.com>
 <20130710165342.GA31692@lunn.ch>
Message-ID: <51DD926C.1010205@harsszegi.com>

Cool, keep you posted.
> On Wed, Jul 10, 2013 at 06:40:43PM +0200, Tibor Harsszegi wrote:
>> Hello Andrew,
>>
>> I did a:
>>
>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make clean
>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make kirkwood_defconfig
>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make zImage
>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make dtbs
>> cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-nsa310-tdc.dtb > /tmp/X
>> mv /tmp/X arch/arm/boot/zImage
>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage
>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make modules
>>
>> [attached .config]
>>
>> copied the uImage over the NSA310, rebooted.
>> Good news: console is back
> Great. Probably was OF_SERIAL_PLATFORM
>
>> Bad news: LEDs still don't work (all green), kernel stops (tried
>> forcing rootfstype=ext4, didn't help)
> Ah, O.k. EXT4 is not part of kirkwood_defconfig. Hence it cannot mount
> the root fs.
>
> Please could you use make menuconfig and include it into the kernel
> image. I will also update the patch later.
>
> LEDs are not working because the GPIO driver is not loading.
> I will see if i can spot an obvious typo etc.
>
>    Andrew



From yadi.brar01 at gmail.com  Wed Jul 10 12:59:13 2013
From: yadi.brar01 at gmail.com (Yadwinder Singh Brar)
Date: Wed, 10 Jul 2013 22:29:13 +0530
Subject: [PATCH v2 1/6] clk: samsung: move common plls registration into
 separate function
In-Reply-To: <201307100057.48265.heiko@sntech.de>
References: <201307100057.06061.heiko@sntech.de>
 <201307100057.48265.heiko@sntech.de>
Message-ID: <CAKew6eUPBUZj4TuhNAjp6NitFUaeFBZscr_jqU3Y_wLi1m7Ekg@mail.gmail.com>

Hi Heiko,

On Wed, Jul 10, 2013 at 4:27 AM, Heiko St?bner <heiko at sntech.de> wrote:
> All Samsung PLLs use similar code to register the clocks and clkdev lookups.
> Therefore move these into a separate function to reduce code duplication.
>
> Suggested-by: Russell King <linux at arm.linux.org.uk>
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> ---

I have posted patch for adding common pll registration function
which some how missed to get merged. I hope will get merged after rc1.
Please give a look at that :
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg19543.html

Regards,
Yadwinder


From festevam at gmail.com  Wed Jul 10 13:06:49 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 10 Jul 2013 14:06:49 -0300
Subject: imx25: How to get frame buffer device in a system using device
 tree
In-Reply-To: <CAO8h3eGhF8DRO73W9GkepUKAF-6v1EmWdMS_Gq+dA_2v5mJ2aQ@mail.gmail.com>
References: <CAO8h3eFq9WhvZYbbeFfWgVEXViR8MAcGaztsvvaLpFSW-W6CfA@mail.gmail.com>
 <CAOMZO5Aat-iAN_TJ6BXEopB+WCkKgLjWh67sCXg0jd1DtzmKSQ@mail.gmail.com>
 <CAO8h3eHAfV808izZzvpPc+z6iQPr14q8OmryNs5sC+VcNk+iLg@mail.gmail.com>
 <CAOMZO5CgAs+hR41=WdJ=jxS5gZf=opOrCXufixBh_CMP0n2TFA@mail.gmail.com>
 <CAO8h3eGhF8DRO73W9GkepUKAF-6v1EmWdMS_Gq+dA_2v5mJ2aQ@mail.gmail.com>
Message-ID: <CAOMZO5CrZjDZjqaaQTX4=ZGO_6chFMr9qAHhqyVGBdxBvimYSw@mail.gmail.com>

Hi Matthias,

On Mon, Jul 8, 2013 at 3:31 AM, Matthias Wei?er <m.weisser.m at gmail.com> wrote:
> Hi Fabio
>
> 2013/7/5 Fabio Estevam <festevam at gmail.com>:
>> Hi Matthias,
>>
>> On Fri, Jul 5, 2013 at 4:37 AM, Matthias Wei?er <m.weisser.m at gmail.com> wrote:
>>
>>> Thanks for the links. That made some things clearer for me. But I am
>>> still a bit confused about the driver (imxfb.c) itself. From what I
>>> can see it is not dt aware as there is no of_device_id structure with
>>> the compatible entries. I think I have to add dt support to the
>>> framebuffer driver. Am I right?
>>
>> Yes, you need to apply this one:
>> http://marc.info/?l=linux-fbdev&m=136956466617736&w=2
>
> OK. Done that and it works like a charm. Thanks a lot.

Great, care to submit patches for adding mx25 fb support?


From tibor at harsszegi.com  Wed Jul 10 13:13:48 2013
From: tibor at harsszegi.com (Tibor Harsszegi)
Date: Wed, 10 Jul 2013 19:13:48 +0200
Subject: NSA310 + DT
In-Reply-To: <51DD926C.1010205@harsszegi.com>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <20130709202143.GD26223@lunn.ch>
 <2544f179ed4349545a25aa60d52a664a@harsszegi.com>
 <20130710134119.GA30885@lunn.ch> <51DD8E8B.2040505@harsszegi.com>
 <20130710165342.GA31692@lunn.ch> <51DD926C.1010205@harsszegi.com>
Message-ID: <51DD964C.7020200@harsszegi.com>

WTF. Andrew. It works COMPLETELY.
The memory mapped GPIO was working from the .config (don't ask me how).

* sensors
* LEDs
* bootup works

Awesome work thanks a lot!!!!
> Cool, keep you posted.
>> On Wed, Jul 10, 2013 at 06:40:43PM +0200, Tibor Harsszegi wrote:
>>> Hello Andrew,
>>>
>>> I did a:
>>>
>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make clean
>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make kirkwood_defconfig
>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make zImage
>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make dtbs
>>> cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-nsa310-tdc.dtb > 
>>> /tmp/X
>>> mv /tmp/X arch/arm/boot/zImage
>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage
>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make modules
>>>
>>> [attached .config]
>>>
>>> copied the uImage over the NSA310, rebooted.
>>> Good news: console is back
>> Great. Probably was OF_SERIAL_PLATFORM
>>
>>> Bad news: LEDs still don't work (all green), kernel stops (tried
>>> forcing rootfstype=ext4, didn't help)
>> Ah, O.k. EXT4 is not part of kirkwood_defconfig. Hence it cannot mount
>> the root fs.
>>
>> Please could you use make menuconfig and include it into the kernel
>> image. I will also update the patch later.
>>
>> LEDs are not working because the GPIO driver is not loading.
>> I will see if i can spot an obvious typo etc.
>>
>>    Andrew
>



From tibor at harsszegi.com  Wed Jul 10 13:15:37 2013
From: tibor at harsszegi.com (Tibor Harsszegi)
Date: Wed, 10 Jul 2013 19:15:37 +0200
Subject: NSA310 + DT
In-Reply-To: <51DD964C.7020200@harsszegi.com>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <20130709202143.GD26223@lunn.ch>
 <2544f179ed4349545a25aa60d52a664a@harsszegi.com>
 <20130710134119.GA30885@lunn.ch> <51DD8E8B.2040505@harsszegi.com>
 <20130710165342.GA31692@lunn.ch> <51DD926C.1010205@harsszegi.com>
 <51DD964C.7020200@harsszegi.com>
Message-ID: <51DD96B9.8030900@harsszegi.com>

Ok, was too fast :(
After a reboot the LEDs are gone, all green :(

t.
> WTF. Andrew. It works COMPLETELY.
> The memory mapped GPIO was working from the .config (don't ask me how).
>
> * sensors
> * LEDs
> * bootup works
>
> Awesome work thanks a lot!!!!
>> Cool, keep you posted.
>>> On Wed, Jul 10, 2013 at 06:40:43PM +0200, Tibor Harsszegi wrote:
>>>> Hello Andrew,
>>>>
>>>> I did a:
>>>>
>>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make clean
>>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make kirkwood_defconfig
>>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make zImage
>>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make dtbs
>>>> cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-nsa310-tdc.dtb 
>>>> > /tmp/X
>>>> mv /tmp/X arch/arm/boot/zImage
>>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage
>>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make modules
>>>>
>>>> [attached .config]
>>>>
>>>> copied the uImage over the NSA310, rebooted.
>>>> Good news: console is back
>>> Great. Probably was OF_SERIAL_PLATFORM
>>>
>>>> Bad news: LEDs still don't work (all green), kernel stops (tried
>>>> forcing rootfstype=ext4, didn't help)
>>> Ah, O.k. EXT4 is not part of kirkwood_defconfig. Hence it cannot mount
>>> the root fs.
>>>
>>> Please could you use make menuconfig and include it into the kernel
>>> image. I will also update the patch later.
>>>
>>> LEDs are not working because the GPIO driver is not loading.
>>> I will see if i can spot an obvious typo etc.
>>>
>>>    Andrew
>>
>



From andrew at lunn.ch  Wed Jul 10 13:23:58 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 10 Jul 2013 19:23:58 +0200
Subject: NSA310 + DT
In-Reply-To: <51DD96B9.8030900@harsszegi.com>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <20130709202143.GD26223@lunn.ch>
 <2544f179ed4349545a25aa60d52a664a@harsszegi.com>
 <20130710134119.GA30885@lunn.ch> <51DD8E8B.2040505@harsszegi.com>
 <20130710165342.GA31692@lunn.ch> <51DD926C.1010205@harsszegi.com>
 <51DD964C.7020200@harsszegi.com> <51DD96B9.8030900@harsszegi.com>
Message-ID: <20130710172358.GB31692@lunn.ch>

On Wed, Jul 10, 2013 at 07:15:37PM +0200, Tibor Harsszegi wrote:
> Ok, was too fast :(
> After a reboot the LEDs are gone, all green :(

Please do not top post. Answer comes after questions, not before...

root at qnap:/sys# find . -name *gpio*
./bus/platform/devices/gpio_keys.1
./bus/platform/devices/f1010140.gpio
./bus/platform/devices/f1010100.gpio
./bus/platform/drivers/leds-gpio
./bus/platform/drivers/mvebu-gpio
./bus/platform/drivers/mvebu-gpio/f1010140.gpio
./bus/platform/drivers/mvebu-gpio/f1010100.gpio
./bus/platform/drivers/poweroff-gpio
./bus/platform/drivers/gpio-keys
./bus/platform/drivers/gpio-keys/gpio_keys.1
./devices/gpio_keys.1
./devices/ocp.0/f1010140.gpio
./devices/ocp.0/f1010140.gpio/gpio
./devices/ocp.0/f1010140.gpio/gpio/gpiochip32
./devices/ocp.0/f1010140.gpio/gpio/gpiochip32/ngpio
./devices/ocp.0/f1010100.gpio
./devices/ocp.0/f1010100.gpio/gpio
./devices/ocp.0/f1010100.gpio/gpio/gpiochip0
./devices/ocp.0/f1010100.gpio/gpio/gpiochip0/ngpio
./class/gpio
./class/gpio/gpiochip32
./class/gpio/gpiochip0

You should have something similar.

I have no LEDs on this box, but you should should see entries in

/sys/class/leds

What you probably see in the kernel logs is lots of warnings from gpio
about deferred, but then they get repeated later and are successful.

	Andrew


From tibor at harsszegi.com  Wed Jul 10 13:29:12 2013
From: tibor at harsszegi.com (Tibor Harsszegi)
Date: Wed, 10 Jul 2013 19:29:12 +0200
Subject: NSA310 + DT
In-Reply-To: <20130710172358.GB31692@lunn.ch>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <20130709202143.GD26223@lunn.ch>
 <2544f179ed4349545a25aa60d52a664a@harsszegi.com>
 <20130710134119.GA30885@lunn.ch> <51DD8E8B.2040505@harsszegi.com>
 <20130710165342.GA31692@lunn.ch> <51DD926C.1010205@harsszegi.com>
 <51DD964C.7020200@harsszegi.com> <51DD96B9.8030900@harsszegi.com>
 <20130710172358.GB31692@lunn.ch>
Message-ID: <51DD99E8.4090507@harsszegi.com>

Hello,
> root at qnap:/sys# find . -name *gpio*
root at nsa310:/sys# find . -name *gpio*
./bus/platform/devices/gpio_keys.1
./bus/platform/devices/f1010140.gpio
./bus/platform/devices/gpio-leds.2
./bus/platform/devices/f1010100.gpio
./bus/platform/devices/gpio_poweroff.3
./bus/platform/drivers/leds-gpio
./bus/platform/drivers/mvebu-gpio
./bus/platform/drivers/mvebu-gpio/f1010140.gpio
./bus/platform/drivers/mvebu-gpio/f1010100.gpio
./bus/platform/drivers/poweroff-gpio
./bus/platform/drivers/gpio-keys
./bus/platform/drivers/basic-mmio-gpio
./devices/gpio_keys.1
./devices/ocp.0/f1010140.gpio
./devices/ocp.0/f1010140.gpio/gpio
./devices/ocp.0/f1010140.gpio/gpio/gpiochip32
./devices/ocp.0/f1010140.gpio/gpio/gpiochip32/ngpio
./devices/ocp.0/f1010100.gpio
./devices/ocp.0/f1010100.gpio/gpio
./devices/ocp.0/f1010100.gpio/gpio/gpiochip0
./devices/ocp.0/f1010100.gpio/gpio/gpiochip0/ngpio
./devices/gpio-leds.2
./devices/gpio_poweroff.3
./class/gpio
./class/gpio/gpiochip32
./class/gpio/gpiochip0

> I have no LEDs on this box, but you should should see entries in
>
> /sys/class/leds
>
No, I don't.

root at nsa310:/sys# ls -la /sys/class/leds/
total 0
drwxr-xr-x 2 root root 0 j??l 10 19:24 .
drwxr-xr-x 34 root root 0 j??l 10 19:24 ..

Cheers,
t.

> What you probably see in the kernel logs is lots of warnings from gpio
> about deferred, but then they get repeated later and are successful.
>
> 	Andrew



From festevam at gmail.com  Wed Jul 10 13:29:25 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 10 Jul 2013 14:29:25 -0300
Subject: [PATCH 3/3] ARM: imx: mm-imx3: Free l2x0_base
In-Reply-To: <CAOMZO5AeJVRL3VhLdYPtAq7-9+Dh3o=ntwhqYOrZZeR7TbBDyQ@mail.gmail.com>
References: <1373306318-15604-1-git-send-email-festevam@gmail.com>
 <1373306318-15604-3-git-send-email-festevam@gmail.com>
 <20130709062414.GG16656@S2101-09.ap.freescale.net>
 <CAOMZO5D4ivbqYovVA2CpXEemrAq8Nyn5By8-iL3SAnw=mpJ+og@mail.gmail.com>
 <20130709182046.GD516@pengutronix.de>
 <CAOMZO5AeJVRL3VhLdYPtAq7-9+Dh3o=ntwhqYOrZZeR7TbBDyQ@mail.gmail.com>
Message-ID: <CAOMZO5DF2bu7CyehQHe671D34DuzuM1uktxbGn+Pw0s5BuQdcA@mail.gmail.com>

On Wed, Jul 10, 2013 at 1:53 PM, Fabio Estevam <festevam at gmail.com> wrote:
> Hi Sascha,
>
> On Tue, Jul 9, 2013 at 3:20 PM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
>
>> l2x0_base is passed to l2x0_init which uses it for the outer cache
>> maintenance operations. I wonder this doesn't crash your kernel.
>
> l2x0_init() is called from arch/arm/mach-imx/mm-imx3.c first and then
> from arch/arm/mm/cache-l2x0.c
> later.
>
> Why do we need to call it twice?

Understood now, actually l2x0_init() is only called in
arch/arm/mm/cache-l2x0.c for the dt case.

So all is fine with the current code.


From gerlando.falauto at keymile.com  Wed Jul 10 13:31:56 2013
From: gerlando.falauto at keymile.com (Gerlando Falauto)
Date: Wed, 10 Jul 2013 19:31:56 +0200
Subject: pci-mvebu driver on km_kirkwood
In-Reply-To: <20130710185706.72b124a4@skate>
References: <51DD88A4.1030506@keymile.com> <20130710185706.72b124a4@skate>
Message-ID: <51DD9A8C.10608@keymile.com>

Hi Thomas,

first of all thanks for your quick feedback.

On 07/10/2013 06:57 PM, Thomas Petazzoni wrote:
> Gerlando,
>
> On Wed, 10 Jul 2013 18:15:32 +0200, Gerlando Falauto wrote:
>
>> I am trying to use the pci-mvebu driver on one of our km_kirkwood
>> boards. The board is based on Marvell's 98dx4122, which should
>> essentially be 6281 compatible.
>
> Was this platform working with the old PCIe driver in mach-kirkwood/ ?

Yes, though we had to trick it a little bit to get both the internal 
switch and this PCIe device working:

- this PCIe device requires to map 256M of memory as opposed to just 128
- we need a virtual PCIe device to connect to the internal switch, which 
must be mapped at 0xf4000000 (normally used for the NAND which must then 
move to 0xff000000)

But apart from the huge BAR (0x07ffffff aka 128M) for the PCIe device 
not being mappable, the rest was normally working just fine even without 
the above changes (i.e. the other BARs were mapped fine).

>
>> The code I took from jcooper's repo:
>>
>>     http://git.infradead.org/users/jcooper/linux.git
>>
>> I took the tag
>>
>>     dt-3.11-6
>>
>> on top of which I merged:
>>
>>     mvebu/pcie
>>     mvebu/pcie_bridge
>>     mvebu/pcie_kirkwood
>
> Could you instead use the latest master from Linus tree? That would
> avoid merge conflicts, and ensure you have all the necessary pieces.

Oops, I had no idea all this had gotten merged already.
Quite honestly, I have no idea how to track this kind of stuff (i.e. did 
a given patch ever got merged and where?) but that's a different topic.

>> Only with the latest merge did I get some conflict on
>> kirkwood.dtsi:
>>
>> <<<<<<< HEAD
>> 		ranges = <0x00000000 0xf1000000 0x0100000		
>> 		          0xf4000000 0xf4000000 0x0000400
>> =======
>> 		ranges = <0x00000000 0xf1000000 0x4000000
>> 		          0xe0000000 0xe0000000 0x8100000
>
> The first cannot work, because it lacks the range for the PCIe. The
> second should work. The correct merge should be:
>
>   		ranges = <0x00000000 0xf1000000 0x0100000		
>   		          0xf4000000 0xf4000000 0x0000400
>   		          0xe0000000 0xe0000000 0x8100000>;
>
> i.e, we've added the PCIe range (last line) and splitted the SRAM into
> its own range (or something like that, don't remember the details, but
> Ezequiel can confirm).

OK that's a good starting point.

>> <<<<<<< HEAD
>> Kirkwood: MV88F6281-A0, TCLK=200000000.
>> Feroceon L2: Cache support initialised, in WT override mode.
>> mvebu-pcie pcie-controller.1: PCIe0.0: link up
>> mvebu-pcie pcie-controller.1: PCI host bridge to bus 0000:00
>> pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
>> pci_bus 0000:00: root bus resource [mem 0xffffffff-0x07fffffe]
>> pci_bus 0000:00: root bus resource [bus 00-ff]
>> pci 0000:00:01.0: [11ab:7846] type 01 class 0x060400
>> PCI: bus0: Fast back to back transfers disabled
>> pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
>> pci 0000:01:00.0: [10ee:0008] type 00 class 0x050000
>> pci 0000:01:00.0: reg 10: [mem 0x00000000-0x00000fff]
>> pci 0000:01:00.0: reg 14: [mem 0x00000000-0x07ffffff]
>> pci 0000:01:00.0: reg 18: [mem 0x00000000-0x00000fff]
>> pci 0000:01:00.0: reg 1c: [mem 0x00000000-0x007fffff]
>> pci 0000:01:00.0: reg 20: [mem 0x00000000-0x00001fff]
>> pci 0000:01:00.0: reg 24: [mem 0x00000000-0x00000fff]
>> pci 0000:01:00.0: supports D1 D2
>> pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot
>> PCI: bus1: Fast back to back transfers disabled
>> pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
>> pci 0000:00:01.0: BAR 8: can't assign mem (size 0xc000000)
>> pci 0000:01:00.0: BAR 1: can't assign mem (size 0x8000000)
>> pci 0000:01:00.0: BAR 3: can't assign mem (size 0x800000)
>> pci 0000:01:00.0: BAR 4: can't assign mem (size 0x2000)
>> pci 0000:01:00.0: BAR 0: can't assign mem (size 0x1000)
>> pci 0000:01:00.0: BAR 2: can't assign mem (size 0x1000)
>> pci 0000:01:00.0: BAR 5: can't assign mem (size 0x1000)
>> pci 0000:00:01.0: PCI bridge to [bus 01]
>
> The first test you did cannot work at all, due to the incorrect ranges.
>
> If you have the PCIe working with the old driver, can you pastebin
> somewhere the complete boot log, as well as the output of "lspci
> -vvv" ?

OK, I will.
In the meantime, what I got to establish is that by manually disabling 
the two biggest resources

 >> pci 0000:00:01.0: BAR 8: can't assign mem (size 0xc000000)
 >> pci 0000:01:00.0: BAR 1: can't assign mem (size 0x8000000)

i.e. something like:

-281,6 +282,10 @@ static void assign_requested_resources_sorted(struct 
list_head *head,
         list_for_each_entry(dev_res, head, list) {
                 res = dev_res->res;
                 idx = res - &dev_res->dev->resource[0];
+
+               if (resource_size(res) < 0x8000000)
+               {
+

at least I can get the following ones to be assigned correctly:

mvebu-pcie pcie-controller.2: PCIe0.0: link up
mvebu-pcie pcie-controller.2: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci 0000:00:01.0: [11ab:7846] type 01 class 0x060400
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0000:01:00.0: [10ee:0008] type 00 class 0x050000
pci 0000:01:00.0: reg 10: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: reg 14: [mem 0x00000000-0x07ffffff]
pci 0000:01:00.0: reg 18: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: reg 1c: [mem 0x00000000-0x007fffff]
pci 0000:01:00.0: reg 20: [mem 0x00000000-0x00001fff]
pci 0000:01:00.0: reg 24: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: supports D1 D2
pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot
PCI: bus1: Fast back to back transfers disabled
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci 0000:01:00.0: BAR 3: assigned [mem 0x04000000-0x047fffff]
pci 0000:01:00.0: BAR 3: set to [mem 0x04000000-0x047fffff] (PCI address 
[0x4000000-0x47fffff])
pci 0000:01:00.0: BAR 4: assigned [mem 0x04800000-0x04801fff]
pci 0000:01:00.0: BAR 4: set to [mem 0x04800000-0x04801fff] (PCI address 
[0x4800000-0x4801fff])
pci 0000:01:00.0: BAR 0: assigned [mem 0x04802000-0x04802fff]
pci 0000:01:00.0: BAR 0: set to [mem 0x04802000-0x04802fff] (PCI address 
[0x4802000-0x4802fff])
pci 0000:01:00.0: BAR 2: assigned [mem 0x04803000-0x04803fff]
pci 0000:01:00.0: BAR 2: set to [mem 0x04803000-0x04803fff] (PCI address 
[0x4803000-0x4803fff])
pci 0000:01:00.0: BAR 5: assigned [mem 0x04804000-0x04804fff]
pci 0000:01:00.0: BAR 5: set to [mem 0x04804000-0x04804fff] (PCI address 
[0x4804000-0x4804fff])
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0x04000000-0x0fffffff]
PCI: enabling device 0000:00:01.0 (0140 -> 0143)


Which is a bit weird because in the past these huge assignments would 
just fail but the following ones would work just fine.

>
>> Compared to a working configuration, here I see a spurious
>>

I assume the

>>     pci 0000:00:01.0: BAR 8: can't assign mem (size 0xc000000)
>>

comes from the switch but I have no idea how to find it out.
I'm quite sure this is the first time I'm seeing BAR 8.

>> which I don't understand, plus all others which are failing.
>>
>> It's weird how with the second configuration:
>>
>>     mvebu-pcie pcie-controller.2: PCIe0.0: link up
>>     mvebu-pcie pcie-controller.2: PCI host bridge to bus 0000:00
>>     pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
>>     pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
>>
>> I get a second mvebu-pcie pcie-controller.2, although with a more
>> reasonable memory range.
>
> A second mvebu-pcie controller? Is your Device Tree correct?

Whoops, my fault. There's just one pcie-controller.2, it's just that 
with the correct ranges the nand.1 node gets created as well, and these 
(platform?) devices are numbered sequentially, regardless of their type.

>
> I'm not really sure to understand what's going on here. Can you post
> the complete boot log, and test with the latest Linus git tree, where
> all the PCIe support got merged?

I sure will.
Thanks for the heads-up.

Thanks a lot!
Gerlando

>
> Thanks!
>
> Thomas
>



From Dave.Martin at arm.com  Wed Jul 10 13:45:26 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Wed, 10 Jul 2013 18:45:26 +0100
Subject: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3() which
 calling instruction smc #1
In-Reply-To: <1373461145-9812-2-git-send-email-pali.rohar@gmail.com>
References: <1362044548-5398-1-git-send-email-pali.rohar@gmail.com>
 <1373461145-9812-1-git-send-email-pali.rohar@gmail.com>
 <1373461145-9812-2-git-send-email-pali.rohar@gmail.com>
Message-ID: <20130710174521.GA2872@localhost.localdomain>

On Wed, Jul 10, 2013 at 02:59:04PM +0200, Pali Roh?r wrote:
> Other secure functions omap_smc1() and omap_smc2() calling instruction smc #0
> but Nokia RX-51 board needs to call smc #1 for PPA access.
> 
> Signed-off-by: Ivaylo Dimitrov <freemangordon at abv.bg>
> Signed-off-by: Pali Roh?r <pali.rohar at gmail.com>
> ---
>  arch/arm/mach-omap2/omap-secure.h |    1 +
>  arch/arm/mach-omap2/omap-smc.S    |   22 +++++++++++++++++++++-
>  2 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
> index 0e72917..c4586f4 100644
> --- a/arch/arm/mach-omap2/omap-secure.h
> +++ b/arch/arm/mach-omap2/omap-secure.h
> @@ -51,6 +51,7 @@
>  extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
>  				u32 arg1, u32 arg2, u32 arg3, u32 arg4);
>  extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
> +extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
>  extern phys_addr_t omap_secure_ram_mempool_base(void);
>  extern int omap_secure_ram_reserve_memblock(void);
>  
> diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
> index f6441c1..5c02b8d 100644
> --- a/arch/arm/mach-omap2/omap-smc.S
> +++ b/arch/arm/mach-omap2/omap-smc.S
> @@ -1,9 +1,11 @@
>  /*
> - * OMAP44xx secure APIs file.
> + * OMAP34xx and OMAP44xx secure APIs file.
>   *
>   * Copyright (C) 2010 Texas Instruments, Inc.
>   * Written by Santosh Shilimkar <santosh.shilimkar at ti.com>
>   *
> + * Copyright (C) 2012 Ivaylo Dimitrov <freemangordon at abv.bg>
> + * Copyright (C) 2013 Pali Roh?r <pali.rohar at gmail.com>
>   *
>   * This program is free software,you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License version 2 as
> @@ -54,6 +56,24 @@ ENTRY(omap_smc2)
>  	ldmfd   sp!, {r4-r12, pc}
>  ENDPROC(omap_smc2)
>  
> +/**
> + * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
> + * Low level common routine for secure HAL and PPA APIs via smc #1
> + * r0 - @service_id: Secure Service ID
> + * r1 - @process_id: Process ID
> + * r2 - @flag: Flag to indicate the criticality of operation
> + * r3 - @pargs: Physical address of parameter list
> + */
> +ENTRY(omap_smc3)
> +	stmfd	sp!, {r4-r12, lr}

You don't need to save/restore r12.  The ABI allows it to be clobbered
across function calls.

> +	mov	r12, r0		@ Copy the secure service ID
> +	mov	r6, #0xff	@ Indicate new Task call
> +	dsb
> +	dmb

dsb synchronises a superset of what dmb synchronises, so the dmb here is
not useful.

In any case, any code calling this must flush the region addressed by
r3 beforehand anyway, which will include a dsb as part of its semantics
-- this is how you call it from rx51_secure_dispatcher().

So I think the dsb may not be needed here (?)

Cheers
---Dave



From Dave.Martin at arm.com  Wed Jul 10 14:09:28 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Wed, 10 Jul 2013 19:09:28 +0100
Subject: Seg fault occurs when running statically compiled binary from
 kernel using call_usermodehelper
In-Reply-To: <20130710163410.GA30514@mudshark.cambridge.arm.com>
References: <CAOiN93mGTu9w9rVNCrbbH1sccXY9VJhaCmg+dS7Rk9mMgKHBaA@mail.gmail.com>
 <CAOiN93=Nx77RkbNuEJMV617MjV5+GmorF0G3vyLy1SwQcuCs+g@mail.gmail.com>
 <CAOiN93nH9fyHoz4yrZmJ-OKCy6ogdt5bYartXCBgP5eHMUBPdw@mail.gmail.com>
 <20130710163410.GA30514@mudshark.cambridge.arm.com>
Message-ID: <20130710180928.GB2872@localhost.localdomain>

On Wed, Jul 10, 2013 at 05:34:11PM +0100, Will Deacon wrote:
> On Wed, Jul 10, 2013 at 11:42:25AM +0100, Ashish Sangwan wrote:
> > Any heads up on this?
> > 
> > or could someone just advice what can we do to debug this?
> > 
> > The ret_from_fork currently looks like following:
> > /*
> >  * This is how we return from a fork.
> >  */
> > ENTRY(ret_from_fork)
> >         bl      schedule_tail
> >         cmp     r5, #0
> >         movne   r0, r4
> >         adrne   lr, BSYM(1f)
> >         movne   pc, r5
> > 1:      get_thread_info tsk
> >         b       ret_slow_syscall
> > ENDPROC(ret_from_fork)
> > 
> > Is this a real issue? Because we are getting this just for static binaries.
> 
> Ok, I've finally got to the bottom of this, but I'm not sure on the best way
> to fix it. The issue is that libc expects r0 to contain a function pointer
> to be invoked at exit (rtld_fini), to clean up after a dynamic linker. If
> this pointer is NULL, then it is ignored. We actually zero this pointer in
> our ELF_PLAT_INIT macro.
> 
> At the same time, we have this strange code called next from the ARM ELF
> loader:
> 
> 	regs->ARM_r2 = stack[2];	/* r2 (envp) */			\
> 	regs->ARM_r1 = stack[1];	/* r1 (argv) */			\
> 	regs->ARM_r0 = stack[0];	/* r0 (argc) */			\
> 
> which puts argc into r0. Usually this gets overwritten by the return value
> of execve (0), so everything hangs together. With kernel threads this is
> different since we do the exec from ____call_usermodehelper on the stack and
> then return to the new application via ret_from_fork, which takes the
> slowpath; popping r0 from pt_regs and making argc visible to the library.
> 
> When the application exits and libc starts running its exit functions, we
> jump to hyperspace.
> 
> My inclination would be to remove the stack popping above (patch below),
> but it's a user-visible change and I'm not sure if something like OABI
> requires it.

It looks like populating r0-r2 is already broken -- libc must be getting
at least argc from the stack and not r0, otherwise it couldn't be
(ab)using r0 for some other purpose before _start.

Do I conclude correctly that the real problem here is a bug in the libc
startup code, which makes incorrect assumptions about the initial r0 in
the statically linked case?

At the ELF entry point, initial r0 is zero, but apparently only by
accident, since there is a clear intent in the kernel for r0=argc, even
if userspace can't have been using this any time recently since it is
normally clobbered with zero.  It seems incorrect for userspace to rely on
either -- but I guess there is no choice but to retain that behaviour now,
since it may break existing binaries which contain that libc bug.

Cheers
---Dave


From markus at trippelsdorf.de  Wed Jul 10 14:28:15 2013
From: markus at trippelsdorf.de (Markus Trippelsdorf)
Date: Wed, 10 Jul 2013 20:28:15 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130710093642.GC14873@pd.tnic>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130506095124.GA22041@pd.tnic>
 <CAMuHMdWH9w5fj6HRXi+9QcBJym4dukAFsPVGZVqSSk3yTZJUcA@mail.gmail.com>
 <20130710093642.GC14873@pd.tnic>
Message-ID: <20130710182815.GA362@x4>

On 2013.07.10 at 11:36 +0200, Borislav Petkov wrote:
> On Wed, Jul 10, 2013 at 10:12:46AM +0200, Geert Uytterhoeven wrote:
> > >> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > >> index a0ab6d7..c9bfbb0 100644
> > >> --- a/scripts/Makefile.lib
> > >> +++ b/scripts/Makefile.lib
> > >> @@ -313,7 +313,7 @@ cmd_lzo = (cat $(filter-out FORCE,$^) | \
> > >>
> > >>  quiet_cmd_lz4 = LZ4     $@
> > >>  cmd_lz4 = (cat $(filter-out FORCE,$^) | \
> > >> -     lz4demo -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
> > >> +     lz4c -l -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
> > >
> > > You probably want to check for the presence of lz4c on the system and
> > > bail with an informative message if absent.
> > 
> > Yep, x86_64-randconfig
> > (http://kisskb.ellerman.id.au/kisskb/buildresult/9110794/):
> > 
> >   LZ4     arch/x86/boot/compressed/vmlinux.bin.lz4
> > /bin/sh: lz4c: command not found
> 
> Sure, it had to be 2 months and to hit upstream for there still to be no
> fix. Geez...

Well, there's also no hand-holding when lzop is missing for LZO.
And the error message is clear enough. No?

BTW speaking of introductory-level patches, what about the following
one:

Now that lz4 kernel compression is available, add *.lz4 to .gitignore

diff --git a/.gitignore b/.gitignore
index 3b8b9b3..7e9932e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -29,6 +29,7 @@ modules.builtin
 *.bz2
 *.lzma
 *.xz
+*.lz4
 *.lzo
 *.patch
 *.gcno


-- 
Markus


From swarren at wwwdotorg.org  Wed Jul 10 14:43:51 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Jul 2013 12:43:51 -0600
Subject: [PATCH V2] ARM: mm: restrict early_alloc to section-aligned memory
Message-ID: <1373481831-31459-1-git-send-email-swarren@wwwdotorg.org>

From: Russell King <rmk at arm.linux.org.uk>

When map_lowmem() runs, and processes a memory bank whose start or end
is not section-aligned, memory must be allocated to store the 2nd-level
page tables. Those allocations are made by calling memblock_alloc().

At this point, the only memory that is free *and* mapped is memory which
has already been mapped by map_lowmem() itself. For this reason, we must
calculate the first point at which map_lowmem() will need to allocate
memory, and set the memblock allocation limit to a lower address, so that
memblock_alloc() is guaranteed to return memory that is already mapped.

This patch enhances sanity_check_meminfo() to calculate that memory
address, and pass it to memblock_set_current_limit(), rather than just
assuming the limit is arm_lowmem_limit.

The algorithm applied is:

* Default memblock_limit to arm_lowmem_limit in the absence of any other
  limit; arm_lowmem_limit is the highest memory that is mapped by
  map_lowmem().

* While walking the list of memblocks, if the start of a block is not
  aligned, 2nd-level page tables will need to be allocated to map the
  first few pages of the block. Hence, the memblock_limit must be before
  the start of the block.

* Similarly, if the end of any block is not aligned, 2nd-level page
  tables will need to be allocated to map the last few pages of the
  block. Hence, the memblock_limit must point at the end of the block,
  rounded down to section-alignment.

* The memory blocks are assumed to be sorted in address order, so the
  first unaligned block start or end is used to set the limit.

With this algorithm, the start or end of almost any bank can be non-
section-aligned. The only exception is that the start of bank 0 must
be section-aligned, since otherwise memory would need to be allocated
when mapping the start of bank 0, which occurs before any free memory
is mapped.

Not-yet-signed-off-by: Russell King <rmk at arm.linux.org.uk>
[swarren, wrote commit description, rewrote calculation of memblock_limit]
Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
V2: completely new implementation based on Russell's suggestion.

Russell, since this is strongly based on your patch, I set you as the
author in git. I assume that's OK. If not, let me know and I'll change
the patch to my authorship and add a note to the commit description
that it's based on your original.

I rewrote the algorithm that calculates memblock_limit to cover the case
of the following memblocks:

0          .. 0x1fc00000 (all section aligned)
0x1fd01000 .. 0x20000000 (start isn't section aligned)

Neither of those matched your start-is-aligned-end-isn't test, so your
patch didn't quite solve my problem, since it didn't set memblock_limit.

 arch/arm/mm/mmu.c | 43 ++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 38 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index d7229d2..08cfa31 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -989,6 +989,7 @@ phys_addr_t arm_lowmem_limit __initdata = 0;
 
 void __init sanity_check_meminfo(void)
 {
+	phys_addr_t memblock_limit = 0;
 	int i, j, highmem = 0;
 	phys_addr_t vmalloc_limit = __pa(vmalloc_min - 1) + 1;
 
@@ -1052,9 +1053,32 @@ void __init sanity_check_meminfo(void)
 			bank->size = size_limit;
 		}
 #endif
-		if (!bank->highmem && bank->start + bank->size > arm_lowmem_limit)
-			arm_lowmem_limit = bank->start + bank->size;
+		if (!bank->highmem) {
+			phys_addr_t bank_end = bank->start + bank->size;
 
+			if (bank_end > arm_lowmem_limit)
+				arm_lowmem_limit = bank_end;
+
+			/*
+			 * Find the first non-section-aligned page, and point
+			 * memblock_limit at it. This relies on rounding the
+			 * limit down to be section-aligned, which happens at
+			 * the end of this function.
+			 *
+			 * With this algorithm, the start or end of almost any
+			 * bank can be non-section-aligned. The only exception
+			 * is that the start of the bank 0 must be section-
+			 * aligned, since otherwise memory would need to be
+			 * allocated when mapping the start of bank 0, which
+			 * occurs before any free memory is mapped.
+			 */
+			if (!memblock_limit) {
+				if (!IS_ALIGNED(bank->start, SECTION_SIZE))
+					memblock_limit = bank->start;
+				else if (!IS_ALIGNED(bank_end, SECTION_SIZE))
+					memblock_limit = bank_end;
+			}
+		}
 		j++;
 	}
 #ifdef CONFIG_HIGHMEM
@@ -1079,7 +1103,18 @@ void __init sanity_check_meminfo(void)
 #endif
 	meminfo.nr_banks = j;
 	high_memory = __va(arm_lowmem_limit - 1) + 1;
-	memblock_set_current_limit(arm_lowmem_limit);
+
+	/*
+	 * Round the memblock limit down to a section size.  This
+	 * helps to ensure that we will allocate memory from the
+	 * last full section, which should be mapped.
+	 */
+	if (memblock_limit)
+		memblock_limit = round_down(memblock_limit, SECTION_SIZE);
+	if (!memblock_limit)
+		memblock_limit = arm_lowmem_limit;
+
+	memblock_set_current_limit(memblock_limit);
 }
 
 static inline void prepare_page_table(void)
@@ -1276,8 +1311,6 @@ void __init paging_init(struct machine_desc *mdesc)
 {
 	void *zero_page;
 
-	memblock_set_current_limit(arm_lowmem_limit);
-
 	build_mem_type_table();
 	prepare_page_table();
 	map_lowmem();
-- 
1.8.1.5



From stern at rowland.harvard.edu  Wed Jul 10 14:45:02 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Wed, 10 Jul 2013 14:45:02 -0400 (EDT)
Subject: [PATCH 5/6] USB: Support wakeup IRQ for suspended controllers
In-Reply-To: <1373473393-27552-1-git-send-email-rogerq@ti.com>
Message-ID: <Pine.LNX.4.44L0.1307101440140.1215-100000@iolanthe.rowland.org>

On Wed, 10 Jul 2013, Roger Quadros wrote:

> Some platforms e.g. ehci-omap can generate an interrupt
> (i.e. remote wakeup) even when the controller is suspended i.e.
> HW_ACCESSIBLE is cleared.
> 
> Introduce a flag "has_wakeup_irq" in struct usb_hcd to indicate
> such cases.
> 
> We tackle this case by disabling the IRQ, scheduling a
> hub resume and enabling back the IRQ after the controller has
> resumed. This ensures that the IRQ handler runs only after the
> controller is accessible.

> @@ -2248,7 +2253,21 @@ irqreturn_t usb_hcd_irq (int irq, void *__hcd)
>  	 */
>  	local_irq_save(flags);
>  
> -	if (unlikely(HCD_DEAD(hcd) || !HCD_HW_ACCESSIBLE(hcd)))
> +	if (unlikely(HCD_DEAD(hcd)))
> +		rc = IRQ_NONE;
> +	else if (unlikely(!HCD_HW_ACCESSIBLE(hcd) && hcd->has_wakeup_irq)) {
> +		/*
> +		 * We got a wakeup interrupt while the controller was
> +		 * suspending or suspended.  We can't handle it now, so
> +		 * disable the IRQ and resume the root hub (and hence
> +		 * the controller too).
> +		 */
> +		disable_irq_nosync(hcd->irq);
> +		set_bit(HCD_FLAG_IRQ_DISABLED, &hcd->flags);
> +		usb_hcd_resume_root_hub(hcd);
> +
> +		rc = IRQ_HANDLED;
> +	} else if (unlikely(!HCD_HW_ACCESSIBLE(hcd)))
>  		rc = IRQ_NONE;

In the interest of minimizing the amount of work needed in the most 
common case, this should be written as:

	else if (unlikely(!HCD_HW_ACCESSIBLE(hcd))) {
		if (hcd->has_wakeup_irq) {
			...
		} else
			rc = IRQ_NONE;

>  	else if (hcd->driver->irq(hcd) == IRQ_NONE)
>  		rc = IRQ_NONE;

Apart from that, the patch is okay.  When you rearrange the logic, you 
can add my Acked-by.

Alan Stern



From linux at arm.linux.org.uk  Wed Jul 10 14:52:00 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 10 Jul 2013 19:52:00 +0100
Subject: Seg fault occurs when running statically compiled binary from
 kernel using call_usermodehelper
In-Reply-To: <20130710163410.GA30514@mudshark.cambridge.arm.com>
References: <CAOiN93mGTu9w9rVNCrbbH1sccXY9VJhaCmg+dS7Rk9mMgKHBaA@mail.gmail.com>
 <CAOiN93=Nx77RkbNuEJMV617MjV5+GmorF0G3vyLy1SwQcuCs+g@mail.gmail.com>
 <CAOiN93nH9fyHoz4yrZmJ-OKCy6ogdt5bYartXCBgP5eHMUBPdw@mail.gmail.com>
 <20130710163410.GA30514@mudshark.cambridge.arm.com>
Message-ID: <20130710185200.GX24642@n2100.arm.linux.org.uk>

On Wed, Jul 10, 2013 at 05:34:11PM +0100, Will Deacon wrote:
> Ok, I've finally got to the bottom of this, but I'm not sure on the best way
> to fix it.

I don't think you have!  You need to look back at the older ARM kernels
to really get to the bottom of this...

> The issue is that libc expects r0 to contain a function pointer
> to be invoked at exit (rtld_fini), to clean up after a dynamic linker. If
> this pointer is NULL, then it is ignored. We actually zero this pointer in
> our ELF_PLAT_INIT macro.
> 
> At the same time, we have this strange code called next from the ARM ELF
> loader:
> 
> 	regs->ARM_r2 = stack[2];	/* r2 (envp) */			\
> 	regs->ARM_r1 = stack[1];	/* r1 (argv) */			\
> 	regs->ARM_r0 = stack[0];	/* r0 (argc) */			\
> 
> which puts argc into r0.

You're sort of right.  It dates from the days when we had a.out binaries,
those required argc, argv and envp in r0/r1/r2 - and ARM kernels carried
this hack in  binfmt_aout.c to make it work in conjunction with the above:

static int load_aout_binary(struct linux_binprm * bprm)
{
...
        start_thread(regs, ex.a_entry, current->mm->start_stack);
#ifndef __arm__
        return 0;
#else
        return regs->ARM_r0;
#endif
}

ELF, on the other hand, never had that hack - ELF has always been zero
in r0, and it's always retrieved the argc/argv/envp off the stack.

As the above hack got dropped from the kernel (I don't think it ever made
it into mainline), I think we should be safe getting rid of this
initialization of regs->ARM_r0 to r2, leaving them all as zeros.

We should probably also remove the selection of HAVE_AOUT from
arch/arm/Kconfig too as this definitely won't work with any recent
kernel (certainly not without binfmt_aout.c hacked in the above way.)


From stern at rowland.harvard.edu  Wed Jul 10 15:04:08 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Wed, 10 Jul 2013 15:04:08 -0400 (EDT)
Subject: [PATCH 6/6] USB: ehci-omap: Implement suspend/resume
In-Reply-To: <1373473405-27589-1-git-send-email-rogerq@ti.com>
Message-ID: <Pine.LNX.4.44L0.1307101446270.1215-100000@iolanthe.rowland.org>

On Wed, 10 Jul 2013, Roger Quadros wrote:

> Call ehci_suspend/resume() during runtime suspend/resume
> as well as system suspend/resume.
> 
> Use a flag "bound" to indicate that the HCD structures are valid.
> This is only true between usb_add_hcd() and usb_remove_hcd() calls.
> 
> The flag can be used by omap_ehci_runtime_suspend/resume() handlers
> to avoid calling ehci_suspend/resume() when we are no longer bound
> to the HCD e.g. during probe() and remove();

> @@ -293,15 +301,67 @@ static const struct of_device_id omap_ehci_dt_ids[] = {
>  
>  MODULE_DEVICE_TABLE(of, omap_ehci_dt_ids);
>  
> +static int omap_ehci_suspend(struct device *dev)
> +{
> +	struct usb_hcd *hcd = dev_get_drvdata(dev);
> +
> +	dev_dbg(dev, "%s\n", __func__);
> +
> +	return ehci_suspend(hcd, true);
> +}
> +
> +static int omap_ehci_resume(struct device *dev)
> +{
> +	struct usb_hcd *hcd = dev_get_drvdata(dev);
> +
> +	dev_dbg(dev, "%s\n", __func__);
> +
> +	return ehci_resume(hcd, false);
> +}

There are three problems here.  The first is very simple: the wakeup 
settings are messed up.  Wakeup is supposed to be enabled always for
runtime suspend, whereas it is controlled by device_may_wakeup() for
system suspend.  You reversed them.

The other two problems are both related to the interaction between
system PM and runtime PM.  Suppose the controller is already runtime
suspended when the system goes to sleep.  Because it is runtime
suspended, it is enabled for wakeup.  But device_may_wakeup() could
return false; if this happens then you have to do a runtime-resume in
omap_ehci_suspend() before calling ehci_suspend(), so that the
controller can be suspended again with wakeups disabled.  (Or you could
choose an alternative method for accomplishing the same result, such as
disabling the wakeup signal from the pad without going through a whole
EHCI resume/suspend cycle.)  Conversely, if device_may_wakeup() returns
true then you shouldn't do anything at all, because the controller is
already suspended with the correct wakeup setting.

For the third problem, suppose the controller was runtime suspended
when the system went to sleep.  When the system wakes up, the
controller will become active, so you have to inform the runtime PM
core about its change of state.  Basically, if omap_ehci_resume() sees
that ehci_resume() returned 0 then it must do:

	pm_runtime_disable(dev);
	pm_runtime_set_active(dev);
	pm_runtime_enable(dev);

All of these issues are discussed (among lots of other material) in 
Documentation/power/runtime_pm.txt.

Alan Stern



From stern at rowland.harvard.edu  Wed Jul 10 15:08:43 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Wed, 10 Jul 2013 15:08:43 -0400 (EDT)
Subject: [PATCH 5/6] USB: Support wakeup IRQ for suspended controllers
In-Reply-To: <1373473393-27552-1-git-send-email-rogerq@ti.com>
Message-ID: <Pine.LNX.4.44L0.1307101504220.1215-100000@iolanthe.rowland.org>

On Wed, 10 Jul 2013, Roger Quadros wrote:

> Some platforms e.g. ehci-omap can generate an interrupt
> (i.e. remote wakeup) even when the controller is suspended i.e.
> HW_ACCESSIBLE is cleared.
> 
> Introduce a flag "has_wakeup_irq" in struct usb_hcd to indicate
> such cases.
> 
> We tackle this case by disabling the IRQ, scheduling a
> hub resume and enabling back the IRQ after the controller has
> resumed. This ensures that the IRQ handler runs only after the
> controller is accessible.

Oh yes, one more thing...

> @@ -132,6 +134,7 @@ struct usb_hcd {
>  	unsigned		wireless:1;	/* Wireless USB HCD */
>  	unsigned		authorized_default:1;
>  	unsigned		has_tt:1;	/* Integrated TT in root hub */
> +	unsigned		has_wakeup_irq:1; /* Can IRQ when suspended */

Please add a highly visible comment here, warning that has_wakeup_irq
should never be set on systems with shared IRQs.  Having both would ...
well, it would indicate a really bad system design.

Alan Stern



From swarren at wwwdotorg.org  Wed Jul 10 15:09:13 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 10 Jul 2013 13:09:13 -0600
Subject: [PATCH] kexec: return error of machine_kexec() fails
In-Reply-To: <87obaaiiry.fsf@xmission.com>
References: <1373421296-6112-1-git-send-email-horms@verge.net.au>
 <87obaaiiry.fsf@xmission.com>
Message-ID: <51DDB159.2080003@wwwdotorg.org>

On 07/10/2013 08:36 AM, Eric W. Biederman wrote:
> Simon Horman <horms at verge.net.au> writes:
> 
>> From: Stephen Warren <swarren at nvidia.com>
>>
>> Prior to commit 3ab8352 "kexec jump", if machine_kexec() returned,
>> sys_reboot() would return -EINVAL. This patch restores this behaviour
>> for the non-KEXEC_JUMP case, where machine_kexec() is not expected to
>> return.
>>
>> This situation can occur on ARM, where kexec requires disabling all but
>> one CPU using CPU hotplug. However, if hotplug isn't supported by the
>> particular HW the kernel is running on, then kexec cannot succeed.
> 
> Ugh. This reasoning is nonsense.  Prior to the kexec jump work
> machine_kexec could never return and so could never return -EINVAL.

Well, any function /can/ return. Perhaps there was some undocumented
requirement that machine_kexec() was not allowed to return? I did test
it, and everything appears to work fine if it does return, aside from
the error code.

> It is not ok to have an image loaded that we can not kexec.  kexec_load
> should fail not machine_shutdown or machine_kexec.

Hmm. I suppose one option is to enhance ARM's machine_kexec_prepare(),
which is called from kexec_load(), and have that fail unless either the
current HW is non-SMP, or full CPU HW/driver hotplug/PM support is
available, so that it's guaranteed that machine_shutdown() will be able
to fully disable all but one CPU.

Would that be acceptable?

Other alternatives would be:

a) Force the user to disable (hot unplug) the CPUs themselves before
calling kexec_load(). This seems rather onerous, and could be defeated
by replugging them between kexec_load() and kernel_kexec().

b) Actually modifying kexec_load() to disable the CPUs, at the point
where it's legal for it to fail. However, I suspect some use-cases call
kexec_load() a long time before kernel_kexec(), so this would end up
disabling SMP way too early.

> ARM needs to get it's act together and stop modifying the generic code
> to deal with it's broken multi-cpu architecture.

A standardized in-CPU mechanism for disabling CPUs as part of the ARM
architecture would be nice. However, even if that appears today, it's
not going to help all the already extant systems that don't have it.


From ezequiel.garcia at free-electrons.com  Wed Jul 10 15:11:49 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Wed, 10 Jul 2013 16:11:49 -0300
Subject: [RFC/PATCH 2/2] ARM: kirkwood: Add basic suspend-to-RAM support
In-Reply-To: <20130710171348.GA3981@localhost>
References: <1372718849-2912-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1372718849-2912-3-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130710130702.GD28813@lunn.ch> <20130710171348.GA3981@localhost>
Message-ID: <20130710191147.GB3981@localhost>

(Yet another resend, this time to public ML as well)

On Wed, Jul 10, 2013 at 02:13:48PM -0300, Ezequiel Garcia wrote:
> (Resending it with some more Ccs)
> 
> On Wed, Jul 10, 2013 at 03:07:02PM +0200, Andrew Lunn wrote:
> > On Mon, Jul 01, 2013 at 07:47:29PM -0300, Ezequiel Garcia wrote:
> > > Implements suspend-to-RAM support in a standby-like fashion:
> > > when the SoC enters suspend state the peripheral clocks are gated
> > > and the memory PM units are disabled.
> > > 
> > > However the network controller clock is not gated for now, since there is
> > > still some work to be done in the driver to provide proper suspend/resume
> > > operations.
> > > 
> > > Signed-off-by: Simon Guinot <sguinot at lacie.com>
> > > Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> > > ---
> > >  arch/arm/mach-kirkwood/Makefile                   |  1 +
> > >  arch/arm/mach-kirkwood/include/mach/bridge-regs.h |  2 +
> > >  arch/arm/mach-kirkwood/pm.c                       | 83 +++++++++++++++++++++++
> > >  3 files changed, 86 insertions(+)
> > >  create mode 100644 arch/arm/mach-kirkwood/pm.c
> > > 
> > > diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
> > > index e1f3735..2c56aa0 100644
> > > --- a/arch/arm/mach-kirkwood/Makefile
> > > +++ b/arch/arm/mach-kirkwood/Makefile
> > > @@ -1,4 +1,5 @@
> > >  obj-y				+= common.o irq.o pcie.o mpp.o
> > > +obj-$(CONFIG_PM)		+= pm.o
> > >  
> > >  obj-$(CONFIG_MACH_D2NET_V2)		+= d2net_v2-setup.o lacie_v2-common.o
> > >  obj-$(CONFIG_MACH_DB88F6281_BP)		+= db88f6281-bp-setup.o
> > > diff --git a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
> > > index 5c82b7d..fad3a35 100644
> > > --- a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
> > > +++ b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
> > > @@ -78,4 +78,6 @@
> > >  #define CGC_TDM			(1 << 20)
> > >  #define CGC_RESERVED		(0x6 << 21)
> > >  
> > > +#define MEMORY_PM_CTRL		(BRIDGE_VIRT_BASE + 0x118)
> > > +
> > >  #endif
> > > diff --git a/arch/arm/mach-kirkwood/pm.c b/arch/arm/mach-kirkwood/pm.c
> > > new file mode 100644
> > > index 0000000..5624b66
> > > --- /dev/null
> > > +++ b/arch/arm/mach-kirkwood/pm.c
> > > @@ -0,0 +1,83 @@
> > > +/*
> > > + * Power Management driver for Marvell Kirkwood SoCs
> > > + *
> > > + * Copyright (C) 2013 Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> > > + * Copyright (C) 2010 Simon Guinot <sguinot at lacie.com>
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License,
> > > + * version 2 of the License.
> > > + *
> > > + * 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.
> > > + */
> > > +
> > > +#include <linux/kernel.h>
> > > +#include <linux/suspend.h>
> > > +#include <linux/io.h>
> > > +#include <mach/bridge-regs.h>
> > > +
> > > +
> > > +static void __iomem *ddr_operation_base;
> > > +
> > > +static void kirkwood_suspend_mem(void)
> > > +{
> > > +	u32 clk_ctrl, mem_pm_ctrl;
> > > +
> > > +	clk_ctrl = readl(CLOCK_GATING_CTRL);
> > > +	mem_pm_ctrl = readl(MEMORY_PM_CTRL);
> > > +
> > > +	/*
> > > +	 * Gate clocks, except for so-called 'Runit' unit, which apparently
> > > +	 * corresponds to NAND, SPI and BootROM.
> > > +	 *
> > > +	 * Also, we skip the gating of the GE0 and GE1 clocks for now.
> > > +	 *
> > > +	 * Contrary to my expectation, the SDRAM clock can also be disabled and
> > > +	 * the suspend-resume cycle will complete successfully.
> > > +	 */
> > > +	writel(CGC_GE1 | CGC_GE0 | CGC_RUNIT, CLOCK_GATING_CTRL);
> > > +
> > > +	/* Set peripherals to low-power mode */
> > > +	writel(~0, MEMORY_PM_CTRL);
> > > +
> > > +	/*
> > > +	 * Set DDR in self-refresh.
> > > +	 */
> > > +	writel(0x7, ddr_operation_base);
> > > +
> > > +	/*
> > > +	 * Set CPU in wait-for-interrupt state.
> > > +	 */
> > > +	cpu_do_idle();
> > > +
> > > +	writel(mem_pm_ctrl, MEMORY_PM_CTRL);
> > > +	writel(clk_ctrl, CLOCK_GATING_CTRL);
> > > +}
> > > +
> > > +static int kirkwood_suspend_enter(suspend_state_t state)
> > > +{
> > > +	switch (state) {
> > > +	case PM_SUSPEND_MEM:
> > > +		kirkwood_suspend_mem();
> > > +		break;
> > > +	default:
> > > +		return -EINVAL;
> > > +	}
> > > +	return 0;
> > > +}
> > > +
> > > +static const struct platform_suspend_ops kirkwood_suspend_ops = {
> > > +	.enter = kirkwood_suspend_enter,
> > > +	.valid = suspend_valid_only_mem,
> > > +};
> > > +
> > > +static int __init kirkwood_pm_init(void)
> > > +{
> > > +	ddr_operation_base = ioremap(DDR_OPERATION_BASE, 4);
> > 
> > Sorry for not replying earlier.
> > 
> 
> No problem. I've been testing this a lot lately, so I'll send a v2
> -more or less- soon.
> 
> FWIW, the v2 will remove *completely* the clock gating from this file,
> since I consider that to be each driver's business and don't think
> it's a good idea to mess with that.
> 
> Before I send the v2 I'd like to perform some (basic) power measurements
> to test the effect of this.
> 
> > Have you tried this in combination with the kirkwood cpuidle code?
> > That also ioremap()s the DDR_OPERATION_BASE. Are two drivers allowed
> > to do this?
> > 
> 
> Hum... yes, I'm pretty sure I've been testing them together.
> 
> AFAIK, nothing prevents you from ioremapping twice the same area,
> it's request_mem_region() what handle such situations, not ioremap.
> 
> However, now that you bring this to my mind: we should re-visit this
> approach as it's a bit racy. Maybe the cpuidle can export a function
> to set the self-refresh mode?
> 
> > And a dumb question. What actually brings it out of suspend mode?
> > Interrupts on GPIO lines?
> > 
> 
> I'm not entirely sure, but I guess the CPU will get out of the
> Wait-for-interrupt state by any enabled interruption source.
> Currently, I'm waking it with a console key stroke or a GPIO button,
> but there may be other means of resuming.
> 
> Thanks a lot for looking at this!

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From gerlando.falauto at keymile.com  Wed Jul 10 15:56:01 2013
From: gerlando.falauto at keymile.com (Gerlando Falauto)
Date: Wed, 10 Jul 2013 21:56:01 +0200
Subject: pci-mvebu driver on km_kirkwood
In-Reply-To: <51DD9A8C.10608@keymile.com>
References: <51DD88A4.1030506@keymile.com> <20130710185706.72b124a4@skate>
 <51DD9A8C.10608@keymile.com>
Message-ID: <51DDBC51.4050009@keymile.com>

Hi Thomas,

I guess I understand now....

 >>> pci 0000:00:01.0: BAR 8: can't assign mem (size 0xc000000)

this is the BAR for the bridge, your virtual PCI host device, whose size 
is calculated dynamically depending on what is found on the underlying 
hardware.
So compared to the legacy driver which was relying on the real hardware 
BARs (where I could get /some/ BARs to work, namely the biggest one 
which was taking up the whole 128M), here it's an all-or-nothing approach.
As a matter of fact, everything works fine if I explicitly disable the 
biggest BAR with a trick:

mvebu-pcie pcie-controller.1: PCIe0.0: link up
mvebu-pcie pcie-controller.1: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci 0000:00:01.0: [11ab:7846] type 01 class 0x060400
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0000:01:00.0: [10ee:0008] type 00 class 0x050000
pci 0000:01:00.0: reg 10: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: reg 14: [mem 0x00000000-0x07ffffff]
pci 0000:01:00.0: reg 18: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: reg 1c: [mem 0x00000000-0x007fffff]
pci 0000:01:00.0: reg 20: [mem 0x00000000-0x00001fff]
pci 0000:01:00.0: reg 24: [mem 0x00000000-0x00000fff]
pci 0000:01:00.0: supports D1 D2
pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot
PCI: bus1: Fast back to back transfers disabled
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci 0000:01:00.0: disabling BAR 1: [mem 0x00000000-0x07ffffff] TOO BIG 
(alignment 0x1000)
pci 0000:00:01.0: BAR 8: assigned [mem 0xe0000000-0xe0bfffff]
pci 0000:01:00.0: BAR 3: assigned [mem 0xe0000000-0xe07fffff]
pci 0000:01:00.0: BAR 4: assigned [mem 0xe0800000-0xe0801fff]
pci 0000:01:00.0: BAR 0: assigned [mem 0xe0802000-0xe0802fff]
pci 0000:01:00.0: BAR 2: assigned [mem 0xe0803000-0xe0803fff]
pci 0000:01:00.0: BAR 5: assigned [mem 0xe0804000-0xe0804fff]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0xe0000000-0xe0bfffff]

So this seems to be the final solution (without the hack above):

--- a/arch/arm/boot/dts/kirkwood-98dx4122.dtsi
+++ b/arch/arm/boot/dts/kirkwood-98dx4122.dtsi
                         bus-range = <0x00 0xff>;

                         ranges = <0x82000000 0 0x00040000 0x00040000 0 
0x00002000   /* Port 0.0 registers */
-                                 0x82000000 0 0xe0000000 0xe0000000 0 
0x08000000   /* non-prefetchable memory */
+                                 0x82000000 0 0xe0000000 0xe0000000 0 
0x0c000000   /* non-prefetchable memory */
                                   0x81000000 0 0          0xe8000000 0 
0x00100000>; /* downstream I/O */

                         pcie at 1,0 {

Does the above make sense? Am I setting up overlapping ranges this way?
Could I make it 0x10000000 so to have 256M?

Thanks a lot!
Gerlando

On 07/10/2013 07:31 PM, Gerlando Falauto wrote:
> Hi Thomas,
>
> first of all thanks for your quick feedback.
>
> On 07/10/2013 06:57 PM, Thomas Petazzoni wrote:
>> Gerlando,
>>
>> On Wed, 10 Jul 2013 18:15:32 +0200, Gerlando Falauto wrote:
>>
>>> I am trying to use the pci-mvebu driver on one of our km_kirkwood
>>> boards. The board is based on Marvell's 98dx4122, which should
>>> essentially be 6281 compatible.
>>
>> Was this platform working with the old PCIe driver in mach-kirkwood/ ?
>
> Yes, though we had to trick it a little bit to get both the internal
> switch and this PCIe device working:
>
> - this PCIe device requires to map 256M of memory as opposed to just 128
> - we need a virtual PCIe device to connect to the internal switch, which
> must be mapped at 0xf4000000 (normally used for the NAND which must then
> move to 0xff000000)
>
> But apart from the huge BAR (0x07ffffff aka 128M) for the PCIe device
> not being mappable, the rest was normally working just fine even without
> the above changes (i.e. the other BARs were mapped fine).
>
>>
>>> The code I took from jcooper's repo:
>>>
>>>     http://git.infradead.org/users/jcooper/linux.git
>>>
>>> I took the tag
>>>
>>>     dt-3.11-6
>>>
>>> on top of which I merged:
>>>
>>>     mvebu/pcie
>>>     mvebu/pcie_bridge
>>>     mvebu/pcie_kirkwood
>>
>> Could you instead use the latest master from Linus tree? That would
>> avoid merge conflicts, and ensure you have all the necessary pieces.
>
> Oops, I had no idea all this had gotten merged already.
> Quite honestly, I have no idea how to track this kind of stuff (i.e. did
> a given patch ever got merged and where?) but that's a different topic.
>
>>> Only with the latest merge did I get some conflict on
>>> kirkwood.dtsi:
>>>
>>> <<<<<<< HEAD
>>>         ranges = <0x00000000 0xf1000000 0x0100000
>>>                   0xf4000000 0xf4000000 0x0000400
>>> =======
>>>         ranges = <0x00000000 0xf1000000 0x4000000
>>>                   0xe0000000 0xe0000000 0x8100000
>>
>> The first cannot work, because it lacks the range for the PCIe. The
>> second should work. The correct merge should be:
>>
>>           ranges = <0x00000000 0xf1000000 0x0100000
>>                     0xf4000000 0xf4000000 0x0000400
>>                     0xe0000000 0xe0000000 0x8100000>;
>>
>> i.e, we've added the PCIe range (last line) and splitted the SRAM into
>> its own range (or something like that, don't remember the details, but
>> Ezequiel can confirm).
>
> OK that's a good starting point.
>
>>> <<<<<<< HEAD
>>> Kirkwood: MV88F6281-A0, TCLK=200000000.
>>> Feroceon L2: Cache support initialised, in WT override mode.
>>> mvebu-pcie pcie-controller.1: PCIe0.0: link up
>>> mvebu-pcie pcie-controller.1: PCI host bridge to bus 0000:00
>>> pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
>>> pci_bus 0000:00: root bus resource [mem 0xffffffff-0x07fffffe]
>>> pci_bus 0000:00: root bus resource [bus 00-ff]
>>> pci 0000:00:01.0: [11ab:7846] type 01 class 0x060400
>>> PCI: bus0: Fast back to back transfers disabled
>>> pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]),
>>> reconfiguring
>>> pci 0000:01:00.0: [10ee:0008] type 00 class 0x050000
>>> pci 0000:01:00.0: reg 10: [mem 0x00000000-0x00000fff]
>>> pci 0000:01:00.0: reg 14: [mem 0x00000000-0x07ffffff]
>>> pci 0000:01:00.0: reg 18: [mem 0x00000000-0x00000fff]
>>> pci 0000:01:00.0: reg 1c: [mem 0x00000000-0x007fffff]
>>> pci 0000:01:00.0: reg 20: [mem 0x00000000-0x00001fff]
>>> pci 0000:01:00.0: reg 24: [mem 0x00000000-0x00000fff]
>>> pci 0000:01:00.0: supports D1 D2
>>> pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot
>>> PCI: bus1: Fast back to back transfers disabled
>>> pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
>>> pci 0000:00:01.0: BAR 8: can't assign mem (size 0xc000000)
>>> pci 0000:01:00.0: BAR 1: can't assign mem (size 0x8000000)
>>> pci 0000:01:00.0: BAR 3: can't assign mem (size 0x800000)
>>> pci 0000:01:00.0: BAR 4: can't assign mem (size 0x2000)
>>> pci 0000:01:00.0: BAR 0: can't assign mem (size 0x1000)
>>> pci 0000:01:00.0: BAR 2: can't assign mem (size 0x1000)
>>> pci 0000:01:00.0: BAR 5: can't assign mem (size 0x1000)
>>> pci 0000:00:01.0: PCI bridge to [bus 01]
>>
>> The first test you did cannot work at all, due to the incorrect ranges.
>>
>> If you have the PCIe working with the old driver, can you pastebin
>> somewhere the complete boot log, as well as the output of "lspci
>> -vvv" ?
>
> OK, I will.
> In the meantime, what I got to establish is that by manually disabling
> the two biggest resources
>
>  >> pci 0000:00:01.0: BAR 8: can't assign mem (size 0xc000000)
>  >> pci 0000:01:00.0: BAR 1: can't assign mem (size 0x8000000)
>
> i.e. something like:
>
> -281,6 +282,10 @@ static void assign_requested_resources_sorted(struct
> list_head *head,
>          list_for_each_entry(dev_res, head, list) {
>                  res = dev_res->res;
>                  idx = res - &dev_res->dev->resource[0];
> +
> +               if (resource_size(res) < 0x8000000)
> +               {
> +
>
> at least I can get the following ones to be assigned correctly:
>
> mvebu-pcie pcie-controller.2: PCIe0.0: link up
> mvebu-pcie pcie-controller.2: PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
> pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
> pci_bus 0000:00: root bus resource [bus 00-ff]
> pci 0000:00:01.0: [11ab:7846] type 01 class 0x060400
> PCI: bus0: Fast back to back transfers disabled
> pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> pci 0000:01:00.0: [10ee:0008] type 00 class 0x050000
> pci 0000:01:00.0: reg 10: [mem 0x00000000-0x00000fff]
> pci 0000:01:00.0: reg 14: [mem 0x00000000-0x07ffffff]
> pci 0000:01:00.0: reg 18: [mem 0x00000000-0x00000fff]
> pci 0000:01:00.0: reg 1c: [mem 0x00000000-0x007fffff]
> pci 0000:01:00.0: reg 20: [mem 0x00000000-0x00001fff]
> pci 0000:01:00.0: reg 24: [mem 0x00000000-0x00000fff]
> pci 0000:01:00.0: supports D1 D2
> pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot
> PCI: bus1: Fast back to back transfers disabled
> pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
> pci 0000:01:00.0: BAR 3: assigned [mem 0x04000000-0x047fffff]
> pci 0000:01:00.0: BAR 3: set to [mem 0x04000000-0x047fffff] (PCI address
> [0x4000000-0x47fffff])
> pci 0000:01:00.0: BAR 4: assigned [mem 0x04800000-0x04801fff]
> pci 0000:01:00.0: BAR 4: set to [mem 0x04800000-0x04801fff] (PCI address
> [0x4800000-0x4801fff])
> pci 0000:01:00.0: BAR 0: assigned [mem 0x04802000-0x04802fff]
> pci 0000:01:00.0: BAR 0: set to [mem 0x04802000-0x04802fff] (PCI address
> [0x4802000-0x4802fff])
> pci 0000:01:00.0: BAR 2: assigned [mem 0x04803000-0x04803fff]
> pci 0000:01:00.0: BAR 2: set to [mem 0x04803000-0x04803fff] (PCI address
> [0x4803000-0x4803fff])
> pci 0000:01:00.0: BAR 5: assigned [mem 0x04804000-0x04804fff]
> pci 0000:01:00.0: BAR 5: set to [mem 0x04804000-0x04804fff] (PCI address
> [0x4804000-0x4804fff])
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x04000000-0x0fffffff]
> PCI: enabling device 0000:00:01.0 (0140 -> 0143)
>
>
> Which is a bit weird because in the past these huge assignments would
> just fail but the following ones would work just fine.
>
>>
>>> Compared to a working configuration, here I see a spurious
>>>
>
> I assume the
>
>>>     pci 0000:00:01.0: BAR 8: can't assign mem (size 0xc000000)
>>>
>
> comes from the switch but I have no idea how to find it out.
> I'm quite sure this is the first time I'm seeing BAR 8.
>
>>> which I don't understand, plus all others which are failing.
>>>
>>> It's weird how with the second configuration:
>>>
>>>     mvebu-pcie pcie-controller.2: PCIe0.0: link up
>>>     mvebu-pcie pcie-controller.2: PCI host bridge to bus 0000:00
>>>     pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
>>>     pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
>>>
>>> I get a second mvebu-pcie pcie-controller.2, although with a more
>>> reasonable memory range.
>>
>> A second mvebu-pcie controller? Is your Device Tree correct?
>
> Whoops, my fault. There's just one pcie-controller.2, it's just that
> with the correct ranges the nand.1 node gets created as well, and these
> (platform?) devices are numbered sequentially, regardless of their type.
>
>>
>> I'm not really sure to understand what's going on here. Can you post
>> the complete boot log, and test with the latest Linus git tree, where
>> all the PCIe support got merged?
>
> I sure will.
> Thanks for the heads-up.
>
> Thanks a lot!
> Gerlando
>
>>
>> Thanks!
>>
>> Thomas
>>
>



From marex at denx.de  Wed Jul 10 15:57:16 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 10 Jul 2013 21:57:16 +0200
Subject: [PATCH 04/12] drivers/mmc/host: don't use
 devm_pinctrl_get_select_default() in probe
In-Reply-To: <1373471889-18107-4-git-send-email-wsa@the-dreams.de>
References: <1373471889-18107-1-git-send-email-wsa@the-dreams.de>
 <1373471889-18107-4-git-send-email-wsa@the-dreams.de>
Message-ID: <201307102157.16419.marex@denx.de>

Dear Wolfram Sang,

> Since commit ab78029 (drivers/pinctrl: grab default handles from device
> core), we can rely on device core for setting the default pins. Compile
> tested only.
> 
> Acked-by: Linus Walleij <linus.walleij at linaro.org> (personally at LCE13)
> Signed-off-by: Wolfram Sang <wsa at the-dreams.de>

Something like that is already in -next:

    mmc: mxs-mmc: Let device core handle pinctrl

Otherwise

Tested-by: Marek Vasut <marex at denx.de>

Best regards,
Marek Vasut


From bp at alien8.de  Wed Jul 10 16:01:39 2013
From: bp at alien8.de (Borislav Petkov)
Date: Wed, 10 Jul 2013 22:01:39 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130710182815.GA362@x4>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130506095124.GA22041@pd.tnic>
 <CAMuHMdWH9w5fj6HRXi+9QcBJym4dukAFsPVGZVqSSk3yTZJUcA@mail.gmail.com>
 <20130710093642.GC14873@pd.tnic> <20130710182815.GA362@x4>
Message-ID: <20130710200139.GC9140@pd.tnic>

On Wed, Jul 10, 2013 at 08:28:15PM +0200, Markus Trippelsdorf wrote:
> Well, there's also no hand-holding when lzop is missing for LZO. And
> the error message is clear enough. No?

Actually, we should error out more gracefully than that. Maybe check for
the presence of the executable first and if not, exit out of the build
with an informational message that lz4c is not present on the system.
Ditto for lzop.

Currently, you wait for the whole build to complete just to see that
there's no executable at the end. Not nice.

> BTW speaking of introductory-level patches, what about the following
> one:
> 
> Now that lz4 kernel compression is available, add *.lz4 to .gitignore

Yep. That makes sense.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--


From linus.walleij at linaro.org  Wed Jul 10 16:36:28 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Jul 2013 22:36:28 +0200
Subject: [RFC] ARM: OMAP2+: omap_device: add pinctrl handling
In-Reply-To: <51CC45D3.2000305@ti.com>
References: <1371826990-25820-1-git-send-email-grygorii.strashko@ti.com>
 <CACRpkdY=m1b9Lh27+wHP8FQ4SbVZKmAOCGhxe59aP+TcuR9QaA@mail.gmail.com>
 <20130625065811.GZ5523@atomide.com> <51CAEA90.90200@ti.com>
 <CACRpkdbKgEcfF67oO9HrczvDp4Po3Xt1hFajJ1vO8kEvsZH4jA@mail.gmail.com>
 <51CC45D3.2000305@ti.com>
Message-ID: <CACRpkdYU13bhPaL2ZG9CT9JRv9sKQ+1N3zCUPizk571+LQqB4A@mail.gmail.com>

On Thu, Jun 27, 2013 at 4:01 PM, Grygorii Strashko
<grygorii.strashko at ti.com> wrote:

> I think, In the future the OMAP pinctrl configurations would be manged in
> more flexible way then now (thanks to "pinctrl PM helpers" and you;))
> - "Idle" state will be splitted to "Idle"/"sleep"
> - "default" state will be splitted to "default"/"active"

OK so the first ones we already have so the discussion is now down
to adding the "active" state (and pinctrl_pm* helper function).

I guess we need a patch set prepared which adds the "active" state
and helper function as the first patch, i.e. this:
http://marc.info/?l=linux-kernel&m=137094012703340&w=2
Can I have your ACK on this patch?

I do not want to add the state unless there is a clear consumer,
so it needs to go in with the first patch to a device driver that uses
pinctrl_pm_select_active_state() which will be a good demonstration
on its use and utility. (And a point to object and suggest other ways
to do the same thing...)

Yours,
Linus Walleij


From linus.walleij at linaro.org  Wed Jul 10 16:42:05 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Jul 2013 22:42:05 +0200
Subject: [RFC] ARM: OMAP2+: omap_device: add pinctrl handling
In-Reply-To: <20130627144535.GK5523@atomide.com>
References: <1371826990-25820-1-git-send-email-grygorii.strashko@ti.com>
 <CACRpkdY=m1b9Lh27+wHP8FQ4SbVZKmAOCGhxe59aP+TcuR9QaA@mail.gmail.com>
 <20130625065811.GZ5523@atomide.com> <51CAEA90.90200@ti.com>
 <CACRpkdbKgEcfF67oO9HrczvDp4Po3Xt1hFajJ1vO8kEvsZH4jA@mail.gmail.com>
 <51CC45D3.2000305@ti.com> <20130627144535.GK5523@atomide.com>
Message-ID: <CACRpkdYdJ0u+J1dbrWpGMyX6K9hi49uzFn4K78m3Xu7uNTAQpw@mail.gmail.com>

On Thu, Jun 27, 2013 at 4:45 PM, Tony Lindgren <tony at atomide.com> wrote:

> The off mode bits can be enabled continuously, the mux hardware
> automatically sets them. So sounds like you don't need any
> separate "idle" "sleep" and "off" states, the following should
> do:
>
> "default" (or "static") static pins that don't need to be touched
>                         after consumer driver probe

Please use "default" for this. We cannot shoehorn OMAP lingo
into the core kernel and expect everyone to accept that...

> "active"                dynamic pins that are not a subset of
>                         "default" needed for runtime; these pins
>                         are the same as "idle" below, but with
>                         different muxing or pinconf device
>                         runtime
>
> "idle"                  dynamic pins that are not a subset of
>                         "default" needed for various idle modes;
>                         these pins are the same as "active" above,
>                         but with different muxing or pinconf for
>                         various idle states

The misunderstanding earlier was that it was assumed that
"active" == "default", just with another name.

If the above is true with an actual driver patch calling
*both* pinctrl_pm_select_default_state() *and*
pinctrl_pm_select_active_state() in different runpaths I
see no reason to reject it.

But if it turns out that the drivers always use either "default"
or "active" and never both I consider it a pure naming
convention and will not accept the "active" state.

Now it's time for patches :-)

Yours,
Linus Walleij


From ebiederm at xmission.com  Wed Jul 10 16:42:17 2013
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Wed, 10 Jul 2013 13:42:17 -0700
Subject: [PATCH] kexec: return error of machine_kexec() fails
In-Reply-To: <51DDB159.2080003@wwwdotorg.org> (Stephen Warren's message of
 "Wed, 10 Jul 2013 13:09:13 -0600")
References: <1373421296-6112-1-git-send-email-horms@verge.net.au>
 <87obaaiiry.fsf@xmission.com> <51DDB159.2080003@wwwdotorg.org>
Message-ID: <87txk2cfkm.fsf@xmission.com>

Stephen Warren <swarren at wwwdotorg.org> writes:

> On 07/10/2013 08:36 AM, Eric W. Biederman wrote:
>> Simon Horman <horms at verge.net.au> writes:
>> 
>>> From: Stephen Warren <swarren at nvidia.com>
>>>
>>> Prior to commit 3ab8352 "kexec jump", if machine_kexec() returned,
>>> sys_reboot() would return -EINVAL. This patch restores this behaviour
>>> for the non-KEXEC_JUMP case, where machine_kexec() is not expected to
>>> return.
>>>
>>> This situation can occur on ARM, where kexec requires disabling all but
>>> one CPU using CPU hotplug. However, if hotplug isn't supported by the
>>> particular HW the kernel is running on, then kexec cannot succeed.
>> 
>> Ugh. This reasoning is nonsense.  Prior to the kexec jump work
>> machine_kexec could never return and so could never return -EINVAL.
>
> Well, any function /can/ return. Perhaps there was some undocumented
> requirement that machine_kexec() was not allowed to return?

I think the name and the lack of an error code is in general a strong
indication that machine_kexec should not return.  As returning is
semantically wrong (baring kexec_jump).  There is the additional fact
that machine_kexec does not return.

> I did test
> it, and everything appears to work fine if it does return, aside from
> the error code.

My point was really that semantically you are failing in the wrong
location.


>> It is not ok to have an image loaded that we can not kexec.  kexec_load
>> should fail not machine_shutdown or machine_kexec.
>
> Hmm. I suppose one option is to enhance ARM's machine_kexec_prepare(),
> which is called from kexec_load(), and have that fail unless either the
> current HW is non-SMP, or full CPU HW/driver hotplug/PM support is
> available, so that it's guaranteed that machine_shutdown() will be able
> to fully disable all but one CPU.
>
> Would that be acceptable?

Yes.  Failing in kexec_load via ARMS's machine_kexec_prepare seems much
more appropriate, and it is where userspace will expect and be prepared
to deal with a failure.

> Other alternatives would be:
>
> a) Force the user to disable (hot unplug) the CPUs themselves before
> calling kexec_load(). This seems rather onerous, and could be defeated
> by replugging them between kexec_load() and kernel_kexec().
>
> b) Actually modifying kexec_load() to disable the CPUs, at the point
> where it's legal for it to fail. However, I suspect some use-cases call
> kexec_load() a long time before kernel_kexec(), so this would end up
> disabling SMP way too early.
>
>> ARM needs to get it's act together and stop modifying the generic code
>> to deal with it's broken multi-cpu architecture.
>
> A standardized in-CPU mechanism for disabling CPUs as part of the ARM
> architecture would be nice. However, even if that appears today, it's
> not going to help all the already extant systems that don't have it.

I meant code not hardware architecture.  We keep having code thrown in
the the shutdown paths because ARM only supports cpu shutdown via cpu
hotunplug and cpu hotunplug is not universally available.

That is a software architecture BUG with the ARM kernels.

I admit that using cpu hotunplug for everything sounds good on paper but
in practice cpu hotunplug is a nasty heavy weight monster that is much
harder to support than other cpu shutdown schemes.

Eric


From neko at bakuhatsu.net  Wed Jul 10 16:50:10 2013
From: neko at bakuhatsu.net (Matt Sealey)
Date: Wed, 10 Jul 2013 15:50:10 -0500
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <20130709124900.GG11908@titan.lakedaemon.net>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
Message-ID: <CAHCPf3u=Zu2-4RsWzi17rB_FmStwcf-Pt_7oRzAEnxN_w=a7cA@mail.gmail.com>

On Tue, Jul 9, 2013 at 7:49 AM, Jason Cooper <jason at lakedaemon.net> wrote:
> Neil,
>
> I agree with the need to change, however, this has been in the binding
> documentation since v3.5.  I wish we had caught this when we decided
> against using stock ticker symbols (not all stock markets use
> alphabetical abbreviated names, not all companies are listed on any
> stock exchange).

Who decided that?

You can't just "stop using stock ticker symbols" - FDT is inherently
based on the original OpenFirmware device tree and therefore any
existing bindings which are done on real OpenFirmware solutions where
using stock ticker symbols is entirely appropriate (although, these
days, not useful) is counter-productive.

If Marvell had originally had mrvl as their ticker, and used this in
OF DTs (and it is..), then mrvl it stays. In the case where new
devices are added with marvell, this is in this case wrong. You should
keep using the old one. A good example of this; Freescale. Nobody is
saying everyone should move to "freescale,imx-this" or
"freescale,vybrid-that" - it's fsl and it stays fsl for
backwards/forwards compatibility because things exist already.

Any new companies can have a long, descriptive name; a privilege of
being late to the party, you might say :)

Having an odd mix of mrvl and marvell or moving to marvell is just
completely obtuse, whether they had that stock ticker, will have it in
the future, it is how they're defined and you can't in good conscience
change the binding after devices ship with it.

> To do this properly, the drivers are going to have to be compatible with
> the old and the new names, and the binding docs updated to reflect the
> legacy name and the preferred name.

Properly would be as above. You can stop using stock tickers for new
company names, but anything that has been defined in a device tree
before has to stay that way, and all the manufacturer prefixes to
device names should be the same. What you're proposing is purely
driver bloat and increasing the size of kernel.

--
Matt Sealey <neko at bakuhatsu.net>


From festevam at gmail.com  Wed Jul 10 16:50:19 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 10 Jul 2013 17:50:19 -0300
Subject: [PATCH v2 2/2] ARM: dts: imx6dl-wandboard: Add support for UART3
In-Reply-To: <1373489419-20893-1-git-send-email-festevam@gmail.com>
References: <1373489419-20893-1-git-send-email-festevam@gmail.com>
Message-ID: <1373489419-20893-2-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Wandboard has a bluetooth device connected to UART3, so add support for it.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- Also add the usdhc pinmux groups to mx6q

 arch/arm/boot/dts/imx6dl-wandboard.dts |  7 +++++++
 arch/arm/boot/dts/imx6dl.dtsi          | 18 ++++++++++++++++++
 arch/arm/boot/dts/imx6q.dtsi           | 18 ++++++++++++++++++
 3 files changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts b/arch/arm/boot/dts/imx6dl-wandboard.dts
index 027ece5..2654b32 100644
--- a/arch/arm/boot/dts/imx6dl-wandboard.dts
+++ b/arch/arm/boot/dts/imx6dl-wandboard.dts
@@ -108,6 +108,13 @@
 	status = "okay";
 };
 
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart3_2>;
+	fsl,uart-has-rtscts;
+	status = "okay";
+};
+
 &usbh1 {
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 49ac931..58a7dbc 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -241,6 +241,24 @@
 					};
 				};
 
+				uart3 {
+					pinctrl_uart3_1: uart3grp-1 {
+						fsl,pins = <
+							MX6DL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
+							MX6DL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
+						>;
+					};
+
+					pinctrl_uart3_2: uart3grp-2 {
+						fsl,pins = <
+							MX6DL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
+							MX6DL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
+							MX6DL_PAD_EIM_D23__UART3_CTS_B 0x1b0b1
+							MX6DL_PAD_EIM_EB3__UART3_RTS_B 0x1b0b1
+						>;
+					};
+				};
+
 				uart4 {
 					pinctrl_uart4_1: uart4grp-1 {
 						fsl,pins = <
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index f039a25..a0e17a5 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -277,6 +277,24 @@
 					};
 				};
 
+				uart3 {
+					pinctrl_uart3_1: uart3grp-1 {
+						fsl,pins = <
+							MX6Q_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
+							MX6Q_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
+						>;
+					};
+
+					pinctrl_uart3_2: uart3grp-2 {
+						fsl,pins = <
+							MX6Q_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
+							MX6Q_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
+							MX6Q_PAD_EIM_D23__UART3_CTS_B 0x1b0b1
+							MX6Q_PAD_EIM_EB3__UART3_RTS_B 0x1b0b1
+						>;
+					};
+				};
+
 				uart4 {
 					pinctrl_uart4_1: uart4grp-1 {
 						fsl,pins = <
-- 
1.8.1.2



From festevam at gmail.com  Wed Jul 10 16:50:18 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 10 Jul 2013 17:50:18 -0300
Subject: [PATCH v2 1/2] ARM: dts: imx6dl-wandboard: Add SDHC1 and SDHC2 ports
Message-ID: <1373489419-20893-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Wandboard has a SD card slot on the baseboard connected to SDHC1 and a
BCM4329 (Wifi + Bluetooth chip) connected to SDHC2.

Add support for these ports.

While at it, provide the card detect gpio on SDHC3.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- Also add the usdhc pinmux groups to mx6q

 arch/arm/boot/dts/imx6dl-wandboard.dts | 17 +++++++++++++++++
 arch/arm/boot/dts/imx6dl.dtsi          | 29 +++++++++++++++++++++++++++++
 arch/arm/boot/dts/imx6q.dtsi           | 28 ++++++++++++++++++++++++++++
 3 files changed, 74 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts b/arch/arm/boot/dts/imx6dl-wandboard.dts
index ab6a053..027ece5 100644
--- a/arch/arm/boot/dts/imx6dl-wandboard.dts
+++ b/arch/arm/boot/dts/imx6dl-wandboard.dts
@@ -83,6 +83,8 @@
 		pinctrl_hog: hoggrp {
 			fsl,pins = <
 				MX6DL_PAD_GPIO_0__CCM_CLKO1    0x130b0
+				MX6DL_PAD_GPIO_2__GPIO1_IO02	0x80000000
+				MX6DL_PAD_EIM_DA9__GPIO3_IO09	0x80000000
 			>;
 		};
 	};
@@ -110,8 +112,23 @@
 	status = "okay";
 };
 
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1_2>;
+	cd-gpios = <&gpio1 2 0>;
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2_2>;
+	non-removable;
+	status = "okay";
+};
+
 &usdhc3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usdhc3_2>;
+	cd-gpios = <&gpio3 9 0>;
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index d75e32c..49ac931 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -264,6 +264,35 @@
 					};
 				};
 
+				usdhc1 {
+					pinctrl_usdhc1_1: usdhc1grp-1 {
+						fsl,pins = <
+							MX6DL_PAD_SD1_CMD__SD1_CMD    0x17059
+							MX6DL_PAD_SD1_CLK__SD1_CLK    0x10059
+							MX6DL_PAD_SD1_DAT0__SD1_DATA0 0x17059
+							MX6DL_PAD_SD1_DAT1__SD1_DATA1 0x17059
+							MX6DL_PAD_SD1_DAT2__SD1_DATA2 0x17059
+							MX6DL_PAD_SD1_DAT3__SD1_DATA3 0x17059
+							MX6DL_PAD_NANDF_D0__SD1_DATA4 0x17059
+							MX6DL_PAD_NANDF_D1__SD1_DATA5 0x17059
+							MX6DL_PAD_NANDF_D2__SD1_DATA6 0x17059
+							MX6DL_PAD_NANDF_D3__SD1_DATA7 0x17059
+						>;
+					};
+
+					pinctrl_usdhc1_2: usdhc1grp-2 {
+						fsl,pins = <
+							MX6DL_PAD_SD1_CMD__SD1_CMD    0x17059
+							MX6DL_PAD_SD1_CLK__SD1_CLK    0x10059
+							MX6DL_PAD_SD1_DAT0__SD1_DATA0 0x17059
+							MX6DL_PAD_SD1_DAT1__SD1_DATA1 0x17059
+							MX6DL_PAD_SD1_DAT2__SD1_DATA2 0x17059
+							MX6DL_PAD_SD1_DAT3__SD1_DATA3 0x17059
+						>;
+					};
+				};
+
+
 				usdhc2 {
 					pinctrl_usdhc2_1: usdhc2grp-1 {
 						fsl,pins = <
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index e0b7bad..f039a25 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -300,6 +300,34 @@
 					};
 				};
 
+				usdhc1 {
+					pinctrl_usdhc1_1: usdhc1grp-1 {
+						fsl,pins = <
+							MX6Q_PAD_SD1_CMD__SD1_CMD    0x17059
+							MX6Q_PAD_SD1_CLK__SD1_CLK    0x10059
+							MX6Q_PAD_SD1_DAT0__SD1_DATA0 0x17059
+							MX6Q_PAD_SD1_DAT1__SD1_DATA1 0x17059
+							MX6Q_PAD_SD1_DAT2__SD1_DATA2 0x17059
+							MX6Q_PAD_SD1_DAT3__SD1_DATA3 0x17059
+							MX6Q_PAD_NANDF_D0__SD1_DATA4 0x17059
+							MX6Q_PAD_NANDF_D1__SD1_DATA5 0x17059
+							MX6Q_PAD_NANDF_D2__SD1_DATA6 0x17059
+							MX6Q_PAD_NANDF_D3__SD1_DATA7 0x17059
+						>;
+					};
+
+					pinctrl_usdhc1_2: usdhc1grp-2 {
+						fsl,pins = <
+							MX6Q_PAD_SD1_CMD__SD1_CMD    0x17059
+							MX6Q_PAD_SD1_CLK__SD1_CLK    0x10059
+							MX6Q_PAD_SD1_DAT0__SD1_DATA0 0x17059
+							MX6Q_PAD_SD1_DAT1__SD1_DATA1 0x17059
+							MX6Q_PAD_SD1_DAT2__SD1_DATA2 0x17059
+							MX6Q_PAD_SD1_DAT3__SD1_DATA3 0x17059
+						>;
+					};
+				};
+
 				usdhc2 {
 					pinctrl_usdhc2_1: usdhc2grp-1 {
 						fsl,pins = <
-- 
1.8.1.2



From s.hauer at pengutronix.de  Wed Jul 10 17:04:14 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 10 Jul 2013 23:04:14 +0200
Subject: [v4 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <1373445355-11453-4-git-send-email-Hong-Xing.Zhu@freescale.com>
References: <1373445355-11453-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373445355-11453-4-git-send-email-Hong-Xing.Zhu@freescale.com>
Message-ID: <20130710210414.GK516@pengutronix.de>

On Wed, Jul 10, 2013 at 04:35:55PM +0800, Richard Zhu wrote:
> From: Richard Zhu <r65037 at freescale.com>
> 
> imx6q contains one Synopsys AHCI SATA controller,
> But it can't shares ahci_platform driver with other
> controllers.
> Because there are some misalignments of the generic
> AHCI controller.
> The bits definitions of the HBA registers, the Vendor
> Specific registers, and the AHCI PHY clock.
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>  value is '0', should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the
>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>  should be configured regarding to the frequency of AHB
>  bus clock.
>  - Configurations of the AHCI PHY clock, and the signal
>  parameters of the GPR13
> 
> Setup its own ahci sata driver, contained the imx6q specific
> initialized codes, and re-use the generic ahci_platform drier,
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  drivers/ata/Kconfig    |    9 ++
>  drivers/ata/Makefile   |    1 +
>  drivers/ata/sata_imx.c |  237 ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 247 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/ata/sata_imx.c
> 

[...]

> +
> +/* imx6q ahci module initialization. */
> +static int imx6q_sata_init(struct device *dev, void __iomem *mmio)
> +{
> +	int ret = 0;
> +	unsigned int rc;
> +	struct regmap *gpr;
> +	struct clk *ahb_clk;
> +	struct imx_ahci_priv *imxpriv = (struct imx_ahci_priv *)dev->p;

Just because a pointer points to valid memory doesn't mean that it's
free to use for your purposes. If you look closer maybe you realize that
the imxpriv pointer you use here is another one than the one you
allocate below in your probe function.

I give up here. Maybe I'll write a driver for this when I find time for
it.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From jason at lakedaemon.net  Wed Jul 10 17:49:22 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 10 Jul 2013 17:49:22 -0400
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <CAHCPf3u=Zu2-4RsWzi17rB_FmStwcf-Pt_7oRzAEnxN_w=a7cA@mail.gmail.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <CAHCPf3u=Zu2-4RsWzi17rB_FmStwcf-Pt_7oRzAEnxN_w=a7cA@mail.gmail.com>
Message-ID: <20130710214922.GQ11908@titan.lakedaemon.net>

On Wed, Jul 10, 2013 at 03:50:10PM -0500, Matt Sealey wrote:
> On Tue, Jul 9, 2013 at 7:49 AM, Jason Cooper <jason at lakedaemon.net> wrote:
> > Neil,
> >
> > I agree with the need to change, however, this has been in the binding
> > documentation since v3.5.  I wish we had caught this when we decided
> > against using stock ticker symbols (not all stock markets use
> > alphabetical abbreviated names, not all companies are listed on any
> > stock exchange).
> 
> Who decided that?

Now you're going to make me dig ;-)  iirc, we were going the stock
ticker route, but then noticed that powerpc dts files had been using
"marvell,..." for a _long_ time.  How long?  I'll leave that as an
exercise for the reader. :-P  Because we shared at least the ethernet
driver with them, we decided to conform with what was already present in
the kernel and use "marvell,..." for all of the dt bindings we were
creating for kirkwood/dove/mvebu (and eventually orion5x, mv78xx0).

As for who is 'we'?

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101337.html

> You can't just "stop using stock ticker symbols" - FDT is inherently
> based on the original OpenFirmware device tree and therefore any
> existing bindings which are done on real OpenFirmware solutions where
> using stock ticker symbols is entirely appropriate (although, these
> days, not useful) is counter-productive.
> 
> If Marvell had originally had mrvl as their ticker, and used this in
> OF DTs (and it is..), then mrvl it stays. In the case where new
> devices are added with marvell, this is in this case wrong. You should
> keep using the old one. A good example of this; Freescale. Nobody is
> saying everyone should move to "freescale,imx-this" or
> "freescale,vybrid-that" - it's fsl and it stays fsl for
> backwards/forwards compatibility because things exist already.

I agree, that's why I'm arguing for *maintaining* backwards
compatibility.

> Any new companies can have a long, descriptive name; a privilege of
> being late to the party, you might say :)
> 
> Having an odd mix of mrvl and marvell or moving to marvell is just
> completely obtuse, whether they had that stock ticker, will have it in
> the future, it is how they're defined and you can't in good conscience
> change the binding after devices ship with it.

See above regarding the marvell ethernet driver and powerpc...

> > To do this properly, the drivers are going to have to be compatible with
> > the old and the new names, and the binding docs updated to reflect the
> > legacy name and the preferred name.
> 
> Properly would be as above. You can stop using stock tickers for new
> company names, but anything that has been defined in a device tree
> before has to stay that way, and all the manufacturer prefixes to
> device names should be the same. What you're proposing is purely
> driver bloat and increasing the size of kernel.

*I'm* not proposing to change the name, Neil is.  I'm proposing that
*iff* they chose to do that, don't break sh*t along the way.

thx,

Jason.


From jason at lakedaemon.net  Wed Jul 10 17:50:41 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 10 Jul 2013 17:50:41 -0400
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <CAN1soZzMvront1-jcBW6-uRKNs0OZNGnmiOjKGZSM28bViB_8A@mail.gmail.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <CAN1soZxiOh6TpbUOCUzK8gNwmvjbT3ihkUWaw8tuZ7md+NVA2g@mail.gmail.com>
 <20130710122433.GO11908@titan.lakedaemon.net>
 <CAN1soZzMvront1-jcBW6-uRKNs0OZNGnmiOjKGZSM28bViB_8A@mail.gmail.com>
Message-ID: <20130710215041.GR11908@titan.lakedaemon.net>

On Wed, Jul 10, 2013 at 10:08:50PM +0800, Haojian Zhuang wrote:
> On Wed, Jul 10, 2013 at 8:24 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> > On Wed, Jul 10, 2013 at 04:19:46PM +0800, Haojian Zhuang wrote:
> >> On Tue, Jul 9, 2013 at 8:49 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> >> > Neil,
> >> >
> >> > On Tue, Jul 09, 2013 at 02:42:44PM +0800, Neil Zhang wrote:
> >> >> The documented vendor prefix for Marvell is 'marvell', not 'mrvl', so
> >> >> let's change it.
> >> >>
> >> >> Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> >> >> ---
> >> >>  .../devicetree/bindings/arm/mrvl/intc.txt          |   16 +++---
> >> >>  .../devicetree/bindings/arm/mrvl/mrvl.txt          |    6 +-
> >> >>  .../devicetree/bindings/arm/mrvl/timer.txt         |    4 +-
> >> >>  Documentation/devicetree/bindings/i2c/i2c-pxa.txt  |   14 +++---
> >> >>  .../devicetree/bindings/mmc/sdhci-pxa.txt          |    8 ++--
> >> >>  .../devicetree/bindings/rtc/sa1100-rtc.txt         |    4 +-
> >> >>  .../devicetree/bindings/serial/mrvl-serial.txt     |    2 +-
> >> >>  arch/arm/boot/dts/mmp2-brownstone.dts              |    2 +-
> >> >>  arch/arm/boot/dts/mmp2.dtsi                        |   56 ++++++++++----------
> >> >>  arch/arm/boot/dts/pxa168-aspenite.dts              |    2 +-
> >> >>  arch/arm/boot/dts/pxa168.dtsi                      |   24 ++++----
> >> >>  arch/arm/boot/dts/pxa2xx.dtsi                      |   16 +++---
> >> >>  arch/arm/boot/dts/pxa3xx.dtsi                      |    2 +-
> >> >>  arch/arm/boot/dts/pxa910-dkb.dts                   |    2 +-
> >> >>  arch/arm/boot/dts/pxa910.dtsi                      |   27 +++++-----
> >> >>  arch/arm/mach-mmp/irq.c                            |   16 +++---
> >> >>  arch/arm/mach-mmp/mmp-dt.c                         |   28 +++++-----
> >> >>  arch/arm/mach-mmp/mmp2-dt.c                        |   16 +++---
> >> >>  arch/arm/mach-mmp/time.c                           |    2 +-
> >> >>  arch/arm/mach-pxa/pxa-dt.c                         |   14 +++---
> >> >>  drivers/i2c/busses/i2c-pxa.c                       |   10 ++--
> >> >>  drivers/mmc/host/sdhci-pxav2.c                     |    4 +-
> >> >>  drivers/mmc/host/sdhci-pxav3.c                     |    4 +-
> >> >>  drivers/rtc/rtc-sa1100.c                           |    4 +-
> >> >>  drivers/tty/serial/pxa.c                           |    4 +-
> >> >>  25 files changed, 144 insertions(+), 143 deletions(-)
> >> >
> >> > I agree with the need to change, however, this has been in the binding
> >> > documentation since v3.5.  I wish we had caught this when we decided
> >> > against using stock ticker symbols (not all stock markets use
> >> > alphabetical abbreviated names, not all companies are listed on any
> >> > stock exchange).
> >> >
> >> > To do this properly, the drivers are going to have to be compatible with
> >> > the old and the new names, and the binding docs updated to reflect the
> >> > legacy name and the preferred name.
> >> >
> >>
> >> It's better to only use the new names.
> >
> > In the dts{i}, yes.  But we don't want to break systems in the field
> > with "mrvl,..." compatible strings.  Therefore, at least the drivers
> > need an extra compatible string to support "mrvl,...".
> >
> > If it had just been since v3.9, it'd be different/simpler.  However,
> > several vendors have opted to use kernels newer than v3.5, which makes
> > this scenario a real possibility.
> >
> > thx,
> >
> > Jason.
> 
> Is there any vendor using DT for this Marvell chip? I think the answer is no.

Well, Daniel Drake spoke up for OLPC.  Does that count?

thx,

Jason.



From mark.rutland at arm.com  Wed Jul 10 18:11:14 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Jul 2013 23:11:14 +0100
Subject: [RFC PATCH 0/5] arm64: initial CPU_HOTPLUG support
Message-ID: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>

The following patches add basic CPU_HOTPLUG support to arm64, which
combined with appropriate firmware (e.g. [1]) can be used to power CPUs
up and down dynamically. From discussions at connect it seemed that
several people were interested in working in this area, so I thought I'd
make my current implementation public now that I've managed to regain
access to my inbox.

I've tested this series with the bootwrapper PSCI implementation I've
placed on linux-arm.org [1] and a modified foundation model dts with a
psci node and each CPU's enable-method set to "psci", using a shell
while repeatedly cycling all cpus off and on:

for C in $(seq 0 3); do
	./cyclichotplug.sh $C >/dev/null 2>&1 &
done

---->8----
#!/bin/sh
# cyclichotplug.sh

CPU=$1;

if [ -z "$CPU" ]; then
	printf "Usage: $0 <cpu id>\n";
	exit 1;
fi

ONLINEFILE=/sys/devices/system/cpu/cpu$CPU/online;

while true; do
	echo 0 > $ONLINEFILE;
	echo 1 > $ONLINEFILE;
done
---->8----

Patches are based on v3.10.

Thanks,
Mark.

[1] http://linux-arm.org/git?p=boot-wrapper-aarch64.git;a=shortlog;h=refs/tags/simple-psci

Mark Rutland (5):
  arm64: reorganise smp_enable_ops
  arm64: factor out spin-table boot method
  arm64: read enable-method for CPU0
  arm64: add CPU_HOTPLUG infrastructure
  arm64: add PSCI CPU_OFF-based hotplug support

 arch/arm64/Kconfig                 |    7 ++
 arch/arm64/include/asm/irq.h       |    1 +
 arch/arm64/include/asm/smp.h       |   37 +++++--
 arch/arm64/kernel/cputable.c       |    2 +-
 arch/arm64/kernel/head.S           |   12 +-
 arch/arm64/kernel/irq.c            |   61 ++++++++++
 arch/arm64/kernel/process.c        |    7 ++
 arch/arm64/kernel/smp.c            |  215 ++++++++++++++++++++++--------------
 arch/arm64/kernel/smp_psci.c       |   54 +++++++--
 arch/arm64/kernel/smp_spin_table.c |   85 +++++++++++++-
 arch/arm64/kernel/vmlinux.lds.S    |    1 -
 11 files changed, 375 insertions(+), 107 deletions(-)

-- 
1.7.9.5



From mark.rutland at arm.com  Wed Jul 10 18:13:54 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Jul 2013 23:13:54 +0100
Subject: [RFC PATCH 1/5] arm64: reorganise smp_enable_ops
In-Reply-To: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
References: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1373494438-24780-1-git-send-email-mark.rutland@arm.com>

For hotplug support, we're going to want a place to store operations
that do more than bring CPUs online, and it makes sense to group these
with our current smp_enable_ops.

This patch renames smp_enable_ops to smp_ops to make the intended use of
the structure clearer. While we're at it, we mark the necessary structs
and functions as __cpuinit* rather than __init*, fix up instances of the
cpu parameter to be an unsigned int, and rename the *_cpu functions to
cpu_* to reduce future churn when smp_operations is extended.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/include/asm/smp.h       |   10 +++++-----
 arch/arm64/kernel/smp.c            |   24 ++++++++++++------------
 arch/arm64/kernel/smp_psci.c       |   10 +++++-----
 arch/arm64/kernel/smp_spin_table.c |   10 +++++-----
 4 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index 4b8023c..90626b6 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -68,13 +68,13 @@ extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
 
 struct device_node;
 
-struct smp_enable_ops {
+struct smp_operations {
 	const char	*name;
-	int		(*init_cpu)(struct device_node *, int);
-	int		(*prepare_cpu)(int);
+	int		(*cpu_init)(struct device_node *, unsigned int);
+	int		(*cpu_prepare)(unsigned int);
 };
 
-extern const struct smp_enable_ops smp_spin_table_ops;
-extern const struct smp_enable_ops smp_psci_ops;
+extern const struct smp_operations smp_spin_table_ops;
+extern const struct smp_operations smp_psci_ops;
 
 #endif /* ifndef __ASM_SMP_H */
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 5d54e37..207bf4f 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -235,17 +235,17 @@ void __init smp_prepare_boot_cpu(void)
 
 static void (*smp_cross_call)(const struct cpumask *, unsigned int);
 
-static const struct smp_enable_ops *enable_ops[] __initconst = {
+static const struct smp_operations *supported_smp_ops[] __initconst = {
 	&smp_spin_table_ops,
 	&smp_psci_ops,
 	NULL,
 };
 
-static const struct smp_enable_ops *smp_enable_ops[NR_CPUS];
+static const struct smp_operations *smp_ops[NR_CPUS];
 
-static const struct smp_enable_ops * __init smp_get_enable_ops(const char *name)
+static const struct smp_operations * __init smp_get_ops(const char *name)
 {
-	const struct smp_enable_ops **ops = enable_ops;
+	const struct smp_operations **ops = supported_smp_ops;
 
 	while (*ops) {
 		if (!strcmp(name, (*ops)->name))
@@ -266,7 +266,7 @@ void __init smp_init_cpus(void)
 {
 	const char *enable_method;
 	struct device_node *dn = NULL;
-	int i, cpu = 1;
+	unsigned int i, cpu = 1;
 	bool bootcpu_valid = false;
 
 	while ((dn = of_find_node_by_type(dn, "cpu"))) {
@@ -345,15 +345,15 @@ void __init smp_init_cpus(void)
 			goto next;
 		}
 
-		smp_enable_ops[cpu] = smp_get_enable_ops(enable_method);
+		smp_ops[cpu] = smp_get_ops(enable_method);
 
-		if (!smp_enable_ops[cpu]) {
+		if (!smp_ops[cpu]) {
 			pr_err("%s: invalid enable-method property: %s\n",
 			       dn->full_name, enable_method);
 			goto next;
 		}
 
-		if (smp_enable_ops[cpu]->init_cpu(dn, cpu))
+		if (smp_ops[cpu]->cpu_init(dn, cpu))
 			goto next;
 
 		pr_debug("cpu logical map 0x%llx\n", hwid);
@@ -383,8 +383,8 @@ next:
 
 void __init smp_prepare_cpus(unsigned int max_cpus)
 {
-	int cpu, err;
-	unsigned int ncores = num_possible_cpus();
+	int err;
+	unsigned int cpu, ncores = num_possible_cpus();
 
 	/*
 	 * are we trying to boot more cores than exist?
@@ -411,10 +411,10 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 		if (cpu == smp_processor_id())
 			continue;
 
-		if (!smp_enable_ops[cpu])
+		if (!smp_ops[cpu])
 			continue;
 
-		err = smp_enable_ops[cpu]->prepare_cpu(cpu);
+		err = smp_ops[cpu]->cpu_prepare(cpu);
 		if (err)
 			continue;
 
diff --git a/arch/arm64/kernel/smp_psci.c b/arch/arm64/kernel/smp_psci.c
index 0c53330..e833930 100644
--- a/arch/arm64/kernel/smp_psci.c
+++ b/arch/arm64/kernel/smp_psci.c
@@ -23,12 +23,12 @@
 #include <asm/psci.h>
 #include <asm/smp_plat.h>
 
-static int __init smp_psci_init_cpu(struct device_node *dn, int cpu)
+static int __cpuinit smp_psci_cpu_init(struct device_node *dn, unsigned int cpu)
 {
 	return 0;
 }
 
-static int __init smp_psci_prepare_cpu(int cpu)
+static int __cpuinit smp_psci_cpu_prepare(unsigned int cpu)
 {
 	int err;
 
@@ -46,8 +46,8 @@ static int __init smp_psci_prepare_cpu(int cpu)
 	return 0;
 }
 
-const struct smp_enable_ops smp_psci_ops __initconst = {
+const struct smp_operations smp_psci_ops __cpuinitconst = {
 	.name		= "psci",
-	.init_cpu	= smp_psci_init_cpu,
-	.prepare_cpu	= smp_psci_prepare_cpu,
+	.cpu_init	= smp_psci_cpu_init,
+	.cpu_prepare	= smp_psci_cpu_prepare,
 };
diff --git a/arch/arm64/kernel/smp_spin_table.c b/arch/arm64/kernel/smp_spin_table.c
index 7c35fa6..098bf64 100644
--- a/arch/arm64/kernel/smp_spin_table.c
+++ b/arch/arm64/kernel/smp_spin_table.c
@@ -24,7 +24,7 @@
 
 static phys_addr_t cpu_release_addr[NR_CPUS];
 
-static int __init smp_spin_table_init_cpu(struct device_node *dn, int cpu)
+static int __cpuinit smp_spin_table_cpu_init(struct device_node *dn, unsigned int cpu)
 {
 	/*
 	 * Determine the address from which the CPU is polling.
@@ -40,7 +40,7 @@ static int __init smp_spin_table_init_cpu(struct device_node *dn, int cpu)
 	return 0;
 }
 
-static int __init smp_spin_table_prepare_cpu(int cpu)
+static int __cpuinit smp_spin_table_cpu_prepare(unsigned int cpu)
 {
 	void **release_addr;
 
@@ -59,8 +59,8 @@ static int __init smp_spin_table_prepare_cpu(int cpu)
 	return 0;
 }
 
-const struct smp_enable_ops smp_spin_table_ops __initconst = {
+const struct smp_operations smp_spin_table_ops __cpuinitconst = {
 	.name		= "spin-table",
-	.init_cpu 	= smp_spin_table_init_cpu,
-	.prepare_cpu	= smp_spin_table_prepare_cpu,
+	.cpu_init	= smp_spin_table_cpu_init,
+	.cpu_prepare	= smp_spin_table_cpu_prepare,
 };
-- 
1.7.9.5



From mark.rutland at arm.com  Wed Jul 10 18:15:13 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Jul 2013 23:15:13 +0100
Subject: [RFC PATCH 2/5] arm64: factor out spin-table boot method
In-Reply-To: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
References: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1373494513-24860-1-git-send-email-mark.rutland@arm.com>

The arm64 kernel has an internal holding pen, which is necessary for
some systems where we can't bring CPUs online individually and must hold
multiple CPUs in a safe area until the kernel is able to handle them.
The current SMP infrastructure for arm64 is closely coupled to this
holding pen, and alternative boot methods must launch CPUs into the pen,
from whence they are launched into the kernel proper.

With PSCI (and possibly other future boot methods), we can bring CPUs
online individually, and need not perform the secondary_holding_pen
dance. Instead, this patch factors the holding pen management code out
to the spin-table boot method code, as it is the only boot method
requiring the pen.

A new entry point for secondaries, secondary_entry is added for other
boot methods to use, which bypasses the holding pen and its associated
overhead when bringing CPUs online. The smp.pen.text section is also
removed, as the pen can live in head.text without problem.

The smp_operations structure is extended with two new functions,
cpu_boot and cpu_postboot, for bringing a cpu into the kernel and
performing any post-boot cleanup required by a bootmethod (e.g.
resetting the secondary_holding_pen_release to INVALID_HWID).

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/include/asm/smp.h       |   17 +++++++-
 arch/arm64/kernel/head.S           |   12 +++++-
 arch/arm64/kernel/smp.c            |   67 +++-----------------------------
 arch/arm64/kernel/smp_psci.c       |   16 ++++----
 arch/arm64/kernel/smp_spin_table.c |   75 ++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/vmlinux.lds.S    |    1 -
 6 files changed, 115 insertions(+), 73 deletions(-)

diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index 90626b6..af39644 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -60,8 +60,7 @@ struct secondary_data {
 	void *stack;
 };
 extern struct secondary_data secondary_data;
-extern void secondary_holding_pen(void);
-extern volatile unsigned long secondary_holding_pen_release;
+extern void secondary_entry(void);
 
 extern void arch_send_call_function_single_ipi(int cpu);
 extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
@@ -70,8 +69,22 @@ struct device_node;
 
 struct smp_operations {
 	const char	*name;
+	/*
+	 * Check devicetree data for cpu
+	 */
 	int		(*cpu_init)(struct device_node *, unsigned int);
+	/*
+	 * Test if cpu is present and bootable
+	 */
 	int		(*cpu_prepare)(unsigned int);
+	/*
+	 * Boot cpu into the kernel
+	 */
+	int		(*cpu_boot)(unsigned int);
+	/*
+	 * Performs post-boot cleanup
+	 */
+	void		(*cpu_postboot)(void);
 };
 
 extern const struct smp_operations smp_spin_table_ops;
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 53dcae4..3532ca6 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -217,7 +217,6 @@ ENTRY(__boot_cpu_mode)
 	.quad	PAGE_OFFSET
 
 #ifdef CONFIG_SMP
-	.pushsection    .smp.pen.text, "ax"
 	.align	3
 1:	.quad	.
 	.quad	secondary_holding_pen_release
@@ -242,7 +241,16 @@ pen:	ldr	x4, [x3]
 	wfe
 	b	pen
 ENDPROC(secondary_holding_pen)
-	.popsection
+
+	/*
+	 * Secondary entry point that jumps straight into the kernel. Only to
+	 * be used where CPUs are brought online dynamically by the kernel.
+	 */
+ENTRY(secondary_entry)
+	bl	__calc_phys_offset		// x2=phys offset
+	bl	el2_setup			// Drop to EL1
+	b	secondary_startup
+ENDPROC(secondary_entry)
 
 ENTRY(secondary_startup)
 	/*
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 207bf4f..e3a4fa1 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -54,7 +54,6 @@
  * where to place its SVC stack
  */
 struct secondary_data secondary_data;
-volatile unsigned long secondary_holding_pen_release = INVALID_HWID;
 
 enum ipi_msg_type {
 	IPI_RESCHEDULE,
@@ -63,22 +62,7 @@ enum ipi_msg_type {
 	IPI_CPU_STOP,
 };
 
-static DEFINE_RAW_SPINLOCK(boot_lock);
-
-/*
- * Write secondary_holding_pen_release in a way that is guaranteed to be
- * visible to all observers, irrespective of whether they're taking part
- * in coherency or not.  This is necessary for the hotplug code to work
- * reliably.
- */
-static void __cpuinit write_pen_release(u64 val)
-{
-	void *start = (void *)&secondary_holding_pen_release;
-	unsigned long size = sizeof(secondary_holding_pen_release);
-
-	secondary_holding_pen_release = val;
-	__flush_dcache_area(start, size);
-}
+static const struct smp_operations *smp_ops[NR_CPUS];
 
 /*
  * Boot a secondary CPU, and assign it the specified idle task.
@@ -86,38 +70,10 @@ static void __cpuinit write_pen_release(u64 val)
  */
 static int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
-	unsigned long timeout;
-
-	/*
-	 * Set synchronisation state between this boot processor
-	 * and the secondary one
-	 */
-	raw_spin_lock(&boot_lock);
-
-	/*
-	 * Update the pen release flag.
-	 */
-	write_pen_release(cpu_logical_map(cpu));
-
-	/*
-	 * Send an event, causing the secondaries to read pen_release.
-	 */
-	sev();
-
-	timeout = jiffies + (1 * HZ);
-	while (time_before(jiffies, timeout)) {
-		if (secondary_holding_pen_release == INVALID_HWID)
-			break;
-		udelay(10);
-	}
-
-	/*
-	 * Now the secondary core is starting up let it run its
-	 * calibrations, then wait for it to finish
-	 */
-	raw_spin_unlock(&boot_lock);
+	if (smp_ops[cpu]->cpu_boot)
+		return smp_ops[cpu]->cpu_boot(cpu);
 
-	return secondary_holding_pen_release != INVALID_HWID ? -ENOSYS : 0;
+	return -EOPNOTSUPP;
 }
 
 static DECLARE_COMPLETION(cpu_running);
@@ -187,17 +143,8 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
 	preempt_disable();
 	trace_hardirqs_off();
 
-	/*
-	 * Let the primary processor know we're out of the
-	 * pen, then head off into the C entry point
-	 */
-	write_pen_release(INVALID_HWID);
-
-	/*
-	 * Synchronise with the boot thread.
-	 */
-	raw_spin_lock(&boot_lock);
-	raw_spin_unlock(&boot_lock);
+	if (smp_ops[cpu]->cpu_postboot)
+		smp_ops[cpu]->cpu_postboot();
 
 	/*
 	 * Enable local interrupts.
@@ -241,8 +188,6 @@ static const struct smp_operations *supported_smp_ops[] __initconst = {
 	NULL,
 };
 
-static const struct smp_operations *smp_ops[NR_CPUS];
-
 static const struct smp_operations * __init smp_get_ops(const char *name)
 {
 	const struct smp_operations **ops = supported_smp_ops;
diff --git a/arch/arm64/kernel/smp_psci.c b/arch/arm64/kernel/smp_psci.c
index e833930..24dbad9 100644
--- a/arch/arm64/kernel/smp_psci.c
+++ b/arch/arm64/kernel/smp_psci.c
@@ -30,24 +30,26 @@ static int __cpuinit smp_psci_cpu_init(struct device_node *dn, unsigned int cpu)
 
 static int __cpuinit smp_psci_cpu_prepare(unsigned int cpu)
 {
-	int err;
-
 	if (!psci_ops.cpu_on) {
 		pr_err("psci: no cpu_on method, not booting CPU%d\n", cpu);
 		return -ENODEV;
 	}
 
-	err = psci_ops.cpu_on(cpu_logical_map(cpu), __pa(secondary_holding_pen));
-	if (err) {
+	return 0;
+}
+
+static int __cpuinit smp_psci_cpu_boot(unsigned int cpu)
+{
+	int err = psci_ops.cpu_on(cpu_logical_map(cpu), __pa(secondary_entry));
+	if (err)
 		pr_err("psci: failed to boot CPU%d (%d)\n", cpu, err);
-		return err;
-	}
 
-	return 0;
+	return err;
 }
 
 const struct smp_operations smp_psci_ops __cpuinitconst = {
 	.name		= "psci",
 	.cpu_init	= smp_psci_cpu_init,
 	.cpu_prepare	= smp_psci_cpu_prepare,
+	.cpu_boot	= smp_psci_cpu_boot,
 };
diff --git a/arch/arm64/kernel/smp_spin_table.c b/arch/arm64/kernel/smp_spin_table.c
index 098bf64..c4c116e 100644
--- a/arch/arm64/kernel/smp_spin_table.c
+++ b/arch/arm64/kernel/smp_spin_table.c
@@ -16,13 +16,36 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/delay.h>
 #include <linux/init.h>
 #include <linux/of.h>
 #include <linux/smp.h>
 
 #include <asm/cacheflush.h>
+#include <asm/cputype.h>
+#include <asm/smp_plat.h>
+
+extern void secondary_holding_pen(void);
+volatile unsigned long secondary_holding_pen_release = INVALID_HWID;
 
 static phys_addr_t cpu_release_addr[NR_CPUS];
+static DEFINE_RAW_SPINLOCK(boot_lock);
+
+/*
+ * Write secondary_holding_pen_release in a way that is guaranteed to be
+ * visible to all observers, irrespective of whether they're taking part
+ * in coherency or not.  This is necessary for the hotplug code to work
+ * reliably.
+ */
+static void __cpuinit write_pen_release(u64 val)
+{
+	void *start = (void *)&secondary_holding_pen_release;
+	unsigned long size = sizeof(secondary_holding_pen_release);
+
+	secondary_holding_pen_release = val;
+	__flush_dcache_area(start, size);
+}
+
 
 static int __cpuinit smp_spin_table_cpu_init(struct device_node *dn, unsigned int cpu)
 {
@@ -59,8 +82,60 @@ static int __cpuinit smp_spin_table_cpu_prepare(unsigned int cpu)
 	return 0;
 }
 
+static int smp_spin_table_cpu_boot(unsigned int cpu)
+{
+	unsigned long timeout;
+
+	/*
+	 * Set synchronisation state between this boot processor
+	 * and the secondary one
+	 */
+	raw_spin_lock(&boot_lock);
+
+	/*
+	 * Update the pen release flag.
+	 */
+	write_pen_release(cpu_logical_map(cpu));
+
+	/*
+	 * Send an event, causing the secondaries to read pen_release.
+	 */
+	sev();
+
+	timeout = jiffies + (1 * HZ);
+	while (time_before(jiffies, timeout)) {
+		if (secondary_holding_pen_release == INVALID_HWID)
+			break;
+		udelay(10);
+	}
+
+	/*
+	 * Now the secondary core is starting up let it run its
+	 * calibrations, then wait for it to finish
+	 */
+	raw_spin_unlock(&boot_lock);
+
+	return secondary_holding_pen_release != INVALID_HWID ? -ENOSYS : 0;
+}
+
+void __cpuinit smp_spin_table_cpu_postboot(void)
+{
+	/*
+	 * Let the primary processor know we're out of the pen.
+	 */
+	write_pen_release(INVALID_HWID);
+
+	/*
+	 * Synchronise with the boot thread.
+	 */
+	raw_spin_lock(&boot_lock);
+	raw_spin_unlock(&boot_lock);
+}
+
 const struct smp_operations smp_spin_table_ops __cpuinitconst = {
 	.name		= "spin-table",
 	.cpu_init	= smp_spin_table_cpu_init,
 	.cpu_prepare	= smp_spin_table_cpu_prepare,
+	.cpu_boot	= smp_spin_table_cpu_boot,
+	.cpu_postboot	= smp_spin_table_cpu_postboot,
 };
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 3fae2be..2c8a95b 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -41,7 +41,6 @@ SECTIONS
 	}
 	.text : {			/* Real text segment		*/
 		_stext = .;		/* Text and read-only data	*/
-			*(.smp.pen.text)
 			__exception_text_start = .;
 			*(.exception.text)
 			__exception_text_end = .;
-- 
1.7.9.5



From mark.rutland at arm.com  Wed Jul 10 18:15:38 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Jul 2013 23:15:38 +0100
Subject: [RFC PATCH 3/5] arm64: read enable-method for CPU0
In-Reply-To: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
References: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1373494538-24935-1-git-send-email-mark.rutland@arm.com>

With the advent of CPU_HOTPLUG, the enable-method property for CPU0
may tells us something useful (i.e. how to hotplug it back on), so
we must read it along with all the enable-method for all the other CPUs.

This patch ensures that CPU0's enable-method property is read.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/kernel/smp.c |   15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index e3a4fa1..15ec428 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -253,6 +253,8 @@ void __init smp_init_cpus(void)
 			}
 		}
 
+		enable_method = of_get_property(dn, "enable-method", NULL);
+
 		/*
 		 * The numbering scheme requires that the boot CPU
 		 * must be assigned logical id 0. Record it so that
@@ -268,11 +270,12 @@ void __init smp_init_cpus(void)
 
 			bootcpu_valid = true;
 
+			if (enable_method)
+				smp_ops[0] = smp_get_ops(enable_method);
+
 			/*
-			 * cpu_logical_map has already been
-			 * initialized and the boot cpu doesn't need
-			 * the enable-method so continue without
-			 * incrementing cpu.
+			 * cpu_logical_map has already been initialized so
+			 * continue without incrementing cpu.
 			 */
 			continue;
 		}
@@ -280,10 +283,6 @@ void __init smp_init_cpus(void)
 		if (cpu >= NR_CPUS)
 			goto next;
 
-		/*
-		 * We currently support only the "spin-table" enable-method.
-		 */
-		enable_method = of_get_property(dn, "enable-method", NULL);
 		if (!enable_method) {
 			pr_err("%s: missing enable-method property\n",
 				dn->full_name);
-- 
1.7.9.5



From mark.rutland at arm.com  Wed Jul 10 18:15:49 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Jul 2013 23:15:49 +0100
Subject: [RFC PATCH 4/5] arm64: add CPU_HOTPLUG infrastructure
In-Reply-To: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
References: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1373494549-24972-1-git-send-email-mark.rutland@arm.com>

This patch adds the basic infrastructure necessary to support
CPU_HOTPLUG on arm64, based on the arm implementation. Actual hotplug
support will depend on an implementation's smp_operations (e.g. PSCI).

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/Kconfig           |    7 +++
 arch/arm64/include/asm/irq.h |    1 +
 arch/arm64/include/asm/smp.h |   10 ++++
 arch/arm64/kernel/cputable.c |    2 +-
 arch/arm64/kernel/irq.c      |   61 +++++++++++++++++++++++
 arch/arm64/kernel/process.c  |    7 +++
 arch/arm64/kernel/smp.c      |  111 ++++++++++++++++++++++++++++++++++++++++++
 7 files changed, 198 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 56b3f6d..3a74435 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -150,6 +150,13 @@ config NR_CPUS
 	depends on SMP
 	default "4"
 
+config HOTPLUG_CPU
+	bool "Support for hot-pluggable CPUs"
+	depends on SMP && HOTPLUG
+	help
+	  Say Y here to experiment with turning CPUs off and on.  CPUs
+	  can be controlled through /sys/devices/system/cpu.
+
 source kernel/Kconfig.preempt
 
 config HZ
diff --git a/arch/arm64/include/asm/irq.h b/arch/arm64/include/asm/irq.h
index 0332fc0..e1f7ecd 100644
--- a/arch/arm64/include/asm/irq.h
+++ b/arch/arm64/include/asm/irq.h
@@ -4,6 +4,7 @@
 #include <asm-generic/irq.h>
 
 extern void (*handle_arch_irq)(struct pt_regs *);
+extern void migrate_irqs(void);
 extern void set_handle_irq(void (*handle_irq)(struct pt_regs *));
 
 #endif
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index af39644..7c55ef4 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -67,6 +67,11 @@ extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
 
 struct device_node;
 
+extern int __cpu_disable(void);
+
+extern void __cpu_die(unsigned int cpu);
+extern void cpu_die(void);
+
 struct smp_operations {
 	const char	*name;
 	/*
@@ -85,6 +90,11 @@ struct smp_operations {
 	 * Performs post-boot cleanup
 	 */
 	void		(*cpu_postboot)(void);
+#ifdef CONFIG_HOTPLUG_CPU
+	int  (*cpu_disable)(unsigned int cpu);
+	void (*cpu_die)(unsigned int cpu);
+	int  (*cpu_kill)(unsigned int cpu);
+#endif
 };
 
 extern const struct smp_operations smp_spin_table_ops;
diff --git a/arch/arm64/kernel/cputable.c b/arch/arm64/kernel/cputable.c
index 63cfc4a..847bfcf 100644
--- a/arch/arm64/kernel/cputable.c
+++ b/arch/arm64/kernel/cputable.c
@@ -22,7 +22,7 @@
 
 extern unsigned long __cpu_setup(void);
 
-struct cpu_info __initdata cpu_table[] = {
+struct cpu_info __cpuinitdata cpu_table[] = {
 	{
 		.cpu_id_val	= 0x000f0000,
 		.cpu_id_mask	= 0x000f0000,
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index ecb3354..473e5db 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -81,3 +81,64 @@ void __init init_IRQ(void)
 	if (!handle_arch_irq)
 		panic("No interrupt controller found.");
 }
+
+#ifdef CONFIG_HOTPLUG_CPU
+static bool migrate_one_irq(struct irq_desc *desc)
+{
+	struct irq_data *d = irq_desc_get_irq_data(desc);
+	const struct cpumask *affinity = d->affinity;
+	struct irq_chip *c;
+	bool ret = false;
+
+	/*
+	 * If this is a per-CPU interrupt, or the affinity does not
+	 * include this CPU, then we have nothing to do.
+	 */
+	if (irqd_is_per_cpu(d) || !cpumask_test_cpu(smp_processor_id(), affinity))
+		return false;
+
+	if (cpumask_any_and(affinity, cpu_online_mask) >= nr_cpu_ids) {
+		affinity = cpu_online_mask;
+		ret = true;
+	}
+
+	c = irq_data_get_irq_chip(d);
+	if (!c->irq_set_affinity)
+		pr_debug("IRQ%u: unable to set affinity\n", d->irq);
+	else if (c->irq_set_affinity(d, affinity, true) == IRQ_SET_MASK_OK && ret)
+		cpumask_copy(d->affinity, affinity);
+
+	return ret;
+}
+
+/*
+ * The current CPU has been marked offline.  Migrate IRQs off this CPU.
+ * If the affinity settings do not allow other CPUs, force them onto any
+ * available CPU.
+ *
+ * Note: we must iterate over all IRQs, whether they have an attached
+ * action structure or not, as we need to get chained interrupts too.
+ */
+void migrate_irqs(void)
+{
+	unsigned int i;
+	struct irq_desc *desc;
+	unsigned long flags;
+
+	local_irq_save(flags);
+
+	for_each_irq_desc(i, desc) {
+		bool affinity_broken;
+
+		raw_spin_lock(&desc->lock);
+		affinity_broken = migrate_one_irq(desc);
+		raw_spin_unlock(&desc->lock);
+
+		if (affinity_broken)
+			pr_warn_ratelimited("IRQ%u no longer affine to CPU%u\n",
+					    i, smp_processor_id());
+	}
+
+	local_irq_restore(flags);
+}
+#endif /* CONFIG_HOTPLUG_CPU */
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 46f02c3..4caf198 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -102,6 +102,13 @@ void arch_cpu_idle(void)
 	local_irq_enable();
 }
 
+#ifdef CONFIG_HOTPLUG_CPU
+void arch_cpu_idle_dead(void)
+{
+       cpu_die();
+}
+#endif
+
 void machine_shutdown(void)
 {
 #ifdef CONFIG_SMP
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 15ec428..07dcb72 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -167,6 +167,117 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
 	cpu_startup_entry(CPUHP_ONLINE);
 }
 
+#ifdef CONFIG_HOTPLUG_CPU
+static int __cpuinit op_cpu_kill(unsigned int cpu)
+{
+	if (smp_ops[cpu]->cpu_kill)
+		return smp_ops[cpu]->cpu_kill(cpu);
+	return 1;
+}
+
+static int __cpuinit op_cpu_disable(unsigned int cpu)
+{
+	/* CPU0 may not have smp_ops */
+	if (!smp_ops[cpu])
+		return -EPERM;
+
+	if (smp_ops[cpu]->cpu_disable)
+		return smp_ops[cpu]->cpu_disable(cpu);
+
+	return 0;
+}
+
+/*
+ * __cpu_disable runs on the processor to be shutdown.
+ */
+int __cpuinit __cpu_disable(void)
+{
+	unsigned int cpu = smp_processor_id();
+	int ret;
+
+	ret = op_cpu_disable(cpu);
+	if (ret)
+		return ret;
+
+	/*
+	 * Take this CPU offline.  Once we clear this, we can't return,
+	 * and we must not schedule until we're ready to give up the cpu.
+	 */
+	set_cpu_online(cpu, false);
+
+	/*
+	 * OK - migrate IRQs away from this CPU
+	 */
+	migrate_irqs();
+
+	/*
+	 * Remove this CPU from the vm mask set of all processes.
+	 */
+	clear_tasks_mm_cpumask(cpu);
+
+	return 0;
+}
+
+static DECLARE_COMPLETION(cpu_died);
+
+/*
+ * called on the thread which is asking for a CPU to be shutdown -
+ * waits until shutdown has completed, or it is timed out.
+ */
+void __cpuinit __cpu_die(unsigned int cpu)
+{
+	if (!wait_for_completion_timeout(&cpu_died, msecs_to_jiffies(5000))) {
+		pr_err("CPU%u: cpu didn't die\n", cpu);
+		return;
+	}
+	pr_notice("CPU%u: shutdown\n", cpu);
+
+	if (!op_cpu_kill(cpu))
+		pr_warn("CPU%u: unable to kill\n", cpu);
+}
+
+/*
+ * Called from the idle thread for the CPU which has been shutdown.
+ *
+ * Note that we disable IRQs here, but do not re-enable them
+ * before returning to the caller. This is also the behaviour
+ * of the other hotplug-cpu capable cores, so presumably coming
+ * out of idle fixes this.
+ */
+void __ref cpu_die(void)
+{
+	unsigned int cpu = smp_processor_id();
+
+	idle_task_exit();
+
+	local_irq_disable();
+	mb();
+
+	/* Tell __cpu_die() that this CPU is now safe to dispose of */
+	RCU_NONIDLE(complete(&cpu_died));
+
+	/*
+	 * actual CPU shutdown procedure is at least platform (if not
+	 * CPU) specific.
+	 */
+	if (smp_ops[cpu]->cpu_die)
+		smp_ops[cpu]->cpu_die(cpu);
+
+	/*
+	 * Do not return to the idle loop - jump back to the secondary
+	 * cpu initialisation.  There's some initialisation which needs
+	 * to be repeated to undo the effects of taking the CPU offline.
+	 */
+	__asm__("mov	sp, %0\n"
+	"	mov	x29, #0\n"
+	"	b	secondary_start_kernel"
+		:
+		: "r" (task_stack_page(current) + THREAD_START_SP));
+}
+#endif
+
+
+
 void __init smp_cpus_done(unsigned int max_cpus)
 {
 	unsigned long bogosum = loops_per_jiffy * num_online_cpus();
-- 
1.7.9.5



From mark.rutland at arm.com  Wed Jul 10 18:16:00 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Jul 2013 23:16:00 +0100
Subject: [RFC PATCH 5/5] arm64: add PSCI CPU_OFF-based hotplug support
In-Reply-To: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
References: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1373494560-25011-1-git-send-email-mark.rutland@arm.com>

This patch adds support for using PSCI CPU_OFF calls for CPU hotplug.
With this code it is possible to hot unplug CPUs with "psci" as their
boot-method, as long as there's an appropriate cpu_off function id
specified in the psci node.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/kernel/smp_psci.c |   30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm64/kernel/smp_psci.c b/arch/arm64/kernel/smp_psci.c
index 24dbad9..d536f3e 100644
--- a/arch/arm64/kernel/smp_psci.c
+++ b/arch/arm64/kernel/smp_psci.c
@@ -47,9 +47,39 @@ static int __cpuinit smp_psci_cpu_boot(unsigned int cpu)
 	return err;
 }
 
+#ifdef CONFIG_HOTPLUG_CPU
+static int __cpuinit smp_psci_cpu_disable(unsigned int cpu)
+{
+	/* Fail early if we don't have CPU_OFF support */
+	if (!psci_ops.cpu_off)
+		return -EOPNOTSUPP;
+	return 0;
+}
+
+static void __cpuinit smp_psci_cpu_die(unsigned int cpu)
+{
+	int ret;
+	/*
+	 * There are no known implementations of PSCI actually using the
+	 * power state field, pass a sensible default for now.
+	 */
+	struct psci_power_state state = {
+		.type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+	};
+
+	ret = psci_ops.cpu_off(state);
+
+	pr_warn("psci: unable to power off CPU%u (%d)", cpu, ret);
+}
+#endif
+
 const struct smp_operations smp_psci_ops __cpuinitconst = {
 	.name		= "psci",
 	.cpu_init	= smp_psci_cpu_init,
 	.cpu_prepare	= smp_psci_cpu_prepare,
 	.cpu_boot	= smp_psci_cpu_boot,
+#ifdef CONFIG_HOTPLUG_CPU
+	.cpu_disable	= smp_psci_cpu_disable,
+	.cpu_die	= smp_psci_cpu_die,
+#endif
 };
-- 
1.7.9.5



From sebastian.hesselbarth at gmail.com  Wed Jul 10 18:59:35 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Thu, 11 Jul 2013 00:59:35 +0200
Subject: [PATCH] net: mv643xx_eth: fix DT port device name
In-Reply-To: <51DD3773.1050408@keymile.com>
References: <1373229231-8838-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130707234341.0000721b@unknown> <20130708000540.00004b37@unknown>
 <51DD3773.1050408@keymile.com>
Message-ID: <51DDE757.2080103@gmail.com>

On 07/10/2013 12:29 PM, Gerlando Falauto wrote:
> Hi Sebastian, Jonas,
>
> first of all thank you for your HUGE efforts in this area.
>
> On 07/08/2013 12:05 AM, Jonas Gorski wrote:
>> On Sun, 7 Jul 2013 23:43:41 +0200
>> Jonas Gorski <jogo at openwrt.org> wrote:
>>
>>> On Sun,  7 Jul 2013 22:33:51 +0200
>>> Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com> wrote:
>>>
>>>> Device tree support added to Marvell MV643xx ethernet driver registers
>>>> port devices from port device nodes found on the corresponding
>>>> controller
>>>> node. The current port device name will cause the second controller to
>>>> fail on registration because of two identical device names. This fixes
>>>> the issue by taking the device node's name also as port device name.
>>>>
>>>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
>>>> Reported-by: Jonas Gorski <jogo at openwrt.org>
>>>> ---
>>>> Cc: Lennert Buytenhek <buytenh at wantstofly.org>
>>>> Cc: Jonas Gorski <jogo at openwrt.org>
>>>> Cc: netdev at vger.kernel.org
>>>> Cc: linux-arm-kernel at lists.infradead.org
>>>> Cc: linux-kernel at vger.kernel.org
>>>> ---
>>>>   drivers/net/ethernet/marvell/mv643xx_eth.c |    2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
>>>> b/drivers/net/ethernet/marvell/mv643xx_eth.c
>>>> index 6495bea..1f3a03d 100644
>>>> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
>>>> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
>>>> @@ -2521,7 +2521,7 @@ static int
>>>> mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
>>>>           of_property_read_u32(pnp, "duplex", &ppd.duplex);
>>>>       }
>>>>
>>>> -    ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
>>>> +    ppdev = platform_device_alloc(pnp->name, ppd.port_number);
>>>>       if (!ppdev)
>>>>           return -ENOMEM;
>>>>       ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>>>
>>> This breaks ethernet completely, as there is no platform driver
>>> registered for pnp->name ("ethernetX-port"), only for MV643XX_ETH_NAME.
>>
>> Looking back at our conversation, this is my fault.
>> I actually did not change this part as you asked, but I saw the
>> alloc/del issue with port 0, then added the counter and also only
>> replaced the ppd.port_number in the alloc with it. I had completely
>> forgotten at that time to replace the device name; else I would
>> have caught it back then.
>>
>> I only caught it now because I tried your patch and wondered why there
>> wasn't anything registered, not because I saw the problem by review.
>>
>
> The way I understand it, you are "manually" creating platform devices
> off the port subnodes (which, incidentally, have a compatible =
> "marvell,kirkwood-eth-port" property), but matching with the driver is
> indeed performed by device name.
> Hence Sebastian's first patch breaks everything and Jonas' latest one
> fixes it. Is that correct? Is there any more work ongoing in this area?
>
> One more question: if my understanding above is correct, what's the
> reason for NOT having an of_device_id[] table, which looks like was
> present in Florian Fainelli's first proposal [1]?

Gerlando,

for the long run, I plan to break with controller/port device
separation. I haven't looked into netdev internals, but I guess
you can have more than one netdev per platform_device.

Using one device per controller will remove some temporal dependencies
of when which driver gets loaded (there will be only one) and also the
root cause of the issue fixed by Jonas.

But it is not on my top priority list, but after fixing MAC address
obliviousness, suspend/resume and initial port setup.

> I'm also willing to help testing your present/future kirkwood patches if
> you like. Please just put me on Cc:

I once put too many people on Cc and that caused ML rejects, but if I
remember it I will keep you posted.

Sebastian



From linux at arm.linux.org.uk  Wed Jul 10 19:51:47 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 11 Jul 2013 00:51:47 +0100
Subject: [PATCH] kexec: return error of machine_kexec() fails
In-Reply-To: <87txk2cfkm.fsf@xmission.com>
References: <1373421296-6112-1-git-send-email-horms@verge.net.au>
 <87obaaiiry.fsf@xmission.com> <51DDB159.2080003@wwwdotorg.org>
 <87txk2cfkm.fsf@xmission.com>
Message-ID: <20130710235147.GZ24642@n2100.arm.linux.org.uk>

On Wed, Jul 10, 2013 at 01:42:17PM -0700, Eric W. Biederman wrote:
> I meant code not hardware architecture.  We keep having code thrown in
> the the shutdown paths because ARM only supports cpu shutdown via cpu
> hotunplug and cpu hotunplug is not universally available.
> 
> That is a software architecture BUG with the ARM kernels.

There are many problems here:

1) if you can't place a CPU individually into reset, what do you do with
it over a kexec?

Once woken it executes code.  It will never stop executing code.  If you
place it inside an infinite loop in the existing kernel, and then
overwrite it, it will then start executing the instructions there when
the new kernel broadcasts the cache flushes, and it will start executing
whatever code is there.

2) if the CPU itself needs to execute code to shut itself down, how do
you get it to do that on a crash-based kexec when IPI broadcasts may not
work?

3) what about situations where you need the requestor to also do something
to shut down the secondary CPU?

Taking CPUs offline is not an easy thing to do when every platform plays
their own games with doing that, and then you have security crap that
gets in the way too, with the security crap having platform specific
interfaces.

CPU hotplug is by far the best solution we have to this mess.


From linux at arm.linux.org.uk  Wed Jul 10 19:59:38 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 11 Jul 2013 00:59:38 +0100
Subject: [RFC PATCH 4/5] arm64: add CPU_HOTPLUG infrastructure
In-Reply-To: <1373494549-24972-1-git-send-email-mark.rutland@arm.com>
References: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
 <1373494549-24972-1-git-send-email-mark.rutland@arm.com>
Message-ID: <20130710235938.GA24642@n2100.arm.linux.org.uk>

On Wed, Jul 10, 2013 at 11:15:49PM +0100, Mark Rutland wrote:
> +	/*
> +	 * actual CPU shutdown procedure is at least platform (if not
> +	 * CPU) specific.
> +	 */
> +	if (smp_ops[cpu]->cpu_die)
> +		smp_ops[cpu]->cpu_die(cpu);
> +
> +	/*
> +	 * Do not return to the idle loop - jump back to the secondary
> +	 * cpu initialisation.  There's some initialisation which needs
> +	 * to be repeated to undo the effects of taking the CPU offline.
> +	 */
> +	__asm__("mov	sp, %0\n"
> +	"	mov	x29, #0\n"
> +	"	b	secondary_start_kernel"
> +		:
> +		: "r" (task_stack_page(current) + THREAD_START_SP));

Don't make that same mistake as on AArch32 - this will result in some
people thinking its acceptable for them to return from cpu_die().  Hot
unplug is supposed to take the CPU offline so it can be restarted as if
it was never booted in the first place.

The above "hack" in AArch32 is only there because of the sillyness of
the 32-bit ARM evaluation boards not having a way to place the
secondary CPUs back into reset or power the secondary CPUs off.


From grundler at chromium.org  Wed Jul 10 20:43:58 2013
From: grundler at chromium.org (Grant Grundler)
Date: Wed, 10 Jul 2013 17:43:58 -0700
Subject: [PATCH 3/5] mmc: dw_mmc: Add exynos resume callback to clear
 WAKEUP_INT
In-Reply-To: <CAD=FV=XLp_2t83JfUBryaSvqLZr5OHEZeFZDRmQ1T=XA1MRkHg@mail.gmail.com>
References: <1373391071-6312-1-git-send-email-dianders@chromium.org>
 <1373391071-6312-4-git-send-email-dianders@chromium.org>
 <CAD=FV=XLp_2t83JfUBryaSvqLZr5OHEZeFZDRmQ1T=XA1MRkHg@mail.gmail.com>
Message-ID: <CANEJEGt4r==VD1gUrTGr=uooFQ-_Odayr3Yv=6i3dwDpf1Y+cg@mail.gmail.com>

On Tue, Jul 9, 2013 at 12:09 PM, Doug Anderson <dianders at chromium.org> wrote:
> Hi,
>
> On Tue, Jul 9, 2013 at 10:31 AM, Doug Anderson <dianders at chromium.org> wrote:
>> If the WAKEUP_INT is asserted at wakeup and not cleared, we'll end up
>> looping around forever.
>>
>> Signed-off-by: Doug Anderson <dianders at chromium.org>
>> ---
>>  drivers/mmc/host/dw_mmc-exynos.c | 23 +++++++++++++++++++++++
>>  1 file changed, 23 insertions(+)
>
> Grant just pointed out that the WAKEUP_INT is supposed to only be
> enabled if bits 8, 9, or 10 are 1.  Our driver never sets those so we
> _should_ never get a WAKEUP_INT.  Bits 8-10 are marked as RESERVED on
> the exynos5420 manual, so the current guess is that they're broken on
> that silicon but that sometimes the interrupt fires anyway.
>
> In any case, it is still a reasonable thing to clear this interrupt at
> wakeup if it has fired, even if we're on an exynos device without any
> problems.

I agree. Can add:
  Reviewed-by: Grant Grundler <grundler at chromium.org>

thanks,
grant

>
> -Doug


From voice.shen at atmel.com  Wed Jul 10 21:17:13 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu, 11 Jul 2013 09:17:13 +0800
Subject: [PATCH 2/3] arm: atmel: at91sam9n12: add qt1070 support
In-Reply-To: <20130710143835.GG18012@ns203013.ovh.net>
References: <1373449869-5083-1-git-send-email-voice.shen@atmel.com>
 <1373449869-5083-3-git-send-email-voice.shen@atmel.com>
 <20130710143835.GG18012@ns203013.ovh.net>
Message-ID: <51DE0799.1090905@atmel.com>

Hi J,

On 7/10/2013 22:38, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 17:51 Wed 10 Jul     , Bo Shen wrote:
>> add qt1070 support on at91sam9n12ek board
>>
>> Signed-off-by: Bo Shen <voice.shen at atmel.com>
>> ---
>>   arch/arm/boot/dts/at91sam9n12ek.dts |   16 ++++++++++++++++
>>   1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts b/arch/arm/boot/dts/at91sam9n12ek.dts
>> index d59b70c..3acac62 100644
>> --- a/arch/arm/boot/dts/at91sam9n12ek.dts
>> +++ b/arch/arm/boot/dts/at91sam9n12ek.dts
>> @@ -40,6 +40,15 @@
>>
>>   			i2c0: i2c at f8010000 {
>>   				status = "okay";
>> +
>> +				qt1070: keyboard at 1b {
>> +					compatible = "qt1070";
>> +					reg = <0x1b>;
>> +					interrupt-parent = <&pioA>;
>> +					interrupts = <2 0x0>;
> use the macro

Thanks, I will use macro here.

>> +					pinctrl-names = "default";
>> +					pinctrl-0 = <&pinctrl_qt1070_irq>;
>> +				};
>>   			};
>>
>>   			i2c1: i2c at f8014000 {
>> @@ -66,6 +75,13 @@
>>   							<AT91_PIOA 7 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;	/* PA7 gpio CD pin pull up and deglitch */
>>   					};
>>   				};
>> +
>> +				qt1070 {
>> +					pinctrl_qt1070_irq: qt1070_irq {
>> +						atmel,pins =
>> +							<AT91_PIOA 2 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PA2 GPIO with pull up deglith */
> drop the comment as we use macro

OK, I will drop the comment

>> +					};
>> +				};
>>   			};
>>
>>   			spi0: spi at f0000000 {
>> --
>
> Best Regards,
> J.
>

Best Regards,
Bo Shen



From voice.shen at atmel.com  Wed Jul 10 21:17:52 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu, 11 Jul 2013 09:17:52 +0800
Subject: [PATCH 1/3] arm: atmel: at91sam9n12: add pinctrl of TWI
In-Reply-To: <20130710143923.GH18012@ns203013.ovh.net>
References: <1373449869-5083-1-git-send-email-voice.shen@atmel.com>
 <1373449869-5083-2-git-send-email-voice.shen@atmel.com>
 <20130710143923.GH18012@ns203013.ovh.net>
Message-ID: <51DE07C0.7060304@atmel.com>

Hi J,

On 7/10/2013 22:39, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 17:51 Wed 10 Jul     , Bo Shen wrote:
>> add pinctrl of TWI for at91sam9n12 SoC
>>
>> Signed-off-by: Bo Shen <voice.shen at atmel.com>
>> ---
>>   arch/arm/boot/dts/at91sam9n12.dtsi |   20 ++++++++++++++++++++
>>   1 file changed, 20 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
>> index bb7f564..3db62f6 100644
>> --- a/arch/arm/boot/dts/at91sam9n12.dtsi
>> +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
>> @@ -291,6 +291,22 @@
>>   					};
>>   				};
>>
>> +				i2c0 {
>> +					pinctrl_i2c0: i2c0-0 {
>> +						atmel,pins =
>> +							<AT91_PIOA 30 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA30 periph A I2C0 data */
>> +							 AT91_PIOA 31 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PA31 periph A I2C0 clock */
>> +					};
>> +				};
>> +
>> +				i2c1 {
>> +					pinctrl_i2c1: i2c1-0 {
>> +						atmel,pins =
>> +							<AT91_PIOC 0 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC0 periph C I2C1 data */
>> +							 AT91_PIOC 1 AT91_PERIPH_C AT91_PINCTRL_NONE>;	/* PC1 periph C I2C1 clock */
> drop  the comment as we use macro

Thanks, I will drop the comment.

>> +					};
>> +				};
>> +
>>   				tcb0 {
>>   					pinctrl_tcb0_tclk0: tcb0_tclk0-0 {
>>   						atmel,pins = <AT91_PIOA 24 AT91_PERIPH_A AT91_PINCTRL_NONE>;
>> @@ -471,6 +487,8 @@
>>   				dma-names = "tx", "rx";
>>   				#address-cells = <1>;
>>   				#size-cells = <0>;
>> +				pinctrl-names = "default";
>> +				pinctrl-0 = <&pinctrl_i2c0>;
>>   				status = "disabled";
>>   			};
>>
>> @@ -483,6 +501,8 @@
>>   				dma-names = "tx", "rx";
>>   				#address-cells = <1>;
>>   				#size-cells = <0>;
>> +				pinctrl-names = "default";
>> +				pinctrl-0 = <&pinctrl_i2c1>;
>>   				status = "disabled";
>>   			};
>>
>> --
>> 1.7.9.5
>>

Best Regards,
Bo Shen



From koba at kmckk.co.jp  Wed Jul 10 21:21:54 2013
From: koba at kmckk.co.jp (Tetsuyuki Kobayashi)
Date: Thu, 11 Jul 2013 10:21:54 +0900
Subject: [PATCH 2/3] ARM: shmobile: Force ARM mode to compile reset vector
 for secondary CPUs
In-Reply-To: <20130710132059.GC13716@verge.net.au>
References: <1373421397-1786-1-git-send-email-koba@kmckk.co.jp>
 <1373421397-1786-3-git-send-email-koba@kmckk.co.jp>
 <20130710132059.GC13716@verge.net.au>
Message-ID: <51DE08B2.6060309@kmckk.co.jp>

Thank you, Simon-san.

I will post the backport patch to next LTSI kernel.

(2013/07/10 22:20), Simon Horman wrote:
> On Wed, Jul 10, 2013 at 10:56:36AM +0900, Tetsuyuki Kobayashi wrote:
>> Instructions start from boot vector must be ARM mode.
>> This patch specify ARM mode explicitly and use 'bx' instruction to be
>> able to change to Thumb mode.
>>
>> Signed-off-by: Tetsuyuki Kobayashi <koba at kmckk.co.jp>
>> ---
>>   arch/arm/mach-shmobile/headsmp.S |    5 ++++-
>>   1 file changed, 4 insertions(+), 1 deletion(-)
>
> Thanks, I have queued this up with Magnus's ack in the thumb-fixes
> branch of my renesas tree on kernel.org. It should be
> included in the renesas-next-20130710v2 tag.
>



From voice.shen at atmel.com  Wed Jul 10 23:30:43 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu, 11 Jul 2013 11:30:43 +0800
Subject: [PATCH v2 0/3] arm: atmel: at91sam9n12: add i2c pinctrl and qt1070
 support
Message-ID: <1373513446-18215-1-git-send-email-voice.shen@atmel.com>

this patch is based on linux master branch, implementation as following:
  - add the i2c pinctrl which needed for using at91sam9n12 TWI
  - enable qt1070
  - trival fix for the gpio-key pin number

Changes in v2:
  - remove comments as use micro
  - using micro for interrupt trigger mode

Bo Shen (3):
  arm: atmel: at91sam9n12: add pinctrl of TWI
  arm: atmel: at91sam9n12: add qt1070 support
  arm: atmel: at91sam9n12: correct pin number of gpio-key

 arch/arm/boot/dts/at91sam9n12.dtsi  |   20 ++++++++++++++++++++
 arch/arm/boot/dts/at91sam9n12ek.dts |   18 +++++++++++++++++-
 2 files changed, 37 insertions(+), 1 deletion(-)

-- 
1.7.9.5



From voice.shen at atmel.com  Wed Jul 10 23:30:46 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu, 11 Jul 2013 11:30:46 +0800
Subject: [PATCH v2 3/3] arm: atmel: at91sam9n12: correct pin number of gpio-key
In-Reply-To: <1373513446-18215-1-git-send-email-voice.shen@atmel.com>
References: <1373513446-18215-1-git-send-email-voice.shen@atmel.com>
Message-ID: <1373513446-18215-4-git-send-email-voice.shen@atmel.com>

correct pin number of gpio-key for at91sam9n12ek board
the pioB4 is connect to LED, the pioB3 use as gpio-key

Signed-off-by: Bo Shen <voice.shen at atmel.com>

---
Changes in v2: None

 arch/arm/boot/dts/at91sam9n12ek.dts |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts b/arch/arm/boot/dts/at91sam9n12ek.dts
index 7a95a28..3e86b05 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -137,7 +137,7 @@
 
 		enter {
 			label = "Enter";
-			gpios = <&pioB 4 GPIO_ACTIVE_LOW>;
+			gpios = <&pioB 3 GPIO_ACTIVE_LOW>;
 			linux,code = <28>;
 			gpio-key,wakeup;
 		};
-- 
1.7.9.5



From voice.shen at atmel.com  Wed Jul 10 23:30:45 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu, 11 Jul 2013 11:30:45 +0800
Subject: [PATCH v2 2/3] arm: atmel: at91sam9n12: add qt1070 support
In-Reply-To: <1373513446-18215-1-git-send-email-voice.shen@atmel.com>
References: <1373513446-18215-1-git-send-email-voice.shen@atmel.com>
Message-ID: <1373513446-18215-3-git-send-email-voice.shen@atmel.com>

add qt1070 support on at91sam9n12ek board

Signed-off-by: Bo Shen <voice.shen at atmel.com>

---
Changes in v2:
  - using micro for interrupt trigger mode

 arch/arm/boot/dts/at91sam9n12ek.dts |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts b/arch/arm/boot/dts/at91sam9n12ek.dts
index d59b70c..7a95a28 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -40,6 +40,15 @@
 
 			i2c0: i2c at f8010000 {
 				status = "okay";
+
+				qt1070: keyboard at 1b {
+					compatible = "qt1070";
+					reg = <0x1b>;
+					interrupt-parent = <&pioA>;
+					interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+					pinctrl-names = "default";
+					pinctrl-0 = <&pinctrl_qt1070_irq>;
+				};
 			};
 
 			i2c1: i2c at f8014000 {
@@ -66,6 +75,13 @@
 							<AT91_PIOA 7 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;	/* PA7 gpio CD pin pull up and deglitch */
 					};
 				};
+
+				qt1070 {
+					pinctrl_qt1070_irq: qt1070_irq {
+						atmel,pins =
+							<AT91_PIOA 2 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
+					};
+				};
 			};
 
 			spi0: spi at f0000000 {
-- 
1.7.9.5



From voice.shen at atmel.com  Wed Jul 10 23:30:44 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu, 11 Jul 2013 11:30:44 +0800
Subject: [PATCH v2 1/3] arm: atmel: at91sam9n12: add pinctrl of TWI
In-Reply-To: <1373513446-18215-1-git-send-email-voice.shen@atmel.com>
References: <1373513446-18215-1-git-send-email-voice.shen@atmel.com>
Message-ID: <1373513446-18215-2-git-send-email-voice.shen@atmel.com>

add pinctrl of TWI for at91sam9n12 SoC

Signed-off-by: Bo Shen <voice.shen at atmel.com>

---
Changes in v2:
  - remove comments as use micro

 arch/arm/boot/dts/at91sam9n12.dtsi |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index bb7f564..9fb7ffd 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -291,6 +291,22 @@
 					};
 				};
 
+				i2c0 {
+					pinctrl_i2c0: i2c0-0 {
+						atmel,pins =
+							<AT91_PIOA 30 AT91_PERIPH_A AT91_PINCTRL_NONE
+							 AT91_PIOA 31 AT91_PERIPH_A AT91_PINCTRL_NONE>;
+					};
+				};
+
+				i2c1 {
+					pinctrl_i2c1: i2c1-0 {
+						atmel,pins =
+							<AT91_PIOC 0 AT91_PERIPH_C AT91_PINCTRL_NONE
+							 AT91_PIOC 1 AT91_PERIPH_C AT91_PINCTRL_NONE>;
+					};
+				};
+
 				tcb0 {
 					pinctrl_tcb0_tclk0: tcb0_tclk0-0 {
 						atmel,pins = <AT91_PIOA 24 AT91_PERIPH_A AT91_PINCTRL_NONE>;
@@ -471,6 +487,8 @@
 				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_i2c0>;
 				status = "disabled";
 			};
 
@@ -483,6 +501,8 @@
 				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_i2c1>;
 				status = "disabled";
 			};
 
-- 
1.7.9.5



From kyungsik.lee at lge.com  Thu Jul 11 00:34:33 2013
From: kyungsik.lee at lge.com (Kyungsik Lee)
Date: Thu, 11 Jul 2013 13:34:33 +0900
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130710182815.GA362@x4>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130506095124.GA22041@pd.tnic>
 <CAMuHMdWH9w5fj6HRXi+9QcBJym4dukAFsPVGZVqSSk3yTZJUcA@mail.gmail.com>
 <20130710093642.GC14873@pd.tnic> <20130710182815.GA362@x4>
Message-ID: <20130711043433.GA29245@hulk>

> 
> BTW speaking of introductory-level patches, what about the following
> one:
> 
> Now that lz4 kernel compression is available, add *.lz4 to .gitignore
> 
> diff --git a/.gitignore b/.gitignore
> index 3b8b9b3..7e9932e 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -29,6 +29,7 @@ modules.builtin
>  *.bz2
>  *.lzma
>  *.xz
> +*.lz4
>  *.lzo
>  *.patch
>  *.gcno
> 
Acked-by: Kyungsik Lee <kyungsik.lee at lge.com>

Thanks,
Kyungsik



From tony at atomide.com  Thu Jul 11 02:17:58 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Jul 2013 23:17:58 -0700
Subject: [RFC] ARM: OMAP2+: omap_device: add pinctrl handling
In-Reply-To: <CACRpkdYU13bhPaL2ZG9CT9JRv9sKQ+1N3zCUPizk571+LQqB4A@mail.gmail.com>
References: <1371826990-25820-1-git-send-email-grygorii.strashko@ti.com>
 <CACRpkdY=m1b9Lh27+wHP8FQ4SbVZKmAOCGhxe59aP+TcuR9QaA@mail.gmail.com>
 <20130625065811.GZ5523@atomide.com> <51CAEA90.90200@ti.com>
 <CACRpkdbKgEcfF67oO9HrczvDp4Po3Xt1hFajJ1vO8kEvsZH4jA@mail.gmail.com>
 <51CC45D3.2000305@ti.com>
 <CACRpkdYU13bhPaL2ZG9CT9JRv9sKQ+1N3zCUPizk571+LQqB4A@mail.gmail.com>
Message-ID: <20130711061757.GX5523@atomide.com>

* Linus Walleij <linus.walleij at linaro.org> [130710 13:42]:
> On Thu, Jun 27, 2013 at 4:01 PM, Grygorii Strashko
> <grygorii.strashko at ti.com> wrote:
> 
> > I think, In the future the OMAP pinctrl configurations would be manged in
> > more flexible way then now (thanks to "pinctrl PM helpers" and you;))
> > - "Idle" state will be splitted to "Idle"/"sleep"
> > - "default" state will be splitted to "default"/"active"
> 
> OK so the first ones we already have so the discussion is now down
> to adding the "active" state (and pinctrl_pm* helper function).

I think I have a patchset ready for pinctrl to allow multiple simulaneous
states as discussed, need to test it first though. Should be able to
post it on Friday hopefully.
 
> I guess we need a patch set prepared which adds the "active" state
> and helper function as the first patch, i.e. this:
> http://marc.info/?l=linux-kernel&m=137094012703340&w=2
> Can I have your ACK on this patch?

Hmm I have gone a bit further with the drivers/base/pinctrl.c in my
set where if active state is defined then sleep and idle states must
match active state for the pingroups to avoid constantly checking
those sets during runtime.

Then the pinctrl_pm_select_active_state() does not actually have
anything to do with PM in the rx/tx case, so we should rename that.

It's pretty close, but before we can apply that we need the changes
I have to allow multiple simultaneous states. I suggest wait just
few days on that patch.
 
> I do not want to add the state unless there is a clear consumer,
> so it needs to go in with the first patch to a device driver that uses
> pinctrl_pm_select_active_state() which will be a good demonstration
> on its use and utility. (And a point to object and suggest other ways
> to do the same thing...)

Right, we have quite a few consumers with omaps for that as am33xx
requires remuxing wake-up events for all drivers AFAIK. The MMC SDIO
pin remuxing is probably closest one ready.

Regards,

Tony


From rnayak at ti.com  Thu Jul 11 02:18:39 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Thu, 11 Jul 2013 11:48:39 +0530
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130710142633.GV5523@atomide.com>
References: <B5906170F1614E41A8A28DE3B8D121433EE93C23@DBDE04.ent.ti.com>
 <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <87mwpuakod.fsf@linaro.org>
 <20130710142633.GV5523@atomide.com>
Message-ID: <51DE4E3F.6030503@ti.com>

On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
> * Kevin Hilman <khilman at linaro.org> [130710 01:29]:
>> Felipe Balbi <balbi at ti.com> writes:
>>>>
>>>> Right, but calling serial_omap_restore_context() even when the context
>>>> is not lost, should not ideally cause an issue.
>>>
>>> it does in one condition. If context hasn't been saved before. And that
>>> can happen in the case of wrong pm runtime status for that device.
>>>
>>> Imagine the device is marked as suspended even though it's fully enabled
>>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
>>> your context structure is all zeroes (context has never been saved
>>> before) then when you call pm_runtime_get_sync() on probe() your
>>> ->runtime_resume() will get called, which will restore context,
>>> essentially undoing anything which was configured by u-boot.
>>>
>>> Am I missing something ?
>>
>> You're right, the _set_active() is crucial in the case when we prevent
>> the console UART from idling during boot (though that shouldn't be
>> happening in mainline unless the fix for "Issue 1" is done.)
> 
> Felipe is right, looks like all we need is to check if context is
> initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
> 
> After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
> works for me.

On what platform? Like I said there are flags set statically in hmwod
data for OMAP4 and OMAP5, which make it work without any hwmod tinkering
in mach-omap2/serial.c. But it won't work for am33xx.

 We could also check for some combination of the context
> save registers being NULL if somebody has a good idea which ones
> should never be 0.
> 
> Regards,
> 
> Tony
> 
> 
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -161,6 +161,7 @@ struct uart_omap_port {
>  	u32			calc_latency;
>  	struct work_struct	qos_work;
>  	struct pinctrl		*pins;
> +	bool			initialized;
>  	bool			is_suspending;
>  };
>  
> @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
>  
>  	pm_runtime_mark_last_busy(up->dev);
>  	pm_runtime_put_autosuspend(up->dev);
> +	up->initialized = true;

This won't help as the context save for serial happens as part of set_termios() and not
when the device is probed.

> +
>  	return 0;
>  
>  err_add_port:
> @@ -1584,6 +1587,9 @@ static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
>  #ifdef CONFIG_PM_RUNTIME
>  static void serial_omap_restore_context(struct uart_omap_port *up)
>  {
> +	if (!up->initialized)
> +		return;
> +
>  	if (up->errata & UART_ERRATA_i202_MDR1_ACCESS)
>  		serial_omap_mdr1_errataset(up, UART_OMAP_MDR1_DISABLE);
>  	else
> 



From tony at atomide.com  Thu Jul 11 02:24:41 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Jul 2013 23:24:41 -0700
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51DE4E3F.6030503@ti.com>
References: <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi>
 <87mwpuakod.fsf@linaro.org> <20130710142633.GV5523@atomide.com>
 <51DE4E3F.6030503@ti.com>
Message-ID: <20130711062440.GY5523@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130710 23:25]:
> On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
> > 
> > Felipe is right, looks like all we need is to check if context is
> > initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
> > 
> > After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
> > works for me.
> 
> On what platform? Like I said there are flags set statically in hmwod
> data for OMAP4 and OMAP5, which make it work without any hwmod tinkering
> in mach-omap2/serial.c. But it won't work for am33xx.

For me omap4 sdp hangs during ttyO2 probe if earlyprintk is enabled for
that port and console is enabled for that port. That's because we attempt
to restore uninitialized context.

It's possible that we have more than one bug here though.
 
> > @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
> >  
> >  	pm_runtime_mark_last_busy(up->dev);
> >  	pm_runtime_put_autosuspend(up->dev);
> > +	up->initialized = true;
> 
> This won't help as the context save for serial happens as part of set_termios() and not
> when the device is probed.

The issue is that in serial probe we currently restore NULL context to
the port which kills earlyprintk output until set_termios() is called.

But as discussed, there are better ways for fixing this issue.

Regards,

Tony


From peter.chen at freescale.com  Thu Jul 11 02:27:08 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:27:08 +0800
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
Message-ID: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>

This patchset adds tested otg id switch function and
vbus connect and disconnect detection for chipidea driver.
And fix kinds of bugs found at chipidea drivers after enabling
id and vbus detection.

This patch is fully tested at imx6 sabresd platform.
My chipidea repo: https://github.com/hzpeterchen/linux-usb.git

Changes for v12:
- Rebased greg's usb-next tree (3.10.0-rc7+)
- Split more small patches for single function and fix.

Changes for v11:
- mark ci_handle_vbus_change as static as it is only used at core.c
[3/9]
- Move the vbus operation for platform code to host code, as vbus
operation is common operation, and host is the only user for vbus.
When it is host mode, we need to open vbus, when it is out of host
mode, we need to close vbus. [6/9] [8/9]
- Delete the delayed work at core.c as it is not needed. [7/9]

Changes for v10:
- Delete [8/9] at v9, ci core's drvdata must be set for further operation.
[8/8]

Changes for v9:
- Some small comments from Alex like: variable comment for otg event
additional newline. [3/9]
- Import function tell show if the controller has otg capable, if
the controller supports both host and device, we think it is otg
capable, and can read OTGSC. [3/9]
- Merge two otg patches [v8 3/8] and [v8 4/8] to one [v9 3/9]. [3/9]
- Add inline to ci_hdrc_gadget_destroy if CONFIG_USB_CHIPIDEA_UDC
is not defined, it can fix one build warning "defined but not used"
[3/9]
- One comment from Felipe about changing calling gadget disconnect
API at chipidea's udc driver. I move calling ci->driver->disconnect
from _gadget_stop_activity to which calls _gadget_stop_activity except
ci13xxx_stop, as udc core will call disconnect when do rmmod gadget. [7/9]
- Add ci core probe's return value to ci's platform_data, we do this
for getting core's probe's result at platform layer, and quit it
if the core's probe fails. [8/9] [9/9]

Changes for v8:
- Add ci_supports_gadget helper to know if the controller
supports gadget, if the controller supports gadget, it
needs to read otgsc to know the vbus value, basically,
if the controller supports gadget, it will support host
as well [3/8]
- At ci_hdrc_probe, it needs to add free memory at error path
[3/8]
- Cosolidate ci->driver = NULL at ci13xxx_stop
[8/8]

Changes for v7:
For Patch 8/8, we only need to set ci->driver to NULL when usb cable
is not connected, for other changes, it will case some runtime pm
unmatch and un-align with udc-core & composite driver problems.

Changes for v6:
- Add Alex comments for init/destroy function [3/8] [4/8]
- Remove memset(&ci->gadget, 0, sizeof(ci->gadget)) at destory function [4/8]
- Add Kishon's comment: Change the format of struct usb_otg otg at drivers/usb/chipidea/ci.h
[1/8]
- Add comments for CI_VBUS_STABLE_TIMEOUT [3/8]
- Change the otg_set_peripheral return value check as the fully
chipidea driver users don't need it. [4/8]
- Fix one bug that the oops when re-plug in usb cable after
rmmod gadget [8/8]

Peter Chen (13):
  usb: chipidea: add vbus regulator control
  usb: chipidea: imx: remove vbus regulator operation
  usb: chipidea: udc: otg_set_peripheral is useless for some chipidea
    users
  usb: chipidea: otg: Add otg file used to access otgsc
  usb: chipidea: Add role init and destory APIs
  usb: chipidea: add otg_cap attribute for otg capable
  usb: chipidea: disable all interrupts and clear all interrupts status
  usb: chipidea: move otg relate things to otg file
  usb: chipidea: add vbus interrupt handler
  usb: chipidea: add wait vbus lower than OTGSC_BSV before role starts
  usb: chipidea: udc: misuse flag CI_HDRC_REGS_SHARED and
    CI_HDRC_PULLUP_ON_VBUS
  usb: chipidea: udc: .pullup is valid when vbus is on at
    CI_HDRC_PULLUP_ON_VBUS
  usb: chipidea: udc: fix the oops when plugs in usb cable after rmmod
    gadget

 drivers/usb/chipidea/Makefile      |    2 +-
 drivers/usb/chipidea/bits.h        |   10 +++
 drivers/usb/chipidea/ci.h          |    8 ++
 drivers/usb/chipidea/ci_hdrc_imx.c |   30 ++-----
 drivers/usb/chipidea/core.c        |  158 +++++++++++++++++++++++------------
 drivers/usb/chipidea/host.c        |   30 +++++++-
 drivers/usb/chipidea/host.h        |    6 ++
 drivers/usb/chipidea/otg.c         |  135 ++++++++++++++++++++++++++++++
 drivers/usb/chipidea/otg.h         |   22 +++++
 drivers/usb/chipidea/udc.c         |   72 +++++++++++++----
 drivers/usb/chipidea/udc.h         |    6 ++
 include/linux/usb/chipidea.h       |   14 +++
 12 files changed, 397 insertions(+), 96 deletions(-)
 create mode 100644 drivers/usb/chipidea/otg.c
 create mode 100644 drivers/usb/chipidea/otg.h




From peter.chen at freescale.com  Thu Jul 11 02:27:09 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:27:09 +0800
Subject: [PATCH v12 01/13] usb: chipidea: add vbus regulator control
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1373524041-10482-2-git-send-email-peter.chen@freescale.com>

For boards which have board level vbus control (eg, through gpio), we
need to vbus operation according to below rules:
- For host, we need open vbus before start hcd, and close it
after remove hcd.
- For otg, the vbus needs to be on/off when usb role switches.
When the host roles begins, it opens vbus; when the host role
finishes, it closes vbus.

We put vbus operation to host as host is the only vbus user,
When we are at host mode, the vbus is on, when we are not at
host mode, vbus should be off.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/host.c  |   23 ++++++++++++++++++++++-
 include/linux/usb/chipidea.h |    1 +
 2 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 40d0fda..e94e52b 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -24,6 +24,7 @@
 #include <linux/usb.h>
 #include <linux/usb/hcd.h>
 #include <linux/usb/chipidea.h>
+#include <linux/regulator/consumer.h>
 
 #include "../host/ehci.h"
 
@@ -64,9 +65,19 @@ static int host_start(struct ci_hdrc *ci)
 	ehci->caps = ci->hw_bank.cap;
 	ehci->has_hostpc = ci->hw_bank.lpm;
 
+	if (ci->platdata->reg_vbus) {
+		ret = regulator_enable(ci->platdata->reg_vbus);
+		if (ret) {
+			dev_err(ci->dev,
+				"Failed to enable vbus regulator, ret=%d\n",
+				ret);
+			goto put_hcd;
+		}
+	}
+
 	ret = usb_add_hcd(hcd, 0, 0);
 	if (ret)
-		usb_put_hcd(hcd);
+		goto disable_reg;
 	else
 		ci->hcd = hcd;
 
@@ -74,6 +85,14 @@ static int host_start(struct ci_hdrc *ci)
 		hw_write(ci, OP_USBMODE, USBMODE_CI_SDIS, USBMODE_CI_SDIS);
 
 	return ret;
+
+disable_reg:
+	regulator_disable(ci->platdata->reg_vbus);
+
+put_hcd:
+	usb_put_hcd(hcd);
+
+	return ret;
 }
 
 static void host_stop(struct ci_hdrc *ci)
@@ -82,6 +101,8 @@ static void host_stop(struct ci_hdrc *ci)
 
 	usb_remove_hcd(hcd);
 	usb_put_hcd(hcd);
+	if (ci->platdata->reg_vbus)
+		regulator_disable(ci->platdata->reg_vbus);
 }
 
 int ci_hdrc_host_init(struct ci_hdrc *ci)
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 2562994..118bf66 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -24,6 +24,7 @@ struct ci_hdrc_platform_data {
 #define CI_HDRC_CONTROLLER_RESET_EVENT		0
 #define CI_HDRC_CONTROLLER_STOPPED_EVENT	1
 	void	(*notify_event) (struct ci_hdrc *ci, unsigned event);
+	struct regulator *reg_vbus;
 };
 
 /* Default offset of capability registers */
-- 
1.7.0.4




From peter.chen at freescale.com  Thu Jul 11 02:27:10 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:27:10 +0800
Subject: [PATCH v12 02/13] usb: chipidea: imx: remove vbus regulator operation
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1373524041-10482-3-git-send-email-peter.chen@freescale.com>

Since we have added vbus reguatlor operation at common
host file (chipidea/host.c), the glue layer vbus operation
isn't needed any more.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/ci_hdrc_imx.c |   30 +++++++-----------------------
 1 files changed, 7 insertions(+), 23 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index 14362c0..d06355e 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -31,7 +31,6 @@ struct ci_hdrc_imx_data {
 	struct usb_phy *phy;
 	struct platform_device *ci_pdev;
 	struct clk *clk;
-	struct regulator *reg_vbus;
 };
 
 static const struct usbmisc_ops *usbmisc_ops;
@@ -141,22 +140,13 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 		goto err_clk;
 	}
 
-	/* we only support host now, so enable vbus here */
-	data->reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
-	if (!IS_ERR(data->reg_vbus)) {
-		ret = regulator_enable(data->reg_vbus);
-		if (ret) {
-			dev_err(&pdev->dev,
-				"Failed to enable vbus regulator, err=%d\n",
-				ret);
-			goto err_clk;
-		}
-	} else {
-		data->reg_vbus = NULL;
-	}
-
 	pdata.phy = data->phy;
 
+	/* Get the vbus regulator */
+	pdata.reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
+	if (IS_ERR(pdata.reg_vbus))
+		pdata.reg_vbus = NULL;
+
 	if (!pdev->dev.dma_mask)
 		pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
 	if (!pdev->dev.coherent_dma_mask)
@@ -167,7 +157,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 		if (ret) {
 			dev_err(&pdev->dev,
 				"usbmisc init failed, ret=%d\n", ret);
-			goto err;
+			goto err_clk;
 		}
 	}
 
@@ -179,7 +169,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev,
 			"Can't register ci_hdrc platform device, err=%d\n",
 			ret);
-		goto err;
+		goto err_clk;
 	}
 
 	if (usbmisc_ops && usbmisc_ops->post) {
@@ -200,9 +190,6 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 
 disable_device:
 	ci_hdrc_remove_device(data->ci_pdev);
-err:
-	if (data->reg_vbus)
-		regulator_disable(data->reg_vbus);
 err_clk:
 	clk_disable_unprepare(data->clk);
 	return ret;
@@ -215,9 +202,6 @@ static int ci_hdrc_imx_remove(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	ci_hdrc_remove_device(data->ci_pdev);
 
-	if (data->reg_vbus)
-		regulator_disable(data->reg_vbus);
-
 	if (data->phy) {
 		usb_phy_shutdown(data->phy);
 		module_put(data->phy->dev->driver->owner);
-- 
1.7.0.4




From peter.chen at freescale.com  Thu Jul 11 02:27:11 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:27:11 +0800
Subject: [PATCH v12 03/13] usb: chipidea: udc: otg_set_peripheral is useless
 for some chipidea users
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1373524041-10482-4-git-send-email-peter.chen@freescale.com>

It is useless at below cases:
- If we implement both usb host and device at chipidea driver.
- If we don't need phy->otg.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/udc.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index e475fcd..116c762 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1805,7 +1805,12 @@ static int udc_start(struct ci_hdrc *ci)
 	if (ci->transceiver) {
 		retval = otg_set_peripheral(ci->transceiver->otg,
 						&ci->gadget);
-		if (retval)
+		/*
+		 * If we implement all USB functions using chipidea drivers,
+		 * it doesn't need to call above API, meanwhile, if we only
+		 * use gadget function, calling above API is useless.
+		 */
+		if (retval && retval != -ENOTSUPP)
 			goto put_transceiver;
 	}
 
-- 
1.7.0.4




From peter.chen at freescale.com  Thu Jul 11 02:27:12 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:27:12 +0800
Subject: [PATCH v12 04/13] usb: chipidea: otg: Add otg file used to access
 otgsc
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1373524041-10482-5-git-send-email-peter.chen@freescale.com>

This file is mainly used to access otgsc currently, it may
add otg related things in the future.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/Makefile |    2 +-
 drivers/usb/chipidea/bits.h   |   10 ++++++++
 drivers/usb/chipidea/core.c   |    3 +-
 drivers/usb/chipidea/otg.c    |   50 +++++++++++++++++++++++++++++++++++++++++
 drivers/usb/chipidea/otg.h    |   19 +++++++++++++++
 5 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 3bbbcba..9d0e288 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -2,7 +2,7 @@ ccflags-$(CONFIG_USB_CHIPIDEA_DEBUG) := -DDEBUG
 
 obj-$(CONFIG_USB_CHIPIDEA)		+= ci_hdrc.o
 
-ci_hdrc-y				:= core.o
+ci_hdrc-y				:= core.o otg.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC)	+= udc.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST)	+= host.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_DEBUG)	+= debug.o
diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index aefa026..dd0cf9e 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -79,11 +79,21 @@
 #define OTGSC_ASVIS	      BIT(18)
 #define OTGSC_BSVIS	      BIT(19)
 #define OTGSC_BSEIS	      BIT(20)
+#define OTGSC_1MSIS	      BIT(21)
+#define OTGSC_DPIS	      BIT(22)
 #define OTGSC_IDIE	      BIT(24)
 #define OTGSC_AVVIE	      BIT(25)
 #define OTGSC_ASVIE	      BIT(26)
 #define OTGSC_BSVIE	      BIT(27)
 #define OTGSC_BSEIE	      BIT(28)
+#define OTGSC_1MSIE	      BIT(29)
+#define OTGSC_DPIE	      BIT(30)
+#define OTGSC_INT_EN_BITS	(OTGSC_IDIE | OTGSC_AVVIE | OTGSC_ASVIE \
+				| OTGSC_BSVIE | OTGSC_BSEIE | OTGSC_1MSIE \
+				| OTGSC_DPIE)
+#define OTGSC_INT_STATUS_BITS	(OTGSC_IDIS | OTGSC_AVVIS | OTGSC_ASVIS	\
+				| OTGSC_BSVIS | OTGSC_BSEIS | OTGSC_1MSIS \
+				| OTGSC_DPIS)
 
 /* USBMODE */
 #define USBMODE_CM            (0x03UL <<  0)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index a5df24c..761f7e8 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -71,6 +71,7 @@
 #include "bits.h"
 #include "host.h"
 #include "debug.h"
+#include "otg.h"
 
 /* Controller register map */
 static uintptr_t ci_regs_nolpm[] = {
@@ -508,7 +509,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 		goto stop;
 
 	if (ci->is_otg)
-		hw_write(ci, OP_OTGSC, OTGSC_IDIE, OTGSC_IDIE);
+		ci_hdrc_otg_init(ci);
 
 	ret = dbg_create_files(ci);
 	if (!ret)
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
new file mode 100644
index 0000000..abefb4d
--- /dev/null
+++ b/drivers/usb/chipidea/otg.c
@@ -0,0 +1,50 @@
+/*
+ * otg.c - ChipIdea USB IP core OTG driver
+ *
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Peter Chen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * This file mainly handles otgsc register, it may include OTG operation
+ * in the future.
+ */
+
+#include <linux/usb/otg.h>
+#include <linux/usb/gadget.h>
+#include <linux/usb/chipidea.h>
+
+#include "ci.h"
+#include "bits.h"
+
+void ci_clear_otg_interrupt(struct ci_hdrc *ci, u32 bits)
+{
+	/* Only clear request bits */
+	hw_write(ci, OP_OTGSC, OTGSC_INT_STATUS_BITS, bits);
+}
+
+void ci_enable_otg_interrupt(struct ci_hdrc *ci, u32 bits)
+{
+	hw_write(ci, OP_OTGSC, bits, bits);
+}
+
+void ci_disable_otg_interrupt(struct ci_hdrc *ci, u32 bits)
+{
+	hw_write(ci, OP_OTGSC, bits, 0);
+}
+
+/**
+ * ci_hdrc_otg_init - initialize otgsc bits
+ * ci: the controller
+ */
+int ci_hdrc_otg_init(struct ci_hdrc *ci)
+{
+	ci_enable_otg_interrupt(ci, OTGSC_IDIE);
+
+	return 0;
+}
diff --git a/drivers/usb/chipidea/otg.h b/drivers/usb/chipidea/otg.h
new file mode 100644
index 0000000..f24ec37
--- /dev/null
+++ b/drivers/usb/chipidea/otg.h
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Peter Chen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __DRIVERS_USB_CHIPIDEA_OTG_H
+#define __DRIVERS_USB_CHIPIDEA_OTG_H
+
+int ci_hdrc_otg_init(struct ci_hdrc *ci);
+void ci_clear_otg_interrupt(struct ci_hdrc *ci, u32 bits);
+void ci_enable_otg_interrupt(struct ci_hdrc *ci, u32 bits);
+void ci_disable_otg_interrupt(struct ci_hdrc *ci, u32 bits);
+
+#endif /* __DRIVERS_USB_CHIPIDEA_OTG_H */
-- 
1.7.0.4




From peter.chen at freescale.com  Thu Jul 11 02:27:14 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:27:14 +0800
Subject: [PATCH v12 06/13] usb: chipidea: add otg_cap attribute for otg capable
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1373524041-10482-7-git-send-email-peter.chen@freescale.com>

Since we need otgsc to know vbus's status at some chipidea
controllers even it is peripheral-only mode. Besides, some
SoCs (eg, AR9331 SoC) don't have otgsc register even
the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS.
We inroduce otg_cap attribute to indicate if the controller
is otg capable, defaultly, we follow the rule that if DCCPARAMS_DC
and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS are otg capable, but if there
is exception, the platform can override it by device tree or platform data.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/core.c  |   35 ++++++++++++++++++++++++++++-------
 include/linux/usb/chipidea.h |   13 +++++++++++++
 2 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 93961ff..e8ceb04 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -405,6 +405,18 @@ static inline void ci_role_destroy(struct ci_hdrc *ci)
 	ci_hdrc_host_destroy(ci);
 }
 
+static void ci_get_otg_capable(struct ci_hdrc *ci)
+{
+	if (ci->platdata->otg_cap != OTG_CAP_ATTR_IS_NOT_EXISTED)
+		ci->is_otg = (ci->platdata->otg_cap == OTG_CAP_ATTR_IS_TRUE);
+	else
+		ci->is_otg = (hw_read(ci, CAP_DCCPARAMS,
+				DCCPARAMS_DC | DCCPARAMS_HC)
+					== (DCCPARAMS_DC | DCCPARAMS_HC));
+	if (ci->is_otg)
+		dev_dbg(ci->dev, "It is OTG capable controller\n");
+}
+
 static int ci_hdrc_probe(struct platform_device *pdev)
 {
 	struct device	*dev = &pdev->dev;
@@ -461,6 +473,9 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
+	/* To know if controller is OTG capable or not */
+	ci_get_otg_capable(ci);
+
 	if (!ci->platdata->phy_mode)
 		ci->platdata->phy_mode = of_usb_get_phy_mode(dev->of_node);
 
@@ -491,10 +506,19 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 	}
 
 	if (ci->roles[CI_ROLE_HOST] && ci->roles[CI_ROLE_GADGET]) {
-		ci->is_otg = true;
-		/* ID pin needs 1ms debouce time, we delay 2ms for safe */
-		mdelay(2);
-		ci->role = ci_otg_role(ci);
+		if (ci->is_otg) {
+			/* ID pin needs 1ms debouce time, we delay 2ms for safe */
+			mdelay(2);
+			ci->role = ci_otg_role(ci);
+			ci_hdrc_otg_init(ci);
+		} else {
+			/*
+			 * If the controller is not OTG capable, but support
+			 * role switch, the defalt role is gadget, and the
+			 * user can switch it through debugfs (proc in future?)
+			 */
+			ci->role = CI_ROLE_GADGET;
+		}
 	} else {
 		ci->role = ci->roles[CI_ROLE_HOST]
 			? CI_ROLE_HOST
@@ -514,9 +538,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 	if (ret)
 		goto stop;
 
-	if (ci->is_otg)
-		ci_hdrc_otg_init(ci);
-
 	ret = dbg_create_files(ci);
 	if (!ret)
 		return 0;
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 118bf66..0a906b4 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -7,6 +7,12 @@
 
 #include <linux/usb/otg.h>
 
+enum usb_otg_cap {
+	OTG_CAP_ATTR_IS_NOT_EXISTED = 0,
+	OTG_CAP_ATTR_IS_TRUE,
+	OTG_CAP_ATTR_IS_FALSE,
+};
+
 struct ci_hdrc;
 struct ci_hdrc_platform_data {
 	const char	*name;
@@ -25,6 +31,13 @@ struct ci_hdrc_platform_data {
 #define CI_HDRC_CONTROLLER_STOPPED_EVENT	1
 	void	(*notify_event) (struct ci_hdrc *ci, unsigned event);
 	struct regulator *reg_vbus;
+	/*
+	 * Please only set otg_cap when the otg capability can't be
+	 * judged by CAP_DCCPARAMS, eg, the DCCPARAMS_DC and DCCPARAMS_HC
+	 * are both 1 at CAP_DCCPARAMS, but the controller doesn't have
+	 * OTGSC register (eg, AR9331 SoC).
+	 */
+	enum usb_otg_cap otg_cap;
 };
 
 /* Default offset of capability registers */
-- 
1.7.0.4




From peter.chen at freescale.com  Thu Jul 11 02:27:15 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:27:15 +0800
Subject: [PATCH v12 07/13] usb: chipidea: disable all interrupts and clear all
 interrupts status
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1373524041-10482-8-git-send-email-peter.chen@freescale.com>

During the initialization, it needs to disable all interrupts
enable bit as well as clear all interrupts status bits to avoid
exceptional interrupt.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/core.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index e8ceb04..f701e3b 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -198,6 +198,12 @@ static int hw_device_init(struct ci_hdrc *ci, void __iomem *base)
 	if (ci->hw_ep_max > ENDPT_MAX)
 		return -ENODEV;
 
+	/* Disable all interrupts bits */
+	hw_write(ci, OP_USBINTR, 0xffffffff, 0);
+
+	/* Clear all interrupts status bits*/
+	hw_write(ci, OP_USBSTS, 0xffffffff, 0xffffffff);
+
 	dev_dbg(ci->dev, "ChipIdea HDRC found, lpm: %d; cap: %p op: %p\n",
 		ci->hw_bank.lpm, ci->hw_bank.cap, ci->hw_bank.op);
 
@@ -413,8 +419,11 @@ static void ci_get_otg_capable(struct ci_hdrc *ci)
 		ci->is_otg = (hw_read(ci, CAP_DCCPARAMS,
 				DCCPARAMS_DC | DCCPARAMS_HC)
 					== (DCCPARAMS_DC | DCCPARAMS_HC));
-	if (ci->is_otg)
+	if (ci->is_otg) {
 		dev_dbg(ci->dev, "It is OTG capable controller\n");
+		ci_disable_otg_interrupt(ci, OTGSC_INT_EN_BITS);
+		ci_clear_otg_interrupt(ci, OTGSC_INT_STATUS_BITS);
+	}
 }
 
 static int ci_hdrc_probe(struct platform_device *pdev)
-- 
1.7.0.4




From peter.chen at freescale.com  Thu Jul 11 02:27:18 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:27:18 +0800
Subject: [PATCH v12 10/13] usb: chipidea: add wait vbus lower than OTGSC_BSV
 before role starts
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1373524041-10482-11-git-send-email-peter.chen@freescale.com>

When the gadget role starts, we need to make sure the vbus is lower
than OTGSC_BSV, or there will be an vbus interrupt since we use
B_SESSION_VALID as vbus interrupt to indicate connect and disconnect.
When the host role starts, it may not be useful to wait vbus to lower
than OTGSC_BSV, but it can indicate some hardware problems like the
vbus is still higher than OTGSC_BSV after we disconnect to host some
time later (500 jiffies currently), which is obvious not correct.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/ci.h   |    3 +++
 drivers/usb/chipidea/core.c |   32 ++++++++++++++++++++++++++++++++
 drivers/usb/chipidea/otg.c  |    4 ++++
 3 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 3160363..df27696 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -308,4 +308,7 @@ int hw_port_test_set(struct ci_hdrc *ci, u8 mode);
 
 u8 hw_port_test_get(struct ci_hdrc *ci);
 
+int hw_wait_reg(struct ci_hdrc *ci, enum ci_hw_regs reg, u32 mask,
+				u32 value, unsigned long timeout);
+
 #endif	/* __DRIVERS_USB_CHIPIDEA_CI_H */
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 7a07300..1c39541 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -295,6 +295,38 @@ int hw_device_reset(struct ci_hdrc *ci, u32 mode)
 	return 0;
 }
 
+/**
+ * hw_wait_reg: wait the register value
+ *
+ * Sometimes, it needs to wait register value before going on.
+ * Eg, when switch to device mode, the vbus value should be lower
+ * than OTGSC_BSV before connects to host.
+ *
+ * @ci: the controller
+ * @reg: register index
+ * @mask: mast bit
+ * @value: the bit value to wait
+ * @timeout: timeout to indicate an error
+ *
+ * This function returns an error code if timeout
+ */
+int hw_wait_reg(struct ci_hdrc *ci, enum ci_hw_regs reg, u32 mask,
+				u32 value, unsigned long timeout)
+{
+	unsigned long elapse = jiffies + timeout;
+
+	while (hw_read(ci, reg, mask) != value) {
+		if (time_after(jiffies, elapse)) {
+			dev_err(ci->dev, "timeout waiting for %08x in %d\n",
+					mask, reg);
+			return -ETIMEDOUT;
+		}
+		msleep(20);
+	}
+
+	return 0;
+}
+
 static irqreturn_t ci_irq(int irq, void *data)
 {
 	struct ci_hdrc *ci = data;
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index c74194d..8aa0241 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -67,6 +67,7 @@ void ci_handle_vbus_change(struct ci_hdrc *ci)
 		usb_gadget_vbus_disconnect(&ci->gadget);
 }
 
+#define CI_VBUS_STABLE_TIMEOUT 500
 static void ci_handle_id_switch(struct ci_hdrc *ci)
 {
 	enum ci_role role = ci_otg_role(ci);
@@ -76,6 +77,9 @@ static void ci_handle_id_switch(struct ci_hdrc *ci)
 			ci_role(ci)->name, ci->roles[role]->name);
 
 		ci_role_stop(ci);
+		/* wait vbus lower than OTGSC_BSV */
+		hw_wait_reg(ci, OP_OTGSC, OTGSC_BSV, 0,
+				CI_VBUS_STABLE_TIMEOUT);
 		ci_role_start(ci, role);
 	}
 }
-- 
1.7.0.4




From peter.chen at freescale.com  Thu Jul 11 02:27:13 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:27:13 +0800
Subject: [PATCH v12 05/13] usb: chipidea: Add role init and destory APIs
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1373524041-10482-6-git-send-email-peter.chen@freescale.com>

- The role's init will be called at probe procedure.
- The role's destory will be called at fail patch
at probe and driver's removal.
- The role's start/stop will be called when specific
role has started.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/core.c |   10 ++++++++--
 drivers/usb/chipidea/host.c |    7 +++++++
 drivers/usb/chipidea/host.h |    6 ++++++
 drivers/usb/chipidea/udc.c  |   36 +++++++++++++++++++++++++++---------
 drivers/usb/chipidea/udc.h  |    6 ++++++
 5 files changed, 54 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 761f7e8..93961ff 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -399,6 +399,12 @@ void ci_hdrc_remove_device(struct platform_device *pdev)
 }
 EXPORT_SYMBOL_GPL(ci_hdrc_remove_device);
 
+static inline void ci_role_destroy(struct ci_hdrc *ci)
+{
+	ci_hdrc_gadget_destroy(ci);
+	ci_hdrc_host_destroy(ci);
+}
+
 static int ci_hdrc_probe(struct platform_device *pdev)
 {
 	struct device	*dev = &pdev->dev;
@@ -517,7 +523,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 
 	free_irq(ci->irq, ci);
 stop:
-	ci_role_stop(ci);
+	ci_role_destroy(ci);
 rm_wq:
 	flush_workqueue(ci->wq);
 	destroy_workqueue(ci->wq);
@@ -533,7 +539,7 @@ static int ci_hdrc_remove(struct platform_device *pdev)
 	flush_workqueue(ci->wq);
 	destroy_workqueue(ci->wq);
 	free_irq(ci->irq, ci);
-	ci_role_stop(ci);
+	ci_role_destroy(ci);
 
 	return 0;
 }
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index e94e52b..382be5b 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -105,6 +105,13 @@ static void host_stop(struct ci_hdrc *ci)
 		regulator_disable(ci->platdata->reg_vbus);
 }
 
+
+void ci_hdrc_host_destroy(struct ci_hdrc *ci)
+{
+	if (ci->role == CI_ROLE_HOST)
+		host_stop(ci);
+}
+
 int ci_hdrc_host_init(struct ci_hdrc *ci)
 {
 	struct ci_role_driver *rdrv;
diff --git a/drivers/usb/chipidea/host.h b/drivers/usb/chipidea/host.h
index 058875c..5707bf3 100644
--- a/drivers/usb/chipidea/host.h
+++ b/drivers/usb/chipidea/host.h
@@ -4,6 +4,7 @@
 #ifdef CONFIG_USB_CHIPIDEA_HOST
 
 int ci_hdrc_host_init(struct ci_hdrc *ci);
+void ci_hdrc_host_destroy(struct ci_hdrc *ci);
 
 #else
 
@@ -12,6 +13,11 @@ static inline int ci_hdrc_host_init(struct ci_hdrc *ci)
 	return -ENXIO;
 }
 
+static inline void ci_hdrc_host_destroy(struct ci_hdrc *ci)
+{
+
+}
+
 #endif
 
 #endif /* __DRIVERS_USB_CHIPIDEA_HOST_H */
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 116c762..24a100d 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -27,6 +27,7 @@
 #include "udc.h"
 #include "bits.h"
 #include "debug.h"
+#include "otg.h"
 
 /* control endpoint description */
 static const struct usb_endpoint_descriptor
@@ -1844,13 +1845,13 @@ free_qh_pool:
 }
 
 /**
- * udc_remove: parent remove must call this to remove UDC
+ * ci_hdrc_gadget_destroy: parent remove must call this to remove UDC
  *
  * No interrupts active, the IRQ has been released
  */
-static void udc_stop(struct ci_hdrc *ci)
+void ci_hdrc_gadget_destroy(struct ci_hdrc *ci)
 {
-	if (ci == NULL)
+	if (!ci->roles[CI_ROLE_GADGET])
 		return;
 
 	usb_del_gadget_udc(&ci->gadget);
@@ -1865,15 +1866,32 @@ static void udc_stop(struct ci_hdrc *ci)
 		if (ci->global_phy)
 			usb_put_phy(ci->transceiver);
 	}
-	/* my kobject is dynamic, I swear! */
-	memset(&ci->gadget, 0, sizeof(ci->gadget));
+}
+
+static int udc_id_switch_for_device(struct ci_hdrc *ci)
+{
+	if (ci->is_otg) {
+		ci_clear_otg_interrupt(ci, OTGSC_BSVIS);
+		ci_enable_otg_interrupt(ci, OTGSC_BSVIE);
+	}
+
+	return 0;
+}
+
+static void udc_id_switch_for_host(struct ci_hdrc *ci)
+{
+	if (ci->is_otg) {
+		/* host doesn't care B_SESSION_VALID event */
+		ci_clear_otg_interrupt(ci, OTGSC_BSVIS);
+		ci_disable_otg_interrupt(ci, OTGSC_BSVIE);
+	}
 }
 
 /**
  * ci_hdrc_gadget_init - initialize device related bits
  * ci: the controller
  *
- * This function enables the gadget role, if the device is "device capable".
+ * This function initializes the gadget, if the device is "device capable".
  */
 int ci_hdrc_gadget_init(struct ci_hdrc *ci)
 {
@@ -1886,11 +1904,11 @@ int ci_hdrc_gadget_init(struct ci_hdrc *ci)
 	if (!rdrv)
 		return -ENOMEM;
 
-	rdrv->start	= udc_start;
-	rdrv->stop	= udc_stop;
+	rdrv->start	= udc_id_switch_for_device;
+	rdrv->stop	= udc_id_switch_for_host;
 	rdrv->irq	= udc_irq;
 	rdrv->name	= "gadget";
 	ci->roles[CI_ROLE_GADGET] = rdrv;
 
-	return 0;
+	return udc_start(ci);
 }
diff --git a/drivers/usb/chipidea/udc.h b/drivers/usb/chipidea/udc.h
index 455ac21..e66df00 100644
--- a/drivers/usb/chipidea/udc.h
+++ b/drivers/usb/chipidea/udc.h
@@ -84,6 +84,7 @@ struct ci_hw_req {
 #ifdef CONFIG_USB_CHIPIDEA_UDC
 
 int ci_hdrc_gadget_init(struct ci_hdrc *ci);
+void ci_hdrc_gadget_destroy(struct ci_hdrc *ci);
 
 #else
 
@@ -92,6 +93,11 @@ static inline int ci_hdrc_gadget_init(struct ci_hdrc *ci)
 	return -ENXIO;
 }
 
+static inline void ci_hdrc_gadget_destroy(struct ci_hdrc *ci)
+{
+
+}
+
 #endif
 
 #endif /* __DRIVERS_USB_CHIPIDEA_UDC_H */
-- 
1.7.0.4




From peter.chen at freescale.com  Thu Jul 11 02:27:20 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:27:20 +0800
Subject: [PATCH v12 12/13] usb: chipidea: udc: .pullup is valid when vbus is
 on at CI_HDRC_PULLUP_ON_VBUS
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1373524041-10482-13-git-send-email-peter.chen@freescale.com>

When the flag CI_HDRC_PULLUP_ON_VBUS is set, .pullup should only be
called when the vbus is active. When the CI_HDRC_PULLUP_ON_VBUS
is set, the controller only begins to run when the vbus is on,
So, it is only meaningful software set pullup/pulldown after
the controller begins to run.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/udc.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 45abf4d..b7ead5f 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1514,6 +1514,10 @@ static int ci_udc_pullup(struct usb_gadget *_gadget, int is_on)
 {
 	struct ci_hdrc *ci = container_of(_gadget, struct ci_hdrc, gadget);
 
+	if ((ci->platdata->flags & CI_HDRC_PULLUP_ON_VBUS)
+			&& !ci->vbus_active)
+		return -EOPNOTSUPP;
+
 	if (is_on)
 		hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
 	else
-- 
1.7.0.4




From peter.chen at freescale.com  Thu Jul 11 02:27:17 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:27:17 +0800
Subject: [PATCH v12 09/13] usb: chipidea: add vbus interrupt handler
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1373524041-10482-10-git-send-email-peter.chen@freescale.com>

We add vbus interrupt handler at ci_otg_work, it uses OTGSC_BSV(at otgsc)
to know it is connect or disconnet event.
Meanwhile, we introduce two flags id_event and b_sess_valid_event to
indicate it is an id interrupt or a vbus interrupt.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/ci.h   |    5 +++++
 drivers/usb/chipidea/core.c |   28 +++++++++++++++++++++++-----
 drivers/usb/chipidea/otg.c  |   42 +++++++++++++++++++++++++++++++++++-------
 drivers/usb/chipidea/otg.h  |    1 +
 drivers/usb/chipidea/udc.c  |    7 +++++++
 5 files changed, 71 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 33cb29f..3160363 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -132,6 +132,9 @@ struct hw_bank {
  * @transceiver: pointer to USB PHY, if any
  * @hcd: pointer to usb_hcd for ehci host driver
  * @debugfs: root dentry for this controller in debugfs
+ * @id_event: indicates there is an id event, and handled at ci_otg_work
+ * @b_sess_valid_event: indicates there is a vbus event, and handled
+ * at ci_otg_work
  */
 struct ci_hdrc {
 	struct device			*dev;
@@ -168,6 +171,8 @@ struct ci_hdrc {
 	struct usb_phy			*transceiver;
 	struct usb_hcd			*hcd;
 	struct dentry			*debugfs;
+	bool				id_event;
+	bool				b_sess_valid_event;
 };
 
 static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 0197da2..7a07300 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -304,16 +304,34 @@ static irqreturn_t ci_irq(int irq, void *data)
 	if (ci->is_otg)
 		otgsc = hw_read(ci, OP_OTGSC, ~0);
 
-	if (ci->role != CI_ROLE_END)
-		ret = ci_role(ci)->irq(ci);
+	/*
+	 * Handle id change interrupt, it indicates device/host function
+	 * switch.
+	 */
+	if (ci->is_otg && (otgsc & OTGSC_IDIE) && (otgsc & OTGSC_IDIS)) {
+		ci->id_event = true;
+		ci_clear_otg_interrupt(ci, OTGSC_IDIS);
+		disable_irq_nosync(ci->irq);
+		queue_work(ci->wq, &ci->work);
+		return IRQ_HANDLED;
+	}
 
-	if (ci->is_otg && (otgsc & OTGSC_IDIS)) {
-		hw_write(ci, OP_OTGSC, OTGSC_IDIS, OTGSC_IDIS);
+	/*
+	 * Handle vbus change interrupt, it indicates device connection
+	 * and disconnection events.
+	 */
+	if (ci->is_otg && (otgsc & OTGSC_BSVIE) && (otgsc & OTGSC_BSVIS)) {
+		ci->b_sess_valid_event = true;
+		ci_clear_otg_interrupt(ci, OTGSC_BSVIS);
 		disable_irq_nosync(ci->irq);
 		queue_work(ci->wq, &ci->work);
-		ret = IRQ_HANDLED;
+		return IRQ_HANDLED;
 	}
 
+	/* Handle device/host interrupt */
+	if (ci->role != CI_ROLE_END)
+		ret = ci_role(ci)->irq(ci);
+
 	return ret;
 }
 
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index 68f2faf..c74194d 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -52,13 +52,23 @@ enum ci_role ci_otg_role(struct ci_hdrc *ci)
 	return role;
 }
 
-/**
- * ci_role_work - perform role changing based on ID pin
- * @work: work struct
- */
-static void ci_role_work(struct work_struct *work)
+void ci_handle_vbus_change(struct ci_hdrc *ci)
+{
+	u32 otgsc;
+
+	if (!ci->is_otg)
+		return;
+
+	otgsc = hw_read(ci, OP_OTGSC, ~0);
+
+	if (otgsc & OTGSC_BSV)
+		usb_gadget_vbus_connect(&ci->gadget);
+	else
+		usb_gadget_vbus_disconnect(&ci->gadget);
+}
+
+static void ci_handle_id_switch(struct ci_hdrc *ci)
 {
-	struct ci_hdrc *ci = container_of(work, struct ci_hdrc, work);
 	enum ci_role role = ci_otg_role(ci);
 
 	if (role != ci->role) {
@@ -68,17 +78,35 @@ static void ci_role_work(struct work_struct *work)
 		ci_role_stop(ci);
 		ci_role_start(ci, role);
 	}
+}
+/**
+ * ci_otg_work - perform otg (vbus/id) event handle
+ * @work: work struct
+ */
+static void ci_otg_work(struct work_struct *work)
+{
+	struct ci_hdrc *ci = container_of(work, struct ci_hdrc, work);
+
+	if (ci->id_event) {
+		ci->id_event = false;
+		ci_handle_id_switch(ci);
+	} else if (ci->b_sess_valid_event) {
+		ci->b_sess_valid_event = false;
+		ci_handle_vbus_change(ci);
+	} else
+		dev_err(ci->dev, "unexpected event occurs at %s\n", __func__);
 
 	enable_irq(ci->irq);
 }
 
+
 /**
  * ci_hdrc_otg_init - initialize otg struct
  * ci: the controller
  */
 int ci_hdrc_otg_init(struct ci_hdrc *ci)
 {
-	INIT_WORK(&ci->work, ci_role_work);
+	INIT_WORK(&ci->work, ci_otg_work);
 	ci->wq = create_singlethread_workqueue("ci_otg");
 	if (!ci->wq) {
 		dev_err(ci->dev, "can't create workqueue\n");
diff --git a/drivers/usb/chipidea/otg.h b/drivers/usb/chipidea/otg.h
index 8913062..b8d5c05 100644
--- a/drivers/usb/chipidea/otg.h
+++ b/drivers/usb/chipidea/otg.h
@@ -17,5 +17,6 @@ void ci_enable_otg_interrupt(struct ci_hdrc *ci, u32 bits);
 void ci_disable_otg_interrupt(struct ci_hdrc *ci, u32 bits);
 void ci_hdrc_otg_destory(struct ci_hdrc *ci);
 enum ci_role ci_otg_role(struct ci_hdrc *ci);
+void ci_handle_vbus_change(struct ci_hdrc *ci);
 
 #endif /* __DRIVERS_USB_CHIPIDEA_OTG_H */
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 24a100d..c70ce38 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -85,8 +85,10 @@ static int hw_device_state(struct ci_hdrc *ci, u32 dma)
 		/* interrupt, error, port change, reset, sleep/suspend */
 		hw_write(ci, OP_USBINTR, ~0,
 			     USBi_UI|USBi_UEI|USBi_PCI|USBi_URI|USBi_SLI);
+		hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
 	} else {
 		hw_write(ci, OP_USBINTR, ~0, 0);
+		hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
 	}
 	return 0;
 }
@@ -1460,6 +1462,7 @@ static int ci_udc_vbus_session(struct usb_gadget *_gadget, int is_active)
 			pm_runtime_get_sync(&_gadget->dev);
 			hw_device_reset(ci, USBMODE_CM_DC);
 			hw_device_state(ci, ci->ep0out->qh.dma);
+			dev_dbg(ci->dev, "Connected to host\n");
 		} else {
 			hw_device_state(ci, 0);
 			if (ci->platdata->notify_event)
@@ -1467,6 +1470,7 @@ static int ci_udc_vbus_session(struct usb_gadget *_gadget, int is_active)
 				CI_HDRC_CONTROLLER_STOPPED_EVENT);
 			_gadget_stop_activity(&ci->gadget);
 			pm_runtime_put_sync(&_gadget->dev);
+			dev_dbg(ci->dev, "Disconnected from host\n");
 		}
 	}
 
@@ -1822,6 +1826,9 @@ static int udc_start(struct ci_hdrc *ci)
 	pm_runtime_no_callbacks(&ci->gadget.dev);
 	pm_runtime_enable(&ci->gadget.dev);
 
+	/* Update ci->vbus_active */
+	ci_handle_vbus_change(ci);
+
 	return retval;
 
 remove_trans:
-- 
1.7.0.4




From m.weisser.m at gmail.com  Thu Jul 11 02:28:38 2013
From: m.weisser.m at gmail.com (=?UTF-8?Q?Matthias_Wei=C3=9Fer?=)
Date: Thu, 11 Jul 2013 08:28:38 +0200
Subject: imx25: How to get frame buffer device in a system using device
 tree
In-Reply-To: <CAOMZO5CrZjDZjqaaQTX4=ZGO_6chFMr9qAHhqyVGBdxBvimYSw@mail.gmail.com>
References: <CAO8h3eFq9WhvZYbbeFfWgVEXViR8MAcGaztsvvaLpFSW-W6CfA@mail.gmail.com>
 <CAOMZO5Aat-iAN_TJ6BXEopB+WCkKgLjWh67sCXg0jd1DtzmKSQ@mail.gmail.com>
 <CAO8h3eHAfV808izZzvpPc+z6iQPr14q8OmryNs5sC+VcNk+iLg@mail.gmail.com>
 <CAOMZO5CgAs+hR41=WdJ=jxS5gZf=opOrCXufixBh_CMP0n2TFA@mail.gmail.com>
 <CAO8h3eGhF8DRO73W9GkepUKAF-6v1EmWdMS_Gq+dA_2v5mJ2aQ@mail.gmail.com>
 <CAOMZO5CrZjDZjqaaQTX4=ZGO_6chFMr9qAHhqyVGBdxBvimYSw@mail.gmail.com>
Message-ID: <CAO8h3eHiXroFWy2na-05MeHgfSg9LGuxMF4wkf4VwFsV57xDnw@mail.gmail.com>

Hi Fabio

2013/7/10 Fabio Estevam <festevam at gmail.com>:
> Hi Matthias,
>
> On Mon, Jul 8, 2013 at 3:31 AM, Matthias Wei?er <m.weisser.m at gmail.com> wrote:
>> Hi Fabio
>>
>> 2013/7/5 Fabio Estevam <festevam at gmail.com>:
>>> Hi Matthias,
>>>
>>> On Fri, Jul 5, 2013 at 4:37 AM, Matthias Wei?er <m.weisser.m at gmail.com> wrote:
>>>
>>>> Thanks for the links. That made some things clearer for me. But I am
>>>> still a bit confused about the driver (imxfb.c) itself. From what I
>>>> can see it is not dt aware as there is no of_device_id structure with
>>>> the compatible entries. I think I have to add dt support to the
>>>> framebuffer driver. Am I right?
>>>
>>> Yes, you need to apply this one:
>>> http://marc.info/?l=linux-fbdev&m=136956466617736&w=2
>>
>> OK. Done that and it works like a charm. Thanks a lot.
>
> Great, care to submit patches for adding mx25 fb support?

I can. But I think the only thing is the slightly changed
arch/arm/boot/dts/imx25.dtsi. Patch to this mailing list? Patch
against mainline kernel is OK?

Regards
Matthias


From peter.chen at freescale.com  Thu Jul 11 02:27:16 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:27:16 +0800
Subject: [PATCH v12 08/13] usb: chipidea: move otg relate things to otg file
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1373524041-10482-9-git-send-email-peter.chen@freescale.com>

Move otg relate things to otg file.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/core.c |   63 +++++++++----------------------------------
 drivers/usb/chipidea/otg.c  |   57 +++++++++++++++++++++++++++++++++++++-
 drivers/usb/chipidea/otg.h  |    2 +
 3 files changed, 70 insertions(+), 52 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index f701e3b..0197da2 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -295,40 +295,6 @@ int hw_device_reset(struct ci_hdrc *ci, u32 mode)
 	return 0;
 }
 
-/**
- * ci_otg_role - pick role based on ID pin state
- * @ci: the controller
- */
-static enum ci_role ci_otg_role(struct ci_hdrc *ci)
-{
-	u32 sts = hw_read(ci, OP_OTGSC, ~0);
-	enum ci_role role = sts & OTGSC_ID
-		? CI_ROLE_GADGET
-		: CI_ROLE_HOST;
-
-	return role;
-}
-
-/**
- * ci_role_work - perform role changing based on ID pin
- * @work: work struct
- */
-static void ci_role_work(struct work_struct *work)
-{
-	struct ci_hdrc *ci = container_of(work, struct ci_hdrc, work);
-	enum ci_role role = ci_otg_role(ci);
-
-	if (role != ci->role) {
-		dev_dbg(ci->dev, "switching from %s to %s\n",
-			ci_role(ci)->name, ci->roles[role]->name);
-
-		ci_role_stop(ci);
-		ci_role_start(ci, role);
-	}
-
-	enable_irq(ci->irq);
-}
-
 static irqreturn_t ci_irq(int irq, void *data)
 {
 	struct ci_hdrc *ci = data;
@@ -409,6 +375,8 @@ static inline void ci_role_destroy(struct ci_hdrc *ci)
 {
 	ci_hdrc_gadget_destroy(ci);
 	ci_hdrc_host_destroy(ci);
+	if (ci->is_otg)
+		ci_hdrc_otg_destory(ci);
 }
 
 static void ci_get_otg_capable(struct ci_hdrc *ci)
@@ -475,13 +443,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	INIT_WORK(&ci->work, ci_role_work);
-	ci->wq = create_singlethread_workqueue("ci_otg");
-	if (!ci->wq) {
-		dev_err(dev, "can't create workqueue\n");
-		return -ENODEV;
-	}
-
 	/* To know if controller is OTG capable or not */
 	ci_get_otg_capable(ci);
 
@@ -510,8 +471,15 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 
 	if (!ci->roles[CI_ROLE_HOST] && !ci->roles[CI_ROLE_GADGET]) {
 		dev_err(dev, "no supported roles\n");
-		ret = -ENODEV;
-		goto rm_wq;
+		return -ENODEV;
+	}
+
+	if (ci->is_otg) {
+		ret = ci_hdrc_otg_init(ci);
+		if (ret) {
+			dev_err(dev, "init otg fails, ret = %d\n", ret);
+			goto stop;
+		}
 	}
 
 	if (ci->roles[CI_ROLE_HOST] && ci->roles[CI_ROLE_GADGET]) {
@@ -519,7 +487,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 			/* ID pin needs 1ms debouce time, we delay 2ms for safe */
 			mdelay(2);
 			ci->role = ci_otg_role(ci);
-			ci_hdrc_otg_init(ci);
+			ci_enable_otg_interrupt(ci, OTGSC_IDIE);
 		} else {
 			/*
 			 * If the controller is not OTG capable, but support
@@ -538,7 +506,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 	if (ret) {
 		dev_err(dev, "can't start %s role\n", ci_role(ci)->name);
 		ret = -ENODEV;
-		goto rm_wq;
+		goto stop;
 	}
 
 	platform_set_drvdata(pdev, ci);
@@ -554,9 +522,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 	free_irq(ci->irq, ci);
 stop:
 	ci_role_destroy(ci);
-rm_wq:
-	flush_workqueue(ci->wq);
-	destroy_workqueue(ci->wq);
 
 	return ret;
 }
@@ -566,8 +531,6 @@ static int ci_hdrc_remove(struct platform_device *pdev)
 	struct ci_hdrc *ci = platform_get_drvdata(pdev);
 
 	dbg_remove_files(ci);
-	flush_workqueue(ci->wq);
-	destroy_workqueue(ci->wq);
 	free_irq(ci->irq, ci);
 	ci_role_destroy(ci);
 
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index abefb4d..68f2faf 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -39,12 +39,65 @@ void ci_disable_otg_interrupt(struct ci_hdrc *ci, u32 bits)
 }
 
 /**
- * ci_hdrc_otg_init - initialize otgsc bits
+ * ci_otg_role - pick role based on ID pin state
+ * @ci: the controller
+ */
+enum ci_role ci_otg_role(struct ci_hdrc *ci)
+{
+	u32 sts = hw_read(ci, OP_OTGSC, ~0);
+	enum ci_role role = sts & OTGSC_ID
+		? CI_ROLE_GADGET
+		: CI_ROLE_HOST;
+
+	return role;
+}
+
+/**
+ * ci_role_work - perform role changing based on ID pin
+ * @work: work struct
+ */
+static void ci_role_work(struct work_struct *work)
+{
+	struct ci_hdrc *ci = container_of(work, struct ci_hdrc, work);
+	enum ci_role role = ci_otg_role(ci);
+
+	if (role != ci->role) {
+		dev_dbg(ci->dev, "switching from %s to %s\n",
+			ci_role(ci)->name, ci->roles[role]->name);
+
+		ci_role_stop(ci);
+		ci_role_start(ci, role);
+	}
+
+	enable_irq(ci->irq);
+}
+
+/**
+ * ci_hdrc_otg_init - initialize otg struct
  * ci: the controller
  */
 int ci_hdrc_otg_init(struct ci_hdrc *ci)
 {
-	ci_enable_otg_interrupt(ci, OTGSC_IDIE);
+	INIT_WORK(&ci->work, ci_role_work);
+	ci->wq = create_singlethread_workqueue("ci_otg");
+	if (!ci->wq) {
+		dev_err(ci->dev, "can't create workqueue\n");
+		return -ENODEV;
+	}
 
 	return 0;
 }
+
+/**
+ * ci_hdrc_otg_destroy - destory otg struct
+ * ci: the controller
+ */
+void ci_hdrc_otg_destory(struct ci_hdrc *ci)
+{
+	if (ci->wq) {
+		flush_workqueue(ci->wq);
+		destroy_workqueue(ci->wq);
+	}
+	ci_disable_otg_interrupt(ci, OTGSC_INT_EN_BITS);
+	ci_clear_otg_interrupt(ci, OTGSC_INT_STATUS_BITS);
+}
diff --git a/drivers/usb/chipidea/otg.h b/drivers/usb/chipidea/otg.h
index f24ec37..8913062 100644
--- a/drivers/usb/chipidea/otg.h
+++ b/drivers/usb/chipidea/otg.h
@@ -15,5 +15,7 @@ int ci_hdrc_otg_init(struct ci_hdrc *ci);
 void ci_clear_otg_interrupt(struct ci_hdrc *ci, u32 bits);
 void ci_enable_otg_interrupt(struct ci_hdrc *ci, u32 bits);
 void ci_disable_otg_interrupt(struct ci_hdrc *ci, u32 bits);
+void ci_hdrc_otg_destory(struct ci_hdrc *ci);
+enum ci_role ci_otg_role(struct ci_hdrc *ci);
 
 #endif /* __DRIVERS_USB_CHIPIDEA_OTG_H */
-- 
1.7.0.4




From peter.chen at freescale.com  Thu Jul 11 02:27:19 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:27:19 +0800
Subject: [PATCH v12 11/13] usb: chipidea: udc: misuse flag CI_HDRC_REGS_SHARED
 and CI_HDRC_PULLUP_ON_VBUS
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1373524041-10482-12-git-send-email-peter.chen@freescale.com>

CI_HDRC_REGS_SHARED stands for the controller registers is shared
with other USB drivers, if all USB drivers are at chipidea/, it doesn't
needed to set.
CI_HDRC_PULLUP_ON_VBUS stands for pullup dp when the vbus is on. This
flag doesn't need to set if the vbus is always on for gadget
since dp has always pulled up after the gadget has initialized.

So, the current code seems to misuse this two flags.
- When the gadget initializes, the controller doesn't need to run if
it depends on vbus (CI_HDRC_PULLUP_ON_VBUS), it does not
relate to shared register.
- When the gadget starts (load one gadget module), the controller
can run if vbus is on (CI_HDRC_PULLUP_ON_VBUS), it also does not
relate to shared register.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/udc.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index c70ce38..45abf4d 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1637,8 +1637,7 @@ static int ci_udc_start(struct usb_gadget *gadget,
 	pm_runtime_get_sync(&ci->gadget.dev);
 	if (ci->platdata->flags & CI_HDRC_PULLUP_ON_VBUS) {
 		if (ci->vbus_active) {
-			if (ci->platdata->flags & CI_HDRC_REGS_SHARED)
-				hw_device_reset(ci, USBMODE_CM_DC);
+			hw_device_reset(ci, USBMODE_CM_DC);
 		} else {
 			pm_runtime_put_sync(&ci->gadget.dev);
 			goto done;
@@ -1801,7 +1800,7 @@ static int udc_start(struct ci_hdrc *ci)
 		}
 	}
 
-	if (!(ci->platdata->flags & CI_HDRC_REGS_SHARED)) {
+	if (!(ci->platdata->flags & CI_HDRC_PULLUP_ON_VBUS)) {
 		retval = hw_device_reset(ci, USBMODE_CM_DC);
 		if (retval)
 			goto put_transceiver;
-- 
1.7.0.4




From peter.chen at freescale.com  Thu Jul 11 02:27:21 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:27:21 +0800
Subject: [PATCH v12 13/13] usb: chipidea: udc: fix the oops when plugs in usb
 cable after rmmod gadget
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1373524041-10482-14-git-send-email-peter.chen@freescale.com>

When we rmmod gadget, the ci->driver needs to be cleared.
Otherwise, we plug in usb cable again, the driver will
consider gadget is there, in fact, it was removed.

Besides, consolidate the calling of ci->driver->disconnect, when
we do rmmod gadget, the gadget's disconnect should be called from
udc core.

Below is the oops this patch fixes.

root at freescale ~$ ci_hdrc ci_hdrc.0: Connected to host
Unable to handle kernel paging request at virtual address 7f01171c
pgd = 80004000
[7f01171c] *pgd=4fa1e811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] SMP ARM
Modules linked in: f_acm libcomposite u_serial [last unloaded: g_serial]
CPU: 0    Not tainted  (3.8.0-rc5+ #221)
PC is at _gadget_stop_activity+0xbc/0x128
LR is at ep_fifo_flush+0x68/0xa0
pc : [<803634cc>]    lr : [<80363938>]    psr: 20000193
sp : 806c7dc8  ip : 00000000  fp : 806c7de4
r10: 00000000  r9 : 80710ea4  r8 : 00000000
r7 : bf834094  r6 : bf834098  r5 : bf834010  r4 : bf8340a0
r3 : 7f011708  r2 : 01940194  r1 : a0000193  r0 : bf834014
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 4f06404a  DAC: 00000017
Process swapper/0 (pid: 0, stack limit = 0x806c6238)
Stack: (0x806c7dc8 to 0x806c8000)
7dc0:                   bf834010 bf809950 bf834010 0000004b 806c7e44 806c7de8
7de0: 80365400 8036341c 0000ec1c 00000000 0000ec1c 00000040 fff5ede0 bf834014
7e00: 000a1220 00000000 0000002e ffffd958 806c7e3c 806c7e20 8004e870 bf834010
7e20: bf809950 0000004b 0000004b 00000000 80710ea4 00000000 806c7e5c 806c7e48
7e40: 80362888 80365154 bfb35180 bf809950 806c7e9c 806c7e60 8008111c 803627f4
7e60: 00989680 00000000 bf809900 bf809964 812df8c0 bf809900 bf809950 806c3f2c
7e80: 0000004b 00000000 412fc09a 00000000 806c7eb4 806c7ea0 80081368 800810b8
7ea0: bf809900 bf809950 806c7ecc 806c7eb8 800843c8 8008130c 0000004b 806cf748
7ec0: 806c7ee4 806c7ed0 80081088 8008432c 806c6000 806cf748 806c7f0c 806c7ee8
7ee0: 8000fa44 8008105c f400010c 806ce974 806c7f30 f4000110 806d29e8 412fc09a
7f00: 806c7f2c 806c7f10 80008584 8000f9f4 8000fbd0 60000013 ffffffff 806c7f64
7f20: 806c7f84 806c7f30 8000eac0 80008554 00000000 00000000 0000000f 8001aea0
7f40: 806c6000 80712a48 804f0040 00000000 806d29e8 412fc09a 00000000 806c7f84
7f60: 806c7f88 806c7f78 8000fbcc 8000fbd0 60000013 ffffffff 806c7fac 806c7f88
7f80: 8001015c 8000fb9c 806cf5b0 80712980 806a4528 8fffffff 1000406a 412fc09a
7fa0: 806c7fbc 806c7fb0 804e5334 800100ac 806c7ff4 806c7fc0 80668940 804e52d4
7fc0: ffffffff ffffffff 806684bc 00000000 00000000 806a4528 10c53c7d 806ce94c
7fe0: 806a4524 806d29dc 00000000 806c7ff8 10008078 806686b0 00000000 00000000
Backtrace:
[<80363410>] (_gadget_stop_activity+0x0/0x128) from [<80365400>] (udc_irq+0x2b8/0xf38)
 r7:0000004b r6:bf834010 r5:bf809950 r4:bf834010
 [<80365148>] (udc_irq+0x0/0xf38) from [<80362888>] (ci_irq+0xa0/0xf4)
[<803627e8>] (ci_irq+0x0/0xf4) from [<8008111c>] (handle_irq_event_percpu+0x70/0x254)
 r5:bf809950 r4:bfb35180
 [<800810ac>] (handle_irq_event_percpu+0x0/0x254) from [<80081368>] (handle_irq_event+0x68/0x88)
[<80081300>] (handle_irq_event+0x0/0x88) from [<800843c8>] (handle_fasteoi_irq+0xa8/0x178)
 r5:bf809950 r4:bf809900
 [<80084320>] (handle_fasteoi_irq+0x0/0x178) from [<80081088>] (generic_handle_irq+0x38/0x40)
 r5:806cf748 r4:0000004b
 [<80081050>] (generic_handle_irq+0x0/0x40) from [<8000fa44>] (handle_IRQ+0x5c/0xbc)
 r5:806cf748 r4:806c6000
 [<8000f9e8>] (handle_IRQ+0x0/0xbc) from [<80008584>] (gic_handle_irq+0x3c/0x70)
 r9:412fc09a r8:806d29e8 r7:f4000110 r6:806c7f30 r5:806ce974
 r4:f400010c
 [<80008548>] (gic_handle_irq+0x0/0x70) from [<8000eac0>] (__irq_svc+0x40/0x54)
Exception stack(0x806c7f30 to 0x806c7f78)
7f20:                                     00000000 00000000 0000000f 8001aea0
7f40: 806c6000 80712a48 804f0040 00000000 806d29e8 412fc09a 00000000 806c7f84
7f60: 806c7f88 806c7f78 8000fbcc 8000fbd0 60000013 ffffffff
 r7:806c7f64 r6:ffffffff r5:60000013 r4:8000fbd0
 [<8000fb90>] (default_idle+0x0/0x4c) from [<8001015c>] (cpu_idle+0xbc/0xf8)
[<800100a0>] (cpu_idle+0x0/0xf8) from [<804e5334>] (rest_init+0x6c/0x84)
 r9:412fc09a r8:1000406a r7:8fffffff r6:806a4528 r5:80712980
 r4:806cf5b0
 [<804e52c8>] (rest_init+0x0/0x84) from [<80668940>] (start_kernel+0x29c/0x2ec)
[<806686a4>] (start_kernel+0x0/0x2ec) from [<10008078>] (0x10008078)
Code: e12fff33 e5953200 e3530000 0a000002 (e5933014)
---[ end trace aade28ad434062bd ]---
Kernel panic - not syncing: 0xbf8bdfa8)
df60: 00000000 00000000 0000000f 8001aea0 bf8bc000 80712a48 804f0040 00000000
df80: 806d29e8 412fc09a 00000000 bf8bdfb4 bf8bdfb8 bf8bdfa8 8000fbcc 8000fbd0
dfa0: 60000013 ffffffff
 r7:bf8bdf94 r6:ffffffff r5:60000013 r4:8000fbd0
 [<8000fb90>] (default_idle+0x0/0x4c) from [<8001015c>] (cpu_idle+0xbc/0xf8)
[<800100a0>] (cpu_idle+0x0/0xf8) from [<804e7930>] (secondary_start_kernel+0x120/0x148)
 r9:412fc09a r8:1000406a r7:80712d20 r6:10c03c7d r5:00000002
 r4:806e2008
 [<804e7810>] (secondary_start_kernel+0x0/0x148) from [<104e7148>] (0x104e7148)
 r5:0000001f r4:4f8a806a
 CPU3: stopping
 Backtrace:
 [<800132e8>] (dump_backtrace+0x0/0x114) from [<804ea684>] (dump_stack+0x20/0x24)
 r7:00000000 r6:806c3f2c r5:806cf748 r4:80712d18
 [<804ea664>] (dump_stack+0x0/0x24) from [<80014adc>] (handle_IPI+0x140/0x18c)
[<8001499c>] (handle_IPI+0x0/0x18c) from [<800085b0>] (gic_handle_irq+0x68/0x70)
 r9:412fc09a r8:806d29e8 r7:f4000110 r6:bf8bff60 r5:806ce974
 r4:f400010c
 [<80008548>] (gic_handle_irq+0x0/0x70) from [<8000eac0>] (__irq_svc+0x40/0x54)
Exception stack(0xbf8bff60 to 0xbf8bffa8)
ff60: 00000000 00000000 0000000f 8001aea0 bf8be000 80712a48 804f0040 00000000
ff80: 806d29e8 412fc09a 00000000 bf8bffb4 bf8bffb8 bf8bffa8 8000fbcc 8000fbd0
ffa0: 60000013 ffffffff
 r7:bf8bff94 r6:ffffffff r5:60000013 r4:8000fbd0
 [<8000fb90>] (default_idle+0x0/0x4c) from [<8001015c>] (cpu_idle+0xbc/0xf8)
[<800100a0>] (cpu_idle+0x0/0xf8) from [<804e7930>] (secondary_start_kernel+0x120/0x148)
 r9:412fc09a r8:1000406a r7:80712d20 r6:10c03c7d r5:00000003
 r4:806e2008
 [<804e7810>] (secondary_start_kernel+0x0/0x148) from [<104e7148>] (0x104e7148)
 r5:0000001f r4:4f8a806a
 CPU1: stopping
 Backtrace:
 [<800132e8>] (dump_backtrace+0x0/0x114) from [<804ea684>] (dump_stack+0x20/0x24)
 r7:00000000 r6:806c3f2c r5:806cf748 r4:80712d18
 [<804ea664>] (dump_stack+0x0/0x24) from [<80014adc>] (handle_IPI+0x140/0x18c)
[<8001499c>] (handle_IPI+0x0/0x18c) from [<800085b0>] (gic_handle_irq+0x68/0x70)
 r9:412fc09a r8:806d29e8 r7:f4000110 r6:bf8bbf60 r5:806ce974
 r4:f400010c
 [<80008548>] (gic_handle_irq+0x0/0x70) from [<8000eac0>] (__irq_svc+0x40/0x54)
Exception stack(0xbf8bbf60 to 0xbf8bbfa8)
bf60: 00000000 00000000 0000000f 8001aea0 bf8ba000 80712a48 804f0040 00000000
bf80: 806d29e8 412fc09a 00000000 bf8bbfb4 bf8bbfb8 bf8bbfa8 8000fbcc 8000fbd0
bfa0: 60000013 ffffffff
 r7:bf8bbf94 r6:ffffffff r5:60000013 r4:8000fbd0
 [<8000fb90>] (default_idle+0x0/0x4c) from [<8001015c>] (cpu_idle+0xbc/0xf8)
[<800100a0>] (cpu_idle+0x0/0xf8) from [<804e7930>] (secondary_start_kernel+0x120/0x148)
 r9:412fc09a r8:1000406a r7:80712d20 r6:10c03c7d r5:00000001
 r4:806e2008

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/udc.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index b7ead5f..aeabdcf 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -686,9 +686,6 @@ static int _gadget_stop_activity(struct usb_gadget *gadget)
 	usb_ep_fifo_flush(&ci->ep0out->ep);
 	usb_ep_fifo_flush(&ci->ep0in->ep);
 
-	if (ci->driver)
-		ci->driver->disconnect(gadget);
-
 	/* make sure to disable all endpoints */
 	gadget_for_each_ep(ep, gadget) {
 		usb_ep_disable(ep);
@@ -717,6 +714,11 @@ __acquires(ci->lock)
 {
 	int retval;
 
+	if (ci->gadget.speed != USB_SPEED_UNKNOWN) {
+		if (ci->driver)
+			ci->driver->disconnect(&ci->gadget);
+	}
+
 	spin_unlock(&ci->lock);
 	retval = _gadget_stop_activity(&ci->gadget);
 	if (retval)
@@ -1464,6 +1466,8 @@ static int ci_udc_vbus_session(struct usb_gadget *_gadget, int is_active)
 			hw_device_state(ci, ci->ep0out->qh.dma);
 			dev_dbg(ci->dev, "Connected to host\n");
 		} else {
+			if (ci->driver)
+				ci->driver->disconnect(&ci->gadget);
 			hw_device_state(ci, 0);
 			if (ci->platdata->notify_event)
 				ci->platdata->notify_event(ci,
@@ -1674,13 +1678,14 @@ static int ci_udc_stop(struct usb_gadget *gadget,
 		if (ci->platdata->notify_event)
 			ci->platdata->notify_event(ci,
 			CI_HDRC_CONTROLLER_STOPPED_EVENT);
-		ci->driver = NULL;
 		spin_unlock_irqrestore(&ci->lock, flags);
 		_gadget_stop_activity(&ci->gadget);
 		spin_lock_irqsave(&ci->lock, flags);
 		pm_runtime_put(&ci->gadget.dev);
 	}
 
+	ci->driver = NULL;
+
 	spin_unlock_irqrestore(&ci->lock, flags);
 
 	return 0;
-- 
1.7.0.4




From tony at atomide.com  Thu Jul 11 02:32:10 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Jul 2013 23:32:10 -0700
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130710161158.GA19716@arwen.pp.htv.fi>
References: <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi>
 <87mwpuakod.fsf@linaro.org> <20130710142633.GV5523@atomide.com>
 <20130710160704.GH18966@arwen.pp.htv.fi>
 <20130710161158.GA19716@arwen.pp.htv.fi>
Message-ID: <20130711063209.GZ5523@atomide.com>

* Felipe Balbi <balbi at ti.com> [130710 09:18]:
> 
> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
> > how about something like below ? It makes omap_device/hwmod and
> > pm_runtime agree on the initial state of the device and will prevent
> > ->runtime_resume() from being called on first pm_runtime_get*() done
> > during probe.
> > 
> > This is similar to what PCI bus does (if you look at pci_pm_init()).
> > 
> > commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
> > Author: Felipe Balbi <balbi at ti.com>
> > Date:   Wed Jul 10 18:50:16 2013 +0300
> > 
> >     arm: omap2plus: unidle devices which are about to probe
> >     
> >     in order to make HWMOD and pm_runtime agree on the
> >     initial state of the device, we will unidle the device
> >     and call pm_runtime_set_active() to tell pm_runtime
> >     that the device is really active.
> >     
> >     By the time driver's probe() is reached, a call to
> >     pm_runtime_get_sync() will not cause driver's
> >     ->runtime_resume() method to be called at first, only
> >     after a successful ->runtime_suspend().
> >     
> >     Signed-off-by: Felipe Balbi <balbi at ti.com>
> 
> btw, this is RFC, haven't tested at all.

Yes it does not compile, then removing the extra ; at the end
of the functions, it oopses with a NULL pointer exception.

Regards,

Tony


From afzal at ti.com  Thu Jul 11 02:33:00 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 11 Jul 2013 12:03:00 +0530
Subject: [PATCH RFC 00/13] ARM: OMAP2+: AM43x PRCM support
Message-ID: <cover.1373519192.git.afzal@ti.com>

Hi,

AM43x PRCM support (excluding clock tree) is being added with this
series. AM43x reuses most of the IP's from AM335x, as that is the
case, it was felt that reusing AM335x code as much as possible for
AM43x is better - it also helps to keep LOC less.

		********

This RFC is being posted to get an early feedback on approach taken
here mainly w.r.t reusing AM335x hwmod database for AM43x.

		********

Major reuse has been with hwmod database of AM335x, moving common
elements to a new array and keeping separate arrays for elements that
are specific only to either one of AM335x or AM43x. And in the cases
where relevant IP is present in both that has difference in details
like CLKCTRL register offsets, it is being updated at runtime based on
the SoC detected.

Powerdomain & Clockdomain data has been added separately as it was not
giving much advantage reusing AM335x ones (runtime updates required
was getting too ugly).

As AM43x PRCM is similar to OMAP4, OMAP4 power domain & clock domain
operations are being reused. This would have to be modified to have
only the required domain operation fields, some thing like reusing
Vaibhav Bedia's newly proposed domain operations for AM335x of [4]
if [1] completely makes it to the mainline (that would require
modifications to power and clock domain data fields of this series
too), otherwise a similar domain operations would have to be added
for AM43x.

Also it has to be ensured that only relevant HWMOD operations are
handled like in [4].

A single header file has been added to provide all AM43x PRCM defines.

Here sequencewise, initially AM335x hwmod is modified to have it's
fields get updated at runtime (wherever element is shared and has
some difference with AM43x). Then power domain, clock domain for AM43x
is added and finally AM335x hwmod database is updated with AM43x
specifics.

This series is being developed with additional clock tree changes that
would be DT'fied.

Additional DTS changes are also required for hwmod to get register
target address space as most of AM335x hwmod address space details has
been recently cleaned up and moved to DTS.

Vaibhav Bedia's [2] & [3] that are part of [1] has been used along
with this series for validating.

Regards
Afzal

[1] Consolidate AM335x and OMAP4 PRM/CM APIs -
	http://www.mail-archive.com/linux-omap at vger.kernel.org/msg91511.html
[2] [RFC 2/9] ARM: OMAP2+: CM code: Reintroduce SW_SLEEP for OMAP4 class of devices
[3] [RFC 6/9] ARM: OMAP4: CM code: Remove the check for non-zero clkctrl_offs
[4] [RFC 8/9] ARM: OMAP2+: AM335x: Migrate to OMAP4 PRM/CM APIs

Afzal Mohammed (8):
  ARM: OMAP2+: hwmod: AM335x: prepare for AM43x reuse
  ARM: OMAP2+: hwmod: AMx3: runtime AM335x handling
  ARM: OMAP2+: hwmod: AMx3: remove common static fields
  ARM: OMAP2+: PRCM: AM43x definitions
  ARM: OMAP2+: hwmod: AMx3: runtime AM43x handling
  ARM: OMAP2+: AM43x: PRCM kbuild
  ARM: OMAP2+: hwmod: type4 sysc
  ARM: OMAP2+: hwmod: AM43x: new w.r.t AM335x

Ambresh K (4):
  ARM: OMAP2+: PM: AM43x powerdomain data
  ARM: OMAP2+: CM: AM43x clockdomain data
  ARM: OMAP2+: hwmod: AM43x operations
  ARM: OMAP2+: AM43x PRCM init

Ankur Kishore (1):
  ARM: OMAP2+: CM: cm_inst offset s16->u16

 arch/arm/mach-omap2/Makefile                 |   5 +-
 arch/arm/mach-omap2/clockdomain.h            |   3 +-
 arch/arm/mach-omap2/clockdomains43xx_data.c  | 199 +++++++
 arch/arm/mach-omap2/cm33xx.c                 |  30 +-
 arch/arm/mach-omap2/cm33xx.h                 |  28 +-
 arch/arm/mach-omap2/cminst44xx.c             |  29 +-
 arch/arm/mach-omap2/cminst44xx.h             |  25 +-
 arch/arm/mach-omap2/io.c                     |   6 +
 arch/arm/mach-omap2/omap_hwmod.c             |   2 +-
 arch/arm/mach-omap2/omap_hwmod.h             |   5 +
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c   | 850 ++++++++++++++++++++++++---
 arch/arm/mach-omap2/omap_hwmod_common_data.c |   6 +
 arch/arm/mach-omap2/powerdomain.h            |   1 +
 arch/arm/mach-omap2/powerdomains43xx_data.c  | 145 +++++
 arch/arm/mach-omap2/prcm43xx.h               | 148 +++++
 15 files changed, 1341 insertions(+), 141 deletions(-)
 create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c
 create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c
 create mode 100644 arch/arm/mach-omap2/prcm43xx.h

-- 
1.8.3.1



From afzal at ti.com  Thu Jul 11 02:34:03 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 11 Jul 2013 12:04:03 +0530
Subject: [PATCH RFC 01/13] ARM: OMAP2+: hwmod: AM335x: prepare for AM43x reuse
In-Reply-To: <cover.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
Message-ID: <1c4a872117bd814d7fad856b6ef89fc6dbcf37da.1373519192.git.afzal@ti.com>

AM335x & AM43x have most of the interconnects, IPs similar. Instead of
adding new hwmod data for AM43x, reuse AM335x hwmod data as much as
possible.

In the hwmod entries that could be reused on AM43x, major changes are
in register offsets and different ocpif clock for most of peripherals
that comes under l4_wkup interconnect.

To achieve reuse, as a first step, bring out ocpif's relevant for both
SoC's to a new array and handle appropriately.

Signed-off-by: Afzal Mohammed <afzal at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 7a9b492..b0a38f0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -29,6 +29,7 @@
 #include "i2c.h"
 #include "mmc.h"
 #include "wd_timer.h"
+#include "soc.h"
 
 /*
  * IP blocks
@@ -2458,6 +2459,13 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__aes0 = {
 
 static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
 	&am33xx_l3_main__emif,
+	&am33xx_l4_hs__pruss,
+	&am33xx_l3_main__lcdc,
+	&am33xx_l3_s__usbss,
+	NULL,
+};
+
+static struct omap_hwmod_ocp_if *amx3xx_hwmod_ocp_ifs[] __initdata = {
 	&am33xx_mpu__l3_main,
 	&am33xx_mpu__prcm,
 	&am33xx_l3_s__l4_ls,
@@ -2481,7 +2489,6 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
 	&am33xx_l4_wkup__gpio0,
 	&am33xx_l4_wkup__adc_tsc,
 	&am33xx_l4_wkup__wd_timer1,
-	&am33xx_l4_hs__pruss,
 	&am33xx_l4_per__dcan0,
 	&am33xx_l4_per__dcan1,
 	&am33xx_l4_per__gpio1,
@@ -2522,14 +2529,12 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
 	&am33xx_epwmss2__eqep2,
 	&am33xx_epwmss2__ehrpwm2,
 	&am33xx_l3_s__gpmc,
-	&am33xx_l3_main__lcdc,
 	&am33xx_l4_ls__mcspi0,
 	&am33xx_l4_ls__mcspi1,
 	&am33xx_l3_main__tptc0,
 	&am33xx_l3_main__tptc1,
 	&am33xx_l3_main__tptc2,
 	&am33xx_l3_main__ocmc,
-	&am33xx_l3_s__usbss,
 	&am33xx_l4_hs__cpgmac0,
 	&am33xx_cpgmac0__mdio,
 	&am33xx_l3_main__sha0,
@@ -2539,6 +2544,15 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
 
 int __init am33xx_hwmod_init(void)
 {
+	int ret;
+
 	omap_hwmod_init();
-	return omap_hwmod_register_links(am33xx_hwmod_ocp_ifs);
+	ret = omap_hwmod_register_links(amx3xx_hwmod_ocp_ifs);
+	if (ret < 0)
+		return ret;
+
+	if (soc_is_am33xx())
+		return omap_hwmod_register_links(am33xx_hwmod_ocp_ifs);
+
+	return 0;
 }
-- 
1.8.3.1



From afzal at ti.com  Thu Jul 11 02:35:30 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 11 Jul 2013 12:05:30 +0530
Subject: [PATCH RFC 02/13] ARM: OMAP2+: hwmod: AMx3: runtime AM335x handling
In-Reply-To: <cover.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
Message-ID: <81ee24af0683f61b7f047875519216352a4bc811.1373519192.git.afzal@ti.com>

Update AM335x CLKCTRL, RSTCTRL, RSTST offsets, clockdomain & ocpif clk
that differ with AM43x at runtime. This is being done so that static
initialization of these details (which are different between AM335x
and AM43x) can be removed to aid in sharing of hwmod data between both
platforms as much as possible.

Signed-off-by: Afzal Mohammed <afzal at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 118 +++++++++++++++++++++++++++++
 1 file changed, 118 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index b0a38f0..57234a0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -2457,6 +2457,115 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__aes0 = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+#define CLKCTRL(oh, clkctrl) ((oh).prcm.omap4.clkctrl_offs = (clkctrl))
+
+static void am33xx_hwmod_clkctrl(void)
+{
+	CLKCTRL(am33xx_uart2_hwmod, AM33XX_CM_PER_UART1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_uart3_hwmod, AM33XX_CM_PER_UART2_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_uart4_hwmod, AM33XX_CM_PER_UART3_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_uart5_hwmod, AM33XX_CM_PER_UART4_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_uart6_hwmod, AM33XX_CM_PER_UART5_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_dcan0_hwmod, AM33XX_CM_PER_DCAN0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_dcan1_hwmod, AM33XX_CM_PER_DCAN1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_elm_hwmod, AM33XX_CM_PER_ELM_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_epwmss0_hwmod, AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_epwmss1_hwmod, AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_epwmss2_hwmod, AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_gpio1_hwmod, AM33XX_CM_PER_GPIO1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_gpio2_hwmod, AM33XX_CM_PER_GPIO2_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_gpio3_hwmod, AM33XX_CM_PER_GPIO3_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_i2c2_hwmod, AM33XX_CM_PER_I2C1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_i2c3_hwmod, AM33XX_CM_PER_I2C2_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_mailbox_hwmod, AM33XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_mcasp0_hwmod, AM33XX_CM_PER_MCASP0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_mcasp1_hwmod, AM33XX_CM_PER_MCASP1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_mmc0_hwmod, AM33XX_CM_PER_MMC0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_mmc1_hwmod, AM33XX_CM_PER_MMC1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_spi0_hwmod, AM33XX_CM_PER_SPI0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_spi1_hwmod, AM33XX_CM_PER_SPI1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_spinlock_hwmod, AM33XX_CM_PER_SPINLOCK_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_timer2_hwmod, AM33XX_CM_PER_TIMER2_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_timer3_hwmod, AM33XX_CM_PER_TIMER3_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_timer4_hwmod, AM33XX_CM_PER_TIMER4_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_timer5_hwmod, AM33XX_CM_PER_TIMER5_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_timer6_hwmod, AM33XX_CM_PER_TIMER6_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_timer7_hwmod, AM33XX_CM_PER_TIMER7_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_wkup_m3_hwmod, AM33XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_control_hwmod, AM33XX_CM_WKUP_CONTROL_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_smartreflex0_hwmod,
+		AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_smartreflex1_hwmod,
+		AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_uart1_hwmod, AM33XX_CM_WKUP_UART0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_timer1_hwmod, AM33XX_CM_WKUP_TIMER1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_i2c1_hwmod, AM33XX_CM_WKUP_I2C0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_gpio0_hwmod, AM33XX_CM_WKUP_GPIO0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_adc_tsc_hwmod, AM33XX_CM_WKUP_ADC_TSC_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_wd_timer1_hwmod, AM33XX_CM_WKUP_WDT1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_rtc_hwmod, AM33XX_CM_RTC_RTC_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_mmc2_hwmod, AM33XX_CM_PER_MMC2_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_gpmc_hwmod, AM33XX_CM_PER_GPMC_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_l4_ls_hwmod, AM33XX_CM_PER_L4LS_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_l4_wkup_hwmod, AM33XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_l3_main_hwmod, AM33XX_CM_PER_L3_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_tpcc_hwmod, AM33XX_CM_PER_TPCC_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_tptc0_hwmod, AM33XX_CM_PER_TPTC0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_tptc1_hwmod, AM33XX_CM_PER_TPTC1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_tptc2_hwmod, AM33XX_CM_PER_TPTC2_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_gfx_hwmod, AM33XX_CM_GFX_GFX_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_l4_hs_hwmod, AM33XX_CM_PER_L4HS_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_cpgmac0_hwmod, AM33XX_CM_PER_CPGMAC0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_pruss_hwmod, AM33XX_CM_PER_PRUSS_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_mpu_hwmod , AM33XX_CM_MPU_MPU_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_l3_instr_hwmod , AM33XX_CM_PER_L3_INSTR_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_ocmcram_hwmod , AM33XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_sha0_hwmod , AM33XX_CM_PER_SHA0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_aes0_hwmod , AM33XX_CM_PER_AES0_CLKCTRL_OFFSET);
+}
+
+#define RSTCTRL(oh, rstctrl) ((oh).prcm.omap4.rstctrl_offs = (rstctrl))
+
+static void am33xx_hwmod_rstctrl(void)
+{
+	RSTCTRL(am33xx_pruss_hwmod, AM33XX_RM_PER_RSTCTRL_OFFSET);
+	RSTCTRL(am33xx_gfx_hwmod, AM33XX_RM_GFX_RSTCTRL_OFFSET);
+	RSTCTRL(am33xx_wkup_m3_hwmod, AM33XX_RM_WKUP_RSTCTRL_OFFSET);
+}
+
+#define RSTST(oh, rstst) ((oh).prcm.omap4.rstst_offs = (rstst))
+
+static void am33xx_hwmod_rstst(void)
+{
+	RSTST(am33xx_gfx_hwmod, AM33XX_RM_GFX_RSTST_OFFSET);
+	RSTST(am33xx_wkup_m3_hwmod, AM33XX_RM_WKUP_RSTST_OFFSET);
+}
+
+static void am33xx_hwmod_clockdomain(void)
+{
+	am33xx_l4_hs_hwmod.clkdm_name = "l4hs_clkdm";
+	am33xx_adc_tsc_hwmod.clkdm_name = "l4_wkup_clkdm";
+}
+
+#define AM33XX_L4_WKUP_OCPIF_CLK "dpll_core_m4_div2_ck"
+
+static void am33xx_hwmod_ocpif_clk(void)
+{
+	am33xx_l4_wkup__wkup_m3.clk = AM33XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__control.clk = AM33XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__smartreflex0.clk = AM33XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__smartreflex1.clk = AM33XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__uart1.clk = AM33XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__timer1.clk = AM33XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__i2c1.clk = AM33XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__gpio0.clk = AM33XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__wd_timer1.clk = AM33XX_L4_WKUP_OCPIF_CLK;
+	am33xx_wkup_m3__l4_wkup.clk = AM33XX_L4_WKUP_OCPIF_CLK;
+	am33xx_wkup_m3_hwmod.main_clk = AM33XX_L4_WKUP_OCPIF_CLK;
+	am33xx_control_hwmod.main_clk = AM33XX_L4_WKUP_OCPIF_CLK;
+	am33xx_gpio0_hwmod.main_clk = AM33XX_L4_WKUP_OCPIF_CLK;
+}
+
 static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
 	&am33xx_l3_main__emif,
 	&am33xx_l4_hs__pruss,
@@ -2547,6 +2656,15 @@ int __init am33xx_hwmod_init(void)
 	int ret;
 
 	omap_hwmod_init();
+
+	if (soc_is_am33xx()) {
+		am33xx_hwmod_clkctrl();
+		am33xx_hwmod_rstctrl();
+		am33xx_hwmod_rstst();
+		am33xx_hwmod_clockdomain();
+		am33xx_hwmod_ocpif_clk();
+	}
+
 	ret = omap_hwmod_register_links(amx3xx_hwmod_ocp_ifs);
 	if (ret < 0)
 		return ret;
-- 
1.8.3.1



From afzal at ti.com  Thu Jul 11 02:35:38 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 11 Jul 2013 12:05:38 +0530
Subject: [PATCH RFC 03/13] ARM: OMAP2+: hwmod: AMx3: remove common static
 fields
In-Reply-To: <cover.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
Message-ID: <937b821fd59e9260d5f7c9c84ee5a4915f1cdaa4.1373519192.git.afzal@ti.com>

Hwmod common to AM43x & AM335x has some of fields different (CLKCTRL,
RSTCTRL, RSTST, ocpif clk and clockdomain). It is now updated based
on SoC detection at run time, hence remove statically initialized
entries.

Signed-off-by: Afzal Mohammed <afzal at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 79 ------------------------------
 1 file changed, 79 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 57234a0..a61032d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -79,7 +79,6 @@ static struct omap_hwmod am33xx_l3_main_hwmod = {
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_L3_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -101,7 +100,6 @@ static struct omap_hwmod am33xx_l3_instr_hwmod = {
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_L3_INSTR_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -124,7 +122,6 @@ static struct omap_hwmod am33xx_l4_ls_hwmod = {
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_L4LS_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -134,12 +131,10 @@ static struct omap_hwmod am33xx_l4_ls_hwmod = {
 static struct omap_hwmod am33xx_l4_hs_hwmod = {
 	.name		= "l4_hs",
 	.class		= &am33xx_l4_hwmod_class,
-	.clkdm_name	= "l4hs_clkdm",
 	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
 	.main_clk	= "l4hs_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_L4HS_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -154,7 +149,6 @@ static struct omap_hwmod am33xx_l4_wkup_hwmod = {
 	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -175,7 +169,6 @@ static struct omap_hwmod am33xx_mpu_hwmod = {
 	.main_clk	= "dpll_mpu_m2_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_MPU_MPU_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -200,12 +193,8 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
 	.clkdm_name	= "l4_wkup_aon_clkdm",
 	/* Keep hardreset asserted */
 	.flags		= HWMOD_INIT_NO_RESET | HWMOD_NO_IDLEST,
-	.main_clk	= "dpll_core_m4_div2_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET,
-			.rstctrl_offs	= AM33XX_RM_WKUP_RSTCTRL_OFFSET,
-			.rstst_offs	= AM33XX_RM_WKUP_RSTST_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -234,8 +223,6 @@ static struct omap_hwmod am33xx_pruss_hwmod = {
 	.main_clk	= "pruss_ocp_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_PRUSS_CLKCTRL_OFFSET,
-			.rstctrl_offs	= AM33XX_RM_PER_RSTCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -260,9 +247,6 @@ static struct omap_hwmod am33xx_gfx_hwmod = {
 	.main_clk	= "gfx_fck_div_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_GFX_GFX_CLKCTRL_OFFSET,
-			.rstctrl_offs	= AM33XX_RM_GFX_RSTCTRL_OFFSET,
-			.rstst_offs	= AM33XX_RM_GFX_RSTST_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -306,11 +290,9 @@ static struct omap_hwmod_class am33xx_adc_tsc_hwmod_class = {
 static struct omap_hwmod am33xx_adc_tsc_hwmod = {
 	.name		= "adc_tsc",
 	.class		= &am33xx_adc_tsc_hwmod_class,
-	.clkdm_name	= "l4_wkup_clkdm",
 	.main_clk	= "adc_tsc_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_WKUP_ADC_TSC_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -432,7 +414,6 @@ static struct omap_hwmod am33xx_aes0_hwmod = {
 	.main_clk	= "aes0_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_AES0_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -458,7 +439,6 @@ static struct omap_hwmod am33xx_sha0_hwmod = {
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_SHA0_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -477,7 +457,6 @@ static struct omap_hwmod am33xx_ocmcram_hwmod = {
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -496,7 +475,6 @@ static struct omap_hwmod am33xx_smartreflex0_hwmod = {
 	.main_clk	= "smartreflex0_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -510,7 +488,6 @@ static struct omap_hwmod am33xx_smartreflex1_hwmod = {
 	.main_clk	= "smartreflex1_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -528,10 +505,8 @@ static struct omap_hwmod am33xx_control_hwmod = {
 	.class		= &am33xx_control_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
 	.flags		= (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
-	.main_clk	= "dpll_core_m4_div2_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_WKUP_CONTROL_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -566,7 +541,6 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
 	.mpu_rt_idx	= 1,
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_CPGMAC0_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -601,7 +575,6 @@ static struct omap_hwmod am33xx_dcan0_hwmod = {
 	.main_clk	= "dcan0_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_DCAN0_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -615,7 +588,6 @@ static struct omap_hwmod am33xx_dcan1_hwmod = {
 	.main_clk	= "dcan1_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_DCAN1_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -645,7 +617,6 @@ static struct omap_hwmod am33xx_elm_hwmod = {
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_ELM_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -687,7 +658,6 @@ static struct omap_hwmod am33xx_epwmss0_hwmod = {
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -725,7 +695,6 @@ static struct omap_hwmod am33xx_epwmss1_hwmod = {
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -763,7 +732,6 @@ static struct omap_hwmod am33xx_epwmss2_hwmod = {
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -829,10 +797,8 @@ static struct omap_hwmod am33xx_gpio0_hwmod = {
 	.class		= &am33xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
 	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
-	.main_clk	= "dpll_core_m4_div2_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_WKUP_GPIO0_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -854,7 +820,6 @@ static struct omap_hwmod am33xx_gpio1_hwmod = {
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_GPIO1_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -876,7 +841,6 @@ static struct omap_hwmod am33xx_gpio2_hwmod = {
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_GPIO2_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -898,7 +862,6 @@ static struct omap_hwmod am33xx_gpio3_hwmod = {
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_GPIO3_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -931,7 +894,6 @@ static struct omap_hwmod am33xx_gpmc_hwmod = {
 	.main_clk	= "l3s_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_GPMC_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -969,7 +931,6 @@ static struct omap_hwmod am33xx_i2c1_hwmod = {
 	.main_clk	= "dpll_per_m2_div4_wkupdm_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_WKUP_I2C0_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -985,7 +946,6 @@ static struct omap_hwmod am33xx_i2c2_hwmod = {
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4 = {
-			.clkctrl_offs	= AM33XX_CM_PER_I2C1_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1001,7 +961,6 @@ static struct omap_hwmod am33xx_i2c3_hwmod = {
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_I2C2_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1063,7 +1022,6 @@ static struct omap_hwmod am33xx_mailbox_hwmod = {
 	.main_clk	= "l4ls_gclk",
 	.prcm = {
 		.omap4 = {
-			.clkctrl_offs	= AM33XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1093,7 +1051,6 @@ static struct omap_hwmod am33xx_mcasp0_hwmod = {
 	.main_clk	= "mcasp0_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_MCASP0_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1107,7 +1064,6 @@ static struct omap_hwmod am33xx_mcasp1_hwmod = {
 	.main_clk	= "mcasp1_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_MCASP1_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1142,7 +1098,6 @@ static struct omap_hwmod am33xx_mmc0_hwmod = {
 	.main_clk	= "mmc_clk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_MMC0_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1161,7 +1116,6 @@ static struct omap_hwmod am33xx_mmc1_hwmod = {
 	.main_clk	= "mmc_clk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_MMC1_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1179,7 +1133,6 @@ static struct omap_hwmod am33xx_mmc2_hwmod = {
 	.main_clk	= "mmc_clk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_MMC2_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1211,7 +1164,6 @@ static struct omap_hwmod am33xx_rtc_hwmod = {
 	.main_clk	= "clk_32768_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_RTC_RTC_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1246,7 +1198,6 @@ static struct omap_hwmod am33xx_spi0_hwmod = {
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_SPI0_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1261,7 +1212,6 @@ static struct omap_hwmod am33xx_spi1_hwmod = {
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_SPI1_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1284,7 +1234,6 @@ static struct omap_hwmod am33xx_spinlock_hwmod = {
 	.main_clk	= "l4ls_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_SPINLOCK_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1330,7 +1279,6 @@ static struct omap_hwmod am33xx_timer1_hwmod = {
 	.main_clk	= "timer1_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_WKUP_TIMER1_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1343,7 +1291,6 @@ static struct omap_hwmod am33xx_timer2_hwmod = {
 	.main_clk	= "timer2_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_TIMER2_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1356,7 +1303,6 @@ static struct omap_hwmod am33xx_timer3_hwmod = {
 	.main_clk	= "timer3_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_TIMER3_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1369,7 +1315,6 @@ static struct omap_hwmod am33xx_timer4_hwmod = {
 	.main_clk	= "timer4_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_TIMER4_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1382,7 +1327,6 @@ static struct omap_hwmod am33xx_timer5_hwmod = {
 	.main_clk	= "timer5_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_TIMER5_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1395,7 +1339,6 @@ static struct omap_hwmod am33xx_timer6_hwmod = {
 	.main_clk	= "timer6_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_TIMER6_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1408,7 +1351,6 @@ static struct omap_hwmod am33xx_timer7_hwmod = {
 	.main_clk	= "timer7_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_TIMER7_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1426,7 +1368,6 @@ static struct omap_hwmod am33xx_tpcc_hwmod = {
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_TPCC_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1456,7 +1397,6 @@ static struct omap_hwmod am33xx_tptc0_hwmod = {
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_TPTC0_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1471,7 +1411,6 @@ static struct omap_hwmod am33xx_tptc1_hwmod = {
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_TPTC1_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1486,7 +1425,6 @@ static struct omap_hwmod am33xx_tptc2_hwmod = {
 	.main_clk	= "l3_gclk",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_TPTC2_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1518,7 +1456,6 @@ static struct omap_hwmod am33xx_uart1_hwmod = {
 	.main_clk	= "dpll_per_m2_div4_wkupdm_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_WKUP_UART0_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1532,7 +1469,6 @@ static struct omap_hwmod am33xx_uart2_hwmod = {
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_UART1_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1547,7 +1483,6 @@ static struct omap_hwmod am33xx_uart3_hwmod = {
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_UART2_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1561,7 +1496,6 @@ static struct omap_hwmod am33xx_uart4_hwmod = {
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_UART3_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1575,7 +1509,6 @@ static struct omap_hwmod am33xx_uart5_hwmod = {
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_UART4_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1589,7 +1522,6 @@ static struct omap_hwmod am33xx_uart6_hwmod = {
 	.main_clk	= "dpll_per_m2_div4_ck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_PER_UART5_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1625,7 +1557,6 @@ static struct omap_hwmod am33xx_wd_timer1_hwmod = {
 	.main_clk	= "wdt1_fck",
 	.prcm		= {
 		.omap4	= {
-			.clkctrl_offs	= AM33XX_CM_WKUP_WDT1_CLKCTRL_OFFSET,
 			.modulemode	= MODULEMODE_SWCTRL,
 		},
 	},
@@ -1761,7 +1692,6 @@ static struct omap_hwmod_ocp_if am33xx_pruss__l3_main = {
 static struct omap_hwmod_ocp_if am33xx_wkup_m3__l4_wkup = {
 	.master		= &am33xx_wkup_m3_hwmod,
 	.slave		= &am33xx_l4_wkup_hwmod,
-	.clk		= "dpll_core_m4_div2_ck",
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
@@ -1777,7 +1707,6 @@ static struct omap_hwmod_ocp_if am33xx_gfx__l3_main = {
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__wkup_m3 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_wkup_m3_hwmod,
-	.clk		= "dpll_core_m4_div2_ck",
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
@@ -1801,7 +1730,6 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__gfx = {
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__smartreflex0 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_smartreflex0_hwmod,
-	.clk		= "dpll_core_m4_div2_ck",
 	.user		= OCP_USER_MPU,
 };
 
@@ -1809,7 +1737,6 @@ static struct omap_hwmod_ocp_if am33xx_l4_wkup__smartreflex0 = {
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__smartreflex1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_smartreflex1_hwmod,
-	.clk		= "dpll_core_m4_div2_ck",
 	.user		= OCP_USER_MPU,
 };
 
@@ -1817,7 +1744,6 @@ static struct omap_hwmod_ocp_if am33xx_l4_wkup__smartreflex1 = {
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__control = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_control_hwmod,
-	.clk		= "dpll_core_m4_div2_ck",
 	.user		= OCP_USER_MPU,
 };
 
@@ -1873,7 +1799,6 @@ static struct omap_hwmod_ocp_if am33xx_l4_per__gpio3 = {
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__i2c1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_i2c1_hwmod,
-	.clk		= "dpll_core_m4_div2_ck",
 	.user		= OCP_USER_MPU,
 };
 
@@ -1881,7 +1806,6 @@ static struct omap_hwmod_ocp_if am33xx_l4_wkup__i2c1 = {
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__gpio0 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_gpio0_hwmod,
-	.clk		= "dpll_core_m4_div2_ck",
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
@@ -2234,7 +2158,6 @@ static struct omap_hwmod_ocp_if am33xx_l4_ls__mcspi1 = {
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__timer1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_timer1_hwmod,
-	.clk		= "dpll_core_m4_div2_ck",
 	.user		= OCP_USER_MPU,
 };
 
@@ -2352,7 +2275,6 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__tptc2 = {
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__uart1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_uart1_hwmod,
-	.clk		= "dpll_core_m4_div2_ck",
 	.user		= OCP_USER_MPU,
 };
 
@@ -2400,7 +2322,6 @@ static struct omap_hwmod_ocp_if am33xx_l4_ls__uart6 = {
 static struct omap_hwmod_ocp_if am33xx_l4_wkup__wd_timer1 = {
 	.master		= &am33xx_l4_wkup_hwmod,
 	.slave		= &am33xx_wd_timer1_hwmod,
-	.clk		= "dpll_core_m4_div2_ck",
 	.user		= OCP_USER_MPU,
 };
 
-- 
1.8.3.1



From afzal at ti.com  Thu Jul 11 02:35:47 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 11 Jul 2013 12:05:47 +0530
Subject: [PATCH RFC 04/13] ARM: OMAP2+: CM: cm_inst offset s16->u16
In-Reply-To: <cover.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
Message-ID: <7a3a9c72e94353e9591ff0b1e65a5fd010e7b890.1373519192.git.afzal@ti.com>

From: Ankur Kishore <a-kishore at ti.com>

Most of the AM43x CM reg address offsets are with MSB bit '1' (on
16-bit value) leading to arithmetic miscalculations while calculating
CLOCK ENABLE register's address because cm_inst field was a type of
"const s16", so make it "const u16".

Also modify relevant functions so as to take care of the above.

Signed-off-by: Ankur Kishore <a-kishore at ti.com>
Signed-off-by: Afzal Mohammed <afzal at ti.com>
---
 arch/arm/mach-omap2/clockdomain.h |  2 +-
 arch/arm/mach-omap2/cm33xx.c      | 30 +++++++++++++++---------------
 arch/arm/mach-omap2/cm33xx.h      | 26 +++++++++++++-------------
 arch/arm/mach-omap2/cminst44xx.c  | 29 +++++++++++++++--------------
 arch/arm/mach-omap2/cminst44xx.h  | 25 +++++++++++++------------
 5 files changed, 57 insertions(+), 55 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomain.h b/arch/arm/mach-omap2/clockdomain.h
index daeecf1..8c22ce6 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -132,7 +132,7 @@ struct clockdomain {
 	u8 _flags;
 	const u8 dep_bit;
 	const u8 prcm_partition;
-	const s16 cm_inst;
+	const u16 cm_inst;
 	const u16 clkdm_offs;
 	struct clkdm_dep *wkdep_srcs;
 	struct clkdm_dep *sleepdep_srcs;
diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
index 325a515..59f276d 100644
--- a/arch/arm/mach-omap2/cm33xx.c
+++ b/arch/arm/mach-omap2/cm33xx.c
@@ -48,13 +48,13 @@
 /* Private functions */
 
 /* Read a register in a CM instance */
-static inline u32 am33xx_cm_read_reg(s16 inst, u16 idx)
+static inline u32 am33xx_cm_read_reg(u16 inst, u16 idx)
 {
 	return __raw_readl(cm_base + inst + idx);
 }
 
 /* Write into a register in a CM */
-static inline void am33xx_cm_write_reg(u32 val, s16 inst, u16 idx)
+static inline void am33xx_cm_write_reg(u32 val, u16 inst, u16 idx)
 {
 	__raw_writel(val, cm_base + inst + idx);
 }
@@ -82,7 +82,7 @@ static inline u32 am33xx_cm_clear_reg_bits(u32 bits, s16 inst, s16 idx)
 	return am33xx_cm_rmw_reg_bits(bits, 0x0, inst, idx);
 }
 
-static inline u32 am33xx_cm_read_reg_bits(u16 inst, s16 idx, u32 mask)
+static inline u32 am33xx_cm_read_reg_bits(u16 inst, u16 idx, u32 mask)
 {
 	u32 v;
 
@@ -102,7 +102,7 @@ static inline u32 am33xx_cm_read_reg_bits(u16 inst, s16 idx, u32 mask)
  * Return the IDLEST bitfield of a CM_*_CLKCTRL register, shifted down to
  * bit 0.
  */
-static u32 _clkctrl_idlest(u16 inst, s16 cdoffs, u16 clkctrl_offs)
+static u32 _clkctrl_idlest(u16 inst, u16 cdoffs, u16 clkctrl_offs)
 {
 	u32 v = am33xx_cm_read_reg(inst, clkctrl_offs);
 	v &= AM33XX_IDLEST_MASK;
@@ -119,7 +119,7 @@ static u32 _clkctrl_idlest(u16 inst, s16 cdoffs, u16 clkctrl_offs)
  * Returns true if the module's CM_*_CLKCTRL.IDLEST bitfield is either
  * *FUNCTIONAL or *INTERFACE_IDLE; false otherwise.
  */
-static bool _is_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
+static bool _is_module_ready(u16 inst, u16 cdoffs, u16 clkctrl_offs)
 {
 	u32 v;
 
@@ -138,7 +138,7 @@ static bool _is_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
  * @c must be the unshifted value for CLKTRCTRL - i.e., this function
  * will handle the shift itself.
  */
-static void _clktrctrl_write(u8 c, s16 inst, u16 cdoffs)
+static void _clktrctrl_write(u8 c, u16 inst, u16 cdoffs)
 {
 	u32 v;
 
@@ -158,7 +158,7 @@ static void _clktrctrl_write(u8 c, s16 inst, u16 cdoffs)
  * Returns true if the clockdomain referred to by (@inst, @cdoffs)
  * is in hardware-supervised idle mode, or 0 otherwise.
  */
-bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs)
+bool am33xx_cm_is_clkdm_in_hwsup(u16 inst, u16 cdoffs)
 {
 	u32 v;
 
@@ -177,7 +177,7 @@ bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs)
  * Put a clockdomain referred to by (@inst, @cdoffs) into
  * hardware-supervised idle mode.  No return value.
  */
-void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_enable_hwsup(u16 inst, u16 cdoffs)
 {
 	_clktrctrl_write(OMAP34XX_CLKSTCTRL_ENABLE_AUTO, inst, cdoffs);
 }
@@ -191,7 +191,7 @@ void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs)
  * software-supervised idle mode, i.e., controlled manually by the
  * Linux OMAP clockdomain code.  No return value.
  */
-void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_disable_hwsup(u16 inst, u16 cdoffs)
 {
 	_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, inst, cdoffs);
 }
@@ -204,7 +204,7 @@ void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs)
  * Put a clockdomain referred to by (@inst, @cdoffs) into idle
  * No return value.
  */
-void am33xx_cm_clkdm_force_sleep(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_force_sleep(u16 inst, u16 cdoffs)
 {
 	_clktrctrl_write(OMAP34XX_CLKSTCTRL_FORCE_SLEEP, inst, cdoffs);
 }
@@ -217,7 +217,7 @@ void am33xx_cm_clkdm_force_sleep(s16 inst, u16 cdoffs)
  * Take a clockdomain referred to by (@inst, @cdoffs) out of idle,
  * waking it up.  No return value.
  */
-void am33xx_cm_clkdm_force_wakeup(s16 inst, u16 cdoffs)
+void am33xx_cm_clkdm_force_wakeup(u16 inst, u16 cdoffs)
 {
 	_clktrctrl_write(OMAP34XX_CLKSTCTRL_FORCE_WAKEUP, inst, cdoffs);
 }
@@ -237,7 +237,7 @@ void am33xx_cm_clkdm_force_wakeup(s16 inst, u16 cdoffs)
  * sysconfig cannot be accessed and will probably lead to an "imprecise
  * external abort"
  */
-int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
+int am33xx_cm_wait_module_ready(u16 inst, u16 cdoffs, u16 clkctrl_offs)
 {
 	int i = 0;
 
@@ -258,7 +258,7 @@ int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
  * like reset assertion or parent clock de-activation must wait the
  * module to be fully disabled.
  */
-int am33xx_cm_wait_module_idle(u16 inst, s16 cdoffs, u16 clkctrl_offs)
+int am33xx_cm_wait_module_idle(u16 inst, u16 cdoffs, u16 clkctrl_offs)
 {
 	int i = 0;
 
@@ -281,7 +281,7 @@ int am33xx_cm_wait_module_idle(u16 inst, s16 cdoffs, u16 clkctrl_offs)
  *
  * No return value.
  */
-void am33xx_cm_module_enable(u8 mode, u16 inst, s16 cdoffs, u16 clkctrl_offs)
+void am33xx_cm_module_enable(u8 mode, u16 inst, u16 cdoffs, u16 clkctrl_offs)
 {
 	u32 v;
 
@@ -299,7 +299,7 @@ void am33xx_cm_module_enable(u8 mode, u16 inst, s16 cdoffs, u16 clkctrl_offs)
  *
  * No return value.
  */
-void am33xx_cm_module_disable(u16 inst, s16 cdoffs, u16 clkctrl_offs)
+void am33xx_cm_module_disable(u16 inst, u16 cdoffs, u16 clkctrl_offs)
 {
 	u32 v;
 
diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h
index 9d1f4fc..201e507 100644
--- a/arch/arm/mach-omap2/cm33xx.h
+++ b/arch/arm/mach-omap2/cm33xx.h
@@ -377,36 +377,36 @@
 
 
 #ifndef __ASSEMBLER__
-extern bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs);
-extern void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs);
-extern void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs);
-extern void am33xx_cm_clkdm_force_sleep(s16 inst, u16 cdoffs);
-extern void am33xx_cm_clkdm_force_wakeup(s16 inst, u16 cdoffs);
+extern bool am33xx_cm_is_clkdm_in_hwsup(u16 inst, u16 cdoffs);
+extern void am33xx_cm_clkdm_enable_hwsup(u16 inst, u16 cdoffs);
+extern void am33xx_cm_clkdm_disable_hwsup(u16 inst, u16 cdoffs);
+extern void am33xx_cm_clkdm_force_sleep(u16 inst, u16 cdoffs);
+extern void am33xx_cm_clkdm_force_wakeup(u16 inst, u16 cdoffs);
 
 #if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX)
-extern int am33xx_cm_wait_module_idle(u16 inst, s16 cdoffs,
+extern int am33xx_cm_wait_module_idle(u16 inst, u16 cdoffs,
 					u16 clkctrl_offs);
-extern void am33xx_cm_module_enable(u8 mode, u16 inst, s16 cdoffs,
+extern void am33xx_cm_module_enable(u8 mode, u16 inst, u16 cdoffs,
 					u16 clkctrl_offs);
-extern void am33xx_cm_module_disable(u16 inst, s16 cdoffs,
+extern void am33xx_cm_module_disable(u16 inst, u16 cdoffs,
 					u16 clkctrl_offs);
-extern int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs,
+extern int am33xx_cm_wait_module_ready(u16 inst, u16 cdoffs,
 					u16 clkctrl_offs);
 #else
-static inline int am33xx_cm_wait_module_idle(u16 inst, s16 cdoffs,
+static inline int am33xx_cm_wait_module_idle(u16 inst, u16 cdoffs,
 					u16 clkctrl_offs)
 {
 	return 0;
 }
-static inline void am33xx_cm_module_enable(u8 mode, u16 inst, s16 cdoffs,
+static inline void am33xx_cm_module_enable(u8 mode, u16 inst, u16 cdoffs,
 					u16 clkctrl_offs)
 {
 }
-static inline void am33xx_cm_module_disable(u16 inst, s16 cdoffs,
+static inline void am33xx_cm_module_disable(u16 inst, u16 cdoffs,
 					u16 clkctrl_offs)
 {
 }
-static inline int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs,
+static inline int am33xx_cm_wait_module_ready(u16 inst, u16 cdoffs,
 					u16 clkctrl_offs)
 {
 	return 0;
diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c
index 4ec9712..20e85b8 100644
--- a/arch/arm/mach-omap2/cminst44xx.c
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -80,7 +80,7 @@ void omap_cm_base_init(void)
  * Return the IDLEST bitfield of a CM_*_CLKCTRL register, shifted down to
  * bit 0.
  */
-static u32 _clkctrl_idlest(u8 part, u16 inst, s16 cdoffs, u16 clkctrl_offs)
+static u32 _clkctrl_idlest(u8 part, u16 inst, u16 cdoffs, u16 clkctrl_offs)
 {
 	u32 v = omap4_cminst_read_inst_reg(part, inst, clkctrl_offs);
 	v &= OMAP4430_IDLEST_MASK;
@@ -98,7 +98,7 @@ static u32 _clkctrl_idlest(u8 part, u16 inst, s16 cdoffs, u16 clkctrl_offs)
  * Returns true if the module's CM_*_CLKCTRL.IDLEST bitfield is either
  * *FUNCTIONAL or *INTERFACE_IDLE; false otherwise.
  */
-static bool _is_module_ready(u8 part, u16 inst, s16 cdoffs, u16 clkctrl_offs)
+static bool _is_module_ready(u8 part, u16 inst, u16 cdoffs, u16 clkctrl_offs)
 {
 	u32 v;
 
@@ -111,7 +111,7 @@ static bool _is_module_ready(u8 part, u16 inst, s16 cdoffs, u16 clkctrl_offs)
 /* Public functions */
 
 /* Read a register in a CM instance */
-u32 omap4_cminst_read_inst_reg(u8 part, s16 inst, u16 idx)
+u32 omap4_cminst_read_inst_reg(u8 part, u16 inst, u16 idx)
 {
 	BUG_ON(part >= OMAP4_MAX_PRCM_PARTITIONS ||
 	       part == OMAP4430_INVALID_PRCM_PARTITION ||
@@ -120,7 +120,7 @@ u32 omap4_cminst_read_inst_reg(u8 part, s16 inst, u16 idx)
 }
 
 /* Write into a register in a CM instance */
-void omap4_cminst_write_inst_reg(u32 val, u8 part, s16 inst, u16 idx)
+void omap4_cminst_write_inst_reg(u32 val, u8 part, u16 inst, u16 idx)
 {
 	BUG_ON(part >= OMAP4_MAX_PRCM_PARTITIONS ||
 	       part == OMAP4430_INVALID_PRCM_PARTITION ||
@@ -152,7 +152,7 @@ u32 omap4_cminst_clear_inst_reg_bits(u32 bits, u8 part, s16 inst, s16 idx)
 	return omap4_cminst_rmw_inst_reg_bits(bits, 0x0, part, inst, idx);
 }
 
-u32 omap4_cminst_read_inst_reg_bits(u8 part, u16 inst, s16 idx, u32 mask)
+u32 omap4_cminst_read_inst_reg_bits(u8 part, u16 inst, u16 idx, u32 mask)
 {
 	u32 v;
 
@@ -177,7 +177,7 @@ u32 omap4_cminst_read_inst_reg_bits(u8 part, u16 inst, s16 idx, u32 mask)
  * @c must be the unshifted value for CLKTRCTRL - i.e., this function
  * will handle the shift itself.
  */
-static void _clktrctrl_write(u8 c, u8 part, s16 inst, u16 cdoffs)
+static void _clktrctrl_write(u8 c, u8 part, u16 inst, u16 cdoffs)
 {
 	u32 v;
 
@@ -196,7 +196,7 @@ static void _clktrctrl_write(u8 c, u8 part, s16 inst, u16 cdoffs)
  * Returns true if the clockdomain referred to by (@part, @inst, @cdoffs)
  * is in hardware-supervised idle mode, or 0 otherwise.
  */
-bool omap4_cminst_is_clkdm_in_hwsup(u8 part, s16 inst, u16 cdoffs)
+bool omap4_cminst_is_clkdm_in_hwsup(u8 part, u16 inst, u16 cdoffs)
 {
 	u32 v;
 
@@ -216,7 +216,7 @@ bool omap4_cminst_is_clkdm_in_hwsup(u8 part, s16 inst, u16 cdoffs)
  * Put a clockdomain referred to by (@part, @inst, @cdoffs) into
  * hardware-supervised idle mode.  No return value.
  */
-void omap4_cminst_clkdm_enable_hwsup(u8 part, s16 inst, u16 cdoffs)
+void omap4_cminst_clkdm_enable_hwsup(u8 part, u16 inst, u16 cdoffs)
 {
 	_clktrctrl_write(OMAP34XX_CLKSTCTRL_ENABLE_AUTO, part, inst, cdoffs);
 }
@@ -231,7 +231,7 @@ void omap4_cminst_clkdm_enable_hwsup(u8 part, s16 inst, u16 cdoffs)
  * software-supervised idle mode, i.e., controlled manually by the
  * Linux OMAP clockdomain code.  No return value.
  */
-void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
+void omap4_cminst_clkdm_disable_hwsup(u8 part, u16 inst, u16 cdoffs)
 {
 	_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
 }
@@ -245,7 +245,7 @@ void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
  * Take a clockdomain referred to by (@part, @inst, @cdoffs) out of idle,
  * waking it up.  No return value.
  */
-void omap4_cminst_clkdm_force_wakeup(u8 part, s16 inst, u16 cdoffs)
+void omap4_cminst_clkdm_force_wakeup(u8 part, u16 inst, u16 cdoffs)
 {
 	_clktrctrl_write(OMAP34XX_CLKSTCTRL_FORCE_WAKEUP, part, inst, cdoffs);
 }
@@ -280,7 +280,7 @@ void omap4_cminst_clkdm_force_sleep(u8 part, s16 inst, u16 cdoffs)
  * sysconfig cannot be accessed and will probably lead to an "imprecise
  * external abort"
  */
-int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs,
+int omap4_cminst_wait_module_ready(u8 part, u16 inst, u16 cdoffs,
 				   u16 clkctrl_offs)
 {
 	int i = 0;
@@ -303,7 +303,8 @@ int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs,
  * like reset assertion or parent clock de-activation must wait the
  * module to be fully disabled.
  */
-int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs, u16 clkctrl_offs)
+int omap4_cminst_wait_module_idle(u8 part, u16 inst,
+				  u16 cdoffs, u16 clkctrl_offs)
 {
 	int i = 0;
 
@@ -324,7 +325,7 @@ int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs, u16 clkctrl_off
  *
  * No return value.
  */
-void omap4_cminst_module_enable(u8 mode, u8 part, u16 inst, s16 cdoffs,
+void omap4_cminst_module_enable(u8 mode, u8 part, u16 inst, u16 cdoffs,
 			    u16 clkctrl_offs)
 {
 	u32 v;
@@ -344,7 +345,7 @@ void omap4_cminst_module_enable(u8 mode, u8 part, u16 inst, s16 cdoffs,
  *
  * No return value.
  */
-void omap4_cminst_module_disable(u8 part, u16 inst, s16 cdoffs,
+void omap4_cminst_module_disable(u8 part, u16 inst, u16 cdoffs,
 			     u16 clkctrl_offs)
 {
 	u32 v;
diff --git a/arch/arm/mach-omap2/cminst44xx.h b/arch/arm/mach-omap2/cminst44xx.h
index bd7bab8..dee2af5 100644
--- a/arch/arm/mach-omap2/cminst44xx.h
+++ b/arch/arm/mach-omap2/cminst44xx.h
@@ -11,31 +11,32 @@
 #ifndef __ARCH_ASM_MACH_OMAP2_CMINST44XX_H
 #define __ARCH_ASM_MACH_OMAP2_CMINST44XX_H
 
-extern bool omap4_cminst_is_clkdm_in_hwsup(u8 part, s16 inst, u16 cdoffs);
-extern void omap4_cminst_clkdm_enable_hwsup(u8 part, s16 inst, u16 cdoffs);
-extern void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs);
-extern void omap4_cminst_clkdm_force_sleep(u8 part, s16 inst, u16 cdoffs);
-extern void omap4_cminst_clkdm_force_wakeup(u8 part, s16 inst, u16 cdoffs);
-extern int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs, u16 clkctrl_offs);
-extern int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs,
+extern bool omap4_cminst_is_clkdm_in_hwsup(u8 part, u16 inst, u16 cdoffs);
+extern void omap4_cminst_clkdm_enable_hwsup(u8 part, u16 inst, u16 cdoffs);
+extern void omap4_cminst_clkdm_disable_hwsup(u8 part, u16 inst, u16 cdoffs);
+extern void omap4_cminst_clkdm_force_sleep(u8 part, u16 inst, u16 cdoffs);
+extern void omap4_cminst_clkdm_force_wakeup(u8 part, u16 inst, u16 cdoffs);
+extern int omap4_cminst_wait_module_ready(u8 part, u16 inst,
+					  u16 cdoffs, u16 clkctrl_offs);
+extern int omap4_cminst_wait_module_idle(u8 part, u16 inst, u16 cdoffs,
 					 u16 clkctrl_offs);
-extern void omap4_cminst_module_enable(u8 mode, u8 part, u16 inst, s16 cdoffs,
+extern void omap4_cminst_module_enable(u8 mode, u8 part, u16 inst, u16 cdoffs,
 				       u16 clkctrl_offs);
-extern void omap4_cminst_module_disable(u8 part, u16 inst, s16 cdoffs,
+extern void omap4_cminst_module_disable(u8 part, u16 inst, u16 cdoffs,
 					u16 clkctrl_offs);
 /*
  * In an ideal world, we would not export these low-level functions,
  * but this will probably take some time to fix properly
  */
-extern u32 omap4_cminst_read_inst_reg(u8 part, s16 inst, u16 idx);
-extern void omap4_cminst_write_inst_reg(u32 val, u8 part, s16 inst, u16 idx);
+extern u32 omap4_cminst_read_inst_reg(u8 part, u16 inst, u16 idx);
+extern void omap4_cminst_write_inst_reg(u32 val, u8 part, u16 inst, u16 idx);
 extern u32 omap4_cminst_rmw_inst_reg_bits(u32 mask, u32 bits, u8 part,
 					   s16 inst, s16 idx);
 extern u32 omap4_cminst_set_inst_reg_bits(u32 bits, u8 part, s16 inst,
 					   s16 idx);
 extern u32 omap4_cminst_clear_inst_reg_bits(u32 bits, u8 part, s16 inst,
 					   s16 idx);
-extern u32 omap4_cminst_read_inst_reg_bits(u8 part, u16 inst, s16 idx,
+extern u32 omap4_cminst_read_inst_reg_bits(u8 part, u16 inst, u16 idx,
 					   u32 mask);
 
 extern void omap_cm_base_init(void);
-- 
1.8.3.1



From afzal at ti.com  Thu Jul 11 02:35:56 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 11 Jul 2013 12:05:56 +0530
Subject: [PATCH RFC 05/13] ARM: OMAP2+: PRCM: AM43x definitions
In-Reply-To: <cover.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
Message-ID: <0fc8041bbc24c462701055835bb09c05c36dff10.1373519192.git.afzal@ti.com>

Add AM43x CMINST, CDOFFS, RM_RSTST & RM_RSTCTRL definitions - minimal
ones that would be used.

Signed-off-by: Afzal Mohammed <afzal at ti.com>
---
 arch/arm/mach-omap2/prcm43xx.h | 148 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 148 insertions(+)
 create mode 100644 arch/arm/mach-omap2/prcm43xx.h

diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
new file mode 100644
index 0000000..0d05278
--- /dev/null
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -0,0 +1,148 @@
+/*
+ * AM43x PRCM defines
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_PRCM_43XX_H
+#define __ARCH_ARM_MACH_OMAP2_PRCM_43XX_H
+
+#define AM43XX_PRM_PARTITION                   1
+#define AM43XX_CM_PARTITION                    1
+
+/* PRM instances */
+#define AM43XX_PRM_OCP_SOCKET_INST	0x0000
+#define AM43XX_PRM_MPU_INST		0x0300
+#define AM43XX_PRM_GFX_INST		0x0400
+#define AM43XX_PRM_RTC_INST		0x0500
+#define AM43XX_PRM_TAMPER_INST		0x0600
+#define AM43XX_PRM_CEFUSE_INST		0x0700
+#define AM43XX_PRM_PER_INST		0x0800
+#define AM43XX_PRM_WKUP_INST		0x2000
+#define AM43XX_PRM_DEVICE_INST		0x4000
+
+/* RM RSTCTRL offsets */
+#define	AM43XX_RM_PER_RSTCTRL_OFFSET	0x0010
+#define	AM43XX_RM_GFX_RSTCTRL_OFFSET	0x0010
+#define	AM43XX_RM_WKUP_RSTCTRL_OFFSET	0x0010
+
+/* RM RSTST offsets */
+#define	AM43XX_RM_GFX_RSTST_OFFSET	0x0014
+#define	AM43XX_RM_WKUP_RSTST_OFFSET	0x0014
+
+/* CM instances */
+#define AM43XX_CM_WKUP_INST	0x2800
+#define AM43XX_CM_DEVICE_INST	0x4100
+#define AM43XX_CM_DPLL_INST	0x4200
+#define AM43XX_CM_MPU_INST	0x8300
+#define AM43XX_CM_GFX_INST	0x8400
+#define AM43XX_CM_RTC_INST	0x8500
+#define AM43XX_CM_TAMPER_INST	0x8600
+#define AM43XX_CM_CEFUSE_INST	0x8700
+#define AM43XX_CM_PER_INST	0x8800
+
+/* CD offsets */
+#define AM43XX_CM_WKUP_L3_AON_CDOFFS		0x0000
+#define AM43XX_CM_WKUP_L3S_TSC_CDOFFS		0x0100
+#define AM43XX_CM_WKUP_L4_WKUP_AON_CDOFFS	0x0200
+#define AM43XX_CM_WKUP_WKUP_CDOFFS		0x0300
+#define AM43XX_CM_MPU_MPU_CDOFFS		0x0000
+#define AM43XX_CM_GFX_GFX_L3_CDOFFS		0x0000
+#define AM43XX_CM_RTC_RTC_CDOFFS		0x0000
+#define AM43XX_CM_TAMPER_TAMPER_CDOFFS		0x0000
+#define AM43XX_CM_CEFUSE_CEFUSE_CDOFFS		0x0000
+#define AM43XX_CM_PER_L3_CDOFFS			0x0000
+#define AM43XX_CM_PER_L3S_CDOFFS		0x0200
+#define AM43XX_CM_PER_ICSS_CDOFFS		0x0300
+#define AM43XX_CM_PER_L4LS_CDOFFS		0x0400
+#define AM43XX_CM_PER_EMIF_CDOFFS		0x0700
+#define AM43XX_CM_PER_LCDC_CDOFFS		0x0800
+#define AM43XX_CM_PER_DSS_CDOFFS		0x0a00
+#define AM43XX_CM_PER_CPSW_CDOFFS		0x0b00
+#define AM43XX_CM_PER_OCPWP_L3_CDOFFS		0x0c00
+
+/* CLK CTRL offsets */
+#define	AM43XX_CM_PER_UART1_CLKCTRL_OFFSET		0x0580
+#define	AM43XX_CM_PER_UART2_CLKCTRL_OFFSET		0x0588
+#define	AM43XX_CM_PER_UART3_CLKCTRL_OFFSET		0x0590
+#define	AM43XX_CM_PER_UART4_CLKCTRL_OFFSET		0x0598
+#define	AM43XX_CM_PER_UART5_CLKCTRL_OFFSET		0x05a0
+#define	AM43XX_CM_PER_DCAN0_CLKCTRL_OFFSET		0x0428
+#define	AM43XX_CM_PER_DCAN1_CLKCTRL_OFFSET		0x0430
+#define	AM43XX_CM_PER_ELM_CLKCTRL_OFFSET		0x0468
+#define	AM43XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET		0x0438
+#define	AM43XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET		0x0440
+#define	AM43XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET		0x0448
+#define	AM43XX_CM_PER_GPIO1_CLKCTRL_OFFSET		0x0478
+#define	AM43XX_CM_PER_GPIO2_CLKCTRL_OFFSET		0x0480
+#define	AM43XX_CM_PER_GPIO3_CLKCTRL_OFFSET		0x0488
+#define	AM43XX_CM_PER_I2C1_CLKCTRL_OFFSET		0x04a8
+#define	AM43XX_CM_PER_I2C2_CLKCTRL_OFFSET		0x04b0
+#define	AM43XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET		0x04b8
+#define	AM43XX_CM_PER_MMC0_CLKCTRL_OFFSET		0x04c0
+#define	AM43XX_CM_PER_MMC1_CLKCTRL_OFFSET		0x04c8
+#define	AM43XX_CM_PER_SPI0_CLKCTRL_OFFSET		0x0500
+#define	AM43XX_CM_PER_SPI1_CLKCTRL_OFFSET		0x0508
+#define	AM43XX_CM_PER_SPINLOCK_CLKCTRL_OFFSET		0x0528
+#define	AM43XX_CM_PER_TIMER2_CLKCTRL_OFFSET		0x0530
+#define	AM43XX_CM_PER_TIMER3_CLKCTRL_OFFSET		0x0538
+#define	AM43XX_CM_PER_TIMER4_CLKCTRL_OFFSET		0x0540
+#define	AM43XX_CM_PER_TIMER5_CLKCTRL_OFFSET		0x0548
+#define	AM43XX_CM_PER_TIMER6_CLKCTRL_OFFSET		0x0550
+#define	AM43XX_CM_PER_TIMER7_CLKCTRL_OFFSET		0x0558
+#define	AM43XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET		0x0228
+#define	AM43XX_CM_WKUP_CONTROL_CLKCTRL_OFFSET		0x0360
+#define	AM43XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET	0x0350
+#define	AM43XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET	0x0358
+#define	AM43XX_CM_WKUP_UART0_CLKCTRL_OFFSET		0x0348
+#define	AM43XX_CM_WKUP_TIMER1_CLKCTRL_OFFSET		0x0328
+#define	AM43XX_CM_WKUP_I2C0_CLKCTRL_OFFSET		0x0340
+#define	AM43XX_CM_WKUP_GPIO0_CLKCTRL_OFFSET		0x0368
+#define	AM43XX_CM_WKUP_ADC_TSC_CLKCTRL_OFFSET		0x0120
+#define	AM43XX_CM_WKUP_WDT1_CLKCTRL_OFFSET		0x0338
+#define	AM43XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET		0x0220
+#define	AM43XX_CM_RTC_RTC_CLKCTRL_OFFSET		0x0020
+#define	AM43XX_CM_PER_MMC2_CLKCTRL_OFFSET		0x0248
+#define	AM43XX_CM_PER_GPMC_CLKCTRL_OFFSET		0x0220
+#define	AM43XX_CM_PER_MCASP0_CLKCTRL_OFFSET		0x0238
+#define	AM43XX_CM_PER_MCASP1_CLKCTRL_OFFSET		0x0240
+#define	AM43XX_CM_PER_L4LS_CLKCTRL_OFFSET		0x0420
+#define	AM43XX_CM_PER_L3_CLKCTRL_OFFSET			0x0020
+#define	AM43XX_CM_PER_TPCC_CLKCTRL_OFFSET		0x0078
+#define	AM43XX_CM_PER_TPTC0_CLKCTRL_OFFSET		0x0080
+#define	AM43XX_CM_PER_TPTC1_CLKCTRL_OFFSET		0x0088
+#define	AM43XX_CM_PER_TPTC2_CLKCTRL_OFFSET		0x0090
+#define	AM43XX_CM_PER_CPGMAC0_CLKCTRL_OFFSET		0x0b20
+#define	AM43XX_CM_PER_PRUSS_CLKCTRL_OFFSET		0x0320
+#define	AM43XX_CM_GFX_GFX_CLKCTRL_OFFSET		0x0020
+#define	AM43XX_CM_PER_L4HS_CLKCTRL_OFFSET		0x00a0
+#define	AM43XX_CM_PER_EMIF_CLKCTRL_OFFSET		0x0720
+#define	AM43XX_CM_MPU_MPU_CLKCTRL_OFFSET		0x0020
+#define	AM43XX_CM_PER_L3_INSTR_CLKCTRL_OFFSET		0x0040
+#define	AM43XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET		0x0050
+#define	AM43XX_CM_PER_SHA0_CLKCTRL_OFFSET		0x0058
+#define	AM43XX_CM_PER_AES0_CLKCTRL_OFFSET		0x0028
+#define	AM43XX_CM_PER_QSPI_CLKCTRL_OFFSET		0x0258
+#define	AM43XX_CM_PER_HDQ1W_CLKCTRL_OFFSET		0x04a0
+#define	AM43XX_CM_PER_VPFE0_CLKCTRL_OFFSET		0x0068
+#define	AM43XX_CM_PER_VPFE1_CLKCTRL_OFFSET		0x0070
+#define	AM43XX_CM_PER_PKA_CLKCTRL_OFFSET		0x04d0
+#define	AM43XX_CM_PER_DES_CLKCTRL_OFFSET		0x0030
+#define	AM43XX_CM_PER_RNG_CLKCTRL_OFFSET		0x04e0
+#define	AM43XX_CM_PER_TIMER8_CLKCTRL_OFFSET		0x0560
+#define	AM43XX_CM_PER_TIMER9_CLKCTRL_OFFSET		0x0568
+#define	AM43XX_CM_PER_TIMER10_CLKCTRL_OFFSET		0x0570
+#define	AM43XX_CM_PER_TIMER11_CLKCTRL_OFFSET		0x0578
+#define	AM43XX_CM_WKUP_SYNCTIMER_CLKCTRL_OFFSET		0x0230
+#define	AM43XX_CM_PER_EPWMSS3_CLKCTRL_OFFSET		0x0450
+#define	AM43XX_CM_PER_EPWMSS4_CLKCTRL_OFFSET		0x0458
+#define	AM43XX_CM_PER_EPWMSS5_CLKCTRL_OFFSET		0x0460
+#define	AM43XX_CM_PER_SPI2_CLKCTRL_OFFSET		0x0510
+#define	AM43XX_CM_PER_SPI3_CLKCTRL_OFFSET		0x0518
+#define	AM43XX_CM_PER_SPI4_CLKCTRL_OFFSET		0x0520
+
+#endif
-- 
1.8.3.1



From afzal at ti.com  Thu Jul 11 02:36:04 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 11 Jul 2013 12:06:04 +0530
Subject: [PATCH RFC 06/13] ARM: OMAP2+: PM: AM43x powerdomain data
In-Reply-To: <cover.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
Message-ID: <e0b01a22734bde5cf8888de873c7da32aa69fe45.1373519192.git.afzal@ti.com>

From: Ambresh K <ambresh at ti.com>

Add the data file to describe all power domains in AM43x SoC.

Signed-off-by: Ambresh K <ambresh at ti.com>
Signed-off-by: Afzal Mohammed <afzal at ti.com>
---

Note: domain operations to be used would have to modified as mentioned in
	the cover letter

 arch/arm/mach-omap2/powerdomain.h           |   1 +
 arch/arm/mach-omap2/powerdomains43xx_data.c | 145 ++++++++++++++++++++++++++++
 2 files changed, 146 insertions(+)
 create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c

diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h
index e4d7bd6..56ad9f5 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -254,6 +254,7 @@ extern void omap242x_powerdomains_init(void);
 extern void omap243x_powerdomains_init(void);
 extern void omap3xxx_powerdomains_init(void);
 extern void am33xx_powerdomains_init(void);
+extern void am43xx_powerdomains_init(void);
 extern void omap44xx_powerdomains_init(void);
 extern void omap54xx_powerdomains_init(void);
 
diff --git a/arch/arm/mach-omap2/powerdomains43xx_data.c b/arch/arm/mach-omap2/powerdomains43xx_data.c
new file mode 100644
index 0000000..35d8dbb
--- /dev/null
+++ b/arch/arm/mach-omap2/powerdomains43xx_data.c
@@ -0,0 +1,145 @@
+/*
+ * AM43xx Power domains framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This file is made by modifying the file generated automatically
+ * from the OMAP hardware databases.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+
+#include "powerdomain.h"
+
+#include "prcm-common.h"
+#include "prcm44xx.h"
+#include "prcm43xx.h"
+
+static struct powerdomain gfx_43xx_pwrdm = {
+	.name		  = "gfx_pwrdm",
+	.voltdm		  = { .name = "core" },
+	.prcm_offs	  = AM43XX_PRM_GFX_INST,
+	.prcm_partition	  = AM43XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* gfx_mem */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_ON,	/* gfx_mem */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+static struct powerdomain mpu_43xx_pwrdm = {
+	.name		  = "mpu_pwrdm",
+	.voltdm		  = { .name = "mpu" },
+	.prcm_offs	  = AM43XX_PRM_MPU_INST,
+	.prcm_partition	  = AM43XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 3,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* mpu_l1 */
+		[1] = PWRSTS_OFF_RET,	/* mpu_l2 */
+		[2] = PWRSTS_OFF_RET,	/* mpu_ram */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_ON,	/* mpu_l1 */
+		[1] = PWRSTS_ON,	/* mpu_l2 */
+		[2] = PWRSTS_ON,	/* mpu_ram */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+static struct powerdomain rtc_43xx_pwrdm = {
+	.name		  = "rtc_pwrdm",
+	.voltdm		  = { .name = "rtc" },
+	.prcm_offs	  = AM43XX_PRM_RTC_INST,
+	.prcm_partition	  = AM43XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_ON,
+};
+
+static struct powerdomain wkup_43xx_pwrdm = {
+	.name		  = "wkup_pwrdm",
+	.voltdm		  = { .name = "core" },
+	.prcm_offs	  = AM43XX_PRM_WKUP_INST,
+	.prcm_partition	  = AM43XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_ON,
+	.banks		  = 1,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF,	/* debugss_mem */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_ON,	/* debugss_mem */
+	},
+};
+
+static struct powerdomain tamper_43xx_pwrdm = {
+	.name		  = "tamper_pwrdm",
+	.voltdm		  = { .name = "tamper" },
+	.prcm_offs	  = AM43XX_PRM_TAMPER_INST,
+	.prcm_partition	  = AM43XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_ON,
+};
+
+static struct powerdomain cefuse_43xx_pwrdm = {
+	.name		  = "cefuse_pwrdm",
+	.voltdm		  = { .name = "core" },
+	.prcm_offs	  = AM43XX_PRM_CEFUSE_INST,
+	.prcm_partition	  = AM43XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_ON,
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+static struct powerdomain per_43xx_pwrdm = {
+	.name		  = "per_pwrdm",
+	.voltdm		  = { .name = "core" },
+	.prcm_offs	  = AM43XX_PRM_PER_INST,
+	.prcm_partition	  = AM43XX_PRM_PARTITION,
+	.pwrsts		  = PWRSTS_OFF_RET_ON,
+	.pwrsts_logic_ret = PWRSTS_OFF_RET,
+	.banks		  = 4,
+	.pwrsts_mem_ret	= {
+		[0] = PWRSTS_OFF_RET,	/* icss_mem */
+		[1] = PWRSTS_OFF_RET,	/* per_mem */
+		[2] = PWRSTS_OFF_RET,	/* ram1_mem */
+		[3] = PWRSTS_OFF_RET,	/* ram2_mem */
+	},
+	.pwrsts_mem_on	= {
+		[0] = PWRSTS_OFF_RET,	/* icss_mem */
+		[1] = PWRSTS_ON,	/* per_mem */
+		[2] = PWRSTS_OFF_RET,	/* ram1_mem */
+		[3] = PWRSTS_OFF_RET,	/* ram2_mem */
+	},
+	.flags		  = PWRDM_HAS_LOWPOWERSTATECHANGE,
+};
+
+static int am43xx_check_vcvp(void)
+{
+	return 0;
+}
+
+static struct powerdomain *powerdomains_am43xx[] __initdata = {
+	&gfx_43xx_pwrdm,
+	&mpu_43xx_pwrdm,
+	&rtc_43xx_pwrdm,
+	&wkup_43xx_pwrdm,
+	&tamper_43xx_pwrdm,
+	&cefuse_43xx_pwrdm,
+	&per_43xx_pwrdm,
+	NULL
+};
+
+void __init am43xx_powerdomains_init(void)
+{
+	omap4_pwrdm_operations.pwrdm_has_voltdm = am43xx_check_vcvp;
+	pwrdm_register_platform_funcs(&omap4_pwrdm_operations);
+	pwrdm_register_pwrdms(powerdomains_am43xx);
+	pwrdm_complete_init();
+}
-- 
1.8.3.1



From afzal at ti.com  Thu Jul 11 02:36:12 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 11 Jul 2013 12:06:12 +0530
Subject: [PATCH RFC 07/13] ARM: OMAP2+: CM: AM43x clockdomain data
In-Reply-To: <cover.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
Message-ID: <cc28ac4f840bdef5816423b576af623972b137d9.1373519192.git.afzal@ti.com>

From: Ambresh K <ambresh at ti.com>

Add the data file to describe clock domains in AM43x SoC.

Signed-off-by: Ambresh K <ambresh at ti.com>
Signed-off-by: Afzal Mohammed <afzal at ti.com>
---

Note: domain operations to be used would have to modified as mentioned in
	the cover letter

 arch/arm/mach-omap2/clockdomain.h           |   1 +
 arch/arm/mach-omap2/clockdomains43xx_data.c | 199 ++++++++++++++++++++++++++++
 2 files changed, 200 insertions(+)
 create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c

diff --git a/arch/arm/mach-omap2/clockdomain.h b/arch/arm/mach-omap2/clockdomain.h
index 8c22ce6..3b61557 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -215,6 +215,7 @@ extern void __init omap242x_clockdomains_init(void);
 extern void __init omap243x_clockdomains_init(void);
 extern void __init omap3xxx_clockdomains_init(void);
 extern void __init am33xx_clockdomains_init(void);
+extern void am43xx_clockdomains_init(void);
 extern void __init omap44xx_clockdomains_init(void);
 extern void __init omap54xx_clockdomains_init(void);
 
diff --git a/arch/arm/mach-omap2/clockdomains43xx_data.c b/arch/arm/mach-omap2/clockdomains43xx_data.c
new file mode 100644
index 0000000..5ddc010
--- /dev/null
+++ b/arch/arm/mach-omap2/clockdomains43xx_data.c
@@ -0,0 +1,199 @@
+/*
+ * AM43xx Clock domains framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This file is made by modifying the file generated automatically
+ * from the OMAP hardware databases.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/io.h>
+
+#include "clockdomain.h"
+#include "prcm44xx.h"
+#include "prcm43xx.h"
+
+static struct clockdomain l4_cefuse_43xx_clkdm = {
+	.name		  = "l4_cefuse_clkdm",
+	.pwrdm		  = { .name = "cefuse_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_CEFUSE_INST,
+	.clkdm_offs	  = AM43XX_CM_CEFUSE_CEFUSE_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain mpu_43xx_clkdm = {
+	.name		  = "mpu_clkdm",
+	.pwrdm		  = { .name = "mpu_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_MPU_INST,
+	.clkdm_offs	  = AM43XX_CM_MPU_MPU_CDOFFS,
+	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+};
+
+static struct clockdomain l4ls_43xx_clkdm = {
+	.name		  = "l4ls_clkdm",
+	.pwrdm		  = { .name = "per_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_PER_INST,
+	.clkdm_offs	  = AM43XX_CM_PER_L4LS_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain tamper_43xx_clkdm = {
+	.name		  = "tamper_clkdm",
+	.pwrdm		  = { .name = "tamper_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_TAMPER_INST,
+	.clkdm_offs	  = AM43XX_CM_TAMPER_TAMPER_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain l4_rtc_43xx_clkdm = {
+	.name		  = "l4_rtc_clkdm",
+	.pwrdm		  = { .name = "rtc_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_RTC_INST,
+	.clkdm_offs	  = AM43XX_CM_RTC_RTC_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain pruss_ocp_43xx_clkdm = {
+	.name		  = "pruss_ocp_clkdm",
+	.pwrdm		  = { .name = "per_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_PER_INST,
+	.clkdm_offs	  = AM43XX_CM_PER_ICSS_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain ocpwp_l3_43xx_clkdm = {
+	.name		  = "ocpwp_l3_clkdm",
+	.pwrdm		  = { .name = "per_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_PER_INST,
+	.clkdm_offs	  = AM43XX_CM_PER_OCPWP_L3_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain l3s_tsc_43xx_clkdm = {
+	.name		  = "l3s_tsc_clkdm",
+	.pwrdm		  = { .name = "wkup_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_WKUP_INST,
+	.clkdm_offs	  = AM43XX_CM_WKUP_L3S_TSC_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain dss_43xx_clkdm = {
+	.name		  = "dss_clkdm",
+	.pwrdm		  = { .name = "per_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_PER_INST,
+	.clkdm_offs	  = AM43XX_CM_PER_DSS_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain l3_aon_43xx_clkdm = {
+	.name		  = "l3_aon_clkdm",
+	.pwrdm		  = { .name = "wkup_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_WKUP_INST,
+	.clkdm_offs	  = AM43XX_CM_WKUP_L3_AON_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain emif_43xx_clkdm = {
+	.name		  = "emif_clkdm",
+	.pwrdm		  = { .name = "per_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_PER_INST,
+	.clkdm_offs	  = AM43XX_CM_PER_EMIF_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain l4_wkup_aon_43xx_clkdm = {
+	.name		  = "l4_wkup_aon_clkdm",
+	.pwrdm		  = { .name = "wkup_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_WKUP_INST,
+	.clkdm_offs	  = AM43XX_CM_WKUP_L4_WKUP_AON_CDOFFS,
+};
+
+static struct clockdomain l3_43xx_clkdm = {
+	.name		  = "l3_clkdm",
+	.pwrdm		  = { .name = "per_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_PER_INST,
+	.clkdm_offs	  = AM43XX_CM_PER_L3_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain l4_wkup_43xx_clkdm = {
+	.name		  = "l4_wkup_clkdm",
+	.pwrdm		  = { .name = "wkup_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_WKUP_INST,
+	.clkdm_offs	  = AM43XX_CM_WKUP_WKUP_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain cpsw_125mhz_43xx_clkdm = {
+	.name		  = "cpsw_125mhz_clkdm",
+	.pwrdm		  = { .name = "per_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_PER_INST,
+	.clkdm_offs	  = AM43XX_CM_PER_CPSW_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain gfx_l3_43xx_clkdm = {
+	.name		  = "gfx_l3_clkdm",
+	.pwrdm		  = { .name = "gfx_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_GFX_INST,
+	.clkdm_offs	  = AM43XX_CM_GFX_GFX_L3_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain l3s_43xx_clkdm = {
+	.name		  = "l3s_clkdm",
+	.pwrdm		  = { .name = "per_pwrdm" },
+	.prcm_partition	  = AM43XX_CM_PARTITION,
+	.cm_inst	  = AM43XX_CM_PER_INST,
+	.clkdm_offs	  = AM43XX_CM_PER_L3S_CDOFFS,
+	.flags		  = CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_FORCE_SLEEP,
+};
+
+static struct clockdomain *clockdomains_am43xx[] __initdata = {
+	&l4_cefuse_43xx_clkdm,
+	&mpu_43xx_clkdm,
+	&l4ls_43xx_clkdm,
+	&tamper_43xx_clkdm,
+	&l4_rtc_43xx_clkdm,
+	&pruss_ocp_43xx_clkdm,
+	&ocpwp_l3_43xx_clkdm,
+	&l3s_tsc_43xx_clkdm,
+	&dss_43xx_clkdm,
+	&l3_aon_43xx_clkdm,
+	&emif_43xx_clkdm,
+	&l4_wkup_aon_43xx_clkdm,
+	&l3_43xx_clkdm,
+	&l4_wkup_43xx_clkdm,
+	&cpsw_125mhz_43xx_clkdm,
+	&gfx_l3_43xx_clkdm,
+	&l3s_43xx_clkdm,
+	NULL
+};
+
+void __init am43xx_clockdomains_init(void)
+{
+	clkdm_register_platform_funcs(&omap4_clkdm_operations);
+	clkdm_register_clkdms(clockdomains_am43xx);
+	clkdm_complete_init();
+}
-- 
1.8.3.1



From afzal at ti.com  Thu Jul 11 02:36:20 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 11 Jul 2013 12:06:20 +0530
Subject: [PATCH RFC 08/13] ARM: OMAP2+: hwmod: AMx3: runtime AM43x handling
In-Reply-To: <cover.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
Message-ID: <244f8bb41eb3a15fd12a6180736defca8baaefbf.1373519192.git.afzal@ti.com>

Update AM43x CLKCTRL, RSTCTRL, RSTST offsets, clockdomain & ocpif clk
that differ with AM335x at runtime. This helps in resuing much of the
AM335x hwmod data's for AM43x.

Signed-off-by: Afzal Mohammed <afzal at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 110 +++++++++++++++++++++++++++++
 1 file changed, 110 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index a61032d..7897fec 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -26,6 +26,7 @@
 #include "cm33xx.h"
 #include "prm33xx.h"
 #include "prm-regbits-33xx.h"
+#include "prcm43xx.h"
 #include "i2c.h"
 #include "mmc.h"
 #include "wd_timer.h"
@@ -2380,6 +2381,71 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__aes0 = {
 
 #define CLKCTRL(oh, clkctrl) ((oh).prcm.omap4.clkctrl_offs = (clkctrl))
 
+static void am43xx_hwmod_clkctrl(void)
+{
+	CLKCTRL(am33xx_uart2_hwmod, AM43XX_CM_PER_UART1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_uart3_hwmod, AM43XX_CM_PER_UART2_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_uart4_hwmod, AM43XX_CM_PER_UART3_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_uart5_hwmod, AM43XX_CM_PER_UART4_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_uart6_hwmod, AM43XX_CM_PER_UART5_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_dcan0_hwmod, AM43XX_CM_PER_DCAN0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_dcan1_hwmod, AM43XX_CM_PER_DCAN1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_elm_hwmod, AM43XX_CM_PER_ELM_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_epwmss0_hwmod, AM43XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_epwmss1_hwmod, AM43XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_epwmss2_hwmod, AM43XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_gpio1_hwmod, AM43XX_CM_PER_GPIO1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_gpio2_hwmod, AM43XX_CM_PER_GPIO2_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_gpio3_hwmod, AM43XX_CM_PER_GPIO3_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_i2c2_hwmod, AM43XX_CM_PER_I2C1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_i2c3_hwmod, AM43XX_CM_PER_I2C2_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_mailbox_hwmod, AM43XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_mmc0_hwmod, AM43XX_CM_PER_MMC0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_mmc1_hwmod, AM43XX_CM_PER_MMC1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_spi0_hwmod, AM43XX_CM_PER_SPI0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_spi1_hwmod, AM43XX_CM_PER_SPI1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_spinlock_hwmod, AM43XX_CM_PER_SPINLOCK_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_timer2_hwmod, AM43XX_CM_PER_TIMER2_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_timer3_hwmod, AM43XX_CM_PER_TIMER3_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_timer4_hwmod, AM43XX_CM_PER_TIMER4_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_timer5_hwmod, AM43XX_CM_PER_TIMER5_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_timer6_hwmod, AM43XX_CM_PER_TIMER6_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_timer7_hwmod, AM43XX_CM_PER_TIMER7_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_wkup_m3_hwmod, AM43XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_control_hwmod, AM43XX_CM_WKUP_CONTROL_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_smartreflex0_hwmod,
+		AM43XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_smartreflex1_hwmod,
+		AM43XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_uart1_hwmod, AM43XX_CM_WKUP_UART0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_timer1_hwmod, AM43XX_CM_WKUP_TIMER1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_i2c1_hwmod, AM43XX_CM_WKUP_I2C0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_gpio0_hwmod, AM43XX_CM_WKUP_GPIO0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_adc_tsc_hwmod, AM43XX_CM_WKUP_ADC_TSC_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_wd_timer1_hwmod, AM43XX_CM_WKUP_WDT1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_l4_wkup_hwmod, AM43XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_rtc_hwmod, AM43XX_CM_RTC_RTC_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_mmc2_hwmod, AM43XX_CM_PER_MMC2_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_gpmc_hwmod, AM43XX_CM_PER_GPMC_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_mcasp0_hwmod, AM43XX_CM_PER_MCASP0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_mcasp1_hwmod, AM43XX_CM_PER_MCASP1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_l4_ls_hwmod, AM43XX_CM_PER_L4LS_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_l3_main_hwmod, AM43XX_CM_PER_L3_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_tpcc_hwmod, AM43XX_CM_PER_TPCC_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_tptc0_hwmod, AM43XX_CM_PER_TPTC0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_tptc1_hwmod, AM43XX_CM_PER_TPTC1_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_tptc2_hwmod, AM43XX_CM_PER_TPTC2_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_cpgmac0_hwmod, AM43XX_CM_PER_CPGMAC0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_pruss_hwmod, AM43XX_CM_PER_PRUSS_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_gfx_hwmod, AM43XX_CM_GFX_GFX_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_l4_hs_hwmod, AM43XX_CM_PER_L4HS_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_mpu_hwmod , AM43XX_CM_MPU_MPU_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_l3_instr_hwmod , AM43XX_CM_PER_L3_INSTR_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_ocmcram_hwmod , AM43XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_sha0_hwmod , AM43XX_CM_PER_SHA0_CLKCTRL_OFFSET);
+	CLKCTRL(am33xx_aes0_hwmod , AM43XX_CM_PER_AES0_CLKCTRL_OFFSET);
+}
+
 static void am33xx_hwmod_clkctrl(void)
 {
 	CLKCTRL(am33xx_uart2_hwmod, AM33XX_CM_PER_UART1_CLKCTRL_OFFSET);
@@ -2447,6 +2513,13 @@ static void am33xx_hwmod_clkctrl(void)
 
 #define RSTCTRL(oh, rstctrl) ((oh).prcm.omap4.rstctrl_offs = (rstctrl))
 
+static void am43xx_hwmod_rstctrl(void)
+{
+	RSTCTRL(am33xx_pruss_hwmod, AM43XX_RM_PER_RSTCTRL_OFFSET);
+	RSTCTRL(am33xx_gfx_hwmod, AM43XX_RM_GFX_RSTCTRL_OFFSET);
+	RSTCTRL(am33xx_wkup_m3_hwmod, AM43XX_RM_WKUP_RSTCTRL_OFFSET);
+}
+
 static void am33xx_hwmod_rstctrl(void)
 {
 	RSTCTRL(am33xx_pruss_hwmod, AM33XX_RM_PER_RSTCTRL_OFFSET);
@@ -2456,18 +2529,49 @@ static void am33xx_hwmod_rstctrl(void)
 
 #define RSTST(oh, rstst) ((oh).prcm.omap4.rstst_offs = (rstst))
 
+static void am43xx_hwmod_rstst(void)
+{
+	RSTST(am33xx_gfx_hwmod, AM43XX_RM_GFX_RSTST_OFFSET);
+	RSTST(am33xx_wkup_m3_hwmod, AM43XX_RM_WKUP_RSTST_OFFSET);
+}
+
 static void am33xx_hwmod_rstst(void)
 {
 	RSTST(am33xx_gfx_hwmod, AM33XX_RM_GFX_RSTST_OFFSET);
 	RSTST(am33xx_wkup_m3_hwmod, AM33XX_RM_WKUP_RSTST_OFFSET);
 }
 
+static void am43xx_hwmod_clockdomain(void)
+{
+	am33xx_l4_hs_hwmod.clkdm_name = "l3_clkdm";
+	am33xx_adc_tsc_hwmod.clkdm_name = "l3s_tsc_clkdm";
+}
+
 static void am33xx_hwmod_clockdomain(void)
 {
 	am33xx_l4_hs_hwmod.clkdm_name = "l4hs_clkdm";
 	am33xx_adc_tsc_hwmod.clkdm_name = "l4_wkup_clkdm";
 }
 
+#define AM43XX_L4_WKUP_OCPIF_CLK "sys_clkin_ck"
+
+static void am43xx_hwmod_ocpif_clk(void)
+{
+	am33xx_l4_wkup__wkup_m3.clk = AM43XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__control.clk = AM43XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__smartreflex0.clk = AM43XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__smartreflex1.clk = AM43XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__uart1.clk = AM43XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__timer1.clk = AM43XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__i2c1.clk = AM43XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__gpio0.clk = AM43XX_L4_WKUP_OCPIF_CLK;
+	am33xx_l4_wkup__wd_timer1.clk = AM43XX_L4_WKUP_OCPIF_CLK;
+	am33xx_wkup_m3__l4_wkup.clk = AM43XX_L4_WKUP_OCPIF_CLK;
+	am33xx_wkup_m3_hwmod.main_clk = AM43XX_L4_WKUP_OCPIF_CLK;
+	am33xx_control_hwmod.main_clk = AM43XX_L4_WKUP_OCPIF_CLK;
+	am33xx_gpio0_hwmod.main_clk = AM43XX_L4_WKUP_OCPIF_CLK;
+}
+
 #define AM33XX_L4_WKUP_OCPIF_CLK "dpll_core_m4_div2_ck"
 
 static void am33xx_hwmod_ocpif_clk(void)
@@ -2584,6 +2688,12 @@ int __init am33xx_hwmod_init(void)
 		am33xx_hwmod_rstst();
 		am33xx_hwmod_clockdomain();
 		am33xx_hwmod_ocpif_clk();
+	} else {
+		am43xx_hwmod_clkctrl();
+		am43xx_hwmod_rstctrl();
+		am43xx_hwmod_rstst();
+		am43xx_hwmod_clockdomain();
+		am43xx_hwmod_ocpif_clk();
 	}
 
 	ret = omap_hwmod_register_links(amx3xx_hwmod_ocp_ifs);
-- 
1.8.3.1



From afzal at ti.com  Thu Jul 11 02:36:28 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 11 Jul 2013 12:06:28 +0530
Subject: [PATCH RFC 09/13] ARM: OMAP2+: hwmod: AM43x operations
In-Reply-To: <cover.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
Message-ID: <98d7f535693c2bdcb576f27cb75dee9743e230f7.1373519192.git.afzal@ti.com>

From: Ambresh K <ambresh at ti.com>

Reuse OMAP4 operations on AM43x.

Signed-off-by: Ambresh K <ambresh at ti.com>
Signed-off-by: Afzal Mohammed <afzal at ti.com>
---

Note: This may have to modified as mentioned in the cover letter.

 arch/arm/mach-omap2/omap_hwmod.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7f4db12..0df6353 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -4113,7 +4113,7 @@ void __init omap_hwmod_init(void)
 		soc_ops.assert_hardreset = _omap2_assert_hardreset;
 		soc_ops.deassert_hardreset = _omap2_deassert_hardreset;
 		soc_ops.is_hardreset_asserted = _omap2_is_hardreset_asserted;
-	} else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
+	} else if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_am43xx()) {
 		soc_ops.enable_module = _omap4_enable_module;
 		soc_ops.disable_module = _omap4_disable_module;
 		soc_ops.wait_target_ready = _omap4_wait_target_ready;
-- 
1.8.3.1



From afzal at ti.com  Thu Jul 11 02:36:37 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 11 Jul 2013 12:06:37 +0530
Subject: [PATCH RFC 10/13] ARM: OMAP2+: AM43x: PRCM kbuild
In-Reply-To: <cover.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
Message-ID: <8c1d337077efb9e2c1aaf7fb394f27d1e47f17c4.1373519192.git.afzal@ti.com>

Build AM43x power domain, clock domain and hwmod data.

Many of AM43x IP's and interconnects are similar as that in AM335x,
hence AM335x hwmod data is being reused with necessary changes.

Earlier the plan was to reuse AM335x specific PRCM code, but as AM43x
PRCM is much similar to OMAP4/5, AM335x PRCM is divorced and instead
married with OMAP4/5 PRCM for AM43x.

Signed-off-by: Afzal Mohammed <afzal at ti.com>
---
 arch/arm/mach-omap2/Makefile | 5 ++++-
 arch/arm/mach-omap2/cm33xx.h | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ea5a27f..647acae 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -112,12 +112,12 @@ obj-$(CONFIG_ARCH_OMAP2)		+= prm2xxx_3xxx.o prm2xxx.o cm2xxx.o
 obj-$(CONFIG_ARCH_OMAP3)		+= prm2xxx_3xxx.o prm3xxx.o cm3xxx.o
 obj-$(CONFIG_ARCH_OMAP3)		+= vc3xxx_data.o vp3xxx_data.o
 obj-$(CONFIG_SOC_AM33XX)		+= prm33xx.o cm33xx.o
-obj-$(CONFIG_SOC_AM43XX)		+= prm33xx.o cm33xx.o
 omap-prcm-4-5-common			=  cminst44xx.o cm44xx.o prm44xx.o \
 					   prcm_mpu44xx.o prminst44xx.o \
 					   vc44xx_data.o vp44xx_data.o
 obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-prcm-4-5-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(omap-prcm-4-5-common)
+obj-$(CONFIG_SOC_AM43XX)		+= $(omap-prcm-4-5-common)
 
 # OMAP voltage domains
 voltagedomain-common			:= voltage.o vc.o vp.o
@@ -145,6 +145,7 @@ obj-$(CONFIG_ARCH_OMAP4)		+= powerdomains44xx_data.o
 obj-$(CONFIG_SOC_AM33XX)		+= $(powerdomain-common)
 obj-$(CONFIG_SOC_AM33XX)		+= powerdomains33xx_data.o
 obj-$(CONFIG_SOC_AM43XX)		+= $(powerdomain-common)
+obj-$(CONFIG_SOC_AM43XX)		+= powerdomains43xx_data.o
 obj-$(CONFIG_SOC_OMAP5)			+= $(powerdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= powerdomains54xx_data.o
 
@@ -162,6 +163,7 @@ obj-$(CONFIG_ARCH_OMAP4)		+= clockdomains44xx_data.o
 obj-$(CONFIG_SOC_AM33XX)		+= $(clockdomain-common)
 obj-$(CONFIG_SOC_AM33XX)		+= clockdomains33xx_data.o
 obj-$(CONFIG_SOC_AM43XX)		+= $(clockdomain-common)
+obj-$(CONFIG_SOC_AM43XX)		+= clockdomains43xx_data.o
 obj-$(CONFIG_SOC_OMAP5)			+= $(clockdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= clockdomains54xx_data.o
 
@@ -205,6 +207,7 @@ obj-$(CONFIG_ARCH_OMAP3)		+= omap_hwmod_2xxx_3xxx_ipblock_data.o
 obj-$(CONFIG_ARCH_OMAP3)		+= omap_hwmod_2xxx_3xxx_interconnect_data.o
 obj-$(CONFIG_ARCH_OMAP3)		+= omap_hwmod_3xxx_data.o
 obj-$(CONFIG_SOC_AM33XX)		+= omap_hwmod_33xx_data.o
+obj-$(CONFIG_SOC_AM43XX)		+= omap_hwmod_33xx_data.o
 obj-$(CONFIG_ARCH_OMAP4)		+= omap_hwmod_44xx_data.o
 obj-$(CONFIG_SOC_OMAP5)			+= omap_hwmod_54xx_data.o
 
diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h
index 201e507..757b9a1 100644
--- a/arch/arm/mach-omap2/cm33xx.h
+++ b/arch/arm/mach-omap2/cm33xx.h
@@ -383,7 +383,7 @@ extern void am33xx_cm_clkdm_disable_hwsup(u16 inst, u16 cdoffs);
 extern void am33xx_cm_clkdm_force_sleep(u16 inst, u16 cdoffs);
 extern void am33xx_cm_clkdm_force_wakeup(u16 inst, u16 cdoffs);
 
-#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX)
+#ifdef CONFIG_SOC_AM33XX
 extern int am33xx_cm_wait_module_idle(u16 inst, u16 cdoffs,
 					u16 clkctrl_offs);
 extern void am33xx_cm_module_enable(u8 mode, u16 inst, u16 cdoffs,
-- 
1.8.3.1



From afzal at ti.com  Thu Jul 11 02:36:45 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 11 Jul 2013 12:06:45 +0530
Subject: [PATCH RFC 11/13] ARM: OMAP2+: AM43x PRCM init
In-Reply-To: <cover.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
Message-ID: <32c6a6fba13448a4a08981a017c7c4c953ab0fa4.1373519192.git.afzal@ti.com>

From: Ambresh K <ambresh at ti.com>

Initialise AM43x HWMOD, powerdomains and clockdomains.

Signed-off-by: Ambresh K <ambresh at ti.com>
Signed-off-by: Afzal Mohammed <afzal at ti.com>
---
 arch/arm/mach-omap2/io.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 7325ba6..901acf6 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -594,8 +594,14 @@ void __init am43xx_init_early(void)
 				  NULL);
 	omap2_set_globals_prm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE));
 	omap2_set_globals_cm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE), NULL);
+	omap_prm_base_init();
+	omap_cm_base_init();
 	omap3xxx_check_revision();
 	am33xx_check_features();
+	am43xx_powerdomains_init();
+	am43xx_clockdomains_init();
+	am33xx_hwmod_init();
+	omap_hwmod_init_postsetup();
 }
 #endif
 
-- 
1.8.3.1



From afzal at ti.com  Thu Jul 11 02:37:01 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 11 Jul 2013 12:07:01 +0530
Subject: [PATCH RFC 12/13] ARM: OMAP2+: hwmod: type4 sysc
In-Reply-To: <cover.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
Message-ID: <1b8dd5893a03a42648a417837fafb193fd69a141.1373519192.git.afzal@ti.com>

AM43x PKA module has sysconfig bitmap different from that of the
existing available types, hence add a new one.

Signed-off-by: Afzal Mohammed <afzal at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.h             | 5 +++++
 arch/arm/mach-omap2/omap_hwmod_common_data.c | 6 ++++++
 2 files changed, 11 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 29f7687..a743358 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -41,6 +41,7 @@ struct omap_device;
 extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type1;
 extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type2;
 extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3;
+extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type4;
 
 /*
  * OCP SYSCONFIG bit shifts/masks TYPE1. These are for IPs compliant
@@ -81,6 +82,10 @@ extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3;
 #define SYSC_TYPE3_MIDLEMODE_SHIFT	2
 #define SYSC_TYPE3_MIDLEMODE_MASK	(0x3 << SYSC_TYPE3_MIDLEMODE_SHIFT)
 
+#define SYSC_TYPE4_SIDLEMODE_SHIFT	4
+#define SYSC_TYPE4_SOFTRESET_SHIFT	1
+#define SYSC_TYPE4_AUTOIDLE_SHIFT	0
+
 /* OCP SYSSTATUS bit shifts/masks */
 #define SYSS_RESETDONE_SHIFT		0
 #define SYSS_RESETDONE_MASK		(1 << SYSS_RESETDONE_SHIFT)
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.c b/arch/arm/mach-omap2/omap_hwmod_common_data.c
index 79d623b..238c2c1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.c
@@ -59,6 +59,12 @@ struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3 = {
 	.sidle_shift	= SYSC_TYPE3_SIDLEMODE_SHIFT,
 };
 
+struct omap_hwmod_sysc_fields omap_hwmod_sysc_type4 = {
+	.sidle_shift	= SYSC_TYPE4_SIDLEMODE_SHIFT,
+	.srst_shift	= SYSC_TYPE4_SOFTRESET_SHIFT,
+	.autoidle_shift	= SYSC_TYPE4_AUTOIDLE_SHIFT,
+};
+
 struct omap_dss_dispc_dev_attr omap2_3_dss_dispc_dev_attr = {
 	.manager_count		= 2,
 	.has_framedonetv_irq	= 0
-- 
1.8.3.1



From afzal at ti.com  Thu Jul 11 02:37:09 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 11 Jul 2013 12:07:09 +0530
Subject: [PATCH RFC 13/13] ARM: OMAP2+: hwmod: AM43x: new w.r.t AM335x
In-Reply-To: <cover.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
Message-ID: <0bb1eb7339ac9fd78c8251f71082ac3b3add3ad2.1373519192.git.afzal@ti.com>

AM43x has a few IP's that are not present in AM335x,
1. qspi
2. hdq1w
3. vpfe (two instances)
4. pka
5. des
6. rng
7. synctimer

In addition it has a few new instances of existing IP's,
1. timer8-11
2. ehrpwm3-5
3. spi2-4

Also a different pruss interconnect.

Update hwmod with the above details and register 'ocpif' if platform
being run is AM43x.

TODO:
1. usb
2. dss

Signed-off-by: Afzal Mohammed <afzal at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 525 ++++++++++++++++++++++++++++-
 1 file changed, 523 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 7897fec..319780e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -30,6 +30,7 @@
 #include "i2c.h"
 #include "mmc.h"
 #include "wd_timer.h"
+#include "hdq1w.h"
 #include "soc.h"
 
 /*
@@ -1595,6 +1596,346 @@ static struct omap_hwmod am33xx_usbss_hwmod = {
 	},
 };
 
+static struct omap_hwmod_class_sysconfig am43xx_qspi_sysc = {
+	.sysc_offs	= 0x10,
+	.sysc_flags	= SYSC_HAS_SIDLEMODE,
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+				SIDLE_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class am43xx_qspi_hwmod_class = {
+	.name		= "qspi",
+	.sysc		= &am43xx_qspi_sysc,
+};
+
+static struct omap_hwmod am43xx_qspi_hwmod = {
+	.name		= "qspi",
+	.class		= &am43xx_qspi_hwmod_class,
+	.clkdm_name	= "l3s_clkdm",
+	.main_clk	= "dpll_per_m2_div4_ck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = AM43XX_CM_PER_QSPI_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod_class_sysconfig am43xx_hdq1w_sysc = {
+	.sysc_offs	= 0x14,
+	.syss_offs	= 0x18,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SOFTRESET |
+			   SYSS_HAS_RESET_STATUS),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am43xx_hdq1w_hwmod_class = {
+	.name	= "hdq1w",
+	.sysc	= &am43xx_hdq1w_sysc,
+	.reset	= &omap_hdq1w_reset,
+};
+
+static struct omap_hwmod am43xx_hdq1w_hwmod = {
+	.name		= "hdq1w",
+	.class		= &am43xx_hdq1w_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.main_clk	= "func_12m_clk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = AM43XX_CM_PER_HDQ1W_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod_class_sysconfig am43xx_vpfe_sysc = {
+	.sysc_offs	= 0x104,
+	.sysc_flags	= (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+			   MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class am43xx_vpfe_hwmod_class = {
+	.name	= "vpfe",
+	.sysc	= &am43xx_vpfe_sysc,
+};
+
+static struct omap_hwmod am43xx_vpfe0_hwmod = {
+	.name		= "vpfe0",
+	.class		= &am43xx_vpfe_hwmod_class,
+	.clkdm_name	= "l3_clkdm",
+	.main_clk	= "sysclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = AM43XX_CM_PER_VPFE0_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod am43xx_vpfe1_hwmod = {
+	.name		= "vpfe1",
+	.class		= &am43xx_vpfe_hwmod_class,
+	.clkdm_name	= "l3_clkdm",
+	.main_clk	= "sysclk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = AM43XX_CM_PER_VPFE1_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod_class_sysconfig am43xx_pka_sysc = {
+	.rev_offs	= 0x1fe0,
+	.sysc_offs	= 0x1ff0,
+	.syss_offs	= 0x1ff4,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO),
+	.sysc_fields	= &omap_hwmod_sysc_type4,
+};
+
+static struct omap_hwmod_class am43xx_pka_hwmod_class = {
+	.name		= "pka",
+	.sysc		= &am43xx_pka_sysc,
+};
+
+static struct omap_hwmod am43xx_pka_hwmod = {
+	.name		= "pka",
+	.class		= &am43xx_pka_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs	= AM43XX_CM_PER_PKA_CLKCTRL_OFFSET,
+			.modulemode	= MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod_class_sysconfig am43xx_des_sysc = {
+	.rev_offs	= 0x30,
+	.sysc_offs	= 0x34,
+	.syss_offs	= 0x38,
+	.sysc_flags	= SYSS_HAS_RESET_STATUS,
+};
+
+static struct omap_hwmod_class am43xx_des_hwmod_class = {
+	.name		= "des",
+	.sysc		= &am43xx_des_sysc,
+};
+
+static struct omap_hwmod am43xx_des_hwmod = {
+	.name		= "des",
+	.class		= &am43xx_des_hwmod_class,
+	.clkdm_name	= "l3_clkdm",
+	.main_clk	= "l3_gclk",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs	= AM43XX_CM_PER_DES_CLKCTRL_OFFSET,
+			.modulemode	= MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod_class am43xx_rng_hwmod_class = {
+	.name		= "rng",
+};
+
+static struct omap_hwmod am43xx_rng_hwmod = {
+	.name		= "rng",
+	.class		= &am43xx_rng_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs	= AM43XX_CM_PER_RNG_CLKCTRL_OFFSET,
+			.modulemode	= MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod am43xx_timer8_hwmod = {
+	.name		= "timer8",
+	.class		= &am33xx_timer_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.main_clk	= "timer8_fck",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs	= AM43XX_CM_PER_TIMER8_CLKCTRL_OFFSET,
+			.modulemode	= MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod am43xx_timer9_hwmod = {
+	.name		= "timer9",
+	.class		= &am33xx_timer_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.main_clk	= "timer9_fck",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs	= AM43XX_CM_PER_TIMER9_CLKCTRL_OFFSET,
+			.modulemode	= MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod am43xx_timer10_hwmod = {
+	.name		= "timer10",
+	.class		= &am33xx_timer_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.main_clk	= "timer10_fck",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs	= AM43XX_CM_PER_TIMER10_CLKCTRL_OFFSET,
+			.modulemode	= MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod am43xx_timer11_hwmod = {
+	.name		= "timer11",
+	.class		= &am33xx_timer_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.main_clk	= "timer11_fck",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs	= AM43XX_CM_PER_TIMER11_CLKCTRL_OFFSET,
+			.modulemode	= MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod_class_sysconfig am43xx_synctimer_sysc = {
+	.rev_offs	= 0x0,
+	.sysc_offs	= 0x4,
+	.sysc_flags	= SYSC_HAS_SIDLEMODE,
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am43xx_synctimer_hwmod_class = {
+	.name	= "synctimer",
+	.sysc	= &am43xx_synctimer_sysc,
+};
+
+static struct omap_hwmod am43xx_synctimer_hwmod = {
+	.name		= "counter_32k",
+	.class		= &am43xx_synctimer_hwmod_class,
+	.clkdm_name	= "l4_wkup_aon_clkdm",
+	.main_clk	= "synctimer_32kclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = AM43XX_CM_WKUP_SYNCTIMER_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod am43xx_epwmss3_hwmod = {
+	.name		= "epwmss3",
+	.class		= &am33xx_epwmss_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.main_clk	= "l4ls_gclk",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs = AM43XX_CM_PER_EPWMSS3_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod am43xx_ehrpwm3_hwmod = {
+	.name		= "ehrpwm3",
+	.class		= &am33xx_ehrpwm_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.main_clk	= "l4ls_gclk",
+};
+
+static struct omap_hwmod am43xx_epwmss4_hwmod = {
+	.name		= "epwmss4",
+	.class		= &am33xx_epwmss_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.main_clk	= "l4ls_gclk",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs = AM43XX_CM_PER_EPWMSS4_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod am43xx_ehrpwm4_hwmod = {
+	.name		= "ehrpwm4",
+	.class		= &am33xx_ehrpwm_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.main_clk	= "l4ls_gclk",
+};
+
+static struct omap_hwmod am43xx_epwmss5_hwmod = {
+	.name		= "epwmss5",
+	.class		= &am33xx_epwmss_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.main_clk	= "l4ls_gclk",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs = AM43XX_CM_PER_EPWMSS5_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod am43xx_ehrpwm5_hwmod = {
+	.name		= "ehrpwm5",
+	.class		= &am33xx_ehrpwm_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.main_clk	= "l4ls_gclk",
+};
+
+static struct omap_hwmod am43xx_spi2_hwmod = {
+	.name		= "spi2",
+	.class		= &am33xx_spi_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.main_clk	= "dpll_per_m2_div4_ck",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs = AM43XX_CM_PER_SPI2_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &mcspi_attrib,
+};
+
+static struct omap_hwmod am43xx_spi3_hwmod = {
+	.name		= "spi3",
+	.class		= &am33xx_spi_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.main_clk	= "dpll_per_m2_div4_ck",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs = AM43XX_CM_PER_SPI3_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &mcspi_attrib,
+};
+
+static struct omap_hwmod am43xx_spi4_hwmod = {
+	.name		= "spi4",
+	.class		= &am33xx_spi_hwmod_class,
+	.clkdm_name	= "l4ls_clkdm",
+	.main_clk	= "dpll_per_m2_div4_ck",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs = AM43XX_CM_PER_SPI4_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.dev_attr	= &mcspi_attrib,
+};
 
 /*
  * Interfaces
@@ -2379,6 +2720,160 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__aes0 = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+static struct omap_hwmod_ocp_if am43xx_l3_s__qspi = {
+	.master		= &am33xx_l3_s_hwmod,
+	.slave		= &am43xx_qspi_hwmod,
+	.clk		= "l3s_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__hdq1w = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_hdq1w_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__vpfe0 = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_vpfe0_hwmod,
+	.clk		= "l3_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__vpfe1 = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_vpfe1_hwmod,
+	.clk		= "l3_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__pka = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_pka_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__rng = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_rng_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l3_main__des = {
+	.master		= &am33xx_l3_main_hwmod,
+	.slave		= &am43xx_des_hwmod,
+	.clk		= "l3_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__timer8 = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_timer8_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__timer9 = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_timer9_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__timer10 = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_timer10_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__timer11 = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_timer11_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am33xx_l4_wkup__synctimer = {
+	.master		= &am33xx_l4_wkup_hwmod,
+	.slave		= &am43xx_synctimer_hwmod,
+	.clk		= "sys_clkin_ck",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__epwmss3 = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_epwmss3_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_epwmss3__ehrpwm3 = {
+	.master		= &am43xx_epwmss3_hwmod,
+	.slave		= &am43xx_ehrpwm3_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__epwmss4 = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_epwmss4_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_epwmss4__ehrpwm4 = {
+	.master		= &am43xx_epwmss4_hwmod,
+	.slave		= &am43xx_ehrpwm4_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__epwmss5 = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_epwmss5_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_epwmss5__ehrpwm5 = {
+	.master		= &am43xx_epwmss5_hwmod,
+	.slave		= &am43xx_ehrpwm5_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__mcspi2 = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_spi2_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__mcspi3 = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_spi3_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__mcspi4 = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_spi4_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l3_main__pruss = {
+	.master		= &am33xx_l3_main_hwmod,
+	.slave		= &am33xx_pruss_hwmod,
+	.clk		= "dpll_core_m4_ck",
+	.user		= OCP_USER_MPU,
+};
+
 #define CLKCTRL(oh, clkctrl) ((oh).prcm.omap4.clkctrl_offs = (clkctrl))
 
 static void am43xx_hwmod_clkctrl(void)
@@ -2591,6 +3086,32 @@ static void am33xx_hwmod_ocpif_clk(void)
 	am33xx_gpio0_hwmod.main_clk = AM33XX_L4_WKUP_OCPIF_CLK;
 }
 
+static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
+	&am43xx_l3_s__qspi,
+	&am43xx_l4_ls__hdq1w,
+	&am43xx_l4_ls__vpfe0,
+	&am43xx_l4_ls__vpfe1,
+	&am43xx_l4_ls__pka,
+	&am43xx_l4_ls__rng,
+	&am43xx_l3_main__des,
+	&am43xx_l4_ls__timer8,
+	&am43xx_l4_ls__timer9,
+	&am43xx_l4_ls__timer10,
+	&am43xx_l4_ls__timer11,
+	&am33xx_l4_wkup__synctimer,
+	&am43xx_l4_ls__epwmss3,
+	&am43xx_epwmss3__ehrpwm3,
+	&am43xx_l4_ls__epwmss4,
+	&am43xx_epwmss4__ehrpwm4,
+	&am43xx_l4_ls__epwmss5,
+	&am43xx_epwmss5__ehrpwm5,
+	&am43xx_l4_ls__mcspi2,
+	&am43xx_l4_ls__mcspi3,
+	&am43xx_l4_ls__mcspi4,
+	&am43xx_l3_main__pruss,
+	NULL,
+};
+
 static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
 	&am33xx_l3_main__emif,
 	&am33xx_l4_hs__pruss,
@@ -2702,6 +3223,6 @@ int __init am33xx_hwmod_init(void)
 
 	if (soc_is_am33xx())
 		return omap_hwmod_register_links(am33xx_hwmod_ocp_ifs);
-
-	return 0;
+	else
+		return omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
 }
-- 
1.8.3.1



From s.hauer at pengutronix.de  Thu Jul 11 02:37:19 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 11 Jul 2013 08:37:19 +0200
Subject: [PATCH v12 02/13] usb: chipidea: imx: remove vbus regulator
 operation
In-Reply-To: <1373524041-10482-3-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <1373524041-10482-3-git-send-email-peter.chen@freescale.com>
Message-ID: <20130711063719.GE14452@pengutronix.de>

On Thu, Jul 11, 2013 at 02:27:10PM +0800, Peter Chen wrote:
> Since we have added vbus reguatlor operation at common
> host file (chipidea/host.c), the glue layer vbus operation
> isn't needed any more.
> 
> Signed-off-by: Peter Chen <peter.chen at freescale.com>
> ---
>  drivers/usb/chipidea/ci_hdrc_imx.c |   30 +++++++-----------------------
>  1 files changed, 7 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
> index 14362c0..d06355e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -31,7 +31,6 @@ struct ci_hdrc_imx_data {
>  	struct usb_phy *phy;
>  	struct platform_device *ci_pdev;
>  	struct clk *clk;
> -	struct regulator *reg_vbus;
>  };
>  
>  static const struct usbmisc_ops *usbmisc_ops;
> @@ -141,22 +140,13 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>  		goto err_clk;
>  	}
>  
> -	/* we only support host now, so enable vbus here */
> -	data->reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
> -	if (!IS_ERR(data->reg_vbus)) {
> -		ret = regulator_enable(data->reg_vbus);
> -		if (ret) {
> -			dev_err(&pdev->dev,
> -				"Failed to enable vbus regulator, err=%d\n",
> -				ret);
> -			goto err_clk;
> -		}
> -	} else {
> -		data->reg_vbus = NULL;
> -	}
> -
>  	pdata.phy = data->phy;
>  
> +	/* Get the vbus regulator */
> +	pdata.reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
> +	if (IS_ERR(pdata.reg_vbus))
> +		pdata.reg_vbus = NULL;

I think you should bail out at least in the -EPROBE_DEFER case.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From penberg at kernel.org  Thu Jul 11 02:48:47 2013
From: penberg at kernel.org (Pekka Enberg)
Date: Thu, 11 Jul 2013 09:48:47 +0300
Subject: [PATCH] slab : allow SLAB_RED_ZONE and SLAB_STORE_USER to work
 on arm
In-Reply-To: <5090F708.3010104@parrot.com>
References: <1350386231-770-1-git-send-email-matthieu.castet@parrot.com>
 <CAOJsxLHQy7pshnskn+wMp=1D9+9wGQZBhFD+kjtbCSJvoW7q2Q@mail.gmail.com>
 <5090F708.3010104@parrot.com>
Message-ID: <51DE554F.8020107@kernel.org>

(nine months later...)

On 10/31/2012 12:01 PM, Matthieu CASTET wrote:
>> This piece of code tends to break in peculiar ways every time someone
>> touches it. I could use some more convincing in the changelog this
>> time it won't...
>
> Ok, is the following changelog is ok ?
>
> The current slab code only allow to put redzone( and user store) info if "buffer
> alignment(ralign) <= __alignof__(unsigned long long)". This was done because we
> want to keep the buffer aligned for user even after adding redzone at the
> beginning of the buffer (the user store is stored after user buffer) [1]
>
> But instead of disabling this feature when "ralign > __alignof__(unsigned long
> long)", we can force the alignment by allocating ralign before user buffer.
>
> This is done by setting ralign in obj_offset when "ralign > __alignof__(unsigned
> long long)" and keeping the old behavior when  "ralign <= __alignof__(unsigned
> long long)" (we set sizeof(unsigned long long)).
>
> The 5c5e3b33b7cb959a401f823707bee006caadd76e commit wasn't handling "ralign <=
> __alignof__(unsigned long long)", that's why it broked some configuration.
>
> This was tested on omap3 (ralign is 64 and __alignof__(unsigned long long) is 8)

Care to resend this patch with the above changelog? I'll see
if I can find someone to ACK it for v3.12.

			Pekka


From peter.chen at freescale.com  Thu Jul 11 02:55:38 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 14:55:38 +0800
Subject: [PATCH v12 02/13] usb: chipidea: imx: remove vbus regulator
 operation
In-Reply-To: <20130711063719.GE14452@pengutronix.de>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <1373524041-10482-3-git-send-email-peter.chen@freescale.com>
 <20130711063719.GE14452@pengutronix.de>
Message-ID: <20130711065537.GA10551@nchen-desktop>

On Thu, Jul 11, 2013 at 08:37:19AM +0200, Sascha Hauer wrote:
> >  
> > -	/* we only support host now, so enable vbus here */
> > -	data->reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
> > -	if (!IS_ERR(data->reg_vbus)) {
> > -		ret = regulator_enable(data->reg_vbus);
> > -		if (ret) {
> > -			dev_err(&pdev->dev,
> > -				"Failed to enable vbus regulator, err=%d\n",
> > -				ret);
> > -			goto err_clk;
> > -		}
> > -	} else {
> > -		data->reg_vbus = NULL;
> > -	}
> > -
> >  	pdata.phy = data->phy;
> >  
> > +	/* Get the vbus regulator */
> > +	pdata.reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
> > +	if (IS_ERR(pdata.reg_vbus))
> > +		pdata.reg_vbus = NULL;
> 
> I think you should bail out at least in the -EPROBE_DEFER case.
> 

Oh, correct. I will add another patch behind this for fix.
In fact, I met this problem at FSL mx6-auto board which uses
gpio-expendor chip max7310 as regulator-gpio for enable vbus
output.

-- 

Best Regards,
Peter Chen



From padma.v at samsung.com  Thu Jul 11 03:08:25 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Thu, 11 Jul 2013 12:38:25 +0530
Subject: [PATCH] ASoC: Samsung: Set RFS and BFS in slave mode
In-Reply-To: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
Message-ID: <1373526505-27115-2-git-send-email-padma.v@samsung.com>

As per the User Manual, the RFS and BFS should be set in slave mode
for correct operation.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
Signed-off-by: Andrew Bresticker <abrestic at chromium.org>
Reviewed-on: https://gerrit-int.chromium.org/37841
Reviewed-by: Simon Glass <sjg at google.com>
---
 sound/soc/samsung/i2s.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 82ebb1a..3fcf8d7 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -742,13 +742,13 @@ static int config_setup(struct i2s_dai *i2s)
 		return -EAGAIN;
 	}
 
-	/* Don't bother RFS, BFS & PSR in Slave mode */
-	if (is_slave(i2s))
-		return 0;
-
 	set_bfs(i2s, bfs);
 	set_rfs(i2s, rfs);
 
+	/* Don't bother with PSR in Slave mode */
+	if (is_slave(i2s))
+		return 0;
+
 	if (!(i2s->quirks & QUIRK_NO_MUXPSR)) {
 		psr = i2s->rclk_srcrate / i2s->frmclk / rfs;
 		writel(((psr - 1) << 8) | PSR_PSREN, i2s->addr + I2SPSR);
-- 
1.7.4.4



From padma.v at samsung.com  Thu Jul 11 03:08:24 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Thu, 11 Jul 2013 12:38:24 +0530
Subject: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on
 Exynos5420
Message-ID: <1373526505-27115-1-git-send-email-padma.v@samsung.com>

Exynos5420 added support for I2S TDM mode. For this, there are some
register changes in the I2S controller. This patch adds the relevant
register changes to support I2S in normal mode. This patch adds a
quirk for TDM mode and if TDM mode is present all the relevent changes
will be applied.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
[abrestic: style cleanup and documentation]
Signed-off-by: Andrew Bresticker <abrestic at chromium.org>
Reviewed-on: https://gerrit-int.chromium.org/37840
Reviewed-by: Simon Glass <sjg at google.com>
---
 .../devicetree/bindings/sound/samsung-i2s.txt      |    2 +
 include/linux/platform_data/asoc-s3c.h             |    1 +
 sound/soc/samsung/i2s-regs.h                       |   51 ++++++---
 sound/soc/samsung/i2s.c                            |  117 ++++++++++++++++----
 4 files changed, 132 insertions(+), 39 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
index 025e66b..b8593d5 100644
--- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
@@ -28,6 +28,8 @@ Optional SoC Specific Properties:
   enabled or disabled based on need.
 - samsung,supports-secdai:If I2S block has a secondary FIFO and internal DMA,
   then this flag is enabled.
+- samsung,supports-tdm: If the I2S controller supports TDM, then this flag
+  must be enabled.
 - samsung,idma-addr: Internal DMA register base address of the audio
   sub system(used in secondary sound source).
 - pinctrl-0: Should specify pin control groups used for this controller.
diff --git a/include/linux/platform_data/asoc-s3c.h b/include/linux/platform_data/asoc-s3c.h
index 8827259..9efc04d 100644
--- a/include/linux/platform_data/asoc-s3c.h
+++ b/include/linux/platform_data/asoc-s3c.h
@@ -36,6 +36,7 @@ struct samsung_i2s {
  */
 #define QUIRK_NO_MUXPSR		(1 << 2)
 #define QUIRK_NEED_RSTCLR	(1 << 3)
+#define QUIRK_SUPPORTS_TDM	(1 << 4)
 	/* Quirks of the I2S controller */
 	u32 quirks;
 	dma_addr_t idma_addr;
diff --git a/sound/soc/samsung/i2s-regs.h b/sound/soc/samsung/i2s-regs.h
index c0e6d9a..821a502 100644
--- a/sound/soc/samsung/i2s-regs.h
+++ b/sound/soc/samsung/i2s-regs.h
@@ -31,6 +31,10 @@
 #define I2SLVL1ADDR	0x34
 #define I2SLVL2ADDR	0x38
 #define I2SLVL3ADDR	0x3c
+#define I2SSTR1		0x40
+#define I2SVER		0x44
+#define I2SFIC2		0x48
+#define I2STDM		0x4c
 
 #define CON_RSTCLR		(1 << 31)
 #define CON_FRXOFSTATUS		(1 << 26)
@@ -95,24 +99,39 @@
 #define MOD_RXONLY		(1 << 8)
 #define MOD_TXRX		(2 << 8)
 #define MOD_MASK		(3 << 8)
-#define MOD_LR_LLOW		(0 << 7)
-#define MOD_LR_RLOW		(1 << 7)
-#define MOD_SDF_IIS		(0 << 5)
-#define MOD_SDF_MSB		(1 << 5)
-#define MOD_SDF_LSB		(2 << 5)
-#define MOD_SDF_MASK		(3 << 5)
-#define MOD_RCLK_256FS		(0 << 3)
-#define MOD_RCLK_512FS		(1 << 3)
-#define MOD_RCLK_384FS		(2 << 3)
-#define MOD_RCLK_768FS		(3 << 3)
-#define MOD_RCLK_MASK		(3 << 3)
-#define MOD_BCLK_32FS		(0 << 1)
-#define MOD_BCLK_48FS		(1 << 1)
-#define MOD_BCLK_16FS		(2 << 1)
-#define MOD_BCLK_24FS		(3 << 1)
-#define MOD_BCLK_MASK		(3 << 1)
+#define MOD_LRP_SHIFT		7
+#define MOD_LR_LLOW		0
+#define MOD_LR_RLOW		1
+#define MOD_SDF_SHIFT		5
+#define MOD_SDF_IIS		0
+#define MOD_SDF_MSB		1
+#define MOD_SDF_LSB		2
+#define MOD_SDF_MASK		3
+#define MOD_RCLK_SHIFT		3
+#define MOD_RCLK_256FS		0
+#define MOD_RCLK_512FS		1
+#define MOD_RCLK_384FS		2
+#define MOD_RCLK_768FS		3
+#define MOD_RCLK_MASK		3
+#define MOD_BCLK_SHIFT		1
+#define MOD_BCLK_32FS		0
+#define MOD_BCLK_48FS		1
+#define MOD_BCLK_16FS		2
+#define MOD_BCLK_24FS		3
+#define MOD_BCLK_MASK		3
 #define MOD_8BIT		(1 << 0)
 
+#define EXYNOS5420_MOD_LRP_SHIFT	15
+#define EXYNOS5420_MOD_SDF_SHIFT	6
+#define EXYNOS5420_MOD_RCLK_SHIFT	4
+#define EXYNOS5420_MOD_BCLK_SHIFT	0
+#define EXYNOS5420_MOD_BCLK_64FS	4
+#define EXYNOS5420_MOD_BCLK_96FS	5
+#define EXYNOS5420_MOD_BCLK_128FS	6
+#define EXYNOS5420_MOD_BCLK_192FS	7
+#define EXYNOS5420_MOD_BCLK_256FS	8
+#define EXYNOS5420_MOD_BCLK_MASK	0xf
+
 #define MOD_CDCLKCON		(1 << 12)
 
 #define PSR_PSREN		(1 << 15)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 3fcf8d7..398f8db 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -198,7 +198,13 @@ static inline bool is_manager(struct i2s_dai *i2s)
 /* Read RCLK of I2S (in multiples of LRCLK) */
 static inline unsigned get_rfs(struct i2s_dai *i2s)
 {
-	u32 rfs = (readl(i2s->addr + I2SMOD) >> 3) & 0x3;
+	u32 rfs;
+
+	if (i2s->quirks & QUIRK_SUPPORTS_TDM)
+		rfs = readl(i2s->addr + I2SMOD) >> EXYNOS5420_MOD_RCLK_SHIFT;
+	else
+		rfs = readl(i2s->addr + I2SMOD) >> MOD_RCLK_SHIFT;
+	rfs &= MOD_RCLK_MASK;
 
 	switch (rfs) {
 	case 3:	return 768;
@@ -212,21 +218,26 @@ static inline unsigned get_rfs(struct i2s_dai *i2s)
 static inline void set_rfs(struct i2s_dai *i2s, unsigned rfs)
 {
 	u32 mod = readl(i2s->addr + I2SMOD);
+	int rfs_shift;
 
-	mod &= ~MOD_RCLK_MASK;
+	if (i2s->quirks & QUIRK_SUPPORTS_TDM)
+		rfs_shift = EXYNOS5420_MOD_RCLK_SHIFT;
+	else
+		rfs_shift = MOD_RCLK_SHIFT;
+	mod &= ~(MOD_RCLK_MASK << rfs_shift);
 
 	switch (rfs) {
 	case 768:
-		mod |= MOD_RCLK_768FS;
+		mod |= (MOD_RCLK_768FS << rfs_shift);
 		break;
 	case 512:
-		mod |= MOD_RCLK_512FS;
+		mod |= (MOD_RCLK_512FS << rfs_shift);
 		break;
 	case 384:
-		mod |= MOD_RCLK_384FS;
+		mod |= (MOD_RCLK_384FS << rfs_shift);
 		break;
 	default:
-		mod |= MOD_RCLK_256FS;
+		mod |= (MOD_RCLK_256FS << rfs_shift);
 		break;
 	}
 
@@ -236,9 +247,22 @@ static inline void set_rfs(struct i2s_dai *i2s, unsigned rfs)
 /* Read Bit-Clock of I2S (in multiples of LRCLK) */
 static inline unsigned get_bfs(struct i2s_dai *i2s)
 {
-	u32 bfs = (readl(i2s->addr + I2SMOD) >> 1) & 0x3;
+	u32 bfs;
+
+	if (i2s->quirks & QUIRK_SUPPORTS_TDM) {
+		bfs = readl(i2s->addr + I2SMOD) >> EXYNOS5420_MOD_BCLK_SHIFT;
+		bfs &= EXYNOS5420_MOD_BCLK_MASK;
+	} else {
+		bfs = readl(i2s->addr + I2SMOD) >> MOD_BCLK_SHIFT;
+		bfs &= MOD_BCLK_MASK;
+	}
 
 	switch (bfs) {
+	case 8: return 256;
+	case 7: return 192;
+	case 6: return 128;
+	case 5: return 96;
+	case 4: return 64;
 	case 3: return 24;
 	case 2: return 16;
 	case 1:	return 48;
@@ -250,21 +274,50 @@ static inline unsigned get_bfs(struct i2s_dai *i2s)
 static inline void set_bfs(struct i2s_dai *i2s, unsigned bfs)
 {
 	u32 mod = readl(i2s->addr + I2SMOD);
+	int bfs_shift;
+	int tdm = i2s->quirks & QUIRK_SUPPORTS_TDM;
 
-	mod &= ~MOD_BCLK_MASK;
+	if (tdm) {
+		bfs_shift = EXYNOS5420_MOD_BCLK_SHIFT;
+		mod &= ~(EXYNOS5420_MOD_BCLK_MASK << bfs_shift);
+	} else {
+		bfs_shift = MOD_BCLK_SHIFT;
+		mod &= ~(MOD_BCLK_MASK << bfs_shift);
+	}
+
+	/* Non-TDM I2S controllers do not support BCLK > 48 * FS */
+	if (!tdm && bfs > 48) {
+		dev_err(&i2s->pdev->dev, "Unsupported BCLK divider\n");
+		return;
+	}
 
 	switch (bfs) {
 	case 48:
-		mod |= MOD_BCLK_48FS;
+		mod |= (MOD_BCLK_48FS << bfs_shift);
 		break;
 	case 32:
-		mod |= MOD_BCLK_32FS;
+		mod |= (MOD_BCLK_32FS << bfs_shift);
 		break;
 	case 24:
-		mod |= MOD_BCLK_24FS;
+		mod |= (MOD_BCLK_24FS << bfs_shift);
 		break;
 	case 16:
-		mod |= MOD_BCLK_16FS;
+		mod |= (MOD_BCLK_16FS << bfs_shift);
+		break;
+	case 64:
+		mod |= (EXYNOS5420_MOD_BCLK_64FS << bfs_shift);
+		break;
+	case 96:
+		mod |= (EXYNOS5420_MOD_BCLK_96FS << bfs_shift);
+		break;
+	case 128:
+		mod |= (EXYNOS5420_MOD_BCLK_128FS << bfs_shift);
+		break;
+	case 192:
+		mod |= (EXYNOS5420_MOD_BCLK_192FS << bfs_shift);
+		break;
+	case 256:
+		mod |= (EXYNOS5420_MOD_BCLK_256FS << bfs_shift);
 		break;
 	default:
 		dev_err(&i2s->pdev->dev, "Wrong BCLK Divider!\n");
@@ -492,19 +545,31 @@ static int i2s_set_fmt(struct snd_soc_dai *dai,
 	struct i2s_dai *i2s = to_info(dai);
 	u32 mod = readl(i2s->addr + I2SMOD);
 	u32 tmp = 0;
+	int lrp_shift, sdf_shift, sdf_mask, lrp_rlow;
+
+	if (i2s->quirks & QUIRK_SUPPORTS_TDM) {
+		lrp_shift = EXYNOS5420_MOD_LRP_SHIFT;
+		sdf_shift = EXYNOS5420_MOD_SDF_SHIFT;
+	} else {
+		lrp_shift = MOD_LRP_SHIFT;
+		sdf_shift = MOD_SDF_SHIFT;
+	}
+
+	sdf_mask = MOD_SDF_MASK << sdf_shift;
+	lrp_rlow = MOD_LR_RLOW << lrp_shift;
 
 	/* Format is priority */
 	switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
 	case SND_SOC_DAIFMT_RIGHT_J:
-		tmp |= MOD_LR_RLOW;
-		tmp |= MOD_SDF_MSB;
+		tmp |= lrp_rlow;
+		tmp |= (MOD_SDF_MSB << sdf_shift);
 		break;
 	case SND_SOC_DAIFMT_LEFT_J:
-		tmp |= MOD_LR_RLOW;
-		tmp |= MOD_SDF_LSB;
+		tmp |= lrp_rlow;
+		tmp |= (MOD_SDF_LSB << sdf_shift);
 		break;
 	case SND_SOC_DAIFMT_I2S:
-		tmp |= MOD_SDF_IIS;
+		tmp |= (MOD_SDF_IIS << sdf_shift);
 		break;
 	default:
 		dev_err(&i2s->pdev->dev, "Format not supported\n");
@@ -519,10 +584,10 @@ static int i2s_set_fmt(struct snd_soc_dai *dai,
 	case SND_SOC_DAIFMT_NB_NF:
 		break;
 	case SND_SOC_DAIFMT_NB_IF:
-		if (tmp & MOD_LR_RLOW)
-			tmp &= ~MOD_LR_RLOW;
+		if (tmp & lrp_rlow)
+			tmp &= ~lrp_rlow;
 		else
-			tmp |= MOD_LR_RLOW;
+			tmp |= lrp_rlow;
 		break;
 	default:
 		dev_err(&i2s->pdev->dev, "Polarity not supported\n");
@@ -544,15 +609,18 @@ static int i2s_set_fmt(struct snd_soc_dai *dai,
 		return -EINVAL;
 	}
 
+	/*
+	 * Don't change the I2S mode if any controller is active on this
+	 * channel.
+	 */
 	if (any_active(i2s) &&
-			((mod & (MOD_SDF_MASK | MOD_LR_RLOW
-				| MOD_SLAVE)) != tmp)) {
+	    ((mod & (sdf_mask | lrp_rlow | MOD_SLAVE)) != tmp)) {
 		dev_err(&i2s->pdev->dev,
 				"%s:%d Other DAI busy\n", __func__, __LINE__);
 		return -EAGAIN;
 	}
 
-	mod &= ~(MOD_SDF_MASK | MOD_LR_RLOW | MOD_SLAVE);
+	mod &= ~(sdf_mask | lrp_rlow | MOD_SLAVE);
 	mod |= tmp;
 	writel(mod, i2s->addr + I2SMOD);
 
@@ -1170,6 +1238,9 @@ static int samsung_i2s_probe(struct platform_device *pdev)
 		if (of_find_property(np, "samsung,supports-rstclr", NULL))
 			quirks |= QUIRK_NEED_RSTCLR;
 
+		if (of_find_property(np, "samsung,supports-tdm", NULL))
+			quirks |= QUIRK_SUPPORTS_TDM;
+
 		if (of_property_read_u32(np, "samsung,idma-addr",
 					 &idma_addr)) {
 			if (quirks & QUIRK_SEC_DAI) {
-- 
1.7.4.4



From valentin.longchamp at keymile.com  Thu Jul 11 03:03:59 2013
From: valentin.longchamp at keymile.com (Valentin Longchamp)
Date: Thu, 11 Jul 2013 09:03:59 +0200
Subject: pci-mvebu driver on km_kirkwood
In-Reply-To: <51DD9A8C.10608@keymile.com>
References: <51DD88A4.1030506@keymile.com> <20130710185706.72b124a4@skate>
 <51DD9A8C.10608@keymile.com>
Message-ID: <51DE58DF.5010304@keymile.com>

Hi Gerlando,

I just want to give further information about  the hardware and memory mapping
we have with these kirkwood variants in our system.

As I told you yesterday, I think it's very important to have a clear view of the
actual memory map when setting these ranges.

On 07/10/2013 07:31 PM, Falauto, Gerlando wrote:
> Hi Thomas,
> 
> first of all thanks for your quick feedback.
> 
> On 07/10/2013 06:57 PM, Thomas Petazzoni wrote:
>> Gerlando,
>>
>> On Wed, 10 Jul 2013 18:15:32 +0200, Gerlando Falauto wrote:
>>
>>> I am trying to use the pci-mvebu driver on one of our km_kirkwood
>>> boards. The board is based on Marvell's 98dx4122, which should
>>> essentially be 6281 compatible.
>>
>> Was this platform working with the old PCIe driver in mach-kirkwood/ ?
> 
> Yes, though we had to trick it a little bit to get both the internal 
> switch and this PCIe device working:
> 
> - this PCIe device requires to map 256M of memory as opposed to just 128

On the board you are currently using for your tests, it is the case (the whole
map is not used ... things are scattered over the 256 MB, with one 128MB BAR).
If you want to get rid of this problem, we have another board that does not
require these (256 MB .. and I have one of them on my desk that you can use for
your tests).

On the kirkwood variant we use, there is only _one_ real PCIe controller. In
order to map 256MB for the MEM space of this controller without having further
memory map conflicts, what was done was to not enable the CPU windows for the
usual 2nd PCIe controller and set a wider CPU window for the MEM space of the
only PCIe controller.

> - we need a virtual PCIe device to connect to the internal switch, which 
> must be mapped at 0xf4000000 (normally used for the NAND which must then 
> move to 0xff000000)
> 

I think you can forget this for the time being. This is called (also in
Marvell's doc) a virtual PCIe controller, but apart that it is then memory
mapped, this has nothing to do with PCIe (although I don't know what is done
internally in the SoC). It is a problem because the physical address chosen for
this CPU window conflicts with the one that is used for the NAND controller in
the current kirkwood Linux memory map. But this is another topic and it should
not play any role in this PCIe topic.

I hope this helps also the other better understand what's going on here.

Valentin


From pekon at ti.com  Thu Jul 11 03:06:19 2013
From: pekon at ti.com (Gupta, Pekon)
Date: Thu, 11 Jul 2013 07:06:19 +0000
Subject: [PATCH RFC 13/13] ARM: OMAP2+: hwmod: AM43x: new w.r.t AM335x
In-Reply-To: <0bb1eb7339ac9fd78c8251f71082ac3b3add3ad2.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
 <0bb1eb7339ac9fd78c8251f71082ac3b3add3ad2.1373519192.git.afzal@ti.com>
Message-ID: <20980858CB6D3A4BAE95CA194937D5E73E9E5F88@DBDE04.ent.ti.com>

> 
> 4. pka
> 5. des
> 6. Rng
Needs some re-wording..
PKA, DES, RNG are there on AM335x silicon.

with regards, pekon


From mkl at pengutronix.de  Thu Jul 11 03:24:56 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Thu, 11 Jul 2013 09:24:56 +0200
Subject: [PATCH v12 10/13] usb: chipidea: add wait vbus lower than
 OTGSC_BSV before role starts
In-Reply-To: <1373524041-10482-11-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <1373524041-10482-11-git-send-email-peter.chen@freescale.com>
Message-ID: <51DE5DC8.8020605@pengutronix.de>

On 07/11/2013 08:27 AM, Peter Chen wrote:
> When the gadget role starts, we need to make sure the vbus is lower
> than OTGSC_BSV, or there will be an vbus interrupt since we use
> B_SESSION_VALID as vbus interrupt to indicate connect and disconnect.
> When the host role starts, it may not be useful to wait vbus to lower
> than OTGSC_BSV, but it can indicate some hardware problems like the
> vbus is still higher than OTGSC_BSV after we disconnect to host some
> time later (500 jiffies currently), which is obvious not correct.

Jiffies ist not constant. I think you have to specify the timeout in
fractions of HZ. The system ticks with HZ jiffies per second. So a
timeout of 500ms is "HZ / 2".

Marc

> 
> Signed-off-by: Peter Chen <peter.chen at freescale.com>
> ---
>  drivers/usb/chipidea/ci.h   |    3 +++
>  drivers/usb/chipidea/core.c |   32 ++++++++++++++++++++++++++++++++
>  drivers/usb/chipidea/otg.c  |    4 ++++
>  3 files changed, 39 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 3160363..df27696 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -308,4 +308,7 @@ int hw_port_test_set(struct ci_hdrc *ci, u8 mode);
>  
>  u8 hw_port_test_get(struct ci_hdrc *ci);
>  
> +int hw_wait_reg(struct ci_hdrc *ci, enum ci_hw_regs reg, u32 mask,
> +				u32 value, unsigned long timeout);
> +
>  #endif	/* __DRIVERS_USB_CHIPIDEA_CI_H */
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 7a07300..1c39541 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -295,6 +295,38 @@ int hw_device_reset(struct ci_hdrc *ci, u32 mode)
>  	return 0;
>  }
>  
> +/**
> + * hw_wait_reg: wait the register value
> + *
> + * Sometimes, it needs to wait register value before going on.
> + * Eg, when switch to device mode, the vbus value should be lower
> + * than OTGSC_BSV before connects to host.
> + *
> + * @ci: the controller
> + * @reg: register index
> + * @mask: mast bit
> + * @value: the bit value to wait
> + * @timeout: timeout to indicate an error
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Better: timeout in jiffies

> + *
> + * This function returns an error code if timeout
> + */
> +int hw_wait_reg(struct ci_hdrc *ci, enum ci_hw_regs reg, u32 mask,
> +				u32 value, unsigned long timeout)
> +{
> +	unsigned long elapse = jiffies + timeout;
> +
> +	while (hw_read(ci, reg, mask) != value) {
> +		if (time_after(jiffies, elapse)) {
> +			dev_err(ci->dev, "timeout waiting for %08x in %d\n",
> +					mask, reg);
> +			return -ETIMEDOUT;
> +		}
> +		msleep(20);
> +	}
> +
> +	return 0;
> +}
> +
>  static irqreturn_t ci_irq(int irq, void *data)
>  {
>  	struct ci_hdrc *ci = data;
> diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
> index c74194d..8aa0241 100644
> --- a/drivers/usb/chipidea/otg.c
> +++ b/drivers/usb/chipidea/otg.c
> @@ -67,6 +67,7 @@ void ci_handle_vbus_change(struct ci_hdrc *ci)
>  		usb_gadget_vbus_disconnect(&ci->gadget);
>  }
>  
> +#define CI_VBUS_STABLE_TIMEOUT 500
>  static void ci_handle_id_switch(struct ci_hdrc *ci)
>  {
>  	enum ci_role role = ci_otg_role(ci);
> @@ -76,6 +77,9 @@ static void ci_handle_id_switch(struct ci_hdrc *ci)
>  			ci_role(ci)->name, ci->roles[role]->name);
>  
>  		ci_role_stop(ci);
> +		/* wait vbus lower than OTGSC_BSV */
> +		hw_wait_reg(ci, OP_OTGSC, OTGSC_BSV, 0,
> +				CI_VBUS_STABLE_TIMEOUT);
>  		ci_role_start(ci, role);
>  	}
>  }
> 


-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130711/cb139f86/attachment.sig>

From rogerq at ti.com  Thu Jul 11 03:30:07 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 11 Jul 2013 10:30:07 +0300
Subject: [PATCH 5/6] USB: Support wakeup IRQ for suspended controllers
In-Reply-To: <Pine.LNX.4.44L0.1307101440140.1215-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307101440140.1215-100000@iolanthe.rowland.org>
Message-ID: <51DE5EFF.5080005@ti.com>

On 07/10/2013 09:45 PM, Alan Stern wrote:
> On Wed, 10 Jul 2013, Roger Quadros wrote:
> 
>> Some platforms e.g. ehci-omap can generate an interrupt
>> (i.e. remote wakeup) even when the controller is suspended i.e.
>> HW_ACCESSIBLE is cleared.
>>
>> Introduce a flag "has_wakeup_irq" in struct usb_hcd to indicate
>> such cases.
>>
>> We tackle this case by disabling the IRQ, scheduling a
>> hub resume and enabling back the IRQ after the controller has
>> resumed. This ensures that the IRQ handler runs only after the
>> controller is accessible.
> 
>> @@ -2248,7 +2253,21 @@ irqreturn_t usb_hcd_irq (int irq, void *__hcd)
>>  	 */
>>  	local_irq_save(flags);
>>  
>> -	if (unlikely(HCD_DEAD(hcd) || !HCD_HW_ACCESSIBLE(hcd)))
>> +	if (unlikely(HCD_DEAD(hcd)))
>> +		rc = IRQ_NONE;
>> +	else if (unlikely(!HCD_HW_ACCESSIBLE(hcd) && hcd->has_wakeup_irq)) {
>> +		/*
>> +		 * We got a wakeup interrupt while the controller was
>> +		 * suspending or suspended.  We can't handle it now, so
>> +		 * disable the IRQ and resume the root hub (and hence
>> +		 * the controller too).
>> +		 */
>> +		disable_irq_nosync(hcd->irq);
>> +		set_bit(HCD_FLAG_IRQ_DISABLED, &hcd->flags);
>> +		usb_hcd_resume_root_hub(hcd);
>> +
>> +		rc = IRQ_HANDLED;
>> +	} else if (unlikely(!HCD_HW_ACCESSIBLE(hcd)))
>>  		rc = IRQ_NONE;
> 
> In the interest of minimizing the amount of work needed in the most 
> common case, this should be written as:
> 
> 	else if (unlikely(!HCD_HW_ACCESSIBLE(hcd))) {
> 		if (hcd->has_wakeup_irq) {
> 			...
> 		} else
> 			rc = IRQ_NONE;
> 

OK.

>>  	else if (hcd->driver->irq(hcd) == IRQ_NONE)
>>  		rc = IRQ_NONE;
> 
> Apart from that, the patch is okay.  When you rearrange the logic, you 
> can add my Acked-by.
> 
Thanks.

cheers,
-roger


From rogerq at ti.com  Thu Jul 11 03:30:35 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 11 Jul 2013 10:30:35 +0300
Subject: [PATCH 5/6] USB: Support wakeup IRQ for suspended controllers
In-Reply-To: <Pine.LNX.4.44L0.1307101504220.1215-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307101504220.1215-100000@iolanthe.rowland.org>
Message-ID: <51DE5F1B.8080201@ti.com>

On 07/10/2013 10:08 PM, Alan Stern wrote:
> On Wed, 10 Jul 2013, Roger Quadros wrote:
> 
>> Some platforms e.g. ehci-omap can generate an interrupt
>> (i.e. remote wakeup) even when the controller is suspended i.e.
>> HW_ACCESSIBLE is cleared.
>>
>> Introduce a flag "has_wakeup_irq" in struct usb_hcd to indicate
>> such cases.
>>
>> We tackle this case by disabling the IRQ, scheduling a
>> hub resume and enabling back the IRQ after the controller has
>> resumed. This ensures that the IRQ handler runs only after the
>> controller is accessible.
> 
> Oh yes, one more thing...
> 
>> @@ -132,6 +134,7 @@ struct usb_hcd {
>>  	unsigned		wireless:1;	/* Wireless USB HCD */
>>  	unsigned		authorized_default:1;
>>  	unsigned		has_tt:1;	/* Integrated TT in root hub */
>> +	unsigned		has_wakeup_irq:1; /* Can IRQ when suspended */
> 
> Please add a highly visible comment here, warning that has_wakeup_irq
> should never be set on systems with shared IRQs.  Having both would ...
> well, it would indicate a really bad system design.
> 
OK, will do.

cheers,
-roger


From tomasz.figa at gmail.com  Thu Jul 11 03:46:53 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 11 Jul 2013 09:46:53 +0200
Subject: [PATCH v2 1/6] clk: samsung: move common plls registration into
 separate function
In-Reply-To: <CAKew6eUPBUZj4TuhNAjp6NitFUaeFBZscr_jqU3Y_wLi1m7Ekg@mail.gmail.com>
References: <201307100057.06061.heiko@sntech.de>
 <201307100057.48265.heiko@sntech.de>
 <CAKew6eUPBUZj4TuhNAjp6NitFUaeFBZscr_jqU3Y_wLi1m7Ekg@mail.gmail.com>
Message-ID: <1874409.iWz7oWBuYA@thinkpad>

Hi,

On Wednesday 10 of July 2013 22:29:13 Yadwinder Singh Brar wrote:
> Hi Heiko,
> 
> On Wed, Jul 10, 2013 at 4:27 AM, Heiko St?bner <heiko at sntech.de> wrote:
> > All Samsung PLLs use similar code to register the clocks and clkdev
> > lookups. Therefore move these into a separate function to reduce code
> > duplication.
> > 
> > Suggested-by: Russell King <linux at arm.linux.org.uk>
> > Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> > ---
> 
> I have posted patch for adding common pll registration function
> which some how missed to get merged. I hope will get merged after rc1.
> Please give a look at that :
> http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg19543.html

Yeah, I was going to post a link to it, but I couldn't find it on any mailing 
list archive. I think we should go with the way of registration introduced by 
Yadwinder.

Best regards,
Tomasz


From r65037 at freescale.com  Thu Jul 11 03:50:50 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Thu, 11 Jul 2013 07:50:50 +0000
Subject: [v4 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <20130710210414.GK516@pengutronix.de>
References: <1373445355-11453-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373445355-11453-4-git-send-email-Hong-Xing.Zhu@freescale.com>
 <20130710210414.GK516@pengutronix.de>
Message-ID: <0E83723C55F66F43A6041464FE31119D32AE6B@039-SN2MPN1-013.039d.mgd.msft.net>

Hi Sascha:
Sorry to make a mess on the usage of the private data.
The private data of "imx_ahci_pdev" platform device would be used to store ata_host point.
I shouldn't set imxpriv to the private data of "imx_ahci_pdev", so do the wrong assignment of
The private pointer of device.

Best Regards
Richard Zhu


-----Original Message-----
From: Sascha Hauer [mailto:s.hauer at pengutronix.de] 
Sent: Thursday, July 11, 2013 5:04 AM
To: Richard Zhu
Cc: shawn.guo at linaro.org; linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; tj at kernel.org; rob.herring at calxeda.com; linux-ide at vger.kernel.org; Zhu Richard-R65037
Subject: Re: [v4 3/3] sata: imx: add ahci sata support on imx platforms

On Wed, Jul 10, 2013 at 04:35:55PM +0800, Richard Zhu wrote:
> From: Richard Zhu <r65037 at freescale.com>
> 
> imx6q contains one Synopsys AHCI SATA controller, But it can't shares 
> ahci_platform driver with other controllers.
> Because there are some misalignments of the generic AHCI controller.
> The bits definitions of the HBA registers, the Vendor Specific 
> registers, and the AHCI PHY clock.
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default  value is '0', 
> should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the  HOST_PORTS_IMPL 
> should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)  should be 
> configured regarding to the frequency of AHB  bus clock.
>  - Configurations of the AHCI PHY clock, and the signal  parameters of 
> the GPR13
> 
> Setup its own ahci sata driver, contained the imx6q specific 
> initialized codes, and re-use the generic ahci_platform drier,
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  drivers/ata/Kconfig    |    9 ++
>  drivers/ata/Makefile   |    1 +
>  drivers/ata/sata_imx.c |  237 
> ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 247 insertions(+), 0 deletions(-)  create mode 
> 100644 drivers/ata/sata_imx.c
> 

[...]

> +
> +/* imx6q ahci module initialization. */ static int 
> +imx6q_sata_init(struct device *dev, void __iomem *mmio) {
> +	int ret = 0;
> +	unsigned int rc;
> +	struct regmap *gpr;
> +	struct clk *ahb_clk;
> +	struct imx_ahci_priv *imxpriv = (struct imx_ahci_priv *)dev->p;

Just because a pointer points to valid memory doesn't mean that it's free to use for your purposes. If you look closer maybe you realize that the imxpriv pointer you use here is another one than the one you allocate below in your probe function.

I give up here. Maybe I'll write a driver for this when I find time for it.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |




From tomasz.figa at gmail.com  Thu Jul 11 03:50:16 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 11 Jul 2013 09:50:16 +0200
Subject: [PATCH v2 2/6] clk: samsung: fix error handling in pll register
 functions
In-Reply-To: <201307100058.13941.heiko@sntech.de>
References: <201307100057.06061.heiko@sntech.de>
 <201307100058.13941.heiko@sntech.de>
Message-ID: <1418034.CJ7vtBLiog@thinkpad>

Hi Heiko,

On Wednesday 10 of July 2013 00:58:13 Heiko St?bner wrote:
> kmalloc has its own error reporting when the allocation fails and
> the register functions also should return the correct ERR_PTR(-ENOMEM)
> when it happens.
> 
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> ---
>  drivers/clk/samsung/clk-pll.c |   30 ++++++++++--------------------
>  1 file changed, 10 insertions(+), 20 deletions(-)

This patch looks pretty good, but I'm not sure if this problem still exists 
after applying Yadwinder's patches that completely changes the way of PLL 
registration.

Best regards,
Tomasz

> diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
> index 9153e46..0afaec6 100644
> --- a/drivers/clk/samsung/clk-pll.c
> +++ b/drivers/clk/samsung/clk-pll.c
> @@ -79,10 +79,8 @@ struct clk * __init samsung_clk_register_pll35xx(const
> char *name, struct clk_init_data init;
> 
>  	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> -	if (!pll) {
> -		pr_err("%s: could not allocate pll clk %s\n", __func__, name);
> -		return NULL;
> -	}
> +	if (!pll)
> +		return ERR_PTR(-ENOMEM);
> 
>  	init.name = name;
>  	init.ops = &samsung_pll35xx_clk_ops;
> @@ -153,10 +151,8 @@ struct clk * __init samsung_clk_register_pll36xx(const
> char *name, struct clk_init_data init;
> 
>  	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> -	if (!pll) {
> -		pr_err("%s: could not allocate pll clk %s\n", __func__, name);
> -		return NULL;
> -	}
> +	if (!pll)
> +		return ERR_PTR(-ENOMEM);
> 
>  	init.name = name;
>  	init.ops = &samsung_pll36xx_clk_ops;
> @@ -227,10 +223,8 @@ struct clk * __init samsung_clk_register_pll45xx(const
> char *name, struct clk_init_data init;
> 
>  	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> -	if (!pll) {
> -		pr_err("%s: could not allocate pll clk %s\n", __func__, name);
> -		return NULL;
> -	}
> +	if (!pll)
> +		return ERR_PTR(-ENOMEM);
> 
>  	init.name = name;
>  	init.ops = &samsung_pll45xx_clk_ops;
> @@ -308,10 +302,8 @@ struct clk * __init samsung_clk_register_pll46xx(const
> char *name, struct clk_init_data init;
> 
>  	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> -	if (!pll) {
> -		pr_err("%s: could not allocate pll clk %s\n", __func__, name);
> -		return NULL;
> -	}
> +	if (!pll)
> +		return ERR_PTR(-ENOMEM);
> 
>  	init.name = name;
>  	init.ops = &samsung_pll46xx_clk_ops;
> @@ -385,10 +377,8 @@ struct clk * __init samsung_clk_register_pll2550x(const
> char *name, struct clk_init_data init;
> 
>  	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> -	if (!pll) {
> -		pr_err("%s: could not allocate pll clk %s\n", __func__, name);
> -		return NULL;
> -	}
> +	if (!pll)
> +		return ERR_PTR(-ENOMEM);
> 
>  	init.name = name;
>  	init.ops = &samsung_pll2550x_clk_ops;


From s.hauer at pengutronix.de  Thu Jul 11 03:55:43 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 11 Jul 2013 09:55:43 +0200
Subject: [v4 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <0E83723C55F66F43A6041464FE31119D32AE6B@039-SN2MPN1-013.039d.mgd.msft.net>
References: <1373445355-11453-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373445355-11453-4-git-send-email-Hong-Xing.Zhu@freescale.com>
 <20130710210414.GK516@pengutronix.de>
 <0E83723C55F66F43A6041464FE31119D32AE6B@039-SN2MPN1-013.039d.mgd.msft.net>
Message-ID: <20130711075543.GG14452@pengutronix.de>

Hi Richard,

On Thu, Jul 11, 2013 at 07:50:50AM +0000, Zhu Richard-R65037 wrote:
> Hi Sascha:
> Sorry to make a mess on the usage of the private data.
> The private data of "imx_ahci_pdev" platform device would be used to store ata_host point.
> I shouldn't set imxpriv to the private data of "imx_ahci_pdev", so do the wrong assignment of
> The private pointer of device.

Please allocate your private data along with the platform_device in the
probe function, then in the init callback you can use container_of() to
get a pointer to the data.
Also I would recommend you to request the necessary resources (clocks,
regmap) in the probe function and not in the init callback.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From tomasz.figa at gmail.com  Thu Jul 11 04:16:41 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 11 Jul 2013 10:16:41 +0200
Subject: [PATCH v2 3/6] clk: samsung: add plls used in s3c2416 and s3c2443
In-Reply-To: <201307100059.08621.heiko@sntech.de>
References: <201307100057.06061.heiko@sntech.de>
 <201307100059.08621.heiko@sntech.de>
Message-ID: <1525015.XUBJYYqnvA@thinkpad>

Hi Heiko,

On Wednesday 10 of July 2013 00:59:08 Heiko St?bner wrote:
> This adds support for pll2126x, pll3000x, pll6552x and pll6553x.
> 
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> ---
>  drivers/clk/samsung/clk-pll.c |  280
> +++++++++++++++++++++++++++++++++++++++++ drivers/clk/samsung/clk-pll.h |  
>  8 ++
>  2 files changed, 288 insertions(+)

Generally the patch looks good, but I have some comments to the part related 
to 655xx PLLs.

I had a patch adding support for them too, but we can go with yours, since the 
way of registration has been changed by Yadwinder's patches and mine would 
have to be updated anyway.

> diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
> index 0afaec6..35c15a1 100644
> --- a/drivers/clk/samsung/clk-pll.c
> +++ b/drivers/clk/samsung/clk-pll.c
> @@ -323,6 +323,73 @@ struct clk * __init samsung_clk_register_pll46xx(const
> char *name, }
> 
>  /*
> + * PLL2126x Clock Type
> + */
> +
> +#define PLL2126X_MDIV_MASK	(0xFF)
> +#define PLL2126X_PDIV_MASK	(0x3)
> +#define PLL2126X_SDIV_MASK	(0x3)
> +#define PLL2126X_MDIV_SHIFT	(16)
> +#define PLL2126X_PDIV_SHIFT	(8)
> +#define PLL2126X_SDIV_SHIFT	(0)
> +
> +struct samsung_clk_pll2126x {
> +	struct clk_hw		hw;
> +	const void __iomem	*con_reg;
> +};
> +
> +#define to_clk_pll2126x(_hw) container_of(_hw, struct samsung_clk_pll2126x,
> hw) +
> +static unsigned long samsung_pll2126x_recalc_rate(struct clk_hw *hw,
> +				unsigned long parent_rate)
> +{
> +	struct samsung_clk_pll2126x *pll = to_clk_pll2126x(hw);
> +	u32 pll_con, mdiv, pdiv, sdiv;
> +	u64 fvco = parent_rate;
> +
> +	pll_con = __raw_readl(pll->con_reg);
> +	mdiv = (pll_con >> PLL2126X_MDIV_SHIFT) & PLL2126X_MDIV_MASK;
> +	pdiv = (pll_con >> PLL2126X_PDIV_SHIFT) & PLL2126X_PDIV_MASK;
> +	sdiv = (pll_con >> PLL2126X_SDIV_SHIFT) & PLL2126X_SDIV_MASK;
> +
> +	fvco *= (mdiv + 8);
> +	do_div(fvco, (pdiv + 2) << sdiv);
> +
> +	return (unsigned long)fvco;
> +}
> +
> +static const struct clk_ops samsung_pll2126x_clk_ops = {
> +	.recalc_rate = samsung_pll2126x_recalc_rate,
> +};
> +
> +struct clk * __init samsung_clk_register_pll2126x(const char *name,
> +			const char *pname, const void __iomem *con_reg)
> +{
> +	struct samsung_clk_pll2126x *pll;
> +	struct clk *clk;
> +	struct clk_init_data init;
> +
> +	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> +	if (!pll)
> +		return ERR_PTR(-ENOMEM);
> +
> +	init.name = name;
> +	init.ops = &samsung_pll2126x_clk_ops;
> +	init.flags = CLK_GET_RATE_NOCACHE;
> +	init.parent_names = &pname;
> +	init.num_parents = 1;
> +
> +	pll->hw.init = &init;
> +	pll->con_reg = con_reg;
> +
> +	clk = samsung_register_pll(&pll->hw);
> +	if (IS_ERR(clk))
> +		kfree(pll);
> +
> +	return clk;
> +}
> +
> +/*
>   * PLL2550x Clock Type
>   */
> 
> @@ -396,3 +463,216 @@ struct clk * __init
> samsung_clk_register_pll2550x(const char *name,
> 
>  	return clk;
>  }
> +
> +/*
> + * PLL3000x Clock Type
> + */
> +
> +#define PLL3000X_MDIV_MASK	(0xFF)
> +#define PLL3000X_PDIV_MASK	(0x3)
> +#define PLL3000X_SDIV_MASK	(0x3)
> +#define PLL3000X_MDIV_SHIFT	(16)
> +#define PLL3000X_PDIV_SHIFT	(8)
> +#define PLL3000X_SDIV_SHIFT	(0)
> +
> +struct samsung_clk_pll3000x {
> +	struct clk_hw		hw;
> +	const void __iomem	*con_reg;
> +};
> +
> +#define to_clk_pll3000x(_hw) container_of(_hw, struct samsung_clk_pll3000x,
> hw) +
> +static unsigned long samsung_pll3000x_recalc_rate(struct clk_hw *hw,
> +				unsigned long parent_rate)
> +{
> +	struct samsung_clk_pll3000x *pll = to_clk_pll3000x(hw);
> +	u32 pll_con, mdiv, pdiv, sdiv;
> +	u64 fvco = parent_rate;
> +
> +	pll_con = __raw_readl(pll->con_reg);
> +	mdiv = (pll_con >> PLL3000X_MDIV_SHIFT) & PLL3000X_MDIV_MASK;
> +	pdiv = (pll_con >> PLL3000X_PDIV_SHIFT) & PLL3000X_PDIV_MASK;
> +	sdiv = (pll_con >> PLL3000X_SDIV_SHIFT) & PLL3000X_SDIV_MASK;
> +
> +	fvco *= (2 * (mdiv + 8));
> +	do_div(fvco, pdiv << sdiv);
> +
> +	return (unsigned long)fvco;
> +}
> +
> +static const struct clk_ops samsung_pll3000x_clk_ops = {
> +	.recalc_rate = samsung_pll3000x_recalc_rate,
> +};
> +
> +struct clk * __init samsung_clk_register_pll3000x(const char *name,
> +			const char *pname, const void __iomem *con_reg)
> +{
> +	struct samsung_clk_pll3000x *pll;
> +	struct clk *clk;
> +	struct clk_init_data init;
> +
> +	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> +	if (!pll)
> +		return ERR_PTR(-ENOMEM);
> +
> +	init.name = name;
> +	init.ops = &samsung_pll3000x_clk_ops;
> +	init.flags = CLK_GET_RATE_NOCACHE;
> +	init.parent_names = &pname;
> +	init.num_parents = 1;
> +
> +	pll->hw.init = &init;
> +	pll->con_reg = con_reg;
> +
> +	clk = samsung_register_pll(&pll->hw);
> +	if (IS_ERR(clk))
> +		kfree(pll);
> +
> +	return clk;
> +}
> +
> +/*
> + * PLL6552x Clock Type
> + */
> +
> +#define PLL6552X_MDIV_MASK	(0x3FF)
> +#define PLL6552X_PDIV_MASK	(0x3F)
> +#define PLL6552X_SDIV_MASK	(0x7)
> +#define PLL6552X_MDIV_SHIFT	(14)
> +#define PLL6552X_PDIV_SHIFT	(5)
> +#define PLL6552X_SDIV_SHIFT	(0)

Are you sure about those bitfields?

In S3C6410 User's Manual they are different. You can look at my patch for a 
comparison:

http://thread.gmane.org/gmane.linux.usb.general/87571/focus=88344

> +struct samsung_clk_pll6552x {
> +	struct clk_hw		hw;
> +	const void __iomem	*con_reg;
> +};
> +
> +#define to_clk_pll6552x(_hw) container_of(_hw, struct samsung_clk_pll6552x,
> hw) +
> +static unsigned long samsung_pll6552x_recalc_rate(struct clk_hw *hw,
> +				unsigned long parent_rate)
> +{
> +	struct samsung_clk_pll6552x *pll = to_clk_pll6552x(hw);
> +	u32 pll_con, mdiv, pdiv, sdiv;
> +	u64 fvco = parent_rate;
> +
> +	pll_con = __raw_readl(pll->con_reg);
> +	mdiv = (pll_con >> PLL6552X_MDIV_SHIFT) & PLL6552X_MDIV_MASK;
> +	pdiv = (pll_con >> PLL6552X_PDIV_SHIFT) & PLL6552X_PDIV_MASK;
> +	sdiv = (pll_con >> PLL6552X_SDIV_SHIFT) & PLL6552X_SDIV_MASK;
> +
> +	fvco *= mdiv;
> +	do_div(fvco, (pdiv << sdiv));
> +
> +	return (unsigned long)fvco;
> +}
> +
> +static const struct clk_ops samsung_pll6552x_clk_ops = {
> +	.recalc_rate = samsung_pll6552x_recalc_rate,
> +};
> +
> +struct clk * __init samsung_clk_register_pll6552x(const char *name,
> +			const char *pname, const void __iomem *con_reg)
> +{
> +	struct samsung_clk_pll6552x *pll;
> +	struct clk *clk;
> +	struct clk_init_data init;
> +
> +	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> +	if (!pll)
> +		return ERR_PTR(-ENOMEM);
> +
> +	init.name = name;
> +	init.ops = &samsung_pll6552x_clk_ops;
> +	init.flags = CLK_GET_RATE_NOCACHE;
> +	init.parent_names = &pname;
> +	init.num_parents = 1;
> +
> +	pll->hw.init = &init;
> +	pll->con_reg = con_reg;
> +
> +	clk = samsung_register_pll(&pll->hw);
> +	if (IS_ERR(clk))
> +		kfree(pll);
> +
> +	return clk;
> +}
> +
> +/*
> + * PLL6553x Clock Type
> + */
> +
> +#define PLL6553X_MDIV_MASK	(0x7F)
> +#define PLL6553X_PDIV_MASK	(0x1F)
> +#define PLL6553X_SDIV_MASK	(0x3)
> +#define PLL6553X_KDIV_MASK	(0xFFFF)
> +#define PLL6553X_MDIV_SHIFT	(16)
> +#define PLL6553X_PDIV_SHIFT	(8)
> +#define PLL6553X_SDIV_SHIFT	(0)

Same about those bitfields. They seem to be different on S3C64xx.

Best regards,
Tomasz



From ulrich.hecht at gmail.com  Thu Jul 11 04:40:19 2013
From: ulrich.hecht at gmail.com (Ulrich Hecht)
Date: Thu, 11 Jul 2013 10:40:19 +0200
Subject: [PATCH 00/02] ARM: shmobile: r8a7790 arch timer frequency update
In-Reply-To: <20130710022103.GR32603@verge.net.au>
References: <20130709125007.4388.15701.sendpatchset@w520>
 <20130710012346.GT32603@verge.net.au>
 <CANqRtoSHk_LJ6AyFqHYPy6w-As3XN=3Peku08gDMoEcz5MoRHQ@mail.gmail.com>
 <20130710022103.GR32603@verge.net.au>
Message-ID: <CAO3366wTa8=7yO9jkp36v8v2cKr13agUWkL6FfdR=h8jgiTBYw@mail.gmail.com>

On Wed, Jul 10, 2013 at 4:21 AM, Simon Horman <horms at verge.net.au> wrote:
> On Wed, Jul 10, 2013 at 11:12:25AM +0900, Magnus Damm wrote:
>> I can resend 1/2 today or tomorrow and I think Ulrich can most likely
>> help us with testing sometime this week.
>
> Thanks, I'll wait for your repost and feedback from Ulrich.

Works for me, "sleep 10" actually sleeps for 10 seconds now.

Tested-by: Ulrich Hecht <ulrich.hecht at gmail.com>

CU
Uli


From heiko at sntech.de  Thu Jul 11 04:50:39 2013
From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=)
Date: Thu, 11 Jul 2013 10:50:39 +0200
Subject: [PATCH v2 3/6] clk: samsung: add plls used in s3c2416 and s3c2443
In-Reply-To: <1525015.XUBJYYqnvA@thinkpad>
References: <201307100057.06061.heiko@sntech.de>
 <201307100059.08621.heiko@sntech.de> <1525015.XUBJYYqnvA@thinkpad>
Message-ID: <201307111050.39878.heiko@sntech.de>

Am Donnerstag, 11. Juli 2013, 10:16:41 schrieb Tomasz Figa:
> Hi Heiko,
> 
> On Wednesday 10 of July 2013 00:59:08 Heiko St?bner wrote:
> > This adds support for pll2126x, pll3000x, pll6552x and pll6553x.
> > 
> > Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> > ---
> > 
> >  drivers/clk/samsung/clk-pll.c |  280
> > 
> > +++++++++++++++++++++++++++++++++++++++++ drivers/clk/samsung/clk-pll.h |
> > 
> >  8 ++
> >  2 files changed, 288 insertions(+)
> 
> Generally the patch looks good, but I have some comments to the part
> related to 655xx PLLs.
> 
> I had a patch adding support for them too, but we can go with yours, since
> the way of registration has been changed by Yadwinder's patches and mine
> would have to be updated anyway.
> 
> > diff --git a/drivers/clk/samsung/clk-pll.c
> > b/drivers/clk/samsung/clk-pll.c index 0afaec6..35c15a1 100644
> > --- a/drivers/clk/samsung/clk-pll.c
> > +++ b/drivers/clk/samsung/clk-pll.c
> > @@ -323,6 +323,73 @@ struct clk * __init
> > samsung_clk_register_pll46xx(const char *name, }
> > 
> >  /*
> > 
> > + * PLL2126x Clock Type
> > + */
> > +
> > +#define PLL2126X_MDIV_MASK	(0xFF)
> > +#define PLL2126X_PDIV_MASK	(0x3)
> > +#define PLL2126X_SDIV_MASK	(0x3)
> > +#define PLL2126X_MDIV_SHIFT	(16)
> > +#define PLL2126X_PDIV_SHIFT	(8)
> > +#define PLL2126X_SDIV_SHIFT	(0)


+#define PLL2126X_PDIV_MASK	(0x3F)

is the correct value.


> > +
> > +struct samsung_clk_pll2126x {
> > +	struct clk_hw		hw;
> > +	const void __iomem	*con_reg;
> > +};
> > +
> > +#define to_clk_pll2126x(_hw) container_of(_hw, struct
> > samsung_clk_pll2126x, hw) +
> > +static unsigned long samsung_pll2126x_recalc_rate(struct clk_hw *hw,
> > +				unsigned long parent_rate)
> > +{
> > +	struct samsung_clk_pll2126x *pll = to_clk_pll2126x(hw);
> > +	u32 pll_con, mdiv, pdiv, sdiv;
> > +	u64 fvco = parent_rate;
> > +
> > +	pll_con = __raw_readl(pll->con_reg);
> > +	mdiv = (pll_con >> PLL2126X_MDIV_SHIFT) & PLL2126X_MDIV_MASK;
> > +	pdiv = (pll_con >> PLL2126X_PDIV_SHIFT) & PLL2126X_PDIV_MASK;
> > +	sdiv = (pll_con >> PLL2126X_SDIV_SHIFT) & PLL2126X_SDIV_MASK;
> > +
> > +	fvco *= (mdiv + 8);
> > +	do_div(fvco, (pdiv + 2) << sdiv);
> > +
> > +	return (unsigned long)fvco;
> > +}
> > +
> > +static const struct clk_ops samsung_pll2126x_clk_ops = {
> > +	.recalc_rate = samsung_pll2126x_recalc_rate,
> > +};
> > +
> > +struct clk * __init samsung_clk_register_pll2126x(const char *name,
> > +			const char *pname, const void __iomem *con_reg)
> > +{
> > +	struct samsung_clk_pll2126x *pll;
> > +	struct clk *clk;
> > +	struct clk_init_data init;
> > +
> > +	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> > +	if (!pll)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	init.name = name;
> > +	init.ops = &samsung_pll2126x_clk_ops;
> > +	init.flags = CLK_GET_RATE_NOCACHE;
> > +	init.parent_names = &pname;
> > +	init.num_parents = 1;
> > +
> > +	pll->hw.init = &init;
> > +	pll->con_reg = con_reg;
> > +
> > +	clk = samsung_register_pll(&pll->hw);
> > +	if (IS_ERR(clk))
> > +		kfree(pll);
> > +
> > +	return clk;
> > +}
> > +
> > +/*
> > 
> >   * PLL2550x Clock Type
> >   */
> > 
> > @@ -396,3 +463,216 @@ struct clk * __init
> > samsung_clk_register_pll2550x(const char *name,
> > 
> >  	return clk;
> >  
> >  }
> > 
> > +
> > +/*
> > + * PLL3000x Clock Type
> > + */
> > +
> > +#define PLL3000X_MDIV_MASK	(0xFF)
> > +#define PLL3000X_PDIV_MASK	(0x3)
> > +#define PLL3000X_SDIV_MASK	(0x3)
> > +#define PLL3000X_MDIV_SHIFT	(16)
> > +#define PLL3000X_PDIV_SHIFT	(8)
> > +#define PLL3000X_SDIV_SHIFT	(0)

these are correct.

> > +
> > +struct samsung_clk_pll3000x {
> > +	struct clk_hw		hw;
> > +	const void __iomem	*con_reg;
> > +};
> > +
> > +#define to_clk_pll3000x(_hw) container_of(_hw, struct
> > samsung_clk_pll3000x, hw) +
> > +static unsigned long samsung_pll3000x_recalc_rate(struct clk_hw *hw,
> > +				unsigned long parent_rate)
> > +{
> > +	struct samsung_clk_pll3000x *pll = to_clk_pll3000x(hw);
> > +	u32 pll_con, mdiv, pdiv, sdiv;
> > +	u64 fvco = parent_rate;
> > +
> > +	pll_con = __raw_readl(pll->con_reg);
> > +	mdiv = (pll_con >> PLL3000X_MDIV_SHIFT) & PLL3000X_MDIV_MASK;
> > +	pdiv = (pll_con >> PLL3000X_PDIV_SHIFT) & PLL3000X_PDIV_MASK;
> > +	sdiv = (pll_con >> PLL3000X_SDIV_SHIFT) & PLL3000X_SDIV_MASK;
> > +
> > +	fvco *= (2 * (mdiv + 8));
> > +	do_div(fvco, pdiv << sdiv);
> > +
> > +	return (unsigned long)fvco;
> > +}
> > +
> > +static const struct clk_ops samsung_pll3000x_clk_ops = {
> > +	.recalc_rate = samsung_pll3000x_recalc_rate,
> > +};
> > +
> > +struct clk * __init samsung_clk_register_pll3000x(const char *name,
> > +			const char *pname, const void __iomem *con_reg)
> > +{
> > +	struct samsung_clk_pll3000x *pll;
> > +	struct clk *clk;
> > +	struct clk_init_data init;
> > +
> > +	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> > +	if (!pll)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	init.name = name;
> > +	init.ops = &samsung_pll3000x_clk_ops;
> > +	init.flags = CLK_GET_RATE_NOCACHE;
> > +	init.parent_names = &pname;
> > +	init.num_parents = 1;
> > +
> > +	pll->hw.init = &init;
> > +	pll->con_reg = con_reg;
> > +
> > +	clk = samsung_register_pll(&pll->hw);
> > +	if (IS_ERR(clk))
> > +		kfree(pll);
> > +
> > +	return clk;
> > +}
> > +
> > +/*
> > + * PLL6552x Clock Type
> > + */
> > +
> > +#define PLL6552X_MDIV_MASK	(0x3FF)
> > +#define PLL6552X_PDIV_MASK	(0x3F)
> > +#define PLL6552X_SDIV_MASK	(0x7)
> > +#define PLL6552X_MDIV_SHIFT	(14)
> > +#define PLL6552X_PDIV_SHIFT	(5)
> > +#define PLL6552X_SDIV_SHIFT	(0)
> 
> Are you sure about those bitfields?
> 
> In S3C6410 User's Manual they are different. You can look at my patch for a
> comparison:
> 
> http://thread.gmane.org/gmane.linux.usb.general/87571/focus=88344

The numbers where taken from the previous pll code, but I now again checked 
them against the datasheet of the s3c2416 and the s3c2450.

When comparing with your patch, it really seems that the bit offsets in the 
register are different for the pdiv and mdiv - the above values are correct 
according the the datasheet (and also produce the expected results in the 
clock tree).



> > +struct samsung_clk_pll6552x {
> > +	struct clk_hw		hw;
> > +	const void __iomem	*con_reg;
> > +};
> > +
> > +#define to_clk_pll6552x(_hw) container_of(_hw, struct
> > samsung_clk_pll6552x, hw) +
> > +static unsigned long samsung_pll6552x_recalc_rate(struct clk_hw *hw,
> > +				unsigned long parent_rate)
> > +{
> > +	struct samsung_clk_pll6552x *pll = to_clk_pll6552x(hw);
> > +	u32 pll_con, mdiv, pdiv, sdiv;
> > +	u64 fvco = parent_rate;
> > +
> > +	pll_con = __raw_readl(pll->con_reg);
> > +	mdiv = (pll_con >> PLL6552X_MDIV_SHIFT) & PLL6552X_MDIV_MASK;
> > +	pdiv = (pll_con >> PLL6552X_PDIV_SHIFT) & PLL6552X_PDIV_MASK;
> > +	sdiv = (pll_con >> PLL6552X_SDIV_SHIFT) & PLL6552X_SDIV_MASK;
> > +
> > +	fvco *= mdiv;
> > +	do_div(fvco, (pdiv << sdiv));
> > +
> > +	return (unsigned long)fvco;
> > +}
> > +
> > +static const struct clk_ops samsung_pll6552x_clk_ops = {
> > +	.recalc_rate = samsung_pll6552x_recalc_rate,
> > +};
> > +
> > +struct clk * __init samsung_clk_register_pll6552x(const char *name,
> > +			const char *pname, const void __iomem *con_reg)
> > +{
> > +	struct samsung_clk_pll6552x *pll;
> > +	struct clk *clk;
> > +	struct clk_init_data init;
> > +
> > +	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> > +	if (!pll)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	init.name = name;
> > +	init.ops = &samsung_pll6552x_clk_ops;
> > +	init.flags = CLK_GET_RATE_NOCACHE;
> > +	init.parent_names = &pname;
> > +	init.num_parents = 1;
> > +
> > +	pll->hw.init = &init;
> > +	pll->con_reg = con_reg;
> > +
> > +	clk = samsung_register_pll(&pll->hw);
> > +	if (IS_ERR(clk))
> > +		kfree(pll);
> > +
> > +	return clk;
> > +}
> > +
> > +/*
> > + * PLL6553x Clock Type
> > + */
> > +
> > +#define PLL6553X_MDIV_MASK	(0x7F)
> > +#define PLL6553X_PDIV_MASK	(0x1F)
> > +#define PLL6553X_SDIV_MASK	(0x3)
> > +#define PLL6553X_KDIV_MASK	(0xFFFF)
> > +#define PLL6553X_MDIV_SHIFT	(16)
> > +#define PLL6553X_PDIV_SHIFT	(8)
> > +#define PLL6553X_SDIV_SHIFT	(0)
> 
> Same about those bitfields. They seem to be different on S3C64xx.

Here it seems the values were off in the original code. According to the 
datasheet the values in your patch are correct. Thanks for the catch.

+#define PLL6553X_MDIV_MASK	(0xFF)
+#define PLL6553X_PDIV_MASK	(0x3F)
+#define PLL6553X_SDIV_MASK	(0x7)


This leaves the problem on what to do with the 6552X and its different bit 
offsets. Is the pll in question really a 6552X? In the s3c2416 manual its name 
is explicitly stated.


Thanks
Heiko


From rogerq at ti.com  Thu Jul 11 04:50:59 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 11 Jul 2013 11:50:59 +0300
Subject: [PATCH 6/6] USB: ehci-omap: Implement suspend/resume
In-Reply-To: <Pine.LNX.4.44L0.1307101446270.1215-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307101446270.1215-100000@iolanthe.rowland.org>
Message-ID: <51DE71F3.1040101@ti.com>

On 07/10/2013 10:04 PM, Alan Stern wrote:
> On Wed, 10 Jul 2013, Roger Quadros wrote:
> 
>> Call ehci_suspend/resume() during runtime suspend/resume
>> as well as system suspend/resume.
>>
>> Use a flag "bound" to indicate that the HCD structures are valid.
>> This is only true between usb_add_hcd() and usb_remove_hcd() calls.
>>
>> The flag can be used by omap_ehci_runtime_suspend/resume() handlers
>> to avoid calling ehci_suspend/resume() when we are no longer bound
>> to the HCD e.g. during probe() and remove();
> 
>> @@ -293,15 +301,67 @@ static const struct of_device_id omap_ehci_dt_ids[] = {
>>  
>>  MODULE_DEVICE_TABLE(of, omap_ehci_dt_ids);
>>  
>> +static int omap_ehci_suspend(struct device *dev)
>> +{
>> +	struct usb_hcd *hcd = dev_get_drvdata(dev);
>> +
>> +	dev_dbg(dev, "%s\n", __func__);
>> +
>> +	return ehci_suspend(hcd, true);
>> +}
>> +
>> +static int omap_ehci_resume(struct device *dev)
>> +{
>> +	struct usb_hcd *hcd = dev_get_drvdata(dev);
>> +
>> +	dev_dbg(dev, "%s\n", __func__);
>> +
>> +	return ehci_resume(hcd, false);
>> +}
> 
> There are three problems here.  The first is very simple: the wakeup 
> settings are messed up.  Wakeup is supposed to be enabled always for
> runtime suspend, whereas it is controlled by device_may_wakeup() for
> system suspend.  You reversed them.

Indeed. I'll fix that up.

However, even if wakeup is disabled during system suspend, the OMAP will
still wakeup on any activity on the USB pins.

The only way to disable that is to disable IO pad wakeup. This can
only be done in mfd/omap-usb-host.c

I suppose I can use device_may_wakeup() there and configure the IO pad
wakeup accordingly.

> 
> The other two problems are both related to the interaction between
> system PM and runtime PM.  Suppose the controller is already runtime
> suspended when the system goes to sleep.  Because it is runtime
> suspended, it is enabled for wakeup.  But device_may_wakeup() could
> return false; if this happens then you have to do a runtime-resume in
> omap_ehci_suspend() before calling ehci_suspend(), so that the
> controller can be suspended again with wakeups disabled.  (Or you could
> choose an alternative method for accomplishing the same result, such as
> disabling the wakeup signal from the pad without going through a whole
> EHCI resume/suspend cycle.)  Conversely, if device_may_wakeup() returns
> true then you shouldn't do anything at all, because the controller is
> already suspended with the correct wakeup setting.

I think this case is taken care of by the Runtime PM core at least for the OMAP
platform according to the documentation

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/power/runtime_pm.txt#n647

At the end of this mail is the log during system suspend/resume

You can notice the following sequence

-ehci runtime suspends
-system suspend triggered
-ehci runtime resumes
-ehci suspends (uses new wakeup settings)
-system wakeup triggered
-ehci resumes
-ehci runtime suspends

> 
> For the third problem, suppose the controller was runtime suspended
> when the system went to sleep.  When the system wakes up, the
> controller will become active, so you have to inform the runtime PM
> core about its change of state.  Basically, if omap_ehci_resume() sees
> that ehci_resume() returned 0 then it must do:
> 
> 	pm_runtime_disable(dev);
> 	pm_runtime_set_active(dev);
> 	pm_runtime_enable(dev);
> 
> All of these issues are discussed (among lots of other material) in 
> Documentation/power/runtime_pm.txt.

Is this still applicable? Documentation claims

   "During system resume it calls pm_runtime_enable() and pm_runtime_put_sync()
    for every device right after executing the subsystem-level .resume_early()
    callback and right after executing the subsystem-level .resume() callback
    for it, respectively."

cheers,
-roger

---
[   13.256286] smsc95xx 1-2.1:1.0 eth0: entering SUSPEND2 mode
[   13.264648] usb 1-2.1: usb auto-suspend, wakeup 0
[   13.281677] hub 1-2:1.0: hub_suspend
[   13.285858] usb 1-2: unlink qh256-0001/dd443880 start 1 [1/0 us]
/
/ # [   13.296386] usb 1-2: usb auto-suspend, wakeup 1
[   13.321411] hub 1-0:1.0: hub_suspend
[   13.325225] usb usb1: bus auto-suspend, wakeup 1
[   13.330139] ehci-omap 48064800.ehci: suspend root hub
[   13.336395] ehci-omap 48064800.ehci: omap_ehci_runtime_suspend

/ # 
/ # echo mem > /sys/power/state 
[   26.821838] PM: Syncing filesystems ... done.
[   26.828491] PM: Preparing system for mem sleep
[   26.841796] Freezing user space processes ... (elapsed 0.000 seconds) done.
[   26.849426] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
[   26.860046] PM: Entering mem sleep
[   26.863769] Suspending console(s) (use no_console_suspend to debug)
[   26.878234] ehci-omap 48064800.ehci: omap_ehci_runtime_resume
[   26.878295] usb usb1: usb auto-resume
[   26.878326] ehci-omap 48064800.ehci: resume root hub
[   26.878417] hub 1-0:1.0: hub_resume
[   26.878570] hub 1-0:1.0: port 2: status 0507 change 0000
[   26.879089] hub 1-0:1.0: hub_suspend
[   26.879211] usb usb1: bus suspend, wakeup 0
[   26.879241] ehci-omap 48064800.ehci: suspend root hub
[   26.891845] ehci-omap 48064800.ehci: omap_ehci_suspend may_wakeup 0
[   26.923797] PM: suspend of devices complete after 47.912 msecs
[   26.929443] PM: late suspend of devices complete after 5.645 msecs
[   26.935882] PM: noirq suspend of devices complete after 6.378 msecs
[   26.935943] Disabling non-boot CPUs ...
[   26.936065] Successfully put all powerdomains to target state
[   26.939636] PM: noirq resume of devices complete after 3.448 msecs
[   26.945190] PM: early resume of devices complete after 4.180 msecs
[   26.954833] ehci-omap 48064800.ehci: omap_ehci_resume
[   26.955383] usb usb1: usb resume
[   26.955383] ehci-omap 48064800.ehci: resume root hub
[   26.955413] hub 1-0:1.0: hub_resume
[   26.955535] hub 1-0:1.0: port 2: status 0507 change 0000
[   26.955902] usb 1-2: usb resume
[   26.990661] ehci-omap 48064800.ehci: GetStatus port:2 status 001005 0  ACK POWER sig=se0 PE CONNECT
[   27.010528] usb 1-2: finish resume
[   27.010894] hub 1-2:1.0: hub_resume
[   27.011352] hub 1-2:1.0: port 1: status 0507 change 0000
[   27.012390] ehci-omap 48064800.ehci: reused qh dd443880 schedule
[   27.012390] usb 1-2: link qh256-0001/dd443880 start 1 [1/0 us]
[   27.013244] usb 1-2.1: usb resume
[   27.070800] usb 1-2.1: finish resume
[   27.072998] PM: resume of devices complete after 127.716 msecs
[   27.243438] PM: Finishing wakeup.
[   27.246948] Restarting tasks ... [   27.251312] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
[   27.257171] hub 1-2:1.0: state 7 ports 5 chg 0000 evt 0000
done.
/ # [   29.074493] smsc95xx 1-2.1:1.0 eth0: entering SUSPEND2 mode
[   29.082458] usb 1-2.1: usb auto-suspend, wakeup 0
[   29.100891] hub 1-2:1.0: hub_suspend
[   29.104736] usb 1-2: unlink qh256-0001/dd443880 start 1 [1/0 us]
[   29.114288] usb 1-2: usb auto-suspend, wakeup 1
[   29.130859] hub 1-0:1.0: hub_suspend
[   29.134735] usb usb1: bus auto-suspend, wakeup 1
[   29.139648] ehci-omap 48064800.ehci: suspend root hub
[   29.145446] ehci-omap 48064800.ehci: omap_ehci_runtime_suspend



From heiko at sntech.de  Thu Jul 11 04:52:13 2013
From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=)
Date: Thu, 11 Jul 2013 10:52:13 +0200
Subject: [PATCH v2 1/6] clk: samsung: move common plls registration into
 separate function
In-Reply-To: <1874409.iWz7oWBuYA@thinkpad>
References: <201307100057.06061.heiko@sntech.de>
 <CAKew6eUPBUZj4TuhNAjp6NitFUaeFBZscr_jqU3Y_wLi1m7Ekg@mail.gmail.com>
 <1874409.iWz7oWBuYA@thinkpad>
Message-ID: <201307111052.13618.heiko@sntech.de>

Am Donnerstag, 11. Juli 2013, 09:46:53 schrieb Tomasz Figa:
> Hi,
> 
> On Wednesday 10 of July 2013 22:29:13 Yadwinder Singh Brar wrote:
> > Hi Heiko,
> > 
> > On Wed, Jul 10, 2013 at 4:27 AM, Heiko St?bner <heiko at sntech.de> wrote:
> > > All Samsung PLLs use similar code to register the clocks and clkdev
> > > lookups. Therefore move these into a separate function to reduce code
> > > duplication.
> > > 
> > > Suggested-by: Russell King <linux at arm.linux.org.uk>
> > > Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> > > ---
> > 
> > I have posted patch for adding common pll registration function
> > which some how missed to get merged. I hope will get merged after rc1.
> > Please give a look at that :
> > http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg19543.ht
> > ml
> 
> Yeah, I was going to post a link to it, but I couldn't find it on any
> mailing list archive. I think we should go with the way of registration
> introduced by Yadwinder.

the linked patch looks nice, thanks for the link. So I'll redo the plls 
against it in the next round.


Heiko


From linus.walleij at linaro.org  Thu Jul 11 05:05:33 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Jul 2013 11:05:33 +0200
Subject: [GIT PULL] ux500 defconfig updates
Message-ID: <CACRpkdaczQWVv2S48bxRT+0NoMvmjgj5_Tf7cxOC-8xj+TnuTw@mail.gmail.com>

Hi ARM SoC folks,

these are some defconfig patches that can be pulled in now that all the new
stuff from various trees has percolated up to Torvalds.

Please pull them in!

Yours,
Linus Walleij


The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b:

  Linux 3.10-rc3 (2013-05-26 16:00:47 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
tags/ux500-defconfig-for-arm-soc

for you to fetch changes up to cbe8933143a62e0ced2d48183cdbdbdc38659338:

  ARM: ux500: Enable HIGHMEM in the u8500 defconfig (2013-06-04 11:18:54 +0200)

----------------------------------------------------------------
Ux500 defconfig changes:
- Update base due to different Kconfig changes
- Select watchdog, MUSB, Ux500 ALSA SoC, various MMC/SD
  features and enable highmem

----------------------------------------------------------------
Fabio Baltieri (2):
      ARM: ux500: select WATCHDOG and MUSB for ux500
      ARM: ux500: select SND_SOC_UX500 for ux500

Lee Jones (1):
      ARM: ux500: Enable HIGHMEM in the u8500 defconfig

Linus Walleij (1):
      ARM: ux500: update defconfig base

Ulf Hansson (1):
      ARM: ux500: Update MMC configs for u8500 defconfig

 arch/arm/configs/u8500_defconfig | 44 +++++++++++++++++++++++-----------------
 1 file changed, 25 insertions(+), 19 deletions(-)


From r65037 at freescale.com  Thu Jul 11 05:07:36 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Thu, 11 Jul 2013 09:07:36 +0000
Subject: [v4 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <20130711075543.GG14452@pengutronix.de>
References: <1373445355-11453-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373445355-11453-4-git-send-email-Hong-Xing.Zhu@freescale.com>
 <20130710210414.GK516@pengutronix.de>
 <0E83723C55F66F43A6041464FE31119D32AE6B@039-SN2MPN1-013.039d.mgd.msft.net>
 <20130711075543.GG14452@pengutronix.de>
Message-ID: <0E83723C55F66F43A6041464FE31119D32AF10@039-SN2MPN1-013.039d.mgd.msft.net>

Hi Sascha:
Thanks for your comments.
Yes, it is.
That's is what I done in the V5 patch-set. The patch-set is almost done, would send out a moment later.

Best Regards
Richard Zhu


-----Original Message-----
From: Sascha Hauer [mailto:s.hauer at pengutronix.de] 
Sent: Thursday, July 11, 2013 3:56 PM
To: Zhu Richard-R65037
Cc: Richard Zhu; shawn.guo at linaro.org; linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; tj at kernel.org; rob.herring at calxeda.com; linux-ide at vger.kernel.org
Subject: Re: [v4 3/3] sata: imx: add ahci sata support on imx platforms

Hi Richard,

On Thu, Jul 11, 2013 at 07:50:50AM +0000, Zhu Richard-R65037 wrote:
> Hi Sascha:
> Sorry to make a mess on the usage of the private data.
> The private data of "imx_ahci_pdev" platform device would be used to store ata_host point.
> I shouldn't set imxpriv to the private data of "imx_ahci_pdev", so do 
> the wrong assignment of The private pointer of device.

Please allocate your private data along with the platform_device in the probe function, then in the init callback you can use container_of() to get a pointer to the data.
Also I would recommend you to request the necessary resources (clocks,
regmap) in the probe function and not in the init callback.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |




From richard.zhuhongxing at gmail.com  Thu Jul 11 05:10:28 2013
From: richard.zhuhongxing at gmail.com (Richard Zhu)
Date: Thu, 11 Jul 2013 17:10:28 +0800
Subject: [PATCH v5 0/3] ahci: enable ahci sata support on imx6q
Message-ID: <1373533831-9500-1-git-send-email-Hong-Xing.Zhu@freescale.com>

V5: add imx6q specific ahci sata support
  - Fix the wrong referrence usage of the private data.
  - Use the private data to contain the poninter of the PHY
  signals adjustment window(gpr)
  - Tested on imx6q sd board.
  - 

v4: http://www.spinics.net/lists/linux-ide/msg45699.html
  Thanks for the review comments provided by Sascha, and Alexander.
  - Use the private data and keep a pointer to the PHY clock.
  - Don't use the global platform device variable, because that
  it would make the driver broken for mutiple instances.
  - Don't do the "writel" with assignment.
  - Other minor changes, such as print the error code when printing
  error message, use a u32 type to store readl results, and so on.

v3: http://www.spinics.net/lists/linux-ide/msg45688.html
  - Keep arch/arm and ahci_platform driver clean.
  - Add the sata_imx standalone driver contained all the
  specific setup
  - Add the release function, support the loadable module
  driver.
  - Tested on imx6q sd board.

v2: http://www.spinics.net/lists/linux-ide/msg45666.html 
 - Setup standalone imx ahci sata driver, because of
 the misalignments of the bits definition of the HBA register.
 - Replace the node by the label in the board dts.
 - 

v1: http://www.spinics.net/lists/linux-ide/msg45581.html
 - add imx6q specific ahci sata support to arch/arm/mach-imx/mach-imx6q.c

These patches is based on imx/dt branch of
"http://git.linaro.org/git-ro/people/shawnguo/linux-2.6.git"

[v5 1/3] ARM: dtsi: enable ahci sata on imx6q platforms
[v5 2/3] ARM: imx6q: update the sata bits definitions of gpr13
[v5 3/3] sata: imx: add ahci sata support on imx platforms

arch/arm/boot/dts/imx6q-sabreauto.dts       |    4 +
arch/arm/boot/dts/imx6q-sabrelite.dts       |    4 +
arch/arm/boot/dts/imx6q-sabresd.dts         |    4 +
arch/arm/boot/dts/imx6q.dtsi                |    9 +
drivers/ata/Kconfig                         |    9 +
drivers/ata/Makefile                        |    1 +
drivers/ata/sata_imx.c                      |  233 +++++++++++++++++++++++++++
include/linux/mfd/syscon/imx6q-iomuxc-gpr.h |  121 ++++++++++-----
8 files changed, 348 insertions(+), 37 deletions(-)


From rnayak at ti.com  Thu Jul 11 05:11:11 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Thu, 11 Jul 2013 14:41:11 +0530
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130711062440.GY5523@atomide.com>
References: <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <87mwpuakod.fsf@linaro.org>
 <20130710142633.GV5523@atomide.com> <51DE4E3F.6030503@ti.com>
 <20130711062440.GY5523@atomide.com>
Message-ID: <51DE76AF.8030402@ti.com>

On Thursday 11 July 2013 11:54 AM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak at ti.com> [130710 23:25]:
>> On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
>>>
>>> Felipe is right, looks like all we need is to check if context is
>>> initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
>>>
>>> After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
>>> works for me.
>>
>> On what platform? Like I said there are flags set statically in hmwod
>> data for OMAP4 and OMAP5, which make it work without any hwmod tinkering
>> in mach-omap2/serial.c. But it won't work for am33xx.
> 
> For me omap4 sdp hangs during ttyO2 probe if earlyprintk is enabled for
> that port and console is enabled for that port. That's because we attempt
> to restore uninitialized context.

Right, so thats the Issue 2: that you see on the omap4 sdp. You never hit
Issue 1: despite not doing any hwmod tinkering because of the static flags
set for uart3 in hwmod data.

> 
> It's possible that we have more than one bug here though.

Right, we have 2 issues like I said earlier. Issue 1: is when hwmod _setup()
does a console UART reset (Not seen if the flags are set either runtime or
statically)

Issue 2: Is when omap serial does a runtime resume before set_termios().

>  
>>> @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
>>>  
>>>  	pm_runtime_mark_last_busy(up->dev);
>>>  	pm_runtime_put_autosuspend(up->dev);
>>> +	up->initialized = true;
>>
>> This won't help as the context save for serial happens as part of set_termios() and not
>> when the device is probed.
> 
> The issue is that in serial probe we currently restore NULL context to
> the port which kills earlyprintk output until set_termios() is called.
> 
> But as discussed, there are better ways for fixing this issue.
> 
> Regards,
> 
> Tony
> 



From tomasz.figa at gmail.com  Thu Jul 11 05:13:55 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 11 Jul 2013 11:13:55 +0200
Subject: [PATCH v2 5/6] clk: samsung: add clock-driver for s3c2416,
 s3c2443 and s3c2450
In-Reply-To: <201307100100.00872.heiko@sntech.de>
References: <201307100057.06061.heiko@sntech.de>
 <201307100100.00872.heiko@sntech.de>
Message-ID: <2621812.eUdv97DGos@thinkpad>

Hi Heiko,

Looks mostly good, but please see my comments inline.

On Wednesday 10 of July 2013 01:00:00 Heiko St?bner wrote:
> The three SoCs share a common clock tree which only differs in the
> existence of some special clocks.
> 
> As with all parts common to these three SoCs the driver is named
> after the s3c2443, as it was the first SoC introducing this structure
> and there exists no other label to describe this s3c24xx epoch.
> 
> The clock structure is built according to the manuals of the included
> SoCs and might include changes in comparison to the previous clock
> structure. As an example the sclk_uart gate was never handled previously
> and the div_uart was made to be the clock used by the serial driver.
> 
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> ---
>  .../bindings/clock/samsung,s3c2443-clock.txt       |   48 +++
>  drivers/clk/Kconfig                                |    1 +
>  drivers/clk/samsung/Kconfig                        |    2 +
>  drivers/clk/samsung/Makefile                       |    1 +
>  drivers/clk/samsung/clk-s3c2443.c                  |  422
> ++++++++++++++++++++ include/dt-bindings/clock/samsung,s3c2443-clock.h  |  
> 96 +++++
>  6 files changed, 570 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt create
> mode 100644 drivers/clk/samsung/Kconfig
>  create mode 100644 drivers/clk/samsung/clk-s3c2443.c
>  create mode 100644 include/dt-bindings/clock/samsung,s3c2443-clock.h
> 
> diff --git
> a/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt
> b/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt new
> file mode 100644
> index 0000000..a61d8d1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt
> @@ -0,0 +1,48 @@
> +* Samsung S3C2443 Clock Controller
> +
> +The S3C2443 clock controller generates and supplies clock to various
> controllers +within the SoC. The clock binding described here is applicable
> to all SoCs in +the s3c24x family starting with the s3c2443.
> +
> +Required Properties:
> +
> +- comptible: should be one of the following.

nit: compatible

> +  - "samsung,s3c2416-clock" - controller compatible with S3C2416 SoC.
> +  - "samsung,s3c2443-clock" - controller compatible with S3C2443 SoC.
> +  - "samsung,s3c2450-clock" - controller compatible with S3C2450 SoC.
> +
> +- reg: physical base address of the controller and length of memory mapped
> +  region.
> +
> +- #clock-cells: should be 1.
> +
> +Each clock is assigned an identifier and client nodes can use this
> identifier +to specify the clock which they consume. Some of the clocks are
> available only +on a particular SoC.
> +
> +All available clocks are defined as preprocessor macros in
> +dt-bindings/clock/samsung,s3c2443-clock.h header and can be used in device
> +tree sources.
> +
> +Example: Clock controller node:
> +
> +	clocks: clock-controller at 4c000000 {
> +		compatible = "samsung,s3c2416-clock";
> +		reg = <0x4c000000 0x40>;
> +		#clock-cells = <1>;
> +	};
> +
> +Example: UART controller node that consumes the clock generated by the
> clock +  controller (refer to the standard clock bindings for information
> about +  "clocks" and "clock-names" properties):
> +
> +	serial at 50004000 {
> +		compatible = "samsung,s3c2440-uart";
> +		reg = <0x50004000 0x4000>;
> +		interrupts = <1 23 3 4>, <1 23 4 4>;
> +		clock-names = "uart", "clk_uart_baud2",
> +				"clk_uart_baud3";
> +		clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>,
> +				<&clocks SCLK_UART>;
> +		status = "disabled";
> +	};
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 0357ac4..b2fdd68 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -84,3 +84,4 @@ config COMMON_CLK_AXI_CLKGEN
>  endmenu
> 
>  source "drivers/clk/mvebu/Kconfig"
> +source "drivers/clk/samsung/Kconfig"
> diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
> new file mode 100644
> index 0000000..0cfbb29
> --- /dev/null
> +++ b/drivers/clk/samsung/Kconfig
> @@ -0,0 +1,2 @@
> +config COMMON_CLK_S3C2443
> +       bool

Do you need to introduce a new Kconfig file for this? I guess it's just a matter 
of preference, but since it's here just temporarily, I would just put this 
Kconfig entry into the top level clk Kconfig file or even in arch/arm/mach-
s3c24xx/Kconfig.

> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> index 5d4d432..1c7932c 100644
> --- a/drivers/clk/samsung/Makefile
> +++ b/drivers/clk/samsung/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_SOC_EXYNOS5250)	+= clk-exynos5250.o
>  obj-$(CONFIG_SOC_EXYNOS5420)	+= clk-exynos5420.o
>  obj-$(CONFIG_SOC_EXYNOS5440)	+= clk-exynos5440.o
>  obj-$(CONFIG_ARCH_EXYNOS)	+= clk-exynos-audss.o
> +obj-$(CONFIG_COMMON_CLK_S3C2443)+= clk-s3c2443.o
> diff --git a/drivers/clk/samsung/clk-s3c2443.c
> b/drivers/clk/samsung/clk-s3c2443.c new file mode 100644
> index 0000000..7d57b08
> --- /dev/null
> +++ b/drivers/clk/samsung/clk-s3c2443.c
> @@ -0,0 +1,422 @@
> +/*
> + * Copyright (c) 2013 Heiko Stuebner <heiko at sntech.de>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Common Clock Framework support for S3C2443 and following SoCs.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +
> +#include <dt-bindings/clock/samsung,s3c2443-clock.h>
> +
> +#include "clk.h"
> +#include "clk-pll.h"
> +
> +/* S3C2416 clock controller register offsets */
> +#define MPLLCON		0x10
> +#define EPLLCON		0x18
> +#define EPLLCON_K	0x1C
> +#define CLKSRC		0x20
> +#define CLKDIV0		0x24
> +#define CLKDIV1		0x28
> +#define CLKDIV2		0x2C
> +#define HCLKCON		0x30
> +#define PCLKCON		0x34
> +#define SCLKCON		0x38
> +
> +/* the soc types */
> +enum supported_socs {
> +	S3C2416,
> +	S3C2443,
> +	S3C2450,
> +};
> +
> +/*
> + * list of controller registers to be saved and restored during a
> + * suspend/resume cycle.
> + */
> +static __initdata unsigned long s3c2443_clk_regs[] = {
> +	MPLLCON,
> +	EPLLCON,
> +	EPLLCON_K,
> +	CLKSRC,
> +	CLKDIV0,
> +	CLKDIV1,
> +	CLKDIV2,
> +	PCLKCON,
> +	HCLKCON,
> +	SCLKCON,
> +};
> +
> +PNAME(epllref_p) = { "mpllref", "mpllref", "xti", "ext" };
> +PNAME(esysclk_p) = { "epllref", "epll" };
> +PNAME(msysclk_p) = { "mpllref, mdivclk", "mpll", "mpll" };
> +PNAME(armclk_p) = { "armdiv" , "hclk" };
> +PNAME(i2s0_p) = { "div_i2s0", "ext_i2s", "epllref", "epllref" };
> +
> +/* fixed rate clocks generated outside the soc */
> +struct samsung_fixed_rate_clock s3c2443_common_frate_clks[] __initdata = {
> +	FRATE(XTI, "xti", NULL, CLK_IS_ROOT, 0),
> +	FRATE(EXT, "ext", NULL, CLK_IS_ROOT, 0),
> +	FRATE(EXT_I2S, "ext_i2s", NULL, CLK_IS_ROOT, 0),
> +	FRATE(EXT_UART, "ext_uart", NULL, CLK_IS_ROOT, 0),
> +};
> +
> +/* mpllref is a direct descendant of clk_xtal by default, but it is not

nit: The preferred style of multiline comments is:

/*
 * mpllref is a...

> + * elided as the EPLL can be either sourced by the XTAL or EXTCLK and as
> + * such directly equating the two source clocks is impossible.
> + */
> +struct samsung_fixed_factor_clock s3c2443_common_ffactor[] __initdata = {
> +	FFACTOR(0, "mpllref", "xti", 1, 1, 0),
> +};

Hmm, I don't understand the reason for having this fixed factor clock. Why 
can't xti be used directly instead?

> +struct samsung_mux_clock s3c2443_common_muxes[] __initdata = {
> +	MUX(0, "epllref", epllref_p, CLKSRC, 7, 2),
> +	MUX(ESYSCLK, "esysclk", esysclk_p, CLKSRC, 6, 1),
> +	MUX_A(MSYSCLK, "msysclk", msysclk_p, CLKSRC, 3, 2, "msysclk"),
> +	MUX_A(ARMCLK, "armclk", armclk_p, CLKDIV0, 13, 1, "armclk"),
> +	MUX(0, "mux_i2s0", i2s0_p, CLKSRC, 14, 2),
> +};
> +
> +static struct clk_div_table hclk_d[] = {
> +	{ .val = 0, .div = 1 },
> +	{ .val = 1, .div = 2 },
> +	{ .val = 3, .div = 4 },
> +	{ .div = 0 },
> +};

Hmm, this makes me rethink some of the code I made for S3C64xx. There are few 
dividers that have additional constraints, like only even divisors, or so, but 
they are just normal linear dividers, so can be registered as simple divider 
clocks.

Originally I registered them as simple dividers, but now I'm thinking if they 
shouldn't be constrained by a table.

> +static struct clk_div_table mdivclk_d[] = {
> +	{ .val = 0, .div = 1 },
> +	{ .val = 1, .div = 3 },
> +	{ .val = 2, .div = 5 },
> +	{ .val = 3, .div = 7 },
> +	{ .val = 4, .div = 9 },
> +	{ .val = 5, .div = 11 },
> +	{ .val = 6, .div = 13 },
> +	{ .val = 7, .div = 15 },
> +	{ .div = 0 },
> +};
> +
> +struct samsung_div_clock s3c2443_common_dividers[] __initdata = {
> +	DIV_T(0, "mdivclk", "mpllref", CLKDIV0, 6, 3, mdivclk_d),
> +	DIV(0, "prediv", "msysclk", CLKDIV0, 4, 2),
> +	DIV_T(HCLK, "hclk", "prediv", CLKDIV0, 0, 2, hclk_d),
> +	DIV(PCLK, "pclk", "hclk", CLKDIV0, 2, 1),
> +	DIV(0, "div_hsspi0_epll", "esysclk", CLKDIV1, 24, 2),
> +	DIV(0, "div_fimd", "esysclk", CLKDIV1, 16, 8),
> +	DIV(0, "div_i2s0", "esysclk", CLKDIV1, 12, 4),
> +	DIV(0, "div_uart", "esysclk", CLKDIV1, 8, 4),
> +	DIV(0, "div_hsmmc1", "esysclk", CLKDIV1, 6, 2),
> +	DIV(0, "div_usbhost", "esysclk", CLKDIV1, 4, 2),
> +};
> +
> +struct samsung_gate_clock s3c2443_common_gates[] __initdata = {
> +	GATE(SCLK_HSMMC_EXT, "sclk_hsmmcext", "ext", SCLKCON, 13, 0, 0),
> +	GATE(SCLK_HSMMC1, "sclk_hsmmc1", "div_hsmmc1", SCLKCON, 12, 0, 0),
> +	GATE(SCLK_FIMD, "sclk_fimd", "div_fimd", SCLKCON, 10, 0, 0),
> +	GATE(SCLK_I2S0, "sclk_i2s0", "mux_i2s0", SCLKCON, 9, 0, 0),
> +	GATE(SCLK_UART, "sclk_uart", "div_uart", SCLKCON, 8, 0, 0),
> +	GATE(SCLK_USBH, "sclk_usbhost", "div_usbhost", SCLKCON, 1, 0, 0),
> +	GATE(HCLK_DRAM, "dram", "hclk", HCLKCON, 19, CLK_IGNORE_UNUSED, 0),
> +	GATE(HCLK_SSMC, "ssmc", "hclk", HCLKCON, 18, CLK_IGNORE_UNUSED, 0),
> +	GATE(HCLK_HSMMC1, "hsmmc1", "hclk", HCLKCON, 16, 0, 0),
> +	GATE(HCLK_USBD, "usb-device", "hclk", HCLKCON, 12, 0, 0),
> +	GATE(HCLK_USBH, "usb-host", "hclk", HCLKCON, 11, 0, 0),
> +	GATE(HCLK_LCD, "lcd", "hclk", HCLKCON, 9, 0, 0),
> +	GATE(HCLK_DMA5, "dma5", "hclk", HCLKCON, 5, CLK_IGNORE_UNUSED, 0),
> +	GATE(HCLK_DMA4, "dma4", "hclk", HCLKCON, 4, CLK_IGNORE_UNUSED, 0),
> +	GATE(HCLK_DMA3, "dma3", "hclk", HCLKCON, 3, CLK_IGNORE_UNUSED, 0),
> +	GATE(HCLK_DMA2, "dma2", "hclk", HCLKCON, 2, CLK_IGNORE_UNUSED, 0),
> +	GATE(HCLK_DMA1, "dma1", "hclk", HCLKCON, 1, CLK_IGNORE_UNUSED, 0),
> +	GATE(HCLK_DMA0, "dma0", "hclk", HCLKCON, 0, CLK_IGNORE_UNUSED, 0),

Hmm, I guess these CLK_IGNORE_UNUSED flags are needed because the old DMA 
driver doesn't handle clocks, right?

By the way, do you have some plans to continue working on the DMA engine 
driver for s3c24xx you posted some time ago? This would be really helpful, as 
we could then switch all the drivers using currently the Samsung-specific DMA 
API to the generic DMA engine API. (Actually I already have some patches for 
Samsung sound drivers. Will probably post an RFC soon.)

> +	GATE(PCLK_GPIO, "gpio", "pclk", PCLKCON, 13, CLK_IGNORE_UNUSED, 0),
> +	GATE(PCLK_RTC, "rtc", "pclk", PCLKCON, 12, 0, 0),
> +	GATE(PCLK_WDT, "wdt", "pclk", PCLKCON, 11, 0, 0),
> +	GATE(PCLK_PWM, "pwm", "pclk", PCLKCON, 10, 0, 0),
> +	GATE(PCLK_I2S0, "i2s0", "pclk", PCLKCON, 9, 0, 0),
> +	GATE(PCLK_AC97, "ac97", "pclk", PCLKCON, 8, 0, 0),
> +	GATE(PCLK_ADC, "adc", "pclk", PCLKCON, 7, 0, 0),
> +	GATE(PCLK_SPI0, "spi0", "pclk", PCLKCON, 6, 0, 0),
> +	GATE(PCLK_I2C0, "i2c0", "pclk", PCLKCON, 4, 0, 0),
> +	GATE(PCLK_UART3, "uart3", "pclk", PCLKCON, 3, 0, 0),
> +	GATE(PCLK_UART2, "uart2", "pclk", PCLKCON, 2, 0, 0),
> +	GATE(PCLK_UART1, "uart1", "pclk", PCLKCON, 1, 0, 0),
> +	GATE(PCLK_UART0, "uart0", "pclk", PCLKCON, 0, 0, 0),
> +};
> +
> +struct samsung_clock_alias s3c2443_common_aliases[] __initdata = {
> +	ALIAS(HCLK, NULL, "hclk"),
> +	ALIAS(HCLK_SSMC, NULL, "nand"),
> +	ALIAS(PCLK_UART0, "s3c2440-uart.0", "uart"),
> +	ALIAS(PCLK_UART1, "s3c2440-uart.1", "uart"),
> +	ALIAS(PCLK_UART2, "s3c2440-uart.2", "uart"),
> +	ALIAS(PCLK_UART3, "s3c2440-uart.3", "uart"),
> +	ALIAS(EXT_UART, NULL, "clk_uart_baud1"),
> +	ALIAS(PCLK_UART0, "s3c2440-uart.0", "clk_uart_baud2"),
> +	ALIAS(PCLK_UART1, "s3c2440-uart.1", "clk_uart_baud2"),
> +	ALIAS(PCLK_UART2, "s3c2440-uart.2", "clk_uart_baud2"),
> +	ALIAS(PCLK_UART3, "s3c2440-uart.3", "clk_uart_baud2"),
> +	ALIAS(SCLK_UART, NULL, "clk_uart_baud3"),
> +	ALIAS(PCLK_PWM, NULL, "timers"),
> +	ALIAS(PCLK_RTC, NULL, "rtc"),
> +	ALIAS(PCLK_WDT, NULL, "watchdog"),
> +	ALIAS(PCLK_ADC, NULL, "adc"),
> +	ALIAS(PCLK_I2C0, "s3c2410-i2c.0", "i2c"),
> +	ALIAS(HCLK_USBD, NULL, "usb-device"),
> +	ALIAS(HCLK_USBH, NULL, "usb-host"),
> +	ALIAS(SCLK_USBH, NULL, "usb-bus-host"),
> +	ALIAS(PCLK_SPI0, "s3c2443-spi.0", "spi"),
> +	ALIAS(PCLK_SPI0, "s3c2443-spi.0", "spi_busclk0"),
> +	ALIAS(HCLK_HSMMC1, "s3c-sdhci.1", "hsmmc"),
> +	ALIAS(HCLK_HSMMC1, "s3c-sdhci.1", "mmc_busclk.0"),
> +	ALIAS(PCLK_I2S0, "samsung-i2s.0", "iis"),
> +	ALIAS(SCLK_I2S0, NULL, "i2s-if"),
> +	ALIAS(HCLK_LCD, NULL, "lcd"),
> +	ALIAS(SCLK_FIMD, NULL, "sclk_fimd"),
> +};
> +
> +/* S3C2416 specific clocks */
> +
> +PNAME(s3c2416_hsmmc0_p) = { "sclk_hsmmc0", "sclk_hsmmcext" };
> +PNAME(s3c2416_hsmmc1_p) = { "sclk_hsmmc1", "sclk_hsmmcext" };
> +PNAME(s3c2416_hsspi0_p) = { "hsspi0_epll", "hsspi0_mpll" };
> +
> +static struct clk_div_table armdiv_s3c2416_d[] = {
> +	{ .val = 0, .div = 1 },
> +	{ .val = 1, .div = 2 },
> +	{ .val = 2, .div = 3 },
> +	{ .val = 3, .div = 4 },
> +	{ .val = 5, .div = 6 },
> +	{ .val = 7, .div = 8 },
> +	{ .div = 0 },
> +};
> +
> +struct samsung_div_clock s3c2416_dividers[] __initdata = {
> +	DIV_T(ARMDIV, "armdiv", "msysclk", CLKDIV0, 9, 3, armdiv_s3c2416_d),
> +	DIV(0, "div_hsspi0_mpll", "msysclk", CLKDIV2, 0, 4),
> +	DIV(0, "div_hsmmc0", "esysclk", CLKDIV2, 6, 2),
> +};
> +
> +struct samsung_mux_clock s3c2416_muxes[] __initdata = {
> +	MUX(MUX_HSMMC0, "mux_hsmmc0", s3c2416_hsmmc0_p, CLKSRC, 16, 1),
> +	MUX(MUX_HSMMC1, "mux_hsmmc1", s3c2416_hsmmc1_p, CLKSRC, 17, 1),
> +	MUX(MUX_HSSPI0, "mux_hsspi0", s3c2416_hsspi0_p, CLKSRC, 18, 1),
> +};
> +
> +struct samsung_gate_clock s3c2416_gates[] __initdata = {
> +	GATE(0, "hsspi0_mpll", "div_hsspi0_mpll", SCLKCON, 19, 0, 0),
> +	GATE(0, "hsspi0_epll", "div_hsspi0_epll", SCLKCON, 14, 0, 0),
> +	GATE(0, "sclk_hsmmc0", "div_hsmmc0", SCLKCON, 6, 0, 0),
> +	GATE(HCLK_2D, "2d", "hclk", HCLKCON, 20, 0, 0),
> +	GATE(HCLK_HSMMC0, "hsmmc0", "hclk", HCLKCON, 15, 0, 0),
> +	GATE(HCLK_IROM, "irom", "hclk", HCLKCON, 13, CLK_IGNORE_UNUSED, 0),
> +	GATE(PCLK_PCM, "pcm", "pclk", PCLKCON, 19, 0, 0),
> +};
> +
> +struct samsung_clock_alias s3c2416_aliases[] __initdata = {
> +	ALIAS(HCLK_HSMMC0, "s3c-sdhci.0", "hsmmc"),
> +	ALIAS(HCLK_HSMMC0, "s3c-sdhci.0", "mmc_busclk.0"),
> +	ALIAS(MUX_HSMMC0, "s3c-sdhci.0", "mmc_busclk.2"),
> +	ALIAS(MUX_HSMMC1, "s3c-sdhci.1", "mmc_busclk.2"),
> +	ALIAS(MUX_HSSPI0, "s3c2443-spi.0", "spi_busclk2"),
> +	ALIAS(ARMDIV, NULL, "armdiv"),
> +};
> +
> +/* S3C2443 specific clocks */
> +
> +static struct clk_div_table armdiv_s3c2443_d[] = {
> +	{ .val = 0, .div = 1 },
> +	{ .val = 8, .div = 2 },
> +	{ .val = 2, .div = 3 },
> +	{ .val = 9, .div = 4 },
> +	{ .val = 10, .div = 6 },
> +	{ .val = 11, .div = 8 },
> +	{ .val = 13, .div = 12 },
> +	{ .val = 15, .div = 16 },
> +	{ .div = 0 },
> +};
> +
> +struct samsung_div_clock s3c2443_dividers[] __initdata = {
> +	DIV_T(ARMDIV, "armdiv", "msysclk", CLKDIV0, 9, 4, armdiv_s3c2443_d),
> +	DIV(0, "div_cam", "esysclk", CLKDIV1, 26, 4),
> +};
> +
> +struct samsung_gate_clock s3c2443_gates[] __initdata = {
> +	GATE(SCLK_HSSPI0, "sclk_hsspi0", "div_hsspi0_epll", SCLKCON, 14, 0, 0),
> +	GATE(SCLK_CAM, "sclk_cam", "div_cam", SCLKCON, 11, 0, 0),
> +	GATE(HCLK_CFC, "cfc", "hclk", HCLKCON, 17, CLK_IGNORE_UNUSED, 0),
> +	GATE(HCLK_CAM, "cam", "hclk", HCLKCON, 8, 0, 0),
> +	GATE(PCLK_SPI1, "spi1", "pclk", PCLKCON, 15, 0, 0),
> +	GATE(PCLK_SDI, "sdi", "pclk", PCLKCON, 5, 0, 0),
> +};
> +
> +struct samsung_clock_alias s3c2443_aliases[] __initdata = {
> +	ALIAS(SCLK_HSSPI0, "s3c2443-spi.0", "spi_busclk2"),
> +	ALIAS(SCLK_HSMMC1, "s3c-sdhci.1", "mmc_busclk.2"),
> +	ALIAS(SCLK_CAM, NULL, "camif-upll"),
> +	ALIAS(PCLK_SPI1, "s3c2410-spi.0", "spi"),
> +	ALIAS(PCLK_SDI, NULL, "sdi"),
> +	ALIAS(HCLK_CFC, NULL, "cfc"),
> +	ALIAS(ARMDIV, NULL, "armdiv"),
> +};
> +
> +/* S3C2450 specific clocks */
> +
> +PNAME(s3c2450_cam_p) = { "div_cam", "hclk" };
> +PNAME(s3c2450_hsspi1_p) = { "hsspi1_epll", "hsspi1_mpll" };
> +PNAME(i2s1_p) = { "div_i2s1", "ext_i2s", "epllref", "epllref" };
> +
> +struct samsung_div_clock s3c2450_dividers[] __initdata = {
> +	DIV(0, "div_cam", "esysclk", CLKDIV1, 26, 4),
> +	DIV(0, "div_hsspi1_epll", "esysclk", CLKDIV2, 24, 2),
> +	DIV(0, "div_hsspi1_mpll", "msysclk", CLKDIV2, 16, 4),
> +	DIV(0, "div_i2s1", "esysclk", CLKDIV2, 12, 4),
> +};
> +
> +struct samsung_mux_clock s3c2450_muxes[] __initdata = {
> +	MUX(0, "mux_cam", s3c2450_cam_p, CLKSRC, 20, 1),
> +	MUX(MUX_HSSPI1, "mux_hsspi1", s3c2450_hsspi1_p, CLKSRC, 19, 1),
> +	MUX(0, "mux_i2s1", i2s1_p, CLKSRC, 12, 2),
> +};
> +
> +struct samsung_gate_clock s3c2450_gates[] __initdata = {
> +	GATE(SCLK_I2S1, "sclk_i2s1", "div_i2s1", SCLKCON, 5, 0, 0),
> +	GATE(HCLK_CFC, "cfc", "hclk", HCLKCON, 17, 0, 0),
> +	GATE(HCLK_CAM, "cam", "hclk", HCLKCON, 8, 0, 0),
> +	GATE(HCLK_DMA7, "dma7", "hclk", HCLKCON, 7, CLK_IGNORE_UNUSED, 0),
> +	GATE(HCLK_DMA6, "dma6", "hclk", HCLKCON, 6, CLK_IGNORE_UNUSED, 0),
> +	GATE(PCLK_I2S1, "i2s1", "pclk", PCLKCON, 17, 0, 0),
> +	GATE(PCLK_I2C1, "i2c1", "pclk", PCLKCON, 16, 0, 0),
> +	GATE(PCLK_SPI1, "spi1", "pclk", PCLKCON, 14, 0, 0),
> +};
> +
> +struct samsung_clock_alias s3c2450_aliases[] __initdata = {
> +	ALIAS(PCLK_SPI1, "s3c2443-spi.1", "spi"),
> +	ALIAS(PCLK_SPI1, "s3c2443-spi.1", "spi_busclk0"),
> +	ALIAS(MUX_HSSPI1, "s3c2443-spi.1", "spi_busclk2"),
> +	ALIAS(PCLK_I2C1, "s3c2410-i2c.1", "i2c"),
> +};
> +
> +/*
> + * This function allows non-dt platforms to specify the clock speed of the
> + * xti and ext clocks.
> + */
> +void __init s3c2443_clk_register_fixed_ext(unsigned long xti_f,
> +				unsigned long ext_f, unsigned long i2s_f,
> +				unsigned long uart_f)
> +{
> +	s3c2443_common_frate_clks[0].fixed_rate = xti_f;
> +	s3c2443_common_frate_clks[1].fixed_rate = ext_f;
> +	s3c2443_common_frate_clks[2].fixed_rate = i2s_f;
> +	s3c2443_common_frate_clks[3].fixed_rate = uart_f;
> +
> +	samsung_clk_register_fixed_rate(s3c2443_common_frate_clks,
> +			ARRAY_SIZE(s3c2443_common_frate_clks));
> +}
> +
> +static __initdata struct of_device_id ext_clk_match[] = {
> +	{ .compatible = "samsung,clock-xti", .data = (void *)0, },
> +	{ .compatible = "samsung,clock-ext", .data = (void *)1, },
> +	{ .compatible = "samsung,clock-ext-i2s", .data = (void *)2, },
> +	{ .compatible = "samsung,clock-ext-uart", .data = (void *)3, },
> +	{},
> +};

I wonder if we shouldn't use the generic clock bindings to define these instead 
of introducing platform specific binding. I know this has been already done for 
Exynos (and even in my patches for S3C64xx - I need to fix this), but I 
think the preferred way now (or maybe even the only allowed) is to use the 
generic bindings.

> +
> +void __init s3c2443_common_clk_init(struct device_node *np, int
> current_soc, +			     void __iomem *reg_base)
> +{
> +	struct clk *mpll, *epll;
> +
> +	if (np) {
> +		reg_base = of_iomap(np, 0);
> +		if (!reg_base)
> +			panic("%s: failed to map registers\n", __func__);
> +	}
> +
> +	samsung_clk_init(np, reg_base, NR_CLKS,
> +		s3c2443_clk_regs, ARRAY_SIZE(s3c2443_clk_regs), NULL, 0);
> +
> +	if (np)
> +		samsung_clk_of_register_fixed_ext(s3c2443_common_frate_clks,
> +			ARRAY_SIZE(s3c2443_common_frate_clks),
> +			ext_clk_match);
> +
> +	samsung_clk_register_fixed_factor(s3c2443_common_ffactor,
> +			ARRAY_SIZE(s3c2443_common_ffactor));
> +
> +	if (current_soc == S3C2416 || current_soc == S3C2450) {
> +		mpll = samsung_clk_register_pll6552x("mpll", "mpllref",
> +					reg_base + MPLLCON);
> +		epll = samsung_clk_register_pll6553x("epll", "epllref",
> +					reg_base + EPLLCON);
> +	} else {
> +		mpll = samsung_clk_register_pll3000x("mpll", "mpllref",
> +					reg_base + MPLLCON);
> +		epll = samsung_clk_register_pll2126x("epll", "epllref",
> +					reg_base + EPLLCON);
> +	}
> +
> +	samsung_clk_register_mux(s3c2443_common_muxes,
> +			ARRAY_SIZE(s3c2443_common_muxes));
> +	samsung_clk_register_div(s3c2443_common_dividers,
> +			ARRAY_SIZE(s3c2443_common_dividers));
> +	samsung_clk_register_gate(s3c2443_common_gates,
> +		ARRAY_SIZE(s3c2443_common_gates));
> +	samsung_clk_register_alias(s3c2443_common_aliases,
> +		ARRAY_SIZE(s3c2443_common_aliases));
> +
> +	if (current_soc == S3C2416 || current_soc == S3C2450) {
> +		samsung_clk_register_div(s3c2416_dividers,
> +				ARRAY_SIZE(s3c2416_dividers));
> +		samsung_clk_register_mux(s3c2416_muxes,
> +				ARRAY_SIZE(s3c2416_muxes));
> +		samsung_clk_register_gate(s3c2416_gates,
> +				ARRAY_SIZE(s3c2416_gates));
> +		samsung_clk_register_alias(s3c2416_aliases,
> +				ARRAY_SIZE(s3c2416_aliases));
> +	} else {
> +		samsung_clk_register_div(s3c2443_dividers,
> +				ARRAY_SIZE(s3c2443_dividers));
> +		samsung_clk_register_gate(s3c2443_gates,
> +				ARRAY_SIZE(s3c2443_gates));
> +		samsung_clk_register_alias(s3c2443_aliases,
> +				ARRAY_SIZE(s3c2443_aliases));
> +	}
> +
> +	/* s3c2450 extends the s3c2416 clocks */
> +	if (current_soc == S3C2450) {
> +		samsung_clk_register_div(s3c2450_dividers,
> +				ARRAY_SIZE(s3c2450_dividers));
> +		samsung_clk_register_mux(s3c2450_muxes,
> +				ARRAY_SIZE(s3c2450_muxes));
> +		samsung_clk_register_gate(s3c2450_gates,
> +				ARRAY_SIZE(s3c2450_gates));
> +		samsung_clk_register_alias(s3c2450_aliases,
> +				ARRAY_SIZE(s3c2450_aliases));
> +	}

nit: What about using a switch statement, like:

	switch (current_soc) {
	case S3C2450:
		/* register 2450 specific clocks */
		/* fall through */
	case S3C2416:
		/* register clocks common to 2416 and 2450 */
		break;
	case S3C2443:
		/* register 2443 specific clocks */
		break;
	}

Still, I guess it's just a matter of preference, so just feel free to leave it 
as it is.

Best regards,
Tomasz



From rnayak at ti.com  Thu Jul 11 05:17:00 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Thu, 11 Jul 2013 14:47:00 +0530
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130710160704.GH18966@arwen.pp.htv.fi>
References: <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <87mwpuakod.fsf@linaro.org>
 <20130710142633.GV5523@atomide.com> <20130710160704.GH18966@arwen.pp.htv.fi>
Message-ID: <51DE780C.2070701@ti.com>

On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
> how about something like below ? It makes omap_device/hwmod and
> pm_runtime agree on the initial state of the device and will prevent
> ->runtime_resume() from being called on first pm_runtime_get*() done
> during probe.
> 
> This is similar to what PCI bus does (if you look at pci_pm_init()).

I tried something similar [1] but what I found is that the serial
runtime resume was called despite it being marked as active using
pm_runtime_set_active().

That seems to be because of the pm_runtime_set_autosuspend_delay()
because we have the autosuspend_delay = -1

-----
static void update_autosuspend(struct device *dev, int old_delay, int old_use)
{
        int delay = dev->power.autosuspend_delay;

        /* Should runtime suspend be prevented now? */
        if (dev->power.use_autosuspend && delay < 0) {

                /* If it used to be allowed then prevent it. */
                if (!old_use || old_delay >= 0) {
                        atomic_inc(&dev->power.usage_count);
                        rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
                }
        }
-----

So we end up with the same issue with serial resume being called before set_termios()

[1]

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..c71d47d 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
        struct device_node *node = pdev->dev.of_node;
        const char *oh_name;
        int oh_cnt, i, ret = 0;
+       bool device_active = false;
 
        oh_cnt = of_property_count_strings(node, "ti,hwmods");
        if (oh_cnt <= 0) {
@@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
                        goto odbfd_exit1;
                }
                hwmods[i] = oh;
+               if (oh->flags & HWMOD_INIT_NO_IDLE)
+                       device_active = true;
+                       
        }
 
        od = omap_device_alloc(pdev, hwmods, oh_cnt);
@@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
 
        pdev->dev.pm_domain = &omap_device_pm_domain;
 
+       if (device_active) {
+               omap_device_enable(pdev);
+               pm_runtime_set_active(&pdev->dev);
+       }
+       
 odbfd_exit1:
        kfree(hwmods);
 odbfd_exit:



From sachin.kamat at linaro.org  Thu Jul 11 05:02:08 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Thu, 11 Jul 2013 14:32:08 +0530
Subject: [PATCH 0/6] clk: exynos: Some fixes and cleanup
Message-ID: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>

Resending some of patches (1, 3 and 5) as per discussion in thread [1].
Other patches in the series are new.

[1] http://comments.gmane.org/gmane.linux.kernel.samsung-soc/19933

Sachin Kamat (6):
  clk: exynos4: Staticize local symbols
  clk: exynos4: Remove unused function
  clk: exynos5250: Staticize local symbols
  clk: exynos5420: Staticize local symbols
  clk: exynos5440: Staticize local symbols
  clk: exynos-audss: Staticize exynos_audss_clk_init

 drivers/clk/samsung/clk-exynos-audss.c |    2 +-
 drivers/clk/samsung/clk-exynos4.c      |   42 ++++++++++++--------------------
 drivers/clk/samsung/clk-exynos5250.c   |   14 +++++------
 drivers/clk/samsung/clk-exynos5420.c   |   14 +++++------
 drivers/clk/samsung/clk-exynos5440.c   |   14 +++++------
 5 files changed, 37 insertions(+), 49 deletions(-)

-- 
1.7.9.5



From sachin.kamat at linaro.org  Thu Jul 11 05:02:09 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Thu, 11 Jul 2013 14:32:09 +0530
Subject: [PATCH 1/6] clk: exynos4: Staticize local symbols
In-Reply-To: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
References: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1373533334-5169-2-git-send-email-sachin.kamat@linaro.org>

Symbols referenced only in this file are made static.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
---
 drivers/clk/samsung/clk-exynos4.c |   30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index 1bdb882..18eadc4 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -338,24 +338,24 @@ PNAME(mout_user_aclk200_p4x12) = {"fin_pll", "div_aclk200", };
 PNAME(mout_user_aclk266_gps_p4x12) = {"fin_pll", "div_aclk266_gps", };
 
 /* fixed rate clocks generated outside the soc */
-struct samsung_fixed_rate_clock exynos4_fixed_rate_ext_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos4_fixed_rate_ext_clks[] __initdata = {
 	FRATE(xxti, "xxti", NULL, CLK_IS_ROOT, 0),
 	FRATE(xusbxti, "xusbxti", NULL, CLK_IS_ROOT, 0),
 };
 
 /* fixed rate clocks generated inside the soc */
-struct samsung_fixed_rate_clock exynos4_fixed_rate_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos4_fixed_rate_clks[] __initdata = {
 	FRATE(none, "sclk_hdmi24m", NULL, CLK_IS_ROOT, 24000000),
 	FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 27000000),
 	FRATE(none, "sclk_usbphy0", NULL, CLK_IS_ROOT, 48000000),
 };
 
-struct samsung_fixed_rate_clock exynos4210_fixed_rate_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos4210_fixed_rate_clks[] __initdata = {
 	FRATE(none, "sclk_usbphy1", NULL, CLK_IS_ROOT, 48000000),
 };
 
 /* list of mux clocks supported in all exynos4 soc's */
-struct samsung_mux_clock exynos4_mux_clks[] __initdata = {
+static struct samsung_mux_clock exynos4_mux_clks[] __initdata = {
 	MUX_FA(mout_apll, "mout_apll", mout_apll_p, SRC_CPU, 0, 1,
 			CLK_SET_RATE_PARENT, 0, "mout_apll"),
 	MUX(none, "mout_hdmi", mout_hdmi_p, SRC_TV, 0, 1),
@@ -372,7 +372,7 @@ struct samsung_mux_clock exynos4_mux_clks[] __initdata = {
 };
 
 /* list of mux clocks supported in exynos4210 soc */
-struct samsung_mux_clock exynos4210_mux_clks[] __initdata = {
+static struct samsung_mux_clock exynos4210_mux_clks[] __initdata = {
 	MUX(none, "mout_aclk200", sclk_ampll_p4210, SRC_TOP0, 12, 1),
 	MUX(none, "mout_aclk100", sclk_ampll_p4210, SRC_TOP0, 16, 1),
 	MUX(none, "mout_aclk160", sclk_ampll_p4210, SRC_TOP0, 20, 1),
@@ -423,7 +423,7 @@ struct samsung_mux_clock exynos4210_mux_clks[] __initdata = {
 };
 
 /* list of mux clocks supported in exynos4x12 soc */
-struct samsung_mux_clock exynos4x12_mux_clks[] __initdata = {
+static struct samsung_mux_clock exynos4x12_mux_clks[] __initdata = {
 	MUX_A(mout_mpll_user_c, "mout_mpll_user_c", mout_mpll_user_p4x12,
 			SRC_CPU, 24, 1, "mout_mpll"),
 	MUX(none, "mout_aclk266_gps", aclk_p4412, SRC_TOP1, 4, 1),
@@ -491,7 +491,7 @@ struct samsung_mux_clock exynos4x12_mux_clks[] __initdata = {
 };
 
 /* list of divider clocks supported in all exynos4 soc's */
-struct samsung_div_clock exynos4_div_clks[] __initdata = {
+static struct samsung_div_clock exynos4_div_clks[] __initdata = {
 	DIV(none, "div_core", "mout_core", DIV_CPU0, 0, 3),
 	DIV(none, "div_core2", "div_core", DIV_CPU0, 28, 3),
 	DIV(none, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
@@ -554,7 +554,7 @@ struct samsung_div_clock exynos4_div_clks[] __initdata = {
 };
 
 /* list of divider clocks supported in exynos4210 soc */
-struct samsung_div_clock exynos4210_div_clks[] __initdata = {
+static struct samsung_div_clock exynos4210_div_clks[] __initdata = {
 	DIV(aclk200, "aclk200", "mout_aclk200", DIV_TOP, 0, 3),
 	DIV(sclk_fimg2d, "sclk_fimg2d", "mout_g2d", DIV_IMAGE, 0, 4),
 	DIV(none, "div_fimd1", "mout_fimd1", E4210_DIV_LCD1, 0, 4),
@@ -565,7 +565,7 @@ struct samsung_div_clock exynos4210_div_clks[] __initdata = {
 };
 
 /* list of divider clocks supported in exynos4x12 soc */
-struct samsung_div_clock exynos4x12_div_clks[] __initdata = {
+static struct samsung_div_clock exynos4x12_div_clks[] __initdata = {
 	DIV(none, "div_mdnie0", "mout_mdnie0", DIV_LCD0, 4, 4),
 	DIV(none, "div_mdnie_pwm0", "mout_mdnie_pwm0", DIV_LCD0, 8, 4),
 	DIV(none, "div_mdnie_pwm_pre0", "div_mdnie_pwm0", DIV_LCD0, 12, 4),
@@ -590,7 +590,7 @@ struct samsung_div_clock exynos4x12_div_clks[] __initdata = {
 };
 
 /* list of gate clocks supported in all exynos4 soc's */
-struct samsung_gate_clock exynos4_gate_clks[] __initdata = {
+static struct samsung_gate_clock exynos4_gate_clks[] __initdata = {
 	/*
 	 * After all Exynos4 based platforms are migrated to use device tree,
 	 * the device name and clock alias names specified below for some
@@ -782,7 +782,7 @@ struct samsung_gate_clock exynos4_gate_clks[] __initdata = {
 };
 
 /* list of gate clocks supported in exynos4210 soc */
-struct samsung_gate_clock exynos4210_gate_clks[] __initdata = {
+static struct samsung_gate_clock exynos4210_gate_clks[] __initdata = {
 	GATE(tvenc, "tvenc", "aclk160", GATE_IP_TV, 2, 0, 0),
 	GATE(g2d, "g2d", "aclk200", E4210_GATE_IP_IMAGE, 0, 0, 0),
 	GATE(rotator, "rotator", "aclk200", E4210_GATE_IP_IMAGE, 1, 0, 0),
@@ -817,7 +817,7 @@ struct samsung_gate_clock exynos4210_gate_clks[] __initdata = {
 };
 
 /* list of gate clocks supported in exynos4x12 soc */
-struct samsung_gate_clock exynos4x12_gate_clks[] __initdata = {
+static struct samsung_gate_clock exynos4x12_gate_clks[] __initdata = {
 	GATE(audss, "audss", "sclk_epll", E4X12_GATE_IP_MAUDIO, 0, 0, 0),
 	GATE(mdnie0, "mdnie0", "aclk160", GATE_IP_LCD0, 2, 0, 0),
 	GATE(rotator, "rotator", "aclk200", E4X12_GATE_IP_IMAGE, 1, 0, 0),
@@ -975,7 +975,7 @@ static void __init exynos4_clk_register_finpll(unsigned long xom)
  * clock speed.
  */
 void __init exynos4_clk_register_fixed_ext(unsigned long xxti_f,
-						unsigned long xusbxti_f)
+						  unsigned long xusbxti_f)
 {
 	exynos4_fixed_rate_ext_clks[0].fixed_rate = xxti_f;
 	exynos4_fixed_rate_ext_clks[1].fixed_rate = xusbxti_f;
@@ -990,7 +990,9 @@ static __initdata struct of_device_id ext_clk_match[] = {
 };
 
 /* register exynos4 clocks */
-void __init exynos4_clk_init(struct device_node *np, enum exynos4_soc exynos4_soc, void __iomem *reg_base, unsigned long xom)
+static void __init exynos4_clk_init(struct device_node *np,
+				    enum exynos4_soc exynos4_soc,
+				    void __iomem *reg_base, unsigned long xom)
 {
 	struct clk *apll, *mpll, *epll, *vpll;
 
-- 
1.7.9.5



From sachin.kamat at linaro.org  Thu Jul 11 05:02:10 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Thu, 11 Jul 2013 14:32:10 +0530
Subject: [PATCH 2/6] clk: exynos4: Remove unused function
In-Reply-To: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
References: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1373533334-5169-3-git-send-email-sachin.kamat@linaro.org>

Subsequent to the cleanup in commit 3c70348c7c ("ARM: EXYNOS:
Remove legacy timer initialization code"), this function has no more
users. Hence remove it.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
---
 drivers/clk/samsung/clk-exynos4.c |   14 --------------
 1 file changed, 14 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index 18eadc4..75635eb 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -969,20 +969,6 @@ static void __init exynos4_clk_register_finpll(unsigned long xom)
 
 }
 
-/*
- * This function allows non-dt platforms to specify the clock speed of the
- * xxti and xusbxti clocks. These clocks are then registered with the specified
- * clock speed.
- */
-void __init exynos4_clk_register_fixed_ext(unsigned long xxti_f,
-						  unsigned long xusbxti_f)
-{
-	exynos4_fixed_rate_ext_clks[0].fixed_rate = xxti_f;
-	exynos4_fixed_rate_ext_clks[1].fixed_rate = xusbxti_f;
-	samsung_clk_register_fixed_rate(exynos4_fixed_rate_ext_clks,
-			ARRAY_SIZE(exynos4_fixed_rate_ext_clks));
-}
-
 static __initdata struct of_device_id ext_clk_match[] = {
 	{ .compatible = "samsung,clock-xxti", .data = (void *)0, },
 	{ .compatible = "samsung,clock-xusbxti", .data = (void *)1, },
-- 
1.7.9.5



From sachin.kamat at linaro.org  Thu Jul 11 05:02:11 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Thu, 11 Jul 2013 14:32:11 +0530
Subject: [PATCH 3/6] clk: exynos5250: Staticize local symbols
In-Reply-To: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
References: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1373533334-5169-4-git-send-email-sachin.kamat@linaro.org>

Symbols referenced only in this file are made static.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
---
 drivers/clk/samsung/clk-exynos5250.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index 3da0bdf..e6a4be1 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -193,24 +193,24 @@ PNAME(mout_spdif_p)	= { "sclk_audio0", "sclk_audio1", "sclk_audio2",
 				"spdif_extclk" };
 
 /* fixed rate clocks generated outside the soc */
-struct samsung_fixed_rate_clock exynos5250_fixed_rate_ext_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos5250_fixed_rate_ext_clks[] __initdata = {
 	FRATE(fin_pll, "fin_pll", NULL, CLK_IS_ROOT, 0),
 };
 
 /* fixed rate clocks generated inside the soc */
-struct samsung_fixed_rate_clock exynos5250_fixed_rate_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos5250_fixed_rate_clks[] __initdata = {
 	FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 24000000),
 	FRATE(none, "sclk_hdmi27m", NULL, CLK_IS_ROOT, 27000000),
 	FRATE(none, "sclk_dptxphy", NULL, CLK_IS_ROOT, 24000000),
 	FRATE(none, "sclk_uhostphy", NULL, CLK_IS_ROOT, 48000000),
 };
 
-struct samsung_fixed_factor_clock exynos5250_fixed_factor_clks[] __initdata = {
+static struct samsung_fixed_factor_clock exynos5250_fixed_factor_clks[] __initdata = {
 	FFACTOR(none, "fout_mplldiv2", "fout_mpll", 1, 2, 0),
 	FFACTOR(none, "fout_bplldiv2", "fout_bpll", 1, 2, 0),
 };
 
-struct samsung_mux_clock exynos5250_mux_clks[] __initdata = {
+static struct samsung_mux_clock exynos5250_mux_clks[] __initdata = {
 	MUX_A(none, "mout_apll", mout_apll_p, SRC_CPU, 0, 1, "mout_apll"),
 	MUX_A(none, "mout_cpu", mout_cpu_p, SRC_CPU, 16, 1, "mout_cpu"),
 	MUX(none, "mout_mpll_fout", mout_mpll_fout_p, PLL_DIV2_SEL, 4, 1),
@@ -256,7 +256,7 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata = {
 	MUX(none, "mout_spi2", mout_group1_p, SRC_PERIC1, 24, 4),
 };
 
-struct samsung_div_clock exynos5250_div_clks[] __initdata = {
+static struct samsung_div_clock exynos5250_div_clks[] __initdata = {
 	DIV(none, "div_arm", "mout_cpu", DIV_CPU0, 0, 3),
 	DIV(none, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3),
 	DIV(none, "aclk66_pre", "sclk_mpll_user", DIV_TOP1, 24, 3),
@@ -316,7 +316,7 @@ struct samsung_div_clock exynos5250_div_clks[] __initdata = {
 			DIV_PERIC2, 8, 8, CLK_SET_RATE_PARENT, 0),
 };
 
-struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
+static struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
 	GATE(gscl0, "gscl0", "none", GATE_IP_GSCL, 0, 0, 0),
 	GATE(gscl1, "gscl1", "none", GATE_IP_GSCL, 1, 0, 0),
 	GATE(gscl2, "gscl2", "aclk266", GATE_IP_GSCL, 2, 0, 0),
@@ -474,7 +474,7 @@ static __initdata struct of_device_id ext_clk_match[] = {
 };
 
 /* register exynox5250 clocks */
-void __init exynos5250_clk_init(struct device_node *np)
+static void __init exynos5250_clk_init(struct device_node *np)
 {
 	void __iomem *reg_base;
 	struct clk *apll, *mpll, *epll, *vpll, *bpll, *gpll, *cpll;
-- 
1.7.9.5



From sachin.kamat at linaro.org  Thu Jul 11 05:02:12 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Thu, 11 Jul 2013 14:32:12 +0530
Subject: [PATCH 4/6] clk: exynos5420: Staticize local symbols
In-Reply-To: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
References: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1373533334-5169-5-git-send-email-sachin.kamat@linaro.org>

Symbols referenced only in this file are made static.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
---
 drivers/clk/samsung/clk-exynos5420.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index 68a96cb..125728a 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -262,12 +262,12 @@ PNAME(maudio0_p)	= { "fin_pll", "maudio_clk", "sclk_dpll", "sclk_mpll",
 			  "sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };
 
 /* fixed rate clocks generated outside the soc */
-struct samsung_fixed_rate_clock exynos5420_fixed_rate_ext_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos5420_fixed_rate_ext_clks[] __initdata = {
 	FRATE(fin_pll, "fin_pll", NULL, CLK_IS_ROOT, 0),
 };
 
 /* fixed rate clocks generated inside the soc */
-struct samsung_fixed_rate_clock exynos5420_fixed_rate_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos5420_fixed_rate_clks[] __initdata = {
 	FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 24000000),
 	FRATE(none, "sclk_pwi", NULL, CLK_IS_ROOT, 24000000),
 	FRATE(none, "sclk_usbh20", NULL, CLK_IS_ROOT, 48000000),
@@ -275,11 +275,11 @@ struct samsung_fixed_rate_clock exynos5420_fixed_rate_clks[] __initdata = {
 	FRATE(none, "sclk_usbh20_scan_clk", NULL, CLK_IS_ROOT, 480000000),
 };
 
-struct samsung_fixed_factor_clock exynos5420_fixed_factor_clks[] __initdata = {
+static struct samsung_fixed_factor_clock exynos5420_fixed_factor_clks[] __initdata = {
 	FFACTOR(none, "sclk_hsic_12m", "fin_pll", 1, 2, 0),
 };
 
-struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
+static struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
 	MUX(none, "mout_mspll_kfc", mspll_cpu_p, SRC_TOP7, 8, 2),
 	MUX(none, "mout_mspll_cpu", mspll_cpu_p, SRC_TOP7, 12, 2),
 	MUX(none, "mout_apll", apll_p, SRC_CPU, 0, 1),
@@ -399,7 +399,7 @@ struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
 	MUX(none, "mout_spi2", group2_p, SRC_PERIC1, 28, 3),
 };
 
-struct samsung_div_clock exynos5420_div_clks[] __initdata = {
+static struct samsung_div_clock exynos5420_div_clks[] __initdata = {
 	DIV(none, "div_arm", "mout_cpu", DIV_CPU0, 0, 3),
 	DIV(none, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3),
 	DIV(none, "armclk2", "div_arm", DIV_CPU0, 28, 3),
@@ -479,7 +479,7 @@ struct samsung_div_clock exynos5420_div_clks[] __initdata = {
 	DIV(none, "dout_pre_spi2", "dout_spi2", DIV_PERIC4, 24, 8),
 };
 
-struct samsung_gate_clock exynos5420_gate_clks[] __initdata = {
+static struct samsung_gate_clock exynos5420_gate_clks[] __initdata = {
 	/* TODO: Re-verify the CG bits for all the gate clocks */
 	GATE_A(mct, "pclk_st", "aclk66_psgen", GATE_BUS_PERIS1, 2, 0, 0, "mct"),
 
@@ -704,7 +704,7 @@ static __initdata struct of_device_id ext_clk_match[] = {
 };
 
 /* register exynos5420 clocks */
-void __init exynos5420_clk_init(struct device_node *np)
+static void __init exynos5420_clk_init(struct device_node *np)
 {
 	void __iomem *reg_base;
 	struct clk *apll, *bpll, *cpll, *dpll, *epll, *ipll, *kpll, *mpll;
-- 
1.7.9.5



From sachin.kamat at linaro.org  Thu Jul 11 05:02:13 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Thu, 11 Jul 2013 14:32:13 +0530
Subject: [PATCH 5/6] clk: exynos5440: Staticize local symbols
In-Reply-To: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
References: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1373533334-5169-6-git-send-email-sachin.kamat@linaro.org>

Symbols referenced only in this file are made static.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
---
 drivers/clk/samsung/clk-exynos5440.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5440.c b/drivers/clk/samsung/clk-exynos5440.c
index 7d54341..6d043a2 100644
--- a/drivers/clk/samsung/clk-exynos5440.c
+++ b/drivers/clk/samsung/clk-exynos5440.c
@@ -41,12 +41,12 @@ PNAME(mout_armclk_p)	= { "cplla", "cpllb" };
 PNAME(mout_spi_p)	= { "div125", "div200" };
 
 /* fixed rate clocks generated outside the soc */
-struct samsung_fixed_rate_clock exynos5440_fixed_rate_ext_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos5440_fixed_rate_ext_clks[] __initdata = {
 	FRATE(none, "xtal", NULL, CLK_IS_ROOT, 0),
 };
 
 /* fixed rate clocks */
-struct samsung_fixed_rate_clock exynos5440_fixed_rate_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos5440_fixed_rate_clks[] __initdata = {
 	FRATE(none, "ppll", NULL, CLK_IS_ROOT, 1000000000),
 	FRATE(none, "usb_phy0", NULL, CLK_IS_ROOT, 60000000),
 	FRATE(none, "usb_phy1", NULL, CLK_IS_ROOT, 60000000),
@@ -55,26 +55,26 @@ struct samsung_fixed_rate_clock exynos5440_fixed_rate_clks[] __initdata = {
 };
 
 /* fixed factor clocks */
-struct samsung_fixed_factor_clock exynos5440_fixed_factor_clks[] __initdata = {
+static struct samsung_fixed_factor_clock exynos5440_fixed_factor_clks[] __initdata = {
 	FFACTOR(none, "div250", "ppll", 1, 4, 0),
 	FFACTOR(none, "div200", "ppll", 1, 5, 0),
 	FFACTOR(none, "div125", "div250", 1, 2, 0),
 };
 
 /* mux clocks */
-struct samsung_mux_clock exynos5440_mux_clks[] __initdata = {
+static struct samsung_mux_clock exynos5440_mux_clks[] __initdata = {
 	MUX(none, "mout_spi", mout_spi_p, MISC_DOUT1, 5, 1),
 	MUX_A(arm_clk, "arm_clk", mout_armclk_p,
 			CPU_CLK_STATUS, 0, 1, "armclk"),
 };
 
 /* divider clocks */
-struct samsung_div_clock exynos5440_div_clks[] __initdata = {
+static struct samsung_div_clock exynos5440_div_clks[] __initdata = {
 	DIV(spi_baud, "div_spi", "mout_spi", MISC_DOUT1, 3, 2),
 };
 
 /* gate clocks */
-struct samsung_gate_clock exynos5440_gate_clks[] __initdata = {
+static struct samsung_gate_clock exynos5440_gate_clks[] __initdata = {
 	GATE(pb0_250, "pb0_250", "div250", CLKEN_OV_VAL, 3, 0, 0),
 	GATE(pr0_250, "pr0_250", "div250", CLKEN_OV_VAL, 4, 0, 0),
 	GATE(pr1_250, "pr1_250", "div250", CLKEN_OV_VAL, 5, 0, 0),
@@ -103,7 +103,7 @@ static __initdata struct of_device_id ext_clk_match[] = {
 };
 
 /* register exynos5440 clocks */
-void __init exynos5440_clk_init(struct device_node *np)
+static void __init exynos5440_clk_init(struct device_node *np)
 {
 	void __iomem *reg_base;
 
-- 
1.7.9.5



From sachin.kamat at linaro.org  Thu Jul 11 05:02:14 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Thu, 11 Jul 2013 14:32:14 +0530
Subject: [PATCH 6/6] clk: exynos-audss: Staticize exynos_audss_clk_init
In-Reply-To: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
References: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1373533334-5169-7-git-send-email-sachin.kamat@linaro.org>

exynos_audss_clk_init() is used only in this file. Make it
static.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
---
 drivers/clk/samsung/clk-exynos-audss.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
index 9b1bbd5..51b48da 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -62,7 +62,7 @@ static struct syscore_ops exynos_audss_clk_syscore_ops = {
 #endif /* CONFIG_PM_SLEEP */
 
 /* register exynos_audss clocks */
-void __init exynos_audss_clk_init(struct device_node *np)
+static void __init exynos_audss_clk_init(struct device_node *np)
 {
 	reg_base = of_iomap(np, 0);
 	if (!reg_base) {
-- 
1.7.9.5



From peter.chen at freescale.com  Thu Jul 11 05:25:36 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 11 Jul 2013 17:25:36 +0800
Subject: [PATCH v12 10/13] usb: chipidea: add wait vbus lower than
 OTGSC_BSV before role starts
In-Reply-To: <51DE5DC8.8020605@pengutronix.de>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <1373524041-10482-11-git-send-email-peter.chen@freescale.com>
 <51DE5DC8.8020605@pengutronix.de>
Message-ID: <20130711092535.GA11728@nchen-desktop>

On Thu, Jul 11, 2013 at 09:24:56AM +0200, Marc Kleine-Budde wrote:
> On 07/11/2013 08:27 AM, Peter Chen wrote:
> > When the gadget role starts, we need to make sure the vbus is lower
> > than OTGSC_BSV, or there will be an vbus interrupt since we use
> > B_SESSION_VALID as vbus interrupt to indicate connect and disconnect.
> > When the host role starts, it may not be useful to wait vbus to lower
> > than OTGSC_BSV, but it can indicate some hardware problems like the
> > vbus is still higher than OTGSC_BSV after we disconnect to host some
> > time later (500 jiffies currently), which is obvious not correct.
> 
> Jiffies ist not constant. I think you have to specify the timeout in
> fractions of HZ. The system ticks with HZ jiffies per second. So a
> timeout of 500ms is "HZ / 2".

Thanks, I will use msecs_to_jiffies.

> > +/**
> > + * hw_wait_reg: wait the register value
> > + *
> > + * Sometimes, it needs to wait register value before going on.
> > + * Eg, when switch to device mode, the vbus value should be lower
> > + * than OTGSC_BSV before connects to host.
> > + *
> > + * @ci: the controller
> > + * @reg: register index
> > + * @mask: mast bit
> > + * @value: the bit value to wait
> > + * @timeout: timeout to indicate an error
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Better: timeout in jiffies
> 

As I will use msecs_to_jiffies, @timeout: timeout in millisecond.

Thanks.

-- 

Best Regards,
Peter Chen



From tomasz.figa at gmail.com  Thu Jul 11 05:25:47 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 11 Jul 2013 11:25:47 +0200
Subject: [PATCH v2 3/6] clk: samsung: add plls used in s3c2416 and s3c2443
In-Reply-To: <201307111050.39878.heiko@sntech.de>
References: <201307100057.06061.heiko@sntech.de> <1525015.XUBJYYqnvA@thinkpad>
 <201307111050.39878.heiko@sntech.de>
Message-ID: <10485562.994mEYPTEH@thinkpad>

On Thursday 11 of July 2013 10:50:39 Heiko St?bner wrote:
> Am Donnerstag, 11. Juli 2013, 10:16:41 schrieb Tomasz Figa:
> > Hi Heiko,
> > 
> > On Wednesday 10 of July 2013 00:59:08 Heiko St?bner wrote:
> > > This adds support for pll2126x, pll3000x, pll6552x and pll6553x.
> > > 
> > > Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> > > ---
> > > 
> > >  drivers/clk/samsung/clk-pll.c |  280
> > > 
> > > +++++++++++++++++++++++++++++++++++++++++ drivers/clk/samsung/clk-pll.h
> > > |
> > > 
> > >  8 ++
> > >  2 files changed, 288 insertions(+)
> > 
> > Generally the patch looks good, but I have some comments to the part
> > related to 655xx PLLs.
> > 
> > I had a patch adding support for them too, but we can go with yours, since
> > the way of registration has been changed by Yadwinder's patches and mine
> > would have to be updated anyway.
> > 
> > > diff --git a/drivers/clk/samsung/clk-pll.c
> > > b/drivers/clk/samsung/clk-pll.c index 0afaec6..35c15a1 100644
> > > --- a/drivers/clk/samsung/clk-pll.c
> > > +++ b/drivers/clk/samsung/clk-pll.c
> > > @@ -323,6 +323,73 @@ struct clk * __init
> > > samsung_clk_register_pll46xx(const char *name, }
> > > 
> > >  /*
> > > 
> > > + * PLL2126x Clock Type
> > > + */
> > > +
> > > +#define PLL2126X_MDIV_MASK	(0xFF)
> > > +#define PLL2126X_PDIV_MASK	(0x3)
> > > +#define PLL2126X_SDIV_MASK	(0x3)
> > > +#define PLL2126X_MDIV_SHIFT	(16)
> > > +#define PLL2126X_PDIV_SHIFT	(8)
> > > +#define PLL2126X_SDIV_SHIFT	(0)
> 
> +#define PLL2126X_PDIV_MASK	(0x3F)
> 
> is the correct value.
> 
> > > +
> > > +struct samsung_clk_pll2126x {
> > > +	struct clk_hw		hw;
> > > +	const void __iomem	*con_reg;
> > > +};
> > > +
> > > +#define to_clk_pll2126x(_hw) container_of(_hw, struct
> > > samsung_clk_pll2126x, hw) +
> > > +static unsigned long samsung_pll2126x_recalc_rate(struct clk_hw *hw,
> > > +				unsigned long parent_rate)
> > > +{
> > > +	struct samsung_clk_pll2126x *pll = to_clk_pll2126x(hw);
> > > +	u32 pll_con, mdiv, pdiv, sdiv;
> > > +	u64 fvco = parent_rate;
> > > +
> > > +	pll_con = __raw_readl(pll->con_reg);
> > > +	mdiv = (pll_con >> PLL2126X_MDIV_SHIFT) & PLL2126X_MDIV_MASK;
> > > +	pdiv = (pll_con >> PLL2126X_PDIV_SHIFT) & PLL2126X_PDIV_MASK;
> > > +	sdiv = (pll_con >> PLL2126X_SDIV_SHIFT) & PLL2126X_SDIV_MASK;
> > > +
> > > +	fvco *= (mdiv + 8);
> > > +	do_div(fvco, (pdiv + 2) << sdiv);
> > > +
> > > +	return (unsigned long)fvco;
> > > +}
> > > +
> > > +static const struct clk_ops samsung_pll2126x_clk_ops = {
> > > +	.recalc_rate = samsung_pll2126x_recalc_rate,
> > > +};
> > > +
> > > +struct clk * __init samsung_clk_register_pll2126x(const char *name,
> > > +			const char *pname, const void __iomem *con_reg)
> > > +{
> > > +	struct samsung_clk_pll2126x *pll;
> > > +	struct clk *clk;
> > > +	struct clk_init_data init;
> > > +
> > > +	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> > > +	if (!pll)
> > > +		return ERR_PTR(-ENOMEM);
> > > +
> > > +	init.name = name;
> > > +	init.ops = &samsung_pll2126x_clk_ops;
> > > +	init.flags = CLK_GET_RATE_NOCACHE;
> > > +	init.parent_names = &pname;
> > > +	init.num_parents = 1;
> > > +
> > > +	pll->hw.init = &init;
> > > +	pll->con_reg = con_reg;
> > > +
> > > +	clk = samsung_register_pll(&pll->hw);
> > > +	if (IS_ERR(clk))
> > > +		kfree(pll);
> > > +
> > > +	return clk;
> > > +}
> > > +
> > > +/*
> > > 
> > >   * PLL2550x Clock Type
> > >   */
> > > 
> > > @@ -396,3 +463,216 @@ struct clk * __init
> > > samsung_clk_register_pll2550x(const char *name,
> > > 
> > >  	return clk;
> > >  
> > >  }
> > > 
> > > +
> > > +/*
> > > + * PLL3000x Clock Type
> > > + */
> > > +
> > > +#define PLL3000X_MDIV_MASK	(0xFF)
> > > +#define PLL3000X_PDIV_MASK	(0x3)
> > > +#define PLL3000X_SDIV_MASK	(0x3)
> > > +#define PLL3000X_MDIV_SHIFT	(16)
> > > +#define PLL3000X_PDIV_SHIFT	(8)
> > > +#define PLL3000X_SDIV_SHIFT	(0)
> 
> these are correct.
> 
> > > +
> > > +struct samsung_clk_pll3000x {
> > > +	struct clk_hw		hw;
> > > +	const void __iomem	*con_reg;
> > > +};
> > > +
> > > +#define to_clk_pll3000x(_hw) container_of(_hw, struct
> > > samsung_clk_pll3000x, hw) +
> > > +static unsigned long samsung_pll3000x_recalc_rate(struct clk_hw *hw,
> > > +				unsigned long parent_rate)
> > > +{
> > > +	struct samsung_clk_pll3000x *pll = to_clk_pll3000x(hw);
> > > +	u32 pll_con, mdiv, pdiv, sdiv;
> > > +	u64 fvco = parent_rate;
> > > +
> > > +	pll_con = __raw_readl(pll->con_reg);
> > > +	mdiv = (pll_con >> PLL3000X_MDIV_SHIFT) & PLL3000X_MDIV_MASK;
> > > +	pdiv = (pll_con >> PLL3000X_PDIV_SHIFT) & PLL3000X_PDIV_MASK;
> > > +	sdiv = (pll_con >> PLL3000X_SDIV_SHIFT) & PLL3000X_SDIV_MASK;
> > > +
> > > +	fvco *= (2 * (mdiv + 8));
> > > +	do_div(fvco, pdiv << sdiv);
> > > +
> > > +	return (unsigned long)fvco;
> > > +}
> > > +
> > > +static const struct clk_ops samsung_pll3000x_clk_ops = {
> > > +	.recalc_rate = samsung_pll3000x_recalc_rate,
> > > +};
> > > +
> > > +struct clk * __init samsung_clk_register_pll3000x(const char *name,
> > > +			const char *pname, const void __iomem *con_reg)
> > > +{
> > > +	struct samsung_clk_pll3000x *pll;
> > > +	struct clk *clk;
> > > +	struct clk_init_data init;
> > > +
> > > +	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> > > +	if (!pll)
> > > +		return ERR_PTR(-ENOMEM);
> > > +
> > > +	init.name = name;
> > > +	init.ops = &samsung_pll3000x_clk_ops;
> > > +	init.flags = CLK_GET_RATE_NOCACHE;
> > > +	init.parent_names = &pname;
> > > +	init.num_parents = 1;
> > > +
> > > +	pll->hw.init = &init;
> > > +	pll->con_reg = con_reg;
> > > +
> > > +	clk = samsung_register_pll(&pll->hw);
> > > +	if (IS_ERR(clk))
> > > +		kfree(pll);
> > > +
> > > +	return clk;
> > > +}
> > > +
> > > +/*
> > > + * PLL6552x Clock Type
> > > + */
> > > +
> > > +#define PLL6552X_MDIV_MASK	(0x3FF)
> > > +#define PLL6552X_PDIV_MASK	(0x3F)
> > > +#define PLL6552X_SDIV_MASK	(0x7)
> > > +#define PLL6552X_MDIV_SHIFT	(14)
> > > +#define PLL6552X_PDIV_SHIFT	(5)
> > > +#define PLL6552X_SDIV_SHIFT	(0)
> > 
> > Are you sure about those bitfields?
> > 
> > In S3C6410 User's Manual they are different. You can look at my patch for
> > a
> > comparison:
> > 
> > http://thread.gmane.org/gmane.linux.usb.general/87571/focus=88344
> 
> The numbers where taken from the previous pll code, but I now again checked
> them against the datasheet of the s3c2416 and the s3c2450.
> 
> When comparing with your patch, it really seems that the bit offsets in the
> register are different for the pdiv and mdiv - the above values are correct
> according the the datasheet (and also produce the expected results in the
> clock tree).

> > > +struct samsung_clk_pll6552x {
> > > +	struct clk_hw		hw;
> > > +	const void __iomem	*con_reg;
> > > +};
> > > +
> > > +#define to_clk_pll6552x(_hw) container_of(_hw, struct
> > > samsung_clk_pll6552x, hw) +
> > > +static unsigned long samsung_pll6552x_recalc_rate(struct clk_hw *hw,
> > > +				unsigned long parent_rate)
> > > +{
> > > +	struct samsung_clk_pll6552x *pll = to_clk_pll6552x(hw);
> > > +	u32 pll_con, mdiv, pdiv, sdiv;
> > > +	u64 fvco = parent_rate;
> > > +
> > > +	pll_con = __raw_readl(pll->con_reg);
> > > +	mdiv = (pll_con >> PLL6552X_MDIV_SHIFT) & PLL6552X_MDIV_MASK;
> > > +	pdiv = (pll_con >> PLL6552X_PDIV_SHIFT) & PLL6552X_PDIV_MASK;
> > > +	sdiv = (pll_con >> PLL6552X_SDIV_SHIFT) & PLL6552X_SDIV_MASK;
> > > +
> > > +	fvco *= mdiv;
> > > +	do_div(fvco, (pdiv << sdiv));
> > > +
> > > +	return (unsigned long)fvco;
> > > +}
> > > +
> > > +static const struct clk_ops samsung_pll6552x_clk_ops = {
> > > +	.recalc_rate = samsung_pll6552x_recalc_rate,
> > > +};
> > > +
> > > +struct clk * __init samsung_clk_register_pll6552x(const char *name,
> > > +			const char *pname, const void __iomem *con_reg)
> > > +{
> > > +	struct samsung_clk_pll6552x *pll;
> > > +	struct clk *clk;
> > > +	struct clk_init_data init;
> > > +
> > > +	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> > > +	if (!pll)
> > > +		return ERR_PTR(-ENOMEM);
> > > +
> > > +	init.name = name;
> > > +	init.ops = &samsung_pll6552x_clk_ops;
> > > +	init.flags = CLK_GET_RATE_NOCACHE;
> > > +	init.parent_names = &pname;
> > > +	init.num_parents = 1;
> > > +
> > > +	pll->hw.init = &init;
> > > +	pll->con_reg = con_reg;
> > > +
> > > +	clk = samsung_register_pll(&pll->hw);
> > > +	if (IS_ERR(clk))
> > > +		kfree(pll);
> > > +
> > > +	return clk;
> > > +}
> > > +
> > > +/*
> > > + * PLL6553x Clock Type
> > > + */
> > > +
> > > +#define PLL6553X_MDIV_MASK	(0x7F)
> > > +#define PLL6553X_PDIV_MASK	(0x1F)
> > > +#define PLL6553X_SDIV_MASK	(0x3)
> > > +#define PLL6553X_KDIV_MASK	(0xFFFF)
> > > +#define PLL6553X_MDIV_SHIFT	(16)
> > > +#define PLL6553X_PDIV_SHIFT	(8)
> > > +#define PLL6553X_SDIV_SHIFT	(0)
> > 
> > Same about those bitfields. They seem to be different on S3C64xx.
> 
> Here it seems the values were off in the original code. According to the
> datasheet the values in your patch are correct. Thanks for the catch.
> 
> +#define PLL6553X_MDIV_MASK	(0xFF)
> +#define PLL6553X_PDIV_MASK	(0x3F)
> +#define PLL6553X_SDIV_MASK	(0x7)
> 
> 
> This leaves the problem on what to do with the 6552X and its different bit
> offsets. Is the pll in question really a 6552X? In the s3c2416 manual its
> name is explicitly stated.

So is it in S3C6410 User's Manual.

If you look at the old plat/pll.h header, you can see that none of S3C2416_PLL 
(which I believe corresponds to your 6552X) and S3C6400_PLL (which is the 
PLL6552x that can be found on S3C64xx) is labelled as PLL6552x explicitly.

Best regards,
Tomasz



From balbi at ti.com  Thu Jul 11 05:26:12 2013
From: balbi at ti.com (Felipe Balbi)
Date: Thu, 11 Jul 2013 12:26:12 +0300
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51DE780C.2070701@ti.com>
References: <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi>
 <87mwpuakod.fsf@linaro.org> <20130710142633.GV5523@atomide.com>
 <20130710160704.GH18966@arwen.pp.htv.fi> <51DE780C.2070701@ti.com>
Message-ID: <20130711092612.GG23892@arwen.pp.htv.fi>

Hi,

On Thu, Jul 11, 2013 at 02:47:00PM +0530, Rajendra Nayak wrote:
> On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
> > how about something like below ? It makes omap_device/hwmod and
> > pm_runtime agree on the initial state of the device and will prevent
> > ->runtime_resume() from being called on first pm_runtime_get*() done
> > during probe.
> > 
> > This is similar to what PCI bus does (if you look at pci_pm_init()).
> 
> I tried something similar [1] but what I found is that the serial
> runtime resume was called despite it being marked as active using
> pm_runtime_set_active().
> 
> That seems to be because of the pm_runtime_set_autosuspend_delay()
> because we have the autosuspend_delay = -1
> 
> -----
> static void update_autosuspend(struct device *dev, int old_delay, int old_use)
> {
>         int delay = dev->power.autosuspend_delay;
> 
>         /* Should runtime suspend be prevented now? */
>         if (dev->power.use_autosuspend && delay < 0) {
> 
>                 /* If it used to be allowed then prevent it. */
>                 if (!old_use || old_delay >= 0) {
>                         atomic_inc(&dev->power.usage_count);
>                         rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
>                 }
>         }
> -----
> 
> So we end up with the same issue with serial resume being called before set_termios()

yeah, that part I figured out after I started testing today. It seems
like my latest version is getting closer but I still see problems, diff
below:

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index e6d2307..0cc2da9 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -181,6 +181,26 @@ odbfd_exit:
 	return ret;
 }
 
+static void omap_device_pm_init(struct platform_device *pdev)
+{
+	omap_device_enable(pdev);
+	pm_runtime_forbid(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	device_enable_async_suspend(&pdev->dev);
+}
+
+static void omap_device_pm_allow(struct platform_device *pdev)
+{
+	pm_runtime_allow(&pdev->dev);
+}
+
+static void omap_device_pm_exit(struct platform_device *pdev)
+{
+	device_disable_async_suspend(&pdev->dev);
+	pm_runtime_set_suspended(&pdev->dev);
+	omap_device_idle(pdev);
+}
+
 static int _omap_device_notifier_call(struct notifier_block *nb,
 				      unsigned long event, void *dev)
 {
@@ -192,16 +212,31 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
 		if (pdev->archdata.od)
 			omap_device_delete(pdev->archdata.od);
 		break;
+	case BUS_NOTIFY_BIND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_init(pdev);
+		break;
+	case BUS_NOTIFY_BOUND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_allow(pdev);
+		break;
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_exit(pdev);
+		break;
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdev->dev.of_node)
 			omap_device_build_from_dt(pdev);
-		/* fall through */
+		break;
 	default:
-		od = to_omap_device(pdev);
-		if (od)
-			od->_driver_status = event;
+		/* nothing */
+		break;
 	}
 
+	od = to_omap_device(pdev);
+	if (od)
+		od->_driver_status = event;
+
 	return NOTIFY_DONE;
 }
 

-- 
balbi
-------------- 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/20130711/01d3f194/attachment.sig>

From thomas.abraham at linaro.org  Thu Jul 11 05:27:49 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Thu, 11 Jul 2013 14:57:49 +0530
Subject: [PATCH] clk: samsung: add set_rate and round_rate callbacks for
 pll45xx
Message-ID: <1373534869-12034-1-git-send-email-thomas.abraham@linaro.org>

Add support for set_rate and round_rate callbacks for pll45xx pll. This allows
configuring pll45xx to generate a desired clock output.

Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
---

The set_rate and round_rate callbacks in this patch for pll45xx are handled
slightly differently from the way it is done in the (not yet merged) patch
series from Yadwinder
(http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg19540.html)

In this patch, the pll lookup table is kept as part of the pll configuration
code itself, since the pll is just a hardware block which takes an input
frequency and configuration values to genertate a output clock frequency.
Given a set of inputs, a pll of a given type will generate the same output
regardless of the SoC it is used in. So instead of supplying the pll lookup
table from per-soc clock driver code (as done in the Yadwinder's patch series),
the pll lookup table can be coupled with the pll code itself, saving duplication
of pll lookup table for every SoC the pll is used with.

 drivers/clk/samsung/clk-pll.c |   88 +++++++++++++++++++++++++++++++++++++++++
 drivers/clk/samsung/clk-pll.h |   15 +++++++
 2 files changed, 103 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 362f12d..4940936 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -172,6 +172,8 @@ struct clk * __init samsung_clk_register_pll36xx(const char *name,
  * PLL45xx Clock Type
  */
 
+#define PLL45XX_EN_MASK		(1 << 31)
+#define PLL45XX_LOCK_MASK	(1 << 29)
 #define PLL45XX_MDIV_MASK	(0x3FF)
 #define PLL45XX_PDIV_MASK	(0x3F)
 #define PLL45XX_SDIV_MASK	(0x7)
@@ -187,6 +189,90 @@ struct samsung_clk_pll45xx {
 
 #define to_clk_pll45xx(_hw) container_of(_hw, struct samsung_clk_pll45xx, hw)
 
+/* a sorted table of freq supported by pll45xx with 24mhz parent clock */
+static struct pll45xx_freq_lookup pll45xx_freq_lookup_24mhz[] = {
+	PLL45XX_PMS(1000000000, 6, 250, 1),
+	PLL45XX_PMS(800000000, 6, 200, 1),
+	PLL45XX_PMS(500000000, 6, 250, 2),
+	PLL45XX_PMS(400000000, 6, 200, 2),
+	PLL45XX_PMS(200000000, 6, 200, 3),
+};
+
+static int samsung_pll45xx_set_rate(struct clk_hw *hw, unsigned long rate,
+					unsigned long prate)
+{
+	struct samsung_clk_pll45xx *pll = to_clk_pll45xx(hw);
+	struct pll45xx_freq_lookup *f;
+	unsigned long timeout, pll_con, cnt, idx;
+
+	/* select a lookup table based on parent clock frequency */
+	switch (prate) {
+	case 24000000:
+		f = pll45xx_freq_lookup_24mhz;
+		cnt = ARRAY_SIZE(pll45xx_freq_lookup_24mhz);
+		break;
+	default:
+		pr_err("%s: unsupported parent clock rate, failed to set rate",
+					__func__);
+		return -EINVAL;
+	}
+
+	/* check if the requested freq is in the list of supported freq */
+	for (idx = 0; idx < cnt; idx++, f++)
+		if (f->target_freq == rate)
+			break;
+
+	if (idx == cnt) {
+		pr_err("%s: unspported clock speed %ld requested\n",
+				__func__, rate);
+		return -EINVAL;
+	}
+
+	/* first, disable the output of the pll */
+	writel(readl(pll->con_reg) & ~PLL45XX_EN_MASK, (void *)pll->con_reg);
+
+	/* write the new pll configuration values */
+	pll_con = (f->pdiv << PLL45XX_PDIV_SHIFT) |
+			(f->mdiv << PLL45XX_MDIV_SHIFT) |
+			(f->sdiv << PLL45XX_SDIV_SHIFT);
+	writel(pll_con, (void *)pll->con_reg);
+
+	/* enable the pll and wait for it to stabilize */
+	writel(pll_con | PLL45XX_EN_MASK, (void *)pll->con_reg);
+	timeout = jiffies + msecs_to_jiffies(20);
+	while (time_before(jiffies, timeout))
+		if (readl(pll->con_reg) & PLL45XX_LOCK_MASK)
+			return 0;
+	return -EBUSY;
+}
+
+static long samsung_pll45xx_round_rate(struct clk_hw *hw, unsigned long rate,
+						unsigned long *prate)
+{
+	struct pll45xx_freq_lookup *f;
+	unsigned long cnt;
+
+	/* select a lookup table based on parent clock frequency */
+	switch (*prate) {
+	case 24000000:
+		f = pll45xx_freq_lookup_24mhz;
+		cnt = ARRAY_SIZE(pll45xx_freq_lookup_24mhz);
+		break;
+	default:
+		pr_err("%s: unsupported parent clock rate", __func__);
+		return *prate;
+	}
+
+	/* find the nearest possible clock output that can be supported */
+	while (cnt-- > 0) {
+		if (rate >= f->target_freq)
+			return f->target_freq;
+		f++;
+	}
+
+	return (--f)->target_freq;
+}
+
 static unsigned long samsung_pll45xx_recalc_rate(struct clk_hw *hw,
 				unsigned long parent_rate)
 {
@@ -209,6 +295,8 @@ static unsigned long samsung_pll45xx_recalc_rate(struct clk_hw *hw,
 }
 
 static const struct clk_ops samsung_pll45xx_clk_ops = {
+	.set_rate = samsung_pll45xx_set_rate,
+	.round_rate = samsung_pll45xx_round_rate,
 	.recalc_rate = samsung_pll45xx_recalc_rate,
 };
 
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
index f33786e..fb687ec 100644
--- a/drivers/clk/samsung/clk-pll.h
+++ b/drivers/clk/samsung/clk-pll.h
@@ -18,6 +18,21 @@ enum pll45xx_type {
 	pll_4508
 };
 
+struct pll45xx_freq_lookup {
+	unsigned long	target_freq;
+	unsigned long	pdiv;
+	unsigned long	mdiv;
+	unsigned long	sdiv;
+};
+
+#define PLL45XX_PMS(f, p, m, s)		\
+	{					\
+		.target_freq	= f,		\
+		.pdiv		= p,		\
+		.mdiv		= m,		\
+		.sdiv		= s,		\
+	}
+
 enum pll46xx_type {
 	pll_4600,
 	pll_4650,
-- 
1.7.5.4



From mkl at pengutronix.de  Thu Jul 11 05:31:46 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Thu, 11 Jul 2013 11:31:46 +0200
Subject: [PATCH v12 10/13] usb: chipidea: add wait vbus lower than
 OTGSC_BSV before role starts
In-Reply-To: <20130711092535.GA11728@nchen-desktop>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <1373524041-10482-11-git-send-email-peter.chen@freescale.com>
 <51DE5DC8.8020605@pengutronix.de> <20130711092535.GA11728@nchen-desktop>
Message-ID: <51DE7B82.4030402@pengutronix.de>

On 07/11/2013 11:25 AM, Peter Chen wrote:
> On Thu, Jul 11, 2013 at 09:24:56AM +0200, Marc Kleine-Budde wrote:
>> On 07/11/2013 08:27 AM, Peter Chen wrote:
>>> When the gadget role starts, we need to make sure the vbus is lower
>>> than OTGSC_BSV, or there will be an vbus interrupt since we use
>>> B_SESSION_VALID as vbus interrupt to indicate connect and disconnect.
>>> When the host role starts, it may not be useful to wait vbus to lower
>>> than OTGSC_BSV, but it can indicate some hardware problems like the
>>> vbus is still higher than OTGSC_BSV after we disconnect to host some
>>> time later (500 jiffies currently), which is obvious not correct.
>>
>> Jiffies ist not constant. I think you have to specify the timeout in
>> fractions of HZ. The system ticks with HZ jiffies per second. So a
>> timeout of 500ms is "HZ / 2".
> 
> Thanks, I will use msecs_to_jiffies.

even better.

> 
>>> +/**
>>> + * hw_wait_reg: wait the register value
>>> + *
>>> + * Sometimes, it needs to wait register value before going on.
>>> + * Eg, when switch to device mode, the vbus value should be lower
>>> + * than OTGSC_BSV before connects to host.
>>> + *
>>> + * @ci: the controller
>>> + * @reg: register index
>>> + * @mask: mast bit
>>> + * @value: the bit value to wait
>>> + * @timeout: timeout to indicate an error
>>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> Better: timeout in jiffies
>>
> 
> As I will use msecs_to_jiffies, @timeout: timeout in millisecond.

Good idea - you might want to use timeout_ms.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130711/a1363c68/attachment.sig>

From sboyd at codeaurora.org  Thu Jul 11 05:33:59 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 11 Jul 2013 02:33:59 -0700
Subject: [RFC PATCH 4/5] arm64: add CPU_HOTPLUG infrastructure
In-Reply-To: <1373494549-24972-1-git-send-email-mark.rutland@arm.com>
References: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
 <1373494549-24972-1-git-send-email-mark.rutland@arm.com>
Message-ID: <20130711093359.GF830@codeaurora.org>

On 07/10, Mark Rutland wrote:
> +void __ref cpu_die(void)
> +{
> +	unsigned int cpu = smp_processor_id();
> +
> +	idle_task_exit();
> +
> +	local_irq_disable();
> +	mb();
> +
> +	/* Tell __cpu_die() that this CPU is now safe to dispose of */
> +	RCU_NONIDLE(complete(&cpu_died));

This isn't true anymore.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From markus at trippelsdorf.de  Thu Jul 11 05:46:40 2013
From: markus at trippelsdorf.de (Markus Trippelsdorf)
Date: Thu, 11 Jul 2013 11:46:40 +0200
Subject: [PATCH] .gitignore: ignore *.lz4 files
In-Reply-To: <20130711043433.GA29245@hulk>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130506095124.GA22041@pd.tnic>
 <CAMuHMdWH9w5fj6HRXi+9QcBJym4dukAFsPVGZVqSSk3yTZJUcA@mail.gmail.com>
 <20130710093642.GC14873@pd.tnic> <20130710182815.GA362@x4>
 <20130711043433.GA29245@hulk>
Message-ID: <20130711094640.GA358@x4>

Now that lz4 kernel compression is available, add *.lz4 to .gitignore.

Signed-off-by: Markus Trippelsdorf <markus at trippelsdorf.de>
Acked-by: Kyungsik Lee <kyungsik.lee at lge.com>

diff --git a/.gitignore b/.gitignore
index 3b8b9b3..7e9932e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -29,6 +29,7 @@ modules.builtin
 *.bz2
 *.lzma
 *.xz
+*.lz4
 *.lzo
 *.patch
 *.gcno
-- 
Markus


From shinya.kuribayashi.px at renesas.com  Thu Jul 11 05:50:44 2013
From: shinya.kuribayashi.px at renesas.com (Shinya Kuribayashi)
Date: Thu, 11 Jul 2013 18:50:44 +0900
Subject: [PATCH] ARM: shmobile: r8a7790 SMP prototype v4
In-Reply-To: <20130710104151.20742.56398.sendpatchset@w520>
References: <20130710104151.20742.56398.sendpatchset@w520>
Message-ID: <51DE7FF4.5050800@renesas.com>

Hello,

On 7/10/2013 7:41 PM, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Add SMP prototype support for r8a7790 by enabling
> one cluster of either 4 x Cortex-A7 or 4 x Cortex-A15.
> 
> This patch only adds support for booting, at this point
> no CPU Hotplug is included. In v4 both the big and the
> LITTLE clusters are working with either architected timers
> (in physical mode only for CA7) or CMT and broadcast timer.
> 
> On r8a7790 the MD6 pin control boot processor, and on the
> Lager board SW8.7 can be used to select big or LITTLE.
> 
> In big boot mode the CPU cores will be configured as:
>  - CPU0, CPU1, CPU2, CPU3: enabled (CA15)
>  - CPU4, CPU5, CPU6, CPU7: disabled (CA7)
> 
> In LITTLE boot mode the CPU cores will be configured as:
>  - CPU0, CPU5, CPU6, CPU7: enabled (CA7)
>  - CPU1, CPU2, CPU3, CPU4: disabled (CA15)
> 
> Base addresses for RST and APMU are still hard coded
> but DT will be used for them in future versions.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

I still have some requests to this v4 patch and would like to explain
them in the patch format; please take a look at patches attached.

> In big boot mode the CPU cores will be configured as:
> In LITTLE boot mode the CPU cores will be configured as:

This patchset is boot-tested with both "big" and "LITTLE" boot mode.

Thanks,

Shinya Kuribayashi (4):
      ARM: shmobile: smp-r8a7790: remove the obsolete RESCNT register
      ARM: shmobile: smp-r8a7790: rename s/carescnt/rescnt/g
      ARM: shmobile: smp-r8a7790: rename s/cabar/bar/g as well
      ARM: shmobile: smp-r8a7790: power up a CPU core at .smp_boot_secondary stage

 arch/arm/mach-shmobile/smp-r8a7790.c | 67 ++++++++++++++++++++++---------------------------------------------

--
Shinya Kuribayashi
Renesas Electronics


From shinya.kuribayashi.px at renesas.com  Thu Jul 11 05:51:39 2013
From: shinya.kuribayashi.px at renesas.com (Shinya Kuribayashi)
Date: Thu, 11 Jul 2013 18:51:39 +0900
Subject: [PATCH 1/4] ARM: shmobile: smp-r8a7790: remove the obsolete RESCNT
 register
In-Reply-To: <51DE7FF4.5050800@renesas.com>
References: <20130710104151.20742.56398.sendpatchset@w520>
 <51DE7FF4.5050800@renesas.com>
Message-ID: <51DE802B.6090401@renesas.com>

I should have notice this one, sorry for bothering you in v4 again.

The RESCNT register, which is supposed to be used to control clock supply
to CA15/CA7 clusters by manipulating dedicated MSTP bits, turned out that
it doesn't do anything good for clock supply to clusters.  It was listed
in the datasheet v0.5, but it's now obsolete in the datasheet v0.6.

This patch removes the defines and routines related to RESCNT.

Note that, this patch removes r8a7790_deassert_reset(0) call in
r8a7790_smp_prepare_cpus at the time.  As we already know, it's pointless
to deassert reset to CPU#0 (boot CPU) in the kernel initialization.  It
was just there to set r8a7790_clst[0].use_count to 1 on start-up to keep
.use_count balanced.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
---
 arch/arm/mach-shmobile/smp-r8a7790.c | 22 ----------------------
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/mach-shmobile/smp-r8a7790.c b/arch/arm/mach-shmobile/smp-r8a7790.c
index a1696f4..1ab4c04 100644
--- a/arch/arm/mach-shmobile/smp-r8a7790.c
+++ b/arch/arm/mach-shmobile/smp-r8a7790.c
@@ -25,7 +25,6 @@
 #define CA7BAR	0x0030
 #define CA15RESCNT 0x0040
 #define CA7RESCNT 0x0044
-#define RESCNT	0x0050
 
 #define APMU	0xe6150000
 #define CA15WUPCR 0x2010
@@ -39,20 +38,16 @@ static struct {
 	unsigned int cabar;
 	unsigned int carescnt;
 	unsigned int carescnt_magic;
-	unsigned int rescnt_bit;
-	unsigned int use_count;
 } r8a7790_clst[R8A7790_CLST_NR] = {
 	[R8A7790_CLST_CA15] = {
 		.cabar = CA15BAR,
 		.carescnt = CA15RESCNT,
 		.carescnt_magic = 0xa5a50000,
-		.rescnt_bit = 1,
 	},
 	[R8A7790_CLST_CA7] = {
 		.cabar = CA7BAR,
 		.carescnt = CA7RESCNT,
 		.carescnt_magic = 0x5a5a0000,
-		.rescnt_bit = 0,
 	},
 };
 
@@ -71,12 +66,6 @@ static void r8a7790_deassert_reset(unsigned int cpu)
 	writel_relaxed(bar, p + r8a7790_clst[clst_id].cabar);
 	writel_relaxed(bar | 0x10, p + r8a7790_clst[clst_id].cabar);
 
-	/* enable clocks for cluster */
-	if (r8a7790_clst[clst_id].use_count++ == 0) {
-		mask = 1 << r8a7790_clst[clst_id].rescnt_bit;
-		writel_relaxed(readl_relaxed(p + RESCNT) & ~mask, p + RESCNT);
-	}
-
 	/* enable per-core clocks */
 	mask = BIT(3 - r8a7790_cpu_id(cpu));
 	magic = r8a7790_clst[clst_id].carescnt_magic;
@@ -100,15 +89,6 @@ static void r8a7790_assert_reset(unsigned int cpu)
 	carescnt = p + r8a7790_clst[clst_id].carescnt;
 	writel_relaxed((readl_relaxed(carescnt) | mask) | magic, carescnt);
 
-	/* disable clocks for cluster */
-	if (r8a7790_clst[clst_id].use_count == 1) {
-		mask = 1 << r8a7790_clst[clst_id].rescnt_bit;
-		writel_relaxed(readl_relaxed(p + RESCNT) | mask, p + RESCNT);
-	}
-
-	if (r8a7790_clst[clst_id].use_count > 0)
-		r8a7790_clst[clst_id].use_count--;
-
 	iounmap(p);
 }
 
@@ -145,8 +125,6 @@ static void __init r8a7790_smp_prepare_cpus(unsigned int max_cpus)
 		r8a7790_assert_reset(k);
 		r8a7790_power_on(k);
 	}
-
-	r8a7790_deassert_reset(0);
 }
 
 static int __cpuinit r8a7790_boot_secondary(unsigned int cpu,
-- 
1.8.3.2



From shinya.kuribayashi.px at renesas.com  Thu Jul 11 05:52:05 2013
From: shinya.kuribayashi.px at renesas.com (Shinya Kuribayashi)
Date: Thu, 11 Jul 2013 18:52:05 +0900
Subject: [PATCH 2/4] ARM: shmobile: smp-r8a7790: rename s/carescnt/rescnt/g
In-Reply-To: <51DE7FF4.5050800@renesas.com>
References: <20130710104151.20742.56398.sendpatchset@w520>
 <51DE7FF4.5050800@renesas.com>
Message-ID: <51DE8045.5070206@renesas.com>

I don't have strong opinion on this one.  Leave it to you.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
---
 arch/arm/mach-shmobile/smp-r8a7790.c | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-shmobile/smp-r8a7790.c b/arch/arm/mach-shmobile/smp-r8a7790.c
index 1ab4c04..e8c2636 100644
--- a/arch/arm/mach-shmobile/smp-r8a7790.c
+++ b/arch/arm/mach-shmobile/smp-r8a7790.c
@@ -36,18 +36,18 @@ enum { R8A7790_CLST_CA15, R8A7790_CLST_CA7, R8A7790_CLST_NR };
 
 static struct {
 	unsigned int cabar;
-	unsigned int carescnt;
-	unsigned int carescnt_magic;
+	unsigned int rescnt;
+	unsigned int rescnt_magic;
 } r8a7790_clst[R8A7790_CLST_NR] = {
 	[R8A7790_CLST_CA15] = {
 		.cabar = CA15BAR,
-		.carescnt = CA15RESCNT,
-		.carescnt_magic = 0xa5a50000,
+		.rescnt = CA15RESCNT,
+		.rescnt_magic = 0xa5a50000,
 	},
 	[R8A7790_CLST_CA7] = {
 		.cabar = CA7BAR,
-		.carescnt = CA7RESCNT,
-		.carescnt_magic = 0x5a5a0000,
+		.rescnt = CA7RESCNT,
+		.rescnt_magic = 0x5a5a0000,
 	},
 };
 
@@ -56,7 +56,7 @@ static struct {
 
 static void r8a7790_deassert_reset(unsigned int cpu)
 {
-	void __iomem *p, *carescnt;
+	void __iomem *p, *rescnt;
 	u32 bar, mask, magic;
 	unsigned int clst_id = r8a7790_clst_id(cpu);
 
@@ -68,16 +68,16 @@ static void r8a7790_deassert_reset(unsigned int cpu)
 
 	/* enable per-core clocks */
 	mask = BIT(3 - r8a7790_cpu_id(cpu));
-	magic = r8a7790_clst[clst_id].carescnt_magic;
-	carescnt = p + r8a7790_clst[clst_id].carescnt;
-	writel_relaxed((readl_relaxed(carescnt) & ~mask) | magic, carescnt);
+	magic = r8a7790_clst[clst_id].rescnt_magic;
+	rescnt = p + r8a7790_clst[clst_id].rescnt;
+	writel_relaxed((readl_relaxed(rescnt) & ~mask) | magic, rescnt);
 
 	iounmap(p);
 }
 
 static void r8a7790_assert_reset(unsigned int cpu)
 {
-	void __iomem *p, *carescnt;
+	void __iomem *p, *rescnt;
 	u32 mask, magic;
 	unsigned int clst_id = r8a7790_clst_id(cpu);
 
@@ -85,9 +85,9 @@ static void r8a7790_assert_reset(unsigned int cpu)
 
 	/* disable per-core clocks */
 	mask = BIT(3 - r8a7790_cpu_id(cpu));
-	magic = r8a7790_clst[clst_id].carescnt_magic;
-	carescnt = p + r8a7790_clst[clst_id].carescnt;
-	writel_relaxed((readl_relaxed(carescnt) | mask) | magic, carescnt);
+	magic = r8a7790_clst[clst_id].rescnt_magic;
+	rescnt = p + r8a7790_clst[clst_id].rescnt;
+	writel_relaxed((readl_relaxed(rescnt) | mask) | magic, rescnt);
 
 	iounmap(p);
 }
-- 
1.8.3.2



From shinya.kuribayashi.px at renesas.com  Thu Jul 11 05:52:32 2013
From: shinya.kuribayashi.px at renesas.com (Shinya Kuribayashi)
Date: Thu, 11 Jul 2013 18:52:32 +0900
Subject: [PATCH 3/4] ARM: shmobile: smp-r8a7790: rename s/cabar/bar/g as well
In-Reply-To: <51DE7FF4.5050800@renesas.com>
References: <20130710104151.20742.56398.sendpatchset@w520>
 <51DE7FF4.5050800@renesas.com>
Message-ID: <51DE8060.5010400@renesas.com>

I don't have strong opinion on this one, either  Leave it to you.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
---
 arch/arm/mach-shmobile/smp-r8a7790.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-shmobile/smp-r8a7790.c b/arch/arm/mach-shmobile/smp-r8a7790.c
index e8c2636..1448e387 100644
--- a/arch/arm/mach-shmobile/smp-r8a7790.c
+++ b/arch/arm/mach-shmobile/smp-r8a7790.c
@@ -35,17 +35,17 @@
 enum { R8A7790_CLST_CA15, R8A7790_CLST_CA7, R8A7790_CLST_NR };
 
 static struct {
-	unsigned int cabar;
+	unsigned int bar;
 	unsigned int rescnt;
 	unsigned int rescnt_magic;
 } r8a7790_clst[R8A7790_CLST_NR] = {
 	[R8A7790_CLST_CA15] = {
-		.cabar = CA15BAR,
+		.bar = CA15BAR,
 		.rescnt = CA15RESCNT,
 		.rescnt_magic = 0xa5a50000,
 	},
 	[R8A7790_CLST_CA7] = {
-		.cabar = CA7BAR,
+		.bar = CA7BAR,
 		.rescnt = CA7RESCNT,
 		.rescnt_magic = 0x5a5a0000,
 	},
@@ -63,8 +63,8 @@ static void r8a7790_deassert_reset(unsigned int cpu)
 	/* setup reset vectors */
 	p = ioremap_nocache(RST, 0x63);
 	bar = (MERAM >> 8) & 0xfffffc00;
-	writel_relaxed(bar, p + r8a7790_clst[clst_id].cabar);
-	writel_relaxed(bar | 0x10, p + r8a7790_clst[clst_id].cabar);
+	writel_relaxed(bar, p + r8a7790_clst[clst_id].bar);
+	writel_relaxed(bar | 0x10, p + r8a7790_clst[clst_id].bar);
 
 	/* enable per-core clocks */
 	mask = BIT(3 - r8a7790_cpu_id(cpu));
-- 
1.8.3.2



From shinya.kuribayashi.px at renesas.com  Thu Jul 11 05:52:57 2013
From: shinya.kuribayashi.px at renesas.com (Shinya Kuribayashi)
Date: Thu, 11 Jul 2013 18:52:57 +0900
Subject: [PATCH 4/4] ARM: shmobile: smp-r8a7790: power up a CPU core at
 .smp_boot_secondary stage
In-Reply-To: <51DE7FF4.5050800@renesas.com>
References: <20130710104151.20742.56398.sendpatchset@w520>
 <51DE7FF4.5050800@renesas.com>
Message-ID: <51DE8079.6000001@renesas.com>

With the CPU hotplug support in mind, we should not let oneline CPU cores
get powered on at .smp_prepare_cpus stage _just_ _once_, but should power
up a requested CPU core one by one, when .smp_boot_secondary is processed.

Otherwise, the power supply to CPU cores can never be on again after
resume or cpu_up request via CPU hotplug.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
---
 arch/arm/mach-shmobile/smp-r8a7790.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-shmobile/smp-r8a7790.c b/arch/arm/mach-shmobile/smp-r8a7790.c
index 1448e387..6d23c52 100644
--- a/arch/arm/mach-shmobile/smp-r8a7790.c
+++ b/arch/arm/mach-shmobile/smp-r8a7790.c
@@ -120,11 +120,9 @@ static void __init r8a7790_smp_prepare_cpus(unsigned int max_cpus)
 	memcpy_toio(p, shmobile_boot_vector, 16);
 	iounmap(p);
 
-	/* keep secondary CPU cores in reset, but powered on */
-	for (k = 1; k < 8; k++) {
+	/* keep secondary CPU cores in reset */
+	for (k = 1; k < 8; k++)
 		r8a7790_assert_reset(k);
-		r8a7790_power_on(k);
-	}
 }
 
 static int __cpuinit r8a7790_boot_secondary(unsigned int cpu,
@@ -134,6 +132,7 @@ static int __cpuinit r8a7790_boot_secondary(unsigned int cpu,
 	if (r8a7790_clst_id(cpu) != r8a7790_clst_id(0))
 		return -ENOTSUPP;
 
+	r8a7790_power_on(cpu);
 	r8a7790_deassert_reset(cpu);
 	return 0;
 }
-- 
1.8.3.2



From grygorii.strashko at ti.com  Thu Jul 11 05:59:31 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Thu, 11 Jul 2013 12:59:31 +0300
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51DE780C.2070701@ti.com>
References: <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <87mwpuakod.fsf@linaro.org>
 <20130710142633.GV5523@atomide.com> <20130710160704.GH18966@arwen.pp.htv.fi>
 <51DE780C.2070701@ti.com>
Message-ID: <51DE8203.7040408@ti.com>

On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
> On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
>> how about something like below ? It makes omap_device/hwmod and
>> pm_runtime agree on the initial state of the device and will prevent
>> ->runtime_resume() from being called on first pm_runtime_get*() done
>> during probe.
>>
>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>
> I tried something similar [1] but what I found is that the serial
> runtime resume was called despite it being marked as active using
> pm_runtime_set_active().
>
> That seems to be because of the pm_runtime_set_autosuspend_delay()
> because we have the autosuspend_delay = -1
>
> -----
> static void update_autosuspend(struct device *dev, int old_delay, int old_use)
> {
>          int delay = dev->power.autosuspend_delay;
>
>          /* Should runtime suspend be prevented now? */
>          if (dev->power.use_autosuspend && delay < 0) {
>
>                  /* If it used to be allowed then prevent it. */
>                  if (!old_use || old_delay >= 0) {
>                          atomic_inc(&dev->power.usage_count);
>                          rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
It's strange - the check for status is inside rpm_resume()

if (dev->power.runtime_status == RPM_ACTIVE) {
		retval = 1;
		goto out;
	}

So, if status is set to RPM_ACTIVE before first call to:
  pm_runtime_use_autosuspend(&pdev->dev);
  pm_runtime_set_autosuspend_delay(&pdev->dev,
			omap_up_info->autosuspend_timeout);
-- or --
  pm_runtime_get*()
everything should be ok.

May be the problem is inside serial_omap_set_termios() where 
pm_runtime_get_sync is called before context is initialized.
probe:
  get - status is ACTIVE and serial resume is not called
  put - status is IDLE

set_termios
  get - status is IDLE and serial resume is called


>                  }
>          }
> -----
>
> So we end up with the same issue with serial resume being called before set_termios()
>
> [1]
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 5cc9287..c71d47d 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>          struct device_node *node = pdev->dev.of_node;
>          const char *oh_name;
>          int oh_cnt, i, ret = 0;
> +       bool device_active = false;
>
>          oh_cnt = of_property_count_strings(node, "ti,hwmods");
>          if (oh_cnt <= 0) {
> @@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>                          goto odbfd_exit1;
>                  }
>                  hwmods[i] = oh;
> +               if (oh->flags & HWMOD_INIT_NO_IDLE)
> +                       device_active = true;
> +
>          }
>
>          od = omap_device_alloc(pdev, hwmods, oh_cnt);
> @@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>
>          pdev->dev.pm_domain = &omap_device_pm_domain;
>
> +       if (device_active) {
> +               omap_device_enable(pdev);
> +               pm_runtime_set_active(&pdev->dev);
> +       }
> +
>   odbfd_exit1:
>          kfree(hwmods);
>   odbfd_exit:
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



From grygorii.strashko at ti.com  Thu Jul 11 05:59:49 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Thu, 11 Jul 2013 12:59:49 +0300
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <20130711063209.GZ5523@atomide.com>
References: <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <87mwpuakod.fsf@linaro.org>
 <20130710142633.GV5523@atomide.com> <20130710160704.GH18966@arwen.pp.htv.fi>
 <20130710161158.GA19716@arwen.pp.htv.fi> <20130711063209.GZ5523@atomide.com>
Message-ID: <51DE8215.5060306@ti.com>

Hi,

On 07/11/2013 09:32 AM, Tony Lindgren wrote:
> * Felipe Balbi <balbi at ti.com> [130710 09:18]:
>>
>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>> how about something like below ? It makes omap_device/hwmod and
>>> pm_runtime agree on the initial state of the device and will prevent
>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>> during probe.
>>>
>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>
>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>> Author: Felipe Balbi <balbi at ti.com>
>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>
>>>      arm: omap2plus: unidle devices which are about to probe
>>>
>>>      in order to make HWMOD and pm_runtime agree on the
>>>      initial state of the device, we will unidle the device
>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>      that the device is really active.
Don't think that it's good idea (
I've checked some driver's and think this patch will enable some devices 
unpredictably:
- hwspinlock
- mailbox
- iommu
- ipu
All above devices need to be enabled on demand only (no 
pm_runtime_get*() calls in probe). More over, some of them have very 
specific enabling sequence - like ipu).

May be Summan can say more on that.

>>>
>>>      By the time driver's probe() is reached, a call to
>>>      pm_runtime_get_sync() will not cause driver's
>>>      ->runtime_resume() method to be called at first, only
>>>      after a successful ->runtime_suspend().
>>>
>>>      Signed-off-by: Felipe Balbi <balbi at ti.com>
>>
>> btw, this is RFC, haven't tested at all.
>
> Yes it does not compile, then removing the extra ; at the end
> of the functions, it oopses with a NULL pointer exception.
>
> Regards,
>
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



From balbi at ti.com  Thu Jul 11 06:16:28 2013
From: balbi at ti.com (Felipe Balbi)
Date: Thu, 11 Jul 2013 13:16:28 +0300
Subject: [PATCH] arm: omap2plus: unidle devices which are about to probe
In-Reply-To: <20130711092612.GG23892@arwen.pp.htv.fi>
References: <20130711092612.GG23892@arwen.pp.htv.fi>
Message-ID: <1373537788-30413-1-git-send-email-balbi@ti.com>

in order to make HWMOD and pm_runtime agree on the
initial state of the device, we will unidle the device
and call pm_runtime_set_active() to tell pm_runtime
that the device is really active.

By the time driver's probe() is reached, a call to
pm_runtime_get_sync() will not cause driver's
->runtime_resume() method to be called at first, only
after a successful ->runtime_suspend().

Note that we must prevent pm_runtime transitions while
driver is probing otherwise drivers would be suspended
as soon as they call pm_runtime_use_autosuspend(). By
calling pm_runtime_forbid() before probe() and
pm_runtime_allow() after probe() we 'fix' that detail.

Note that this patch was inspired by PCI's pci_pm_init().

Signed-off-by: Felipe Balbi <balbi at ti.com>
---

boot tested on top of today's Linus master
6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
panda. Reached console prompt and, after setting a
proper autosuspend delay, consoles autosuspend just
fine.

It needs to be tested on other platforms.

ps: note that we also call pm_runtime_set_suspended(dev)
from our late_initcall() to disable devices so that pm_runtime
and HWMOD continue to aggree on device's state.

 arch/arm/mach-omap2/omap_device.c | 44 +++++++++++++++++++++++++++++++++++----
 1 file changed, 40 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..cb1fc1d 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -178,6 +178,26 @@ odbfd_exit:
 	return ret;
 }
 
+static void omap_device_pm_init(struct platform_device *pdev)
+{
+	omap_device_enable(pdev);
+	pm_runtime_forbid(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	device_enable_async_suspend(&pdev->dev);
+}
+
+static void omap_device_pm_allow(struct platform_device *pdev)
+{
+	pm_runtime_allow(&pdev->dev);
+}
+
+static void omap_device_pm_exit(struct platform_device *pdev)
+{
+	device_disable_async_suspend(&pdev->dev);
+	pm_runtime_set_suspended(&pdev->dev);
+	omap_device_idle(pdev);
+}
+
 static int _omap_device_notifier_call(struct notifier_block *nb,
 				      unsigned long event, void *dev)
 {
@@ -189,16 +209,31 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
 		if (pdev->archdata.od)
 			omap_device_delete(pdev->archdata.od);
 		break;
+	case BUS_NOTIFY_BIND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_init(pdev);
+		break;
+	case BUS_NOTIFY_BOUND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_allow(pdev);
+		break;
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_exit(pdev);
+		break;
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdev->dev.of_node)
 			omap_device_build_from_dt(pdev);
-		/* fall through */
+		break;
 	default:
-		od = to_omap_device(pdev);
-		if (od)
-			od->_driver_status = event;
+		/* nothing */
+		break;
 	}
 
+	od = to_omap_device(pdev);
+	if (od)
+		od->_driver_status = event;
+
 	return NOTIFY_DONE;
 }
 
@@ -855,6 +890,7 @@ static int __init omap_device_late_idle(struct device *dev, void *data)
 			dev_warn(dev, "%s: enabled but no driver.  Idling\n",
 				 __func__);
 			omap_device_idle(pdev);
+			pm_runtime_set_suspended(dev);
 		}
 	}
 
-- 
1.8.2.1



From tomasz.figa at gmail.com  Thu Jul 11 06:19:26 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 11 Jul 2013 12:19:26 +0200
Subject: [PATCH] clk: samsung: add set_rate and round_rate callbacks for
 pll45xx
In-Reply-To: <1373534869-12034-1-git-send-email-thomas.abraham@linaro.org>
References: <1373534869-12034-1-git-send-email-thomas.abraham@linaro.org>
Message-ID: <1395018.H3ijo3R2Tj@thinkpad>

Hi Thomas,

On Thursday 11 of July 2013 14:57:49 Thomas Abraham wrote:
> Add support for set_rate and round_rate callbacks for pll45xx pll. This
> allows configuring pll45xx to generate a desired clock output.
> 
> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
> ---
> 
> The set_rate and round_rate callbacks in this patch for pll45xx are handled
> slightly differently from the way it is done in the (not yet merged) patch
> series from Yadwinder
> (http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg19540.html
> )

I think this series should be considered as already merged. All the patches 
have been already acked and are just waiting to be picked up after 3.11-rc1 
gets released.

> 
> In this patch, the pll lookup table is kept as part of the pll configuration
> code itself, since the pll is just a hardware block which takes an input
> frequency and configuration values to genertate a output clock frequency.
> Given a set of inputs, a pll of a given type will generate the same output
> regardless of the SoC it is used in.

Are you sure about this? I've seen different sets of PMS(K) settings across 
different SoCs with the same PLL blocks.

> So instead of supplying the pll lookup
> table from per-soc clock driver code (as done in the Yadwinder's patch
> series), the pll lookup table can be coupled with the pll code itself,
> saving duplication of pll lookup table for every SoC the pll is used with.

Yes, that would be nice to have, but we already discussed this problem a lot 
and found out that this has to be specified on per-SoC basis.

>  drivers/clk/samsung/clk-pll.c |   88
> +++++++++++++++++++++++++++++++++++++++++ drivers/clk/samsung/clk-pll.h |  
> 15 +++++++
>  2 files changed, 103 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
> index 362f12d..4940936 100644
> --- a/drivers/clk/samsung/clk-pll.c
> +++ b/drivers/clk/samsung/clk-pll.c
> @@ -172,6 +172,8 @@ struct clk * __init samsung_clk_register_pll36xx(const
> char *name, * PLL45xx Clock Type
>   */
> 
> +#define PLL45XX_EN_MASK		(1 << 31)
> +#define PLL45XX_LOCK_MASK	(1 << 29)
>  #define PLL45XX_MDIV_MASK	(0x3FF)
>  #define PLL45XX_PDIV_MASK	(0x3F)
>  #define PLL45XX_SDIV_MASK	(0x7)
> @@ -187,6 +189,90 @@ struct samsung_clk_pll45xx {
> 
>  #define to_clk_pll45xx(_hw) container_of(_hw, struct samsung_clk_pll45xx,
> hw)
> 
> +/* a sorted table of freq supported by pll45xx with 24mhz parent clock */
> +static struct pll45xx_freq_lookup pll45xx_freq_lookup_24mhz[] = {
> +	PLL45XX_PMS(1000000000, 6, 250, 1),
> +	PLL45XX_PMS(800000000, 6, 200, 1),
> +	PLL45XX_PMS(500000000, 6, 250, 2),
> +	PLL45XX_PMS(400000000, 6, 200, 2),
> +	PLL45XX_PMS(200000000, 6, 200, 3),
> +};
> +
> +static int samsung_pll45xx_set_rate(struct clk_hw *hw, unsigned long rate,
> +					unsigned long prate)
> +{
> +	struct samsung_clk_pll45xx *pll = to_clk_pll45xx(hw);
> +	struct pll45xx_freq_lookup *f;
> +	unsigned long timeout, pll_con, cnt, idx;
> +
> +	/* select a lookup table based on parent clock frequency */
> +	switch (prate) {
> +	case 24000000:
> +		f = pll45xx_freq_lookup_24mhz;
> +		cnt = ARRAY_SIZE(pll45xx_freq_lookup_24mhz);
> +		break;

Do you really need to check the input frequency every time? I think you could 
just set up appropriate rate table in register function, like it is done in 
Yadwinder's patches.

> +	default:
> +		pr_err("%s: unsupported parent clock rate, failed to set rate",
> +					__func__);
> +		return -EINVAL;
> +	}
> +
> +	/* check if the requested freq is in the list of supported freq */
> +	for (idx = 0; idx < cnt; idx++, f++)
> +		if (f->target_freq == rate)
> +			break;

You don't have to check all the entries if you keep the PMS table sorted. You 
just have to look for first entry that has frequency less or equal to requested 
one.

> +
> +	if (idx == cnt) {
> +		pr_err("%s: unspported clock speed %ld requested\n",
> +				__func__, rate);
> +		return -EINVAL;
> +	}
> +
> +	/* first, disable the output of the pll */
> +	writel(readl(pll->con_reg) & ~PLL45XX_EN_MASK, (void *)pll->con_reg);
> +
> +	/* write the new pll configuration values */
> +	pll_con = (f->pdiv << PLL45XX_PDIV_SHIFT) |
> +			(f->mdiv << PLL45XX_MDIV_SHIFT) |
> +			(f->sdiv << PLL45XX_SDIV_SHIFT);
> +	writel(pll_con, (void *)pll->con_reg);
> +
> +	/* enable the pll and wait for it to stabilize */
> +	writel(pll_con | PLL45XX_EN_MASK, (void *)pll->con_reg);
> +	timeout = jiffies + msecs_to_jiffies(20);
> +	while (time_before(jiffies, timeout))
> +		if (readl(pll->con_reg) & PLL45XX_LOCK_MASK)
> +			return 0;
> +	return -EBUSY;
> +}
> +
> +static long samsung_pll45xx_round_rate(struct clk_hw *hw, unsigned long
> rate, +						unsigned long *prate)
> +{
> +	struct pll45xx_freq_lookup *f;
> +	unsigned long cnt;
> +
> +	/* select a lookup table based on parent clock frequency */
> +	switch (*prate) {
> +	case 24000000:
> +		f = pll45xx_freq_lookup_24mhz;
> +		cnt = ARRAY_SIZE(pll45xx_freq_lookup_24mhz);
> +		break;
> +	default:
> +		pr_err("%s: unsupported parent clock rate", __func__);
> +		return *prate;
> +	}

Again, PMS table can be set in register function and just used here.

> +	/* find the nearest possible clock output that can be supported */
> +	while (cnt-- > 0) {
> +		if (rate >= f->target_freq)
> +			return f->target_freq;
> +		f++;
> +	}
> +
> +	return (--f)->target_freq;
> +}
> +
>  static unsigned long samsung_pll45xx_recalc_rate(struct clk_hw *hw,
>  				unsigned long parent_rate)
>  {
> @@ -209,6 +295,8 @@ static unsigned long samsung_pll45xx_recalc_rate(struct
> clk_hw *hw, }
> 
>  static const struct clk_ops samsung_pll45xx_clk_ops = {
> +	.set_rate = samsung_pll45xx_set_rate,
> +	.round_rate = samsung_pll45xx_round_rate,
>  	.recalc_rate = samsung_pll45xx_recalc_rate,
>  };
> 
> diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
> index f33786e..fb687ec 100644
> --- a/drivers/clk/samsung/clk-pll.h
> +++ b/drivers/clk/samsung/clk-pll.h
> @@ -18,6 +18,21 @@ enum pll45xx_type {
>  	pll_4508
>  };
> 
> +struct pll45xx_freq_lookup {
> +	unsigned long	target_freq;
> +	unsigned long	pdiv;
> +	unsigned long	mdiv;
> +	unsigned long	sdiv;
> +};
> +
> +#define PLL45XX_PMS(f, p, m, s)		\
> +	{					\
> +		.target_freq	= f,		\
> +		.pdiv		= p,		\
> +		.mdiv		= m,		\
> +		.sdiv		= s,		\
> +	}
> +
>  enum pll46xx_type {
>  	pll_4600,
>  	pll_4650,

Basically, I would prefer the way introduced by Yadwinder's and Vikas' patches 
to be used. We already discussed all the aspects during all the 7 versions of 
those patches and decided to go with that solution, so for the case of 
consistency, same should be used for remaining PLLs.

Best regards,
Tomasz



From tomasz.figa at gmail.com  Thu Jul 11 06:23:13 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 11 Jul 2013 12:23:13 +0200
Subject: [PATCH] gpio: samsung: more generic pinctrl exclude ifdef
In-Reply-To: <201307090212.31422.heiko@sntech.de>
References: <201307090212.31422.heiko@sntech.de>
Message-ID: <2059841.SxvZmAMDu5@thinkpad>

Hi Heiko,

On Tuesday 09 of July 2013 02:12:31 Heiko St?bner wrote:
> The exclude check should run any time when either the PINCTRL_SAMSUNG
> or PINCTRL_EXYNOS5440 are selected.
> 
> As the real check for the presence of a pinctrl driver is done via a
> dt lookup it's not necessary to specifiy every pinctrl option in the
> ifdef individually.
> 
> This fixes a breakage on s3c2416, when both the legacy and
> dt boards are selected.
> 
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> ---
> Extracted from Tomasz pinctrl series, as it fixes a bug in the current
> 3.11 development.
> 
>  drivers/gpio/gpio-samsung.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
> index a1392f4..ceb7971 100644
> --- a/drivers/gpio/gpio-samsung.c
> +++ b/drivers/gpio/gpio-samsung.c
> @@ -2949,7 +2949,7 @@ static __init int samsung_gpiolib_init(void)
>  	int i, nr_chips;
>  	int group = 0;
> 
> -#if defined(CONFIG_PINCTRL_EXYNOS) || defined(CONFIG_PINCTRL_EXYNOS5440)
> +#if defined(CONFIG_PINCTRL_SAMSUNG) || defined(CONFIG_PINCTRL_EXYNOS5440)
>  	/*
>  	* This gpio driver includes support for device tree support and there
>  	* are platforms using it. In order to maintain compatibility with those

I think we can simplify this even more now, since when booting with DT pinctrl 
driver is always used. What about just removing the whole check, including the 
ifdef and looking for compatible nodes and replacing them with:

	if (of_have_populated_dt())
		return -ENODEV;

Best regards,
Tomasz


From rogerq at ti.com  Thu Jul 11 06:24:19 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 11 Jul 2013 13:24:19 +0300
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51DC1B47.7070504@denx.de>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de>
Message-ID: <51DE87D3.5030600@ti.com>

On 07/09/2013 05:16 PM, Stefan Roese wrote:
> Hi Roger,
> 
>>
>> I have been too lazy to setup NFS :). But I will give it a shot soon to see what's going
>> wrong.
> 
> Really appreciated. :) Please let me know if you need anything else from
> me to reproduce this issue.

Stefan,

I tried it out today and it worked 5/5 times. I used a bare bones debian root filesystem for
the NFS root.

Could it be possible that the boot scripts on your filesystem are somehow shutting down
the ethernet interface? Might be worth checking on a fresh filesystem.

My u-boot script is below and boot log is attached.

setenv bootargs console=ttyO2,115200n8 root=/dev/nfs rw nfsroot=192.168.2.1:/srv/nfsroot/ ip=192.168.2.2 rootwait

setenv usbethaddr A6:66:4D:B0:69:04
setenv netmask 255.255.255.0
setenv ipaddr 192.168.2.2
setenv serverip 192.168.2.1

usb start

tftpboot 0x825f0000 omap3-beagle.dtb
tftpboot 0x80300000 uImage
set fdt_high 0xffffffff

bootm 0x80300000 - 0x825f0000

cheers,
-roger

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nfs-boot.log
Type: text/x-log
Size: 19655 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130711/dc853f1d/attachment-0001.bin>

From tomasz.figa at gmail.com  Thu Jul 11 06:24:13 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 11 Jul 2013 12:24:13 +0200
Subject: [PATCH v2 Resend 2/3] of/documentation: Update G2D documentation
In-Reply-To: <1373351355-27444-1-git-send-email-sachin.kamat@linaro.org>
References: <1373351355-27444-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1748068.8mvO9B4JjP@thinkpad>

Hi Sachin,

On Tuesday 09 of July 2013 11:59:15 Sachin Kamat wrote:
> Exynos5250 G2D IP requires only the gate clock. Update the
> binding documentation accordingly.
> 
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> Cc: Inki Dae <inki.dae at samsung.com>
> ---
> Updated the description of clock-names as suggested by Tomasz Figa.
> ---
>  .../devicetree/bindings/gpu/samsung-g2d.txt        |    7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
> b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt index
> 3f454ff..c4f358d 100644
> --- a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
> +++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
> @@ -11,8 +11,11 @@ Required properties:
> 
>    - interrupts : G2D interrupt number to the CPU.
>    - clocks : from common clock binding: handle to G2D clocks.
> -  - clock-names : from common clock binding: must contain "sclk_fimg2d" and
> -		  "fimg2d", corresponding to entries in the clocks property.
> +  - clock-names : names of clocks listed in clocks property, in the same
> +		  order, depending on SoC type:
> +		  - for S5PV210 and Exynos4 based SoCs: "fimg2d" and
> +		    "sclk_fimg2d"
> +		  - for Exynos5250 SoC: "fimg2d".

This looks fine for me now.

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From tomasz.figa at gmail.com  Thu Jul 11 06:43:22 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 11 Jul 2013 12:43:22 +0200
Subject: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on
 Exynos5420
In-Reply-To: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
Message-ID: <29860116.IF545KsGYb@thinkpad>

Hi Padmavathi,

On Thursday 11 of July 2013 12:38:24 Padmavathi Venna wrote:
> Exynos5420 added support for I2S TDM mode. For this, there are some
> register changes in the I2S controller. This patch adds the relevant
> register changes to support I2S in normal mode. This patch adds a
> quirk for TDM mode and if TDM mode is present all the relevent changes
> will be applied.
> 
> Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
> [abrestic: style cleanup and documentation]
> Signed-off-by: Andrew Bresticker <abrestic at chromium.org>
> Reviewed-on: https://gerrit-int.chromium.org/37840
> Reviewed-by: Simon Glass <sjg at google.com>
> ---
>  .../devicetree/bindings/sound/samsung-i2s.txt      |    2 +
>  include/linux/platform_data/asoc-s3c.h             |    1 +
>  sound/soc/samsung/i2s-regs.h                       |   51 ++++++---
>  sound/soc/samsung/i2s.c                            |  117
> ++++++++++++++++---- 4 files changed, 132 insertions(+), 39 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
> b/Documentation/devicetree/bindings/sound/samsung-i2s.txt index
> 025e66b..b8593d5 100644
> --- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
> +++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
> @@ -28,6 +28,8 @@ Optional SoC Specific Properties:
>    enabled or disabled based on need.
>  - samsung,supports-secdai:If I2S block has a secondary FIFO and internal
> DMA, then this flag is enabled.
> +- samsung,supports-tdm: If the I2S controller supports TDM, then this flag
> +  must be enabled.

I think this should be rather handled by a different compatible value, not a 
flag. Also a word about what this TDM mode is would be nice.

Best regards,
Tomasz

>  - samsung,idma-addr: Internal DMA register base address of the audio
>    sub system(used in secondary sound source).
>  - pinctrl-0: Should specify pin control groups used for this controller.
> diff --git a/include/linux/platform_data/asoc-s3c.h
> b/include/linux/platform_data/asoc-s3c.h index 8827259..9efc04d 100644
> --- a/include/linux/platform_data/asoc-s3c.h
> +++ b/include/linux/platform_data/asoc-s3c.h
> @@ -36,6 +36,7 @@ struct samsung_i2s {
>   */
>  #define QUIRK_NO_MUXPSR		(1 << 2)
>  #define QUIRK_NEED_RSTCLR	(1 << 3)
> +#define QUIRK_SUPPORTS_TDM	(1 << 4)
>  	/* Quirks of the I2S controller */
>  	u32 quirks;
>  	dma_addr_t idma_addr;
> diff --git a/sound/soc/samsung/i2s-regs.h b/sound/soc/samsung/i2s-regs.h
> index c0e6d9a..821a502 100644
> --- a/sound/soc/samsung/i2s-regs.h
> +++ b/sound/soc/samsung/i2s-regs.h
> @@ -31,6 +31,10 @@
>  #define I2SLVL1ADDR	0x34
>  #define I2SLVL2ADDR	0x38
>  #define I2SLVL3ADDR	0x3c
> +#define I2SSTR1		0x40
> +#define I2SVER		0x44
> +#define I2SFIC2		0x48
> +#define I2STDM		0x4c
> 
>  #define CON_RSTCLR		(1 << 31)
>  #define CON_FRXOFSTATUS		(1 << 26)
> @@ -95,24 +99,39 @@
>  #define MOD_RXONLY		(1 << 8)
>  #define MOD_TXRX		(2 << 8)
>  #define MOD_MASK		(3 << 8)
> -#define MOD_LR_LLOW		(0 << 7)
> -#define MOD_LR_RLOW		(1 << 7)
> -#define MOD_SDF_IIS		(0 << 5)
> -#define MOD_SDF_MSB		(1 << 5)
> -#define MOD_SDF_LSB		(2 << 5)
> -#define MOD_SDF_MASK		(3 << 5)
> -#define MOD_RCLK_256FS		(0 << 3)
> -#define MOD_RCLK_512FS		(1 << 3)
> -#define MOD_RCLK_384FS		(2 << 3)
> -#define MOD_RCLK_768FS		(3 << 3)
> -#define MOD_RCLK_MASK		(3 << 3)
> -#define MOD_BCLK_32FS		(0 << 1)
> -#define MOD_BCLK_48FS		(1 << 1)
> -#define MOD_BCLK_16FS		(2 << 1)
> -#define MOD_BCLK_24FS		(3 << 1)
> -#define MOD_BCLK_MASK		(3 << 1)
> +#define MOD_LRP_SHIFT		7
> +#define MOD_LR_LLOW		0
> +#define MOD_LR_RLOW		1
> +#define MOD_SDF_SHIFT		5
> +#define MOD_SDF_IIS		0
> +#define MOD_SDF_MSB		1
> +#define MOD_SDF_LSB		2
> +#define MOD_SDF_MASK		3
> +#define MOD_RCLK_SHIFT		3
> +#define MOD_RCLK_256FS		0
> +#define MOD_RCLK_512FS		1
> +#define MOD_RCLK_384FS		2
> +#define MOD_RCLK_768FS		3
> +#define MOD_RCLK_MASK		3
> +#define MOD_BCLK_SHIFT		1
> +#define MOD_BCLK_32FS		0
> +#define MOD_BCLK_48FS		1
> +#define MOD_BCLK_16FS		2
> +#define MOD_BCLK_24FS		3
> +#define MOD_BCLK_MASK		3
>  #define MOD_8BIT		(1 << 0)
> 
> +#define EXYNOS5420_MOD_LRP_SHIFT	15
> +#define EXYNOS5420_MOD_SDF_SHIFT	6
> +#define EXYNOS5420_MOD_RCLK_SHIFT	4
> +#define EXYNOS5420_MOD_BCLK_SHIFT	0
> +#define EXYNOS5420_MOD_BCLK_64FS	4
> +#define EXYNOS5420_MOD_BCLK_96FS	5
> +#define EXYNOS5420_MOD_BCLK_128FS	6
> +#define EXYNOS5420_MOD_BCLK_192FS	7
> +#define EXYNOS5420_MOD_BCLK_256FS	8
> +#define EXYNOS5420_MOD_BCLK_MASK	0xf
> +
>  #define MOD_CDCLKCON		(1 << 12)
> 
>  #define PSR_PSREN		(1 << 15)
> diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
> index 3fcf8d7..398f8db 100644
> --- a/sound/soc/samsung/i2s.c
> +++ b/sound/soc/samsung/i2s.c
> @@ -198,7 +198,13 @@ static inline bool is_manager(struct i2s_dai *i2s)
>  /* Read RCLK of I2S (in multiples of LRCLK) */
>  static inline unsigned get_rfs(struct i2s_dai *i2s)
>  {
> -	u32 rfs = (readl(i2s->addr + I2SMOD) >> 3) & 0x3;
> +	u32 rfs;
> +
> +	if (i2s->quirks & QUIRK_SUPPORTS_TDM)
> +		rfs = readl(i2s->addr + I2SMOD) >> EXYNOS5420_MOD_RCLK_SHIFT;
> +	else
> +		rfs = readl(i2s->addr + I2SMOD) >> MOD_RCLK_SHIFT;
> +	rfs &= MOD_RCLK_MASK;
> 
>  	switch (rfs) {
>  	case 3:	return 768;
> @@ -212,21 +218,26 @@ static inline unsigned get_rfs(struct i2s_dai *i2s)
>  static inline void set_rfs(struct i2s_dai *i2s, unsigned rfs)
>  {
>  	u32 mod = readl(i2s->addr + I2SMOD);
> +	int rfs_shift;
> 
> -	mod &= ~MOD_RCLK_MASK;
> +	if (i2s->quirks & QUIRK_SUPPORTS_TDM)
> +		rfs_shift = EXYNOS5420_MOD_RCLK_SHIFT;
> +	else
> +		rfs_shift = MOD_RCLK_SHIFT;
> +	mod &= ~(MOD_RCLK_MASK << rfs_shift);
> 
>  	switch (rfs) {
>  	case 768:
> -		mod |= MOD_RCLK_768FS;
> +		mod |= (MOD_RCLK_768FS << rfs_shift);
>  		break;
>  	case 512:
> -		mod |= MOD_RCLK_512FS;
> +		mod |= (MOD_RCLK_512FS << rfs_shift);
>  		break;
>  	case 384:
> -		mod |= MOD_RCLK_384FS;
> +		mod |= (MOD_RCLK_384FS << rfs_shift);
>  		break;
>  	default:
> -		mod |= MOD_RCLK_256FS;
> +		mod |= (MOD_RCLK_256FS << rfs_shift);
>  		break;
>  	}
> 
> @@ -236,9 +247,22 @@ static inline void set_rfs(struct i2s_dai *i2s,
> unsigned rfs) /* Read Bit-Clock of I2S (in multiples of LRCLK) */
>  static inline unsigned get_bfs(struct i2s_dai *i2s)
>  {
> -	u32 bfs = (readl(i2s->addr + I2SMOD) >> 1) & 0x3;
> +	u32 bfs;
> +
> +	if (i2s->quirks & QUIRK_SUPPORTS_TDM) {
> +		bfs = readl(i2s->addr + I2SMOD) >> EXYNOS5420_MOD_BCLK_SHIFT;
> +		bfs &= EXYNOS5420_MOD_BCLK_MASK;
> +	} else {
> +		bfs = readl(i2s->addr + I2SMOD) >> MOD_BCLK_SHIFT;
> +		bfs &= MOD_BCLK_MASK;
> +	}
> 
>  	switch (bfs) {
> +	case 8: return 256;
> +	case 7: return 192;
> +	case 6: return 128;
> +	case 5: return 96;
> +	case 4: return 64;
>  	case 3: return 24;
>  	case 2: return 16;
>  	case 1:	return 48;
> @@ -250,21 +274,50 @@ static inline unsigned get_bfs(struct i2s_dai *i2s)
>  static inline void set_bfs(struct i2s_dai *i2s, unsigned bfs)
>  {
>  	u32 mod = readl(i2s->addr + I2SMOD);
> +	int bfs_shift;
> +	int tdm = i2s->quirks & QUIRK_SUPPORTS_TDM;
> 
> -	mod &= ~MOD_BCLK_MASK;
> +	if (tdm) {
> +		bfs_shift = EXYNOS5420_MOD_BCLK_SHIFT;
> +		mod &= ~(EXYNOS5420_MOD_BCLK_MASK << bfs_shift);
> +	} else {
> +		bfs_shift = MOD_BCLK_SHIFT;
> +		mod &= ~(MOD_BCLK_MASK << bfs_shift);
> +	}
> +
> +	/* Non-TDM I2S controllers do not support BCLK > 48 * FS */
> +	if (!tdm && bfs > 48) {
> +		dev_err(&i2s->pdev->dev, "Unsupported BCLK divider\n");
> +		return;
> +	}
> 
>  	switch (bfs) {
>  	case 48:
> -		mod |= MOD_BCLK_48FS;
> +		mod |= (MOD_BCLK_48FS << bfs_shift);
>  		break;
>  	case 32:
> -		mod |= MOD_BCLK_32FS;
> +		mod |= (MOD_BCLK_32FS << bfs_shift);
>  		break;
>  	case 24:
> -		mod |= MOD_BCLK_24FS;
> +		mod |= (MOD_BCLK_24FS << bfs_shift);
>  		break;
>  	case 16:
> -		mod |= MOD_BCLK_16FS;
> +		mod |= (MOD_BCLK_16FS << bfs_shift);
> +		break;
> +	case 64:
> +		mod |= (EXYNOS5420_MOD_BCLK_64FS << bfs_shift);
> +		break;
> +	case 96:
> +		mod |= (EXYNOS5420_MOD_BCLK_96FS << bfs_shift);
> +		break;
> +	case 128:
> +		mod |= (EXYNOS5420_MOD_BCLK_128FS << bfs_shift);
> +		break;
> +	case 192:
> +		mod |= (EXYNOS5420_MOD_BCLK_192FS << bfs_shift);
> +		break;
> +	case 256:
> +		mod |= (EXYNOS5420_MOD_BCLK_256FS << bfs_shift);
>  		break;
>  	default:
>  		dev_err(&i2s->pdev->dev, "Wrong BCLK Divider!\n");
> @@ -492,19 +545,31 @@ static int i2s_set_fmt(struct snd_soc_dai *dai,
>  	struct i2s_dai *i2s = to_info(dai);
>  	u32 mod = readl(i2s->addr + I2SMOD);
>  	u32 tmp = 0;
> +	int lrp_shift, sdf_shift, sdf_mask, lrp_rlow;
> +
> +	if (i2s->quirks & QUIRK_SUPPORTS_TDM) {
> +		lrp_shift = EXYNOS5420_MOD_LRP_SHIFT;
> +		sdf_shift = EXYNOS5420_MOD_SDF_SHIFT;
> +	} else {
> +		lrp_shift = MOD_LRP_SHIFT;
> +		sdf_shift = MOD_SDF_SHIFT;
> +	}
> +
> +	sdf_mask = MOD_SDF_MASK << sdf_shift;
> +	lrp_rlow = MOD_LR_RLOW << lrp_shift;
> 
>  	/* Format is priority */
>  	switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
>  	case SND_SOC_DAIFMT_RIGHT_J:
> -		tmp |= MOD_LR_RLOW;
> -		tmp |= MOD_SDF_MSB;
> +		tmp |= lrp_rlow;
> +		tmp |= (MOD_SDF_MSB << sdf_shift);
>  		break;
>  	case SND_SOC_DAIFMT_LEFT_J:
> -		tmp |= MOD_LR_RLOW;
> -		tmp |= MOD_SDF_LSB;
> +		tmp |= lrp_rlow;
> +		tmp |= (MOD_SDF_LSB << sdf_shift);
>  		break;
>  	case SND_SOC_DAIFMT_I2S:
> -		tmp |= MOD_SDF_IIS;
> +		tmp |= (MOD_SDF_IIS << sdf_shift);
>  		break;
>  	default:
>  		dev_err(&i2s->pdev->dev, "Format not supported\n");
> @@ -519,10 +584,10 @@ static int i2s_set_fmt(struct snd_soc_dai *dai,
>  	case SND_SOC_DAIFMT_NB_NF:
>  		break;
>  	case SND_SOC_DAIFMT_NB_IF:
> -		if (tmp & MOD_LR_RLOW)
> -			tmp &= ~MOD_LR_RLOW;
> +		if (tmp & lrp_rlow)
> +			tmp &= ~lrp_rlow;
>  		else
> -			tmp |= MOD_LR_RLOW;
> +			tmp |= lrp_rlow;
>  		break;
>  	default:
>  		dev_err(&i2s->pdev->dev, "Polarity not supported\n");
> @@ -544,15 +609,18 @@ static int i2s_set_fmt(struct snd_soc_dai *dai,
>  		return -EINVAL;
>  	}
> 
> +	/*
> +	 * Don't change the I2S mode if any controller is active on this
> +	 * channel.
> +	 */
>  	if (any_active(i2s) &&
> -			((mod & (MOD_SDF_MASK | MOD_LR_RLOW
> -				| MOD_SLAVE)) != tmp)) {
> +	    ((mod & (sdf_mask | lrp_rlow | MOD_SLAVE)) != tmp)) {
>  		dev_err(&i2s->pdev->dev,
>  				"%s:%d Other DAI busy\n", __func__, __LINE__);
>  		return -EAGAIN;
>  	}
> 
> -	mod &= ~(MOD_SDF_MASK | MOD_LR_RLOW | MOD_SLAVE);
> +	mod &= ~(sdf_mask | lrp_rlow | MOD_SLAVE);
>  	mod |= tmp;
>  	writel(mod, i2s->addr + I2SMOD);
> 
> @@ -1170,6 +1238,9 @@ static int samsung_i2s_probe(struct platform_device
> *pdev) if (of_find_property(np, "samsung,supports-rstclr", NULL))
>  			quirks |= QUIRK_NEED_RSTCLR;
> 
> +		if (of_find_property(np, "samsung,supports-tdm", NULL))
> +			quirks |= QUIRK_SUPPORTS_TDM;
> +
>  		if (of_property_read_u32(np, "samsung,idma-addr",
>  					 &idma_addr)) {
>  			if (quirks & QUIRK_SEC_DAI) {


From yadi.brar01 at gmail.com  Thu Jul 11 06:44:26 2013
From: yadi.brar01 at gmail.com (Yadwinder Singh Brar)
Date: Thu, 11 Jul 2013 16:14:26 +0530
Subject: [PATCH] clk: samsung: add set_rate and round_rate callbacks for
 pll45xx
In-Reply-To: <1373534869-12034-1-git-send-email-thomas.abraham@linaro.org>
References: <1373534869-12034-1-git-send-email-thomas.abraham@linaro.org>
Message-ID: <CAKew6eV0QP31gJNB2waeSRB5DN5Vs+mXO5bwaD5TiHYZvrANQA@mail.gmail.com>

Hi Thomas,

On Thu, Jul 11, 2013 at 2:57 PM, Thomas Abraham
<thomas.abraham at linaro.org> wrote:
> Add support for set_rate and round_rate callbacks for pll45xx pll. This allows
> configuring pll45xx to generate a desired clock output.
>
> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
> ---
>
> The set_rate and round_rate callbacks in this patch for pll45xx are handled
> slightly differently from the way it is done in the (not yet merged) patch
> series from Yadwinder
> (http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg19540.html)
>
> In this patch, the pll lookup table is kept as part of the pll configuration
> code itself, since the pll is just a hardware block which takes an input
> frequency and configuration values to genertate a output clock frequency.
> Given a set of inputs, a pll of a given type will generate the same output
> regardless of the SoC it is used in. So instead of supplying the pll lookup

Tomasz also raised similar point earlier in discussion on that series.
That time a question which remained unanswered for which we were waiting
(as requested from hardware guys also) was that :
Whether we need to stick to recommended values only or we can drive a
particular output frequency with a given input frequency with any possible
set of (P, M, S) values ?

Theoretically it seems possible but from manual its seems to prefer
recommended values.
Also I am not sure whether same values are always recommended in user manuals
for different SoCs using same PLL type.

> table from per-soc clock driver code (as done in the Yadwinder's patch series),
> the pll lookup table can be coupled with the pll code itself, saving duplication
> of pll lookup table for every SoC the pll is used with.

If we don't need to stick to recommended table, definitely it will
save lot of duplication.
In-fact then we can use same pll lookup table for other PLLs also
which have same calculation
equation for output frequency.


Regards,
Yadwinder

>
>  drivers/clk/samsung/clk-pll.c |   88 +++++++++++++++++++++++++++++++++++++++++
>  drivers/clk/samsung/clk-pll.h |   15 +++++++
>  2 files changed, 103 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
> index 362f12d..4940936 100644
> --- a/drivers/clk/samsung/clk-pll.c
> +++ b/drivers/clk/samsung/clk-pll.c
> @@ -172,6 +172,8 @@ struct clk * __init samsung_clk_register_pll36xx(const char *name,
>   * PLL45xx Clock Type
>   */
>
> +#define PLL45XX_EN_MASK                (1 << 31)
> +#define PLL45XX_LOCK_MASK      (1 << 29)
>  #define PLL45XX_MDIV_MASK      (0x3FF)
>  #define PLL45XX_PDIV_MASK      (0x3F)
>  #define PLL45XX_SDIV_MASK      (0x7)
> @@ -187,6 +189,90 @@ struct samsung_clk_pll45xx {
>
>  #define to_clk_pll45xx(_hw) container_of(_hw, struct samsung_clk_pll45xx, hw)
>
> +/* a sorted table of freq supported by pll45xx with 24mhz parent clock */
> +static struct pll45xx_freq_lookup pll45xx_freq_lookup_24mhz[] = {
> +       PLL45XX_PMS(1000000000, 6, 250, 1),
> +       PLL45XX_PMS(800000000, 6, 200, 1),
> +       PLL45XX_PMS(500000000, 6, 250, 2),
> +       PLL45XX_PMS(400000000, 6, 200, 2),
> +       PLL45XX_PMS(200000000, 6, 200, 3),
> +};
> +
> +static int samsung_pll45xx_set_rate(struct clk_hw *hw, unsigned long rate,
> +                                       unsigned long prate)
> +{
> +       struct samsung_clk_pll45xx *pll = to_clk_pll45xx(hw);
> +       struct pll45xx_freq_lookup *f;
> +       unsigned long timeout, pll_con, cnt, idx;
> +
> +       /* select a lookup table based on parent clock frequency */
> +       switch (prate) {
> +       case 24000000:
> +               f = pll45xx_freq_lookup_24mhz;
> +               cnt = ARRAY_SIZE(pll45xx_freq_lookup_24mhz);
> +               break;
> +       default:
> +               pr_err("%s: unsupported parent clock rate, failed to set rate",
> +                                       __func__);
> +               return -EINVAL;
> +       }
> +
> +       /* check if the requested freq is in the list of supported freq */
> +       for (idx = 0; idx < cnt; idx++, f++)
> +               if (f->target_freq == rate)
> +                       break;
> +
> +       if (idx == cnt) {
> +               pr_err("%s: unspported clock speed %ld requested\n",
> +                               __func__, rate);
> +               return -EINVAL;
> +       }
> +
> +       /* first, disable the output of the pll */
> +       writel(readl(pll->con_reg) & ~PLL45XX_EN_MASK, (void *)pll->con_reg);
> +
> +       /* write the new pll configuration values */
> +       pll_con = (f->pdiv << PLL45XX_PDIV_SHIFT) |
> +                       (f->mdiv << PLL45XX_MDIV_SHIFT) |
> +                       (f->sdiv << PLL45XX_SDIV_SHIFT);
> +       writel(pll_con, (void *)pll->con_reg);
> +
> +       /* enable the pll and wait for it to stabilize */
> +       writel(pll_con | PLL45XX_EN_MASK, (void *)pll->con_reg);
> +       timeout = jiffies + msecs_to_jiffies(20);
> +       while (time_before(jiffies, timeout))
> +               if (readl(pll->con_reg) & PLL45XX_LOCK_MASK)
> +                       return 0;
> +       return -EBUSY;
> +}
> +
> +static long samsung_pll45xx_round_rate(struct clk_hw *hw, unsigned long rate,
> +                                               unsigned long *prate)
> +{
> +       struct pll45xx_freq_lookup *f;
> +       unsigned long cnt;
> +
> +       /* select a lookup table based on parent clock frequency */
> +       switch (*prate) {
> +       case 24000000:
> +               f = pll45xx_freq_lookup_24mhz;
> +               cnt = ARRAY_SIZE(pll45xx_freq_lookup_24mhz);
> +               break;
> +       default:
> +               pr_err("%s: unsupported parent clock rate", __func__);
> +               return *prate;
> +       }
> +
> +       /* find the nearest possible clock output that can be supported */
> +       while (cnt-- > 0) {
> +               if (rate >= f->target_freq)
> +                       return f->target_freq;
> +               f++;
> +       }
> +
> +       return (--f)->target_freq;
> +}
> +
>  static unsigned long samsung_pll45xx_recalc_rate(struct clk_hw *hw,
>                                 unsigned long parent_rate)
>  {
> @@ -209,6 +295,8 @@ static unsigned long samsung_pll45xx_recalc_rate(struct clk_hw *hw,
>  }
>
>  static const struct clk_ops samsung_pll45xx_clk_ops = {
> +       .set_rate = samsung_pll45xx_set_rate,
> +       .round_rate = samsung_pll45xx_round_rate,
>         .recalc_rate = samsung_pll45xx_recalc_rate,
>  };
>
> diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
> index f33786e..fb687ec 100644
> --- a/drivers/clk/samsung/clk-pll.h
> +++ b/drivers/clk/samsung/clk-pll.h
> @@ -18,6 +18,21 @@ enum pll45xx_type {
>         pll_4508
>  };
>
> +struct pll45xx_freq_lookup {
> +       unsigned long   target_freq;
> +       unsigned long   pdiv;
> +       unsigned long   mdiv;
> +       unsigned long   sdiv;
> +};
> +
> +#define PLL45XX_PMS(f, p, m, s)                \
> +       {                                       \
> +               .target_freq    = f,            \
> +               .pdiv           = p,            \
> +               .mdiv           = m,            \
> +               .sdiv           = s,            \
> +       }
> +
>  enum pll46xx_type {
>         pll_4600,
>         pll_4650,
> --
> 1.7.5.4
>


From sr at denx.de  Thu Jul 11 06:45:15 2013
From: sr at denx.de (Stefan Roese)
Date: Thu, 11 Jul 2013 12:45:15 +0200
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51DE87D3.5030600@ti.com>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de> <51DE87D3.5030600@ti.com>
Message-ID: <51DE8CBB.4000709@denx.de>

Hi Roger,

On 07/11/2013 12:24 PM, Roger Quadros wrote:
> Stefan,
> 
> I tried it out today and it worked 5/5 times. I used a bare bones
> debian root filesystem for
> the NFS root.

Thanks for testing.

> Could it be possible that the boot scripts on your filesystem are
> somehow shutting down
> the ethernet interface? Might be worth checking on a fresh filesystem.

I'm pretty sure that its not a problem with the filesystem. I'm using
exactly this filesystem for multiple other ARM based boards as well.
And all other boards (most of them with buildin ethernet controller
instead of USB connected) have no problem mounting/booting from it.

BTW: The filesystem is from the ELDK 5.3 [1][2]. You could download/install
it yourself.

>From your log I can see, that you are using a slightly different board
than I am ("Beagle xM Rev C" vs. "Beagle Rev C1/C2/C3"). So its a
different OMAP variant. Could this perhaps make a difference? Do you
by chance have the "old" Beagleboard (non-xM) at hand for another test?

Thanks again,
Stefan

[1] http://www.denx.de/wiki/view/ELDK-5/WebHome#Section_1.6.
[2] ftp://ftp.denx.de/pub/eldk/5.3/targets/armv7a/core-image-sato-sdk-generic-armv7a.tar.gz



From broonie at kernel.org  Thu Jul 11 06:48:04 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 11 Jul 2013 11:48:04 +0100
Subject: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on
 Exynos5420
In-Reply-To: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
Message-ID: <20130711104804.GK24508@sirena.org.uk>

On Thu, Jul 11, 2013 at 12:38:24PM +0530, Padmavathi Venna wrote:

> -#define MOD_LR_LLOW		(0 << 7)
> -#define MOD_LR_RLOW		(1 << 7)
> -#define MOD_SDF_IIS		(0 << 5)
> -#define MOD_SDF_MSB		(1 << 5)
> -#define MOD_SDF_LSB		(2 << 5)
> -#define MOD_SDF_MASK		(3 << 5)

> +#define MOD_LR_LLOW		0
> +#define MOD_LR_RLOW		1
> +#define MOD_SDF_SHIFT		5
> +#define MOD_SDF_IIS		0
> +#define MOD_SDF_MSB		1
> +#define MOD_SDF_LSB		2
> +#define MOD_SDF_MASK		3

This patch has an awful lot of coding style changes like this which
are just coding style changes and not implementing TDM support.  These
should be done separately, not as part of the same patch, in order to
make the code easier to review.

>  	case 768:
> -		mod |= MOD_RCLK_768FS;
> +		mod |= (MOD_RCLK_768FS << rfs_shift);
>  		break;

This stuff is another example.

I think the change itself should be fine but I'm not 100% sure I'm
correctly identifying what's a stylistic change and what's a functional
change.
-------------- 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/20130711/2aad456e/attachment.sig>

From rnayak at ti.com  Thu Jul 11 06:53:03 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Thu, 11 Jul 2013 16:23:03 +0530
Subject: [PATCH 0/2] Fix omap serial early crash during hwmod _setup()
Message-ID: <1373539986-27272-1-git-send-email-rnayak@ti.com>

This series should fix the issue with the early serial crash seen
during hwmod _setup() as reported by [1]

The issue was reported on a am33xx device and was not seen on omap4
or omap5 devices as the hwmod data for both omap4 and omap5 had
statically defined HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET for
uart3 which happens to be the debug console used on omap4 panda and
omap5 uevm boards.

The series reverts the patch which stubbed out omap_serial_early_init()
for DT boot and gets rid of the static flags in omap4 and omap5 hwmod
data.

This series along with the patch posted by Felipe [2] should fix the
issue reported by [1] completely and boot to prompt on a am33xx device
with LL_DEBUG enabled.

I have boot tested this series (along with [2]) on a omap4 panda es and
a am335x boneblack.

[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/100628

[2] http://marc.info/?l=linux-omap&m=137353783912736&w=2

Rajendra Nayak (2):
  Revert "ARM: OMAP2+: Fix serial init for device tree based booting"
  ARM: OMAP4+: Get rid of the HWMOD_INIT_NO_IDLE and
    HWMOD_INIT_NO_RESET flags for uart

 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    3 +--
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |    1 -
 arch/arm/mach-omap2/serial.c               |    3 ---
 3 files changed, 1 insertion(+), 6 deletions(-)

-- 
1.7.9.5



From rnayak at ti.com  Thu Jul 11 06:53:04 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Thu, 11 Jul 2013 16:23:04 +0530
Subject: [PATCH 1/2] Revert "ARM: OMAP2+: Fix serial init for device tree
 based booting"
In-Reply-To: <1373539986-27272-1-git-send-email-rnayak@ti.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
Message-ID: <1373539986-27272-2-git-send-email-rnayak@ti.com>

This reverts commit 82702ea11ddfe0e43382e1fa5b66d807d8114916.

The above commit stubbed out omap_serial_early_init() in case of
DT build thinking it was doing the serial port initializations.

omap_serial_early_init() however does not do the serial port
inits (its instead done by omap_serial_init_port()) instead
it sets the HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags
for the console uart which causes hwmod to avoid doing a reset
followed by the idling of the console uart.

This is still needed even in the DT case.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
Reported-by: Mark Jackson <mpfj-list at newflow.co.uk>
Reported-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
---
 arch/arm/mach-omap2/serial.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3a674de..58d5b56 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -175,9 +175,6 @@ static char *cmdline_find_option(char *str)
 
 static int __init omap_serial_early_init(void)
 {
-	if (of_have_populated_dt())
-		return -ENODEV;
-
 	do {
 		char oh_name[MAX_UART_HWMOD_NAME_LEN];
 		struct omap_hwmod *oh;
-- 
1.7.9.5



From rnayak at ti.com  Thu Jul 11 06:53:05 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Thu, 11 Jul 2013 16:23:05 +0530
Subject: [PATCH 2/2] ARM: OMAP4+: Get rid of the HWMOD_INIT_NO_IDLE and
 HWMOD_INIT_NO_RESET flags for uart
In-Reply-To: <1373539986-27272-1-git-send-email-rnayak@ti.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
Message-ID: <1373539986-27272-3-git-send-email-rnayak@ti.com>

The HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags don't belong in the
SoC data but instead need to be set runtime based on the uart thats used
for debug console, so hwmod avoids doing a reset followed by a idling of
the device. This is already happening as part of the omap_serial_early_init()
so remove these flags from the static SoC data.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    3 +--
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |    1 -
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index d04b5e6..f80f120 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2858,8 +2858,7 @@ static struct omap_hwmod omap44xx_uart3_hwmod = {
 	.name		= "uart3",
 	.class		= &omap44xx_uart_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
-				HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index f37ae96..e816edd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1375,7 +1375,6 @@ static struct omap_hwmod omap54xx_uart3_hwmod = {
 	.name		= "uart3",
 	.class		= &omap54xx_uart_hwmod_class,
 	.clkdm_name	= "l4per_clkdm",
-	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
 	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
-- 
1.7.9.5



From will.deacon at arm.com  Thu Jul 11 06:54:44 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 11 Jul 2013 11:54:44 +0100
Subject: Seg fault occurs when running statically compiled binary from
 kernel using call_usermodehelper
In-Reply-To: <20130710185200.GX24642@n2100.arm.linux.org.uk>
References: <CAOiN93mGTu9w9rVNCrbbH1sccXY9VJhaCmg+dS7Rk9mMgKHBaA@mail.gmail.com>
 <CAOiN93=Nx77RkbNuEJMV617MjV5+GmorF0G3vyLy1SwQcuCs+g@mail.gmail.com>
 <CAOiN93nH9fyHoz4yrZmJ-OKCy6ogdt5bYartXCBgP5eHMUBPdw@mail.gmail.com>
 <20130710163410.GA30514@mudshark.cambridge.arm.com>
 <20130710185200.GX24642@n2100.arm.linux.org.uk>
Message-ID: <20130711105443.GE32197@mudshark.cambridge.arm.com>

On Wed, Jul 10, 2013 at 07:52:00PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 10, 2013 at 05:34:11PM +0100, Will Deacon wrote:
> > Ok, I've finally got to the bottom of this, but I'm not sure on the best way
> > to fix it.
> 
> I don't think you have!  You need to look back at the older ARM kernels
> to really get to the bottom of this...

It's hard enough looking at the current kernel with the internet connection
I'm currently on! Anyway, what I meant was that I can see why the
application is falling over.

> > The issue is that libc expects r0 to contain a function pointer
> > to be invoked at exit (rtld_fini), to clean up after a dynamic linker. If
> > this pointer is NULL, then it is ignored. We actually zero this pointer in
> > our ELF_PLAT_INIT macro.
> > 
> > At the same time, we have this strange code called next from the ARM ELF
> > loader:
> > 
> > 	regs->ARM_r2 = stack[2];	/* r2 (envp) */			\
> > 	regs->ARM_r1 = stack[1];	/* r1 (argv) */			\
> > 	regs->ARM_r0 = stack[0];	/* r0 (argc) */			\
> > 
> > which puts argc into r0.
> 
> You're sort of right.  It dates from the days when we had a.out binaries,
> those required argc, argv and envp in r0/r1/r2 - and ARM kernels carried
> this hack in  binfmt_aout.c to make it work in conjunction with the above:
> 
> static int load_aout_binary(struct linux_binprm * bprm)
> {
> ...
>         start_thread(regs, ex.a_entry, current->mm->start_stack);
> #ifndef __arm__
>         return 0;
> #else
>         return regs->ARM_r0;
> #endif
> }
> 
> ELF, on the other hand, never had that hack - ELF has always been zero
> in r0, and it's always retrieved the argc/argv/envp off the stack.

Aha, I was missing the a.out part, thanks. The ELF loader does call:

	ELF_PLAT_INIT(regs, reloc_func_desc);
	start_thread(regs, elf_entry, bprm->p);

back-to-back, which zeroes ARM_r0 and then promptly sticks argc there
straight away. libc uses the stack for everything (ARM_r0 gets clobbered
again with the return value of execve anyway), so we just have to assume
that nobody is using argv and/or envp from r1 and r2. I think that's a
sensible assumption.

> As the above hack got dropped from the kernel (I don't think it ever made
> it into mainline), I think we should be safe getting rid of this
> initialization of regs->ARM_r0 to r2, leaving them all as zeros.
> 
> We should probably also remove the selection of HAVE_AOUT from
> arch/arm/Kconfig too as this definitely won't work with any recent
> kernel (certainly not without binfmt_aout.c hacked in the above way.)

Sounds like a good idea, I'll write a patch...

Will


From u.kleine-koenig at pengutronix.de  Thu Jul 11 06:56:26 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Thu, 11 Jul 2013 12:56:26 +0200
Subject: [PATCH 2/6] ARM: mxs: look up timrot clock from device tree
In-Reply-To: <1364224652-28332-3-git-send-email-shawn.guo@linaro.org>
References: <1364224652-28332-1-git-send-email-shawn.guo@linaro.org>
 <1364224652-28332-3-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130711105625.GB12139@pengutronix.de>

Hello Shawn,

On Mon, Mar 25, 2013 at 11:17:28PM +0800, Shawn Guo wrote:
> Change call clk_get_sys() to of_clk_get() to look up timrot clock from
> device tree, so that the clk_register_clkdev() call for timrot can be
> saved in clock driver.

I'm currently using an i.MX28 with 3.8-rt13 and patched the clocksource
and clockevent to use the 24 MHz clock source
(BV_TIMROTv2_TIMCTRLn_SELECT__ALWAYS instead of
BV_TIMROTv2_TIMCTRLn_SELECT__32KHZ_XTAL). Currently my patch is a hack
because I hard code the 24 MHz. I wonder how to do it properly?

Add another item to the "clocks = <...>" entry and use the first entry
for enable and the 2nd for clk_get_rate?

Something like:

	always_clk = of_clk_get(np, 1);
	if (always_clk)
		register timers using always clk (24 MHz, SELECT__ALWAYS)
	else
		fall back to timer_clk (32 kHz, 32KHZ_XTAL)

and then

	timrot at 80068000 {
		compatible = "fsl,imx28-timrot", "fsl,timrot";
		reg = <0x80068000 0x2000>;
		interrupts = <48 49 50 51>;
		clocks = <&clks 26 &clks 0>;
	};

If you like it, too, I can prepare a patch.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From broonie at kernel.org  Wed Jul 10 11:47:12 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 10 Jul 2013 16:47:12 +0100
Subject: [PATCH] rtc: Add MOXA ART RTC driver
In-Reply-To: <1373464848-28146-1-git-send-email-jonas.jensen@gmail.com>
References: <1373464848-28146-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <20130710154712.GG24508@sirena.org.uk>

On Wed, Jul 10, 2013 at 04:00:48PM +0200, Jonas Jensen wrote:

> +++ b/drivers/rtc/Makefile
> @@ -77,6 +77,7 @@ obj-$(CONFIG_RTC_DRV_MAX6902)	+= rtc-max6902.o
>  obj-$(CONFIG_RTC_DRV_MAX77686)	+= rtc-max77686.o
>  obj-$(CONFIG_RTC_DRV_MC13XXX)	+= rtc-mc13xxx.o
>  obj-$(CONFIG_RTC_DRV_MSM6242)	+= rtc-msm6242.o
> +obj-$(CONFIG_RTC_DRV_MOXART)	+= rtc-moxart.o
>  obj-$(CONFIG_RTC_DRV_MPC5121)	+= rtc-mpc5121.o

It'd be good to keep this sorted.

> +struct rtc_plat_data {

This is a bit confusing - normally platform data is data passed in by
the platform as part of device registration, not runtime data.

> +	struct rtc_device *rtc;
> +};
> +
> +static spinlock_t rtc_lock;

Why is this global not part of the runtime data?  Not that anyone is
likely to have two RTCs in the one system but still...

> +u8 moxart_rtc_read_byte(void)
> +{
> +	int i;
> +	u8 data = 0;
> +
> +	for (i = 0; i < 8; i++) {
> +		gpio_set_value(GPIO_RTC_SCLK, GPIO_EM1240_LOW);
> +		udelay(GPIO_RTC_DELAY_TIME);
> +		gpio_set_value(GPIO_RTC_SCLK, GPIO_EM1240_HIGH);
> +		if (gpio_get_value(GPIO_RTC_DATA))
> +			data |= (1 << i);
> +		udelay(GPIO_RTC_DELAY_TIME);

This looks wrong, although I expect it's probably fine - you're reading
the value with no delay after setting the GPIO high.  I assume the
hardware actually strobes the data out on the the high to low transition
but in that case I'd expect the get to be before the raise.  Either that
or some delay after the raise just to make sure.

It's also very odd seeing the constants for _LOW and _HIGH, these should
just be booleans.

> +static int moxart_rtc_ioctl(struct device *dev, unsigned int cmd,
> +	unsigned long arg)
> +{
> +	switch (cmd) {
> +	default:
> +		return -ENOIOCTLCMD;
> +	}
> +
> +	return 0;
> +}

Why not just remove this function?

> + out:
> +	if (pdata->rtc)
> +		rtc_device_unregister(pdata->rtc);
> +	devm_kfree(&pdev->dev, pdata);

devm_kfree() isn't needed, the main point of devm_ is to avoid having to
explicitly free things.

> +	gpio_free(GPIO_RTC_DATA);
> +	gpio_free(GPIO_RTC_SCLK);
> +	gpio_free(GPIO_RTC_RESET);

Use devm_gpio_request().
-------------- 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/20130710/be4d14ac/attachment.sig>

From tomasz.figa at gmail.com  Thu Jul 11 07:07:13 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 11 Jul 2013 13:07:13 +0200
Subject: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on
 Exynos5420
In-Reply-To: <20130711104804.GK24508@sirena.org.uk>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
 <20130711104804.GK24508@sirena.org.uk>
Message-ID: <10406176.2lc5qJ8Oq7@thinkpad>

On Thursday 11 of July 2013 11:48:04 Mark Brown wrote:
> On Thu, Jul 11, 2013 at 12:38:24PM +0530, Padmavathi Venna wrote:
> > -#define MOD_LR_LLOW		(0 << 7)
> > -#define MOD_LR_RLOW		(1 << 7)
> > -#define MOD_SDF_IIS		(0 << 5)
> > -#define MOD_SDF_MSB		(1 << 5)
> > -#define MOD_SDF_LSB		(2 << 5)
> > -#define MOD_SDF_MASK		(3 << 5)
> > 
> > +#define MOD_LR_LLOW		0
> > +#define MOD_LR_RLOW		1
> > +#define MOD_SDF_SHIFT		5
> > +#define MOD_SDF_IIS		0
> > +#define MOD_SDF_MSB		1
> > +#define MOD_SDF_LSB		2
> > +#define MOD_SDF_MASK		3
> 
> This patch has an awful lot of coding style changes like this which
> are just coding style changes and not implementing TDM support.  These
> should be done separately, not as part of the same patch, in order to
> make the code easier to review.
> 
> >  	case 768:
> > -		mod |= MOD_RCLK_768FS;
> > +		mod |= (MOD_RCLK_768FS << rfs_shift);
> > 
> >  		break;
> 
> This stuff is another example.
> 
> I think the change itself should be fine but I'm not 100% sure I'm
> correctly identifying what's a stylistic change and what's a functional
> change.

Right. This could be split into two patches, first reworking the style to give 
more flexibility with operations on registers and another one adding TDM 
specific changes, like new bitfield definitions and conditional handling of 
register accesses to account for new bitfield locations.

Best regards,
Tomasz



From mark.rutland at arm.com  Thu Jul 11 07:10:04 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Jul 2013 12:10:04 +0100
Subject: [RFC PATCH 4/5] arm64: add CPU_HOTPLUG infrastructure
In-Reply-To: <20130711093359.GF830@codeaurora.org>
References: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
 <1373494549-24972-1-git-send-email-mark.rutland@arm.com>
 <20130711093359.GF830@codeaurora.org>
Message-ID: <20130711111003.GB13035@kartoffel>

On Thu, Jul 11, 2013 at 10:33:59AM +0100, Stephen Boyd wrote:
> On 07/10, Mark Rutland wrote:
> > +void __ref cpu_die(void)
> > +{
> > +	unsigned int cpu = smp_processor_id();
> > +
> > +	idle_task_exit();
> > +
> > +	local_irq_disable();
> > +	mb();
> > +
> > +	/* Tell __cpu_die() that this CPU is now safe to dispose of */
> > +	RCU_NONIDLE(complete(&cpu_died));
> 
> This isn't true anymore.

Ah. I'd missed the RCU_NONIDLE while rebasing the series. I'll fix that up.

Thanks,
Mark.


From broonie at kernel.org  Thu Jul 11 07:11:44 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 11 Jul 2013 12:11:44 +0100
Subject: [PATCH] ASoC: Samsung: Set RFS and BFS in slave mode
In-Reply-To: <1373526505-27115-2-git-send-email-padma.v@samsung.com>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
 <1373526505-27115-2-git-send-email-padma.v@samsung.com>
Message-ID: <20130711111144.GL24508@sirena.org.uk>

On Thu, Jul 11, 2013 at 12:38:25PM +0530, Padmavathi Venna wrote:
> As per the User Manual, the RFS and BFS should be set in slave mode
> for correct operation.

Applied, thanks.  Since this is a fix it should have been the first
patch in the series - this allows fixes to be sent to 

> Reviewed-on: https://gerrit-int.chromium.org/37841

Including things like this isn't terribly helpful - this is the Chromium
internal system and nobody in the community can view the review.  A link
to a public system might be useful but a private one should be omitted.
-------------- 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/20130711/486b9d13/attachment.sig>

From marc.zyngier at arm.com  Thu Jul 11 07:13:00 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Jul 2013 12:13:00 +0100
Subject: [PATCH] arm64: use common reboot infrastructure
Message-ID: <1373541180-7452-1-git-send-email-marc.zyngier@arm.com>

Commit 7b6d864b48d9 (reboot: arm: change reboot_mode to use enum
reboot_mode) changed the way reboot is handled on arm, which has a
direct impact on arm64 as we share the reset driver on the VE platform.

The obvious fix is to move arm64 to use the same infrastructure.

Cc: Robin Holt <holt at sgi.com>
Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/system_misc.h | 3 ++-
 arch/arm64/kernel/process.c          | 2 +-
 kernel/reboot.c                      | 2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
index a6e1750..7a18fab 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -23,6 +23,7 @@
 #include <linux/compiler.h>
 #include <linux/linkage.h>
 #include <linux/irqflags.h>
+#include <linux/reboot.h>
 
 struct pt_regs;
 
@@ -41,7 +42,7 @@ extern void show_pte(struct mm_struct *mm, unsigned long addr);
 extern void __show_regs(struct pt_regs *);
 
 void soft_restart(unsigned long);
-extern void (*arm_pm_restart)(char str, const char *cmd);
+extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
 
 #define UDBG_UNDEFINED	(1 << 0)
 #define UDBG_SYSCALL	(1 << 1)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 46f02c3..1788bf6 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -132,7 +132,7 @@ void machine_restart(char *cmd)
 
 	/* Now call the architecture specific reboot code. */
 	if (arm_pm_restart)
-		arm_pm_restart('h', cmd);
+		arm_pm_restart(reboot_mode, cmd);
 
 	/*
 	 * Whoops - the architecture was unable to reboot.
diff --git a/kernel/reboot.c b/kernel/reboot.c
index 269ed93..9aaeb58 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -25,7 +25,7 @@ int C_A_D = 1;
 struct pid *cad_pid;
 EXPORT_SYMBOL(cad_pid);
 
-#if defined(CONFIG_ARM) || defined(CONFIG_UNICORE32)
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_UNICORE32)
 #define DEFAULT_REBOOT_MODE		= REBOOT_HARD
 #else
 #define DEFAULT_REBOOT_MODE
-- 
1.8.1.5



From broonie at kernel.org  Thu Jul 11 07:20:23 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 11 Jul 2013 12:20:23 +0100
Subject: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on
 Exynos5420
In-Reply-To: <29860116.IF545KsGYb@thinkpad>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
 <29860116.IF545KsGYb@thinkpad>
Message-ID: <20130711112023.GM24508@sirena.org.uk>

On Thu, Jul 11, 2013 at 12:43:22PM +0200, Tomasz Figa wrote:
> On Thursday 11 of July 2013 12:38:24 Padmavathi Venna wrote:

> > +- samsung,supports-tdm: If the I2S controller supports TDM, then this flag
> > +  must be enabled.

> I think this should be rather handled by a different compatible value, not a 

This is a bit of a larger project sadly, there was resistance to doing
the DT bindings based on compatible strings using the IP version :(
-------------- 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/20130711/5d790561/attachment.sig>

From zhangwm at marvell.com  Thu Jul 11 07:20:31 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Thu, 11 Jul 2013 04:20:31 -0700
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <20130710214922.GQ11908@titan.lakedaemon.net>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <CAHCPf3u=Zu2-4RsWzi17rB_FmStwcf-Pt_7oRzAEnxN_w=a7cA@mail.gmail.com>
 <20130710214922.GQ11908@titan.lakedaemon.net>
Message-ID: <175CCF5F49938B4D99B2E3EF7F558EBE3DBC97FDFA@SC-VEXCH4.marvell.com>

Arnd?


> -----Original Message-----
> From: Jason Cooper [mailto:jason at lakedaemon.net]
> Sent: 2013?7?11? 5:49
> To: Matt Sealey
> Cc: Neil Zhang; grant.likely at linaro.org; haojian.zhuang at gmail.com;
> arnd at arndb.de; devicetree-discuss at lists.ozlabs.org;
> linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
> 
> On Wed, Jul 10, 2013 at 03:50:10PM -0500, Matt Sealey wrote:
> > On Tue, Jul 9, 2013 at 7:49 AM, Jason Cooper <jason at lakedaemon.net>
> wrote:
> > > Neil,
> > >
> > > I agree with the need to change, however, this has been in the
> > > binding documentation since v3.5.  I wish we had caught this when we
> > > decided against using stock ticker symbols (not all stock markets
> > > use alphabetical abbreviated names, not all companies are listed on
> > > any stock exchange).
> >
> > Who decided that?
> 
> Now you're going to make me dig ;-)  iirc, we were going the stock ticker
> route, but then noticed that powerpc dts files had been using "marvell,..."
> for a _long_ time.  How long?  I'll leave that as an exercise for the
> reader. :-P  Because we shared at least the ethernet driver with them, we
> decided to conform with what was already present in the kernel and use
> "marvell,..." for all of the dt bindings we were creating for
> kirkwood/dove/mvebu (and eventually orion5x, mv78xx0).
> 
> As for who is 'we'?
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101337.htm
> l
> 
> > You can't just "stop using stock ticker symbols" - FDT is inherently
> > based on the original OpenFirmware device tree and therefore any
> > existing bindings which are done on real OpenFirmware solutions where
> > using stock ticker symbols is entirely appropriate (although, these
> > days, not useful) is counter-productive.
> >
> > If Marvell had originally had mrvl as their ticker, and used this in
> > OF DTs (and it is..), then mrvl it stays. In the case where new
> > devices are added with marvell, this is in this case wrong. You should
> > keep using the old one. A good example of this; Freescale. Nobody is
> > saying everyone should move to "freescale,imx-this" or
> > "freescale,vybrid-that" - it's fsl and it stays fsl for
> > backwards/forwards compatibility because things exist already.
> 
> I agree, that's why I'm arguing for *maintaining* backwards compatibility.
> 
> > Any new companies can have a long, descriptive name; a privilege of
> > being late to the party, you might say :)
> >
> > Having an odd mix of mrvl and marvell or moving to marvell is just
> > completely obtuse, whether they had that stock ticker, will have it in
> > the future, it is how they're defined and you can't in good conscience
> > change the binding after devices ship with it.
> 
> See above regarding the marvell ethernet driver and powerpc...
> 
> > > To do this properly, the drivers are going to have to be compatible
> > > with the old and the new names, and the binding docs updated to
> > > reflect the legacy name and the preferred name.
> >
> > Properly would be as above. You can stop using stock tickers for new
> > company names, but anything that has been defined in a device tree
> > before has to stay that way, and all the manufacturer prefixes to
> > device names should be the same. What you're proposing is purely
> > driver bloat and increasing the size of kernel.
> 
> *I'm* not proposing to change the name, Neil is.  I'm proposing that
> *iff* they chose to do that, don't break sh*t along the way.
> 

What's your opinion?

> thx,
> 
> Jason.

Best Regards,
Neil Zhang

From zhangwm at marvell.com  Thu Jul 11 07:23:10 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Thu, 11 Jul 2013 04:23:10 -0700
Subject: [PATCH V3 2/3] clocksource: mmp: support CLOCKSOURCE OF DECLARE
In-Reply-To: <CAN1soZyFztVR1XSw9bDS5JexK0Mdbpr6yevatVf+MnBohwCj1Q@mail.gmail.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-3-git-send-email-zhangwm@marvell.com>
 <20130709181434.76f6216d@skate>	<201307092316.20905.arnd@arndb.de>
 <CAN1soZyFztVR1XSw9bDS5JexK0Mdbpr6yevatVf+MnBohwCj1Q@mail.gmail.com>
Message-ID: <175CCF5F49938B4D99B2E3EF7F558EBE3DBC97FDFF@SC-VEXCH4.marvell.com>

Haojian,


> -----Original Message-----
> From: Haojian Zhuang [mailto:haojian.zhuang at gmail.com]
> Sent: 2013?7?10? 13:59
> To: Arnd Bergmann
> Cc: Thomas Petazzoni; Neil Zhang; Grant Likely;
> devicetree-discuss at lists.ozlabs.org; linux-kernel at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH V3 2/3] clocksource: mmp: support CLOCKSOURCE OF
> DECLARE
> 
> On Wed, Jul 10, 2013 at 5:16 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Tuesday 09 July 2013, Thomas Petazzoni wrote:
> >> Dear Neil Zhang,
> >>
> >> On Tue, 9 Jul 2013 14:42:45 +0800, Neil Zhang wrote:
> >> > support CLOCKSOURCE OF DECLARE for mmp timer.
> >> >
> >> > Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> >> > ---
> >> >  arch/arm/mach-mmp/mmp-dt.c  |    5 ++---
> >> >  arch/arm/mach-mmp/mmp2-dt.c |    3 +--
> >> >  arch/arm/mach-mmp/time.c    |   15 ++-------------
> >> >  3 files changed, 5 insertions(+), 18 deletions(-)
> >>
> >> Maybe it would be good to take this opportunity to move
> >> arch/arm/mach-mmp/time.c into drivers/clocksource/.
> >
> > +1
> >
> > Or we might want to have a more coordinated move of all clocksource
> > drivers in arch/arm to drivers/clocksource now, as we have done for
> > some other subsystems.
> >
> >         Arnd
> 
> I already sent some patches on this. But I didn't get response yet. I'll rebase
> them and send them again. I hope that they could be merged in this cycle.
> 
> Regards
> Haojian

Will you submit a patch to move it by yourself or let me update the patch to 
move it to drivers/clocksource in next version?

Best Regards,
Neil Zhang

From zhangwm at marvell.com  Thu Jul 11 07:35:16 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Thu, 11 Jul 2013 04:35:16 -0700
Subject: [PATCH V3 3/3] ARM: mmp: bring up pxa988 with device tree support
In-Reply-To: <201307100005.21769.arnd@arndb.de>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-4-git-send-email-zhangwm@marvell.com>
 <201307100005.21769.arnd@arndb.de>
Message-ID: <175CCF5F49938B4D99B2E3EF7F558EBE3DBC97FE11@SC-VEXCH4.marvell.com>

Arnd,



> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 2013?7?10? 6:05
> To: Neil Zhang
> Cc: grant.likely at linaro.org; haojian.zhuang at gmail.com;
> devicetree-discuss at lists.ozlabs.org; linux-kernel at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org; Chao Xie
> Subject: Re: [PATCH V3 3/3] ARM: mmp: bring up pxa988 with device tree
> support
> 
> On Tuesday 09 July 2013, Neil Zhang wrote:
> > +	soc {
> > +		compatible = "simple-bus";
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		interrupt-parent = <&gic>;
> > +		ranges;
> > +
> > +		gic: interrupt-controller at d1dfe100 {
> > +			compatible = "arm,cortex-a9-gic";
> > +			#interrupt-cells = <3>;
> > +			#address-cells = <1>;
> > +			interrupt-controller;
> > +			reg = <0xd1dff000 0x1000>,
> > +			      <0xd1dfe100 0x0100>;
> > +		};
> > +
> > +		L2: l2-cache-controller at d1dfb000 {
> > +			compatible = "arm,pl310-cache";
> > +			reg = <0xd1dfb000 0x1000>;
> > +			arm,data-latency = <2 1 1>;
> > +			arm,tag-latency = <2 1 1>;
> > +			arm,pwr-dynamic-clk-gating;
> > +			arm,pwr-standby-mode;
> > +			cache-unified;
> > +			cache-level = <2>;
> > +		};
> > +
> > +		local-timer at d1dfe600 {
> > +			compatible = "arm,cortex-a9-twd-timer";
> > +			reg = <0xd1dfe600 0x20>;
> > +			interrupts = <1 13 0x304>;
> > +		};
> > +
> > +		axi at d4200000 {	/* AXI */
> > +			compatible = "simple-bus";
> > +			#address-cells = <1>;
> > +			#size-cells = <1>;
> > +			ranges = <0xd4200000 0xd4200000 0x00200000>;
> > +
> > +			intc: wakeupgen at d4282000 {
> > +				compatible = "marvell,mmp-intc";
> > +				reg = <0xd4282000 0x1000>;
> > +				marvell,intc-wakeup = <0x114 0x3
> > +						    0x144 0x3>;
> > +			};
> > +		};
> 
> I am guessing that the structure does not actually reflect the hardware.
> 
> Shouldn't AXI be the top-level bus, with the other stuff under it?
> 
> > +
> > +
> > +			uart1: uart at d4017000 {
> > +				compatible = "marvell,mmp-uart";
> > +				reg = <0xd4017000 0x1000>;
> > +				interrupts = <0 27 0x4>;
> > +				status = "disabled";
> > +			};
> 
> The uart node should be called "serial at d4017000" instead of
> "uart at d4017000".

Thanks for the catch!

> 
> > diff --git a/arch/arm/mach-mmp/reset.c b/arch/arm/mach-mmp/reset.c
> new
> > file mode 100644 index 0000000..b90ec54
> > --- /dev/null
> > +++ b/arch/arm/mach-mmp/reset.c
> > @@ -0,0 +1,66 @@
> > +/*
> > + * linux/arch/arm/mach-mmp/reset.c
> 
> I think this could just be part of the smp.c file.

Sorry, but which smp.c do you mean?

> 
> > + *
> > + * Author:	Neil Zhang <zhangwm at marvell.com>
> > + * Copyright:	(C) 2012 Marvell International Ltd.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + modify
> > + * it under the terms of the GNU General Public License as published
> > + by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include <linux/kernel.h>
> > +#include <linux/smp.h>
> > +
> > +#include <asm/io.h>
> > +#include <asm/cacheflush.h>
> > +#include <asm/mach/map.h>
> > +
> > +#include <mach/addr-map.h>
> > +
> > +#include "reset.h"
> > +
> > +#define PMU_CC2_AP			APMU_REG(0x0100)
> > +#define CIU_CA9_WARM_RESET_VECTOR	CIU_REG(0x00d8)
> 
> You should not hardcode the addresses here, better find them from the
> device tree.

Thanks for your suggestion, we will consider it.

> > +
> > +#define CPU_CORE_RST(n)	(1 << ((n) * 4 + 16))
> > +#define CPU_DBG_RST(n)	(1 << ((n) * 4 + 18))
> > +#define CPU_WDOG_RST(n)	(1 << ((n) * 4 + 19))
> 
> This should probably go into a reset controller driver, in drivers/reset/
> 

It should not related to drivers/reset/.
What this file does is to set reset handler for core bootup or reset from power down (suspend or C2 power down).

> 	Arnd

Best Regards,
Neil Zhang

From pullip.cho at samsung.com  Thu Jul 11 07:40:35 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Thu, 11 Jul 2013 20:40:35 +0900
Subject: [PATCH v7 9/9] iommu/exynos: add bus notifier for registering
 System MMU
In-Reply-To: <CAH=HWYMg4cD5kisxj3uUj+2_DvvgihE09tDO=9-2cVjJrnhMSg@mail.gmail.com>
References: <003101ce797b$5418e8e0$fc4abaa0$@samsung.com>
 <CAH=HWYMg4cD5kisxj3uUj+2_DvvgihE09tDO=9-2cVjJrnhMSg@mail.gmail.com>
Message-ID: <000001ce7e2b$75568120$60038360$@samsung.com>

> From: Prathyush K [mailto:prathyush at chromium.org] 
> Sent: Thursday, July 11, 2013 12:03 AM
> 
> I think this patch can be split further.
> There is a lot more added in this patch (suspend/resume functions etc) than just adding a bus notifier.

Oh, Sorry for that ;-)

Actually, adding bus notifier is to register gpd_pm_ops to master peripheral devices,
it results in big change in the driver.

> 
> I will review further and also, test this patchset.
> 

Thank you very much.

> Regards,
> Prathyush
> 
> On Fri, Jul 5, 2013 at 5:59 PM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> When a device driver is registered, all constructs to handle System MMU
> is prepared by bus notifier call.
> 
> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> ---
>  drivers/iommu/exynos-iommu.c |  778 ++++++++++++++++++++++++++++++-----------
>  1 files changed, 569 insertions(+), 209 deletions(-)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index b151e51..51d43bb 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -27,6 +27,9 @@
>  #include <linux/memblock.h>
>  #include <linux/export.h>
>  #include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/pm_domain.h>
> +#include <linux/notifier.h>
> 
>  #include <asm/cacheflush.h>
>  #include <asm/pgtable.h>
> @@ -80,6 +83,14 @@
>  #define CTRL_BLOCK     0x7
>  #define CTRL_DISABLE   0x0
> 
> +#define CFG_LRU                0x1
> +#define CFG_QOS(n)     ((n & 0xF) << 7)
> +#define CFG_MASK       0x0150FFFF /* Selecting bit 0-15, 20, 22 and 24 */
> +#define CFG_ACGEN      (1 << 24) /* System MMU 3.3 only */
> +#define CFG_SYSSEL     (1 << 22) /* System MMU 3.2 only */
> +#define CFG_FLPDCACHE  (1 << 20) /* System MMU 3.2+ only */
> +#define CFG_SHAREABLE  (1 << 12) /* System MMU 3.x only */
> +
>  #define REG_MMU_CTRL           0x000
>  #define REG_MMU_CFG            0x004
>  #define REG_MMU_STATUS         0x008
> @@ -96,6 +107,9 @@
> 
>  #define REG_MMU_VERSION                0x034
> 
> +#define MMU_MAJ_VER(reg)       (reg >> 28)
> +#define MMU_MIN_VER(reg)       ((reg >> 21) & 0x7F)
> +
>  #define REG_PB0_SADDR          0x04C
>  #define REG_PB0_EADDR          0x050
>  #define REG_PB1_SADDR          0x054
> @@ -126,16 +140,6 @@ enum exynos_sysmmu_inttype {
>         SYSMMU_FAULTS_NUM
>  };
> 
> -/*
> - * @itype: type of fault.
> - * @pgtable_base: the physical address of page table base. This is 0 if @itype
> - *                is SYSMMU_BUSERROR.
> - * @fault_addr: the device (virtual) address that the System MMU tried to
> - *             translated. This is 0 if @itype is SYSMMU_BUSERROR.
> - */
> -typedef int (*sysmmu_fault_handler_t)(enum exynos_sysmmu_inttype itype,
> -                       unsigned long pgtable_base, unsigned long fault_addr);
> -
>  static unsigned short fault_reg_offset[SYSMMU_FAULTS_NUM] = {
>         REG_PAGE_FAULT_ADDR,
>         REG_AR_FAULT_ADDR,
> @@ -159,6 +163,14 @@ static char *sysmmu_fault_name[SYSMMU_FAULTS_NUM] = {
>         "UNKNOWN FAULT"
>  };
> 
> +struct exynos_iommu_client {
> +       struct list_head node;  /* entry of exynos_iommu_domain.clients */
> +       struct device *dev;
> +       spinlock_t lock;
> +       int num_sysmmu;
> +       struct device *sysmmu[0];
> +};
> +
>  struct exynos_iommu_domain {
>         struct list_head clients; /* list of sysmmu_drvdata.node */
>         unsigned long *pgtable; /* lv1 page table, 16KB */
> @@ -170,13 +182,13 @@ struct exynos_iommu_domain {
>  struct sysmmu_drvdata {
>         struct list_head node; /* entry of exynos_iommu_domain.clients */
>         struct device *sysmmu;  /* System MMU's device descriptor */
> -       struct device *dev;     /* Owner of system MMU */
> +       struct device *master;  /* Owner of system MMU */
>         int nsfrs;
>         struct clk *clk;
>         int activations;
>         spinlock_t lock;
>         struct iommu_domain *domain;
> -       sysmmu_fault_handler_t fault_handler;
> +       bool runtime_active;
>         unsigned long pgtable;
>         void __iomem *sfrbases[0];
>  };
> @@ -200,6 +212,20 @@ static bool is_sysmmu_active(struct sysmmu_drvdata *data)
>         return data->activations > 0;
>  }
> 
> +static unsigned int __sysmmu_version(struct sysmmu_drvdata *data,
> +                                       int idx, unsigned int *minor)
> +{
> +       unsigned int major;
> +
> +       major = readl(data->sfrbases[idx] + REG_MMU_VERSION);
> +
> +       if (minor)
> +               *minor = MMU_MIN_VER(major);
> +       major = MMU_MAJ_VER(major);
> +
> +       return major;
> +}
> +
>  static void sysmmu_unblock(void __iomem *sfrbase)
>  {
>         __raw_writel(CTRL_ENABLE, sfrbase + REG_MMU_CTRL);
> @@ -235,7 +261,6 @@ static void __sysmmu_tlb_invalidate_entry(void __iomem *sfrbase,
>  static void __sysmmu_set_ptbase(void __iomem *sfrbase,
>                                        unsigned long pgd)
>  {
> -       __raw_writel(0x1, sfrbase + REG_MMU_CFG); /* 16KB LV1, LRU */
>         __raw_writel(pgd, sfrbase + REG_PT_BASE_ADDR);
> 
>         __sysmmu_tlb_invalidate(sfrbase);
> @@ -292,34 +317,17 @@ finish:
>         spin_unlock_irqrestore(&data->lock, flags);
>  }
> 
> -static void __set_fault_handler(struct sysmmu_drvdata *data,
> -                                       sysmmu_fault_handler_t handler)
> -{
> -       unsigned long flags;
> -
> -       spin_lock_irqsave(&data->lock, flags);
> -       data->fault_handler = handler;
> -       spin_unlock_irqrestore(&data->lock, flags);
> -}
> -
> -void exynos_sysmmu_set_fault_handler(struct device *dev,
> -                                       sysmmu_fault_handler_t handler)
> -{
> -       struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
> -
> -       __set_fault_handler(data, handler);
> -}
> -
> -static int default_fault_handler(enum exynos_sysmmu_inttype itype,
> -                    unsigned long pgtable_base, unsigned long fault_addr)
> +static int show_fault_information(const char *name,
> +               enum exynos_sysmmu_inttype itype,
> +               unsigned long pgtable_base, unsigned long fault_addr)
>  {
>         unsigned long *ent;
> 
>         if ((itype >= SYSMMU_FAULTS_NUM) || (itype < SYSMMU_PAGEFAULT))
>                 itype = SYSMMU_FAULT_UNKNOWN;
> 
> -       pr_err("%s occurred at 0x%lx(Page table base: 0x%lx)\n",
> -                       sysmmu_fault_name[itype], fault_addr, pgtable_base);
> +       pr_err("%s occurred at 0x%lx by %s(Page table base: 0x%lx)\n",
> +               sysmmu_fault_name[itype], fault_addr, name, pgtable_base);
> 
>         ent = section_entry(__va(pgtable_base), fault_addr);
>         pr_err("\tLv1 entry: 0x%lx\n", *ent);
> @@ -340,25 +348,34 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
>  {
>         /* SYSMMU is in blocked when interrupt occurred. */
>         struct sysmmu_drvdata *data = dev_id;
> -       struct resource *irqres;
> -       struct platform_device *pdev;
> +       struct exynos_iommu_client *client = NULL;
> +       struct resource *memres;
>         enum exynos_sysmmu_inttype itype;
>         unsigned long addr = -1;
> -
>         int i, ret = -ENOSYS;
> 
> -       spin_lock(&data->lock);
> +       if (data->master)
> +               client = data->master->archdata.iommu;
> 
>         WARN_ON(!is_sysmmu_active(data));
> 
> -       pdev = to_platform_device(data->sysmmu);
> -       for (i = 0; i < (pdev->num_resources / 2); i++) {
> -               irqres = platform_get_resource(pdev, IORESOURCE_IRQ, i);
> -               if (irqres && ((int)irqres->start == irq))
> +       for (i = 0; i < data->nsfrs; i++) {
> +               struct resource *irqres;
> +               irqres = platform_get_resource(to_platform_device(data->sysmmu),
> +                                               IORESOURCE_IRQ, i);
> +               if (irqres && ((int)irqres->start == irq)) {
> +                       memres = platform_get_resource(
> +                                       to_platform_device(data->sysmmu),
> +                                       IORESOURCE_MEM, i);
>                         break;
> +               }
>         }
> 
> -       if (i == pdev->num_resources) {
> +       if (client)
> +               spin_lock(&client->lock);
> +       spin_lock(&data->lock);
> +
> +       if (i == data->nsfrs) {
>                 itype = SYSMMU_FAULT_UNKNOWN;
>         } else {
>                 itype = (enum exynos_sysmmu_inttype)
> @@ -371,197 +388,263 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
>         }
> 
>         if (data->domain)
> -               ret = report_iommu_fault(data->domain, data->dev,
> +               ret = report_iommu_fault(data->domain, data->master,
>                                 addr, itype);
> 
> -       if ((ret == -ENOSYS) && data->fault_handler) {
> -               unsigned long base = data->pgtable;
> -               if (itype != SYSMMU_FAULT_UNKNOWN)
> -                       base = __raw_readl(
> -                                       data->sfrbases[i] + REG_PT_BASE_ADDR);
> -               ret = data->fault_handler(itype, base, addr);
> -       }
> -
>         if (!ret && (itype != SYSMMU_FAULT_UNKNOWN))
>                 __raw_writel(1 << itype, data->sfrbases[i] + REG_INT_CLEAR);
> -       else
> -               dev_dbg(data->sysmmu, "%s is not handled.\n",
> -                               sysmmu_fault_name[itype]);
> +       else {
> +               unsigned long ba = data->pgtable;
> +               if (itype != SYSMMU_FAULT_UNKNOWN)
> +                       ba = __raw_readl(data->sfrbases[i] + REG_PT_BASE_ADDR);
> +               show_fault_information(dev_name(data->sysmmu),
> +                                       itype, ba, addr);
> +       }
> 
>         if (itype != SYSMMU_FAULT_UNKNOWN)
>                 sysmmu_unblock(data->sfrbases[i]);
> 
>         spin_unlock(&data->lock);
> +       if (client)
> +               spin_unlock(&client->lock);
> 
>         return IRQ_HANDLED;
>  }
> 
> -static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
> +static void __sysmmu_disable_nocount(struct sysmmu_drvdata *data)
>  {
> +               int i;
> +
> +               for (i = 0; i < data->nsfrs; i++) {
> +                       __raw_writel(CTRL_DISABLE,
> +                                    data->sfrbases[i] + REG_MMU_CTRL);
> +                       __raw_writel(0, data->sfrbases[i] + REG_MMU_CFG);
> +               }
> +
> +               clk_disable(data->clk);
> +}
> +
> +static bool __sysmmu_disable(struct sysmmu_drvdata *data)
> +{
> +       bool disabled;
>         unsigned long flags;
> -       bool disabled = false;
> -       int i;
> 
>         spin_lock_irqsave(&data->lock, flags);
> 
> -       if (!set_sysmmu_inactive(data))
> -               goto finish;
> +       disabled = set_sysmmu_inactive(data);
> 
> -       for (i = 0; i < data->nsfrs; i++)
> -               __raw_writel(CTRL_DISABLE, data->sfrbases[i] + REG_MMU_CTRL);
> +       if (disabled) {
> +               data->pgtable = 0;
> +               data->domain = NULL;
> 
> -       if (data->clk)
> -               clk_disable(data->clk);
> +               if (data->runtime_active)
> +                       __sysmmu_disable_nocount(data);
> 
> -       disabled = true;
> -       data->pgtable = 0;
> -       data->domain = NULL;
> -finish:
> -       spin_unlock_irqrestore(&data->lock, flags);
> -
> -       if (disabled)
>                 dev_dbg(data->sysmmu, "Disabled\n");
> -       else
> -               dev_dbg(data->sysmmu, "%d times left to be disabled\n",
> +       } else  {
> +               dev_dbg(data->sysmmu, "%d times left to disable\n",
>                                         data->activations);
> +       }
> +
> +       spin_unlock_irqrestore(&data->lock, flags);
> 
>         return disabled;
>  }
> 
> -/* __exynos_sysmmu_enable: Enables System MMU
> - *
> - * returns -error if an error occurred and System MMU is not enabled,
> - * 0 if the System MMU has been just enabled and 1 if System MMU was already
> - * enabled before.
> - */
> -static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
> +
> +static void __sysmmu_init_config(struct sysmmu_drvdata *data, int idx)
> +{
> +       unsigned long cfg = CFG_LRU;
> +       int maj, min = 0;
> +
> +       maj = __sysmmu_version(data, idx, &min);
> +       if (maj == 3) {
> +               cfg |= CFG_SHAREABLE;
> +               if (min > 1) {
> +                       cfg |= CFG_FLPDCACHE;
> +                       cfg |= (min == 2) ? CFG_SYSSEL : CFG_ACGEN;
> +               }
> +       }
> +
> +       cfg |= __raw_readl(data->sfrbases[idx] + REG_MMU_CFG) & ~CFG_MASK;
> +       __raw_writel(cfg, data->sfrbases[idx] + REG_MMU_CFG);
> +}
> +
> +static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
> +{
> +       int i;
> +
> +       clk_enable(data->clk);
> +
> +       for (i = 0; i < data->nsfrs; i++) {
> +               BUG_ON(__raw_readl(data->sfrbases[i] + REG_MMU_CTRL)
> +                                                               & CTRL_ENABLE);
> 
> We are assuming that the REG_MMU_CTRL will be 0 in the beginning.
> In the newer versions of smmus (e.g. FIMD's sysmmu in Exynos5420), the reset value of REG_MMU_CTRL is 1.
> So this BUG will be triggered when sysmmu gets enabled for the first time.
> 
> One way to fix this is to pass an additional parameter to this function 'init':
> The BUG_ON should not be checked when sysmmu is enabled for first time i.e. from __sysmmu_enable (init = true)
> And the BUG_ON can be checked when this function is called from else where (init = false)

You pointed correctly.

This driver does not consider the SoC after Exynos5250.

Actually the BUG_ON is not required because __sysmmu_enable_nocount(
soon writes CTRL_ENABLE to MMU_CTRL.
Why I put the checking MMU_CTRL before enabling System MMU is
just related to our team's SoC S/W solution.

I don't feel that it is required to add additional parameter to that function.
Just writing CTRL_BLOCK to MMU_CTRL is enough instead of BUG_ON().


>  
> +
> +               __sysmmu_init_config(data, i);
> +
> +               __sysmmu_set_ptbase(data->sfrbases[i], data->pgtable);
> +
> +               __raw_writel(CTRL_ENABLE, data->sfrbases[i] + REG_MMU_CTRL);
> +       }
> +}
> +
> +static int __sysmmu_enable(struct sysmmu_drvdata *data,
>                         unsigned long pgtable, struct iommu_domain *domain)
>  {
> -       int i, ret = 0;
> +       int ret = 0;
>         unsigned long flags;
> 
>         spin_lock_irqsave(&data->lock, flags);
> +       if (set_sysmmu_active(data)) {
> +               data->pgtable = pgtable;
> +               data->domain = domain;
> 
> -       if (!set_sysmmu_active(data)) {
> -               if (WARN_ON(pgtable != data->pgtable)) {
> -                       ret = -EBUSY;
> -                       set_sysmmu_inactive(data);
> -               } else {
> -                       ret = 1;
> -               }
> +               if (data->runtime_active)
> +                       __sysmmu_enable_nocount(data);
> 
> -               dev_dbg(data->sysmmu, "Already enabled\n");
> -               goto finish;
> +               dev_dbg(data->sysmmu, "Enabled\n");
> +       } else {
> +               ret = (pgtable == data->pgtable) ? 1 : -EBUSY;
> +
> +               dev_dbg(data->sysmmu, "already enabled\n");
>         }
> 
> -       if (data->clk)
> -               clk_enable(data->clk);
> +       if (WARN_ON(ret < 0))
> +               set_sysmmu_inactive(data); /* decrement count */
> 
> -       data->pgtable = pgtable;
> +       spin_unlock_irqrestore(&data->lock, flags);
> 
> -       for (i = 0; i < data->nsfrs; i++) {
> -               __sysmmu_set_ptbase(data->sfrbases[i], pgtable);
> +       return ret;
> +}
> 
> -               if ((readl(data->sfrbases[i] + REG_MMU_VERSION) >> 28) == 3) {
> -                       /* System MMU version is 3.x */
> -                       __raw_writel((1 << 12) | (2 << 28),
> -                                       data->sfrbases[i] + REG_MMU_CFG);
> -                       __sysmmu_set_prefbuf(data->sfrbases[i], 0, -1, 0);
> -                       __sysmmu_set_prefbuf(data->sfrbases[i], 0, -1, 1);
> -               }
> +/* __exynos_sysmmu_enable: Enables System MMU
> + *
> + * returns -error if an error occurred and System MMU is not enabled,
> + * 0 if the System MMU has been just enabled and 1 if System MMU was already
> + * enabled before.
> + */
> +static int __exynos_sysmmu_enable(struct device *dev, unsigned long pgtable,
> +                                 struct iommu_domain *domain)
> +{
> +       int ret = 0;
> +       unsigned long flags;
> +       struct exynos_iommu_client *client = dev->archdata.iommu;
> +       int i;
> 
> -               __raw_writel(CTRL_ENABLE, data->sfrbases[i] + REG_MMU_CTRL);
> -       }
> +       if (WARN_ON(!client))
> +               return -ENODEV;
> 
> -       data->domain = domain;
> +       spin_lock_irqsave(&client->lock, flags);
> 
> -       dev_dbg(data->sysmmu, "Enabled\n");
> -finish:
> -       spin_unlock_irqrestore(&data->lock, flags);
> +       for (i = 0; i < client->num_sysmmu; i++) {
> +               struct sysmmu_drvdata *data =
> +                               dev_get_drvdata(client->sysmmu[i]);
> +               ret = __sysmmu_enable(data, pgtable, domain);
> +               if (ret < 0) {
> +                       int j;
> +                       for (j = 0; j < i; j++)
> +                               __sysmmu_disable(data);
> +                       break;
> +               } else {
> +                       data->master = dev;
> +               }
> +       }
> +
> +       spin_unlock_irqrestore(&client->lock, flags);
> 
>         return ret;
>  }
> 
>  int exynos_sysmmu_enable(struct device *dev, unsigned long pgtable)
>  {
> -       struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
>         int ret;
> 
>         BUG_ON(!memblock_is_memory(pgtable));
> 
> -       ret = pm_runtime_get_sync(data->sysmmu);
> -       if (ret < 0) {
> -               dev_dbg(data->sysmmu, "Failed to enable\n");
> -               return ret;
> -       }
> -
> -       ret = __exynos_sysmmu_enable(data, pgtable, NULL);
> -       if (WARN_ON(ret < 0)) {
> -               pm_runtime_put(data->sysmmu);
> -               dev_err(data->sysmmu,
> -                       "Already enabled with page table %#lx\n",
> -                       data->pgtable);
> -       } else {
> -               data->dev = dev;
> -       }
> +       ret = __exynos_sysmmu_enable(dev, pgtable, NULL);
> 
>         return ret;
>  }
> 
>  static bool exynos_sysmmu_disable(struct device *dev)
>  {
> -       struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
> -       bool disabled;
> +       unsigned long flags;
> +       bool disabled = true;
> +       struct exynos_iommu_client *client = dev->archdata.iommu;
> +       int i;
> +
> +       if (WARN_ON(!client))
> +               return true;
> +
> +       spin_lock_irqsave(&client->lock, flags);
> +
> +       /* Every call to __sysmmu_disable() must return same result */
> +       for (i = 0; i < client->num_sysmmu; i++) {
> +               struct sysmmu_drvdata *data =
> +                               dev_get_drvdata(client->sysmmu[i]);
> +               disabled = __sysmmu_disable(data);
> +               if (disabled)
> +                       data->master = NULL;
> +       }
> 
> -       disabled = __exynos_sysmmu_disable(data);
> -       pm_runtime_put(data->sysmmu);
> +       spin_unlock_irqrestore(&client->lock, flags);
> 
>         return disabled;
>  }
> 
>  static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
>  {
> -       unsigned long flags;
> -       struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
> +       struct exynos_iommu_client *client = dev->archdata.iommu;
> +       int i;
> 
> -       spin_lock_irqsave(&data->lock, flags);
> +       for (i = 0; i < client->num_sysmmu; i++) {
> +               unsigned long flags;
> +               struct sysmmu_drvdata *data;
> 
> -       if (is_sysmmu_active(data)) {
> -               int i;
> -               for (i = 0; i < data->nsfrs; i++) {
> -                       if (sysmmu_block(data->sfrbases[i])) {
> +               data = dev_get_drvdata(client->sysmmu[i]);
> +
> +               spin_lock_irqsave(&data->lock, flags);
> +               if (is_sysmmu_active(data) && data->runtime_active) {
> +                       int i;
> +                       for (i = 0; i < data->nsfrs; i++)
>                                 __sysmmu_tlb_invalidate_entry(
>                                                 data->sfrbases[i], iova);
> -                               sysmmu_unblock(data->sfrbases[i]);
> -                       }
> +               } else {
> +                       dev_dbg(dev,
> +                               "disabled. Skipping TLB invalidation @ %#lx\n",
> +                               iova);
>                 }
> -       } else {
> -               dev_dbg(data->sysmmu, "Disabled. Skipping invalidating TLB.\n");
> +               spin_unlock_irqrestore(&data->lock, flags);
>         }
> -
> -       spin_unlock_irqrestore(&data->lock, flags);
>  }
> 
>  void exynos_sysmmu_tlb_invalidate(struct device *dev)
>  {
> -       unsigned long flags;
> -       struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
> -
> -       spin_lock_irqsave(&data->lock, flags);
> +       struct exynos_iommu_client *client = dev->archdata.iommu;
> +       int i;
> 
> -       if (is_sysmmu_active(data)) {
> -               int i;
> -               for (i = 0; i < data->nsfrs; i++) {
> -                       if (sysmmu_block(data->sfrbases[i])) {
> -                               __sysmmu_tlb_invalidate(data->sfrbases[i]);
> -                               sysmmu_unblock(data->sfrbases[i]);
> +       for (i = 0; i < client->num_sysmmu; i++) {
> +               unsigned long flags;
> +               struct sysmmu_drvdata *data;
> +
> +               data = dev_get_drvdata(client->sysmmu[i]);
> +
> +               spin_lock_irqsave(&data->lock, flags);
> +               if (is_sysmmu_active(data) &&
> +                               data->runtime_active) {
> +                       int i;
> +                       for (i = 0; i < data->nsfrs; i++) {
> +                               if (sysmmu_block(data->sfrbases[i])) {
> +                                       __sysmmu_tlb_invalidate(
> +                                                       data->sfrbases[i]);
> +                                       sysmmu_unblock(data->sfrbases[i]);
> +                               }
>                         }
> +               } else {
> +                       dev_dbg(dev, "disabled. Skipping TLB invalidation\n");
>                 }
> -       } else {
> -               dev_dbg(data->sysmmu, "Disabled. Skipping invalidating TLB.\n");
> +               spin_unlock_irqrestore(&data->lock, flags);
>         }
> -
> -       spin_unlock_irqrestore(&data->lock, flags);
>  }
> 
>  static int __init exynos_sysmmu_probe(struct platform_device *pdev)
> @@ -622,8 +705,6 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
> 
>         pm_runtime_enable(dev);
> 
> -       __set_fault_handler(data, &default_fault_handler);
> -
>         data->sysmmu = dev;
>         data->clk = devm_clk_get(dev, "sysmmu");
>         if (IS_ERR(data->clk)) {
> @@ -647,6 +728,8 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
>                 }
>         }
> 
> +       data->runtime_active = !pm_runtime_enabled(dev);
> 
> We are enabling pm_runtime in the probe itself. Is this check still required?
> We can directly set data->runtime_active to false since sysmmus get probed first.

It is required to work correctly without checking if CONFIG_PM_RUNTIME is configured or not.

> 
> +
>         spin_lock_init(&data->lock);
>         INIT_LIST_HEAD(&data->node);
> 
> @@ -656,6 +739,34 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
>         return ret;
>  }
> 
> +#ifdef CONFIG_PM_SLEEP
> +static int sysmmu_suspend(struct device *dev)
> +{
> +       struct sysmmu_drvdata *data = dev_get_drvdata(dev);
> +       unsigned long flags;
> +       spin_lock_irqsave(&data->lock, flags);
> +       if (is_sysmmu_active(data) &&
> +               (!pm_runtime_enabled(dev) || data->runtime_active))
> +               __sysmmu_disable_nocount(data);
> +       spin_unlock_irqrestore(&data->lock, flags);
> +       return 0;
> +}
> +
> +static int sysmmu_resume(struct device *dev)
> +{
> +       struct sysmmu_drvdata *data = dev_get_drvdata(dev);
> +       unsigned long flags;
> +       spin_lock_irqsave(&data->lock, flags);
> +       if (is_sysmmu_active(data) &&
> +               (!pm_runtime_enabled(dev) || data->runtime_active))
> +               __sysmmu_enable_nocount(data);
> +       spin_unlock_irqrestore(&data->lock, flags);
> +       return 0;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(sysmmu_pm_ops, sysmmu_suspend, sysmmu_resume);
> +
>  #ifdef CONFIG_OF
>  static struct of_device_id sysmmu_of_match[] __initconst = {
>         { .compatible   = "samsung,exynos4210-sysmmu", },
> @@ -668,6 +779,7 @@ static struct platform_driver exynos_sysmmu_driver __refdata = {
>         .driver = {
>                 .owner          = THIS_MODULE,
>                 .name           = "exynos-sysmmu",
> +               .pm             = &sysmmu_pm_ops,
>                 .of_match_table = of_match_ptr(sysmmu_of_match),
>         }
>  };
> @@ -720,7 +832,7 @@ err_pgtable:
>  static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
>  {
>         struct exynos_iommu_domain *priv = domain->priv;
> -       struct sysmmu_drvdata *data;
> +       struct exynos_iommu_client *client;
>         unsigned long flags;
>         int i;
> 
> @@ -728,11 +840,14 @@ static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
> 
>         spin_lock_irqsave(&priv->lock, flags);
> 
> -       list_for_each_entry(data, &priv->clients, node) {
> -               while (!exynos_sysmmu_disable(data->dev))
> +       list_for_each_entry(client, &priv->clients, node) {
> +               while (!exynos_sysmmu_disable(client->dev))
>                         ; /* until System MMU is actually disabled */
>         }
> 
> +       while (!list_empty(&priv->clients))
> +               list_del_init(priv->clients.next);
> +
>         spin_unlock_irqrestore(&priv->lock, flags);
> 
>         for (i = 0; i < NUM_LV1ENTRIES; i++)
> @@ -749,41 +864,26 @@ static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
>  static int exynos_iommu_attach_device(struct iommu_domain *domain,
>                                    struct device *dev)
>  {
> -       struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
> +       struct exynos_iommu_client *client = dev->archdata.iommu;
>         struct exynos_iommu_domain *priv = domain->priv;
>         unsigned long flags;
>         int ret;
> 
> -       ret = pm_runtime_get_sync(data->sysmmu);
> -       if (ret < 0)
> -               return ret;
> -
> -       ret = 0;
> -
>         spin_lock_irqsave(&priv->lock, flags);
> 
> -       ret = __exynos_sysmmu_enable(data, __pa(priv->pgtable), domain);
> -
> -       if (ret == 0) {
> -               /* 'data->node' must not be appeared in priv->clients */
> -               BUG_ON(!list_empty(&data->node));
> -               data->dev = dev;
> -               list_add_tail(&data->node, &priv->clients);
> -       }
> +       ret = __exynos_sysmmu_enable(dev, __pa(priv->pgtable), domain);
> +       if (ret == 0)
> +               list_add_tail(&client->node, &priv->clients);
> 
>         spin_unlock_irqrestore(&priv->lock, flags);
> 
> -       if (ret < 0) {
> +       if (ret < 0)
>                 dev_err(dev, "%s: Failed to attach IOMMU with pgtable %#lx\n",
>                                 __func__, __pa(priv->pgtable));
> -               pm_runtime_put(data->sysmmu);
> -       } else if (ret > 0) {
> -               dev_dbg(dev, "%s: IOMMU with pgtable 0x%lx already attached\n",
> -                                       __func__, __pa(priv->pgtable));
> -       } else {
> -               dev_dbg(dev, "%s: Attached new IOMMU with pgtable 0x%lx\n",
> -                                       __func__, __pa(priv->pgtable));
> -       }
> +       else
> +               dev_dbg(dev, "%s: Attached IOMMU with pgtable 0x%lx%s\n",
> +                                       __func__, __pa(priv->pgtable),
> +                                       (ret == 0) ? "" : ", again");
> 
>         return ret;
>  }
> @@ -791,39 +891,27 @@ static int exynos_iommu_attach_device(struct iommu_domain *domain,
>  static void exynos_iommu_detach_device(struct iommu_domain *domain,
>                                     struct device *dev)
>  {
> -       struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
> +       struct exynos_iommu_client *client = NULL;
>         struct exynos_iommu_domain *priv = domain->priv;
> -       struct list_head *pos;
>         unsigned long flags;
> -       bool found = false;
> 
>         spin_lock_irqsave(&priv->lock, flags);
> 
> -       list_for_each(pos, &priv->clients) {
> -               if (list_entry(pos, struct sysmmu_drvdata, node) == data) {
> -                       found = true;
> +       list_for_each_entry(client, &priv->clients, node) {
> +               if (client == dev->archdata.iommu) {
> +                       if (exynos_sysmmu_disable(dev))
> +                               list_del_init(&client->node);
>                         break;
>                 }
>         }
> 
> -       if (!found)
> -               goto finish;
> +       spin_unlock_irqrestore(&priv->lock, flags);
> 
> -       if (__exynos_sysmmu_disable(data)) {
> +       if (client == dev->archdata.iommu)
>                 dev_dbg(dev, "%s: Detached IOMMU with pgtable %#lx\n",
>                                         __func__, __pa(priv->pgtable));
> -               list_del_init(&data->node);
> -
> -       } else {
> -               dev_dbg(dev, "%s: Detaching IOMMU with pgtable %#lx delayed",
> -                                       __func__, __pa(priv->pgtable));
> -       }
> -
> -finish:
> -       spin_unlock_irqrestore(&priv->lock, flags);
> -
> -       if (found)
> -               pm_runtime_put(data->sysmmu);
> +       else
> +               dev_dbg(dev, "%s: No IOMMU is attached\n", __func__);
>  }
> 
>  static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long iova,
> @@ -940,7 +1028,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
>                                                unsigned long iova, size_t size)
>  {
>         struct exynos_iommu_domain *priv = domain->priv;
> -       struct sysmmu_drvdata *data;
> +       struct exynos_iommu_client *client;
>         unsigned long flags;
>         unsigned long *ent;
>         size_t err_page;
> @@ -997,8 +1085,8 @@ done:
>         spin_unlock_irqrestore(&priv->pgtablelock, flags);
> 
>         spin_lock_irqsave(&priv->lock, flags);
> -       list_for_each_entry(data, &priv->clients, node)
> -               sysmmu_tlb_invalidate_entry(data->dev, iova);
> +       list_for_each_entry(client, &priv->clients, node)
> +               sysmmu_tlb_invalidate_entry(client->dev, iova);
>         spin_unlock_irqrestore(&priv->lock, flags);
> 
>         return size;
> @@ -1082,3 +1170,275 @@ static int __init exynos_iommu_init(void)
>         return ret;
>  }
>  subsys_initcall(exynos_iommu_init);
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int sysmmu_pm_genpd_suspend(struct device *dev)
> +{
> +       struct exynos_iommu_client *client = dev->archdata.iommu;
> +       int ret = 0;
> +       int i;
> +
> +       for (i = 0; i < client->num_sysmmu; i++) {
> +               ret = pm_generic_suspend(client->sysmmu[i]);
> +               if (ret)
> +                       break;
> +       }
> +
> +       if (!ret)
> +               ret = pm_generic_suspend(dev);
> +
> +       if (ret) {
> +               int j;
> +
> +               for (j = 0; j < i; j++)
> +                       pm_generic_resume(client->sysmmu[j]);
> +       }
> +
> +       return ret;
> +}
> +
> +static int sysmmu_pm_genpd_resume(struct device *dev)
> +{
> +       struct exynos_iommu_client *client = dev->archdata.iommu;
> +       int ret = 0;
> +       int i;
> +
> +       for (i = 0; i < client->num_sysmmu; i++) {
> +               ret = pm_generic_resume(client->sysmmu[i]);
> +               if (ret)
> +                       break;
> +       }
> +
> +       if (!ret)
> +               ret = pm_generic_resume(dev);
> +
> +       if (ret) {
> +               int j;
> +
> +               for (j = 0; j < i; j++)
> +                       pm_generic_suspend(client->sysmmu[j]);
> +       }
> +
> +       return ret;
> +}
> +#endif
> +
> +#ifdef CONFIG_PM_RUNTIME
> +static void sysmmu_restore_state(struct device *sysmmu)
> +{
> +       struct sysmmu_drvdata *data = dev_get_drvdata(sysmmu);
> +       unsigned long flags;
> +
> +       spin_lock_irqsave(&data->lock, flags);
> +       data->runtime_active = true;
> +       if (is_sysmmu_active(data))
> +               __sysmmu_enable_nocount(data);
> +       spin_unlock_irqrestore(&data->lock, flags);
> +}
> +
> +static void sysmmu_save_state(struct device *sysmmu)
> +{
> +       struct sysmmu_drvdata *data = dev_get_drvdata(sysmmu);
> +       unsigned long flags;
> +
> +       spin_lock_irqsave(&data->lock, flags);
> +       if (is_sysmmu_active(data))
> +               __sysmmu_disable_nocount(data);
> +       data->runtime_active = false;
> +       spin_unlock_irqrestore(&data->lock, flags);
> +}
> +
> +static int sysmmu_pm_genpd_save_state(struct device *dev)
> +{
> +       struct exynos_iommu_client *client = dev->archdata.iommu;
> +       int (*cb)(struct device *__dev);
> +       int i;
> +
> +       if (dev->type && dev->type->pm)
> +               cb = dev->type->pm->runtime_suspend;
> +       else if (dev->class && dev->class->pm)
> +               cb = dev->class->pm->runtime_suspend;
> +       else if (dev->bus && dev->bus->pm)
> +               cb = dev->bus->pm->runtime_suspend;
> +       else
> +               cb = NULL;
> +
> +       if (!cb && dev->driver && dev->driver->pm)
> +               cb = dev->driver->pm->runtime_suspend;
> +
> +       if (cb) {
> +               int ret;
> +
> +               ret = cb(dev);
> +               if (ret)
> +                       return ret;
> +       }
> +
> +       for (i = 0; i < client->num_sysmmu; i++)
> +               sysmmu_save_state(client->sysmmu[i]);
> +
> +       return 0;
> +}
> +
> +static int sysmmu_pm_genpd_restore_state(struct device *dev)
> +{
> +       struct exynos_iommu_client *client = dev->archdata.iommu;
> +       int (*cb)(struct device *__dev);
> +       int i;
> +
> +       if (dev->type && dev->type->pm)
> +               cb = dev->type->pm->runtime_resume;
> +       else if (dev->class && dev->class->pm)
> +               cb = dev->class->pm->runtime_resume;
> +       else if (dev->bus && dev->bus->pm)
> +               cb = dev->bus->pm->runtime_resume;
> +       else
> +               cb = NULL;
> +
> +       if (!cb && dev->driver && dev->driver->pm)
> +               cb = dev->driver->pm->runtime_resume;
> +
> +       for (i = 0; i < client->num_sysmmu; i++)
> +               sysmmu_restore_state(client->sysmmu[i]);
> +
> +       if (cb) {
> +               int ret;
> +               ret = cb(dev);
> +               if (ret) {
> +                       for (i = 0; i < client->num_sysmmu; i++)
> +                               sysmmu_save_state(client->sysmmu[i]);
> +                       return ret;
> +               }
> +       }
> +
> +       return 0;
> +}
> +#endif
> +
> +#ifdef CONFIG_PM_GENERIC_DOMAINS
> +struct gpd_dev_ops sysmmu_devpm_ops = {
> +#ifdef CONFIG_PM_RUNTIME
> +       .save_state = &sysmmu_pm_genpd_save_state,
> +       .restore_state = &sysmmu_pm_genpd_restore_state,
> +#endif
> +#ifdef CONFIG_PM_SLEEP
> +       .suspend = &sysmmu_pm_genpd_suspend,
> +       .resume = &sysmmu_pm_genpd_resume,
> +#endif
> +};
> +#endif /* CONFIG_PM_GENERIC_DOMAINS */
> +
> +static int sysmmu_hook_driver_register(struct notifier_block *nb,
> +                                       unsigned long val,
> +                                       void *p)
> +{
> +       struct device *dev = p;
> +
> +       switch (val) {
> +       case BUS_NOTIFY_BIND_DRIVER:
> +       {
> +               int i = 0;
> +               int size = 0;
> +               const __be32 *phandle;
> +               struct exynos_iommu_client *client;
> +
> +               phandle = of_get_property(dev->of_node, "iommu", &size);
> +               if (!phandle)
> +                       break;
> +
> +               size = size / sizeof(*phandle); /* number of elements */
> +
> +               client = devm_kzalloc(dev, sizeof(*client) * size, GFP_KERNEL);
> +               if (!client) {
> +                       dev_err(dev, "No Memory for exynos_iommu_client\n");
> +                       return -ENOMEM;
> +               }
> +
> +               client->num_sysmmu = size;
> +               client->dev = dev;
> +               INIT_LIST_HEAD(&client->node);
> +               spin_lock_init(&client->lock);
> +
> +               for (i = 0; i < size; i++) {
> +                       struct device_node *np;
> +                       struct platform_device *sysmmu;
> +
> +                       /* this always success: see above of_find_property() */
> +                       np = of_parse_phandle(dev->of_node, "iommu", i);
> +
> +                       sysmmu = of_find_device_by_node(np);
> +                       if (!sysmmu) {
> +                               dev_err(dev,
> +                                       "sysmmu node '%s' is not found\n",
> +                                       np->name);
> +                               break;
> +                       }
> +
> +                       client->sysmmu[i] = &sysmmu->dev;
> +               }
> +
> +               if (i < size) {
> +                       while (--i >= 0)
> +                               of_node_put(client->sysmmu[i]->of_node);
> +                       devm_kfree(dev, client);
> +                       return -ENODEV;
> +               }
> +
> +               i = pm_genpd_add_callbacks(dev, &sysmmu_devpm_ops, NULL);
> +               if (i && (i != -ENOSYS)) {
> +                       dev_err(dev,
> +                               "Failed to register 'dev_pm_ops' for iommu\n");
> +                       devm_kfree(dev, client);
> +                       return i;
> +               }
> +
> +               dev->archdata.iommu = client;
> +               break;
> +       }
> +       case BUS_NOTIFY_BOUND_DRIVER:
> +       {
> +               struct exynos_iommu_client *client = dev->archdata.iommu;
> +               if (dev->archdata.iommu &&
> +                               (!pm_runtime_enabled(dev) ||
> +                                        IS_ERR(dev_to_genpd(dev)))) {
> +                       int i;
> +                       for (i = 0; i < client->num_sysmmu; i++) {
> +                               struct sysmmu_drvdata *data;
> +                               pm_runtime_disable(client->sysmmu[i]);
> +                               data = dev_get_drvdata(client->sysmmu[i]);
> +                               if (!data)
> +                                       continue;
> +                               data->runtime_active =
> +                                       !pm_runtime_enabled(data->sysmmu);
> +                               if (data->runtime_active &&
> +                                               is_sysmmu_active(data))
> +                                       __sysmmu_enable_nocount(data);
> +                       }
> +               }
> +               break;
> +       }
> +       case BUS_NOTIFY_UNBOUND_DRIVER:
> +       {
> +               if (dev->archdata.iommu) {
> +                       __pm_genpd_remove_callbacks(dev, false);
> +
> +                       devm_kfree(dev, dev->archdata.iommu);
> +
> +                       dev->archdata.iommu = NULL;
> +               }
> +               break;
> +       }
> +       } /* switch (val) */
> +
> +       return 0;
> +}
> +
> +static struct notifier_block sysmmu_notifier = {
> +       .notifier_call = &sysmmu_hook_driver_register,
> +};
> +
> +static int __init exynos_iommu_prepare(void)
> +{
> +       return bus_register_notifier(&platform_bus_type, &sysmmu_notifier);
> +}
> +arch_initcall(exynos_iommu_prepare);
> --
> 1.7.2.5
> 



From tomasz.figa at gmail.com  Thu Jul 11 07:41:40 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 11 Jul 2013 13:41:40 +0200
Subject: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on
 Exynos5420
In-Reply-To: <20130711112023.GM24508@sirena.org.uk>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
 <29860116.IF545KsGYb@thinkpad> <20130711112023.GM24508@sirena.org.uk>
Message-ID: <2214161.FSfscAvpna@thinkpad>

On Thursday 11 of July 2013 12:20:23 Mark Brown wrote:
> On Thu, Jul 11, 2013 at 12:43:22PM +0200, Tomasz Figa wrote:
> > On Thursday 11 of July 2013 12:38:24 Padmavathi Venna wrote:
> > > +- samsung,supports-tdm: If the I2S controller supports TDM, then this
> > > flag
> > > +  must be enabled.
> > 
> > I think this should be rather handled by a different compatible value, not
> > a
> This is a bit of a larger project sadly, there was resistance to doing
> the DT bindings based on compatible strings using the IP version :(

I'm not sure if this case is related to this problem in any way. I just 
suggested introducing a new include like samsung,exynos5420-i2s, a opposed to 
using samsung,exynos5250-i2s and adding flags, since the I2S in Exynos5420 is 
the first one to have this TDM or whatever mode. (I'd still like to hear what 
it is...)

Best regards,
Tomasz



From daniel.lezcano at linaro.org  Thu Jul 11 07:53:26 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 11 Jul 2013 13:53:26 +0200
Subject: [PATCH V2] ARM: cpuidle: davinci: Fix target residency
In-Reply-To: <51CD3063.5010309@ti.com>
References: <1372345800-26792-1-git-send-email-daniel.lezcano@linaro.org>
 <51CD3063.5010309@ti.com>
Message-ID: <51DE9CB6.40706@linaro.org>

On 06/28/2013 08:42 AM, Sekhar Nori wrote:
> On 6/27/2013 8:40 PM, Daniel Lezcano wrote:
>> The commit 19976c2a88d125aec16b9255c7197c297bbdd637 changed the target
>> residency to 100000, assuming this is a careless mistake.
>>
>> commit 19976c2a88d125aec16b9255c7197c297bbdd637
>> Author: Robert Lee <rob.lee at linaro.org>
>> Date:   Tue Mar 20 15:22:45 2012 -0500
>>
>>     ARM: davinci: Consolidate time keeping and irq enable
>>
>>     Enable core cpuidle timekeeping and irq enabling and remove that
>>     handling from this code.
>>
>>     Signed-off-by: Robert Lee <rob.lee at linaro.org>
>>     Reviewed-by: Kevin Hilman <khilman at ti.com>
>>     Reviewed-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>>     Acked-by: Jean Pihet <j-pihet at ti.com>
>>     Signed-off-by: Len Brown <len.brown at intel.com>
>>
>> The same happened to the at91's cpuidle driver.
>>
>> Fix it by putting the initial value to 10000.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> 
> Acked-by: Sekhar Nori <nsekhar at ti.com>

Hi Sekhar,

I applied this patch on my tree for the next PM pull request.

Thanks
  -- Daniel



-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From pullip.cho at samsung.com  Thu Jul 11 07:56:02 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Thu, 11 Jul 2013 20:56:02 +0900
Subject: [PATCH v7 6/9] clk: exynos5250: add gate clock descriptions of
 System MMU
In-Reply-To: <CAH=HWYPUJP9NxOgs6Ei+azB5UqiKocMe00+z5i+sD7io8D0g=w@mail.gmail.com>
References: <002e01ce797b$4dc46d20$e94d4760$@samsung.com>
 <CAH=HWYPUJP9NxOgs6Ei+azB5UqiKocMe00+z5i+sD7io8D0g=w@mail.gmail.com>
Message-ID: <000a01ce7e2d$9de742d0$d9b5c870$@samsung.com>

> From: Prathyush K [mailto:prathyush at chromium.org] 
> Sent: Wednesday, July 10, 2013 11:49 PM
> 
> On Fri, Jul 5, 2013 at 5:59 PM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> This adds gate clocks of all System MMUs and their master IPs
> that are not apeared in clk-exynos5250.c
> 
> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> CC: Thomas Abraham <thomas.abraham at linaro.org>
> ---
>  .../devicetree/bindings/clock/exynos5250-clock.txt |   28 +++++++++-
>  drivers/clk/samsung/clk-exynos5250.c               |   57 ++++++++++++++++---
>  2 files changed, 75 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> index 781a627..df49694 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> @@ -154,7 +154,33 @@ clock which they consume.
>    dsim0                        341
>    dp                   342
>    mixer                        343
> -  hdmi                 345
> +  hdmi                 344
> +  camif_top            345
> +  smmu_fimc_lite0      346
> +  smmu_fimc_lite1      347
> +  smmu_fimc_lite2      348
> +  smmu_tv              349
> +  smmu_fimd1           350
> +  smmu_2d              351
> +  fimc_isp             352
> +  fimc_drc             353
> +  fimc_fd              354
> +  fimc_scc             355
> +  fimc_scp             356
> +  fimc_mcuctl          357
> +  fimc_odc             358
> +  fimc_dis             359
> +  fimc_3dnr            360
> +  smmu_fimc_isp                361
> +  smmu_fimc_drc                362
> +  smmu_fimc_fd         363
> +  smmu_fimc_scc                364
> +  smmu_fimc_scp                365
> +  smmu_fimc_mcuctl     366
> +  smmu_fimc_odc                367
> +  smmu_fimc_dis0       368
> +  smmu_fimc_dis1       369
> +  smmu_fimc_3dnr       370
> 
>  Example 1: An example of a clock controller node is listed below.
> 
> diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
> index 22d7699..1921d6c 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -53,12 +53,15 @@
>  #define DIV_PERIC3             0x10564
>  #define DIV_PERIC4             0x10568
>  #define DIV_PERIC5             0x1056c
> +#define GATE_IP_ISP0           0x0C800
> +#define GATE_IP_ISP1           0x0C800
>  #define GATE_IP_GSCL           0x10920
>  #define GATE_IP_MFC            0x1092c
>  #define GATE_IP_GEN            0x10934
>  #define GATE_IP_FSYS           0x10944
>  #define GATE_IP_PERIC          0x10950
>  #define GATE_IP_PERIS          0x10960
> +#define GATE_IP_ACP            0x18800
>  #define SRC_CDREX              0x20200
>  #define PLL_DIV2_SEL           0x20a24
>  #define GATE_IP_DISP1          0x10928
> @@ -100,6 +103,14 @@ enum exynos5250_clks {
>         tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
>         wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
> 
> +       camif_top, smmu_fimc_lite0, smmu_fimc_lite1, smmu_fimc_lite2,
> +       smmu_tv, smmu_fimd1, smmu_2d,
> +       fimc_isp, fimc_drc, fimc_fd, fimc_scc, fimc_scp, fimc_mcuctl, fimc_odc,
> +       fimc_dis, fimc_3dnr,
> +       smmu_fimc_isp, smmu_fimc_drc, smmu_fimc_fd, smmu_fimc_scc,
> +       smmu_fimc_scp, smmu_fimc_mcuctl, smmu_fimc_odc, smmu_fimc_dis0,
> +       smmu_fimc_dis1, smmu_fimc_3dnr,
> +
>         nr_clks,
>  };
> 
> @@ -320,19 +331,26 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
>         GATE(gscl3, "gscl3", "aclk266", GATE_IP_GSCL, 3, 0, 0),
>         GATE(gscl_wa, "gscl_wa", "div_gscl_wa", GATE_IP_GSCL, 5, 0, 0),
>         GATE(gscl_wb, "gscl_wb", "div_gscl_wb", GATE_IP_GSCL, 6, 0, 0),
> -       GATE(smmu_gscl0, "smmu_gscl0", "aclk266", GATE_IP_GSCL, 7, 0, 0),
> -       GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
> -       GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
> -       GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
> +       GATE(smmu_gscl0, "smmu_gscl0", "gscl0", GATE_IP_GSCL, 7, 0, 0),
> +       GATE(smmu_gscl1, "smmu_gscl1", "gscl1", GATE_IP_GSCL, 8, 0, 0),
> +       GATE(smmu_gscl2, "smmu_gscl2", "gscl2", GATE_IP_GSCL, 9, 0, 0),
> +       GATE(smmu_gscl3, "smmu_gscl3", "gscl3", GATE_IP_GSCL, 10, 0, 0),
> +       GATE(camif_top, "camif_top", "aclk266", GATE_IP_GSCL, 4, 0, 0),
> +       GATE(smmu_fimc_lite0, "smmu_fimc_lite0", "camif_top",
> +                                               GATE_IP_GSCL, 12, 0, 0),
> +       GATE(smmu_fimc_lite1, "smmu_fimc_lite1", "camif_top",
> +                                               GATE_IP_GSCL, 13, 0, 0),
> +       GATE(smmu_fimc_lite2, "smmu_fimc_lite2", "camif_top",
> +                                               GATE_IP_GSCL, 14, 0, 0),
>         GATE(mfc, "mfc", "aclk333", GATE_IP_MFC, 0, 0, 0),
> -       GATE(smmu_mfcl, "smmu_mfcl", "aclk333", GATE_IP_MFC, 1, 0, 0),
> -       GATE(smmu_mfcr, "smmu_mfcr", "aclk333", GATE_IP_MFC, 2, 0, 0),
> +       GATE(smmu_mfcl, "smmu_mfcl", "mfc", GATE_IP_MFC, 1, 0, 0),
> +       GATE(smmu_mfcr, "smmu_mfcr", "mfc", GATE_IP_MFC, 2, 0, 0),
> 
> This should be reversed as seen in 5250. The mfcl's control bit is 2 and mfcr's control bit is 1.
> 
Oh. Really it is.
I didn't check it.
I remember that you have pointed that several times already. :)

> Why is the parent of the smmu_mfc set as "mfc"? Is this a required hierarchy in the clocks?
> Even I noticed that we need to turn on MFC's clock to be able to access smmu_mfc's registers.
> But I don't think setting mfc as parent of smmu_mfc is the correct solution since this results in MFC not getting clock gated
during video playback.
> 
> Beginning of playback:
> Turn on SYSMMU:
> MFC Sysmmu clock: +1
> MFC clock: +1
> 
> During video playback, dynamic clock gating of MFC:
> Turn on MFC (before frame decode)
> MFC Sysmmu clock: +1
> MFC clock: +2
> 
> Turn off MFC (after frame decode)
> MFC Sysmmu clock: +1
> MFC clock: +1
> 
> End of playback:
> Turn off SYSMMU:
> MFC Sysmmu clock: 0 (gated)
> MFC clock: 0 (gated)
> 
> As can be seen, MFC's dynamic clock gating between frames never works since the sysmmu has already turned on the clock.
> 
> A better way is to pass the mmu-master's clock through the device node (optional parameter).
> If the parent device's clock is present in the sysmmu node, we turn ON/OFF this clock before/after we access any sysmmu registers
> E.g. before/after TLB invalidation.
> 
> What do you think?
> 

Hmm,, it is also a good idea to handle master's clock explicitly
Master's clock is already passed to the System MMU driver if it is required
via dts.
Please let me think about it again

Thank you.

Cho KyongHo.



From rogerq at ti.com  Thu Jul 11 08:00:34 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 11 Jul 2013 15:00:34 +0300
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51DE8CBB.4000709@denx.de>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de> <51DE87D3.5030600@ti.com>
 <51DE8CBB.4000709@denx.de>
Message-ID: <51DE9E62.9080406@ti.com>

On 07/11/2013 01:45 PM, Stefan Roese wrote:
> Hi Roger,
> 
> On 07/11/2013 12:24 PM, Roger Quadros wrote:
>> Stefan,
>>
>> I tried it out today and it worked 5/5 times. I used a bare bones
>> debian root filesystem for
>> the NFS root.
> 
> Thanks for testing.
> 
>> Could it be possible that the boot scripts on your filesystem are
>> somehow shutting down
>> the ethernet interface? Might be worth checking on a fresh filesystem.
> 
> I'm pretty sure that its not a problem with the filesystem. I'm using
> exactly this filesystem for multiple other ARM based boards as well.
> And all other boards (most of them with buildin ethernet controller
> instead of USB connected) have no problem mounting/booting from it.

OK, then it might be something to do with beagle.
Is pandaboard working fine for you?

> 
> BTW: The filesystem is from the ELDK 5.3 [1][2]. You could download/install
> it yourself.

OK. Will give it a try.
> 
> From your log I can see, that you are using a slightly different board
> than I am ("Beagle xM Rev C" vs. "Beagle Rev C1/C2/C3"). So its a

My board is a C2.

> different OMAP variant. Could this perhaps make a difference? Do you
> by chance have the "old" Beagleboard (non-xM) at hand for another test?

Sure. I have the old beagleboard with me. Let me know what to test.

cheers,
-roger


From festevam at gmail.com  Thu Jul 11 08:14:30 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 11 Jul 2013 09:14:30 -0300
Subject: imx25: How to get frame buffer device in a system using device
 tree
In-Reply-To: <CAO8h3eHiXroFWy2na-05MeHgfSg9LGuxMF4wkf4VwFsV57xDnw@mail.gmail.com>
References: <CAO8h3eFq9WhvZYbbeFfWgVEXViR8MAcGaztsvvaLpFSW-W6CfA@mail.gmail.com>
 <CAOMZO5Aat-iAN_TJ6BXEopB+WCkKgLjWh67sCXg0jd1DtzmKSQ@mail.gmail.com>
 <CAO8h3eHAfV808izZzvpPc+z6iQPr14q8OmryNs5sC+VcNk+iLg@mail.gmail.com>
 <CAOMZO5CgAs+hR41=WdJ=jxS5gZf=opOrCXufixBh_CMP0n2TFA@mail.gmail.com>
 <CAO8h3eGhF8DRO73W9GkepUKAF-6v1EmWdMS_Gq+dA_2v5mJ2aQ@mail.gmail.com>
 <CAOMZO5CrZjDZjqaaQTX4=ZGO_6chFMr9qAHhqyVGBdxBvimYSw@mail.gmail.com>
 <CAO8h3eHiXroFWy2na-05MeHgfSg9LGuxMF4wkf4VwFsV57xDnw@mail.gmail.com>
Message-ID: <CAOMZO5C9-o=E_jBub-YAYJ+j8ienE_-krykOm-KcjSuzq_BioQ@mail.gmail.com>

On Thu, Jul 11, 2013 at 3:28 AM, Matthias Wei?er <m.weisser.m at gmail.com> wrote:

>> Great, care to submit patches for adding mx25 fb support?
>
> I can. But I think the only thing is the slightly changed
> arch/arm/boot/dts/imx25.dtsi. Patch to this mailing list? Patch
> against mainline kernel is OK?

Yes, you should generate the patch against Shawn's for-next branch:
http://git.linaro.org/gitweb?p=people/shawnguo/linux-2.6.git;a=shortlog;h=refs/heads/for-next

Then send the patch to him with the linux-arm-kernel list on Cc.

Regards,

Fabio Estevam


From jonas.jensen at gmail.com  Thu Jul 11 08:29:46 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Thu, 11 Jul 2013 14:29:46 +0200
Subject: [PATCH] watchdog: Add MOXA ART watchdog driver
Message-ID: <1373545786-7151-1-git-send-email-jonas.jensen@gmail.com>

Add watchdog driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130711

 drivers/watchdog/Kconfig      |  10 +++
 drivers/watchdog/Makefile     |   1 +
 drivers/watchdog/moxart_wdt.c | 190 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 201 insertions(+)
 create mode 100644 drivers/watchdog/moxart_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 362085d..6883aab 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -382,6 +382,16 @@ config RETU_WATCHDOG
 	  To compile this driver as a module, choose M here: the
 	  module will be called retu_wdt.
 
+config MOXART_WDT
+	tristate "MOXART watchdog"
+	depends on ARCH_MOXART
+	help
+	  Say Y here to include Watchdog timer support for the watchdog
+	  existing on the MOXA ART SoC series platforms.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called moxart_wdt.
+
 # AVR32 Architecture
 
 config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 2f26a0b..7cab53a 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
 obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
 obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
 obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
+obj-$(CONFIG_MOXART_WDT) += moxart_wdt.o
 
 # AVR32 Architecture
 obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
new file mode 100644
index 0000000..c6c00bf
--- /dev/null
+++ b/drivers/watchdog/moxart_wdt.c
@@ -0,0 +1,190 @@
+/*
+ * MOXA ART SoCs watchdog driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+#include <linux/watchdog.h>
+
+#include <asm/system_misc.h>
+
+#define REG_COUNT			0x4
+#define REG_MODE			0x8
+#define REG_ENABLE			0xC
+
+struct moxart_wdt_dev {
+	struct watchdog_device wdt_dev;
+	void __iomem *wdt_base;
+};
+
+static struct moxart_wdt_dev *moxart_wdt;
+static bool nowayout = WATCHDOG_NOWAYOUT;
+static int heartbeat;
+static unsigned int clock_frequency;
+static unsigned int max_timeout;
+
+static void moxart_wdt_restart(enum reboot_mode reboot_mode, const char *cmd)
+{
+	writel(1, moxart_wdt->wdt_base + REG_COUNT);
+	writel(0x5ab9, moxart_wdt->wdt_base + REG_MODE);
+	writel(0x03, moxart_wdt->wdt_base + REG_ENABLE);
+}
+
+static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+	void __iomem *wdt_base = moxart_wdt->wdt_base;
+
+	writel(0, wdt_base + REG_ENABLE);
+
+	return 0;
+}
+
+static int moxart_wdt_start(struct watchdog_device *wdt_dev)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+	void __iomem *wdt_base = moxart_wdt->wdt_base;
+
+	writel(clock_frequency * moxart_wdt->wdt_dev.timeout,
+	       wdt_base + REG_COUNT);
+	writel(0x5ab9, wdt_base + REG_MODE);
+	writel(0x03, wdt_base + REG_ENABLE);
+
+	return 0;
+}
+
+static int moxart_wdt_ping(struct watchdog_device *wdt_dev)
+{
+	moxart_wdt_start(wdt_dev);
+	return 0;
+}
+
+static int moxart_wdt_set_timeout(struct watchdog_device *wdt_dev,
+				  unsigned int timeout)
+{
+	dev_dbg(wdt_dev->dev, "%s: timeout=%u\n", __func__, timeout);
+
+	if (timeout > max_timeout)
+		return -EINVAL;
+
+	moxart_wdt->wdt_dev.timeout = timeout;
+
+	return 0;
+}
+
+static const struct watchdog_info moxart_wdt_info = {
+	.identity       = "moxart-wdt",
+	.options        = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
+static const struct watchdog_ops moxart_wdt_ops = {
+	.owner          = THIS_MODULE,
+	.start          = moxart_wdt_start,
+	.stop           = moxart_wdt_stop,
+	.ping           = moxart_wdt_ping,
+	.set_timeout    = moxart_wdt_set_timeout,
+};
+
+static int moxart_wdt_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct resource *res;
+	struct clk *clk;
+	int err;
+
+	moxart_wdt = devm_kzalloc(&pdev->dev, sizeof(*moxart_wdt), GFP_KERNEL);
+	if (!moxart_wdt)
+		return -EINVAL;
+
+	platform_set_drvdata(pdev, moxart_wdt);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	moxart_wdt->wdt_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_wdt->wdt_base))
+		return PTR_ERR(moxart_wdt->wdt_base);
+
+	arm_pm_restart = moxart_wdt_restart;
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk)) {
+		pr_err("%s: of_clk_get failed\n", __func__);
+		return PTR_ERR(clk);
+	}
+
+	clock_frequency = clk_get_rate(clk);
+
+	max_timeout = UINT_MAX / clock_frequency;
+
+	moxart_wdt->wdt_dev.info = &moxart_wdt_info;
+	moxart_wdt->wdt_dev.ops = &moxart_wdt_ops;
+	moxart_wdt->wdt_dev.timeout = max_timeout;
+	moxart_wdt->wdt_dev.min_timeout = 1;
+	moxart_wdt->wdt_dev.max_timeout = max_timeout;
+	moxart_wdt->wdt_dev.parent = &pdev->dev;
+
+	watchdog_init_timeout(&moxart_wdt->wdt_dev, heartbeat, &pdev->dev);
+	watchdog_set_nowayout(&moxart_wdt->wdt_dev, nowayout);
+
+	watchdog_set_drvdata(&moxart_wdt->wdt_dev, moxart_wdt);
+
+	err = watchdog_register_device(&moxart_wdt->wdt_dev);
+	if (unlikely(err))
+		return err;
+
+	dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
+		 moxart_wdt->wdt_dev.timeout, nowayout);
+
+	return 0;
+}
+
+static int moxart_wdt_remove(struct platform_device *pdev)
+{
+	struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
+
+	watchdog_unregister_device(&moxart_wdt->wdt_dev);
+	watchdog_set_drvdata(&moxart_wdt->wdt_dev, NULL);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_watchdog_match[] = {
+	{ .compatible = "moxa,moxart-watchdog" },
+	{ },
+};
+
+static struct platform_driver moxart_wdt_driver = {
+	.probe      = moxart_wdt_probe,
+	.remove     = moxart_wdt_remove,
+	.driver     = {
+		.name		= "moxart-watchdog",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_watchdog_match,
+	},
+};
+module_platform_driver(moxart_wdt_driver);
+
+module_param(heartbeat, int, 0);
+MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");
+
+MODULE_DESCRIPTION("MOXART watchdog driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From sr at denx.de  Thu Jul 11 08:33:23 2013
From: sr at denx.de (Stefan Roese)
Date: Thu, 11 Jul 2013 14:33:23 +0200
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51DE9E62.9080406@ti.com>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de> <51DE87D3.5030600@ti.com>
 <51DE8CBB.4000709@denx.de> <51DE9E62.9080406@ti.com>
Message-ID: <51DEA613.3010209@denx.de>

On 07/11/2013 02:00 PM, Roger Quadros wrote:
>>> Could it be possible that the boot scripts on your filesystem are
>>> somehow shutting down
>>> the ethernet interface? Might be worth checking on a fresh filesystem.
>>
>> I'm pretty sure that its not a problem with the filesystem. I'm using
>> exactly this filesystem for multiple other ARM based boards as well.
>> And all other boards (most of them with buildin ethernet controller
>> instead of USB connected) have no problem mounting/booting from it.
> 
> OK, then it might be something to do with beagle.
> Is pandaboard working fine for you?

I don't have a pandaboard here. Sorry. Only a another OMAP3530-based
board which also fails to boot via NFS.

>> BTW: The filesystem is from the ELDK 5.3 [1][2]. You could download/install
>> it yourself.
> 
> OK. Will give it a try.
>>
>> From your log I can see, that you are using a slightly different board
>> than I am ("Beagle xM Rev C" vs. "Beagle Rev C1/C2/C3"). So its a
> 
> My board is a C2.

Mine too.

>> different OMAP variant. Could this perhaps make a difference? Do you
>> by chance have the "old" Beagleboard (non-xM) at hand for another test?
> 
> Sure. I have the old beagleboard with me. Let me know what to test.

Either your debian rootfs via NFS or the ELDK one. As you have done with
the Beagle-xM. And then please repeat the NFS booting (if successful)
again for at least 5 times. Or even better, setup the bootcmd to
autoboot via NFS and tune your NFS rootfs to reboot automatically. So a
hangup in NFS booting would be noticed after some time with this board
automatically rebooting.

Thanks,
Stefan



From sr at denx.de  Thu Jul 11 08:41:21 2013
From: sr at denx.de (Stefan Roese)
Date: Thu, 11 Jul 2013 14:41:21 +0200
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51DE87D3.5030600@ti.com>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de> <51DE87D3.5030600@ti.com>
Message-ID: <51DEA7F1.1050902@denx.de>

On 07/11/2013 12:24 PM, Roger Quadros wrote:
> My u-boot script is below and boot log is attached.

BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
Do you have any patches locally applied to the kernel.org version that
might be helpful with this USB issue I'm seeing?

Thanks,
Stefan



From broonie at kernel.org  Thu Jul 11 09:01:39 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 11 Jul 2013 14:01:39 +0100
Subject: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on
 Exynos5420
In-Reply-To: <2214161.FSfscAvpna@thinkpad>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
 <29860116.IF545KsGYb@thinkpad>
 <20130711112023.GM24508@sirena.org.uk>
 <2214161.FSfscAvpna@thinkpad>
Message-ID: <20130711130139.GQ24508@sirena.org.uk>

On Thu, Jul 11, 2013 at 01:41:40PM +0200, Tomasz Figa wrote:
> On Thursday 11 of July 2013 12:20:23 Mark Brown wrote:

> > This is a bit of a larger project sadly, there was resistance to doing
> > the DT bindings based on compatible strings using the IP version :(

> I'm not sure if this case is related to this problem in any way. I just 
> suggested introducing a new include like samsung,exynos5420-i2s, a opposed to 
> using samsung,exynos5250-i2s and adding flags, since the I2S in Exynos5420 is 

Well, it *should* be samsung,i2s-vN where N is the version number of the
IP but documentation on the versioning has been patchy hence this whole
thinng.

> the first one to have this TDM or whatever mode. (I'd still like to hear what 
> it is...)

What it *should* be is the option to send more than one audio stream
down a link using time division multiplexing.
-------------- 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/20130711/36342c14/attachment.sig>

From b.zolnierkie at samsung.com  Thu Jul 11 09:14:49 2013
From: b.zolnierkie at samsung.com (Bartlomiej Zolnierkiewicz)
Date: Thu, 11 Jul 2013 15:14:49 +0200
Subject: [PATCH 1/3] ARM: EXYNOS: remove non-working AFTR mode support
In-Reply-To: <51CE0485.8020109@linaro.org>
References: <1372241627-22695-1-git-send-email-b.zolnierkie@samsung.com>
 <2484012.IH9WOi4iIR@amdc1032> <51CE0485.8020109@linaro.org>
Message-ID: <5509794.32CckI9OQ8@amdc1032>


Hi,

On Friday, June 28, 2013 11:47:49 PM Daniel Lezcano wrote:
> On 06/28/2013 06:27 PM, Bartlomiej Zolnierkiewicz wrote:
> > On Friday, June 28, 2013 01:20:09 PM Daniel Lezcano wrote:
> >> On 06/28/2013 12:11 PM, Tomasz Figa wrote:
> >>> Hi Daniel,
> >>>
> >>> I've been fighting with this whole AFTR state as well, before Bartlomiej. 
> >>> Let me share my thoughts on this.
> >>>
> 
> [ ... ]
> 
> >>>
> >>> If you don't unplug all the CPUs >0 the state is obviously never reached. 
> >>> Otherwise the whole system hangs after it tries to enter this mode without 
> >>> any reaction for external events, other than reset.
> >>
> >> Need investigation.
> >>
> >> What is the exynos board version where that occurs ?
> > 
> > Could you please tell me what exactly do you mean by that?
> > 
> > I already wrote that we can reproduce the problem on EXYNOS4210 rev0
> > and rev1.1 (we don't have rev1.0). Tomek has also reproduced the problem
> > on some later SoCs (I hope that he can give you exact revisions).
> > 
> > In our testing we didn't encounter the board on which the problem
> > doesn't occur. Our current working theory is that the problem may be
> > u-boot (or first stage bootloader) related.
> 
> Ok, the status for what I know:
> 
> Origen Exynos4210, board ver A: works for me
> Arndale Exynos5250: works for me but only if u-boot does not enable the
> hypervisor mode.
> Chromebook Exynos5250: works for me

I've also done some more testing. First I tested on some Exynos4412 devices
(M0 and SLP_PQ) and AFTR was not working on them. Then I got my hands on
Origen Exynos4210 (thanks to Tomek Figa for providing it) and AFTR is working
just fine on it. Finally I tried Trats board again but with the upstream
u-boot instead of our custom modified version (thanks to help from Lukasz
Majewski) and I found out that after this change AFTR works fine on it! It
also gives quite nice power savings (~80mA less current drawn in AFTR mode
compared to just WFI one).

With the above findings it now seems that the issue is on our side and is
outside the kernel. Thanks for help with narrowing down the problem and
sorry for wasting your time.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> I found the following drivers:
> 
> https://github.com/AndreiLux/Perseus-UNIVERSAL5410/blob/samsung/arch/arm/mach-exynos/cpuidle.c
> 
> https://github.com/CyanogenMod/hardkernel-kernel-4412/blob/cm-10.1/arch/arm/mach-exynos/cpuidle-exynos4.c
> 
> Sounds like the num cpus > 1 is still there.
> 
> [ ... ]
> 
> >> The kernel is not a playground where you can upstream code and then
> >> remove it because a feature seems broken and you don't have an idea of why.
> > 
> > Neither me or Tomek did upstream this code and we couldn't react in
> > time because we haven't noticed that it is completely unusable for us
> > as EXYNOS cpuidle driver is not even used by default on EXYNOS (it is
> > not enabled either in defconfig or Kconfig).
> > 
> > Moreover the feature we are talking about (AFTR mode) is also not used
> > by default (except EXYNOS4210 rev0 on which it lockups system for us)
> > even with EXYNOS cpuidle driver being enabled (because this specific
> > feature depends on CPU hot-unplug which is not done automatically right
> > now).
> > 
> > Such things like unused/broken code removal is not something very
> > unusual in the upstream kernel (I'm speaking from the experience here
> > having maintained large subsystem for a couple of years). In this
> > particular case we are talking about ~130 lines of code which can
> > be trivially brought back later when/if needed.
> > 
> > Anyway if the code removal is controversial for you we can just disable
> > AFTR mode by default and enable it only when special command line option
> > is given (i.e. "aftr"). This would fix all the broken configuration
> > while still allowing the feature to be enabled on systems that had it
> > working previously (since you claim that it works on some chipset/u-boot
> > configurations).
> 
> Actually, there are several reasons I am not in favor for the moment to
> remove this code:
> 
> 1) code can't be pushed upstream and then removed so easily
> 2) I asked several times what was this cpu1 hack, I had no answer
> 3) I tried to make both cpus entering the AFTR state, but the cpu1 never
> wakes up, I asked but no answer.
> 
> I would like to have some answers :)
> 
> Before taking the decision to remove this state (btw you can remove the
> driver directly, no ? the default idle function is WFI), IMO it is worth
> to investigate and to spend some time to clarify what is happening. Then
> we can take a decision.
> 
> I am willing to help.
> 
> >> I asked several times the reasons of why the AFTR state couldn't work
> >> with multiple CPUs and I had no answer.
> > 
> > Unfortunately I don't know the answer for your question.
> > 
> > The AFTR mode doesn't work for us *at*all* (even with *one* CPU).
> > 
> >> Frankly speaking I have a couple of hypothesis:
> >>
> >> 1. something is not correctly setup and the PMU does not wake up the CPU1
> >> 2. there is a silicon bug and no one wants to tell it is the case
> >>
> >> In any case, this must be investigated and identified. And then we can
> >> take a decision about this state.
> > 
> > I don't have good idea currently how to investigate it further.
> > 
> > I also don't have any prove that the actual work is worth it
> > (and this work can easily take some weeks).
> > 
> > One of main responsibilities of the maintainer it to make sure that
> > the code does indeed work and that regressions (like these caused by
> > AFTR mode feature) are fixed in the timely manner, not let the code
> > sit in the limbo state for large periods of time.  It is already very
> > bad situation that the regression we are hitting was present since
> > v3.4 and we are in v3.10 now, I would like to have it fixed ASAP so
> > we may actually consider enabling cpuidle in our exynos_defconfig.
> 
> I agree.
> 
> Thanks
>   -- Daniel



From balbi at ti.com  Thu Jul 11 09:28:18 2013
From: balbi at ti.com (Felipe Balbi)
Date: Thu, 11 Jul 2013 16:28:18 +0300
Subject: [PATCH 0/2] Fix omap serial early crash during hwmod _setup()
In-Reply-To: <1373539986-27272-1-git-send-email-rnayak@ti.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
Message-ID: <20130711132818.GE30970@arwen.pp.htv.fi>

On Thu, Jul 11, 2013 at 04:23:03PM +0530, Rajendra Nayak wrote:
> This series should fix the issue with the early serial crash seen
> during hwmod _setup() as reported by [1]
> 
> The issue was reported on a am33xx device and was not seen on omap4
> or omap5 devices as the hwmod data for both omap4 and omap5 had
> statically defined HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET for
> uart3 which happens to be the debug console used on omap4 panda and
> omap5 uevm boards.
> 
> The series reverts the patch which stubbed out omap_serial_early_init()
> for DT boot and gets rid of the static flags in omap4 and omap5 hwmod
> data.
> 
> This series along with the patch posted by Felipe [2] should fix the
> issue reported by [1] completely and boot to prompt on a am33xx device
> with LL_DEBUG enabled.
> 
> I have boot tested this series (along with [2]) on a omap4 panda es and
> a am335x boneblack.
> 
> [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/100628
> 
> [2] http://marc.info/?l=linux-omap&m=137353783912736&w=2
> 
> Rajendra Nayak (2):
>   Revert "ARM: OMAP2+: Fix serial init for device tree based booting"
>   ARM: OMAP4+: Get rid of the HWMOD_INIT_NO_IDLE and
>     HWMOD_INIT_NO_RESET flags for uart

boot tested on omap4-panda rev a3. Console still works and it suspends
and resumes fine after setting a proper timeout.

Tested-by: Felipe Balbi <balbi at ti.com>

-- 
balbi
-------------- 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/20130711/b7de8f7f/attachment.sig>

From jonas.jensen at gmail.com  Thu Jul 11 09:51:51 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Thu, 11 Jul 2013 15:51:51 +0200
Subject: [PATCH v2] rtc: Add MOXA ART RTC driver
In-Reply-To: <1373464848-28146-1-git-send-email-jonas.jensen@gmail.com>
References: <1373464848-28146-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1373550711-18828-1-git-send-email-jonas.jensen@gmail.com>

Add RTC driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Thanks for the review Mark, what you said should be
    fixed in v2.
    
    Applies to next-20130711
    
    Changes since v1:
    
    1. remove defines GPIO_EM1240_HIGH and GPIO_EM1240_LOW
    2. rename struct "rtc_plat_data" "moxart_rtc"
    3. move rtc_lock to struct moxart_rtc
    4. add delay after setting GPIO high
    5. remove moxart_rtc_ioctl
    6. use devm_gpio_request instead of gpio_request
    7. remove explicit devm_kfree
    8. change Makefile list order

 drivers/rtc/Kconfig      |   9 ++
 drivers/rtc/Makefile     |   1 +
 drivers/rtc/rtc-moxart.c | 316 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 326 insertions(+)
 create mode 100644 drivers/rtc/rtc-moxart.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 9e3498b..9654aa3 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1249,6 +1249,15 @@ config RTC_DRV_SIRFSOC
 	  Say "yes" here to support the real time clock on SiRF SOC chips.
 	  This driver can also be built as a module called rtc-sirfsoc.
 
+config RTC_DRV_MOXART
+	tristate "MOXA ART RTC"
+	help
+	   If you say yes here you get support for the MOXA ART
+	   RTC module.
+
+	   This driver can also be built as a module. If so, the module
+	   will be called rtc-moxart
+
 comment "HID Sensor RTC drivers"
 
 config RTC_DRV_HID_SENSOR_TIME
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index d3b4488..2dff3d2 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -130,3 +130,4 @@ obj-$(CONFIG_RTC_DRV_WM831X)	+= rtc-wm831x.o
 obj-$(CONFIG_RTC_DRV_WM8350)	+= rtc-wm8350.o
 obj-$(CONFIG_RTC_DRV_X1205)	+= rtc-x1205.o
 obj-$(CONFIG_RTC_DRV_SIRFSOC)	+= rtc-sirfsoc.o
+obj-$(CONFIG_RTC_DRV_MOXART)	+= rtc-moxart.o
diff --git a/drivers/rtc/rtc-moxart.c b/drivers/rtc/rtc-moxart.c
new file mode 100644
index 0000000..dd8615e
--- /dev/null
+++ b/drivers/rtc/rtc-moxart.c
@@ -0,0 +1,316 @@
+/*
+ * MOXA ART RTC driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/rtc.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/gpio.h>
+
+#define GPIO_EM1240_OUTPUT			1
+#define GPIO_EM1240_INPUT			0
+
+#define GPIO_RTC_SCLK				(5)
+#define GPIO_RTC_DATA				(6)
+#define GPIO_RTC_RESET				(7)
+
+#define GPIO_RTC_RESERVED			0x0C
+#define GPIO_RTC_DATA_SET			0x10
+#define GPIO_RTC_DATA_CLEAR			0x14
+#define GPIO_RTC_PIN_PULL_ENABLE		0x18
+#define GPIO_RTC_PIN_PULL_TYPE			0x1C
+#define GPIO_RTC_INT_ENABLE			0x20
+#define GPIO_RTC_INT_RAW_STATE			0x24
+#define GPIO_RTC_INT_MASKED_STATE		0x28
+#define GPIO_RTC_INT_MASK			0x2C
+#define GPIO_RTC_INT_CLEAR			0x30
+#define GPIO_RTC_INT_TRIGGER			0x34
+#define GPIO_RTC_INT_BOTH			0x38
+#define GPIO_RTC_INT_RISE_NEG			0x3C
+#define GPIO_RTC_BOUNCE_ENABLE			0x40
+#define GPIO_RTC_BOUNCE_PRE_SCALE		0x44
+
+#define GPIO_RTC_PROTECT_W			0x8E
+#define GPIO_RTC_PROTECT_R			0x8F
+#define GPIO_RTC_YEAR_W				0x8C
+#define GPIO_RTC_YEAR_R				0x8D
+#define GPIO_RTC_DAY_W				0x8A
+#define GPIO_RTC_DAY_R				0x8B
+#define GPIO_RTC_MONTH_W			0x88
+#define GPIO_RTC_MONTH_R			0x89
+#define GPIO_RTC_DATE_W				0x86
+#define GPIO_RTC_DATE_R				0x87
+#define GPIO_RTC_HOURS_W			0x84
+#define GPIO_RTC_HOURS_R			0x85
+#define GPIO_RTC_MINUTES_W			0x82
+#define GPIO_RTC_MINUTES_R			0x83
+#define GPIO_RTC_SECONDS_W			0x80
+#define GPIO_RTC_SECONDS_R			0x81
+#define GPIO_RTC_DELAY_TIME			8	/* 8 usecond */
+#define GPIO_RTC_IS_OPEN			0x01	/* /dev/rtc in use */
+#define GPIO_PIO(x)				(1 << x)
+
+struct moxart_rtc {
+	struct rtc_device *rtc;
+	spinlock_t rtc_lock;
+};
+
+static int day_of_year[12] =	{ 0, 31, 59, 90, 120, 151, 181,
+				  212, 243, 273, 304, 334 };
+
+void moxart_rtc_write_byte(u8 data)
+{
+	int i;
+
+	for (i = 0; i < 8; i++, data >>= 1) {
+		gpio_set_value(GPIO_RTC_SCLK, 0);
+		gpio_set_value(GPIO_RTC_DATA, ((data & 1) == 1));
+		udelay(GPIO_RTC_DELAY_TIME);
+		gpio_set_value(GPIO_RTC_SCLK, 1);
+		udelay(GPIO_RTC_DELAY_TIME);
+	}
+}
+
+u8 moxart_rtc_read_byte(void)
+{
+	int i;
+	u8 data = 0;
+
+	for (i = 0; i < 8; i++) {
+		gpio_set_value(GPIO_RTC_SCLK, 0);
+		udelay(GPIO_RTC_DELAY_TIME);
+		gpio_set_value(GPIO_RTC_SCLK, 1);
+		udelay(GPIO_RTC_DELAY_TIME);
+		if (gpio_get_value(GPIO_RTC_DATA))
+			data |= (1 << i);
+		udelay(GPIO_RTC_DELAY_TIME);
+	}
+	return data;
+}
+
+static u8 moxart_rtc_read_register(u8 cmd)
+{
+	u8 data;
+	unsigned long flags;
+
+	local_irq_save(flags);
+
+	gpio_direction_output(GPIO_RTC_DATA, 0);
+	gpio_set_value(GPIO_RTC_RESET, 1);
+	udelay(GPIO_RTC_DELAY_TIME);
+	moxart_rtc_write_byte(cmd);
+	gpio_direction_input(GPIO_RTC_DATA);
+	udelay(GPIO_RTC_DELAY_TIME);
+	data = moxart_rtc_read_byte();
+	gpio_set_value(GPIO_RTC_SCLK, 0);
+	gpio_set_value(GPIO_RTC_RESET, 0);
+	udelay(GPIO_RTC_DELAY_TIME);
+
+	local_irq_restore(flags);
+
+	return data;
+}
+
+static void moxart_rtc_write_register(u8 cmd, u8 data)
+{
+	unsigned long flags;
+
+	local_irq_save(flags);
+
+	gpio_direction_output(GPIO_RTC_DATA, 0);
+	gpio_set_value(GPIO_RTC_RESET, 1);
+	udelay(GPIO_RTC_DELAY_TIME);
+	moxart_rtc_write_byte(cmd);
+	moxart_rtc_write_byte(data);
+	gpio_set_value(GPIO_RTC_SCLK, 0);
+	gpio_set_value(GPIO_RTC_RESET, 0);
+	udelay(GPIO_RTC_DELAY_TIME);
+
+	local_irq_restore(flags);
+}
+
+static int moxart_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+	struct moxart_rtc *moxart_rtc = dev_get_drvdata(dev);
+
+	spin_lock_irq(&moxart_rtc->rtc_lock);
+
+	moxart_rtc_write_register(GPIO_RTC_PROTECT_W, 0);
+	moxart_rtc_write_register(GPIO_RTC_YEAR_W,
+				  (((tm->tm_year - 100) / 10) << 4) |
+				  ((tm->tm_year - 100) % 10));
+
+	moxart_rtc_write_register(GPIO_RTC_MONTH_W,
+				  (((tm->tm_mon + 1) / 10) << 4) |
+				  ((tm->tm_mon + 1) % 10));
+
+	moxart_rtc_write_register(GPIO_RTC_DATE_W,
+				  ((tm->tm_mday / 10) << 4) |
+				  (tm->tm_mday % 10));
+
+	moxart_rtc_write_register(GPIO_RTC_HOURS_W,
+				  ((tm->tm_hour / 10) << 4) |
+				  (tm->tm_hour % 10));
+
+	moxart_rtc_write_register(GPIO_RTC_MINUTES_W,
+				  ((tm->tm_min / 10) << 4) |
+				  (tm->tm_min % 10));
+
+	moxart_rtc_write_register(GPIO_RTC_SECONDS_W,
+				  ((tm->tm_sec / 10) << 4) |
+				  (tm->tm_sec % 10));
+
+	moxart_rtc_write_register(GPIO_RTC_PROTECT_W, 0x80);
+
+	spin_unlock_irq(&moxart_rtc->rtc_lock);
+
+	dev_dbg(dev, "%s: success tm_year=%d tm_mon=%d\n"
+		"tm_mday=%d tm_hour=%d tm_min=%d tm_sec=%d\n",
+		__func__, tm->tm_year, tm->tm_mon, tm->tm_mday,
+		tm->tm_hour, tm->tm_min, tm->tm_sec);
+
+	return 0;
+}
+
+static int moxart_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+	struct moxart_rtc *moxart_rtc = dev_get_drvdata(dev);
+	unsigned char v;
+
+	spin_lock_irq(&moxart_rtc->rtc_lock);
+
+	v = moxart_rtc_read_register(GPIO_RTC_SECONDS_R);
+	tm->tm_sec = (((v & 0x70) >> 4) * 10) + (v & 0x0F);
+
+	v = moxart_rtc_read_register(GPIO_RTC_MINUTES_R);
+	tm->tm_min = (((v & 0x70) >> 4) * 10) + (v & 0x0F);
+
+	v = moxart_rtc_read_register(GPIO_RTC_HOURS_R);
+	if (v & 0x80) { /* 12-hour mode */
+		tm->tm_hour = (((v & 0x10) >> 4) * 10) + (v & 0x0F);
+		if (v & 0x20) { /* PM mode */
+			tm->tm_hour += 12;
+			if (tm->tm_hour >= 24)
+				tm->tm_hour = 0;
+		}
+	} else { /* 24-hour mode */
+		tm->tm_hour = (((v & 0x30) >> 4) * 10) + (v & 0x0F);
+	}
+
+	v = moxart_rtc_read_register(GPIO_RTC_DATE_R);
+	tm->tm_mday = (((v & 0x30) >> 4) * 10) + (v & 0x0F);
+
+	v = moxart_rtc_read_register(GPIO_RTC_MONTH_R);
+	tm->tm_mon = (((v & 0x10) >> 4) * 10) + (v & 0x0F);
+	tm->tm_mon--;
+
+	v = moxart_rtc_read_register(GPIO_RTC_YEAR_R);
+	tm->tm_year = (((v & 0xF0) >> 4) * 10) + (v & 0x0F);
+	tm->tm_year += 100;
+	if (tm->tm_year <= 69)
+		tm->tm_year += 100;
+
+	v = moxart_rtc_read_register(GPIO_RTC_DAY_R);
+	tm->tm_wday = (v & 0x0f) - 1;
+	tm->tm_yday = day_of_year[tm->tm_mon];
+	tm->tm_yday += (tm->tm_mday - 1);
+	if (tm->tm_mon >= 2) {
+		if (!(tm->tm_year % 4) && (tm->tm_year % 100))
+			tm->tm_yday++;
+	}
+
+	tm->tm_isdst = 0;
+
+	spin_unlock_irq(&moxart_rtc->rtc_lock);
+
+	return 0;
+}
+
+static const struct rtc_class_ops moxart_rtc_ops = {
+	.read_time	= moxart_rtc_read_time,
+	.set_time	= moxart_rtc_set_time,
+};
+
+static int moxart_rtc_probe(struct platform_device *pdev)
+{
+	struct moxart_rtc *moxart_rtc;
+	int ret = 0;
+
+	moxart_rtc = devm_kzalloc(&pdev->dev, sizeof(*moxart_rtc), GFP_KERNEL);
+	if (!moxart_rtc) {
+		dev_err(&pdev->dev, "devm_kzalloc failed\n");
+		return -ENOMEM;
+	}
+
+	spin_lock_init(&moxart_rtc->rtc_lock);
+	platform_set_drvdata(pdev, moxart_rtc);
+
+	devm_gpio_request(&pdev->dev, GPIO_RTC_DATA, "rtc_data");
+	devm_gpio_request(&pdev->dev, GPIO_RTC_SCLK, "rtc_sclk");
+	devm_gpio_request(&pdev->dev, GPIO_RTC_RESET, "rtc_reset");
+
+	gpio_direction_output(GPIO_RTC_RESET, 0);
+	gpio_direction_output(GPIO_RTC_SCLK, 0);
+
+	moxart_rtc->rtc = rtc_device_register(pdev->name, &pdev->dev,
+					      &moxart_rtc_ops, THIS_MODULE);
+	if (IS_ERR(moxart_rtc->rtc)) {
+		ret = PTR_ERR(moxart_rtc->rtc);
+		goto out;
+	}
+
+	dev_dbg(&pdev->dev, "%s\n", __func__);
+
+	if (ret)
+		goto out;
+
+	return 0;
+
+ out:
+	if (moxart_rtc->rtc)
+		rtc_device_unregister(moxart_rtc->rtc);
+	return ret;
+}
+
+static int moxart_rtc_remove(struct platform_device *pdev)
+{
+	struct moxart_rtc *moxart_rtc = platform_get_drvdata(pdev);
+
+	rtc_device_unregister(moxart_rtc->rtc);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_rtc_match[] = {
+	{ .compatible = "moxa,moxart-rtc" },
+	{ },
+};
+
+static struct platform_driver moxart_rtc_driver = {
+	.probe	= moxart_rtc_probe,
+	.remove	= moxart_rtc_remove,
+	.driver	= {
+		.name		= "moxart-rtc",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_rtc_match,
+	},
+};
+module_platform_driver(moxart_rtc_driver);
+
+MODULE_DESCRIPTION("MOXART RTC driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From shawn.guo at linaro.org  Thu Jul 11 09:57:43 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 11 Jul 2013 21:57:43 +0800
Subject: [PATCH 2/6] ARM: mxs: look up timrot clock from device tree
In-Reply-To: <20130711105625.GB12139@pengutronix.de>
References: <1364224652-28332-1-git-send-email-shawn.guo@linaro.org>
 <1364224652-28332-3-git-send-email-shawn.guo@linaro.org>
 <20130711105625.GB12139@pengutronix.de>
Message-ID: <20130711135741.GA3043@S2101-09.ap.freescale.net>

Hi Uwe,

On Thu, Jul 11, 2013 at 12:56:26PM +0200, Uwe Kleine-K?nig wrote:
> I'm currently using an i.MX28 with 3.8-rt13 and patched the clocksource
> and clockevent to use the 24 MHz clock source
> (BV_TIMROTv2_TIMCTRLn_SELECT__ALWAYS instead of
> BV_TIMROTv2_TIMCTRLn_SELECT__32KHZ_XTAL). Currently my patch is a hack
> because I hard code the 24 MHz. I wonder how to do it properly?
> 

You may want to take a look at commit 2fb318f (ARM: mxs: use apbx bus
clock to drive the timers on timrotv2), which hit mainline in v3.9.

Shawn

> Add another item to the "clocks = <...>" entry and use the first entry
> for enable and the 2nd for clk_get_rate?
> 
> Something like:
> 
> 	always_clk = of_clk_get(np, 1);
> 	if (always_clk)
> 		register timers using always clk (24 MHz, SELECT__ALWAYS)
> 	else
> 		fall back to timer_clk (32 kHz, 32KHZ_XTAL)
> 
> and then
> 
> 	timrot at 80068000 {
> 		compatible = "fsl,imx28-timrot", "fsl,timrot";
> 		reg = <0x80068000 0x2000>;
> 		interrupts = <48 49 50 51>;
> 		clocks = <&clks 26 &clks 0>;
> 	};
> 
> If you like it, too, I can prepare a patch.
> 
> Best regards
> Uwe
> 
> -- 
> Pengutronix e.K.                           | Uwe Kleine-K?nig            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |



From sboyd at codeaurora.org  Thu Jul 11 10:00:59 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 11 Jul 2013 07:00:59 -0700
Subject: CPU hotplug issue w/ 0647065 clocksource: Add generic dummy
 timer driver
In-Reply-To: <51DD872D.7020101@wwwdotorg.org>
References: <51DAF895.1020700@wwwdotorg.org>
 <20130709005837.GC830@codeaurora.org>
 <51DC34AD.30009@wwwdotorg.org>
 <20130709163518.GD830@codeaurora.org>
 <51DC3FD2.9070308@wwwdotorg.org>
 <20130709230528.GE830@codeaurora.org>
 <51DD872D.7020101@wwwdotorg.org>
Message-ID: <20130711140059.GA27430@codeaurora.org>

On 07/10, Stephen Warren wrote:
> On 07/09/2013 05:05 PM, Stephen Boyd wrote:
> > On 07/09, Stephen Warren wrote:
> >> On 07/09/2013 10:35 AM, Stephen Boyd wrote:
> >>> On 07/09, Stephen Warren wrote:
> >>>> On 07/08/2013 06:58 PM, Stephen Boyd wrote:
> >>>>> On 07/08, Stephen Warren wrote:
> >>>>>> CPU hotplug (replug) on Tegra HW seems to be occasionally broken due to
> >>>>>> commit 0647065 "clocksource: Add generic dummy timer driver" in
> >>>>>> linux-next. Reverting that commit solves the issue.
> ...
> > Can you try this patch?
> 
> That seems to work great, thanks! I successfully unpugged/replugged CPU1
> about 200 times, whereas without the patch I'd usually see the problem
> about 10% of replug attempts.
> 
> Tested-by: Stephen Warren <swarren at nvidia.com>
> 

Thomas, here's the full patch:

---8<----
Subject: [PATCH] tick: Fix hotplug confusing the broadcast mode

On ARM systems the dummy clockevent is registered with the cpu
hotplug notifier chain before any other per-cpu clockevent. This
has the side-effect of causing the dummy clockevent to be
registered first in every hotplug sequence. Because the dummy is
first, we'll try to turn the broadcast source on but the code in
tick_device_uses_broadcast() assumes the broadcast source is in
periodic mode and calls tick_broadcast_start_periodic()
unconditionally.

On boot this isn't a problem because we typically haven't
switched into oneshot mode yet (if at all). During hotplug, if
the broadcast source isn't in periodic mode we'll replace the
broadcast oneshot handler with the broadcast periodic handler and
start emulating oneshot mode when we shouldn't. Due to the way
the broadcast oneshot handler programs the next_event it's
possible for it to contain KTIME_MAX and cause us to hang the
system when the periodic handler tries to program the next tick.
Fix this by using the appropriate function to start the broadcast
source.

Reported-by: Stephen Warren <swarren at nvidia.com>
Tested-by: Stephen Warren <swarren at nvidia.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 kernel/time/tick-broadcast.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 6d3f916..218bcb5 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -157,7 +157,10 @@ int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu)
 		dev->event_handler = tick_handle_periodic;
 		tick_device_setup_broadcast_func(dev);
 		cpumask_set_cpu(cpu, tick_broadcast_mask);
-		tick_broadcast_start_periodic(bc);
+		if (tick_broadcast_device.mode == TICKDEV_MODE_PERIODIC)
+			tick_broadcast_start_periodic(bc);
+		else
+			tick_broadcast_setup_oneshot(bc);
 		ret = 1;
 	} else {
 		/*
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From peter.ujfalusi at ti.com  Thu Jul 11 10:04:48 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 11 Jul 2013 16:04:48 +0200
Subject: [PATCH] ARM: OMAP2+: Remove legacy device creation for McPDM and DMIC
Message-ID: <1373551488-3816-1-git-send-email-peter.ujfalusi@ti.com>

McPDM and DMIC only available on OMAP4/5 which no longer boots in legacy
mode.
The code to create the devices in legacy mode can be removed.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/mach-omap2/devices.c | 40 ----------------------------------------
 1 file changed, 40 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index aef96e4..dbcadcc 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -328,44 +328,6 @@ static void omap_init_audio(void)
 static inline void omap_init_audio(void) {}
 #endif
 
-#if defined(CONFIG_SND_OMAP_SOC_MCPDM) || \
-		defined(CONFIG_SND_OMAP_SOC_MCPDM_MODULE)
-
-static void __init omap_init_mcpdm(void)
-{
-	struct omap_hwmod *oh;
-	struct platform_device *pdev;
-
-	oh = omap_hwmod_lookup("mcpdm");
-	if (!oh)
-		return;
-
-	pdev = omap_device_build("omap-mcpdm", -1, oh, NULL, 0);
-	WARN(IS_ERR(pdev), "Can't build omap_device for omap-mcpdm.\n");
-}
-#else
-static inline void omap_init_mcpdm(void) {}
-#endif
-
-#if defined(CONFIG_SND_OMAP_SOC_DMIC) || \
-		defined(CONFIG_SND_OMAP_SOC_DMIC_MODULE)
-
-static void __init omap_init_dmic(void)
-{
-	struct omap_hwmod *oh;
-	struct platform_device *pdev;
-
-	oh = omap_hwmod_lookup("dmic");
-	if (!oh)
-		return;
-
-	pdev = omap_device_build("omap-dmic", -1, oh, NULL, 0);
-	WARN(IS_ERR(pdev), "Can't build omap_device for omap-dmic.\n");
-}
-#else
-static inline void omap_init_dmic(void) {}
-#endif
-
 #if defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI) || \
 		defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI_MODULE)
 
@@ -566,8 +528,6 @@ static int __init omap2_init_devices(void)
 	omap_init_mbox();
 	/* If dtb is there, the devices will be created dynamically */
 	if (!of_have_populated_dt()) {
-		omap_init_dmic();
-		omap_init_mcpdm();
 		omap_init_mcspi();
 		omap_init_sham();
 		omap_init_aes();
-- 
1.8.2.1



From shawn.guo at linaro.org  Thu Jul 11 10:10:23 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 11 Jul 2013 22:10:23 +0800
Subject: [PATCH] ARM: imx_v6_v7_defconfig: Select ARM1136 related errata
In-Reply-To: <1373472712-22295-1-git-send-email-fabio.estevam@freescale.com>
References: <1373472712-22295-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <20130711141021.GB3361@S2101-09.ap.freescale.net>

On Wed, Jul 10, 2013 at 01:11:52PM -0300, Fabio Estevam wrote:
> CONFIG_ARM_ERRATA_411920 and CONFIG_ARM_ERRATA_364296 should be selected for
> ARM1136 SoCs.
> 

Should errata be selected in Kconfig rather than defconfig?

Shawn

> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  arch/arm/configs/imx_v6_v7_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
> index f1662d3..ee84e82 100644
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@ -40,6 +40,8 @@ CONFIG_SOC_IMX6Q=y
>  CONFIG_SOC_IMX6SL=y
>  CONFIG_SOC_VF610=y
>  CONFIG_MXC_PWM=y
> +CONFIG_ARM_ERRATA_411920=y
> +CONFIG_ARM_ERRATA_364296=y
>  CONFIG_SMP=y
>  CONFIG_VMSPLIT_2G=y
>  CONFIG_PREEMPT_VOLUNTARY=y
> -- 
> 1.8.1.2
> 
> 



From peter.ujfalusi at ti.com  Thu Jul 11 10:23:58 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 11 Jul 2013 16:23:58 +0200
Subject: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and twl6040
 setup for legacy boot
Message-ID: <1373552638-13930-1-git-send-email-peter.ujfalusi@ti.com>

OMAP4 no longer boots in legacy mode so the code here is no longer used.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/mach-omap2/twl-common.c | 332 ++-------------------------------------
 arch/arm/mach-omap2/twl-common.h |   8 -
 2 files changed, 12 insertions(+), 328 deletions(-)

diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index c05898f..932dea7 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -38,20 +38,6 @@ static struct i2c_board_info __initdata pmic_i2c_board_info = {
 	.flags		= I2C_CLIENT_WAKE,
 };
 
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-static int twl_set_voltage(void *data, int target_uV)
-{
-	struct voltagedomain *voltdm = (struct voltagedomain *)data;
-	return voltdm_scale(voltdm, target_uV);
-}
-
-static int twl_get_voltage(void *data)
-{
-	struct voltagedomain *voltdm = (struct voltagedomain *)data;
-	return voltdm_get_voltage(voltdm);
-}
-#endif
-
 void __init omap_pmic_init(int bus, u32 clkrate,
 			   const char *pmic_type, int pmic_irq,
 			   struct twl4030_platform_data *pmic_data)
@@ -65,20 +51,6 @@ void __init omap_pmic_init(int bus, u32 clkrate,
 	omap_register_i2c_bus(bus, clkrate, &pmic_i2c_board_info, 1);
 }
 
-void __init omap4_pmic_init(const char *pmic_type,
-		    struct twl4030_platform_data *pmic_data,
-		    struct i2c_board_info *devices, int nr_devices)
-{
-	/* PMIC part*/
-	omap_mux_init_signal("sys_nirq1", OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE);
-	omap_mux_init_signal("fref_clk0_out.sys_drm_msecure", OMAP_PIN_OUTPUT);
-	omap_pmic_init(1, 400, pmic_type, 7 + OMAP44XX_IRQ_GIC_START, pmic_data);
-
-	/* Register additional devices on i2c1 bus if needed */
-	if (devices)
-		i2c_register_board_info(1, devices, nr_devices);
-}
-
 void __init omap_pmic_late_init(void)
 {
 	/* Init the OMAP TWL parameters (if PMIC has been registerd) */
@@ -86,7 +58,6 @@ void __init omap_pmic_late_init(void)
 		return;
 
 	omap3_twl_init();
-	omap4_twl_init();
 }
 
 #if defined(CONFIG_ARCH_OMAP3)
@@ -189,6 +160,18 @@ static struct regulator_init_data omap3_vdd2 = {
 	.consumer_supplies		= omap3_vdd2_supply,
 };
 
+static int twl_set_voltage(void *data, int target_uV)
+{
+	struct voltagedomain *voltdm = (struct voltagedomain *)data;
+	return voltdm_scale(voltdm, target_uV);
+}
+
+static int twl_get_voltage(void *data)
+{
+	struct voltagedomain *voltdm = (struct voltagedomain *)data;
+	return voltdm_get_voltage(voltdm);
+}
+
 static struct twl_regulator_driver_data omap3_vdd1_drvdata = {
 	.get_voltage = twl_get_voltage,
 	.set_voltage = twl_set_voltage,
@@ -235,297 +218,6 @@ void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
 }
 #endif /* CONFIG_ARCH_OMAP3 */
 
-#if defined(CONFIG_ARCH_OMAP4)
-static struct twl4030_usb_data omap4_usb_pdata = {
-};
-
-static struct regulator_consumer_supply omap4_vdda_hdmi_dac_supplies[] = {
-	REGULATOR_SUPPLY("vdda_hdmi_dac", "omapdss_hdmi"),
-};
-
-static struct regulator_init_data omap4_vdac_idata = {
-	.constraints = {
-		.min_uV			= 1800000,
-		.max_uV			= 1800000,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask		= REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-	},
-	.num_consumer_supplies	= ARRAY_SIZE(omap4_vdda_hdmi_dac_supplies),
-	.consumer_supplies	= omap4_vdda_hdmi_dac_supplies,
-	.supply_regulator	= "V2V1",
-};
-
-static struct regulator_init_data omap4_vaux2_idata = {
-	.constraints = {
-		.min_uV			= 1200000,
-		.max_uV			= 2800000,
-		.apply_uV		= true,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask		= REGULATOR_CHANGE_VOLTAGE
-					| REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-	},
-};
-
-static struct regulator_init_data omap4_vaux3_idata = {
-	.constraints = {
-		.min_uV			= 1000000,
-		.max_uV			= 3000000,
-		.apply_uV		= true,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask		= REGULATOR_CHANGE_VOLTAGE
-					| REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-	},
-};
-
-static struct regulator_consumer_supply omap4_vmmc_supply[] = {
-	REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0"),
-};
-
-/* VMMC1 for MMC1 card */
-static struct regulator_init_data omap4_vmmc_idata = {
-	.constraints = {
-		.min_uV			= 1200000,
-		.max_uV			= 3000000,
-		.apply_uV		= true,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask		= REGULATOR_CHANGE_VOLTAGE
-					| REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-	},
-	.num_consumer_supplies  = ARRAY_SIZE(omap4_vmmc_supply),
-	.consumer_supplies      = omap4_vmmc_supply,
-};
-
-static struct regulator_init_data omap4_vpp_idata = {
-	.constraints = {
-		.min_uV			= 1800000,
-		.max_uV			= 2500000,
-		.apply_uV		= true,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask		= REGULATOR_CHANGE_VOLTAGE
-					| REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-	},
-};
-
-static struct regulator_init_data omap4_vana_idata = {
-	.constraints = {
-		.min_uV			= 2100000,
-		.max_uV			= 2100000,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask		= REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-	},
-};
-
-static struct regulator_consumer_supply omap4_vcxio_supply[] = {
-	REGULATOR_SUPPLY("vdds_dsi", "omapdss_dss"),
-	REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.0"),
-	REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi.1"),
-};
-
-static struct regulator_init_data omap4_vcxio_idata = {
-	.constraints = {
-		.min_uV			= 1800000,
-		.max_uV			= 1800000,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask		= REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-		.always_on		= true,
-	},
-	.num_consumer_supplies	= ARRAY_SIZE(omap4_vcxio_supply),
-	.consumer_supplies	= omap4_vcxio_supply,
-	.supply_regulator	= "V2V1",
-};
-
-static struct regulator_init_data omap4_vusb_idata = {
-	.constraints = {
-		.min_uV			= 3300000,
-		.max_uV			= 3300000,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask		= REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-	},
-};
-
-static struct regulator_init_data omap4_clk32kg_idata = {
-	.constraints = {
-		.valid_ops_mask		= REGULATOR_CHANGE_STATUS,
-	},
-};
-
-static struct regulator_consumer_supply omap4_vdd1_supply[] = {
-	REGULATOR_SUPPLY("vcc", "cpu0"),
-};
-
-static struct regulator_consumer_supply omap4_vdd2_supply[] = {
-	REGULATOR_SUPPLY("vcc", "iva.0"),
-};
-
-static struct regulator_consumer_supply omap4_vdd3_supply[] = {
-	REGULATOR_SUPPLY("vcc", "l3_main.0"),
-};
-
-static struct regulator_init_data omap4_vdd1 = {
-	.constraints = {
-		.name			= "vdd_mpu",
-		.min_uV			= 500000,
-		.max_uV			= 1500000,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL,
-		.valid_ops_mask		= REGULATOR_CHANGE_VOLTAGE,
-	},
-	.num_consumer_supplies		= ARRAY_SIZE(omap4_vdd1_supply),
-	.consumer_supplies		= omap4_vdd1_supply,
-};
-
-static struct regulator_init_data omap4_vdd2 = {
-	.constraints = {
-		.name			= "vdd_iva",
-		.min_uV			= 500000,
-		.max_uV			= 1500000,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL,
-		.valid_ops_mask		= REGULATOR_CHANGE_VOLTAGE,
-	},
-	.num_consumer_supplies		= ARRAY_SIZE(omap4_vdd2_supply),
-	.consumer_supplies		= omap4_vdd2_supply,
-};
-
-static struct regulator_init_data omap4_vdd3 = {
-	.constraints = {
-		.name			= "vdd_core",
-		.min_uV			= 500000,
-		.max_uV			= 1500000,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL,
-		.valid_ops_mask		= REGULATOR_CHANGE_VOLTAGE,
-	},
-	.num_consumer_supplies		= ARRAY_SIZE(omap4_vdd3_supply),
-	.consumer_supplies		= omap4_vdd3_supply,
-};
-
-
-static struct twl_regulator_driver_data omap4_vdd1_drvdata = {
-	.get_voltage = twl_get_voltage,
-	.set_voltage = twl_set_voltage,
-};
-
-static struct twl_regulator_driver_data omap4_vdd2_drvdata = {
-	.get_voltage = twl_get_voltage,
-	.set_voltage = twl_set_voltage,
-};
-
-static struct twl_regulator_driver_data omap4_vdd3_drvdata = {
-	.get_voltage = twl_get_voltage,
-	.set_voltage = twl_set_voltage,
-};
-
-static struct regulator_consumer_supply omap4_v1v8_supply[] = {
-	REGULATOR_SUPPLY("vio", "1-004b"),
-};
-
-static struct regulator_init_data omap4_v1v8_idata = {
-	.constraints = {
-		.min_uV			= 1800000,
-		.max_uV			= 1800000,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask		= REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-		.always_on		= true,
-	},
-	.num_consumer_supplies	= ARRAY_SIZE(omap4_v1v8_supply),
-	.consumer_supplies	= omap4_v1v8_supply,
-};
-
-static struct regulator_consumer_supply omap4_v2v1_supply[] = {
-	REGULATOR_SUPPLY("v2v1", "1-004b"),
-};
-
-static struct regulator_init_data omap4_v2v1_idata = {
-	.constraints = {
-		.min_uV			= 2100000,
-		.max_uV			= 2100000,
-		.valid_modes_mask	= REGULATOR_MODE_NORMAL
-					| REGULATOR_MODE_STANDBY,
-		.valid_ops_mask		= REGULATOR_CHANGE_MODE
-					| REGULATOR_CHANGE_STATUS,
-	},
-	.num_consumer_supplies	= ARRAY_SIZE(omap4_v2v1_supply),
-	.consumer_supplies	= omap4_v2v1_supply,
-};
-
-void __init omap4_pmic_get_config(struct twl4030_platform_data *pmic_data,
-				  u32 pdata_flags, u32 regulators_flags)
-{
-	if (!pmic_data->vdd1) {
-		omap4_vdd1.driver_data = &omap4_vdd1_drvdata;
-		omap4_vdd1_drvdata.data = voltdm_lookup("mpu");
-		pmic_data->vdd1 = &omap4_vdd1;
-	}
-
-	if (!pmic_data->vdd2) {
-		omap4_vdd2.driver_data = &omap4_vdd2_drvdata;
-		omap4_vdd2_drvdata.data = voltdm_lookup("iva");
-		pmic_data->vdd2 = &omap4_vdd2;
-	}
-
-	if (!pmic_data->vdd3) {
-		omap4_vdd3.driver_data = &omap4_vdd3_drvdata;
-		omap4_vdd3_drvdata.data = voltdm_lookup("core");
-		pmic_data->vdd3 = &omap4_vdd3;
-	}
-
-	/* Common platform data configurations */
-	if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb)
-		pmic_data->usb = &omap4_usb_pdata;
-
-	/* Common regulator configurations */
-	if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
-		pmic_data->vdac = &omap4_vdac_idata;
-
-	if (regulators_flags & TWL_COMMON_REGULATOR_VAUX2 && !pmic_data->vaux2)
-		pmic_data->vaux2 = &omap4_vaux2_idata;
-
-	if (regulators_flags & TWL_COMMON_REGULATOR_VAUX3 && !pmic_data->vaux3)
-		pmic_data->vaux3 = &omap4_vaux3_idata;
-
-	if (regulators_flags & TWL_COMMON_REGULATOR_VMMC && !pmic_data->vmmc)
-		pmic_data->vmmc = &omap4_vmmc_idata;
-
-	if (regulators_flags & TWL_COMMON_REGULATOR_VPP && !pmic_data->vpp)
-		pmic_data->vpp = &omap4_vpp_idata;
-
-	if (regulators_flags & TWL_COMMON_REGULATOR_VANA && !pmic_data->vana)
-		pmic_data->vana = &omap4_vana_idata;
-
-	if (regulators_flags & TWL_COMMON_REGULATOR_VCXIO && !pmic_data->vcxio)
-		pmic_data->vcxio = &omap4_vcxio_idata;
-
-	if (regulators_flags & TWL_COMMON_REGULATOR_VUSB && !pmic_data->vusb)
-		pmic_data->vusb = &omap4_vusb_idata;
-
-	if (regulators_flags & TWL_COMMON_REGULATOR_CLK32KG &&
-	    !pmic_data->clk32kg)
-		pmic_data->clk32kg = &omap4_clk32kg_idata;
-
-	if (regulators_flags & TWL_COMMON_REGULATOR_V1V8 && !pmic_data->v1v8)
-		pmic_data->v1v8 = &omap4_v1v8_idata;
-
-	if (regulators_flags & TWL_COMMON_REGULATOR_V2V1 && !pmic_data->v2v1)
-		pmic_data->v2v1 = &omap4_v2v1_idata;
-}
-#endif /* CONFIG_ARCH_OMAP4 */
-
 #if defined(CONFIG_SND_OMAP_SOC_OMAP_TWL4030) || \
 	defined(CONFIG_SND_OMAP_SOC_OMAP_TWL4030_MODULE)
 #include <linux/platform_data/omap-twl4030.h>
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 24b65d0..15eace6 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -31,7 +31,6 @@
 
 
 struct twl4030_platform_data;
-struct twl6040_platform_data;
 struct omap_tw4030_pdata;
 struct i2c_board_info;
 
@@ -51,16 +50,9 @@ static inline void omap3_pmic_init(const char *pmic_type,
 	omap_pmic_init(1, 2600, pmic_type, 7 + OMAP_INTC_START, pmic_data);
 }
 
-void omap4_pmic_init(const char *pmic_type,
-		    struct twl4030_platform_data *pmic_data,
-		    struct i2c_board_info *devices, int nr_devices);
-
 void omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
 			   u32 pdata_flags, u32 regulators_flags);
 
-void omap4_pmic_get_config(struct twl4030_platform_data *pmic_data,
-			   u32 pdata_flags, u32 regulators_flags);
-
 void omap_twl4030_audio_init(char *card_name, struct omap_tw4030_pdata *pdata);
 
 #endif /* __OMAP_PMIC_COMMON__ */
-- 
1.8.2.1



From fabio.estevam at freescale.com  Thu Jul 11 10:26:22 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Thu, 11 Jul 2013 11:26:22 -0300
Subject: [PATCH v2] ARM: imx: Kconfig: Select ARM1136 related errata
Message-ID: <1373552782-14196-1-git-send-email-fabio.estevam@freescale.com>

CONFIG_ARM_ERRATA_411920 and CONFIG_ARM_ERRATA_364296 should be selected for
ARM1136 SoCs.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- Select the errata via Kconfig

 arch/arm/mach-imx/Kconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index f7a5ad1..1d15d5c 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -123,6 +123,8 @@ config SOC_IMX27
 
 config SOC_IMX31
 	bool
+	select ARM_ERRATA_364296
+	select ARM_ERRATA_411920
 	select COMMON_CLK
 	select CPU_V6
 	select IMX_HAVE_PLATFORM_MXC_RNGA
@@ -132,6 +134,8 @@ config SOC_IMX31
 config SOC_IMX35
 	bool
 	select ARCH_MXC_IOMUX_V3
+	select ARM_ERRATA_364296
+	select ARM_ERRATA_411920
 	select COMMON_CLK
 	select CPU_V6K
 	select HAVE_EPIT
-- 
1.8.1.2




From marc.zyngier at arm.com  Thu Jul 11 10:30:36 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Jul 2013 15:30:36 +0100
Subject: [PATCH] arm64: compat: fix compilation when using 64kB pages
Message-ID: <1373553036-5418-1-git-send-email-marc.zyngier@arm.com>

When compiling for 64kB pages, we end-up having conflicting
implementations for aarch32_break_handler().

Wrap the 4kB page implementation with a CONFIG_COMPAT guard and change
the !CONFIG_COMPAT implementation to be static inline instead of simply static.

Cc: Will Deacon <will.deacon at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/debug-monitors.h | 2 +-
 arch/arm64/kernel/debug-monitors.c      | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
index ef8235c..7c962f3 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -86,7 +86,7 @@ static inline int reinstall_suspended_bps(struct pt_regs *regs)
 #ifdef CONFIG_COMPAT
 int aarch32_break_handler(struct pt_regs *regs);
 #else
-static int aarch32_break_handler(struct pt_regs *regs)
+static inline int aarch32_break_handler(struct pt_regs *regs)
 {
 	return -EFAULT;
 }
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 08018e3..ceedcd7 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -246,6 +246,7 @@ static int brk_handler(unsigned long addr, unsigned int esr,
 	return 0;
 }
 
+#ifdef CONFIG_COMPAT
 int aarch32_break_handler(struct pt_regs *regs)
 {
 	siginfo_t info;
@@ -285,6 +286,7 @@ int aarch32_break_handler(struct pt_regs *regs)
 	force_sig_info(SIGTRAP, &info, current);
 	return 0;
 }
+#endif
 
 static int __init debug_traps_init(void)
 {
-- 
1.8.1.5



From thomas.petazzoni at free-electrons.com  Thu Jul 11 10:32:20 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 11 Jul 2013 16:32:20 +0200
Subject: pci-mvebu driver on km_kirkwood
In-Reply-To: <51DD9A8C.10608@keymile.com>
References: <51DD88A4.1030506@keymile.com> <20130710185706.72b124a4@skate>
 <51DD9A8C.10608@keymile.com>
Message-ID: <20130711163220.2b3adf38@skate>

Dear Gerlando Falauto,

On Wed, 10 Jul 2013 19:31:56 +0200, Gerlando Falauto wrote:

> Yes, though we had to trick it a little bit to get both the internal 
> switch and this PCIe device working:
> 
> - this PCIe device requires to map 256M of memory as opposed to just 128
> - we need a virtual PCIe device to connect to the internal switch, which 
> must be mapped at 0xf4000000 (normally used for the NAND which must then 
> move to 0xff000000)

Aah, if you need 256 MB, then you need to adjust the ranges, because
by default there is only 128 MB for PCIe memory. So, you would need
something like:

So, within the pcie-controller node, you should do something like:

			ranges = <0x82000000 0 0x00040000 0x00040000 0 0x00002000   /* Port 0.0 registers */
				  0x82000000 0 0xe0000000 0xe0000000 0 0x10000000   /* non-prefetchable memory */
			          0x81000000 0 0          0xf0000000 0 0x00100000>; /* downstream I/O */

and in the ranges property at the ocp { } level, you should do something like:


		ranges = <0x00000000 0xf1000000 0x0100000
		          0xe0000000 0xe0000000 0x10100000 /* PCIE */
		          0xf4000000 0xf4000000 0x0000400
		          0xf5000000 0xf5000000 0x0000400>;

Basically, before the change the configuration was:

 * 128 MB of PCIe memory at 0xe0000000
 * 1 MB of PCIe I/O at 0xe8000000

After the change, you have:

 * 256 MB of PCIe memory at 0xe0000000
 * 1 MB of PCIe I/O at 0xf0000000

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From rogerq at ti.com  Thu Jul 11 10:35:58 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 11 Jul 2013 17:35:58 +0300
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51DEA7F1.1050902@denx.de>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de> <51DE87D3.5030600@ti.com>
 <51DEA7F1.1050902@denx.de>
Message-ID: <51DEC2CE.70400@ti.com>

On 07/11/2013 03:41 PM, Stefan Roese wrote:
> On 07/11/2013 12:24 PM, Roger Quadros wrote:
>> My u-boot script is below and boot log is attached.
> 
> BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
> Do you have any patches locally applied to the kernel.org version that
> might be helpful with this USB issue I'm seeing?

Yes I had tested it on a more recent kernel with some local patches applied
that I've recently sent for review.

But to cross check with your setup I've retested it with commit d2b4a646 
with the 2 below patches on top

https://lkml.org/lkml/2013/6/20/327
https://lkml.org/lkml/2013/6/20/339

I've tried it again with the ELDK 5.3 root but still can't get it to fail.

I think we should match our u-boot as well. Could you please let me know
your u-boot commit and uEnv.txt?

My network setup is pretty simple, beagle-xm is connected directly to my laptop's
ethernet port. No network switch in between.

When you get the problem do you cold boot the board or warm boot it?
I've been always cold booting it.

cheers,
-roger


From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 11 10:37:47 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Thu, 11 Jul 2013 16:37:47 +0200
Subject: [PATCH 1/2] ARM i.MX53: mba53: Fix PWM backlight DT node
In-Reply-To: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1373553468-6564-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The i.MX53 PWM controller uses two cells to describe the PWM specifier.
Remove the extra unused values from the backlight DT node pwms property.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 arch/arm/boot/dts/imx53-mba53.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx53-mba53.dts b/arch/arm/boot/dts/imx53-mba53.dts
index aaa33bc..a630902 100644
--- a/arch/arm/boot/dts/imx53-mba53.dts
+++ b/arch/arm/boot/dts/imx53-mba53.dts
@@ -27,7 +27,7 @@
 
 	backlight {
 		compatible = "pwm-backlight";
-		pwms = <&pwm2 0 50000 0 0>;
+		pwms = <&pwm2 0 50000>;
 		brightness-levels = <0 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80 84 88 92 96 100>;
 		default-brightness-level = <10>;
 		enable-gpios = <&gpio7 7 0>;
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 11 10:37:46 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Thu, 11 Jul 2013 16:37:46 +0200
Subject: [PATCH 0/2] Add PWM polarity flag macros for DT
Message-ID: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Hello,

Here's a small patch set that replaces PWM polarity numerical constants with
macros in DT. The series starts with a fix for an error in the i.MX53 mba53 DT,
and the second patch then introduces the macros and update both bindings
documentation and existing DT.

Laurent Pinchart (2):
  ARM i.MX53: mba53: Fix PWM backlight DT node
  pwm: Add PWM polarity flag macros for DT

 Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt |  6 +++---
 Documentation/devicetree/bindings/pwm/pwm-samsung.txt   |  5 +++--
 Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt  |  5 +++--
 Documentation/devicetree/bindings/pwm/pwm.txt           |  8 +++++---
 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt    |  5 +++--
 arch/arm/boot/dts/am335x-evm.dts                        |  3 ++-
 arch/arm/boot/dts/am335x-evmsk.dts                      |  3 ++-
 arch/arm/boot/dts/imx53-mba53.dts                       |  2 +-
 arch/arm/boot/dts/wm8850-w70v2.dts                      |  3 ++-
 include/dt-bindings/pwm/pwm.h                           | 15 +++++++++++++++
 include/linux/pwm.h                                     |  4 ++--
 11 files changed, 41 insertions(+), 18 deletions(-)
 create mode 100644 include/dt-bindings/pwm/pwm.h

-- 
Regards,

Laurent Pinchart



From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 11 10:37:48 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Thu, 11 Jul 2013 16:37:48 +0200
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1373553468-6564-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Define PWM_POLARITY_NORMAL and PWM_POLARITY_INVERTED macros in
include/dt-bindings/pwm/pwm.h to be used by device tree sources.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt |  6 +++---
 Documentation/devicetree/bindings/pwm/pwm-samsung.txt   |  5 +++--
 Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt  |  5 +++--
 Documentation/devicetree/bindings/pwm/pwm.txt           |  8 +++++---
 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt    |  5 +++--
 arch/arm/boot/dts/am335x-evm.dts                        |  3 ++-
 arch/arm/boot/dts/am335x-evmsk.dts                      |  3 ++-
 arch/arm/boot/dts/wm8850-w70v2.dts                      |  3 ++-
 include/dt-bindings/pwm/pwm.h                           | 15 +++++++++++++++
 include/linux/pwm.h                                     |  4 ++--
 10 files changed, 40 insertions(+), 17 deletions(-)
 create mode 100644 include/dt-bindings/pwm/pwm.h

diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
index de0eaed..be09be4 100644
--- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
@@ -4,9 +4,9 @@ Required properties:
 - compatible: should be "atmel,tcb-pwm"
 - #pwm-cells: Should be 3.  The first cell specifies the per-chip index
   of the PWM to use, the second cell is the period in nanoseconds and
-  bit 0 in the third cell is used to encode the polarity of PWM output.
-  Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity &
-  set to 0 for normal polarity.
+  the third cell is used to encode the polarity of PWM output. Set the
+  PWM_POLARITY_NORMAL flag for normal polarity or the PWM_POLARITY_INVERSED
+  flag for inverted polarity. PWM flags are defined in <dt-bindings/pwm/pwm.h>.
 - tc-block: The Timer Counter block to use as a PWM chip.
 
 Example:
diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
index ac67c68..bece18b 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
@@ -24,8 +24,9 @@ Required properties:
      - phandle to PWM controller node
      - index of PWM channel (from 0 to 4)
      - PWM signal period in nanoseconds
-     - bitmask of optional PWM flags:
-        0x1 - invert PWM signal
+     - bitmask of optional PWM flags as defined in <dt-bindings/pwm/pwm.h>:
+        PWM_POLARITY_NORMAL - normal polarity
+	PWM_POLARITY_INVERSED - inverted polarity
 
 Optional properties:
 - samsung,pwm-outputs: list of PWM channels used as PWM outputs on particular
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
index 337c6fc..9007d92 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
@@ -7,8 +7,9 @@ Required properties:
 - #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
   First cell specifies the per-chip index of the PWM to use, the second
   cell is the period in nanoseconds and bit 0 in the third cell is used to
-  encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
-  to 1 for inverse polarity & set to 0 for normal polarity.
+  encode the polarity of PWM output. Set the PWM_POLARITY_NORMAL flag for
+  normal polarity or the PWM_POLARITY_INVERSED flag for inverted polarity.
+  PWM flags are defined in <dt-bindings/pwm/pwm.h>.
 - reg: physical base address and size of the registers map.
 
 Optional properties:
diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt b/Documentation/devicetree/bindings/pwm/pwm.txt
index 06e6724..38c357a 100644
--- a/Documentation/devicetree/bindings/pwm/pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm.txt
@@ -43,13 +43,15 @@ because the name "backlight" would be used as fallback anyway.
 pwm-specifier typically encodes the chip-relative PWM number and the PWM
 period in nanoseconds.
 
-Optionally, the pwm-specifier can encode a number of flags in a third cell:
-- bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity)
+Optionally, the pwm-specifier can encode a number of flags (defined in
+<dt-bindings/gpio/gpio.h>) in a third cell:
+- PWM_POLARITY_NORMAL: use the normal PWM signal polarity
+- PWM_POLARITY_INVERSED: invert the PWM signal polarity
 
 Example with optional PWM specifier for inverse polarity
 
 	bl: backlight {
-		pwms = <&pwm 0 5000000 1>;
+		pwms = <&pwm 0 5000000 PWM_POLARITY_INVERSED>;
 		pwm-names = "backlight";
 	};
 
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
index d21d82d..5b1b21f 100644
--- a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
@@ -6,8 +6,9 @@ Required properties:
 - #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
   First cell specifies the per-chip index of the PWM to use, the second
   cell is the period in nanoseconds and bit 0 in the third cell is used to
-  encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
-  to 1 for inverse polarity & set to 0 for normal polarity.
+  encode the polarity of PWM output. Set the PWM_POLARITY_NORMAL flag for
+  normal polarity or the PWM_POLARITY_INVERSED flag for inverted polarity.
+  PWM flags are defined in <dt-bindings/pwm/pwm.h>.
 - clocks: phandle to the PWM source clock
 
 Example:
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 3aee1a4..c9da673 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -8,6 +8,7 @@
 /dts-v1/;
 
 #include "am33xx.dtsi"
+#include <dt-bindings/pwm/pwm.h>
 
 / {
 	model = "TI AM335x EVM";
@@ -370,7 +371,7 @@
 
 	backlight {
 		compatible = "pwm-backlight";
-		pwms = <&ecap0 0 50000 0>;
+		pwms = <&ecap0 0 50000 PWM_POLARITY_NORMAL>;
 		brightness-levels = <0 51 53 56 62 75 101 152 255>;
 		default-brightness-level = <8>;
 	};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 0c8ad17..5d4ec91 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -14,6 +14,7 @@
 /dts-v1/;
 
 #include "am33xx.dtsi"
+#include <dt-bindings/pwm/pwm.h>
 
 / {
 	model = "TI AM335x EVM-SK";
@@ -298,7 +299,7 @@
 
 	backlight {
 		compatible = "pwm-backlight";
-		pwms = <&ecap2 0 50000 1>;
+		pwms = <&ecap2 0 50000 PWM_POLARITY_INVERSED>;
 		brightness-levels = <0 58 61 66 75 90 125 170 255>;
 		default-brightness-level = <8>;
 	};
diff --git a/arch/arm/boot/dts/wm8850-w70v2.dts b/arch/arm/boot/dts/wm8850-w70v2.dts
index 90e913f..171930a 100644
--- a/arch/arm/boot/dts/wm8850-w70v2.dts
+++ b/arch/arm/boot/dts/wm8850-w70v2.dts
@@ -11,13 +11,14 @@
 
 /dts-v1/;
 /include/ "wm8850.dtsi"
+#include <dt-bindings/pwm/pwm.h>
 
 / {
 	model = "Wondermedia WM8850-W70v2 Tablet";
 
 	backlight {
 		compatible = "pwm-backlight";
-		pwms = <&pwm 0 50000 1>;	/* duty inverted */
+		pwms = <&pwm 0 50000 PWM_POLARITY_INVERSED>;
 
 		brightness-levels = <0 40 60 80 100 130 190 255>;
 		default-brightness-level = <5>;
diff --git a/include/dt-bindings/pwm/pwm.h b/include/dt-bindings/pwm/pwm.h
new file mode 100644
index 0000000..f82be30
--- /dev/null
+++ b/include/dt-bindings/pwm/pwm.h
@@ -0,0 +1,15 @@
+/*
+ * This header provides constants for most PWM bindings.
+ *
+ * Most PWM bindings can include a flags cell as part of the PWM specifier.
+ * In most cases, the format of the flags cell uses the standard values
+ * defined in this header.
+ */
+
+#ifndef _DT_BINDINGS_PWM_PWM_H
+#define _DT_BINDINGS_PWM_PWM_H
+
+#define PWM_POLARITY_NORMAL			(0 << 0)
+#define PWM_POLARITY_INVERSED			(1 << 0)
+
+#endif
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index f0feafd..ffde99b 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -69,8 +69,8 @@ struct pwm_chip;
  * period
  */
 enum pwm_polarity {
-	PWM_POLARITY_NORMAL,
-	PWM_POLARITY_INVERSED,
+	PWM_POLARITY_NORMAL = 0,
+	PWM_POLARITY_INVERSED = 1,
 };
 
 enum {
-- 
1.8.1.5



From grant.likely at secretlab.ca  Thu Jul 11 10:56:41 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Thu, 11 Jul 2013 15:56:41 +0100
Subject: [PATCH v3 2/2] drivers: dma-contiguous: add initialization from
 device tree
In-Reply-To: <1372254009-25307-3-git-send-email-m.szyprowski@samsung.com>
References: <1372254009-25307-1-git-send-email-m.szyprowski@samsung.com>
 <1372254009-25307-3-git-send-email-m.szyprowski@samsung.com>
Message-ID: <CACxGe6uzau+g0gd=hkNYw1zdkfq18zt_m9OEaiJKR6=q1U4rag@mail.gmail.com>

Hi Marek,

Thanks for working on this. Comments below...

On Wed, Jun 26, 2013 at 2:40 PM, Marek Szyprowski
<m.szyprowski at samsung.com> wrote:
> Add device tree support for contiguous memory regions defined in device
> tree. Initialization is done in 2 steps. First, the contiguous memory is
> reserved, what happens very early when only flattened device tree is
> available. Then on device initialization the corresponding cma regions are
> assigned to each device structure.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park at samsung.com>
> ---
>  .../devicetree/bindings/contiguous-memory.txt      |   94 ++++++++++++++
>  arch/arm/boot/dts/skeleton.dtsi                    |    7 +-
>  drivers/base/dma-contiguous.c                      |  132 ++++++++++++++++++++
>  3 files changed, 232 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/contiguous-memory.txt
>
> diff --git a/Documentation/devicetree/bindings/contiguous-memory.txt b/Documentation/devicetree/bindings/contiguous-memory.txt
> new file mode 100644
> index 0000000..a733df2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/contiguous-memory.txt
> @@ -0,0 +1,94 @@
> +*** Contiguous Memory binding ***
> +
> +The /chosen/contiguous-memory node provides runtime configuration of
> +contiguous memory regions for Linux kernel. Such regions can be created
> +for special usage by various device drivers. A good example are
> +contiguous memory allocations or memory sharing with other operating
> +system(s) on the same hardware board. Those special memory regions might
> +depend on the selected board configuration and devices used on the target
> +system.
> +
> +Parameters for each memory region can be encoded into the device tree
> +with the following convention:
> +
> +contiguous-memory {
> +
> +       (name): region@(base-address) {
> +               reg = <(baseaddr) (size)>;
> +               (linux,default-contiguous-region);
> +               device = <&device_0 &device_1 ...>
> +       };
> +};

Okay, I've gone and read all of the backlog on the 3 versions of the
patch series, and I think I understand the issues. I actually think it
was better off to have the regions specified as children of the memory
node. I understand the argument about how would firmware know what
size the kernel wants and that it would be better to have a kernel
parameter to override the default. However, it is also reasonable for
the kernel to be provided with a default amount of CMA based on the
usage profile of the device. In that regard it is absolutely
appropriate to put the CMA region data into the memory node. I don't
think /chosen is the right place for that.

> +
> +name:          an name given to the defined region;

In the above node example, "name:" is a label used for creating
phandles. That information doesn't appear in the resulting .dtb
output. The label is actually optional It should instead be:
        [(label):] (name)@(address) { }

> +base-address:  the base address of the defined region;
> +size:          the size of the memory region (bytes);

The reg property should follow the normal reg rules which are well
defined. That also means that a memory region could have multiple reg
entries if appropriate.

> +linux,default-contiguous-region: property indicating that the region
> +               is the default region for all contiguous memory
> +               allocations, Linux specific (optional);
> +device:                array of phandles to the client device nodes, which
> +               will use the defined contiguous region.

This is backwards compared to the way device references usually work.
It would be more consistent for each device node to have a
"dma-memory-region" property with phandles to one or more memory
regions that it cares about.

> +Each defined region must use unique name. It is optional to specify the
> +base address, so if one wants to use autoconfiguration of the base
> +address, he must specify the '0' as base address in the 'reg' property
> +and assign ann uniqe name to such regions, following the convention:
> +'region at 0', 'region at 1', 'region at 2', ...

Drop the use of 'region'. "name at 0" is more typical. It would be
appropriate to have compatible = "reserved-memory-region" in each of
the reserved regions. That would avoid the problem of two regions
based at the same address having a conflict in name.

> +
> +
> +*** Example ***
> +
> +This example defines a memory configuration containing 2 contiguous
> +regions for Linux kernel, one default of all device drivers (named
> +contig_mem, autoconfigured at boot time, 64MiB) and one dedicated to the
> +framebuffer device (named display_mem, placed at 0x78000000, 64MiB). The
> +display_mem region is then assigned to fb at 12300000, scaller at 12500000 and
> +codec at 12600000 devices for contiguous memory allocation with Linux
> +kernel drivers.
> +
> +The reason for creating a separate region for framebuffer device is to
> +match the framebuffer base address to the one configured by bootloader,
> +so once Linux kernel drivers starts no glitches on the displayed boot
> +logo appears. Scaller and codec drivers should share the memory
> +allocations with framebuffer driver.
> +
> +/ {
> +       /* ... */
> +
> +       chosen {
> +               bootargs = /* ... */
> +
> +               contiguous-memory {
> +
> +                       /*
> +                        * global autoconfigured region
> +                        * for contiguous allocations
> +                        */
> +                       contig_mem: region at 0 {
> +                               reg = <0x0 0x4000000>;
> +                               linux,default-contiguous-region;
> +                       };
> +
> +                       /*
> +                        * special region for framebuffer and
> +                        * multimedia processing devices
> +                        */
> +                       display_mem: region at 78000000 {
> +                               reg = <0x78000000 0x4000000>;
> +                               device = <&fb0 &scaller &codec>;
> +                       };
> +               };
> +       };
> +
> +       /* ... */
> +
> +       fb0: fb at 12300000 {
> +               status = "okay";
> +       };
> +       scaller: scaller at 12500000 {
> +               status = "okay";
> +       };
> +       codec: codec at 12600000 {
> +               status = "okay";
> +       };
> +};
> diff --git a/arch/arm/boot/dts/skeleton.dtsi b/arch/arm/boot/dts/skeleton.dtsi
> index b41d241..cadc3b9 100644
> --- a/arch/arm/boot/dts/skeleton.dtsi
> +++ b/arch/arm/boot/dts/skeleton.dtsi
> @@ -7,7 +7,12 @@
>  / {
>         #address-cells = <1>;
>         #size-cells = <1>;
> -       chosen { };
> +       chosen {
> +               contiguous-memory {
> +                       #address-cells = <1>;
> +                       #size-cells = <1>;
> +               };
> +       };
>         aliases { };
>         memory { device_type = "memory"; reg = <0 0>; };
>  };
> diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
> index 01fe743..ce5f5d1 100644
> --- a/drivers/base/dma-contiguous.c
> +++ b/drivers/base/dma-contiguous.c
> @@ -24,6 +24,9 @@
>
>  #include <linux/memblock.h>
>  #include <linux/err.h>
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/of_platform.h>
>  #include <linux/mm.h>
>  #include <linux/mutex.h>
>  #include <linux/page-isolation.h>
> @@ -37,6 +40,7 @@ struct cma {
>         unsigned long   base_pfn;
>         unsigned long   count;
>         unsigned long   *bitmap;
> +       char            full_name[32];
>  };
>
>  static DEFINE_MUTEX(cma_mutex);
> @@ -133,6 +137,52 @@ static __init int cma_activate_area(struct cma *cma)
>         return 0;
>  }
>
> +/*****************************************************************************/
> +
> +#ifdef CONFIG_OF
> +int __init cma_fdt_scan(unsigned long node, const char *uname,
> +                               int depth, void *data)
> +{
> +       static int level;
> +       phys_addr_t base, size;
> +       unsigned long len;
> +       struct cma *cma;
> +       __be32 *prop;
> +       int ret;
> +
> +       if (depth == 1 && strcmp(uname, "chosen") == 0) {
> +               level = depth;
> +               return 0;
> +       }
> +
> +       if (depth == 2 && strcmp(uname, "contiguous-memory") == 0) {
> +               level = depth;
> +               return 0;
> +       }
> +
> +       if (level != 2 || depth != 3 || strncmp(uname, "region@", 7) != 0)
> +               return 0;
> +
> +       prop = of_get_flat_dt_prop(node, "reg", &len);
> +       if (!prop || (len != 2 * sizeof(unsigned long)))
> +               return 0;
> +
> +       base = be32_to_cpu(prop[0]);
> +       size = be32_to_cpu(prop[1]);
> +
> +       pr_info("Found %s, memory base %lx, size %ld MiB\n", uname,
> +               (unsigned long)base, (unsigned long)size / SZ_1M);
> +
> +       ret = dma_contiguous_reserve_area(size, base, 0, &cma);
> +       if (ret == 0) {
> +               strcpy(cma->full_name, uname);
> +               if (of_get_flat_dt_prop(node, "linux,default-contiguous-region", NULL))
> +                       dma_contiguous_default_area = cma;
> +       }
> +       return 0;
> +}
> +#endif
> +
>  /**
>   * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling
>   * @limit: End address of the reserved memory (optional, 0 for any).
> @@ -149,6 +199,10 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
>
>         pr_debug("%s(limit %08lx)\n", __func__, (unsigned long)limit);
>
> +#ifdef CONFIG_OF
> +       of_scan_flat_dt(cma_fdt_scan, NULL);
> +#endif
> +
>         if (size_cmdline != -1) {
>                 sel_size = size_cmdline;
>         } else {
> @@ -265,6 +319,80 @@ int __init dma_contiguous_add_device(struct device *dev, struct cma *cma)
>         return 0;
>  }
>
> +#ifdef CONFIG_OF
> +
> +#define MAX_CMA_MAPS   64
> +
> +static struct cma_map {
> +       struct cma *cma;
> +       struct device_node *node;
> +} cma_maps[MAX_CMA_MAPS];
> +static unsigned cma_map_count;
> +
> +static void cma_assign_device_from_dt(struct device *dev)
> +{
> +       int i;
> +       for (i = 0; i < cma_map_count; i++) {
> +               if (cma_maps[i].node == dev->of_node) {
> +                       dev_set_cma_area(dev, cma_maps[i].cma);
> +                       pr_info("Assigned CMA %s to %s device\n",
> +                               cma_maps[i].cma->full_name,
> +                               dev_name(dev));
> +               }
> +       }
> +}
> +
> +static int cma_device_init_notifier_call(struct notifier_block *nb,
> +                                        unsigned long event, void *data)
> +{
> +       struct device *dev = data;
> +       if (event == BUS_NOTIFY_ADD_DEVICE && dev->of_node)
> +               cma_assign_device_from_dt(dev);
> +       return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block cma_dev_init_nb = {
> +       .notifier_call = cma_device_init_notifier_call,
> +};
> +
> +void scan_cma_nodes(void)
> +{
> +       struct device_node *parent = of_find_node_by_path("/chosen/contiguous-memory");
> +       struct device_node *child;
> +
> +       if (!parent)
> +               return;
> +
> +       for_each_child_of_node(parent, child) {
> +               struct cma *cma = NULL;
> +               int i;
> +
> +               for (i = 0; i < cma_area_count; i++) {
> +                       char *p = strrchr(child->full_name, '/') + 1;
> +                       if (strcmp(p, cma_areas[i].full_name) == 0)
> +                               cma = &cma_areas[i];
> +               }
> +               if (!cma)
> +                       continue;
> +
> +               for (i = 0;; i++) {
> +                       struct device_node *node;
> +                       node = of_parse_phandle(child, "device", i);
> +                       if (!node)
> +                               break;
> +
> +                       if (cma_map_count < MAX_CMA_MAPS) {
> +                               cma_maps[cma_map_count].cma = cma;
> +                               cma_maps[cma_map_count].node = node;
> +                               cma_map_count++;
> +                       } else {
> +                               pr_err("CMA error: too many devices defined\n");
> +                       }
> +               }
> +       }
> +}
> +#endif
> +
>  static int __init cma_init_reserved_areas(void)
>  {
>         int i;
> @@ -275,6 +403,10 @@ static int __init cma_init_reserved_areas(void)
>                         return ret;
>         }
>
> +#ifdef CONFIG_OF
> +       scan_cma_nodes();
> +       bus_register_notifier(&platform_bus_type, &cma_dev_init_nb);
> +#endif
>         return 0;
>  }
>  core_initcall(cma_init_reserved_areas);
> --
> 1.7.9.5
>


From nm at ti.com  Thu Jul 11 10:59:16 2013
From: nm at ti.com (Nishanth Menon)
Date: Thu, 11 Jul 2013 09:59:16 -0500
Subject: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and
 twl6040 setup for legacy boot
In-Reply-To: <1373552638-13930-1-git-send-email-peter.ujfalusi@ti.com>
References: <1373552638-13930-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <20130711145916.GA6138@kahuna>

On 16:23-20130711, Peter Ujfalusi wrote:
> OMAP4 no longer boots in legacy mode so the code here is no longer used.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> ---
>  arch/arm/mach-omap2/twl-common.c | 332 ++-------------------------------------
>  arch/arm/mach-omap2/twl-common.h |   8 -
>  2 files changed, 12 insertions(+), 328 deletions(-)
Could we modify the Makefile and build twl-common.o only for
CONFIG_ARCH_OMAP3?

We could get rid of all the #ifdef from the code that way. OMAP3 is the
only platform that still depends on this - Further, with this change,

commit 34a38440689b06a515104d668494e0ff8a4e1537
(regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators)
will need a relook as well. currently part of the discussion with Mark
in [1]


[1] http://marc.info/?t=137185016300003&r=1&w=2


-- 
Regards,
Nishanth Menon


From hanjun.guo at linaro.org  Thu Jul 11 11:10:51 2013
From: hanjun.guo at linaro.org (Hanjun Guo)
Date: Thu, 11 Jul 2013 23:10:51 +0800
Subject: [RFC PATCH 0/5] arm64: initial CPU_HOTPLUG support
In-Reply-To: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
References: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
Message-ID: <51DECAFB.4010800@linaro.org>

Hi Mark,

I tested this patch set on the armv8 foundation model, it's panic.

I seems that we need to do something more, I'll also checkout
what's going on here.

Thanks
Hanjun

dump formation:
root at genericarmv8:/sys/devices/system/cpu/cpu3# echo 0 > online
CPU3: Booted secondary processor
CPU3: shutdown
BUG: failure at kernel/time/clockevents.c:284/clockevents_register_device()!
Kernel panic - not syncing: BUG!
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 3.10.0+ #2
Call trace:
[<ffffffc0000873e0>] dump_backtrace+0x0/0x12c
[<ffffffc000087520>] show_stack+0x14/0x1c
[<ffffffc0003f2e7c>] dump_stack+0x20/0x28
[<ffffffc0003efd24>] panic+0xe8/0x214
[<ffffffc0000d049c>] clockevents_set_mode+0x0/0x6c
[<ffffffc0000d074c>] clockevents_config_and_register+0x24/0x30
[<ffffffc0003ef840>] arch_timer_setup+0xd8/0x140
[<ffffffc0003ef8f0>] arch_timer_cpu_notify+0x48/0xc8
[<ffffffc0000b83e4>] notifier_call_chain+0x48/0x88
[<ffffffc0000b8500>] __raw_notifier_call_chain+0xc/0x14
[<ffffffc0000973f0>] __cpu_notify+0x30/0x58
[<ffffffc00009742c>] cpu_notify+0x14/0x1c
[<ffffffc0003ed46c>] notify_cpu_starting+0x14/0x1c
[<ffffffc0003ece74>] secondary_start_kernel+0xc0/0xf4
CPU2: stopping
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.10.0+ #2
Call trace:
[<ffffffc0000873e0>] dump_backtrace+0x0/0x12c
[<ffffffc000087520>] show_stack+0x14/0x1c
[<ffffffc0003f2e7c>] dump_stack+0x20/0x28
[<ffffffc00008da8c>] handle_IPI+0x120/0x130
[<ffffffc0000812e0>] gic_handle_irq+0x7c/0x80
Exception stack(0xffffffc87fc8de30 to 0xffffffc87fc8df50)
de20: 7fc8c000 ffffffc8 005a1c8b ffffffc0
de40: 7fc8df70 ffffffc8 00084540 ffffffc0 00000e90 00000000 00000000 
00000000
de60: 3ffbb9ec ffffffc0 00010000 00000000 00000020 00000000 00000000 
00000000
de80: 3ffbb7f8 ffffffc0 00000000 00000000 7fc5ddd0 ffffffc8 7fc8dd80 
ffffffc8
dea0: 003fb8e4 ffffffc0 03ee8b1d 00000000 003fb8e8 ffffffc0 00000000 
00000000
dec0: 1f7458e8 ffffffbc 00001000 00000000 00000001 00000000 00002000 
00000000
dee0: 00000000 00000000 7fc8c000 ffffffc8 005a1c8b ffffffc0 00000001 
00000000
df00: 004dc3f0 ffffffc0 005adf00 ffffffc0 003faca0 ffffffc0 8007b000 
00000000
df20: 8007d000 00000000 000801a0 ffffffc0 80080188 00000000 7fc8df70 
ffffffc8
df40: 0008453c ffffffc0 7fc8df70 ffffffc8
[<ffffffc0000835ac>] el1_irq+0x6c/0xc0
[<ffffffc0000ca4f4>] cpu_startup_entry+0xf0/0x138
[<ffffffc0003ece9c>] secondary_start_kernel+0xe8/0xf4
CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.10.0+ #2
Call trace:
[<ffffffc0000873e0>] dump_backtrace+0x0/0x12c
[<ffffffc000087520>] show_stack+0x14/0x1c
[<ffffffc0003f2e7c>] dump_stack+0x20/0x28
[<ffffffc00008da8c>] handle_IPI+0x120/0x130
[<ffffffc0000812e0>] gic_handle_irq+0x7c/0x80
Exception stack(0xffffffc87fc8be30 to 0xffffffc87fc8bf50)
be20: 7fc8a000 ffffffc8 005a1c8b ffffffc0
be40: 7fc8bf70 ffffffc8 00084540 ffffffc0 00002088 00000000 00000000 
00000000
be60: 3ffb19ec ffffffc0 00010000 00000000 00000010 00000000 0fcf5932 
0000274b
be80: aba36180 0000008d 7f7bd8b0 ffffffc8 7fc5d4d0 ffffffc8 7fc8bd80 
ffffffc8
bea0: 00004d30 00000001 00000020 00000000 003fb8e8 ffffffc0 ae892f33 
ffffffff
bec0: 46000000 0021a0f7 00000000 003b9aca 0016dae4 ffffffc0 94294800 
0000007f
bee0: f0587350 0000007f 7fc8a000 ffffffc8 005a1c8b ffffffc0 00000001 
00000000
bf00: 004dc3f0 ffffffc0 005adf00 ffffffc0 003faca0 ffffffc0 8007b000 
00000000
bf20: 8007d000 00000000 000801a0 ffffffc0 80080188 00000000 7fc8bf70 
ffffffc8
bf40: 0008453c ffffffc0 7fc8bf70 ffffffc8
[<ffffffc0000835ac>] el1_irq+0x6c/0xc0
[<ffffffc0000ca4f4>] cpu_startup_entry+0xf0/0x138
[<ffffffc0003ece9c>] secondary_start_kernel+0xe8/0xf4
CPU: 0 PID: 957 Comm: sh Not tainted 3.10.0+ #2
Call trace:
[<ffffffc0000873e0>] dump_backtrace+0x0/0x12c
[<ffffffc000087520>] show_stack+0x14/0x1c
[<ffffffc0003f2e7c>] dump_stack+0x20/0x28
[<ffffffc00008da8c>] handle_IPI+0x120/0x130
[<ffffffc0000812e0>] gic_handle_irq+0x7c/0x80
Exception stack(0xffffffc87e1e7a70 to 0xffffffc87e1e7b90)
7a60: 00000007 00000000 0057b000 ffffffc0
7a80: 7e1e7bb0 ffffffc8 00096044 ffffffc0 00000000 00000000 3fa41000 
00000000
7aa0: 00000000 00000000 3ffa73d8 ffffffc0 00000000 00000000 00000000 
00000000
7ac0: 005b1000 ffffffc0 7e1e6000 ffffffc8 00000002 00000000 0057b000 
ffffffc0
7ae0: 00000001 00000000 00000030 00000000 000012b0 00000000 00000000 
00000000
7b00: 000000a6 00000000 00000006 00000000 005a8000 ffffffc0 b62e09b8 
0000007f
7b20: c32ba320 0000007f 00000007 00000000 0057b000 ffffffc0 00000005 
00000000
7b40: 005a4758 ffffffc0 00000140 00000000 0000000e 00000000 00000000 
00000000
7b60: 00000000 00000000 0000000e 00000000 00000006 00000000 7e1e7bb0 
ffffffc8
7b80: 000960f8 ffffffc0 7e1e7bb0 ffffffc8
[<ffffffc0000835ac>] el1_irq+0x6c/0xc0
[<ffffffc0003efec4>] printk+0x74/0x7c
[<ffffffc0003ecf68>] __cpu_die+0x50/0x8c
[<ffffffc0003eacd4>] _cpu_down.constprop.2+0xec/0x280
[<ffffffc0003eae8c>] cpu_down+0x24/0x40
[<ffffffc0003ebca4>] store_online+0x40/0xa4
[<ffffffc0002f1bf4>] dev_attr_store+0x18/0x28
[<ffffffc00018c0ec>] sysfs_write_file+0xdc/0x154
[<ffffffc00012fefc>] vfs_write+0xac/0x1a4
[<ffffffc00013032c>] SyS_write+0x44/0x8c


On 2013?07?11? 06:11, Mark Rutland wrote:
> The following patches add basic CPU_HOTPLUG support to arm64, which
> combined with appropriate firmware (e.g. [1]) can be used to power CPUs
> up and down dynamically. From discussions at connect it seemed that
> several people were interested in working in this area, so I thought I'd
> make my current implementation public now that I've managed to regain
> access to my inbox.
>
> I've tested this series with the bootwrapper PSCI implementation I've
> placed on linux-arm.org [1] and a modified foundation model dts with a
> psci node and each CPU's enable-method set to "psci", using a shell
> while repeatedly cycling all cpus off and on:
>
> for C in $(seq 0 3); do
> 	./cyclichotplug.sh $C >/dev/null 2>&1 &
> done
>
> ---->8----
> #!/bin/sh
> # cyclichotplug.sh
>
> CPU=$1;
>
> if [ -z "$CPU" ]; then
> 	printf "Usage: $0 <cpu id>\n";
> 	exit 1;
> fi
>
> ONLINEFILE=/sys/devices/system/cpu/cpu$CPU/online;
>
> while true; do
> 	echo 0 > $ONLINEFILE;
> 	echo 1 > $ONLINEFILE;
> done
> ---->8----
>
> Patches are based on v3.10.
>
> Thanks,
> Mark.
>
> [1] http://linux-arm.org/git?p=boot-wrapper-aarch64.git;a=shortlog;h=refs/tags/simple-psci
>
> Mark Rutland (5):
>    arm64: reorganise smp_enable_ops
>    arm64: factor out spin-table boot method
>    arm64: read enable-method for CPU0
>    arm64: add CPU_HOTPLUG infrastructure
>    arm64: add PSCI CPU_OFF-based hotplug support
>
>   arch/arm64/Kconfig                 |    7 ++
>   arch/arm64/include/asm/irq.h       |    1 +
>   arch/arm64/include/asm/smp.h       |   37 +++++--
>   arch/arm64/kernel/cputable.c       |    2 +-
>   arch/arm64/kernel/head.S           |   12 +-
>   arch/arm64/kernel/irq.c            |   61 ++++++++++
>   arch/arm64/kernel/process.c        |    7 ++
>   arch/arm64/kernel/smp.c            |  215 ++++++++++++++++++++++--------------
>   arch/arm64/kernel/smp_psci.c       |   54 +++++++--
>   arch/arm64/kernel/smp_spin_table.c |   85 +++++++++++++-
>   arch/arm64/kernel/vmlinux.lds.S    |    1 -
>   11 files changed, 375 insertions(+), 107 deletions(-)
>



From stern at rowland.harvard.edu  Thu Jul 11 11:14:29 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Thu, 11 Jul 2013 11:14:29 -0400 (EDT)
Subject: [PATCH 6/6] USB: ehci-omap: Implement suspend/resume
In-Reply-To: <51DE71F3.1040101@ti.com>
Message-ID: <Pine.LNX.4.44L0.1307111106090.1276-100000@iolanthe.rowland.org>

On Thu, 11 Jul 2013, Roger Quadros wrote:

> > The other two problems are both related to the interaction between
> > system PM and runtime PM.  Suppose the controller is already runtime
> > suspended when the system goes to sleep.  Because it is runtime
> > suspended, it is enabled for wakeup.  But device_may_wakeup() could
> > return false; if this happens then you have to do a runtime-resume in
> > omap_ehci_suspend() before calling ehci_suspend(), so that the
> > controller can be suspended again with wakeups disabled.  (Or you could
> > choose an alternative method for accomplishing the same result, such as
> > disabling the wakeup signal from the pad without going through a whole
> > EHCI resume/suspend cycle.)  Conversely, if device_may_wakeup() returns
> > true then you shouldn't do anything at all, because the controller is
> > already suspended with the correct wakeup setting.
> 
> I think this case is taken care of by the Runtime PM core at least for the OMAP
> platform according to the documentation
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/power/runtime_pm.txt#n647

No; that section refers only to races, not to wakeup settings.

> At the end of this mail is the log during system suspend/resume
> 
> You can notice the following sequence
> 
> -ehci runtime suspends
> -system suspend triggered
> -ehci runtime resumes
> -ehci suspends (uses new wakeup settings)
> -system wakeup triggered
> -ehci resumes
> -ehci runtime suspends

This is because the root hub was runtime suspended with the wrong
wakeup setting.  The USB core, which is careful about these things,
resumed and re-suspended it with the proper wakeup setting.  In the 
process, the controller had to be runtime resumed as well.

Try doing the test over again, but this time with the root hub enabled 
for wakeup and the controller disabled.  (I know this is a bizarre 
combination, but try it anyway.)  Also, after the system wakes up, see 
whether the root hub and controller get runtime suspended.

> > For the third problem, suppose the controller was runtime suspended
> > when the system went to sleep.  When the system wakes up, the
> > controller will become active, so you have to inform the runtime PM
> > core about its change of state.  Basically, if omap_ehci_resume() sees
> > that ehci_resume() returned 0 then it must do:
> > 
> > 	pm_runtime_disable(dev);
> > 	pm_runtime_set_active(dev);
> > 	pm_runtime_enable(dev);
> > 
> > All of these issues are discussed (among lots of other material) in 
> > Documentation/power/runtime_pm.txt.
> 
> Is this still applicable? Documentation claims
> 
>    "During system resume it calls pm_runtime_enable() and pm_runtime_put_sync()
>     for every device right after executing the subsystem-level .resume_early()
>     callback and right after executing the subsystem-level .resume() callback
>     for it, respectively."

Yes, this is applicable, but it is irrelevant to the problem I 
described.  You still have to tell the runtime PM core that the device 
is now active.

Alan Stern



From zonque at gmail.com  Thu Jul 11 11:17:52 2013
From: zonque at gmail.com (Daniel Mack)
Date: Thu, 11 Jul 2013 17:17:52 +0200
Subject: [PATCH 0/5] Assorted patches for pxa-gpio
Message-ID: <1373555877-29887-1-git-send-email-zonque@gmail.com>

Hi Eric,
Hi Haojian,

here are some patches for gpio-pxa and its bindings. They fix some
flaws I came across while trying to boot a PXA3xx board with v3.10+.


Best regards,
Daniel

Daniel Mack (5):
  gpio: pxa: remove dead code
  gpio: pxa: fix Documentation of interrupt-names property
  gpio: pxa: Documentation: provide example bindings for PXA3xx
  ARM: pxa: fix DT auxdata for pxa3xx-gpio
  ARM: pxa: DTS: override gpio node in pxa3xx.dtsi

 .../devicetree/bindings/gpio/mrvl-gpio.txt         | 22 ++++++++++++++++++----
 arch/arm/boot/dts/pxa3xx.dtsi                      | 11 +++++++++++
 arch/arm/mach-pxa/pxa-dt.c                         |  2 +-
 drivers/gpio/gpio-pxa.c                            | 13 +++----------
 4 files changed, 33 insertions(+), 15 deletions(-)

-- 
1.8.1.4



From zonque at gmail.com  Thu Jul 11 11:17:54 2013
From: zonque at gmail.com (Daniel Mack)
Date: Thu, 11 Jul 2013 17:17:54 +0200
Subject: [PATCH 2/5] gpio: pxa: fix Documentation of interrupt-names property
In-Reply-To: <1373555877-29887-1-git-send-email-zonque@gmail.com>
References: <1373555877-29887-1-git-send-email-zonque@gmail.com>
Message-ID: <1373555877-29887-3-git-send-email-zonque@gmail.com>

The property name to pass names for interrupt resources is called
"interrupt-names", not "interrupt-name". Fix it to avoid further
confusion.

Signed-off-by: Daniel Mack <zonque at gmail.com>
Cc: Haojian Zhuang <haojian.zhuang at linaro.org>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
---
 Documentation/devicetree/bindings/gpio/mrvl-gpio.txt | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
index 9b3f1d4..6641626 100644
--- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
@@ -10,8 +10,9 @@ Required properties:
   There're three gpio interrupts in arch-pxa, and they're gpio0,
   gpio1 and gpio_mux. There're only one gpio interrupt in arch-mmp,
   gpio_mux.
-- interrupt-name : Should be the name of irq resource. Each interrupt
-  binds its interrupt-name.
+- interrupt-names : Should be the names of irq resources. Each interrupt
+  uses its own interrupt name, so there should be as many interrupt names
+  as referenced interrups.
 - interrupt-controller : Identifies the node as an interrupt controller.
 - #interrupt-cells: Specifies the number of cells needed to encode an
   interrupt source.
@@ -24,7 +25,7 @@ Example:
 		compatible = "marvell,mmp-gpio";
 		reg = <0xd4019000 0x1000>;
 		interrupts = <49>;
-		interrupt-name = "gpio_mux";
+		interrupt-names = "gpio_mux";
 		gpio-controller;
 		#gpio-cells = <1>;
 		interrupt-controller;
-- 
1.8.1.4



From zonque at gmail.com  Thu Jul 11 11:17:55 2013
From: zonque at gmail.com (Daniel Mack)
Date: Thu, 11 Jul 2013 17:17:55 +0200
Subject: [PATCH 3/5] gpio: pxa: Documentation: provide example bindings for
 PXA3xx
In-Reply-To: <1373555877-29887-1-git-send-email-zonque@gmail.com>
References: <1373555877-29887-1-git-send-email-zonque@gmail.com>
Message-ID: <1373555877-29887-4-git-send-email-zonque@gmail.com>

Add another example to describe bindings that work for PXA3xx boards.

Signed-off-by: Daniel Mack <zonque at gmail.com>
---
 Documentation/devicetree/bindings/gpio/mrvl-gpio.txt | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
index 6641626..b2afdb2 100644
--- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
@@ -19,7 +19,7 @@ Required properties:
 - gpio-controller : Marks the device node as a gpio controller.
 - #gpio-cells : Should be one.  It is the pin number.
 
-Example:
+Example for a MMP platform:
 
 	gpio: gpio at d4019000 {
 		compatible = "marvell,mmp-gpio";
@@ -32,6 +32,19 @@ Example:
 		#interrupt-cells = <1>;
       };
 
+Example for a PXA3xx platform:
+
+	gpio: gpio at 40e00000 {
+		compatible = "intel,pxa3xx-gpio";
+		reg = <0x40e00000 0x10000>;
+		interrupt-names = "gpio0", "gpio1", "gpio_mux";
+		interrupts = <8 9 10>;
+		gpio-controller;
+		#gpio-cells = <0x2>;
+		interrupt-controller;
+		#interrupt-cells = <0x2>;
+	};
+
 * Marvell Orion GPIO Controller
 
 Required properties:
-- 
1.8.1.4



From zonque at gmail.com  Thu Jul 11 11:17:53 2013
From: zonque at gmail.com (Daniel Mack)
Date: Thu, 11 Jul 2013 17:17:53 +0200
Subject: [PATCH 1/5] gpio: pxa: remove dead code
In-Reply-To: <1373555877-29887-1-git-send-email-zonque@gmail.com>
References: <1373555877-29887-1-git-send-email-zonque@gmail.com>
Message-ID: <1373555877-29887-2-git-send-email-zonque@gmail.com>

Commit f87311743 ("ARM: mmp: add more compatible names in gpio driver")
changed the driver logic to determine the number of available GPIOs from
the compatible string, and hence obsoleted the (undocumented) child
nodes that were previously necessary. However, it left some remainder
which can be safely removed now.

Also, this patch makes pxa_gpio_probe_dt() return the correct value in
case irq_alloc_descs() fails.

Signed-off-by: Daniel Mack <zonque at gmail.com>
Cc: Haojian Zhuang <haojian.zhuang at linaro.org>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpio/gpio-pxa.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
index df2199d..cc13d1b 100644
--- a/drivers/gpio/gpio-pxa.c
+++ b/drivers/gpio/gpio-pxa.c
@@ -524,8 +524,8 @@ const struct irq_domain_ops pxa_irq_domain_ops = {
 
 static int pxa_gpio_probe_dt(struct platform_device *pdev)
 {
-	int ret, nr_gpios;
-	struct device_node *prev, *next, *np = pdev->dev.of_node;
+	int ret = 0, nr_gpios;
+	struct device_node *np = pdev->dev.of_node;
 	const struct of_device_id *of_id =
 				of_match_device(pxa_gpio_dt_ids, &pdev->dev);
 	const struct pxa_gpio_id *gpio_id;
@@ -537,20 +537,13 @@ static int pxa_gpio_probe_dt(struct platform_device *pdev)
 	gpio_id = of_id->data;
 	gpio_type = gpio_id->type;
 
-	next = of_get_next_child(np, NULL);
-	prev = next;
-	if (!next) {
-		dev_err(&pdev->dev, "Failed to find child gpio node\n");
-		ret = -EINVAL;
-		goto err;
-	}
-	of_node_put(prev);
 	nr_gpios = gpio_id->gpio_nums;
 	pxa_last_gpio = nr_gpios - 1;
 
 	irq_base = irq_alloc_descs(-1, 0, nr_gpios, 0);
 	if (irq_base < 0) {
 		dev_err(&pdev->dev, "Failed to allocate IRQ numbers\n");
+		ret = irq_base;
 		goto err;
 	}
 	domain = irq_domain_add_legacy(np, nr_gpios, irq_base, 0,
-- 
1.8.1.4



From zonque at gmail.com  Thu Jul 11 11:17:56 2013
From: zonque at gmail.com (Daniel Mack)
Date: Thu, 11 Jul 2013 17:17:56 +0200
Subject: [PATCH 4/5] ARM: pxa: fix DT auxdata for pxa3xx-gpio
In-Reply-To: <1373555877-29887-1-git-send-email-zonque@gmail.com>
References: <1373555877-29887-1-git-send-email-zonque@gmail.com>
Message-ID: <1373555877-29887-5-git-send-email-zonque@gmail.com>

Commit f87311743 ("ARM: mmp: add more compatible names in gpio driver")
changed the DT match string for pxa3xx-gpio, but left the auxdata table
unchanged.

Signed-off-by: Daniel Mack <zonque at gmail.com>
Cc: Haojian Zhuang <haojian.zhuang at linaro.org>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-pxa/pxa-dt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-pxa/pxa-dt.c b/arch/arm/mach-pxa/pxa-dt.c
index 3835979..f6a2c4b 100644
--- a/arch/arm/mach-pxa/pxa-dt.c
+++ b/arch/arm/mach-pxa/pxa-dt.c
@@ -28,7 +28,7 @@ static const struct of_dev_auxdata pxa3xx_auxdata_lookup[] __initconst = {
 	OF_DEV_AUXDATA("mrvl,pxa-uart",		0x40700000, "pxa2xx-uart.2", NULL),
 	OF_DEV_AUXDATA("mrvl,pxa-uart",		0x41600000, "pxa2xx-uart.3", NULL),
 	OF_DEV_AUXDATA("marvell,pxa-mmc",	0x41100000, "pxa2xx-mci.0", NULL),
-	OF_DEV_AUXDATA("mrvl,pxa-gpio",		0x40e00000, "pxa-gpio", NULL),
+	OF_DEV_AUXDATA("intel,pxa3xx-gpio",	0x40e00000, "pxa3xx-gpio", NULL),
 	OF_DEV_AUXDATA("marvell,pxa-ohci",	0x4c000000, "pxa27x-ohci", NULL),
 	OF_DEV_AUXDATA("mrvl,pxa-i2c",		0x40301680, "pxa2xx-i2c.0", NULL),
 	OF_DEV_AUXDATA("mrvl,pwri2c",		0x40f500c0, "pxa3xx-i2c.1", NULL),
-- 
1.8.1.4



From zonque at gmail.com  Thu Jul 11 11:17:57 2013
From: zonque at gmail.com (Daniel Mack)
Date: Thu, 11 Jul 2013 17:17:57 +0200
Subject: [PATCH 5/5] ARM: pxa: DTS: override gpio node in pxa3xx.dtsi
In-Reply-To: <1373555877-29887-1-git-send-email-zonque@gmail.com>
References: <1373555877-29887-1-git-send-email-zonque@gmail.com>
Message-ID: <1373555877-29887-6-git-send-email-zonque@gmail.com>

The gpio controller node inherited from pxa2xx.dtsi won't work for
pxa3xx SoCs, so let's override it in pxa3xx.dtsi.

Signed-off-by: Daniel Mack <zonque at gmail.com>
Cc: Haojian Zhuang <haojian.zhuang at linaro.org>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/boot/dts/pxa3xx.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/pxa3xx.dtsi b/arch/arm/boot/dts/pxa3xx.dtsi
index f9d92da..83bb0ef 100644
--- a/arch/arm/boot/dts/pxa3xx.dtsi
+++ b/arch/arm/boot/dts/pxa3xx.dtsi
@@ -28,5 +28,16 @@
 			marvell,intc-priority;
 			marvell,intc-nr-irqs = <56>;
 		};
+
+		gpio: gpio at 40e00000 {
+			compatible = "intel,pxa3xx-gpio";
+			reg = <0x40e00000 0x10000>;
+			interrupt-names = "gpio0", "gpio1", "gpio_mux";
+			interrupts = <8 9 10>;
+			gpio-controller;
+			#gpio-cells = <0x2>;
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
 	};
 };
-- 
1.8.1.4



From thomas.abraham at linaro.org  Thu Jul 11 11:19:55 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Thu, 11 Jul 2013 20:49:55 +0530
Subject: [PATCH] clk: samsung: add set_rate and round_rate callbacks for
 pll45xx
In-Reply-To: <1395018.H3ijo3R2Tj@thinkpad>
References: <1373534869-12034-1-git-send-email-thomas.abraham@linaro.org>
 <1395018.H3ijo3R2Tj@thinkpad>
Message-ID: <CAJuYYwSwNT=ymU72bY8x8PBk=BrVWzMrxGee3kaHOyk3cozv+g@mail.gmail.com>

Hi Tomasz,

Thanks for reviewing the patch. I have few comments inline below.

On 11 July 2013 15:49, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> Hi Thomas,
>
> On Thursday 11 of July 2013 14:57:49 Thomas Abraham wrote:
>> Add support for set_rate and round_rate callbacks for pll45xx pll. This
>> allows configuring pll45xx to generate a desired clock output.
>>
>> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
>> ---
>>
>> The set_rate and round_rate callbacks in this patch for pll45xx are handled
>> slightly differently from the way it is done in the (not yet merged) patch
>> series from Yadwinder
>> (http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg19540.html
>> )
>
> I think this series should be considered as already merged. All the patches
> have been already acked and are just waiting to be picked up after 3.11-rc1
> gets released.

Ok.

>
>>
>> In this patch, the pll lookup table is kept as part of the pll configuration
>> code itself, since the pll is just a hardware block which takes an input
>> frequency and configuration values to genertate a output clock frequency.
>> Given a set of inputs, a pll of a given type will generate the same output
>> regardless of the SoC it is used in.
>
> Are you sure about this? I've seen different sets of PMS(K) settings across
> different SoCs with the same PLL blocks.

Looking at Exynos4412 and Exynos5250 user manuals which uses PLL35xx,
there is only one entry of 1.2GHz which have differing values for
recommended PMS value. I am not sure if there is any issue in using a
common PMS value for 1.2Ghz for both Exynos4412 and Exynos5250.

>
>> So instead of supplying the pll lookup
>> table from per-soc clock driver code (as done in the Yadwinder's patch
>> series), the pll lookup table can be coupled with the pll code itself,
>> saving duplication of pll lookup table for every SoC the pll is used with.
>
> Yes, that would be nice to have, but we already discussed this problem a lot
> and found out that this has to be specified on per-SoC basis.

Ok.

>
>>  drivers/clk/samsung/clk-pll.c |   88
>> +++++++++++++++++++++++++++++++++++++++++ drivers/clk/samsung/clk-pll.h |
>> 15 +++++++
>>  2 files changed, 103 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
>> index 362f12d..4940936 100644
>> --- a/drivers/clk/samsung/clk-pll.c
>> +++ b/drivers/clk/samsung/clk-pll.c
>> @@ -172,6 +172,8 @@ struct clk * __init samsung_clk_register_pll36xx(const
>> char *name, * PLL45xx Clock Type
>>   */
>>
>> +#define PLL45XX_EN_MASK              (1 << 31)
>> +#define PLL45XX_LOCK_MASK    (1 << 29)
>>  #define PLL45XX_MDIV_MASK    (0x3FF)
>>  #define PLL45XX_PDIV_MASK    (0x3F)
>>  #define PLL45XX_SDIV_MASK    (0x7)
>> @@ -187,6 +189,90 @@ struct samsung_clk_pll45xx {
>>
>>  #define to_clk_pll45xx(_hw) container_of(_hw, struct samsung_clk_pll45xx,
>> hw)
>>
>> +/* a sorted table of freq supported by pll45xx with 24mhz parent clock */
>> +static struct pll45xx_freq_lookup pll45xx_freq_lookup_24mhz[] = {
>> +     PLL45XX_PMS(1000000000, 6, 250, 1),
>> +     PLL45XX_PMS(800000000, 6, 200, 1),
>> +     PLL45XX_PMS(500000000, 6, 250, 2),
>> +     PLL45XX_PMS(400000000, 6, 200, 2),
>> +     PLL45XX_PMS(200000000, 6, 200, 3),
>> +};
>> +
>> +static int samsung_pll45xx_set_rate(struct clk_hw *hw, unsigned long rate,
>> +                                     unsigned long prate)
>> +{
>> +     struct samsung_clk_pll45xx *pll = to_clk_pll45xx(hw);
>> +     struct pll45xx_freq_lookup *f;
>> +     unsigned long timeout, pll_con, cnt, idx;
>> +
>> +     /* select a lookup table based on parent clock frequency */
>> +     switch (prate) {
>> +     case 24000000:
>> +             f = pll45xx_freq_lookup_24mhz;
>> +             cnt = ARRAY_SIZE(pll45xx_freq_lookup_24mhz);
>> +             break;
>
> Do you really need to check the input frequency every time? I think you could
> just set up appropriate rate table in register function, like it is done in
> Yadwinder's patches.

There is no assumption made about the parent clock speed of the PLL.
The PLL might have been re-parented in which case the parent's clock
frequency would be different.

>
>> +     default:
>> +             pr_err("%s: unsupported parent clock rate, failed to set rate",
>> +                                     __func__);
>> +             return -EINVAL;
>> +     }
>> +
>> +     /* check if the requested freq is in the list of supported freq */
>> +     for (idx = 0; idx < cnt; idx++, f++)
>> +             if (f->target_freq == rate)
>> +                     break;
>
> You don't have to check all the entries if you keep the PMS table sorted. You
> just have to look for first entry that has frequency less or equal to requested
> one.

Yes, the lookup table above is sorted in descending order and this
lookup code is aware of the order and works as you described.

>
>> +
>> +     if (idx == cnt) {
>> +             pr_err("%s: unspported clock speed %ld requested\n",
>> +                             __func__, rate);
>> +             return -EINVAL;
>> +     }
>> +
>> +     /* first, disable the output of the pll */
>> +     writel(readl(pll->con_reg) & ~PLL45XX_EN_MASK, (void *)pll->con_reg);
>> +
>> +     /* write the new pll configuration values */
>> +     pll_con = (f->pdiv << PLL45XX_PDIV_SHIFT) |
>> +                     (f->mdiv << PLL45XX_MDIV_SHIFT) |
>> +                     (f->sdiv << PLL45XX_SDIV_SHIFT);
>> +     writel(pll_con, (void *)pll->con_reg);
>> +
>> +     /* enable the pll and wait for it to stabilize */
>> +     writel(pll_con | PLL45XX_EN_MASK, (void *)pll->con_reg);
>> +     timeout = jiffies + msecs_to_jiffies(20);
>> +     while (time_before(jiffies, timeout))
>> +             if (readl(pll->con_reg) & PLL45XX_LOCK_MASK)
>> +                     return 0;
>> +     return -EBUSY;
>> +}
>> +
>> +static long samsung_pll45xx_round_rate(struct clk_hw *hw, unsigned long
>> rate, +                                               unsigned long *prate)
>> +{
>> +     struct pll45xx_freq_lookup *f;
>> +     unsigned long cnt;
>> +
>> +     /* select a lookup table based on parent clock frequency */
>> +     switch (*prate) {
>> +     case 24000000:
>> +             f = pll45xx_freq_lookup_24mhz;
>> +             cnt = ARRAY_SIZE(pll45xx_freq_lookup_24mhz);
>> +             break;
>> +     default:
>> +             pr_err("%s: unsupported parent clock rate", __func__);
>> +             return *prate;
>> +     }
>
> Again, PMS table can be set in register function and just used here.

Ok, but it would be good to give another thought about having the
lookup table tied to the pll configuration code. If required, we could
have both options implemented. A pll will have a default PMS lookup
table here and if a SoC specific table is needed, it can be supplied
at the time of PLL registration.

>
>> +     /* find the nearest possible clock output that can be supported */
>> +     while (cnt-- > 0) {
>> +             if (rate >= f->target_freq)
>> +                     return f->target_freq;
>> +             f++;
>> +     }
>> +
>> +     return (--f)->target_freq;
>> +}
>> +
>>  static unsigned long samsung_pll45xx_recalc_rate(struct clk_hw *hw,
>>                               unsigned long parent_rate)
>>  {
>> @@ -209,6 +295,8 @@ static unsigned long samsung_pll45xx_recalc_rate(struct
>> clk_hw *hw, }
>>
>>  static const struct clk_ops samsung_pll45xx_clk_ops = {
>> +     .set_rate = samsung_pll45xx_set_rate,
>> +     .round_rate = samsung_pll45xx_round_rate,
>>       .recalc_rate = samsung_pll45xx_recalc_rate,
>>  };
>>
>> diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
>> index f33786e..fb687ec 100644
>> --- a/drivers/clk/samsung/clk-pll.h
>> +++ b/drivers/clk/samsung/clk-pll.h
>> @@ -18,6 +18,21 @@ enum pll45xx_type {
>>       pll_4508
>>  };
>>
>> +struct pll45xx_freq_lookup {
>> +     unsigned long   target_freq;
>> +     unsigned long   pdiv;
>> +     unsigned long   mdiv;
>> +     unsigned long   sdiv;
>> +};
>> +
>> +#define PLL45XX_PMS(f, p, m, s)              \
>> +     {                                       \
>> +             .target_freq    = f,            \
>> +             .pdiv           = p,            \
>> +             .mdiv           = m,            \
>> +             .sdiv           = s,            \
>> +     }
>> +
>>  enum pll46xx_type {
>>       pll_4600,
>>       pll_4650,
>
> Basically, I would prefer the way introduced by Yadwinder's and Vikas' patches
> to be used. We already discussed all the aspects during all the 7 versions of
> those patches and decided to go with that solution, so for the case of
> consistency, same should be used for remaining PLLs.

Ok, but could we look at this once more. We could avoid duplication of
PLL tables if the lookup tables are kept generic. It would be nice to
get opinions from others as well on this.

>
> Best regards,
> Tomasz
>

Thanks,
Thomas.


From thomas.abraham at linaro.org  Thu Jul 11 11:24:51 2013
From: thomas.abraham at linaro.org (Thomas Abraham)
Date: Thu, 11 Jul 2013 20:54:51 +0530
Subject: [PATCH] clk: samsung: add set_rate and round_rate callbacks for
 pll45xx
In-Reply-To: <CAKew6eV0QP31gJNB2waeSRB5DN5Vs+mXO5bwaD5TiHYZvrANQA@mail.gmail.com>
References: <1373534869-12034-1-git-send-email-thomas.abraham@linaro.org>
 <CAKew6eV0QP31gJNB2waeSRB5DN5Vs+mXO5bwaD5TiHYZvrANQA@mail.gmail.com>
Message-ID: <CAJuYYwSSQ49Tp17Kja9sZgnibYR7UDrvSpoyPUs0i6GC6j2qeA@mail.gmail.com>

Hi Yadwinder,

Thanks for your comments.

On 11 July 2013 16:14, Yadwinder Singh Brar <yadi.brar01 at gmail.com> wrote:
> Hi Thomas,
>
> On Thu, Jul 11, 2013 at 2:57 PM, Thomas Abraham
> <thomas.abraham at linaro.org> wrote:
>> Add support for set_rate and round_rate callbacks for pll45xx pll. This allows
>> configuring pll45xx to generate a desired clock output.
>>
>> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
>> ---
>>
>> The set_rate and round_rate callbacks in this patch for pll45xx are handled
>> slightly differently from the way it is done in the (not yet merged) patch
>> series from Yadwinder
>> (http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg19540.html)
>>
>> In this patch, the pll lookup table is kept as part of the pll configuration
>> code itself, since the pll is just a hardware block which takes an input
>> frequency and configuration values to genertate a output clock frequency.
>> Given a set of inputs, a pll of a given type will generate the same output
>> regardless of the SoC it is used in. So instead of supplying the pll lookup
>
> Tomasz also raised similar point earlier in discussion on that series.
> That time a question which remained unanswered for which we were waiting
> (as requested from hardware guys also) was that :
> Whether we need to stick to recommended values only or we can drive a
> particular output frequency with a given input frequency with any possible
> set of (P, M, S) values ?

The default lookup table could list all the possible target frequency
and its associated PMS values. Having a bigger list of PMS lookup
values should not matter since the CPUFreq driver would have a smaller
subset of frequency which can be selected on a particular SoC.

>
> Theoretically it seems possible but from manual its seems to prefer
> recommended values.
> Also I am not sure whether same values are always recommended in user manuals
> for different SoCs using same PLL type.
>
>> table from per-soc clock driver code (as done in the Yadwinder's patch series),
>> the pll lookup table can be coupled with the pll code itself, saving duplication
>> of pll lookup table for every SoC the pll is used with.
>
> If we don't need to stick to recommended table, definitely it will
> save lot of duplication.
> In-fact then we can use same pll lookup table for other PLLs also
> which have same calculation
> equation for output frequency.

Ok.

>
>
> Regards,
> Yadwinder

Thanks,
Thomas.

[...]


From sr at denx.de  Thu Jul 11 11:34:14 2013
From: sr at denx.de (Stefan Roese)
Date: Thu, 11 Jul 2013 17:34:14 +0200
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51DEC2CE.70400@ti.com>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de> <51DE87D3.5030600@ti.com>
 <51DEA7F1.1050902@denx.de> <51DEC2CE.70400@ti.com>
Message-ID: <51DED076.3040000@denx.de>

On 07/11/2013 04:35 PM, Roger Quadros wrote:
>> BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
>> Do you have any patches locally applied to the kernel.org version that
>> might be helpful with this USB issue I'm seeing?
> 
> Yes I had tested it on a more recent kernel with some local patches applied
> that I've recently sent for review.
> 
> But to cross check with your setup I've retested it with commit d2b4a646 
> with the 2 below patches on top
> 
> https://lkml.org/lkml/2013/6/20/327
> https://lkml.org/lkml/2013/6/20/339

Thanks. I have exactly those 2 patches applies as well. But on a
different git commit. And with some local (unrelated) patches as well.
I'll revert to exactly your version tomorrow and test again.

> I've tried it again with the ELDK 5.3 root but still can't get it to fail.
> 
> I think we should match our u-boot as well. Could you please let me know
> your u-boot commit and uEnv.txt?

Good idea. I'm currently using a "dirty" local version. I'll try to
switch to an officially available version tomorrow. And send you the
version/git id.

> My network setup is pretty simple, beagle-xm is connected directly to my laptop's
> ethernet port. No network switch in between.

I have a switch in between the target and my PC. But this network setup
is also quite "simple" and works with all other boards as well. So this
shouldn't be a problem.

> When you get the problem do you cold boot the board or warm boot it?
> I've been always cold booting it.

I'm usually warm booting (pushbutton reset).

As mentioned above, I have some "homework" now to move to a
setup/configuration (official git commits) that you can reproduce on
your version C2 beagleboard as well. Stay tuned... ;)

Thanks,
Stefan



From thierry.reding at gmail.com  Thu Jul 11 11:36:00 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 11 Jul 2013 08:36:00 -0700
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <1373553468-6564-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1373553468-6564-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <20130711153559.GB2198@dhcp-172-17-186-34.nvidia.com>

On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote:
[...]
> diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> index de0eaed..be09be4 100644
> --- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> @@ -4,9 +4,9 @@ Required properties:
>  - compatible: should be "atmel,tcb-pwm"
>  - #pwm-cells: Should be 3.  The first cell specifies the per-chip index
>    of the PWM to use, the second cell is the period in nanoseconds and
> -  bit 0 in the third cell is used to encode the polarity of PWM output.
> -  Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity &
> -  set to 0 for normal polarity.
> +  the third cell is used to encode the polarity of PWM output. Set the
> +  PWM_POLARITY_NORMAL flag for normal polarity or the PWM_POLARITY_INVERSED
> +  flag for inverted polarity. PWM flags are defined in <dt-bindings/pwm/pwm.h>.
>  - tc-block: The Timer Counter block to use as a PWM chip.
>  
>  Example:

I'd prefer for the original text to stay in place and the reference to
the dt-bindings/pwm/pwm.h file to go below that block. The reason is
that perhaps somebody will look at an older version of a given DT (with
the numerical value) and not have access to the include and therefore
not know which flag was being set by just looking at the documentation.
I'm also not sure about what the plans are with respect to shipping
device trees in a separate repository and if they are, whether that
repository would ship the includes as well.

Another issue might be that people without access to recent versions of
DTC won't be able to use the new #include feature, so keeping the
documentation backwards compatible seems like a good idea.

Perhaps the include file should even only be mentioned in the general
PWM binding documentation.

Perhaps Grant and Rob (Cc'ed) can comment on how they want to handle
this.

> diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
> index ac67c68..bece18b 100644
> --- a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
> +++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
> @@ -24,8 +24,9 @@ Required properties:
>       - phandle to PWM controller node
>       - index of PWM channel (from 0 to 4)
>       - PWM signal period in nanoseconds
> -     - bitmask of optional PWM flags:
> -        0x1 - invert PWM signal
> +     - bitmask of optional PWM flags as defined in <dt-bindings/pwm/pwm.h>:
> +        PWM_POLARITY_NORMAL - normal polarity
> +	PWM_POLARITY_INVERSED - inverted polarity

This part mixes spaces and tabs for indentation. Please stick to spaces.

> diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt b/Documentation/devicetree/bindings/pwm/pwm.txt
> index 06e6724..38c357a 100644
> --- a/Documentation/devicetree/bindings/pwm/pwm.txt
> +++ b/Documentation/devicetree/bindings/pwm/pwm.txt
> @@ -43,13 +43,15 @@ because the name "backlight" would be used as fallback anyway.
>  pwm-specifier typically encodes the chip-relative PWM number and the PWM
>  period in nanoseconds.
>  
> -Optionally, the pwm-specifier can encode a number of flags in a third cell:
> -- bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity)
> +Optionally, the pwm-specifier can encode a number of flags (defined in
> +<dt-bindings/gpio/gpio.h>) in a third cell:
> +- PWM_POLARITY_NORMAL: use the normal PWM signal polarity
> +- PWM_POLARITY_INVERSED: invert the PWM signal polarity

You'd have a hard time finding those in the GPIO header. =)

> diff --git a/include/dt-bindings/pwm/pwm.h b/include/dt-bindings/pwm/pwm.h
> new file mode 100644
> index 0000000..f82be30
> --- /dev/null
> +++ b/include/dt-bindings/pwm/pwm.h
> @@ -0,0 +1,15 @@
> +/*
> + * This header provides constants for most PWM bindings.
> + *
> + * Most PWM bindings can include a flags cell as part of the PWM specifier.
> + * In most cases, the format of the flags cell uses the standard values
> + * defined in this header.
> + */
> +
> +#ifndef _DT_BINDINGS_PWM_PWM_H
> +#define _DT_BINDINGS_PWM_PWM_H
> +
> +#define PWM_POLARITY_NORMAL			(0 << 0)
> +#define PWM_POLARITY_INVERSED			(1 << 0)
> +
> +#endif

I think this should go into a patch separate from the DT changes above
because they'll likely go in via different trees. Or maybe they won't,
but it'd still be good to introduce the header first and only then
change the DTS files.

> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
[...]
>  enum pwm_polarity {
> -	PWM_POLARITY_NORMAL,
> -	PWM_POLARITY_INVERSED,
> +	PWM_POLARITY_NORMAL = 0,
> +	PWM_POLARITY_INVERSED = 1,

That's what the enum values will be by default, so there's no need to be
explicit here.

Thierry
-------------- 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/20130711/f8ebd9d3/attachment.sig>

From marex at denx.de  Thu Jul 11 11:36:10 2013
From: marex at denx.de (Marek Vasut)
Date: Thu, 11 Jul 2013 17:36:10 +0200
Subject: [PATCH v12 06/13] usb: chipidea: add otg_cap attribute for otg
 capable
In-Reply-To: <1373524041-10482-7-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <1373524041-10482-7-git-send-email-peter.chen@freescale.com>
Message-ID: <201307111736.11065.marex@denx.de>

Dear Peter Chen,

> Since we need otgsc to know vbus's status at some chipidea
> controllers even it is peripheral-only mode. Besides, some
> SoCs (eg, AR9331 SoC) don't have otgsc register even
> the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS.
> We inroduce otg_cap attribute to indicate if the controller
> is otg capable, defaultly, we follow the rule that if DCCPARAMS_DC
> and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS are otg capable, but if there
> is exception, the platform can override it by device tree or platform data.
> 
> Signed-off-by: Peter Chen <peter.chen at freescale.com>
> ---
>  drivers/usb/chipidea/core.c  |   35 ++++++++++++++++++++++++++++-------
>  include/linux/usb/chipidea.h |   13 +++++++++++++
>  2 files changed, 41 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 93961ff..e8ceb04 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -405,6 +405,18 @@ static inline void ci_role_destroy(struct ci_hdrc *ci)
>  	ci_hdrc_host_destroy(ci);
>  }
> 
> +static void ci_get_otg_capable(struct ci_hdrc *ci)
> +{
> +	if (ci->platdata->otg_cap != OTG_CAP_ATTR_IS_NOT_EXISTED)

IS_NONEXISTENT , no?

[..]

Best regards,
Marek Vasut


From peter.ujfalusi at ti.com  Thu Jul 11 11:45:55 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 11 Jul 2013 17:45:55 +0200
Subject: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and
 twl6040 setup for legacy boot
In-Reply-To: <20130711145916.GA6138@kahuna>
References: <1373552638-13930-1-git-send-email-peter.ujfalusi@ti.com>
 <20130711145916.GA6138@kahuna>
Message-ID: <51DED333.9080609@ti.com>

On 07/11/2013 04:59 PM, Nishanth Menon wrote:
> On 16:23-20130711, Peter Ujfalusi wrote:
>> OMAP4 no longer boots in legacy mode so the code here is no longer used.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
>> ---
>>  arch/arm/mach-omap2/twl-common.c | 332 ++-------------------------------------
>>  arch/arm/mach-omap2/twl-common.h |   8 -
>>  2 files changed, 12 insertions(+), 328 deletions(-)
> Could we modify the Makefile and build twl-common.o only for
> CONFIG_ARCH_OMAP3?
> 
> We could get rid of all the #ifdef from the code that way. OMAP3 is the
> only platform that still depends on this - Further, with this change,

Yep, I can do that. I'll send a separate patch to do this.

> commit 34a38440689b06a515104d668494e0ff8a4e1537
> (regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators)
> will need a relook as well. currently part of the discussion with Mark
> in [1]
> 
> [1] http://marc.info/?t=137185016300003&r=1&w=2

I don't see anything touching twl-common.c/h in the series.
But at the end we should get rid of the legacy support in all of the drivers
aimed for OMAP4+ gradually since it is pointless to keep dead code. Emphasis
on gradually ;)

-- 
P?ter


From richard.genoud at gmail.com  Thu Jul 11 12:15:52 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Thu, 11 Jul 2013 18:15:52 +0200
Subject: [PATCH v5 0/7] Sound support for at91sam9x5-wm8731 based boards
Message-ID: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>

Hi,

This patchset add sound on the at91sam9x5ek board.
It's based on Nicolas Ferre's work in the 2.6.39 atmel patch for sam9x5:
https://github.com/linux4sam/linux-at91/commit/0aa157c9e71ccccf3abc30fa37eb5c95b392978d

It needs Bo Chen's patchset on the generic dmaengine (topic/atmel branch
on Mark's sound tree) and the SSC interrupts disabled (cf
http://www.spinics.net/lists/arm-kernel/msg256901.html)

Outstanding issue:
If this machine driver will support more SoCs maybe we should name it differently.


It has been tested on at91sam9g35ek, and should work on g15, g25, x25 and x35 also.

patches applies on next-20130711

[I let the original signed-off from Nicolas and Uwe in place, I don't
know if I should replace them by something like "originaly-signed-off-by"
since the code has been changed.]

Changes from v4:
 * Move the rates constraints into the codec
 * Hard code the DAI format since it cannot be changed anyway (and
remove the DT bindings accordingly)
 * Add some consistency in the functions naming (sam9x5ek/at91sam9x5ek/sam9x5)
 * Retrieve the SSC id from the SSC controller phandle
 * Clarify the atmel-ssc.txt documentation
 * Develop audio-routing documentation
 * Tidy up the includes in the machine driver

Changes from v3:
 * Remove the use of macros in device tree documentation.

Changes from v2:
 * Change atmel,sam9x5-audio-wm8731 to atmel,sam9x5-wm8731-audio for
consistency with sam9g20 machine driver.
 * Use the snd_pcm_hw_constraint() API as suggested by Mark and Lars-Peter.
 * Remove the unnecessary snd_soc_dapm_sync() call as Lars-Peter suggested.
 * Add documentation for machine driver DT binding.
 * Update atmel-ssc DT binding documentation.
 * Add GPL license instead of just the "GPL" word (hope that's ok !)

Changes from v1-RFC:
 * drop patches on SSC since Bo Chen already did the work
 * reorder patches to have the machine driver first
 * drop code already handled by the ASoC framework
 * drop unneeded SND_ATMEL_SOC_PDC config selection
 * use static snd_soc_card and  snd_soc_dai_link structures.

Best regards,
Richard.

Nicolas Ferre (1):
  sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards

Richard Genoud (6):
  sound: codec: wm8731: add rates constraints
  Documentation: DT: update atmel SSC with DMA binding
  ARM: AT91: DTS: sam9x5: add SSC DMA parameters
  ARM: AT91: DTS: sam9x5ek: add WM8731 codec
  ARM: AT91: DTS: sam9x5ek: enable SSC
  ARM: AT91: DTS: sam9x5ek: add sound configuration

 .../devicetree/bindings/misc/atmel-ssc.txt         |   23 ++-
 .../bindings/sound/atmel-sam9x5-wm8731-audio.txt   |   41 ++++
 arch/arm/boot/dts/at91sam9x5.dtsi                  |    3 +
 arch/arm/boot/dts/at91sam9x5ek.dtsi                |   24 +++
 sound/soc/atmel/Kconfig                            |   10 +
 sound/soc/atmel/Makefile                           |    2 +
 sound/soc/atmel/sam9x5_wm8731.c                    |  207 ++++++++++++++++++++
 sound/soc/codecs/wm8731.c                          |   57 +++++-
 8 files changed, 363 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
 create mode 100644 sound/soc/atmel/sam9x5_wm8731.c

-- 
1.7.10.4



From richard.genoud at gmail.com  Thu Jul 11 12:15:53 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Thu, 11 Jul 2013 18:15:53 +0200
Subject: [PATCH v5 1/7] sound: codec: wm8731: add rates constraints
In-Reply-To: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
References: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373559359-31607-2-git-send-email-richard.genoud@gmail.com>

Depending on the mclk (or crystal) selected, the wm8731 codec have some
constraints on its data sampling rates:
e.g. with a 12.288MHz or 18.432MHz crystal, the authorized rates are
8KHz, 32KHz, 48KHz and 96KHz.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 sound/soc/codecs/wm8731.c |   57 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 54 insertions(+), 3 deletions(-)

diff --git a/sound/soc/codecs/wm8731.c b/sound/soc/codecs/wm8731.c
index 5276062..fc031ed 100644
--- a/sound/soc/codecs/wm8731.c
+++ b/sound/soc/codecs/wm8731.c
@@ -45,6 +45,7 @@ static const char *wm8731_supply_names[WM8731_NUM_SUPPLIES] = {
 struct wm8731_priv {
 	struct regmap *regmap;
 	struct regulator_bulk_data supplies[WM8731_NUM_SUPPLIES];
+	const struct snd_pcm_hw_constraint_list *constraints;
 	unsigned int sysclk;
 	int sysclk_type;
 	int playback_fs;
@@ -290,6 +291,36 @@ static const struct _coeff_div coeff_div[] = {
 	{12000000, 88200, 136, 0xf, 0x1, 0x1},
 };
 
+/* rates constraints */
+static const unsigned int wm8731_rates_12000000[] = {
+	8000, 32000, 44100, 48000, 96000, 88200,
+};
+
+static const unsigned int wm8731_rates_12288000_18432000[] = {
+	8000, 32000, 48000, 96000,
+};
+
+static const unsigned int wm8731_rates_11289600_16934400[] = {
+	8000, 44100, 88200,
+};
+
+static const struct snd_pcm_hw_constraint_list wm8731_constraints_12000000 = {
+	.list = wm8731_rates_12000000,
+	.count = ARRAY_SIZE(wm8731_rates_12000000),
+};
+
+static const
+struct snd_pcm_hw_constraint_list wm8731_constraints_12288000_18432000 = {
+	.list = wm8731_rates_12288000_18432000,
+	.count = ARRAY_SIZE(wm8731_rates_12288000_18432000),
+};
+
+static const
+struct snd_pcm_hw_constraint_list wm8731_constraints_11289600_16934400 = {
+	.list = wm8731_rates_11289600_16934400,
+	.count = ARRAY_SIZE(wm8731_rates_11289600_16934400),
+};
+
 static inline int get_coeff(int mclk, int rate)
 {
 	int i;
@@ -362,17 +393,23 @@ static int wm8731_set_dai_sysclk(struct snd_soc_dai *codec_dai,
 	}
 
 	switch (freq) {
-	case 11289600:
 	case 12000000:
+		wm8731->constraints = &wm8731_constraints_12000000;
+		break;
 	case 12288000:
-	case 16934400:
 	case 18432000:
-		wm8731->sysclk = freq;
+		wm8731->constraints = &wm8731_constraints_12288000_18432000;
+		break;
+	case 16934400:
+	case 11289600:
+		wm8731->constraints = &wm8731_constraints_11289600_16934400;
 		break;
 	default:
 		return -EINVAL;
 	}
 
+	wm8731->sysclk = freq;
+
 	snd_soc_dapm_sync(&codec->dapm);
 
 	return 0;
@@ -475,12 +512,26 @@ static int wm8731_set_bias_level(struct snd_soc_codec *codec,
 	return 0;
 }
 
+static int wm8731_startup(struct snd_pcm_substream *substream,
+	struct snd_soc_dai *dai)
+{
+	struct wm8731_priv *wm8731 = snd_soc_codec_get_drvdata(dai->codec);
+
+	if (wm8731->constraints)
+		snd_pcm_hw_constraint_list(substream->runtime, 0,
+					   SNDRV_PCM_HW_PARAM_RATE,
+					   wm8731->constraints);
+
+	return 0;
+}
+
 #define WM8731_RATES SNDRV_PCM_RATE_8000_96000
 
 #define WM8731_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S20_3LE |\
 	SNDRV_PCM_FMTBIT_S24_LE)
 
 static const struct snd_soc_dai_ops wm8731_dai_ops = {
+	.startup	= wm8731_startup,
 	.hw_params	= wm8731_hw_params,
 	.digital_mute	= wm8731_mute,
 	.set_sysclk	= wm8731_set_dai_sysclk,
-- 
1.7.10.4



From richard.genoud at gmail.com  Thu Jul 11 12:15:55 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Thu, 11 Jul 2013 18:15:55 +0200
Subject: [PATCH v5 3/7] Documentation: DT: update atmel SSC with DMA binding
In-Reply-To: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
References: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373559359-31607-4-git-send-email-richard.genoud@gmail.com>

As atmel-ssc can be used with DMA, the documentation should be updated.
Also, a configuration DMA example is given.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 .../devicetree/bindings/misc/atmel-ssc.txt         |   23 +++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
index 38e51ad..a45ae08 100644
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -7,9 +7,30 @@ Required properties:
 - reg: Should contain SSC registers location and length
 - interrupts: Should contain SSC interrupt
 
-Example:
+
+Required properties for devices compatible with "atmel,at91sam9g45-ssc":
+- dmas: DMA specifier, consisting of a phandle to DMA controller node,
+  the memory interface and SSC DMA channel ID (for tx and rx).
+  See Documentation/devicetree/bindings/dma/atmel-dma.txt for details.
+- dma-names: Must be "tx", "rx".
+
+Examples:
+- PDC transfer:
 ssc0: ssc at fffbc000 {
 	compatible = "atmel,at91rm9200-ssc";
 	reg = <0xfffbc000 0x4000>;
 	interrupts = <14 4 5>;
 };
+
+- DMA transfer:
+ssc0: ssc at f0010000 {
+      compatible = "atmel,at91sam9g45-ssc";
+      reg = <0xf0010000 0x4000>;
+      interrupts = <28 4 5>;
+      dmas = <&dma0 1 13>,
+	     <&dma0 1 14>;
+      dma-names = "tx", "rx";
+      pinctrl-names = "default";
+      pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+      status = "disabled";
+};
-- 
1.7.10.4



From richard.genoud at gmail.com  Thu Jul 11 12:15:54 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Thu, 11 Jul 2013 18:15:54 +0200
Subject: [PATCH v5 2/7] sound: sam9x5_wm8731: machine driver for at91sam9x5
 wm8731 boards
In-Reply-To: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
References: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373559359-31607-3-git-send-email-richard.genoud@gmail.com>

From: Nicolas Ferre <nicolas.ferre at atmel.com>

Description of the Asoc machine driver for an at91sam9x5 based board
with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
master on the SSC/I2S interface. Its connections are a headphone jack
and an Line input jack.

[Richard: this is based on an old patch from Nicolas that I forward
ported and reworked to use only device tree]

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 .../bindings/sound/atmel-sam9x5-wm8731-audio.txt   |   41 ++++
 sound/soc/atmel/Kconfig                            |   10 +
 sound/soc/atmel/Makefile                           |    2 +
 sound/soc/atmel/sam9x5_wm8731.c                    |  207 ++++++++++++++++++++
 4 files changed, 260 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
 create mode 100644 sound/soc/atmel/sam9x5_wm8731.c

diff --git a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
new file mode 100644
index 0000000..630ef8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
@@ -0,0 +1,41 @@
+* Atmel at91sam9x5ek wm8731 audio complex
+
+Required properties:
+  - compatible: "atmel,sam9x5-wm8731-audio"
+  - atmel,model: The user-visible name of this sound complex.
+  - atmel,ssc-controller: The phandle of the SSC controller
+  - atmel,audio-codec: The phandle of the WM8731 audio codec
+  - atmel,audio-routing: A list of the connections between audio components.
+    Each entry is a pair of strings, the first being the connection's sink,
+    the second being the connection's source.
+
+Available audio endpoints for the audio-routing table:
+
+Board connectors:
+ * Headphone Jack
+ * Line In Jack
+
+sam9x5 pins:
+ * LOUT
+ * ROUT
+ * LHPOUT
+ * RHPOUT
+ * LLINEIN
+ * RLINEIN
+ * MICIN
+
+Example:
+sound {
+	compatible = "atmel,sam9x5-wm8731-audio";
+
+	atmel,model = "wm8731 @ AT91SAM9X5EK";
+
+	atmel,audio-routing =
+		"Headphone Jack", "RHPOUT",
+		"Headphone Jack", "LHPOUT",
+		"LLINEIN", "Line In Jack",
+		"RLINEIN", "Line In Jack";
+
+	atmel,ssc-controller = <&ssc0>;
+	atmel,audio-codec = <&wm8731>;
+};
diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 1c0b185..9eb8c49 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -33,6 +33,16 @@ config SND_AT91_SOC_SAM9G20_WM8731
 	  Say Y if you want to add support for SoC audio on WM8731-based
 	  AT91sam9g20 evaluation board.
 
+config SND_AT91_SOC_SAM9X5_WM8731
+	tristate "SoC Audio support for WM8731-based at91sam9x5 board"
+	depends on ATMEL_SSC && SND_ATMEL_SOC && SOC_AT91SAM9X5
+	select SND_ATMEL_SOC_SSC
+	select SND_ATMEL_SOC_DMA
+	select SND_SOC_WM8731
+	help
+	  Say Y if you want to add support for audio SoC on an
+	  at91sam9x5 based board that is using WM8731 codec.
+
 config SND_AT91_SOC_AFEB9260
 	tristate "SoC Audio support for AFEB9260 board"
 	depends on ARCH_AT91 && ATMEL_SSC && ARCH_AT91 && MACH_AFEB9260 && SND_ATMEL_SOC
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index 41967cc..7784c09 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -11,6 +11,8 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
 
 # AT91 Machine Support
 snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
+snd-soc-sam9x5-wm8731-objs := sam9x5_wm8731.o
 
 obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
+obj-$(CONFIG_SND_AT91_SOC_SAM9X5_WM8731) += snd-soc-sam9x5-wm8731.o
 obj-$(CONFIG_SND_AT91_SOC_AFEB9260) += snd-soc-afeb9260.o
diff --git a/sound/soc/atmel/sam9x5_wm8731.c b/sound/soc/atmel/sam9x5_wm8731.c
new file mode 100644
index 0000000..8ecf29f
--- /dev/null
+++ b/sound/soc/atmel/sam9x5_wm8731.c
@@ -0,0 +1,207 @@
+/*
+ * sam9x5_wm8731   --	SoC audio for AT91SAM9X5-based boards
+ *			that are using WM8731 as codec.
+ *
+ *  Copyright (C) 2011 Atmel,
+ *		  Nicolas Ferre <nicolas.ferre at atmel.com>
+ *
+ *  Copyright (C) 2013 Paratronic,
+ *		  Richard Genoud <richard.genoud at gmail.com>
+ *
+ * Based on sam9g20_wm8731.c by:
+ * Sedji Gaouaou <sedji.gaouaou at atmel.com>
+ *
+ *  This program is free software; you can redistribute  it and/or modify it
+ *  under  the terms of  the GNU General  Public License as published by the
+ *  Free Software Foundation;  either version 2 of the  License, or (at your
+ *  option) any later version.
+ *
+ */
+#include <linux/of.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/platform_device.h>
+#include <linux/device.h>
+
+#include <sound/soc.h>
+#include <sound/soc-dai.h>
+#include <sound/soc-dapm.h>
+
+#include "../codecs/wm8731.h"
+#include "atmel_ssc_dai.h"
+
+
+#define MCLK_RATE 12288000
+
+#define DRV_NAME "sam9x5-snd-wm8731"
+
+struct sam9x5_drvdata {
+	int ssc_id;
+};
+
+/*
+ * Logic for a wm8731 as connected on a at91sam9x5ek based board.
+ */
+static int sam9x5_wm8731_init(struct snd_soc_pcm_runtime *rtd)
+{
+	struct snd_soc_dai *codec_dai = rtd->codec_dai;
+	struct device *dev = rtd->dev;
+	int ret;
+
+	dev_dbg(dev, "ASoC: %s called\n", __func__);
+
+	/* set the codec system clock for DAC and ADC */
+	ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
+				     MCLK_RATE, SND_SOC_CLOCK_IN);
+	if (ret < 0) {
+		dev_err(dev, "ASoC: Failed to set WM8731 SYSCLK: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+/*
+ * Audio paths on at91sam9x5ek board:
+ *
+ *  |A| ------------> |      | ---R----> Headphone Jack
+ *  |T| <----\        |  WM  | ---L--/
+ *  |9| ---> CLK <--> | 8731 | <--R----- Line In Jack
+ *  |1| <------------ |      | <--L--/
+ */
+static const struct snd_soc_dapm_widget sam9x5_dapm_widgets[] = {
+	SND_SOC_DAPM_HP("Headphone Jack", NULL),
+	SND_SOC_DAPM_LINE("Line In Jack", NULL),
+};
+
+static struct snd_soc_dai_link sam9x5_dai = {
+	.name = "WM8731",
+	.stream_name = "WM8731 PCM",
+	.codec_dai_name = "wm8731-hifi",
+	.init = sam9x5_wm8731_init,
+	.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
+		| SND_SOC_DAIFMT_CBM_CFM,
+};
+
+static struct sam9x5_drvdata sam9x5_priv;
+
+static struct snd_soc_card snd_soc_sam9x5 = {
+	.owner = THIS_MODULE,
+	.dai_link = &sam9x5_dai,
+	.num_links = 1,
+	.dapm_widgets = sam9x5_dapm_widgets,
+	.num_dapm_widgets = ARRAY_SIZE(sam9x5_dapm_widgets),
+	.drvdata = &sam9x5_priv,
+};
+
+static int sam9x5_wm8731_driver_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *codec_np, *cpu_np;
+	int ret;
+
+	if (!np) {
+		dev_err(&pdev->dev, "No device node supplied\n");
+		return -EINVAL;
+	}
+
+	snd_soc_sam9x5.dev = &pdev->dev;
+
+	ret = snd_soc_of_parse_card_name(&snd_soc_sam9x5, "atmel,model");
+	if (ret) {
+		dev_err(&pdev->dev, "atmel,model node missing\n");
+		goto out;
+	}
+
+	ret = snd_soc_of_parse_audio_routing(&snd_soc_sam9x5,
+					     "atmel,audio-routing");
+	if (ret) {
+		dev_err(&pdev->dev, "atmel,audio-routing node missing\n");
+		goto out;
+	}
+
+	codec_np = of_parse_phandle(np, "atmel,audio-codec", 0);
+	if (!codec_np) {
+		dev_err(&pdev->dev, "atmel,audio-codec node missing\n");
+		ret = -EINVAL;
+		goto out;
+	}
+
+	sam9x5_dai.codec_of_node = codec_np;
+
+	cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
+	if (!cpu_np) {
+		dev_err(&pdev->dev, "atmel,ssc-controller node missing\n");
+		ret = -EINVAL;
+		goto out;
+	}
+	sam9x5_dai.cpu_of_node = cpu_np;
+	sam9x5_dai.platform_of_node = cpu_np;
+
+	sam9x5_priv.ssc_id = of_alias_get_id(cpu_np, "ssc");
+
+	ret = atmel_ssc_set_audio(sam9x5_priv.ssc_id);
+	if (ret != 0) {
+		dev_err(&pdev->dev,
+			"ASoC: Failed to set SSC %d for audio: %d\n",
+			ret, sam9x5_priv.ssc_id);
+		goto out;
+	}
+
+	of_node_put(codec_np);
+	of_node_put(cpu_np);
+
+	ret = snd_soc_register_card(&snd_soc_sam9x5);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"ASoC: Platform device allocation failed\n");
+		goto out_put_audio;
+	}
+
+	platform_set_drvdata(pdev, &snd_soc_sam9x5);
+
+	dev_dbg(&pdev->dev, "ASoC: %s ok\n", __func__);
+
+	return ret;
+
+out_put_audio:
+	atmel_ssc_put_audio(sam9x5_priv.ssc_id);
+out:
+	return ret;
+}
+
+static int sam9x5_wm8731_driver_remove(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = platform_get_drvdata(pdev);
+	struct sam9x5_drvdata *sam9x5_priv = card->drvdata;
+
+	snd_soc_unregister_card(card);
+	atmel_ssc_put_audio(sam9x5_priv->ssc_id);
+
+	return 0;
+}
+
+static const struct of_device_id sam9x5_wm8731_of_match[] = {
+	{ .compatible = "atmel,sam9x5-wm8731-audio", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sam9x5_wm8731_of_match);
+
+static struct platform_driver sam9x5_wm8731_driver = {
+	.driver = {
+		.name = DRV_NAME,
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(sam9x5_wm8731_of_match),
+	},
+	.probe = sam9x5_wm8731_driver_probe,
+	.remove = sam9x5_wm8731_driver_remove,
+};
+module_platform_driver(sam9x5_wm8731_driver);
+
+/* Module information */
+MODULE_AUTHOR("Nicolas Ferre <nicolas.ferre at atmel.com>");
+MODULE_AUTHOR("Richard Genoud <richard.genoud at gmail.com>");
+MODULE_DESCRIPTION("ALSA SoC machine driver for AT91SAM9x5 - WM8731");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:" DRV_NAME);
-- 
1.7.10.4



From richard.genoud at gmail.com  Thu Jul 11 12:15:58 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Thu, 11 Jul 2013 18:15:58 +0200
Subject: [PATCH v5 6/7] ARM: AT91: DTS: sam9x5ek: enable SSC
In-Reply-To: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
References: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373559359-31607-7-git-send-email-richard.genoud@gmail.com>

Enable the SSC needed for the WM8731 codec

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index e6fb309..f3e83f7 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -95,6 +95,10 @@
 			watchdog at fffffe40 {
 				status = "okay";
 			};
+
+			ssc0: ssc at f0010000 {
+				status = "okay";
+			};
 		};
 
 		usb0: ohci at 00600000 {
-- 
1.7.10.4



From richard.genoud at gmail.com  Thu Jul 11 12:15:56 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Thu, 11 Jul 2013 18:15:56 +0200
Subject: [PATCH v5 4/7] ARM: AT91: DTS: sam9x5: add SSC DMA parameters
In-Reply-To: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
References: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373559359-31607-5-git-send-email-richard.genoud@gmail.com>

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5.dtsi |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 57d45f5..cf78ac0 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -542,6 +542,9 @@
 				compatible = "atmel,at91sam9g45-ssc";
 				reg = <0xf0010000 0x4000>;
 				interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
+				dmas = <&dma0 1 AT91_DMA_CFG_PER_ID(13)>,
+				       <&dma0 1 AT91_DMA_CFG_PER_ID(14)>;
+				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
 				status = "disabled";
-- 
1.7.10.4



From richard.genoud at gmail.com  Thu Jul 11 12:15:57 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Thu, 11 Jul 2013 18:15:57 +0200
Subject: [PATCH v5 5/7] ARM: AT91: DTS: sam9x5ek: add WM8731 codec
In-Reply-To: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
References: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373559359-31607-6-git-send-email-richard.genoud@gmail.com>

The WM8731 codec on sam9x5ek board is on i2c, address 1A

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
Acked-by: Mark Brown <broonie at linaro.org>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index d107241..e6fb309 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -59,6 +59,11 @@
 
 			i2c0: i2c at f8010000 {
 				status = "okay";
+
+				wm8731: wm8731 at 1a {
+					compatible = "wm8731";
+					reg = <0x1a>;
+				};
 			};
 
 			pinctrl at fffff400 {
-- 
1.7.10.4



From richard.genoud at gmail.com  Thu Jul 11 12:15:59 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Thu, 11 Jul 2013 18:15:59 +0200
Subject: [PATCH v5 7/7] ARM: AT91: DTS: sam9x5ek: add sound configuration
In-Reply-To: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
References: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1373559359-31607-8-git-send-email-richard.genoud@gmail.com>

The sam9x5ek board has 2 jacks:
headphone wired on RHPOUT/LHPOUT of the wm8731
line in wired on LLINEIN/RLINEIN of the wm8731

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index f3e83f7..9afe15b 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -113,4 +113,19 @@
 			status = "okay";
 		};
 	};
+
+	sound {
+		compatible = "atmel,sam9x5-wm8731-audio";
+
+		atmel,model = "wm8731 @ AT91SAM9X5EK";
+
+		atmel,audio-routing =
+			"Headphone Jack", "RHPOUT",
+			"Headphone Jack", "LHPOUT",
+			"LLINEIN", "Line In Jack",
+			"RLINEIN", "Line In Jack";
+
+		atmel,ssc-controller = <&ssc0>;
+		atmel,audio-codec = <&wm8731>;
+	};
 };
-- 
1.7.10.4



From magnus.damm at gmail.com  Thu Jul 11 12:22:09 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Fri, 12 Jul 2013 01:22:09 +0900
Subject: [PATCH v2 00/02] ARM: shmobile: r8a7790 arch timer frequency update
Message-ID: <20130711162209.933.47610.sendpatchset@w520>

ARM: shmobile: r8a7790 arch timer frequency update (v2)

[PATCH v2 01/02] ARM: shmobile: Introduce r8a7790_read_mode_pins()
[PATCH 02/02] ARM: shmobile: Setup r8a7790 arch timer based on MD pins

Add code to setup r8a7790 arch timer frequency dynamically at boot time
based on the EXTAL frequency pointed out by the boot mode pins.

Patch 1/2 has been updated with a ioremap() fix.
Patch 2/2 now has reported-by and tested-by.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Built on top of renesas-next-20130711

 arch/arm/mach-shmobile/clock-r8a7790.c        |   11 ----
 arch/arm/mach-shmobile/include/mach/r8a7790.h |    3 +
 arch/arm/mach-shmobile/setup-r8a7790.c        |   63 +++++++++++++++++++++++--
 3 files changed, 63 insertions(+), 14 deletions(-)


From magnus.damm at gmail.com  Thu Jul 11 12:22:19 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Fri, 12 Jul 2013 01:22:19 +0900
Subject: [PATCH v2 01/02] ARM: shmobile: Introduce r8a7790_read_mode_pins()
In-Reply-To: <20130711162209.933.47610.sendpatchset@w520>
References: <20130711162209.933.47610.sendpatchset@w520>
Message-ID: <20130711162219.933.96902.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Break out the r8a7790 boot mode code into a separate
function so it can be shared by multiple users.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Changes since v1:
 - Don't ioremap() two pages, thanks Sergei!

 arch/arm/mach-shmobile/clock-r8a7790.c        |   11 ++---------
 arch/arm/mach-shmobile/include/mach/r8a7790.h |    3 +++
 arch/arm/mach-shmobile/setup-r8a7790.c        |   14 ++++++++++++++
 3 files changed, 19 insertions(+), 9 deletions(-)

--- 0001/arch/arm/mach-shmobile/clock-r8a7790.c
+++ work/arch/arm/mach-shmobile/clock-r8a7790.c	2013-07-12 01:13:42.000000000 +0900
@@ -24,6 +24,7 @@
 #include <linux/clkdev.h>
 #include <mach/clock.h>
 #include <mach/common.h>
+#include <mach/r8a7790.h>
 
 /*
  *   MD		EXTAL		PLL0	PLL1	PLL3
@@ -42,8 +43,6 @@
  *	see "p1 / 2" on R8A7790_CLOCK_ROOT() below
  */
 
-#define MD(nr)	(1 << nr)
-
 #define CPG_BASE 0xe6150000
 #define CPG_LEN 0x1000
 
@@ -53,7 +52,6 @@
 #define SMSTPCR5 0xe6150144
 #define SMSTPCR7 0xe615014c
 
-#define MODEMR		0xE6160060
 #define SDCKCR		0xE6150074
 #define SD2CKCR		0xE6150078
 #define SD3CKCR		0xE615007C
@@ -288,14 +286,9 @@ static struct clk_lookup lookups[] = {
 
 void __init r8a7790_clock_init(void)
 {
-	void __iomem *modemr = ioremap_nocache(MODEMR, PAGE_SIZE);
-	u32 mode;
+	u32 mode = r8a7790_read_mode_pins();
 	int k, ret = 0;
 
-	BUG_ON(!modemr);
-	mode = ioread32(modemr);
-	iounmap(modemr);
-
 	switch (mode & (MD(14) | MD(13))) {
 	case 0:
 		R8A7790_CLOCK_ROOT(15, &extal_clk, 172, 208, 106, 88);
--- 0001/arch/arm/mach-shmobile/include/mach/r8a7790.h
+++ work/arch/arm/mach-shmobile/include/mach/r8a7790.h	2013-07-12 01:13:42.000000000 +0900
@@ -8,4 +8,7 @@ void r8a7790_pinmux_init(void);
 void r8a7790_init_delay(void);
 void r8a7790_timer_init(void);
 
+#define MD(nr) BIT(nr)
+u32 r8a7790_read_mode_pins(void);
+
 #endif /* __ASM_R8A7790_H__ */
--- 0001/arch/arm/mach-shmobile/setup-r8a7790.c
+++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-07-12 01:14:03.000000000 +0900
@@ -201,6 +201,20 @@ void __init r8a7790_add_standard_devices
 	r8a7790_register_thermal();
 }
 
+#define MODEMR 0xe6160060
+
+u32 __init r8a7790_read_mode_pins(void)
+{
+	void __iomem *modemr = ioremap_nocache(MODEMR, 4);
+	u32 mode;
+
+	BUG_ON(!modemr);
+	mode = ioread32(modemr);
+	iounmap(modemr);
+
+	return mode;
+}
+
 void __init r8a7790_timer_init(void)
 {
 	void __iomem *cntcr;


From magnus.damm at gmail.com  Thu Jul 11 12:22:29 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Fri, 12 Jul 2013 01:22:29 +0900
Subject: [PATCH 02/02] ARM: shmobile: Setup r8a7790 arch timer based on MD pins
In-Reply-To: <20130711162209.933.47610.sendpatchset@w520>
References: <20130711162209.933.47610.sendpatchset@w520>
Message-ID: <20130711162229.933.53924.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Update the r8a7790 arch timer setup code to configure the
frequency dynamically at boot time. This means that the arch
timer driver will be able to detect a timer frequency that
has been calculated based on the MD pins instead of a fixed
and potentially incorrect 13 MHz.

With this patch applied the Linux kernel will correctly
support the r8a7790 Lager board that uses a 20 Mhz EXTAL.
The arch timer will operate on 10 MHz and the Linux arch
timer driver will be correctly configured to use 10 MHz.

Without this patch the 20 MHz EXTAL will be used to drive
the arch timer at 10 MHz, but the Linux arch timer driver
will believe it is counting at 13 Mhz.

Reported-by: Ulrich Hecht <ulrich.hecht at gmail.com>
Signed-off-by: Magnus Damm <damm at opensource.se>
Tested-by: Ulrich Hecht <ulrich.hecht at gmail.com>
---

 arch/arm/mach-shmobile/setup-r8a7790.c |   49 ++++++++++++++++++++++++++++----
 1 file changed, 44 insertions(+), 5 deletions(-)

--- 0006/arch/arm/mach-shmobile/setup-r8a7790.c
+++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-07-09 21:29:18.000000000 +0900
@@ -215,14 +215,53 @@ u32 __init r8a7790_read_mode_pins(void)
 	return mode;
 }
 
+#define CNTCR 0
+#define CNTFID0 0x20
+
 void __init r8a7790_timer_init(void)
 {
-	void __iomem *cntcr;
+#ifdef CONFIG_ARM_ARCH_TIMER
+	u32 mode = r8a7790_read_mode_pins();
+	void __iomem *base;
+	int extal_mhz = 0;
+	u32 freq;
+
+	/* At Linux boot time the r8a7790 arch timer comes up
+	 * with the counter disabled. Moreover, it may also report
+	 * a potentially incorrect fixed 13 MHz frequency. To be
+	 * correct these registers need to be updated to use the
+	 * frequency EXTAL / 2 which can be determined by the MD pins.
+	 */
+
+	switch (mode & (MD(14) | MD(13))) {
+	case 0:
+		extal_mhz = 15;
+		break;
+	case MD(13):
+		extal_mhz = 20;
+		break;
+	case MD(14):
+		extal_mhz = 26;
+		break;
+	case MD(13) | MD(14):
+		extal_mhz = 30;
+		break;
+	}
+
+	/* The arch timer frequency equals EXTAL / 2 */
+	freq = extal_mhz * (1000000 / 2);
+
+	/* Remap "armgcnt address map" space */
+	base = ioremap(0xe6080000, PAGE_SIZE);
+
+	/* Update registers with correct frequency */
+	iowrite32(freq, base + CNTFID0);
+	asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
 
-	/* make sure arch timer is started by setting bit 0 of CNTCT */
-	cntcr = ioremap(0xe6080000, PAGE_SIZE);
-	iowrite32(1, cntcr);
-	iounmap(cntcr);
+	/* make sure arch timer is started by setting bit 0 of CNTCR */
+	iowrite32(1, base + CNTCR);
+	iounmap(base);
+#endif /* CONFIG_ARM_ARCH_TIMER */
 
 	shmobile_timer_init();
 }


From maxime.ripard at free-electrons.com  Thu Jul 11 12:31:14 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Jul 2013 18:31:14 +0200
Subject: [PATCHv5 02/10] clocksource: sun4i: Wrap macros arguments in
 parenthesis
In-Reply-To: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373560282-15184-3-git-send-email-maxime.ripard@free-electrons.com>

The macros were not using parenthesis to escape the arguments passed to
them. It is pretty unsafe, so add those parenthesis.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index bdf34d9..34ab658 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -30,8 +30,8 @@
 #define TIMER_CTL_ENABLE		BIT(0)
 #define TIMER_CTL_AUTORELOAD		BIT(1)
 #define TIMER_CTL_ONESHOT		BIT(7)
-#define TIMER_INTVAL_REG(val)	(0x10 * val + 0x14)
-#define TIMER_CNTVAL_REG(val)	(0x10 * val + 0x18)
+#define TIMER_INTVAL_REG(val)	(0x10 * (val) + 0x14)
+#define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
 
 #define TIMER_SCAL		16
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Thu Jul 11 12:31:15 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Jul 2013 18:31:15 +0200
Subject: [PATCHv5 03/10] clocksource: sun4i: rename AUTORELOAD define to RELOAD
In-Reply-To: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373560282-15184-4-git-send-email-maxime.ripard@free-electrons.com>

The name AUTORELOAD was actually pretty bad since it doesn't make the
register reload the previous interval when it expires, but setting this
value pushes the new programmed interval to the internal timer counter.
Rename it to RELOAD instead.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 34ab658..f5e227b 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -28,7 +28,7 @@
 #define TIMER_IRQ_ST_REG	0x04
 #define TIMER_CTL_REG(val)	(0x10 * val + 0x10)
 #define TIMER_CTL_ENABLE		BIT(0)
-#define TIMER_CTL_AUTORELOAD		BIT(1)
+#define TIMER_CTL_RELOAD		BIT(1)
 #define TIMER_CTL_ONESHOT		BIT(7)
 #define TIMER_INTVAL_REG(val)	(0x10 * (val) + 0x14)
 #define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
@@ -129,7 +129,7 @@ static void __init sun4i_timer_init(struct device_node *node)
 
 	/* set mode to auto reload */
 	val = readl(timer_base + TIMER_CTL_REG(0));
-	writel(val | TIMER_CTL_AUTORELOAD, timer_base + TIMER_CTL_REG(0));
+	writel(val | TIMER_CTL_RELOAD, timer_base + TIMER_CTL_REG(0));
 
 	ret = setup_irq(irq, &sun4i_timer_irq);
 	if (ret)
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Thu Jul 11 12:31:13 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Jul 2013 18:31:13 +0200
Subject: [PATCHv5 01/10] clocksource: sun4i: Use the BIT macros where possible
In-Reply-To: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373560282-15184-2-git-send-email-maxime.ripard@free-electrons.com>

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index d4674e7..bdf34d9 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -24,12 +24,12 @@
 #include <linux/of_irq.h>
 
 #define TIMER_IRQ_EN_REG	0x00
-#define TIMER_IRQ_EN(val)		(1 << val)
+#define TIMER_IRQ_EN(val)		BIT(val)
 #define TIMER_IRQ_ST_REG	0x04
 #define TIMER_CTL_REG(val)	(0x10 * val + 0x10)
-#define TIMER_CTL_ENABLE		(1 << 0)
-#define TIMER_CTL_AUTORELOAD		(1 << 1)
-#define TIMER_CTL_ONESHOT		(1 << 7)
+#define TIMER_CTL_ENABLE		BIT(0)
+#define TIMER_CTL_AUTORELOAD		BIT(1)
+#define TIMER_CTL_ONESHOT		BIT(7)
 #define TIMER_INTVAL_REG(val)	(0x10 * val + 0x14)
 #define TIMER_CNTVAL_REG(val)	(0x10 * val + 0x18)
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Thu Jul 11 12:31:16 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Jul 2013 18:31:16 +0200
Subject: [PATCHv5 04/10] clocksource: sun4i: Add clocksource and sched clock
 drivers
In-Reply-To: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373560282-15184-5-git-send-email-maxime.ripard@free-electrons.com>

Use the second timer found on the Allwinner SoCs as a clock source and
sched clock, that were both not used yet on these platforms.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index f5e227b..b581c93 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -19,6 +19,7 @@
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/irqreturn.h>
+#include <linux/sched_clock.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
@@ -96,6 +97,11 @@ static struct irqaction sun4i_timer_irq = {
 	.dev_id = &sun4i_clockevent,
 };
 
+static u32 sun4i_timer_sched_read(void)
+{
+	return ~readl(timer_base + TIMER_CNTVAL_REG(1));
+}
+
 static void __init sun4i_timer_init(struct device_node *node)
 {
 	unsigned long rate = 0;
@@ -117,6 +123,15 @@ static void __init sun4i_timer_init(struct device_node *node)
 
 	rate = clk_get_rate(clk);
 
+	writel(~0, timer_base + TIMER_INTVAL_REG(1));
+	writel(TIMER_CTL_ENABLE | TIMER_CTL_RELOAD |
+	       TIMER_CTL_CLK_SRC(TIMER_CTL_CLK_SRC_OSC24M),
+	       timer_base + TIMER_CTL_REG(1));
+
+	setup_sched_clock(sun4i_timer_sched_read, 32, rate);
+	clocksource_mmio_init(timer_base + TIMER_CNTVAL_REG(1), node->name,
+			      rate, 300, 32, clocksource_mmio_readl_down);
+
 	writel(rate / (TIMER_SCAL * HZ),
 	       timer_base + TIMER_INTVAL_REG(0));
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Thu Jul 11 12:31:12 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Jul 2013 18:31:12 +0200
Subject: [PATCHv5 00/10] clocksource: sunxi: Timer fixes and cleanup
Message-ID: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>

Hi everyone,

The first timer code we merged when adding support for the A13 some
time back was mostly a clean up from the source drop we had, without
any documentation.  This happened to work, but the code merged in
turned out to be far from perfect, and had several flaws.

This patchset hopefully fixes these flaws, and cleanup most of the
driver as well, to end up in an almost complete rewrite of it (even
though it's not that long).

It also finally adds a clocksource driver using the second timer as
our monotonic clock source.

These flaws have all been spotted when trying to add the A31 support,
work that is still ongoing, but will hopefully benefit from this
patchset as well.

Thanks,
Maxime

Changes from v4:
  - Removed the last clk_get_rate() user
  - Got a few beers

Changes from v3:
  - Reintroduce the rate variable to cache the parent clock rate
  - Remove the interval programming at probe time that was
    reintroduced in the v3 due to a poor rebase.

Changes from v2:
  - Use the clocksource timer to get the amount of time we have to
    wait for when disabling and enabling back a timer
  - Added patch to add parenthesis around the macros arguments
  - Renamed the AUTORELOAD register define to the more meaningful
    RELOAD name

Changes from v1:
  - Rebased on top of linux-next to benefit from the move to all
    architectures of the sched_clock functions
  - Moved the clock source to the second timer instead of the 64 bits
    free-running counter like suggested by Thomas.

Maxime Ripard (10):
  clocksource: sun4i: Use the BIT macros where possible
  clocksource: sun4i: Wrap macros arguments in parenthesis
  clocksource: sun4i: rename AUTORELOAD define to RELOAD
  clocksource: sun4i: Add clocksource and sched clock drivers
  clocksource: sun4i: Don't forget to enable the clock we use
  clocksource: sun4i: Fix the next event code
  clocksource: sun4i: Factor out some timer code
  clocksource: sun4i: Remove TIMER_SCAL variable
  clocksource: sun4i: Cleanup parent clock setup
  clocksource: sun4i: Fix bug when switching from periodic to oneshot
    modes

 drivers/clocksource/sun4i_timer.c | 110 +++++++++++++++++++++++++++-----------
 1 file changed, 78 insertions(+), 32 deletions(-)

-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Thu Jul 11 12:31:17 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Jul 2013 18:31:17 +0200
Subject: [PATCHv5 05/10] clocksource: sun4i: Don't forget to enable the clock
 we use
In-Reply-To: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373560282-15184-6-git-send-email-maxime.ripard@free-electrons.com>

Even if in our case, this clock was non-gatable, used as a parent clock
for several IPs, it still is a good idea to enable it.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index b581c93..8e9c651 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -120,6 +120,7 @@ static void __init sun4i_timer_init(struct device_node *node)
 	clk = of_clk_get(node, 0);
 	if (IS_ERR(clk))
 		panic("Can't get timer clock");
+	clk_prepare_enable(clk);
 
 	rate = clk_get_rate(clk);
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Thu Jul 11 12:31:21 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Jul 2013 18:31:21 +0200
Subject: [PATCHv5 09/10] clocksource: sun4i: Cleanup parent clock setup
In-Reply-To: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373560282-15184-10-git-send-email-maxime.ripard@free-electrons.com>

The current bring-up code for the timer was overly complicated. The only
thing we need is actually which clock we want to use as source and
that's pretty much all. Let's keep it that way.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 3217adc..2fadb3b 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -30,6 +30,9 @@
 #define TIMER_CTL_REG(val)	(0x10 * val + 0x10)
 #define TIMER_CTL_ENABLE		BIT(0)
 #define TIMER_CTL_RELOAD		BIT(1)
+#define TIMER_CTL_CLK_SRC(val)		(((val) & 0x3) << 2)
+#define TIMER_CTL_CLK_SRC_OSC24M		(1)
+#define TIMER_CTL_CLK_PRES(val)		(((val) & 0x7) << 4)
 #define TIMER_CTL_ONESHOT		BIT(7)
 #define TIMER_INTVAL_REG(val)	(0x10 * (val) + 0x14)
 #define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
@@ -168,16 +171,8 @@ static void __init sun4i_timer_init(struct device_node *node)
 
 	writel(rate / HZ, timer_base + TIMER_INTVAL_REG(0));
 
-	/* set clock source to HOSC, 16 pre-division */
-	val = readl(timer_base + TIMER_CTL_REG(0));
-	val &= ~(0x07 << 4);
-	val &= ~(0x03 << 2);
-	val |= (4 << 4) | (1 << 2);
-	writel(val, timer_base + TIMER_CTL_REG(0));
-
-	/* set mode to auto reload */
-	val = readl(timer_base + TIMER_CTL_REG(0));
-	writel(val | TIMER_CTL_RELOAD, timer_base + TIMER_CTL_REG(0));
+	writel(TIMER_CTL_CLK_SRC(TIMER_CTL_CLK_SRC_OSC24M) | TIMER_CTL_RELOAD,
+	       timer_base + TIMER_CTL_REG(0));
 
 	ret = setup_irq(irq, &sun4i_timer_irq);
 	if (ret)
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Thu Jul 11 12:31:20 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Jul 2013 18:31:20 +0200
Subject: [PATCHv5 08/10] clocksource: sun4i: Remove TIMER_SCAL variable
In-Reply-To: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373560282-15184-9-git-send-email-maxime.ripard@free-electrons.com>

The prescaler is only used when using the internal low frequency
oscillator (at 32kHz). Since we're using the higher frequency oscillator
at 24MHz, we can just remove it.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index dd78b63..3217adc 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -34,8 +34,6 @@
 #define TIMER_INTVAL_REG(val)	(0x10 * (val) + 0x14)
 #define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
 
-#define TIMER_SCAL		16
-
 static void __iomem *timer_base;
 
 /*
@@ -168,8 +166,7 @@ static void __init sun4i_timer_init(struct device_node *node)
 	clocksource_mmio_init(timer_base + TIMER_CNTVAL_REG(1), node->name,
 			      rate, 300, 32, clocksource_mmio_readl_down);
 
-	writel(rate / (TIMER_SCAL * HZ),
-	       timer_base + TIMER_INTVAL_REG(0));
+	writel(rate / HZ, timer_base + TIMER_INTVAL_REG(0));
 
 	/* set clock source to HOSC, 16 pre-division */
 	val = readl(timer_base + TIMER_CTL_REG(0));
@@ -192,8 +189,8 @@ static void __init sun4i_timer_init(struct device_node *node)
 
 	sun4i_clockevent.cpumask = cpumask_of(0);
 
-	clockevents_config_and_register(&sun4i_clockevent, rate / TIMER_SCAL,
-					0x1, 0xff);
+	clockevents_config_and_register(&sun4i_clockevent, rate, 0x1,
+					0xffffffff);
 }
 CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-timer",
 		       sun4i_timer_init);
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Thu Jul 11 12:31:19 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Jul 2013 18:31:19 +0200
Subject: [PATCHv5 07/10] clocksource: sun4i: Factor out some timer code
In-Reply-To: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373560282-15184-8-git-send-email-maxime.ripard@free-electrons.com>

The set_next_event and set_mode callbacks share a lot of common code we
can easily factor to avoid duplication and mistakes.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 48 ++++++++++++++++++++++++++-------------
 1 file changed, 32 insertions(+), 16 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 7123f65..dd78b63 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -52,24 +52,46 @@ static void sun4i_clkevt_sync(void)
 		cpu_relax();
 }
 
+static void sun4i_clkevt_time_stop(u8 timer)
+{
+	u32 val = readl(timer_base + TIMER_CTL_REG(timer));
+	writel(val & ~TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(timer));
+	sun4i_clkevt_sync();
+}
+
+static void sun4i_clkevt_time_setup(u8 timer, unsigned long delay)
+{
+	writel(delay, timer_base + TIMER_INTVAL_REG(timer));
+}
+
+static void sun4i_clkevt_time_start(u8 timer, bool periodic)
+{
+	u32 val = readl(timer_base + TIMER_CTL_REG(timer));
+
+	if (periodic)
+		val &= ~TIMER_CTL_ONESHOT;
+	else
+		val |= TIMER_CTL_ONESHOT;
+
+	writel(val | TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(timer));
+}
+
 static void sun4i_clkevt_mode(enum clock_event_mode mode,
 			      struct clock_event_device *clk)
 {
-	u32 u = readl(timer_base + TIMER_CTL_REG(0));
-
 	switch (mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
-		u &= ~(TIMER_CTL_ONESHOT);
-		writel(u | TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(0));
+		sun4i_clkevt_time_stop(0);
+		sun4i_clkevt_time_start(0, true);
 		break;
-
 	case CLOCK_EVT_MODE_ONESHOT:
-		writel(u | TIMER_CTL_ONESHOT, timer_base + TIMER_CTL_REG(0));
+		sun4i_clkevt_time_stop(0);
+		sun4i_clkevt_time_start(0, false);
 		break;
 	case CLOCK_EVT_MODE_UNUSED:
 	case CLOCK_EVT_MODE_SHUTDOWN:
 	default:
-		writel(u & ~(TIMER_CTL_ENABLE), timer_base + TIMER_CTL_REG(0));
+		sun4i_clkevt_time_stop(0);
 		break;
 	}
 }
@@ -77,15 +99,9 @@ static void sun4i_clkevt_mode(enum clock_event_mode mode,
 static int sun4i_clkevt_next_event(unsigned long evt,
 				   struct clock_event_device *unused)
 {
-	u32 val = readl(timer_base + TIMER_CTL_REG(0));
-	writel(val & ~TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(0));
-	sun4i_clkevt_sync();
-
-	writel(evt, timer_base + TIMER_INTVAL_REG(0));
-
-	val = readl(timer_base + TIMER_CTL_REG(0));
-	writel(val | TIMER_CTL_ENABLE | TIMER_CTL_AUTORELOAD,
-	       timer_base + TIMER_CTL_REG(0));
+	sun4i_clkevt_time_stop(0);
+	sun4i_clkevt_time_setup(0, evt);
+	sun4i_clkevt_time_start(0, false);
 
 	return 0;
 }
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Thu Jul 11 12:31:22 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Jul 2013 18:31:22 +0200
Subject: [PATCHv5 10/10] clocksource: sun4i: Fix bug when switching from
 periodic to oneshot modes
In-Reply-To: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373560282-15184-11-git-send-email-maxime.ripard@free-electrons.com>

The interval was firing at was set up at probe time, and only changed in
the set_next_event, and never changed back, which is not really what is
expected.

When enabling the periodic mode, now set an interval to tick every
jiffy.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 2fadb3b..8ead025 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -38,6 +38,7 @@
 #define TIMER_CNTVAL_REG(val)	(0x10 * (val) + 0x18)
 
 static void __iomem *timer_base;
+static u32 ticks_per_jiffy;
 
 /*
  * When we disable a timer, we need to wait at least for 2 cycles of
@@ -74,7 +75,8 @@ static void sun4i_clkevt_time_start(u8 timer, bool periodic)
 	else
 		val |= TIMER_CTL_ONESHOT;
 
-	writel(val | TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(timer));
+	writel(val | TIMER_CTL_ENABLE | TIMER_CTL_RELOAD,
+	       timer_base + TIMER_CTL_REG(timer));
 }
 
 static void sun4i_clkevt_mode(enum clock_event_mode mode,
@@ -83,6 +85,7 @@ static void sun4i_clkevt_mode(enum clock_event_mode mode,
 	switch (mode) {
 	case CLOCK_EVT_MODE_PERIODIC:
 		sun4i_clkevt_time_stop(0);
+		sun4i_clkevt_time_setup(0, ticks_per_jiffy);
 		sun4i_clkevt_time_start(0, true);
 		break;
 	case CLOCK_EVT_MODE_ONESHOT:
@@ -169,9 +172,9 @@ static void __init sun4i_timer_init(struct device_node *node)
 	clocksource_mmio_init(timer_base + TIMER_CNTVAL_REG(1), node->name,
 			      rate, 300, 32, clocksource_mmio_readl_down);
 
-	writel(rate / HZ, timer_base + TIMER_INTVAL_REG(0));
+	ticks_per_jiffy = DIV_ROUND_UP(rate, HZ);
 
-	writel(TIMER_CTL_CLK_SRC(TIMER_CTL_CLK_SRC_OSC24M) | TIMER_CTL_RELOAD,
+	writel(TIMER_CTL_CLK_SRC(TIMER_CTL_CLK_SRC_OSC24M),
 	       timer_base + TIMER_CTL_REG(0));
 
 	ret = setup_irq(irq, &sun4i_timer_irq);
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Thu Jul 11 12:31:18 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Jul 2013 18:31:18 +0200
Subject: [PATCHv5 06/10] clocksource: sun4i: Fix the next event code
In-Reply-To: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373560282-15184-7-git-send-email-maxime.ripard@free-electrons.com>

The next_event logic was setting the next interval to fire in the
current timer value instead of the interval value register, which is
obviously wrong.

Plus, the logic to set the actual value was wrong as well: the interval
register can only be modified when the timer is disabled, and then
enable it back, otherwise, it'll have no effect. Fix this logic as well
since that code couldn't possibly work.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clocksource/sun4i_timer.c | 25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 8e9c651..7123f65 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -38,6 +38,20 @@
 
 static void __iomem *timer_base;
 
+/*
+ * When we disable a timer, we need to wait at least for 2 cycles of
+ * the timer source clock. We will use for that the clocksource timer
+ * that is already setup and runs at the same frequency than the other
+ * timers, and we never will be disabled.
+ */
+static void sun4i_clkevt_sync(void)
+{
+	u32 old = readl(timer_base + TIMER_CNTVAL_REG(1));
+
+	while ((old - readl(timer_base + TIMER_CNTVAL_REG(1))) < 3)
+		cpu_relax();
+}
+
 static void sun4i_clkevt_mode(enum clock_event_mode mode,
 			      struct clock_event_device *clk)
 {
@@ -63,9 +77,14 @@ static void sun4i_clkevt_mode(enum clock_event_mode mode,
 static int sun4i_clkevt_next_event(unsigned long evt,
 				   struct clock_event_device *unused)
 {
-	u32 u = readl(timer_base + TIMER_CTL_REG(0));
-	writel(evt, timer_base + TIMER_CNTVAL_REG(0));
-	writel(u | TIMER_CTL_ENABLE | TIMER_CTL_AUTORELOAD,
+	u32 val = readl(timer_base + TIMER_CTL_REG(0));
+	writel(val & ~TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(0));
+	sun4i_clkevt_sync();
+
+	writel(evt, timer_base + TIMER_INTVAL_REG(0));
+
+	val = readl(timer_base + TIMER_CTL_REG(0));
+	writel(val | TIMER_CTL_ENABLE | TIMER_CTL_AUTORELOAD,
 	       timer_base + TIMER_CTL_REG(0));
 
 	return 0;
-- 
1.8.3.2



From nm at ti.com  Thu Jul 11 12:35:03 2013
From: nm at ti.com (Nishanth Menon)
Date: Thu, 11 Jul 2013 11:35:03 -0500
Subject: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and
 twl6040 setup for legacy boot
In-Reply-To: <51DED333.9080609@ti.com>
References: <1373552638-13930-1-git-send-email-peter.ujfalusi@ti.com>
 <20130711145916.GA6138@kahuna> <51DED333.9080609@ti.com>
Message-ID: <20130711163503.GA6611@kahuna>

On 17:45-20130711, Peter Ujfalusi wrote:
> On 07/11/2013 04:59 PM, Nishanth Menon wrote:
> > On 16:23-20130711, Peter Ujfalusi wrote:
> >> OMAP4 no longer boots in legacy mode so the code here is no longer used.
> >>
> >> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> >> ---
> >>  arch/arm/mach-omap2/twl-common.c | 332 ++-------------------------------------
> >>  arch/arm/mach-omap2/twl-common.h |   8 -
> >>  2 files changed, 12 insertions(+), 328 deletions(-)
> > Could we modify the Makefile and build twl-common.o only for
> > CONFIG_ARCH_OMAP3?
> > 
> > We could get rid of all the #ifdef from the code that way. OMAP3 is the
> > only platform that still depends on this - Further, with this change,
> 
> Yep, I can do that. I'll send a separate patch to do this.
> 
> > commit 34a38440689b06a515104d668494e0ff8a4e1537
> > (regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators)
> > will need a relook as well. currently part of the discussion with Mark
> > in [1]
> > 
> > [1] http://marc.info/?t=137185016300003&r=1&w=2
> 
> I don't see anything touching twl-common.c/h in the series.
> But at the end we should get rid of the legacy support in all of the drivers
> aimed for OMAP4+ gradually since it is pointless to keep dead code. Emphasis
> on gradually ;)
right - now that we removed the set_voltage/get_voltage custom code,
there are no longer any way the code introduced in the commit can be
exercised.

-- 
Regards,
Nishanth Menon


From mark.rutland at arm.com  Thu Jul 11 12:34:58 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Jul 2013 17:34:58 +0100
Subject: [RFC PATCH 0/5] arm64: initial CPU_HOTPLUG support
In-Reply-To: <51DECAFB.4010800@linaro.org>
References: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
 <51DECAFB.4010800@linaro.org>
Message-ID: <20130711163458.GA8303@kartoffel>

On Thu, Jul 11, 2013 at 04:10:51PM +0100, Hanjun Guo wrote:
> Hi Mark,

Hi Hanjun,

> 
> I tested this patch set on the armv8 foundation model, it's panic.
> 
> I seems that we need to do something more, I'll also checkout
> what's going on here.
> 
> Thanks
> Hanjun
> 
> dump formation:
> root at genericarmv8:/sys/devices/system/cpu/cpu3# echo 0 > online
> CPU3: Booted secondary processor
> CPU3: shutdown
> BUG: failure at kernel/time/clockevents.c:284/clockevents_register_device()!
> Kernel panic - not syncing: BUG!
> CPU: 3 PID: 0 Comm: swapper/3 Not tainted 3.10.0+ #2
> Call trace:
> [<ffffffc0000873e0>] dump_backtrace+0x0/0x12c
> [<ffffffc000087520>] show_stack+0x14/0x1c
> [<ffffffc0003f2e7c>] dump_stack+0x20/0x28
> [<ffffffc0003efd24>] panic+0xe8/0x214
> [<ffffffc0000d049c>] clockevents_set_mode+0x0/0x6c
> [<ffffffc0000d074c>] clockevents_config_and_register+0x24/0x30
> [<ffffffc0003ef840>] arch_timer_setup+0xd8/0x140
> [<ffffffc0003ef8f0>] arch_timer_cpu_notify+0x48/0xc8
> [<ffffffc0000b83e4>] notifier_call_chain+0x48/0x88
> [<ffffffc0000b8500>] __raw_notifier_call_chain+0xc/0x14
> [<ffffffc0000973f0>] __cpu_notify+0x30/0x58
> [<ffffffc00009742c>] cpu_notify+0x14/0x1c
> [<ffffffc0003ed46c>] notify_cpu_starting+0x14/0x1c
> [<ffffffc0003ece74>] secondary_start_kernel+0xc0/0xf4

That looks suspicious. It looks like the CPU didn't actually die and jumped
immediately to secondary_start_kernel. At a guess, did you update your dts with
a psci node and cpu enable-methods?

I can see the code's broken if you try hotplug with spin-table, because
cpu_disable and cpu_die are both NULL, and the sanity checking doesn't attempt
to deal with this case, so the cpu will end up getting into cpu_die, won't call
anything, and jump straight back into the kernel. I'll fix up the
op_cpu_disable checks to cover this.

The other possibility is that you're using PSCI but your function id for
cpu_off is wrong, and thus the psci cpu_off call fails. Did you update your dts
for PSCI? Below is a patch to do so.

Thanks,
Mark.

---->8----
>From ae35ce871b52ee006f8c5538b9be6c6829a71d6f Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland at arm.com>
Date: Thu, 11 Jul 2013 17:09:56 +0100
Subject: [PATCH] HACK: arm64: dts: foundation: add PSCI data

---
 arch/arm64/boot/dts/foundation-v8.dts |   19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/foundation-v8.dts b/arch/arm64/boot/dts/foundation-v8.dts
index 84fcc50..335a88f 100644
--- a/arch/arm64/boot/dts/foundation-v8.dts
+++ b/arch/arm64/boot/dts/foundation-v8.dts
@@ -22,6 +22,13 @@
 		serial3 = &v2m_serial3;
 	};
 
+	psci {
+		compatible = "arm,psci";
+		method = "smc";
+		cpu_off = <0x84000001>;
+		cpu_on = <0x84000002>;
+	};
+
 	cpus {
 		#address-cells = <2>;
 		#size-cells = <0>;
@@ -30,29 +37,25 @@
 			device_type = "cpu";
 			compatible = "arm,armv8";
 			reg = <0x0 0x0>;
-			enable-method = "spin-table";
-			cpu-release-addr = <0x0 0x8000fff8>;
+			enable-method = "psci";
 		};
 		cpu at 1 {
 			device_type = "cpu";
 			compatible = "arm,armv8";
 			reg = <0x0 0x1>;
-			enable-method = "spin-table";
-			cpu-release-addr = <0x0 0x8000fff8>;
+			enable-method = "psci";
 		};
 		cpu at 2 {
 			device_type = "cpu";
 			compatible = "arm,armv8";
 			reg = <0x0 0x2>;
-			enable-method = "spin-table";
-			cpu-release-addr = <0x0 0x8000fff8>;
+			enable-method = "psci";
 		};
 		cpu at 3 {
 			device_type = "cpu";
 			compatible = "arm,armv8";
 			reg = <0x0 0x3>;
-			enable-method = "spin-table";
-			cpu-release-addr = <0x0 0x8000fff8>;
+			enable-method = "psci";
 		};
 	};
 
-- 
1.7.9.5



From linux at roeck-us.net  Thu Jul 11 12:35:32 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 11 Jul 2013 09:35:32 -0700
Subject: [PATCH] watchdog: Add MOXA ART watchdog driver
In-Reply-To: <1373545786-7151-1-git-send-email-jonas.jensen@gmail.com>
References: <1373545786-7151-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <20130711163532.GA17310@roeck-us.net>

On Thu, Jul 11, 2013 at 02:29:46PM +0200, Jonas Jensen wrote:
> Add watchdog driver for MOXA ART SoCs.
> 
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
> ---
> 
> Notes:
>     Applies to next-20130711
> 
>  drivers/watchdog/Kconfig      |  10 +++
>  drivers/watchdog/Makefile     |   1 +
>  drivers/watchdog/moxart_wdt.c | 190 ++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 201 insertions(+)
>  create mode 100644 drivers/watchdog/moxart_wdt.c
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 362085d..6883aab 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -382,6 +382,16 @@ config RETU_WATCHDOG
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called retu_wdt.
>  
> +config MOXART_WDT
> +	tristate "MOXART watchdog"
> +	depends on ARCH_MOXART
> +	help
> +	  Say Y here to include Watchdog timer support for the watchdog
> +	  existing on the MOXA ART SoC series platforms.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called moxart_wdt.
> +
>  # AVR32 Architecture
>  
>  config AT32AP700X_WDT
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 2f26a0b..7cab53a 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -54,6 +54,7 @@ obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
>  obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
>  obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
>  obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
> +obj-$(CONFIG_MOXART_WDT) += moxart_wdt.o
>  
>  # AVR32 Architecture
>  obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
> new file mode 100644
> index 0000000..c6c00bf
> --- /dev/null
> +++ b/drivers/watchdog/moxart_wdt.c
> @@ -0,0 +1,190 @@
> +/*
> + * MOXA ART SoCs watchdog driver.
> + *
> + * Copyright (C) 2013 Jonas Jensen
> + *
> + * Jonas Jensen <jonas.jensen at gmail.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +#include <linux/types.h>
> +#include <linux/watchdog.h>
> +
> +#include <asm/system_misc.h>
> +
> +#define REG_COUNT			0x4
> +#define REG_MODE			0x8
> +#define REG_ENABLE			0xC
> +
> +struct moxart_wdt_dev {
> +	struct watchdog_device wdt_dev;
> +	void __iomem *wdt_base;
> +};
> +
> +static struct moxart_wdt_dev *moxart_wdt;
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +static int heartbeat;
> +static unsigned int clock_frequency;
> +static unsigned int max_timeout;
> +
> +static void moxart_wdt_restart(enum reboot_mode reboot_mode, const char *cmd)
> +{
> +	writel(1, moxart_wdt->wdt_base + REG_COUNT);
> +	writel(0x5ab9, moxart_wdt->wdt_base + REG_MODE);
> +	writel(0x03, moxart_wdt->wdt_base + REG_ENABLE);
> +}
> +
> +static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
> +	void __iomem *wdt_base = moxart_wdt->wdt_base;
> +
> +	writel(0, wdt_base + REG_ENABLE);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_start(struct watchdog_device *wdt_dev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
> +	void __iomem *wdt_base = moxart_wdt->wdt_base;
> +
> +	writel(clock_frequency * moxart_wdt->wdt_dev.timeout,
> +	       wdt_base + REG_COUNT);
> +	writel(0x5ab9, wdt_base + REG_MODE);
> +	writel(0x03, wdt_base + REG_ENABLE);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_ping(struct watchdog_device *wdt_dev)
> +{
> +	moxart_wdt_start(wdt_dev);
> +	return 0;
> +}

This function is unnecessary. If it is not there, the infrastructure code will
call the start function automatically.

> +
> +static int moxart_wdt_set_timeout(struct watchdog_device *wdt_dev,
> +				  unsigned int timeout)
> +{
> +	dev_dbg(wdt_dev->dev, "%s: timeout=%u\n", __func__, timeout);
> +
> +	if (timeout > max_timeout)
> +		return -EINVAL;

Unnecessary check; handled by infrastructure.

> +
> +	moxart_wdt->wdt_dev.timeout = timeout;
> +
> +	return 0;
> +}
> +
> +static const struct watchdog_info moxart_wdt_info = {
> +	.identity       = "moxart-wdt",
> +	.options        = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
> +			  WDIOF_MAGICCLOSE,
> +};
> +
> +static const struct watchdog_ops moxart_wdt_ops = {
> +	.owner          = THIS_MODULE,
> +	.start          = moxart_wdt_start,
> +	.stop           = moxart_wdt_stop,
> +	.ping           = moxart_wdt_ping,
> +	.set_timeout    = moxart_wdt_set_timeout,
> +};
> +
> +static int moxart_wdt_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct device_node *node = dev->of_node;
> +	struct resource *res;
> +	struct clk *clk;
> +	int err;
> +
> +	moxart_wdt = devm_kzalloc(&pdev->dev, sizeof(*moxart_wdt), GFP_KERNEL);
> +	if (!moxart_wdt)
> +		return -EINVAL;
> +
> +	platform_set_drvdata(pdev, moxart_wdt);
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	moxart_wdt->wdt_base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(moxart_wdt->wdt_base))
> +		return PTR_ERR(moxart_wdt->wdt_base);
> +
> +	arm_pm_restart = moxart_wdt_restart;

It is quite unusual that system restart code is implemented in a watchdog
driver (which may not even be compiled into an image, or not be loaded).

Also, I'd like to see what happens if the driver is built as module and
unloaded before the restart. Unless I am missing something, this should result
in a nice crash.

> +
> +	clk = of_clk_get(node, 0);
> +	if (IS_ERR(clk)) {
> +		pr_err("%s: of_clk_get failed\n", __func__);
> +		return PTR_ERR(clk);

.... even more so if it fails to load for any reason.

> +	}
> +
> +	clock_frequency = clk_get_rate(clk);
> +
> +	max_timeout = UINT_MAX / clock_frequency;
> +
> +	moxart_wdt->wdt_dev.info = &moxart_wdt_info;
> +	moxart_wdt->wdt_dev.ops = &moxart_wdt_ops;
> +	moxart_wdt->wdt_dev.timeout = max_timeout;
> +	moxart_wdt->wdt_dev.min_timeout = 1;
> +	moxart_wdt->wdt_dev.max_timeout = max_timeout;
> +	moxart_wdt->wdt_dev.parent = &pdev->dev;
> +
> +	watchdog_init_timeout(&moxart_wdt->wdt_dev, heartbeat, &pdev->dev);
> +	watchdog_set_nowayout(&moxart_wdt->wdt_dev, nowayout);
> +
> +	watchdog_set_drvdata(&moxart_wdt->wdt_dev, moxart_wdt);
> +
> +	err = watchdog_register_device(&moxart_wdt->wdt_dev);
> +	if (unlikely(err))
> +		return err;
> +
> +	dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
> +		 moxart_wdt->wdt_dev.timeout, nowayout);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_remove(struct platform_device *pdev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
> +
> +	watchdog_unregister_device(&moxart_wdt->wdt_dev);
> +	watchdog_set_drvdata(&moxart_wdt->wdt_dev, NULL);

This is unnecessary.

> +
> +	return 0;
> +}
> +
> +static const struct of_device_id moxart_watchdog_match[] = {
> +	{ .compatible = "moxa,moxart-watchdog" },
> +	{ },
> +};
> +
> +static struct platform_driver moxart_wdt_driver = {
> +	.probe      = moxart_wdt_probe,
> +	.remove     = moxart_wdt_remove,
> +	.driver     = {
> +		.name		= "moxart-watchdog",
> +		.owner		= THIS_MODULE,
> +		.of_match_table	= moxart_watchdog_match,
> +	},
> +};
> +module_platform_driver(moxart_wdt_driver);
> +
> +module_param(heartbeat, int, 0);
> +MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");
> +
> +MODULE_DESCRIPTION("MOXART watchdog driver");
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
> -- 
> 1.8.2.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From maxime.ripard at free-electrons.com  Thu Jul 11 12:38:59 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Jul 2013 18:38:59 +0200
Subject: [PATCH 0/4] A10S-OLinuXino-Micro I2C support
In-Reply-To: <1373232719-13050-1-git-send-email-emilio@elopez.com.ar>
References: <1373232719-13050-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <20130711163859.GX11243@lukather>

Hi Emilio,

On Sun, Jul 07, 2013 at 06:31:55PM -0300, Emilio L?pez wrote:
> Hi,
> 
> This patchset adds the required DT nodes to get I2C supported and 
> working on the OLIMEX A10S-OLinuXino-Micro board.
> 
> Patch 1 adds the muxings as seen on the board's schematics. Patch 2 adds 
> the DT nodes, based on other sunxi dts, as we don't have an A10S user 
> manual so far. Patch 3 enables the controllers, and patch 4 adds a node 
> for the AT24 EEPROM found on the board.
> 
> I have tested and can see the PMU on I2C-0 using i2cdetect, and can read 
> the EEPROM contents on I2C-1. I have not tested I2C-2, but i2cdetect 
> reports no devices so I suppose it's working okay too.
> 
> Any testing or review will be appreciated :)
> 
> Thanks,
> 
> Emilio
> 
> Emilio L?pez (4):
>   ARM: sun5i: dt: Add I2C muxings for sun5i A10S
>   ARM: sun5i: dt: Add I2C controller nodes to the A10S dtsi
>   ARM: sun5i: dt: Enable I2C controllers on A10S-OLinuXino-Micro
>   ARM: sun5i: dt: Add AT24 device on A10S-OLinuXino-Micro
> 
>  arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 25 +++++++++++
>  arch/arm/boot/dts/sun5i-a10s.dtsi                | 54 ++++++++++++++++++++++++
>  2 files changed, 79 insertions(+)

Thanks for doing this!

Overall, this patchset looks fine. I'll apply it as soon as 3.11-rc1 is
out.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130711/93271d83/attachment.sig>

From andrew at lunn.ch  Thu Jul 11 12:44:56 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 11 Jul 2013 18:44:56 +0200
Subject: gpio_blink_set + Kirkwood
In-Reply-To: <51DEDB32.4080101@harsszegi.com>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <1a9bcb9094ae695c6707c4835417dd5b@harsszegi.com>
 <20130710073706.GA28212@lunn.ch> <51DEDB32.4080101@harsszegi.com>
Message-ID: <20130711164456.GA3095@lunn.ch>

On Thu, Jul 11, 2013 at 06:20:02PM +0200, Tibor Harsszegi wrote:
> Hello guys,
> 
> can anyone explain me how does the gpio_blink_set member gets filled
> in leds-gpio through platform_get_drvdata()?
> I can't seem to follow how the specific function pointer can be set
> to orion_gpio_set_blink() for example.
> Sorry for the dumb question :(

Hi Tibor

For DT based board, hardware blinking is not supported, as far as i
remember.

	Andrew


From broonie at kernel.org  Thu Jul 11 12:51:16 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 11 Jul 2013 17:51:16 +0100
Subject: [PATCH v2] rtc: Add MOXA ART RTC driver
In-Reply-To: <1373550711-18828-1-git-send-email-jonas.jensen@gmail.com>
References: <1373464848-28146-1-git-send-email-jonas.jensen@gmail.com>
 <1373550711-18828-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <20130711165116.GT24508@sirena.org.uk>

On Thu, Jul 11, 2013 at 03:51:51PM +0200, Jonas Jensen wrote:
> Add RTC driver for MOXA ART SoCs.

Looks good now.  A couple more minor nits.

> +void moxart_rtc_write_byte(u8 data)
> +{

> +u8 moxart_rtc_read_byte(void)
> +{

These should be static.

> +	gpio_direction_output(GPIO_RTC_DATA, 0);
> +	gpio_set_value(GPIO_RTC_RESET, 1);

I guess I'd expect the GPIOs to be configured by platform data in case
of board changes (it's a bit odd that a SoC RTC is being done with
bitbanging, I guess it's on an external chip?).

> +	devm_gpio_request(&pdev->dev, GPIO_RTC_DATA, "rtc_data");
> +	devm_gpio_request(&pdev->dev, GPIO_RTC_SCLK, "rtc_sclk");
> +	devm_gpio_request(&pdev->dev, GPIO_RTC_RESET, "rtc_reset");

Should check the errors from these.

> +	gpio_direction_output(GPIO_RTC_RESET, 0);
> +	gpio_direction_output(GPIO_RTC_SCLK, 0);

devm_gpio_request_one()?  Though it doesn't make much difference and you
do have a nice block of devm_gpio_request() above not all of which have
a direction assigned immediately.
-------------- 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/20130711/7019f737/attachment.sig>

From maxime.ripard at free-electrons.com  Thu Jul 11 13:05:06 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Jul 2013 19:05:06 +0200
Subject: MTD EEPROM support and driver integration
In-Reply-To: <20130709145510.GZ27646@sirena.org.uk>
References: <20130705201118.GM2959@lukather> <5811519.oHVuMujf0I@wuerfel>
 <20130706120112.GA11069@lukather> <8997501.Dchyii8uWX@wuerfel>
 <20130708083426.GO27646@sirena.org.uk>
 <20130708202538.GK11243@lukather>
 <20130709145510.GZ27646@sirena.org.uk>
Message-ID: <20130711170506.GZ11243@lukather>

Hi Mark,

On Tue, Jul 09, 2013 at 03:55:10PM +0100, Mark Brown wrote:
> On Mon, Jul 08, 2013 at 10:25:38PM +0200, Maxime Ripard wrote:
> > On Mon, Jul 08, 2013 at 09:34:26AM +0100, Mark Brown wrote:
> 
> > > I'd really like to see more discussion of this "DT parsing code for
> > > regmap" idea...  I've missed almost all the context here.
> 
> > The context was that I found we lack a way to simply express the need
> > for one driver to get a value from an EEPROM-like device, for example to
> > get a MAC Address, or a serial number, in a generic way, without having
> > to poke directly with some custom function that would be exported by the
> > EEPROM driver.
> 
> This sort of information is often stored in places like flash partitions
> too.  Are we sure that regmap is a good place to be hooking in here?
> The use case is sane, and being able to use regmap to do some of it
> seems sensible (I've seen people use OTP in PMICs for similar purposes)
> but perhaps an additional layer of abstraction on top makes sense.

Ah, I didn't thought it could be stored into a partition. Ok, so using
an intermediate abstraction for this makes sense (probably using regmap
for all the accesses that are relevant, like i2c, spi or mmio)

> > What we've been discussing so far is that:
> >   - To have a common framework we could base our work on, we could move
> >     the EEPROM drivers from drivers/misc/eeprom to MTD
> >   - To declare the ranges that needed to be used by a driver that was
> >     needing a value from one of those MTD drivers, we would use regmap
> >     with a MTD backend
> >   - And since we actually need to declare which ranges and in which
> >     device one driver would have to retrieve this value from, we were
> >     actually in need of DT bindings.
> 
> > This is pretty much the only context involved, and we are at the early
> > stage of the discussion, so any comment is very welcome :)
> 
> If this stuff is being represented in MTD doesn't MTD already have
> adequate abstractions for saying "this region in flash".  But otherwise
> this seems fine, it's not a generic regmap DT binding but instead rather
> more specific than that.

Yes, since we seem to be going to a point where regmap will be a
convenience in this case, we probably won't need a generic regmap
binding, but rather a generic way to define a range and offset into a
referenced device.

Arnd, the others, is this ok for you?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130711/7299fbd3/attachment.sig>

From prabhakar.csengg at gmail.com  Thu Jul 11 13:12:57 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Thu, 11 Jul 2013 22:42:57 +0530
Subject: [PATCH v3 0/6] ARM: davinci: da850: add ethernet driver DT support
In-Reply-To: <1371999607-6483-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1371999607-6483-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <CA+V-a8t-sTPAK+D5869X0_ZCdrmK0B+eRaowk9hMYwXMw09NqA@mail.gmail.com>

Hi Sekhar,

On Sun, Jun 23, 2013 at 8:30 PM, Prabhakar Lad
<prabhakar.csengg at gmail.com> wrote:
> From: "Lad, Prabhakar" <prabhakar.csengg at gmail.com>
>
> This patch set enables Ethernet support through device tree model.
> This patch set enables mii interface only and is being tested to boot via
> rootfs. The rmii phy is present on the i2c gpio expander chip (UI board)
> for which yet support needs to be added, once the DT support for the chip
> is enabled, enabling rmii will be subsequnet patch.
>
> Changes for v2:
> 1: Enabled mdio device.
> 2: Fixed clock lookup.
>
> Changes for v3:
> 1: Fixed review comments pointed out by Sekhar.
>
> Lad, Prabhakar (6):
>   ARM: davinci: da8xx: fix clock lookup for mdio device
>   ARM: davinci: da850: add DT node for mdio device
>   ARM: davinci: da850: add OF_DEV_AUXDATA entry for mdio.
>   ARM: davinci: da850: add DT node for eth0.
>   ARM: davinci: da850: add OF_DEV_AUXDATA entry for eth0.
>   ARM: davinci: da850: configure system configuration chip(CFGCHIP3)
>     for emac
>
gentle ping..

Regards,
--Prabhakar Lad


From grundler at chromium.org  Thu Jul 11 13:22:59 2013
From: grundler at chromium.org (Grant Grundler)
Date: Thu, 11 Jul 2013 10:22:59 -0700
Subject: [PATCH v7 00/12] iommu/exynos: Fixes and Enhancements of System
 MMU driver with DT
In-Reply-To: <002801ce797b$3d2fbc80$b78f3580$@samsung.com>
References: <002801ce797b$3d2fbc80$b78f3580$@samsung.com>
Message-ID: <CANEJEGvajhgzUPG6ppbjwBb4-9TdU9em3T_SejBpz8NCjGHYTQ@mail.gmail.com>

On Fri, Jul 5, 2013 at 5:29 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> The current exynos-iommu(System MMU) driver does not work autonomously
> since it is lack of support for power management of peripheral blocks.
...
> Patch summary:
> [PATCH v7 1/9] iommu/exynos: do not include removed header
> [PATCH v7 2/9] iommu/exynos: add missing cache flush for removed page table entries
> [PATCH v7 3/9] iommu/exynos: fix page table maintenance
> [PATCH v7 4/9] iommu/exynos: allocate lv2 page table from own slab
> [PATCH v7 5/9] iommu/exynos: change rwlock to spinlock
> [PATCH v7 6/9] clk: exynos5250: add gate clock descriptions of System MMU
> [PATCH v7 7/9] ARM: dts: Add description of System MMU of Exynos SoCs
> [PATCH v7 8/9] iommu/exynos: support for device tree
> [PATCH v7 9/9] iommu/exynos: add bus notifier for registering System MMU

Cho,
Of the above patches, nearly all have been applied to chromeos-3.8
(kernel-next git tree) by Doug Anderson and others.

AFAICT, the only ones not applied are:
   [v7,3/9] iommu/exynos: fix page table maintenance
   [v7,6/9] clk: exynos5250: add gate clock descriptions of System MMU
(conflicts in this one)
   [v7,7/9] ARM: dts: Add description of System MMU of Exynos SoCs
(depends on 6/9)

We also already have parts of:
   [v7,9/9] iommu/exynos: add bus notifier for registering System MMU

Some of those are being further discussed but I've lost track now
exactly which ones.

I'm telling you about chromeos-3.8 status since the adopted changes
have been reviewed (by me and others) are being tested manually here
on several different Samsung Exynos platforms (including 5250 which is
our "snow" platform). Not sure how you should to mark those patches
since they aren't identical to your changes (which apply to post 3.10
kernels, not 3.8).  You might consider splitting those patches out
from the 4 I've listed above to get that series accepted upstream
since the additional review/testing should provide some confidence
those patches are good.

cheers,
grant


From b.zolnierkie at samsung.com  Thu Jul 11 13:37:47 2013
From: b.zolnierkie at samsung.com (Bartlomiej Zolnierkiewicz)
Date: Thu, 11 Jul 2013 19:37:47 +0200
Subject: [PATCH v7 3/9] iommu/exynos: fix page table maintenance
In-Reply-To: <002b01ce797b$44d4ad10$ce7e0730$@samsung.com>
References: <002b01ce797b$44d4ad10$ce7e0730$@samsung.com>
Message-ID: <1933986.4vddYccClk@amdc1032>


Hi,

Some minor nitpicks below.

On Friday, July 05, 2013 09:29:18 PM Cho KyongHo wrote:
> This prevents allocating lv2 page table for the lv1 page table entry
> that already has 1MB page mapping. In addition some BUG_ON() is
> changed to WARN_ON().
> 
> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> ---
>  drivers/iommu/exynos-iommu.c |   34 ++++++++++++++++++++++++++--------
>  1 files changed, 26 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index e3be3e5..2bfe9fa 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -862,12 +862,14 @@ static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long iova,
>  		pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
>  		BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
>  		if (!pent)
> -			return NULL;
> +			return ERR_PTR(-ENOMEM);
>  
>  		*sent = mk_lv1ent_page(__pa(pent));
>  		*pgcounter = NUM_LV2ENTRIES;
>  		pgtable_flush(pent, pent + NUM_LV2ENTRIES);
>  		pgtable_flush(sent, sent + 1);
> +	} else if (lv1ent_section(sent)) {
> +		return ERR_PTR(-EADDRINUSE);
>  	}
>  
>  	return page_entry(sent, iova);
> @@ -944,16 +946,16 @@ static int exynos_iommu_map(struct iommu_domain *domain, unsigned long iova,
>  		pent = alloc_lv2entry(entry, iova,
>  					&priv->lv2entcnt[lv1ent_offset(iova)]);
>  
> -		if (!pent)
> -			ret = -ENOMEM;
> +		if (IS_ERR(pent))
> +			ret = PTR_ERR(pent);
>  		else
>  			ret = lv2set_page(pent, paddr, size,
>  					&priv->lv2entcnt[lv1ent_offset(iova)]);
>  	}
>  
>  	if (ret) {
> -		pr_debug("%s: Failed to map iova 0x%lx/0x%x bytes\n",
> -							__func__, iova, size);
> +		pr_err("%s: Failed(%d) to map iova 0x%#x bytes @ %#lx\n",
> +						__func__, ret, size, iova);
>  	}

Intendation is a bit weird, it should be more like:

		pr_err("%s: Failed(%d) to map iova 0x%#x bytes @ %#lx\n",
			__func__, ret, size, iova);

to be consistent with the rest of the driver.

You could have also removed superfluous braces while at it.

>  	spin_unlock_irqrestore(&priv->pgtablelock, flags);
> @@ -968,6 +970,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
>  	struct sysmmu_drvdata *data;
>  	unsigned long flags;
>  	unsigned long *ent;
> +	size_t err_page;
>  
>  	BUG_ON(priv->pgtable == NULL);
>  
> @@ -976,7 +979,8 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
>  	ent = section_entry(priv->pgtable, iova);
>  
>  	if (lv1ent_section(ent)) {
> -		BUG_ON(size < SECT_SIZE);
> +		if (WARN_ON(size < SECT_SIZE))
> +			goto err;
>  
>  		*ent = 0;
>  		pgtable_flush(ent, ent + 1);
> @@ -1008,7 +1012,8 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
>  	}
>  
>  	/* lv1ent_large(ent) == true here */
> -	BUG_ON(size < LPAGE_SIZE);
> +	if (WARN_ON(size < LPAGE_SIZE))
> +		goto err;
>  
>  	memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
>  	pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
> @@ -1023,8 +1028,21 @@ done:
>  		sysmmu_tlb_invalidate_entry(data->dev, iova);
>  	spin_unlock_irqrestore(&priv->lock, flags);
>  
> -
>  	return size;
> +err:
> +	spin_unlock_irqrestore(&priv->pgtablelock, flags);
> +
> +	err_page = (
> +		((unsigned long)ent - (unsigned long)priv->pgtable)
> +			< (NUM_LV1ENTRIES * sizeof(long))

Maybe you could add LV1TABLE_SIZE define and use it here (there is
already a LV2TABLE_SIZE define)?

> +			   ) ?  SECT_SIZE : LPAGE_SIZE;

It also seems that err_page should be of unsigned long type, no need
to make it size_t one.

The above code is quite ugly currently, it could be rewritten into
something prettier, i.e.:

	err_page = (unsigned long)ent - (unsigned long)priv->pgtable;
	err_page = (err_page < LV1TABLE_SIZE) ? SECT_SIZE : LPAGE_SIZE;

> +	pr_err("%s: Failed due to size(%#lx) @ %#x is"\
> +		" smaller than page size %#x\n",
> +		__func__, iova, size, err_page);

Aren't iova and size arguments interchanged here?

> +
> +	       return 0;

There is an intendation issue here (extra whitespaces).

> +
>  }
>  
>  static phys_addr_t exynos_iommu_iova_to_phys(struct iommu_domain *domain,

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics



From swarren at wwwdotorg.org  Thu Jul 11 13:40:37 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 11 Jul 2013 11:40:37 -0600
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <1373553468-6564-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1373553468-6564-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <51DEEE15.7040801@wwwdotorg.org>

On 07/11/2013 08:37 AM, Laurent Pinchart wrote:
> Define PWM_POLARITY_NORMAL and PWM_POLARITY_INVERTED macros in
> include/dt-bindings/pwm/pwm.h to be used by device tree sources.

>  Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt |  6 +++---
>  Documentation/devicetree/bindings/pwm/pwm-samsung.txt   |  5 +++--
>  Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt  |  5 +++--
>  Documentation/devicetree/bindings/pwm/pwm.txt           |  8 +++++---
>  Documentation/devicetree/bindings/pwm/vt8500-pwm.txt    |  5 +++--
>  arch/arm/boot/dts/am335x-evm.dts                        |  3 ++-
>  arch/arm/boot/dts/am335x-evmsk.dts                      |  3 ++-
>  arch/arm/boot/dts/wm8850-w70v2.dts                      |  3 ++-
>  include/dt-bindings/pwm/pwm.h                           | 15 +++++++++++++++
>  include/linux/pwm.h                                     |  4 ++--

I think this needs to be separate patches; at least the new pwm.h should
be introduced separately to the board-specific *.dts edits, and perhaps
further split up?

That way, the one patch that introduces <dt-bindings/pwm.h> would be
available to be merged into any other tree that wanted to take patches
to use the new defines.

> diff --git a/include/linux/pwm.h b/include/linux/pwm.h

>  enum pwm_polarity {
> -	PWM_POLARITY_NORMAL,
> -	PWM_POLARITY_INVERSED,
> +	PWM_POLARITY_NORMAL = 0,
> +	PWM_POLARITY_INVERSED = 1,
>  };

Rather than manually editing that to ensure the enum matches the DT
bindings header, the whole point of making a separate <dt-bindings/...>
directory was that drivers could include the binding header files
directly to avoid having to duplicate the constant definitions. Can't
<linux/pwm.h> include <dt-bindings/pwm.h> and remove that enum?



From swarren at wwwdotorg.org  Thu Jul 11 13:50:48 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 11 Jul 2013 11:50:48 -0600
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <20130711153559.GB2198@dhcp-172-17-186-34.nvidia.com>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1373553468-6564-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <20130711153559.GB2198@dhcp-172-17-186-34.nvidia.com>
Message-ID: <51DEF078.1010408@wwwdotorg.org>

On 07/11/2013 09:36 AM, Thierry Reding wrote:
> On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote: 
> [...]
>> diff --git
>> a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
>> b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index
>> de0eaed..be09be4 100644 ---
>> a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt +++
>> b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt @@ -4,9
>> +4,9 @@ Required properties: - compatible: should be
>> "atmel,tcb-pwm" - #pwm-cells: Should be 3.  The first cell
>> specifies the per-chip index of the PWM to use, the second cell
>> is the period in nanoseconds and -  bit 0 in the third cell is
>> used to encode the polarity of PWM output. -  Set bit 0 of the
>> third cell in PWM specifier to 1 for inverse polarity & -  set to
>> 0 for normal polarity. +  the third cell is used to encode the
>> polarity of PWM output. Set the +  PWM_POLARITY_NORMAL flag for
>> normal polarity or the PWM_POLARITY_INVERSED +  flag for inverted
>> polarity. PWM flags are defined in <dt-bindings/pwm/pwm.h>. -
>> tc-block: The Timer Counter block to use as a PWM chip.
>> 
>> Example:
> 
> I'd prefer for the original text to stay in place and the reference
> to the dt-bindings/pwm/pwm.h file to go below that block.

I disagree here. The whole point of creating header files for the
constants in binding definitions was so that you wouldn't have to
duplicate all the values into the binding definitions. Rather, you'd
simply say "see <dt-bindings/xxx.h>".

A comment on the original patch:

You're creating <dt-bindings/pwm/pwm.h>. That filename sounds entirely
generic, as if the values are defining something PWM-wide rather than
specific to individual PWM bindings. As such, I think the text in each
individual binding should simply say something like:

-----
the third cell encodes standard PWM flags, as defined in
<dt-bindings/pwm/pwm.h>.
-----

Similarly, pwm.txt should mention that standard flags exist, and refer
to that same file for definitions.

> The reason is that perhaps somebody will look at an older version
> of a given DT (with the numerical value) and not have access to the
> include and therefore not know which flag was being set by just
> looking at the documentation.

It's pretty trivial to find the header that defines the values; just
grab the latest source. If you're looking at an old version of the
.dts file, it's almost certain that's within the context of an old
Linux kernel soruce tree, in which case you trivially have access to
the old version of the binding document that spelled out the values.

> I'm also not sure about what the plans are with respect to
> shipping device trees in a separate repository and if they are,
> whether that repository would ship the includes as well.

It would have to. That separate repository would be upstream for
<dt-bindings/> files, which would be imported into the kernel
periodically as drivers wanted to make use of any new headers/values
defined there.

> Another issue might be that people without access to recent
> versions of DTC won't be able to use the new #include feature, so
> keeping the documentation backwards compatible seems like a good
> idea.

The dtc source tree is duplicated into the kernel source tree, so that
isn't an issue for now.

Besides, the dtc version is an entirely unrelated issue to how the
documentation is written.

> Perhaps the include file should even only be mentioned in the
> general PWM binding documentation.

I wondered about that too. It's slightly indirect in that you'd read
foo-pwm.txt which would say something like:

-----
the third cell encodes standard PWM flags, as defined by the core PWM
binding in pwm.txt in this directory.
-----

and pwm.txt would say:

-----
The PWM specifier should include a flags cell to contain standard PWM
flags. Values for that cell are defined in <dt-bindings/pwm/pwm.h>.
-----

Which is somewhat like following a lot of symlinks. Still, I agree
that's arguably the correct thing to do.


From marex at denx.de  Thu Jul 11 13:57:19 2013
From: marex at denx.de (Marek Vasut)
Date: Thu, 11 Jul 2013 19:57:19 +0200
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <201307111957.19537.marex@denx.de>

Hi Peter,

> This patchset adds tested otg id switch function and
> vbus connect and disconnect detection for chipidea driver.
> And fix kinds of bugs found at chipidea drivers after enabling
> id and vbus detection.
> 
> This patch is fully tested at imx6 sabresd platform.
> My chipidea repo: https://github.com/hzpeterchen/linux-usb.git
> 
> Changes for v12:
> - Rebased greg's usb-next tree (3.10.0-rc7+)
> - Split more small patches for single function and fix.

I tested the patchset. Here are the results:

- VBUS switching

I'm no longer getting any ID interrupts at all when I apply the patch below. The 
board stays in HOST mode all the time. If I configure it as peripheral, it works 
as peripheral. Note with [1], I was able to switch from Peripheral->Host , not 
the other way around.

--- a/arch/arm/boot/dts/imx28-m28evk.dts
+++ b/arch/arm/boot/dts/imx28-m28evk.dts
@@ -240,6 +240,8 @@
 
        ahb at 80080000 {
                usb0: usb at 80080000 {
+                       dr_mode = "otg";
+                       phy_mode = "utmi";
                        vbus-supply = <&reg_usb0_vbus>;
                        pinctrl-names = "default";
                        pinctrl-0 = <&usbphy0_pins_a>;

---------------------------

- MX23 UDC issue

I found a workaround. Now running 'dmesg' via telnet through USB CDC link no 
longer hangs the USB driver, but works as expected. I applied this small patch 
that enables the streaming mode. Works on MX23EVK. It's surprising this issue 
doesn't manifest on MX28, maybe MX28 contains a new revision of the controller. 
I remember there was some discussion about the streaming mode on MXS some time 
ago.

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index d06355e..bba8e25 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -92,8 +92,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
                .name           = "ci_hdrc_imx",
                .capoffset      = DEF_CAPOFFSET,
                .flags          = CI_HDRC_REQUIRE_TRANSCEIVER |
-                                 CI_HDRC_PULLUP_ON_VBUS |
-                                 CI_HDRC_DISABLE_STREAMING,
+                                 CI_HDRC_PULLUP_ON_VBUS,
        };
        struct resource *res;
        int ret;

[1] 
http://git.pengutronix.de/?p=mgr/linux.git;a=shortlog;h=refs/heads/v3.10/topic/usb-
peterchen

Best regards,
Marek Vasut


From tibor at harsszegi.com  Thu Jul 11 14:32:42 2013
From: tibor at harsszegi.com (Tibor Harsszegi)
Date: Thu, 11 Jul 2013 20:32:42 +0200
Subject: gpio_blink_set + Kirkwood
In-Reply-To: <20130711164456.GA3095@lunn.ch>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <1a9bcb9094ae695c6707c4835417dd5b@harsszegi.com>
 <20130710073706.GA28212@lunn.ch> <51DEDB32.4080101@harsszegi.com>
 <20130711164456.GA3095@lunn.ch>
Message-ID: <51DEFA4A.6010303@harsszegi.com>

> On Thu, Jul 11, 2013 at 06:20:02PM +0200, Tibor Harsszegi wrote:
>> Hello guys,
>>
>> can anyone explain me how does the gpio_blink_set member gets filled
>> in leds-gpio through platform_get_drvdata()?
>> I can't seem to follow how the specific function pointer can be set
>> to orion_gpio_set_blink() for example.
>> Sorry for the dumb question :(
> Hi Tibor
>
> For DT based board, hardware blinking is not supported, as far as i
> remember.
>
> 	Andrew

Hello Andrew,

is there an example for "mixed machine setup" (if there is anything like 
that) ?
I'm thinking about:

* DT based initialization starts
* then if supported board based "after-DT-init-board-code" executes

similar what we have in board-*.c files just that it would be executed 
after kirkwood has initialized the board
based upon the .DTB
[I'm thinking about getting rid of the LED setup from the .DTB and move 
it back to .C land - at least for a trial]

Thanks,
Tibor


From jason at lakedaemon.net  Thu Jul 11 14:37:37 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 11 Jul 2013 14:37:37 -0400
Subject: gpio_blink_set + Kirkwood
In-Reply-To: <51DEFA4A.6010303@harsszegi.com>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <1a9bcb9094ae695c6707c4835417dd5b@harsszegi.com>
 <20130710073706.GA28212@lunn.ch> <51DEDB32.4080101@harsszegi.com>
 <20130711164456.GA3095@lunn.ch> <51DEFA4A.6010303@harsszegi.com>
Message-ID: <20130711183737.GX11908@titan.lakedaemon.net>

On Thu, Jul 11, 2013 at 08:32:42PM +0200, Tibor Harsszegi wrote:
> >On Thu, Jul 11, 2013 at 06:20:02PM +0200, Tibor Harsszegi wrote:
> >>Hello guys,
> >>
> >>can anyone explain me how does the gpio_blink_set member gets filled
> >>in leds-gpio through platform_get_drvdata()?
> >>I can't seem to follow how the specific function pointer can be set
> >>to orion_gpio_set_blink() for example.
> >>Sorry for the dumb question :(
> >Hi Tibor
> >
> >For DT based board, hardware blinking is not supported, as far as i
> >remember.
> >
> >	Andrew
> 
> Hello Andrew,
> 
> is there an example for "mixed machine setup" (if there is anything
> like that) ?
> I'm thinking about:
> 
> * DT based initialization starts
> * then if supported board based "after-DT-init-board-code" executes
> 
> similar what we have in board-*.c files just that it would be
> executed after kirkwood has initialized the board
> based upon the .DTB
> [I'm thinking about getting rid of the LED setup from the .DTB and
> move it back to .C land - at least for a trial]

As a testing hack, just add the following to board-dt.c:

	if (of_machine_is_compatible("keymile,whizbang-board")) {
		/* GPIO hackery here */
	}

hth,

Jason.


From tibor at harsszegi.com  Thu Jul 11 14:52:08 2013
From: tibor at harsszegi.com (Tibor Harsszegi)
Date: Thu, 11 Jul 2013 20:52:08 +0200
Subject: gpio_blink_set + Kirkwood
In-Reply-To: <20130711183737.GX11908@titan.lakedaemon.net>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <1a9bcb9094ae695c6707c4835417dd5b@harsszegi.com>
 <20130710073706.GA28212@lunn.ch> <51DEDB32.4080101@harsszegi.com>
 <20130711164456.GA3095@lunn.ch> <51DEFA4A.6010303@harsszegi.com>
 <20130711183737.GX11908@titan.lakedaemon.net>
Message-ID: <51DEFED8.4050402@harsszegi.com>

On 2013-07-11 20:37, Jason Cooper wrote:
> On Thu, Jul 11, 2013 at 08:32:42PM +0200, Tibor Harsszegi wrote:
>>> On Thu, Jul 11, 2013 at 06:20:02PM +0200, Tibor Harsszegi wrote:
>>>> Hello guys,
>>>>
>>>> can anyone explain me how does the gpio_blink_set member gets filled
>>>> in leds-gpio through platform_get_drvdata()?
>>>> I can't seem to follow how the specific function pointer can be set
>>>> to orion_gpio_set_blink() for example.
>>>> Sorry for the dumb question :(
>>> Hi Tibor
>>>
>>> For DT based board, hardware blinking is not supported, as far as i
>>> remember.
>>>
>>> 	Andrew
>> Hello Andrew,
>>
>> is there an example for "mixed machine setup" (if there is anything
>> like that) ?
>> I'm thinking about:
>>
>> * DT based initialization starts
>> * then if supported board based "after-DT-init-board-code" executes
>>
>> similar what we have in board-*.c files just that it would be
>> executed after kirkwood has initialized the board
>> based upon the .DTB
>> [I'm thinking about getting rid of the LED setup from the .DTB and
>> move it back to .C land - at least for a trial]
> As a testing hack, just add the following to board-dt.c:
>
> 	if (of_machine_is_compatible("keymile,whizbang-board")) {
> 		/* GPIO hackery here */
> 	}
>
> hth,
>
> Jason.
Ok, but isn't board-dt.c is the very first thing (kinda) which is 
executed prior the .DTB is parsed
and executed?
E.g. if I add the GPIO hack there, I assume that kirkwood and orion is 
already initialized.
Or is the board-dt.c executed after the .DTB is loaded/parsed?
Thanks,


From marex at denx.de  Thu Jul 11 15:30:16 2013
From: marex at denx.de (Marek Vasut)
Date: Thu, 11 Jul 2013 21:30:16 +0200
Subject: [PATCH] ARM: mxs: Add backlight support for M28EVK
Message-ID: <1373571016-22268-1-git-send-email-marex@denx.de>

This patch adds backlight support for M28EVK.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx28-m28evk.dts |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/imx28-m28evk.dts b/arch/arm/boot/dts/imx28-m28evk.dts
index 44d9da5..0d322a2 100644
--- a/arch/arm/boot/dts/imx28-m28evk.dts
+++ b/arch/arm/boot/dts/imx28-m28evk.dts
@@ -235,6 +235,12 @@
 				pinctrl-0 = <&auart2_2pins_b>;
 				status = "okay";
 			};
+
+			pwm: pwm at 80064000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&pwm4_pins_a>;
+				status = "okay";
+			};
 		};
 	};
 
@@ -270,6 +276,13 @@
 		};
 	};
 
+	backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm 4 5000000>;
+		brightness-levels = <0 4 8 16 32 64 128 255>;
+		default-brightness-level = <6>;
+	};
+
 	regulators {
 		compatible = "simple-bus";
 
-- 
1.7.10.4



From thierry.reding at gmail.com  Thu Jul 11 15:32:46 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 11 Jul 2013 12:32:46 -0700
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <51DEF078.1010408@wwwdotorg.org>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1373553468-6564-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <20130711153559.GB2198@dhcp-172-17-186-34.nvidia.com>
 <51DEF078.1010408@wwwdotorg.org>
Message-ID: <20130711193245.GB17212@dhcp-172-17-186-34.nvidia.com>

On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote:
> On 07/11/2013 09:36 AM, Thierry Reding wrote:
> > On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote: 
> > [...]
> >> diff --git
> >> a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> >> b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index
> >> de0eaed..be09be4 100644 ---
> >> a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt +++
> >> b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt @@ -4,9
> >> +4,9 @@ Required properties: - compatible: should be
> >> "atmel,tcb-pwm" - #pwm-cells: Should be 3.  The first cell
> >> specifies the per-chip index of the PWM to use, the second cell
> >> is the period in nanoseconds and -  bit 0 in the third cell is
> >> used to encode the polarity of PWM output. -  Set bit 0 of the
> >> third cell in PWM specifier to 1 for inverse polarity & -  set to
> >> 0 for normal polarity. +  the third cell is used to encode the
> >> polarity of PWM output. Set the +  PWM_POLARITY_NORMAL flag for
> >> normal polarity or the PWM_POLARITY_INVERSED +  flag for inverted
> >> polarity. PWM flags are defined in <dt-bindings/pwm/pwm.h>. -
> >> tc-block: The Timer Counter block to use as a PWM chip.
> >> 
> >> Example:
> > 
> > I'd prefer for the original text to stay in place and the reference
> > to the dt-bindings/pwm/pwm.h file to go below that block.
> 
> I disagree here. The whole point of creating header files for the
> constants in binding definitions was so that you wouldn't have to
> duplicate all the values into the binding definitions. Rather, you'd
> simply say "see <dt-bindings/xxx.h>".

But that's not something that this patch solves. And it could be solved
even in the absence of the header file defining the symbolic constants.
If all the standard flags that dt-bindings/pwm/pwm.txt now specifies
were to be listed in pwm.txt (they actually are) then referring to that
document as the canonical source works equally well.

> > The reason is that perhaps somebody will look at an older version
> > of a given DT (with the numerical value) and not have access to the
> > include and therefore not know which flag was being set by just
> > looking at the documentation.
> 
> It's pretty trivial to find the header that defines the values; just
> grab the latest source. If you're looking at an old version of the
> .dts file, it's almost certain that's within the context of an old
> Linux kernel soruce tree, in which case you trivially have access to
> the old version of the binding document that spelled out the values.
> 
> > I'm also not sure about what the plans are with respect to
> > shipping device trees in a separate repository and if they are,
> > whether that repository would ship the includes as well.
> 
> It would have to. That separate repository would be upstream for
> <dt-bindings/> files, which would be imported into the kernel
> periodically as drivers wanted to make use of any new headers/values
> defined there.

If we can take both of the above for granted, then sure, let's refer to
the header from within the generic pwm.txt file and add a reference to
that in bindings for drivers that use the standard flags.

> > Another issue might be that people without access to recent
> > versions of DTC won't be able to use the new #include feature, so
> > keeping the documentation backwards compatible seems like a good
> > idea.
> 
> The dtc source tree is duplicated into the kernel source tree, so that
> isn't an issue for now.
> 
> Besides, the dtc version is an entirely unrelated issue to how the
> documentation is written.

Well, not really. If the documentation specifies the binding in a way
that the DTC can't handle that's still a problem. People will end up
with a DTS that their DTC can't compile. I guess that can be resolved
by adding a note to the upstream device tree repository about the
minimum required version of DTC.

> > Perhaps the include file should even only be mentioned in the
> > general PWM binding documentation.
> 
> I wondered about that too. It's slightly indirect in that you'd read
> foo-pwm.txt which would say something like:
> 
> -----
> the third cell encodes standard PWM flags, as defined by the core PWM
> binding in pwm.txt in this directory.
> -----
> 
> and pwm.txt would say:
> 
> -----
> The PWM specifier should include a flags cell to contain standard PWM
> flags. Values for that cell are defined in <dt-bindings/pwm/pwm.h>.
> -----
> 
> Which is somewhat like following a lot of symlinks. Still, I agree
> that's arguably the correct thing to do.

Yes, I like this a whole lot better than the current situation. It gets
us almost automatic consistency, which is harder to do with the current
approach.

Thierry
-------------- 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/20130711/d9a1e836/attachment.sig>

From jason at lakedaemon.net  Thu Jul 11 15:44:01 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 11 Jul 2013 15:44:01 -0400
Subject: gpio_blink_set + Kirkwood
In-Reply-To: <51DEFED8.4050402@harsszegi.com>
References: <51DC564A.8050002@harsszegi.com> <20130709193605.GC26223@lunn.ch>
 <1a9bcb9094ae695c6707c4835417dd5b@harsszegi.com>
 <20130710073706.GA28212@lunn.ch> <51DEDB32.4080101@harsszegi.com>
 <20130711164456.GA3095@lunn.ch> <51DEFA4A.6010303@harsszegi.com>
 <20130711183737.GX11908@titan.lakedaemon.net>
 <51DEFED8.4050402@harsszegi.com>
Message-ID: <20130711194401.GY11908@titan.lakedaemon.net>

On Thu, Jul 11, 2013 at 08:52:08PM +0200, Tibor Harsszegi wrote:
> On 2013-07-11 20:37, Jason Cooper wrote:
> >On Thu, Jul 11, 2013 at 08:32:42PM +0200, Tibor Harsszegi wrote:
> >>>On Thu, Jul 11, 2013 at 06:20:02PM +0200, Tibor Harsszegi wrote:
> >>>>Hello guys,
> >>>>
> >>>>can anyone explain me how does the gpio_blink_set member gets filled
> >>>>in leds-gpio through platform_get_drvdata()?
> >>>>I can't seem to follow how the specific function pointer can be set
> >>>>to orion_gpio_set_blink() for example.
> >>>>Sorry for the dumb question :(
> >>>Hi Tibor
> >>>
> >>>For DT based board, hardware blinking is not supported, as far as i
> >>>remember.
> >>>
> >>>	Andrew
> >>Hello Andrew,
> >>
> >>is there an example for "mixed machine setup" (if there is anything
> >>like that) ?
> >>I'm thinking about:
> >>
> >>* DT based initialization starts
> >>* then if supported board based "after-DT-init-board-code" executes
> >>
> >>similar what we have in board-*.c files just that it would be
> >>executed after kirkwood has initialized the board
> >>based upon the .DTB
> >>[I'm thinking about getting rid of the LED setup from the .DTB and
> >>move it back to .C land - at least for a trial]
> >As a testing hack, just add the following to board-dt.c:
> >
> >	if (of_machine_is_compatible("keymile,whizbang-board")) {
> >		/* GPIO hackery here */
> >	}
> >
> >hth,
> >
> >Jason.
> Ok, but isn't board-dt.c is the very first thing (kinda) which is
> executed prior the .DTB is parsed
> and executed?
> E.g. if I add the GPIO hack there, I assume that kirkwood and orion
> is already initialized.
> Or is the board-dt.c executed after the .DTB is loaded/parsed?

The last line parses the dtb.  Perhaps late_initcall()?

hth,

Jason.


From santosh.shilimkar at ti.com  Thu Jul 11 15:54:34 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 11 Jul 2013 15:54:34 -0400
Subject: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3() which
 calling instruction smc #1
In-Reply-To: <531356997.66774.1373571839852.JavaMail.apache@mail81.abv.bg>
References: <531356997.66774.1373571839852.JavaMail.apache@mail81.abv.bg>
Message-ID: <51DF0D7A.4090008@ti.com>

On Thursday 11 July 2013 03:43 PM, ?????? ???????? wrote:
>  
> 
> 
> 
> 
>  >-------- ?????????? ????? --------
>  >??:  Dave Martin 
>  >???????: Re: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3() which
>  calling instruction smc #1
>  >??: Pali Roh?r 
>  >????????? ??: ?????, 2013, ??? 10 20:45:26 EEST
>  >
>  >
>  >On Wed, Jul 10, 2013 at 02:59:04PM +0200, Pali Roh?r wrote:
>  >> Other secure functions omap_smc1() and omap_smc2() calling instruction smc #0
>  >> but Nokia RX-51 board needs to call smc #1 for PPA access.
>  >> 
>  >> Signed-off-by: Ivaylo Dimitrov 
>  >> Signed-off-by: Pali Roh?r 
>  >> ---
>  >>  arch/arm/mach-omap2/omap-secure.h |    1 +
>  >>  arch/arm/mach-omap2/omap-smc.S    |   22 +++++++++++++++++++++-
>  >>  2 files changed, 22 insertions(+), 1 deletion(-)
>  >> 
>  >> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
>  >> index 0e72917..c4586f4 100644
>  >> --- a/arch/arm/mach-omap2/omap-secure.h
>  >> +++ b/arch/arm/mach-omap2/omap-secure.h
>  >> @@ -51,6 +51,7 @@
>  >>  extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
>  >>  				u32 arg1, u32 arg2, u32 arg3, u32 arg4);
>  >>  extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
>  >> +extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
>  >>  extern phys_addr_t omap_secure_ram_mempool_base(void);
>  >>  extern int omap_secure_ram_reserve_memblock(void);
>  >>  
>  >> diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
>  >> index f6441c1..5c02b8d 100644
>  >> --- a/arch/arm/mach-omap2/omap-smc.S
>  >> +++ b/arch/arm/mach-omap2/omap-smc.S
>  >> @@ -1,9 +1,11 @@
>  >>  /*
>  >> - * OMAP44xx secure APIs file.
>  >> + * OMAP34xx and OMAP44xx secure APIs file.
>  >>   *
>  >>   * Copyright (C) 2010 Texas Instruments, Inc.
>  >>   * Written by Santosh Shilimkar 
>  >>   *
>  >> + * Copyright (C) 2012 Ivaylo Dimitrov 
>  >> + * Copyright (C) 2013 Pali Roh?r 
>  >>   *
>  >>   * This program is free software,you can redistribute it and/or modify
>  >>   * it under the terms of the GNU General Public License version 2 as
>  >> @@ -54,6 +56,24 @@ ENTRY(omap_smc2)
>  >>  	ldmfd   sp!, {r4-r12, pc}
>  >>  ENDPROC(omap_smc2)
>  >>  
>  >> +/**
>  >> + * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
>  >> + * Low level common routine for secure HAL and PPA APIs via smc #1
>  >> + * r0 - @service_id: Secure Service ID
>  >> + * r1 - @process_id: Process ID
>  >> + * r2 - @flag: Flag to indicate the criticality of operation
>  >> + * r3 - @pargs: Physical address of parameter list
>  >> + */
>  >> +ENTRY(omap_smc3)
>  >> +	stmfd	sp!, {r4-r12, lr}
>  >
>  >You don't need to save/restore r12.  The ABI allows it to be clobbered
>  >across function calls.
>  >
>  >> +	mov	r12, r0		@ Copy the secure service ID
>  >> +	mov	r6, #0xff	@ Indicate new Task call
>  >> +	dsb
>  >> +	dmb
>  >
>  >dsb synchronises a superset of what dmb synchronises, so the dmb here is
>  >not useful.
>  >
>  >In any case, any code calling this must flush the region addressed by
>  >r3 beforehand anyway, which will include a dsb as part of its semantics
>  >-- this is how you call it from rx51_secure_dispatcher().
>  >
>  >So I think the dsb may not be needed here (?)
>  >
>  >Cheers
>  >---Dave
>  >
>  >
> 
> Could be, but I wonder why almost all the kernel code(I am aware of) that uses SMC and is written by TI, is storing r12 and is using both DSB and DMB. See arch/arm/mach-omap2/sleep34xx.S or arch/arm/mach-omap2/omap-smc.S for examples. I'd rather play it safe and leave it that way, unless someone confirms the other code using SMC has extra DSB/DMB instructions too. I wouldn't risk passing invalid/stale data to the Secure Monitor to just save 8 bytes and barriers in a performance non-critical code which will be called only a couple of times during the boot-up process. r12 save/restore is a legacy from omap_smc2 in omap-smc.S, so I guess it can go away without much of a trouble.
> 
Dave pointed out about the dsb and r12 to me in another thread. R12 can be easily removed
but the DSB's were needed on OMAP for power sequencing. Without those, we have seen
many issues. So you can leave the dsb's to be consistent with rest of the code.

Regards
Santosh
P.S: Please sensibly wrap your message while replying. You reply apears like
one single line and I needed to keep scrolling to read it.




From dsd at laptop.org  Thu Jul 11 15:59:50 2013
From: dsd at laptop.org (Daniel Drake)
Date: Thu, 11 Jul 2013 13:59:50 -0600
Subject: Armada 510 display controller
Message-ID: <CAMLZHHRNjbQy7zfw=bD1kC+pKh946rOBWKyFOyhzyoLkdkE0PA@mail.gmail.com>

Hi,

We seem to have reached an initial conclusion from the "Best practice
device tree design for display subsystems/DRM". Thanks for the
discussion. I am trying to come up with a binding + implementation.

I am a bit stuck though, because I don't fully understand what the
DCON on the Armada 510 does.

In that thread, the ascii art suggests that it receives the output
from the two LCD controllers. From there it can send the image to a
VGA output or a parallel bus (where the HDMI encoder lies). Does it
let you choose which LCD controller input goes to which output? Can
you clone one input onto both outputs?

If it plays such an integral role in the "get an image from Cubox onto
my TV" path, as suggested in the diagram, why can't I see any code in
the armada_drm driver that configures it?


We also have a naming conflict that might be annoying. The MMP2 and
MMP3 can effectively drive 3 different video outputs (2 panels + 1
HDMI), but the documentation and register layout does not treat it as
3 different devices. Rather it is just 1 device, annoyingly named
"display controller". Comparing MMP to Armada 510, the MMP "display
controller" seems to act like the 510's LCD controllers and display
controller combined, i.e. it coordinates both the reading of image
data from memory *and* sending it to a configurable selection of
output devices.

That might produce a challenge for writing good documentation that
covers all the target hardware. That will become apparent once I'm
clearer on what the Armada 510 DCON is and how to document it's
possible involvement in the DT. If necessary, maybe we could refer to
the Armada 510 DCON as "output controller" or "output selector" or
something like that, to avoid the name conflict.

Thanks
Daniel


From swarren at wwwdotorg.org  Thu Jul 11 16:06:44 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 11 Jul 2013 14:06:44 -0600
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <20130711193245.GB17212@dhcp-172-17-186-34.nvidia.com>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1373553468-6564-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <20130711153559.GB2198@dhcp-172-17-186-34.nvidia.com>
 <51DEF078.1010408@wwwdotorg.org>
 <20130711193245.GB17212@dhcp-172-17-186-34.nvidia.com>
Message-ID: <51DF1054.9000207@wwwdotorg.org>

On 07/11/2013 01:32 PM, Thierry Reding wrote:
> On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote:
>> On 07/11/2013 09:36 AM, Thierry Reding wrote:
>>> On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart
>>> wrote: [...]
>>>> diff --git 
>>>> a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt 
>>>> b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
>>>> index de0eaed..be09be4 100644 --- 
>>>> a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
>>>> +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
>>>> @@ -4,9 +4,9 @@ Required properties: - compatible: should be 
>>>> "atmel,tcb-pwm" - #pwm-cells: Should be 3.  The first cell 
>>>> specifies the per-chip index of the PWM to use, the second
>>>> cell is the period in nanoseconds and -  bit 0 in the third
>>>> cell is used to encode the polarity of PWM output. -  Set bit
>>>> 0 of the third cell in PWM specifier to 1 for inverse
>>>> polarity & -  set to 0 for normal polarity. +  the third cell
>>>> is used to encode the polarity of PWM output. Set the +
>>>> PWM_POLARITY_NORMAL flag for normal polarity or the
>>>> PWM_POLARITY_INVERSED +  flag for inverted polarity. PWM
>>>> flags are defined in <dt-bindings/pwm/pwm.h>. - tc-block: The
>>>> Timer Counter block to use as a PWM chip.
>>>> 
>>>> Example:
>>> 
>>> I'd prefer for the original text to stay in place and the
>>> reference to the dt-bindings/pwm/pwm.h file to go below that
>>> block.
>> 
>> I disagree here. The whole point of creating header files for
>> the constants in binding definitions was so that you wouldn't
>> have to duplicate all the values into the binding definitions.
>> Rather, you'd simply say "see <dt-bindings/xxx.h>".
> 
> But that's not something that this patch solves.

Well, if the comments I made on the patch re: that <linux/pwm.h>
should simply #include <dt-bindings/pwm/pwm.h> instead of duplicating
the constants, then yet this patch will solve that. There will be a
single place where the constants are defined.

> And it could be solved even in the absence of the header file
> defining the symbolic constants. If all the standard flags that
> dt-bindings/pwm/pwm.txt now specifies were to be listed in pwm.txt
> (they actually are) then referring to that document as the
> canonical source works equally well.

If that's all the happens, then there will still be duplication
between pwm.txt and <linux/pwm.h>.

> If we can take both of the above for granted, then sure, let's
> refer to the header from within the generic pwm.txt file and add a
> reference to that in bindings for drivers that use the standard
> flags.
> 
>>> Another issue might be that people without access to recent 
>>> versions of DTC won't be able to use the new #include feature,
>>> so keeping the documentation backwards compatible seems like a
>>> good idea.
>> 
>> The dtc source tree is duplicated into the kernel source tree, so
>> that isn't an issue for now.
>> 
>> Besides, the dtc version is an entirely unrelated issue to how
>> the documentation is written.
> 
> Well, not really. If the documentation specifies the binding in a
> way that the DTC can't handle that's still a problem. People will
> end up with a DTS that their DTC can't compile. I guess that can be
> resolved by adding a note to the upstream device tree repository
> about the minimum required version of DTC.

Yes, the separate repository would obviously require a version of dtc
that's able to compile the files there; i.e. a version equivalent to
what's already in the kernel tree (upstream 1.4.0 specifically).

Again, right now, all of the binding docs, the *.dts files, and the
dtc required to use them are part of the kernel; a single package, so
there's no scope for issues re: using dtc features that aren't
supported. If those components get separated later, obviously there
will be a requirement to install a specific version of dtc to use with
the separated *.dts and binding files.


From sebastian.hesselbarth at gmail.com  Thu Jul 11 18:11:56 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Fri, 12 Jul 2013 00:11:56 +0200
Subject: Armada 510 display controller
In-Reply-To: <CAMLZHHRNjbQy7zfw=bD1kC+pKh946rOBWKyFOyhzyoLkdkE0PA@mail.gmail.com>
References: <CAMLZHHRNjbQy7zfw=bD1kC+pKh946rOBWKyFOyhzyoLkdkE0PA@mail.gmail.com>
Message-ID: <51DF2DAC.3080605@gmail.com>

On 07/11/2013 09:59 PM, Daniel Drake wrote:
> We seem to have reached an initial conclusion from the "Best practice
> device tree design for display subsystems/DRM". Thanks for the
> discussion. I am trying to come up with a binding + implementation.
>
> I am a bit stuck though, because I don't fully understand what the
> DCON on the Armada 510 does.

Daniel,

just ignore DCON for now. Its reset state allows us to use Dove
DRM in the only way we plan to already. Later if somebody comes
up with a board that has both LCD0 and LCD1 connected, we propose
the DT binding.

> In that thread, the ascii art suggests that it receives the output
> from the two LCD controllers. From there it can send the image to a
> VGA output or a parallel bus (where the HDMI encoder lies). Does it
> let you choose which LCD controller input goes to which output? Can
> you clone one input onto both outputs?

You can clone LCD0 to VGA but not the other way round. I guess it
use kind of useless anyway. Or you want to clone HDMI to analog VGA? ;)
 From a DT point-of-view DCON it completely independent.

> If it plays such an integral role in the "get an image from Cubox onto
> my TV" path, as suggested in the diagram, why can't I see any code in
> the armada_drm driver that configures it?

It does, but currently reset state is sufficient for us.

> We also have a naming conflict that might be annoying. The MMP2 and
> MMP3 can effectively drive 3 different video outputs (2 panels + 1
> HDMI), but the documentation and register layout does not treat it as
> 3 different devices. Rather it is just 1 device, annoyingly named
> "display controller". Comparing MMP to Armada 510, the MMP "display
> controller" seems to act like the 510's LCD controllers and display
> controller combined, i.e. it coordinates both the reading of image
> data from memory *and* sending it to a configurable selection of
> output devices.

That is also the case for A510. LCD0 reads from memory and drives
dumb RGB connected to HDMI controller. LCD1 can also read from memory
and drive VGA. DCON allows you to clone video from LCD0 to VGA instead
of LCD1.

> That might produce a challenge for writing good documentation that
> covers all the target hardware. That will become apparent once I'm
> clearer on what the Armada 510 DCON is and how to document it's
> possible involvement in the DT. If necessary, maybe we could refer to
> the Armada 510 DCON as "output controller" or "output selector" or
> something like that, to avoid the name conflict.

I don't recall if DCON really is named "display controller" in the
public datasheet. It was the most likely name, so I called it display
controller. For the documentation, name it output multiplexer/selector.
Both LCD controller and Display controller are not very helpful for the
function anyway.

Sebastian



From ulrich.prinz at googlemail.com  Thu Jul 11 18:44:29 2013
From: ulrich.prinz at googlemail.com (Ulrich Prinz)
Date: Fri, 12 Jul 2013 00:44:29 +0200
Subject: [PATCH 9/9] clocksource: dw_apb_timer: special variant for
 rockchip rk3188 timers
In-Reply-To: <alpine.DEB.2.02.1307062233480.32106@ionos.tec.linutronix.de>
References: <201307060051.09716.heiko@sntech.de>
 <201307060056.29370.heiko@sntech.de>
 <alpine.DEB.2.02.1307060153110.32106@ionos.tec.linutronix.de>
 <51D87E04.3060704@googlemail.com>
 <alpine.DEB.2.02.1307062233480.32106@ionos.tec.linutronix.de>
Message-ID: <51DF354D.6050401@googlemail.com>

Hey guys,

according the dw_apb_timer I need your statement...

Am 06.07.2013 23:00, schrieb Thomas Gleixner:
> Ulrich,
> 
> On Sat, 6 Jul 2013, Ulrich Prinz wrote:
> 
>> I got the message. With modifying the existing driver to support more
>> function pointers in its system struct and assigning them at the
>> beginning, and using them on runtime, these quirks are obsolete.
> 
> Correct.
>  
>>
>> Adding more function pointers to a system relevant structure, doubling
>> the number of functions and such didn't look non-invasive to me.
> 
> Well, it always depends. If there is a single place to deal with some
> oddball hardware, a flag is often the simplest way to go.
> 
> If you have to add 10 conditionals in several functions then in a
> first step converting the existing implementation into function
> pointer calls and then in the next step providing new implementations
> for your hardware is most of the time simpler and cleaner.
> 
>> But, I totally agree with your argumentation and I even wanted to do it
>> in the way you explained in your replies. Just the courage was missing I
>> guess :)
> 
> Gut feelings are often a better guidance than our self-doubting
> intellect. :)

You can look at my github repo for the new driver, rewriting the
interface as discussed above:
https://github.com/Astralix/linux-rockchip/blob/wip/dw_timer64/drivers/clocksource/dw_apb_timer.c

Summary: It is a 90% rewrite of the complete dw_apb_timer.c and
modifications of dw_apb_timer_of.c and dw_apb_timer.h and the related
x86 drivers are needed.
And after that the 64bit functionality is still not given as the
existing structures do not take it. But for now scheduler doesn't
support 64bit either, I guess.

The drivers local struct stays, but instead of carrying pointers to
registers it now consists of function pointers. This could be used to
fit almost any kind of timer.

I would really appreciate your comments. Sure I need to clean up a bit,
but we're still testing. But before investing more time into that code I
need you comment if I should continue or split to a separate driver for
these kind of timers.

Thanks for any comments

Regards
	Ulrich



From swarren at wwwdotorg.org  Thu Jul 11 18:48:51 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 11 Jul 2013 16:48:51 -0600
Subject: [PATCH] ARM: kexec: validate CPU hotplug support
Message-ID: <1373582931-11956-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Architectures should fully validate whether kexec is possible as part of
machine_kexec_prepare(), so that user-space's kexec_load() operation can
report any problems. Performing validation in machine_kexec() itself is
too late, since it is not allowed to return.

Prior to this patch, ARM's machine_kexec() was testing after-the-fact
whether machine_kexec_prepare() was able to disable all but one CPU.
Instead, modify machine_kexec_prepare() to validate all conditions
necessary for machine_kexec_prepare()'s to succeed. BUG if the validation
succeeded, yet disabling the CPUs didn't actually work.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
Russell, does it make sense for this to be cc: stable as a follow-up to
19ab428 "ARM: 7759/1: decouple CPU offlining from reboot/shutdown"?

 arch/arm/include/asm/smp_plat.h |  3 +++
 arch/arm/kernel/machine_kexec.c | 20 ++++++++++++++++----
 arch/arm/kernel/smp.c           |  8 ++++++++
 3 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 6462a72..a252c0b 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -88,4 +88,7 @@ static inline u32 mpidr_hash_size(void)
 {
 	return 1 << mpidr_hash.bits;
 }
+
+extern int platform_can_cpu_hotplug(void);
+
 #endif
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index 4fb074c..d7c82df 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -15,6 +15,7 @@
 #include <asm/mmu_context.h>
 #include <asm/cacheflush.h>
 #include <asm/mach-types.h>
+#include <asm/smp_plat.h>
 #include <asm/system_misc.h>
 
 extern const unsigned char relocate_new_kernel[];
@@ -39,6 +40,14 @@ int machine_kexec_prepare(struct kimage *image)
 	int i, err;
 
 	/*
+	 * Validate that if the current HW supports SMP, then the SW supports
+	 * and implements CPU hotplug for the current HW. If not, we won't be
+	 * able to kexec reliably, so fail the prepare operation.
+	 */
+	if (num_possible_cpus() > 1 && !platform_can_cpu_hotplug())
+		return -EINVAL;
+
+	/*
 	 * No segment at default ATAGs address. try to locate
 	 * a dtb using magic.
 	 */
@@ -134,10 +143,13 @@ void machine_kexec(struct kimage *image)
 	unsigned long reboot_code_buffer_phys;
 	void *reboot_code_buffer;
 
-	if (num_online_cpus() > 1) {
-		pr_err("kexec: error: multiple CPUs still online\n");
-		return;
-	}
+	/*
+	 * This can only happen if machine_shutdown() failed to disable some
+	 * CPU, and that can only happen if the checks in
+	 * machine_kexec_prepare() were not correct. If this fails, we can't
+	 * reliably kexec anyway, so BUG_ON is appropriate.
+	 */
+	BUG_ON(num_online_cpus() > 1);
 
 	page_list = image->head & PAGE_MASK;
 
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index c2b4f8f..5b9e501 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -145,6 +145,14 @@ int boot_secondary(unsigned int cpu, struct task_struct *idle)
 	return -ENOSYS;
 }
 
+int platform_can_cpu_hotplug(void)
+{
+	if (!IS_ENABLED(CONFIG_HOTPLUG_CPU) || !smp_ops.cpu_kill)
+		return 0;
+
+	return 1;
+}
+
 #ifdef CONFIG_HOTPLUG_CPU
 static void percpu_timer_stop(void);
 
-- 
1.8.1.5



From haojian.zhuang at gmail.com  Thu Jul 11 19:51:41 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 12 Jul 2013 07:51:41 +0800
Subject: [PATCH V3 2/3] clocksource: mmp: support CLOCKSOURCE OF DECLARE
In-Reply-To: <175CCF5F49938B4D99B2E3EF7F558EBE3DBC97FDFF@SC-VEXCH4.marvell.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-3-git-send-email-zhangwm@marvell.com>
 <20130709181434.76f6216d@skate> <201307092316.20905.arnd@arndb.de>
 <CAN1soZyFztVR1XSw9bDS5JexK0Mdbpr6yevatVf+MnBohwCj1Q@mail.gmail.com>
 <175CCF5F49938B4D99B2E3EF7F558EBE3DBC97FDFF@SC-VEXCH4.marvell.com>
Message-ID: <CAN1soZzkycTDc-U4h43LC6hSYS1v+UkG+C4k-+dYMxRL=t7Zbg@mail.gmail.com>

On Thu, Jul 11, 2013 at 7:23 PM, Neil Zhang <zhangwm at marvell.com> wrote:
> Haojian,
>
>
>> -----Original Message-----
>> From: Haojian Zhuang [mailto:haojian.zhuang at gmail.com]
>> Sent: 2013?7?10? 13:59
>> To: Arnd Bergmann
>> Cc: Thomas Petazzoni; Neil Zhang; Grant Likely;
>> devicetree-discuss at lists.ozlabs.org; linux-kernel at vger.kernel.org;
>> linux-arm-kernel at lists.infradead.org
>> Subject: Re: [PATCH V3 2/3] clocksource: mmp: support CLOCKSOURCE OF
>> DECLARE
>>
>> On Wed, Jul 10, 2013 at 5:16 AM, Arnd Bergmann <arnd at arndb.de> wrote:
>> > On Tuesday 09 July 2013, Thomas Petazzoni wrote:
>> >> Dear Neil Zhang,
>> >>
>> >> On Tue, 9 Jul 2013 14:42:45 +0800, Neil Zhang wrote:
>> >> > support CLOCKSOURCE OF DECLARE for mmp timer.
>> >> >
>> >> > Signed-off-by: Neil Zhang <zhangwm at marvell.com>
>> >> > ---
>> >> >  arch/arm/mach-mmp/mmp-dt.c  |    5 ++---
>> >> >  arch/arm/mach-mmp/mmp2-dt.c |    3 +--
>> >> >  arch/arm/mach-mmp/time.c    |   15 ++-------------
>> >> >  3 files changed, 5 insertions(+), 18 deletions(-)
>> >>
>> >> Maybe it would be good to take this opportunity to move
>> >> arch/arm/mach-mmp/time.c into drivers/clocksource/.
>> >
>> > +1
>> >
>> > Or we might want to have a more coordinated move of all clocksource
>> > drivers in arch/arm to drivers/clocksource now, as we have done for
>> > some other subsystems.
>> >
>> >         Arnd
>>
>> I already sent some patches on this. But I didn't get response yet. I'll rebase
>> them and send them again. I hope that they could be merged in this cycle.
>>
>> Regards
>> Haojian
>
> Will you submit a patch to move it by yourself or let me update the patch to
> move it to drivers/clocksource in next version?
>
> Best Regards,
> Neil Zhang

Not one patch. There're a couples of patches. They are depandant each other.

I don't have time to rebase them in these two weeks. Go ahead to rebase all
your patches on mine.

Regards
Haojian


From haojian.zhuang at gmail.com  Thu Jul 11 19:54:25 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 12 Jul 2013 07:54:25 +0800
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <20130710215041.GR11908@titan.lakedaemon.net>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <CAN1soZxiOh6TpbUOCUzK8gNwmvjbT3ihkUWaw8tuZ7md+NVA2g@mail.gmail.com>
 <20130710122433.GO11908@titan.lakedaemon.net>
 <CAN1soZzMvront1-jcBW6-uRKNs0OZNGnmiOjKGZSM28bViB_8A@mail.gmail.com>
 <20130710215041.GR11908@titan.lakedaemon.net>
Message-ID: <CAN1soZzuiukY9qASFNcH0k=zH8=uT=71bKejPss44FCzNy=X-A@mail.gmail.com>

On Thu, Jul 11, 2013 at 5:50 AM, Jason Cooper <jason at lakedaemon.net> wrote:
> On Wed, Jul 10, 2013 at 10:08:50PM +0800, Haojian Zhuang wrote:
>> On Wed, Jul 10, 2013 at 8:24 PM, Jason Cooper <jason at lakedaemon.net> wrote:
>> > On Wed, Jul 10, 2013 at 04:19:46PM +0800, Haojian Zhuang wrote:
>> >> On Tue, Jul 9, 2013 at 8:49 PM, Jason Cooper <jason at lakedaemon.net> wrote:
>> >> > Neil,
>> >> >
>> >> > On Tue, Jul 09, 2013 at 02:42:44PM +0800, Neil Zhang wrote:
>> >> >> The documented vendor prefix for Marvell is 'marvell', not 'mrvl', so
>> >> >> let's change it.
>> >> >>
>> >> >> Signed-off-by: Neil Zhang <zhangwm at marvell.com>
>> >> >> ---
>> >> >>  .../devicetree/bindings/arm/mrvl/intc.txt          |   16 +++---
>> >> >>  .../devicetree/bindings/arm/mrvl/mrvl.txt          |    6 +-
>> >> >>  .../devicetree/bindings/arm/mrvl/timer.txt         |    4 +-
>> >> >>  Documentation/devicetree/bindings/i2c/i2c-pxa.txt  |   14 +++---
>> >> >>  .../devicetree/bindings/mmc/sdhci-pxa.txt          |    8 ++--
>> >> >>  .../devicetree/bindings/rtc/sa1100-rtc.txt         |    4 +-
>> >> >>  .../devicetree/bindings/serial/mrvl-serial.txt     |    2 +-
>> >> >>  arch/arm/boot/dts/mmp2-brownstone.dts              |    2 +-
>> >> >>  arch/arm/boot/dts/mmp2.dtsi                        |   56 ++++++++++----------
>> >> >>  arch/arm/boot/dts/pxa168-aspenite.dts              |    2 +-
>> >> >>  arch/arm/boot/dts/pxa168.dtsi                      |   24 ++++----
>> >> >>  arch/arm/boot/dts/pxa2xx.dtsi                      |   16 +++---
>> >> >>  arch/arm/boot/dts/pxa3xx.dtsi                      |    2 +-
>> >> >>  arch/arm/boot/dts/pxa910-dkb.dts                   |    2 +-
>> >> >>  arch/arm/boot/dts/pxa910.dtsi                      |   27 +++++-----
>> >> >>  arch/arm/mach-mmp/irq.c                            |   16 +++---
>> >> >>  arch/arm/mach-mmp/mmp-dt.c                         |   28 +++++-----
>> >> >>  arch/arm/mach-mmp/mmp2-dt.c                        |   16 +++---
>> >> >>  arch/arm/mach-mmp/time.c                           |    2 +-
>> >> >>  arch/arm/mach-pxa/pxa-dt.c                         |   14 +++---
>> >> >>  drivers/i2c/busses/i2c-pxa.c                       |   10 ++--
>> >> >>  drivers/mmc/host/sdhci-pxav2.c                     |    4 +-
>> >> >>  drivers/mmc/host/sdhci-pxav3.c                     |    4 +-
>> >> >>  drivers/rtc/rtc-sa1100.c                           |    4 +-
>> >> >>  drivers/tty/serial/pxa.c                           |    4 +-
>> >> >>  25 files changed, 144 insertions(+), 143 deletions(-)
>> >> >
>> >> > I agree with the need to change, however, this has been in the binding
>> >> > documentation since v3.5.  I wish we had caught this when we decided
>> >> > against using stock ticker symbols (not all stock markets use
>> >> > alphabetical abbreviated names, not all companies are listed on any
>> >> > stock exchange).
>> >> >
>> >> > To do this properly, the drivers are going to have to be compatible with
>> >> > the old and the new names, and the binding docs updated to reflect the
>> >> > legacy name and the preferred name.
>> >> >
>> >>
>> >> It's better to only use the new names.
>> >
>> > In the dts{i}, yes.  But we don't want to break systems in the field
>> > with "mrvl,..." compatible strings.  Therefore, at least the drivers
>> > need an extra compatible string to support "mrvl,...".
>> >
>> > If it had just been since v3.9, it'd be different/simpler.  However,
>> > several vendors have opted to use kernels newer than v3.5, which makes
>> > this scenario a real possibility.
>> >
>> > thx,
>> >
>> > Jason.
>>
>> Is there any vendor using DT for this Marvell chip? I think the answer is no.
>
> Well, Daniel Drake spoke up for OLPC.  Does that count?
>
> thx,
>
> Jason.
>

We don't know they used DT on Marvell MMP2/MMP3. So they don't have DTS file
in kernel, we could use both old name & new name in driver.

Regards
Haojian


From s-anna at ti.com  Thu Jul 11 20:40:47 2013
From: s-anna at ti.com (Suman Anna)
Date: Thu, 11 Jul 2013 19:40:47 -0500
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51DE8215.5060306@ti.com>
References: <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <87mwpuakod.fsf@linaro.org>
 <20130710142633.GV5523@atomide.com> <20130710160704.GH18966@arwen.pp.htv.fi>
 <20130710161158.GA19716@arwen.pp.htv.fi> <20130711063209.GZ5523@atomide.com>
 <51DE8215.5060306@ti.com>
Message-ID: <51DF508F.3050703@ti.com>

On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
> Hi,
> 
> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>> * Felipe Balbi <balbi at ti.com> [130710 09:18]:
>>>
>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>> how about something like below ? It makes omap_device/hwmod and
>>>> pm_runtime agree on the initial state of the device and will prevent
>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>> during probe.
>>>>
>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>
>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>> Author: Felipe Balbi <balbi at ti.com>
>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>
>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>
>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>      initial state of the device, we will unidle the device
>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>      that the device is really active.
> Don't think that it's good idea (
> I've checked some driver's and think this patch will enable some devices
> unpredictably:
> - hwspinlock
> - mailbox
> - iommu
> - ipu
> All above devices need to be enabled on demand only (no
> pm_runtime_get*() calls in probe). More over, some of them have very
> specific enabling sequence - like ipu).
> 
> May be Summan can say more on that.

Indeed, this is a problem for any of the slave processor devices.
mailbox and iommu would be slaves to the remoteproc and the drivers have
a specific sequence of bringing up a processor. The current
hwmod/omap_device code is such that these devices will be left in reset
and the driver code use the omap_device_(de)assert_hardreset API
together with omap_device_enable code to bring up the devices. The
remoteproc driver also needs to assert the resets (there are other
problems associated with using omap_device_idle for remoteproc and
iommu) for bringing up the devices after a suspend sequence. hwspinlock
and mailbox may get away since they are in CORE domain, but definitely
an issue for iommu and remoteproc. I would think that this would also
affect other compute devices like IVAHD, ISS, SGX.

regards
Suman

> 
>>>>
>>>>      By the time driver's probe() is reached, a call to
>>>>      pm_runtime_get_sync() will not cause driver's
>>>>      ->runtime_resume() method to be called at first, only
>>>>      after a successful ->runtime_suspend().
>>>>
>>>>      Signed-off-by: Felipe Balbi <balbi at ti.com>
>>>
>>> btw, this is RFC, haven't tested at all.
>>
>> Yes it does not compile, then removing the extra ; at the end
>> of the functions, it oopses with a NULL pointer exception.
>>
>> Regards,
>>
>> Tony
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 



From peter.chen at freescale.com  Thu Jul 11 22:58:34 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 12 Jul 2013 10:58:34 +0800
Subject: [PATCH v12 06/13] usb: chipidea: add otg_cap attribute for otg
 capable
In-Reply-To: <201307111736.11065.marex@denx.de>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <1373524041-10482-7-git-send-email-peter.chen@freescale.com>
 <201307111736.11065.marex@denx.de>
Message-ID: <20130712025833.GA14793@nchen-desktop>

On Thu, Jul 11, 2013 at 05:36:10PM +0200, Marek Vasut wrote:
> Dear Peter Chen,
> 
> > Since we need otgsc to know vbus's status at some chipidea
> > controllers even it is peripheral-only mode. Besides, some
> > SoCs (eg, AR9331 SoC) don't have otgsc register even
> > the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS.
> > We inroduce otg_cap attribute to indicate if the controller
> > is otg capable, defaultly, we follow the rule that if DCCPARAMS_DC
> > and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS are otg capable, but if there
> > is exception, the platform can override it by device tree or platform data.
> > 
> > Signed-off-by: Peter Chen <peter.chen at freescale.com>
> > ---
> >  drivers/usb/chipidea/core.c  |   35 ++++++++++++++++++++++++++++-------
> >  include/linux/usb/chipidea.h |   13 +++++++++++++
> >  2 files changed, 41 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index 93961ff..e8ceb04 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -405,6 +405,18 @@ static inline void ci_role_destroy(struct ci_hdrc *ci)
> >  	ci_hdrc_host_destroy(ci);
> >  }
> > 
> > +static void ci_get_otg_capable(struct ci_hdrc *ci)
> > +{
> > +	if (ci->platdata->otg_cap != OTG_CAP_ATTR_IS_NOT_EXISTED)
> 
> IS_NONEXISTENT , no?
> 

You mean the English for this string? ok, I can change.
It means if the "otg_cap" is not existed at platform data,
then, the "otg_cap" can be determined by DCCPARAMS

-- 

Best Regards,
Peter Chen



From peter.chen at freescale.com  Thu Jul 11 23:12:01 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 12 Jul 2013 11:12:01 +0800
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <201307111957.19537.marex@denx.de>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <201307111957.19537.marex@denx.de>
Message-ID: <20130712031200.GB14793@nchen-desktop>

On Thu, Jul 11, 2013 at 07:57:19PM +0200, Marek Vasut wrote:
> Hi Peter,
> 
> > This patchset adds tested otg id switch function and
> > vbus connect and disconnect detection for chipidea driver.
> > And fix kinds of bugs found at chipidea drivers after enabling
> > id and vbus detection.
> > 
> > This patch is fully tested at imx6 sabresd platform.
> > My chipidea repo: https://github.com/hzpeterchen/linux-usb.git
> > 
> > Changes for v12:
> > - Rebased greg's usb-next tree (3.10.0-rc7+)
> > - Split more small patches for single function and fix.
> 
> I tested the patchset. Here are the results:
> 
> - VBUS switching
> 
> I'm no longer getting any ID interrupts at all when I apply the patch below. The 
> board stays in HOST mode all the time. If I configure it as peripheral, it works 
> as peripheral. Note with [1], I was able to switch from Peripheral->Host , not 
> the other way around.

Thanks for your testing. But first, can you have me check
if your ID wakeup is enabled?

I can have a test at mx28evk.
Is it current upstream kernel can boot mx28evk run?
I have a RevC board, I would like to know if
any patches needed.
> 
> --- a/arch/arm/boot/dts/imx28-m28evk.dts
> +++ b/arch/arm/boot/dts/imx28-m28evk.dts
> @@ -240,6 +240,8 @@
>  
>         ahb at 80080000 {
>                 usb0: usb at 80080000 {
> +                       dr_mode = "otg";
> +                       phy_mode = "utmi";
>                         vbus-supply = <&reg_usb0_vbus>;
>                         pinctrl-names = "default";
>                         pinctrl-0 = <&usbphy0_pins_a>;
> 
> ---------------------------
> 
> - MX23 UDC issue
> 
> I found a workaround. Now running 'dmesg' via telnet through USB CDC link no 
> longer hangs the USB driver, but works as expected. I applied this small patch 
> that enables the streaming mode. Works on MX23EVK. It's surprising this issue 
> doesn't manifest on MX28, maybe MX28 contains a new revision of the controller. 
> I remember there was some discussion about the streaming mode on MXS some time 
> ago.

It seems not reasonable, the same question for mx23evk,
it can run well with current kernel? I have no board on hand,
let me see if I can find one.
  

-- 

Best Regards,
Peter Chen



From 21cnbao at gmail.com  Thu Jul 11 23:39:46 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Fri, 12 Jul 2013 11:39:46 +0800
Subject: [PATCH 04/12] drivers/mmc/host: don't use
 devm_pinctrl_get_select_default() in probe
In-Reply-To: <1373471889-18107-4-git-send-email-wsa@the-dreams.de>
References: <1373471889-18107-1-git-send-email-wsa@the-dreams.de>
 <1373471889-18107-4-git-send-email-wsa@the-dreams.de>
Message-ID: <CAGsJ_4ygnSs_MLHOsoOo5VK=dLL4m0-o-mFR21oKwZ=LY35jXw@mail.gmail.com>

2013/7/10 Wolfram Sang <wsa at the-dreams.de>:
> Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
> we can rely on device core for setting the default pins. Compile tested only.
>
> Acked-by: Linus Walleij <linus.walleij at linaro.org> (personally at LCE13)
> Signed-off-by: Wolfram Sang <wsa at the-dreams.de>
> ---
>  drivers/mmc/host/mvsdio.c          |    6 ------
>  drivers/mmc/host/mxs-mmc.c         |    8 --------
>  drivers/mmc/host/omap_hsmmc.c      |    7 -------
>  drivers/mmc/host/sdhci-esdhc-imx.c |    8 --------
>  drivers/mmc/host/sdhci-sirf.c      |    8 --------

Wolfram, this has been done for sirf, which version are you based on?

>  5 files changed, 37 deletions(-)

-barry


From marex at denx.de  Thu Jul 11 23:54:35 2013
From: marex at denx.de (Marek Vasut)
Date: Fri, 12 Jul 2013 05:54:35 +0200
Subject: [PATCH v12 06/13] usb: chipidea: add otg_cap attribute for otg
 capable
In-Reply-To: <20130712025833.GA14793@nchen-desktop>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <201307111736.11065.marex@denx.de> <20130712025833.GA14793@nchen-desktop>
Message-ID: <201307120554.35403.marex@denx.de>

Dear Peter Chen,

> On Thu, Jul 11, 2013 at 05:36:10PM +0200, Marek Vasut wrote:
> > Dear Peter Chen,
> > 
> > > Since we need otgsc to know vbus's status at some chipidea
> > > controllers even it is peripheral-only mode. Besides, some
> > > SoCs (eg, AR9331 SoC) don't have otgsc register even
> > > the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS.
> > > We inroduce otg_cap attribute to indicate if the controller
> > > is otg capable, defaultly, we follow the rule that if DCCPARAMS_DC
> > > and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS are otg capable, but if
> > > there is exception, the platform can override it by device tree or
> > > platform data.
> > > 
> > > Signed-off-by: Peter Chen <peter.chen at freescale.com>
> > > ---
> > > 
> > >  drivers/usb/chipidea/core.c  |   35
> > >  ++++++++++++++++++++++++++++------- include/linux/usb/chipidea.h |  
> > >  13 +++++++++++++
> > >  2 files changed, 41 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > > index 93961ff..e8ceb04 100644
> > > --- a/drivers/usb/chipidea/core.c
> > > +++ b/drivers/usb/chipidea/core.c
> > > @@ -405,6 +405,18 @@ static inline void ci_role_destroy(struct ci_hdrc
> > > *ci)
> > > 
> > >  	ci_hdrc_host_destroy(ci);
> > >  
> > >  }
> > > 
> > > +static void ci_get_otg_capable(struct ci_hdrc *ci)
> > > +{
> > > +	if (ci->platdata->otg_cap != OTG_CAP_ATTR_IS_NOT_EXISTED)
> > 
> > IS_NONEXISTENT , no?
> 
> You mean the English for this string? ok, I can change.

Yes, IS_NOT_EXISTED doesn't make much sense. Sorry, don't mean to nitpick.

> It means if the "otg_cap" is not existed at platform data,
> then, the "otg_cap" can be determined by DCCPARAMS

Then maybe just call it OTG_CAP_ATTR_NOT_SET or something .

Best regards,
Marek Vasut


From horms at verge.net.au  Fri Jul 12 00:00:05 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 12 Jul 2013 13:00:05 +0900
Subject: [PATCH v2 01/02] ARM: shmobile: Introduce r8a7790_read_mode_pins()
In-Reply-To: <20130711162219.933.96902.sendpatchset@w520>
References: <20130711162209.933.47610.sendpatchset@w520>
 <20130711162219.933.96902.sendpatchset@w520>
Message-ID: <20130712040005.GB26287@verge.net.au>

On Fri, Jul 12, 2013 at 01:22:19AM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Break out the r8a7790 boot mode code into a separate
> function so it can be shared by multiple users.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

Thanks.

I have queued this up for v3.12 in the soc branch and it
is available in renesas-devel-20130712.


From horms at verge.net.au  Fri Jul 12 00:00:27 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 12 Jul 2013 13:00:27 +0900
Subject: [PATCH 02/02] ARM: shmobile: Setup r8a7790 arch timer based on
 MD pins
In-Reply-To: <20130711162229.933.53924.sendpatchset@w520>
References: <20130711162209.933.47610.sendpatchset@w520>
 <20130711162229.933.53924.sendpatchset@w520>
Message-ID: <20130712040025.GC26287@verge.net.au>

On Fri, Jul 12, 2013 at 01:22:29AM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Update the r8a7790 arch timer setup code to configure the
> frequency dynamically at boot time. This means that the arch
> timer driver will be able to detect a timer frequency that
> has been calculated based on the MD pins instead of a fixed
> and potentially incorrect 13 MHz.
> 
> With this patch applied the Linux kernel will correctly
> support the r8a7790 Lager board that uses a 20 Mhz EXTAL.
> The arch timer will operate on 10 MHz and the Linux arch
> timer driver will be correctly configured to use 10 MHz.
> 
> Without this patch the 20 MHz EXTAL will be used to drive
> the arch timer at 10 MHz, but the Linux arch timer driver
> will believe it is counting at 13 Mhz.
> 
> Reported-by: Ulrich Hecht <ulrich.hecht at gmail.com>
> Signed-off-by: Magnus Damm <damm at opensource.se>
> Tested-by: Ulrich Hecht <ulrich.hecht at gmail.com>

Thanks.

I have queued this up for v3.12 in the soc branch and it
is available in renesas-devel-20130712.


From marex at denx.de  Fri Jul 12 00:04:43 2013
From: marex at denx.de (Marek Vasut)
Date: Fri, 12 Jul 2013 06:04:43 +0200
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <20130712031200.GB14793@nchen-desktop>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <201307111957.19537.marex@denx.de> <20130712031200.GB14793@nchen-desktop>
Message-ID: <201307120604.43642.marex@denx.de>

Hi Peter,

> On Thu, Jul 11, 2013 at 07:57:19PM +0200, Marek Vasut wrote:
> > Hi Peter,
> > 
> > > This patchset adds tested otg id switch function and
> > > vbus connect and disconnect detection for chipidea driver.
> > > And fix kinds of bugs found at chipidea drivers after enabling
> > > id and vbus detection.
> > > 
> > > This patch is fully tested at imx6 sabresd platform.
> > > My chipidea repo: https://github.com/hzpeterchen/linux-usb.git
> > > 
> > > Changes for v12:
> > > - Rebased greg's usb-next tree (3.10.0-rc7+)
> > > - Split more small patches for single function and fix.
> > 
> > I tested the patchset. Here are the results:
> > 
> > - VBUS switching
> > 
> > I'm no longer getting any ID interrupts at all when I apply the patch
> > below. The board stays in HOST mode all the time. If I configure it as
> > peripheral, it works as peripheral. Note with [1], I was able to switch
> > from Peripheral->Host , not the other way around.
> 
> Thanks for your testing. But first, can you have me check
> if your ID wakeup is enabled?

ID wakeup? How do I check?

> I can have a test at mx28evk.
> Is it current upstream kernel can boot mx28evk run?

Yes, I use next-20130711 and it works fine.

> I have a RevC board, I would like to know if
> any patches needed.

Apply just this patchset and you should be all set.

> > --- a/arch/arm/boot/dts/imx28-m28evk.dts
> > +++ b/arch/arm/boot/dts/imx28-m28evk.dts
> > @@ -240,6 +240,8 @@
> > 
> >         ahb at 80080000 {
> >         
> >                 usb0: usb at 80080000 {
> > 
> > +                       dr_mode = "otg";
> > +                       phy_mode = "utmi";
> > 
> >                         vbus-supply = <&reg_usb0_vbus>;
> >                         pinctrl-names = "default";
> >                         pinctrl-0 = <&usbphy0_pins_a>;
> > 
> > ---------------------------
> > 
> > - MX23 UDC issue
> > 
> > I found a workaround. Now running 'dmesg' via telnet through USB CDC link
> > no longer hangs the USB driver, but works as expected. I applied this
> > small patch that enables the streaming mode. Works on MX23EVK. It's
> > surprising this issue doesn't manifest on MX28, maybe MX28 contains a
> > new revision of the controller. I remember there was some discussion
> > about the streaming mode on MXS some time ago.
> 
> It seems not reasonable

I talked to Fabio and he said he met similar issue on MX6, where disabling the 
streaming mode fixed the problem. Could it possibly be so that the non-streaming 
mode is broken on mx23?

btw. I also tested this on STMP3780-based device, works the same way as MX23 
does, streaming mode has to be enabled.

> the same question for mx23evk,
> it can run well with current kernel? I have no board on hand,
> let me see if I can find one.

Yes, MX23EVK rev. B2 works just fine with next-20130711 . You need to add the DT 
USB sections for MX23EVK, but they can be copied from imx28.dtsi + imx28-evk.dts 
.

Best regards,
Marek Vasut


From padma.kvr at gmail.com  Fri Jul 12 00:22:35 2013
From: padma.kvr at gmail.com (Padma Venkat)
Date: Fri, 12 Jul 2013 09:52:35 +0530
Subject: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on
 Exynos5420
In-Reply-To: <10406176.2lc5qJ8Oq7@thinkpad>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
 <20130711104804.GK24508@sirena.org.uk>
 <10406176.2lc5qJ8Oq7@thinkpad>
Message-ID: <CAAgF-BdTY3x9Hb9HmTm6WBrpES7QdKO_VbxN_9zu6zf43AaGQA@mail.gmail.com>

On Thu, Jul 11, 2013 at 4:37 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> On Thursday 11 of July 2013 11:48:04 Mark Brown wrote:
>> On Thu, Jul 11, 2013 at 12:38:24PM +0530, Padmavathi Venna wrote:
>> > -#define MOD_LR_LLOW                (0 << 7)
>> > -#define MOD_LR_RLOW                (1 << 7)
>> > -#define MOD_SDF_IIS                (0 << 5)
>> > -#define MOD_SDF_MSB                (1 << 5)
>> > -#define MOD_SDF_LSB                (2 << 5)
>> > -#define MOD_SDF_MASK               (3 << 5)
>> >
>> > +#define MOD_LR_LLOW                0
>> > +#define MOD_LR_RLOW                1
>> > +#define MOD_SDF_SHIFT              5
>> > +#define MOD_SDF_IIS                0
>> > +#define MOD_SDF_MSB                1
>> > +#define MOD_SDF_LSB                2
>> > +#define MOD_SDF_MASK               3
>>
>> This patch has an awful lot of coding style changes like this which
>> are just coding style changes and not implementing TDM support.  These
>> should be done separately, not as part of the same patch, in order to
>> make the code easier to review.
>>
>> >     case 768:
>> > -           mod |= MOD_RCLK_768FS;
>> > +           mod |= (MOD_RCLK_768FS << rfs_shift);
>> >
>> >             break;
>>
>> This stuff is another example.
>>
>> I think the change itself should be fine but I'm not 100% sure I'm
>> correctly identifying what's a stylistic change and what's a functional
>> change.
>
> Right. This could be split into two patches, first reworking the style to give
> more flexibility with operations on registers and another one adding TDM
> specific changes, like new bitfield definitions and conditional handling of
> register accesses to account for new bitfield locations.
>
> Best regards,
> Tomasz
>

Ok. I will bisect the changes into two patches as suggested.

Thanks
Padma


From padma.kvr at gmail.com  Fri Jul 12 00:37:22 2013
From: padma.kvr at gmail.com (Padma Venkat)
Date: Fri, 12 Jul 2013 10:07:22 +0530
Subject: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on
 Exynos5420
In-Reply-To: <20130711130139.GQ24508@sirena.org.uk>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
 <29860116.IF545KsGYb@thinkpad>
 <20130711112023.GM24508@sirena.org.uk>
 <2214161.FSfscAvpna@thinkpad>
 <20130711130139.GQ24508@sirena.org.uk>
Message-ID: <CAAgF-BdM4jw0o4+ELVo_N029tbgMJBBqJxU91e=TgBNiiREyaA@mail.gmail.com>

Hi,

On Thu, Jul 11, 2013 at 6:31 PM, Mark Brown <broonie at kernel.org> wrote:
> On Thu, Jul 11, 2013 at 01:41:40PM +0200, Tomasz Figa wrote:
>> On Thursday 11 of July 2013 12:20:23 Mark Brown wrote:
>
>> > This is a bit of a larger project sadly, there was resistance to doing
>> > the DT bindings based on compatible strings using the IP version :(
>
>> I'm not sure if this case is related to this problem in any way. I just
>> suggested introducing a new include like samsung,exynos5420-i2s, a opposed to
>> using samsung,exynos5250-i2s and adding flags, since the I2S in Exynos5420 is
>
> Well, it *should* be samsung,i2s-vN where N is the version number of the
> IP but documentation on the versioning has been patchy hence this whole
> thinng.
>

A new version number is added when a there was some change in the IP
like adding a internal mux to the IP, adding multi channel support,
adding reset control bit. This was done in the older code with
platform device.
Same thing is followed here. So as previously done, adding a new
compatible name like "samsung,i2s-v6" with new quirk
"samsung,supports-tdm" is okey?

I will mention about this versioning info in the Documentation in the
next patch.

>> the first one to have this TDM or whatever mode. (I'd still like to hear what
>> it is...)
>
> What it *should* be is the option to send more than one audio stream
> down a link using time division multiplexing.

Thanks
Padma


From padma.kvr at gmail.com  Fri Jul 12 00:42:12 2013
From: padma.kvr at gmail.com (Padma Venkat)
Date: Fri, 12 Jul 2013 10:12:12 +0530
Subject: [PATCH] ASoC: Samsung: Set RFS and BFS in slave mode
In-Reply-To: <20130711111144.GL24508@sirena.org.uk>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
 <1373526505-27115-2-git-send-email-padma.v@samsung.com>
 <20130711111144.GL24508@sirena.org.uk>
Message-ID: <CAAgF-BedX9G80Pjp5+oOZRCekzDzORUJj2Wvr_Lqpz=O3qg4tA@mail.gmail.com>

Hi,

On Thu, Jul 11, 2013 at 4:41 PM, Mark Brown <broonie at kernel.org> wrote:
> On Thu, Jul 11, 2013 at 12:38:25PM +0530, Padmavathi Venna wrote:
>> As per the User Manual, the RFS and BFS should be set in slave mode
>> for correct operation.
>
> Applied, thanks.  Since this is a fix it should have been the first
> patch in the series - this allows fixes to be sent to
>
>> Reviewed-on: https://gerrit-int.chromium.org/37841
>
> Including things like this isn't terribly helpful - this is the Chromium
> internal system and nobody in the community can view the review.  A link
> to a public system might be useful but a private one should be omitted.

I thought it was link to the public gerrit review system. Will remove next time.

Thanks
Padma


From yadi.brar01 at gmail.com  Fri Jul 12 01:11:13 2013
From: yadi.brar01 at gmail.com (Yadwinder Singh Brar)
Date: Fri, 12 Jul 2013 10:41:13 +0530
Subject: [PATCH] clk: samsung: add set_rate and round_rate callbacks for
 pll45xx
In-Reply-To: <CAJuYYwSSQ49Tp17Kja9sZgnibYR7UDrvSpoyPUs0i6GC6j2qeA@mail.gmail.com>
References: <1373534869-12034-1-git-send-email-thomas.abraham@linaro.org>
 <CAKew6eV0QP31gJNB2waeSRB5DN5Vs+mXO5bwaD5TiHYZvrANQA@mail.gmail.com>
 <CAJuYYwSSQ49Tp17Kja9sZgnibYR7UDrvSpoyPUs0i6GC6j2qeA@mail.gmail.com>
Message-ID: <CAKew6eVXZrf3BOM88mE9jRC+5KW8VZi6hhLvzK+E=kdZSeXuAQ@mail.gmail.com>

On Thu, Jul 11, 2013 at 8:54 PM, Thomas Abraham
<thomas.abraham at linaro.org> wrote:
> Hi Yadwinder,
>
> Thanks for your comments.
>
> On 11 July 2013 16:14, Yadwinder Singh Brar <yadi.brar01 at gmail.com> wrote:
>> Hi Thomas,
>>
>> On Thu, Jul 11, 2013 at 2:57 PM, Thomas Abraham
>> <thomas.abraham at linaro.org> wrote:
>>> Add support for set_rate and round_rate callbacks for pll45xx pll. This allows
>>> configuring pll45xx to generate a desired clock output.
>>>
>>> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
>>> ---
>>>
>>> The set_rate and round_rate callbacks in this patch for pll45xx are handled
>>> slightly differently from the way it is done in the (not yet merged) patch
>>> series from Yadwinder
>>> (http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg19540.html)
>>>
>>> In this patch, the pll lookup table is kept as part of the pll configuration
>>> code itself, since the pll is just a hardware block which takes an input
>>> frequency and configuration values to genertate a output clock frequency.
>>> Given a set of inputs, a pll of a given type will generate the same output
>>> regardless of the SoC it is used in. So instead of supplying the pll lookup
>>
>> Tomasz also raised similar point earlier in discussion on that series.
>> That time a question which remained unanswered for which we were waiting
>> (as requested from hardware guys also) was that :
>> Whether we need to stick to recommended values only or we can drive a
>> particular output frequency with a given input frequency with any possible
>> set of (P, M, S) values ?
>
> The default lookup table could list all the possible target frequency
> and its associated PMS values. Having a bigger list of PMS lookup

same target frequency can have different associated PMS values recommended
in manual. So the question was in that case whether to stick to
recommended values.

> values should not matter since the CPUFreq driver would have a smaller
> subset of frequency which can be selected on a particular SoC.
>
>>
>> Theoretically it seems possible but from manual its seems to prefer
>> recommended values.
>> Also I am not sure whether same values are always recommended in user manuals
>> for different SoCs using same PLL type.
>>
> [...]

Regards,
Yadwinder


From shawn.guo at linaro.org  Fri Jul 12 01:18:06 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Jul 2013 13:18:06 +0800
Subject: [PATCH] ARM: dts: add more imx6q/dl pin groups
Message-ID: <1373606286-31245-1-git-send-email-shawn.guo@linaro.org>

Add more imx6q/dl pin groups for those supported boards, e.g. sabresd,
sabreauto, arm2.

IPU2 pin groups are added into imx6q.dtsi, since the block is only
available on imx6q.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx6q.dtsi   |   36 +++++
 arch/arm/boot/dts/imx6qdl.dtsi |  285 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 321 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 5e6c7f3..f104223 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -73,6 +73,42 @@
 
 			iomuxc: iomuxc at 020e0000 {
 				compatible = "fsl,imx6q-iomuxc";
+
+				ipu2 {
+					pinctrl_ipu2_1: ipu2grp-1 {
+						fsl,pins = <
+							PAD_DI0_DISP_CLK__IPU2_DI0_DISP_CLK 0x10
+							PAD_DI0_PIN15__IPU2_DI0_PIN15       0x10
+							PAD_DI0_PIN2__IPU2_DI0_PIN02        0x10
+							PAD_DI0_PIN3__IPU2_DI0_PIN03        0x10
+							PAD_DI0_PIN4__IPU2_DI0_PIN04        0x80000000
+							PAD_DISP0_DAT0__IPU2_DISP0_DATA00   0x10
+							PAD_DISP0_DAT1__IPU2_DISP0_DATA01   0x10
+							PAD_DISP0_DAT2__IPU2_DISP0_DATA02   0x10
+							PAD_DISP0_DAT3__IPU2_DISP0_DATA03   0x10
+							PAD_DISP0_DAT4__IPU2_DISP0_DATA04   0x10
+							PAD_DISP0_DAT5__IPU2_DISP0_DATA05   0x10
+							PAD_DISP0_DAT6__IPU2_DISP0_DATA06   0x10
+							PAD_DISP0_DAT7__IPU2_DISP0_DATA07   0x10
+							PAD_DISP0_DAT8__IPU2_DISP0_DATA08   0x10
+							PAD_DISP0_DAT9__IPU2_DISP0_DATA09   0x10
+							PAD_DISP0_DAT10__IPU2_DISP0_DATA10  0x10
+							PAD_DISP0_DAT11__IPU2_DISP0_DATA11  0x10
+							PAD_DISP0_DAT12__IPU2_DISP0_DATA12  0x10
+							PAD_DISP0_DAT13__IPU2_DISP0_DATA13  0x10
+							PAD_DISP0_DAT14__IPU2_DISP0_DATA14  0x10
+							PAD_DISP0_DAT15__IPU2_DISP0_DATA15  0x10
+							PAD_DISP0_DAT16__IPU2_DISP0_DATA16  0x10
+							PAD_DISP0_DAT17__IPU2_DISP0_DATA17  0x10
+							PAD_DISP0_DAT18__IPU2_DISP0_DATA18  0x10
+							PAD_DISP0_DAT19__IPU2_DISP0_DATA19  0x10
+							PAD_DISP0_DAT20__IPU2_DISP0_DATA20  0x10
+							PAD_DISP0_DAT21__IPU2_DISP0_DATA21  0x10
+							PAD_DISP0_DAT22__IPU2_DISP0_DATA22  0x10
+							PAD_DISP0_DAT23__IPU2_DISP0_DATA23  0x10
+						>;
+					};
+				};
 			};
 		};
 
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 1f1c493..5ca82bf 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -587,6 +587,14 @@
 							PAD_CSI0_DAT6__AUD3_TXFS 0x80000000
 						>;
 					};
+
+					pinctrl_audmux_3: audmux-3 {
+						fsl,pins = <
+							PAD_DISP0_DAT16__AUD5_TXC  0x80000000
+							PAD_DISP0_DAT18__AUD5_TXFS 0x80000000
+							PAD_DISP0_DAT19__AUD5_RXD  0x80000000
+						>;
+					};
 				};
 
 				ecspi1 {
@@ -681,6 +689,62 @@
 					};
 				};
 
+				esai {
+					pinctrl_esai_1: esaigrp-1 {
+						fsl,pins = <
+							PAD_ENET_RXD0__ESAI_TX_HF_CLK 0x1b030
+							PAD_ENET_CRS_DV__ESAI_TX_CLK  0x1b030
+							PAD_ENET_RXD1__ESAI_TX_FS     0x1b030
+							PAD_ENET_TX_EN__ESAI_TX3_RX2  0x1b030
+							PAD_ENET_TXD1__ESAI_TX2_RX3   0x1b030
+							PAD_ENET_TXD0__ESAI_TX4_RX1   0x1b030
+							PAD_ENET_MDC__ESAI_TX5_RX0    0x1b030
+							PAD_NANDF_CS2__ESAI_TX0       0x1b030
+							PAD_NANDF_CS3__ESAI_TX1       0x1b030
+						>;
+					};
+
+					pinctrl_esai_2: esaigrp-2 {
+						fsl,pins = <
+							PAD_ENET_CRS_DV__ESAI_TX_CLK 0x1b030
+							PAD_ENET_RXD1__ESAI_TX_FS    0x1b030
+							PAD_ENET_TX_EN__ESAI_TX3_RX2 0x1b030
+							PAD_GPIO_5__ESAI_TX2_RX3     0x1b030
+							PAD_ENET_TXD0__ESAI_TX4_RX1  0x1b030
+							PAD_ENET_MDC__ESAI_TX5_RX0   0x1b030
+							PAD_GPIO_17__ESAI_TX0        0x1b030
+							PAD_NANDF_CS3__ESAI_TX1      0x1b030
+							PAD_ENET_MDIO__ESAI_RX_CLK   0x1b030
+							PAD_GPIO_9__ESAI_RX_FS       0x1b030
+						>;
+					};
+				};
+
+				flexcan1 {
+					pinctrl_flexcan1_1: flexcan1grp-1 {
+						fsl,pins = <
+							PAD_KEY_ROW2__FLEXCAN1_RX 0x80000000
+							PAD_KEY_COL2__FLEXCAN1_TX 0x80000000
+						>;
+					};
+
+					pinctrl_flexcan1_2: flexcan1grp-2 {
+						fsl,pins = <
+							PAD_GPIO_7__FLEXCAN1_TX   0x80000000
+							PAD_KEY_ROW2__FLEXCAN1_RX 0x80000000
+						>;
+					};
+				};
+
+				flexcan2 {
+					pinctrl_flexcan2_1: flexcan2grp-1 {
+						fsl,pins = <
+							PAD_KEY_COL4__FLEXCAN2_TX 0x80000000
+							PAD_KEY_ROW4__FLEXCAN2_RX 0x80000000
+						>;
+					};
+				};
+
 				gpmi-nand {
 					pinctrl_gpmi_nand_1: gpmi-nand-1 {
 						fsl,pins = <
@@ -705,6 +769,43 @@
 					};
 				};
 
+				hdmi_hdcp {
+					pinctrl_hdmi_hdcp_1: hdmihdcpgrp-1 {
+						fsl,pins = <
+							PAD_KEY_COL3__HDMI_TX_DDC_SCL 0x4001b8b1
+							PAD_KEY_ROW3__HDMI_TX_DDC_SDA 0x4001b8b1
+						>;
+					};
+
+					pinctrl_hdmi_hdcp_2: hdmihdcpgrp-2 {
+						fsl,pins = <
+							PAD_EIM_EB2__HDMI_TX_DDC_SCL 0x4001b8b1
+							PAD_EIM_D16__HDMI_TX_DDC_SDA 0x4001b8b1
+						>;
+					};
+
+					pinctrl_hdmi_hdcp_3: hdmihdcpgrp-3 {
+						fsl,pins = <
+							PAD_EIM_EB2__HDMI_TX_DDC_SCL  0x4001b8b1
+							PAD_KEY_ROW3__HDMI_TX_DDC_SDA 0x4001b8b1
+						>;
+					};
+				};
+
+				hdmi_cec {
+					pinctrl_hdmi_cec_1: hdmicecgrp-1 {
+						fsl,pins = <
+							PAD_EIM_A25__HDMI_TX_CEC_LINE 0x1f8b0
+						>;
+					};
+
+					pinctrl_hdmi_cec_2: hdmicecgrp-2 {
+						fsl,pins = <
+							PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
+						>;
+					};
+				};
+
 				i2c1 {
 					pinctrl_i2c1_1: i2c1grp-1 {
 						fsl,pins = <
@@ -735,6 +836,13 @@
 							PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
 						>;
 					};
+
+					pinctrl_i2c2_3: i2c2grp-3 {
+						fsl,pins = <
+							PAD_EIM_EB2__I2C2_SCL  0x4001b8b1
+							PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+						>;
+					};
 				};
 
 				i2c3 {
@@ -744,6 +852,153 @@
 							PAD_EIM_D18__I2C3_SDA 0x4001b8b1
 						>;
 					};
+
+					pinctrl_i2c3_2: i2c3grp-2 {
+						fsl,pins = <
+							PAD_GPIO_3__I2C3_SCL 0x4001b8b1
+							PAD_GPIO_6__I2C3_SDA 0x4001b8b1
+						>;
+					};
+
+					pinctrl_i2c3_3: i2c3grp-3 {
+						fsl,pins = <
+							PAD_GPIO_5__I2C3_SCL  0x4001b8b1
+							PAD_GPIO_16__I2C3_SDA 0x4001b8b1
+						>;
+					};
+
+					pinctrl_i2c3_4: i2c3grp-4 {
+						fsl,pins = <
+							PAD_GPIO_3__I2C3_SCL  0x4001b8b1
+							PAD_EIM_D18__I2C3_SDA 0x4001b8b1
+						>;
+					};
+				};
+
+				ipu1 {
+					pinctrl_ipu1_1: ipu1grp-1 {
+						fsl,pins = <
+							PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10
+							PAD_DI0_PIN15__IPU1_DI0_PIN15       0x10
+							PAD_DI0_PIN2__IPU1_DI0_PIN02        0x10
+							PAD_DI0_PIN3__IPU1_DI0_PIN03        0x10
+							PAD_DI0_PIN4__IPU1_DI0_PIN04        0x80000000
+							PAD_DISP0_DAT0__IPU1_DISP0_DATA00   0x10
+							PAD_DISP0_DAT1__IPU1_DISP0_DATA01   0x10
+							PAD_DISP0_DAT2__IPU1_DISP0_DATA02   0x10
+							PAD_DISP0_DAT3__IPU1_DISP0_DATA03   0x10
+							PAD_DISP0_DAT4__IPU1_DISP0_DATA04   0x10
+							PAD_DISP0_DAT5__IPU1_DISP0_DATA05   0x10
+							PAD_DISP0_DAT6__IPU1_DISP0_DATA06   0x10
+							PAD_DISP0_DAT7__IPU1_DISP0_DATA07   0x10
+							PAD_DISP0_DAT8__IPU1_DISP0_DATA08   0x10
+							PAD_DISP0_DAT9__IPU1_DISP0_DATA09   0x10
+							PAD_DISP0_DAT10__IPU1_DISP0_DATA10  0x10
+							PAD_DISP0_DAT11__IPU1_DISP0_DATA11  0x10
+							PAD_DISP0_DAT12__IPU1_DISP0_DATA12  0x10
+							PAD_DISP0_DAT13__IPU1_DISP0_DATA13  0x10
+							PAD_DISP0_DAT14__IPU1_DISP0_DATA14  0x10
+							PAD_DISP0_DAT15__IPU1_DISP0_DATA15  0x10
+							PAD_DISP0_DAT16__IPU1_DISP0_DATA16  0x10
+							PAD_DISP0_DAT17__IPU1_DISP0_DATA17  0x10
+							PAD_DISP0_DAT18__IPU1_DISP0_DATA18  0x10
+							PAD_DISP0_DAT19__IPU1_DISP0_DATA19  0x10
+							PAD_DISP0_DAT20__IPU1_DISP0_DATA20  0x10
+							PAD_DISP0_DAT21__IPU1_DISP0_DATA21  0x10
+							PAD_DISP0_DAT22__IPU1_DISP0_DATA22  0x10
+							PAD_DISP0_DAT23__IPU1_DISP0_DATA23  0x10
+						>;
+					};
+
+					pinctrl_ipu1_2: ipu1grp-2 { /* parallel camera */
+						fsl,pins = <
+							PAD_CSI0_DAT12__IPU1_CSI0_DATA12    0x80000000
+							PAD_CSI0_DAT13__IPU1_CSI0_DATA13    0x80000000
+							PAD_CSI0_DAT14__IPU1_CSI0_DATA14    0x80000000
+							PAD_CSI0_DAT15__IPU1_CSI0_DATA15    0x80000000
+							PAD_CSI0_DAT16__IPU1_CSI0_DATA16    0x80000000
+							PAD_CSI0_DAT17__IPU1_CSI0_DATA17    0x80000000
+							PAD_CSI0_DAT18__IPU1_CSI0_DATA18    0x80000000
+							PAD_CSI0_DAT19__IPU1_CSI0_DATA19    0x80000000
+							PAD_CSI0_DATA_EN__IPU1_CSI0_DATA_EN 0x80000000
+							PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK   0x80000000
+							PAD_CSI0_MCLK__IPU1_CSI0_HSYNC      0x80000000
+							PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC     0x80000000
+						>;
+					};
+
+					pinctrl_ipu1_3: ipu1grp-3 { /* parallel port 16-bit */
+						fsl,pins = <
+							PAD_CSI0_DAT4__IPU1_CSI0_DATA04   0x80000000
+							PAD_CSI0_DAT5__IPU1_CSI0_DATA05   0x80000000
+							PAD_CSI0_DAT6__IPU1_CSI0_DATA06   0x80000000
+							PAD_CSI0_DAT7__IPU1_CSI0_DATA07   0x80000000
+							PAD_CSI0_DAT8__IPU1_CSI0_DATA08   0x80000000
+							PAD_CSI0_DAT9__IPU1_CSI0_DATA09   0x80000000
+							PAD_CSI0_DAT10__IPU1_CSI0_DATA10  0x80000000
+							PAD_CSI0_DAT11__IPU1_CSI0_DATA11  0x80000000
+							PAD_CSI0_DAT12__IPU1_CSI0_DATA12  0x80000000
+							PAD_CSI0_DAT13__IPU1_CSI0_DATA13  0x80000000
+							PAD_CSI0_DAT14__IPU1_CSI0_DATA14  0x80000000
+							PAD_CSI0_DAT15__IPU1_CSI0_DATA15  0x80000000
+							PAD_CSI0_DAT16__IPU1_CSI0_DATA16  0x80000000
+							PAD_CSI0_DAT17__IPU1_CSI0_DATA17  0x80000000
+							PAD_CSI0_DAT18__IPU1_CSI0_DATA18  0x80000000
+							PAD_CSI0_DAT19__IPU1_CSI0_DATA19  0x80000000
+							PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x80000000
+							PAD_CSI0_MCLK__IPU1_CSI0_HSYNC    0x80000000
+							PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC   0x80000000
+						>;
+					};
+				};
+
+				mlb {
+					pinctrl_mlb_1: mlbgrp-1 {
+						fsl,pins = <
+							PAD_GPIO_3__MLB_CLK  0x71
+							PAD_GPIO_6__MLB_SIG  0x71
+							PAD_GPIO_2__MLB_DATA 0x71
+						>;
+					};
+
+					pinctrl_mlb_2: mlbgrp-2 {
+						fsl,pins = <
+							PAD_ENET_TXD1__MLB_CLK 0x71
+							PAD_GPIO_6__MLB_SIG    0x71
+							PAD_GPIO_2__MLB_DATA   0x71
+						>;
+					};
+				};
+
+				pwm0 {
+					pinctrl_pwm0_1: pwm0grp-1 {
+						fsl,pins = <
+							PAD_SD1_DAT3__PWM1_OUT 0x1b0b1
+						>;
+					};
+				};
+
+				pwm3 {
+					pinctrl_pwm3_1: pwm3grp-1 {
+						fsl,pins = <
+							PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
+						>;
+					};
+				};
+
+				spdif {
+					pinctrl_spdif_1: spdifgrp-1 {
+						fsl,pins = <
+							PAD_KEY_COL3__SPDIF_IN 0x1b0b0
+						>;
+					};
+
+					pinctrl_spdif_2: spdifgrp-2 {
+						fsl,pins = <
+							PAD_GPIO_16__SPDIF_IN  0x1b0b0
+							PAD_GPIO_17__SPDIF_OUT 0x1b0b0
+						>;
+					};
 				};
 
 				uart1 {
@@ -796,6 +1051,36 @@
 					};
 				};
 
+				usbh2 {
+					pinctrl_usbh2_1: usbh2grp-1 {
+						fsl,pins = <
+							PAD_RGMII_TXC__USB_H2_DATA      0x40013030
+							PAD_RGMII_TX_CTL__USB_H2_STROBE 0x40013030
+						>;
+					};
+
+					pinctrl_usbh2_2: usbh2grp-2 {
+						fsl,pins = <
+							PAD_RGMII_TX_CTL__USB_H2_STROBE 0x40017030
+						>;
+					};
+				};
+
+				usbh3 {
+					pinctrl_usbh3_1: usbh3grp-1 {
+						fsl,pins = <
+							PAD_RGMII_RX_CTL__USB_H3_DATA 0x40013030
+							PAD_RGMII_RXC__USB_H3_STROBE  0x40013030
+						>;
+					};
+
+					pinctrl_usbh3_2: usbh3grp-2 {
+						fsl,pins = <
+							PAD_RGMII_RXC__USB_H3_STROBE 0x40017030
+						>;
+					};
+				};
+
 				usdhc2 {
 					pinctrl_usdhc2_1: usdhc2grp-1 {
 						fsl,pins = <
-- 
1.7.9.5




From yadi.brar01 at gmail.com  Fri Jul 12 01:27:32 2013
From: yadi.brar01 at gmail.com (Yadwinder Singh Brar)
Date: Fri, 12 Jul 2013 10:57:32 +0530
Subject: [PATCH] clk: samsung: add set_rate and round_rate callbacks for
 pll45xx
In-Reply-To: <CAJuYYwSwNT=ymU72bY8x8PBk=BrVWzMrxGee3kaHOyk3cozv+g@mail.gmail.com>
References: <1373534869-12034-1-git-send-email-thomas.abraham@linaro.org>
 <1395018.H3ijo3R2Tj@thinkpad>
 <CAJuYYwSwNT=ymU72bY8x8PBk=BrVWzMrxGee3kaHOyk3cozv+g@mail.gmail.com>
Message-ID: <CAKew6eXR7Cz80e1ZHTKy7X5mvMN4dgcQQZHgz0wB6J-mTnTFfw@mail.gmail.com>

Hi Thomas,

>>> +     /* select a lookup table based on parent clock frequency */
>>> +     switch (*prate) {
>>> +     case 24000000:
>>> +             f = pll45xx_freq_lookup_24mhz;
>>> +             cnt = ARRAY_SIZE(pll45xx_freq_lookup_24mhz);
>>> +             break;
>>> +     default:
>>> +             pr_err("%s: unsupported parent clock rate", __func__);
>>> +             return *prate;
>>> +     }
>>
>> Again, PMS table can be set in register function and just used here.
>
> Ok, but it would be good to give another thought about having the
> lookup table tied to the pll configuration code. If required, we could
> have both options implemented. A pll will have a default PMS lookup
> table here and if a SoC specific table is needed, it can be supplied
> at the time of PLL registration.
>

I agree with this approach.
But I am not sure actually how many SoC can have common  table.

Regards,
Yadwinder


From shawn.guo at linaro.org  Fri Jul 12 01:28:35 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Jul 2013 13:28:35 +0800
Subject: [PATCH 1/2] ARM: dts: imx6q{dl}: add a new pinctrl for uart3
In-Reply-To: <1373449227-11740-1-git-send-email-b32955@freescale.com>
References: <1373449227-11740-1-git-send-email-b32955@freescale.com>
Message-ID: <20130712052833.GA25501@S2101-09.ap.freescale.net>

On Wed, Jul 10, 2013 at 05:40:26PM +0800, Huang Shijie wrote:
> Add the a new pinctrl for uart3. In the imx6q{dl}-sabreauto boards,
> the uart3 is used for Bluetooth.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>

We have some pin groups tweaking happening in DTS files.  Can you please
rebase your patches on the latest imx/dt branch?

Shawn

> ---
>  arch/arm/boot/dts/imx6dl.dtsi |   11 +++++++++++
>  arch/arm/boot/dts/imx6q.dtsi  |   11 +++++++++++
>  2 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index a1302ed..d818ced 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boot/dts/imx6dl.dtsi
> @@ -234,6 +234,17 @@
>  					};
>  				};
>  
> +				uart3 {
> +					pinctrl_uart3_1: uart3grp-1 {
> +						fsl,pins = <
> +							MX6DL_PAD_SD4_CLK__UART3_RX_DATA 0x1b0b1
> +							MX6DL_PAD_SD4_CMD__UART3_TX_DATA 0x1b0b1
> +							MX6DL_PAD_EIM_D30__UART3_CTS_B   0x1b0b1
> +							MX6DL_PAD_EIM_EB3__UART3_RTS_B   0x1b0b1
> +						>;
> +					};
> +				};
> +
>  				uart4 {
>  					pinctrl_uart4_1: uart4grp-1 {
>  						fsl,pins = <
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index e0b7bad..1984ca4 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -277,6 +277,17 @@
>  					};
>  				};
>  
> +				uart3 {
> +					pinctrl_uart3_1: uart3grp-1 {
> +						fsl,pins = <
> +							MX6Q_PAD_SD4_CLK__UART3_RX_DATA 0x1b0b1
> +							MX6Q_PAD_SD4_CMD__UART3_TX_DATA 0x1b0b1
> +							MX6Q_PAD_EIM_D30__UART3_CTS_B   0x1b0b1
> +							MX6Q_PAD_EIM_EB3__UART3_RTS_B   0x1b0b1
> +						>;
> +					};
> +				};
> +
>  				uart4 {
>  					pinctrl_uart4_1: uart4grp-1 {
>  						fsl,pins = <
> -- 
> 1.7.1
> 
> 



From shawn.guo at linaro.org  Fri Jul 12 01:34:38 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Jul 2013 13:34:38 +0800
Subject: [PATCH v2 1/2] ARM: dts: imx6dl-wandboard: Add SDHC1 and SDHC2
 ports
In-Reply-To: <1373489419-20893-1-git-send-email-festevam@gmail.com>
References: <1373489419-20893-1-git-send-email-festevam@gmail.com>
Message-ID: <20130712053436.GB25501@S2101-09.ap.freescale.net>

On Wed, Jul 10, 2013 at 05:50:18PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Wandboard has a SD card slot on the baseboard connected to SDHC1 and a
> BCM4329 (Wifi + Bluetooth chip) connected to SDHC2.
> 
> Add support for these ports.
> 
> While at it, provide the card detect gpio on SDHC3.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Fabio,

I did some tweaking on pin groups definition in DTS, so that we do not
have too much maintenance burden to keep the groups aligned between
imx6q and imx6dl.  Can you please rebase your patch on the latest imx/dt
branch?  Also please separate soc changes and board changes into
different patches.

Shawn



From yadi.brar01 at gmail.com  Fri Jul 12 01:48:55 2013
From: yadi.brar01 at gmail.com (Yadwinder Singh Brar)
Date: Fri, 12 Jul 2013 11:18:55 +0530
Subject: [PATCH] clk: samsung: add set_rate and round_rate callbacks for
 pll45xx
In-Reply-To: <CAJuYYwSwNT=ymU72bY8x8PBk=BrVWzMrxGee3kaHOyk3cozv+g@mail.gmail.com>
References: <1373534869-12034-1-git-send-email-thomas.abraham@linaro.org>
 <1395018.H3ijo3R2Tj@thinkpad>
 <CAJuYYwSwNT=ymU72bY8x8PBk=BrVWzMrxGee3kaHOyk3cozv+g@mail.gmail.com>
Message-ID: <CAKew6eVBtbS1qaaauGOOTj831m-KHK7gyOSTcNQHzvw_vKiTgQ@mail.gmail.com>

Sorry I missed to state a point in earlier reply..,


>>> +#define PLL45XX_PMS(f, p, m, s)              \
>>> +     {                                       \
>>> +             .target_freq    = f,            \
>>> +             .pdiv           = p,            \
>>> +             .mdiv           = m,            \
>>> +             .sdiv           = s,            \
>>> +     }
>>> +
>>>  enum pll46xx_type {
>>>       pll_4600,
>>>       pll_4650,
>>
>> Basically, I would prefer the way introduced by Yadwinder's and Vikas' patches
>> to be used. We already discussed all the aspects during all the 7 versions of
>> those patches and decided to go with that solution, so for the case of
>> consistency, same should be used for remaining PLLs.
>
> Ok, but could we look at this once more. We could avoid duplication of
> PLL tables if the lookup tables are kept generic. It would be nice to
> get opinions from others as well on this.
>

The rationale behind using common enum type was to use common(generic) set
of clk ops where ever it is possible, to avoid duplication of most of
the code(which
looks mostly common with many PLLs).  For example its done for 35xx & 25xx
and 36xx & 26xx PLLs in that series.

Regards,
Yadwinder


From inki.dae at samsung.com  Fri Jul 12 02:12:44 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Fri, 12 Jul 2013 15:12:44 +0900
Subject: [RFC PATCH 0/2 v5] Introduce buffer synchronization framework
Message-ID: <1373609566-10784-1-git-send-email-inki.dae@samsung.com>

Hi all,

This patch set introduces a buffer synchronization framework based
on DMA BUF[1] and based on ww-mutexes[2] for lock mechanism.

The purpose of this framework is to provide not only buffer access
control to CPU and CPU, and CPU and DMA, and DMA and DMA but also
easy-to-use interfaces for device drivers and user application.
In addtion, this patch set suggests a way for enhancing performance.

For generic user mode interface, we have used fcntl system call[3].
As you know, user application sees a buffer object as a dma-buf file
descriptor. So fcntl() call with the file descriptor means to lock
some buffer region being managed by the dma-buf object.
For more detail, you can refer to the dma-buf-sync.txt in Documentation/

Moreover, we had tried to find how we could utilize limited hardware
resources more using buffer synchronization mechanism. And finally,
we have realized that it could enhance performance using multi threads
with this buffer synchronization mechanism: DMA and CPU works individually
so CPU could perform other works while DMA is performing some works,
and vise versa.

However, in the conventional way, that is not easy to do so because DMA
operation is depend on CPU operation, and vice versa.

Conventional way:
        User                                     Kernel
        ---------------------------------------------------------------------
        CPU writes something to src
        send the src to driver------------------------->
                                                 update DMA register
        request DMA start(1)--------------------------->
                                                 DMA start
                <---------completion signal(2)----------
        CPU accesses dst

        (1) Request DMA start after the CPU access to src buffer is completed.
        (2) Access dst buffer after DMA access to the dst buffer is completed.

On the other hand, if there is something to control buffer access between CPU
and DMA? The below shows that:

        User(thread a)          User(thread b)            Kernel
        ---------------------------------------------------------------------
        send a src to driver---------------------------------->
                                                          update DMA register
        lock the src
                                request DMA start(1)---------->
        CPU acccess to src
        unlock the src                                    lock src and dst
                                                          DMA start
                <-------------completion signal(2)-------------
        lock dst                                          DMA completion
        CPU access to dst                                 unlock src and dst
        unlock DST

        (1) Try to start DMA operation while CPU is accessing the src buffer.
        (2) Try CPU access to dst buffer while DMA is accessing the dst buffer.

	This means that CPU or DMA could do more works.

	In the same way, we could reduce hand shaking overhead between
	two processes when those processes need to share a shared buffer.
	There may be other cases that we could reduce overhead as well.


References:
[1] http://lwn.net/Articles/470339/
[2] https://patchwork.kernel.org/patch/2625361/
[3] http://linux.die.net/man/2/fcntl


Inki Dae (2):
  [RFC PATCH v5 1/2] dmabuf-sync: Introduce buffer synchronization framework
  [RFC PATCH v1 2/2] dma-buf: add lock callback for fcntl system call

 Documentation/dma-buf-sync.txt |  290 +++++++++++++++++
 drivers/base/Kconfig           |    7 +
 drivers/base/Makefile          |    1 +
 drivers/base/dma-buf.c         |   37 +++
 drivers/base/dmabuf-sync.c     |  674 ++++++++++++++++++++++++++++++++++++++++
 include/linux/dma-buf.h        |   16 +
 include/linux/dmabuf-sync.h    |  178 +++++++++++
 7 files changed, 1203 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sync.txt
 create mode 100644 drivers/base/dmabuf-sync.c
 create mode 100644 include/linux/dmabuf-sync.h

-- 
1.7.5.4



From inki.dae at samsung.com  Fri Jul 12 02:12:46 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Fri, 12 Jul 2013 15:12:46 +0900
Subject: [RFC PATCH v1 2/2] dma-buf: add lock callback for fcntl system call
In-Reply-To: <1373609566-10784-1-git-send-email-inki.dae@samsung.com>
References: <1373609566-10784-1-git-send-email-inki.dae@samsung.com>
Message-ID: <1373609566-10784-3-git-send-email-inki.dae@samsung.com>

This patch adds lock callback to dma buf file operations,
and this callback will be called by fcntl system call.

With this patch, fcntl system call can be used for buffer
synchronization between CPU and CPU, and CPU and DMA in user mode.

Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/base/dma-buf.c |   33 +++++++++++++++++++++++++++++++++
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 9a26981..e1b8583 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -80,9 +80,42 @@ static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
 	return dmabuf->ops->mmap(dmabuf, vma);
 }
 
+static int dma_buf_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+	struct dma_buf *dmabuf;
+	unsigned int type;
+	bool wait = false;
+
+	if (!is_dma_buf_file(file))
+		return -EINVAL;
+
+	dmabuf = file->private_data;
+
+	if ((fl->fl_type & F_UNLCK) == F_UNLCK) {
+		dmabuf_sync_single_unlock(dmabuf);
+		return 0;
+	}
+
+	/* convert flock type to dmabuf sync type. */
+	if ((fl->fl_type & F_WRLCK) == F_WRLCK)
+		type = DMA_BUF_ACCESS_W;
+	else if ((fl->fl_type & F_RDLCK) == F_RDLCK)
+		type = DMA_BUF_ACCESS_R;
+	else
+		return -EINVAL;
+
+	if (fl->fl_flags & FL_SLEEP)
+		wait = true;
+
+	/* TODO. the locking to certain region should also be considered. */
+
+	return dmabuf_sync_single_lock(dmabuf, type, wait);
+}
+
 static const struct file_operations dma_buf_fops = {
 	.release	= dma_buf_release,
 	.mmap		= dma_buf_mmap_internal,
+	.lock		= dma_buf_lock,
 };
 
 /*
-- 
1.7.5.4



From inki.dae at samsung.com  Fri Jul 12 02:12:45 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Fri, 12 Jul 2013 15:12:45 +0900
Subject: [RFC PATCH v5 1/2] dmabuf-sync: Introduce buffer synchronization
 framework
In-Reply-To: <1373609566-10784-1-git-send-email-inki.dae@samsung.com>
References: <1373609566-10784-1-git-send-email-inki.dae@samsung.com>
Message-ID: <1373609566-10784-2-git-send-email-inki.dae@samsung.com>

This patch adds a buffer synchronization framework based on DMA BUF[1]
and and based on ww-mutexes[2] for lock mechanism.

The purpose of this framework is to provide not only buffer access control
to CPU and DMA but also easy-to-use interfaces for device drivers and
user application. This framework can be used for all dma devices using
system memory as dma buffer, especially for most ARM based SoCs.

Changelog v5:
- Rmove a dependence on reservation_object: the reservation_object is used
  to hook up to ttm and dma-buf for easy sharing of reservations across
  devices. However, the dmabuf sync can be used for all dma devices; v4l2
  and drm based drivers, so doesn't need the reservation_object anymore.
  With regared to this, it adds 'void *sync' to dma_buf structure.
- All patches are rebased on mainline, Linux v3.10.

Changelog v4:
- Add user side interface for buffer synchronization mechanism and update
  descriptions related to the user side interface.

Changelog v3:
- remove cache operation relevant codes and update document file.

Changelog v2:
- use atomic_add_unless to avoid potential bug.
- add a macro for checking valid access type.
- code clean.

The mechanism of this framework has the following steps,
    1. Register dmabufs to a sync object - A task gets a new sync object and
    can add one or more dmabufs that the task wants to access.
    This registering should be performed when a device context or an event
    context such as a page flip event is created or before CPU accesses a shared
    buffer.

	dma_buf_sync_get(a sync object, a dmabuf);

    2. Lock a sync object - A task tries to lock all dmabufs added in its own
    sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead
    lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA
    and DMA. Taking a lock means that others cannot access all locked dmabufs
    until the task that locked the corresponding dmabufs, unlocks all the locked
    dmabufs.
    This locking should be performed before DMA or CPU accesses these dmabufs.

	dma_buf_sync_lock(a sync object);

    3. Unlock a sync object - The task unlocks all dmabufs added in its own sync
    object. The unlock means that the DMA or CPU accesses to the dmabufs have
    been completed so that others may access them.
    This unlocking should be performed after DMA or CPU has completed accesses
    to the dmabufs.

	dma_buf_sync_unlock(a sync object);

    4. Unregister one or all dmabufs from a sync object - A task unregisters
    the given dmabufs from the sync object. This means that the task dosen't
    want to lock the dmabufs.
    The unregistering should be performed after DMA or CPU has completed
    accesses to the dmabufs or when dma_buf_sync_lock() is failed.

	dma_buf_sync_put(a sync object, a dmabuf);
	dma_buf_sync_put_all(a sync object);

    The described steps may be summarized as:
	get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put

This framework includes the following two features.
    1. read (shared) and write (exclusive) locks - A task is required to declare
    the access type when the task tries to register a dmabuf;
    READ, WRITE, READ DMA, or WRITE DMA.

    The below is example codes,
	struct dmabuf_sync *sync;

	sync = dmabuf_sync_init(NULL, "test sync");

	dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R);
	...

	And the below can be used as access types:
		DMA_BUF_ACCESS_R - CPU will access a buffer for read.
		DMA_BUF_ACCESS_W - CPU will access a buffer for read or write.
		DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read
		DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or
					write.

    2. Mandatory resource releasing - a task cannot hold a lock indefinitely.
    A task may never try to unlock a buffer after taking a lock to the buffer.
    In this case, a timer handler to the corresponding sync object is called
    in five (default) seconds and then the timed-out buffer is unlocked by work
    queue handler to avoid lockups and to enforce resources of the buffer.

The below is how to use interfaces for device driver:
	1. Allocate and Initialize a sync object:
		struct dmabuf_sync *sync;

		sync = dmabuf_sync_init(NULL, "test sync");
		...

	2. Add a dmabuf to the sync object when setting up dma buffer relevant
	   registers:
		dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ);
		...

	3. Lock all dmabufs of the sync object before DMA or CPU accesses
	   the dmabufs:
		dmabuf_sync_lock(sync);
		...

	4. Now CPU or DMA can access all dmabufs locked in step 3.

	5. Unlock all dmabufs added in a sync object after DMA or CPU access
	   to these dmabufs is completed:
		dmabuf_sync_unlock(sync);

	   And call the following functions to release all resources,
		dmabuf_sync_put_all(sync);
		dmabuf_sync_fini(sync);

	You can refer to actual example codes:
		"drm/exynos: add dmabuf sync support for g2d driver" and
		"drm/exynos: add dmabuf sync support for kms framework" from
		https://git.kernel.org/cgit/linux/kernel/git/daeinki/
		drm-exynos.git/log/?h=dmabuf-sync

And this framework includes fcntl system call[3] as interfaces exported
to user. As you know, user sees a buffer object as a dma-buf file descriptor.
So fcntl() call with the file descriptor means to lock some buffer region being
managed by the dma-buf object.

The below is how to use interfaces for user application:
	struct flock filelock;

	1. Lock a dma buf:
		filelock.l_type = F_WRLCK or F_RDLCK;

		/* lock entire region to the dma buf. */
		filelock.lwhence = SEEK_CUR;
		filelock.l_start = 0;
		filelock.l_len = 0;

		fcntl(dmabuf fd, F_SETLKW or F_SETLK, &filelock);
		...
		CPU access to the dma buf

	2. Unlock a dma buf:
		filelock.l_type = F_UNLCK;

		fcntl(dmabuf fd, F_SETLKW or F_SETLK, &filelock);

		close(dmabuf fd) call would also unlock the dma buf. And for more
		detail, please refer to [3]

References:
[1] http://lwn.net/Articles/470339/
[2] https://patchwork.kernel.org/patch/2625361/
[3] http://linux.die.net/man/2/fcntl

Signed-off-by: Inki Dae <inki.dae at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 Documentation/dma-buf-sync.txt |  290 +++++++++++++++++
 drivers/base/Kconfig           |    7 +
 drivers/base/Makefile          |    1 +
 drivers/base/dma-buf.c         |    4 +
 drivers/base/dmabuf-sync.c     |  674 ++++++++++++++++++++++++++++++++++++++++
 include/linux/dma-buf.h        |   16 +
 include/linux/dmabuf-sync.h    |  178 +++++++++++
 7 files changed, 1170 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sync.txt
 create mode 100644 drivers/base/dmabuf-sync.c
 create mode 100644 include/linux/dmabuf-sync.h

diff --git a/Documentation/dma-buf-sync.txt b/Documentation/dma-buf-sync.txt
new file mode 100644
index 0000000..4427759
--- /dev/null
+++ b/Documentation/dma-buf-sync.txt
@@ -0,0 +1,290 @@
+                    DMA Buffer Synchronization Framework
+                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+                                  Inki Dae
+                      <inki dot dae at samsung dot com>
+                          <daeinki at gmail dot com>
+
+This document is a guide for device-driver writers describing the DMA buffer
+synchronization API. This document also describes how to use the API to
+use buffer synchronization mechanism between DMA and DMA, CPU and DMA, and
+CPU and CPU.
+
+The DMA Buffer synchronization API provides buffer synchronization mechanism;
+i.e., buffer access control to CPU and DMA, and easy-to-use interfaces for
+device drivers and user application. And this API can be used for all dma
+devices using system memory as dma buffer, especially for most ARM based SoCs.
+
+
+Motivation
+----------
+
+Buffer synchronization issue between DMA and DMA:
+	Sharing a buffer, a device cannot be aware of when the other device
+	will access the shared buffer: a device may access a buffer containing
+	wrong data if the device accesses the shared buffer while another
+	device is still accessing the shared buffer.
+	Therefore, a user process should have waited for the completion of DMA
+	access by another device before a device tries to access the shared
+	buffer.
+
+Buffer synchronization issue between CPU and DMA:
+	A user process should consider that when having to send a buffer, filled
+	by CPU, to a device driver for the device driver to access the buffer as
+	a input buffer while CPU and DMA are sharing the buffer.
+	This means that the user process needs to understand how the device
+	driver is worked. Hence, the conventional mechanism not only makes
+	user application complicated but also incurs performance overhead.
+
+Buffer synchronization issue between CPU and CPU:
+	In case that two processes share one buffer; shared with DMA also,
+	they may need some mechanism to allow process B to access the shared
+	buffer after the completion of CPU access by process A.
+	Therefore, process B should have waited for the completion of CPU access
+	by process A using the mechanism before trying to access the shared
+	buffer.
+
+What is the best way to solve these buffer synchronization issues?
+	We may need a common object that a device driver and a user process
+	notify the common object of when they try to access a shared buffer.
+	That way we could decide when we have to allow or not to allow for CPU
+	or DMA to access the shared buffer through the common object.
+	If so, what could become the common object? Right, that's a dma-buf[1].
+	Now we have already been using the dma-buf to share one buffer with
+	other drivers.
+
+How we can utilize multi threads for more performance?
+	DMA and CPU works individually. So CPU could perform other works while
+	DMA are performing some works, and vise versa.
+	However, in the conventional way, that is not easy to do so because
+	DMA operation is depend on CPU operation, and vice versa.
+
+	Conventional way:
+        User                                     Kernel
+        ---------------------------------------------------------------------
+        CPU writes something to src
+        send the src to driver------------------------->
+                                                 update DMA register
+        request DMA start(1)--------------------------->
+                                                 DMA start
+                <---------completion signal(2)----------
+        CPU accesses dst
+
+        (1) Request DMA start after the CPU access to src buffer is completed.
+        (2) Access dst buffer after DMA access to the dst buffer is completed.
+
+On the other hand, if there is something to control buffer access between CPU
+and DMA? The below shows that:
+
+        User(thread a)          User(thread b)            Kernel
+        ---------------------------------------------------------------------
+        send a src to driver---------------------------------->
+                                                          update DMA register
+        lock the src
+                                request DMA start(1)---------->
+        CPU acccess to src
+        unlock the src                                    lock src and dst
+                                                          DMA start
+                <-------------completion signal(2)-------------
+        lock dst                                          DMA completion
+        CPU access to dst                                 unlock src and dst
+        unlock DST
+
+        (1) Try to start DMA operation while CPU is accessing the src buffer.
+        (2) Try CPU access to dst buffer while DMA is accessing the dst buffer.
+
+	In the same way, we could reduce hand shaking overhead between
+	two processes when those processes need to share a shared buffer.
+	There may be other cases that we could reduce overhead as well.
+
+
+Basic concept
+-------------
+
+The mechanism of this framework has the following steps,
+    1. Register dmabufs to a sync object - A task gets a new sync object and
+    can add one or more dmabufs that the task wants to access.
+    This registering should be performed when a device context or an event
+    context such as a page flip event is created or before CPU accesses a shared
+    buffer.
+
+	dma_buf_sync_get(a sync object, a dmabuf);
+
+    2. Lock a sync object - A task tries to lock all dmabufs added in its own
+    sync object. Basically, the lock mechanism uses ww-mutexes[2] to avoid dead
+    lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA
+    and DMA. Taking a lock means that others cannot access all locked dmabufs
+    until the task that locked the corresponding dmabufs, unlocks all the locked
+    dmabufs.
+    This locking should be performed before DMA or CPU accesses these dmabufs.
+
+	dma_buf_sync_lock(a sync object);
+
+    3. Unlock a sync object - The task unlocks all dmabufs added in its own sync
+    object. The unlock means that the DMA or CPU accesses to the dmabufs have
+    been completed so that others may access them.
+    This unlocking should be performed after DMA or CPU has completed accesses
+    to the dmabufs.
+
+	dma_buf_sync_unlock(a sync object);
+
+    4. Unregister one or all dmabufs from a sync object - A task unregisters
+    the given dmabufs from the sync object. This means that the task dosen't
+    want to lock the dmabufs.
+    The unregistering should be performed after DMA or CPU has completed
+    accesses to the dmabufs or when dma_buf_sync_lock() is failed.
+
+	dma_buf_sync_put(a sync object, a dmabuf);
+	dma_buf_sync_put_all(a sync object);
+
+    The described steps may be summarized as:
+	get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put
+
+This framework includes the following two features.
+    1. read (shared) and write (exclusive) locks - A task is required to declare
+    the access type when the task tries to register a dmabuf;
+    READ, WRITE, READ DMA, or WRITE DMA.
+
+    The below is example codes,
+	struct dmabuf_sync *sync;
+
+	sync = dmabuf_sync_init(NULL, "test sync");
+
+	dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R);
+	...
+
+    2. Mandatory resource releasing - a task cannot hold a lock indefinitely.
+    A task may never try to unlock a buffer after taking a lock to the buffer.
+    In this case, a timer handler to the corresponding sync object is called
+    in five (default) seconds and then the timed-out buffer is unlocked by work
+    queue handler to avoid lockups and to enforce resources of the buffer.
+
+
+Access types
+------------
+
+DMA_BUF_ACCESS_R - CPU will access a buffer for read.
+DMA_BUF_ACCESS_W - CPU will access a buffer for read or write.
+DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read
+DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or write.
+
+
+Generic user interfaces
+-----------------------
+
+And this framework includes fcntl system call[3] as interfaces exported
+to user. As you know, user sees a buffer object as a dma-buf file descriptor.
+So fcntl() call with the file descriptor means to lock some buffer region being
+managed by the dma-buf object.
+
+
+API set
+-------
+
+bool is_dmabuf_sync_supported(void)
+	- Check if dmabuf sync is supported or not.
+
+struct dmabuf_sync *dmabuf_sync_init(void *priv, const char *name)
+	- Allocate and initialize a new sync object. The caller can get a new
+	sync object for buffer synchronization. priv is used to set caller's
+	private data and name is the name of sync object.
+
+void dmabuf_sync_fini(struct dmabuf_sync *sync)
+	- Release all resources to the sync object.
+
+int dmabuf_sync_get(struct dmabuf_sync *sync, void *sync_buf,
+			unsigned int type)
+	- Get dmabuf sync object. Internally, this function allocates
+	a dmabuf_sync object and adds a given dmabuf to it, and also takes
+	a reference to the dmabuf. The caller can tie up multiple dmabufs
+	into one sync object by calling this function several times.
+
+void dmabuf_sync_put(struct dmabuf_sync *sync, struct dma_buf *dmabuf)
+	- Put dmabuf sync object to a given dmabuf. Internally, this function
+	removes a given dmabuf from a sync object and remove the sync object.
+	At this time, the dmabuf is putted.
+
+void dmabuf_sync_put_all(struct dmabuf_sync *sync)
+	- Put dmabuf sync object to dmabufs. Internally, this function removes
+	all dmabufs from a sync object and remove the sync object.
+	At this time, all dmabufs are putted.
+
+int dmabuf_sync_lock(struct dmabuf_sync *sync)
+	- Lock all dmabufs added in a sync object. The caller should call this
+	function prior to CPU or DMA access to the dmabufs so that others can
+	not access the dmabufs. Internally, this function avoids dead lock
+	issue with ww-mutexes.
+
+int dmabuf_sync_single_lock(struct dma_buf *dmabuf)
+	- Lock a dmabuf. The caller should call this
+	function prior to CPU or DMA access to the dmabuf so that others can
+	not access the dmabuf.
+
+int dmabuf_sync_unlock(struct dmabuf_sync *sync)
+	- Unlock all dmabufs added in a sync object. The caller should call
+	this function after CPU or DMA access to the dmabufs is completed so
+	that others can access the dmabufs.
+
+void dmabuf_sync_single_unlock(struct dma_buf *dmabuf)
+	- Unlock a dmabuf. The caller should call this function after CPU or
+	DMA access to the dmabuf is completed so that others can access
+	the dmabuf.
+
+
+Tutorial for device driver
+--------------------------
+
+1. Allocate and Initialize a sync object:
+	struct dmabuf_sync *sync;
+
+	sync = dmabuf_sync_init(NULL, "test sync");
+	...
+
+2. Add a dmabuf to the sync object when setting up dma buffer relevant registers:
+	dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ);
+	...
+
+3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs:
+	dmabuf_sync_lock(sync);
+	...
+
+4. Now CPU or DMA can access all dmabufs locked in step 3.
+
+5. Unlock all dmabufs added in a sync object after DMA or CPU access to these
+   dmabufs is completed:
+	dmabuf_sync_unlock(sync);
+
+   And call the following functions to release all resources,
+	dmabuf_sync_put_all(sync);
+	dmabuf_sync_fini(sync);
+
+
+Tutorial for user application
+-----------------------------
+	struct flock filelock;
+
+1. Lock a dma buf:
+	filelock.l_type = F_WRLCK or F_RDLCK;
+
+	/* lock entire region to the dma buf. */
+	filelock.lwhence = SEEK_CUR;
+	filelock.l_start = 0;
+	filelock.l_len = 0;
+
+	fcntl(dmabuf fd, F_SETLKW or F_SETLK, &filelock);
+	...
+	CPU access to the dma buf
+
+2. Unlock a dma buf:
+	filelock.l_type = F_UNLCK;
+
+	fcntl(dmabuf fd, F_SETLKW or F_SETLK, &filelock);
+
+	close(dmabuf fd) call would also unlock the dma buf. And for more
+	detail, please refer to [3]
+
+
+References:
+[1] http://lwn.net/Articles/470339/
+[2] https://patchwork.kernel.org/patch/2625361/
+[3] http://linux.die.net/man/2/fcntl
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 5daa259..35e1518 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -200,6 +200,13 @@ config DMA_SHARED_BUFFER
 	  APIs extension; the file's descriptor can then be passed on to other
 	  driver.
 
+config DMABUF_SYNC
+	bool "DMABUF Synchronization Framework"
+	depends on DMA_SHARED_BUFFER
+	help
+	  This option enables dmabuf sync framework for buffer synchronization between
+	  DMA and DMA, CPU and DMA, and CPU and CPU.
+
 config CMA
 	bool "Contiguous Memory Allocator"
 	depends on HAVE_DMA_CONTIGUOUS && HAVE_MEMBLOCK
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 48029aa..e06a5d7 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -11,6 +11,7 @@ obj-y			+= power/
 obj-$(CONFIG_HAS_DMA)	+= dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
 obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o reservation.o
+obj-$(CONFIG_DMABUF_SYNC) += dmabuf-sync.o
 obj-$(CONFIG_ISA)	+= isa.o
 obj-$(CONFIG_FW_LOADER)	+= firmware_class.o
 obj-$(CONFIG_NUMA)	+= node.o
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 08fe897..9a26981 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -29,6 +29,7 @@
 #include <linux/export.h>
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
+#include <linux/dmabuf-sync.h>
 
 static inline int is_dma_buf_file(struct file *);
 
@@ -56,6 +57,8 @@ static int dma_buf_release(struct inode *inode, struct file *file)
 	list_del(&dmabuf->list_node);
 	mutex_unlock(&db_list.lock);
 
+	dmabuf_sync_reservation_fini(dmabuf);
+
 	kfree(dmabuf);
 	return 0;
 }
@@ -134,6 +137,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
 
 	file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
 
+	dmabuf_sync_reservation_init(dmabuf);
 	dmabuf->file = file;
 
 	mutex_init(&dmabuf->lock);
diff --git a/drivers/base/dmabuf-sync.c b/drivers/base/dmabuf-sync.c
new file mode 100644
index 0000000..0b83111
--- /dev/null
+++ b/drivers/base/dmabuf-sync.c
@@ -0,0 +1,674 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics Co.Ltd
+ * Authors:
+ *	Inki Dae <inki.dae at samsung.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/debugfs.h>
+#include <linux/uaccess.h>
+
+#include <linux/dmabuf-sync.h>
+
+#define MAX_SYNC_TIMEOUT	5 /* Second. */
+
+int dmabuf_sync_enabled = 1;
+
+MODULE_PARM_DESC(enabled, "Check if dmabuf sync is supported or not");
+module_param_named(enabled, dmabuf_sync_enabled, int, 0444);
+
+DEFINE_WW_CLASS(dmabuf_sync_ww_class);
+EXPORT_SYMBOL(dmabuf_sync_ww_class);
+
+static void dmabuf_sync_timeout_worker(struct work_struct *work)
+{
+	struct dmabuf_sync *sync = container_of(work, struct dmabuf_sync, work);
+	struct dmabuf_sync_object *sobj;
+
+	mutex_lock(&sync->lock);
+
+	list_for_each_entry(sobj, &sync->syncs, head) {
+		if (WARN_ON(!sobj->robj))
+			continue;
+
+		mutex_lock(&sobj->robj->lock);
+
+		printk(KERN_WARNING "%s: timeout = 0x%x [type = %d, " \
+					"refcnt = %d, locked = %d]\n",
+					sync->name, (u32)sobj->dmabuf,
+					sobj->access_type,
+					atomic_read(&sobj->robj->shared_cnt),
+					sobj->robj->locked);
+
+		/* unlock only valid sync object. */
+		if (!sobj->robj->locked) {
+			mutex_unlock(&sobj->robj->lock);
+			continue;
+		}
+
+		if (sobj->robj->shared &&
+		    atomic_add_unless(&sobj->robj->shared_cnt, -1, 1)) {
+			mutex_unlock(&sobj->robj->lock);
+			continue;
+		}
+
+		mutex_unlock(&sobj->robj->lock);
+
+		ww_mutex_unlock(&sobj->robj->sync_lock);
+
+		mutex_lock(&sobj->robj->lock);
+
+		if (sobj->access_type & DMA_BUF_ACCESS_R)
+			printk(KERN_WARNING "%s: r-unlocked = 0x%x\n",
+					sync->name, (u32)sobj->dmabuf);
+		else
+			printk(KERN_WARNING "%s: w-unlocked = 0x%x\n",
+					sync->name, (u32)sobj->dmabuf);
+
+		mutex_unlock(&sobj->robj->lock);
+	}
+
+	sync->status = 0;
+	mutex_unlock(&sync->lock);
+
+	dmabuf_sync_put_all(sync);
+	dmabuf_sync_fini(sync);
+}
+
+static void dmabuf_sync_lock_timeout(unsigned long arg)
+{
+	struct dmabuf_sync *sync = (struct dmabuf_sync *)arg;
+
+	schedule_work(&sync->work);
+}
+
+static int dmabuf_sync_lock_objs(struct dmabuf_sync *sync,
+					struct ww_acquire_ctx *ctx)
+{
+	struct dmabuf_sync_object *contended_sobj = NULL;
+	struct dmabuf_sync_object *res_sobj = NULL;
+	struct dmabuf_sync_object *sobj = NULL;
+	int ret;
+
+	if (ctx)
+		ww_acquire_init(ctx, &dmabuf_sync_ww_class);
+
+retry:
+	list_for_each_entry(sobj, &sync->syncs, head) {
+		if (WARN_ON(!sobj->robj))
+			continue;
+
+		mutex_lock(&sobj->robj->lock);
+
+		/* Don't lock in case of read and read. */
+		if (sobj->robj->accessed_type & DMA_BUF_ACCESS_R &&
+		    sobj->access_type & DMA_BUF_ACCESS_R) {
+			atomic_inc(&sobj->robj->shared_cnt);
+			sobj->robj->shared = true;
+			mutex_unlock(&sobj->robj->lock);
+			continue;
+		}
+
+		if (sobj == res_sobj) {
+			res_sobj = NULL;
+			mutex_unlock(&sobj->robj->lock);
+			continue;
+		}
+
+		mutex_unlock(&sobj->robj->lock);
+
+		ret = ww_mutex_lock(&sobj->robj->sync_lock, ctx);
+		if (ret < 0) {
+			contended_sobj = sobj;
+
+			if (ret == -EDEADLK)
+				printk(KERN_WARNING"%s: deadlock = 0x%x\n",
+					sync->name, (u32)sobj->dmabuf);
+			goto err;
+		}
+
+		mutex_lock(&sobj->robj->lock);
+		sobj->robj->locked = true;
+
+		mutex_unlock(&sobj->robj->lock);
+	}
+
+	if (ctx)
+		ww_acquire_done(ctx);
+
+	init_timer(&sync->timer);
+
+	sync->timer.data = (unsigned long)sync;
+	sync->timer.function = dmabuf_sync_lock_timeout;
+	sync->timer.expires = jiffies + (HZ * MAX_SYNC_TIMEOUT);
+
+	add_timer(&sync->timer);
+
+	return 0;
+
+err:
+	list_for_each_entry_continue_reverse(sobj, &sync->syncs, head) {
+		mutex_lock(&sobj->robj->lock);
+
+		/* Don't need to unlock in case of read and read. */
+		if (atomic_add_unless(&sobj->robj->shared_cnt, -1, 1)) {
+			mutex_unlock(&sobj->robj->lock);
+			continue;
+		}
+
+		ww_mutex_unlock(&sobj->robj->sync_lock);
+		sobj->robj->locked = false;
+
+		mutex_unlock(&sobj->robj->lock);
+	}
+
+	if (res_sobj) {
+		mutex_lock(&res_sobj->robj->lock);
+
+		if (!atomic_add_unless(&res_sobj->robj->shared_cnt, -1, 1)) {
+			ww_mutex_unlock(&res_sobj->robj->sync_lock);
+			res_sobj->robj->locked = false;
+		}
+
+		mutex_unlock(&res_sobj->robj->lock);
+	}
+
+	if (ret == -EDEADLK) {
+		ww_mutex_lock_slow(&contended_sobj->robj->sync_lock, ctx);
+		res_sobj = contended_sobj;
+
+		goto retry;
+	}
+
+	if (ctx)
+		ww_acquire_fini(ctx);
+
+	return ret;
+}
+
+static void dmabuf_sync_unlock_objs(struct dmabuf_sync *sync,
+					struct ww_acquire_ctx *ctx)
+{
+	struct dmabuf_sync_object *sobj;
+
+	if (list_empty(&sync->syncs))
+		return;
+
+	mutex_lock(&sync->lock);
+
+	list_for_each_entry(sobj, &sync->syncs, head) {
+		mutex_lock(&sobj->robj->lock);
+
+		if (sobj->robj->shared) {
+			if (atomic_add_unless(&sobj->robj->shared_cnt, -1,
+						1)) {
+				mutex_unlock(&sobj->robj->lock);
+				continue;
+			}
+
+			mutex_unlock(&sobj->robj->lock);
+
+			ww_mutex_unlock(&sobj->robj->sync_lock);
+
+			mutex_lock(&sobj->robj->lock);
+			sobj->robj->shared = false;
+			sobj->robj->locked = false;
+		} else {
+			mutex_unlock(&sobj->robj->lock);
+
+			ww_mutex_unlock(&sobj->robj->sync_lock);
+
+			mutex_lock(&sobj->robj->lock);
+			sobj->robj->locked = false;
+		}
+
+		mutex_unlock(&sobj->robj->lock);
+	}
+
+	mutex_unlock(&sync->lock);
+
+	if (ctx)
+		ww_acquire_fini(ctx);
+
+	del_timer(&sync->timer);
+}
+
+/**
+ * is_dmabuf_sync_supported - Check if dmabuf sync is supported or not.
+ */
+bool is_dmabuf_sync_supported(void)
+{
+	return dmabuf_sync_enabled == 1;
+}
+EXPORT_SYMBOL(is_dmabuf_sync_supported);
+
+/**
+ * dmabuf_sync_init - Allocate and initialize a dmabuf sync.
+ *
+ * @priv: A device private data.
+ * @name: A sync object name.
+ *
+ * This function should be called when a device context or an event
+ * context such as a page flip event is created. And the created
+ * dmabuf_sync object should be set to the context.
+ * The caller can get a new sync object for buffer synchronization
+ * through this function.
+ */
+struct dmabuf_sync *dmabuf_sync_init(void *priv, const char *name)
+{
+	struct dmabuf_sync *sync;
+
+	sync = kzalloc(sizeof(*sync), GFP_KERNEL);
+	if (!sync)
+		return ERR_PTR(-ENOMEM);
+
+	strncpy(sync->name, name, ARRAY_SIZE(sync->name) - 1);
+
+	sync->priv = priv;
+	INIT_LIST_HEAD(&sync->syncs);
+	mutex_init(&sync->lock);
+	INIT_WORK(&sync->work, dmabuf_sync_timeout_worker);
+
+	return sync;
+}
+EXPORT_SYMBOL(dmabuf_sync_init);
+
+/**
+ * dmabuf_sync_fini - Release a given dmabuf sync.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ *
+ * This function should be called if some operation is failed after
+ * dmabuf_sync_init call to release relevant resources, and after
+ * dmabuf_sync_unlock function is called.
+ */
+void dmabuf_sync_fini(struct dmabuf_sync *sync)
+{
+	if (WARN_ON(!sync))
+		return;
+
+	kfree(sync);
+}
+EXPORT_SYMBOL(dmabuf_sync_fini);
+
+/*
+ * dmabuf_sync_get_obj - Add a given object to syncs list.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ * @dmabuf: An object to dma_buf structure.
+ * @type: A access type to a dma buf.
+ *	The DMA_BUF_ACCESS_R means that this dmabuf could be accessed by
+ *	others for read access. On the other hand, the DMA_BUF_ACCESS_W
+ *	means that this dmabuf couldn't be accessed by others but would be
+ *	accessed by caller's dma exclusively. And the DMA_BUF_ACCESS_DMA can be
+ *	combined.
+ *
+ * This function creates and initializes a new dmabuf sync object and it adds
+ * the dmabuf sync object to syncs list to track and manage all dmabufs.
+ */
+static int dmabuf_sync_get_obj(struct dmabuf_sync *sync, struct dma_buf *dmabuf,
+					unsigned int type)
+{
+	struct dmabuf_sync_object *sobj;
+
+	if (!dmabuf->sync) {
+		WARN_ON(1);
+		return -EFAULT;
+	}
+
+	if (!IS_VALID_DMA_BUF_ACCESS_TYPE(type))
+		return -EINVAL;
+
+	if ((type & DMA_BUF_ACCESS_RW) == DMA_BUF_ACCESS_RW)
+		type &= ~DMA_BUF_ACCESS_R;
+
+	sobj = kzalloc(sizeof(*sobj), GFP_KERNEL);
+	if (!sobj) {
+		WARN_ON(1);
+		return -ENOMEM;
+	}
+
+	sobj->dmabuf = dmabuf;
+	sobj->robj = dmabuf->sync;
+
+	mutex_lock(&sync->lock);
+	list_add_tail(&sobj->head, &sync->syncs);
+	mutex_unlock(&sync->lock);
+
+	get_dma_buf(dmabuf);
+
+	mutex_lock(&sobj->robj->lock);
+	sobj->access_type = type;
+	mutex_unlock(&sobj->robj->lock);
+
+	return 0;
+}
+
+/*
+ * dmabuf_sync_put_obj - Release a given sync object.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ *
+ * This function should be called if some operation is failed after
+ * dmabuf_sync_get_obj call to release a given sync object.
+ */
+static void dmabuf_sync_put_obj(struct dmabuf_sync *sync,
+					struct dma_buf *dmabuf)
+{
+	struct dmabuf_sync_object *sobj;
+
+	mutex_lock(&sync->lock);
+
+	list_for_each_entry(sobj, &sync->syncs, head) {
+		if (sobj->dmabuf != dmabuf)
+			continue;
+
+		dma_buf_put(sobj->dmabuf);
+
+		list_del_init(&sobj->head);
+		kfree(sobj);
+		break;
+	}
+
+	if (list_empty(&sync->syncs))
+		sync->status = 0;
+
+	mutex_unlock(&sync->lock);
+}
+
+/*
+ * dmabuf_sync_put_objs - Release all sync objects of dmabuf_sync.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ *
+ * This function should be called if some operation is failed after
+ * dmabuf_sync_get_obj call to release all sync objects.
+ */
+static void dmabuf_sync_put_objs(struct dmabuf_sync *sync)
+{
+	struct dmabuf_sync_object *sobj, *next;
+
+	mutex_lock(&sync->lock);
+
+	list_for_each_entry_safe(sobj, next, &sync->syncs, head) {
+		dma_buf_put(sobj->dmabuf);
+
+		list_del_init(&sobj->head);
+		kfree(sobj);
+	}
+
+	mutex_unlock(&sync->lock);
+
+	sync->status = 0;
+}
+
+/**
+ * dmabuf_sync_lock - lock all dmabufs added to syncs list.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ *
+ * The caller should call this function prior to CPU or DMA access to
+ * the dmabufs so that others can not access the dmabufs.
+ * Internally, this function avoids dead lock issue with ww-mutex.
+ */
+int dmabuf_sync_lock(struct dmabuf_sync *sync)
+{
+	int ret;
+
+	if (!sync) {
+		WARN_ON(1);
+		return -EFAULT;
+	}
+
+	if (list_empty(&sync->syncs))
+		return -EINVAL;
+
+	if (sync->status != DMABUF_SYNC_GOT)
+		return -EINVAL;
+
+	ret = dmabuf_sync_lock_objs(sync, &sync->ctx);
+	if (ret < 0) {
+		WARN_ON(1);
+		return ret;
+	}
+
+	sync->status = DMABUF_SYNC_LOCKED;
+
+	return ret;
+}
+EXPORT_SYMBOL(dmabuf_sync_lock);
+
+/**
+ * dmabuf_sync_unlock - unlock all objects added to syncs list.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ *
+ * The caller should call this function after CPU or DMA access to
+ * the dmabufs is completed so that others can access the dmabufs.
+ */
+int dmabuf_sync_unlock(struct dmabuf_sync *sync)
+{
+	if (!sync) {
+		WARN_ON(1);
+		return -EFAULT;
+	}
+
+	/* If current dmabuf sync object wasn't reserved then just return. */
+	if (sync->status != DMABUF_SYNC_LOCKED)
+		return -EAGAIN;
+
+	dmabuf_sync_unlock_objs(sync, &sync->ctx);
+
+	return 0;
+}
+EXPORT_SYMBOL(dmabuf_sync_unlock);
+
+/**
+ * dmabuf_sync_single_lock - lock a dma buf.
+ *
+ * @dmabuf: A dma buf object that tries to lock.
+ * @type: A access type to a dma buf.
+ *	The DMA_BUF_ACCESS_R means that this dmabuf could be accessed by
+ *	others for read access. On the other hand, the DMA_BUF_ACCESS_W
+ *	means that this dmabuf couldn't be accessed by others but would be
+ *	accessed by caller's dma exclusively. And the DMA_BUF_ACCESS_DMA can
+ *	be combined with other.
+ * @wait: Indicate whether caller is blocked or not.
+ *	true means that caller will be blocked, and false means that this
+ *	function will return -EAGAIN if this caller can't take the lock
+ *	right now.
+ *
+ * The caller should call this function prior to CPU or DMA access to the dmabuf
+ * so that others cannot access the dmabuf.
+ */
+int dmabuf_sync_single_lock(struct dma_buf *dmabuf, unsigned int type,
+				bool wait)
+{
+	struct dmabuf_sync_reservation *robj;
+
+	if (!dmabuf->sync) {
+		WARN_ON(1);
+		return -EFAULT;
+	}
+
+	if (!IS_VALID_DMA_BUF_ACCESS_TYPE(type)) {
+		WARN_ON(1);
+		return -EINVAL;
+	}
+
+	get_dma_buf(dmabuf);
+	robj = dmabuf->sync;
+
+	mutex_lock(&robj->lock);
+
+	/* Don't lock in case of read and read. */
+	if (robj->accessed_type & DMA_BUF_ACCESS_R && type & DMA_BUF_ACCESS_R) {
+		atomic_inc(&robj->shared_cnt);
+		robj->shared = true;
+		mutex_unlock(&robj->lock);
+		return 0;
+	}
+
+	/*
+	 * In case of F_SETLK, just return -EAGAIN if this dmabuf has already
+	 * been locked.
+	 */
+	if (!wait && robj->locked) {
+		mutex_unlock(&robj->lock);
+		dma_buf_put(dmabuf);
+		return -EAGAIN;
+	}
+
+	mutex_unlock(&robj->lock);
+
+	mutex_lock(&robj->sync_lock.base);
+
+	mutex_lock(&robj->lock);
+	robj->locked = true;
+	mutex_unlock(&robj->lock);
+
+	return 0;
+}
+EXPORT_SYMBOL(dmabuf_sync_single_lock);
+
+/**
+ * dmabuf_sync_single_unlock - unlock a dma buf.
+ *
+ * @dmabuf: A dma buf object that tries to unlock.
+ *
+ * The caller should call this function after CPU or DMA access to
+ * the dmabuf is completed so that others can access the dmabuf.
+ */
+void dmabuf_sync_single_unlock(struct dma_buf *dmabuf)
+{
+	struct dmabuf_sync_reservation *robj;
+
+	if (!dmabuf->sync) {
+		WARN_ON(1);
+		return;
+	}
+
+	robj = dmabuf->sync;
+
+	mutex_lock(&robj->lock);
+
+	if (robj->shared) {
+		if (atomic_add_unless(&robj->shared_cnt, -1 , 1)) {
+			mutex_unlock(&robj->lock);
+			return;
+		}
+
+		robj->shared = false;
+	}
+
+	mutex_unlock(&robj->lock);
+
+	mutex_unlock(&robj->sync_lock.base);
+
+	mutex_lock(&robj->lock);
+	robj->locked = false;
+	mutex_unlock(&robj->lock);
+
+	dma_buf_put(dmabuf);
+
+	return;
+}
+EXPORT_SYMBOL(dmabuf_sync_single_unlock);
+
+/**
+ * dmabuf_sync_get - Get dmabuf sync object.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ * @sync_buf: A dmabuf object to be synchronized with others.
+ * @type: A access type to a dma buf.
+ *	The DMA_BUF_ACCESS_R means that this dmabuf could be accessed by
+ *	others for read access. On the other hand, the DMA_BUF_ACCESS_W
+ *	means that this dmabuf couldn't be accessed by others but would be
+ *	accessed by caller's dma exclusively. And the DMA_BUF_ACCESS_DMA can
+ *	be combined with other.
+ *
+ * This function should be called after dmabuf_sync_init function is called.
+ * The caller can tie up multiple dmabufs into one sync object by calling this
+ * function several times. Internally, this function allocates
+ * a dmabuf_sync_object and adds a given dmabuf to it, and also takes
+ * a reference to a dmabuf.
+ */
+int dmabuf_sync_get(struct dmabuf_sync *sync, void *sync_buf, unsigned int type)
+{
+	int ret;
+
+	if (!sync || !sync_buf) {
+		WARN_ON(1);
+		return -EFAULT;
+	}
+
+	ret = dmabuf_sync_get_obj(sync, sync_buf, type);
+	if (ret < 0) {
+		WARN_ON(1);
+		return ret;
+	}
+
+	sync->status = DMABUF_SYNC_GOT;
+
+	return 0;
+}
+EXPORT_SYMBOL(dmabuf_sync_get);
+
+/**
+ * dmabuf_sync_put - Put dmabuf sync object to a given dmabuf.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ * @dmabuf: An dmabuf object.
+ *
+ * This function should be called if some operation is failed after
+ * dmabuf_sync_get function is called to release the dmabuf, or
+ * dmabuf_sync_unlock function is called. Internally, this function
+ * removes a given dmabuf from a sync object and remove the sync object.
+ * At this time, the dmabuf is putted.
+ */
+void dmabuf_sync_put(struct dmabuf_sync *sync, struct dma_buf *dmabuf)
+{
+	if (!sync || !dmabuf) {
+		WARN_ON(1);
+		return;
+	}
+
+	if (list_empty(&sync->syncs))
+		return;
+
+	dmabuf_sync_put_obj(sync, dmabuf);
+}
+EXPORT_SYMBOL(dmabuf_sync_put);
+
+/**
+ * dmabuf_sync_put_all - Put dmabuf sync object to dmabufs.
+ *
+ * @sync: An object to dmabuf_sync structure.
+ *
+ * This function should be called if some operation is failed after
+ * dmabuf_sync_get function is called to release all sync objects, or
+ * dmabuf_sync_unlock function is called. Internally, this function
+ * removes dmabufs from a sync object and remove the sync object.
+ * At this time, all dmabufs are putted.
+ */
+void dmabuf_sync_put_all(struct dmabuf_sync *sync)
+{
+	if (!sync) {
+		WARN_ON(1);
+		return;
+	}
+
+	if (list_empty(&sync->syncs))
+		return;
+
+	dmabuf_sync_put_objs(sync);
+}
+EXPORT_SYMBOL(dmabuf_sync_put_all);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index dfac5ed..0109673 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -115,6 +115,7 @@ struct dma_buf_ops {
  * @exp_name: name of the exporter; useful for debugging.
  * @list_node: node for dma_buf accounting and debugging.
  * @priv: exporter specific private data for this buffer object.
+ * @sync: sync object linked to this dma-buf
  */
 struct dma_buf {
 	size_t size;
@@ -128,6 +129,7 @@ struct dma_buf {
 	const char *exp_name;
 	struct list_head list_node;
 	void *priv;
+	void *sync;
 };
 
 /**
@@ -148,6 +150,20 @@ struct dma_buf_attachment {
 	void *priv;
 };
 
+#define	DMA_BUF_ACCESS_R	0x1
+#define DMA_BUF_ACCESS_W	0x2
+#define DMA_BUF_ACCESS_DMA	0x4
+#define DMA_BUF_ACCESS_RW	(DMA_BUF_ACCESS_R | DMA_BUF_ACCESS_W)
+#define DMA_BUF_ACCESS_DMA_R	(DMA_BUF_ACCESS_R | DMA_BUF_ACCESS_DMA)
+#define DMA_BUF_ACCESS_DMA_W	(DMA_BUF_ACCESS_W | DMA_BUF_ACCESS_DMA)
+#define DMA_BUF_ACCESS_DMA_RW	(DMA_BUF_ACCESS_DMA_R | DMA_BUF_ACCESS_DMA_W)
+#define IS_VALID_DMA_BUF_ACCESS_TYPE(t)	(t == DMA_BUF_ACCESS_R || \
+					 t == DMA_BUF_ACCESS_W || \
+					 t == DMA_BUF_ACCESS_DMA_R || \
+					 t == DMA_BUF_ACCESS_DMA_W || \
+					 t == DMA_BUF_ACCESS_RW || \
+					 t == DMA_BUF_ACCESS_DMA_RW)
+
 /**
  * get_dma_buf - convenience wrapper for get_file.
  * @dmabuf:	[in]	pointer to dma_buf
diff --git a/include/linux/dmabuf-sync.h b/include/linux/dmabuf-sync.h
new file mode 100644
index 0000000..2502ad6
--- /dev/null
+++ b/include/linux/dmabuf-sync.h
@@ -0,0 +1,178 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics Co.Ltd
+ * Authors:
+ *	Inki Dae <inki.dae at samsung.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include <linux/mutex.h>
+#include <linux/sched.h>
+#include <linux/dma-buf.h>
+
+enum dmabuf_sync_status {
+	DMABUF_SYNC_GOT		= 1,
+	DMABUF_SYNC_LOCKED,
+};
+
+struct dmabuf_sync_reservation {
+	struct ww_mutex		sync_lock;
+	struct mutex		lock;
+	atomic_t		shared_cnt;
+	unsigned int		accessed_type;
+	unsigned int		shared;
+	unsigned int		locked;
+};
+
+/*
+ * A structure for dmabuf_sync_object.
+ *
+ * @head: A list head to be added to syncs list.
+ * @robj: A reservation_object object.
+ * @dma_buf: A dma_buf object.
+ * @access_type: Indicate how a current task tries to access
+ *	a given buffer.
+ */
+struct dmabuf_sync_object {
+	struct list_head		head;
+	struct dmabuf_sync_reservation	*robj;
+	struct dma_buf			*dmabuf;
+	unsigned int			access_type;
+};
+
+/*
+ * A structure for dmabuf_sync.
+ *
+ * @syncs: A list head to sync object and this is global to system.
+ * @list: A list entry used as committed list node
+ * @lock: A mutex lock to current sync object.
+ * @ctx: A current context for ww mutex.
+ * @work: A work struct to release resources at timeout.
+ * @priv: A private data.
+ * @name: A string to dmabuf sync owner.
+ * @timer: A timer list to avoid lockup and release resources.
+ * @status: Indicate current status (DMABUF_SYNC_GOT or DMABUF_SYNC_LOCKED).
+ */
+struct dmabuf_sync {
+	struct list_head	syncs;
+	struct list_head	list;
+	struct mutex		lock;
+	struct ww_acquire_ctx	ctx;
+	struct work_struct	work;
+	void			*priv;
+	char			name[64];
+	struct timer_list	timer;
+	unsigned int		status;
+};
+
+#ifdef CONFIG_DMABUF_SYNC
+
+extern struct ww_class dmabuf_sync_ww_class;
+
+static inline void dmabuf_sync_reservation_init(struct dma_buf *dmabuf)
+{
+	struct dmabuf_sync_reservation *obj;
+
+	obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+	if (!obj)
+		return;
+
+	dmabuf->sync = obj;
+
+	ww_mutex_init(&obj->sync_lock, &dmabuf_sync_ww_class);
+
+	mutex_init(&obj->lock);
+	atomic_set(&obj->shared_cnt, 1);
+}
+
+static inline void dmabuf_sync_reservation_fini(struct dma_buf *dmabuf)
+{
+	struct dmabuf_sync_reservation *obj;
+
+	if (!dmabuf->sync)
+		return;
+
+	obj = dmabuf->sync;
+
+	ww_mutex_destroy(&obj->sync_lock);
+
+	kfree(obj);
+}
+
+extern bool is_dmabuf_sync_supported(void);
+
+extern struct dmabuf_sync *dmabuf_sync_init(void *priv, const char *name);
+
+extern void dmabuf_sync_fini(struct dmabuf_sync *sync);
+
+extern int dmabuf_sync_lock(struct dmabuf_sync *sync);
+
+extern int dmabuf_sync_unlock(struct dmabuf_sync *sync);
+
+int dmabuf_sync_single_lock(struct dma_buf *dmabuf, unsigned int type,
+				bool wait);
+
+void dmabuf_sync_single_unlock(struct dma_buf *dmabuf);
+
+extern int dmabuf_sync_get(struct dmabuf_sync *sync, void *sync_buf,
+				unsigned int type);
+
+extern void dmabuf_sync_put(struct dmabuf_sync *sync, struct dma_buf *dmabuf);
+
+extern void dmabuf_sync_put_all(struct dmabuf_sync *sync);
+
+#else
+
+static inline void dmabuf_sync_reservation_init(struct dma_buf *dmabuf) { }
+
+static inline void dmabuf_sync_reservation_fini(struct dma_buf *dmabuf) { }
+
+static inline bool is_dmabuf_sync_supported(void) { return false; }
+
+static inline struct dmabuf_sync *dmabuf_sync_init(void *priv,
+					const char *names)
+{
+	return ERR_PTR(0);
+}
+
+static inline void dmabuf_sync_fini(struct dmabuf_sync *sync) { }
+
+static inline int dmabuf_sync_lock(struct dmabuf_sync *sync)
+{
+	return 0;
+}
+
+static inline int dmabuf_sync_unlock(struct dmabuf_sync *sync)
+{
+	return 0;
+}
+
+static inline int dmabuf_sync_single_lock(struct dma_buf *dmabuf,
+						unsigned int type,
+						bool wait)
+{
+	return 0;
+}
+
+static inline void dmabuf_sync_single_unlock(struct dma_buf *dmabuf)
+{
+	return;
+}
+
+static inline int dmabuf_sync_get(struct dmabuf_sync *sync,
+					void *sync_buf,
+					unsigned int type)
+{
+	return 0;
+}
+
+static inline void dmabuf_sync_put(struct dmabuf_sync *sync,
+					struct dma_buf *dmabuf) { }
+
+static inline void dmabuf_sync_put_all(struct dmabuf_sync *sync) { }
+
+#endif
-- 
1.7.5.4



From s.hauer at pengutronix.de  Fri Jul 12 02:49:57 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 12 Jul 2013 08:49:57 +0200
Subject: [PATCH] ARM: dts: imx: share pad macro names between imx6q and
 imx6dl
In-Reply-To: <1373522316-12319-1-git-send-email-shawn.guo@linaro.org>
References: <1373522316-12319-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130712064957.GH14452@pengutronix.de>

Hi Shawn,

Nice patch.

On Thu, Jul 11, 2013 at 01:58:36PM +0800, Shawn Guo wrote:
> The imx6q and imx6dl are two pin-to-pin compatible SoCs.  The same board
> design can work with either chip plugged into the socket, e.g. sabresd
> and sabreauto boards.
> 
> We currently define pin groups in imx6q.dtsi and imx6dl.dtsi
> respectively because the pad macro names are different between two
> chips.  This brings a maintenance burden on having the same label point
> to the same pin group defined in two places.
> 
> The patch drops prefix MX6Q_ and MX6DL_ from those pad macro names.

Can we use another prefix instead of removing it completely? Maybe
MX6QDL_?

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From nsekhar at ti.com  Fri Jul 12 02:51:20 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 12 Jul 2013 12:21:20 +0530
Subject: [PATCH v3 0/6] ARM: davinci: da850: add ethernet driver DT support
In-Reply-To: <CA+V-a8t-sTPAK+D5869X0_ZCdrmK0B+eRaowk9hMYwXMw09NqA@mail.gmail.com>
References: <1371999607-6483-1-git-send-email-prabhakar.csengg@gmail.com>
 <CA+V-a8t-sTPAK+D5869X0_ZCdrmK0B+eRaowk9hMYwXMw09NqA@mail.gmail.com>
Message-ID: <51DFA768.9090703@ti.com>

On 7/11/2013 10:42 PM, Prabhakar Lad wrote:
> Hi Sekhar,
> 
> On Sun, Jun 23, 2013 at 8:30 PM, Prabhakar Lad
> <prabhakar.csengg at gmail.com> wrote:
>> From: "Lad, Prabhakar" <prabhakar.csengg at gmail.com>
>>
>> This patch set enables Ethernet support through device tree model.
>> This patch set enables mii interface only and is being tested to boot via
>> rootfs. The rmii phy is present on the i2c gpio expander chip (UI board)
>> for which yet support needs to be added, once the DT support for the chip
>> is enabled, enabling rmii will be subsequnet patch.
>>
>> Changes for v2:
>> 1: Enabled mdio device.
>> 2: Fixed clock lookup.
>>
>> Changes for v3:
>> 1: Fixed review comments pointed out by Sekhar.
>>
>> Lad, Prabhakar (6):
>>   ARM: davinci: da8xx: fix clock lookup for mdio device
>>   ARM: davinci: da850: add DT node for mdio device
>>   ARM: davinci: da850: add OF_DEV_AUXDATA entry for mdio.
>>   ARM: davinci: da850: add DT node for eth0.
>>   ARM: davinci: da850: add OF_DEV_AUXDATA entry for eth0.
>>   ARM: davinci: da850: configure system configuration chip(CFGCHIP3)
>>     for emac
>>
> gentle ping..

I haven't been able to get to reviewing patches meant for v3.12 yet.
Most probably will happen next week.

Thanks,
Sekhar


From b18965 at freescale.com  Fri Jul 12 02:07:52 2013
From: b18965 at freescale.com (Alison Wang)
Date: Fri, 12 Jul 2013 14:07:52 +0800
Subject: [PATCH 1/5] ARM: dts: vf610: Add DCU and TCON nodes
In-Reply-To: <1373609276-14566-1-git-send-email-b18965@freescale.com>
References: <1373609276-14566-1-git-send-email-b18965@freescale.com>
Message-ID: <1373609276-14566-2-git-send-email-b18965@freescale.com>

This patch adds DCU and TCON nodes in SoC level DTS for Freescale
Vybrid VF610. It also removes useless pin for DCU0 pinctrl.

Signed-off-by: Alison Wang <b18965 at freescale.com>
---
Changes in v2: None

 arch/arm/boot/dts/vf610.dtsi | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index e1eb7da..037e8f1 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -140,6 +140,14 @@
 				clock-names = "pit";
 			};
 
+			tcon0: tcon at 4003d000 {
+				compatible = "fsl,vf610-tcon";
+				reg = <0x4003d000 0x1000>;
+				clocks = <&clks VF610_CLK_TCON0>;
+				clock-names = "tcon";
+				status = "disabled";
+			};
+
 			wdog at 4003e000 {
 				compatible = "fsl,vf610-wdt", "fsl,imx21-wdt";
 				reg = <0x4003e000 0x1000>;
@@ -169,7 +177,6 @@
 				dcu0 {
 					pinctrl_dcu0_1: dcu0grp_1 {
 						fsl,pins = <
-						VF610_PAD_PTB8__GPIO_30		0x42
 						VF610_PAD_PTE0__DCU0_HSYNC	0x42
 						VF610_PAD_PTE1__DCU0_VSYNC	0x42
 						VF610_PAD_PTE2__DCU0_PCLK	0x42
@@ -395,6 +402,16 @@
 				reg = <0x40050000 0x1000>;
 			};
 
+			dcu0: dcu at 40058000 {
+				compatible = "fsl,vf610-dcu";
+				reg = <0x40058000 0x1200>;
+				interrupts = <0 30 0x04>;
+				clocks = <&clks VF610_CLK_DCU0>;
+				clock-names = "dcu";
+				tcon-controller = <&tcon0>;
+				status = "disabled";
+			};
+
 			i2c0: i2c at 40066000 {
 				#address-cells = <1>;
 				#size-cells = <0>;
-- 
1.8.0




From b18965 at freescale.com  Fri Jul 12 02:07:53 2013
From: b18965 at freescale.com (Alison Wang)
Date: Fri, 12 Jul 2013 14:07:53 +0800
Subject: [PATCH 2/5] ARM: dts: vf610-twr: Enable DCU and TCON devices
In-Reply-To: <1373609276-14566-1-git-send-email-b18965@freescale.com>
References: <1373609276-14566-1-git-send-email-b18965@freescale.com>
Message-ID: <1373609276-14566-3-git-send-email-b18965@freescale.com>

This patch enables DCU and TCON devices for Vybrid VF610 TOWER board.

Signed-off-by: Alison Wang <b18965 at freescale.com>
---
Changes in v2: None

 arch/arm/boot/dts/vf610-twr.dts | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index b3905f5..605fb04 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -36,6 +36,12 @@
 
 };
 
+&dcu0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_dcu0_1>;
+	status = "okay";
+};
+
 &fec0 {
 	phy-mode = "rmii";
 	pinctrl-names = "default";
@@ -50,6 +56,10 @@
 	status = "okay";
 };
 
+&tcon0 {
+	status = "okay";
+};
+
 &uart1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart1_1>;
-- 
1.8.0




From b18965 at freescale.com  Fri Jul 12 02:07:51 2013
From: b18965 at freescale.com (Alison Wang)
Date: Fri, 12 Jul 2013 14:07:51 +0800
Subject: [PATCH v2 0/5] ARM: vf610: Add DCU framebuffer driver for Vybrid
 VF610 platform
Message-ID: <1373609276-14566-1-git-send-email-b18965@freescale.com>

This series contain DCU framebuffer driver for Freescale Vybrid VF610 platform.

The Display Controller Unit (DCU) module is a system master that
fetches graphics stored in internal or external memory and displays
them on a TFT LCD panel. A wide range of panel sizes is supported
and the timing of the interface signals is highly configurable.
Graphics are read directly from memory and then blended in real-time,
which allows for dynamic content creation with minimal CPU intervention.

The features:

(1) Full RGB888 output to TFT LCD panel.
(2) For the current LCD panel, WQVGA "480x272" is tested.
(3) Blending of each pixel using up to 4 source layers dependent on size of panel.
(4) Each graphic layer can be placed with one pixel resolution in either axis.
(5) Each graphic layer support RGB565 and RGB888 direct colors without alpha channel
and BGRA8888 direct colors with an alpha channel.
(6) Each graphic layer support alpha blending with 8-bit resolution.

Changes in v2:
- Add a document for DCU framebuffer driver under Documentation/devicetree/bindings/fb/.

----------------------------------------------------------------
Alison Wang (5):
      ARM: dts: vf610: Add DCU and TCON nodes
      ARM: dts: vf610-twr: Enable DCU and TCON devices
      ARM: clk: vf610: Add DCU and TCON clock support
      fb: Add DCU framebuffer driver for Vybrid VF610 platform
      Documentation: DT: Add DCU framebuffer driver

 Documentation/devicetree/bindings/fb/fsl-dcu-fb.txt |   36 ++++
 arch/arm/boot/dts/vf610-twr.dts                     |   10 +
 arch/arm/boot/dts/vf610.dtsi                        |   19 +-
 arch/arm/mach-imx/clk-vf610.c                       |    5 +
 drivers/video/Kconfig                               |    9 +
 drivers/video/Makefile                              |    1 +
 drivers/video/fsl-dcu-fb.c                          | 1091 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/dt-bindings/clock/vf610-clock.h             |    3 +-
 8 files changed, 1172 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/fb/fsl-dcu-fb.txt
 create mode 100644 drivers/video/fsl-dcu-fb.c




From b18965 at freescale.com  Fri Jul 12 02:07:54 2013
From: b18965 at freescale.com (Alison Wang)
Date: Fri, 12 Jul 2013 14:07:54 +0800
Subject: [PATCH 3/5] ARM: clk: vf610: Add DCU and TCON clock support
In-Reply-To: <1373609276-14566-1-git-send-email-b18965@freescale.com>
References: <1373609276-14566-1-git-send-email-b18965@freescale.com>
Message-ID: <1373609276-14566-4-git-send-email-b18965@freescale.com>

This patch adds DCU and TCON clock support for Vybrid VF610 platform.

Signed-off-by: Alison Wang <b18965 at freescale.com>
---
Changes in v2: None

 arch/arm/mach-imx/clk-vf610.c           | 5 +++++
 include/dt-bindings/clock/vf610-clock.h | 3 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/clk-vf610.c b/arch/arm/mach-imx/clk-vf610.c
index d617c0b..c4dbe32 100644
--- a/arch/arm/mach-imx/clk-vf610.c
+++ b/arch/arm/mach-imx/clk-vf610.c
@@ -245,6 +245,8 @@ static void __init vf610_clocks_init(struct device_node *ccm_node)
 	clk[VF610_CLK_DCU1_DIV] = imx_clk_divider("dcu1_div", "dcu1_en", CCM_CSCDR3, 20, 3);
 	clk[VF610_CLK_DCU1] = imx_clk_gate2("dcu1", "dcu1_div", CCM_CCGR9, CCM_CCGRx_CGn(8));
 
+	clk[VF610_CLK_TCON0] = imx_clk_gate2("tcon0", "platform_bus", CCM_CCGR1, CCM_CCGRx_CGn(13));
+
 	clk[VF610_CLK_ESAI_SEL] = imx_clk_mux("esai_sel", CCM_CSCMR1, 20, 2, esai_sels, 4);
 	clk[VF610_CLK_ESAI_EN] = imx_clk_gate("esai_en", "esai_sel", CCM_CSCDR2, 30);
 	clk[VF610_CLK_ESAI_DIV] = imx_clk_divider("esai_div", "esai_en", CCM_CSCDR2, 24, 4);
@@ -311,6 +313,9 @@ static void __init vf610_clocks_init(struct device_node *ccm_node)
 	clk_set_parent(clk[VF610_CLK_SAI2_SEL], clk[VF610_CLK_AUDIO_EXT]);
 	clk_set_parent(clk[VF610_CLK_SAI3_SEL], clk[VF610_CLK_AUDIO_EXT]);
 
+	clk_set_parent(clk[VF610_CLK_DCU0_SEL], clk[VF610_CLK_PLL1_PFD2]);
+	clk_set_rate(clk[VF610_CLK_DCU0_DIV], 113200000);
+
 	/* Add the clocks to provider list */
 	clk_data.clks = clk;
 	clk_data.clk_num = ARRAY_SIZE(clk);
diff --git a/include/dt-bindings/clock/vf610-clock.h b/include/dt-bindings/clock/vf610-clock.h
index 15e997f..a2fc6d9 100644
--- a/include/dt-bindings/clock/vf610-clock.h
+++ b/include/dt-bindings/clock/vf610-clock.h
@@ -158,6 +158,7 @@
 #define VF610_CLK_GPU_SEL		145
 #define VF610_CLK_GPU_EN		146
 #define VF610_CLK_GPU2D			147
-#define VF610_CLK_END			148
+#define VF610_CLK_TCON0			148
+#define VF610_CLK_END			149
 
 #endif /* __DT_BINDINGS_CLOCK_VF610_H */
-- 
1.8.0




From b18965 at freescale.com  Fri Jul 12 02:07:55 2013
From: b18965 at freescale.com (Alison Wang)
Date: Fri, 12 Jul 2013 14:07:55 +0800
Subject: [PATCH 4/5] fb: Add DCU framebuffer driver for Vybrid VF610 platform
In-Reply-To: <1373609276-14566-1-git-send-email-b18965@freescale.com>
References: <1373609276-14566-1-git-send-email-b18965@freescale.com>
Message-ID: <1373609276-14566-5-git-send-email-b18965@freescale.com>

The Display Controller Unit (DCU) module is a system master that
fetches graphics stored in internal or external memory and displays
them on a TFT LCD panel. A wide range of panel sizes is supported
and the timing of the interface signals is highly configurable.
Graphics are read directly from memory and then blended in real-time,
which allows for dynamic content creation with minimal CPU intervention.

The features:

(1) Full RGB888 output to TFT LCD panel.
(2) For the current LCD panel, WQVGA "480x272" is tested.
(3) Blending of each pixel using up to 4 source layers dependent on size of panel.
(4) Each graphic layer can be placed with one pixel resolution in either axis.
(5) Each graphic layer support RGB565 and RGB888 direct colors without alpha channel
and BGRA8888 direct colors with an alpha channel.
(6) Each graphic layer support alpha blending with 8-bit resolution.

This driver has been tested on Vybrid VF610 TOWER board.

Signed-off-by: Alison Wang <b18965 at freescale.com>
---
Changes in v2: None

 drivers/video/Kconfig      |    9 +
 drivers/video/Makefile     |    1 +
 drivers/video/fsl-dcu-fb.c | 1091 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 1101 insertions(+)
 create mode 100644 drivers/video/fsl-dcu-fb.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 46544d0..32dc1f8 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1978,6 +1978,15 @@ config FB_FSL_DIU
 	---help---
 	  Framebuffer driver for the Freescale SoC DIU
 
+config FB_FSL_DCU
+	tristate "Freescale DCU framebuffer support"
+	depends on FB
+	select FB_CFB_FILLRECT
+	select FB_CFB_COPYAREA
+	select FB_CFB_IMAGEBLIT
+	---help---
+	  Framebuffer driver for the Freescale SoC DCU
+
 config FB_W100
 	tristate "W100 frame buffer support"
 	depends on FB && ARCH_PXA
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index e8bae8d..3707a7d 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -129,6 +129,7 @@ obj-$(CONFIG_FB_IMX)              += imxfb.o
 obj-$(CONFIG_FB_S3C)		  += s3c-fb.o
 obj-$(CONFIG_FB_S3C2410)	  += s3c2410fb.o
 obj-$(CONFIG_FB_FSL_DIU)	  += fsl-diu-fb.o
+obj-$(CONFIG_FB_FSL_DCU)	  += fsl-dcu-fb.o
 obj-$(CONFIG_FB_COBALT)           += cobalt_lcdfb.o
 obj-$(CONFIG_FB_IBM_GXT4500)	  += gxt4500.o
 obj-$(CONFIG_FB_PS3)		  += ps3fb.o
diff --git a/drivers/video/fsl-dcu-fb.c b/drivers/video/fsl-dcu-fb.c
new file mode 100644
index 0000000..5571dde
--- /dev/null
+++ b/drivers/video/fsl-dcu-fb.c
@@ -0,0 +1,1091 @@
+/*
+ * Copyright 2012-2013 Freescale Semiconductor, Inc.
+ *
+ * Freescale DCU Frame Buffer device driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/dma-mapping.h>
+#include <linux/interrupt.h>
+#include <linux/fb.h>
+#include <linux/clk.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/uaccess.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+
+#define DRIVER_NAME			"fsl-dcu-fb"
+
+#define DCU_DCU_MODE			0x0010
+#define DCU_MODE_BLEND_ITER(x)		(x << 20)
+#define DCU_MODE_RASTER_EN		(1 << 14)
+#define DCU_MODE_DCU_MODE(x)		(x)
+#define DCU_MODE_DCU_MODE_MASK		0x03
+#define DCU_MODE_OFF			0
+#define DCU_MODE_NORMAL			1
+#define DCU_MODE_TEST			2
+#define DCU_MODE_COLORBAR		3
+
+#define DCU_BGND			0x0014
+#define DCU_BGND_R(x)			(x << 16)
+#define DCU_BGND_G(x)			(x << 8)
+#define DCU_BGND_B(x)			(x)
+
+#define DCU_DISP_SIZE			0x0018
+#define DCU_DISP_SIZE_DELTA_Y(x)	(x << 16)
+#define DCU_DISP_SIZE_DELTA_X(x)	(x)
+
+#define DCU_HSYN_PARA			0x001c
+#define DCU_HSYN_PARA_BP(x)		(x << 22)
+#define DCU_HSYN_PARA_PW(x)		(x << 11)
+#define DCU_HSYN_PARA_FP(x)		(x)
+
+#define DCU_VSYN_PARA			0x0020
+#define DCU_VSYN_PARA_BP(x)		(x << 22)
+#define DCU_VSYN_PARA_PW(x)		(x << 11)
+#define DCU_VSYN_PARA_FP(x)		(x)
+
+#define DCU_SYN_POL			0x0024
+#define DCU_SYN_POL_INV_PXCK_FALL	(0 << 6)
+#define DCU_SYN_POL_NEG_REMAIN		(0 << 5)
+#define DCU_SYN_POL_INV_VS_LOW		(1 << 1)
+#define DCU_SYN_POL_INV_HS_LOW		(1)
+
+#define DCU_THRESHOLD			0x0028
+#define DCU_THRESHOLD_LS_BF_VS(x)	(x << 16)
+#define DCU_THRESHOLD_OUT_BUF_HIGH(x)	(x << 8)
+#define DCU_THRESHOLD_OUT_BUF_LOW(x)	(x)
+
+#define DCU_INT_STATUS			0x002C
+#define DCU_INT_STATUS_UNDRUN		(1 << 1)
+
+#define DCU_INT_MASK			0x0030
+#define DCU_INT_MASK_UNDRUN		(1 << 1)
+
+#define DCU_DIV_RATIO			0x0054
+
+#define DCU_UPDATE_MODE			0x00cc
+#define DCU_UPDATE_MODE_MODE		(1 << 31)
+#define DCU_UPDATE_MODE_READREG		(1 << 30)
+
+#define DCU_CTRLDESCLN_1(x)		(0x200 + (x) * 0x40)
+#define DCU_CTRLDESCLN_1_HEIGHT(x)	(x << 16)
+#define DCU_CTRLDESCLN_1_WIDTH(x)	(x)
+
+#define DCU_CTRLDESCLN_2(x)		(0x204 + (x) * 0x40)
+#define DCU_CTRLDESCLN_2_POSY(x)	(x << 16)
+#define DCU_CTRLDESCLN_2_POSX(x)	(x)
+
+#define DCU_CTRLDESCLN_3(x)		(0x208 + (x) * 0x40)
+
+#define DCU_CTRLDESCLN_4(x)		(0x20c + (x) * 0x40)
+#define DCU_CTRLDESCLN_4_EN		(1 << 31)
+#define DCU_CTRLDESCLN_4_TILE_EN	(1 << 30)
+#define DCU_CTRLDESCLN_4_DATA_SEL_CLUT	(1 << 29)
+#define DCU_CTRLDESCLN_4_SAFETY_EN	(1 << 28)
+#define DCU_CTRLDESCLN_4_TRANS(x)	(x << 20)
+#define DCU_CTRLDESCLN_4_BPP(x)		(x << 16)
+#define DCU_CTRLDESCLN_4_RLE_EN		(1 << 15)
+#define DCU_CTRLDESCLN_4_LUOFFS(x)	(x << 4)
+#define DCU_CTRLDESCLN_4_BB_ON		(1 << 2)
+#define DCU_CTRLDESCLN_4_AB(x)		(x)
+
+#define DCU_CTRLDESCLN_5(x)		(0x210 + (x) * 0x40)
+#define DCU_CTRLDESCLN_5_CKMAX_R(x)	(x << 16)
+#define DCU_CTRLDESCLN_5_CKMAX_G(x)	(x << 8)
+#define DCU_CTRLDESCLN_5_CKMAX_B(x)	(x)
+
+#define DCU_CTRLDESCLN_6(x)		(0x214 + (x) * 0x40)
+#define DCU_CTRLDESCLN_6_CKMIN_R(x)	(x << 16)
+#define DCU_CTRLDESCLN_6_CKMIN_G(x)	(x << 8)
+#define DCU_CTRLDESCLN_6_CKMIN_B(x)	(x)
+
+#define DCU_CTRLDESCLN_7(x)		(0x218 + (x) * 0x40)
+#define DCU_CTRLDESCLN_7_TILE_VER(x)	(x << 16)
+#define DCU_CTRLDESCLN_7_TILE_HOR(x)	(x)
+
+#define DCU_CTRLDESCLN_8(x)		(0x21c + (x) * 0x40)
+#define DCU_CTRLDESCLN_8_FG_FCOLOR(x)	(x)
+
+#define DCU_CTRLDESCLN_9(x)		(0x220 + (x) * 0x40)
+#define DCU_CTRLDESCLN_9_BG_BCOLOR(x)	(x)
+
+#define DCU_TOTAL_LAYER_NUM		64
+#define DCU_LAYER_NUM_MAX		6
+#define DCU_LAYER_NUM			4
+
+#define BPP_16_RGB565			4
+#define BPP_24_RGB888			5
+#define BPP_32_ARGB8888			6
+
+#define TCON_CTRL1			0x0000
+#define TCON_BYPASS_ENABLE		(1 << 29)
+
+#define MFB_SET_ALPHA		_IOW('M', 0, __u8)
+#define MFB_GET_ALPHA		_IOR('M', 0, __u8)
+#define MFB_SET_LAYER		_IOW('M', 4, struct layer_display_offset)
+#define MFB_GET_LAYER		_IOR('M', 4, struct layer_display_offset)
+
+static char *fb_mode;
+static unsigned int default_bpp = 24;
+
+static struct fb_videomode dcu_mode_db[] = {
+	{
+		.name		= "480x272",
+		.refresh	= 75,
+		.xres		= 480,
+		.yres		= 272,
+		.pixclock	= 91996,
+		.left_margin	= 2,
+		.right_margin	= 2,
+		.upper_margin	= 1,
+		.lower_margin	= 1,
+		.hsync_len	= 41,
+		.vsync_len	= 2,
+		.sync		= FB_SYNC_COMP_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+		.vmode		= FB_VMODE_NONINTERLACED,
+	},
+};
+
+/* DCU framebuffer data structure */
+struct dcu_fb_data {
+	struct fb_info *fsl_dcu_info[DCU_LAYER_NUM];
+	void __iomem *reg_base;
+	unsigned int irq;
+	struct clk *clk;
+};
+
+struct layer_display_offset {
+	int x_layer_d;
+	int y_layer_d;
+};
+
+struct mfb_info {
+	int index;
+	char *id;
+	unsigned long pseudo_palette[16];
+	unsigned char alpha;
+	unsigned char blend;
+	unsigned int count;
+	int x_layer_d;	/* layer display x offset to physical screen */
+	int y_layer_d;	/* layer display y offset to physical screen */
+	struct dcu_fb_data *parent;
+};
+
+enum mfb_index {
+	LAYER0 = 0,
+	LAYER1,
+	LAYER2,
+	LAYER3,
+};
+
+static struct mfb_info mfb_template[] = {
+	{
+	.index = LAYER0,
+	.id = "Layer0",
+	.alpha = 0xff,
+	.blend = 0,
+	.count = 0,
+	.x_layer_d = 0,
+	.y_layer_d = 0,
+	},
+	{
+	.index = LAYER1,
+	.id = "Layer1",
+	.alpha = 0xff,
+	.blend = 0,
+	.count = 0,
+	.x_layer_d = 50,
+	.y_layer_d = 50,
+	},
+	{
+	.index = LAYER2,
+	.id = "Layer2",
+	.alpha = 0xff,
+	.blend = 0,
+	.count = 0,
+	.x_layer_d = 100,
+	.y_layer_d = 100,
+	},
+	{
+	.index = LAYER3,
+	.id = "Layer3",
+	.alpha = 0xff,
+	.blend = 0,
+	.count = 0,
+	.x_layer_d = 150,
+	.y_layer_d = 150,
+	},
+};
+
+static int enable_panel(struct fb_info *info)
+{
+	struct fb_var_screeninfo *var = &info->var;
+	struct mfb_info *mfbi = info->par;
+	struct dcu_fb_data *dcufb = mfbi->parent;
+	unsigned int bpp;
+
+	writel(DCU_CTRLDESCLN_1_HEIGHT(var->yres) |
+		DCU_CTRLDESCLN_1_WIDTH(var->xres),
+		dcufb->reg_base + DCU_CTRLDESCLN_1(mfbi->index));
+	writel(DCU_CTRLDESCLN_2_POSY(mfbi->y_layer_d) |
+		DCU_CTRLDESCLN_2_POSX(mfbi->x_layer_d),
+		dcufb->reg_base + DCU_CTRLDESCLN_2(mfbi->index));
+
+	writel(info->fix.smem_start,
+		dcufb->reg_base + DCU_CTRLDESCLN_3(mfbi->index));
+
+	switch (var->bits_per_pixel) {
+	case 16:
+		bpp = BPP_16_RGB565;
+		break;
+	case 24:
+		bpp = BPP_24_RGB888;
+		break;
+	case 32:
+		bpp = BPP_32_ARGB8888;
+		break;
+	default:
+		printk(KERN_ERR "unsupported color depth: %u\n",
+			var->bits_per_pixel);
+		return -EINVAL;
+	}
+
+	writel(DCU_CTRLDESCLN_4_EN |
+		DCU_CTRLDESCLN_4_TRANS(mfbi->alpha) |
+		DCU_CTRLDESCLN_4_BPP(bpp) |
+		DCU_CTRLDESCLN_4_AB(mfbi->blend),
+		dcufb->reg_base + DCU_CTRLDESCLN_4(mfbi->index));
+
+	writel(DCU_CTRLDESCLN_5_CKMAX_R(0xff) |
+		DCU_CTRLDESCLN_5_CKMAX_G(0xff) |
+		DCU_CTRLDESCLN_5_CKMAX_B(0xff),
+		dcufb->reg_base + DCU_CTRLDESCLN_5(mfbi->index));
+	writel(DCU_CTRLDESCLN_6_CKMIN_R(0) |
+		DCU_CTRLDESCLN_6_CKMIN_G(0) |
+		DCU_CTRLDESCLN_6_CKMIN_B(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_6(mfbi->index));
+
+	writel(DCU_CTRLDESCLN_7_TILE_VER(0) | DCU_CTRLDESCLN_7_TILE_HOR(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_7(mfbi->index));
+
+	writel(DCU_CTRLDESCLN_8_FG_FCOLOR(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_8(mfbi->index));
+	writel(DCU_CTRLDESCLN_9_BG_BCOLOR(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_9(mfbi->index));
+
+	writel(DCU_UPDATE_MODE_READREG, dcufb->reg_base + DCU_UPDATE_MODE);
+	return 0;
+}
+
+static int disable_panel(struct fb_info *info)
+{
+	struct mfb_info *mfbi = info->par;
+	struct dcu_fb_data *dcufb = mfbi->parent;
+
+	writel(DCU_CTRLDESCLN_1_HEIGHT(0) |
+		DCU_CTRLDESCLN_1_WIDTH(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_1(mfbi->index));
+	writel(DCU_CTRLDESCLN_2_POSY(0) | DCU_CTRLDESCLN_2_POSX(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_2(mfbi->index));
+
+	writel(0, dcufb->reg_base + DCU_CTRLDESCLN_3(mfbi->index));
+	writel(0, dcufb->reg_base + DCU_CTRLDESCLN_4(mfbi->index));
+
+	writel(DCU_CTRLDESCLN_5_CKMAX_R(0) |
+		DCU_CTRLDESCLN_5_CKMAX_G(0) |
+		DCU_CTRLDESCLN_5_CKMAX_B(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_5(mfbi->index));
+	writel(DCU_CTRLDESCLN_6_CKMIN_R(0) |
+		DCU_CTRLDESCLN_6_CKMIN_G(0) |
+		DCU_CTRLDESCLN_6_CKMIN_B(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_6(mfbi->index));
+
+	writel(DCU_CTRLDESCLN_7_TILE_VER(0) | DCU_CTRLDESCLN_7_TILE_HOR(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_7(mfbi->index));
+
+	writel(DCU_CTRLDESCLN_8_FG_FCOLOR(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_8(mfbi->index));
+	writel(DCU_CTRLDESCLN_9_BG_BCOLOR(0),
+		dcufb->reg_base + DCU_CTRLDESCLN_9(mfbi->index));
+
+	writel(DCU_UPDATE_MODE_READREG, dcufb->reg_base + DCU_UPDATE_MODE);
+	return 0;
+}
+
+static void enable_controller(struct fb_info *info)
+{
+	struct mfb_info *mfbi = info->par;
+	struct dcu_fb_data *dcufb = mfbi->parent;
+	unsigned int dcu_mode;
+
+	dcu_mode = readl(dcufb->reg_base + DCU_DCU_MODE);
+	writel(dcu_mode | DCU_MODE_DCU_MODE(DCU_MODE_NORMAL),
+		dcufb->reg_base + DCU_DCU_MODE);
+}
+
+static void disable_controller(struct fb_info *info)
+{
+	struct mfb_info *mfbi = info->par;
+	struct dcu_fb_data *dcufb = mfbi->parent;
+
+	writel(DCU_MODE_DCU_MODE(DCU_MODE_OFF),
+		dcufb->reg_base + DCU_DCU_MODE);
+}
+
+static int fsl_dcu_check_var(struct fb_var_screeninfo *var,
+		struct fb_info *info)
+{
+	if (var->xres_virtual < var->xres)
+		var->xres_virtual = var->xres;
+	if (var->yres_virtual < var->yres)
+		var->yres_virtual = var->yres;
+
+	if (var->xoffset < 0)
+		var->xoffset = 0;
+
+	if (var->yoffset < 0)
+		var->yoffset = 0;
+
+	if (var->xoffset + info->var.xres > info->var.xres_virtual)
+		var->xoffset = info->var.xres_virtual - info->var.xres;
+
+	if (var->yoffset + info->var.yres > info->var.yres_virtual)
+		var->yoffset = info->var.yres_virtual - info->var.yres;
+
+	if ((var->bits_per_pixel != 32) && (var->bits_per_pixel != 24) &&
+	    (var->bits_per_pixel != 16))
+		var->bits_per_pixel = default_bpp;
+
+	switch (var->bits_per_pixel) {
+	case 16:
+		var->red.length = 5;
+		var->red.offset = 11;
+		var->red.msb_right = 0;
+
+		var->green.length = 6;
+		var->green.offset = 5;
+		var->green.msb_right = 0;
+
+		var->blue.length = 5;
+		var->blue.offset = 0;
+		var->blue.msb_right = 0;
+
+		var->transp.length = 0;
+		var->transp.offset = 0;
+		var->transp.msb_right = 0;
+		break;
+	case 24:
+		var->red.length = 8;
+		var->red.offset = 16;
+		var->red.msb_right = 0;
+
+		var->green.length = 8;
+		var->green.offset = 8;
+		var->green.msb_right = 0;
+
+		var->blue.length = 8;
+		var->blue.offset = 0;
+		var->blue.msb_right = 0;
+
+		var->transp.length = 0;
+		var->transp.offset = 0;
+		var->transp.msb_right = 0;
+		break;
+	case 32:
+		var->red.length = 8;
+		var->red.offset = 16;
+		var->red.msb_right = 0;
+
+		var->green.length = 8;
+		var->green.offset = 8;
+		var->green.msb_right = 0;
+
+		var->blue.length = 8;
+		var->blue.offset = 0;
+		var->blue.msb_right = 0;
+
+		var->transp.length = 8;
+		var->transp.offset = 24;
+		var->transp.msb_right = 0;
+		break;
+	default:
+		printk(KERN_ERR "unsupported color depth: %u\n",
+			var->bits_per_pixel);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int calc_div_ratio(struct fb_info *info)
+{
+	struct mfb_info *mfbi = info->par;
+	struct dcu_fb_data *dcufb = mfbi->parent;
+	unsigned long dcu_clk;
+	unsigned long long tmp;
+
+	dcu_clk = clk_get_rate(dcufb->clk);
+	tmp = info->var.pixclock * (unsigned long long)dcu_clk;
+
+	do_div(tmp, 1000000);
+
+	if (do_div(tmp, 1000000) > 500000)
+		tmp++;
+
+	tmp = tmp - 1;
+	return tmp;
+}
+
+static void update_controller(struct fb_info *info)
+{
+	struct fb_var_screeninfo *var = &info->var;
+	struct mfb_info *mfbi = info->par;
+	struct dcu_fb_data *dcufb = mfbi->parent;
+	unsigned int ratio;
+
+	ratio = calc_div_ratio(info);
+	writel(ratio, dcufb->reg_base + DCU_DIV_RATIO);
+
+	writel(DCU_DISP_SIZE_DELTA_Y(var->yres) |
+		DCU_DISP_SIZE_DELTA_X(var->xres / 16),
+		dcufb->reg_base + DCU_DISP_SIZE);
+
+	/* Horizontal and vertical sync parameter */
+	writel(DCU_HSYN_PARA_BP(var->left_margin) |
+		DCU_HSYN_PARA_PW(var->hsync_len) |
+		DCU_HSYN_PARA_FP(var->right_margin),
+		dcufb->reg_base + DCU_HSYN_PARA);
+
+	writel(DCU_VSYN_PARA_BP(var->upper_margin) |
+		DCU_VSYN_PARA_PW(var->vsync_len) |
+		DCU_VSYN_PARA_FP(var->lower_margin),
+		dcufb->reg_base + DCU_VSYN_PARA);
+
+	writel(DCU_SYN_POL_INV_PXCK_FALL | DCU_SYN_POL_NEG_REMAIN |
+		DCU_SYN_POL_INV_VS_LOW | DCU_SYN_POL_INV_HS_LOW,
+		dcufb->reg_base + DCU_SYN_POL);
+
+	writel(DCU_BGND_R(0) | DCU_BGND_G(0) | DCU_BGND_B(0),
+		dcufb->reg_base + DCU_BGND);
+
+	writel(DCU_MODE_BLEND_ITER(DCU_LAYER_NUM_MAX) | DCU_MODE_RASTER_EN,
+			dcufb->reg_base + DCU_DCU_MODE);
+
+	writel(DCU_THRESHOLD_LS_BF_VS(0x3) | DCU_THRESHOLD_OUT_BUF_HIGH(0x78) |
+		DCU_THRESHOLD_OUT_BUF_LOW(0), dcufb->reg_base + DCU_THRESHOLD);
+
+	enable_controller(info);
+}
+
+static int map_video_memory(struct fb_info *info)
+{
+	u32 smem_len = info->fix.line_length * info->var.yres_virtual;
+
+	info->fix.smem_len = smem_len;
+
+	info->screen_base = dma_alloc_coherent(info->device, info->fix.smem_len,
+		(dma_addr_t *)&info->fix.smem_start, GFP_KERNEL);
+	if (!info->screen_base) {
+		printk(KERN_ERR "unable to allocate fb memory\n");
+		return -ENOMEM;
+	}
+
+	memset(info->screen_base, 0, info->fix.smem_len);
+
+	return 0;
+}
+
+static void unmap_video_memory(struct fb_info *info)
+{
+	if (!info->screen_base)
+		return;
+
+	dma_free_coherent(info->device, info->fix.smem_len,
+		info->screen_base, info->fix.smem_start);
+
+	info->screen_base = NULL;
+	info->fix.smem_start = 0;
+	info->fix.smem_len = 0;
+}
+
+static int fsl_dcu_set_layer(struct fb_info *info)
+{
+	struct mfb_info *mfbi = info->par;
+	struct fb_var_screeninfo *var = &info->var;
+	struct dcu_fb_data *dcufb = mfbi->parent;
+	int pixel_offset;
+	unsigned long addr;
+
+	pixel_offset = (var->yoffset * var->xres_virtual) + var->xoffset;
+	addr = info->fix.smem_start +
+		(pixel_offset * (var->bits_per_pixel >> 3));
+
+	writel(addr, dcufb->reg_base + DCU_CTRLDESCLN_3(mfbi->index));
+	writel(DCU_UPDATE_MODE_READREG, dcufb->reg_base + DCU_UPDATE_MODE);
+
+	return 0;
+}
+
+static int fsl_dcu_set_par(struct fb_info *info)
+{
+	unsigned long len;
+	struct fb_var_screeninfo *var = &info->var;
+	struct fb_fix_screeninfo *fix = &info->fix;
+	struct mfb_info *mfbi = info->par;
+
+	fix->line_length = var->xres_virtual * var->bits_per_pixel / 8;
+	fix->type = FB_TYPE_PACKED_PIXELS;
+	fix->accel = FB_ACCEL_NONE;
+	fix->visual = FB_VISUAL_TRUECOLOR;
+	fix->xpanstep = 1;
+	fix->ypanstep = 1;
+
+	len = info->var.yres_virtual * info->fix.line_length;
+	if (len != info->fix.smem_len) {
+		if (info->fix.smem_start)
+			unmap_video_memory(info);
+
+		if (map_video_memory(info)) {
+			printk(KERN_ERR "unable to allocate fb memory\n");
+			return -ENOMEM;
+		}
+	}
+
+	/* Only layer 0 could update LCD controller */
+	if (mfbi->index == LAYER0)
+		update_controller(info);
+
+	enable_panel(info);
+	return 0;
+}
+
+static inline __u32 CNVT_TOHW(__u32 val, __u32 width)
+{
+	return ((val<<width) + 0x7FFF - val) >> 16;
+}
+
+static int fsl_dcu_setcolreg(unsigned regno, unsigned red, unsigned green,
+			   unsigned blue, unsigned transp, struct fb_info *info)
+{
+	unsigned int val;
+	int ret = -EINVAL;
+
+	/*
+	 * If greyscale is true, then we convert the RGB value
+	 * to greyscale no matter what visual we are using.
+	 */
+	if (info->var.grayscale)
+		red = green = blue = (19595 * red + 38470 * green +
+				      7471 * blue) >> 16;
+	switch (info->fix.visual) {
+	case FB_VISUAL_TRUECOLOR:
+		/*
+		 * 16-bit True Colour.  We encode the RGB value
+		 * according to the RGB bitfield information.
+		 */
+		if (regno < 16) {
+			u32 *pal = info->pseudo_palette;
+
+			red = CNVT_TOHW(red, info->var.red.length);
+			green = CNVT_TOHW(green, info->var.green.length);
+			blue = CNVT_TOHW(blue, info->var.blue.length);
+			transp = CNVT_TOHW(transp, info->var.transp.length);
+
+			val = (red << info->var.red.offset) |
+			    (green << info->var.green.offset) |
+			    (blue << info->var.blue.offset) |
+			    (transp << info->var.transp.offset);
+
+			pal[regno] = val;
+			ret = 0;
+		}
+		break;
+	case FB_VISUAL_STATIC_PSEUDOCOLOR:
+	case FB_VISUAL_PSEUDOCOLOR:
+		break;
+	}
+
+	return ret;
+}
+
+static int fsl_dcu_pan_display(struct fb_var_screeninfo *var,
+			     struct fb_info *info)
+{
+	if ((info->var.xoffset == var->xoffset) &&
+	    (info->var.yoffset == var->yoffset))
+		return 0;
+
+	if (var->xoffset < 0 || var->yoffset < 0
+	    || var->xoffset + info->var.xres > info->var.xres_virtual
+	    || var->yoffset + info->var.yres > info->var.yres_virtual)
+		return -EINVAL;
+
+	info->var.xoffset = var->xoffset;
+	info->var.yoffset = var->yoffset;
+
+	if (var->vmode & FB_VMODE_YWRAP)
+		info->var.vmode |= FB_VMODE_YWRAP;
+	else
+		info->var.vmode &= ~FB_VMODE_YWRAP;
+
+	fsl_dcu_set_layer(info);
+
+	return 0;
+}
+
+static int fsl_dcu_blank(int blank_mode, struct fb_info *info)
+{
+	switch (blank_mode) {
+	case FB_BLANK_VSYNC_SUSPEND:
+	case FB_BLANK_HSYNC_SUSPEND:
+	case FB_BLANK_NORMAL:
+		disable_panel(info);
+		break;
+	case FB_BLANK_POWERDOWN:
+		disable_controller(info);
+		break;
+	case FB_BLANK_UNBLANK:
+		enable_panel(info);
+		break;
+	}
+
+	return 0;
+}
+
+static int fsl_dcu_ioctl(struct fb_info *info, unsigned int cmd,
+		unsigned long arg)
+{
+	struct mfb_info *mfbi = info->par;
+	struct layer_display_offset layer_d;
+	void __user *buf = (void __user *)arg;
+	unsigned char alpha;
+
+	switch (cmd) {
+	case MFB_SET_LAYER:
+		if (copy_from_user(&layer_d, buf, sizeof(layer_d)))
+			return -EFAULT;
+		mfbi->x_layer_d = layer_d.x_layer_d;
+		mfbi->y_layer_d = layer_d.y_layer_d;
+		fsl_dcu_set_par(info);
+		break;
+	case MFB_GET_LAYER:
+		layer_d.x_layer_d = mfbi->x_layer_d;
+		layer_d.y_layer_d = mfbi->y_layer_d;
+		if (copy_to_user(buf, &layer_d, sizeof(layer_d)))
+			return -EFAULT;
+		break;
+	case MFB_GET_ALPHA:
+		alpha = mfbi->alpha;
+		if (copy_to_user(buf, &alpha, sizeof(alpha)))
+			return -EFAULT;
+		break;
+	case MFB_SET_ALPHA:
+		if (copy_from_user(&alpha, buf, sizeof(alpha)))
+			return -EFAULT;
+		mfbi->blend = 1;
+		mfbi->alpha = alpha;
+		fsl_dcu_set_par(info);
+		break;
+	default:
+		printk(KERN_ERR "unknown ioctl command (0x%08X)\n", cmd);
+		return -ENOIOCTLCMD;
+	}
+
+	return 0;
+}
+
+static void enable_interrupts(struct dcu_fb_data *dcufb)
+{
+	u32 int_mask = readl(dcufb->reg_base + DCU_INT_MASK);
+
+	writel(int_mask & ~DCU_INT_MASK_UNDRUN, dcufb->reg_base + DCU_INT_MASK);
+}
+
+static void reset_layers(struct dcu_fb_data *dcufb)
+{
+	int i;
+
+	for (i = 1; i < DCU_TOTAL_LAYER_NUM; i++) {
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_1(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_2(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_3(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_4(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_5(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_6(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_7(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_8(i));
+		writel(0, dcufb->reg_base + DCU_CTRLDESCLN_9(i));
+	}
+	writel(DCU_UPDATE_MODE_READREG, dcufb->reg_base + DCU_UPDATE_MODE);
+}
+
+static int fsl_dcu_open(struct fb_info *info, int user)
+{
+	struct mfb_info *mfbi = info->par;
+	int ret = 0;
+
+	mfbi->index = info->node;
+
+	mfbi->count++;
+	if (mfbi->count == 1) {
+		fsl_dcu_check_var(&info->var, info);
+		ret = fsl_dcu_set_par(info);
+		if (ret < 0)
+			mfbi->count--;
+		else
+			enable_interrupts(mfbi->parent);
+	}
+
+	return ret;
+}
+
+static int fsl_dcu_release(struct fb_info *info, int user)
+{
+	struct mfb_info *mfbi = info->par;
+	int ret = 0;
+
+	mfbi->count--;
+	if (mfbi->count == 0) {
+		ret = disable_panel(info);
+		if (ret < 0)
+			mfbi->count++;
+	}
+
+	return ret;
+}
+
+static struct fb_ops fsl_dcu_ops = {
+	.owner = THIS_MODULE,
+	.fb_check_var = fsl_dcu_check_var,
+	.fb_set_par = fsl_dcu_set_par,
+	.fb_setcolreg = fsl_dcu_setcolreg,
+	.fb_blank = fsl_dcu_blank,
+	.fb_pan_display = fsl_dcu_pan_display,
+	.fb_fillrect = cfb_fillrect,
+	.fb_copyarea = cfb_copyarea,
+	.fb_imageblit = cfb_imageblit,
+	.fb_ioctl = fsl_dcu_ioctl,
+	.fb_open = fsl_dcu_open,
+	.fb_release = fsl_dcu_release,
+};
+
+static int install_framebuffer(struct fb_info *info)
+{
+	struct mfb_info *mfbi = info->par;
+	struct fb_videomode *db = dcu_mode_db;
+	unsigned int dbsize = ARRAY_SIZE(dcu_mode_db);
+	int ret;
+
+	info->var.activate = FB_ACTIVATE_NOW;
+	info->fbops = &fsl_dcu_ops;
+	info->flags = FBINFO_FLAG_DEFAULT;
+	info->pseudo_palette = &mfbi->pseudo_palette;
+
+	fb_alloc_cmap(&info->cmap, 16, 0);
+
+	ret = fb_find_mode(&info->var, info, fb_mode, db, dbsize,
+			NULL, default_bpp);
+
+	if (fsl_dcu_check_var(&info->var, info)) {
+		ret = -EINVAL;
+		goto failed_checkvar;
+	}
+
+	if (register_framebuffer(info) < 0) {
+		ret = -EINVAL;
+		goto failed_register_framebuffer;
+	}
+
+	printk(KERN_INFO "fb%d: %s fb device registered successfully.\n",
+		info->node, info->fix.id);
+	return 0;
+
+failed_checkvar:
+	fb_dealloc_cmap(&info->cmap);
+failed_register_framebuffer:
+	unmap_video_memory(info);
+	fb_dealloc_cmap(&info->cmap);
+	return ret;
+}
+
+static void uninstall_framebuffer(struct fb_info *info)
+{
+	unregister_framebuffer(info);
+	unmap_video_memory(info);
+
+	if (&info->cmap)
+		fb_dealloc_cmap(&info->cmap);
+}
+
+static irqreturn_t fsl_dcu_irq(int irq, void *dev_id)
+{
+	struct dcu_fb_data *dcufb = dev_id;
+	unsigned int status = readl(dcufb->reg_base + DCU_INT_STATUS);
+	u32 dcu_mode;
+
+	if (status) {
+		if (status & DCU_INT_STATUS_UNDRUN) {
+			dcu_mode = readl(dcufb->reg_base + DCU_DCU_MODE);
+			dcu_mode &= ~DCU_MODE_DCU_MODE_MASK;
+			writel(dcu_mode | DCU_MODE_DCU_MODE(DCU_MODE_OFF),
+				dcufb->reg_base + DCU_DCU_MODE);
+			udelay(1);
+			writel(dcu_mode | DCU_MODE_DCU_MODE(DCU_MODE_NORMAL),
+				dcufb->reg_base + DCU_DCU_MODE);
+		}
+		writel(status, dcufb->reg_base + DCU_INT_STATUS);
+		return IRQ_HANDLED;
+	}
+	return IRQ_NONE;
+}
+
+#ifdef CONFIG_PM
+static int fsl_dcu_suspend(struct platform_device *pdev,
+		pm_message_t state)
+{
+	struct dcu_fb_data *dcufb = dev_get_drvdata(&pdev->dev);
+
+	clk_disable_unprepare(dcufb->clk);
+	return 0;
+}
+
+static int fsl_dcu_resume(struct platform_device *pdev)
+{
+	struct dcu_fb_data *dcufb = dev_get_drvdata(&pdev->dev);
+
+	clk_prepare_enable(dcufb->clk);
+	return 0;
+}
+#else
+#define fsl_dcu_suspend	NULL
+#define fsl_dcu_resume	NULL
+#endif
+
+static int bypass_tcon(struct device_node *np)
+{
+	struct device_node *tcon_np;
+	struct platform_device *tcon_pdev;
+	struct clk *tcon_clk;
+	void __iomem *tcon_reg;
+	int ret = 0;
+
+	tcon_np = of_parse_phandle(np, "tcon-controller", 0);
+	if (!tcon_np)
+		return -EINVAL;
+
+	tcon_pdev = of_find_device_by_node(tcon_np);
+	if (!tcon_pdev)
+		return -EINVAL;
+
+	tcon_clk = devm_clk_get(&tcon_pdev->dev, "tcon");
+	if (IS_ERR(tcon_clk)) {
+		ret = PTR_ERR(tcon_clk);
+		goto failed_getclock;
+	}
+	clk_prepare_enable(tcon_clk);
+
+	tcon_reg = of_iomap(tcon_np, 0);
+	if (!tcon_reg) {
+		ret = -ENOMEM;
+		goto failed_ioremap;
+	}
+	writel(TCON_BYPASS_ENABLE, tcon_reg + TCON_CTRL1);
+
+	return 0;
+
+failed_ioremap:
+	clk_disable_unprepare(tcon_clk);
+failed_getclock:
+	of_node_put(tcon_np);
+	return ret;
+}
+
+static int fsl_dcu_probe(struct platform_device *pdev)
+{
+	struct dcu_fb_data *dcufb;
+	struct mfb_info *mfbi;
+	struct resource *res;
+	int ret = 0;
+	int i;
+
+	dcufb = devm_kzalloc(&pdev->dev,
+		sizeof(struct dcu_fb_data), GFP_KERNEL);
+	if (!dcufb)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(&pdev->dev, "could not get memory IO resource\n");
+		return -ENODEV;
+	}
+
+	dcufb->reg_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(dcufb->reg_base)) {
+		ret = PTR_ERR(dcufb->reg_base);
+		goto failed_ioremap;
+	}
+
+	dcufb->irq = platform_get_irq(pdev, 0);
+	if (!dcufb->irq) {
+		ret = -EINVAL;
+		goto failed_getirq;
+	}
+
+	ret = request_irq(dcufb->irq, fsl_dcu_irq, 0, DRIVER_NAME, dcufb);
+	if (ret) {
+		dev_err(&pdev->dev, "could not request irq\n");
+		goto failed_requestirq;
+	}
+
+	/* Put TCON in bypass mode, so the input signals from DCU are passed
+	 * through TCON unchanged */
+	ret = bypass_tcon(pdev->dev.of_node);
+	if (ret) {
+		dev_err(&pdev->dev, "could not bypass TCON\n");
+		goto failed_bypasstcon;
+	}
+
+	dcufb->clk = devm_clk_get(&pdev->dev, "dcu");
+	if (IS_ERR(dcufb->clk)) {
+		dev_err(&pdev->dev, "could not get clock\n");
+		goto failed_getclock;
+	}
+	clk_prepare_enable(dcufb->clk);
+
+	for (i = 0; i < ARRAY_SIZE(dcufb->fsl_dcu_info); i++) {
+		dcufb->fsl_dcu_info[i] =
+			framebuffer_alloc(sizeof(struct mfb_info), &pdev->dev);
+		if (!dcufb->fsl_dcu_info[i]) {
+			ret = ENOMEM;
+			goto failed_alloc_framebuffer;
+		}
+
+		dcufb->fsl_dcu_info[i]->fix.smem_start = 0;
+
+		mfbi = dcufb->fsl_dcu_info[i]->par;
+		memcpy(mfbi, &mfb_template[i], sizeof(struct mfb_info));
+		mfbi->parent = dcufb;
+
+		ret = install_framebuffer(dcufb->fsl_dcu_info[i]);
+		if (ret) {
+			dev_err(&pdev->dev,
+				"could not register framebuffer %d\n", i);
+			goto failed_register_framebuffer;
+		}
+	}
+
+	reset_layers(mfbi->parent);
+
+	dev_set_drvdata(&pdev->dev, dcufb);
+	return 0;
+
+failed_register_framebuffer:
+	for (i = 0; i < ARRAY_SIZE(dcufb->fsl_dcu_info); i++) {
+		if (dcufb->fsl_dcu_info[i])
+			framebuffer_release(dcufb->fsl_dcu_info[i]);
+	}
+failed_alloc_framebuffer:
+failed_getclock:
+failed_bypasstcon:
+	free_irq(dcufb->irq, dcufb);
+failed_requestirq:
+failed_getirq:
+	iounmap(dcufb->reg_base);
+failed_ioremap:
+	kfree(dcufb);
+	return ret;
+}
+
+static int fsl_dcu_remove(struct platform_device *pdev)
+{
+	struct dcu_fb_data *dcufb = dev_get_drvdata(&pdev->dev);
+	int i;
+
+	disable_controller(dcufb->fsl_dcu_info[0]);
+
+	clk_disable_unprepare(dcufb->clk);
+	free_irq(dcufb->irq, dcufb);
+
+	for (i = 0; i < ARRAY_SIZE(dcufb->fsl_dcu_info); i++) {
+		uninstall_framebuffer(dcufb->fsl_dcu_info[i]);
+		framebuffer_release(dcufb->fsl_dcu_info[i]);
+	}
+
+	return 0;
+}
+
+static int fsl_dcu_setup(void)
+{
+#ifndef MODULE
+	char *opt, *options = NULL;
+	unsigned long val;
+
+	if (fb_get_options("fslfb", &options))
+		return -ENODEV;
+
+	if (!options || !*options)
+		return 0;
+
+	while ((opt = strsep(&options, ",")) != NULL) {
+		if (!*opt)
+			continue;
+		if (!strncmp(opt, "bpp=", 4)) {
+			if (!strict_strtoul(opt + 4, 10, &val))
+				default_bpp = val;
+		} else {
+			fb_mode = opt;
+		}
+	}
+#endif
+	return 0;
+}
+
+static struct of_device_id fsl_dcu_dt_ids[] = {
+	{
+		.compatible = "fsl,vf610-dcu",
+	},
+	{}
+};
+
+static struct platform_driver fsl_dcu_driver = {
+	.driver = {
+		.name = DRIVER_NAME,
+		.owner = THIS_MODULE,
+		.of_match_table = fsl_dcu_dt_ids,
+	},
+	.probe = fsl_dcu_probe,
+	.remove = fsl_dcu_remove,
+	.suspend = fsl_dcu_suspend,
+	.resume = fsl_dcu_resume,
+};
+
+static int __init fsl_dcu_init(void)
+{
+	int ret = fsl_dcu_setup();
+
+	if (ret < 0)
+		return ret;
+
+	return platform_driver_register(&fsl_dcu_driver);
+}
+
+static void __exit fsl_dcu_exit(void)
+{
+	platform_driver_unregister(&fsl_dcu_driver);
+}
+
+module_init(fsl_dcu_init);
+module_exit(fsl_dcu_exit);
+
+MODULE_AUTHOR("Alison Wang");
+MODULE_DESCRIPTION("Freescale DCU framebuffer driver");
+MODULE_LICENSE("GPL v2");
-- 
1.8.0




From b18965 at freescale.com  Fri Jul 12 02:07:56 2013
From: b18965 at freescale.com (Alison Wang)
Date: Fri, 12 Jul 2013 14:07:56 +0800
Subject: [PATCH 5/5] Documentation: DT: Add DCU framebuffer driver
In-Reply-To: <1373609276-14566-1-git-send-email-b18965@freescale.com>
References: <1373609276-14566-1-git-send-email-b18965@freescale.com>
Message-ID: <1373609276-14566-6-git-send-email-b18965@freescale.com>

This patch adds the document for DCU framebuffer driver under
Documentation/devicetree/bindings/fb/.

Signed-off-by: Alison Wang <b18965 at freescale.com>
---
Changes in v2: New
- Add this document for DCU framebuffer driver.

 .../devicetree/bindings/fb/fsl-dcu-fb.txt          | 36 ++++++++++++++++++++++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fb/fsl-dcu-fb.txt

diff --git a/Documentation/devicetree/bindings/fb/fsl-dcu-fb.txt b/Documentation/devicetree/bindings/fb/fsl-dcu-fb.txt
new file mode 100644
index 0000000..231bda7
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/fsl-dcu-fb.txt
@@ -0,0 +1,36 @@
+* Freescale Display Control Unit (DCU)
+
+Required properties:
+- compatible: Should be "fsl,vf610-dcu". Supported chips include
+  Vybrid VF610.
+- reg: Address and length of the register set for DCU.
+- interrupts: Should contain DCU interrupts.
+- clocks: From common clock binding: handle to DCU clock.
+- clock-names: From common clock binding: Shall be "dcu".
+- tcon-controller: The phandle of TCON controller.
+
+For the DCU initialization, we read data from TCON node.
+Required properties for TCON:
+- compatible: Should be "fsl,vf610-tcon". Supported chips include
+  Vybrid VF610.
+- reg: Address and length of the register set for TCON.
+- clocks: From common clock binding: handle to TCON clock.
+- clock-names: From common clock binding: Shall be "tcon".
+
+Examples:
+
+dcu0: dcu at 40058000 {
+	compatible = "fsl,vf610-dcu";
+	reg = <0x40058000 0x1200>;
+	interrupts = <0 30 0x04>;
+	clocks = <&clks VF610_CLK_DCU0>;
+	clock-names = "dcu";
+	tcon-controller = <&tcon0>;
+};
+
+tcon0: tcon at 4003d000 {
+	compatible = "fsl,vf610-tcon";
+	reg = <0x4003d000 0x1000>;
+	clocks = <&clks VF610_CLK_TCON0>;
+	clock-names = "tcon";
+};
-- 
1.8.0




From shawn.guo at linaro.org  Fri Jul 12 03:01:32 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Jul 2013 15:01:32 +0800
Subject: [v5 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <1373533831-9500-4-git-send-email-Hong-Xing.Zhu@freescale.com>
References: <1373533831-9500-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373533831-9500-4-git-send-email-Hong-Xing.Zhu@freescale.com>
Message-ID: <20130712070130.GC25501@S2101-09.ap.freescale.net>

On Thu, Jul 11, 2013 at 05:10:31PM +0800, Richard Zhu wrote:
> From: Richard Zhu <r65037 at freescale.com>
> 
> imx6q contains one Synopsys AHCI SATA controller,
> But it can't shares ahci_platform driver with other
> controllers.
> Because there are some misalignments of the generic
> AHCI controller.
> The bits definitions of the HBA registers, the Vendor
> Specific registers, the AHCI PHY clock and the AHCI
> signals adjustment window(GPR13 Reg).
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>  value is '0', should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the
>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>  should be configured regarding to the frequency of AHB
>  bus clock.
>  - Configurations of the AHCI PHY clock, and the signal
>  parameters of the GPR13
> 
> Setup its own ahci sata driver, contained the imx6q specific
> initialized codes, re-use the generic ahci_platform drier, and

s/drier/driver

> keep the generic ahci_platform driver clean as much as possible.
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  drivers/ata/Kconfig    |    9 ++
>  drivers/ata/Makefile   |    1 +
>  drivers/ata/sata_imx.c |  233 ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 243 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/ata/sata_imx.c
> 
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index a5a3ebc..275dc2c 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -97,6 +97,15 @@ config SATA_AHCI_PLATFORM
>  
>  	  If unsure, say N.
>  
> +config SATA_IMX
> +	tristate "Freescale i.MX AHCI SATA support"
> +	depends on SATA_AHCI_PLATFORM
> +	help
> +	  This option enables support for the Freescale i.MX SoC's
> +	  onboard AHCI SATA.
> +
> +	  If unsure, say N.
> +
>  config SATA_FSL
>  	tristate "Freescale 3.0Gbps SATA support"
>  	depends on FSL_SOC
> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
> index c04d0fd..04b1c6c 100644
> --- a/drivers/ata/Makefile
> +++ b/drivers/ata/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_SATA_INIC162X)	+= sata_inic162x.o
>  obj-$(CONFIG_SATA_SIL24)	+= sata_sil24.o
>  obj-$(CONFIG_SATA_DWC)		+= sata_dwc_460ex.o
>  obj-$(CONFIG_SATA_HIGHBANK)	+= sata_highbank.o libahci.o
> +obj-$(CONFIG_SATA_IMX)		+= sata_imx.o
>  
>  # SFF w/ custom DMA
>  obj-$(CONFIG_PDC_ADMA)		+= pdc_adma.o
> diff --git a/drivers/ata/sata_imx.c b/drivers/ata/sata_imx.c
> new file mode 100644
> index 0000000..de6330e
> --- /dev/null
> +++ b/drivers/ata/sata_imx.c
> @@ -0,0 +1,233 @@
> +/*
> + * Freescale IMX AHCI SATA platform driver
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * based on the AHCI SATA platform driver by Jeff Garzik and Anton Vorontsov
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/ahci_platform.h>
> +#include <linux/of_device.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
> +#include "ahci.h"
> +
> +enum {
> +	HOST_TIMER1MS = 0xe0, /* Timer 1-ms */
> +};
> +
> +struct imx_ahci_priv {
> +	struct platform_device *imx_ahci_pdev;
> +	struct clk *sata_ref_clk;
> +	struct regmap *gpr;
> +};
> +
> +/* imx6q ahci module initialization. */
> +static int imx6q_sata_init(struct device *dev, void __iomem *mmio)
> +{
> +	int ret = 0;
> +	unsigned int rc;

The variable name is confusing. "rc" generally means return code.

> +	struct clk *ahb_clk;
> +	struct device *p_dev = dev->parent;
> +	struct imx_ahci_priv *imxpriv =  dev_get_drvdata(p_dev);

I would go dev_get_drvdata(dev->parent), since dev->parent is even more
readable than p_dev.

> +
> +	imxpriv->gpr =
> +		syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +	if (IS_ERR(imxpriv->gpr)) {
> +		dev_err(dev, "failed to find fsl,imx6q-iomux-gpr regmap\n");
> +		return PTR_ERR(imxpriv->gpr);
> +	}

Move it into imx_ahci_probe().

> +
> +	imxpriv->sata_ref_clk = devm_clk_get(dev, "sata_ref");
> +	if (IS_ERR(imxpriv->sata_ref_clk)) {
> +		dev_err(dev, "can't get sata_ref clock.\n");
> +		return PTR_ERR(imxpriv->sata_ref_clk);
> +	}

Ditto

> +
> +	ret = clk_prepare_enable(imxpriv->sata_ref_clk);
> +	if (ret < 0) {
> +		dev_err(dev, "prepare-enable sata_ref clock err:%d\n", ret);
> +		return ret;
> +	}
> +
> +	/*
> +	 * set PHY Paremeters, two steps to configure the GPR13,
> +	 * one write for rest of parameters, mask of first write
> +	 * is 0x07fffffd, and the other one write for setting
> +	 * the mpll_clk_en.
> +	 */
> +	regmap_update_bits(imxpriv->gpr, 0x34, IMX6Q_GPR13_SATA_RX_EQ_VAL_MASK
> +			| IMX6Q_GPR13_SATA_RX_LOS_LVL_MASK
> +			| IMX6Q_GPR13_SATA_RX_DPLL_MODE_MASK
> +			| IMX6Q_GPR13_SATA_SPD_MODE_MASK
> +			| IMX6Q_GPR13_SATA_MPLL_SS_EN
> +			| IMX6Q_GPR13_SATA_TX_ATTEN_MASK
> +			| IMX6Q_GPR13_SATA_TX_BOOST_MASK
> +			| IMX6Q_GPR13_SATA_TX_LVL_MASK
> +			| IMX6Q_GPR13_SATA_TX_EDGE_RATE
> +			, IMX6Q_GPR13_SATA_RX_EQ_VAL_3_0_DB
> +			| IMX6Q_GPR13_SATA_RX_LOS_LVL_SATA2M
> +			| IMX6Q_GPR13_SATA_RX_DPLL_MODE_2P_4F
> +			| IMX6Q_GPR13_SATA_SPD_MODE_3P0G
> +			| IMX6Q_GPR13_SATA_MPLL_SS_EN
> +			| IMX6Q_GPR13_SATA_TX_ATTEN_9_16
> +			| IMX6Q_GPR13_SATA_TX_BOOST_3_33_DB
> +			| IMX6Q_GPR13_SATA_TX_LVL_1_025_V);
> +	regmap_update_bits(imxpriv->gpr, 0x34, IMX6Q_GPR13_SATA_MPLL_CLK_EN,
> +			IMX6Q_GPR13_SATA_MPLL_CLK_EN);
> +	usleep_range(100, 200);
> +
> +	/*
> +	 * Configure the HWINIT bits of the HOST_CAP and HOST_PORTS_IMPL,
> +	 * and IP vendor specific register HOST_TIMER1MS.
> +	 *
> +	 * Configure CAP_SSS (support stagered spin up).
> +	 * Implement the port0.
> +	 * Get the ahb clock rate, and configure the TIMER1MS register.
> +	 */
> +	rc = readl(mmio + HOST_CAP);
> +	if (!(rc & HOST_CAP_SSS)) {
> +		rc |= HOST_CAP_SSS;
> +		writel(rc, mmio + HOST_CAP);
> +	}
> +	rc = readl(mmio + HOST_PORTS_IMPL);
> +	if (!(rc & 0x1)) {
> +		rc |= 0x1;
> +		writel(rc, mmio + HOST_PORTS_IMPL);
> +	}
> +
> +	ahb_clk = devm_clk_get(dev, "ahb");

If you need to get ahb clock, please specify it in your DTS node.  Right
now, you only have the following two clocks in the DTS.

	clocks = <&clks 154>, <&clks 187>;
	clock-names = "sata", "sata_ref";

You code happens to work because of the following call in clk-imx6q.c.

	clk_register_clkdev(clk[ahb], "ahb", NULL);

But you shouldn't reply on that.  With all users moved to looking up
clocks from device tree, we would remove it from clock driver.

Also, please have a clk pointer in imx_ahci_priv and call devm_clk_get()
in imx_ahci_probe().

> +	if (IS_ERR(ahb_clk)) {
> +		dev_err(dev, "no ahb clock.\n");
> +		clk_disable_unprepare(imxpriv->sata_ref_clk);
> +		devm_clk_put(dev, imxpriv->sata_ref_clk);
> +		return PTR_ERR(ahb_clk);
> +	}
> +	rc = clk_get_rate(ahb_clk) / 1000;
> +	writel(rc, mmio + HOST_TIMER1MS);
> +	devm_clk_put(dev, ahb_clk);
> +
> +	return 0;
> +}
> +
> +static void imx6q_sata_exit(struct device *dev)
> +{
> +	struct device *p_dev = dev->parent;
> +	struct imx_ahci_priv *imxpriv =  dev_get_drvdata(p_dev);

dev_get_drvdata(dev->parent);

> +
> +	regmap_update_bits(imxpriv->gpr, 0x34, IMX6Q_GPR13_SATA_MPLL_CLK_EN,
> +			!IMX6Q_GPR13_SATA_MPLL_CLK_EN);
> +	clk_disable_unprepare(imxpriv->sata_ref_clk);
> +}
> +
> +static struct ahci_platform_data imx6q_sata_pdata = {
> +	.init = imx6q_sata_init,
> +	.exit = imx6q_sata_exit,
> +};

Put a blank line here.

> +static const struct of_device_id imx_ahci_of_match[] = {
> +	{ .compatible = "fsl,imx6q-ahci", .data = &imx6q_sata_pdata},
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, imx_ahci_of_match);
> +
> +static void imx_ahci_platform_release(struct device *dev)
> +{
> +	return;
> +}

Is this empty function mandatory?

> +
> +static int imx_ahci_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct resource *mem, *irq, res[2];
> +	const struct of_device_id *of_id;
> +	const struct ahci_platform_data *pdata = NULL;
> +	struct imx_ahci_priv *imxpriv;
> +	int ret;
> +
I would drop this blank line and move the following two line above
"int ret;".

> +	struct device *imx_dev;
> +	struct platform_device *imx_ahci_pdev;

These two variable names are confusing.  I would name them ahci_dev and
ahci_pdev, as they are all about generic "ahci" rather than imx specific
one.

> +
> +	imx_ahci_pdev = platform_device_alloc("ahci", -1);
> +	if (!imx_ahci_pdev)
> +		return -ENODEV;
> +
> +	imx_dev = &imx_ahci_pdev->dev;
> +	imx_dev->release = imx_ahci_platform_release;
> +	imx_dev->parent = dev;
> +
> +	imxpriv = devm_kzalloc(dev, sizeof(*imxpriv), GFP_KERNEL);
> +	if (!imxpriv) {
> +		dev_err(dev, "can't alloc ahci_host_priv\n");
> +		return -ENOMEM;
> +	}
> +
> +	imxpriv->imx_ahci_pdev = imx_ahci_pdev;

So imx_ahci_pdev in imx_ahci_priv is also confusing.

> +	platform_set_drvdata(pdev, imxpriv);
> +
> +	of_id = of_match_device(imx_ahci_of_match, dev);
> +	if (of_id)
> +		pdata = of_id->data;
> +	else
> +		return -EINVAL;
> +
> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +	if (!mem || !irq) {
> +		dev_err(dev, "no mmio/irq resource\n");
> +		return -EINVAL;
> +	}
> +
> +	res[0] = *mem;
> +	res[1] = *irq;
> +
> +	imx_dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +	imx_dev->dma_mask = &imx_dev->coherent_dma_mask;
> +	imx_dev->of_node = dev->of_node;
> +
> +	platform_device_add_resources(imx_ahci_pdev, res, 2);
> +	platform_device_add_data(imx_ahci_pdev, pdata, sizeof(*pdata));
> +
> +	ret = platform_device_add(imx_ahci_pdev);
> +
> +	return ret;

Can just be return platform_device_add(imx_ahci_pdev);

Shawn

> +}
> +
> +static int imx_ahci_remove(struct platform_device *pdev)
> +{
> +	struct imx_ahci_priv *imxpriv = platform_get_drvdata(pdev);
> +	struct platform_device *imx_ahci_pdev = imxpriv->imx_ahci_pdev;
> +
> +	platform_device_unregister(imx_ahci_pdev);
> +	return 0;
> +}
> +
> +static struct platform_driver imx_ahci_driver = {
> +	.probe = imx_ahci_probe,
> +	.remove = imx_ahci_remove,
> +	.driver = {
> +		.name = "sata-imx",
> +		.owner = THIS_MODULE,
> +		.of_match_table = imx_ahci_of_match,
> +	},
> +};
> +module_platform_driver(imx_ahci_driver);
> +
> +MODULE_DESCRIPTION("Freescale i.MX AHCI SATA platform driver");
> +MODULE_AUTHOR("Richard Zhu <Hong-Xing.Zhu at freescale.com>");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("sata:imx");
> -- 
> 1.7.5.4
> 



From oleksandr.kozaruk at ti.com  Fri Jul 12 03:18:00 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Fri, 12 Jul 2013 10:18:00 +0300
Subject: [PATCH v3 0/2] TWL6030, TWL6032 GPADC driver
Message-ID: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>

Hello,

v3 - fixed compiler warning
v2 - the driver put in drivers/iio, and
converted using iio facilities as suggested by Graeme.

TWL603[02] GPADC is used to measure battery voltage,
battery temperature, battery presence ID, and could
be used to measure twl603[02] die temperature.
This is used on TI blaze, blaze tablet platforms.

The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19
channels respectively. Some channels have current
source and are used for measuring voltage drop
on resistive load for detecting battery ID resistance,
or measuring voltage drop on NTC resistors for external
temperature measurements, other channels measure voltage,
(i.e. battery voltage), and have inbuilt voltage dividers,
thus, capable to scale voltage. Some channels are dedicated
for measuring die temperature.

Some channels could be calibrated in 2 points, having
offsets from ideal values in trim registers.

The difference between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i. e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

The driver exports function returning converted value for
requested channels.

Sysfs entries are added to start and read conversion result
in millivolts for chosen channel.

The driver is derived from git://git.omapzoom.org/kernel/omap.git
The original driver's authors and contributors are Balaji T K,
Graeme Gregory, Ambresh K, Girish S Ghongdemath.

The changes to the original driver:
- device tree adaptation;
- drop ioctl support - never been used;
- unified measurement method for both devices;
- get rid of "if (device == X)" code style to data driven;
- drop polling end of conversion and use interrupt instead;
- iio framework is used

Tested with on blaze tablet 2 with OMAP4430(twl6030), and
OMAP4470(twl6032) SOMs.

The patches were tested against 3.10-rc7

Oleksandr Kozaruk (2):
  ARM: dts: twl: Add GPADC data to device tree
  iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

 arch/arm/boot/dts/twl6030.dtsi  |    6 +
 drivers/iio/adc/Kconfig         |    8 +
 drivers/iio/adc/Makefile        |    1 +
 drivers/iio/adc/twl6030-gpadc.c | 1019 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 1034 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

-- 
1.7.9.5



From oleksandr.kozaruk at ti.com  Fri Jul 12 03:18:02 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Fri, 12 Jul 2013 10:18:02 +0300
Subject: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1373613482-28390-3-git-send-email-oleksandr.kozaruk@ti.com>

The GPADC is general purpose ADC found on TWL6030,
and TWL6032 PMIC, known also as Phoenix and PhoenixLite.

The TWL6030 and TWL6032 have GPADC with 17 and 19
channels respectively. Some channels have current
source and are used for measuring voltage drop
on resistive load for detecting battery ID resistance,
or measuring voltage drop on NTC resistors for external
temperature measurements. Some channels measure voltage,
(i.e. battery voltage), and have voltage dividers,
thus, capable to scale voltage. Some channels are dedicated
for measuring die temperature.

Some channels are calibrated in 2 points, having
offsets from ideal values kept in trim registers. This
is used to correct measurements.

The differences between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i. e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

The driver exports function returning converted value for
requested channels.

Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
Girish S Ghongdemath.

Signed-off-by: Balaji T K <balajitk at ti.com>
Graeme Gregory <gg at slimlogic.co.uk>
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 drivers/iio/adc/Kconfig         |    8 +
 drivers/iio/adc/Makefile        |    1 +
 drivers/iio/adc/twl6030-gpadc.c | 1019 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 1028 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index ab0767e6..87d699e 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -157,4 +157,12 @@ config VIPERBOARD_ADC
 	  Say yes here to access the ADC part of the Nano River
 	  Technologies Viperboard.
 
+config TWL6030_GPADC
+	tristate "TWL6030 GPADC (General Purpose A/D Convertor) Support"
+	depends on TWL4030_CORE
+	default n
+	help
+	  Say yes here if you want support for the TWL6030 General Purpose
+	  A/D Convertor.
+
 endmenu
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 0a825be..8b05633 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
 obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
 obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
+obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
new file mode 100644
index 0000000..6ceb789
--- /dev/null
+++ b/drivers/iio/adc/twl6030-gpadc.c
@@ -0,0 +1,1019 @@
+/*
+ * TWL6030 GPADC module driver
+ *
+ * Copyright (C) 2009-2013 Texas Instruments Inc.
+ * Nishant Kamat <nskamat at ti.com>
+ * Balaji T K <balajitk at ti.com>
+ * Graeme Gregory <gg at slimlogic.co.uk>
+ * Girish S Ghongdemath <girishsg at ti.com>
+ * Ambresh K <ambresh at ti.com>
+ * Oleksandr Kozaruk <oleksandr.kozaruk at ti.com
+ *
+ * Based on twl4030-madc.c
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen <mikko.k.ylinen at nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of_platform.h>
+#include <linux/i2c/twl.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define DRIVER_NAME		"twl6030_gpadc"
+
+#define TWL6030_GPADC_MAX_CHANNELS 17
+#define TWL6032_GPADC_MAX_CHANNELS 19
+/* Define this as the biggest of all chips using this driver */
+#define GPADC_MAX_CHANNELS TWL6032_GPADC_MAX_CHANNELS
+
+#define TWL6030_GPADC_CTRL			0x00    /* 0x2e */
+#define TWL6030_GPADC_CTRL2			0x01	/* 0x2f */
+
+#define TWL6030_GPADC_CTRL_P1			0x05
+#define TWL6030_GPADC_CTRL_P2			0x06
+
+#define TWL6032_GPADC_GPSELECT_ISB		0x07
+#define TWL6032_GPADC_CTRL_P1			0x08
+
+#define TWL6032_GPADC_RTCH0_LSB			0x09
+#define TWL6032_GPADC_RTCH0_MSB			0x0a
+#define TWL6032_GPADC_RTCH1_LSB			0x0b
+#define TWL6032_GPADC_RTCH1_MSB			0x0c
+#define TWL6032_GPADC_GPCH0_LSB			0x0d
+#define TWL6032_GPADC_GPCH0_MSB			0x0e
+
+#define TWL6030_GPADC_CTRL_P1_SP1		BIT(3)
+#define TWL6030_GPADC_CTRL_P1_EOCRT		BIT(2)
+#define TWL6030_GPADC_CTRL_P1_EOCP1		BIT(1)
+#define TWL6030_GPADC_CTRL_P1_BUSY		BIT(0)
+
+#define TWL6030_GPADC_CTRL_P2_SP2		BIT(2)
+#define TWL6030_GPADC_CTRL_P2_EOCP2		BIT(1)
+#define TWL6030_GPADC_CTRL_P1_BUSY		BIT(0)
+
+#define TWL6030_GPADC_EOC_SW			BIT(1)
+#define TWL6030_GPADC_BUSY			BIT(0)
+
+#define TWL6030_GPADC_RTCH0_LSB			(0x07)
+#define TWL6030_GPADC_GPCH0_LSB			(0x29)
+
+/* Fixed channels */
+#define TWL6030_GPADC_CTRL_TEMP1_EN		BIT(0)    /* input ch 1 */
+#define TWL6030_GPADC_CTRL_TEMP2_EN		BIT(1)    /* input ch 4 */
+#define TWL6030_GPADC_CTRL_SCALER_EN		BIT(2)    /* input ch 2 */
+#define TWL6030_GPADC_CTRL_SCALER_DIV4		BIT(3)
+#define TWL6030_GPADC_CTRL_SCALER_EN_CH11	BIT(4)    /* input ch 11 */
+#define TWL6030_GPADC_CTRL_TEMP1_EN_MONITOR	BIT(5)
+#define TWL6030_GPADC_CTRL_TEMP2_EN_MONITOR	BIT(6)
+#define TWL6030_GPADC_CTRL_ISOURCE_EN		BIT(7)
+
+#define TWL6030_GPADC_CTRL2_REMSENSE_0		BIT(0)
+#define TWL6030_GPADC_CTRL2_REMSENSE_1		BIT(1)
+#define TWL6030_GPADC_CTRL2_SCALER_EN_CH18	BIT(2)
+#define TWL6030_GPADC_CTRL2_VBAT_SCALER_DIV4	BIT(3)
+
+#define TWL6030_GPADC_RT_SW1_EOC_MASK		BIT(5)
+#define TWL6030_GPADC_SW2_EOC_MASK		BIT(6)
+
+#define TWL6032_GPADC_RT_EOC_MASK		BIT(4)
+#define TWL6032_GPADC_SW_EOC_MASK		BIT(5)
+
+#define TWL6030_GPADC_TRIM1			0xCD
+
+#define TWL6030_REG_TOGGLE1			0x90
+#define TWL6030_GPADCS				BIT(1)
+#define TWL6030_GPADCR				BIT(0)
+
+/**
+ * struct twl6030_chnl_calib - channel calibration
+ * @gain:		slope coefficient for ideal curve
+ * @gain_error:		gain error
+ * @offset_error:	offset of the real curve
+ */
+struct twl6030_chnl_calib {
+	s32 gain;
+	s32 gain_error;
+	s32 offset_error;
+};
+
+/**
+ * struct twl6030_ideal_code - GPADC calibration parameters
+ * GPADC is calibrated in two points: close to the beginning and
+ * to the and of the measurable input range
+ *
+ * @code1:	ideal code for the input at the beginning
+ * @code2:	ideal code for at the end of the range
+ * @v1:		voltage input at the beginning(low voltage)
+ * @v2:		voltage input at the end(high voltage)
+ */
+struct twl6030_ideal_code {
+	u16 code1;
+	u16 code2;
+	u16 v1;
+	u16 v2;
+};
+
+struct twl6030_gpadc_data;
+
+/**
+ * struct twl6030_gpadc_platform_data - platform specific data
+ * @nchannels:		number of GPADC channels
+ * @iio_channels:	iio channels
+ * @twl6030_ideal:	pointer to calibration parameters
+ * @start_conversion:	pointer to ADC start conversion function
+ * @channel_to_reg	pointer to ADC function to convert channel to
+ * 			register address for reading conversion result
+ * @calibrate:		pointer to calibration function
+ */
+struct twl6030_gpadc_platform_data {
+	const int nchannels;
+	const struct iio_chan_spec *iio_channels;
+	const struct twl6030_ideal_code *ideal;
+	int (*start_conversion)(int channel);
+	u8 (*channel_to_reg)(int channel);
+	int (*calibrate)(struct twl6030_gpadc_data *gpadc);
+};
+
+/**
+ * struct twl6030_gpadc_data - GPADC data
+ * @dev:		device pointer
+ * @lock:		mutual exclusion lock for the structure
+ * @irq_complete:	completion to signal end of conversion
+ * @twl6030_cal_tbl:	pointer to calibration data for each
+ * 			channel with gain error and offset
+ * @pdata:		pointer to device specific data
+ */
+struct twl6030_gpadc_data {
+	struct device	*dev;
+	struct mutex	lock;
+	struct completion	irq_complete;
+	struct twl6030_chnl_calib	*twl6030_cal_tbl;
+	const struct twl6030_gpadc_platform_data *pdata;
+};
+
+/*
+ * channels 11, 12, 13, 15 and 16 have no calibration data
+ * calibration offset is same for channels 1, 3, 4, 5
+ *
+ * The data is taken from GPADC_TRIM registers description.
+ * GPADC_TRIM registers keeps difference between the code measured
+ * at v1 and v2 input voltages and corresponding code1 and code2
+ */
+static const struct twl6030_ideal_code
+	twl6030_ideal[TWL6030_GPADC_MAX_CHANNELS] = {
+	{ /* ch 0, external, battery type, resistor value */
+		.code1 = 116,
+		.code2 = 745,
+		.v1 = 141,
+		.v2 = 910,
+	},
+	{ /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 82,
+		.code2 = 900,
+		.v1 = 100,
+		.v2 = 1100,
+	},
+	{ /* ch 2, external, audio accessory/general purpose */
+		.code1 = 55,
+		.code2 = 818,
+		.v1 = 101,
+		.v2 = 1499,
+	},
+	{ /* ch 3, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.v1 = 100,
+		.v2 = 1100,
+	},
+	{ /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.v1 = 100,
+		.v2 = 1100,
+	},
+	{ /* ch 5, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.v1 = 100,
+		.v2 = 1100,
+	},
+	{ /* ch 6, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.v1 = 100,
+		.v2 = 1100,
+	},
+	{ /* ch 7, internal, main battery */
+		.code1 = 614,
+		.code2 = 941,
+		.v1 = 3001,
+		.v2 = 4599,
+	},
+	{ /* ch 8, internal, backup battery */
+		.code1 = 82,
+		.code2 = 688,
+		.v1 = 501,
+		.v2 = 4203,
+	},
+	{ /* ch 9, internal, external charger input */
+		.code1 = 182,
+		.code2 = 818,
+		.v1 = 2001,
+		.v2 = 8996,
+	},
+	{ /* ch 10, internal, VBUS */
+		.code1 = 149,
+		.code2 = 818,
+		.v1 = 1001,
+		.v2 = 5497,
+	},
+	{},	/* ch 11, internal, VBUS charging current */
+	{},	/* ch 12, internal, Die temperature */
+	{},	/* ch 13, internal, Die temperature */
+	{ /* ch 14, internal, USB ID line */
+		.code1 = 48,
+		.code2 = 714,
+		.v1 = 323,
+		.v2 = 4800,
+	},
+	{},	/* ch 15, internal, test network */
+	{},	/* ch 16, internal, test network */
+};
+
+static const struct twl6030_ideal_code
+			twl6032_ideal[TWL6032_GPADC_MAX_CHANNELS] = {
+	{ /* ch 0, external, battery type, resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch 2, external, audio accessory/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 660,
+		.v2 = 1500,
+	},
+	{ /* ch 3, external, temperature with external diode/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch 5, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch 6, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch7, internal, system supply */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 2200,
+		.v2 = 5000,
+	},
+	{ /* ch8, internal, backup battery */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 2200,
+		.v2 = 5000,
+	},
+	{ /* ch 9, internal, external charger input */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 3960,
+		.v2 = 9000,
+	},
+	{ /* ch10, internal, VBUS */
+		.code1 = 150,
+		.code2 = 751,
+		.v1 = 1000,
+		.v2 = 5000,
+	},
+	{ /* ch 11, internal, VBUS DC-DC output current */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 660,
+		.v2 = 1500,
+	},
+	{ /* ch 12, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch 13, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 440,
+		.v2 = 1000,
+	},
+	{ /* ch 14, internal, USB ID line */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 2420,
+		.v2 = 5500,
+	},
+	{},	/* ch 15, internal, test network */
+	{},	/* ch 16, internal, test network */
+	{},	/* ch 17, internal, battery charging current */
+	{ /* ch 18, internal, battery voltage */
+		.code1 = 1441,
+		.code2 = 3276,
+		.v1 = 2200,
+		.v2 = 5000,
+	},
+};
+
+static inline int twl6030_gpadc_write(u8 reg, u8 val)
+{
+	return twl_i2c_write_u8(TWL6030_MODULE_GPADC, val, reg);
+}
+
+static inline int twl6030_gpadc_read(u8 *val, u8 reg)
+{
+
+	return twl_i2c_read(TWL6030_MODULE_GPADC, val, reg, 2);
+}
+
+static int twl6030_gpadc_enable_irq(u8 mask)
+{
+	int ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_LINE_B);
+	ret |= twl6030_interrupt_unmask(mask, REG_INT_MSK_STS_B);
+
+	return ret;
+}
+
+static void twl6030_gpadc_disable_irq(u8 mask)
+{
+	twl6030_interrupt_mask(mask, REG_INT_MSK_LINE_B);
+	twl6030_interrupt_mask(mask, REG_INT_MSK_STS_B);
+}
+
+static irqreturn_t twl6030_gpadc_irq_handler(int irq, void *_gpadc)
+{
+	struct twl6030_gpadc_data *gpadc = _gpadc;
+
+	complete(&gpadc->irq_complete);
+
+	return IRQ_HANDLED;
+}
+
+static int twl6030_start_conversion(int channel)
+{
+	return twl6030_gpadc_write(TWL6030_GPADC_CTRL_P1,
+					TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static int twl6032_start_conversion(int channel)
+{
+	int ret;
+
+	ret = twl6030_gpadc_write(TWL6032_GPADC_GPSELECT_ISB, channel);
+	if (ret)
+		return ret;
+
+	return twl6030_gpadc_write(TWL6032_GPADC_CTRL_P1,
+						TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static u8 twl6030_channel_to_reg(int channel)
+{
+	return TWL6030_GPADC_GPCH0_LSB + 2 * channel;
+}
+
+static u8 twl6032_channel_to_reg(int channel)
+{
+	return TWL6032_GPADC_GPCH0_LSB;
+}
+
+static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
+		int channel, int *res)
+{
+	u8 reg = gpadc->pdata->channel_to_reg(channel);
+	u8 val[2];
+	int ret;
+
+	ret = twl6030_gpadc_read(val, reg);
+	if (ret) {
+		dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
+		return ret;
+	}
+
+	*res = (val[1] << 8) | val[0];
+
+	return ret;
+}
+
+static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
+		int channel, int *val)
+{
+	int raw_code;
+	int corrected_code;
+	int channel_value;
+	int ret;
+
+	ret = twl6030_gpadc_get_raw(gpadc, channel, &raw_code);
+	if (ret)
+		return ret;
+
+	corrected_code = ((raw_code * 1000) -
+		gpadc->twl6030_cal_tbl[channel].offset_error) /
+		gpadc->twl6030_cal_tbl[channel].gain_error;
+
+	channel_value = corrected_code *
+			gpadc->twl6030_cal_tbl[channel].gain;
+
+	/* Shift back into mV range */
+	channel_value /= 1000;
+
+	dev_dbg(gpadc->dev, "GPADC raw: %d", raw_code);
+	dev_dbg(gpadc->dev, "GPADC cor: %d", corrected_code);
+	dev_dbg(gpadc->dev, "GPADC val: %d", channel_value);
+
+	*val = channel_value;
+
+	return ret;
+}
+
+static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
+			     const struct iio_chan_spec *chan,
+			     int *val, int *val2, long mask)
+{
+	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
+	int ret = -EINVAL;
+
+	mutex_lock(&gpadc->lock);
+
+	ret = gpadc->pdata->start_conversion(chan->channel);
+	if (ret) {
+		dev_err(gpadc->dev, "failed to start conversion\n");
+		goto err;
+	}
+	/* wait for conversion to complete */
+	wait_for_completion_interruptible_timeout(&gpadc->irq_complete,
+						msecs_to_jiffies(5000));
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	case IIO_CHAN_INFO_PROCESSED:
+		ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	default:
+		break;
+	}
+err:
+	mutex_unlock(&gpadc->lock);
+
+	return ret;
+}
+
+static void twl6030_calibrate_channel(struct twl6030_gpadc_data *gpadc,
+					int channel, int d1, int d2)
+{
+	int b, k, gain, x1, x2;
+	const struct twl6030_ideal_code *ideal = gpadc->pdata->ideal;
+
+	/* Gain */
+	gain = ((ideal[channel].v2 - ideal[channel].v1) * 1000) /
+		(ideal[channel].code2 - ideal[channel].code1);
+
+	x1 = ideal[channel].code1;
+	x2 = ideal[channel].code2;
+
+	/* k */
+	k = 1000 + (((d2 - d1) * 1000) / (x2 - x1));
+
+	/* b */
+	b = (d1 * 1000) - (k - 1000) * x1;
+
+	gpadc->twl6030_cal_tbl[channel].gain = gain;
+	gpadc->twl6030_cal_tbl[channel].gain_error = k;
+	gpadc->twl6030_cal_tbl[channel].offset_error = b;
+
+	dev_dbg(gpadc->dev, "GPADC d1   for Chn: %d = %d\n", channel, d1);
+	dev_dbg(gpadc->dev, "GPADC d2   for Chn: %d = %d\n", channel, d2);
+	dev_dbg(gpadc->dev, "GPADC x1   for Chn: %d = %d\n", channel, x1);
+	dev_dbg(gpadc->dev, "GPADC x2   for Chn: %d = %d\n", channel, x2);
+	dev_dbg(gpadc->dev, "GPADC Gain for Chn: %d = %d\n", channel, gain);
+	dev_dbg(gpadc->dev, "GPADC k    for Chn: %d = %d\n", channel, k);
+	dev_dbg(gpadc->dev, "GPADC b    for Chn: %d = %d\n", channel, b);
+}
+
+static inline int twl6030_gpadc_get_trim_offset(s8 d)
+{
+	int sign;
+
+	/*
+	 * XXX NOTE!
+	 * bit 0 - sign, bit 7 - reserved, 6..1 - trim value
+	 * though, the documentation states that trim value
+	 * is absolute value, the correct conversion results are
+	 * obtained if the value is interpreted as 2's complement.
+	 */
+	sign = d & 1;
+	d = (d & 0x7f) >> 1;
+
+	return sign ? (d | 0xc0) : d;
+}
+
+static int twl6030_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int ret;
+	int chn;
+	u8 trim_regs[TWL6030_GPADC_MAX_CHANNELS];
+	s8 d1, d2;
+
+	/*
+	 * for calibration two measurements have been performed at
+	 * factory, for some channels, during the production test and
+	 * have been stored in registers. This two stored values are
+	 * used to correct the measurements. The values represent
+	 * offsets for the given input from the output on ideal curve.
+	 */
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs,
+			TWL6030_GPADC_TRIM1, 16);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	for (chn = 0; chn < TWL6030_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+			d1 = trim_regs[0];
+			d2 = trim_regs[1];
+			break;
+		case 1:
+			d1 = trim_regs[4];
+			d2 = trim_regs[5];
+			break;
+		case 2:
+			d1 = trim_regs[12];
+			d2 = trim_regs[13];
+			break;
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+			d1 = trim_regs[4];
+			d2 = trim_regs[5];
+			break;
+		case 7:
+			d1 = trim_regs[6];
+			d2 = trim_regs[7];
+			break;
+		case 8:
+			d1 = trim_regs[2];
+			d2 = trim_regs[3];
+			break;
+		case 9:
+			d1 = trim_regs[8];
+			d2 = trim_regs[9];
+			break;
+		case 10:
+			d1 = trim_regs[10];
+			d2 = trim_regs[11];
+			break;
+		case 14:
+			d1 = trim_regs[14];
+			d2 = trim_regs[15];
+			break;
+		default:
+			continue;
+		}
+
+		d1 = twl6030_gpadc_get_trim_offset(d1);
+		d2 = twl6030_gpadc_get_trim_offset(d2);
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int chn, d1 = 0, d2 = 0, temp;
+	u8 trim_regs[17];
+	int ret;
+
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
+			TWL6030_GPADC_TRIM1, 16);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	/* Loop to calculate the value needed for returning voltages from
+	 * GPADC not values.
+	 *
+	 * gain is calculated to 3 decimal places fixed point.
+	 */
+	for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+		case 1:
+		case 2:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+		case 11:
+		case 12:
+		case 13:
+		case 14:
+			/* D1 */
+			d1 = (trim_regs[3] & 0x1F) << 2;
+			d1 |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				d1 = -d1;
+
+			/* D2 */
+			d2 = (trim_regs[4] & 0x3F) << 2;
+			d2 |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				d2 = -d2;
+			break;
+		case 8:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[8] & 0x18) << 1;
+			d1 |= (trim_regs[7] & 0x1E) >> 1;
+			if (trim_regs[7] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[10] & 0x1F) << 2;
+			d2 |= (trim_regs[8] & 0x06) >> 1;
+			if (trim_regs[8] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		case 9:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[14] & 0x18) << 1;
+			d1 |= (trim_regs[12] & 0x1E) >> 1;
+			if (trim_regs[12] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[16] & 0x1F) << 2;
+			d2 |= (trim_regs[14] & 0x06) >> 1;
+			if (trim_regs[14] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+		case 10:
+			/* D1 */
+			d1 = (trim_regs[11] & 0x0F) << 3;
+			d1 |= (trim_regs[9] & 0x0E) >> 1;
+			if (trim_regs[9] & 0x01)
+				d1 = -d1;
+
+			/* D2 */
+			d2 = (trim_regs[15] & 0x0F) << 3;
+			d2 |= (trim_regs[13] & 0x0E) >> 1;
+			if (trim_regs[13] & 0x01)
+				d2 = -d2;
+			break;
+		case 7:
+		case 18:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[5] & 0x7E) >> 1;
+			if (trim_regs[5] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[6] & 0xFE) >> 1;
+			if (trim_regs[6] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		default:
+			/* No data for other channels */
+			continue;
+		}
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+#define TWL6030_GPADC_CHAN(chn, chan_info) {		\
+	.type = IIO_VOLTAGE,				\
+	.channel = chn,					\
+	.scan_type = {					\
+		.sign = 'u',				\
+		.storagebits = 16,			\
+	},						\
+	.info_mask = BIT(chan_info),			\
+	.info_mask_separate = BIT(chan_info), 		\
+	.indexed = 1,					\
+}
+
+static const struct iio_chan_spec twl6030_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(2, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(5, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(12, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(13, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(14, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(15, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(16, IIO_CHAN_INFO_RAW),
+};
+
+static const struct iio_chan_spec twl6032_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(2, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(5, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(12, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(13, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(14, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(15, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(16, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(17, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(18, IIO_CHAN_INFO_PROCESSED),
+};
+
+static const struct iio_info twl6030_gpadc_iio_info = {
+	.read_raw = &twl6030_gpadc_read_raw,
+	.driver_module = THIS_MODULE,
+};
+
+static const struct twl6030_gpadc_platform_data twl6030_pdata = {
+	.iio_channels = twl6030_gpadc_iio_channels,
+	.nchannels = TWL6030_GPADC_MAX_CHANNELS,
+	.ideal = twl6030_ideal,
+	.start_conversion = twl6030_start_conversion,
+	.channel_to_reg = twl6030_channel_to_reg,
+	.calibrate = twl6030_calibration,
+};
+
+static const struct twl6030_gpadc_platform_data twl6032_pdata = {
+	.iio_channels = twl6032_gpadc_iio_channels,
+	.nchannels = TWL6032_GPADC_MAX_CHANNELS,
+	.ideal = twl6032_ideal,
+	.start_conversion = twl6032_start_conversion,
+	.channel_to_reg = twl6032_channel_to_reg,
+	.calibrate = twl6032_calibration,
+};
+
+static const struct of_device_id of_twl6030_match_tbl[] = {
+	{
+		.compatible = "ti,twl6030_gpadc",
+		.data = &twl6030_pdata,
+	},
+	{
+		.compatible = "ti,twl6032_gpadc",
+		.data = &twl6032_pdata,
+	},
+	{ /* end */ }
+};
+
+static int twl6030_gpadc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct twl6030_gpadc_data *gpadc;
+	const struct twl6030_gpadc_platform_data *pdata;
+	const struct of_device_id *match;
+	struct iio_dev *indio_dev;
+	int irq;
+	int ret = 0;
+
+	match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
+	pdata = match ? match->data : dev->platform_data;
+
+	if (!pdata)
+		return -EINVAL;
+
+	indio_dev = iio_device_alloc(sizeof(struct twl6030_gpadc_data));
+	if (!indio_dev) {
+		dev_err(dev, "failed allocating iio device\n");
+		ret = -ENOMEM;
+	}
+
+	gpadc = iio_priv(indio_dev);
+
+	gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
+					sizeof(struct twl6030_chnl_calib) *
+					pdata->nchannels, GFP_KERNEL);
+	if (!gpadc->twl6030_cal_tbl)
+		goto err;
+
+	gpadc->dev = dev;
+	gpadc->pdata = pdata;
+
+	platform_set_drvdata(pdev, indio_dev);
+	mutex_init(&gpadc->lock);
+	init_completion(&gpadc->irq_complete);
+
+	ret = pdata->calibrate(gpadc);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to read calibration registers\n");
+		goto err;
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "failed to get irq\n");
+		goto err;
+	}
+
+	ret = devm_request_threaded_irq(dev, irq, NULL,
+					twl6030_gpadc_irq_handler,
+					IRQF_ONESHOT, "twl6030_gpadc", gpadc);
+	if (ret) {
+		dev_dbg(&pdev->dev, "could not request irq\n");
+		goto err;
+	}
+
+	ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
+		goto err;
+	}
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+					TWL6030_REG_TOGGLE1);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC module\n");
+		goto err;
+	}
+
+	indio_dev->name = DRIVER_NAME;
+	indio_dev->dev.parent = dev;
+	indio_dev->info = &twl6030_gpadc_iio_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->channels = pdata->iio_channels;
+	indio_dev->num_channels = pdata->nchannels;
+
+	ret = iio_device_register(indio_dev);
+	if (ret)
+		goto err;
+
+	return ret;
+err:
+	iio_device_free(indio_dev);
+	return ret;
+}
+
+static int twl6030_gpadc_remove(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+
+	twl6030_gpadc_disable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	iio_device_unregister(indio_dev);
+	iio_device_free(indio_dev);
+
+	return 0;
+}
+
+static int twl6030_gpadc_suspend(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCR,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error reseting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+
+static int twl6030_gpadc_resume(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error setting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+
+static const struct dev_pm_ops twl6030_gpadc_pm_ops = {
+	.suspend = twl6030_gpadc_suspend,
+	.resume = twl6030_gpadc_resume,
+};
+
+static struct platform_driver twl6030_gpadc_driver = {
+	.probe		= twl6030_gpadc_probe,
+	.remove		= twl6030_gpadc_remove,
+	.driver		= {
+		.name	= DRIVER_NAME,
+		.owner	= THIS_MODULE,
+		.pm	= &twl6030_gpadc_pm_ops,
+		.of_match_table = of_twl6030_match_tbl,
+	},
+};
+
+module_platform_driver(twl6030_gpadc_driver);
+
+MODULE_ALIAS("platform: " DRIVER_NAME);
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_DESCRIPTION("twl6030 ADC driver");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5



From oleksandr.kozaruk at ti.com  Fri Jul 12 03:18:01 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Fri, 12 Jul 2013 10:18:01 +0300
Subject: [PATCH v3 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1373613482-28390-2-git-send-email-oleksandr.kozaruk@ti.com>

GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.

Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 arch/arm/boot/dts/twl6030.dtsi |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..434842c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
 		compatible = "ti,twl6030-pwmled";
 		#pwm-cells = <2>;
 	};
+
+	gpadc: twl6030_gpadc {
+		compatible = "ti,twl6030_gpadc";
+		interrupts = <3>;
+		#io-channel-cells = <1>;
+	};
 };
-- 
1.7.9.5



From tony at atomide.com  Fri Jul 12 03:20:51 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Jul 2013 00:20:51 -0700
Subject: [PATCH 1/2] Revert "ARM: OMAP2+: Fix serial init for device
 tree based booting"
In-Reply-To: <1373539986-27272-2-git-send-email-rnayak@ti.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
 <1373539986-27272-2-git-send-email-rnayak@ti.com>
Message-ID: <20130712072051.GA7656@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130711 03:59]:
> This reverts commit 82702ea11ddfe0e43382e1fa5b66d807d8114916.
> 
> The above commit stubbed out omap_serial_early_init() in case of
> DT build thinking it was doing the serial port initializations.

Well not really. It was done to cut dependency between device
tree initialized drivers and pdata initialized drivers.
 
> omap_serial_early_init() however does not do the serial port
> inits (its instead done by omap_serial_init_port()) instead
> it sets the HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags
> for the console uart which causes hwmod to avoid doing a reset
> followed by the idling of the console uart.
> 
> This is still needed even in the DT case.

This fix is going the wrong way.

The console is working fine with DT based booting for me,
except for the earlyprintk fix needed.

And there should not be any need to parse cmdline for console
as omap-serial.c sets it up and already knows about it.

Care to state what exactly this attempts to fix and for which
omaps? If this is only needed for am33xx, then why?

Regards,

Tony
 
> Signed-off-by: Rajendra Nayak <rnayak at ti.com>
> Reported-by: Mark Jackson <mpfj-list at newflow.co.uk>
> Reported-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
> ---
>  arch/arm/mach-omap2/serial.c |    3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 3a674de..58d5b56 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -175,9 +175,6 @@ static char *cmdline_find_option(char *str)
>  
>  static int __init omap_serial_early_init(void)
>  {
> -	if (of_have_populated_dt())
> -		return -ENODEV;
> -
>  	do {
>  		char oh_name[MAX_UART_HWMOD_NAME_LEN];
>  		struct omap_hwmod *oh;
> -- 
> 1.7.9.5
> 


From tony at atomide.com  Fri Jul 12 03:22:45 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Jul 2013 00:22:45 -0700
Subject: [PATCH 0/2] Fix omap serial early crash during hwmod _setup()
In-Reply-To: <1373539986-27272-1-git-send-email-rnayak@ti.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
Message-ID: <20130712072244.GB7656@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130711 03:59]:
> This series should fix the issue with the early serial crash seen
> during hwmod _setup() as reported by [1]
> 
> The issue was reported on a am33xx device and was not seen on omap4
> or omap5 devices as the hwmod data for both omap4 and omap5 had
> statically defined HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET for
> uart3 which happens to be the debug console used on omap4 panda and
> omap5 uevm boards.

The serial driver should be capable of setting this on it's own
as it sets up the console.

Regards,

Tony


From tony at atomide.com  Fri Jul 12 03:26:51 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Jul 2013 00:26:51 -0700
Subject: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and
 twl6040 setup for legacy boot
In-Reply-To: <1373552638-13930-1-git-send-email-peter.ujfalusi@ti.com>
References: <1373552638-13930-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <20130712072650.GC7656@atomide.com>

* Peter Ujfalusi <peter.ujfalusi at ti.com> [130711 07:30]:
> OMAP4 no longer boots in legacy mode so the code here is no longer used.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> ---
>  arch/arm/mach-omap2/twl-common.c | 332 ++-------------------------------------
>  arch/arm/mach-omap2/twl-common.h |   8 -
>  2 files changed, 12 insertions(+), 328 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
> index c05898f..932dea7 100644
> --- a/arch/arm/mach-omap2/twl-common.c
> +++ b/arch/arm/mach-omap2/twl-common.c
> @@ -38,20 +38,6 @@ static struct i2c_board_info __initdata pmic_i2c_board_info = {
>  	.flags		= I2C_CLIENT_WAKE,
>  };
>  
> -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> -static int twl_set_voltage(void *data, int target_uV)
> -{
> -	struct voltagedomain *voltdm = (struct voltagedomain *)data;
> -	return voltdm_scale(voltdm, target_uV);
> -}
> -
> -static int twl_get_voltage(void *data)
> -{
> -	struct voltagedomain *voltdm = (struct voltagedomain *)data;
> -	return voltdm_get_voltage(voltdm);
> -}
> -#endif

Looks like the code above is also needed for omap3 based on the
if defined?

Tony


From rnayak at ti.com  Fri Jul 12 03:31:48 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 12 Jul 2013 13:01:48 +0530
Subject: [PATCH 1/2] Revert "ARM: OMAP2+: Fix serial init for device tree
 based booting"
In-Reply-To: <20130712072051.GA7656@atomide.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
 <1373539986-27272-2-git-send-email-rnayak@ti.com>
 <20130712072051.GA7656@atomide.com>
Message-ID: <51DFB0E4.6040007@ti.com>

On Friday 12 July 2013 12:50 PM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak at ti.com> [130711 03:59]:
>> This reverts commit 82702ea11ddfe0e43382e1fa5b66d807d8114916.
>>
>> The above commit stubbed out omap_serial_early_init() in case of
>> DT build thinking it was doing the serial port initializations.
> 
> Well not really. It was done to cut dependency between device
> tree initialized drivers and pdata initialized drivers.
>  
>> omap_serial_early_init() however does not do the serial port
>> inits (its instead done by omap_serial_init_port()) instead
>> it sets the HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags
>> for the console uart which causes hwmod to avoid doing a reset
>> followed by the idling of the console uart.
>>
>> This is still needed even in the DT case.
> 
> This fix is going the wrong way.
> 
> The console is working fine with DT based booting for me,
> except for the earlyprintk fix needed.

It works on omap4 and omap5. It won't work on any
am33xx devices.

> 
> And there should not be any need to parse cmdline for console
> as omap-serial.c sets it up and already knows about it.
> 
> Care to state what exactly this attempts to fix and for which
> omaps? If this is only needed for am33xx, then why?

Yes, this is needed only for am33xx because am33xx hwmod rightly
had the hwmod flags for NO_IDLE and NO_RESET removed and omap4
and omap5 wrongly still carry them around.

Just try applying PATCH 2/2 of this series and it won't work on the
omap4 sdp anymore.

regards,
Rajendra

> 
> Regards,
> 
> Tony
>  
>> Signed-off-by: Rajendra Nayak <rnayak at ti.com>
>> Reported-by: Mark Jackson <mpfj-list at newflow.co.uk>
>> Reported-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
>> ---
>>  arch/arm/mach-omap2/serial.c |    3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
>> index 3a674de..58d5b56 100644
>> --- a/arch/arm/mach-omap2/serial.c
>> +++ b/arch/arm/mach-omap2/serial.c
>> @@ -175,9 +175,6 @@ static char *cmdline_find_option(char *str)
>>  
>>  static int __init omap_serial_early_init(void)
>>  {
>> -	if (of_have_populated_dt())
>> -		return -ENODEV;
>> -
>>  	do {
>>  		char oh_name[MAX_UART_HWMOD_NAME_LEN];
>>  		struct omap_hwmod *oh;
>> -- 
>> 1.7.9.5
>>



From rnayak at ti.com  Fri Jul 12 03:33:13 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 12 Jul 2013 13:03:13 +0530
Subject: [PATCH 0/2] Fix omap serial early crash during hwmod _setup()
In-Reply-To: <20130712072244.GB7656@atomide.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
 <20130712072244.GB7656@atomide.com>
Message-ID: <51DFB139.8060408@ti.com>

On Friday 12 July 2013 12:52 PM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak at ti.com> [130711 03:59]:
>> This series should fix the issue with the early serial crash seen
>> during hwmod _setup() as reported by [1]
>>
>> The issue was reported on a am33xx device and was not seen on omap4
>> or omap5 devices as the hwmod data for both omap4 and omap5 had
>> statically defined HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET for
>> uart3 which happens to be the debug console used on omap4 panda and
>> omap5 uevm boards.
> 
> The serial driver should be capable of setting this on it's own
> as it sets up the console.

These flags are used to avoid an early reset that hwmod does to all devices
on the SoC and is done much before serial driver is initialized.

> 
> Regards,
> 
> Tony
> 



From r65037 at freescale.com  Fri Jul 12 03:42:13 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Fri, 12 Jul 2013 07:42:13 +0000
Subject: [v5 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <20130712070130.GC25501@S2101-09.ap.freescale.net>
References: <1373533831-9500-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373533831-9500-4-git-send-email-Hong-Xing.Zhu@freescale.com>
 <20130712070130.GC25501@S2101-09.ap.freescale.net>
Message-ID: <0E83723C55F66F43A6041464FE31119D338480@039-SN2MPN1-011.039d.mgd.msft.net>

Hi Shawn:
Thanks for your comments.

Best Regards
Richard Zhu


-----Original Message-----
From: Shawn Guo [mailto:shawn.guo at linaro.org] 
Sent: Friday, July 12, 2013 3:02 PM
To: Richard Zhu
Cc: linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; tj at kernel.org; rob.herring at calxeda.com; s.hauer at pengutronix.de; linux-ide at vger.kernel.org; Zhu Richard-R65037
Subject: Re: [v5 3/3] sata: imx: add ahci sata support on imx platforms

On Thu, Jul 11, 2013 at 05:10:31PM +0800, Richard Zhu wrote:
> From: Richard Zhu <r65037 at freescale.com>
> 
> imx6q contains one Synopsys AHCI SATA controller, But it can't shares 
> ahci_platform driver with other controllers.
> Because there are some misalignments of the generic AHCI controller.
> The bits definitions of the HBA registers, the Vendor Specific 
> registers, the AHCI PHY clock and the AHCI signals adjustment 
> window(GPR13 Reg).
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default  value is '0', 
> should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the  HOST_PORTS_IMPL 
> should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)  should be 
> configured regarding to the frequency of AHB  bus clock.
>  - Configurations of the AHCI PHY clock, and the signal  parameters of 
> the GPR13
> 
> Setup its own ahci sata driver, contained the imx6q specific 
> initialized codes, re-use the generic ahci_platform drier, and

s/drier/driver
[Richard] One typo error, would be changed.

> keep the generic ahci_platform driver clean as much as possible.
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  drivers/ata/Kconfig    |    9 ++
>  drivers/ata/Makefile   |    1 +
>  drivers/ata/sata_imx.c |  233 
> ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 243 insertions(+), 0 deletions(-)  create mode 
> 100644 drivers/ata/sata_imx.c
> 
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 
> a5a3ebc..275dc2c 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -97,6 +97,15 @@ config SATA_AHCI_PLATFORM
>  
>  	  If unsure, say N.
>  
> +config SATA_IMX
> +	tristate "Freescale i.MX AHCI SATA support"
> +	depends on SATA_AHCI_PLATFORM
> +	help
> +	  This option enables support for the Freescale i.MX SoC's
> +	  onboard AHCI SATA.
> +
> +	  If unsure, say N.
> +
>  config SATA_FSL
>  	tristate "Freescale 3.0Gbps SATA support"
>  	depends on FSL_SOC
> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index 
> c04d0fd..04b1c6c 100644
> --- a/drivers/ata/Makefile
> +++ b/drivers/ata/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_SATA_INIC162X)	+= sata_inic162x.o
>  obj-$(CONFIG_SATA_SIL24)	+= sata_sil24.o
>  obj-$(CONFIG_SATA_DWC)		+= sata_dwc_460ex.o
>  obj-$(CONFIG_SATA_HIGHBANK)	+= sata_highbank.o libahci.o
> +obj-$(CONFIG_SATA_IMX)		+= sata_imx.o
>  
>  # SFF w/ custom DMA
>  obj-$(CONFIG_PDC_ADMA)		+= pdc_adma.o
> diff --git a/drivers/ata/sata_imx.c b/drivers/ata/sata_imx.c new file 
> mode 100644 index 0000000..de6330e
> --- /dev/null
> +++ b/drivers/ata/sata_imx.c
> @@ -0,0 +1,233 @@
> +/*
> + * Freescale IMX AHCI SATA platform driver
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * based on the AHCI SATA platform driver by Jeff Garzik and Anton 
> +Vorontsov
> + *
> + * This program is free software; you can redistribute it and/or 
> +modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License 
> +along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/ahci_platform.h>
> +#include <linux/of_device.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
> +#include "ahci.h"
> +
> +enum {
> +	HOST_TIMER1MS = 0xe0, /* Timer 1-ms */ };
> +
> +struct imx_ahci_priv {
> +	struct platform_device *imx_ahci_pdev;
> +	struct clk *sata_ref_clk;
> +	struct regmap *gpr;
> +};
> +
> +/* imx6q ahci module initialization. */ static int 
> +imx6q_sata_init(struct device *dev, void __iomem *mmio) {
> +	int ret = 0;
> +	unsigned int rc;

The variable name is confusing. "rc" generally means return code.
[Richard] Accepted. Would be changed.
> +	struct clk *ahb_clk;
> +	struct device *p_dev = dev->parent;
> +	struct imx_ahci_priv *imxpriv =  dev_get_drvdata(p_dev);

I would go dev_get_drvdata(dev->parent), since dev->parent is even more readable than p_dev.
[Richard] Accepted.

> +
> +	imxpriv->gpr =
> +		syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +	if (IS_ERR(imxpriv->gpr)) {
> +		dev_err(dev, "failed to find fsl,imx6q-iomux-gpr regmap\n");
> +		return PTR_ERR(imxpriv->gpr);
> +	}

Move it into imx_ahci_probe().
[Richard] The codes "> +		syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr"); " is imx6q specific.
I think it's better to place these codes in the imx6q_sata_init(). Otherwise, the probe maybe broken here, when imx53
sata use sata_imx driver in future.

> +
> +	imxpriv->sata_ref_clk = devm_clk_get(dev, "sata_ref");
> +	if (IS_ERR(imxpriv->sata_ref_clk)) {
> +		dev_err(dev, "can't get sata_ref clock.\n");
> +		return PTR_ERR(imxpriv->sata_ref_clk);
> +	}

Ditto
[Richard] Accepted.

> +
> +	ret = clk_prepare_enable(imxpriv->sata_ref_clk);
> +	if (ret < 0) {
> +		dev_err(dev, "prepare-enable sata_ref clock err:%d\n", ret);
> +		return ret;
> +	}
> +
> +	/*
> +	 * set PHY Paremeters, two steps to configure the GPR13,
> +	 * one write for rest of parameters, mask of first write
> +	 * is 0x07fffffd, and the other one write for setting
> +	 * the mpll_clk_en.
> +	 */
> +	regmap_update_bits(imxpriv->gpr, 0x34, IMX6Q_GPR13_SATA_RX_EQ_VAL_MASK
> +			| IMX6Q_GPR13_SATA_RX_LOS_LVL_MASK
> +			| IMX6Q_GPR13_SATA_RX_DPLL_MODE_MASK
> +			| IMX6Q_GPR13_SATA_SPD_MODE_MASK
> +			| IMX6Q_GPR13_SATA_MPLL_SS_EN
> +			| IMX6Q_GPR13_SATA_TX_ATTEN_MASK
> +			| IMX6Q_GPR13_SATA_TX_BOOST_MASK
> +			| IMX6Q_GPR13_SATA_TX_LVL_MASK
> +			| IMX6Q_GPR13_SATA_TX_EDGE_RATE
> +			, IMX6Q_GPR13_SATA_RX_EQ_VAL_3_0_DB
> +			| IMX6Q_GPR13_SATA_RX_LOS_LVL_SATA2M
> +			| IMX6Q_GPR13_SATA_RX_DPLL_MODE_2P_4F
> +			| IMX6Q_GPR13_SATA_SPD_MODE_3P0G
> +			| IMX6Q_GPR13_SATA_MPLL_SS_EN
> +			| IMX6Q_GPR13_SATA_TX_ATTEN_9_16
> +			| IMX6Q_GPR13_SATA_TX_BOOST_3_33_DB
> +			| IMX6Q_GPR13_SATA_TX_LVL_1_025_V);
> +	regmap_update_bits(imxpriv->gpr, 0x34, IMX6Q_GPR13_SATA_MPLL_CLK_EN,
> +			IMX6Q_GPR13_SATA_MPLL_CLK_EN);
> +	usleep_range(100, 200);
> +
> +	/*
> +	 * Configure the HWINIT bits of the HOST_CAP and HOST_PORTS_IMPL,
> +	 * and IP vendor specific register HOST_TIMER1MS.
> +	 *
> +	 * Configure CAP_SSS (support stagered spin up).
> +	 * Implement the port0.
> +	 * Get the ahb clock rate, and configure the TIMER1MS register.
> +	 */
> +	rc = readl(mmio + HOST_CAP);
> +	if (!(rc & HOST_CAP_SSS)) {
> +		rc |= HOST_CAP_SSS;
> +		writel(rc, mmio + HOST_CAP);
> +	}
> +	rc = readl(mmio + HOST_PORTS_IMPL);
> +	if (!(rc & 0x1)) {
> +		rc |= 0x1;
> +		writel(rc, mmio + HOST_PORTS_IMPL);
> +	}
> +
> +	ahb_clk = devm_clk_get(dev, "ahb");

If you need to get ahb clock, please specify it in your DTS node.  Right now, you only have the following two clocks in the DTS.

	clocks = <&clks 154>, <&clks 187>;
	clock-names = "sata", "sata_ref";

You code happens to work because of the following call in clk-imx6q.c.

	clk_register_clkdev(clk[ahb], "ahb", NULL);

But you shouldn't reply on that.  With all users moved to looking up clocks from device tree, we would remove it from clock driver.

Also, please have a clk pointer in imx_ahci_priv and call devm_clk_get() in imx_ahci_probe().
[Richard] Accepted. Would add "ahb" to sata related dts changes.

> +	if (IS_ERR(ahb_clk)) {
> +		dev_err(dev, "no ahb clock.\n");
> +		clk_disable_unprepare(imxpriv->sata_ref_clk);
> +		devm_clk_put(dev, imxpriv->sata_ref_clk);
> +		return PTR_ERR(ahb_clk);
> +	}
> +	rc = clk_get_rate(ahb_clk) / 1000;
> +	writel(rc, mmio + HOST_TIMER1MS);
> +	devm_clk_put(dev, ahb_clk);
> +
> +	return 0;
> +}
> +
> +static void imx6q_sata_exit(struct device *dev) {
> +	struct device *p_dev = dev->parent;
> +	struct imx_ahci_priv *imxpriv =  dev_get_drvdata(p_dev);

dev_get_drvdata(dev->parent);
[Richard] Accepted.

> +
> +	regmap_update_bits(imxpriv->gpr, 0x34, IMX6Q_GPR13_SATA_MPLL_CLK_EN,
> +			!IMX6Q_GPR13_SATA_MPLL_CLK_EN);
> +	clk_disable_unprepare(imxpriv->sata_ref_clk);
> +}
> +
> +static struct ahci_platform_data imx6q_sata_pdata = {
> +	.init = imx6q_sata_init,
> +	.exit = imx6q_sata_exit,
> +};

Put a blank line here.

> +static const struct of_device_id imx_ahci_of_match[] = {
> +	{ .compatible = "fsl,imx6q-ahci", .data = &imx6q_sata_pdata},
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, imx_ahci_of_match);
> +
> +static void imx_ahci_platform_release(struct device *dev) {
> +	return;
> +}

Is this empty function mandatory?
[Richard] Introduce in the previous patch-set, It can be removed in the current version.

> +
> +static int imx_ahci_probe(struct platform_device *pdev) {
> +	struct device *dev = &pdev->dev;
> +	struct resource *mem, *irq, res[2];
> +	const struct of_device_id *of_id;
> +	const struct ahci_platform_data *pdata = NULL;
> +	struct imx_ahci_priv *imxpriv;
> +	int ret;
> +
I would drop this blank line and move the following two line above "int ret;".
[Richard] Accepted. 

> +	struct device *imx_dev;
> +	struct platform_device *imx_ahci_pdev;

These two variable names are confusing.  I would name them ahci_dev and ahci_pdev, as they are all about generic "ahci" rather than imx specific one.
[Richard] Accepted.

> +
> +	imx_ahci_pdev = platform_device_alloc("ahci", -1);
> +	if (!imx_ahci_pdev)
> +		return -ENODEV;
> +
> +	imx_dev = &imx_ahci_pdev->dev;
> +	imx_dev->release = imx_ahci_platform_release;
> +	imx_dev->parent = dev;
> +
> +	imxpriv = devm_kzalloc(dev, sizeof(*imxpriv), GFP_KERNEL);
> +	if (!imxpriv) {
> +		dev_err(dev, "can't alloc ahci_host_priv\n");
> +		return -ENOMEM;
> +	}
> +
> +	imxpriv->imx_ahci_pdev = imx_ahci_pdev;

So imx_ahci_pdev in imx_ahci_priv is also confusing.
[Richard] imx_ahci_pdev would be replaced by ahci_pdev.

> +	platform_set_drvdata(pdev, imxpriv);
> +
> +	of_id = of_match_device(imx_ahci_of_match, dev);
> +	if (of_id)
> +		pdata = of_id->data;
> +	else
> +		return -EINVAL;
> +
> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +	if (!mem || !irq) {
> +		dev_err(dev, "no mmio/irq resource\n");
> +		return -EINVAL;
> +	}
> +
> +	res[0] = *mem;
> +	res[1] = *irq;
> +
> +	imx_dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +	imx_dev->dma_mask = &imx_dev->coherent_dma_mask;
> +	imx_dev->of_node = dev->of_node;
> +
> +	platform_device_add_resources(imx_ahci_pdev, res, 2);
> +	platform_device_add_data(imx_ahci_pdev, pdata, sizeof(*pdata));
> +
> +	ret = platform_device_add(imx_ahci_pdev);
> +
> +	return ret;

Can just be return platform_device_add(imx_ahci_pdev);
[Richard] Accepted.

Shawn

> +}
> +
> +static int imx_ahci_remove(struct platform_device *pdev) {
> +	struct imx_ahci_priv *imxpriv = platform_get_drvdata(pdev);
> +	struct platform_device *imx_ahci_pdev = imxpriv->imx_ahci_pdev;
> +
> +	platform_device_unregister(imx_ahci_pdev);
> +	return 0;
> +}
> +
> +static struct platform_driver imx_ahci_driver = {
> +	.probe = imx_ahci_probe,
> +	.remove = imx_ahci_remove,
> +	.driver = {
> +		.name = "sata-imx",
> +		.owner = THIS_MODULE,
> +		.of_match_table = imx_ahci_of_match,
> +	},
> +};
> +module_platform_driver(imx_ahci_driver);
> +
> +MODULE_DESCRIPTION("Freescale i.MX AHCI SATA platform driver"); 
> +MODULE_AUTHOR("Richard Zhu <Hong-Xing.Zhu at freescale.com>"); 
> +MODULE_LICENSE("GPL"); MODULE_ALIAS("sata:imx");
> --
> 1.7.5.4
> 



From shawn.guo at linaro.org  Fri Jul 12 03:49:49 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Jul 2013 15:49:49 +0800
Subject: [PATCH v2] ARM: imx: Kconfig: Select ARM1136 related errata
In-Reply-To: <1373552782-14196-1-git-send-email-fabio.estevam@freescale.com>
References: <1373552782-14196-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <20130712074946.GD25501@S2101-09.ap.freescale.net>

On Thu, Jul 11, 2013 at 11:26:22AM -0300, Fabio Estevam wrote:
> CONFIG_ARM_ERRATA_411920 and CONFIG_ARM_ERRATA_364296 should be selected for
> ARM1136 SoCs.
> 
Per help text of the erratums, 364296 affects ARM1136 r0p2, and 411920
affects ARM1136 before r1p4.  Do you know the revisions used on imx31
and imx35?  Or do you see that enabling the workaround help fix some
real issues?

Shawn

> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
> Changes since v1:
> - Select the errata via Kconfig
> 
>  arch/arm/mach-imx/Kconfig | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index f7a5ad1..1d15d5c 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -123,6 +123,8 @@ config SOC_IMX27
>  
>  config SOC_IMX31
>  	bool
> +	select ARM_ERRATA_364296
> +	select ARM_ERRATA_411920
>  	select COMMON_CLK
>  	select CPU_V6
>  	select IMX_HAVE_PLATFORM_MXC_RNGA
> @@ -132,6 +134,8 @@ config SOC_IMX31
>  config SOC_IMX35
>  	bool
>  	select ARCH_MXC_IOMUX_V3
> +	select ARM_ERRATA_364296
> +	select ARM_ERRATA_411920
>  	select COMMON_CLK
>  	select CPU_V6K
>  	select HAVE_EPIT
> -- 
> 1.8.1.2
> 
> 



From shawn.guo at linaro.org  Fri Jul 12 03:55:37 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Jul 2013 15:55:37 +0800
Subject: [PATCH 1/2] ARM i.MX53: mba53: Fix PWM backlight DT node
In-Reply-To: <1373553468-6564-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1373553468-6564-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <20130712075535.GE25501@S2101-09.ap.freescale.net>

On Thu, Jul 11, 2013 at 04:37:47PM +0200, Laurent Pinchart wrote:
> The i.MX53 PWM controller uses two cells to describe the PWM specifier.
> Remove the extra unused values from the backlight DT node pwms property.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Applied, thanks.



From mingo at kernel.org  Fri Jul 12 03:56:02 2013
From: mingo at kernel.org (Ingo Molnar)
Date: Fri, 12 Jul 2013 09:56:02 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
Message-ID: <20130712075602.GA4002@gmail.com>


* Kyungsik Lee <kyungsik.lee at lge.com> wrote:

> LZ4 has been updated with LZ4 Streaming Format specification(v1.3).
> lz4demo is replaced by lz4c. lz4c supports both the new streaming and
> legacy format with -l option.
> 
> This patch makes use of lz4c to support legacy format which is
> used for LZ4 De/compression in the linux kernel.
> 
> Link: https://code.google.com/p/lz4/source/checkout
> Signed-off-by: Kyungsik Lee <kyungsik.lee at lge.com>
> Cc: "H. Peter Anvin" <hpa at zytor.com>
> Cc: Ingo Molnar <mingo at elte.hu>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Russell King <rmk at arm.linux.org.uk>
> Cc: Borislav Petkov <bp at alien8.de>
> Cc: Florian Fainelli <florian at openwrt.org>
> Cc: Yann Collet <yann.collet.73 at gmail.com>
> Cc: Chanho Min <chanho.min at lge.com>
> ---
>  scripts/Makefile.lib | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index a0ab6d7..c9bfbb0 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -313,7 +313,7 @@ cmd_lzo = (cat $(filter-out FORCE,$^) | \
>  
>  quiet_cmd_lz4 = LZ4     $@
>  cmd_lz4 = (cat $(filter-out FORCE,$^) | \
> -	lz4demo -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
> +	lz4c -l -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
>  	(rm -f $@ ; false)

None of the major distros I tried has the lz4 or lz4c binary available, 
and this breaks randconfig builds:

  /bin/sh: lz4c: command not found

If:

 CONFIG_HAVE_KERNEL_LZ4=y
 CONFIG_KERNEL_LZ4=y
 CONFIG_RD_LZ4=y
 CONFIG_LZ4_DECOMPRESS=y
 CONFIG_DECOMPRESS_LZ4=y

If a utility is not widely available yet and if the utility is not in the 
kernel proper, could you please at least make sure that randconfig does 
not stumble over non-buildable kernels?

Thanks,

	Ingo


From bp at alien8.de  Fri Jul 12 04:01:46 2013
From: bp at alien8.de (Borislav Petkov)
Date: Fri, 12 Jul 2013 10:01:46 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130712075602.GA4002@gmail.com>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130712075602.GA4002@gmail.com>
Message-ID: <20130712080145.GC24008@pd.tnic>

On Fri, Jul 12, 2013 at 09:56:02AM +0200, Ingo Molnar wrote:
> If a utility is not widely available yet and if the utility is not in
> the kernel proper, could you please at least make sure that randconfig
> does not stumble over non-buildable kernels?

Two months ago I've complained about this and other people have burned
themselves too in the meantime...

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--


From tony at atomide.com  Fri Jul 12 04:03:05 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Jul 2013 01:03:05 -0700
Subject: [PATCH 1/2] Revert "ARM: OMAP2+: Fix serial init for device
 tree based booting"
In-Reply-To: <51DFB0E4.6040007@ti.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
 <1373539986-27272-2-git-send-email-rnayak@ti.com>
 <20130712072051.GA7656@atomide.com> <51DFB0E4.6040007@ti.com>
Message-ID: <20130712080305.GD7656@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130712 00:38]:
> On Friday 12 July 2013 12:50 PM, Tony Lindgren wrote:
> > * Rajendra Nayak <rnayak at ti.com> [130711 03:59]:
> >> This reverts commit 82702ea11ddfe0e43382e1fa5b66d807d8114916.
> >>
> >> The above commit stubbed out omap_serial_early_init() in case of
> >> DT build thinking it was doing the serial port initializations.
> > 
> > Well not really. It was done to cut dependency between device
> > tree initialized drivers and pdata initialized drivers.
> >  
> >> omap_serial_early_init() however does not do the serial port
> >> inits (its instead done by omap_serial_init_port()) instead
> >> it sets the HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags
> >> for the console uart which causes hwmod to avoid doing a reset
> >> followed by the idling of the console uart.
> >>
> >> This is still needed even in the DT case.
> > 
> > This fix is going the wrong way.
> > 
> > The console is working fine with DT based booting for me,
> > except for the earlyprintk fix needed.
> 
> It works on omap4 and omap5. It won't work on any
> am33xx devices.

OK. I assume the regular serial onsole works just fine, what does
not work is the earlyprintk for am33xx?

> > And there should not be any need to parse cmdline for console
> > as omap-serial.c sets it up and already knows about it.
> > 
> > Care to state what exactly this attempts to fix and for which
> > omaps? If this is only needed for am33xx, then why?
> 
> Yes, this is needed only for am33xx because am33xx hwmod rightly
> had the hwmod flags for NO_IDLE and NO_RESET removed and omap4
> and omap5 wrongly still carry them around.

OK.
 
> Just try applying PATCH 2/2 of this series and it won't work on the
> omap4 sdp anymore.

OK, so that's only for earlyprintk then?

If so, it seems the right fix is to set the NO_IDLE and NO_RESET
flags based on ifdef CONFIG_DEBUG_OMAP4UART3 etc as that is selected
in the Kconfig now.

The current code in mach-omap2/serial.c is wrong, and is a hack
needed for the pdata based booting. What's broken is that
omap_serial_early_init() parses the cmdline for console, which
itself is pretty nasty, and it won't work the right way as
there's nothing stopping from having the earlycon in a different
UART from the serial console. So we just want to get rid of the
whole mach-omap2/serial.c once we're all DT.

So to summarize, we have two bugs:

1. Omap hwmod code can reset UART while earlycon may be using
   it. The fix to this is to use NO_IDLE and NO_RESET flags in
   the hwmod code if CONFIG_DEBUG_OMAPxUARTy is specified.

2. A bug in drivers/tty/serial/omap-serial.c where the
   missing context loss count can cause NULL context to be
   initialized during driver probe causing port to hang for
   earlycon. The fix for that is what Felipe has suggested or
   fix it in the driver by removing the context loss count usage
   and detect the need for context restore based on the UART
   state.

Or am I still missing something?

Regards,

Tony


From tony at atomide.com  Fri Jul 12 04:03:48 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Jul 2013 01:03:48 -0700
Subject: [PATCH 0/2] Fix omap serial early crash during hwmod _setup()
In-Reply-To: <51DFB139.8060408@ti.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
 <20130712072244.GB7656@atomide.com> <51DFB139.8060408@ti.com>
Message-ID: <20130712080348.GE7656@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130712 00:39]:
> On Friday 12 July 2013 12:52 PM, Tony Lindgren wrote:
> > * Rajendra Nayak <rnayak at ti.com> [130711 03:59]:
> >> This series should fix the issue with the early serial crash seen
> >> during hwmod _setup() as reported by [1]
> >>
> >> The issue was reported on a am33xx device and was not seen on omap4
> >> or omap5 devices as the hwmod data for both omap4 and omap5 had
> >> statically defined HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET for
> >> uart3 which happens to be the debug console used on omap4 panda and
> >> omap5 uevm boards.
> > 
> > The serial driver should be capable of setting this on it's own
> > as it sets up the console.
> 
> These flags are used to avoid an early reset that hwmod does to all devices
> on the SoC and is done much before serial driver is initialized.

OK so that's only needed for earlycon then it seems.

Regards,

Tony


From weisserm at arcor.de  Fri Jul 12 03:34:54 2013
From: weisserm at arcor.de (Matthias Weisser)
Date: Fri, 12 Jul 2013 09:34:54 +0200
Subject: [PATCH] ARM: dts: imx25: Make lcdc compatible to imx27/imx21 fb
Message-ID: <1373614495-21717-1-git-send-email-weisserm@arcor.de>

ARM: dts: imx25: Make lcdc compatible to imx27/imx21 fb

Signed-off-by: Matthias Weisser <weisserm at arcor.de>
---
 arch/arm/boot/dts/imx25.dtsi |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index d2550e0..83532b6 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -377,7 +377,8 @@
 				status = "disabled";
 			};
 
-			lcdc at 53fbc000 {
+			lcdc: lcdc at 53fbc000 {
+				compatible = "fsl,imx27-fb", "fsl,imx21-fb";
 				reg = <0x53fbc000 0x4000>;
 				interrupts = <39>;
 				clocks = <&clks 103>, <&clks 66>, <&clks 49>;
-- 
1.7.9.5



From alexander.shishkin at linux.intel.com  Fri Jul 12 04:12:01 2013
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Fri, 12 Jul 2013 11:12:01 +0300
Subject: [PATCH v12 06/13] usb: chipidea: add otg_cap attribute for otg
 capable
In-Reply-To: <1373524041-10482-7-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <1373524041-10482-7-git-send-email-peter.chen@freescale.com>
Message-ID: <871u742o4u.fsf@ashishki-desk.ger.corp.intel.com>

Peter Chen <peter.chen at freescale.com> writes:

> Since we need otgsc to know vbus's status at some chipidea
> controllers even it is peripheral-only mode. Besides, some
> SoCs (eg, AR9331 SoC) don't have otgsc register even
> the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS.
> We inroduce otg_cap attribute to indicate if the controller
> is otg capable, defaultly, we follow the rule that if DCCPARAMS_DC
> and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS are otg capable, but if there
> is exception, the platform can override it by device tree or platform data.
>
> Signed-off-by: Peter Chen <peter.chen at freescale.com>
> ---

[...]

> diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
> index 118bf66..0a906b4 100644
> --- a/include/linux/usb/chipidea.h
> +++ b/include/linux/usb/chipidea.h
> @@ -7,6 +7,12 @@
>  
>  #include <linux/usb/otg.h>
>  
> +enum usb_otg_cap {
> +	OTG_CAP_ATTR_IS_NOT_EXISTED = 0,
> +	OTG_CAP_ATTR_IS_TRUE,
> +	OTG_CAP_ATTR_IS_FALSE,
> +};

We don't really need all three, do we? We only need to know if the
controller *can't* do otg. The rest we can infer from dr_mode and
DCCPARAMS. So it can be another bit in flags rather than a separate
field in platdata.

Regards,
--
Alex


From peter.ujfalusi at ti.com  Fri Jul 12 04:13:52 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Fri, 12 Jul 2013 10:13:52 +0200
Subject: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and
 twl6040 setup for legacy boot
In-Reply-To: <20130712072650.GC7656@atomide.com>
References: <1373552638-13930-1-git-send-email-peter.ujfalusi@ti.com>
 <20130712072650.GC7656@atomide.com>
Message-ID: <51DFBAC0.5070806@ti.com>

On 07/12/2013 09:26 AM, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi at ti.com> [130711 07:30]:
>> OMAP4 no longer boots in legacy mode so the code here is no longer used.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
>> ---
>>  arch/arm/mach-omap2/twl-common.c | 332 ++-------------------------------------
>>  arch/arm/mach-omap2/twl-common.h |   8 -
>>  2 files changed, 12 insertions(+), 328 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
>> index c05898f..932dea7 100644
>> --- a/arch/arm/mach-omap2/twl-common.c
>> +++ b/arch/arm/mach-omap2/twl-common.c
>> @@ -38,20 +38,6 @@ static struct i2c_board_info __initdata pmic_i2c_board_info = {
>>  	.flags		= I2C_CLIENT_WAKE,
>>  };
>>  
>> -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
>> -static int twl_set_voltage(void *data, int target_uV)
>> -{
>> -	struct voltagedomain *voltdm = (struct voltagedomain *)data;
>> -	return voltdm_scale(voltdm, target_uV);
>> -}
>> -
>> -static int twl_get_voltage(void *data)
>> -{
>> -	struct voltagedomain *voltdm = (struct voltagedomain *)data;
>> -	return voltdm_get_voltage(voltdm);
>> -}
>> -#endif
> 
> Looks like the code above is also needed for omap3 based on the
> if defined?

Yes it is still needed for OMAP3 when booting in legacy. I have moved these
two function down within the #if defined(CONFIG_ARCH_OMAP3) :

 #if defined(CONFIG_ARCH_OMAP3)
@@ -189,6 +160,18 @@ static struct regulator_init_data omap3_vdd2 = {
 	.consumer_supplies		= omap3_vdd2_supply,
 };

+static int twl_set_voltage(void *data, int target_uV)
+{
+	struct voltagedomain *voltdm = (struct voltagedomain *)data;
+	return voltdm_scale(voltdm, target_uV);
+}
+
+static int twl_get_voltage(void *data)
+{
+	struct voltagedomain *voltdm = (struct voltagedomain *)data;
+	return voltdm_get_voltage(voltdm);
+}
+
 static struct twl_regulator_driver_data omap3_vdd1_drvdata = {
 	.get_voltage = twl_get_voltage,
 	.set_voltage = twl_set_voltage,
@@ -235,297 +218,6 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
 }
 #endif /* CONFIG_ARCH_OMAP3 */


-- 
P?ter


From jjo.braun at gmail.com  Fri Jul 12 04:19:16 2013
From: jjo.braun at gmail.com (Johannes Braun)
Date: Fri, 12 Jul 2013 10:19:16 +0200
Subject: Freescale i.MX351: Poor framebuffer performance with 7 inch display
Message-ID: <CADwvPCsm4UEGLH_mfpeoZ7L-wSTqTgicYXd6+_YuFSxGy57o2Q@mail.gmail.com>

Dear mailing list,

our current board design is based on a freescale i.MX35 processor.
First some information to the used arm processor. It is an i.MX351 and
its core is clocked to 523Mhz. We have connected a 7 inch display with
a resolution of 800x480 pixels directly to the arm. The display is
working but the performance with qt embedded is very poor. When the
complete display content changes, e.g. from red to green or from blue
to black, there is a bad "wipe effect". The new display content wipes
from the top down to the bottom of the display.

To test the performance without qt embedded I wrote a small c program
which writes a color array directly to the framebuffer device
(/dev/fb0). This program updates the complete framebuffer content
every second. From red to green, from green to blue, from blue to
black and so on. The "wipe effect" is also visible. But less
pronounced than with qt embedded. Shure qt embedded decreases the
performance, but I don`t think this is the core issue for my
performance problems.

There is another point I noticed. The defaut bpp (bit per pixel) value
in the driver is 16. Changing the drivers bpp up to 32 decreases the
performance rapidly. To change the bpp I used the kernel parameter
video=mx3fb:bpp=32.

So I think the core issue is either the performace of the arm itself,
the ram throughput or the driver mx3fb.c. Maybe someone who uses a
similar design could share some information about the performance of
this design. Also I will be gratefull for hints to increase my
performance or to find the bottleneck.

Thanks.


---
Johannes


From axel.lin at ingics.com  Fri Jul 12 04:15:15 2013
From: axel.lin at ingics.com (Axel Lin)
Date: Fri, 12 Jul 2013 16:15:15 +0800
Subject: [PATCH] clk: sunxi: Fix checking return value of
 clk_register_[composite|factors]
Message-ID: <1373616915.24328.1.camel@phoenix>

clk_register_composite() and clk_register_factors() return ERR_PTR on error.

Signed-off-by: Axel Lin <axel.lin at ingics.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 412912b..02e440b 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -64,7 +64,7 @@ static void __init sunxi_osc_clk_setup(struct device_node *node)
 			&gate->hw, &clk_gate_ops,
 			CLK_IS_ROOT);
 
-	if (clk) {
+	if (!IS_ERR(clk)) {
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
 		clk_register_clkdev(clk, clk_name, NULL);
 	}
@@ -221,7 +221,7 @@ static void __init sunxi_factors_clk_setup(struct device_node *node,
 	clk = clk_register_factors(NULL, clk_name, parent, 0, reg,
 				   data->table, data->getter, &clk_lock);
 
-	if (clk) {
+	if (!IS_ERR(clk)) {
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
 		clk_register_clkdev(clk, clk_name, NULL);
 	}
-- 
1.8.1.2





From b32955 at freescale.com  Fri Jul 12 03:56:11 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Fri, 12 Jul 2013 15:56:11 +0800
Subject: [PATCH rebased 1/2] ARM: dts: imx6qdl: add a new pinctrl for uart3
Message-ID: <1373615772-30665-1-git-send-email-b32955@freescale.com>

Add the a new pinctrl for uart3. In the imx6q{dl}-sabreauto boards,
the uart3 is used for Bluetooth.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6qdl.dtsi |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 5ca82bf..a050865 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1028,6 +1028,17 @@
 					};
 				};
 
+				uart3 {
+					pinctrl_uart3_1: uart3grp-1 {
+						fsl,pins = <
+							PAD_SD4_CLK__UART3_RX_DATA 0x1b0b1
+							PAD_SD4_CMD__UART3_TX_DATA 0x1b0b1
+							PAD_EIM_D30__UART3_CTS_B   0x1b0b1
+							PAD_EIM_EB3__UART3_RTS_B   0x1b0b1
+						>;
+					};
+				};
+
 				uart4 {
 					pinctrl_uart4_1: uart4grp-1 {
 						fsl,pins = <
-- 
1.7.1




From b32955 at freescale.com  Fri Jul 12 03:56:12 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Fri, 12 Jul 2013 15:56:12 +0800
Subject: [PATCH rebased 2/2] ARM: dts: imx6qdl-sabreauto: add a DT node for
 uart3
In-Reply-To: <1373615772-30665-1-git-send-email-b32955@freescale.com>
References: <1373615772-30665-1-git-send-email-b32955@freescale.com>
Message-ID: <1373615772-30665-2-git-send-email-b32955@freescale.com>

Add a DT node for uart3, in the imx6q{dl}-sabreauto boards,
the uart3 is used by Bluetooth.

Since the uart3 has pin conflict with gpmi and weim nor, we keep it
disabled by default.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 365e8ff..70a8bf1 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -67,6 +67,15 @@
 	};
 };
 
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart3_1>;
+	fsl,uart-has-rtscts;
+	dma-names = "rx", "tx";
+	dmas = <&sdma 29 4 0>, <&sdma 30 4 0>;
+	status = "disabled"; /* used by the BT, pin conflict with gpmi and weim NOR */
+};
+
 &uart4 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart4_1>;
-- 
1.7.1




From peter.chen at freescale.com  Fri Jul 12 04:25:01 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 12 Jul 2013 16:25:01 +0800
Subject: [PATCH v12 06/13] usb: chipidea: add otg_cap attribute for otg
 capable
In-Reply-To: <871u742o4u.fsf@ashishki-desk.ger.corp.intel.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <1373524041-10482-7-git-send-email-peter.chen@freescale.com>
 <871u742o4u.fsf@ashishki-desk.ger.corp.intel.com>
Message-ID: <20130712082500.GA16202@nchen-desktop>

On Fri, Jul 12, 2013 at 11:12:01AM +0300, Alexander Shishkin wrote:
> Peter Chen <peter.chen at freescale.com> writes:
> 
> > Since we need otgsc to know vbus's status at some chipidea
> > controllers even it is peripheral-only mode. Besides, some
> > SoCs (eg, AR9331 SoC) don't have otgsc register even
> > the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS.
> > We inroduce otg_cap attribute to indicate if the controller
> > is otg capable, defaultly, we follow the rule that if DCCPARAMS_DC
> > and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS are otg capable, but if there
> > is exception, the platform can override it by device tree or platform data.
> >
> > Signed-off-by: Peter Chen <peter.chen at freescale.com>
> > ---
> 
> [...]
> 
> > diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
> > index 118bf66..0a906b4 100644
> > --- a/include/linux/usb/chipidea.h
> > +++ b/include/linux/usb/chipidea.h
> > @@ -7,6 +7,12 @@
> >  
> >  #include <linux/usb/otg.h>
> >  
> > +enum usb_otg_cap {
> > +	OTG_CAP_ATTR_IS_NOT_EXISTED = 0,
> > +	OTG_CAP_ATTR_IS_TRUE,
> > +	OTG_CAP_ATTR_IS_FALSE,
> > +};
> 
> We don't really need all three, do we? We only need to know if the
> controller *can't* do otg. The rest we can infer from dr_mode and
> DCCPARAMS. So it can be another bit in flags rather than a separate
> field in platdata.
> 

In order to cover below two cases, I have no other idea.

1. For mips Soc (ARxxx), if dr_mode = otg and it is 1 for both
mode at DCCPARAMS,  It can switch role through proc or whatever,
but NO otgsc register, it is NOT otg-capable.

2. For peripheral-only case at most chipidea controllers,
the dr_mode = peripheral and it is 1 for both modes at DCCPARAMS,
the otgsc can be visited, it is otg-capable.

-- 

Best Regards,
Peter Chen



From peter.chen at freescale.com  Fri Jul 12 04:26:43 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 12 Jul 2013 16:26:43 +0800
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <201307120604.43642.marex@denx.de>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <201307111957.19537.marex@denx.de>
 <20130712031200.GB14793@nchen-desktop>
 <201307120604.43642.marex@denx.de>
Message-ID: <20130712082642.GB16202@nchen-desktop>

On Fri, Jul 12, 2013 at 06:04:43AM +0200, Marek Vasut wrote:
> Hi Peter,
> 
> > On Thu, Jul 11, 2013 at 07:57:19PM +0200, Marek Vasut wrote:
> > > Hi Peter,
> > > 
> > > > This patchset adds tested otg id switch function and
> > > > vbus connect and disconnect detection for chipidea driver.
> > > > And fix kinds of bugs found at chipidea drivers after enabling
> > > > id and vbus detection.
> > > > 
> > > > This patch is fully tested at imx6 sabresd platform.
> > > > My chipidea repo: https://github.com/hzpeterchen/linux-usb.git
> > > > 
> > > > Changes for v12:
> > > > - Rebased greg's usb-next tree (3.10.0-rc7+)
> > > > - Split more small patches for single function and fix.
> > > 
> > > I tested the patchset. Here are the results:
> > > 
> > > - VBUS switching
> > > 
> > > I'm no longer getting any ID interrupts at all when I apply the patch
> > > below. The board stays in HOST mode all the time. If I configure it as
> > > peripheral, it works as peripheral. Note with [1], I was able to switch
> > > from Peripheral->Host , not the other way around.
> > 
> > Thanks for your testing. But first, can you have me check
> > if your ID wakeup is enabled?
> 
> ID wakeup? How do I check?
> 

See otgsc at controller register, the ID wakeup enable is bit 24.

-- 

Best Regards,
Peter Chen



From shawn.guo at linaro.org  Fri Jul 12 04:31:17 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Jul 2013 16:31:17 +0800
Subject: [PATCH v2] ARM: dts: add more imx6q/dl pin groups
Message-ID: <1373617877-18198-1-git-send-email-shawn.guo@linaro.org>

Add more imx6q/dl pin groups for those supported boards, e.g. sabresd,
sabreauto, arm2.

IPU2 pin groups are added into imx6q.dtsi, since the block is only
available on imx6q.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
Changes since v1:
* Use prefix MX6QDL_ in macro names

 arch/arm/boot/dts/imx6q.dtsi   |   36 +++++
 arch/arm/boot/dts/imx6qdl.dtsi |  285 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 321 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 5e6c7f3..778f833 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -73,6 +73,42 @@
 
 			iomuxc: iomuxc at 020e0000 {
 				compatible = "fsl,imx6q-iomuxc";
+
+				ipu2 {
+					pinctrl_ipu2_1: ipu2grp-1 {
+						fsl,pins = <
+							MX6QDL_PAD_DI0_DISP_CLK__IPU2_DI0_DISP_CLK 0x10
+							MX6QDL_PAD_DI0_PIN15__IPU2_DI0_PIN15       0x10
+							MX6QDL_PAD_DI0_PIN2__IPU2_DI0_PIN02        0x10
+							MX6QDL_PAD_DI0_PIN3__IPU2_DI0_PIN03        0x10
+							MX6QDL_PAD_DI0_PIN4__IPU2_DI0_PIN04        0x80000000
+							MX6QDL_PAD_DISP0_DAT0__IPU2_DISP0_DATA00   0x10
+							MX6QDL_PAD_DISP0_DAT1__IPU2_DISP0_DATA01   0x10
+							MX6QDL_PAD_DISP0_DAT2__IPU2_DISP0_DATA02   0x10
+							MX6QDL_PAD_DISP0_DAT3__IPU2_DISP0_DATA03   0x10
+							MX6QDL_PAD_DISP0_DAT4__IPU2_DISP0_DATA04   0x10
+							MX6QDL_PAD_DISP0_DAT5__IPU2_DISP0_DATA05   0x10
+							MX6QDL_PAD_DISP0_DAT6__IPU2_DISP0_DATA06   0x10
+							MX6QDL_PAD_DISP0_DAT7__IPU2_DISP0_DATA07   0x10
+							MX6QDL_PAD_DISP0_DAT8__IPU2_DISP0_DATA08   0x10
+							MX6QDL_PAD_DISP0_DAT9__IPU2_DISP0_DATA09   0x10
+							MX6QDL_PAD_DISP0_DAT10__IPU2_DISP0_DATA10  0x10
+							MX6QDL_PAD_DISP0_DAT11__IPU2_DISP0_DATA11  0x10
+							MX6QDL_PAD_DISP0_DAT12__IPU2_DISP0_DATA12  0x10
+							MX6QDL_PAD_DISP0_DAT13__IPU2_DISP0_DATA13  0x10
+							MX6QDL_PAD_DISP0_DAT14__IPU2_DISP0_DATA14  0x10
+							MX6QDL_PAD_DISP0_DAT15__IPU2_DISP0_DATA15  0x10
+							MX6QDL_PAD_DISP0_DAT16__IPU2_DISP0_DATA16  0x10
+							MX6QDL_PAD_DISP0_DAT17__IPU2_DISP0_DATA17  0x10
+							MX6QDL_PAD_DISP0_DAT18__IPU2_DISP0_DATA18  0x10
+							MX6QDL_PAD_DISP0_DAT19__IPU2_DISP0_DATA19  0x10
+							MX6QDL_PAD_DISP0_DAT20__IPU2_DISP0_DATA20  0x10
+							MX6QDL_PAD_DISP0_DAT21__IPU2_DISP0_DATA21  0x10
+							MX6QDL_PAD_DISP0_DAT22__IPU2_DISP0_DATA22  0x10
+							MX6QDL_PAD_DISP0_DAT23__IPU2_DISP0_DATA23  0x10
+						>;
+					};
+				};
 			};
 		};
 
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 15af09e..f1f7542 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -587,6 +587,14 @@
 							MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x80000000
 						>;
 					};
+
+					pinctrl_audmux_3: audmux-3 {
+						fsl,pins = <
+							MX6QDL_PAD_DISP0_DAT16__AUD5_TXC  0x80000000
+							MX6QDL_PAD_DISP0_DAT18__AUD5_TXFS 0x80000000
+							MX6QDL_PAD_DISP0_DAT19__AUD5_RXD  0x80000000
+						>;
+					};
 				};
 
 				ecspi1 {
@@ -681,6 +689,62 @@
 					};
 				};
 
+				esai {
+					pinctrl_esai_1: esaigrp-1 {
+						fsl,pins = <
+							MX6QDL_PAD_ENET_RXD0__ESAI_TX_HF_CLK 0x1b030
+							MX6QDL_PAD_ENET_CRS_DV__ESAI_TX_CLK  0x1b030
+							MX6QDL_PAD_ENET_RXD1__ESAI_TX_FS     0x1b030
+							MX6QDL_PAD_ENET_TX_EN__ESAI_TX3_RX2  0x1b030
+							MX6QDL_PAD_ENET_TXD1__ESAI_TX2_RX3   0x1b030
+							MX6QDL_PAD_ENET_TXD0__ESAI_TX4_RX1   0x1b030
+							MX6QDL_PAD_ENET_MDC__ESAI_TX5_RX0    0x1b030
+							MX6QDL_PAD_NANDF_CS2__ESAI_TX0       0x1b030
+							MX6QDL_PAD_NANDF_CS3__ESAI_TX1       0x1b030
+						>;
+					};
+
+					pinctrl_esai_2: esaigrp-2 {
+						fsl,pins = <
+							MX6QDL_PAD_ENET_CRS_DV__ESAI_TX_CLK 0x1b030
+							MX6QDL_PAD_ENET_RXD1__ESAI_TX_FS    0x1b030
+							MX6QDL_PAD_ENET_TX_EN__ESAI_TX3_RX2 0x1b030
+							MX6QDL_PAD_GPIO_5__ESAI_TX2_RX3     0x1b030
+							MX6QDL_PAD_ENET_TXD0__ESAI_TX4_RX1  0x1b030
+							MX6QDL_PAD_ENET_MDC__ESAI_TX5_RX0   0x1b030
+							MX6QDL_PAD_GPIO_17__ESAI_TX0        0x1b030
+							MX6QDL_PAD_NANDF_CS3__ESAI_TX1      0x1b030
+							MX6QDL_PAD_ENET_MDIO__ESAI_RX_CLK   0x1b030
+							MX6QDL_PAD_GPIO_9__ESAI_RX_FS       0x1b030
+						>;
+					};
+				};
+
+				flexcan1 {
+					pinctrl_flexcan1_1: flexcan1grp-1 {
+						fsl,pins = <
+							MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x80000000
+							MX6QDL_PAD_KEY_COL2__FLEXCAN1_TX 0x80000000
+						>;
+					};
+
+					pinctrl_flexcan1_2: flexcan1grp-2 {
+						fsl,pins = <
+							MX6QDL_PAD_GPIO_7__FLEXCAN1_TX   0x80000000
+							MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x80000000
+						>;
+					};
+				};
+
+				flexcan2 {
+					pinctrl_flexcan2_1: flexcan2grp-1 {
+						fsl,pins = <
+							MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x80000000
+							MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x80000000
+						>;
+					};
+				};
+
 				gpmi-nand {
 					pinctrl_gpmi_nand_1: gpmi-nand-1 {
 						fsl,pins = <
@@ -705,6 +769,43 @@
 					};
 				};
 
+				hdmi_hdcp {
+					pinctrl_hdmi_hdcp_1: hdmihdcpgrp-1 {
+						fsl,pins = <
+							MX6QDL_PAD_KEY_COL3__HDMI_TX_DDC_SCL 0x4001b8b1
+							MX6QDL_PAD_KEY_ROW3__HDMI_TX_DDC_SDA 0x4001b8b1
+						>;
+					};
+
+					pinctrl_hdmi_hdcp_2: hdmihdcpgrp-2 {
+						fsl,pins = <
+							MX6QDL_PAD_EIM_EB2__HDMI_TX_DDC_SCL 0x4001b8b1
+							MX6QDL_PAD_EIM_D16__HDMI_TX_DDC_SDA 0x4001b8b1
+						>;
+					};
+
+					pinctrl_hdmi_hdcp_3: hdmihdcpgrp-3 {
+						fsl,pins = <
+							MX6QDL_PAD_EIM_EB2__HDMI_TX_DDC_SCL  0x4001b8b1
+							MX6QDL_PAD_KEY_ROW3__HDMI_TX_DDC_SDA 0x4001b8b1
+						>;
+					};
+				};
+
+				hdmi_cec {
+					pinctrl_hdmi_cec_1: hdmicecgrp-1 {
+						fsl,pins = <
+							MX6QDL_PAD_EIM_A25__HDMI_TX_CEC_LINE 0x1f8b0
+						>;
+					};
+
+					pinctrl_hdmi_cec_2: hdmicecgrp-2 {
+						fsl,pins = <
+							MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
+						>;
+					};
+				};
+
 				i2c1 {
 					pinctrl_i2c1_1: i2c1grp-1 {
 						fsl,pins = <
@@ -735,6 +836,13 @@
 							MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
 						>;
 					};
+
+					pinctrl_i2c2_3: i2c2grp-3 {
+						fsl,pins = <
+							MX6QDL_PAD_EIM_EB2__I2C2_SCL  0x4001b8b1
+							MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+						>;
+					};
 				};
 
 				i2c3 {
@@ -744,6 +852,153 @@
 							MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
 						>;
 					};
+
+					pinctrl_i2c3_2: i2c3grp-2 {
+						fsl,pins = <
+							MX6QDL_PAD_GPIO_3__I2C3_SCL 0x4001b8b1
+							MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
+						>;
+					};
+
+					pinctrl_i2c3_3: i2c3grp-3 {
+						fsl,pins = <
+							MX6QDL_PAD_GPIO_5__I2C3_SCL  0x4001b8b1
+							MX6QDL_PAD_GPIO_16__I2C3_SDA 0x4001b8b1
+						>;
+					};
+
+					pinctrl_i2c3_4: i2c3grp-4 {
+						fsl,pins = <
+							MX6QDL_PAD_GPIO_3__I2C3_SCL  0x4001b8b1
+							MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
+						>;
+					};
+				};
+
+				ipu1 {
+					pinctrl_ipu1_1: ipu1grp-1 {
+						fsl,pins = <
+							MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10
+							MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15       0x10
+							MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02        0x10
+							MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03        0x10
+							MX6QDL_PAD_DI0_PIN4__IPU1_DI0_PIN04        0x80000000
+							MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00   0x10
+							MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01   0x10
+							MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02   0x10
+							MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03   0x10
+							MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04   0x10
+							MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05   0x10
+							MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06   0x10
+							MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07   0x10
+							MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08   0x10
+							MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09   0x10
+							MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10  0x10
+							MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11  0x10
+							MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12  0x10
+							MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13  0x10
+							MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14  0x10
+							MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15  0x10
+							MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16  0x10
+							MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17  0x10
+							MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18  0x10
+							MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19  0x10
+							MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20  0x10
+							MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21  0x10
+							MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22  0x10
+							MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23  0x10
+						>;
+					};
+
+					pinctrl_ipu1_2: ipu1grp-2 { /* parallel camera */
+						fsl,pins = <
+							MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12    0x80000000
+							MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13    0x80000000
+							MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14    0x80000000
+							MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15    0x80000000
+							MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16    0x80000000
+							MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17    0x80000000
+							MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18    0x80000000
+							MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19    0x80000000
+							MX6QDL_PAD_CSI0_DATA_EN__IPU1_CSI0_DATA_EN 0x80000000
+							MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK   0x80000000
+							MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC      0x80000000
+							MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC     0x80000000
+						>;
+					};
+
+					pinctrl_ipu1_3: ipu1grp-3 { /* parallel port 16-bit */
+						fsl,pins = <
+							MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04   0x80000000
+							MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05   0x80000000
+							MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06   0x80000000
+							MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07   0x80000000
+							MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08   0x80000000
+							MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09   0x80000000
+							MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10  0x80000000
+							MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11  0x80000000
+							MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12  0x80000000
+							MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13  0x80000000
+							MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14  0x80000000
+							MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15  0x80000000
+							MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16  0x80000000
+							MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17  0x80000000
+							MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18  0x80000000
+							MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19  0x80000000
+							MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x80000000
+							MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC    0x80000000
+							MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC   0x80000000
+						>;
+					};
+				};
+
+				mlb {
+					pinctrl_mlb_1: mlbgrp-1 {
+						fsl,pins = <
+							MX6QDL_PAD_GPIO_3__MLB_CLK  0x71
+							MX6QDL_PAD_GPIO_6__MLB_SIG  0x71
+							MX6QDL_PAD_GPIO_2__MLB_DATA 0x71
+						>;
+					};
+
+					pinctrl_mlb_2: mlbgrp-2 {
+						fsl,pins = <
+							MX6QDL_PAD_ENET_TXD1__MLB_CLK 0x71
+							MX6QDL_PAD_GPIO_6__MLB_SIG    0x71
+							MX6QDL_PAD_GPIO_2__MLB_DATA   0x71
+						>;
+					};
+				};
+
+				pwm0 {
+					pinctrl_pwm0_1: pwm0grp-1 {
+						fsl,pins = <
+							MX6QDL_PAD_SD1_DAT3__PWM1_OUT 0x1b0b1
+						>;
+					};
+				};
+
+				pwm3 {
+					pinctrl_pwm3_1: pwm3grp-1 {
+						fsl,pins = <
+							MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
+						>;
+					};
+				};
+
+				spdif {
+					pinctrl_spdif_1: spdifgrp-1 {
+						fsl,pins = <
+							MX6QDL_PAD_KEY_COL3__SPDIF_IN 0x1b0b0
+						>;
+					};
+
+					pinctrl_spdif_2: spdifgrp-2 {
+						fsl,pins = <
+							MX6QDL_PAD_GPIO_16__SPDIF_IN  0x1b0b0
+							MX6QDL_PAD_GPIO_17__SPDIF_OUT 0x1b0b0
+						>;
+					};
 				};
 
 				uart1 {
@@ -796,6 +1051,36 @@
 					};
 				};
 
+				usbh2 {
+					pinctrl_usbh2_1: usbh2grp-1 {
+						fsl,pins = <
+							MX6QDL_PAD_RGMII_TXC__USB_H2_DATA      0x40013030
+							MX6QDL_PAD_RGMII_TX_CTL__USB_H2_STROBE 0x40013030
+						>;
+					};
+
+					pinctrl_usbh2_2: usbh2grp-2 {
+						fsl,pins = <
+							MX6QDL_PAD_RGMII_TX_CTL__USB_H2_STROBE 0x40017030
+						>;
+					};
+				};
+
+				usbh3 {
+					pinctrl_usbh3_1: usbh3grp-1 {
+						fsl,pins = <
+							MX6QDL_PAD_RGMII_RX_CTL__USB_H3_DATA 0x40013030
+							MX6QDL_PAD_RGMII_RXC__USB_H3_STROBE  0x40013030
+						>;
+					};
+
+					pinctrl_usbh3_2: usbh3grp-2 {
+						fsl,pins = <
+							MX6QDL_PAD_RGMII_RXC__USB_H3_STROBE 0x40017030
+						>;
+					};
+				};
+
 				usdhc2 {
 					pinctrl_usdhc2_1: usdhc2grp-1 {
 						fsl,pins = <
-- 
1.7.9.5




From tony at atomide.com  Fri Jul 12 04:32:28 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Jul 2013 01:32:28 -0700
Subject: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and
 twl6040 setup for legacy boot
In-Reply-To: <51DFBAC0.5070806@ti.com>
References: <1373552638-13930-1-git-send-email-peter.ujfalusi@ti.com>
 <20130712072650.GC7656@atomide.com> <51DFBAC0.5070806@ti.com>
Message-ID: <20130712083227.GF7656@atomide.com>

* Peter Ujfalusi <peter.ujfalusi at ti.com> [130712 01:20]:
> On 07/12/2013 09:26 AM, Tony Lindgren wrote:
> > * Peter Ujfalusi <peter.ujfalusi at ti.com> [130711 07:30]:
> >> OMAP4 no longer boots in legacy mode so the code here is no longer used.
> >>
> >> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> >> ---
> >>  arch/arm/mach-omap2/twl-common.c | 332 ++-------------------------------------
> >>  arch/arm/mach-omap2/twl-common.h |   8 -
> >>  2 files changed, 12 insertions(+), 328 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
> >> index c05898f..932dea7 100644
> >> --- a/arch/arm/mach-omap2/twl-common.c
> >> +++ b/arch/arm/mach-omap2/twl-common.c
> >> @@ -38,20 +38,6 @@ static struct i2c_board_info __initdata pmic_i2c_board_info = {
> >>  	.flags		= I2C_CLIENT_WAKE,
> >>  };
> >>  
> >> -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> >> -static int twl_set_voltage(void *data, int target_uV)
> >> -{
> >> -	struct voltagedomain *voltdm = (struct voltagedomain *)data;
> >> -	return voltdm_scale(voltdm, target_uV);
> >> -}
> >> -
> >> -static int twl_get_voltage(void *data)
> >> -{
> >> -	struct voltagedomain *voltdm = (struct voltagedomain *)data;
> >> -	return voltdm_get_voltage(voltdm);
> >> -}
> >> -#endif
> > 
> > Looks like the code above is also needed for omap3 based on the
> > if defined?
> 
> Yes it is still needed for OMAP3 when booting in legacy. I have moved these
> two function down within the #if defined(CONFIG_ARCH_OMAP3) :
> 
>  #if defined(CONFIG_ARCH_OMAP3)
> @@ -189,6 +160,18 @@ static struct regulator_init_data omap3_vdd2 = {
>  	.consumer_supplies		= omap3_vdd2_supply,
>  };
> 
> +static int twl_set_voltage(void *data, int target_uV)
> +{
> +	struct voltagedomain *voltdm = (struct voltagedomain *)data;
> +	return voltdm_scale(voltdm, target_uV);
> +}
> +
> +static int twl_get_voltage(void *data)
> +{
> +	struct voltagedomain *voltdm = (struct voltagedomain *)data;
> +	return voltdm_get_voltage(voltdm);
> +}
> +
>  static struct twl_regulator_driver_data omap3_vdd1_drvdata = {
>  	.get_voltage = twl_get_voltage,
>  	.set_voltage = twl_set_voltage,
> @@ -235,297 +218,6 @@ void __init omap3_pmic_get_config(struct
> twl4030_platform_data *pmic_data,
>  }
>  #endif /* CONFIG_ARCH_OMAP3 */

Oh OK sorry I missed that while glancing over it.

Regards,

Tony


From shawn.guo at linaro.org  Fri Jul 12 04:33:13 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Jul 2013 16:33:13 +0800
Subject: [PATCH] ARM: dts: imx: share pad macro names between imx6q and
 imx6dl
In-Reply-To: <20130712064957.GH14452@pengutronix.de>
References: <1373522316-12319-1-git-send-email-shawn.guo@linaro.org>
 <20130712064957.GH14452@pengutronix.de>
Message-ID: <20130712083311.GF25501@S2101-09.ap.freescale.net>

On Fri, Jul 12, 2013 at 08:49:57AM +0200, Sascha Hauer wrote:
> Hi Shawn,
> 
> Nice patch.
> 
> On Thu, Jul 11, 2013 at 01:58:36PM +0800, Shawn Guo wrote:
> > The imx6q and imx6dl are two pin-to-pin compatible SoCs.  The same board
> > design can work with either chip plugged into the socket, e.g. sabresd
> > and sabreauto boards.
> > 
> > We currently define pin groups in imx6q.dtsi and imx6dl.dtsi
> > respectively because the pad macro names are different between two
> > chips.  This brings a maintenance burden on having the same label point
> > to the same pin group defined in two places.
> > 
> > The patch drops prefix MX6Q_ and MX6DL_ from those pad macro names.
> 
> Can we use another prefix instead of removing it completely? Maybe
> MX6QDL_?
> 
Sounds good.  I changed it on my branch, and will not resend due to the
patch size.

Shawn



From shawn.guo at linaro.org  Fri Jul 12 04:38:16 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Jul 2013 16:38:16 +0800
Subject: [PATCH rebased 1/2] ARM: dts: imx6qdl: add a new pinctrl for uart3
In-Reply-To: <1373615772-30665-1-git-send-email-b32955@freescale.com>
References: <1373615772-30665-1-git-send-email-b32955@freescale.com>
Message-ID: <20130712083814.GG25501@S2101-09.ap.freescale.net>

On Fri, Jul 12, 2013 at 03:56:11PM +0800, Huang Shijie wrote:
> Add the a new pinctrl for uart3. In the imx6q{dl}-sabreauto boards,
> the uart3 is used for Bluetooth.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>

Applied (with updating macros to use prefix MX6QDL_), thanks.



From shawn.guo at linaro.org  Fri Jul 12 04:40:27 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Jul 2013 16:40:27 +0800
Subject: [PATCH rebased 2/2] ARM: dts: imx6qdl-sabreauto: add a DT node
 for uart3
In-Reply-To: <1373615772-30665-2-git-send-email-b32955@freescale.com>
References: <1373615772-30665-1-git-send-email-b32955@freescale.com>
 <1373615772-30665-2-git-send-email-b32955@freescale.com>
Message-ID: <20130712084025.GH25501@S2101-09.ap.freescale.net>

On Fri, Jul 12, 2013 at 03:56:12PM +0800, Huang Shijie wrote:
> Add a DT node for uart3, in the imx6q{dl}-sabreauto boards,
> the uart3 is used by Bluetooth.
> 
> Since the uart3 has pin conflict with gpmi and weim nor, we keep it
> disabled by default.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>
> ---
>  arch/arm/boot/dts/imx6qdl-sabreauto.dtsi |    9 +++++++++
>  1 files changed, 9 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> index 365e8ff..70a8bf1 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> @@ -67,6 +67,15 @@
>  	};
>  };
>  
> +&uart3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart3_1>;
> +	fsl,uart-has-rtscts;

> +	dma-names = "rx", "tx";
> +	dmas = <&sdma 29 4 0>, <&sdma 30 4 0>;

These two properties should be added in imx6qdl.dtsi

Shawn

> +	status = "disabled"; /* used by the BT, pin conflict with gpmi and weim NOR */
> +};
> +
>  &uart4 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_uart4_1>;
> -- 
> 1.7.1
> 
> 



From shawn.guo at linaro.org  Fri Jul 12 04:45:18 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 12 Jul 2013 16:45:18 +0800
Subject: [PATCH] ARM: dts: imx25: Make lcdc compatible to imx27/imx21 fb
In-Reply-To: <1373614495-21717-1-git-send-email-weisserm@arcor.de>
References: <1373614495-21717-1-git-send-email-weisserm@arcor.de>
Message-ID: <20130712084516.GI25501@S2101-09.ap.freescale.net>

On Fri, Jul 12, 2013 at 09:34:54AM +0200, Matthias Weisser wrote:
> ARM: dts: imx25: Make lcdc compatible to imx27/imx21 fb
> 
> Signed-off-by: Matthias Weisser <weisserm at arcor.de>
> ---
>  arch/arm/boot/dts/imx25.dtsi |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
> index d2550e0..83532b6 100644
> --- a/arch/arm/boot/dts/imx25.dtsi
> +++ b/arch/arm/boot/dts/imx25.dtsi
> @@ -377,7 +377,8 @@
>  				status = "disabled";
>  			};
>  
> -			lcdc at 53fbc000 {
> +			lcdc: lcdc at 53fbc000 {
> +				compatible = "fsl,imx27-fb", "fsl,imx21-fb";

It makes more sense to have it be:

	compatible = "fsl,imx25-fb", "fsl,imx21-fb";

Shawn

>  				reg = <0x53fbc000 0x4000>;
>  				interrupts = <39>;
>  				clocks = <&clks 103>, <&clks 66>, <&clks 49>;
> -- 
> 1.7.9.5
> 



From b32955 at freescale.com  Fri Jul 12 04:50:58 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Fri, 12 Jul 2013 16:50:58 +0800
Subject: [PATCH rebased 2/2] ARM: dts: imx6qdl-sabreauto: add a DT node
 for uart3
In-Reply-To: <20130712084025.GH25501@S2101-09.ap.freescale.net>
References: <1373615772-30665-1-git-send-email-b32955@freescale.com>
 <1373615772-30665-2-git-send-email-b32955@freescale.com>
 <20130712084025.GH25501@S2101-09.ap.freescale.net>
Message-ID: <51DFC372.2020309@freescale.com>

? 2013?07?12? 16:40, Shawn Guo ??:
>> >  +&uart3 {
>> >  +	pinctrl-names = "default";
>> >  +	pinctrl-0 =<&pinctrl_uart3_1>;
>> >  +	fsl,uart-has-rtscts;
>> >  +	dma-names = "rx", "tx";
>> >  +	dmas =<&sdma 29 4 0>,<&sdma 30 4 0>;
> These two properties should be added in imx6qdl.dtsi
the uart3 may does _not_ have the RTS/CTS pins except in the 
imx6q{dl}-sabreauto boards.

Is it proper to add the dma property in the imx6qdl.dtsi?


thanks
Huang Shijie



From thomas.petazzoni at free-electrons.com  Fri Jul 12 04:59:03 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 12 Jul 2013 10:59:03 +0200
Subject: pci-mvebu driver on km_kirkwood
In-Reply-To: <51DE58DF.5010304@keymile.com>
References: <51DD88A4.1030506@keymile.com> <20130710185706.72b124a4@skate>
 <51DD9A8C.10608@keymile.com> <51DE58DF.5010304@keymile.com>
Message-ID: <20130712105903.6336e912@skate>

Dear Valentin Longchamp,

On Thu, 11 Jul 2013 09:03:59 +0200, Valentin Longchamp wrote:

> On the board you are currently using for your tests, it is the case (the whole
> map is not used ... things are scattered over the 256 MB, with one 128MB BAR).
> If you want to get rid of this problem, we have another board that does not
> require these (256 MB .. and I have one of them on my desk that you can use for
> your tests).
> 
> On the kirkwood variant we use, there is only _one_ real PCIe controller. In
> order to map 256MB for the MEM space of this controller without having further
> memory map conflicts, what was done was to not enable the CPU windows for the
> usual 2nd PCIe controller and set a wider CPU window for the MEM space of the
> only PCIe controller.

Such tricks are no longer needed with the new PCIe driver. Instead of
assigning address ranges per PCIe controller, the new PCIe driver
(together with the mvebu-mbus driver) allows to specify one global
range of addresses for PCIe mem, and the PCIe driver will automatically
figure out which devices are available on which PCIe bus, how much PCIe
mem then need, and create the MBus windows accordingly.

However of course, as I pointed out in an earlier e-mail, this global
range must be suitably sized to allow the mapping of all PCIe devices.
By default, we've made it 128 MB large, but in this case, it looks like
you would need 256 MB.

But there's no need to disable the second PCIe controller anymore. If
there's nothing connected to it, not PCIe window will be created for it.

> > - we need a virtual PCIe device to connect to the internal switch, which 
> > must be mapped at 0xf4000000 (normally used for the NAND which must then 
> > move to 0xff000000)
> > 
> 
> I think you can forget this for the time being. This is called (also in
> Marvell's doc) a virtual PCIe controller, but apart that it is then memory
> mapped, this has nothing to do with PCIe (although I don't know what is done
> internally in the SoC). It is a problem because the physical address chosen for
> this CPU window conflicts with the one that is used for the NAND controller in
> the current kirkwood Linux memory map. But this is another topic and it should
> not play any role in this PCIe topic.

I'm not sure to follow this story of a virtual PCIe controller sitting
at 0xf4000000. Can you give a few more details?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From peter.ujfalusi at ti.com  Fri Jul 12 04:59:41 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Fri, 12 Jul 2013 10:59:41 +0200
Subject: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and
 twl6040 setup for legacy boot
In-Reply-To: <20130711163503.GA6611@kahuna>
References: <1373552638-13930-1-git-send-email-peter.ujfalusi@ti.com>
 <20130711145916.GA6138@kahuna> <51DED333.9080609@ti.com>
 <20130711163503.GA6611@kahuna>
Message-ID: <51DFC57D.2020905@ti.com>

On 07/11/2013 06:35 PM, Nishanth Menon wrote:
> right - now that we removed the set_voltage/get_voltage custom code,
> there are no longer any way the code introduced in the commit can be
> exercised.

If we boot with DT (which is the case with OMAP4/5) this part was not even
executed, so the custom callbacks were not added from here for OMAP4. I might
be wrong here...

-- 
P?ter


From rnayak at ti.com  Fri Jul 12 04:59:56 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 12 Jul 2013 14:29:56 +0530
Subject: [PATCH 1/2] Revert "ARM: OMAP2+: Fix serial init for device tree
 based booting"
In-Reply-To: <20130712080305.GD7656@atomide.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
 <1373539986-27272-2-git-send-email-rnayak@ti.com>
 <20130712072051.GA7656@atomide.com> <51DFB0E4.6040007@ti.com>
 <20130712080305.GD7656@atomide.com>
Message-ID: <51DFC58C.7030105@ti.com>

On Friday 12 July 2013 01:33 PM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak at ti.com> [130712 00:38]:
>> On Friday 12 July 2013 12:50 PM, Tony Lindgren wrote:
>>> * Rajendra Nayak <rnayak at ti.com> [130711 03:59]:
>>>> This reverts commit 82702ea11ddfe0e43382e1fa5b66d807d8114916.
>>>>
>>>> The above commit stubbed out omap_serial_early_init() in case of
>>>> DT build thinking it was doing the serial port initializations.
>>>
>>> Well not really. It was done to cut dependency between device
>>> tree initialized drivers and pdata initialized drivers.
>>>  
>>>> omap_serial_early_init() however does not do the serial port
>>>> inits (its instead done by omap_serial_init_port()) instead
>>>> it sets the HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags
>>>> for the console uart which causes hwmod to avoid doing a reset
>>>> followed by the idling of the console uart.
>>>>
>>>> This is still needed even in the DT case.
>>>
>>> This fix is going the wrong way.
>>>
>>> The console is working fine with DT based booting for me,
>>> except for the earlyprintk fix needed.
>>
>> It works on omap4 and omap5. It won't work on any
>> am33xx devices.
> 
> OK. I assume the regular serial onsole works just fine, what does
> not work is the earlyprintk for am33xx?

Yes, thats right.

> 
>>> And there should not be any need to parse cmdline for console
>>> as omap-serial.c sets it up and already knows about it.
>>>
>>> Care to state what exactly this attempts to fix and for which
>>> omaps? If this is only needed for am33xx, then why?
>>
>> Yes, this is needed only for am33xx because am33xx hwmod rightly
>> had the hwmod flags for NO_IDLE and NO_RESET removed and omap4
>> and omap5 wrongly still carry them around.
> 
> OK.
>  
>> Just try applying PATCH 2/2 of this series and it won't work on the
>> omap4 sdp anymore.
> 
> OK, so that's only for earlyprintk then?

yes,

> 
> If so, it seems the right fix is to set the NO_IDLE and NO_RESET
> flags based on ifdef CONFIG_DEBUG_OMAP4UART3 etc as that is selected
> in the Kconfig now.

ok makes sense. It seems like the static data in hwmod can be populated
based on these defines? something like

/* uart3 */
static struct omap_hwmod omap44xx_uart3_hwmod = {
        .name           = "uart3",
        .class          = &omap44xx_uart_hwmod_class,
        .clkdm_name     = "l4_per_clkdm",
#ifdef CONFIG_DEBUG_OMAP4UART3
        .flags          = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
                                HWMOD_SWSUP_SIDLE_ACT,
#else
        .flags          = HWMOD_SWSUP_SIDLE_ACT,
#endif
        .main_clk       = "func_48m_fclk",
        .prcm = {
                .omap4 = {
                        .clkctrl_offs = OMAP4_CM_L4PER_UART3_CLKCTRL_OFFSET,
                        .context_offs = OMAP4_RM_L4PER_UART3_CONTEXT_OFFSET,
                        .modulemode   = MODULEMODE_SWCTRL,
                },
        },
};

And same way for others? That way the cmdline parsing can be done away
with even for the non-DT case.

> 
> The current code in mach-omap2/serial.c is wrong, and is a hack
> needed for the pdata based booting. What's broken is that
> omap_serial_early_init() parses the cmdline for console, which
> itself is pretty nasty, and it won't work the right way as
> there's nothing stopping from having the earlycon in a different
> UART from the serial console. So we just want to get rid of the
> whole mach-omap2/serial.c once we're all DT.
> 
> So to summarize, we have two bugs:
> 
> 1. Omap hwmod code can reset UART while earlycon may be using
>    it. The fix to this is to use NO_IDLE and NO_RESET flags in
>    the hwmod code if CONFIG_DEBUG_OMAPxUARTy is specified.
> 
> 2. A bug in drivers/tty/serial/omap-serial.c where the
>    missing context loss count can cause NULL context to be
>    initialized during driver probe causing port to hang for
>    earlycon. The fix for that is what Felipe has suggested or
>    fix it in the driver by removing the context loss count usage
>    and detect the need for context restore based on the UART
>    state.
> 
> Or am I still missing something?

No, thats pretty much the 2 issues we have.

regards,
Rajendra
> 
> Regards,
> 
> Tony
> 



From peter.ujfalusi at ti.com  Fri Jul 12 05:09:51 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Fri, 12 Jul 2013 11:09:51 +0200
Subject: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c
In-Reply-To: <20130709082304.GB5523@atomide.com>
References: <20130517191304.468.73487.stgit@localhost>
 <20130517191751.468.89202.stgit@localhost>
 <20130520095447.GR21614@n2100.arm.linux.org.uk>
 <20130706131057.GU21614@n2100.arm.linux.org.uk>
 <20130706133627.GV21614@n2100.arm.linux.org.uk>
 <20130708093410.GT5523@atomide.com>
 <20130708142103.GX21614@n2100.arm.linux.org.uk>
 <20130709082304.GB5523@atomide.com>
Message-ID: <51DFC7DF.7050806@ti.com>

On 07/09/2013 10:23 AM, Tony Lindgren wrote:
>> ASoC looks dead too:
>>
>> omap-abe-twl6040 sound.10: ASoC: CPU DAI (null) not registered
>> omap-abe-twl6040 sound.10: snd_soc_register_card() failed: -517
> 
> Peter, I think you've had audio working with devicetree for at least
> a year or something?

Yes it has been working and going to work soon again:
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-July/063909.html

With the DMA devicetree bindings platform_get_resource_byname() stopped
working for DMA (it works for MEM resources) -> dai drivers were not probing.

-- 
P?ter


From broonie at kernel.org  Fri Jul 12 04:49:32 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 12 Jul 2013 09:49:32 +0100
Subject: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on
 Exynos5420
In-Reply-To: <CAAgF-BdM4jw0o4+ELVo_N029tbgMJBBqJxU91e=TgBNiiREyaA@mail.gmail.com>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
 <29860116.IF545KsGYb@thinkpad>
 <20130711112023.GM24508@sirena.org.uk>
 <2214161.FSfscAvpna@thinkpad>
 <20130711130139.GQ24508@sirena.org.uk>
 <CAAgF-BdM4jw0o4+ELVo_N029tbgMJBBqJxU91e=TgBNiiREyaA@mail.gmail.com>
Message-ID: <20130712084932.GY24508@sirena.org.uk>

On Fri, Jul 12, 2013 at 10:07:22AM +0530, Padma Venkat wrote:

> A new version number is added when a there was some change in the IP
> like adding a internal mux to the IP, adding multi channel support,
> adding reset control bit. This was done in the older code with
> platform device.
> Same thing is followed here. So as previously done, adding a new
> compatible name like "samsung,i2s-v6" with new quirk
> "samsung,supports-tdm" is okey?

Yes, this is good but the quirk should just be found by software based
on the compatible string rather than in the DT.
-------------- 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/20130712/957b5b54/attachment.sig>

From rogerq at ti.com  Fri Jul 12 05:15:27 2013
From: rogerq at ti.com (Roger Quadros)
Date: Fri, 12 Jul 2013 12:15:27 +0300
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51DEF0DE.4050607@denx.de>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de> <51DE87D3.5030600@ti.com>
 <51DEA7F1.1050902@denx.de> <51DEC2CE.70400@ti.com> <51DED076.3040000@denx.de>
 <51DEF0DE.4050607@denx.de>
Message-ID: <51DFC92F.1050701@ti.com>

Stefan,

On 07/11/2013 08:52 PM, Stefan Roese wrote:
> On 07/11/2013 05:34 PM, Stefan Roese wrote:
>> On 07/11/2013 04:35 PM, Roger Quadros wrote:
>>>> BTW: I noticed a git ID (8e1cacd) in your kernel that I can't identify.
>>>> Do you have any patches locally applied to the kernel.org version that
>>>> might be helpful with this USB issue I'm seeing?
>>>
>>> Yes I had tested it on a more recent kernel with some local patches applied
>>> that I've recently sent for review.
>>>
>>> But to cross check with your setup I've retested it with commit d2b4a646 
>>> with the 2 below patches on top
>>>
>>> https://lkml.org/lkml/2013/6/20/327
>>> https://lkml.org/lkml/2013/6/20/339
>>
>> Thanks. I have exactly those 2 patches applies as well. But on a
>> different git commit. And with some local (unrelated) patches as well.
>> I'll revert to exactly your version tomorrow and test again.
> 
> Okay. I changed to exactly this version: d2b4a646 with those 2 patches
> on top.
> 
>>> I've tried it again with the ELDK 5.3 root but still can't get it to fail.
>>>
>>> I think we should match our u-boot as well. Could you please let me know
>>> your u-boot commit and uEnv.txt?
>>
>> Good idea. I'm currently using a "dirty" local version. I'll try to
>> switch to an officially available version tomorrow. And send you the
>> version/git id.
> 
> I updated my U-Boot to the following version: Based on mainline git
> commit ID 225fd8c. Only this patch added:
> 
> http://patchwork.ozlabs.org/patch/256702/
> 
> This is needed for USB to work in U-Boot. Otherwise my external USB
> SMSC95xx will not be detected in U-Boot.

I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
as I don't have an external USB-ethernet adapter.
The above commit doesn't work well for beagle-xm, so my u-boot is on tag v2013.04
and you don't need that additional patch.

Can you please retest on it? Thanks.

You will need to set "usbethaddr" before starting USB else SMSC will not work.
e.g.
	setenv usbethaddr A6:66:4D:B0:69:04

Also could you please increase the Linux console message verbosity to debug (8), so that
all kernel messages are visible in the log? If it spits out something more than what you
sent last time then do send it to me.

Let's first sort out the beagle-xm problem, then we can see about old beagle.

cheers,
-roger


From tony at atomide.com  Fri Jul 12 05:18:27 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Jul 2013 02:18:27 -0700
Subject: [PATCH 1/2] Revert "ARM: OMAP2+: Fix serial init for device
 tree based booting"
In-Reply-To: <51DFC58C.7030105@ti.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
 <1373539986-27272-2-git-send-email-rnayak@ti.com>
 <20130712072051.GA7656@atomide.com> <51DFB0E4.6040007@ti.com>
 <20130712080305.GD7656@atomide.com> <51DFC58C.7030105@ti.com>
Message-ID: <20130712091827.GH7656@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130712 02:06]:
> On Friday 12 July 2013 01:33 PM, Tony Lindgren wrote:
> > 
> > OK, so that's only for earlyprintk then?
> 
> yes,
> 
> > 
> > If so, it seems the right fix is to set the NO_IDLE and NO_RESET
> > flags based on ifdef CONFIG_DEBUG_OMAP4UART3 etc as that is selected
> > in the Kconfig now.
> 
> ok makes sense. It seems like the static data in hwmod can be populated
> based on these defines? something like
> 
> /* uart3 */
> static struct omap_hwmod omap44xx_uart3_hwmod = {
>         .name           = "uart3",
>         .class          = &omap44xx_uart_hwmod_class,
>         .clkdm_name     = "l4_per_clkdm",
> #ifdef CONFIG_DEBUG_OMAP4UART3
>         .flags          = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
>                                 HWMOD_SWSUP_SIDLE_ACT,
> #else
>         .flags          = HWMOD_SWSUP_SIDLE_ACT,
> #endif
>         .main_clk       = "func_48m_fclk",
>         .prcm = {
>                 .omap4 = {
>                         .clkctrl_offs = OMAP4_CM_L4PER_UART3_CLKCTRL_OFFSET,
>                         .context_offs = OMAP4_RM_L4PER_UART3_CONTEXT_OFFSET,
>                         .modulemode   = MODULEMODE_SWCTRL,
>                 },
>         },
> };
> 
> And same way for others? That way the cmdline parsing can be done away
> with even for the non-DT case.

Yes we can do it that way. How about add a common macro for it if
it's always the same? Then the .flags line would be just:

#define HWMOD_OMAP_UART_FLAGS(soc, port)
...

	.flags		= HWMOD_OMAP_UART_FLAGS(4, 3),

> > The current code in mach-omap2/serial.c is wrong, and is a hack
> > needed for the pdata based booting. What's broken is that
> > omap_serial_early_init() parses the cmdline for console, which
> > itself is pretty nasty, and it won't work the right way as
> > there's nothing stopping from having the earlycon in a different
> > UART from the serial console. So we just want to get rid of the
> > whole mach-omap2/serial.c once we're all DT.
> > 
> > So to summarize, we have two bugs:
> > 
> > 1. Omap hwmod code can reset UART while earlycon may be using
> >    it. The fix to this is to use NO_IDLE and NO_RESET flags in
> >    the hwmod code if CONFIG_DEBUG_OMAPxUARTy is specified.
> > 
> > 2. A bug in drivers/tty/serial/omap-serial.c where the
> >    missing context loss count can cause NULL context to be
> >    initialized during driver probe causing port to hang for
> >    earlycon. The fix for that is what Felipe has suggested or
> >    fix it in the driver by removing the context loss count usage
> >    and detect the need for context restore based on the UART
> >    state.
> > 
> > Or am I still missing something?
> 
> No, thats pretty much the 2 issues we have.

OK thanks good to hear it's limited to earlycon issues.

Regards,

Tony


From dirk.behme at de.bosch.com  Fri Jul 12 05:15:43 2013
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Fri, 12 Jul 2013 11:15:43 +0200
Subject: [PATCH 0/3] ARM: imx6: fix up buggy CCM_CSCMR1 register
In-Reply-To: <1373469722-32514-1-git-send-email-shawn.guo@linaro.org>
References: <1373469722-32514-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <51DFC93F.4020209@de.bosch.com>

On 10.07.2013 17:21, Shawn Guo wrote:
> There is a defect in bits 22 and 21 of i.MX6 CCM_CSCMR1 register.  These
> two bits are inverted between read and write.  That said, bit field
> CCM_CSCMR1[22-20] (aclk/emi_podf on imx6q/dl and lcdif_pix_podf on
> imx6sl) will be something as below between read and write.
>
>    read    write    divider
>     000     110       1
>     001     111       2
>     010     100       3
>     011     101       4
>     100     010       5
>     101     011       6
>     110     000       7
>     111     001       8
>
> To work around this hardware defect, every single read/modify/write
> sequence on the register will require a fix-up (invert bits 22 and 21)
> before writing the value into register.  As there are dividers and
> multiplexers defined in the register, we choose to inherit the basic
> clk-divider and clk-mux and override the functions which writes register
> with a fix-up hooked in.
>
> Shawn
>
> Liu Ying (3):
>    ARM: imx: add common clock support for fixup div
>    ARM: imx: add common clock support for fixup mux
>    ARM: imx6: change some clocks to fixup clocks
>
>   arch/arm/mach-imx/Makefile        |    3 +-
>   arch/arm/mach-imx/clk-fixup-div.c |  129 +++++++++++++++++++++++++++++++++++++
>   arch/arm/mach-imx/clk-fixup-mux.c |  107 ++++++++++++++++++++++++++++++
>   arch/arm/mach-imx/clk-imx6q.c     |   24 +++----
>   arch/arm/mach-imx/clk-imx6sl.c    |   20 +++---
>   arch/arm/mach-imx/clk.c           |   26 ++++++++
>   arch/arm/mach-imx/clk.h           |   10 +++
>   7 files changed, 296 insertions(+), 23 deletions(-)
>   create mode 100644 arch/arm/mach-imx/clk-fixup-div.c
>   create mode 100644 arch/arm/mach-imx/clk-fixup-mux.c

For the whole series:

Acked-by: Dirk Behme <dirk.behme at de.bosch.com>

Thanks

Dirk




From b32955 at freescale.com  Fri Jul 12 04:51:19 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Fri, 12 Jul 2013 16:51:19 +0800
Subject: [PATCH fix] ARM: dts: imx6qdl-sabreauto: add a DT node for uart3
In-Reply-To: <20130712084025.GH25501@S2101-09.ap.freescale.net>
References: <20130712084025.GH25501@S2101-09.ap.freescale.net>
Message-ID: <1373619079-14049-1-git-send-email-b32955@freescale.com>

Add a DT node for uart3, in the imx6q{dl}-sabreauto boards,
the uart3 is used by Bluetooth.

Since the uart3 has pin conflict with gpmi and weim nor, we keep it
disabled by default.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 1cbbc51..4f99ddd 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -67,6 +67,13 @@
 	};
 };
 
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart3_1>;
+	fsl,uart-has-rtscts;
+	status = "disabled"; /* used by the BT, pin conflict with gpmi and weim NOR */
+};
+
 &uart4 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart4_1>;
-- 
1.7.1




From rnayak at ti.com  Fri Jul 12 05:22:59 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 12 Jul 2013 14:52:59 +0530
Subject: [PATCH 1/2] Revert "ARM: OMAP2+: Fix serial init for device tree
 based booting"
In-Reply-To: <20130712091827.GH7656@atomide.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
 <1373539986-27272-2-git-send-email-rnayak@ti.com>
 <20130712072051.GA7656@atomide.com> <51DFB0E4.6040007@ti.com>
 <20130712080305.GD7656@atomide.com> <51DFC58C.7030105@ti.com>
 <20130712091827.GH7656@atomide.com>
Message-ID: <51DFCAF3.7040503@ti.com>

On Friday 12 July 2013 02:48 PM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak at ti.com> [130712 02:06]:
>> On Friday 12 July 2013 01:33 PM, Tony Lindgren wrote:
>>>
>>> OK, so that's only for earlyprintk then?
>>
>> yes,
>>
>>>
>>> If so, it seems the right fix is to set the NO_IDLE and NO_RESET
>>> flags based on ifdef CONFIG_DEBUG_OMAP4UART3 etc as that is selected
>>> in the Kconfig now.
>>
>> ok makes sense. It seems like the static data in hwmod can be populated
>> based on these defines? something like
>>
>> /* uart3 */
>> static struct omap_hwmod omap44xx_uart3_hwmod = {
>>         .name           = "uart3",
>>         .class          = &omap44xx_uart_hwmod_class,
>>         .clkdm_name     = "l4_per_clkdm",
>> #ifdef CONFIG_DEBUG_OMAP4UART3
>>         .flags          = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
>>                                 HWMOD_SWSUP_SIDLE_ACT,
>> #else
>>         .flags          = HWMOD_SWSUP_SIDLE_ACT,
>> #endif
>>         .main_clk       = "func_48m_fclk",
>>         .prcm = {
>>                 .omap4 = {
>>                         .clkctrl_offs = OMAP4_CM_L4PER_UART3_CLKCTRL_OFFSET,
>>                         .context_offs = OMAP4_RM_L4PER_UART3_CONTEXT_OFFSET,
>>                         .modulemode   = MODULEMODE_SWCTRL,
>>                 },
>>         },
>> };
>>
>> And same way for others? That way the cmdline parsing can be done away
>> with even for the non-DT case.
> 
> Yes we can do it that way. How about add a common macro for it if
> it's always the same? Then the .flags line would be just:
> 
> #define HWMOD_OMAP_UART_FLAGS(soc, port)
> ...
> 
> 	.flags		= HWMOD_OMAP_UART_FLAGS(4, 3),

Right, that seems much cleaner. I will send a patch out for it and get rid
of all the cmdline parsing in serial.c

regards
Rajendra
> 
>>> The current code in mach-omap2/serial.c is wrong, and is a hack
>>> needed for the pdata based booting. What's broken is that
>>> omap_serial_early_init() parses the cmdline for console, which
>>> itself is pretty nasty, and it won't work the right way as
>>> there's nothing stopping from having the earlycon in a different
>>> UART from the serial console. So we just want to get rid of the
>>> whole mach-omap2/serial.c once we're all DT.
>>>
>>> So to summarize, we have two bugs:
>>>
>>> 1. Omap hwmod code can reset UART while earlycon may be using
>>>    it. The fix to this is to use NO_IDLE and NO_RESET flags in
>>>    the hwmod code if CONFIG_DEBUG_OMAPxUARTy is specified.
>>>
>>> 2. A bug in drivers/tty/serial/omap-serial.c where the
>>>    missing context loss count can cause NULL context to be
>>>    initialized during driver probe causing port to hang for
>>>    earlycon. The fix for that is what Felipe has suggested or
>>>    fix it in the driver by removing the context loss count usage
>>>    and detect the need for context restore based on the UART
>>>    state.
>>>
>>> Or am I still missing something?
>>
>> No, thats pretty much the 2 issues we have.
> 
> OK thanks good to hear it's limited to earlycon issues.
> 
> Regards,
> 
> Tony
> 



From peter.ujfalusi at ti.com  Fri Jul 12 05:27:36 2013
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Fri, 12 Jul 2013 11:27:36 +0200
Subject: [PATCH] ARM: OMAP2+: twl-common: Remove code for twl6030 and
 twl6040 setup for legacy boot
In-Reply-To: <51DED333.9080609@ti.com>
References: <1373552638-13930-1-git-send-email-peter.ujfalusi@ti.com>
 <20130711145916.GA6138@kahuna> <51DED333.9080609@ti.com>
Message-ID: <51DFCC08.4050204@ti.com>

On 07/11/2013 05:45 PM, Peter Ujfalusi wrote:
>> We could get rid of all the #ifdef from the code that way. OMAP3 is the
>> only platform that still depends on this - Further, with this change,
> 
> Yep, I can do that. I'll send a separate patch to do this.

Now that I have looked at this: we might need to wait a bit and clean up other
files first: if we compile twl-common only if OMAP3 is selected, a build for
OMAP4/5 only will break due to missing symbol in pm.c (omap_pmic_late_init is
missing).
I could add another set of #ifdef there, but it defeats the point IMHO.

-- 
P?ter


From maxime.ripard at free-electrons.com  Fri Jul 12 05:37:20 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 12 Jul 2013 11:37:20 +0200
Subject: [PATCH 0/2] ARM: sunxi: Convert DTSI to new CPU bindings
In-Reply-To: <20130705101946.GA5584@e102568-lin.cambridge.arm.com>
References: <1372437844-16325-1-git-send-email-maxime.ripard@free-electrons.com>
 <20130628171532.GD30603@e102568-lin.cambridge.arm.com>
 <20130628200333.GA2756@lukather>
 <CAOesGMgsD+tK4+ywvLzsWd+mngrP7zGgSFn0naWjSsQLGaUn2Q@mail.gmail.com>
 <20130629193819.GD3353@n2100.arm.linux.org.uk>
 <20130630094846.GA27559@e102568-lin.cambridge.arm.com>
 <20130705101946.GA5584@e102568-lin.cambridge.arm.com>
Message-ID: <20130712093720.GE24370@lukather>

Hi Lorenzo,

On Fri, Jul 05, 2013 at 11:19:46AM +0100, Lorenzo Pieralisi wrote:
> On Sun, Jun 30, 2013 at 10:48:46AM +0100, Lorenzo Pieralisi wrote:
> > On Sat, Jun 29, 2013 at 08:38:19PM +0100, Russell King - ARM Linux wrote:
> > > On Fri, Jun 28, 2013 at 01:05:42PM -0700, Olof Johansson wrote:
> > > > On Fri, Jun 28, 2013 at 1:03 PM, Maxime Ripard
> > > > <maxime.ripard at free-electrons.com> wrote:
> > > > > On Fri, Jun 28, 2013 at 06:15:32PM +0100, Lorenzo Pieralisi wrote:
> > > > >> The patch above should already be queued in next/dt right ?
> > > > >
> > > > > Indeed.
> > > > >
> > > > > Then why the latest patch of your patchset got in 3.10, while the
> > > > > patches actually fixing the DT it would have impacted were delayed to
> > > > > 3.11?
> > > > >
> > > > > (And why was it merged so late in the development cycle?)
> > > > 
> > > > This. So now we have to scramble because some device trees will
> > > > produce warnings at boot.
> > > > 
> > > > Russell, the alternative is to revert Lorenzo's patch for 3.10 (and
> > > > re-introduce it for 3.11). Do you have a preference?
> > > 
> > > Sorry but I really don't understand what all the fuss in this thread
> > > is about.
> > > 
> > > This thread seems to be saying that two development patches were
> > > merged, which were 7762/1 and 7763/1, and that 7764/1 is a fix?
> > > Are you sure about that, because that's not how they're described,
> > > and not how they look either.
> > 
> > As Olof's warning downgrade is being merged (thanks for that and apologies for
> > failing to explain patches dependencies properly and stable related issues),
> > 7764/1 won't apply cleanly anymore. Can you please drop it from the patch
> > system, I will update it and test it first thing tomorrow and send a
> > final version to the patch system.
> 
> Patch 7779/1, replacing 7764/1 is in the patch system now, and is ready
> to get merged.
> 
> Unfortunately cpu/cpus bindings documentation updates, following:
> 
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036735.html
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-May/033779.html
> 
> were not pulled in the kernel. This is an issue since this means that
> we still have no reference in the kernel or wherever it has to be, to
> the final cpus/cpu bindings for ARM and ARM64 provided in the pull
> request link above (that has been reviewed to death and acknowledged).
> 
> It is a significant overhaul of cpu/cpus bindings standard for ARM/ARM64,
> covering all CPUs harking back to arm926 and beyond, and should be final.
> 
> dts updates following that standard have already been pulled into 3.11
> through arm-soc.
> 
> IMHO the bindings contained in pull request above must be merged in the
> kernel asap, I would like to ask you please what should I do to get them in
> please. If we want to move bindings documentation elsewhere let's do it,
> as long as there is a published standard I am happy and will stop annoying
> you with this stuff.

Just to be clear, I had no problems with the patches themselves, but
just the way it was merged.

That being said, I think every DTS patch you did should be merged by
now, only the second patch of this serie for the A10S hasn't.

Arnd, Olof, could you just apply the patch 2 for a 3.11-rc*? It's the
only rc patch for the sunxi platform for now, so I don't think a pull
request would be worth it, but I can send one anyway if you prefer.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130712/cb1d3c36/attachment.sig>

From richard.zhuhongxing at gmail.com  Fri Jul 12 05:41:15 2013
From: richard.zhuhongxing at gmail.com (Richard Zhu)
Date: Fri, 12 Jul 2013 17:41:15 +0800
Subject: [PATCH v6 0/3] ahci: enable ahci sata support on imx6q
Message-ID: <1373622078-18723-1-git-send-email-Hong-Xing.Zhu@freescale.com>

v6: add imx6q specific ahci sata support
  Thanks for Shawn's comments.
  - Speicify the ahb clock in the sata related dts changes.
  - Move the initialization of the sata PHY clock of the private
  data to the probe function.
  - Remove the empty device release function.
  - In order to be more readable, rename the imx_dev/imx_ahci_pdev
  to be ahci_dev/ahci_pdev, and do some other changes, such as typo
  error, more readable name of the variable.
  - Tested on imx6q sd board.
  - 

v5: http://www.spinics.net/lists/linux-ide/msg45712.html
  - Fix the wrong referrence usage of the private data.
  - Use the private data to contain the poninter of the PHY
  signals adjustment window(gpr)
  - Tested on imx6q sd board.
  - 

v4: http://www.spinics.net/lists/linux-ide/msg45699.html
  Thanks for the review comments provided by Sascha, and Alexander.
  - Use the private data and keep a pointer to the PHY clock.
  - Don't use the global platform device variable, because that
  it would make the driver broken for mutiple instances.
  - Don't do the "writel" with assignment.
  - Other minor changes, such as print the error code when printing
  error message, use a u32 type to store readl results, and so on.

v3: http://www.spinics.net/lists/linux-ide/msg45688.html
  - Keep arch/arm and ahci_platform driver clean.
  - Add the sata_imx standalone driver contained all the
  specific setup
  - Add the release function, support the loadable module
  driver.
  - Tested on imx6q sd board.

v2: http://www.spinics.net/lists/linux-ide/msg45666.html 
 - Setup standalone imx ahci sata driver, because of
 the misalignments of the bits definition of the HBA register.
 - Replace the node by the label in the board dts.
 - 

v1: http://www.spinics.net/lists/linux-ide/msg45581.html
 - add imx6q specific ahci sata support to arch/arm/mach-imx/mach-imx6q.c

These patches is based on imx/dt branch of
"http://git.linaro.org/git-ro/people/shawnguo/linux-2.6.git"

[v6 1/3] ARM: dtsi: enable ahci sata on imx6q platforms
[v6 2/3] ARM: imx6q: update the sata bits definitions of gpr13
[v6 3/3] sata: imx: add ahci sata support on imx platforms

arch/arm/boot/dts/imx6q-sabreauto.dts       |    4 +
arch/arm/boot/dts/imx6q-sabrelite.dts       |    4 +
arch/arm/boot/dts/imx6q-sabresd.dts         |    4 +
arch/arm/boot/dts/imx6q.dtsi                |    9 +
drivers/ata/Kconfig                         |    9 +
drivers/ata/Makefile                        |    1 +
drivers/ata/sata_imx.c                      |  241 +++++++++++++++++++++++++++
include/linux/mfd/syscon/imx6q-iomuxc-gpr.h |  121 +++++++++----
8 files changed, 356 insertions(+), 37 deletions(-)


From alexander.shishkin at linux.intel.com  Fri Jul 12 05:42:10 2013
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Fri, 12 Jul 2013 12:42:10 +0300
Subject: [PATCH v12 06/13] usb: chipidea: add otg_cap attribute for otg
 capable
In-Reply-To: <20130712082500.GA16202@nchen-desktop>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <1373524041-10482-7-git-send-email-peter.chen@freescale.com>
 <871u742o4u.fsf@ashishki-desk.ger.corp.intel.com>
 <20130712082500.GA16202@nchen-desktop>
Message-ID: <87r4f4dsi5.fsf@ashishki-desk.ger.corp.intel.com>

Peter Chen <peter.chen at freescale.com> writes:

> On Fri, Jul 12, 2013 at 11:12:01AM +0300, Alexander Shishkin wrote:
>> Peter Chen <peter.chen at freescale.com> writes:
>> 
>> > Since we need otgsc to know vbus's status at some chipidea
>> > controllers even it is peripheral-only mode. Besides, some
>> > SoCs (eg, AR9331 SoC) don't have otgsc register even
>> > the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS.
>> > We inroduce otg_cap attribute to indicate if the controller
>> > is otg capable, defaultly, we follow the rule that if DCCPARAMS_DC
>> > and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS are otg capable, but if there
>> > is exception, the platform can override it by device tree or platform data.
>> >
>> > Signed-off-by: Peter Chen <peter.chen at freescale.com>
>> > ---
>> 
>> [...]
>> 
>> > diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
>> > index 118bf66..0a906b4 100644
>> > --- a/include/linux/usb/chipidea.h
>> > +++ b/include/linux/usb/chipidea.h
>> > @@ -7,6 +7,12 @@
>> >  
>> >  #include <linux/usb/otg.h>
>> >  
>> > +enum usb_otg_cap {
>> > +	OTG_CAP_ATTR_IS_NOT_EXISTED = 0,
>> > +	OTG_CAP_ATTR_IS_TRUE,
>> > +	OTG_CAP_ATTR_IS_FALSE,
>> > +};
>> 
>> We don't really need all three, do we? We only need to know if the
>> controller *can't* do otg. The rest we can infer from dr_mode and
>> DCCPARAMS. So it can be another bit in flags rather than a separate
>> field in platdata.
>> 
>
> In order to cover below two cases, I have no other idea.
>
> 1. For mips Soc (ARxxx), if dr_mode = otg and it is 1 for both
> mode at DCCPARAMS,  It can switch role through proc or whatever,
> but NO otgsc register, it is NOT otg-capable.

For this case, platform should set

platdata->flags &= CI_HDRC_NO_OTG

, which will set ci->is_otg = false. No ci->is_otg => no touching
OTGSC.

> 2. For peripheral-only case at most chipidea controllers,
> the dr_mode = peripheral and it is 1 for both modes at DCCPARAMS,
> the otgsc can be visited, it is otg-capable.

Then platform *doesn't* set CI_HDRC_NO_OTG and ci->is_otg is set to
true, because DCCPARAMS.DC==1 and DCCPARAMS.HC==1, but we only have one
role initialized, because of dr_mode==peripheral, so no role switching
happens, but OTGSC accesses are fine.

Makes sense?

Regards,
--
Alex


From weisserm at arcor.de  Fri Jul 12 05:43:20 2013
From: weisserm at arcor.de (=?ISO-8859-1?Q?Matthias_Wei=DFer?=)
Date: Fri, 12 Jul 2013 11:43:20 +0200
Subject: [PATCH] ARM: dts: imx25: Make lcdc compatible to imx27/imx21
 fb
In-Reply-To: <20130712084516.GI25501@S2101-09.ap.freescale.net>
References: <1373614495-21717-1-git-send-email-weisserm@arcor.de>
 <20130712084516.GI25501@S2101-09.ap.freescale.net>
Message-ID: <51DFCFB8.5050303@arcor.de>

Am 12.07.2013 10:45, schrieb Shawn Guo:
> On Fri, Jul 12, 2013 at 09:34:54AM +0200, Matthias Weisser wrote:
>> ARM: dts: imx25: Make lcdc compatible to imx27/imx21 fb
>>
>> Signed-off-by: Matthias Weisser <weisserm at arcor.de>
>> ---
>>  arch/arm/boot/dts/imx25.dtsi |    3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
>> index d2550e0..83532b6 100644
>> --- a/arch/arm/boot/dts/imx25.dtsi
>> +++ b/arch/arm/boot/dts/imx25.dtsi
>> @@ -377,7 +377,8 @@
>>  				status = "disabled";
>>  			};
>>
>> -			lcdc at 53fbc000 {
>> +			lcdc: lcdc at 53fbc000 {
>> +				compatible = "fsl,imx27-fb", "fsl,imx21-fb";
>
> It makes more sense to have it be:
>
> 	compatible = "fsl,imx25-fb", "fsl,imx21-fb";

Should I send a v2?

Matthias



From tony at atomide.com  Fri Jul 12 05:46:31 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Jul 2013 02:46:31 -0700
Subject: [PATCH 1/2] Revert "ARM: OMAP2+: Fix serial init for device
 tree based booting"
In-Reply-To: <51DFCAF3.7040503@ti.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
 <1373539986-27272-2-git-send-email-rnayak@ti.com>
 <20130712072051.GA7656@atomide.com> <51DFB0E4.6040007@ti.com>
 <20130712080305.GD7656@atomide.com> <51DFC58C.7030105@ti.com>
 <20130712091827.GH7656@atomide.com> <51DFCAF3.7040503@ti.com>
Message-ID: <20130712094631.GI7656@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130712 02:29]:
>
> Right, that seems much cleaner. I will send a patch out for it and get rid
> of all the cmdline parsing in serial.c

Oh that's right, then it should not be needed for legacy pdata based
booting either :)

Regards,

Tony


From mingo at kernel.org  Fri Jul 12 06:13:19 2013
From: mingo at kernel.org (Ingo Molnar)
Date: Fri, 12 Jul 2013 12:13:19 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130712080145.GC24008@pd.tnic>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130712075602.GA4002@gmail.com> <20130712080145.GC24008@pd.tnic>
Message-ID: <20130712101319.GA13421@gmail.com>


* Borislav Petkov <bp at alien8.de> wrote:

> On Fri, Jul 12, 2013 at 09:56:02AM +0200, Ingo Molnar wrote:
> >
> > If a utility is not widely available yet and if the utility is not in 
> > the kernel proper, could you please at least make sure that randconfig 
> > does not stumble over non-buildable kernels?
> 
> Two months ago I've complained about this and other people have burned 
> themselves too in the meantime...

and now it is upstream already, via -mm:

   e76e1fdfa8f8 lib: add support for LZ4-compressed kernel


Thanks,

	Ingo


From tomasz.figa at gmail.com  Fri Jul 12 06:13:17 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Fri, 12 Jul 2013 12:13:17 +0200
Subject: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on
 Exynos5420
In-Reply-To: <20130711130139.GQ24508@sirena.org.uk>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
 <2214161.FSfscAvpna@thinkpad> <20130711130139.GQ24508@sirena.org.uk>
Message-ID: <2463181.bQfIDO6XJk@thinkpad>

On Thursday 11 of July 2013 14:01:39 Mark Brown wrote:
> On Thu, Jul 11, 2013 at 01:41:40PM +0200, Tomasz Figa wrote:
> > On Thursday 11 of July 2013 12:20:23 Mark Brown wrote:
> > > This is a bit of a larger project sadly, there was resistance to doing
> > > the DT bindings based on compatible strings using the IP version :(
> > 
> > I'm not sure if this case is related to this problem in any way. I just
> > suggested introducing a new include like samsung,exynos5420-i2s, a opposed
> > to using samsung,exynos5250-i2s and adding flags, since the I2S in
> > Exynos5420 is
> Well, it *should* be samsung,i2s-vN where N is the version number of the
> IP but documentation on the versioning has been patchy hence this whole
> thinng.

Oh, the binding for samsung-i2s uses IP versions. Isn't that slightly broken?

At least with Samsung bindings, I think we happened to agree on a single 
convention of naming compatible values after the first SoC in which such block 
first appeared.

I wonder what happened with this i2s binding that made it end up outside this 
convention.

> > the first one to have this TDM or whatever mode. (I'd still like to hear
> > what it is...)
> 
> What it *should* be is the option to send more than one audio stream
> down a link using time division multiplexing.

OK.

Best regards,
Tomasz



From mingo at kernel.org  Fri Jul 12 06:15:25 2013
From: mingo at kernel.org (Ingo Molnar)
Date: Fri, 12 Jul 2013 12:15:25 +0200
Subject: [PATCH, re-send] Always trap on BUG()
In-Reply-To: <201307051738.35930.arnd@arndb.de>
References: <201307051738.35930.arnd@arndb.de>
Message-ID: <20130712101525.GA13552@gmail.com>


* Arnd Bergmann <arnd at arndb.de> wrote:

> I've run some size analyis using the ARM 'multi_v7_defconfig'
> and gcc-4.8, using various definitions for BUG() and BUG_ON(), to
> see how big the size improvement actually gets
> 
> 1. Baseline: normal bug plus CONFIG_BUG_VERBOSE
>    text    data     bss     dec     hex filename
> 3743196  224396  206812 4174404  3fb244 vmlinux-bugverbose
> 
> 2. disabling CONFIG_BUG_VERBOSE, saving 0.6%
> 3716920  224380  206812 4148112  3f4b90 vmlinux-nobugverbose
> 
> 3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.0%
> 3701076  224384  206812 4132272  3f0db0 vmlinux-bug-panicfunc
> 
> 3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.5%
> 3678884  224400  206812 4110096  3eb710 vmlinux-bug-panic
> 
> 4. #define BUG() unreachable(), saving 2.1%
> 3652636  224384  206812 4083832  3e5078 vmlinux-bug-unreachable
> 
> 5. as 4, plus #define BUG_ON(c) if(c) unreachable(), saving 2.2%
> 3651108  224380  206812 4082300  3e4a7c vmlinux-bugon-unreachable
> 
> 6. #define BUG() do{}while(0), saving 2.1%
> 3654264  224380  206812 4085456  3e56d0 vmlinux-nobug
> 
> 7. as 6, plus #define BUG_ON if(0 && (c)) unreachable, saving 2.2%
> 3648392  223996  206748 4079136  3e3e20 vmlinux-no-bugon
> 
> 8. my patch below, saving 1.8%
> 3666532  224380  206812 4097724  3e86bc obj-tmp/vmlinux
> 
> The gain of doing unreachable and letting the code run off whereever
> is minimal compared to the current state of doing nothing, but it
> avoids the warnings.
> 
> Same test using x86_defconfig:
> 
> 1. CONFIG_BUG=y, CONFIG_BUGVERBOSE=n
> 10797859        1395648 1175552 13369059         cbfee3 vmlinux-x86-bug
> 
> 2. CONFIG_BUG=n, saves 1.0%
> 10658553        1395584 1175552 13229689         c9de79 vmlinux-x86-nobug
> 
> 3. with my patch, saves 0.8%
> 10684186        1395584 1175552 13255322         ca429a vmlinux-x86-archbug
> 
> Getting 1-2% savings in kernel size seems absolutely worth keeping the
> option, but 0.2-0.4% left for getting reproducible behavior also seems
> worthwhile. The result in the patch below.
> 
> This basically loses any of the BUG() reporting, but leaves the
> logic to trap and kill the task in place when CONFIG_BUG is disabled.

This also kills a boatload of compiler warnings when CONFIG_BUG is 
disabled.

Acked-by: Ingo Molnar <mingo at kernel.org>

Thanks,

	Ingo


From peter.chen at freescale.com  Fri Jul 12 06:16:57 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 12 Jul 2013 18:16:57 +0800
Subject: [PATCH v12 06/13] usb: chipidea: add otg_cap attribute for otg
 capable
In-Reply-To: <87r4f4dsi5.fsf@ashishki-desk.ger.corp.intel.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <1373524041-10482-7-git-send-email-peter.chen@freescale.com>
 <871u742o4u.fsf@ashishki-desk.ger.corp.intel.com>
 <20130712082500.GA16202@nchen-desktop>
 <87r4f4dsi5.fsf@ashishki-desk.ger.corp.intel.com>
Message-ID: <20130712101656.GD16202@nchen-desktop>

On Fri, Jul 12, 2013 at 12:42:10PM +0300, Alexander Shishkin wrote:
> Peter Chen <peter.chen at freescale.com> writes:
> 
> > On Fri, Jul 12, 2013 at 11:12:01AM +0300, Alexander Shishkin wrote:
> >> Peter Chen <peter.chen at freescale.com> writes:
> >> 
> >> > Since we need otgsc to know vbus's status at some chipidea
> >> > controllers even it is peripheral-only mode. Besides, some
> >> > SoCs (eg, AR9331 SoC) don't have otgsc register even
> >> > the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS.
> >> > We inroduce otg_cap attribute to indicate if the controller
> >> > is otg capable, defaultly, we follow the rule that if DCCPARAMS_DC
> >> > and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS are otg capable, but if there
> >> > is exception, the platform can override it by device tree or platform data.
> >> >
> >> > Signed-off-by: Peter Chen <peter.chen at freescale.com>
> >> > ---
> >> 
> >> [...]
> >> 
> >> > diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
> >> > index 118bf66..0a906b4 100644
> >> > --- a/include/linux/usb/chipidea.h
> >> > +++ b/include/linux/usb/chipidea.h
> >> > @@ -7,6 +7,12 @@
> >> >  
> >> >  #include <linux/usb/otg.h>
> >> >  
> >> > +enum usb_otg_cap {
> >> > +	OTG_CAP_ATTR_IS_NOT_EXISTED = 0,
> >> > +	OTG_CAP_ATTR_IS_TRUE,
> >> > +	OTG_CAP_ATTR_IS_FALSE,
> >> > +};
> >> 
> >> We don't really need all three, do we? We only need to know if the
> >> controller *can't* do otg. The rest we can infer from dr_mode and
> >> DCCPARAMS. So it can be another bit in flags rather than a separate
> >> field in platdata.
> >> 
> >
> > In order to cover below two cases, I have no other idea.
> >
> > 1. For mips Soc (ARxxx), if dr_mode = otg and it is 1 for both
> > mode at DCCPARAMS,  It can switch role through proc or whatever,
> > but NO otgsc register, it is NOT otg-capable.
> 
> For this case, platform should set
> 
> platdata->flags &= CI_HDRC_NO_OTG
> 
> , which will set ci->is_otg = false. No ci->is_otg => no touching
> OTGSC.
> 
> > 2. For peripheral-only case at most chipidea controllers,
> > the dr_mode = peripheral and it is 1 for both modes at DCCPARAMS,
> > the otgsc can be visited, it is otg-capable.
> 
> Then platform *doesn't* set CI_HDRC_NO_OTG and ci->is_otg is set to
> true, because DCCPARAMS.DC==1 and DCCPARAMS.HC==1, but we only have one
> role initialized, because of dr_mode==peripheral, so no role switching
> happens, but OTGSC accesses are fine.
> 
> Makes sense?
> 

Agree, I will add the define of CI_HDRC_NO_OTG to
struct ci_hdrc_platform_data, and add below comments

/* Only set it when DCCPARAMS.DC==1 and DCCPARAMS.HC==1,
 * but otg is not supported (no register otgsc).
 */

-- 

Best Regards,
Peter Chen



From bp at alien8.de  Fri Jul 12 06:23:26 2013
From: bp at alien8.de (Borislav Petkov)
Date: Fri, 12 Jul 2013 12:23:26 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130712101319.GA13421@gmail.com>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130712075602.GA4002@gmail.com> <20130712080145.GC24008@pd.tnic>
 <20130712101319.GA13421@gmail.com>
Message-ID: <20130712102326.GE24008@pd.tnic>

On Fri, Jul 12, 2013 at 12:13:19PM +0200, Ingo Molnar wrote:
> and now it is upstream already, via -mm:
> 
>    e76e1fdfa8f8 lib: add support for LZ4-compressed kernel

Sure. Let's see if it manages to get released b0rked like it is right
now.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--


From Dave.Martin at arm.com  Fri Jul 12 06:24:37 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Fri, 12 Jul 2013 11:24:37 +0100
Subject: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3() which
 calling instruction smc #1
In-Reply-To: <51DF0D7A.4090008@ti.com>
References: <531356997.66774.1373571839852.JavaMail.apache@mail81.abv.bg>
 <51DF0D7A.4090008@ti.com>
Message-ID: <20130712102430.GA3249@localhost.localdomain>

On Thu, Jul 11, 2013 at 03:54:34PM -0400, Santosh Shilimkar wrote:
> On Thursday 11 July 2013 03:43 PM, ?????? ???????? wrote:
> >  
> > 
> > 
> > 
> > 
> >  >-------- ?????????? ????? --------
> >  >??:  Dave Martin 
> >  >???????: Re: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3() which
> >  calling instruction smc #1
> >  >??: Pali Roh?r 
> >  >????????? ??: ?????, 2013, ??? 10 20:45:26 EEST
> >  >
> >  >
> >  >On Wed, Jul 10, 2013 at 02:59:04PM +0200, Pali Roh?r wrote:
> >  >> Other secure functions omap_smc1() and omap_smc2() calling instruction smc #0
> >  >> but Nokia RX-51 board needs to call smc #1 for PPA access.
> >  >> 
> >  >> Signed-off-by: Ivaylo Dimitrov 
> >  >> Signed-off-by: Pali Roh?r 
> >  >> ---
> >  >>  arch/arm/mach-omap2/omap-secure.h |    1 +
> >  >>  arch/arm/mach-omap2/omap-smc.S    |   22 +++++++++++++++++++++-
> >  >>  2 files changed, 22 insertions(+), 1 deletion(-)
> >  >> 
> >  >> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
> >  >> index 0e72917..c4586f4 100644
> >  >> --- a/arch/arm/mach-omap2/omap-secure.h
> >  >> +++ b/arch/arm/mach-omap2/omap-secure.h
> >  >> @@ -51,6 +51,7 @@
> >  >>  extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
> >  >>  				u32 arg1, u32 arg2, u32 arg3, u32 arg4);
> >  >>  extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
> >  >> +extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
> >  >>  extern phys_addr_t omap_secure_ram_mempool_base(void);
> >  >>  extern int omap_secure_ram_reserve_memblock(void);
> >  >>  
> >  >> diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
> >  >> index f6441c1..5c02b8d 100644
> >  >> --- a/arch/arm/mach-omap2/omap-smc.S
> >  >> +++ b/arch/arm/mach-omap2/omap-smc.S
> >  >> @@ -1,9 +1,11 @@
> >  >>  /*
> >  >> - * OMAP44xx secure APIs file.
> >  >> + * OMAP34xx and OMAP44xx secure APIs file.
> >  >>   *
> >  >>   * Copyright (C) 2010 Texas Instruments, Inc.
> >  >>   * Written by Santosh Shilimkar 
> >  >>   *
> >  >> + * Copyright (C) 2012 Ivaylo Dimitrov 
> >  >> + * Copyright (C) 2013 Pali Roh?r 
> >  >>   *
> >  >>   * This program is free software,you can redistribute it and/or modify
> >  >>   * it under the terms of the GNU General Public License version 2 as
> >  >> @@ -54,6 +56,24 @@ ENTRY(omap_smc2)
> >  >>  	ldmfd   sp!, {r4-r12, pc}
> >  >>  ENDPROC(omap_smc2)
> >  >>  
> >  >> +/**
> >  >> + * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
> >  >> + * Low level common routine for secure HAL and PPA APIs via smc #1
> >  >> + * r0 - @service_id: Secure Service ID
> >  >> + * r1 - @process_id: Process ID
> >  >> + * r2 - @flag: Flag to indicate the criticality of operation
> >  >> + * r3 - @pargs: Physical address of parameter list
> >  >> + */
> >  >> +ENTRY(omap_smc3)
> >  >> +	stmfd	sp!, {r4-r12, lr}
> >  >
> >  >You don't need to save/restore r12.  The ABI allows it to be clobbered
> >  >across function calls.
> >  >
> >  >> +	mov	r12, r0		@ Copy the secure service ID
> >  >> +	mov	r6, #0xff	@ Indicate new Task call
> >  >> +	dsb
> >  >> +	dmb
> >  >
> >  >dsb synchronises a superset of what dmb synchronises, so the dmb here is
> >  >not useful.
> >  >
> >  >In any case, any code calling this must flush the region addressed by
> >  >r3 beforehand anyway, which will include a dsb as part of its semantics
> >  >-- this is how you call it from rx51_secure_dispatcher().
> >  >
> >  >So I think the dsb may not be needed here (?)
> >  >
> >  >Cheers
> >  >---Dave
> >  >
> >  >
> > 
> > Could be, but I wonder why almost all the kernel code(I am aware of) that uses SMC and is written by TI, is storing r12 and is using both DSB and DMB. See arch/arm/mach-omap2/sleep34xx.S or arch/arm/mach-omap2/omap-smc.S for examples. I'd rather play it safe and leave it that way, unless someone confirms the other code using SMC has extra DSB/DMB instructions too. I wouldn't risk passing invalid/stale data to the Secure Monitor to just save 8 bytes and barriers in a performance non-critical code which will be called only a couple of times during the boot-up process. r12 save/restore is a legacy from omap_smc2 in omap-smc.S, so I guess it can go away without much of a trouble.
> > 
> Dave pointed out about the dsb and r12 to me in another thread. R12 can be easily removed
> but the DSB's were needed on OMAP for power sequencing. Without those, we have seen
> many issues. So you can leave the dsb's to be consistent with rest of the code.

Consistency is a perfectly good reason, especially in code like this
where a certain code sequence has been proven, but it's preferable to
include brief comments to explain nonetheless.

Difficulty in explaining precisely why something is needed should be a
warning flag that a comment is needed.

Cheers
---Dave



From b32955 at freescale.com  Fri Jul 12 06:02:09 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Fri, 12 Jul 2013 18:02:09 +0800
Subject: [PATCH] ARM: dts: imx6qdl/imx6sl: add the dma property for uart
Message-ID: <1373623329-18204-1-git-send-email-b32955@freescale.com>

Add the dma property for all the uart.

Note: Add the dma property does not mean we enable the dma for this
uart.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx6q-arm2.dts |    2 --
 arch/arm/boot/dts/imx6qdl.dtsi   |   10 ++++++++++
 arch/arm/boot/dts/imx6sl.dtsi    |   10 ++++++++++
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-arm2.dts b/arch/arm/boot/dts/imx6q-arm2.dts
index 9b17393..edf1bd9 100644
--- a/arch/arm/boot/dts/imx6q-arm2.dts
+++ b/arch/arm/boot/dts/imx6q-arm2.dts
@@ -102,8 +102,6 @@
 	pinctrl-0 = <&pinctrl_uart2_2>;
 	fsl,dte-mode;
 	fsl,uart-has-rtscts;
-	dma-names = "rx", "tx";
-	dmas = <&sdma 27 4 0>, <&sdma 28 4 0>;
 	status = "okay";
 };
 
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 72a28d6..34ffc2e 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -197,6 +197,8 @@
 					interrupts = <0 26 0x04>;
 					clocks = <&clks 160>, <&clks 161>;
 					clock-names = "ipg", "per";
+					dma-names = "rx", "tx";
+					dmas = <&sdma 25 4 0>, <&sdma 26 4 0>;
 					status = "disabled";
 				};
 
@@ -1479,6 +1481,8 @@
 				interrupts = <0 27 0x04>;
 				clocks = <&clks 160>, <&clks 161>;
 				clock-names = "ipg", "per";
+				dma-names = "rx", "tx";
+				dmas = <&sdma 27 4 0>, <&sdma 28 4 0>;
 				status = "disabled";
 			};
 
@@ -1488,6 +1492,8 @@
 				interrupts = <0 28 0x04>;
 				clocks = <&clks 160>, <&clks 161>;
 				clock-names = "ipg", "per";
+				dma-names = "rx", "tx";
+				dmas = <&sdma 29 4 0>, <&sdma 30 4 0>;
 				status = "disabled";
 			};
 
@@ -1497,6 +1503,8 @@
 				interrupts = <0 29 0x04>;
 				clocks = <&clks 160>, <&clks 161>;
 				clock-names = "ipg", "per";
+				dma-names = "rx", "tx";
+				dmas = <&sdma 31 4 0>, <&sdma 32 4 0>;
 				status = "disabled";
 			};
 
@@ -1506,6 +1514,8 @@
 				interrupts = <0 30 0x04>;
 				clocks = <&clks 160>, <&clks 161>;
 				clock-names = "ipg", "per";
+				dma-names = "rx", "tx";
+				dmas = <&sdma 33 4 0>, <&sdma 34 4 0>;
 				status = "disabled";
 			};
 		};
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 0a297af..230ee86 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -159,6 +159,8 @@
 					clocks = <&clks IMX6SL_CLK_UART>,
 						 <&clks IMX6SL_CLK_UART_SERIAL>;
 					clock-names = "ipg", "per";
+					dma-names = "rx", "tx";
+					dmas = <&sdma 33 4 0>, <&sdma 34 4 0>;
 					status = "disabled";
 				};
 
@@ -170,6 +172,8 @@
 					clocks = <&clks IMX6SL_CLK_UART>,
 						 <&clks IMX6SL_CLK_UART_SERIAL>;
 					clock-names = "ipg", "per";
+					dma-names = "rx", "tx";
+					dmas = <&sdma 25 4 0>, <&sdma 26 4 0>;
 					status = "disabled";
 				};
 
@@ -181,6 +185,8 @@
 					clocks = <&clks IMX6SL_CLK_UART>,
 						 <&clks IMX6SL_CLK_UART_SERIAL>;
 					clock-names = "ipg", "per";
+					dma-names = "rx", "tx";
+					dmas = <&sdma 27 4 0>, <&sdma 28 4 0>;
 					status = "disabled";
 				};
 
@@ -219,6 +225,8 @@
 					clocks = <&clks IMX6SL_CLK_UART>,
 						 <&clks IMX6SL_CLK_UART_SERIAL>;
 					clock-names = "ipg", "per";
+					dma-names = "rx", "tx";
+					dmas = <&sdma 29 4 0>, <&sdma 30 4 0>;
 					status = "disabled";
 				};
 
@@ -230,6 +238,8 @@
 					clocks = <&clks IMX6SL_CLK_UART>,
 						 <&clks IMX6SL_CLK_UART_SERIAL>;
 					clock-names = "ipg", "per";
+					dma-names = "rx", "tx";
+					dmas = <&sdma 31 4 0>, <&sdma 32 4 0>;
 					status = "disabled";
 				};
 			};
-- 
1.7.1




From mark.rutland at arm.com  Fri Jul 12 06:30:51 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 12 Jul 2013 11:30:51 +0100
Subject: [PATCH 02/02] ARM: shmobile: Setup r8a7790 arch timer based on
 MD pins
In-Reply-To: <20130711162229.933.53924.sendpatchset@w520>
References: <20130711162209.933.47610.sendpatchset@w520>
 <20130711162229.933.53924.sendpatchset@w520>
Message-ID: <20130712103051.GA4144@kartoffel>

On Thu, Jul 11, 2013 at 05:22:29PM +0100, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Update the r8a7790 arch timer setup code to configure the
> frequency dynamically at boot time. This means that the arch
> timer driver will be able to detect a timer frequency that
> has been calculated based on the MD pins instead of a fixed
> and potentially incorrect 13 MHz.
> 
> With this patch applied the Linux kernel will correctly
> support the r8a7790 Lager board that uses a 20 Mhz EXTAL.
> The arch timer will operate on 10 MHz and the Linux arch
> timer driver will be correctly configured to use 10 MHz.
> 
> Without this patch the 20 MHz EXTAL will be used to drive
> the arch timer at 10 MHz, but the Linux arch timer driver
> will believe it is counting at 13 Mhz.

This seems scary to me. The bootloader should be doing this before jumping to
Linux. As CNTCR is only writeable from the secure side, you won't be able to
use KVM unless the bootloader has done this.

Additionally, if you didn't do this in Linux, as far as I can see you wouldn't
need an init_time callback at all...

Thanks,
Mark.

> 
> Reported-by: Ulrich Hecht <ulrich.hecht at gmail.com>
> Signed-off-by: Magnus Damm <damm at opensource.se>
> Tested-by: Ulrich Hecht <ulrich.hecht at gmail.com>
> ---
> 
>  arch/arm/mach-shmobile/setup-r8a7790.c |   49 ++++++++++++++++++++++++++++----
>  1 file changed, 44 insertions(+), 5 deletions(-)
> 
> --- 0006/arch/arm/mach-shmobile/setup-r8a7790.c
> +++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-07-09 21:29:18.000000000 +0900
> @@ -215,14 +215,53 @@ u32 __init r8a7790_read_mode_pins(void)
>  	return mode;
>  }
>  
> +#define CNTCR 0
> +#define CNTFID0 0x20
> +
>  void __init r8a7790_timer_init(void)
>  {
> -	void __iomem *cntcr;
> +#ifdef CONFIG_ARM_ARCH_TIMER
> +	u32 mode = r8a7790_read_mode_pins();
> +	void __iomem *base;
> +	int extal_mhz = 0;
> +	u32 freq;
> +
> +	/* At Linux boot time the r8a7790 arch timer comes up
> +	 * with the counter disabled. Moreover, it may also report
> +	 * a potentially incorrect fixed 13 MHz frequency. To be
> +	 * correct these registers need to be updated to use the
> +	 * frequency EXTAL / 2 which can be determined by the MD pins.
> +	 */
> +
> +	switch (mode & (MD(14) | MD(13))) {
> +	case 0:
> +		extal_mhz = 15;
> +		break;
> +	case MD(13):
> +		extal_mhz = 20;
> +		break;
> +	case MD(14):
> +		extal_mhz = 26;
> +		break;
> +	case MD(13) | MD(14):
> +		extal_mhz = 30;
> +		break;
> +	}
> +
> +	/* The arch timer frequency equals EXTAL / 2 */
> +	freq = extal_mhz * (1000000 / 2);
> +
> +	/* Remap "armgcnt address map" space */
> +	base = ioremap(0xe6080000, PAGE_SIZE);
> +
> +	/* Update registers with correct frequency */
> +	iowrite32(freq, base + CNTFID0);
> +	asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
>  
> -	/* make sure arch timer is started by setting bit 0 of CNTCT */
> -	cntcr = ioremap(0xe6080000, PAGE_SIZE);
> -	iowrite32(1, cntcr);
> -	iounmap(cntcr);
> +	/* make sure arch timer is started by setting bit 0 of CNTCR */
> +	iowrite32(1, base + CNTCR);
> +	iounmap(base);
> +#endif /* CONFIG_ARM_ARCH_TIMER */
>  
>  	shmobile_timer_init();
>  }
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From laurent.pinchart at ideasonboard.com  Fri Jul 12 06:41:57 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 12 Jul 2013 12:41:57 +0200
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <51DEEE15.7040801@wwwdotorg.org>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1373553468-6564-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <51DEEE15.7040801@wwwdotorg.org>
Message-ID: <3211864.2dENa1E110@avalon>

Hi Stephen,

On Thursday 11 July 2013 11:40:37 Stephen Warren wrote:
> On 07/11/2013 08:37 AM, Laurent Pinchart wrote:
> > Define PWM_POLARITY_NORMAL and PWM_POLARITY_INVERTED macros in
> > include/dt-bindings/pwm/pwm.h to be used by device tree sources.
> > 
> >  Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt |  6 +++---
> >  Documentation/devicetree/bindings/pwm/pwm-samsung.txt   |  5 +++--
> >  Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt  |  5 +++--
> >  Documentation/devicetree/bindings/pwm/pwm.txt           |  8 +++++---
> >  Documentation/devicetree/bindings/pwm/vt8500-pwm.txt    |  5 +++--
> >  arch/arm/boot/dts/am335x-evm.dts                        |  3 ++-
> >  arch/arm/boot/dts/am335x-evmsk.dts                      |  3 ++-
> >  arch/arm/boot/dts/wm8850-w70v2.dts                      |  3 ++-
> >  include/dt-bindings/pwm/pwm.h                           | 15 ++++++++++++
> >  include/linux/pwm.h                                     |  4 ++--
> 
> I think this needs to be separate patches; at least the new pwm.h should
> be introduced separately to the board-specific *.dts edits, and perhaps
> further split up?

What about splitting it in three patches that

- add the include/dt-bindings/pwm/pwm.h header, and update include/linux/pwm.h 
and Documentation/devicetree/bindings/pwm/pwm.txt

- update the rest of the documentation

- update the .dts files

> That way, the one patch that introduces <dt-bindings/pwm.h> would be
> available to be merged into any other tree that wanted to take patches
> to use the new defines.
> 
> > diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> > 
> >  enum pwm_polarity {
> > 
> > -	PWM_POLARITY_NORMAL,
> > -	PWM_POLARITY_INVERSED,
> > +	PWM_POLARITY_NORMAL = 0,
> > +	PWM_POLARITY_INVERSED = 1,
> > 
> >  };
> 
> Rather than manually editing that to ensure the enum matches the DT bindings
> header, the whole point of making a separate <dt-bindings/...> directory was
> that drivers could include the binding header files directly to avoid having
> to duplicate the constant definitions. Can't <linux/pwm.h> include <dt-
> bindings/pwm.h> and remove that enum?

We could do that, but we would then need to modify all drivers to replace 
enum_pwm_polarity with unsigned int. Thierry, what's your opinion on this ?

Replying to a comment from another e-mail, I know that the above change to 
include/linux/pwm.h is not strictly needed as the enum values are already 
correct. The point of specifying the enum values explicitly was to hint that 
the values matter and should not be changed. A comment in the source would 
probably be more appropriate though.

-- 
Regards,

Laurent Pinchart



From laurent.pinchart at ideasonboard.com  Fri Jul 12 06:50:52 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 12 Jul 2013 12:50:52 +0200
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <20130711153559.GB2198@dhcp-172-17-186-34.nvidia.com>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1373553468-6564-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <20130711153559.GB2198@dhcp-172-17-186-34.nvidia.com>
Message-ID: <1912926.Zzl227Nulf@avalon>

Hi Thierry,

On Thursday 11 July 2013 08:36:00 Thierry Reding wrote:
> On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart wrote:
> [...]
> 
> > diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> > b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index
> > de0eaed..be09be4 100644
> > --- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> > +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> > 
> > @@ -4,9 +4,9 @@ Required properties:
> >  - compatible: should be "atmel,tcb-pwm"
> >  - #pwm-cells: Should be 3.  The first cell specifies the per-chip index
> >    of the PWM to use, the second cell is the period in nanoseconds and
> > -  bit 0 in the third cell is used to encode the polarity of PWM output.
> > -  Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity
> > &
> > -  set to 0 for normal polarity.
> > +  the third cell is used to encode the polarity of PWM output. Set the
> > +  PWM_POLARITY_NORMAL flag for normal polarity or the
> > PWM_POLARITY_INVERSED
> > +  flag for inverted polarity. PWM flags are defined in <dt-
bindings/pwm/pwm.h>.
> >  - tc-block: The Timer Counter block to use as a PWM chip.
> 
> >  Example:
>
> I'd prefer for the original text to stay in place and the reference to the
> dt-bindings/pwm/pwm.h file to go below that block. The reason is that
> perhaps somebody will look at an older version of a given DT (with the
> numerical value) and not have access to the include and therefore not know
> which flag was being set by just looking at the documentation. I'm also not
> sure about what the plans are with respect to shipping device trees in a
> separate repository and if they are, whether that repository would ship the
> includes as well.
> 
> Another issue might be that people without access to recent versions of
> DTC won't be able to use the new #include feature, so keeping the
> documentation backwards compatible seems like a good idea.
> 
> Perhaps the include file should even only be mentioned in the general
> PWM binding documentation.
> 
> Perhaps Grant and Rob (Cc'ed) can comment on how they want to handle
> this.

I'll comment on this in a reply to Stephen.

> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
> > b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt index
> > ac67c68..bece18b 100644
> > --- a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
> > +++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
> > 
> > @@ -24,8 +24,9 @@ Required properties:
> >       - phandle to PWM controller node
> >       - index of PWM channel (from 0 to 4)
> >       - PWM signal period in nanoseconds
> > 
> > -     - bitmask of optional PWM flags:
> > -        0x1 - invert PWM signal
> > +     - bitmask of optional PWM flags as defined in
> > <dt-bindings/pwm/pwm.h>: +        PWM_POLARITY_NORMAL - normal polarity
> > +	PWM_POLARITY_INVERSED - inverted polarity
> 
> This part mixes spaces and tabs for indentation. Please stick to spaces.

OK.

> > diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt
> > b/Documentation/devicetree/bindings/pwm/pwm.txt index 06e6724..38c357a
> > 100644
> > --- a/Documentation/devicetree/bindings/pwm/pwm.txt
> > +++ b/Documentation/devicetree/bindings/pwm/pwm.txt
> > @@ -43,13 +43,15 @@ because the name "backlight" would be used as fallback
> > anyway.> 
> >  pwm-specifier typically encodes the chip-relative PWM number and the PWM
> >  period in nanoseconds.
> > 
> > -Optionally, the pwm-specifier can encode a number of flags in a third
> > cell:
> > -- bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity)
> > +Optionally, the pwm-specifier can encode a number of flags (defined in
> > +<dt-bindings/gpio/gpio.h>) in a third cell:
> > +- PWM_POLARITY_NORMAL: use the normal PWM signal polarity
> > +- PWM_POLARITY_INVERSED: invert the PWM signal polarity
> 
> You'd have a hard time finding those in the GPIO header. =)

Oops :-)

Will fix.

> > diff --git a/include/dt-bindings/pwm/pwm.h b/include/dt-bindings/pwm/pwm.h
> > new file mode 100644
> > index 0000000..f82be30
> > --- /dev/null
> > +++ b/include/dt-bindings/pwm/pwm.h
> > @@ -0,0 +1,15 @@
> > +/*
> > + * This header provides constants for most PWM bindings.
> > + *
> > + * Most PWM bindings can include a flags cell as part of the PWM 
> > specifier.
> > + * In most cases, the format of the flags cell uses the standard values
> > + * defined in this header.
> > + */
> > +
> > +#ifndef _DT_BINDINGS_PWM_PWM_H
> > +#define _DT_BINDINGS_PWM_PWM_H
> > +
> > +#define PWM_POLARITY_NORMAL			(0 << 0)
> > +#define PWM_POLARITY_INVERSED			(1 << 0)
> > +
> > +#endif
> 
> I think this should go into a patch separate from the DT changes above
> because they'll likely go in via different trees. Or maybe they won't,
> but it'd still be good to introduce the header first and only then
> change the DTS files.

I'll fix that as well. Please see my reply to Stephen for details.

> > diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> 
> [...]
> 
> >  enum pwm_polarity {
> > 
> > -	PWM_POLARITY_NORMAL,
> > -	PWM_POLARITY_INVERSED,
> > +	PWM_POLARITY_NORMAL = 0,
> > +	PWM_POLARITY_INVERSED = 1,
> 
> That's what the enum values will be by default, so there's no need to be
> explicit here.

Please see my reply to Stephen as well. I'll at least replace this change with 
a comment, or remove enum pwm_polarity completely if that's the preferred 
solution.

-- 
Regards,

Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130712/d86c4c0d/attachment.sig>

From sr at denx.de  Fri Jul 12 06:52:04 2013
From: sr at denx.de (Stefan Roese)
Date: Fri, 12 Jul 2013 12:52:04 +0200
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51DFC92F.1050701@ti.com>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de> <51DE87D3.5030600@ti.com>
 <51DEA7F1.1050902@denx.de> <51DEC2CE.70400@ti.com> <51DED076.3040000@denx.de>
 <51DEF0DE.4050607@denx.de> <51DFC92F.1050701@ti.com>
Message-ID: <51DFDFD4.3040900@denx.de>

Roger,

On 07/12/2013 11:15 AM, Roger Quadros wrote:
>>> Good idea. I'm currently using a "dirty" local version. I'll try to
>>> switch to an officially available version tomorrow. And send you the
>>> version/git id.
>>
>> I updated my U-Boot to the following version: Based on mainline git
>> commit ID 225fd8c. Only this patch added:
>>
>> http://patchwork.ozlabs.org/patch/256702/
>>
>> This is needed for USB to work in U-Boot. Otherwise my external USB
>> SMSC95xx will not be detected in U-Boot.
> 
> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
> as I don't have an external USB-ethernet adapter.

Too bad. This difference in boards makes the tests a bit less
meaningful. Is there really no USB-ethernet adapter somewhere in your
department (perhaps a non-SMSC95xx might serve as well?)? I might
send/order you one if necessary. ;)

> The above commit doesn't work well for beagle-xm,

Why is this? What does happen? Does U-Boot not boot up to the prompt?
Please send me a log.

> so my u-boot is on tag v2013.04
> and you don't need that additional patch.
> 
> Can you please retest on it? Thanks.

Done, please see below.

> You will need to set "usbethaddr" before starting USB else SMSC will not work.
> e.g.
> 	setenv usbethaddr A6:66:4D:B0:69:04

I don't have a beagle-xm, only my beable. And my U-Boot network setup is
already working, thanks.

> Also could you please increase the Linux console message verbosity to debug (8), so that
> all kernel messages are visible in the log? If it spits out something more than what you
> sent last time then do send it to me.

I added "ignore_loglevel" to the cmdline. But I cannot see anything
interesting that has not been there before with "debug" as well.

> Let's first sort out the beagle-xm problem, then we can see about old beagle.

Okay, I tested again with U-Boot v2013.01 plus my SMSC patch. Same
problem. NFS booting/mounting hangs at some time.

Thanks,
Stefan


From laurent.pinchart at ideasonboard.com  Fri Jul 12 07:01:01 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 12 Jul 2013 13:01:01 +0200
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <51DF1054.9000207@wwwdotorg.org>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <20130711193245.GB17212@dhcp-172-17-186-34.nvidia.com>
 <51DF1054.9000207@wwwdotorg.org>
Message-ID: <2172485.AZTjvkLGcM@avalon>

Hi,

On Thursday 11 July 2013 14:06:44 Stephen Warren wrote:
> On 07/11/2013 01:32 PM, Thierry Reding wrote:
> > On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote:
> >> On 07/11/2013 09:36 AM, Thierry Reding wrote:
> >>> On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart
> >>> wrote: [...]
> >>> 
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> >>>> b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> >>>> index de0eaed..be09be4 100644 ---
> >>>> a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> >>>> +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> >>>> @@ -4,9 +4,9 @@ Required properties: - compatible: should be
> >>>> "atmel,tcb-pwm" - #pwm-cells: Should be 3.  The first cell
> >>>> specifies the per-chip index of the PWM to use, the second
> >>>> cell is the period in nanoseconds and -  bit 0 in the third
> >>>> cell is used to encode the polarity of PWM output. -  Set bit
> >>>> 0 of the third cell in PWM specifier to 1 for inverse
> >>>> polarity & -  set to 0 for normal polarity. +  the third cell
> >>>> is used to encode the polarity of PWM output. Set the +
> >>>> PWM_POLARITY_NORMAL flag for normal polarity or the
> >>>> PWM_POLARITY_INVERSED +  flag for inverted polarity. PWM
> >>>> flags are defined in <dt-bindings/pwm/pwm.h>. - tc-block: The
> >>>> Timer Counter block to use as a PWM chip.
> >>> 
> >>>> Example:
> >>> I'd prefer for the original text to stay in place and the reference to
> >>> the dt-bindings/pwm/pwm.h file to go below that block.
> >> 
> >> I disagree here. The whole point of creating header files for the
> >> constants in binding definitions was so that you wouldn't have to
> >> duplicate all the values into the binding definitions. Rather, you'd
> >> simply say "see <dt-bindings/xxx.h>".
> > 
> > But that's not something that this patch solves.
> 
> Well, if the comments I made on the patch re: that <linux/pwm.h> should
> simply #include <dt-bindings/pwm/pwm.h> instead of duplicating the
> constants, then yet this patch will solve that. There will be a single place
> where the constants are defined.

As explained in another reply, this would require replacing the enum with an 
unsigned int. I can write a patch if we agree on this.

> > And it could be solved even in the absence of the header file defining the
> > symbolic constants. If all the standard flags that dt-bindings/pwm/pwm.txt
> > now specifies were to be listed in pwm.txt (they actually are) then
> > referring to that document as the canonical source works equally well.
> 
> If that's all the happens, then there will still be duplication
> between pwm.txt and <linux/pwm.h>.

I've explicitly mentioned the flags in individual DT bindings to ease adding 
new flags in the future. At the moment the defined flags are either all 
supported or not used at all by drivers. If we later add a new flag supported 
by a subset of drivers only the driver bindings should list supported flags 
for each driver.

I'm fine with removing the explicit mentions of individual flags right now and 
adding it back when needed if you think that's better.

> > If we can take both of the above for granted, then sure, let's refer to
> > the header from within the generic pwm.txt file and add a reference to
> > that in bindings for drivers that use the standard flags.
> > 
> >>> Another issue might be that people without access to recent versions of
> >>> DTC won't be able to use the new #include feature, so keeping the
> >>> documentation backwards compatible seems like a good idea.
> >> 
> >> The dtc source tree is duplicated into the kernel source tree, so that
> >> isn't an issue for now.
> >> 
> >> Besides, the dtc version is an entirely unrelated issue to how the
> >> documentation is written.
> > 
> > Well, not really. If the documentation specifies the binding in a way that
> > the DTC can't handle that's still a problem. People will end up with a DTS
> > that their DTC can't compile. I guess that can be resolved by adding a
> > note to the upstream device tree repository about the minimum required
> > version of DTC.
> 
> Yes, the separate repository would obviously require a version of dtc that's
> able to compile the files there; i.e. a version equivalent to what's already
> in the kernel tree (upstream 1.4.0 specifically).
> 
> Again, right now, all of the binding docs, the *.dts files, and the dtc
> required to use them are part of the kernel; a single package, so there's no
> scope for issues re: using dtc features that aren't supported. If those
> components get separated later, obviously there will be a requirement to
> install a specific version of dtc to use with the separated *.dts and
> binding files.

-- 
Regards,

Laurent Pinchart



From festevam at gmail.com  Fri Jul 12 07:03:48 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 12 Jul 2013 08:03:48 -0300
Subject: [PATCH v2] ARM: imx: Kconfig: Select ARM1136 related errata
In-Reply-To: <20130712074946.GD25501@S2101-09.ap.freescale.net>
References: <1373552782-14196-1-git-send-email-fabio.estevam@freescale.com>
 <20130712074946.GD25501@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5DhyXp5arkLTHO+MZaA3hrMX4q6Y3OH3LeVfUiizytoAQ@mail.gmail.com>

On Fri, Jul 12, 2013 at 4:49 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> On Thu, Jul 11, 2013 at 11:26:22AM -0300, Fabio Estevam wrote:
>> CONFIG_ARM_ERRATA_411920 and CONFIG_ARM_ERRATA_364296 should be selected for
>> ARM1136 SoCs.
>>
> Per help text of the erratums, 364296 affects ARM1136 r0p2, and 411920
> affects ARM1136 before r1p4.  Do you know the revisions used on imx31
> and imx35?  Or do you see that enabling the workaround help fix some
> real issues?

I haven't checked the exact revisions of mx31/mx35.

The reason I selected these two errata was due to comparison with the
FSL BSP defconfig for mx31:
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/configs/imx31_3stack_defconfig?h=imx_2.6.31


From javi.merino at arm.com  Fri Jul 12 07:13:22 2013
From: javi.merino at arm.com (Javi Merino)
Date: Fri, 12 Jul 2013 12:13:22 +0100
Subject: [PATCH] irqchip: gic: Don't complain in gic_get_cpumask() if UP
 system
In-Reply-To: <1373067573-29946-1-git-send-email-sboyd@codeaurora.org>
References: <1373067573-29946-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130712111322.GC3213@e102654-lin.cambridge.arm.com>

On Sat, Jul 06, 2013 at 12:39:33AM +0100, Stephen Boyd wrote:
> In a uniprocessor implementation the interrupt processor targets
> registers are read-as-zero/write-ignored (RAZ/WI). Unfortunately
> gic_get_cpumask() will print a critical message saying
> 
>  GIC CPU mask not found - kernel will fail to boot.
> 
> if these registers all read as zero, but there won't actually be
> a problem on uniprocessor systems and the kernel will boot just
> fine. Skip this check if we're running a UP kernel or if we
> detect that the hardware only supports a single processor.
> 
> Cc: Nicolas Pitre <nico at linaro.org>
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
> 
> Maybe we should just drop the check entirely? It looks like it may
> just be debug code that won't ever trigger in practice, even on the
> 11MPCore that caused this code to be introduced.

I agree, we should drop the check.  It's annoying in uniprocessors and
unlikely to be found in the real world unless your gic entry in the dt
is wrong.



From akpm at linux-foundation.org  Fri Jul 12 07:18:10 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Fri, 12 Jul 2013 04:18:10 -0700
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130712102326.GE24008@pd.tnic>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130712075602.GA4002@gmail.com> <20130712080145.GC24008@pd.tnic>
 <20130712101319.GA13421@gmail.com> <20130712102326.GE24008@pd.tnic>
Message-ID: <20130712041810.53c86e5f.akpm@linux-foundation.org>

On Fri, 12 Jul 2013 12:23:26 +0200 Borislav Petkov <bp at alien8.de> wrote:

> On Fri, Jul 12, 2013 at 12:13:19PM +0200, Ingo Molnar wrote:
> > and now it is upstream already, via -mm:
> > 
> >    e76e1fdfa8f8 lib: add support for LZ4-compressed kernel
> 
> Sure. Let's see if it manages to get released b0rked like it is right
> now.

Well y'know, if whining fixed bugs then there would be no problem here
at all.

This problem came up briefly and I thought it had been adequately
addressed.  Now a month or two later we find out who are the people who
can't be bothered testing -next, but think it terribly important that
others do so.


From broonie at kernel.org  Fri Jul 12 07:18:38 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 12 Jul 2013 12:18:38 +0100
Subject: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on
 Exynos5420
In-Reply-To: <2463181.bQfIDO6XJk@thinkpad>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
 <2214161.FSfscAvpna@thinkpad>
 <20130711130139.GQ24508@sirena.org.uk>
 <2463181.bQfIDO6XJk@thinkpad>
Message-ID: <20130712111838.GZ24508@sirena.org.uk>

On Fri, Jul 12, 2013 at 12:13:17PM +0200, Tomasz Figa wrote:
> On Thursday 11 of July 2013 14:01:39 Mark Brown wrote:

> > Well, it *should* be samsung,i2s-vN where N is the version number of the
> > IP but documentation on the versioning has been patchy hence this whole
> > thinng.

> Oh, the binding for samsung-i2s uses IP versions. Isn't that slightly broken?

> At least with Samsung bindings, I think we happened to agree on a single 
> convention of naming compatible values after the first SoC in which such block 
> first appeared.

> I wonder what happened with this i2s binding that made it end up outside this 
> convention.

I think it predates that convention, plus it's been quite common to put
two different I2S blocks in the same SoC (for totally sensible reasons)
so it's not always been clear that the SoC name is sufficiently unique.
-------------- 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/20130712/1898d978/attachment.sig>

From nsekhar at ti.com  Fri Jul 12 07:19:17 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 12 Jul 2013 16:49:17 +0530
Subject: [PATCH] ARM: davinci: make file local variables static
Message-ID: <1373627957-12979-1-git-send-email-nsekhar@ti.com>

Make file local variables static in mach-davinci.
This fixes sparse warnings of the form:

arch/arm/mach-davinci/dm355.c:863:27: warning: symbol 'dm355_venc_pdata' was not declared. Should it be static?

Cc: Prabhakar Lad <prabhakar.csengg at gmail.com>
Signed-off-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/board-dm365-evm.c |    2 +-
 arch/arm/mach-davinci/dm355.c           |    2 +-
 arch/arm/mach-davinci/dm365.c           |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index fd38c8d..7e4e32f 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -505,7 +505,7 @@ static struct vpbe_output dm365evm_vpbe_outputs[] = {
 /*
  * Amplifiers on the board
  */
-struct ths7303_platform_data ths7303_pdata = {
+static struct ths7303_platform_data ths7303_pdata = {
 	.ch_1 = 3,
 	.ch_2 = 3,
 	.ch_3 = 3,
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 42ef53f..86100d1 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -860,7 +860,7 @@ static struct platform_device dm355_vpbe_display = {
 	},
 };
 
-struct venc_platform_data dm355_venc_pdata = {
+static struct venc_platform_data dm355_venc_pdata = {
 	.setup_pinmux	= dm355_vpbe_setup_pinmux,
 	.setup_clock	= dm355_venc_setup_clock,
 };
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index fa7af5e..dad2802 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1349,7 +1349,7 @@ static struct platform_device dm365_vpbe_display = {
 	},
 };
 
-struct venc_platform_data dm365_venc_pdata = {
+static struct venc_platform_data dm365_venc_pdata = {
 	.setup_pinmux	= dm365_vpbe_setup_pinmux,
 	.setup_clock	= dm365_venc_setup_clock,
 };
-- 
1.7.10.1



From pavel at ucw.cz  Fri Jul 12 07:36:56 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Fri, 12 Jul 2013 13:36:56 +0200
Subject: [PATCH] Route kbd LEDs through the generic LEDs layer
In-Reply-To: <20130707101028.GD5651@type.youpi.perso.aquilenet.fr>
References: <201011112205.oABM5KVJ005298@imap1.linux-foundation.org>
 <201011111440.07882.dmitry.torokhov@gmail.com>
 <20110102090935.GV32469@atrey.karlin.mff.cuni.cz>
 <20110102103210.GA25662@core.coreip.homeip.net>
 <20110102225741.GX5480@const.famille.thibault.fr>
 <20110112182702.GA9168@core.coreip.homeip.net>
 <20111114040613.GA4992@type.famille.thibault.fr>
 <20121221003449.GA6999@type.youpi.perso.aquilenet.fr>
 <20130707101028.GD5651@type.youpi.perso.aquilenet.fr>
Message-ID: <20130712113655.GA4227@amd.pavel.ucw.cz>

Hi!

> This permits to reassign keyboard LEDs to something else than keyboard "leds"
> state, by adding keyboard led and modifier triggers connected to a series
> of VT input LEDs, themselves connected to VT input triggers, which
> per-input device LEDs use by default.  Userland can thus easily change the LED
> behavior of (a priori) all input devices, or of particular input devices.

Nice! Leds now have proper /sys interface.

But... I boot up, switch from X to console, press capslock, and no
reaction anywhere.

Note that this is notebook with usb keyboard plugged in (and two
monitors), but I believe this worked before...

Thanks,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From broonie at kernel.org  Fri Jul 12 07:45:51 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 12 Jul 2013 12:45:51 +0100
Subject: [PATCH v5 1/7] sound: codec: wm8731: add rates constraints
In-Reply-To: <1373559359-31607-2-git-send-email-richard.genoud@gmail.com>
References: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
 <1373559359-31607-2-git-send-email-richard.genoud@gmail.com>
Message-ID: <20130712114551.GD24508@sirena.org.uk>

On Thu, Jul 11, 2013 at 06:15:53PM +0200, Richard Genoud wrote:

Please always try to use commit logs that look like normal commit logs
for the subsystem.

>  	switch (freq) {
> -	case 11289600:
>  	case 12000000:
> +		wm8731->constraints = &wm8731_constraints_12000000;
> +		break;
>  	case 12288000:
> -	case 16934400:
>  	case 18432000:
> -		wm8731->sysclk = freq;
> +		wm8731->constraints = &wm8731_constraints_12288000_18432000;
> +		break;
> +	case 16934400:
> +	case 11289600:
> +		wm8731->constraints = &wm8731_constraints_11289600_16934400;
>  		break;
>  	default:
>  		return -EINVAL;
>  	}

This isn't going to work with systems which have a variable clock as the
input to the CODEC.  If it's imposing constraints the driver needs to
allow setting the clock to zero as a way of removing constraints (and
any existing drivers should be updated to do this if needed).
-------------- 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/20130712/f6b906da/attachment.sig>

From thomas.petazzoni at free-electrons.com  Fri Jul 12 07:47:26 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 12 Jul 2013 13:47:26 +0200
Subject: v3.10 - big endian core support
In-Reply-To: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
Message-ID: <20130712134726.0a909165@skate>

Dear Vijay Kilari,

On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:

> > Ben Dooks has a separate branch on top of this base branch for
> > big-endian support, that adds atags compat code to convert the ATAGs
> > data from LE to BE. See the baserock/311/be/atags branch in
> > git://git.baserock.org/delta/linux. Or
> > http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
> 
>  ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
> It hangs at very early stage of boot

Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
of the TODO-list. I think Ben said he would probably not have much time
to work on this. I might be able to spare some time on this, so just
let me know if I should start working on this. If I remember correctly,
it's mainly the fixup_pv_table code that needed some Thumb2/BE love.

Will, is getting Thumb2 working a requirement to get the BE support
merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From broonie at kernel.org  Fri Jul 12 07:49:26 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 12 Jul 2013 12:49:26 +0100
Subject: [PATCH v5 2/7] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <1373559359-31607-3-git-send-email-richard.genoud@gmail.com>
References: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
 <1373559359-31607-3-git-send-email-richard.genoud@gmail.com>
Message-ID: <20130712114926.GE24508@sirena.org.uk>

On Thu, Jul 11, 2013 at 06:15:54PM +0200, Richard Genoud wrote:
> From: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> Description of the Asoc machine driver for an at91sam9x5 based board

ASoC.

> +sam9x5 pins:
> + * LOUT
> + * ROUT
> + * LHPOUT
> + * RHPOUT
> + * LLINEIN
> + * RLINEIN
> + * MICIN

These aren't pins on the CPU, they're pins on the CODEC, and you should
be adding this to the binding document for the CODEC and referring to
that rather than having them in each individual binding document.  This
also helps if any new variants are added (not that this is likely for
the WM8731).

> +static struct sam9x5_drvdata sam9x5_priv;

Why is this a global static?

> +	ret = snd_soc_register_card(&snd_soc_sam9x5);
> +	if (ret) {
> +		dev_err(&pdev->dev,
> +			"ASoC: Platform device allocation failed\n");
> +		goto out_put_audio;
> +	}

> +	platform_set_drvdata(pdev, &snd_soc_sam9x5);

It should be being dynamically allocated and retrieved as driver data
when needed.
-------------- 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/20130712/2edc0bad/attachment.sig>

From vijay.kilari at gmail.com  Fri Jul 12 07:56:59 2013
From: vijay.kilari at gmail.com (Vijay Kilari)
Date: Fri, 12 Jul 2013 17:26:59 +0530
Subject: v3.10 - big endian core support
In-Reply-To: <20130712134726.0a909165@skate>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate>
Message-ID: <CALicx6sr=OXYAdSS-RXPCjSp4f_yLQyw6jJsQ2KyhgQ9fRtXag@mail.gmail.com>

On Fri, Jul 12, 2013 at 5:17 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Dear Vijay Kilari,
>
> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>
>> > Ben Dooks has a separate branch on top of this base branch for
>> > big-endian support, that adds atags compat code to convert the ATAGs
>> > data from LE to BE. See the baserock/311/be/atags branch in
>> > git://git.baserock.org/delta/linux. Or
>> > http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>
>>  ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
>> It hangs at very early stage of boot
>
> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
> of the TODO-list. I think Ben said he would probably not have much time
> to work on this. I might be able to spare some time on this, so just
> let me know if I should start working on this. If I remember correctly,
> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.

In fact, I tried with below changes.. still it fails

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 2de1114..7df64c7 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -592,8 +592,14 @@ __fixup_a_pv_table:
        b       2f
 1:     add     r7, r3
        ldrh    ip, [r7, #2]
+#ifdef CONFIG_CPU_ENDIAN_BE8
+       rev     ip, ip
+#endif
        and     ip, 0x8f00
        orr     ip, r6  @ mask in offset bits 31-24
+#ifdef CONFIG_CPU_ENDIAN_BE8
+       rev     ip, ip
+#endif
        strh    ip, [r7, #2]
 2:     cmp     r4, r5
        ldrcc   r7, [r4], #4    @ use branch for delay slot

>
> Will, is getting Thumb2 working a requirement to get the BE support
> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com


From balbi at ti.com  Fri Jul 12 07:58:05 2013
From: balbi at ti.com (Felipe Balbi)
Date: Fri, 12 Jul 2013 14:58:05 +0300
Subject: [PATCH] arm: omap5: dts: fix reg property size
Message-ID: <1373630285-17389-1-git-send-email-balbi@ti.com>

USB3 block has a 64KiB space, another 64KiB is
used for the wrapper.

Without this change, resource_size() will get
confused and driver won't probe because size
will be negative.

Signed-off-by: Felipe Balbi <balbi at ti.com>
---

does anybody know Benoit's knew email address ?

 arch/arm/boot/dts/omap5.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..5c99f19 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -637,7 +637,7 @@
 		omap_dwc3 at 4a020000 {
 			compatible = "ti,dwc3";
 			ti,hwmods = "usb_otg_ss";
-			reg = <0x4a020000 0x1000>;
+			reg = <0x4a020000 0x10000>;
 			interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
 			#address-cells = <1>;
 			#size-cells = <1>;
@@ -645,7 +645,7 @@
 			ranges;
 			dwc3 at 4a030000 {
 				compatible = "synopsys,dwc3";
-				reg = <0x4a030000 0x1000>;
+				reg = <0x4a030000 0x10000>;
 				interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
 				usb-phy = <&usb2_phy>, <&usb3_phy>;
 				tx-fifo-resize;
-- 
1.8.2.1



From grygorii.strashko at ti.com  Fri Jul 12 07:58:17 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Fri, 12 Jul 2013 14:58:17 +0300
Subject: [PATCH] arm: omap2plus: unidle devices which are about to probe
In-Reply-To: <1373537788-30413-1-git-send-email-balbi@ti.com>
References: <20130711092612.GG23892@arwen.pp.htv.fi>
 <1373537788-30413-1-git-send-email-balbi@ti.com>
Message-ID: <51DFEF59.1010509@ti.com>

On 07/11/2013 01:16 PM, Felipe Balbi wrote:
> in order to make HWMOD and pm_runtime agree on the
> initial state of the device, we will unidle the device
> and call pm_runtime_set_active() to tell pm_runtime
> that the device is really active.
>
> By the time driver's probe() is reached, a call to
> pm_runtime_get_sync() will not cause driver's
> ->runtime_resume() method to be called at first, only
> after a successful ->runtime_suspend().
>
> Note that we must prevent pm_runtime transitions while
> driver is probing otherwise drivers would be suspended
> as soon as they call pm_runtime_use_autosuspend(). By
> calling pm_runtime_forbid() before probe() and
> pm_runtime_allow() after probe() we 'fix' that detail.
>
> Note that this patch was inspired by PCI's pci_pm_init().

NAK. This is a hack.
In addition to what I've mentioned in
http://www.spinics.net/lists/arm-kernel/msg258061.html there are 
following issues:
1) this patch disables call to PM runtime callbacks for all
OMAP drivers which is wrong - I've found, for example, that
omap-usb-host.c driver enables TLL in some configurations in its
.runtime_resume():

usbhs_runtime_resume()
|-omap_tll_enable()


2) even with this fix the restore context issue will not be fixed for 
*non* console UARTs. Just try:
#echo 0xDEAD > dev/ttyO3 // checked on OMAP4 SDP

3) I've checked most of OMAP drivers and all of them solve such kind of 
problem internally (SPI, MMC, I2C, etc.)

4) See inline
>
> Signed-off-by: Felipe Balbi <balbi at ti.com>
> ---
>
> boot tested on top of today's Linus master
> 6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
> panda. Reached console prompt and, after setting a
> proper autosuspend delay, consoles autosuspend just
> fine.
>
> It needs to be tested on other platforms.
>
> ps: note that we also call pm_runtime_set_suspended(dev)
> from our late_initcall() to disable devices so that pm_runtime
> and HWMOD continue to aggree on device's state.
>
>   arch/arm/mach-omap2/omap_device.c | 44 +++++++++++++++++++++++++++++++++++----
>   1 file changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 5cc9287..cb1fc1d 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -178,6 +178,26 @@ odbfd_exit:
>   	return ret;
>   }
>
> +static void omap_device_pm_init(struct platform_device *pdev)
> +{
> +	omap_device_enable(pdev);
> +	pm_runtime_forbid(&pdev->dev);
It's wrong to use pm_runtime_forbid() - pm_runtime_get_noresume() should 
be used instead.
pm_runtime_forbid()
|-rpm_resume()


> +	pm_runtime_set_active(&pdev->dev);
> +	device_enable_async_suspend(&pdev->dev);
why did you use device_enable_async_suspend() - it would enable async 
suspend for devices - this is not related to the current issue and topic 
for discussion (currently is used by usb/scsi/pci/ata drivers only).
> +}
> +
> +static void omap_device_pm_allow(struct platform_device *pdev)
> +{
> +	pm_runtime_allow(&pdev->dev);
> +}
> +
> +static void omap_device_pm_exit(struct platform_device *pdev)
> +{
> +	device_disable_async_suspend(&pdev->dev);
> +	pm_runtime_set_suspended(&pdev->dev);
> +	omap_device_idle(pdev);
> +}
> +
>   static int _omap_device_notifier_call(struct notifier_block *nb,
>   				      unsigned long event, void *dev)
>   {
> @@ -189,16 +209,31 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
>   		if (pdev->archdata.od)
>   			omap_device_delete(pdev->archdata.od);
>   		break;
> +	case BUS_NOTIFY_BIND_DRIVER:
> +		if (pdev->archdata.od)
> +			omap_device_pm_init(pdev);
> +		break;
> +	case BUS_NOTIFY_BOUND_DRIVER:
> +		if (pdev->archdata.od)
> +			omap_device_pm_allow(pdev);
> +		break;
> +	case BUS_NOTIFY_UNBOUND_DRIVER:
> +		if (pdev->archdata.od)
> +			omap_device_pm_exit(pdev);
> +		break;
>   	case BUS_NOTIFY_ADD_DEVICE:
>   		if (pdev->dev.of_node)
>   			omap_device_build_from_dt(pdev);
> -		/* fall through */
> +		break;
>   	default:
> -		od = to_omap_device(pdev);
> -		if (od)
> -			od->_driver_status = event;
> +		/* nothing */
> +		break;
>   	}
>
> +	od = to_omap_device(pdev);
> +	if (od)
> +		od->_driver_status = event;
> +
>   	return NOTIFY_DONE;
>   }
>
> @@ -855,6 +890,7 @@ static int __init omap_device_late_idle(struct device *dev, void *data)
>   			dev_warn(dev, "%s: enabled but no driver.  Idling\n",
>   				 __func__);
>   			omap_device_idle(pdev);
> +			pm_runtime_set_suspended(dev);
>   		}
>   	}
>
>



From ben.dooks at codethink.co.uk  Fri Jul 12 07:58:45 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Fri, 12 Jul 2013 12:58:45 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <20130712134726.0a909165@skate>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate>
Message-ID: <51DFEF75.8080600@codethink.co.uk>

On 12/07/13 12:47, Thomas Petazzoni wrote:
> Dear Vijay Kilari,
>
> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>
>>> Ben Dooks has a separate branch on top of this base branch for
>>> big-endian support, that adds atags compat code to convert the ATAGs
>>> data from LE to BE. See the baserock/311/be/atags branch in
>>> git://git.baserock.org/delta/linux. Or
>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>
>>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
>> It hangs at very early stage of boot
>
> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
> of the TODO-list. I think Ben said he would probably not have much time
> to work on this. I might be able to spare some time on this, so just
> let me know if I should start working on this. If I remember correctly,
> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>
> Will, is getting Thumb2 working a requirement to get the BE support
> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?

I would like to sort out getting this code merged as it seems to have
been tested by several people now outside Codethink.

I could try doing the THUMB2 support, but I do not have a lot of
experience with building THUMB2 kernels.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From ben.dooks at codethink.co.uk  Fri Jul 12 08:00:25 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Fri, 12 Jul 2013 13:00:25 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <CALicx6sr=OXYAdSS-RXPCjSp4f_yLQyw6jJsQ2KyhgQ9fRtXag@mail.gmail.com>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate>
 <CALicx6sr=OXYAdSS-RXPCjSp4f_yLQyw6jJsQ2KyhgQ9fRtXag@mail.gmail.com>
Message-ID: <51DFEFD9.2060509@codethink.co.uk>

On 12/07/13 12:56, Vijay Kilari wrote:
> On Fri, Jul 12, 2013 at 5:17 PM, Thomas Petazzoni
> <thomas.petazzoni at free-electrons.com>  wrote:
>> Dear Vijay Kilari,
>>
>> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>>
>>>> Ben Dooks has a separate branch on top of this base branch for
>>>> big-endian support, that adds atags compat code to convert the ATAGs
>>>> data from LE to BE. See the baserock/311/be/atags branch in
>>>> git://git.baserock.org/delta/linux. Or
>>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>>
>>>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
>>> It hangs at very early stage of boot
>>
>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>> of the TODO-list. I think Ben said he would probably not have much time
>> to work on this. I might be able to spare some time on this, so just
>> let me know if I should start working on this. If I remember correctly,
>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>
> In fact, I tried with below changes.. still it fails
>
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 2de1114..7df64c7 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -592,8 +592,14 @@ __fixup_a_pv_table:
>          b       2f
>   1:     add     r7, r3
>          ldrh    ip, [r7, #2]
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +       rev     ip, ip
> +#endif

Do you need a rev16 here? I think you may have tried
reversing the full 32 bits here instead of just the
16bits of instruction that was loaded.

>          and     ip, 0x8f00
>          orr     ip, r6  @ mask in offset bits 31-24
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +       rev     ip, ip
> +#endif
>          strh    ip, [r7, #2]
>   2:     cmp     r4, r5
>          ldrcc   r7, [r4], #4    @ use branch for delay slot
>
>>
>> Will, is getting Thumb2 working a requirement to get the BE support
>> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>>
>> Thanks!
>>
>> Thomas
>> --
>> Thomas Petazzoni, Free Electrons
>> Kernel, drivers, real-time and embedded Linux
>> development, consulting, training and support.
>> http://free-electrons.com


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From mingo at kernel.org  Fri Jul 12 08:06:13 2013
From: mingo at kernel.org (Ingo Molnar)
Date: Fri, 12 Jul 2013 14:06:13 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130712041810.53c86e5f.akpm@linux-foundation.org>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130712075602.GA4002@gmail.com> <20130712080145.GC24008@pd.tnic>
 <20130712101319.GA13421@gmail.com> <20130712102326.GE24008@pd.tnic>
 <20130712041810.53c86e5f.akpm@linux-foundation.org>
Message-ID: <20130712120613.GA21313@gmail.com>


* Andrew Morton <akpm at linux-foundation.org> wrote:

> On Fri, 12 Jul 2013 12:23:26 +0200 Borislav Petkov <bp at alien8.de> wrote:
> 
> > On Fri, Jul 12, 2013 at 12:13:19PM +0200, Ingo Molnar wrote:
> > > and now it is upstream already, via -mm:
> > > 
> > >    e76e1fdfa8f8 lib: add support for LZ4-compressed kernel
> > 
> > Sure. Let's see if it manages to get released b0rked like it is right
> > now.
> 
> Well y'know, if whining fixed bugs then there would be no problem here 
> at all.
> 
> This problem came up briefly and I thought it had been adequately 
> addressed.  Now a month or two later we find out who are the people who 
> can't be bothered testing -next, but think it terribly important that 
> others do so.

At least with my limited resources -next is unusable for my randconfig 
testing. I can randconfig test the fresh new bugs I introduce plus the 
bugs that slip upstream - which naturally peak during the merge window.

Anyway, I hacked it around locally, sh*t happens, it should be easy enough 
to fix.

Thanks,

	Ingo


From thomas.petazzoni at free-electrons.com  Fri Jul 12 08:06:43 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 12 Jul 2013 14:06:43 +0200
Subject: v3.10 - big endian core support
In-Reply-To: <51DFEF75.8080600@codethink.co.uk>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate> <51DFEF75.8080600@codethink.co.uk>
Message-ID: <20130712140643.2a3f1c68@skate>

Dear Ben Dooks,

On Fri, 12 Jul 2013 12:58:45 +0100, Ben Dooks wrote:

> > Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
> > of the TODO-list. I think Ben said he would probably not have much time
> > to work on this. I might be able to spare some time on this, so just
> > let me know if I should start working on this. If I remember correctly,
> > it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
> >
> > Will, is getting Thumb2 working a requirement to get the BE support
> > merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
> 
> I would like to sort out getting this code merged as it seems to have
> been tested by several people now outside Codethink.

I briefly talked with Will this week at LCE, and apparently he was
generally ok with the patches. He only mentioned that the series should
be split between core ARM stuff (that goes through Russell's tree), and
the platform-specific changes, that go through the different
maintainers tree.

> I could try doing the THUMB2 support, but I do not have a lot of
> experience with building THUMB2 kernels.

Ok. Let me know if you need some help. I'd really like to see this BE
work make it into 3.12.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From monstr at monstr.eu  Fri Jul 12 08:08:10 2013
From: monstr at monstr.eu (Michal Simek)
Date: Fri, 12 Jul 2013 14:08:10 +0200
Subject: [PATCH v2 2/2] clocksource/cadence_ttc: Reuse clocksource as
 sched_clock
In-Reply-To: <1373302298-27957-3-git-send-email-soren.brinkmann@xilinx.com>
References: <1373302298-27957-1-git-send-email-soren.brinkmann@xilinx.com>
 <1373302298-27957-3-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <51DFF1AA.8080407@monstr.eu>

On 07/08/2013 06:51 PM, Soren Brinkmann wrote:
> Reuse the TTC clocksource timer as sched clock provider.
> 
> Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
> ---
> v2:
>  - #include linux/sched_clock.h instead of asm/sched_clock.h
>  - remove Kconfig options and #ifdefs around sched_clock related code
>     The reasons for having those are obsolete, since ARM deprecated its
>     custom sched_clock framework and migrated to the common one.
> 
>  drivers/clocksource/cadence_ttc_timer.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/clocksource/cadence_ttc_timer.c b/drivers/clocksource/cadence_ttc_timer.c
> index 0eefc8d..b2bb3a4b 100644
> --- a/drivers/clocksource/cadence_ttc_timer.c
> +++ b/drivers/clocksource/cadence_ttc_timer.c
> @@ -21,6 +21,7 @@
>  #include <linux/of_address.h>
>  #include <linux/of_irq.h>
>  #include <linux/slab.h>
> +#include <linux/sched_clock.h>
>  
>  /*
>   * This driver configures the 2 16-bit count-up timers as follows:
> @@ -94,6 +95,8 @@ struct ttc_timer_clockevent {
>  #define to_ttc_timer_clkevent(x) \
>  		container_of(x, struct ttc_timer_clockevent, ce)
>  
> +static void __iomem *ttc_sched_clock_val_reg;
> +
>  /**
>   * ttc_set_interval - Set the timer interval value
>   *
> @@ -155,6 +158,11 @@ static cycle_t __ttc_clocksource_read(struct clocksource *cs)
>  				TTC_COUNT_VAL_OFFSET);
>  }
>  
> +static u32 notrace ttc_sched_clock_read(void)
> +{
> +	return __raw_readl(ttc_sched_clock_val_reg);
> +}
> +
>  /**
>   * ttc_set_next_event - Sets the time interval for next event
>   *
> @@ -296,6 +304,10 @@ static void __init ttc_setup_clocksource(struct clk *clk, void __iomem *base)
>  		kfree(ttccs);
>  		return;
>  	}
> +
> +	ttc_sched_clock_val_reg = base + TTC_COUNT_VAL_OFFSET;
> +	setup_sched_clock(ttc_sched_clock_read, 16,
> +			clk_get_rate(ttccs->ttc.clk) / PRESCALE);
>  }
>  
>  static int ttc_rate_change_clockevent_cb(struct notifier_block *nb,
> 

Acked-by: Michal Simek <monstr at monstr.eu>

Thomas, John: Can you please add this patch to your queue?
IRC all these timer patches should go through your trees.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130712/bdcd7113/attachment.sig>

From sboyd at codeaurora.org  Fri Jul 12 08:10:23 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 12 Jul 2013 05:10:23 -0700
Subject: [PATCH] irqchip: gic: Don't complain in gic_get_cpumask() if
 UP system
In-Reply-To: <20130712111322.GC3213@e102654-lin.cambridge.arm.com>
References: <1373067573-29946-1-git-send-email-sboyd@codeaurora.org>
 <20130712111322.GC3213@e102654-lin.cambridge.arm.com>
Message-ID: <20130712121023.GB27430@codeaurora.org>

On 07/12, Javi Merino wrote:
> On Sat, Jul 06, 2013 at 12:39:33AM +0100, Stephen Boyd wrote:
> > In a uniprocessor implementation the interrupt processor targets
> > registers are read-as-zero/write-ignored (RAZ/WI). Unfortunately
> > gic_get_cpumask() will print a critical message saying
> > 
> >  GIC CPU mask not found - kernel will fail to boot.
> > 
> > if these registers all read as zero, but there won't actually be
> > a problem on uniprocessor systems and the kernel will boot just
> > fine. Skip this check if we're running a UP kernel or if we
> > detect that the hardware only supports a single processor.
> > 
> > Cc: Nicolas Pitre <nico at linaro.org>
> > Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> > Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> > ---
> > 
> > Maybe we should just drop the check entirely? It looks like it may
> > just be debug code that won't ever trigger in practice, even on the
> > 11MPCore that caused this code to be introduced.
> 
> I agree, we should drop the check.  It's annoying in uniprocessors and
> unlikely to be found in the real world unless your gic entry in the dt
> is wrong.
> 

Ok. How about this?

----8<-----
Subject: [PATCH v2] irqchip: gic: Don't complain in gic_get_cpumask()

In a uniprocessor implementation the interrupt processor targets
registers are read-as-zero/write-ignored (RAZ/WI). Unfortunately
gic_get_cpumask() will print a critical message saying

 GIC CPU mask not found - kernel will fail to boot.

if these registers all read as zero, but there won't actually be
a problem on uniprocessor systems and the kernel will boot just
fine. Remove this check because if you're on a multiprocessor
system it's unlikely to be printed unless your DT is wrong or
your hardware is broken.

Cc: Nicolas Pitre <nico at linaro.org>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Cc: Javi Merino <javi.merino at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/irqchip/irq-gic.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 19ceaa60..4fbcea9 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -368,9 +368,6 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic)
 			break;
 	}
 
-	if (!mask)
-		pr_crit("GIC CPU mask not found - kernel will fail to boot.\n");
-
 	return mask;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From balbi at ti.com  Fri Jul 12 08:10:31 2013
From: balbi at ti.com (Felipe Balbi)
Date: Fri, 12 Jul 2013 15:10:31 +0300
Subject: [PATCH] arm: omap2plus: unidle devices which are about to probe
In-Reply-To: <51DFEF59.1010509@ti.com>
References: <20130711092612.GG23892@arwen.pp.htv.fi>
 <1373537788-30413-1-git-send-email-balbi@ti.com>
 <51DFEF59.1010509@ti.com>
Message-ID: <20130712121031.GB17053@arwen.pp.htv.fi>

On Fri, Jul 12, 2013 at 02:58:17PM +0300, Grygorii Strashko wrote:
> On 07/11/2013 01:16 PM, Felipe Balbi wrote:
> >in order to make HWMOD and pm_runtime agree on the
> >initial state of the device, we will unidle the device
> >and call pm_runtime_set_active() to tell pm_runtime
> >that the device is really active.
> >
> >By the time driver's probe() is reached, a call to
> >pm_runtime_get_sync() will not cause driver's
> >->runtime_resume() method to be called at first, only
> >after a successful ->runtime_suspend().
> >
> >Note that we must prevent pm_runtime transitions while
> >driver is probing otherwise drivers would be suspended
> >as soon as they call pm_runtime_use_autosuspend(). By
> >calling pm_runtime_forbid() before probe() and
> >pm_runtime_allow() after probe() we 'fix' that detail.
> >
> >Note that this patch was inspired by PCI's pci_pm_init().
> 
> NAK. This is a hack.

hack is your flag to check if the driver is "initialized". pff

> In addition to what I've mentioned in
> http://www.spinics.net/lists/arm-kernel/msg258061.html there are
> following issues:
> 1) this patch disables call to PM runtime callbacks for all

no, it does not. It forbids pm runtime transitions during probe.

> OMAP drivers which is wrong - I've found, for example, that
> omap-usb-host.c driver enables TLL in some configurations in its
> .runtime_resume():
> 
> usbhs_runtime_resume()
> |-omap_tll_enable()

which is wrong. PM runtime callbacks are supposed to be use for,
surprise, PM!

> 2) even with this fix the restore context issue will not be fixed for
> *non* console UARTs. Just try:
> #echo 0xDEAD > dev/ttyO3 // checked on OMAP4 SDP

that I have not checked, but then again, with that you're not calling
set_termios() anyway.

> 3) I've checked most of OMAP drivers and all of them solve such kind
> of problem internally (SPI, MMC, I2C, etc.)

and you see no problem with that ? Repeating the same thing over and
over again ?

> 4) See inline
> >
> >Signed-off-by: Felipe Balbi <balbi at ti.com>
> >---
> >
> >boot tested on top of today's Linus master
> >6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
> >panda. Reached console prompt and, after setting a
> >proper autosuspend delay, consoles autosuspend just
> >fine.
> >
> >It needs to be tested on other platforms.
> >
> >ps: note that we also call pm_runtime_set_suspended(dev)
> >from our late_initcall() to disable devices so that pm_runtime
> >and HWMOD continue to aggree on device's state.
> >
> >  arch/arm/mach-omap2/omap_device.c | 44 +++++++++++++++++++++++++++++++++++----
> >  1 file changed, 40 insertions(+), 4 deletions(-)
> >
> >diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> >index 5cc9287..cb1fc1d 100644
> >--- a/arch/arm/mach-omap2/omap_device.c
> >+++ b/arch/arm/mach-omap2/omap_device.c
> >@@ -178,6 +178,26 @@ odbfd_exit:
> >  	return ret;
> >  }
> >
> >+static void omap_device_pm_init(struct platform_device *pdev)
> >+{
> >+	omap_device_enable(pdev);
> >+	pm_runtime_forbid(&pdev->dev);
> It's wrong to use pm_runtime_forbid() - pm_runtime_get_noresume()
> should be used instead.

how come ? What makes you think pm_runtime_get_noresume() is the right
thing here ? 

> pm_runtime_forbid()
> |-rpm_resume()

so what ? flags is zero.

-- 
balbi
-------------- 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/20130712/316a3665/attachment.sig>

From rnayak at ti.com  Fri Jul 12 08:12:04 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 12 Jul 2013 17:42:04 +0530
Subject: [PATCH 1/2] Revert "ARM: OMAP2+: Fix serial init for device tree
 based booting"
In-Reply-To: <20130712091827.GH7656@atomide.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
 <1373539986-27272-2-git-send-email-rnayak@ti.com>
 <20130712072051.GA7656@atomide.com> <51DFB0E4.6040007@ti.com>
 <20130712080305.GD7656@atomide.com> <51DFC58C.7030105@ti.com>
 <20130712091827.GH7656@atomide.com>
Message-ID: <51DFF294.9080501@ti.com>

On Friday 12 July 2013 02:48 PM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak at ti.com> [130712 02:06]:
>> On Friday 12 July 2013 01:33 PM, Tony Lindgren wrote:
>>>
>>> OK, so that's only for earlyprintk then?
>>
>> yes,
>>
>>>
>>> If so, it seems the right fix is to set the NO_IDLE and NO_RESET
>>> flags based on ifdef CONFIG_DEBUG_OMAP4UART3 etc as that is selected
>>> in the Kconfig now.
>>
>> ok makes sense. It seems like the static data in hwmod can be populated
>> based on these defines? something like
>>
>> /* uart3 */
>> static struct omap_hwmod omap44xx_uart3_hwmod = {
>>         .name           = "uart3",
>>         .class          = &omap44xx_uart_hwmod_class,
>>         .clkdm_name     = "l4_per_clkdm",
>> #ifdef CONFIG_DEBUG_OMAP4UART3
>>         .flags          = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
>>                                 HWMOD_SWSUP_SIDLE_ACT,
>> #else
>>         .flags          = HWMOD_SWSUP_SIDLE_ACT,
>> #endif
>>         .main_clk       = "func_48m_fclk",
>>         .prcm = {
>>                 .omap4 = {
>>                         .clkctrl_offs = OMAP4_CM_L4PER_UART3_CLKCTRL_OFFSET,
>>                         .context_offs = OMAP4_RM_L4PER_UART3_CONTEXT_OFFSET,
>>                         .modulemode   = MODULEMODE_SWCTRL,
>>                 },
>>         },
>> };
>>
>> And same way for others? That way the cmdline parsing can be done away
>> with even for the non-DT case.
> 
> Yes we can do it that way. How about add a common macro for it if
> it's always the same? Then the .flags line would be just:
> 
> #define HWMOD_OMAP_UART_FLAGS(soc, port)
> ...
> 
> 	.flags		= HWMOD_OMAP_UART_FLAGS(4, 3),

I started doing this and ended up with equal number of #ifdefs in the
header :( Was the intention of doing this to reduce the #ifdefs? in which
case maybe I am doing something wrong.

> 
>>> The current code in mach-omap2/serial.c is wrong, and is a hack
>>> needed for the pdata based booting. What's broken is that
>>> omap_serial_early_init() parses the cmdline for console, which
>>> itself is pretty nasty, and it won't work the right way as
>>> there's nothing stopping from having the earlycon in a different
>>> UART from the serial console. So we just want to get rid of the
>>> whole mach-omap2/serial.c once we're all DT.
>>>
>>> So to summarize, we have two bugs:
>>>
>>> 1. Omap hwmod code can reset UART while earlycon may be using
>>>    it. The fix to this is to use NO_IDLE and NO_RESET flags in
>>>    the hwmod code if CONFIG_DEBUG_OMAPxUARTy is specified.
>>>
>>> 2. A bug in drivers/tty/serial/omap-serial.c where the
>>>    missing context loss count can cause NULL context to be
>>>    initialized during driver probe causing port to hang for
>>>    earlycon. The fix for that is what Felipe has suggested or
>>>    fix it in the driver by removing the context loss count usage
>>>    and detect the need for context restore based on the UART
>>>    state.
>>>
>>> Or am I still missing something?
>>
>> No, thats pretty much the 2 issues we have.
> 
> OK thanks good to hear it's limited to earlycon issues.
> 
> Regards,
> 
> Tony
> 



From bp at alien8.de  Fri Jul 12 08:13:54 2013
From: bp at alien8.de (Borislav Petkov)
Date: Fri, 12 Jul 2013 14:13:54 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130712041810.53c86e5f.akpm@linux-foundation.org>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130712075602.GA4002@gmail.com> <20130712080145.GC24008@pd.tnic>
 <20130712101319.GA13421@gmail.com> <20130712102326.GE24008@pd.tnic>
 <20130712041810.53c86e5f.akpm@linux-foundation.org>
Message-ID: <20130712121354.GG24008@pd.tnic>

On Fri, Jul 12, 2013 at 04:18:10AM -0700, Andrew Morton wrote:
> Well y'know, if whining fixed bugs then there would be no problem here
> at all.

I know. I decided to whine this time and not try to fix it because
attempting to fix every fallout I'm seeing in the tree with randconfigs
is a full-time job and the *actual* job doesn't see any progress.

And in all fairness, if someone were reporting an issue against my code,
I'll try to do my very best to fix it as quickly aas possible, instead
of ignoring it.

So actually, the right thing to do in such cases is back out half-cooked
stuff from the tree until it gets fixed. That'll give the authors the
right incentive. But this is just me.

> This problem came up briefly and I thought it had been adequately
> addressed. Now a month or two later we find out who are the people who
> can't be bothered testing -next, but think it terribly important that
> others do so.

Yeah, if everyone would put their money where their mouth is...

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--


From rnayak at ti.com  Fri Jul 12 08:27:51 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Fri, 12 Jul 2013 17:57:51 +0530
Subject: [PATCH] arm: omap2plus: unidle devices which are about to probe
In-Reply-To: <20130712121031.GB17053@arwen.pp.htv.fi>
References: <20130711092612.GG23892@arwen.pp.htv.fi>
 <1373537788-30413-1-git-send-email-balbi@ti.com> <51DFEF59.1010509@ti.com>
 <20130712121031.GB17053@arwen.pp.htv.fi>
Message-ID: <51DFF647.6030709@ti.com>

On Friday 12 July 2013 05:40 PM, Felipe Balbi wrote:
>> 3) I've checked most of OMAP drivers and all of them solve such kind
>> > of problem internally (SPI, MMC, I2C, etc.)
> and you see no problem with that ? Repeating the same thing over and
> over again ?
> 

I agree with Felipe that this is best handled at the bus/omap-device level
to avoid all drivers having to repeat the same thing over.
Having said that I dont know whats the best way to do this for OMAP and the
patch we have currently does seem to have atleast issues handling processor
IPs as Suman mentioned.

regards,
Rajendra


From maxime.ripard at free-electrons.com  Fri Jul 12 08:30:28 2013
From: maxime.ripard at free-electrons.com (maxime.ripard at free-electrons.com)
Date: Fri, 12 Jul 2013 14:30:28 +0200
Subject: [PATCH RESEND] video: mxsfb: fix color settings for 18bit data
 bus and 32bpp
In-Reply-To: <20130703085505.GG2969@lukather>
References: <51C01DE1.8030300@digi.com>
 <20130703085505.GG2969@lukather>
Message-ID: <20130712123028.GJ24370@lukather>

On Wed, Jul 03, 2013 at 10:55:05AM +0200, maxime.ripard at free-electrons.com wrote:
> Hi Jean-Christophe,
> 
> On Tue, Jun 18, 2013 at 10:44:17AM +0200, Hector Palacios wrote:
> > For a combination of 18bit LCD data bus width and a color
> > mode of 32bpp, the driver was setting the color mapping to
> > rgb666, which is wrong, as the color in memory realy has an
> > rgb888 layout.
> > 
> > This patch also removes the setting of flag CTRL_DF24 that
> > makes the driver dimiss the upper 2 bits when handling 32/24bpp
> > colors in a diplay with 18bit data bus width. This flag made
> > true color images display wrong in such configurations.
> > 
> > Finally, the color mapping rgb666 has also been removed as nobody
> > is using it and high level applications like Qt5 cannot work
> > with it either.
> > 
> > Reference: https://lkml.org/lkml/2013/5/23/220
> > Signed-off-by: Hector Palacios <hector.palacios at digi.com>
> > Acked-by: Juergen Beisert <jbe at pengutronix.de>
> > Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> 
> I don't see this patch in your for-next branch.
> 
> It would be really great to have it for 3.11 if possible.
> 
> Could you take a look at this patch please?

Ping?

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130712/f181e374/attachment.sig>

From ben.dooks at codethink.co.uk  Fri Jul 12 08:33:27 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Fri, 12 Jul 2013 13:33:27 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <20130712140643.2a3f1c68@skate>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate> <51DFEF75.8080600@codethink.co.uk>
 <20130712140643.2a3f1c68@skate>
Message-ID: <51DFF797.8080100@codethink.co.uk>

On 12/07/13 13:06, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Fri, 12 Jul 2013 12:58:45 +0100, Ben Dooks wrote:
>
>>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>>> of the TODO-list. I think Ben said he would probably not have much time
>>> to work on this. I might be able to spare some time on this, so just
>>> let me know if I should start working on this. If I remember correctly,
>>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>>>
>>> Will, is getting Thumb2 working a requirement to get the BE support
>>> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>>
>> I would like to sort out getting this code merged as it seems to have
>> been tested by several people now outside Codethink.
>
> I briefly talked with Will this week at LCE, and apparently he was
> generally ok with the patches. He only mentioned that the series should
> be split between core ARM stuff (that goes through Russell's tree), and
> the platform-specific changes, that go through the different
> maintainers tree.

The 311/be/core series which was the first posted has a few machine
specific bits in it (vexpress, highbank and mvebu) but is mainly the
ARM core code and bits of peripheral specific support which still live
under arch/arm.

I left there there as they're fairly small patches and would tend to get
lost. I can remove these before asking RMK to pull the core support and
possibly the atag/boot-endian patches.

>> I could try doing the THUMB2 support, but I do not have a lot of
>> experience with building THUMB2 kernels.
>
> Ok. Let me know if you need some help. I'd really like to see this BE
> work make it into 3.12.

Thanks for the testing. I'll see if I can get some time in early next
week to re-test and send against 3.11-rc series.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From tony at atomide.com  Fri Jul 12 08:33:31 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Jul 2013 05:33:31 -0700
Subject: [PATCH 1/2] Revert "ARM: OMAP2+: Fix serial init for device
 tree based booting"
In-Reply-To: <51DFF294.9080501@ti.com>
References: <1373539986-27272-1-git-send-email-rnayak@ti.com>
 <1373539986-27272-2-git-send-email-rnayak@ti.com>
 <20130712072051.GA7656@atomide.com> <51DFB0E4.6040007@ti.com>
 <20130712080305.GD7656@atomide.com> <51DFC58C.7030105@ti.com>
 <20130712091827.GH7656@atomide.com> <51DFF294.9080501@ti.com>
Message-ID: <20130712123331.GJ7656@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130712 05:18]:
> On Friday 12 July 2013 02:48 PM, Tony Lindgren wrote:
> > * Rajendra Nayak <rnayak at ti.com> [130712 02:06]:
> >> On Friday 12 July 2013 01:33 PM, Tony Lindgren wrote:
> >>>
> >>> OK, so that's only for earlyprintk then?
> >>
> >> yes,
> >>
> >>>
> >>> If so, it seems the right fix is to set the NO_IDLE and NO_RESET
> >>> flags based on ifdef CONFIG_DEBUG_OMAP4UART3 etc as that is selected
> >>> in the Kconfig now.
> >>
> >> ok makes sense. It seems like the static data in hwmod can be populated
> >> based on these defines? something like
> >>
> >> /* uart3 */
> >> static struct omap_hwmod omap44xx_uart3_hwmod = {
> >>         .name           = "uart3",
> >>         .class          = &omap44xx_uart_hwmod_class,
> >>         .clkdm_name     = "l4_per_clkdm",
> >> #ifdef CONFIG_DEBUG_OMAP4UART3
> >>         .flags          = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
> >>                                 HWMOD_SWSUP_SIDLE_ACT,
> >> #else
> >>         .flags          = HWMOD_SWSUP_SIDLE_ACT,
> >> #endif
> >>         .main_clk       = "func_48m_fclk",
> >>         .prcm = {
> >>                 .omap4 = {
> >>                         .clkctrl_offs = OMAP4_CM_L4PER_UART3_CLKCTRL_OFFSET,
> >>                         .context_offs = OMAP4_RM_L4PER_UART3_CONTEXT_OFFSET,
> >>                         .modulemode   = MODULEMODE_SWCTRL,
> >>                 },
> >>         },
> >> };
> >>
> >> And same way for others? That way the cmdline parsing can be done away
> >> with even for the non-DT case.
> > 
> > Yes we can do it that way. How about add a common macro for it if
> > it's always the same? Then the .flags line would be just:
> > 
> > #define HWMOD_OMAP_UART_FLAGS(soc, port)
> > ...
> > 
> > 	.flags		= HWMOD_OMAP_UART_FLAGS(4, 3),
> 
> I started doing this and ended up with equal number of #ifdefs in the
> header :( Was the intention of doing this to reduce the #ifdefs? in which
> case maybe I am doing something wrong.

Hmm can't you use ## for substition in the macro to reduce the ifdefs
and have just one macro instead one for every debug port?

Regards,

Tony


From florian at openwrt.org  Fri Jul 12 08:34:38 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Fri, 12 Jul 2013 13:34:38 +0100
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130712121354.GG24008@pd.tnic>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130712075602.GA4002@gmail.com>
 <20130712080145.GC24008@pd.tnic> <20130712101319.GA13421@gmail.com>
 <20130712102326.GE24008@pd.tnic>
 <20130712041810.53c86e5f.akpm@linux-foundation.org>
 <20130712121354.GG24008@pd.tnic>
Message-ID: <CAGVrzcZq-NQU=1UY7FpXPXZPFjJV7CQMsNQJbdY=bLTFVqGQHA@mail.gmail.com>

Hello,

2013/7/12 Borislav Petkov <bp at alien8.de>:
> On Fri, Jul 12, 2013 at 04:18:10AM -0700, Andrew Morton wrote:
>> Well y'know, if whining fixed bugs then there would be no problem here
>> at all.
>
> I know. I decided to whine this time and not try to fix it because
> attempting to fix every fallout I'm seeing in the tree with randconfigs
> is a full-time job and the *actual* job doesn't see any progress.
>
> And in all fairness, if someone were reporting an issue against my code,
> I'll try to do my very best to fix it as quickly aas possible, instead
> of ignoring it.
>
> So actually, the right thing to do in such cases is back out half-cooked
> stuff from the tree until it gets fixed. That'll give the authors the
> right incentive. But this is just me.
>
>> This problem came up briefly and I thought it had been adequately
>> addressed. Now a month or two later we find out who are the people who
>> can't be bothered testing -next, but think it terribly important that
>> others do so.
>
> Yeah, if everyone would put their money where their mouth is...

Shall we provide a shell script wrapper for all of these compressor
commands which would test for the utility presence and issue a BIG FAT
WARNING if not, but still create the file not to make the kernel build
fail? I guess we could probably do this in the Makefile directly as
well.
--
Florian


From kishon at ti.com  Fri Jul 12 08:37:04 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 12 Jul 2013 18:07:04 +0530
Subject: [PATCH] arm: omap5: dts: fix reg property size
In-Reply-To: <1373630285-17389-1-git-send-email-balbi@ti.com>
References: <1373630285-17389-1-git-send-email-balbi@ti.com>
Message-ID: <51DFF870.5060507@ti.com>

On Friday 12 July 2013 05:28 PM, Felipe Balbi wrote:
> USB3 block has a 64KiB space, another 64KiB is
> used for the wrapper.
> 
> Without this change, resource_size() will get
> confused and driver won't probe because size
> will be negative.
> 
> Signed-off-by: Felipe Balbi <balbi at ti.com>
> ---
> 
> does anybody know Benoit's knew email address ?
benoit.cousson at linaro.org

-Kishon


From samuel.thibault at ens-lyon.org  Fri Jul 12 08:42:42 2013
From: samuel.thibault at ens-lyon.org (Samuel Thibault)
Date: Fri, 12 Jul 2013 14:42:42 +0200
Subject: [PATCH] Route kbd LEDs through the generic LEDs layer
In-Reply-To: <20130712113655.GA4227@amd.pavel.ucw.cz>
References: <201011112205.oABM5KVJ005298@imap1.linux-foundation.org>
 <201011111440.07882.dmitry.torokhov@gmail.com>
 <20110102090935.GV32469@atrey.karlin.mff.cuni.cz>
 <20110102103210.GA25662@core.coreip.homeip.net>
 <20110102225741.GX5480@const.famille.thibault.fr>
 <20110112182702.GA9168@core.coreip.homeip.net>
 <20111114040613.GA4992@type.famille.thibault.fr>
 <20121221003449.GA6999@type.youpi.perso.aquilenet.fr>
 <20130707101028.GD5651@type.youpi.perso.aquilenet.fr>
 <20130712113655.GA4227@amd.pavel.ucw.cz>
Message-ID: <20130712124242.GA5876@type>

Pavel Machek, le Fri 12 Jul 2013 13:36:56 +0200, a ?crit :
> > This permits to reassign keyboard LEDs to something else than keyboard "leds"
> > state, by adding keyboard led and modifier triggers connected to a series
> > of VT input LEDs, themselves connected to VT input triggers, which
> > per-input device LEDs use by default.  Userland can thus easily change the LED
> > behavior of (a priori) all input devices, or of particular input devices.
> 
> Nice! Leds now have proper /sys interface.
> 
> But... I boot up, switch from X to console, press capslock, and no
> reaction anywhere.

Is it working without the patch?  Console-setup for instance is known to
have broken the capslock LED, which is precisely one of the reasons for
this patch, which will provide console-setup with a way to bring back
caps lock working properly.

At any rate, please provide way more information about your keyboard
and LED configuration (output of dumpkeys, dmesg, content of
/sys/class/leds/*/trigger, etc.), as things are just working fine for me
(just like it has been for the past two years).

> Note that this is notebook with usb keyboard plugged in (and two
> monitors), but I believe this worked before...

Things work fine with my USB keyboard too, is this perhaps using an odd
driver which would not expose LEDs in a standard way?

Samuel


From balbi at ti.com  Fri Jul 12 08:45:54 2013
From: balbi at ti.com (Felipe Balbi)
Date: Fri, 12 Jul 2013 15:45:54 +0300
Subject: [PATCH] arm: omap5: dts: fix reg property size
In-Reply-To: <1373630285-17389-1-git-send-email-balbi@ti.com>
References: <1373630285-17389-1-git-send-email-balbi@ti.com>
Message-ID: <20130712124554.GA18154@arwen.pp.htv.fi>

+ Benoit

On Fri, Jul 12, 2013 at 02:58:05PM +0300, Felipe Balbi wrote:
> USB3 block has a 64KiB space, another 64KiB is
> used for the wrapper.
> 
> Without this change, resource_size() will get
> confused and driver won't probe because size
> will be negative.
> 
> Signed-off-by: Felipe Balbi <balbi at ti.com>
> ---
> 
> does anybody know Benoit's knew email address ?
> 
>  arch/arm/boot/dts/omap5.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index e643620..5c99f19 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -637,7 +637,7 @@
>  		omap_dwc3 at 4a020000 {
>  			compatible = "ti,dwc3";
>  			ti,hwmods = "usb_otg_ss";
> -			reg = <0x4a020000 0x1000>;
> +			reg = <0x4a020000 0x10000>;
>  			interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
>  			#address-cells = <1>;
>  			#size-cells = <1>;
> @@ -645,7 +645,7 @@
>  			ranges;
>  			dwc3 at 4a030000 {
>  				compatible = "synopsys,dwc3";
> -				reg = <0x4a030000 0x1000>;
> +				reg = <0x4a030000 0x10000>;
>  				interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
>  				usb-phy = <&usb2_phy>, <&usb3_phy>;
>  				tx-fifo-resize;
> -- 
> 1.8.2.1
> 

-- 
balbi
-------------- 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/20130712/5a82452d/attachment.sig>

From bp at alien8.de  Fri Jul 12 08:46:57 2013
From: bp at alien8.de (Borislav Petkov)
Date: Fri, 12 Jul 2013 14:46:57 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <CAGVrzcZq-NQU=1UY7FpXPXZPFjJV7CQMsNQJbdY=bLTFVqGQHA@mail.gmail.com>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130712075602.GA4002@gmail.com> <20130712080145.GC24008@pd.tnic>
 <20130712101319.GA13421@gmail.com> <20130712102326.GE24008@pd.tnic>
 <20130712041810.53c86e5f.akpm@linux-foundation.org>
 <20130712121354.GG24008@pd.tnic>
 <CAGVrzcZq-NQU=1UY7FpXPXZPFjJV7CQMsNQJbdY=bLTFVqGQHA@mail.gmail.com>
Message-ID: <20130712124657.GH24008@pd.tnic>

On Fri, Jul 12, 2013 at 01:34:38PM +0100, Florian Fainelli wrote:
> Shall we provide a shell script wrapper for all of these compressor
> commands which would test for the utility presence and issue a BIG FAT
> WARNING if not, but still create the file not to make the kernel build
> fail? I guess we could probably do this in the Makefile directly as
> well.

I don't know how that would work with the main kernel Makefile
but we do those kinds of tests in perf before we build it so
that we can save ourselves the time spent on a failed build:
2209001fd895e8932ae2c85bfca233758234499a.

This should probably work if you add a prerequisite target which runs
early in the build process and checks for all the userspace tools
required for the build.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--


From festevam at gmail.com  Fri Jul 12 08:49:30 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 12 Jul 2013 09:49:30 -0300
Subject: [PATCH v3 1/4] ARM: dts: imx6qdl.dtsi: Add usdhc1 pin groups
Message-ID: <1373633373-3352-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v2:
- None. Newly introduced in this series

 arch/arm/boot/dts/imx6qdl.dtsi | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 72a28d6..14c9726 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1092,6 +1092,34 @@
 					};
 				};
 
+				usdhc1 {
+					pinctrl_usdhc1_1: usdhc1grp-1 {
+						fsl,pins = <
+							MX6QDL_PAD_SD1_CMD__SD1_CMD    0x17059
+							MX6QDL_PAD_SD1_CLK__SD1_CLK    0x10059
+							MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17059
+							MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17059
+							MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17059
+							MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17059
+							MX6QDL_PAD_NANDF_D0__SD1_DATA4 0x17059
+							MX6QDL_PAD_NANDF_D1__SD1_DATA5 0x17059
+							MX6QDL_PAD_NANDF_D2__SD1_DATA6 0x17059
+							MX6QDL_PAD_NANDF_D3__SD1_DATA7 0x17059
+						>;
+					};
+
+					pinctrl_usdhc1_2: usdhc1grp-2 {
+						fsl,pins = <
+							MX6QDL_PAD_SD1_CMD__SD1_CMD    0x17059
+							MX6QDL_PAD_SD1_CLK__SD1_CLK    0x10059
+							MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17059
+							MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17059
+							MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17059
+							MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17059
+						>;
+					};
+				};
+
 				usdhc2 {
 					pinctrl_usdhc2_1: usdhc2grp-1 {
 						fsl,pins = <
-- 
1.8.1.2



From festevam at gmail.com  Fri Jul 12 08:49:31 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 12 Jul 2013 09:49:31 -0300
Subject: [PATCH v3 2/4] ARM: dts: imx6qdl.dtsi: Add another uart3 pin group
In-Reply-To: <1373633373-3352-1-git-send-email-festevam@gmail.com>
References: <1373633373-3352-1-git-send-email-festevam@gmail.com>
Message-ID: <1373633373-3352-2-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v2:
- None. Newly introduced in this series

 arch/arm/boot/dts/imx6qdl.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 14c9726..b564d74 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1037,6 +1037,15 @@
 							MX6QDL_PAD_EIM_EB3__UART3_RTS_B   0x1b0b1
 						>;
 					};
+
+					pinctrl_uart3_2: uart3grp-2 {
+						fsl,pins = <
+							MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
+							MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
+							MX6QDL_PAD_EIM_D23__UART3_CTS_B	  0x1b0b1
+							MX6QDL_PAD_EIM_EB3__UART3_RTS_B	  0x1b0b1
+						>;
+					};
 				};
 
 				uart4 {
-- 
1.8.1.2



From festevam at gmail.com  Fri Jul 12 08:49:32 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 12 Jul 2013 09:49:32 -0300
Subject: [PATCH v3 3/4] ARM: dts: imx6dl-wandboard: Add SDHC1 and SDHC2 ports
In-Reply-To: <1373633373-3352-1-git-send-email-festevam@gmail.com>
References: <1373633373-3352-1-git-send-email-festevam@gmail.com>
Message-ID: <1373633373-3352-3-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Wandboard has a SD card slot on the baseboard connected to SDHC1 and a
BCM4329 (Wifi + Bluetooth chip) connected to SDHC2.

Add support for these ports.

While at it, provide the card detect gpio on SDHC3 and also fix indentation on 
MX6QDL_PAD_GPIO_0__CCM_CLKO1 hog pin.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v2:
- Rebased against imx-dt tree.
- Separate board changes from SoC changes
- Fix indentation of MX6QDL_PAD_GPIO_0__CCM_CLKO1
Changes since v1:
- Also add the usdhc pinmux groups to mx6q

 arch/arm/boot/dts/imx6dl-wandboard.dts | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts b/arch/arm/boot/dts/imx6dl-wandboard.dts
index fbe0f19..fe9a01d 100644
--- a/arch/arm/boot/dts/imx6dl-wandboard.dts
+++ b/arch/arm/boot/dts/imx6dl-wandboard.dts
@@ -82,7 +82,9 @@
 	hog {
 		pinctrl_hog: hoggrp {
 			fsl,pins = <
-				MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x130b0
+				MX6QDL_PAD_GPIO_0__CCM_CLKO1 	0x130b0
+				MX6QDL_PAD_GPIO_2__GPIO1_IO02	0x80000000
+				MX6QDL_PAD_EIM_DA9__GPIO3_IO09	0x80000000
 			>;
 		};
 	};
@@ -110,8 +112,23 @@
 	status = "okay";
 };
 
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1_2>;
+	cd-gpios = <&gpio1 2 0>;
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2_2>;
+	non-removable;
+	status = "okay";
+};
+
 &usdhc3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usdhc3_2>;
+	cd-gpios = <&gpio3 9 0>;
 	status = "okay";
 };
-- 
1.8.1.2



From festevam at gmail.com  Fri Jul 12 08:49:33 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 12 Jul 2013 09:49:33 -0300
Subject: [PATCH v3 4/4] ARM: dts: imx6dl-wandboard: Add support for UART3
In-Reply-To: <1373633373-3352-1-git-send-email-festevam@gmail.com>
References: <1373633373-3352-1-git-send-email-festevam@gmail.com>
Message-ID: <1373633373-3352-4-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Wandboard has a bluetooth device connected to UART3, so add support for it.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v2:
- Rebased against imx-dt tree.
- Separate board changes from SoC changes
Changes since v1:
- Also add the usdhc pinmux groups to mx6q

 arch/arm/boot/dts/imx6dl-wandboard.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts b/arch/arm/boot/dts/imx6dl-wandboard.dts
index fe9a01d..15014bb 100644
--- a/arch/arm/boot/dts/imx6dl-wandboard.dts
+++ b/arch/arm/boot/dts/imx6dl-wandboard.dts
@@ -108,6 +108,13 @@
 	status = "okay";
 };
 
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart3_2>;
+	fsl,uart-has-rtscts;
+	status = "okay";
+};
+
 &usbh1 {
 	status = "okay";
 };
-- 
1.8.1.2



From marex at denx.de  Fri Jul 12 09:18:31 2013
From: marex at denx.de (Marek Vasut)
Date: Fri, 12 Jul 2013 15:18:31 +0200
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <20130712082642.GB16202@nchen-desktop>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <201307120604.43642.marex@denx.de> <20130712082642.GB16202@nchen-desktop>
Message-ID: <201307121518.31501.marex@denx.de>

Hi Peter,

> On Fri, Jul 12, 2013 at 06:04:43AM +0200, Marek Vasut wrote:
> > Hi Peter,
> > 
> > > On Thu, Jul 11, 2013 at 07:57:19PM +0200, Marek Vasut wrote:
> > > > Hi Peter,
> > > > 
> > > > > This patchset adds tested otg id switch function and
> > > > > vbus connect and disconnect detection for chipidea driver.
> > > > > And fix kinds of bugs found at chipidea drivers after enabling
> > > > > id and vbus detection.
> > > > > 
> > > > > This patch is fully tested at imx6 sabresd platform.
> > > > > My chipidea repo: https://github.com/hzpeterchen/linux-usb.git
> > > > > 
> > > > > Changes for v12:
> > > > > - Rebased greg's usb-next tree (3.10.0-rc7+)
> > > > > - Split more small patches for single function and fix.
> > > > 
> > > > I tested the patchset. Here are the results:
> > > > 
> > > > - VBUS switching
> > > > 
> > > > I'm no longer getting any ID interrupts at all when I apply the patch
> > > > below. The board stays in HOST mode all the time. If I configure it
> > > > as peripheral, it works as peripheral. Note with [1], I was able to
> > > > switch from Peripheral->Host , not the other way around.
> > > 
> > > Thanks for your testing. But first, can you have me check
> > > if your ID wakeup is enabled?
> > 
> > ID wakeup? How do I check?
> 
> See otgsc at controller register, the ID wakeup enable is bit 24.

Yes, ID interrupt (IDIE) is set.

I noticed this backtrace in the kernel bootlog, but this only happens if the 
dr_mode="otg" , it comes from the host-mode irq handler :

[    2.757563] irq 238: nobody cared (try booting with the "irqpoll" option)
[    2.764398] CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-
next-20130711-00013-g011c4b3-dirty #703
[    2.773445] [<80013878>] (unwind_backtrace+0x0/0xe8) from [<80011644>] 
(show_stack+0x10/0x14)
[    2.782027] [<80011644>] (show_stack+0x10/0x14) from [<800659f4>] 
(__report_bad_irq.isra.6+0x20/0xe0)
[    2.791286] [<800659f4>] (__report_bad_irq.isra.6+0x20/0xe0) from 
[<80065c98>] (note_interrupt+0x16c/0x230)
[    2.801063] [<80065c98>] (note_interrupt+0x16c/0x230) from [<80064000>] 
(handle_irq_event_percpu+0x10c/0x1a4)
[    2.811010] [<80064000>] (handle_irq_event_percpu+0x10c/0x1a4) from 
[<800640e8>] (handle_irq_event+0x50/0x78)
[    2.820958] [<800640e8>] (handle_irq_event+0x50/0x78) from [<8006652c>] 
(handle_level_irq+0x88/0x10c)
[    2.830210] [<8006652c>] (handle_level_irq+0x88/0x10c) from [<800638d0>] 
(generic_handle_irq+0x28/0x3c)
[    2.839637] [<800638d0>] (generic_handle_irq+0x28/0x3c) from [<8000f84c>] 
(handle_IRQ+0x30/0x84)
[    2.848461] [<8000f84c>] (handle_IRQ+0x30/0x84) from [<80012160>] 
(__irq_svc+0x40/0x6c)
[    2.856510] [<80012160>] (__irq_svc+0x40/0x6c) from [<80022a44>] 
(__do_softirq+0x90/0x1d8)
[    2.864812] [<80022a44>] (__do_softirq+0x90/0x1d8) from [<80022edc>] 
(irq_exit+0x98/0xd4)
[    2.873025] [<80022edc>] (irq_exit+0x98/0xd4) from [<8000f850>] 
(handle_IRQ+0x34/0x84)
[    2.880980] [<8000f850>] (handle_IRQ+0x34/0x84) from [<80012160>] 
(__irq_svc+0x40/0x6c)
[    2.889020] [<80012160>] (__irq_svc+0x40/0x6c) from [<8001d724>] 
(vprintk_emit+0x1bc/0x524)
[    2.897411] [<8001d724>] (vprintk_emit+0x1bc/0x524) from [<804da5a4>] 
(printk+0x30/0x40)
[    2.905551] [<804da5a4>] (printk+0x30/0x40) from [<80630138>] 
(mousedev_init+0x4c/0x60)
[    2.913617] [<80630138>] (mousedev_init+0x4c/0x60) from [<806178fc>] 
(do_one_initcall+0x94/0x14c)
[    2.922537] [<806178fc>] (do_one_initcall+0x94/0x14c) from [<80617b20>] 
(kernel_init_freeable+0x16c/0x22c)
[    2.932230] [<80617b20>] (kernel_init_freeable+0x16c/0x22c) from [<804d8cbc>] 
(kernel_init+0x8/0x150)
[    2.941486] [<804d8cbc>] (kernel_init+0x8/0x150) from [<8000ea70>] 
(ret_from_fork+0x14/0x24)
[    2.949932] handlers:
[    2.952227] [<8033fc58>] ci_irq
[    2.955388] Disabling IRQ #238

btw. do you have any kind of other CI13xxx documentation than what's in the CPU 
datasheets ?

Best regards,
Marek Vasut


From weiyj.lk at gmail.com  Fri Jul 12 09:20:23 2013
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Fri, 12 Jul 2013 21:20:23 +0800
Subject: [PATCH] video: nuc900fb: fix to pass correct device identity to
 free_irq()
Message-ID: <CAPgLHd_mMOOeMecVJbTQjiK+xJD+-8jvgH6oAFqTHK_uSpWOJw@mail.gmail.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

free_irq() expects the same device identity that was passed to
corresponding request_irq(), otherwise the IRQ is not freed.

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
 drivers/video/nuc900fb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
index 8c527e5..ebd5501 100644
--- a/drivers/video/nuc900fb.c
+++ b/drivers/video/nuc900fb.c
@@ -661,7 +661,7 @@ release_clock:
 	clk_disable(fbi->clk);
 	clk_put(fbi->clk);
 release_irq:
-	free_irq(irq, fbi);
+	free_irq(irq, fbinfo);
 release_regs:
 	iounmap(fbi->io);
 release_mem_region:
@@ -702,7 +702,7 @@ static int nuc900fb_remove(struct platform_device *pdev)
 	iounmap(fbi->io);
 
 	irq = platform_get_irq(pdev, 0);
-	free_irq(irq, fbi);
+	free_irq(irq, fbinfo);
 
 	release_resource(fbi->mem);
 	kfree(fbi->mem);



From mpfj-list at newflow.co.uk  Fri Jul 12 09:57:03 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Fri, 12 Jul 2013 14:57:03 +0100
Subject: [PATCH] remove vlan tags in CPSW dual emac mode
In-Reply-To: <5176C4FE.4080305@ti.com>
References: <4699400.vD3TdgH1nR@localhost> <5176C4FE.4080305@ti.com>
Message-ID: <51E00B2F.6050406@newflow.co.uk>

On 23/04/13 18:29, Mugunthan V N wrote:
> On 4/23/2013 9:48 PM, Markus Brunner wrote:
>> If operating in dual emac mode all packets sent by the CPSW contain vlan headers with the reserved VID 0,
>> which gets stripped away by all somewhat recent Linux versions. Operating systems without that behaviour will fail to communicate.
>> This patch fixes that behaviour by disabling the VLAN_AWARE mode as already described by the comment above.
>>
>> Signed-off-by: Markus Brunner <systemprogrammierung.brunner at gmail.com>
>> Tested-by: Mark Jackson <mpfj at newflow.co.uk>
>>
>> ---
>> --- linux-3.9-rc8.orig/drivers/net/ethernet/ti/cpsw.c    2013-04-23 17:26:11.000000000 +0200
>> +++ linux-3.9-rc8/drivers/net/ethernet/ti/cpsw.c    2013-04-23 17:36:25.000000000 +0200
>> @@ -751,9 +751,9 @@ static void cpsw_init_host_port(struct c
>>       /* switch to vlan unaware mode */
>>       cpsw_ale_control_set(priv->ale, priv->host_port, ALE_VLAN_AWARE,
>>                    CPSW_ALE_VLAN_AWARE);
>>       control_reg = readl(&priv->regs->control);
>> -    control_reg |= CPSW_VLAN_AWARE;
>> +    control_reg &= ~CPSW_VLAN_AWARE;
>>       writel(control_reg, &priv->regs->control);
>>       fifo_mode = (priv->data.dual_emac) ? CPSW_FIFO_DUAL_MAC_MODE :
>>                CPSW_FIFO_NORMAL_MODE;
>>       writel(fifo_mode, &priv->host_port_regs->tx_in_ctl);
> Disabling VLAN aware mode will enable switching mode and the feature of
> separating the two down stream port is lost with this patch
> Please check TRM for more info in *14.3.2.10.2 Dual Mac Mode* chapter

Just to update this (old) thread ...

I can still confirm that *without* the above patch, I am *unable* to use both network
ports on our AM335x board.

My .dts file contains:-

mac: ethernet at 4a100000 {
	dual_emac = <1>;

	cpsw_emac0: slave at 4a100200 {
		dual_emac_res_vlan = <1>;
	};

	cpsw_emac1: slave at 4a100300 {
		dual_emac_res_vlan = <2>;
	};
};

&cpsw_emac0 {
	phy_id = <&davinci_mdio>, <0>;
};

&cpsw_emac1 {
	phy_id = <&davinci_mdio>, <1>;
};

My /etc/network/interfaces file is:-

auto lo eth0 eth1
iface lo inet loopback
iface eth0 inet static
address 10.0.101.3
netmask 255.255.0.0
gateway 10.0.0.1
iface eth1 inet static
address 10.1.101.3
netmask 255.255.0.0

So I'm not sure what's wrong, but it's *definitely* not correct.

Cheers
Mark J.


From nsekhar at ti.com  Fri Jul 12 10:08:26 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 12 Jul 2013 19:38:26 +0530
Subject: [PATCH] ARM: davinci: defconfig: enable EDMA driver
Message-ID: <1373638106-18706-1-git-send-email-nsekhar@ti.com>

Enable EDMA dmaengine driver by default in DaVinci
defconfig files as it is required for DMA support
on MMC/SD, SPI etc.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/configs/da8xx_omapl_defconfig |    2 ++
 arch/arm/configs/davinci_all_defconfig |    2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/arm/configs/da8xx_omapl_defconfig b/arch/arm/configs/da8xx_omapl_defconfig
index 7c86813..1571bea 100644
--- a/arch/arm/configs/da8xx_omapl_defconfig
+++ b/arch/arm/configs/da8xx_omapl_defconfig
@@ -102,6 +102,8 @@ CONFIG_SND_SOC=m
 CONFIG_SND_DAVINCI_SOC=m
 # CONFIG_HID_SUPPORT is not set
 # CONFIG_USB_SUPPORT is not set
+CONFIG_DMADEVICES=y
+CONFIG_TI_EDMA=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 CONFIG_XFS_FS=m
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index c86fd75..ab2f737 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -162,6 +162,8 @@ CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=m
 CONFIG_LEDS_TRIGGER_HEARTBEAT=m
 CONFIG_RTC_CLASS=y
+CONFIG_DMADEVICES=y
+CONFIG_TI_EDMA=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 CONFIG_XFS_FS=m
-- 
1.7.10.1



From swarren at wwwdotorg.org  Fri Jul 12 10:40:07 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 12 Jul 2013 08:40:07 -0600
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <3211864.2dENa1E110@avalon>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1373553468-6564-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <51DEEE15.7040801@wwwdotorg.org> <3211864.2dENa1E110@avalon>
Message-ID: <51E01547.4030204@wwwdotorg.org>

On 07/12/2013 04:41 AM, Laurent Pinchart wrote:
> Hi Stephen,
> 
> On Thursday 11 July 2013 11:40:37 Stephen Warren wrote:
>> On 07/11/2013 08:37 AM, Laurent Pinchart wrote:
>>> Define PWM_POLARITY_NORMAL and PWM_POLARITY_INVERTED macros in
>>> include/dt-bindings/pwm/pwm.h to be used by device tree sources.
>>>
>>>  Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt |  6 +++---
>>>  Documentation/devicetree/bindings/pwm/pwm-samsung.txt   |  5 +++--
>>>  Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt  |  5 +++--
>>>  Documentation/devicetree/bindings/pwm/pwm.txt           |  8 +++++---
>>>  Documentation/devicetree/bindings/pwm/vt8500-pwm.txt    |  5 +++--
>>>  arch/arm/boot/dts/am335x-evm.dts                        |  3 ++-
>>>  arch/arm/boot/dts/am335x-evmsk.dts                      |  3 ++-
>>>  arch/arm/boot/dts/wm8850-w70v2.dts                      |  3 ++-
>>>  include/dt-bindings/pwm/pwm.h                           | 15 ++++++++++++
>>>  include/linux/pwm.h                                     |  4 ++--
>>
>> I think this needs to be separate patches; at least the new pwm.h should
>> be introduced separately to the board-specific *.dts edits, and perhaps
>> further split up?
> 
> What about splitting it in three patches that
> 
> - add the include/dt-bindings/pwm/pwm.h header, and update include/linux/pwm.h 
> and Documentation/devicetree/bindings/pwm/pwm.txt
> 
> - update the rest of the documentation
> 
> - update the .dts files

I think that sounds reasonable.

>> That way, the one patch that introduces <dt-bindings/pwm.h> would be
>> available to be merged into any other tree that wanted to take patches
>> to use the new defines.
>>
>>> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
>>>
>>>  enum pwm_polarity {
>>>
>>> -	PWM_POLARITY_NORMAL,
>>> -	PWM_POLARITY_INVERSED,
>>> +	PWM_POLARITY_NORMAL = 0,
>>> +	PWM_POLARITY_INVERSED = 1,
>>>
>>>  };
>>
>> Rather than manually editing that to ensure the enum matches the DT bindings
>> header, the whole point of making a separate <dt-bindings/...> directory was
>> that drivers could include the binding header files directly to avoid having
>> to duplicate the constant definitions. Can't <linux/pwm.h> include <dt-
>> bindings/pwm.h> and remove that enum?
> 
> We could do that, but we would then need to modify all drivers to replace 
> enum_pwm_polarity with unsigned int. Thierry, what's your opinion on this ?

Or perhaps we could keep the enums around, but force the values to match
the DT constants:

enum pwm_polarity {
	PWM_POLARITY_NORMAL = PWM_POLARITY_NORMAL,
	PWM_POLARITY_INVERTED = PWM_POLARITY_INVERTED,
};

(although obviously you'd need to avoid the enum and DT constants having
the same name).

Although this brings up one point: let's say we support ACPI/.. bindings
in the future. The enum possibly can't match the binding values from
every different kind of binding definition (DT, ACPI, ...) so perhaps
rather than changing the enum definition in <linux/pwm.h>, what we
should be doing is mapping between the different name-spaces in whatever
of_xlate function exists for the PWM flags cell. That would be more
flexible.


From swarren at wwwdotorg.org  Fri Jul 12 10:42:41 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 12 Jul 2013 08:42:41 -0600
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <2172485.AZTjvkLGcM@avalon>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <20130711193245.GB17212@dhcp-172-17-186-34.nvidia.com>
 <51DF1054.9000207@wwwdotorg.org> <2172485.AZTjvkLGcM@avalon>
Message-ID: <51E015E1.2090906@wwwdotorg.org>

On 07/12/2013 05:01 AM, Laurent Pinchart wrote:
> Hi,
> 
> On Thursday 11 July 2013 14:06:44 Stephen Warren wrote:
>> On 07/11/2013 01:32 PM, Thierry Reding wrote:
>>> On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote:
>>>> On 07/11/2013 09:36 AM, Thierry Reding wrote:
>>>>> On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart
>>>>> wrote: [...]
>>>>>
>>>>>> diff --git
>>>>>> a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
>>>>>> b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
>>>>>> index de0eaed..be09be4 100644 ---
>>>>>> a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
>>>>>> +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
>>>>>> @@ -4,9 +4,9 @@ Required properties: - compatible: should be
>>>>>> "atmel,tcb-pwm" - #pwm-cells: Should be 3.  The first cell
>>>>>> specifies the per-chip index of the PWM to use, the second
>>>>>> cell is the period in nanoseconds and -  bit 0 in the third
>>>>>> cell is used to encode the polarity of PWM output. -  Set bit
>>>>>> 0 of the third cell in PWM specifier to 1 for inverse
>>>>>> polarity & -  set to 0 for normal polarity. +  the third cell
>>>>>> is used to encode the polarity of PWM output. Set the +
>>>>>> PWM_POLARITY_NORMAL flag for normal polarity or the
>>>>>> PWM_POLARITY_INVERSED +  flag for inverted polarity. PWM
>>>>>> flags are defined in <dt-bindings/pwm/pwm.h>. - tc-block: The
>>>>>> Timer Counter block to use as a PWM chip.
>>>>>
>>>>>> Example:
>>>>> I'd prefer for the original text to stay in place and the reference to
>>>>> the dt-bindings/pwm/pwm.h file to go below that block.
>>>>
>>>> I disagree here. The whole point of creating header files for the
>>>> constants in binding definitions was so that you wouldn't have to
>>>> duplicate all the values into the binding definitions. Rather, you'd
>>>> simply say "see <dt-bindings/xxx.h>".
>>>
>>> But that's not something that this patch solves.
>>
>> Well, if the comments I made on the patch re: that <linux/pwm.h> should
>> simply #include <dt-bindings/pwm/pwm.h> instead of duplicating the
>> constants, then yet this patch will solve that. There will be a single place
>> where the constants are defined.
> 
> As explained in another reply, this would require replacing the enum with an 
> unsigned int. I can write a patch if we agree on this.
> 
>>> And it could be solved even in the absence of the header file defining the
>>> symbolic constants. If all the standard flags that dt-bindings/pwm/pwm.txt
>>> now specifies were to be listed in pwm.txt (they actually are) then
>>> referring to that document as the canonical source works equally well.
>>
>> If that's all the happens, then there will still be duplication
>> between pwm.txt and <linux/pwm.h>.
> 
> I've explicitly mentioned the flags in individual DT bindings to ease adding 
> new flags in the future. At the moment the defined flags are either all 
> supported or not used at all by drivers. If we later add a new flag supported 
> by a subset of drivers only the driver bindings should list supported flags 
> for each driver.
> 
> I'm fine with removing the explicit mentions of individual flags right now and 
> adding it back when needed if you think that's better.

I think the values for any common system-wide flags should be defined
once in some system-wide place, and the values for any HW-specific
values should be defined only in the documentation for that specific HW.
You could try and avoid conflicts by either:

a) Allocating system-wide flags from bit 0 up, and HW-specific flags
from bit 31 down.

or:

b) Using 1 cell for standard flags, and a separate cell for any
HW-specific flags. Drivers can quite easily adapt to adding extra cells
to #pwm-cells, thus making adding a HW-specific cell later
backwards-compatible.


From robherring2 at gmail.com  Fri Jul 12 10:47:17 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 12 Jul 2013 09:47:17 -0500
Subject: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu
 nodes bindings updates
In-Reply-To: <1368804061-4421-4-git-send-email-lorenzo.pieralisi@arm.com>
References: <1368804061-4421-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1368804061-4421-4-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <CAL_JsqLANi5UoVyRMsa6XoQ+_KnmTQDfTz++shEh-dZ3FQGZaQ@mail.gmail.com>

On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi
<lorenzo.pieralisi at arm.com> wrote:
> In order to extend the current cpu nodes bindings to newer CPUs
> inclusive of AArch64 and to update support for older ARM CPUs this
> patch updates device tree documentation for the cpu nodes bindings.

Sorry for the long delay on this, but I'm still not happy with the binding here.

> Main changes:
>     - adds 64-bit bindings
>     - define usage of #address-cells
>     - define 32/64 dts compatibility settings
>     - defines behaviour on pre and post v7 uniprocessor systems
>     - adds ARM 11MPcore specific reg property definition
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
>  Documentation/devicetree/bindings/arm/cpus.txt | 459 ++++++++++++++++++++++---
>  1 file changed, 412 insertions(+), 47 deletions(-)

[snip]

> +                       # On ARM v8 64-bit systems, where the reg property
> +                         size can be 1 or 2 cells (as defined by cpus node's
> +                         #address-cells property), this property is
> +                         required and matches:
> +
> +                         - On systems running the OS in AArch32:

The DTS cannot change based on 32-bit or 64-bit OS.

> +
> +                           * If the cpus node's #address-cells value is 2:
> +
> +                             The first reg cell must be set to 0.
> +
> +                             The second reg cell bits [23:0] must be set to
> +                             bits [23:0] of MPIDR_EL1.
> +
> +                             All other bits in the reg cells must be set to 0.
> +
> +                           * If the cpus node's #address-cells value is 1:
> +
> +                             Bits [23:0] in the reg cell must be set to
> +                             bits [23:0] in MPIDR_EL1.
> +
> +                             All other bits in the reg cell must be 0.
> +
> +                         - On systems running the OS in AArch64:
> +
> +                           * If the cpus node's #address-cells value is 2:
> +
> +                             The first reg cell bits [7:0] must be set to
> +                             bits [39:32] of MPIDR_EL1.
> +
> +                             The second reg cell bits [23:0] must be set to
> +                             bits [23:0] of MPIDR_EL1.
> +
> +                             All other bits in the reg cells must be set to 0.
> +
> +                           * If the cpus node's #address-cells value is 1:
> +
> +                             MPIDR_EL1[63:32] is 0 on all processors in the
> +                             system.

Your logic is backwards here. If the MPIDR_EL1[63:32] is 0, then
#address-cells can be 1. You could say the upper bits are ignored and
treated as 0. However, you should simplify all this and just mandate
that #address-cells must be 2 for ARMv8 or more generally must match
the size of the MPIDR. If we want to boot a 32-bit kernel, then the
kernel will have to adapt to support this.

> +
> +                             The reg cell bits [23:0] must be set to
> +                             bits [23:0] of MPIDR_EL1.
> +
> +                             All other bits in the reg cell must be set to 0.
> +
> +       - compatible:
> +               Usage: required
> +               Value type: <string>
> +               Definition: should be one of:
> +                           "arm,arm710t"
> +                           "arm,arm720t"
> +                           "arm,arm740t"
> +                           "arm,arm7ej-s"
> +                           "arm,arm7tdmi"
> +                           "arm,arm7tdmi-s"
> +                           "arm,arm9es"
> +                           "arm,arm9ej-s"
> +                           "arm,arm920t"
> +                           "arm,arm922t"
> +                           "arm,arm925"
> +                           "arm,arm926e-s"
> +                           "arm,arm926ej-s"
> +                           "arm,arm940t"
> +                           "arm,arm946e-s"
> +                           "arm,arm966e-s"
> +                           "arm,arm968e-s"
> +                           "arm,arm9tdmi"
> +                           "arm,arm1020e"
> +                           "arm,arm1020t"
> +                           "arm,arm1022e"
> +                           "arm,arm1026ej-s"
> +                           "arm,arm1136j-s"
> +                           "arm,arm1136jf-s"
> +                           "arm,arm1156t2-s"
> +                           "arm,arm1156t2f-s"
> +                           "arm,arm1176jzf"
> +                           "arm,arm1176jz-s"
> +                           "arm,arm1176jzf-s"
> +                           "arm,arm11mpcore"
> +                           "arm,cortex-a5"
> +                           "arm,cortex-a7"
> +                           "arm,cortex-a8"
> +                           "arm,cortex-a9"
> +                           "arm,cortex-a15"
> +                           "arm,cortex-a53"
> +                           "arm,cortex-a57"
> +                           "arm,cortex-m0"
> +                           "arm,cortex-m0+"
> +                           "arm,cortex-m1"
> +                           "arm,cortex-m3"
> +                           "arm,cortex-m4"
> +                           "arm,cortex-r4"
> +                           "arm,cortex-r5"
> +                           "arm,cortex-r7"
> +                           "faraday,fa526"
> +                           "intel,sa110"
> +                           "intel,sa1100"
> +                           "marvell,feroceon"
> +                           "marvell,mohawk"
> +                           "marvell,pj4"
> +                           "marvell,sheeva-v7"
> +                           "marvell,xsc3"
> +                           "marvell,xscale"
> +                           "qcom,krait"
> +                           "qcom,scorpion"
> +       - enable-method
> +               Value type: <stringlist>
> +               Usage and definition depend on ARM architecture version and
> +               configuration:
> +                       # On ARM v8 64-bit systems running the OS in AArch64,

Again, the DTS can't depend on the OS type.

> +                         this property is required and must be one of:
> +                            "spin-table"
> +                            "psci"
> +                       # On ARM 32-bit systems or ARM v8 systems running
> +                         the OS in AArch32 this property is prohibited.

I still don't get the distinction between 32 and 64 bit here. On
32-bit, you have 3 choices: psci, spin-table, or SoC specific. So make
this property optional for 32-bit and mandatory for 64-bit.

> +
> +       - cpu-release-addr
> +               Usage: required for systems that have an "enable-method"
> +                      property value of "spin-table".
> +               Value type: <prop-encoded-array>
> +               Definition:
> +                       # On ARM v8 64-bit systems must be a two cell
> +                         property identifying a 64-bit zero-initialised
> +                         memory location.

As I mentioned previously, isn't some wake-up method needed? Most
systems will be in wfi or wfe rather than continuously spinning.

Rob


From dsd at laptop.org  Fri Jul 12 11:10:49 2013
From: dsd at laptop.org (Daniel Drake)
Date: Fri, 12 Jul 2013 09:10:49 -0600
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <CAN1soZzuiukY9qASFNcH0k=zH8=uT=71bKejPss44FCzNy=X-A@mail.gmail.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <CAN1soZxiOh6TpbUOCUzK8gNwmvjbT3ihkUWaw8tuZ7md+NVA2g@mail.gmail.com>
 <20130710122433.GO11908@titan.lakedaemon.net>
 <CAN1soZzMvront1-jcBW6-uRKNs0OZNGnmiOjKGZSM28bViB_8A@mail.gmail.com>
 <20130710215041.GR11908@titan.lakedaemon.net>
 <CAN1soZzuiukY9qASFNcH0k=zH8=uT=71bKejPss44FCzNy=X-A@mail.gmail.com>
Message-ID: <CAMLZHHQGZvDssY-YxQ3ZW8FYhpG-H1-VbokOid33socRSPrMNw@mail.gmail.com>

On Thu, Jul 11, 2013 at 5:54 PM, Haojian Zhuang
<haojian.zhuang at gmail.com> wrote:
>> Well, Daniel Drake spoke up for OLPC.  Does that count?
>
> We don't know they used DT on Marvell MMP2/MMP3. So they don't have DTS file
> in kernel, we could use both old name & new name in driver.

You are listed as one of the MMP maintainers in the MAINTAINERS file
and I have sent you several patches in the few 3 weeks which make
OLPC's usage of MMP + DT pretty obvious. As a maintainer I believe you
are supposed to review the patches too. hint hint ;)

My request to avoid breaking compatibility actually comes as a
two-prong request.

I would prefer to see these compatible properties stay the same as it
seems like changing them has little purpose/benefit - and there *will*
become a later point where changing them causes major breakage.

At the same time I see that there have been recent efforts to remove
MMP2 platform code and make it entirely DT-driven, which could also
generate some compatibility concerns. However, such movements are much
appreciated and I think they will become increasingly necessary as we
bring up the devices on the MMP3 SoC to a fuller extent, so please
continue :) I would not want to discourage you from breaking
compatibility when *that* type of work needs to be done.


So: breaking compatibility is actually OK from my standpoint, but only
for now (while we stabilise), and I would advise/appreciate that it
only be done in cases where there is a clear purpose and benefit.

Daniel


From balbi at ti.com  Fri Jul 12 11:14:26 2013
From: balbi at ti.com (Felipe Balbi)
Date: Fri, 12 Jul 2013 18:14:26 +0300
Subject: [PATCH] arm: omap5: hwmod: add missing ocp2scp hwmod data
Message-ID: <1373642066-5235-1-git-send-email-balbi@ti.com>

From: Benoit Cousson <benoit.cousson at linaro.org>

without that hwmod data, USB3 will not in OMAP5 boards.

While at that, also fix DTS data to pass reg property,
otherwise driver won't probe.

Signed-off-by: Benoit Cousson <benoit.cousson at linaro.org>
Signed-off-by: Felipe Balbi <balbi at ti.com>
---

tested on OMAP5 uEVM. Gets rid of a data abort when USB3
is enabled. There still some other patches missing to get
USB3 working out of the box, but that's on Palmas and will
come as soon as I get those ready.

This is already on step forward.

 arch/arm/boot/dts/omap5.dtsi               |  3 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45 ++++++++++++++++++++++++++++++
 2 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index da41d70..a0de586 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -654,10 +654,11 @@
 			};
 		};
 
-		ocp2scp {
+		ocp2scp at 4a080000 {
 			compatible = "ti,omap-ocp2scp";
 			#address-cells = <1>;
 			#size-cells = <1>;
+			reg = <0x4a080000 0x20>;
 			ranges;
 			ti,hwmods = "ocp2scp1";
 			usb2_phy: usb2phy at 4a084000 {
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 2435109..d9118a1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1105,6 +1105,42 @@ static struct omap_hwmod omap54xx_mpu_hwmod = {
 };
 
 /*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_ocp2scp_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+			SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_ocp2scp_hwmod_class = {
+	.name	= "ocp2scp",
+	.sysc	= &omap54xx_ocp2scp_sysc,
+};
+
+/* ocp2scp1 */
+static struct omap_hwmod omap54xx_ocp2scp1_hwmod = {
+	.name		= "ocp2scp1",
+	.class		= &omap54xx_ocp2scp_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.main_clk	= "l4_root_clk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L3INIT_OCP2SCP1_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L3INIT_OCP2SCP1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/*
  * 'timer' class
  * general purpose timer module with accurate 1ms tick
  * This class contains several variants: ['timer_1ms', 'timer']
@@ -1900,6 +1936,14 @@ static struct omap_hwmod_ocp_if omap54xx_l4_cfg__mpu = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_cfg -> ocp2scp1 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp1 = {
+	.master		= &omap54xx_l4_cfg_hwmod,
+	.slave		= &omap54xx_ocp2scp1_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_wkup -> timer1 */
 static struct omap_hwmod_ocp_if omap54xx_l4_wkup__timer1 = {
 	.master		= &omap54xx_l4_wkup_hwmod,
@@ -2102,6 +2146,7 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] __initdata = {
 	&omap54xx_l4_per__mmc4,
 	&omap54xx_l4_per__mmc5,
 	&omap54xx_l4_cfg__mpu,
+	&omap54xx_l4_cfg__ocp2scp1,
 	&omap54xx_l4_wkup__timer1,
 	&omap54xx_l4_per__timer2,
 	&omap54xx_l4_per__timer3,
-- 
1.8.2.1



From catalin.marinas at arm.com  Fri Jul 12 11:14:35 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 12 Jul 2013 16:14:35 +0100
Subject: Handling ARM_ERRATA_364296 when CONFIG_SMP=y
In-Reply-To: <CAOMZO5AVpQ6DUja=usBCDzRH0NyNqbXsHNNOJSAY=8OvgHHTmA@mail.gmail.com>
References: <CAOMZO5AVpQ6DUja=usBCDzRH0NyNqbXsHNNOJSAY=8OvgHHTmA@mail.gmail.com>
Message-ID: <20130712151434.GF28271@arm.com>

On Mon, Jul 08, 2013 at 07:16:34PM +0100, Fabio Estevam wrote:
> On commit 145e10e1 (ARM: 7015/1: ARM errata: Possible cache data
> corruption with hit-under-miss enabled) you added support for
> ARM_ERRATA_364296 option:
> 
> +config ARM_ERRATA_364296
> +       bool "ARM errata: Possible cache data corruption with
> hit-under-miss enabled"
> +       depends on CPU_V6 && !SMP
> +       help
> 
> As this erratum affects mx31/mx35, I would like to enable it, but I am
> not allowed to do it because mx31/mx35 share the same config file as
> mx6 (imx_v6_v7_defconfig), which has SMP turned on.
> 
> What would be the correct approach for applying this erratum?
> 
> Is it safe to do "depends on CPU_V6" only or should this erratum be
> handled in the bootloader?

I think you can just remove the !SMP case. The workaround (setting an
undocumented bit) already checks for the right CPU Id. The only problem
issue is that oldconfig will ask whether to enable it or not.

Bootloader would be even better but it's pretty late to enforce this on
ARMv6.

-- 
Catalin


From catalin.marinas at arm.com  Fri Jul 12 11:15:40 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 12 Jul 2013 16:15:40 +0100
Subject: [PATCH] ARM: Kconfig: Let ARM_ERRATA_364296 not depend on
 CONFIG_SMP
In-Reply-To: <1373319489-9467-1-git-send-email-festevam@gmail.com>
References: <1373319489-9467-1-git-send-email-festevam@gmail.com>
Message-ID: <20130712151540.GG28271@arm.com>

On Mon, Jul 08, 2013 at 10:38:09PM +0100, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> imx_v6_v7_defconfig handles both multi-core and single-core SoCs, and it has 
> CONFIG_SMP=y selected by default.
> 
> With such config we cannot select ARM_ERRATA_364296, as it depends on !SMP.
> 
> Let ARM_ERRATA_364296 be undependent on CONFIG_SMP, so that we can select
> this erratum for the ARM1136 SoCs, even if CONFIG_SMP=y is enabled.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

I've just seen the patch (long email backlog).

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From linux at arm.linux.org.uk  Fri Jul 12 11:19:21 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 12 Jul 2013 16:19:21 +0100
Subject: Handling ARM_ERRATA_364296 when CONFIG_SMP=y
In-Reply-To: <20130712151434.GF28271@arm.com>
References: <CAOMZO5AVpQ6DUja=usBCDzRH0NyNqbXsHNNOJSAY=8OvgHHTmA@mail.gmail.com>
 <20130712151434.GF28271@arm.com>
Message-ID: <20130712151921.GF24642@n2100.arm.linux.org.uk>

On Fri, Jul 12, 2013 at 04:14:35PM +0100, Catalin Marinas wrote:
> On Mon, Jul 08, 2013 at 07:16:34PM +0100, Fabio Estevam wrote:
> > On commit 145e10e1 (ARM: 7015/1: ARM errata: Possible cache data
> > corruption with hit-under-miss enabled) you added support for
> > ARM_ERRATA_364296 option:
> > 
> > +config ARM_ERRATA_364296
> > +       bool "ARM errata: Possible cache data corruption with
> > hit-under-miss enabled"
> > +       depends on CPU_V6 && !SMP
> > +       help
> > 
> > As this erratum affects mx31/mx35, I would like to enable it, but I am
> > not allowed to do it because mx31/mx35 share the same config file as
> > mx6 (imx_v6_v7_defconfig), which has SMP turned on.
> > 
> > What would be the correct approach for applying this erratum?
> > 
> > Is it safe to do "depends on CPU_V6" only or should this erratum be
> > handled in the bootloader?
> 
> I think you can just remove the !SMP case. The workaround (setting an
> undocumented bit) already checks for the right CPU Id. The only problem
> issue is that oldconfig will ask whether to enable it or not.

Good thing you don't disagree, because it's already on its way to Linus
as of this morning.


From b.zolnierkie at samsung.com  Fri Jul 12 11:30:33 2013
From: b.zolnierkie at samsung.com (Bartlomiej Zolnierkiewicz)
Date: Fri, 12 Jul 2013 17:30:33 +0200
Subject: [PATCH v7 5/9] iommu/exynos: change rwlock to spinlock
In-Reply-To: <002d01ce797b$49c441a0$dd4cc4e0$@samsung.com>
References: <002d01ce797b$49c441a0$dd4cc4e0$@samsung.com>
Message-ID: <13890783.WKk2X4EVm4@amdc1032>


Hi,

On Friday, July 05, 2013 09:29:26 PM Cho KyongHo wrote:
> Since acquiring read_lock is not more frequent than write_lock, it is
> not beneficial to use rwlock, this commit changes rwlock to spinlock.

This change is not of a "fix type" and is not required to make the driver
work so it would probably be best to move it to the end of a patch series
(IOW just making it the last patch in the series).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> ---
>  drivers/iommu/exynos-iommu.c |   32 ++++++++++++++++----------------
>  1 files changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 390f8b7..6793661 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -175,7 +175,7 @@ struct sysmmu_drvdata {
>  	void __iomem **sfrbases;
>  	struct clk *clk[2];
>  	int activations;
> -	rwlock_t lock;
> +	spinlock_t lock;
>  	struct iommu_domain *domain;
>  	sysmmu_fault_handler_t fault_handler;
>  	unsigned long pgtable;
> @@ -259,7 +259,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
>  	BUG_ON((base0 + size0) <= base0);
>  	BUG_ON((size1 > 0) && ((base1 + size1) <= base1));
>  
> -	read_lock_irqsave(&data->lock, flags);
> +	spin_lock_irqsave(&data->lock, flags);
>  	if (!is_sysmmu_active(data))
>  		goto finish;
>  
> @@ -289,7 +289,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
>  		}
>  	}
>  finish:
> -	read_unlock_irqrestore(&data->lock, flags);
> +	spin_unlock_irqrestore(&data->lock, flags);
>  }
>  
>  static void __set_fault_handler(struct sysmmu_drvdata *data,
> @@ -297,9 +297,9 @@ static void __set_fault_handler(struct sysmmu_drvdata *data,
>  {
>  	unsigned long flags;
>  
> -	write_lock_irqsave(&data->lock, flags);
> +	spin_lock_irqsave(&data->lock, flags);
>  	data->fault_handler = handler;
> -	write_unlock_irqrestore(&data->lock, flags);
> +	spin_unlock_irqrestore(&data->lock, flags);
>  }
>  
>  void exynos_sysmmu_set_fault_handler(struct device *dev,
> @@ -347,7 +347,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
>  
>  	int i, ret = -ENOSYS;
>  
> -	read_lock(&data->lock);
> +	spin_lock(&data->lock);
>  
>  	WARN_ON(!is_sysmmu_active(data));
>  
> @@ -391,7 +391,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
>  	if (itype != SYSMMU_FAULT_UNKNOWN)
>  		sysmmu_unblock(data->sfrbases[i]);
>  
> -	read_unlock(&data->lock);
> +	spin_unlock(&data->lock);
>  
>  	return IRQ_HANDLED;
>  }
> @@ -402,7 +402,7 @@ static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
>  	bool disabled = false;
>  	int i;
>  
> -	write_lock_irqsave(&data->lock, flags);
> +	spin_lock_irqsave(&data->lock, flags);
>  
>  	if (!set_sysmmu_inactive(data))
>  		goto finish;
> @@ -419,7 +419,7 @@ static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
>  	data->pgtable = 0;
>  	data->domain = NULL;
>  finish:
> -	write_unlock_irqrestore(&data->lock, flags);
> +	spin_unlock_irqrestore(&data->lock, flags);
>  
>  	if (disabled)
>  		dev_dbg(data->sysmmu, "(%s) Disabled\n", data->dbgname);
> @@ -442,7 +442,7 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
>  	int i, ret = 0;
>  	unsigned long flags;
>  
> -	write_lock_irqsave(&data->lock, flags);
> +	spin_lock_irqsave(&data->lock, flags);
>  
>  	if (!set_sysmmu_active(data)) {
>  		if (WARN_ON(pgtable != data->pgtable)) {
> @@ -481,7 +481,7 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
>  
>  	dev_dbg(data->sysmmu, "(%s) Enabled\n", data->dbgname);
>  finish:
> -	write_unlock_irqrestore(&data->lock, flags);
> +	spin_unlock_irqrestore(&data->lock, flags);
>  
>  	return ret;
>  }
> @@ -528,7 +528,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
>  	unsigned long flags;
>  	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
>  
> -	read_lock_irqsave(&data->lock, flags);
> +	spin_lock_irqsave(&data->lock, flags);
>  
>  	if (is_sysmmu_active(data)) {
>  		int i;
> @@ -545,7 +545,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
>  			data->dbgname);
>  	}
>  
> -	read_unlock_irqrestore(&data->lock, flags);
> +	spin_unlock_irqrestore(&data->lock, flags);
>  }
>  
>  void exynos_sysmmu_tlb_invalidate(struct device *dev)
> @@ -553,7 +553,7 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
>  	unsigned long flags;
>  	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
>  
> -	read_lock_irqsave(&data->lock, flags);
> +	spin_lock_irqsave(&data->lock, flags);
>  
>  	if (is_sysmmu_active(data)) {
>  		int i;
> @@ -569,7 +569,7 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
>  			data->dbgname);
>  	}
>  
> -	read_unlock_irqrestore(&data->lock, flags);
> +	spin_unlock_irqrestore(&data->lock, flags);
>  }
>  
>  static int exynos_sysmmu_probe(struct platform_device *pdev)
> @@ -666,7 +666,7 @@ static int exynos_sysmmu_probe(struct platform_device *pdev)
>  	}
>  
>  	data->sysmmu = dev;
> -	rwlock_init(&data->lock);
> +	spin_lock_init(&data->lock);
>  	INIT_LIST_HEAD(&data->node);
>  
>  	__set_fault_handler(data, &default_fault_handler);



From grygorii.strashko at ti.com  Fri Jul 12 11:36:30 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Fri, 12 Jul 2013 18:36:30 +0300
Subject: [RFC] ARM: OMAP2+: omap_device: add pinctrl handling
In-Reply-To: <CACRpkdYU13bhPaL2ZG9CT9JRv9sKQ+1N3zCUPizk571+LQqB4A@mail.gmail.com>
References: <1371826990-25820-1-git-send-email-grygorii.strashko@ti.com>
 <CACRpkdY=m1b9Lh27+wHP8FQ4SbVZKmAOCGhxe59aP+TcuR9QaA@mail.gmail.com>
 <20130625065811.GZ5523@atomide.com> <51CAEA90.90200@ti.com>
 <CACRpkdbKgEcfF67oO9HrczvDp4Po3Xt1hFajJ1vO8kEvsZH4jA@mail.gmail.com>
 <51CC45D3.2000305@ti.com>
 <CACRpkdYU13bhPaL2ZG9CT9JRv9sKQ+1N3zCUPizk571+LQqB4A@mail.gmail.com>
Message-ID: <51E0227E.2000008@ti.com>

Hi Linus,

On 07/10/2013 11:36 PM, Linus Walleij wrote:
> On Thu, Jun 27, 2013 at 4:01 PM, Grygorii Strashko
> <grygorii.strashko at ti.com> wrote:
>
>> I think, In the future the OMAP pinctrl configurations would be manged in
>> more flexible way then now (thanks to "pinctrl PM helpers" and you;))
>> - "Idle" state will be splitted to "Idle"/"sleep"
>> - "default" state will be splitted to "default"/"active"
>
> OK so the first ones we already have so the discussion is now down
> to adding the "active" state (and pinctrl_pm* helper function).
>
> I guess we need a patch set prepared which adds the "active" state
> and helper function as the first patch, i.e. this:
> http://marc.info/?l=linux-kernel&m=137094012703340&w=2
> Can I have your ACK on this patch?
I've verified combination of
[PATCH] drivers: pinctrl: add active state to core
[RFC] ARM: OMAP2+: omap_device: add pinctrl handling
on OMAP4 SDP board+UARTs and going to send patches on Monday.

So, Acked/Tested-by: Grygorii Strashko <grygorii.strashko at ti.com>
(I can't reply directly to thread - not signed to those lists :))

What is the best branch to base my patches on?

>
> I do not want to add the state unless there is a clear consumer,
> so it needs to go in with the first patch to a device driver that uses
> pinctrl_pm_select_active_state() which will be a good demonstration
> on its use and utility. (And a point to object and suggest other ways
> to do the same thing...)
>
> Yours,
> Linus Walleij
>

Regards,
-grygorii


From jason at lakedaemon.net  Fri Jul 12 11:57:33 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 12 Jul 2013 11:57:33 -0400
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <CAMLZHHQGZvDssY-YxQ3ZW8FYhpG-H1-VbokOid33socRSPrMNw@mail.gmail.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <CAN1soZxiOh6TpbUOCUzK8gNwmvjbT3ihkUWaw8tuZ7md+NVA2g@mail.gmail.com>
 <20130710122433.GO11908@titan.lakedaemon.net>
 <CAN1soZzMvront1-jcBW6-uRKNs0OZNGnmiOjKGZSM28bViB_8A@mail.gmail.com>
 <20130710215041.GR11908@titan.lakedaemon.net>
 <CAN1soZzuiukY9qASFNcH0k=zH8=uT=71bKejPss44FCzNy=X-A@mail.gmail.com>
 <CAMLZHHQGZvDssY-YxQ3ZW8FYhpG-H1-VbokOid33socRSPrMNw@mail.gmail.com>
Message-ID: <20130712155733.GZ11908@titan.lakedaemon.net>

On Fri, Jul 12, 2013 at 09:10:49AM -0600, Daniel Drake wrote:
> On Thu, Jul 11, 2013 at 5:54 PM, Haojian Zhuang
> <haojian.zhuang at gmail.com> wrote:
> >> Well, Daniel Drake spoke up for OLPC.  Does that count?
> >
> > We don't know they used DT on Marvell MMP2/MMP3. So they don't have DTS file
> > in kernel, we could use both old name & new name in driver.
> 
> You are listed as one of the MMP maintainers in the MAINTAINERS file
> and I have sent you several patches in the few 3 weeks which make
> OLPC's usage of MMP + DT pretty obvious. As a maintainer I believe you
> are supposed to review the patches too. hint hint ;)
> 
> My request to avoid breaking compatibility actually comes as a
> two-prong request.
> 
> I would prefer to see these compatible properties stay the same as it
> seems like changing them has little purpose/benefit - and there *will*
> become a later point where changing them causes major breakage.

I agree with both of you :)  It needs to stabilise quickly, but since
the first inception of Marvell compatible strings was in the mv643xx_eth
driver for powerpc (long before ARM thought it was cool), and they used
"marvell,...", I think we should stick with that.

Which means doing as Haojian now realizes, and having both strings in
the relevant drivers.

This also means we should do a patch for stable v3.5+ appending the
"mrvl,..." string to the drivers that had it removed improperly, as
Daniel discovered.  Daniel, since you are probably most familiar (and
most able to test ;-) ), would you mind putting that patch together?

So we don't have to keep it around forever, we could do as Arnd has
suggested in the past (for an entirely different problem):

	/* assuming it goes in for v3.12 */
	if (WARN_ON(of_device_is_compatible(dev, "mrvl,..."))) {
		dev_info(&dev->dev, "compatible string \"mrvl,...\" being removed in v3.15\n");
		BUG_ON(LINUX_VERSION_CODE >= KERNEL_VERSION(3,15,0));
	}

* I can't find where Arnd's suggestion was, so this hack is completely
my own.

Keep in mind, the above hack is just a suggestion, it makes my skin
crawl just looking at it... I'm open to other ideas.  Or, not doing it
at all.

thx,

Jason.


From dsd at laptop.org  Fri Jul 12 12:05:45 2013
From: dsd at laptop.org (Daniel Drake)
Date: Fri, 12 Jul 2013 10:05:45 -0600
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <20130712155733.GZ11908@titan.lakedaemon.net>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <CAN1soZxiOh6TpbUOCUzK8gNwmvjbT3ihkUWaw8tuZ7md+NVA2g@mail.gmail.com>
 <20130710122433.GO11908@titan.lakedaemon.net>
 <CAN1soZzMvront1-jcBW6-uRKNs0OZNGnmiOjKGZSM28bViB_8A@mail.gmail.com>
 <20130710215041.GR11908@titan.lakedaemon.net>
 <CAN1soZzuiukY9qASFNcH0k=zH8=uT=71bKejPss44FCzNy=X-A@mail.gmail.com>
 <CAMLZHHQGZvDssY-YxQ3ZW8FYhpG-H1-VbokOid33socRSPrMNw@mail.gmail.com>
 <20130712155733.GZ11908@titan.lakedaemon.net>
Message-ID: <CAMLZHHRrrHpSkNbabP9ALKBXemUw07=VmB6kBoD+4u05HQwQ_Q@mail.gmail.com>

On Fri, Jul 12, 2013 at 9:57 AM, Jason Cooper <jason at lakedaemon.net> wrote:
> This also means we should do a patch for stable v3.5+ appending the
> "mrvl,..." string to the drivers that had it removed improperly, as
> Daniel discovered.  Daniel, since you are probably most familiar (and
> most able to test ;-) ), would you mind putting that patch together?

I will look at that. There was another case of a quiet mrvl->marvell
conversion that bit us around a year ago as well, so I will dig that
up too for consideration.

> So we don't have to keep it around forever, we could do as Arnd has
> suggested in the past (for an entirely different problem):
>
>         /* assuming it goes in for v3.12 */
>         if (WARN_ON(of_device_is_compatible(dev, "mrvl,..."))) {
>                 dev_info(&dev->dev, "compatible string \"mrvl,...\" being removed in v3.15\n");
>                 BUG_ON(LINUX_VERSION_CODE >= KERNEL_VERSION(3,15,0));
>         }
>
> * I can't find where Arnd's suggestion was, so this hack is completely
> my own.
>
> Keep in mind, the above hack is just a suggestion, it makes my skin
> crawl just looking at it... I'm open to other ideas.  Or, not doing it
> at all.

A new OpenFirmware or dtb file would want to keep the old mrvl
compatible string around in order to have compatibility with old
kernels. So I think that hack would have to be extended to "if device
is compatible with mrvl, but not marvell, then warn". And that seems
so ugly that my vote would be to avoid it. Especially while we don't
know of existing users who have a requirement of stability.

Daniel


From jason at lakedaemon.net  Fri Jul 12 12:14:23 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 12 Jul 2013 12:14:23 -0400
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <CAMLZHHRrrHpSkNbabP9ALKBXemUw07=VmB6kBoD+4u05HQwQ_Q@mail.gmail.com>
References: <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <CAN1soZxiOh6TpbUOCUzK8gNwmvjbT3ihkUWaw8tuZ7md+NVA2g@mail.gmail.com>
 <20130710122433.GO11908@titan.lakedaemon.net>
 <CAN1soZzMvront1-jcBW6-uRKNs0OZNGnmiOjKGZSM28bViB_8A@mail.gmail.com>
 <20130710215041.GR11908@titan.lakedaemon.net>
 <CAN1soZzuiukY9qASFNcH0k=zH8=uT=71bKejPss44FCzNy=X-A@mail.gmail.com>
 <CAMLZHHQGZvDssY-YxQ3ZW8FYhpG-H1-VbokOid33socRSPrMNw@mail.gmail.com>
 <20130712155733.GZ11908@titan.lakedaemon.net>
 <CAMLZHHRrrHpSkNbabP9ALKBXemUw07=VmB6kBoD+4u05HQwQ_Q@mail.gmail.com>
Message-ID: <20130712161423.GA11908@titan.lakedaemon.net>

On Fri, Jul 12, 2013 at 10:05:45AM -0600, Daniel Drake wrote:
> On Fri, Jul 12, 2013 at 9:57 AM, Jason Cooper <jason at lakedaemon.net> wrote:
> > This also means we should do a patch for stable v3.5+ appending the
> > "mrvl,..." string to the drivers that had it removed improperly, as
> > Daniel discovered.  Daniel, since you are probably most familiar (and
> > most able to test ;-) ), would you mind putting that patch together?
> 
> I will look at that. There was another case of a quiet mrvl->marvell
> conversion that bit us around a year ago as well, so I will dig that
> up too for consideration.

Ok, thanks.

> > So we don't have to keep it around forever, we could do as Arnd has
> > suggested in the past (for an entirely different problem):
> >
> >         /* assuming it goes in for v3.12 */
> >         if (WARN_ON(of_device_is_compatible(dev, "mrvl,..."))) {
> >                 dev_info(&dev->dev, "compatible string \"mrvl,...\" being removed in v3.15\n");
> >                 BUG_ON(LINUX_VERSION_CODE >= KERNEL_VERSION(3,15,0));
> >         }
> >
> > * I can't find where Arnd's suggestion was, so this hack is completely
> > my own.
> >
> > Keep in mind, the above hack is just a suggestion, it makes my skin
> > crawl just looking at it... I'm open to other ideas.  Or, not doing it
> > at all.
> 
> A new OpenFirmware or dtb file would want to keep the old mrvl
> compatible string around in order to have compatibility with old
> kernels. So I think that hack would have to be extended to "if device
> is compatible with mrvl, but not marvell, then warn". And that seems
> so ugly that my vote would be to avoid it. Especially while we don't
> know of existing users who have a requirement of stability.

whew!  Ok, drop that idea.

thx,

Jason.


From balbi at ti.com  Fri Jul 12 12:14:41 2013
From: balbi at ti.com (Felipe Balbi)
Date: Fri, 12 Jul 2013 19:14:41 +0300
Subject: [PATCH] arm: omap5: dts: add palmas-usb node
Message-ID: <1373645681-29779-1-git-send-email-balbi@ti.com>

Without this node, there will be no palmas
driver to notify dwc3 that a cable has
been connected and, without that, dwc3
will never initialize.

Signed-off-by: Felipe Balbi <balbi at ti.com>
---

after this, all we need is wait EXTCON merge
which contains the final changes necessary
to get USB3 working out of the box.

I'd suggest waiting on this patch until EXTCON
reaches mainline, just to make sure we don't
end up with DTS data for devices which don't
exist.

cheers

 arch/arm/boot/dts/omap5-uevm.dts | 9 +++++++++
 arch/arm/boot/dts/omap5.dtsi     | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..7fe0e2b 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -280,6 +280,11 @@
 
 			ti,ldo6-vibrator;
 
+			extcon_usb3: palmas_usb {
+				compatible = "ti,palmas-usb";
+				ti,wakeup;
+			};
+
 			regulators {
 				smps123_reg: smps123 {
 					regulator-name = "smps123";
@@ -450,6 +455,10 @@
 	phys = <0 &hsusb2_phy &hsusb3_phy>;
 };
 
+&usb3 {
+	extcon = <&extcon_usb3>;
+};
+
 &mcspi1 {
 
 };
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 4e41409..1659246 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -634,7 +634,7 @@
 			ti,type = <2>;
 		};
 
-		omap_dwc3 at 4a020000 {
+		usb3: omap_dwc3 at 4a020000 {
 			compatible = "ti,dwc3";
 			ti,hwmods = "usb_otg_ss";
 			reg = <0x4a020000 0x10000>;
-- 
1.8.2.1



From dsd at laptop.org  Fri Jul 12 12:44:28 2013
From: dsd at laptop.org (Daniel Drake)
Date: Fri, 12 Jul 2013 12:44:28 -0400 (EDT)
Subject: DT binding review for Armada display subsystem
Message-ID: <20130712164428.AC3D2FAAE9@dev.laptop.org>

Hi,

Based on the outcomes of the "Best practice device tree design for display
subsystems" discussion I have drafted a DT binding. Comments much appreciated.

At a high level, it uses a "super node" as something for the driver to bind
to, needed because there is no clear one device that controls all the
others, and also to distinguish between the Armada 510 possible use cases
of having one video card with two outputs, or two independent video cards.
It uses node-to-node linking beyond that point, V4L2 style.

I have some questions still:

1. What names does the Armada 510 datasheet give to the components? Below
   I renamed the "LCD controllers" (which don't control LCDs on any of the
   current target hardware) to "display controllers". For what we were
   previously referring to as DCON, I renamed to "output selector". I would
   like to match the docs.

   Actually the output selector is not mentioned as per Sebastian's
   suggestion, but I believe it would fit in the below design once the first
   user comes along (e.g. it would slot in the graph between dcon0 and tda99x).

2. On that topic, what names does the Armada 510 datasheet give to the
   available clocks? Lets make them match the docs.

3. What is the "remote" property in the video interfaces binding? Doesn't
   seem to be documented. But I think I copied its usage style below.





Marvell Armada Display Subsystem

Design considerations
---------------------

The display device that emerges from this subsystem is quite heavily
componentized and the formation of the composite device will vary by SoC and
by board. The DT binding is designed with this flexibility in mind.

For example, there are 2 display controllers on the Armada 510.
They could legitametely be used to form two independent video cards, or
they could be combined into a single video card with two outputs, depending
on board wiring and use case.

As there is no clear component that controls the other components, especially
when we wish to combine the two display controllers into one virtual device, we
define a top-level "super node" that describes the basic composition of the
overall display device. That node uses phandles to define the start of the
graph of display components.

In the bindings for the individual display components, phandle properties
are used to represent direct, fixed links to other components. We use the
port/endpoint abstraction from bindings/media/video-interfaces.txt to
represent these links.


display super node
------------------

Required properties:
 - compatible: "marvell,armada-display"
 - marvell,video-devices : List of phandles to the display controllers that
   form this composite device.

Optional properties;
 - reg: Memory address and size of a RAM allocation designated as graphics
   memory
 - linux,video-memory-size: If reg is not provided, this property defines
   how much memory to cut out of regular available RAM to be used as graphics
   memory.


display-controller node
-----------------------

Required properties:
 - compatible: "marvell,armada-510-display", "marvell,mmp2-display" or
  "marvell,mmp3-display"
 - reg: Register space for this display controller
 - clocks: List of clocks available to this device. From common clock binding.
 - clock-names: Names of the given clocks (see below)
 - ports: From video interface binding

Valid clock names for Armada 510: extclk0 extclk1 axi pll

Valid clock names for MMP2: lcd1 lcd2 axi hdmi

Valid clock names for MMP3: lcd1 lcd2 axi hdmi dsi lvds


Example:

    display {
?? ??   compatible = "marvell,armada-display";
?? ?? ?? reg = <0 0x3f000000 0x1000000>; /* video-mem hole */
?? ?? ?? marvell,video-devices = <&dcon0>;
?? ?? };

    dcon0: display-controller at 20000 {
      compatible = "marvell,armada-510-display-controller";
?? ?? ?? reg = <0x20000 0x1000>;
?? ?? ?? interrupts = <47>;
?? ?? ?? clocks = <&ext_clk0>;
?? ?? ?? clock-names = "extclk0";

      port {
        dcon0_1: endpoint {
          remote = <&tda998x>;
        };
      };
    };

    &i2c0 {
?? ??   tda998x: hdmi-transmitter at 60 {
?? ?? ??   compatible = "nxp,tda19988";
?? ?? ?? ?? reg = <0x60>;
        port {
          tda998x_1: endpoint {
            remote-endpoint = <&dcon0_1>;
          };
        };
?? ?? ?? };
    };


From prabhakar.csengg at gmail.com  Fri Jul 12 12:46:32 2013
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Fri, 12 Jul 2013 22:16:32 +0530
Subject: [PATCH] ARM: davinci: make file local variables static
In-Reply-To: <1373627957-12979-1-git-send-email-nsekhar@ti.com>
References: <1373627957-12979-1-git-send-email-nsekhar@ti.com>
Message-ID: <CA+V-a8tYgtdUp0FwrJ49r0YhnJUt=E=e2-=uCxPhTK=R-uc9bg@mail.gmail.com>

On Fri, Jul 12, 2013 at 4:49 PM, Sekhar Nori <nsekhar at ti.com> wrote:
> Make file local variables static in mach-davinci.
> This fixes sparse warnings of the form:
>
> arch/arm/mach-davinci/dm355.c:863:27: warning: symbol 'dm355_venc_pdata' was not declared. Should it be static?
>
> Cc: Prabhakar Lad <prabhakar.csengg at gmail.com>
> Signed-off-by: Sekhar Nori <nsekhar at ti.com>

Acked-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>

Regards,
--Prabhakar Lad


From thierry.reding at gmail.com  Fri Jul 12 13:24:42 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Fri, 12 Jul 2013 10:24:42 -0700
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <51E01547.4030204@wwwdotorg.org>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1373553468-6564-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <51DEEE15.7040801@wwwdotorg.org> <3211864.2dENa1E110@avalon>
 <51E01547.4030204@wwwdotorg.org>
Message-ID: <20130712172441.GB9620@dhcp-172-17-186-34.nvidia.com>

On Fri, Jul 12, 2013 at 08:40:07AM -0600, Stephen Warren wrote:
> On 07/12/2013 04:41 AM, Laurent Pinchart wrote:
> > Hi Stephen,
[...]
> > What about splitting it in three patches that
> > 
> > - add the include/dt-bindings/pwm/pwm.h header, and update include/linux/pwm.h 
> > and Documentation/devicetree/bindings/pwm/pwm.txt
> > 
> > - update the rest of the documentation
> > 
> > - update the .dts files
> 
> I think that sounds reasonable.

Shouldn't the addition of include/dt-bindings/pwm/pwm.h be separate from
its inclusion in include/linux/pwm.h so that it can be moved more easily
(cherry-picked) to a separate repository?

> >>> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> >>>
> >>>  enum pwm_polarity {
> >>>
> >>> -	PWM_POLARITY_NORMAL,
> >>> -	PWM_POLARITY_INVERSED,
> >>> +	PWM_POLARITY_NORMAL = 0,
> >>> +	PWM_POLARITY_INVERSED = 1,
> >>>
> >>>  };
> >>
> >> Rather than manually editing that to ensure the enum matches the DT bindings
> >> header, the whole point of making a separate <dt-bindings/...> directory was
> >> that drivers could include the binding header files directly to avoid having
> >> to duplicate the constant definitions. Can't <linux/pwm.h> include <dt-
> >> bindings/pwm.h> and remove that enum?
> > 
> > We could do that, but we would then need to modify all drivers to replace 
> > enum_pwm_polarity with unsigned int. Thierry, what's your opinion on this ?
> 
> Or perhaps we could keep the enums around, but force the values to match
> the DT constants:
> 
> enum pwm_polarity {
> 	PWM_POLARITY_NORMAL = PWM_POLARITY_NORMAL,
> 	PWM_POLARITY_INVERTED = PWM_POLARITY_INVERTED,
> };
> 
> (although obviously you'd need to avoid the enum and DT constants having
> the same name).

I think I've seen stuff like the following done in a few header files to
keep compatibility between enums and defines.

	enum foo {
		BAR,
	#define BAR BAR
		BAZ,
	#define BAZ BAZ
	};

Which, as I understand it, won't work in this case because DTC can only
cope with plain cpp files?

> Although this brings up one point: let's say we support ACPI/.. bindings
> in the future. The enum possibly can't match the binding values from
> every different kind of binding definition (DT, ACPI, ...) so perhaps
> rather than changing the enum definition in <linux/pwm.h>, what we
> should be doing is mapping between the different name-spaces in whatever
> of_xlate function exists for the PWM flags cell. That would be more
> flexible.

I'm not quite sure what exactly you are suggesting here. Can you
elaborate?

Thierry
-------------- 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/20130712/6006a484/attachment-0001.sig>

From swarren at wwwdotorg.org  Fri Jul 12 13:40:44 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 12 Jul 2013 11:40:44 -0600
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <20130712172441.GB9620@dhcp-172-17-186-34.nvidia.com>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1373553468-6564-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <51DEEE15.7040801@wwwdotorg.org> <3211864.2dENa1E110@avalon>
 <51E01547.4030204@wwwdotorg.org>
 <20130712172441.GB9620@dhcp-172-17-186-34.nvidia.com>
Message-ID: <51E03F9C.2060903@wwwdotorg.org>

On 07/12/2013 11:24 AM, Thierry Reding wrote:
> On Fri, Jul 12, 2013 at 08:40:07AM -0600, Stephen Warren wrote:
>> On 07/12/2013 04:41 AM, Laurent Pinchart wrote:
>>> Hi Stephen,
> [...]
>>> What about splitting it in three patches that
>>> 
>>> - add the include/dt-bindings/pwm/pwm.h header, and update
>>> include/linux/pwm.h and
>>> Documentation/devicetree/bindings/pwm/pwm.txt
>>> 
>>> - update the rest of the documentation
>>> 
>>> - update the .dts files
>> 
>> I think that sounds reasonable.
> 
> Shouldn't the addition of include/dt-bindings/pwm/pwm.h be separate
> from its inclusion in include/linux/pwm.h so that it can be moved
> more easily (cherry-picked) to a separate repository?

I'm fine with that being another separate patch. However, I doubt
cherry-picking is an issue here; when the separate DT repo is created,
it seems likely that someone will simply copy the latest files from
the latest Linux kernel in order to populate the tree. cherry-picking
probably won't work because:

a) I doubt that the DT binding/header additions have always been kept
separate from kernel code changes in all of Linux's history.

b) I wouldn't be remotely surprised if the layout of the new repo was
entirely different to the kernel source tree layout, so direct
cherry-pick wouldn't work.

c) Not having a common git history would make adding a kernel remote
into the DT repo rather odd.

(b) and (c)  would at leat require some kind of git filter operation
rather than cherry-pick, and this issue could be solve in that filter
definition.

>>>>> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
>>>>> 
>>>>> enum pwm_polarity {
>>>>> 
>>>>> -	PWM_POLARITY_NORMAL, -	PWM_POLARITY_INVERSED, +
>>>>> PWM_POLARITY_NORMAL = 0, +	PWM_POLARITY_INVERSED = 1,
>>>>> 
>>>>> };
>>>> 
>>>> Rather than manually editing that to ensure the enum matches
>>>> the DT bindings header, the whole point of making a separate
>>>> <dt-bindings/...> directory was that drivers could include
>>>> the binding header files directly to avoid having to
>>>> duplicate the constant definitions. Can't <linux/pwm.h>
>>>> include <dt- bindings/pwm.h> and remove that enum?
>>> 
>>> We could do that, but we would then need to modify all drivers
>>> to replace enum_pwm_polarity with unsigned int. Thierry, what's
>>> your opinion on this ?
>> 
>> Or perhaps we could keep the enums around, but force the values
>> to match the DT constants:
>> 
>> enum pwm_polarity { PWM_POLARITY_NORMAL = PWM_POLARITY_NORMAL, 
>> PWM_POLARITY_INVERTED = PWM_POLARITY_INVERTED, };
>> 
>> (although obviously you'd need to avoid the enum and DT constants
>> having the same name).
> 
> I think I've seen stuff like the following done in a few header
> files to keep compatibility between enums and defines.
> 
> enum foo { BAR, #define BAR BAR BAZ, #define BAZ BAZ };
> 
> Which, as I understand it, won't work in this case because DTC can
> only cope with plain cpp files?

Yeah, dtc doesn't understand "enum", so you can't include an enum
definition in a DT file. You have to share simple #define headers
between DT and kernel code.

>> Although this brings up one point: let's say we support ACPI/..
>> bindings in the future. The enum possibly can't match the binding
>> values from every different kind of binding definition (DT, ACPI,
>> ...) so perhaps rather than changing the enum definition in
>> <linux/pwm.h>, what we should be doing is mapping between the
>> different name-spaces in whatever of_xlate function exists for
>> the PWM flags cell. That would be more flexible.
> 
> I'm not quite sure what exactly you are suggesting here. Can you 
> elaborate?

Suppose ACPI (or whatever else) starts representing PWM devices.
Suppose the author isn't aware that DT exists, represents PWM devices
and/or has already defined some PWM-related flags. So, ACPI picks bit
5 in some data value to represent inverted, rather than bit 0. Then,
there is no way that all of [ (a) DT binding PWM flags (b) ACPI PWM
flags (c) Linux's enum foo ] can use the same values. Hence, some
mapping is required between them.

The typical way to do this is to define an "of_xlate" function which
converts from DT cell values to Linux-internal representation.
Presumably if we added an ACPI parser, there'd be some equivalent for
that.

So, what I'm arguing for is that of_pwm_simple_xlate() (or any other
custom xlate function) should include both <dt-bindings/pwm/pwm.h> and
<linux/pwm.h>, and contain explicit code to convert between the two
name-spaces of flags definitions. Since those two name-spaces
currently are 100% identical, presumably if the code is written in the
right way, the compiler will actually just optimize it all away...



From olof at lixom.net  Fri Jul 12 13:57:17 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 12 Jul 2013 10:57:17 -0700
Subject: [GIT PULL] omap fixes for v3.11 merge window
In-Reply-To: <20130710080241.GN5523@atomide.com>
References: <20130710080241.GN5523@atomide.com>
Message-ID: <20130712175717.GA27575@quad.lixom.net>

On Wed, Jul 10, 2013 at 01:02:41AM -0700, Tony Lindgren wrote:
> The following changes since commit ddcf6600b133697adbafd96e080818bdc0dfd028:
> 
>   Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging (2013-07-03 19:56:35 -0700)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/fixes-for-merge-window


Thanks, merged. There was a quite verbose merge conflict due to the changes of
the Kconfig in our fixes branch, so please double-check my resolution.


-Olof


From olof at lixom.net  Fri Jul 12 14:04:20 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 12 Jul 2013 11:04:20 -0700
Subject: [PATCH linux-next] arm: multi_v7_defconfig: add fsl lpuart
 serial console
In-Reply-To: <1373392491-32056-1-git-send-email-vincent.stehle@freescale.com>
References: <1373392491-32056-1-git-send-email-vincent.stehle@freescale.com>
Message-ID: <20130712180420.GA28285@quad.lixom.net>

On Tue, Jul 09, 2013 at 07:54:51PM +0200, Vincent Stehl? wrote:
> Add Freescale LPUART serial console support. This gives us the boot messages on
> UART on e.g. the Vybrid VF610 Tower board.
> 
> Signed-off-by: Vincent Stehl? <vincent.stehle at freescale.com>
> Cc: Olof Johansson <olof at lixom.net>
> Cc: Russell King <linux at arm.linux.org.uk>
> ---
> 
> 
> Hi,
> 
> Would you please consider adding LPUART for ARM multi_v7_defconfig, please?
> 
> (This patch is built on top of the following patches:
> http://comments.gmane.org/gmane.linux.kernel/1519712)
> 
> Best regards,

Thanks, applied to fixes. Note that I squashed together the three patches to
one though.


-Olof


From olof at lixom.net  Fri Jul 12 14:06:35 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 12 Jul 2013 11:06:35 -0700
Subject: [GIT PULL] ux500 defconfig updates
In-Reply-To: <CACRpkdaczQWVv2S48bxRT+0NoMvmjgj5_Tf7cxOC-8xj+TnuTw@mail.gmail.com>
References: <CACRpkdaczQWVv2S48bxRT+0NoMvmjgj5_Tf7cxOC-8xj+TnuTw@mail.gmail.com>
Message-ID: <20130712180635.GB28285@quad.lixom.net>

On Thu, Jul 11, 2013 at 11:05:33AM +0200, Linus Walleij wrote:
> Hi ARM SoC folks,
> 
> these are some defconfig patches that can be pulled in now that all the new
> stuff from various trees has percolated up to Torvalds.
> 
> Please pull them in!
> 
> Yours,
> Linus Walleij
> 
> 
> The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b:
> 
>   Linux 3.10-rc3 (2013-05-26 16:00:47 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
> tags/ux500-defconfig-for-arm-soc

Thanks, pulled.


-Olof


From mugunthanvnm at ti.com  Fri Jul 12 14:35:53 2013
From: mugunthanvnm at ti.com (Mugunthan V N)
Date: Sat, 13 Jul 2013 00:05:53 +0530
Subject: [PATCH] remove vlan tags in CPSW dual emac mode
In-Reply-To: <51E00B2F.6050406@newflow.co.uk>
References: <4699400.vD3TdgH1nR@localhost> <5176C4FE.4080305@ti.com>
 <51E00B2F.6050406@newflow.co.uk>
Message-ID: <51E04C89.8030202@ti.com>

On 7/12/2013 7:27 PM, Mark Jackson wrote:
> On 23/04/13 18:29, Mugunthan V N wrote:
>> On 4/23/2013 9:48 PM, Markus Brunner wrote:
>>> If operating in dual emac mode all packets sent by the CPSW contain vlan headers with the reserved VID 0,
>>> which gets stripped away by all somewhat recent Linux versions. Operating systems without that behaviour will fail to communicate.
>>> This patch fixes that behaviour by disabling the VLAN_AWARE mode as already described by the comment above.
>>>
>>> Signed-off-by: Markus Brunner <systemprogrammierung.brunner at gmail.com>
>>> Tested-by: Mark Jackson <mpfj at newflow.co.uk>
>>>
>>> ---
>>> --- linux-3.9-rc8.orig/drivers/net/ethernet/ti/cpsw.c    2013-04-23 17:26:11.000000000 +0200
>>> +++ linux-3.9-rc8/drivers/net/ethernet/ti/cpsw.c    2013-04-23 17:36:25.000000000 +0200
>>> @@ -751,9 +751,9 @@ static void cpsw_init_host_port(struct c
>>>       /* switch to vlan unaware mode */
>>>       cpsw_ale_control_set(priv->ale, priv->host_port, ALE_VLAN_AWARE,
>>>                    CPSW_ALE_VLAN_AWARE);
>>>       control_reg = readl(&priv->regs->control);
>>> -    control_reg |= CPSW_VLAN_AWARE;
>>> +    control_reg &= ~CPSW_VLAN_AWARE;
>>>       writel(control_reg, &priv->regs->control);
>>>       fifo_mode = (priv->data.dual_emac) ? CPSW_FIFO_DUAL_MAC_MODE :
>>>                CPSW_FIFO_NORMAL_MODE;
>>>       writel(fifo_mode, &priv->host_port_regs->tx_in_ctl);
>> Disabling VLAN aware mode will enable switching mode and the feature of
>> separating the two down stream port is lost with this patch
>> Please check TRM for more info in *14.3.2.10.2 Dual Mac Mode* chapter
> Just to update this (old) thread ...
>
> I can still confirm that *without* the above patch, I am *unable* to use both network
> ports on our AM335x board.
>
> My .dts file contains:-
>
> mac: ethernet at 4a100000 {
> 	dual_emac = <1>;
>
> 	cpsw_emac0: slave at 4a100200 {
> 		dual_emac_res_vlan = <1>;
> 	};
>
> 	cpsw_emac1: slave at 4a100300 {
> 		dual_emac_res_vlan = <2>;
> 	};
> };
>
> &cpsw_emac0 {
> 	phy_id = <&davinci_mdio>, <0>;
> };
>
> &cpsw_emac1 {
> 	phy_id = <&davinci_mdio>, <1>;
> };
>
> My /etc/network/interfaces file is:-
>
> auto lo eth0 eth1
> iface lo inet loopback
> iface eth0 inet static
> address 10.0.101.3
> netmask 255.255.0.0
> gateway 10.0.0.1
> iface eth1 inet static
> address 10.1.101.3
> netmask 255.255.0.0
>
> So I'm not sure what's wrong, but it's *definitely* not correct.
>
>
I am sure that current code in mainline works for Dual EMAC. I can test it
again and share the images with you if are interested. But had tested with DHCP
on both the interfaces.

Regards
Mugunthan V N


From moinejf at free.fr  Fri Jul 12 14:39:52 2013
From: moinejf at free.fr (Jean-Francois Moine)
Date: Fri, 12 Jul 2013 20:39:52 +0200
Subject: DT binding review for Armada display subsystem
In-Reply-To: <20130712164428.AC3D2FAAE9@dev.laptop.org>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
Message-ID: <20130712203952.6b7aa927@armhf>

On Fri, 12 Jul 2013 12:44:28 -0400 (EDT)
Daniel Drake <dsd at laptop.org> wrote:

> Hi,
> 
> Based on the outcomes of the "Best practice device tree design for display
> subsystems" discussion I have drafted a DT binding. Comments much appreciated.
> 
> At a high level, it uses a "super node" as something for the driver to bind
> to, needed because there is no clear one device that controls all the
> others, and also to distinguish between the Armada 510 possible use cases
> of having one video card with two outputs, or two independent video cards.
> It uses node-to-node linking beyond that point, V4L2 style.
> 
> I have some questions still:
> 
> 1. What names does the Armada 510 datasheet give to the components? Below
>    I renamed the "LCD controllers" (which don't control LCDs on any of the
>    current target hardware) to "display controllers". For what we were
>    previously referring to as DCON, I renamed to "output selector". I would
>    like to match the docs.
> 
>    Actually the output selector is not mentioned as per Sebastian's
>    suggestion, but I believe it would fit in the below design once the first
>    user comes along (e.g. it would slot in the graph between dcon0 and tda99x).
> 
> 2. On that topic, what names does the Armada 510 datasheet give to the
>    available clocks? Lets make them match the docs.
> 
> 3. What is the "remote" property in the video interfaces binding? Doesn't
>    seem to be documented. But I think I copied its usage style below.

Hi Daniel,

The Armada 510 spec is:

http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf

> Marvell Armada Display Subsystem
> 
> Design considerations
> ---------------------
> 
> The display device that emerges from this subsystem is quite heavily
> componentized and the formation of the composite device will vary by SoC and
> by board. The DT binding is designed with this flexibility in mind.
> 
> For example, there are 2 display controllers on the Armada 510.
> They could legitametely be used to form two independent video cards, or
> they could be combined into a single video card with two outputs, depending
> on board wiring and use case.
> 
> As there is no clear component that controls the other components, especially
> when we wish to combine the two display controllers into one virtual device, we
> define a top-level "super node" that describes the basic composition of the
> overall display device. That node uses phandles to define the start of the
> graph of display components.
> 
> In the bindings for the individual display components, phandle properties
> are used to represent direct, fixed links to other components. We use the
> port/endpoint abstraction from bindings/media/video-interfaces.txt to
> represent these links.
> 
> 
> display super node
> ------------------
> 
> Required properties:
>  - compatible: "marvell,armada-display"
>  - marvell,video-devices : List of phandles to the display controllers that
>    form this composite device.
> 
> Optional properties;
>  - reg: Memory address and size of a RAM allocation designated as graphics
>    memory
>  - linux,video-memory-size: If reg is not provided, this property defines
>    how much memory to cut out of regular available RAM to be used as graphics
>    memory.
> 
> 
> display-controller node
> -----------------------
> 
> Required properties:
>  - compatible: "marvell,armada-510-display", "marvell,mmp2-display" or
>   "marvell,mmp3-display"
>  - reg: Register space for this display controller
>  - clocks: List of clocks available to this device. From common clock binding.
>  - clock-names: Names of the given clocks (see below)
>  - ports: From video interface binding
> 
> Valid clock names for Armada 510: extclk0 extclk1 axi pll
> 
> Valid clock names for MMP2: lcd1 lcd2 axi hdmi
> 
> Valid clock names for MMP3: lcd1 lcd2 axi hdmi dsi lvds
> 
> 
> Example:
> 
>     display {
> ?? ??   compatible = "marvell,armada-display";
> ?? ?? ?? reg = <0 0x3f000000 0x1000000>; /* video-mem hole */
> ?? ?? ?? marvell,video-devices = <&dcon0>;
> ?? ?? };
> 
>     dcon0: display-controller at 20000 {
>       compatible = "marvell,armada-510-display-controller";
> ?? ?? ?? reg = <0x20000 0x1000>;
> ?? ?? ?? interrupts = <47>;
> ?? ?? ?? clocks = <&ext_clk0>;
> ?? ?? ?? clock-names = "extclk0";
> 
>       port {
>         dcon0_1: endpoint {
>           remote = <&tda998x>;
>         };
>       };
>     };
> 
>     &i2c0 {
> ?? ??   tda998x: hdmi-transmitter at 60 {
> ?? ?? ??   compatible = "nxp,tda19988";
> ?? ?? ?? ?? reg = <0x60>;
>         port {
>           tda998x_1: endpoint {
>             remote-endpoint = <&dcon0_1>;
>           };
>         };
> ?? ?? ?? };
>     };

Some remarks:

- I think it is better to keep the names 'lcd' for the memory to dumb panel
  sub-devices and 'dcon' for the dumb panel to LCD/VGA sub-device, as
  named in the spec.

- the phandles to the clocks does not tell how the clock may be set by
  the driver (it is an array index in the 510).

- I don't see the use of the phandles in the leaves (dcon and tda998x).

Well, here is how I feel the DTs:

- for the Cubox (one LCD, the DCON is not used, TDA998x for HDMI/DVI
  output):

	video {
		compatible = "marvell,armada-video";
		marvell,video-devices = <&lcd0>		/* only one device */
	};

	/* the LCD reg and interrupts are described in dove.dtsi */

	&lcd0 {
		status = "okay";
		clocks = <&core_clk 3>, <&lcdclk>, <&si5351 0>;
		marvell,clock-type = <0>, <2>, <3>;	/* how to set the clock */
		marvell,connector-type = <11>;		/* HDMIA */
		marvell,external-encoder = <&tda998x>;
	};

	&i2c0 {
		si5351: clock-generator {
			...
		};
		tda998x: hdmi-encoder {
			compatible = "nxp,tda998x";
			reg = <0x70>;
			interrupt-parent = <&gpio0>;
			interrupts = <27 2>;		/* falling edge */
		};
	};

- for some tablet based on the Armada 510 with a LCD and a VGA connector:

	video {
		compatible = "marvell,armada-video";
		marvell,video-devices = <&lcd0>, <&lcd1>, <&dcon>
	};

	/* the LCDs reg and interrupts are described in dove.dtsi */

	&lcd0 {						/* LCD */
		status = "okay";
		clocks = <&lcdclk>;			/* only the LCD clock */
		marvell,clock-type = <2>;
		marvell,connector-type = <7>;		/* LVDS */
		display-timings {
			mode {
				hactive = <1920>;
				vactive = <1080>;
				hfront-porch = <88>;
				hsync-len = <44>;
				hback-porch = <148>;
				vfront-porch = <4>;
				vsync-len = <5>;
				vback-porch = <36>;
				clock = <148500>;
			};
		};
	};
	&lcd1 {						/* VGA */
		status = "okay";
		clocks = <&core_clk 3>, <&lcdclk>;	/* only the AXI and LCD clocks */
		marvell,clock-type = <0>, <2>;		/* how to set the clock */
		marvell,port-type = <1>;		/* VGA */
			/* there may be some external encoder to handle DAC */
	};

	/* the DCON reg and interrupts are described in dove.dtsi */

	&dcon { status = "okay"; };

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/


From ppaulina.wilson1 at yahoo.com  Fri Jul 12 14:33:32 2013
From: ppaulina.wilson1 at yahoo.com (paulina Wilson)
Date: Fri, 12 Jul 2013 13:33:32 -0500
Subject: Check out this photo gallery on newsok.com
Message-ID: <201307121833.r6CIXWkc000604@web3.newsok.com>

http://newsok.com/gallery/feedid/544616/50/pictures/2096830


Sorry for contacting you through this medium without a previous notice. Am Miss Paulina,I need your collaboration in a partnership business in your country; I have money to invest under your care as my business manager. Reply for More details.


From ppaulina.wilson1 at yahoo.com  Fri Jul 12 14:30:42 2013
From: ppaulina.wilson1 at yahoo.com (paulina Wilson)
Date: Fri, 12 Jul 2013 13:30:42 -0500
Subject: Check out this photo gallery on newsok.com
Message-ID: <201307121830.r6CIUgxM007158@web2.newsok.com>

http://newsok.com/gallery/feedid/544616/50/pictures/2096830


Sorry for contacting you through this medium without a previous notice. Am Miss Paulina,I need your collaboration in a partnership business in your country; I have money to invest under your care as my business manager. Reply for More details.


From dsd at laptop.org  Fri Jul 12 15:00:23 2013
From: dsd at laptop.org (Daniel Drake)
Date: Fri, 12 Jul 2013 13:00:23 -0600
Subject: DT binding review for Armada display subsystem
In-Reply-To: <20130712203952.6b7aa927@armhf>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <20130712203952.6b7aa927@armhf>
Message-ID: <CAMLZHHT1oAvOLe3JgQqMqLNXEr0NGrdtgELtF_djbqLFceHtiQ@mail.gmail.com>

On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine <moinejf at free.fr> wrote:
> - I think it is better to keep the names 'lcd' for the memory to dumb panel
>   sub-devices and 'dcon' for the dumb panel to LCD/VGA sub-device, as
>   named in the spec.

I agree it is worth keeping the spec-defined names, if they do not
cause excessive confusion when mixed with the spec-defined names for
MMP2/MMP3. I'll check the spec you pointed out, thanks.

> - the phandles to the clocks does not tell how the clock may be set by
>   the driver (it is an array index in the 510).

In the other threads on clock selection, we decided that that exact
information on how to select a clock (i.e. register bits/values) must
be in the driver, not in the DT. What was suggested there is a
well-documented scheme for clock naming, so the driver knows which
clock is which. That is defined in the proposed DT binding though the
"valid clock names" part. For an example driver implementation of this
you can see my patch "armada_drm clock selection - try 2".

> - I don't see the use of the phandles in the leaves (dcon and tda998x).

That is defined by the video interfaces common binding. I'm not
immediately aware of the use, but the ability to easily traverse the
graph in both directions seems like a requirement that could easily
emerge from somewhere.

> Well, here is how I feel the DTs:
>
> - for the Cubox (one LCD, the DCON is not used, TDA998x for HDMI/DVI
>   output):

That is the same as my proposal except you have decided to use direct
phandle properties instead of using the common video interfaces
binding (which is just a slightly more detailed way of describing such
links). In the "best practices" thread, the suggestion was raised
multiple times of doing what v4l2 does, so thats why I decided to
explore this here.

> - for some tablet based on the Armada 510 with a LCD and a VGA connector:
>
>         video {
>                 compatible = "marvell,armada-video";
>                 marvell,video-devices = <&lcd0>, <&lcd1>, <&dcon>
>         };

This proposal is slightly different because it does not describe the
relationship between the LCD controllers and the DCON. Focusing
specifically on LCD1, which would be connected to a DAC via a phandle
property in your proposal. The interconnectivity between the
components represented as a graph (and in the v4l2 way, which includes
my proposal) would be:

LCD1 --- DCON --- DAC

However your phandle properties would "suggest" that LCD1 is directly
connected to the DAC. The driver would have to have special knowledge
that the DCON sits right in the middle. Maybe that is not an issue, as
it is obviously OK for the driver to have *some* knowledge about how
the hardware works :)

I don't think we have a full consensus on whether we want to go the
"v4l2 way" here. But I figured that would be a good thing to propose
in a first iteration to have a clearer idea of what the result would
look like. It sounds like you are not overly keen on it, I would be
interested to hear exactly why.

Thanks,
Daniel


From mpfj-list at newflow.co.uk  Fri Jul 12 15:25:33 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Fri, 12 Jul 2013 20:25:33 +0100
Subject: [PATCH] remove vlan tags in CPSW dual emac mode
In-Reply-To: <51E04C89.8030202@ti.com>
References: <4699400.vD3TdgH1nR@localhost> <5176C4FE.4080305@ti.com>
 <51E00B2F.6050406@newflow.co.uk> <51E04C89.8030202@ti.com>
Message-ID: <51E0582D.4090306@newflow.co.uk>

On 12/07/13 19:35, Mugunthan V N wrote:
> On 7/12/2013 7:27 PM, Mark Jackson wrote:

[snip]

>> Just to update this (old) thread ...
>>
>> I can still confirm that *without* the above patch, I am *unable* to use both network
>> ports on our AM335x board.
>>

[snip]

>>
>> So I'm not sure what's wrong, but it's *definitely* not correct.
>>
>>
> I am sure that current code in mainline works for Dual EMAC. I can test it
> again and share the images with you if are interested. But had tested with DHCP
> on both the interfaces.

Hmmm ... well it's not working for me.  What hardware are you testing it on ?

I tried DHCP to start with, and switched to static IP when that failed.
Then I recalled this patch and re-applied it ... hey presto !!

Markus, are you still using this patch ?



From jic23 at kernel.org  Fri Jul 12 15:42:03 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Fri, 12 Jul 2013 20:42:03 +0100
Subject: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <1373613482-28390-3-git-send-email-oleksandr.kozaruk@ti.com>
References: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1373613482-28390-3-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <51E05C0B.5050009@kernel.org>

On 07/12/2013 08:18 AM, Oleksandr Kozaruk wrote:
> The GPADC is general purpose ADC found on TWL6030,
> and TWL6032 PMIC, known also as Phoenix and PhoenixLite.
>
> The TWL6030 and TWL6032 have GPADC with 17 and 19
> channels respectively. Some channels have current
> source and are used for measuring voltage drop
> on resistive load for detecting battery ID resistance,
> or measuring voltage drop on NTC resistors for external
> temperature measurements. Some channels measure voltage,
> (i.e. battery voltage), and have voltage dividers,
> thus, capable to scale voltage. Some channels are dedicated
> for measuring die temperature.
>
> Some channels are calibrated in 2 points, having
> offsets from ideal values kept in trim registers. This
> is used to correct measurements.
>
> The differences between GPADC in TWL6030 and TWL6032:
> - 10 bit vs 12 bit ADC;
> - 17 vs 19 channels;
> - channels have different purpose(i. e. battery voltage
>   channel 8 vs channel 18);
> - trim values are interpreted differently.
>
> The driver exports function returning converted value for
> requested channels.
>
> Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
> Girish S Ghongdemath.

Couple of things:

1) It looks from the driver that a lot of the channels are not measuring
   voltages but rather temperature or currents etc.  If so then their
   types in the channel mask should be appropriately set.  Also if some
   of the channels are entirely internal test networks, what is the benefit
   of exposing them to userspace as readable channels?
   If channels are merely 'suggested' as being used for temperatures etc
   then it is fine to keep them as voltages.

2) You have my sympathy when it comes to the way those trim values are packed
   into the registers.  That is truely hideous ;)

Various trivial little bits but all in all a nice clean driver. Thanks,

Jonathan
>
> Signed-off-by: Balaji T K <balajitk at ti.com>
> Graeme Gregory <gg at slimlogic.co.uk>
> Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
> ---
>  drivers/iio/adc/Kconfig         |    8 +
>  drivers/iio/adc/Makefile        |    1 +
>  drivers/iio/adc/twl6030-gpadc.c | 1019 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 1028 insertions(+)
>  create mode 100644 drivers/iio/adc/twl6030-gpadc.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index ab0767e6..87d699e 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -157,4 +157,12 @@ config VIPERBOARD_ADC
>  	  Say yes here to access the ADC part of the Nano River
>  	  Technologies Viperboard.
>
> +config TWL6030_GPADC
> +	tristate "TWL6030 GPADC (General Purpose A/D Convertor) Support"
> +	depends on TWL4030_CORE
> +	default n
> +	help
> +	  Say yes here if you want support for the TWL6030 General Purpose
> +	  A/D Convertor.
Perhaps a little more detail for such a complex device?
> +
>  endmenu
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 0a825be..8b05633 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o
>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>  obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
> +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
> diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
> new file mode 100644
> index 0000000..6ceb789
> --- /dev/null
> +++ b/drivers/iio/adc/twl6030-gpadc.c
> @@ -0,0 +1,1019 @@
> +/*
> + * TWL6030 GPADC module driver
> + *
> + * Copyright (C) 2009-2013 Texas Instruments Inc.
> + * Nishant Kamat <nskamat at ti.com>
> + * Balaji T K <balajitk at ti.com>
> + * Graeme Gregory <gg at slimlogic.co.uk>
> + * Girish S Ghongdemath <girishsg at ti.com>
> + * Ambresh K <ambresh at ti.com>
> + * Oleksandr Kozaruk <oleksandr.kozaruk at ti.com
> + *
> + * Based on twl4030-madc.c
> + * Copyright (C) 2008 Nokia Corporation
> + * Mikko Ylinen <mikko.k.ylinen at nokia.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA
> + *
> + */
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of_platform.h>
> +#include <linux/i2c/twl.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +
> +#define DRIVER_NAME		"twl6030_gpadc"
> +
> +#define TWL6030_GPADC_MAX_CHANNELS 17
> +#define TWL6032_GPADC_MAX_CHANNELS 19
> +/* Define this as the biggest of all chips using this driver */
> +#define GPADC_MAX_CHANNELS TWL6032_GPADC_MAX_CHANNELS
> +
> +#define TWL6030_GPADC_CTRL			0x00    /* 0x2e */
> +#define TWL6030_GPADC_CTRL2			0x01	/* 0x2f */
> +
> +#define TWL6030_GPADC_CTRL_P1			0x05
> +#define TWL6030_GPADC_CTRL_P2			0x06
> +
> +#define TWL6032_GPADC_GPSELECT_ISB		0x07
> +#define TWL6032_GPADC_CTRL_P1			0x08
> +
> +#define TWL6032_GPADC_RTCH0_LSB			0x09
> +#define TWL6032_GPADC_RTCH0_MSB			0x0a
> +#define TWL6032_GPADC_RTCH1_LSB			0x0b
> +#define TWL6032_GPADC_RTCH1_MSB			0x0c
> +#define TWL6032_GPADC_GPCH0_LSB			0x0d
> +#define TWL6032_GPADC_GPCH0_MSB			0x0e
> +
> +#define TWL6030_GPADC_CTRL_P1_SP1		BIT(3)
> +#define TWL6030_GPADC_CTRL_P1_EOCRT		BIT(2)
> +#define TWL6030_GPADC_CTRL_P1_EOCP1		BIT(1)
> +#define TWL6030_GPADC_CTRL_P1_BUSY		BIT(0)
> +
> +#define TWL6030_GPADC_CTRL_P2_SP2		BIT(2)
> +#define TWL6030_GPADC_CTRL_P2_EOCP2		BIT(1)
> +#define TWL6030_GPADC_CTRL_P1_BUSY		BIT(0)
> +
> +#define TWL6030_GPADC_EOC_SW			BIT(1)
> +#define TWL6030_GPADC_BUSY			BIT(0)
> +
> +#define TWL6030_GPADC_RTCH0_LSB			(0x07)
> +#define TWL6030_GPADC_GPCH0_LSB			(0x29)
> +
> +/* Fixed channels */
> +#define TWL6030_GPADC_CTRL_TEMP1_EN		BIT(0)    /* input ch 1 */
> +#define TWL6030_GPADC_CTRL_TEMP2_EN		BIT(1)    /* input ch 4 */
> +#define TWL6030_GPADC_CTRL_SCALER_EN		BIT(2)    /* input ch 2 */
> +#define TWL6030_GPADC_CTRL_SCALER_DIV4		BIT(3)
> +#define TWL6030_GPADC_CTRL_SCALER_EN_CH11	BIT(4)    /* input ch 11 */
> +#define TWL6030_GPADC_CTRL_TEMP1_EN_MONITOR	BIT(5)
> +#define TWL6030_GPADC_CTRL_TEMP2_EN_MONITOR	BIT(6)
> +#define TWL6030_GPADC_CTRL_ISOURCE_EN		BIT(7)
> +
> +#define TWL6030_GPADC_CTRL2_REMSENSE_0		BIT(0)
> +#define TWL6030_GPADC_CTRL2_REMSENSE_1		BIT(1)
> +#define TWL6030_GPADC_CTRL2_SCALER_EN_CH18	BIT(2)
> +#define TWL6030_GPADC_CTRL2_VBAT_SCALER_DIV4	BIT(3)
> +
> +#define TWL6030_GPADC_RT_SW1_EOC_MASK		BIT(5)
> +#define TWL6030_GPADC_SW2_EOC_MASK		BIT(6)
> +
> +#define TWL6032_GPADC_RT_EOC_MASK		BIT(4)
> +#define TWL6032_GPADC_SW_EOC_MASK		BIT(5)
> +
> +#define TWL6030_GPADC_TRIM1			0xCD
> +
> +#define TWL6030_REG_TOGGLE1			0x90
> +#define TWL6030_GPADCS				BIT(1)
> +#define TWL6030_GPADCR				BIT(0)
> +
> +/**
> + * struct twl6030_chnl_calib - channel calibration
> + * @gain:		slope coefficient for ideal curve
> + * @gain_error:		gain error
> + * @offset_error:	offset of the real curve
> + */
> +struct twl6030_chnl_calib {
> +	s32 gain;
> +	s32 gain_error;
> +	s32 offset_error;
> +};
> +
> +/**
> + * struct twl6030_ideal_code - GPADC calibration parameters
> + * GPADC is calibrated in two points: close to the beginning and
> + * to the and of the measurable input range
> + *
> + * @code1:	ideal code for the input at the beginning
> + * @code2:	ideal code for at the end of the range
> + * @v1:		voltage input at the beginning(low voltage)
> + * @v2:		voltage input at the end(high voltage)
> + */
> +struct twl6030_ideal_code {
> +	u16 code1;
> +	u16 code2;
> +	u16 v1;
> +	u16 v2;
> +};
> +
> +struct twl6030_gpadc_data;
> +
> +/**
> + * struct twl6030_gpadc_platform_data - platform specific data
> + * @nchannels:		number of GPADC channels
> + * @iio_channels:	iio channels
> + * @twl6030_ideal:	pointer to calibration parameters
> + * @start_conversion:	pointer to ADC start conversion function
> + * @channel_to_reg	pointer to ADC function to convert channel to
> + * 			register address for reading conversion result
> + * @calibrate:		pointer to calibration function
> + */
> +struct twl6030_gpadc_platform_data {
> +	const int nchannels;
> +	const struct iio_chan_spec *iio_channels;
> +	const struct twl6030_ideal_code *ideal;
> +	int (*start_conversion)(int channel);
> +	u8 (*channel_to_reg)(int channel);
> +	int (*calibrate)(struct twl6030_gpadc_data *gpadc);
> +};
> +
> +/**
> + * struct twl6030_gpadc_data - GPADC data
> + * @dev:		device pointer
> + * @lock:		mutual exclusion lock for the structure
> + * @irq_complete:	completion to signal end of conversion
> + * @twl6030_cal_tbl:	pointer to calibration data for each
> + * 			channel with gain error and offset
> + * @pdata:		pointer to device specific data
> + */
> +struct twl6030_gpadc_data {
> +	struct device	*dev;
> +	struct mutex	lock;
> +	struct completion	irq_complete;
> +	struct twl6030_chnl_calib	*twl6030_cal_tbl;
> +	const struct twl6030_gpadc_platform_data *pdata;
> +};
> +
> +/*
> + * channels 11, 12, 13, 15 and 16 have no calibration data
> + * calibration offset is same for channels 1, 3, 4, 5
> + *
> + * The data is taken from GPADC_TRIM registers description.
> + * GPADC_TRIM registers keeps difference between the code measured
> + * at v1 and v2 input voltages and corresponding code1 and code2
> + */
> +static const struct twl6030_ideal_code
> +	twl6030_ideal[TWL6030_GPADC_MAX_CHANNELS] = {
> +	{ /* ch 0, external, battery type, resistor value */
> +		.code1 = 116,
> +		.code2 = 745,
> +		.v1 = 141,
> +		.v2 = 910,
> +	},
> +	{ /* ch 1, external, battery temperature, NTC resistor value */
> +		.code1 = 82,
> +		.code2 = 900,
> +		.v1 = 100,
> +		.v2 = 1100,
> +	},
> +	{ /* ch 2, external, audio accessory/general purpose */
> +		.code1 = 55,
> +		.code2 = 818,
> +		.v1 = 101,
> +		.v2 = 1499,
> +	},
> +	{ /* ch 3, external, general purpose */
> +		.code1 = 82,
> +		.code2 = 900,
> +		.v1 = 100,
> +		.v2 = 1100,
> +	},
> +	{ /* ch 4, external, temperature measurement/general purpose */
> +		.code1 = 82,
> +		.code2 = 900,
> +		.v1 = 100,
> +		.v2 = 1100,
> +	},
> +	{ /* ch 5, external, general purpose */
> +		.code1 = 82,
> +		.code2 = 900,
> +		.v1 = 100,
> +		.v2 = 1100,
> +	},
> +	{ /* ch 6, external, general purpose */
> +		.code1 = 82,
> +		.code2 = 900,
> +		.v1 = 100,
> +		.v2 = 1100,
> +	},
> +	{ /* ch 7, internal, main battery */
> +		.code1 = 614,
> +		.code2 = 941,
> +		.v1 = 3001,
> +		.v2 = 4599,
> +	},
> +	{ /* ch 8, internal, backup battery */
> +		.code1 = 82,
> +		.code2 = 688,
> +		.v1 = 501,
> +		.v2 = 4203,
> +	},
> +	{ /* ch 9, internal, external charger input */
> +		.code1 = 182,
> +		.code2 = 818,
> +		.v1 = 2001,
> +		.v2 = 8996,
> +	},
> +	{ /* ch 10, internal, VBUS */
> +		.code1 = 149,
> +		.code2 = 818,
> +		.v1 = 1001,
> +		.v2 = 5497,
> +	},
> +	{},	/* ch 11, internal, VBUS charging current */
> +	{},	/* ch 12, internal, Die temperature */
> +	{},	/* ch 13, internal, Die temperature */
> +	{ /* ch 14, internal, USB ID line */
> +		.code1 = 48,
> +		.code2 = 714,
> +		.v1 = 323,
> +		.v2 = 4800,
> +	},
> +	{},	/* ch 15, internal, test network */
> +	{},	/* ch 16, internal, test network */
> +};
> +
> +static const struct twl6030_ideal_code
> +			twl6032_ideal[TWL6032_GPADC_MAX_CHANNELS] = {

[0] = {
will make this clearer to read.
> +	{ /* ch 0, external, battery type, resistor value */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 440,
> +		.v2 = 1000,
> +	},
> +	{ /* ch 1, external, battery temperature, NTC resistor value */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 440,
> +		.v2 = 1000,
> +	},
> +	{ /* ch 2, external, audio accessory/general purpose */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 660,
> +		.v2 = 1500,
> +	},
> +	{ /* ch 3, external, temperature with external diode/general purpose */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 440,
> +		.v2 = 1000,
> +	},
> +	{ /* ch 4, external, temperature measurement/general purpose */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 440,
> +		.v2 = 1000,
> +	},
> +	{ /* ch 5, external, general purpose */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 440,
> +		.v2 = 1000,
> +	},
> +	{ /* ch 6, external, general purpose */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 440,
> +		.v2 = 1000,
> +	},
> +	{ /* ch7, internal, system supply */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 2200,
> +		.v2 = 5000,
> +	},
> +	{ /* ch8, internal, backup battery */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 2200,
> +		.v2 = 5000,
> +	},
> +	{ /* ch 9, internal, external charger input */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 3960,
> +		.v2 = 9000,
> +	},
> +	{ /* ch10, internal, VBUS */
> +		.code1 = 150,
> +		.code2 = 751,
> +		.v1 = 1000,
> +		.v2 = 5000,
> +	},
> +	{ /* ch 11, internal, VBUS DC-DC output current */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 660,
> +		.v2 = 1500,
> +	},
> +	{ /* ch 12, internal, Die temperature */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 440,
> +		.v2 = 1000,
> +	},
> +	{ /* ch 13, internal, Die temperature */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 440,
> +		.v2 = 1000,
> +	},
> +	{ /* ch 14, internal, USB ID line */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 2420,
> +		.v2 = 5500,
> +	},
> +	{},	/* ch 15, internal, test network */
> +	{},	/* ch 16, internal, test network */
> +	{},	/* ch 17, internal, battery charging current */
> +	{ /* ch 18, internal, battery voltage */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.v1 = 2200,
> +		.v2 = 5000,
> +	},
> +};
> +
> +static inline int twl6030_gpadc_write(u8 reg, u8 val)
> +{
> +	return twl_i2c_write_u8(TWL6030_MODULE_GPADC, val, reg);
> +}
> +
> +static inline int twl6030_gpadc_read(u8 *val, u8 reg)
> +{
> +
> +	return twl_i2c_read(TWL6030_MODULE_GPADC, val, reg, 2);
> +}
> +
> +static int twl6030_gpadc_enable_irq(u8 mask)
> +{
> +	int ret;
> +
> +	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_LINE_B);
> +	ret |= twl6030_interrupt_unmask(mask, REG_INT_MSK_STS_B);
I'd just roll these into 1 if it makes sense not to check the value
of ret in between.
> +
> +	return ret;
> +}
> +
> +static void twl6030_gpadc_disable_irq(u8 mask)
> +{
> +	twl6030_interrupt_mask(mask, REG_INT_MSK_LINE_B);
> +	twl6030_interrupt_mask(mask, REG_INT_MSK_STS_B);
> +}
> +
> +static irqreturn_t twl6030_gpadc_irq_handler(int irq, void *_gpadc)
> +{
> +	struct twl6030_gpadc_data *gpadc = _gpadc;
> +
> +	complete(&gpadc->irq_complete);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int twl6030_start_conversion(int channel)
> +{
> +	return twl6030_gpadc_write(TWL6030_GPADC_CTRL_P1,
> +					TWL6030_GPADC_CTRL_P1_SP1);
> +}
> +
> +static int twl6032_start_conversion(int channel)
> +{
> +	int ret;
> +
> +	ret = twl6030_gpadc_write(TWL6032_GPADC_GPSELECT_ISB, channel);
> +	if (ret)
> +		return ret;
> +
> +	return twl6030_gpadc_write(TWL6032_GPADC_CTRL_P1,
> +						TWL6030_GPADC_CTRL_P1_SP1);
> +}
> +
> +static u8 twl6030_channel_to_reg(int channel)
> +{
> +	return TWL6030_GPADC_GPCH0_LSB + 2 * channel;
> +}
> +
> +static u8 twl6032_channel_to_reg(int channel)
> +{
> +	return TWL6032_GPADC_GPCH0_LSB;
> +}
> +
> +static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
> +		int channel, int *res)
> +{
> +	u8 reg = gpadc->pdata->channel_to_reg(channel);
> +	u8 val[2];

le16 val;
> +	int ret;
> +
ret = twl6030_gpadc_read(val, reg);
(note that (reg, val) ordering of parameters would be a more common choice)

> +	ret = twl6030_gpadc_read(val, reg);
> +	if (ret) {
> +		dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
> +		return ret;
> +	}
> +
res = le16_to_cpup(val);

> +	*res = (val[1] << 8) | val[0];
> +
> +	return ret;
> +}
> +
> +static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
> +		int channel, int *val)
> +{
> +	int raw_code;
> +	int corrected_code;
> +	int channel_value;
> +	int ret;
> +
> +	ret = twl6030_gpadc_get_raw(gpadc, channel, &raw_code);
> +	if (ret)
> +		return ret;
> +

Might first thought on seeing this is that it would be better to return
raw for all channels and provide the scale and offset info_mask elements
where possible rather than doing the conversion in the kernel.  Note we
allow really quite a bit of precision on those values so I doubt it
will be a problem.

If nothing else it would make everything rather more consistent.


> +	corrected_code = ((raw_code * 1000) -
> +		gpadc->twl6030_cal_tbl[channel].offset_error) /
> +		gpadc->twl6030_cal_tbl[channel].gain_error;
> +
> +	channel_value = corrected_code *
> +			gpadc->twl6030_cal_tbl[channel].gain;
> +
> +	/* Shift back into mV range */
> +	channel_value /= 1000;
> +
> +	dev_dbg(gpadc->dev, "GPADC raw: %d", raw_code);
> +	dev_dbg(gpadc->dev, "GPADC cor: %d", corrected_code);
> +	dev_dbg(gpadc->dev, "GPADC val: %d", channel_value);
> +
> +	*val = channel_value;
> +
> +	return ret;
> +}
> +
> +static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
> +			     const struct iio_chan_spec *chan,
> +			     int *val, int *val2, long mask)
> +{
> +	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
> +	int ret = -EINVAL;
> +
> +	mutex_lock(&gpadc->lock);
> +
> +	ret = gpadc->pdata->start_conversion(chan->channel);
> +	if (ret) {
> +		dev_err(gpadc->dev, "failed to start conversion\n");
> +		goto err;
> +	}
> +	/* wait for conversion to complete */
> +	wait_for_completion_interruptible_timeout(&gpadc->irq_complete,
> +						msecs_to_jiffies(5000));
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
> +		ret = ret ? -EIO : IIO_VAL_INT;
> +		break;
> +
> +	case IIO_CHAN_INFO_PROCESSED:
> +		ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
> +		ret = ret ? -EIO : IIO_VAL_INT;
> +		break;
> +
> +	default:
> +		break;
> +	}
> +err:
> +	mutex_unlock(&gpadc->lock);
> +
> +	return ret;
> +}
> +
> +static void twl6030_calibrate_channel(struct twl6030_gpadc_data *gpadc,
> +					int channel, int d1, int d2)
> +{
> +	int b, k, gain, x1, x2;
> +	const struct twl6030_ideal_code *ideal = gpadc->pdata->ideal;
> +
> +	/* Gain */
> +	gain = ((ideal[channel].v2 - ideal[channel].v1) * 1000) /
> +		(ideal[channel].code2 - ideal[channel].code1);
> +
> +	x1 = ideal[channel].code1;
> +	x2 = ideal[channel].code2;
> +
> +	/* k */
> +	k = 1000 + (((d2 - d1) * 1000) / (x2 - x1));
> +
> +	/* b */
> +	b = (d1 * 1000) - (k - 1000) * x1;
> +
> +	gpadc->twl6030_cal_tbl[channel].gain = gain;
> +	gpadc->twl6030_cal_tbl[channel].gain_error = k;
> +	gpadc->twl6030_cal_tbl[channel].offset_error = b;
> +
> +	dev_dbg(gpadc->dev, "GPADC d1   for Chn: %d = %d\n", channel, d1);
> +	dev_dbg(gpadc->dev, "GPADC d2   for Chn: %d = %d\n", channel, d2);
> +	dev_dbg(gpadc->dev, "GPADC x1   for Chn: %d = %d\n", channel, x1);
> +	dev_dbg(gpadc->dev, "GPADC x2   for Chn: %d = %d\n", channel, x2);
> +	dev_dbg(gpadc->dev, "GPADC Gain for Chn: %d = %d\n", channel, gain);
> +	dev_dbg(gpadc->dev, "GPADC k    for Chn: %d = %d\n", channel, k);
> +	dev_dbg(gpadc->dev, "GPADC b    for Chn: %d = %d\n", channel, b);
> +}
> +
> +static inline int twl6030_gpadc_get_trim_offset(s8 d)
> +{
> +	int sign;
> +
> +	/*
> +	 * XXX NOTE!
> +	 * bit 0 - sign, bit 7 - reserved, 6..1 - trim value
> +	 * though, the documentation states that trim value
> +	 * is absolute value, the correct conversion results are
> +	 * obtained if the value is interpreted as 2's complement.
> +	 */
I'd be tempted to reorder this and then use the sign extend standard
functions.
	temp = ((d & 0x7f) >> 1) | ((d & 1) << 7);
	return sign_extend32(temp, 7);

(or something like that)

> +	sign = d & 1;
> +	d = (d & 0x7f) >> 1;
> +
> +	return sign ? (d | 0xc0) : d;
> +}
> +
> +static int twl6030_calibration(struct twl6030_gpadc_data *gpadc)
> +{
> +	int ret;
> +	int chn;
> +	u8 trim_regs[TWL6030_GPADC_MAX_CHANNELS];
> +	s8 d1, d2;
> +
> +	/*
> +	 * for calibration two measurements have been performed at
> +	 * factory, for some channels, during the production test and
> +	 * have been stored in registers. This two stored values are
> +	 * used to correct the measurements. The values represent
> +	 * offsets for the given input from the output on ideal curve.
> +	 */
> +	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs,
> +			TWL6030_GPADC_TRIM1, 16);
> +	if (ret < 0) {
> +		dev_err(gpadc->dev, "calibration failed\n");
> +		return ret;
> +	}
> +
> +	for (chn = 0; chn < TWL6030_GPADC_MAX_CHANNELS; chn++) {
> +
> +		switch (chn) {
> +		case 0:
> +			d1 = trim_regs[0];
> +			d2 = trim_regs[1];
> +			break;
> +		case 1:
> +			d1 = trim_regs[4];
> +			d2 = trim_regs[5];
> +			break;
> +		case 2:
> +			d1 = trim_regs[12];
> +			d2 = trim_regs[13];
> +			break;
Given you give up entirely on ordering in the next calibration function
I'd be tempted to do the same here and have all the d1 = ...[4] etc in one
case statement.
> +		case 3:
> +		case 4:
> +		case 5:
> +		case 6:
> +			d1 = trim_regs[4];
> +			d2 = trim_regs[5];
> +			break;
> +		case 7:
> +			d1 = trim_regs[6];
> +			d2 = trim_regs[7];
> +			break;
> +		case 8:
> +			d1 = trim_regs[2];
> +			d2 = trim_regs[3];
> +			break;
> +		case 9:
> +			d1 = trim_regs[8];
> +			d2 = trim_regs[9];
> +			break;
> +		case 10:
> +			d1 = trim_regs[10];
> +			d2 = trim_regs[11];
> +			break;
> +		case 14:
> +			d1 = trim_regs[14];
> +			d2 = trim_regs[15];
> +			break;
> +		default:
> +			continue;
> +		}
> +
> +		d1 = twl6030_gpadc_get_trim_offset(d1);
> +		d2 = twl6030_gpadc_get_trim_offset(d2);
> +
> +		twl6030_calibrate_channel(gpadc, chn, d1, d2);
> +	}
> +
> +	return 0;
> +}
> +
> +static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
> +{
> +	int chn, d1 = 0, d2 = 0, temp;
> +	u8 trim_regs[17];
> +	int ret;
> +
> +	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
> +			TWL6030_GPADC_TRIM1, 16);
> +	if (ret < 0) {
> +		dev_err(gpadc->dev, "calibration failed\n");
> +		return ret;
> +	}
> +
/*
 * Loop
please for kernel code.
> +	/* Loop to calculate the value needed for returning voltages from
> +	 * GPADC not values.
> +	 *
> +	 * gain is calculated to 3 decimal places fixed point.
> +	 */
> +	for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
> +
> +		switch (chn) {
> +		case 0:
> +		case 1:
> +		case 2:
> +		case 3:
> +		case 4:
> +		case 5:
> +		case 6:
> +		case 11:
> +		case 12:
> +		case 13:
> +		case 14:
> +			/* D1 */
> +			d1 = (trim_regs[3] & 0x1F) << 2;
> +			d1 |= (trim_regs[1] & 0x06) >> 1;
> +			if (trim_regs[1] & 0x01)
> +				d1 = -d1;
> +
> +			/* D2 */
> +			d2 = (trim_regs[4] & 0x3F) << 2;
> +			d2 |= (trim_regs[2] & 0x06) >> 1;
> +			if (trim_regs[2] & 0x01)
> +				d2 = -d2;
> +			break;
> +		case 8:
No coment on your code, but this is an 'interesting' bit
of bit packing...
I did vaguely wonder if this could be mapped to a big lookup table,
but having tried it I think I end up with something almost as tricky
to read.. Oh well that was a fun 10 minute diversion ;)

> +			/* D1 */
> +			temp = (trim_regs[3] & 0x1F) << 2;
> +			temp |= (trim_regs[1] & 0x06) >> 1;
> +			if (trim_regs[1] & 0x01)
> +				temp = -temp;
> +
> +			d1 = (trim_regs[8] & 0x18) << 1;
> +			d1 |= (trim_regs[7] & 0x1E) >> 1;
> +			if (trim_regs[7] & 0x01)
> +				d1 = -d1;
> +
> +			d1 += temp;
> +
> +			/* D2 */
> +			temp = (trim_regs[4] & 0x3F) << 2;
> +			temp |= (trim_regs[2] & 0x06) >> 1;
> +			if (trim_regs[2] & 0x01)
> +				temp = -temp;
> +
> +			d2 = (trim_regs[10] & 0x1F) << 2;
> +			d2 |= (trim_regs[8] & 0x06) >> 1;
> +			if (trim_regs[8] & 0x01)
> +				d2 = -d2;
> +
> +			d2 += temp;
> +			break;
> +		case 9:
> +			/* D1 */
> +			temp = (trim_regs[3] & 0x1F) << 2;
> +			temp |= (trim_regs[1] & 0x06) >> 1;
> +			if (trim_regs[1] & 0x01)
> +				temp = -temp;
> +
> +			d1 = (trim_regs[14] & 0x18) << 1;
> +			d1 |= (trim_regs[12] & 0x1E) >> 1;
> +			if (trim_regs[12] & 0x01)
> +				d1 = -d1;
> +
> +			d1 += temp;
> +
> +			/* D2 */
> +			temp = (trim_regs[4] & 0x3F) << 2;
> +			temp |= (trim_regs[2] & 0x06) >> 1;
> +			if (trim_regs[2] & 0x01)
> +				temp = -temp;
> +
> +			d2 = (trim_regs[16] & 0x1F) << 2;
> +			d2 |= (trim_regs[14] & 0x06) >> 1;
> +			if (trim_regs[14] & 0x01)
> +				d2 = -d2;
> +
> +			d2 += temp;
> +		case 10:
> +			/* D1 */
> +			d1 = (trim_regs[11] & 0x0F) << 3;
> +			d1 |= (trim_regs[9] & 0x0E) >> 1;
> +			if (trim_regs[9] & 0x01)
> +				d1 = -d1;
> +
> +			/* D2 */
> +			d2 = (trim_regs[15] & 0x0F) << 3;
> +			d2 |= (trim_regs[13] & 0x0E) >> 1;
> +			if (trim_regs[13] & 0x01)
> +				d2 = -d2;
> +			break;
> +		case 7:
> +		case 18:
> +			/* D1 */
> +			temp = (trim_regs[3] & 0x1F) << 2;
> +			temp |= (trim_regs[1] & 0x06) >> 1;
> +			if (trim_regs[1] & 0x01)
> +				temp = -temp;
> +
> +			d1 = (trim_regs[5] & 0x7E) >> 1;
> +			if (trim_regs[5] & 0x01)
> +				d1 = -d1;
> +
> +			d1 += temp;
> +
> +			/* D2 */
> +			temp = (trim_regs[4] & 0x3F) << 2;
> +			temp |= (trim_regs[2] & 0x06) >> 1;
> +			if (trim_regs[2] & 0x01)
> +				temp = -temp;
> +
> +			d2 = (trim_regs[6] & 0xFE) >> 1;
> +			if (trim_regs[6] & 0x01)
> +				d2 = -d2;
> +
> +			d2 += temp;
> +			break;
> +		default:
> +			/* No data for other channels */
> +			continue;
> +		}
> +
> +		twl6030_calibrate_channel(gpadc, chn, d1, d2);
> +	}
> +
> +	return 0;
> +}
> +
> +#define TWL6030_GPADC_CHAN(chn, chan_info) {		\
> +	.type = IIO_VOLTAGE,				\
A lot of the channels appear not to be measuring voltages.
So they should all be appropriately specified.

> +	.channel = chn,					\

Unless you are doing buffered output this stuff is of no interest to
anyone so drop .scan_type from here.

> +	.scan_type = {					\
> +		.sign = 'u',				\
> +		.storagebits = 16,			\
> +	},						\
> +	.info_mask = BIT(chan_info),			\
> +	.info_mask_separate = BIT(chan_info), 		\
> +	.indexed = 1,					\
> +}
> +
> +static const struct iio_chan_spec twl6030_gpadc_iio_channels[] = {
> +	TWL6030_GPADC_CHAN(0, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(1, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(2, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(3, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(4, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(5, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(6, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(7, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(8, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(9, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(10, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(11, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(12, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(13, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(14, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(15, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(16, IIO_CHAN_INFO_RAW),
> +};
> +
> +static const struct iio_chan_spec twl6032_gpadc_iio_channels[] = {
> +	TWL6030_GPADC_CHAN(0, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(1, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(2, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(3, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(4, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(5, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(6, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(7, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(8, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(9, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(10, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(11, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(12, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(13, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(14, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(15, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(16, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(17, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(18, IIO_CHAN_INFO_PROCESSED),
> +};
> +
> +static const struct iio_info twl6030_gpadc_iio_info = {
> +	.read_raw = &twl6030_gpadc_read_raw,
> +	.driver_module = THIS_MODULE,
> +};
> +
> +static const struct twl6030_gpadc_platform_data twl6030_pdata = {
> +	.iio_channels = twl6030_gpadc_iio_channels,
> +	.nchannels = TWL6030_GPADC_MAX_CHANNELS,
> +	.ideal = twl6030_ideal,
> +	.start_conversion = twl6030_start_conversion,
> +	.channel_to_reg = twl6030_channel_to_reg,
> +	.calibrate = twl6030_calibration,
> +};
> +
> +static const struct twl6030_gpadc_platform_data twl6032_pdata = {
> +	.iio_channels = twl6032_gpadc_iio_channels,
> +	.nchannels = TWL6032_GPADC_MAX_CHANNELS,
> +	.ideal = twl6032_ideal,
> +	.start_conversion = twl6032_start_conversion,
> +	.channel_to_reg = twl6032_channel_to_reg,
> +	.calibrate = twl6032_calibration,
> +};
> +
> +static const struct of_device_id of_twl6030_match_tbl[] = {
> +	{
> +		.compatible = "ti,twl6030_gpadc",
> +		.data = &twl6030_pdata,
> +	},
> +	{
> +		.compatible = "ti,twl6032_gpadc",
> +		.data = &twl6032_pdata,
> +	},
> +	{ /* end */ }
> +};
> +
> +static int twl6030_gpadc_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct twl6030_gpadc_data *gpadc;
> +	const struct twl6030_gpadc_platform_data *pdata;
> +	const struct of_device_id *match;
> +	struct iio_dev *indio_dev;
> +	int irq;
> +	int ret = 0;
> +
> +	match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
> +	pdata = match ? match->data : dev->platform_data;
> +
> +	if (!pdata)
> +		return -EINVAL;
> +
> +	indio_dev = iio_device_alloc(sizeof(struct twl6030_gpadc_data));
> +	if (!indio_dev) {
> +		dev_err(dev, "failed allocating iio device\n");
> +		ret = -ENOMEM;
> +	}
> +
> +	gpadc = iio_priv(indio_dev);
> +
> +	gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
> +					sizeof(struct twl6030_chnl_calib) *
> +					pdata->nchannels, GFP_KERNEL);
> +	if (!gpadc->twl6030_cal_tbl)
> +		goto err;
> +
> +	gpadc->dev = dev;
> +	gpadc->pdata = pdata;
> +
> +	platform_set_drvdata(pdev, indio_dev);
> +	mutex_init(&gpadc->lock);
> +	init_completion(&gpadc->irq_complete);
> +
> +	ret = pdata->calibrate(gpadc);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to read calibration registers\n");
> +		goto err;
> +	}
> +
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq < 0) {
> +		dev_err(&pdev->dev, "failed to get irq\n");
> +		goto err;
> +	}
> +
> +	ret = devm_request_threaded_irq(dev, irq, NULL,
> +					twl6030_gpadc_irq_handler,
> +					IRQF_ONESHOT, "twl6030_gpadc", gpadc);
> +	if (ret) {
> +		dev_dbg(&pdev->dev, "could not request irq\n");
> +		goto err;
> +	}
> +
> +	ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
> +		goto err;
> +	}
> +	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
> +					TWL6030_REG_TOGGLE1);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to enable GPADC module\n");
> +		goto err;
> +	}
> +
> +	indio_dev->name = DRIVER_NAME;
> +	indio_dev->dev.parent = dev;
> +	indio_dev->info = &twl6030_gpadc_iio_info;
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->channels = pdata->iio_channels;
> +	indio_dev->num_channels = pdata->nchannels;
> +
> +	ret = iio_device_register(indio_dev);
> +	if (ret)
> +		goto err;
> +
> +	return ret;
> +err:
> +	iio_device_free(indio_dev);
> +	return ret;
> +}
> +
> +static int twl6030_gpadc_remove(struct platform_device *pdev)
> +{
> +	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> +
> +	twl6030_gpadc_disable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
> +	iio_device_unregister(indio_dev);
> +	iio_device_free(indio_dev);
> +
> +	return 0;
> +}
> +
> +static int twl6030_gpadc_suspend(struct device *pdev)
> +{
> +	int ret;
> +
> +	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCR,
> +				TWL6030_REG_TOGGLE1);
> +	if (ret)
> +		dev_err(pdev, "error reseting GPADC (%d)!\n", ret);
> +
> +	return 0;
> +};
> +
> +static int twl6030_gpadc_resume(struct device *pdev)
> +{
> +	int ret;
> +
> +	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
> +				TWL6030_REG_TOGGLE1);
> +	if (ret)
> +		dev_err(pdev, "error setting GPADC (%d)!\n", ret);
> +
> +	return 0;
> +};
> +
> +static const struct dev_pm_ops twl6030_gpadc_pm_ops = {
> +	.suspend = twl6030_gpadc_suspend,
> +	.resume = twl6030_gpadc_resume,
> +};
> +
> +static struct platform_driver twl6030_gpadc_driver = {
> +	.probe		= twl6030_gpadc_probe,
> +	.remove		= twl6030_gpadc_remove,
> +	.driver		= {
> +		.name	= DRIVER_NAME,
> +		.owner	= THIS_MODULE,
> +		.pm	= &twl6030_gpadc_pm_ops,
> +		.of_match_table = of_twl6030_match_tbl,
> +	},
> +};
> +
> +module_platform_driver(twl6030_gpadc_driver);
> +
> +MODULE_ALIAS("platform: " DRIVER_NAME);
> +MODULE_AUTHOR("Texas Instruments Inc.");
> +MODULE_DESCRIPTION("twl6030 ADC driver");
> +MODULE_LICENSE("GPL");
>


From lars at metafoo.de  Fri Jul 12 15:56:28 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Fri, 12 Jul 2013 21:56:28 +0200
Subject: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <1373613482-28390-3-git-send-email-oleksandr.kozaruk@ti.com>
References: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1373613482-28390-3-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <51E05F6C.1060506@metafoo.de>


A couple of comments inline.

On 07/12/2013 09:18 AM, Oleksandr Kozaruk wrote:
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index ab0767e6..87d699e 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -157,4 +157,12 @@ config VIPERBOARD_ADC
>   	  Say yes here to access the ADC part of the Nano River
>   	  Technologies Viperboard.
>
> +config TWL6030_GPADC
> +	tristate "TWL6030 GPADC (General Purpose A/D Convertor) Support"
> +	depends on TWL4030_CORE
> +	default n
> +	help
> +	  Say yes here if you want support for the TWL6030 General Purpose
> +	  A/D Convertor.
> +

Keep it in alphabetical order

>   endmenu
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 0a825be..8b05633 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o
>   obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>   obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>   obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
> +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o

Same here.

> diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
> new file mode 100644
> index 0000000..6ceb789
> --- /dev/null
> +++ b/drivers/iio/adc/twl6030-gpadc.c
> @@ -0,0 +1,1019 @@
[...]
> +static u8 twl6032_channel_to_reg(int channel)
> +{
> +	return TWL6032_GPADC_GPCH0_LSB;

There is more than one channel, isn't there?

[...]
 > +static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
 > +			     const struct iio_chan_spec *chan,
 > +			     int *val, int *val2, long mask)
 > +{
 > +	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
 > +	int ret = -EINVAL;
 > +
 > +	mutex_lock(&gpadc->lock);
 > +
 > +	ret = gpadc->pdata->start_conversion(chan->channel);
 > +	if (ret) {
 > +		dev_err(gpadc->dev, "failed to start conversion\n");
 > +		goto err;
 > +	}
 > +	/* wait for conversion to complete */
 > +	wait_for_completion_interruptible_timeout(&gpadc->irq_complete,
 > +						msecs_to_jiffies(5000));

wait_for_completion_interruptible_timeout() can return either a negative error 
code if it was interrupted, 0 if it timed out, or a positive value if it was 
successfully completed. You need to handle all three cases. Have a look at 
other existing drivers to see how to do this properly.

 > +
 > +	switch (mask) {
 > +	case IIO_CHAN_INFO_RAW:
 > +		ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
 > +		ret = ret ? -EIO : IIO_VAL_INT;
 > +		break;
 > +
 > +	case IIO_CHAN_INFO_PROCESSED:
 > +		ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
 > +		ret = ret ? -EIO : IIO_VAL_INT;
 > +		break;
 > +
 > +	default:
 > +		break;
 > +	}
 > +err:
 > +	mutex_unlock(&gpadc->lock);
 > +
 > +	return ret;
 > +}

> +}
> +
[...]
> +static int twl6030_gpadc_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct twl6030_gpadc_data *gpadc;
> +	const struct twl6030_gpadc_platform_data *pdata;
> +	const struct of_device_id *match;
> +	struct iio_dev *indio_dev;
> +	int irq;
> +	int ret = 0;
> +
> +	match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
> +	pdata = match ? match->data : dev->platform_data;
> +
> +	if (!pdata)
> +		return -EINVAL;
> +
> +	indio_dev = iio_device_alloc(sizeof(struct twl6030_gpadc_data));

sizeof(*gpadc)

> +	if (!indio_dev) {
> +		dev_err(dev, "failed allocating iio device\n");
> +		ret = -ENOMEM;
> +	}
> +
> +	gpadc = iio_priv(indio_dev);
> +
> +	gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
> +					sizeof(struct twl6030_chnl_calib) *
> +					pdata->nchannels, GFP_KERNEL);
> +	if (!gpadc->twl6030_cal_tbl)
> +		goto err;
> +
> +	gpadc->dev = dev;
> +	gpadc->pdata = pdata;
> +
> +	platform_set_drvdata(pdev, indio_dev);
> +	mutex_init(&gpadc->lock);
> +	init_completion(&gpadc->irq_complete);
> +
> +	ret = pdata->calibrate(gpadc);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to read calibration registers\n");
> +		goto err;
> +	}
> +
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq < 0) {
> +		dev_err(&pdev->dev, "failed to get irq\n");
> +		goto err;
> +	}
> +
> +	ret = devm_request_threaded_irq(dev, irq, NULL,
> +					twl6030_gpadc_irq_handler,
> +					IRQF_ONESHOT, "twl6030_gpadc", gpadc);

You access memory in the interrupt handler which is freed before the interrupt 
handler is freed.

> +	if (ret) {
> +		dev_dbg(&pdev->dev, "could not request irq\n");
> +		goto err;
> +	}
> +
> +	ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
> +		goto err;
> +	}
> +	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
> +					TWL6030_REG_TOGGLE1);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to enable GPADC module\n");
> +		goto err;
> +	}
> +
> +	indio_dev->name = DRIVER_NAME;
> +	indio_dev->dev.parent = dev;
> +	indio_dev->info = &twl6030_gpadc_iio_info;
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->channels = pdata->iio_channels;
> +	indio_dev->num_channels = pdata->nchannels;
> +
> +	ret = iio_device_register(indio_dev);
> +	if (ret)
> +		goto err;
> +
> +	return ret;
> +err:
> +	iio_device_free(indio_dev);
> +	return ret;
> +}
> +
[...]
> +static int twl6030_gpadc_suspend(struct device *pdev)
> +{
> +	int ret;
> +
> +	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCR,
> +				TWL6030_REG_TOGGLE1);
> +	if (ret)
> +		dev_err(pdev, "error reseting GPADC (%d)!\n", ret);
> +
> +	return 0;
> +};
> +
> +static int twl6030_gpadc_resume(struct device *pdev)
> +{
> +	int ret;
> +
> +	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
> +				TWL6030_REG_TOGGLE1);
> +	if (ret)
> +		dev_err(pdev, "error setting GPADC (%d)!\n", ret);
> +
> +	return 0;
> +};
> +
> +static const struct dev_pm_ops twl6030_gpadc_pm_ops = {
> +	.suspend = twl6030_gpadc_suspend,
> +	.resume = twl6030_gpadc_resume,
> +};

SIMPLE_DEV_PM_OPS?

[...]


From swarren at wwwdotorg.org  Fri Jul 12 15:58:35 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 12 Jul 2013 13:58:35 -0600
Subject: Sharing *.dtsi between Linux architectures?
Message-ID: <51E05FEB.1090308@wwwdotorg.org>

Is there a (possibly just proposed) mechanism in place to allow *.dts
from multiple Linux architectures to share common *.dtsi files?

As an example, consider two SoCs that are identical except for the CPU
complex. One uses an ARMv7 CPU (DTs in arch/arm/boot/dts/) and the other
uses some ARMv8 CPU (DTs in arch/am64/boot/dts/). It'd be useful to
define all the SoC components in some common .dtsi file to avoid
duplication, and have both arch/arm/boot/dts/tegraXXX.dtsi and
arch/arm64/boot/dts/tegraYYY.dtsi include that and add the relevant
CPU-related nodes.

I could imagine creating one of the following paths for this purpose:

arch/common/dts/
include/dt-common/
include/dtsi/

... or perhaps re-using the existing:

include/dt-bindings/

... although my original intent for that last location was just to house
header files that define constants that are part of binding definitions,
rather than actual structural content.


From robherring2 at gmail.com  Fri Jul 12 16:17:57 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 12 Jul 2013 15:17:57 -0500
Subject: Sharing *.dtsi between Linux architectures?
In-Reply-To: <51E05FEB.1090308@wwwdotorg.org>
References: <51E05FEB.1090308@wwwdotorg.org>
Message-ID: <51E06475.6010006@gmail.com>

On 07/12/2013 02:58 PM, Stephen Warren wrote:
> Is there a (possibly just proposed) mechanism in place to allow *.dts
> from multiple Linux architectures to share common *.dtsi files?

Nothing proposed yet. There was some discussion at Connect (which I
missed part of). We're certainly going to start to have that issue
between arm and arm64 as well as probably FSL powerpc and arm.

I would like to move all dts files out of arch. I think we should think
about how we construct a separate dts repository and then move the
kernel structure in that direction (it's still believed there is too
much interdependency to have separate repo yet). I don't think cpu
architecture is the right top level structure for dts files. Probably
something by vendor and/or SOC family is more appropriate. Then you have
to figure out how to handle board vs. chip vendors.

> As an example, consider two SoCs that are identical except for the CPU
> complex. One uses an ARMv7 CPU (DTs in arch/arm/boot/dts/) and the other
> uses some ARMv8 CPU (DTs in arch/am64/boot/dts/). It'd be useful to
> define all the SoC components in some common .dtsi file to avoid
> duplication, and have both arch/arm/boot/dts/tegraXXX.dtsi and
> arch/arm64/boot/dts/tegraYYY.dtsi include that and add the relevant
> CPU-related nodes.
> 
> I could imagine creating one of the following paths for this purpose:
> 
> arch/common/dts/
> include/dt-common/
> include/dtsi/
> 
> ... or perhaps re-using the existing:
> 
> include/dt-bindings/
> 
> ... although my original intent for that last location was just to house
> header files that define constants that are part of binding definitions,
> rather than actual structural content.

I think we should stick with defines there.

Rob



From plagnioj at jcrosoft.com  Fri Jul 12 16:23:36 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sat, 13 Jul 2013 04:23:36 +0800
Subject: Sharing *.dtsi between Linux architectures?
In-Reply-To: <51E06475.6010006@gmail.com>
References: <51E05FEB.1090308@wwwdotorg.org> <51E06475.6010006@gmail.com>
Message-ID: <0A6B2945-FE3B-4CF9-BB4B-0ED9126D5A27@jcrosoft.com>


On Jul 13, 2013, at 4:17 AM, Rob Herring <robherring2 at gmail.com> wrote:

> On 07/12/2013 02:58 PM, Stephen Warren wrote:
>> Is there a (possibly just proposed) mechanism in place to allow *.dts
>> from multiple Linux architectures to share common *.dtsi files?
> 
> Nothing proposed yet. There was some discussion at Connect (which I
> missed part of). We're certainly going to start to have that issue
> between arm and arm64 as well as probably FSL powerpc and arm.
> 
> I would like to move all dts files out of arch. I think we should think
> about how we construct a separate dts repository and then move the
> kernel structure in that direction (it's still believed there is too
> much interdependency to have separate repo yet). I don't think cpu
> architecture is the right top level structure for dts files. Probably
> something by vendor and/or SOC family is more appropriate. Then you have
> to figure out how to handle board vs. chip vendors.
> 
>> As an example, consider two SoCs that are identical except for the CPU
>> complex. One uses an ARMv7 CPU (DTs in arch/arm/boot/dts/) and the other
>> uses some ARMv8 CPU (DTs in arch/am64/boot/dts/). It'd be useful to
>> define all the SoC components in some common .dtsi file to avoid
>> duplication, and have both arch/arm/boot/dts/tegraXXX.dtsi and
>> arch/arm64/boot/dts/tegraYYY.dtsi include that and add the relevant
>> CPU-related nodes.
>> 
>> I could imagine creating one of the following paths for this purpose:
>> 
>> arch/common/dts/
>> include/dt-common/
>> include/dtsi/
>> 
>> ... or perhaps re-using the existing:
>> 
>> include/dt-bindings/
>> 
>> ... although my original intent for that last location was just to house
>> header files that define constants that are part of binding definitions,
>> rather than actual structural content.
> 
> I think we should stick with defines there.

I think it's to do it how move the dt simple in dt directory at the root of
the kernel tree

this will simplify the move to out of tree

and include/dt-bindings/ to dt/include/dt-bindings/ and just handle the include
via a -i in the Makefile

Best Regards,
J.
> 
> Rob
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From sergei.shtylyov at cogentembedded.com  Fri Jul 12 16:40:48 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Jul 2013 00:40:48 +0400
Subject: [v6 1/3] ARM: dtsi: enable ahci sata on imx6q platforms
In-Reply-To: <1373622078-18723-2-git-send-email-Hong-Xing.Zhu@freescale.com>
References: <1373622078-18723-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373622078-18723-2-git-send-email-Hong-Xing.Zhu@freescale.com>
Message-ID: <51E069D0.7030204@cogentembedded.com>

On 07/12/2013 01:41 PM, Richard Zhu wrote:

> From: Richard Zhu <r65037 at freescale.com>

> Only imx6q has the ahci sata controller, enable
> it on imx6q platforms.

> Signed-off-by: Richard Zhu <r65037 at freescale.com>
[...]

> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index e7dd2c4..93b65d9 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -424,6 +424,15 @@
>   			};
>   		};
>
> +		ahci: ahci at 02200000 {

    According to ePAPR [1] section 2.2.2, "the name of the node should 
be somewhat generic, reflecting the function of the device and not its
precise programming model. If appropriate, the name should be one of the 
following choices:
[...]
- sata;
[...]"

[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei



From santosh.shilimkar at ti.com  Fri Jul 12 17:48:10 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 12 Jul 2013 17:48:10 -0400
Subject: [RFC/RFT PATCH 1/5] block: Rename parameter dma_mask to max_addr for
 blk_queue_bounce_limit()
In-Reply-To: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1373665694-7580-2-git-send-email-santosh.shilimkar@ti.com>

The blk_queue_bounce_limit() API parameter 'dma_mask' is actually the
maximum address the device can handle rather than a dma_mask. Rename
it accordingly to avoid it being interpreted as dma_mask.

No functional change.

The idea is to fix the bad assumptions about dma_mask wherever it could
be miss-interpreted.

Cc: Russell King <rmk at arm.linux.org.uk>
Cc: Jens Axboe <axboe at kernel.dk>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 block/blk-settings.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index c50ecf0..026c151 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -195,17 +195,17 @@ EXPORT_SYMBOL(blk_queue_make_request);
 /**
  * blk_queue_bounce_limit - set bounce buffer limit for queue
  * @q: the request queue for the device
- * @dma_mask: the maximum address the device can handle
+ * @max_addr: the maximum address the device can handle
  *
  * Description:
  *    Different hardware can have different requirements as to what pages
  *    it can do I/O directly to. A low level driver can call
  *    blk_queue_bounce_limit to have lower memory pages allocated as bounce
- *    buffers for doing I/O to pages residing above @dma_mask.
+ *    buffers for doing I/O to pages residing above @max_addr.
  **/
-void blk_queue_bounce_limit(struct request_queue *q, u64 dma_mask)
+void blk_queue_bounce_limit(struct request_queue *q, u64 max_addr)
 {
-	unsigned long b_pfn = dma_mask >> PAGE_SHIFT;
+	unsigned long b_pfn = max_addr >> PAGE_SHIFT;
 	int dma = 0;
 
 	q->bounce_gfp = GFP_NOIO;
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Fri Jul 12 17:48:12 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 12 Jul 2013 17:48:12 -0400
Subject: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for
 bounce_limit calculations
In-Reply-To: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1373665694-7580-4-git-send-email-santosh.shilimkar@ti.com>

DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: linux-scsi at vger.kernel.org

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 drivers/scsi/scsi_lib.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 86d5220..e8275fa 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
 
 	host_dev = scsi_get_device(shost);
 	if (host_dev && host_dev->dma_mask)
-		bounce_limit = *host_dev->dma_mask;
+		bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;
 
 	return bounce_limit;
 }
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Fri Jul 12 17:48:11 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 12 Jul 2013 17:48:11 -0400
Subject: [RFC/RFT PATCH 2/5] mm: dma-mapping: Add dma_max_pfn(dev) helper
 function
In-Reply-To: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1373665694-7580-3-git-send-email-santosh.shilimkar@ti.com>

Most of the kernel assumes that PFN0 is the start of the physical
memory (RAM). This assumptions is not true on most of the ARM SOCs
and hence and if one try to update the ARM port to follow the assumptions,
we end of breaking the dma bounce limit for few block layer drivers.
One such example is trying to unify the meaning of max*_pfn on ARM
as the bootmem layer expects, breaks few block layer driver dma
bounce limit.

To fix this problem, we introduce dma_max_pfn(dev) generic helper with
a possibility of override from the architecture code. The helper converts
a DMA bitmask of bits to a block PFN number. In all the generic cases,
it is just  "dev->dma_mask >> PAGE_SHIFT" and hence default behavior
is maintained as is.

Subsequent patches will make use of the helper. No functional change.

Cc: Russell King <rmk at arm.linux.org.uk>
Cc: Jens Axboe <axboe at kernel.dk>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 include/linux/dma-mapping.h |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 94af418..68a7863 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -129,6 +129,13 @@ static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask)
 		return -EIO;
 }
 
+#ifndef dma_max_pfn
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+	return *dev->dma_mask >> PAGE_SHIFT;
+}
+#endif
+
 static inline void *dma_zalloc_coherent(struct device *dev, size_t size,
 					dma_addr_t *dma_handle, gfp_t flag)
 {
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Fri Jul 12 17:48:13 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 12 Jul 2013 17:48:13 -0400
Subject: [RFC/RFT PATCH 4/5] ARM: mm: change max*pfn to include the physical
 offset of memory
In-Reply-To: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1373665694-7580-5-git-send-email-santosh.shilimkar@ti.com>

Most of the kernel code assumes that max*pfn is maximum pfns because
the physical start of memory is expected to be PFN0. Since this
assumption is not true on ARM architectures, the meaning of max*pfn
is number of memory pages. This is done to keep drivers happy which
are making use of of these variable to calculate the dma bounce limit
using dma_mask.

Now since we have a architecture override possibility for DMAable
maximum pfns, lets make meaning of max*pfns as maximum pnfs on ARM
as well.

In the patch, the dma_to_pfn/pfn_to_dma() pair is hacked to take care of
the physical memory offset. It is done this way just to enable testing
since its understood that it can come in way of single zImage.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Nicolas Pitre <nicolas.pitre at linaro.org>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/include/asm/dma-mapping.h |   16 ++++++++++++----
 arch/arm/mm/init.c                 |   10 ++++------
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 5b579b9..b2d5937 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -47,12 +47,12 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
 #ifndef __arch_pfn_to_dma
 static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
 {
-	return (dma_addr_t)__pfn_to_bus(pfn);
+	return (dma_addr_t)__pfn_to_bus(pfn + PHYS_PFN_OFFSET);
 }
 
 static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
 {
-	return __bus_to_pfn(addr);
+	return __bus_to_pfn(addr) - PHYS_PFN_OFFSET;
 }
 
 static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
@@ -64,15 +64,16 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
 {
 	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
 }
+
 #else
 static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
 {
-	return __arch_pfn_to_dma(dev, pfn);
+	return __arch_pfn_to_dma(dev, pfn + PHYS_PFN_OFFSET);
 }
 
 static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
 {
-	return __arch_dma_to_pfn(dev, addr);
+	return __arch_dma_to_pfn(dev, addr) - PHYS_PFN_OFFSET;
 }
 
 static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
@@ -86,6 +87,13 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
 }
 #endif
 
+/* The ARM override for dma_max_pfn() */
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+	return dma_to_pfn(dev, *dev->dma_mask);
+}
+#define dma_max_pfn(dev) dma_max_pfn(dev)
+
 /*
  * DMA errors are defined by all-bits-set in the DMA address.
  */
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 6833cbe..588a2c1 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -420,12 +420,10 @@ void __init bootmem_init(void)
 	 * This doesn't seem to be used by the Linux memory manager any
 	 * more, but is used by ll_rw_block.  If we can get rid of it, we
 	 * also get rid of some of the stuff above as well.
-	 *
-	 * Note: max_low_pfn and max_pfn reflect the number of _pages_ in
-	 * the system, not the maximum PFN.
 	 */
-	max_low_pfn = max_low - PHYS_PFN_OFFSET;
-	max_pfn = max_high - PHYS_PFN_OFFSET;
+	min_low_pfn = min;
+	max_low_pfn = max_low;
+	max_pfn = max_high;
 }
 
 /*
@@ -531,7 +529,7 @@ static inline void free_area_high(unsigned long pfn, unsigned long end)
 static void __init free_highpages(void)
 {
 #ifdef CONFIG_HIGHMEM
-	unsigned long max_low = max_low_pfn + PHYS_PFN_OFFSET;
+	unsigned long max_low = max_low_pfn;
 	struct memblock_region *mem, *res;
 
 	/* set highmem page free */
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Fri Jul 12 17:48:09 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 12 Jul 2013 17:48:09 -0400
Subject: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes
Message-ID: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>

The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
PFNs but that breaks the dma_mask for few block layer drivers since
ARM start of physical memory is not PFN0 unlike most of the architectures.
Some more read on it is here:
	http://lwn.net/Articles/543408/
	http://lwn.net/Articles/543424/

To address this issue, we introduce generic dma_max_pfn() helper which
can be overridden from the architectures.
	
Another intention behind move to nobootmem is also to convert ARM to
switch to memblock and getting rid of bootmem allocator dependency which
don't work for LPAE machines which has physical memory starting beyond
4 GB boundary. It needs changes to core kernel and also a new memblock
API. More on this can be found here:
	https://lkml.org/lkml/2013/6/29/77

I have been trying to cook up these patches with kind help from Russell
and we know series don't solve all the dma_mask bad assumptions. But at
least I am hoping that it can get the ball rolling.	

Comments/testing help is welcome !!

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Nicolas Pitre <nicolas.pitre at linaro.org>
Cc: Tejun Heo <tj at kernel.org>
Cc: Jens Axboe <axboe at kernel.dk>

Santosh Shilimkar (5):
  block: Rename parameter dma_mask to max_addr for
    blk_queue_bounce_limit()
  mm: dma-mapping: Add dma_max_pfn(dev) helper function
  scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations
  ARM: mm: change max*pfn to include the physical offset of memory
  ARM: mm: Remove bootmem code and switch to NO_BOOTMEM

 arch/arm/Kconfig                   |    1 +
 arch/arm/include/asm/dma-mapping.h |   16 ++++++---
 arch/arm/kernel/setup.c            |    2 +-
 arch/arm/mm/init.c                 |   68 ++++--------------------------------
 block/blk-settings.c               |    8 ++---
 drivers/scsi/scsi_lib.c            |    2 +-
 include/linux/dma-mapping.h        |    7 ++++
 7 files changed, 32 insertions(+), 72 deletions(-)

-- 
1.7.9.5



From santosh.shilimkar at ti.com  Fri Jul 12 17:48:14 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 12 Jul 2013 17:48:14 -0400
Subject: [RFC/RFT PATCH 5/5] ARM: mm: Remove bootmem code and switch to
 NO_BOOTMEM
In-Reply-To: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1373665694-7580-6-git-send-email-santosh.shilimkar@ti.com>

In the effort of using memblock instead of bootmem allocator, ARM arch
needs to be converted to use NO_BOOTMEM. With NO_BOOTMEM change,
now we use memblock allocator to reserve space for crash kernel to
have one less dependency with nobootmem allocator wrapper.

Hopefully the NO_BOOTMEM memblock wrapper(nobootmem.c) will vanish in
near future and archs can directly use memblock APIs. Ongoing thread
on this topic is here:
https://lkml.org/lkml/2013/6/29/77

Boot tested with both flat memory and sparse (faked) memory models
with highmem enabled. LAPE systems with memory starting > 4GB still
won't work but this is one of the step to solve that problem for ARM.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Nicolas Pitre <nicolas.pitre at linaro.org>
Cc: Tejun Heo <tj at kernel.org>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/Kconfig        |    1 +
 arch/arm/kernel/setup.c |    2 +-
 arch/arm/mm/init.c      |   58 ++---------------------------------------------
 3 files changed, 4 insertions(+), 57 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0ac9be6..cff9a59 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -63,6 +63,7 @@ config ARM
 	select OLD_SIGSUSPEND3
 	select OLD_SIGACTION
 	select HAVE_CONTEXT_TRACKING
+	select NO_BOOTMEM
 	help
 	  The ARM series is a line of low-power-consumption RISC chip designs
 	  licensed by ARM Ltd and targeted at embedded applications and
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 63af9a7..2ca4b90 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -805,7 +805,7 @@ static void __init reserve_crashkernel(void)
 	if (ret)
 		return;
 
-	ret = reserve_bootmem(crash_base, crash_size, BOOTMEM_EXCLUSIVE);
+	ret = memblock_reserve(crash_base, crash_size);
 	if (ret < 0) {
 		printk(KERN_WARNING "crashkernel reservation failed - "
 		       "memory is in use (0x%lx)\n", (unsigned long)crash_base);
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 588a2c1..84dd56c 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -153,58 +153,6 @@ static void __init find_limits(unsigned long *min, unsigned long *max_low,
 	*max_high = bank_pfn_end(&mi->bank[mi->nr_banks - 1]);
 }
 
-static void __init arm_bootmem_init(unsigned long start_pfn,
-	unsigned long end_pfn)
-{
-	struct memblock_region *reg;
-	unsigned int boot_pages;
-	phys_addr_t bitmap;
-	pg_data_t *pgdat;
-
-	/*
-	 * Allocate the bootmem bitmap page.  This must be in a region
-	 * of memory which has already been mapped.
-	 */
-	boot_pages = bootmem_bootmap_pages(end_pfn - start_pfn);
-	bitmap = memblock_alloc_base(boot_pages << PAGE_SHIFT, L1_CACHE_BYTES,
-				__pfn_to_phys(end_pfn));
-
-	/*
-	 * Initialise the bootmem allocator, handing the
-	 * memory banks over to bootmem.
-	 */
-	node_set_online(0);
-	pgdat = NODE_DATA(0);
-	init_bootmem_node(pgdat, __phys_to_pfn(bitmap), start_pfn, end_pfn);
-
-	/* Free the lowmem regions from memblock into bootmem. */
-	for_each_memblock(memory, reg) {
-		unsigned long start = memblock_region_memory_base_pfn(reg);
-		unsigned long end = memblock_region_memory_end_pfn(reg);
-
-		if (end >= end_pfn)
-			end = end_pfn;
-		if (start >= end)
-			break;
-
-		free_bootmem(__pfn_to_phys(start), (end - start) << PAGE_SHIFT);
-	}
-
-	/* Reserve the lowmem memblock reserved regions in bootmem. */
-	for_each_memblock(reserved, reg) {
-		unsigned long start = memblock_region_reserved_base_pfn(reg);
-		unsigned long end = memblock_region_reserved_end_pfn(reg);
-
-		if (end >= end_pfn)
-			end = end_pfn;
-		if (start >= end)
-			break;
-
-		reserve_bootmem(__pfn_to_phys(start),
-			        (end - start) << PAGE_SHIFT, BOOTMEM_DEFAULT);
-	}
-}
-
 #ifdef CONFIG_ZONE_DMA
 
 unsigned long arm_dma_zone_size __read_mostly;
@@ -242,7 +190,7 @@ void __init setup_dma_zone(struct machine_desc *mdesc)
 #endif
 }
 
-static void __init arm_bootmem_free(unsigned long min, unsigned long max_low,
+static void __init zone_sizes_init(unsigned long min, unsigned long max_low,
 	unsigned long max_high)
 {
 	unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES];
@@ -396,8 +344,6 @@ void __init bootmem_init(void)
 
 	find_limits(&min, &max_low, &max_high);
 
-	arm_bootmem_init(min, max_low);
-
 	/*
 	 * Sparsemem tries to allocate bootmem in memory_present(),
 	 * so must be done after the fixed reservations
@@ -414,7 +360,7 @@ void __init bootmem_init(void)
 	 * the sparse mem_map arrays initialized by sparse_init()
 	 * for memmap_init_zone(), otherwise all PFNs are invalid.
 	 */
-	arm_bootmem_free(min, max_low, max_high);
+	zone_sizes_init(min, max_low, max_high);
 
 	/*
 	 * This doesn't seem to be used by the Linux memory manager any
-- 
1.7.9.5



From sergei.shtylyov at cogentembedded.com  Fri Jul 12 17:55:58 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Jul 2013 01:55:58 +0400
Subject: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for
 bounce_limit calculations
In-Reply-To: <1373665694-7580-4-git-send-email-santosh.shilimkar@ti.com>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
 <1373665694-7580-4-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <51E07B6E.5090900@cogentembedded.com>

Hello.

On 07/13/2013 01:48 AM, Santosh Shilimkar wrote:

> DMA bounce limit is the maximum direct DMA'able memory beyond which
> bounce buffers has to be used to perform dma operations. SCSI driver
> relies on dma_mask but its calculation is based on max_*pfn which
> don't have uniform meaning across architectures. So make use of
> dma_max_pfn() which is expected to return the DMAable maximum pfn
> value across architectures.

> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: linux-scsi at vger.kernel.org

> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>   drivers/scsi/scsi_lib.c |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 86d5220..e8275fa 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
>
>   	host_dev = scsi_get_device(shost);
>   	if (host_dev && host_dev->dma_mask)
> -		bounce_limit = *host_dev->dma_mask;
> +		bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;

    You definitely forgot -1 here.

WBR, Sergei



From linux at arm.linux.org.uk  Fri Jul 12 18:25:06 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 12 Jul 2013 23:25:06 +0100
Subject: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for
 bounce_limit calculations
In-Reply-To: <51E07B6E.5090900@cogentembedded.com>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
 <1373665694-7580-4-git-send-email-santosh.shilimkar@ti.com>
 <51E07B6E.5090900@cogentembedded.com>
Message-ID: <20130712222506.GI24642@n2100.arm.linux.org.uk>

On Sat, Jul 13, 2013 at 01:55:58AM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 07/13/2013 01:48 AM, Santosh Shilimkar wrote:
>
>> DMA bounce limit is the maximum direct DMA'able memory beyond which
>> bounce buffers has to be used to perform dma operations. SCSI driver
>> relies on dma_mask but its calculation is based on max_*pfn which
>> don't have uniform meaning across architectures. So make use of
>> dma_max_pfn() which is expected to return the DMAable maximum pfn
>> value across architectures.
>
>> Cc: Russell King <linux at arm.linux.org.uk>
>> Cc: linux-scsi at vger.kernel.org
>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>> ---
>>   drivers/scsi/scsi_lib.c |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index 86d5220..e8275fa 100644
>> --- a/drivers/scsi/scsi_lib.c
>> +++ b/drivers/scsi/scsi_lib.c
>> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
>>
>>   	host_dev = scsi_get_device(shost);
>>   	if (host_dev && host_dev->dma_mask)
>> -		bounce_limit = *host_dev->dma_mask;
>> +		bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;
>
>    You definitely forgot -1 here.

Please explain your point.


From linux at arm.linux.org.uk  Fri Jul 12 18:26:18 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 12 Jul 2013 23:26:18 +0100
Subject: Sharing *.dtsi between Linux architectures?
In-Reply-To: <51E05FEB.1090308@wwwdotorg.org>
References: <51E05FEB.1090308@wwwdotorg.org>
Message-ID: <20130712222618.GJ24642@n2100.arm.linux.org.uk>

On Fri, Jul 12, 2013 at 01:58:35PM -0600, Stephen Warren wrote:
> Is there a (possibly just proposed) mechanism in place to allow *.dts
> from multiple Linux architectures to share common *.dtsi files?

Don't forget that the long term goal is to move these files out of the
kernel source, which means that they'll be a separately managed project,
possibly with a different file structure.


From sergei.shtylyov at cogentembedded.com  Fri Jul 12 19:08:27 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Jul 2013 03:08:27 +0400
Subject: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for
 bounce_limit calculations
In-Reply-To: <20130712222506.GI24642@n2100.arm.linux.org.uk>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
 <1373665694-7580-4-git-send-email-santosh.shilimkar@ti.com>
 <51E07B6E.5090900@cogentembedded.com>
 <20130712222506.GI24642@n2100.arm.linux.org.uk>
Message-ID: <51E08C6B.2080802@cogentembedded.com>

Hello.

On 07/13/2013 02:25 AM, Russell King - ARM Linux wrote:

>>> DMA bounce limit is the maximum direct DMA'able memory beyond which
>>> bounce buffers has to be used to perform dma operations. SCSI driver
>>> relies on dma_mask but its calculation is based on max_*pfn which
>>> don't have uniform meaning across architectures. So make use of
>>> dma_max_pfn() which is expected to return the DMAable maximum pfn
>>> value across architectures.

>>> Cc: Russell King <linux at arm.linux.org.uk>
>>> Cc: linux-scsi at vger.kernel.org

>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>>> ---
>>>    drivers/scsi/scsi_lib.c |    2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)

>>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>>> index 86d5220..e8275fa 100644
>>> --- a/drivers/scsi/scsi_lib.c
>>> +++ b/drivers/scsi/scsi_lib.c
>>> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)
>>>
>>>    	host_dev = scsi_get_device(shost);
>>>    	if (host_dev && host_dev->dma_mask)
>>> -		bounce_limit = *host_dev->dma_mask;
>>> +		bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;

>>     You definitely forgot -1 here.

> Please explain your point.

    Previously, 'bounce_limit' would look like 0xffffffff (unless I'm 
mistaken), now it would look like 0xfffff000 which is hardly what we're 
looking for, no?

WBR, Sergei



From pavel at ucw.cz  Fri Jul 12 19:33:01 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Sat, 13 Jul 2013 01:33:01 +0200
Subject: [PATCH] Route kbd LEDs through the generic LEDs layer
In-Reply-To: <20130712124242.GA5876@type>
References: <201011111440.07882.dmitry.torokhov@gmail.com>
 <20110102090935.GV32469@atrey.karlin.mff.cuni.cz>
 <20110102103210.GA25662@core.coreip.homeip.net>
 <20110102225741.GX5480@const.famille.thibault.fr>
 <20110112182702.GA9168@core.coreip.homeip.net>
 <20111114040613.GA4992@type.famille.thibault.fr>
 <20121221003449.GA6999@type.youpi.perso.aquilenet.fr>
 <20130707101028.GD5651@type.youpi.perso.aquilenet.fr>
 <20130712113655.GA4227@amd.pavel.ucw.cz>
 <20130712124242.GA5876@type>
Message-ID: <20130712233301.GA3646@amd.pavel.ucw.cz>

Hi!

> > > This permits to reassign keyboard LEDs to something else than keyboard "leds"
> > > state, by adding keyboard led and modifier triggers connected to a series
> > > of VT input LEDs, themselves connected to VT input triggers, which
> > > per-input device LEDs use by default.  Userland can thus easily change the LED
> > > behavior of (a priori) all input devices, or of particular input devices.
> > 
> > Nice! Leds now have proper /sys interface.
> > 
> > But... I boot up, switch from X to console, press capslock, and no
> > reaction anywhere.
> 
> Is it working without the patch?  Console-setup for instance is known to
> have broken the capslock LED, which is precisely one of the reasons for
> this patch, which will provide console-setup with a way to bring back
> caps lock working properly.

You are right, it was broken before.

> At any rate, please provide way more information about your keyboard
> and LED configuration (output of dumpkeys, dmesg, content of
> /sys/class/leds/*/trigger, etc.), as things are just working fine for me
> (just like it has been for the past two years).

Well... I just verified, and it works "as well as before", which it
should.

> > Note that this is notebook with usb keyboard plugged in (and two
> > monitors), but I believe this worked before...
> 
> Things work fine with my USB keyboard too, is this perhaps using an odd
> driver which would not expose LEDs in a standard way?

No, everything works as well as it did. Feel free to add:

Tested-by: Pavel Machek <pavel at ucw.cz>

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From sergei.shtylyov at cogentembedded.com  Fri Jul 12 19:42:55 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Jul 2013 03:42:55 +0400
Subject: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for
 bounce_limit calculations
In-Reply-To: <51E08C6B.2080802@cogentembedded.com>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
 <1373665694-7580-4-git-send-email-santosh.shilimkar@ti.com>
 <51E07B6E.5090900@cogentembedded.com>
 <20130712222506.GI24642@n2100.arm.linux.org.uk>
 <51E08C6B.2080802@cogentembedded.com>
Message-ID: <51E0947F.1040800@cogentembedded.com>

On 07/13/2013 03:08 AM, Sergei Shtylyov wrote:

>>>> DMA bounce limit is the maximum direct DMA'able memory beyond which
>>>> bounce buffers has to be used to perform dma operations. SCSI driver
>>>> relies on dma_mask but its calculation is based on max_*pfn which
>>>> don't have uniform meaning across architectures. So make use of
>>>> dma_max_pfn() which is expected to return the DMAable maximum pfn
>>>> value across architectures.

>>>> Cc: Russell King <linux at arm.linux.org.uk>
>>>> Cc: linux-scsi at vger.kernel.org

>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>>>> ---
>>>>    drivers/scsi/scsi_lib.c |    2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)

>>>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>>>> index 86d5220..e8275fa 100644
>>>> --- a/drivers/scsi/scsi_lib.c
>>>> +++ b/drivers/scsi/scsi_lib.c
>>>> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct
>>>> Scsi_Host *shost)
>>>>
>>>>        host_dev = scsi_get_device(shost);
>>>>        if (host_dev && host_dev->dma_mask)
>>>> -        bounce_limit = *host_dev->dma_mask;
>>>> +        bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;

>>>     You definitely forgot -1 here.

>> Please explain your point.

>     Previously, 'bounce_limit' would look like 0xffffffff (unless I'm
> mistaken), now it would look like 0xfffff000 which is hardly what we're
> looking for, no?

    Although, -1 won't give us the correct result in this case, it's 
more like + PAGE_SIZE - 1.

WBR, Sergei



From linux at arm.linux.org.uk  Fri Jul 12 19:57:11 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 13 Jul 2013 00:57:11 +0100
Subject: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for
 bounce_limit calculations
In-Reply-To: <51E0947F.1040800@cogentembedded.com>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
 <1373665694-7580-4-git-send-email-santosh.shilimkar@ti.com>
 <51E07B6E.5090900@cogentembedded.com>
 <20130712222506.GI24642@n2100.arm.linux.org.uk>
 <51E08C6B.2080802@cogentembedded.com> <51E0947F.1040800@cogentembedded.com>
Message-ID: <20130712235711.GK24642@n2100.arm.linux.org.uk>

On Sat, Jul 13, 2013 at 03:42:55AM +0400, Sergei Shtylyov wrote:
>>>>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>>>>> index 86d5220..e8275fa 100644
>>>>> --- a/drivers/scsi/scsi_lib.c
>>>>> +++ b/drivers/scsi/scsi_lib.c
>>>>> @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct
>>>>> Scsi_Host *shost)
>>>>>
>>>>>        host_dev = scsi_get_device(shost);
>>>>>        if (host_dev && host_dev->dma_mask)
>>>>> -        bounce_limit = *host_dev->dma_mask;
>>>>> +        bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;
>
>>>>     You definitely forgot -1 here.
>
>>> Please explain your point.
>
>>     Previously, 'bounce_limit' would look like 0xffffffff (unless I'm
>> mistaken), now it would look like 0xfffff000 which is hardly what we're
>> looking for, no?
>
>    Although, -1 won't give us the correct result in this case, it's more 
> like + PAGE_SIZE - 1.

And where it's used is blk_bounce_limit(), the first which that does
is convert it back to a PFN, losing the bottom bits again...

I'm tempted to suggest converting the whole thing to just deal with
PFNs rather than bytes since we only deal with "can we DMA to this"
on a per-page basis.


From linux at arm.linux.org.uk  Fri Jul 12 20:14:42 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 13 Jul 2013 01:14:42 +0100
Subject: [RFC/RFT PATCH 4/5] ARM: mm: change max*pfn to include the
 physical offset of memory
In-Reply-To: <1373665694-7580-5-git-send-email-santosh.shilimkar@ti.com>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
 <1373665694-7580-5-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <20130713001442.GL24642@n2100.arm.linux.org.uk>

On Fri, Jul 12, 2013 at 05:48:13PM -0400, Santosh Shilimkar wrote:
> Most of the kernel code assumes that max*pfn is maximum pfns because
> the physical start of memory is expected to be PFN0. Since this
> assumption is not true on ARM architectures, the meaning of max*pfn
> is number of memory pages. This is done to keep drivers happy which
> are making use of of these variable to calculate the dma bounce limit
> using dma_mask.
> 
> Now since we have a architecture override possibility for DMAable
> maximum pfns, lets make meaning of max*pfns as maximum pnfs on ARM
> as well.
> 
> In the patch, the dma_to_pfn/pfn_to_dma() pair is hacked to take care of
> the physical memory offset. It is done this way just to enable testing
> since its understood that it can come in way of single zImage.

As Santosh says, this is a hack - but we need to have a discussion about
how to handle translations from PFN to bus addresses.

Currently, the way we do that on ARM is mostly assume that physical
addresses are the same as bus addresses, but that's not true everywhere,
and certainly isn't true when you have a 32-bit DMA controller which
can access physical memory, where the physical memory is above 4GB
in physical space.

We have certain platforms where the DMA address is already being
programmed into a controller with less than 32-bits in its address
register, and with a physical memory offset - and of course this
case just works out of the box because the high bits are ignored
by the device.

What I'm basically saying is we've had this problem for a while, and
we've lived with it by hoping and hacking, and adjusting max*pfn, but
this is not long-term sustainable.  We *need* to get away from the
idea that DMA addresses are physical addresses and device DMA masks
have some relationship to physical addresses.

Consider for a moment:

	PCI address 0x00000000 ---> physical address 0xc0000000.

You plug a card in which can't do 32-bit addressing (remember, there
are such PCI cards in the past...).  The driver sets the DMA mask to
0x0fffffff (or whatever).  How does that relate to the PCI bus address?
It's 0x00000000 to 0x0fffffff.  How does that relate to the physical
address space?  0xc0000000 to 0xcfffffff.

This is why DMA masks can't be treated as some notional address limit.
It just doesn't work when you have bus offsets.

And the extreme case of that is LPAE with all system memory above the
4GB physical mark, with 32-bit DMA capable peripherals - which we're
starting to see now.

Ideally, I think we need some kind of per-bus DT property to describe
the memory which can be accessed from the bus - to do it properly to
cover the cases we've already seen, that would be an offset and a size.

We then need some way for dma_to_pfn() and pfn_to_dma() to efficiently
get at that information - bear in mind that they're hot paths when doing
DMA mappings and the like.  I doubt we want to be looking up the same
property time and time again inside them.


From haojian.zhuang at gmail.com  Fri Jul 12 20:35:03 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Sat, 13 Jul 2013 08:35:03 +0800
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <CAMLZHHQGZvDssY-YxQ3ZW8FYhpG-H1-VbokOid33socRSPrMNw@mail.gmail.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <CAN1soZxiOh6TpbUOCUzK8gNwmvjbT3ihkUWaw8tuZ7md+NVA2g@mail.gmail.com>
 <20130710122433.GO11908@titan.lakedaemon.net>
 <CAN1soZzMvront1-jcBW6-uRKNs0OZNGnmiOjKGZSM28bViB_8A@mail.gmail.com>
 <20130710215041.GR11908@titan.lakedaemon.net>
 <CAN1soZzuiukY9qASFNcH0k=zH8=uT=71bKejPss44FCzNy=X-A@mail.gmail.com>
 <CAMLZHHQGZvDssY-YxQ3ZW8FYhpG-H1-VbokOid33socRSPrMNw@mail.gmail.com>
Message-ID: <CAN1soZzQz8PaHOwNf-Ec6G=ahhx_P8gaaX4fQnpX-Mqrepk_7g@mail.gmail.com>

On Fri, Jul 12, 2013 at 11:10 PM, Daniel Drake <dsd at laptop.org> wrote:
> On Thu, Jul 11, 2013 at 5:54 PM, Haojian Zhuang
> <haojian.zhuang at gmail.com> wrote:
>>> Well, Daniel Drake spoke up for OLPC.  Does that count?
>>
>> We don't know they used DT on Marvell MMP2/MMP3. So they don't have DTS file
>> in kernel, we could use both old name & new name in driver.
>
> You are listed as one of the MMP maintainers in the MAINTAINERS file
> and I have sent you several patches in the few 3 weeks which make
> OLPC's usage of MMP + DT pretty obvious. As a maintainer I believe you
> are supposed to review the patches too. hint hint ;)
>

These patches couldn't be applied. Since we're moving irq drivers from arch
directories to irq directories.

When the irq patches are applied, you can rebase your patches.

Regards
Haojian


From B29397 at freescale.com  Fri Jul 12 20:36:13 2013
From: B29397 at freescale.com (Chen Peter-B29397)
Date: Sat, 13 Jul 2013 00:36:13 +0000
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <201307121518.31501.marex@denx.de>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <201307120604.43642.marex@denx.de> <20130712082642.GB16202@nchen-desktop>
 <201307121518.31501.marex@denx.de>
Message-ID: <F281D0F91ED19E4D8E63A7504E8A649803F46D18@039-SN2MPN1-022.039d.mgd.msft.net>


 
> 
> Yes, ID interrupt (IDIE) is set.
> 
> I noticed this backtrace in the kernel bootlog, but this only happens if
> the
> dr_mode="otg" , it comes from the host-mode irq handler :
> 
> [    2.757563] irq 238: nobody cared (try booting with the "irqpoll"
> option)
> [    2.764398] CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-
> next-20130711-00013-g011c4b3-dirty #703
> [    2.773445] [<80013878>] (unwind_backtrace+0x0/0xe8) from [<80011644>]
> (show_stack+0x10/0x14)
> [    2.782027] [<80011644>] (show_stack+0x10/0x14) from [<800659f4>]
> (__report_bad_irq.isra.6+0x20/0xe0)
> [    2.791286] [<800659f4>] (__report_bad_irq.isra.6+0x20/0xe0) from
> [<80065c98>] (note_interrupt+0x16c/0x230)
> [    2.801063] [<80065c98>] (note_interrupt+0x16c/0x230) from [<80064000>]
> (handle_irq_event_percpu+0x10c/0x1a4)
> [    2.811010] [<80064000>] (handle_irq_event_percpu+0x10c/0x1a4) from
> [<800640e8>] (handle_irq_event+0x50/0x78)
> [    2.820958] [<800640e8>] (handle_irq_event+0x50/0x78) from [<8006652c>]
> (handle_level_irq+0x88/0x10c)
> [    2.830210] [<8006652c>] (handle_level_irq+0x88/0x10c) from
> [<800638d0>]
> (generic_handle_irq+0x28/0x3c)
> [    2.839637] [<800638d0>] (generic_handle_irq+0x28/0x3c) from
> [<8000f84c>]
> (handle_IRQ+0x30/0x84)
> [    2.848461] [<8000f84c>] (handle_IRQ+0x30/0x84) from [<80012160>]
> (__irq_svc+0x40/0x6c)
> [    2.856510] [<80012160>] (__irq_svc+0x40/0x6c) from [<80022a44>]
> (__do_softirq+0x90/0x1d8)
> [    2.864812] [<80022a44>] (__do_softirq+0x90/0x1d8) from [<80022edc>]
> (irq_exit+0x98/0xd4)
> [    2.873025] [<80022edc>] (irq_exit+0x98/0xd4) from [<8000f850>]
> (handle_IRQ+0x34/0x84)
> [    2.880980] [<8000f850>] (handle_IRQ+0x34/0x84) from [<80012160>]
> (__irq_svc+0x40/0x6c)
> [    2.889020] [<80012160>] (__irq_svc+0x40/0x6c) from [<8001d724>]
> (vprintk_emit+0x1bc/0x524)
> [    2.897411] [<8001d724>] (vprintk_emit+0x1bc/0x524) from [<804da5a4>]
> (printk+0x30/0x40)
> [    2.905551] [<804da5a4>] (printk+0x30/0x40) from [<80630138>]
> (mousedev_init+0x4c/0x60)
> [    2.913617] [<80630138>] (mousedev_init+0x4c/0x60) from [<806178fc>]
> (do_one_initcall+0x94/0x14c)
> [    2.922537] [<806178fc>] (do_one_initcall+0x94/0x14c) from [<80617b20>]
> (kernel_init_freeable+0x16c/0x22c)
> [    2.932230] [<80617b20>] (kernel_init_freeable+0x16c/0x22c) from
> [<804d8cbc>]
> (kernel_init+0x8/0x150)
> [    2.941486] [<804d8cbc>] (kernel_init+0x8/0x150) from [<8000ea70>]
> (ret_from_fork+0x14/0x24)
> [    2.949932] handlers:
> [    2.952227] [<8033fc58>] ci_irq
> [    2.955388] Disabling IRQ #238
> 

See this " Disabling IRQ #238", that is the reason you can't get
ID interrupt.

I have no other idea before I try, you can try below things:

1. please switch VDD 5V SOURCE SELECT to USB 5V
2. try not plug in mouse during the boots up

> btw. do you have any kind of other CI13xxx documentation than what's in
> the CPU
> datasheets ?
> 

Mx28 RM does not include many controller detail, please try to 
read it from mx6/mx5 RM.

Best regards,
Peter
 




From olof at lixom.net  Fri Jul 12 22:31:58 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 12 Jul 2013 19:31:58 -0700
Subject: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c
In-Reply-To: <20130706133627.GV21614@n2100.arm.linux.org.uk>
References: <20130517191304.468.73487.stgit@localhost>
 <20130517191751.468.89202.stgit@localhost>
 <20130520095447.GR21614@n2100.arm.linux.org.uk>
 <20130706131057.GU21614@n2100.arm.linux.org.uk>
 <20130706133627.GV21614@n2100.arm.linux.org.uk>
Message-ID: <CAOesGMjv=GxWSxaUebY6pP4sJHfQNeuUk2BcAFBT3QxX3jGZLw@mail.gmail.com>

Hi,


On Sat, Jul 6, 2013 at 6:36 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:

> With that worked out, throwing my standard printascii() hack into the
> kernel results in boot messages... up to the point where the timer is
> calibrated.  So, it looks like either interrupts, clocks, or the OMAP
> timers are non-functional with DT based kernels on the SDP board.
>
> Any ideas?

I'm a bit late to the party due to travel and other things going on,
but I have the exact same thing happening with multi_v7_defconfig on
my Panda ES right now -- it gets stuck on calibrating delay loop. I
needed to enable DEBUG_LL and early printk to not just get a dead
system though.

What happened in my case was that MACH_OMAP4 was no longer enabled so
clocks weren't registered. I wonder if we can improve debugability of
that somehow.

Before Arnd's patch to flip the MACH_OMAP2PLUS option around, they got
enabled by default I think. So now I needed:

-CONFIG_ARCH_OMAP2PLUS=y
+CONFIG_ARCH_OMAP3=y
+CONFIG_ARCH_OMAP4=y
 CONFIG_SOC_OMAP5=y
+CONFIG_SOC_AM33XX=y

...in the defconfig.

This is pretty painful, and I don't know if we want to rethink Arnd's
patch since it will break existing defconfigs out there that rely on
OMAP2PLUS enabling the socs instead of the other way around. Opinions?


-Olof


From olof at lixom.net  Fri Jul 12 23:10:29 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 12 Jul 2013 20:10:29 -0700
Subject: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c
In-Reply-To: <CAOesGMjv=GxWSxaUebY6pP4sJHfQNeuUk2BcAFBT3QxX3jGZLw@mail.gmail.com>
References: <20130517191304.468.73487.stgit@localhost>
 <20130517191751.468.89202.stgit@localhost>
 <20130520095447.GR21614@n2100.arm.linux.org.uk>
 <20130706131057.GU21614@n2100.arm.linux.org.uk>
 <20130706133627.GV21614@n2100.arm.linux.org.uk>
 <CAOesGMjv=GxWSxaUebY6pP4sJHfQNeuUk2BcAFBT3QxX3jGZLw@mail.gmail.com>
Message-ID: <CAOesGMgO74FU0P4DC6_yws8ZaQ6F923-LWwGAxbCQkQbr69L5w@mail.gmail.com>

On Fri, Jul 12, 2013 at 7:31 PM, Olof Johansson <olof at lixom.net> wrote:

> This is pretty painful, and I don't know if we want to rethink Arnd's
> patch since it will break existing defconfigs out there that rely on
> OMAP2PLUS enabling the socs instead of the other way around. Opinions?

(replying to myself, I know, I know...)

I think it's probably easiest to just select the OMAP{2,3,4} and
AM33XX options in multi_v7_defconfig just like Arnd did in the commit
that changed the dependencies for now. I've added a patch on top of
our current fixes branch to do so.

Note that you need to make corresponding changes to your seeds for
your build tests, Russell.


-Olof


From olof at lixom.net  Fri Jul 12 23:12:54 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 12 Jul 2013 20:12:54 -0700
Subject: [PATCH] arm: multi_v7_defconfig: Tweaks for omap and sunxi
Message-ID: <1373685174-7918-1-git-send-email-olof@lixom.net>

OMAP recently changed how the platforms are configured, so OMAP2/3/4 SoC
support is no longer enabled by default. Add them back.

Enable new ethernet driver for sunxi.

The i.MX console options moved due to resorting, no functional change.

Signed-off-by: Olof Johansson <olof at lixom.net>
---

The OMAP changes are needed to deal with the dependency flip from OMAP2PLUS
being on and defaulting the SoCs accordingly, to the SoC options selecting
OMAP2PLUS. See the "ARM: OMAP2+: Remove board-4430sdp.c" for background.

 arch/arm/configs/multi_v7_defconfig | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 80aacc6..fcd2b9b 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -15,8 +15,10 @@ CONFIG_SOC_IMX53=y
 CONFIG_SOC_IMX6Q=y
 CONFIG_SOC_IMX6SL=y
 CONFIG_SOC_VF610=y
-CONFIG_ARCH_OMAP2PLUS=y
+CONFIG_ARCH_OMAP3=y
+CONFIG_ARCH_OMAP4=y
 CONFIG_SOC_OMAP5=y
+CONFIG_SOC_AM33XX=y
 CONFIG_SOC_AM43XX=y
 CONFIG_ARCH_ROCKCHIP=y
 CONFIG_ARCH_SOCFPGA=y
@@ -57,6 +59,7 @@ CONFIG_SATA_AHCI_PLATFORM=y
 CONFIG_SATA_HIGHBANK=y
 CONFIG_SATA_MV=y
 CONFIG_NETDEVICES=y
+CONFIG_SUN4I_EMAC=y
 CONFIG_NET_CALXEDA_XGMAC=y
 CONFIG_SMSC911X=y
 CONFIG_STMMAC_ETH=y
@@ -70,6 +73,8 @@ CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
 CONFIG_SERIAL_SIRFSOC=y
 CONFIG_SERIAL_SIRFSOC_CONSOLE=y
 CONFIG_SERIAL_TEGRA=y
+CONFIG_SERIAL_IMX=y
+CONFIG_SERIAL_IMX_CONSOLE=y
 CONFIG_SERIAL_VT8500=y
 CONFIG_SERIAL_VT8500_CONSOLE=y
 CONFIG_SERIAL_OF_PLATFORM=y
@@ -77,8 +82,6 @@ CONFIG_SERIAL_OMAP=y
 CONFIG_SERIAL_OMAP_CONSOLE=y
 CONFIG_SERIAL_XILINX_PS_UART=y
 CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
-CONFIG_SERIAL_IMX=y
-CONFIG_SERIAL_IMX_CONSOLE=y
 CONFIG_SERIAL_FSL_LPUART=y
 CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
 CONFIG_I2C_DESIGNWARE_PLATFORM=y
-- 
1.8.1.192.gc4361b8



From jld at mozilla.com  Fri Jul 12 23:17:14 2013
From: jld at mozilla.com (Jed Davis)
Date: Fri, 12 Jul 2013 20:17:14 -0700
Subject: [PATCH] ARM: perf: Implement perf_arch_fetch_caller_regs
Message-ID: <1373685434-1581-1-git-send-email-jld@mozilla.com>

We need a perf_arch_fetch_caller_regs for at least some software events
to be able to get a callchain; even user stacks won't work without
at least the CPSR bits for non-user-mode (see perf_callchain).  In
particular, profiling context switches needs this.

This records the state of the point at which perf_arch_fetch_caller_regs
is expanded, instead of that function activation's call site, because we
need SP and PC to be consistent for EHABI unwinding; hopefully nothing
will be inconvenienced by the extra stack frame.

Signed-off-by: Jed Davis <jld at mozilla.com>
---
 arch/arm/include/asm/perf_event.h |   43 +++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/include/asm/perf_event.h b/arch/arm/include/asm/perf_event.h
index 7558775..2cc7255 100644
--- a/arch/arm/include/asm/perf_event.h
+++ b/arch/arm/include/asm/perf_event.h
@@ -12,6 +12,8 @@
 #ifndef __ARM_PERF_EVENT_H__
 #define __ARM_PERF_EVENT_H__
 
+#include <asm/ptrace.h>
+
 /*
  * The ARMv7 CPU PMU supports up to 32 event counters.
  */
@@ -28,4 +30,45 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)	perf_misc_flags(regs)
 #endif
 
+/*
+ * We can't actually get the caller's registers here; the saved PC and
+ * SP values have to be consistent or else EHABI unwinding won't work,
+ * and the only way to find the matching SP for the return address is
+ * to unwind the current function.  So we save the current state
+ * instead.
+ *
+ * Note that the ARM Exception Handling ABI allows unwinding to depend
+ * on the contents of any core register, but our unwinder is limited
+ * to the ones in struct stackframe (which are the only ones we expect
+ * GCC to need for kernel code), so we just record those.
+ */
+#ifdef CONFIG_THUMB2_KERNEL
+#define perf_arch_fetch_caller_regs(regs, ip)				\
+	do {								\
+		__u32 _cpsr, _pc;					\
+		__asm__ __volatile__("str r7, [%[_regs], #(7 * 4)]\n\t" \
+				     "str r13, [%[_regs], #(13 * 4)]\n\t" \
+				     "str r14, [%[_regs], #(14 * 4)]\n\t" \
+				     "mov %[_pc],  r15\n\t"		\
+				     "mrs %[_cpsr], cpsr\n\t"		\
+				     : [_cpsr] "=r" (_cpsr),		\
+				       [_pc] "=r" (_pc)			\
+				     : [_regs] "r" (&(regs)->uregs)	\
+				     : "memory");			\
+		(regs)->ARM_pc = _pc;					\
+		(regs)->ARM_cpsr = _cpsr;				\
+	} while (0)
+#else
+#define perf_arch_fetch_caller_regs(regs, ip)				\
+	do {								\
+		__u32 _cpsr;						\
+		__asm__ __volatile__("stmia %[_regs11], {r11 - r15}\n\t" \
+				     "mrs %[_cpsr], cpsr\n\t"		\
+				     : [_cpsr] "=r" (_cpsr)		\
+				     : [_regs11] "r" (&(regs)->uregs[11]) \
+				     : "memory");			\
+		(regs)->ARM_cpsr = _cpsr;				\
+	} while (0)
+#endif
+
 #endif /* __ARM_PERF_EVENT_H__ */
-- 
1.7.10.4



From jld at mozilla.com  Fri Jul 12 23:18:20 2013
From: jld at mozilla.com (Jed Davis)
Date: Fri, 12 Jul 2013 20:18:20 -0700
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y
Message-ID: <1373685501-1620-1-git-send-email-jld@mozilla.com>

There is currently some inconsistency about the "frame pointer" on ARM.
r11 is the register with assemblers recognize and disassemblers often
print as "fp", and which is sufficient for stack unwinding when using
the APCS frame pointer option; but when unwinding with the Exception
Handling ABI, the register GCC uses when a constant offset won't suffice
(or when -fno-omit-frame-pointer is used; see kernel/sched/Makefile in
particular) is r11 on ARM and r7 on Thumb.

Correspondingly, arch/arm/include/uapi/arm/ptrace.h defines ARM_fp to
refer to r11, but arch/arm/kernel/unwind.c uses "FP" to mean either r11
or r7 depending on Thumbness, and it is unclear what other cases such as
the "fp" in struct stackframe should be doing.

Effects of this are probably limited to failure of EHABI unwinding when
starting from a function that uses r7 to restore its stack pointer, but
the possibility for further breakage (which would be invisible on
non-Thumb kernels) is worrying.

With this change, it is hoped, r7 is consistently referred to as "r7",
and "fp" always means r11; this costs a few extra ifdefs, but it should
help prevent future issues.

Signed-off-by: Jed Davis <jld at mozilla.com>
---
 arch/arm/include/asm/stacktrace.h  |    4 ++++
 arch/arm/include/asm/thread_info.h |    2 ++
 arch/arm/kernel/perf_event.c       |    4 ++++
 arch/arm/kernel/process.c          |    4 ++++
 arch/arm/kernel/time.c             |    4 ++++
 arch/arm/kernel/unwind.c           |   27 ++++++++++++++++++++++++++-
 arch/arm/oprofile/common.c         |    4 ++++
 7 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/stacktrace.h b/arch/arm/include/asm/stacktrace.h
index 4d0a164..5e546bf 100644
--- a/arch/arm/include/asm/stacktrace.h
+++ b/arch/arm/include/asm/stacktrace.h
@@ -2,7 +2,11 @@
 #define __ASM_STACKTRACE_H
 
 struct stackframe {
+#ifdef CONFIG_THUMB2_KERNEL
+	unsigned long r7;
+#else
 	unsigned long fp;
+#endif
 	unsigned long sp;
 	unsigned long lr;
 	unsigned long pc;
diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
index 214d415..ae3cd81 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -105,6 +105,8 @@ static inline struct thread_info *current_thread_info(void)
 	((unsigned long)(task_thread_info(tsk)->cpu_context.sp))
 #define thread_saved_fp(tsk)	\
 	((unsigned long)(task_thread_info(tsk)->cpu_context.fp))
+#define thread_saved_r7(tsk)	\
+	((unsigned long)(task_thread_info(tsk)->cpu_context.r7))
 
 extern void crunch_task_disable(struct thread_info *);
 extern void crunch_task_copy(struct thread_info *, void *);
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index d9f5cd4..55776d6 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -601,7 +601,11 @@ perf_callchain_kernel(struct perf_callchain_entry *entry, struct pt_regs *regs)
 		return;
 	}
 
+#ifdef CONFIG_THUMB2_KERNEL
+	fr.r7 = regs->ARM_r7;
+#else
 	fr.fp = regs->ARM_fp;
+#endif
 	fr.sp = regs->ARM_sp;
 	fr.lr = regs->ARM_lr;
 	fr.pc = regs->ARM_pc;
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index d3ca4f6..aeb4c28 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -405,7 +405,11 @@ unsigned long get_wchan(struct task_struct *p)
 	if (!p || p == current || p->state == TASK_RUNNING)
 		return 0;
 
+#ifdef CONFIG_THUMB2_KERNEL
+	frame.r7 = thread_saved_r7(p);
+#else
 	frame.fp = thread_saved_fp(p);
+#endif
 	frame.sp = thread_saved_sp(p);
 	frame.lr = 0;			/* recovered from the stack */
 	frame.pc = thread_saved_pc(p);
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 98aee32..80410d3 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -49,7 +49,11 @@ unsigned long profile_pc(struct pt_regs *regs)
 	if (!in_lock_functions(regs->ARM_pc))
 		return regs->ARM_pc;
 
+#ifdef CONFIG_THUMB2_KERNEL
+	frame.r7 = regs->ARM_r7;
+#else
 	frame.fp = regs->ARM_fp;
+#endif
 	frame.sp = regs->ARM_sp;
 	frame.lr = regs->ARM_lr;
 	frame.pc = regs->ARM_pc;
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 00df012..dec03ae 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -74,7 +74,7 @@ struct unwind_ctrl_block {
 
 enum regs {
 #ifdef CONFIG_THUMB2_KERNEL
-	FP = 7,
+	R7 = 7,
 #else
 	FP = 11,
 #endif
@@ -317,8 +317,13 @@ static int unwind_exec_insn(struct unwind_ctrl_block *ctrl)
 		return -URC_FAILURE;
 	}
 
+#ifdef CONFIG_THUMB2_KERNEL
+	pr_debug("%s: r7 = %08lx sp = %08lx lr = %08lx pc = %08lx\n", __func__,
+		 ctrl->vrs[R7], ctrl->vrs[SP], ctrl->vrs[LR], ctrl->vrs[PC]);
+#else
 	pr_debug("%s: fp = %08lx sp = %08lx lr = %08lx pc = %08lx\n", __func__,
 		 ctrl->vrs[FP], ctrl->vrs[SP], ctrl->vrs[LR], ctrl->vrs[PC]);
+#endif
 
 	return URC_OK;
 }
@@ -349,7 +354,11 @@ int unwind_frame(struct stackframe *frame)
 		return -URC_FAILURE;
 	}
 
+#ifdef CONFIG_THUMB2_KERNEL
+	ctrl.vrs[R7] = frame->r7;
+#else
 	ctrl.vrs[FP] = frame->fp;
+#endif
 	ctrl.vrs[SP] = frame->sp;
 	ctrl.vrs[LR] = frame->lr;
 	ctrl.vrs[PC] = 0;
@@ -397,7 +406,11 @@ int unwind_frame(struct stackframe *frame)
 	if (frame->pc == ctrl.vrs[PC])
 		return -URC_FAILURE;
 
+#ifdef CONFIG_THUMB2_KERNEL
+	frame->r7 = ctrl.vrs[R7];
+#else
 	frame->fp = ctrl.vrs[FP];
+#endif
 	frame->sp = ctrl.vrs[SP];
 	frame->lr = ctrl.vrs[LR];
 	frame->pc = ctrl.vrs[PC];
@@ -416,20 +429,32 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 		tsk = current;
 
 	if (regs) {
+#ifdef CONFIG_THUMB2_KERNEL
+		frame.r7 = regs->ARM_r7;
+#else
 		frame.fp = regs->ARM_fp;
+#endif
 		frame.sp = regs->ARM_sp;
 		frame.lr = regs->ARM_lr;
 		/* PC might be corrupted, use LR in that case. */
 		frame.pc = kernel_text_address(regs->ARM_pc)
 			 ? regs->ARM_pc : regs->ARM_lr;
 	} else if (tsk == current) {
+#ifdef CONFIG_THUMB2_KERNEL
+		frame.r7 = (unsigned long)__builtin_frame_address(0);
+#else
 		frame.fp = (unsigned long)__builtin_frame_address(0);
+#endif
 		frame.sp = current_sp;
 		frame.lr = (unsigned long)__builtin_return_address(0);
 		frame.pc = (unsigned long)unwind_backtrace;
 	} else {
 		/* task blocked in __switch_to */
+#ifdef CONFIG_THUMB2_KERNEL
+		frame.r7 = thread_saved_r7(tsk);
+#else
 		frame.fp = thread_saved_fp(tsk);
+#endif
 		frame.sp = thread_saved_sp(tsk);
 		/*
 		 * The function calling __switch_to cannot be a leaf function
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 99c63d4b..38cbfff 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -107,7 +107,11 @@ static void arm_backtrace(struct pt_regs * const regs, unsigned int depth)
 
 	if (!user_mode(regs)) {
 		struct stackframe frame;
+#ifdef CONFIG_THUMB2_KERNEL
+		frame.r7 = regs->ARM_r7;
+#else
 		frame.fp = regs->ARM_fp;
+#endif
 		frame.sp = regs->ARM_sp;
 		frame.lr = regs->ARM_lr;
 		frame.pc = regs->ARM_pc;
-- 
1.7.10.4



From emilio at elopez.com.ar  Fri Jul 12 23:51:04 2013
From: emilio at elopez.com.ar (=?ISO-8859-1?Q?Emilio_L=F3pez?=)
Date: Sat, 13 Jul 2013 00:51:04 -0300
Subject: [PATCH] arm: multi_v7_defconfig: Tweaks for omap and sunxi
In-Reply-To: <1373685174-7918-1-git-send-email-olof@lixom.net>
References: <1373685174-7918-1-git-send-email-olof@lixom.net>
Message-ID: <51E0CEA8.2040201@elopez.com.ar>

Hi Olof,

El 13/07/13 00:12, Olof Johansson escribi?:
> OMAP recently changed how the platforms are configured, so OMAP2/3/4 SoC
> support is no longer enabled by default. Add them back.
> 
> Enable new ethernet driver for sunxi.

"ARM: multi_v7: Enable Allwinner EMAC in multi_v7_defconfig" by Maxime
already does this, and is on Linus Torvalds' tree:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fb1c60288a886a28dc7c055449fd1936140fe891

> 
> The i.MX console options moved due to resorting, no functional change.
> 
> Signed-off-by: Olof Johansson <olof at lixom.net>
> ---
> 
> The OMAP changes are needed to deal with the dependency flip from OMAP2PLUS
> being on and defaulting the SoCs accordingly, to the SoC options selecting
> OMAP2PLUS. See the "ARM: OMAP2+: Remove board-4430sdp.c" for background.
> 
>  arch/arm/configs/multi_v7_defconfig | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index 80aacc6..fcd2b9b 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -15,8 +15,10 @@ CONFIG_SOC_IMX53=y
>  CONFIG_SOC_IMX6Q=y
>  CONFIG_SOC_IMX6SL=y
>  CONFIG_SOC_VF610=y
> -CONFIG_ARCH_OMAP2PLUS=y
> +CONFIG_ARCH_OMAP3=y
> +CONFIG_ARCH_OMAP4=y
>  CONFIG_SOC_OMAP5=y
> +CONFIG_SOC_AM33XX=y
>  CONFIG_SOC_AM43XX=y
>  CONFIG_ARCH_ROCKCHIP=y
>  CONFIG_ARCH_SOCFPGA=y
> @@ -57,6 +59,7 @@ CONFIG_SATA_AHCI_PLATFORM=y
>  CONFIG_SATA_HIGHBANK=y
>  CONFIG_SATA_MV=y
>  CONFIG_NETDEVICES=y
> +CONFIG_SUN4I_EMAC=y

Additionally, this patch is missing CONFIG_MDIO_SUN4I=y, which I think
would be needed to make CONFIG_SUN4I_EMAC=y of any use. Maybe a Kconfig
select would be a good idea here?

>  CONFIG_NET_CALXEDA_XGMAC=y
>  CONFIG_SMSC911X=y
>  CONFIG_STMMAC_ETH=y
> @@ -70,6 +73,8 @@ CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
>  CONFIG_SERIAL_SIRFSOC=y
>  CONFIG_SERIAL_SIRFSOC_CONSOLE=y
>  CONFIG_SERIAL_TEGRA=y
> +CONFIG_SERIAL_IMX=y
> +CONFIG_SERIAL_IMX_CONSOLE=y
>  CONFIG_SERIAL_VT8500=y
>  CONFIG_SERIAL_VT8500_CONSOLE=y
>  CONFIG_SERIAL_OF_PLATFORM=y
> @@ -77,8 +82,6 @@ CONFIG_SERIAL_OMAP=y
>  CONFIG_SERIAL_OMAP_CONSOLE=y
>  CONFIG_SERIAL_XILINX_PS_UART=y
>  CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
> -CONFIG_SERIAL_IMX=y
> -CONFIG_SERIAL_IMX_CONSOLE=y
>  CONFIG_SERIAL_FSL_LPUART=y
>  CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
>  CONFIG_I2C_DESIGNWARE_PLATFORM=y
> 

Cheers,

Emilio


From shc_work at mail.ru  Sat Jul 13 00:25:50 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 13 Jul 2013 08:25:50 +0400
Subject: [PATCH v2 2/3] input: mc13783: Add MC13892 support
In-Reply-To: <1373689551-24375-1-git-send-email-shc_work@mail.ru>
References: <1373689551-24375-1-git-send-email-shc_work@mail.ru>
Message-ID: <1373689551-24375-2-git-send-email-shc_work@mail.ru>


Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 drivers/input/misc/Kconfig             |  6 +++---
 drivers/input/misc/mc13783-pwrbutton.c | 10 +++++++++-
 include/linux/mfd/mc13892.h            |  4 ++++
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 0b541cd..0d83653 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -167,10 +167,10 @@ config INPUT_MAX8997_HAPTIC
 	  module will be called max8997-haptic.
 
 config INPUT_MC13783_PWRBUTTON
-	tristate "MC13783 ON buttons"
-	depends on MFD_MC13783
+	tristate "MC13783/MC13892 ON buttons"
+	depends on MFD_MC13XXX
 	help
-	  Support the ON buttons of MC13783 PMIC as an input device
+	  Support the ON buttons of MC13783/MC13892 PMIC as an input device
 	  reporting power button status.
 
 	  To compile this driver as a module, choose M here: the module
diff --git a/drivers/input/misc/mc13783-pwrbutton.c b/drivers/input/misc/mc13783-pwrbutton.c
index 33613ca..855d576 100644
--- a/drivers/input/misc/mc13783-pwrbutton.c
+++ b/drivers/input/misc/mc13783-pwrbutton.c
@@ -26,6 +26,7 @@
 #include <linux/input.h>
 #include <linux/platform_device.h>
 #include <linux/mfd/mc13783.h>
+#include <linux/mfd/mc13892.h>
 
 struct mc13xxx_button_def {
 	unsigned int	irq;
@@ -194,8 +195,15 @@ static const struct mc13xxx_pwrb_devtype mc13783_pwrb_devtype = {
 	.btn_def[2] = { MC13783_IRQ_ONOFD3, BIT(5) }
 };
 
+static const struct mc13xxx_pwrb_devtype mc13892_pwrb_devtype = {
+	.btn_def[0] = { MC13892_IRQ_ONOFD1, BIT(3) },
+	.btn_def[1] = { MC13892_IRQ_ONOFD2, BIT(4) },
+	.btn_def[2] = { MC13892_IRQ_ONOFD3, BIT(2) }
+};
+
 static const struct platform_device_id mc13xxx_pwrbutton_id_table[] = {
 	{ "mc13783-pwrbutton", (kernel_ulong_t)&mc13783_pwrb_devtype },
+	{ "mc13892-pwrbutton", (kernel_ulong_t)&mc13892_pwrb_devtype },
 	{ }
 };
 MODULE_DEVICE_TABLE(platform, mc13xxx_pwrbutton_id_table);
@@ -209,6 +217,6 @@ static struct platform_driver mc13xxx_pwrbutton_driver = {
 };
 module_platform_driver_probe(mc13xxx_pwrbutton_driver, mc13xxx_pwrbutton_probe);
 
-MODULE_DESCRIPTION("MC13783 Power Button");
+MODULE_DESCRIPTION("MC13XXX Power Button");
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Philippe Retornaz");
diff --git a/include/linux/mfd/mc13892.h b/include/linux/mfd/mc13892.h
index a00f2be..bdc3baf 100644
--- a/include/linux/mfd/mc13892.h
+++ b/include/linux/mfd/mc13892.h
@@ -36,4 +36,8 @@
 #define MC13892_PWGT2SPI	22
 #define MC13892_VCOINCELL	23
 
+#define MC13892_IRQ_ONOFD3	26
+#define MC13892_IRQ_ONOFD1	27
+#define MC13892_IRQ_ONOFD2	28
+
 #endif
-- 
1.8.1.5



From shc_work at mail.ru  Sat Jul 13 00:25:51 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 13 Jul 2013 08:25:51 +0400
Subject: [PATCH v2 3/3] input: mc13783: Add DT probe support
In-Reply-To: <1373689551-24375-1-git-send-email-shc_work@mail.ru>
References: <1373689551-24375-1-git-send-email-shc_work@mail.ru>
Message-ID: <1373689551-24375-3-git-send-email-shc_work@mail.ru>

Patch adds DT support for MC13783/MC13892 PMICs.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 Documentation/devicetree/bindings/mfd/mc13xxx.txt | 13 +++++
 drivers/input/misc/mc13783-pwrbutton.c            | 59 ++++++++++++++++++-----
 2 files changed, 59 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/mc13xxx.txt b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
index abd9e3c..cf8b61c 100644
--- a/Documentation/devicetree/bindings/mfd/mc13xxx.txt
+++ b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
@@ -10,6 +10,12 @@ Optional properties:
 - fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used
 
 Sub-nodes:
+- buttons : Contain power button nodes. Each button should be declared as
+  "button@<num>" and contain code in "linux,code" property.
+  Optional properties:
+    active-high : Change active button level from 0 to 1.
+    enable-reset: Performs hadware reset through PMIC.
+    debounce    : Debounce value which will be taken from PMIC datasheet.
 - regulators : Contain the regulator nodes. The regulators are bound using
   their names as listed below with their registers and bits for enabling.
 
@@ -89,6 +95,13 @@ ecspi at 70010000 { /* ECSPI1 */
 		interrupt-parent = <&gpio0>;
 		interrupts = <8>;
 
+		buttons {
+			button at 1 {
+				linux,code = <0x1f>;
+				debounce = <1>;
+			};
+		};
+
 		regulators {
 			sw1_reg: mc13892__sw1 {
 				regulator-min-microvolt = <600000>;
diff --git a/drivers/input/misc/mc13783-pwrbutton.c b/drivers/input/misc/mc13783-pwrbutton.c
index 855d576..2040eb2 100644
--- a/drivers/input/misc/mc13783-pwrbutton.c
+++ b/drivers/input/misc/mc13783-pwrbutton.c
@@ -24,6 +24,7 @@
 #include <linux/kernel.h>
 #include <linux/errno.h>
 #include <linux/input.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/mfd/mc13783.h>
 #include <linux/mfd/mc13892.h>
@@ -121,21 +122,28 @@ static int __init mc13xxx_pwrbutton_probe(struct platform_device *pdev)
 	struct mc13xxx *mc13xxx = dev_get_drvdata(pdev->dev.parent);
 	struct mc13xxx_pwrb_devtype *devtype =
 		(struct mc13xxx_pwrb_devtype *)pdev->id_entry->driver_data;
+	struct device_node *parent, *child;
 	struct mc13xxx_pwrb *priv;
 	int i, reg = 0, ret = -EINVAL;
 
-	if (!pdata) {
+	of_node_get(pdev->dev.parent->of_node);
+	parent = of_find_node_by_name(pdev->dev.parent->of_node, "buttons");
+	if (!pdata && !parent) {
 		dev_err(&pdev->dev, "Missing platform data\n");
 		return -ENODEV;
 	}
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
-	if (!priv)
-		return -ENOMEM;
+	if (!priv) {
+		ret = -ENOMEM;
+		goto out_node_put;
+	}
 
 	priv->input = devm_input_allocate_device(&pdev->dev);
-	if (!priv->input)
-		return -ENOMEM;
+	if (!priv->input) {
+		ret = -ENOMEM;
+		goto out_node_put;
+	}
 
 	priv->mc13xxx = mc13xxx;
 	priv->devtype = devtype;
@@ -143,15 +151,36 @@ static int __init mc13xxx_pwrbutton_probe(struct platform_device *pdev)
 
 	for (i = 0; i < MAX13XXX_NUM_BUTTONS; i++) {
 		u16 code, invert, reset, debounce;
+		const __be32 *prop;
+		char childname[5];
 
-		if (!(pdata->buttons[i].flags & MC13XXX_BUTTON_ENABLE))
-			continue;
-		code = pdata->buttons[i].keycode;
-		invert = !!(pdata->buttons[i].flags &
-			    MC13XXX_BUTTON_POL_INVERT);
-		reset = !!(pdata->buttons[i].flags &
-			   MC13XXX_BUTTON_RESET_EN);
-		debounce = pdata->buttons[i].flags;
+		if (parent) {
+			sprintf(childname, "button@%i", i + 1);
+			child = of_get_child_by_name(parent, childname);
+			if (!child)
+				continue;
+			prop = of_get_property(child, "linux,code", NULL);
+			if (prop)
+				code = be32_to_cpu(*prop) & 0xffff;
+			else {
+				dev_err(&pdev->dev,
+					"Button %i: Missing key code\n", i + 1);
+				continue;
+			}
+			invert = of_property_read_bool(child, "active-high");
+			reset = of_property_read_bool(child, "enable-reset");
+			prop = of_get_property(child, "debounce", NULL);
+			debounce = prop ? be32_to_cpu(*prop) : 0;
+		} else {
+			if (!(pdata->buttons[i].flags & MC13XXX_BUTTON_ENABLE))
+				continue;
+			code = pdata->buttons[i].keycode;
+			invert = !!(pdata->buttons[i].flags &
+				    MC13XXX_BUTTON_POL_INVERT);
+			reset = !!(pdata->buttons[i].flags &
+				   MC13XXX_BUTTON_RESET_EN);
+			debounce = pdata->buttons[i].flags;
+		}
 
 		priv->btn_code[i] = code;
 		if (code != KEY_RESERVED)
@@ -186,6 +215,10 @@ static int __init mc13xxx_pwrbutton_probe(struct platform_device *pdev)
 	if (ret)
 		dev_err(&pdev->dev, "Can't register input device: %i\n", ret);
 
+out_node_put:
+	if (parent)
+		of_node_put(parent);
+
 	return ret;
 }
 
-- 
1.8.1.5



From shc_work at mail.ru  Sat Jul 13 00:25:49 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 13 Jul 2013 08:25:49 +0400
Subject: [PATCH v2 1/3] input: mc13783: Prepare driver to support MC13892 and
 OF
Message-ID: <1373689551-24375-1-git-send-email-shc_work@mail.ru>

This patch is a preparation mc13xxx powerbutton driver to support
MC13892 and support the probe through the DT.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/mach-imx/mach-mx31moboard.c   |   9 +-
 drivers/input/misc/mc13783-pwrbutton.c | 361 ++++++++++++++-------------------
 include/linux/mfd/mc13xxx.h            |  28 +--
 3 files changed, 173 insertions(+), 225 deletions(-)

diff --git a/arch/arm/mach-imx/mach-mx31moboard.c b/arch/arm/mach-imx/mach-mx31moboard.c
index 6f424ec..2a8aa43 100644
--- a/arch/arm/mach-imx/mach-mx31moboard.c
+++ b/arch/arm/mach-imx/mach-mx31moboard.c
@@ -276,9 +276,12 @@ static struct mc13xxx_leds_platform_data moboard_leds = {
 };
 
 static struct mc13xxx_buttons_platform_data moboard_buttons = {
-	.b1on_flags = MC13783_BUTTON_DBNC_750MS | MC13783_BUTTON_ENABLE |
-			MC13783_BUTTON_POL_INVERT,
-	.b1on_key = KEY_POWER,
+	.buttons[0] = {
+		.keycode	= KEY_POWER,
+		.flags		= MC13XXX_BUTTON_ENABLE |
+				  MC13XXX_BUTTON_DBNC_750MS |
+				  MC13XXX_BUTTON_POL_INVERT,
+	},
 };
 
 static struct mc13xxx_codec_platform_data moboard_codec = {
diff --git a/drivers/input/misc/mc13783-pwrbutton.c b/drivers/input/misc/mc13783-pwrbutton.c
index d0277a7..33613ca 100644
--- a/drivers/input/misc/mc13783-pwrbutton.c
+++ b/drivers/input/misc/mc13783-pwrbutton.c
@@ -24,248 +24,191 @@
 #include <linux/kernel.h>
 #include <linux/errno.h>
 #include <linux/input.h>
-#include <linux/interrupt.h>
 #include <linux/platform_device.h>
 #include <linux/mfd/mc13783.h>
-#include <linux/sched.h>
-#include <linux/slab.h>
-
-struct mc13783_pwrb {
-	struct input_dev *pwr;
-	struct mc13xxx *mc13783;
-#define MC13783_PWRB_B1_POL_INVERT	(1 << 0)
-#define MC13783_PWRB_B2_POL_INVERT	(1 << 1)
-#define MC13783_PWRB_B3_POL_INVERT	(1 << 2)
-	int flags;
-	unsigned short keymap[3];
+
+struct mc13xxx_button_def {
+	unsigned int	irq;
+	unsigned int	sense_bit;
 };
 
-#define MC13783_REG_INTERRUPT_SENSE_1		5
-#define MC13783_IRQSENSE1_ONOFD1S		(1 << 3)
-#define MC13783_IRQSENSE1_ONOFD2S		(1 << 4)
-#define MC13783_IRQSENSE1_ONOFD3S		(1 << 5)
+struct mc13xxx_pwrb_devtype {
+	struct mc13xxx_button_def	btn_def[MAX13XXX_NUM_BUTTONS];
+};
 
-#define MC13783_REG_POWER_CONTROL_2		15
-#define MC13783_POWER_CONTROL_2_ON1BDBNC	4
-#define MC13783_POWER_CONTROL_2_ON2BDBNC	6
-#define MC13783_POWER_CONTROL_2_ON3BDBNC	8
-#define MC13783_POWER_CONTROL_2_ON1BRSTEN	(1 << 1)
-#define MC13783_POWER_CONTROL_2_ON2BRSTEN	(1 << 2)
-#define MC13783_POWER_CONTROL_2_ON3BRSTEN	(1 << 3)
+struct mc13xxx_pwrb {
+	struct mc13xxx_pwrb_devtype	*devtype;
+	unsigned int			enabled;
+	unsigned int			inverted;
+	u16				btn_code[MAX13XXX_NUM_BUTTONS];
+	struct input_dev		*input;
+	struct mc13xxx			*mc13xxx;
+};
 
-static irqreturn_t button_irq(int irq, void *_priv)
-{
-	struct mc13783_pwrb *priv = _priv;
-	int val;
-
-	mc13xxx_irq_ack(priv->mc13783, irq);
-	mc13xxx_reg_read(priv->mc13783, MC13783_REG_INTERRUPT_SENSE_1, &val);
-
-	switch (irq) {
-	case MC13783_IRQ_ONOFD1:
-		val = val & MC13783_IRQSENSE1_ONOFD1S ? 1 : 0;
-		if (priv->flags & MC13783_PWRB_B1_POL_INVERT)
-			val ^= 1;
-		input_report_key(priv->pwr, priv->keymap[0], val);
-		break;
-
-	case MC13783_IRQ_ONOFD2:
-		val = val & MC13783_IRQSENSE1_ONOFD2S ? 1 : 0;
-		if (priv->flags & MC13783_PWRB_B2_POL_INVERT)
-			val ^= 1;
-		input_report_key(priv->pwr, priv->keymap[1], val);
-		break;
-
-	case MC13783_IRQ_ONOFD3:
-		val = val & MC13783_IRQSENSE1_ONOFD3S ? 1 : 0;
-		if (priv->flags & MC13783_PWRB_B3_POL_INVERT)
-			val ^= 1;
-		input_report_key(priv->pwr, priv->keymap[2], val);
-		break;
-	}
+#define MC13XXX_REG_INTERRUPT_SENSE_1	5
+#define MC13XXX_REG_POWER_CONTROL_2	15
 
-	input_sync(priv->pwr);
+static irqreturn_t mc13xxx_pwrbutton_irq(int irq, void *data)
+{
+	struct mc13xxx_pwrb *priv = data;
+	unsigned int i, val;
+
+	mc13xxx_irq_ack(priv->mc13xxx, irq);
+	mc13xxx_reg_read(priv->mc13xxx, MC13XXX_REG_INTERRUPT_SENSE_1, &val);
+ 
+	for (i = 0; i < MAX13XXX_NUM_BUTTONS; i++)
+		if (irq == priv->devtype->btn_def[i].irq) {
+			val = !!(val & priv->devtype->btn_def[i].sense_bit);
+			if (priv->inverted & BIT(i))
+				val = !val;
+			input_report_key(priv->input, priv->btn_code[i], val);
+			input_sync(priv->input);
+			break;
+		}
 
 	return IRQ_HANDLED;
 }
 
-static int mc13783_pwrbutton_probe(struct platform_device *pdev)
+static int mc13xxx_pwrbutton_open(struct input_dev *dev)
 {
-	const struct mc13xxx_buttons_platform_data *pdata;
-	struct mc13xxx *mc13783 = dev_get_drvdata(pdev->dev.parent);
-	struct input_dev *pwr;
-	struct mc13783_pwrb *priv;
-	int err = 0;
-	int reg = 0;
-
-	pdata = dev_get_platdata(&pdev->dev);
-	if (!pdata) {
-		dev_err(&pdev->dev, "missing platform data\n");
-		return -ENODEV;
-	}
-
-	pwr = input_allocate_device();
-	if (!pwr) {
-		dev_dbg(&pdev->dev, "Can't allocate power button\n");
-		return -ENOMEM;
-	}
-
-	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
-	if (!priv) {
-		err = -ENOMEM;
-		dev_dbg(&pdev->dev, "Can't allocate power button\n");
-		goto free_input_dev;
-	}
-
-	reg |= (pdata->b1on_flags & 0x3) << MC13783_POWER_CONTROL_2_ON1BDBNC;
-	reg |= (pdata->b2on_flags & 0x3) << MC13783_POWER_CONTROL_2_ON2BDBNC;
-	reg |= (pdata->b3on_flags & 0x3) << MC13783_POWER_CONTROL_2_ON3BDBNC;
-
-	priv->pwr = pwr;
-	priv->mc13783 = mc13783;
-
-	mc13xxx_lock(mc13783);
-
-	if (pdata->b1on_flags & MC13783_BUTTON_ENABLE) {
-		priv->keymap[0] = pdata->b1on_key;
-		if (pdata->b1on_key != KEY_RESERVED)
-			__set_bit(pdata->b1on_key, pwr->keybit);
-
-		if (pdata->b1on_flags & MC13783_BUTTON_POL_INVERT)
-			priv->flags |= MC13783_PWRB_B1_POL_INVERT;
-
-		if (pdata->b1on_flags & MC13783_BUTTON_RESET_EN)
-			reg |= MC13783_POWER_CONTROL_2_ON1BRSTEN;
-
-		err = mc13xxx_irq_request(mc13783, MC13783_IRQ_ONOFD1,
-					  button_irq, "b1on", priv);
-		if (err) {
-			dev_dbg(&pdev->dev, "Can't request irq\n");
-			goto free_priv;
+	struct mc13xxx_pwrb *priv = input_get_drvdata(dev);
+	int i, ret = 0;
+
+	mc13xxx_lock(priv->mc13xxx);
+
+	for (i = 0; i < MAX13XXX_NUM_BUTTONS; i++)
+		if (priv->enabled & BIT(i)) {
+			ret = mc13xxx_irq_request(priv->mc13xxx,
+						  priv->devtype->btn_def[i].irq,
+						  mc13xxx_pwrbutton_irq, NULL,
+						  priv);
+			if (!ret)
+				continue;
+
+			dev_err(&dev->dev, "Can't request IRQ: %i\n", ret);
+			
+			while (--i >= 0)
+				if (priv->enabled & BIT(i))
+					mc13xxx_irq_free(priv->mc13xxx,
+						 priv->devtype->btn_def[i].irq,
+						 priv);
+			break;
 		}
-	}
-
-	if (pdata->b2on_flags & MC13783_BUTTON_ENABLE) {
-		priv->keymap[1] = pdata->b2on_key;
-		if (pdata->b2on_key != KEY_RESERVED)
-			__set_bit(pdata->b2on_key, pwr->keybit);
 
-		if (pdata->b2on_flags & MC13783_BUTTON_POL_INVERT)
-			priv->flags |= MC13783_PWRB_B2_POL_INVERT;
+	mc13xxx_unlock(priv->mc13xxx);
 
-		if (pdata->b2on_flags & MC13783_BUTTON_RESET_EN)
-			reg |= MC13783_POWER_CONTROL_2_ON2BRSTEN;
-
-		err = mc13xxx_irq_request(mc13783, MC13783_IRQ_ONOFD2,
-					  button_irq, "b2on", priv);
-		if (err) {
-			dev_dbg(&pdev->dev, "Can't request irq\n");
-			goto free_irq_b1;
-		}
-	}
-
-	if (pdata->b3on_flags & MC13783_BUTTON_ENABLE) {
-		priv->keymap[2] = pdata->b3on_key;
-		if (pdata->b3on_key != KEY_RESERVED)
-			__set_bit(pdata->b3on_key, pwr->keybit);
+	return ret;
+}
 
-		if (pdata->b3on_flags & MC13783_BUTTON_POL_INVERT)
-			priv->flags |= MC13783_PWRB_B3_POL_INVERT;
+static void mc13xxx_pwrbutton_close(struct input_dev *dev)
+{
+	struct mc13xxx_pwrb *priv = input_get_drvdata(dev);
+	int i;
+
+	mc13xxx_lock(priv->mc13xxx);
+	for (i = 0; i < MAX13XXX_NUM_BUTTONS; i++)
+		if (priv->enabled & BIT(i))
+			mc13xxx_irq_free(priv->mc13xxx,
+					 priv->devtype->btn_def[i].irq, priv);
+	mc13xxx_unlock(priv->mc13xxx);
+}
 
-		if (pdata->b3on_flags & MC13783_BUTTON_RESET_EN)
-			reg |= MC13783_POWER_CONTROL_2_ON3BRSTEN;
+static int __init mc13xxx_pwrbutton_probe(struct platform_device *pdev)
+{
+	struct mc13xxx_buttons_platform_data *pdata =
+		dev_get_platdata(&pdev->dev);
+	struct mc13xxx *mc13xxx = dev_get_drvdata(pdev->dev.parent);
+	struct mc13xxx_pwrb_devtype *devtype =
+		(struct mc13xxx_pwrb_devtype *)pdev->id_entry->driver_data;
+	struct mc13xxx_pwrb *priv;
+	int i, reg = 0, ret = -EINVAL;
 
-		err = mc13xxx_irq_request(mc13783, MC13783_IRQ_ONOFD3,
-					  button_irq, "b3on", priv);
-		if (err) {
-			dev_dbg(&pdev->dev, "Can't request irq: %d\n", err);
-			goto free_irq_b2;
-		}
+	if (!pdata) {
+		dev_err(&pdev->dev, "Missing platform data\n");
+		return -ENODEV;
 	}
 
-	mc13xxx_reg_rmw(mc13783, MC13783_REG_POWER_CONTROL_2, 0x3FE, reg);
-
-	mc13xxx_unlock(mc13783);
-
-	pwr->name = "mc13783_pwrbutton";
-	pwr->phys = "mc13783_pwrbutton/input0";
-	pwr->dev.parent = &pdev->dev;
-
-	pwr->keycode = priv->keymap;
-	pwr->keycodemax = ARRAY_SIZE(priv->keymap);
-	pwr->keycodesize = sizeof(priv->keymap[0]);
-	__set_bit(EV_KEY, pwr->evbit);
+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
 
-	err = input_register_device(pwr);
-	if (err) {
-		dev_dbg(&pdev->dev, "Can't register power button: %d\n", err);
-		goto free_irq;
-	}
+	priv->input = devm_input_allocate_device(&pdev->dev);
+	if (!priv->input)
+		return -ENOMEM;
 
+	priv->mc13xxx = mc13xxx;
+	priv->devtype = devtype;
 	platform_set_drvdata(pdev, priv);
 
-	return 0;
-
-free_irq:
-	mc13xxx_lock(mc13783);
-
-	if (pdata->b3on_flags & MC13783_BUTTON_ENABLE)
-		mc13xxx_irq_free(mc13783, MC13783_IRQ_ONOFD3, priv);
-
-free_irq_b2:
-	if (pdata->b2on_flags & MC13783_BUTTON_ENABLE)
-		mc13xxx_irq_free(mc13783, MC13783_IRQ_ONOFD2, priv);
-
-free_irq_b1:
-	if (pdata->b1on_flags & MC13783_BUTTON_ENABLE)
-		mc13xxx_irq_free(mc13783, MC13783_IRQ_ONOFD1, priv);
-
-free_priv:
-	mc13xxx_unlock(mc13783);
-	kfree(priv);
-
-free_input_dev:
-	input_free_device(pwr);
+	for (i = 0; i < MAX13XXX_NUM_BUTTONS; i++) {
+		u16 code, invert, reset, debounce;
+
+		if (!(pdata->buttons[i].flags & MC13XXX_BUTTON_ENABLE))
+			continue;
+		code = pdata->buttons[i].keycode;
+		invert = !!(pdata->buttons[i].flags &
+			    MC13XXX_BUTTON_POL_INVERT);
+		reset = !!(pdata->buttons[i].flags &
+			   MC13XXX_BUTTON_RESET_EN);
+		debounce = pdata->buttons[i].flags;
+
+		priv->btn_code[i] = code;
+		if (code != KEY_RESERVED)
+			__set_bit(code, priv->input->keybit);
+
+		priv->enabled |= BIT(i);
+		priv->inverted |= invert << i;
+		reg |= reset << (i + 1);
+		reg |= (debounce & 0x03) << (4 + i * 2);
+	}
 
-	return err;
+	mc13xxx_lock(mc13xxx);
+	mc13xxx_reg_rmw(mc13xxx, MC13XXX_REG_POWER_CONTROL_2, 0x3fe, reg);
+	mc13xxx_unlock(mc13xxx);
+
+	priv->input->name		= "mc13xxx_pwrbutton";
+	priv->input->phys		= "mc13xxx_pwrbutton/input0";
+	priv->input->id.bustype		= BUS_HOST;
+	priv->input->id.vendor		= 0x0001;
+	priv->input->id.product		= 0x0001;
+	priv->input->id.version		= 0x0100;
+	priv->input->keycode		= priv->btn_code;
+	priv->input->keycodemax		= ARRAY_SIZE(priv->btn_code);
+	priv->input->keycodesize	= sizeof(priv->btn_code[0]);
+	priv->input->open		= mc13xxx_pwrbutton_open;
+	priv->input->close		= mc13xxx_pwrbutton_close;
+	__set_bit(EV_KEY, priv->input->evbit);
+
+	input_set_drvdata(priv->input, priv);
+
+	ret = input_register_device(priv->input);
+	if (ret)
+		dev_err(&pdev->dev, "Can't register input device: %i\n", ret);
+
+	return ret;
 }
 
-static int mc13783_pwrbutton_remove(struct platform_device *pdev)
-{
-	struct mc13783_pwrb *priv = platform_get_drvdata(pdev);
-	const struct mc13xxx_buttons_platform_data *pdata;
-
-	pdata = dev_get_platdata(&pdev->dev);
-
-	mc13xxx_lock(priv->mc13783);
-
-	if (pdata->b3on_flags & MC13783_BUTTON_ENABLE)
-		mc13xxx_irq_free(priv->mc13783, MC13783_IRQ_ONOFD3, priv);
-	if (pdata->b2on_flags & MC13783_BUTTON_ENABLE)
-		mc13xxx_irq_free(priv->mc13783, MC13783_IRQ_ONOFD2, priv);
-	if (pdata->b1on_flags & MC13783_BUTTON_ENABLE)
-		mc13xxx_irq_free(priv->mc13783, MC13783_IRQ_ONOFD1, priv);
-
-	mc13xxx_unlock(priv->mc13783);
-
-	input_unregister_device(priv->pwr);
-	kfree(priv);
+static const struct mc13xxx_pwrb_devtype mc13783_pwrb_devtype = {
+	.btn_def[0] = { MC13783_IRQ_ONOFD1, BIT(3) },
+	.btn_def[1] = { MC13783_IRQ_ONOFD2, BIT(4) },
+	.btn_def[2] = { MC13783_IRQ_ONOFD3, BIT(5) }
+};
 
-	return 0;
-}
+static const struct platform_device_id mc13xxx_pwrbutton_id_table[] = {
+	{ "mc13783-pwrbutton", (kernel_ulong_t)&mc13783_pwrb_devtype },
+	{ }
+};
+MODULE_DEVICE_TABLE(platform, mc13xxx_pwrbutton_id_table);
 
-static struct platform_driver mc13783_pwrbutton_driver = {
-	.probe		= mc13783_pwrbutton_probe,
-	.remove		= mc13783_pwrbutton_remove,
-	.driver		= {
-		.name	= "mc13783-pwrbutton",
+static struct platform_driver mc13xxx_pwrbutton_driver = {
+	.driver	= {
+		.name	= "mc13xxx-pwrbutton",
 		.owner	= THIS_MODULE,
 	},
+	.id_table	= mc13xxx_pwrbutton_id_table,
 };
+module_platform_driver_probe(mc13xxx_pwrbutton_driver, mc13xxx_pwrbutton_probe);
 
-module_platform_driver(mc13783_pwrbutton_driver);
-
-MODULE_ALIAS("platform:mc13783-pwrbutton");
 MODULE_DESCRIPTION("MC13783 Power Button");
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Philippe Retornaz");
diff --git a/include/linux/mfd/mc13xxx.h b/include/linux/mfd/mc13xxx.h
index 41ed592..b895538 100644
--- a/include/linux/mfd/mc13xxx.h
+++ b/include/linux/mfd/mc13xxx.h
@@ -142,20 +142,22 @@ struct mc13xxx_leds_platform_data {
 	u32 led_control[MAX_LED_CONTROL_REGS];
 };
 
+#define MAX13XXX_NUM_BUTTONS	3
+
+struct mc13xxx_button {
+	u16		keycode;
+	unsigned int	flags;
+#define MC13XXX_BUTTON_DBNC_0MS		0
+#define MC13XXX_BUTTON_DBNC_30MS	1
+#define MC13XXX_BUTTON_DBNC_150MS	2
+#define MC13XXX_BUTTON_DBNC_750MS	3
+#define MC13XXX_BUTTON_ENABLE		(1 << 2)
+#define MC13XXX_BUTTON_POL_INVERT	(1 << 3)
+#define MC13XXX_BUTTON_RESET_EN		(1 << 4)
+};
+
 struct mc13xxx_buttons_platform_data {
-#define MC13783_BUTTON_DBNC_0MS		0
-#define MC13783_BUTTON_DBNC_30MS	1
-#define MC13783_BUTTON_DBNC_150MS	2
-#define MC13783_BUTTON_DBNC_750MS	3
-#define MC13783_BUTTON_ENABLE		(1 << 2)
-#define MC13783_BUTTON_POL_INVERT	(1 << 3)
-#define MC13783_BUTTON_RESET_EN		(1 << 4)
-	int b1on_flags;
-	unsigned short b1on_key;
-	int b2on_flags;
-	unsigned short b2on_key;
-	int b3on_flags;
-	unsigned short b3on_key;
+	struct mc13xxx_button	buttons[MAX13XXX_NUM_BUTTONS];
 };
 
 struct mc13xxx_ts_platform_data {
-- 
1.8.1.5



From shc_work at mail.ru  Sat Jul 13 00:30:57 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 13 Jul 2013 08:30:57 +0400
Subject: [PATCH v2] ARM: dts: i.MX51: Add WEIM node
Message-ID: <1373689857-24481-1-git-send-email-shc_work@mail.ru>

This patch adds the missing (Wireless External Interface Module) WEIM
devicetree node for i.MX51 CPUs.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx51.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index fb5c2c3..d086e07 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -746,6 +746,23 @@
 				status = "disabled";
 			};
 
+			weim: weim at 83fda000 {
+				#address-cells = <2>;
+				#size-cells = <1>;
+				compatible = "fsl,imx51-weim";
+				reg = <0x83fda000 0x1000>;
+				clocks = <&clks 57>;
+				ranges = <
+					0 0 0xb0000000 0x08000000
+					1 0 0xb8000000 0x08000000
+					2 0 0xc0000000 0x08000000
+					3 0 0xc8000000 0x04000000
+					4 0 0xcc000000 0x02000000
+					5 0 0xce000000 0x02000000
+				>;
+				status = "disabled";
+			};
+
 			nfc: nand at 83fdb000 {
 				compatible = "fsl,imx51-nand";
 				reg = <0x83fdb000 0x1000 0xcfff0000 0x10000>;
-- 
1.8.1.5



From shc_work at mail.ru  Sat Jul 13 00:34:44 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 13 Jul 2013 08:34:44 +0400
Subject: [PATCH] ARM: dts: imx27: Add core voltages
Message-ID: <1373690084-26760-1-git-send-email-shc_work@mail.ru>

This patch adds core voltages for i.MX27 CPUs. Only 266 and 400 MHz modes
is documented in the datasheet, so we add a 266 MHz frequency for conform this.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27.dtsi | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index 056e33b..56b8c97 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -57,13 +57,14 @@
 			device_type = "cpu";
 			compatible = "arm,arm926ej-s";
 			operating-points = <
-				/* kHz  uV (No regulator support) */
-				133000  0
-				399000  0
+				/* kHz uV */
+				266000 1300000
+				399000 1450000
 			>;
 			clock-latency = <61036>; /* two CLK32 periods */
 			clocks = <&clks 18>;
 			clock-names = "cpu";
+			voltage-tolerance = <5>;
 		};
 	};
 
-- 
1.8.1.5



From dmitry.torokhov at gmail.com  Sat Jul 13 02:46:38 2013
From: dmitry.torokhov at gmail.com (Dmitry Torokhov)
Date: Fri, 12 Jul 2013 23:46:38 -0700
Subject: [PATCH v2 1/3] input: mc13783: Prepare driver to support MC13892
 and OF
In-Reply-To: <1373689551-24375-1-git-send-email-shc_work@mail.ru>
References: <1373689551-24375-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130713064638.GB20979@core.coreip.homeip.net>

Hi Alexander,

On Sat, Jul 13, 2013 at 08:25:49AM +0400, Alexander Shiyan wrote:
> +
> +	for (i = 0; i < MAX13XXX_NUM_BUTTONS; i++)
> +		if (priv->enabled & BIT(i)) {
> +			ret = mc13xxx_irq_request(priv->mc13xxx,
> +						  priv->devtype->btn_def[i].irq,
> +						  mc13xxx_pwrbutton_irq, NULL,
> +						  priv);
> +			if (!ret)
> +				continue;

I'd rather we continued requesting interrupts in probe() as opposed to
open(). I believe the driver should acquire all resources it needs when
binding, instead of later.

Thanks.

-- 
Dmitry


From olof at lixom.net  Sat Jul 13 02:46:58 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 12 Jul 2013 23:46:58 -0700
Subject: [PATCH] arm: multi_v7_defconfig: Tweaks for omap and sunxi
In-Reply-To: <51E0CEA8.2040201@elopez.com.ar>
References: <1373685174-7918-1-git-send-email-olof@lixom.net>
 <51E0CEA8.2040201@elopez.com.ar>
Message-ID: <CAOesGMjzhfQwhxDQv7ETAqu_fzE7WLzy-ydoxFWjLpcFpPeajw@mail.gmail.com>

On Fri, Jul 12, 2013 at 8:51 PM, Emilio L?pez <emilio at elopez.com.ar> wrote:
> Hi Olof,
>
> El 13/07/13 00:12, Olof Johansson escribi?:
>> OMAP recently changed how the platforms are configured, so OMAP2/3/4 SoC
>> support is no longer enabled by default. Add them back.
>>
>> Enable new ethernet driver for sunxi.
>
> "ARM: multi_v7: Enable Allwinner EMAC in multi_v7_defconfig" by Maxime
> already does this, and is on Linus Torvalds' tree:
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fb1c60288a886a28dc7c055449fd1936140fe891

No, it's been effectively reverted due to the driver not being in the
tree by the time the patch was merged, so if anyone ran savedefconfig
inbetween (which I did), the option was removed.

>> The i.MX console options moved due to resorting, no functional change.
>>
>> Signed-off-by: Olof Johansson <olof at lixom.net>
>> ---
>>
>> The OMAP changes are needed to deal with the dependency flip from OMAP2PLUS
>> being on and defaulting the SoCs accordingly, to the SoC options selecting
>> OMAP2PLUS. See the "ARM: OMAP2+: Remove board-4430sdp.c" for background.
>>
>>  arch/arm/configs/multi_v7_defconfig | 9 ++++++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>> index 80aacc6..fcd2b9b 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -15,8 +15,10 @@ CONFIG_SOC_IMX53=y
>>  CONFIG_SOC_IMX6Q=y
>>  CONFIG_SOC_IMX6SL=y
>>  CONFIG_SOC_VF610=y
>> -CONFIG_ARCH_OMAP2PLUS=y
>> +CONFIG_ARCH_OMAP3=y
>> +CONFIG_ARCH_OMAP4=y
>>  CONFIG_SOC_OMAP5=y
>> +CONFIG_SOC_AM33XX=y
>>  CONFIG_SOC_AM43XX=y
>>  CONFIG_ARCH_ROCKCHIP=y
>>  CONFIG_ARCH_SOCFPGA=y
>> @@ -57,6 +59,7 @@ CONFIG_SATA_AHCI_PLATFORM=y
>>  CONFIG_SATA_HIGHBANK=y
>>  CONFIG_SATA_MV=y
>>  CONFIG_NETDEVICES=y
>> +CONFIG_SUN4I_EMAC=y
>
> Additionally, this patch is missing CONFIG_MDIO_SUN4I=y, which I think
> would be needed to make CONFIG_SUN4I_EMAC=y of any use. Maybe a Kconfig
> select would be a good idea here?

Yes, likely. I can turn it on in the defconfig (I'll revise the
patch), but independent of that there should probably be a select for
the future.


-Olof


From moinejf at free.fr  Sat Jul 13 04:35:16 2013
From: moinejf at free.fr (Jean-Francois Moine)
Date: Sat, 13 Jul 2013 10:35:16 +0200
Subject: DT binding review for Armada display subsystem
In-Reply-To: <CAMLZHHT1oAvOLe3JgQqMqLNXEr0NGrdtgELtF_djbqLFceHtiQ@mail.gmail.com>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <20130712203952.6b7aa927@armhf>
 <CAMLZHHT1oAvOLe3JgQqMqLNXEr0NGrdtgELtF_djbqLFceHtiQ@mail.gmail.com>
Message-ID: <20130713103516.38a55b0b@armhf>

On Fri, 12 Jul 2013 13:00:23 -0600
Daniel Drake <dsd at laptop.org> wrote:

> On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine <moinejf at free.fr> wrote:
> > - the phandles to the clocks does not tell how the clock may be set by
> >   the driver (it is an array index in the 510).  
> 
> In the other threads on clock selection, we decided that that exact
> information on how to select a clock (i.e. register bits/values) must
> be in the driver, not in the DT. What was suggested there is a
> well-documented scheme for clock naming, so the driver knows which
> clock is which. That is defined in the proposed DT binding though the
> "valid clock names" part. For an example driver implementation of this
> you can see my patch "armada_drm clock selection - try 2".

OK.

Sorry to go back to this thread.

I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
modules. I set 3 clocks in the DT for the LCD0: lcdclk, axi and extclk0
(si5351). Normally, the external clock is used, but, sometimes, the
si5351 module is not yet initialized when the drm driver starts. So,
for 1920x1080p, it uses the lcdclk which sets the LCD clock to 133333
(400000/3) instead of 148500. As a result, display and sound still work
correctly on my TV set thru HDMI.

So, it would be nice to have 2 usable clocks per LCD, until we find a
good way to initialize the modules in the right order at startup time.

> > - I don't see the use of the phandles in the leaves (dcon and tda998x).  
> 
> That is defined by the video interfaces common binding. I'm not
> immediately aware of the use, but the ability to easily traverse the
> graph in both directions seems like a requirement that could easily
> emerge from somewhere.

OK, but I am not convinced...

> > Well, here is how I feel the DTs:
> >
> > - for the Cubox (one LCD, the DCON is not used, TDA998x for HDMI/DVI
> >   output):  
> 
> That is the same as my proposal except you have decided to use direct
> phandle properties instead of using the common video interfaces
> binding (which is just a slightly more detailed way of describing such
> links). In the "best practices" thread, the suggestion was raised
> multiple times of doing what v4l2 does, so thats why I decided to
> explore this here.
> 
> > - for some tablet based on the Armada 510 with a LCD and a VGA connector:
> >
> >         video {
> >                 compatible = "marvell,armada-video";
> >                 marvell,video-devices = <&lcd0>, <&lcd1>, <&dcon>
> >         };  
> 
> This proposal is slightly different because it does not describe the
> relationship between the LCD controllers and the DCON. Focusing
> specifically on LCD1, which would be connected to a DAC via a phandle
> property in your proposal. The interconnectivity between the
> components represented as a graph (and in the v4l2 way, which includes
> my proposal) would be:
> 
> LCD1 --- DCON --- DAC
> 
> However your phandle properties would "suggest" that LCD1 is directly
> connected to the DAC. The driver would have to have special knowledge
> that the DCON sits right in the middle. Maybe that is not an issue, as
> it is obviously OK for the driver to have *some* knowledge about how
> the hardware works :)
> 
> I don't think we have a full consensus on whether we want to go the
> "v4l2 way" here. But I figured that would be a good thing to propose
> in a first iteration to have a clearer idea of what the result would
> look like. It sounds like you are not overly keen on it, I would be
> interested to hear exactly why.

I think this is because I was focused on the software and not on the
hardware.

Back to the specific case of the Cubox with new ideas.

The Cubox is based on the Armada 510 (Dove), so, all the hardware must
be described in dove.dtsi. This includes the LCDs and DCON/IRE, the
possible clocks and the (static) v4l2 links:

	lcd0: lcd-controller at 820000 {
		compatible = "marvell,dove-lcd0";
		reg = <0x820000 0x1c8>;
		interrupts = <47>;
		clocks = <&core_clk 3>, <&lcdclk>;
		clock-names = "axi", "lcdclk";
		marvell-output = <&dcon 0>;
		status = "disabled";
	};

	lcd1: lcd-controller at 810000 {
		compatible = "marvell,dove-lcd1";
		reg = <0x810000 0x1c8>;
		interrupts = <46>;
		clocks = <&core_clk 3>, <&lcdclk>;
		clock-names = "axi", "lcdclk";
		marvell-output = <&dcon 1>;
		status = "disabled";
	};

	/* display controller and image rotation engine */
	dcon: display-controller at 830000 {
		compatible = "marvell,dove-dcon";
		reg = <0x830000 0xc4>,			/* DCON */
		      <0x831000 0x8c>;			/* IRE */
		interrupts = <45>;
		marvell-input = <&lcd0>, <&lcd1>;
		status = "disabled";
	};

The specific Cubox hardware (tda998x and si5351) is described in
dove-cubox.dts, with the new clocks and the v4l2 link dcon0 <--> tda998x.

	&i2c0 {
		si5351: clock-generator {
			...
		};
		tda998x: hdmi-encoder {
			compatible = "nxp,tda998x";
			reg = <0x70>;
			interrupt-parent = <&gpio0>;
			interrupts = <27 2>;		/* falling edge */
			marvell-input = <&dcon 0>;
		};
	};
	&lcd0 {
		status = "okay";
		clocks = <&si5351 0>;
		clock-names = "extclk0";
	};
	&dcon {
		status = "okay";
		marvell-output = <&tda998x>, 0;		/* no connector on port B */
	};

Then, about the software, the drm driver may not need to know anything
more (it scans the DT for the LCDs and gets all the subdevices thanks
to the v4l2 links):

	video {
		compatible = "marvell,armada-video";
	};

For some boards / other SoCs, there may be independant drm devices. In
this case, there would be descriptions as:

	video0 {
		compatible = "marvell,armada-video0";
		marvell,video-devices = <&lcd0>;
	};
	video1 {
		compatible = "marvell,armada-video1";
		marvell,video-devices = <&lcd1>;
	};

About the LCD clocks, the drm driver may choose itself one of the
clocks declared in the DT. If a clock should not be used, if should be
zeroed in the board specific DT:

	&lcd0 {
		status = "okay";
		clocks = 0, 0, <&si5351 0>;
		clock-names = "axi", "lcdclk", "extclk0";
	};

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/


From samuel.thibault at ens-lyon.org  Sat Jul 13 05:35:52 2013
From: samuel.thibault at ens-lyon.org (Samuel Thibault)
Date: Sat, 13 Jul 2013 11:35:52 +0200
Subject: [PATCH] Route kbd LEDs through the generic LEDs layer
In-Reply-To: <20130712233301.GA3646@amd.pavel.ucw.cz>
References: <20110102090935.GV32469@atrey.karlin.mff.cuni.cz>
 <20110102103210.GA25662@core.coreip.homeip.net>
 <20110102225741.GX5480@const.famille.thibault.fr>
 <20110112182702.GA9168@core.coreip.homeip.net>
 <20111114040613.GA4992@type.famille.thibault.fr>
 <20121221003449.GA6999@type.youpi.perso.aquilenet.fr>
 <20130707101028.GD5651@type.youpi.perso.aquilenet.fr>
 <20130712113655.GA4227@amd.pavel.ucw.cz>
 <20130712124242.GA5876@type>
 <20130712233301.GA3646@amd.pavel.ucw.cz>
Message-ID: <20130713093552.GU8252@type>

Pavel Machek, le Sat 13 Jul 2013 01:33:01 +0200, a ?crit :
> > > > This permits to reassign keyboard LEDs to something else than keyboard "leds"
> > > > state, by adding keyboard led and modifier triggers connected to a series
> > > > of VT input LEDs, themselves connected to VT input triggers, which
> > > > per-input device LEDs use by default.  Userland can thus easily change the LED
> > > > behavior of (a priori) all input devices, or of particular input devices.
> > > 
> > > Nice! Leds now have proper /sys interface.
> > > 
> > > But... I boot up, switch from X to console, press capslock, and no
> > > reaction anywhere.
> > 
> > Is it working without the patch?  Console-setup for instance is known to
> > have broken the capslock LED, which is precisely one of the reasons for
> > this patch, which will provide console-setup with a way to bring back
> > caps lock working properly.
> 
> You are right, it was broken before.

Ok. You then may want fix your setup by configuring your caps lock led
the way console-setup will be supposed to do in the future:

echo ctrlllock > /sys/class/leds/vt::capsl/trigger

Or some other of the locks that console-setup might be using to
implement caps lock.

> > Things work fine with my USB keyboard too, is this perhaps using an odd
> > driver which would not expose LEDs in a standard way?
> 
> No, everything works as well as it did. Feel free to add:
> 
> Tested-by: Pavel Machek <pavel at ucw.cz>

Thanks for testing,
Samuel


From sylvester.nawrocki at gmail.com  Sat Jul 13 06:56:50 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Sat, 13 Jul 2013 12:56:50 +0200
Subject: DT binding review for Armada display subsystem
In-Reply-To: <20130713103516.38a55b0b@armhf>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <20130712203952.6b7aa927@armhf>
 <CAMLZHHT1oAvOLe3JgQqMqLNXEr0NGrdtgELtF_djbqLFceHtiQ@mail.gmail.com>
 <20130713103516.38a55b0b@armhf>
Message-ID: <51E13272.5040903@gmail.com>

On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
> On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake<dsd at laptop.org>  wrote:
>> On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine<moinejf at free.fr>  wrote:

>>> - the phandles to the clocks does not tell how the clock may be set by
>>>    the driver (it is an array index in the 510).
>>
>> In the other threads on clock selection, we decided that that exact
>> information on how to select a clock (i.e. register bits/values) must
>> be in the driver, not in the DT. What was suggested there is a
>> well-documented scheme for clock naming, so the driver knows which
>> clock is which. That is defined in the proposed DT binding though the
>> "valid clock names" part. For an example driver implementation of this
>> you can see my patch "armada_drm clock selection - try 2".
>
> OK.
>
> Sorry to go back to this thread.
>
> I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
> driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
> modules. I set 3 clocks in the DT for the LCD0: lcdclk, axi and extclk0

Hmm, a bit off topic question, does it work when the si5351 module gets
removed ? I can't see anything preventing clock provider module from being
removed why any of its clocks is used and clk_unregister() function is
currently unimplemented.

> (si5351). Normally, the external clock is used, but, sometimes, the
> si5351 module is not yet initialized when the drm driver starts. So,
> for 1920x1080p, it uses the lcdclk which sets the LCD clock to 133333
> (400000/3) instead of 148500. As a result, display and sound still work
> correctly on my TV set thru HDMI.
>
> So, it would be nice to have 2 usable clocks per LCD, until we find a
> good way to initialize the modules in the right order at startup time.

Doesn't deferred probing help here ?

>>> - I don't see the use of the phandles in the leaves (dcon and tda998x).
>>
>> That is defined by the video interfaces common binding. I'm not
>> immediately aware of the use, but the ability to easily traverse the
>> graph in both directions seems like a requirement that could easily
>> emerge from somewhere.
>
> OK, but I am not convinced...
>
>>> Well, here is how I feel the DTs:
>>>
>>> - for the Cubox (one LCD, the DCON is not used, TDA998x for HDMI/DVI
>>>    output):
>>
>> That is the same as my proposal except you have decided to use direct
>> phandle properties instead of using the common video interfaces
>> binding (which is just a slightly more detailed way of describing such
>> links). In the "best practices" thread, the suggestion was raised
>> multiple times of doing what v4l2 does, so thats why I decided to
>> explore this here.
>>
>>> - for some tablet based on the Armada 510 with a LCD and a VGA connector:
>>>
>>>          video {
>>>                  compatible = "marvell,armada-video";
>>>                  marvell,video-devices =<&lcd0>,<&lcd1>,<&dcon>
>>>          };
>>
>> This proposal is slightly different because it does not describe the
>> relationship between the LCD controllers and the DCON. Focusing
>> specifically on LCD1, which would be connected to a DAC via a phandle
>> property in your proposal. The interconnectivity between the
>> components represented as a graph (and in the v4l2 way, which includes
>> my proposal) would be:
>>
>> LCD1 --- DCON --- DAC
>>
>> However your phandle properties would "suggest" that LCD1 is directly
>> connected to the DAC. The driver would have to have special knowledge
>> that the DCON sits right in the middle. Maybe that is not an issue, as
>> it is obviously OK for the driver to have *some* knowledge about how
>> the hardware works :)
>>
>> I don't think we have a full consensus on whether we want to go the
>> "v4l2 way" here. But I figured that would be a good thing to propose
>> in a first iteration to have a clearer idea of what the result would
>> look like. It sounds like you are not overly keen on it, I would be
>> interested to hear exactly why.
>
> I think this is because I was focused on the software and not on the
> hardware.
>
> Back to the specific case of the Cubox with new ideas.
>
> The Cubox is based on the Armada 510 (Dove), so, all the hardware must
> be described in dove.dtsi. This includes the LCDs and DCON/IRE, the
> possible clocks and the (static) v4l2 links:
>
> 	lcd0: lcd-controller at 820000 {
> 		compatible = "marvell,dove-lcd0";
[...]
> 	};
>
> 	lcd1: lcd-controller at 810000 {
> 		compatible = "marvell,dove-lcd1";
[...]
> 	};

Using different compatible strings to indicate multiple instances of same
hardware doesn't seem right. Unless LCD0, LCD1 are really different pieces
of hardware incompatible with each other I think it would be more correct
to use same compatible property and DT node aliases, similarly as is now
done with e.g. I2C busses:

	aliases {
		lcd0 = &lcd_0;	
		lcd1 = &lcd_1;	
	};

  	lcd_0: lcd-controller at 820000 {
  		compatible = "marvell,dove-lcd";
		...
  	};


  	lcd_1: lcd-controller at 820000 {
  		compatible = "marvell,dove-lcd";
		...
  	};


> 	/* display controller and image rotation engine */
> 	dcon: display-controller at 830000 {
> 		compatible = "marvell,dove-dcon";
> 		reg =<0x830000 0xc4>,			/* DCON */
> 		<0x831000 0x8c>;			/* IRE */
> 		interrupts =<45>;
> 		marvell-input =<&lcd0>,<&lcd1>;
> 		status = "disabled";
> 	};
>
> The specific Cubox hardware (tda998x and si5351) is described in
> dove-cubox.dts, with the new clocks and the v4l2 link dcon0<-->  tda998x.
>
> 	&i2c0 {
> 		si5351: clock-generator {
> 			...
> 		};
> 		tda998x: hdmi-encoder {
> 			compatible = "nxp,tda998x";
> 			reg =<0x70>;
> 			interrupt-parent =<&gpio0>;
> 			interrupts =<27 2>;		/* falling edge */
> 			marvell-input =<&dcon 0>;
> 		};
> 	};
> 	&lcd0 {
> 		status = "okay";
> 		clocks =<&si5351 0>;
> 		clock-names = "extclk0";
> 	};
> 	&dcon {
> 		status = "okay";
> 		marvell-output =<&tda998x>, 0;		/* no connector on port B */

Hmm, was this custom binding intended or did you mean rather something
like:

  	&i2c0 {
  		si5351: clock-generator {
  			...
  		};
  		tda998x: hdmi-encoder {
  			compatible = "nxp,tda998x";
  			reg =<0x70>;
  			interrupt-parent =<&gpio0>;
  			interrupts =<27 2>;		/* falling edge */
  			marvell-input =<&dcon 0>;

			port at I {
				reg = <I>; /* input (or reg omitted completely) */
				endpoint {
					remote-endpoint = <&dcon>;
				};
			}
  		};
  	};
  	&lcd0 {
  		status = "okay";
  		clocks =<&si5351 0>;
  		clock-names = "extclk0";
  	};
  	&dcon {
  		status = "okay";
			
		port at A {
			reg = <A>; /* port A */
			endpoint {
				remote-endpoint = <&tda998x>;
			};
		}
		/* no connector on port B */
  	};

I think it should be tried to use common binding for common problems,
then a common parser library could be used, instead of repeating similar
code in each driver.

> 	};
>
> Then, about the software, the drm driver may not need to know anything
> more (it scans the DT for the LCDs and gets all the subdevices thanks
> to the v4l2 links):
>
> 	video {
> 		compatible = "marvell,armada-video";
> 	};
>
> For some boards / other SoCs, there may be independant drm devices. In
> this case, there would be descriptions as:
>
> 	video0 {
> 		compatible = "marvell,armada-video0";
> 		marvell,video-devices =<&lcd0>;
> 	};
> 	video1 {
> 		compatible = "marvell,armada-video1";
> 		marvell,video-devices =<&lcd1>;
> 	};
>
> About the LCD clocks, the drm driver may choose itself one of the
> clocks declared in the DT. If a clock should not be used, if should be
> zeroed in the board specific DT:
>
> 	&lcd0 {
> 		status = "okay";
> 		clocks = 0, 0,<&si5351 0>;
> 		clock-names = "axi", "lcdclk", "extclk0";
> 	};

Hmm, not sure how that could work. IIUC there should be same number
of cells used in the clocks property for each clock specifier (clocks
provider's node #clock-cells), so &si5351 cell would need to be at
offset 4. Maybe there is some convention to specify null phandles but
I'm not aware of it.

--
Regards,
Sylwester


From linux at arm.linux.org.uk  Sat Jul 13 07:12:39 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 13 Jul 2013 12:12:39 +0100
Subject: DT binding review for Armada display subsystem
In-Reply-To: <51E13272.5040903@gmail.com>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <20130712203952.6b7aa927@armhf>
 <CAMLZHHT1oAvOLe3JgQqMqLNXEr0NGrdtgELtF_djbqLFceHtiQ@mail.gmail.com>
 <20130713103516.38a55b0b@armhf> <51E13272.5040903@gmail.com>
Message-ID: <20130713111239.GM24642@n2100.arm.linux.org.uk>

On Sat, Jul 13, 2013 at 12:56:50PM +0200, Sylwester Nawrocki wrote:
> On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
>> On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake<dsd at laptop.org>  wrote:
>>> On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine<moinejf at free.fr>  wrote:
>
>>>> - the phandles to the clocks does not tell how the clock may be set by
>>>>    the driver (it is an array index in the 510).
>>>
>>> In the other threads on clock selection, we decided that that exact
>>> information on how to select a clock (i.e. register bits/values) must
>>> be in the driver, not in the DT. What was suggested there is a
>>> well-documented scheme for clock naming, so the driver knows which
>>> clock is which. That is defined in the proposed DT binding though the
>>> "valid clock names" part. For an example driver implementation of this
>>> you can see my patch "armada_drm clock selection - try 2".
>>
>> OK.
>>
>> Sorry to go back to this thread.
>>
>> I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
>> driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
>> modules. I set 3 clocks in the DT for the LCD0: lcdclk, axi and extclk0
>
> Hmm, a bit off topic question, does it work when the si5351 module gets
> removed ? I can't see anything preventing clock provider module from being
> removed why any of its clocks is used and clk_unregister() function is
> currently unimplemented.

When I designed the clk API, I arranged for things like clk_get() to
take a reference on the module if the clock was supplied by a module.
You'll see some evidence of that by looking back in the git history
for arch/arm/mach-integrator/include/mach/clkdev.h.

If the common clk API has been designed without any thought to clocks
supplied by modules and making sure that in-use clocks don't go away,
then it's going to be a real pain to sort that out.  I don't think
refcounting clocks makes sense (what do you do with an enabled clock
that you then remove the module for but it's still being used?  Do you
just shut it down anyway?  Do you leave it running?  What about
subsequent calls?).

I think this is one case where taking a reference on the module supplying
it makes total sense.

>> (si5351). Normally, the external clock is used, but, sometimes, the
>> si5351 module is not yet initialized when the drm driver starts. So,
>> for 1920x1080p, it uses the lcdclk which sets the LCD clock to 133333
>> (400000/3) instead of 148500. As a result, display and sound still work
>> correctly on my TV set thru HDMI.
>>
>> So, it would be nice to have 2 usable clocks per LCD, until we find a
>> good way to initialize the modules in the right order at startup time.
>
> Doesn't deferred probing help here ?

Indeed it does.  Just because one TV works with such a wrong clock does not
mean that all TVs and HDMI compatible monitors will do.  It's 11% out.

The reason that audio works is because of the way the HDMI transmitter works
- it can calculate the CTS value to send (by measuring it) and it sends that
value over the link so the TV can regenerate the correct audio clock from
the HDMI clock.

Whether that's going to be universally true, I don't know - it depends on
how much audio data gets sent via each frame.  As the HDMI clock is slower,
there would need to be more audio data sent.

>> 	lcd0: lcd-controller at 820000 {
>> 		compatible = "marvell,dove-lcd0";
> [...]
>> 	};
>>
>> 	lcd1: lcd-controller at 810000 {
>> 		compatible = "marvell,dove-lcd1";
> [...]
>> 	};
>
> Using different compatible strings to indicate multiple instances of same
> hardware doesn't seem right. Unless LCD0, LCD1 are really different pieces

They aren't.  They're 100% identical in the Armada 510.

> of hardware incompatible with each other I think it would be more correct
> to use same compatible property and DT node aliases, similarly as is now
> done with e.g. I2C busses:
>
> 	aliases {
> 		lcd0 = &lcd_0;	
> 		lcd1 = &lcd_1;	
> 	};
>
>  	lcd_0: lcd-controller at 820000 {
>  		compatible = "marvell,dove-lcd";

I'd much prefer marvell,armada-510-lcd rather than using the codenames for
the devices.  Otherwise we're going to run into totally different things
being used for different devices (eg, armada-xp...)


From pavel at ucw.cz  Sat Jul 13 08:17:09 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Sat, 13 Jul 2013 14:17:09 +0200
Subject: [PATCH v2] N900: add device tree
In-Reply-To: <20130704203256.GB27374@blackmetal.musicnaut.iki.fi>
References: <20130613155240.GB3775@amd.pavel.ucw.cz>
 <20130613161418.GJ8164@atomide.com>
 <20130613230808.GA14876@amd.pavel.ucw.cz>
 <20130614055629.GM8164@atomide.com>
 <20130614212816.GA31768@atrey.karlin.mff.cuni.cz>
 <20130617111031.GQ20992@atomide.com>
 <20130701211753.GC15318@amd.pavel.ucw.cz>
 <20130704171939.GA27374@blackmetal.musicnaut.iki.fi>
 <20130704202145.GB10752@amd.pavel.ucw.cz>
 <20130704203256.GB27374@blackmetal.musicnaut.iki.fi>
Message-ID: <20130713121709.GC16473@amd.pavel.ucw.cz>


This adds device tree with neccessary support to boot with functional
video (on both emulator and real N900 device).

Signed-off-by: Pavel Machek <pavel at ucw.cz>

---

>From v1: Aaro wants just GPLv2, so I did that. I re-enabled parts that
can be enabled on 3.10, and tested it on that kernel.

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f0895c5..1950aed 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -141,6 +141,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
 	omap3-devkit8000.dtb \
 	omap3-beagle-xm.dtb \
 	omap3-evm.dtb \
+	omap3-n900.dtb \
 	omap3-tobi.dtb \
 	omap3-igep0020.dtb \
 	omap3-igep0030.dtb \
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
new file mode 100644
index 0000000..fb461bf
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2013 Pavel Machek <pavel at ucw.cz>
+ * Copyright 2013 Aaro Koskinen <aaro.koskinen at iki.fi>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+/include/ "omap34xx.dtsi"
+
+/ {
+	model = "Nokia N900";
+	compatible = "nokia,omap3-n900", "ti,omap3";
+
+	cpus {
+		cpu at 0 {
+			cpu0-supply = <&vcc>;
+		};
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x10000000>; /* 256 MB */
+	};
+
+};
+
+&i2c1 {
+	clock-frequency = <2200000>;
+
+	twl: twl at 48 {
+		reg = <0x48>;
+		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+		interrupt-parent = <&intc>;
+	};
+};
+
+/include/ "twl4030.dtsi"
+
+&twl_gpio {
+	ti,pullups	= <0x0>;
+	ti,pulldowns	= <0x03ff3f>; /* BIT(0..5) | BIT(8..17) */
+};
+
+&i2c2 {
+	clock-frequency = <400000>;
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+};
+
+&mmc1 {
+	status = "disabled";
+};
+
+&mmc2 {
+	status = "disabled";
+};
+
+&mmc3 {
+	status = "disabled";
+};
+
+&mcspi1 {
+	// For some reason, touchscreen is neccessary for screen to work at 
+	// all on real hw. It works well without it on emulator.
+	//
+	// Also... order in the device tree actually matters here.
+	tsc2005 at 0 {
+		compatible = "tsc2005";
+		spi-max-frequency = <6000000>;
+		reg = <0>;
+	};
+	mipid at 2 {
+		compatible = "acx565akm";
+		spi-max-frequency = <6000000>;
+		reg = <2>;
+		// turbo_mode = 0,
+		// cs_per_word = 0
+	};
+};
+
+&usb_otg_hs {
+	interface-type = <0>;
+	usb-phy = <&usb2_phy>;
+	mode = <2>;
+	power = <50>;
+};

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From shc_work at mail.ru  Sat Jul 13 10:11:57 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 13 Jul 2013 18:11:57 +0400
Subject: [RFC] ARM: imx clk: Implement pllv1 set_rate
Message-ID: <1373724717-3473-1-git-send-email-shc_work@mail.ru>

This patch implements frequency change for i.MX clk v1 PLL.
Selection of the values of the registers is not optimal, since is
made by simple enumeration of all possible values.
Comments are welcome.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/mach-imx/clk-imx27.c |   2 +-
 arch/arm/mach-imx/clk-pllv1.c | 109 ++++++++++++++++++++++++++++++++++--------
 arch/arm/mach-imx/mx27.h      |   4 +-
 3 files changed, 94 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index c3cfa41..2b363d9 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -125,7 +125,7 @@ int __init mx27_clocks_init(unsigned long fref)
 	clk[vpu_sel] = imx_clk_mux("vpu_sel", CCM_CSCR, 21, 1, vpu_sel_clks, ARRAY_SIZE(vpu_sel_clks));
 	clk[vpu_div] = imx_clk_divider("vpu_div", "vpu_sel", CCM_PCDR0, 10, 6);
 	clk[usb_div] = imx_clk_divider("usb_div", "spll_gate", CCM_CSCR, 28, 3);
-	clk[cpu_sel] = imx_clk_mux("cpu_sel", CCM_CSCR, 15, 1, cpu_sel_clks, ARRAY_SIZE(cpu_sel_clks));
+	clk[cpu_sel] = imx_clk_mux_flags("cpu_sel", CCM_CSCR, 15, 1, cpu_sel_clks, ARRAY_SIZE(cpu_sel_clks), CLK_SET_RATE_PARENT);
 	clk[clko_sel] = imx_clk_mux("clko_sel", CCM_CCSR, 0, 5, clko_sel_clks, ARRAY_SIZE(clko_sel_clks));
 	if (mx27_revision() >= IMX_CHIP_REVISION_2_0)
 		clk[cpu_div] = imx_clk_divider("cpu_div", "cpu_sel", CCM_CSCR, 12, 2);
diff --git a/arch/arm/mach-imx/clk-pllv1.c b/arch/arm/mach-imx/clk-pllv1.c
index c1eaee3..1a80abf 100644
--- a/arch/arm/mach-imx/clk-pllv1.c
+++ b/arch/arm/mach-imx/clk-pllv1.c
@@ -9,6 +9,8 @@
 #include "common.h"
 #include "hardware.h"
 
+#include "mx27.h"
+
 /**
  * pll v1
  *
@@ -25,17 +27,13 @@ struct clk_pllv1 {
 
 #define to_clk_pllv1(clk) (container_of(clk, struct clk_pllv1, clk))
 
-static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
-		unsigned long parent_rate)
+static unsigned long _clk_pllv1_recalc_rate(unsigned int mfi, unsigned int mfn,
+					    unsigned int mfd, unsigned int pd,
+					    unsigned long parent_rate)
 {
-	struct clk_pllv1 *pll = to_clk_pllv1(hw);
-	long long ll;
-	int mfn_abs;
-	unsigned int mfi, mfn, mfd, pd;
-	u32 reg;
 	unsigned long rate;
-
-	reg = readl(pll->base);
+	int mfn_abs = mfn;
+	long long ll;
 
 	/*
 	 * Get the resulting clock rate from a PLL register value and the input
@@ -47,15 +45,6 @@ static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
 	 *                        pd + 1
 	 */
 
-	mfi = (reg >> 10) & 0xf;
-	mfn = reg & 0x3ff;
-	mfd = (reg >> 16) & 0x3ff;
-	pd =  (reg >> 26) & 0xf;
-
-	mfi = mfi <= 5 ? 5 : mfi;
-
-	mfn_abs = mfn;
-
 	/*
 	 * On all i.MXs except i.MX1 and i.MX21 mfn is a 10bit
 	 * 2's complements number
@@ -78,8 +67,90 @@ static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
 	return ll;
 }
 
+static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
+		unsigned long parent_rate)
+{
+	struct clk_pllv1 *pll = to_clk_pllv1(hw);
+	unsigned int mfi, mfn, mfd, pd;
+	u32 reg = readl(pll->base);
+
+	/* Avoid i.MX27 TO2 SPCTL0 bug */
+	if (cpu_is_mx27() && (mx27_revision() == IMX_CHIP_REVISION_2_0))
+		writel(reg, pll->base);
+
+	mfi = (reg >> 10) & 0xf;
+	mfn = reg & 0x3ff;
+	mfd = (reg >> 16) & 0x3ff;
+	pd =  (reg >> 26) & 0xf;
+
+	mfi = mfi <= 5 ? 5 : mfi;
+
+	return _clk_pllv1_recalc_rate(mfi, mfn, mfd, pd, parent_rate);
+}
+
+static void _clk_pllv1_set_rate(unsigned long rate, unsigned long parent_rate,
+				unsigned int *reg)
+{
+	unsigned int pd, mfi, mfn, mfd;
+	long res, best = 0;
+
+	pd = (parent_rate * 2 * 5) / rate;
+	if (pd > 15)
+		pd = 15;
+	mfi = rate / (parent_rate * 2 * (pd + 1));
+	if (mfi < 5)
+		mfi = 5;
+	else if (mfi > 15)
+		mfi = 15;
+
+	for (mfd = 1; mfd < 0x400; mfd++)
+		for (mfn = 0; mfn < mfd; mfn++) {
+			res = _clk_pllv1_recalc_rate(mfi, mfn, mfd, pd,
+						     parent_rate);
+			if (!best || (abs(rate - res) < abs(rate - best))) {
+				*reg = mfn;
+				*reg |= mfi << 10;
+				*reg |= mfd << 16;
+				*reg |= pd << 26;
+				if (res == rate)
+					return;
+				best = res;
+			}
+		}
+}
+
+static int clk_pllv1_set_rate(struct clk_hw *hw, unsigned long rate,
+			      unsigned long parent_rate)
+{
+	struct clk_pllv1 *pll = to_clk_pllv1(hw);
+	u32 reg;
+
+	_clk_pllv1_set_rate(rate, parent_rate, &reg);
+	writel(reg, pll->base);
+
+	return 0;
+}
+
+static long clk_pllv1_round_rate(struct clk_hw *hw, unsigned long rate,
+				 unsigned long *prate)
+{
+	unsigned int pd, mfi, mfn, mfd;
+	u32 reg;
+
+	_clk_pllv1_set_rate(rate, *prate, &reg);
+
+	mfi = (reg >> 10) & 0xf;
+	mfn = reg & 0x3ff;
+	mfd = (reg >> 16) & 0x3ff;
+	pd =  (reg >> 26) & 0xf;
+
+	return _clk_pllv1_recalc_rate(mfi, mfn, mfd, pd, *prate);
+}
+
 static struct clk_ops clk_pllv1_ops = {
-	.recalc_rate = clk_pllv1_recalc_rate,
+	.recalc_rate	= clk_pllv1_recalc_rate,
+	.round_rate	= clk_pllv1_round_rate,
+	.set_rate	= clk_pllv1_set_rate,
 };
 
 struct clk *imx_clk_pllv1(const char *name, const char *parent,
diff --git a/arch/arm/mach-imx/mx27.h b/arch/arm/mach-imx/mx27.h
index 8a65f19..6835e23 100644
--- a/arch/arm/mach-imx/mx27.h
+++ b/arch/arm/mach-imx/mx27.h
@@ -231,8 +231,10 @@
 #define MX27_DMA_REQ_SDHC3	36
 #define MX27_DMA_REQ_NFC	37
 
-#ifndef __ASSEMBLY__
+#ifdef CONFIG_SOC_IMX27
 extern int mx27_revision(void);
+#else
+static int mx27_revision(void) { }
 #endif
 
 #endif /* ifndef __MACH_MX27_H__ */
-- 
1.8.1.5



From dsd at laptop.org  Sat Jul 13 10:25:15 2013
From: dsd at laptop.org (Daniel Drake)
Date: Sat, 13 Jul 2013 08:25:15 -0600
Subject: DT binding review for Armada display subsystem
In-Reply-To: <20130713103516.38a55b0b@armhf>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <20130712203952.6b7aa927@armhf>
 <CAMLZHHT1oAvOLe3JgQqMqLNXEr0NGrdtgELtF_djbqLFceHtiQ@mail.gmail.com>
 <20130713103516.38a55b0b@armhf>
Message-ID: <CAMLZHHSrX2T+pU3RosmjS3EggV3mX_J8D2OJD52sww_n6Y7B+A@mail.gmail.com>

On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine <moinejf at free.fr> wrote:
> I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
> driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
> modules. I set 3 clocks in the DT for the LCD0: lcdclk, axi and extclk0
> (si5351). Normally, the external clock is used, but, sometimes, the
> si5351 module is not yet initialized when the drm driver starts. So,
> for 1920x1080p, it uses the lcdclk which sets the LCD clock to 133333
> (400000/3) instead of 148500. As a result, display and sound still work
> correctly on my TV set thru HDMI.
>
> So, it would be nice to have 2 usable clocks per LCD, until we find a
> good way to initialize the modules in the right order at startup time.

Having multiple usable clocks is implemented in the patch I referred
you to. However it doesn't solve the "better clock turns up after
initializing the driver" problem, which seems like a tricky one.

Maybe the best solution is to defer probe until all DT-defined clocks
become available. That means that whoever compiles the kernel must
take care to not forget to build the clock drivers for all the clocks
referenced in this part of the DT, but perhaps that is a reasonable
thing to require.

On the other hand, this problem acts in support of a simpler approach
mentioned by Sebastian: developers figure out what the best clock is
for each CRTC on each board, and the DT only specifies that one clock.
The driver uses that clock if it is available and defers probe if it
is not.

> Back to the specific case of the Cubox with new ideas.
>
> The Cubox is based on the Armada 510 (Dove), so, all the hardware must
> be described in dove.dtsi. This includes the LCDs and DCON/IRE, the
> possible clocks and the (static) v4l2 links:

As a sidenote, I think we have concluded that we are not going to
interact with the armada 510 DCON in any way at the moment. The driver
will not have code that touches it, and the DT will not mention it.
The first person who actually needs to use the DCON will have the
responsibility for doing that work. Nevertheless it makes sense for us
to pick a DT design where we know that the DCON could be slotted in
later.

>         lcd0: lcd-controller at 820000 {
>                 compatible = "marvell,dove-lcd0";
>                 reg = <0x820000 0x1c8>;
>                 interrupts = <47>;
>                 clocks = <&core_clk 3>, <&lcdclk>;
>                 clock-names = "axi", "lcdclk";
>                 marvell-output = <&dcon 0>;
>                 status = "disabled";
>         };
>
>         lcd1: lcd-controller at 810000 {
>                 compatible = "marvell,dove-lcd1";
>                 reg = <0x810000 0x1c8>;
>                 interrupts = <46>;
>                 clocks = <&core_clk 3>, <&lcdclk>;
>                 clock-names = "axi", "lcdclk";
>                 marvell-output = <&dcon 1>;
>                 status = "disabled";
>         };
>
>         /* display controller and image rotation engine */
>         dcon: display-controller at 830000 {
>                 compatible = "marvell,dove-dcon";
>                 reg = <0x830000 0xc4>,                  /* DCON */
>                       <0x831000 0x8c>;                  /* IRE */
>                 interrupts = <45>;
>                 marvell-input = <&lcd0>, <&lcd1>;
>                 status = "disabled";
>         };

I guess the IRE falls into the same category as the DCON - we won't
implement it for now, but knowing where it might fit in is useful.

Why would you put it in the same node as the DCON though? It has its
own separate register space and additionally it is a component shared
with the MMP boards (whereas the DCON is not).

> The specific Cubox hardware (tda998x and si5351) is described in
> dove-cubox.dts, with the new clocks and the v4l2 link dcon0 <--> tda998x.
>
>         &i2c0 {
>                 si5351: clock-generator {
>                         ...
>                 };
>                 tda998x: hdmi-encoder {
>                         compatible = "nxp,tda998x";
>                         reg = <0x70>;
>                         interrupt-parent = <&gpio0>;
>                         interrupts = <27 2>;            /* falling edge */
>                         marvell-input = <&dcon 0>;
>                 };
>         };
>         &lcd0 {
>                 status = "okay";
>                 clocks = <&si5351 0>;
>                 clock-names = "extclk0";
>         };
>         &dcon {
>                 status = "okay";
>                 marvell-output = <&tda998x>, 0;         /* no connector on port B */
>         };

So now you are taking an approach equivalent to the v4l2 standard
"video interfaces" binding, which is the concept of representing a
connection graph via phandles. This means that our two proposals are
equivalent yet I proposed using a standard interface and you proposed
inventing your own, again without explaining why you don't like the
standard interface.

> Then, about the software, the drm driver may not need to know anything
> more (it scans the DT for the LCDs and gets all the subdevices thanks
> to the v4l2 links):
>
>         video {
>                 compatible = "marvell,armada-video";
>         };
>
> For some boards / other SoCs, there may be independant drm devices. In
> this case, there would be descriptions as:
>
>         video0 {
>                 compatible = "marvell,armada-video0";
>                 marvell,video-devices = <&lcd0>;
>         };
>         video1 {
>                 compatible = "marvell,armada-video1";
>                 marvell,video-devices = <&lcd1>;
>         };

This bit differs from my proposal, but I'm not sure what the benefit
of your design is. In my design, the two above use cases are
represented cleanly using the same DT abstraction (same compatible
string, same required properties, etc). In your design, the two use
cases call for something quite different as shown above.

Daniel


From dsd at laptop.org  Sat Jul 13 10:30:59 2013
From: dsd at laptop.org (Daniel Drake)
Date: Sat, 13 Jul 2013 08:30:59 -0600
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <CAN1soZzQz8PaHOwNf-Ec6G=ahhx_P8gaaX4fQnpX-Mqrepk_7g@mail.gmail.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <CAN1soZxiOh6TpbUOCUzK8gNwmvjbT3ihkUWaw8tuZ7md+NVA2g@mail.gmail.com>
 <20130710122433.GO11908@titan.lakedaemon.net>
 <CAN1soZzMvront1-jcBW6-uRKNs0OZNGnmiOjKGZSM28bViB_8A@mail.gmail.com>
 <20130710215041.GR11908@titan.lakedaemon.net>
 <CAN1soZzuiukY9qASFNcH0k=zH8=uT=71bKejPss44FCzNy=X-A@mail.gmail.com>
 <CAMLZHHQGZvDssY-YxQ3ZW8FYhpG-H1-VbokOid33socRSPrMNw@mail.gmail.com>
 <CAN1soZzQz8PaHOwNf-Ec6G=ahhx_P8gaaX4fQnpX-Mqrepk_7g@mail.gmail.com>
Message-ID: <CAMLZHHSDu+zgumVtWeU8yGiJ8Wmp3TQJbEc6u54LziOC5oXPeQ@mail.gmail.com>

On Fri, Jul 12, 2013 at 6:35 PM, Haojian Zhuang
<haojian.zhuang at gmail.com> wrote:
> These patches couldn't be applied. Since we're moving irq drivers from arch
> directories to irq directories.

It does not seem in line with the collaborative manner of kernel
development to block my patches for a whole month because they
conflict with your own private patches which do not exist for anyone
else (at least I searched and couldn't find them).

Please, either post your patches immediately (I will help review), or
review mine and figure out how to handle any conflict with your own
work afterwards.

> When the irq patches are applied, you can rebase your patches.

2 of the pending patches don't touch the irq stuff anyway.

Daniel


From olof at lixom.net  Sat Jul 13 11:38:36 2013
From: olof at lixom.net (Olof Johansson)
Date: Sat, 13 Jul 2013 08:38:36 -0700
Subject: [GIT PULL] ARM: SoC fixes for -rc1
Message-ID: <20130713153836.GA13431@quad.lixom.net>

Hi Linus,

Here's the first set of fixes for SoC platforms. You'll see a trivial
merge conflict due to the same bug being fixed through our tree and
another (with a newline difference), but it was near the bottom of the
branch and I didn't think it was worth rebasing away.


-Olof

The following changes since commit ddcf6600b133697adbafd96e080818bdc0dfd028:

  Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging (2013-07-03 19:56:35 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus

for you to fetch changes up to d4e1c7ef46e9b02dbf691da0c84d653f88670213:

  arm: multi_v7_defconfig: Tweaks for omap and sunxi (2013-07-12 23:45:33 -0700)

----------------------------------------------------------------
ARM: SoC fixes for 3.11-rc

This is our first set of fixes from arm-soc for 3.11.
 - A handful of build and warning fixes from Arnd
 - A collection of OMAP fixes
 - defconfig updates to make the default configs more useful for real use
   (and testing) out of the box on hardware.

And a couple of other small fixes. Some of these have been recently
applied but it's normally how we deal with fixes, with less bake time
in -next needed.

----------------------------------------------------------------
Afzal Mohammed (1):
      ARM: OMAP2+: timer: initialize before using oh_name

Arnd Bergmann (8):
      Merge tag 'renesas-fixes-for-v3.11' of git://git.kernel.org/.../horms/renesas into fixes
      ARM: omap5: omap5 has SCU and TWD
      ARM: zynq: use DT_MACHINE_START
      ARM: OMAP: build mach-omap code only if needed
      ARM: sti: move DEBUG_STI_UART into alphabetical order
      ARM: OMAP: omap_common_late_init may be unused
      ARM: ixp4xx: avoid circular header dependency
      ARM: exynos: select PM_GENERIC_DOMAINS only when used

Eduardo Valentin (2):
      ARM: OMAP2+: omap2plus_defconfig: enable TI bandgap driver
      ARM: OMAP2+: omap2plus_defconfig: enable DRA752 thermal support by default

Enric Balletbo i Serra (1):
      ARM: OMAP3: igep0020: Set DSS pins in correct mux mode.

Fabio Baltieri (2):
      ARM: ux500: select WATCHDOG and MUSB for ux500
      ARM: ux500: select SND_SOC_UX500 for ux500

Joel Fernandes (1):
      ARM: OMAP2+: Enable TI_EDMA in omap2plus_defconfig

Lee Jones (1):
      ARM: ux500: Enable HIGHMEM in the u8500 defconfig

Linus Walleij (1):
      ARM: ux500: update defconfig base

Magnus Damm (1):
      ARM: shmobile: emev2 GIO3 resource fix

Nishanth Menon (2):
      ARM: OMAP4: sleep: build OMAP4 specific functions only for OMAP4
      ARM: scu: provide inline dummy functions when SCU is not present

Olof Johansson (5):
      ARM: Make multi_v7_defconfig usable on hardware
      ARM: omap2: add select of TI_PRIV_EDMA
      Merge tag 'omap-for-v3.11/fixes-for-merge-window' of git://git.kernel.org/.../tmlind/linux-omap into fixes
      Merge tag 'ux500-defconfig-for-arm-soc' of git://git.kernel.org/.../linusw/linux-stericsson into fixes
      arm: multi_v7_defconfig: Tweaks for omap and sunxi

Paul Bolle (1):
      ARM: OMAP2+: Remove obsolete Makefile line

Pavel Machek (1):
      ARM: OMAP2+: N900: enable N900-specific drivers even if device tree is enabled

Santosh Shilimkar (1):
      ARM: OMAP5: Enable Cortex A15 errata 798181

Stephen Warren (1):
      ARM: tegra: fix VBUS regulator GPIO polarity in DT

Takanari Hayama (1):
      ARM: shmobile: r8a73a4: Fix resources for SCIFB0

Thomas Meyer (1):
      ARM: OMAP2+: Cocci spatch "ptr_ret.spatch"

Tom Rini (1):
      ARM: OMAP2+: omap2plus_defconfig: Enable appended DTB support

Ulf Hansson (1):
      ARM: ux500: Update MMC configs for u8500 defconfig

Vincent Stehl? (1):
      arm: multi_v7_defconfig: add i.MX options and NFS root

Wei Yongjun (1):
      ARM: OMAP2+: devices: remove duplicated include from devices.c

 arch/arm/Kconfig.debug                    |  20 ++--
 arch/arm/boot/dts/tegra20-seaboard.dts    |   1 +
 arch/arm/boot/dts/tegra20-trimslice.dts   |   1 +
 arch/arm/boot/dts/tegra20-whistler.dts    |   2 +
 arch/arm/configs/multi_v7_defconfig       | 133 ++++++++++++++++++++------
 arch/arm/configs/omap2plus_defconfig      |  19 ++++
 arch/arm/configs/u8500_defconfig          |  44 +++++----
 arch/arm/include/asm/smp_scu.h            |  13 ++-
 arch/arm/mach-exynos/Kconfig              |   2 +-
 arch/arm/mach-ixp4xx/dsmg600-setup.c      |   2 +
 arch/arm/mach-ixp4xx/include/mach/timex.h |   2 +-
 arch/arm/mach-ixp4xx/omixp-setup.c        |   2 +
 arch/arm/mach-omap2/Kconfig               | 153 +++++++++++++++---------------
 arch/arm/mach-omap2/Makefile              |   4 -
 arch/arm/mach-omap2/board-igep0020.c      |  31 ++++++
 arch/arm/mach-omap2/board-rx51-video.c    |   2 +-
 arch/arm/mach-omap2/devices.c             |   5 +-
 arch/arm/mach-omap2/fb.c                  |   5 +-
 arch/arm/mach-omap2/gpmc.c                |   2 +-
 arch/arm/mach-omap2/io.c                  |   2 +-
 arch/arm/mach-omap2/pmu.c                 |   5 +-
 arch/arm/mach-omap2/sleep44xx.S           |   6 +-
 arch/arm/mach-omap2/timer.c               |   2 +-
 arch/arm/mach-shmobile/setup-emev2.c      |   8 +-
 arch/arm/mach-shmobile/setup-r8a73a4.c    |   2 +-
 arch/arm/mach-zynq/common.c               |   2 +-
 sound/soc/omap/rx51.c                     |   2 +-
 27 files changed, 311 insertions(+), 161 deletions(-)


From fgenfb at yahoo.com  Sat Jul 13 11:51:07 2013
From: fgenfb at yahoo.com (Harm Hanemaaijer)
Date: Sat, 13 Jul 2013 15:51:07 +0000 (UTC)
Subject: Call for testing/opinions: Optimized memset/memcpy
Message-ID: <loom.20130713T172357-560@post.gmane.org>

Hello,

I've been doing some work on optimizing the memset/memcpy family of
functions for modern ARM platforms, including copy_page, memset,
memzero, memcpy, copy_from_user and copy_to_user. It appears that
there is room for improvement, especially with regard to using an
optimal preload strategy for armv6/v7 architectures as well as
aligning the write target. For example, on an armv6-based platform
(RPi) I am seeing a 80% speed-up in copy_page and large sized
memcpy. Gains in the range 10-25% are seen on a Cortex A8 device.
These optimizations use the regular register file, like the
previous implementation, and do not use any NEON or vfp registers.

To properly benchmark and test these new implementations, I've
created a userspace testing utility that can be used to compare
and validate exact copies of the original and optimized kernel
versions of the functions in userspace. The repository is
available at https://github.com/hglm/test-arm-kernel-memcpy.git.
It would be useful to compare the results on different
platforms and to check whether changes in the prefetch distance
or write alignment result in optimized performance.

I've created a preliminary patch set that replaces the copy_page,
memset and memzero functions for all ARM platforms. Features
include use of a configurable prefetch distance in copy_page,
translation to 16-bit Thumb2 instructions whenever possible,
optimization for the common word-aligned case in memset/memzero,
and application of a predefined write alignment in memset/memzero.
In order to safely use unified ARM assembler syntax, which appears
to be desirable going forward, the first patch in the set renames
all references of the "push" macro so that it no longer conflicts
with the "push" instruction defined in unified syntax. The new
memset/memzero functions use the unified syntax. The patch set
is available at
https://github.com/hglm/patches/tree/master/arm-mem-funcs.

Optimization of memcpy/copy_from_user/copy_to_user is more
complicated, and although I've created optimized versions that
provide better results in benchmarks, we have to be careful that
increased code size and branch prediction burden does not result
in lower performance in real-world use, especially on older
platforms. Therefore it might be desirable to only enable them
on newer platforms like armv6/v7.

So in short, I am looking for opinions, and test results especially
from the userspace benchmark, to see the relative merit of these
optimizations on different platforms.




From gilbertd at treblig.org  Sat Jul 13 12:48:40 2013
From: gilbertd at treblig.org (Dr. David Alan Gilbert)
Date: Sat, 13 Jul 2013 17:48:40 +0100
Subject: Call for testing/opinions: Optimized memset/memcpy
In-Reply-To: <loom.20130713T172357-560@post.gmane.org>
References: <loom.20130713T172357-560@post.gmane.org>
Message-ID: <20130713164840.GC28473@gallifrey>

* Harm Hanemaaijer (fgenfb at yahoo.com) wrote:
> Hello,
> 
> I've been doing some work on optimizing the memset/memcpy family of
> functions for modern ARM platforms, including copy_page, memset,
> memzero, memcpy, copy_from_user and copy_to_user. It appears that
> there is room for improvement, especially with regard to using an
> optimal preload strategy for armv6/v7 architectures as well as
> aligning the write target. For example, on an armv6-based platform
> (RPi) I am seeing a 80% speed-up in copy_page and large sized
> memcpy. Gains in the range 10-25% are seen on a Cortex A8 device.
> These optimizations use the regular register file, like the
> previous implementation, and do not use any NEON or vfp registers.

You might like to compare with some of the routines at:
https://launchpad.net/cortex-strings
and some of the numbers at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Benchmarks/

(I'm sure Michael Hope who owns that set of stuff would be
interested in seeing your stuff as well).

> To properly benchmark and test these new implementations, I've
> created a userspace testing utility that can be used to compare
> and validate exact copies of the original and optimized kernel
> versions of the functions in userspace. The repository is
> available at https://github.com/hglm/test-arm-kernel-memcpy.git.
> It would be useful to compare the results on different
> platforms and to check whether changes in the prefetch distance
> or write alignment result in optimized performance.

It's quite tricky figuring out across different machines; also
even the same machine in different setups;

http://ssvb.github.io/2013/06/27/fullhd-x11-desktop-performance-of-the-allwinner-a10.html

is an interesting article on one machine being screwed over by
video bandwidth.

I've only had a brief scan through your code, one thing I remember
from a couple of years ago was a theory that ldrd/strd was supposed
to be faster on A15's (but I never had a chance to try it out).

<snip>

> So in short, I am looking for opinions, and test results especially
> from the userspace benchmark, to see the relative merit of these
> optimizations on different platforms.

Maybe neon is worth a try these days (although be careful of platforms
like Tegra 2 that doens't have it); there was a recent patch that enabled
use in the kernel (I think for some RAID use). The downside is it's
supposed to be quite power hungry.

Dave
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\ gro.gilbert @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/


From w at 1wt.eu  Sat Jul 13 13:24:45 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Sat, 13 Jul 2013 19:24:45 +0200
Subject: Call for testing/opinions: Optimized memset/memcpy
In-Reply-To: <loom.20130713T172357-560@post.gmane.org>
References: <loom.20130713T172357-560@post.gmane.org>
Message-ID: <20130713172445.GL32054@1wt.eu>

Hello Harm,

On Sat, Jul 13, 2013 at 03:51:07PM +0000, Harm Hanemaaijer wrote:
> Hello,
> 
> I've been doing some work on optimizing the memset/memcpy family of
> functions for modern ARM platforms, including copy_page, memset,
> memzero, memcpy, copy_from_user and copy_to_user. It appears that
> there is room for improvement, especially with regard to using an
> optimal preload strategy for armv6/v7 architectures as well as
> aligning the write target. For example, on an armv6-based platform
> (RPi) I am seeing a 80% speed-up in copy_page and large sized
> memcpy. Gains in the range 10-25% are seen on a Cortex A8 device.

Interesting, especially for devices that have a narrow DDR bus where
we want to shave every possible bus cycle!

(...)
> So in short, I am looking for opinions, and test results especially
> from the userspace benchmark, to see the relative merit of these
> optimizations on different platforms.

OK I've run bench.script on the following platforms :

  - Snowball board : it is a dual-core 1GHz cortex-a9 from STE (A9500).
    It has some 32-bit LPDDR2 soldered on the CPU (package on package).
    The test ran only in ARMv7 mode.

    root at snowball:tmp# cat /proc/cpuinfo 
    processor       : 0
    model name      : ARMv7 Processor rev 1 (v7l)
    BogoMIPS        : 4.80
    Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls 
    CPU implementer : 0x41
    CPU architecture: 7
    CPU variant     : 0x2
    CPU part        : 0xc09
    CPU revision    : 1

  - Armada XP-GP board : it's a quad-core 1.6 GHz Marvell Armada-XP (PJ4Bv2)
    CPU. It has 64-bit DDR3-1600 RAM on a DIMM. The tests were run in ARMv7
    and Thumb2 modes. The difference was not impressive between the two
    modes.

    root at xpgp:tmp# cat /proc/cpuinfo 
    processor       : 0
    model name      : ARMv7 Processor rev 2 (v7l)
    BogoMIPS        : 1594.16
    Features        : swp half thumb fastmult vfp edsp vfpv3 tls idiva idivt 
    CPU implementer : 0x56
    CPU architecture: 7
    CPU variant     : 0x2
    CPU part        : 0x584
    CPU revision    : 2

  - Mirabox : single-core 1.2 GHz Marvell Armada370 (PJ4B) CPU. It uses
    16-bit DDR3-1200 soldered onboard. The tests were run in ARMv7 and
    Thumb2 modes. It can be useful to compare with the xp-gp above because
    its CPU can be seen as a scaled down version of the previous one, with
    1/4 of the DRAM bus width, and both have the DRAM at half CPU frequency.

    root at mirabox:tmp# cat /proc/cpuinfo 
    processor       : 0
    model name      : ARMv7 Processor rev 1 (v7l)
    BogoMIPS        : 597.60
    Features        : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16 tls idivt 
    CPU implementer : 0x56
    CPU architecture: 7
    CPU variant     : 0x1
    CPU part        : 0x581
    CPU revision    : 1

I'm attaching all the results.

Hoping this helps,
Willy

-------------- next part --------------
libc memcpy:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 599.89 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 600.57 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 597.81 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 598.70 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 595.39 MB/s
kernel memcpy (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 618.28 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 615.10 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 618.15 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 615.02 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 621.19 MB/s
kernel memcpy (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 618.03 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 612.97 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 614.82 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 611.68 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 616.50 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 363.92 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 365.71 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 363.92 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 365.73 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 365.63 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 381.35 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 383.49 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 381.49 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 383.32 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 381.47 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 426.75 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 426.75 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 426.75 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 426.69 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 424.72 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 130, word aligned: 311.75 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 310.30 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 311.74 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 310.22 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 311.76 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 130, word aligned: 327.84 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 327.89 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 327.87 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 326.25 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 327.87 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 364.50 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 366.29 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 364.51 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 366.24 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 366.31 MB/s
kernel copy_from_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 361.11 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 362.86 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 361.10 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 362.86 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 361.13 MB/s
kernel copy_to_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 366.61 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 364.79 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 366.56 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 366.60 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 364.84 MB/s
libc memcpy:
4096 bytes page aligned: 356.71 MB/s
4096 bytes page aligned: 355.04 MB/s
4096 bytes page aligned: 356.67 MB/s
4096 bytes page aligned: 354.98 MB/s
4096 bytes page aligned: 356.68 MB/s
kernel memcpy (original):
4096 bytes page aligned: 355.32 MB/s
4096 bytes page aligned: 356.96 MB/s
4096 bytes page aligned: 355.31 MB/s
4096 bytes page aligned: 357.01 MB/s
4096 bytes page aligned: 355.30 MB/s
kernel memcpy (optimized):
4096 bytes page aligned: 341.05 MB/s
4096 bytes page aligned: 339.37 MB/s
4096 bytes page aligned: 341.04 MB/s
4096 bytes page aligned: 339.37 MB/s
4096 bytes page aligned: 341.03 MB/s
kernel copy_page (original):
4096 bytes page aligned: 382.31 MB/s
4096 bytes page aligned: 384.19 MB/s
4096 bytes page aligned: 382.29 MB/s
4096 bytes page aligned: 384.25 MB/s
4096 bytes page aligned: 382.30 MB/s
kernel copy_page (optimized):
4096 bytes page aligned: 340.55 MB/s
4096 bytes page aligned: 338.96 MB/s
4096 bytes page aligned: 340.60 MB/s
4096 bytes page aligned: 338.96 MB/s
4096 bytes page aligned: 340.56 MB/s
libc memcpy:
Mixed from 1 to 1023 (power law), unaligned: 513.06 MB/s
Mixed from 1 to 1023 (power law), unaligned: 513.02 MB/s
Mixed from 1 to 1023 (power law), unaligned: 512.94 MB/s
Mixed from 1 to 1023 (power law), unaligned: 510.37 MB/s
Mixed from 1 to 1023 (power law), unaligned: 513.35 MB/s
kernel memcpy (original):
Mixed from 1 to 1023 (power law), unaligned: 532.66 MB/s
Mixed from 1 to 1023 (power law), unaligned: 535.20 MB/s
Mixed from 1 to 1023 (power law), unaligned: 532.29 MB/s
Mixed from 1 to 1023 (power law), unaligned: 535.41 MB/s
Mixed from 1 to 1023 (power law), unaligned: 535.59 MB/s
kernel memcpy (optimized):
Mixed from 1 to 1023 (power law), unaligned: 528.33 MB/s
Mixed from 1 to 1023 (power law), unaligned: 531.12 MB/s
Mixed from 1 to 1023 (power law), unaligned: 527.64 MB/s
Mixed from 1 to 1023 (power law), unaligned: 530.72 MB/s
Mixed from 1 to 1023 (power law), unaligned: 528.05 MB/s
libc memset:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 888.47 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 884.25 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 888.42 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 888.49 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 884.05 MB/s
kernel memset (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 962.84 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 958.71 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 963.20 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 958.83 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 962.86 MB/s
kernel memset (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1004.37 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 999.61 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1004.49 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 999.43 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1004.46 MB/s
kernel memzero (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 922.59 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 926.98 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 926.99 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 922.46 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 927.07 MB/s
kernel memzero (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 930.00 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 934.53 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 930.89 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 935.60 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 935.32 MB/s
libc memset:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 520.37 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 520.42 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 517.93 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 520.36 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 517.84 MB/s
kernel memset (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 594.94 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 591.54 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 594.39 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 594.45 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 591.58 MB/s
kernel memset (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 658.84 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 655.68 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 658.78 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 655.58 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 658.85 MB/s
kernel memzero (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 567.21 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 569.94 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 569.92 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 567.08 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 569.93 MB/s
kernel memzero (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 586.06 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 588.64 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 585.75 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 588.86 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 588.66 MB/s
libc memset:
4096 bytes page aligned: 2052.77 MB/s
4096 bytes page aligned: 2052.69 MB/s
4096 bytes page aligned: 2042.84 MB/s
4096 bytes page aligned: 2052.72 MB/s
4096 bytes page aligned: 2042.30 MB/s
kernel memset (original):
4096 bytes page aligned: 1920.98 MB/s
4096 bytes page aligned: 1911.66 MB/s
4096 bytes page aligned: 1921.13 MB/s
4096 bytes page aligned: 1921.17 MB/s
4096 bytes page aligned: 1911.92 MB/s
kernel memset (optimized):
4096 bytes page aligned: 1900.46 MB/s
4096 bytes page aligned: 1891.21 MB/s
4096 bytes page aligned: 1900.52 MB/s
4096 bytes page aligned: 1891.16 MB/s
4096 bytes page aligned: 1900.64 MB/s
kernel memzero (original):
4096 bytes page aligned: 1910.57 MB/s
4096 bytes page aligned: 1920.05 MB/s
4096 bytes page aligned: 1920.02 MB/s
4096 bytes page aligned: 1910.87 MB/s
4096 bytes page aligned: 1920.06 MB/s
kernel memzero (optimized):
4096 bytes page aligned: 1917.74 MB/s
4096 bytes page aligned: 1927.05 MB/s
4096 bytes page aligned: 1917.28 MB/s
4096 bytes page aligned: 1927.11 MB/s
4096 bytes page aligned: 1926.87 MB/s
libc memset:
Mixed from 1 to 1023 (power law), unaligned: 759.37 MB/s
Mixed from 1 to 1023 (power law), unaligned: 759.42 MB/s
Mixed from 1 to 1023 (power law), unaligned: 755.88 MB/s
Mixed from 1 to 1023 (power law), unaligned: 759.32 MB/s
Mixed from 1 to 1023 (power law), unaligned: 756.04 MB/s
kernel memset (original):
Mixed from 1 to 1023 (power law), unaligned: 802.77 MB/s
Mixed from 1 to 1023 (power law), unaligned: 798.89 MB/s
Mixed from 1 to 1023 (power law), unaligned: 801.62 MB/s
Mixed from 1 to 1023 (power law), unaligned: 802.67 MB/s
Mixed from 1 to 1023 (power law), unaligned: 798.07 MB/s
kernel memset (optimized):
Mixed from 1 to 1023 (power law), unaligned: 862.50 MB/s
Mixed from 1 to 1023 (power law), unaligned: 857.72 MB/s
Mixed from 1 to 1023 (power law), unaligned: 862.52 MB/s
Mixed from 1 to 1023 (power law), unaligned: 857.00 MB/s
Mixed from 1 to 1023 (power law), unaligned: 860.71 MB/s
kernel memzero (original):
Mixed from 1 to 1023 (power law), unaligned: 784.48 MB/s
Mixed from 1 to 1023 (power law), unaligned: 780.41 MB/s
Mixed from 1 to 1023 (power law), unaligned: 784.97 MB/s
Mixed from 1 to 1023 (power law), unaligned: 781.14 MB/s
Mixed from 1 to 1023 (power law), unaligned: 783.99 MB/s
kernel memzero (optimized):
Mixed from 1 to 1023 (power law), unaligned: 793.48 MB/s
Mixed from 1 to 1023 (power law), unaligned: 796.39 MB/s
Mixed from 1 to 1023 (power law), unaligned: 792.86 MB/s
Mixed from 1 to 1023 (power law), unaligned: 796.20 MB/s
Mixed from 1 to 1023 (power law), unaligned: 796.68 MB/s
-------------- next part --------------
libc memcpy:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 614.78 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 618.39 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 614.90 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 618.16 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 614.83 MB/s
kernel memcpy (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 654.11 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 650.60 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 653.49 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 653.81 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 649.56 MB/s
kernel memcpy (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 653.09 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 650.86 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 653.72 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 650.74 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 653.71 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 332.22 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 333.86 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 332.22 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 333.86 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 333.77 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 365.63 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 365.65 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 363.96 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 365.63 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 363.95 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 403.08 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 401.21 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 403.06 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 401.23 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 403.02 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 130, word aligned: 293.84 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 293.87 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 293.79 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 292.46 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 293.78 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 130, word aligned: 312.63 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 314.11 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 312.64 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 314.05 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 312.63 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 347.08 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 345.40 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 347.01 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 347.06 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 347.05 MB/s
kernel copy_from_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 338.99 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 337.42 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 338.96 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 337.42 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 339.07 MB/s
kernel copy_to_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 336.61 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 338.16 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 336.61 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 338.21 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 336.58 MB/s
libc memcpy:
4096 bytes page aligned: 358.08 MB/s
4096 bytes page aligned: 356.32 MB/s
4096 bytes page aligned: 358.07 MB/s
4096 bytes page aligned: 356.39 MB/s
4096 bytes page aligned: 358.08 MB/s
kernel memcpy (original):
4096 bytes page aligned: 356.76 MB/s
4096 bytes page aligned: 358.47 MB/s
4096 bytes page aligned: 356.76 MB/s
4096 bytes page aligned: 358.47 MB/s
4096 bytes page aligned: 356.86 MB/s
kernel memcpy (optimized):
4096 bytes page aligned: 342.33 MB/s
4096 bytes page aligned: 340.66 MB/s
4096 bytes page aligned: 342.32 MB/s
4096 bytes page aligned: 340.70 MB/s
4096 bytes page aligned: 342.31 MB/s
kernel copy_page (original):
4096 bytes page aligned: 381.93 MB/s
4096 bytes page aligned: 383.87 MB/s
4096 bytes page aligned: 381.97 MB/s
4096 bytes page aligned: 383.86 MB/s
4096 bytes page aligned: 381.98 MB/s
kernel copy_page (optimized):
4096 bytes page aligned: 341.86 MB/s
4096 bytes page aligned: 341.83 MB/s
4096 bytes page aligned: 341.86 MB/s
4096 bytes page aligned: 341.80 MB/s
4096 bytes page aligned: 341.85 MB/s
libc memcpy:
Mixed from 1 to 1023 (power law), unaligned: 484.57 MB/s
Mixed from 1 to 1023 (power law), unaligned: 482.42 MB/s
Mixed from 1 to 1023 (power law), unaligned: 484.45 MB/s
Mixed from 1 to 1023 (power law), unaligned: 482.49 MB/s
Mixed from 1 to 1023 (power law), unaligned: 484.27 MB/s
kernel memcpy (original):
Mixed from 1 to 1023 (power law), unaligned: 503.45 MB/s
Mixed from 1 to 1023 (power law), unaligned: 505.11 MB/s
Mixed from 1 to 1023 (power law), unaligned: 502.65 MB/s
Mixed from 1 to 1023 (power law), unaligned: 505.09 MB/s
Mixed from 1 to 1023 (power law), unaligned: 502.69 MB/s
kernel memcpy (optimized):
Mixed from 1 to 1023 (power law), unaligned: 490.07 MB/s
Mixed from 1 to 1023 (power law), unaligned: 490.26 MB/s
Mixed from 1 to 1023 (power law), unaligned: 486.98 MB/s
Mixed from 1 to 1023 (power law), unaligned: 489.95 MB/s
Mixed from 1 to 1023 (power law), unaligned: 487.95 MB/s
libc memset:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 844.51 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 840.39 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 844.37 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 840.68 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 844.55 MB/s
kernel memset (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 886.05 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 890.19 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 890.11 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 885.76 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 889.84 MB/s
kernel memset (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 930.57 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 934.93 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 930.50 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 934.75 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 930.35 MB/s
kernel memzero (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 860.46 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 860.40 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 860.34 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 860.40 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 856.31 MB/s
kernel memzero (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 881.67 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 877.42 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 881.60 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 877.48 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 881.70 MB/s
libc memset:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 496.66 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 499.04 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 498.98 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 496.62 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 498.96 MB/s
kernel memset (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 551.78 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 554.33 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 551.63 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 554.13 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 551.60 MB/s
kernel memset (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 601.07 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 597.87 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 601.06 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 601.08 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 598.38 MB/s
kernel memzero (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 525.40 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 522.99 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 525.42 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 522.74 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 525.28 MB/s
kernel memzero (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 556.46 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 559.02 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 559.16 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 559.00 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 559.13 MB/s
libc memset:
4096 bytes page aligned: 2029.13 MB/s
4096 bytes page aligned: 2038.87 MB/s
4096 bytes page aligned: 2029.11 MB/s
4096 bytes page aligned: 2038.82 MB/s
4096 bytes page aligned: 2028.82 MB/s
kernel memset (original):
4096 bytes page aligned: 1918.99 MB/s
4096 bytes page aligned: 1909.79 MB/s
4096 bytes page aligned: 1919.03 MB/s
4096 bytes page aligned: 1918.82 MB/s
4096 bytes page aligned: 1918.96 MB/s
kernel memset (optimized):
4096 bytes page aligned: 1920.02 MB/s
4096 bytes page aligned: 1910.71 MB/s
4096 bytes page aligned: 1920.03 MB/s
4096 bytes page aligned: 1910.58 MB/s
4096 bytes page aligned: 1919.89 MB/s
kernel memzero (original):
4096 bytes page aligned: 1885.37 MB/s
4096 bytes page aligned: 1894.53 MB/s
4096 bytes page aligned: 1885.11 MB/s
4096 bytes page aligned: 1894.52 MB/s
4096 bytes page aligned: 1894.52 MB/s
kernel memzero (optimized):
4096 bytes page aligned: 1895.10 MB/s
4096 bytes page aligned: 1894.72 MB/s
4096 bytes page aligned: 1885.82 MB/s
4096 bytes page aligned: 1895.08 MB/s
4096 bytes page aligned: 1885.86 MB/s
libc memset:
Mixed from 1 to 1023 (power law), unaligned: 737.90 MB/s
Mixed from 1 to 1023 (power law), unaligned: 734.13 MB/s
Mixed from 1 to 1023 (power law), unaligned: 737.61 MB/s
Mixed from 1 to 1023 (power law), unaligned: 734.18 MB/s
Mixed from 1 to 1023 (power law), unaligned: 737.53 MB/s
kernel memset (original):
Mixed from 1 to 1023 (power law), unaligned: 786.00 MB/s
Mixed from 1 to 1023 (power law), unaligned: 786.00 MB/s
Mixed from 1 to 1023 (power law), unaligned: 785.98 MB/s
Mixed from 1 to 1023 (power law), unaligned: 782.09 MB/s
Mixed from 1 to 1023 (power law), unaligned: 785.96 MB/s
kernel memset (optimized):
Mixed from 1 to 1023 (power law), unaligned: 813.68 MB/s
Mixed from 1 to 1023 (power law), unaligned: 817.65 MB/s
Mixed from 1 to 1023 (power law), unaligned: 813.22 MB/s
Mixed from 1 to 1023 (power law), unaligned: 817.10 MB/s
Mixed from 1 to 1023 (power law), unaligned: 813.94 MB/s
kernel memzero (original):
Mixed from 1 to 1023 (power law), unaligned: 746.57 MB/s
Mixed from 1 to 1023 (power law), unaligned: 746.77 MB/s
Mixed from 1 to 1023 (power law), unaligned: 742.82 MB/s
Mixed from 1 to 1023 (power law), unaligned: 746.56 MB/s
Mixed from 1 to 1023 (power law), unaligned: 743.25 MB/s
kernel memzero (optimized):
Mixed from 1 to 1023 (power law), unaligned: 785.01 MB/s
Mixed from 1 to 1023 (power law), unaligned: 781.21 MB/s
Mixed from 1 to 1023 (power law), unaligned: 785.10 MB/s
Mixed from 1 to 1023 (power law), unaligned: 781.19 MB/s
Mixed from 1 to 1023 (power law), unaligned: 784.99 MB/s
-------------- next part --------------
libc memcpy:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 944.06 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 939.55 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 936.32 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 938.91 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 935.52 MB/s
kernel memcpy (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 921.58 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 918.61 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 915.82 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 915.27 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 911.62 MB/s
kernel memcpy (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 908.06 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 905.13 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 907.52 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 906.64 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 907.89 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 547.23 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 547.29 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 546.17 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 547.24 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 547.50 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 541.90 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 541.91 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 541.93 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 542.91 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 541.95 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 615.08 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 614.48 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 615.11 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 615.07 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 614.90 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 130, word aligned: 459.28 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 459.87 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 459.40 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 459.62 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 459.40 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 130, word aligned: 457.91 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 458.35 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 457.98 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 458.22 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 457.85 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 545.62 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 544.90 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 545.52 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 545.42 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 545.54 MB/s
kernel copy_from_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 485.72 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 484.69 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 484.78 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 485.02 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 485.64 MB/s
kernel copy_to_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 489.08 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 491.05 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 492.40 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 493.27 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 491.08 MB/s
libc memcpy:
4096 bytes page aligned: 1027.53 MB/s
4096 bytes page aligned: 1020.33 MB/s
4096 bytes page aligned: 1026.20 MB/s
4096 bytes page aligned: 1025.76 MB/s
4096 bytes page aligned: 1024.70 MB/s
kernel memcpy (original):
4096 bytes page aligned: 1026.80 MB/s
4096 bytes page aligned: 1027.25 MB/s
4096 bytes page aligned: 1026.46 MB/s
4096 bytes page aligned: 1020.09 MB/s
4096 bytes page aligned: 1027.83 MB/s
kernel memcpy (optimized):
4096 bytes page aligned: 841.49 MB/s
4096 bytes page aligned: 847.07 MB/s
4096 bytes page aligned: 840.32 MB/s
4096 bytes page aligned: 847.07 MB/s
4096 bytes page aligned: 841.32 MB/s
kernel copy_page (original):
4096 bytes page aligned: 948.27 MB/s
4096 bytes page aligned: 940.34 MB/s
4096 bytes page aligned: 946.30 MB/s
4096 bytes page aligned: 942.02 MB/s
4096 bytes page aligned: 948.32 MB/s
kernel copy_page (optimized):
4096 bytes page aligned: 850.59 MB/s
4096 bytes page aligned: 857.73 MB/s
4096 bytes page aligned: 851.24 MB/s
4096 bytes page aligned: 858.75 MB/s
4096 bytes page aligned: 851.73 MB/s
libc memcpy:
Mixed from 1 to 1023 (power law), unaligned: 715.47 MB/s
Mixed from 1 to 1023 (power law), unaligned: 714.09 MB/s
Mixed from 1 to 1023 (power law), unaligned: 715.65 MB/s
Mixed from 1 to 1023 (power law), unaligned: 714.83 MB/s
Mixed from 1 to 1023 (power law), unaligned: 712.47 MB/s
kernel memcpy (original):
Mixed from 1 to 1023 (power law), unaligned: 721.70 MB/s
Mixed from 1 to 1023 (power law), unaligned: 719.15 MB/s
Mixed from 1 to 1023 (power law), unaligned: 721.34 MB/s
Mixed from 1 to 1023 (power law), unaligned: 718.81 MB/s
Mixed from 1 to 1023 (power law), unaligned: 721.02 MB/s
kernel memcpy (optimized):
Mixed from 1 to 1023 (power law), unaligned: 635.79 MB/s
Mixed from 1 to 1023 (power law), unaligned: 636.97 MB/s
Mixed from 1 to 1023 (power law), unaligned: 635.52 MB/s
Mixed from 1 to 1023 (power law), unaligned: 636.23 MB/s
Mixed from 1 to 1023 (power law), unaligned: 636.05 MB/s
libc memset:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1323.49 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1326.82 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1348.12 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1328.57 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1324.56 MB/s
kernel memset (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1786.48 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1782.46 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1776.21 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1745.68 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1771.53 MB/s
kernel memset (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1770.77 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1759.21 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1721.21 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1782.98 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1762.74 MB/s
kernel memzero (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1745.20 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1763.23 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1743.48 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1766.37 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1728.34 MB/s
kernel memzero (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1682.73 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1660.62 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1695.76 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1703.42 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1766.86 MB/s
libc memset:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 901.11 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 901.81 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 889.89 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 886.94 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 899.02 MB/s
kernel memset (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1142.87 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1145.74 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1141.91 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1142.41 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1143.23 MB/s
kernel memset (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1129.60 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1132.20 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1131.63 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1131.37 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1128.10 MB/s
kernel memzero (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1110.96 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1105.10 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1106.56 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1107.89 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1105.29 MB/s
kernel memzero (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1081.12 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1086.37 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1086.06 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1086.13 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1085.48 MB/s
libc memset:
4096 bytes page aligned: 1371.96 MB/s
4096 bytes page aligned: 1362.53 MB/s
4096 bytes page aligned: 1383.10 MB/s
4096 bytes page aligned: 1356.89 MB/s
4096 bytes page aligned: 1367.61 MB/s
kernel memset (original):
4096 bytes page aligned: 1321.56 MB/s
4096 bytes page aligned: 1337.12 MB/s
4096 bytes page aligned: 1318.98 MB/s
4096 bytes page aligned: 1330.80 MB/s
4096 bytes page aligned: 1324.66 MB/s
kernel memset (optimized):
4096 bytes page aligned: 1317.07 MB/s
4096 bytes page aligned: 1305.07 MB/s
4096 bytes page aligned: 1311.78 MB/s
4096 bytes page aligned: 1301.32 MB/s
4096 bytes page aligned: 1305.47 MB/s
kernel memzero (original):
4096 bytes page aligned: 1320.70 MB/s
4096 bytes page aligned: 1317.15 MB/s
4096 bytes page aligned: 1380.78 MB/s
4096 bytes page aligned: 1316.34 MB/s
4096 bytes page aligned: 1363.25 MB/s
kernel memzero (optimized):
4096 bytes page aligned: 1302.89 MB/s
4096 bytes page aligned: 1349.68 MB/s
4096 bytes page aligned: 1305.33 MB/s
4096 bytes page aligned: 1338.91 MB/s
4096 bytes page aligned: 1304.71 MB/s
libc memset:
Mixed from 1 to 1023 (power law), unaligned: 1296.85 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1281.93 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1284.15 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1303.82 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1289.72 MB/s
kernel memset (original):
Mixed from 1 to 1023 (power law), unaligned: 1635.98 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1631.05 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1630.50 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1629.33 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1640.34 MB/s
kernel memset (optimized):
Mixed from 1 to 1023 (power law), unaligned: 1674.27 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1661.84 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1670.77 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1656.26 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1664.30 MB/s
kernel memzero (original):
Mixed from 1 to 1023 (power law), unaligned: 1583.12 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1576.78 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1579.13 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1571.27 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1554.87 MB/s
kernel memzero (optimized):
Mixed from 1 to 1023 (power law), unaligned: 1613.16 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1624.66 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1613.26 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1624.16 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1611.64 MB/s
-------------- next part --------------
libc memcpy:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 938.28 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 938.13 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 938.22 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 937.87 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 938.26 MB/s
kernel memcpy (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 992.48 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 992.77 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 992.53 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 992.82 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 992.45 MB/s
kernel memcpy (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 869.57 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 870.32 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 869.57 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 870.32 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 869.65 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 506.25 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 506.18 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 506.17 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 506.16 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 506.19 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 542.36 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 542.08 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 541.74 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 542.09 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 542.71 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 568.31 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 567.96 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 567.96 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 567.81 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 567.88 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 130, word aligned: 425.27 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 425.41 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 425.29 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 426.54 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 425.58 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 130, word aligned: 458.17 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 458.13 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 458.73 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 458.32 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 458.95 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 503.75 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 503.23 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 503.38 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 502.87 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 503.40 MB/s
kernel copy_from_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 486.47 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 485.02 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 485.65 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 485.20 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 485.11 MB/s
kernel copy_to_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 456.43 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 455.72 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 455.60 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 455.58 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 456.06 MB/s
libc memcpy:
4096 bytes page aligned: 2733.85 MB/s
4096 bytes page aligned: 2734.82 MB/s
4096 bytes page aligned: 2735.47 MB/s
4096 bytes page aligned: 2733.74 MB/s
4096 bytes page aligned: 2735.10 MB/s
kernel memcpy (original):
4096 bytes page aligned: 2763.15 MB/s
4096 bytes page aligned: 2764.57 MB/s
4096 bytes page aligned: 2762.87 MB/s
4096 bytes page aligned: 2764.31 MB/s
4096 bytes page aligned: 2763.97 MB/s
kernel memcpy (optimized):
4096 bytes page aligned: 2021.61 MB/s
4096 bytes page aligned: 2022.85 MB/s
4096 bytes page aligned: 2021.30 MB/s
4096 bytes page aligned: 2022.75 MB/s
4096 bytes page aligned: 2021.18 MB/s
kernel copy_page (original):
4096 bytes page aligned: 1536.64 MB/s
4096 bytes page aligned: 1536.07 MB/s
4096 bytes page aligned: 1536.62 MB/s
4096 bytes page aligned: 1536.44 MB/s
4096 bytes page aligned: 1536.04 MB/s
kernel copy_page (optimized):
4096 bytes page aligned: 2029.46 MB/s
4096 bytes page aligned: 2028.46 MB/s
4096 bytes page aligned: 2029.26 MB/s
4096 bytes page aligned: 2028.49 MB/s
4096 bytes page aligned: 2029.51 MB/s
libc memcpy:
Mixed from 1 to 1023 (power law), unaligned: 677.42 MB/s
Mixed from 1 to 1023 (power law), unaligned: 677.45 MB/s
Mixed from 1 to 1023 (power law), unaligned: 677.43 MB/s
Mixed from 1 to 1023 (power law), unaligned: 677.49 MB/s
Mixed from 1 to 1023 (power law), unaligned: 677.55 MB/s
kernel memcpy (original):
Mixed from 1 to 1023 (power law), unaligned: 705.91 MB/s
Mixed from 1 to 1023 (power law), unaligned: 705.96 MB/s
Mixed from 1 to 1023 (power law), unaligned: 706.14 MB/s
Mixed from 1 to 1023 (power law), unaligned: 706.18 MB/s
Mixed from 1 to 1023 (power law), unaligned: 706.32 MB/s
kernel memcpy (optimized):
Mixed from 1 to 1023 (power law), unaligned: 671.04 MB/s
Mixed from 1 to 1023 (power law), unaligned: 671.49 MB/s
Mixed from 1 to 1023 (power law), unaligned: 671.19 MB/s
Mixed from 1 to 1023 (power law), unaligned: 671.87 MB/s
Mixed from 1 to 1023 (power law), unaligned: 671.50 MB/s
libc memset:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1288.97 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1288.99 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1288.74 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1288.95 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1288.51 MB/s
kernel memset (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1698.82 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1695.12 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1695.28 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1699.55 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1698.91 MB/s
kernel memset (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1826.35 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1826.33 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1833.66 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1833.25 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1834.97 MB/s
kernel memzero (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1608.61 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1603.63 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1606.36 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1608.51 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1607.49 MB/s
kernel memzero (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1654.00 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1653.34 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1653.09 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1647.16 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1653.98 MB/s
libc memset:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 779.98 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 780.05 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 779.98 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 780.09 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 779.82 MB/s
kernel memset (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 971.07 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 969.65 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 969.63 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 969.63 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 969.45 MB/s
kernel memset (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1166.68 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1166.31 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1166.68 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1166.41 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1166.45 MB/s
kernel memzero (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 915.94 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 915.88 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 916.08 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 915.77 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 915.94 MB/s
kernel memzero (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 980.79 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 981.17 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 981.46 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 981.44 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 981.17 MB/s
libc memset:
4096 bytes page aligned: 2808.48 MB/s
4096 bytes page aligned: 2809.23 MB/s
4096 bytes page aligned: 2809.10 MB/s
4096 bytes page aligned: 2808.32 MB/s
4096 bytes page aligned: 2808.85 MB/s
kernel memset (original):
4096 bytes page aligned: 4285.77 MB/s
4096 bytes page aligned: 4286.95 MB/s
4096 bytes page aligned: 4285.80 MB/s
4096 bytes page aligned: 4287.03 MB/s
4096 bytes page aligned: 4286.30 MB/s
kernel memset (optimized):
4096 bytes page aligned: 4332.88 MB/s
4096 bytes page aligned: 4333.13 MB/s
4096 bytes page aligned: 4332.22 MB/s
4096 bytes page aligned: 4333.00 MB/s
4096 bytes page aligned: 4331.64 MB/s
kernel memzero (original):
4096 bytes page aligned: 4286.68 MB/s
4096 bytes page aligned: 4286.68 MB/s
4096 bytes page aligned: 4286.96 MB/s
4096 bytes page aligned: 4286.31 MB/s
4096 bytes page aligned: 4285.41 MB/s
kernel memzero (optimized):
4096 bytes page aligned: 4307.47 MB/s
4096 bytes page aligned: 4306.33 MB/s
4096 bytes page aligned: 4307.97 MB/s
4096 bytes page aligned: 4305.94 MB/s
4096 bytes page aligned: 4307.61 MB/s
libc memset:
Mixed from 1 to 1023 (power law), unaligned: 1150.12 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1149.80 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1150.06 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1149.76 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1149.91 MB/s
kernel memset (original):
Mixed from 1 to 1023 (power law), unaligned: 1482.23 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1483.26 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1483.42 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1482.48 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1483.19 MB/s
kernel memset (optimized):
Mixed from 1 to 1023 (power law), unaligned: 1683.39 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1680.19 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1681.58 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1680.15 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1680.06 MB/s
kernel memzero (original):
Mixed from 1 to 1023 (power law), unaligned: 1357.13 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1357.31 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1356.41 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1357.16 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1356.60 MB/s
kernel memzero (optimized):
Mixed from 1 to 1023 (power law), unaligned: 1469.08 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1470.31 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1469.47 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1468.80 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1469.37 MB/s
-------------- next part --------------
libc memcpy:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 869.54 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 869.27 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 869.78 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 869.52 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 869.50 MB/s
kernel memcpy (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 954.22 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 954.17 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 954.16 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 954.08 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 954.19 MB/s
kernel memcpy (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 852.17 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 852.53 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 852.37 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 852.44 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 852.45 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 455.51 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 457.69 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 455.01 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 455.30 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 455.68 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 512.36 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 512.02 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 512.47 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 512.47 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 512.66 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 538.32 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 537.83 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 538.36 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 538.29 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 539.25 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 130, word aligned: 392.90 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 388.25 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 388.67 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 392.51 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 392.09 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 130, word aligned: 433.21 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 433.73 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 433.34 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 433.91 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 433.43 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 474.10 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 474.06 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 474.29 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 474.10 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 473.95 MB/s
kernel copy_from_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 455.22 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 455.10 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 454.55 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 454.71 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 454.86 MB/s
kernel copy_to_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 429.08 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 429.08 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 429.42 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 429.12 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 429.59 MB/s
libc memcpy:
4096 bytes page aligned: 2698.97 MB/s
4096 bytes page aligned: 2703.85 MB/s
4096 bytes page aligned: 2706.42 MB/s
4096 bytes page aligned: 2701.26 MB/s
4096 bytes page aligned: 2699.65 MB/s
kernel memcpy (original):
4096 bytes page aligned: 2735.92 MB/s
4096 bytes page aligned: 2735.76 MB/s
4096 bytes page aligned: 2739.53 MB/s
4096 bytes page aligned: 2737.95 MB/s
4096 bytes page aligned: 2735.23 MB/s
kernel memcpy (optimized):
4096 bytes page aligned: 2016.76 MB/s
4096 bytes page aligned: 2015.85 MB/s
4096 bytes page aligned: 2016.87 MB/s
4096 bytes page aligned: 2015.99 MB/s
4096 bytes page aligned: 2018.49 MB/s
kernel copy_page (original):
4096 bytes page aligned: 1533.05 MB/s
4096 bytes page aligned: 1533.36 MB/s
4096 bytes page aligned: 1533.81 MB/s
4096 bytes page aligned: 1533.62 MB/s
4096 bytes page aligned: 1533.05 MB/s
kernel copy_page (optimized):
4096 bytes page aligned: 2016.48 MB/s
4096 bytes page aligned: 2019.79 MB/s
4096 bytes page aligned: 2016.49 MB/s
4096 bytes page aligned: 2017.68 MB/s
4096 bytes page aligned: 2018.23 MB/s
libc memcpy:
Mixed from 1 to 1023 (power law), unaligned: 640.12 MB/s
Mixed from 1 to 1023 (power law), unaligned: 640.23 MB/s
Mixed from 1 to 1023 (power law), unaligned: 640.13 MB/s
Mixed from 1 to 1023 (power law), unaligned: 640.34 MB/s
Mixed from 1 to 1023 (power law), unaligned: 640.36 MB/s
kernel memcpy (original):
Mixed from 1 to 1023 (power law), unaligned: 681.11 MB/s
Mixed from 1 to 1023 (power law), unaligned: 680.79 MB/s
Mixed from 1 to 1023 (power law), unaligned: 681.19 MB/s
Mixed from 1 to 1023 (power law), unaligned: 680.93 MB/s
Mixed from 1 to 1023 (power law), unaligned: 681.05 MB/s
kernel memcpy (optimized):
Mixed from 1 to 1023 (power law), unaligned: 645.50 MB/s
Mixed from 1 to 1023 (power law), unaligned: 644.98 MB/s
Mixed from 1 to 1023 (power law), unaligned: 645.10 MB/s
Mixed from 1 to 1023 (power law), unaligned: 644.91 MB/s
Mixed from 1 to 1023 (power law), unaligned: 645.03 MB/s
libc memset:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1246.47 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1246.77 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1246.49 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1246.87 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1246.58 MB/s
kernel memset (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1609.02 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1612.50 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1612.66 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1614.68 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1609.93 MB/s
kernel memset (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1744.85 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1747.18 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1748.65 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1745.03 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1745.42 MB/s
kernel memzero (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1509.51 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1510.41 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1509.70 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1508.00 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1508.73 MB/s
kernel memzero (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1615.44 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1617.76 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1612.05 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1616.54 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1610.91 MB/s
libc memset:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 735.51 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 735.65 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 735.62 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 735.75 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 735.83 MB/s
kernel memset (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 884.22 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 884.39 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 884.11 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 885.90 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 884.09 MB/s
kernel memset (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1025.79 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1025.70 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1025.98 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1025.56 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1025.59 MB/s
kernel memzero (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 831.09 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 830.34 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 830.77 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 830.50 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 830.64 MB/s
kernel memzero (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 919.83 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 920.16 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 919.50 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 919.75 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 920.02 MB/s
libc memset:
4096 bytes page aligned: 2789.85 MB/s
4096 bytes page aligned: 2790.47 MB/s
4096 bytes page aligned: 2789.64 MB/s
4096 bytes page aligned: 2790.60 MB/s
4096 bytes page aligned: 2789.42 MB/s
kernel memset (original):
4096 bytes page aligned: 4292.31 MB/s
4096 bytes page aligned: 4292.19 MB/s
4096 bytes page aligned: 4291.39 MB/s
4096 bytes page aligned: 4291.91 MB/s
4096 bytes page aligned: 4291.29 MB/s
kernel memset (optimized):
4096 bytes page aligned: 4321.51 MB/s
4096 bytes page aligned: 4319.98 MB/s
4096 bytes page aligned: 4321.53 MB/s
4096 bytes page aligned: 4319.93 MB/s
4096 bytes page aligned: 4321.46 MB/s
kernel memzero (original):
4096 bytes page aligned: 4243.19 MB/s
4096 bytes page aligned: 4242.35 MB/s
4096 bytes page aligned: 4243.32 MB/s
4096 bytes page aligned: 4242.29 MB/s
4096 bytes page aligned: 4243.34 MB/s
kernel memzero (optimized):
4096 bytes page aligned: 4261.67 MB/s
4096 bytes page aligned: 4262.59 MB/s
4096 bytes page aligned: 4262.13 MB/s
4096 bytes page aligned: 4262.75 MB/s
4096 bytes page aligned: 4262.62 MB/s
libc memset:
Mixed from 1 to 1023 (power law), unaligned: 1084.53 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1084.89 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1084.61 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1084.71 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1084.43 MB/s
kernel memset (original):
Mixed from 1 to 1023 (power law), unaligned: 1364.45 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1363.67 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1364.87 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1364.47 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1364.17 MB/s
kernel memset (optimized):
Mixed from 1 to 1023 (power law), unaligned: 1508.02 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1510.44 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1508.57 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1508.86 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1510.14 MB/s
kernel memzero (original):
Mixed from 1 to 1023 (power law), unaligned: 1261.52 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1261.24 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1262.57 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1260.26 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1261.35 MB/s
kernel memzero (optimized):
Mixed from 1 to 1023 (power law), unaligned: 1412.76 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1412.17 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1413.32 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1412.77 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1413.13 MB/s

From sebastian.hesselbarth at gmail.com  Sat Jul 13 13:36:39 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Sat, 13 Jul 2013 19:36:39 +0200
Subject: DT binding review for Armada display subsystem
In-Reply-To: <CAMLZHHSrX2T+pU3RosmjS3EggV3mX_J8D2OJD52sww_n6Y7B+A@mail.gmail.com>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <20130712203952.6b7aa927@armhf>
 <CAMLZHHT1oAvOLe3JgQqMqLNXEr0NGrdtgELtF_djbqLFceHtiQ@mail.gmail.com>
 <20130713103516.38a55b0b@armhf>
 <CAMLZHHSrX2T+pU3RosmjS3EggV3mX_J8D2OJD52sww_n6Y7B+A@mail.gmail.com>
Message-ID: <51E19027.9000107@gmail.com>

On 07/13/2013 04:25 PM, Daniel Drake wrote:
> On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine <moinejf at free.fr> wrote:
>> I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
>> driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
>> modules. I set 3 clocks in the DT for the LCD0: lcdclk, axi and extclk0
>> (si5351). Normally, the external clock is used, but, sometimes, the
>> si5351 module is not yet initialized when the drm driver starts. So,
>> for 1920x1080p, it uses the lcdclk which sets the LCD clock to 133333
>> (400000/3) instead of 148500. As a result, display and sound still work
>> correctly on my TV set thru HDMI.
>>
>> So, it would be nice to have 2 usable clocks per LCD, until we find a
>> good way to initialize the modules in the right order at startup time.
>
> Having multiple usable clocks is implemented in the patch I referred
> you to. However it doesn't solve the "better clock turns up after
> initializing the driver" problem, which seems like a tricky one.
>
> Maybe the best solution is to defer probe until all DT-defined clocks
> become available. That means that whoever compiles the kernel must
> take care to not forget to build the clock drivers for all the clocks
> referenced in this part of the DT, but perhaps that is a reasonable
> thing to require.
>
> On the other hand, this problem acts in support of a simpler approach
> mentioned by Sebastian: developers figure out what the best clock is
> for each CRTC on each board, and the DT only specifies that one clock.
> The driver uses that clock if it is available and defers probe if it
> is not.

Daniel,

sorry for the late response, I just came back from a boat trip around
Capri :D

About the clocks and deferred probing, the issue here is that you might
have trouble to find out if that clock will ever come up. Therefore, I
suggested the easiest heuristic which is "let the DT author decide".

I am fine with allowing more than one clock from DT and get or wait for
all/one clock.

>> Back to the specific case of the Cubox with new ideas.
>>
>> The Cubox is based on the Armada 510 (Dove), so, all the hardware must
>> be described in dove.dtsi. This includes the LCDs and DCON/IRE, the
>> possible clocks and the (static) v4l2 links:
>
> As a sidenote, I think we have concluded that we are not going to
> interact with the armada 510 DCON in any way at the moment. The driver
> will not have code that touches it, and the DT will not mention it.
> The first person who actually needs to use the DCON will have the
> responsibility for doing that work. Nevertheless it makes sense for us
> to pick a DT design where we know that the DCON could be slotted in
> later.

True, do not link dcon node with any of lcd, tda998x or anything else.
If there is support for it in the driver we just use
of_find_compatible_node and let the driver do the magic. From a physical
POV, lcd0 is directly connected to tda998x through dumb RGB pins. DCON
can control data flow to those pins but should not be DT linked.

>>          lcd0: lcd-controller at 820000 {
>>                  compatible = "marvell,dove-lcd0";
>>                  reg = <0x820000 0x1c8>;
>>                  interrupts = <47>;
>>                  clocks = <&core_clk 3>, <&lcdclk>;
>>                  clock-names = "axi", "lcdclk";

About clock names for Armada 510 LCD: I suggest "axiclk", "lcdpll", 
"extclk0", "extclk1". IIRC axiclk is 333MHz (or maybe 2xTCLK),
lcdpll can be derived from 2GHz core PLL with min integer divider
of 5. extclk0/1 are dedicated pins and can be used from both lcd0
and lcd1.

>>                  marvell-output = <&dcon 0>;
>>                  status = "disabled";
>>          };
>>
>>          lcd1: lcd-controller at 810000 {
>>                  compatible = "marvell,dove-lcd1";
>>                  reg = <0x810000 0x1c8>;
>>                  interrupts = <46>;
>>                  clocks = <&core_clk 3>, <&lcdclk>;
>>                  clock-names = "axi", "lcdclk";
>>                  marvell-output = <&dcon 1>;
>>                  status = "disabled";
>>          };
>>
>>          /* display controller and image rotation engine */
>>          dcon: display-controller at 830000 {
>>                  compatible = "marvell,dove-dcon";
>>                  reg = <0x830000 0xc4>,                  /* DCON */
>>                        <0x831000 0x8c>;                  /* IRE */
>>                  interrupts = <45>;
>>                  marvell-input = <&lcd0>, <&lcd1>;
>>                  status = "disabled";
>>          };
>
> I guess the IRE falls into the same category as the DCON - we won't
> implement it for now, but knowing where it might fit in is useful.
>
> Why would you put it in the same node as the DCON though? It has its
> own separate register space and additionally it is a component shared
> with the MMP boards (whereas the DCON is not).

DCON and IRE are summarized in the same register description in Dove FS.
Maybe we can split them up and have two nodes or just one if registers
overlap. Anyway, not that important for now.

>> The specific Cubox hardware (tda998x and si5351) is described in
>> dove-cubox.dts, with the new clocks and the v4l2 link dcon0 <--> tda998x.
>>
>>          &i2c0 {
>>                  si5351: clock-generator {
>>                          ...
>>                  };
>>                  tda998x: hdmi-encoder {
>>                          compatible = "nxp,tda998x";
>>                          reg = <0x70>;
>>                          interrupt-parent = <&gpio0>;
>>                          interrupts = <27 2>;            /* falling edge */
>>                          marvell-input = <&dcon 0>;
>>                  };
>>          };
>>          &lcd0 {
>>                  status = "okay";
>>                  clocks = <&si5351 0>;
>>                  clock-names = "extclk0";
>>          };
>>          &dcon {
>>                  status = "okay";
>>                  marvell-output = <&tda998x>, 0;         /* no connector on port B */
>>          };
>
> So now you are taking an approach equivalent to the v4l2 standard
> "video interfaces" binding, which is the concept of representing a
> connection graph via phandles. This means that our two proposals are
> equivalent yet I proposed using a standard interface and you proposed
> inventing your own, again without explaining why you don't like the
> standard interface.

I suggest to choose the same names v4l2 did, they are the first and
as long as the use case matches, we should reuse their names.

>> Then, about the software, the drm driver may not need to know anything
>> more (it scans the DT for the LCDs and gets all the subdevices thanks
>> to the v4l2 links):
>>
>>          video {
>>                  compatible = "marvell,armada-video";
>>          };
>>
>> For some boards / other SoCs, there may be independant drm devices. In
>> this case, there would be descriptions as:
>>
>>          video0 {
>>                  compatible = "marvell,armada-video0";
>>                  marvell,video-devices = <&lcd0>;
>>          };
>>          video1 {
>>                  compatible = "marvell,armada-video1";
>>                  marvell,video-devices = <&lcd1>;
>>          };
>
> This bit differs from my proposal, but I'm not sure what the benefit
> of your design is. In my design, the two above use cases are
> represented cleanly using the same DT abstraction (same compatible
> string, same required properties, etc). In your design, the two use
> cases call for something quite different as shown above.

Of course, compatible string of both (virtual) video devices should
be "marvell,armada-510-video" or if you prefer to follow Sascha Hauer's
suggestion reuse the lcd controller node instead of the "super node".

Sebastian


From linux at arm.linux.org.uk  Sat Jul 13 13:38:47 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 13 Jul 2013 18:38:47 +0100
Subject: DT binding review for Armada display subsystem
In-Reply-To: <CAMLZHHSrX2T+pU3RosmjS3EggV3mX_J8D2OJD52sww_n6Y7B+A@mail.gmail.com>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <20130712203952.6b7aa927@armhf>
 <CAMLZHHT1oAvOLe3JgQqMqLNXEr0NGrdtgELtF_djbqLFceHtiQ@mail.gmail.com>
 <20130713103516.38a55b0b@armhf>
 <CAMLZHHSrX2T+pU3RosmjS3EggV3mX_J8D2OJD52sww_n6Y7B+A@mail.gmail.com>
Message-ID: <20130713173847.GN24642@n2100.arm.linux.org.uk>

On Sat, Jul 13, 2013 at 08:25:15AM -0600, Daniel Drake wrote:
> I guess the IRE falls into the same category as the DCON - we won't
> implement it for now, but knowing where it might fit in is useful.

I don't see much need at the moment for IRE.  IRE isn't going to be
useful for general graphics rotation as it only supports up to 16bpp
RGB.

It looks to me like this module was designed to rotate YUV/camera
images.  If we wanted to rotate a video image, then it would probably
be more efficient to use this, but it will cause a conversion of the
image format in doing so.


From sebastian.hesselbarth at gmail.com  Sat Jul 13 13:44:58 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Sat, 13 Jul 2013 19:44:58 +0200
Subject: DT binding review for Armada display subsystem
In-Reply-To: <20130713111239.GM24642@n2100.arm.linux.org.uk>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <20130712203952.6b7aa927@armhf>
 <CAMLZHHT1oAvOLe3JgQqMqLNXEr0NGrdtgELtF_djbqLFceHtiQ@mail.gmail.com>
 <20130713103516.38a55b0b@armhf> <51E13272.5040903@gmail.com>
 <20130713111239.GM24642@n2100.arm.linux.org.uk>
Message-ID: <51E1921A.3070207@gmail.com>

On 07/13/2013 01:12 PM, Russell King - ARM Linux wrote:
> On Sat, Jul 13, 2013 at 12:56:50PM +0200, Sylwester Nawrocki wrote:
>> On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
>>> On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake<dsd at laptop.org>  wrote:
>>>> On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine<moinejf at free.fr>  wrote:
>>
>>>>> - the phandles to the clocks does not tell how the clock may be set by
>>>>>     the driver (it is an array index in the 510).
>>>>
>>>> In the other threads on clock selection, we decided that that exact
>>>> information on how to select a clock (i.e. register bits/values) must
>>>> be in the driver, not in the DT. What was suggested there is a
>>>> well-documented scheme for clock naming, so the driver knows which
>>>> clock is which. That is defined in the proposed DT binding though the
>>>> "valid clock names" part. For an example driver implementation of this
>>>> you can see my patch "armada_drm clock selection - try 2".
>>>
>>> OK.
>>>
>>> Sorry to go back to this thread.
>>>
>>> I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
>>> driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
>>> modules. I set 3 clocks in the DT for the LCD0: lcdclk, axi and extclk0
>>
>> Hmm, a bit off topic question, does it work when the si5351 module gets
>> removed ? I can't see anything preventing clock provider module from being
>> removed why any of its clocks is used and clk_unregister() function is
>> currently unimplemented.
>
> When I designed the clk API, I arranged for things like clk_get() to
> take a reference on the module if the clock was supplied by a module.
> You'll see some evidence of that by looking back in the git history
> for arch/arm/mach-integrator/include/mach/clkdev.h.

Last time I checked, clkdev API neither implements referencing nor
unregister. This is on Mike's list and IIRC there already has been
a proposal for unregister. Si5351 was the first clkdev driver ever
that could possibly be unloaded, so there may be still some features
missing.

> If the common clk API has been designed without any thought to clocks
> supplied by modules and making sure that in-use clocks don't go away,
> then it's going to be a real pain to sort that out.  I don't think
> refcounting clocks makes sense (what do you do with an enabled clock
> that you then remove the module for but it's still being used?  Do you
> just shut it down anyway?  Do you leave it running?  What about
> subsequent calls?).

Good point, first I thought always disable on last user dropping it but
that may most likely break some platforms. Second thought, get back to
the state when the driver was loaded.

> I think this is one case where taking a reference on the module supplying
> it makes total sense.
>
>>> (si5351). Normally, the external clock is used, but, sometimes, the
>>> si5351 module is not yet initialized when the drm driver starts. So,
>>> for 1920x1080p, it uses the lcdclk which sets the LCD clock to 133333
>>> (400000/3) instead of 148500. As a result, display and sound still work
>>> correctly on my TV set thru HDMI.
>>>
>>> So, it would be nice to have 2 usable clocks per LCD, until we find a
>>> good way to initialize the modules in the right order at startup time.
>>
>> Doesn't deferred probing help here ?
>
> Indeed it does.  Just because one TV works with such a wrong clock does not
> mean that all TVs and HDMI compatible monitors will do.  It's 11% out.
>
> The reason that audio works is because of the way the HDMI transmitter works
> - it can calculate the CTS value to send (by measuring it) and it sends that
> value over the link so the TV can regenerate the correct audio clock from
> the HDMI clock.

True, wrong clock will most likely not work on all monitors or TV. My
impression for TVs is that the the "cheaper" the brand is, the more
likely they accept any mode/clock combination ;)

> Whether that's going to be universally true, I don't know - it depends on
> how much audio data gets sent via each frame.  As the HDMI clock is slower,
> there would need to be more audio data sent.

Also: audio/video clock relation is sent in AVI packets over HDMI.
Picking a clock with 11% off may not even allow you to send (valid) CTS
information.

>>> 	lcd0: lcd-controller at 820000 {
>>> 		compatible = "marvell,dove-lcd0";
>> [...]
>>> 	};
>>>
>>> 	lcd1: lcd-controller at 810000 {
>>> 		compatible = "marvell,dove-lcd1";
>> [...]
>>> 	};
>>
>> Using different compatible strings to indicate multiple instances of same
>> hardware doesn't seem right. Unless LCD0, LCD1 are really different pieces
>
> They aren't.  They're 100% identical in the Armada 510.
>
>> of hardware incompatible with each other I think it would be more correct
>> to use same compatible property and DT node aliases, similarly as is now
>> done with e.g. I2C busses:
>>
>> 	aliases {
>> 		lcd0 = &lcd_0;	
>> 		lcd1 = &lcd_1;	
>> 	};
>>
>>   	lcd_0: lcd-controller at 820000 {
>>   		compatible = "marvell,dove-lcd";
>
> I'd much prefer marvell,armada-510-lcd rather than using the codenames for
> the devices.  Otherwise we're going to run into totally different things
> being used for different devices (eg, armada-xp...)
>

+1 for using marvell,armada-510-lcd. I like the nick-name "dove" but
armada-510 is much easier to find on Marvell's website.

Sebastian


From olof at lixom.net  Sat Jul 13 15:56:25 2013
From: olof at lixom.net (Olof Johansson)
Date: Sat, 13 Jul 2013 12:56:25 -0700
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <20130710215041.GR11908@titan.lakedaemon.net>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <CAN1soZxiOh6TpbUOCUzK8gNwmvjbT3ihkUWaw8tuZ7md+NVA2g@mail.gmail.com>
 <20130710122433.GO11908@titan.lakedaemon.net>
 <CAN1soZzMvront1-jcBW6-uRKNs0OZNGnmiOjKGZSM28bViB_8A@mail.gmail.com>
 <20130710215041.GR11908@titan.lakedaemon.net>
Message-ID: <CAOesGMi-J5OE998umtyt7awP3nW7iEHFdSiks0aOotsozLJ5pw@mail.gmail.com>

On Wed, Jul 10, 2013 at 2:50 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> On Wed, Jul 10, 2013 at 10:08:50PM +0800, Haojian Zhuang wrote:
>> On Wed, Jul 10, 2013 at 8:24 PM, Jason Cooper <jason at lakedaemon.net> wrote:
>> > On Wed, Jul 10, 2013 at 04:19:46PM +0800, Haojian Zhuang wrote:
>> >> On Tue, Jul 9, 2013 at 8:49 PM, Jason Cooper <jason at lakedaemon.net> wrote:
>> >> > Neil,
>> >> >
>> >> > On Tue, Jul 09, 2013 at 02:42:44PM +0800, Neil Zhang wrote:
>> >> >> The documented vendor prefix for Marvell is 'marvell', not 'mrvl', so
>> >> >> let's change it.
>> >> >>
>> >> >> Signed-off-by: Neil Zhang <zhangwm at marvell.com>
>> >> >> ---
>> >> >>  .../devicetree/bindings/arm/mrvl/intc.txt          |   16 +++---
>> >> >>  .../devicetree/bindings/arm/mrvl/mrvl.txt          |    6 +-
>> >> >>  .../devicetree/bindings/arm/mrvl/timer.txt         |    4 +-
>> >> >>  Documentation/devicetree/bindings/i2c/i2c-pxa.txt  |   14 +++---
>> >> >>  .../devicetree/bindings/mmc/sdhci-pxa.txt          |    8 ++--
>> >> >>  .../devicetree/bindings/rtc/sa1100-rtc.txt         |    4 +-
>> >> >>  .../devicetree/bindings/serial/mrvl-serial.txt     |    2 +-
>> >> >>  arch/arm/boot/dts/mmp2-brownstone.dts              |    2 +-
>> >> >>  arch/arm/boot/dts/mmp2.dtsi                        |   56 ++++++++++----------
>> >> >>  arch/arm/boot/dts/pxa168-aspenite.dts              |    2 +-
>> >> >>  arch/arm/boot/dts/pxa168.dtsi                      |   24 ++++----
>> >> >>  arch/arm/boot/dts/pxa2xx.dtsi                      |   16 +++---
>> >> >>  arch/arm/boot/dts/pxa3xx.dtsi                      |    2 +-
>> >> >>  arch/arm/boot/dts/pxa910-dkb.dts                   |    2 +-
>> >> >>  arch/arm/boot/dts/pxa910.dtsi                      |   27 +++++-----
>> >> >>  arch/arm/mach-mmp/irq.c                            |   16 +++---
>> >> >>  arch/arm/mach-mmp/mmp-dt.c                         |   28 +++++-----
>> >> >>  arch/arm/mach-mmp/mmp2-dt.c                        |   16 +++---
>> >> >>  arch/arm/mach-mmp/time.c                           |    2 +-
>> >> >>  arch/arm/mach-pxa/pxa-dt.c                         |   14 +++---
>> >> >>  drivers/i2c/busses/i2c-pxa.c                       |   10 ++--
>> >> >>  drivers/mmc/host/sdhci-pxav2.c                     |    4 +-
>> >> >>  drivers/mmc/host/sdhci-pxav3.c                     |    4 +-
>> >> >>  drivers/rtc/rtc-sa1100.c                           |    4 +-
>> >> >>  drivers/tty/serial/pxa.c                           |    4 +-
>> >> >>  25 files changed, 144 insertions(+), 143 deletions(-)
>> >> >
>> >> > I agree with the need to change, however, this has been in the binding
>> >> > documentation since v3.5.  I wish we had caught this when we decided
>> >> > against using stock ticker symbols (not all stock markets use
>> >> > alphabetical abbreviated names, not all companies are listed on any
>> >> > stock exchange).
>> >> >
>> >> > To do this properly, the drivers are going to have to be compatible with
>> >> > the old and the new names, and the binding docs updated to reflect the
>> >> > legacy name and the preferred name.
>> >> >
>> >>
>> >> It's better to only use the new names.
>> >
>> > In the dts{i}, yes.  But we don't want to break systems in the field
>> > with "mrvl,..." compatible strings.  Therefore, at least the drivers
>> > need an extra compatible string to support "mrvl,...".
>> >
>> > If it had just been since v3.9, it'd be different/simpler.  However,
>> > several vendors have opted to use kernels newer than v3.5, which makes
>> > this scenario a real possibility.
>> >
>> > thx,
>> >
>> > Jason.
>>
>> Is there any vendor using DT for this Marvell chip? I think the answer is no.
>
> Well, Daniel Drake spoke up for OLPC.  Does that count?

There's stock ticker history for MRVL is available for at least as far
back as 2001, so it's been around for a while. I would argue that the
powerpc guys made a mistake by using the marvell prefix. Either way,
they are not likely to add any new driver or code anytime soon for
these platforms.

Given that we are using mrvl extensively already, I'd say the way
forward is to make the driver handle both compatible values, but only
use mrvl for new code and for all new device tree bindings/data on
ARM.

It's a known issue that we are still in an "in-flux" state when it
comes to bindings on ARM, where people have been free to change them
as needed. At Linaro Connect last week, a group of us got together to
discuss this and I hope that Grant (or maybe someone else) will be
able to post those notes. We have a proposal on how to start moving
away from _everything_ being unstable to a model where parts of the
bindings can be locked down over time to a state where they won't
change. But I won't preempt the proper proposal email by going into
details here.



-Olof


From pebolle at tiscali.nl  Sat Jul 13 16:09:51 2013
From: pebolle at tiscali.nl (Paul Bolle)
Date: Sat, 13 Jul 2013 22:09:51 +0200
Subject: [PATCH] ARM: multiplatform: remove reference to ARCH_MULTI_V4
Message-ID: <1373746191.1359.37.camel@x61.thuisdomein>

The Kconfig symbol ARCH_MULTI_V4 was removed in commit 24e860fbfd
("ARM: multiplatform: always pick one CPU type"). Remove the last
reference to it too.

Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
---
0) Untested.

1) Commit 24e860fbfd is silent on the reason to drop ARCH_MULTI_V4. And
the ARM section of the Kconfig files is rather complicated for people,
like me, that aren't familiar with the way the ARM universe is divided
in architectures, machines, platforms, etc. That makes it hard to say
whether ARCH_MULTI_V4 was dropped on purpose or by accident.

 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0ac9be6..0746bc8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -912,7 +912,7 @@ config ARCH_MULTI_V6_V7
 	bool
 
 config ARCH_MULTI_CPU_AUTO
-	def_bool !(ARCH_MULTI_V4 || ARCH_MULTI_V4T || ARCH_MULTI_V6_V7)
+	def_bool !(ARCH_MULTI_V4T || ARCH_MULTI_V6_V7)
 	select ARCH_MULTI_V5
 
 endmenu
-- 
1.8.1.4



From sylvester.nawrocki at gmail.com  Sat Jul 13 16:43:29 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Sat, 13 Jul 2013 22:43:29 +0200
Subject: DT binding review for Armada display subsystem
In-Reply-To: <51E1921A.3070207@gmail.com>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <20130712203952.6b7aa927@armhf>
 <CAMLZHHT1oAvOLe3JgQqMqLNXEr0NGrdtgELtF_djbqLFceHtiQ@mail.gmail.com>
 <20130713103516.38a55b0b@armhf> <51E13272.5040903@gmail.com>
 <20130713111239.GM24642@n2100.arm.linux.org.uk> <51E1921A.3070207@gmail.com>
Message-ID: <51E1BBF1.1020009@gmail.com>

On 07/13/2013 07:44 PM, Sebastian Hesselbarth wrote:
> On 07/13/2013 01:12 PM, Russell King - ARM Linux wrote:
>> On Sat, Jul 13, 2013 at 12:56:50PM +0200, Sylwester Nawrocki wrote:
>>> On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
>>>> On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake<dsd at laptop.org> wrote:
>>>>> On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois
>>>>> Moine<moinejf at free.fr> wrote:
[...]
>>>> I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
>>>> driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
>>>> modules. I set 3 clocks in the DT for the LCD0: lcdclk, axi and extclk0
>>>
>>> Hmm, a bit off topic question, does it work when the si5351 module gets
>>> removed ? I can't see anything preventing clock provider module from
>>> being
>>> removed why any of its clocks is used and clk_unregister() function is
>>> currently unimplemented.
>>
>> When I designed the clk API, I arranged for things like clk_get() to
>> take a reference on the module if the clock was supplied by a module.
>> You'll see some evidence of that by looking back in the git history
>> for arch/arm/mach-integrator/include/mach/clkdev.h.
>
> Last time I checked, clkdev API neither implements referencing nor
> unregister. This is on Mike's list and IIRC there already has been
> a proposal for unregister. Si5351 was the first clkdev driver ever

I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it seems
they're working on v4 with clock object reference counting. Presumably we
need both clk_get() to be taking reference on the module and reference
counted clk free, e.g. in cases where clock provider is a hot-pluggable
device. It might be too paranoid though, I haven't seen hardware
configurations where a clock source could be unplugged safely when whole
system is running.

> that could possibly be unloaded, so there may be still some features
> missing.

I guess there should be a warning in e.g. Kconfig saying that it is safe
to use this driver only with CONFIG_MODULE_UNLOAD or something similar.
Otherwise users might not be happy and might start filling bug reports. :)

>> If the common clk API has been designed without any thought to clocks
>> supplied by modules and making sure that in-use clocks don't go away,
>> then it's going to be a real pain to sort that out. I don't think
>> refcounting clocks makes sense (what do you do with an enabled clock
>> that you then remove the module for but it's still being used? Do you
>> just shut it down anyway? Do you leave it running? What about
>> subsequent calls?).
>
> Good point, first I thought always disable on last user dropping it but
> that may most likely break some platforms. Second thought, get back to
> the state when the driver was loaded.

When last user drops the reference it could be already too late to change
anything in hardware, since the clock provider module is already unloaded.

Anyway I suppose it's best to take reference on the clk provider module
in clk_get(). This can easily lead to circular dependencies though, when
e.g. a module A is a clock consumer of a clock provided by module B, and
module B calls back into module A, so it also takes reference on A.
The only solution I could think of is to call clk_get() only before a clock
is enabled and clk_put() right after it is disabled and stops being used.

>> I think this is one case where taking a reference on the module supplying
>> it makes total sense.
>>
>>>> (si5351). Normally, the external clock is used, but, sometimes, the
>>>> si5351 module is not yet initialized when the drm driver starts. So,
>>>> for 1920x1080p, it uses the lcdclk which sets the LCD clock to 133333
>>>> (400000/3) instead of 148500. As a result, display and sound still work
>>>> correctly on my TV set thru HDMI.
>>>>
>>>> So, it would be nice to have 2 usable clocks per LCD, until we find a
>>>> good way to initialize the modules in the right order at startup time.
>>>
>>> Doesn't deferred probing help here ?
>>
>> Indeed it does. Just because one TV works with such a wrong clock does
>> not
>> mean that all TVs and HDMI compatible monitors will do. It's 11% out.
>>
>> The reason that audio works is because of the way the HDMI transmitter
>> works
>> - it can calculate the CTS value to send (by measuring it) and it
>> sends that
>> value over the link so the TV can regenerate the correct audio clock from
>> the HDMI clock.
>
> True, wrong clock will most likely not work on all monitors or TV. My
> impression for TVs is that the the "cheaper" the brand is, the more
> likely they accept any mode/clock combination ;)
>
>> Whether that's going to be universally true, I don't know - it depends on
>> how much audio data gets sent via each frame. As the HDMI clock is
>> slower,
>> there would need to be more audio data sent.
>
> Also: audio/video clock relation is sent in AVI packets over HDMI.
> Picking a clock with 11% off may not even allow you to send (valid) CTS
> information.
>
>>>> lcd0: lcd-controller at 820000 {
>>>> compatible = "marvell,dove-lcd0";
>>> [...]
>>>> };
>>>>
>>>> lcd1: lcd-controller at 810000 {
>>>> compatible = "marvell,dove-lcd1";
>>> [...]
>>>> };
>>>
>>> Using different compatible strings to indicate multiple instances of
>>> same
>>> hardware doesn't seem right. Unless LCD0, LCD1 are really different
>>> pieces
>>
>> They aren't. They're 100% identical in the Armada 510.
>>
>>> of hardware incompatible with each other I think it would be more
>>> correct
>>> to use same compatible property and DT node aliases, similarly as is now
>>> done with e.g. I2C busses:
>>>
>>> aliases {
>>> lcd0 = &lcd_0;
>>> lcd1 = &lcd_1;
>>> };
>>>
>>> lcd_0: lcd-controller at 820000 {
>>> compatible = "marvell,dove-lcd";
>>
>> I'd much prefer marvell,armada-510-lcd rather than using the codenames
>> for
>> the devices. Otherwise we're going to run into totally different things
>> being used for different devices (eg, armada-xp...)
>>
>
> +1 for using marvell,armada-510-lcd. I like the nick-name "dove" but
> armada-510 is much easier to find on Marvell's website.

Indeed, I'm not much into Marvell SoCs details but "marvell,armada-510-lcd"
seems more clear.

--
Thanks,
Sylwester


From linux at arm.linux.org.uk  Sat Jul 13 16:51:52 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 13 Jul 2013 21:51:52 +0100
Subject: DT binding review for Armada display subsystem
In-Reply-To: <51E1921A.3070207@gmail.com>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <20130712203952.6b7aa927@armhf>
 <CAMLZHHT1oAvOLe3JgQqMqLNXEr0NGrdtgELtF_djbqLFceHtiQ@mail.gmail.com>
 <20130713103516.38a55b0b@armhf> <51E13272.5040903@gmail.com>
 <20130713111239.GM24642@n2100.arm.linux.org.uk> <51E1921A.3070207@gmail.com>
Message-ID: <20130713205152.GO24642@n2100.arm.linux.org.uk>

On Sat, Jul 13, 2013 at 07:44:58PM +0200, Sebastian Hesselbarth wrote:
> On 07/13/2013 01:12 PM, Russell King - ARM Linux wrote:
>> When I designed the clk API, I arranged for things like clk_get() to
>> take a reference on the module if the clock was supplied by a module.
>> You'll see some evidence of that by looking back in the git history
>> for arch/arm/mach-integrator/include/mach/clkdev.h.
>
> Last time I checked, clkdev API neither implements referencing nor
> unregister.

*Sigh*.

a613163dff04cbfcb7d66b06ef4a5f65498ee59b:
arch/arm/mach-integrator/include/mach/clkdev.h:
-struct clk {
-       unsigned long           rate;
-       const struct clk_ops    *ops;
-       struct module           *owner;
-       const struct icst_params *params;
-       void __iomem            *vcoreg;
-       void                    *data;
-};
-
-static inline int __clk_get(struct clk *clk)
-{
-       return try_module_get(clk->owner);
-}
-
-static inline void __clk_put(struct clk *clk)
-{
-       module_put(clk->owner);
-}

70ee65771424829fd092a1df9afcc7e24c94004b:
arch/arm/mach-integrator/impd1.c:
 static int impd1_probe(struct lm_device *dev)
...
-       for (i = 0; i < ARRAY_SIZE(impd1->vcos); i++) {
-               impd1->vcos[i].ops = &impd1_clk_ops,
-               impd1->vcos[i].owner = THIS_MODULE,
-               impd1->vcos[i].params = &impd1_vco_params,
-               impd1->vcos[i].data = impd1;
-       }
-       impd1->vcos[0].vcoreg = impd1->base + IMPD1_OSC1;
-       impd1->vcos[1].vcoreg = impd1->base + IMPD1_OSC2;
-
-       impd1->clks[0] = clkdev_alloc(&impd1->vcos[0], NULL, "lm%x:01000",
-                                       dev->id);
-       impd1->clks[1] = clkdev_alloc(&fixed_14745600, NULL, "lm%x:00100",
-                                       dev->id);
-       impd1->clks[2] = clkdev_alloc(&fixed_14745600, NULL, "lm%x:00200",
-                                       dev->id);
-       for (i = 0; i < ARRAY_SIZE(impd1->clks); i++)
-               clkdev_add(impd1->clks[i]);
...
 static void impd1_remove(struct lm_device *dev)
...
-       for (i = 0; i < ARRAY_SIZE(impd1->clks); i++)
-               clkdev_drop(impd1->clks[i]);

drivers/clk/clkdev.c:
/*
 * clkdev_drop - remove a clock dynamically allocated
 */
void clkdev_drop(struct clk_lookup *cl)
{
        mutex_lock(&clocks_mutex);
        list_del(&cl->node);
        mutex_unlock(&clocks_mutex);
        kfree(cl);
}
EXPORT_SYMBOL(clkdev_drop);

No, of course, I'm imagining all the above!

Now, today, the IM-PD/1 support got broken in respect of ensuring that
things are properly refcounted in the rush to convert things to this
wonderful new common clk API - because it's oh soooooo much better.  Yes,
right, I'd forgotten the number one rule of kernel programming - always
sacrifice correctness when we get a new fantasic hip idea!  Silly me.

> This is on Mike's list and IIRC there already has been
> a proposal for unregister. Si5351 was the first clkdev driver ever
> that could possibly be unloaded, so there may be still some features
> missing.

Utter rubbish - it's not the first as you can see from the above.
Integrator had this support since the clk and clkdev APIs came along,
because the IM-PD/1 module was implemented as a module, and it has to
create and register clocks for its peripherals.

What you've found is a backwards step with the common clk API, nothing
more.


From linux at arm.linux.org.uk  Sat Jul 13 17:02:36 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 13 Jul 2013 22:02:36 +0100
Subject: DT binding review for Armada display subsystem
In-Reply-To: <51E1BBF1.1020009@gmail.com>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <20130712203952.6b7aa927@armhf>
 <CAMLZHHT1oAvOLe3JgQqMqLNXEr0NGrdtgELtF_djbqLFceHtiQ@mail.gmail.com>
 <20130713103516.38a55b0b@armhf> <51E13272.5040903@gmail.com>
 <20130713111239.GM24642@n2100.arm.linux.org.uk> <51E1921A.3070207@gmail.com>
 <51E1BBF1.1020009@gmail.com>
Message-ID: <20130713210236.GP24642@n2100.arm.linux.org.uk>

On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it seems
> they're working on v4 with clock object reference counting. Presumably we
> need both clk_get() to be taking reference on the module and reference
> counted clk free, e.g. in cases where clock provider is a hot-pluggable
> device. It might be too paranoid though, I haven't seen hardware
> configurations where a clock source could be unplugged safely when whole
> system is running.

I'm not going to accept refcounting being thrown into clk_get().  The
clkdev API already has refcounting, as much as it needs to.  It just
needs people to use the hooks that I provided back in 2008 when I
created the clkdev API for doing _precisely_ this job.

Have a read through these commits, which backup my statement above:

0318e693d3a56836632bf1a2cfdafb7f34bcc703 - initial commit of the clkdev API
d72fbdf01fc77628c0b837d0dd2fd564fa26ede6 - converting Integrator to clkdev API

and it will show you how to do refcounting.  The common clk API just
needs to stop defining __clk_get() and __clk_put() to be an empty
function and implement them appropriately for it's clk implementation,
like they were always meant to be.

__clk_get() and __clk_put() are the clk-implementation specific parts
of the clkdev API, because the clkdev API is utterly divorsed from the
internals of what a 'struct clk' actually is.  clkdev just treats a
'struct clk' as a completely opaque type and never bothers poking
about inside it.


From fgenfb at yahoo.com  Sat Jul 13 17:13:12 2013
From: fgenfb at yahoo.com (Harm Hanemaaijer)
Date: Sat, 13 Jul 2013 21:13:12 +0000 (UTC)
Subject: Call for testing/opinions: Optimized memset/memcpy
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713164840.GC28473@gallifrey>
Message-ID: <loom.20130713T225129-903@post.gmane.org>

Dr. David Alan Gilbert <gilbertd <at> treblig.org> writes:

> 
> You might like to compare with some of the routines at:
> https://launchpad.net/cortex-strings
> and some of the numbers at:
> https://wiki.linaro.org/WorkingGroups/ToolChain/Benchmarks/

That's interesting. I had looked at cortex-strings before but didn't
dig into it, also because its benchmark program seemed to be limited in
scope. From the Linaro numbers it seems NEON isn't always a win
especially on newer Cortex platforms, with large variability across
different platforms/cores.

> 
>
http://ssvb.github.io/2013/06/27/fullhd-x11-desktop-performance-of-the-allwinner-a10.html
> 
> is an interesting article on one machine being screwed over by
> video bandwidth.

I have the same type of device (the Cortex A8 which I've tested on),
when running a 1920x1080 screen at 32bpp that does indeed cost a lot
bandwidth (it's 500MB/s of scanout bandwidth), I think this applies to
most devices except higher-end ones with a 64-bit DRAM interface.

> I've only had a brief scan through your code, one thing I remember
> from a couple of years ago was a theory that ldrd/strd was supposed
> to be faster on A15's (but I never had a chance to try it out).

I briefly experimented with ldrd/strd, it seemed to be fast but
highly dependent on the proper (64-bit) alignment. In my current code
it is only used in Thumb2 mode in one spot.

> Maybe neon is worth a try these days (although be careful of platforms
> like Tegra 2 that doens't have it); there was a recent patch that enabled
> use in the kernel (I think for some RAID use). The downside is it's
> supposed to be quite power hungry.

Although I don't have experience with NEON, there seems to be a lot of
variability across platforms/cores when using it for memcpy, and it may
have extra overhead when used in the kernel. I will look at it in more
detail, but not using NEON does make things easier (not having to detect
NEON, being compatible with older platforms etc).

Thanks for the comments.




From fgenfb at yahoo.com  Sat Jul 13 17:51:18 2013
From: fgenfb at yahoo.com (Harm Hanemaaijer)
Date: Sat, 13 Jul 2013 21:51:18 +0000 (UTC)
Subject: Call for testing/opinions: Optimized memset/memcpy
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713172445.GL32054@1wt.eu>
Message-ID: <loom.20130713T232124-511@post.gmane.org>

Willy Tarreau <w <at> 1wt.eu> writes:

> OK I've run bench.script on the following platforms :

Thanks, that's incredibly helpful!

Note that Thumb2 mode usually doesn't do much in synthetic benchmarks,
because the benchmark code will fit into the L1 instruction cache; the
benefit of Thumb2 happens in real-world usage when the active code
footprint becomes larger.

To summarize, memset seems to be in good shape and also the "fast path"
for common word-aligned memcpy of size <= 256 seems to be working well.

However, the copy_page and memcpy results for larger sizes seem to suggest
that the prefetch strategy isn't working well on these platforms. Note also
that on the quad core the existing copy_page is also highly sub-optimal.

Fixing the preload strategy for these platforms may simply be a case of
changing the configurable constant PREFETCH_DISTANCE from 3 to 2 (from an
offset of 192 bytes to 128 bytes), which more closely mimics the original
kernel memcpy. I have added PREFETCH_DISTANCE as a configurable parameter
in the Makefile in the latest version of test-arm-kernel-memcpy. It will
be interesting to see the results of testing with a PREFETCH_DISTANCE
of 2 especially on the quad-core platform or a similar one.




From sylvester.nawrocki at gmail.com  Sat Jul 13 18:16:58 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Sun, 14 Jul 2013 00:16:58 +0200
Subject: DT binding review for Armada display subsystem
In-Reply-To: <20130713210236.GP24642@n2100.arm.linux.org.uk>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <20130712203952.6b7aa927@armhf>
 <CAMLZHHT1oAvOLe3JgQqMqLNXEr0NGrdtgELtF_djbqLFceHtiQ@mail.gmail.com>
 <20130713103516.38a55b0b@armhf> <51E13272.5040903@gmail.com>
 <20130713111239.GM24642@n2100.arm.linux.org.uk> <51E1921A.3070207@gmail.com>
 <51E1BBF1.1020009@gmail.com> <20130713210236.GP24642@n2100.arm.linux.org.uk>
Message-ID: <51E1D1DA.8080102@gmail.com>

On 07/13/2013 11:02 PM, Russell King - ARM Linux wrote:
> On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
>> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it seems
>> they're working on v4 with clock object reference counting. Presumably we
>> need both clk_get() to be taking reference on the module and reference
>> counted clk free, e.g. in cases where clock provider is a hot-pluggable
>> device. It might be too paranoid though, I haven't seen hardware
>> configurations where a clock source could be unplugged safely when whole
>> system is running.
>
> I'm not going to accept refcounting being thrown into clk_get().  The
> clkdev API already has refcounting, as much as it needs to.  It just
> needs people to use the hooks that I provided back in 2008 when I
> created the clkdev API for doing _precisely_ this job.
>
> Have a read through these commits, which backup my statement above:
>
> 0318e693d3a56836632bf1a2cfdafb7f34bcc703 - initial commit of the clkdev API
> d72fbdf01fc77628c0b837d0dd2fd564fa26ede6 - converting Integrator to clkdev API
>
> and it will show you how to do refcounting.  The common clk API just
> needs to stop defining __clk_get() and __clk_put() to be an empty
> function and implement them appropriately for it's clk implementation,
> like they were always meant to be.

Sure, I've already seen the above commits. This is how I understood it
as well - __clk_get(), __clk_put() need to be defined by the common clk
API, since it is going to replace all the arch specific implementations.

> __clk_get() and __clk_put() are the clk-implementation specific parts
> of the clkdev API, because the clkdev API is utterly divorsed from the
> internals of what a 'struct clk' actually is.  clkdev just treats a
> 'struct clk' as a completely opaque type and never bothers poking
> about inside it.

OK, but at the clock's implementation side we may need, e.g. to use kref
to keep track of the clock's state, and free it only when it is unprepared,
all its children are unregistered, etc. ? Is it not what you stated in
your comment to patch [1] ?

[1] https://patchwork.kernel.org/patch/2651171/


From khilman at linaro.org  Sat Jul 13 18:21:29 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Sat, 13 Jul 2013 23:21:29 +0100
Subject: [PATCH] arm: omap2plus: unidle devices which are about to probe
In-Reply-To: <1373537788-30413-1-git-send-email-balbi@ti.com> (Felipe Balbi's
 message of "Thu, 11 Jul 2013 13:16:28 +0300")
References: <20130711092612.GG23892@arwen.pp.htv.fi>
 <1373537788-30413-1-git-send-email-balbi@ti.com>
Message-ID: <8738rije3a.fsf@linaro.org>

Felipe Balbi <balbi at ti.com> writes:

> in order to make HWMOD and pm_runtime agree on the
> initial state of the device, we will unidle the device
> and call pm_runtime_set_active() to tell pm_runtime
> that the device is really active.
>
> By the time driver's probe() is reached, a call to
> pm_runtime_get_sync() will not cause driver's
> ->runtime_resume() method to be called at first, only
> after a successful ->runtime_suspend().
>
> Note that we must prevent pm_runtime transitions while
> driver is probing otherwise drivers would be suspended
> as soon as they call pm_runtime_use_autosuspend(). By
> calling pm_runtime_forbid() before probe() and
> pm_runtime_allow() after probe() we 'fix' that detail.

This part sounds a bit strange to me, and sounds more like a driver bug.
Looking at omap-serial, this probably happens because the driver calls
_use_autosuspend() after it has called _enable() but before has done its
_get_sync().

> Note that this patch was inspired by PCI's pci_pm_init().
>
> Signed-off-by: Felipe Balbi <balbi at ti.com>
> ---
>
> boot tested on top of today's Linus master
> 6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
> panda. Reached console prompt and, after setting a
> proper autosuspend delay, consoles autosuspend just
> fine.
>
> It needs to be tested on other platforms.
>
> ps: note that we also call pm_runtime_set_suspended(dev)
> from our late_initcall() to disable devices so that pm_runtime
> and HWMOD continue to aggree on device's state.

Excellent.

I like this approach, but agree it needs more testing like you
mentioned.

>  arch/arm/mach-omap2/omap_device.c | 44 +++++++++++++++++++++++++++++++++++----
>  1 file changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 5cc9287..cb1fc1d 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -178,6 +178,26 @@ odbfd_exit:
>  	return ret;
>  }
>  
> +static void omap_device_pm_init(struct platform_device *pdev)
> +{
> +	omap_device_enable(pdev);
> +	pm_runtime_forbid(&pdev->dev);
> +	pm_runtime_set_active(&pdev->dev);
> +	device_enable_async_suspend(&pdev->dev);

You don't comment in the changelog about what this is for.  I think we
probably want this, but I suspect it belongs in a follow-up patch with
its own changelog.

Also Like PCI, I think we also want the device_set_wakeup_capable() here
also, but that should have its own patch+changelog also.

Kevin


From linux at arm.linux.org.uk  Sat Jul 13 19:09:55 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sun, 14 Jul 2013 00:09:55 +0100
Subject: DT binding review for Armada display subsystem
In-Reply-To: <51E1D1DA.8080102@gmail.com>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <20130712203952.6b7aa927@armhf>
 <CAMLZHHT1oAvOLe3JgQqMqLNXEr0NGrdtgELtF_djbqLFceHtiQ@mail.gmail.com>
 <20130713103516.38a55b0b@armhf> <51E13272.5040903@gmail.com>
 <20130713111239.GM24642@n2100.arm.linux.org.uk> <51E1921A.3070207@gmail.com>
 <51E1BBF1.1020009@gmail.com> <20130713210236.GP24642@n2100.arm.linux.org.uk>
 <51E1D1DA.8080102@gmail.com>
Message-ID: <20130713230955.GQ24642@n2100.arm.linux.org.uk>

On Sun, Jul 14, 2013 at 12:16:58AM +0200, Sylwester Nawrocki wrote:
> On 07/13/2013 11:02 PM, Russell King - ARM Linux wrote:
>> On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
>>> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it seems
>>> they're working on v4 with clock object reference counting. Presumably we
>>> need both clk_get() to be taking reference on the module and reference
>>> counted clk free, e.g. in cases where clock provider is a hot-pluggable
>>> device. It might be too paranoid though, I haven't seen hardware
>>> configurations where a clock source could be unplugged safely when whole
>>> system is running.
>>
>> I'm not going to accept refcounting being thrown into clk_get().  The
>> clkdev API already has refcounting, as much as it needs to.  It just
>> needs people to use the hooks that I provided back in 2008 when I
>> created the clkdev API for doing _precisely_ this job.
>>
>> Have a read through these commits, which backup my statement above:
>>
>> 0318e693d3a56836632bf1a2cfdafb7f34bcc703 - initial commit of the clkdev API
>> d72fbdf01fc77628c0b837d0dd2fd564fa26ede6 - converting Integrator to clkdev API
>>
>> and it will show you how to do refcounting.  The common clk API just
>> needs to stop defining __clk_get() and __clk_put() to be an empty
>> function and implement them appropriately for it's clk implementation,
>> like they were always meant to be.
>
> Sure, I've already seen the above commits. This is how I understood it
> as well - __clk_get(), __clk_put() need to be defined by the common clk
> API, since it is going to replace all the arch specific implementations.
>
>> __clk_get() and __clk_put() are the clk-implementation specific parts
>> of the clkdev API, because the clkdev API is utterly divorsed from the
>> internals of what a 'struct clk' actually is.  clkdev just treats a
>> 'struct clk' as a completely opaque type and never bothers poking
>> about inside it.
>
> OK, but at the clock's implementation side we may need, e.g. to use kref
> to keep track of the clock's state, and free it only when it is unprepared,
> all its children are unregistered, etc. ? Is it not what you stated in
> your comment to patch [1] ?

If you want to do refcounting on a clock (which you run into problems
as I highlighted earlier in this thread) then yes, you need to use a
kref, and take a reference in __clk_get() and drop it in __clk_put()
to make things safe.

Whether you also take a reference on the module supplying the clock or
not depends whether you need to keep the code around to manipulate that
clock while there are users of it.

As I've already said - consider the possibilities with this scenario.
Here's one:

  A clock consumer is using a clock, but the clock supplier has been
  removed.  The clock consumer wants to change the state of the clock
  in some way - eg, system is suspending.  clk_disable() doesn't fail,
  but on resume, clk_enable() does... (and how many people assume that
  clk_enable() never fails?)  And who knows what rate the clock is now
  producing or whether it's even producing anything...

I'm not saying don't do the refcounting thing I mentioned back in June.
I'm merely pointing out the issues that there are.  There isn't a one
right answer here because each has their own advantages and disadvantages
(and problems.)


From peter.chen at freescale.com  Sat Jul 13 20:43:04 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Sun, 14 Jul 2013 08:43:04 +0800
Subject: [PATCH v2 1/1] ARM: imx: clk-pllv3: change wait method for PLL
 lock
In-Reply-To: <20130608010922.GA25105@nchen-desktop>
References: <1370593146-14025-1-git-send-email-peter.chen@freescale.com>
 <20130607082457.GF12361@pengutronix.de>
 <20130607083134.GE21641@nchen-desktop>
 <20130607083528.GG12361@pengutronix.de>
 <20130607084354.GF21641@nchen-desktop>
 <20130607084937.GH12361@pengutronix.de>
 <20130607110741.GB20756@S2101-09.ap.freescale.net>
 <20130608010922.GA25105@nchen-desktop>
Message-ID: <20130714004303.GA15443@nchen-desktop>

On Sat, Jun 08, 2013 at 09:09:23AM +0800, Peter Chen wrote:
> On Fri, Jun 07, 2013 at 07:07:43PM +0800, Shawn Guo wrote:
> > On Fri, Jun 07, 2013 at 10:49:38AM +0200, Uwe Kleine-K?nig wrote:
> > > > I will try your fix, but still it just reduces the possibilities.
> > > > The problem is not the preemption takes too long, it is the jiffies
> > > > updates more than one tick at one short preemption.
> > > If that is really the problem that many more instances that use the same
> > > incarnation need the same fix. I would be surprised if that was the
> > > case.
> > 
> > +1
> > 
> 
> Using uwe's patch, the pll lock timeout hasn't appeared during the
> overtime test, usually, it will occur 4 or 5 times during overnight
> test. The reason why I suspect jiffies update problem that is we
> meet the similiar issue at other drivers which timeout is 2 jiffies,
> but it is satisfied within 1ms.
> 
> I will do more test, if it is passed, I will send patch with uwe's suggestion.
> Thanks.

The root cause of this problem is timer problem, Jason has already submitted a patch
to fix this problem.

http://marc.info/?l=linux-arm-kernel&m=137109340222931&w=2

I will send a improvement patch with uwe's suggestion.

-- 

Best Regards,
Peter Chen



From peter.chen at freescale.com  Sat Jul 13 20:58:48 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Sun, 14 Jul 2013 08:58:48 +0800
Subject: [PATCH 1/1] ARM: imx: clk-pllv3: move the timeout just before the
 comparison
Message-ID: <1373763528-20792-1-git-send-email-peter.chen@freescale.com>

It can let the timeout value be more precise.

Suggested-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 arch/arm/mach-imx/clk-pllv3.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-imx/clk-pllv3.c b/arch/arm/mach-imx/clk-pllv3.c
index a9fad5f..e2c026f 100644
--- a/arch/arm/mach-imx/clk-pllv3.c
+++ b/arch/arm/mach-imx/clk-pllv3.c
@@ -48,7 +48,7 @@ struct clk_pllv3 {
 static int clk_pllv3_prepare(struct clk_hw *hw)
 {
 	struct clk_pllv3 *pll = to_clk_pllv3(hw);
-	unsigned long timeout = jiffies + msecs_to_jiffies(10);
+	unsigned long timeout;
 	u32 val;
 
 	val = readl_relaxed(pll->base);
@@ -59,6 +59,7 @@ static int clk_pllv3_prepare(struct clk_hw *hw)
 		val &= ~BM_PLL_POWER;
 	writel_relaxed(val, pll->base);
 
+	timeout = jiffies + msecs_to_jiffies(10);
 	/* Wait for PLL to lock */
 	while (!(readl_relaxed(pll->base) & BM_PLL_LOCK))
 		if (time_after(jiffies, timeout))
-- 
1.7.0.4




From jett.zhou at gmail.com  Sat Jul 13 23:00:25 2013
From: jett.zhou at gmail.com (jett zhou)
Date: Sun, 14 Jul 2013 11:00:25 +0800
Subject: [V3 0/7] Enhance mmp display driver
In-Reply-To: <20130709133918.GC18477@ns203013.ovh.net>
References: <1372332473-6584-1-git-send-email-jtzhou@marvell.com>
 <20130709133918.GC18477@ns203013.ovh.net>
Message-ID: <CACDDiy8OwYHbmYGwc0FV2NLVfu1BiUL9GYCmA2QEVVB5isFJGQ@mail.gmail.com>

Hi Jean
     As I checked the for-next branch, found patch4 and patch5 are
already applied.
     As checked on my side,  only apply patch1~patch3 and
patch6~patch7 is ok, so think you can apply them except for patch4/5.
     If there is still problem, please let me know, I will check it then.
Thanks

2013/7/9 Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>:
> HI,
>
>         please rebase on the for-next branch as it does not apply
>
> Best Regards,
> J.
> On 19:27 Thu 27 Jun     , Jett.Zhou wrote:
>> Changelog:
>> 1 Add more comments for the mmp_display rbswap usage
>> according to Daniel's comments;
>> 2 Add fix patch for ttc_dkb on rbswap;
>> 3 Add more comments on the pitch usage and definition;
>> 4 Combine the modification on pitch of graphic and video layer
>> in one patch.
>>
>> Guoqing Li (2):
>>   video: mmp: rb swap setting update for mmp display
>>   video: mmp: optimize some register setting code
>>
>> Jett.Zhou (1):
>>   ARM: mmp: remove the legacy rbswap setting for ttc_dkb platform
>>
>> Jing Xiang (4):
>>   video: mmp: fix graphics/video layer enable/mask issue
>>   video: mmp: fix memcpy wrong size for mmp_addr issue
>>   video: mmp: calculate pitch value when fb set win
>>   video: mmp: add pitch info in mmp_win structure
>>
>>  arch/arm/mach-mmp/ttc_dkb.c     |    4 +-
>>  drivers/video/mmp/fb/mmpfb.c    |   34 +++++++++++------
>>  drivers/video/mmp/hw/mmp_ctrl.c |   79 ++++++++++++++++++++++-----------------
>>  drivers/video/mmp/hw/mmp_ctrl.h |    5 ++
>>  include/video/mmp_disp.h        |    6 +++
>>  5 files changed, 79 insertions(+), 49 deletions(-)
>>



--

----------------------------------
Best Regards
Jett Zhou


From swarren at wwwdotorg.org  Sun Jul 14 01:39:33 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Sat, 13 Jul 2013 23:39:33 -0600
Subject: [PATCH] irqchip: bcm2835: Convert to use IRQCHIP_DECLARE macro
In-Reply-To: <1372955496.9018.2.camel@phoenix>
References: <1372955496.9018.2.camel@phoenix>
Message-ID: <51E23995.4040606@wwwdotorg.org>

On 07/04/2013 10:31 AM, Axel Lin wrote:
> This patch converts irq-bcm2835 driver to use the new IRQCHIP_DECLARE and
> irqchip_init.

I guess the diffs to the ARM tree are much smaller than the irqchip
tree, so it's simplest to take it through the irqchip tree, so,

Acked-by: Stephen Warren <swarren at wwwdotorg.org>
Tested-by: Stephen Warren <swarren at wwwdotorg.org>


From w at 1wt.eu  Sun Jul 14 02:13:54 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Sun, 14 Jul 2013 08:13:54 +0200
Subject: Call for testing/opinions: Optimized memset/memcpy
In-Reply-To: <loom.20130713T232124-511@post.gmane.org>
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713172445.GL32054@1wt.eu> <loom.20130713T232124-511@post.gmane.org>
Message-ID: <20130714061354.GS32054@1wt.eu>

Hi,

On Sat, Jul 13, 2013 at 09:51:18PM +0000, Harm Hanemaaijer wrote:
> Willy Tarreau <w <at> 1wt.eu> writes:
> 
> > OK I've run bench.script on the following platforms :
> 
> Thanks, that's incredibly helpful!
> 
> Note that Thumb2 mode usually doesn't do much in synthetic benchmarks,
> because the benchmark code will fit into the L1 instruction cache; the
> benefit of Thumb2 happens in real-world usage when the active code
> footprint becomes larger.
> 
> To summarize, memset seems to be in good shape and also the "fast path"
> for common word-aligned memcpy of size <= 256 seems to be working well.
> 
> However, the copy_page and memcpy results for larger sizes seem to suggest
> that the prefetch strategy isn't working well on these platforms. Note also
> that on the quad core the existing copy_page is also highly sub-optimal.
> 
> Fixing the preload strategy for these platforms may simply be a case of
> changing the configurable constant PREFETCH_DISTANCE from 3 to 2 (from an
> offset of 192 bytes to 128 bytes), which more closely mimics the original
> kernel memcpy. I have added PREFETCH_DISTANCE as a configurable parameter
> in the Makefile in the latest version of test-arm-kernel-memcpy. It will
> be interesting to see the results of testing with a PREFETCH_DISTANCE
> of 2 especially on the quad-core platform or a similar one.

No problem, I ran it on the two in armv7+thumb mode again.

Please find the results attached. It seems that memcpy improved by 0.8%
though that's not even certain.

Regards,
Willy

-------------- next part --------------
libc memcpy:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 870.97 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 870.98 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 870.96 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 870.88 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 870.63 MB/s
kernel memcpy (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 955.68 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 955.36 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 955.71 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 955.41 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 955.66 MB/s
kernel memcpy (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 850.25 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 850.26 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 850.16 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 849.91 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 850.27 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 454.00 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 457.50 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 453.22 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 456.13 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 454.23 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 508.77 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 508.95 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 509.26 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 509.19 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 509.46 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 523.20 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 523.22 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 523.31 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 523.09 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 523.62 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 130, word aligned: 389.04 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 388.08 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 387.82 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 387.74 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 387.92 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 130, word aligned: 429.52 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 430.19 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 430.10 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 430.02 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 429.45 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 473.75 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 474.00 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 473.59 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 473.24 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 473.65 MB/s
kernel copy_from_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 452.37 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 452.11 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 452.91 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 451.84 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 452.71 MB/s
kernel copy_to_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 427.17 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 427.11 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 426.57 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 426.67 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 427.11 MB/s
libc memcpy:
4096 bytes page aligned: 2703.64 MB/s
4096 bytes page aligned: 2702.35 MB/s
4096 bytes page aligned: 2705.23 MB/s
4096 bytes page aligned: 2702.31 MB/s
4096 bytes page aligned: 2703.18 MB/s
kernel memcpy (original):
4096 bytes page aligned: 2735.75 MB/s
4096 bytes page aligned: 2736.98 MB/s
4096 bytes page aligned: 2739.54 MB/s
4096 bytes page aligned: 2736.56 MB/s
4096 bytes page aligned: 2735.81 MB/s
kernel memcpy (optimized):
4096 bytes page aligned: 2019.77 MB/s
4096 bytes page aligned: 2019.01 MB/s
4096 bytes page aligned: 2019.78 MB/s
4096 bytes page aligned: 2019.88 MB/s
4096 bytes page aligned: 2018.68 MB/s
kernel copy_page (original):
4096 bytes page aligned: 1533.13 MB/s
4096 bytes page aligned: 1532.51 MB/s
4096 bytes page aligned: 1534.12 MB/s
4096 bytes page aligned: 1532.53 MB/s
4096 bytes page aligned: 1533.16 MB/s
kernel copy_page (optimized):
4096 bytes page aligned: 2012.66 MB/s
4096 bytes page aligned: 2013.76 MB/s
4096 bytes page aligned: 2013.53 MB/s
4096 bytes page aligned: 2013.34 MB/s
4096 bytes page aligned: 2013.62 MB/s
libc memcpy:
Mixed from 1 to 1023 (power law), unaligned: 641.26 MB/s
Mixed from 1 to 1023 (power law), unaligned: 641.16 MB/s
Mixed from 1 to 1023 (power law), unaligned: 640.95 MB/s
Mixed from 1 to 1023 (power law), unaligned: 641.30 MB/s
Mixed from 1 to 1023 (power law), unaligned: 640.65 MB/s
kernel memcpy (original):
Mixed from 1 to 1023 (power law), unaligned: 677.55 MB/s
Mixed from 1 to 1023 (power law), unaligned: 677.50 MB/s
Mixed from 1 to 1023 (power law), unaligned: 677.51 MB/s
Mixed from 1 to 1023 (power law), unaligned: 677.09 MB/s
Mixed from 1 to 1023 (power law), unaligned: 676.69 MB/s
kernel memcpy (optimized):
Mixed from 1 to 1023 (power law), unaligned: 660.80 MB/s
Mixed from 1 to 1023 (power law), unaligned: 660.89 MB/s
Mixed from 1 to 1023 (power law), unaligned: 660.50 MB/s
Mixed from 1 to 1023 (power law), unaligned: 660.72 MB/s
Mixed from 1 to 1023 (power law), unaligned: 661.12 MB/s
libc memset:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1241.64 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1242.02 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1241.66 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1241.32 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1241.57 MB/s
kernel memset (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1603.86 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1608.36 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1605.22 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1606.88 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1606.02 MB/s
kernel memset (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1733.22 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1729.46 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1737.01 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1734.14 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1733.59 MB/s
kernel memzero (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1509.90 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1507.44 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1508.64 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1508.11 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1505.42 MB/s
kernel memzero (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1616.59 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1616.74 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1617.85 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1613.74 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1621.71 MB/s
libc memset:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 742.55 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 742.68 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 742.64 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 742.52 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 742.60 MB/s
kernel memset (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 893.16 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 893.35 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 893.18 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 893.45 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 893.39 MB/s
kernel memset (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1028.50 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1028.49 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1028.30 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1028.37 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1028.22 MB/s
kernel memzero (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 839.00 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 838.75 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 839.01 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 838.93 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 838.96 MB/s
kernel memzero (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 930.07 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 930.04 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 930.11 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 930.09 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 930.08 MB/s
libc memset:
4096 bytes page aligned: 2787.64 MB/s
4096 bytes page aligned: 2788.50 MB/s
4096 bytes page aligned: 2788.44 MB/s
4096 bytes page aligned: 2788.39 MB/s
4096 bytes page aligned: 2788.18 MB/s
kernel memset (original):
4096 bytes page aligned: 4285.78 MB/s
4096 bytes page aligned: 4286.76 MB/s
4096 bytes page aligned: 4285.85 MB/s
4096 bytes page aligned: 4286.59 MB/s
4096 bytes page aligned: 4285.58 MB/s
kernel memset (optimized):
4096 bytes page aligned: 4314.98 MB/s
4096 bytes page aligned: 4314.69 MB/s
4096 bytes page aligned: 4314.15 MB/s
4096 bytes page aligned: 4314.67 MB/s
4096 bytes page aligned: 4313.65 MB/s
kernel memzero (original):
4096 bytes page aligned: 4242.90 MB/s
4096 bytes page aligned: 4241.60 MB/s
4096 bytes page aligned: 4242.77 MB/s
4096 bytes page aligned: 4241.56 MB/s
4096 bytes page aligned: 4243.05 MB/s
kernel memzero (optimized):
4096 bytes page aligned: 4265.52 MB/s
4096 bytes page aligned: 4264.31 MB/s
4096 bytes page aligned: 4265.14 MB/s
4096 bytes page aligned: 4264.22 MB/s
4096 bytes page aligned: 4265.74 MB/s
libc memset:
Mixed from 1 to 1023 (power law), unaligned: 1083.33 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1083.76 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1083.22 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1083.63 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1083.44 MB/s
kernel memset (original):
Mixed from 1 to 1023 (power law), unaligned: 1361.29 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1362.14 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1361.44 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1362.91 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1361.52 MB/s
kernel memset (optimized):
Mixed from 1 to 1023 (power law), unaligned: 1511.68 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1511.65 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1512.21 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1512.55 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1512.37 MB/s
kernel memzero (original):
Mixed from 1 to 1023 (power law), unaligned: 1259.19 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1259.69 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1260.27 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1259.07 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1260.15 MB/s
kernel memzero (optimized):
Mixed from 1 to 1023 (power law), unaligned: 1410.53 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1410.31 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1410.48 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1408.95 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1412.63 MB/s
-------------- next part --------------
libc memcpy:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 944.18 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 943.83 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 944.12 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 943.90 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 944.20 MB/s
kernel memcpy (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 999.62 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 999.90 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 999.98 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 999.64 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1000.03 MB/s
kernel memcpy (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 869.93 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 870.49 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 870.24 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 870.35 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 870.49 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 505.38 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 505.22 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 505.65 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 505.57 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 505.54 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 541.06 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 541.00 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 540.94 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 541.01 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 541.03 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 549.25 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 549.45 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 549.94 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 549.20 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 549.48 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 130, word aligned: 425.16 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 425.82 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 425.51 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 425.70 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 425.59 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 130, word aligned: 458.28 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 458.62 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 459.25 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 458.18 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 459.43 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 501.98 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 502.06 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 501.65 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 502.31 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 502.14 MB/s
kernel copy_from_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 484.64 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 484.08 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 483.97 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 485.09 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 485.96 MB/s
kernel copy_to_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 455.69 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 455.98 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 455.98 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 455.97 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 457.07 MB/s
libc memcpy:
4096 bytes page aligned: 2739.85 MB/s
4096 bytes page aligned: 2738.74 MB/s
4096 bytes page aligned: 2739.70 MB/s
4096 bytes page aligned: 2738.93 MB/s
4096 bytes page aligned: 2739.83 MB/s
kernel memcpy (original):
4096 bytes page aligned: 2770.15 MB/s
4096 bytes page aligned: 2772.07 MB/s
4096 bytes page aligned: 2771.84 MB/s
4096 bytes page aligned: 2770.57 MB/s
4096 bytes page aligned: 2771.75 MB/s
kernel memcpy (optimized):
4096 bytes page aligned: 2016.25 MB/s
4096 bytes page aligned: 2017.41 MB/s
4096 bytes page aligned: 2017.92 MB/s
4096 bytes page aligned: 2019.81 MB/s
4096 bytes page aligned: 2016.19 MB/s
kernel copy_page (original):
4096 bytes page aligned: 1537.52 MB/s
4096 bytes page aligned: 1537.46 MB/s
4096 bytes page aligned: 1536.99 MB/s
4096 bytes page aligned: 1537.60 MB/s
4096 bytes page aligned: 1536.97 MB/s
kernel copy_page (optimized):
4096 bytes page aligned: 2032.28 MB/s
4096 bytes page aligned: 2031.33 MB/s
4096 bytes page aligned: 2032.23 MB/s
4096 bytes page aligned: 2032.35 MB/s
4096 bytes page aligned: 2031.26 MB/s
libc memcpy:
Mixed from 1 to 1023 (power law), unaligned: 678.17 MB/s
Mixed from 1 to 1023 (power law), unaligned: 677.84 MB/s
Mixed from 1 to 1023 (power law), unaligned: 678.13 MB/s
Mixed from 1 to 1023 (power law), unaligned: 678.03 MB/s
Mixed from 1 to 1023 (power law), unaligned: 678.14 MB/s
kernel memcpy (original):
Mixed from 1 to 1023 (power law), unaligned: 706.55 MB/s
Mixed from 1 to 1023 (power law), unaligned: 706.16 MB/s
Mixed from 1 to 1023 (power law), unaligned: 706.71 MB/s
Mixed from 1 to 1023 (power law), unaligned: 706.09 MB/s
Mixed from 1 to 1023 (power law), unaligned: 706.90 MB/s
kernel memcpy (optimized):
Mixed from 1 to 1023 (power law), unaligned: 691.01 MB/s
Mixed from 1 to 1023 (power law), unaligned: 691.40 MB/s
Mixed from 1 to 1023 (power law), unaligned: 691.07 MB/s
Mixed from 1 to 1023 (power law), unaligned: 691.55 MB/s
Mixed from 1 to 1023 (power law), unaligned: 691.35 MB/s
libc memset:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1279.54 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1280.04 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1279.75 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1279.82 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1279.46 MB/s
kernel memset (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1700.89 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1699.79 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1699.45 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1699.46 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1699.12 MB/s
kernel memset (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1859.00 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1855.05 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1857.88 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1858.97 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1855.57 MB/s
kernel memzero (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1603.50 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1603.51 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1602.76 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1603.89 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1604.60 MB/s
kernel memzero (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1653.52 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1652.73 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1654.63 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1652.44 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1654.76 MB/s
libc memset:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 777.78 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 777.85 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 777.78 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 777.86 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 777.86 MB/s
kernel memset (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 966.31 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 966.26 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 966.17 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 966.31 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 966.12 MB/s
kernel memset (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1161.60 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1161.58 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1161.33 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1161.54 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 1161.27 MB/s
kernel memzero (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 912.78 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 912.68 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 912.72 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 912.83 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 912.75 MB/s
kernel memzero (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 978.47 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 978.58 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 978.63 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 978.51 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 977.65 MB/s
libc memset:
4096 bytes page aligned: 2809.19 MB/s
4096 bytes page aligned: 2809.15 MB/s
4096 bytes page aligned: 2809.19 MB/s
4096 bytes page aligned: 2808.39 MB/s
4096 bytes page aligned: 2809.20 MB/s
kernel memset (original):
4096 bytes page aligned: 4286.67 MB/s
4096 bytes page aligned: 4287.73 MB/s
4096 bytes page aligned: 4287.69 MB/s
4096 bytes page aligned: 4287.50 MB/s
4096 bytes page aligned: 4287.77 MB/s
kernel memset (optimized):
4096 bytes page aligned: 4332.86 MB/s
4096 bytes page aligned: 4333.92 MB/s
4096 bytes page aligned: 4332.87 MB/s
4096 bytes page aligned: 4333.86 MB/s
4096 bytes page aligned: 4332.81 MB/s
kernel memzero (original):
4096 bytes page aligned: 4286.77 MB/s
4096 bytes page aligned: 4286.73 MB/s
4096 bytes page aligned: 4285.68 MB/s
4096 bytes page aligned: 4286.65 MB/s
4096 bytes page aligned: 4285.85 MB/s
kernel memzero (optimized):
4096 bytes page aligned: 4308.08 MB/s
4096 bytes page aligned: 4307.07 MB/s
4096 bytes page aligned: 4308.18 MB/s
4096 bytes page aligned: 4307.95 MB/s
4096 bytes page aligned: 4306.85 MB/s
libc memset:
Mixed from 1 to 1023 (power law), unaligned: 1156.13 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1156.08 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1156.25 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1156.23 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1156.31 MB/s
kernel memset (original):
Mixed from 1 to 1023 (power law), unaligned: 1491.20 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1491.11 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1491.80 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1491.44 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1491.66 MB/s
kernel memset (optimized):
Mixed from 1 to 1023 (power law), unaligned: 1690.43 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1691.03 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1693.37 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1691.31 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1691.96 MB/s
kernel memzero (original):
Mixed from 1 to 1023 (power law), unaligned: 1364.67 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1365.10 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1364.98 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1365.15 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1365.25 MB/s
kernel memzero (optimized):
Mixed from 1 to 1023 (power law), unaligned: 1475.90 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1476.30 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1476.07 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1476.49 MB/s
Mixed from 1 to 1023 (power law), unaligned: 1476.28 MB/s
-------------- next part --------------
libc memcpy:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 652.61 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 649.67 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 652.72 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 649.61 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 652.57 MB/s
kernel memcpy (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 673.87 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 677.13 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 677.32 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 677.41 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 677.17 MB/s
kernel memcpy (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 662.60 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 663.56 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 659.15 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 664.26 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 659.52 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 364.58 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 364.71 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 362.93 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 364.58 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 363.00 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 382.17 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 380.45 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 382.24 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 380.23 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 382.24 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 424.01 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 421.91 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 423.94 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 421.65 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 423.90 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 130, word aligned: 311.50 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 312.98 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 311.42 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 312.96 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 312.97 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 130, word aligned: 327.64 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 329.20 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 327.67 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 329.21 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 327.65 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 367.15 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 365.31 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 367.18 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 367.12 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 365.37 MB/s
kernel copy_from_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 365.11 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 363.52 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 365.17 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 363.37 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 365.18 MB/s
kernel copy_to_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 368.24 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 368.29 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 368.23 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 366.48 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 368.24 MB/s
libc memcpy:
4096 bytes page aligned: 358.42 MB/s
4096 bytes page aligned: 360.12 MB/s
4096 bytes page aligned: 358.39 MB/s
4096 bytes page aligned: 360.09 MB/s
4096 bytes page aligned: 358.45 MB/s
kernel memcpy (original):
4096 bytes page aligned: 360.40 MB/s
4096 bytes page aligned: 358.72 MB/s
4096 bytes page aligned: 360.39 MB/s
4096 bytes page aligned: 358.79 MB/s
4096 bytes page aligned: 360.46 MB/s
kernel memcpy (optimized):
4096 bytes page aligned: 342.08 MB/s
4096 bytes page aligned: 343.69 MB/s
4096 bytes page aligned: 341.96 MB/s
4096 bytes page aligned: 343.70 MB/s
4096 bytes page aligned: 342.10 MB/s
kernel copy_page (original):
4096 bytes page aligned: 386.91 MB/s
4096 bytes page aligned: 385.04 MB/s
4096 bytes page aligned: 386.90 MB/s
4096 bytes page aligned: 385.13 MB/s
4096 bytes page aligned: 386.90 MB/s
kernel copy_page (optimized):
4096 bytes page aligned: 341.49 MB/s
4096 bytes page aligned: 343.25 MB/s
4096 bytes page aligned: 343.26 MB/s
4096 bytes page aligned: 343.20 MB/s
4096 bytes page aligned: 343.12 MB/s
libc memcpy:
Mixed from 1 to 1023 (power law), unaligned: 514.14 MB/s
Mixed from 1 to 1023 (power law), unaligned: 515.74 MB/s
Mixed from 1 to 1023 (power law), unaligned: 514.14 MB/s
Mixed from 1 to 1023 (power law), unaligned: 515.79 MB/s
Mixed from 1 to 1023 (power law), unaligned: 514.18 MB/s
kernel memcpy (original):
Mixed from 1 to 1023 (power law), unaligned: 540.90 MB/s
Mixed from 1 to 1023 (power law), unaligned: 537.63 MB/s
Mixed from 1 to 1023 (power law), unaligned: 539.82 MB/s
Mixed from 1 to 1023 (power law), unaligned: 540.33 MB/s
Mixed from 1 to 1023 (power law), unaligned: 537.00 MB/s
kernel memcpy (optimized):
Mixed from 1 to 1023 (power law), unaligned: 540.31 MB/s
Mixed from 1 to 1023 (power law), unaligned: 537.17 MB/s
Mixed from 1 to 1023 (power law), unaligned: 540.38 MB/s
Mixed from 1 to 1023 (power law), unaligned: 539.03 MB/s
Mixed from 1 to 1023 (power law), unaligned: 542.41 MB/s
libc memset:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 881.70 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 881.68 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 881.56 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 877.40 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 881.52 MB/s
kernel memset (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 954.65 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 958.99 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 954.36 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 959.20 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 958.94 MB/s
kernel memset (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 999.30 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1004.01 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 999.36 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 1004.03 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 999.32 MB/s
kernel memzero (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 925.38 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 925.25 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 920.83 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 925.23 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 920.99 MB/s
kernel memzero (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 933.68 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 929.32 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 933.83 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 933.73 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 933.68 MB/s
libc memset:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 521.29 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 518.76 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 521.32 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 518.80 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 521.31 MB/s
kernel memset (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 588.12 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 590.97 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 591.00 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 588.13 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 590.94 MB/s
kernel memset (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 645.02 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 648.18 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 645.16 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 648.13 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 648.04 MB/s
kernel memzero (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 569.18 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 569.19 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 566.41 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 569.04 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 566.44 MB/s
kernel memzero (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 587.84 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 585.04 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 587.75 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 587.79 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 585.07 MB/s
libc memset:
4096 bytes page aligned: 2052.96 MB/s
4096 bytes page aligned: 2042.84 MB/s
4096 bytes page aligned: 2052.52 MB/s
4096 bytes page aligned: 2043.01 MB/s
4096 bytes page aligned: 2052.58 MB/s
kernel memset (original):
4096 bytes page aligned: 1912.63 MB/s
4096 bytes page aligned: 1922.23 MB/s
4096 bytes page aligned: 1921.84 MB/s
4096 bytes page aligned: 1912.60 MB/s
4096 bytes page aligned: 1921.86 MB/s
kernel memset (optimized):
4096 bytes page aligned: 1892.39 MB/s
4096 bytes page aligned: 1901.32 MB/s
4096 bytes page aligned: 1892.51 MB/s
4096 bytes page aligned: 1901.22 MB/s
4096 bytes page aligned: 1901.58 MB/s
kernel memzero (original):
4096 bytes page aligned: 1920.75 MB/s
4096 bytes page aligned: 1920.38 MB/s
4096 bytes page aligned: 1911.56 MB/s
4096 bytes page aligned: 1920.81 MB/s
4096 bytes page aligned: 1911.45 MB/s
kernel memzero (optimized):
4096 bytes page aligned: 1928.78 MB/s
4096 bytes page aligned: 1919.76 MB/s
4096 bytes page aligned: 1928.75 MB/s
4096 bytes page aligned: 1929.09 MB/s
4096 bytes page aligned: 1919.61 MB/s
libc memset:
Mixed from 1 to 1023 (power law), unaligned: 785.51 MB/s
Mixed from 1 to 1023 (power law), unaligned: 781.66 MB/s
Mixed from 1 to 1023 (power law), unaligned: 785.54 MB/s
Mixed from 1 to 1023 (power law), unaligned: 781.71 MB/s
Mixed from 1 to 1023 (power law), unaligned: 785.41 MB/s
kernel memset (original):
Mixed from 1 to 1023 (power law), unaligned: 816.79 MB/s
Mixed from 1 to 1023 (power law), unaligned: 820.37 MB/s
Mixed from 1 to 1023 (power law), unaligned: 820.29 MB/s
Mixed from 1 to 1023 (power law), unaligned: 817.25 MB/s
Mixed from 1 to 1023 (power law), unaligned: 820.35 MB/s
kernel memset (optimized):
Mixed from 1 to 1023 (power law), unaligned: 880.18 MB/s
Mixed from 1 to 1023 (power law), unaligned: 884.47 MB/s
Mixed from 1 to 1023 (power law), unaligned: 880.03 MB/s
Mixed from 1 to 1023 (power law), unaligned: 884.15 MB/s
Mixed from 1 to 1023 (power law), unaligned: 884.00 MB/s
kernel memzero (original):
Mixed from 1 to 1023 (power law), unaligned: 797.30 MB/s
Mixed from 1 to 1023 (power law), unaligned: 800.99 MB/s
Mixed from 1 to 1023 (power law), unaligned: 797.06 MB/s
Mixed from 1 to 1023 (power law), unaligned: 800.49 MB/s
Mixed from 1 to 1023 (power law), unaligned: 797.08 MB/s
kernel memzero (optimized):
Mixed from 1 to 1023 (power law), unaligned: 813.62 MB/s
Mixed from 1 to 1023 (power law), unaligned: 813.55 MB/s
Mixed from 1 to 1023 (power law), unaligned: 813.41 MB/s
Mixed from 1 to 1023 (power law), unaligned: 813.81 MB/s
Mixed from 1 to 1023 (power law), unaligned: 809.52 MB/s
-------------- next part --------------
libc memcpy:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 628.06 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 623.94 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 626.71 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 623.43 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 627.13 MB/s
kernel memcpy (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 657.41 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 661.00 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 660.91 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 659.46 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 661.87 MB/s
kernel memcpy (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 657.37 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 661.33 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 659.10 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 662.16 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 658.66 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 332.21 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 330.70 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 332.24 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 332.27 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 330.55 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 363.62 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 361.89 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 363.65 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 361.77 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 363.54 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 397.26 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 399.06 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 397.13 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 399.11 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 399.11 MB/s
libc memcpy:
Mixed multiples of 4 from 4 to 130, word aligned: 292.31 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 292.31 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 290.92 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 292.26 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 290.86 MB/s
kernel memcpy (original):
Mixed multiples of 4 from 4 to 130, word aligned: 311.41 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 309.88 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 311.35 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 309.86 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 311.41 MB/s
kernel memcpy (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 343.87 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 343.89 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 343.85 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 342.24 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 343.91 MB/s
kernel copy_from_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 336.13 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 337.70 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 336.16 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 337.76 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 336.12 MB/s
kernel copy_to_user (optimized):
Mixed multiples of 4 from 4 to 130, word aligned: 336.24 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 334.60 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 336.29 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 336.30 MB/s
Mixed multiples of 4 from 4 to 130, word aligned: 336.28 MB/s
libc memcpy:
4096 bytes page aligned: 350.93 MB/s
4096 bytes page aligned: 350.87 MB/s
4096 bytes page aligned: 350.86 MB/s
4096 bytes page aligned: 349.12 MB/s
4096 bytes page aligned: 350.82 MB/s
kernel memcpy (original):
4096 bytes page aligned: 349.41 MB/s
4096 bytes page aligned: 351.20 MB/s
4096 bytes page aligned: 349.45 MB/s
4096 bytes page aligned: 351.11 MB/s
4096 bytes page aligned: 349.44 MB/s
kernel memcpy (optimized):
4096 bytes page aligned: 335.77 MB/s
4096 bytes page aligned: 334.08 MB/s
4096 bytes page aligned: 335.69 MB/s
4096 bytes page aligned: 334.18 MB/s
4096 bytes page aligned: 335.80 MB/s
kernel copy_page (original):
4096 bytes page aligned: 376.23 MB/s
4096 bytes page aligned: 377.99 MB/s
4096 bytes page aligned: 376.22 MB/s
4096 bytes page aligned: 378.12 MB/s
4096 bytes page aligned: 376.26 MB/s
kernel copy_page (optimized):
4096 bytes page aligned: 335.23 MB/s
4096 bytes page aligned: 333.74 MB/s
4096 bytes page aligned: 335.35 MB/s
4096 bytes page aligned: 333.73 MB/s
4096 bytes page aligned: 335.24 MB/s
libc memcpy:
Mixed from 1 to 1023 (power law), unaligned: 491.15 MB/s
Mixed from 1 to 1023 (power law), unaligned: 494.03 MB/s
Mixed from 1 to 1023 (power law), unaligned: 491.42 MB/s
Mixed from 1 to 1023 (power law), unaligned: 493.73 MB/s
Mixed from 1 to 1023 (power law), unaligned: 493.67 MB/s
kernel memcpy (original):
Mixed from 1 to 1023 (power law), unaligned: 511.36 MB/s
Mixed from 1 to 1023 (power law), unaligned: 511.31 MB/s
Mixed from 1 to 1023 (power law), unaligned: 508.09 MB/s
Mixed from 1 to 1023 (power law), unaligned: 510.07 MB/s
Mixed from 1 to 1023 (power law), unaligned: 508.48 MB/s
kernel memcpy (optimized):
Mixed from 1 to 1023 (power law), unaligned: 504.81 MB/s
Mixed from 1 to 1023 (power law), unaligned: 502.20 MB/s
Mixed from 1 to 1023 (power law), unaligned: 504.56 MB/s
Mixed from 1 to 1023 (power law), unaligned: 502.11 MB/s
Mixed from 1 to 1023 (power law), unaligned: 504.76 MB/s
libc memset:
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 848.27 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 848.05 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 848.22 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 844.06 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 848.15 MB/s
kernel memset (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 904.37 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 908.54 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 904.19 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 908.48 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 903.71 MB/s
kernel memset (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 950.89 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 951.03 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 946.37 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 950.95 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 946.38 MB/s
kernel memzero (original):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 861.66 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 857.97 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 861.77 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 857.91 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 861.79 MB/s
kernel memzero (optimized):
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 895.24 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 895.20 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 895.13 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 890.91 MB/s
Mixed powers of 2 from 4 to 4096 (power law), word aligned: 895.07 MB/s
libc memset:
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 501.37 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 503.81 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 501.35 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 503.73 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 501.30 MB/s
kernel memset (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 569.17 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 569.17 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 569.07 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 569.06 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 566.40 MB/s
kernel memset (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 621.23 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 618.26 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 621.15 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 618.15 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 621.22 MB/s
kernel memzero (original):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 535.10 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 537.69 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 537.67 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 535.13 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 537.73 MB/s
kernel memzero (optimized):
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 566.99 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 569.74 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 567.10 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 569.83 MB/s
Mixed multiples of 4 from 4 to 1024 (power law), word aligned: 567.03 MB/s
libc memset:
4096 bytes page aligned: 2041.83 MB/s
4096 bytes page aligned: 2032.34 MB/s
4096 bytes page aligned: 2042.07 MB/s
4096 bytes page aligned: 2042.09 MB/s
4096 bytes page aligned: 2031.88 MB/s
kernel memset (original):
4096 bytes page aligned: 1922.09 MB/s
4096 bytes page aligned: 1912.70 MB/s
4096 bytes page aligned: 1922.13 MB/s
4096 bytes page aligned: 1912.52 MB/s
4096 bytes page aligned: 1921.78 MB/s
kernel memset (optimized):
4096 bytes page aligned: 1913.71 MB/s
4096 bytes page aligned: 1923.03 MB/s
4096 bytes page aligned: 1913.67 MB/s
4096 bytes page aligned: 1922.56 MB/s
4096 bytes page aligned: 1923.01 MB/s
kernel memzero (original):
4096 bytes page aligned: 1888.00 MB/s
4096 bytes page aligned: 1897.21 MB/s
4096 bytes page aligned: 1887.74 MB/s
4096 bytes page aligned: 1896.99 MB/s
4096 bytes page aligned: 1887.97 MB/s
kernel memzero (optimized):
4096 bytes page aligned: 1898.35 MB/s
4096 bytes page aligned: 1888.97 MB/s
4096 bytes page aligned: 1897.97 MB/s
4096 bytes page aligned: 1889.20 MB/s
4096 bytes page aligned: 1898.33 MB/s
libc memset:
Mixed from 1 to 1023 (power law), unaligned: 735.51 MB/s
Mixed from 1 to 1023 (power law), unaligned: 732.16 MB/s
Mixed from 1 to 1023 (power law), unaligned: 735.44 MB/s
Mixed from 1 to 1023 (power law), unaligned: 731.94 MB/s
Mixed from 1 to 1023 (power law), unaligned: 735.37 MB/s
kernel memset (original):
Mixed from 1 to 1023 (power law), unaligned: 782.22 MB/s
Mixed from 1 to 1023 (power law), unaligned: 785.91 MB/s
Mixed from 1 to 1023 (power law), unaligned: 782.22 MB/s
Mixed from 1 to 1023 (power law), unaligned: 785.91 MB/s
Mixed from 1 to 1023 (power law), unaligned: 785.99 MB/s
kernel memset (optimized):
Mixed from 1 to 1023 (power law), unaligned: 818.63 MB/s
Mixed from 1 to 1023 (power law), unaligned: 818.80 MB/s
Mixed from 1 to 1023 (power law), unaligned: 815.12 MB/s
Mixed from 1 to 1023 (power law), unaligned: 818.64 MB/s
Mixed from 1 to 1023 (power law), unaligned: 814.92 MB/s
kernel memzero (original):
Mixed from 1 to 1023 (power law), unaligned: 748.04 MB/s
Mixed from 1 to 1023 (power law), unaligned: 745.01 MB/s
Mixed from 1 to 1023 (power law), unaligned: 748.67 MB/s
Mixed from 1 to 1023 (power law), unaligned: 744.85 MB/s
Mixed from 1 to 1023 (power law), unaligned: 748.90 MB/s
kernel memzero (optimized):
Mixed from 1 to 1023 (power law), unaligned: 784.81 MB/s
Mixed from 1 to 1023 (power law), unaligned: 781.09 MB/s
Mixed from 1 to 1023 (power law), unaligned: 784.40 MB/s
Mixed from 1 to 1023 (power law), unaligned: 780.62 MB/s
Mixed from 1 to 1023 (power law), unaligned: 784.59 MB/s

From josh.wu at atmel.com  Sun Jul 14 04:04:24 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Sun, 14 Jul 2013 16:04:24 +0800
Subject: [PATCH 0/5] iio: at91: Add touch screen support in at91 adc
Message-ID: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>

This patch series will add touch screen support for at91 adc driver.
To enable touch screen you need add the touch screen related dt properties.

Josh Wu (5):
  iio: at91: use adc_clk_khz to make the calculation not easy to large
    than u32.
  iio: at91: Use different prescal, startup mask in MR for different IP
  iio: at91: ADC start-up time calculation changed since at91sam9x5
  iio: at91: add an optional dt property for for adc clock hz.
  iio: at91: introduce touch screen support in iio adc driver

 .../devicetree/bindings/arm/atmel-adc.txt          |   15 +
 arch/arm/mach-at91/include/mach/at91_adc.h         |   43 +-
 drivers/iio/adc/at91_adc.c                         |  492 ++++++++++++++++++--
 3 files changed, 511 insertions(+), 39 deletions(-)

-- 
1.7.10



From josh.wu at atmel.com  Sun Jul 14 04:04:28 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Sun, 14 Jul 2013 16:04:28 +0800
Subject: [PATCH 4/5] iio: at91: add an optional dt property for for adc clock
 hz.
In-Reply-To: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1373789069-11604-5-git-send-email-josh.wu@atmel.com>

Signed-off-by: Josh Wu <josh.wu at atmel.com>
---
 Documentation/devicetree/bindings/arm/atmel-adc.txt |    2 ++
 drivers/iio/adc/at91_adc.c                          |    8 +++++++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
index 16769d9..0db2945 100644
--- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
@@ -27,6 +27,8 @@ Optional properties:
 		       resolution will be used.
   - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
   - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
+  - atmel,adc-clock-rate: ADC clock rate. If not specified, use the default
+			  adc_op_clk.
  
 Optional trigger Nodes:
   - Required properties:
diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index e93a075..8f1386f 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -47,6 +47,7 @@ struct at91_adc_caps {
 
 struct at91_adc_state {
 	struct clk		*adc_clk;
+	u32			adc_clk_rate;
 	u16			*buffer;
 	unsigned long		channels_mask;
 	struct clk		*clk;
@@ -448,6 +449,10 @@ static int at91_adc_probe_dt(struct at91_adc_state *st,
 	if (!node)
 		return -EINVAL;
 
+	prop = 0;
+	of_property_read_u32(node, "atmel,adc-clock-rate", &prop);
+	st->adc_clk_rate = prop;
+
 	st->use_external = of_property_read_bool(node, "atmel,adc-use-external-triggers");
 
 	if (of_property_read_u32(node, "atmel,adc-channels-used", &prop)) {
@@ -723,7 +728,8 @@ static int at91_adc_probe(struct platform_device *pdev)
 	 * specified by the electrical characteristics of the board.
 	 */
 	mstrclk = clk_get_rate(st->clk);
-	adc_clk = clk_get_rate(st->adc_clk);
+	adc_clk = st->adc_clk_rate ?
+		st->adc_clk_rate : clk_get_rate(st->adc_clk);
 	adc_clk_khz = adc_clk / 1000;
 	prsc = (mstrclk / (2 * adc_clk)) - 1;
 
-- 
1.7.10



From josh.wu at atmel.com  Sun Jul 14 04:04:27 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Sun, 14 Jul 2013 16:04:27 +0800
Subject: [PATCH 3/5] iio: at91: ADC start-up time calculation changed since
 at91sam9x5
In-Reply-To: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1373789069-11604-4-git-send-email-josh.wu@atmel.com>

Since in at91sam9x5, sama5d3x chip. the start up time calucation is changed.
And these two chips also have TSMR, so we check whether ADC has TSMR, then
choose different start up time calculation formula.

Signed-off-by: Josh Wu <josh.wu at atmel.com>
---
 drivers/iio/adc/at91_adc.c |   40 +++++++++++++++++++++++++++++++++-------
 1 file changed, 33 insertions(+), 7 deletions(-)

diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index 14e99ba..e93a075 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -733,13 +733,39 @@ static int at91_adc_probe(struct platform_device *pdev)
 		goto error_disable_adc_clk;
 	}
 
-	/*
-	 * Number of ticks needed to cover the startup time of the ADC as
-	 * defined in the electrical characteristics of the board, divided by 8.
-	 * The formula thus is : Startup Time = (ticks + 1) * 8 / ADC Clock
-	 */
-	ticks = round_up((st->startup_time * adc_clk_khz /
-			  1000) - 1, 8) / 8;
+	if (!st->caps.has_tsmr) {
+		/*
+		 * Number of ticks needed to cover the startup time of the ADC
+		 * as defined in the electrical characteristics of the board,
+		 * divided by 8. The formula thus is :
+		 *   Startup Time = (ticks + 1) * 8 / ADC Clock
+		 */
+		ticks = round_up((st->startup_time * adc_clk_khz /
+				  1000) - 1, 8) / 8;
+	} else {
+		/*
+		 * For sama5d3x and at91sam9x5, the formula changes to:
+		 * Startup Time = <lookup_table_value> / ADC Clock
+		 */
+		const int startup_lookup[] = {
+			0  , 8  , 16 , 24 ,
+			64 , 80 , 96 , 112,
+			512, 576, 640, 704,
+			768, 832, 896, 960
+			};
+
+		int i, size = ARRAY_SIZE(startup_lookup);
+		ticks = st->startup_time * adc_clk_khz / 1000;
+		for (i = 0; i < size; i++)
+			if (ticks < startup_lookup[i])
+				break;
+
+		ticks = i;
+		if (ticks == size)
+			/* Reach the end of lookup table */
+			ticks = size - 1;
+	}
+
 	/*
 	 * a minimal Sample and Hold Time is necessary for the ADC to guarantee
 	 * the best converted final value between two channels selection
-- 
1.7.10



From josh.wu at atmel.com  Sun Jul 14 04:04:25 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Sun, 14 Jul 2013 16:04:25 +0800
Subject: [PATCH 1/5] iio: at91: use adc_clk_khz to make the calculation not
 easy to large than u32.
In-Reply-To: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1373789069-11604-2-git-send-email-josh.wu@atmel.com>

for example, if adc_clk is 20Mhz and start-up time set as larger than 215us.
then the calculation "st->startup_time * adc_clk_khz" will out of u32.

In this patch, it will use khz unit for adc_clk, that avoids above problem.

Signed-off-by: Josh Wu <josh.wu at atmel.com>
---
 drivers/iio/adc/at91_adc.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index e5b88d5..18bd54f 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -582,7 +582,7 @@ static const struct iio_info at91_adc_info = {
 
 static int at91_adc_probe(struct platform_device *pdev)
 {
-	unsigned int prsc, mstrclk, ticks, adc_clk, shtim;
+	unsigned int prsc, mstrclk, ticks, adc_clk, adc_clk_khz, shtim;
 	int ret;
 	struct iio_dev *idev;
 	struct at91_adc_state *st;
@@ -680,6 +680,7 @@ static int at91_adc_probe(struct platform_device *pdev)
 	 */
 	mstrclk = clk_get_rate(st->clk);
 	adc_clk = clk_get_rate(st->adc_clk);
+	adc_clk_khz = adc_clk / 1000;
 	prsc = (mstrclk / (2 * adc_clk)) - 1;
 
 	if (!st->startup_time) {
@@ -693,15 +694,15 @@ static int at91_adc_probe(struct platform_device *pdev)
 	 * defined in the electrical characteristics of the board, divided by 8.
 	 * The formula thus is : Startup Time = (ticks + 1) * 8 / ADC Clock
 	 */
-	ticks = round_up((st->startup_time * adc_clk /
-			  1000000) - 1, 8) / 8;
+	ticks = round_up((st->startup_time * adc_clk_khz /
+			  1000) - 1, 8) / 8;
 	/*
 	 * a minimal Sample and Hold Time is necessary for the ADC to guarantee
 	 * the best converted final value between two channels selection
 	 * The formula thus is : Sample and Hold Time = (shtim + 1) / ADCClock
 	 */
-	shtim = round_up((st->sample_hold_time * adc_clk /
-			  1000000) - 1, 1);
+	shtim = round_up((st->sample_hold_time * adc_clk_khz /
+			  1000) - 1, 1);
 
 	reg = AT91_ADC_PRESCAL_(prsc) & AT91_ADC_PRESCAL;
 	reg |= AT91_ADC_STARTUP_(ticks) & AT91_ADC_STARTUP;
-- 
1.7.10



From josh.wu at atmel.com  Sun Jul 14 04:04:26 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Sun, 14 Jul 2013 16:04:26 +0800
Subject: [PATCH 2/5] iio: at91: Use different prescal,
 startup mask in MR for different IP
In-Reply-To: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1373789069-11604-3-git-send-email-josh.wu@atmel.com>

For at91 boards, there are different IPs for adc. Different IPs has different
STARTUP & PRESCAL mask in ADC_MR.

This patch can change the masks according to the different IP version.

Signed-off-by: Josh Wu <josh.wu at atmel.com>
---
 arch/arm/mach-at91/include/mach/at91_adc.h |    9 ++++--
 drivers/iio/adc/at91_adc.c                 |   48 ++++++++++++++++++++++++++--
 2 files changed, 53 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-at91/include/mach/at91_adc.h b/arch/arm/mach-at91/include/mach/at91_adc.h
index 8e7ed5c..ab273ee 100644
--- a/arch/arm/mach-at91/include/mach/at91_adc.h
+++ b/arch/arm/mach-at91/include/mach/at91_adc.h
@@ -28,9 +28,12 @@
 #define			AT91_ADC_TRGSEL_EXTERNAL	(6 << 1)
 #define		AT91_ADC_LOWRES		(1 << 4)	/* Low Resolution */
 #define		AT91_ADC_SLEEP		(1 << 5)	/* Sleep Mode */
-#define		AT91_ADC_PRESCAL	(0x3f << 8)	/* Prescalar Rate Selection */
+#define		AT91_ADC_PRESCAL	(0xff << 8)	/* Prescalar Rate Selection */
+#define		AT91_ADC_PRESCAL_9260	(0x3f << 8)
 #define			AT91_ADC_PRESCAL_(x)	((x) << 8)
-#define		AT91_ADC_STARTUP	(0x1f << 16)	/* Startup Up Time */
+#define		AT91_ADC_STARTUP	(0xf << 16)	/* Startup Up Time */
+#define		AT91_ADC_STARTUP_9260	(0x1f << 16)
+#define		AT91_ADC_STARTUP_9G45	(0x7f << 16)
 #define			AT91_ADC_STARTUP_(x)	((x) << 16)
 #define		AT91_ADC_SHTIM		(0xf  << 24)	/* Sample & Hold Time */
 #define			AT91_ADC_SHTIM_(x)	((x) << 24)
@@ -58,4 +61,6 @@
 #define AT91_ADC_CHR(n)		(0x30 + ((n) * 4))	/* Channel Data Register N */
 #define		AT91_ADC_DATA		(0x3ff)
 
+#define AT91_ADC_VERSION	0xFC
+
 #endif
diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index 18bd54f..14e99ba 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -39,6 +39,12 @@
 #define at91_adc_writel(st, reg, val) \
 	(writel_relaxed(val, st->reg_base + reg))
 
+struct at91_adc_caps {
+	bool	has_tsmr;	/* only at91sam9x5, sama5d3 have TSMR reg */
+	u32	mr_prescal_mask;
+	u32	mr_startup_mask;
+};
+
 struct at91_adc_state {
 	struct clk		*adc_clk;
 	u16			*buffer;
@@ -62,6 +68,7 @@ struct at91_adc_state {
 	u32			res;		/* resolution used for convertions */
 	bool			low_res;	/* the resolution corresponds to the lowest one */
 	wait_queue_head_t	wq_data_avail;
+	struct at91_adc_caps	caps;
 };
 
 static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
@@ -580,6 +587,41 @@ static const struct iio_info at91_adc_info = {
 	.read_raw = &at91_adc_read_raw,
 };
 
+/*
+ * Since atmel adc support different ip for touchscreen mode. Through the
+ * IP check, we will know the touchscreen capbilities.
+ */
+static void atmel_adc_get_cap(struct at91_adc_state *st)
+{
+	unsigned int version;
+	struct iio_dev *idev = iio_priv_to_dev(st);
+
+	version = at91_adc_readl(st, AT91_ADC_VERSION);
+	dev_dbg(&idev->dev, "version: 0x%x\n", version);
+
+	st->caps.mr_prescal_mask = AT91_ADC_PRESCAL_9260;
+	st->caps.mr_startup_mask = AT91_ADC_STARTUP_9260;
+
+	/* keep only major version number */
+	switch (version & 0xf00) {
+	case 0x500:	/* SAMA5D3 */
+	case 0x400:	/* AT91SAM9X5/9N12 */
+		st->caps.has_tsmr = 1;
+		st->caps.mr_startup_mask = AT91_ADC_STARTUP;
+	case 0x200:	/* AT91SAM9M10/9G45 */
+		st->caps.mr_prescal_mask = AT91_ADC_PRESCAL;
+
+		if ((version & 0xf00) == 0x200)
+			st->caps.mr_startup_mask = AT91_ADC_STARTUP_9G45;
+	case 0x100:	/* AT91SAM9260/9G20 */
+		break;
+	default:
+		dev_warn(&idev->dev,
+				"Unmanaged adc version, use minimal capabilities\n");
+		break;
+	};
+}
+
 static int at91_adc_probe(struct platform_device *pdev)
 {
 	unsigned int prsc, mstrclk, ticks, adc_clk, adc_clk_khz, shtim;
@@ -645,6 +687,8 @@ static int at91_adc_probe(struct platform_device *pdev)
 		goto error_free_device;
 	}
 
+	atmel_adc_get_cap(st);
+
 	st->clk = devm_clk_get(&pdev->dev, "adc_clk");
 	if (IS_ERR(st->clk)) {
 		dev_err(&pdev->dev, "Failed to get the clock.\n");
@@ -704,8 +748,8 @@ static int at91_adc_probe(struct platform_device *pdev)
 	shtim = round_up((st->sample_hold_time * adc_clk_khz /
 			  1000) - 1, 1);
 
-	reg = AT91_ADC_PRESCAL_(prsc) & AT91_ADC_PRESCAL;
-	reg |= AT91_ADC_STARTUP_(ticks) & AT91_ADC_STARTUP;
+	reg = AT91_ADC_PRESCAL_(prsc) & st->caps.mr_prescal_mask;
+	reg |= AT91_ADC_STARTUP_(ticks) & st->caps.mr_startup_mask;
 	if (st->low_res)
 		reg |= AT91_ADC_LOWRES;
 	if (st->sleep_mode)
-- 
1.7.10



From josh.wu at atmel.com  Sun Jul 14 04:04:29 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Sun, 14 Jul 2013 16:04:29 +0800
Subject: [PATCH 5/5] iio: at91: introduce touch screen support in iio adc
 driver
In-Reply-To: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
Message-ID: <1373789069-11604-6-git-send-email-josh.wu@atmel.com>

AT91 ADC hardware integrate touch screen support. So this patch add touch
screen support for at91 adc iio driver.
To enable touch screen support in adc, you need to add the dt parameters:
  which type of touch are used? (4 or 5 wires), sample period time,
  pen detect debounce time, average samples and pen detect resistor.

In the meantime, since touch screen will use a interal period trigger of adc,
so it is conflict to other hardware triggers. Driver will disable the hardware
trigger support if touch screen is enabled.

This driver has been tested in AT91SAM9X5-EK and SAMA5D3x-EK.

Signed-off-by: Josh Wu <josh.wu at atmel.com>
Cc: Dmitry Torokhov <dmitry.torokhov at gmail.com>
---
 .../devicetree/bindings/arm/atmel-adc.txt          |   13 +
 arch/arm/mach-at91/include/mach/at91_adc.h         |   34 ++
 drivers/iio/adc/at91_adc.c                         |  389 ++++++++++++++++++--
 3 files changed, 412 insertions(+), 24 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
index 0db2945..925d656 100644
--- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
@@ -29,6 +29,19 @@ Optional properties:
   - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
   - atmel,adc-clock-rate: ADC clock rate. If not specified, use the default
 			  adc_op_clk.
+  - atmel,adc-touchscreen-wires: Number of touch screen wires. Only support
+				 4 and 5 wires touch screen.
+    NOTE: when adc touch screen enabled, the adc hardware trigger will be
+          disabled. Since touch screen will occupied the trigger register.
+  - atmel,adc-ts-pendet-debounce: Debounce time in microsecond for touch pen
+				  detect.
+  - atmel,adc-ts-sample-period-time: Sample Period Time in microsecond for
+				     touch screen
+  - atmel,adc-ts-filter-average: Numbers of sampling data will be averaged.
+    0 means no average. 1 means average two samples. 2 means average four
+    samples. 3 means average eight samples.
+  - atmel,adc-ts-pendet-sensitivity: Pen Detection input pull-up resistor.
+    It can be 0, 1, 2, 3.
  
 Optional trigger Nodes:
   - Required properties:
diff --git a/arch/arm/mach-at91/include/mach/at91_adc.h b/arch/arm/mach-at91/include/mach/at91_adc.h
index ab273ee..6d6cc14 100644
--- a/arch/arm/mach-at91/include/mach/at91_adc.h
+++ b/arch/arm/mach-at91/include/mach/at91_adc.h
@@ -57,10 +57,44 @@
 #define AT91_ADC_IER		0x24		/* Interrupt Enable Register */
 #define AT91_ADC_IDR		0x28		/* Interrupt Disable Register */
 #define AT91_ADC_IMR		0x2C		/* Interrupt Mask Register */
+#define		AT91_ADC_IER_PEN	(1 << 29)
+#define		AT91_ADC_IER_NOPEN	(1 << 30)
+#define		AT91_ADC_IER_XRDY	(1 << 20)
+#define		AT91_ADC_IER_YRDY	(1 << 21)
+#define		AT91_ADC_IER_PRDY	(1 << 22)
+#define		AT91_ADC_ISR_PENS	(1 << 31)
 
 #define AT91_ADC_CHR(n)		(0x30 + ((n) * 4))	/* Channel Data Register N */
 #define		AT91_ADC_DATA		(0x3ff)
 
+#define AT91_ADC_ACR		0x94	/* Analog Control Register */
+#define		AT91_ADC_ACR_PENDETSENS	(0x3 << 0)	/* pull-up resistor */
+
+#define AT91_ADC_TSMR		0xB0
+#define		AT91_ADC_TSMR_TSMODE	(3 << 0)	/* Touch Screen Mode */
+#define			AT91_ADC_TSMR_TSMODE_NONE		(0 << 0)
+#define			AT91_ADC_TSMR_TSMODE_4WIRE_NO_PRESS	(1 << 0)
+#define			AT91_ADC_TSMR_TSMODE_4WIRE_PRESS	(2 << 0)
+#define			AT91_ADC_TSMR_TSMODE_5WIRE		(3 << 0)
+#define		AT91_ADC_TSMR_TSAV	(3 << 4)	/* Averages samples */
+#define			AT91_ADC_TSMR_TSAV_(x)		((x) << 4)
+#define		AT91_ADC_TSMR_SCTIM	(0x0f << 16)	/* Switch closure time */
+#define		AT91_ADC_TSMR_PENDBC	(0x0f << 28)	/* Pen Debounce time */
+#define			AT91_ADC_TSMR_PENDBC_(x)	((x) << 28)
+#define		AT91_ADC_TSMR_NOTSDMA	(1 << 22)	/* No Touchscreen DMA */
+#define		AT91_ADC_TSMR_PENDET_DIS	(0 << 24)	/* Pen contact detection disable */
+#define		AT91_ADC_TSMR_PENDET_ENA	(1 << 24)	/* Pen contact detection enable */
+
+#define AT91_ADC_TSXPOSR	0xB4
+#define AT91_ADC_TSYPOSR	0xB8
+#define AT91_ADC_TSPRESSR	0xBC
+
 #define AT91_ADC_VERSION	0xFC
 
+/* Trigger Register bit field */
+#define		AT91_ADC_TRGR_TRGPER	(0xffff << 16)
+#define			AT91_ADC_TRGR_TRGPER_(x)	((x) << 16)
+#define		AT91_ADC_TRGR_TRGMOD	(0x7 << 0)
+#define			AT91_ADC_TRGR_MOD_PERIOD_TRIG	(5 << 0)
+
 #endif
diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index 8f1386f..ffc0e42 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -11,6 +11,7 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/io.h>
+#include <linux/input.h>
 #include <linux/interrupt.h>
 #include <linux/jiffies.h>
 #include <linux/kernel.h>
@@ -39,12 +40,24 @@
 #define at91_adc_writel(st, reg, val) \
 	(writel_relaxed(val, st->reg_base + reg))
 
+#define DRIVER_NAME		"at91_adc"
+#define MAX_POS_BITS		12
+
+#define ZTHRESHOLD		9000
+
 struct at91_adc_caps {
+	bool	has_12bits_xy;	/* true means use 12 bits. Otherwise 10 bits */
 	bool	has_tsmr;	/* only at91sam9x5, sama5d3 have TSMR reg */
 	u32	mr_prescal_mask;
 	u32	mr_startup_mask;
 };
 
+enum atmel_adc_ts_type {
+	ATMEL_ADC_TOUCHSCREEN_NONE = 0,
+	ATMEL_ADC_TOUCHSCREEN_4WIRE,
+	ATMEL_ADC_TOUCHSCREEN_5WIRE,
+};
+
 struct at91_adc_state {
 	struct clk		*adc_clk;
 	u32			adc_clk_rate;
@@ -70,6 +83,29 @@ struct at91_adc_state {
 	bool			low_res;	/* the resolution corresponds to the lowest one */
 	wait_queue_head_t	wq_data_avail;
 	struct at91_adc_caps	caps;
+
+	/*
+	 * Following ADC channels are shared by touchscreen:
+	 *
+	 * CH0 -- Touch screen XP/UL
+	 * CH1 -- Touch screen XM/UR
+	 * CH2 -- Touch screen YP/LL
+	 * CH3 -- Touch screen YM/Sense
+	 * CH4 -- Touch screen LR(5-wire only)
+	 *
+	 * The bitfields below represents the reserved channel in the
+	 * touchscreen mode.
+	 */
+#define CHAN_MASK_TOUCHSCREEN_4WIRE	(0xf << 0)
+#define CHAN_MASK_TOUCHSCREEN_5WIRE	(0x1f << 0)
+	enum atmel_adc_ts_type	touchscreen_type;
+	struct input_dev		*ts_input;
+
+	u8			ts_filter_average;
+	u16			ts_pen_detect_debounce;
+	u8			ts_pen_detect_sensitivity;
+	u16			ts_sample_period_time;
+	u16			ts_sample_period_val;
 };
 
 static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
@@ -104,14 +140,10 @@ static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
 	return IRQ_HANDLED;
 }
 
-static irqreturn_t at91_adc_eoc_trigger(int irq, void *private)
+/* Handler for classic adc channel eoc trigger */
+void handle_adc_eoc_trigger(int irq, struct iio_dev *idev)
 {
-	struct iio_dev *idev = private;
 	struct at91_adc_state *st = iio_priv(idev);
-	u32 status = at91_adc_readl(st, st->registers->status_register);
-
-	if (!(status & st->registers->drdy_mask))
-		return IRQ_HANDLED;
 
 	if (iio_buffer_enabled(idev)) {
 		disable_irq_nosync(irq);
@@ -121,6 +153,115 @@ static irqreturn_t at91_adc_eoc_trigger(int irq, void *private)
 		st->done = true;
 		wake_up_interruptible(&st->wq_data_avail);
 	}
+}
+
+static int at91_ts_sample(struct at91_adc_state *st)
+{
+	unsigned int xscale, yscale, reg, z1, z2;
+	unsigned int x, y, pres, xpos, ypos;
+	unsigned int rxp = 1;
+	unsigned int factor = 1000;
+	struct iio_dev *idev = iio_priv_to_dev(st);
+
+	unsigned int xyz_mask_bits = st->caps.has_12bits_xy ? 12 : 10;
+	unsigned int xyz_mask = (1 << xyz_mask_bits) - 1;
+
+	/* calculate position */
+	/* x position = (x / xscale) * max, max = 2^MAX_POS_BITS - 1 */
+	reg = at91_adc_readl(st, AT91_ADC_TSXPOSR);
+	xpos = reg & xyz_mask;
+	x = (xpos << MAX_POS_BITS) - xpos;
+	xscale = (reg >> 16) & xyz_mask;
+	if (xscale != 0)
+		x /= xscale;
+	else
+		dev_err(&idev->dev, "xscale == 0!!!\n");
+
+	/* y position = (y / yscale) * max, max = 2^MAX_POS_BITS - 1 */
+	reg = at91_adc_readl(st, AT91_ADC_TSYPOSR);
+	ypos = reg & xyz_mask;
+	y = (ypos << MAX_POS_BITS) - ypos;
+	yscale = (reg >> 16) & xyz_mask;
+	if (yscale != 0)
+		y /= yscale;
+	else
+		dev_err(&idev->dev, "yscale == 0!!!\n");
+
+	/* calculate the pressure */
+	reg = at91_adc_readl(st, AT91_ADC_TSPRESSR);
+	z1 = reg & xyz_mask;
+	z2 = (reg >> 16) & xyz_mask;
+
+	if (z1 != 0)
+		pres = rxp * (x * factor / 1024) * (z2 * factor / z1 - factor)
+			/ factor;
+	else
+		pres = ZTHRESHOLD;	/* no pen contacted */
+
+	dev_dbg(&idev->dev, "xpos = %d, xscale = %d, ypos = %d, yscale = %d, z1 = %d, z2 = %d, press = %d\n",
+				xpos, xscale, ypos, yscale, z1, z2, pres);
+
+	if (pres < ZTHRESHOLD) {
+		dev_dbg(&idev->dev, "x = %d, y = %d, pressure = %d\n",
+					x, y, pres / factor);
+		input_report_abs(st->ts_input, ABS_X, x);
+		input_report_abs(st->ts_input, ABS_Y, y);
+		input_report_abs(st->ts_input, ABS_PRESSURE, pres);
+		input_report_key(st->ts_input, BTN_TOUCH, 1);
+		input_sync(st->ts_input);
+	} else {
+		dev_dbg(&idev->dev,
+				"pressure too low: not reporting\n");
+	}
+
+	return 0;
+}
+
+
+static irqreturn_t at91_adc_interrupt(int irq, void *private)
+{
+	struct iio_dev *idev = private;
+	struct at91_adc_state *st = iio_priv(idev);
+	u32 status = at91_adc_readl(st, st->registers->status_register);
+	const uint32_t ts_data_irq_mask =
+		AT91_ADC_IER_XRDY |
+		AT91_ADC_IER_YRDY |
+		AT91_ADC_IER_PRDY;
+
+	if (status & st->registers->drdy_mask)
+		handle_adc_eoc_trigger(irq, idev);
+
+	if (status & AT91_ADC_IER_PEN) {
+		at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_PEN);
+		at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_NOPEN |
+			ts_data_irq_mask);
+		/* Set up period trigger for sampling */
+		at91_adc_writel(st, st->registers->trigger_register,
+			AT91_ADC_TRGR_MOD_PERIOD_TRIG |
+			AT91_ADC_TRGR_TRGPER_(st->ts_sample_period_val));
+	} else if (status & AT91_ADC_IER_NOPEN) {
+		at91_adc_writel(st, st->registers->trigger_register, 0);
+		at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_NOPEN |
+			ts_data_irq_mask);
+		at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_PEN);
+
+		input_report_key(st->ts_input, BTN_TOUCH, 0);
+		input_sync(st->ts_input);
+	} else if ((status & ts_data_irq_mask) == ts_data_irq_mask) {
+		/* Now all touchscreen data is ready */
+
+		if (status & AT91_ADC_ISR_PENS) {
+			/* validate data by pen contact */
+			at91_ts_sample(st);
+		} else {
+			/* triggered by event that is no pen contact, just read
+			 * them to clean the interrupt and discard all.
+			 */
+			at91_adc_readl(st, AT91_ADC_TSXPOSR);
+			at91_adc_readl(st, AT91_ADC_TSYPOSR);
+			at91_adc_readl(st, AT91_ADC_TSPRESSR);
+		}
+	}
 
 	return IRQ_HANDLED;
 }
@@ -130,6 +271,16 @@ static int at91_adc_channel_init(struct iio_dev *idev)
 	struct at91_adc_state *st = iio_priv(idev);
 	struct iio_chan_spec *chan_array, *timestamp;
 	int bit, idx = 0;
+	unsigned long rsvd_mask = 0;
+
+	/* If touchscreen is enable, then reserve the adc channels */
+	if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_4WIRE)
+		rsvd_mask = CHAN_MASK_TOUCHSCREEN_4WIRE;
+	else if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_5WIRE)
+		rsvd_mask = CHAN_MASK_TOUCHSCREEN_5WIRE;
+
+	/* set up the channel mask to reserve touchscreen channels */
+	st->channels_mask &= ~rsvd_mask;
 
 	idev->num_channels = bitmap_weight(&st->channels_mask,
 					   st->num_channels) + 1;
@@ -561,6 +712,57 @@ static int at91_adc_probe_dt(struct at91_adc_state *st,
 		i++;
 	}
 
+	/* Check if touchscreen is enabled in DT. */
+	ret = of_property_read_u32(node, "atmel,adc-touchscreen-wires", &prop);
+	if (ret)
+		dev_info(&idev->dev, "Touchscreen not enabled.\n");
+	else if (prop == 4)
+		st->touchscreen_type = ATMEL_ADC_TOUCHSCREEN_4WIRE;
+	else if (prop == 5)
+		st->touchscreen_type = ATMEL_ADC_TOUCHSCREEN_5WIRE;
+	else
+		dev_warn(&idev->dev, "Unsupported number of touchscreen wires (%d)\n",
+				prop);
+
+	if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_NONE)
+		return 0;
+
+	/* Touch screen is enabled, so check touch screen dt parameters */
+	if (of_property_read_u32(node, "atmel,adc-ts-filter-average", &prop)) {
+		dev_err(&idev->dev, "Missing atmel,adc-ts-filtering-average property in the DT.\n");
+		ret = -EINVAL;
+		goto error_ret;
+	}
+	st->ts_filter_average = prop;
+	if (st->ts_filter_average > 3) {
+		dev_err(&idev->dev, "Invalid atmel,adc-ts-filtering-average property in the DT.\n");
+		ret = -EINVAL;
+		goto error_ret;
+	}
+
+	prop = 0;
+	of_property_read_u32(node, "atmel,adc-ts-pendet-debounce", &prop);
+	st->ts_pen_detect_debounce = prop;
+
+	/* default sample period is 2ms. The real touch sample period should be
+	 * this period * TSFREQ.
+	 */
+	prop = 2000;
+	of_property_read_u32(node, "atmel,adc-ts-sample-period-time", &prop);
+	st->ts_sample_period_time = prop;
+
+	if (of_property_read_u32(node, "atmel,adc-ts-pendet-sensitivity", &prop)) {
+		dev_err(&idev->dev, "Missing atmel,adc-ts-pendet-sensitivity property in the DT.\n");
+		ret = -EINVAL;
+		goto error_ret;
+	}
+	st->ts_pen_detect_sensitivity = prop;
+	if (st->ts_pen_detect_sensitivity > 3) {
+		dev_err(&idev->dev, "Invalid atmel,adc-ts-pendet-sensitivity property in the DT.\n");
+		ret = -EINVAL;
+		goto error_ret;
+	}
+
 	return 0;
 
 error_ret:
@@ -592,6 +794,114 @@ static const struct iio_info at91_adc_info = {
 	.read_raw = &at91_adc_read_raw,
 };
 
+/* Touchscreen related functions */
+static int atmel_ts_open(struct input_dev *dev)
+{
+	struct at91_adc_state *st = input_get_drvdata(dev);
+
+	at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_PEN);
+	return 0;
+}
+
+static void atmel_ts_close(struct input_dev *dev)
+{
+	struct at91_adc_state *st = input_get_drvdata(dev);
+
+	at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_PEN);
+}
+
+static int at91_ts_hw_init(struct at91_adc_state *st, u32 adc_clk_khz)
+{
+	u32 reg = 0, pendbc;
+	int i = 0;
+
+	if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_4WIRE)
+		reg = AT91_ADC_TSMR_TSMODE_4WIRE_PRESS;
+	else
+		reg = AT91_ADC_TSMR_TSMODE_5WIRE;
+
+	/* a Pen Detect Debounce Time is necessary for the ADC Touch to avoid
+	 * pen detect noise.
+	 * The formula is : Pen Detect Debounce Time = (2 ^ pendbc) / ADCClock
+	 */
+	pendbc = round_up(st->ts_pen_detect_debounce * adc_clk_khz / 1000, 1);
+
+	while (pendbc >> ++i)
+		;	/* Empty! Find the shift offset */
+	if (abs(pendbc - (1 << i)) < abs(pendbc - (1 << (i - 1))))
+		pendbc = i;
+	else
+		pendbc = i - 1;
+
+	if (st->caps.has_tsmr) {
+		reg |= AT91_ADC_TSMR_TSAV_(st->ts_filter_average)
+				& AT91_ADC_TSMR_TSAV;
+		reg |= AT91_ADC_TSMR_PENDBC_(pendbc) & AT91_ADC_TSMR_PENDBC;
+		reg |= AT91_ADC_TSMR_NOTSDMA;
+		reg |= AT91_ADC_TSMR_PENDET_ENA;
+		reg |= 0x03 << 8;	/* TSFREQ, need bigger than TSAV */
+
+		at91_adc_writel(st, AT91_ADC_TSMR, reg);
+	} else {
+		/* TODO: for 9g45 which has no TSMR */
+	}
+
+	/* Change adc internal resistor value for better pen detection,
+	 * default value is 100 kOhm.
+	 * 0 = 200 kOhm, 1 = 150 kOhm, 2 = 100 kOhm, 3 = 50 kOhm
+	 * option only available on ES2 and higher
+	 */
+	at91_adc_writel(st, AT91_ADC_ACR, st->ts_pen_detect_sensitivity
+			& AT91_ADC_ACR_PENDETSENS);
+
+	/* Sample Peroid Time = (TRGPER + 1) / ADCClock */
+	st->ts_sample_period_val = round_up((st->ts_sample_period_time *
+			adc_clk_khz / 1000) - 1, 1);
+
+	return 0;
+}
+
+static int at91_ts_register(struct at91_adc_state *st)
+{
+	struct input_dev *input;
+	struct iio_dev *idev = iio_priv_to_dev(st);
+	int ret;
+
+	input = input_allocate_device();
+	if (!input) {
+		dev_err(&idev->dev, "Failed to allocate TS device!\n");
+		return -ENOMEM;
+	}
+
+	input->name = DRIVER_NAME;
+	input->id.bustype = BUS_HOST;
+	input->dev.parent = idev->dev.parent;
+	input->open = atmel_ts_open;
+	input->close = atmel_ts_close;
+
+	__set_bit(EV_ABS, input->evbit);
+	__set_bit(EV_KEY, input->evbit);
+	__set_bit(BTN_TOUCH, input->keybit);
+	input_set_abs_params(input, ABS_X, 0, (1 << MAX_POS_BITS) - 1, 0, 0);
+	input_set_abs_params(input, ABS_Y, 0, (1 << MAX_POS_BITS) - 1, 0, 0);
+	input_set_abs_params(input, ABS_PRESSURE, 0, 0xffffff, 0, 0);
+
+	st->ts_input = input;
+	input_set_drvdata(input, st);
+
+	ret = input_register_device(input);
+	if (ret)
+		input_free_device(st->ts_input);
+
+	return ret;
+}
+
+static void at91_ts_unregister(struct at91_adc_state *st)
+{
+	input_unregister_device(st->ts_input);
+	input_free_device(st->ts_input);
+}
+
 /*
  * Since atmel adc support different ip for touchscreen mode. Through the
  * IP check, we will know the touchscreen capbilities.
@@ -610,6 +920,7 @@ static void atmel_adc_get_cap(struct at91_adc_state *st)
 	/* keep only major version number */
 	switch (version & 0xf00) {
 	case 0x500:	/* SAMA5D3 */
+		st->caps.has_12bits_xy = 1;
 	case 0x400:	/* AT91SAM9X5/9N12 */
 		st->caps.has_tsmr = 1;
 		st->caps.mr_startup_mask = AT91_ADC_STARTUP;
@@ -683,7 +994,7 @@ static int at91_adc_probe(struct platform_device *pdev)
 	at91_adc_writel(st, AT91_ADC_CR, AT91_ADC_SWRST);
 	at91_adc_writel(st, AT91_ADC_IDR, 0xFFFFFFFF);
 	ret = request_irq(st->irq,
-			  at91_adc_eoc_trigger,
+			  at91_adc_interrupt,
 			  0,
 			  pdev->dev.driver->name,
 			  idev);
@@ -731,6 +1042,10 @@ static int at91_adc_probe(struct platform_device *pdev)
 	adc_clk = st->adc_clk_rate ?
 		st->adc_clk_rate : clk_get_rate(st->adc_clk);
 	adc_clk_khz = adc_clk / 1000;
+
+	dev_dbg(&pdev->dev, "Master clock is set as: %d Hz, adc_clk should set as: %d Hz\n",
+		mstrclk, adc_clk);
+
 	prsc = (mstrclk / (2 * adc_clk)) - 1;
 
 	if (!st->startup_time) {
@@ -799,30 +1114,52 @@ static int at91_adc_probe(struct platform_device *pdev)
 	init_waitqueue_head(&st->wq_data_avail);
 	mutex_init(&st->lock);
 
-	ret = at91_adc_buffer_init(idev);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "Couldn't initialize the buffer.\n");
-		goto error_disable_adc_clk;
-	}
+	/*
+	 * Since touch screen will set trigger register as period trigger. So
+	 * when touch screen is enabled, then we have to disable hardware
+	 * trigger for classic adc.
+	 */
+	if (!st->touchscreen_type) {
+		ret = at91_adc_buffer_init(idev);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "Couldn't initialize the buffer.\n");
+			goto error_disable_adc_clk;
+		}
 
-	ret = at91_adc_trigger_init(idev);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "Couldn't setup the triggers.\n");
-		goto error_unregister_buffer;
+		ret = at91_adc_trigger_init(idev);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "Couldn't setup the triggers.\n");
+			at91_adc_buffer_remove(idev);
+			goto error_disable_adc_clk;
+		}
+	} else {
+		if (!st->caps.has_tsmr) {
+			dev_err(&pdev->dev, "We don't support non-TSMR adc\n");
+			goto error_disable_adc_clk;
+		}
+
+		ret = at91_ts_register(st);
+		if (ret)
+			goto error_disable_adc_clk;
+
+		at91_ts_hw_init(st, adc_clk_khz);
 	}
 
 	ret = iio_device_register(idev);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Couldn't register the device.\n");
-		goto error_remove_triggers;
+		goto error_iio_device_register;
 	}
 
 	return 0;
 
-error_remove_triggers:
-	at91_adc_trigger_remove(idev);
-error_unregister_buffer:
-	at91_adc_buffer_remove(idev);
+error_iio_device_register:
+	if (!st->touchscreen_type) {
+		at91_adc_trigger_remove(idev);
+		at91_adc_buffer_remove(idev);
+	} else {
+		at91_ts_unregister(st);
+	}
 error_disable_adc_clk:
 	clk_disable_unprepare(st->adc_clk);
 error_disable_clk:
@@ -841,8 +1178,12 @@ static int at91_adc_remove(struct platform_device *pdev)
 	struct at91_adc_state *st = iio_priv(idev);
 
 	iio_device_unregister(idev);
-	at91_adc_trigger_remove(idev);
-	at91_adc_buffer_remove(idev);
+	if (!st->touchscreen_type) {
+		at91_adc_trigger_remove(idev);
+		at91_adc_buffer_remove(idev);
+	} else {
+		at91_ts_unregister(st);
+	}
 	clk_disable_unprepare(st->adc_clk);
 	clk_disable_unprepare(st->clk);
 	free_irq(st->irq, idev);
@@ -861,7 +1202,7 @@ static struct platform_driver at91_adc_driver = {
 	.probe = at91_adc_probe,
 	.remove = at91_adc_remove,
 	.driver = {
-		   .name = "at91_adc",
+		   .name = DRIVER_NAME,
 		   .of_match_table = of_match_ptr(at91_adc_dt_ids),
 	},
 };
-- 
1.7.10



From arnd at arndb.de  Sun Jul 14 04:34:42 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sun, 14 Jul 2013 10:34:42 +0200
Subject: [PATCH] ARM: multiplatform: remove reference to ARCH_MULTI_V4
In-Reply-To: <1373746191.1359.37.camel@x61.thuisdomein>
References: <1373746191.1359.37.camel@x61.thuisdomein>
Message-ID: <201307141034.42868.arnd@arndb.de>

On Saturday 13 July 2013, Paul Bolle wrote:
> The Kconfig symbol ARCH_MULTI_V4 was removed in commit 24e860fbfd
> ("ARM: multiplatform: always pick one CPU type"). Remove the last
> reference to it too.
> 
> Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
> ---
> 0) Untested.
> 
> 1) Commit 24e860fbfd is silent on the reason to drop ARCH_MULTI_V4. And
> the ARM section of the Kconfig files is rather complicated for people,
> like me, that aren't familiar with the way the ARM universe is divided
> in architectures, machines, platforms, etc. That makes it hard to say
> whether ARCH_MULTI_V4 was dropped on purpose or by accident.

It was dropped on purpose because it is unused in 3.11 but it will
be used again in 3.12, so I wouldn't bother with your patch.

Thanks anyway for looking into unused symbols, I think checking for
unused code like this is very useful in general.

	Arnd


From pebolle at tiscali.nl  Sun Jul 14 06:38:05 2013
From: pebolle at tiscali.nl (Paul Bolle)
Date: Sun, 14 Jul 2013 12:38:05 +0200
Subject: [PATCH] ARM: keystone: drop "select HAVE_SCHED_CLOCK"
Message-ID: <1373798285.1370.2.camel@x61.thuisdomein>

The Kconfig symbol HAVE_SCHED_CLOCK got removed in v3.4,
with commit 6905a65879b5 ("ARM: Make the sched_clock
framework mandatory"). But a select statement for it popped up again
through commit 828989ad87af ("ARM: keystone: Add minimal TI Keystone
platform support"). Drop that statement, as it is useless.

Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
---
Not tested.

 arch/arm/mach-keystone/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index 51a50e9..366d1a3 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -7,7 +7,6 @@ config ARCH_KEYSTONE
 	select HAVE_SMP
 	select CLKSRC_MMIO
 	select GENERIC_CLOCKEVENTS
-	select HAVE_SCHED_CLOCK
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_ERRATA_798181 if SMP
 	help
-- 
1.8.1.4



From fgenfb at yahoo.com  Sun Jul 14 07:00:50 2013
From: fgenfb at yahoo.com (Harm Hanemaaijer)
Date: Sun, 14 Jul 2013 11:00:50 +0000 (UTC)
Subject: Call for testing/opinions: Optimized memset/memcpy
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713172445.GL32054@1wt.eu> <loom.20130713T232124-511@post.gmane.org>
 <20130714061354.GS32054@1wt.eu>
Message-ID: <loom.20130714T124137-382@post.gmane.org>

Willy Tarreau <w <at> 1wt.eu> writes:

> 
> Please find the results attached. It seems that memcpy improved by 0.8%
> though that's not even certain.
> 

What is interesting is that
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Caccifbd.html,
and several other sources (such as other
optimized memcpy implementations) document the cache line size of the Cortex
A9 as 32 bytes, which is an anomaly in the armv7 family. However, it looks
like the kernel is defining L1_CACHE_BYTES as 64 (L1_CACHE_SHIFT == 6) for
all armv7 platforms, which looks like a serious configuring error for Cortex
A9.

This explains why the large size memcpy results that you posted are not
optimal, and also explains the below-par copy_page performance in the current
kernel implementation, because copy_page uses L1_CACHE_BYTES to determine the
preload strategy, while the current memcpy doesn't (it is hardcoded for
L1_CACHE_BYTES of 32).

This merits further investigation, and there might potentially be other
kernel issues for Cortex A9 (including performance) related to this.

To confirm, does running 'zcat /proc/config.gz| grep L1_CACHE_SHIFT' on a
Cortex A9 show CONFIG_ARM_L1_CACHE_SHIFT defined as 6?




From fgenfb at yahoo.com  Sun Jul 14 07:19:27 2013
From: fgenfb at yahoo.com (Harm Hanemaaijer)
Date: Sun, 14 Jul 2013 11:19:27 +0000 (UTC)
Subject: Call for testing/opinions: Optimized memset/memcpy
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713164840.GC28473@gallifrey>
Message-ID: <loom.20130714T130546-799@post.gmane.org>

Dr. David Alan Gilbert <gilbertd <at> treblig.org> writes:
> 
> Maybe neon is worth a try these days (although be careful of platforms
> like Tegra 2 that doens't have it); there was a recent patch that enabled
> use in the kernel (I think for some RAID use). The downside is it's
> supposed to be quite power hungry.
> 

As it turns out, NEON isn't too hard to implement. I have added NEON support
to copy_page, memset, memzero, and memcpy (both for the aligned and unaligned
case) in my userspace testing environment. It gives a nice boost (ranging
from 10% for copy_page to >30% for unaligned memcpy on a Cortex A8), which
can potentially be more on other cores. Although I have not tested a live
kernel yet, it looks like NEON can be used fairly transparently #ifdefed on
the CONFIG_NEON kernel definition as long as only the lower end of the
NEON/vfp register file is clobbered (although this needs verification).




From gilbertd at treblig.org  Sun Jul 14 07:32:51 2013
From: gilbertd at treblig.org (Dr. David Alan Gilbert)
Date: Sun, 14 Jul 2013 12:32:51 +0100
Subject: Call for testing/opinions: Optimized memset/memcpy
In-Reply-To: <loom.20130714T130546-799@post.gmane.org>
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713164840.GC28473@gallifrey>
 <loom.20130714T130546-799@post.gmane.org>
Message-ID: <20130714113251.GA27803@gallifrey>

* Harm Hanemaaijer (fgenfb at yahoo.com) wrote:
> Dr. David Alan Gilbert <gilbertd <at> treblig.org> writes:
> > 
> > Maybe neon is worth a try these days (although be careful of platforms
> > like Tegra 2 that doens't have it); there was a recent patch that enabled
> > use in the kernel (I think for some RAID use). The downside is it's
> > supposed to be quite power hungry.
> > 
> 
> As it turns out, NEON isn't too hard to implement. I have added NEON support
> to copy_page, memset, memzero, and memcpy (both for the aligned and unaligned
> case) in my userspace testing environment. It gives a nice boost (ranging
> from 10% for copy_page to >30% for unaligned memcpy on a Cortex A8), which
> can potentially be more on other cores.

What size memcpy's is that on?   If I remember correctly A8 happens to be
able to do very fast Neon to it's cache but it doesn't help outside of the cache,
and it doesn't make any benefit on A9.

> Although I have not tested a live
> kernel yet, it looks like NEON can be used fairly transparently #ifdefed on
> the CONFIG_NEON kernel definition as long as only the lower end of the
> NEON/vfp register file is clobbered (although this needs verification).

Hmm I'd assumed there would be some save/restory stuff needed and given
copy_to_ etc get used everywhere I'd be careful.

Dave
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\ gro.gilbert @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/


From ard.biesheuvel at linaro.org  Sun Jul 14 07:37:44 2013
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Sun, 14 Jul 2013 13:37:44 +0200
Subject: Call for testing/opinions: Optimized memset/memcpy
In-Reply-To: <loom.20130714T130546-799@post.gmane.org>
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713164840.GC28473@gallifrey>
 <loom.20130714T130546-799@post.gmane.org>
Message-ID: <CAKv+Gu-fUNSZaNMgZekoCX2kOGEFDLKY1yFtKq1=yp9xQN3rOA@mail.gmail.com>

On 14 July 2013 13:19, Harm Hanemaaijer <fgenfb at yahoo.com> wrote:
> Dr. David Alan Gilbert <gilbertd <at> treblig.org> writes:
>>
>> Maybe neon is worth a try these days (although be careful of platforms
>> like Tegra 2 that doens't have it); there was a recent patch that enabled
>> use in the kernel (I think for some RAID use). The downside is it's
>> supposed to be quite power hungry.
>>
>
> As it turns out, NEON isn't too hard to implement. I have added NEON support
> to copy_page, memset, memzero, and memcpy (both for the aligned and unaligned
> case) in my userspace testing environment. It gives a nice boost (ranging
> from 10% for copy_page to >30% for unaligned memcpy on a Cortex A8), which
> can potentially be more on other cores. Although I have not tested a live
> kernel yet, it looks like NEON can be used fairly transparently #ifdefed on
> the CONFIG_NEON kernel definition as long as only the lower end of the
> NEON/vfp register file is clobbered (although this needs verification).
>

You will clobber the userland NEON contents of the register file if
you don't preserve them properly. Also, kernel preemption (if enabled)
may put your task to sleep at any time, and the context switching
machinery is totally oblivious of NEON being used in the kernel, so
the kernel side will get corrupted as well in this case.

I have a patch series pending (i.e., accepted but not pulled yet by
Russell) which addresses these issues.



--
Ard.


From pebolle at tiscali.nl  Sun Jul 14 08:02:19 2013
From: pebolle at tiscali.nl (Paul Bolle)
Date: Sun, 14 Jul 2013 14:02:19 +0200
Subject: [PATCH] cpufreq: s3c24xx: fix typo "ARM_S3C24XX"
Message-ID: <1373803339.1370.18.camel@x61.thuisdomein>

Kconfig symbol S3C24XX_PLL depends on ARM_S3C24XX. But that symbol
doesn't exist. Commit f023f8dd59bf ("cpufreq: s3c24xx: move cpufreq
driver to drivers/cpufreq"), which added this typo, makes clear that
ARM_S3C24XX_CPUFREQ was intended here.

Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
---
Untested!

 arch/arm/mach-s3c24xx/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 6d9252e..7791ac7 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -208,7 +208,7 @@ config S3C24XX_GPIO_EXTRA128
 
 config S3C24XX_PLL
 	bool "Support CPUfreq changing of PLL frequency (EXPERIMENTAL)"
-	depends on ARM_S3C24XX
+	depends on ARM_S3C24XX_CPUFREQ
 	help
 	  Compile in support for changing the PLL frequency from the
 	  S3C24XX series CPUfreq driver. The PLL takes time to settle
-- 
1.8.1.4



From pebolle at tiscali.nl  Sun Jul 14 08:26:52 2013
From: pebolle at tiscali.nl (Paul Bolle)
Date: Sun, 14 Jul 2013 14:26:52 +0200
Subject: [PATCH] ARM: EXYNOS: remove references to non-DT SoCs
Message-ID: <1373804812.1370.23.camel@x61.thuisdomein>

Commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT for EXYNOS
SoCs") removed the Kconfig symbols MACH_SMDKV310 and MACH_SMDKC210.
Now remove the references to both of these symbols from the Kconfig
entry for SND_SOC_SAMSUNG_SMDK_WM9713. They're not needed anymore.

Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
---
Untested.

 sound/soc/samsung/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 9855dfc..3d76659 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -136,7 +136,7 @@ config SND_SOC_SAMSUNG_RX1950_UDA1380
 
 config SND_SOC_SAMSUNG_SMDK_WM9713
 	tristate "SoC AC97 Audio support for SMDK with WM9713"
-	depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310 || MACH_SMDKC210)
+	depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110)
 	select SND_SOC_WM9713
 	select SND_SAMSUNG_AC97
 	help
-- 
1.8.1.4



From broonie at kernel.org  Sun Jul 14 08:45:38 2013
From: broonie at kernel.org (Mark Brown)
Date: Sun, 14 Jul 2013 13:45:38 +0100
Subject: [PATCH] ARM: EXYNOS: remove references to non-DT SoCs
In-Reply-To: <1373804812.1370.23.camel@x61.thuisdomein>
References: <1373804812.1370.23.camel@x61.thuisdomein>
Message-ID: <20130714124538.GA11538@sirena.org.uk>

On Sun, Jul 14, 2013 at 02:26:52PM +0200, Paul Bolle wrote:
> Commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT for EXYNOS
> SoCs") removed the Kconfig symbols MACH_SMDKV310 and MACH_SMDKC210.
> Now remove the references to both of these symbols from the Kconfig
> entry for SND_SOC_SAMSUNG_SMDK_WM9713. They're not needed anymore.

Look at the code you are editing here:

> -       depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310 || MACH_SMDKC210)
> +       depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110)

Simply removing the dependencies is not going to give the clearly
intended effect here.  The dependency on the DT only machine needs to be
replaced with something, not just deleted, otherwise the driver can't be
enabled in Kconfig.

Also let me again remind you to submit patches with subject lines that
are appropriate for the subsystem you're updating.  I very nearly
deleted this unread since it looks like a patch for arch/arm with no
relationship with audio but in fact it doesn't touch arch/arm at all.
-------------- 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/20130714/5cfbc8a3/attachment.sig>

From linux at arm.linux.org.uk  Sun Jul 14 09:09:50 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sun, 14 Jul 2013 14:09:50 +0100
Subject: Call for testing/opinions: Optimized memset/memcpy
In-Reply-To: <loom.20130714T124137-382@post.gmane.org>
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713172445.GL32054@1wt.eu> <loom.20130713T232124-511@post.gmane.org>
 <20130714061354.GS32054@1wt.eu> <loom.20130714T124137-382@post.gmane.org>
Message-ID: <20130714130949.GR24642@n2100.arm.linux.org.uk>

On Sun, Jul 14, 2013 at 11:00:50AM +0000, Harm Hanemaaijer wrote:
> What is interesting is that
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Caccifbd.html,
> and several other sources (such as other
> optimized memcpy implementations) document the cache line size of the Cortex
> A9 as 32 bytes, which is an anomaly in the armv7 family. However, it looks
> like the kernel is defining L1_CACHE_BYTES as 64 (L1_CACHE_SHIFT == 6) for
> all armv7 platforms, which looks like a serious configuring error for Cortex
> A9.

You're making wrong assumptions about what L1_CACHE_BYTES is.

Firstly, L1_CACHE_BYTES is not dynamic - it's a build time constant.
You have to make a decision what value it is to be set to when you
build the kernel.  This is because it gets used to determine the
alignment of structures built into the kernel image, amongst other
things, and we can't dynamically relink the kernel at boot time.

So please, get out of your mind any idea that L1_CACHE_BYTES somehow
relates to the exact CPU you're running on.  It doesn't.

What it relates to is the *maximum* cache line size of *any* CPU that
we will run on.

Take a moment to think about why given the above.  If you're booting on
a 32 byte cache line CPU, will a structure aligned for a 64 byte cache
line also be aligned for a 32-byte cache line?  How about the reverse
case?

Now, there are various ARMv7 Cortex CPUs that have 64 byte cache lines
out there in the wild - Cortex A8 and Cortex A15 are two examples, both
of them are ARMv7 CPUs.

As we can't distinguish at run time between these, and we are working for
a single zImage kernel, we have to assume that ARMv7 means a 64 byte cache
line as far as the L1_CACHE_* constants are concerned.  Yes, we used to
set it for OMAP3 and some Samsung SoC too, but then others came along and
single zImage too - and that all makes trying to reduce it down to the
minimum rather pointless.

So, no, this is *not* a "serious configuring error" at all.  It is totally
intended to be this way.


From linux at arm.linux.org.uk  Sun Jul 14 09:13:21 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sun, 14 Jul 2013 14:13:21 +0100
Subject: Call for testing/opinions: Optimized memset/memcpy
In-Reply-To: <CAKv+Gu-fUNSZaNMgZekoCX2kOGEFDLKY1yFtKq1=yp9xQN3rOA@mail.gmail.com>
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713164840.GC28473@gallifrey> <loom.20130714T130546-799@post.gmane.org>
 <CAKv+Gu-fUNSZaNMgZekoCX2kOGEFDLKY1yFtKq1=yp9xQN3rOA@mail.gmail.com>
Message-ID: <20130714131320.GS24642@n2100.arm.linux.org.uk>

On Sun, Jul 14, 2013 at 01:37:44PM +0200, Ard Biesheuvel wrote:
> On 14 July 2013 13:19, Harm Hanemaaijer <fgenfb at yahoo.com> wrote:
> > Dr. David Alan Gilbert <gilbertd <at> treblig.org> writes:
> >>
> >> Maybe neon is worth a try these days (although be careful of platforms
> >> like Tegra 2 that doens't have it); there was a recent patch that enabled
> >> use in the kernel (I think for some RAID use). The downside is it's
> >> supposed to be quite power hungry.
> >>
> >
> > As it turns out, NEON isn't too hard to implement. I have added NEON support
> > to copy_page, memset, memzero, and memcpy (both for the aligned and unaligned
> > case) in my userspace testing environment. It gives a nice boost (ranging
> > from 10% for copy_page to >30% for unaligned memcpy on a Cortex A8), which
> > can potentially be more on other cores. Although I have not tested a live
> > kernel yet, it looks like NEON can be used fairly transparently #ifdefed on
> > the CONFIG_NEON kernel definition as long as only the lower end of the
> > NEON/vfp register file is clobbered (although this needs verification).
> >
> 
> You will clobber the userland NEON contents of the register file if
> you don't preserve them properly. Also, kernel preemption (if enabled)
> may put your task to sleep at any time, and the context switching
> machinery is totally oblivious of NEON being used in the kernel, so
> the kernel side will get corrupted as well in this case.

The other issue is - not every ARMv7 core has Neon, so this is going
to have to be something that is selected at runtime - which means
indirecting every memcpy/memset through a function pointer.

The final point is, don't forget that gcc will generate implicit calls
to memset/memcpy, and neon won't be available early in the kernel boot,
so you can't optimize those function pointers away.


From pebolle at tiscali.nl  Sun Jul 14 09:18:16 2013
From: pebolle at tiscali.nl (Paul Bolle)
Date: Sun, 14 Jul 2013 15:18:16 +0200
Subject: [PATCH] ARM: EXYNOS: remove references to non-DT SoCs
In-Reply-To: <20130714124538.GA11538@sirena.org.uk>
References: <1373804812.1370.23.camel@x61.thuisdomein>
 <20130714124538.GA11538@sirena.org.uk>
Message-ID: <1373807896.1370.43.camel@x61.thuisdomein>

On Sun, 2013-07-14 at 13:45 +0100, Mark Brown wrote:
> Look at the code you are editing here:
> 
> > -       depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310 || MACH_SMDKC210)
> > +       depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110)
> 
> Simply removing the dependencies is not going to give the clearly
> intended effect here.  The dependency on the DT only machine needs to be
> replaced with something, not just deleted, otherwise the driver can't be
> enabled in Kconfig.

I interpreted commit 383ffda2fa as a commit that just removed a lot of
stuff: see its commit explanation and its diffstat (it adds one line and
deletes over 900 lines). Moreover, after that commit the references to
MACH_SMDKV310 and MACH_SMDKC210 both are nops. Deleting them can't
possibly change anything.

But, anyhow, what would be the symbols to use here?

> Also let me again remind you to submit patches with subject lines that
> are appropriate for the subsystem you're updating.  I very nearly
> deleted this unread since it looks like a patch for arch/arm with no
> relationship with audio but in fact it doesn't touch arch/arm at all.

I do try to use subject lines that are used in the sections I touch. I
seem to remember that you asked me _once_, I think one or two years ago,
to adjust to the system used for SoC. Since then you've received a
number of patches from me that, as far as I can remember, always used
that system.

Besides, this patch was intended as a follow up to commit 383ffda2fa, to
clean up two references it apparently forgot to remove, and therefor
basically copied the subject line used in that commit.


Paul Bolle



From fgenfb at yahoo.com  Sun Jul 14 09:33:14 2013
From: fgenfb at yahoo.com (Harm Hanemaaijer)
Date: Sun, 14 Jul 2013 13:33:14 +0000 (UTC)
Subject: Call for testing/opinions: Optimized memset/memcpy
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713164840.GC28473@gallifrey> <loom.20130714T130546-799@post.gmane.org>
 <CAKv+Gu-fUNSZaNMgZekoCX2kOGEFDLKY1yFtKq1=yp9xQN3rOA@mail.gmail.com>
Message-ID: <loom.20130714T152342-120@post.gmane.org>

Ard Biesheuvel <ard.biesheuvel <at> linaro.org> writes:

> 
> You will clobber the userland NEON contents of the register file if
> you don't preserve them properly. Also, kernel preemption (if enabled)
> may put your task to sleep at any time, and the context switching
> machinery is totally oblivious of NEON being used in the kernel, so
> the kernel side will get corrupted as well in this case.
> 
> I have a patch series pending (i.e., accepted but not pulled yet by
> Russell) which addresses these issues.
> 

That was what I was afraid of concerning NEON. It must be tricky to solve
without sacrificing performance, since saving/restoring the entire NEON
register file would obviously seriously impact context switch performance.
For memcpy-like applications, basically only four dword registers are
required (d0-d3) which could possibly be optimized for.




From fgenfb at yahoo.com  Sun Jul 14 09:59:57 2013
From: fgenfb at yahoo.com (Harm Hanemaaijer)
Date: Sun, 14 Jul 2013 13:59:57 +0000 (UTC)
Subject: Call for testing/opinions: Optimized memset/memcpy
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713172445.GL32054@1wt.eu> <loom.20130713T232124-511@post.gmane.org>
 <20130714061354.GS32054@1wt.eu> <loom.20130714T124137-382@post.gmane.org>
 <20130714130949.GR24642@n2100.arm.linux.org.uk>
Message-ID: <loom.20130714T154731-132@post.gmane.org>

Russell King - ARM Linux <linux <at> arm.linux.org.uk> writes:

> 
> You're making wrong assumptions about what L1_CACHE_BYTES is.

Thanks for the clarification. I have been focused too much on the concept
of a kernel image customized for a single device.

I can see how having to support multiple platforms with a single kernel
image makes things more difficult, especially when trying to optimize for
something. I will have to think about how to manage this when trying to
optimize memcpy-related functions.




From ard.biesheuvel at linaro.org  Sun Jul 14 10:09:20 2013
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Sun, 14 Jul 2013 16:09:20 +0200
Subject: Call for testing/opinions: Optimized memset/memcpy
In-Reply-To: <loom.20130714T152342-120@post.gmane.org>
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713164840.GC28473@gallifrey>
 <loom.20130714T130546-799@post.gmane.org>
 <CAKv+Gu-fUNSZaNMgZekoCX2kOGEFDLKY1yFtKq1=yp9xQN3rOA@mail.gmail.com>
 <loom.20130714T152342-120@post.gmane.org>
Message-ID: <CAKv+Gu8JcQUH6d1mWh+sGcMXU6rPW7yk8P16PgqnF1Zdfn3OkA@mail.gmail.com>

On 14 July 2013 15:33, Harm Hanemaaijer <fgenfb at yahoo.com> wrote:
> Ard Biesheuvel <ard.biesheuvel <at> linaro.org> writes:
>
>>
>> You will clobber the userland NEON contents of the register file if
>> you don't preserve them properly. Also, kernel preemption (if enabled)
>> may put your task to sleep at any time, and the context switching
>> machinery is totally oblivious of NEON being used in the kernel, so
>> the kernel side will get corrupted as well in this case.
>>
>> I have a patch series pending (i.e., accepted but not pulled yet by
>> Russell) which addresses these issues.
>>
>
> That was what I was afraid of concerning NEON. It must be tricky to solve
> without sacrificing performance, since saving/restoring the entire NEON
> register file would obviously seriously impact context switch performance.
> For memcpy-like applications, basically only four dword registers are
> required (d0-d3) which could possibly be optimized for.
>

Well, the whole lazy preserve/restore mechanism is based on the
premise that preserve/restore is only required when multiple users are
contending for the NEON (or in the SMP case, when a task gets migrated
to another CPU). As we will not be allowing NEON in interrupt context
nor in a preemptible section, the burden of the more costly context
switches should not grow disproportionately, even if tasks may be
contending for the NEON with themselves in a way (userland vs kernel).
However, it also means that a NEON based memcpy() is going to be
problematic, not only for the reasons pointed out by Russell, also
because you will need a fallback to use from interrupt context.

Perhaps for sufficiently large sizes, it makes sense to take the hit
of testing whether NEON is allowable at that particular moment, and
doing the preserve in that case. In the end, the numbers should speak
for themselves: if you manage a considerable speedup in a real-world
case, and no deterioration in others, people are usually quite
receptive.

-- 
Ard.


From santosh.shilimkar at ti.com  Sun Jul 14 10:27:38 2013
From: santosh.shilimkar at ti.com (Shilimkar, Santosh)
Date: Sun, 14 Jul 2013 14:27:38 +0000
Subject: [PATCH] ARM: keystone: drop "select HAVE_SCHED_CLOCK"
In-Reply-To: <1373798285.1370.2.camel@x61.thuisdomein>
References: <1373798285.1370.2.camel@x61.thuisdomein>
Message-ID: <448912EABC71F84BBCADFD3C67C4BE52826E9F@DBDE04.ent.ti.com>

Sorry for top posting. Thanks for the patch. I will pick this up.

Regards,
Santosh
________________________________________
From: Paul Bolle [pebolle at tiscali.nl]
Sent: Sunday, July 14, 2013 6:38 AM
To: Russell King
Cc: Olof Johansson; Shilimkar, Santosh; linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org
Subject: [PATCH] ARM: keystone: drop "select HAVE_SCHED_CLOCK"

The Kconfig symbol HAVE_SCHED_CLOCK got removed in v3.4,
with commit 6905a65879b5 ("ARM: Make the sched_clock
framework mandatory"). But a select statement for it popped up again
through commit 828989ad87af ("ARM: keystone: Add minimal TI Keystone
platform support"). Drop that statement, as it is useless.

Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
---
Not tested.

 arch/arm/mach-keystone/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index 51a50e9..366d1a3 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -7,7 +7,6 @@ config ARCH_KEYSTONE
        select HAVE_SMP
        select CLKSRC_MMIO
        select GENERIC_CLOCKEVENTS
-       select HAVE_SCHED_CLOCK
        select ARCH_WANT_OPTIONAL_GPIOLIB
        select ARM_ERRATA_798181 if SMP
        help
--
1.8.1.4



From linux at arm.linux.org.uk  Sun Jul 14 10:32:07 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sun, 14 Jul 2013 15:32:07 +0100
Subject: Call for testing/opinions: Optimized memset/memcpy
In-Reply-To: <CAKv+Gu8JcQUH6d1mWh+sGcMXU6rPW7yk8P16PgqnF1Zdfn3OkA@mail.gmail.com>
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713164840.GC28473@gallifrey> <loom.20130714T130546-799@post.gmane.org>
 <CAKv+Gu-fUNSZaNMgZekoCX2kOGEFDLKY1yFtKq1=yp9xQN3rOA@mail.gmail.com>
 <loom.20130714T152342-120@post.gmane.org>
 <CAKv+Gu8JcQUH6d1mWh+sGcMXU6rPW7yk8P16PgqnF1Zdfn3OkA@mail.gmail.com>
Message-ID: <20130714143207.GT24642@n2100.arm.linux.org.uk>

On Sun, Jul 14, 2013 at 04:09:20PM +0200, Ard Biesheuvel wrote:
> Well, the whole lazy preserve/restore mechanism is based on the
> premise that preserve/restore is only required when multiple users are
> contending for the NEON (or in the SMP case, when a task gets migrated
> to another CPU). As we will not be allowing NEON in interrupt context
> nor in a preemptible section, the burden of the more costly context
> switches should not grow disproportionately, even if tasks may be
> contending for the NEON with themselves in a way (userland vs kernel).
> However, it also means that a NEON based memcpy() is going to be
> problematic, not only for the reasons pointed out by Russell, also
> because you will need a fallback to use from interrupt context.

There's another reason too: it would make memcpy() et.al., non-preemptible
also - that's probably fine for very small copies, but not for larger ones.
The acceptability threshold depends on how RT orientated you are and what
your application demands in terms of accuracy from the RT implementation.


From siarhei.siamashka at gmail.com  Sun Jul 14 11:21:33 2013
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Sun, 14 Jul 2013 18:21:33 +0300
Subject: Call for testing/opinions: Optimized memset/memcpy
In-Reply-To: <loom.20130714T124137-382@post.gmane.org>
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713172445.GL32054@1wt.eu>
 <loom.20130713T232124-511@post.gmane.org>
 <20130714061354.GS32054@1wt.eu>
 <loom.20130714T124137-382@post.gmane.org>
Message-ID: <20130714182133.7971180d@i7>

On Sun, 14 Jul 2013 11:00:50 +0000 (UTC)
Harm Hanemaaijer <fgenfb at yahoo.com> wrote:

> Willy Tarreau <w <at> 1wt.eu> writes:
> 
> > 
> > Please find the results attached. It seems that memcpy improved by 0.8%
> > though that's not even certain.
> > 
> 
> What is interesting is that
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Caccifbd.html,
> and several other sources (such as other
> optimized memcpy implementations) document the cache line size of the Cortex
> A9 as 32 bytes, which is an anomaly in the armv7 family.

Yes, the cache line size is 32 bytes in Cortex-A9. However in order to
mitigate poor memory memory bandwidth utilization, the L2 cache
controller implements 'double linefill' feature:

    http://infocenter.arm.com/help/topic/com.arm.doc.ddi0246h/CHDHIECI.html

But 'double linefill' only first appeared in r3p0 revision of L2C-310
L2 cache controller (also known as PL310) and was a bit buggy in the
revisions older than r3p2 according to the errata list:

    http://infocenter.arm.com/help/topic/com.arm.doc.uan0013b/index.html

Which only makes double linefill usable in modern Cortex-A9 based SoCs
such as Exynos4412, but unfortunately not in the older Cortex-A9 based
systems.

When double linefill is enabled, two cache lines are allocated at once
in L2, so for the memcpy alike workloads it looks somewhat similar to
real 64 byte cache line size. Welcome to the diverse world of ARM
hardware :)

-- 
Best regards,
Siarhei Siamashka


From u.kleine-koenig at pengutronix.de  Sun Jul 14 14:33:47 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Sun, 14 Jul 2013 20:33:47 +0200
Subject: [PATCH 1/1] ARM: imx: clk-pllv3: move the timeout just before
 the comparison
In-Reply-To: <1373763528-20792-1-git-send-email-peter.chen@freescale.com>
References: <1373763528-20792-1-git-send-email-peter.chen@freescale.com>
Message-ID: <20130714183347.GJ12139@pengutronix.de>

On Sun, Jul 14, 2013 at 08:58:48AM +0800, Peter Chen wrote:
> It can let the timeout value be more precise.
> 
> Suggested-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Whoever applies this patch, can you make the ? an ? (or at least "oe")?

Peter, does this fix anything for you? Would be nice to mention that in
the commit log.

Best regards
Uwe

> Signed-off-by: Peter Chen <peter.chen at freescale.com>
> ---
>  arch/arm/mach-imx/clk-pllv3.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/clk-pllv3.c b/arch/arm/mach-imx/clk-pllv3.c
> index a9fad5f..e2c026f 100644
> --- a/arch/arm/mach-imx/clk-pllv3.c
> +++ b/arch/arm/mach-imx/clk-pllv3.c
> @@ -48,7 +48,7 @@ struct clk_pllv3 {
>  static int clk_pllv3_prepare(struct clk_hw *hw)
>  {
>  	struct clk_pllv3 *pll = to_clk_pllv3(hw);
> -	unsigned long timeout = jiffies + msecs_to_jiffies(10);
> +	unsigned long timeout;
>  	u32 val;
>  
>  	val = readl_relaxed(pll->base);
> @@ -59,6 +59,7 @@ static int clk_pllv3_prepare(struct clk_hw *hw)
>  		val &= ~BM_PLL_POWER;
>  	writel_relaxed(val, pll->base);
>  
> +	timeout = jiffies + msecs_to_jiffies(10);
>  	/* Wait for PLL to lock */
>  	while (!(readl_relaxed(pll->base) & BM_PLL_LOCK))
>  		if (time_after(jiffies, timeout))
> -- 
> 1.7.0.4
> 
> 
> 

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From arnd at arndb.de  Sun Jul 14 15:29:43 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sun, 14 Jul 2013 21:29:43 +0200
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <175CCF5F49938B4D99B2E3EF7F558EBE3DBC97FDFA@SC-VEXCH4.marvell.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <20130710214922.GQ11908@titan.lakedaemon.net>
 <175CCF5F49938B4D99B2E3EF7F558EBE3DBC97FDFA@SC-VEXCH4.marvell.com>
Message-ID: <201307142129.43271.arnd@arndb.de>

On Thursday 11 July 2013, Neil Zhang wrote:
> > > > To do this properly, the drivers are going to have to be compatible
> > > > with the old and the new names, and the binding docs updated to
> > > > reflect the legacy name and the preferred name.
> > >
> > > Properly would be as above. You can stop using stock tickers for new
> > > company names, but anything that has been defined in a device tree
> > > before has to stay that way, and all the manufacturer prefixes to
> > > device names should be the same. What you're proposing is purely
> > > driver bloat and increasing the size of kernel.
> > 
> > *I'm* not proposing to change the name, Neil is.  I'm proposing that
> > iff they chose to do that, don't break sh*t along the way.
> > 
> 
> What's your opinion?

We discussed the topic of fixing bad bindings vs. keeping backwards
compatibility during last week's Linaro Connect.

The main outcome was that we need to have a better review for new bindings
getting merged to avoid this situation in the future, but the general
consensus seems that bindings that are already in use but were never
reviewed properly (which should have caught this) should be changed.
We will likely establish an annotation in the binding soon to mark those
that can not be changed as opposed to those that are not considered stable
yet.

	Arnd


From arnd at arndb.de  Sun Jul 14 15:58:43 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sun, 14 Jul 2013 21:58:43 +0200
Subject: [PATCH v2] rtc: Add MOXA ART RTC driver
In-Reply-To: <1373550711-18828-1-git-send-email-jonas.jensen@gmail.com>
References: <1373464848-28146-1-git-send-email-jonas.jensen@gmail.com>
 <1373550711-18828-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <201307142158.44027.arnd@arndb.de>

On Thursday 11 July 2013, Jonas Jensen wrote:
> Add RTC driver for MOXA ART SoCs.
> +
> +#define GPIO_EM1240_OUTPUT			1
> +#define GPIO_EM1240_INPUT			0
> +
> +#define GPIO_RTC_SCLK				(5)
> +#define GPIO_RTC_DATA				(6)
> +#define GPIO_RTC_RESET				(7)

Since this is a DT-only platform, you should not really have hardcoded GPIO
numbers.

> +	devm_gpio_request(&pdev->dev, GPIO_RTC_DATA, "rtc_data");
> +	devm_gpio_request(&pdev->dev, GPIO_RTC_SCLK, "rtc_sclk");
> +	devm_gpio_request(&pdev->dev, GPIO_RTC_RESET, "rtc_reset");

Instead, you should use of_get_named_gpio() here, and add a binding document
that describes the names.

	Arnd


From will.deacon at arm.com  Sun Jul 14 17:53:25 2013
From: will.deacon at arm.com (Will Deacon)
Date: Sun, 14 Jul 2013 22:53:25 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <51DFEF75.8080600@codethink.co.uk>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate> <51DFEF75.8080600@codethink.co.uk>
Message-ID: <20130714215325.GB7382@mudshark.cambridge.arm.com>

On Fri, Jul 12, 2013 at 12:58:45PM +0100, Ben Dooks wrote:
> On 12/07/13 12:47, Thomas Petazzoni wrote:
> > Dear Vijay Kilari,
> >
> > On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
> >
> >>> Ben Dooks has a separate branch on top of this base branch for
> >>> big-endian support, that adds atags compat code to convert the ATAGs
> >>> data from LE to BE. See the baserock/311/be/atags branch in
> >>> git://git.baserock.org/delta/linux. Or
> >>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
> >>
> >>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
> >> It hangs at very early stage of boot
> >
> > Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
> > of the TODO-list. I think Ben said he would probably not have much time
> > to work on this. I might be able to spare some time on this, so just
> > let me know if I should start working on this. If I remember correctly,
> > it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
> >
> > Will, is getting Thumb2 working a requirement to get the BE support
> > merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
> 
> I would like to sort out getting this code merged as it seems to have
> been tested by several people now outside Codethink.
> 
> I could try doing the THUMB2 support, but I do not have a lot of
> experience with building THUMB2 kernels.

I think we should try and get Thumb-2 supported before merging this as there
isn't any real reason why the instruction set should cause endianness
issues. We're also only almost at -rc1, so there's still time to fix this
properly for 3.12 instead of adding a fake Kconfig dependency.

As for building a Thumb-2 kernel; just enable the option in menuconfig and
you're done. The compiler should "do the right thing".

Will


From aaro.koskinen at iki.fi  Sun Jul 14 18:28:19 2013
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Mon, 15 Jul 2013 01:28:19 +0300
Subject: [PATCH v2] N900: add device tree
In-Reply-To: <20130713121709.GC16473@amd.pavel.ucw.cz>
References: <20130613161418.GJ8164@atomide.com>
 <20130613230808.GA14876@amd.pavel.ucw.cz>
 <20130614055629.GM8164@atomide.com>
 <20130614212816.GA31768@atrey.karlin.mff.cuni.cz>
 <20130617111031.GQ20992@atomide.com>
 <20130701211753.GC15318@amd.pavel.ucw.cz>
 <20130704171939.GA27374@blackmetal.musicnaut.iki.fi>
 <20130704202145.GB10752@amd.pavel.ucw.cz>
 <20130704203256.GB27374@blackmetal.musicnaut.iki.fi>
 <20130713121709.GC16473@amd.pavel.ucw.cz>
Message-ID: <20130714222819.GB3296@blackmetal.musicnaut.iki.fi>

Hi,

On Sat, Jul 13, 2013 at 02:17:09PM +0200, Pavel Machek wrote:
> 
> This adds device tree with neccessary support to boot with functional
> video (on both emulator and real N900 device).
> 
> Signed-off-by: Pavel Machek <pavel at ucw.cz>

You can also add:

Signed-off-by: Aaro Koskinen <aaro.koskinen at iki.fi>

Thanks,

A.

> 
> ---
> 
> From v1: Aaro wants just GPLv2, so I did that. I re-enabled parts that
> can be enabled on 3.10, and tested it on that kernel.
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f0895c5..1950aed 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -141,6 +141,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
>  	omap3-devkit8000.dtb \
>  	omap3-beagle-xm.dtb \
>  	omap3-evm.dtb \
> +	omap3-n900.dtb \
>  	omap3-tobi.dtb \
>  	omap3-igep0020.dtb \
>  	omap3-igep0030.dtb \
> diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> new file mode 100644
> index 0000000..fb461bf
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -0,0 +1,92 @@
> +/*
> + * Copyright (C) 2013 Pavel Machek <pavel at ucw.cz>
> + * Copyright 2013 Aaro Koskinen <aaro.koskinen at iki.fi>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +
> +/include/ "omap34xx.dtsi"
> +
> +/ {
> +	model = "Nokia N900";
> +	compatible = "nokia,omap3-n900", "ti,omap3";
> +
> +	cpus {
> +		cpu at 0 {
> +			cpu0-supply = <&vcc>;
> +		};
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x80000000 0x10000000>; /* 256 MB */
> +	};
> +
> +};
> +
> +&i2c1 {
> +	clock-frequency = <2200000>;
> +
> +	twl: twl at 48 {
> +		reg = <0x48>;
> +		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> +		interrupt-parent = <&intc>;
> +	};
> +};
> +
> +/include/ "twl4030.dtsi"
> +
> +&twl_gpio {
> +	ti,pullups	= <0x0>;
> +	ti,pulldowns	= <0x03ff3f>; /* BIT(0..5) | BIT(8..17) */
> +};
> +
> +&i2c2 {
> +	clock-frequency = <400000>;
> +};
> +
> +&i2c3 {
> +	clock-frequency = <100000>;
> +};
> +
> +&mmc1 {
> +	status = "disabled";
> +};
> +
> +&mmc2 {
> +	status = "disabled";
> +};
> +
> +&mmc3 {
> +	status = "disabled";
> +};
> +
> +&mcspi1 {
> +	// For some reason, touchscreen is neccessary for screen to work at 
> +	// all on real hw. It works well without it on emulator.
> +	//
> +	// Also... order in the device tree actually matters here.
> +	tsc2005 at 0 {
> +		compatible = "tsc2005";
> +		spi-max-frequency = <6000000>;
> +		reg = <0>;
> +	};
> +	mipid at 2 {
> +		compatible = "acx565akm";
> +		spi-max-frequency = <6000000>;
> +		reg = <2>;
> +		// turbo_mode = 0,
> +		// cs_per_word = 0
> +	};
> +};
> +
> +&usb_otg_hs {
> +	interface-type = <0>;
> +	usb-phy = <&usb2_phy>;
> +	mode = <2>;
> +	power = <50>;
> +};
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From shawn.guo at linaro.org  Sun Jul 14 21:43:41 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 15 Jul 2013 09:43:41 +0800
Subject: [PATCH] ARM: dts: imx25: Make lcdc compatible to imx27/imx21 fb
In-Reply-To: <51DFCFB8.5050303@arcor.de>
References: <1373614495-21717-1-git-send-email-weisserm@arcor.de>
 <20130712084516.GI25501@S2101-09.ap.freescale.net>
 <51DFCFB8.5050303@arcor.de>
Message-ID: <20130715014339.GB2730@S2101-09.ap.freescale.net>

On Fri, Jul 12, 2013 at 11:43:20AM +0200, Matthias Wei?er wrote:
> Should I send a v2?

I just fixed it up and applied.

Shawn



From peter.chen at freescale.com  Sun Jul 14 21:47:18 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Mon, 15 Jul 2013 09:47:18 +0800
Subject: [PATCH 1/1] ARM: imx: clk-pllv3: move the timeout just before
 the comparison
In-Reply-To: <20130714183347.GJ12139@pengutronix.de>
References: <1373763528-20792-1-git-send-email-peter.chen@freescale.com>
 <20130714183347.GJ12139@pengutronix.de>
Message-ID: <20130715014717.GA23444@nchen-desktop>

On Sun, Jul 14, 2013 at 08:33:47PM +0200, Uwe Kleine-K?nig wrote:
> On Sun, Jul 14, 2013 at 08:58:48AM +0800, Peter Chen wrote:
> > It can let the timeout value be more precise.
> > 
> > Suggested-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> Whoever applies this patch, can you make the ? an ? (or at least "oe")?

Oh, sorry.

> 
> Peter, does this fix anything for you? Would be nice to mention that in
> the commit log.

The root cause of this PLL lock timeout problem is:

http://marc.info/?l=linux-arm-kernel&m=137109340222931&w=2

If causes the jiffies is not precise sometimes. This commit is just an
improvement.

> > Signed-off-by: Peter Chen <peter.chen at freescale.com>
> > ---
> >  arch/arm/mach-imx/clk-pllv3.c |    3 ++-
> >  1 files changed, 2 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/arm/mach-imx/clk-pllv3.c b/arch/arm/mach-imx/clk-pllv3.c
> > index a9fad5f..e2c026f 100644
> > --- a/arch/arm/mach-imx/clk-pllv3.c
> > +++ b/arch/arm/mach-imx/clk-pllv3.c
> > @@ -48,7 +48,7 @@ struct clk_pllv3 {
> >  static int clk_pllv3_prepare(struct clk_hw *hw)
> >  {
> >  	struct clk_pllv3 *pll = to_clk_pllv3(hw);
> > -	unsigned long timeout = jiffies + msecs_to_jiffies(10);
> > +	unsigned long timeout;
> >  	u32 val;
> >  
> >  	val = readl_relaxed(pll->base);
> > @@ -59,6 +59,7 @@ static int clk_pllv3_prepare(struct clk_hw *hw)
> >  		val &= ~BM_PLL_POWER;
> >  	writel_relaxed(val, pll->base);
> >  
> > +	timeout = jiffies + msecs_to_jiffies(10);
> >  	/* Wait for PLL to lock */
> >  	while (!(readl_relaxed(pll->base) & BM_PLL_LOCK))
> >  		if (time_after(jiffies, timeout))
> > -- 
> > 1.7.0.4
> > 
> > 
> > 
> 
> -- 
> Pengutronix e.K.                           | Uwe Kleine-K?nig            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> 

-- 

Best Regards,
Peter Chen



From festevam at gmail.com  Sun Jul 14 21:53:45 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Sun, 14 Jul 2013 22:53:45 -0300
Subject: [PATCH 1/1] ARM: imx: clk-pllv3: move the timeout just before the
 comparison
In-Reply-To: <20130715014717.GA23444@nchen-desktop>
References: <1373763528-20792-1-git-send-email-peter.chen@freescale.com>
 <20130714183347.GJ12139@pengutronix.de>
 <20130715014717.GA23444@nchen-desktop>
Message-ID: <CAOMZO5DyXFt8YbJN+Z7pE9z2CZE3G9FaFHrStx6xu-6noTpGPg@mail.gmail.com>

Hi Peter,

On Sun, Jul 14, 2013 at 10:47 PM, Peter Chen <peter.chen at freescale.com> wrote:

> The root cause of this PLL lock timeout problem is:
>
> http://marc.info/?l=linux-arm-kernel&m=137109340222931&w=2
>
> If causes the jiffies is not precise sometimes. This commit is just an
> improvement.

Your commit log does not explain what it improves, and why/how it
improves things.

Please provide a better description in the commit log.


From shawn.guo at linaro.org  Sun Jul 14 22:02:56 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 15 Jul 2013 10:02:56 +0800
Subject: [v6 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <1373622078-18723-4-git-send-email-Hong-Xing.Zhu@freescale.com>
References: <1373622078-18723-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373622078-18723-4-git-send-email-Hong-Xing.Zhu@freescale.com>
Message-ID: <20130715020254.GC2730@S2101-09.ap.freescale.net>

On Fri, Jul 12, 2013 at 05:41:18PM +0800, Richard Zhu wrote:
> From: Richard Zhu <r65037 at freescale.com>
> 
> imx6q contains one Synopsys AHCI SATA controller,
> But it can't share ahci_platform driver with other
> controllers.
> Because there are some misalignments of the generic
> AHCI controller.
> The bits definitions of the HBA registers, the Vendor
> Specific registers, the AHCI PHY clock and the AHCI
> signals adjustment window(GPR13 register).
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>  value is '0', should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the
>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>  should be configured regarding to the frequency of AHB
>  bus clock.
>  - Configurations of the AHCI PHY clock, and the signal
>  parameters of the GPR13
> 
> Setup its own ahci sata driver, contained the imx6q specific
> initialized codes, re-use the generic ahci_platform driver, and
> keep the generic ahci_platform driver clean as much as possible.
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  drivers/ata/Kconfig    |    9 ++
>  drivers/ata/Makefile   |    1 +
>  drivers/ata/sata_imx.c |  241 ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 251 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/ata/sata_imx.c
> 
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index a5a3ebc..275dc2c 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -97,6 +97,15 @@ config SATA_AHCI_PLATFORM
>  
>  	  If unsure, say N.
>  
> +config SATA_IMX
> +	tristate "Freescale i.MX AHCI SATA support"
> +	depends on SATA_AHCI_PLATFORM
> +	help
> +	  This option enables support for the Freescale i.MX SoC's
> +	  onboard AHCI SATA.
> +
> +	  If unsure, say N.
> +
>  config SATA_FSL
>  	tristate "Freescale 3.0Gbps SATA support"
>  	depends on FSL_SOC
> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
> index c04d0fd..04b1c6c 100644
> --- a/drivers/ata/Makefile
> +++ b/drivers/ata/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_SATA_INIC162X)	+= sata_inic162x.o
>  obj-$(CONFIG_SATA_SIL24)	+= sata_sil24.o
>  obj-$(CONFIG_SATA_DWC)		+= sata_dwc_460ex.o
>  obj-$(CONFIG_SATA_HIGHBANK)	+= sata_highbank.o libahci.o
> +obj-$(CONFIG_SATA_IMX)		+= sata_imx.o
>  
>  # SFF w/ custom DMA
>  obj-$(CONFIG_PDC_ADMA)		+= pdc_adma.o
> diff --git a/drivers/ata/sata_imx.c b/drivers/ata/sata_imx.c
> new file mode 100644
> index 0000000..fb13867
> --- /dev/null
> +++ b/drivers/ata/sata_imx.c
> @@ -0,0 +1,241 @@
> +/*
> + * Freescale IMX AHCI SATA platform driver
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * based on the AHCI SATA platform driver by Jeff Garzik and Anton Vorontsov
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/ahci_platform.h>
> +#include <linux/of_device.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
> +#include "ahci.h"
> +
> +enum {
> +	HOST_TIMER1MS = 0xe0, /* Timer 1-ms */
> +};
> +
> +struct imx_ahci_priv {
> +	struct platform_device *ahci_pdev;
> +	struct clk *sata_ref_clk;
> +	struct regmap *gpr;
> +};
> +
> +static int imx6q_sata_init(struct device *dev, void __iomem *mmio)
> +{
> +	int ret = 0;
> +	unsigned int reg_val;
> +	struct clk *ahb_clk;
> +	struct imx_ahci_priv *imxpriv = dev_get_drvdata(dev->parent);
> +
> +	imxpriv->gpr =
> +		syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +	if (IS_ERR(imxpriv->gpr)) {
> +		dev_err(dev, "failed to find fsl,imx6q-iomux-gpr regmap\n");
> +		return PTR_ERR(imxpriv->gpr);
> +	}
> +
> +	ret = clk_prepare_enable(imxpriv->sata_ref_clk);
> +	if (ret < 0) {
> +		dev_err(dev, "prepare-enable sata_ref clock err:%d\n", ret);
> +		return ret;
> +	}
> +
> +	/*
> +	 * set PHY Paremeters, two steps to configure the GPR13,
> +	 * one write for rest of parameters, mask of first write
> +	 * is 0x07fffffd, and the other one write for setting
> +	 * the mpll_clk_en.
> +	 */
> +	regmap_update_bits(imxpriv->gpr, 0x34, IMX6Q_GPR13_SATA_RX_EQ_VAL_MASK
> +			| IMX6Q_GPR13_SATA_RX_LOS_LVL_MASK
> +			| IMX6Q_GPR13_SATA_RX_DPLL_MODE_MASK
> +			| IMX6Q_GPR13_SATA_SPD_MODE_MASK
> +			| IMX6Q_GPR13_SATA_MPLL_SS_EN
> +			| IMX6Q_GPR13_SATA_TX_ATTEN_MASK
> +			| IMX6Q_GPR13_SATA_TX_BOOST_MASK
> +			| IMX6Q_GPR13_SATA_TX_LVL_MASK
> +			| IMX6Q_GPR13_SATA_TX_EDGE_RATE
> +			, IMX6Q_GPR13_SATA_RX_EQ_VAL_3_0_DB
> +			| IMX6Q_GPR13_SATA_RX_LOS_LVL_SATA2M
> +			| IMX6Q_GPR13_SATA_RX_DPLL_MODE_2P_4F
> +			| IMX6Q_GPR13_SATA_SPD_MODE_3P0G
> +			| IMX6Q_GPR13_SATA_MPLL_SS_EN
> +			| IMX6Q_GPR13_SATA_TX_ATTEN_9_16
> +			| IMX6Q_GPR13_SATA_TX_BOOST_3_33_DB
> +			| IMX6Q_GPR13_SATA_TX_LVL_1_025_V);
> +	regmap_update_bits(imxpriv->gpr, 0x34, IMX6Q_GPR13_SATA_MPLL_CLK_EN,
> +			IMX6Q_GPR13_SATA_MPLL_CLK_EN);
> +	usleep_range(100, 200);
> +
> +	/*
> +	 * Configure the HWINIT bits of the HOST_CAP and HOST_PORTS_IMPL,
> +	 * and IP vendor specific register HOST_TIMER1MS.
> +	 * Configure CAP_SSS (support stagered spin up).
> +	 * Implement the port0.
> +	 * Get the ahb clock rate, and configure the TIMER1MS register.
> +	 */
> +	reg_val = readl(mmio + HOST_CAP);
> +	if (!(reg_val & HOST_CAP_SSS)) {
> +		reg_val |= HOST_CAP_SSS;
> +		writel(reg_val, mmio + HOST_CAP);
> +	}
> +	reg_val = readl(mmio + HOST_PORTS_IMPL);
> +	if (!(reg_val & 0x1)) {
> +		reg_val |= 0x1;
> +		writel(reg_val, mmio + HOST_PORTS_IMPL);
> +	}
> +
> +	ahb_clk = devm_clk_get(dev, "ahb");

Can we move this devm_clk_get() call into .probe as well?

> +	if (IS_ERR(ahb_clk)) {
> +		dev_err(dev, "no ahb clock.\n");
> +		clk_disable_unprepare(imxpriv->sata_ref_clk);
> +		devm_clk_put(dev, imxpriv->sata_ref_clk);
> +		return PTR_ERR(ahb_clk);
> +	}
> +	reg_val = clk_get_rate(ahb_clk) / 1000;
> +	writel(reg_val, mmio + HOST_TIMER1MS);
> +	devm_clk_put(dev, ahb_clk);
> +
> +	return 0;
> +}
> +
> +static void imx6q_sata_exit(struct device *dev)
> +{
> +	struct imx_ahci_priv *imxpriv =  dev_get_drvdata(dev->parent);
> +
> +	regmap_update_bits(imxpriv->gpr, 0x34, IMX6Q_GPR13_SATA_MPLL_CLK_EN,
> +			!IMX6Q_GPR13_SATA_MPLL_CLK_EN);
> +	clk_disable_unprepare(imxpriv->sata_ref_clk);
> +}
> +
> +static struct ahci_platform_data imx6q_sata_pdata = {
> +	.init = imx6q_sata_init,
> +	.exit = imx6q_sata_exit,
> +};
> +
> +static const struct of_device_id imx_ahci_of_match[] = {
> +	{ .compatible = "fsl,imx6q-ahci", .data = &imx6q_sata_pdata},
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, imx_ahci_of_match);
> +
> +static int imx_ahci_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct resource *mem, *irq, res[2];
> +	const struct of_device_id *of_id;
> +	const struct ahci_platform_data *pdata = NULL;
> +	struct imx_ahci_priv *imxpriv;
> +	struct device *ahci_dev;
> +	struct platform_device *ahci_pdev;
> +	int ret;
> +
> +	imxpriv = devm_kzalloc(dev, sizeof(*imxpriv), GFP_KERNEL);
> +	if (!imxpriv) {
> +		dev_err(dev, "can't alloc ahci_host_priv\n");
> +		return -ENOMEM;
> +	}
> +
> +	ahci_pdev = platform_device_alloc("ahci", -1);
> +	if (!ahci_pdev)
> +		return -ENODEV;
> +
> +	ahci_dev = &ahci_pdev->dev;
> +	ahci_dev->parent = dev;
> +
> +	imxpriv->sata_ref_clk = devm_clk_get(dev, "sata_ref");
> +	if (IS_ERR(imxpriv->sata_ref_clk)) {
> +		dev_err(dev, "can't get sata_ref clock.\n");
> +		ret = PTR_ERR(imxpriv->sata_ref_clk);
> +		goto err_pdev_put;
> +	}
> +
> +	imxpriv->ahci_pdev = ahci_pdev;
> +	platform_set_drvdata(pdev, imxpriv);
> +
> +	of_id = of_match_device(imx_ahci_of_match, dev);
> +	if (of_id) {
> +		pdata = of_id->data;
> +	} else {
> +		ret = -EINVAL;
> +		goto err_out;
> +	}
> +
> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +	if (!mem || !irq) {
> +		dev_err(dev, "no mmio/irq resource\n");
> +		ret = -ENOMEM;
> +		goto err_out;
> +	}
> +
> +	res[0] = *mem;
> +	res[1] = *irq;
> +
> +	ahci_dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +	ahci_dev->dma_mask = &ahci_dev->coherent_dma_mask;
> +	ahci_dev->of_node = dev->of_node;
> +
> +	ret = platform_device_add_resources(ahci_pdev, res, 2);
> +	if (ret)
> +		goto err_out;
> +
> +	ret = platform_device_add_data(ahci_pdev, pdata, sizeof(*pdata));
> +	if (ret)
> +		goto err_out;
> +
> +	ret = platform_device_add(ahci_pdev);
> +	if (ret) {
> +err_out:
> +		platform_set_drvdata(pdev, NULL);

I do not think you need this.

> +		devm_clk_put(dev, imxpriv->sata_ref_clk);

The good thing about using devm_clk_get() above is you do not need to
explicitly call devm_clk_put() on either .remove or .probe failure.

> +err_pdev_put:
> +		platform_device_put(ahci_pdev);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int imx_ahci_remove(struct platform_device *pdev)
> +{
> +	struct imx_ahci_priv *imxpriv = platform_get_drvdata(pdev);
> +	struct platform_device *ahci_pdev = imxpriv->ahci_pdev;
> +
> +	platform_device_unregister(ahci_pdev);
> +	platform_set_drvdata(pdev, NULL);

Ditto, you do not need to do this.

Shawn

> +	return 0;
> +}
> +
> +static struct platform_driver imx_ahci_driver = {
> +	.probe = imx_ahci_probe,
> +	.remove = imx_ahci_remove,
> +	.driver = {
> +		.name = "sata-imx",
> +		.owner = THIS_MODULE,
> +		.of_match_table = imx_ahci_of_match,
> +	},
> +};
> +module_platform_driver(imx_ahci_driver);
> +
> +MODULE_DESCRIPTION("Freescale i.MX AHCI SATA platform driver");
> +MODULE_AUTHOR("Richard Zhu <Hong-Xing.Zhu at freescale.com>");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("sata:imx");
> -- 
> 1.7.5.4
> 



From shawn.guo at linaro.org  Sun Jul 14 22:11:06 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 15 Jul 2013 10:11:06 +0800
Subject: [PATCH] ARM: dts: imx6qdl/imx6sl: add the dma property for uart
In-Reply-To: <1373623329-18204-1-git-send-email-b32955@freescale.com>
References: <1373623329-18204-1-git-send-email-b32955@freescale.com>
Message-ID: <20130715021105.GD2730@S2101-09.ap.freescale.net>

On Fri, Jul 12, 2013 at 06:02:09PM +0800, Huang Shijie wrote:
> Add the dma property for all the uart.
> 
> Note: Add the dma property does not mean we enable the dma for this
> uart.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>

Applied.  But I change the patch to put dma-names after dmas.

Shawn

> ---
>  arch/arm/boot/dts/imx6q-arm2.dts |    2 --
>  arch/arm/boot/dts/imx6qdl.dtsi   |   10 ++++++++++
>  arch/arm/boot/dts/imx6sl.dtsi    |   10 ++++++++++
>  3 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6q-arm2.dts b/arch/arm/boot/dts/imx6q-arm2.dts
> index 9b17393..edf1bd9 100644
> --- a/arch/arm/boot/dts/imx6q-arm2.dts
> +++ b/arch/arm/boot/dts/imx6q-arm2.dts
> @@ -102,8 +102,6 @@
>  	pinctrl-0 = <&pinctrl_uart2_2>;
>  	fsl,dte-mode;
>  	fsl,uart-has-rtscts;
> -	dma-names = "rx", "tx";
> -	dmas = <&sdma 27 4 0>, <&sdma 28 4 0>;
>  	status = "okay";
>  };
>  
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index 72a28d6..34ffc2e 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -197,6 +197,8 @@
>  					interrupts = <0 26 0x04>;
>  					clocks = <&clks 160>, <&clks 161>;
>  					clock-names = "ipg", "per";
> +					dma-names = "rx", "tx";
> +					dmas = <&sdma 25 4 0>, <&sdma 26 4 0>;
>  					status = "disabled";
>  				};
>  
> @@ -1479,6 +1481,8 @@
>  				interrupts = <0 27 0x04>;
>  				clocks = <&clks 160>, <&clks 161>;
>  				clock-names = "ipg", "per";
> +				dma-names = "rx", "tx";
> +				dmas = <&sdma 27 4 0>, <&sdma 28 4 0>;
>  				status = "disabled";
>  			};
>  
> @@ -1488,6 +1492,8 @@
>  				interrupts = <0 28 0x04>;
>  				clocks = <&clks 160>, <&clks 161>;
>  				clock-names = "ipg", "per";
> +				dma-names = "rx", "tx";
> +				dmas = <&sdma 29 4 0>, <&sdma 30 4 0>;
>  				status = "disabled";
>  			};
>  
> @@ -1497,6 +1503,8 @@
>  				interrupts = <0 29 0x04>;
>  				clocks = <&clks 160>, <&clks 161>;
>  				clock-names = "ipg", "per";
> +				dma-names = "rx", "tx";
> +				dmas = <&sdma 31 4 0>, <&sdma 32 4 0>;
>  				status = "disabled";
>  			};
>  
> @@ -1506,6 +1514,8 @@
>  				interrupts = <0 30 0x04>;
>  				clocks = <&clks 160>, <&clks 161>;
>  				clock-names = "ipg", "per";
> +				dma-names = "rx", "tx";
> +				dmas = <&sdma 33 4 0>, <&sdma 34 4 0>;
>  				status = "disabled";
>  			};
>  		};
> diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
> index 0a297af..230ee86 100644
> --- a/arch/arm/boot/dts/imx6sl.dtsi
> +++ b/arch/arm/boot/dts/imx6sl.dtsi
> @@ -159,6 +159,8 @@
>  					clocks = <&clks IMX6SL_CLK_UART>,
>  						 <&clks IMX6SL_CLK_UART_SERIAL>;
>  					clock-names = "ipg", "per";
> +					dma-names = "rx", "tx";
> +					dmas = <&sdma 33 4 0>, <&sdma 34 4 0>;
>  					status = "disabled";
>  				};
>  
> @@ -170,6 +172,8 @@
>  					clocks = <&clks IMX6SL_CLK_UART>,
>  						 <&clks IMX6SL_CLK_UART_SERIAL>;
>  					clock-names = "ipg", "per";
> +					dma-names = "rx", "tx";
> +					dmas = <&sdma 25 4 0>, <&sdma 26 4 0>;
>  					status = "disabled";
>  				};
>  
> @@ -181,6 +185,8 @@
>  					clocks = <&clks IMX6SL_CLK_UART>,
>  						 <&clks IMX6SL_CLK_UART_SERIAL>;
>  					clock-names = "ipg", "per";
> +					dma-names = "rx", "tx";
> +					dmas = <&sdma 27 4 0>, <&sdma 28 4 0>;
>  					status = "disabled";
>  				};
>  
> @@ -219,6 +225,8 @@
>  					clocks = <&clks IMX6SL_CLK_UART>,
>  						 <&clks IMX6SL_CLK_UART_SERIAL>;
>  					clock-names = "ipg", "per";
> +					dma-names = "rx", "tx";
> +					dmas = <&sdma 29 4 0>, <&sdma 30 4 0>;
>  					status = "disabled";
>  				};
>  
> @@ -230,6 +238,8 @@
>  					clocks = <&clks IMX6SL_CLK_UART>,
>  						 <&clks IMX6SL_CLK_UART_SERIAL>;
>  					clock-names = "ipg", "per";
> +					dma-names = "rx", "tx";
> +					dmas = <&sdma 31 4 0>, <&sdma 32 4 0>;
>  					status = "disabled";
>  				};
>  			};
> -- 
> 1.7.1
> 
> 



From r65037 at freescale.com  Sun Jul 14 22:13:17 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Mon, 15 Jul 2013 02:13:17 +0000
Subject: [v6 1/3] ARM: dtsi: enable ahci sata on imx6q platforms
In-Reply-To: <51E069D0.7030204@cogentembedded.com>
References: <1373622078-18723-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373622078-18723-2-git-send-email-Hong-Xing.Zhu@freescale.com>
 <51E069D0.7030204@cogentembedded.com>
Message-ID: <0E83723C55F66F43A6041464FE31119D33BCFF@039-SN2MPN1-011.039d.mgd.msft.net>

Hi Sergei:
Thanks for your comments.


Best Regards
Richard Zhu


-----Original Message-----
From: Sergei Shtylyov [mailto:sergei.shtylyov at cogentembedded.com] 
Sent: Saturday, July 13, 2013 4:41 AM
To: Richard Zhu
Cc: shawn.guo at linaro.org; linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; tj at kernel.org; rob.herring at calxeda.com; s.hauer at pengutronix.de; linux-ide at vger.kernel.org; Zhu Richard-R65037
Subject: Re: [v6 1/3] ARM: dtsi: enable ahci sata on imx6q platforms

On 07/12/2013 01:41 PM, Richard Zhu wrote:

> From: Richard Zhu <r65037 at freescale.com>

> Only imx6q has the ahci sata controller, enable it on imx6q platforms.

> Signed-off-by: Richard Zhu <r65037 at freescale.com>
[...]

> diff --git a/arch/arm/boot/dts/imx6q.dtsi 
> b/arch/arm/boot/dts/imx6q.dtsi index e7dd2c4..93b65d9 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -424,6 +424,15 @@
>   			};
>   		};
>
> +		ahci: ahci at 02200000 {

    According to ePAPR [1] section 2.2.2, "the name of the node should be somewhat generic, reflecting the function of the device and not its precise programming model. If appropriate, the name should be one of the following choices:
[...]
- sata;
[...]"

[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
[Richard] Ok, ahci would be replaced by sata.

WBR, Sergei





From shawn.guo at linaro.org  Sun Jul 14 22:17:58 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 15 Jul 2013 10:17:58 +0800
Subject: [PATCH v3 1/4] ARM: dts: imx6qdl.dtsi: Add usdhc1 pin groups
In-Reply-To: <1373633373-3352-1-git-send-email-festevam@gmail.com>
References: <1373633373-3352-1-git-send-email-festevam@gmail.com>
Message-ID: <20130715021756.GE2730@S2101-09.ap.freescale.net>

On Fri, Jul 12, 2013 at 09:49:30AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
> Changes since v2:
> - None. Newly introduced in this series

All applied, thanks.



From shawn.guo at linaro.org  Sun Jul 14 22:20:13 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 15 Jul 2013 10:20:13 +0800
Subject: [PATCH v2] ARM: dts: i.MX51: Add WEIM node
In-Reply-To: <1373689857-24481-1-git-send-email-shc_work@mail.ru>
References: <1373689857-24481-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130715022012.GF2730@S2101-09.ap.freescale.net>

On Sat, Jul 13, 2013 at 08:30:57AM +0400, Alexander Shiyan wrote:
> This patch adds the missing (Wireless External Interface Module) WEIM
> devicetree node for i.MX51 CPUs.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>

Applied, thanks.



From shawn.guo at linaro.org  Sun Jul 14 22:21:30 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 15 Jul 2013 10:21:30 +0800
Subject: [PATCH] ARM: dts: imx27: Add core voltages
In-Reply-To: <1373690084-26760-1-git-send-email-shc_work@mail.ru>
References: <1373690084-26760-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130715022129.GG2730@S2101-09.ap.freescale.net>

On Sat, Jul 13, 2013 at 08:34:44AM +0400, Alexander Shiyan wrote:
> This patch adds core voltages for i.MX27 CPUs. Only 266 and 400 MHz modes
> is documented in the datasheet, so we add a 266 MHz frequency for conform this.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>

Applied, thanks.



From mcuos.com at gmail.com  Sun Jul 14 22:41:45 2013
From: mcuos.com at gmail.com (Wan ZongShun)
Date: Mon, 15 Jul 2013 10:41:45 +0800
Subject: [PATCH] video: nuc900fb: fix to pass correct device identity to
 free_irq()
In-Reply-To: <CAPgLHd_mMOOeMecVJbTQjiK+xJD+-8jvgH6oAFqTHK_uSpWOJw@mail.gmail.com>
References: <CAPgLHd_mMOOeMecVJbTQjiK+xJD+-8jvgH6oAFqTHK_uSpWOJw@mail.gmail.com>
Message-ID: <CAKT61h-yRxHk6uQqp7hXNQcnRv7WOUQsi21SnCANhSECCW4nYw@mail.gmail.com>

2013/7/12 Wei Yongjun <weiyj.lk at gmail.com>:
> From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
>
> free_irq() expects the same device identity that was passed to
> corresponding request_irq(), otherwise the IRQ is not freed.
>
> Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Sorry, repost.

Hi Yongjun,

(1)  ret = request_irq(irq, nuc900fb_irqhandler, 0,
              pdev->name, fbinfo);

(2)  static irqreturn_t nuc900fb_irqhandler(int irq, void *dev_id)
{
    struct nuc900fb_info *fbi = dev_id;
    void __iomem *regs = fbi->io;

>From (1) and (2), we should consider the wrong with passing 'fbinfo'
to 'nuc900fb_irqhandler', it should pass the 'fbi' instead as
following codes:

ret = request_irq(irq, nuc900fb_irqhandler, 0,
              pdev->name, fbi);

So if we fix this wrong,' free_irq(irq, fbi);' would be ok, right?

Thanks!
Vincent Wan.


> ---
>  drivers/video/nuc900fb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index 8c527e5..ebd5501 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -661,7 +661,7 @@ release_clock:
>         clk_disable(fbi->clk);
>         clk_put(fbi->clk);
>  release_irq:
> -       free_irq(irq, fbi);
> +       free_irq(irq, fbinfo);
>  release_regs:
>         iounmap(fbi->io);
>  release_mem_region:
> @@ -702,7 +702,7 @@ static int nuc900fb_remove(struct platform_device *pdev)
>         iounmap(fbi->io);
>
>         irq = platform_get_irq(pdev, 0);
> -       free_irq(irq, fbi);
> +       free_irq(irq, fbinfo);
>
>         release_resource(fbi->mem);
>         kfree(fbi->mem);
>



--
Wan ZongShun.
www.mcuos.com


From jgq516 at gmail.com  Sun Jul 14 22:50:50 2013
From: jgq516 at gmail.com (jgq516 at gmail.com)
Date: Mon, 15 Jul 2013 10:50:50 +0800
Subject: v3.10 - big endian core support
In-Reply-To: <51DFEFD9.2060509@codethink.co.uk>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate>
 <CALicx6sr=OXYAdSS-RXPCjSp4f_yLQyw6jJsQ2KyhgQ9fRtXag@mail.gmail.com>
 <51DFEFD9.2060509@codethink.co.uk>
Message-ID: <51E3638A.3080103@gmail.com>

On 07/12/2013 08:00 PM, Ben Dooks wrote:
> On 12/07/13 12:56, Vijay Kilari wrote:
>> On Fri, Jul 12, 2013 at 5:17 PM, Thomas Petazzoni
>> <thomas.petazzoni at free-electrons.com>  wrote:
>>> Dear Vijay Kilari,
>>>
>>> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>>>
>>>>> Ben Dooks has a separate branch on top of this base branch for
>>>>> big-endian support, that adds atags compat code to convert the ATAGs
>>>>> data from LE to BE. See the baserock/311/be/atags branch in
>>>>> git://git.baserock.org/delta/linux. Or
>>>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags. 
>>>>>
>>>>
>>>>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in 
>>>> BE mode
>>>> It hangs at very early stage of boot
>>>
>>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>>> of the TODO-list. I think Ben said he would probably not have much time
>>> to work on this. I might be able to spare some time on this, so just
>>> let me know if I should start working on this. If I remember correctly,
>>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>>
>> In fact, I tried with below changes.. still it fails
>>
>> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
>> index 2de1114..7df64c7 100644
>> --- a/arch/arm/kernel/head.S
>> +++ b/arch/arm/kernel/head.S
>> @@ -592,8 +592,14 @@ __fixup_a_pv_table:
>>          b       2f
>>   1:     add     r7, r3
>>          ldrh    ip, [r7, #2]
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +       rev     ip, ip
>> +#endif
>
> Do you need a rev16 here? I think you may have tried
> reversing the full 32 bits here instead of just the
> 16bits of instruction that was loaded.
>
Thanks Ben, 3.4 kernel booted ok with your suggested modifications.

gjiang at gjiang-desktop:~/work/be-a15$ git diff
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 0ad3af8..1a0196c 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -600,8 +600,10 @@ __fixup_a_pv_table:
         b       2f
  1:     add     r7, r3
         ldrh    ip, [r7, #2]
+       rev16   ip, ip @be8
         and     ip, 0x8f00
         orr     ip, r6  @ mask in offset bits 31-24
+       rev16   ip, ip @be8
         strh    ip, [r7, #2]
  2:     cmp     r4, r5
         ldrcc   r7, [r4], #4    @ use branch for delay slot

root at localhost:~# zcat /proc/config.gz |grep BE8
CONFIG_CPU_ENDIAN_BE8=y
CONFIG_CPU_BE8_BOOT_LE=y
root at localhost:~# zcat /proc/config.gz |grep THUMB
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
CONFIG_THUMB2_KERNEL=y
CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y


Regards,
Xiao
>>          and     ip, 0x8f00
>>          orr     ip, r6  @ mask in offset bits 31-24
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +       rev     ip, ip
>> +#endif
>>          strh    ip, [r7, #2]
>>   2:     cmp     r4, r5
>>          ldrcc   r7, [r4], #4    @ use branch for delay slot
>>
>>>
>>> Will, is getting Thumb2 working a requirement to get the BE support
>>> merged, or can we for now make the BE option depends on 
>>> !THUMB2_KERNEL ?
>>>
>>> Thanks!
>>>
>>> Thomas
>>> -- 
>>> Thomas Petazzoni, Free Electrons
>>> Kernel, drivers, real-time and embedded Linux
>>> development, consulting, training and support.
>>> http://free-electrons.com
>
>



From b32955 at freescale.com  Sun Jul 14 23:08:56 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 15 Jul 2013 11:08:56 +0800
Subject: [PATCH 3/3] ARM: dts: imx28-evk: add the rts/cts property for auart0
In-Reply-To: <1373857736-30108-1-git-send-email-b32955@freescale.com>
References: <1373857736-30108-1-git-send-email-b32955@freescale.com>
Message-ID: <1373857736-30108-3-git-send-email-b32955@freescale.com>

Add the rts/cts property for auart0 which means we enable the
DMA support for it.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx28-evk.dts |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index e035f46..15715d9 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -220,6 +220,7 @@
 			auart0: serial at 8006a000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&auart0_pins_a>;
+				fsl,uart-has-rtscts;
 				status = "okay";
 			};
 
-- 
1.7.1




From b32955 at freescale.com  Sun Jul 14 23:08:55 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 15 Jul 2013 11:08:55 +0800
Subject: [PATCH 2/3] serial: mxs: enable the DMA only when the rts/cts is
 enabled
In-Reply-To: <1373857736-30108-1-git-send-email-b32955@freescale.com>
References: <1373857736-30108-1-git-send-email-b32955@freescale.com>
Message-ID: <1373857736-30108-2-git-send-email-b32955@freescale.com>

The originall DMA support works only when the rts/cts is enabled.
But after several patchs, the DMA support has lost this limit.

This patch adds an optional property for the uart DT node
which indicates the uart has rts and cts.

This patch also adds the check for rts/cts before we enable the DMA
for the uart.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 .../bindings/tty/serial/fsl-mxs-auart.txt          |    3 +++
 drivers/tty/serial/mxs-auart.c                     |    5 ++++-
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
index 2c00ec6..ef82002 100644
--- a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
@@ -10,6 +10,9 @@ Required properties:
   Refer to dma.txt and fsl-mxs-dma.txt for details.
 - dma-names: "rx" for RX channel, "tx" for TX channel.
 
+Optional properties:
+- fsl,uart-has-rtscts : Indicate the uart has rts and cts
+
 Example:
 auart0: serial at 8006a000 {
 	compatible = "fsl,imx28-auart", "fsl,imx23-auart";
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 465ef0b..27532fd 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -134,6 +134,7 @@ enum mxs_auart_type {
 struct mxs_auart_port {
 	struct uart_port port;
 
+#define MXS_AUART_RTSCTS	1
 #define MXS_AUART_DMA_ENABLED	0x2
 #define MXS_AUART_DMA_TX_SYNC	2  /* bit 2 */
 #define MXS_AUART_DMA_RX_READY	3  /* bit 3 */
@@ -639,7 +640,7 @@ static void mxs_auart_settermios(struct uart_port *u,
 		 * we can only implement the DMA support for auart
 		 * in mx28.
 		 */
-		if (is_imx28_auart(s)) {
+		if (is_imx28_auart(s) && (s->flags & MXS_AUART_RTSCTS)) {
 			if (!mxs_auart_dma_init(s))
 				/* enable DMA tranfer */
 				ctrl2 |= AUART_CTRL2_TXDMAE | AUART_CTRL2_RXDMAE
@@ -1001,6 +1002,8 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
 	}
 	s->port.line = ret;
 
+	if (of_get_property(np, "fsl,uart-has-rtscts", NULL))
+		s->flags |= MXS_AUART_RTSCTS;
 	return 0;
 }
 
-- 
1.7.1




From b32955 at freescale.com  Sun Jul 14 23:08:54 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 15 Jul 2013 11:08:54 +0800
Subject: [PATCH 1/3] serial: mxs: remove the unused macro
Message-ID: <1373857736-30108-1-git-send-email-b32955@freescale.com>

The MXS_AUART_DMA_CONFIG is originally used to check if the DT node
is configured with the DMA property.

But now, the MXS_AUART_DMA_CONFIG is not used any more.
Just remove it.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 drivers/tty/serial/mxs-auart.c |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 4f5f161..465ef0b 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -134,7 +134,6 @@ enum mxs_auart_type {
 struct mxs_auart_port {
 	struct uart_port port;
 
-#define MXS_AUART_DMA_CONFIG	0x1
 #define MXS_AUART_DMA_ENABLED	0x2
 #define MXS_AUART_DMA_TX_SYNC	2  /* bit 2 */
 #define MXS_AUART_DMA_RX_READY	3  /* bit 3 */
@@ -640,7 +639,7 @@ static void mxs_auart_settermios(struct uart_port *u,
 		 * we can only implement the DMA support for auart
 		 * in mx28.
 		 */
-		if (is_imx28_auart(s) && (s->flags & MXS_AUART_DMA_CONFIG)) {
+		if (is_imx28_auart(s)) {
 			if (!mxs_auart_dma_init(s))
 				/* enable DMA tranfer */
 				ctrl2 |= AUART_CTRL2_TXDMAE | AUART_CTRL2_RXDMAE
@@ -1002,8 +1001,6 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
 	}
 	s->port.line = ret;
 
-	s->flags |= MXS_AUART_DMA_CONFIG;
-
 	return 0;
 }
 
-- 
1.7.1




From jason at lakedaemon.net  Mon Jul 15 00:39:41 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Jul 2013 00:39:41 -0400
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <CAOesGMi-J5OE998umtyt7awP3nW7iEHFdSiks0aOotsozLJ5pw@mail.gmail.com>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <1373352166-10064-2-git-send-email-zhangwm@marvell.com>
 <20130709124900.GG11908@titan.lakedaemon.net>
 <CAN1soZxiOh6TpbUOCUzK8gNwmvjbT3ihkUWaw8tuZ7md+NVA2g@mail.gmail.com>
 <20130710122433.GO11908@titan.lakedaemon.net>
 <CAN1soZzMvront1-jcBW6-uRKNs0OZNGnmiOjKGZSM28bViB_8A@mail.gmail.com>
 <20130710215041.GR11908@titan.lakedaemon.net>
 <CAOesGMi-J5OE998umtyt7awP3nW7iEHFdSiks0aOotsozLJ5pw@mail.gmail.com>
Message-ID: <20130715043922.GB9817@titan.lakedaemon.net>

On Sat, Jul 13, 2013 at 12:56:25PM -0700, Olof Johansson wrote:
> On Wed, Jul 10, 2013 at 2:50 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> > On Wed, Jul 10, 2013 at 10:08:50PM +0800, Haojian Zhuang wrote:
> >> On Wed, Jul 10, 2013 at 8:24 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> >> > On Wed, Jul 10, 2013 at 04:19:46PM +0800, Haojian Zhuang wrote:
> >> >> On Tue, Jul 9, 2013 at 8:49 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> >> >> > Neil,
> >> >> >
> >> >> > On Tue, Jul 09, 2013 at 02:42:44PM +0800, Neil Zhang wrote:
> >> >> >> The documented vendor prefix for Marvell is 'marvell', not 'mrvl', so
> >> >> >> let's change it.
> >> >> >>
> >> >> >> Signed-off-by: Neil Zhang <zhangwm at marvell.com>
> >> >> >> ---
> >> >> >>  .../devicetree/bindings/arm/mrvl/intc.txt          |   16 +++---
> >> >> >>  .../devicetree/bindings/arm/mrvl/mrvl.txt          |    6 +-
> >> >> >>  .../devicetree/bindings/arm/mrvl/timer.txt         |    4 +-
> >> >> >>  Documentation/devicetree/bindings/i2c/i2c-pxa.txt  |   14 +++---
> >> >> >>  .../devicetree/bindings/mmc/sdhci-pxa.txt          |    8 ++--
> >> >> >>  .../devicetree/bindings/rtc/sa1100-rtc.txt         |    4 +-
> >> >> >>  .../devicetree/bindings/serial/mrvl-serial.txt     |    2 +-
> >> >> >>  arch/arm/boot/dts/mmp2-brownstone.dts              |    2 +-
> >> >> >>  arch/arm/boot/dts/mmp2.dtsi                        |   56 ++++++++++----------
> >> >> >>  arch/arm/boot/dts/pxa168-aspenite.dts              |    2 +-
> >> >> >>  arch/arm/boot/dts/pxa168.dtsi                      |   24 ++++----
> >> >> >>  arch/arm/boot/dts/pxa2xx.dtsi                      |   16 +++---
> >> >> >>  arch/arm/boot/dts/pxa3xx.dtsi                      |    2 +-
> >> >> >>  arch/arm/boot/dts/pxa910-dkb.dts                   |    2 +-
> >> >> >>  arch/arm/boot/dts/pxa910.dtsi                      |   27 +++++-----
> >> >> >>  arch/arm/mach-mmp/irq.c                            |   16 +++---
> >> >> >>  arch/arm/mach-mmp/mmp-dt.c                         |   28 +++++-----
> >> >> >>  arch/arm/mach-mmp/mmp2-dt.c                        |   16 +++---
> >> >> >>  arch/arm/mach-mmp/time.c                           |    2 +-
> >> >> >>  arch/arm/mach-pxa/pxa-dt.c                         |   14 +++---
> >> >> >>  drivers/i2c/busses/i2c-pxa.c                       |   10 ++--
> >> >> >>  drivers/mmc/host/sdhci-pxav2.c                     |    4 +-
> >> >> >>  drivers/mmc/host/sdhci-pxav3.c                     |    4 +-
> >> >> >>  drivers/rtc/rtc-sa1100.c                           |    4 +-
> >> >> >>  drivers/tty/serial/pxa.c                           |    4 +-
> >> >> >>  25 files changed, 144 insertions(+), 143 deletions(-)
> >> >> >
> >> >> > I agree with the need to change, however, this has been in the binding
> >> >> > documentation since v3.5.  I wish we had caught this when we decided
> >> >> > against using stock ticker symbols (not all stock markets use
> >> >> > alphabetical abbreviated names, not all companies are listed on any
> >> >> > stock exchange).
> >> >> >
> >> >> > To do this properly, the drivers are going to have to be compatible with
> >> >> > the old and the new names, and the binding docs updated to reflect the
> >> >> > legacy name and the preferred name.
> >> >> >
> >> >>
> >> >> It's better to only use the new names.
> >> >
> >> > In the dts{i}, yes.  But we don't want to break systems in the field
> >> > with "mrvl,..." compatible strings.  Therefore, at least the drivers
> >> > need an extra compatible string to support "mrvl,...".
> >> >
> >> > If it had just been since v3.9, it'd be different/simpler.  However,
> >> > several vendors have opted to use kernels newer than v3.5, which makes
> >> > this scenario a real possibility.
> >> >
> >> > thx,
> >> >
> >> > Jason.
> >>
> >> Is there any vendor using DT for this Marvell chip? I think the answer is no.
> >
> > Well, Daniel Drake spoke up for OLPC.  Does that count?
> 
> There's stock ticker history for MRVL is available for at least as far
> back as 2001, so it's been around for a while. I would argue that the
> powerpc guys made a mistake by using the marvell prefix. Either way,
> they are not likely to add any new driver or code anytime soon for
> these platforms.

I think this boils down to which is more important, adhering to stock
tickers, or adhering to what's actually in the kernel before we (arm-soc
dt effort) got here?

I don't mind if the answer is either way, but back when we started
converting kirkwood to DT we had this discussion, and settled on
"marvell,..." because of powerpc/mv643xx_eth.  Now, it appears we're
flip-flopping.

> Given that we are using mrvl extensively already,

?!  Only -mmp and -pxa have used mrvl.  _everything_ for -kirkwood,
-dove, -orion5x, and -mvebu has used marvell.

$ git grep 'compatible\b.*\bmrvl,' -- drivers/ | wc -l
9
$ git grep 'compatible\b.*\bmarvell,' -- drivers/ | wc -l
54

This is from mvebu/for-next, and does _not_ include Sebastian's patches
going though DaveM's tree adding proper bindings to mv643xx_eth (for
v3.11) which also uses marvell.

> I'd say the way forward is to make the driver handle both compatible
> values,

Agreed, but only where necessary.

> but only use mrvl for new code and for all new device tree
> bindings/data on ARM.

If that's what you want, then no problem.  I just wish this had been
brought up sooner.  We're damn near finished converting -kirkwood to DT.

> It's a known issue that we are still in an "in-flux" state when it
> comes to bindings on ARM, where people have been free to change them
> as needed.

True, but we're doing a pretty good job of thinking them through
carefully and not messing with them once applied.  It's only going to
become more stringent (by necessity of popularity).

> At Linaro Connect last week, a group of us got together to
> discuss this and I hope that Grant (or maybe someone else) will be
> able to post those notes. We have a proposal on how to start moving
> away from _everything_ being unstable to a model where parts of the
> bindings can be locked down over time to a state where they won't
> change. But I won't preempt the proper proposal email by going into
> details here.

Documentation/devicetree/bindings/staging/ ?  :-P

thx,

Jason.


From r65037 at freescale.com  Mon Jul 15 01:21:08 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Mon, 15 Jul 2013 05:21:08 +0000
Subject: [v6 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <20130715020254.GC2730@S2101-09.ap.freescale.net>
References: <1373622078-18723-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373622078-18723-4-git-send-email-Hong-Xing.Zhu@freescale.com>
 <20130715020254.GC2730@S2101-09.ap.freescale.net>
Message-ID: <0E83723C55F66F43A6041464FE31119D33BDB4@039-SN2MPN1-011.039d.mgd.msft.net>

Hi Shawn:
Thanks a lot for your great help on the patch-review.

Best Regards
Richard Zhu


-----Original Message-----
From: Shawn Guo [mailto:shawn.guo at linaro.org] 
Sent: Monday, July 15, 2013 10:03 AM
To: Richard Zhu
Cc: linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; tj at kernel.org; rob.herring at calxeda.com; s.hauer at pengutronix.de; linux-ide at vger.kernel.org; Zhu Richard-R65037
Subject: Re: [v6 3/3] sata: imx: add ahci sata support on imx platforms

On Fri, Jul 12, 2013 at 05:41:18PM +0800, Richard Zhu wrote:
> From: Richard Zhu <r65037 at freescale.com>
> 
> imx6q contains one Synopsys AHCI SATA controller, But it can't share 
> ahci_platform driver with other controllers.
> Because there are some misalignments of the generic AHCI controller.
> The bits definitions of the HBA registers, the Vendor Specific 
> registers, the AHCI PHY clock and the AHCI signals adjustment 
> window(GPR13 register).
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default  value is '0', 
> should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the  HOST_PORTS_IMPL 
> should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)  should be 
> configured regarding to the frequency of AHB  bus clock.
>  - Configurations of the AHCI PHY clock, and the signal  parameters of 
> the GPR13
> 
> Setup its own ahci sata driver, contained the imx6q specific 
> initialized codes, re-use the generic ahci_platform driver, and keep 
> the generic ahci_platform driver clean as much as possible.
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> ---
>  drivers/ata/Kconfig    |    9 ++
>  drivers/ata/Makefile   |    1 +
>  drivers/ata/sata_imx.c |  241 
> ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 251 insertions(+), 0 deletions(-)  create mode 
> 100644 drivers/ata/sata_imx.c
> 
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 
> a5a3ebc..275dc2c 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -97,6 +97,15 @@ config SATA_AHCI_PLATFORM
>  
>  	  If unsure, say N.
>  
> +config SATA_IMX
> +	tristate "Freescale i.MX AHCI SATA support"
> +	depends on SATA_AHCI_PLATFORM
> +	help
> +	  This option enables support for the Freescale i.MX SoC's
> +	  onboard AHCI SATA.
> +
> +	  If unsure, say N.
> +
>  config SATA_FSL
>  	tristate "Freescale 3.0Gbps SATA support"
>  	depends on FSL_SOC
> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index 
> c04d0fd..04b1c6c 100644
> --- a/drivers/ata/Makefile
> +++ b/drivers/ata/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_SATA_INIC162X)	+= sata_inic162x.o
>  obj-$(CONFIG_SATA_SIL24)	+= sata_sil24.o
>  obj-$(CONFIG_SATA_DWC)		+= sata_dwc_460ex.o
>  obj-$(CONFIG_SATA_HIGHBANK)	+= sata_highbank.o libahci.o
> +obj-$(CONFIG_SATA_IMX)		+= sata_imx.o
>  
>  # SFF w/ custom DMA
>  obj-$(CONFIG_PDC_ADMA)		+= pdc_adma.o
> diff --git a/drivers/ata/sata_imx.c b/drivers/ata/sata_imx.c new file 
> mode 100644 index 0000000..fb13867
> --- /dev/null
> +++ b/drivers/ata/sata_imx.c
> @@ -0,0 +1,241 @@
> +/*
> + * Freescale IMX AHCI SATA platform driver
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * based on the AHCI SATA platform driver by Jeff Garzik and Anton 
> +Vorontsov
> + *
> + * This program is free software; you can redistribute it and/or 
> +modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License 
> +along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/ahci_platform.h>
> +#include <linux/of_device.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
> +#include "ahci.h"
> +
> +enum {
> +	HOST_TIMER1MS = 0xe0, /* Timer 1-ms */ };
> +
> +struct imx_ahci_priv {
> +	struct platform_device *ahci_pdev;
> +	struct clk *sata_ref_clk;
> +	struct regmap *gpr;
> +};
> +
> +static int imx6q_sata_init(struct device *dev, void __iomem *mmio) {
> +	int ret = 0;
> +	unsigned int reg_val;
> +	struct clk *ahb_clk;
> +	struct imx_ahci_priv *imxpriv = dev_get_drvdata(dev->parent);
> +
> +	imxpriv->gpr =
> +		syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +	if (IS_ERR(imxpriv->gpr)) {
> +		dev_err(dev, "failed to find fsl,imx6q-iomux-gpr regmap\n");
> +		return PTR_ERR(imxpriv->gpr);
> +	}
> +
> +	ret = clk_prepare_enable(imxpriv->sata_ref_clk);
> +	if (ret < 0) {
> +		dev_err(dev, "prepare-enable sata_ref clock err:%d\n", ret);
> +		return ret;
> +	}
> +
> +	/*
> +	 * set PHY Paremeters, two steps to configure the GPR13,
> +	 * one write for rest of parameters, mask of first write
> +	 * is 0x07fffffd, and the other one write for setting
> +	 * the mpll_clk_en.
> +	 */
> +	regmap_update_bits(imxpriv->gpr, 0x34, IMX6Q_GPR13_SATA_RX_EQ_VAL_MASK
> +			| IMX6Q_GPR13_SATA_RX_LOS_LVL_MASK
> +			| IMX6Q_GPR13_SATA_RX_DPLL_MODE_MASK
> +			| IMX6Q_GPR13_SATA_SPD_MODE_MASK
> +			| IMX6Q_GPR13_SATA_MPLL_SS_EN
> +			| IMX6Q_GPR13_SATA_TX_ATTEN_MASK
> +			| IMX6Q_GPR13_SATA_TX_BOOST_MASK
> +			| IMX6Q_GPR13_SATA_TX_LVL_MASK
> +			| IMX6Q_GPR13_SATA_TX_EDGE_RATE
> +			, IMX6Q_GPR13_SATA_RX_EQ_VAL_3_0_DB
> +			| IMX6Q_GPR13_SATA_RX_LOS_LVL_SATA2M
> +			| IMX6Q_GPR13_SATA_RX_DPLL_MODE_2P_4F
> +			| IMX6Q_GPR13_SATA_SPD_MODE_3P0G
> +			| IMX6Q_GPR13_SATA_MPLL_SS_EN
> +			| IMX6Q_GPR13_SATA_TX_ATTEN_9_16
> +			| IMX6Q_GPR13_SATA_TX_BOOST_3_33_DB
> +			| IMX6Q_GPR13_SATA_TX_LVL_1_025_V);
> +	regmap_update_bits(imxpriv->gpr, 0x34, IMX6Q_GPR13_SATA_MPLL_CLK_EN,
> +			IMX6Q_GPR13_SATA_MPLL_CLK_EN);
> +	usleep_range(100, 200);
> +
> +	/*
> +	 * Configure the HWINIT bits of the HOST_CAP and HOST_PORTS_IMPL,
> +	 * and IP vendor specific register HOST_TIMER1MS.
> +	 * Configure CAP_SSS (support stagered spin up).
> +	 * Implement the port0.
> +	 * Get the ahb clock rate, and configure the TIMER1MS register.
> +	 */
> +	reg_val = readl(mmio + HOST_CAP);
> +	if (!(reg_val & HOST_CAP_SSS)) {
> +		reg_val |= HOST_CAP_SSS;
> +		writel(reg_val, mmio + HOST_CAP);
> +	}
> +	reg_val = readl(mmio + HOST_PORTS_IMPL);
> +	if (!(reg_val & 0x1)) {
> +		reg_val |= 0x1;
> +		writel(reg_val, mmio + HOST_PORTS_IMPL);
> +	}
> +
> +	ahb_clk = devm_clk_get(dev, "ahb");

Can we move this devm_clk_get() call into .probe as well?
[Ok] it would be moved to .probe.

> +	if (IS_ERR(ahb_clk)) {
> +		dev_err(dev, "no ahb clock.\n");
> +		clk_disable_unprepare(imxpriv->sata_ref_clk);
> +		devm_clk_put(dev, imxpriv->sata_ref_clk);
> +		return PTR_ERR(ahb_clk);
> +	}
> +	reg_val = clk_get_rate(ahb_clk) / 1000;
> +	writel(reg_val, mmio + HOST_TIMER1MS);
> +	devm_clk_put(dev, ahb_clk);
> +
> +	return 0;
> +}
> +
> +static void imx6q_sata_exit(struct device *dev) {
> +	struct imx_ahci_priv *imxpriv =  dev_get_drvdata(dev->parent);
> +
> +	regmap_update_bits(imxpriv->gpr, 0x34, IMX6Q_GPR13_SATA_MPLL_CLK_EN,
> +			!IMX6Q_GPR13_SATA_MPLL_CLK_EN);
> +	clk_disable_unprepare(imxpriv->sata_ref_clk);
> +}
> +
> +static struct ahci_platform_data imx6q_sata_pdata = {
> +	.init = imx6q_sata_init,
> +	.exit = imx6q_sata_exit,
> +};
> +
> +static const struct of_device_id imx_ahci_of_match[] = {
> +	{ .compatible = "fsl,imx6q-ahci", .data = &imx6q_sata_pdata},
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, imx_ahci_of_match);
> +
> +static int imx_ahci_probe(struct platform_device *pdev) {
> +	struct device *dev = &pdev->dev;
> +	struct resource *mem, *irq, res[2];
> +	const struct of_device_id *of_id;
> +	const struct ahci_platform_data *pdata = NULL;
> +	struct imx_ahci_priv *imxpriv;
> +	struct device *ahci_dev;
> +	struct platform_device *ahci_pdev;
> +	int ret;
> +
> +	imxpriv = devm_kzalloc(dev, sizeof(*imxpriv), GFP_KERNEL);
> +	if (!imxpriv) {
> +		dev_err(dev, "can't alloc ahci_host_priv\n");
> +		return -ENOMEM;
> +	}
> +
> +	ahci_pdev = platform_device_alloc("ahci", -1);
> +	if (!ahci_pdev)
> +		return -ENODEV;
> +
> +	ahci_dev = &ahci_pdev->dev;
> +	ahci_dev->parent = dev;
> +
> +	imxpriv->sata_ref_clk = devm_clk_get(dev, "sata_ref");
> +	if (IS_ERR(imxpriv->sata_ref_clk)) {
> +		dev_err(dev, "can't get sata_ref clock.\n");
> +		ret = PTR_ERR(imxpriv->sata_ref_clk);
> +		goto err_pdev_put;
> +	}
> +
> +	imxpriv->ahci_pdev = ahci_pdev;
> +	platform_set_drvdata(pdev, imxpriv);
> +
> +	of_id = of_match_device(imx_ahci_of_match, dev);
> +	if (of_id) {
> +		pdata = of_id->data;
> +	} else {
> +		ret = -EINVAL;
> +		goto err_out;
> +	}
> +
> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +	if (!mem || !irq) {
> +		dev_err(dev, "no mmio/irq resource\n");
> +		ret = -ENOMEM;
> +		goto err_out;
> +	}
> +
> +	res[0] = *mem;
> +	res[1] = *irq;
> +
> +	ahci_dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +	ahci_dev->dma_mask = &ahci_dev->coherent_dma_mask;
> +	ahci_dev->of_node = dev->of_node;
> +
> +	ret = platform_device_add_resources(ahci_pdev, res, 2);
> +	if (ret)
> +		goto err_out;
> +
> +	ret = platform_device_add_data(ahci_pdev, pdata, sizeof(*pdata));
> +	if (ret)
> +		goto err_out;
> +
> +	ret = platform_device_add(ahci_pdev);
> +	if (ret) {
> +err_out:
> +		platform_set_drvdata(pdev, NULL);

I do not think you need this.
[Richard] ok, they would be removed.

> +		devm_clk_put(dev, imxpriv->sata_ref_clk);

The good thing about using devm_clk_get() above is you do not need to explicitly call devm_clk_put() on either .remove or .probe failure.
[Richard] ok, they would be removed.

> +err_pdev_put:
> +		platform_device_put(ahci_pdev);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int imx_ahci_remove(struct platform_device *pdev) {
> +	struct imx_ahci_priv *imxpriv = platform_get_drvdata(pdev);
> +	struct platform_device *ahci_pdev = imxpriv->ahci_pdev;
> +
> +	platform_device_unregister(ahci_pdev);
> +	platform_set_drvdata(pdev, NULL);

Ditto, you do not need to do this.
[Richard] ok, they would be removed. 

Shawn

> +	return 0;
> +}
> +
> +static struct platform_driver imx_ahci_driver = {
> +	.probe = imx_ahci_probe,
> +	.remove = imx_ahci_remove,
> +	.driver = {
> +		.name = "sata-imx",
> +		.owner = THIS_MODULE,
> +		.of_match_table = imx_ahci_of_match,
> +	},
> +};
> +module_platform_driver(imx_ahci_driver);
> +
> +MODULE_DESCRIPTION("Freescale i.MX AHCI SATA platform driver"); 
> +MODULE_AUTHOR("Richard Zhu <Hong-Xing.Zhu at freescale.com>"); 
> +MODULE_LICENSE("GPL"); MODULE_ALIAS("sata:imx");
> --
> 1.7.5.4
> 



From khilman at linaro.org  Sun Jul 14 08:12:48 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Sun, 14 Jul 2013 13:12:48 +0100
Subject: [PATCH 08/12] ARM: DRA7: Reuse the omap44xx_restart and fix the
 device instance
In-Reply-To: <1373355139-12487-9-git-send-email-rnayak@ti.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
 <1373355139-12487-9-git-send-email-rnayak@ti.com>
Message-ID: <51E295C0.4080309@linaro.org>

On 07/09/2013 08:32 AM, Rajendra Nayak wrote:
> The omap44xx_restart used on omap4 and omap5 devices can be reused
> on dra7 devices as well. The device instance however is different
> across omap5 and dra7 as compared to omap4. So fix this for omap5
> as well as dra7.
> 
> Signed-off-by: Rajendra Nayak <rnayak at ti.com>
> Signed-off-by: R Sricharan <r.sricharan at ti.com>

[...]

> @@ -165,10 +168,19 @@ int omap4_prminst_deassert_hardreset(u8 shift, u8 part, s16 inst,
>  void omap4_prminst_global_warm_sw_reset(void)
>  {
>  	u32 v;
> -
> -	v = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
> -				    OMAP4430_PRM_DEVICE_INST,
> -				    OMAP4_PRM_RSTCTRL_OFFSET);
> +	s16 dev_inst;
> +
> +	if (cpu_is_omap44xx())
> +		dev_inst = OMAP4430_PRM_DEVICE_INST;

Please don't use cpu_is_* (or soc_is_*) at runtime.  Rather, the right
offset/instance should be setup at init time.

Kevin



From khilman at linaro.org  Sun Jul 14 09:22:11 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Sun, 14 Jul 2013 14:22:11 +0100
Subject: [PATCH 4/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
In-Reply-To: <1373473380-27515-1-git-send-email-rogerq@ti.com>
References: <1373473081-27181-1-git-send-email-rogerq@ti.com>
 <1373473380-27515-1-git-send-email-rogerq@ti.com>
Message-ID: <51E2A603.1000805@linaro.org>

On 07/10/2013 05:23 PM, Roger Quadros wrote:
> In order to support wake up from suspend use the pinctrl
> framework to put the USB host pins in IDLE state during suspend.
> 
> CC: Samuel Ortiz <sameo at linux.intel.com>
> Signed-off-by: Roger Quadros <rogerq at ti.com>

[...]

> @@ -608,6 +618,14 @@ static int usbhs_omap_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  	}
>  
> +	if (!dev->pins || !dev->pins->idle_state) {
> +		/* If IDLE pins are not available, we can't remote wakeup,
> +		 * so prevent idling in that case.
> +		 */

nit: multi-line comment style

Also, if there are no pins, aren't the pinctrl ops nops anyways?  IOW,
not sure the need
for this is clear, and it's not mentioned in the changelog.

Kevin



From khilman at linaro.org  Sun Jul 14 08:07:30 2013
From: khilman at linaro.org (Kevin Hilman)
Date: Sun, 14 Jul 2013 13:07:30 +0100
Subject: [PATCH 8/8] ARM: DRA7: Kconfig: Increase the default gpio count
In-Reply-To: <1373354873-12359-9-git-send-email-rnayak@ti.com>
References: <1373354873-12359-1-git-send-email-rnayak@ti.com>
 <1373354873-12359-9-git-send-email-rnayak@ti.com>
Message-ID: <51E29482.7060208@linaro.org>

On 07/09/2013 08:27 AM, Rajendra Nayak wrote:
> From: R Sricharan <r.sricharan at ti.com>
> 
> DRA7xx has 8 GPIO banks so that there are 32x8 = 256 GPIOs.
> In order for the gpiolib to detect and initialize these
> additional GPIOs and other TWL GPIOs, ARCH_NR_GPIO is set
> to 512 instead of present 256.

nit: the patch itself doesn't change 256 to 512, but just adds another
Kconfig default.

Kevin

> Signed-off-by: R Sricharan <r.sricharan at ti.com>
> Signed-off-by: Rajendra Nayak <rnayak at ti.com>
> ---
>  arch/arm/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 5ef7af0..9faed52 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1599,7 +1599,7 @@ config LOCAL_TIMERS
>  config ARCH_NR_GPIO
>  	int
>  	default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
> -	default 512 if SOC_OMAP5
> +	default 512 if SOC_OMAP5 || SOC_DRA7XX
>  	default 512 if ARCH_KEYSTONE
>  	default 392 if ARCH_U8500
>  	default 352 if ARCH_VT8500
> 


From vijay.kilari at gmail.com  Mon Jul 15 02:15:58 2013
From: vijay.kilari at gmail.com (Vijay Kilari)
Date: Mon, 15 Jul 2013 11:45:58 +0530
Subject: v3.10 - big endian core support
In-Reply-To: <51E3638A.3080103@gmail.com>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate>
 <CALicx6sr=OXYAdSS-RXPCjSp4f_yLQyw6jJsQ2KyhgQ9fRtXag@mail.gmail.com>
 <51DFEFD9.2060509@codethink.co.uk> <51E3638A.3080103@gmail.com>
Message-ID: <CALicx6ujEvEVnHM8qT7ThKwg1kgtGsqjSrvmx1pZxk9zXJm0yQ@mail.gmail.com>

Yes, It works now after using rev16

Regards
Vijay

On Mon, Jul 15, 2013 at 8:20 AM,  <jgq516 at gmail.com> wrote:
> On 07/12/2013 08:00 PM, Ben Dooks wrote:
>>
>> On 12/07/13 12:56, Vijay Kilari wrote:
>>>
>>> On Fri, Jul 12, 2013 at 5:17 PM, Thomas Petazzoni
>>> <thomas.petazzoni at free-electrons.com>  wrote:
>>>>
>>>> Dear Vijay Kilari,
>>>>
>>>> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>>>>
>>>>>> Ben Dooks has a separate branch on top of this base branch for
>>>>>> big-endian support, that adds atags compat code to convert the ATAGs
>>>>>> data from LE to BE. See the baserock/311/be/atags branch in
>>>>>> git://git.baserock.org/delta/linux. Or
>>>>>>
>>>>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>>>>
>>>>>
>>>>>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE
>>>>> mode
>>>>> It hangs at very early stage of boot
>>>>
>>>>
>>>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>>>> of the TODO-list. I think Ben said he would probably not have much time
>>>> to work on this. I might be able to spare some time on this, so just
>>>> let me know if I should start working on this. If I remember correctly,
>>>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>>>
>>>
>>> In fact, I tried with below changes.. still it fails
>>>
>>> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
>>> index 2de1114..7df64c7 100644
>>> --- a/arch/arm/kernel/head.S
>>> +++ b/arch/arm/kernel/head.S
>>> @@ -592,8 +592,14 @@ __fixup_a_pv_table:
>>>          b       2f
>>>   1:     add     r7, r3
>>>          ldrh    ip, [r7, #2]
>>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>>> +       rev     ip, ip
>>> +#endif
>>
>>
>> Do you need a rev16 here? I think you may have tried
>> reversing the full 32 bits here instead of just the
>> 16bits of instruction that was loaded.
>>
> Thanks Ben, 3.4 kernel booted ok with your suggested modifications.
>
> gjiang at gjiang-desktop:~/work/be-a15$ git diff
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 0ad3af8..1a0196c 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -600,8 +600,10 @@ __fixup_a_pv_table:
>
>         b       2f
>  1:     add     r7, r3
>         ldrh    ip, [r7, #2]
> +       rev16   ip, ip @be8
>
>         and     ip, 0x8f00
>         orr     ip, r6  @ mask in offset bits 31-24
> +       rev16   ip, ip @be8
>
>         strh    ip, [r7, #2]
>  2:     cmp     r4, r5
>         ldrcc   r7, [r4], #4    @ use branch for delay slot
>
> root at localhost:~# zcat /proc/config.gz |grep BE8
> CONFIG_CPU_ENDIAN_BE8=y
> CONFIG_CPU_BE8_BOOT_LE=y
> root at localhost:~# zcat /proc/config.gz |grep THUMB
> CONFIG_ARM_THUMB=y
> # CONFIG_ARM_THUMBEE is not set
> CONFIG_THUMB2_KERNEL=y
> CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y
>
>
> Regards,
> Xiao
>
>>>          and     ip, 0x8f00
>>>          orr     ip, r6  @ mask in offset bits 31-24
>>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>>> +       rev     ip, ip
>>> +#endif
>>>          strh    ip, [r7, #2]
>>>   2:     cmp     r4, r5
>>>          ldrcc   r7, [r4], #4    @ use branch for delay slot
>>>
>>>>
>>>> Will, is getting Thumb2 working a requirement to get the BE support
>>>> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>>>>
>>>> Thanks!
>>>>
>>>> Thomas
>>>> --
>>>> Thomas Petazzoni, Free Electrons
>>>> Kernel, drivers, real-time and embedded Linux
>>>> development, consulting, training and support.
>>>> http://free-electrons.com
>>
>>
>>
>


From s.hauer at pengutronix.de  Mon Jul 15 02:36:44 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 15 Jul 2013 08:36:44 +0200
Subject: [PATCH 1/1] ARM: imx: clk-pllv3: move the timeout just before
 the comparison
In-Reply-To: <1373763528-20792-1-git-send-email-peter.chen@freescale.com>
References: <1373763528-20792-1-git-send-email-peter.chen@freescale.com>
Message-ID: <20130715063644.GK14452@pengutronix.de>

On Sun, Jul 14, 2013 at 08:58:48AM +0800, Peter Chen wrote:
> It can let the timeout value be more precise.
> 
> Suggested-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> Signed-off-by: Peter Chen <peter.chen at freescale.com>
> ---
>  arch/arm/mach-imx/clk-pllv3.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/clk-pllv3.c b/arch/arm/mach-imx/clk-pllv3.c
> index a9fad5f..e2c026f 100644
> --- a/arch/arm/mach-imx/clk-pllv3.c
> +++ b/arch/arm/mach-imx/clk-pllv3.c
> @@ -48,7 +48,7 @@ struct clk_pllv3 {
>  static int clk_pllv3_prepare(struct clk_hw *hw)
>  {
>  	struct clk_pllv3 *pll = to_clk_pllv3(hw);
> -	unsigned long timeout = jiffies + msecs_to_jiffies(10);
> +	unsigned long timeout;
>  	u32 val;
>  
>  	val = readl_relaxed(pll->base);
> @@ -59,6 +59,7 @@ static int clk_pllv3_prepare(struct clk_hw *hw)
>  		val &= ~BM_PLL_POWER;
>  	writel_relaxed(val, pll->base);
>  
> +	timeout = jiffies + msecs_to_jiffies(10);
>  	/* Wait for PLL to lock */
>  	while (!(readl_relaxed(pll->base) & BM_PLL_LOCK))
>  		if (time_after(jiffies, timeout))

For a proper timeout loop you have to check the condition once after the
timeout, like this:

	while (1) {
		if (condition)
			break;
		if (time_after())
			break;
	}

	if (condition)
		res = OK;
	else
		res = -ETIMEDOUT;

Otherwise you risk being scheduled away after checking the condition but
before checking the timeout.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From rnayak at ti.com  Mon Jul 15 02:44:15 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 15 Jul 2013 12:14:15 +0530
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51DF508F.3050703@ti.com>
References: <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <87mwpuakod.fsf@linaro.org>
 <20130710142633.GV5523@atomide.com> <20130710160704.GH18966@arwen.pp.htv.fi>
 <20130710161158.GA19716@arwen.pp.htv.fi> <20130711063209.GZ5523@atomide.com>
 <51DE8215.5060306@ti.com> <51DF508F.3050703@ti.com>
Message-ID: <51E39A3F.6080106@ti.com>

On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>> Hi,
>>
>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>>> * Felipe Balbi <balbi at ti.com> [130710 09:18]:
>>>>
>>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>>> how about something like below ? It makes omap_device/hwmod and
>>>>> pm_runtime agree on the initial state of the device and will prevent
>>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>>> during probe.
>>>>>
>>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>>
>>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>>> Author: Felipe Balbi <balbi at ti.com>
>>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>>
>>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>>
>>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>>      initial state of the device, we will unidle the device
>>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>>      that the device is really active.
>> Don't think that it's good idea (
>> I've checked some driver's and think this patch will enable some devices
>> unpredictably:
>> - hwspinlock
>> - mailbox
>> - iommu
>> - ipu
>> All above devices need to be enabled on demand only (no
>> pm_runtime_get*() calls in probe). More over, some of them have very
>> specific enabling sequence - like ipu).
>>
>> May be Summan can say more on that.
> 
> Indeed, this is a problem for any of the slave processor devices.
> mailbox and iommu would be slaves to the remoteproc and the drivers have
> a specific sequence of bringing up a processor. The current
> hwmod/omap_device code is such that these devices will be left in reset
> and the driver code use the omap_device_(de)assert_hardreset API
> together with omap_device_enable code to bring up the devices. The
> remoteproc driver also needs to assert the resets (there are other
> problems associated with using omap_device_idle for remoteproc and
> iommu) for bringing up the devices after a suspend sequence. hwspinlock
> and mailbox may get away since they are in CORE domain, but definitely
> an issue for iommu and remoteproc. I would think that this would also
> affect other compute devices like IVAHD, ISS, SGX.

Today, for these IPs I guess hwmod waits for the resets to be de-asserted, right?

        /*
         * If an IP block contains HW reset lines and all of them are
         * asserted, we let integration code associated with that
         * block handle the enable.  We've received very little
         * information on what those driver authors need, and until
         * detailed information is provided and the driver code is
         * posted to the public lists, this is probably the best we
         * can do.
         */
        if (_are_all_hardreset_lines_asserted(oh))
                return 0;

What if this information is send back to omap_device() through a return value
so omap_device() knows about this too, so it avoids marking the omap device as
enabled? Wouldn't that fix the issue?


> 
> regards
> Suman
> 
>>
>>>>>
>>>>>      By the time driver's probe() is reached, a call to
>>>>>      pm_runtime_get_sync() will not cause driver's
>>>>>      ->runtime_resume() method to be called at first, only
>>>>>      after a successful ->runtime_suspend().
>>>>>
>>>>>      Signed-off-by: Felipe Balbi <balbi at ti.com>
>>>>
>>>> btw, this is RFC, haven't tested at all.
>>>
>>> Yes it does not compile, then removing the extra ; at the end
>>> of the functions, it oopses with a NULL pointer exception.
>>>
>>> Regards,
>>>
>>> Tony
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> 



From tony at atomide.com  Mon Jul 15 02:55:42 2013
From: tony at atomide.com (Tony Lindgren)
Date: Sun, 14 Jul 2013 23:55:42 -0700
Subject: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c
In-Reply-To: <CAOesGMgO74FU0P4DC6_yws8ZaQ6F923-LWwGAxbCQkQbr69L5w@mail.gmail.com>
References: <20130517191304.468.73487.stgit@localhost>
 <20130517191751.468.89202.stgit@localhost>
 <20130520095447.GR21614@n2100.arm.linux.org.uk>
 <20130706131057.GU21614@n2100.arm.linux.org.uk>
 <20130706133627.GV21614@n2100.arm.linux.org.uk>
 <CAOesGMjv=GxWSxaUebY6pP4sJHfQNeuUk2BcAFBT3QxX3jGZLw@mail.gmail.com>
 <CAOesGMgO74FU0P4DC6_yws8ZaQ6F923-LWwGAxbCQkQbr69L5w@mail.gmail.com>
Message-ID: <20130715065542.GK7656@atomide.com>

* Olof Johansson <olof at lixom.net> [130712 20:16]:
> On Fri, Jul 12, 2013 at 7:31 PM, Olof Johansson <olof at lixom.net> wrote:
> 
> > This is pretty painful, and I don't know if we want to rethink Arnd's
> > patch since it will break existing defconfigs out there that rely on
> > OMAP2PLUS enabling the socs instead of the other way around. Opinions?
> 
> (replying to myself, I know, I know...)
> 
> I think it's probably easiest to just select the OMAP{2,3,4} and
> AM33XX options in multi_v7_defconfig just like Arnd did in the commit
> that changed the dependencies for now. I've added a patch on top of
> our current fixes branch to do so.

Well should select only omap 3 and later for multi_v7_defconfig as
omap2 is v6 :)
 
> Note that you need to make corresponding changes to your seeds for
> your build tests, Russell.

Eventually we could have them all selected based on the core type,
but I'd rather not do that until clocks and hwmod data come from DT.

Regards,

Tony


From tony at atomide.com  Mon Jul 15 03:58:17 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 15 Jul 2013 00:58:17 -0700
Subject: [PATCH] ARM: multi_v7: Enabled omap4430 sdp nfsroot
Message-ID: <20130715075816.GN7656@atomide.com>

Author: Tony Lindgren <tony at atomide.com>
Date:   Mon Jul 15 00:39:41 2013 -0700

    ARM: multi_v7: Enabled omap4430 sdp nfsroot
    
    By adding support for OCP2SCP, SPI and KS8851 I can also boot test
    multi_v7_defconfig easily.
    
    Note that if using an older u-boot, CONFIG_ARM_ATAG_DTB_COMPAT=y
    may also be needed for the appended DTB based booting.
    
    Signed-off-by: Tony Lindgren <tony at atomide.com>

--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -53,6 +53,7 @@ CONFIG_IP_PNP=y
 CONFIG_IP_PNP_DHCP=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_OMAP_OCP2SCP=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_ATA=y
 CONFIG_SATA_AHCI_PLATFORM=y
@@ -61,6 +62,7 @@ CONFIG_SATA_MV=y
 CONFIG_NETDEVICES=y
 CONFIG_SUN4I_EMAC=y
 CONFIG_NET_CALXEDA_XGMAC=y
+CONFIG_KS8851=y
 CONFIG_SMSC911X=y
 CONFIG_STMMAC_ETH=y
 CONFIG_MDIO_SUN4I=y
@@ -89,6 +91,7 @@ CONFIG_I2C_DESIGNWARE_PLATFORM=y
 CONFIG_I2C_SIRF=y
 CONFIG_I2C_TEGRA=y
 CONFIG_SPI=y
+CONFIG_SPI_OMAP24XX=y
 CONFIG_SPI_PL022=y
 CONFIG_SPI_SIRF=y
 CONFIG_SPI_TEGRA114=y


From maxime.ripard at free-electrons.com  Mon Jul 15 03:59:53 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 15 Jul 2013 09:59:53 +0200
Subject: [PATCH 0/4] A10S-OLinuXino-Micro I2C support
In-Reply-To: <1373232719-13050-1-git-send-email-emilio@elopez.com.ar>
References: <1373232719-13050-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <20130715075953.GA2962@lukather>

Hi Emilio,

On Sun, Jul 07, 2013 at 06:31:55PM -0300, Emilio L?pez wrote:
> Hi,
> 
> This patchset adds the required DT nodes to get I2C supported and 
> working on the OLIMEX A10S-OLinuXino-Micro board.
> 
> Patch 1 adds the muxings as seen on the board's schematics. Patch 2 adds 
> the DT nodes, based on other sunxi dts, as we don't have an A10S user 
> manual so far. Patch 3 enables the controllers, and patch 4 adds a node 
> for the AT24 EEPROM found on the board.
> 
> I have tested and can see the PMU on I2C-0 using i2cdetect, and can read 
> the EEPROM contents on I2C-1. I have not tested I2C-2, but i2cdetect 
> reports no devices so I suppose it's working okay too.
> 
> Any testing or review will be appreciated :)

I just applied them to my sunxi/dt-for-3.12 branch.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130715/9a977471/attachment.sig>

From ben.dooks at codethink.co.uk  Mon Jul 15 04:03:28 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 15 Jul 2013 09:03:28 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <20130714215325.GB7382@mudshark.cambridge.arm.com>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate> <51DFEF75.8080600@codethink.co.uk>
 <20130714215325.GB7382@mudshark.cambridge.arm.com>
Message-ID: <51E3ACD0.8040209@codethink.co.uk>

On 14/07/13 22:53, Will Deacon wrote:
> On Fri, Jul 12, 2013 at 12:58:45PM +0100, Ben Dooks wrote:
>> On 12/07/13 12:47, Thomas Petazzoni wrote:
>>> Dear Vijay Kilari,
>>>
>>> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>>>
>>>>> Ben Dooks has a separate branch on top of this base branch for
>>>>> big-endian support, that adds atags compat code to convert the ATAGs
>>>>> data from LE to BE. See the baserock/311/be/atags branch in
>>>>> git://git.baserock.org/delta/linux. Or
>>>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>>>
>>>>    ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
>>>> It hangs at very early stage of boot
>>>
>>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>>> of the TODO-list. I think Ben said he would probably not have much time
>>> to work on this. I might be able to spare some time on this, so just
>>> let me know if I should start working on this. If I remember correctly,
>>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>>>
>>> Will, is getting Thumb2 working a requirement to get the BE support
>>> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>>
>> I would like to sort out getting this code merged as it seems to have
>> been tested by several people now outside Codethink.
>>
>> I could try doing the THUMB2 support, but I do not have a lot of
>> experience with building THUMB2 kernels.
>
> I think we should try and get Thumb-2 supported before merging this as there
> isn't any real reason why the instruction set should cause endianness
> issues. We're also only almost at -rc1, so there's still time to fix this
> properly for 3.12 instead of adding a fake Kconfig dependency.
>
> As for building a Thumb-2 kernel; just enable the option in menuconfig and
> you're done. The compiler should "do the right thing".

I can build it, I just don't have the time and hardware to give it a
test at the moment. However it seems that changing to using 'rev16'
instead of 'rev'. I will make the necessary changes and get this ready
to go.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From chf.fritz at googlemail.com  Mon Jul 15 04:13:59 2013
From: chf.fritz at googlemail.com (Christoph Fritz)
Date: Mon, 15 Jul 2013 10:13:59 +0200
Subject: [PATCH] ARM: dma: imx: Fix deadlock bug
In-Reply-To: <20130612030321.GA4107@intel.com>
References: <1370724988-16426-1-git-send-email-shc_work@mail.ru>
 <20130608211557.GK18614@n2100.arm.linux.org.uk>
 <20130612030321.GA4107@intel.com>
Message-ID: <1373876039.3897.9.camel@mars>

Hi,

 I'm the initiator of the bug-report[1] ("ARM: imx27: dmaengine:
imx-dma: SD-Card: copy hangs forever") which led to this thread.

Are there any updates yet?

[1]: http://www.spinics.net/lists/arm-kernel/msg250758.html

 Thanks
  -- Christoph



From rogerq at ti.com  Mon Jul 15 04:16:52 2013
From: rogerq at ti.com (Roger Quadros)
Date: Mon, 15 Jul 2013 11:16:52 +0300
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51DFDFD4.3040900@denx.de>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de> <51DE87D3.5030600@ti.com>
 <51DEA7F1.1050902@denx.de> <51DEC2CE.70400@ti.com> <51DED076.3040000@denx.de>
 <51DEF0DE.4050607@denx.de> <51DFC92F.1050701@ti.com>
 <51DFDFD4.3040900@denx.de>
Message-ID: <51E3AFF4.7060607@ti.com>

On 07/12/2013 01:52 PM, Stefan Roese wrote:
> Roger,
> 
> On 07/12/2013 11:15 AM, Roger Quadros wrote:
>>>> Good idea. I'm currently using a "dirty" local version. I'll try to
>>>> switch to an officially available version tomorrow. And send you the
>>>> version/git id.
>>>
>>> I updated my U-Boot to the following version: Based on mainline git
>>> commit ID 225fd8c. Only this patch added:
>>>
>>> http://patchwork.ozlabs.org/patch/256702/
>>>
>>> This is needed for USB to work in U-Boot. Otherwise my external USB
>>> SMSC95xx will not be detected in U-Boot.
>>
>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>> as I don't have an external USB-ethernet adapter.
> 
> Too bad. This difference in boards makes the tests a bit less
> meaningful. Is there really no USB-ethernet adapter somewhere in your
> department (perhaps a non-SMSC95xx might serve as well?)? I might
> send/order you one if necessary. ;)

Thanks for the offer :). I'll just get one for myself by today/tomorrow.
The one available here uses this driver "drivers/net/usb/asix.c"

> 
>> The above commit doesn't work well for beagle-xm,
> 
> Why is this? What does happen? Does U-Boot not boot up to the prompt?
> Please send me a log.

The last time it had failed I remember seeing a lot of IO pad configuration errors.
But I'm no longer able to reproduce that problem. Maybe it was just a messed up
build. In case I observe it again I'll let you know.

> 
>> so my u-boot is on tag v2013.04
>> and you don't need that additional patch.
>>
>> Can you please retest on it? Thanks.
> 
> Done, please see below.
> 
>> You will need to set "usbethaddr" before starting USB else SMSC will not work.
>> e.g.
>> 	setenv usbethaddr A6:66:4D:B0:69:04
> 
> I don't have a beagle-xm, only my beable. And my U-Boot network setup is
> already working, thanks.

Right. you won't need that for beagle. It was only for beagle-xm or panda with on board
usb-ethernet.

> 
>> Also could you please increase the Linux console message verbosity to debug (8), so that
>> all kernel messages are visible in the log? If it spits out something more than what you
>> sent last time then do send it to me.
> 
> I added "ignore_loglevel" to the cmdline. But I cannot see anything
> interesting that has not been there before with "debug" as well.

OK.

cheers,
-roger


From u.kleine-koenig at pengutronix.de  Mon Jul 15 04:20:44 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Mon, 15 Jul 2013 10:20:44 +0200
Subject: [PATCH 1/3] serial: mxs: remove the unused macro
In-Reply-To: <1373857736-30108-1-git-send-email-b32955@freescale.com>
References: <1373857736-30108-1-git-send-email-b32955@freescale.com>
Message-ID: <20130715082044.GL12139@pengutronix.de>

Hello,

On Mon, Jul 15, 2013 at 11:08:54AM +0800, Huang Shijie wrote:
> The MXS_AUART_DMA_CONFIG is originally used to check if the DT node
> is configured with the DMA property.
> 
> But now, the MXS_AUART_DMA_CONFIG is not used any more.
> Just remove it.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>
> ---
>  drivers/tty/serial/mxs-auart.c |    5 +----
>  1 files changed, 1 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index 4f5f161..465ef0b 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -134,7 +134,6 @@ enum mxs_auart_type {
>  struct mxs_auart_port {
>  	struct uart_port port;
>  
> -#define MXS_AUART_DMA_CONFIG	0x1
>  #define MXS_AUART_DMA_ENABLED	0x2
>  #define MXS_AUART_DMA_TX_SYNC	2  /* bit 2 */
>  #define MXS_AUART_DMA_RX_READY	3  /* bit 3 */
> @@ -640,7 +639,7 @@ static void mxs_auart_settermios(struct uart_port *u,
>  		 * we can only implement the DMA support for auart
>  		 * in mx28.
>  		 */
> -		if (is_imx28_auart(s) && (s->flags & MXS_AUART_DMA_CONFIG)) {
> +		if (is_imx28_auart(s)) {
>  			if (!mxs_auart_dma_init(s))
>  				/* enable DMA tranfer */
>  				ctrl2 |= AUART_CTRL2_TXDMAE | AUART_CTRL2_RXDMAE
> @@ -1002,8 +1001,6 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
>  	}
>  	s->port.line = ret;
>  
> -	s->flags |= MXS_AUART_DMA_CONFIG;
> -
You're suggesting that MXS_AUART_DMA_CONFIG was set here unconditionally
before and so the check in the hunk above is not necessary anymore.
(<pedantic>So your "not used any more" is technically wrong.</pedantic>)

However serial_mxs_probe_dt returns earlier if the device was not probed
by dt (which I think we can assume to not apply, still it should be
mentioned in the commit log).

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From rogerq at ti.com  Mon Jul 15 04:23:58 2013
From: rogerq at ti.com (Roger Quadros)
Date: Mon, 15 Jul 2013 11:23:58 +0300
Subject: [PATCH 4/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
In-Reply-To: <51E2A603.1000805@linaro.org>
References: <1373473081-27181-1-git-send-email-rogerq@ti.com>
 <1373473380-27515-1-git-send-email-rogerq@ti.com>
 <51E2A603.1000805@linaro.org>
Message-ID: <51E3B19E.80906@ti.com>

On 07/14/2013 04:22 PM, Kevin Hilman wrote:
> On 07/10/2013 05:23 PM, Roger Quadros wrote:
>> In order to support wake up from suspend use the pinctrl
>> framework to put the USB host pins in IDLE state during suspend.
>>
>> CC: Samuel Ortiz <sameo at linux.intel.com>
>> Signed-off-by: Roger Quadros <rogerq at ti.com>
> 
> [...]
> 
>> @@ -608,6 +618,14 @@ static int usbhs_omap_probe(struct platform_device *pdev)
>>  		return -ENOMEM;
>>  	}
>>  
>> +	if (!dev->pins || !dev->pins->idle_state) {
>> +		/* If IDLE pins are not available, we can't remote wakeup,
>> +		 * so prevent idling in that case.
>> +		 */
> 
> nit: multi-line comment style
> 
> Also, if there are no pins, aren't the pinctrl ops nops anyways?  IOW,
> not sure the need
> for this is clear, and it's not mentioned in the changelog.

The pinctrl ops are nops but the runtime suspend isn't. So in this case,
we'll never be able to wake up the USB controller.

I'll update the changelog to reflect this.

cheers,
-roger


From sr at denx.de  Mon Jul 15 04:24:17 2013
From: sr at denx.de (Stefan Roese)
Date: Mon, 15 Jul 2013 10:24:17 +0200
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51E3AFF4.7060607@ti.com>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de> <51DE87D3.5030600@ti.com>
 <51DEA7F1.1050902@denx.de> <51DEC2CE.70400@ti.com> <51DED076.3040000@denx.de>
 <51DEF0DE.4050607@denx.de> <51DFC92F.1050701@ti.com>
 <51DFDFD4.3040900@denx.de> <51E3AFF4.7060607@ti.com>
Message-ID: <51E3B1B1.3060202@denx.de>

On 07/15/2013 10:16 AM, Roger Quadros wrote:
>>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>>> as I don't have an external USB-ethernet adapter.
>>
>> Too bad. This difference in boards makes the tests a bit less
>> meaningful. Is there really no USB-ethernet adapter somewhere in your
>> department (perhaps a non-SMSC95xx might serve as well?)? I might
>> send/order you one if necessary. ;)
> 
> Thanks for the offer :). I'll just get one for myself by today/tomorrow.
> The one available here uses this driver "drivers/net/usb/asix.c"

Great.

>>
>>> The above commit doesn't work well for beagle-xm,
>>
>> Why is this? What does happen? Does U-Boot not boot up to the prompt?
>> Please send me a log.
> 
> The last time it had failed I remember seeing a lot of IO pad configuration errors.
> But I'm no longer able to reproduce that problem. Maybe it was just a messed up
> build. In case I observe it again I'll let you know.

It might be related to a problem with the gd (global-data) pointer being
overwritten in den SPL. This is still not finally resolved the upcoming
release:

http://patchwork.ozlabs.org/patch/251293/

>>
>>> so my u-boot is on tag v2013.04
>>> and you don't need that additional patch.
>>>
>>> Can you please retest on it? Thanks.
>>
>> Done, please see below.
>>
>>> You will need to set "usbethaddr" before starting USB else SMSC will not work.
>>> e.g.
>>> 	setenv usbethaddr A6:66:4D:B0:69:04
>>
>> I don't have a beagle-xm, only my beable. And my U-Boot network setup is
>> already working, thanks.
> 
> Right. you won't need that for beagle. It was only for beagle-xm or panda with on board
> usb-ethernet.

I'm using the (external) USB-ethernet adapter on the beagle in U-Boot as
well. To tftp the kernel/dtb.

Thanks,
Stefan


From b32955 at freescale.com  Mon Jul 15 04:30:27 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 15 Jul 2013 16:30:27 +0800
Subject: [PATCH 1/3] serial: mxs: remove the unused macro
In-Reply-To: <20130715082044.GL12139@pengutronix.de>
References: <1373857736-30108-1-git-send-email-b32955@freescale.com>
 <20130715082044.GL12139@pengutronix.de>
Message-ID: <51E3B323.1070606@freescale.com>

? 2013?07?15? 16:20, Uwe Kleine-K?nig ??:
> You're suggesting that MXS_AUART_DMA_CONFIG was set here unconditionally
> before and so the check in the hunk above is not necessary anymore.
yes, that's what i want to say.
> (<pedantic>So your "not used any more" is technically wrong.</pedantic>)
ok, I will change this comment.

thanks
Huang Shijie



From u.kleine-koenig at pengutronix.de  Mon Jul 15 04:27:16 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Mon, 15 Jul 2013 10:27:16 +0200
Subject: [PATCH 2/3] serial: mxs: enable the DMA only when the rts/cts is
 enabled
In-Reply-To: <1373857736-30108-2-git-send-email-b32955@freescale.com>
References: <1373857736-30108-1-git-send-email-b32955@freescale.com>
 <1373857736-30108-2-git-send-email-b32955@freescale.com>
Message-ID: <20130715082716.GM12139@pengutronix.de>

On Mon, Jul 15, 2013 at 11:08:55AM +0800, Huang Shijie wrote:
> The originall DMA support works only when the rts/cts is enabled.
s/originall/original/. I'd drop "the" and capitalize RTS/CTS.

> But after several patchs, the DMA support has lost this limit.
s/patchs/patches/, s/the //.

do you want to say that the driver fails to only enable DMA when RTS/CTS
are available; or that today the driver can handle DMA just fine even
without RTS/CTS? I interpret your commit log as the latter, your patch
implements the former however.

> This patch adds an optional property for the uart DT node
> which indicates the uart has rts and cts.
which indicates that the UART has RTS and CTS lines.

> This patch also adds the check for rts/cts before we enable the DMA
> for the uart.
> 
> Signed-off-by: Huang Shijie <b32955 at freescale.com>
> ---
>  .../bindings/tty/serial/fsl-mxs-auart.txt          |    3 +++
>  drivers/tty/serial/mxs-auart.c                     |    5 ++++-
>  2 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
> index 2c00ec6..ef82002 100644
> --- a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
> +++ b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
> @@ -10,6 +10,9 @@ Required properties:
>    Refer to dma.txt and fsl-mxs-dma.txt for details.
>  - dma-names: "rx" for RX channel, "tx" for TX channel.
>  
> +Optional properties:
> +- fsl,uart-has-rtscts : Indicate the uart has rts and cts
> +
>  Example:
>  auart0: serial at 8006a000 {
>  	compatible = "fsl,imx28-auart", "fsl,imx23-auart";
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index 465ef0b..27532fd 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -134,6 +134,7 @@ enum mxs_auart_type {
>  struct mxs_auart_port {
>  	struct uart_port port;
>  
> +#define MXS_AUART_RTSCTS	1
>  #define MXS_AUART_DMA_ENABLED	0x2
>  #define MXS_AUART_DMA_TX_SYNC	2  /* bit 2 */
>  #define MXS_AUART_DMA_RX_READY	3  /* bit 3 */
> @@ -639,7 +640,7 @@ static void mxs_auart_settermios(struct uart_port *u,
>  		 * we can only implement the DMA support for auart
>  		 * in mx28.
>  		 */
> -		if (is_imx28_auart(s)) {
> +		if (is_imx28_auart(s) && (s->flags & MXS_AUART_RTSCTS)) {
>  			if (!mxs_auart_dma_init(s))
>  				/* enable DMA tranfer */
>  				ctrl2 |= AUART_CTRL2_TXDMAE | AUART_CTRL2_RXDMAE
> @@ -1001,6 +1002,8 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
>  	}
>  	s->port.line = ret;
>  
> +	if (of_get_property(np, "fsl,uart-has-rtscts", NULL))
> +		s->flags |= MXS_AUART_RTSCTS;
>  	return 0;
>  }
>  
> -- 
> 1.7.1
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From thomas.petazzoni at free-electrons.com  Mon Jul 15 04:36:58 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 10:36:58 +0200
Subject: v3.10 - big endian core support
In-Reply-To: <51E3ACD0.8040209@codethink.co.uk>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate> <51DFEF75.8080600@codethink.co.uk>
 <20130714215325.GB7382@mudshark.cambridge.arm.com>
 <51E3ACD0.8040209@codethink.co.uk>
Message-ID: <20130715103658.068ac6b7@skate>

Dear Ben Dooks,

On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:

> > As for building a Thumb-2 kernel; just enable the option in menuconfig and
> > you're done. The compiler should "do the right thing".
> 
> I can build it, I just don't have the time and hardware to give it a
> test at the moment. However it seems that changing to using 'rev16'
> instead of 'rev'. I will make the necessary changes and get this ready
> to go.

I am willing to give some testing to early patches, if needed. Do not
hesitate to send me things to test.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From b32955 at freescale.com  Mon Jul 15 04:41:25 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 15 Jul 2013 16:41:25 +0800
Subject: [PATCH 2/3] serial: mxs: enable the DMA only when the rts/cts
 is enabled
In-Reply-To: <20130715082716.GM12139@pengutronix.de>
References: <1373857736-30108-1-git-send-email-b32955@freescale.com>
 <1373857736-30108-2-git-send-email-b32955@freescale.com>
 <20130715082716.GM12139@pengutronix.de>
Message-ID: <51E3B5B5.1030706@freescale.com>

? 2013?07?15? 16:27, Uwe Kleine-K?nig ??:
> do you want to say that the driver fails to only enable DMA when RTS/CTS
> are available; or that today the driver can handle DMA just fine even
> without RTS/CTS? I interpret your commit log as the latter, your patch
> implements the former however.
in the mxs-auart, if the RTS/CTS is not invalid, the DMA should be not 
enabled.

But current code lost the limit, a uart without the RTS/CTS may also 
enables the DMA in which case the uart
may does not run or run in a abnormal way.

thanks
Huang Shijie






From jgq516 at gmail.com  Mon Jul 15 05:02:52 2013
From: jgq516 at gmail.com (jgq516 at gmail.com)
Date: Mon, 15 Jul 2013 17:02:52 +0800
Subject: v3.10 - big endian core support
In-Reply-To: <20130715103658.068ac6b7@skate>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate> <51DFEF75.8080600@codethink.co.uk>
 <20130714215325.GB7382@mudshark.cambridge.arm.com>
 <51E3ACD0.8040209@codethink.co.uk> <20130715103658.068ac6b7@skate>
Message-ID: <51E3BABC.9070204@gmail.com>

On 07/15/2013 04:36 PM, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:
>
>>> As for building a Thumb-2 kernel; just enable the option in menuconfig and
>>> you're done. The compiler should "do the right thing".
>> I can build it, I just don't have the time and hardware to give it a
>> test at the moment. However it seems that changing to using 'rev16'
>> instead of 'rev'. I will make the necessary changes and get this ready
>> to go.
> I am willing to give some testing to early patches, if needed. Do not
> hesitate to send me things to test.
I can test it too if needed :).

Thanks,
Xiao
> Thanks!
>
> Thomas



From u.kleine-koenig at pengutronix.de  Mon Jul 15 05:07:55 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Mon, 15 Jul 2013 11:07:55 +0200
Subject: [PATCH 2/3] serial: mxs: enable the DMA only when the rts/cts is
 enabled
In-Reply-To: <51E3B5B5.1030706@freescale.com>
References: <1373857736-30108-1-git-send-email-b32955@freescale.com>
 <1373857736-30108-2-git-send-email-b32955@freescale.com>
 <20130715082716.GM12139@pengutronix.de>
 <51E3B5B5.1030706@freescale.com>
Message-ID: <20130715090755.GN12139@pengutronix.de>

Hello,

On Mon, Jul 15, 2013 at 04:41:25PM +0800, Huang Shijie wrote:
> ? 2013?07?15? 16:27, Uwe Kleine-K?nig ??:
> >do you want to say that the driver fails to only enable DMA when RTS/CTS
> >are available; or that today the driver can handle DMA just fine even
> >without RTS/CTS? I interpret your commit log as the latter, your patch
> >implements the former however.
> in the mxs-auart, if the RTS/CTS is not invalid, the DMA should be
> not enabled.
> 
> But current code lost the limit, a uart without the RTS/CTS may also
> enables the DMA in which case the uart
> may does not run or run in a abnormal way.
So this sounds like a fix that should go into stable and so preferably
should be the first patch in your series.

Something like:

	serial: mxs-auart: DMA unreliable without RTS/CTS

	According to [add some document name here] DMA doesn't work
	reliable without hardware handshaking. So make DMA dependant on
	a newly introdused property "fsl,uart-has-rtscts".

	Cc: stable at kernel.org # [first affected version]

The flag is only used to decide if dma should be enabled. So I think an
in-code comment would be nice, too. Is it still correct to set
AUART_CTRL2_RTSEN and AUART_CTRL2_RTS and read AUART_STAT_CTS when
fsl,uart-has-rtscts is not provided?
(BTW, mxs_auart_set_mctrl has:

	u32 ctrl = readl(u->membase + AUART_CTRL2);

	ctrl &= ~(AUART_CTRL2_RTSEN | AUART_CTRL2_RTS);
        if (mctrl & TIOCM_RTS) {
                if (tty_port_cts_enabled(&u->state->port))
                        ctrl |= AUART_CTRL2_RTSEN;
                else
                        ctrl |= AUART_CTRL2_RTS;
        }

	s->ctrl = mctrl;

A comment for the diligent reader about the difference between RTSEN and
RTS would be nice. Also I wonder if shadowing mctrl is sensible and used
correctly here.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From pavel at ucw.cz  Mon Jul 15 05:12:32 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Mon, 15 Jul 2013 11:12:32 +0200
Subject: [PATCH] Route kbd LEDs through the generic LEDs layer
In-Reply-To: <20130713093552.GU8252@type>
References: <20110102103210.GA25662@core.coreip.homeip.net>
 <20110102225741.GX5480@const.famille.thibault.fr>
 <20110112182702.GA9168@core.coreip.homeip.net>
 <20111114040613.GA4992@type.famille.thibault.fr>
 <20121221003449.GA6999@type.youpi.perso.aquilenet.fr>
 <20130707101028.GD5651@type.youpi.perso.aquilenet.fr>
 <20130712113655.GA4227@amd.pavel.ucw.cz>
 <20130712124242.GA5876@type>
 <20130712233301.GA3646@amd.pavel.ucw.cz>
 <20130713093552.GU8252@type>
Message-ID: <20130715091230.GA8786@amd.pavel.ucw.cz>

Hi!

> > > > > This permits to reassign keyboard LEDs to something else than keyboard "leds"
> > > > > state, by adding keyboard led and modifier triggers connected to a series
> > > > > of VT input LEDs, themselves connected to VT input triggers, which
> > > > > per-input device LEDs use by default.  Userland can thus easily change the LED
> > > > > behavior of (a priori) all input devices, or of particular input devices.
> > > > 
> > > > Nice! Leds now have proper /sys interface.
> > > > 
> > > > But... I boot up, switch from X to console, press capslock, and no
> > > > reaction anywhere.
> > > 
> > > Is it working without the patch?  Console-setup for instance is known to
> > > have broken the capslock LED, which is precisely one of the reasons for
> > > this patch, which will provide console-setup with a way to bring back
> > > caps lock working properly.
> > 
> > You are right, it was broken before.
> 
> Ok. You then may want fix your setup by configuring your caps lock led
> the way console-setup will be supposed to do in the future:
> 
> echo ctrlllock > /sys/class/leds/vt::capsl/trigger

And this indeed makes capslock led work on console, again. Nice!

Richard, could we get this applied for 3.12 or something? It makes
keyboard LEDs sane...

Thanks,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From rnayak at ti.com  Mon Jul 15 05:22:23 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 15 Jul 2013 14:52:23 +0530
Subject: [PATCH 09/12] ARM: DRA7: hwmod: Create initial DRA7XX SoC data
In-Reply-To: <20130709113657.GF5523@atomide.com>
References: <1373355139-12487-1-git-send-email-rnayak@ti.com>
 <1373355139-12487-10-git-send-email-rnayak@ti.com>
 <20130709083152.GC5523@atomide.com> <51DBE2A2.2040403@ti.com>
 <20130709113657.GF5523@atomide.com>
Message-ID: <51E3BF4F.2010803@ti.com>

On Tuesday 09 July 2013 05:06 PM, Tony Lindgren wrote:
>>>> +/* dma_system */
>>>> > >> +static struct omap_hwmod_irq_info dra7xx_dma_system_irqs[] = {
>>>> > >> +	{ .name = "0", .irq = 12 + DRA7XX_IRQ_GIC_START },
>>>> > >> +	{ .name = "1", .irq = 13 + DRA7XX_IRQ_GIC_START },
>>>> > >> +	{ .name = "2", .irq = 14 + DRA7XX_IRQ_GIC_START },
>>>> > >> +	{ .name = "3", .irq = 15 + DRA7XX_IRQ_GIC_START },
>>>> > >> +	{ .irq = -1 }
>>>> > >> +};
>>> > > 
>>> > > I think these should no longer be needed?
>> > 
>> > These are needed only for dma because mach-omap2/dma.c still creates
>> > devices from hmwod and which are used by plat/dma.c.
>> > These irqs for sdma exist even in the cleaned up omap4 and omap5 hmwod files.
>> > I'll try and get rid of that dependency of plat/dma on mach/dma to create devices.
> OK great.

Looks like this wouldn't be possible because drivers/dma/omap-dma.c is the one which is
probing the sdma device created using device tree. So we can't have plat-omap/dma.c probe the
same device.

>  



From balbi at ti.com  Mon Jul 15 05:26:33 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 15 Jul 2013 12:26:33 +0300
Subject: [PATCH] arm: omap5: dts: add palmas-usb node
In-Reply-To: <1373645681-29779-1-git-send-email-balbi@ti.com>
References: <1373645681-29779-1-git-send-email-balbi@ti.com>
Message-ID: <20130715092633.GC14330@arwen.pp.htv.fi>

On Fri, Jul 12, 2013 at 07:14:41PM +0300, Felipe Balbi wrote:
> Without this node, there will be no palmas
> driver to notify dwc3 that a cable has
> been connected and, without that, dwc3
> will never initialize.
> 
> Signed-off-by: Felipe Balbi <balbi at ti.com>
> ---
> 
> after this, all we need is wait EXTCON merge
> which contains the final changes necessary
> to get USB3 working out of the box.
> 
> I'd suggest waiting on this patch until EXTCON
> reaches mainline, just to make sure we don't
> end up with DTS data for devices which don't
> exist.

this is not entirely correct. v3.11-rc1 has almost everything we need,
already have a newer version of this patch but dwc3 has decided not to
behave.

don't apply this version

-- 
balbi
-------------- 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/20130715/5843200f/attachment.sig>

From jacmet at sunsite.dk  Mon Jul 15 05:27:24 2013
From: jacmet at sunsite.dk (Peter Korsgaard)
Date: Mon, 15 Jul 2013 11:27:24 +0200
Subject: [PATCH] Route kbd LEDs through the generic LEDs layer
In-Reply-To: <20130707101028.GD5651@type.youpi.perso.aquilenet.fr> (Samuel
 Thibault's message of "Sun, 7 Jul 2013 12:10:28 +0200")
References: <201011112205.oABM5KVJ005298@imap1.linux-foundation.org>
 <201011111440.07882.dmitry.torokhov@gmail.com>
 <20110102090935.GV32469@atrey.karlin.mff.cuni.cz>
 <20110102103210.GA25662@core.coreip.homeip.net>
 <20110102225741.GX5480@const.famille.thibault.fr>
 <20110112182702.GA9168@core.coreip.homeip.net>
 <20111114040613.GA4992@type.famille.thibault.fr>
 <20121221003449.GA6999@type.youpi.perso.aquilenet.fr>
 <20130707101028.GD5651@type.youpi.perso.aquilenet.fr>
Message-ID: <87wqos9nr7.fsf@dell.be.48ers.dk>

>>>>> "Samuel" == Samuel Thibault <samuel.thibault at ens-lyon.org> writes:

 Samuel> This permits to reassign keyboard LEDs to something else than keyboard "leds"
 Samuel> state, by adding keyboard led and modifier triggers connected to a series
 Samuel> of VT input LEDs, themselves connected to VT input triggers, which
 Samuel> per-input device LEDs use by default.  Userland can thus easily change the LED
 Samuel> behavior of (a priori) all input devices, or of particular input devices.

 Samuel> This also permits to fix #7063 from userland by using a modifier to implement
 Samuel> proper CapsLock behavior and have the keyboard caps lock led show that modifier
 Samuel> state.

 Samuel> Signed-off-by: Samuel Thibault <samuel.thibault at ens-lyon.org>
 Samuel> [ebroder at mokafive.com: Rebased to 3.2-rc1 or so, cleaned up some includes, and fixed some constants]
 Samuel> Signed-off-by: Evan Broder <evan at ebroder.net>

Looks good to me. Samuel, thanks for picking this up again.

Acked-by: Peter Korsgaard <jacmet at sunsite.dk>

-- 
Bye, Peter Korsgaard


From viresh.kumar at linaro.org  Mon Jul 15 05:31:42 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 15 Jul 2013 15:01:42 +0530
Subject: [PATCH] cpufreq: s3c24xx: fix typo "ARM_S3C24XX"
In-Reply-To: <1373803339.1370.18.camel@x61.thuisdomein>
References: <1373803339.1370.18.camel@x61.thuisdomein>
Message-ID: <CAKohpok1xvsVrssYrNJJZ2GTLJZVnY8SrCzNx+VdXbiMjL6uLw@mail.gmail.com>

On 14 July 2013 17:32, Paul Bolle <pebolle at tiscali.nl> wrote:
> Kconfig symbol S3C24XX_PLL depends on ARM_S3C24XX. But that symbol
> doesn't exist. Commit f023f8dd59bf ("cpufreq: s3c24xx: move cpufreq
> driver to drivers/cpufreq"), which added this typo, makes clear that
> ARM_S3C24XX_CPUFREQ was intended here.
>
> Signed-off-by: Paul Bolle <pebolle at tiscali.nl>
> ---
> Untested!
>
>  arch/arm/mach-s3c24xx/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index 6d9252e..7791ac7 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -208,7 +208,7 @@ config S3C24XX_GPIO_EXTRA128
>
>  config S3C24XX_PLL
>         bool "Support CPUfreq changing of PLL frequency (EXPERIMENTAL)"
> -       depends on ARM_S3C24XX
> +       depends on ARM_S3C24XX_CPUFREQ
>         help
>           Compile in support for changing the PLL frequency from the
>           S3C24XX series CPUfreq driver. The PLL takes time to settle

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>

@Rafael: I saw you taking other s3c patch directly. Mind taking this
one too?


From lorenzo.pieralisi at arm.com  Mon Jul 15 05:34:06 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 15 Jul 2013 10:34:06 +0100
Subject: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu
 nodes bindings updates
In-Reply-To: <CAL_JsqLANi5UoVyRMsa6XoQ+_KnmTQDfTz++shEh-dZ3FQGZaQ@mail.gmail.com>
References: <1368804061-4421-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1368804061-4421-4-git-send-email-lorenzo.pieralisi@arm.com>
 <CAL_JsqLANi5UoVyRMsa6XoQ+_KnmTQDfTz++shEh-dZ3FQGZaQ@mail.gmail.com>
Message-ID: <20130715093406.GC15904@e102568-lin.cambridge.arm.com>

On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote:
> On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi
> <lorenzo.pieralisi at arm.com> wrote:
> > In order to extend the current cpu nodes bindings to newer CPUs
> > inclusive of AArch64 and to update support for older ARM CPUs this
> > patch updates device tree documentation for the cpu nodes bindings.
> 
> Sorry for the long delay on this, but I'm still not happy with the binding here.

I had to ask Russell again to drop the bindings patches from the patch
system, and this is not acceptable since two months have passed and the
entire series was reviewed, acked and partially merged. I will review
these bindings again but I would like to understand who should give the final
go ahead to get these patches queued for upstreaming, I can't continue
updating this stuff forever.

> > Main changes:
> >     - adds 64-bit bindings
> >     - define usage of #address-cells
> >     - define 32/64 dts compatibility settings
> >     - defines behaviour on pre and post v7 uniprocessor systems
> >     - adds ARM 11MPcore specific reg property definition
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > ---
> >  Documentation/devicetree/bindings/arm/cpus.txt | 459 ++++++++++++++++++++++---
> >  1 file changed, 412 insertions(+), 47 deletions(-)
> 
> [snip]
> 
> > +                       # On ARM v8 64-bit systems, where the reg property
> > +                         size can be 1 or 2 cells (as defined by cpus node's
> > +                         #address-cells property), this property is
> > +                         required and matches:
> > +
> > +                         - On systems running the OS in AArch32:
> 
> The DTS cannot change based on 32-bit or 64-bit OS.

"On systems running the OS in AArch32" implies a dependency on the
HW execution state. Since the DT is used to configure OSs I thought that
could be a valid sentence. Unfortunately this stuff is not C, so I
reiterate my point above, before changing it I would like to understand
who should say the wording is ok otherwise we could argue forever.

> > +
> > +                           * If the cpus node's #address-cells value is 2:
> > +
> > +                             The first reg cell must be set to 0.
> > +
> > +                             The second reg cell bits [23:0] must be set to
> > +                             bits [23:0] of MPIDR_EL1.
> > +
> > +                             All other bits in the reg cells must be set to 0.
> > +
> > +                           * If the cpus node's #address-cells value is 1:
> > +
> > +                             Bits [23:0] in the reg cell must be set to
> > +                             bits [23:0] in MPIDR_EL1.
> > +
> > +                             All other bits in the reg cell must be 0.
> > +
> > +                         - On systems running the OS in AArch64:
> > +
> > +                           * If the cpus node's #address-cells value is 2:
> > +
> > +                             The first reg cell bits [7:0] must be set to
> > +                             bits [39:32] of MPIDR_EL1.
> > +
> > +                             The second reg cell bits [23:0] must be set to
> > +                             bits [23:0] of MPIDR_EL1.
> > +
> > +                             All other bits in the reg cells must be set to 0.
> > +
> > +                           * If the cpus node's #address-cells value is 1:
> > +
> > +                             MPIDR_EL1[63:32] is 0 on all processors in the
> > +                             system.
> 
> Your logic is backwards here. If the MPIDR_EL1[63:32] is 0, then
> #address-cells can be 1. You could say the upper bits are ignored and
> treated as 0. However, you should simplify all this and just mandate
> that #address-cells must be 2 for ARMv8 or more generally must match
> the size of the MPIDR. If we want to boot a 32-bit kernel, then the
> kernel will have to adapt to support this.

Fair enough I will see how I can reword it.

> > +
> > +                             The reg cell bits [23:0] must be set to
> > +                             bits [23:0] of MPIDR_EL1.
> > +
> > +                             All other bits in the reg cell must be set to 0.
> > +
> > +       - compatible:
> > +               Usage: required
> > +               Value type: <string>
> > +               Definition: should be one of:
> > +                           "arm,arm710t"
> > +                           "arm,arm720t"
> > +                           "arm,arm740t"
> > +                           "arm,arm7ej-s"
> > +                           "arm,arm7tdmi"
> > +                           "arm,arm7tdmi-s"
> > +                           "arm,arm9es"
> > +                           "arm,arm9ej-s"
> > +                           "arm,arm920t"
> > +                           "arm,arm922t"
> > +                           "arm,arm925"
> > +                           "arm,arm926e-s"
> > +                           "arm,arm926ej-s"
> > +                           "arm,arm940t"
> > +                           "arm,arm946e-s"
> > +                           "arm,arm966e-s"
> > +                           "arm,arm968e-s"
> > +                           "arm,arm9tdmi"
> > +                           "arm,arm1020e"
> > +                           "arm,arm1020t"
> > +                           "arm,arm1022e"
> > +                           "arm,arm1026ej-s"
> > +                           "arm,arm1136j-s"
> > +                           "arm,arm1136jf-s"
> > +                           "arm,arm1156t2-s"
> > +                           "arm,arm1156t2f-s"
> > +                           "arm,arm1176jzf"
> > +                           "arm,arm1176jz-s"
> > +                           "arm,arm1176jzf-s"
> > +                           "arm,arm11mpcore"
> > +                           "arm,cortex-a5"
> > +                           "arm,cortex-a7"
> > +                           "arm,cortex-a8"
> > +                           "arm,cortex-a9"
> > +                           "arm,cortex-a15"
> > +                           "arm,cortex-a53"
> > +                           "arm,cortex-a57"
> > +                           "arm,cortex-m0"
> > +                           "arm,cortex-m0+"
> > +                           "arm,cortex-m1"
> > +                           "arm,cortex-m3"
> > +                           "arm,cortex-m4"
> > +                           "arm,cortex-r4"
> > +                           "arm,cortex-r5"
> > +                           "arm,cortex-r7"
> > +                           "faraday,fa526"
> > +                           "intel,sa110"
> > +                           "intel,sa1100"
> > +                           "marvell,feroceon"
> > +                           "marvell,mohawk"
> > +                           "marvell,pj4"
> > +                           "marvell,sheeva-v7"
> > +                           "marvell,xsc3"
> > +                           "marvell,xscale"
> > +                           "qcom,krait"
> > +                           "qcom,scorpion"
> > +       - enable-method
> > +               Value type: <stringlist>
> > +               Usage and definition depend on ARM architecture version and
> > +               configuration:
> > +                       # On ARM v8 64-bit systems running the OS in AArch64,
> 
> Again, the DTS can't depend on the OS type.

It was meant to make it dependent on the execution state.

> > +                         this property is required and must be one of:
> > +                            "spin-table"
> > +                            "psci"
> > +                       # On ARM 32-bit systems or ARM v8 systems running
> > +                         the OS in AArch32 this property is prohibited.
> 
> I still don't get the distinction between 32 and 64 bit here. On
> 32-bit, you have 3 choices: psci, spin-table, or SoC specific. So make
> this property optional for 32-bit and mandatory for 64-bit.

Ok.

> > +
> > +       - cpu-release-addr
> > +               Usage: required for systems that have an "enable-method"
> > +                      property value of "spin-table".
> > +               Value type: <prop-encoded-array>
> > +               Definition:
> > +                       # On ARM v8 64-bit systems must be a two cell
> > +                         property identifying a 64-bit zero-initialised
> > +                         memory location.
> 
> As I mentioned previously, isn't some wake-up method needed? Most
> systems will be in wfi or wfe rather than continuously spinning.

Mmm...this can become a minefield, wfe, wfi, CPU in reset..this needs some
thought.

Thanks,
Lorenzo



From rnayak at ti.com  Mon Jul 15 06:01:01 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 15 Jul 2013 15:31:01 +0530
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51E39A3F.6080106@ti.com>
References: <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <87mwpuakod.fsf@linaro.org>
 <20130710142633.GV5523@atomide.com> <20130710160704.GH18966@arwen.pp.htv.fi>
 <20130710161158.GA19716@arwen.pp.htv.fi> <20130711063209.GZ5523@atomide.com>
 <51DE8215.5060306@ti.com> <51DF508F.3050703@ti.com> <51E39A3F.6080106@ti.com>
Message-ID: <51E3C85D.2010008@ti.com>

On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote:
> On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
>> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>>> Hi,
>>>
>>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>>>> * Felipe Balbi <balbi at ti.com> [130710 09:18]:
>>>>>
>>>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>>>> how about something like below ? It makes omap_device/hwmod and
>>>>>> pm_runtime agree on the initial state of the device and will prevent
>>>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>>>> during probe.
>>>>>>
>>>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>>>
>>>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>>>> Author: Felipe Balbi <balbi at ti.com>
>>>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>>>
>>>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>>>
>>>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>>>      initial state of the device, we will unidle the device
>>>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>>>      that the device is really active.
>>> Don't think that it's good idea (
>>> I've checked some driver's and think this patch will enable some devices
>>> unpredictably:
>>> - hwspinlock
>>> - mailbox
>>> - iommu
>>> - ipu
>>> All above devices need to be enabled on demand only (no
>>> pm_runtime_get*() calls in probe). More over, some of them have very
>>> specific enabling sequence - like ipu).
>>>
>>> May be Summan can say more on that.
>>
>> Indeed, this is a problem for any of the slave processor devices.
>> mailbox and iommu would be slaves to the remoteproc and the drivers have
>> a specific sequence of bringing up a processor. The current
>> hwmod/omap_device code is such that these devices will be left in reset
>> and the driver code use the omap_device_(de)assert_hardreset API
>> together with omap_device_enable code to bring up the devices. The
>> remoteproc driver also needs to assert the resets (there are other
>> problems associated with using omap_device_idle for remoteproc and
>> iommu) for bringing up the devices after a suspend sequence. hwspinlock
>> and mailbox may get away since they are in CORE domain, but definitely
>> an issue for iommu and remoteproc. I would think that this would also
>> affect other compute devices like IVAHD, ISS, SGX.
> 
> Today, for these IPs I guess hwmod waits for the resets to be de-asserted, right?
> 
>         /*
>          * If an IP block contains HW reset lines and all of them are
>          * asserted, we let integration code associated with that
>          * block handle the enable.  We've received very little
>          * information on what those driver authors need, and until
>          * detailed information is provided and the driver code is
>          * posted to the public lists, this is probably the best we
>          * can do.
>          */
>         if (_are_all_hardreset_lines_asserted(oh))
>                 return 0;
> 
> What if this information is send back to omap_device() through a return value
> so omap_device() knows about this too, so it avoids marking the omap device as
> enabled? Wouldn't that fix the issue?

I meant something like this..

>From 2fbea0dde0f72897089ef2e8e441b5e5bd6ea967 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <rnayak at ti.com>
Date: Mon, 15 Jul 2013 15:23:07 +0530
Subject: [PATCH] ARM: OMAP2+: Make omap_device aware of hwmod failing to
 enable/idle/shutdown the hwmods

For IP blocks (mainly processors) which have hard reset lines, hwmod avoids
enable/idle/shutdown operations as long as all the hard reset lines are
kept asserted. However it does not return an error back to the caller (in some
cases the omap_device layer) to communicate back the failure to operate on the
hwmod.

Fix this by making _enable()/_idle()/_shutdown() all return an error in such
cases, and also fix the omap_device layer to look at the return values coming
from hwmod operations before doing a omap_device level state transition.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/omap_device.c |   20 ++++++++++----------
 arch/arm/mach-omap2/omap_hwmod.c  |    6 +++---
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..e89244b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -210,13 +210,12 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
  */
 static int _omap_device_enable_hwmods(struct omap_device *od)
 {
-	int i;
+	int i, ret = 0;
 
 	for (i = 0; i < od->hwmods_cnt; i++)
-		omap_hwmod_enable(od->hwmods[i]);
+		ret |= omap_hwmod_enable(od->hwmods[i]);
 
-	/* XXX pass along return value here? */
-	return 0;
+	return ret;
 }
 
 /**
@@ -227,13 +226,12 @@ static int _omap_device_enable_hwmods(struct omap_device *od)
  */
 static int _omap_device_idle_hwmods(struct omap_device *od)
 {
-	int i;
+	int i, ret = 0;
 
 	for (i = 0; i < od->hwmods_cnt; i++)
-		omap_hwmod_idle(od->hwmods[i]);
+		ret |= omap_hwmod_idle(od->hwmods[i]);
 
-	/* XXX pass along return value here? */
-	return 0;
+	return ret;
 }
 
 /* Public functions for use by core code */
@@ -697,7 +695,8 @@ int omap_device_enable(struct platform_device *pdev)
 
 	ret = _omap_device_enable_hwmods(od);
 
-	od->_state = OMAP_DEVICE_STATE_ENABLED;
+	if (!ret)
+		od->_state = OMAP_DEVICE_STATE_ENABLED;
 
 	return ret;
 }
@@ -727,7 +726,8 @@ int omap_device_idle(struct platform_device *pdev)
 
 	ret = _omap_device_idle_hwmods(od);
 
-	od->_state = OMAP_DEVICE_STATE_IDLE;
+	if (!ret)
+		od->_state = OMAP_DEVICE_STATE_IDLE;
 
 	return ret;
 }
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7341eff..07fd2a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2133,7 +2133,7 @@ static int _enable(struct omap_hwmod *oh)
 	 * can do.
 	 */
 	if (_are_all_hardreset_lines_asserted(oh))
-		return 0;
+		return -EPERM;
 
 	/* Mux pins for device runtime if populated */
 	if (oh->mux && (!oh->mux->enabled ||
@@ -2222,7 +2222,7 @@ static int _idle(struct omap_hwmod *oh)
 	}
 
 	if (_are_all_hardreset_lines_asserted(oh))
-		return 0;
+		return -EPERM;
 
 	if (oh->class->sysc)
 		_idle_sysc(oh);
@@ -2276,7 +2276,7 @@ static int _shutdown(struct omap_hwmod *oh)
 	}
 
 	if (_are_all_hardreset_lines_asserted(oh))
-		return 0;
+		return -EPERM;
 
 	pr_debug("omap_hwmod: %s: disabling\n", oh->name);
 
-- 
1.7.9.5



From will.deacon at arm.com  Mon Jul 15 06:02:43 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Jul 2013 11:02:43 +0100
Subject: [PATCH] arm64: compat: fix compilation when using 64kB pages
In-Reply-To: <1373553036-5418-1-git-send-email-marc.zyngier@arm.com>
References: <1373553036-5418-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130715100243.GA10000@mudshark.cambridge.arm.com>

On Thu, Jul 11, 2013 at 03:30:36PM +0100, Marc Zyngier wrote:
> When compiling for 64kB pages, we end-up having conflicting
> implementations for aarch32_break_handler().
> 
> Wrap the 4kB page implementation with a CONFIG_COMPAT guard and change
> the !CONFIG_COMPAT implementation to be static inline instead of simply static.
> 
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

I think there was a better fix kicking around for this from Chen Gang already.
I asked for a new commit message, but a v3 didn't appear:

  http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/179418.html

Will


From plagnioj at jcrosoft.com  Mon Jul 15 06:05:19 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 15 Jul 2013 12:05:19 +0200
Subject: [PATCH 1/1] ARM: at91: at91sam9260: add missing pinctrl-names on mmc
Message-ID: <1373882719-9940-1-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 arch/arm/boot/dts/at91sam9260.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index c7ccbcb..56ee828 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -572,6 +572,7 @@
 				interrupts = <9 IRQ_TYPE_LEVEL_HIGH 0>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				pinctrl-names = "default";
 				status = "disabled";
 			};
 
-- 
1.8.3.2



From pullip.cho at samsung.com  Mon Jul 15 06:20:34 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Mon, 15 Jul 2013 19:20:34 +0900
Subject: [PATCH v7 5/9] iommu/exynos: change rwlock to spinlock
In-Reply-To: <13890783.WKk2X4EVm4@amdc1032>
References: <002d01ce797b$49c441a0$dd4cc4e0$@samsung.com>
 <13890783.WKk2X4EVm4@amdc1032>
Message-ID: <009301ce8144$f1172c30$d3458490$@samsung.com>

> From: Bartlomiej Zolnierkiewicz [mailto:b.zolnierkie at samsung.com]
> Sent: Saturday, July 13, 2013 12:31 AM
> 
> Hi,
> 
> On Friday, July 05, 2013 09:29:26 PM Cho KyongHo wrote:
> > Since acquiring read_lock is not more frequent than write_lock, it is
> > not beneficial to use rwlock, this commit changes rwlock to spinlock.
> 
> This change is not of a "fix type" and is not required to make the driver
> work so it would probably be best to move it to the end of a patch series
> (IOW just making it the last patch in the series).
> 

Thank you for advice.
I will do that in the next patchset :)

Cho KyongHo.

> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
> 
> > Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> > ---
> >  drivers/iommu/exynos-iommu.c |   32 ++++++++++++++++----------------
> >  1 files changed, 16 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> > index 390f8b7..6793661 100644
> > --- a/drivers/iommu/exynos-iommu.c
> > +++ b/drivers/iommu/exynos-iommu.c
> > @@ -175,7 +175,7 @@ struct sysmmu_drvdata {
> >  	void __iomem **sfrbases;
> >  	struct clk *clk[2];
> >  	int activations;
> > -	rwlock_t lock;
> > +	spinlock_t lock;
> >  	struct iommu_domain *domain;
> >  	sysmmu_fault_handler_t fault_handler;
> >  	unsigned long pgtable;
> > @@ -259,7 +259,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
> >  	BUG_ON((base0 + size0) <= base0);
> >  	BUG_ON((size1 > 0) && ((base1 + size1) <= base1));
> >
> > -	read_lock_irqsave(&data->lock, flags);
> > +	spin_lock_irqsave(&data->lock, flags);
> >  	if (!is_sysmmu_active(data))
> >  		goto finish;
> >
> > @@ -289,7 +289,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
> >  		}
> >  	}
> >  finish:
> > -	read_unlock_irqrestore(&data->lock, flags);
> > +	spin_unlock_irqrestore(&data->lock, flags);
> >  }
> >
> >  static void __set_fault_handler(struct sysmmu_drvdata *data,
> > @@ -297,9 +297,9 @@ static void __set_fault_handler(struct sysmmu_drvdata *data,
> >  {
> >  	unsigned long flags;
> >
> > -	write_lock_irqsave(&data->lock, flags);
> > +	spin_lock_irqsave(&data->lock, flags);
> >  	data->fault_handler = handler;
> > -	write_unlock_irqrestore(&data->lock, flags);
> > +	spin_unlock_irqrestore(&data->lock, flags);
> >  }
> >
> >  void exynos_sysmmu_set_fault_handler(struct device *dev,
> > @@ -347,7 +347,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
> >
> >  	int i, ret = -ENOSYS;
> >
> > -	read_lock(&data->lock);
> > +	spin_lock(&data->lock);
> >
> >  	WARN_ON(!is_sysmmu_active(data));
> >
> > @@ -391,7 +391,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
> >  	if (itype != SYSMMU_FAULT_UNKNOWN)
> >  		sysmmu_unblock(data->sfrbases[i]);
> >
> > -	read_unlock(&data->lock);
> > +	spin_unlock(&data->lock);
> >
> >  	return IRQ_HANDLED;
> >  }
> > @@ -402,7 +402,7 @@ static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
> >  	bool disabled = false;
> >  	int i;
> >
> > -	write_lock_irqsave(&data->lock, flags);
> > +	spin_lock_irqsave(&data->lock, flags);
> >
> >  	if (!set_sysmmu_inactive(data))
> >  		goto finish;
> > @@ -419,7 +419,7 @@ static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
> >  	data->pgtable = 0;
> >  	data->domain = NULL;
> >  finish:
> > -	write_unlock_irqrestore(&data->lock, flags);
> > +	spin_unlock_irqrestore(&data->lock, flags);
> >
> >  	if (disabled)
> >  		dev_dbg(data->sysmmu, "(%s) Disabled\n", data->dbgname);
> > @@ -442,7 +442,7 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
> >  	int i, ret = 0;
> >  	unsigned long flags;
> >
> > -	write_lock_irqsave(&data->lock, flags);
> > +	spin_lock_irqsave(&data->lock, flags);
> >
> >  	if (!set_sysmmu_active(data)) {
> >  		if (WARN_ON(pgtable != data->pgtable)) {
> > @@ -481,7 +481,7 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
> >
> >  	dev_dbg(data->sysmmu, "(%s) Enabled\n", data->dbgname);
> >  finish:
> > -	write_unlock_irqrestore(&data->lock, flags);
> > +	spin_unlock_irqrestore(&data->lock, flags);
> >
> >  	return ret;
> >  }
> > @@ -528,7 +528,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
> >  	unsigned long flags;
> >  	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
> >
> > -	read_lock_irqsave(&data->lock, flags);
> > +	spin_lock_irqsave(&data->lock, flags);
> >
> >  	if (is_sysmmu_active(data)) {
> >  		int i;
> > @@ -545,7 +545,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
> >  			data->dbgname);
> >  	}
> >
> > -	read_unlock_irqrestore(&data->lock, flags);
> > +	spin_unlock_irqrestore(&data->lock, flags);
> >  }
> >
> >  void exynos_sysmmu_tlb_invalidate(struct device *dev)
> > @@ -553,7 +553,7 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
> >  	unsigned long flags;
> >  	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
> >
> > -	read_lock_irqsave(&data->lock, flags);
> > +	spin_lock_irqsave(&data->lock, flags);
> >
> >  	if (is_sysmmu_active(data)) {
> >  		int i;
> > @@ -569,7 +569,7 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
> >  			data->dbgname);
> >  	}
> >
> > -	read_unlock_irqrestore(&data->lock, flags);
> > +	spin_unlock_irqrestore(&data->lock, flags);
> >  }
> >
> >  static int exynos_sysmmu_probe(struct platform_device *pdev)
> > @@ -666,7 +666,7 @@ static int exynos_sysmmu_probe(struct platform_device *pdev)
> >  	}
> >
> >  	data->sysmmu = dev;
> > -	rwlock_init(&data->lock);
> > +	spin_lock_init(&data->lock);
> >  	INIT_LIST_HEAD(&data->node);
> >
> >  	__set_fault_handler(data, &default_fault_handler);



From Sudeep.KarkadaNagesha at arm.com  Mon Jul 15 06:22:06 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Mon, 15 Jul 2013 11:22:06 +0100
Subject: [RFC PATCH 05/11] drivers/bus: arm-cci: avoid parsing DT for cpu
 device nodes
In-Reply-To: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1373883732-26303-6-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Since the CPU device nodes can be retrieved using arch_of_get_cpu_node,
we can use it to avoid parsing the cpus node searching the cpu nodes and
mapping to logical index.

This patch removes parsing DT for cpu nodes by using arch_of_get_cpu_node.

Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/bus/arm-cci.c | 28 +++++++---------------------
 1 file changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 7332889..8de67c2 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -122,17 +122,8 @@ EXPORT_SYMBOL_GPL(cci_ace_get_port);
 
 static void __init cci_ace_init_ports(void)
 {
-	int port, ac, cpu;
-	u64 hwid;
-	const u32 *cell;
-	struct device_node *cpun, *cpus;
-
-	cpus = of_find_node_by_path("/cpus");
-	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
-		return;
-
-	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
-		ac = of_n_addr_cells(cpus);
+	int port, cpu;
+	struct device_node *cpun;
 
 	/*
 	 * Port index look-up speeds up the function disabling ports by CPU,
@@ -141,18 +132,13 @@ static void __init cci_ace_init_ports(void)
 	 * The stashed index array is initialized for all possible CPUs
 	 * at probe time.
 	 */
-	for_each_child_of_node(cpus, cpun) {
-		if (of_node_cmp(cpun->type, "cpu"))
-			continue;
-		cell = of_get_property(cpun, "reg", NULL);
-		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
-			continue;
-
-		hwid = of_read_number(cell, ac);
-		cpu = get_logical_index(hwid & MPIDR_HWID_BITMASK);
+	for_each_possible_cpu(cpu) {
+		/* too early to use cpu->of_node */
+		cpun = arch_of_get_cpu_node(cpu);
 
-		if (cpu < 0 || !cpu_possible(cpu))
+		if (WARN(!cpun, "Missing cpu device node\n"))
 			continue;
+
 		port = __cci_ace_get_port(cpun, ACE_PORT);
 		if (port < 0)
 			continue;
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 15 06:22:05 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Mon, 15 Jul 2013 11:22:05 +0100
Subject: [RFC PATCH 04/11] ARM: mvebu: remove device tree parsing for cpu nodes
In-Reply-To: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1373883732-26303-5-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Currently set_secondary_cpus_clock assume the CPU logical ordering
and the MPDIR in DT are same, which is incorrect.

Since the CPU device nodes can be retrieved in the logical ordering
using the helper, we can remove the devices tree parsing.

This patch removes DT parsing by making use of arch_of_get_cpu_node.

Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/mach-mvebu/platsmp.c | 52 ++++++++++++++++++++-----------------------
 1 file changed, 24 insertions(+), 28 deletions(-)

diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 93f2f3a..b57af6c 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -23,51 +23,47 @@
 #include <linux/of.h>
 #include <linux/mbus.h>
 #include <asm/cacheflush.h>
+#include <asm/prom.h>
 #include <asm/smp_plat.h>
 #include "common.h"
 #include "armada-370-xp.h"
 #include "pmsu.h"
 #include "coherency.h"
 
+static struct clk *__init get_cpu_clk(int cpu)
+{
+	struct clk *cpu_clk;
+	struct device_node *np = arch_of_get_cpu_node(cpu);
+
+	if (WARN(!np, "missing cpu node\n"))
+		return NULL;
+	cpu_clk = of_clk_get(np, 0);
+	if (WARN_ON(IS_ERR(cpu_clk)))
+		return NULL;
+	return cpu_clk;
+}
+
 void __init set_secondary_cpus_clock(void)
 {
-	int thiscpu;
+	int thiscpu, cpu;
 	unsigned long rate;
-	struct clk *cpu_clk = NULL;
-	struct device_node *np = NULL;
+	struct clk *cpu_clk;
 
 	thiscpu = smp_processor_id();
-	for_each_node_by_type(np, "cpu") {
-		int err;
-		int cpu;
-
-		err = of_property_read_u32(np, "reg", &cpu);
-		if (WARN_ON(err))
-			return;
-
-		if (cpu == thiscpu) {
-			cpu_clk = of_clk_get(np, 0);
-			break;
-		}
-	}
-	if (WARN_ON(IS_ERR(cpu_clk)))
+	cpu_clk = get_cpu_clk(thiscpu);
+	if (!cpu_clk)
 		return;
 	clk_prepare_enable(cpu_clk);
 	rate = clk_get_rate(cpu_clk);
 
 	/* set all the other CPU clk to the same rate than the boot CPU */
-	for_each_node_by_type(np, "cpu") {
-		int err;
-		int cpu;
-
-		err = of_property_read_u32(np, "reg", &cpu);
-		if (WARN_ON(err))
+	for_each_possible_cpu(cpu) {
+		if (cpu == thiscpu)
+			continue;
+		cpu_clk = get_cpu_clk(cpu);
+		if (!cpu_clk)
 			return;
-
-		if (cpu != thiscpu) {
-			cpu_clk = of_clk_get(np, 0);
-			clk_set_rate(cpu_clk, rate);
-		}
+		clk_set_rate(cpu_clk, rate);
 	}
 }
 
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 15 06:22:01 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Mon, 15 Jul 2013 11:22:01 +0100
Subject: [RFC PATCH 00/11] ARM: DT: update cpu device of_node
Message-ID: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

As more and more information is getting added into the cpu node, the number
of drivers needing to parse the device tree for CPU nodes are increasing.
Most of the time, the information needed from the cpu node is preferred
in the logical CPU order. Hence many drivers first parse and search the
CPU node, match them to logical index if needed and then search for the
required property inside a particular cpu node. Some of them assume the
logical and physical CPU ordering to be same which is incorrect.

This patch series initialises the of_node in all the cpu devices when
registering the CPU device.
1. This avoids different drivers having to parse the cpu nodes to obtain
   different attributes like operating points, latency,...etc.
2. This handles different physical and logical cpu ordering which is not
   the case in current code.
3. Also all the cpu nodes will have their of_node initialised correctly.
   Currently different drivers assign them partially and incorrectly.
4. Removes all the reduntant parsing in various drivers.

Regards,
Sudeep

Sudeep KarkadaNagesha (11):
  driver/core: cpu: initialize of_node in cpu's device struture
  ARM: DT/kernel: define ARM specific arch_of_get_cpu_node
  ARM: topology: remove hwid(MPIDR dependency) from cpu_capacity
  ARM: mvebu: remove device tree parsing for cpu nodes
  drivers/bus: arm-cci: avoid parsing DT for cpu device nodes
  cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
  cpufreq: highbank-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: spear-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: arm_big_little: remove device tree parsing for cpu nodes

 arch/arm/include/asm/prom.h         |  1 +
 arch/arm/kernel/devtree.c           | 29 ++++++++++++++++++
 arch/arm/kernel/topology.c          | 61 ++++++++++++-------------------------
 arch/arm/mach-imx/mach-imx6q.c      |  3 +-
 arch/arm/mach-mvebu/platsmp.c       | 52 +++++++++++++++----------------
 drivers/base/cpu.c                  | 19 ++++++++++++
 drivers/bus/arm-cci.c               | 28 +++++------------
 drivers/cpufreq/arm_big_little_dt.c | 39 +++++++++++-------------
 drivers/cpufreq/cpufreq-cpu0.c      | 23 +++-----------
 drivers/cpufreq/highbank-cpufreq.c  | 18 ++++-------
 drivers/cpufreq/imx6q-cpufreq.c     |  4 +--
 drivers/cpufreq/kirkwood-cpufreq.c  | 14 +++++++--
 drivers/cpufreq/spear-cpufreq.c     | 10 +++++-
 13 files changed, 149 insertions(+), 152 deletions(-)

-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 15 06:22:09 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Mon, 15 Jul 2013 11:22:09 +0100
Subject: [RFC PATCH 08/11] cpufreq: highbank-cpufreq: remove device tree
 parsing for cpu nodes
In-Reply-To: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1373883732-26303-9-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/highbank-cpufreq.c | 18 ++++++------------
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/cpufreq/highbank-cpufreq.c b/drivers/cpufreq/highbank-cpufreq.c
index b61b5a3..794123f 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -69,23 +69,17 @@ static int hb_cpufreq_driver_init(void)
 	if (!of_machine_is_compatible("calxeda,highbank"))
 		return -ENODEV;
 
-	for_each_child_of_node(of_find_node_by_path("/cpus"), np)
-		if (of_get_property(np, "operating-points", NULL))
-			break;
-
-	if (!np) {
-		pr_err("failed to find highbank cpufreq node\n");
-		return -ENOENT;
-	}
-
 	cpu_dev = get_cpu_device(0);
 	if (!cpu_dev) {
 		pr_err("failed to get highbank cpufreq device\n");
-		ret = -ENODEV;
-		goto out_put_node;
+		return -ENODEV;
 	}
 
-	cpu_dev->of_node = np;
+	np = of_node_get(cpu_dev->of_node);
+	if (!np) {
+		pr_err("failed to find highbank cpufreq node\n");
+		return -ENOENT;
+	}
 
 	cpu_clk = clk_get(cpu_dev, NULL);
 	if (IS_ERR(cpu_clk)) {
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 15 06:22:03 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Mon, 15 Jul 2013 11:22:03 +0100
Subject: [RFC PATCH 02/11] ARM: DT/kernel: define ARM specific
 arch_of_get_cpu_node
In-Reply-To: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1373883732-26303-3-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

CPU subsystem now provides architecture specific hook to retrieve the
of_node. Most of the cpu DT node parsing and initialisation is contained
in devtree.c. It's better to contain all CPU device node parsing there.

arch_of_get_cpu_node is mainly used to assign cpu->of_node when CPUs get
registered. This patch overrides the defination of the same. It can also
act as the helper function in pre-SMP/early initialisation stages to
retrieve CPU device node pointers in logical ordering.

This mainly helps to avoid replication of the code doing CPU node parsing
and physical(MPIDR) to logical mapping.

Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/include/asm/prom.h |  1 +
 arch/arm/kernel/devtree.c   | 29 +++++++++++++++++++++++++++++
 2 files changed, 30 insertions(+)

diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
index a219227..96f1682 100644
--- a/arch/arm/include/asm/prom.h
+++ b/arch/arm/include/asm/prom.h
@@ -18,6 +18,7 @@
 extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
 extern void arm_dt_memblock_reserve(void);
 extern void __init arm_dt_init_cpu_maps(void);
+extern struct device_node *arch_of_get_cpu_node(int cpu);
 
 #else /* CONFIG_OF */
 
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 5859c8b..3431aa9 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -169,6 +169,35 @@ void __init arm_dt_init_cpu_maps(void)
 	}
 }
 
+struct device_node * __init arch_of_get_cpu_node(int cpu)
+{
+	struct device_node *cpun, *cpus;
+	const u32 *cell;
+	u64 hwid;
+	int ac;
+
+	cpus = of_find_node_by_path("/cpus");
+	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
+		return NULL;
+
+	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
+		ac = of_n_addr_cells(cpus);
+
+	for_each_child_of_node(cpus, cpun) {
+		if (of_node_cmp(cpun->type, "cpu"))
+			continue;
+		cell = of_get_property(cpun, "reg", NULL);
+		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
+			continue;
+
+		hwid = of_read_number(cell, ac);
+		if ((hwid & MPIDR_HWID_BITMASK) == cpu_logical_map(cpu))
+			return cpun;
+	}
+
+	return NULL;
+}
+
 /**
  * setup_machine_fdt - Machine setup when an dtb was passed to the kernel
  * @dt_phys: physical address of dt blob
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 15 06:22:07 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Mon, 15 Jul 2013 11:22:07 +0100
Subject: [RFC PATCH 06/11] cpufreq: imx6q-cpufreq: remove device tree parsing
 for cpu nodes
In-Reply-To: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1373883732-26303-7-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/mach-imx/mach-imx6q.c  | 3 +--
 drivers/cpufreq/imx6q-cpufreq.c | 4 +---
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 7be13f8..a02f275 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -254,13 +254,12 @@ static void __init imx6q_opp_init(struct device *cpu_dev)
 {
 	struct device_node *np;
 
-	np = of_find_node_by_path("/cpus/cpu at 0");
+	np = of_node_get(cpu_dev->of_node);
 	if (!np) {
 		pr_warn("failed to find cpu0 node\n");
 		return;
 	}
 
-	cpu_dev->of_node = np;
 	if (of_init_opp_table(cpu_dev)) {
 		pr_warn("failed to init OPP table\n");
 		goto put_node;
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index e37cdae..b16632b 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -221,14 +221,12 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev)
 
 	cpu_dev = &pdev->dev;
 
-	np = of_find_node_by_path("/cpus/cpu at 0");
+	np = of_node_get(cpu_dev->of_node);
 	if (!np) {
 		dev_err(cpu_dev, "failed to find cpu0 node\n");
 		return -ENOENT;
 	}
 
-	cpu_dev->of_node = np;
-
 	arm_clk = devm_clk_get(cpu_dev, "arm");
 	pll1_sys_clk = devm_clk_get(cpu_dev, "pll1_sys");
 	pll1_sw_clk = devm_clk_get(cpu_dev, "pll1_sw");
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 15 06:22:02 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Mon, 15 Jul 2013 11:22:02 +0100
Subject: [RFC PATCH 01/11] driver/core: cpu: initialize of_node in cpu's
 device struture
In-Reply-To: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1373883732-26303-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

CPUs are also registered as devices but the of_node in these cpu
devices are not initialized. Currently different drivers requiring
to access cpu device node are parsing the nodes themselves and
initialising the of_node in cpu device.

The of_node in all the cpu devices properly needs to be initialized
properly and at one place. The best place to update this is CPU
subsystem driver when registering the cpu devices.

This patch introduces a new function arch_of_get_cpu_node and uses it
to assign of_node. The definition of this function can be overridden
by architecture specific implementation.

Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/base/cpu.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index a16d20e..4b3047a 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -28,6 +28,24 @@ static int cpu_subsys_match(struct device *dev, struct device_driver *drv)
 	return 0;
 }
 
+/**
+ * arch_of_get_cpu_node - Get device node associated with the given logical CPU
+ * @cpu: CPU number(logical index) for which device node is required
+ *
+ * The only purpose of this function is to retrieve the device node for the
+ * given logical CPU index. It should be used to intialise the of_node in
+ * cpu device. Once of_node in cpu device is populated, all the further
+ * references can use that instead.
+ *
+ * CPU logical to physical index mapping is architecure specific and is built
+ * before booting secondary cores. Hence this function is marked __weak and
+ * can be overridden by architecture specific implementation.
+ */
+struct device_node * __weak arch_of_get_cpu_node(int cpu)
+{
+	return NULL;
+}
+
 #ifdef CONFIG_HOTPLUG_CPU
 static void change_cpu_under_node(struct cpu *cpu,
 			unsigned int from_nid, unsigned int to_nid)
@@ -289,6 +307,7 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
 	cpu->dev.release = cpu_device_release;
 	cpu->dev.offline_disabled = !cpu->hotpluggable;
 	cpu->dev.offline = !cpu_online(num);
+	cpu->dev.of_node = arch_of_get_cpu_node(num);
 #ifdef CONFIG_ARCH_HAS_CPU_AUTOPROBE
 	cpu->dev.bus->uevent = arch_cpu_uevent;
 #endif
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 15 06:22:08 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Mon, 15 Jul 2013 11:22:08 +0100
Subject: [RFC PATCH 07/11] cpufreq: cpufreq-cpu0: remove device tree parsing
 for cpu nodes
In-Reply-To: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1373883732-26303-8-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/cpufreq-cpu0.c | 23 ++++-------------------
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..5b05c26 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -174,29 +174,17 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
 
 static int cpu0_cpufreq_probe(struct platform_device *pdev)
 {
-	struct device_node *np, *parent;
+	struct device_node *np;
 	int ret;
 
-	parent = of_find_node_by_path("/cpus");
-	if (!parent) {
-		pr_err("failed to find OF /cpus\n");
-		return -ENOENT;
-	}
-
-	for_each_child_of_node(parent, np) {
-		if (of_get_property(np, "operating-points", NULL))
-			break;
-	}
+	cpu_dev = &pdev->dev;
 
+	np = of_node_get(cpu_dev->of_node);
 	if (!np) {
 		pr_err("failed to find cpu0 node\n");
-		ret = -ENOENT;
-		goto out_put_parent;
+		return -ENOENT;
 	}
 
-	cpu_dev = &pdev->dev;
-	cpu_dev->of_node = np;
-
 	cpu_reg = devm_regulator_get(cpu_dev, "cpu0");
 	if (IS_ERR(cpu_reg)) {
 		/*
@@ -269,15 +257,12 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
 	}
 
 	of_node_put(np);
-	of_node_put(parent);
 	return 0;
 
 out_free_table:
 	opp_free_cpufreq_table(cpu_dev, &freq_table);
 out_put_node:
 	of_node_put(np);
-out_put_parent:
-	of_node_put(parent);
 	return ret;
 }
 
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 15 06:22:04 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Mon, 15 Jul 2013 11:22:04 +0100
Subject: [RFC PATCH 03/11] ARM: topology: remove hwid/MPIDR dependency from
 cpu_capacity
In-Reply-To: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1373883732-26303-4-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Currently the topology code computes cpu capacity and stores it in
the list along with hwid(which is MPIDR) as it parses the CPU nodes
in the device tree. This is required as it needs to be mapped to the
logical CPU later.

Since the CPU device nodes can be retrieved in the logical ordering
using helpers, its possible to store cpu_capacity also in logical
ordering and avoid storing hwid for each entry.

This patch removes hwid by making use of arch_of_get_cpu_node.

Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/kernel/topology.c | 61 +++++++++++++++-------------------------------
 1 file changed, 19 insertions(+), 42 deletions(-)

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index c5a5954..c1a8f05 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -74,12 +74,8 @@ struct cpu_efficiency table_efficiency[] = {
 	{NULL, },
 };
 
-struct cpu_capacity {
-	unsigned long hwid;
-	unsigned long capacity;
-};
-
-struct cpu_capacity *cpu_capacity;
+unsigned long *__cpu_capacity;
+#define cpu_capacity(cpu)	__cpu_capacity[cpu]
 
 unsigned long middle_capacity = 1;
 
@@ -100,15 +96,19 @@ static void __init parse_dt_topology(void)
 	unsigned long capacity = 0;
 	int alloc_size, cpu = 0;
 
-	alloc_size = nr_cpu_ids * sizeof(struct cpu_capacity);
-	cpu_capacity = kzalloc(alloc_size, GFP_NOWAIT);
+	alloc_size = nr_cpu_ids * sizeof(*__cpu_capacity);
+	__cpu_capacity = kzalloc(alloc_size, GFP_NOWAIT);
 
-	while ((cn = of_find_node_by_type(cn, "cpu"))) {
-		const u32 *rate, *reg;
+	for_each_possible_cpu(cpu) {
+		const u32 *rate;
 		int len;
 
-		if (cpu >= num_possible_cpus())
-			break;
+		/* too early to use cpu->of_node */
+		cn = arch_of_get_cpu_node(cpu);
+		if (!cn) {
+			pr_err("missing device node for CPU %d\n", cpu);
+			continue;
+		}
 
 		for (cpu_eff = table_efficiency; cpu_eff->compatible; cpu_eff++)
 			if (of_device_is_compatible(cn, cpu_eff->compatible))
@@ -124,12 +124,6 @@ static void __init parse_dt_topology(void)
 			continue;
 		}
 
-		reg = of_get_property(cn, "reg", &len);
-		if (!reg || len != 4) {
-			pr_err("%s missing reg property\n", cn->full_name);
-			continue;
-		}
-
 		capacity = ((be32_to_cpup(rate)) >> 20) * cpu_eff->efficiency;
 
 		/* Save min capacity of the system */
@@ -140,13 +134,9 @@ static void __init parse_dt_topology(void)
 		if (capacity > max_capacity)
 			max_capacity = capacity;
 
-		cpu_capacity[cpu].capacity = capacity;
-		cpu_capacity[cpu++].hwid = be32_to_cpup(reg);
+		cpu_capacity(cpu) = capacity;
 	}
 
-	if (cpu < num_possible_cpus())
-		cpu_capacity[cpu].hwid = (unsigned long)(-1);
-
 	/* If min and max capacities are equals, we bypass the update of the
 	 * cpu_scale because all CPUs have the same capacity. Otherwise, we
 	 * compute a middle_capacity factor that will ensure that the capacity
@@ -154,9 +144,7 @@ static void __init parse_dt_topology(void)
 	 * SCHED_POWER_SCALE, which is the default value, but with the
 	 * constraint explained near table_efficiency[].
 	 */
-	if (min_capacity == max_capacity)
-		cpu_capacity[0].hwid = (unsigned long)(-1);
-	else if (4*max_capacity < (3*(max_capacity + min_capacity)))
+	if (4*max_capacity < (3*(max_capacity + min_capacity)))
 		middle_capacity = (min_capacity + max_capacity)
 				>> (SCHED_POWER_SHIFT+1);
 	else
@@ -170,23 +158,12 @@ static void __init parse_dt_topology(void)
  * boot. The update of all CPUs is in O(n^2) for heteregeneous system but the
  * function returns directly for SMP system.
  */
-void update_cpu_power(unsigned int cpu, unsigned long hwid)
+void update_cpu_power(unsigned int cpu)
 {
-	unsigned int idx = 0;
-
-	/* look for the cpu's hwid in the cpu capacity table */
-	for (idx = 0; idx < num_possible_cpus(); idx++) {
-		if (cpu_capacity[idx].hwid == hwid)
-			break;
-
-		if (cpu_capacity[idx].hwid == -1)
-			return;
-	}
-
-	if (idx == num_possible_cpus())
+	if (!cpu_capacity(cpu))
 		return;
 
-	set_power_scale(cpu, cpu_capacity[idx].capacity / middle_capacity);
+	set_power_scale(cpu, cpu_capacity(cpu) / middle_capacity);
 
 	printk(KERN_INFO "CPU%u: update cpu_power %lu\n",
 		cpu, arch_scale_freq_power(NULL, cpu));
@@ -194,7 +171,7 @@ void update_cpu_power(unsigned int cpu, unsigned long hwid)
 
 #else
 static inline void parse_dt_topology(void) {}
-static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {}
+static inline void update_cpu_power(unsigned int cpuid) {}
 #endif
 
  /*
@@ -281,7 +258,7 @@ void store_cpu_topology(unsigned int cpuid)
 
 	update_siblings_masks(cpuid);
 
-	update_cpu_power(cpuid, mpidr & MPIDR_HWID_BITMASK);
+	update_cpu_power(cpuid);
 
 	printk(KERN_INFO "CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n",
 		cpuid, cpu_topology[cpuid].thread_id,
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 15 06:22:11 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Mon, 15 Jul 2013 11:22:11 +0100
Subject: [RFC PATCH 10/11] cpufreq: kirkwood-cpufreq: remove device tree
 parsing for cpu nodes
In-Reply-To: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1373883732-26303-11-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/kirkwood-cpufreq.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
index c233ea6..18aa3eb 100644
--- a/drivers/cpufreq/kirkwood-cpufreq.c
+++ b/drivers/cpufreq/kirkwood-cpufreq.c
@@ -13,6 +13,7 @@
 #include <linux/module.h>
 #include <linux/clk.h>
 #include <linux/clk-provider.h>
+#include <linux/cpu.h>
 #include <linux/cpufreq.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
@@ -165,6 +166,7 @@ static struct cpufreq_driver kirkwood_cpufreq_driver = {
 static int kirkwood_cpufreq_probe(struct platform_device *pdev)
 {
 	struct device_node *np;
+	struct device *cpu_dev;
 	struct resource *res;
 	int err;
 
@@ -175,9 +177,17 @@ static int kirkwood_cpufreq_probe(struct platform_device *pdev)
 	if (IS_ERR(priv.base))
 		return PTR_ERR(priv.base);
 
-	np = of_find_node_by_path("/cpus/cpu at 0");
-	if (!np)
+	cpu_dev = get_cpu_device(0);
+	if (!cpu_dev) {
+		dev_err(&pdev->dev, "failed to get cpu device\n");
 		return -ENODEV;
+	}
+
+	np = of_node_get(cpu_dev->of_node);
+	if (!np) {
+		dev_err(&pdev->dev, "failed to get cpu device node\n");
+		return -ENODEV;
+	}
 
 	priv.cpu_clk = of_clk_get_by_name(np, "cpu_clk");
 	if (IS_ERR(priv.cpu_clk)) {
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 15 06:22:10 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Mon, 15 Jul 2013 11:22:10 +0100
Subject: [RFC PATCH 09/11] cpufreq: spear-cpufreq: remove device tree parsing
 for cpu nodes
In-Reply-To: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1373883732-26303-10-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/spear-cpufreq.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/spear-cpufreq.c b/drivers/cpufreq/spear-cpufreq.c
index c3efa7f..eb73c47 100644
--- a/drivers/cpufreq/spear-cpufreq.c
+++ b/drivers/cpufreq/spear-cpufreq.c
@@ -14,6 +14,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include <linux/clk.h>
+#include <linux/cpu.h>
 #include <linux/cpufreq.h>
 #include <linux/err.h>
 #include <linux/init.h>
@@ -218,12 +219,19 @@ static struct cpufreq_driver spear_cpufreq_driver = {
 static int spear_cpufreq_driver_init(void)
 {
 	struct device_node *np;
+	struct device *cpu_dev;
 	const struct property *prop;
 	struct cpufreq_frequency_table *freq_tbl;
 	const __be32 *val;
 	int cnt, i, ret;
 
-	np = of_find_node_by_path("/cpus/cpu at 0");
+	cpu_dev = get_cpu_device(0);
+	if (!cpu_dev) {
+		pr_err("failed to get cpu device\n");
+		return -ENODEV;
+	}
+
+	np = of_node_get(cpu_dev->of_node);
 	if (!np) {
 		pr_err("No cpu node found");
 		return -ENODEV;
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 15 06:22:12 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Mon, 15 Jul 2013 11:22:12 +0100
Subject: [RFC PATCH 11/11] cpufreq: arm_big_little: remove device tree parsing
 for cpu nodes
In-Reply-To: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1373883732-26303-12-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/arm_big_little_dt.c | 39 ++++++++++++++++---------------------
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/drivers/cpufreq/arm_big_little_dt.c b/drivers/cpufreq/arm_big_little_dt.c
index fd9e3ea..d2648d1 100644
--- a/drivers/cpufreq/arm_big_little_dt.c
+++ b/drivers/cpufreq/arm_big_little_dt.c
@@ -34,27 +34,19 @@
 /* get cpu node with valid operating-points */
 static struct device_node *get_cpu_node_with_valid_op(int cpu)
 {
-	struct device_node *np = NULL, *parent;
-	int count = 0;
+	struct device *cpu_dev = get_cpu_device(cpu);
+	struct device_node *np;
 
-	parent = of_find_node_by_path("/cpus");
-	if (!parent) {
-		pr_err("failed to find OF /cpus\n");
+	if (!cpu_dev) {
+		pr_err("failed to get cpu device\n");
 		return NULL;
 	}
-
-	for_each_child_of_node(parent, np) {
-		if (count++ != cpu)
-			continue;
-		if (!of_get_property(np, "operating-points", NULL)) {
-			of_node_put(np);
-			np = NULL;
-		}
-
-		break;
+	np = of_node_get(cpu_dev->of_node);
+	if (!of_get_property(np, "operating-points", NULL)) {
+		of_node_put(np);
+		np = NULL;
 	}
 
-	of_node_put(parent);
 	return np;
 }
 
@@ -63,11 +55,12 @@ static int dt_init_opp_table(struct device *cpu_dev)
 	struct device_node *np;
 	int ret;
 
-	np = get_cpu_node_with_valid_op(cpu_dev->id);
-	if (!np)
-		return -ENODATA;
+	np = of_node_get(cpu_dev->of_node);
+	if (!np) {
+		pr_err("failed to find cpu%d node\n", cpu_dev->id);
+		return -ENOENT;
+	}
 
-	cpu_dev->of_node = np;
 	ret = of_init_opp_table(cpu_dev);
 	of_node_put(np);
 
@@ -79,9 +72,11 @@ static int dt_get_transition_latency(struct device *cpu_dev)
 	struct device_node *np;
 	u32 transition_latency = CPUFREQ_ETERNAL;
 
-	np = get_cpu_node_with_valid_op(cpu_dev->id);
-	if (!np)
+	np = of_node_get(cpu_dev->of_node);
+	if (!np) {
+		pr_info("Failed to find cpu node. Use CPUFREQ_ETERNAL transition latency\n");
 		return CPUFREQ_ETERNAL;
+	}
 
 	of_property_read_u32(np, "clock-latency", &transition_latency);
 	of_node_put(np);
-- 
1.8.1.2




From ben.dooks at codethink.co.uk  Mon Jul 15 06:26:09 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 15 Jul 2013 11:26:09 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <20130715103658.068ac6b7@skate>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate> <51DFEF75.8080600@codethink.co.uk>
 <20130714215325.GB7382@mudshark.cambridge.arm.com>
 <51E3ACD0.8040209@codethink.co.uk> <20130715103658.068ac6b7@skate>
Message-ID: <51E3CE41.5010807@codethink.co.uk>

On 15/07/13 09:36, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:
>
>>> As for building a Thumb-2 kernel; just enable the option in menuconfig and
>>> you're done. The compiler should "do the right thing".
>>
>> I can build it, I just don't have the time and hardware to give it a
>> test at the moment. However it seems that changing to using 'rev16'
>> instead of 'rev'. I will make the necessary changes and get this ready
>> to go.
>
> I am willing to give some testing to early patches, if needed. Do not
> hesitate to send me things to test.

I've pushed out two new branches on git.baserock.org/delta/linux.git
as:
	baserock/311/be/core-v2
	baserock/311/be/atags-v2

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From vinod.koul at intel.com  Mon Jul 15 06:01:31 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 15 Jul 2013 15:31:31 +0530
Subject: [PATCH] ARM: dma: imx: Fix deadlock bug
In-Reply-To: <1373876039.3897.9.camel@mars>
References: <1370724988-16426-1-git-send-email-shc_work@mail.ru>
 <20130608211557.GK18614@n2100.arm.linux.org.uk>
 <20130612030321.GA4107@intel.com> <1373876039.3897.9.camel@mars>
Message-ID: <20130715100131.GR16653@intel.com>

On Mon, Jul 15, 2013 at 10:13:59AM +0200, Christoph Fritz wrote:
> Hi,
> 
>  I'm the initiator of the bug-report[1] ("ARM: imx27: dmaengine:
> imx-dma: SD-Card: copy hangs forever") which led to this thread.
> 
> Are there any updates yet?
I should have a fix for you pretty soon. Obviosuly it would be untested on my
part as I lack the hardware

~Vinod


From mark.rutland at arm.com  Mon Jul 15 06:47:07 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 15 Jul 2013 11:47:07 +0100
Subject: [RFC PATCH 0/5] arm64: initial CPU_HOTPLUG support
In-Reply-To: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
References: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
Message-ID: <20130715104706.GA14505@e106331-lin.cambridge.arm.com>

Hi Catalin, Paul,

I've realised these patches are going to conflict with Paul's "arm64:
delete __cpuinit usage from all users", so I'd like to rebase this
series atop of it (removing my cpuinit additions as I do so).

Catalin, would you be happy to create a stable branch at some point soon
with Paul's arm64 patch for me to work atop of?

Thanks,
Mark.

On Wed, Jul 10, 2013 at 11:11:14PM +0100, Mark Rutland wrote:
> The following patches add basic CPU_HOTPLUG support to arm64, which
> combined with appropriate firmware (e.g. [1]) can be used to power CPUs
> up and down dynamically. From discussions at connect it seemed that
> several people were interested in working in this area, so I thought I'd
> make my current implementation public now that I've managed to regain
> access to my inbox.
> 
> I've tested this series with the bootwrapper PSCI implementation I've
> placed on linux-arm.org [1] and a modified foundation model dts with a
> psci node and each CPU's enable-method set to "psci", using a shell
> while repeatedly cycling all cpus off and on:
> 
> for C in $(seq 0 3); do
> 	./cyclichotplug.sh $C >/dev/null 2>&1 &
> done
> 
> ---->8----
> #!/bin/sh
> # cyclichotplug.sh
> 
> CPU=$1;
> 
> if [ -z "$CPU" ]; then
> 	printf "Usage: $0 <cpu id>\n";
> 	exit 1;
> fi
> 
> ONLINEFILE=/sys/devices/system/cpu/cpu$CPU/online;
> 
> while true; do
> 	echo 0 > $ONLINEFILE;
> 	echo 1 > $ONLINEFILE;
> done
> ---->8----
> 
> Patches are based on v3.10.
> 
> Thanks,
> Mark.
> 
> [1] http://linux-arm.org/git?p=boot-wrapper-aarch64.git;a=shortlog;h=refs/tags/simple-psci
> 
> Mark Rutland (5):
>   arm64: reorganise smp_enable_ops
>   arm64: factor out spin-table boot method
>   arm64: read enable-method for CPU0
>   arm64: add CPU_HOTPLUG infrastructure
>   arm64: add PSCI CPU_OFF-based hotplug support
> 
>  arch/arm64/Kconfig                 |    7 ++
>  arch/arm64/include/asm/irq.h       |    1 +
>  arch/arm64/include/asm/smp.h       |   37 +++++--
>  arch/arm64/kernel/cputable.c       |    2 +-
>  arch/arm64/kernel/head.S           |   12 +-
>  arch/arm64/kernel/irq.c            |   61 ++++++++++
>  arch/arm64/kernel/process.c        |    7 ++
>  arch/arm64/kernel/smp.c            |  215 ++++++++++++++++++++++--------------
>  arch/arm64/kernel/smp_psci.c       |   54 +++++++--
>  arch/arm64/kernel/smp_spin_table.c |   85 +++++++++++++-
>  arch/arm64/kernel/vmlinux.lds.S    |    1 -
>  11 files changed, 375 insertions(+), 107 deletions(-)
> 
> -- 
> 1.7.9.5
> 


From b32955 at freescale.com  Mon Jul 15 06:53:13 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Mon, 15 Jul 2013 18:53:13 +0800
Subject: [PATCH 2/3] serial: mxs: enable the DMA only when the rts/cts
 is enabled
In-Reply-To: <20130715090755.GN12139@pengutronix.de>
References: <1373857736-30108-1-git-send-email-b32955@freescale.com>
 <1373857736-30108-2-git-send-email-b32955@freescale.com>
 <20130715082716.GM12139@pengutronix.de> <51E3B5B5.1030706@freescale.com>
 <20130715090755.GN12139@pengutronix.de>
Message-ID: <51E3D499.3060902@freescale.com>

? 2013?07?15? 17:07, Uwe Kleine-K?nig ??:
> Hello,
>
> On Mon, Jul 15, 2013 at 04:41:25PM +0800, Huang Shijie wrote:
>> ? 2013?07?15? 16:27, Uwe Kleine-K?nig ??:
>>> do you want to say that the driver fails to only enable DMA when RTS/CTS
>>> are available; or that today the driver can handle DMA just fine even
>>> without RTS/CTS? I interpret your commit log as the latter, your patch
>>> implements the former however.
>> in the mxs-auart, if the RTS/CTS is not invalid, the DMA should be
>> not enabled.
>>
>> But current code lost the limit, a uart without the RTS/CTS may also
>> enables the DMA in which case the uart
>> may does not run or run in a abnormal way.
> So this sounds like a fix that should go into stable and so preferably
> should be the first patch in your series.
This patch depends on the first patch. :)
> Something like:
>
> 	serial: mxs-auart: DMA unreliable without RTS/CTS
>
> 	According to [add some document name here] DMA doesn't work
> 	reliable without hardware handshaking. So make DMA dependant on
> 	a newly introdused property "fsl,uart-has-rtscts".
>
> 	Cc: stable at kernel.org # [first affected version]
>
> The flag is only used to decide if dma should be enabled. So I think an
> in-code comment would be nice, too. Is it still correct to set
ok.
> AUART_CTRL2_RTSEN and AUART_CTRL2_RTS and read AUART_STAT_CTS when
> fsl,uart-has-rtscts is not provided?
i think it's correct. (if i have a imx28-evk board, i can test it.)

If you enable the RTS/CTS from the application, the 
tty_port_cts_enabled() will be true.
we will set the AUART_CTRL2_RTSEN in the end when the 
"fsl,uart-has-rtscts" is enabled.


> (BTW, mxs_auart_set_mctrl has:
>
> 	u32 ctrl = readl(u->membase + AUART_CTRL2);
>
> 	ctrl&= ~(AUART_CTRL2_RTSEN | AUART_CTRL2_RTS);
>          if (mctrl&  TIOCM_RTS) {
>                  if (tty_port_cts_enabled(&u->state->port))
>                          ctrl |= AUART_CTRL2_RTSEN;
>                  else
>                          ctrl |= AUART_CTRL2_RTS;
>          }
>
> 	s->ctrl = mctrl;
>
> A comment for the diligent reader about the difference between RTSEN and
> RTS would be nice. Also I wonder if shadowing mctrl is sensible and used
Please see the spec about the RTSEN and RTS.

RTSEN enable the flow control by the hardware;
RTS enable the flow control by the software.

thanks
Huang Shijie
> correctly here.)
>
> Best regards
> Uwe
>




From oleksandr.kozaruk at ti.com  Mon Jul 15 07:09:40 2013
From: oleksandr.kozaruk at ti.com (Kozaruk, Oleksandr)
Date: Mon, 15 Jul 2013 11:09:40 +0000
Subject: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <51E05F6C.1060506@metafoo.de>
References: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1373613482-28390-3-git-send-email-oleksandr.kozaruk@ti.com>,
 <51E05F6C.1060506@metafoo.de>
Message-ID: <2A7ABDFCE21540479A5AEB0244A684D5E3D067@DNCE04.ent.ti.com>

Hello Lars-Peter,
Thank you for the review.

>> diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
>> new file mode 100644
>> index 0000000..6ceb789
>> --- /dev/null
>> +++ b/drivers/iio/adc/twl6030-gpadc.c
>> @@ -0,0 +1,1019 @@
>[...]
>> +static u8 twl6032_channel_to_reg(int channel)
>> +{
>> +     return TWL6032_GPADC_GPCH0_LSB;
>
>There is more than one channel, isn't there?
Yes. But for twl6032 channel of interest is chosen first. When the conversion
is ready tre result is available in GPCH0_LSB/GPCH1_MSB for any cosen
channel. For twl6030 there are as many result register pairs as many of
channels.

>> +     ret = devm_request_threaded_irq(dev, irq, NULL,
>> +                                     twl6030_gpadc_irq_handler,
>> +                                     IRQF_ONESHOT, "twl6030_gpadc", gpadc);
>
>You access memory in the interrupt handler which is freed before the interrupt
>handler is freed.
Thanks for pointing this. devm_* will free memory for irq after the driver
is removed and memory for the device is freed. I took me awhile to understand
this. Is there going to be something like devm_iio_device_alloc? whould it be helpfull?

From pullip.cho at samsung.com  Mon Jul 15 07:21:56 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Mon, 15 Jul 2013 20:21:56 +0900
Subject: [PATCH v7 3/9] iommu/exynos: fix page table maintenance
In-Reply-To: <1933986.4vddYccClk@amdc1032>
References: <002b01ce797b$44d4ad10$ce7e0730$@samsung.com>
 <1933986.4vddYccClk@amdc1032>
Message-ID: <009a01ce814d$840b48c0$8c21da40$@samsung.com>

> -----Original Message-----
> From: Bartlomiej Zolnierkiewicz [mailto:b.zolnierkie at samsung.com]
> Sent: Friday, July 12, 2013 2:38 AM
> 
> Hi,
> 
> Some minor nitpicks below.
> 
> On Friday, July 05, 2013 09:29:18 PM Cho KyongHo wrote:
> > This prevents allocating lv2 page table for the lv1 page table entry
> > that already has 1MB page mapping. In addition some BUG_ON() is
> > changed to WARN_ON().
> >
> > Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> > ---
> >  drivers/iommu/exynos-iommu.c |   34 ++++++++++++++++++++++++++--------
> >  1 files changed, 26 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> > index e3be3e5..2bfe9fa 100644
> > --- a/drivers/iommu/exynos-iommu.c
> > +++ b/drivers/iommu/exynos-iommu.c
> > @@ -862,12 +862,14 @@ static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long iova,
> >  		pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
> >  		BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
> >  		if (!pent)
> > -			return NULL;
> > +			return ERR_PTR(-ENOMEM);
> >
> >  		*sent = mk_lv1ent_page(__pa(pent));
> >  		*pgcounter = NUM_LV2ENTRIES;
> >  		pgtable_flush(pent, pent + NUM_LV2ENTRIES);
> >  		pgtable_flush(sent, sent + 1);
> > +	} else if (lv1ent_section(sent)) {
> > +		return ERR_PTR(-EADDRINUSE);
> >  	}
> >
> >  	return page_entry(sent, iova);
> > @@ -944,16 +946,16 @@ static int exynos_iommu_map(struct iommu_domain *domain, unsigned long iova,
> >  		pent = alloc_lv2entry(entry, iova,
> >  					&priv->lv2entcnt[lv1ent_offset(iova)]);
> >
> > -		if (!pent)
> > -			ret = -ENOMEM;
> > +		if (IS_ERR(pent))
> > +			ret = PTR_ERR(pent);
> >  		else
> >  			ret = lv2set_page(pent, paddr, size,
> >  					&priv->lv2entcnt[lv1ent_offset(iova)]);
> >  	}
> >
> >  	if (ret) {
> > -		pr_debug("%s: Failed to map iova 0x%lx/0x%x bytes\n",
> > -							__func__, iova, size);
> > +		pr_err("%s: Failed(%d) to map iova 0x%#x bytes @ %#lx\n",
> > +						__func__, ret, size, iova);
> >  	}
> 
> Intendation is a bit weird, it should be more like:
> 
> 		pr_err("%s: Failed(%d) to map iova 0x%#x bytes @ %#lx\n",
> 			__func__, ret, size, iova);
> 
> to be consistent with the rest of the driver.
> 
> You could have also removed superfluous braces while at it.
> 

Do you think it is better to read the code?
Hmm, I think it is better too.
Thanks.

> >  	spin_unlock_irqrestore(&priv->pgtablelock, flags);
> > @@ -968,6 +970,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
> >  	struct sysmmu_drvdata *data;
> >  	unsigned long flags;
> >  	unsigned long *ent;
> > +	size_t err_page;
> >
> >  	BUG_ON(priv->pgtable == NULL);
> >
> > @@ -976,7 +979,8 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
> >  	ent = section_entry(priv->pgtable, iova);
> >
> >  	if (lv1ent_section(ent)) {
> > -		BUG_ON(size < SECT_SIZE);
> > +		if (WARN_ON(size < SECT_SIZE))
> > +			goto err;
> >
> >  		*ent = 0;
> >  		pgtable_flush(ent, ent + 1);
> > @@ -1008,7 +1012,8 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
> >  	}
> >
> >  	/* lv1ent_large(ent) == true here */
> > -	BUG_ON(size < LPAGE_SIZE);
> > +	if (WARN_ON(size < LPAGE_SIZE))
> > +		goto err;
> >
> >  	memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
> >  	pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
> > @@ -1023,8 +1028,21 @@ done:
> >  		sysmmu_tlb_invalidate_entry(data->dev, iova);
> >  	spin_unlock_irqrestore(&priv->lock, flags);
> >
> > -
> >  	return size;
> > +err:
> > +	spin_unlock_irqrestore(&priv->pgtablelock, flags);
> > +
> > +	err_page = (
> > +		((unsigned long)ent - (unsigned long)priv->pgtable)
> > +			< (NUM_LV1ENTRIES * sizeof(long))
> 
> Maybe you could add LV1TABLE_SIZE define and use it here (there is
> already a LV2TABLE_SIZE define)?

Yes. But, LV2TABLE_SIZE is used in more places than one.
I do not feel that it is needed to define LV1TABLE_SIZE for the single line.

> 
> > +			   ) ?  SECT_SIZE : LPAGE_SIZE;
> 
> It also seems that err_page should be of unsigned long type, no need
> to make it size_t one.
> 

err_page is the page size.
I agree that the name of the variable is not proper to indicate size.

> The above code is quite ugly currently, it could be rewritten into
> something prettier, i.e.:
> 
> 	err_page = (unsigned long)ent - (unsigned long)priv->pgtable;
> 	err_page = (err_page < LV1TABLE_SIZE) ? SECT_SIZE : LPAGE_SIZE;
> 
Ah, this is the reason that you addresses err_page could be unsigned long.
I agree that it is prettier.

> > +	pr_err("%s: Failed due to size(%#lx) @ %#x is"\
> > +		" smaller than page size %#x\n",
> > +		__func__, iova, size, err_page);
> 
> Aren't iova and size arguments interchanged here?
Oh, it is my mistake.

It will should be fixed in the next patchset with the change in
calculation of err_page.
> 
> > +
> > +	       return 0;
> 
> There is an intendation issue here (extra whitespaces).

Yes. Thanks.

> 
> > +
> >  }
> >
> >  static phys_addr_t exynos_iommu_iova_to_phys(struct iommu_domain *domain,
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics

Thank you.

Cho KyongHo.



From pullip.cho at samsung.com  Mon Jul 15 07:24:29 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Mon, 15 Jul 2013 20:24:29 +0900
Subject: [PATCH v7 00/12] iommu/exynos: Fixes and Enhancements of System
 MMU driver with DT
In-Reply-To: <CANEJEGvajhgzUPG6ppbjwBb4-9TdU9em3T_SejBpz8NCjGHYTQ@mail.gmail.com>
References: <002801ce797b$3d2fbc80$b78f3580$@samsung.com>
 <CANEJEGvajhgzUPG6ppbjwBb4-9TdU9em3T_SejBpz8NCjGHYTQ@mail.gmail.com>
Message-ID: <009b01ce814d$def7a6c0$9ce6f440$@samsung.com>

> From: grundler at google.com [mailto:grundler at google.com] On Behalf Of Grant Grundler
> Sent: Friday, July 12, 2013 2:23 AM
> 
> On Fri, Jul 5, 2013 at 5:29 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> > The current exynos-iommu(System MMU) driver does not work autonomously
> > since it is lack of support for power management of peripheral blocks.
> ...
> > Patch summary:
> > [PATCH v7 1/9] iommu/exynos: do not include removed header
> > [PATCH v7 2/9] iommu/exynos: add missing cache flush for removed page table entries
> > [PATCH v7 3/9] iommu/exynos: fix page table maintenance
> > [PATCH v7 4/9] iommu/exynos: allocate lv2 page table from own slab
> > [PATCH v7 5/9] iommu/exynos: change rwlock to spinlock
> > [PATCH v7 6/9] clk: exynos5250: add gate clock descriptions of System MMU
> > [PATCH v7 7/9] ARM: dts: Add description of System MMU of Exynos SoCs
> > [PATCH v7 8/9] iommu/exynos: support for device tree
> > [PATCH v7 9/9] iommu/exynos: add bus notifier for registering System MMU
> 
> Cho,
> Of the above patches, nearly all have been applied to chromeos-3.8
> (kernel-next git tree) by Doug Anderson and others.
> 
> AFAICT, the only ones not applied are:
>    [v7,3/9] iommu/exynos: fix page table maintenance
>    [v7,6/9] clk: exynos5250: add gate clock descriptions of System MMU
> (conflicts in this one)
>    [v7,7/9] ARM: dts: Add description of System MMU of Exynos SoCs
> (depends on 6/9)
> 
> We also already have parts of:
>    [v7,9/9] iommu/exynos: add bus notifier for registering System MMU
> 
> Some of those are being further discussed but I've lost track now
> exactly which ones.
> 
> I'm telling you about chromeos-3.8 status since the adopted changes
> have been reviewed (by me and others) are being tested manually here
> on several different Samsung Exynos platforms (including 5250 which is
> our "snow" platform). Not sure how you should to mark those patches
> since they aren't identical to your changes (which apply to post 3.10
> kernels, not 3.8).  You might consider splitting those patches out
> from the 4 I've listed above to get that series accepted upstream
> since the additional review/testing should provide some confidence
> those patches are good.
> 

I understand what you are concerning about.
Have you applied v6 patchset?

I will try to split the patches and make the changes from v6
on top of the v6 patcheset.

> cheers,
> grant

Thank you.

Cho KyonogHo.



From broonie at kernel.org  Mon Jul 15 07:25:03 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 15 Jul 2013 12:25:03 +0100
Subject: [PATCH] ARM: EXYNOS: remove references to non-DT SoCs
In-Reply-To: <1373807896.1370.43.camel@x61.thuisdomein>
References: <1373804812.1370.23.camel@x61.thuisdomein>
 <20130714124538.GA11538@sirena.org.uk>
 <1373807896.1370.43.camel@x61.thuisdomein>
Message-ID: <20130715112503.GB11538@sirena.org.uk>

On Sun, Jul 14, 2013 at 03:18:16PM +0200, Paul Bolle wrote:
> On Sun, 2013-07-14 at 13:45 +0100, Mark Brown wrote:

> > Simply removing the dependencies is not going to give the clearly
> > intended effect here.  The dependency on the DT only machine needs to be
> > replaced with something, not just deleted, otherwise the driver can't be
> > enabled in Kconfig.

> I interpreted commit 383ffda2fa as a commit that just removed a lot of

Always provide human readable descriptions of commits in email.

> stuff: see its commit explanation and its diffstat (it adds one line and
> deletes over 900 lines). Moreover, after that commit the references to
> MACH_SMDKV310 and MACH_SMDKC210 both are nops. Deleting them can't
> possibly change anything.

This still doesn't have much to do with your commit message or indicate
much understanding of what the change is actually doing or why it might
be a problem.

> But, anyhow, what would be the symbols to use here?

Well, let's think about this for a minute - what is going on when
someone does a device tree conversion on a platform?  What is replacing
the board files?  What would an equivalent change be for the audio
driver?

> Besides, this patch was intended as a follow up to commit 383ffda2fa, to
> clean up two references it apparently forgot to remove, and therefor
> basically copied the subject line used in that commit.

That doesn't really help - putting in a completely irrelevant subject
line is a really good way to get your patch ignored.
-------------- 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/20130715/1ec4cc47/attachment.sig>

From lars at metafoo.de  Mon Jul 15 07:33:53 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Mon, 15 Jul 2013 13:33:53 +0200
Subject: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <2A7ABDFCE21540479A5AEB0244A684D5E3D067@DNCE04.ent.ti.com>
References: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1373613482-28390-3-git-send-email-oleksandr.kozaruk@ti.com>,
 <51E05F6C.1060506@metafoo.de>
 <2A7ABDFCE21540479A5AEB0244A684D5E3D067@DNCE04.ent.ti.com>
Message-ID: <51E3DE21.9060105@metafoo.de>

On 07/15/2013 01:09 PM, Kozaruk, Oleksandr wrote:
[...]
> 
>>> +     ret = devm_request_threaded_irq(dev, irq, NULL,
>>> +                                     twl6030_gpadc_irq_handler,
>>> +                                     IRQF_ONESHOT, "twl6030_gpadc", gpadc);
>>
>> You access memory in the interrupt handler which is freed before the interrupt
>> handler is freed.
> Thanks for pointing this. devm_* will free memory for irq after the driver
> is removed and memory for the device is freed. I took me awhile to understand
> this. Is there going to be something like devm_iio_device_alloc? whould it be helpfull?
> 

Yes, I think it certainly makes sense to add a devm_iio_device_alloc(), care
to send a patch?


From anup.patel at linaro.org  Mon Jul 15 07:46:27 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Mon, 15 Jul 2013 17:16:27 +0530
Subject: [PATCH] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene host
Message-ID: <1373888788-8055-1-git-send-email-anup.patel@linaro.org>

This patch allows us to have X-Gene guest VCPU when using
KVM arm64 on APM X-Gene host.

We add KVM_ARM_TARGET_XGENE_V8 for X-Gene compatible guest VCPU
and we return KVM_ARM_TARGET_XGENE_V8 in kvm_target_cpu() when
running on X-Gene host.

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
 arch/arm64/kvm/guest.c               |   34 ++++++++++++++++++++++------------
 arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
 3 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 5031f42..8194707 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -55,8 +55,9 @@ struct kvm_regs {
 #define KVM_ARM_TARGET_AEM_V8		0
 #define KVM_ARM_TARGET_FOUNDATION_V8	1
 #define KVM_ARM_TARGET_CORTEX_A57	2
+#define KVM_ARM_TARGET_XGENE_V8		3
 
-#define KVM_ARM_NUM_TARGETS		3
+#define KVM_ARM_NUM_TARGETS		4
 
 /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
 #define KVM_ARM_DEVICE_TYPE_SHIFT	0
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 2c3ff67..e99b0a5 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -207,19 +207,29 @@ int __attribute_const__ kvm_target_cpu(void)
 	unsigned long implementor = read_cpuid_implementor();
 	unsigned long part_number = read_cpuid_part_number();
 
-	if (implementor != ARM_CPU_IMP_ARM)
-		return -EINVAL;
-
-	switch (part_number) {
-	case ARM_CPU_PART_AEM_V8:
-		return KVM_ARM_TARGET_AEM_V8;
-	case ARM_CPU_PART_FOUNDATION:
-		return KVM_ARM_TARGET_FOUNDATION_V8;
-	case ARM_CPU_PART_CORTEX_A57:
-		/* Currently handled by the generic backend */
-		return KVM_ARM_TARGET_CORTEX_A57;
+	switch (implementor) {
+	case ARM_CPU_IMP_ARM:
+		switch (part_number) {
+		case ARM_CPU_PART_AEM_V8:
+			return KVM_ARM_TARGET_AEM_V8;
+		case ARM_CPU_PART_FOUNDATION:
+			return KVM_ARM_TARGET_FOUNDATION_V8;
+		case ARM_CPU_PART_CORTEX_A57:
+			return KVM_ARM_TARGET_CORTEX_A57;
+		default:
+			return -EINVAL;
+		}
+		break;
+	case ARM_CPU_IMP_APM:
+		switch (part_number) {
+		case APM_CPU_PART_POTENZA:
+			return KVM_ARM_TARGET_XGENE_V8;
+		default:
+			return -EINVAL;
+		}
+		break;
 	default:
-		return -EINVAL;
+ 		return -EINVAL;
 	}
 }
 
diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
index 4268ab9..87f0b3f4 100644
--- a/arch/arm64/kvm/sys_regs_generic_v8.c
+++ b/arch/arm64/kvm/sys_regs_generic_v8.c
@@ -90,6 +90,9 @@ static int __init sys_reg_genericv8_init(void)
 					  &genericv8_target_table);
 	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_CORTEX_A57,
 					  &genericv8_target_table);
+	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_XGENE_V8,
+					  &genericv8_target_table);
+
 	return 0;
 }
 late_initcall(sys_reg_genericv8_init);
-- 
1.7.9.5



From sachin.kamat at linaro.org  Mon Jul 15 07:52:09 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Mon, 15 Jul 2013 17:22:09 +0530
Subject: [PATCH 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <1372054438-15693-1-git-send-email-sachin.kamat@linaro.org>
References: <1372054438-15693-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <CAK9yfHyEaysTJ9QpWWxxOacQEP4wv1NX3sXKkvKFhMbBgbCYYg@mail.gmail.com>

On 24 June 2013 11:43, Sachin Kamat <sachin.kamat at linaro.org> wrote:
> With the recent cleanup in Exynos platform code notably commits
> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
> more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
> Exynos4412 which have more (285) than the default number of GPIOs (255).
> Thus define this number in Kconfig file. Without this patch we get the
> following errors during boot:
>
> gpiochip_add: gpios 251..258 (gpv0) failed to register
> samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
> error code: -22
> samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
>
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> Cc: Tomasz Figa <t.figa at samsung.com>
> ---
> Based on Kukjin's for-next tree.
> ---
>  arch/arm/Kconfig |    1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index ddf2667..380a53b 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1578,6 +1578,7 @@ config ARCH_NR_GPIO
>         default 512 if SOC_OMAP5
>         default 392 if ARCH_U8500
>         default 352 if ARCH_VT8500
> +       default 288 if ARCH_EXYNOS
>         default 288 if ARCH_SUNXI
>         default 264 if MACH_H4700
>         default 0
> --
> 1.7.9.5
>

Kukjin,

Now that 3.11-rc1 is out, can you please queue this up for 3.11-rc2 as
without this patch
gpio support on 4412 boards is broken.


-- 
With warm regards,
Sachin


From thomas.petazzoni at free-electrons.com  Mon Jul 15 07:52:37 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 13:52:37 +0200
Subject: [PATCHv5 01/11] irqdomain: add irq_alloc_mapping() function
In-Reply-To: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373889167-27878-2-git-send-email-thomas.petazzoni@free-electrons.com>

This commit extends the irqdomain subsystem with an
irq_alloc_mapping() function which allows to let the irqdomain code
find an available hwirq number in the range [ 0 ; domain size ] for
the given domain, and create a virq mapping for it.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 include/linux/irqdomain.h |  2 ++
 kernel/irq/irqdomain.c    | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index c983ed1..1ffa336 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -195,6 +195,8 @@ static inline unsigned int irq_linear_revmap(struct irq_domain *domain,
 extern unsigned int irq_find_mapping(struct irq_domain *host,
 				     irq_hw_number_t hwirq);
 extern unsigned int irq_create_direct_mapping(struct irq_domain *host);
+extern unsigned int irq_alloc_mapping(struct irq_domain *host,
+				      irq_hw_number_t *hwirq);
 extern int irq_create_strict_mappings(struct irq_domain *domain,
 				      unsigned int irq_base,
 				      irq_hw_number_t hwirq_base, int count);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 706724e..b9ddb94 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -375,6 +375,38 @@ unsigned int irq_create_direct_mapping(struct irq_domain *domain)
 EXPORT_SYMBOL_GPL(irq_create_direct_mapping);
 
 /**
+ * irq_alloc_mapping() - Allocate an irq for mapping
+ * @domain: domain to allocate the irq for or NULL for default domain
+ * @hwirq:  reference to the returned hwirq
+ *
+ * This routine are used for irq controllers which can choose the
+ * hardware interrupt number from a range [ 0 ; domain size ], such as
+ * is often the case with PCI MSI controllers. The function will
+ * returned the allocated hwirq number in the hwirq pointer, and the
+ * corresponding virq number as the return value.
+ */
+unsigned int irq_alloc_mapping(struct irq_domain *domain,
+			       irq_hw_number_t *out_hwirq)
+{
+	irq_hw_number_t hwirq;
+
+	pr_debug("irq_alloc_mapping(0x%p)\n", domain);
+
+	for (hwirq = 0; hwirq < domain->hwirq_max; hwirq++)
+		if (!irq_find_mapping(domain, hwirq))
+			break;
+
+	if (hwirq == domain->hwirq_max) {
+		pr_debug("-> no available hwirq found\n");
+		return 0;
+	}
+
+	*out_hwirq = hwirq;
+	return irq_create_mapping(domain, hwirq);
+}
+EXPORT_SYMBOL_GPL(irq_alloc_mapping);
+
+/**
  * irq_create_mapping() - Map a hardware interrupt into linux irq space
  * @domain: domain owning this hardware interrupt or NULL for default domain
  * @hwirq: hardware irq number in that domain space
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 07:52:36 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 13:52:36 +0200
Subject: [PATCHv5 00/11] MSI support for Marvell EBU PCIe driver
Message-ID: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello,

This set of patches introduces Message Signaled Interrupt support in
the Marvell EBU PCIe driver. It has been successfully tested on the
Armada XP GP platform with an Intel e1000e PCIe network card that
supports MSI.

This patch set is intended for merging in 3.12, so the respective
maintainers of the different areas are invited to review/ack the
patches, see below for the details. This set of patches applies on top
of 3.11-rc1.

The patches do the following:

 * Patch 1 adds an IRQ domain function that allows to allocate
   dynamically a free hwirq number from an IRQ domain, and create a
   virq mapping to it. It was suggested by Grant Likely in order to
   remove the hwirq allocation code from the IRQ driver itself.

   This patch needs the Ack of Grant Likely.

 * Patch 2 reworks how the architecture-specific MSI functions can be
   overriden by architecture-specific code, by using weak
   functions. It was suggested by Bjorn Helgaas.

   This patch needs the Ack from Bjorn Helgaas, and the relevant
   architecture maintainers.

 * Patch 3 removes the ARCH_SUPPORTS_MSI hidden kconfig boolean which
   is no longer needed now that we have weak functions for all MSI
   architecture-specific hooks.

   This patch needs the Ack from Bjorn Helgaas, and the relevant
   architecture maintainers.

 * Patch 4 adds a minimal msi_chip infrastructure, that allows a
   pci_bus to be connected to a msi_chip, and that provides default
   implementations of the architecture-specific MSI functions to use
   msi_chip.

   This patch needs the Ack from Bjorn Helgaas.

 * Patch 5 adds a small registry of msi_chip <-> of_node in the OF
   code.

   This patch needs the Ack from Grant Likely or Rob Herring, and
   probably Bjorn Helgaas as well.

 * Patch 6 makes some not very interesting preparation in the Armada
   370/XP IRQ controller driver.

   This patch needs the Ack from Thomas Gleixner.

 * Patch 7 implements the MSI support in the Armada 370/XP IRQ
   controller driver. It registers an msi_chip using the
   msi_chip_add() function added in PATCH 3.

   This patch needs the Ack from Thomas Gleixner.

 * Patch 8 extends the ARM PCI core to expose ->add_bus() and
   ->remove_bus() hooks to PCI drivers. This was suggested by Bjorn
   Helgaas to allow the PCI driver to connected the PCI busses with
   the corresponding MSI chip.

   This patch needs the Ack from Russell King.

 * Patch 9 adjust the Armada 370/XP Device Tree to indicate that the
   MPIC is not only an interrupt-controller, but also an
   msi-controller.

   This patch needs the Ack from Jason Cooper, Gregory Clement
   and/or Andrew Lunn, the Marvell Maintainers.

 * Patch 10 adds MSI support in the Marvell PCIe host controller
   driver. The work to do here is minimal: get a reference to the
   msi-parent controller thanks to msi_chip_find_by_of_node(), and
   link it to the pci_bus structure before the bus gets enumerated.

   This patch needs the Ack from Bjorn Helgaas.

 * Patch 11 adjusts the Armada 370/XP Device Tree to add the msi-parent
   properties in the PCIe controller nodes.

   This patch needs the Ack from Jason Cooper, Gregory Clement
   and/or Andrew Lunn, the Marvell Maintainers.

This version 5 follows:
 * PATCH version 4 sent on July, 1st 2013
 * PATCH version 3 sent on June, 19th 2013
 * PATCH version 2 sent on June, 6th 2013
 * RFC version 1 sent on March, 26th 2013

Changes since v4:

 * Rebased on top of 3.11-rc1.

 * Slightly rework the implementation of arch_setup_msi_irq(),
   arch_teardown_msi_irq and arch_msi_check_device() according to the
   suggestions of Bjorn Helgaas (PATCH 4)

 * Make a few improvements to the msi_chip registry, according to the
   suggestion of Bjorn Helgaas and Rob Herring: coding style fixes,
   usage of mutex while traversing the list of msi_chip, usage of
   of_pci_msi_* prefix instead of just of_msi_*.

Changes since v3:

 * Keep only a default_teardown_msi_irqs() function needed for the Xen
   PCI x86 code, and remove all other default_*() function and put the
   default behavior directly in the weak functions. Suggested by
   Thierry Redding and Bjorn Helgaas.

 * Misc small improvements the MSI chip registry code: compiled only
   under CONFIG_PCI_MSI, functions exported to modules, addition of an
   of_msi_chip_remove() function, renaming of
   of_msi_chip_find_by_node() to of_find_msi_chip_by_node(), move the
   test of the "msi-controller" property to the of_msi_chip_add()
   function, renamed the list_head field from link to list, added
   dummy functions in the header files when !CONFIG_PCI_MSI &&
   !CONFIG_OF. All suggested by Thierry Redding.

 * Add a patch that entirely removes the ARCH_SUPPORTS_MSI, as we now
   have weak functions, so even if an arch doesn't actually
   use/support MSI, the code will build properly. Suggested by Thierry
   Redding.

 * Added Device Tree binding documentation updates for the IRQ
   controller and the PCIe controller.

Changes since v2:

 * Add an IRQ domain function that allows to allocate dynamically a
   free hwirq number from an IRQ domain, and create a virq mapping to
   it. It was suggested by Grant Likely in order to remove the hwirq
   allocation code from the IRQ driver itself. (PATCH 1)

 * Separate the use of weak functions from the introduction of the
   msi_chip infrastructure, and use weak functions for all
   architecture-specific MSI hooks. Suggested by Bjorn Helgaas (PATCH
   2).

 * Move the msi_chip registry to drivers/of. Suggested by Bjorn
   Helgaas (PATCH 4).

 * Use pcibios_add_bus() and pcibios_remove_bus() to connect the PCI
   busses to their msi_chip, as suggested by Bjorn Helgaas. Requires
   some ARM PCI core changes (PATCH 7), and then changes to the PCI
   driver itself (PATCH 9).

Thanks,

Thomas

Thierry Reding (1):
  PCI: Introduce new MSI chip infrastructure

Thomas Petazzoni (10):
  irqdomain: add irq_alloc_mapping() function
  PCI: use weak functions for MSI arch-specific functions
  PCI: remove ARCH_SUPPORTS_MSI kconfig option
  of: pci: add registry of MSI chips
  irqchip: armada-370-xp: properly request resources
  irqchip: armada-370-xp: implement MSI support
  ARM: pci: add ->add_bus() and ->remove_bus() hooks to hw_pci
  ARM: mvebu: the MPIC now provides MSI controller features
  PCI: mvebu: add support for MSI
  ARM: mvebu: link PCIe controllers to the MSI controller

 .../devicetree/bindings/arm/armada-370-xp-mpic.txt |   3 +
 .../devicetree/bindings/pci/mvebu-pci.txt          |   3 +
 arch/arm/Kconfig                                   |   1 -
 arch/arm/boot/dts/armada-370-xp.dtsi               |   1 +
 arch/arm/boot/dts/armada-370.dtsi                  |   1 +
 arch/arm/boot/dts/armada-xp-mv78230.dtsi           |   1 +
 arch/arm/boot/dts/armada-xp-mv78260.dtsi           |   1 +
 arch/arm/boot/dts/armada-xp-mv78460.dtsi           |   1 +
 arch/arm/include/asm/mach/pci.h                    |   4 +
 arch/arm/kernel/bios32.c                           |  16 ++
 arch/ia64/Kconfig                                  |   1 -
 arch/mips/Kconfig                                  |   2 -
 arch/mips/include/asm/pci.h                        |   5 -
 arch/powerpc/Kconfig                               |   1 -
 arch/powerpc/include/asm/pci.h                     |   5 -
 arch/s390/Kconfig                                  |   1 -
 arch/s390/include/asm/pci.h                        |   4 -
 arch/sparc/Kconfig                                 |   1 -
 arch/tile/Kconfig                                  |   1 -
 arch/x86/Kconfig                                   |   1 -
 arch/x86/include/asm/pci.h                         |  28 ----
 arch/x86/kernel/x86_init.c                         |  21 +++
 drivers/irqchip/irq-armada-370-xp.c                | 161 ++++++++++++++++++++-
 drivers/of/of_pci.c                                |  45 ++++++
 drivers/pci/Kconfig                                |   4 -
 drivers/pci/host/pci-mvebu.c                       |  26 ++++
 drivers/pci/msi.c                                  |  66 ++++++---
 drivers/pci/probe.c                                |   1 +
 include/linux/irqdomain.h                          |   2 +
 include/linux/msi.h                                |  20 ++-
 include/linux/of_pci.h                             |  12 ++
 include/linux/pci.h                                |   1 +
 kernel/irq/irqdomain.c                             |  32 ++++
 33 files changed, 388 insertions(+), 85 deletions(-)

-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 07:52:38 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 13:52:38 +0200
Subject: [PATCHv5 02/11] PCI: use weak functions for MSI arch-specific
 functions
In-Reply-To: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373889167-27878-3-git-send-email-thomas.petazzoni@free-electrons.com>

Until now, the MSI architecture-specific functions could be overloaded
using a fairly complex set of #define and compile-time
conditionals. In order to prepare for the introduction of the msi_chip
infrastructure, it is desirable to switch all those functions to use
the 'weak' mechanism. This commit converts all the architectures that
were overidding those MSI functions to use the new strategy.

Note that we keep a separate, non-weak, function
default_teardown_msi_irqs() for the default behavior of the
arch_teardown_msi_irqs(), as the default behavior is needed by the Xen
x86 PCI code.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: linuxppc-dev at lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky at de.ibm.com>
Cc: Heiko Carstens <heiko.carstens at de.ibm.com>
Cc: linux390 at de.ibm.com
Cc: linux-s390 at vger.kernel.org
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: H. Peter Anvin <hpa at zytor.com>
Cc: x86 at kernel.org
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Tony Luck <tony.luck at intel.com>
Cc: Fenghua Yu <fenghua.yu at intel.com>
Cc: linux-ia64 at vger.kernel.org
Cc: Ralf Baechle <ralf at linux-mips.org>
Cc: linux-mips at linux-mips.org
Cc: David S. Miller <davem at davemloft.net>
Cc: sparclinux at vger.kernel.org
Cc: Chris Metcalf <cmetcalf at tilera.com>
---
 arch/mips/include/asm/pci.h    |  5 -----
 arch/powerpc/include/asm/pci.h |  5 -----
 arch/s390/include/asm/pci.h    |  4 ----
 arch/x86/include/asm/pci.h     | 28 --------------------------
 arch/x86/kernel/x86_init.c     | 21 ++++++++++++++++++++
 drivers/pci/msi.c              | 45 +++++++++++++++++++-----------------------
 include/linux/msi.h            |  7 ++++++-
 7 files changed, 47 insertions(+), 68 deletions(-)

diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
index fa8e0aa..f194c08 100644
--- a/arch/mips/include/asm/pci.h
+++ b/arch/mips/include/asm/pci.h
@@ -136,11 +136,6 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
 	return channel ? 15 : 14;
 }
 
-#ifdef CONFIG_CPU_CAVIUM_OCTEON
-/* MSI arch hook for OCTEON */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#endif
-
 extern char * (*pcibios_plat_setup)(char *str);
 
 #ifdef CONFIG_OF
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 6653f27..95145a1 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -113,11 +113,6 @@ extern int pci_domain_nr(struct pci_bus *bus);
 /* Decide whether to display the domain number in /proc */
 extern int pci_proc_domain(struct pci_bus *bus);
 
-/* MSI arch hooks */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#define arch_teardown_msi_irqs arch_teardown_msi_irqs
-#define arch_msi_check_device arch_msi_check_device
-
 struct vm_area_struct;
 /* Map a range of PCI memory or I/O space for a device into user space */
 int pci_mmap_page_range(struct pci_dev *pdev, struct vm_area_struct *vma,
diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
index 6e577ba..262b91b 100644
--- a/arch/s390/include/asm/pci.h
+++ b/arch/s390/include/asm/pci.h
@@ -21,10 +21,6 @@ void pci_iounmap(struct pci_dev *, void __iomem *);
 int pci_domain_nr(struct pci_bus *);
 int pci_proc_domain(struct pci_bus *);
 
-/* MSI arch hooks */
-#define arch_setup_msi_irqs	arch_setup_msi_irqs
-#define arch_teardown_msi_irqs	arch_teardown_msi_irqs
-
 #define ZPCI_BUS_NR			0	/* default bus number */
 #define ZPCI_DEVFN			0	/* default device number */
 
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index d9e9e6c..8c61de0 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -100,29 +100,6 @@ static inline void early_quirks(void) { }
 extern void pci_iommu_alloc(void);
 
 #ifdef CONFIG_PCI_MSI
-/* MSI arch specific hooks */
-static inline int x86_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
-{
-	return x86_msi.setup_msi_irqs(dev, nvec, type);
-}
-
-static inline void x86_teardown_msi_irqs(struct pci_dev *dev)
-{
-	x86_msi.teardown_msi_irqs(dev);
-}
-
-static inline void x86_teardown_msi_irq(unsigned int irq)
-{
-	x86_msi.teardown_msi_irq(irq);
-}
-static inline void x86_restore_msi_irqs(struct pci_dev *dev, int irq)
-{
-	x86_msi.restore_msi_irqs(dev, irq);
-}
-#define arch_setup_msi_irqs x86_setup_msi_irqs
-#define arch_teardown_msi_irqs x86_teardown_msi_irqs
-#define arch_teardown_msi_irq x86_teardown_msi_irq
-#define arch_restore_msi_irqs x86_restore_msi_irqs
 /* implemented in arch/x86/kernel/apic/io_apic. */
 struct msi_desc;
 int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
@@ -130,11 +107,6 @@ void native_teardown_msi_irq(unsigned int irq);
 void native_restore_msi_irqs(struct pci_dev *dev, int irq);
 int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
 		  unsigned int irq_base, unsigned int irq_offset);
-/* default to the implementation in drivers/lib/msi.c */
-#define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
-#define HAVE_DEFAULT_MSI_RESTORE_IRQS
-void default_teardown_msi_irqs(struct pci_dev *dev);
-void default_restore_msi_irqs(struct pci_dev *dev, int irq);
 #else
 #define native_setup_msi_irqs		NULL
 #define native_teardown_msi_irq		NULL
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 45a14db..a2b189c 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -116,6 +116,27 @@ struct x86_msi_ops x86_msi = {
 	.setup_hpet_msi		= default_setup_hpet_msi,
 };
 
+/* MSI arch specific hooks */
+int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+	return x86_msi.setup_msi_irqs(dev, nvec, type);
+}
+
+void arch_teardown_msi_irqs(struct pci_dev *dev)
+{
+	x86_msi.teardown_msi_irqs(dev);
+}
+
+void arch_teardown_msi_irq(unsigned int irq)
+{
+	x86_msi.teardown_msi_irq(irq);
+}
+
+void arch_restore_msi_irqs(struct pci_dev *dev, int irq)
+{
+	x86_msi.restore_msi_irqs(dev, irq);
+}
+
 struct x86_io_apic_ops x86_io_apic_ops = {
 	.init			= native_io_apic_init_mappings,
 	.read			= native_io_apic_read,
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index aca7578..aa2f697 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -30,20 +30,21 @@ static int pci_msi_enable = 1;
 
 /* Arch hooks */
 
-#ifndef arch_msi_check_device
-int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
 {
-	return 0;
+	return -EINVAL;
 }
-#endif
 
-#ifndef arch_setup_msi_irqs
-# define arch_setup_msi_irqs default_setup_msi_irqs
-# define HAVE_DEFAULT_MSI_SETUP_IRQS
-#endif
+void __weak arch_teardown_msi_irq(unsigned int irq)
+{
+}
 
-#ifdef HAVE_DEFAULT_MSI_SETUP_IRQS
-int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+{
+	return 0;
+}
+
+int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 {
 	struct msi_desc *entry;
 	int ret;
@@ -65,14 +66,11 @@ int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 
 	return 0;
 }
-#endif
 
-#ifndef arch_teardown_msi_irqs
-# define arch_teardown_msi_irqs default_teardown_msi_irqs
-# define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
-#endif
-
-#ifdef HAVE_DEFAULT_MSI_TEARDOWN_IRQS
+/*
+ * We have a default implementation available as a separate non-weak
+ * function, as it is used by the Xen x86 PCI code
+ */
 void default_teardown_msi_irqs(struct pci_dev *dev)
 {
 	struct msi_desc *entry;
@@ -89,15 +87,13 @@ void default_teardown_msi_irqs(struct pci_dev *dev)
 			arch_teardown_msi_irq(entry->irq + i);
 	}
 }
-#endif
 
-#ifndef arch_restore_msi_irqs
-# define arch_restore_msi_irqs default_restore_msi_irqs
-# define HAVE_DEFAULT_MSI_RESTORE_IRQS
-#endif
+void __weak arch_teardown_msi_irqs(struct pci_dev *dev)
+{
+	return default_teardown_msi_irqs(dev);
+}
 
-#ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS
-void default_restore_msi_irqs(struct pci_dev *dev, int irq)
+void __weak arch_restore_msi_irqs(struct pci_dev *dev, int irq)
 {
 	struct msi_desc *entry;
 
@@ -114,7 +110,6 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)
 	if (entry)
 		write_msi_msg(irq, &entry->msg);
 }
-#endif
 
 static void msi_set_enable(struct pci_dev *dev, int enable)
 {
diff --git a/include/linux/msi.h b/include/linux/msi.h
index ee66f3a..18870b0 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -51,12 +51,17 @@ struct msi_desc {
 };
 
 /*
- * The arch hook for setup up msi irqs
+ * The arch hooks to setup up msi irqs. Those functions are
+ * implemented as weak symbols so that they /can/ be overriden by
+ * architecture specific code if needed.
  */
 int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc);
 void arch_teardown_msi_irq(unsigned int irq);
 int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
 void arch_teardown_msi_irqs(struct pci_dev *dev);
 int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
+void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
+
+void default_teardown_msi_irqs(struct pci_dev *dev);
 
 #endif /* LINUX_MSI_H */
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 07:52:40 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 13:52:40 +0200
Subject: [PATCHv5 04/11] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373889167-27878-5-git-send-email-thomas.petazzoni@free-electrons.com>

From: Thierry Reding <thierry.reding at avionic-design.de>

The new struct msi_chip is used to associated an MSI controller with a
PCI bus. It is automatically handed down from the root to its children
during bus enumeration.

This patch provides default (weak) implementations for the architecture-
specific MSI functions (arch_setup_msi_irq(), arch_teardown_msi_irq()
and arch_msi_check_device()) which check if a PCI device's bus has an
attached MSI chip and forward the call appropriately.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/pci/msi.c   | 27 +++++++++++++++++++++++++--
 drivers/pci/probe.c |  1 +
 include/linux/msi.h | 11 +++++++++++
 include/linux/pci.h |  1 +
 4 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index aa2f697..d5b6378 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -32,16 +32,39 @@ static int pci_msi_enable = 1;
 
 int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
 {
-	return -EINVAL;
+	struct msi_chip *chip = dev->bus->msi;
+	int err;
+
+	if (!chip || !chip->setup_irq)
+		return -EINVAL;
+
+	err = chip->setup_irq(chip, dev, desc);
+	if (err < 0)
+		return err;
+
+	irq_set_chip_data(desc->irq, chip);
+
+	return 0;
 }
 
 void __weak arch_teardown_msi_irq(unsigned int irq)
 {
+	struct msi_chip *chip = irq_get_chip_data(irq);
+
+	if (!chip || !chip->teardown_irq)
+		return;
+
+	chip->teardown_irq(chip, irq);
 }
 
 int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
 {
-	return 0;
+	struct msi_chip *chip = dev->bus->msi;
+
+	if (!chip || !chip->check_device)
+		return 0;
+
+	return chip->check_device(chip, dev, nvec, type);
 }
 
 int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 46ada5c..b8eaa81 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -666,6 +666,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
 
 	child->parent = parent;
 	child->ops = parent->ops;
+	child->msi = parent->msi;
 	child->sysdata = parent->sysdata;
 	child->bus_flags = parent->bus_flags;
 
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 18870b0..cbf5d05 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -64,4 +64,15 @@ void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
 
 void default_teardown_msi_irqs(struct pci_dev *dev);
 
+struct msi_chip {
+	struct module *owner;
+	struct device *dev;
+
+	int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
+			 struct msi_desc *desc);
+	void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
+	int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
+			    int nvec, int type);
+};
+
 #endif /* LINUX_MSI_H */
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 0fd1f15..4044e3c 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -433,6 +433,7 @@ struct pci_bus {
 	struct resource busn_res;	/* bus numbers routed to this bus */
 
 	struct pci_ops	*ops;		/* configuration access functions */
+	struct msi_chip	*msi;		/* MSI controller */
 	void		*sysdata;	/* hook for sys-specific extension */
 	struct proc_dir_entry *procdir;	/* directory entry in /proc/bus/pci */
 
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 07:52:39 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 13:52:39 +0200
Subject: [PATCHv5 03/11] PCI: remove ARCH_SUPPORTS_MSI kconfig option
In-Reply-To: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373889167-27878-4-git-send-email-thomas.petazzoni@free-electrons.com>

Now that we have weak versions for each of the PCI MSI architecture
functions, we can actually build the MSI support for all platforms,
regardless of whether they provide or not architecture-specific
versions of those functions. For this reason, the ARCH_SUPPORTS_MSI
hidden kconfig boolean becomes useless, and this patch gets rid of it.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: linuxppc-dev at lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky at de.ibm.com>
Cc: Heiko Carstens <heiko.carstens at de.ibm.com>
Cc: linux390 at de.ibm.com
Cc: linux-s390 at vger.kernel.org
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: H. Peter Anvin <hpa at zytor.com>
Cc: x86 at kernel.org
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Tony Luck <tony.luck at intel.com>
Cc: Fenghua Yu <fenghua.yu at intel.com>
Cc: linux-ia64 at vger.kernel.org
Cc: Ralf Baechle <ralf at linux-mips.org>
Cc: linux-mips at linux-mips.org
Cc: David S. Miller <davem at davemloft.net>
Cc: sparclinux at vger.kernel.org
Cc: Chris Metcalf <cmetcalf at tilera.com>
---
 arch/arm/Kconfig     | 1 -
 arch/ia64/Kconfig    | 1 -
 arch/mips/Kconfig    | 2 --
 arch/powerpc/Kconfig | 1 -
 arch/s390/Kconfig    | 1 -
 arch/sparc/Kconfig   | 1 -
 arch/tile/Kconfig    | 1 -
 arch/x86/Kconfig     | 1 -
 drivers/pci/Kconfig  | 4 ----
 9 files changed, 13 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..b173c1d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -441,7 +441,6 @@ config ARCH_NETX
 config ARCH_IOP13XX
 	bool "IOP13xx-based"
 	depends on MMU
-	select ARCH_SUPPORTS_MSI
 	select CPU_XSC3
 	select NEED_MACH_MEMORY_H
 	select NEED_RET_TO_USER
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 5a768ad..098602b 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -9,7 +9,6 @@ config IA64
 	select PCI if (!IA64_HP_SIM)
 	select ACPI if (!IA64_HP_SIM)
 	select PM if (!IA64_HP_SIM)
-	select ARCH_SUPPORTS_MSI
 	select HAVE_UNSTABLE_SCHED_CLOCK
 	select HAVE_IDE
 	select HAVE_OPROFILE
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 4758a8f..00b2698 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -726,7 +726,6 @@ config CAVIUM_OCTEON_SOC
 	select SYS_HAS_CPU_CAVIUM_OCTEON
 	select SWAP_IO_SPACE
 	select HW_HAS_PCI
-	select ARCH_SUPPORTS_MSI
 	select ZONE_DMA32
 	select USB_ARCH_HAS_OHCI
 	select USB_ARCH_HAS_EHCI
@@ -762,7 +761,6 @@ config NLM_XLR_BOARD
 	select CEVT_R4K
 	select CSRC_R4K
 	select IRQ_CPU
-	select ARCH_SUPPORTS_MSI
 	select ZONE_DMA32 if 64BIT
 	select SYNC_R4K
 	select SYS_HAS_EARLY_PRINTK
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3bf72cd..183a165 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -727,7 +727,6 @@ config PCI
 	default y if !40x && !CPM2 && !8xx && !PPC_83xx \
 		&& !PPC_85xx && !PPC_86xx && !GAMECUBE_COMMON
 	default PCI_QSPAN if !4xx && !CPM2 && 8xx
-	select ARCH_SUPPORTS_MSI
 	select GENERIC_PCI_IOMAP
 	help
 	  Find out whether your system includes a PCI bus. PCI is the name of
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 22f75b5..e9982a3 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -428,7 +428,6 @@ menuconfig PCI
 	bool "PCI support"
 	default n
 	depends on 64BIT
-	select ARCH_SUPPORTS_MSI
 	select PCI_MSI
 	help
 	  Enable PCI support.
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index a00cbd3..1570ad2 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -52,7 +52,6 @@ config SPARC32
 
 config SPARC64
 	def_bool 64BIT
-	select ARCH_SUPPORTS_MSI
 	select HAVE_FUNCTION_TRACER
 	select HAVE_FUNCTION_GRAPH_TRACER
 	select HAVE_FUNCTION_GRAPH_FP_TEST
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 24565a7..74dff90 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -380,7 +380,6 @@ config PCI
 	select PCI_DOMAINS
 	select GENERIC_PCI_IOMAP
 	select TILE_GXIO_TRIO if TILEGX
-	select ARCH_SUPPORTS_MSI if TILEGX
 	select PCI_MSI if TILEGX
 	---help---
 	  Enable PCI root complex support, so PCIe endpoint devices can
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b32ebf9..5db62ef 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2014,7 +2014,6 @@ menu "Bus options (PCI etc.)"
 config PCI
 	bool "PCI support"
 	default y
-	select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC)
 	---help---
 	  Find out whether you have a PCI motherboard. PCI is the name of a
 	  bus system, i.e. the way the CPU talks to the other stuff inside
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 81944fb..b6a99f7 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -1,13 +1,9 @@
 #
 # PCI configuration
 #
-config ARCH_SUPPORTS_MSI
-	bool
-
 config PCI_MSI
 	bool "Message Signaled Interrupts (MSI and MSI-X)"
 	depends on PCI
-	depends on ARCH_SUPPORTS_MSI
 	help
 	   This allows device drivers to enable MSI (Message Signaled
 	   Interrupts).  Message Signaled Interrupts enable a device to
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 07:52:42 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 13:52:42 +0200
Subject: [PATCHv5 06/11] irqchip: armada-370-xp: properly request resources
In-Reply-To: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373889167-27878-7-git-send-email-thomas.petazzoni@free-electrons.com>

Instead of using of_iomap(), we now use of_address_to_resource(),
request_mem_region() and ioremap(). This allows the corresponding I/O
regions to be properly requested and visible in /proc/iomem.

The main motivation for this change is that the introduction of the
MSI support requires us to get the physical address of the main
interrupt controller registers, so we will need the corresponding
'struct resource' anyway.

We also take this opportunity to change a panic() to BUG_ON(), in
order to be consistent with the rest of the driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/irqchip/irq-armada-370-xp.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index bb328a3..26adc74 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -248,12 +248,25 @@ armada_370_xp_handle_irq(struct pt_regs *regs)
 static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 					     struct device_node *parent)
 {
+	struct resource main_int_res, per_cpu_int_res;
 	u32 control;
 
-	main_int_base = of_iomap(node, 0);
-	per_cpu_int_base = of_iomap(node, 1);
+	BUG_ON(of_address_to_resource(node, 0, &main_int_res));
+	BUG_ON(of_address_to_resource(node, 1, &per_cpu_int_res));
 
+	BUG_ON(!request_mem_region(main_int_res.start,
+				   resource_size(&main_int_res),
+				   node->full_name));
+	BUG_ON(!request_mem_region(per_cpu_int_res.start,
+				   resource_size(&per_cpu_int_res),
+				   node->full_name));
+
+	main_int_base = ioremap(main_int_res.start,
+				resource_size(&main_int_res));
 	BUG_ON(!main_int_base);
+
+	per_cpu_int_base = ioremap(per_cpu_int_res.start,
+				   resource_size(&per_cpu_int_res));
 	BUG_ON(!per_cpu_int_base);
 
 	control = readl(main_int_base + ARMADA_370_XP_INT_CONTROL);
@@ -262,8 +275,7 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 		irq_domain_add_linear(node, (control >> 2) & 0x3ff,
 				&armada_370_xp_mpic_irq_ops, NULL);
 
-	if (!armada_370_xp_mpic_domain)
-		panic("Unable to add Armada_370_Xp MPIC irq domain (DT)\n");
+	BUG_ON(!armada_370_xp_mpic_domain);
 
 	irq_set_default_host(armada_370_xp_mpic_domain);
 
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 07:52:44 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 13:52:44 +0200
Subject: [PATCHv5 08/11] ARM: pci: add ->add_bus() and ->remove_bus() hooks to
 hw_pci
In-Reply-To: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373889167-27878-9-git-send-email-thomas.petazzoni@free-electrons.com>

Some PCI drivers may need to adjust the pci_bus structure after it has
been allocated by the Linux PCI core. The PCI core allows
architectures to implement the pcibios_add_bus() and
pcibios_remove_bus() for this purpose. This commit therefore extends
the hw_pci and pci_sys_data structures of the ARM PCI core to allow
PCI drivers to register ->add_bus() and ->remove_bus() in hw_pci,
which will get called when a bus is added or removed from the system.

This will be used for example by the Marvell PCIe driver to connect a
particular PCI bus with its corresponding MSI chip to handle Message
Signaled Interrupts.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Reviewed-by: Thierry Reding <thierry.reding at gmail.com>
---
 arch/arm/include/asm/mach/pci.h |  4 ++++
 arch/arm/kernel/bios32.c        | 16 ++++++++++++++++
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index a1c90d7..487155c 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -36,6 +36,8 @@ struct hw_pci {
 					  resource_size_t start,
 					  resource_size_t size,
 					  resource_size_t align);
+	void            (*add_bus)(struct pci_bus *bus);
+	void            (*remove_bus)(struct pci_bus *bus);
 };
 
 /*
@@ -63,6 +65,8 @@ struct pci_sys_data {
 					  resource_size_t start,
 					  resource_size_t size,
 					  resource_size_t align);
+	void            (*add_bus)(struct pci_bus *bus);
+	void            (*remove_bus)(struct pci_bus *bus);
 	void		*private_data;	/* platform controller private data	*/
 };
 
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index 261fcc8..530e59d 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -363,6 +363,20 @@ void pcibios_fixup_bus(struct pci_bus *bus)
 }
 EXPORT_SYMBOL(pcibios_fixup_bus);
 
+void pcibios_add_bus(struct pci_bus *bus)
+{
+	struct pci_sys_data *sys = bus->sysdata;
+	if (sys->add_bus)
+		sys->add_bus(bus);
+}
+
+void pcibios_remove_bus(struct pci_bus *bus)
+{
+	struct pci_sys_data *sys = bus->sysdata;
+	if (sys->remove_bus)
+		sys->remove_bus(bus);
+}
+
 /*
  * Swizzle the device pin each time we cross a bridge.  If a platform does
  * not provide a swizzle function, we perform the standard PCI swizzling.
@@ -464,6 +478,8 @@ static void pcibios_init_hw(struct device *parent, struct hw_pci *hw,
 		sys->swizzle = hw->swizzle;
 		sys->map_irq = hw->map_irq;
 		sys->align_resource = hw->align_resource;
+		sys->add_bus        = hw->add_bus;
+		sys->remove_bus     = hw->remove_bus;
 		INIT_LIST_HEAD(&sys->resources);
 
 		if (hw->private_data)
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 07:52:45 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 13:52:45 +0200
Subject: [PATCHv5 09/11] ARM: mvebu: the MPIC now provides MSI controller
 features
In-Reply-To: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373889167-27878-10-git-send-email-thomas.petazzoni@free-electrons.com>

Adds the 'msi-controller' property to the main interrupt controller
Device Tree node, to indicate that it can now behave as a MSI
controller.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Reviewed-by: Thierry Reding <thierry.reding at gmail.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 90b1176..ac0bbc0 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -56,6 +56,7 @@
 				#interrupt-cells = <1>;
 				#size-cells = <1>;
 				interrupt-controller;
+				msi-controller;
 			};
 
 			coherency-fabric at 20200 {
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 07:52:41 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 13:52:41 +0200
Subject: [PATCHv5 05/11] of: pci: add registry of MSI chips
In-Reply-To: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373889167-27878-6-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds a very basic registry of msi_chip structures, so that
an IRQ controller driver can register an msi_chip, and a PCIe host
controller can find it, based on a 'struct device_node'.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/of/of_pci.c    | 45 +++++++++++++++++++++++++++++++++++++++++++++
 include/linux/msi.h    |  2 ++
 include/linux/of_pci.h | 12 ++++++++++++
 3 files changed, 59 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 42c687a..e5ca008 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -89,3 +89,48 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
+
+#ifdef CONFIG_PCI_MSI
+
+static LIST_HEAD(of_pci_msi_chip_list);
+static DEFINE_MUTEX(of_pci_msi_chip_mutex);
+
+int of_pci_msi_chip_add(struct msi_chip *chip)
+{
+	if (!of_property_read_bool(chip->of_node, "msi-controller"))
+		return -EINVAL;
+
+	mutex_lock(&of_pci_msi_chip_mutex);
+	list_add(&chip->list, &of_pci_msi_chip_list);
+	mutex_unlock(&of_pci_msi_chip_mutex);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_msi_chip_add);
+
+void of_pci_msi_chip_remove(struct msi_chip *chip)
+{
+	mutex_lock(&of_pci_msi_chip_mutex);
+	list_del(&chip->list);
+	mutex_unlock(&of_pci_msi_chip_mutex);
+}
+EXPORT_SYMBOL_GPL(of_pci_msi_chip_remove);
+
+struct msi_chip *of_pci_find_msi_chip_by_node(struct device_node *of_node)
+{
+	struct msi_chip *c;
+
+	mutex_lock(&of_pci_msi_chip_mutex);
+	list_for_each_entry(c, &of_pci_msi_chip_list, list) {
+		if (c->of_node == of_node) {
+			mutex_unlock(&of_pci_msi_chip_mutex);
+			return c;
+		}
+	}
+	mutex_unlock(&of_pci_msi_chip_mutex);
+
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(of_pci_find_msi_chip_by_node);
+
+#endif /* CONFIG_PCI_MSI */
diff --git a/include/linux/msi.h b/include/linux/msi.h
index cbf5d05..80900e0 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -67,6 +67,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);
 struct msi_chip {
 	struct module *owner;
 	struct device *dev;
+	struct device_node *of_node;
+	struct list_head list;
 
 	int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
 			 struct msi_desc *desc);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 7a04826..29631eb 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -2,6 +2,7 @@
 #define __OF_PCI_H
 
 #include <linux/pci.h>
+#include <linux/msi.h>
 
 struct pci_dev;
 struct of_irq;
@@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 int of_pci_get_devfn(struct device_node *np);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 
+#if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
+int of_pci_msi_chip_add(struct msi_chip *chip);
+void of_pci_msi_chip_remove(struct msi_chip *chip);
+struct msi_chip *of_pci_find_msi_chip_by_node(struct device_node *of_node);
+#else
+static inline int of_pci_msi_chip_add(struct msi_chip *chip) { return -EINVAL; }
+static inline void of_pci_msi_chip_remove(struct msi_chip *chip) { }
+static inline struct msi_chip *
+of_pci_find_msi_chip_by_node(struct device_node *of_node) { return NULL };
+#endif
+
 #endif
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 07:52:43 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 13:52:43 +0200
Subject: [PATCHv5 07/11] irqchip: armada-370-xp: implement MSI support
In-Reply-To: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373889167-27878-8-git-send-email-thomas.petazzoni@free-electrons.com>

This commit introduces the support for the MSI interrupts in the
armada-370-xp interrupt controller driver. It registers an MSI chip to
the MSI chip registry, which will be used by the Marvell PCIe host
controller driver.

The MSI interrupts use the 16 high doorbells, and are therefore
notified using IRQ1 of the main interrupt controller.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../devicetree/bindings/arm/armada-370-xp-mpic.txt |   3 +
 drivers/irqchip/irq-armada-370-xp.c                | 141 ++++++++++++++++++++-
 2 files changed, 143 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
index 61df564..d74091a 100644
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
@@ -4,6 +4,8 @@ Marvell Armada 370 and Armada XP Interrupt Controller
 Required properties:
 - compatible: Should be "marvell,mpic"
 - interrupt-controller: Identifies the node as an interrupt controller.
+- msi-controller: Identifies the node as an PCI Message Signaled
+  Interrupt controller.
 - #interrupt-cells: The number of cells to define the interrupts. Should be 1.
   The cell is the IRQ number
 
@@ -24,6 +26,7 @@ Example:
               #address-cells = <1>;
               #size-cells = <1>;
               interrupt-controller;
+              msi-controller;
               reg = <0xd0020a00 0x1d0>,
                     <0xd0021070 0x58>;
         };
diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index 26adc74..ca1f5e2 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -21,7 +21,10 @@
 #include <linux/io.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <linux/of_pci.h>
 #include <linux/irqdomain.h>
+#include <linux/slab.h>
+#include <linux/msi.h>
 #include <asm/mach/arch.h>
 #include <asm/exception.h>
 #include <asm/smp_plat.h>
@@ -51,12 +54,20 @@
 #define IPI_DOORBELL_START                      (0)
 #define IPI_DOORBELL_END                        (8)
 #define IPI_DOORBELL_MASK                       0xFF
+#define PCI_MSI_DOORBELL_START                  (16)
+#define PCI_MSI_DOORBELL_NR                     (16)
+#define PCI_MSI_DOORBELL_END                    (32)
+#define PCI_MSI_DOORBELL_MASK                   0xFFFF0000
 
 static DEFINE_RAW_SPINLOCK(irq_controller_lock);
 
 static void __iomem *per_cpu_int_base;
 static void __iomem *main_int_base;
 static struct irq_domain *armada_370_xp_mpic_domain;
+#ifdef CONFIG_PCI_MSI
+static struct irq_domain *armada_370_xp_msi_domain;
+static phys_addr_t msi_doorbell_addr;
+#endif
 
 /*
  * In SMP mode:
@@ -87,6 +98,102 @@ static void armada_370_xp_irq_unmask(struct irq_data *d)
 				ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
 }
 
+#ifdef CONFIG_PCI_MSI
+
+static int armada_370_xp_setup_msi_irq(struct msi_chip *chip,
+				       struct pci_dev *pdev,
+				       struct msi_desc *desc)
+{
+	struct msi_msg msg;
+	irq_hw_number_t hwirq;
+	int virq;
+
+	virq = irq_alloc_mapping(armada_370_xp_msi_domain, &hwirq);
+	if (!virq)
+		return -EINVAL;
+
+	irq_set_msi_desc(virq, desc);
+
+	msg.address_lo = msi_doorbell_addr;
+	msg.address_hi = 0;
+	msg.data = 0xf00 | (hwirq + 16);
+
+	write_msi_msg(virq, &msg);
+	return 0;
+}
+
+static void armada_370_xp_teardown_msi_irq(struct msi_chip *chip,
+					   unsigned int irq)
+{
+	irq_dispose_mapping(irq);
+}
+
+static struct irq_chip armada_370_xp_msi_irq_chip = {
+	.name = "armada_370_xp_msi_irq",
+	.irq_enable = unmask_msi_irq,
+	.irq_disable = mask_msi_irq,
+	.irq_mask = mask_msi_irq,
+	.irq_unmask = unmask_msi_irq,
+};
+
+static int armada_370_xp_msi_map(struct irq_domain *domain, unsigned int virq,
+				 irq_hw_number_t hw)
+{
+	irq_set_chip_and_handler(virq, &armada_370_xp_msi_irq_chip,
+				 handle_simple_irq);
+	set_irq_flags(virq, IRQF_VALID);
+
+	return 0;
+}
+
+static const struct irq_domain_ops armada_370_xp_msi_irq_ops = {
+	.map = armada_370_xp_msi_map,
+};
+
+static int armada_370_xp_msi_init(struct device_node *node)
+{
+	struct msi_chip *msi_chip;
+	int ret;
+	u32 reg;
+
+	msi_chip = kzalloc(sizeof(*msi_chip), GFP_KERNEL);
+	if (!msi_chip)
+		return -ENOMEM;
+
+	armada_370_xp_msi_domain =
+		irq_domain_add_linear(NULL, PCI_MSI_DOORBELL_NR,
+				      &armada_370_xp_msi_irq_ops, NULL);
+	if (!armada_370_xp_msi_domain) {
+		kfree(msi_chip);
+		return -ENOMEM;
+	}
+
+	msi_chip->of_node = node;
+	msi_chip->setup_irq = armada_370_xp_setup_msi_irq;
+	msi_chip->teardown_irq = armada_370_xp_teardown_msi_irq;
+
+	ret = of_pci_msi_chip_add(msi_chip);
+	if (ret < 0) {
+		irq_domain_remove(armada_370_xp_msi_domain);
+		kfree(msi_chip);
+		return ret;
+	}
+
+	reg = readl(per_cpu_int_base + ARMADA_370_XP_IN_DRBEL_MSK_OFFS)
+		| PCI_MSI_DOORBELL_MASK;
+
+	writel(reg, per_cpu_int_base +
+	       ARMADA_370_XP_IN_DRBEL_MSK_OFFS);
+
+	/* Unmask IPI interrupt */
+	writel(1, per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+
+	return 0;
+}
+#else
+static inline int armada_370_xp_msi_init(struct device_node *node) { return 0; }
+#endif
+
 #ifdef CONFIG_SMP
 static int armada_xp_set_affinity(struct irq_data *d,
 				  const struct cpumask *mask_val, bool force)
@@ -214,12 +321,39 @@ armada_370_xp_handle_irq(struct pt_regs *regs)
 		if (irqnr > 1022)
 			break;
 
-		if (irqnr > 0) {
+		if (irqnr > 1) {
 			irqnr =	irq_find_mapping(armada_370_xp_mpic_domain,
 					irqnr);
 			handle_IRQ(irqnr, regs);
 			continue;
 		}
+
+#ifdef CONFIG_PCI_MSI
+		/* MSI handling */
+		if (irqnr == 1) {
+			u32 msimask, msinr;
+
+			msimask = readl_relaxed(per_cpu_int_base +
+						ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS)
+				& PCI_MSI_DOORBELL_MASK;
+
+			writel(~PCI_MSI_DOORBELL_MASK, per_cpu_int_base +
+			       ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS);
+
+			for (msinr = PCI_MSI_DOORBELL_START;
+			     msinr < PCI_MSI_DOORBELL_END; msinr++) {
+				int irq;
+
+				if (!(msimask & BIT(msinr)))
+					continue;
+
+				irq = irq_find_mapping(armada_370_xp_msi_domain,
+						       msinr - 16);
+				handle_IRQ(irq, regs);
+			}
+		}
+#endif
+
 #ifdef CONFIG_SMP
 		/* IPI Handling */
 		if (irqnr == 0) {
@@ -269,6 +403,9 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 				   resource_size(&per_cpu_int_res));
 	BUG_ON(!per_cpu_int_base);
 
+	msi_doorbell_addr = main_int_res.start +
+		ARMADA_370_XP_SW_TRIG_INT_OFFS;
+
 	control = readl(main_int_base + ARMADA_370_XP_INT_CONTROL);
 
 	armada_370_xp_mpic_domain =
@@ -292,6 +429,8 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 
 #endif
 
+	armada_370_xp_msi_init(node);
+
 	set_handle_irq(armada_370_xp_handle_irq);
 
 	return 0;
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 07:52:47 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 13:52:47 +0200
Subject: [PATCHv5 11/11] ARM: mvebu: link PCIe controllers to the MSI
 controller
In-Reply-To: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373889167-27878-12-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adjusts the Armada 370 and Armada XP PCIe controllers
Device Tree informations to reference their MSI controller. In the
case of this platform, the MSI controller is implemented by the MPIC.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/armada-370.dtsi        | 1 +
 arch/arm/boot/dts/armada-xp-mv78230.dtsi | 1 +
 arch/arm/boot/dts/armada-xp-mv78260.dtsi | 1 +
 arch/arm/boot/dts/armada-xp-mv78460.dtsi | 1 +
 4 files changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..a60018d 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -178,6 +178,7 @@
 				#address-cells = <3>;
 				#size-cells = <2>;
 
+				msi-parent = <&mpic>;
 				bus-range = <0x00 0xff>;
 
 				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f8eaa38..4a9a305 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -91,6 +91,7 @@
 #address-cells = <3>;
 #size-cells = <2>;
 
+				msi-parent = <&mpic>;
 				bus-range = <0x00 0xff>;
 
 				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2d9335d..dd23e96 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -111,6 +111,7 @@
 				#address-cells = <3>;
 				#size-cells = <2>;
 
+				msi-parent = <&mpic>;
 				bus-range = <0x00 0xff>;
 
 				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index c7b1f4d..77db2bc 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -127,6 +127,7 @@
 				#address-cells = <3>;
 				#size-cells = <2>;
 
+				msi-parent = <&mpic>;
 				bus-range = <0x00 0xff>;
 
 				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 07:52:46 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 13:52:46 +0200
Subject: [PATCHv5 10/11] PCI: mvebu: add support for MSI
In-Reply-To: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373889167-27878-11-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds support for Message Signaled Interrupts in the
Marvell PCIe host controller. The work is very simple: it simply gets
a reference to the msi_chip associated to the PCIe controller thanks
to the msi-parent DT property, and stores this reference in the
pci_bus structure. This is enough to let the Linux PCI core use the
functions of msi_chip to setup and teardown MSIs.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Reviewed-by: Thierry Reding <thierry.reding at gmail.com>
Acked-by: Bjorn Helgaas <bhelgaas at google.com>
---
 .../devicetree/bindings/pci/mvebu-pci.txt          |  3 +++
 drivers/pci/host/pci-mvebu.c                       | 26 ++++++++++++++++++++++
 2 files changed, 29 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index f8d4058..77e0ffe 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -12,6 +12,8 @@ Mandatory properties:
 - device_type, set to "pci"
 - ranges: ranges for the PCI memory and I/O regions, as well as the
   MMIO registers to control the PCIe interfaces.
+- msi-parent: Link to the hardware entity that serves as the Message
+  Signaled Interrupt controller for this PCI controller.
 
 In addition, the Device Tree node must have sub-nodes describing each
 PCIe interface, having the following mandatory properties:
@@ -46,6 +48,7 @@ pcie-controller {
 	#size-cells = <2>;
 
 	bus-range = <0x00 0xff>;
+	msi-parent = <&mpic>;
 
 	ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
 		  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 13a633b..5715a97 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -11,6 +11,7 @@
 #include <linux/clk.h>
 #include <linux/module.h>
 #include <linux/mbus.h>
+#include <linux/msi.h>
 #include <linux/slab.h>
 #include <linux/platform_device.h>
 #include <linux/of_address.h>
@@ -107,6 +108,7 @@ struct mvebu_pcie_port;
 struct mvebu_pcie {
 	struct platform_device *pdev;
 	struct mvebu_pcie_port *ports;
+	struct msi_chip *msi;
 	struct resource io;
 	struct resource realio;
 	struct resource mem;
@@ -695,6 +697,12 @@ static struct pci_bus *mvebu_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 	return bus;
 }
 
+void mvebu_pcie_add_bus(struct pci_bus *bus)
+{
+	struct mvebu_pcie *pcie = sys_to_pcie(bus->sysdata);
+	bus->msi = pcie->msi;
+}
+
 resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev,
 					  const struct resource *res,
 					  resource_size_t start,
@@ -731,6 +739,7 @@ static void __init mvebu_pcie_enable(struct mvebu_pcie *pcie)
 	hw.map_irq        = mvebu_pcie_map_irq;
 	hw.ops            = &mvebu_pcie_ops;
 	hw.align_resource = mvebu_pcie_align_resource;
+	hw.add_bus        = mvebu_pcie_add_bus;
 
 	pci_common_init(&hw);
 }
@@ -755,6 +764,21 @@ mvebu_pcie_map_registers(struct platform_device *pdev,
 	return devm_request_and_ioremap(&pdev->dev, &regs);
 }
 
+static void __init mvebu_pcie_msi_enable(struct mvebu_pcie *pcie)
+{
+	struct device_node *msi_node;
+
+	msi_node = of_parse_phandle(pcie->pdev->dev.of_node,
+				    "msi-parent", 0);
+	if (!msi_node)
+		return;
+
+	pcie->msi = of_pci_find_msi_chip_by_node(msi_node);
+
+	if (pcie->msi)
+		pcie->msi->dev = &pcie->pdev->dev;
+}
+
 static int __init mvebu_pcie_probe(struct platform_device *pdev)
 {
 	struct mvebu_pcie *pcie;
@@ -879,6 +903,8 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
 		i++;
 	}
 
+	mvebu_pcie_msi_enable(pcie);
+
 	mvebu_pcie_enable(pcie);
 
 	return 0;
-- 
1.8.1.2



From grygorii.strashko at ti.com  Mon Jul 15 07:56:18 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Mon, 15 Jul 2013 14:56:18 +0300
Subject: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <51E05F6C.1060506@metafoo.de>
References: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1373613482-28390-3-git-send-email-oleksandr.kozaruk@ti.com>
 <51E05F6C.1060506@metafoo.de>
Message-ID: <51E3E362.6090903@ti.com>

Hi All,

I have a question regarding this patch and IIO in general
- Does IIO provide sync mechanism with system wide suspend/resume or 
this should be handled by each driver itself?

What if during system suspend iio_read_channel_raw() (or any other 
consumer API) will be called after gpadc driver have been suspended 
already? (I did some investigation and seems it's possible - Am I right?)

If no, could "info_exist_lock" be reused for such purposes?

Regards,
-grygorii


On 07/12/2013 10:56 PM, Lars-Peter Clausen wrote:
>
> A couple of comments inline.
>
> On 07/12/2013 09:18 AM, Oleksandr Kozaruk wrote:
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index ab0767e6..87d699e 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -157,4 +157,12 @@ config VIPERBOARD_ADC
>>         Say yes here to access the ADC part of the Nano River
>>         Technologies Viperboard.
>>
>> +config TWL6030_GPADC
>> +    tristate "TWL6030 GPADC (General Purpose A/D Convertor) Support"
>> +    depends on TWL4030_CORE
>> +    default n
>> +    help
>> +      Say yes here if you want support for the TWL6030 General Purpose
>> +      A/D Convertor.
>> +
>
> Keep it in alphabetical order
>
>>   endmenu
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index 0a825be..8b05633 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o
>>   obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>   obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>>   obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
>> +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
>
> Same here.
>
>> diff --git a/drivers/iio/adc/twl6030-gpadc.c
>> b/drivers/iio/adc/twl6030-gpadc.c
>> new file mode 100644
>> index 0000000..6ceb789
>> --- /dev/null
>> +++ b/drivers/iio/adc/twl6030-gpadc.c
>> @@ -0,0 +1,1019 @@
> [...]
>> +static u8 twl6032_channel_to_reg(int channel)
>> +{
>> +    return TWL6032_GPADC_GPCH0_LSB;
>
> There is more than one channel, isn't there?
>
> [...]
>  > +static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
>  > +                 const struct iio_chan_spec *chan,
>  > +                 int *val, int *val2, long mask)
>  > +{
>  > +    struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
>  > +    int ret = -EINVAL;
>  > +
>  > +    mutex_lock(&gpadc->lock);
>  > +
>  > +    ret = gpadc->pdata->start_conversion(chan->channel);
>  > +    if (ret) {
>  > +        dev_err(gpadc->dev, "failed to start conversion\n");
>  > +        goto err;
>  > +    }
>  > +    /* wait for conversion to complete */
>  > +    wait_for_completion_interruptible_timeout(&gpadc->irq_complete,
>  > +                        msecs_to_jiffies(5000));
>
> wait_for_completion_interruptible_timeout() can return either a negative
> error code if it was interrupted, 0 if it timed out, or a positive value
> if it was successfully completed. You need to handle all three cases.
> Have a look at other existing drivers to see how to do this properly.
>
>  > +
>  > +    switch (mask) {
>  > +    case IIO_CHAN_INFO_RAW:
>  > +        ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
>  > +        ret = ret ? -EIO : IIO_VAL_INT;
>  > +        break;
>  > +
>  > +    case IIO_CHAN_INFO_PROCESSED:
>  > +        ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
>  > +        ret = ret ? -EIO : IIO_VAL_INT;
>  > +        break;
>  > +
>  > +    default:
>  > +        break;
>  > +    }
>  > +err:
>  > +    mutex_unlock(&gpadc->lock);
>  > +
>  > +    return ret;
>  > +}
>
>> +}
>> +
> [...]
>> +static int twl6030_gpadc_probe(struct platform_device *pdev)
>> +{
>> +    struct device *dev = &pdev->dev;
>> +    struct twl6030_gpadc_data *gpadc;
>> +    const struct twl6030_gpadc_platform_data *pdata;
>> +    const struct of_device_id *match;
>> +    struct iio_dev *indio_dev;
>> +    int irq;
>> +    int ret = 0;
>> +
>> +    match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
>> +    pdata = match ? match->data : dev->platform_data;
>> +
>> +    if (!pdata)
>> +        return -EINVAL;
>> +
>> +    indio_dev = iio_device_alloc(sizeof(struct twl6030_gpadc_data));
>
> sizeof(*gpadc)
>
>> +    if (!indio_dev) {
>> +        dev_err(dev, "failed allocating iio device\n");
>> +        ret = -ENOMEM;
>> +    }
>> +
>> +    gpadc = iio_priv(indio_dev);
>> +
>> +    gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
>> +                    sizeof(struct twl6030_chnl_calib) *
>> +                    pdata->nchannels, GFP_KERNEL);
>> +    if (!gpadc->twl6030_cal_tbl)
>> +        goto err;
>> +
>> +    gpadc->dev = dev;
>> +    gpadc->pdata = pdata;
>> +
>> +    platform_set_drvdata(pdev, indio_dev);
>> +    mutex_init(&gpadc->lock);
>> +    init_completion(&gpadc->irq_complete);
>> +
>> +    ret = pdata->calibrate(gpadc);
>> +    if (ret < 0) {
>> +        dev_err(&pdev->dev, "failed to read calibration registers\n");
>> +        goto err;
>> +    }
>> +
>> +    irq = platform_get_irq(pdev, 0);
>> +    if (irq < 0) {
>> +        dev_err(&pdev->dev, "failed to get irq\n");
>> +        goto err;
>> +    }
>> +
>> +    ret = devm_request_threaded_irq(dev, irq, NULL,
>> +                    twl6030_gpadc_irq_handler,
>> +                    IRQF_ONESHOT, "twl6030_gpadc", gpadc);
>
> You access memory in the interrupt handler which is freed before the
> interrupt handler is freed.
>
>> +    if (ret) {
>> +        dev_dbg(&pdev->dev, "could not request irq\n");
>> +        goto err;
>> +    }
>> +
>> +    ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
>> +    if (ret < 0) {
>> +        dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
>> +        goto err;
>> +    }
>> +    ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
>> +                    TWL6030_REG_TOGGLE1);
>> +    if (ret < 0) {
>> +        dev_err(&pdev->dev, "failed to enable GPADC module\n");
>> +        goto err;
>> +    }
>> +
>> +    indio_dev->name = DRIVER_NAME;
>> +    indio_dev->dev.parent = dev;
>> +    indio_dev->info = &twl6030_gpadc_iio_info;
>> +    indio_dev->modes = INDIO_DIRECT_MODE;
>> +    indio_dev->channels = pdata->iio_channels;
>> +    indio_dev->num_channels = pdata->nchannels;
>> +
>> +    ret = iio_device_register(indio_dev);
>> +    if (ret)
>> +        goto err;
>> +
>> +    return ret;
>> +err:
>> +    iio_device_free(indio_dev);
>> +    return ret;
>> +}
>> +
> [...]
>> +static int twl6030_gpadc_suspend(struct device *pdev)
>> +{
>> +    int ret;
>> +
>> +    ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCR,
>> +                TWL6030_REG_TOGGLE1);
>> +    if (ret)
>> +        dev_err(pdev, "error reseting GPADC (%d)!\n", ret);
>> +
>> +    return 0;
>> +};
>> +
>> +static int twl6030_gpadc_resume(struct device *pdev)
>> +{
>> +    int ret;
>> +
>> +    ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
>> +                TWL6030_REG_TOGGLE1);
>> +    if (ret)
>> +        dev_err(pdev, "error setting GPADC (%d)!\n", ret);
>> +
>> +    return 0;
>> +};
>> +
>> +static const struct dev_pm_ops twl6030_gpadc_pm_ops = {
>> +    .suspend = twl6030_gpadc_suspend,
>> +    .resume = twl6030_gpadc_resume,
>> +};
>
> SIMPLE_DEV_PM_OPS?
>
> [...]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From tgih.jun at samsung.com  Mon Jul 15 08:09:40 2013
From: tgih.jun at samsung.com (Seungwon Jeon)
Date: Mon, 15 Jul 2013 21:09:40 +0900
Subject: [PATCH v2 3/5] mmc: dw_mmc: Add exynos resume_noirq callback to
 clear WAKEUP_INT
In-Reply-To: <CAD=FV=UtX0Z1ABdi5h270ks8Py2o1iPK4DonOHJH3N0Q1YShTQ@mail.gmail.com>
References: <1373391071-6312-1-git-send-email-dianders@chromium.org>
 <1373411961-23812-1-git-send-email-dianders@chromium.org>
 <1373411961-23812-4-git-send-email-dianders@chromium.org>
 <002a01ce7d7d$6bd9e870$438db950$%jun@samsung.com>
 <CAD=FV=UtX0Z1ABdi5h270ks8Py2o1iPK4DonOHJH3N0Q1YShTQ@mail.gmail.com>
Message-ID: <003f01ce8154$2f5ea1d0$8e1be570$%jun@samsung.com>

On Thu, July 11, 2013, Doug Anderson wrote:
> Seungwon,
> 
> On Wed, Jul 10, 2013 at 7:54 AM, Seungwon Jeon <tgih.jun at samsung.com> wrote:
> > On Wed, July 10, 2013, Doug Anderson wrote:
> >> If the WAKEUP_INT is asserted at wakeup and not cleared, we'll end up
> >> looping around forever.  This has been seen to happen on exynos5420
> >> silicon despite the fact that we haven't enabled any wakeup events.
> >>
> >> Signed-off-by: Doug Anderson <dianders at chromium.org>
> >> ---
> >> Changes in v2:
> >> - Use suspend_noirq as per James Hogan.
> >>
> >>  drivers/mmc/host/dw_mmc-exynos.c | 23 +++++++++++++++++++++++
> >>  1 file changed, 23 insertions(+)
> >>
> >> diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
> >> index f013e7e..36b9620 100644
> >> --- a/drivers/mmc/host/dw_mmc-exynos.c
> >> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> >> @@ -30,6 +30,7 @@
> >>  #define SDMMC_CLKSEL_TIMING(x, y, z) (SDMMC_CLKSEL_CCLK_SAMPLE(x) |  \
> >>                                       SDMMC_CLKSEL_CCLK_DRIVE(y) |    \
> >>                                       SDMMC_CLKSEL_CCLK_DIVIDER(z))
> >> +#define SDMMC_CLKSEL_WAKEUP_INT              BIT(11)
> >>
> >>  #define SDMMC_CMD_USE_HOLD_REG               BIT(29)
> >>
> >> @@ -102,6 +103,27 @@ static int dw_mci_exynos_setup_clock(struct dw_mci *host)
> >>       return 0;
> >>  }
> >>
> >> +/**
> >> + * dw_mci_exynos_resume_noirq - Exynos-specific resume code
> >> + *
> >> + * We have seen cases (at least on the exynos5420) where turning off the INT
> >> + * power rail during suspend will leave the WAKEUP_INT bit in the CLKSEL
> >> + * register asserted.  This bit is 1 to indicate that it fired and we can
> >> + * clear it by writing a 1 back.  Clear it to prevent interrupts from going off
> >> + * constantly.
> >> + */
> > As I know this bit is auto-cleared.
> > Did you find the cause of this problem?
> > How about your GPIO setting in sleep?
> > Currently, we don't know why the problem is happened.
> > At least, we should make it clear.
> 
> Yes, the documentation that I have says that this bit is "auto
> cleared" as well but doesn't indicate under what conditions it is auto
> cleared.  From testing how this bit reacts I have found that writing a
> 1 to it clears the bit--in other words it behaves like bits in
> RINTSTS.  That's a terrible design for a bit in a register with shared
> config but appears to be how it works.
> 
> Note: in a sense it will be "auto cleared" because doing a
> read-modify-write of any other bits in this register will clear the
> interrupt.
> 
> I have asked for official confirmation.
> 
> We have found that on exynos5420 bits 8-10 of CLKSEL are marked as
> RESERVED.  Those bits are documented to enable the WAKEUP_INT on
> exynos5250.  My best guess is that these bits are not used on
> exynos5420 and the WAKEUP_INT line is left floating, which means it
> can fire randomly.  I have also asked for official confirmation about
> this.
Sorry for late response.
Yes, it's not clear.
If you get the confirmation, could you share this problem?
Possibly, auto-clear may not be implemented.
Then, manual should be correct.

Thanks,
Seungwon Jeon
> 
> 
> I will likely merge this change locally in our kernel tree while
> waiting for a response.  If you would like to wait before Acking
> that's very reasonable.  Do you have any other problems with this
> change assuming my understanding above is correct?
> 
> -Doug
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From pullip.cho at samsung.com  Mon Jul 15 08:20:50 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Mon, 15 Jul 2013 21:20:50 +0900
Subject: [PATCH v7 00/12] iommu/exynos: Fixes and Enhancements of System
 MMU driver with DT
References: <002801ce797b$3d2fbc80$b78f3580$@samsung.com>
 <CANEJEGvajhgzUPG6ppbjwBb4-9TdU9em3T_SejBpz8NCjGHYTQ@mail.gmail.com>
Message-ID: <00a701ce8155$be139240$3a3ab6c0$@samsung.com>

> From: Cho KyongHo [mailto:pullip.cho at samsung.com]
> Sent: Monday, July 15, 2013 8:24 PM
> 
> > From: grundler at google.com [mailto:grundler at google.com] On Behalf Of Grant Grundler
> > Sent: Friday, July 12, 2013 2:23 AM
> >
> > On Fri, Jul 5, 2013 at 5:29 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> > > The current exynos-iommu(System MMU) driver does not work autonomously
> > > since it is lack of support for power management of peripheral blocks.
> > ...
> > > Patch summary:
> > > [PATCH v7 1/9] iommu/exynos: do not include removed header
> > > [PATCH v7 2/9] iommu/exynos: add missing cache flush for removed page table entries
> > > [PATCH v7 3/9] iommu/exynos: fix page table maintenance
> > > [PATCH v7 4/9] iommu/exynos: allocate lv2 page table from own slab
> > > [PATCH v7 5/9] iommu/exynos: change rwlock to spinlock
> > > [PATCH v7 6/9] clk: exynos5250: add gate clock descriptions of System MMU
> > > [PATCH v7 7/9] ARM: dts: Add description of System MMU of Exynos SoCs
> > > [PATCH v7 8/9] iommu/exynos: support for device tree
> > > [PATCH v7 9/9] iommu/exynos: add bus notifier for registering System MMU
> >
> > Cho,
> > Of the above patches, nearly all have been applied to chromeos-3.8
> > (kernel-next git tree) by Doug Anderson and others.
> >
> > AFAICT, the only ones not applied are:
> >    [v7,3/9] iommu/exynos: fix page table maintenance
> >    [v7,6/9] clk: exynos5250: add gate clock descriptions of System MMU
> > (conflicts in this one)
> >    [v7,7/9] ARM: dts: Add description of System MMU of Exynos SoCs
> > (depends on 6/9)
> >
> > We also already have parts of:
> >    [v7,9/9] iommu/exynos: add bus notifier for registering System MMU
> >
> > Some of those are being further discussed but I've lost track now
> > exactly which ones.
> >
> > I'm telling you about chromeos-3.8 status since the adopted changes
> > have been reviewed (by me and others) are being tested manually here
> > on several different Samsung Exynos platforms (including 5250 which is
> > our "snow" platform). Not sure how you should to mark those patches
> > since they aren't identical to your changes (which apply to post 3.10
> > kernels, not 3.8).  You might consider splitting those patches out
> > from the 4 I've listed above to get that series accepted upstream
> > since the additional review/testing should provide some confidence
> > those patches are good.
> >
> 
> I understand what you are concerning about.
> Have you applied v6 patchset?
> 
> I will try to split the patches and make the changes from v6
> on top of the v6 patcheset.
> 

Actually, as you know, the previous patches include setting a System MMU
as the parent device of its master device in probe() of System MMU.
I asked Greg KH about changing device hierarchy in probe() and he answered
that it is not a good idea because it modifies sysfs even though probe() of
System MMU driver is called before sysfs is constructed.

That's why I uses genpd_pm_ops.
It results in big change in the patches after registering device tree.

I want to ask your opinion about this change :)

> > cheers,
> > grant
> 
> Thank you.
> 
> Cho KyonogHo.



From lars at metafoo.de  Mon Jul 15 08:33:32 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Mon, 15 Jul 2013 14:33:32 +0200
Subject: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <51E3E362.6090903@ti.com>
References: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1373613482-28390-3-git-send-email-oleksandr.kozaruk@ti.com>
 <51E05F6C.1060506@metafoo.de> <51E3E362.6090903@ti.com>
Message-ID: <51E3EC1C.9090507@metafoo.de>

On 07/15/2013 01:56 PM, Grygorii Strashko wrote:
> Hi All,
> 
> I have a question regarding this patch and IIO in general
> - Does IIO provide sync mechanism with system wide suspend/resume or this
> should be handled by each driver itself?
> 
> What if during system suspend iio_read_channel_raw() (or any other consumer
> API) will be called after gpadc driver have been suspended already? (I did
> some investigation and seems it's possible - Am I right?)
> 
> If no, could "info_exist_lock" be reused for such purposes?

I think you can use the mlock for this purpose. Usually you'd have a flag in
your driver struct which you'd set to true in suspend and to false in
resume. And in the read_raw callback you'd check that flag before accessing
the hardware. If it turns out that this is a common pattern it probably
makes sense to add infrastructure for this to the IIO core. Something along
the lines of:

static int drv_suspend(...)
{
	...
	iio_device_set_suspended(iio_dev, true);
	...
}

static int drv_suspend(...)
{
	...
	iio_device_set_suspended(iio_dev, false);
	...
}

and then have the IIO core check that flag before calling the read_raw callback.

- Lars

> 
> Regards,
> -grygorii
> 
> 
> On 07/12/2013 10:56 PM, Lars-Peter Clausen wrote:
>>
>> A couple of comments inline.
>>
>> On 07/12/2013 09:18 AM, Oleksandr Kozaruk wrote:
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index ab0767e6..87d699e 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -157,4 +157,12 @@ config VIPERBOARD_ADC
>>>         Say yes here to access the ADC part of the Nano River
>>>         Technologies Viperboard.
>>>
>>> +config TWL6030_GPADC
>>> +    tristate "TWL6030 GPADC (General Purpose A/D Convertor) Support"
>>> +    depends on TWL4030_CORE
>>> +    default n
>>> +    help
>>> +      Say yes here if you want support for the TWL6030 General Purpose
>>> +      A/D Convertor.
>>> +
>>
>> Keep it in alphabetical order
>>
>>>   endmenu
>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>> index 0a825be..8b05633 100644
>>> --- a/drivers/iio/adc/Makefile
>>> +++ b/drivers/iio/adc/Makefile
>>> @@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o
>>>   obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>>   obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>>>   obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
>>> +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
>>
>> Same here.
>>
>>> diff --git a/drivers/iio/adc/twl6030-gpadc.c
>>> b/drivers/iio/adc/twl6030-gpadc.c
>>> new file mode 100644
>>> index 0000000..6ceb789
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/twl6030-gpadc.c
>>> @@ -0,0 +1,1019 @@
>> [...]
>>> +static u8 twl6032_channel_to_reg(int channel)
>>> +{
>>> +    return TWL6032_GPADC_GPCH0_LSB;
>>
>> There is more than one channel, isn't there?
>>
>> [...]
>>  > +static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
>>  > +                 const struct iio_chan_spec *chan,
>>  > +                 int *val, int *val2, long mask)
>>  > +{
>>  > +    struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
>>  > +    int ret = -EINVAL;
>>  > +
>>  > +    mutex_lock(&gpadc->lock);
>>  > +
>>  > +    ret = gpadc->pdata->start_conversion(chan->channel);
>>  > +    if (ret) {
>>  > +        dev_err(gpadc->dev, "failed to start conversion\n");
>>  > +        goto err;
>>  > +    }
>>  > +    /* wait for conversion to complete */
>>  > +    wait_for_completion_interruptible_timeout(&gpadc->irq_complete,
>>  > +                        msecs_to_jiffies(5000));
>>
>> wait_for_completion_interruptible_timeout() can return either a negative
>> error code if it was interrupted, 0 if it timed out, or a positive value
>> if it was successfully completed. You need to handle all three cases.
>> Have a look at other existing drivers to see how to do this properly.
>>
>>  > +
>>  > +    switch (mask) {
>>  > +    case IIO_CHAN_INFO_RAW:
>>  > +        ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
>>  > +        ret = ret ? -EIO : IIO_VAL_INT;
>>  > +        break;
>>  > +
>>  > +    case IIO_CHAN_INFO_PROCESSED:
>>  > +        ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
>>  > +        ret = ret ? -EIO : IIO_VAL_INT;
>>  > +        break;
>>  > +
>>  > +    default:
>>  > +        break;
>>  > +    }
>>  > +err:
>>  > +    mutex_unlock(&gpadc->lock);
>>  > +
>>  > +    return ret;
>>  > +}
>>
>>> +}
>>> +
>> [...]
>>> +static int twl6030_gpadc_probe(struct platform_device *pdev)
>>> +{
>>> +    struct device *dev = &pdev->dev;
>>> +    struct twl6030_gpadc_data *gpadc;
>>> +    const struct twl6030_gpadc_platform_data *pdata;
>>> +    const struct of_device_id *match;
>>> +    struct iio_dev *indio_dev;
>>> +    int irq;
>>> +    int ret = 0;
>>> +
>>> +    match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
>>> +    pdata = match ? match->data : dev->platform_data;
>>> +
>>> +    if (!pdata)
>>> +        return -EINVAL;
>>> +
>>> +    indio_dev = iio_device_alloc(sizeof(struct twl6030_gpadc_data));
>>
>> sizeof(*gpadc)
>>
>>> +    if (!indio_dev) {
>>> +        dev_err(dev, "failed allocating iio device\n");
>>> +        ret = -ENOMEM;
>>> +    }
>>> +
>>> +    gpadc = iio_priv(indio_dev);
>>> +
>>> +    gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
>>> +                    sizeof(struct twl6030_chnl_calib) *
>>> +                    pdata->nchannels, GFP_KERNEL);
>>> +    if (!gpadc->twl6030_cal_tbl)
>>> +        goto err;
>>> +
>>> +    gpadc->dev = dev;
>>> +    gpadc->pdata = pdata;
>>> +
>>> +    platform_set_drvdata(pdev, indio_dev);
>>> +    mutex_init(&gpadc->lock);
>>> +    init_completion(&gpadc->irq_complete);
>>> +
>>> +    ret = pdata->calibrate(gpadc);
>>> +    if (ret < 0) {
>>> +        dev_err(&pdev->dev, "failed to read calibration registers\n");
>>> +        goto err;
>>> +    }
>>> +
>>> +    irq = platform_get_irq(pdev, 0);
>>> +    if (irq < 0) {
>>> +        dev_err(&pdev->dev, "failed to get irq\n");
>>> +        goto err;
>>> +    }
>>> +
>>> +    ret = devm_request_threaded_irq(dev, irq, NULL,
>>> +                    twl6030_gpadc_irq_handler,
>>> +                    IRQF_ONESHOT, "twl6030_gpadc", gpadc);
>>
>> You access memory in the interrupt handler which is freed before the
>> interrupt handler is freed.
>>
>>> +    if (ret) {
>>> +        dev_dbg(&pdev->dev, "could not request irq\n");
>>> +        goto err;
>>> +    }
>>> +
>>> +    ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
>>> +    if (ret < 0) {
>>> +        dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
>>> +        goto err;
>>> +    }
>>> +    ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
>>> +                    TWL6030_REG_TOGGLE1);
>>> +    if (ret < 0) {
>>> +        dev_err(&pdev->dev, "failed to enable GPADC module\n");
>>> +        goto err;
>>> +    }
>>> +
>>> +    indio_dev->name = DRIVER_NAME;
>>> +    indio_dev->dev.parent = dev;
>>> +    indio_dev->info = &twl6030_gpadc_iio_info;
>>> +    indio_dev->modes = INDIO_DIRECT_MODE;
>>> +    indio_dev->channels = pdata->iio_channels;
>>> +    indio_dev->num_channels = pdata->nchannels;
>>> +
>>> +    ret = iio_device_register(indio_dev);
>>> +    if (ret)
>>> +        goto err;
>>> +
>>> +    return ret;
>>> +err:
>>> +    iio_device_free(indio_dev);
>>> +    return ret;
>>> +}
>>> +
>> [...]
>>> +static int twl6030_gpadc_suspend(struct device *pdev)
>>> +{
>>> +    int ret;
>>> +
>>> +    ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCR,
>>> +                TWL6030_REG_TOGGLE1);
>>> +    if (ret)
>>> +        dev_err(pdev, "error reseting GPADC (%d)!\n", ret);
>>> +
>>> +    return 0;
>>> +};
>>> +
>>> +static int twl6030_gpadc_resume(struct device *pdev)
>>> +{
>>> +    int ret;
>>> +
>>> +    ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
>>> +                TWL6030_REG_TOGGLE1);
>>> +    if (ret)
>>> +        dev_err(pdev, "error setting GPADC (%d)!\n", ret);
>>> +
>>> +    return 0;
>>> +};
>>> +
>>> +static const struct dev_pm_ops twl6030_gpadc_pm_ops = {
>>> +    .suspend = twl6030_gpadc_suspend,
>>> +    .resume = twl6030_gpadc_resume,
>>> +};
>>
>> SIMPLE_DEV_PM_OPS?
>>
>> [...]
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



From marc.zyngier at arm.com  Mon Jul 15 08:39:22 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Jul 2013 13:39:22 +0100
Subject: [PATCH] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene host
In-Reply-To: <1373888788-8055-1-git-send-email-anup.patel@linaro.org>
References: <1373888788-8055-1-git-send-email-anup.patel@linaro.org>
Message-ID: <51E3ED7A.7050207@arm.com>

Hi Anup,

On 15/07/13 12:46, Anup Patel wrote:
> This patch allows us to have X-Gene guest VCPU when using
> KVM arm64 on APM X-Gene host.
> 
> We add KVM_ARM_TARGET_XGENE_V8 for X-Gene compatible guest VCPU
> and we return KVM_ARM_TARGET_XGENE_V8 in kvm_target_cpu() when
> running on X-Gene host.
> 
> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> ---
>  arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
>  arch/arm64/kvm/guest.c               |   34 ++++++++++++++++++++++------------
>  arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
>  3 files changed, 27 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 5031f42..8194707 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -55,8 +55,9 @@ struct kvm_regs {
>  #define KVM_ARM_TARGET_AEM_V8		0
>  #define KVM_ARM_TARGET_FOUNDATION_V8	1
>  #define KVM_ARM_TARGET_CORTEX_A57	2
> +#define KVM_ARM_TARGET_XGENE_V8		3
>  
> -#define KVM_ARM_NUM_TARGETS		3
> +#define KVM_ARM_NUM_TARGETS		4
>  
>  /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
>  #define KVM_ARM_DEVICE_TYPE_SHIFT	0
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 2c3ff67..e99b0a5 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -207,19 +207,29 @@ int __attribute_const__ kvm_target_cpu(void)
>  	unsigned long implementor = read_cpuid_implementor();
>  	unsigned long part_number = read_cpuid_part_number();
>  
> -	if (implementor != ARM_CPU_IMP_ARM)
> -		return -EINVAL;
> -
> -	switch (part_number) {
> -	case ARM_CPU_PART_AEM_V8:
> -		return KVM_ARM_TARGET_AEM_V8;
> -	case ARM_CPU_PART_FOUNDATION:
> -		return KVM_ARM_TARGET_FOUNDATION_V8;
> -	case ARM_CPU_PART_CORTEX_A57:
> -		/* Currently handled by the generic backend */
> -		return KVM_ARM_TARGET_CORTEX_A57;
> +	switch (implementor) {
> +	case ARM_CPU_IMP_ARM:
> +		switch (part_number) {
> +		case ARM_CPU_PART_AEM_V8:
> +			return KVM_ARM_TARGET_AEM_V8;
> +		case ARM_CPU_PART_FOUNDATION:
> +			return KVM_ARM_TARGET_FOUNDATION_V8;
> +		case ARM_CPU_PART_CORTEX_A57:
> +			return KVM_ARM_TARGET_CORTEX_A57;
> +		default:
> +			return -EINVAL;
> +		}
> +		break;
> +	case ARM_CPU_IMP_APM:
> +		switch (part_number) {
> +		case APM_CPU_PART_POTENZA:
> +			return KVM_ARM_TARGET_XGENE_V8;

Why don't we have KVM_ARM_TARGET_XGENE_POTENZA (or something similar)
instead? I don't expect all the X-Gene CPUs to be the same forever...

	M.
-- 
Jazz is not dead. It just smells funny...



From mugunthanvnm at ti.com  Mon Jul 15 08:45:27 2013
From: mugunthanvnm at ti.com (Mugunthan V N)
Date: Mon, 15 Jul 2013 18:15:27 +0530
Subject: [PATCH] remove vlan tags in CPSW dual emac mode
In-Reply-To: <51E0582D.4090306@newflow.co.uk>
References: <4699400.vD3TdgH1nR@localhost> <5176C4FE.4080305@ti.com>
 <51E00B2F.6050406@newflow.co.uk> <51E04C89.8030202@ti.com>
 <51E0582D.4090306@newflow.co.uk>
Message-ID: <51E3EEE7.9030508@ti.com>

On 7/13/2013 12:55 AM, Mark Jackson wrote:
> On 12/07/13 19:35, Mugunthan V N wrote:
>> On 7/12/2013 7:27 PM, Mark Jackson wrote:
> [snip]
>
>>> Just to update this (old) thread ...
>>>
>>> I can still confirm that *without* the above patch, I am *unable* to use both network
>>> ports on our AM335x board.
>>>
> [snip]
>
>>> So I'm not sure what's wrong, but it's *definitely* not correct.
>>>
>>>
>> I am sure that current code in mainline works for Dual EMAC. I can test it
>> again and share the images with you if are interested. But had tested with DHCP
>> on both the interfaces.
> Hmmm ... well it's not working for me.  What hardware are you testing it on ?
>
> I tried DHCP to start with, and switched to static IP when that failed.
> Then I recalled this patch and re-applied it ... hey presto !!
>
> Markus, are you still using this patch ?
>
Today I have tested the Dual EMAC on my am335x-evmsk and its working fine with
net/master branch.
I had 3 patches additional to net/master in which two for basic boot of EVMsk
and one for enabling Dual EMAC. I had pushed the branch in the below repo
repo:
git://git.ti.com/~mugunthanvnm/ti-linux-kernel/mugunth-connectivity-linux-feature-tree.git
branch: dual-emac

Regards
Mugunthan V N


From maxime.ripard at free-electrons.com  Mon Jul 15 08:52:13 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 15 Jul 2013 14:52:13 +0200
Subject: [PATCH 1/5] iio: at91: use adc_clk_khz to make the calculation
 not easy to large than u32.
In-Reply-To: <1373789069-11604-2-git-send-email-josh.wu@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-2-git-send-email-josh.wu@atmel.com>
Message-ID: <20130715125213.GB2962@lukather>

Hi Josh,

On Sun, Jul 14, 2013 at 04:04:25PM +0800, Josh Wu wrote:
> for example, if adc_clk is 20Mhz and start-up time set as larger than 215us.
> then the calculation "st->startup_time * adc_clk_khz" will out of u32.
> 
> In this patch, it will use khz unit for adc_clk, that avoids above problem.
> 
> Signed-off-by: Josh Wu <josh.wu at atmel.com>

Maybe we can have a slightly better commit log here, like:

------8<-----------
iio: at91: Fix adc_clk overflow

The adc_clk variable is currently defined using a 32-bits unsigned
integer, which will overflow under some very valid range of operations.

Such overflow will occur if, for example, the parent clock is set to a
20MHz frequency and the ADC startup time is larger than 215ns.

To fix this, introduce an intermediate variable holding the clock rate
in kHz.

--------8<---------------

Or something like that.

For the patch itself, I'm happy about it. You can add my Acked-by.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130715/b37339f0/attachment.sig>

From anup at brainfault.org  Mon Jul 15 08:56:46 2013
From: anup at brainfault.org (Anup Patel)
Date: Mon, 15 Jul 2013 18:26:46 +0530
Subject: [PATCH] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene host
In-Reply-To: <51E3ED7A.7050207@arm.com>
References: <1373888788-8055-1-git-send-email-anup.patel@linaro.org>
 <51E3ED7A.7050207@arm.com>
Message-ID: <CAAhSdy25WVnynDyPcOMtqVNEepGGq9WFT3b1PV34P6iSBm-FUg@mail.gmail.com>

Hi Marc,

On Mon, Jul 15, 2013 at 6:09 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> Hi Anup,
>
> On 15/07/13 12:46, Anup Patel wrote:
>> This patch allows us to have X-Gene guest VCPU when using
>> KVM arm64 on APM X-Gene host.
>>
>> We add KVM_ARM_TARGET_XGENE_V8 for X-Gene compatible guest VCPU
>> and we return KVM_ARM_TARGET_XGENE_V8 in kvm_target_cpu() when
>> running on X-Gene host.
>>
>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>> ---
>>  arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
>>  arch/arm64/kvm/guest.c               |   34 ++++++++++++++++++++++------------
>>  arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
>>  3 files changed, 27 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 5031f42..8194707 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -55,8 +55,9 @@ struct kvm_regs {
>>  #define KVM_ARM_TARGET_AEM_V8                0
>>  #define KVM_ARM_TARGET_FOUNDATION_V8 1
>>  #define KVM_ARM_TARGET_CORTEX_A57    2
>> +#define KVM_ARM_TARGET_XGENE_V8              3
>>
>> -#define KVM_ARM_NUM_TARGETS          3
>> +#define KVM_ARM_NUM_TARGETS          4
>>
>>  /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
>>  #define KVM_ARM_DEVICE_TYPE_SHIFT    0
>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>> index 2c3ff67..e99b0a5 100644
>> --- a/arch/arm64/kvm/guest.c
>> +++ b/arch/arm64/kvm/guest.c
>> @@ -207,19 +207,29 @@ int __attribute_const__ kvm_target_cpu(void)
>>       unsigned long implementor = read_cpuid_implementor();
>>       unsigned long part_number = read_cpuid_part_number();
>>
>> -     if (implementor != ARM_CPU_IMP_ARM)
>> -             return -EINVAL;
>> -
>> -     switch (part_number) {
>> -     case ARM_CPU_PART_AEM_V8:
>> -             return KVM_ARM_TARGET_AEM_V8;
>> -     case ARM_CPU_PART_FOUNDATION:
>> -             return KVM_ARM_TARGET_FOUNDATION_V8;
>> -     case ARM_CPU_PART_CORTEX_A57:
>> -             /* Currently handled by the generic backend */
>> -             return KVM_ARM_TARGET_CORTEX_A57;
>> +     switch (implementor) {
>> +     case ARM_CPU_IMP_ARM:
>> +             switch (part_number) {
>> +             case ARM_CPU_PART_AEM_V8:
>> +                     return KVM_ARM_TARGET_AEM_V8;
>> +             case ARM_CPU_PART_FOUNDATION:
>> +                     return KVM_ARM_TARGET_FOUNDATION_V8;
>> +             case ARM_CPU_PART_CORTEX_A57:
>> +                     return KVM_ARM_TARGET_CORTEX_A57;
>> +             default:
>> +                     return -EINVAL;
>> +             }
>> +             break;
>> +     case ARM_CPU_IMP_APM:
>> +             switch (part_number) {
>> +             case APM_CPU_PART_POTENZA:
>> +                     return KVM_ARM_TARGET_XGENE_V8;
>
> Why don't we have KVM_ARM_TARGET_XGENE_POTENZA (or something similar)
> instead? I don't expect all the X-Gene CPUs to be the same forever...

OK, I will rename it to KVM_ARM_TARGET_XGENE_POTENZA.

Does this mean that with every new ARM64 CPU we will have to add a new
target for KVM ARM64 ?

If so then I think the list of targets will grow very fast.

I also realized that if we add a new target type in KVM ARM64 then we have
to also update KVMTOOL to use the new target else KVMTOOL fails to
recognize the target provided by KVM ARM64.

Do you think we can have KVM_ARM_TARGET_xxx to represent a common
target for a family of CPUs from given ARM64 vendor?

>
>         M.
> --
> Jazz is not dead. It just smells funny...
>
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

Regards,
Anup


From maxime.ripard at free-electrons.com  Mon Jul 15 08:58:15 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 15 Jul 2013 14:58:15 +0200
Subject: [PATCH 2/5] iio: at91: Use different prescal, startup mask in MR
 for different IP
In-Reply-To: <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
Message-ID: <20130715125815.GC2962@lukather>

Hi Josh,

On Sun, Jul 14, 2013 at 04:04:26PM +0800, Josh Wu wrote:
> For at91 boards, there are different IPs for adc. Different IPs has different
> STARTUP & PRESCAL mask in ADC_MR.
> 
> This patch can change the masks according to the different IP version.
> 
> Signed-off-by: Josh Wu <josh.wu at atmel.com>
> ---
>  arch/arm/mach-at91/include/mach/at91_adc.h |    9 ++++--
>  drivers/iio/adc/at91_adc.c                 |   48 ++++++++++++++++++++++++++--
>  2 files changed, 53 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/include/mach/at91_adc.h b/arch/arm/mach-at91/include/mach/at91_adc.h
> index 8e7ed5c..ab273ee 100644
> --- a/arch/arm/mach-at91/include/mach/at91_adc.h
> +++ b/arch/arm/mach-at91/include/mach/at91_adc.h
> @@ -28,9 +28,12 @@
>  #define			AT91_ADC_TRGSEL_EXTERNAL	(6 << 1)
>  #define		AT91_ADC_LOWRES		(1 << 4)	/* Low Resolution */
>  #define		AT91_ADC_SLEEP		(1 << 5)	/* Sleep Mode */
> -#define		AT91_ADC_PRESCAL	(0x3f << 8)	/* Prescalar Rate Selection */
> +#define		AT91_ADC_PRESCAL	(0xff << 8)	/* Prescalar Rate Selection */
> +#define		AT91_ADC_PRESCAL_9260	(0x3f << 8)
>  #define			AT91_ADC_PRESCAL_(x)	((x) << 8)
> -#define		AT91_ADC_STARTUP	(0x1f << 16)	/* Startup Up Time */
> +#define		AT91_ADC_STARTUP	(0xf << 16)	/* Startup Up Time */
> +#define		AT91_ADC_STARTUP_9260	(0x1f << 16)
> +#define		AT91_ADC_STARTUP_9G45	(0x7f << 16)
>  #define			AT91_ADC_STARTUP_(x)	((x) << 16)
>  #define		AT91_ADC_SHTIM		(0xf  << 24)	/* Sample & Hold Time */
>  #define			AT91_ADC_SHTIM_(x)	((x) << 24)
> @@ -58,4 +61,6 @@
>  #define AT91_ADC_CHR(n)		(0x30 + ((n) * 4))	/* Channel Data Register N */
>  #define		AT91_ADC_DATA		(0x3ff)
>  
> +#define AT91_ADC_VERSION	0xFC
> +
>  #endif
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index 18bd54f..14e99ba 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -39,6 +39,12 @@
>  #define at91_adc_writel(st, reg, val) \
>  	(writel_relaxed(val, st->reg_base + reg))
>  
> +struct at91_adc_caps {
> +	bool	has_tsmr;	/* only at91sam9x5, sama5d3 have TSMR reg */
> +	u32	mr_prescal_mask;
> +	u32	mr_startup_mask;
> +};
> +
>  struct at91_adc_state {
>  	struct clk		*adc_clk;
>  	u16			*buffer;
> @@ -62,6 +68,7 @@ struct at91_adc_state {
>  	u32			res;		/* resolution used for convertions */
>  	bool			low_res;	/* the resolution corresponds to the lowest one */
>  	wait_queue_head_t	wq_data_avail;
> +	struct at91_adc_caps	caps;
>  };
>  
>  static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
> @@ -580,6 +587,41 @@ static const struct iio_info at91_adc_info = {
>  	.read_raw = &at91_adc_read_raw,
>  };
>  
> +/*
> + * Since atmel adc support different ip for touchscreen mode. Through the
> + * IP check, we will know the touchscreen capbilities.
> + */
> +static void atmel_adc_get_cap(struct at91_adc_state *st)
> +{
> +	unsigned int version;
> +	struct iio_dev *idev = iio_priv_to_dev(st);
> +
> +	version = at91_adc_readl(st, AT91_ADC_VERSION);
> +	dev_dbg(&idev->dev, "version: 0x%x\n", version);
> +
> +	st->caps.mr_prescal_mask = AT91_ADC_PRESCAL_9260;
> +	st->caps.mr_startup_mask = AT91_ADC_STARTUP_9260;
> +
> +	/* keep only major version number */
> +	switch (version & 0xf00) {
> +	case 0x500:	/* SAMA5D3 */
> +	case 0x400:	/* AT91SAM9X5/9N12 */
> +		st->caps.has_tsmr = 1;
> +		st->caps.mr_startup_mask = AT91_ADC_STARTUP;
> +	case 0x200:	/* AT91SAM9M10/9G45 */
> +		st->caps.mr_prescal_mask = AT91_ADC_PRESCAL;
> +
> +		if ((version & 0xf00) == 0x200)
> +			st->caps.mr_startup_mask = AT91_ADC_STARTUP_9G45;
> +	case 0x100:	/* AT91SAM9260/9G20 */
> +		break;
> +	default:
> +		dev_warn(&idev->dev,
> +				"Unmanaged adc version, use minimal capabilities\n");
> +		break;
> +	};
> +}

Why don't you use different compatible names and derive your
capabilities from which compatible is declared.

It seems safer.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130715/896a845b/attachment.sig>

From agraf at suse.de  Mon Jul 15 09:02:47 2013
From: agraf at suse.de (Alexander Graf)
Date: Mon, 15 Jul 2013 15:02:47 +0200
Subject: [PATCH] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene host
In-Reply-To: <CAAhSdy25WVnynDyPcOMtqVNEepGGq9WFT3b1PV34P6iSBm-FUg@mail.gmail.com>
References: <1373888788-8055-1-git-send-email-anup.patel@linaro.org>
 <51E3ED7A.7050207@arm.com>
 <CAAhSdy25WVnynDyPcOMtqVNEepGGq9WFT3b1PV34P6iSBm-FUg@mail.gmail.com>
Message-ID: <73A8FA0E-9F7F-4866-9544-57838F30BB91@suse.de>


On 15.07.2013, at 14:56, Anup Patel wrote:

> Hi Marc,
> 
> On Mon, Jul 15, 2013 at 6:09 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> Hi Anup,
>> 
>> On 15/07/13 12:46, Anup Patel wrote:
>>> This patch allows us to have X-Gene guest VCPU when using
>>> KVM arm64 on APM X-Gene host.
>>> 
>>> We add KVM_ARM_TARGET_XGENE_V8 for X-Gene compatible guest VCPU
>>> and we return KVM_ARM_TARGET_XGENE_V8 in kvm_target_cpu() when
>>> running on X-Gene host.
>>> 
>>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>> ---
>>> arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
>>> arch/arm64/kvm/guest.c               |   34 ++++++++++++++++++++++------------
>>> arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
>>> 3 files changed, 27 insertions(+), 13 deletions(-)
>>> 
>>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>>> index 5031f42..8194707 100644
>>> --- a/arch/arm64/include/uapi/asm/kvm.h
>>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>>> @@ -55,8 +55,9 @@ struct kvm_regs {
>>> #define KVM_ARM_TARGET_AEM_V8                0
>>> #define KVM_ARM_TARGET_FOUNDATION_V8 1
>>> #define KVM_ARM_TARGET_CORTEX_A57    2
>>> +#define KVM_ARM_TARGET_XGENE_V8              3
>>> 
>>> -#define KVM_ARM_NUM_TARGETS          3
>>> +#define KVM_ARM_NUM_TARGETS          4
>>> 
>>> /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
>>> #define KVM_ARM_DEVICE_TYPE_SHIFT    0
>>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>>> index 2c3ff67..e99b0a5 100644
>>> --- a/arch/arm64/kvm/guest.c
>>> +++ b/arch/arm64/kvm/guest.c
>>> @@ -207,19 +207,29 @@ int __attribute_const__ kvm_target_cpu(void)
>>>      unsigned long implementor = read_cpuid_implementor();
>>>      unsigned long part_number = read_cpuid_part_number();
>>> 
>>> -     if (implementor != ARM_CPU_IMP_ARM)
>>> -             return -EINVAL;
>>> -
>>> -     switch (part_number) {
>>> -     case ARM_CPU_PART_AEM_V8:
>>> -             return KVM_ARM_TARGET_AEM_V8;
>>> -     case ARM_CPU_PART_FOUNDATION:
>>> -             return KVM_ARM_TARGET_FOUNDATION_V8;
>>> -     case ARM_CPU_PART_CORTEX_A57:
>>> -             /* Currently handled by the generic backend */
>>> -             return KVM_ARM_TARGET_CORTEX_A57;
>>> +     switch (implementor) {
>>> +     case ARM_CPU_IMP_ARM:
>>> +             switch (part_number) {
>>> +             case ARM_CPU_PART_AEM_V8:
>>> +                     return KVM_ARM_TARGET_AEM_V8;
>>> +             case ARM_CPU_PART_FOUNDATION:
>>> +                     return KVM_ARM_TARGET_FOUNDATION_V8;
>>> +             case ARM_CPU_PART_CORTEX_A57:
>>> +                     return KVM_ARM_TARGET_CORTEX_A57;
>>> +             default:
>>> +                     return -EINVAL;
>>> +             }
>>> +             break;
>>> +     case ARM_CPU_IMP_APM:
>>> +             switch (part_number) {
>>> +             case APM_CPU_PART_POTENZA:
>>> +                     return KVM_ARM_TARGET_XGENE_V8;
>> 
>> Why don't we have KVM_ARM_TARGET_XGENE_POTENZA (or something similar)
>> instead? I don't expect all the X-Gene CPUs to be the same forever...
> 
> OK, I will rename it to KVM_ARM_TARGET_XGENE_POTENZA.
> 
> Does this mean that with every new ARM64 CPU we will have to add a new
> target for KVM ARM64 ?

Only for different core types, no? Any Cortex-A57 should still behave the same.

> If so then I think the list of targets will grow very fast.
> 
> I also realized that if we add a new target type in KVM ARM64 then we have
> to also update KVMTOOL to use the new target else KVMTOOL fails to
> recognize the target provided by KVM ARM64.

Right. It might make sense to have a fetch mechanism for the host cpu part. So you can ask KVM for the host cpu type and pass that back in here.

> Do you think we can have KVM_ARM_TARGET_xxx to represent a common
> target for a family of CPUs from given ARM64 vendor?

Anything that is compatible is compatible :). I don't know the product roadmaps for X-Gene cores, but you will want to make the field here as coarse grained as possible, while maintaining the guarantee that a guest still behaves the same.


Alex



From maxime.ripard at free-electrons.com  Mon Jul 15 09:06:10 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 15 Jul 2013 15:06:10 +0200
Subject: [PATCH 4/5] iio: at91: add an optional dt property for for adc
 clock hz.
In-Reply-To: <1373789069-11604-5-git-send-email-josh.wu@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-5-git-send-email-josh.wu@atmel.com>
Message-ID: <20130715130610.GD2962@lukather>

Hi Josh,

On Sun, Jul 14, 2013 at 04:04:28PM +0800, Josh Wu wrote:
> Signed-off-by: Josh Wu <josh.wu at atmel.com>
> ---
>  Documentation/devicetree/bindings/arm/atmel-adc.txt |    2 ++
>  drivers/iio/adc/at91_adc.c                          |    8 +++++++-
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> index 16769d9..0db2945 100644
> --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> @@ -27,6 +27,8 @@ Optional properties:
>  		       resolution will be used.
>    - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
>    - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
> +  - atmel,adc-clock-rate: ADC clock rate. If not specified, use the default
> +			  adc_op_clk.
>   
>  Optional trigger Nodes:
>    - Required properties:
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index e93a075..8f1386f 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -47,6 +47,7 @@ struct at91_adc_caps {
>  
>  struct at91_adc_state {
>  	struct clk		*adc_clk;
> +	u32			adc_clk_rate;
>  	u16			*buffer;
>  	unsigned long		channels_mask;
>  	struct clk		*clk;
> @@ -448,6 +449,10 @@ static int at91_adc_probe_dt(struct at91_adc_state *st,
>  	if (!node)
>  		return -EINVAL;
>  
> +	prop = 0;
> +	of_property_read_u32(node, "atmel,adc-clock-rate", &prop);
> +	st->adc_clk_rate = prop;
> +
>  	st->use_external = of_property_read_bool(node, "atmel,adc-use-external-triggers");
>  
>  	if (of_property_read_u32(node, "atmel,adc-channels-used", &prop)) {
> @@ -723,7 +728,8 @@ static int at91_adc_probe(struct platform_device *pdev)
>  	 * specified by the electrical characteristics of the board.
>  	 */
>  	mstrclk = clk_get_rate(st->clk);
> -	adc_clk = clk_get_rate(st->adc_clk);
> +	adc_clk = st->adc_clk_rate ?
> +		st->adc_clk_rate : clk_get_rate(st->adc_clk);

Why is that needed? Isn't it completely redundant with the clocks
property?

Maxime


-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130715/bc33e590/attachment-0001.sig>

From maxime.ripard at free-electrons.com  Mon Jul 15 09:15:07 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 15 Jul 2013 15:15:07 +0200
Subject: [PATCH 5/5] iio: at91: introduce touch screen support in iio adc
 driver
In-Reply-To: <1373789069-11604-6-git-send-email-josh.wu@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-6-git-send-email-josh.wu@atmel.com>
Message-ID: <20130715131507.GE2962@lukather>

Hi Josh,

On Sun, Jul 14, 2013 at 04:04:29PM +0800, Josh Wu wrote:
> AT91 ADC hardware integrate touch screen support. So this patch add touch
> screen support for at91 adc iio driver.
> To enable touch screen support in adc, you need to add the dt parameters:
>   which type of touch are used? (4 or 5 wires), sample period time,
>   pen detect debounce time, average samples and pen detect resistor.
> 
> In the meantime, since touch screen will use a interal period trigger of adc,
> so it is conflict to other hardware triggers. Driver will disable the hardware
> trigger support if touch screen is enabled.
> 
> This driver has been tested in AT91SAM9X5-EK and SAMA5D3x-EK.
> 
> Signed-off-by: Josh Wu <josh.wu at atmel.com>
> Cc: Dmitry Torokhov <dmitry.torokhov at gmail.com>
> ---
>  .../devicetree/bindings/arm/atmel-adc.txt          |   13 +
>  arch/arm/mach-at91/include/mach/at91_adc.h         |   34 ++
>  drivers/iio/adc/at91_adc.c                         |  389 ++++++++++++++++++--
>  3 files changed, 412 insertions(+), 24 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> index 0db2945..925d656 100644
> --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> @@ -29,6 +29,19 @@ Optional properties:
>    - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
>    - atmel,adc-clock-rate: ADC clock rate. If not specified, use the default
>  			  adc_op_clk.
> +  - atmel,adc-touchscreen-wires: Number of touch screen wires. Only support
> +				 4 and 5 wires touch screen.
> +    NOTE: when adc touch screen enabled, the adc hardware trigger will be
> +          disabled. Since touch screen will occupied the trigger register.
> +  - atmel,adc-ts-pendet-debounce: Debounce time in microsecond for touch pen
> +				  detect.
> +  - atmel,adc-ts-sample-period-time: Sample Period Time in microsecond for
> +				     touch screen
> +  - atmel,adc-ts-filter-average: Numbers of sampling data will be averaged.
> +    0 means no average. 1 means average two samples. 2 means average four
> +    samples. 3 means average eight samples.
> +  - atmel,adc-ts-pendet-sensitivity: Pen Detection input pull-up resistor.
> +    It can be 0, 1, 2, 3.

Could you expand a bit on what are these properties for? Are they
board-specific? IP-specific?

[...]

> +#define DRIVER_NAME		"at91_adc"

This looks like this part doesn't belong to another cleanup patch.

> +#define MAX_POS_BITS		12
> +
> +#define ZTHRESHOLD		9000
> +
>  struct at91_adc_caps {
> +	bool	has_12bits_xy;	/* true means use 12 bits. Otherwise 10 bits */

Isn't that redundant with the low_res boolean?

>  	bool	has_tsmr;	/* only at91sam9x5, sama5d3 have TSMR reg */
>  	u32	mr_prescal_mask;
>  	u32	mr_startup_mask;
>  };
>  
> +enum atmel_adc_ts_type {
> +	ATMEL_ADC_TOUCHSCREEN_NONE = 0,
> +	ATMEL_ADC_TOUCHSCREEN_4WIRE,
> +	ATMEL_ADC_TOUCHSCREEN_5WIRE,
> +};
> +
>  struct at91_adc_state {
>  	struct clk		*adc_clk;
>  	u32			adc_clk_rate;
> @@ -70,6 +83,29 @@ struct at91_adc_state {
>  	bool			low_res;	/* the resolution corresponds to the lowest one */
>  	wait_queue_head_t	wq_data_avail;
>  	struct at91_adc_caps	caps;
> +
> +	/*
> +	 * Following ADC channels are shared by touchscreen:
> +	 *
> +	 * CH0 -- Touch screen XP/UL
> +	 * CH1 -- Touch screen XM/UR
> +	 * CH2 -- Touch screen YP/LL
> +	 * CH3 -- Touch screen YM/Sense
> +	 * CH4 -- Touch screen LR(5-wire only)
> +	 *
> +	 * The bitfields below represents the reserved channel in the
> +	 * touchscreen mode.
> +	 */
> +#define CHAN_MASK_TOUCHSCREEN_4WIRE	(0xf << 0)
> +#define CHAN_MASK_TOUCHSCREEN_5WIRE	(0x1f << 0)
> +	enum atmel_adc_ts_type	touchscreen_type;
> +	struct input_dev		*ts_input;
> +
> +	u8			ts_filter_average;
> +	u16			ts_pen_detect_debounce;
> +	u8			ts_pen_detect_sensitivity;
> +	u16			ts_sample_period_time;
> +	u16			ts_sample_period_val;
>  };
>  
>  static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
> @@ -104,14 +140,10 @@ static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
>  	return IRQ_HANDLED;
>  }
>  
> -static irqreturn_t at91_adc_eoc_trigger(int irq, void *private)
> +/* Handler for classic adc channel eoc trigger */
> +void handle_adc_eoc_trigger(int irq, struct iio_dev *idev)
>  {
> -	struct iio_dev *idev = private;
>  	struct at91_adc_state *st = iio_priv(idev);
> -	u32 status = at91_adc_readl(st, st->registers->status_register);
> -
> -	if (!(status & st->registers->drdy_mask))
> -		return IRQ_HANDLED;

Why are you changing the prototype and remove most of the useful part
out of the handler?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130715/14495b41/attachment.sig>

From catalin.marinas at arm.com  Mon Jul 15 09:15:20 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 15 Jul 2013 14:15:20 +0100
Subject: Call for testing/opinions: Optimized memset/memcpy
In-Reply-To: <loom.20130713T225129-903@post.gmane.org>
References: <loom.20130713T172357-560@post.gmane.org>
 <20130713164840.GC28473@gallifrey>
 <loom.20130713T225129-903@post.gmane.org>
Message-ID: <20130715131520.GA16220@arm.com>

On Sat, Jul 13, 2013 at 10:13:12PM +0100, Harm Hanemaaijer wrote:
> Dr. David Alan Gilbert <gilbertd <at> treblig.org> writes:
> 
> > 
> > You might like to compare with some of the routines at:
> > https://launchpad.net/cortex-strings
> > and some of the numbers at:
> > https://wiki.linaro.org/WorkingGroups/ToolChain/Benchmarks/
> 
> That's interesting. I had looked at cortex-strings before but didn't
> dig into it, also because its benchmark program seemed to be limited in
> scope. From the Linaro numbers it seems NEON isn't always a win
> especially on newer Cortex platforms, with large variability across
> different platforms/cores.

As it has been stated in this thread, we shouldn't use Neon for memcpy.
There is a significant overhead with saving/restoring Neon registers,
preemptability.

But Cortex Strings is a good starting point and Linaro is going to port
some of these functions to the Linux kernel for ARMv8 (AArch64).

-- 
Catalin


From thomas.petazzoni at free-electrons.com  Mon Jul 15 09:17:12 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 15:17:12 +0200
Subject: v3.10 - big endian core support
In-Reply-To: <51E3CE41.5010807@codethink.co.uk>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate> <51DFEF75.8080600@codethink.co.uk>
 <20130714215325.GB7382@mudshark.cambridge.arm.com>
 <51E3ACD0.8040209@codethink.co.uk> <20130715103658.068ac6b7@skate>
 <51E3CE41.5010807@codethink.co.uk>
Message-ID: <20130715151712.69f2cf8d@skate>

Dear Ben Dooks,

On Mon, 15 Jul 2013 11:26:09 +0100, Ben Dooks wrote:

> I've pushed out two new branches on git.baserock.org/delta/linux.git
> as:
> 	baserock/311/be/core-v2
> 	baserock/311/be/atags-v2

I've tested baserock/311/be/core-v2, after rebasing it on top of
3.11-rc1. I've tested the following combination on an Armada XP board:
little endian ARM, big endian ARM, little endian Thumb2 and big endian
Thumb2. They all worked fine.

There were minor conflicts in arch/arm/kernel/sleep.S and
arch/arm/mach-mvebu/headsmp.S when doing the rebase on top of 3.11-rc1,
but nothing major.

Ben, do you have the time to rebase on 3.11-rc1 and post the patches
for merging?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From rogerq at ti.com  Mon Jul 15 09:20:21 2013
From: rogerq at ti.com (Roger Quadros)
Date: Mon, 15 Jul 2013 16:20:21 +0300
Subject: [PATCH v5 0/2] ARM: dts: Add USB host support for Beagle-xm
In-Reply-To: <B7CE1C39EBFBA0428A012975D4B2FC830B72CECA@DNCE05.ent.ti.com>
References: <1371732374-27191-1-git-send-email-rogerq@ti.com>
 <B7CE1C39EBFBA0428A012975D4B2FC830B72CECA@DNCE05.ent.ti.com>
Message-ID: <51E3F715.9070103@ti.com>

Hi Benoit,

On 06/20/2013 05:11 PM, Cousson, Benoit wrote:
> Thanks Roger,
> 
> I'll take them for 3.12. I was already late for my 3.11 pull request.

Please disregard these patches. I'll send a new version based on the reset-gpio
driver.

cheers,
-roger


From balbi at ti.com  Mon Jul 15 09:23:26 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 15 Jul 2013 16:23:26 +0300
Subject: [PATCH] ARM: multi_v7: Enabled omap4430 sdp nfsroot
In-Reply-To: <20130715075816.GN7656@atomide.com>
References: <20130715075816.GN7656@atomide.com>
Message-ID: <20130715132326.GA12025@arwen.pp.htv.fi>

On Mon, Jul 15, 2013 at 12:58:17AM -0700, Tony Lindgren wrote:
> Author: Tony Lindgren <tony at atomide.com>
> Date:   Mon Jul 15 00:39:41 2013 -0700
> 
>     ARM: multi_v7: Enabled omap4430 sdp nfsroot
>     
>     By adding support for OCP2SCP, SPI and KS8851 I can also boot test
>     multi_v7_defconfig easily.
>     
>     Note that if using an older u-boot, CONFIG_ARM_ATAG_DTB_COMPAT=y
>     may also be needed for the appended DTB based booting.
>     
>     Signed-off-by: Tony Lindgren <tony at atomide.com>

We will also use OCP2SCP driver to enable USB3 on OMAP5 uEVM, good it's
already enabled in multi_v7 after this patch.

Reviewed-by: Felipe Balbi <balbi at ti.com>

-- 
balbi
-------------- 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/20130715/965e296a/attachment.sig>

From paul.gortmaker at windriver.com  Mon Jul 15 09:25:13 2013
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Mon, 15 Jul 2013 09:25:13 -0400
Subject: [RFC PATCH 0/5] arm64: initial CPU_HOTPLUG support
In-Reply-To: <20130715104706.GA14505@e106331-lin.cambridge.arm.com>
References: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
 <20130715104706.GA14505@e106331-lin.cambridge.arm.com>
Message-ID: <51E3F839.4010900@windriver.com>

On 13-07-15 06:47 AM, Mark Rutland wrote:
> Hi Catalin, Paul,
> 
> I've realised these patches are going to conflict with Paul's "arm64:
> delete __cpuinit usage from all users", so I'd like to rebase this
> series atop of it (removing my cpuinit additions as I do so).
> 
> Catalin, would you be happy to create a stable branch at some point soon
> with Paul's arm64 patch for me to work atop of?

Now that 3.11-rc1 is out, I'll be sending a pull request
for phase two of the removal, including the arm64 patch,
so that should be mainline very shortly.

Paul.
--

> 
> Thanks,
> Mark.
> 
> On Wed, Jul 10, 2013 at 11:11:14PM +0100, Mark Rutland wrote:
>> The following patches add basic CPU_HOTPLUG support to arm64, which
>> combined with appropriate firmware (e.g. [1]) can be used to power CPUs
>> up and down dynamically. From discussions at connect it seemed that
>> several people were interested in working in this area, so I thought I'd
>> make my current implementation public now that I've managed to regain
>> access to my inbox.
>>
>> I've tested this series with the bootwrapper PSCI implementation I've
>> placed on linux-arm.org [1] and a modified foundation model dts with a
>> psci node and each CPU's enable-method set to "psci", using a shell
>> while repeatedly cycling all cpus off and on:
>>
>> for C in $(seq 0 3); do
>> 	./cyclichotplug.sh $C >/dev/null 2>&1 &
>> done
>>
>> ---->8----
>> #!/bin/sh
>> # cyclichotplug.sh
>>
>> CPU=$1;
>>
>> if [ -z "$CPU" ]; then
>> 	printf "Usage: $0 <cpu id>\n";
>> 	exit 1;
>> fi
>>
>> ONLINEFILE=/sys/devices/system/cpu/cpu$CPU/online;
>>
>> while true; do
>> 	echo 0 > $ONLINEFILE;
>> 	echo 1 > $ONLINEFILE;
>> done
>> ---->8----
>>
>> Patches are based on v3.10.
>>
>> Thanks,
>> Mark.
>>
>> [1] http://linux-arm.org/git?p=boot-wrapper-aarch64.git;a=shortlog;h=refs/tags/simple-psci
>>
>> Mark Rutland (5):
>>   arm64: reorganise smp_enable_ops
>>   arm64: factor out spin-table boot method
>>   arm64: read enable-method for CPU0
>>   arm64: add CPU_HOTPLUG infrastructure
>>   arm64: add PSCI CPU_OFF-based hotplug support
>>
>>  arch/arm64/Kconfig                 |    7 ++
>>  arch/arm64/include/asm/irq.h       |    1 +
>>  arch/arm64/include/asm/smp.h       |   37 +++++--
>>  arch/arm64/kernel/cputable.c       |    2 +-
>>  arch/arm64/kernel/head.S           |   12 +-
>>  arch/arm64/kernel/irq.c            |   61 ++++++++++
>>  arch/arm64/kernel/process.c        |    7 ++
>>  arch/arm64/kernel/smp.c            |  215 ++++++++++++++++++++++--------------
>>  arch/arm64/kernel/smp_psci.c       |   54 +++++++--
>>  arch/arm64/kernel/smp_spin_table.c |   85 +++++++++++++-
>>  arch/arm64/kernel/vmlinux.lds.S    |    1 -
>>  11 files changed, 375 insertions(+), 107 deletions(-)
>>
>> -- 
>> 1.7.9.5
>>


From thomas.petazzoni at free-electrons.com  Mon Jul 15 09:27:24 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 15:27:24 +0200
Subject: [PATCH 0/2] net: mvneta: big endian support
Message-ID: <1373894846-1147-1-git-send-email-thomas.petazzoni@free-electrons.com>

David,

You'll find in this patch series two small patches that add support
for big-endian in the mvneta driver, for the network interface found
in ARM Marvell Armada 370 and Armada XP SOCs. They are based on
3.11-rc1.

Thanks,

Thomas

Thomas Petazzoni (2):
  net: mvneta: move the RX and TX desc macros outside of the structs
  net: mvneta: support big endian

 drivers/net/ethernet/marvell/mvneta.c | 61 +++++++++++++++++++++++++++--------
 1 file changed, 47 insertions(+), 14 deletions(-)

-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 09:27:25 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 15:27:25 +0200
Subject: [PATCH 1/2] net: mvneta: move the RX and TX desc macros outside of
 the structs
In-Reply-To: <1373894846-1147-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373894846-1147-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373894846-1147-2-git-send-email-thomas.petazzoni@free-electrons.com>

The macros used for the various fields of the RX and TX descriptions
are currently declared next to those fields within the structure
definitions of the RX and TX descriptors.

However, in order to support big endian, we'll have to use the "swap
descriptors" features of the hardware, which swaps every byte within
each 64 bits word of the descriptors. This requires a separate
definition of the RX and TX descriptor structures for little and big
endian, as is done in the mv643xx_eth. Those macros can therefore no
longer be defined inside those structures.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 26 +++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 712779f..649162e 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -262,8 +262,7 @@ struct mvneta_port {
  * layout of the transmit and reception DMA descriptors, and their
  * layout is therefore defined by the hardware design
  */
-struct mvneta_tx_desc {
-	u32  command;		/* Options used by HW for packet transmitting.*/
+
 #define MVNETA_TX_L3_OFF_SHIFT	0
 #define MVNETA_TX_IP_HLEN_SHIFT	8
 #define MVNETA_TX_L4_UDP	BIT(16)
@@ -278,15 +277,6 @@ struct mvneta_tx_desc {
 #define MVNETA_TX_L4_CSUM_FULL	BIT(30)
 #define MVNETA_TX_L4_CSUM_NOT	BIT(31)
 
-	u16  reserverd1;	/* csum_l4 (for future use)		*/
-	u16  data_size;		/* Data size of transmitted packet in bytes */
-	u32  buf_phys_addr;	/* Physical addr of transmitted buffer	*/
-	u32  reserved2;		/* hw_cmd - (for future use, PMT)	*/
-	u32  reserved3[4];	/* Reserved - (for future use)		*/
-};
-
-struct mvneta_rx_desc {
-	u32  status;		/* Info about received packet		*/
 #define MVNETA_RXD_ERR_CRC		0x0
 #define MVNETA_RXD_ERR_SUMMARY		BIT(16)
 #define MVNETA_RXD_ERR_OVERRUN		BIT(17)
@@ -297,13 +287,27 @@ struct mvneta_rx_desc {
 #define MVNETA_RXD_FIRST_LAST_DESC	(BIT(26) | BIT(27))
 #define MVNETA_RXD_L4_CSUM_OK		BIT(30)
 
+struct mvneta_tx_desc {
+	u32  command;		/* Options used by HW for packet transmitting.*/
+	u16  reserverd1;	/* csum_l4 (for future use)		*/
+	u16  data_size;		/* Data size of transmitted packet in bytes */
+	u32  buf_phys_addr;	/* Physical addr of transmitted buffer	*/
+	u32  reserved2;		/* hw_cmd - (for future use, PMT)	*/
+	u32  reserved3[4];	/* Reserved - (for future use)		*/
+};
+
+struct mvneta_rx_desc {
+	u32  status;		/* Info about received packet		*/
 	u16  reserved1;		/* pnc_info - (for future use, PnC)	*/
 	u16  data_size;		/* Size of received packet in bytes	*/
+
 	u32  buf_phys_addr;	/* Physical address of the buffer	*/
 	u32  reserved2;		/* pnc_flow_id  (for future use, PnC)	*/
+
 	u32  buf_cookie;	/* cookie for access to RX buffer in rx path */
 	u16  reserved3;		/* prefetch_cmd, for future use		*/
 	u16  reserved4;		/* csum_l4 - (for future use, PnC)	*/
+
 	u32  reserved5;		/* pnc_extra PnC (for future use, PnC)	*/
 	u32  reserved6;		/* hw_cmd (for future use, PnC and HWF)	*/
 };
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 09:27:26 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 15:27:26 +0200
Subject: [PATCH 2/2] net: mvneta: support big endian
In-Reply-To: <1373894846-1147-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373894846-1147-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373894846-1147-3-git-send-email-thomas.petazzoni@free-electrons.com>

Use the "swap descriptor" feature of the hardware to properly swap the
descriptors when running in big endian mode. Since the swapping occurs
on 64 bits words, we also need to provide a separate structure layout
for the DMA descriptors between little endian and big endian mode,
like is done in the mv643xx_eth driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 35 ++++++++++++++++++++++++++++++++---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 649162e..9647976 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -79,10 +79,10 @@
 #define MVNETA_MAC_ADDR_HIGH                     0x2418
 #define MVNETA_SDMA_CONFIG                       0x241c
 #define      MVNETA_SDMA_BRST_SIZE_16            4
-#define      MVNETA_NO_DESC_SWAP                 0x0
 #define      MVNETA_RX_BRST_SZ_MASK(burst)       ((burst) << 1)
 #define      MVNETA_RX_NO_DATA_SWAP              BIT(4)
 #define      MVNETA_TX_NO_DATA_SWAP              BIT(5)
+#define      MVNETA_DESC_SWAP                    BIT(6)
 #define      MVNETA_TX_BRST_SZ_MASK(burst)       ((burst) << 22)
 #define MVNETA_PORT_STATUS                       0x2444
 #define      MVNETA_TX_IN_PRGRS                  BIT(1)
@@ -287,6 +287,7 @@ struct mvneta_port {
 #define MVNETA_RXD_FIRST_LAST_DESC	(BIT(26) | BIT(27))
 #define MVNETA_RXD_L4_CSUM_OK		BIT(30)
 
+#if defined(__LITTLE_ENDIAN)
 struct mvneta_tx_desc {
 	u32  command;		/* Options used by HW for packet transmitting.*/
 	u16  reserverd1;	/* csum_l4 (for future use)		*/
@@ -311,6 +312,32 @@ struct mvneta_rx_desc {
 	u32  reserved5;		/* pnc_extra PnC (for future use, PnC)	*/
 	u32  reserved6;		/* hw_cmd (for future use, PnC and HWF)	*/
 };
+#else
+struct mvneta_tx_desc {
+	u16  data_size;		/* Data size of transmitted packet in bytes */
+	u16  reserverd1;	/* csum_l4 (for future use)		*/
+	u32  command;		/* Options used by HW for packet transmitting.*/
+	u32  reserved2;		/* hw_cmd - (for future use, PMT)	*/
+	u32  buf_phys_addr;	/* Physical addr of transmitted buffer	*/
+	u32  reserved3[4];	/* Reserved - (for future use)		*/
+};
+
+struct mvneta_rx_desc {
+	u16  data_size;		/* Size of received packet in bytes	*/
+	u16  reserved1;		/* pnc_info - (for future use, PnC)	*/
+	u32  status;		/* Info about received packet		*/
+
+	u32  reserved2;		/* pnc_flow_id  (for future use, PnC)	*/
+	u32  buf_phys_addr;	/* Physical address of the buffer	*/
+
+	u16  reserved4;		/* csum_l4 - (for future use, PnC)	*/
+	u16  reserved3;		/* prefetch_cmd, for future use		*/
+	u32  buf_cookie;	/* cookie for access to RX buffer in rx path */
+
+	u32  reserved5;		/* pnc_extra PnC (for future use, PnC)	*/
+	u32  reserved6;		/* hw_cmd (for future use, PnC and HWF)	*/
+};
+#endif
 
 struct mvneta_tx_queue {
 	/* Number of this TX queue, in the range 0-7 */
@@ -908,9 +935,11 @@ static void mvneta_defaults_set(struct mvneta_port *pp)
 	/* Default burst size */
 	val |= MVNETA_TX_BRST_SZ_MASK(MVNETA_SDMA_BRST_SIZE_16);
 	val |= MVNETA_RX_BRST_SZ_MASK(MVNETA_SDMA_BRST_SIZE_16);
+	val |= MVNETA_RX_NO_DATA_SWAP | MVNETA_TX_NO_DATA_SWAP;
 
-	val |= (MVNETA_RX_NO_DATA_SWAP | MVNETA_TX_NO_DATA_SWAP |
-		MVNETA_NO_DESC_SWAP);
+#if defined(__BIG_ENDIAN)
+	val |= MVNETA_DESC_SWAP;
+#endif
 
 	/* Assign port SDMA configuration */
 	mvreg_write(pp, MVNETA_SDMA_CONFIG, val);
-- 
1.8.1.2



From will.deacon at arm.com  Mon Jul 15 09:27:59 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Jul 2013 14:27:59 +0100
Subject: [PATCH] ARM: locks: remove opencoded #16 for ticket shift
Message-ID: <1373894879-30559-1-git-send-email-will.deacon@arm.com>

The ticket width of our spinlocks is defined by TICKET_SHIFT, so remove
the opencoded #16 from the trylock implementation.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/spinlock.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index f8b8965..fa3ccce 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -104,11 +104,11 @@ static inline int arch_spin_trylock(arch_spinlock_t *lock)
 		__asm__ __volatile__(
 		"	ldrex	%0, [%3]\n"
 		"	mov	%2, #0\n"
-		"	subs	%1, %0, %0, ror #16\n"
-		"	addeq	%0, %0, %4\n"
+		"	subs	%1, %0, %0, ror %4\n"
+		"	addeq	%0, %0, %5\n"
 		"	strexeq	%2, %0, [%3]"
 		: "=&r" (slock), "=&r" (contended), "=r" (res)
-		: "r" (&lock->slock), "I" (1 << TICKET_SHIFT)
+		: "r" (&lock->slock), "I" (TICKET_SHIFT), "I" (1 << TICKET_SHIFT)
 		: "cc");
 	} while (res);
 
-- 
1.8.2.2



From will.deacon at arm.com  Mon Jul 15 09:28:17 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Jul 2013 14:28:17 +0100
Subject: [PATCH] ARM: a.out: remove partial a.out support
Message-ID: <1373894897-30607-1-git-send-email-will.deacon@arm.com>

a.out support on ARM requires that argc, argv and envp are passed in
r0-r2 respectively, which requires hacking load_aout_binary to
prevent argc being clobbered by the return code. Whilst mainline kernels
do set the registers up in start_thread, the aout loader has never
carried the hack in mainline.

Initialising the registers in this way actually goes against the libc
expectations for ELF binaries, where argc, argv and envp are passed on
the stack, with r0 being used to hold a pointer to an exit function for
cleaning up after the dynamic linker if required. If the pointer is
NULL, then it is ignored. When execing an ELF binary, Linux currently
zeroes r0, then sets it to argc and then finally clobbers it with the
return value of the execve syscall, so we actually end up with:

	r0 = 0
	stack[0] = argc
	r1 = stack[1] = argv
	r2 = stack[2] = envp

libc treats r1 and r2 as undefined. The clobbering of r0 by sys_execve
works for user-spawned threads, but when executing an ELF binary from a
kernel thread (via call_usermodehelper), the execve is performed on the
ret_from_fork path, which restores r0 from the saved pt_regs, resulting
in argc being presented to the C library. This has horrible consequences
when the application exits, since we have an exit function registered
using argc, resulting in a jump to hyperspace.

This patch solves the problem by removing the partial a.out support from
arch/arm/ altogether.

Cc: Ashish Sangwan <ashishsangwan2 at gmail.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/Kconfig                  |  1 -
 arch/arm/include/asm/a.out-core.h | 45 ---------------------------------------
 arch/arm/include/asm/processor.h  |  4 ----
 arch/arm/include/uapi/asm/Kbuild  |  1 -
 arch/arm/include/uapi/asm/a.out.h | 34 -----------------------------
 5 files changed, 85 deletions(-)
 delete mode 100644 arch/arm/include/asm/a.out-core.h
 delete mode 100644 arch/arm/include/uapi/asm/a.out.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..82f06982 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -20,7 +20,6 @@ config ARM
 	select GENERIC_STRNCPY_FROM_USER
 	select GENERIC_STRNLEN_USER
 	select HARDIRQS_SW_RESEND
-	select HAVE_AOUT
 	select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
 	select HAVE_ARCH_KGDB
 	select HAVE_ARCH_SECCOMP_FILTER
diff --git a/arch/arm/include/asm/a.out-core.h b/arch/arm/include/asm/a.out-core.h
deleted file mode 100644
index 92f10cb..0000000
--- a/arch/arm/include/asm/a.out-core.h
+++ /dev/null
@@ -1,45 +0,0 @@
-/* a.out coredump register dumper
- *
- * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
- * Written by David Howells (dhowells at redhat.com)
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public Licence
- * as published by the Free Software Foundation; either version
- * 2 of the Licence, or (at your option) any later version.
- */
-
-#ifndef _ASM_A_OUT_CORE_H
-#define _ASM_A_OUT_CORE_H
-
-#ifdef __KERNEL__
-
-#include <linux/user.h>
-#include <linux/elfcore.h>
-
-/*
- * fill in the user structure for an a.out core dump
- */
-static inline void aout_dump_thread(struct pt_regs *regs, struct user *dump)
-{
-	struct task_struct *tsk = current;
-
-	dump->magic = CMAGIC;
-	dump->start_code = tsk->mm->start_code;
-	dump->start_stack = regs->ARM_sp & ~(PAGE_SIZE - 1);
-
-	dump->u_tsize = (tsk->mm->end_code - tsk->mm->start_code) >> PAGE_SHIFT;
-	dump->u_dsize = (tsk->mm->brk - tsk->mm->start_data + PAGE_SIZE - 1) >> PAGE_SHIFT;
-	dump->u_ssize = 0;
-
-	memset(dump->u_debugreg, 0, sizeof(dump->u_debugreg));
-
-	if (dump->start_stack < 0x04000000)
-		dump->u_ssize = (0x04000000 - dump->start_stack) >> PAGE_SHIFT;
-
-	dump->regs = *regs;
-	dump->u_fpvalid = dump_fpu (regs, &dump->u_fp);
-}
-
-#endif /* __KERNEL__ */
-#endif /* _ASM_A_OUT_CORE_H */
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 06e7d50..413f387 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -54,7 +54,6 @@ struct thread_struct {
 
 #define start_thread(regs,pc,sp)					\
 ({									\
-	unsigned long *stack = (unsigned long *)sp;			\
 	memset(regs->uregs, 0, sizeof(regs->uregs));			\
 	if (current->personality & ADDR_LIMIT_32BIT)			\
 		regs->ARM_cpsr = USR_MODE;				\
@@ -65,9 +64,6 @@ struct thread_struct {
 	regs->ARM_cpsr |= PSR_ENDSTATE;					\
 	regs->ARM_pc = pc & ~1;		/* pc */			\
 	regs->ARM_sp = sp;		/* sp */			\
-	regs->ARM_r2 = stack[2];	/* r2 (envp) */			\
-	regs->ARM_r1 = stack[1];	/* r1 (argv) */			\
-	regs->ARM_r0 = stack[0];	/* r0 (argc) */			\
 	nommu_start_thread(regs);					\
 })
 
diff --git a/arch/arm/include/uapi/asm/Kbuild b/arch/arm/include/uapi/asm/Kbuild
index 47bcb2d..18d76fd 100644
--- a/arch/arm/include/uapi/asm/Kbuild
+++ b/arch/arm/include/uapi/asm/Kbuild
@@ -1,7 +1,6 @@
 # UAPI Header export list
 include include/uapi/asm-generic/Kbuild.asm
 
-header-y += a.out.h
 header-y += byteorder.h
 header-y += fcntl.h
 header-y += hwcap.h
diff --git a/arch/arm/include/uapi/asm/a.out.h b/arch/arm/include/uapi/asm/a.out.h
deleted file mode 100644
index 083894b..0000000
--- a/arch/arm/include/uapi/asm/a.out.h
+++ /dev/null
@@ -1,34 +0,0 @@
-#ifndef __ARM_A_OUT_H__
-#define __ARM_A_OUT_H__
-
-#include <linux/personality.h>
-#include <linux/types.h>
-
-struct exec
-{
-  __u32 a_info;		/* Use macros N_MAGIC, etc for access */
-  __u32 a_text;		/* length of text, in bytes */
-  __u32 a_data;		/* length of data, in bytes */
-  __u32 a_bss;		/* length of uninitialized data area for file, in bytes */
-  __u32 a_syms;		/* length of symbol table data in file, in bytes */
-  __u32 a_entry;	/* start address */
-  __u32 a_trsize;	/* length of relocation info for text, in bytes */
-  __u32 a_drsize;	/* length of relocation info for data, in bytes */
-};
-
-/*
- * This is always the same
- */
-#define N_TXTADDR(a)	(0x00008000)
-
-#define N_TRSIZE(a)	((a).a_trsize)
-#define N_DRSIZE(a)	((a).a_drsize)
-#define N_SYMSIZE(a)	((a).a_syms)
-
-#define M_ARM 103
-
-#ifndef LIBRARY_START_TEXT
-#define LIBRARY_START_TEXT	(0x00c00000)
-#endif
-
-#endif /* __A_OUT_GNU_H__ */
-- 
1.8.2.2



From oleksandr.kozaruk at ti.com  Mon Jul 15 09:30:25 2013
From: oleksandr.kozaruk at ti.com (Kozaruk, Oleksandr)
Date: Mon, 15 Jul 2013 13:30:25 +0000
Subject: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <51E05C0B.5050009@kernel.org>
References: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1373613482-28390-3-git-send-email-oleksandr.kozaruk@ti.com>,
 <51E05C0B.5050009@kernel.org>
Message-ID: <2A7ABDFCE21540479A5AEB0244A684D5E3D0E3@DNCE04.ent.ti.com>

Hello Jonathan,
Thanks for the review.

>Couple of things:
>
>1) It looks from the driver that a lot of the channels are not measuring
>voltages but rather temperature or currents etc.  If so then their
>types in the channel mask should be appropriately set.  Also if some
>of the channels are entirely internal test networks, what is the benefit
>of exposing them to userspace as readable channels?
>If channels are merely 'suggested' as being used for temperatures etc
>then it is fine to keep them as voltages.
There are two kinds of channel for measuring temperature: die temperature
and those that measure temperature indirectly measuring voltage on resistive
load(NTC sensor).
die temperature is calculated by some formulas which convert ADC code to
temperature. This is not implemented in the driver.
Channels intended to measure temperature with NTC sensor have inbuilt current
sources. Voltage measured by this channels and specific NTC could be converted
to temperature.
This is the reason they chosen to be voltage channels.
As for test network I'll remove them from exposing to userspace.
[...]

>> +static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
>> +             int channel, int *res)
>> +{
>> +     u8 reg = gpadc->pdata->channel_to_reg(channel);
>> +     u8 val[2];
>
>le16 val;
>> +     int ret;
>> +
>ret = twl6030_gpadc_read(val, reg);
>(note that (reg, val) ordering of parameters would be a more common choice)
>
>> +     ret = twl6030_gpadc_read(val, reg);
>> +     if (ret) {
>> +             dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
>> +             return ret;
>> +     }
>> +
>res = le16_to_cpup(val);
>
>> +     *res = (val[1] << 8) | val[0];
>> +
>> +     return ret;
>> +}
>> +
You mean something like this:
static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,                                                                                                                                                  
						int channel, int *res)                                                                                                                                                                              
{                                                                                                                                                                                                                   
	u8 reg = gpadc->pdata->channel_to_reg(channel);                                                                                                                                                             
	__le16 val;                                                                                                                                                                                                 
	int ret;                                                                                                                                                                                                    

	ret = twl6030_gpadc_read(reg, (u8 *)&val);                                                                                                                                                                  
	if (ret) {                                                                                                                                                                                                  
		dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);                                                                                                                                         
		return ret;                                                                                                                                                                                         
	}                                                                                                                                                                                                           

	*res = le16_to_cpup(&val);                                                                                                                                                                                  

	return ret;                                                                                                                                                                                                 
}
Note, that twl6030_gpadc_read() is just wrapper for twl_i2c_read() which takes
"an array of num_bytes containing data to be read"
I like the original implementation better then this(if I did it correctly)
Do you insist on this change?
[...]

>> +static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
>> +             int channel, int *val)
>> +{
>> +     int raw_code;
>> +     int corrected_code;
>> +     int channel_value;
>> +     int ret;
>> +
>> +     ret = twl6030_gpadc_get_raw(gpadc, channel, &raw_code);
>> +     if (ret)
>> +             return ret;
>> +
>
>Might first thought on seeing this is that it would be better to return
>raw for all channels and provide the scale and offset info_mask elements
>where possible rather than doing the conversion in the kernel.  Note we

In our custom kernel branch battery driver needs battery voltage and
temperature.  Thus the conversion anyway is done in the kernel, either
in ADC driver or battery driver.

>allow really quite a bit of precision on those values so I doubt it
>will be a problem.
>
>If nothing else it would make everything rather more consistent.
>
[...]

>> +static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
>> +{
>> +     int chn, d1 = 0, d2 = 0, temp;
>> +     u8 trim_regs[17];
>> +     int ret;
>> +
>> +     ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
>> +                     TWL6030_GPADC_TRIM1, 16);
>> +     if (ret < 0) {
>> +             dev_err(gpadc->dev, "calibration failed\n");
>> +             return ret;
>> +     }
>> +
>/*
>* Loop
>please for kernel code.
>> +     /* Loop to calculate the value needed for returning voltages from
>> +      * GPADC not values.
>> +      *
>> +      * gain is calculated to 3 decimal places fixed point.
>> +      */
>> +     for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
>> +
>> +             switch (chn) {
>> +             case 0:
>> +             case 1:
>> +             case 2:
>> +             case 3:
>> +             case 4:
>> +             case 5:
>> +             case 6:
>> +             case 11:
>> +             case 12:
>> +             case 13:
>> +             case 14:
>> +                     /* D1 */
>> +                     d1 = (trim_regs[3] & 0x1F) << 2;
>> +                     d1 |= (trim_regs[1] & 0x06) >> 1;
>> +                     if (trim_regs[1] & 0x01)
>> +                             d1 = -d1;
>> +
>> +                     /* D2 */
>> +                     d2 = (trim_regs[4] & 0x3F) << 2;
>> +                     d2 |= (trim_regs[2] & 0x06) >> 1;
>> +                     if (trim_regs[2] & 0x01)
>> +                             d2 = -d2;
>> +                     break;
>> +             case 8:
>No coment on your code, but this is an 'interesting' bit
>of bit packing...
>I did vaguely wonder if this could be mapped to a big lookup table,
>but having tried it I think I end up with something almost as tricky
>to read.. Oh well that was a fun 10 minute diversion ;)
This is inherited code from Graeme - original author of implementation
for twl6032.
[...]

Regards,
OK.


From maxime.ripard at free-electrons.com  Mon Jul 15 09:42:35 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 15 Jul 2013 15:42:35 +0200
Subject: [PATCH] clk: sunxi: Fix checking return value of
 clk_register_[composite|factors]
In-Reply-To: <1373616915.24328.1.camel@phoenix>
References: <1373616915.24328.1.camel@phoenix>
Message-ID: <20130715134235.GF2962@lukather>

Hi Axel,


On Fri, Jul 12, 2013 at 04:15:15PM +0800, Axel Lin wrote:
> clk_register_composite() and clk_register_factors() return ERR_PTR on error.
> 
> Signed-off-by: Axel Lin <axel.lin at ingics.com>

Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Thanks for this patch!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130715/24106ae7/attachment.sig>

From mark.rutland at arm.com  Mon Jul 15 09:45:06 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 15 Jul 2013 14:45:06 +0100
Subject: [RFC PATCH 0/5] arm64: initial CPU_HOTPLUG support
In-Reply-To: <51E3F839.4010900@windriver.com>
References: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
 <20130715104706.GA14505@e106331-lin.cambridge.arm.com>
 <51E3F839.4010900@windriver.com>
Message-ID: <20130715134506.GA31535@e106331-lin.cambridge.arm.com>

On Mon, Jul 15, 2013 at 02:25:13PM +0100, Paul Gortmaker wrote:
> On 13-07-15 06:47 AM, Mark Rutland wrote:
> > Hi Catalin, Paul,
> > 
> > I've realised these patches are going to conflict with Paul's "arm64:
> > delete __cpuinit usage from all users", so I'd like to rebase this
> > series atop of it (removing my cpuinit additions as I do so).
> > 
> > Catalin, would you be happy to create a stable branch at some point soon
> > with Paul's arm64 patch for me to work atop of?
> 
> Now that 3.11-rc1 is out, I'll be sending a pull request
> for phase two of the removal, including the arm64 patch,
> so that should be mainline very shortly.

Ok, I'll wait for that to hit.

Thanks,
Mark.

> 
> Paul.
> --
> 
> > 
> > Thanks,
> > Mark.
> > 
> > On Wed, Jul 10, 2013 at 11:11:14PM +0100, Mark Rutland wrote:
> >> The following patches add basic CPU_HOTPLUG support to arm64, which
> >> combined with appropriate firmware (e.g. [1]) can be used to power CPUs
> >> up and down dynamically. From discussions at connect it seemed that
> >> several people were interested in working in this area, so I thought I'd
> >> make my current implementation public now that I've managed to regain
> >> access to my inbox.
> >>
> >> I've tested this series with the bootwrapper PSCI implementation I've
> >> placed on linux-arm.org [1] and a modified foundation model dts with a
> >> psci node and each CPU's enable-method set to "psci", using a shell
> >> while repeatedly cycling all cpus off and on:
> >>
> >> for C in $(seq 0 3); do
> >> 	./cyclichotplug.sh $C >/dev/null 2>&1 &
> >> done
> >>
> >> ---->8----
> >> #!/bin/sh
> >> # cyclichotplug.sh
> >>
> >> CPU=$1;
> >>
> >> if [ -z "$CPU" ]; then
> >> 	printf "Usage: $0 <cpu id>\n";
> >> 	exit 1;
> >> fi
> >>
> >> ONLINEFILE=/sys/devices/system/cpu/cpu$CPU/online;
> >>
> >> while true; do
> >> 	echo 0 > $ONLINEFILE;
> >> 	echo 1 > $ONLINEFILE;
> >> done
> >> ---->8----
> >>
> >> Patches are based on v3.10.
> >>
> >> Thanks,
> >> Mark.
> >>
> >> [1] http://linux-arm.org/git?p=boot-wrapper-aarch64.git;a=shortlog;h=refs/tags/simple-psci
> >>
> >> Mark Rutland (5):
> >>   arm64: reorganise smp_enable_ops
> >>   arm64: factor out spin-table boot method
> >>   arm64: read enable-method for CPU0
> >>   arm64: add CPU_HOTPLUG infrastructure
> >>   arm64: add PSCI CPU_OFF-based hotplug support
> >>
> >>  arch/arm64/Kconfig                 |    7 ++
> >>  arch/arm64/include/asm/irq.h       |    1 +
> >>  arch/arm64/include/asm/smp.h       |   37 +++++--
> >>  arch/arm64/kernel/cputable.c       |    2 +-
> >>  arch/arm64/kernel/head.S           |   12 +-
> >>  arch/arm64/kernel/irq.c            |   61 ++++++++++
> >>  arch/arm64/kernel/process.c        |    7 ++
> >>  arch/arm64/kernel/smp.c            |  215 ++++++++++++++++++++++--------------
> >>  arch/arm64/kernel/smp_psci.c       |   54 +++++++--
> >>  arch/arm64/kernel/smp_spin_table.c |   85 +++++++++++++-
> >>  arch/arm64/kernel/vmlinux.lds.S    |    1 -
> >>  11 files changed, 375 insertions(+), 107 deletions(-)
> >>
> >> -- 
> >> 1.7.9.5
> >>
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From will.deacon at arm.com  Mon Jul 15 09:53:42 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Jul 2013 14:53:42 +0100
Subject: [PATCH] ARM: perf: Implement perf_arch_fetch_caller_regs
In-Reply-To: <1373685434-1581-1-git-send-email-jld@mozilla.com>
References: <1373685434-1581-1-git-send-email-jld@mozilla.com>
Message-ID: <20130715135342.GF10000@mudshark.cambridge.arm.com>

Hi Jed,

On Sat, Jul 13, 2013 at 04:17:14AM +0100, Jed Davis wrote:
> We need a perf_arch_fetch_caller_regs for at least some software events
> to be able to get a callchain; even user stacks won't work without
> at least the CPSR bits for non-user-mode (see perf_callchain).  In
> particular, profiling context switches needs this.
> 
> This records the state of the point at which perf_arch_fetch_caller_regs
> is expanded, instead of that function activation's call site, because we
> need SP and PC to be consistent for EHABI unwinding; hopefully nothing
> will be inconvenienced by the extra stack frame.

[...]

> +#ifdef CONFIG_THUMB2_KERNEL
> +#define perf_arch_fetch_caller_regs(regs, ip)				\
> +	do {								\
> +		__u32 _cpsr, _pc;					\
> +		__asm__ __volatile__("str r7, [%[_regs], #(7 * 4)]\n\t" \
> +				     "str r13, [%[_regs], #(13 * 4)]\n\t" \
> +				     "str r14, [%[_regs], #(14 * 4)]\n\t" \

Is this safe? How can we be sure that the registers haven't been clobbered
by the callee before this macro is expanded? For example, you can end up
with the following code:

00000058 <perf_ftrace_function_call>:
  58:   e92d 43f0       stmdb   sp!, {r4, r5, r6, r7, r8, r9, lr}
  5c:   b09b            sub     sp, #108        ; 0x6c
  5e:   ac08            add     r4, sp, #32
  60:   4681            mov     r9, r0
  62:   4688            mov     r8, r1
  64:   4620            mov     r0, r4
  66:   2148            movs    r1, #72 ; 0x48
  68:   f7ff fffe       bl      0 <__memzero>
  6c:   61e7            str     r7, [r4, #28]
  6e:   f8c4 d034       str.w   sp, [r4, #52]   ; 0x34
  72:   f8c4 e038       str.w   lr, [r4, #56]   ; 0x38

but the call to __memzero will have corrupted the lr.

> +				     "mov %[_pc],  r15\n\t"		\
> +				     "mrs %[_cpsr], cpsr\n\t"		\
> +				     : [_cpsr] "=r" (_cpsr),		\
> +				       [_pc] "=r" (_pc)			\
> +				     : [_regs] "r" (&(regs)->uregs)	\

It would be cleaner to pass a separate argument for each register, using the
ARM_rN macros rather than calculating the offset by hand.

Will


From will.deacon at arm.com  Mon Jul 15 09:54:20 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Jul 2013 14:54:20 +0100
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y
In-Reply-To: <1373685501-1620-1-git-send-email-jld@mozilla.com>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
Message-ID: <20130715135420.GG10000@mudshark.cambridge.arm.com>

Hi Jed,

On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> There is currently some inconsistency about the "frame pointer" on ARM.
> r11 is the register with assemblers recognize and disassemblers often
> print as "fp", and which is sufficient for stack unwinding when using
> the APCS frame pointer option; but when unwinding with the Exception
> Handling ABI, the register GCC uses when a constant offset won't suffice
> (or when -fno-omit-frame-pointer is used; see kernel/sched/Makefile in
> particular) is r11 on ARM and r7 on Thumb.
> 
> Correspondingly, arch/arm/include/uapi/arm/ptrace.h defines ARM_fp to
> refer to r11, but arch/arm/kernel/unwind.c uses "FP" to mean either r11
> or r7 depending on Thumbness, and it is unclear what other cases such as
> the "fp" in struct stackframe should be doing.
> 
> Effects of this are probably limited to failure of EHABI unwinding when
> starting from a function that uses r7 to restore its stack pointer, but
> the possibility for further breakage (which would be invisible on
> non-Thumb kernels) is worrying.
> 
> With this change, it is hoped, r7 is consistently referred to as "r7",
> and "fp" always means r11; this costs a few extra ifdefs, but it should
> help prevent future issues.

I'm struggling to understand exactly the problem that this patch is trying
to address. If it's just a code consistency issue, I don't think it's worth
it (I actually find it less confusing the way we currently have things) but
if there is a real bug, perhaps you could provide a testcase?

Cheers,

Will


From anup at brainfault.org  Mon Jul 15 10:04:50 2013
From: anup at brainfault.org (Anup Patel)
Date: Mon, 15 Jul 2013 19:34:50 +0530
Subject: [PATCH] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene host
In-Reply-To: <73A8FA0E-9F7F-4866-9544-57838F30BB91@suse.de>
References: <1373888788-8055-1-git-send-email-anup.patel@linaro.org>
 <51E3ED7A.7050207@arm.com>
 <CAAhSdy25WVnynDyPcOMtqVNEepGGq9WFT3b1PV34P6iSBm-FUg@mail.gmail.com>
 <73A8FA0E-9F7F-4866-9544-57838F30BB91@suse.de>
Message-ID: <CAAhSdy1tYsdm-2kJzoRfqb-FaPa0-t9x2+=jtMjgFqes+Pco6Q@mail.gmail.com>

On Mon, Jul 15, 2013 at 6:32 PM, Alexander Graf <agraf at suse.de> wrote:
>
> On 15.07.2013, at 14:56, Anup Patel wrote:
>
>> Hi Marc,
>>
>> On Mon, Jul 15, 2013 at 6:09 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>> Hi Anup,
>>>
>>> On 15/07/13 12:46, Anup Patel wrote:
>>>> This patch allows us to have X-Gene guest VCPU when using
>>>> KVM arm64 on APM X-Gene host.
>>>>
>>>> We add KVM_ARM_TARGET_XGENE_V8 for X-Gene compatible guest VCPU
>>>> and we return KVM_ARM_TARGET_XGENE_V8 in kvm_target_cpu() when
>>>> running on X-Gene host.
>>>>
>>>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>>>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>>> ---
>>>> arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
>>>> arch/arm64/kvm/guest.c               |   34 ++++++++++++++++++++++------------
>>>> arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
>>>> 3 files changed, 27 insertions(+), 13 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>>>> index 5031f42..8194707 100644
>>>> --- a/arch/arm64/include/uapi/asm/kvm.h
>>>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>>>> @@ -55,8 +55,9 @@ struct kvm_regs {
>>>> #define KVM_ARM_TARGET_AEM_V8                0
>>>> #define KVM_ARM_TARGET_FOUNDATION_V8 1
>>>> #define KVM_ARM_TARGET_CORTEX_A57    2
>>>> +#define KVM_ARM_TARGET_XGENE_V8              3
>>>>
>>>> -#define KVM_ARM_NUM_TARGETS          3
>>>> +#define KVM_ARM_NUM_TARGETS          4
>>>>
>>>> /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
>>>> #define KVM_ARM_DEVICE_TYPE_SHIFT    0
>>>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>>>> index 2c3ff67..e99b0a5 100644
>>>> --- a/arch/arm64/kvm/guest.c
>>>> +++ b/arch/arm64/kvm/guest.c
>>>> @@ -207,19 +207,29 @@ int __attribute_const__ kvm_target_cpu(void)
>>>>      unsigned long implementor = read_cpuid_implementor();
>>>>      unsigned long part_number = read_cpuid_part_number();
>>>>
>>>> -     if (implementor != ARM_CPU_IMP_ARM)
>>>> -             return -EINVAL;
>>>> -
>>>> -     switch (part_number) {
>>>> -     case ARM_CPU_PART_AEM_V8:
>>>> -             return KVM_ARM_TARGET_AEM_V8;
>>>> -     case ARM_CPU_PART_FOUNDATION:
>>>> -             return KVM_ARM_TARGET_FOUNDATION_V8;
>>>> -     case ARM_CPU_PART_CORTEX_A57:
>>>> -             /* Currently handled by the generic backend */
>>>> -             return KVM_ARM_TARGET_CORTEX_A57;
>>>> +     switch (implementor) {
>>>> +     case ARM_CPU_IMP_ARM:
>>>> +             switch (part_number) {
>>>> +             case ARM_CPU_PART_AEM_V8:
>>>> +                     return KVM_ARM_TARGET_AEM_V8;
>>>> +             case ARM_CPU_PART_FOUNDATION:
>>>> +                     return KVM_ARM_TARGET_FOUNDATION_V8;
>>>> +             case ARM_CPU_PART_CORTEX_A57:
>>>> +                     return KVM_ARM_TARGET_CORTEX_A57;
>>>> +             default:
>>>> +                     return -EINVAL;
>>>> +             }
>>>> +             break;
>>>> +     case ARM_CPU_IMP_APM:
>>>> +             switch (part_number) {
>>>> +             case APM_CPU_PART_POTENZA:
>>>> +                     return KVM_ARM_TARGET_XGENE_V8;
>>>
>>> Why don't we have KVM_ARM_TARGET_XGENE_POTENZA (or something similar)
>>> instead? I don't expect all the X-Gene CPUs to be the same forever...
>>
>> OK, I will rename it to KVM_ARM_TARGET_XGENE_POTENZA.
>>
>> Does this mean that with every new ARM64 CPU we will have to add a new
>> target for KVM ARM64 ?
>
> Only for different core types, no? Any Cortex-A57 should still behave the same.
>
>> If so then I think the list of targets will grow very fast.
>>
>> I also realized that if we add a new target type in KVM ARM64 then we have
>> to also update KVMTOOL to use the new target else KVMTOOL fails to
>> recognize the target provided by KVM ARM64.
>
> Right. It might make sense to have a fetch mechanism for the host cpu part. So you can ask KVM for the host cpu type and pass that back in here.
>
>> Do you think we can have KVM_ARM_TARGET_xxx to represent a common
>> target for a family of CPUs from given ARM64 vendor?
>
> Anything that is compatible is compatible :). I don't know the product roadmaps for X-Gene cores, but you will want to make the field here as coarse grained as possible, while maintaining the guarantee that a guest still behaves the same.

Actually, I don't see X-Gene cores changing in-terms of register interface
available to EL1 and EL0 in near future. This is the reason why I had named
the target as KVM_ARM_TARGET_XGENE_V8.

My only concern in having a more specific target type (such as
KVM_ARM_TARGET_XGENE_POTENZA) is that we might unnecessarily
add new target types without any difference on KVM-side.

>
>
> Alex
>

--Anup


From gg at slimlogic.co.uk  Mon Jul 15 10:05:05 2013
From: gg at slimlogic.co.uk (Graeme Gregory)
Date: Mon, 15 Jul 2013 15:05:05 +0100
Subject: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <2A7ABDFCE21540479A5AEB0244A684D5E3D0E3@DNCE04.ent.ti.com>
References: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1373613482-28390-3-git-send-email-oleksandr.kozaruk@ti.com>,
 <51E05C0B.5050009@kernel.org>
 <2A7ABDFCE21540479A5AEB0244A684D5E3D0E3@DNCE04.ent.ti.com>
Message-ID: <51E40191.8010708@slimlogic.co.uk>

On 15/07/13 14:30, Kozaruk, Oleksandr wrote:
> Hello Jonathan,
> Thanks for the review.
>
>> Couple of things:
>>
>> 1) It looks from the driver that a lot of the channels are not measuring
>> voltages but rather temperature or currents etc.  If so then their
>> types in the channel mask should be appropriately set.  Also if some
>> of the channels are entirely internal test networks, what is the benefit
>> of exposing them to userspace as readable channels?
>> If channels are merely 'suggested' as being used for temperatures etc
>> then it is fine to keep them as voltages.
> There are two kinds of channel for measuring temperature: die temperature
> and those that measure temperature indirectly measuring voltage on resistive
> load(NTC sensor).
> die temperature is calculated by some formulas which convert ADC code to
> temperature. This is not implemented in the driver.
> Channels intended to measure temperature with NTC sensor have inbuilt current
> sources. Voltage measured by this channels and specific NTC could be converted
> to temperature.
> This is the reason they chosen to be voltage channels.
> As for test network I'll remove them from exposing to userspace.
> [...]
>
>>> +static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
>>> +             int channel, int *res)
>>> +{
>>> +     u8 reg = gpadc->pdata->channel_to_reg(channel);
>>> +     u8 val[2];
>> le16 val;
>>> +     int ret;
>>> +
>> ret = twl6030_gpadc_read(val, reg);
>> (note that (reg, val) ordering of parameters would be a more common choice)
>>
>>> +     ret = twl6030_gpadc_read(val, reg);
>>> +     if (ret) {
>>> +             dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
>>> +             return ret;
>>> +     }
>>> +
>> res = le16_to_cpup(val);
>>
>>> +     *res = (val[1] << 8) | val[0];
>>> +
>>> +     return ret;
>>> +}
>>> +
> You mean something like this:
> static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,                                                                                                                                                  
> 						int channel, int *res)                                                                                                                                                                              
> {                                                                                                                                                                                                                   
> 	u8 reg = gpadc->pdata->channel_to_reg(channel);                                                                                                                                                             
> 	__le16 val;                                                                                                                                                                                                 
> 	int ret;                                                                                                                                                                                                    
>
> 	ret = twl6030_gpadc_read(reg, (u8 *)&val);                                                                                                                                                                  
> 	if (ret) {                                                                                                                                                                                                  
> 		dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);                                                                                                                                         
> 		return ret;                                                                                                                                                                                         
> 	}                                                                                                                                                                                                           
>
> 	*res = le16_to_cpup(&val);                                                                                                                                                                                  
>
> 	return ret;                                                                                                                                                                                                 
> }
> Note, that twl6030_gpadc_read() is just wrapper for twl_i2c_read() which takes
> "an array of num_bytes containing data to be read"
> I like the original implementation better then this(if I did it correctly)
> Do you insist on this change?
> [...]
>
>>> +static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
>>> +             int channel, int *val)
>>> +{
>>> +     int raw_code;
>>> +     int corrected_code;
>>> +     int channel_value;
>>> +     int ret;
>>> +
>>> +     ret = twl6030_gpadc_get_raw(gpadc, channel, &raw_code);
>>> +     if (ret)
>>> +             return ret;
>>> +
>> Might first thought on seeing this is that it would be better to return
>> raw for all channels and provide the scale and offset info_mask elements
>> where possible rather than doing the conversion in the kernel.  Note we
> In our custom kernel branch battery driver needs battery voltage and
> temperature.  Thus the conversion anyway is done in the kernel, either
> in ADC driver or battery driver.
>
>> allow really quite a bit of precision on those values so I doubt it
>> will be a problem.
>>
>> If nothing else it would make everything rather more consistent.
>>
> [...]
>
>>> +static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
>>> +{
>>> +     int chn, d1 = 0, d2 = 0, temp;
>>> +     u8 trim_regs[17];
>>> +     int ret;
>>> +
>>> +     ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
>>> +                     TWL6030_GPADC_TRIM1, 16);
>>> +     if (ret < 0) {
>>> +             dev_err(gpadc->dev, "calibration failed\n");
>>> +             return ret;
>>> +     }
>>> +
>> /*
>> * Loop
>> please for kernel code.
>>> +     /* Loop to calculate the value needed for returning voltages from
>>> +      * GPADC not values.
>>> +      *
>>> +      * gain is calculated to 3 decimal places fixed point.
>>> +      */
>>> +     for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
>>> +
>>> +             switch (chn) {
>>> +             case 0:
>>> +             case 1:
>>> +             case 2:
>>> +             case 3:
>>> +             case 4:
>>> +             case 5:
>>> +             case 6:
>>> +             case 11:
>>> +             case 12:
>>> +             case 13:
>>> +             case 14:
>>> +                     /* D1 */
>>> +                     d1 = (trim_regs[3] & 0x1F) << 2;
>>> +                     d1 |= (trim_regs[1] & 0x06) >> 1;
>>> +                     if (trim_regs[1] & 0x01)
>>> +                             d1 = -d1;
>>> +
>>> +                     /* D2 */
>>> +                     d2 = (trim_regs[4] & 0x3F) << 2;
>>> +                     d2 |= (trim_regs[2] & 0x06) >> 1;
>>> +                     if (trim_regs[2] & 0x01)
>>> +                             d2 = -d2;
>>> +                     break;
>>> +             case 8:
>> No coment on your code, but this is an 'interesting' bit
>> of bit packing...
>> I did vaguely wonder if this could be mapped to a big lookup table,
>> but having tried it I think I end up with something almost as tricky
>> to read.. Oh well that was a fun 10 minute diversion ;)
> This is inherited code from Graeme - original author of implementation
> for twl6032.
> [...]
>
That bit is the bane of my life :-( I think the data sheet used to
changed weekly as the hardware guys did not understand the difference
between ones and twos complement!

The reason for the crazy packing is there was not enough space allocated
in hardware for the change from 10 to 12 bits for the error values
between 6030 and 6032.

Graeme



From rogerq at ti.com  Mon Jul 15 10:05:13 2013
From: rogerq at ti.com (Roger Quadros)
Date: Mon, 15 Jul 2013 17:05:13 +0300
Subject: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock
In-Reply-To: <1371571487-14389-5-git-send-email-rogerq@ti.com>
References: <1371571487-14389-1-git-send-email-rogerq@ti.com>
 <1371571487-14389-5-git-send-email-rogerq@ti.com>
Message-ID: <51E40199.9070906@ti.com>

Hi Tony,

On 06/18/2013 07:04 PM, Roger Quadros wrote:
> Till the OMAP clocks are correctly defined in device tree, use
> this temporary hack to provide clock alias to the USB PHY clocks.
> 
> Without this, USB Host & Ethernet will not be functional with
> device tree boots on Panda and uEVM.

Looks like this one got missed out.

USB host no longer works on Panda with DT boot.
Could you please queue this for next 3.11-rc? Thanks.

cheers,
-roger

> 
> Signed-off-by: Roger Quadros <rogerq at ti.com>
> ---
>  arch/arm/mach-omap2/board-generic.c |   23 ++++++++++++++++++++++-
>  1 files changed, 22 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index 88aa6b1..7428733 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -15,6 +15,7 @@
>  #include <linux/of_irq.h>
>  #include <linux/of_platform.h>
>  #include <linux/irqdomain.h>
> +#include <linux/clk.h>
>  
>  #include <asm/mach/arch.h>
>  
> @@ -35,6 +36,21 @@ static struct of_device_id omap_dt_match_table[] __initdata = {
>  	{ }
>  };
>  
> +/*
> + * Create alias for USB host PHY clock.
> + * Remove this when clock phandle can be provided via DT
> + */
> +static void __init legacy_init_ehci_clk(char *clkname)
> +{
> +	int ret;
> +
> +	ret = clk_add_alias("main_clk", NULL, clkname, NULL);
> +	if (ret) {
> +		pr_err("%s:Failed to add main_clk alias to %s :%d\n",
> +						__func__, clkname, ret);
> +	}
> +}
> +
>  static void __init omap_generic_init(void)
>  {
>  	omap_sdrc_init(NULL, NULL);
> @@ -45,10 +61,15 @@ static void __init omap_generic_init(void)
>  	 * HACK: call display setup code for selected boards to enable omapdss.
>  	 * This will be removed when omapdss supports DT.
>  	 */
> -	if (of_machine_is_compatible("ti,omap4-panda"))
> +	if (of_machine_is_compatible("ti,omap4-panda")) {
>  		omap4_panda_display_init_of();
> +		legacy_init_ehci_clk("auxclk3_ck");
> +
> +	}
>  	else if (of_machine_is_compatible("ti,omap4-sdp"))
>  		omap_4430sdp_display_init_of();
> +	else if (of_machine_is_compatible("ti,omap5-uevm"))
> +		legacy_init_ehci_clk("auxclk1_ck");
>  }
>  
>  #ifdef CONFIG_SOC_OMAP2420
> 



From linux at arm.linux.org.uk  Mon Jul 15 10:08:25 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Jul 2013 15:08:25 +0100
Subject: [PATCH] ARM: a.out: remove partial a.out support
In-Reply-To: <1373894897-30607-1-git-send-email-will.deacon@arm.com>
References: <1373894897-30607-1-git-send-email-will.deacon@arm.com>
Message-ID: <20130715140825.GU24642@n2100.arm.linux.org.uk>

On Mon, Jul 15, 2013 at 02:28:17PM +0100, Will Deacon wrote:
>  arch/arm/include/uapi/asm/Kbuild  |  1 -
>  arch/arm/include/uapi/asm/a.out.h | 34 -----------------------------

I don't think we can remove this quite as easily as this - this is
a user visible API change as it's part of the userland headers, and
will break anything in userspace which includes <a.out.h>


From julien.grall at linaro.org  Mon Jul 15 10:15:06 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Mon, 15 Jul 2013 15:15:06 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress debug
 is disabled
Message-ID: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>

Even if uncompress debug is disabled, some board will continue to print
information during uncompress step.
By using debug/uncompress.h include, all debug output will be disabled.

This is usefull in Xen environment for DOM0 because the UART is stolen by
Xen.

Signed-off-by: Julien Grall <julien.grall at linaro.org>
---
 arch/arm/Kconfig.debug |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 21cc8a7..86c023d 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -679,7 +679,7 @@ config DEBUG_UNCOMPRESS
 
 config UNCOMPRESS_INCLUDE
 	string
-	default "debug/uncompress.h" if ARCH_MULTIPLATFORM
+	default "debug/uncompress.h" if ARCH_MULTIPLATFORM || !DEBUG_UNCOMPRESS
 	default "mach/uncompress.h"
 
 config EARLY_PRINTK
-- 
1.7.10.4



From julien.grall at linaro.org  Mon Jul 15 10:21:41 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Mon, 15 Jul 2013 15:21:41 +0100
Subject: [PATCH] xen/arm: disable cpuidle when linux is running as dom0
Message-ID: <1373898101-15633-1-git-send-email-julien.grall@linaro.org>

When linux is running as dom0, Xen doesn't show the physical cpu but a
virtual CPU.
On some ARM SOC (for instance the exynos 5250), linux registers callbacks
for cpuidle. When these callbacks are called, they will modify
directly the physical cpu not the virtual one. It can impact the whole board
instead of dom0.

Signed-off-by: Julien Grall <julien.grall at linaro.org>
---
 arch/arm/xen/enlighten.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 49839d8..a98999f 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -24,6 +24,8 @@
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/of_address.h>
+#include <linux/cpuidle.h>
+#include <linux/cpufreq.h>
 
 #include <linux/mm.h>
 
@@ -292,6 +294,11 @@ static int __init xen_pm_init(void)
 {
 	pm_power_off = xen_power_off;
 	arm_pm_restart = xen_restart;
+	/*
+	 * Making sure board specific code will not set up ops for
+	 * cpu idle.
+	 */
+	disable_cpuidle();
 
 	return 0;
 }
-- 
1.7.10.4



From agraf at suse.de  Mon Jul 15 10:21:47 2013
From: agraf at suse.de (Alexander Graf)
Date: Mon, 15 Jul 2013 16:21:47 +0200
Subject: [PATCH] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene host
In-Reply-To: <CAAhSdy1tYsdm-2kJzoRfqb-FaPa0-t9x2+=jtMjgFqes+Pco6Q@mail.gmail.com>
References: <1373888788-8055-1-git-send-email-anup.patel@linaro.org>
 <51E3ED7A.7050207@arm.com>
 <CAAhSdy25WVnynDyPcOMtqVNEepGGq9WFT3b1PV34P6iSBm-FUg@mail.gmail.com>
 <73A8FA0E-9F7F-4866-9544-57838F30BB91@suse.de>
 <CAAhSdy1tYsdm-2kJzoRfqb-FaPa0-t9x2+=jtMjgFqes+Pco6Q@mail.gmail.com>
Message-ID: <03C760B4-A395-491C-B589-0689BC2C48BB@suse.de>


On 15.07.2013, at 16:04, Anup Patel wrote:

> On Mon, Jul 15, 2013 at 6:32 PM, Alexander Graf <agraf at suse.de> wrote:
>> 
>> On 15.07.2013, at 14:56, Anup Patel wrote:
>> 
>>> Hi Marc,
>>> 
>>> On Mon, Jul 15, 2013 at 6:09 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>> Hi Anup,
>>>> 
>>>> On 15/07/13 12:46, Anup Patel wrote:
>>>>> This patch allows us to have X-Gene guest VCPU when using
>>>>> KVM arm64 on APM X-Gene host.
>>>>> 
>>>>> We add KVM_ARM_TARGET_XGENE_V8 for X-Gene compatible guest VCPU
>>>>> and we return KVM_ARM_TARGET_XGENE_V8 in kvm_target_cpu() when
>>>>> running on X-Gene host.
>>>>> 
>>>>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>>>>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>>>> ---
>>>>> arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
>>>>> arch/arm64/kvm/guest.c               |   34 ++++++++++++++++++++++------------
>>>>> arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
>>>>> 3 files changed, 27 insertions(+), 13 deletions(-)
>>>>> 
>>>>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>>>>> index 5031f42..8194707 100644
>>>>> --- a/arch/arm64/include/uapi/asm/kvm.h
>>>>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>>>>> @@ -55,8 +55,9 @@ struct kvm_regs {
>>>>> #define KVM_ARM_TARGET_AEM_V8                0
>>>>> #define KVM_ARM_TARGET_FOUNDATION_V8 1
>>>>> #define KVM_ARM_TARGET_CORTEX_A57    2
>>>>> +#define KVM_ARM_TARGET_XGENE_V8              3
>>>>> 
>>>>> -#define KVM_ARM_NUM_TARGETS          3
>>>>> +#define KVM_ARM_NUM_TARGETS          4
>>>>> 
>>>>> /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
>>>>> #define KVM_ARM_DEVICE_TYPE_SHIFT    0
>>>>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>>>>> index 2c3ff67..e99b0a5 100644
>>>>> --- a/arch/arm64/kvm/guest.c
>>>>> +++ b/arch/arm64/kvm/guest.c
>>>>> @@ -207,19 +207,29 @@ int __attribute_const__ kvm_target_cpu(void)
>>>>>     unsigned long implementor = read_cpuid_implementor();
>>>>>     unsigned long part_number = read_cpuid_part_number();
>>>>> 
>>>>> -     if (implementor != ARM_CPU_IMP_ARM)
>>>>> -             return -EINVAL;
>>>>> -
>>>>> -     switch (part_number) {
>>>>> -     case ARM_CPU_PART_AEM_V8:
>>>>> -             return KVM_ARM_TARGET_AEM_V8;
>>>>> -     case ARM_CPU_PART_FOUNDATION:
>>>>> -             return KVM_ARM_TARGET_FOUNDATION_V8;
>>>>> -     case ARM_CPU_PART_CORTEX_A57:
>>>>> -             /* Currently handled by the generic backend */
>>>>> -             return KVM_ARM_TARGET_CORTEX_A57;
>>>>> +     switch (implementor) {
>>>>> +     case ARM_CPU_IMP_ARM:
>>>>> +             switch (part_number) {
>>>>> +             case ARM_CPU_PART_AEM_V8:
>>>>> +                     return KVM_ARM_TARGET_AEM_V8;
>>>>> +             case ARM_CPU_PART_FOUNDATION:
>>>>> +                     return KVM_ARM_TARGET_FOUNDATION_V8;
>>>>> +             case ARM_CPU_PART_CORTEX_A57:
>>>>> +                     return KVM_ARM_TARGET_CORTEX_A57;
>>>>> +             default:
>>>>> +                     return -EINVAL;
>>>>> +             }
>>>>> +             break;
>>>>> +     case ARM_CPU_IMP_APM:
>>>>> +             switch (part_number) {
>>>>> +             case APM_CPU_PART_POTENZA:
>>>>> +                     return KVM_ARM_TARGET_XGENE_V8;
>>>> 
>>>> Why don't we have KVM_ARM_TARGET_XGENE_POTENZA (or something similar)
>>>> instead? I don't expect all the X-Gene CPUs to be the same forever...
>>> 
>>> OK, I will rename it to KVM_ARM_TARGET_XGENE_POTENZA.
>>> 
>>> Does this mean that with every new ARM64 CPU we will have to add a new
>>> target for KVM ARM64 ?
>> 
>> Only for different core types, no? Any Cortex-A57 should still behave the same.
>> 
>>> If so then I think the list of targets will grow very fast.
>>> 
>>> I also realized that if we add a new target type in KVM ARM64 then we have
>>> to also update KVMTOOL to use the new target else KVMTOOL fails to
>>> recognize the target provided by KVM ARM64.
>> 
>> Right. It might make sense to have a fetch mechanism for the host cpu part. So you can ask KVM for the host cpu type and pass that back in here.
>> 
>>> Do you think we can have KVM_ARM_TARGET_xxx to represent a common
>>> target for a family of CPUs from given ARM64 vendor?
>> 
>> Anything that is compatible is compatible :). I don't know the product roadmaps for X-Gene cores, but you will want to make the field here as coarse grained as possible, while maintaining the guarantee that a guest still behaves the same.
> 
> Actually, I don't see X-Gene cores changing in-terms of register interface
> available to EL1 and EL0 in near future. This is the reason why I had named
> the target as KVM_ARM_TARGET_XGENE_V8.

So where does the v8 come from? Is there any non-ARMv8 XGene? If not, this is v1 really, right? What if we just call it v1 instead? Then when a new core comes up that needs different treatment, we create a new target.

But this really is Marc's call.


Alex



From otavio at ossystems.com.br  Mon Jul 15 10:22:36 2013
From: otavio at ossystems.com.br (Otavio Salvador)
Date: Mon, 15 Jul 2013 11:22:36 -0300
Subject: [PATCH 1/5] ARM: dts: imx23-evk: enable USB PHY and controller
Message-ID: <1373898160-8460-1-git-send-email-otavio@ossystems.com.br>

The i.MX23EVK board provides a USB port so the USB PHY and controller
need to be enabled for it to be usable.

Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
---
 arch/arm/boot/dts/imx23-evk.dts | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index da0588a..dc3ab45 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -107,6 +107,16 @@
 				pinctrl-0 = <&duart_pins_a>;
 				status = "okay";
 			};
+
+			usbphy0: usbphy at 8007c000 {
+				status = "okay";
+			};
+		};
+	};
+
+	ahb at 80080000 {
+		usb0: usb at 80080000 {
+			status = "okay";
 		};
 	};
 
-- 
1.8.3.2



From otavio at ossystems.com.br  Mon Jul 15 10:22:38 2013
From: otavio at ossystems.com.br (Otavio Salvador)
Date: Mon, 15 Jul 2013 11:22:38 -0300
Subject: [PATCH 3/5] ARM: dts: imx23-evk: enable Low Resolution ADC
In-Reply-To: <1373898160-8460-1-git-send-email-otavio@ossystems.com.br>
References: <1373898160-8460-1-git-send-email-otavio@ossystems.com.br>
Message-ID: <1373898160-8460-3-git-send-email-otavio@ossystems.com.br>

The i.XM23 has a internal Low Resolution ADC; this enables the support
for this device.

Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
---
 arch/arm/boot/dts/imx23-evk.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index dc3ab45..185c7c0 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -90,6 +90,11 @@
 		};
 
 		apbx at 80040000 {
+			lradc at 80050000 {
+				status = "okay";
+				fsl,lradc-touchscreen-wires = <4>;
+			};
+
 			pwm: pwm at 80064000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&pwm2_pins_a>;
-- 
1.8.3.2



From otavio at ossystems.com.br  Mon Jul 15 10:22:39 2013
From: otavio at ossystems.com.br (Otavio Salvador)
Date: Mon, 15 Jul 2013 11:22:39 -0300
Subject: [PATCH 4/5] ARM: dts: imx23-olinuxino: enable Low Resolution ADC
In-Reply-To: <1373898160-8460-1-git-send-email-otavio@ossystems.com.br>
References: <1373898160-8460-1-git-send-email-otavio@ossystems.com.br>
Message-ID: <1373898160-8460-4-git-send-email-otavio@ossystems.com.br>

The i.XM23 has a internal Low Resolution ADC; this enables the support
for this device.

Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
---
 arch/arm/boot/dts/imx23-olinuxino.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts b/arch/arm/boot/dts/imx23-olinuxino.dts
index d107c4a..fc766ae 100644
--- a/arch/arm/boot/dts/imx23-olinuxino.dts
+++ b/arch/arm/boot/dts/imx23-olinuxino.dts
@@ -69,6 +69,10 @@
 		};
 
 		apbx at 80040000 {
+			lradc at 80050000 {
+				status = "okay";
+			};
+
 			duart: serial at 80070000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&duart_pins_a>;
-- 
1.8.3.2



From julien.grall at linaro.org  Mon Jul 15 10:23:39 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Mon, 15 Jul 2013 15:23:39 +0100
Subject: [PATCH] xen/arm: enable PV control for ARM
Message-ID: <1373898219-15713-1-git-send-email-julien.grall@linaro.org>

Enable power management from the toolstack for ARM guest.

Signed-off-by: Julien Grall <julien.grall at linaro.org>
---
 drivers/xen/Makefile |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 2bf461a..a5f12bd 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,9 +1,8 @@
 ifneq ($(CONFIG_ARM),y)
-obj-y	+= manage.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
 obj-$(CONFIG_X86)			+= fallback.o
-obj-y	+= grant-table.o features.o events.o balloon.o time.o
+obj-y	+= grant-table.o features.o events.o balloon.o time.o manage.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
-- 
1.7.10.4



From julien.grall at linaro.org  Mon Jul 15 10:24:35 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Mon, 15 Jul 2013 15:24:35 +0100
Subject: [PATCH] xen/control: protect functions with
 CONFIG_HIBERNATE_CALLBACKS to avoid warning
Message-ID: <1373898275-15765-1-git-send-email-julien.grall@linaro.org>

If CONFIG_HIBERNATE_CALLBACKS is not set gcc will issue warnings:
drivers/xen/manage.c:46:13: warning: 'xen_hvm_post_suspend' defined but not used [-Wunused-function]
drivers/xen/manage.c:52:13: warning: 'xen_pre_suspend' defined but not used [-Wunused-function]
drivers/xen/manage.c:59:13: warning: 'xen_post_suspend' defined but not used [-Wunused-function]

Signed-off-by: Julien Grall <julien.grall at linaro.org>
---
 drivers/xen/manage.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index 412b96c..7680276 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -36,6 +36,7 @@ enum shutdown_state {
 /* Ignore multiple shutdown requests. */
 static enum shutdown_state shutting_down = SHUTDOWN_INVALID;
 
+#ifdef CONFIG_HIBERNATE_CALLBACKS
 struct suspend_info {
 	int cancelled;
 	unsigned long arg; /* extra hypercall argument */
@@ -63,7 +64,6 @@ static void xen_post_suspend(int cancelled)
 	xen_mm_unpin_all();
 }
 
-#ifdef CONFIG_HIBERNATE_CALLBACKS
 static int xen_suspend(void *data)
 {
 	struct suspend_info *si = data;
-- 
1.7.10.4



From gregory.clement at free-electrons.com  Mon Jul 15 10:24:35 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 15 Jul 2013 16:24:35 +0200
Subject: [PATCH 0/3] i2c-mv64xxx: Fixes and new feature for controlers
 embedded in Aramda XP
Message-ID: <1373898278-4805-1-git-send-email-gregory.clement@free-electrons.com>

Hello,

this patch set adds support for the I2C Transaction Generator which
offloads CPU from managing I2C transfer step by step. This feature is
currently only available on the I2C controller IP embedded in the
Armada XP SoC.

This is mainly a updated series rebased on 3.11-rc1.

This series also contains a real fix for the I2C controller of the
Armada XP SoC.

The first two patches modify the driver itself and should go through
i2c subsystem.

The last patch updates the device tree to be able to use this new
feature and should go through mvebu subsystem.

Thanks,

Change log:
v3->v4:

 - reverse the order of the compatible strings, with the most
   specific first

 - rebased on 3.11-rc1

v2->v3:

 - Introduces a new compatible string mv78230-i2c which will be used
   for the fix and for the offload feature which are only present on
   the Armada XP SoCs

 - Removes the unneeded spin_lock_irqsave pointed by Russell King

 - The offload mechanism is now port of the fsm and handle the
   multiple messages.

 - The flag bridge-enabled is renamed to offload_enabled, but the
   register name stills contains the BRIDGE word to match the
   datasheet.

 - Uses writel_relaxed on the place pointed by Russell King

 - Uses the bool type for the flag (pointed by Thomas Petazzoni)

 - Removes useless code (pointed by Thomas Petazzoni)

 - Updates the bindings documentation

v1->v2:
 - Move the flag for the timing issue from global scope to per device
   scope
 - Assignment is no more done in if condition


Gregory CLEMENT (3):
  i2c-mv64xxx: Add I2C Transaction Generator support
  i2c-mv64xxx: Fix timing issue on Armada XP (errata FE-8471889)
  ARM: dts: mvebu: Introduce a new compatible string for mv64xxx-i2c

 .../devicetree/bindings/i2c/i2c-mv64xxx.txt        |  13 +-
 arch/arm/boot/dts/armada-370-xp.dtsi               |   2 -
 arch/arm/boot/dts/armada-370.dtsi                  |   8 +
 arch/arm/boot/dts/armada-xp.dtsi                   |  10 +
 drivers/i2c/busses/i2c-mv64xxx.c                   | 216 ++++++++++++++++++++-
 5 files changed, 236 insertions(+), 13 deletions(-)

-- 
1.8.1.2



From gregory.clement at free-electrons.com  Mon Jul 15 10:24:36 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 15 Jul 2013 16:24:36 +0200
Subject: [PATCH 1/3] i2c-mv64xxx: Add I2C Transaction Generator support
In-Reply-To: <1373898278-4805-1-git-send-email-gregory.clement@free-electrons.com>
References: <1373898278-4805-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1373898278-4805-2-git-send-email-gregory.clement@free-electrons.com>

The I2C Transaction Generator offloads CPU from managing I2C
transfer step by step.

This feature is currently only available on Armada XP, so usage of
this mechanism is activated through device tree.

Based on the work of Piotr Ziecik and rewrote to use the new way of
handling multiples i2c messages.

Signed-off-by: Piotr Ziecik <kosmo at semihalf.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/i2c/busses/i2c-mv64xxx.c | 207 ++++++++++++++++++++++++++++++++++++---
 1 file changed, 196 insertions(+), 11 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index b1f42bf..355ab64 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -55,6 +55,32 @@
 #define	MV64XXX_I2C_STATUS_MAST_RD_ADDR_2_NO_ACK	0xe8
 #define	MV64XXX_I2C_STATUS_NO_STATUS			0xf8
 
+/* Register defines (I2C bridge) */
+#define	MV64XXX_I2C_REG_TX_DATA_LO			0xc0
+#define	MV64XXX_I2C_REG_TX_DATA_HI			0xc4
+#define	MV64XXX_I2C_REG_RX_DATA_LO			0xc8
+#define	MV64XXX_I2C_REG_RX_DATA_HI			0xcc
+#define	MV64XXX_I2C_REG_BRIDGE_CONTROL			0xd0
+#define	MV64XXX_I2C_REG_BRIDGE_STATUS			0xd4
+#define	MV64XXX_I2C_REG_BRIDGE_INTR_CAUSE		0xd8
+#define	MV64XXX_I2C_REG_BRIDGE_INTR_MASK		0xdC
+#define	MV64XXX_I2C_REG_BRIDGE_TIMING			0xe0
+
+/* Bridge Control values */
+#define	MV64XXX_I2C_BRIDGE_CONTROL_WR			0x00000001
+#define	MV64XXX_I2C_BRIDGE_CONTROL_RD			0x00000002
+#define	MV64XXX_I2C_BRIDGE_CONTROL_ADDR_SHIFT		2
+#define	MV64XXX_I2C_BRIDGE_CONTROL_ADDR_EXT		0x00001000
+#define	MV64XXX_I2C_BRIDGE_CONTROL_TX_SIZE_SHIFT	13
+#define	MV64XXX_I2C_BRIDGE_CONTROL_RX_SIZE_SHIFT	16
+#define	MV64XXX_I2C_BRIDGE_CONTROL_ENABLE		0x00080000
+
+/* Bridge Status values */
+#define	MV64XXX_I2C_BRIDGE_STATUS_ERROR			0x00000001
+#define	MV64XXX_I2C_STATUS_OFFLOAD_ERROR		0xf0000001
+#define	MV64XXX_I2C_STATUS_OFFLOAD_OK			0xf0000000
+
+
 /* Driver states */
 enum {
 	MV64XXX_I2C_STATE_INVALID,
@@ -71,14 +97,17 @@ enum {
 enum {
 	MV64XXX_I2C_ACTION_INVALID,
 	MV64XXX_I2C_ACTION_CONTINUE,
+	MV64XXX_I2C_ACTION_OFFLOAD_SEND_START,
 	MV64XXX_I2C_ACTION_SEND_START,
 	MV64XXX_I2C_ACTION_SEND_RESTART,
+	MV64XXX_I2C_ACTION_OFFLOAD_RESTART,
 	MV64XXX_I2C_ACTION_SEND_ADDR_1,
 	MV64XXX_I2C_ACTION_SEND_ADDR_2,
 	MV64XXX_I2C_ACTION_SEND_DATA,
 	MV64XXX_I2C_ACTION_RCV_DATA,
 	MV64XXX_I2C_ACTION_RCV_DATA_STOP,
 	MV64XXX_I2C_ACTION_SEND_STOP,
+	MV64XXX_I2C_ACTION_OFFLOAD_SEND_STOP,
 };
 
 struct mv64xxx_i2c_regs {
@@ -117,6 +146,7 @@ struct mv64xxx_i2c_data {
 	spinlock_t		lock;
 	struct i2c_msg		*msg;
 	struct i2c_adapter	adapter;
+	bool			offload_enabled;
 };
 
 static struct mv64xxx_i2c_regs mv64xxx_i2c_regs_mv64xxx = {
@@ -165,6 +195,79 @@ mv64xxx_i2c_prepare_for_io(struct mv64xxx_i2c_data *drv_data,
 	}
 }
 
+static int mv64xxx_i2c_offload_msg(struct mv64xxx_i2c_data *drv_data)
+{
+	unsigned long data_reg_hi = 0;
+	unsigned long data_reg_lo = 0;
+	unsigned long ctrl_reg;
+	unsigned int i;
+	struct i2c_msg *msg = drv_data->msgs;
+
+	drv_data->msg = msg;
+	drv_data->byte_posn = 0;
+	drv_data->bytes_left = msg->len;
+	drv_data->aborting = 0;
+	drv_data->rc = 0;
+	/* Only regular transactions can be offloaded */
+	if ((msg->flags & ~(I2C_M_TEN | I2C_M_RD)) != 0)
+		return 1;
+
+	/* Only 1-8 byte transfers can be offloaded */
+	if (msg->len < 1 || msg->len > 8)
+		return 1;
+
+	/* Build transaction */
+	ctrl_reg = MV64XXX_I2C_BRIDGE_CONTROL_ENABLE |
+		   (msg->addr << MV64XXX_I2C_BRIDGE_CONTROL_ADDR_SHIFT);
+
+	if ((msg->flags & I2C_M_TEN) != 0)
+		ctrl_reg |=  MV64XXX_I2C_BRIDGE_CONTROL_ADDR_EXT;
+
+	if ((msg->flags & I2C_M_RD) == 0) {
+		for (i = 0; i < 4 && i < msg->len; i++)
+			data_reg_lo = data_reg_lo |
+					(msg->buf[i] << ((i & 0x3) * 8));
+
+		for (i = 4; i < 8 && i < msg->len; i++)
+			data_reg_hi = data_reg_hi |
+					(msg->buf[i] << ((i & 0x3) * 8));
+
+		ctrl_reg |= MV64XXX_I2C_BRIDGE_CONTROL_WR |
+		    (msg->len - 1) << MV64XXX_I2C_BRIDGE_CONTROL_TX_SIZE_SHIFT;
+	} else {
+		ctrl_reg |= MV64XXX_I2C_BRIDGE_CONTROL_RD |
+		    (msg->len - 1) << MV64XXX_I2C_BRIDGE_CONTROL_RX_SIZE_SHIFT;
+	}
+
+	/* Execute transaction */
+	writel_relaxed(data_reg_lo,
+		drv_data->reg_base + MV64XXX_I2C_REG_TX_DATA_LO);
+	writel_relaxed(data_reg_hi,
+		drv_data->reg_base + MV64XXX_I2C_REG_TX_DATA_HI);
+	writel(ctrl_reg, drv_data->reg_base + MV64XXX_I2C_REG_BRIDGE_CONTROL);
+
+	return 0;
+}
+
+static void
+mv64xxx_i2c_update_offload_data(struct i2c_msg *msg, unsigned long data_reg_hi,
+	unsigned long data_reg_lo)
+{
+	int i;
+
+	if ((msg->flags & I2C_M_RD) != 0) {
+		for (i = 0; i < 4 && i < msg->len; i++) {
+			msg->buf[i] = data_reg_lo & 0xFF;
+			data_reg_lo >>= 8;
+		}
+
+		for (i = 4; i < 8 && i < msg->len; i++) {
+			msg->buf[i] = data_reg_hi & 0xFF;
+			data_reg_hi >>= 8;
+		}
+	}
+
+}
 /*
  *****************************************************************************
  *
@@ -177,6 +280,15 @@ mv64xxx_i2c_prepare_for_io(struct mv64xxx_i2c_data *drv_data,
 static void
 mv64xxx_i2c_hw_init(struct mv64xxx_i2c_data *drv_data)
 {
+	if (drv_data->offload_enabled) {
+		writel(0, drv_data->reg_base + MV64XXX_I2C_REG_BRIDGE_CONTROL);
+		writel(0, drv_data->reg_base + MV64XXX_I2C_REG_BRIDGE_TIMING);
+		writel(0, drv_data->reg_base +
+			MV64XXX_I2C_REG_BRIDGE_INTR_CAUSE);
+		writel(0, drv_data->reg_base +
+			MV64XXX_I2C_REG_BRIDGE_INTR_MASK);
+	}
+
 	writel(0, drv_data->reg_base + drv_data->reg_offsets.soft_reset);
 	writel(MV64XXX_I2C_BAUD_DIV_M(drv_data->freq_m) | MV64XXX_I2C_BAUD_DIV_N(drv_data->freq_n),
 		drv_data->reg_base + drv_data->reg_offsets.clock);
@@ -283,6 +395,16 @@ mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 status)
 		drv_data->rc = -ENXIO;
 		break;
 
+	case MV64XXX_I2C_STATUS_OFFLOAD_OK:
+		if (drv_data->send_stop || drv_data->aborting) {
+			drv_data->action = MV64XXX_I2C_ACTION_OFFLOAD_SEND_STOP;
+			drv_data->state = MV64XXX_I2C_STATE_IDLE;
+		} else {
+			drv_data->action = MV64XXX_I2C_ACTION_OFFLOAD_RESTART;
+			drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_RESTART;
+		}
+		break;
+
 	default:
 		dev_err(&drv_data->adapter.dev,
 			"mv64xxx_i2c_fsm: Ctlr Error -- state: 0x%x, "
@@ -298,21 +420,36 @@ mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 status)
 static void
 mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
 {
+	unsigned long data_reg_hi = 0;
+	unsigned long data_reg_lo = 0;
+
 	switch(drv_data->action) {
+	case MV64XXX_I2C_ACTION_OFFLOAD_RESTART:
+		data_reg_lo = readl(drv_data->reg_base +
+				MV64XXX_I2C_REG_RX_DATA_LO);
+		data_reg_hi = readl(drv_data->reg_base +
+				MV64XXX_I2C_REG_RX_DATA_HI);
+		mv64xxx_i2c_update_offload_data(drv_data->msg, data_reg_hi,
+						data_reg_lo);
+		writel(0, drv_data->reg_base +	MV64XXX_I2C_REG_BRIDGE_CONTROL);
+		writel(0, drv_data->reg_base +
+			MV64XXX_I2C_REG_BRIDGE_INTR_CAUSE);
+		/* FALLTHRU */
 	case MV64XXX_I2C_ACTION_SEND_RESTART:
 		/* We should only get here if we have further messages */
 		BUG_ON(drv_data->num_msgs == 0);
 
-		drv_data->cntl_bits |= MV64XXX_I2C_REG_CONTROL_START;
-		writel(drv_data->cntl_bits,
-			drv_data->reg_base + drv_data->reg_offsets.control);
-
 		drv_data->msgs++;
 		drv_data->num_msgs--;
+		if (!(drv_data->offload_enabled &&
+				mv64xxx_i2c_offload_msg(drv_data))) {
+			drv_data->cntl_bits |= MV64XXX_I2C_REG_CONTROL_START;
+			writel(drv_data->cntl_bits,
+			drv_data->reg_base + drv_data->reg_offsets.control);
 
-		/* Setup for the next message */
-		mv64xxx_i2c_prepare_for_io(drv_data, drv_data->msgs);
-
+			/* Setup for the next message */
+			mv64xxx_i2c_prepare_for_io(drv_data, drv_data->msgs);
+		}
 		/*
 		 * We're never at the start of the message here, and by this
 		 * time it's already too late to do any protocol mangling.
@@ -326,6 +463,12 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
 			drv_data->reg_base + drv_data->reg_offsets.control);
 		break;
 
+	case MV64XXX_I2C_ACTION_OFFLOAD_SEND_START:
+		if (mv64xxx_i2c_offload_msg(drv_data) <= 0)
+			break;
+		else
+			drv_data->action = MV64XXX_I2C_ACTION_SEND_START;
+		/* FALLTHRU */
 	case MV64XXX_I2C_ACTION_SEND_START:
 		writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_START,
 			drv_data->reg_base + drv_data->reg_offsets.control);
@@ -375,6 +518,7 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
 			"mv64xxx_i2c_do_action: Invalid action: %d\n",
 			drv_data->action);
 		drv_data->rc = -EIO;
+
 		/* FALLTHRU */
 	case MV64XXX_I2C_ACTION_SEND_STOP:
 		drv_data->cntl_bits &= ~MV64XXX_I2C_REG_CONTROL_INTEN;
@@ -383,6 +527,20 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
 		drv_data->block = 0;
 		wake_up(&drv_data->waitq);
 		break;
+
+	case MV64XXX_I2C_ACTION_OFFLOAD_SEND_STOP:
+		data_reg_lo = readl(drv_data->reg_base +
+				MV64XXX_I2C_REG_RX_DATA_LO);
+		data_reg_hi = readl(drv_data->reg_base +
+				MV64XXX_I2C_REG_RX_DATA_HI);
+		mv64xxx_i2c_update_offload_data(drv_data->msg, data_reg_hi,
+						data_reg_lo);
+		writel(0, drv_data->reg_base +	MV64XXX_I2C_REG_BRIDGE_CONTROL);
+		writel(0, drv_data->reg_base +
+			MV64XXX_I2C_REG_BRIDGE_INTR_CAUSE);
+		drv_data->block = 0;
+		wake_up(&drv_data->waitq);
+		break;
 	}
 }
 
@@ -395,6 +553,21 @@ mv64xxx_i2c_intr(int irq, void *dev_id)
 	irqreturn_t	rc = IRQ_NONE;
 
 	spin_lock_irqsave(&drv_data->lock, flags);
+
+	if (drv_data->offload_enabled) {
+		while (readl(drv_data->reg_base +
+				MV64XXX_I2C_REG_BRIDGE_INTR_CAUSE)) {
+			int reg_status = readl(drv_data->reg_base +
+					MV64XXX_I2C_REG_BRIDGE_STATUS);
+			if (reg_status & MV64XXX_I2C_BRIDGE_STATUS_ERROR)
+				status = MV64XXX_I2C_STATUS_OFFLOAD_ERROR;
+			else
+				status = MV64XXX_I2C_STATUS_OFFLOAD_OK;
+			mv64xxx_i2c_fsm(drv_data, status);
+			mv64xxx_i2c_do_action(drv_data);
+			rc = IRQ_HANDLED;
+		}
+	}
 	while (readl(drv_data->reg_base + drv_data->reg_offsets.control) &
 						MV64XXX_I2C_REG_CONTROL_IFLG) {
 		status = readl(drv_data->reg_base + drv_data->reg_offsets.status);
@@ -459,11 +632,15 @@ mv64xxx_i2c_execute_msg(struct mv64xxx_i2c_data *drv_data, struct i2c_msg *msg,
 	unsigned long	flags;
 
 	spin_lock_irqsave(&drv_data->lock, flags);
-	mv64xxx_i2c_prepare_for_io(drv_data, msg);
-
-	drv_data->action = MV64XXX_I2C_ACTION_SEND_START;
-	drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_START_COND;
+	if (drv_data->offload_enabled) {
+		drv_data->action = MV64XXX_I2C_ACTION_OFFLOAD_SEND_START;
+		drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_START_COND;
+	} else {
+		mv64xxx_i2c_prepare_for_io(drv_data, msg);
 
+		drv_data->action = MV64XXX_I2C_ACTION_SEND_START;
+		drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_START_COND;
+	}
 	drv_data->send_stop = is_last;
 	drv_data->block = 1;
 	mv64xxx_i2c_do_action(drv_data);
@@ -601,6 +778,13 @@ mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
 
 	memcpy(&drv_data->reg_offsets, device->data, sizeof(drv_data->reg_offsets));
 
+	/*
+	 * For controllers embedded in new SoCs activate the
+	 * Transaction Generator support.
+	 */
+	if (of_device_is_compatible(np, "marvell,mv78230-i2c"))
+		drv_data->offload_enabled = true;
+
 out:
 	return rc;
 #endif
@@ -654,6 +838,7 @@ mv64xxx_i2c_probe(struct platform_device *pd)
 		drv_data->freq_n = pdata->freq_n;
 		drv_data->irq = platform_get_irq(pd, 0);
 		drv_data->adapter.timeout = msecs_to_jiffies(pdata->timeout);
+		drv_data->offload_enabled = 0;
 		memcpy(&drv_data->reg_offsets, &mv64xxx_i2c_regs_mv64xxx, sizeof(drv_data->reg_offsets));
 	} else if (pd->dev.of_node) {
 		rc = mv64xxx_of_config(drv_data, &pd->dev);
-- 
1.8.1.2



From gregory.clement at free-electrons.com  Mon Jul 15 10:24:37 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 15 Jul 2013 16:24:37 +0200
Subject: [PATCH 2/3] i2c-mv64xxx: Fix timing issue on Armada XP (errata
 FE-8471889)
In-Reply-To: <1373898278-4805-1-git-send-email-gregory.clement@free-electrons.com>
References: <1373898278-4805-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1373898278-4805-3-git-send-email-gregory.clement@free-electrons.com>

All the Armada XP (mv78230, mv78260 and mv78460) have a silicon issue
in the I2C controller which violate the i2c repeated start
timing. The I2C standard requires a minimum of 4.7us for the repeated
start condition whereas the I2C controller of the Armada XP this time
is 2.9us.

So this patch adds a 5us delay for the start case only if the
the compatible i2c-mv78230 is set.

Based on the initals patches from Zbigniew Bodek

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Signed-off-by: Zbigniew Bodek <zbb at semihalf.com>
---
 drivers/i2c/busses/i2c-mv64xxx.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 355ab64..75be30cce 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -24,6 +24,7 @@
 #include <linux/of_i2c.h>
 #include <linux/clk.h>
 #include <linux/err.h>
+#include <linux/delay.h>
 
 #define MV64XXX_I2C_ADDR_ADDR(val)			((val & 0x7f) << 1)
 #define MV64XXX_I2C_BAUD_DIV_N(val)			(val & 0x7)
@@ -147,6 +148,8 @@ struct mv64xxx_i2c_data {
 	struct i2c_msg		*msg;
 	struct i2c_adapter	adapter;
 	bool			offload_enabled;
+/* 5us delay in order to avoid repeated start timing violation */
+	bool			errata_delay;
 };
 
 static struct mv64xxx_i2c_regs mv64xxx_i2c_regs_mv64xxx = {
@@ -450,6 +453,9 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
 			/* Setup for the next message */
 			mv64xxx_i2c_prepare_for_io(drv_data, drv_data->msgs);
 		}
+		if (drv_data->errata_delay)
+			udelay(5);
+
 		/*
 		 * We're never at the start of the message here, and by this
 		 * time it's already too late to do any protocol mangling.
@@ -509,6 +515,9 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
 		writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_STOP,
 			drv_data->reg_base + drv_data->reg_offsets.control);
 		drv_data->block = 0;
+		if (drv_data->errata_delay)
+			udelay(5);
+
 		wake_up(&drv_data->waitq);
 		break;
 
@@ -780,10 +789,12 @@ mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
 
 	/*
 	 * For controllers embedded in new SoCs activate the
-	 * Transaction Generator support.
+	 * Transaction Generator support and the errata fix.
 	 */
-	if (of_device_is_compatible(np, "marvell,mv78230-i2c"))
+	if (of_device_is_compatible(np, "marvell,mv78230-i2c")) {
 		drv_data->offload_enabled = true;
+		drv_data->errata_delay = true;
+	}
 
 out:
 	return rc;
-- 
1.8.1.2



From gregory.clement at free-electrons.com  Mon Jul 15 10:24:38 2013
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 15 Jul 2013 16:24:38 +0200
Subject: [PATCH 3/3] ARM: dts: mvebu: Introduce a new compatible string for
 mv64xxx-i2c
In-Reply-To: <1373898278-4805-1-git-send-email-gregory.clement@free-electrons.com>
References: <1373898278-4805-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1373898278-4805-4-git-send-email-gregory.clement@free-electrons.com>

The mv64xxx-i2c embedded in the Armada XP have a new feature to
offload i2c transaction. This new version of the IP come also with
some errata. This lead to the introduction to a another compatible
string.

This commit split the i2c information into armada-370.dtsi and
armada-xp.dtsi. Most of the data remains the same and stay in the
common file Armada-370-xp.dtsi. With this new feature the size of the
registers are bigger for Armada XP and the new compatible string is
used.

The Device Tree binding documentation is updated accordingly.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt | 13 ++++++++++++-
 arch/arm/boot/dts/armada-370-xp.dtsi                  |  2 --
 arch/arm/boot/dts/armada-370.dtsi                     |  8 ++++++++
 arch/arm/boot/dts/armada-xp.dtsi                      | 10 ++++++++++
 4 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
index a1ee681..c5dd952 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
@@ -4,7 +4,8 @@
 Required properties :
 
  - reg             : Offset and length of the register set for the device
- - compatible      : Should be "marvell,mv64xxx-i2c"
+ - compatible      : Should be "marvell,mv64xxx-i2c" and "marvell,mv7230-i2c"
+for controller which support the I2C Transaction Generator
  - interrupts      : The interrupt number
 
 Optional properties :
@@ -20,3 +21,13 @@ Examples:
 		interrupts = <29>;
 		clock-frequency = <100000>;
 	};
+
+For a controller which support the I2C Transaction Generator:
+
+	i2c at 11000 {
+		compatible = "marvell,mv78230-i2c", "marvell,mv64xxx-i2c";
+		reg = <0x11000 0x100>;
+		compatible = "marvell,mv64xxx-i2c";
+		interrupts = <29>;
+		clock-frequency = <100000>;
+	};
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 90b1176..d8b24c9 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -121,7 +121,6 @@
 
 			i2c0: i2c at 11000 {
 				compatible = "marvell,mv64xxx-i2c";
-				reg = <0x11000 0x20>;
 				#address-cells = <1>;
 				#size-cells = <0>;
 				interrupts = <31>;
@@ -132,7 +131,6 @@
 
 			i2c1: i2c at 11100 {
 				compatible = "marvell,mv64xxx-i2c";
-				reg = <0x11100 0x20>;
 				#address-cells = <1>;
 				#size-cells = <0>;
 				interrupts = <32>;
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..0e2eefa 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -155,6 +155,14 @@
 				};
 			};
 
+			i2c0: i2c at 11000 {
+				reg = <0x11000 0x20>;
+			};
+
+			i2c1: i2c at 11100 {
+				reg = <0x11100 0x20>;
+			};
+
 			usb at 50000 {
 				clocks = <&coreclk 0>;
 			};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 416eb94..e1f2547 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -138,6 +138,16 @@
 				};
 			};
 
+			i2c0: i2c at 11000 {
+				compatible = "marvell,mv78230-i2c", "marvell,mv64xxx-i2c";
+				reg = <0x11000 0x100>;
+			};
+
+			i2c1: i2c at 11100 {
+				compatible = "marvell,mv78230-i2c", "marvell,mv64xxx-i2c";
+				reg = <0x11100 0x100>;
+			};
+
 			usb at 50000 {
 				clocks = <&gateclk 18>;
 			};
-- 
1.8.1.2



From shawn.guo at linaro.org  Mon Jul 15 10:30:30 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 15 Jul 2013 22:30:30 +0800
Subject: [PATCH 2/2] ARM: dts: imx51-babbage: Pass a real clock to the
 codec
In-Reply-To: <1370826467-30399-2-git-send-email-festevam@gmail.com>
References: <1370826467-30399-1-git-send-email-festevam@gmail.com>
 <1370826467-30399-2-git-send-email-festevam@gmail.com>
Message-ID: <20130715143028.GA23589@S2101-09.ap.freescale.net>

On Sun, Jun 09, 2013 at 10:07:47PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> On imx51_babbage the codec clock is activated via GPIO4_26.
> 
> Provide a real clock to the sgtl5000 codec via device tree.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Applied, thanks.



From anup at brainfault.org  Mon Jul 15 10:37:03 2013
From: anup at brainfault.org (Anup Patel)
Date: Mon, 15 Jul 2013 20:07:03 +0530
Subject: [PATCH] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene host
In-Reply-To: <03C760B4-A395-491C-B589-0689BC2C48BB@suse.de>
References: <1373888788-8055-1-git-send-email-anup.patel@linaro.org>
 <51E3ED7A.7050207@arm.com>
 <CAAhSdy25WVnynDyPcOMtqVNEepGGq9WFT3b1PV34P6iSBm-FUg@mail.gmail.com>
 <73A8FA0E-9F7F-4866-9544-57838F30BB91@suse.de>
 <CAAhSdy1tYsdm-2kJzoRfqb-FaPa0-t9x2+=jtMjgFqes+Pco6Q@mail.gmail.com>
 <03C760B4-A395-491C-B589-0689BC2C48BB@suse.de>
Message-ID: <CAAhSdy0JrJT0LnW7MEncHXKGb=qFUgjp43KSs70j_QEHSn3mfw@mail.gmail.com>

Hi Marc,

On Mon, Jul 15, 2013 at 7:51 PM, Alexander Graf <agraf at suse.de> wrote:
>
> On 15.07.2013, at 16:04, Anup Patel wrote:
>
>> On Mon, Jul 15, 2013 at 6:32 PM, Alexander Graf <agraf at suse.de> wrote:
>>>
>>> On 15.07.2013, at 14:56, Anup Patel wrote:
>>>
>>>> Hi Marc,
>>>>
>>>> On Mon, Jul 15, 2013 at 6:09 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>>> Hi Anup,
>>>>>
>>>>> On 15/07/13 12:46, Anup Patel wrote:
>>>>>> This patch allows us to have X-Gene guest VCPU when using
>>>>>> KVM arm64 on APM X-Gene host.
>>>>>>
>>>>>> We add KVM_ARM_TARGET_XGENE_V8 for X-Gene compatible guest VCPU
>>>>>> and we return KVM_ARM_TARGET_XGENE_V8 in kvm_target_cpu() when
>>>>>> running on X-Gene host.
>>>>>>
>>>>>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>>>>>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>>>>> ---
>>>>>> arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
>>>>>> arch/arm64/kvm/guest.c               |   34 ++++++++++++++++++++++------------
>>>>>> arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
>>>>>> 3 files changed, 27 insertions(+), 13 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>>>>>> index 5031f42..8194707 100644
>>>>>> --- a/arch/arm64/include/uapi/asm/kvm.h
>>>>>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>>>>>> @@ -55,8 +55,9 @@ struct kvm_regs {
>>>>>> #define KVM_ARM_TARGET_AEM_V8                0
>>>>>> #define KVM_ARM_TARGET_FOUNDATION_V8 1
>>>>>> #define KVM_ARM_TARGET_CORTEX_A57    2
>>>>>> +#define KVM_ARM_TARGET_XGENE_V8              3
>>>>>>
>>>>>> -#define KVM_ARM_NUM_TARGETS          3
>>>>>> +#define KVM_ARM_NUM_TARGETS          4
>>>>>>
>>>>>> /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
>>>>>> #define KVM_ARM_DEVICE_TYPE_SHIFT    0
>>>>>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>>>>>> index 2c3ff67..e99b0a5 100644
>>>>>> --- a/arch/arm64/kvm/guest.c
>>>>>> +++ b/arch/arm64/kvm/guest.c
>>>>>> @@ -207,19 +207,29 @@ int __attribute_const__ kvm_target_cpu(void)
>>>>>>     unsigned long implementor = read_cpuid_implementor();
>>>>>>     unsigned long part_number = read_cpuid_part_number();
>>>>>>
>>>>>> -     if (implementor != ARM_CPU_IMP_ARM)
>>>>>> -             return -EINVAL;
>>>>>> -
>>>>>> -     switch (part_number) {
>>>>>> -     case ARM_CPU_PART_AEM_V8:
>>>>>> -             return KVM_ARM_TARGET_AEM_V8;
>>>>>> -     case ARM_CPU_PART_FOUNDATION:
>>>>>> -             return KVM_ARM_TARGET_FOUNDATION_V8;
>>>>>> -     case ARM_CPU_PART_CORTEX_A57:
>>>>>> -             /* Currently handled by the generic backend */
>>>>>> -             return KVM_ARM_TARGET_CORTEX_A57;
>>>>>> +     switch (implementor) {
>>>>>> +     case ARM_CPU_IMP_ARM:
>>>>>> +             switch (part_number) {
>>>>>> +             case ARM_CPU_PART_AEM_V8:
>>>>>> +                     return KVM_ARM_TARGET_AEM_V8;
>>>>>> +             case ARM_CPU_PART_FOUNDATION:
>>>>>> +                     return KVM_ARM_TARGET_FOUNDATION_V8;
>>>>>> +             case ARM_CPU_PART_CORTEX_A57:
>>>>>> +                     return KVM_ARM_TARGET_CORTEX_A57;
>>>>>> +             default:
>>>>>> +                     return -EINVAL;
>>>>>> +             }
>>>>>> +             break;
>>>>>> +     case ARM_CPU_IMP_APM:
>>>>>> +             switch (part_number) {
>>>>>> +             case APM_CPU_PART_POTENZA:
>>>>>> +                     return KVM_ARM_TARGET_XGENE_V8;
>>>>>
>>>>> Why don't we have KVM_ARM_TARGET_XGENE_POTENZA (or something similar)
>>>>> instead? I don't expect all the X-Gene CPUs to be the same forever...
>>>>
>>>> OK, I will rename it to KVM_ARM_TARGET_XGENE_POTENZA.
>>>>
>>>> Does this mean that with every new ARM64 CPU we will have to add a new
>>>> target for KVM ARM64 ?
>>>
>>> Only for different core types, no? Any Cortex-A57 should still behave the same.
>>>
>>>> If so then I think the list of targets will grow very fast.
>>>>
>>>> I also realized that if we add a new target type in KVM ARM64 then we have
>>>> to also update KVMTOOL to use the new target else KVMTOOL fails to
>>>> recognize the target provided by KVM ARM64.
>>>
>>> Right. It might make sense to have a fetch mechanism for the host cpu part. So you can ask KVM for the host cpu type and pass that back in here.
>>>
>>>> Do you think we can have KVM_ARM_TARGET_xxx to represent a common
>>>> target for a family of CPUs from given ARM64 vendor?
>>>
>>> Anything that is compatible is compatible :). I don't know the product roadmaps for X-Gene cores, but you will want to make the field here as coarse grained as possible, while maintaining the guarantee that a guest still behaves the same.
>>
>> Actually, I don't see X-Gene cores changing in-terms of register interface
>> available to EL1 and EL0 in near future. This is the reason why I had named
>> the target as KVM_ARM_TARGET_XGENE_V8.
>
> So where does the v8 come from? Is there any non-ARMv8 XGene? If not, this is v1 really, right? What if we just call it v1 instead? Then when a new core comes up that needs different treatment, we create a new target.
>
> But this really is Marc's call.

I like Alex's suggestion.

How about having KVM_ARM_TARGET_XGENE_V1 now and
KVM_ARM_TARGET_XGENE_V2 in future ?

>
>
> Alex
>

--Anup


From richard.genoud at gmail.com  Mon Jul 15 10:53:46 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon, 15 Jul 2013 16:53:46 +0200
Subject: [PATCH v5 1/7] sound: codec: wm8731: add rates constraints
In-Reply-To: <20130712114551.GD24508@sirena.org.uk>
References: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
 <1373559359-31607-2-git-send-email-richard.genoud@gmail.com>
 <20130712114551.GD24508@sirena.org.uk>
Message-ID: <CACQ1gAhmp-i7vzPKuTMxqs9Ytjynz9NTvrQk9R08U9Fo-cVzMg@mail.gmail.com>

2013/7/12 Mark Brown <broonie at kernel.org>:
> On Thu, Jul 11, 2013 at 06:15:53PM +0200, Richard Genoud wrote:
>
> Please always try to use commit logs that look like normal commit logs
> for the subsystem.
Ok, I'll pay attention to that.

>>       switch (freq) {
>> -     case 11289600:
>>       case 12000000:
>> +             wm8731->constraints = &wm8731_constraints_12000000;
>> +             break;
>>       case 12288000:
>> -     case 16934400:
>>       case 18432000:
>> -             wm8731->sysclk = freq;
>> +             wm8731->constraints = &wm8731_constraints_12288000_18432000;
>> +             break;
>> +     case 16934400:
>> +     case 11289600:
>> +             wm8731->constraints = &wm8731_constraints_11289600_16934400;
>>               break;
>>       default:
>>               return -EINVAL;
>>       }
>
> This isn't going to work with systems which have a variable clock as the
> input to the CODEC.  If it's imposing constraints the driver needs to
> allow setting the clock to zero as a way of removing constraints (and
> any existing drivers should be updated to do this if needed).
Maybe I'm wrong, but I didn't find any system using variable clock
with this codec.
The sam9g20ek (soc/atmel/sam9g20_wm8731.c) is not using a crystal, but
it's using a fixed clock anyway.
But there's soc/pxa/corgi.c and soc/pxa/poodle.c that puzzle me.
They seems to use a crystal, but they are setting a different sysclk
depending on the rate.
That seems wrong, but as I'm a newbie in ASoC...


From denis at eukrea.com  Mon Jul 15 10:56:54 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:54 +0200
Subject: [PATCH 09/22] arm/dts: imx25.dtsi: Add an alias for the Audio
 Multiplexer.
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-10-git-send-email-denis@eukrea.com>

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 arch/arm/boot/dts/imx25.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index f7f024f..b0b2fea 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -235,7 +235,7 @@
 				};
 			};
 
-			audmux at 43fb0000 {
+			audmux: audmux at 43fb0000 {
 				compatible = "fsl,imx25-audmux", "fsl,imx31-audmux";
 				reg = <0x43fb0000 0x4000>;
 				status = "disabled";
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:56:50 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:50 +0200
Subject: [PATCH 05/22] ARM: i.MX25 DT: use auxdata to attach
 imxfb_platform_data
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-6-git-send-email-denis@eukrea.com>

This commit is based on the following commit:
  ab2815c3997b179f043a747264d155ab0bc181ad ARM: mxs: use auxdata to attach mxsfb_platform_data

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 arch/arm/mach-imx/Kconfig    |    1 +
 arch/arm/mach-imx/imx25-dt.c |   75 +++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 8f7109e..ed09a63 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -255,6 +255,7 @@ endchoice
 config MACH_IMX25_DT
 	bool "Support i.MX25 platforms from device tree"
 	select SOC_IMX25
+	select IMX_HAVE_PLATFORM_IMX_FB
 	help
 	  Include support for Freescale i.MX25 based platforms
 	  using the device tree for discovery
diff --git a/arch/arm/mach-imx/imx25-dt.c b/arch/arm/mach-imx/imx25-dt.c
index 3e1ec5f..dbfac49 100644
--- a/arch/arm/mach-imx/imx25-dt.c
+++ b/arch/arm/mach-imx/imx25-dt.c
@@ -12,16 +12,89 @@
 #include <linux/irq.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
+#include <linux/platform_data/video-imxfb.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
 #include "common.h"
 #include "mx25.h"
 
+static struct imx_fb_videomode eukrea_mximxsd_modes[] = {
+	 {
+		.mode   = {
+			.name		= "CMO-QVGA",
+			.refresh	= 60,
+			.xres		= 320,
+			.yres		= 240,
+			.pixclock	= KHZ2PICOS(6500),
+			.left_margin	= 30,
+			.right_margin	= 38,
+			.upper_margin	= 20,
+			.lower_margin	= 3,
+			.hsync_len	= 15,
+			.vsync_len	= 4,
+		},
+		.bpp	= 16,
+		.pcr	= 0xCAD08B80,
+	 }, {
+		.mode = {
+			.name		= "DVI-VGA",
+			.refresh	= 60,
+			.xres		= 640,
+			.yres		= 480,
+			.pixclock	= 32000,
+			.hsync_len	= 7,
+			.left_margin	= 100,
+			.right_margin	= 100,
+			.vsync_len	= 7,
+			.upper_margin	= 7,
+			.lower_margin	= 100,
+		},
+		.pcr	= 0xFA208B80,
+		.bpp	= 16,
+	 }, {
+		.mode = {
+			.name		= "DVI-SVGA",
+			.refresh	= 60,
+			.xres		= 800,
+			.yres		= 600,
+			.pixclock	= 25000,
+			.hsync_len	= 7,
+			.left_margin	= 75,
+			.right_margin	= 75,
+			.vsync_len	= 7,
+			.upper_margin	= 7,
+			.lower_margin	= 75,
+		},
+		.pcr	= 0xFA208B80,
+		.bpp	= 16,
+	 },
+};
+
+static struct imx_fb_platform_data imxfb_pdata __initdata;
+
+static struct of_dev_auxdata imx_auxdata_lookup[] __initdata = {
+	OF_DEV_AUXDATA("fsl,imx21-lcdif", 0x53fbc000, "imx21-fb", &imxfb_pdata),
+	{ /* sentinel */ }
+};
+
+static void __init eukrea_mximxsd_init(void)
+{
+	imxfb_pdata.mode = eukrea_mximxsd_modes;
+	imxfb_pdata.num_modes = ARRAY_SIZE(eukrea_mximxsd_modes);
+	imxfb_pdata.pwmr	= 0x00A903FF;
+	imxfb_pdata.lscr1	= 0x00120300;
+	imxfb_pdata.dmacr	= 0x00040060;
+}
+
 static void __init imx25_dt_init(void)
 {
 	mxc_arch_reset_init_dt();
 
-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+	if (of_machine_is_compatible("fsl,eukrea_cpuimx25"))
+		eukrea_mximxsd_init();
+
+	of_platform_populate(NULL, of_default_bus_match_table,
+				imx_auxdata_lookup, NULL);
 }
 
 static const char * const imx25_dt_board_compat[] __initconst = {
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:56:45 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:45 +0200
Subject: Devicetree support for Eukrea cpuimx{25,35,51} 
Message-ID: <1373900227-341-1-git-send-email-denis@eukrea.com>

Here are some patches which adds support for the Eukrea cpuimx{25,35,51}
  CPU modules, and their respective baseboard, in the devicetree, 
  and the patches on which that support depends on.

Denis.



From denis at eukrea.com  Mon Jul 15 10:56:52 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:52 +0200
Subject: [PATCH 07/22] arm/dts: i.MX25: Add sdma script path.
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-8-git-send-email-denis@eukrea.com>

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 arch/arm/boot/dts/imx25.dtsi |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index fb37111..f7f024f 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -506,6 +506,7 @@
 				clock-names = "ipg", "ahb";
 				#dma-cells = <3>;
 				interrupts = <34>;
+				fsl,sdma-ram-script-name = "imx/sdma/sdma-imx25-to1.bin";
 			};
 
 			wdog at 53fdc000 {
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:56:46 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:46 +0200
Subject: [PATCH 01/22] ARM i.MX25: devicetree: add compatible property for
 imxfb support.
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-2-git-send-email-denis@eukrea.com>

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 arch/arm/boot/dts/imx25.dtsi |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index bcd3171..6a1633d 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -394,6 +394,7 @@
 			};
 
 			lcdc at 53fbc000 {
+				compatible = "fsl,imx21-lcdif";
 				reg = <0x53fbc000 0x4000>;
 				interrupts = <39>;
 				clocks = <&clks 103>, <&clks 66>, <&clks 49>;
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:57:00 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:57:00 +0200
Subject: [PATCH 15/22] drm: Add the lacking DRM_MODE_FLAG_* for matching the
 DISPLAY_FLAGS_*
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-16-git-send-email-denis@eukrea.com>

Without that fix, drivers using the drm_display_mode_from_videomode
  function will not be able to get certain information because
  some DISPLAY_FLAGS_* have no corresponding DRM_MODE_FLAG_*.

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 drivers/gpu/drm/drm_modes.c |    9 +++++++++
 include/uapi/drm/drm_mode.h |   32 ++++++++++++++++++--------------
 2 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a6729bf..443bb94 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(const struct videomode *vm,
 		dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
 	if (vm->flags & DISPLAY_FLAGS_DOUBLECLK)
 		dmode->flags |= DRM_MODE_FLAG_DBLCLK;
+	if (vm->flags & DISPLAY_FLAGS_DE_LOW)
+		dmode->flags |= DRM_MODE_FLAG_NDATEN;
+	if (vm->flags & DISPLAY_FLAGS_DE_HIGH)
+		dmode->flags |= DRM_MODE_FLAG_PDATEN;
+	if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE)
+		dmode->flags |= DRM_MODE_FLAG_PPIXDATEDGE;
+	if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+		dmode->flags |= DRM_MODE_FLAG_NPIXDATEDGE;
+
 	drm_mode_set_name(dmode);
 
 	return 0;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 53db7ce..5ec85f9 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -44,20 +44,24 @@
 
 /* Video mode flags */
 /* bit compatible with the xorg definitions. */
-#define DRM_MODE_FLAG_PHSYNC	(1<<0)
-#define DRM_MODE_FLAG_NHSYNC	(1<<1)
-#define DRM_MODE_FLAG_PVSYNC	(1<<2)
-#define DRM_MODE_FLAG_NVSYNC	(1<<3)
-#define DRM_MODE_FLAG_INTERLACE	(1<<4)
-#define DRM_MODE_FLAG_DBLSCAN	(1<<5)
-#define DRM_MODE_FLAG_CSYNC	(1<<6)
-#define DRM_MODE_FLAG_PCSYNC	(1<<7)
-#define DRM_MODE_FLAG_NCSYNC	(1<<8)
-#define DRM_MODE_FLAG_HSKEW	(1<<9) /* hskew provided */
-#define DRM_MODE_FLAG_BCAST	(1<<10)
-#define DRM_MODE_FLAG_PIXMUX	(1<<11)
-#define DRM_MODE_FLAG_DBLCLK	(1<<12)
-#define DRM_MODE_FLAG_CLKDIV2	(1<<13)
+#define DRM_MODE_FLAG_PHSYNC		(1<<0)
+#define DRM_MODE_FLAG_NHSYNC		(1<<1)
+#define DRM_MODE_FLAG_PVSYNC		(1<<2)
+#define DRM_MODE_FLAG_NVSYNC		(1<<3)
+#define DRM_MODE_FLAG_INTERLACE		(1<<4)
+#define DRM_MODE_FLAG_DBLSCAN		(1<<5)
+#define DRM_MODE_FLAG_CSYNC		(1<<6)
+#define DRM_MODE_FLAG_PCSYNC		(1<<7)
+#define DRM_MODE_FLAG_NCSYNC		(1<<8)
+#define DRM_MODE_FLAG_HSKEW		(1<<9) /* hskew provided */
+#define DRM_MODE_FLAG_BCAST		(1<<10)
+#define DRM_MODE_FLAG_PIXMUX		(1<<11)
+#define DRM_MODE_FLAG_DBLCLK		(1<<12)
+#define DRM_MODE_FLAG_CLKDIV2		(1<<13)
+#define DRM_MODE_FLAG_PDATEN		(1<<14)
+#define DRM_MODE_FLAG_NDATEN		(1<<15)
+#define DRM_MODE_FLAG_PPIXDATEDGE	(1<<16)
+#define DRM_MODE_FLAG_NPIXDATEDGE	(1<<17)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:56:55 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:55 +0200
Subject: =?UTF-8?q?=5BPATCH=2010/22=5D=20arm/dts=3A=20Add=20support=20for=20the=20cpuimx25=20board=20from=20Eukrea=20and=20its=20baseboard=2E?=
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-11-git-send-email-denis@eukrea.com>

Only the following devices/functionalities were added:
 * Main UART
 * Memory node
 * NAND
 * i2c and its pcf8563
 * Ethernet
 * LCD controller
 * Sound
 * ESDHC

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 Documentation/devicetree/bindings/arm/fsl.txt     |    4 ++
 arch/arm/boot/dts/eukrea_cpuimx25.dts             |   48 +++++++++++++++++
 arch/arm/boot/dts/eukrea_mbimxsd25-baseboard.dtsi |   59 +++++++++++++++++++++
 3 files changed, 111 insertions(+)
 create mode 100644 arch/arm/boot/dts/eukrea_cpuimx25.dts
 create mode 100644 arch/arm/boot/dts/eukrea_mbimxsd25-baseboard.dtsi

diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index e935d7d..2c19348 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -9,6 +9,10 @@ i.MX25 Product Development Kit
 Required root node properties:
     - compatible = "fsl,imx25-pdk", "fsl,imx25";
 
+i.MX25 Eukrea CPUIMX25 Board.
+Required root node properties:
+    - compatible = "fsl,eukrea_cpuimx25", "fsl,imx25";
+
 i.MX27 Product Development Kit
 Required root node properties:
     - compatible = "fsl,imx27-pdk", "fsl,imx27";
diff --git a/arch/arm/boot/dts/eukrea_cpuimx25.dts b/arch/arm/boot/dts/eukrea_cpuimx25.dts
new file mode 100644
index 0000000..a65243c
--- /dev/null
+++ b/arch/arm/boot/dts/eukrea_cpuimx25.dts
@@ -0,0 +1,48 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique <denis at eukrea.com>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include "imx25.dtsi"
+#include "eukrea_mbimxsd25-baseboard.dtsi"
+
+/ {
+	model = "Eukrea CPUIMX25";
+	compatible = "fsl,eukrea_cpuimx25", "fsl,imx25";
+
+	memory {
+		reg = <0x80000000 0x4000000>; /* 64M */
+	};
+};
+
+&fec {
+	phy-mode = "rmii";
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec_1>;
+};
+
+&nfc {
+	nand-bus-width = <8>;
+	nand-ecc-mode = "hw";
+	nand-on-flash-bbt;
+	status = "okay";
+};
+
+&i2c1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1_1>;
+
+	pcf8563 at 51 {
+		compatible = "nxp,pcf8563";
+		reg = <0x51>;
+	};
+};
diff --git a/arch/arm/boot/dts/eukrea_mbimxsd25-baseboard.dtsi b/arch/arm/boot/dts/eukrea_mbimxsd25-baseboard.dtsi
new file mode 100644
index 0000000..ffaf657
--- /dev/null
+++ b/arch/arm/boot/dts/eukrea_mbimxsd25-baseboard.dtsi
@@ -0,0 +1,59 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique <denis at eukrea.com>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "skeleton.dtsi"
+
+/ {
+	sound {
+		compatible = "fsl,eukrea-tlv320";
+		model = "imx25-eukrea-tlv320aic23";
+		ssi-controller = <&ssi1>;
+		fsl,audio-codec = <&tlv320aic23>;
+		mux-int-port = <1>;
+		mux-ext-port = <5>;
+	};
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1_1>;
+	fsl,uart-has-rtscts;
+	status = "okay";
+};
+
+&lcdc {
+	status = "okay";
+};
+
+&audmux {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_audmux_1>;
+};
+
+&ssi1 {
+	fsl,mode = "i2s-slave";
+	status = "okay";
+};
+
+&i2c1 {
+	tlv320aic23: codec at 1a {
+		compatible = "ti,tlv320aic23";
+		reg = <0x1a>;
+	};
+};
+
+&esdhc1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_esdhc1_1>;
+	cd-gpios = <&gpio1 20>;
+};
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:56:58 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:58 +0200
Subject: =?UTF-8?q?=5BPATCH=2013/22=5D=20lcd=3A=20Add=20GPIO=20LCD=20driver=2E?=
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-14-git-send-email-denis@eukrea.com>

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 .../bindings/video/backlight/gpio-lcd.txt          |   15 ++
 drivers/video/backlight/Kconfig                    |    8 +
 drivers/video/backlight/Makefile                   |    1 +
 drivers/video/backlight/gpio_lcd.c                 |  178 ++++++++++++++++++++
 4 files changed, 202 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/backlight/gpio-lcd.txt
 create mode 100644 drivers/video/backlight/gpio_lcd.c

diff --git a/Documentation/devicetree/bindings/video/backlight/gpio-lcd.txt b/Documentation/devicetree/bindings/video/backlight/gpio-lcd.txt
new file mode 100644
index 0000000..4ff409d
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/gpio-lcd.txt
@@ -0,0 +1,15 @@
+gpio-lcd bindings
+
+Required properties:
+  - compatible: "gpio-lcd"
+  - gpios: describes the gpio that is used for enabling/disabling the lcd
+     (see GPIO binding[0] for more details).
+
+[0]: Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+
+	lcd {
+		compatible = "gpio-lcd";
+		gpios = <&gpio3 13 0>;
+	};
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 70e7706..eaf0525 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -34,6 +34,14 @@ config LCD_CORGI
 	  Say y here to support the LCD panels usually found on SHARP
 	  corgi (C7x0) and spitz (Cxx00) models.
 
+config LCD_GPIO
+	tristate "LCD GPIO Driver"
+	depends on OF && GPIOLIB
+	help
+	  If your LCD enbling/disabling is controlled by a GPIO
+	  and that you use the device tree for booting,
+	  say y to enable the LCD GPIO driver.
+
 config LCD_L4F00242T03
 	tristate "Epson L4F00242T03 LCD"
 	depends on SPI_MASTER && GPIOLIB
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 8cde337..5c25955 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -3,6 +3,7 @@
 obj-$(CONFIG_LCD_AMS369FG06)		+= ams369fg06.o
 obj-$(CONFIG_LCD_CLASS_DEVICE)		+= lcd.o
 obj-$(CONFIG_LCD_CORGI)			+= corgi_lcd.o
+obj-$(CONFIG_LCD_GPIO)			+= gpio_lcd.o
 obj-$(CONFIG_LCD_HP700)			+= jornada720_lcd.o
 obj-$(CONFIG_LCD_HX8357)		+= hx8357.o
 obj-$(CONFIG_LCD_ILI922X)		+= ili922x.o
diff --git a/drivers/video/backlight/gpio_lcd.c b/drivers/video/backlight/gpio_lcd.c
new file mode 100644
index 0000000..e1c9d4a
--- /dev/null
+++ b/drivers/video/backlight/gpio_lcd.c
@@ -0,0 +1,178 @@
+/*
+ * drivers/video/backlight/gpio_lcd.c
+ *
+ * simple GPIO based lcd control.
+ *
+ * Copyright 2013 Eukr?a Electromatique <denis at eukrea.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Based on drivers/video/backlight/platform_lcd.c
+ */
+
+#include <linux/lcd.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+
+struct gpio_lcd {
+	unsigned gpio;
+	u32 active_low; /* 1 if active_low, 0 otherwise */
+	struct lcd_device *lcd;
+	unsigned int power;
+	unsigned int suspended;
+};
+
+static int gpio_lcd_get_power(struct lcd_device *lcd)
+{
+	struct gpio_lcd *glcd = lcd_get_data(lcd);
+
+	return glcd->power;
+}
+
+static int gpio_lcd_set_power(struct lcd_device *lcd, int power)
+{
+	struct gpio_lcd *glcd = lcd_get_data(lcd);
+	int lcd_power = 1;
+	unsigned ret = 0;
+
+	if (power == FB_BLANK_POWERDOWN || glcd->suspended)
+		lcd_power = 0;
+
+	ret = gpio_direction_output(glcd->gpio,
+			    lcd_power ? !glcd->active_low : glcd->active_low);
+
+	glcd->power = power;
+
+	return ret;
+}
+
+static struct lcd_ops gpio_lcd_ops = {
+	.get_power	= gpio_lcd_get_power,
+	.set_power	= gpio_lcd_set_power,
+};
+
+static int gpio_lcd_probe(struct platform_device *pdev)
+{
+	struct gpio_lcd *glcd;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = pdev->dev.of_node;
+	enum of_gpio_flags gpio_flags;
+	int ret = 0;
+
+	dev_info(&pdev->dev, "Initializing.\n");
+
+	glcd = devm_kzalloc(&pdev->dev, sizeof(*glcd), GFP_KERNEL);
+	if (!glcd) {
+		dev_err(&pdev->dev, "No memory for gpio_lcd.\n");
+		return -ENOMEM;
+	};
+
+	glcd->gpio = of_get_gpio_flags(np, 0, &gpio_flags);
+	glcd->active_low = gpio_flags & OF_GPIO_ACTIVE_LOW;
+	if (glcd->gpio == -EPROBE_DEFER) {
+		ret = ERR_PTR(-EPROBE_DEFER);
+		goto err_free_pdata;
+	} else if (glcd->gpio < 0) {
+		ret = glcd->gpio;
+		dev_err(&pdev->dev, "Error: gpios is a required parameter.\n");
+		goto err_free_pdata;
+	}
+
+	/* Request the LCD gpio */
+	ret = gpio_request(glcd->gpio, "LCDRST");
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failled to request LCD reset"
+		" GPIO %u.\n", glcd->gpio);
+		goto err_free_pdata;
+	}
+
+	glcd->lcd = lcd_device_register(dev_name(dev), dev,
+					glcd, &gpio_lcd_ops);
+	if (IS_ERR(glcd->lcd)) {
+		dev_err(dev, "Cannot register lcd device.\n");
+		ret = PTR_ERR(glcd->lcd);
+		goto err_free_pdata;
+	}
+
+	platform_set_drvdata(pdev, glcd);
+	gpio_lcd_set_power(glcd->lcd, FB_BLANK_NORMAL);
+
+	dev_info(&pdev->dev, "The LCD was Enabled by the GPIO %u which is %s.\n",
+			     glcd->gpio,
+			     glcd->active_low ? "active low" : "active high");
+
+	dev_info(&pdev->dev, "Initialized.\n");
+
+	return 0;
+
+err_free_pdata:
+	devm_kfree(&pdev->dev, glcd);
+	return ret;
+}
+
+static int gpio_lcd_remove(struct platform_device *pdev)
+{
+	struct gpio_lcd *glcd = platform_get_drvdata(pdev);
+
+	lcd_device_unregister(glcd->lcd);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int gpio_lcd_suspend(struct device *dev)
+{
+	struct gpio_lcd *glcd = dev_get_drvdata(dev);
+
+	glcd->suspended = 1;
+	return gpio_lcd_set_power(glcd->lcd, glcd->power);
+}
+
+static int gpio_lcd_resume(struct device *dev)
+{
+	struct gpio_lcd *glcd = dev_get_drvdata(dev);
+
+	glcd->suspended = 0;
+	return gpio_lcd_set_power(glcd->lcd, glcd->power);
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(gpio_lcd_pm_ops, gpio_lcd_suspend,
+			gpio_lcd_resume);
+
+static struct of_device_id gpio_lcd_of_match[] = {
+	{ .compatible = "gpio-lcd" },
+	{ /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, gpio_lcd_of_match);
+
+static struct platform_driver gpio_lcd_driver = {
+	.driver		= {
+		.name           = "gpio-lcd",
+		.owner          = THIS_MODULE,
+		.pm		= &gpio_lcd_pm_ops,
+		.of_match_table = of_match_ptr(gpio_lcd_of_match),
+	},
+	.probe          = gpio_lcd_probe,
+	.remove         = gpio_lcd_remove,
+};
+
+module_platform_driver(gpio_lcd_driver);
+
+MODULE_DESCRIPTION("GPIO based LCD Driver");
+MODULE_LICENSE("GPLv2");
+MODULE_ALIAS("platform:gpio-lcd");
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:56:56 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:56 +0200
Subject: [PATCH 11/22] arm/dts: imx51.dtsi: i2c1 : Add pinctrl configuration.
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-12-git-send-email-denis@eukrea.com>

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 arch/arm/boot/dts/imx51.dtsi |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index fb5c2c3..60b2a8e 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -410,6 +410,15 @@
 					};
 				};
 
+				i2c1 {
+					pinctrl_i2c1_1: i2c1grp-1 {
+						fsl,pins = <
+							MX51_PAD_SD2_CMD__I2C1_SCL 0x400001ed
+							MX51_PAD_SD2_CLK__I2C1_SDA 0x400001ed
+						>;
+					};
+				};
+
 				i2c2 {
 					pinctrl_i2c2_1: i2c2grp-1 {
 						fsl,pins = <
-- 
1.7.9.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:30 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:30 -0300
Subject: [RESEND PATCH v7 01/22] memory: mvebu-devbus: Remove address decoding
 window workaround
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-2-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus device tree binding has been introduced, remove the address
decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in
the device tree, as described by the mbus binding documentation.

Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/memory/mvebu-devbus.c | 64 ++-----------------------------------------
 1 file changed, 2 insertions(+), 62 deletions(-)

diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
index 978e8e3..94c9248 100644
--- a/drivers/memory/mvebu-devbus.c
+++ b/drivers/memory/mvebu-devbus.c
@@ -208,16 +208,11 @@ static int mvebu_devbus_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct device_node *node = pdev->dev.of_node;
-	struct device_node *parent;
 	struct devbus *devbus;
 	struct resource *res;
 	struct clk *clk;
 	unsigned long rate;
-	const __be32 *ranges;
-	int err, cs;
-	int addr_cells, p_addr_cells, size_cells;
-	int ranges_len, tuple_len;
-	u32 base, size;
+	int err;
 
 	devbus = devm_kzalloc(&pdev->dev, sizeof(struct devbus), GFP_KERNEL);
 	if (!devbus)
@@ -248,68 +243,13 @@ static int mvebu_devbus_probe(struct platform_device *pdev)
 		return err;
 
 	/*
-	 * Allocate an address window for this device.
-	 * If the device probing fails, then we won't be able to
-	 * remove the allocated address decoding window.
-	 *
-	 * FIXME: This is only a temporary hack! We need to do this here
-	 * because we still don't have device tree bindings for mbus.
-	 * Once that support is added, we will declare these address windows
-	 * statically in the device tree, and remove the window configuration
-	 * from here.
-	 */
-
-	/*
-	 * Get the CS to choose the window string.
-	 * This is a bit hacky, but it will be removed once the
-	 * address windows are declared in the device tree.
-	 */
-	cs = (((unsigned long)devbus->base) % 0x400) / 8;
-
-	/*
-	 * Parse 'ranges' property to obtain a (base,size) window tuple.
-	 * This will be removed once the address windows
-	 * are declared in the device tree.
-	 */
-	parent = of_get_parent(node);
-	if (!parent)
-		return -EINVAL;
-
-	p_addr_cells = of_n_addr_cells(parent);
-	of_node_put(parent);
-
-	addr_cells = of_n_addr_cells(node);
-	size_cells = of_n_size_cells(node);
-	tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
-
-	ranges = of_get_property(node, "ranges", &ranges_len);
-	if (ranges == NULL || ranges_len != tuple_len)
-		return -EINVAL;
-
-	base = of_translate_address(node, ranges + addr_cells);
-	if (base == OF_BAD_ADDR)
-		return -EINVAL;
-	size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
-
-	/*
-	 * Create an mbus address windows.
-	 * FIXME: Remove this, together with the above code, once the
-	 * address windows are declared in the device tree.
-	 */
-	err = mvebu_mbus_add_window(devbus_wins[cs], base, size);
-	if (err < 0)
-		return err;
-
-	/*
 	 * We need to create a child device explicitly from here to
 	 * guarantee that the child will be probed after the timing
 	 * parameters for the bus are written.
 	 */
 	err = of_platform_populate(node, NULL, NULL, dev);
-	if (err < 0) {
-		mvebu_mbus_del_window(base, size);
+	if (err < 0)
 		return err;
-	}
 
 	return 0;
 }
-- 
1.8.1.5



From denis at eukrea.com  Mon Jul 15 10:57:05 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:57:05 +0200
Subject: =?UTF-8?q?=5BPATCH=2020/22=5D=20arm/dts=3A=20Add=20support=20for=20the=20cpuimx51=20board=20from=20Eukrea=20and=20its=20baseboard=2E?=
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-21-git-send-email-denis@eukrea.com>

Only the following devices/functionalities were added:
 * Main UART and the memory node information.
 * NAND.
 * Ethernet.
 * i2c and its pcf8563 device.
 * The GPIO button (its label is BP1 on the baseboard).
 * The GPIO backlight.
 * The GPIO LCD enabling/disabling.
 * Display/IPU controller.
 * Touchscreen.

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 Documentation/devicetree/bindings/arm/fsl.txt     |    4 +
 arch/arm/boot/dts/eukrea_cpuimx51.dts             |   69 ++++++++++++++
 arch/arm/boot/dts/eukrea_mbimxsd51-baseboard.dtsi |  105 +++++++++++++++++++++
 3 files changed, 178 insertions(+)
 create mode 100644 arch/arm/boot/dts/eukrea_cpuimx51.dts
 create mode 100644 arch/arm/boot/dts/eukrea_mbimxsd51-baseboard.dtsi

diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index 2c19348..4001d91 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -25,6 +25,10 @@ i.MX51 Babbage Board
 Required root node properties:
     - compatible = "fsl,imx51-babbage", "fsl,imx51";
 
+i.MX51 Eukrea CPUIMX51 Board
+Required root node properties:
+    - compatible = "fsl,eukrea_cpuimx51", "fsl,imx51";
+
 i.MX53 Automotive Reference Design Board
 Required root node properties:
     - compatible = "fsl,imx53-ard", "fsl,imx53";
diff --git a/arch/arm/boot/dts/eukrea_cpuimx51.dts b/arch/arm/boot/dts/eukrea_cpuimx51.dts
new file mode 100644
index 0000000..4e944cd
--- /dev/null
+++ b/arch/arm/boot/dts/eukrea_cpuimx51.dts
@@ -0,0 +1,69 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique <denis at eukrea.com>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include "imx51.dtsi"
+#include "eukrea_mbimxsd51-baseboard.dtsi"
+
+/ {
+	model = "Eukrea CPUIMX51";
+	compatible = "fsl,eukrea_cpuimx51", "fsl,imx51";
+
+	memory {
+		reg = <0x90000000 0x10000000>; /* 256M */
+	};
+};
+
+&iomuxc {
+	tsc2007 {
+		pinctrl_tsc2007_1: tsc2007grp-1 {
+			fsl,pins = <
+				MX51_PAD_GPIO_NAND__GPIO_NAND 0x1f5
+				MX51_PAD_NANDF_D8__GPIO4_0 0x1f5
+			>;
+		};
+	};
+};
+
+&nfc {
+	nand-bus-width = <8>;
+	nand-ecc-mode = "hw";
+	nand-on-flash-bbt;
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1_1>;
+	status = "okay";
+
+	tsc2007 at 49 {
+		compatible = "ti,tsc2007";
+		reg = <0x49>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_tsc2007_1>;
+		interrupt-parent = <&gpio4>;
+		interrupts = <0x0 0x8>;
+		gpios = <&gpio4 0 0>;
+		x-plate-ohms = <180>;
+	};
+
+	pcf8563 at 51 {
+		compatible = "nxp,pcf8563";
+		reg = <0x51>;
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec_2>;
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/eukrea_mbimxsd51-baseboard.dtsi b/arch/arm/boot/dts/eukrea_mbimxsd51-baseboard.dtsi
new file mode 100644
index 0000000..6d74659
--- /dev/null
+++ b/arch/arm/boot/dts/eukrea_mbimxsd51-baseboard.dtsi
@@ -0,0 +1,105 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique <denis at eukrea.com>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "skeleton.dtsi"
+
+/ {
+	soc {
+		display at di0 {
+			compatible = "fsl,imx-parallel-display";
+			crtcs = <&ipu 0>;
+			interface-pix-fmt = "rgb666";
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_ipu_disp1_1>;
+
+			display-timings {
+			native-mode = <&cmoqvga>;
+				cmoqvga: 320x240 {
+					clock-frequency = <6500000>;
+					hactive = <320>;
+					vactive = <240>;
+					hfront-porch = <20>;
+					hback-porch = <38>;
+					vfront-porch = <4>;
+					vback-porch = <15>;
+					hsync-len = <30>;
+					vsync-len = <3>;
+					hsync-active = <0>;
+					vsync-active = <0>;
+					de-active = <0>;
+					pixelclk-active = <1>;
+				};
+			};
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_gpiokeys_1>;
+
+		button-1 {
+			label = "BP1";
+			gpios = <&gpio3 31 1>;
+			linux,code = <256>;
+			gpio-key,wakeup;
+			linux,input-type = <1>;
+		};
+	};
+
+	backlight {
+		compatible = "gpio-backlight";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_backlight_1>;
+		gpios = <&gpio3 4 0>;
+		default-brightness-level = <1>;
+	};
+
+	lcd {
+		compatible = "gpio-lcd";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_lcd_1>;
+		gpios = <&gpio3 13 0>;
+	};
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1_1>;
+	fsl,uart-has-rtscts;
+	status = "okay";
+};
+
+&iomuxc {
+	gpio-keys {
+		pinctrl_gpiokeys_1: gpiokeysgrp-1 {
+			fsl,pins = <
+				MX51_PAD_NANDF_D9__GPIO3_31 0x1f5
+			>;
+		};
+	};
+
+	backlight {
+		pinctrl_backlight_1: backlightgrp-1 {
+			fsl,pins = <
+				MX51_PAD_DI1_D1_CS__GPIO3_4 0x1f5
+			>;
+		};
+	};
+
+	lcd {
+		pinctrl_lcd_1: lcdgrp-1 {
+			fsl,pins = <
+				MX51_PAD_CSI1_D9__GPIO3_13 0x1f5
+			>;
+		};
+	};
+};
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:56:57 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:57 +0200
Subject: =?UTF-8?q?=5BPATCH=2012/22=5D=20video=3A=20backlight=3A=20Add=20GPIO=20Backlight=20driver=2E?=
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-13-git-send-email-denis@eukrea.com>

This initial driver uses and depends on DT bindings.

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 .../bindings/video/backlight/gpio-backlight.txt    |   18 ++
 drivers/video/backlight/Kconfig                    |    7 +
 drivers/video/backlight/Makefile                   |    1 +
 drivers/video/backlight/gpio_bl.c                  |  226 ++++++++++++++++++++
 4 files changed, 252 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt
 create mode 100644 drivers/video/backlight/gpio_bl.c

diff --git a/Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt b/Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt
new file mode 100644
index 0000000..362dd40
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt
@@ -0,0 +1,18 @@
+gpio-backlight bindings
+
+Required properties:
+  - compatible: "gpio-backlight"
+  - gpios: describes the gpio that is used for enabling/disabling the backlight
+     (see GPIO binding[0] for more details).
+  - default-brightness-level: the default brightness level (can be 0(off) or
+      1(on) since GPIOs only support theses levels).
+
+[0]: Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+
+	backlight {
+		compatible = "gpio-backlight";
+		gpios = <&gpio3 4 0>;
+		default-brightness-level = <1>;
+	};
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index d5ab658..70e7706 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -207,6 +207,13 @@ config BACKLIGHT_GENERIC
 	  known as the Corgi backlight driver. If you have a Sharp Zaurus
 	  SL-C7xx, SL-Cxx00 or SL-6000x say y.
 
+config BACKLIGHT_GPIO
+	tristate "GPIO Backlight Driver"
+	depends on OF && GPIOLIB
+	help
+	  If you have a GPIO backlight and that you use the device tree
+	  for booting, say y to enable the GPIO backlight driver.
+
 config BACKLIGHT_LM3533
 	tristate "Backlight Driver for LM3533"
 	depends on BACKLIGHT_CLASS_DEVICE
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 92711fe..8cde337 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_BACKLIGHT_DA903X)		+= da903x_bl.o
 obj-$(CONFIG_BACKLIGHT_DA9052)		+= da9052_bl.o
 obj-$(CONFIG_BACKLIGHT_EP93XX)		+= ep93xx_bl.o
 obj-$(CONFIG_BACKLIGHT_GENERIC)		+= generic_bl.o
+obj-$(CONFIG_BACKLIGHT_GPIO)		+= gpio_bl.o
 obj-$(CONFIG_BACKLIGHT_HP680)		+= hp680_bl.o
 obj-$(CONFIG_BACKLIGHT_HP700)		+= jornada720_bl.o
 obj-$(CONFIG_BACKLIGHT_LM3533)		+= lm3533_bl.o
diff --git a/drivers/video/backlight/gpio_bl.c b/drivers/video/backlight/gpio_bl.c
new file mode 100644
index 0000000..76b9c99
--- /dev/null
+++ b/drivers/video/backlight/gpio_bl.c
@@ -0,0 +1,226 @@
+/*
+ * drivers/video/backlight/gpio_bl.c
+ *
+ * simple GPIO based backlight control.
+ *
+ * Copyright 2013 Eukr?a Electromatique <denis at eukrea.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Based on drivers/video/backlight/pwm_bl.c
+ */
+
+#include <linux/backlight.h>
+#include <linux/fb.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+
+struct gpio_bl_data {
+	unsigned gpio;
+	u32 dft_brightness;
+	u32 active_low; /* 1 if active_low, 0 otherwise */
+};
+
+static int gpio_backlight_update_status(struct backlight_device *bl)
+{
+	struct gpio_bl_data *gb = bl_get_data(bl);
+	int brightness = bl->props.brightness;
+
+	if (bl->props.power != FB_BLANK_UNBLANK ||
+	    bl->props.fb_blank != FB_BLANK_UNBLANK ||
+	    bl->props.state & BL_CORE_FBBLANK)
+		brightness = 0;
+
+	return gpio_direction_output(gb->gpio,
+				     brightness ?
+				     !gb->active_low : gb->active_low);
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int gpio_backlight_suspend(struct device *dev)
+{
+	struct backlight_device *bl = dev_get_drvdata(dev);
+	struct gpio_bl_data *gb = bl_get_data(bl);
+
+	/* Power down the backlight */
+	return gpio_direction_output(gb->gpio, gb->active_low);
+}
+
+static int gpio_backlight_resume(struct device *dev)
+{
+	struct backlight_device *bl = dev_get_drvdata(dev);
+
+	backlight_update_status(bl);
+
+	return 0;
+}
+#endif
+
+static int gpio_backlight_get_brightness(struct backlight_device *bl)
+{
+	return bl->props.brightness;
+}
+
+static const struct backlight_ops gpio_backlight_ops = {
+	.update_status = gpio_backlight_update_status,
+	.get_brightness = gpio_backlight_get_brightness,
+};
+
+static int gpio_backlight_remove(struct platform_device *pdev)
+{
+	struct backlight_device *bl = platform_get_drvdata(pdev);
+	struct gpio_bl_data *gb = bl_get_data(bl);
+	int ret;
+
+	backlight_device_unregister(bl);
+
+	/* Power down the backlight */
+	ret = gpio_direction_output(gb->gpio, gb->active_low);
+	if (ret < 0)
+		dev_err(&pdev->dev, "Failled to set GPIO %u to output direction\n",
+				    gb->gpio);
+
+	return 0;
+}
+
+static int gpio_backlight_probe(struct platform_device *pdev)
+{
+	struct backlight_properties props;
+	struct backlight_device *bl;
+	struct gpio_bl_data *gb;
+	struct device_node *np = pdev->dev.of_node;
+	enum of_gpio_flags gpio_flags;
+	int ret = 0;
+
+	dev_info(&pdev->dev, "Initializing.\n");
+
+	gb = devm_kzalloc(&pdev->dev, sizeof(*gb), GFP_KERNEL);
+	if (!gb) {
+		dev_err(&pdev->dev, "No memory for gpio_bl_data.\n");
+		return -ENOMEM;
+	}
+
+	ret = of_property_read_u32(np, "default-brightness-level",
+				   &gb->dft_brightness);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Error: default-brightness-level is a required parameter.\n");
+		goto err_free_pdata;
+	}
+
+	if (gb->dft_brightness < 0 || gb->dft_brightness > 1) {
+		dev_err(&pdev->dev, "Error: Invalid default-brightness-level value."
+		" Its value can be either 0(off) or 1(on).\n");
+		goto err_free_pdata;
+	}
+
+	ret = of_property_read_u32(np, "active-level", &gb->active_low);
+	/* By default, the GPIO activating the backlight is active high. */
+	if (ret < 0)
+		gb->active_low = 0;
+	else
+		if (gb->active_low < 0 || gb->active_low > 1) {
+			dev_err(&pdev->dev, "Error: Invalid active-level value."
+			" Its value can be either 0(active low)"
+			"or 1(active high).\n");
+		}
+
+	gb->gpio = of_get_gpio_flags(np, 0, &gpio_flags);
+	gb->active_low = gpio_flags & OF_GPIO_ACTIVE_LOW;
+	if (gb->gpio == -EPROBE_DEFER) {
+		ret = ERR_PTR(-EPROBE_DEFER);
+		goto err_free_pdata;
+	} else if (gb->gpio < 0) {
+		ret = gb->gpio;
+		dev_err(&pdev->dev, "Error: gpios is a required parameter.\n");
+		goto err_free_pdata;
+	}
+
+	/* Request the backlight gpio */
+	ret = gpio_request(gb->gpio, "LCDBL");
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failled to request LCD Backlight"
+		" GPIO %u.\n", gb->gpio);
+		goto err_free_pdata;
+	}
+	/* If the default brightness is 1, enable the backlight,
+	 * else power it down */
+	ret = gpio_direction_output(gb->gpio,
+				    gb->dft_brightness ?
+				    !gb->active_low : gb->active_low);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "The LCD GPIO %u failed to "
+				    "%s the backlight.\n",
+				    gb->gpio,
+				    gb->dft_brightness ? "enable" : "disable");
+		goto err_free_pdata;
+	}
+
+	dev_info(&pdev->dev, "The backlight was %s by the GPIO %u "
+			     "which is %s.\n",
+			     gb->dft_brightness ? "Enabled" : "Disabled",
+			     gb->gpio,
+			     gb->active_low ? "active low" : "active high");
+
+	memset(&props, 0, sizeof(struct backlight_properties));
+	props.type = BACKLIGHT_RAW;
+	props.max_brightness = 1; /* A GPIO can only be at level 0 or 1 */
+
+	bl = backlight_device_register(dev_name(&pdev->dev), &pdev->dev, gb,
+				       &gpio_backlight_ops, &props);
+	if (IS_ERR(bl)) {
+		dev_err(&pdev->dev, "Failed to register backlight\n");
+		ret = PTR_ERR(bl);
+		goto err_free_pdata;
+	}
+
+	bl->props.brightness = 1;
+	backlight_update_status(bl);
+	platform_set_drvdata(pdev, bl);
+
+	dev_info(&pdev->dev, "Initialized.\n");
+
+	return 0;
+
+err_free_pdata:
+	devm_kfree(&pdev->dev, bl);
+	return ret;
+}
+
+MODULE_DEVICE_TABLE(of, gpio_backlight_of_match);
+static SIMPLE_DEV_PM_OPS(gpio_backlight_pm_ops, gpio_backlight_suspend,
+			gpio_backlight_resume);
+
+static struct of_device_id gpio_backlight_of_match[] = {
+	{ .compatible = "gpio-backlight" },
+	{ /* sentinel */ }
+};
+
+static struct platform_driver gpio_backlight_driver = {
+	.driver         = {
+		.name           = "gpio-backlight",
+		.owner          = THIS_MODULE,
+		.pm             = &gpio_backlight_pm_ops,
+		.of_match_table = of_match_ptr(gpio_backlight_of_match),
+	},
+	.probe          = gpio_backlight_probe,
+	.remove         = gpio_backlight_remove,
+};
+
+module_platform_driver(gpio_backlight_driver);
+
+MODULE_DESCRIPTION("GPIO based Backlight Driver");
+MODULE_LICENSE("GPLv2");
+MODULE_ALIAS("platform:gpio-backlight");
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:56:48 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:48 +0200
Subject: =?UTF-8?q?=5BPATCH=2003/22=5D=20pinctrl=3A=20pinctrl-imx=3A=20add=20imx25=20pinctrl=20driver?=
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-4-git-send-email-denis@eukrea.com>

This is mostly cut and paste from the imx35 pinctrl driver.
The data was generated using sed and awk on
  arch/arm/plat-mxc/include/mach/iomux-mx25.h.

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 .../bindings/pinctrl/fsl,imx25-pinctrl.txt         |   33 ++
 arch/arm/boot/dts/imx25-pinfunc.h                  |  513 ++++++++++++++++++++
 arch/arm/boot/dts/imx25.dtsi                       |    1 +
 arch/arm/mach-imx/Kconfig                          |    2 +
 drivers/pinctrl/Kconfig                            |    8 +
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/pinctrl-imx25.c                    |  351 ++++++++++++++
 7 files changed, 909 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx25-pinctrl.txt
 create mode 100644 arch/arm/boot/dts/imx25-pinfunc.h
 create mode 100644 drivers/pinctrl/pinctrl-imx25.c

diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx25-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx25-pinctrl.txt
new file mode 100644
index 0000000..0099f36
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx25-pinctrl.txt
@@ -0,0 +1,33 @@
+* Freescale IMX25 IOMUX Controller
+
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+
+Required properties:
+- compatible: "fsl,imx25-iomuxc"
+- fsl,pins: two integers array, represents a group of pins mux and config
+  setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
+  pin working on a specific function, CONFIG is the pad setting value like
+  pull-up for this pin. Please refer to imx25 datasheet for the valid pad
+  config settings.
+
+CONFIG bits definition:
+PAD_CTL_DRIVE_VOLAGAGE_18	(1 << 13)
+PAD_CTL_DRIVE_VOLAGAGE_33	(0 << 13)
+PAD_CTL_HYS			(1 << 8)
+PAD_CTL_PKE			(1 << 7)
+PAD_CTL_PUE			(1 << 6)
+PAD_CTL_PUS_100K_DOWN		(0 << 4)
+PAD_CTL_PUS_47K_UP		(1 << 4)
+PAD_CTL_PUS_100K_UP		(2 << 4)
+PAD_CTL_PUS_22K_UP		(3 << 4)
+PAD_CTL_ODE_CMOS		(0 << 3)
+PAD_CTL_ODE_OPENDRAIN		(1 << 3)
+PAD_CTL_DSE_NOMINAL		(0 << 1)
+PAD_CTL_DSE_HIGH		(1 << 1)
+PAD_CTL_DSE_MAX		(2 << 1)
+PAD_CTL_SRE_FAST		(1 << 0)
+PAD_CTL_SRE_SLOW		(0 << 0)
+
+Refer to imx25-pinfunc.h in device tree source folder for all available
+imx25 PIN_FUNC_ID.
diff --git a/arch/arm/boot/dts/imx25-pinfunc.h b/arch/arm/boot/dts/imx25-pinfunc.h
new file mode 100644
index 0000000..0a9f9a2
--- /dev/null
+++ b/arch/arm/boot/dts/imx25-pinfunc.h
@@ -0,0 +1,513 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique <denis at eukrea.com>
+ * Based on imx35-pinfunc.h in the same directory Which is:
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#ifndef __DTS_IMX25_PINFUNC_H
+#define __DTS_IMX25_PINFUNC_H
+
+/*
+ * The pin function ID is a tuple of
+ * <mux_reg conf_reg input_reg mux_mode input_val>
+ */
+
+#define MX25_PAD_A10__A10			0x008 0x000 0x000 0x00 0x000
+#define MX25_PAD_A10__GPIO_4_0			0x008 0x000 0x000 0x05 0x000
+
+#define MX25_PAD_A13__A13			0x00c 0x22C 0x000 0x00 0x000
+#define MX25_PAD_A13__GPIO_4_1			0x00c 0x22C 0x000 0x05 0x000
+
+#define MX25_PAD_A14__A14			0x010 0x230 0x000 0x10 0x000
+#define MX25_PAD_A14__GPIO_2_0			0x010 0x230 0x000 0x15 0x000
+
+#define MX25_PAD_A15__A15			0x014 0x234 0x000 0x10 0x000
+#define MX25_PAD_A15__GPIO_2_1			0x014 0x234 0x000 0x15 0x000
+
+#define MX25_PAD_A16__A16			0x018 0x000 0x000 0x10 0x000
+#define MX25_PAD_A16__GPIO_2_2			0x018 0x000 0x000 0x15 0x000
+
+#define MX25_PAD_A17__A17			0x01c 0x238 0x000 0x10 0x000
+#define MX25_PAD_A17__GPIO_2_3			0x01c 0x238 0x000 0x15 0x000
+
+#define MX25_PAD_A18__A18			0x020 0x23c 0x000 0x10 0x000
+#define MX25_PAD_A18__GPIO_2_4			0x020 0x23c 0x000 0x15 0x000
+#define MX25_PAD_A18__FEC_COL			0x020 0x23c 0x504 0x17 0x000
+
+#define MX25_PAD_A19__A19			0x024 0x240 0x000 0x10 0x000
+#define MX25_PAD_A19__FEC_RX_ER			0x024 0x240 0x518 0x17 0x000
+#define MX25_PAD_A19__GPIO_2_5			0x024 0x240 0x000 0x15 0x000
+
+#define MX25_PAD_A20__A20			0x028 0x244 0x000 0x10 0x000
+#define MX25_PAD_A20__GPIO_2_6			0x028 0x244 0x000 0x15 0x000
+#define MX25_PAD_A20__FEC_RDATA2		0x028 0x244 0x50c 0x17 0x000
+
+#define MX25_PAD_A21__A21			0x02c 0x248 0x000 0x10 0x000
+#define MX25_PAD_A21__GPIO_2_7			0x02c 0x248 0x000 0x15 0x000
+#define MX25_PAD_A21__FEC_RDATA3		0x02c 0x248 0x510 0x17 0x000
+
+#define MX25_PAD_A22__A22			0x030 0x000 0x000 0x10 0x000
+#define MX25_PAD_A22__GPIO_2_8			0x030 0x000 0x000 0x15 0x000
+
+#define MX25_PAD_A23__A23			0x034 0x24c 0x000 0x10 0x000
+#define MX25_PAD_A23__GPIO_2_9			0x034 0x24c 0x000 0x15 0x000
+
+#define MX25_PAD_A24__A24			0x038 0x250 0x000 0x10 0x000
+#define MX25_PAD_A24__GPIO_2_10			0x038 0x250 0x000 0x15 0x000
+#define MX25_PAD_A24__FEC_RX_CLK		0x038 0x250 0x514 0x17 0x000
+
+#define MX25_PAD_A25__A25			0x03c 0x254 0x000 0x10 0x000
+#define MX25_PAD_A25__GPIO_2_11			0x03c 0x254 0x000 0x15 0x000
+#define MX25_PAD_A25__FEC_CRS			0x03c 0x254 0x508 0x17 0x000
+
+#define MX25_PAD_EB0__EB0			0x040 0x258 0x000 0x10 0x000
+#define MX25_PAD_EB0__AUD4_TXD			0x040 0x258 0x464 0x14 0x000
+#define MX25_PAD_EB0__GPIO_2_12			0x040 0x258 0x000 0x15 0x000
+
+#define MX25_PAD_EB1__EB1			0x044 0x25c 0x000 0x10 0x000
+#define MX25_PAD_EB1__AUD4_RXD			0x044 0x25c 0x460 0x14 0x000
+#define MX25_PAD_EB1__GPIO_2_13			0x044 0x25c 0x000 0x15 0x000
+
+#define MX25_PAD_OE__OE				0x048 0x260 0x000 0x10 0x000
+#define MX25_PAD_OE__AUD4_TXC			0x048 0x260 0x000 0x14 0x000
+#define MX25_PAD_OE__GPIO_2_14			0x048 0x260 0x000 0x15 0x000
+
+#define MX25_PAD_CS0__CS0			0x04c 0x000 0x000 0x00 0x000
+#define MX25_PAD_CS0__GPIO_4_2			0x04c 0x000 0x000 0x05 0x000
+
+#define MX25_PAD_CS1__CS1			0x050 0x000 0x000 0x00 0x000
+#define MX25_PAD_CS1__NF_CE3			0x050 0x000 0x000 0x01 0x000
+#define MX25_PAD_CS1__GPIO_4_3			0x050 0x000 0x000 0x05 0x000
+
+#define MX25_PAD_CS4__CS4			0x054 0x264 0x000 0x10 0x000
+#define MX25_PAD_CS4__NF_CE1			0x054 0x264 0x000 0x01 0x000
+#define MX25_PAD_CS4__UART5_CTS			0x054 0x264 0x000 0x13 0x000
+#define MX25_PAD_CS4__GPIO_3_20			0x054 0x264 0x000 0x15 0x000
+
+#define MX25_PAD_CS5__CS5			0x058 0x268 0x000 0x10 0x000
+#define MX25_PAD_CS5__NF_CE2			0x058 0x268 0x000 0x01 0x000
+#define MX25_PAD_CS5__UART5_RTS			0x058 0x268 0x574 0x13 0x000
+#define MX25_PAD_CS5__GPIO_3_21			0x058 0x268 0x000 0x15 0x000
+
+#define MX25_PAD_NF_CE0__NF_CE0			0x05c 0x26c 0x000 0x10 0x000
+#define MX25_PAD_NF_CE0__GPIO_3_22		0x05c 0x26c 0x000 0x15 0x000
+
+#define MX25_PAD_ECB__ECB			0x060 0x270 0x000 0x10 0x000
+#define MX25_PAD_ECB__UART5_TXD_MUX		0x060 0x270 0x000 0x13 0x000
+#define MX25_PAD_ECB__GPIO_3_23			0x060 0x270 0x000 0x15 0x000
+
+#define MX25_PAD_LBA__LBA			0x064 0x274 0x000 0x10 0x000
+#define MX25_PAD_LBA__UART5_RXD_MUX		0x064 0x274 0x578 0x13 0x000
+#define MX25_PAD_LBA__GPIO_3_24			0x064 0x274 0x000 0x15 0x000
+
+#define MX25_PAD_BCLK__BCLK			0x068 0x000 0x000 0x00 0x000
+#define MX25_PAD_BCLK__GPIO_4_4			0x068 0x000 0x000 0x05 0x000
+
+#define MX25_PAD_RW__RW				0x06c 0x278 0x000 0x10 0x000
+#define MX25_PAD_RW__AUD4_TXFS			0x06c 0x278 0x474 0x14 0x000
+#define MX25_PAD_RW__GPIO_3_25			0x06c 0x278 0x000 0x15 0x000
+
+#define MX25_PAD_NFWE_B__NFWE_B			0x070 0x000 0x000 0x10 0x000
+#define MX25_PAD_NFWE_B__GPIO_3_26		0x070 0x000 0x000 0x15 0x000
+
+#define MX25_PAD_NFRE_B__NFRE_B			0x074 0x000 0x000 0x10 0x000
+#define MX25_PAD_NFRE_B__GPIO_3_27		0x074 0x000 0x000 0x15 0x000
+
+#define MX25_PAD_NFALE__NFALE			0x078 0x000 0x000 0x10 0x000
+#define MX25_PAD_NFALE__GPIO_3_28		0x078 0x000 0x000 0x15 0x000
+
+#define MX25_PAD_NFCLE__NFCLE			0x07c 0x000 0x000 0x10 0x000
+#define MX25_PAD_NFCLE__GPIO_3_29		0x07c 0x000 0x000 0x15 0x000
+
+#define MX25_PAD_NFWP_B__NFWP_B			0x080 0x000 0x000 0x10 0x000
+#define MX25_PAD_NFWP_B__GPIO_3_30		0x080 0x000 0x000 0x15 0x000
+
+#define MX25_PAD_NFRB__NFRB			0x084 0x27c 0x000 0x10 0x000
+#define MX25_PAD_NFRB__GPIO_3_31		0x084 0x27c 0x000 0x15 0x000
+
+#define MX25_PAD_D15__D15			0x088 0x280 0x000 0x00 0x000
+#define MX25_PAD_D15__LD16			0x088 0x280 0x000 0x01 0x000
+#define MX25_PAD_D15__GPIO_4_5			0x088 0x280 0x000 0x05 0x000
+
+#define MX25_PAD_D14__D14			0x08c 0x284 0x000 0x00 0x000
+#define MX25_PAD_D14__LD17			0x08c 0x284 0x000 0x01 0x000
+#define MX25_PAD_D14__GPIO_4_6			0x08c 0x284 0x000 0x05 0x000
+
+#define MX25_PAD_D13__D13			0x090 0x288 0x000 0x00 0x000
+#define MX25_PAD_D13__LD18			0x090 0x288 0x000 0x01 0x000
+#define MX25_PAD_D13__GPIO_4_7			0x090 0x288 0x000 0x05 0x000
+
+#define MX25_PAD_D12__D12			0x094 0x28c 0x000 0x00 0x000
+#define MX25_PAD_D12__GPIO_4_8			0x094 0x28c 0x000 0x05 0x000
+
+#define MX25_PAD_D11__D11			0x098 0x290 0x000 0x00 0x000
+#define MX25_PAD_D11__GPIO_4_9			0x098 0x290 0x000 0x05 0x000
+
+#define MX25_PAD_D10__D10			0x09c 0x294 0x000 0x00 0x000
+#define MX25_PAD_D10__GPIO_4_10			0x09c 0x294 0x000 0x05 0x000
+#define MX25_PAD_D10__USBOTG_OC			0x09c 0x294 0x57c 0x06 0x000
+
+#define MX25_PAD_D9__D9				0x0a0 0x298 0x000 0x00 0x000
+#define MX25_PAD_D9__GPIO_4_11			0x0a0 0x298 0x000 0x05 0x000
+#define MX25_PAD_D9__USBH2_PWR			0x0a0 0x298 0x000 0x06 0x000
+
+#define MX25_PAD_D8__D8				0x0a4 0x29c 0x000 0x00 0x000
+#define MX25_PAD_D8__GPIO_4_12			0x0a4 0x29c 0x000 0x05 0x000
+#define MX25_PAD_D8__USBH2_OC			0x0a4 0x29c 0x580 0x06 0x000
+
+#define MX25_PAD_D7__D7				0x0a8 0x2a0 0x000 0x00 0x000
+#define MX25_PAD_D7__GPIO_4_13			0x0a8 0x2a0 0x000 0x05 0x000
+
+#define MX25_PAD_D6__D6				0x0ac 0x2a4 0x000 0x00 0x000
+#define MX25_PAD_D6__GPIO_4_14			0x0ac 0x2a4 0x000 0x05 0x000
+
+#define MX25_PAD_D5__D5				0x0b0 0x2a8 0x000 0x00 0x000
+#define MX25_PAD_D5__GPIO_4_15			0x0b0 0x2a8 0x000 0x05 0x000
+
+#define MX25_PAD_D4__D4				0x0b4 0x2ac 0x000 0x00 0x000
+#define MX25_PAD_D4__GPIO_4_16			0x0b4 0x2ac 0x000 0x05 0x000
+
+#define MX25_PAD_D3__D3				0x0b8 0x2b0 0x000 0x00 0x000
+#define MX25_PAD_D3__GPIO_4_17			0x0b8 0x2b0 0x000 0x05 0x000
+
+#define MX25_PAD_D2__D2				0x0bc 0x2b4 0x000 0x00 0x000
+#define MX25_PAD_D2__GPIO_4_18			0x0bc 0x2b4 0x000 0x05 0x000
+
+#define MX25_PAD_D1__D1				0x0c0 0x2b8 0x000 0x00 0x000
+#define MX25_PAD_D1__GPIO_4_19			0x0c0 0x2b8 0x000 0x05 0x000
+
+#define MX25_PAD_D0__D0				0x0c4 0x2bc 0x000 0x00 0x000
+#define MX25_PAD_D0__GPIO_4_20			0x0c4 0x2bc 0x000 0x05 0x000
+
+#define MX25_PAD_LD0__LD0			0x0c8 0x2c0 0x000 0x10 0x000
+#define MX25_PAD_LD0__CSI_D0			0x0c8 0x2c0 0x488 0x12 0x000
+#define MX25_PAD_LD0__GPIO_2_15			0x0c8 0x2c0 0x000 0x15 0x000
+
+#define MX25_PAD_LD1__LD1			0x0cc 0x2c4 0x000 0x10 0x000
+#define MX25_PAD_LD1__CSI_D1			0x0cc 0x2c4 0x48c 0x12 0x000
+#define MX25_PAD_LD1__GPIO_2_16			0x0cc 0x2c4 0x000 0x15 0x000
+
+#define MX25_PAD_LD2__LD2			0x0d0 0x2c8 0x000 0x10 0x000
+#define MX25_PAD_LD2__GPIO_2_17			0x0d0 0x2c8 0x000 0x15 0x000
+
+#define MX25_PAD_LD3__LD3			0x0d4 0x2cc 0x000 0x10 0x000
+#define MX25_PAD_LD3__GPIO_2_18			0x0d4 0x2cc 0x000 0x15 0x000
+
+#define MX25_PAD_LD4__LD4			0x0d8 0x2d0 0x000 0x10 0x000
+#define MX25_PAD_LD4__GPIO_2_19			0x0d8 0x2d0 0x000 0x15 0x000
+
+#define MX25_PAD_LD5__LD5			0x0dc 0x2d4 0x000 0x10 0x000
+#define MX25_PAD_LD5__GPIO_1_19			0x0dc 0x2d4 0x000 0x15 0x000
+
+#define MX25_PAD_LD6__LD6			0x0e0 0x2d8 0x000 0x10 0x000
+#define MX25_PAD_LD6__GPIO_1_20			0x0e0 0x2d8 0x000 0x15 0x000
+
+#define MX25_PAD_LD7__LD7			0x0e4 0x2dc 0x000 0x10 0x000
+#define MX25_PAD_LD7__GPIO_1_21			0x0e4 0x2dc 0x000 0x15 0x000
+
+#define MX25_PAD_LD8__LD8			0x0e8 0x2e0 0x000 0x10 0x000
+#define MX25_PAD_LD8__FEC_TX_ERR		0x0e8 0x2e0 0x000 0x15 0x000
+
+#define MX25_PAD_LD9__LD9			0x0ec 0x2e4 0x000 0x10 0x000
+#define MX25_PAD_LD9__FEC_COL			0x0ec 0x2e4 0x504 0x15 0x001
+
+#define MX25_PAD_LD10__LD10			0x0f0 0x2e8 0x000 0x10 0x000
+#define MX25_PAD_LD10__FEC_RX_ER		0x0f0 0x2e8 0x518 0x15 0x001
+
+#define MX25_PAD_LD11__LD11			0x0f4 0x2ec 0x000 0x10 0x000
+#define MX25_PAD_LD11__FEC_RDATA2		0x0f4 0x2ec 0x50c 0x15 0x001
+
+#define MX25_PAD_LD12__LD12			0x0f8 0x2f0 0x000 0x10 0x000
+#define MX25_PAD_LD12__FEC_RDATA3		0x0f8 0x2f0 0x510 0x15 0x001
+
+#define MX25_PAD_LD13__LD13			0x0fc 0x2f4 0x000 0x10 0x000
+#define MX25_PAD_LD13__FEC_TDATA2		0x0fc 0x2f4 0x000 0x15 0x000
+
+#define MX25_PAD_LD14__LD14			0x100 0x2f8 0x000 0x10 0x000
+#define MX25_PAD_LD14__FEC_TDATA3		0x100 0x2f8 0x000 0x15 0x000
+
+#define MX25_PAD_LD15__LD15			0x104 0x2fc 0x000 0x10 0x000
+#define MX25_PAD_LD15__FEC_RX_CLK		0x104 0x2fc 0x514 0x15 0x001
+
+#define MX25_PAD_HSYNC__HSYNC			0x108 0x300 0x000 0x10 0x000
+#define MX25_PAD_HSYNC__GPIO_1_22		0x108 0x300 0x000 0x15 0x000
+
+#define MX25_PAD_VSYNC__VSYNC			0x10c 0x304 0x000 0x10 0x000
+#define MX25_PAD_VSYNC__GPIO_1_23		0x10c 0x304 0x000 0x15 0x000
+
+#define MX25_PAD_LSCLK__LSCLK			0x110 0x308 0x000 0x10 0x000
+#define MX25_PAD_LSCLK__GPIO_1_24		0x110 0x308 0x000 0x15 0x000
+
+#define MX25_PAD_OE_ACD__OE_ACD			0x114 0x30c 0x000 0x10 0x000
+#define MX25_PAD_OE_ACD__GPIO_1_25		0x114 0x30c 0x000 0x15 0x000
+
+#define MX25_PAD_CONTRAST__CONTRAST		0x118 0x310 0x000 0x10 0x000
+#define MX25_PAD_CONTRAST__PWM4_PWMO		0x118 0x310 0x000 0x14 0x000
+#define MX25_PAD_CONTRAST__FEC_CRS		0x118 0x310 0x508 0x15 0x001
+
+#define MX25_PAD_PWM__PWM			0x11c 0x314 0x000 0x10 0x000
+#define MX25_PAD_PWM__GPIO_1_26			0x11c 0x314 0x000 0x15 0x000
+#define MX25_PAD_PWM__USBH2_OC			0x11c 0x314 0x580 0x16 0x001
+
+#define MX25_PAD_CSI_D2__CSI_D2			0x120 0x318 0x000 0x10 0x000
+#define MX25_PAD_CSI_D2__UART5_RXD_MUX		0x120 0x318 0x578 0x11 0x001
+#define MX25_PAD_CSI_D2__GPIO_1_27		0x120 0x318 0x000 0x15 0x000
+#define MX25_PAD_CSI_D2__CSPI3_MOSI		0x120 0x318 0x000 0x17 0x000
+
+#define MX25_PAD_CSI_D3__CSI_D3			0x124 0x31c 0x000 0x10 0x000
+#define MX25_PAD_CSI_D3__GPIO_1_28		0x124 0x31c 0x000 0x15 0x000
+#define MX25_PAD_CSI_D3__CSPI3_MISO		0x124 0x31c 0x4b4 0x17 0x001
+
+#define MX25_PAD_CSI_D4__CSI_D4			0x128 0x320 0x000 0x10 0x000
+#define MX25_PAD_CSI_D4__UART5_RTS		0x128 0x320 0x574 0x11 0x001
+#define MX25_PAD_CSI_D4__GPIO_1_29		0x128 0x320 0x000 0x15 0x000
+#define MX25_PAD_CSI_D4__CSPI3_SCLK		0x128 0x320 0x000 0x17 0x000
+
+#define MX25_PAD_CSI_D5__CSI_D5			0x12c 0x324 0x000 0x10 0x000
+#define MX25_PAD_CSI_D5__GPIO_1_30		0x12c 0x324 0x000 0x15 0x000
+#define MX25_PAD_CSI_D5__CSPI3_RDY		0x12c 0x324 0x000 0x17 0x000
+
+#define MX25_PAD_CSI_D6__CSI_D6			0x130 0x328 0x000 0x10 0x000
+#define MX25_PAD_CSI_D6__GPIO_1_31		0x130 0x328 0x000 0x15 0x000
+
+#define MX25_PAD_CSI_D7__CSI_D7			0x134 0x32c 0x000 0x10 0x000
+#define MX25_PAD_CSI_D7__GPIO_1_6		0x134 0x32c 0x000 0x15 0x000
+
+#define MX25_PAD_CSI_D8__CSI_D8			0x138 0x330 0x000 0x10 0x000
+#define MX25_PAD_CSI_D8__GPIO_1_7		0x138 0x330 0x000 0x15 0x000
+
+#define MX25_PAD_CSI_D9__CSI_D9			0x13c 0x334 0x000 0x10 0x000
+#define MX25_PAD_CSI_D9__GPIO_4_21		0x13c 0x334 0x000 0x15 0x000
+
+#define MX25_PAD_CSI_MCLK__CSI_MCLK		0x140 0x338 0x000 0x10 0x000
+#define MX25_PAD_CSI_MCLK__GPIO_1_8		0x140 0x338 0x000 0x15 0x000
+
+#define MX25_PAD_CSI_VSYNC__CSI_VSYNC		0x144 0x33c 0x000 0x10 0x000
+#define MX25_PAD_CSI_VSYNC__GPIO_1_9		0x144 0x33c 0x000 0x15 0x000
+
+#define MX25_PAD_CSI_HSYNC__CSI_HSYNC		0x148 0x340 0x000 0x10 0x000
+#define MX25_PAD_CSI_HSYNC__GPIO_1_10		0x148 0x340 0x000 0x15 0x000
+
+#define MX25_PAD_CSI_PIXCLK__CSI_PIXCLK		0x14c 0x344 0x000 0x10 0x000
+#define MX25_PAD_CSI_PIXCLK__GPIO_1_11		0x14c 0x344 0x000 0x15 0x000
+
+#define MX25_PAD_I2C1_CLK__I2C1_CLK		0x150 0x348 0x000 0x10 0x000
+#define MX25_PAD_I2C1_CLK__GPIO_1_12		0x150 0x348 0x000 0x15 0x000
+
+#define MX25_PAD_I2C1_DAT__I2C1_DAT		0x154 0x34c 0x000 0x10 0x000
+#define MX25_PAD_I2C1_DAT__GPIO_1_13		0x154 0x34c 0x000 0x15 0x000
+
+#define MX25_PAD_CSPI1_MOSI__CSPI1_MOSI		0x158 0x350 0x000 0x10 0x000
+#define MX25_PAD_CSPI1_MOSI__GPIO_1_14		0x158 0x350 0x000 0x15 0x000
+
+#define MX25_PAD_CSPI1_MISO__CSPI1_MISO		0x15c 0x354 0x000 0x10 0x000
+#define MX25_PAD_CSPI1_MISO__GPIO_1_15		0x15c 0x354 0x000 0x15 0x000
+
+#define MX25_PAD_CSPI1_SS0__CSPI1_SS0		0x160 0x358 0x000 0x10 0x000
+#define MX25_PAD_CSPI1_SS0__GPIO_1_16		0x160 0x358 0x000 0x15 0x000
+
+#define MX25_PAD_CSPI1_SS1__CSPI1_SS1		0x164 0x35c 0x000 0x10 0x000
+#define MX25_PAD_CSPI1_SS1__GPIO_1_17		0x164 0x35c 0x000 0x15 0x000
+
+#define MX25_PAD_CSPI1_SCLK__CSPI1_SCLK		0x168 0x360 0x000 0x10 0x000
+#define MX25_PAD_CSPI1_SCLK__GPIO_1_18		0x168 0x360 0x000 0x15 0x000
+
+#define MX25_PAD_CSPI1_RDY__CSPI1_RDY		0x16c 0x364 0x000 0x10 0x000
+#define MX25_PAD_CSPI1_RDY__GPIO_2_22		0x16c 0x364 0x000 0x15 0x000
+
+#define MX25_PAD_UART1_RXD__UART1_RXD		0x170 0x368 0x000 0x10 0x000
+#define MX25_PAD_UART1_RXD__GPIO_4_22		0x170 0x368 0x000 0x15 0x000
+
+#define MX25_PAD_UART1_TXD__UART1_TXD		0x174 0x36c 0x000 0x10 0x000
+#define MX25_PAD_UART1_TXD__GPIO_4_23		0x174 0x36c 0x000 0x15 0x000
+
+#define MX25_PAD_UART1_RTS__UART1_RTS		0x178 0x370 0x000 0x10 0x000
+#define MX25_PAD_UART1_RTS__CSI_D0		0x178 0x370 0x488 0x11 0x001
+#define MX25_PAD_UART1_RTS__GPIO_4_24		0x178 0x370 0x000 0x15 0x000
+
+#define MX25_PAD_UART1_CTS__UART1_CTS		0x17c 0x374 0x000 0x10 0x000
+#define MX25_PAD_UART1_CTS__CSI_D1		0x17c 0x374 0x48c 0x11 0x001
+#define MX25_PAD_UART1_CTS__GPIO_4_25		0x17c 0x374 0x000 0x15 0x000
+
+#define MX25_PAD_UART2_RXD__UART2_RXD		0x180 0x378 0x000 0x10 0x000
+#define MX25_PAD_UART2_RXD__GPIO_4_26		0x180 0x378 0x000 0x15 0x000
+
+#define MX25_PAD_UART2_TXD__UART2_TXD		0x184 0x37c 0x000 0x10 0x000
+#define MX25_PAD_UART2_TXD__GPIO_4_27		0x184 0x37c 0x000 0x15 0x000
+
+#define MX25_PAD_UART2_RTS__UART2_RTS		0x188 0x380 0x000 0x10 0x000
+#define MX25_PAD_UART2_RTS__FEC_COL		0x188 0x380 0x504 0x12 0x002
+#define MX25_PAD_UART2_RTS__GPIO_4_28		0x188 0x380 0x000 0x15 0x000
+
+#define MX25_PAD_UART2_CTS__FEC_RX_ER		0x18c 0x384 0x518 0x12 0x002
+#define MX25_PAD_UART2_CTS__UART2_CTS		0x18c 0x384 0x000 0x10 0x000
+#define MX25_PAD_UART2_CTS__GPIO_4_29		0x18c 0x384 0x000 0x15 0x000
+
+#define MX25_PAD_SD1_CMD__SD1_CMD		0x190 0x388 0x000 0x10 0x000
+#define MX25_PAD_SD1_CMD__FEC_RDATA2		0x190 0x388 0x50c 0x12 0x002
+#define MX25_PAD_SD1_CMD__GPIO_2_23		0x190 0x388 0x000 0x15 0x000
+
+#define MX25_PAD_SD1_CLK__SD1_CLK		0x194 0x38c 0x000 0x10 0x000
+#define MX25_PAD_SD1_CLK__FEC_RDATA3		0x194 0x38c 0x510 0x12 0x002
+#define MX25_PAD_SD1_CLK__GPIO_2_24		0x194 0x38c 0x000 0x15 0x000
+
+#define MX25_PAD_SD1_DATA0__SD1_DATA0		0x198 0x390 0x000 0x10 0x000
+#define MX25_PAD_SD1_DATA0__GPIO_2_25		0x198 0x390 0x000 0x15 0x000
+
+#define MX25_PAD_SD1_DATA1__SD1_DATA1		0x19c 0x394 0x000 0x10 0x000
+#define MX25_PAD_SD1_DATA1__AUD7_RXD		0x19c 0x394 0x478 0x13 0x000
+#define MX25_PAD_SD1_DATA1__GPIO_2_26		0x19c 0x394 0x000 0x15 0x000
+
+#define MX25_PAD_SD1_DATA2__SD1_DATA2		0x1a0 0x398 0x000 0x10 0x000
+#define MX25_PAD_SD1_DATA2__FEC_RX_CLK		0x1a0 0x398 0x514 0x15 0x002
+#define MX25_PAD_SD1_DATA2__GPIO_2_27		0x1a0 0x398 0x000 0x15 0x000
+
+#define MX25_PAD_SD1_DATA3__SD1_DATA3		0x1a4 0x39c 0x000 0x10 0x000
+#define MX25_PAD_SD1_DATA3__FEC_CRS		0x1a4 0x39c 0x508 0x10 0x002
+#define MX25_PAD_SD1_DATA3__GPIO_2_28		0x1a4 0x39c 0x000 0x15 0x000
+
+#define MX25_PAD_KPP_ROW0__KPP_ROW0		0x1a8 0x3a0 0x000 0x10 0x000
+#define MX25_PAD_KPP_ROW0__GPIO_2_29		0x1a8 0x3a0 0x000 0x15 0x000
+
+#define MX25_PAD_KPP_ROW1__KPP_ROW1		0x1ac 0x3a4 0x000 0x10 0x000
+#define MX25_PAD_KPP_ROW1__GPIO_2_30		0x1ac 0x3a4 0x000 0x15 0x000
+
+#define MX25_PAD_KPP_ROW2__KPP_ROW2		0x1b0 0x3a8 0x000 0x10 0x000
+#define MX25_PAD_KPP_ROW2__CSI_D0		0x1b0 0x3a8 0x488 0x13 0x002
+#define MX25_PAD_KPP_ROW2__GPIO_2_31		0x1b0 0x3a8 0x000 0x15 0x000
+
+#define MX25_PAD_KPP_ROW3__KPP_ROW3		0x1b4 0x3ac 0x000 0x10 0x000
+#define MX25_PAD_KPP_ROW3__CSI_LD1		0x1b4 0x3ac 0x48c 0x13 0x002
+#define MX25_PAD_KPP_ROW3__GPIO_3_0		0x1b4 0x3ac 0x000 0x15 0x000
+
+#define MX25_PAD_KPP_COL0__KPP_COL0		0x1b8 0x3b0 0x000 0x10 0x000
+#define MX25_PAD_KPP_COL0__UART4_RXD_MUX	0x1b8 0x3b0 0x570 0x11 0x001
+#define MX25_PAD_KPP_COL0__AUD5_TXD		0x1b8 0x3b0 0x000 0x12 0x000
+#define MX25_PAD_KPP_COL0__GPIO_3_1		0x1b8 0x3b0 0x000 0x15 0x000
+
+#define MX25_PAD_KPP_COL1__KPP_COL1		0x1bc 0x3b4 0x000 0x10 0x000
+#define MX25_PAD_KPP_COL1__UART4_TXD_MUX	0x1bc 0x3b4 0x000 0x11 0x000
+#define MX25_PAD_KPP_COL1__AUD5_RXD		0x1bc 0x3b4 0x000 0x12 0x000
+#define MX25_PAD_KPP_COL1__GPIO_3_2		0x1bc 0x3b4 0x000 0x15 0x000
+
+#define MX25_PAD_KPP_COL2__KPP_COL2		0x1c0 0x3b8 0x000 0x10 0x000
+#define MX25_PAD_KPP_COL2__UART4_RTS		0x1c0 0x3b8 0x000 0x11 0x000
+#define MX25_PAD_KPP_COL2__AUD5_TXC		0x1c0 0x3b8 0x000 0x12 0x000
+#define MX25_PAD_KPP_COL2__GPIO_3_3		0x1c0 0x3b8 0x000 0x15 0x000
+
+#define MX25_PAD_KPP_COL3__KPP_COL3		0x1c4 0x3bc 0x000 0x10 0x000
+#define MX25_PAD_KPP_COL3__UART4_CTS		0x1c4 0x3bc 0x000 0x11 0x000
+#define MX25_PAD_KPP_COL3__AUD5_TXFS		0x1c4 0x3bc 0x000 0x12 0x000
+#define MX25_PAD_KPP_COL3__GPIO_3_4		0x1c4 0x3bc 0x000 0x15 0x000
+
+#define MX25_PAD_FEC_MDC__FEC_MDC		0x1c8 0x3c0 0x000 0x10 0x000
+#define MX25_PAD_FEC_MDC__AUD4_TXD		0x1c8 0x3c0 0x464 0x12 0x001
+#define MX25_PAD_FEC_MDC__GPIO_3_5		0x1c8 0x3c0 0x000 0x15 0x000
+
+#define MX25_PAD_FEC_MDIO__FEC_MDIO		0x1cc 0x3c4 0x000 0x10 0x000
+#define MX25_PAD_FEC_MDIO__AUD4_RXD		0x1cc 0x3c4 0x460 0x12 0x001
+#define MX25_PAD_FEC_MDIO__GPIO_3_6		0x1cc 0x3c4 0x000 0x15 0x000
+
+#define MX25_PAD_FEC_TDATA0__FEC_TDATA0		0x1d0 0x3c8 0x000 0x10 0x000
+#define MX25_PAD_FEC_TDATA0__GPIO_3_7		0x1d0 0x3c8 0x000 0x15 0x000
+
+#define MX25_PAD_FEC_TDATA1__FEC_TDATA1		0x1d4 0x3cc 0x000 0x10 0x000
+#define MX25_PAD_FEC_TDATA1__AUD4_TXFS		0x1d4 0x3cc 0x474 0x12 0x001
+#define MX25_PAD_FEC_TDATA1__GPIO_3_8		0x1d4 0x3cc 0x000 0x15 0x000
+
+#define MX25_PAD_FEC_TX_EN__FEC_TX_EN		0x1d8 0x3d0 0x000 0x10 0x000
+#define MX25_PAD_FEC_TX_EN__GPIO_3_9		0x1d8 0x3d0 0x000 0x15 0x000
+
+#define MX25_PAD_FEC_RDATA0__FEC_RDATA0		0x1dc 0x3d4 0x000 0x10 0x000
+#define MX25_PAD_FEC_RDATA0__GPIO_3_10		0x1dc 0x3d4 0x000 0x15 0x000
+
+#define MX25_PAD_FEC_RDATA1__FEC_RDATA1		0x1e0 0x3d8 0x000 0x10 0x000
+#define MX25_PAD_FEC_RDATA1__GPIO_3_11		0x1e0 0x3d8 0x000 0x15 0x000
+
+#define MX25_PAD_FEC_RX_DV__FEC_RX_DV		0x1e4 0x3dc 0x000 0x10 0x000
+#define MX25_PAD_FEC_RX_DV__CAN2_RX		0x1e4 0x3dc 0x484 0x14 0x000
+#define MX25_PAD_FEC_RX_DV__GPIO_3_12		0x1e4 0x3dc 0x000 0x15 0x000
+
+#define MX25_PAD_FEC_TX_CLK__FEC_TX_CLK		0x1e8 0x3e0 0x000 0x10 0x000
+#define MX25_PAD_FEC_TX_CLK__GPIO_3_13		0x1e8 0x3e0 0x000 0x15 0x000
+
+#define MX25_PAD_RTCK__RTCK			0x1ec 0x3e4 0x000 0x10 0x000
+#define MX25_PAD_RTCK__OWIRE			0x1ec 0x3e4 0x000 0x11 0x000
+#define MX25_PAD_RTCK__GPIO_3_14		0x1ec 0x3e4 0x000 0x15 0x000
+
+#define MX25_PAD_DE_B__DE_B			0x1f0 0x3ec 0x000 0x10 0x000
+#define MX25_PAD_DE_B__GPIO_2_20		0x1f0 0x3ec 0x000 0x15 0x000
+
+#define MX25_PAD_TDO__TDO			0x000 0x3e8 0x000 0x00 0x000
+
+#define MX25_PAD_GPIO_A__GPIO_A			0x1f4 0x3f0 0x000 0x10 0x000
+#define MX25_PAD_GPIO_A__CAN1_TX		0x1f4 0x3f0 0x000 0x16 0x000
+#define MX25_PAD_GPIO_A__USBOTG_PWR		0x1f4 0x3f0 0x000 0x12 0x000
+
+#define MX25_PAD_GPIO_B__GPIO_B			0x1f8 0x3f4 0x000 0x10 0x000
+#define MX25_PAD_GPIO_B__CAN1_RX		0x1f8 0x3f4 0x480 0x16 0x001
+#define MX25_PAD_GPIO_B__USBOTG_OC		0x1f8 0x3f4 0x57c 0x12 0x001
+
+#define MX25_PAD_GPIO_C__GPIO_C			0x1fc 0x3f8 0x000 0x10 0x000
+#define MX25_PAD_GPIO_C__CAN2_TX		0x1fc 0x3f8 0x000 0x16 0x000
+
+#define MX25_PAD_GPIO_D__GPIO_D			0x200 0x3fc 0x000 0x10 0x000
+#define MX25_PAD_GPIO_E__LD16			0x204 0x400 0x000 0x02 0x000
+#define MX25_PAD_GPIO_D__CAN2_RX		0x200 0x3fc 0x484 0x16 0x001
+
+#define MX25_PAD_GPIO_E__GPIO_E			0x204 0x400 0x000 0x10 0x000
+#define MX25_PAD_GPIO_F__LD17			0x208 0x404 0x000 0x02 0x000
+#define MX25_PAD_GPIO_E__AUD7_TXD		0x204 0x400 0x000 0x14 0x000
+
+#define MX25_PAD_GPIO_F__GPIO_F			0x208 0x404 0x000 0x10 0x000
+#define MX25_PAD_GPIO_F__AUD7_TXC		0x208 0x404 0x000 0x14 0x000
+
+#define MX25_PAD_EXT_ARMCLK__EXT_ARMCLK		0x20c 0x000 0x000 0x10 0x000
+#define MX25_PAD_EXT_ARMCLK__GPIO_3_15		0x20c 0x000 0x000 0x15 0x000
+
+#define MX25_PAD_UPLL_BYPCLK__UPLL_BYPCLK	0x210 0x000 0x000 0x10 0x000
+#define MX25_PAD_UPLL_BYPCLK__GPIO_3_16		0x210 0x000 0x000 0x15 0x000
+
+#define MX25_PAD_VSTBY_REQ__VSTBY_REQ		0x214 0x408 0x000 0x10 0x000
+#define MX25_PAD_VSTBY_REQ__AUD7_TXFS		0x214 0x408 0x000 0x14 0x000
+#define MX25_PAD_VSTBY_REQ__GPIO_3_17		0x214 0x408 0x000 0x15 0x000
+#define MX25_PAD_VSTBY_ACK__VSTBY_ACK		0x218 0x40c 0x000 0x10 0x000
+#define MX25_PAD_VSTBY_ACK__GPIO_3_18		0x218 0x40c 0x000 0x15 0x000
+
+#define MX25_PAD_POWER_FAIL__POWER_FAIL		0x21c 0x410 0x000 0x10 0x000
+#define MX25_PAD_POWER_FAIL__AUD7_RXD		0x21c 0x410 0x478 0x14 0x001
+#define MX25_PAD_POWER_FAIL__GPIO_3_19		0x21c 0x410 0x000 0x15 0x000
+
+#define MX25_PAD_CLKO__CLKO			0x220 0x414 0x000 0x10 0x000
+#define MX25_PAD_CLKO__GPIO_2_21		0x220 0x414 0x000 0x15 0x000
+
+#define MX25_PAD_BOOT_MODE0__BOOT_MODE0		0x224 0x000 0x000 0x00 0x000
+#define MX25_PAD_BOOT_MODE0__GPIO_4_30		0x224 0x000 0x000 0x05 0x000
+#define MX25_PAD_BOOT_MODE1__BOOT_MODE1		0x228 0x000 0x000 0x00 0x000
+#define MX25_PAD_BOOT_MODE1__GPIO_4_31		0x228 0x000 0x000 0x05 0x000
+
+#define MX25_PAD_CTL_GRP_DVS_MISC		0x000 0x418 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DSE_FEC		0x000 0x41c 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DVS_JTAG		0x000 0x420 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DSE_NFC		0x000 0x424 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DSE_CSI		0x000 0x428 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DSE_WEIM		0x000 0x42c 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DSE_DDR		0x000 0x430 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DVS_CRM		0x000 0x434 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DSE_KPP		0x000 0x438 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DSE_SDHC1		0x000 0x43c 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DSE_LCD		0x000 0x440 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DSE_UART		0x000 0x444 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DVS_NFC		0x000 0x448 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DVS_CSI		0x000 0x44c 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DSE_CSPI1		0x000 0x450 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DDRTYPE		0x000 0x454 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DVS_SDHC1		0x000 0x458 0x000 0x00 0x000
+#define MX25_PAD_CTL_GRP_DVS_LCD		0x000 0x45c 0x000 0x00 0x000
+
+#endif /* __DTS_IMX25_PINFUNC_H */
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 4837849..f098603 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -10,6 +10,7 @@
  */
 
 #include "skeleton.dtsi"
+#include "imx25-pinfunc.h"
 
 / {
 	aliases {
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index f7a5ad1..8f7109e 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -110,6 +110,8 @@ config SOC_IMX25
 	select COMMON_CLK
 	select CPU_ARM926T
 	select MXC_AVIC
+	select PINCTRL
+	select PINCTRL_IMX25
 
 config SOC_IMX27
 	bool
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 5a8ad51..133238e 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -80,6 +80,14 @@ config PINCTRL_IMX
 	select PINMUX
 	select PINCONF
 
+config PINCTRL_IMX25
+        bool "IMX25 pinctrl driver"
+        depends on OF
+        depends on SOC_IMX25
+        select PINCTRL_IMX
+        help
+          Say Y here to enable the imx25 pinctrl driver
+
 config PINCTRL_IMX35
 	bool "IMX35 pinctrl driver"
 	depends on OF
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index d64563bf..cdd6606 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_PINCTRL_IMX6SL)	+= pinctrl-imx6sl.o
 obj-$(CONFIG_PINCTRL_FALCON)	+= pinctrl-falcon.o
 obj-$(CONFIG_PINCTRL_MXS)	+= pinctrl-mxs.o
 obj-$(CONFIG_PINCTRL_IMX23)	+= pinctrl-imx23.o
+obj-$(CONFIG_PINCTRL_IMX25)	+= pinctrl-imx25.o
 obj-$(CONFIG_PINCTRL_IMX28)	+= pinctrl-imx28.o
 obj-$(CONFIG_PINCTRL_NOMADIK)	+= pinctrl-nomadik.o
 obj-$(CONFIG_PINCTRL_STN8815)	+= pinctrl-nomadik-stn8815.o
diff --git a/drivers/pinctrl/pinctrl-imx25.c b/drivers/pinctrl/pinctrl-imx25.c
new file mode 100644
index 0000000..8994b43
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-imx25.c
@@ -0,0 +1,351 @@
+/*
+ * imx25 pinctrl driver.
+ *
+ * Copyright 2013 Eukr?a Electromatique <denis at eukrea.com>
+ *
+ * This driver was mostly copied from the imx51 pinctrl driver which has:
+ *
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ * Copyright (C) 2012 Linaro, Inc.
+ *
+ * Author: Dong Aisheng <dong.aisheng at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/pinctrl.h>
+
+#include "pinctrl-imx.h"
+
+enum imx25_pads {
+	MX25_PAD_RESERVE0 = 1,
+	MX25_PAD_RESERVE1 = 2,
+	MX25_PAD_A10 = 3,
+	MX25_PAD_A13 = 4,
+	MX25_PAD_A14 = 5,
+	MX25_PAD_A15 = 6,
+	MX25_PAD_A16 = 7,
+	MX25_PAD_A17 = 8,
+	MX25_PAD_A18 = 9,
+	MX25_PAD_A19 = 10,
+	MX25_PAD_A20 = 11,
+	MX25_PAD_A21 = 12,
+	MX25_PAD_A22 = 13,
+	MX25_PAD_A23 = 14,
+	MX25_PAD_A24 = 15,
+	MX25_PAD_A25 = 16,
+	MX25_PAD_EB0 = 17,
+	MX25_PAD_EB1 = 18,
+	MX25_PAD_OE = 19,
+	MX25_PAD_CS0 = 20,
+	MX25_PAD_CS1 = 21,
+	MX25_PAD_CS4 = 22,
+	MX25_PAD_CS5 = 23,
+	MX25_PAD_NF_CE0 = 24,
+	MX25_PAD_ECB = 25,
+	MX25_PAD_LBA = 26,
+	MX25_PAD_BCLK = 27,
+	MX25_PAD_RW = 28,
+	MX25_PAD_NFWE_B = 29,
+	MX25_PAD_NFRE_B = 30,
+	MX25_PAD_NFALE = 31,
+	MX25_PAD_NFCLE = 32,
+	MX25_PAD_NFWP_B = 33,
+	MX25_PAD_NFRB = 34,
+	MX25_PAD_D15 = 35,
+	MX25_PAD_D14 = 36,
+	MX25_PAD_D13 = 37,
+	MX25_PAD_D12 = 38,
+	MX25_PAD_D11 = 39,
+	MX25_PAD_D10 = 40,
+	MX25_PAD_D9 = 41,
+	MX25_PAD_D8 = 42,
+	MX25_PAD_D7 = 43,
+	MX25_PAD_D6 = 44,
+	MX25_PAD_D5 = 45,
+	MX25_PAD_D4 = 46,
+	MX25_PAD_D3 = 47,
+	MX25_PAD_D2 = 48,
+	MX25_PAD_D1 = 49,
+	MX25_PAD_D0 = 50,
+	MX25_PAD_LD0 = 51,
+	MX25_PAD_LD1 = 52,
+	MX25_PAD_LD2 = 53,
+	MX25_PAD_LD3 = 54,
+	MX25_PAD_LD4 = 55,
+	MX25_PAD_LD5 = 56,
+	MX25_PAD_LD6 = 57,
+	MX25_PAD_LD7 = 58,
+	MX25_PAD_LD8 = 59,
+	MX25_PAD_LD9 = 60,
+	MX25_PAD_LD10 = 61,
+	MX25_PAD_LD11 = 62,
+	MX25_PAD_LD12 = 63,
+	MX25_PAD_LD13 = 64,
+	MX25_PAD_LD14 = 65,
+	MX25_PAD_LD15 = 66,
+	MX25_PAD_HSYNC = 67,
+	MX25_PAD_VSYNC = 68,
+	MX25_PAD_LSCLK = 69,
+	MX25_PAD_OE_ACD = 70,
+	MX25_PAD_CONTRAST = 71,
+	MX25_PAD_PWM = 72,
+	MX25_PAD_CSI_D2 = 73,
+	MX25_PAD_CSI_D3 = 74,
+	MX25_PAD_CSI_D4 = 75,
+	MX25_PAD_CSI_D5 = 76,
+	MX25_PAD_CSI_D6 = 77,
+	MX25_PAD_CSI_D7 = 78,
+	MX25_PAD_CSI_D8 = 79,
+	MX25_PAD_CSI_D9 = 80,
+	MX25_PAD_CSI_MCLK = 81,
+	MX25_PAD_CSI_VSYNC = 82,
+	MX25_PAD_CSI_HSYNC = 83,
+	MX25_PAD_CSI_PIXCLK = 84,
+	MX25_PAD_I2C1_CLK = 85,
+	MX25_PAD_I2C1_DAT = 86,
+	MX25_PAD_CSPI1_MOSI = 87,
+	MX25_PAD_CSPI1_MISO = 88,
+	MX25_PAD_CSPI1_SS0 = 89,
+	MX25_PAD_CSPI1_SS1 = 90,
+	MX25_PAD_CSPI1_SCLK = 91,
+	MX25_PAD_CSPI1_RDY = 92,
+	MX25_PAD_UART1_RXD = 93,
+	MX25_PAD_UART1_TXD = 94,
+	MX25_PAD_UART1_RTS = 95,
+	MX25_PAD_UART1_CTS = 96,
+	MX25_PAD_UART2_RXD = 97,
+	MX25_PAD_UART2_TXD = 98,
+	MX25_PAD_UART2_RTS = 99,
+	MX25_PAD_UART2_CTS = 100,
+	MX25_PAD_SD1_CMD = 101,
+	MX25_PAD_SD1_CLK = 102,
+	MX25_PAD_SD1_DATA0 = 103,
+	MX25_PAD_SD1_DATA1 = 104,
+	MX25_PAD_SD1_DATA2 = 105,
+	MX25_PAD_SD1_DATA3 = 106,
+	MX25_PAD_KPP_ROW0 = 107,
+	MX25_PAD_KPP_ROW1 = 108,
+	MX25_PAD_KPP_ROW2 = 109,
+	MX25_PAD_KPP_ROW3 = 110,
+	MX25_PAD_KPP_COL0 = 111,
+	MX25_PAD_KPP_COL1 = 112,
+	MX25_PAD_KPP_COL2 = 113,
+	MX25_PAD_KPP_COL3 = 114,
+	MX25_PAD_FEC_MDC = 115,
+	MX25_PAD_FEC_MDIO = 116,
+	MX25_PAD_FEC_TDATA0 = 117,
+	MX25_PAD_FEC_TDATA1 = 118,
+	MX25_PAD_FEC_TX_EN = 119,
+	MX25_PAD_FEC_RDATA0 = 120,
+	MX25_PAD_FEC_RDATA1 = 121,
+	MX25_PAD_FEC_RX_DV = 122,
+	MX25_PAD_FEC_TX_CLK = 123,
+	MX25_PAD_RTCK = 124,
+	MX25_PAD_DE_B = 125,
+	MX25_PAD_GPIO_A = 126,
+	MX25_PAD_GPIO_B = 127,
+	MX25_PAD_GPIO_C = 128,
+	MX25_PAD_GPIO_D = 129,
+	MX25_PAD_GPIO_E = 130,
+	MX25_PAD_GPIO_F = 131,
+	MX25_PAD_EXT_ARMCLK = 132,
+	MX25_PAD_UPLL_BYPCLK = 133,
+	MX25_PAD_VSTBY_REQ = 134,
+	MX25_PAD_VSTBY_ACK = 135,
+	MX25_PAD_POWER_FAIL  = 136,
+	MX25_PAD_CLKO = 137,
+	MX25_PAD_BOOT_MODE0 = 138,
+	MX25_PAD_BOOT_MODE1 = 139,
+};
+
+/* Pad names for the pinmux subsystem */
+static const struct pinctrl_pin_desc imx25_pinctrl_pads[] = {
+	IMX_PINCTRL_PIN(MX25_PAD_RESERVE0),
+	IMX_PINCTRL_PIN(MX25_PAD_RESERVE1),
+	IMX_PINCTRL_PIN(MX25_PAD_A10),
+	IMX_PINCTRL_PIN(MX25_PAD_A13),
+	IMX_PINCTRL_PIN(MX25_PAD_A14),
+	IMX_PINCTRL_PIN(MX25_PAD_A15),
+	IMX_PINCTRL_PIN(MX25_PAD_A16),
+	IMX_PINCTRL_PIN(MX25_PAD_A17),
+	IMX_PINCTRL_PIN(MX25_PAD_A18),
+	IMX_PINCTRL_PIN(MX25_PAD_A19),
+	IMX_PINCTRL_PIN(MX25_PAD_A20),
+	IMX_PINCTRL_PIN(MX25_PAD_A21),
+	IMX_PINCTRL_PIN(MX25_PAD_A22),
+	IMX_PINCTRL_PIN(MX25_PAD_A23),
+	IMX_PINCTRL_PIN(MX25_PAD_A24),
+	IMX_PINCTRL_PIN(MX25_PAD_A25),
+	IMX_PINCTRL_PIN(MX25_PAD_EB0),
+	IMX_PINCTRL_PIN(MX25_PAD_EB1),
+	IMX_PINCTRL_PIN(MX25_PAD_OE),
+	IMX_PINCTRL_PIN(MX25_PAD_CS0),
+	IMX_PINCTRL_PIN(MX25_PAD_CS1),
+	IMX_PINCTRL_PIN(MX25_PAD_CS4),
+	IMX_PINCTRL_PIN(MX25_PAD_CS5),
+	IMX_PINCTRL_PIN(MX25_PAD_NF_CE0),
+	IMX_PINCTRL_PIN(MX25_PAD_ECB),
+	IMX_PINCTRL_PIN(MX25_PAD_LBA),
+	IMX_PINCTRL_PIN(MX25_PAD_BCLK),
+	IMX_PINCTRL_PIN(MX25_PAD_RW),
+	IMX_PINCTRL_PIN(MX25_PAD_NFWE_B),
+	IMX_PINCTRL_PIN(MX25_PAD_NFRE_B),
+	IMX_PINCTRL_PIN(MX25_PAD_NFALE),
+	IMX_PINCTRL_PIN(MX25_PAD_NFCLE),
+	IMX_PINCTRL_PIN(MX25_PAD_NFWP_B),
+	IMX_PINCTRL_PIN(MX25_PAD_NFRB),
+	IMX_PINCTRL_PIN(MX25_PAD_D15),
+	IMX_PINCTRL_PIN(MX25_PAD_D14),
+	IMX_PINCTRL_PIN(MX25_PAD_D13),
+	IMX_PINCTRL_PIN(MX25_PAD_D12),
+	IMX_PINCTRL_PIN(MX25_PAD_D11),
+	IMX_PINCTRL_PIN(MX25_PAD_D10),
+	IMX_PINCTRL_PIN(MX25_PAD_D9),
+	IMX_PINCTRL_PIN(MX25_PAD_D8),
+	IMX_PINCTRL_PIN(MX25_PAD_D7),
+	IMX_PINCTRL_PIN(MX25_PAD_D6),
+	IMX_PINCTRL_PIN(MX25_PAD_D5),
+	IMX_PINCTRL_PIN(MX25_PAD_D4),
+	IMX_PINCTRL_PIN(MX25_PAD_D3),
+	IMX_PINCTRL_PIN(MX25_PAD_D2),
+	IMX_PINCTRL_PIN(MX25_PAD_D1),
+	IMX_PINCTRL_PIN(MX25_PAD_D0),
+	IMX_PINCTRL_PIN(MX25_PAD_LD0),
+	IMX_PINCTRL_PIN(MX25_PAD_LD1),
+	IMX_PINCTRL_PIN(MX25_PAD_LD2),
+	IMX_PINCTRL_PIN(MX25_PAD_LD3),
+	IMX_PINCTRL_PIN(MX25_PAD_LD4),
+	IMX_PINCTRL_PIN(MX25_PAD_LD5),
+	IMX_PINCTRL_PIN(MX25_PAD_LD6),
+	IMX_PINCTRL_PIN(MX25_PAD_LD7),
+	IMX_PINCTRL_PIN(MX25_PAD_LD8),
+	IMX_PINCTRL_PIN(MX25_PAD_LD9),
+	IMX_PINCTRL_PIN(MX25_PAD_LD10),
+	IMX_PINCTRL_PIN(MX25_PAD_LD11),
+	IMX_PINCTRL_PIN(MX25_PAD_LD12),
+	IMX_PINCTRL_PIN(MX25_PAD_LD13),
+	IMX_PINCTRL_PIN(MX25_PAD_LD14),
+	IMX_PINCTRL_PIN(MX25_PAD_LD15),
+	IMX_PINCTRL_PIN(MX25_PAD_HSYNC),
+	IMX_PINCTRL_PIN(MX25_PAD_VSYNC),
+	IMX_PINCTRL_PIN(MX25_PAD_LSCLK),
+	IMX_PINCTRL_PIN(MX25_PAD_OE_ACD),
+	IMX_PINCTRL_PIN(MX25_PAD_CONTRAST),
+	IMX_PINCTRL_PIN(MX25_PAD_PWM),
+	IMX_PINCTRL_PIN(MX25_PAD_CSI_D2),
+	IMX_PINCTRL_PIN(MX25_PAD_CSI_D3),
+	IMX_PINCTRL_PIN(MX25_PAD_CSI_D4),
+	IMX_PINCTRL_PIN(MX25_PAD_CSI_D5),
+	IMX_PINCTRL_PIN(MX25_PAD_CSI_D6),
+	IMX_PINCTRL_PIN(MX25_PAD_CSI_D7),
+	IMX_PINCTRL_PIN(MX25_PAD_CSI_D8),
+	IMX_PINCTRL_PIN(MX25_PAD_CSI_D9),
+	IMX_PINCTRL_PIN(MX25_PAD_CSI_MCLK),
+	IMX_PINCTRL_PIN(MX25_PAD_CSI_VSYNC),
+	IMX_PINCTRL_PIN(MX25_PAD_CSI_HSYNC),
+	IMX_PINCTRL_PIN(MX25_PAD_CSI_PIXCLK),
+	IMX_PINCTRL_PIN(MX25_PAD_I2C1_CLK),
+	IMX_PINCTRL_PIN(MX25_PAD_I2C1_DAT),
+	IMX_PINCTRL_PIN(MX25_PAD_CSPI1_MOSI),
+	IMX_PINCTRL_PIN(MX25_PAD_CSPI1_MISO),
+	IMX_PINCTRL_PIN(MX25_PAD_CSPI1_SS0),
+	IMX_PINCTRL_PIN(MX25_PAD_CSPI1_SS1),
+	IMX_PINCTRL_PIN(MX25_PAD_CSPI1_SCLK),
+	IMX_PINCTRL_PIN(MX25_PAD_CSPI1_RDY),
+	IMX_PINCTRL_PIN(MX25_PAD_UART1_RXD),
+	IMX_PINCTRL_PIN(MX25_PAD_UART1_TXD),
+	IMX_PINCTRL_PIN(MX25_PAD_UART1_RTS),
+	IMX_PINCTRL_PIN(MX25_PAD_UART1_CTS),
+	IMX_PINCTRL_PIN(MX25_PAD_UART2_RXD),
+	IMX_PINCTRL_PIN(MX25_PAD_UART2_TXD),
+	IMX_PINCTRL_PIN(MX25_PAD_UART2_RTS),
+	IMX_PINCTRL_PIN(MX25_PAD_UART2_CTS),
+	IMX_PINCTRL_PIN(MX25_PAD_SD1_CMD),
+	IMX_PINCTRL_PIN(MX25_PAD_SD1_CLK),
+	IMX_PINCTRL_PIN(MX25_PAD_SD1_DATA0),
+	IMX_PINCTRL_PIN(MX25_PAD_SD1_DATA1),
+	IMX_PINCTRL_PIN(MX25_PAD_SD1_DATA2),
+	IMX_PINCTRL_PIN(MX25_PAD_SD1_DATA3),
+	IMX_PINCTRL_PIN(MX25_PAD_KPP_ROW0),
+	IMX_PINCTRL_PIN(MX25_PAD_KPP_ROW1),
+	IMX_PINCTRL_PIN(MX25_PAD_KPP_ROW2),
+	IMX_PINCTRL_PIN(MX25_PAD_KPP_ROW3),
+	IMX_PINCTRL_PIN(MX25_PAD_KPP_COL0),
+	IMX_PINCTRL_PIN(MX25_PAD_KPP_COL1),
+	IMX_PINCTRL_PIN(MX25_PAD_KPP_COL2),
+	IMX_PINCTRL_PIN(MX25_PAD_KPP_COL3),
+	IMX_PINCTRL_PIN(MX25_PAD_FEC_MDC),
+	IMX_PINCTRL_PIN(MX25_PAD_FEC_MDIO),
+	IMX_PINCTRL_PIN(MX25_PAD_FEC_TDATA0),
+	IMX_PINCTRL_PIN(MX25_PAD_FEC_TDATA1),
+	IMX_PINCTRL_PIN(MX25_PAD_FEC_TX_EN),
+	IMX_PINCTRL_PIN(MX25_PAD_FEC_RDATA0),
+	IMX_PINCTRL_PIN(MX25_PAD_FEC_RDATA1),
+	IMX_PINCTRL_PIN(MX25_PAD_FEC_RX_DV),
+	IMX_PINCTRL_PIN(MX25_PAD_FEC_TX_CLK),
+	IMX_PINCTRL_PIN(MX25_PAD_RTCK),
+	IMX_PINCTRL_PIN(MX25_PAD_DE_B),
+	IMX_PINCTRL_PIN(MX25_PAD_GPIO_A),
+	IMX_PINCTRL_PIN(MX25_PAD_GPIO_B),
+	IMX_PINCTRL_PIN(MX25_PAD_GPIO_C),
+	IMX_PINCTRL_PIN(MX25_PAD_GPIO_D),
+	IMX_PINCTRL_PIN(MX25_PAD_GPIO_E),
+	IMX_PINCTRL_PIN(MX25_PAD_GPIO_F),
+	IMX_PINCTRL_PIN(MX25_PAD_EXT_ARMCLK),
+	IMX_PINCTRL_PIN(MX25_PAD_UPLL_BYPCLK),
+	IMX_PINCTRL_PIN(MX25_PAD_VSTBY_REQ),
+	IMX_PINCTRL_PIN(MX25_PAD_VSTBY_ACK),
+	IMX_PINCTRL_PIN(MX25_PAD_POWER_FAIL),
+	IMX_PINCTRL_PIN(MX25_PAD_CLKO),
+	IMX_PINCTRL_PIN(MX25_PAD_BOOT_MODE0),
+	IMX_PINCTRL_PIN(MX25_PAD_BOOT_MODE1),
+};
+
+static struct imx_pinctrl_soc_info imx25_pinctrl_info = {
+	.pins = imx25_pinctrl_pads,
+	.npins = ARRAY_SIZE(imx25_pinctrl_pads),
+};
+
+static struct of_device_id imx25_pinctrl_of_match[] = {
+	{ .compatible = "fsl,imx25-iomuxc", },
+	{ /* sentinel */ }
+};
+
+static int imx25_pinctrl_probe(struct platform_device *pdev)
+{
+	return imx_pinctrl_probe(pdev, &imx25_pinctrl_info);
+}
+
+static struct platform_driver imx25_pinctrl_driver = {
+	.driver = {
+		.name = "imx25-pinctrl",
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(imx25_pinctrl_of_match),
+	},
+	.probe = imx25_pinctrl_probe,
+	.remove = imx_pinctrl_remove,
+};
+
+static int __init imx25_pinctrl_init(void)
+{
+	return platform_driver_register(&imx25_pinctrl_driver);
+}
+arch_initcall(imx25_pinctrl_init);
+
+static void __exit imx25_pinctrl_exit(void)
+{
+	platform_driver_unregister(&imx25_pinctrl_driver);
+}
+module_exit(imx25_pinctrl_exit);
+MODULE_AUTHOR("Denis Carikli <denis at eukrea.com>");
+MODULE_DESCRIPTION("Freescale IMX25 pinctrl driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:35 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:35 -0300
Subject: [RESEND PATCH v7 06/22] ARM: dove: Move to ID based window creation
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-7-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-dove/common.c | 68 ++++++++++++++++++++++++++++++---------------
 1 file changed, 45 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 00247c7..bc22056 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -27,6 +27,22 @@
 #include <plat/time.h>
 #include "common.h"
 
+/* These can go away once Dove uses the mvebu-mbus DT binding */
+#define DOVE_MBUS_PCIE0_MEM_TARGET    0x4
+#define DOVE_MBUS_PCIE0_MEM_ATTR      0xe8
+#define DOVE_MBUS_PCIE0_IO_TARGET     0x4
+#define DOVE_MBUS_PCIE0_IO_ATTR       0xe0
+#define DOVE_MBUS_PCIE1_MEM_TARGET    0x8
+#define DOVE_MBUS_PCIE1_MEM_ATTR      0xe8
+#define DOVE_MBUS_PCIE1_IO_TARGET     0x8
+#define DOVE_MBUS_PCIE1_IO_ATTR       0xe0
+#define DOVE_MBUS_CESA_TARGET         0x3
+#define DOVE_MBUS_CESA_ATTR           0x1
+#define DOVE_MBUS_BOOTROM_TARGET      0x1
+#define DOVE_MBUS_BOOTROM_ATTR        0xfd
+#define DOVE_MBUS_SCRATCHPAD_TARGET   0xd
+#define DOVE_MBUS_SCRATCHPAD_ATTR     0x0
+
 /*****************************************************************************
  * I/O Address Mapping
  ****************************************************************************/
@@ -332,34 +348,40 @@ void __init dove_setup_cpu_wins(void)
 {
 	/*
 	 * The PCIe windows will no longer be statically allocated
-	 * here once Dove is migrated to the pci-mvebu driver.
+	 * here once Dove is migrated to the pci-mvebu driver. The
+	 * non-PCIe windows will no longer be created here once Dove
+	 * fully moves to DT.
 	 */
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
+	mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE0_IO_TARGET,
+					  DOVE_MBUS_PCIE0_IO_ATTR,
 					  DOVE_PCIE0_IO_PHYS_BASE,
 					  DOVE_PCIE0_IO_SIZE,
-					  DOVE_PCIE0_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
+					  DOVE_PCIE0_IO_BUS_BASE);
+	mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE1_IO_TARGET,
+					  DOVE_MBUS_PCIE1_IO_ATTR,
 					  DOVE_PCIE1_IO_PHYS_BASE,
 					  DOVE_PCIE1_IO_SIZE,
-					  DOVE_PCIE1_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
-					  DOVE_PCIE0_MEM_PHYS_BASE,
-					  DOVE_PCIE0_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
-					  DOVE_PCIE1_MEM_PHYS_BASE,
-					  DOVE_PCIE1_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window("cesa", DOVE_CESA_PHYS_BASE,
-			      DOVE_CESA_SIZE);
-	mvebu_mbus_add_window("bootrom", DOVE_BOOTROM_PHYS_BASE,
-			      DOVE_BOOTROM_SIZE);
-	mvebu_mbus_add_window("scratchpad", DOVE_SCRATCHPAD_PHYS_BASE,
-			      DOVE_SCRATCHPAD_SIZE);
+					  DOVE_PCIE1_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE0_MEM_TARGET,
+				    DOVE_MBUS_PCIE0_MEM_ATTR,
+				    DOVE_PCIE0_MEM_PHYS_BASE,
+				    DOVE_PCIE0_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE1_MEM_TARGET,
+				    DOVE_MBUS_PCIE1_MEM_ATTR,
+				    DOVE_PCIE1_MEM_PHYS_BASE,
+				    DOVE_PCIE1_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_CESA_TARGET,
+				    DOVE_MBUS_CESA_ATTR,
+				    DOVE_CESA_PHYS_BASE,
+				    DOVE_CESA_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_BOOTROM_TARGET,
+				    DOVE_MBUS_BOOTROM_ATTR,
+				    DOVE_BOOTROM_PHYS_BASE,
+				    DOVE_BOOTROM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_SCRATCHPAD_TARGET,
+				    DOVE_MBUS_SCRATCHPAD_ATTR,
+				    DOVE_SCRATCHPAD_PHYS_BASE,
+				    DOVE_SCRATCHPAD_SIZE);
 }
 
 void __init dove_init(void)
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:39 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:39 -0300
Subject: [RESEND PATCH v7 10/22] bus: mvebu-mbus: Add new API for the PCIe
 memory and IO aperture
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-11-git-send-email-ezequiel.garcia@free-electrons.com>

We add two optional properties to the MBus DT binding, to encode
the PCIe memory and IO aperture. This allows such information to
be retrieved by -for instance- the pci driver to allocate the
MBus decoding windows.

Correspondingly, and in order to retrieve this information,
we add two new APIs.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 .../devicetree/bindings/bus/mvebu-mbus.txt         | 14 +++++++
 drivers/bus/mvebu-mbus.c                           | 49 ++++++++++++++++++++++
 include/linux/mbus.h                               |  4 ++
 3 files changed, 67 insertions(+)

diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
index cce863f..960186f 100644
--- a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -20,6 +20,18 @@ Required properties:
 		 registers that control the MBus, which is typically contained
 		 within the internal register window (see below).
 
+Optional properties:
+
+- pcie-mem-aperture:	This optional property contains the aperture for
+			the memory region of the PCIe driver.
+			If it's defined, it must encode the base address and
+			size for the address decoding windows allocated for
+			the PCIe memory region.
+
+- pcie-io-aperture:	Just as explained for the above property, this
+			optional property contains the aperture for the
+			I/O region of the PCIe driver.
+
 * Marvell MBus controller
 
 Required properties:
@@ -38,6 +50,8 @@ Example:
 		#address-cells = <2>;
 		#size-cells = <1>;
 		controller = <&mbusc>;
+		pcie-mem-aperture = <0xe0000000 0x8000000>;
+		pcie-io-aperture  = <0xe8000000 0x100000>;
 
 		internal-regs {
 			compatible = "simple-bus";
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 8aa3b45..5f0bfa3 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -142,6 +142,8 @@ struct mvebu_mbus_state {
 	struct dentry *debugfs_root;
 	struct dentry *debugfs_sdram;
 	struct dentry *debugfs_devs;
+	struct resource pcie_mem_aperture;
+	struct resource pcie_io_aperture;
 	const struct mvebu_mbus_soc_data *soc;
 	int hw_io_coherency;
 };
@@ -821,6 +823,20 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size)
 	return 0;
 }
 
+void mvebu_mbus_get_pcie_mem_aperture(struct resource *res)
+{
+	if (!res)
+		return;
+	*res = mbus_state.pcie_mem_aperture;
+}
+
+void mvebu_mbus_get_pcie_io_aperture(struct resource *res)
+{
+	if (!res)
+		return;
+	*res = mbus_state.pcie_io_aperture;
+}
+
 static __init int mvebu_mbus_debugfs_init(void)
 {
 	struct mvebu_mbus_state *s = &mbus_state;
@@ -1017,6 +1033,35 @@ static int __init mbus_dt_setup(struct mvebu_mbus_state *mbus,
 	return 0;
 }
 
+static void __init mvebu_mbus_get_pcie_resources(struct device_node *np,
+						 struct resource *mem,
+						 struct resource *io)
+{
+	u32 reg[2];
+	int ret;
+
+	/*
+	 * These are optional, so we clear them and they'll
+	 * be zero if they are missing from the DT.
+	 */
+	memset(mem, 0, sizeof(struct resource));
+	memset(io, 0, sizeof(struct resource));
+
+	ret = of_property_read_u32_array(np, "pcie-mem-aperture", reg, ARRAY_SIZE(reg));
+	if (!ret) {
+		mem->start = reg[0];
+		mem->end = mem->start + reg[1];
+		mem->flags = IORESOURCE_MEM;
+	}
+
+	ret = of_property_read_u32_array(np, "pcie-io-aperture", reg, ARRAY_SIZE(reg));
+	if (!ret) {
+		io->start = reg[0];
+		io->end = io->start + reg[1];
+		io->flags = IORESOURCE_IO;
+	}
+}
+
 int __init mvebu_mbus_dt_init(void)
 {
 	struct resource mbuswins_res, sdramwins_res;
@@ -1056,6 +1101,10 @@ int __init mvebu_mbus_dt_init(void)
 		return -EINVAL;
 	}
 
+	/* Get optional pcie-{mem,io}-aperture properties */
+	mvebu_mbus_get_pcie_resources(np, &mbus_state.pcie_mem_aperture,
+					  &mbus_state.pcie_io_aperture);
+
 	ret = mvebu_mbus_common_init(&mbus_state,
 				     mbuswins_res.start,
 				     resource_size(&mbuswins_res),
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index eadefd6..650bc15 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -11,6 +11,8 @@
 #ifndef __LINUX_MBUS_H
 #define __LINUX_MBUS_H
 
+struct resource;
+
 struct mbus_dram_target_info
 {
 	/*
@@ -59,6 +61,8 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
 }
 #endif
 
+void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
+void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
 int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 				      size_t size, phys_addr_t remap,
 				      unsigned int flags);
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:43 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:43 -0300
Subject: [RESEND PATCH v7 14/22] bus: mvebu-mbus: Update main description
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-15-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

After replacing the MBus name-based by the new ID-based API
let's fix the general description of the driver at the beginning
of the file.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index e13d475..f6e9192 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -35,13 +35,9 @@
  *
  * - Provides an API for platform code or device drivers to
  *   dynamically add or remove address decoding windows for the CPU ->
- *   device accesses. This API is mvebu_mbus_add_window(),
- *   mvebu_mbus_add_window_remap_flags() and
- *   mvebu_mbus_del_window(). Since the (target, attribute) values
- *   differ from one SoC family to another, the API uses a 'const char
- *   *' string to identify devices, and this driver is responsible for
- *   knowing the mapping between the name of a device and its
- *   corresponding (target, attribute) in the current SoC family.
+ *   device accesses. This API is mvebu_mbus_add_window_by_id(),
+ *   mvebu_mbus_add_window_remap_by_id() and
+ *   mvebu_mbus_del_window().
  *
  * - Provides a debugfs interface in /sys/kernel/debug/mvebu-mbus/ to
  *   see the list of CPU -> SDRAM windows and their configuration
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:48 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:48 -0300
Subject: [RESEND PATCH v7 19/22] ARM: mvebu: Add MBus to Armada 370/XP device
 tree
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-20-git-send-email-ezequiel.garcia@free-electrons.com>

The Armada 370/XP SoC family has a completely configurable address
space handled by the MBus controller.

This patch introduces the device tree layout of MBus, making the
'soc' node as mbus-compatible.
Since every peripheral/controller is a child of this 'soc' node,
this makes all of them sit behind the mbus, thus describing the
hardware accurately.

A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              |  2 ++
 arch/arm/boot/dts/armada-370-mirabox.dts         |  2 ++
 arch/arm/boot/dts/armada-370-rd.dts              |  2 ++
 arch/arm/boot/dts/armada-370-xp.dtsi             | 15 ++++++++++-----
 arch/arm/boot/dts/armada-370.dtsi                |  4 ++--
 arch/arm/boot/dts/armada-xp-db.dts               |  4 +---
 arch/arm/boot/dts/armada-xp-gp.dts               |  4 +---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  4 +---
 arch/arm/boot/dts/armada-xp.dtsi                 |  2 ++
 9 files changed, 23 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 55b986c..5920b4e 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,6 +30,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 37530af..a4202b6 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,6 +25,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index 7aa2171..dd0ba01 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,6 +28,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 90b1176..62639b4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -18,6 +18,8 @@
 
 /include/ "skeleton64.dtsi"
 
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
 / {
 	model = "Marvell Armada 370 and XP SoC";
 	compatible = "marvell,armada-370-xp";
@@ -38,18 +40,21 @@
 	};
 
 	soc {
-		#address-cells = <1>;
+		#address-cells = <2>;
 		#size-cells = <1>;
-		compatible = "simple-bus";
+		controller = <&mbusc>;
 		interrupt-parent = <&mpic>;
-		ranges = <0          0 0xd0000000 0x0100000 /* internal registers */
-			  0xe0000000 0 0xe0000000 0x8100000 /* PCIe */>;
 
 		internal-regs {
 			compatible = "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
-			ranges;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
 
 			mpic: interrupt-controller at 20000 {
 				compatible = "marvell,mpic";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 08ec6e3..4b54e51 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -29,8 +29,8 @@
 	};
 
 	soc {
-		ranges = <0          0xd0000000 0x0100000 /* internal registers */
-			  0xe0000000 0xe0000000 0x8100000 /* PCIe */>;
+		compatible = "marvell,armada370-mbus", "simple-bus";
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index a9bd766..0d4ce54 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,9 +30,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000	/* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000     /* PCIe */
-			  0xf0000000 0 0xf0000000 0x1000000>;	/* Device Bus, NOR 16MiB   */
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 54843e5..2fa9209 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,9 +39,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000  /* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000 /* PCIe */
-			  0xf0000000 0 0xf0000000 0x1000000 /* Device Bus, NOR 16MiB  */>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index d090264..a3e3a12 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,9 +27,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000	/* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000     /* PCIe */
-			  0xf0000000 0 0xf0000000 0x8000000     /* Device Bus, NOR 128MiB   */>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 8c07bfe..8033824 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -27,6 +27,8 @@
 	};
 
 	soc {
+		compatible = "marvell,armadaxp-mbus", "simple-bus";
+
 		internal-regs {
 			L2: l2-cache {
 				compatible = "marvell,aurora-system-cache";
-- 
1.8.1.5



From denis at eukrea.com  Mon Jul 15 10:56:51 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:51 +0200
Subject: [PATCH 06/22] arm/dts: i.MX25: Add ssi clocks and DMA events.
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-7-git-send-email-denis@eukrea.com>

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 arch/arm/boot/dts/imx25.dtsi |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index b318106..fb37111 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -293,6 +293,9 @@
 				compatible = "fsl,imx25-ssi", "fsl,imx21-ssi";
 				reg = <0x50014000 0x4000>;
 				interrupts = <11>;
+				clocks = <&clks 118>;
+				clock-names = "ssi2_ipg";
+				fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */
 				status = "disabled";
 			};
 
@@ -323,6 +326,9 @@
 				compatible = "fsl,imx25-ssi", "fsl,imx21-ssi";
 				reg = <0x50034000 0x4000>;
 				interrupts = <12>;
+				clocks = <&clks 117>;
+				clock-names = "ssi1_ipg";
+				fsl,ssi-dma-events = <29 28 27 26>; /* TX0 RX0 TX1 RX1 */
 				status = "disabled";
 			};
 
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:56:49 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:49 +0200
Subject: [PATCH 04/22] arm/dts: imx25.dtsi: Add some pinmux pins.
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-5-git-send-email-denis@eukrea.com>

Uart1, fec, i2c1,esdhc1 and audmux were added.

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 arch/arm/boot/dts/imx25.dtsi |   56 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index f098603..b318106 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -177,6 +177,62 @@
 			iomuxc at 43fac000{
 				compatible = "fsl,imx25-iomuxc";
 				reg = <0x43fac000 0x4000>;
+				audmux {
+					pinctrl_audmux_1: audmuxgrp-1 {
+						fsl,pins = <
+							MX25_PAD_KPP_COL3__AUD5_TXFS 0xe0
+							MX25_PAD_KPP_COL2__AUD5_TXC  0xe0
+							MX25_PAD_KPP_COL1__AUD5_RXD  0xe0
+							MX25_PAD_KPP_COL0__AUD5_TXD  0xe0
+						>;
+					};
+				};
+				uart1 {
+					pinctrl_uart1_1: uartgrp-1 {
+						fsl,pins = <
+							MX25_PAD_UART1_RTS__UART1_RTS 0xe0
+							MX25_PAD_UART1_CTS__UART1_CTS 0xe0
+							MX25_PAD_UART1_TXD__UART1_TXD 0x10000
+							MX25_PAD_UART1_RXD__UART1_RXD 0xc0
+						>;
+					};
+				};
+				fec {
+					pinctrl_fec_1: fecgrp-1 {
+						fsl,pins = <
+							MX25_PAD_FEC_MDC__FEC_MDC       0x10000
+							MX25_PAD_FEC_MDIO__FEC_MDIO     0x1f0
+							MX25_PAD_FEC_TDATA0__FEC_TDATA0 0x10000
+							MX25_PAD_FEC_TDATA1__FEC_TDATA1 0x10000
+							MX25_PAD_FEC_TX_EN__FEC_TX_EN   0x10000
+							MX25_PAD_FEC_RDATA0__FEC_RDATA0 0x100c0
+							MX25_PAD_FEC_RDATA1__FEC_RDATA1 0x100c0
+							MX25_PAD_FEC_RX_DV__FEC_RX_DV   0x100c0
+							MX25_PAD_FEC_TX_CLK__FEC_TX_CLK 0x1c0
+						>;
+					};
+
+				};
+				i2c1 {
+					pinctrl_i2c1_1: i2c1grp-1 {
+						fsl,pins = <
+							MX25_PAD_I2C1_CLK__I2C1_CLK 0x10000
+							MX25_PAD_I2C1_DAT__I2C1_DAT 0x10000
+						>;
+					};
+				};
+				esdhc1 {
+					pinctrl_esdhc1_1: esdhc1grp-1 {
+						fsl,pins = <
+							MX25_PAD_SD1_CMD__SD1_CMD      0xd0
+							MX25_PAD_SD1_CLK__SD1_CLK      0xd0
+							MX25_PAD_SD1_DATA0__SD1_DATA0  0xd0
+							MX25_PAD_SD1_DATA1__SD1_DATA1  0xd0
+							MX25_PAD_SD1_DATA2__SD1_DATA2  0xd0
+							MX25_PAD_SD1_DATA3__SD1_DATA3  0xd0
+						>;
+					};
+				};
 			};
 
 			audmux at 43fb0000 {
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:56:53 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:53 +0200
Subject: [PATCH 08/22] ASoC: eukrea-tlv320: Add DT support.
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-9-git-send-email-denis@eukrea.com>

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 sound/soc/fsl/Kconfig         |    5 +-
 sound/soc/fsl/eukrea-tlv320.c |  105 +++++++++++++++++++++++++++++++++--------
 2 files changed, 90 insertions(+), 20 deletions(-)

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index aa43854..de21f48 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -158,12 +158,15 @@ config SND_SOC_EUKREA_TLV320
 	depends on MACH_EUKREA_MBIMX27_BASEBOARD \
 		|| MACH_EUKREA_MBIMXSD25_BASEBOARD \
 		|| MACH_EUKREA_MBIMXSD35_BASEBOARD \
-		|| MACH_EUKREA_MBIMXSD51_BASEBOARD
+		|| MACH_EUKREA_MBIMXSD51_BASEBOARD \
+		|| OF
 	depends on I2C
 	select SND_SOC_TLV320AIC23
 	select SND_SOC_IMX_PCM_FIQ
 	select SND_SOC_IMX_AUDMUX
 	select SND_SOC_IMX_SSI
+	select SND_SOC_FSL_SSI
+	select SND_SOC_IMX_PCM_DMA
 	help
 	  Enable I2S based access to the TLV320AIC23B codec attached
 	  to the SSI interface
diff --git a/sound/soc/fsl/eukrea-tlv320.c b/sound/soc/fsl/eukrea-tlv320.c
index 9a4a0ca..090e1c9 100644
--- a/sound/soc/fsl/eukrea-tlv320.c
+++ b/sound/soc/fsl/eukrea-tlv320.c
@@ -17,6 +17,8 @@
 
 #include <linux/module.h>
 #include <linux/moduleparam.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
 #include <linux/device.h>
 #include <linux/i2c.h>
 #include <sound/core.h>
@@ -26,24 +28,33 @@
 
 #include "../codecs/tlv320aic23.h"
 #include "imx-ssi.h"
+#include "fsl_ssi.h"
 #include "imx-audmux.h"
 
 #define CODEC_CLOCK 12000000
 
+struct eukrea_tlv320 {
+	char of;
+};
+
 static int eukrea_tlv320_hw_params(struct snd_pcm_substream *substream,
 			    struct snd_pcm_hw_params *params)
 {
 	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct eukrea_tlv320 *priv = snd_soc_card_get_drvdata(rtd->card);
 	struct snd_soc_dai *codec_dai = rtd->codec_dai;
 	struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
 	int ret;
 
-	ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_I2S |
-				  SND_SOC_DAIFMT_NB_NF |
-				  SND_SOC_DAIFMT_CBM_CFM);
-	if (ret) {
-		pr_err("%s: failed set cpu dai format\n", __func__);
-		return ret;
+	/* fsl_ssi lacks the set_fmt ops. */
+	if (!priv->of) {
+		ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_I2S |
+					  SND_SOC_DAIFMT_NB_NF |
+					  SND_SOC_DAIFMT_CBM_CFM);
+		if (ret) {
+			pr_err("%s: failed set cpu dai format\n", __func__);
+			return ret;
+		}
 	}
 
 	ret = snd_soc_dai_set_fmt(codec_dai, SND_SOC_DAIFMT_I2S |
@@ -60,15 +71,18 @@ static int eukrea_tlv320_hw_params(struct snd_pcm_substream *substream,
 		pr_err("%s: failed setting codec sysclk\n", __func__);
 		return ret;
 	}
-	snd_soc_dai_set_tdm_slot(cpu_dai, 0xffffffc, 0xffffffc, 2, 0);
 
-	ret = snd_soc_dai_set_sysclk(cpu_dai, IMX_SSP_SYS_CLK, 0,
-				SND_SOC_CLOCK_IN);
-	if (ret) {
-		pr_err("can't set CPU system clock IMX_SSP_SYS_CLK\n");
-		return ret;
-	}
+	/* fsl_ssi lacks the set_sysclk ops */
+	if (!priv->of) {
+		snd_soc_dai_set_tdm_slot(cpu_dai, 0xffffffc, 0xffffffc, 2, 0);
 
+		ret = snd_soc_dai_set_sysclk(cpu_dai, IMX_SSP_SYS_CLK, 0,
+					SND_SOC_CLOCK_IN);
+		if (ret) {
+			pr_err("can't set CPU system clock IMX_SSP_SYS_CLK\n");
+			return ret;
+		}
+	}
 	return 0;
 }
 
@@ -80,7 +94,6 @@ static struct snd_soc_dai_link eukrea_tlv320_dai = {
 	.name		= "tlv320aic23",
 	.stream_name	= "TLV320AIC23",
 	.codec_dai_name	= "tlv320aic23-hifi",
-	.platform_name	= "imx-ssi.0",
 	.codec_name	= "tlv320aic23-codec.0-001a",
 	.cpu_dai_name	= "imx-ssi.0",
 	.ops		= &eukrea_tlv320_snd_ops,
@@ -97,8 +110,49 @@ static int eukrea_tlv320_probe(struct platform_device *pdev)
 {
 	int ret;
 	int int_port = 0, ext_port;
-
-	if (machine_is_eukrea_cpuimx27()) {
+	struct platform_device *ssi_pdev;
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *ssi_np;
+	struct eukrea_tlv320 *priv;
+
+	priv = devm_kzalloc(&pdev->dev,
+				sizeof(struct eukrea_tlv320), GFP_KERNEL);
+	if (priv == NULL)
+		return -ENOMEM;
+
+	if (np) {
+		ssi_np = of_parse_phandle(pdev->dev.of_node,
+					  "ssi-controller", 0);
+		ssi_pdev = of_find_device_by_node(ssi_np);
+
+		ret = of_property_read_u32(np, "mux-int-port", &int_port);
+		if (ret) {
+			dev_err(&pdev->dev,
+				"mux-int-port missing or invalid\n");
+			return ret;
+		}
+		ret = of_property_read_u32(np, "mux-ext-port", &ext_port);
+		if (ret) {
+			dev_err(&pdev->dev,
+				"mux-ext-port missing or invalid\n");
+			return ret;
+		}
+
+		/*
+		 * The port numbering in the hardware manual starts at 1, while
+		 * the audmux API expects it starts at 0.
+		 */
+		int_port--;
+		ext_port--;
+
+		eukrea_tlv320_dai.cpu_dai_name = dev_name(&ssi_pdev->dev);
+		eukrea_tlv320_dai.platform_of_node = ssi_np;
+		priv->of = 1;
+	} else
+		eukrea_tlv320_dai.platform_name = "imx-ssi.0";
+
+	if (machine_is_eukrea_cpuimx27() ||
+	    of_machine_is_compatible("fsl,eukrea_cpuimx27")) {
 		imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0,
 			IMX_AUDMUX_V1_PCR_SYN |
 			IMX_AUDMUX_V1_PCR_TFSDIR |
@@ -115,8 +169,14 @@ static int eukrea_tlv320_probe(struct platform_device *pdev)
 		);
 	} else if (machine_is_eukrea_cpuimx25sd() ||
 		   machine_is_eukrea_cpuimx35sd() ||
-		   machine_is_eukrea_cpuimx51sd()) {
-		ext_port = machine_is_eukrea_cpuimx25sd() ? 4 : 3;
+		   machine_is_eukrea_cpuimx51sd() ||
+		   of_machine_is_compatible("fsl,eukrea_cpuimx25") ||
+		   of_machine_is_compatible("fsl,eukrea_cpuimx35") ||
+		   of_machine_is_compatible("fsl,eukrea_cpuimx51")) {
+		ext_port = (machine_is_eukrea_cpuimx25sd() ||
+			    of_machine_is_compatible("fsl,eukrea_cpuimx25")) ?
+				4 : 3;
+
 		imx_audmux_v2_configure_port(int_port,
 			IMX_AUDMUX_V2_PTCR_SYN |
 			IMX_AUDMUX_V2_PTCR_TFSDIR |
@@ -133,8 +193,8 @@ static int eukrea_tlv320_probe(struct platform_device *pdev)
 		/* return happy. We might run on a totally different machine */
 		return 0;
 	}
-
 	eukrea_tlv320.dev = &pdev->dev;
+	snd_soc_card_set_drvdata(&eukrea_tlv320, priv);
 	ret = snd_soc_register_card(&eukrea_tlv320);
 	if (ret)
 		dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret);
@@ -149,10 +209,17 @@ static int eukrea_tlv320_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id imx_tlv320_dt_ids[] = {
+	{ .compatible = "fsl,eukrea-tlv320"},
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, imx_tlv320_dt_ids);
+
 static struct platform_driver eukrea_tlv320_driver = {
 	.driver = {
 		.name = "eukrea_tlv320",
 		.owner = THIS_MODULE,
+		.of_match_table = imx_tlv320_dt_ids,
 	},
 	.probe = eukrea_tlv320_probe,
 	.remove = eukrea_tlv320_remove,};
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:57:01 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:57:01 +0200
Subject: [PATCH 16/22] staging: drm/imx: ipuv3-crtc: don't harcode some mode
 flags.
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-17-git-send-email-denis@eukrea.com>

This change is needed for making the eukrea-cpuimx51
  QVGA display work.

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 drivers/staging/imx-drm/ipuv3-crtc.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c b/drivers/staging/imx-drm/ipuv3-crtc.c
index 9176a81..19502d8 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -235,9 +235,11 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
 		sig_cfg.Hsync_pol = 1;
 	if (mode->flags & DRM_MODE_FLAG_PVSYNC)
 		sig_cfg.Vsync_pol = 1;
+	if (mode->flags & DRM_MODE_FLAG_PDATEN)
+		sig_cfg.enable_pol = 1;
+	if (mode->flags & DRM_MODE_FLAG_PPIXDATEDGE)
+		sig_cfg.clk_pol = 1;
 
-	sig_cfg.enable_pol = 1;
-	sig_cfg.clk_pol = 0;
 	sig_cfg.width = mode->hdisplay;
 	sig_cfg.height = mode->vdisplay;
 	sig_cfg.pixel_fmt = out_pixel_fmt;
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:56:59 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:59 +0200
Subject: [PATCH 14/22] staging: imx-drm: use of_get_display_timings.
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-15-git-send-email-denis@eukrea.com>

The comment on top of of_get_drm_display_mode says:
 * This function is expensive and should only be used, if only one mode is to be
 * read from DT. To get multiple modes start with of_get_display_timings and
 * work with that instead.

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 drivers/staging/imx-drm/parallel-display.c |   24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-drm/parallel-display.c
index cea9f14..fee9b10 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -23,6 +23,8 @@
 #include <drm/drm_fb_helper.h>
 #include <drm/drm_crtc_helper.h>
 #include <linux/videodev2.h>
+#include <video/videomode.h>
+#include <video/of_display_timing.h>
 
 #include "imx-drm.h"
 
@@ -74,11 +76,23 @@ static int imx_pd_connector_get_modes(struct drm_connector *connector)
 
 	if (np) {
 		struct drm_display_mode *mode = drm_mode_create(connector->dev);
-		of_get_drm_display_mode(np, &imxpd->mode, 0);
-		drm_mode_copy(mode, &imxpd->mode);
-		mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
-		drm_mode_probed_add(connector, mode);
-		num_modes++;
+		struct display_timings *timings;
+		struct videomode vm;
+		int np_num_mode;
+
+		timings = of_get_display_timings(np);
+		for (np_num_mode = 0; np_num_mode < timings->num_timings;
+			np_num_mode++, num_modes++) {
+			if (videomode_from_timings(timings, &vm, np_num_mode))
+				break;
+			drm_display_mode_from_videomode(&vm, mode);
+			mode->type = DRM_MODE_TYPE_DRIVER;
+			if (timings->native_mode == np_num_mode)
+				mode->type |= DRM_MODE_TYPE_PREFERRED;
+
+			drm_mode_set_name(mode);
+			drm_mode_probed_add(connector, mode);
+		}
 	}
 
 	return num_modes;
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:56:47 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:56:47 +0200
Subject: [PATCH 02/22] arm/dts: imx25.dtsi: Add an alias for the LCD
 controller.
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-3-git-send-email-denis@eukrea.com>

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 arch/arm/boot/dts/imx25.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 6a1633d..4837849 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -393,7 +393,7 @@
 				status = "disabled";
 			};
 
-			lcdc at 53fbc000 {
+			lcdc: lcdc at 53fbc000 {
 				compatible = "fsl,imx21-lcdif";
 				reg = <0x53fbc000 0x4000>;
 				interrupts = <39>;
-- 
1.7.9.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:40 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:40 -0300
Subject: [RESEND PATCH v7 11/22] PCI: mvebu: Adapt to the new device tree
 layout
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-12-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

The new device tree layout encodes the window's target ID and attribute
in the PCIe controller node's ranges property. This allows to parse
such entries to obtain such information and use the recently introduced
MBus API to create the windows, instead of using the current name based
scheme.

Acked-by: Bjorn Helgaas <bhelgaas at google.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../devicetree/bindings/pci/mvebu-pci.txt          | 145 ++++++++++++++++-----
 drivers/pci/host/pci-mvebu.c                       | 113 +++++++++++-----
 2 files changed, 193 insertions(+), 65 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index f8d4058..9556e2f 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -1,6 +1,7 @@
 * Marvell EBU PCIe interfaces
 
 Mandatory properties:
+
 - compatible: one of the following values:
     marvell,armada-370-pcie
     marvell,armada-xp-pcie
@@ -10,11 +11,49 @@ Mandatory properties:
 - #interrupt-cells, set to <1>
 - bus-range: PCI bus numbers covered
 - device_type, set to "pci"
-- ranges: ranges for the PCI memory and I/O regions, as well as the
-  MMIO registers to control the PCIe interfaces.
+- ranges: ranges describing the MMIO registers to control the PCIe
+  interfaces, and ranges describing the MBus windows needed to access
+  the memory and I/O regions of each PCIe interface.
+
+The ranges describing the MMIO registers have the following layout:
+
+    0x82000000 0 r MBUS_ID(0xf0, 0x01) r 0 s
+
+where:
+
+  * r is a 32-bits value that gives the offset of the MMIO
+  registers of this PCIe interface, from the base of the internal
+  registers.
+
+  * s is a 32-bits value that give the size of this MMIO
+  registers area. This range entry translates the '0x82000000 0 r' PCI
+  address into the 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part
+  of the internal register window (as identified by MBUS_ID(0xf0,
+  0x01)).
+
+The ranges describing the MBus windows have the following layout:
+
+    0x8t000000 s 0     MBUS_ID(w, a) 0 1 0
+
+where:
+
+   * t is the type of the MBus window (as defined by the standard PCI DT
+   bindings), 1 for I/O and 2 for memory.
 
-In addition, the Device Tree node must have sub-nodes describing each
+   * s is the PCI slot that corresponds to this PCIe interface
+
+   * w is the 'target ID' value for the MBus window
+
+   * a the 'attribute' value for the MBus window.
+
+Since the location and size of the different MBus windows is not fixed in
+hardware, and only determined in runtime, those ranges cover the full first
+4 GB of the physical address space, and do not translate into a valid CPU
+address.
+
+In addition, the device tree node must have sub-nodes describing each
 PCIe interface, having the following mandatory properties:
+
 - reg: used only for interrupt mapping, so only the first four bytes
   are used to refer to the correct bus number and device number.
 - assigned-addresses: reference to the MMIO registers used to control
@@ -26,7 +65,8 @@ PCIe interface, having the following mandatory properties:
 - #address-cells, set to <3>
 - #size-cells, set to <2>
 - #interrupt-cells, set to <1>
-- ranges, empty property.
+- ranges, translating the MBus windows ranges of the parent node into
+  standard PCI addresses.
 - interrupt-map-mask and interrupt-map, standard PCI properties to
   define the mapping of the PCIe interface to interrupt numbers.
 
@@ -47,27 +87,50 @@ pcie-controller {
 
 	bus-range = <0x00 0xff>;
 
-	ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
-		  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
-		  0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
-		  0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
-		  0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
-		  0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
-		  0x82000000 0 0xd0082000 0xd0082000 0 0x00002000   /* Port 3.0 registers */
-		  0x82000000 0 0xd0084000 0xd0084000 0 0x00002000   /* Port 1.1 registers */
-		  0x82000000 0 0xd0088000 0xd0088000 0 0x00002000   /* Port 1.2 registers */
-		  0x82000000 0 0xd008c000 0xd008c000 0 0x00002000   /* Port 1.3 registers */
-		  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-		  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
+	ranges =
+	       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000	/* Port 0.0 registers */
+		0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000	/* Port 2.0 registers */
+		0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000	/* Port 0.1 registers */
+		0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000	/* Port 0.2 registers */
+		0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000	/* Port 0.3 registers */
+		0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000	/* Port 1.0 registers */
+		0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000	/* Port 3.0 registers */
+		0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000	/* Port 1.1 registers */
+		0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000	/* Port 1.2 registers */
+		0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000	/* Port 1.3 registers */
+		0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+		0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+		0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+		0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+		0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+		0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+		0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+		0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+
+		0x82000000 0x5 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
+		0x81000000 0x5 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
+		0x82000000 0x6 0     MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */
+		0x81000000 0x6 0     MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO  */
+		0x82000000 0x7 0     MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */
+		0x81000000 0x7 0     MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO  */
+		0x82000000 0x8 0     MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */
+		0x81000000 0x8 0     MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO  */
+
+		0x82000000 0x9 0     MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
+		0x81000000 0x9 0     MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */
+
+		0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
+		0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
 
 	pcie at 1,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+		assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
 		reg = <0x0800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+			  0x81000000 0 0 0x81000000 0x1 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 58>;
 		marvell,pcie-port = <0>;
@@ -78,12 +141,13 @@ pcie-controller {
 
 	pcie at 2,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>;
+		assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
 		reg = <0x1000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+			  0x81000000 0 0 0x81000000 0x2 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 59>;
 		marvell,pcie-port = <0>;
@@ -94,12 +158,13 @@ pcie-controller {
 
 	pcie at 3,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>;
+		assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
 		reg = <0x1800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+			  0x81000000 0 0 0x81000000 0x3 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 60>;
 		marvell,pcie-port = <0>;
@@ -110,12 +175,13 @@ pcie-controller {
 
 	pcie at 4,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>;
+		assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
 		reg = <0x2000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+			  0x81000000 0 0 0x81000000 0x4 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 61>;
 		marvell,pcie-port = <0>;
@@ -126,12 +192,13 @@ pcie-controller {
 
 	pcie at 5,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
+		assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
 		reg = <0x2800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
+			  0x81000000 0 0 0x81000000 0x5 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 62>;
 		marvell,pcie-port = <1>;
@@ -142,12 +209,13 @@ pcie-controller {
 
 	pcie at 6,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>;
+		assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
 		reg = <0x3000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0
+			  0x81000000 0 0 0x81000000 0x6 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 63>;
 		marvell,pcie-port = <1>;
@@ -158,12 +226,13 @@ pcie-controller {
 
 	pcie at 7,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>;
+		assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
 		reg = <0x3800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0
+			  0x81000000 0 0 0x81000000 0x7 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 64>;
 		marvell,pcie-port = <1>;
@@ -174,12 +243,13 @@ pcie-controller {
 
 	pcie at 8,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>;
+		assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
 		reg = <0x4000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0
+			  0x81000000 0 0 0x81000000 0x8 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 65>;
 		marvell,pcie-port = <1>;
@@ -187,14 +257,16 @@ pcie-controller {
 		clocks = <&gateclk 12>;
 		status = "disabled";
 	};
+
 	pcie at 9,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>;
+		assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
 		reg = <0x4800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+			  0x81000000 0 0 0x81000000 0x9 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 99>;
 		marvell,pcie-port = <2>;
@@ -205,12 +277,13 @@ pcie-controller {
 
 	pcie at 10,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>;
+		assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
 		reg = <0x5000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
+			  0x81000000 0 0 0x81000000 0xa 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 103>;
 		marvell,pcie-port = <3>;
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 13a633b..424a7b8 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -123,6 +123,10 @@ struct mvebu_pcie_port {
 	u32 port;
 	u32 lane;
 	int devfn;
+	unsigned int mem_target;
+	unsigned int mem_attr;
+	unsigned int io_target;
+	unsigned int io_attr;
 	struct clk *clk;
 	struct mvebu_sw_pci_bridge bridge;
 	struct device_node *dn;
@@ -307,10 +311,9 @@ static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port *port)
 			    (port->bridge.iolimitupper << 16)) -
 			    iobase);
 
-	mvebu_mbus_add_window_remap_flags(port->name, port->iowin_base,
-					  port->iowin_size,
-					  iobase,
-					  MVEBU_MBUS_PCI_IO);
+	mvebu_mbus_add_window_remap_by_id(port->io_target, port->io_attr,
+					  port->iowin_base, port->iowin_size,
+					  iobase);
 
 	pci_ioremap_io(iobase, port->iowin_base);
 }
@@ -342,10 +345,8 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
 		(((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) -
 		port->memwin_base;
 
-	mvebu_mbus_add_window_remap_flags(port->name, port->memwin_base,
-					  port->memwin_size,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+	mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr,
+				    port->memwin_base, port->memwin_size);
 }
 
 /*
@@ -755,12 +756,54 @@ mvebu_pcie_map_registers(struct platform_device *pdev,
 	return devm_request_and_ioremap(&pdev->dev, &regs);
 }
 
+#define DT_FLAGS_TO_TYPE(flags)       (((flags) >> 24) & 0x03)
+#define    DT_TYPE_IO                 0x1
+#define    DT_TYPE_MEM32              0x2
+#define DT_CPUADDR_TO_TARGET(cpuaddr) (((cpuaddr) >> 56) & 0xFF)
+#define DT_CPUADDR_TO_ATTR(cpuaddr)   (((cpuaddr) >> 48) & 0xFF)
+
+static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
+			      unsigned long type, int *tgt, int *attr)
+{
+	const int na = 3, ns = 2;
+	const __be32 *range;
+	int rlen, nranges, rangesz, pna, i;
+
+	range = of_get_property(np, "ranges", &rlen);
+	if (!range)
+		return -EINVAL;
+
+	pna = of_n_addr_cells(np);
+	rangesz = pna + na + ns;
+	nranges = rlen / sizeof(__be32) / rangesz;
+
+	for (i = 0; i < nranges; i++) {
+		u32 flags = of_read_number(range, 1);
+		u32 slot = of_read_number(range, 2);
+		u64 cpuaddr = of_read_number(range + na, pna);
+		unsigned long rtype;
+
+		if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_IO)
+			rtype = IORESOURCE_IO;
+		else if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_MEM32)
+			rtype = IORESOURCE_MEM;
+
+		if (slot == PCI_SLOT(devfn) && type == rtype) {
+			*tgt = DT_CPUADDR_TO_TARGET(cpuaddr);
+			*attr = DT_CPUADDR_TO_ATTR(cpuaddr);
+			return 0;
+		}
+
+		range += rangesz;
+	}
+
+	return -ENOENT;
+}
+
 static int __init mvebu_pcie_probe(struct platform_device *pdev)
 {
 	struct mvebu_pcie *pcie;
 	struct device_node *np = pdev->dev.of_node;
-	struct of_pci_range range;
-	struct of_pci_range_parser parser;
 	struct device_node *child;
 	int i, ret;
 
@@ -771,29 +814,25 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
 
 	pcie->pdev = pdev;
 
-	if (of_pci_range_parser_init(&parser, np))
+	/* Get the PCIe memory and I/O aperture */
+	mvebu_mbus_get_pcie_mem_aperture(&pcie->mem);
+	if (resource_size(&pcie->mem) == 0) {
+		dev_err(&pdev->dev, "invalid memory aperture size\n");
 		return -EINVAL;
+	}
 
-	/* Get the I/O and memory ranges from DT */
-	for_each_of_pci_range(&parser, &range) {
-		unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
-		if (restype == IORESOURCE_IO) {
-			of_pci_range_to_resource(&range, np, &pcie->io);
-			of_pci_range_to_resource(&range, np, &pcie->realio);
-			pcie->io.name = "I/O";
-			pcie->realio.start = max_t(resource_size_t,
-						   PCIBIOS_MIN_IO,
-						   range.pci_addr);
-			pcie->realio.end = min_t(resource_size_t,
-						 IO_SPACE_LIMIT,
-						 range.pci_addr + range.size);
-		}
-		if (restype == IORESOURCE_MEM) {
-			of_pci_range_to_resource(&range, np, &pcie->mem);
-			pcie->mem.name = "MEM";
-		}
+	mvebu_mbus_get_pcie_io_aperture(&pcie->io);
+	if (resource_size(&pcie->io) == 0) {
+		dev_err(&pdev->dev, "invalid I/O aperture size\n");
+		return -EINVAL;
 	}
 
+	pcie->realio.flags = pcie->io.flags;
+	pcie->realio.start = PCIBIOS_MIN_IO;
+	pcie->realio.end = min_t(resource_size_t,
+				  IO_SPACE_LIMIT,
+				  resource_size(&pcie->io));
+
 	/* Get the bus range */
 	ret = of_pci_parse_bus_range(np, &pcie->busn);
 	if (ret) {
@@ -841,6 +880,22 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
 		if (port->devfn < 0)
 			continue;
 
+		ret = mvebu_get_tgt_attr(np, port->devfn, IORESOURCE_MEM,
+					 &port->mem_target, &port->mem_attr);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "PCIe%d.%d: cannot get tgt/attr for mem window\n",
+				port->port, port->lane);
+			continue;
+		}
+
+		ret = mvebu_get_tgt_attr(np, port->devfn, IORESOURCE_IO,
+					 &port->io_target, &port->io_attr);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "PCIe%d.%d: cannot get tgt/attr for io window\n",
+				port->port, port->lane);
+			continue;
+		}
+
 		port->base = mvebu_pcie_map_registers(pdev, child, port);
 		if (!port->base) {
 			dev_err(&pdev->dev, "PCIe%d.%d: cannot map registers\n",
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:46 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:46 -0300
Subject: [RESEND PATCH v7 17/22] ARM: mvebu: Initialize MBus using the DT
 binding
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-18-git-send-email-ezequiel.garcia@free-electrons.com>

Now that the mbus device tree binding has been introduced, we can
switch over to it.

Also, and since the initialization of the mbus driver is quite
fundamental for the system to work properly, this patch adds a BUG()
in case mbus fails to initialize.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/mach-mvebu/armada-370-xp.c | 34 +---------------------------------
 1 file changed, 1 insertion(+), 33 deletions(-)

diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 97cbb80..829b573 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -34,44 +34,12 @@ static void __init armada_370_xp_map_io(void)
 	debug_ll_io_init();
 }
 
-/*
- * This initialization will be replaced by a DT-based
- * initialization once the mvebu-mbus driver gains DT support.
- */
-
-#define ARMADA_370_XP_MBUS_WINS_OFFS   0x20000
-#define ARMADA_370_XP_MBUS_WINS_SIZE   0x100
-#define ARMADA_370_XP_SDRAM_WINS_OFFS  0x20180
-#define ARMADA_370_XP_SDRAM_WINS_SIZE  0x20
-
-static void __init armada_370_xp_mbus_init(void)
-{
-	char *mbus_soc_name;
-	struct device_node *dn;
-	const __be32 mbus_wins_offs = cpu_to_be32(ARMADA_370_XP_MBUS_WINS_OFFS);
-	const __be32 sdram_wins_offs = cpu_to_be32(ARMADA_370_XP_SDRAM_WINS_OFFS);
-
-	if (of_machine_is_compatible("marvell,armada370"))
-		mbus_soc_name = "marvell,armada370-mbus";
-	else
-		mbus_soc_name = "marvell,armadaxp-mbus";
-
-	dn = of_find_node_by_name(NULL, "internal-regs");
-	BUG_ON(!dn);
-
-	mvebu_mbus_init(mbus_soc_name,
-			of_translate_address(dn, &mbus_wins_offs),
-			ARMADA_370_XP_MBUS_WINS_SIZE,
-			of_translate_address(dn, &sdram_wins_offs),
-			ARMADA_370_XP_SDRAM_WINS_SIZE);
-}
-
 static void __init armada_370_xp_timer_and_clk_init(void)
 {
 	of_clk_init(NULL);
 	armada_370_xp_timer_init();
 	coherency_init();
-	armada_370_xp_mbus_init();
+	BUG_ON(mvebu_mbus_dt_init());
 #ifdef CONFIG_CACHE_L2X0
 	l2x0_of_init(0, ~0UL);
 #endif
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:47 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:47 -0300
Subject: [RESEND PATCH v7 18/22] ARM: mvebu: Use the preprocessor on Armada
 370/XP device tree files
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-19-git-send-email-ezequiel.garcia@free-electrons.com>

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              | 2 +-
 arch/arm/boot/dts/armada-370-mirabox.dts         | 2 +-
 arch/arm/boot/dts/armada-370-rd.dts              | 2 +-
 arch/arm/boot/dts/armada-370.dtsi                | 2 +-
 arch/arm/boot/dts/armada-xp-db.dts               | 2 +-
 arch/arm/boot/dts/armada-xp-gp.dts               | 2 +-
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         | 2 +-
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         | 2 +-
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 2 +-
 arch/arm/boot/dts/armada-xp.dtsi                 | 2 +-
 10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index beee169..55b986c 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Marvell Armada 370 Evaluation Board";
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 45b1077..37530af 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -9,7 +9,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Globalscale Mirabox";
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index a3a2fed..7aa2171 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -12,7 +12,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Marvell Armada 370 Reference Design";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..08ec6e3 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -15,7 +15,7 @@
  * common to all Armada SoCs.
  */
 
-/include/ "armada-370-xp.dtsi"
+#include "armada-370-xp.dtsi"
 /include/ "skeleton.dtsi"
 
 / {
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index e28e68f..a9bd766 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78460.dtsi"
+#include "armada-xp-mv78460.dtsi"
 
 / {
 	model = "Marvell Armada XP Evaluation Board";
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index c87b2de..54843e5 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78460.dtsi"
+#include "armada-xp-mv78460.dtsi"
 
 / {
 	model = "Marvell Armada XP Development Board DB-MV784MP-GP";
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2d9335d..985373a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -13,7 +13,7 @@
  * common to all Armada XP SoCs.
  */
 
-/include/ "armada-xp.dtsi"
+#include "armada-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP MV78260 SoC";
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index c7b1f4d..f8bf25a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -13,7 +13,7 @@
  * common to all Armada XP SoCs.
  */
 
-/include/ "armada-xp.dtsi"
+#include "armada-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP MV78460 SoC";
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 8f51045..d090264 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -11,7 +11,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78260.dtsi"
+#include "armada-xp-mv78260.dtsi"
 
 / {
 	model = "PlatHome OpenBlocks AX3-4 board";
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 416eb94..8c07bfe 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -16,7 +16,7 @@
  * common to all Armada SoCs.
  */
 
-/include/ "armada-370-xp.dtsi"
+#include "armada-370-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP family SoC";
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:51 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:51 -0300
Subject: [RESEND PATCH v7 22/22] ARM: mvebu: Relocate Armada 370/XP PCIe
 device tree nodes
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-23-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.

Moving the PCIe nodes, we now need to introduce an extra cell to
encode the window target ID and attribute. Since this depends on
the PCIe port, we split the ranges translation entries, to correspond
to each MBus window.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-mirabox.dts         |  32 +-
 arch/arm/boot/dts/armada-370-xp.dtsi             |   2 +
 arch/arm/boot/dts/armada-370.dtsi                | 101 +++---
 arch/arm/boot/dts/armada-xp-db.dts               |  67 ++--
 arch/arm/boot/dts/armada-xp-gp.dts               |  42 +--
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         | 222 ++++++------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         | 261 ++++++++-------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         | 409 ++++++++++++-----------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  18 +-
 9 files changed, 612 insertions(+), 542 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 19341d2..2471d9d 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -28,6 +28,22 @@
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
 			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
+		pcie-controller {
+			status = "okay";
+
+			/* Internal mini-PCIe connector */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+
+			/* Connected on the PCB to a USB 3.0 XHCI controller */
+			pcie at 2,0 {
+				/* Port 1, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
@@ -123,22 +139,6 @@
 					reg = <0x25>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/* Internal mini-PCIe connector */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-
-				/* Connected on the PCB to a USB 3.0 XHCI controller */
-				pcie at 2,0 {
-					/* Port 1, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 073dd20..e984ce6 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -44,6 +44,8 @@
 		#size-cells = <1>;
 		controller = <&mbusc>;
 		interrupt-parent = <&mpic>;
+		pcie-mem-aperture = <0xe0000000 0x8000000>;
+		pcie-io-aperture  = <0xe8000000 0x100000>;
 
 		devbus-bootcs {
 			compatible = "marvell,mvebu-devbus";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index bd21d49..648e530 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -36,6 +36,59 @@
 			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
 		};
 
+		pcie-controller {
+			compatible = "marvell,armada-370-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0       1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0       1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0     MBUS_ID(0x08, 0xe8) 0       1 0 /* Port 1.0 MEM */
+				0x81000000 0x2 0     MBUS_ID(0x08, 0xe0) 0       1 0 /* Port 1.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+                                ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+                                          0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+                                ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+                                          0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 62>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 9>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
@@ -174,54 +227,6 @@
 					0x18304 0x4>;
 				status = "okay";
 			};
-
-			pcie-controller {
-				compatible = "marvell,armada-370-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 62>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 9>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 76ae1a9..bcf6d79 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -62,6 +62,39 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+
+			/*
+			 * All 6 slots are physically present as
+			 * standard PCIe slots on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+			pcie at 2,0 {
+				/* Port 0, Lane 1 */
+				status = "okay";
+			};
+			pcie at 3,0 {
+				/* Port 0, Lane 2 */
+				status = "okay";
+			};
+			pcie at 4,0 {
+				/* Port 0, Lane 3 */
+				status = "okay";
+			};
+			pcie at 9,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+			pcie at 10,0 {
+				/* Port 3, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -155,40 +188,6 @@
 					spi-max-frequency = <20000000>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/*
-				 * All 6 slots are physically present as
-				 * standard PCIe slots on the board.
-				 */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-				pcie at 2,0 {
-					/* Port 0, Lane 1 */
-					status = "okay";
-				};
-				pcie at 3,0 {
-					/* Port 0, Lane 2 */
-					status = "okay";
-				};
-				pcie at 4,0 {
-					/* Port 0, Lane 3 */
-					status = "okay";
-				};
-				pcie at 9,0 {
-					/* Port 2, Lane 0 */
-					status = "okay";
-				};
-				pcie at 10,0 {
-					/* Port 3, Lane 0 */
-					status = "okay";
-				};
-			};
-
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 8c0de20..2298e4a 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -71,6 +71,27 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+
+			/*
+			 * The 3 slots are physically present as
+			 * standard PCIe slots on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+			pcie at 9,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+			pcie at 10,0 {
+				/* Port 3, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -154,27 +175,6 @@
 					spi-max-frequency = <108000000>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/*
-				 * The 3 slots are physically present as
-				 * standard PCIe slots on the board.
-				 */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-				pcie at 9,0 {
-					/* Port 2, Lane 0 */
-					status = "okay";
-				};
-				pcie at 10,0 {
-					/* Port 3, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f8eaa38..f093e39 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -44,6 +44,124 @@
 	};
 
 	soc {
+		/*
+		 * MV78230 has 2 PCIe units Gen2.0: One unit can be
+		 * configured as x4 or quad x1 lanes. One unit is
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000000 0x1 0       MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0       MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0       MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+				0x81000000 0x2 0       MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+				0x82000000 0x3 0       MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+				0x81000000 0x3 0       MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+				0x82000000 0x4 0       MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+				0x81000000 0x4 0       MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+				0x82000000 0x9 0       MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
+				0x81000000 0x9 0       MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+					  0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+					  0x81000000 0 0 0x81000000 0x3 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+					  0x81000000 0 0 0x81000000 0x4 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+					  0x81000000 0 0 0x81000000 0x9 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78230-pinctrl";
@@ -77,110 +195,6 @@
 				#interrupts-cells = <2>;
 				interrupts = <87>, <88>, <89>;
 			};
-
-			/*
-			 * MV78230 has 2 PCIe units Gen2.0: One unit can be
-			 * configured as x4 or quad x1 lanes. One unit is
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-#address-cells = <3>;
-#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 985373a..6dc3921 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -45,6 +45,145 @@
 	};
 
 	soc {
+		/*
+		 * MV78260 has 3 PCIe units Gen2.0: Two units can be
+		 * configured as x4 or quad x1 lanes. One unit is
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000   /* Port 1.0 registers */
+				0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000   /* Port 3.0 registers */
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+				0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+				0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+				0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+				0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+				0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+				0x82000000 0x9 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
+				0x81000000 0x9 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
+				0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
+				0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+                                ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+                                          0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+					  0x81000000 0 0 0x81000000 0x3 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+					  0x81000000 0 0 0x81000000 0x4 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+					  0x81000000 0 0 0x81000000 0x9 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+
+			pcie at 10,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x82000 0 0x2000>;
+				reg = <0x5000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
+					  0x81000000 0 0 0x81000000 0xa 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 103>;
+				marvell,pcie-port = <3>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 27>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78260-pinctrl";
@@ -97,128 +236,6 @@
 				clocks = <&gateclk 1>;
 				status = "disabled";
 			};
-
-			/*
-			 * MV78260 has 3 PCIe units Gen2.0: Two units can be
-			 * configured as x4 or quad x1 lanes. One unit is
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-
-				pcie at 10,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x82000 0 0x2000>;
-					reg = <0x5000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 103>;
-					marvell,pcie-port = <3>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 27>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index f8bf25a..a6661e3 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -61,6 +61,227 @@
 	};
 
 	soc {
+		/*
+		 * MV78460 has 4 PCIe units Gen2.0: Two units can be
+		 * configured as x4 or quad x1 lanes. Two units are
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000   /* Port 1.0 registers */
+				0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000   /* Port 3.0 registers */
+				0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000   /* Port 1.1 registers */
+				0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000   /* Port 1.2 registers */
+				0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000   /* Port 1.3 registers */
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+				0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+				0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+				0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+				0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+				0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+
+				0x82000000 0x5 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
+				0x81000000 0x5 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
+				0x82000000 0x6 0     MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */
+				0x81000000 0x6 0     MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO  */
+				0x82000000 0x7 0     MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */
+				0x81000000 0x7 0     MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO  */
+				0x82000000 0x8 0     MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */
+				0x81000000 0x8 0     MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO  */
+
+				0x82000000 0x9 0     MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
+				0x81000000 0x9 0     MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */
+
+				0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
+				0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+					  0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+					  0x81000000 0 0 0x81000000 0x3 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+					  0x81000000 0 0 0x81000000 0x4 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 5,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
+				reg = <0x2800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
+					  0x81000000 0 0 0x81000000 0x5 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 62>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 9>;
+				status = "disabled";
+			};
+
+			pcie at 6,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
+				reg = <0x3000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0
+					  0x81000000 0 0 0x81000000 0x6 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 63>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 10>;
+				status = "disabled";
+			};
+
+			pcie at 7,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
+				reg = <0x3800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0
+					  0x81000000 0 0 0x81000000 0x7 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 64>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 11>;
+				status = "disabled";
+			};
+
+			pcie at 8,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
+				reg = <0x4000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0
+					  0x81000000 0 0 0x81000000 0x8 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 65>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 12>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+					  0x81000000 0 0 0x81000000 0x9 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+
+			pcie at 10,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
+				reg = <0x5000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
+					  0x81000000 0 0 0x81000000 0xa 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 103>;
+				marvell,pcie-port = <3>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 27>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78460-pinctrl";
@@ -113,194 +334,6 @@
 				clocks = <&gateclk 1>;
 				status = "disabled";
 			};
-
-			/*
-			 * MV78460 has 4 PCIe units Gen2.0: Two units can be
-			 * configured as x4 or quad x1 lanes. Two units are
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
-					0x82000000 0 0x84000 0x84000 0 0x00002000   /* Port 1.1 registers */
-					0x82000000 0 0x88000 0x88000 0 0x00002000   /* Port 1.2 registers */
-					0x82000000 0 0x8c000 0x8c000 0 0x00002000   /* Port 1.3 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 5,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
-					reg = <0x2800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 62>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 9>;
-					status = "disabled";
-				};
-
-				pcie at 6,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
-					reg = <0x3000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 63>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 10>;
-					status = "disabled";
-				};
-
-				pcie at 7,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
-					reg = <0x3800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 64>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 11>;
-					status = "disabled";
-				};
-
-				pcie at 8,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
-					reg = <0x4000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 65>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 12>;
-					status = "disabled";
-				};
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-
-				pcie at 10,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
-					reg = <0x5000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 103>;
-					marvell,pcie-port = <3>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 27>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 2b60ee0..5695afc 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -59,6 +59,15 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+			/* Internal mini-PCIe connector */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -176,15 +185,6 @@
 			usb at 51000 {
 				status = "okay";
 			};
-
-			pcie-controller {
-				status = "okay";
-				/* Internal mini-PCIe connector */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
-- 
1.8.1.5



From denis at eukrea.com  Mon Jul 15 10:57:06 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:57:06 +0200
Subject: [PATCH 21/22] DT: Add basic support for imx35-based devices.
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-22-git-send-email-denis@eukrea.com>

From: Steffen Trumtrar <s.trumtrar at pengutronix.de>

Signed-off-by: Steffen Trumtrar <s.trumtrar at pengutronix.de>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 arch/arm/boot/dts/imx35.dtsi         |  308 ++++++++++++++++++++++++++++++++++
 arch/arm/configs/imx_v6_v7_defconfig |    1 +
 arch/arm/mach-imx/Kconfig            |   11 ++
 arch/arm/mach-imx/Makefile           |    1 +
 arch/arm/mach-imx/clk-imx35.c        |   13 ++
 arch/arm/mach-imx/imx35-dt.c         |   48 ++++++
 6 files changed, 382 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx35.dtsi
 create mode 100644 arch/arm/mach-imx/imx35-dt.c

diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
new file mode 100644
index 0000000..012c1a3
--- /dev/null
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -0,0 +1,308 @@
+/*
+ * Copyright 2012 Steffen Trumtrar, Pengutronix
+ *
+ * based on imx27.dtsi
+ *
+ * This program is free software; you can redistribute it and/or modify it under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation.
+ */
+
+#include "skeleton.dtsi"
+#include "imx35-pinfunc.h"
+
+/ {
+	aliases {
+		serial0 = &uart1;
+		serial1 = &uart2;
+		serial2 = &uart3;
+		gpio0 = &gpio1;
+		gpio1 = &gpio2;
+		gpio2 = &gpio3;
+	};
+
+	avic: avic-interrupt-controller at 68000000 {
+		compatible = "fsl,imx35-avic", "fsl,avic";
+		interrupt-controller;
+		#interrupt-cells = <1>;
+		reg = <0x68000000 0x10000000>;
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ckil {
+			compatible = "fsl,imx-ckil", "fixed-clock";
+			clock-frequency = <32768>;
+		};
+
+		osc {
+			compatible = "fsl,imx-osc", "fixed-clock";
+			clock-frequency = <24000000>;
+		};
+	};
+
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		interrupt-parent = <&avic>;
+		ranges;
+
+		l2-cache at 30000000 {
+			compatible = "arm,l210-cache";
+			reg = <0x30000000 0x1000>;
+			cache-unified;
+			cache-level = <2>;
+		};
+
+		aips at 43f00000 { /* AIPS1 */
+			compatible = "fsl,aips", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0x43f00000 0x100000>;
+			ranges;
+
+			i2c1: i2c at 43f80000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "fsl,imx35-i2c", "fsl,imx1-i2c";
+				reg = <0x43f80000 0x4000>;
+				interrupts = <10>;
+				status = "disabled";
+			};
+
+			i2c3: i2c at 43f84000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "fsl,imx35-i2c", "fsl,imx1-i2c";
+				reg = <0x43f84000 0x4000>;
+				interrupts = <3>;
+				status = "disabled";
+			};
+
+			uart1: serial at 43f90000 {
+				compatible = "fsl,imx35-uart", "fsl,imx21-uart";
+				reg = <0x43f90000 0x4000>;
+				interrupts = <45>;
+				status = "disabled";
+			};
+
+			uart2: serial at 43f94000 {
+				compatible = "fsl,imx35-uart", "fsl,imx21-uart";
+				reg = <0x43f94000 0x4000>;
+				interrupts = <32>;
+				status = "disabled";
+			};
+
+			i2c2: i2c at 43f98000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "fsl,imx35-i2c", "fsl,imx1-i2c";
+				reg = <0x43f98000 0x4000>;
+				interrupts = <4>;
+				status = "disabled";
+			};
+
+			ssi1: ssi at 43fa0000 {
+				compatible = "fsl,imx35-ssi", "fsl,imx21-ssi";
+				reg = <0x43fa0000 0x4000>;
+				interrupts = <11>;
+				fsl,ssi-dma-events = <29 28 27 26>;
+				status = "disabled";
+			};
+
+			iomuxc at 43fac000 {
+				compatible = "fsl,imx35-iomuxc";
+				reg = <0x43fac000 0x4000>;
+
+				i2c1 {
+					pinctrl_i2c1_1: i2c1grp-1 {
+						fsl,pins = <
+								MX35_PAD_I2C1_CLK__I2C1_SCL 0x80000000
+								MX35_PAD_I2C1_DAT__I2C1_SDA 0x80000000
+						>;
+					};
+				};
+
+				i2c3 {
+					pinctrl_i2c3_1: i2c3grp-1 {
+						fsl,pins = <MX35_PAD_ATA_DATA12__I2C3_SCL 0x1c0
+							    MX35_PAD_ATA_DATA13__I2C3_SDA 0x1c0>;
+					};
+				};
+
+				can1 {
+					pinctrl_can1_1: can1grp-1 {
+						fsl,pins = <MX35_PAD_I2C2_CLK__CAN1_TXCAN 0x1c0
+							    MX35_PAD_I2C2_DAT__CAN1_RXCAN 0x1c0>;
+					};
+				};
+
+				can2 {
+					pinctrl_can2_1: can2grp-1 {
+						fsl,pins = <MX35_PAD_TX5_RX0__CAN2_TXCAN 0x1c0
+							MX35_PAD_TX4_RX1__CAN2_RXCAN 0x1c0>;
+					};
+				};
+
+				uart1 {
+					pinctrl_uart1_1: uart1grp-1 {
+						fsl,pins = <
+							MX35_PAD_CTS1__UART1_CTS 0x80000000
+							MX35_PAD_RTS1__UART1_RTS 0x80000000
+							MX35_PAD_TXD1__UART1_TXD_MUX 0x80000000
+							MX35_PAD_RXD1__UART1_RXD_MUX 0x80000000
+						>;
+					};
+				};
+
+				fec {
+					pinctrl_fec_1: fecgrp-1 {
+						fsl,pins = <
+							MX35_PAD_FEC_TX_CLK__FEC_TX_CLK 0x80000000
+							MX35_PAD_FEC_RX_CLK__FEC_RX_CLK 0x80000000
+							MX35_PAD_FEC_RX_DV__FEC_RX_DV 0x80000000
+							MX35_PAD_FEC_COL__FEC_COL 0x80000000
+							MX35_PAD_FEC_RDATA0__FEC_RDATA_0 0x80000000
+							MX35_PAD_FEC_TDATA0__FEC_TDATA_0 0x80000000
+							MX35_PAD_FEC_TX_EN__FEC_TX_EN 0x80000000
+							MX35_PAD_FEC_MDC__FEC_MDC 0x80000000
+							MX35_PAD_FEC_MDIO__FEC_MDIO 0x80000000
+							MX35_PAD_FEC_TX_ERR__FEC_TX_ERR 0x80000000
+							MX35_PAD_FEC_RX_ERR__FEC_RX_ERR 0x80000000
+							MX35_PAD_FEC_CRS__FEC_CRS 0x80000000
+							MX35_PAD_FEC_RDATA1__FEC_RDATA_1 0x80000000
+							MX35_PAD_FEC_TDATA1__FEC_TDATA_1 0x80000000
+							MX35_PAD_FEC_RDATA2__FEC_RDATA_2 0x80000000
+							MX35_PAD_FEC_TDATA2__FEC_TDATA_2 0x80000000
+							MX35_PAD_FEC_RDATA3__FEC_RDATA_3 0x80000000
+							MX35_PAD_FEC_TDATA3__FEC_TDATA_3 0x80000000
+						>;
+
+					};
+				};
+			};
+		};
+
+		spba at 50000000 {
+			compatible = "fsl,spba-bus", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0x50000000 0x100000>;
+			ranges;
+
+			uart3: serial at 5000c000 {
+				compatible = "fsl,imx35-uart", "fsl,imx21-uart";
+				reg = <0x5000c000 0x4000>;
+				interrupts = <18>;
+				status = "disabled";
+			};
+
+			fec: fec at 50038000 {
+				compatible = "fsl,imx35-fec", "fsl,imx27-fec";
+				reg = <0x50038000 0x4000>;
+				interrupts = <57>;
+				status = "disabled";
+			};
+		};
+
+		aips at 53f00000 { /* AIPS2 */
+			compatible = "fsl,aips", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0x53f00000 0x100000>;
+			ranges;
+
+			gpio3: gpio at 0x53fa4000 {
+				compatible = "fsl,imx35-gpio", "fsl,imx31-gpio";
+				reg = <0x53fa4000 0x4000>;
+				interrupts = <56>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupt-cells = <2>;
+			};
+
+			esdhc1: esdhc at 53fb4000 {
+				compatible = "fsl,mx35-sdhc";
+				reg = <0x53fb4000 0x4000>;
+				interrupts = <7>;
+				status = "disabled";
+			};
+
+			esdhc2: esdhc at 53fb8000 {
+				compatible = "fsl,mx35-sdhc";
+				reg = <0x53fb8000 0x4000>;
+				interrupts = <8>;
+				status = "disabled";
+			};
+
+			esdhc3: esdhc at 53fbc000 {
+				compatible = "fsl,mx35-sdhc";
+				reg = <0x53fbc000 0x4000>;
+				interrupts = <9>;
+				status = "disabled";
+			};
+
+			gpio1: gpio at 0x53fcc000 {
+				compatible = "fsl,imx35-gpio", "fsl,imx31-gpio";
+				reg = <0x53fcc000 0x4000>;
+				interrupts = <52>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupt-cells = <2>;
+			};
+
+			gpio2: gpio at 0x53fd0000 {
+				compatible = "fsl,imx35-gpio", "fsl,imx31-gpio";
+				reg = <0x53fd0000 0x4000>;
+				interrupts = <51>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				#interrupt-cells = <2>;
+			};
+
+			wdog at 53fdc000 {
+				compatible = "fsl,imx35-wdt", "fsl,imx2-wdt";
+				reg = <0x53fdc000 0x4000>;
+				interrupts = <55>;
+			};
+
+			can at 53fe4000 {
+				compatible = "fsl,imx35-flexcan", "fsl,p1010-flexcan";
+				reg = <0x53fe4000 0x1000>;
+				interrupts = <43>;
+				status = "disabled";
+			};
+
+			can at 53fe8000 {
+				compatible = "fsl,imx35-flexcan", "fsl,p1010-flexcan";
+				reg = <0x53fe8000 0x1000>;
+				interrupts = <44>;
+				status = "disabled";
+			};
+		};
+
+		emi at 80000000 { /* External Memory Interface */
+			compatible = "fsl,emi", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0x80000000 0x40000000>;
+			ranges;
+
+			nand: nand at bb000000 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+
+				compatible = "fsl,imx35-nand", "fsl,imx25-nand";
+				reg = <0xbb000000 0x2000>;
+				interrupts = <33>;
+				status = "disabled";
+			};
+		};
+	};
+};
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f1662d3..366b20d 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -32,6 +32,7 @@ CONFIG_MACH_ARMADILLO5X0=y
 CONFIG_MACH_KZM_ARM11_01=y
 CONFIG_MACH_PCM043=y
 CONFIG_MACH_MX35_3DS=y
+CONFIG_MACH_IMX35_DT=y
 CONFIG_MACH_VPR200=y
 CONFIG_MACH_IMX51_DT=y
 CONFIG_MACH_EUKREA_CPUIMX51SD=y
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index ed09a63..dc8f809 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -627,6 +627,17 @@ config MACH_IMX31_DT
 
 comment "MX35 platforms:"
 
+config MACH_IMX35_DT
+	bool "Support i.MX35 platforms from device tree"
+	select SOC_IMX35
+	select IMX_HAVE_PLATFORM_IMX2_WDT
+	select IMX_HAVE_PLATFORM_MXC_NAND
+	select PINCTRL
+	select PINCTRL_IMX35
+	help
+	  Include support for Freescale i.MX35 based platforms
+	  using the device tree for discovery.
+
 config MACH_PCM043
 	bool "Support Phytec pcm043 (i.MX35) platforms"
 	select IMX_HAVE_PLATFORM_FLEXCAN
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index e20f22d..3cb9d30 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_MACH_MX35_3DS) += mach-mx35_3ds.o
 obj-$(CONFIG_MACH_EUKREA_CPUIMX35SD) += mach-cpuimx35.o
 obj-$(CONFIG_MACH_EUKREA_MBIMXSD35_BASEBOARD) += eukrea_mbimxsd35-baseboard.o
 obj-$(CONFIG_MACH_VPR200) += mach-vpr200.o
+obj-$(CONFIG_MACH_IMX35_DT) += imx35-dt.o
 
 obj-$(CONFIG_HAVE_IMX_ANATOP) += anatop.o
 obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
diff --git a/arch/arm/mach-imx/clk-imx35.c b/arch/arm/mach-imx/clk-imx35.c
index 2193c83..b46375c 100644
--- a/arch/arm/mach-imx/clk-imx35.c
+++ b/arch/arm/mach-imx/clk-imx35.c
@@ -204,7 +204,9 @@ int __init mx35_clocks_init(void)
 				i, PTR_ERR(clk[i]));
 
 	clk_register_clkdev(clk[pata_gate], NULL, "pata_imx");
+	clk_register_clkdev(clk[can1_gate], NULL, "53fe4000.can");
 	clk_register_clkdev(clk[can1_gate], NULL, "flexcan.0");
+	clk_register_clkdev(clk[can2_gate], NULL, "53fe8000.can");
 	clk_register_clkdev(clk[can2_gate], NULL, "flexcan.1");
 	clk_register_clkdev(clk[cspi1_gate], "per", "imx35-cspi.0");
 	clk_register_clkdev(clk[cspi1_gate], "ipg", "imx35-cspi.0");
@@ -221,12 +223,16 @@ int __init mx35_clocks_init(void)
 	clk_register_clkdev(clk[esdhc3_gate], "per", "sdhci-esdhc-imx35.2");
 	clk_register_clkdev(clk[ipg], "ipg", "sdhci-esdhc-imx35.2");
 	clk_register_clkdev(clk[ahb], "ahb", "sdhci-esdhc-imx35.2");
+	clk_register_clkdev(clk[fec_gate], NULL, "50038000.fec");
 	/* i.mx35 has the i.mx27 type fec */
 	clk_register_clkdev(clk[fec_gate], NULL, "imx27-fec.0");
 	clk_register_clkdev(clk[gpt_gate], "per", "imx-gpt.0");
 	clk_register_clkdev(clk[ipg], "ipg", "imx-gpt.0");
+	clk_register_clkdev(clk[i2c1_gate], NULL, "43f80000.i2c");
 	clk_register_clkdev(clk[i2c1_gate], NULL, "imx21-i2c.0");
+	clk_register_clkdev(clk[i2c2_gate], NULL, "43f98000.i2c");
 	clk_register_clkdev(clk[i2c2_gate], NULL, "imx21-i2c.1");
+	clk_register_clkdev(clk[i2c3_gate], NULL, "43f84000.i2c");
 	clk_register_clkdev(clk[i2c3_gate], NULL, "imx21-i2c.2");
 	clk_register_clkdev(clk[ipu_gate], NULL, "ipu-core");
 	clk_register_clkdev(clk[ipu_gate], NULL, "mx3_sdc_fb");
@@ -235,6 +241,12 @@ int __init mx35_clocks_init(void)
 	clk_register_clkdev(clk[sdma_gate], NULL, "imx35-sdma");
 	clk_register_clkdev(clk[ssi1_gate], NULL, "imx-ssi.0");
 	clk_register_clkdev(clk[ssi2_gate], NULL, "imx-ssi.1");
+	clk_register_clkdev(clk[uart1_gate], "per", "43f90000.serial");
+	clk_register_clkdev(clk[ipg], "ipg", "43f90000.serial");
+	clk_register_clkdev(clk[uart2_gate], "per", "43f94000.serial");
+	clk_register_clkdev(clk[ipg], "ipg", "43f94000.serial");
+	clk_register_clkdev(clk[uart3_gate], "per", "5000c000.serial");
+	clk_register_clkdev(clk[ipg], "ipg", "5000c000.serial");
 	/* i.mx35 has the i.mx21 type uart */
 	clk_register_clkdev(clk[uart1_gate], "per", "imx21-uart.0");
 	clk_register_clkdev(clk[ipg], "ipg", "imx21-uart.0");
@@ -255,6 +267,7 @@ int __init mx35_clocks_init(void)
 	clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx27");
 	clk_register_clkdev(clk[usbotg_gate], "ahb", "imx-udc-mx27");
 	clk_register_clkdev(clk[wdog_gate], NULL, "imx2-wdt.0");
+	clk_register_clkdev(clk[nfc_div], NULL, "bb000000.nand");
 	clk_register_clkdev(clk[nfc_div], NULL, "imx25-nand.0");
 	clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0");
 	clk_register_clkdev(clk[admux_gate], "audmux", NULL);
diff --git a/arch/arm/mach-imx/imx35-dt.c b/arch/arm/mach-imx/imx35-dt.c
new file mode 100644
index 0000000..db8a1dd
--- /dev/null
+++ b/arch/arm/mach-imx/imx35-dt.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright 2012 Steffen Trumtrar, Pengutronix
+ *
+ * based on imx27-dt.c
+ *
+ * This program is free software; you can redistribute it and/or modify it under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation.
+ */
+
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/time.h>
+#include <asm/hardware/cache-l2x0.h>
+#include "common.h"
+#include "mx35.h"
+
+static void __init imx35_dt_init(void)
+{
+	l2x0_of_init(0x00030024, 0x00000000);
+
+	of_platform_populate(NULL, of_default_bus_match_table,
+			     NULL, NULL);
+}
+
+static void __init imx35_timer_init(void)
+{
+	mx35_clocks_init();
+}
+
+static const char *imx35_dt_board_compat[] __initdata = {
+	"fsl,imx35",
+	NULL
+};
+
+DT_MACHINE_START(IMX35_DT, "Freescale i.MX35 (Device Tree Support)")
+	.map_io		= mx35_map_io,
+	.init_early	= imx35_init_early,
+	.init_irq	= mx35_init_irq,
+	.handle_irq	= imx35_handle_irq,
+	.init_time      = imx35_timer_init,
+	.init_machine	= imx35_dt_init,
+	.dt_compat	= imx35_dt_board_compat,
+	.restart	= mxc_restart,
+MACHINE_END
-- 
1.7.9.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:42 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:42 -0300
Subject: [RESEND PATCH v7 13/22] bus: mvebu-mbus: Remove name -> target,
 attribute mapping tables
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-14-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

This tables were used together with the name-based MBus window
creation API. Since that's has been removed, we can also remove
the tables.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 150 +++--------------------------------------------
 1 file changed, 7 insertions(+), 143 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 9aee344..e13d475 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -97,33 +97,6 @@
 
 #define DOVE_DDR_BASE_CS_OFF(n) ((n) << 4)
 
-struct mvebu_mbus_mapping {
-	const char *name;
-	u8 target;
-	u8 attr;
-	u8 attrmask;
-};
-
-/*
- * Masks used for the 'attrmask' field of mvebu_mbus_mapping. They
- * allow to get the real attribute value, discarding the special bits
- * used to select a PCI MEM region or a PCI WA region. This allows the
- * debugfs code to reverse-match the name of a device from its
- * target/attr values.
- *
- * For all devices except PCI, all bits of 'attr' must be
- * considered. For most SoCs, only bit 3 should be ignored (it allows
- * to select between PCI MEM and PCI I/O). On Orion5x however, there
- * is the special bit 5 to select a PCI WA region.
- */
-#define MAPDEF_NOMASK       0xff
-#define MAPDEF_PCIMASK      0xf7
-#define MAPDEF_ORIONPCIMASK 0xd7
-
-/* Macro used to define one mvebu_mbus_mapping entry */
-#define MAPDEF(__n, __t, __a, __m) \
-	{ .name = __n, .target = __t, .attr = __a, .attrmask = __m }
-
 struct mvebu_mbus_state;
 
 struct mvebu_mbus_soc_data {
@@ -133,7 +106,6 @@ struct mvebu_mbus_soc_data {
 	void (*setup_cpu_target)(struct mvebu_mbus_state *s);
 	int (*show_cpu_target)(struct mvebu_mbus_state *s,
 			       struct seq_file *seq, void *v);
-	const struct mvebu_mbus_mapping *map;
 };
 
 struct mvebu_mbus_state {
@@ -430,8 +402,7 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void *v)
 		u64 wbase, wremap;
 		u32 wsize;
 		u8 wtarget, wattr;
-		int enabled, i;
-		const char *name;
+		int enabled;
 
 		mvebu_mbus_read_window(mbus, win,
 				       &enabled, &wbase, &wsize,
@@ -442,18 +413,9 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void *v)
 			continue;
 		}
 
-
-		for (i = 0; mbus->soc->map[i].name; i++)
-			if (mbus->soc->map[i].target == wtarget &&
-			    mbus->soc->map[i].attr ==
-			    (wattr & mbus->soc->map[i].attrmask))
-				break;
-
-		name = mbus->soc->map[i].name ?: "unknown";
-
-		seq_printf(seq, "[%02d] %016llx - %016llx : %s",
+		seq_printf(seq, "[%02d] %016llx - %016llx : %04x:%04x",
 			   win, (unsigned long long)wbase,
-			   (unsigned long long)(wbase + wsize), name);
+			   (unsigned long long)(wbase + wsize), wtarget, wattr);
 
 		if (win < mbus->soc->num_remappable_wins) {
 			seq_printf(seq, " (remap %016llx)\n",
@@ -578,45 +540,12 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
 	mvebu_mbus_dram_info.num_cs = cs;
 }
 
-static const struct mvebu_mbus_mapping armada_370_map[] = {
-	MAPDEF("bootrom",     1, 0xe0, MAPDEF_NOMASK),
-	MAPDEF("devbus-boot", 1, 0x2f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x3e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x3d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x3b, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs3",  1, 0x37, MAPDEF_NOMASK),
-	MAPDEF("pcie0.0",     4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",     8, 0xe0, MAPDEF_PCIMASK),
-	{},
-};
-
 static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
 	.num_wins            = 20,
 	.num_remappable_wins = 8,
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = armada_370_map,
-};
-
-static const struct mvebu_mbus_mapping armada_xp_map[] = {
-	MAPDEF("bootrom",     1, 0x1d, MAPDEF_NOMASK),
-	MAPDEF("devbus-boot", 1, 0x2f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x3e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x3d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x3b, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs3",  1, 0x37, MAPDEF_NOMASK),
-	MAPDEF("pcie0.0",     4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.1",     4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.2",     4, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.3",     4, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",     8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.1",     8, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.2",     8, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.3",     8, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie2.0",     4, 0xf0, MAPDEF_PCIMASK),
-	MAPDEF("pcie3.0",     8, 0xf0, MAPDEF_PCIMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
@@ -625,15 +554,6 @@ static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = armada_xp_map,
-};
-
-static const struct mvebu_mbus_mapping kirkwood_map[] = {
-	MAPDEF("pcie0.0", 4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0", 4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("sram",    3, 0x01, MAPDEF_NOMASK),
-	MAPDEF("nand",    1, 0x2f, MAPDEF_NOMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data kirkwood_mbus_data = {
@@ -642,16 +562,6 @@ static const struct mvebu_mbus_soc_data kirkwood_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = kirkwood_map,
-};
-
-static const struct mvebu_mbus_mapping dove_map[] = {
-	MAPDEF("pcie0.0",    0x4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",    0x8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("cesa",       0x3, 0x01, MAPDEF_NOMASK),
-	MAPDEF("bootrom",    0x1, 0xfd, MAPDEF_NOMASK),
-	MAPDEF("scratchpad", 0xd, 0x0, MAPDEF_NOMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data dove_mbus_data = {
@@ -660,18 +570,6 @@ static const struct mvebu_mbus_soc_data dove_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_dove_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_dove,
-	.map                 = dove_map,
-};
-
-static const struct mvebu_mbus_mapping orion5x_map[] = {
-	MAPDEF("pcie0.0",     4, 0x51, MAPDEF_ORIONPCIMASK),
-	MAPDEF("pci0.0",      3, 0x51, MAPDEF_ORIONPCIMASK),
-	MAPDEF("devbus-boot", 1, 0x0f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x1e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x1d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x1b, MAPDEF_NOMASK),
-	MAPDEF("sram",        0, 0x00, MAPDEF_NOMASK),
-	{},
 };
 
 /*
@@ -684,7 +582,6 @@ static const struct mvebu_mbus_soc_data orion5x_4win_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = orion5x_map,
 };
 
 static const struct mvebu_mbus_soc_data orion5x_2win_mbus_data = {
@@ -693,21 +590,6 @@ static const struct mvebu_mbus_soc_data orion5x_2win_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = orion5x_map,
-};
-
-static const struct mvebu_mbus_mapping mv78xx0_map[] = {
-	MAPDEF("pcie0.0", 4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.1", 4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.2", 4, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.3", 4, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0", 8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.1", 8, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.2", 8, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.3", 8, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie2.0", 4, 0xf0, MAPDEF_PCIMASK),
-	MAPDEF("pcie3.0", 8, 0xf0, MAPDEF_PCIMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
@@ -716,7 +598,6 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
 	.win_cfg_offset      = mv78xx0_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = mv78xx0_map,
 };
 
 /*
@@ -895,33 +776,16 @@ static int __init mbus_dt_setup_win(struct mvebu_mbus_state *mbus,
 				    u32 base, u32 size,
 				    u8 target, u8 attr)
 {
-	const struct mvebu_mbus_mapping *map = mbus->soc->map;
-	const char *name;
-	int i;
-
-	/* Search for a suitable window in the existing mappings */
-	for (i = 0; map[i].name; i++)
-		if (map[i].target == target &&
-		    map[i].attr == (attr & map[i].attrmask))
-			break;
-
-	name = map[i].name;
-	if (!name) {
-		pr_err("window 0x%x:0x%x is unknown, skipping\n",
-		       target, attr);
-		return -EINVAL;
-	}
-
 	if (!mvebu_mbus_window_conflicts(mbus, base, size, target, attr)) {
-		pr_err("cannot add window '%s', conflicts with another window\n",
-		       name);
+		pr_err("cannot add window '%04x:%04x', conflicts with another window\n",
+		       target, attr);
 		return -EBUSY;
 	}
 
 	if (mvebu_mbus_alloc_window(mbus, base, size, MVEBU_MBUS_NO_REMAP,
 				    target, attr)) {
-		pr_err("cannot add window '%s', too many windows\n",
-		       name);
+		pr_err("cannot add window '%04x:%04x', too many windows\n",
+		       target, attr);
 		return -ENOMEM;
 	}
 	return 0;
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:45 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:45 -0300
Subject: [RESEND PATCH v7 16/22] ARM: mvebu: Remove the harcoded BootROM
 window allocation
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-17-git-send-email-ezequiel.garcia@free-electrons.com>

The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/mach-mvebu/platsmp.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 93f2f3a..a952f8d 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -21,6 +21,7 @@
 #include <linux/smp.h>
 #include <linux/clk.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/mbus.h>
 #include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
@@ -29,6 +30,9 @@
 #include "pmsu.h"
 #include "coherency.h"
 
+#define AXP_BOOTROM_BASE 0xfff00000
+#define AXP_BOOTROM_SIZE 0x100000
+
 void __init set_secondary_cpus_clock(void)
 {
 	int thiscpu;
@@ -115,10 +119,29 @@ static void __init armada_xp_smp_init_cpus(void)
 
 void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
 {
+	struct device_node *node;
+	struct resource res;
+	int err;
+
 	set_secondary_cpus_clock();
 	flush_cache_all();
 	set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
-	mvebu_mbus_add_window("bootrom", 0xfff00000, SZ_1M);
+
+	/*
+	 * In order to boot the secondary CPUs we need to ensure
+	 * the bootROM is mapped at the correct address.
+	 */
+	node = of_find_compatible_node(NULL, NULL, "marvell,bootrom");
+	if (!node)
+		panic("Cannot find 'marvell,bootrom' compatible node");
+
+	err = of_address_to_resource(node, 0, &res);
+	if (err < 0)
+		panic("Cannot get 'bootrom' node address");
+
+	if (res.start != AXP_BOOTROM_BASE||
+	    resource_size(&res) != AXP_BOOTROM_SIZE)
+		panic("The address for the BootROM is incorrect");
 }
 
 struct smp_operations armada_xp_smp_ops __initdata = {
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:38 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:38 -0300
Subject: [RESEND PATCH v7 09/22] bus: mvebu-mbus: Add static window allocation
 to the DT binding
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-10-git-send-email-ezequiel.garcia@free-electrons.com>

This patch adds static window allocation to the device tree binding.
Each first-child of the mbus-compatible node, with a suitable 'ranges'
property, declaring an address translation, will trigger an address
decoding window allocation.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 .../devicetree/bindings/bus/mvebu-mbus.txt         | 253 +++++++++++++++++++++
 drivers/bus/mvebu-mbus.c                           | 121 +++++++++-
 2 files changed, 373 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt

diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
new file mode 100644
index 0000000..cce863f
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -0,0 +1,253 @@
+
+* Marvell MBus
+
+Required properties:
+
+- compatible:	 Should be set to one of the following:
+		 marvell,armada370-mbus
+		 marvell,armadaxp-mbus
+
+- address-cells: Must be '2'. The first cell for the MBus ID encoding,
+                 the second cell for the address offset within the window.
+
+- size-cells:    Must be '1'.
+
+- ranges:        Must be set up to provide a proper translation for each child.
+	         See the examples below.
+
+- controller:    Contains a single phandle referring to the MBus controller
+                 node. This allows to specify the node that contains the
+		 registers that control the MBus, which is typically contained
+		 within the internal register window (see below).
+
+* Marvell MBus controller
+
+Required properties:
+
+- compatible:	Should be set to "marvell,mbus-controller".
+
+- reg:          Device's register space.
+		Two entries are expected (see the examples below):
+		the first one controls the devices decoding window and
+		the second one controls the SDRAM decoding window.
+
+Example:
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+
+		internal-regs {
+			compatible = "simple-bus";
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* more children ...*/
+		};
+	};
+
+** MBus address decoding window specification
+
+The MBus children address space is comprised of two cells: the first one for
+the window ID and the second one for the offset within the window.
+In order to allow to describe valid and non-valid window entries, the
+following encoding is used:
+
+  0xSIAA0000 0x00oooooo
+
+Where:
+
+  S = 0x0 for a MBus valid window
+  S = 0xf for a non-valid window (see below)
+
+If S = 0x0, then:
+
+   I = 4-bit window target ID
+  AA = windpw attribute
+
+If S = 0xf, then:
+
+   I = don't care
+   AA = 1 for internal register
+
+Following the above encoding, for each ranges entry for a MBus valid window
+(S = 0x0), an address decoding window is allocated. On the other side,
+entries for translation that do not correspond to valid windows (S = 0xf)
+are skipped.
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+
+		ranges = <0xf0010000 0 0 0xd0000000 0x100000
+			  0x01e00000 0 0 0xfff00000 0x100000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <0x01e00000 0 0x100000>;
+		};
+
+		/* other children */
+		...
+
+		internal-regs {
+			compatible = "simple-bus";
+			ranges = <0 0xf0010000 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* more children ...*/
+		};
+	};
+
+In the shown example, the translation entry in the 'ranges' property is what
+makes the MBus driver create a static decoding window for the corresponding
+given child device. Note that the binding does not require child nodes to be
+present. Of course, child nodes are needed to probe the devices.
+
+Since each window is identified by its target ID and attribute ID there's
+a special macro that can be use to simplify the translation entries:
+
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
+Using this macro, the above example would be:
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+
+		ranges = < MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			   MBUS_ID(0x01, 0xe0) 0 0 0xfff00000 0x100000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
+		};
+
+		/* other children */
+		...
+
+		internal-regs {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* other children */
+			...
+		};
+	};
+
+
+** About the window base address
+
+Remember the MBus controller allows a great deal of flexibility for choosing
+the decoding window base address. When planning the device tree layout it's
+possible to choose any address as the base address, provided of course there's
+a region large enough available, and with the required alignment.
+
+Yet in other words: there's nothing preventing us from setting a base address
+of 0xf0000000, or 0xd0000000 for the NOR device shown above, if such region is
+unused.
+
+** Window allocation policy
+
+The mbus-node ranges property defines a set of mbus windows that are expected
+to be set by the operating system and that are guaranteed to be free of overlaps
+with one another or with the system memory ranges.
+
+Each entry in the property refers to exactly one window. If the operating system
+choses to use a different set of mbus windows, it must ensure that any address
+translations performed from downstream devices are adapted accordingly.
+
+The operating system may insert additional mbus windows that do not conflict
+with the ones listed in the ranges, e.g. for mapping PCIe devices.
+As a special case, the internal register window must be set up by the boot
+loader at the address listed in the ranges property, since access to that region
+is needed to set up the other windows.
+
+** Example
+
+See the example below, where a more complete device tree is shown:
+
+	soc {
+		compatible = "marvell,armadaxp-mbus", "simple-bus";
+		controller = <&mbusc>;
+
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
+		};
+
+		devbus-bootcs {
+			status = "okay";
+			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;
+
+			/* NOR */
+			nor {
+				compatible = "cfi-flash";
+				reg = <0 0x8000000>;
+				bank-width = <2>;
+			};
+		};
+
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "okay";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
+				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>;
+
+
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+		};
+
+		internal-regs {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			interrupt-controller at 20000 {
+			      reg = <0x20a00 0x2d0>, <0x21070 0x58>;
+			};
+		};
+	};
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 44a07c4..8aa3b45 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -902,6 +902,121 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 }
 
 #ifdef CONFIG_OF
+/*
+ * The window IDs in the ranges DT property have the following format:
+ *  - bits 28 to 31: MBus custom field
+ *  - bits 24 to 27: window target ID
+ *  - bits 16 to 23: window attribute ID
+ *  - bits  0 to 15: unused
+ */
+#define CUSTOM(id) (((id) & 0xF0000000) >> 24)
+#define TARGET(id) (((id) & 0x0F000000) >> 24)
+#define ATTR(id)   (((id) & 0x00FF0000) >> 16)
+
+static int __init mbus_dt_setup_win(struct mvebu_mbus_state *mbus,
+				    u32 base, u32 size,
+				    u8 target, u8 attr)
+{
+	const struct mvebu_mbus_mapping *map = mbus->soc->map;
+	const char *name;
+	int i;
+
+	/* Search for a suitable window in the existing mappings */
+	for (i = 0; map[i].name; i++)
+		if (map[i].target == target &&
+		    map[i].attr == (attr & map[i].attrmask))
+			break;
+
+	name = map[i].name;
+	if (!name) {
+		pr_err("window 0x%x:0x%x is unknown, skipping\n",
+		       target, attr);
+		return -EINVAL;
+	}
+
+	if (!mvebu_mbus_window_conflicts(mbus, base, size, target, attr)) {
+		pr_err("cannot add window '%s', conflicts with another window\n",
+		       name);
+		return -EBUSY;
+	}
+
+	if (mvebu_mbus_alloc_window(mbus, base, size, MVEBU_MBUS_NO_REMAP,
+				    target, attr)) {
+		pr_err("cannot add window '%s', too many windows\n",
+		       name);
+		return -ENOMEM;
+	}
+	return 0;
+}
+
+static int __init
+mbus_parse_ranges(struct device_node *node,
+		  int *addr_cells, int *c_addr_cells, int *c_size_cells,
+		  int *cell_count, const __be32 **ranges_start,
+		  const __be32 **ranges_end)
+{
+	const __be32 *prop;
+	int ranges_len, tuple_len;
+
+	*addr_cells = of_n_addr_cells(node);
+
+	prop = of_get_property(node, "#address-cells", NULL);
+	*c_addr_cells = be32_to_cpup(prop);
+
+	prop = of_get_property(node, "#size-cells", NULL);
+	*c_size_cells = be32_to_cpup(prop);
+
+	*cell_count = *addr_cells + *c_addr_cells + *c_size_cells;
+	tuple_len = (*cell_count) * sizeof(__be32);
+
+	*ranges_start = of_get_property(node, "ranges", &ranges_len);
+	*ranges_end = *ranges_start + ranges_len / sizeof(__be32);
+
+	if (*ranges_start == NULL || ranges_len % tuple_len) {
+		pr_warn("malformed ranges entry '%s'\n", node->name);
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static int __init mbus_dt_setup(struct mvebu_mbus_state *mbus,
+				struct device_node *np)
+{
+	int addr_cells, c_addr_cells, c_size_cells;
+	int i, ret, cell_count;
+	const __be32 *r, *ranges_start, *ranges_end;
+
+	ret = mbus_parse_ranges(np, &addr_cells, &c_addr_cells,
+				&c_size_cells, &cell_count,
+				&ranges_start, &ranges_end);
+	if (ret < 0)
+		return ret;
+
+	for (i = 0, r = ranges_start; r < ranges_end; r += cell_count, i++) {
+		u32 windowid, base, size;
+		u8 target, attr;
+
+		/*
+		 * An entry with a non-zero custom field do not
+		 * correspond to a static window, so skip it.
+		 */
+		windowid = of_read_number(r, 1);
+		if (CUSTOM(windowid))
+			continue;
+
+		target = TARGET(windowid);
+		attr = ATTR(windowid);
+
+		base = of_read_number(r + c_addr_cells, addr_cells);
+		size = of_read_number(r + c_addr_cells + addr_cells,
+				      c_size_cells);
+		ret = mbus_dt_setup_win(mbus, base, size, target, attr);
+		if (ret < 0)
+			return ret;
+	}
+	return 0;
+}
+
 int __init mvebu_mbus_dt_init(void)
 {
 	struct resource mbuswins_res, sdramwins_res;
@@ -946,6 +1061,10 @@ int __init mvebu_mbus_dt_init(void)
 				     resource_size(&mbuswins_res),
 				     sdramwins_res.start,
 				     resource_size(&sdramwins_res));
-	return ret;
+	if (ret)
+		return ret;
+
+	/* Setup statically declared windows in the DT */
+	return mbus_dt_setup(&mbus_state, np);
 }
 #endif
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:37 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:37 -0300
Subject: [RESEND PATCH v7 08/22] bus: mvebu-mbus: Introduce device tree binding
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-9-git-send-email-ezequiel.garcia@free-electrons.com>

This patch adds the most fundamental device-tree initialization.
We only introduce what's required to be able to probe the mvebu-mbus
driver from the DT. Follow-up patches will extend the device tree binding,
allowing to describe static address decoding windows.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mbus.h     |  1 +
 2 files changed, 50 insertions(+)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 1b17954..44a07c4 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -900,3 +900,52 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 			sdramwins_phys_base,
 			sdramwins_size);
 }
+
+#ifdef CONFIG_OF
+int __init mvebu_mbus_dt_init(void)
+{
+	struct resource mbuswins_res, sdramwins_res;
+	struct device_node *np, *controller;
+	const struct of_device_id *of_id;
+	const __be32 *prop;
+	int ret;
+
+	np = of_find_matching_node(NULL, of_mvebu_mbus_ids);
+	if (!np) {
+		pr_err("could not find a matching SoC family\n");
+		return -ENODEV;
+	}
+
+	of_id = of_match_node(of_mvebu_mbus_ids, np);
+	mbus_state.soc = of_id->data;
+
+	prop = of_get_property(np, "controller", NULL);
+	if (!prop) {
+		pr_err("required 'controller' property missing\n");
+		return -EINVAL;
+	}
+
+	controller = of_find_node_by_phandle(be32_to_cpup(prop));
+	if (!controller) {
+		pr_err("could not find an 'mbus-controller' node\n");
+		return -ENODEV;
+	}
+
+	if (of_address_to_resource(controller, 0, &mbuswins_res)) {
+		pr_err("cannot get MBUS register address\n");
+		return -EINVAL;
+	}
+
+	if (of_address_to_resource(controller, 1, &sdramwins_res)) {
+		pr_err("cannot get SDRAM register address\n");
+		return -EINVAL;
+	}
+
+	ret = mvebu_mbus_common_init(&mbus_state,
+				     mbuswins_res.start,
+				     resource_size(&mbuswins_res),
+				     sdramwins_res.start,
+				     resource_size(&sdramwins_res));
+	return ret;
+}
+#endif
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 9245b66..eadefd6 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -74,5 +74,6 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size);
 int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
 		    size_t mbus_size, phys_addr_t sdram_phys_base,
 		    size_t sdram_size);
+int mvebu_mbus_dt_init(void);
 
 #endif /* __LINUX_MBUS_H */
-- 
1.8.1.5



From dh.herrmann at gmail.com  Mon Jul 15 11:03:08 2013
From: dh.herrmann at gmail.com (David Herrmann)
Date: Mon, 15 Jul 2013 17:03:08 +0200
Subject: [PATCH] Route kbd LEDs through the generic LEDs layer
In-Reply-To: <20130707101028.GD5651@type.youpi.perso.aquilenet.fr>
References: <201011112205.oABM5KVJ005298@imap1.linux-foundation.org>
 <201011111440.07882.dmitry.torokhov@gmail.com>
 <20110102090935.GV32469@atrey.karlin.mff.cuni.cz>
 <20110102103210.GA25662@core.coreip.homeip.net>
 <20110102225741.GX5480@const.famille.thibault.fr>
 <20110112182702.GA9168@core.coreip.homeip.net>
 <20111114040613.GA4992@type.famille.thibault.fr>
 <20121221003449.GA6999@type.youpi.perso.aquilenet.fr>
 <20130707101028.GD5651@type.youpi.perso.aquilenet.fr>
Message-ID: <CANq1E4TRAOp+=w4oqPt4sjV7iLyDygxxpwrZy7dSB8UK288aNA@mail.gmail.com>

Hi

On Sun, Jul 7, 2013 at 12:10 PM, Samuel Thibault
<samuel.thibault at ens-lyon.org> wrote:
> This permits to reassign keyboard LEDs to something else than keyboard "leds"
> state, by adding keyboard led and modifier triggers connected to a series
> of VT input LEDs, themselves connected to VT input triggers, which
> per-input device LEDs use by default.  Userland can thus easily change the LED
> behavior of (a priori) all input devices, or of particular input devices.
>
> This also permits to fix #7063 from userland by using a modifier to implement
> proper CapsLock behavior and have the keyboard caps lock led show that modifier
> state.
>
> Signed-off-by: Samuel Thibault <samuel.thibault at ens-lyon.org>
> [ebroder at mokafive.com: Rebased to 3.2-rc1 or so, cleaned up some includes, and fixed some constants]
> Signed-off-by: Evan Broder <evan at ebroder.net>
>
> diff --exclude .svn -ur linux-3.10-orig/Documentation/leds/leds-class.txt linux-3.10-perso/Documentation/leds/leds-class.txt
> --- linux-3.10-orig/Documentation/leds/leds-class.txt   2013-04-29 13:27:16.959258613 +0200
> +++ linux-3.10-perso/Documentation/leds/leds-class.txt  2013-07-01 23:51:39.229318781 +0200
> @@ -2,9 +2,6 @@
>  LED handling under Linux
>  ========================
>
> -If you're reading this and thinking about keyboard leds, these are
> -handled by the input subsystem and the led class is *not* needed.
> -
>  In its simplest form, the LED class just allows control of LEDs from
>  userspace. LEDs appear in /sys/class/leds/. The maximum brightness of the
>  LED is defined in max_brightness file. The brightness file will set the brightness
> diff --exclude .svn -ur linux-3.10-orig/drivers/input/input.c linux-3.10-perso/drivers/input/input.c
> --- linux-3.10-orig/drivers/input/input.c       2013-04-29 13:27:16.959258613 +0200
> +++ linux-3.10-perso/drivers/input/input.c      2013-07-01 23:51:39.233318421 +0200
> @@ -28,6 +28,7 @@
>  #include <linux/mutex.h>
>  #include <linux/rcupdate.h>
>  #include "input-compat.h"
> +#include "leds.h"
>
>  MODULE_AUTHOR("Vojtech Pavlik <vojtech at suse.cz>");
>  MODULE_DESCRIPTION("Input core");
> @@ -708,6 +709,11 @@
>                 handle->open = 0;
>
>         spin_unlock_irq(&dev->event_lock);
> +
> +#ifdef CONFIG_INPUT_LEDS
> +       if (is_event_supported(EV_LED, dev->evbit, EV_MAX))
> +               input_led_disconnect(dev);
> +#endif

Please turn "input_led_disconnect()" into a dummy instead of #ifdef
around function calls. See below.

>  }
>
>  /**
> @@ -2092,6 +2098,11 @@
>
>         list_add_tail(&dev->node, &input_dev_list);
>
> +#ifdef CONFIG_INPUT_LEDS
> +       if (is_event_supported(EV_LED, dev->evbit, EV_MAX))
> +               input_led_connect(dev);
> +#endif
> +

Same as above.

>         list_for_each_entry(handler, &input_handler_list, node)
>                 input_attach_handler(dev, handler);
>
> diff --exclude .svn -ur linux-3.10-orig/drivers/input/Kconfig linux-3.10-perso/drivers/input/Kconfig
> --- linux-3.10-orig/drivers/input/Kconfig       2013-04-29 13:32:29.997497163 +0200
> +++ linux-3.10-perso/drivers/input/Kconfig      2013-07-01 23:51:39.233318421 +0200
> @@ -178,6 +178,15 @@
>
>  source "drivers/input/keyboard/Kconfig"
>
> +config INPUT_LEDS
> +       tristate "LED Support"
> +       depends on LEDS_CLASS
> +       select LEDS_TRIGGERS
> +       default y
> +       help
> +         This option enables support for the LEDs on keyboard managed

-the +keyboard_s_?

> +         by the input layer.
> +
>  source "drivers/input/mouse/Kconfig"
>
>  source "drivers/input/joystick/Kconfig"
> diff --exclude .svn -ur linux-3.10-orig/drivers/input/Makefile linux-3.10-perso/drivers/input/Makefile
> --- linux-3.10-orig/drivers/input/Makefile      2013-04-29 13:27:16.959258613 +0200
> +++ linux-3.10-perso/drivers/input/Makefile     2013-07-01 23:51:39.233318421 +0200
> @@ -18,6 +18,7 @@
>  obj-$(CONFIG_INPUT_EVBUG)      += evbug.o
>
>  obj-$(CONFIG_INPUT_KEYBOARD)   += keyboard/
> +obj-$(CONFIG_INPUT_LEDS)       += leds.o

Nitpick, but could you move it into the section above or below? This
section includes sub-directories only.

>  obj-$(CONFIG_INPUT_MOUSE)      += mouse/
>  obj-$(CONFIG_INPUT_JOYSTICK)   += joystick/
>  obj-$(CONFIG_INPUT_TABLET)     += tablet/
> diff --exclude .svn -ur linux-3.10-orig/drivers/leds/Kconfig linux-3.10-perso/drivers/leds/Kconfig
> --- linux-3.10-orig/drivers/leds/Kconfig        2013-07-01 01:56:00.335874214 +0200
> +++ linux-3.10-perso/drivers/leds/Kconfig       2013-07-01 23:51:39.233318421 +0200
> @@ -11,9 +11,6 @@
>           Say Y to enable Linux LED support.  This allows control of supported
>           LEDs from both userspace and optionally, by kernel events (triggers).
>
> -         This is not related to standard keyboard LEDs which are controlled
> -         via the input system.
> -
>  if NEW_LEDS
>
>  config LEDS_CLASS
> diff --exclude .svn -ur linux-3.10-orig/drivers/tty/Kconfig linux-3.10-perso/drivers/tty/Kconfig
> --- linux-3.10-orig/drivers/tty/Kconfig 2013-04-29 13:32:36.353298705 +0200
> +++ linux-3.10-perso/drivers/tty/Kconfig        2013-07-01 23:51:39.237318056 +0200
> @@ -13,6 +13,10 @@
>         bool "Virtual terminal" if EXPERT
>         depends on !S390 && !UML
>         select INPUT
> +       select NEW_LEDS
> +       select LEDS_CLASS
> +       select LEDS_TRIGGERS
> +       select INPUT_LEDS

This looks odd. Any dependency changes in the input-layer will break
this. But I guess that's what we get for a non-recursive "select". Hmm

>         default y
>         ---help---
>           If you say Y here, you will get support for terminal devices with
> diff --exclude .svn -ur linux-3.10-orig/drivers/tty/vt/keyboard.c linux-3.10-perso/drivers/tty/vt/keyboard.c
> --- linux-3.10-orig/drivers/tty/vt/keyboard.c   2013-04-29 13:32:36.681288463 +0200
> +++ linux-3.10-perso/drivers/tty/vt/keyboard.c  2013-07-01 23:51:39.237318056 +0200
> @@ -33,6 +33,7 @@
>  #include <linux/string.h>
>  #include <linux/init.h>
>  #include <linux/slab.h>
> +#include <linux/leds.h>
>
>  #include <linux/kbd_kern.h>
>  #include <linux/kbd_diacr.h>
> @@ -130,6 +131,7 @@
>  static int shift_state = 0;
>
>  static unsigned char ledstate = 0xff;                  /* undefined */
> +static unsigned char lockstate = 0xff;                 /* undefined */
>  static unsigned char ledioctl;
>
>  static struct ledptr {
> @@ -967,6 +969,32 @@
>         }
>  }
>
> +/* We route VT keyboard "leds" through triggers */
> +static void kbd_ledstate_trigger_activate(struct led_classdev *cdev);
> +static struct led_trigger ledtrig_ledstate[] = {
> +#define DEFINE_LEDSTATE_TRIGGER(kbd_led, nam) \
> +       [kbd_led] = { .name = nam, .activate = kbd_ledstate_trigger_activate, }
> +       DEFINE_LEDSTATE_TRIGGER(VC_SCROLLOCK, "scrollock"),
> +       DEFINE_LEDSTATE_TRIGGER(VC_NUMLOCK,   "numlock"),
> +       DEFINE_LEDSTATE_TRIGGER(VC_CAPSLOCK,  "capslock"),
> +       DEFINE_LEDSTATE_TRIGGER(VC_KANALOCK,  "kanalock"),
> +#undef DEFINE_LEDSTATE_TRIGGER
> +};
> +static void kbd_lockstate_trigger_activate(struct led_classdev *cdev);
> +static struct led_trigger ledtrig_lockstate[] = {
> +#define DEFINE_LOCKSTATE_TRIGGER(kbd_led, nam) \
> +       [kbd_led] = { .name = nam, .activate = kbd_lockstate_trigger_activate, }
> +       DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTLOCK,  "shiftlock"),
> +       DEFINE_LOCKSTATE_TRIGGER(VC_ALTGRLOCK,  "altgrlock"),
> +       DEFINE_LOCKSTATE_TRIGGER(VC_CTRLLOCK,   "ctrllock"),
> +       DEFINE_LOCKSTATE_TRIGGER(VC_ALTLOCK,    "altlock"),
> +       DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTLLOCK, "shiftllock"),
> +       DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTRLOCK, "shiftrlock"),
> +       DEFINE_LOCKSTATE_TRIGGER(VC_CTRLLLOCK,  "ctrlllock"),
> +       DEFINE_LOCKSTATE_TRIGGER(VC_CTRLRLOCK,  "ctrlrlock"),
> +#undef DEFINE_LOCKSTATE_TRIGGER
> +};
> +

We use empty lines between function-declarations and variable
declarations, I think. Would make this a lot easier to read. I also
think that the macros don't really simplify this. So:
  [VC_SHIFTLOCK] = { .name = "shiftlock", .activate =
kbd_lockstate_trigger_activate },
isn't much longer than:
  DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTLOCK,  "shiftlock"),
But I guess that's a matter of taste.

>  /*
>   * The leds display either (i) the status of NumLock, CapsLock, ScrollLock,
>   * or (ii) whatever pattern of lights people want to show using KDSETLED,
> @@ -1002,6 +1030,7 @@
>
>         leds = kbd->ledflagstate;
>
> +       /* TODO: should be replaced by a LED trigger */
>         if (kbd->ledmode == LED_SHOW_MEM) {
>                 for (i = 0; i < 3; i++)
>                         if (ledptrs[i].valid) {
> @@ -1014,18 +1043,24 @@
>         return leds;
>  }
>
> -static int kbd_update_leds_helper(struct input_handle *handle, void *data)
> +/* Called on trigger connection, to set initial state */
> +static void kbd_ledstate_trigger_activate(struct led_classdev *cdev)
>  {
> -       unsigned char leds = *(unsigned char *)data;
> +       struct led_trigger *trigger = cdev->trigger;
> +       int led = trigger - ledtrig_ledstate;
>
> -       if (test_bit(EV_LED, handle->dev->evbit)) {
> -               input_inject_event(handle, EV_LED, LED_SCROLLL, !!(leds & 0x01));
> -               input_inject_event(handle, EV_LED, LED_NUML,    !!(leds & 0x02));
> -               input_inject_event(handle, EV_LED, LED_CAPSL,   !!(leds & 0x04));
> -               input_inject_event(handle, EV_SYN, SYN_REPORT, 0);
> -       }
> +       tasklet_disable(&keyboard_tasklet);
> +       led_trigger_event(trigger, ledstate & (1 << led) ? LED_FULL : LED_OFF);
> +       tasklet_enable(&keyboard_tasklet);
> +}
> +static void kbd_lockstate_trigger_activate(struct led_classdev *cdev)
> +{
> +       struct led_trigger *trigger = cdev->trigger;
> +       int led = trigger - ledtrig_lockstate;
>
> -       return 0;
> +       tasklet_disable(&keyboard_tasklet);
> +       led_trigger_event(trigger, lockstate & (1 << led) ? LED_FULL : LED_OFF);
> +       tasklet_enable(&keyboard_tasklet);
>  }

Again, please add empty lines between functions definitions.

>
>  /**
> @@ -1120,10 +1155,24 @@
>         spin_unlock_irqrestore(&led_lock, flags);
>
>         if (leds != ledstate) {
> -               input_handler_for_each_handle(&kbd_handler, &leds,
> -                                             kbd_update_leds_helper);
> +               int i;

Move "int i;" to the top. You use it again below. gcc is smart enough
to notice that both usages are independent.

> +               for (i = 0; i < ARRAY_SIZE(ledtrig_ledstate); i++)
> +                       if ((leds ^ ledstate) & (1 << i))
> +                               led_trigger_event(&ledtrig_ledstate[i],
> +                                               leds & (1 << i)
> +                                               ? LED_FULL : LED_OFF);
>                 ledstate = leds;
>         }
> +
> +       if (kbd->lockstate != lockstate) {
> +               int i;
> +               for (i = 0; i < ARRAY_SIZE(ledtrig_lockstate); i++)
> +                       if ((kbd->lockstate ^ lockstate) & (1 << i))
> +                               led_trigger_event(&ledtrig_lockstate[i],
> +                                               kbd->lockstate & (1 << i)
> +                                               ? LED_FULL : LED_OFF);
> +               lockstate = kbd->lockstate;
> +       }
>  }
>
>  DECLARE_TASKLET_DISABLED(keyboard_tasklet, kbd_bh, 0);
> @@ -1461,20 +1510,6 @@
>         kfree(handle);
>  }
>
> -/*
> - * Start keyboard handler on the new keyboard by refreshing LED state to
> - * match the rest of the system.
> - */
> -static void kbd_start(struct input_handle *handle)
> -{
> -       tasklet_disable(&keyboard_tasklet);
> -
> -       if (ledstate != 0xff)
> -               kbd_update_leds_helper(handle, &ledstate);
> -
> -       tasklet_enable(&keyboard_tasklet);
> -}
> -
>  static const struct input_device_id kbd_ids[] = {
>         {
>                 .flags = INPUT_DEVICE_ID_MATCH_EVBIT,
> @@ -1496,7 +1531,6 @@
>         .match          = kbd_match,
>         .connect        = kbd_connect,
>         .disconnect     = kbd_disconnect,
> -       .start          = kbd_start,
>         .name           = "kbd",
>         .id_table       = kbd_ids,
>  };
> @@ -1520,6 +1554,11 @@
>         if (error)
>                 return error;
>
> +       for (i = 0; i < ARRAY_SIZE(ledtrig_ledstate); i++)
> +               led_trigger_register(&ledtrig_ledstate[i]);
> +       for (i = 0; i < ARRAY_SIZE(ledtrig_lockstate); i++)
> +               led_trigger_register(&ledtrig_lockstate[i]);
> +

This returns "int", are you sure no error-handling is needed?

>         tasklet_enable(&keyboard_tasklet);
>         tasklet_schedule(&keyboard_tasklet);
>
> diff --exclude .svn -ur linux-3.10-orig/include/linux/input.h linux-3.10-perso/include/linux/input.h
> --- linux-3.10-orig/include/linux/input.h       2013-04-29 13:27:16.959258613 +0200
> +++ linux-3.10-perso/include/linux/input.h      2013-07-01 23:51:39.241317685 +0200
> @@ -164,6 +164,8 @@
>         unsigned long snd[BITS_TO_LONGS(SND_CNT)];
>         unsigned long sw[BITS_TO_LONGS(SW_CNT)];
>
> +       struct led_classdev *leds;
> +
>         int (*open)(struct input_dev *dev);
>         void (*close)(struct input_dev *dev);
>         int (*flush)(struct input_dev *dev, struct file *file);
> --- linux-3.10-orig/drivers/input/leds.h        1970-01-01 01:00:00.000000000 +0100
> +++ linux-3.10-perso/drivers/input/leds.h       2011-11-14 02:24:26.738456456 +0100
> @@ -0,0 +1,14 @@
> +/*
> + * LED support for the input layer
> + *
> + * Copyright 2010-2013 Samuel Thibault <samuel.thibault at ens-lyon.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/input.h>
> +
> +extern int input_led_connect(struct input_dev *dev);
> +extern void input_led_disconnect(struct input_dev *dev);

Header-protection is missing. Besides, these 2 lines could be easily
merged into input.h. Any reason not to?
Also remove the "extern" before functions. It does not add any value
and we try to drop it for new declarations.

And you can avoid the #ifdef mentioned above if you use something like this:

#ifdef CONFIG_LEDS

int input_led_connect(struct input_dev *dev);
void input_led_disconnect(struct input_dev *dev);

#else

static inline int input_led_connect(struct input_dev *dev)
{
    return 0;
}

static inline void input_led_disconnect(struct input_dev *dev)
{
}

#endif

> --- linux-3.10-orig/drivers/input/leds.c        1970-01-01 01:00:00.000000000 +0100
> +++ linux-3.10-perso/drivers/input/leds.c       2011-11-14 03:23:07.578469395 +0100
> @@ -0,0 +1,243 @@
> +/*
> + * LED support for the input layer
> + *
> + * Copyright 2010-2013 Samuel Thibault <samuel.thibault at ens-lyon.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/leds.h>
> +#include <linux/input.h>

If you keep "input/leds.h" you should probably include it here. If you
drop it, you're fine.

> +
> +/*
> + * Keyboard LEDs are propagated by default like the following example:
> + *
> + * VT keyboard numlock trigger
> + * -> vt::numl VT LED
> + * -> vt-numl VT trigger

Nitpick: What's the reason for the syntax difference? "vt-numl" vs. "vt::numl"

> + * -> per-device inputx::numl LED

nitpick, but upper-case "X" is probably easier to understand. I had to
read it twice to get what the "x" means.

> + *
> + * Userland can however choose the trigger for the vt::numl LED, or
> + * independently choose the trigger for any inputx::numl LED.
> + */
> +
> +/* VT LED classes and triggers are registered on-demand according to
> + * existing LED devices */

Merge this comment with the comment above?

> +
> +/* Handler for VT LEDs, just triggers the corresponding VT trigger. */
> +static void vt_led_set(struct led_classdev *cdev,
> +                         enum led_brightness brightness);
> +static struct led_classdev vt_leds[LED_CNT] = {
> +#define DEFINE_INPUT_LED(vt_led, nam, deftrig) \
> +       [vt_led] = { \
> +               .name = "vt::"nam, \
> +               .max_brightness = 1, \
> +               .brightness_set = vt_led_set, \
> +               .default_trigger = deftrig, \
> +       }
> +/* Default triggers for the VT LEDs just correspond to the legacy
> + * usage. */
> +       DEFINE_INPUT_LED(LED_NUML, "numl", "numlock"),
> +       DEFINE_INPUT_LED(LED_CAPSL, "capsl", "capslock"),
> +       DEFINE_INPUT_LED(LED_SCROLLL, "scrolll", "scrollock"),
> +       DEFINE_INPUT_LED(LED_COMPOSE, "compose", NULL),
> +       DEFINE_INPUT_LED(LED_KANA, "kana", "kanalock"),
> +       DEFINE_INPUT_LED(LED_SLEEP, "sleep", NULL),
> +       DEFINE_INPUT_LED(LED_SUSPEND, "suspend", NULL),
> +       DEFINE_INPUT_LED(LED_MUTE, "mute", NULL),
> +       DEFINE_INPUT_LED(LED_MISC, "misc", NULL),
> +       DEFINE_INPUT_LED(LED_MAIL, "mail", NULL),
> +       DEFINE_INPUT_LED(LED_CHARGING, "charging", NULL),
> +};
> +static const char *const vt_led_names[LED_CNT] = {
> +       [LED_NUML] = "numl",
> +       [LED_CAPSL] = "capsl",
> +       [LED_SCROLLL] = "scrolll",
> +       [LED_COMPOSE] = "compose",
> +       [LED_KANA] = "kana",
> +       [LED_SLEEP] = "sleep",
> +       [LED_SUSPEND] = "suspend",
> +       [LED_MUTE] = "mute",
> +       [LED_MISC] = "misc",
> +       [LED_MAIL] = "mail",
> +       [LED_CHARGING] = "charging",
> +};
> +/* Handler for hotplug initialization */
> +static void vt_led_trigger_activate(struct led_classdev *cdev);
> +/* VT triggers */
> +static struct led_trigger vt_led_triggers[LED_CNT] = {
> +#define DEFINE_INPUT_LED_TRIGGER(vt_led, nam) \
> +       [vt_led] = { \
> +               .name = "vt-"nam, \
> +               .activate = vt_led_trigger_activate, \
> +       }
> +       DEFINE_INPUT_LED_TRIGGER(LED_NUML, "numl"),
> +       DEFINE_INPUT_LED_TRIGGER(LED_CAPSL, "capsl"),
> +       DEFINE_INPUT_LED_TRIGGER(LED_SCROLLL, "scrolll"),
> +       DEFINE_INPUT_LED_TRIGGER(LED_COMPOSE, "compose"),
> +       DEFINE_INPUT_LED_TRIGGER(LED_KANA, "kana"),
> +       DEFINE_INPUT_LED_TRIGGER(LED_SLEEP, "sleep"),
> +       DEFINE_INPUT_LED_TRIGGER(LED_SUSPEND, "suspend"),
> +       DEFINE_INPUT_LED_TRIGGER(LED_MUTE, "mute"),
> +       DEFINE_INPUT_LED_TRIGGER(LED_MISC, "misc"),
> +       DEFINE_INPUT_LED_TRIGGER(LED_MAIL, "mail"),
> +       DEFINE_INPUT_LED_TRIGGER(LED_CHARGING, "charging"),
> +};
> +/* Lock for registration coherency */
> +static DEFINE_MUTEX(vt_led_registered_lock);
> +/* Which VT LED classes and triggers are registered */
> +static unsigned long vt_led_registered[BITS_TO_LONGS(LED_CNT)];
> +/* Number of input devices having each LED */
> +static int vt_led_references[LED_CNT];

Please add some empty lines here. At least the different static arrays
should be separated by an empty newline.

> +
> +/* VT LED state change, tell the VT trigger.  */
> +static void vt_led_set(struct led_classdev *cdev,
> +                         enum led_brightness brightness)
> +{
> +       int led = cdev - vt_leds;
> +
> +       led_trigger_event(&vt_led_triggers[led], !!brightness);
> +}
> +
> +/* LED state change for some keyboard, notify that keyboard.  */
> +static void perdevice_input_led_set(struct led_classdev *cdev,
> +                         enum led_brightness brightness)
> +{
> +       struct input_dev *dev;
> +       struct led_classdev *leds;
> +       int led;
> +
> +       dev = cdev->dev->platform_data;
> +       if (!dev)
> +               /* Still initializing */
> +               return;
> +       leds = dev->leds;
> +       led = cdev - leds;
> +
> +       input_event(dev, EV_LED, led, !!brightness);
> +       input_event(dev, EV_SYN, SYN_REPORT, 0);
> +}
> +
> +/* Keyboard hotplug, initialize its LED status */
> +static void vt_led_trigger_activate(struct led_classdev *cdev)
> +{
> +       struct led_trigger *trigger = cdev->trigger;
> +       int led = trigger - vt_led_triggers;
> +
> +       if (cdev->brightness_set)
> +               cdev->brightness_set(cdev, vt_leds[led].brightness);
> +}
> +
> +/* Free led stuff from input device, used at abortion and disconnection.  */
> +static void input_led_delete(struct input_dev *dev)
> +{
> +       if (dev) {
> +               struct led_classdev *leds = dev->leds;
> +               if (leds) {
> +                       int i;
> +                       for (i = 0; i < LED_CNT; i++)
> +                               kfree(leds[i].name);
> +                       kfree(leds);
> +                       dev->leds = NULL;
> +               }
> +       }
> +}
> +
> +/* A new input device with potential LEDs to connect.  */
> +int input_led_connect(struct input_dev *dev)
> +{
> +       int i, error = 0;
> +       struct led_classdev *leds;
> +
> +       dev->leds = leds = kzalloc(sizeof(*leds) * LED_CNT, GFP_KERNEL);
> +       if (!dev->leds)
> +               return -ENOMEM;
> +
> +       /* lazily register missing VT LEDs */
> +       mutex_lock(&vt_led_registered_lock);
> +       for (i = 0; i < LED_CNT; i++)
> +               if (vt_leds[i].name && test_bit(i, dev->ledbit)) {
> +                       if (!vt_led_references[i]) {
> +                               led_trigger_register(&vt_led_triggers[i]);
> +                               /* This keyboard is first to have led i,
> +                                * try to register it */
> +                               if (!led_classdev_register(NULL, &vt_leds[i]))
> +                                       vt_led_references[i] = 1;
> +                               else
> +                                       led_trigger_unregister(&vt_led_triggers[i]);
> +                       } else
> +                               vt_led_references[i]++;
> +               }
> +       mutex_unlock(&vt_led_registered_lock);
> +
> +       /* and register this device's LEDs */
> +       for (i = 0; i < LED_CNT; i++)
> +               if (vt_leds[i].name && test_bit(i, dev->ledbit)) {
> +                       leds[i].name = kasprintf(GFP_KERNEL, "%s::%s",
> +                                               dev_name(&dev->dev),
> +                                               vt_led_names[i]);
> +                       if (!leds[i].name) {
> +                               error = -ENOMEM;
> +                               goto err;
> +                       }
> +                       leds[i].max_brightness = 1;
> +                       leds[i].brightness_set = perdevice_input_led_set;
> +                       leds[i].default_trigger = vt_led_triggers[i].name;
> +               }
> +
> +       /* No issue so far, we can register for real.  */
> +       for (i = 0; i < LED_CNT; i++)
> +               if (leds[i].name) {
> +                       led_classdev_register(&dev->dev, &leds[i]);
> +                       leds[i].dev->platform_data = dev;
> +                       perdevice_input_led_set(&leds[i],
> +                                       vt_leds[i].brightness);
> +               }
> +
> +       return 0;
> +
> +err:
> +       input_led_delete(dev);
> +       return error;
> +}
> +
> +/* Disconnected input device. Clean it, and deregister now-useless VT LEDs
> + * and triggers.  */
> +extern void input_led_disconnect(struct input_dev *dev)
> +{
> +       int i;
> +       struct led_classdev *leds = dev->leds;
> +
> +       for (i = 0; i < LED_CNT; i++)
> +               if (leds[i].name)
> +                       led_classdev_unregister(&leds[i]);
> +
> +       input_led_delete(dev);
> +
> +       mutex_lock(&vt_led_registered_lock);
> +       for (i = 0; i < LED_CNT; i++) {
> +               if (!vt_leds[i].name || !test_bit(i, dev->ledbit))
> +                       continue;
> +
> +               vt_led_references[i]--;
> +               if (vt_led_references[i]) {
> +                       /* Still some devices needing it */
> +                       continue;
> +               }
> +
> +               led_classdev_unregister(&vt_leds[i]);
> +               led_trigger_unregister(&vt_led_triggers[i]);
> +               clear_bit(i, vt_led_registered);
> +       }
> +       mutex_unlock(&vt_led_registered_lock);
> +}
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("User LED support for input layer");
> +MODULE_AUTHOR("Samuel Thibault <samuel.thibault at ens-lyon.org>");

I haven't done any locking review, yet, and some of the comments are
probably just a matter of taste. But the patch looks good.

Cheers
David

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:32 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:32 -0300
Subject: [RESEND PATCH v7 03/22] ARM: kirkwood: Move to ID based MBus window
 creation
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-4-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-kirkwood/common.c | 18 ++++++++++++++----
 arch/arm/mach-kirkwood/pcie.c   | 40 ++++++++++++++++++++++++----------------
 2 files changed, 38 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index e9238b5..165e751 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -37,6 +37,12 @@
 #include <linux/platform_data/dma-mv_xor.h>
 #include "common.h"
 
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_NAND_TARGET 0x01
+#define KIRKWOOD_MBUS_NAND_ATTR   0x2f
+#define KIRKWOOD_MBUS_SRAM_TARGET 0x03
+#define KIRKWOOD_MBUS_SRAM_ATTR   0x01
+
 /*****************************************************************************
  * I/O Address Mapping
  ****************************************************************************/
@@ -672,10 +678,14 @@ char * __init kirkwood_id(void)
 
 void __init kirkwood_setup_wins(void)
 {
-	mvebu_mbus_add_window("nand", KIRKWOOD_NAND_MEM_PHYS_BASE,
-			      KIRKWOOD_NAND_MEM_SIZE);
-	mvebu_mbus_add_window("sram", KIRKWOOD_SRAM_PHYS_BASE,
-			      KIRKWOOD_SRAM_SIZE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_NAND_TARGET,
+				    KIRKWOOD_MBUS_NAND_ATTR,
+				    KIRKWOOD_NAND_MEM_PHYS_BASE,
+				    KIRKWOOD_NAND_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_SRAM_TARGET,
+				    KIRKWOOD_MBUS_SRAM_ATTR,
+				    KIRKWOOD_SRAM_PHYS_BASE,
+				    KIRKWOOD_SRAM_SIZE);
 }
 
 void __init kirkwood_l2_init(void)
diff --git a/arch/arm/mach-kirkwood/pcie.c b/arch/arm/mach-kirkwood/pcie.c
index ddcb09f..12d86f3 100644
--- a/arch/arm/mach-kirkwood/pcie.c
+++ b/arch/arm/mach-kirkwood/pcie.c
@@ -20,6 +20,16 @@
 #include <mach/bridge-regs.h>
 #include "common.h"
 
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_PCIE0_MEM_TARGET    0x4
+#define KIRKWOOD_MBUS_PCIE0_MEM_ATTR      0xe8
+#define KIRKWOOD_MBUS_PCIE0_IO_TARGET     0x4
+#define KIRKWOOD_MBUS_PCIE0_IO_ATTR       0xe0
+#define KIRKWOOD_MBUS_PCIE1_MEM_TARGET    0x4
+#define KIRKWOOD_MBUS_PCIE1_MEM_ATTR      0xd8
+#define KIRKWOOD_MBUS_PCIE1_IO_TARGET     0x4
+#define KIRKWOOD_MBUS_PCIE1_IO_ATTR       0xd0
+
 static void kirkwood_enable_pcie_clk(const char *port)
 {
 	struct clk *clk;
@@ -254,26 +264,24 @@ static void __init add_pcie_port(int index, void __iomem *base)
 
 void __init kirkwood_pcie_init(unsigned int portmask)
 {
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
+	mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE0_IO_TARGET,
+					  KIRKWOOD_MBUS_PCIE0_IO_ATTR,
 					  KIRKWOOD_PCIE_IO_PHYS_BASE,
 					  KIRKWOOD_PCIE_IO_SIZE,
-					  KIRKWOOD_PCIE_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
-					  KIRKWOOD_PCIE_MEM_PHYS_BASE,
-					  KIRKWOOD_PCIE_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
+					  KIRKWOOD_PCIE_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_PCIE0_MEM_TARGET,
+				    KIRKWOOD_MBUS_PCIE0_MEM_ATTR,
+				    KIRKWOOD_PCIE_MEM_PHYS_BASE,
+				    KIRKWOOD_PCIE_MEM_SIZE);
+	mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE1_IO_TARGET,
+					  KIRKWOOD_MBUS_PCIE1_IO_ATTR,
 					  KIRKWOOD_PCIE1_IO_PHYS_BASE,
 					  KIRKWOOD_PCIE1_IO_SIZE,
-					  KIRKWOOD_PCIE1_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
-					  KIRKWOOD_PCIE1_MEM_PHYS_BASE,
-					  KIRKWOOD_PCIE1_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+					  KIRKWOOD_PCIE1_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_PCIE1_MEM_TARGET,
+				    KIRKWOOD_MBUS_PCIE1_MEM_ATTR,
+				    KIRKWOOD_PCIE1_MEM_PHYS_BASE,
+				    KIRKWOOD_PCIE1_MEM_SIZE);
 
 	vga_base = KIRKWOOD_PCIE_MEM_PHYS_BASE;
 
-- 
1.8.1.5



From denis at eukrea.com  Mon Jul 15 10:57:02 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:57:02 +0200
Subject: [PATCH 17/22] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-18-git-send-email-denis@eukrea.com>

That new macro is needed by the imx_drm staging driver
  for supporting the QVGA display of the eukrea-cpuimx51 board.

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 include/uapi/linux/videodev2.h |    1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 95ef455..52958af 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -294,6 +294,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_RGB555X v4l2_fourcc('R', 'G', 'B', 'Q') /* 16  RGB-5-5-5 BE  */
 #define V4L2_PIX_FMT_RGB565X v4l2_fourcc('R', 'G', 'B', 'R') /* 16  RGB-5-6-5 BE  */
 #define V4L2_PIX_FMT_BGR666  v4l2_fourcc('B', 'G', 'R', 'H') /* 18  BGR-6-6-6	  */
+#define V4L2_PIX_FMT_RGB666  v4l2_fourcc('R', 'G', 'B', 'H') /* 18  RGB-6-6-6	  */
 #define V4L2_PIX_FMT_BGR24   v4l2_fourcc('B', 'G', 'R', '3') /* 24  BGR-8-8-8     */
 #define V4L2_PIX_FMT_RGB24   v4l2_fourcc('R', 'G', 'B', '3') /* 24  RGB-8-8-8     */
 #define V4L2_PIX_FMT_BGR32   v4l2_fourcc('B', 'G', 'R', '4') /* 32  BGR-8-8-8-8   */
-- 
1.7.9.5



From shc_work at mail.ru  Mon Jul 15 11:19:01 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Mon, 15 Jul 2013 19:19:01 +0400
Subject: =?UTF-8?B?UmU6IFtQQVRDSCAyMS8yMl0gRFQ6IEFkZCBiYXNpYyBzdXBwb3J0IGZvciBp?=
 =?UTF-8?B?bXgzNS1iYXNlZCBkZXZpY2VzLg==?=
In-Reply-To: <1373900227-341-22-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-22-git-send-email-denis@eukrea.com>
Message-ID: <1373901541.255544938@f148.mail.ru>

> From: Steffen Trumtrar <s.trumtrar at pengutronix.de>
> 
> Signed-off-by: Steffen Trumtrar <s.trumtrar at pengutronix.de>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
...
> diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
> new file mode 100644
> index 0000000..012c1a3
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx35.dtsi
...
> +		emi at 80000000 { /* External Memory Interface */
> +			compatible = "fsl,emi", "simple-bus";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			reg = <0x80000000 0x40000000>;
> +			ranges;
> +
> +			nand: nand at bb000000 {
> +				#address-cells = <1>;
> +				#size-cells = <1>;
> +
> +				compatible = "fsl,imx35-nand", "fsl,imx25-nand";
> +				reg = <0xbb000000 0x2000>;
> +				interrupts = <33>;
> +				status = "disabled";
> +			};
> +		};

WEIM driver can (should) be used here.
See the example of usage in imx27.dtsi.

---

From broonie at kernel.org  Mon Jul 15 11:22:28 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 15 Jul 2013 16:22:28 +0100
Subject: [PATCH v5 1/7] sound: codec: wm8731: add rates constraints
In-Reply-To: <CACQ1gAhmp-i7vzPKuTMxqs9Ytjynz9NTvrQk9R08U9Fo-cVzMg@mail.gmail.com>
References: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
 <1373559359-31607-2-git-send-email-richard.genoud@gmail.com>
 <20130712114551.GD24508@sirena.org.uk>
 <CACQ1gAhmp-i7vzPKuTMxqs9Ytjynz9NTvrQk9R08U9Fo-cVzMg@mail.gmail.com>
Message-ID: <20130715152228.GJ11538@sirena.org.uk>

On Mon, Jul 15, 2013 at 04:53:46PM +0200, Richard Genoud wrote:
> 2013/7/12 Mark Brown <broonie at kernel.org>:

> > This isn't going to work with systems which have a variable clock as the
> > input to the CODEC.  If it's imposing constraints the driver needs to
> > allow setting the clock to zero as a way of removing constraints (and
> > any existing drivers should be updated to do this if needed).

> Maybe I'm wrong, but I didn't find any system using variable clock
> with this codec.

The driver should be written with that possibility in mind even if there
were no users; it only takes a couple of lines of code.

> The sam9g20ek (soc/atmel/sam9g20_wm8731.c) is not using a crystal, but
> it's using a fixed clock anyway.
> But there's soc/pxa/corgi.c and soc/pxa/poodle.c that puzzle me.
> They seems to use a crystal, but they are setting a different sysclk
> depending on the rate.
> That seems wrong, but as I'm a newbie in ASoC...

Note that the CPU is clock master for those - it's going to be
outputting a clock based on the sample rate selected automatically.
These boards would be broken by your change as it stands.
-------------- 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/20130715/6730f15f/attachment.sig>

From zubair.lutfullah at gmail.com  Mon Jul 15 11:25:28 2013
From: zubair.lutfullah at gmail.com (Zubair Lutfullah)
Date: Mon, 15 Jul 2013 16:25:28 +0100
Subject: [PATCH] typo fixes (coordiante -> coordinate) in am335x
Message-ID: <1373901928-19605-1-git-send-email-zubair.lutfullah@gmail.com>

Did a grep for coordiante and replaced them all
with coordinate.

This applies to the mfd-next tree.

Signed-off-by: Zubair Lutfullah <zubair.lutfullah at gmail.com>
---
 .../bindings/input/touchscreen/ti-tsc-adc.txt      |    4 ++--
 arch/arm/boot/dts/am335x-evm.dts                   |    2 +-
 drivers/input/touchscreen/ti_am335x_tsc.c          |    2 +-
 drivers/mfd/ti_am335x_tscadc.c                     |    2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
index 491c97b..3e22aec 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -6,7 +6,7 @@ Required properties:
 	ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen
 		  support on the platform.
 	ti,x-plate-resistance: X plate resistance
-	ti,coordiante-readouts: The sequencer supports a total of 16
+	ti,coordinate-readouts: The sequencer supports a total of 16
 				programmable steps each step is used to
 				read a single coordinate. A single
                                 readout is enough but multiple reads can
@@ -34,7 +34,7 @@ Example:
 		tsc {
 			ti,wires = <4>;
 			ti,x-plate-resistance = <200>;
-			ti,coordiante-readouts = <5>;
+			ti,coordinate-readouts = <5>;
 			ti,wire-config = <0x00 0x11 0x22 0x33>;
 		};
 
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 0fa4c7f..e50b781 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -250,7 +250,7 @@
 	tsc {
 		ti,wires = <4>;
 		ti,x-plate-resistance = <200>;
-		ti,coordiante-readouts = <5>;
+		ti,coordinate-readouts = <5>;
 		ti,wire-config = <0x00 0x11 0x22 0x33>;
 	};
 
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c
index 0e9f02a..6422f65 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -348,7 +348,7 @@ static int titsc_parse_dt(struct platform_device *pdev,
 	if (err < 0)
 		return err;
 
-	err = of_property_read_u32(node, "ti,coordiante-readouts",
+	err = of_property_read_u32(node, "ti,coordinate-readouts",
 			&ts_dev->coordinate_readouts);
 	if (err < 0)
 		return err;
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index b003a16..dd31e23 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -106,7 +106,7 @@ static	int ti_tscadc_probe(struct platform_device *pdev)
 
 	node = of_get_child_by_name(pdev->dev.of_node, "tsc");
 	of_property_read_u32(node, "ti,wires", &tsc_wires);
-	of_property_read_u32(node, "ti,coordiante-readouts", &readouts);
+	of_property_read_u32(node, "ti,coordinate-readouts", &readouts);
 
 	node = of_get_child_by_name(pdev->dev.of_node, "adc");
 	of_property_for_each_u32(node, "ti,adc-channels", prop, cur, val) {
-- 
1.7.9.5



From konrad.wilk at oracle.com  Mon Jul 15 11:25:32 2013
From: konrad.wilk at oracle.com (Konrad Rzeszutek Wilk)
Date: Mon, 15 Jul 2013 11:25:32 -0400
Subject: [Xen-devel] [PATCH] xen/arm: disable cpuidle when linux is
 running as dom0
In-Reply-To: <1373898101-15633-1-git-send-email-julien.grall@linaro.org>
References: <1373898101-15633-1-git-send-email-julien.grall@linaro.org>
Message-ID: <20130715152532.GC5774@phenom.dumpdata.com>

On Mon, Jul 15, 2013 at 03:21:41PM +0100, Julien Grall wrote:
> When linux is running as dom0, Xen doesn't show the physical cpu but a
> virtual CPU.
> On some ARM SOC (for instance the exynos 5250), linux registers callbacks
> for cpuidle. When these callbacks are called, they will modify
> directly the physical cpu not the virtual one. It can impact the whole board
> instead of dom0.

Should you also call disable_cpufreq() ?

> 
> Signed-off-by: Julien Grall <julien.grall at linaro.org>
> ---
>  arch/arm/xen/enlighten.c |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 49839d8..a98999f 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -24,6 +24,8 @@
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_address.h>
> +#include <linux/cpuidle.h>
> +#include <linux/cpufreq.h>
>  
>  #include <linux/mm.h>
>  
> @@ -292,6 +294,11 @@ static int __init xen_pm_init(void)
>  {
>  	pm_power_off = xen_power_off;
>  	arm_pm_restart = xen_restart;
> +	/*
> +	 * Making sure board specific code will not set up ops for
> +	 * cpu idle.
> +	 */
> +	disable_cpuidle();
>  
>  	return 0;
>  }
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel at lists.xen.org
> http://lists.xen.org/xen-devel


From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:50 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:50 -0300
Subject: [RESEND PATCH v7 21/22] ARM: mvebu: Relocate Armada 370/XP DeviceBus
 device tree nodes
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-22-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus has been added to the device tree, it's possible to
move the DeviceBus out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the hardware.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi             | 94 +++++++++++++-----------
 arch/arm/boot/dts/armada-xp-db.dts               | 59 +++++++--------
 arch/arm/boot/dts/armada-xp-gp.dts               | 60 +++++++--------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 65 ++++++++--------
 4 files changed, 140 insertions(+), 138 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 62639b4..073dd20 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -45,6 +45,56 @@
 		controller = <&mbusc>;
 		interrupt-parent = <&mpic>;
 
+		devbus-bootcs {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs0 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs1 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs2 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs3 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
 		internal-regs {
 			compatible = "simple-bus";
 			#address-cells = <1>;
@@ -200,50 +250,6 @@
 				status = "disabled";
 			};
 
-			devbus-bootcs at 10400 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10400 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs0 at 10408 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10408 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs1 at 10410 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10410 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs2 at 10418 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10418 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs3 at 10420 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10420 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
 		};
 	};
  };
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 857f272..76ae1a9 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -31,7 +31,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x1000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -160,34 +189,6 @@
 				};
 			};
 
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x1000000>;
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 16 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x1000000>;
-					bank-width = <2>;
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 934dc46..8c0de20 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -40,7 +40,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x1000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -126,35 +155,6 @@
 				};
 			};
 
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf000000, size 0x1000000 */
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 16 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x1000000>;
-					bank-width = <2>;
-				};
-			};
-
 			pcie-controller {
 				status = "okay";
 
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 1700f6f..2b60ee0 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -28,7 +28,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 128 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x8000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -148,40 +177,6 @@
 				status = "okay";
 			};
 
-			/* USB interface in the mini-PCIe connector */
-			usb at 52000 {
-				status = "okay";
-			};
-
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x8000000>; /* @addr 0xf000000, size 0x8000000 */
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 128 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x8000000>;
-					bank-width = <2>;
-				};
-			};
-
 			pcie-controller {
 				status = "okay";
 				/* Internal mini-PCIe connector */
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:49 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:49 -0300
Subject: [RESEND PATCH v7 20/22] ARM: mvebu: Add BootROM to Armada 370/XP
 device tree
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-21-git-send-email-ezequiel.garcia@free-electrons.com>

In order to access the SoC BootROM, we need to declare a mapping
(through a ranges property). The mbus driver will use this property
to allocate a suitable address decoding window.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              | 3 ++-
 arch/arm/boot/dts/armada-370-mirabox.dts         | 3 ++-
 arch/arm/boot/dts/armada-370-rd.dts              | 3 ++-
 arch/arm/boot/dts/armada-370.dtsi                | 5 +++++
 arch/arm/boot/dts/armada-xp-db.dts               | 3 ++-
 arch/arm/boot/dts/armada-xp-gp.dts               | 3 ++-
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 3 ++-
 arch/arm/boot/dts/armada-xp.dtsi                 | 5 +++++
 8 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 5920b4e..90ce29d 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,7 +30,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index a4202b6..19341d2 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,7 +25,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index dd0ba01..0b3acf3 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,7 +28,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 4b54e51..bd21d49 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -31,6 +31,11 @@
 	soc {
 		compatible = "marvell,armada370-mbus", "simple-bus";
 
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
+		};
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 0d4ce54..857f272 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,7 +30,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 2fa9209..934dc46 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,7 +39,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index a3e3a12..1700f6f 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,7 +27,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 8033824..7ba99ce 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -29,6 +29,11 @@
 	soc {
 		compatible = "marvell,armadaxp-mbus", "simple-bus";
 
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
+		};
+
 		internal-regs {
 			L2: l2-cache {
 				compatible = "marvell,aurora-system-cache";
-- 
1.8.1.5



From richard.genoud at gmail.com  Mon Jul 15 10:59:21 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon, 15 Jul 2013 16:59:21 +0200
Subject: [PATCH v5 2/7] sound: sam9x5_wm8731: machine driver for
 at91sam9x5 wm8731 boards
In-Reply-To: <20130712114926.GE24508@sirena.org.uk>
References: <1373559359-31607-1-git-send-email-richard.genoud@gmail.com>
 <1373559359-31607-3-git-send-email-richard.genoud@gmail.com>
 <20130712114926.GE24508@sirena.org.uk>
Message-ID: <CACQ1gAiJ8ww-gYfcUsux00DmpWUpfqyzzqfxZjWZSaObgsz29g@mail.gmail.com>

2013/7/12 Mark Brown <broonie at kernel.org>:
> On Thu, Jul 11, 2013 at 06:15:54PM +0200, Richard Genoud wrote:
>> From: Nicolas Ferre <nicolas.ferre at atmel.com>
>>
>> Description of the Asoc machine driver for an at91sam9x5 based board
>
> ASoC.
>
>> +sam9x5 pins:
>> + * LOUT
>> + * ROUT
>> + * LHPOUT
>> + * RHPOUT
>> + * LLINEIN
>> + * RLINEIN
>> + * MICIN
>
> These aren't pins on the CPU, they're pins on the CODEC, and you should
> be adding this to the binding document for the CODEC and referring to
> that rather than having them in each individual binding document.  This
> also helps if any new variants are added (not that this is likely for
> the WM8731).
ok, I'll move that

>
>> +static struct sam9x5_drvdata sam9x5_priv;
>
> Why is this a global static?
>
>> +     ret = snd_soc_register_card(&snd_soc_sam9x5);
>> +     if (ret) {
>> +             dev_err(&pdev->dev,
>> +                     "ASoC: Platform device allocation failed\n");
>> +             goto out_put_audio;
>> +     }
>
>> +     platform_set_drvdata(pdev, &snd_soc_sam9x5);
>
> It should be being dynamically allocated and retrieved as driver data
> when needed.
ok.

Thanks !


-- 
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?


From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:44 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:44 -0300
Subject: [RESEND PATCH v7 15/22] bus: mvebu-mbus: Factorize Armada 370/XP data
 structures
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-16-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

These structures were only different in the mapping tables.
Now that those tables have been removed, it doesn't make any sense
to keep different structures.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index f6e9192..d0a61ce 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -536,15 +536,7 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
 	mvebu_mbus_dram_info.num_cs = cs;
 }
 
-static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
-	.num_wins            = 20,
-	.num_remappable_wins = 8,
-	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
-	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
-	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-};
-
-static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
+static const struct mvebu_mbus_soc_data armada_370_xp_mbus_data = {
 	.num_wins            = 20,
 	.num_remappable_wins = 8,
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
@@ -604,9 +596,9 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
  */
 static const struct of_device_id of_mvebu_mbus_ids[] = {
 	{ .compatible = "marvell,armada370-mbus",
-	  .data = &armada_370_mbus_data, },
+	  .data = &armada_370_xp_mbus_data, },
 	{ .compatible = "marvell,armadaxp-mbus",
-	  .data = &armada_xp_mbus_data, },
+	  .data = &armada_370_xp_mbus_data, },
 	{ .compatible = "marvell,kirkwood-mbus",
 	  .data = &kirkwood_mbus_data, },
 	{ .compatible = "marvell,dove-mbus",
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:41 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:41 -0300
Subject: [RESEND PATCH v7 12/22] bus: mvebu-mbus: Remove the no longer used
 name-based API
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-13-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Now that every user of the deprecated name-based API has been
converted to using the ID-based API, let's remove the former one.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 38 --------------------------------------
 include/linux/mbus.h     |  5 -----
 2 files changed, 43 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 5f0bfa3..9aee344 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -766,44 +766,6 @@ int mvebu_mbus_add_window_remap_by_id(unsigned int target,
 	return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
 }
 
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
-				      size_t size, phys_addr_t remap,
-				      unsigned int flags)
-{
-	struct mvebu_mbus_state *s = &mbus_state;
-	u8 target, attr;
-	int i;
-
-	if (!s->soc->map)
-		return -ENODEV;
-
-	for (i = 0; s->soc->map[i].name; i++)
-		if (!strcmp(s->soc->map[i].name, devname))
-			break;
-
-	if (!s->soc->map[i].name) {
-		pr_err("unknown device '%s'\n", devname);
-		return -ENODEV;
-	}
-
-	target = s->soc->map[i].target;
-	attr   = s->soc->map[i].attr;
-
-	if (flags == MVEBU_MBUS_PCI_MEM)
-		attr |= 0x8;
-	else if (flags == MVEBU_MBUS_PCI_WA)
-		attr |= 0x28;
-
-	return mvebu_mbus_add_window_remap_by_id(target, attr, base,
-						 size, remap);
-}
-
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
-{
-	return mvebu_mbus_add_window_remap_flags(devname, base, size,
-						 MVEBU_MBUS_NO_REMAP, 0);
-}
-
 int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
 				phys_addr_t base, size_t size)
 {
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 650bc15..345b8c5 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -63,15 +63,10 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
 
 void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
 void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
-				      size_t size, phys_addr_t remap,
-				      unsigned int flags);
 int mvebu_mbus_add_window_remap_by_id(unsigned int target,
 				      unsigned int attribute,
 				      phys_addr_t base, size_t size,
 				      phys_addr_t remap);
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
-			  size_t size);
 int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
 				phys_addr_t base, size_t size);
 int mvebu_mbus_del_window(phys_addr_t base, size_t size);
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:36 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:36 -0300
Subject: [RESEND PATCH v7 07/22] bus: mvebu-mbus: Factor out initialization
 details
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-8-git-send-email-ezequiel.garcia@free-electrons.com>

We introduce a common initialization function mvebu_mbus_common_init()
that will be used by both legacy and device-tree initialization code.
This patch is an intermediate step, which will allow to introduce the
DT binding for this driver in a less intrusive way.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 47 ++++++++++++++++++++++++++++++-----------------
 1 file changed, 30 insertions(+), 17 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 827468a..1b17954 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -847,26 +847,14 @@ static __init int mvebu_mbus_debugfs_init(void)
 }
 fs_initcall(mvebu_mbus_debugfs_init);
 
-int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
-			   size_t mbuswins_size,
-			   phys_addr_t sdramwins_phys_base,
-			   size_t sdramwins_size)
+static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
+					 phys_addr_t mbuswins_phys_base,
+					 size_t mbuswins_size,
+					 phys_addr_t sdramwins_phys_base,
+					 size_t sdramwins_size)
 {
-	struct mvebu_mbus_state *mbus = &mbus_state;
-	const struct of_device_id *of_id;
 	int win;
 
-	for (of_id = of_mvebu_mbus_ids; of_id->compatible; of_id++)
-		if (!strcmp(of_id->compatible, soc))
-			break;
-
-	if (!of_id->compatible) {
-		pr_err("could not find a matching SoC family\n");
-		return -ENODEV;
-	}
-
-	mbus->soc = of_id->data;
-
 	mbus->mbuswins_base = ioremap(mbuswins_phys_base, mbuswins_size);
 	if (!mbus->mbuswins_base)
 		return -ENOMEM;
@@ -887,3 +875,28 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 
 	return 0;
 }
+
+int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
+			   size_t mbuswins_size,
+			   phys_addr_t sdramwins_phys_base,
+			   size_t sdramwins_size)
+{
+	const struct of_device_id *of_id;
+
+	for (of_id = of_mvebu_mbus_ids; of_id->compatible; of_id++)
+		if (!strcmp(of_id->compatible, soc))
+			break;
+
+	if (!of_id->compatible) {
+		pr_err("could not find a matching SoC family\n");
+		return -ENODEV;
+	}
+
+	mbus_state.soc = of_id->data;
+
+	return mvebu_mbus_common_init(&mbus_state,
+			mbuswins_phys_base,
+			mbuswins_size,
+			sdramwins_phys_base,
+			sdramwins_size);
+}
-- 
1.8.1.5



From denis at eukrea.com  Mon Jul 15 10:57:04 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:57:04 +0200
Subject: [PATCH 19/22] Input: tsc2007: Add device tree support.
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-20-git-send-email-denis@eukrea.com>

Set the of_match_table for this driver so that devices can be described
  in the device tree.

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 .../bindings/input/touchscreen/tsc2007.txt         |   44 +++++
 drivers/input/touchscreen/tsc2007.c                |  205 ++++++++++++++++----
 2 files changed, 206 insertions(+), 43 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt

diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
new file mode 100644
index 0000000..d67b33f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -0,0 +1,44 @@
+* Texas Instruments tsc2007 touchscreen controller
+
+Required properties:
+- compatible: must be "ti,tsc2007".
+- reg: I2C address of the chip.
+- pinctrl-0: Should specify pin control groups used for this controller
+  (see pinctrl bindings[0]).
+- pinctrl-names: Should contain only one value - "default"
+  (see pinctrl bindings[0]).
+- interrupt-parent: the phandle for the interrupt controller
+  (see interrupt binding[1]).
+- interrupts: interrupt to which the chip is connected
+  (see interrupt binding[1]).
+- x-plate-ohms: X-plate resistance in ohms.
+
+Optional properties:
+- gpios: the interrupt gpio the chip is connected to (trough the penirq pin)
+  (see GPIO binding[2] for more details).
+- max-rt: maximum pressure.
+- fuzzy: specifies the fuzz value that is used to filter noise from the event
+  stream.
+- poll-period: how much time to wait(in millisecond) before reading again the
+  values from the tsc2007.
+
+[0]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+[1]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+[2]: Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+	&i2c1 {
+		/* ... */
+		tsc2007 at 49 {
+			compatible = "ti,tsc2007";
+			reg = <0x49>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_tsc2007_1>;
+			interrupt-parent = <&gpio4>;
+			interrupts = <0x0 0x8>;
+			gpios = <&gpio4 0 0>;
+			x-plate-ohms = <180>;
+		};
+
+		/* ... */
+	};
diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c
index 0b67ba4..c0af04b 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -26,6 +26,9 @@
 #include <linux/interrupt.h>
 #include <linux/i2c.h>
 #include <linux/i2c/tsc2007.h>
+#include <linux/of_device.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
 
 #define TSC2007_MEASURE_TEMP0		(0x0 << 4)
 #define TSC2007_MEASURE_AUX		(0x2 << 4)
@@ -74,7 +77,10 @@ struct tsc2007 {
 	u16			max_rt;
 	unsigned long		poll_delay;
 	unsigned long		poll_period;
+	int			fuzzy;
+	char			of;
 
+	unsigned		gpio;
 	int			irq;
 
 	wait_queue_head_t	wait;
@@ -84,6 +90,14 @@ struct tsc2007 {
 	void			(*clear_penirq)(void);
 };
 
+static int tsc2007_get_pendown_state_dt(struct tsc2007  *ts)
+{
+	if (ts->gpio >= 0)
+		return !gpio_get_value(ts->gpio);
+	else
+		return true;
+}
+
 static inline int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
 {
 	s32 data;
@@ -158,6 +172,9 @@ static bool tsc2007_is_pen_down(struct tsc2007 *ts)
 	 * to fall back on the pressure reading.
 	 */
 
+	if (ts->of)
+		return tsc2007_get_pendown_state_dt(ts);
+
 	if (!ts->get_pendown_state)
 		return true;
 
@@ -175,10 +192,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 
 		/* pen is down, continue with the measurement */
 		tsc2007_read_values(ts, &tc);
-
 		rt = tsc2007_calculate_pressure(ts, &tc);
 
-		if (rt == 0 && !ts->get_pendown_state) {
+		if ((ts->of && rt == 0 && ts->gpio < 0) ||
+			(!ts->of && rt == 0 && !ts->get_pendown_state)) {
 			/*
 			 * If pressure reported is 0 and we don't have
 			 * callback to check pendown state, we have to
@@ -198,7 +215,6 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 			input_report_abs(input, ABS_PRESSURE, rt);
 
 			input_sync(input);
-
 		} else {
 			/*
 			 * Sample found inconsistent by debouncing or pressure is
@@ -217,7 +233,6 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 	input_report_key(input, BTN_TOUCH, 0);
 	input_report_abs(input, ABS_PRESSURE, 0);
 	input_sync(input);
-
 	if (ts->clear_penirq)
 		ts->clear_penirq();
 
@@ -228,11 +243,16 @@ static irqreturn_t tsc2007_hard_irq(int irq, void *handle)
 {
 	struct tsc2007 *ts = handle;
 
-	if (!ts->get_pendown_state || likely(ts->get_pendown_state()))
-		return IRQ_WAKE_THREAD;
+	if (!ts->of) {
+		if (!ts->get_pendown_state || likely(ts->get_pendown_state()))
+			return IRQ_WAKE_THREAD;
 
-	if (ts->clear_penirq)
-		ts->clear_penirq();
+		if (ts->clear_penirq)
+			ts->clear_penirq();
+	} else {
+		if (ts->gpio < 0 || likely(tsc2007_get_pendown_state_dt(ts)))
+			return IRQ_WAKE_THREAD;
+	}
 
 	return IRQ_HANDLED;
 }
@@ -273,34 +293,70 @@ static void tsc2007_close(struct input_dev *input_dev)
 	tsc2007_stop(ts);
 }
 
-static int tsc2007_probe(struct i2c_client *client,
-				   const struct i2c_device_id *id)
+#ifdef CONFIG_OF
+static int tsc2007_probe_dt(struct i2c_client *client, struct tsc2007 *ts,
+			    struct device_node *np)
 {
-	struct tsc2007 *ts;
-	struct tsc2007_platform_data *pdata = client->dev.platform_data;
-	struct input_dev *input_dev;
-	int err;
-
-	if (!pdata) {
-		dev_err(&client->dev, "platform data is required!\n");
+	int err = 0;
+	struct pinctrl *pinctrl;
+	u32 val32;
+	u64 val64;
+
+	if (!of_property_read_u32(np, "max-rt", &val32))
+		ts->max_rt = val32;
+	else
+		ts->max_rt = MAX_12BIT;
+
+	if (!of_property_read_u32(np, "fuzzy", &val32))
+		ts->fuzzy = val32;
+
+	if (!of_property_read_u64(np, "poll-period", &val64))
+		ts->poll_period = val64;
+	else
+		ts->poll_period = 1;
+
+	if (!of_property_read_u32(np, "x-plate-ohms", &val32))
+		ts->x_plate_ohms = val32;
+	else {
+		dev_err(&client->dev,
+			"x-plate-ohms is not set up in the devicetree."
+			" (err %d).", err);
 		return -EINVAL;
 	}
 
-	if (!i2c_check_functionality(client->adapter,
-				     I2C_FUNC_SMBUS_READ_WORD_DATA))
-		return -EIO;
-
-	ts = kzalloc(sizeof(struct tsc2007), GFP_KERNEL);
-	input_dev = input_allocate_device();
-	if (!ts || !input_dev) {
-		err = -ENOMEM;
-		goto err_free_mem;
+	pinctrl = devm_pinctrl_get_select_default(&client->dev);
+	if (IS_ERR(pinctrl)) {
+		err = PTR_ERR(pinctrl);
+		return err;
 	}
 
-	ts->client = client;
-	ts->irq = client->irq;
-	ts->input = input_dev;
-	init_waitqueue_head(&ts->wait);
+	ts->gpio = of_get_gpio(np, 0);
+	if (ts->gpio < 0)
+		pr_err("GPIO not found (of_get_gpio returned %d)\n", ts->gpio);
+
+	/* Used to detect if it is probed trough the device tree,
+	 * in order to be able to use that information in the IRQ handler.
+	 */
+	ts->of = 1;
+
+	return 0;
+}
+#else
+static int tsc2007_probe_dt(struct i2c_client *client, struct tsc2007 *ts,
+			    struct device_node *np)
+{
+	return -ENODEV;
+}
+#endif
+
+static int tsc2007_probe_pdev(struct i2c_client *client, struct tsc2007 *ts,
+			      struct tsc2007_platform_data *pdata,
+			      const struct i2c_device_id *id)
+{
+	if (!pdata) {
+		dev_err(&client->dev, "platform data is required!\n");
+		return -EINVAL;
+	}
 
 	ts->model             = pdata->model;
 	ts->x_plate_ohms      = pdata->x_plate_ohms;
@@ -309,13 +365,59 @@ static int tsc2007_probe(struct i2c_client *client,
 	ts->poll_period       = pdata->poll_period ? : 1;
 	ts->get_pendown_state = pdata->get_pendown_state;
 	ts->clear_penirq      = pdata->clear_penirq;
+	ts->fuzzy             = pdata->fuzzy;
 
 	if (pdata->x_plate_ohms == 0) {
 		dev_err(&client->dev, "x_plate_ohms is not set up in platform data");
-		err = -EINVAL;
+		return -EINVAL;
+	}
+
+	/* Used to detect if it is probed trough the device tree,
+	 * in order to be able to use that information in the IRQ handler.
+	 */
+	ts->of = 0;
+
+	return 0;
+}
+
+static int tsc2007_probe(struct i2c_client *client,
+			 const struct i2c_device_id *id)
+{
+	struct device_node *np = client->dev.of_node;
+	struct tsc2007_platform_data *pdata = client->dev.platform_data;
+	struct tsc2007 *ts;
+	struct input_dev *input_dev;
+	int err = 0;
+
+	ts = kzalloc(sizeof(struct tsc2007), GFP_KERNEL);
+	if (!ts)
+		return -ENOMEM;
+
+	if (np)
+		err = tsc2007_probe_dt(client, ts, np);
+	else
+		err = tsc2007_probe_pdev(client, ts, pdata, id);
+
+	if (err)
+		goto err_free_mem;
+
+	if (!i2c_check_functionality(client->adapter,
+				     I2C_FUNC_SMBUS_READ_WORD_DATA)) {
+		err = -EIO;
 		goto err_free_mem;
 	}
 
+	input_dev = input_allocate_device();
+	if (!input_dev) {
+		err = -ENOMEM;
+		goto err_free_input;
+	};
+
+	ts->client = client;
+	ts->irq = client->irq;
+	ts->input = input_dev;
+	init_waitqueue_head(&ts->wait);
+
 	snprintf(ts->phys, sizeof(ts->phys),
 		 "%s/input0", dev_name(&client->dev));
 
@@ -331,19 +433,21 @@ static int tsc2007_probe(struct i2c_client *client,
 	input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
 	input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
 
-	input_set_abs_params(input_dev, ABS_X, 0, MAX_12BIT, pdata->fuzzx, 0);
-	input_set_abs_params(input_dev, ABS_Y, 0, MAX_12BIT, pdata->fuzzy, 0);
+	input_set_abs_params(input_dev, ABS_X, 0, MAX_12BIT, ts->fuzzy, 0);
+	input_set_abs_params(input_dev, ABS_Y, 0, MAX_12BIT, ts->fuzzy, 0);
 	input_set_abs_params(input_dev, ABS_PRESSURE, 0, MAX_12BIT,
-			pdata->fuzzz, 0);
+			     ts->fuzzy, 0);
 
-	if (pdata->init_platform_hw)
-		pdata->init_platform_hw();
+	if (!np) {
+		if (pdata->init_platform_hw)
+			pdata->init_platform_hw();
+	}
 
 	err = request_threaded_irq(ts->irq, tsc2007_hard_irq, tsc2007_soft_irq,
 				   IRQF_ONESHOT, client->dev.driver->name, ts);
 	if (err < 0) {
 		dev_err(&client->dev, "irq %d busy?\n", ts->irq);
-		goto err_free_mem;
+		goto err_free_input;
 	}
 
 	tsc2007_stop(ts);
@@ -358,23 +462,29 @@ static int tsc2007_probe(struct i2c_client *client,
 
  err_free_irq:
 	free_irq(ts->irq, ts);
-	if (pdata->exit_platform_hw)
-		pdata->exit_platform_hw();
- err_free_mem:
+	if (!np) {
+		if (pdata->exit_platform_hw)
+			pdata->exit_platform_hw();
+	}
+ err_free_input:
 	input_free_device(input_dev);
+ err_free_mem:
 	kfree(ts);
 	return err;
 }
 
 static int tsc2007_remove(struct i2c_client *client)
 {
+	struct device_node *np = client->dev.of_node;
 	struct tsc2007	*ts = i2c_get_clientdata(client);
 	struct tsc2007_platform_data *pdata = client->dev.platform_data;
 
 	free_irq(ts->irq, ts);
 
-	if (pdata->exit_platform_hw)
-		pdata->exit_platform_hw();
+	if (!np) {
+		if (pdata->exit_platform_hw)
+			pdata->exit_platform_hw();
+	}
 
 	input_unregister_device(ts->input);
 	kfree(ts);
@@ -389,10 +499,19 @@ static const struct i2c_device_id tsc2007_idtable[] = {
 
 MODULE_DEVICE_TABLE(i2c, tsc2007_idtable);
 
+#ifdef CONFIG_OF
+static const struct of_device_id tsc2007_of_match[] = {
+	{ .compatible = "ti,tsc2007" },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, tsc2007_of_match);
+#endif
+
 static struct i2c_driver tsc2007_driver = {
 	.driver = {
 		.owner	= THIS_MODULE,
-		.name	= "tsc2007"
+		.name	= "tsc2007",
+		.of_match_table = of_match_ptr(tsc2007_of_match),
 	},
 	.id_table	= tsc2007_idtable,
 	.probe		= tsc2007_probe,
-- 
1.7.9.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:34 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:34 -0300
Subject: [RESEND PATCH v7 05/22] ARM: orion5x: Move to ID based window creation
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-6-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-orion5x/common.c                 | 36 ++++++++++++++------------
 arch/arm/mach-orion5x/common.h                 | 17 ++++++++++++
 arch/arm/mach-orion5x/d2net-setup.c            |  6 +++--
 arch/arm/mach-orion5x/db88f5281-setup.c        | 24 +++++++++++------
 arch/arm/mach-orion5x/dns323-setup.c           |  6 +++--
 arch/arm/mach-orion5x/edmini_v2-setup.c        |  6 +++--
 arch/arm/mach-orion5x/kurobox_pro-setup.c      | 12 ++++++---
 arch/arm/mach-orion5x/ls-chl-setup.c           |  6 +++--
 arch/arm/mach-orion5x/ls_hgl-setup.c           |  6 +++--
 arch/arm/mach-orion5x/lsmini-setup.c           |  6 +++--
 arch/arm/mach-orion5x/mss2-setup.c             |  6 +++--
 arch/arm/mach-orion5x/mv2120-setup.c           |  6 +++--
 arch/arm/mach-orion5x/net2big-setup.c          |  6 +++--
 arch/arm/mach-orion5x/pci.c                    |  9 +++----
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c   |  6 +++--
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c    |  6 +++--
 arch/arm/mach-orion5x/rd88f5182-setup.c        | 13 ++++++----
 arch/arm/mach-orion5x/terastation_pro2-setup.c |  6 +++--
 arch/arm/mach-orion5x/ts209-setup.c            |  6 +++--
 arch/arm/mach-orion5x/ts409-setup.c            |  6 +++--
 arch/arm/mach-orion5x/wnr854t-setup.c          |  6 +++--
 arch/arm/mach-orion5x/wrt350n-v2-setup.c       |  6 +++--
 22 files changed, 137 insertions(+), 70 deletions(-)

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index b41599f..91a5852 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -174,8 +174,10 @@ void __init orion5x_xor_init(void)
  ****************************************************************************/
 static void __init orion5x_crypto_init(void)
 {
-	mvebu_mbus_add_window("sram", ORION5X_SRAM_PHYS_BASE,
-			      ORION5X_SRAM_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_SRAM_TARGET,
+				    ORION_MBUS_SRAM_ATTR,
+				    ORION5X_SRAM_PHYS_BASE,
+				    ORION5X_SRAM_SIZE);
 	orion_crypto_init(ORION5X_CRYPTO_PHYS_BASE, ORION5X_SRAM_PHYS_BASE,
 			  SZ_8K, IRQ_ORION5X_CESA);
 }
@@ -222,22 +224,24 @@ void orion5x_setup_wins(void)
 	 * The PCIe windows will no longer be statically allocated
 	 * here once Orion5x is migrated to the pci-mvebu driver.
 	 */
-	mvebu_mbus_add_window_remap_flags("pcie0.0", ORION5X_PCIE_IO_PHYS_BASE,
+	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
+					  ORION_MBUS_PCIE_IO_ATTR,
+					  ORION5X_PCIE_IO_PHYS_BASE,
 					  ORION5X_PCIE_IO_SIZE,
-					  ORION5X_PCIE_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0", ORION5X_PCIE_MEM_PHYS_BASE,
-					  ORION5X_PCIE_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pci0.0", ORION5X_PCI_IO_PHYS_BASE,
+					  ORION5X_PCIE_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
+				    ORION_MBUS_PCIE_MEM_ATTR,
+				    ORION5X_PCIE_MEM_PHYS_BASE,
+				    ORION5X_PCIE_MEM_SIZE);
+	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
+					  ORION_MBUS_PCI_IO_ATTR,
+					  ORION5X_PCI_IO_PHYS_BASE,
 					  ORION5X_PCI_IO_SIZE,
-					  ORION5X_PCI_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pci0.0", ORION5X_PCI_MEM_PHYS_BASE,
-					  ORION5X_PCI_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+					  ORION5X_PCI_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
+				    ORION_MBUS_PCI_MEM_ATTR,
+				    ORION5X_PCI_MEM_PHYS_BASE,
+				    ORION5X_PCI_MEM_SIZE);
 }
 
 int orion5x_tclk;
diff --git a/arch/arm/mach-orion5x/common.h b/arch/arm/mach-orion5x/common.h
index a909afb..f565f99 100644
--- a/arch/arm/mach-orion5x/common.h
+++ b/arch/arm/mach-orion5x/common.h
@@ -7,6 +7,23 @@ struct dsa_platform_data;
 struct mv643xx_eth_platform_data;
 struct mv_sata_platform_data;
 
+#define ORION_MBUS_PCIE_MEM_TARGET    0x04
+#define ORION_MBUS_PCIE_MEM_ATTR      0x59
+#define ORION_MBUS_PCIE_IO_TARGET     0x04
+#define ORION_MBUS_PCIE_IO_ATTR       0x51
+#define ORION_MBUS_PCIE_WA_TARGET     0x04
+#define ORION_MBUS_PCIE_WA_ATTR       0x79
+#define ORION_MBUS_PCI_MEM_TARGET     0x03
+#define ORION_MBUS_PCI_MEM_ATTR       0x59
+#define ORION_MBUS_PCI_IO_TARGET      0x03
+#define ORION_MBUS_PCI_IO_ATTR        0x51
+#define ORION_MBUS_DEVBUS_BOOT_TARGET 0x01
+#define ORION_MBUS_DEVBUS_BOOT_ATTR   0x0f
+#define ORION_MBUS_DEVBUS_TARGET(cs)  0x01
+#define ORION_MBUS_DEVBUS_ATTR(cs)    (~(1 << cs))
+#define ORION_MBUS_SRAM_TARGET        0x00
+#define ORION_MBUS_SRAM_ATTR          0x00
+
 /*
  * Basic Orion init functions used early by machine-setup.
  */
diff --git a/arch/arm/mach-orion5x/d2net-setup.c b/arch/arm/mach-orion5x/d2net-setup.c
index 16c88bb..8f68b74 100644
--- a/arch/arm/mach-orion5x/d2net-setup.c
+++ b/arch/arm/mach-orion5x/d2net-setup.c
@@ -317,8 +317,10 @@ static void __init d2net_init(void)
 	d2net_sata_power_init();
 	orion5x_sata_init(&d2net_sata_data);
 
-	mvebu_mbus_add_window("devbus-boot", D2NET_NOR_BOOT_BASE,
-			      D2NET_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    D2NET_NOR_BOOT_BASE,
+				    D2NET_NOR_BOOT_SIZE);
 	platform_device_register(&d2net_nor_flash);
 
 	platform_device_register(&d2net_gpio_buttons);
diff --git a/arch/arm/mach-orion5x/db88f5281-setup.c b/arch/arm/mach-orion5x/db88f5281-setup.c
index 4e1263d..4b2aefd 100644
--- a/arch/arm/mach-orion5x/db88f5281-setup.c
+++ b/arch/arm/mach-orion5x/db88f5281-setup.c
@@ -340,19 +340,27 @@ static void __init db88f5281_init(void)
 	orion5x_uart0_init();
 	orion5x_uart1_init();
 
-	mvebu_mbus_add_window("devbus-boot", DB88F5281_NOR_BOOT_BASE,
-			      DB88F5281_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    DB88F5281_NOR_BOOT_BASE,
+				    DB88F5281_NOR_BOOT_SIZE);
 	platform_device_register(&db88f5281_boot_flash);
 
-	mvebu_mbus_add_window("devbus-cs0", DB88F5281_7SEG_BASE,
-			      DB88F5281_7SEG_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(0),
+				    ORION_MBUS_DEVBUS_ATTR(0),
+				    DB88F5281_7SEG_BASE,
+				    DB88F5281_7SEG_SIZE);
 
-	mvebu_mbus_add_window("devbus-cs1", DB88F5281_NOR_BASE,
-			      DB88F5281_NOR_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(1),
+				    ORION_MBUS_DEVBUS_ATTR(1),
+				    DB88F5281_NOR_BASE,
+				    DB88F5281_NOR_SIZE);
 	platform_device_register(&db88f5281_nor_flash);
 
-	mvebu_mbus_add_window("devbus-cs2", DB88F5281_NAND_BASE,
-			      DB88F5281_NAND_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(2),
+				    ORION_MBUS_DEVBUS_ATTR(2),
+				    DB88F5281_NAND_BASE,
+				    DB88F5281_NAND_SIZE);
 	platform_device_register(&db88f5281_nand_flash);
 
 	i2c_register_board_info(0, &db88f5281_i2c_rtc, 1);
diff --git a/arch/arm/mach-orion5x/dns323-setup.c b/arch/arm/mach-orion5x/dns323-setup.c
index 9e6baf5..7097473 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -611,8 +611,10 @@ static void __init dns323_init(void)
 	/* setup flash mapping
 	 * CS3 holds a 8 MB Spansion S29GL064M90TFIR4
 	 */
-	mvebu_mbus_add_window("devbus-boot", DNS323_NOR_BOOT_BASE,
-			      DNS323_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    DNS323_NOR_BOOT_BASE,
+				    DNS323_NOR_BOOT_SIZE);
 	platform_device_register(&dns323_nor_flash);
 
 	/* Sort out LEDs, Buttons and i2c devices */
diff --git a/arch/arm/mach-orion5x/edmini_v2-setup.c b/arch/arm/mach-orion5x/edmini_v2-setup.c
index 1476155..0fc33c5 100644
--- a/arch/arm/mach-orion5x/edmini_v2-setup.c
+++ b/arch/arm/mach-orion5x/edmini_v2-setup.c
@@ -154,8 +154,10 @@ void __init edmini_v2_init(void)
 	orion5x_ehci0_init();
 	orion5x_eth_init(&edmini_v2_eth_data);
 
-	mvebu_mbus_add_window("devbus-boot", EDMINI_V2_NOR_BOOT_BASE,
-			      EDMINI_V2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    EDMINI_V2_NOR_BOOT_BASE,
+				    EDMINI_V2_NOR_BOOT_SIZE);
 	platform_device_register(&edmini_v2_nor_flash);
 
 	pr_notice("edmini_v2: USB device port, flash write and power-off "
diff --git a/arch/arm/mach-orion5x/kurobox_pro-setup.c b/arch/arm/mach-orion5x/kurobox_pro-setup.c
index aae10e4..fe6a48a 100644
--- a/arch/arm/mach-orion5x/kurobox_pro-setup.c
+++ b/arch/arm/mach-orion5x/kurobox_pro-setup.c
@@ -359,13 +359,17 @@ static void __init kurobox_pro_init(void)
 	orion5x_uart1_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", KUROBOX_PRO_NOR_BOOT_BASE,
-			      KUROBOX_PRO_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    KUROBOX_PRO_NOR_BOOT_BASE,
+				    KUROBOX_PRO_NOR_BOOT_SIZE);
 	platform_device_register(&kurobox_pro_nor_flash);
 
 	if (machine_is_kurobox_pro()) {
-		mvebu_mbus_add_window("devbus-cs0", KUROBOX_PRO_NAND_BASE,
-				      KUROBOX_PRO_NAND_SIZE);
+		mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(0),
+					    ORION_MBUS_DEVBUS_ATTR(0),
+					    KUROBOX_PRO_NAND_BASE,
+					    KUROBOX_PRO_NAND_SIZE);
 		platform_device_register(&kurobox_pro_nand_flash);
 	}
 
diff --git a/arch/arm/mach-orion5x/ls-chl-setup.c b/arch/arm/mach-orion5x/ls-chl-setup.c
index 6234977..028ea03 100644
--- a/arch/arm/mach-orion5x/ls-chl-setup.c
+++ b/arch/arm/mach-orion5x/ls-chl-setup.c
@@ -294,8 +294,10 @@ static void __init lschl_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LSCHL_NOR_BOOT_BASE,
-			      LSCHL_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LSCHL_NOR_BOOT_BASE,
+				    LSCHL_NOR_BOOT_SIZE);
 	platform_device_register(&lschl_nor_flash);
 
 	platform_device_register(&lschl_leds);
diff --git a/arch/arm/mach-orion5x/ls_hgl-setup.c b/arch/arm/mach-orion5x/ls_hgl-setup.c
index fe04c4b..32b7129 100644
--- a/arch/arm/mach-orion5x/ls_hgl-setup.c
+++ b/arch/arm/mach-orion5x/ls_hgl-setup.c
@@ -243,8 +243,10 @@ static void __init ls_hgl_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LS_HGL_NOR_BOOT_BASE,
-			      LS_HGL_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LS_HGL_NOR_BOOT_BASE,
+				    LS_HGL_NOR_BOOT_SIZE);
 	platform_device_register(&ls_hgl_nor_flash);
 
 	platform_device_register(&ls_hgl_button_device);
diff --git a/arch/arm/mach-orion5x/lsmini-setup.c b/arch/arm/mach-orion5x/lsmini-setup.c
index ca4dbe9..a6493e7 100644
--- a/arch/arm/mach-orion5x/lsmini-setup.c
+++ b/arch/arm/mach-orion5x/lsmini-setup.c
@@ -244,8 +244,10 @@ static void __init lsmini_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LSMINI_NOR_BOOT_BASE,
-			      LSMINI_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LSMINI_NOR_BOOT_BASE,
+				    LSMINI_NOR_BOOT_SIZE);
 	platform_device_register(&lsmini_nor_flash);
 
 	platform_device_register(&lsmini_button_device);
diff --git a/arch/arm/mach-orion5x/mss2-setup.c b/arch/arm/mach-orion5x/mss2-setup.c
index 827acba..e105130 100644
--- a/arch/arm/mach-orion5x/mss2-setup.c
+++ b/arch/arm/mach-orion5x/mss2-setup.c
@@ -241,8 +241,10 @@ static void __init mss2_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", MSS2_NOR_BOOT_BASE,
-			      MSS2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    MSS2_NOR_BOOT_BASE,
+				    MSS2_NOR_BOOT_SIZE);
 	platform_device_register(&mss2_nor_flash);
 
 	platform_device_register(&mss2_button_device);
diff --git a/arch/arm/mach-orion5x/mv2120-setup.c b/arch/arm/mach-orion5x/mv2120-setup.c
index 92600ae..e032f01 100644
--- a/arch/arm/mach-orion5x/mv2120-setup.c
+++ b/arch/arm/mach-orion5x/mv2120-setup.c
@@ -204,8 +204,10 @@ static void __init mv2120_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", MV2120_NOR_BOOT_BASE,
-			      MV2120_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    MV2120_NOR_BOOT_BASE,
+				    MV2120_NOR_BOOT_SIZE);
 	platform_device_register(&mv2120_nor_flash);
 
 	platform_device_register(&mv2120_button_device);
diff --git a/arch/arm/mach-orion5x/net2big-setup.c b/arch/arm/mach-orion5x/net2big-setup.c
index dd0641a..ba73dc7 100644
--- a/arch/arm/mach-orion5x/net2big-setup.c
+++ b/arch/arm/mach-orion5x/net2big-setup.c
@@ -397,8 +397,10 @@ static void __init net2big_init(void)
 	net2big_sata_power_init();
 	orion5x_sata_init(&net2big_sata_data);
 
-	mvebu_mbus_add_window("devbus-boot", NET2BIG_NOR_BOOT_BASE,
-			      NET2BIG_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    NET2BIG_NOR_BOOT_BASE,
+				    NET2BIG_NOR_BOOT_SIZE);
 	platform_device_register(&net2big_nor_flash);
 
 	platform_device_register(&net2big_gpio_buttons);
diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion5x/pci.c
index 5033680..7fab670 100644
--- a/arch/arm/mach-orion5x/pci.c
+++ b/arch/arm/mach-orion5x/pci.c
@@ -157,11 +157,10 @@ static int __init pcie_setup(struct pci_sys_data *sys)
 	if (dev == MV88F5181_DEV_ID || dev == MV88F5182_DEV_ID) {
 		printk(KERN_NOTICE "Applying Orion-1/Orion-NAS PCIe config "
 				   "read transaction workaround\n");
-		mvebu_mbus_add_window_remap_flags("pcie0.0",
-						  ORION5X_PCIE_WA_PHYS_BASE,
-						  ORION5X_PCIE_WA_SIZE,
-						  MVEBU_MBUS_NO_REMAP,
-						  MVEBU_MBUS_PCI_WA);
+		mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_WA_TARGET,
+					    ORION_MBUS_PCIE_WA_ATTR,
+					    ORION5X_PCIE_WA_PHYS_BASE,
+					    ORION5X_PCIE_WA_SIZE);
 		pcie_ops.read = pcie_rd_conf_wa;
 	}
 
diff --git a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
index 1c4498b..213b3e1 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
@@ -123,8 +123,10 @@ static void __init rd88f5181l_fxo_init(void)
 	orion5x_eth_switch_init(&rd88f5181l_fxo_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5181L_FXO_NOR_BOOT_BASE,
-			      RD88F5181L_FXO_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5181L_FXO_NOR_BOOT_BASE,
+				    RD88F5181L_FXO_NOR_BOOT_SIZE);
 	platform_device_register(&rd88f5181l_fxo_nor_boot_flash);
 }
 
diff --git a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
index adabe34..594800e 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
@@ -130,8 +130,10 @@ static void __init rd88f5181l_ge_init(void)
 	orion5x_i2c_init();
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5181L_GE_NOR_BOOT_BASE,
-			      RD88F5181L_GE_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5181L_GE_NOR_BOOT_BASE,
+				    RD88F5181L_GE_NOR_BOOT_SIZE);
 	platform_device_register(&rd88f5181l_ge_nor_boot_flash);
 
 	i2c_register_board_info(0, &rd88f5181l_ge_i2c_rtc, 1);
diff --git a/arch/arm/mach-orion5x/rd88f5182-setup.c b/arch/arm/mach-orion5x/rd88f5182-setup.c
index 66e77ec..b1cf684 100644
--- a/arch/arm/mach-orion5x/rd88f5182-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5182-setup.c
@@ -264,11 +264,14 @@ static void __init rd88f5182_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5182_NOR_BOOT_BASE,
-			      RD88F5182_NOR_BOOT_SIZE);
-
-	mvebu_mbus_add_window("devbus-cs1", RD88F5182_NOR_BASE,
-			      RD88F5182_NOR_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5182_NOR_BOOT_BASE,
+				    RD88F5182_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(1),
+				    ORION_MBUS_DEVBUS_ATTR(1),
+				    RD88F5182_NOR_BASE,
+				    RD88F5182_NOR_SIZE);
 	platform_device_register(&rd88f5182_nor_flash);
 	platform_device_register(&rd88f5182_gpio_leds);
 
diff --git a/arch/arm/mach-orion5x/terastation_pro2-setup.c b/arch/arm/mach-orion5x/terastation_pro2-setup.c
index a0bfa53..7e90648 100644
--- a/arch/arm/mach-orion5x/terastation_pro2-setup.c
+++ b/arch/arm/mach-orion5x/terastation_pro2-setup.c
@@ -329,8 +329,10 @@ static void __init tsp2_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", TSP2_NOR_BOOT_BASE,
-			      TSP2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    TSP2_NOR_BOOT_BASE,
+				    TSP2_NOR_BOOT_SIZE);
 	platform_device_register(&tsp2_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/ts209-setup.c b/arch/arm/mach-orion5x/ts209-setup.c
index 80174f0..e90c061 100644
--- a/arch/arm/mach-orion5x/ts209-setup.c
+++ b/arch/arm/mach-orion5x/ts209-setup.c
@@ -286,8 +286,10 @@ static void __init qnap_ts209_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", QNAP_TS209_NOR_BOOT_BASE,
-			      QNAP_TS209_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    QNAP_TS209_NOR_BOOT_BASE,
+				    QNAP_TS209_NOR_BOOT_SIZE);
 	platform_device_register(&qnap_ts209_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/ts409-setup.c b/arch/arm/mach-orion5x/ts409-setup.c
index 9259279..5c079d3 100644
--- a/arch/arm/mach-orion5x/ts409-setup.c
+++ b/arch/arm/mach-orion5x/ts409-setup.c
@@ -277,8 +277,10 @@ static void __init qnap_ts409_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", QNAP_TS409_NOR_BOOT_BASE,
-			      QNAP_TS409_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    QNAP_TS409_NOR_BOOT_BASE,
+				    QNAP_TS409_NOR_BOOT_SIZE);
 	platform_device_register(&qnap_ts409_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/wnr854t-setup.c b/arch/arm/mach-orion5x/wnr854t-setup.c
index 6b84863..80a56ee 100644
--- a/arch/arm/mach-orion5x/wnr854t-setup.c
+++ b/arch/arm/mach-orion5x/wnr854t-setup.c
@@ -127,8 +127,10 @@ static void __init wnr854t_init(void)
 	orion5x_eth_switch_init(&wnr854t_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", WNR854T_NOR_BOOT_BASE,
-			      WNR854T_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    WNR854T_NOR_BOOT_BASE,
+				    WNR854T_NOR_BOOT_SIZE);
 	platform_device_register(&wnr854t_nor_flash);
 }
 
diff --git a/arch/arm/mach-orion5x/wrt350n-v2-setup.c b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
index fae684b..670e30d 100644
--- a/arch/arm/mach-orion5x/wrt350n-v2-setup.c
+++ b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
@@ -213,8 +213,10 @@ static void __init wrt350n_v2_init(void)
 	orion5x_eth_switch_init(&wrt350n_v2_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", WRT350N_V2_NOR_BOOT_BASE,
-			      WRT350N_V2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    WRT350N_V2_NOR_BOOT_BASE,
+				    WRT350N_V2_NOR_BOOT_SIZE);
 	platform_device_register(&wrt350n_v2_nor_flash);
 	platform_device_register(&wrt350n_v2_leds);
 	platform_device_register(&wrt350n_v2_button_device);
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:33 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:33 -0300
Subject: [RESEND PATCH v7 04/22] ARM: mv78xx0: Move to ID based window creation
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-5-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-mv78xx0/pcie.c | 23 +++++++++++------------
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-mv78xx0/pcie.c b/arch/arm/mach-mv78xx0/pcie.c
index dc26a65..397afde 100644
--- a/arch/arm/mach-mv78xx0/pcie.c
+++ b/arch/arm/mach-mv78xx0/pcie.c
@@ -18,6 +18,11 @@
 #include <mach/mv78xx0.h>
 #include "common.h"
 
+#define MV78XX0_MBUS_PCIE_MEM_TARGET(port,lane) ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_MEM_ATTR(port,lane)   (0xf8 & ~(0x10 << (lane)))
+#define MV78XX0_MBUS_PCIE_IO_TARGET(port,lane)  ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_IO_ATTR(port,lane)    (0xf0 & ~(0x10 << (lane)))
+
 struct pcie_port {
 	u8			maj;
 	u8			min;
@@ -71,7 +76,6 @@ static void __init mv78xx0_pcie_preinit(void)
 	start = MV78XX0_PCIE_MEM_PHYS_BASE;
 	for (i = 0; i < num_pcie_ports; i++) {
 		struct pcie_port *pp = pcie_port + i;
-		char winname[MVEBU_MBUS_MAX_WINNAME_SZ];
 
 		snprintf(pp->mem_space_name, sizeof(pp->mem_space_name),
 			"PCIe %d.%d MEM", pp->maj, pp->min);
@@ -85,17 +89,12 @@ static void __init mv78xx0_pcie_preinit(void)
 		if (request_resource(&iomem_resource, &pp->res))
 			panic("can't allocate PCIe MEM sub-space");
 
-		snprintf(winname, sizeof(winname), "pcie%d.%d",
-			 pp->maj, pp->min);
-
-		mvebu_mbus_add_window_remap_flags(winname,
-						  pp->res.start,
-						  resource_size(&pp->res),
-						  MVEBU_MBUS_NO_REMAP,
-						  MVEBU_MBUS_PCI_MEM);
-		mvebu_mbus_add_window_remap_flags(winname,
-						  i * SZ_64K, SZ_64K,
-						  0, MVEBU_MBUS_PCI_IO);
+		mvebu_mbus_add_window_by_id(MV78XX0_MBUS_PCIE_MEM_TARGET(pp->maj, pp->min),
+					    MV78XX0_MBUS_PCIE_MEM_ATTR(pp->maj, pp->min),
+					    pp->res.start, resource_size(&pp->res));
+		mvebu_mbus_add_window_remap_by_id(MV78XX0_MBUS_PCIE_IO_TARGET(pp->maj, pp->min),
+						  MV78XX0_MBUS_PCIE_IO_ATTR(pp->maj, pp->min),
+						  i * SZ_64K, SZ_64K, 0);
 	}
 }
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:31 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:31 -0300
Subject: [RESEND PATCH v7 02/22] bus: mvebu-mbus: Add new API for window
 creation
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373900271-4722-3-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

We add an API to create MBus address decoding windows from the target
ID and attribute. This function will be used later and deprecate the
current name based scheme.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 33 +++++++++++++++++++++++++--------
 include/linux/mbus.h     |  6 ++++++
 2 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 33c6947..827468a 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -748,6 +748,22 @@ static const struct of_device_id of_mvebu_mbus_ids[] = {
 /*
  * Public API of the driver
  */
+int mvebu_mbus_add_window_remap_by_id(unsigned int target,
+				      unsigned int attribute,
+				      phys_addr_t base, size_t size,
+				      phys_addr_t remap)
+{
+	struct mvebu_mbus_state *s = &mbus_state;
+
+	if (!mvebu_mbus_window_conflicts(s, base, size, target, attribute)) {
+		pr_err("cannot add window '%x:%x', conflicts with another window\n",
+		       target, attribute);
+		return -EINVAL;
+	}
+
+	return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
+}
+
 int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 				      size_t size, phys_addr_t remap,
 				      unsigned int flags)
@@ -776,14 +792,8 @@ int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 	else if (flags == MVEBU_MBUS_PCI_WA)
 		attr |= 0x28;
 
-	if (!mvebu_mbus_window_conflicts(s, base, size, target, attr)) {
-		pr_err("cannot add window '%s', conflicts with another window\n",
-		       devname);
-		return -EINVAL;
-	}
-
-	return mvebu_mbus_alloc_window(s, base, size, remap, target, attr);
-
+	return mvebu_mbus_add_window_remap_by_id(target, attr, base,
+						 size, remap);
 }
 
 int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
@@ -792,6 +802,13 @@ int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
 						 MVEBU_MBUS_NO_REMAP, 0);
 }
 
+int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
+				phys_addr_t base, size_t size)
+{
+	return mvebu_mbus_add_window_remap_by_id(target, attribute, base,
+						 size, MVEBU_MBUS_NO_REMAP);
+}
+
 int mvebu_mbus_del_window(phys_addr_t base, size_t size)
 {
 	int win;
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index dba482e..9245b66 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -62,8 +62,14 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
 int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 				      size_t size, phys_addr_t remap,
 				      unsigned int flags);
+int mvebu_mbus_add_window_remap_by_id(unsigned int target,
+				      unsigned int attribute,
+				      phys_addr_t base, size_t size,
+				      phys_addr_t remap);
 int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
 			  size_t size);
+int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
+				phys_addr_t base, size_t size);
 int mvebu_mbus_del_window(phys_addr_t base, size_t size);
 int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
 		    size_t mbus_size, phys_addr_t sdram_phys_base,
-- 
1.8.1.5



From denis at eukrea.com  Mon Jul 15 10:57:03 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:57:03 +0200
Subject: [PATCH 18/22] staging: video: imx: Add RGB666 support for parallel
 display
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-19-git-send-email-denis@eukrea.com>

Support the RGB666 format on the IPUv3 parallel display.

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 .../bindings/staging/imx-drm/fsl-imx-drm.txt       |    2 +-
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c            |    9 +++++++++
 drivers/staging/imx-drm/parallel-display.c         |    2 ++
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index b876d49..2d24425 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -29,7 +29,7 @@ Required properties:
 - crtc: the crtc this display is connected to, see below
 Optional properties:
 - interface_pix_fmt: How this display is connected to the
-  crtc. Currently supported types: "rgb24", "rgb565", "bgr666"
+  crtc. Currently supported types: "rgb24", "rgb565", "bgr666", "rgb666"
 - edid: verbatim EDID data block describing attached display.
 - ddc: phandle describing the i2c bus handling the display data
   channel
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index 59f03f9..41049b9 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -91,6 +91,7 @@ enum ipu_dc_map {
 	IPU_DC_MAP_RGB565,
 	IPU_DC_MAP_GBR24, /* TVEv2 */
 	IPU_DC_MAP_BGR666,
+	IPU_DC_MAP_RGB666,
 };
 
 struct ipu_dc {
@@ -152,6 +153,8 @@ static int ipu_pixfmt_to_map(u32 fmt)
 		return IPU_DC_MAP_GBR24;
 	case V4L2_PIX_FMT_BGR666:
 		return IPU_DC_MAP_BGR666;
+	case V4L2_PIX_FMT_RGB666:
+		return IPU_DC_MAP_RGB666;
 	default:
 		return -EINVAL;
 	}
@@ -394,6 +397,12 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
 	ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /* green */
 	ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 17, 0xfc); /* red */
 
+	/* rgb666 */
+	ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
+	ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
+	ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1, 11, 0xfc); /* green */
+	ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 0, 5, 0xfc); /* blue */
+
 	return 0;
 }
 
diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-drm/parallel-display.c
index fee9b10..dd65236 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -236,6 +236,8 @@ static int imx_pd_probe(struct platform_device *pdev)
 			imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB565;
 		else if (!strcmp(fmt, "bgr666"))
 			imxpd->interface_pix_fmt = V4L2_PIX_FMT_BGR666;
+		else if (!strcmp(fmt, "rgb666"))
+			imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB666;
 	}
 
 	imxpd->dev = &pdev->dev;
-- 
1.7.9.5



From denis at eukrea.com  Mon Jul 15 10:57:07 2013
From: denis at eukrea.com (Denis Carikli)
Date: Mon, 15 Jul 2013 16:57:07 +0200
Subject: =?UTF-8?q?=5BPATCH=2022/22=5D=20arm/dts=3A=20Add=20support=20for=20the=20cpuimx35=20board=20from=20Eukrea=20and=20its=20baseboard=2E?=
In-Reply-To: <1373900227-341-1-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
Message-ID: <1373900227-341-23-git-send-email-denis@eukrea.com>

Only the following devices were added:
 * Main UART
 * Memory node
 * NAND
 * i2c and its pcf8563
 * Ethernet

Signed-off-by: Denis Carikli <denis at eukrea.com>
---
 Documentation/devicetree/bindings/arm/fsl.txt     |    4 ++
 arch/arm/boot/dts/eukrea_cpuimx35.dts             |   45 +++++++++++++++++++++
 arch/arm/boot/dts/eukrea_mbimxsd35-baseboard.dtsi |   19 +++++++++
 3 files changed, 68 insertions(+)
 create mode 100644 arch/arm/boot/dts/eukrea_cpuimx35.dts
 create mode 100644 arch/arm/boot/dts/eukrea_mbimxsd35-baseboard.dtsi

diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index 4001d91..40d5d22 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -21,6 +21,10 @@ i.MX28 Evaluation Kit
 Required root node properties:
     - compatible = "fsl,imx28-evk", "fsl,imx28";
 
+i.MX35 Eukrea CPUIMX35 Board
+Required root node properties:
+    - compatible = "fsl,eukrea_cpuimx35", "fsl,imx35";
+
 i.MX51 Babbage Board
 Required root node properties:
     - compatible = "fsl,imx51-babbage", "fsl,imx51";
diff --git a/arch/arm/boot/dts/eukrea_cpuimx35.dts b/arch/arm/boot/dts/eukrea_cpuimx35.dts
new file mode 100644
index 0000000..162df18c
--- /dev/null
+++ b/arch/arm/boot/dts/eukrea_cpuimx35.dts
@@ -0,0 +1,45 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique <denis at eukrea.com>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include "imx35.dtsi"
+#include "eukrea_mbimxsd35-baseboard.dtsi"
+/ {
+	model = "Eukrea CPUIMX35";
+	compatible = "fsl,eukrea_cpuimx35", "fsl,imx35";
+
+	memory {
+		reg = <0x80000000 0x8000000>; /* 128M */
+	};
+};
+
+&nand {
+	nand-bus-width = <8>;
+	nand-ecc-mode = "hw";
+	nand-on-flash-bbt;
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1_1>;
+	status = "okay";
+	pcf8563 at 51 {
+		compatible = "nxp,pcf8563";
+		reg = <0x51>;
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec_1>;
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/eukrea_mbimxsd35-baseboard.dtsi b/arch/arm/boot/dts/eukrea_mbimxsd35-baseboard.dtsi
new file mode 100644
index 0000000..7ac5572
--- /dev/null
+++ b/arch/arm/boot/dts/eukrea_mbimxsd35-baseboard.dtsi
@@ -0,0 +1,19 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique <denis at eukrea.com>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "skeleton.dtsi"
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1_1>;
+	fsl,uart-has-rtscts;
+	status = "okay";
+};
-- 
1.7.9.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 10:57:29 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 11:57:29 -0300
Subject: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
Message-ID: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>

Here's the new MBus DT binding, implementing the changes proposed
by Thomas when we discussed the previous patchset:

  http://www.spinics.net/lists/arm-kernel/msg257170.html

As far as I know, this round fixes *all* the concerns raised in the past
and therefore I'd like to get Acked-by's from all the parties involved
on the respective patches, and particularly for the DT binding.

If there's anything left to review, we'll be glad to fix it quickly,
so don't hesitate in providing your feedback!

I'm sure many of you are dying to test this new MBus thing, so to make
it easier for those courageous enough, I've pushed a public branch:

  https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v7

This patchset is based on v3.11-rc1.

Changelog
---------

v7:

 * Add two optional properties pcie-{mem,io}-aperture to the MBus node
   defining the PCIe mem and IO region apertures.

 * Encode the PCIe port in the second cell of the ranges entries, using
   the PCIe slot; and remove such encoding from the first cell, since it
   was violating the specification.

   Quoting Jason Gunthorpe:
   """ [...] the OF spec says that the phys.hi fields of the child address
   spaces in the "ranges" property for PCI does not contain the same
   information as "reg" property entries within PCI nodes. The only information
   that is present in "ranges" phys.hi entries are the non-relocatable,
   prefetchable and the PCI address space bits for which the entry applies.
   I.e., only the n, p and ss bits are present; the bbbbbbbb, ddddd, fff and
   rrrrrrrr fields are 0."""

v6:

 * Change the PCIe ranges translations encoding, removing the big fake
   window encoded as MBUS_ID(0xf0, 0x02) by an array of entries representing
   the PCIe real windows with full 4 GiB size.

 * The corresponding PCIe port is selected by encoding the bus in the first cell
   of the PCIe controller node ranges entry.

 * Remove the name-based MBus window allocation API, replacing it by an
   ID-based API.

v5:

 * Add a required a 'controller' property to specify a phandle containing
   the MBus controller MMIO registers.

v4:

 * Fixed the pcie-controller to mbus address space translations, to match
   a 1:1 mapping between the PCI and CPU busses.

 * Fixed the binding documentation with suggestions from Arnd Bergmann.

 * Added a BootROM sanity check on AXP SMP initialization, as suggested
   by Jason Gunthorpe. This also implied changing slightly the bootrom
   node.

 * Changed the first cell format for the MBus address space.

v3:

 * Replaced the PCIe mapping with 0xffff0002, to avoid using a representation
   that might correspond to a possible window id.

 * Remove every mbus-node 'ranges' property from the dtsi files. Having them
   on the per-board dts files only makes maintaince less painful.

 * Declare children window size, in the children 'ranges' property, as large
   as possible (4 GiB size) and move the property to the dtsi files.
   The per-board dts, does not need to declare that property now.

 * The MBus driver now creates the decoding window using the base address and
   size specified in the mbus-node, instead of using the children entries.

v2:

 * Use the preprocessor on the DT and define a macro for the window ID.

 * Changed the way the address spaces were declared: the window's base
   addresses are only present in the mbus-node ranges property.
   This makes sense since that information belongs only to the MBus
   address space.

 * Drop the ranges dynamic update, since now the DT translations are complete.

 * Replaced the internal register first cell mapping with 0xffff0001, to avoid
   clashing when using 0x00000000.

 * Replaced the PCIe mapping with 0xffff0000.

v1:

  * Initial proposal

Example
-------

Here's an example showing how the MBus DT binding looks now:

soc {
	compatible = "marvell,armadaxp-mbus", "simple-bus";
	controller = <&mbusc>;
	pcie-mem-aperture = <0xe0000000 0x8000000>;
	pcie-io-aperture  = <0xe8000000 0x100000>;

	ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
		  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
		  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;

	bootrom {
		compatible = "marvell,bootrom";
		reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
	};

	devbus-bootcs {
		status = "okay";
		ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;

		/* NOR */
		nor {
			compatible = "cfi-flash";
			reg = <0 0x8000000>;
			bank-width = <2>;
		};
	};

	pcie-controller {
		compatible = "marvell,armada-xp-pcie";
		status = "okay";
		device_type = "pci";
		#address-cells = <3>;
		#size-cells = <2>;

		ranges =
			<0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
			0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
			0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
			0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
			0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
			0x82000000 0x1 0       MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
			0x81000000 0x1 0       MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */
			0x82000000 0x2 0       MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
			0x81000000 0x2 0       MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */>;


		pcie at 1,0 {
			device_type = "pci";
			assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
			reg = <0x0800 0 0 0 0>;
			#address-cells = <3>;
			#size-cells = <2>;
			#interrupt-cells = <1>;
			ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
				  0x81000000 0 0 0x81000000 0x1 0 1 0>;
			interrupt-map-mask = <0 0 0 0>;
			interrupt-map = <0 0 0 0 &mpic 58>;
			marvell,pcie-port = <0>;
			marvell,pcie-lane = <0>;
			clocks = <&gateclk 5>;
			status = "disabled";
		};

		pcie at 2,0 {
			device_type = "pci";
			assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
			reg = <0x1000 0 0 0 0>;
			#address-cells = <3>;
			#size-cells = <2>;
			#interrupt-cells = <1>;
			ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
				  0x81000000 0 0 0x81000000 0x2 0 1 0>;
			interrupt-map-mask = <0 0 0 0>;
			interrupt-map = <0 0 0 0 &mpic 62>;
			marvell,pcie-port = <1>;
			marvell,pcie-lane = <0>;
			clocks = <&gateclk 9>;
			status = "disabled";
		};
	};

	internal-regs {
		compatible = "simple-bus";
		#address-cells = <1>;
		#size-cells = <1>;
		ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;

		mbusc: mbus-controller at 20000 {
			reg = <0x20000 0x100>, <0x20180 0x20>;
		};

		interrupt-controller at 20000 {
			reg = <0x20a00 0x2d0>, <0x21070 0x58>;
		};
	};
};


Ezequiel Garcia (12):
  memory: mvebu-devbus: Remove address decoding window workaround
  bus: mvebu-mbus: Factor out initialization details
  bus: mvebu-mbus: Introduce device tree binding
  bus: mvebu-mbus: Add static window allocation to the DT binding
  bus: mvebu-mbus: Add new API for the PCIe memory and IO aperture
  ARM: mvebu: Remove the harcoded BootROM window allocation
  ARM: mvebu: Initialize MBus using the DT binding
  ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
  ARM: mvebu: Add MBus to Armada 370/XP device tree
  ARM: mvebu: Add BootROM to Armada 370/XP device tree
  ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
  ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes

Thomas Petazzoni (10):
  bus: mvebu-mbus: Add new API for window creation
  ARM: kirkwood: Move to ID based MBus window creation
  ARM: mv78xx0: Move to ID based window creation
  ARM: orion5x: Move to ID based window creation
  ARM: dove: Move to ID based window creation
  PCI: mvebu: Adapt to the new device tree layout
  bus: mvebu-mbus: Remove the no longer used name-based API
  bus: mvebu-mbus: Remove name -> target, attribute mapping tables
  bus: mvebu-mbus: Update main description
  bus: mvebu-mbus: Factorize Armada 370/XP data structures

 .../devicetree/bindings/bus/mvebu-mbus.txt         | 267 +++++++++++++
 .../devicetree/bindings/pci/mvebu-pci.txt          | 145 +++++--
 arch/arm/boot/dts/armada-370-db.dts                |   5 +-
 arch/arm/boot/dts/armada-370-mirabox.dts           |  37 +-
 arch/arm/boot/dts/armada-370-rd.dts                |   5 +-
 arch/arm/boot/dts/armada-370-xp.dtsi               | 111 +++---
 arch/arm/boot/dts/armada-370.dtsi                  | 112 +++---
 arch/arm/boot/dts/armada-xp-db.dts                 | 131 +++----
 arch/arm/boot/dts/armada-xp-gp.dts                 | 107 +++--
 arch/arm/boot/dts/armada-xp-mv78230.dtsi           | 222 ++++++-----
 arch/arm/boot/dts/armada-xp-mv78260.dtsi           | 263 +++++++------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi           | 411 ++++++++++---------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |  88 ++---
 arch/arm/boot/dts/armada-xp.dtsi                   |   9 +-
 arch/arm/mach-dove/common.c                        |  68 ++--
 arch/arm/mach-kirkwood/common.c                    |  18 +-
 arch/arm/mach-kirkwood/pcie.c                      |  40 +-
 arch/arm/mach-mv78xx0/pcie.c                       |  23 +-
 arch/arm/mach-mvebu/armada-370-xp.c                |  34 +-
 arch/arm/mach-mvebu/platsmp.c                      |  25 +-
 arch/arm/mach-orion5x/common.c                     |  36 +-
 arch/arm/mach-orion5x/common.h                     |  17 +
 arch/arm/mach-orion5x/d2net-setup.c                |   6 +-
 arch/arm/mach-orion5x/db88f5281-setup.c            |  24 +-
 arch/arm/mach-orion5x/dns323-setup.c               |   6 +-
 arch/arm/mach-orion5x/edmini_v2-setup.c            |   6 +-
 arch/arm/mach-orion5x/kurobox_pro-setup.c          |  12 +-
 arch/arm/mach-orion5x/ls-chl-setup.c               |   6 +-
 arch/arm/mach-orion5x/ls_hgl-setup.c               |   6 +-
 arch/arm/mach-orion5x/lsmini-setup.c               |   6 +-
 arch/arm/mach-orion5x/mss2-setup.c                 |   6 +-
 arch/arm/mach-orion5x/mv2120-setup.c               |   6 +-
 arch/arm/mach-orion5x/net2big-setup.c              |   6 +-
 arch/arm/mach-orion5x/pci.c                        |   9 +-
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c       |   6 +-
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c        |   6 +-
 arch/arm/mach-orion5x/rd88f5182-setup.c            |  13 +-
 arch/arm/mach-orion5x/terastation_pro2-setup.c     |   6 +-
 arch/arm/mach-orion5x/ts209-setup.c                |   6 +-
 arch/arm/mach-orion5x/ts409-setup.c                |   6 +-
 arch/arm/mach-orion5x/wnr854t-setup.c              |   6 +-
 arch/arm/mach-orion5x/wrt350n-v2-setup.c           |   6 +-
 drivers/bus/mvebu-mbus.c                           | 435 ++++++++++++---------
 drivers/memory/mvebu-devbus.c                      |  64 +--
 drivers/pci/host/pci-mvebu.c                       | 113 ++++--
 include/linux/mbus.h                               |  16 +-
 46 files changed, 1775 insertions(+), 1181 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt

-- 
1.8.1.5



From maxime.ripard at free-electrons.com  Mon Jul 15 11:26:59 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 15 Jul 2013 17:26:59 +0200
Subject: [PATCH 0/3] Few ignored framebuffer fixes/additions
Message-ID: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>

Hi Andrew, 

Sorry to bother you again with the framebuffer stuff but the new
maintainer doesn't appear to be responsive either.k

This is a collection of patches that have been silently ignored,
despite being pinged numerous times:
  - Patch 1 has been sent for the first time on June 7 [1], resent on
    June 18 [2], plus two pings on July, 3rd [3] and July, 12th [4]. With
    no comments whatsoever.
  - Patch 2 has been sent on June, 21st [5]. Jean Christophe commented
    on it on June, 24th [6], but every attempts at getting clear
    explanations on what was expected have been ignored ever since
    (June 25th [7], July 12th [8])
  - Patch 3 was sent on June 21st along with Patch 2 [9]. There was
    comments on it and a second version was sent on June 24th
    [10]. Without any comments so far.

Could you take a look at those patches? We already missed 3.11, and
I'd really like not to miss another merge window because of the fbdev
curse.

Thanks,
Maxime

[1]: https://lkml.org/lkml/2013/6/7/116
[2]: https://lkml.org/lkml/2013/6/18/130
[3]: https://lkml.org/lkml/2013/7/3/105
[4]: https://lkml.org/lkml/2013/7/12/177
[5]: https://lkml.org/lkml/2013/6/21/405
[6]: https://lkml.org/lkml/2013/6/24/313
[7]: https://lkml.org/lkml/2013/6/25/274
[8]: https://lkml.org/lkml/2013/7/12/103
[9]: https://lkml.org/lkml/2013/6/21/407
[10]: https://lkml.org/lkml/2013/6/24/302

Alexandre Belloni (1):
  fb: backlight: HX8357: Add HX8369 support

Hector Palacios (1):
  video: mxsfb: fix color settings for 18bit data bus and 32bpp

Maxime Ripard (1):
  video: hx8357: Make IM pins optional

 drivers/video/backlight/hx8357.c | 255 +++++++++++++++++++++++++++++++++------
 drivers/video/mxsfb.c            |  26 ----
 2 files changed, 218 insertions(+), 63 deletions(-)

-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Mon Jul 15 11:27:00 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 15 Jul 2013 17:27:00 +0200
Subject: [PATCH 1/3] video: mxsfb: fix color settings for 18bit data bus and
 32bpp
In-Reply-To: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373902022-20439-2-git-send-email-maxime.ripard@free-electrons.com>

From: Hector Palacios <hector.palacios at digi.com>

For a combination of 18bit LCD data bus width and a color
mode of 32bpp, the driver was setting the color mapping to
rgb666, which is wrong, as the color in memory realy has an
rgb888 layout.

This patch also removes the setting of flag CTRL_DF24 that
makes the driver dimiss the upper 2 bits when handling 32/24bpp
colors in a diplay with 18bit data bus width. This flag made
true color images display wrong in such configurations.

Finally, the color mapping rgb666 has also been removed as nobody
is using it and high level applications like Qt5 cannot work
with it either.

Reference: https://lkml.org/lkml/2013/5/23/220
Signed-off-by: Hector Palacios <hector.palacios at digi.com>
Acked-by: Juergen Beisert <jbe at pengutronix.de>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/video/mxsfb.c | 26 --------------------------
 1 file changed, 26 deletions(-)

diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 3ba3771..dc09ebe 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -239,24 +239,6 @@ static const struct fb_bitfield def_rgb565[] = {
 	}
 };
 
-static const struct fb_bitfield def_rgb666[] = {
-	[RED] = {
-		.offset = 16,
-		.length = 6,
-	},
-	[GREEN] = {
-		.offset = 8,
-		.length = 6,
-	},
-	[BLUE] = {
-		.offset = 0,
-		.length = 6,
-	},
-	[TRANSP] = {	/* no support for transparency */
-		.length = 0,
-	}
-};
-
 static const struct fb_bitfield def_rgb888[] = {
 	[RED] = {
 		.offset = 16,
@@ -309,9 +291,6 @@ static int mxsfb_check_var(struct fb_var_screeninfo *var,
 			break;
 		case STMLCDIF_16BIT:
 		case STMLCDIF_18BIT:
-			/* 24 bit to 18 bit mapping */
-			rgb = def_rgb666;
-			break;
 		case STMLCDIF_24BIT:
 			/* real 24 bit */
 			rgb = def_rgb888;
@@ -453,11 +432,6 @@ static int mxsfb_set_par(struct fb_info *fb_info)
 			return -EINVAL;
 		case STMLCDIF_16BIT:
 		case STMLCDIF_18BIT:
-			/* 24 bit to 18 bit mapping */
-			ctrl |= CTRL_DF24; /* ignore the upper 2 bits in
-					    *  each colour component
-					    */
-			break;
 		case STMLCDIF_24BIT:
 			/* real 24 bit */
 			break;
-- 
1.8.3.2



From konrad.wilk at oracle.com  Mon Jul 15 11:27:14 2013
From: konrad.wilk at oracle.com (Konrad Rzeszutek Wilk)
Date: Mon, 15 Jul 2013 11:27:14 -0400
Subject: [PATCH] xen/control: protect functions with
 CONFIG_HIBERNATE_CALLBACKS to avoid warning
In-Reply-To: <1373898275-15765-1-git-send-email-julien.grall@linaro.org>
References: <1373898275-15765-1-git-send-email-julien.grall@linaro.org>
Message-ID: <20130715152714.GD5774@phenom.dumpdata.com>

On Mon, Jul 15, 2013 at 03:24:35PM +0100, Julien Grall wrote:
> If CONFIG_HIBERNATE_CALLBACKS is not set gcc will issue warnings:
> drivers/xen/manage.c:46:13: warning: 'xen_hvm_post_suspend' defined but not used [-Wunused-function]
> drivers/xen/manage.c:52:13: warning: 'xen_pre_suspend' defined but not used [-Wunused-function]
> drivers/xen/manage.c:59:13: warning: 'xen_post_suspend' defined but not used [-Wunused-function]

Have you checked the upstream kernel?
I see this:

commit 65e053a7038c608f89272d4fb1f899890c579f0a
Author: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Date:   Thu Jun 27 14:28:38 2013 +0100

    xen: ifdef CONFIG_HIBERNATE_CALLBACKS xen_*_suspend
    
    xen_hvm_post_suspend, xen_pre_suspend, xen_post_suspend are only used if
    CONFIG_HIBERNATE_CALLBACKS is defined, resulting in:
    
    drivers/xen/manage.c:46:13: warning: ?xen_hvm_post_suspend? defined but not used [-Wunused-function]
    drivers/xen/manage.c:52:13: warning: ?xen_pre_suspend? defined but not used [-Wunused-function]
    drivers/xen/manage.c:59:13: warning: ?xen_post_suspend? defined but not used [-Wunused-function]
    
    If the kernel config is missing CONFIG_HIBERNATE_CALLBACKS.
    
    Simply ifdef CONFIG_HIBERNATE_CALLBACKS the three functions.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>


> 
> Signed-off-by: Julien Grall <julien.grall at linaro.org>
> ---
>  drivers/xen/manage.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
> index 412b96c..7680276 100644
> --- a/drivers/xen/manage.c
> +++ b/drivers/xen/manage.c
> @@ -36,6 +36,7 @@ enum shutdown_state {
>  /* Ignore multiple shutdown requests. */
>  static enum shutdown_state shutting_down = SHUTDOWN_INVALID;
>  
> +#ifdef CONFIG_HIBERNATE_CALLBACKS
>  struct suspend_info {
>  	int cancelled;
>  	unsigned long arg; /* extra hypercall argument */
> @@ -63,7 +64,6 @@ static void xen_post_suspend(int cancelled)
>  	xen_mm_unpin_all();
>  }
>  
> -#ifdef CONFIG_HIBERNATE_CALLBACKS
>  static int xen_suspend(void *data)
>  {
>  	struct suspend_info *si = data;
> -- 
> 1.7.10.4
> 


From maxime.ripard at free-electrons.com  Mon Jul 15 11:27:01 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 15 Jul 2013 17:27:01 +0200
Subject: [PATCH 2/3] video: hx8357: Make IM pins optional
In-Reply-To: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373902022-20439-3-git-send-email-maxime.ripard@free-electrons.com>

The IM pins of the HX8357 controller are used to define the interface
used to feed pixel stream to the LCD panel.

Most of the time, these pins are directly routed to either the ground or
the VCC to set their values.

Remove the need to assign GPIOs to these pins when we are in such a case.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/video/backlight/hx8357.c | 52 +++++++++++++++++++++++-----------------
 1 file changed, 30 insertions(+), 22 deletions(-)

diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index a0482b5..ed94796 100644
--- a/drivers/video/backlight/hx8357.c
+++ b/drivers/video/backlight/hx8357.c
@@ -76,6 +76,7 @@ struct hx8357_data {
 	unsigned		reset;
 	struct spi_device	*spi;
 	int			state;
+	bool			use_im_pins;
 };
 
 static u8 hx8357_seq_power[] = {
@@ -250,9 +251,11 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
 	 * Set the interface selection pins to SPI mode, with three
 	 * wires
 	 */
-	gpio_set_value_cansleep(lcd->im_pins[0], 1);
-	gpio_set_value_cansleep(lcd->im_pins[1], 0);
-	gpio_set_value_cansleep(lcd->im_pins[2], 1);
+	if (lcd->use_im_pins) {
+		gpio_set_value_cansleep(lcd->im_pins[0], 1);
+		gpio_set_value_cansleep(lcd->im_pins[1], 0);
+		gpio_set_value_cansleep(lcd->im_pins[2], 1);
+	}
 
 	/* Reset the screen */
 	gpio_set_value(lcd->reset, 1);
@@ -424,26 +427,31 @@ static int hx8357_probe(struct spi_device *spi)
 		return -EINVAL;
 	}
 
-	for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
-		lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
-						"im-gpios", i);
-		if (lcd->im_pins[i] == -EPROBE_DEFER) {
-			dev_info(&spi->dev, "GPIO requested is not here yet, deferring the probe\n");
-			return -EPROBE_DEFER;
-		}
-		if (!gpio_is_valid(lcd->im_pins[i])) {
-			dev_err(&spi->dev, "Missing dt property: im-gpios\n");
-			return -EINVAL;
+	if (of_find_property(spi->dev.of_node, "im-gpios", NULL)) {
+		lcd->use_im_pins = 1;
+
+		for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
+			lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
+							    "im-gpios", i);
+			if (lcd->im_pins[i] == -EPROBE_DEFER) {
+				dev_info(&spi->dev, "GPIO requested is not here yet, deferring the probe\n");
+				return -EPROBE_DEFER;
+			}
+			if (!gpio_is_valid(lcd->im_pins[i])) {
+				dev_err(&spi->dev, "Missing dt property: im-gpios\n");
+				return -EINVAL;
+			}
+
+			ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
+						    GPIOF_OUT_INIT_LOW, "im_pins");
+			if (ret) {
+				dev_err(&spi->dev, "failed to request gpio %d: %d\n",
+					lcd->im_pins[i], ret);
+				return -EINVAL;
+			}
 		}
-
-		ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
-					GPIOF_OUT_INIT_LOW, "im_pins");
-		if (ret) {
-			dev_err(&spi->dev, "failed to request gpio %d: %d\n",
-				lcd->im_pins[i], ret);
-			return -EINVAL;
-		}
-	}
+	} else
+		lcd->use_im_pins = 0;
 
 	lcdev = lcd_device_register("mxsfb", &spi->dev, lcd, &hx8357_ops);
 	if (IS_ERR(lcdev)) {
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Mon Jul 15 11:27:02 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 15 Jul 2013 17:27:02 +0200
Subject: [PATCH 3/3] fb: backlight: HX8357: Add HX8369 support
In-Reply-To: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1373902022-20439-4-git-send-email-maxime.ripard@free-electrons.com>

From: Alexandre Belloni <alexandre.belloni at free-electrons.com>

Add support for the Himax HX8369 controller as it is quite similar to the
hx8357.

Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/video/backlight/hx8357.c | 203 ++++++++++++++++++++++++++++++++++++---
 1 file changed, 188 insertions(+), 15 deletions(-)

diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index ed94796..b035fab 100644
--- a/drivers/video/backlight/hx8357.c
+++ b/drivers/video/backlight/hx8357.c
@@ -71,6 +71,18 @@
 #define HX8357_SET_POWER_NORMAL		0xd2
 #define HX8357_SET_PANEL_RELATED	0xe9
 
+#define HX8369_SET_DISPLAY_BRIGHTNESS		0x51
+#define HX8369_WRITE_CABC_DISPLAY_VALUE		0x53
+#define HX8369_WRITE_CABC_BRIGHT_CTRL		0x55
+#define HX8369_WRITE_CABC_MIN_BRIGHTNESS	0x5e
+#define HX8369_SET_POWER			0xb1
+#define HX8369_SET_DISPLAY_MODE			0xb2
+#define HX8369_SET_DISPLAY_WAVEFORM_CYC		0xb4
+#define HX8369_SET_VCOM				0xb6
+#define HX8369_SET_EXTENSION_COMMAND		0xb9
+#define HX8369_SET_GIP				0xd5
+#define HX8369_SET_GAMMA_CURVE_RELATED		0xe0
+
 struct hx8357_data {
 	unsigned		im_pins[HX8357_NUM_IM_PINS];
 	unsigned		reset;
@@ -144,6 +156,61 @@ static u8 hx8357_seq_display_mode[] = {
 	HX8357_SET_DISPLAY_MODE_RGB_INTERFACE,
 };
 
+static u8 hx8369_seq_write_CABC_min_brightness[] = {
+	HX8369_WRITE_CABC_MIN_BRIGHTNESS, 0x00,
+};
+
+static u8 hx8369_seq_write_CABC_control[] = {
+	HX8369_WRITE_CABC_DISPLAY_VALUE, 0x24,
+};
+
+static u8 hx8369_seq_set_display_brightness[] = {
+	HX8369_SET_DISPLAY_BRIGHTNESS, 0xFF,
+};
+
+static u8 hx8369_seq_write_CABC_control_setting[] = {
+	HX8369_WRITE_CABC_BRIGHT_CTRL, 0x02,
+};
+
+static u8 hx8369_seq_extension_command[] = {
+	HX8369_SET_EXTENSION_COMMAND, 0xff, 0x83, 0x69,
+};
+
+static u8 hx8369_seq_display_related[] = {
+	HX8369_SET_DISPLAY_MODE, 0x00, 0x2b, 0x03, 0x03, 0x70, 0x00,
+	0xff, 0x00, 0x00, 0x00, 0x00, 0x03, 0x03, 0x00,	0x01,
+};
+
+static u8 hx8369_seq_panel_waveform_cycle[] = {
+	HX8369_SET_DISPLAY_WAVEFORM_CYC, 0x0a, 0x1d, 0x80, 0x06, 0x02,
+};
+
+static u8 hx8369_seq_set_address_mode[] = {
+	HX8357_SET_ADDRESS_MODE, 0x00,
+};
+
+static u8 hx8369_seq_vcom[] = {
+	HX8369_SET_VCOM, 0x3e, 0x3e,
+};
+
+static u8 hx8369_seq_gip[] = {
+	HX8369_SET_GIP, 0x00, 0x01, 0x03, 0x25, 0x01, 0x02, 0x28, 0x70,
+	0x11, 0x13, 0x00, 0x00, 0x40, 0x26, 0x51, 0x37, 0x00, 0x00, 0x71,
+	0x35, 0x60, 0x24, 0x07, 0x0f, 0x04, 0x04,
+};
+
+static u8 hx8369_seq_power[] = {
+	HX8369_SET_POWER, 0x01, 0x00, 0x34, 0x03, 0x00, 0x11, 0x11, 0x32,
+	0x2f, 0x3f, 0x3f, 0x01, 0x3a, 0x01, 0xe6, 0xe6, 0xe6, 0xe6, 0xe6,
+};
+
+static u8 hx8369_seq_gamma_curve_related[] = {
+	HX8369_SET_GAMMA_CURVE_RELATED, 0x00, 0x0d, 0x19, 0x2f, 0x3b, 0x3d,
+	0x2e, 0x4a, 0x08, 0x0e, 0x0f, 0x14, 0x16, 0x14, 0x14, 0x14, 0x1e,
+	0x00, 0x0d, 0x19, 0x2f, 0x3b, 0x3d, 0x2e, 0x4a, 0x08, 0x0e, 0x0f,
+	0x14, 0x16, 0x14, 0x14, 0x14, 0x1e,
+};
+
 static int hx8357_spi_write_then_read(struct lcd_device *lcdev,
 				u8 *txbuf, u16 txlen,
 				u8 *rxbuf, u16 rxlen)
@@ -242,6 +309,18 @@ static int hx8357_exit_standby(struct lcd_device *lcdev)
 	return 0;
 }
 
+static void hx8357_lcd_reset(struct lcd_device *lcdev)
+{
+	struct hx8357_data *lcd = lcd_get_data(lcdev);
+
+	gpio_set_value(lcd->reset, 1);
+	usleep_range(10000, 12000);
+	gpio_set_value(lcd->reset, 0);
+	usleep_range(10000, 12000);
+	gpio_set_value(lcd->reset, 1);
+	msleep(120);
+}
+
 static int hx8357_lcd_init(struct lcd_device *lcdev)
 {
 	struct hx8357_data *lcd = lcd_get_data(lcdev);
@@ -257,14 +336,6 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
 		gpio_set_value_cansleep(lcd->im_pins[2], 1);
 	}
 
-	/* Reset the screen */
-	gpio_set_value(lcd->reset, 1);
-	usleep_range(10000, 12000);
-	gpio_set_value(lcd->reset, 0);
-	usleep_range(10000, 12000);
-	gpio_set_value(lcd->reset, 1);
-	msleep(120);
-
 	ret = hx8357_spi_write_array(lcdev, hx8357_seq_power,
 				ARRAY_SIZE(hx8357_seq_power));
 	if (ret < 0)
@@ -359,6 +430,94 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
 	return 0;
 }
 
+static int hx8369_lcd_init(struct lcd_device *lcdev)
+{
+	int ret;
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_extension_command,
+				ARRAY_SIZE(hx8369_seq_extension_command));
+	if (ret < 0)
+		return ret;
+	usleep_range(10000, 12000);
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_display_related,
+				ARRAY_SIZE(hx8369_seq_display_related));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_panel_waveform_cycle,
+				ARRAY_SIZE(hx8369_seq_panel_waveform_cycle));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_set_address_mode,
+				ARRAY_SIZE(hx8369_seq_set_address_mode));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_vcom,
+				ARRAY_SIZE(hx8369_seq_vcom));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_gip,
+				ARRAY_SIZE(hx8369_seq_gip));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_power,
+				ARRAY_SIZE(hx8369_seq_power));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_byte(lcdev, HX8357_EXIT_SLEEP_MODE);
+	if (ret < 0)
+		return ret;
+
+	msleep(120);
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_gamma_curve_related,
+				ARRAY_SIZE(hx8369_seq_gamma_curve_related));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_byte(lcdev, HX8357_EXIT_SLEEP_MODE);
+	if (ret < 0)
+		return ret;
+	usleep_range(1000, 1200);
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_write_CABC_control,
+				ARRAY_SIZE(hx8369_seq_write_CABC_control));
+	if (ret < 0)
+		return ret;
+	usleep_range(10000, 12000);
+
+	ret = hx8357_spi_write_array(lcdev,
+			hx8369_seq_write_CABC_control_setting,
+			ARRAY_SIZE(hx8369_seq_write_CABC_control_setting));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_array(lcdev,
+			hx8369_seq_write_CABC_min_brightness,
+			ARRAY_SIZE(hx8369_seq_write_CABC_min_brightness));
+	if (ret < 0)
+		return ret;
+	usleep_range(10000, 12000);
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_set_display_brightness,
+				ARRAY_SIZE(hx8369_seq_set_display_brightness));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_ON);
+	if (ret < 0)
+		return ret;
+	msleep(100);
+
+	return 0;
+}
+
 #define POWER_IS_ON(pwr)	((pwr) <= FB_BLANK_NORMAL)
 
 static int hx8357_set_power(struct lcd_device *lcdev, int power)
@@ -391,10 +550,24 @@ static struct lcd_ops hx8357_ops = {
 	.get_power	= hx8357_get_power,
 };
 
+static const struct of_device_id hx8357_dt_ids[] = {
+	{
+		.compatible = "himax,hx8357",
+		.data = hx8357_lcd_init,
+	},
+	{
+		.compatible = "himax,hx8369",
+		.data = hx8369_lcd_init,
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, hx8357_dt_ids);
+
 static int hx8357_probe(struct spi_device *spi)
 {
 	struct lcd_device *lcdev;
 	struct hx8357_data *lcd;
+	const struct of_device_id *match;
 	int i, ret;
 
 	lcd = devm_kzalloc(&spi->dev, sizeof(*lcd), GFP_KERNEL);
@@ -411,6 +584,10 @@ static int hx8357_probe(struct spi_device *spi)
 
 	lcd->spi = spi;
 
+	match = of_match_device(hx8357_dt_ids, &spi->dev);
+	if (!match || !match->data)
+		return -EINVAL;
+
 	lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0);
 	if (!gpio_is_valid(lcd->reset)) {
 		dev_err(&spi->dev, "Missing dt property: gpios-reset\n");
@@ -460,7 +637,9 @@ static int hx8357_probe(struct spi_device *spi)
 	}
 	spi_set_drvdata(spi, lcdev);
 
-	ret = hx8357_lcd_init(lcdev);
+	hx8357_lcd_reset(lcdev);
+
+	ret = ((int (*)(struct lcd_device *))match->data)(lcdev);
 	if (ret) {
 		dev_err(&spi->dev, "Couldn't initialize panel\n");
 		goto init_error;
@@ -483,12 +662,6 @@ static int hx8357_remove(struct spi_device *spi)
 	return 0;
 }
 
-static const struct of_device_id hx8357_dt_ids[] = {
-	{ .compatible = "himax,hx8357" },
-	{},
-};
-MODULE_DEVICE_TABLE(of, hx8357_dt_ids);
-
 static struct spi_driver hx8357_driver = {
 	.probe  = hx8357_probe,
 	.remove = hx8357_remove,
-- 
1.8.3.2



From shc_work at mail.ru  Mon Jul 15 11:30:00 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Mon, 15 Jul 2013 19:30:00 +0400
Subject: =?UTF-8?B?UmU6IFtQQVRDSCAxMy8yMl0gbGNkOiBBZGQgR1BJTyBMQ0QgZHJpdmVyLg==?=
In-Reply-To: <1373900227-341-14-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-14-git-send-email-denis@eukrea.com>
Message-ID: <1373902200.734772008@f148.mail.ru>

> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  .../bindings/video/backlight/gpio-lcd.txt          |   15 ++
>  drivers/video/backlight/Kconfig                    |    8 +
>  drivers/video/backlight/Makefile                   |    1 +
>  drivers/video/backlight/gpio_lcd.c                 |  178 ++++++++++++++++++++
>  4 files changed, 202 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/backlight/gpio-lcd.txt
>  create mode 100644 drivers/video/backlight/gpio_lcd.c
> 
> diff --git a/Documentation/devicetree/bindings/video/backlight/gpio-lcd.txt b/Documentation/devicetree/bindings/video/backlight/gpio-lcd.txt
> new file mode 100644
> index 0000000..4ff409d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/backlight/gpio-lcd.txt
> @@ -0,0 +1,15 @@
> +gpio-lcd bindings
> +
> +Required properties:
> +  - compatible: "gpio-lcd"
> +  - gpios: describes the gpio that is used for enabling/disabling the lcd
> +     (see GPIO binding[0] for more details).
> +
> +[0]: Documentation/devicetree/bindings/gpio/gpio.txt
> +
> +Example:
> +
> +	lcd {
> +		compatible = "gpio-lcd";
> +		gpios = <&gpio3 13 0>;
> +	};
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 70e7706..eaf0525 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -34,6 +34,14 @@ config LCD_CORGI
>  	  Say y here to support the LCD panels usually found on SHARP
>  	  corgi (C7x0) and spitz (Cxx00) models.
>  
> +config LCD_GPIO
> +	tristate "LCD GPIO Driver"
> +	depends on OF && GPIOLIB
> +	help
> +	  If your LCD enbling/disabling is controlled by a GPIO
> +	  and that you use the device tree for booting,
> +	  say y to enable the LCD GPIO driver.
> +

Instead of using GPIO maybe it would be better to use a regulator here?
That would be a universal solution.
Thanks.

---

From balbi at ti.com  Mon Jul 15 11:33:39 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 15 Jul 2013 18:33:39 +0300
Subject: [PATCH 0/4] Enable USB3 for OMAP5
Message-ID: <1373902423-28654-1-git-send-email-balbi@ti.com>

Hi,

I have just tested all these patches on OMAP5 uEVM and it's
working fine.

| [1141397.137900] usb 10-2: USB disconnect, device number 3
| [1142023.549485] usb 10-2: new SuperSpeed USB device number 4 using xhci_hcd
| [1142024.185535] usb 10-2: Parent hub missing LPM exit latency info.  Power management will be impacted.
| [1142025.458738] usb 10-2: New USB device found, idVendor=0525, idProduct=a4a0
| [1142025.458744] usb 10-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
| [1142025.458748] usb 10-2: Product: Gadget Zero
| [1142025.458752] usb 10-2: Manufacturer: Linux 3.11.0-rc1-00068-g6df6cd3-dirty with dwc3-gadget
| [1142025.458755] usb 10-2: SerialNumber: 0123456789.0123456789.0123456789
| [1142025.866540] usbtest 10-2:3.0: Linux gadget zero
| [1142025.866547] usbtest 10-2:3.0: super-speed {control in/out bulk-in bulk-out} tests (+alt)

please consider applying them.

Benoit Cousson (1):
  arm: omap5: hwmod: add missing ocp2scp hwmod data

Felipe Balbi (3):
  arm: omap5: dts: fix reg property size
  arm: omap5: dts: add palmas-usb node
  arm: omap2plus_defconfig: enable dwc3 and dependencies

 arch/arm/boot/dts/omap5-uevm.dts           | 10 +++++++
 arch/arm/boot/dts/omap5.dtsi               |  9 +++---
 arch/arm/configs/omap2plus_defconfig       |  9 ++++++
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45 ++++++++++++++++++++++++++++++
 4 files changed, 69 insertions(+), 4 deletions(-)

-- 
1.8.2.1



From balbi at ti.com  Mon Jul 15 11:33:40 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 15 Jul 2013 18:33:40 +0300
Subject: [PATCH 1/4] arm: omap5: dts: fix reg property size
In-Reply-To: <1373902423-28654-1-git-send-email-balbi@ti.com>
References: <1373902423-28654-1-git-send-email-balbi@ti.com>
Message-ID: <1373902423-28654-2-git-send-email-balbi@ti.com>

USB3 block has a 64KiB space, another 64KiB is
used for the wrapper.

Without this change, resource_size() will get
confused and driver won't probe because size
will be negative.

Signed-off-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/boot/dts/omap5.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..5c99f19 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -637,7 +637,7 @@
 		omap_dwc3 at 4a020000 {
 			compatible = "ti,dwc3";
 			ti,hwmods = "usb_otg_ss";
-			reg = <0x4a020000 0x1000>;
+			reg = <0x4a020000 0x10000>;
 			interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
 			#address-cells = <1>;
 			#size-cells = <1>;
@@ -645,7 +645,7 @@
 			ranges;
 			dwc3 at 4a030000 {
 				compatible = "synopsys,dwc3";
-				reg = <0x4a030000 0x1000>;
+				reg = <0x4a030000 0x10000>;
 				interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
 				usb-phy = <&usb2_phy>, <&usb3_phy>;
 				tx-fifo-resize;
-- 
1.8.2.1



From balbi at ti.com  Mon Jul 15 11:33:41 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 15 Jul 2013 18:33:41 +0300
Subject: [PATCH 2/4] arm: omap5: hwmod: add missing ocp2scp hwmod data
In-Reply-To: <1373902423-28654-1-git-send-email-balbi@ti.com>
References: <1373902423-28654-1-git-send-email-balbi@ti.com>
Message-ID: <1373902423-28654-3-git-send-email-balbi@ti.com>

From: Benoit Cousson <benoit.cousson at linaro.org>

without that hwmod data, USB3 will not in OMAP5 boards.

While at that, also fix DTS data to pass reg property,
otherwise driver won't probe.

Signed-off-by: Benoit Cousson <benoit.cousson at linaro.org>
Signed-off-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/boot/dts/omap5.dtsi               |  3 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45 ++++++++++++++++++++++++++++++
 2 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 5c99f19..4e41409 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -652,10 +652,11 @@
 			};
 		};
 
-		ocp2scp {
+		ocp2scp at 4a080000 {
 			compatible = "ti,omap-ocp2scp";
 			#address-cells = <1>;
 			#size-cells = <1>;
+			reg = <0x4a080000 0x20>;
 			ranges;
 			ti,hwmods = "ocp2scp1";
 			usb2_phy: usb2phy at 4a084000 {
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index f37ae96..542eddd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1114,6 +1114,42 @@ static struct omap_hwmod omap54xx_mpu_hwmod = {
 };
 
 /*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_ocp2scp_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+			SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_ocp2scp_hwmod_class = {
+	.name	= "ocp2scp",
+	.sysc	= &omap54xx_ocp2scp_sysc,
+};
+
+/* ocp2scp1 */
+static struct omap_hwmod omap54xx_ocp2scp1_hwmod = {
+	.name		= "ocp2scp1",
+	.class		= &omap54xx_ocp2scp_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.main_clk	= "l4_root_clk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L3INIT_OCP2SCP1_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L3INIT_OCP2SCP1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/*
  * 'timer' class
  * general purpose timer module with accurate 1ms tick
  * This class contains several variants: ['timer_1ms', 'timer']
@@ -1919,6 +1955,14 @@ static struct omap_hwmod_ocp_if omap54xx_l4_cfg__mpu = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_cfg -> ocp2scp1 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp1 = {
+	.master		= &omap54xx_l4_cfg_hwmod,
+	.slave		= &omap54xx_ocp2scp1_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_wkup -> timer1 */
 static struct omap_hwmod_ocp_if omap54xx_l4_wkup__timer1 = {
 	.master		= &omap54xx_l4_wkup_hwmod,
@@ -2121,6 +2165,7 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] __initdata = {
 	&omap54xx_l4_per__mmc4,
 	&omap54xx_l4_per__mmc5,
 	&omap54xx_l4_cfg__mpu,
+	&omap54xx_l4_cfg__ocp2scp1,
 	&omap54xx_l4_wkup__timer1,
 	&omap54xx_l4_per__timer2,
 	&omap54xx_l4_per__timer3,
-- 
1.8.2.1



From balbi at ti.com  Mon Jul 15 11:33:42 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 15 Jul 2013 18:33:42 +0300
Subject: [PATCH 3/4] arm: omap5: dts: add palmas-usb node
In-Reply-To: <1373902423-28654-1-git-send-email-balbi@ti.com>
References: <1373902423-28654-1-git-send-email-balbi@ti.com>
Message-ID: <1373902423-28654-4-git-send-email-balbi@ti.com>

Without this node, there will be no palmas
driver to notify dwc3 that a cable has
been connected and, without that, dwc3
will never initialize.

Signed-off-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/boot/dts/omap5-uevm.dts | 10 ++++++++++
 arch/arm/boot/dts/omap5.dtsi     |  2 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..badceb8 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -272,6 +272,11 @@
 		interrupt-controller;
 		#interrupt-cells = <2>;
 
+		extcon_usb3: palmas_usb {
+			compatible = "ti,palmas-usb";
+			ti,wakeup;
+		};
+
 		palmas_pmic {
 			compatible = "ti,palmas-pmic";
 			interrupt-parent = <&palmas>;
@@ -450,6 +455,11 @@
 	phys = <0 &hsusb2_phy &hsusb3_phy>;
 };
 
+&usb3 {
+	extcon = <&extcon_usb3>;
+	vbus-supply = <&smps10_reg>;
+};
+
 &mcspi1 {
 
 };
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 4e41409..1659246 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -634,7 +634,7 @@
 			ti,type = <2>;
 		};
 
-		omap_dwc3 at 4a020000 {
+		usb3: omap_dwc3 at 4a020000 {
 			compatible = "ti,dwc3";
 			ti,hwmods = "usb_otg_ss";
 			reg = <0x4a020000 0x10000>;
-- 
1.8.2.1



From balbi at ti.com  Mon Jul 15 11:33:43 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 15 Jul 2013 18:33:43 +0300
Subject: [PATCH 4/4] arm: omap2plus_defconfig: enable dwc3 and dependencies
In-Reply-To: <1373902423-28654-1-git-send-email-balbi@ti.com>
References: <1373902423-28654-1-git-send-email-balbi@ti.com>
Message-ID: <1373902423-28654-5-git-send-email-balbi@ti.com>

DWC3 enables USB3 functionality for OMAP5 boards,
it's safe to enable those drivers in omap2plus_defconfig.

Signed-off-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/configs/omap2plus_defconfig | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 5339e6a..aed3cce 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -81,6 +81,7 @@ CONFIG_CMA=y
 CONFIG_CONNECTOR=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_OMAP_OCP2SCP=y
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_CHAR=y
@@ -167,9 +168,11 @@ CONFIG_THERMAL_GOV_USER_SPACE=y
 CONFIG_CPU_THERMAL=y
 CONFIG_OMAP_WATCHDOG=y
 CONFIG_TWL4030_WATCHDOG=y
+CONFIG_MFD_PALMAS=y
 CONFIG_MFD_TPS65217=y
 CONFIG_MFD_TPS65910=y
 CONFIG_TWL6040_CORE=y
+CONFIG_REGULATOR_PALMAS=y
 CONFIG_REGULATOR_TWL4030=y
 CONFIG_REGULATOR_TPS65023=y
 CONFIG_REGULATOR_TPS6507X=y
@@ -222,10 +225,14 @@ CONFIG_USB_MON=y
 CONFIG_USB_WDM=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_LIBUSUAL=y
+CONFIG_USB_DWC3=m
+CONFIG_USB_DWC3_OMAP=m
 CONFIG_USB_TEST=y
 CONFIG_USB_PHY=y
 CONFIG_NOP_USB_XCEIV=y
 CONFIG_USB_GADGET=y
+CONFIG_OMAP_USB2=y
+CONFIG_OMAP_USB3=y
 CONFIG_USB_GADGET_DEBUG=y
 CONFIG_USB_GADGET_DEBUG_FILES=y
 CONFIG_USB_GADGET_DEBUG_FS=y
@@ -258,6 +265,8 @@ CONFIG_TI_THERMAL=y
 CONFIG_OMAP4_THERMAL=y
 CONFIG_OMAP5_THERMAL=y
 CONFIG_DRA752_THERMAL=y
+CONFIG_EXTCON=y
+CONFIG_EXTCON_PALMAS=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 # CONFIG_EXT3_FS_XATTR is not set
-- 
1.8.2.1



From swarren at wwwdotorg.org  Mon Jul 15 11:34:19 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 09:34:19 -0600
Subject: [PATCHv5 00/11] MSI support for Marvell EBU PCIe driver
In-Reply-To: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <51E4167B.4000208@wwwdotorg.org>

On 07/15/2013 05:52 AM, Thomas Petazzoni wrote:
> Hello,
> 
> This set of patches introduces Message Signaled Interrupt support in
> the Marvell EBU PCIe driver. It has been successfully tested on the
> Armada XP GP platform with an Intel e1000e PCIe network card that
> supports MSI.
> 
> This patch set is intended for merging in 3.12, so the respective
> maintainers of the different areas are invited to review/ack the
> patches, see below for the details. This set of patches applies on top
> of 3.11-rc1.

Thomas, who is going to merge this series?

I believe at least patches 1-8 (or perhaps just 1-5 plus 8; I /think/
all the other patches are MVEBU-specific) are dependencies for the new
Tegra PCIe driver which should be posted very soon for 3.12. As such,
I'd like to see these dependencies merged into a standalone stable (100%
non-rebasable) topic branch based on 3.11-rc1 so that the topic branch
is available for merging into whichever tree takes the new Tegra PCIe
driver (which I'm guessing will be the Tegra tree to reduce conflicts).
So, whoever merges these patches is going to need to know to set up that
topic branch.

Thierry, please correct me if I'm wrong here.


From thomas.petazzoni at free-electrons.com  Mon Jul 15 11:34:09 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 17:34:09 +0200
Subject: [RFC PATCH 2/3] net: phy: call mdiobus_scan() after adding a fixed PHY
In-Reply-To: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373902450-11857-3-git-send-email-thomas.petazzoni@free-electrons.com>

The fixed_phy_add() function allows to register a fixed PHY. However,
when this function gets called *after* fixed_mdio_bus_init() (which
gets called at the module_init stage), then the fixed PHY is not
registered into the phylib.

In order to address this, we add a call to mdiobus_scan() in
fixed_phy_add() to ensure that the PHY indeed gets registered into the
phylib, even if the fixed_phy_add() is called after
fixed_mdio_bus_init().

This is needed because until now, the only code that was calling the
fixed_add_phy() function was PowerPC-specific platform code, which
could ensure that such fixed PHYs get registered before
fixed_mdio_bus_init() is called.

However, with the new of_phy_register_fixed_link() function, device
drivers can parse their 'fixed-link' property and register a fixed PHY
at ->probe() time, which may happen after fixed_mdio_bus_init() is
called.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/net/phy/fixed.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index ba55adf..bd1e67a 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -195,6 +195,8 @@ int fixed_phy_add(unsigned int irq, int phy_id,
 
 	list_add_tail(&fp->node, &fmb->phys);
 
+	mdiobus_scan(fmb->mii_bus, phy_id);
+
 	return 0;
 
 err_regs:
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 11:34:07 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 17:34:07 +0200
Subject: [RFC PATCH 0/3] Add DT support for fixed PHYs
Message-ID: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello,

Following the discussion of last week with Florian Fainelli and Grant
Likely [1], this patch set introduces DT-based support for fixed PHYs
through an additional OF API, and uses it in the context of the
Marvell mvneta network driver.

Grant, Rob, your opinions as DT maintainers are welcome. Thanks!

Thomas

[1] http://www.spinics.net/lists/netdev/msg242766.html
    http://www.spinics.net/lists/netdev/msg243192.html

Thomas Petazzoni (3):
  of: provide a binding for the 'fixed-link' property
  net: phy: call mdiobus_scan() after adding a fixed PHY
  net: mvneta: add support for fixed links

 .../devicetree/bindings/net/fixed-link.txt         | 26 ++++++++++++++++
 .../bindings/net/marvell-armada-370-neta.txt       | 24 +++++++++++++--
 drivers/net/ethernet/marvell/mvneta.c              | 18 ++++++++---
 drivers/net/phy/fixed.c                            |  2 ++
 drivers/of/of_mdio.c                               | 36 +++++++++++++++++++---
 include/linux/of_mdio.h                            | 10 ++++++
 6 files changed, 104 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/fixed-link.txt

-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 11:34:08 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 17:34:08 +0200
Subject: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link' property
In-Reply-To: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>

Some Ethernet MACs have a "fixed link", and are not connected to a
normal MDIO-managed PHY device. For those situations, a Device Tree
binding allows to describe a "fixed link", as a "fixed-link" property
of the Ethernet device Device Tree node.

This patch adds:

 * A documentation for the Device Tree property "fixed-link".

 * A of_phy_register_fixed_link() OF helper, which provided an OF node
   that contains a "fixed-link" property, registers the corresponding
   fixed PHY.

 * Removes the warning on the of_phy_connect_fixed_link() that says
   new drivers should not use it, since Grant Likely indicated that
   this "fixed-link" property is indeed the way to go.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../devicetree/bindings/net/fixed-link.txt         | 26 ++++++++++++++++
 drivers/of/of_mdio.c                               | 36 +++++++++++++++++++---
 include/linux/of_mdio.h                            | 10 ++++++
 3 files changed, 68 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/fixed-link.txt

diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt
new file mode 100644
index 0000000..25a009a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fixed-link.txt
@@ -0,0 +1,26 @@
+Fixed link Device Tree binding
+------------------------------
+
+Some Ethernet MACs have a "fixed link", and are not connected to a
+normal MDIO-managed PHY device. For those situations, a Device Tree
+binding allows to describe a "fixed link".
+
+Such a fixed link situation is described within an Ethernet device
+Device Tree node using a 'fixed-link' property, composed of 5
+elements:
+
+ 1. A fake PHY ID, which must be unique accross all fixed-link PHYs in
+    the system.
+ 2. The duplex (1 for full-duplex, 0 for half-duplex)
+ 3. The speed (10, 100, 1000)
+ 4. The pause setting (1 for enabled, 0 for disabled)
+ 5. The asym pause setting (1 for enabled, 0 for disabled)
+
+Example:
+
+ethernet at 0 {
+	...
+	fixed-link = <1 1 1000 0 0>;
+	...
+};
+
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index d5a57a9..66d5591 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -14,6 +14,7 @@
 #include <linux/netdevice.h>
 #include <linux/err.h>
 #include <linux/phy.h>
+#include <linux/phy_fixed.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/of_mdio.h>
@@ -215,10 +216,6 @@ EXPORT_SYMBOL(of_phy_connect);
  * @dev: pointer to net_device claiming the phy
  * @hndlr: Link state callback for the network device
  * @iface: PHY data interface type
- *
- * This function is a temporary stop-gap and will be removed soon.  It is
- * only to support the fs_enet, ucc_geth and gianfar Ethernet drivers.  Do
- * not call this function from new drivers.
  */
 struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
 					     void (*hndlr)(struct net_device *),
@@ -247,3 +244,34 @@ struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
 	return IS_ERR(phy) ? NULL : phy;
 }
 EXPORT_SYMBOL(of_phy_connect_fixed_link);
+
+#if defined(CONFIG_FIXED_PHY)
+/**
+ * of_phy_register_fixed_link - Parse fixed-link property and register a dummy phy
+ * @np: pointer to the OF device node that contains the "fixed-link"
+ * property for which a dummy phy should be registered.
+ */
+#define FIXED_LINK_PROPERTIES_COUNT 5
+int of_phy_register_fixed_link(struct device_node *np)
+{
+	struct fixed_phy_status status = {};
+	u32 fixed_link_props[FIXED_LINK_PROPERTIES_COUNT];
+	int ret;
+
+	ret = of_property_read_u32_array(np, "fixed-link",
+					 fixed_link_props,
+					 FIXED_LINK_PROPERTIES_COUNT);
+	if (ret < 0)
+		return ret;
+
+	status.link       = 1;
+	status.duplex     = fixed_link_props[1];
+	status.speed      = fixed_link_props[2];
+	status.pause      = fixed_link_props[3];
+	status.asym_pause = fixed_link_props[4];
+
+	return fixed_phy_add(PHY_POLL, fixed_link_props[0],
+			     &status);
+}
+EXPORT_SYMBOL(of_phy_register_fixed_link);
+#endif
diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
index 8163107..bf6efea 100644
--- a/include/linux/of_mdio.h
+++ b/include/linux/of_mdio.h
@@ -57,4 +57,14 @@ static inline struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np)
 }
 #endif /* CONFIG_OF */
 
+#if defined(CONFIG_OF) && defined(CONFIG_FIXED_PHY)
+extern int of_phy_register_fixed_link(struct device_node *np);
+#else
+static inline int of_phy_register_fixed_link(struct device_node *np)
+{
+	return -ENOSYS;
+}
+#endif
+
+
 #endif /* __LINUX_OF_MDIO_H */
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 15 11:34:10 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 17:34:10 +0200
Subject: [RFC PATCH 3/3] net: mvneta: add support for fixed links
In-Reply-To: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1373902450-11857-4-git-send-email-thomas.petazzoni@free-electrons.com>

Following the introduction of of_phy_register_fixed_link(), this patch
introduces fixed link support in the mvneta driver, for Marvell Armada
370/XP SOCs.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../bindings/net/marvell-armada-370-neta.txt       | 24 +++++++++++++++++++---
 drivers/net/ethernet/marvell/mvneta.c              | 18 +++++++++++-----
 2 files changed, 34 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
index 859a6fa..31e61c0 100644
--- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
+++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
@@ -4,13 +4,21 @@ Required properties:
 - compatible: should be "marvell,armada-370-neta".
 - reg: address and length of the register set for the device.
 - interrupts: interrupt for the device
-- phy: A phandle to a phy node defining the PHY address (as the reg
-  property, a single integer).
 - phy-mode: The interface between the SoC and the PHY (a string that
   of_get_phy_mode() can understand)
 - clocks: a pointer to the reference clock for this device.
 
-Example:
+Optional properties:
+
+- phy: A phandle to a phy node defining the PHY address (as the reg
+  property, a single integer). Note: if this property isn't present,
+  then fixed link is assumed, and the 'fixed-link' property is
+  mandatory.
+- fixed-link: A 5 elements array that describe a fixed link, see
+  fixed-link.txt for details. Note: if a 'phy' property is present,
+  this 'fixed-link' property is ignored.
+
+Examples:
 
 ethernet at d0070000 {
 	compatible = "marvell,armada-370-neta";
@@ -21,3 +29,13 @@ ethernet at d0070000 {
 	phy = <&phy0>;
 	phy-mode = "rgmii-id";
 };
+
+ethernet at d0070000 {
+	compatible = "marvell,armada-370-neta";
+	reg = <0xd0070000 0x2500>;
+	interrupts = <8>;
+	clocks = <&gate_clk 4>;
+	status = "okay";
+	fixed-link = <1 1 1000 0 0>;
+	phy-mode = "rgmii-id";
+};
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 712779f..0bd1590 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2349,8 +2349,12 @@ static int mvneta_mdio_probe(struct mvneta_port *pp)
 {
 	struct phy_device *phy_dev;
 
-	phy_dev = of_phy_connect(pp->dev, pp->phy_node, mvneta_adjust_link, 0,
-				 pp->phy_interface);
+	if (pp->phy_node)
+		phy_dev = of_phy_connect(pp->dev, pp->phy_node, mvneta_adjust_link, 0,
+					 pp->phy_interface);
+	else
+		phy_dev = of_phy_connect_fixed_link(pp->dev, mvneta_adjust_link,
+						    pp->phy_interface);
 	if (!phy_dev) {
 		netdev_err(pp->dev, "could not find the PHY\n");
 		return -ENODEV;
@@ -2708,9 +2712,13 @@ static int mvneta_probe(struct platform_device *pdev)
 
 	phy_node = of_parse_phandle(dn, "phy", 0);
 	if (!phy_node) {
-		dev_err(&pdev->dev, "no associated PHY\n");
-		err = -ENODEV;
-		goto err_free_irq;
+		/* No 'phy' found, see if we have a 'fixed-link'
+		 * property */
+		err = of_phy_register_fixed_link(dn);
+		if (err < 0) {
+			dev_err(&pdev->dev, "no 'phy' or 'fixed-link' properties\n");
+			goto err_free_irq;
+		}
 	}
 
 	phy_mode = of_get_phy_mode(dn);
-- 
1.8.1.2



From festevam at gmail.com  Mon Jul 15 11:39:43 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 15 Jul 2013 12:39:43 -0300
Subject: [PATCH 1/5] ARM: dts: imx23-evk: enable USB PHY and controller
In-Reply-To: <1373898160-8460-1-git-send-email-otavio@ossystems.com.br>
References: <1373898160-8460-1-git-send-email-otavio@ossystems.com.br>
Message-ID: <CAOMZO5C_7nJ9RVYvuKJHP2u0mYY6P2UyGVA6OpPzqTnd7YXN2Q@mail.gmail.com>

Hi Otavio,

On Mon, Jul 15, 2013 at 11:22 AM, Otavio Salvador
<otavio at ossystems.com.br> wrote:
> The i.MX23EVK board provides a USB port so the USB PHY and controller
> need to be enabled for it to be usable.
>
> Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
> ---

You should have Cc'd Shawn Guo on this series.


From kishon at ti.com  Mon Jul 15 11:43:32 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 15 Jul 2013 21:13:32 +0530
Subject: [PATCH 2/4] arm: omap5: hwmod: add missing ocp2scp hwmod data
In-Reply-To: <1373902423-28654-3-git-send-email-balbi@ti.com>
References: <1373902423-28654-1-git-send-email-balbi@ti.com>
 <1373902423-28654-3-git-send-email-balbi@ti.com>
Message-ID: <51E418A4.9000109@ti.com>

Hi,

On Monday 15 July 2013 09:03 PM, Felipe Balbi wrote:
> From: Benoit Cousson <benoit.cousson at linaro.org>
> 
> without that hwmod data, USB3 will not in OMAP5 boards.
> 
> While at that, also fix DTS data to pass reg property,
> otherwise driver won't probe.
> 
> Signed-off-by: Benoit Cousson <benoit.cousson at linaro.org>
> Signed-off-by: Felipe Balbi <balbi at ti.com>
> ---
>  arch/arm/boot/dts/omap5.dtsi               |  3 +-
>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45 ++++++++++++++++++++++++++++++
>  2 files changed, 47 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 5c99f19..4e41409 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -652,10 +652,11 @@
>  			};
>  		};
>  
> -		ocp2scp {
> +		ocp2scp at 4a080000 {

While at that, can we also name it ocp2scp1 since we have 3 instances of
ocp2scp and it'll conflict when we want to add it for SATA and PCIE.

Thanks
Kishon


From valentin.longchamp at keymile.com  Mon Jul 15 11:46:12 2013
From: valentin.longchamp at keymile.com (Valentin Longchamp)
Date: Mon, 15 Jul 2013 17:46:12 +0200
Subject: pci-mvebu driver on km_kirkwood
In-Reply-To: <20130712105903.6336e912@skate>
References: <51DD88A4.1030506@keymile.com>	<20130710185706.72b124a4@skate>
 <51DD9A8C.10608@keymile.com>	<51DE58DF.5010304@keymile.com>
 <20130712105903.6336e912@skate>
Message-ID: <51E41944.6030403@keymile.com>

Hello Thomas,

On 07/12/2013 10:59 AM, Thomas Petazzoni wrote:
> Dear Valentin Longchamp,
> 
> On Thu, 11 Jul 2013 09:03:59 +0200, Valentin Longchamp wrote:
> 
>> On the board you are currently using for your tests, it is the case (the whole
>> map is not used ... things are scattered over the 256 MB, with one 128MB BAR).
>> If you want to get rid of this problem, we have another board that does not
>> require these (256 MB .. and I have one of them on my desk that you can use for
>> your tests).
>>
>> On the kirkwood variant we use, there is only _one_ real PCIe controller. In
>> order to map 256MB for the MEM space of this controller without having further
>> memory map conflicts, what was done was to not enable the CPU windows for the
>> usual 2nd PCIe controller and set a wider CPU window for the MEM space of the
>> only PCIe controller.
> 
> Such tricks are no longer needed with the new PCIe driver. Instead of
> assigning address ranges per PCIe controller, the new PCIe driver
> (together with the mvebu-mbus driver) allows to specify one global
> range of addresses for PCIe mem, and the PCIe driver will automatically
> figure out which devices are available on which PCIe bus, how much PCIe
> mem then need, and create the MBus windows accordingly.
> 
> However of course, as I pointed out in an earlier e-mail, this global
> range must be suitably sized to allow the mapping of all PCIe devices.
> By default, we've made it 128 MB large, but in this case, it looks like
> you would need 256 MB.
> 
> But there's no need to disable the second PCIe controller anymore. If
> there's nothing connected to it, not PCIe window will be created for it.

Thank you for this precision. That's a nice feature of the new PCIe driver.

> 
>>> - we need a virtual PCIe device to connect to the internal switch, which 
>>> must be mapped at 0xf4000000 (normally used for the NAND which must then 
>>> move to 0xff000000)
>>>
>>
>> I think you can forget this for the time being. This is called (also in
>> Marvell's doc) a virtual PCIe controller, but apart that it is then memory
>> mapped, this has nothing to do with PCIe (although I don't know what is done
>> internally in the SoC). It is a problem because the physical address chosen for
>> this CPU window conflicts with the one that is used for the NAND controller in
>> the current kirkwood Linux memory map. But this is another topic and it should
>> not play any role in this PCIe topic.
> 
> I'm not sure to follow this story of a virtual PCIe controller sitting
> at 0xf4000000. Can you give a few more details?
> 

I'm not sure I can give all the details here as the documentation that we have
for this is subject to an NDA. To keep it short, in the kirkwood SoC we use,
there is an Ethernet Switch that is accessed by the kirkwood through an internal
virtual PCIe controller. The switch management SW has some hard expectations
about the physical address for this "PCIe" memory mapped window which conflicts
with the ones defined in the current device trees.

Valentin



From balbi at ti.com  Mon Jul 15 11:46:03 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 15 Jul 2013 18:46:03 +0300
Subject: [PATCH 2/4] arm: omap5: hwmod: add missing ocp2scp hwmod data
In-Reply-To: <51E418A4.9000109@ti.com>
References: <1373902423-28654-1-git-send-email-balbi@ti.com>
 <1373902423-28654-3-git-send-email-balbi@ti.com>
 <51E418A4.9000109@ti.com>
Message-ID: <20130715154603.GC32035@arwen.pp.htv.fi>

On Mon, Jul 15, 2013 at 09:13:32PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Monday 15 July 2013 09:03 PM, Felipe Balbi wrote:
> > From: Benoit Cousson <benoit.cousson at linaro.org>
> > 
> > without that hwmod data, USB3 will not in OMAP5 boards.
> > 
> > While at that, also fix DTS data to pass reg property,
> > otherwise driver won't probe.
> > 
> > Signed-off-by: Benoit Cousson <benoit.cousson at linaro.org>
> > Signed-off-by: Felipe Balbi <balbi at ti.com>
> > ---
> >  arch/arm/boot/dts/omap5.dtsi               |  3 +-
> >  arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45 ++++++++++++++++++++++++++++++
> >  2 files changed, 47 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> > index 5c99f19..4e41409 100644
> > --- a/arch/arm/boot/dts/omap5.dtsi
> > +++ b/arch/arm/boot/dts/omap5.dtsi
> > @@ -652,10 +652,11 @@
> >  			};
> >  		};
> >  
> > -		ocp2scp {
> > +		ocp2scp at 4a080000 {
> 
> While at that, can we also name it ocp2scp1 since we have 3 instances of
> ocp2scp and it'll conflict when we want to add it for SATA and PCIE.

Tony/Benoit, you want that in same patch or as a separate patch
altogether ?

-- 
balbi
-------------- 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/20130715/a33075f5/attachment.sig>

From florian at openwrt.org  Mon Jul 15 11:46:05 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Mon, 15 Jul 2013 16:46:05 +0100
Subject: [RFC PATCH 2/3] net: phy: call mdiobus_scan() after adding a
 fixed PHY
In-Reply-To: <1373902450-11857-3-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373902450-11857-3-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAGVrzcbn0FASWBbj-zF+pYnUATm02tUurN_wM0YWrWrTBh+dJQ@mail.gmail.com>

Hello Thomas,

2013/7/15 Thomas Petazzoni <thomas.petazzoni at free-electrons.com>:
> The fixed_phy_add() function allows to register a fixed PHY. However,
> when this function gets called *after* fixed_mdio_bus_init() (which
> gets called at the module_init stage), then the fixed PHY is not
> registered into the phylib.
>
> In order to address this, we add a call to mdiobus_scan() in
> fixed_phy_add() to ensure that the PHY indeed gets registered into the
> phylib, even if the fixed_phy_add() is called after
> fixed_mdio_bus_init().
>
> This is needed because until now, the only code that was calling the
> fixed_add_phy() function was PowerPC-specific platform code, which
> could ensure that such fixed PHYs get registered before
> fixed_mdio_bus_init() is called.

arch/mips/ar7/platform.c also calls fixed_phy_add() early enough as
well to ensure that we do not need to rescan the MDIO bus. There is
also another user: arch/m68k/platform/coldfire/m5272.c

>
> However, with the new of_phy_register_fixed_link() function, device
> drivers can parse their 'fixed-link' property and register a fixed PHY
> at ->probe() time, which may happen after fixed_mdio_bus_init() is
> called.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Reviewed-by: Florian Fainelli <florian at openwrt.org>

> ---
>  drivers/net/phy/fixed.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
> index ba55adf..bd1e67a 100644
> --- a/drivers/net/phy/fixed.c
> +++ b/drivers/net/phy/fixed.c
> @@ -195,6 +195,8 @@ int fixed_phy_add(unsigned int irq, int phy_id,
>
>         list_add_tail(&fp->node, &fmb->phys);
>
> +       mdiobus_scan(fmb->mii_bus, phy_id);
> +
>         return 0;
>
>  err_regs:
> --
> 1.8.1.2
>



--
Florian


From julien.grall at linaro.org  Mon Jul 15 11:49:32 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Mon, 15 Jul 2013 16:49:32 +0100
Subject: [Xen-devel] [PATCH] xen/control: protect functions with
 CONFIG_HIBERNATE_CALLBACKS to avoid warning
In-Reply-To: <51E41975.3070706@citrix.com>
References: <1373898275-15765-1-git-send-email-julien.grall@linaro.org>
 <20130715152714.GD5774@phenom.dumpdata.com> <51E41975.3070706@citrix.com>
Message-ID: <51E41A0C.2050408@linaro.org>

Forgot the different cc.

On 07/15/2013 04:47 PM, Julien Grall wrote:
> On 07/15/2013 04:27 PM, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jul 15, 2013 at 03:24:35PM +0100, Julien Grall wrote:
>>> If CONFIG_HIBERNATE_CALLBACKS is not set gcc will issue warnings:
>>> drivers/xen/manage.c:46:13: warning: 'xen_hvm_post_suspend' defined but not used [-Wunused-function]
>>> drivers/xen/manage.c:52:13: warning: 'xen_pre_suspend' defined but not used [-Wunused-function]
>>> drivers/xen/manage.c:59:13: warning: 'xen_post_suspend' defined but not used [-Wunused-function]
>>
>> Have you checked the upstream kernel?
> 
> My apologies, I forgot to check upstream for this patch.
> 



From mpfj-list at newflow.co.uk  Mon Jul 15 11:50:12 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Mon, 15 Jul 2013 16:50:12 +0100
Subject: [PATCH] remove vlan tags in CPSW dual emac mode
In-Reply-To: <51E3EEE7.9030508@ti.com>
References: <4699400.vD3TdgH1nR@localhost> <5176C4FE.4080305@ti.com>
 <51E00B2F.6050406@newflow.co.uk> <51E04C89.8030202@ti.com>
 <51E0582D.4090306@newflow.co.uk> <51E3EEE7.9030508@ti.com>
Message-ID: <51E41A34.4030000@newflow.co.uk>

On 15/07/13 13:45, Mugunthan V N wrote:
> On 7/13/2013 12:55 AM, Mark Jackson wrote:
>> On 12/07/13 19:35, Mugunthan V N wrote:
>>> On 7/12/2013 7:27 PM, Mark Jackson wrote:
>> [snip]
>>
>>>> Just to update this (old) thread ...
>>>>
>>>> I can still confirm that *without* the above patch, I am *unable* to use both network
>>>> ports on our AM335x board.
>>>>
>> [snip]
>>
>>>> So I'm not sure what's wrong, but it's *definitely* not correct.
>>>>
>>>>
>>> I am sure that current code in mainline works for Dual EMAC. I can test it
>>> again and share the images with you if are interested. But had tested with DHCP
>>> on both the interfaces.
>> Hmmm ... well it's not working for me.  What hardware are you testing it on ?
>>
>> I tried DHCP to start with, and switched to static IP when that failed.
>> Then I recalled this patch and re-applied it ... hey presto !!
>>
>> Markus, are you still using this patch ?
>>
> Today I have tested the Dual EMAC on my am335x-evmsk and its working fine with
> net/master branch.
> I had 3 patches additional to net/master in which two for basic boot of EVMsk
> and one for enabling Dual EMAC. I had pushed the branch in the below repo
> repo:
> git://git.ti.com/~mugunthanvnm/ti-linux-kernel/mugunth-connectivity-linux-feature-tree.git
> branch: dual-emac

Okay ... I can't test that at the moment as I can only boot from MMC as there's
currently no support for MMC booting in the mainline kernel.

So ... the code works for you, but not for me.

I guess the other difference is that I'm not using the same PHY (we use a 10/100
SMSC 8710A, not the GbE Atheros part).

Could that make any difference ?

Markus, are you still seeing the same issue ?  What PHY are you using ?

Cheers
Mark J.


From florian at openwrt.org  Mon Jul 15 11:50:15 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Mon, 15 Jul 2013 16:50:15 +0100
Subject: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link'
 property
In-Reply-To: <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAGVrzcZU-3VS87RgrCrcSuoQd+aU3XRX-QerToT1uvRemtcQDQ@mail.gmail.com>

Hello Thomas,

2013/7/15 Thomas Petazzoni <thomas.petazzoni at free-electrons.com>:
> Some Ethernet MACs have a "fixed link", and are not connected to a
> normal MDIO-managed PHY device. For those situations, a Device Tree
> binding allows to describe a "fixed link", as a "fixed-link" property
> of the Ethernet device Device Tree node.
>
> This patch adds:
>
>  * A documentation for the Device Tree property "fixed-link".
>
>  * A of_phy_register_fixed_link() OF helper, which provided an OF node
>    that contains a "fixed-link" property, registers the corresponding
>    fixed PHY.
>
>  * Removes the warning on the of_phy_connect_fixed_link() that says
>    new drivers should not use it, since Grant Likely indicated that
>    this "fixed-link" property is indeed the way to go.

Some minor nitpicks below. Other than that:

>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Reviewed-by: Florian Fainelli <florian at openwrt.org>

> ---
>  .../devicetree/bindings/net/fixed-link.txt         | 26 ++++++++++++++++
>  drivers/of/of_mdio.c                               | 36 +++++++++++++++++++---
>  include/linux/of_mdio.h                            | 10 ++++++
>  3 files changed, 68 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/fixed-link.txt
>
> diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt
> new file mode 100644
> index 0000000..25a009a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/fixed-link.txt
> @@ -0,0 +1,26 @@
> +Fixed link Device Tree binding
> +------------------------------
> +
> +Some Ethernet MACs have a "fixed link", and are not connected to a
> +normal MDIO-managed PHY device. For those situations, a Device Tree
> +binding allows to describe a "fixed link".

You could also add the following:

"this might be the case when using an Ethernet switch whose management
interface is not accessible using the MDIO bus, or for specific PHYs
where the control path of the PHY might be separated from its data
path".

> +
> +Such a fixed link situation is described within an Ethernet device
> +Device Tree node using a 'fixed-link' property, composed of 5
> +elements:
> +
> + 1. A fake PHY ID, which must be unique accross all fixed-link PHYs in
> +    the system.

You might want to detail that will be used to fake PHY identification
registers 2 & 3.

> + 2. The duplex (1 for full-duplex, 0 for half-duplex)
> + 3. The speed (10, 100, 1000)
> + 4. The pause setting (1 for enabled, 0 for disabled)
> + 5. The asym pause setting (1 for enabled, 0 for disabled)
> +
> +Example:
> +
> +ethernet at 0 {
> +       ...
> +       fixed-link = <1 1 1000 0 0>;
> +       ...
> +};
> +
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index d5a57a9..66d5591 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -14,6 +14,7 @@
>  #include <linux/netdevice.h>
>  #include <linux/err.h>
>  #include <linux/phy.h>
> +#include <linux/phy_fixed.h>
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_mdio.h>
> @@ -215,10 +216,6 @@ EXPORT_SYMBOL(of_phy_connect);
>   * @dev: pointer to net_device claiming the phy
>   * @hndlr: Link state callback for the network device
>   * @iface: PHY data interface type
> - *
> - * This function is a temporary stop-gap and will be removed soon.  It is
> - * only to support the fs_enet, ucc_geth and gianfar Ethernet drivers.  Do
> - * not call this function from new drivers.
>   */
>  struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
>                                              void (*hndlr)(struct net_device *),
> @@ -247,3 +244,34 @@ struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
>         return IS_ERR(phy) ? NULL : phy;
>  }
>  EXPORT_SYMBOL(of_phy_connect_fixed_link);
> +
> +#if defined(CONFIG_FIXED_PHY)
> +/**
> + * of_phy_register_fixed_link - Parse fixed-link property and register a dummy phy
> + * @np: pointer to the OF device node that contains the "fixed-link"
> + * property for which a dummy phy should be registered.
> + */
> +#define FIXED_LINK_PROPERTIES_COUNT 5
> +int of_phy_register_fixed_link(struct device_node *np)
> +{
> +       struct fixed_phy_status status = {};
> +       u32 fixed_link_props[FIXED_LINK_PROPERTIES_COUNT];
> +       int ret;
> +
> +       ret = of_property_read_u32_array(np, "fixed-link",
> +                                        fixed_link_props,
> +                                        FIXED_LINK_PROPERTIES_COUNT);
> +       if (ret < 0)
> +               return ret;
> +
> +       status.link       = 1;
> +       status.duplex     = fixed_link_props[1];
> +       status.speed      = fixed_link_props[2];
> +       status.pause      = fixed_link_props[3];
> +       status.asym_pause = fixed_link_props[4];
> +
> +       return fixed_phy_add(PHY_POLL, fixed_link_props[0],
> +                            &status);
> +}
> +EXPORT_SYMBOL(of_phy_register_fixed_link);
> +#endif
> diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
> index 8163107..bf6efea 100644
> --- a/include/linux/of_mdio.h
> +++ b/include/linux/of_mdio.h
> @@ -57,4 +57,14 @@ static inline struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np)
>  }
>  #endif /* CONFIG_OF */
>
> +#if defined(CONFIG_OF) && defined(CONFIG_FIXED_PHY)
> +extern int of_phy_register_fixed_link(struct device_node *np);
> +#else
> +static inline int of_phy_register_fixed_link(struct device_node *np)
> +{
> +       return -ENOSYS;
> +}
> +#endif
> +
> +
>  #endif /* __LINUX_OF_MDIO_H */
> --
> 1.8.1.2
>



--
Florian


From grundler at chromium.org  Mon Jul 15 11:56:02 2013
From: grundler at chromium.org (Grant Grundler)
Date: Mon, 15 Jul 2013 08:56:02 -0700
Subject: [PATCH v7 00/12] iommu/exynos: Fixes and Enhancements of System
 MMU driver with DT
In-Reply-To: <00a701ce8155$be139240$3a3ab6c0$@samsung.com>
References: <002801ce797b$3d2fbc80$b78f3580$@samsung.com>
 <CANEJEGvajhgzUPG6ppbjwBb4-9TdU9em3T_SejBpz8NCjGHYTQ@mail.gmail.com>
 <00a701ce8155$be139240$3a3ab6c0$@samsung.com>
Message-ID: <CANEJEGu0VJdFZmS800EKRSH0GXLGomC973BON7Vtr1qjjqi_nw@mail.gmail.com>

On Mon, Jul 15, 2013 at 5:20 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
...
>> > Cho,
>> > Of the above patches, nearly all have been applied to chromeos-3.8
>> > (kernel-next git tree) by Doug Anderson and others.
>> >
>> > AFAICT, the only ones not applied are:
>> >    [v7,3/9] iommu/exynos: fix page table maintenance
>> >    [v7,6/9] clk: exynos5250: add gate clock descriptions of System MMU
>> > (conflicts in this one)
>> >    [v7,7/9] ARM: dts: Add description of System MMU of Exynos SoCs
>> > (depends on 6/9)
>> >
>> > We also already have parts of:
>> >    [v7,9/9] iommu/exynos: add bus notifier for registering System MMU
>> >
>> > Some of those are being further discussed but I've lost track now
>> > exactly which ones.
>> >
>> > I'm telling you about chromeos-3.8 status since the adopted changes
>> > have been reviewed (by me and others) are being tested manually here
>> > on several different Samsung Exynos platforms (including 5250 which is
>> > our "snow" platform). Not sure how you should to mark those patches
>> > since they aren't identical to your changes (which apply to post 3.10
>> > kernels, not 3.8).  You might consider splitting those patches out
>> > from the 4 I've listed above to get that series accepted upstream
>> > since the additional review/testing should provide some confidence
>> > those patches are good.
>> >
>>
>> I understand what you are concerning about.
>> Have you applied v6 patchset?

I did not though it's possible some of the code that was applied to
chromeos-3.8 kernel came from v6 (or earlier) patches. I just compared
with v7. Since it's a "backport", the code I found in chromeos-3.8 is
the same if not identical to v7.

>>
>> I will try to split the patches and make the changes from v6
>> on top of the v6 patcheset.

Ok.

> Actually, as you know, the previous patches include setting a System MMU
> as the parent device of its master device in probe() of System MMU.
> I asked Greg KH about changing device hierarchy in probe() and he answered
> that it is not a good idea because it modifies sysfs even though probe() of
> System MMU driver is called before sysfs is constructed.

SysMMU primarily provides DMA API, right? Can sysfs be initialized
before DMA is available?
On some (many?) platforms the SysMMU is also responsible for "child"
bus controllers and MMIO resource routing, and on ARM platforms,
clocks for rest of the IO devices.

SysMMU might be needed for early gfx support (or something). Maybe the
right answer is to "discover" the SysMMU twice: once very early to get
the SysMMU operational and then again later in a "normal" probe
sequence to register with the sysfs. Any reason a driver couldn't
register two different module_init() routines in different parts of
the init call table?


> That's why I uses genpd_pm_ops.
> It results in big change in the patches after registering device tree.
>
> I want to ask your opinion about this change :)

I have no objection to large changes if they work well and are easy to
understand.

<rant>
I personally not happy with the direction the Linux IOMMU "subsystem"
has taken. I think the generic IOMMU subsystem should be discarded.
Strong words for someone who's not a key contributor but I'll explain.

I wrote the IOMMU support for PA-RISC (three different IOMMUs) 10+
years ago. I rewrote the HPUX implementations in the 90's and then
around 2000 wrote the implementation for PA-RISC (one of which Alex
Williamson used for IA64 IOMMU support - sba_iommu.c).  It's pretty
straight forward. There is "page allocation policy", code to do TLB
shoot down, and code to manage the IO Pdir. This is the same as for
CPU MMU.  The *efficiency* of the TLB depends on the page allocation
(SW) to work together with the HW TLB replacement policy. In other
words, the page allocation policy needs to avoid thrashing the IO TLB.
A generic IOTLB allocation policy can't do that for every platform.

Exynos 5250 has an 8-way associative TLB. That's likely very different
from the Intel and TI (omap) IOMMU the IOMMU subsystem code was
originally implemented for. The "optimal" size of page to allocate
will be different too.  Older Exynos products are likely different

The "2cd layer" of indirect function calls between the generic IOMMU
support and the platform specific code makes it harder to understand
the code.  While jump tables are good for some things, I don't think
this is a good use. We should "flip" this design around. Let the
platform specific code "own" the DMA ops API and it can decide which
services it should or should not use.

E.g. The IOTLB shoot down can be divorced from the "unmap" call. The
efficiency of shooting down one IOTLB entry at a time is horrible on
most platforms. One answer is to add a new API to shoot down an array
of IOVAs. But the tradeoffs in the size of the array and the events
that might trigger a TLB shoot down should be left up to the
platform/chipset specific code (e.g. "lazy TLB shootdown").

Sorry...this got rant got alot longer than it should have been. I hope
this helps people understand the design tradeoffs that linux IOMMU
subsystem never will be able to cleanly address. My hope is this rant
will help developers like you justify small steps to move away from
generic IOMMU code.
</rant>

cheers,
grant


From peter.maydell at linaro.org  Mon Jul 15 11:59:53 2013
From: peter.maydell at linaro.org (Peter Maydell)
Date: Mon, 15 Jul 2013 16:59:53 +0100
Subject: [PATCH] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene host
In-Reply-To: <03C760B4-A395-491C-B589-0689BC2C48BB@suse.de>
References: <1373888788-8055-1-git-send-email-anup.patel@linaro.org>
 <51E3ED7A.7050207@arm.com>
 <CAAhSdy25WVnynDyPcOMtqVNEepGGq9WFT3b1PV34P6iSBm-FUg@mail.gmail.com>
 <73A8FA0E-9F7F-4866-9544-57838F30BB91@suse.de>
 <CAAhSdy1tYsdm-2kJzoRfqb-FaPa0-t9x2+=jtMjgFqes+Pco6Q@mail.gmail.com>
 <03C760B4-A395-491C-B589-0689BC2C48BB@suse.de>
Message-ID: <CAFEAcA-0Csn9NuHGKjL1TuNVVnmA0woUvAhuwxTv3r5a+3nMGg@mail.gmail.com>

On 15 July 2013 15:21, Alexander Graf <agraf at suse.de> wrote:
> On 15.07.2013, at 16:04, Anup Patel wrote:
>> On Mon, Jul 15, 2013 at 6:32 PM, Alexander Graf <agraf at suse.de> wrote:
>>> Anything that is compatible is compatible :). I don't know
>>> the product roadmaps for X-Gene cores, but you will want to
>>> make the field here as coarse grained as possible, while
>>> maintaining the guarantee that a guest still behaves the same.
>>
>> Actually, I don't see X-Gene cores changing in-terms of register
>> interface available to EL1 and EL0 in near future. This is the
>> reason why I had named the target as KVM_ARM_TARGET_XGENE_V8.
>
> So where does the v8 come from? Is there any non-ARMv8 XGene? If
> not, this is v1 really, right? What if we just call it v1 instead?
> Then when a new core comes up that needs different treatment, we
> create a new target.

I think what we're actually seeing here is that we started with
a design that specifically said (in the v7 space) "only A15
on A15", and we're now trying to broaden that out, only we
haven't actually set out anywhere how that broadening is
supposed to work (ie what range of hosts will work with
what range of guests, and how, and whether we want to have
a "give me a guest CPU that looks like the host CPU" option).

I think the original idea was that userspace would say
which CPU it wanted, and the kernel would know about that
CPU (including details like ID and feature registers which
are going to vary from core to core).

thanks
-- PMM


From festevam at gmail.com  Mon Jul 15 12:08:23 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 15 Jul 2013 13:08:23 -0300
Subject: [PATCH 19/22] Input: tsc2007: Add device tree support.
In-Reply-To: <1373900227-341-20-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-20-git-send-email-denis@eukrea.com>
Message-ID: <CAOMZO5B169k+6f0G388xne4dUTNiEAb9Zpx1_XJH8TMv5FTLLg@mail.gmail.com>

On Mon, Jul 15, 2013 at 11:57 AM, Denis Carikli <denis at eukrea.com> wrote:
> Set the of_match_table for this driver so that devices can be described
>   in the device tree.
>
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  .../bindings/input/touchscreen/tsc2007.txt         |   44 +++++
>  drivers/input/touchscreen/tsc2007.c                |  205 ++++++++++++++++----

You should have Cc'ed linux-input list and its maintainer Dmitry
Torokhov <dmitry.torokhov at gmail.com>

> +static int tsc2007_get_pendown_state_dt(struct tsc2007  *ts)
> +{
> +       if (ts->gpio >= 0)

What about
if (gpio_is_valid(ts->gpio)) instead?


From chf.fritz at googlemail.com  Mon Jul 15 12:09:43 2013
From: chf.fritz at googlemail.com (Christoph Fritz)
Date: Mon, 15 Jul 2013 18:09:43 +0200
Subject: [PATCH] ARM: dma: imx: Fix deadlock bug
In-Reply-To: <20130715100131.GR16653@intel.com>
References: <1370724988-16426-1-git-send-email-shc_work@mail.ru>
 <20130608211557.GK18614@n2100.arm.linux.org.uk>
 <20130612030321.GA4107@intel.com> <1373876039.3897.9.camel@mars>
 <20130715100131.GR16653@intel.com>
Message-ID: <1373904583.3897.12.camel@mars>

On Mon, 2013-07-15 at 15:31 +0530, Vinod Koul wrote:
> On Mon, Jul 15, 2013 at 10:13:59AM +0200, Christoph Fritz wrote:
> > Hi,
> > 
> >  I'm the initiator of the bug-report[1] ("ARM: imx27: dmaengine:
> > imx-dma: SD-Card: copy hangs forever") which led to this thread.
> > 
> > Are there any updates yet?
> I should have a fix for you pretty soon. Obviosuly it would be untested on my
> part as I lack the hardware

No problem, I'll do that.

 Thanks
  -- Christoph



From aletes.xgr at gmail.com  Mon Jul 15 12:11:46 2013
From: aletes.xgr at gmail.com (Alexandre Pereira da Silva)
Date: Mon, 15 Jul 2013 13:11:46 -0300
Subject: [PATCH 4/5] ARM: dts: imx23-olinuxino: enable Low Resolution ADC
In-Reply-To: <1373898160-8460-4-git-send-email-otavio@ossystems.com.br>
References: <1373898160-8460-1-git-send-email-otavio@ossystems.com.br>
 <1373898160-8460-4-git-send-email-otavio@ossystems.com.br>
Message-ID: <CAAAP30FpVgmBhU3=cXciVbNJ4yGtfr2Rt9i_3+T+sTw4VeXycg@mail.gmail.com>

On Mon, Jul 15, 2013 at 11:22 AM, Otavio Salvador
<otavio at ossystems.com.br> wrote:
> The i.XM23 has a internal Low Resolution ADC; this enables the support
> for this device.
>
> Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>

Acked-by: Alexandre Pereira da Silva <aletes.xgr at gmail.com>


From shawn.guo at linaro.org  Mon Jul 15 12:12:38 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 00:12:38 +0800
Subject: [GIT PULL] ARM: imx: fixes for 3.11
Message-ID: <20130715161236.GC23589@S2101-09.ap.freescale.net>

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-fixes-3.11

for you to fetch changes up to 84bb08472520882394fe16d7a3548793302563de:

  ARM: dts: imx51-babbage: Pass a real clock to the codec (2013-07-15 22:28:52 +0800)

----------------------------------------------------------------
The imx fixes for 3.11:

* A few device tree source fixes regarding pinctrl, clock, and pwm
  backlight.
* Fixes imx28 and imx51 audio driver failure caused by sgtl5000 codec
  driver change by supplying the correct clock for codec.
* imx6q emi_sel clock muxing and imx6q-iomuxc-gpr macro fixes

----------------------------------------------------------------
Alexander Shiyan (1):
      ARM: i.MX27: Typo fix

Fabio Estevam (1):
      ARM: dts: imx51-babbage: Pass a real clock to the codec

Laurent Pinchart (1):
      ARM i.MX53: mba53: Fix PWM backlight DT node

Liu Ying (1):
      ARM: i.MX6Q: correct emi_sel clock muxing

Markus Pargmann (1):
      ARM: imx27: Fix documentation for SPLL clock

Philipp Zabel (2):
      ARM i.MX53: Fix UART pad configuration
      ARM i.MX6Q: Fix IOMUXC GPR1 defines for ENET_CLK_SEL and IPU1/2_MUX

Shawn Guo (2):
      ARM: mxs: saif0 is the clock provider to sgtl5000
      ARM: imx: fix vf610 enet module clock selection

 .../devicetree/bindings/clock/imx27-clock.txt      |    1 +
 arch/arm/boot/dts/imx28-apx4devkit.dts             |    2 +-
 arch/arm/boot/dts/imx28-evk.dts                    |    2 +-
 arch/arm/boot/dts/imx28-m28evk.dts                 |    2 +-
 arch/arm/boot/dts/imx28.dtsi                       |    1 +
 arch/arm/boot/dts/imx51-babbage.dts                |   13 +++++++-
 arch/arm/boot/dts/imx53-mba53.dts                  |    2 +-
 arch/arm/boot/dts/imx53.dtsi                       |   32 ++++++++++----------
 arch/arm/boot/dts/vf610.dtsi                       |    8 ++---
 arch/arm/mach-imx/clk-imx6q.c                      |    5 +--
 arch/arm/mach-imx/clk-vf610.c                      |    2 ++
 arch/arm/mach-imx/mx27.h                           |    2 +-
 include/dt-bindings/clock/vf610-clock.h            |    4 ++-
 include/linux/mfd/syscon/imx6q-iomuxc-gpr.h        |   16 +++++-----
 14 files changed, 55 insertions(+), 37 deletions(-)



From robherring2 at gmail.com  Mon Jul 15 12:12:42 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 15 Jul 2013 11:12:42 -0500
Subject: [PATCHv5 05/11] of: pci: add registry of MSI chips
In-Reply-To: <1373889167-27878-6-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-6-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <51E41F7A.4010502@gmail.com>

On 07/15/2013 06:52 AM, Thomas Petazzoni wrote:
> This commit adds a very basic registry of msi_chip structures, so that
> an IRQ controller driver can register an msi_chip, and a PCIe host
> controller can find it, based on a 'struct device_node'.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Acked-by: Rob Herring <rob.herring at calxeda.com>


> ---
>  drivers/of/of_pci.c    | 45 +++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/msi.h    |  2 ++
>  include/linux/of_pci.h | 12 ++++++++++++
>  3 files changed, 59 insertions(+)
> 
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 42c687a..e5ca008 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -89,3 +89,48 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
> +
> +#ifdef CONFIG_PCI_MSI
> +
> +static LIST_HEAD(of_pci_msi_chip_list);
> +static DEFINE_MUTEX(of_pci_msi_chip_mutex);
> +
> +int of_pci_msi_chip_add(struct msi_chip *chip)
> +{
> +	if (!of_property_read_bool(chip->of_node, "msi-controller"))
> +		return -EINVAL;
> +
> +	mutex_lock(&of_pci_msi_chip_mutex);
> +	list_add(&chip->list, &of_pci_msi_chip_list);
> +	mutex_unlock(&of_pci_msi_chip_mutex);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_msi_chip_add);
> +
> +void of_pci_msi_chip_remove(struct msi_chip *chip)
> +{
> +	mutex_lock(&of_pci_msi_chip_mutex);
> +	list_del(&chip->list);
> +	mutex_unlock(&of_pci_msi_chip_mutex);
> +}
> +EXPORT_SYMBOL_GPL(of_pci_msi_chip_remove);
> +
> +struct msi_chip *of_pci_find_msi_chip_by_node(struct device_node *of_node)
> +{
> +	struct msi_chip *c;
> +
> +	mutex_lock(&of_pci_msi_chip_mutex);
> +	list_for_each_entry(c, &of_pci_msi_chip_list, list) {
> +		if (c->of_node == of_node) {
> +			mutex_unlock(&of_pci_msi_chip_mutex);
> +			return c;
> +		}
> +	}
> +	mutex_unlock(&of_pci_msi_chip_mutex);
> +
> +	return NULL;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_find_msi_chip_by_node);
> +
> +#endif /* CONFIG_PCI_MSI */
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index cbf5d05..80900e0 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -67,6 +67,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);
>  struct msi_chip {
>  	struct module *owner;
>  	struct device *dev;
> +	struct device_node *of_node;
> +	struct list_head list;
>  
>  	int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
>  			 struct msi_desc *desc);
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index 7a04826..29631eb 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -2,6 +2,7 @@
>  #define __OF_PCI_H
>  
>  #include <linux/pci.h>
> +#include <linux/msi.h>
>  
>  struct pci_dev;
>  struct of_irq;
> @@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
>  int of_pci_get_devfn(struct device_node *np);
>  int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
>  
> +#if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
> +int of_pci_msi_chip_add(struct msi_chip *chip);
> +void of_pci_msi_chip_remove(struct msi_chip *chip);
> +struct msi_chip *of_pci_find_msi_chip_by_node(struct device_node *of_node);
> +#else
> +static inline int of_pci_msi_chip_add(struct msi_chip *chip) { return -EINVAL; }
> +static inline void of_pci_msi_chip_remove(struct msi_chip *chip) { }
> +static inline struct msi_chip *
> +of_pci_find_msi_chip_by_node(struct device_node *of_node) { return NULL };
> +#endif
> +
>  #endif
> 



From festevam at gmail.com  Mon Jul 15 12:14:58 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 15 Jul 2013 13:14:58 -0300
Subject: [PATCH 13/22] lcd: Add GPIO LCD driver.
In-Reply-To: <1373900227-341-14-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-14-git-send-email-denis@eukrea.com>
Message-ID: <CAOMZO5C6wKUmK25+7iBX+JGs00RR_hpKrCW3r0un610Z-BZn0w@mail.gmail.com>

Hi Denis,

On Mon, Jul 15, 2013 at 11:56 AM, Denis Carikli <denis at eukrea.com> wrote:
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  .../bindings/video/backlight/gpio-lcd.txt          |   15 ++
>  drivers/video/backlight/Kconfig                    |    8 +
>  drivers/video/backlight/Makefile                   |    1 +
>  drivers/video/backlight/gpio_lcd.c                 |  178 ++++++++++++++++++++
>  4 files changed, 202 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/backlight/gpio-lcd.txt
>  create mode 100644 drivers/video/backlight/gpio_lcd.c
>
> diff --git a/Documentation/devicetree/bindings/video/backlight/gpio-lcd.txt b/Documentation/devicetree/bindings/video/backlight/gpio-lcd.txt
> new file mode 100644
> index 0000000..4ff409d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/backlight/gpio-lcd.txt
> @@ -0,0 +1,15 @@
> +gpio-lcd bindings
> +
> +Required properties:
> +  - compatible: "gpio-lcd"
> +  - gpios: describes the gpio that is used for enabling/disabling the lcd
> +     (see GPIO binding[0] for more details).

Do we really need this?

Why not just use the regulator framework instead?

You can refer to an example here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/video/mxsfb.c?id=4344429d3d926d219671f607125cff51223a140a

Regards,

Fabio Estevam


From grundler at chromium.org  Mon Jul 15 12:18:41 2013
From: grundler at chromium.org (Grant Grundler)
Date: Mon, 15 Jul 2013 09:18:41 -0700
Subject: [PATCH v7 3/9] iommu/exynos: fix page table maintenance
In-Reply-To: <009a01ce814d$840b48c0$8c21da40$@samsung.com>
References: <002b01ce797b$44d4ad10$ce7e0730$@samsung.com>
 <1933986.4vddYccClk@amdc1032>
 <009a01ce814d$840b48c0$8c21da40$@samsung.com>
Message-ID: <CANEJEGs_8a9dPCYtDT8u2NEv5HUUD5gcdmRmbsrKU-_aagztgg@mail.gmail.com>

On Mon, Jul 15, 2013 at 4:21 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
...
>> Maybe you could add LV1TABLE_SIZE define and use it here (there is
>> already a LV2TABLE_SIZE define)?
>
> Yes. But, LV2TABLE_SIZE is used in more places than one.
> I do not feel that it is needed to define LV1TABLE_SIZE for the single line.

Cho,
#define's are part of the code "documentation". Doesn't really matter
how often it's used. I think Bartlomiej's suggestion is a good one.

Key is to use "consistent" names so they makes sense to someone not
familiar with the code. In this case, we want to show this use is the
same way LV2TABLE_SIZE is used and serves the same purpose.

cheers.
grant


From julien.grall at linaro.org  Mon Jul 15 12:22:00 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Mon, 15 Jul 2013 17:22:00 +0100
Subject: [Xen-devel] [PATCH] xen/arm: disable cpuidle when linux is running
 as dom0
In-Reply-To: <20130715152532.GC5774@phenom.dumpdata.com>
References: <1373898101-15633-1-git-send-email-julien.grall@linaro.org>
 <20130715152532.GC5774@phenom.dumpdata.com>
Message-ID: <51E421A8.1010302@linaro.org>

On 07/15/2013 04:25 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Jul 15, 2013 at 03:21:41PM +0100, Julien Grall wrote:
>> When linux is running as dom0, Xen doesn't show the physical cpu but a
>> virtual CPU.
>> On some ARM SOC (for instance the exynos 5250), linux registers callbacks
>> for cpuidle. When these callbacks are called, they will modify
>> directly the physical cpu not the virtual one. It can impact the whole board
>> instead of dom0.
> 
> Should you also call disable_cpufreq() ?

I had some issue on the versatile express when cpufreq was disabled.
I will give another try and see the exact error.

-- 
Julien



From thierry.reding at gmail.com  Mon Jul 15 12:27:10 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 15 Jul 2013 09:27:10 -0700
Subject: [PATCHv5 00/11] MSI support for Marvell EBU PCIe driver
In-Reply-To: <51E4167B.4000208@wwwdotorg.org>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E4167B.4000208@wwwdotorg.org>
Message-ID: <20130715162709.GA24625@dhcp-172-17-186-34.nvidia.com>

On Mon, Jul 15, 2013 at 09:34:19AM -0600, Stephen Warren wrote:
> On 07/15/2013 05:52 AM, Thomas Petazzoni wrote:
> > Hello,
> > 
> > This set of patches introduces Message Signaled Interrupt support in
> > the Marvell EBU PCIe driver. It has been successfully tested on the
> > Armada XP GP platform with an Intel e1000e PCIe network card that
> > supports MSI.
> > 
> > This patch set is intended for merging in 3.12, so the respective
> > maintainers of the different areas are invited to review/ack the
> > patches, see below for the details. This set of patches applies on top
> > of 3.11-rc1.
> 
> Thomas, who is going to merge this series?
> 
> I believe at least patches 1-8 (or perhaps just 1-5 plus 8; I /think/
> all the other patches are MVEBU-specific) are dependencies for the new
> Tegra PCIe driver which should be posted very soon for 3.12. As such,
> I'd like to see these dependencies merged into a standalone stable (100%
> non-rebasable) topic branch based on 3.11-rc1 so that the topic branch
> is available for merging into whichever tree takes the new Tegra PCIe
> driver (which I'm guessing will be the Tegra tree to reduce conflicts).
> So, whoever merges these patches is going to need to know to set up that
> topic branch.
> 
> Thierry, please correct me if I'm wrong here.

We need at least patches 2, 4 and 8 for Tegra. There's still the option
of working around patch 8 by using the custom root bus scan function
that we have to use anyway, so I guess we could even trim the
requirement down to patches 2 and 4 if we really need.

Thierry
-------------- 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/20130715/97e67ff4/attachment.sig>

From otavio at ossystems.com.br  Mon Jul 15 12:39:13 2013
From: otavio at ossystems.com.br (Otavio Salvador)
Date: Mon, 15 Jul 2013 13:39:13 -0300
Subject: [PATCH 1/5] ARM: dts: imx23-evk: enable USB PHY and controller
In-Reply-To: <CAOMZO5C_7nJ9RVYvuKJHP2u0mYY6P2UyGVA6OpPzqTnd7YXN2Q@mail.gmail.com>
References: <1373898160-8460-1-git-send-email-otavio@ossystems.com.br>
 <CAOMZO5C_7nJ9RVYvuKJHP2u0mYY6P2UyGVA6OpPzqTnd7YXN2Q@mail.gmail.com>
Message-ID: <CAP9ODKpr82mMoxhiv=K70RKdn01b=ZM2J9E4vV-AM5nwXxUR+g@mail.gmail.com>

On Mon, Jul 15, 2013 at 12:39 PM, Fabio Estevam <festevam at gmail.com> wrote:
> Hi Otavio,
>
> On Mon, Jul 15, 2013 at 11:22 AM, Otavio Salvador
> <otavio at ossystems.com.br> wrote:
>> The i.MX23EVK board provides a USB port so the USB PHY and controller
>> need to be enabled for it to be usable.
>>
>> Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
>> ---
>
> You should have Cc'd Shawn Guo on this series.

Oh; thanks for fix my mistake. I am new to kernel development :-)

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750


From swarren at wwwdotorg.org  Mon Jul 15 12:48:22 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 10:48:22 -0600
Subject: [PATCH V2] ARM: tegra: enable palmas device for dalmore
In-Reply-To: <1373441852-27176-1-git-send-email-ldewangan@nvidia.com>
References: <1373441852-27176-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <51E427D6.7090702@wwwdotorg.org>

On 07/10/2013 01:37 AM, Laxman Dewangan wrote:
> Make the entry of Dalmore Power Management Unit device TPS65913
> in dalmore DTS file. The Palma driver support this device.
> 
> Enable following submodule of the TPS65913:
> - GPIO driver
> - RTC driver.
> - Power regulator driver.

If I apply this, (at least) the SD card no longer works. I assume the
regulator for it is being turned off somehow.


From swarren at wwwdotorg.org  Mon Jul 15 12:49:47 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 10:49:47 -0600
Subject: [PATCH V3] ARM: tegra: enable gpio-keys on dalmore
In-Reply-To: <1373439643-16633-1-git-send-email-ldewangan@nvidia.com>
References: <1373439643-16633-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <51E4282B.5040905@wwwdotorg.org>

On 07/10/2013 01:00 AM, Laxman Dewangan wrote:
> Dalmore have the keys mounted on board which are connected
> to different pins of Tegra.
> 
> Add the keys entry in DTS file to enable key functionality.
> This will enable KEY_POWER, KEY_HOME, KEY_VOLUMEUP and
> KEY_VOLUMEDOWN.

I have applied this to Tegra's for-3.12/dt branch.


From swarren at wwwdotorg.org  Mon Jul 15 12:51:43 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 10:51:43 -0600
Subject: [PATCH] ARM: tegra: fix DT node ordering in Tegra30 Cardhu
Message-ID: <1373907103-28418-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Nodes should be sorted by reg. Fix location of the tps62361 node.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
I will immediately apply this to Tegra's for-3.12/dt branch.

 arch/arm/boot/dts/tegra30-cardhu.dtsi | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index e5759ca..c011b67 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -173,19 +173,6 @@
 			gpio-cfg = <0xffffffff 0xffffffff 0 0xffffffff 0xffffffff>;
 		};
 
-		tps62361 {
-			compatible = "ti,tps62361";
-			reg = <0x60>;
-
-			regulator-name = "tps62361-vout";
-			regulator-min-microvolt = <500000>;
-			regulator-max-microvolt = <1500000>;
-			regulator-boot-on;
-			regulator-always-on;
-			ti,vsel0-state-high;
-			ti,vsel1-state-high;
-		};
-
 		pmic: tps65911 at 2d {
 			compatible = "ti,tps65911";
 			reg = <0x2d>;
@@ -293,6 +280,19 @@
 			interrupt-parent = <&gpio>;
 			interrupts = <TEGRA_GPIO(CC, 2) IRQ_TYPE_LEVEL_LOW>;
 		};
+
+		tps62361 {
+			compatible = "ti,tps62361";
+			reg = <0x60>;
+
+			regulator-name = "tps62361-vout";
+			regulator-min-microvolt = <500000>;
+			regulator-max-microvolt = <1500000>;
+			regulator-boot-on;
+			regulator-always-on;
+			ti,vsel0-state-high;
+			ti,vsel1-state-high;
+		};
 	};
 
 	spi at 7000da00 {
-- 
1.8.1.5



From mugunthanvnm at ti.com  Mon Jul 15 13:02:59 2013
From: mugunthanvnm at ti.com (Mugunthan V N)
Date: Mon, 15 Jul 2013 22:32:59 +0530
Subject: [PATCH] remove vlan tags in CPSW dual emac mode
In-Reply-To: <51E41A34.4030000@newflow.co.uk>
References: <4699400.vD3TdgH1nR@localhost> <5176C4FE.4080305@ti.com>
 <51E00B2F.6050406@newflow.co.uk> <51E04C89.8030202@ti.com>
 <51E0582D.4090306@newflow.co.uk> <51E3EEE7.9030508@ti.com>
 <51E41A34.4030000@newflow.co.uk>
Message-ID: <51E42B43.8060307@ti.com>

On 7/15/2013 9:20 PM, Mark Jackson wrote:
> On 15/07/13 13:45, Mugunthan V N wrote:
>> On 7/13/2013 12:55 AM, Mark Jackson wrote:
>>> On 12/07/13 19:35, Mugunthan V N wrote:
>>>> On 7/12/2013 7:27 PM, Mark Jackson wrote:
>>> [snip]
>>>
>>>>> Just to update this (old) thread ...
>>>>>
>>>>> I can still confirm that *without* the above patch, I am *unable* to use both network
>>>>> ports on our AM335x board.
>>>>>
>>> [snip]
>>>
>>>>> So I'm not sure what's wrong, but it's *definitely* not correct.
>>>>>
>>>>>
>>>> I am sure that current code in mainline works for Dual EMAC. I can test it
>>>> again and share the images with you if are interested. But had tested with DHCP
>>>> on both the interfaces.
>>> Hmmm ... well it's not working for me.  What hardware are you testing it on ?
>>>
>>> I tried DHCP to start with, and switched to static IP when that failed.
>>> Then I recalled this patch and re-applied it ... hey presto !!
>>>
>>> Markus, are you still using this patch ?
>>>
>> Today I have tested the Dual EMAC on my am335x-evmsk and its working fine with
>> net/master branch.
>> I had 3 patches additional to net/master in which two for basic boot of EVMsk
>> and one for enabling Dual EMAC. I had pushed the branch in the below repo
>> repo:
>> git://git.ti.com/~mugunthanvnm/ti-linux-kernel/mugunth-connectivity-linux-feature-tree.git
>> branch: dual-emac
> Okay ... I can't test that at the moment as I can only boot from MMC as there's
> currently no support for MMC booting in the mainline kernel.
>
> So ... the code works for you, but not for me.
>
> I guess the other difference is that I'm not using the same PHY (we use a 10/100
> SMSC 8710A, not the GbE Atheros part).
>
> Could that make any difference ?
>
> Markus, are you still seeing the same issue ?  What PHY are you using ?
>
There is no relation between what you used vs vlan aware mode in CPSW. I don't
have a board with SMSC phy. If I have I could have helped you to bring up Dual
EMAC.

Regards
Mugunthan V N


From nerv at dawncrow.de  Mon Jul 15 13:14:57 2013
From: nerv at dawncrow.de (=?ISO-8859-1?Q?Andr=E9_Hentschel?=)
Date: Mon, 15 Jul 2013 19:14:57 +0200
Subject: arm: Only load TLS values when needed
Message-ID: <51E42E11.1010903@dawncrow.de>

From: Andr? Hentschel <nerv at dawncrow.de>

This patch intents to reduce loading instructions when the resulting value is not used.
It's a follow up on a4780adeefd042482f624f5e0d577bf9cdcbb760

Signed-off-by: Andr? Hentschel <nerv at dawncrow.de>

---
This patch is against Linux 3.11-rc1 (ad81f0545ef01ea651886dddac4bef6cec930092)

Thanks to everyone who helped me with a4780adeefd042482f624f5e0d577bf9cdcbb760

diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h
index 83259b8..3742722 100644
--- a/arch/arm/include/asm/tls.h
+++ b/arch/arm/include/asm/tls.h
@@ -3,29 +3,32 @@
 
 #ifdef __ASSEMBLY__
 #include <asm/asm-offsets.h>
-	.macro switch_tls_none, base, tp, tpuser, tmp1, tmp2
+	.macro switch_tls_none, prev, next, tp, tpuser, tmp1, tmp2
 	.endm
 
-	.macro switch_tls_v6k, base, tp, tpuser, tmp1, tmp2
+	.macro switch_tls_v6k, prev, next, tp, tpuser, tmp1, tmp2
+	ldrd	\tp, \tpuser, [\next, #TI_TP_VALUE]	@ get the next TLS and user r/w register
 	mrc	p15, 0, \tmp2, c13, c0, 2	@ get the user r/w register
 	mcr	p15, 0, \tp, c13, c0, 3		@ set TLS register
 	mcr	p15, 0, \tpuser, c13, c0, 2	@ and the user r/w register
-	str	\tmp2, [\base, #TI_TP_VALUE + 4] @ save it
+	str	\tmp2, [\prev, #TI_TP_VALUE + 4] @ save it
 	.endm
 
-	.macro switch_tls_v6, base, tp, tpuser, tmp1, tmp2
+	.macro switch_tls_v6, prev, next, tp, tpuser, tmp1, tmp2
 	ldr	\tmp1, =elf_hwcap
 	ldr	\tmp1, [\tmp1, #0]
 	mov	\tmp2, #0xffff0fff
+	ldr	\tp, [\next, #TI_TP_VALUE]	@ get the next TLS register
 	tst	\tmp1, #HWCAP_TLS		@ hardware TLS available?
 	streq	\tp, [\tmp2, #-15]		@ set TLS value at 0xffff0ff0
-	mrcne	p15, 0, \tmp2, c13, c0, 2	@ get the user r/w register
+	mrcne	p15, 0, \tmp2, c13, c0, 2	@ get the previous user r/w register
+	ldrne	\tpuser, [\next, #TI_TP_VALUE + 4]	@ get the next user r/w register
 	mcrne	p15, 0, \tp, c13, c0, 3		@ yes, set TLS register
 	mcrne	p15, 0, \tpuser, c13, c0, 2	@ set user r/w register
-	strne	\tmp2, [\base, #TI_TP_VALUE + 4] @ save it
+	strne	\tmp2, [\prev, #TI_TP_VALUE + 4] @ save it
 	.endm
 
-	.macro switch_tls_software, base, tp, tpuser, tmp1, tmp2
+	.macro switch_tls_software, prev, next, tp, tpuser, tmp1, tmp2
 	mov	\tmp1, #0xffff0fff
 	str	\tp, [\tmp1, #-15]		@ set TLS value at 0xffff0ff0
 	.endm
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index a39cfc2a1..1484b59 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -689,12 +689,10 @@ ENTRY(__switch_to)
  THUMB(	stmia	ip!, {r4 - sl, fp}	   )	@ Store most regs on stack
  THUMB(	str	sp, [ip], #4		   )
  THUMB(	str	lr, [ip], #4		   )
-	ldr	r4, [r2, #TI_TP_VALUE]
-	ldr	r5, [r2, #TI_TP_VALUE + 4]
 #ifdef CONFIG_CPU_USE_DOMAINS
 	ldr	r6, [r2, #TI_CPU_DOMAIN]
 #endif
-	switch_tls r1, r4, r5, r3, r7
+	switch_tls r1, r2, r4, r5, r3, r7
 #if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
 	ldr	r7, [r2, #TI_TASK]
 	ldr	r8, =__stack_chk_guard


From ldewangan at nvidia.com  Mon Jul 15 13:28:09 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 15 Jul 2013 22:58:09 +0530
Subject: [PATCH V2] ARM: tegra: enable palmas device for dalmore
In-Reply-To: <51E427D6.7090702@wwwdotorg.org>
References: <1373441852-27176-1-git-send-email-ldewangan@nvidia.com>
 <51E427D6.7090702@wwwdotorg.org>
Message-ID: <51E43129.7080602@nvidia.com>

On Monday 15 July 2013 10:18 PM, Stephen Warren wrote:
> On 07/10/2013 01:37 AM, Laxman Dewangan wrote:
>> Make the entry of Dalmore Power Management Unit device TPS65913
>> in dalmore DTS file. The Palma driver support this device.
>>
>> Enable following submodule of the TPS65913:
>> - GPIO driver
>> - RTC driver.
>> - Power regulator driver.
> If I apply this, (at least) the SD card no longer works. I assume the
> regulator for it is being turned off somehow.

As per downstream power tree, smps9 is feeding power to sd slot and I 
make this rail as always ON. So there should not be any issue.

Rhyland,
Do you see any differences on this power tree with your power tree with 
DT? There was discussion sometime ago on the sdcard. Am I missing 
anything here?

Thanks,
Laxman


From rklein at nvidia.com  Mon Jul 15 13:29:45 2013
From: rklein at nvidia.com (Rhyland Klein)
Date: Mon, 15 Jul 2013 13:29:45 -0400
Subject: [PATCH V2] ARM: tegra: enable palmas device for dalmore
In-Reply-To: <51E43129.7080602@nvidia.com>
References: <1373441852-27176-1-git-send-email-ldewangan@nvidia.com>
 <51E427D6.7090702@wwwdotorg.org> <51E43129.7080602@nvidia.com>
Message-ID: <51E43189.5050805@nvidia.com>

On 7/15/2013 1:28 PM, Laxman Dewangan wrote:
> On Monday 15 July 2013 10:18 PM, Stephen Warren wrote:
>> On 07/10/2013 01:37 AM, Laxman Dewangan wrote:
>>> Make the entry of Dalmore Power Management Unit device TPS65913
>>> in dalmore DTS file. The Palma driver support this device.
>>>
>>> Enable following submodule of the TPS65913:
>>> - GPIO driver
>>> - RTC driver.
>>> - Power regulator driver.
>> If I apply this, (at least) the SD card no longer works. I assume the
>> regulator for it is being turned off somehow.
> 
> As per downstream power tree, smps9 is feeding power to sd slot and I 
> make this rail as always ON. So there should not be any issue.
> 
> Rhyland,
> Do you see any differences on this power tree with your power tree with 
> DT? There was discussion sometime ago on the sdcard. Am I missing 
> anything here?
> 
> Thanks,
> Laxman
> 


I noticed a couple differences between this and what we are using...

Yours:
+			    ldo8-in-supply = <&tps65090_dcdc3_reg>;
+			    ldo9-in-supply = <&palmas_smps9_reg>;
Ours:
                            ldo8-in-supply = <&tps65090_dcdc2_reg>;
                            ldo9-in-supply = <&tps65090_dcdc2_reg>;

We also specify supplies (floating) for smps6 and smps10.  I don't think
that matters though.

Also we have the vmmc-supply and sd-slot-supply propeties set for the sd
card slot, like so:

                vmmc-supply = <&palmas_smps3_reg>;
                sd-slot-supply = <&palmas_smps9_reg>;

Also, we have the interrupt trigger mode different for the palmas:

Yours:
+			interrupts = <0 86 0x4>;
Ours:
                        interrupts = <0 86 0x8>;


I think other than that they should be the same.

-Rhyland

-- 
nvpublic


From gorcunov at gmail.com  Mon Jul 15 13:32:38 2013
From: gorcunov at gmail.com (Cyrill Gorcunov)
Date: Mon, 15 Jul 2013 21:32:38 +0400
Subject: [PATCH] arm: align shared memory unconditionally to the SHMLBA
 boundary
In-Reply-To: <1361254269-3444-1-git-send-email-alekskartashov@parallels.com>
References: <1361254269-3444-1-git-send-email-alekskartashov@parallels.com>
Message-ID: <20130715173238.GJ1730@moon>

On Tue, Feb 19, 2013 at 10:11:09AM +0400, Alexander Kartashov wrote:
> Currently IPC SHM works in a strange way on ARM:
> the syscall sys_shmat() requires the argument shmaddr
> be SHMLBA-aligned (ARM has the macro __ARCH_FORCE_SHMLBA
> unconditionally defined) but allocates memory that
> isn't SHMLBA-aligned because the value of memory alignment
> depends on presense of certain cache aliases.

Hi guys, is there some conclusion on this patch? It has been sent
almost 5 months back ;)


From jason at lakedaemon.net  Mon Jul 15 13:33:30 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 15 Jul 2013 13:33:30 -0400
Subject: [PATCHv5 00/11] MSI support for Marvell EBU PCIe driver
In-Reply-To: <51E4167B.4000208@wwwdotorg.org>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E4167B.4000208@wwwdotorg.org>
Message-ID: <20130715173329.GA12062@titan.lakedaemon.net>

On Mon, Jul 15, 2013 at 09:34:19AM -0600, Stephen Warren wrote:
> On 07/15/2013 05:52 AM, Thomas Petazzoni wrote:
> > Hello,
> > 
> > This set of patches introduces Message Signaled Interrupt support in
> > the Marvell EBU PCIe driver. It has been successfully tested on the
> > Armada XP GP platform with an Intel e1000e PCIe network card that
> > supports MSI.
> > 
> > This patch set is intended for merging in 3.12, so the respective
> > maintainers of the different areas are invited to review/ack the
> > patches, see below for the details. This set of patches applies on top
> > of 3.11-rc1.
> 
> Thomas, who is going to merge this series?

In a previous version of this series, Thomas and I discussed the
feasibility of sending the irq changes through tglx, the pci changes
through Bjorn, and the mvebu stuff through us.  With that version,
Thomas felt it would work out fine, without depending on each other.

If this is still the case, we'll just ask Thomas and Bjorn (or, at least
Bjorn) to make topic branches for us.

thx,

Jason.


From swarren at wwwdotorg.org  Mon Jul 15 14:04:44 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 12:04:44 -0600
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
Message-ID: <51E439BC.9030608@wwwdotorg.org>

On 06/25/2013 03:23 AM, Joseph Lo wrote:
> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
> this state.

I tried applying this patch, your series "[PATCH V3 0/3] ARM: tegra114:
cpuidle: add power down state", and your series "[PATCH V2 00/11] ARM:
tegra114: add support for system suspend", all on top of v3.11-rc1.

On Dalmore, the new cpuidle mode /appears/ to work (I see increasing
values in the sysfs cpuidle "usage" file for all defined cpuidle
states), but I don't see the "CPU VDD off" LED light up; I'm not
convinced that the CPU is actually being powered off in the idle mode.

With these patches applies, Harmony acts very strangely. After
hot-unplug and re-plug of CPU1, the system is hung or almost hung. The
patches appear to reduce the amount of time CPU VDD is off judging by
the LEDs. The patches might cause issues with system suspend too, but
I'm not 100% sure.

As such, I haven't applied any of these. Can you please test boards for
all of Tegra20/30/114, and validate that on Dalmore the CPU power is
actually being turned off, and report back? Thanks.


From linux at arm.linux.org.uk  Mon Jul 15 14:08:46 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Jul 2013 19:08:46 +0100
Subject: [PATCH] arm: align shared memory unconditionally to the SHMLBA
 boundary
In-Reply-To: <20130715173238.GJ1730@moon>
References: <1361254269-3444-1-git-send-email-alekskartashov@parallels.com>
 <20130715173238.GJ1730@moon>
Message-ID: <20130715180846.GV24642@n2100.arm.linux.org.uk>

On Mon, Jul 15, 2013 at 09:32:38PM +0400, Cyrill Gorcunov wrote:
> On Tue, Feb 19, 2013 at 10:11:09AM +0400, Alexander Kartashov wrote:
> > Currently IPC SHM works in a strange way on ARM:
> > the syscall sys_shmat() requires the argument shmaddr
> > be SHMLBA-aligned (ARM has the macro __ARCH_FORCE_SHMLBA
> > unconditionally defined) but allocates memory that
> > isn't SHMLBA-aligned because the value of memory alignment
> > depends on presense of certain cache aliases.
> 
> Hi guys, is there some conclusion on this patch? It has been sent
> almost 5 months back ;)

It's pointless.  The alignment is only required for CPUs which have
aliasing caches.  What the code does in mmap() is correct.  However,
we can't dynamically select this in the SHM code.


From festevam at gmail.com  Mon Jul 15 14:10:59 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 15 Jul 2013 15:10:59 -0300
Subject: [PATCH 20/22] arm/dts: Add support for the cpuimx51 board from
 Eukrea and its baseboard.
In-Reply-To: <1373900227-341-21-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-21-git-send-email-denis@eukrea.com>
Message-ID: <CAOMZO5AMA=0Qt_XBYmZXLpPn0ri=JvSV40Qt0CyDNps6GsvAfQ@mail.gmail.com>

Hi Denis,

On Mon, Jul 15, 2013 at 11:57 AM, Denis Carikli <denis at eukrea.com> wrote:

> +i.MX51 Eukrea CPUIMX51 Board
> +Required root node properties:
> +    - compatible = "fsl,eukrea_cpuimx51", "fsl,imx51";
> +

The fsl.txt file contains boards that are developed by Freescale.

The compatible string "fsl,eukrea_cpuimx51" is not correct, as the
cpuimx51 board is not manufactured by Freescale.

You should have used "eukrea" as the manufacturer instead.


From nfortino at nvidia.com  Mon Jul 15 14:19:23 2013
From: nfortino at nvidia.com (Nickolas Fortino)
Date: Mon, 15 Jul 2013 11:19:23 -0700
Subject: preempted dup_mm misses TLB invalidate
Message-ID: <51E43D2B.9090709@nvidia.com>

I?ve noticed an issue in simulation where the Linux kernel is executing 
a user process when the page tables and TLBs have gotten out of sync. 
The page tables have a page marked as user read only, but the TLB has 
the page marked as user read/write.

I?ve traced the issue back to the handling of copy on write pages 
generated from the ?do_fork?, ?copy_process?, ?dup_mm?, ?dup_mmap? call 
stack. If run without interruption, ?dup_mmap? calls 
?flush_tlb_mm(oldmm)? on completion, avoiding any issues. In this case, 
however, about 4 million instructions after ?dup_mm? is called, 
?copy_pte_range? yields to another thread via __cond_resched. About 20 
million instructions later, a user process with the ASID of the source 
mm is scheduled. This process performs a store to a page modified from 
read/write to read only in the copy on write logic of ?copy_one_pte?. 
Because the TLB was not invalidated, the store hits on a TLB entry with 
read/write permissions and succeeds without a fault.

What invariant in the Linux kernel is supposed to prevent this from 
happening? Note I have not observed user visible corruption, but it 
seems very unlikely a successful store to a page marked as read only in 
the kernel is safe.

For reference, this issue was found with the Linux 3.7 kernel coming 
from the Linaro 12.12 release available at 
http://releases.linaro.org/12.12/android/vexpress


From festevam at gmail.com  Mon Jul 15 14:27:01 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 15 Jul 2013 15:27:01 -0300
Subject: [PATCH 18/22] staging: video: imx: Add RGB666 support for
 parallel display
In-Reply-To: <1373900227-341-19-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-19-git-send-email-denis@eukrea.com>
Message-ID: <CAOMZO5B8CuBR8sjVkDZH6ObLGKUUT1+jHPBujmFAQVGNtA5mBw@mail.gmail.com>

Hi Denis,

On Mon, Jul 15, 2013 at 11:57 AM, Denis Carikli <denis at eukrea.com> wrote:
> Support the RGB666 format on the IPUv3 parallel display.
>
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  .../bindings/staging/imx-drm/fsl-imx-drm.txt       |    2 +-
>  drivers/staging/imx-drm/ipu-v3/ipu-dc.c            |    9 +++++++++
>  drivers/staging/imx-drm/parallel-display.c         |    2 ++
>  3 files changed, 12 insertions(+), 1 deletion(-)

Maybe you could split your series and send all the driver related
patches to their appropriate mailing lists and maintainers.


From swarren at wwwdotorg.org  Mon Jul 15 14:27:36 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 12:27:36 -0600
Subject: [PATCH] ARM: tegra114: Enable Cortex-A15 errata 798181
In-Reply-To: <1372845348-27089-1-git-send-email-josephl@nvidia.com>
References: <1372845348-27089-1-git-send-email-josephl@nvidia.com>
Message-ID: <51E43F18.4090508@wwwdotorg.org>

On 07/03/2013 03:55 AM, Joseph Lo wrote:
> The commit 93dc688 (ARM: 7684/1: errata: Workaround for Cortex-A15
> erratum 798181 (TLBI/DSB operations)) introduecd a workaround for
> Cortex-A15 errata 798181. Enabling it for Tegra114.

Applied to Tegra's for-3.12/soc branch.


From swarren at wwwdotorg.org  Mon Jul 15 14:40:28 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 12:40:28 -0600
Subject: [PATCH V2 4/5] gpio: implement gpio-ranges binding document fix
In-Reply-To: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
References: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1373913629-32179-4-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Use the new of_parse_phandle_with_fixed_args() to implement the
corrected gpio-ranges DT property definition.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 drivers/gpio/gpiolib-of.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 665f953..48cda3c 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -194,8 +194,8 @@ static void of_gpiochip_add_pin_range(struct gpio_chip *chip)
 		return;
 
 	for (;; index++) {
-		ret = of_parse_phandle_with_args(np, "gpio-ranges",
-				"#gpio-range-cells", index, &pinspec);
+		ret = of_parse_phandle_with_fixed_args(np, "gpio-ranges", 3,
+				index, &pinspec);
 		if (ret)
 			break;
 
-- 
1.8.1.5



From swarren at wwwdotorg.org  Mon Jul 15 14:40:25 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 12:40:25 -0600
Subject: [PATCH V2 1/5] gpio: clean up gpio-ranges documentation
Message-ID: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

This change makes documentation of the the gpio-ranges property shorter
and more succinct, more consistent with the style of the rest of the
document, and not mention Linux-specifics such as the API
pinctrl_request_gpio(); DT binding documents should be OS independant
where at all possible.

This change also removes any mention of the #gpio-range-cells property.
Such properties are useful when one node references a second node, and
that second node dictates the format of the reference. However, that is
not the case here; the definition of gpio-ranges itself always dictates
its format entirely, and hence the value #gpio-range-cells must always
be 3, and hence there is no point requiring any referenced node to
include this property.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
Patches 2-6 need to be applied in the same branch, since they all build
upon each-other.
---
 Documentation/devicetree/bindings/gpio/gpio.txt | 48 ++++++++++++-------------
 1 file changed, 23 insertions(+), 25 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index d933af3..b262378 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -75,23 +75,29 @@ Example of two SOC GPIO banks defined as gpio-controller nodes:
 		gpio-controller;
 	};
 
-2.1) gpio-controller and pinctrl subsystem
-------------------------------------------
+2.1) gpio- and pin-controller interaction
+-----------------------------------------
 
-gpio-controller on a SOC might be tightly coupled with the pinctrl
-subsystem, in the sense that the pins can be used by other functions
-together with optional gpio feature.
+Some or all of the GPIOs provided by a GPIO controller may be routed to pins
+on the package via a pin controller. This allows muxing those pins between
+GPIO and other functions.
 
-While the pin allocation is totally managed by the pin ctrl subsystem,
-gpio (under gpiolib) is still maintained by gpio drivers. It may happen
-that different pin ranges in a SoC is managed by different gpio drivers.
+It is useful to represent which GPIOs correspond to which pins on which pin
+controllers. The gpio-ranges property described below represents this, and
+contains information strucutres as follows:
 
-This makes it logical to let gpio drivers announce their pin ranges to
-the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to
-request the corresponding pin before any gpio usage.
+	gpio-range-list ::= <single-gpio-range> [gpio-range-list]
+	single-gpio-range ::=
+			<pinctrl-phandle> <gpio-base> <pinctrl-base> <count>
+	gpio-phandle : phandle to pin controller node.
+	gpio-base : Base GPIO ID in the GPIO controller
+	pinctrl-base : Base pinctrl pin ID in the pin controller
+	count : The number of GPIOs/pins in this range
 
-For this, the gpio controller can use a pinctrl phandle and pins to
-announce the pinrange to the pin ctrl subsystem. For example,
+The "pin controller node" mentioned above must conform to the bindings
+described in ../pinctrl/pinctrl-bindings.txt.
+
+Example:
 
 	qe_pio_e: gpio-controller at 1460 {
 		#gpio-cells = <2>;
@@ -99,16 +105,8 @@ announce the pinrange to the pin ctrl subsystem. For example,
 		reg = <0x1460 0x18>;
 		gpio-controller;
 		gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>;
+	};
 
-    }
-
-where,
-   &pinctrl1 and &pinctrl2 is the phandle to the pinctrl DT node.
-
-   Next values specify the base pin and number of pins for the range
-   handled by 'qe_pio_e' gpio. In the given example from base pin 20 to
-   pin 29 under pinctrl1 with gpio offset 0 and pin 50 to pin 69 under
-   pinctrl2 with gpio offset 10 is handled by this gpio controller.
-
-The pinctrl node must have "#gpio-range-cells" property to show number of
-arguments to pass with phandle from gpio controllers node.
+Here, a single GPIO controller has GPIOs 0..9 routed to pin controller
+pinctrl1's pins 20..29, and GPIOs 10..19 routed to pin controller pinctrl2's
+pins 50..59.
-- 
1.8.1.5



From swarren at wwwdotorg.org  Mon Jul 15 14:40:26 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 12:40:26 -0600
Subject: [PATCH V2 2/5] of: move documentation of of_parse_phandle_with_args
In-Reply-To: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
References: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1373913629-32179-2-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Commit bd69f73 "of: Create function for counting number of phandles in
a property" renamed of_parse_phandle_with_args(), and created a wrapper
function that implemented the original name. However, the documentation
of the original function was not moved, leaving it apparently documenting
the newly renamed function.

Move the documentation so that it is adjacent to the function it
documents.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 drivers/of/base.c | 64 +++++++++++++++++++++++++++----------------------------
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5c54279..23e7073 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1104,38 +1104,6 @@ struct device_node *of_parse_phandle(const struct device_node *np,
 }
 EXPORT_SYMBOL(of_parse_phandle);
 
-/**
- * of_parse_phandle_with_args() - Find a node pointed by phandle in a list
- * @np:		pointer to a device tree node containing a list
- * @list_name:	property name that contains a list
- * @cells_name:	property name that specifies phandles' arguments count
- * @index:	index of a phandle to parse out
- * @out_args:	optional pointer to output arguments structure (will be filled)
- *
- * This function is useful to parse lists of phandles and their arguments.
- * Returns 0 on success and fills out_args, on error returns appropriate
- * errno value.
- *
- * Caller is responsible to call of_node_put() on the returned out_args->node
- * pointer.
- *
- * Example:
- *
- * phandle1: node1 {
- * 	#list-cells = <2>;
- * }
- *
- * phandle2: node2 {
- * 	#list-cells = <1>;
- * }
- *
- * node3 {
- * 	list = <&phandle1 1 2 &phandle2 3>;
- * }
- *
- * To get a device_node of the `node2' node you may call this:
- * of_parse_phandle_with_args(node3, "list", "#list-cells", 1, &args);
- */
 static int __of_parse_phandle_with_args(const struct device_node *np,
 					const char *list_name,
 					const char *cells_name, int index,
@@ -1238,6 +1206,38 @@ static int __of_parse_phandle_with_args(const struct device_node *np,
 	return rc;
 }
 
+/**
+ * of_parse_phandle_with_args() - Find a node pointed by phandle in a list
+ * @np:		pointer to a device tree node containing a list
+ * @list_name:	property name that contains a list
+ * @cells_name:	property name that specifies phandles' arguments count
+ * @index:	index of a phandle to parse out
+ * @out_args:	optional pointer to output arguments structure (will be filled)
+ *
+ * This function is useful to parse lists of phandles and their arguments.
+ * Returns 0 on success and fills out_args, on error returns appropriate
+ * errno value.
+ *
+ * Caller is responsible to call of_node_put() on the returned out_args->node
+ * pointer.
+ *
+ * Example:
+ *
+ * phandle1: node1 {
+ * 	#list-cells = <2>;
+ * }
+ *
+ * phandle2: node2 {
+ * 	#list-cells = <1>;
+ * }
+ *
+ * node3 {
+ * 	list = <&phandle1 1 2 &phandle2 3>;
+ * }
+ *
+ * To get a device_node of the `node2' node you may call this:
+ * of_parse_phandle_with_args(node3, "list", "#list-cells", 1, &args);
+ */
 int of_parse_phandle_with_args(const struct device_node *np, const char *list_name,
 				const char *cells_name, int index,
 				struct of_phandle_args *out_args)
-- 
1.8.1.5



From swarren at wwwdotorg.org  Mon Jul 15 14:40:27 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 12:40:27 -0600
Subject: [PATCH V2 3/5] of: introduce of_parse_phandle_with_fixed_args
In-Reply-To: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
References: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1373913629-32179-3-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

This is identical to of_parse_phandle_with_args(), except that the
number of argument cells is fixed, rather than being parsed out of the
node referenced by each phandle.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 drivers/of/base.c  | 67 ++++++++++++++++++++++++++++++++++++++++++++++--------
 include/linux/of.h | 10 ++++++++
 2 files changed, 68 insertions(+), 9 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 23e7073..ad799d9 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1106,7 +1106,8 @@ EXPORT_SYMBOL(of_parse_phandle);
 
 static int __of_parse_phandle_with_args(const struct device_node *np,
 					const char *list_name,
-					const char *cells_name, int index,
+					const char *cells_name,
+					int cells_count, int index,
 					struct of_phandle_args *out_args)
 {
 	const __be32 *list, *list_end;
@@ -1142,12 +1143,17 @@ static int __of_parse_phandle_with_args(const struct device_node *np,
 					 np->full_name);
 				goto err;
 			}
-			if (of_property_read_u32(node, cells_name, &count)) {
-				pr_err("%s: could not get %s for %s\n",
-					 np->full_name, cells_name,
-					 node->full_name);
-				goto err;
-			}
+
+			if (cells_name) {
+				if (of_property_read_u32(node, cells_name,
+							 &count)) {
+					pr_err("%s: could not get %s for %s\n",
+						np->full_name, cells_name,
+						node->full_name);
+					goto err;
+				}
+			} else
+				count = cells_count;
 
 			/*
 			 * Make sure that the arguments actually fit in the
@@ -1244,11 +1250,53 @@ int of_parse_phandle_with_args(const struct device_node *np, const char *list_na
 {
 	if (index < 0)
 		return -EINVAL;
-	return __of_parse_phandle_with_args(np, list_name, cells_name, index, out_args);
+	return __of_parse_phandle_with_args(np, list_name, cells_name, 0,
+					    index, out_args);
 }
 EXPORT_SYMBOL(of_parse_phandle_with_args);
 
 /**
+ * of_parse_phandle_with_fixed_args() - Find a node pointed by phandle in a list
+ * @np:		pointer to a device tree node containing a list
+ * @list_name:	property name that contains a list
+ * @cells_count: number of argument cells following the phandle
+ * @index:	index of a phandle to parse out
+ * @out_args:	optional pointer to output arguments structure (will be filled)
+ *
+ * This function is useful to parse lists of phandles and their arguments.
+ * Returns 0 on success and fills out_args, on error returns appropriate
+ * errno value.
+ *
+ * Caller is responsible to call of_node_put() on the returned out_args->node
+ * pointer.
+ *
+ * Example:
+ *
+ * phandle1: node1 {
+ * }
+ *
+ * phandle2: node2 {
+ * }
+ *
+ * node3 {
+ * 	list = <&phandle1 0 2 &phandle2 2 3>;
+ * }
+ *
+ * To get a device_node of the `node2' node you may call this:
+ * of_parse_phandle_with_fixed_args(node3, "list", 2, 1, &args);
+ */
+int of_parse_phandle_with_fixed_args(const struct device_node *np,
+				const char *list_name, int cells_count,
+				int index, struct of_phandle_args *out_args)
+{
+	if (index < 0)
+		return -EINVAL;
+	return __of_parse_phandle_with_args(np, list_name, NULL, cells_count,
+					   index, out_args);
+}
+EXPORT_SYMBOL(of_parse_phandle_with_fixed_args);
+
+/**
  * of_count_phandle_with_args() - Find the number of phandles references in a property
  * @np:		pointer to a device tree node containing a list
  * @list_name:	property name that contains a list
@@ -1266,7 +1314,8 @@ EXPORT_SYMBOL(of_parse_phandle_with_args);
 int of_count_phandle_with_args(const struct device_node *np, const char *list_name,
 				const char *cells_name)
 {
-	return __of_parse_phandle_with_args(np, list_name, cells_name, -1, NULL);
+	return __of_parse_phandle_with_args(np, list_name, cells_name, 0, -1,
+					    NULL);
 }
 EXPORT_SYMBOL(of_count_phandle_with_args);
 
diff --git a/include/linux/of.h b/include/linux/of.h
index 1fd08ca..0c457f5 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -280,6 +280,9 @@ extern struct device_node *of_parse_phandle(const struct device_node *np,
 extern int of_parse_phandle_with_args(const struct device_node *np,
 	const char *list_name, const char *cells_name, int index,
 	struct of_phandle_args *out_args);
+extern int of_parse_phandle_with_fixed_args(const struct device_node *np,
+	const char *list_name, int cells_count, int index,
+	struct of_phandle_args *out_args);
 extern int of_count_phandle_with_args(const struct device_node *np,
 	const char *list_name, const char *cells_name);
 
@@ -488,6 +491,13 @@ static inline int of_parse_phandle_with_args(struct device_node *np,
 	return -ENOSYS;
 }
 
+static inline int of_parse_phandle_with_fixed_args(const struct device_node *np,
+	const char *list_name, int cells_count, int index,
+	struct of_phandle_args *out_args)
+{
+	return -ENOSYS;
+}
+
 static inline int of_count_phandle_with_args(struct device_node *np,
 					     const char *list_name,
 					     const char *cells_name)
-- 
1.8.1.5



From swarren at wwwdotorg.org  Mon Jul 15 14:40:29 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 12:40:29 -0600
Subject: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property
In-Reply-To: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
References: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1373913629-32179-5-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

This property is no longer required by the GPIO binding. Remove it.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
---
This should presumably be applied along with the previous changes

v2: Squash spear and mxc changes into a single patch; there's no
need to keep vf610.dtsi separate now that this series will go into
v3.12 or later, and that file is part of v3.11-rc1.
---
 arch/arm/boot/dts/spear1310.dtsi | 1 -
 arch/arm/boot/dts/spear1340.dtsi | 1 -
 arch/arm/boot/dts/spear310.dtsi  | 1 -
 arch/arm/boot/dts/spear320.dtsi  | 2 --
 arch/arm/boot/dts/vf610.dtsi     | 1 -
 5 files changed, 6 deletions(-)

diff --git a/arch/arm/boot/dts/spear1310.dtsi b/arch/arm/boot/dts/spear1310.dtsi
index 122ae94..90e99b5 100644
--- a/arch/arm/boot/dts/spear1310.dtsi
+++ b/arch/arm/boot/dts/spear1310.dtsi
@@ -89,7 +89,6 @@
 		pinmux: pinmux at e0700000 {
 			compatible = "st,spear1310-pinmux";
 			reg = <0xe0700000 0x1000>;
-			#gpio-range-cells = <3>;
 		};
 
 		apb {
diff --git a/arch/arm/boot/dts/spear1340.dtsi b/arch/arm/boot/dts/spear1340.dtsi
index 54d128d..5003013 100644
--- a/arch/arm/boot/dts/spear1340.dtsi
+++ b/arch/arm/boot/dts/spear1340.dtsi
@@ -63,7 +63,6 @@
 		pinmux: pinmux at e0700000 {
 			compatible = "st,spear1340-pinmux";
 			reg = <0xe0700000 0x1000>;
-			#gpio-range-cells = <3>;
 		};
 
 		pwm: pwm at e0180000 {
diff --git a/arch/arm/boot/dts/spear310.dtsi b/arch/arm/boot/dts/spear310.dtsi
index 9537208..1e1318e 100644
--- a/arch/arm/boot/dts/spear310.dtsi
+++ b/arch/arm/boot/dts/spear310.dtsi
@@ -25,7 +25,6 @@
 		pinmux: pinmux at b4000000 {
 			compatible = "st,spear310-pinmux";
 			reg = <0xb4000000 0x1000>;
-			#gpio-range-cells = <3>;
 		};
 
 		fsmc: flash at 44000000 {
diff --git a/arch/arm/boot/dts/spear320.dtsi b/arch/arm/boot/dts/spear320.dtsi
index ffea342..f630d0c 100644
--- a/arch/arm/boot/dts/spear320.dtsi
+++ b/arch/arm/boot/dts/spear320.dtsi
@@ -1,4 +1,3 @@
-/*
  * DTS file for SPEAr320 SoC
  *
  * Copyright 2012 Viresh Kumar <viresh.linux at gmail.com>
@@ -24,7 +23,6 @@
 		pinmux: pinmux at b3000000 {
 			compatible = "st,spear320-pinmux";
 			reg = <0xb3000000 0x1000>;
-			#gpio-range-cells = <3>;
 		};
 
 		clcd at 90000000 {
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index e1eb7da..8577780 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -162,7 +162,6 @@
 			iomuxc: iomuxc at 40048000 {
 				compatible = "fsl,vf610-iomuxc";
 				reg = <0x40048000 0x1000>;
-				#gpio-range-cells = <3>;
 
 				/* functions and groups pins */
 
-- 
1.8.1.5



From gsi at denx.de  Mon Jul 15 14:47:32 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:32 +0200
Subject: [PATCH v1 03/24] mtd: mpc5121_nfc: prepare clocks before enabling them
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373914074-20889-4-git-send-email-gsi@denx.de>

must prepare clocks before enabling them, unprepare after disable

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/mtd/nand/mpc5121_nfc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/mpc5121_nfc.c b/drivers/mtd/nand/mpc5121_nfc.c
index 3c9cdcb..eb7771d 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -618,7 +618,7 @@ static void mpc5121_nfc_free(struct device *dev, struct mtd_info *mtd)
 	struct mpc5121_nfc_prv *prv = chip->priv;
 
 	if (prv->clk) {
-		clk_disable(prv->clk);
+		clk_disable_unprepare(prv->clk);
 		clk_put(prv->clk);
 	}
 
@@ -737,7 +737,7 @@ static int mpc5121_nfc_probe(struct platform_device *op)
 		goto error;
 	}
 
-	clk_enable(prv->clk);
+	clk_prepare_enable(prv->clk);
 
 	/* Reset NAND Flash controller */
 	nfc_set(mtd, NFC_CONFIG1, NFC_RESET);
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 15 14:47:33 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:33 +0200
Subject: [PATCH v1 04/24] powerpc: mpc512x: array decl for MCLK registers in
 CCM
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373914074-20889-5-git-send-email-gsi@denx.de>

reword the clock control module's registers declaration such that the
MCLK related registers form an array and get indexed by PSC number

this change is in preparation to COMMON_CLK support for the MPC512x
platform, the changed declaration remains neutral to existing code since
the PSC and MSCAN CCR fields declared here aren't referenced anywhere

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/include/asm/mpc5121.h |   18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/include/asm/mpc5121.h b/arch/powerpc/include/asm/mpc5121.h
index 8ae133e..887d3d6 100644
--- a/arch/powerpc/include/asm/mpc5121.h
+++ b/arch/powerpc/include/asm/mpc5121.h
@@ -32,25 +32,11 @@ struct mpc512x_ccm {
 	u32	scfr2;	/* System Clock Frequency Register 2 */
 	u32	scfr2s;	/* System Clock Frequency Shadow Register 2 */
 	u32	bcr;	/* Bread Crumb Register */
-	u32	p0ccr;	/* PSC0 Clock Control Register */
-	u32	p1ccr;	/* PSC1 CCR */
-	u32	p2ccr;	/* PSC2 CCR */
-	u32	p3ccr;	/* PSC3 CCR */
-	u32	p4ccr;	/* PSC4 CCR */
-	u32	p5ccr;	/* PSC5 CCR */
-	u32	p6ccr;	/* PSC6 CCR */
-	u32	p7ccr;	/* PSC7 CCR */
-	u32	p8ccr;	/* PSC8 CCR */
-	u32	p9ccr;	/* PSC9 CCR */
-	u32	p10ccr;	/* PSC10 CCR */
-	u32	p11ccr;	/* PSC11 CCR */
+	u32	psc_ccr[12];	/* PSC Clock Control Registers */
 	u32	spccr;	/* SPDIF Clock Control Register */
 	u32	cccr;	/* CFM Clock Control Register */
 	u32	dccr;	/* DIU Clock Control Register */
-	u32	m1ccr;	/* MSCAN1 CCR */
-	u32	m2ccr;	/* MSCAN2 CCR */
-	u32	m3ccr;	/* MSCAN3 CCR */
-	u32	m4ccr;	/* MSCAN4 CCR */
+	u32	mscan_ccr[4];	/* MSCAN Clock Control Registers */
 	u8	res[0x98]; /* Reserved */
 };
 
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 15 14:47:30 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:30 +0200
Subject: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373914074-20889-2-git-send-email-gsi@denx.de>

clocks need to get prepared before they can get enabled,
fix the MPC512x PSC SPI master's initialization

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/spi/spi-mpc512x-psc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
index 29fce6a..76b20ea 100644
--- a/drivers/spi/spi-mpc512x-psc.c
+++ b/drivers/spi/spi-mpc512x-psc.c
@@ -395,7 +395,7 @@ static int mpc512x_psc_spi_port_config(struct spi_master *master,
 
 	sprintf(name, "psc%d_mclk", master->bus_num);
 	spiclk = clk_get(&master->dev, name);
-	clk_enable(spiclk);
+	clk_prepare_enable(spiclk);
 	mps->mclk = clk_get_rate(spiclk);
 	clk_put(spiclk);
 
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 15 14:47:29 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:29 +0200
Subject: [PATCH v1 00/24] add COMMON_CLK support for PowerPC MPC512x
Message-ID: <1373914074-20889-1-git-send-email-gsi@denx.de>

this series introduces support for the common clock framework (CCF,
COMMON_CLK Kconfig option) in the PowerPC based MPC512x platform, a
resulting debugfs clk_summary is at the end of the message after the
stats

although the series does touch several subsystems -- serial, spi, net
(can, fs_enet), mtd (nfc), usb, i2c, media (viu), and dts -- all of the
patches are strictly clock related, changes outside of the clock driver
in the mpc512x platform are rather small and local to probe and setup

the distribution was chosen such to not spam too many lists, yet reach
all the relevant maintainers (there appears to be no clk related list,
it's assumed that the clk API is ARM centric, which is why I send the
PowerPC related changes to the ARM list as well), but I'd be happy to
add more participants if necessary

it appears most appropriate to take this series through either the clk
or the powerpc trees after it has passed review and other subsystem
maintainers ACKed the clock setup related driver modifications --
splitting the series and taking the parts through several trees might
reorder the set (make drivers fail to see the device tree specs) or
would create unnecessary dependencies which need to get tracked upon
merges and might defer propagation (unless I missed something)

the series passes 'checkpatch.pl --strict' except for one warning which
cannot get resolved, since that either breaks compilation (the data type
is preset by the clk-provider.h API) or requires a cast which shadows
real mismatches:

  WARNING: static const char * array should probably be static const char * const
  #413: FILE: arch/powerpc/platforms/512x/clock-commonclk.c:335:
  +static const char *parent_names_mux0[] = {

  total: 0 errors, 1 warnings, 0 checks, 836 lines checked


Gerhard Sittig (24):
  spi: mpc512x: prepare clocks before enabling them
  serial: mpc512x: prepare clocks before enabling them
  mtd: mpc5121_nfc: prepare clocks before enabling them
  powerpc: mpc512x: array decl for MCLK registers in CCM
  clk: wrap I/O access for improved portability
  dts: mpc512x: prepare for preprocessor support
  dts: mpc512x: introduce dt-bindings/clock/ header
  dts: mpc512x: add clock related device tree specs
  clk: mpc512x: introduce COMMON_CLK for MPC512x
  dts: mpc512x: add clock specs for client lookups
  net: can: mscan: add a comment on reg to idx mapping
  net: can: mscan: make mpc512x code use common clock
  spi: mpc512x: OF clock lookup, use the 'mclk' name
  powerpc/mpc512x: improve DIU related clock setup
  serial: mpc512x: OF clock lookup, use the 'mclk' name
  clk: mpc512x: remove now obsolete clkdev registration
  serial: mpc512x: setup the PSC FIFO clock as well
  i2c: mpc: OF clock lookup for MPC512x
  USB: fsl-mph-dr-of: OF clock lookup, prepare and enable
  fs_enet: OF clock lookup (non-fatal), prepare and enable
  [media] fsl-viu: OF clock lookup, prepare before enable
  powerpc/fsl-pci: OF clock lookup, prepare before enable
  clk: mpc512x: switch to COMMON_CLK, remove PPC_CLOCK
  net: can: mscan: remove MPC512x non-COMMON_CLK code path

 arch/powerpc/boot/dts/ac14xx.dts                   |    9 +-
 arch/powerpc/boot/dts/include/dt-bindings          |    1 +
 arch/powerpc/boot/dts/mpc5121.dtsi                 |   94 ++-
 arch/powerpc/boot/dts/mpc5121ads.dts               |    2 +-
 arch/powerpc/boot/dts/pdm360ng.dts                 |    2 +-
 arch/powerpc/include/asm/mpc5121.h                 |   18 +-
 arch/powerpc/platforms/512x/Kconfig                |    2 +-
 arch/powerpc/platforms/512x/Makefile               |    3 +-
 arch/powerpc/platforms/512x/clock-commonclk.c      |  762 ++++++++++++++++++++
 arch/powerpc/platforms/512x/clock.c                |  753 -------------------
 arch/powerpc/platforms/512x/mpc512x_shared.c       |  165 +++--
 arch/powerpc/sysdev/fsl_pci.c                      |   15 +
 drivers/clk/clk-divider.c                          |    6 +-
 drivers/clk/clk-gate.c                             |    6 +-
 drivers/clk/clk-mux.c                              |    6 +-
 drivers/i2c/busses/i2c-mpc.c                       |    9 +
 drivers/media/platform/fsl-viu.c                   |   12 +-
 drivers/mtd/nand/mpc5121_nfc.c                     |    4 +-
 drivers/net/can/mscan/mpc5xxx_can.c                |  234 +++---
 .../net/ethernet/freescale/fs_enet/fs_enet-main.c  |   27 +-
 drivers/spi/spi-mpc512x-psc.c                      |    6 +-
 drivers/tty/serial/mpc52xx_uart.c                  |   59 +-
 drivers/usb/host/fsl-mph-dr-of.c                   |   24 +-
 include/dt-bindings/clock/mpc512x-clock.h          |   59 ++
 include/linux/clk-provider.h                       |   33 +
 include/linux/fs_enet_pd.h                         |    3 +
 26 files changed, 1299 insertions(+), 1015 deletions(-)
 create mode 120000 arch/powerpc/boot/dts/include/dt-bindings
 create mode 100644 arch/powerpc/platforms/512x/clock-commonclk.c
 delete mode 100644 arch/powerpc/platforms/512x/clock.c
 create mode 100644 include/dt-bindings/clock/mpc512x-clock.h


$ uname -srm
Linux 3.11.0-rc1-00024-g25dc674 ppc
$ cat /sys/kernel/debug/clk/clk_summary
   clock                        enable_cnt  prepare_cnt  rate
---------------------------------------------------------------------
 ac97                           0           0            24567000
 spdif_rx_in                    0           0            0
 spdif_tx_in                    0           0            0
 psc_mclk_in                    0           0            25000000
 dummy                          1           1            0
 osc                            1           1            25000000
    ref                         1           1            25000000
       sys                      9           9            320000000
          spdif-mux0            0           0            320000000
             spdif-en0          0           0            320000000
                spdif_mclk_div  0           0            80000000
                   spdif_mclk_out 0           0            80000000
                      spdif_mclk 0           0            80000000
          mscan3-mux0           1           1            320000000
             mscan3-en0         1           1            320000000
                mscan3_mclk_div 1           1            80000000
                   mscan3_mclk_out 1           1            80000000
                      mscan3_mclk 1           1            80000000
          mscan2-mux0           1           1            320000000
             mscan2-en0         1           1            320000000
                mscan2_mclk_div 1           1            80000000
                   mscan2_mclk_out 1           1            80000000
                      mscan2_mclk 1           1            80000000
          mscan1-mux0           1           1            320000000
             mscan1-en0         1           1            320000000
                mscan1_mclk_div 1           1            16000000
                   mscan1_mclk_out 1           1            16000000
                      mscan1_mclk 2           2            16000000
          mscan0-mux0           1           1            320000000
             mscan0-en0         1           1            320000000
                mscan0_mclk_div 1           1            16000000
                   mscan0_mclk_out 1           1            16000000
                      mscan0_mclk 2           2            16000000
          psc11-mux0            0           0            320000000
             psc11-en0          0           0            320000000
                psc11_mclk_div  0           0            80000000
                   psc11_mclk_out 0           0            80000000
                      psc11_mclk 0           0            80000000
          psc10-mux0            0           0            320000000
             psc10-en0          0           0            320000000
                psc10_mclk_div  0           0            80000000
                   psc10_mclk_out 0           0            80000000
                      psc10_mclk 0           0            80000000
          psc9-mux0             0           0            320000000
             psc9-en0           0           0            320000000
                psc9_mclk_div   0           0            80000000
                   psc9_mclk_out 0           0            80000000
                      psc9_mclk 0           0            80000000
          psc8-mux0             0           0            320000000
             psc8-en0           0           0            320000000
                psc8_mclk_div   0           0            80000000
                   psc8_mclk_out 0           0            80000000
                      psc8_mclk 0           0            80000000
          psc7-mux0             0           0            320000000
             psc7-en0           0           0            320000000
                psc7_mclk_div   0           0            80000000
                   psc7_mclk_out 0           0            80000000
                      psc7_mclk 0           0            80000000
          psc6-mux0             0           0            320000000
             psc6-en0           0           0            320000000
                psc6_mclk_div   0           0            80000000
                   psc6_mclk_out 0           0            80000000
                      psc6_mclk 0           0            80000000
          psc5-mux0             1           1            320000000
             psc5-en0           1           1            320000000
                psc5_mclk_div   1           1            80000000
                   psc5_mclk_out 1           1            80000000
                      psc5_mclk 1           1            80000000
          psc4-mux0             1           1            320000000
             psc4-en0           1           1            320000000
                psc4_mclk_div   1           1            80000000
                   psc4_mclk_out 1           1            80000000
                      psc4_mclk 1           1            80000000
          psc3-mux0             1           1            320000000
             psc3-en0           1           1            320000000
                psc3_mclk_div   1           1            80000000
                   psc3_mclk_out 1           1            80000000
                      psc3_mclk 1           1            80000000
          psc2-mux0             0           0            320000000
             psc2-en0           0           0            320000000
                psc2_mclk_div   0           0            80000000
                   psc2_mclk_out 0           0            80000000
                      psc2_mclk 0           0            80000000
          psc1-mux0             0           0            320000000
             psc1-en0           0           0            320000000
                psc1_mclk_div   0           0            80000000
                   psc1_mclk_out 0           0            80000000
                      psc1_mclk 0           0            80000000
          psc0-mux0             0           0            320000000
             psc0-en0           0           0            320000000
                psc0_mclk_div   0           0            80000000
                   psc0_mclk_out 0           0            80000000
                      psc0_mclk 0           0            80000000
          ddr-ug                1           1            160000000
             ddr                1           1            160000000
          csb                   4           4            160000000
             viu                0           0            160000000
             iim                0           0            160000000
             usb2               0           0            160000000
             usb1               0           0            160000000
             axe                0           0            160000000
             pci-ug             0           0            26666666
                pci             0           0            26666666
             mbx-bus-ug         0           0            80000000
                mbx-bus         0           0            80000000
                mbx-ug          0           0            80000000
                   mbx          0           0            80000000
                   mbx-3d-ug    0           0            80000000
                      mbx-3d    0           0            80000000
             e300               1           1            400000000
             diu-x4             1           1            640000000
                diu-ug          1           1            2509803
                   diu          2           2            2509803
             sdhc-x4            1           1            640000000
                sdhc-ug         1           1            53333333
                   sdhc-2       0           0            53333333
                   sdhc         1           1            53333333
             ips                7           7            80000000
                i2c             3           3            80000000
                mem             1           1            80000000
                fec             1           1            80000000
                sata            0           0            80000000
                psc-fifo        1           1            80000000
                pata            0           0            80000000
                lpc-ug          1           1            40000000
                   lpc          1           1            40000000
                nfc-ug          0           0            40000000
                   nfc          0           0            40000000

-- 
1.7.10.4



From gsi at denx.de  Mon Jul 15 14:47:39 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:39 +0200
Subject: [PATCH v1 10/24] dts: mpc512x: add clock specs for client lookups
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373914074-20889-11-git-send-email-gsi@denx.de>

this addresses the client side of device tree based clock lookups:
add clock specifiers to the mbx, nfc, mscan, sdhc, i2c, axe, diu,
viu, mdio, fec, usb, pata, psc, psc fifo, and pci nodes in the
shared mpc5121.dtsi include

these specs map 'clock-names' encoded in drivers to their respective
'struct clk' items in the platform's clock driver; some drivers
still need to learn how to lookup OF clocks, other drivers will
transparently probe successfully on MPC512x as well (sdhc)

few 'clock-names' (nfc, viu) use strings that are encoded in their
respective drivers to keep up compatibility, an alternative approach
would be to register clkdev items in the platform's clock driver for
the migration period

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/boot/dts/mpc5121.dtsi |   79 ++++++++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi b/arch/powerpc/boot/dts/mpc5121.dtsi
index 8f4cba0..983da9c 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -51,6 +51,10 @@
 		compatible = "fsl,mpc5121-mbx";
 		reg = <0x20000000 0x4000>;
 		interrupts = <66 0x8>;
+		clocks = <&clks MPC512x_CLK_MBX_BUS>,
+			 <&clks MPC512x_CLK_MBX_3D>,
+			 <&clks MPC512x_CLK_MBX>;
+		clock-names = "mbx-bus", "mbx-3d", "mbx";
 	};
 
 	sram at 30000000 {
@@ -64,6 +68,8 @@
 		interrupts = <6 8>;
 		#address-cells = <1>;
 		#size-cells = <1>;
+		clocks = <&clks MPC512x_CLK_NFC>;
+		clock-names = "nfc_clk";	/* backwards compat */
 	};
 
 	localbus at 80000020 {
@@ -153,12 +159,22 @@
 			compatible = "fsl,mpc5121-mscan";
 			reg = <0x1300 0x80>;
 			interrupts = <12 0x8>;
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SYS>,
+				 <&clks MPC512x_CLK_REF>,
+				 <&clks MPC512x_CLK_MSCAN0_MCLK>;
+			clock-names = "ips", "sys", "ref", "mclk";
 		};
 
 		can at 1380 {
 			compatible = "fsl,mpc5121-mscan";
 			reg = <0x1380 0x80>;
 			interrupts = <13 0x8>;
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SYS>,
+				 <&clks MPC512x_CLK_REF>,
+				 <&clks MPC512x_CLK_MSCAN1_MCLK>;
+			clock-names = "ips", "sys", "ref", "mclk";
 		};
 
 		sdhc at 1500 {
@@ -167,6 +183,9 @@
 			interrupts = <8 0x8>;
 			dmas = <&dma0 30>;
 			dma-names = "rx-tx";
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SDHC>;
+			clock-names = "ipg", "per";
 		};
 
 		i2c at 1700 {
@@ -175,6 +194,8 @@
 			compatible = "fsl,mpc5121-i2c", "fsl-i2c";
 			reg = <0x1700 0x20>;
 			interrupts = <9 0x8>;
+			clocks = <&clks MPC512x_CLK_I2C>;
+			clock-names = "per";
 		};
 
 		i2c at 1720 {
@@ -183,6 +204,8 @@
 			compatible = "fsl,mpc5121-i2c", "fsl-i2c";
 			reg = <0x1720 0x20>;
 			interrupts = <10 0x8>;
+			clocks = <&clks MPC512x_CLK_I2C>;
+			clock-names = "per";
 		};
 
 		i2c at 1740 {
@@ -191,6 +214,8 @@
 			compatible = "fsl,mpc5121-i2c", "fsl-i2c";
 			reg = <0x1740 0x20>;
 			interrupts = <11 0x8>;
+			clocks = <&clks MPC512x_CLK_I2C>;
+			clock-names = "per";
 		};
 
 		i2ccontrol at 1760 {
@@ -202,30 +227,46 @@
 			compatible = "fsl,mpc5121-axe";
 			reg = <0x2000 0x100>;
 			interrupts = <42 0x8>;
+			clocks = <&clks MPC512x_CLK_AXE>;
+			clock-names = "per";
 		};
 
 		display at 2100 {
 			compatible = "fsl,mpc5121-diu";
 			reg = <0x2100 0x100>;
 			interrupts = <64 0x8>;
+			clocks = <&clks MPC512x_CLK_DIU>;
+			clock-names = "per";
 		};
 
 		can at 2300 {
 			compatible = "fsl,mpc5121-mscan";
 			reg = <0x2300 0x80>;
 			interrupts = <90 0x8>;
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SYS>,
+				 <&clks MPC512x_CLK_REF>,
+				 <&clks MPC512x_CLK_MSCAN2_MCLK>;
+			clock-names = "ips", "sys", "ref", "mclk";
 		};
 
 		can at 2380 {
 			compatible = "fsl,mpc5121-mscan";
 			reg = <0x2380 0x80>;
 			interrupts = <91 0x8>;
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SYS>,
+				 <&clks MPC512x_CLK_REF>,
+				 <&clks MPC512x_CLK_MSCAN3_MCLK>;
+			clock-names = "ips", "sys", "ref", "mclk";
 		};
 
 		viu at 2400 {
 			compatible = "fsl,mpc5121-viu";
 			reg = <0x2400 0x400>;
 			interrupts = <67 0x8>;
+			clocks = <&clks MPC512x_CLK_VIU>;
+			clock-names = "viu_clk";	/* backwards compat */
 		};
 
 		mdio at 2800 {
@@ -233,6 +274,8 @@
 			reg = <0x2800 0x800>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+			clocks = <&clks MPC512x_CLK_FEC>;
+			clock-names = "per";
 		};
 
 		eth0: ethernet at 2800 {
@@ -241,6 +284,8 @@
 			reg = <0x2800 0x800>;
 			local-mac-address = [ 00 00 00 00 00 00 ];
 			interrupts = <4 0x8>;
+			clocks = <&clks MPC512x_CLK_FEC>;
+			clock-names = "per";
 		};
 
 		/* USB1 using external ULPI PHY */
@@ -252,6 +297,8 @@
 			interrupts = <43 0x8>;
 			dr_mode = "otg";
 			phy_type = "ulpi";
+			clocks = <&clks MPC512x_CLK_USB1>;
+			clock-names = "per";
 		};
 
 		/* USB0 using internal UTMI PHY */
@@ -263,6 +310,8 @@
 			interrupts = <44 0x8>;
 			dr_mode = "otg";
 			phy_type = "utmi_wide";
+			clocks = <&clks MPC512x_CLK_USB2>;
+			clock-names = "per";
 		};
 
 		/* IO control */
@@ -281,6 +330,8 @@
 			compatible = "fsl,mpc5121-pata";
 			reg = <0x10200 0x100>;
 			interrupts = <5 0x8>;
+			clocks = <&clks MPC512x_CLK_PATA>;
+			clock-names = "per";
 		};
 
 		/* 512x PSCs are not 52xx PSC compatible */
@@ -292,6 +343,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC0_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC1 */
@@ -301,6 +354,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC1_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC2 */
@@ -310,6 +365,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC2_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC3 */
@@ -319,6 +376,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC3_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC4 */
@@ -328,6 +387,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC4_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC5 */
@@ -337,6 +398,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC5_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC6 */
@@ -346,6 +409,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC6_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC7 */
@@ -355,6 +420,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC7_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC8 */
@@ -364,6 +431,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC8_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC9 */
@@ -373,6 +442,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC9_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC10 */
@@ -382,6 +453,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC10_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC11 */
@@ -391,12 +464,16 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC11_MCLK>;
+			clock-names = "mclk";
 		};
 
 		pscfifo at 11f00 {
 			compatible = "fsl,mpc5121-psc-fifo";
 			reg = <0x11f00 0x100>;
 			interrupts = <40 0x8>;
+			clocks = <&clks MPC512x_CLK_PSC_FIFO>;
+			clock-names = "per";
 		};
 
 		dma0: dma at 14000 {
@@ -414,6 +491,8 @@
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
+		clocks = <&clks MPC512x_CLK_PCI>;
+		clock-names = "per";
 
 		reg = <0x80008500 0x100	/* internal registers */
 		       0x80008300 0x8>;	/* config space access registers */
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 15 14:47:31 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:31 +0200
Subject: [PATCH v1 02/24] serial: mpc512x: prepare clocks before enabling them
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373914074-20889-3-git-send-email-gsi@denx.de>

clocks need to get prepared before they can get enabled, and after
disabling them they can get unprepared

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/tty/serial/mpc52xx_uart.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/mpc52xx_uart.c b/drivers/tty/serial/mpc52xx_uart.c
index e1280a2..53c1093 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -636,9 +636,9 @@ static int mpc512x_psc_clock(struct uart_port *port, int enable)
 	dev_dbg(port->dev, "%s %sable\n", clk_name, enable ? "en" : "dis");
 
 	if (enable)
-		clk_enable(psc_clk);
+		clk_prepare_enable(psc_clk);
 	else
-		clk_disable(psc_clk);
+		clk_disable_unprepare(psc_clk);
 
 	return 0;
 }
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 15 14:47:38 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:38 +0200
Subject: [PATCH v1 09/24] clk: mpc512x: introduce COMMON_CLK for MPC512x
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373914074-20889-10-git-send-email-gsi@denx.de>

this change introduces a clock infrastructure implementation for the
MPC512x PowerPC platform which follows the COMMON_CLK approach and uses
common clock drivers shared with other platforms

this driver implements the publicly announced set of clocks (which can
get referenced by means of symbolic identifiers from the dt-bindings
header file), as well as generates additional 'struct clk' items where
the SoC hardware cannot easily get mapped to the common primitives of
the clock API, or requires "intermediate" clock nodes to represent
clocks that have both gates and dividers

the previous PPC_CLOCK implementation is kept in place and resides in
parallel to the common clock implementation for test and comparison
during migration, a compile time option picks one of the two
alternatives (Kconfig switch, common clock used by default)

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/Kconfig           |   14 +-
 arch/powerpc/platforms/512x/Makefile          |    4 +-
 arch/powerpc/platforms/512x/clock-commonclk.c |  777 +++++++++++++++++++++++++
 include/linux/clk-provider.h                  |   16 +
 4 files changed, 809 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/platforms/512x/clock-commonclk.c

diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig
index fc9c1cb..c5fcdd0 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -1,9 +1,21 @@
+config MPC512x_COMMON_CLK
+	bool "MPC512x platform uses COMMON_CLK"
+	default y
+	depends on PPC_MPC512x
+	help
+	  This option is only here to support tests and comparison
+	  during development and migration.  This option will get
+	  removed after the COMMON_CLK support for MPC512x has become
+	  fully operational and all drivers were adjusted to explicitly
+	  acquire their required clocks.
+
 config PPC_MPC512x
 	bool "512x-based boards"
 	depends on 6xx
 	select FSL_SOC
 	select IPIC
-	select PPC_CLOCK
+	select PPC_CLOCK if !MPC512x_COMMON_CLK
+	select COMMON_CLK if MPC512x_COMMON_CLK
 	select PPC_PCI_CHOICE
 	select FSL_PCI if PCI
 	select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/powerpc/platforms/512x/Makefile b/arch/powerpc/platforms/512x/Makefile
index 72fb934..1e05f9d 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -1,7 +1,9 @@
 #
 # Makefile for the Freescale PowerPC 512x linux kernel.
 #
-obj-y				+= clock.o mpc512x_shared.o
+obj-$(CONFIG_PPC_CLOCK)		+= clock.o
+obj-$(CONFIG_COMMON_CLK)	+= clock-commonclk.o
+obj-y				+= mpc512x_shared.o
 obj-$(CONFIG_MPC5121_ADS)	+= mpc5121_ads.o mpc5121_ads_cpld.o
 obj-$(CONFIG_MPC512x_GENERIC)	+= mpc512x_generic.o
 obj-$(CONFIG_PDM360NG)		+= pdm360ng.o
diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
new file mode 100644
index 0000000..218f55b
--- /dev/null
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -0,0 +1,777 @@
+/*
+ * Copyright (C) 2013 DENX Software Engineering
+ *
+ * Gerhard Sittig, <gsi at denx.de>
+ *
+ * common clock driver support for the MPC512x platform
+ *
+ * This is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+#include <linux/of.h>
+
+#include <asm/mpc5121.h>
+#include <dt-bindings/clock/mpc512x-clock.h>
+
+#include "mpc512x.h"		/* our public mpc5121_clk_init() API */
+
+/* helpers to keep the MCLK intermediates "somewhere" in our table */
+enum {
+	MCLK_IDX_MUX0,
+	MCLK_IDX_EN0,
+	MCLK_IDX_DIV0,
+	MCLK_IDX_MUX1,
+	MCLK_MAX_IDX,
+};
+
+#define NR_PSCS			12
+#define NR_MSCANS		4
+#define NR_SPDIFS		1
+#define NR_MCLKS		(NR_PSCS + NR_MSCANS + NR_SPDIFS)
+
+/* extend the public set of clocks by adding internal slots for management */
+enum {
+	/* arrange for adjacent numbers after the public set */
+	MPC512x_CLK_START_PRIVATE = MPC512x_CLK_LAST_PUBLIC,
+	/* clocks which aren't announced to the public */
+	MPC512x_CLK_DDR,
+	MPC512x_CLK_MEM,
+	MPC512x_CLK_IIM,
+	MPC512x_CLK_SDHC_2,
+	/* intermediates in div+gate combos or fractional dividers */
+	MPC512x_CLK_DDR_UG,
+	MPC512x_CLK_SDHC_x4,
+	MPC512x_CLK_SDHC_UG,
+	MPC512x_CLK_DIU_x4,
+	MPC512x_CLK_DIU_UG,
+	MPC512x_CLK_MBX_BUS_UG,
+	MPC512x_CLK_MBX_UG,
+	MPC512x_CLK_MBX_3D_UG,
+	MPC512x_CLK_PCI_UG,
+	MPC512x_CLK_NFC_UG,
+	MPC512x_CLK_LPC_UG,
+	MPC512x_CLK_SPDIF_TX_IN,
+	/* intermediates for the mux+gate+div+mux MCLK generation */
+	MPC512x_CLK_MCLKS_FIRST,
+	MPC512x_CLK_MCLKS_LAST = MPC512x_CLK_MCLKS_FIRST
+				+ NR_MCLKS * MCLK_MAX_IDX,
+	/* internal, symbolic spec for the number of slots */
+	MPC512x_CLK_LAST_PRIVATE,
+};
+
+/* data required for the OF clock provider registration */
+static struct clk *clks[MPC512x_CLK_LAST_PRIVATE];
+static struct clk_onecell_data clk_data;
+
+/* CCM register access */
+static struct mpc512x_ccm __iomem *clkregs;
+static DEFINE_SPINLOCK(clklock);
+
+/* convenience wrappers around the common clk API */
+static inline struct clk *mpc512x_clk_fixed(const char *name, int rate)
+{
+	return clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
+}
+
+static inline struct clk *mpc512x_clk_factor(
+	const char *name, const char *parent_name,
+	int mul, int div)
+{
+	int clkflags;
+
+	clkflags = CLK_SET_RATE_PARENT;
+	return clk_register_fixed_factor(NULL, name, parent_name, clkflags,
+					 mul, div);
+}
+
+static inline struct clk *mpc512x_clk_divider(
+	const char *name, const char *parent_name, u8 clkflags,
+	u32 __iomem *reg, u8 pos, u8 len, int divflags)
+{
+	return clk_register_divider(NULL, name, parent_name, clkflags,
+				    reg, pos, len, divflags, &clklock);
+}
+
+static inline struct clk *mpc512x_clk_divtable(
+	const char *name, const char *parent_name,
+	u32 __iomem *reg, u8 pos, u8 len,
+	const struct clk_div_table *divtab)
+{
+	u8 divflags;
+
+	divflags = 0;
+	return clk_register_divider_table(NULL, name, parent_name, 0,
+					  reg, pos, len, divflags,
+					  divtab, &clklock);
+}
+
+static inline struct clk *mpc512x_clk_gated(
+	const char *name, const char *parent_name,
+	u32 __iomem *reg, u8 pos)
+{
+	int clkflags;
+
+	clkflags = CLK_SET_RATE_PARENT;
+	return clk_register_gate(NULL, name, parent_name, clkflags,
+				 reg, pos, 0, &clklock);
+}
+
+static inline struct clk *mpc512x_clk_muxed(const char *name,
+	const char **parent_names, int parent_count,
+	u32 __iomem *reg, u8 pos, u8 len)
+{
+	int clkflags;
+	u8 muxflags;
+
+	clkflags = CLK_SET_RATE_PARENT;
+	muxflags = 0;
+	return clk_register_mux(NULL, name,
+				parent_names, parent_count, clkflags,
+				reg, pos, len, muxflags, &clklock);
+}
+
+/* helper to isolate a bit field from a register */
+static inline int get_bit_field(uint32_t __iomem *reg, uint8_t pos, uint8_t len)
+{
+	uint32_t val;
+
+	val = in_be32(reg);
+	val >>= pos;
+	val &= (1 << len) - 1;
+	return val;
+}
+
+/* get the SPMF and translate it into the "sys pll" multiplier */
+static int get_spmf_mult(void)
+{
+	static int spmf_to_mult[] = {
+		68, 1, 12, 16, 20, 24, 28, 32,
+		36, 40, 44, 48, 52, 56, 60, 64,
+	};
+	int spmf;
+
+	spmf = get_bit_field(&clkregs->spmr, 24, 4);
+	return spmf_to_mult[spmf];
+}
+
+/*
+ * get the SYS_DIV value and translate it into a divide factor
+ *
+ * values returned from here are a multiple of the real factor since the
+ * divide ratio is fractional
+ */
+static int get_sys_div_x2(void)
+{
+	static int sysdiv_code_to_x2[] = {
+		4, 5, 6, 7, 8, 9, 10, 14,
+		12, 16, 18, 22, 20, 24, 26, 30,
+		28, 32, 34, 38, 36, 40, 42, 46,
+		44, 48, 50, 54, 52, 56, 58, 62,
+		60, 64, 66,
+	};
+	int divcode;
+
+	divcode = get_bit_field(&clkregs->scfr2, 26, 6);
+	return sysdiv_code_to_x2[divcode];
+}
+
+/*
+ * get the CPMF value and translate it into a multiplier factor
+ *
+ * values returned from here are a multiple of the real factor since the
+ * multiplier ratio is fractional
+ */
+static int get_cpmf_mult_x2(void)
+{
+	static int cpmf_to_mult[] = {
+		72, 2, 2, 3, 4, 5, 6, 7,
+	};
+	int cpmf;
+
+	cpmf = get_bit_field(&clkregs->spmr, 16, 4);
+	return cpmf_to_mult[cpmf];
+}
+
+/*
+ * some of the clock dividers do scale in a linear way, yet not all of
+ * their bit combinations are legal; use a divider table to get a
+ * resulting set of applicable divider values
+ */
+
+/* applies to the IPS_DIV, and PCI_DIV values */
+static struct clk_div_table divtab_2346[] = {
+	{ .val = 2, .div = 2, },
+	{ .val = 3, .div = 3, },
+	{ .val = 4, .div = 4, },
+	{ .val = 6, .div = 6, },
+	{ .div = 0, },
+};
+
+/* applies to the MBX_DIV, LPC_DIV, and NFC_DIV values */
+static struct clk_div_table divtab_1234[] = {
+	{ .val = 1, .div = 1, },
+	{ .val = 2, .div = 2, },
+	{ .val = 3, .div = 3, },
+	{ .val = 4, .div = 4, },
+	{ .div = 0, },
+};
+
+static int get_freq_from_dt(char *propname)
+{
+	struct device_node *np;
+	const unsigned int *prop;
+	int val;
+
+	val = 0;
+	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-immr");
+	if (np) {
+		prop = of_get_property(np, propname, NULL);
+		if (prop)
+			val = *prop;
+	    of_node_put(np);
+	}
+	return val;
+}
+
+static void mpc512x_clk_preset_data(void)
+{
+	size_t i;
+
+	for (i = 0; i < ARRAY_SIZE(clks); i++)
+		clks[i] = ERR_PTR(-ENODEV);
+}
+
+/*
+ * - receives the "bus frequency" from the caller (that's the IPS clock
+ *   rate, the historical source of clock information)
+ * - fetches the system PLL multiplier and divider values as well as the
+ *   IPS divider value from hardware
+ * - determines the REF clock rate either from the XTAL/OSC spec (if
+ *   there is a device tree node describing the oscillator) or from the
+ *   IPS bus clock (supported for backwards compatibility, such that
+ *   setups without XTAL/OSC specs keep working)
+ * - creates the "ref" clock item in the clock tree, such that
+ *   subsequent code can create the remainder of the hierarchy (REF ->
+ *   SYS -> CSB -> IPS) from the REF clock rate and the returned mul/div
+ *   values
+ */
+static void mpc512x_clk_setup_ref_clock(int bus_freq,
+	int *sys_mul, int *sys_div, int *ips_div)
+{
+	struct clk *osc_clk;
+	int calc_freq;
+
+	/* fetch mul/div factors from the hardware */
+	*sys_mul = get_spmf_mult();
+	*sys_mul *= 2;		/* compensate for the fractional divider */
+	*sys_div = get_sys_div_x2();
+	*ips_div = get_bit_field(&clkregs->scfr1, 23, 3);
+
+	/* lookup the oscillator node */
+	osc_clk = clk_get(NULL, "osc");
+	if (osc_clk) {
+		/* descend REF directly from OSC, verify the IPS rate */
+		clks[MPC512x_CLK_REF] = mpc512x_clk_factor("ref", "osc", 1, 1);
+		calc_freq = clk_get_rate(clks[MPC512x_CLK_REF]);
+		calc_freq *= *sys_mul;
+		calc_freq /= *sys_div;
+		calc_freq /= 2;
+		calc_freq /= *ips_div;
+		if (bus_freq && calc_freq != bus_freq)
+			pr_warn("calc rate %d != OF spec %d\n",
+				calc_freq, bus_freq);
+	} else {
+		/* calculate OSC rate and create REF from the freq value */
+		calc_freq = bus_freq;	/* start with IPS */
+		calc_freq *= *ips_div;	/* IPS -> CSB */
+		calc_freq *= 2;		/* CSB -> SYS */
+		calc_freq *= *sys_div;	/* SYS -> PLL out */
+		calc_freq /= *sys_mul;	/* PLL out -> REF == OSC */
+		clks[MPC512x_CLK_REF] = mpc512x_clk_fixed("ref", calc_freq);
+	}
+}
+
+/*
+ * helper code for the MCLK subtree setup
+ *
+ * the overview in section 5.2.4 of the MPC5121e Reference Manual rev4
+ * suggests that all instances of the "PSC clock generation" are equal,
+ * and that one might re-use the PSC setup for MSCAN clock generation
+ * (section 5.2.5) as well, at least the logic if not the data for
+ * description
+ *
+ * the details (starting at page 5-20) show differences in the specific
+ * inputs of the first mux stage ("can clk in", "spdif tx"), and the
+ * factual non-availability of the second mux stage (it's present yet
+ * only one input is valid)
+ *
+ * the MSCAN clock related registers (starting at page 5-35) all
+ * reference "spdif clk" at the first mux stage and don't mention any
+ * "can clk" at all, which somehow is unexpected
+ *
+ * TODO re-check the document, and clarify whether the RM is correct in
+ * the overview or in the details, and whether the difference is a
+ * clipboard induced error or results from chip revisions
+ *
+ * it turns out that the RM rev4 as of 2012-06 talks about "can" for the
+ * PSCs while RM rev3 as of 2008-10 talks about "spdif", so I guess that
+ * first a doc update is required which better reflects reality in the
+ * SoC before the implementation should follow while no questions remain
+ */
+
+/*
+ * note that this declaration raises a checkpatch warning, but
+ * it's the very data type which <linux/clk-provider.h> expects,
+ * making this declaration pass checkpatch will break compilation
+ */
+static const char *parent_names_mux0[] = {
+	"sys", "ref", "psc-mclk-in", "spdif-tx",
+};
+
+enum mclk_type {
+	MCLK_TYPE_PSC,
+	MCLK_TYPE_MSCAN,
+	MCLK_TYPE_SPDIF,
+};
+
+struct mclk_setup_data {
+	enum mclk_type type;
+	int comp_idx;
+	bool has_mclk1;
+	int bit_sccr1, bit_sccr2;
+	const char *name_mux0;
+	const char *name_en0;
+	const char *name_div0;
+	const char *parent_names_mux1[2];
+	const char *name_mux1;
+	const char *name_mclk;
+};
+
+#define MCLK_SETUP_DATA_PSC(id) { \
+	MCLK_TYPE_PSC, id, \
+	0, 27 - id, -1, \
+	"psc" #id "-mux0", \
+	"psc" #id "-en0", \
+	"psc" #id "_mclk_div", \
+	{ "psc" #id "_mclk_div", "dummy", }, \
+	"psc" #id "_mclk_out", \
+	"psc" #id "_mclk", \
+}
+
+#define MCLK_SETUP_DATA_MSCAN(id) { \
+	MCLK_TYPE_MSCAN, id, \
+	0, -1, 25, \
+	"mscan" #id "-mux0", \
+	"mscan" #id "-en0", \
+	"mscan" #id "_mclk_div", \
+	{ "mscan" #id "_mclk_div", "dummy", }, \
+	"mscan" #id "_mclk_out", \
+	"mscan" #id "_mclk", \
+}
+
+#define MCLK_SETUP_DATA_SPDIF { \
+	MCLK_TYPE_SPDIF, 0, \
+	1, -1, 23, \
+	"spdif-mux0", \
+	"spdif-en0", \
+	"spdif_mclk_div", \
+	{ "spdif_mclk_div", "spdif-rx", }, \
+	"spdif_mclk_out", \
+	"spdif_mclk", \
+}
+
+static struct mclk_setup_data mclk_psc_data[] = {
+	MCLK_SETUP_DATA_PSC(0),
+	MCLK_SETUP_DATA_PSC(1),
+	MCLK_SETUP_DATA_PSC(2),
+	MCLK_SETUP_DATA_PSC(3),
+	MCLK_SETUP_DATA_PSC(4),
+	MCLK_SETUP_DATA_PSC(5),
+	MCLK_SETUP_DATA_PSC(6),
+	MCLK_SETUP_DATA_PSC(7),
+	MCLK_SETUP_DATA_PSC(8),
+	MCLK_SETUP_DATA_PSC(9),
+	MCLK_SETUP_DATA_PSC(10),
+	MCLK_SETUP_DATA_PSC(11),
+};
+
+static struct mclk_setup_data mclk_mscan_data[] = {
+	MCLK_SETUP_DATA_MSCAN(0),
+	MCLK_SETUP_DATA_MSCAN(1),
+	MCLK_SETUP_DATA_MSCAN(2),
+	MCLK_SETUP_DATA_MSCAN(3),
+};
+
+static struct mclk_setup_data mclk_spdif_data[] = {
+	MCLK_SETUP_DATA_SPDIF,
+};
+
+/* setup the MCLK clock subtree of an individual PSC/MSCAN/SPDIF */
+static void mpc512x_clk_setup_mclk(struct mclk_setup_data *entry)
+{
+	size_t clks_idx_pub, clks_idx_int;
+	u32 __iomem *mccr_reg;	/* MCLK control register (mux, en, div) */
+	u32 __iomem *sccr_reg;	/* system clock control register (enable) */
+	int sccr_bit;
+	int div;
+
+	/* derive a few parameters from the component type and index */
+	switch (entry->type) {
+	case MCLK_TYPE_PSC:
+		clks_idx_pub = MPC512x_CLK_PSC0_MCLK + entry->comp_idx;
+		clks_idx_int = MPC512x_CLK_MCLKS_FIRST
+			     + (entry->comp_idx) * MCLK_MAX_IDX;
+		mccr_reg = &clkregs->psc_ccr[entry->comp_idx];
+		break;
+	case MCLK_TYPE_MSCAN:
+		clks_idx_pub = MPC512x_CLK_MSCAN0_MCLK + entry->comp_idx;
+		clks_idx_int = MPC512x_CLK_MCLKS_FIRST
+			     + (NR_PSCS + entry->comp_idx) * MCLK_MAX_IDX;
+		mccr_reg = &clkregs->mscan_ccr[entry->comp_idx];
+		break;
+	case MCLK_TYPE_SPDIF:
+		clks_idx_pub = MPC512x_CLK_SPDIF_MCLK;
+		clks_idx_int = MPC512x_CLK_MCLKS_FIRST
+			     + (NR_PSCS + NR_MSCANS) * MCLK_MAX_IDX;
+		mccr_reg = &clkregs->spccr;
+		break;
+	default:
+		return;
+	}
+	if (entry->bit_sccr1 >= 0) {
+		sccr_reg = &clkregs->sccr1;
+		sccr_bit = entry->bit_sccr1;
+	} else if (entry->bit_sccr2 >= 0) {
+		sccr_reg = &clkregs->sccr2;
+		sccr_bit = entry->bit_sccr2;
+	} else {
+		sccr_reg = NULL;
+	}
+
+	/*
+	 * this was grabbed from the PPC_CLOCK implementation, which
+	 * enforced a specific MCLK divider while the clock was gated
+	 * during setup (that's a documented hardware requirement)
+	 *
+	 * the PPC_CLOCK implementation might even have violated the
+	 * "MCLK <= IPS" constraint, the fixed divider value of 1
+	 * results in a divider of 2 and thus MCLK = SYS/2 which equals
+	 * CSB which is greater than IPS; the serial port setup may have
+	 * adjusted the divider which the clock setup might have left in
+	 * an undesirable state
+	 *
+	 * initial setup is:
+	 * - MCLK 0 from SYS
+	 * - MCLK DIV such to not exceed the IPS clock
+	 * - MCLK 0 enabled
+	 * - MCLK 1 from MCLK DIV
+	 */
+	div = clk_get_rate(clks[MPC512x_CLK_SYS]);
+	div /= clk_get_rate(clks[MPC512x_CLK_IPS]);
+	out_be32(mccr_reg, (0 << 16));
+	out_be32(mccr_reg, (0 << 16) | ((div - 1) << 17));
+	out_be32(mccr_reg, (1 << 16) | ((div - 1) << 17));
+
+	/*
+	 * create the 'struct clk' items of the MCLK's clock subtree
+	 *
+	 * note that by design we always create all nodes and won't take
+	 * shortcuts here, because
+	 * - the "internal" MCLK_DIV and MCLK_OUT signal in turn are
+	 *   selectable inputs to the CFM while those who "actually use"
+	 *   the PSC/MSCAN/SPDIF (serial drivers et al) need the MCLK
+	 *   for their bitrate
+	 * - in the absence of "aliases" for clocks we need to create
+	 *   individial 'struct clk' items for whatever might get
+	 *   referenced or looked up, even if several of those items are
+	 *   identical from the logical POV (their rate value)
+	 * - for easier future maintenance and for better reflection of
+	 *   the SoC's documentation, it appears appropriate to generate
+	 *   clock items even for those muxers which actually are NOPs
+	 *   (those with two inputs of which one is reserved)
+	 */
+	clks[clks_idx_int + MCLK_IDX_MUX0] = mpc512x_clk_muxed(
+			entry->name_mux0,
+			&parent_names_mux0[0], ARRAY_SIZE(parent_names_mux0),
+			mccr_reg, 14, 2);
+	clks[clks_idx_int + MCLK_IDX_EN0] = mpc512x_clk_gated(
+			entry->name_en0, entry->name_mux0,
+			mccr_reg, 16);
+	clks[clks_idx_int + MCLK_IDX_DIV0] = mpc512x_clk_divider(
+			entry->name_div0,
+			entry->name_en0, CLK_SET_RATE_GATE,
+			mccr_reg, 17, 15, 0);
+	if (entry->has_mclk1) {
+		clks[clks_idx_int + MCLK_IDX_MUX1] = mpc512x_clk_muxed(
+				entry->name_mux1,
+				&entry->parent_names_mux1[0],
+				ARRAY_SIZE(entry->parent_names_mux1),
+				mccr_reg, 7, 1);
+	} else {
+		clks[clks_idx_int + MCLK_IDX_MUX1] = mpc512x_clk_factor(
+				entry->name_mux1, entry->parent_names_mux1[0],
+				1, 1);
+	}
+	if (sccr_reg) {
+		clks[clks_idx_pub] = mpc512x_clk_gated(
+				entry->name_mclk,
+				entry->name_mux1, sccr_reg, sccr_bit);
+	} else {
+		clks[clks_idx_pub] = mpc512x_clk_factor(
+				entry->name_mclk,
+				entry->name_mux1, 1, 1);
+	}
+
+	/*
+	 * without this "clock device" registration, "simple" lookups in
+	 * the SPI master initialization and serial port setup will fail
+	 *
+	 * those drivers need to get adjusted to lookup their required
+	 * clocks from OF specs, before this clkdev registration becomes
+	 * obsolete
+	 */
+	clk_register_clkdev(clks[clks_idx_pub], entry->name_mclk, NULL);
+}
+
+static void mpc512x_clk_setup_mclks(struct mclk_setup_data *table, size_t count)
+{
+	while (count-- > 0)
+		mpc512x_clk_setup_mclk(table++);
+}
+
+static void mpc512x_clk_setup_clock_tree(int busfreq)
+{
+	int sys_mul, sys_div, ips_div;
+	int mul, div;
+	int freq;
+
+	/*
+	 * TODO
+	 * - consider whether to handle clocks which have both gates and
+	 *   dividers via intermediates or by means of composites
+	 * - fractional dividers appear to not map well to composites
+	 *   since they can be seen as a fixed multiplier and an
+	 *   adjustable divider, while composites can only combine at
+	 *   most one of a mux, div, and gate each into one 'struct clk'
+	 *   item
+	 * - PSC/MSCAN/SPDIF clock generation OTOH already is very
+	 *   specific and cannot get mapped to componsites (at least not
+	 *   a single one, maybe two of them, but see the comment about
+	 *   "intermediates are referenced from elsewhere, too")
+	 * - trim the list of auto-enabled clocks after drivers acquire
+	 *   them correctly as needed
+	 */
+
+	/* regardless of whether XTAL/OSC exists, have REF created */
+	mpc512x_clk_setup_ref_clock(busfreq, &sys_mul, &sys_div, &ips_div);
+
+	/* now setup the REF -> SYS -> CSB -> IPS hierarchy */
+	clks[MPC512x_CLK_SYS] = mpc512x_clk_factor("sys", "ref",
+						   sys_mul, sys_div);
+	clks[MPC512x_CLK_CSB] = mpc512x_clk_factor("csb", "sys", 1, 2);
+	clks[MPC512x_CLK_IPS] = mpc512x_clk_divtable("ips", "csb",
+						     &clkregs->scfr1, 23, 3,
+						     divtab_2346);
+
+	/* now setup anything below SYS and CSB and IPS */
+	clks[MPC512x_CLK_DDR_UG] = mpc512x_clk_factor("ddr-ug", "sys", 1, 2);
+	clks[MPC512x_CLK_SDHC_x4] = mpc512x_clk_factor("sdhc-x4", "csb", 4, 1);
+	clks[MPC512x_CLK_SDHC_UG] = mpc512x_clk_divider("sdhc-ug", "sdhc-x4", 0,
+							&clkregs->scfr2, 0, 8,
+							CLK_DIVIDER_ONE_BASED);
+	clks[MPC512x_CLK_DIU_x4] = mpc512x_clk_factor("diu-x4", "csb", 4, 1);
+	clks[MPC512x_CLK_DIU_UG] = mpc512x_clk_divider("diu-ug", "diu-x4", 0,
+						       &clkregs->scfr1, 0, 8,
+						       CLK_DIVIDER_ONE_BASED);
+
+	/*
+	 * the "power architecture PLL" was setup from data which was
+	 * sampled from the reset config word, at this point in time the
+	 * configuration can be considered fixed and read only (i.e. no
+	 * longer adjustable, or no longer in need of adjustment), which
+	 * is why we don't register a PLL here but assume fixed factors
+	 */
+	mul = get_cpmf_mult_x2();
+	div = 2;	/* compensate for the fractional factor */
+	clks[MPC512x_CLK_E300] = mpc512x_clk_factor("e300", "csb", mul, div);
+
+	clks[MPC512x_CLK_MBX_BUS_UG] = mpc512x_clk_factor("mbx-bus-ug", "csb",
+							  1, 2);
+	clks[MPC512x_CLK_MBX_UG] = mpc512x_clk_divtable("mbx-ug", "mbx-bus-ug",
+							&clkregs->scfr1, 14, 3,
+							divtab_1234);
+	clks[MPC512x_CLK_MBX_3D_UG] = mpc512x_clk_factor("mbx-3d-ug", "mbx-ug",
+							 1, 1);
+	clks[MPC512x_CLK_PCI_UG] = mpc512x_clk_divtable("pci-ug", "csb",
+							&clkregs->scfr1, 20, 3,
+							divtab_2346);
+	clks[MPC512x_CLK_NFC_UG] = mpc512x_clk_divtable("nfc-ug", "ips",
+							&clkregs->scfr1, 8, 3,
+							divtab_1234);
+	clks[MPC512x_CLK_LPC_UG] = mpc512x_clk_divtable("lpc-ug", "ips",
+							&clkregs->scfr1, 11, 3,
+							divtab_1234);
+
+	clks[MPC512x_CLK_LPC] = mpc512x_clk_gated("lpc", "lpc-ug",
+						  &clkregs->sccr1, 30);
+	clks[MPC512x_CLK_NFC] = mpc512x_clk_gated("nfc", "nfc-ug",
+						  &clkregs->sccr1, 29);
+	clks[MPC512x_CLK_PATA] = mpc512x_clk_gated("pata", "ips",
+						   &clkregs->sccr1, 28);
+	mpc512x_clk_setup_mclks(mclk_psc_data, ARRAY_SIZE(mclk_psc_data));
+	clks[MPC512x_CLK_PSC_FIFO] = mpc512x_clk_gated("psc-fifo", "ips",
+						       &clkregs->sccr1, 15);
+	clks[MPC512x_CLK_SATA] = mpc512x_clk_gated("sata", "ips",
+						   &clkregs->sccr1, 14);
+	clks[MPC512x_CLK_FEC] = mpc512x_clk_gated("fec", "ips",
+						  &clkregs->sccr1, 13);
+	clks[MPC512x_CLK_PCI] = mpc512x_clk_gated("pci", "pci-ug",
+						  &clkregs->sccr1, 11);
+	clks[MPC512x_CLK_DDR] = mpc512x_clk_gated("ddr", "ddr-ug",
+						  &clkregs->sccr1, 10);
+
+	clks[MPC512x_CLK_DIU] = mpc512x_clk_gated("diu", "diu-ug",
+						  &clkregs->sccr2, 31);
+	clks[MPC512x_CLK_AXE] = mpc512x_clk_gated("axe", "csb",
+						  &clkregs->sccr2, 30);
+	clks[MPC512x_CLK_MEM] = mpc512x_clk_gated("mem", "ips",
+						  &clkregs->sccr2, 29);
+	clks[MPC512x_CLK_USB1] = mpc512x_clk_gated("usb1", "csb",
+						   &clkregs->sccr2, 28);
+	clks[MPC512x_CLK_USB2] = mpc512x_clk_gated("usb2", "csb",
+						   &clkregs->sccr2, 27);
+	clks[MPC512x_CLK_I2C] = mpc512x_clk_gated("i2c", "ips",
+						  &clkregs->sccr2, 26);
+	mpc512x_clk_setup_mclks(mclk_mscan_data, ARRAY_SIZE(mclk_mscan_data));
+	clks[MPC512x_CLK_SDHC] = mpc512x_clk_gated("sdhc", "sdhc-ug",
+						   &clkregs->sccr2, 24);
+	mpc512x_clk_setup_mclks(mclk_spdif_data, ARRAY_SIZE(mclk_spdif_data));
+	clks[MPC512x_CLK_MBX_BUS] = mpc512x_clk_gated("mbx-bus", "mbx-bus-ug",
+						      &clkregs->sccr2, 22);
+	clks[MPC512x_CLK_MBX] = mpc512x_clk_gated("mbx", "mbx-ug",
+						  &clkregs->sccr2, 21);
+	clks[MPC512x_CLK_MBX_3D] = mpc512x_clk_gated("mbx-3d", "mbx-3d-ug",
+						     &clkregs->sccr2, 20);
+	clks[MPC512x_CLK_IIM] = mpc512x_clk_gated("iim", "csb",
+						  &clkregs->sccr2, 19);
+	clks[MPC512x_CLK_VIU] = mpc512x_clk_gated("viu", "csb",
+						  &clkregs->sccr2, 18);
+	clks[MPC512x_CLK_SDHC_2] = mpc512x_clk_gated("sdhc-2", "sdhc-ug",
+						     &clkregs->sccr2, 17);
+
+	/*
+	 * externally provided clocks (when implemented in hardware,
+	 * device tree may specify values which otherwise were unknown)
+	 */
+	freq = get_freq_from_dt("psc_mclk_in");
+	if (!freq)
+		freq = 25000000;
+	clks[MPC512x_CLK_PSC_MCLK_IN] = mpc512x_clk_fixed("psc_mclk_in", freq);
+	freq = get_freq_from_dt("spdif_tx_in");
+	clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed("spdif_tx_in", freq);
+	freq = get_freq_from_dt("spdif_rx_in");
+	clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed("spdif_rx_in", freq);
+
+	/* fixed frequency for AC97, always 24.567MHz */
+	clks[MPC512x_CLK_AC97] = mpc512x_clk_fixed("ac97", 24567000);
+
+	pr_debug("clock tree setup complete\n");
+	freq = clk_get_rate(clks[MPC512x_CLK_E300]);
+	pr_debug("derived PPC freq [%d]\n", freq);
+	freq = clk_get_rate(clks[MPC512x_CLK_IPS]);
+	pr_debug("derived IPS freq [%d]\n", freq);
+	freq = clk_get_rate(clks[MPC512x_CLK_LPC]);
+	pr_debug("derived LPC freq [%d]\n", freq);
+
+	/* enable some of the clocks here unconditionally because ... */
+	pr_debug("automatically enabling some clocks\n");
+	/* some are essential yet never get claimed by any driver */
+	clk_prepare_enable(clks[MPC512x_CLK_DUMMY]);
+	clk_prepare_enable(clks[MPC512x_CLK_E300]);	/* PowerPC CPU */
+	clk_prepare_enable(clks[MPC512x_CLK_DDR]);	/* DRAM */
+	clk_prepare_enable(clks[MPC512x_CLK_MEM]);	/* SRAM */
+	clk_prepare_enable(clks[MPC512x_CLK_IPS]);	/* SoC periph */
+	clk_prepare_enable(clks[MPC512x_CLK_LPC]);	/* boot media */
+	/* some are required yet no dependencies were declared */
+	clk_prepare_enable(clks[MPC512x_CLK_PSC_FIFO]);
+	/* some are not yet acquired by their respective drivers */
+	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
+	clk_prepare_enable(clks[MPC512x_CLK_FEC]);	/* network, NFS */
+	clk_prepare_enable(clks[MPC512x_CLK_DIU]);	/* display */
+	clk_prepare_enable(clks[MPC512x_CLK_I2C]);
+	/*
+	 * some have their individual clock subtree with separate clock
+	 * items and their individual enable counters, yet share a
+	 * common gate (refer to the same register location) while the
+	 * common clock driver code is not aware of the fact and the
+	 * platform's code doesn't provide specific support either
+	 *
+	 * what might happen is that e.g. enabling two MSCAN clock items
+	 * and disabling one of them will disable the common gate and
+	 * thus break the other MSCAN clock as well
+	 */
+	clk_prepare_enable(clks[MPC512x_CLK_MSCAN0_MCLK]);
+	clk_prepare_enable(clks[MPC512x_CLK_MSCAN1_MCLK]);
+	clk_prepare_enable(clks[MPC512x_CLK_MSCAN2_MCLK]);
+	clk_prepare_enable(clks[MPC512x_CLK_MSCAN3_MCLK]);
+}
+
+/*
+ * registers the set of public clocks (those listed in the dt-bindings/
+ * header file) for OF lookups, keeps the intermediates private to us
+ */
+static void mpc5121_clk_register_of_provider(struct device_node *np)
+{
+	clk_data.clks = clks;
+	clk_data.clk_num = MPC512x_CLK_LAST_PUBLIC + 1;	/* _not_ ARRAY_SIZE() */
+	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
+}
+
+int __init mpc5121_clk_init(void)
+{
+	struct device_node *clk_np;
+	int busfreq;
+
+	/* map the clock control registers */
+	clk_np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-clock");
+	if (!clk_np)
+		return -ENODEV;
+	clkregs = of_iomap(clk_np, 0);
+	WARN_ON(!clkregs);
+
+	/* invalidate all not yet registered clock slots */
+	mpc512x_clk_preset_data();
+
+	/*
+	 * have the device tree scanned for "fixed-clock" nodes (which
+	 * includes the oscillator node if the board's DT provides one)
+	 */
+	of_clk_init(NULL);
+
+	/*
+	 * add a dummy clock for those situations where a clock spec is
+	 * required yet no real clock is involved
+	 */
+	clks[MPC512x_CLK_DUMMY] = mpc512x_clk_fixed("dummy", 0);
+
+	/*
+	 * have all the real nodes in the clock tree populated from REF
+	 * down to all leaves, either starting from the OSC node or from
+	 * a REF root that was created from the IPS bus clock input
+	 */
+	busfreq = get_freq_from_dt("bus-frequency");
+	mpc512x_clk_setup_clock_tree(busfreq);
+
+	/* register as an OF clock provider */
+	mpc5121_clk_register_of_provider(clk_np);
+
+	return 0;
+}
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index c4f7799..7f8fc64 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -497,6 +497,20 @@ static inline const char *of_clk_get_parent_name(struct device_node *np,
  * for improved portability across platforms
  */
 
+#if IS_ENABLED(CONFIG_PPC)
+
+static inline u32 clk_readl(u32 __iomem *reg)
+{
+	return ioread32be(reg);
+}
+
+static inline void clk_writel(u32 val, u32 __iomem *reg)
+{
+	iowrite32be(val, reg);
+}
+
+#else	/* platform dependent I/O accessors */
+
 static inline u32 clk_readl(u32 __iomem *reg)
 {
 	return readl(reg);
@@ -507,5 +521,7 @@ static inline void clk_writel(u32 val, u32 __iomem *reg)
 	writel(val, reg);
 }
 
+#endif	/* platform dependent I/O accessors */
+
 #endif /* CONFIG_COMMON_CLK */
 #endif /* CLK_PROVIDER_H */
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 15 14:47:34 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:34 +0200
Subject: [PATCH v1 05/24] clk: wrap I/O access for improved portability
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373914074-20889-6-git-send-email-gsi@denx.de>

the common clock drivers were motivated/initiated by ARM development
and apparently assume little endian peripherals

wrap register/peripherals access in the common code (div, gate, mux)
in preparation of adding COMMON_CLK support for other platforms

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/clk/clk-divider.c    |    6 +++---
 drivers/clk/clk-gate.c       |    6 +++---
 drivers/clk/clk-mux.c        |    6 +++---
 include/linux/clk-provider.h |   17 +++++++++++++++++
 4 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 6d55eb2..2c07061 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -104,7 +104,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
 	struct clk_divider *divider = to_clk_divider(hw);
 	unsigned int div, val;
 
-	val = readl(divider->reg) >> divider->shift;
+	val = clk_readl(divider->reg) >> divider->shift;
 	val &= div_mask(divider);
 
 	div = _get_div(divider, val);
@@ -230,11 +230,11 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
 	if (divider->flags & CLK_DIVIDER_HIWORD_MASK) {
 		val = div_mask(divider) << (divider->shift + 16);
 	} else {
-		val = readl(divider->reg);
+		val = clk_readl(divider->reg);
 		val &= ~(div_mask(divider) << divider->shift);
 	}
 	val |= value << divider->shift;
-	writel(val, divider->reg);
+	clk_writel(val, divider->reg);
 
 	if (divider->lock)
 		spin_unlock_irqrestore(divider->lock, flags);
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 790306e..b7fbd96 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -58,7 +58,7 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable)
 		if (set)
 			reg |= BIT(gate->bit_idx);
 	} else {
-		reg = readl(gate->reg);
+		reg = clk_readl(gate->reg);
 
 		if (set)
 			reg |= BIT(gate->bit_idx);
@@ -66,7 +66,7 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable)
 			reg &= ~BIT(gate->bit_idx);
 	}
 
-	writel(reg, gate->reg);
+	clk_writel(reg, gate->reg);
 
 	if (gate->lock)
 		spin_unlock_irqrestore(gate->lock, flags);
@@ -89,7 +89,7 @@ static int clk_gate_is_enabled(struct clk_hw *hw)
 	u32 reg;
 	struct clk_gate *gate = to_clk_gate(hw);
 
-	reg = readl(gate->reg);
+	reg = clk_readl(gate->reg);
 
 	/* if a set bit disables this clk, flip it before masking */
 	if (gate->flags & CLK_GATE_SET_TO_DISABLE)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 614444c..02ef506 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -42,7 +42,7 @@ static u8 clk_mux_get_parent(struct clk_hw *hw)
 	 * OTOH, pmd_trace_clk_mux_ck uses a separate bit for each clock, so
 	 * val = 0x4 really means "bit 2, index starts at bit 0"
 	 */
-	val = readl(mux->reg) >> mux->shift;
+	val = clk_readl(mux->reg) >> mux->shift;
 	val &= mux->mask;
 
 	if (mux->table) {
@@ -89,11 +89,11 @@ static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
 	if (mux->flags & CLK_MUX_HIWORD_MASK) {
 		val = mux->mask << (mux->shift + 16);
 	} else {
-		val = readl(mux->reg);
+		val = clk_readl(mux->reg);
 		val &= ~(mux->mask << mux->shift);
 	}
 	val |= index << mux->shift;
-	writel(val, mux->reg);
+	clk_writel(val, mux->reg);
 
 	if (mux->lock)
 		spin_unlock_irqrestore(mux->lock, flags);
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1ec14a7..c4f7799 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -12,6 +12,7 @@
 #define __LINUX_CLK_PROVIDER_H
 
 #include <linux/clk.h>
+#include <linux/io.h>
 
 #ifdef CONFIG_COMMON_CLK
 
@@ -490,5 +491,21 @@ static inline const char *of_clk_get_parent_name(struct device_node *np,
 #define of_clk_init(matches) \
 	{ while (0); }
 #endif /* CONFIG_OF */
+
+/*
+ * wrap access to peripherals in accessor routines
+ * for improved portability across platforms
+ */
+
+static inline u32 clk_readl(u32 __iomem *reg)
+{
+	return readl(reg);
+}
+
+static inline void clk_writel(u32 val, u32 __iomem *reg)
+{
+	writel(val, reg);
+}
+
 #endif /* CONFIG_COMMON_CLK */
 #endif /* CLK_PROVIDER_H */
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 15 14:47:35 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:35 +0200
Subject: [PATCH v1 06/24] dts: mpc512x: prepare for preprocessor support
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373914074-20889-7-git-send-email-gsi@denx.de>

prepare C preprocessor support when processing MPC512x DTS files
- switch from DTS syntax to CPP syntax for include specs
- create a symlink such that DTS processing can reference includes

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/boot/dts/ac14xx.dts          |    2 +-
 arch/powerpc/boot/dts/include/dt-bindings |    1 +
 arch/powerpc/boot/dts/mpc5121ads.dts      |    2 +-
 arch/powerpc/boot/dts/pdm360ng.dts        |    2 +-
 4 files changed, 4 insertions(+), 3 deletions(-)
 create mode 120000 arch/powerpc/boot/dts/include/dt-bindings

diff --git a/arch/powerpc/boot/dts/ac14xx.dts b/arch/powerpc/boot/dts/ac14xx.dts
index a27a460..a543c40 100644
--- a/arch/powerpc/boot/dts/ac14xx.dts
+++ b/arch/powerpc/boot/dts/ac14xx.dts
@@ -10,7 +10,7 @@
  */
 
 
-/include/ "mpc5121.dtsi"
+#include <mpc5121.dtsi>
 
 / {
 	model = "ac14xx";
diff --git a/arch/powerpc/boot/dts/include/dt-bindings b/arch/powerpc/boot/dts/include/dt-bindings
new file mode 120000
index 0000000..08c00e4
--- /dev/null
+++ b/arch/powerpc/boot/dts/include/dt-bindings
@@ -0,0 +1 @@
+../../../../../include/dt-bindings
\ No newline at end of file
diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts b/arch/powerpc/boot/dts/mpc5121ads.dts
index 7d3cb79..c228a0a 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -9,7 +9,7 @@
  * option) any later version.
  */
 
-/include/ "mpc5121.dtsi"
+#include <mpc5121.dtsi>
 
 / {
 	model = "mpc5121ads";
diff --git a/arch/powerpc/boot/dts/pdm360ng.dts b/arch/powerpc/boot/dts/pdm360ng.dts
index 7433740..871c16d 100644
--- a/arch/powerpc/boot/dts/pdm360ng.dts
+++ b/arch/powerpc/boot/dts/pdm360ng.dts
@@ -13,7 +13,7 @@
  * option) any later version.
  */
 
-/include/ "mpc5121.dtsi"
+#include <mpc5121.dtsi>
 
 / {
 	model = "pdm360ng";
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 15 14:47:36 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:36 +0200
Subject: [PATCH v1 07/24] dts: mpc512x: introduce dt-bindings/clock/ header
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373914074-20889-8-git-send-email-gsi@denx.de>

introduce a dt-bindings/ header file for MPC512x clocks,
providing symbolic identifiers for those SoC clocks which
clients will reference from their device tree nodes

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 include/dt-bindings/clock/mpc512x-clock.h |   59 +++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)
 create mode 100644 include/dt-bindings/clock/mpc512x-clock.h

diff --git a/include/dt-bindings/clock/mpc512x-clock.h b/include/dt-bindings/clock/mpc512x-clock.h
new file mode 100644
index 0000000..46c560e
--- /dev/null
+++ b/include/dt-bindings/clock/mpc512x-clock.h
@@ -0,0 +1,59 @@
+/*
+ * This header provides constants for MPC512x clock specs in DT bindings.
+ *
+ * Unfortunately the clock number declaration cannot be an enum but
+ * needs to be a list of #define directives since when referenced from
+ * within DTS files they need to get resolved "at compile time".
+ */
+
+#ifndef _DT_BINDINGS_CLOCK_MPC512x_CLOCK_H
+#define _DT_BINDINGS_CLOCK_MPC512x_CLOCK_H
+
+#define MPC512x_CLK_DUMMY		0
+#define MPC512x_CLK_REF			1
+#define MPC512x_CLK_SYS			2
+#define MPC512x_CLK_DIU			3
+#define MPC512x_CLK_VIU			4
+#define MPC512x_CLK_CSB			5
+#define MPC512x_CLK_E300		6
+#define MPC512x_CLK_IPS			7
+#define MPC512x_CLK_FEC			8
+#define MPC512x_CLK_SATA		9
+#define MPC512x_CLK_PATA		10
+#define MPC512x_CLK_NFC			11
+#define MPC512x_CLK_LPC			12
+#define MPC512x_CLK_MBX_BUS		13
+#define MPC512x_CLK_MBX			14
+#define MPC512x_CLK_MBX_3D		15
+#define MPC512x_CLK_AXE			16
+#define MPC512x_CLK_USB1		17
+#define MPC512x_CLK_USB2		18
+#define MPC512x_CLK_I2C			19
+#define MPC512x_CLK_MSCAN0_MCLK		20
+#define MPC512x_CLK_MSCAN1_MCLK		21
+#define MPC512x_CLK_MSCAN2_MCLK		22
+#define MPC512x_CLK_MSCAN3_MCLK		23
+#define MPC512x_CLK_SDHC		24
+#define MPC512x_CLK_PCI			25
+#define MPC512x_CLK_PSC_MCLK_IN		26
+#define MPC512x_CLK_SPDIF_TX		27
+#define MPC512x_CLK_SPDIF_RX		28
+#define MPC512x_CLK_SPDIF_MCLK		29
+#define MPC512x_CLK_AC97		30
+#define MPC512x_CLK_PSC0_MCLK		31
+#define MPC512x_CLK_PSC1_MCLK		32
+#define MPC512x_CLK_PSC2_MCLK		33
+#define MPC512x_CLK_PSC3_MCLK		34
+#define MPC512x_CLK_PSC4_MCLK		35
+#define MPC512x_CLK_PSC5_MCLK		36
+#define MPC512x_CLK_PSC6_MCLK		37
+#define MPC512x_CLK_PSC7_MCLK		38
+#define MPC512x_CLK_PSC8_MCLK		39
+#define MPC512x_CLK_PSC9_MCLK		40
+#define MPC512x_CLK_PSC10_MCLK		41
+#define MPC512x_CLK_PSC11_MCLK		42
+#define MPC512x_CLK_PSC_FIFO		43
+
+#define MPC512x_CLK_LAST_PUBLIC		43
+
+#endif
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 15 14:47:37 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:37 +0200
Subject: [PATCH v1 08/24] dts: mpc512x: add clock related device tree specs
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373914074-20889-9-git-send-email-gsi@denx.de>

this addresses the clock driver aka provider's side of clocks
- prepare for future '<&clks ID>' phandle references for device tree
  based clock lookup in client drivers
- introduce a 'clocks' subtree with an 'osc' node for the crystal
  or oscillator SoC input (fixed frequency)
- provide default values with 33MHz oscillator frequency in the
  common include (the 66MHz IPS bus already was there), add
  override values for the ifm AC14xx board which deviates from
  the reference design (25MHz xtal, 80MHz IPS bus)

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/boot/dts/ac14xx.dts   |    7 +++++++
 arch/powerpc/boot/dts/mpc5121.dtsi |   15 ++++++++++++++-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/ac14xx.dts b/arch/powerpc/boot/dts/ac14xx.dts
index a543c40..a1b8837 100644
--- a/arch/powerpc/boot/dts/ac14xx.dts
+++ b/arch/powerpc/boot/dts/ac14xx.dts
@@ -139,7 +139,14 @@
 		};
 	};
 
+	clocks {
+		osc {
+			clock-frequency = <25000000>;
+		};
+	};
+
 	soc at 80000000 {
+		bus-frequency = <80000000>;	/* 80 MHz ips bus */
 
 		clock at f00 {
 			compatible = "fsl,mpc5121rev2-clock", "fsl,mpc5121-clock";
diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi b/arch/powerpc/boot/dts/mpc5121.dtsi
index bd14c00..8f4cba0 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -9,6 +9,8 @@
  * option) any later version.
  */
 
+#include <dt-bindings/clock/mpc512x-clock.h>
+
 /dts-v1/;
 
 / {
@@ -73,6 +75,16 @@
 		ranges = <0x0 0x0 0xfc000000 0x04000000>;
 	};
 
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		osc {
+			compatible = "fsl,mpc512x-osc", "fixed-clock";
+			clock-frequency = <33000000>;
+		};
+	};
+
 	soc at 80000000 {
 		compatible = "fsl,mpc5121-immr";
 		#address-cells = <1>;
@@ -118,9 +130,10 @@
 		};
 
 		/* Clock control */
-		clock at f00 {
+		clks: clock at f00 {
 			compatible = "fsl,mpc5121-clock";
 			reg = <0xf00 0x100>;
+			#clock-cells = <1>;
 		};
 
 		/* Power Management Controller */
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 15 14:47:40 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:40 +0200
Subject: [PATCH v1 11/24] net: can: mscan: add a comment on reg to idx mapping
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373914074-20889-12-git-send-email-gsi@denx.de>

add a comment about the magic of deriving an MSCAN component index
from the peripheral's physical address / register offset

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/net/can/mscan/mpc5xxx_can.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index 5b0ee8e..bc422ba 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -148,7 +148,10 @@ static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 		goto exit_put;
 	}
 
-	/* Determine the MSCAN device index from the physical address */
+	/* Determine the MSCAN device index from the peripheral's
+	 * physical address. Register address offsets against the
+	 * IMMR base are:  0x1300, 0x1380, 0x2300, 0x2380
+	 */
 	pval = of_get_property(ofdev->dev.of_node, "reg", &plen);
 	BUG_ON(!pval || plen < sizeof(*pval));
 	clockidx = (*pval & 0x80) ? 1 : 0;
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 15 14:47:42 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:42 +0200
Subject: [PATCH v1 13/24] spi: mpc512x: OF clock lookup, use the 'mclk' name
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373914074-20889-14-git-send-email-gsi@denx.de>

after PSC related clock specifiers were added to the device tree,
the former 'psc%d_mclk' isn't needed any longer to lookup clock items

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/spi/spi-mpc512x-psc.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
index 76b20ea..3e30e52 100644
--- a/drivers/spi/spi-mpc512x-psc.c
+++ b/drivers/spi/spi-mpc512x-psc.c
@@ -388,13 +388,11 @@ static int mpc512x_psc_spi_port_config(struct spi_master *master,
 	struct mpc512x_psc_fifo __iomem *fifo = mps->fifo;
 	struct clk *spiclk;
 	int ret = 0;
-	char name[32];
 	u32 sicr;
 	u32 ccr;
 	u16 bclkdiv;
 
-	sprintf(name, "psc%d_mclk", master->bus_num);
-	spiclk = clk_get(&master->dev, name);
+	spiclk = clk_get(&master->dev, "mclk");
 	clk_prepare_enable(spiclk);
 	mps->mclk = clk_get_rate(spiclk);
 	clk_put(spiclk);
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 15 14:47:41 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:41 +0200
Subject: [PATCH v1 12/24] net: can: mscan: make mpc512x code use common clock
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373914074-20889-13-git-send-email-gsi@denx.de>

extend the mscan(4) driver with alternative support for the COMMON_CLK
approach which is an option in the MPC512x platform, keep the existing
clock support implementation in place since the driver is shared with
other MPC5xxx SoCs which don't have common clock support

one byproduct of this change is that the CAN driver no longer needs to
access the SoC's clock control registers, which shall be the domain of
the platform's clock driver

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/net/can/mscan/mpc5xxx_can.c |  139 +++++++++++++++++++++++++++++++++++
 1 file changed, 139 insertions(+)

diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index bc422ba..dd26ab6 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -108,6 +108,143 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
 #endif /* CONFIG_PPC_MPC52xx */
 
 #ifdef CONFIG_PPC_MPC512x
+
+#if IS_ENABLED(CONFIG_COMMON_CLK)
+
+static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
+				 const char *clock_source, int *mscan_clksrc)
+{
+	struct device_node *np;
+	u32 clockdiv;
+	enum {
+		CLK_FROM_AUTO,
+		CLK_FROM_IPS,
+		CLK_FROM_SYS,
+		CLK_FROM_REF,
+	} clk_from;
+	struct clk *clk_in, *clk_can;
+	unsigned long freq_calc;
+
+	/* the caller passed in the clock source spec that was read from
+	 * the device tree, get the optional clock divider as well
+	 */
+	np = ofdev->dev.of_node;
+	clockdiv = 1;
+	of_property_read_u32(np, "fsl,mscan-clock-divider", &clockdiv);
+	dev_dbg(&ofdev->dev, "device tree specs: clk src[%s] div[%d]\n",
+		clock_source ? clock_source : "<NULL>", clockdiv);
+
+	/* when clock-source is 'ip', the CANCTL1[CLKSRC] bit needs to
+	 * get set, and the 'ips' clock is the input to the MSCAN
+	 * component
+	 *
+	 * for clock-source values of 'ref' or 'sys' the CANCTL1[CLKSRC]
+	 * bit needs to get cleared, an optional clock-divider may have
+	 * been specified (the default value is 1), the appropriate
+	 * MSCAN related MCLK is the input to the MSCAN component
+	 *
+	 * in the absence of a clock-source spec, first an optimal clock
+	 * gets determined based on the 'sys' clock, if that fails the
+	 * 'ref' clock is used
+	 */
+	clk_from = CLK_FROM_AUTO;
+	if (clock_source) {
+		/* interpret the device tree's spec for the clock source */
+		if (!strcmp(clock_source, "ip"))
+			clk_from = CLK_FROM_IPS;
+		else if (!strcmp(clock_source, "sys"))
+			clk_from = CLK_FROM_SYS;
+		else if (!strcmp(clock_source, "ref"))
+			clk_from = CLK_FROM_REF;
+		else
+			goto err_invalid;
+		dev_dbg(&ofdev->dev, "got a clk source spec[%d]\n", clk_from);
+	}
+	if (clk_from == CLK_FROM_AUTO) {
+		/* no spec so far, try the 'sys' clock; round to the
+		 * next MHz and see if we can get a multiple of 16MHz
+		 */
+		dev_dbg(&ofdev->dev, "no clk source spec, trying SYS\n");
+		clk_in = clk_get(&ofdev->dev, "sys");
+		if (IS_ERR(clk_in))
+			goto err_notavail;
+		freq_calc = clk_get_rate(clk_in);
+		freq_calc +=  499999;
+		freq_calc /= 1000000;
+		freq_calc *= 1000000;
+		if ((freq_calc % 16000000) == 0) {
+			clk_from = CLK_FROM_SYS;
+			clockdiv = freq_calc / 16000000;
+			dev_dbg(&ofdev->dev,
+				"clk fit, sys[%lu] div[%d] freq[%lu]\n",
+				freq_calc, clockdiv, freq_calc / clockdiv);
+		}
+	}
+	if (clk_from == CLK_FROM_AUTO) {
+		/* no spec so far, use the 'ref' clock */
+		dev_dbg(&ofdev->dev, "no clk source spec, trying REF\n");
+		clk_in = clk_get(&ofdev->dev, "ref");
+		if (IS_ERR(clk_in))
+			goto err_notavail;
+		clk_from = CLK_FROM_REF;
+		freq_calc = clk_get_rate(clk_in);
+		dev_dbg(&ofdev->dev,
+			"clk fit, ref[%lu] (no div) freq[%lu]\n",
+			freq_calc, freq_calc);
+	}
+
+	/* select IPS or MCLK as the MSCAN input (returned to the caller),
+	 * setup the MCLK mux source and rate if applicable, apply the
+	 * optionally specified or derived above divider, and determine
+	 * the actual resulting clock rate to return to the caller
+	 */
+	switch (clk_from) {
+	case CLK_FROM_IPS:
+		clk_can = clk_get(&ofdev->dev, "ips");
+		if (IS_ERR(clk_can))
+			goto err_notavail;
+		clk_prepare_enable(clk_can);
+		freq_calc = clk_get_rate(clk_can);
+		*mscan_clksrc = MSCAN_CLKSRC_IPS;
+		dev_dbg(&ofdev->dev, "clk from IPS, clksrc[%d] freq[%lu]\n",
+			*mscan_clksrc, freq_calc);
+		break;
+	case CLK_FROM_SYS:
+	case CLK_FROM_REF:
+		clk_can = clk_get(&ofdev->dev, "mclk");
+		if (IS_ERR(clk_can))
+			goto err_notavail;
+		clk_prepare_enable(clk_can);
+		if (clk_from == CLK_FROM_SYS)
+			clk_in = clk_get(&ofdev->dev, "sys");
+		if (clk_from == CLK_FROM_REF)
+			clk_in = clk_get(&ofdev->dev, "ref");
+		if (IS_ERR(clk_in))
+			goto err_notavail;
+		clk_set_parent(clk_can, clk_in);
+		freq_calc = clk_get_rate(clk_in);
+		freq_calc /= clockdiv;
+		clk_set_rate(clk_can, freq_calc);
+		freq_calc = clk_get_rate(clk_can);
+		*mscan_clksrc = MSCAN_CLKSRC_BUS;
+		dev_dbg(&ofdev->dev, "clk from MCLK, clksrc[%d] freq[%lu]\n",
+			*mscan_clksrc, freq_calc);
+		break;
+	default:
+		goto err_invalid;
+	}
+
+	return freq_calc;
+
+err_invalid:
+	dev_err(&ofdev->dev, "invalid clock source specification\n");
+	return 0;
+
+err_notavail:
+	dev_err(&ofdev->dev, "cannot acquire or setup clock source\n");
+	return 0;
+}
+#else	/* COMMON_CLK */
 struct mpc512x_clockctl {
 	u32 spmr;		/* System PLL Mode Reg */
 	u32 sccr[2];		/* System Clk Ctrl Reg 1 & 2 */
@@ -238,6 +375,8 @@ exit_put:
 	of_node_put(np_clock);
 	return freq;
 }
+#endif	/* COMMON_CLK */
+
 #else /* !CONFIG_PPC_MPC512x */
 static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 				 const char *clock_name, int *mscan_clksrc)
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 15 14:47:43 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 20:47:43 +0200
Subject: [PATCH v1 14/24] powerpc/mpc512x: improve DIU related clock setup
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373914074-20889-15-git-send-email-gsi@denx.de>

adapt the DIU clock initialization to the COMMON_CLK approach: device
tree based clock lookup, prepare and unprepare for clocks, work with
frequencies not dividers, call the appropriate clk_*() routines and
don't access CCM registers, remove the pre-enable workaround in the
platform's clock driver

the "best clock" determination now completely relies on the platform's
clock driver to pick a frequency close to what the caller requests, and
merely checks whether the desired frequency was met (is acceptable since
it meets the tolerance of the monitor) -- this approach shall succeed
upon first try in the usual case, will test a few less desirable yet
acceptable frequencies in edge cases, and will fallback to "best effort"
if none of the previously tried frequencies pass the test

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |    1 -
 arch/powerpc/platforms/512x/mpc512x_shared.c  |  165 +++++++++++++------------
 2 files changed, 88 insertions(+), 78 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index 218f55b..f31f895 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -705,7 +705,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	/* some are not yet acquired by their respective drivers */
 	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
 	clk_prepare_enable(clks[MPC512x_CLK_FEC]);	/* network, NFS */
-	clk_prepare_enable(clks[MPC512x_CLK_DIU]);	/* display */
 	clk_prepare_enable(clks[MPC512x_CLK_I2C]);
 	/*
 	 * some have their individual clock subtree with separate clock
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
index a82a41b..3381eea 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -12,6 +12,7 @@
  * (at your option) any later version.
  */
 
+#include <linux/clk.h>
 #include <linux/kernel.h>
 #include <linux/io.h>
 #include <linux/irq.h>
@@ -70,98 +71,108 @@ struct fsl_diu_shared_fb {
 	bool		in_use;
 };
 
-#define DIU_DIV_MASK	0x000000ff
+/* receives a pixel clock spec in pico seconds, adjusts the DIU clock rate */
 void mpc512x_set_pixel_clock(unsigned int pixclock)
 {
-	unsigned long bestval, bestfreq, speed, busfreq;
-	unsigned long minpixclock, maxpixclock, pixval;
-	struct mpc512x_ccm __iomem *ccm;
 	struct device_node *np;
-	u32 temp;
-	long err;
-	int i;
+	struct clk *clk_diu;
+	unsigned long epsilon, minpixclock, maxpixclock;
+	unsigned long offset, want, got, delta;
 
-	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-clock");
+	/* lookup and enable the DIU clock */
+	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-diu");
 	if (!np) {
-		pr_err("Can't find clock control module.\n");
+		pr_err("Could not find DIU device tree node.\n");
 		return;
 	}
-
-	ccm = of_iomap(np, 0);
+	clk_diu = of_clk_get_by_name(np, "per");
 	of_node_put(np);
-	if (!ccm) {
-		pr_err("Can't map clock control module reg.\n");
+	if (IS_ERR(clk_diu)) {
+		pr_err("Could not lookup DIU clock.\n");
 		return;
 	}
-
-	np = of_find_node_by_type(NULL, "cpu");
-	if (np) {
-		const unsigned int *prop =
-			of_get_property(np, "bus-frequency", NULL);
-
-		of_node_put(np);
-		if (prop) {
-			busfreq = *prop;
-		} else {
-			pr_err("Can't get bus-frequency property\n");
-			return;
-		}
-	} else {
-		pr_err("Can't find 'cpu' node.\n");
+	if (clk_prepare_enable(clk_diu)) {
+		pr_err("Could not enable DIU clock.\n");
 		return;
 	}
 
-	/* Pixel Clock configuration */
-	pr_debug("DIU: Bus Frequency = %lu\n", busfreq);
-	speed = busfreq * 4; /* DIU_DIV ratio is 4 * CSB_CLK / DIU_CLK */
-
-	/* Calculate the pixel clock with the smallest error */
-	/* calculate the following in steps to avoid overflow */
-	pr_debug("DIU pixclock in ps - %d\n", pixclock);
-	temp = (1000000000 / pixclock) * 1000;
-	pixclock = temp;
-	pr_debug("DIU pixclock freq - %u\n", pixclock);
-
-	temp = temp / 20; /* pixclock * 0.05 */
-	pr_debug("deviation = %d\n", temp);
-	minpixclock = pixclock - temp;
-	maxpixclock = pixclock + temp;
-	pr_debug("DIU minpixclock - %lu\n", minpixclock);
-	pr_debug("DIU maxpixclock - %lu\n", maxpixclock);
-	pixval = speed/pixclock;
-	pr_debug("DIU pixval = %lu\n", pixval);
-
-	err = LONG_MAX;
-	bestval = pixval;
-	pr_debug("DIU bestval = %lu\n", bestval);
-
-	bestfreq = 0;
-	for (i = -1; i <= 1; i++) {
-		temp = speed / (pixval+i);
-		pr_debug("DIU test pixval i=%d, pixval=%lu, temp freq. = %u\n",
-			i, pixval, temp);
-		if ((temp < minpixclock) || (temp > maxpixclock))
-			pr_debug("DIU exceeds monitor range (%lu to %lu)\n",
-				minpixclock, maxpixclock);
-		else if (abs(temp - pixclock) < err) {
-			pr_debug("Entered the else if block %d\n", i);
-			err = abs(temp - pixclock);
-			bestval = pixval + i;
-			bestfreq = temp;
-		}
+	/*
+	 * convert the picoseconds spec into the desired clock rate,
+	 * determine the acceptable clock range for the monitor (+/- 5%),
+	 * do the calculation in steps to avoid integer overflow
+	 */
+	pr_debug("DIU pixclock in ps - %u\n", pixclock);
+	pixclock = (1000000000 / pixclock) * 1000;
+	pr_debug("DIU pixclock freq  - %u\n", pixclock);
+	epsilon = pixclock / 20; /* pixclock * 0.05 */
+	pr_debug("DIU deviation      - %lu\n", epsilon);
+	minpixclock = pixclock - epsilon;
+	maxpixclock = pixclock + epsilon;
+	pr_debug("DIU minpixclock    - %lu\n", minpixclock);
+	pr_debug("DIU maxpixclock    - %lu\n", maxpixclock);
+
+	/*
+	 * check whether the DIU supports the desired pixel clock
+	 *
+	 * - simply request the desired clock and see what the
+	 *   platform's clock driver will make of it, assuming that it
+	 *   will setup the best approximation of the requested value
+	 * - try other candidate frequencies in the order of decreasing
+	 *   preference (i.e. with increasing distance from the desired
+	 *   pixel clock, and checking the lower frequency before the
+	 *   higher frequency to not overload the hardware) until the
+	 *   first match is found -- any potential subsequent match
+	 *   would only be as good as the former match or typically
+	 *   would be less preferrable
+	 *
+	 * the offset increment of pixelclock divided by 64 is an
+	 * arbitrary choice -- it's simple to calculate, in the typical
+	 * case we expect the first check to succeed already, in the
+	 * worst case seven frequencies get tested (the exact center and
+	 * three more values each to the left and to the right) before
+	 * the 5% tolerance window is exceeded, resulting in fast enough
+	 * execution yet high enough probability of finding a suitable
+	 * value, while the error rate will be in the order of single
+	 * percents
+	 */
+	for (offset = 0; offset <= epsilon; offset += pixclock / 64) {
+		want = pixclock - offset;
+		pr_debug("DIU checking clock - %lu\n", want);
+		clk_set_rate(clk_diu, want);
+		got = clk_get_rate(clk_diu);
+		delta = abs(pixclock - got);
+		if (delta < epsilon)
+			break;
+		if (!offset)
+			continue;
+		want = pixclock + offset;
+		pr_debug("DIU checking clock - %lu\n", want);
+		clk_set_rate(clk_diu, want);
+		got = clk_get_rate(clk_diu);
+		delta = abs(pixclock - got);
+		if (delta < epsilon)
+			break;
 	}
+	if (offset <= epsilon) {
+		pr_debug("DIU clock accepted - %lu\n", want);
+		pr_debug("DIU pixclock want %u, got %lu, delta %lu, eps %lu\n",
+			 pixclock, got, delta, epsilon);
+		return;
+	}
+	pr_warn("DIU pixclock auto search unsuccessful\n");
 
-	pr_debug("DIU chose = %lx\n", bestval);
-	pr_debug("DIU error = %ld\n NomPixClk ", err);
-	pr_debug("DIU: Best Freq = %lx\n", bestfreq);
-	/* Modify DIU_DIV in CCM SCFR1 */
-	temp = in_be32(&ccm->scfr1);
-	pr_debug("DIU: Current value of SCFR1: 0x%08x\n", temp);
-	temp &= ~DIU_DIV_MASK;
-	temp |= (bestval & DIU_DIV_MASK);
-	out_be32(&ccm->scfr1, temp);
-	pr_debug("DIU: Modified value of SCFR1: 0x%08x\n", temp);
-	iounmap(ccm);
+	/*
+	 * what is the most appropriate action to take when the search
+	 * for an available pixel clock which is acceptable to the
+	 * monitor has failed?  disable the DIU (clock) or just provide
+	 * a "best effort"?  we go with the latter
+	 */
+	pr_warn("DIU pixclock best effort fallback (backend's choice)\n");
+	clk_set_rate(clk_diu, pixclock);
+	got = clk_get_rate(clk_diu);
+	delta = abs(pixclock - got);
+	pr_debug("DIU pixclock want %u, got %lu, delta %lu, eps %lu\n",
+		 pixclock, got, delta, epsilon);
 }
 
 enum fsl_diu_monitor_port
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Jul 15 14:50:46 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 15 Jul 2013 13:50:46 -0500
Subject: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu
 nodes bindings updates
In-Reply-To: <20130715093406.GC15904@e102568-lin.cambridge.arm.com>
References: <1368804061-4421-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1368804061-4421-4-git-send-email-lorenzo.pieralisi@arm.com>
 <CAL_JsqLANi5UoVyRMsa6XoQ+_KnmTQDfTz++shEh-dZ3FQGZaQ@mail.gmail.com>
 <20130715093406.GC15904@e102568-lin.cambridge.arm.com>
Message-ID: <51E44486.7050806@gmail.com>

On 07/15/2013 04:34 AM, Lorenzo Pieralisi wrote:
> On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote:
>> On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi
>> <lorenzo.pieralisi at arm.com> wrote:
>>> In order to extend the current cpu nodes bindings to newer CPUs
>>> inclusive of AArch64 and to update support for older ARM CPUs this
>>> patch updates device tree documentation for the cpu nodes bindings.
>>
>> Sorry for the long delay on this, but I'm still not happy with the binding here.
> 
> I had to ask Russell again to drop the bindings patches from the patch
> system, and this is not acceptable since two months have passed and the
> entire series was reviewed, acked and partially merged. I will review
> these bindings again but I would like to understand who should give the final
> go ahead to get these patches queued for upstreaming, I can't continue
> updating this stuff forever.

Most of my comments are for 64-bit. So don't blame me that it had to be
reverted. I said up front I was concerned about this change breaking
things and it appears it did. New kernels must not require a new DT.

But yes, this should have been reviewed more quickly. We're working on a
plan to help address DT binding reviews. We have not enforced that Grant
and I must ack all bindings, but in this case you certainly need mine
since I have reviewed it and if you want to me to pull it.

>>> Main changes:
>>>     - adds 64-bit bindings
>>>     - define usage of #address-cells
>>>     - define 32/64 dts compatibility settings
>>>     - defines behaviour on pre and post v7 uniprocessor systems
>>>     - adds ARM 11MPcore specific reg property definition
>>>
>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/cpus.txt | 459 ++++++++++++++++++++++---
>>>  1 file changed, 412 insertions(+), 47 deletions(-)
>>
>> [snip]
>>
>>> +                       # On ARM v8 64-bit systems, where the reg property
>>> +                         size can be 1 or 2 cells (as defined by cpus node's
>>> +                         #address-cells property), this property is
>>> +                         required and matches:
>>> +
>>> +                         - On systems running the OS in AArch32:
>>
>> The DTS cannot change based on 32-bit or 64-bit OS.
> 
> "On systems running the OS in AArch32" implies a dependency on the
> HW execution state. Since the DT is used to configure OSs I thought that
> could be a valid sentence. Unfortunately this stuff is not C, so I
> reiterate my point above, before changing it I would like to understand
> who should say the wording is ok otherwise we could argue forever.

It does configure the OS, but not for 32 vs. 64 bit. That is more of a
problem for the bootloader to know which mode to boot in and covered
under something like Documentation/arm/Booting. Booting ARM vs. Thumb
mode would be similar situation.

Think about how your PC boots and add to that having a DTB as part of
the firmware shipped with your PC. Then the end user can install a
32-bit or 64-bit OS on it. That is the usecase that needs to be
supported and having different DTB for 32 and 64 bit is totally broken
and doesn't even help solve that problem.

>>> +
>>> +       - cpu-release-addr
>>> +               Usage: required for systems that have an "enable-method"
>>> +                      property value of "spin-table".
>>> +               Value type: <prop-encoded-array>
>>> +               Definition:
>>> +                       # On ARM v8 64-bit systems must be a two cell
>>> +                         property identifying a 64-bit zero-initialised
>>> +                         memory location.
>>
>> As I mentioned previously, isn't some wake-up method needed? Most
>> systems will be in wfi or wfe rather than continuously spinning.
> 
> Mmm...this can become a minefield, wfe, wfi, CPU in reset..this needs some
> thought.

Yes, it is today and standardizing this is a good thing. Which is what
PSCI does. So why are you adding the spintable at all? Are you trying to
set this as the standard for non-PSCI enabled platforms? Why not just
say v8 boot interface is PSCI. Sure, we'll probably have to deal with
other methods, but documenting something else here is not going to
prevent that problem. I don't think a simple spintable would even work
for any/most current platforms. I'd think we'd want to define something
that would work for existing platforms (chances are new platforms will
work like vendors' existing 32-bit platforms).

Rob



From swarren at wwwdotorg.org  Mon Jul 15 14:55:47 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 12:55:47 -0600
Subject: [PATCH] ARM: tegra: remove tegra114-pluto.dts
Message-ID: <1373914547-6075-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Early upstream work on Tegra114 was performed on the Pluto board.
However, it's not used any more, and the DT doesn't contain anything
beyond a serial port, so the file isn't useful either. Remove it.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/boot/dts/Makefile           |  3 +--
 arch/arm/boot/dts/tegra114-pluto.dts | 33 ---------------------------------
 2 files changed, 1 insertion(+), 35 deletions(-)
 delete mode 100644 arch/arm/boot/dts/tegra114-pluto.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 2cec2ff..4130237 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -228,8 +228,7 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
 	tegra30-beaver.dtb \
 	tegra30-cardhu-a02.dtb \
 	tegra30-cardhu-a04.dtb \
-	tegra114-dalmore.dtb \
-	tegra114-pluto.dtb
+	tegra114-dalmore.dtb
 dtb-$(CONFIG_ARCH_VERSATILE) += versatile-ab.dtb \
 	versatile-pb.dtb
 dtb-$(CONFIG_ARCH_U300) += ste-u300.dtb
diff --git a/arch/arm/boot/dts/tegra114-pluto.dts b/arch/arm/boot/dts/tegra114-pluto.dts
deleted file mode 100644
index d5f8d3e..0000000
--- a/arch/arm/boot/dts/tegra114-pluto.dts
+++ /dev/null
@@ -1,33 +0,0 @@
-/dts-v1/;
-
-#include "tegra114.dtsi"
-
-/ {
-	model = "NVIDIA Tegra114 Pluto evaluation board";
-	compatible = "nvidia,pluto", "nvidia,tegra114";
-
-	memory {
-		reg = <0x80000000 0x40000000>;
-	};
-
-	serial at 70006300 {
-		status = "okay";
-	};
-
-	pmc {
-		nvidia,invert-interrupt;
-	};
-
-	clocks {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		clk32k_in: clock {
-			compatible = "fixed-clock";
-			reg=<0>;
-			#clock-cells = <0>;
-			clock-frequency = <32768>;
-		};
-	};
-};
-- 
1.8.1.5



From gorcunov at gmail.com  Mon Jul 15 14:57:39 2013
From: gorcunov at gmail.com (Cyrill Gorcunov)
Date: Mon, 15 Jul 2013 22:57:39 +0400
Subject: [PATCH] arm: align shared memory unconditionally to the SHMLBA
 boundary
In-Reply-To: <20130715180846.GV24642@n2100.arm.linux.org.uk>
References: <1361254269-3444-1-git-send-email-alekskartashov@parallels.com>
 <20130715173238.GJ1730@moon>
 <20130715180846.GV24642@n2100.arm.linux.org.uk>
Message-ID: <20130715185739.GK1730@moon>

On Mon, Jul 15, 2013 at 07:08:46PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 15, 2013 at 09:32:38PM +0400, Cyrill Gorcunov wrote:
> > On Tue, Feb 19, 2013 at 10:11:09AM +0400, Alexander Kartashov wrote:
> > > Currently IPC SHM works in a strange way on ARM:
> > > the syscall sys_shmat() requires the argument shmaddr
> > > be SHMLBA-aligned (ARM has the macro __ARCH_FORCE_SHMLBA
> > > unconditionally defined) but allocates memory that
> > > isn't SHMLBA-aligned because the value of memory alignment
> > > depends on presense of certain cache aliases.
> > 
> > Hi guys, is there some conclusion on this patch? It has been sent
> > almost 5 months back ;)
> 
> It's pointless.  The alignment is only required for CPUs which have
> aliasing caches.  What the code does in mmap() is correct.  However,
> we can't dynamically select this in the SHM code.

Hi Russell, thanks a lot for reply! I must admit I'm not that familiar
with arm hw internals, but if the behaviour is correct than we've a
problem with checkpoint/restore procedure on arm platform :( As far
as I know Alexander pointed me that he find no other way of fixing
the problem except patching the kernel. Alexander, mind to remind
where exactly we're failing in c/r procedure, thus maybe arm guys
would help us to find a way to pass it by with some user-space
trick?


From sergei.shtylyov at cogentembedded.com  Mon Jul 15 14:59:20 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 15 Jul 2013 22:59:20 +0400
Subject: [PATCH V2 3/5] of: introduce of_parse_phandle_with_fixed_args
In-Reply-To: <1373913629-32179-3-git-send-email-swarren@wwwdotorg.org>
References: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
 <1373913629-32179-3-git-send-email-swarren@wwwdotorg.org>
Message-ID: <51E44688.3050805@cogentembedded.com>

On 07/15/2013 10:40 PM, Stephen Warren wrote:

> From: Stephen Warren <swarren at nvidia.com>

> This is identical to of_parse_phandle_with_args(), except that the
> number of argument cells is fixed, rather than being parsed out of the
> node referenced by each phandle.

> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> ---
>   drivers/of/base.c  | 67 ++++++++++++++++++++++++++++++++++++++++++++++--------
>   include/linux/of.h | 10 ++++++++
>   2 files changed, 68 insertions(+), 9 deletions(-)

> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 23e7073..ad799d9 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1106,7 +1106,8 @@ EXPORT_SYMBOL(of_parse_phandle);
>
>   static int __of_parse_phandle_with_args(const struct device_node *np,
>   					const char *list_name,
> -					const char *cells_name, int index,
> +					const char *cells_name,
> +					int cells_count, int index,

    The correct grammar would be 'cell_name' and 'cell_count' I think.

>   					struct of_phandle_args *out_args)
>   {
>   	const __be32 *list, *list_end;
> @@ -1142,12 +1143,17 @@ static int __of_parse_phandle_with_args(const struct device_node *np,
>   					 np->full_name);
>   				goto err;
>   			}
> -			if (of_property_read_u32(node, cells_name, &count)) {
> -				pr_err("%s: could not get %s for %s\n",
> -					 np->full_name, cells_name,
> -					 node->full_name);
> -				goto err;
> -			}
> +
> +			if (cells_name) {
> +				if (of_property_read_u32(node, cells_name,
> +							 &count)) {
> +					pr_err("%s: could not get %s for %s\n",
> +						np->full_name, cells_name,
> +						node->full_name);
> +					goto err;
> +				}
> +			} else
> +				count = cells_count;

    According to Documentation/CodingStyle chapter 3, both arms of the 
*if* statment should have {} if oe arm has it.

WBR, Sergei



From samuel.thibault at ens-lyon.org  Mon Jul 15 15:08:03 2013
From: samuel.thibault at ens-lyon.org (Samuel Thibault)
Date: Mon, 15 Jul 2013 21:08:03 +0200
Subject: [PATCH] Route kbd LEDs through the generic LEDs layer
In-Reply-To: <CANq1E4TRAOp+=w4oqPt4sjV7iLyDygxxpwrZy7dSB8UK288aNA@mail.gmail.com>
References: <201011112205.oABM5KVJ005298@imap1.linux-foundation.org>
 <201011111440.07882.dmitry.torokhov@gmail.com>
 <20110102090935.GV32469@atrey.karlin.mff.cuni.cz>
 <20110102103210.GA25662@core.coreip.homeip.net>
 <20110102225741.GX5480@const.famille.thibault.fr>
 <20110112182702.GA9168@core.coreip.homeip.net>
 <20111114040613.GA4992@type.famille.thibault.fr>
 <20121221003449.GA6999@type.youpi.perso.aquilenet.fr>
 <20130707101028.GD5651@type.youpi.perso.aquilenet.fr>
 <CANq1E4TRAOp+=w4oqPt4sjV7iLyDygxxpwrZy7dSB8UK288aNA@mail.gmail.com>
Message-ID: <20130715190803.GG11600@type.youpi.perso.aquilenet.fr>

Hello,

David Herrmann, le Mon 15 Jul 2013 17:03:08 +0200, a ?crit :
> > @@ -13,6 +13,10 @@
> >         bool "Virtual terminal" if EXPERT
> >         depends on !S390 && !UML
> >         select INPUT
> > +       select NEW_LEDS
> > +       select LEDS_CLASS
> > +       select LEDS_TRIGGERS
> > +       select INPUT_LEDS
> 
> This looks odd. Any dependency changes in the input-layer will break
> this. But I guess that's what we get for a non-recursive "select". Hmm

Yes, that's the issue.

> I also think that the macros don't really simplify this. So:
>   [VC_SHIFTLOCK] = { .name = "shiftlock", .activate =
> kbd_lockstate_trigger_activate },
> isn't much longer than:
>   DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTLOCK,  "shiftlock"),

That makes it more than 80 columns, at least.

> > +       for (i = 0; i < ARRAY_SIZE(ledtrig_ledstate); i++)
> > +               led_trigger_register(&ledtrig_ledstate[i]);
> > +       for (i = 0; i < ARRAY_SIZE(ledtrig_lockstate); i++)
> > +               led_trigger_register(&ledtrig_lockstate[i]);
> > +
> 
> This returns "int", are you sure no error-handling is needed?

ATM only registering the same name several times can happen, and
shouldn't ever happen. But better warn than be sorry, indeed.

> > + * Keyboard LEDs are propagated by default like the following example:
> > + *
> > + * VT keyboard numlock trigger
> > + * -> vt::numl VT LED
> > + * -> vt-numl VT trigger
> 
> Nitpick: What's the reason for the syntax difference? "vt-numl" vs. "vt::numl"

vt::numl is a clear LED classification convention. For triggers, I don't
see a clear convention, but at least I have never seen "::", only "-".
That makes me realize that for keyboard triggers I haven't introduced a
prefix, and only used "scrollock", "numlock", etc. Perhaps
"kbd-scrollock" etc. or (in phase with LEDs), "kbd::scrollock" etc.?

Samuel


From robherring2 at gmail.com  Mon Jul 15 15:10:59 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 15 Jul 2013 14:10:59 -0500
Subject: [RFC PATCH 02/11] ARM: DT/kernel: define ARM specific
 arch_of_get_cpu_node
In-Reply-To: <1373883732-26303-3-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1373883732-26303-3-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <51E44943.7000600@gmail.com>

On 07/15/2013 05:22 AM, Sudeep.KarkadaNagesha at arm.com wrote:
> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> CPU subsystem now provides architecture specific hook to retrieve the
> of_node. Most of the cpu DT node parsing and initialisation is contained
> in devtree.c. It's better to contain all CPU device node parsing there.
> 
> arch_of_get_cpu_node is mainly used to assign cpu->of_node when CPUs get
> registered. This patch overrides the defination of the same. It can also
> act as the helper function in pre-SMP/early initialisation stages to
> retrieve CPU device node pointers in logical ordering.
> 
> This mainly helps to avoid replication of the code doing CPU node parsing
> and physical(MPIDR) to logical mapping.
> 
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

[snip]

> +struct device_node * __init arch_of_get_cpu_node(int cpu)
> +{
> +	struct device_node *cpun, *cpus;
> +	const u32 *cell;
> +	u64 hwid;
> +	int ac;
> +
> +	cpus = of_find_node_by_path("/cpus");
> +	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
> +		return NULL;
> +
> +	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
> +		ac = of_n_addr_cells(cpus);
> +
> +	for_each_child_of_node(cpus, cpun) {
> +		if (of_node_cmp(cpun->type, "cpu"))
> +			continue;
> +		cell = of_get_property(cpun, "reg", NULL);
> +		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
> +			continue;
> +
> +		hwid = of_read_number(cell, ac);
> +		if ((hwid & MPIDR_HWID_BITMASK) == cpu_logical_map(cpu))

Most of this function is not ARM specific, so it would be nice if we
could shrink the arch specific part down to just this match. A default
match of reg == logical cpu number might be useful.

The powermac cpufreq driver could probably also be converted
(arch/powerpc/platforms/powermac/cpufreq_64.c).

Other than that, this series looks good to me.

Rob



From s-anna at ti.com  Mon Jul 15 15:23:52 2013
From: s-anna at ti.com (Suman Anna)
Date: Mon, 15 Jul 2013 14:23:52 -0500
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51E3C85D.2010008@ti.com>
References: <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <87mwpuakod.fsf@linaro.org>
 <20130710142633.GV5523@atomide.com> <20130710160704.GH18966@arwen.pp.htv.fi>
 <20130710161158.GA19716@arwen.pp.htv.fi> <20130711063209.GZ5523@atomide.com>
 <51DE8215.5060306@ti.com> <51DF508F.3050703@ti.com> <51E39A3F.6080106@ti.com>
 <51E3C85D.2010008@ti.com>
Message-ID: <51E44C48.3090905@ti.com>

On 07/15/2013 05:01 AM, Rajendra Nayak wrote:
> On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote:
>> On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
>>> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>>>> Hi,
>>>>
>>>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>>>>> * Felipe Balbi <balbi at ti.com> [130710 09:18]:
>>>>>>
>>>>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>>>>> how about something like below ? It makes omap_device/hwmod and
>>>>>>> pm_runtime agree on the initial state of the device and will prevent
>>>>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>>>>> during probe.
>>>>>>>
>>>>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>>>>
>>>>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>>>>> Author: Felipe Balbi <balbi at ti.com>
>>>>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>>>>
>>>>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>>>>
>>>>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>>>>      initial state of the device, we will unidle the device
>>>>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>>>>      that the device is really active.
>>>> Don't think that it's good idea (
>>>> I've checked some driver's and think this patch will enable some devices
>>>> unpredictably:
>>>> - hwspinlock
>>>> - mailbox
>>>> - iommu
>>>> - ipu
>>>> All above devices need to be enabled on demand only (no
>>>> pm_runtime_get*() calls in probe). More over, some of them have very
>>>> specific enabling sequence - like ipu).
>>>>
>>>> May be Summan can say more on that.
>>>
>>> Indeed, this is a problem for any of the slave processor devices.
>>> mailbox and iommu would be slaves to the remoteproc and the drivers have
>>> a specific sequence of bringing up a processor. The current
>>> hwmod/omap_device code is such that these devices will be left in reset
>>> and the driver code use the omap_device_(de)assert_hardreset API
>>> together with omap_device_enable code to bring up the devices. The
>>> remoteproc driver also needs to assert the resets (there are other
>>> problems associated with using omap_device_idle for remoteproc and
>>> iommu) for bringing up the devices after a suspend sequence. hwspinlock
>>> and mailbox may get away since they are in CORE domain, but definitely
>>> an issue for iommu and remoteproc. I would think that this would also
>>> affect other compute devices like IVAHD, ISS, SGX.
>>
>> Today, for these IPs I guess hwmod waits for the resets to be de-asserted, right?

Yes, the omap_device_enable bails out if the reset lines are still
asserted, and the driver code deals with the resets currently. This code
essentially achieves the same as if a HWMOD_INIT_NO_RESET flag is
added to the corresponding hwmods - we do not want the hwmod/omap_device
code to enable the processor IPs and leave the enabling/device
management to the driver.

>>
>>         /*
>>          * If an IP block contains HW reset lines and all of them are
>>          * asserted, we let integration code associated with that
>>          * block handle the enable.  We've received very little
>>          * information on what those driver authors need, and until
>>          * detailed information is provided and the driver code is
>>          * posted to the public lists, this is probably the best we
>>          * can do.
>>          */
>>         if (_are_all_hardreset_lines_asserted(oh))
>>                 return 0;
>>
>> What if this information is send back to omap_device() through a return value
>> so omap_device() knows about this too, so it avoids marking the omap device as
>> enabled? Wouldn't that fix the issue?
> 
> I meant something like this..
> 
> From 2fbea0dde0f72897089ef2e8e441b5e5bd6ea967 Mon Sep 17 00:00:00 2001
> From: Rajendra Nayak <rnayak at ti.com>
> Date: Mon, 15 Jul 2013 15:23:07 +0530
> Subject: [PATCH] ARM: OMAP2+: Make omap_device aware of hwmod failing to
>  enable/idle/shutdown the hwmods
> 
> For IP blocks (mainly processors) which have hard reset lines, hwmod avoids
> enable/idle/shutdown operations as long as all the hard reset lines are
> kept asserted. However it does not return an error back to the caller (in some
> cases the omap_device layer) to communicate back the failure to operate on the
> hwmod.
> 
> Fix this by making _enable()/_idle()/_shutdown() all return an error in such
> cases, and also fix the omap_device layer to look at the return values coming
> from hwmod operations before doing a omap_device level state transition.
> 
> Signed-off-by: Rajendra Nayak <rnayak at ti.com>

Let me test this and get back to you if there are any issues.

regards
Suman



From robherring2 at gmail.com  Mon Jul 15 15:34:49 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 15 Jul 2013 14:34:49 -0500
Subject: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property
In-Reply-To: <1373913629-32179-5-git-send-email-swarren@wwwdotorg.org>
References: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
 <1373913629-32179-5-git-send-email-swarren@wwwdotorg.org>
Message-ID: <51E44ED9.9020807@gmail.com>

On 07/15/2013 01:40 PM, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> This property is no longer required by the GPIO binding. Remove it.

Won't this break compatibility with older kernel? It is one thing to
deprecate, but removal is another. If the relevant maintainers don't
care, then I guess it is fine.

> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
> ---
> This should presumably be applied along with the previous changes

The rest looks fine to me. I can take this series, but would actually
prefer that this patch go separately to arm-soc.

Rob

> 
> v2: Squash spear and mxc changes into a single patch; there's no
> need to keep vf610.dtsi separate now that this series will go into
> v3.12 or later, and that file is part of v3.11-rc1.
> ---
>  arch/arm/boot/dts/spear1310.dtsi | 1 -
>  arch/arm/boot/dts/spear1340.dtsi | 1 -
>  arch/arm/boot/dts/spear310.dtsi  | 1 -
>  arch/arm/boot/dts/spear320.dtsi  | 2 --
>  arch/arm/boot/dts/vf610.dtsi     | 1 -
>  5 files changed, 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/spear1310.dtsi b/arch/arm/boot/dts/spear1310.dtsi
> index 122ae94..90e99b5 100644
> --- a/arch/arm/boot/dts/spear1310.dtsi
> +++ b/arch/arm/boot/dts/spear1310.dtsi
> @@ -89,7 +89,6 @@
>  		pinmux: pinmux at e0700000 {
>  			compatible = "st,spear1310-pinmux";
>  			reg = <0xe0700000 0x1000>;
> -			#gpio-range-cells = <3>;
>  		};
>  
>  		apb {
> diff --git a/arch/arm/boot/dts/spear1340.dtsi b/arch/arm/boot/dts/spear1340.dtsi
> index 54d128d..5003013 100644
> --- a/arch/arm/boot/dts/spear1340.dtsi
> +++ b/arch/arm/boot/dts/spear1340.dtsi
> @@ -63,7 +63,6 @@
>  		pinmux: pinmux at e0700000 {
>  			compatible = "st,spear1340-pinmux";
>  			reg = <0xe0700000 0x1000>;
> -			#gpio-range-cells = <3>;
>  		};
>  
>  		pwm: pwm at e0180000 {
> diff --git a/arch/arm/boot/dts/spear310.dtsi b/arch/arm/boot/dts/spear310.dtsi
> index 9537208..1e1318e 100644
> --- a/arch/arm/boot/dts/spear310.dtsi
> +++ b/arch/arm/boot/dts/spear310.dtsi
> @@ -25,7 +25,6 @@
>  		pinmux: pinmux at b4000000 {
>  			compatible = "st,spear310-pinmux";
>  			reg = <0xb4000000 0x1000>;
> -			#gpio-range-cells = <3>;
>  		};
>  
>  		fsmc: flash at 44000000 {
> diff --git a/arch/arm/boot/dts/spear320.dtsi b/arch/arm/boot/dts/spear320.dtsi
> index ffea342..f630d0c 100644
> --- a/arch/arm/boot/dts/spear320.dtsi
> +++ b/arch/arm/boot/dts/spear320.dtsi
> @@ -1,4 +1,3 @@
> -/*
>   * DTS file for SPEAr320 SoC
>   *
>   * Copyright 2012 Viresh Kumar <viresh.linux at gmail.com>
> @@ -24,7 +23,6 @@
>  		pinmux: pinmux at b3000000 {
>  			compatible = "st,spear320-pinmux";
>  			reg = <0xb3000000 0x1000>;
> -			#gpio-range-cells = <3>;
>  		};
>  
>  		clcd at 90000000 {
> diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
> index e1eb7da..8577780 100644
> --- a/arch/arm/boot/dts/vf610.dtsi
> +++ b/arch/arm/boot/dts/vf610.dtsi
> @@ -162,7 +162,6 @@
>  			iomuxc: iomuxc at 40048000 {
>  				compatible = "fsl,vf610-iomuxc";
>  				reg = <0x40048000 0x1000>;
> -				#gpio-range-cells = <3>;
>  
>  				/* functions and groups pins */
>  
> 



From s.hauer at pengutronix.de  Mon Jul 15 15:38:29 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 15 Jul 2013 21:38:29 +0200
Subject: [PATCH v1 05/24] clk: wrap I/O access for improved portability
In-Reply-To: <1373914074-20889-6-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1373914074-20889-6-git-send-email-gsi@denx.de>
Message-ID: <20130715193829.GS14452@pengutronix.de>

On Mon, Jul 15, 2013 at 08:47:34PM +0200, Gerhard Sittig wrote:
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index 6d55eb2..2c07061 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -104,7 +104,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
>  	struct clk_divider *divider = to_clk_divider(hw);
>  	unsigned int div, val;
>  
> -	val = readl(divider->reg) >> divider->shift;
> +	val = clk_readl(divider->reg) >> divider->shift;
>  	val &= div_mask(divider);

Would it be an option to use regmap for the generic dividers/muxes
instead? This should be suitable for ppc and also for people who want to
use the generic clocks on i2c devices.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From thomas.petazzoni at free-electrons.com  Mon Jul 15 15:51:43 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Jul 2013 21:51:43 +0200
Subject: pci-mvebu driver on km_kirkwood
In-Reply-To: <51E41944.6030403@keymile.com>
References: <51DD88A4.1030506@keymile.com> <20130710185706.72b124a4@skate>
 <51DD9A8C.10608@keymile.com> <51DE58DF.5010304@keymile.com>
 <20130712105903.6336e912@skate> <51E41944.6030403@keymile.com>
Message-ID: <20130715215143.5167a987@skate>

Dear Valentin Longchamp,

On Mon, 15 Jul 2013 17:46:12 +0200, Valentin Longchamp wrote:

> > I'm not sure to follow this story of a virtual PCIe controller sitting
> > at 0xf4000000. Can you give a few more details?
> > 
> 
> I'm not sure I can give all the details here as the documentation that we have
> for this is subject to an NDA. To keep it short, in the kirkwood SoC we use,
> there is an Ethernet Switch that is accessed by the kirkwood through an internal
> virtual PCIe controller. The switch management SW has some hard expectations
> about the physical address for this "PCIe" memory mapped window which conflicts
> with the ones defined in the current device trees.

Ok. Note that the addresses chosen in the Device Tree can easily be
changed on a per-SoC or per-board basis, if needed.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From broonie at kernel.org  Mon Jul 15 16:17:34 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 15 Jul 2013 21:17:34 +0100
Subject: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them
In-Reply-To: <1373914074-20889-2-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1373914074-20889-2-git-send-email-gsi@denx.de>
Message-ID: <20130715201734.GF11538@sirena.org.uk>

On Mon, Jul 15, 2013 at 08:47:30PM +0200, Gerhard Sittig wrote:
> clocks need to get prepared before they can get enabled,
> fix the MPC512x PSC SPI master's initialization

> Signed-off-by: Gerhard Sittig <gsi at denx.de>
> ---
>  drivers/spi/spi-mpc512x-psc.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
> index 29fce6a..76b20ea 100644
> --- a/drivers/spi/spi-mpc512x-psc.c
> +++ b/drivers/spi/spi-mpc512x-psc.c
> @@ -395,7 +395,7 @@ static int mpc512x_psc_spi_port_config(struct spi_master *master,
>  
>  	sprintf(name, "psc%d_mclk", master->bus_num);
>  	spiclk = clk_get(&master->dev, name);
> -	clk_enable(spiclk);
> +	clk_prepare_enable(spiclk);
>  	mps->mclk = clk_get_rate(spiclk);
>  	clk_put(spiclk);

This code is *clearly* buggy and should be fixed rather than papered
over.  Not only is there no matching put the driver is also dropping the
reference to the clock rather than holding on to it while it's in use.
-------------- 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/20130715/a9b4d8ae/attachment.sig>

From dsd at laptop.org  Mon Jul 15 16:23:30 2013
From: dsd at laptop.org (Daniel Drake)
Date: Mon, 15 Jul 2013 14:23:30 -0600
Subject: DT binding review for Armada display subsystem
In-Reply-To: <20130712164428.AC3D2FAAE9@dev.laptop.org>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
Message-ID: <CAMLZHHRvWFrxxjr0sF0NRqvz+K1wB9Mb_OGG-8tx36A2rk-SNQ@mail.gmail.com>

On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake <dsd at laptop.org> wrote:
> Based on the outcomes of the "Best practice device tree design for display
> subsystems" discussion I have drafted a DT binding. Comments much appreciated.
>
> At a high level, it uses a "super node" as something for the driver to bind
> to, needed because there is no clear one device that controls all the
> others, and also to distinguish between the Armada 510 possible use cases
> of having one video card with two outputs, or two independent video cards.
> It uses node-to-node linking beyond that point, V4L2 style.

As this hasn't been shot down very far, I've started to implement the
driver side of this binding. I have already run into a couple of
little problems.

First, interrupts. In the dt binding, each "lcd controller" node
defines which interrupt it listens to, and in the armada 510 case
there are indeed 2 interrupts (47 and 46, one for each LCD
controller). And remember that the drm driver itself binds to the
super-node.

Looking at drm_irq_install(), it looks like DRM only supports 1
interrupt line per drm_device. As we have no known users who will want
these two LCD controllers represented as 2 CRTCs on 1 DRM device
(which would require management of 2 interrupt lines), I figured this
might be a reason to ignore that use case for now (from the coding
standpoint), meaning that in all cases we are left with each DRM
device having 1 CRTC, corresponding to 1 LCD controller, which has
exactly 1 interrupt line.

That still doesn't solve the problem though. drm_irq_install calls
into drm_platform to figure out which IRQ number to use, and that code
looks at the platform_device (i.e. super node). In this case we don't
have the irq info there, we have it in the "lcd controller" node.

Do I invent our own "DRM bus" implementation so that we can override
get_irq()? Start to standardise our DT design as a generic drm_dt.c
bus implementation? Any thoughts?


Secondly, devm. I understand from the "best practices" thread that we
want to have exactly one platform_device which corresponds to the
"super node", and all of the individual display controller components
will be represented by DT nodes but *without* their own
platform_device. As we now put things (clocks, interrupts) into DT
nodes that don't have a corresponding platform_device, we lose the
ability to use devm. Russell wasn't too pleased last time I posted a
patch moving away from devm, admittedly last time the patch was bad
and it wasn't necessary, but this time it looks like it might be.


Finally, just curious, do we still want to support non-DT platform
data type setups on this driver? That adds a bit of coding effort. Not
a problem, just wanted to check.

Daniel


From tomasz.figa at gmail.com  Mon Jul 15 16:35:34 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 15 Jul 2013 22:35:34 +0200
Subject: DT binding review for Armada display subsystem
In-Reply-To: <20130713230955.GQ24642@n2100.arm.linux.org.uk>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <51E1D1DA.8080102@gmail.com> <20130713230955.GQ24642@n2100.arm.linux.org.uk>
Message-ID: <1854596.j2AmPXyF76@flatron>

Hi,

On Sunday 14 of July 2013 00:09:55 Russell King - ARM Linux wrote:
> On Sun, Jul 14, 2013 at 12:16:58AM +0200, Sylwester Nawrocki wrote:
> > On 07/13/2013 11:02 PM, Russell King - ARM Linux wrote:
> >> On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
> >>> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it
> >>> seems they're working on v4 with clock object reference counting.
> >>> Presumably we need both clk_get() to be taking reference on the
> >>> module and reference counted clk free, e.g. in cases where clock
> >>> provider is a hot-pluggable device. It might be too paranoid
> >>> though, I haven't seen hardware configurations where a clock source
> >>> could be unplugged safely when whole system is running.
> >> 
> >> I'm not going to accept refcounting being thrown into clk_get().  The
> >> clkdev API already has refcounting, as much as it needs to.  It just
> >> needs people to use the hooks that I provided back in 2008 when I
> >> created the clkdev API for doing _precisely_ this job.
> >> 
> >> Have a read through these commits, which backup my statement above:
> >> 
> >> 0318e693d3a56836632bf1a2cfdafb7f34bcc703 - initial commit of the
> >> clkdev API d72fbdf01fc77628c0b837d0dd2fd564fa26ede6 - converting
> >> Integrator to clkdev API
> >> 
> >> and it will show you how to do refcounting.  The common clk API just
> >> needs to stop defining __clk_get() and __clk_put() to be an empty
> >> function and implement them appropriately for it's clk
> >> implementation,
> >> like they were always meant to be.
> > 
> > Sure, I've already seen the above commits. This is how I understood it
> > as well - __clk_get(), __clk_put() need to be defined by the common
> > clk
> > API, since it is going to replace all the arch specific
> > implementations.> 
> >> __clk_get() and __clk_put() are the clk-implementation specific parts
> >> of the clkdev API, because the clkdev API is utterly divorsed from
> >> the
> >> internals of what a 'struct clk' actually is.  clkdev just treats a
> >> 'struct clk' as a completely opaque type and never bothers poking
> >> about inside it.
> > 
> > OK, but at the clock's implementation side we may need, e.g. to use
> > kref to keep track of the clock's state, and free it only when it is
> > unprepared, all its children are unregistered, etc. ? Is it not what
> > you stated in your comment to patch [1] ?
> 
> If you want to do refcounting on a clock (which you run into problems
> as I highlighted earlier in this thread) then yes, you need to use a
> kref, and take a reference in __clk_get() and drop it in __clk_put()
> to make things safe.
> 
> Whether you also take a reference on the module supplying the clock or
> not depends whether you need to keep the code around to manipulate that
> clock while there are users of it.
> 
> As I've already said - consider the possibilities with this scenario.
> Here's one:
> 
>   A clock consumer is using a clock, but the clock supplier has been
>   removed.  The clock consumer wants to change the state of the clock
>   in some way - eg, system is suspending.  clk_disable() doesn't fail,
>   but on resume, clk_enable() does... (and how many people assume that
>   clk_enable() never fails?)  And who knows what rate the clock is now
>   producing or whether it's even producing anything...
> 
> I'm not saying don't do the refcounting thing I mentioned back in June.
> I'm merely pointing out the issues that there are.  There isn't a one
> right answer here because each has their own advantages and
> disadvantages (and problems.)

What about having Mike on CC for such clock-related discussion?

Best regards,
Tomasz



From robherring2 at gmail.com  Mon Jul 15 16:42:23 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 15 Jul 2013 15:42:23 -0500
Subject: [PATCH] ARM: Add check for Cortex-A15 errata 798181 ECO
Message-ID: <1373920943-18308-1-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

The work-around for A15 errata 798181 is not needed if appropriate ECO
fixes have been applied to r3p2 and earlier core revisions. This can be
checked by reading REVIDR register bits 4 and 9. If only bit 4 is set,
then the IPI broadcast can be skipped.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---

Compile tested only.

 arch/arm/include/asm/cputype.h |  1 +
 arch/arm/kernel/smp_tlb.c      | 13 +++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index ec635ff..ac1c46a 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -9,6 +9,7 @@
 #define CPUID_TCM	2
 #define CPUID_TLBTYPE	3
 #define CPUID_MPIDR	5
+#define CPUID_REVIDR	6
 
 #ifdef CONFIG_CPU_V7M
 #define CPUID_EXT_PFR0	0x40
diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
index 9a52a07..7fd64b7 100644
--- a/arch/arm/kernel/smp_tlb.c
+++ b/arch/arm/kernel/smp_tlb.c
@@ -74,10 +74,21 @@ static inline void ipi_flush_bp_all(void *ignored)
 static int erratum_a15_798181(void)
 {
 	unsigned int midr = read_cpuid_id();
+	unsigned int revidr;
 
 	/* Cortex-A15 r0p0..r3p2 affected */
 	if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2)
 		return 0;
+
+	/* Check for Cortex A15 <= r3p2 with ECO fix */
+	revidr = read_cpuid(CPUID_REVIDR);
+	if ((revidr & 0x210) == 0x210)
+		return 0;
+
+	dummy_flush_tlb_a15_erratum();
+	if (revidr & 0x10)
+		return 0;
+
 	return 1;
 }
 #else
@@ -97,7 +108,6 @@ static void broadcast_tlb_a15_erratum(void)
 	if (!erratum_a15_798181())
 		return;
 
-	dummy_flush_tlb_a15_erratum();
 	smp_call_function(ipi_flush_tlb_a15_erratum, NULL, 1);
 }
 
@@ -109,7 +119,6 @@ static void broadcast_tlb_mm_a15_erratum(struct mm_struct *mm)
 	if (!erratum_a15_798181())
 		return;
 
-	dummy_flush_tlb_a15_erratum();
 	this_cpu = get_cpu();
 	for_each_online_cpu(cpu) {
 		if (cpu == this_cpu)
-- 
1.8.1.2



From robherring2 at gmail.com  Mon Jul 15 16:52:12 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 15 Jul 2013 15:52:12 -0500
Subject: [PATCH] ARM: footbridge: fix overlapping PCI mappings
In-Reply-To: <1372387356-15341-1-git-send-email-vapier@gentoo.org>
References: <1372387356-15341-1-git-send-email-vapier@gentoo.org>
Message-ID: <CAL_JsqKaha08U0fN1FruEEfsH=jAGzsxeJATJqeDvburd6EDjw@mail.gmail.com>

On Thu, Jun 27, 2013 at 9:42 PM, Mike Frysinger <vapier at gentoo.org> wrote:
> Commit 8ef6e6201b26cb9fde79c1baa08145af6aca2815 (ARM: footbridge: use
> fixed PCI i/o mapping) broke booting on my netwinder.  Before that,
> everything boots fine.  Since then, it crashes on boot.
>
> With earlyprintk, I see it BUG-ing like so:
> kernel BUG at lib/ioremap.c:27!
> Internal error: Oops - BUG: 0 [#1] ARM
> ...
> [<c0139b54>] (ioremap_page_range+0x128/0x154) from [<c02e6a6c>] (dc21285_setup+0xd0/0x114)
> [<c02e6a6c>] (dc21285_setup+0xd0/0x114) from [<c02e4874>] (pci_common_init+0xa0/0x298)
> [<c02e4874>] (pci_common_init+0xa0/0x298) from [<c02e793c>] (netwinder_pci_init+0xc/0x18)
> [<c02e793c>] (netwinder_pci_init+0xc/0x18) from [<c02e27d0>] (do_one_initcall+0xb4/0x180)
> ...
>
> Russell points out it's because of overlapping PCI mappings that was
> added with the aforementioned commit.  Rob thought the code would re-use
> the static mapping, but that turns out to not be the case and instead
> hits the BUG further down.
>
> After deleting this hunk as suggested by Russel, the system boots up fine
> again and all my PCI devices work (IDE, ethernet, the DC21285).
>
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>

Acked-by: Rob Herring <rob.herring at calxeda.com>

Olof, Kevin,

Please apply and add stable.

Rob

> ---
>  arch/arm/mach-footbridge/dc21285.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/mach-footbridge/dc21285.c b/arch/arm/mach-footbridge/dc21285.c
> index a7cd2cf..3490a24 100644
> --- a/arch/arm/mach-footbridge/dc21285.c
> +++ b/arch/arm/mach-footbridge/dc21285.c
> @@ -276,8 +276,6 @@ int __init dc21285_setup(int nr, struct pci_sys_data *sys)
>
>         sys->mem_offset  = DC21285_PCI_MEM;
>
> -       pci_ioremap_io(0, DC21285_PCI_IO);
> -
>         pci_add_resource_offset(&sys->resources, &res[0], sys->mem_offset);
>         pci_add_resource_offset(&sys->resources, &res[1], sys->mem_offset);
>
> --
> 1.8.2.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From olof at lixom.net  Mon Jul 15 16:59:24 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 15 Jul 2013 13:59:24 -0700
Subject: [PATCH] ARM: Add check for Cortex-A15 errata 798181 ECO
In-Reply-To: <1373920943-18308-1-git-send-email-robherring2@gmail.com>
References: <1373920943-18308-1-git-send-email-robherring2@gmail.com>
Message-ID: <CAOesGMjATn9MCzazUGmbD44XR8HyJZU4cCvmOEoUZsmCgutPUg@mail.gmail.com>

On Mon, Jul 15, 2013 at 1:42 PM, Rob Herring <robherring2 at gmail.com> wrote:
> diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
> index 9a52a07..7fd64b7 100644
> --- a/arch/arm/kernel/smp_tlb.c
> +++ b/arch/arm/kernel/smp_tlb.c
> @@ -74,10 +74,21 @@ static inline void ipi_flush_bp_all(void *ignored)
>  static int erratum_a15_798181(void)
>  {
>         unsigned int midr = read_cpuid_id();
> +       unsigned int revidr;
>
>         /* Cortex-A15 r0p0..r3p2 affected */
>         if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2)
>                 return 0;
> +
> +       /* Check for Cortex A15 <= r3p2 with ECO fix */
> +       revidr = read_cpuid(CPUID_REVIDR);
> +       if ((revidr & 0x210) == 0x210)
> +               return 0;

Reading and evaluating all this on every invalidate seems suboptimal.
It should be possible to read just once and cache the result.

I would have had the same comment about the original patch, but ARM
pushes those to Russell in secret so it wasn't on the list. :-)


-Olof


From s.hauer at pengutronix.de  Mon Jul 15 17:09:00 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 15 Jul 2013 23:09:00 +0200
Subject: DT binding review for Armada display subsystem
In-Reply-To: <CAMLZHHRvWFrxxjr0sF0NRqvz+K1wB9Mb_OGG-8tx36A2rk-SNQ@mail.gmail.com>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <CAMLZHHRvWFrxxjr0sF0NRqvz+K1wB9Mb_OGG-8tx36A2rk-SNQ@mail.gmail.com>
Message-ID: <20130715210900.GT14452@pengutronix.de>

On Mon, Jul 15, 2013 at 02:23:30PM -0600, Daniel Drake wrote:
> On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake <dsd at laptop.org> wrote:
> > Based on the outcomes of the "Best practice device tree design for display
> > subsystems" discussion I have drafted a DT binding. Comments much appreciated.
> >
> > At a high level, it uses a "super node" as something for the driver to bind
> > to, needed because there is no clear one device that controls all the
> > others, and also to distinguish between the Armada 510 possible use cases
> > of having one video card with two outputs, or two independent video cards.
> > It uses node-to-node linking beyond that point, V4L2 style.
> 
> As this hasn't been shot down very far, I've started to implement the
> driver side of this binding. I have already run into a couple of
> little problems.
> 
> First, interrupts. In the dt binding, each "lcd controller" node
> defines which interrupt it listens to, and in the armada 510 case
> there are indeed 2 interrupts (47 and 46, one for each LCD
> controller). And remember that the drm driver itself binds to the
> super-node.
> 
> Looking at drm_irq_install(), it looks like DRM only supports 1
> interrupt line per drm_device.

You don't have to call drm_irq_install(). Both the exynos and i.MX
driver do without it and at least the i.MX driver uses multiple irqs per
drm_device.

> 
> Secondly, devm. I understand from the "best practices" thread that we
> want to have exactly one platform_device which corresponds to the
> "super node", and all of the individual display controller components
> will be represented by DT nodes but *without* their own
> platform_device.

A super node approach doesn't mean that there's only one platform
device. You can still have a platform device for each component. The
super node should rather be seen as a node which contains phandles
to the different components..

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From oliver+list at schinagl.nl  Mon Jul 15 17:16:19 2013
From: oliver+list at schinagl.nl (Oliver Schinagl)
Date: Mon, 15 Jul 2013 23:16:19 +0200
Subject: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner's
 Security ID fuses
In-Reply-To: <20130706193646.GB9778@kroah.com>
References: <20130617225847.GA9494@kroah.com>
 <20130624092942.GG26008@lukather> <20130624160440.GA15201@kroah.com>
 <51C87DC7.50005@schinagl.nl> <20130624181509.GA8847@kroah.com>
 <51C8B84C.3020200@schinagl.nl> <20130624214615.GA17604@kroah.com>
 <51CAA709.4060801@schinagl.nl> <20130626175144.GC2222@kroah.com>
 <51D674BF.9030207@schinagl.nl> <20130706193646.GB9778@kroah.com>
Message-ID: <51E466A3.4010503@schinagl.nl>

On 07/06/13 21:36, Greg KH wrote:
> On Fri, Jul 05, 2013 at 09:24:47AM +0200, Oliver Schinagl wrote:
>> The other 'broken' drivers that where linked earlier, also use the
>> BINARY attributes.
>>
>> So Greg, if you could be so kind and give me an example how to
>> implement this properly, I am at loss and don't know :(
>
> Ah crap, devices don't have a binary attribute group, like struct class
> does.  I'll go add that on Monday and send you the patch to see if that
> helps you out.  I'll also go through and fix up all of the binary
> attribute drivers to keep them from doing that...
>
> Sorry, I missed that earlier, but thanks for trying and pointing out my
> mistake.
>
> greg k-h
>

Greg,

I know you are a busy man and I hate take away some of your time, but 
could you be so kind and point me into the right direction and show me 
what I should do?

With your latest patches for binary attributes and your blog post, I 
thought that you want to create your binary attributes before the probe 
function, to avoid the userspace race. To do that, we have two options, 
create them in init (ugly?) or fill the .group member if available so it 
gets automatically created from the register function.

Well in my case, I'm using the module_platform_driver() macro which 
expects the struct platform_driver. Platform_driver has a device_driver 
member .driver where the .groups is located. Great, using that works and 
we should have the sysfs entry race-free. However I don't know hot to 
exchange data between that and the rest of my driver.

Before I used to_platform_device(kobj_to_dev(kobj)) as passed via the 
.read function to obtain a platform_device where i could use 
platform_get_drvdata on. All was good, but that doesn't fly now and my 
knowledge is a bit short as to why.

The second method is finding some other shared structure given that we 
get a platform_device in the probe function, yet I couldn't find 
anything and this platform_device isn't the same as the one from the .read.

Of course using a global var bypasses this issue, but I'm sure it won't 
pass review ;)

So using these new patches for binary attributes, how can I pass data 
between my driver and the sysfs files using a platform_driver? Or are 
other 'hacks' needed and using the .groups attribute from 
platform_driver->device_driver->groups is really the wrong approach.

I did ask around and still haven't figured it out so far, so I do 
apologize if you feel I'm wasting your precious time.

Oliver
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sunxi_sid.c
Type: text/x-csrc
Size: 4119 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130715/7e9d8821/attachment-0001.bin>

From s.hauer at pengutronix.de  Mon Jul 15 17:16:21 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 15 Jul 2013 23:16:21 +0200
Subject: [PATCH 01/22] ARM i.MX25: devicetree: add compatible property
 for imxfb support.
In-Reply-To: <1373900227-341-2-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-2-git-send-email-denis@eukrea.com>
Message-ID: <20130715211621.GA10995@pengutronix.de>

On Mon, Jul 15, 2013 at 04:56:46PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  arch/arm/boot/dts/imx25.dtsi |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
> index bcd3171..6a1633d 100644
> --- a/arch/arm/boot/dts/imx25.dtsi
> +++ b/arch/arm/boot/dts/imx25.dtsi
> @@ -394,6 +394,7 @@
>  			};
>  
>  			lcdc at 53fbc000 {
> +				compatible = "fsl,imx21-lcdif";

The driver matches "fsl,imx21-fb", not "fsl,imx21-lcdif". Also please
add a i.MX25 specific compatible so that we have the chance to match the
specific SoC version in the driver.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From s.hauer at pengutronix.de  Mon Jul 15 17:19:18 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 15 Jul 2013 23:19:18 +0200
Subject: [PATCH 05/22] ARM: i.MX25 DT: use auxdata to attach
 imxfb_platform_data
In-Reply-To: <1373900227-341-6-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-6-git-send-email-denis@eukrea.com>
Message-ID: <20130715211918.GB10995@pengutronix.de>

On Mon, Jul 15, 2013 at 04:56:50PM +0200, Denis Carikli wrote:
> This commit is based on the following commit:
>   ab2815c3997b179f043a747264d155ab0bc181ad ARM: mxs: use auxdata to attach mxsfb_platform_data
> 

This patch is not necessary. The imxfb driver has proper devicetree
binding since 3.11-rc1.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From s.hauer at pengutronix.de  Mon Jul 15 17:20:52 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 15 Jul 2013 23:20:52 +0200
Subject: [PATCH 06/22] arm/dts: i.MX25: Add ssi clocks and DMA events.
In-Reply-To: <1373900227-341-7-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-7-git-send-email-denis@eukrea.com>
Message-ID: <20130715212052.GC10995@pengutronix.de>

On Mon, Jul 15, 2013 at 04:56:51PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  arch/arm/boot/dts/imx25.dtsi |    6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
> index b318106..fb37111 100644
> --- a/arch/arm/boot/dts/imx25.dtsi
> +++ b/arch/arm/boot/dts/imx25.dtsi
> @@ -293,6 +293,9 @@
>  				compatible = "fsl,imx25-ssi", "fsl,imx21-ssi";
>  				reg = <0x50014000 0x4000>;
>  				interrupts = <11>;
> +				clocks = <&clks 118>;
> +				clock-names = "ssi2_ipg";

ssi2_ipg is wrong. This should be "ipg".

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From festevam at gmail.com  Mon Jul 15 17:22:02 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 15 Jul 2013 18:22:02 -0300
Subject: [PATCH 01/22] ARM i.MX25: devicetree: add compatible property for
 imxfb support.
In-Reply-To: <20130715211621.GA10995@pengutronix.de>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-2-git-send-email-denis@eukrea.com>
 <20130715211621.GA10995@pengutronix.de>
Message-ID: <CAOMZO5A0qS39GFf1PeFS7BBL7PFMbNjkNpD2yqKGg660ZyYxbw@mail.gmail.com>

On Mon, Jul 15, 2013 at 6:16 PM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> On Mon, Jul 15, 2013 at 04:56:46PM +0200, Denis Carikli wrote:
>> Signed-off-by: Denis Carikli <denis at eukrea.com>
>> ---
>>  arch/arm/boot/dts/imx25.dtsi |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
>> index bcd3171..6a1633d 100644
>> --- a/arch/arm/boot/dts/imx25.dtsi
>> +++ b/arch/arm/boot/dts/imx25.dtsi
>> @@ -394,6 +394,7 @@
>>                       };
>>
>>                       lcdc at 53fbc000 {
>> +                             compatible = "fsl,imx21-lcdif";
>
> The driver matches "fsl,imx21-fb", not "fsl,imx21-lcdif". Also please
> add a i.MX25 specific compatible so that we have the chance to match the
> specific SoC version in the driver.

A patch was already sent for this:
http://www.spinics.net/lists/arm-kernel/msg258249.html


From s.hauer at pengutronix.de  Mon Jul 15 17:26:13 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 15 Jul 2013 23:26:13 +0200
Subject: [PATCH 10/22] arm/dts: Add support for the cpuimx25 board from
 Eukrea and its baseboard.
In-Reply-To: <1373900227-341-11-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-11-git-send-email-denis@eukrea.com>
Message-ID: <20130715212613.GD10995@pengutronix.de>

On Mon, Jul 15, 2013 at 04:56:55PM +0200, Denis Carikli wrote:
> Only the following devices/functionalities were added:
>  * Main UART
>  * Memory node
>  * NAND
>  * i2c and its pcf8563
>  * Ethernet
>  * LCD controller
>  * Sound
>  * ESDHC
> 
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  Documentation/devicetree/bindings/arm/fsl.txt     |    4 ++
>  arch/arm/boot/dts/eukrea_cpuimx25.dts             |   48 +++++++++++++++++
>  arch/arm/boot/dts/eukrea_mbimxsd25-baseboard.dtsi |   59 +++++++++++++++++++++
>  3 files changed, 111 insertions(+)
>  create mode 100644 arch/arm/boot/dts/eukrea_cpuimx25.dts
>  create mode 100644 arch/arm/boot/dts/eukrea_mbimxsd25-baseboard.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
> index e935d7d..2c19348 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.txt
> +++ b/Documentation/devicetree/bindings/arm/fsl.txt
> @@ -9,6 +9,10 @@ i.MX25 Product Development Kit
>  Required root node properties:
>      - compatible = "fsl,imx25-pdk", "fsl,imx25";
>  
> +i.MX25 Eukrea CPUIMX25 Board.
> +Required root node properties:
> +    - compatible = "fsl,eukrea_cpuimx25", "fsl,imx25";
> +
>  i.MX27 Product Development Kit
>  Required root node properties:
>      - compatible = "fsl,imx27-pdk", "fsl,imx27";
> diff --git a/arch/arm/boot/dts/eukrea_cpuimx25.dts b/arch/arm/boot/dts/eukrea_cpuimx25.dts

Currently all i.MX (and most other SoCs aswell) dts files start with the
SoC prefix, so this file should be named imx25-eukrea-cpuimx25.dts.

> +/dts-v1/;
> +#include "imx25.dtsi"
> +#include "eukrea_mbimxsd25-baseboard.dtsi"

Same here.

> +
> +/ {
> +	model = "Eukrea CPUIMX25";
> +	compatible = "fsl,eukrea_cpuimx25", "fsl,imx25";

As Fabio mentioned in another patch: eukrea,cpuimx25

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From s.hauer at pengutronix.de  Mon Jul 15 17:30:47 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 15 Jul 2013 23:30:47 +0200
Subject: [PATCH 15/22] drm: Add the lacking DRM_MODE_FLAG_* for matching
 the DISPLAY_FLAGS_*
In-Reply-To: <1373900227-341-16-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-16-git-send-email-denis@eukrea.com>
Message-ID: <20130715213047.GE10995@pengutronix.de>

On Mon, Jul 15, 2013 at 04:57:00PM +0200, Denis Carikli wrote:
> Without that fix, drivers using the drm_display_mode_from_videomode
>   function will not be able to get certain information because
>   some DISPLAY_FLAGS_* have no corresponding DRM_MODE_FLAG_*.
> 
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  drivers/gpu/drm/drm_modes.c |    9 +++++++++
>  include/uapi/drm/drm_mode.h |   32 ++++++++++++++++++--------------
>  2 files changed, 27 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index a6729bf..443bb94 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(const struct videomode *vm,
>  		dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
>  	if (vm->flags & DISPLAY_FLAGS_DOUBLECLK)
>  		dmode->flags |= DRM_MODE_FLAG_DBLCLK;
> +	if (vm->flags & DISPLAY_FLAGS_DE_LOW)
> +		dmode->flags |= DRM_MODE_FLAG_NDATEN;
> +	if (vm->flags & DISPLAY_FLAGS_DE_HIGH)
> +		dmode->flags |= DRM_MODE_FLAG_PDATEN;
> +	if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE)
> +		dmode->flags |= DRM_MODE_FLAG_PPIXDATEDGE;
> +	if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> +		dmode->flags |= DRM_MODE_FLAG_NPIXDATEDGE;
> +
>  	drm_mode_set_name(dmode);
>  
>  	return 0;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 53db7ce..5ec85f9 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -44,20 +44,24 @@
>  
>  /* Video mode flags */
>  /* bit compatible with the xorg definitions. */
> -#define DRM_MODE_FLAG_PHSYNC	(1<<0)
> -#define DRM_MODE_FLAG_NHSYNC	(1<<1)
> -#define DRM_MODE_FLAG_PVSYNC	(1<<2)
> -#define DRM_MODE_FLAG_NVSYNC	(1<<3)
> -#define DRM_MODE_FLAG_INTERLACE	(1<<4)
> -#define DRM_MODE_FLAG_DBLSCAN	(1<<5)
> -#define DRM_MODE_FLAG_CSYNC	(1<<6)
> -#define DRM_MODE_FLAG_PCSYNC	(1<<7)
> -#define DRM_MODE_FLAG_NCSYNC	(1<<8)
> -#define DRM_MODE_FLAG_HSKEW	(1<<9) /* hskew provided */
> -#define DRM_MODE_FLAG_BCAST	(1<<10)
> -#define DRM_MODE_FLAG_PIXMUX	(1<<11)
> -#define DRM_MODE_FLAG_DBLCLK	(1<<12)
> -#define DRM_MODE_FLAG_CLKDIV2	(1<<13)
> +#define DRM_MODE_FLAG_PHSYNC		(1<<0)
> +#define DRM_MODE_FLAG_NHSYNC		(1<<1)
> +#define DRM_MODE_FLAG_PVSYNC		(1<<2)
> +#define DRM_MODE_FLAG_NVSYNC		(1<<3)
> +#define DRM_MODE_FLAG_INTERLACE		(1<<4)
> +#define DRM_MODE_FLAG_DBLSCAN		(1<<5)
> +#define DRM_MODE_FLAG_CSYNC		(1<<6)
> +#define DRM_MODE_FLAG_PCSYNC		(1<<7)
> +#define DRM_MODE_FLAG_NCSYNC		(1<<8)
> +#define DRM_MODE_FLAG_HSKEW		(1<<9) /* hskew provided */
> +#define DRM_MODE_FLAG_BCAST		(1<<10)
> +#define DRM_MODE_FLAG_PIXMUX		(1<<11)
> +#define DRM_MODE_FLAG_DBLCLK		(1<<12)
> +#define DRM_MODE_FLAG_CLKDIV2		(1<<13)
> +#define DRM_MODE_FLAG_PDATEN		(1<<14)
> +#define DRM_MODE_FLAG_NDATEN		(1<<15)
> +#define DRM_MODE_FLAG_PPIXDATEDGE	(1<<16)
> +#define DRM_MODE_FLAG_NPIXDATEDGE	(1<<17)

Drop the unnecessary whitespace changes. Cc dri-devel next time.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From s.hauer at pengutronix.de  Mon Jul 15 17:43:01 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 15 Jul 2013 23:43:01 +0200
Subject: [PATCH 19/22] Input: tsc2007: Add device tree support.
In-Reply-To: <1373900227-341-20-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-20-git-send-email-denis@eukrea.com>
Message-ID: <20130715214301.GF10995@pengutronix.de>

On Mon, Jul 15, 2013 at 04:57:04PM +0200, Denis Carikli wrote:
> Set the of_match_table for this driver so that devices can be described
>   in the device tree.
> 
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  .../bindings/input/touchscreen/tsc2007.txt         |   44 +++++
>  drivers/input/touchscreen/tsc2007.c                |  205 ++++++++++++++++----
>  2 files changed, 206 insertions(+), 43 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
> 
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
> new file mode 100644
> index 0000000..d67b33f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
> @@ -0,0 +1,44 @@
> +* Texas Instruments tsc2007 touchscreen controller
> +
> +Required properties:
> +- compatible: must be "ti,tsc2007".
> +- reg: I2C address of the chip.
> +- pinctrl-0: Should specify pin control groups used for this controller
> +  (see pinctrl bindings[0]).
> +- pinctrl-names: Should contain only one value - "default"
> +  (see pinctrl bindings[0]).
> +- interrupt-parent: the phandle for the interrupt controller
> +  (see interrupt binding[1]).
> +- interrupts: interrupt to which the chip is connected
> +  (see interrupt binding[1]).
> +- x-plate-ohms: X-plate resistance in ohms.
> +
> +Optional properties:
> +- gpios: the interrupt gpio the chip is connected to (trough the penirq pin)
> +  (see GPIO binding[2] for more details).
> +- max-rt: maximum pressure.
> +- fuzzy: specifies the fuzz value that is used to filter noise from the event
> +  stream.
> +- poll-period: how much time to wait(in millisecond) before reading again the
> +  values from the tsc2007.
> +
> +[0]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> +[1]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> +[2]: Documentation/devicetree/bindings/gpio/gpio.txt
> +
> +Example:
> +	&i2c1 {
> +		/* ... */
> +		tsc2007 at 49 {
> +			compatible = "ti,tsc2007";
> +			reg = <0x49>;
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_tsc2007_1>;
> +			interrupt-parent = <&gpio4>;
> +			interrupts = <0x0 0x8>;
> +			gpios = <&gpio4 0 0>;
> +			x-plate-ohms = <180>;
> +		};
> +
> +		/* ... */
> +	};
> diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c
> index 0b67ba4..c0af04b 100644
> --- a/drivers/input/touchscreen/tsc2007.c
> +++ b/drivers/input/touchscreen/tsc2007.c
> @@ -26,6 +26,9 @@
>  #include <linux/interrupt.h>
>  #include <linux/i2c.h>
>  #include <linux/i2c/tsc2007.h>
> +#include <linux/of_device.h>
> +#include <linux/of.h>
> +#include <linux/of_gpio.h>
>  
>  #define TSC2007_MEASURE_TEMP0		(0x0 << 4)
>  #define TSC2007_MEASURE_AUX		(0x2 << 4)
> @@ -74,7 +77,10 @@ struct tsc2007 {
>  	u16			max_rt;
>  	unsigned long		poll_delay;
>  	unsigned long		poll_period;
> +	int			fuzzy;
> +	char			of;
>  
> +	unsigned		gpio;
>  	int			irq;
>  
>  	wait_queue_head_t	wait;
> @@ -84,6 +90,14 @@ struct tsc2007 {
>  	void			(*clear_penirq)(void);
>  };
>  
> +static int tsc2007_get_pendown_state_dt(struct tsc2007  *ts)
> +{
> +	if (ts->gpio >= 0)
> +		return !gpio_get_value(ts->gpio);
> +	else
> +		return true;
> +}
> +
>  static inline int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
>  {
>  	s32 data;
> @@ -158,6 +172,9 @@ static bool tsc2007_is_pen_down(struct tsc2007 *ts)
>  	 * to fall back on the pressure reading.
>  	 */
>  
> +	if (ts->of)
> +		return tsc2007_get_pendown_state_dt(ts);

Initializing tsc->gpio to an illegal gpio for the non dt case makes
ts->of unnecessary and the core driver dt agnostic.

> -static int tsc2007_probe(struct i2c_client *client,
> -				   const struct i2c_device_id *id)
> +#ifdef CONFIG_OF
> +static int tsc2007_probe_dt(struct i2c_client *client, struct tsc2007 *ts,
> +			    struct device_node *np)
>  {
> -	struct tsc2007 *ts;
> -	struct tsc2007_platform_data *pdata = client->dev.platform_data;
> -	struct input_dev *input_dev;
> -	int err;
> -
> -	if (!pdata) {
> -		dev_err(&client->dev, "platform data is required!\n");
> +	int err = 0;
> +	struct pinctrl *pinctrl;
> +	u32 val32;
> +	u64 val64;
> +
> +	if (!of_property_read_u32(np, "max-rt", &val32))
> +		ts->max_rt = val32;
> +	else
> +		ts->max_rt = MAX_12BIT;
> +
> +	if (!of_property_read_u32(np, "fuzzy", &val32))
> +		ts->fuzzy = val32;
> +
> +	if (!of_property_read_u64(np, "poll-period", &val64))
> +		ts->poll_period = val64;
> +	else
> +		ts->poll_period = 1;
> +
> +	if (!of_property_read_u32(np, "x-plate-ohms", &val32))
> +		ts->x_plate_ohms = val32;
> +	else {
> +		dev_err(&client->dev,
> +			"x-plate-ohms is not set up in the devicetree."
> +			" (err %d).", err);
>  		return -EINVAL;
>  	}

if one path of an if/else needs braces the other should have braces
aswell.

>  
> -	if (!i2c_check_functionality(client->adapter,
> -				     I2C_FUNC_SMBUS_READ_WORD_DATA))
> -		return -EIO;
> -
> -	ts = kzalloc(sizeof(struct tsc2007), GFP_KERNEL);
> -	input_dev = input_allocate_device();
> -	if (!ts || !input_dev) {
> -		err = -ENOMEM;
> -		goto err_free_mem;
> +	pinctrl = devm_pinctrl_get_select_default(&client->dev);
> +	if (IS_ERR(pinctrl)) {
> +		err = PTR_ERR(pinctrl);
> +		return err;

The driver core will do this for you already.

>  	}
>  
> -	ts->client = client;
> -	ts->irq = client->irq;
> -	ts->input = input_dev;
> -	init_waitqueue_head(&ts->wait);
> +	ts->gpio = of_get_gpio(np, 0);
> +	if (ts->gpio < 0)
> +		pr_err("GPIO not found (of_get_gpio returned %d)\n", ts->gpio);

use dev_err.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From gsi at denx.de  Mon Jul 15 17:46:01 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 15 Jul 2013 23:46:01 +0200
Subject: [PATCH v1 15/24] serial: mpc512x: OF clock lookup, use the 'mclk' name
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373924770-22599-1-git-send-email-gsi@denx.de>

with device tree based clock lookup, the MCLK name no longer
depends on the PSC index

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/tty/serial/mpc52xx_uart.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/mpc52xx_uart.c b/drivers/tty/serial/mpc52xx_uart.c
index 53c1093..221fb89 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -619,21 +619,17 @@ static irqreturn_t mpc512x_psc_handle_irq(struct uart_port *port)
 static int mpc512x_psc_clock(struct uart_port *port, int enable)
 {
 	struct clk *psc_clk;
-	int psc_num;
-	char clk_name[10];
 
 	if (uart_console(port))
 		return 0;
 
-	psc_num = (port->mapbase & 0xf00) >> 8;
-	snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
-	psc_clk = clk_get(port->dev, clk_name);
+	psc_clk = clk_get(port->dev, "mclk");
 	if (IS_ERR(psc_clk)) {
 		dev_err(port->dev, "Failed to get PSC clock entry!\n");
 		return -ENODEV;
 	}
 
-	dev_dbg(port->dev, "%s %sable\n", clk_name, enable ? "en" : "dis");
+	dev_dbg(port->dev, "mclk %sable\n", enable ? "en" : "dis");
 
 	if (enable)
 		clk_prepare_enable(psc_clk);
-- 
1.7.10.4



From s.hauer at pengutronix.de  Mon Jul 15 17:50:09 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 15 Jul 2013 23:50:09 +0200
Subject: [PATCH 21/22] DT: Add basic support for imx35-based devices.
In-Reply-To: <1373900227-341-22-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-22-git-send-email-denis@eukrea.com>
Message-ID: <20130715215009.GG10995@pengutronix.de>

On Mon, Jul 15, 2013 at 04:57:06PM +0200, Denis Carikli wrote:
> From: Steffen Trumtrar <s.trumtrar at pengutronix.de>
> 
> Signed-off-by: Steffen Trumtrar <s.trumtrar at pengutronix.de>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  arch/arm/boot/dts/imx35.dtsi         |  308 ++++++++++++++++++++++++++++++++++
>  arch/arm/configs/imx_v6_v7_defconfig |    1 +
>  arch/arm/mach-imx/Kconfig            |   11 ++
>  arch/arm/mach-imx/Makefile           |    1 +
>  arch/arm/mach-imx/clk-imx35.c        |   13 ++
>  arch/arm/mach-imx/imx35-dt.c         |   48 ++++++
>  6 files changed, 382 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx35.dtsi
>  create mode 100644 arch/arm/mach-imx/imx35-dt.c
> 
> diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
> new file mode 100644
> index 0000000..012c1a3
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx35.dtsi
> @@ -0,0 +1,308 @@
> +/*
> + * Copyright 2012 Steffen Trumtrar, Pengutronix
> + *
> + * based on imx27.dtsi
> + *
> + * This program is free software; you can redistribute it and/or modify it under
> + * the terms of the GNU General Public License version 2 as published by the
> + * Free Software Foundation.
> + */
> +
> +#include "skeleton.dtsi"
> +#include "imx35-pinfunc.h"
> +
> +/ {
> +	aliases {
> +		serial0 = &uart1;
> +		serial1 = &uart2;
> +		serial2 = &uart3;
> +		gpio0 = &gpio1;
> +		gpio1 = &gpio2;
> +		gpio2 = &gpio3;
> +	};
> +
> +	avic: avic-interrupt-controller at 68000000 {
> +		compatible = "fsl,imx35-avic", "fsl,avic";
> +		interrupt-controller;
> +		#interrupt-cells = <1>;
> +		reg = <0x68000000 0x10000000>;
> +	};
> +
> +	clocks {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		ckil {
> +			compatible = "fsl,imx-ckil", "fixed-clock";
> +			clock-frequency = <32768>;
> +		};
> +
> +		osc {
> +			compatible = "fsl,imx-osc", "fixed-clock";
> +			clock-frequency = <24000000>;
> +		};
> +	};
> +
> +	soc {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		compatible = "simple-bus";
> +		interrupt-parent = <&avic>;
> +		ranges;
> +
> +		l2-cache at 30000000 {
> +			compatible = "arm,l210-cache";
> +			reg = <0x30000000 0x1000>;
> +			cache-unified;
> +			cache-level = <2>;
> +		};
> +
> +		aips at 43f00000 { /* AIPS1 */

You could add a 'aips1:' label to make the comment unnecessary.

> +			iomuxc at 43fac000 {

Add a 'iomuxc:' label here.

> diff --git a/arch/arm/mach-imx/clk-imx35.c b/arch/arm/mach-imx/clk-imx35.c
> index 2193c83..b46375c 100644
> --- a/arch/arm/mach-imx/clk-imx35.c
> +++ b/arch/arm/mach-imx/clk-imx35.c
> @@ -204,7 +204,9 @@ int __init mx35_clocks_init(void)
>  				i, PTR_ERR(clk[i]));
>  
>  	clk_register_clkdev(clk[pata_gate], NULL, "pata_imx");
> +	clk_register_clkdev(clk[can1_gate], NULL, "53fe4000.can");
>  	clk_register_clkdev(clk[can1_gate], NULL, "flexcan.0");
> +	clk_register_clkdev(clk[can2_gate], NULL, "53fe8000.can");
>  	clk_register_clkdev(clk[can2_gate], NULL, "flexcan.1");
>  	clk_register_clkdev(clk[cspi1_gate], "per", "imx35-cspi.0");
>  	clk_register_clkdev(clk[cspi1_gate], "ipg", "imx35-cspi.0");
> @@ -221,12 +223,16 @@ int __init mx35_clocks_init(void)
>  	clk_register_clkdev(clk[esdhc3_gate], "per", "sdhci-esdhc-imx35.2");
>  	clk_register_clkdev(clk[ipg], "ipg", "sdhci-esdhc-imx35.2");
>  	clk_register_clkdev(clk[ahb], "ahb", "sdhci-esdhc-imx35.2");
> +	clk_register_clkdev(clk[fec_gate], NULL, "50038000.fec");
>  	/* i.mx35 has the i.mx27 type fec */
>  	clk_register_clkdev(clk[fec_gate], NULL, "imx27-fec.0");
>  	clk_register_clkdev(clk[gpt_gate], "per", "imx-gpt.0");
>  	clk_register_clkdev(clk[ipg], "ipg", "imx-gpt.0");
> +	clk_register_clkdev(clk[i2c1_gate], NULL, "43f80000.i2c");
>  	clk_register_clkdev(clk[i2c1_gate], NULL, "imx21-i2c.0");
> +	clk_register_clkdev(clk[i2c2_gate], NULL, "43f98000.i2c");
>  	clk_register_clkdev(clk[i2c2_gate], NULL, "imx21-i2c.1");
> +	clk_register_clkdev(clk[i2c3_gate], NULL, "43f84000.i2c");
>  	clk_register_clkdev(clk[i2c3_gate], NULL, "imx21-i2c.2");
>  	clk_register_clkdev(clk[ipu_gate], NULL, "ipu-core");
>  	clk_register_clkdev(clk[ipu_gate], NULL, "mx3_sdc_fb");
> @@ -235,6 +241,12 @@ int __init mx35_clocks_init(void)
>  	clk_register_clkdev(clk[sdma_gate], NULL, "imx35-sdma");
>  	clk_register_clkdev(clk[ssi1_gate], NULL, "imx-ssi.0");
>  	clk_register_clkdev(clk[ssi2_gate], NULL, "imx-ssi.1");
> +	clk_register_clkdev(clk[uart1_gate], "per", "43f90000.serial");
> +	clk_register_clkdev(clk[ipg], "ipg", "43f90000.serial");
> +	clk_register_clkdev(clk[uart2_gate], "per", "43f94000.serial");
> +	clk_register_clkdev(clk[ipg], "ipg", "43f94000.serial");
> +	clk_register_clkdev(clk[uart3_gate], "per", "5000c000.serial");
> +	clk_register_clkdev(clk[ipg], "ipg", "5000c000.serial");
>  	/* i.mx35 has the i.mx21 type uart */
>  	clk_register_clkdev(clk[uart1_gate], "per", "imx21-uart.0");
>  	clk_register_clkdev(clk[ipg], "ipg", "imx21-uart.0");
> @@ -255,6 +267,7 @@ int __init mx35_clocks_init(void)
>  	clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx27");
>  	clk_register_clkdev(clk[usbotg_gate], "ahb", "imx-udc-mx27");
>  	clk_register_clkdev(clk[wdog_gate], NULL, "imx2-wdt.0");
> +	clk_register_clkdev(clk[nfc_div], NULL, "bb000000.nand");

All the changes above shouldn't be necessary.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From s.hauer at pengutronix.de  Mon Jul 15 17:54:23 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 15 Jul 2013 23:54:23 +0200
Subject: [PATCH v1 15/24] serial: mpc512x: OF clock lookup, use the
 'mclk' name
In-Reply-To: <1373924770-22599-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1373924770-22599-1-git-send-email-gsi@denx.de>
Message-ID: <20130715215423.GU14452@pengutronix.de>

On Mon, Jul 15, 2013 at 11:46:01PM +0200, Gerhard Sittig wrote:
> with device tree based clock lookup, the MCLK name no longer
> depends on the PSC index
> 
> Signed-off-by: Gerhard Sittig <gsi at denx.de>
> ---
>  drivers/tty/serial/mpc52xx_uart.c |    8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/tty/serial/mpc52xx_uart.c b/drivers/tty/serial/mpc52xx_uart.c
> index 53c1093..221fb89 100644
> --- a/drivers/tty/serial/mpc52xx_uart.c
> +++ b/drivers/tty/serial/mpc52xx_uart.c
> @@ -619,21 +619,17 @@ static irqreturn_t mpc512x_psc_handle_irq(struct uart_port *port)
>  static int mpc512x_psc_clock(struct uart_port *port, int enable)
>  {
>  	struct clk *psc_clk;
> -	int psc_num;
> -	char clk_name[10];
>  
>  	if (uart_console(port))
>  		return 0;
>  
> -	psc_num = (port->mapbase & 0xf00) >> 8;
> -	snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
> -	psc_clk = clk_get(port->dev, clk_name);
> +	psc_clk = clk_get(port->dev, "mclk");

Same comment applies here as Mark made to the spi driver.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From akpm at linux-foundation.org  Mon Jul 15 18:03:42 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Mon, 15 Jul 2013 15:03:42 -0700
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130712075602.GA4002@gmail.com>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130712075602.GA4002@gmail.com>
Message-ID: <20130715150342.35f7620ffe0835e3e2bc37d0@linux-foundation.org>

On Fri, 12 Jul 2013 09:56:02 +0200 Ingo Molnar <mingo at kernel.org> wrote:

> 
> * Kyungsik Lee <kyungsik.lee at lge.com> wrote:
> >  quiet_cmd_lz4 = LZ4     $@
> >  cmd_lz4 = (cat $(filter-out FORCE,$^) | \
> > -	lz4demo -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
> > +	lz4c -l -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
> >  	(rm -f $@ ; false)
> 
> None of the major distros I tried has the lz4 or lz4c binary available, 
> and this breaks randconfig builds:
> 
>   /bin/sh: lz4c: command not found
> 
> If:
> 
>  CONFIG_HAVE_KERNEL_LZ4=y
>  CONFIG_KERNEL_LZ4=y
>  CONFIG_RD_LZ4=y
>  CONFIG_LZ4_DECOMPRESS=y
>  CONFIG_DECOMPRESS_LZ4=y
> 
> If a utility is not widely available yet and if the utility is not in the 
> kernel proper, could you please at least make sure that randconfig does 
> not stumble over non-buildable kernels?

I don't know how to do this.  Any suggestions?

It has to be done at `make config' time.  We'd need to probe for the
presence of lz4c and then....  what?

Is there any precedent for this?

I don't think we can just ignore the absence of lz4c - the user has
selected a config which his system cannot build.  The problem lies
within randconfig itself.


From robherring2 at gmail.com  Mon Jul 15 18:08:58 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 15 Jul 2013 17:08:58 -0500
Subject: [PATCH] ARM: Add check for Cortex-A15 errata 798181 ECO
In-Reply-To: <CAOesGMjATn9MCzazUGmbD44XR8HyJZU4cCvmOEoUZsmCgutPUg@mail.gmail.com>
References: <1373920943-18308-1-git-send-email-robherring2@gmail.com>
 <CAOesGMjATn9MCzazUGmbD44XR8HyJZU4cCvmOEoUZsmCgutPUg@mail.gmail.com>
Message-ID: <51E472FA.1080905@gmail.com>

On 07/15/2013 03:59 PM, Olof Johansson wrote:
> On Mon, Jul 15, 2013 at 1:42 PM, Rob Herring <robherring2 at gmail.com> wrote:
>> diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
>> index 9a52a07..7fd64b7 100644
>> --- a/arch/arm/kernel/smp_tlb.c
>> +++ b/arch/arm/kernel/smp_tlb.c
>> @@ -74,10 +74,21 @@ static inline void ipi_flush_bp_all(void *ignored)
>>  static int erratum_a15_798181(void)
>>  {
>>         unsigned int midr = read_cpuid_id();
>> +       unsigned int revidr;
>>
>>         /* Cortex-A15 r0p0..r3p2 affected */
>>         if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2)
>>                 return 0;
>> +
>> +       /* Check for Cortex A15 <= r3p2 with ECO fix */
>> +       revidr = read_cpuid(CPUID_REVIDR);
>> +       if ((revidr & 0x210) == 0x210)
>> +               return 0;
> 
> Reading and evaluating all this on every invalidate seems suboptimal.
> It should be possible to read just once and cache the result.

Yes, but I'm not sure it is so clear. 2 coproc reads may be faster than
a load potentially from memory. But then how much more code do we have
to fetch. How about something like this:

static int erratum_a15_798181(void)
{
	static int errata_fix_needed = -1;

	if (unlikely(errata_fix_needed == -1)) {
		unsigned int midr = read_cpuid_id();
		unsigned int revidr = read_cpuid(CPUID_REVIDR);

		/* Cortex-A15 r0p0..r3p2 w/o ECO fix affected */
		if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2 ||
		    (revidr & 0x210) == 0x210) {
			errata_fix_needed = 0;
			return 0;
		}
		if (revidr & 0x10)
			errata_fix_needed = 1;

		errata_fix_needed = 2;
	}

	if (errata_fix_needed)
		dummy_flush_tlb_a15_erratum();
	return (errata_fix_needed == 2) ? 1: 0;
}


> I would have had the same comment about the original patch, but ARM
> pushes those to Russell in secret so it wasn't on the list. :-)

And I would have commented that we need to handle ECO fixes...

Rob



From hpa at zytor.com  Mon Jul 15 18:08:20 2013
From: hpa at zytor.com (H. Peter Anvin)
Date: Mon, 15 Jul 2013 15:08:20 -0700
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130715150342.35f7620ffe0835e3e2bc37d0@linux-foundation.org>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130712075602.GA4002@gmail.com>
 <20130715150342.35f7620ffe0835e3e2bc37d0@linux-foundation.org>
Message-ID: <51E472D4.5060307@zytor.com>

On 07/15/2013 03:03 PM, Andrew Morton wrote:
> 
> I don't know how to do this.  Any suggestions?
> 
> It has to be done at `make config' time.  We'd need to probe for the
> presence of lz4c and then....  what?
> 
> Is there any precedent for this?
> 
> I don't think we can just ignore the absence of lz4c - the user has
> selected a config which his system cannot build.  The problem lies
> within randconfig itself.
> 

We keep running over the need to be able to have kconfig run tests on
the build system (for toolchain support or for optional tools needed);
running them in the Makefiles (i.e. at Kbuild time) is simply too late.

	-hpa



From akpm at linux-foundation.org  Mon Jul 15 18:16:12 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Mon, 15 Jul 2013 15:16:12 -0700
Subject: [PATCH, re-send] Always trap on BUG()
In-Reply-To: <201307051738.35930.arnd@arndb.de>
References: <201307051738.35930.arnd@arndb.de>
Message-ID: <20130715151612.9499c2b2ad40e88d183a4600@linux-foundation.org>

On Fri, 5 Jul 2013 17:38:35 +0200 Arnd Bergmann <arnd at arndb.de> wrote:

> I've run some size analyis using the ARM 'multi_v7_defconfig'
> and gcc-4.8, using various definitions for BUG() and BUG_ON(), to
> see how big the size improvement actually gets
> 
> 1. Baseline: normal bug plus CONFIG_BUG_VERBOSE
>    text    data     bss     dec     hex filename
> 3743196  224396  206812 4174404  3fb244 vmlinux-bugverbose
> 
> 2. disabling CONFIG_BUG_VERBOSE, saving 0.6%
> 3716920  224380  206812 4148112  3f4b90 vmlinux-nobugverbose
> 
> 3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.0%
> 3701076  224384  206812 4132272  3f0db0 vmlinux-bug-panicfunc
> 
> 3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.5%
> 3678884  224400  206812 4110096  3eb710 vmlinux-bug-panic
> 
> 4. #define BUG() unreachable(), saving 2.1%
> 3652636  224384  206812 4083832  3e5078 vmlinux-bug-unreachable
> 
> 5. as 4, plus #define BUG_ON(c) if(c) unreachable(), saving 2.2%
> 3651108  224380  206812 4082300  3e4a7c vmlinux-bugon-unreachable
> 
> 6. #define BUG() do{}while(0), saving 2.1%
> 3654264  224380  206812 4085456  3e56d0 vmlinux-nobug
> 
> 7. as 6, plus #define BUG_ON if(0 && (c)) unreachable, saving 2.2%
> 3648392  223996  206748 4079136  3e3e20 vmlinux-no-bugon
> 
> 8. my patch below, saving 1.8%
> 3666532  224380  206812 4097724  3e86bc obj-tmp/vmlinux
> 
> The gain of doing unreachable and letting the code run off whereever
> is minimal compared to the current state of doing nothing, but it
> avoids the warnings.
> 
> Same test using x86_defconfig:
> 
> 1. CONFIG_BUG=y, CONFIG_BUGVERBOSE=n
> 10797859        1395648 1175552 13369059         cbfee3 vmlinux-x86-bug
> 
> 2. CONFIG_BUG=n, saves 1.0%
> 10658553        1395584 1175552 13229689         c9de79 vmlinux-x86-nobug
> 
> 3. with my patch, saves 0.8%
> 10684186        1395584 1175552 13255322         ca429a vmlinux-x86-archbug
> 
> Getting 1-2% savings in kernel size seems absolutely worth keeping the
> option, but 0.2-0.4% left for getting reproducible behavior also seems
> worthwhile. The result in the patch below.
> 
> This basically loses any of the BUG() reporting, but leaves the
> logic to trap and kill the task in place when CONFIG_BUG is disabled.

um, nice changelog, but it didn't tell us what the patch actually does.

AFACIT it arranges for the kernel to execute the trap instruction even
when CONFIG_BUG=n?  Can't be bothered fully working it out, really.

It also makes mystery changes to WARN_ON() and WARN().  What are those?

Also, you say "it avoids the warnings".  To what warnings do you refer?
The ones which are already emitted by CONFIG_BUG=n, or new ones which
would have been added had this patch been implemented differently?

Finally, code-size decreases are nice, but what are the runtime effects
of this patch?

I've been thinking for a while that CONFIG_BUG=n is a pretty dumb thing
to do, and that maintaining it (and trying to fix the warnings it
produces) aren't worth the effort and that we should remove the whole
thing.  Perhaps your patch changes that calculus, dunno.  Please discuss.



From linux at arm.linux.org.uk  Mon Jul 15 18:22:26 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Jul 2013 23:22:26 +0100
Subject: [PATCH] ARM: Add check for Cortex-A15 errata 798181 ECO
In-Reply-To: <CAOesGMjATn9MCzazUGmbD44XR8HyJZU4cCvmOEoUZsmCgutPUg@mail.gmail.com>
References: <1373920943-18308-1-git-send-email-robherring2@gmail.com>
 <CAOesGMjATn9MCzazUGmbD44XR8HyJZU4cCvmOEoUZsmCgutPUg@mail.gmail.com>
Message-ID: <20130715222226.GX24642@n2100.arm.linux.org.uk>

On Mon, Jul 15, 2013 at 01:59:24PM -0700, Olof Johansson wrote:
> On Mon, Jul 15, 2013 at 1:42 PM, Rob Herring <robherring2 at gmail.com> wrote:
> > diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
> > index 9a52a07..7fd64b7 100644
> > --- a/arch/arm/kernel/smp_tlb.c
> > +++ b/arch/arm/kernel/smp_tlb.c
> > @@ -74,10 +74,21 @@ static inline void ipi_flush_bp_all(void *ignored)
> >  static int erratum_a15_798181(void)
> >  {
> >         unsigned int midr = read_cpuid_id();
> > +       unsigned int revidr;
> >
> >         /* Cortex-A15 r0p0..r3p2 affected */
> >         if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2)
> >                 return 0;
> > +
> > +       /* Check for Cortex A15 <= r3p2 with ECO fix */
> > +       revidr = read_cpuid(CPUID_REVIDR);
> > +       if ((revidr & 0x210) == 0x210)
> > +               return 0;
> 
> Reading and evaluating all this on every invalidate seems suboptimal.
> It should be possible to read just once and cache the result.
> 
> I would have had the same comment about the original patch, but ARM
> pushes those to Russell in secret so it wasn't on the list. :-)

For a single read, there's probably not much between reading the CP15
register and doing the tests, vs reading a bool from memory to decide
whether we need to do it.

For more than that (as the above patch is growing) it probably makes
sense to think about using a bool in memory now.


From linux at arm.linux.org.uk  Mon Jul 15 18:27:55 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Jul 2013 23:27:55 +0100
Subject: [PATCH, re-send] Always trap on BUG()
In-Reply-To: <20130715151612.9499c2b2ad40e88d183a4600@linux-foundation.org>
References: <201307051738.35930.arnd@arndb.de>
 <20130715151612.9499c2b2ad40e88d183a4600@linux-foundation.org>
Message-ID: <20130715222755.GY24642@n2100.arm.linux.org.uk>

On Mon, Jul 15, 2013 at 03:16:12PM -0700, Andrew Morton wrote:
> I've been thinking for a while that CONFIG_BUG=n is a pretty dumb thing
> to do, and that maintaining it (and trying to fix the warnings it
> produces) aren't worth the effort and that we should remove the whole
> thing.  Perhaps your patch changes that calculus, dunno.  Please discuss.

This isn't about introducing "CONFIG_BUG=n" - this is about making a
kernel with CONFIG_BUG=n build without producing tonnes and tonnes of
warnings, as it does today.  It makes building randconfig pretty
useless to find what could be more important warnings.

For example, this is a small extract from one such build log that
randconfig decided to set CONFIG_BUG to n:

fs/ext4/extents.c: In function 'ext4_inode_journal_mode':
fs/ext4/ext4_jbd2.h:415:1: warning: control reaches end of non-void function
fs/ext4/ext4_jbd2.c: In function 'ext4_inode_journal_mode':
fs/ext4/ext4_jbd2.h:415:1: warning: control reaches end of non-void function
fs/ext4/mballoc.c: In function 'ext4_inode_journal_mode':
fs/ext4/ext4_jbd2.h:415:1: warning: control reaches end of non-void function
fs/ext4/move_extent.c: In function 'ext4_inode_journal_mode':
fs/ext4/ext4_jbd2.h:415:1: warning: control reaches end of non-void function
fs/ext4/indirect.c: In function 'ext4_inode_journal_mode':
fs/ext4/ext4_jbd2.h:415:1: warning: control reaches end of non-void function
fs/ext4/inline.c: In function 'ext4_inode_journal_mode':
fs/ext4/ext4_jbd2.h:415:1: warning: control reaches end of non-void function
fs/ext4/acl.c: In function 'acl_by_type':
include/linux/posix_acl.h:108:1: warning: control reaches end of non-void function
fs/ext4/acl.c: In function 'ext4_get_acl':
fs/ext4/acl.c:150:6: warning: 'name_index' may be used uninitialized in this funtion


From hpa at zytor.com  Mon Jul 15 18:35:16 2013
From: hpa at zytor.com (H. Peter Anvin)
Date: Mon, 15 Jul 2013 15:35:16 -0700
Subject: [PATCH, re-send] Always trap on BUG()
In-Reply-To: <20130715222755.GY24642@n2100.arm.linux.org.uk>
References: <201307051738.35930.arnd@arndb.de>
 <20130715151612.9499c2b2ad40e88d183a4600@linux-foundation.org>
 <20130715222755.GY24642@n2100.arm.linux.org.uk>
Message-ID: <51E47924.9030005@zytor.com>

On 07/15/2013 03:27 PM, Russell King - ARM Linux wrote:
> On Mon, Jul 15, 2013 at 03:16:12PM -0700, Andrew Morton wrote:
>> I've been thinking for a while that CONFIG_BUG=n is a pretty dumb thing
>> to do, and that maintaining it (and trying to fix the warnings it
>> produces) aren't worth the effort and that we should remove the whole
>> thing.  Perhaps your patch changes that calculus, dunno.  Please discuss.
> 
> This isn't about introducing "CONFIG_BUG=n" - this is about making a
> kernel with CONFIG_BUG=n build without producing tonnes and tonnes of
> warnings, as it does today.  It makes building randconfig pretty
> useless to find what could be more important warnings.
> 

Well, there are three alternatives here, right:

1. We can use unreachable(), which means that the compiler can assume it
never happens.

2. We can trap without metadata.

3. We can trap with metadata (current CONFIG_BUG=y).

I am *guessing* this does 2, but it isn't clear.

	-hpa




From linux at arm.linux.org.uk  Mon Jul 15 18:47:59 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Jul 2013 23:47:59 +0100
Subject: [PATCH, re-send] Always trap on BUG()
In-Reply-To: <51E47924.9030005@zytor.com>
References: <201307051738.35930.arnd@arndb.de>
 <20130715151612.9499c2b2ad40e88d183a4600@linux-foundation.org>
 <20130715222755.GY24642@n2100.arm.linux.org.uk> <51E47924.9030005@zytor.com>
Message-ID: <20130715224759.GZ24642@n2100.arm.linux.org.uk>

On Mon, Jul 15, 2013 at 03:35:16PM -0700, H. Peter Anvin wrote:
> On 07/15/2013 03:27 PM, Russell King - ARM Linux wrote:
> > On Mon, Jul 15, 2013 at 03:16:12PM -0700, Andrew Morton wrote:
> >> I've been thinking for a while that CONFIG_BUG=n is a pretty dumb thing
> >> to do, and that maintaining it (and trying to fix the warnings it
> >> produces) aren't worth the effort and that we should remove the whole
> >> thing.  Perhaps your patch changes that calculus, dunno.  Please discuss.
> > 
> > This isn't about introducing "CONFIG_BUG=n" - this is about making a
> > kernel with CONFIG_BUG=n build without producing tonnes and tonnes of
> > warnings, as it does today.  It makes building randconfig pretty
> > useless to find what could be more important warnings.
> > 
> 
> Well, there are three alternatives here, right:

There's many more than three alternatives - some of them may not pass
your taste filter.

> 1. We can use unreachable(), which means that the compiler can assume it
> never happens.

Arnd tried that... see the commit message for the build results from
that.  Arnd included a whole boat-load of other solutions to this
problem and documented the build results there too.

What this actually means in reality is that you're giving permission for
the CPU to run off the end of a function and start executing whatever it
finds there - which could be literal tables.  That might cause some
memory to be corrupted but otherwise go by unnoticed until very much
later.

Infinite while loops on the other hand... probably a single instruction,
but if we're using a single instruction why not make it trap with an
exception anyway so that the system can panic() and maybe reboot without
needing to wait for the watchdog?

> 2. We can trap without metadata.
> 
> 3. We can trap with metadata (current CONFIG_BUG=y).
> 
> I am *guessing* this does 2, but it isn't clear.

That is what this paragraph in Arnd's mail conveys to me:

  This basically loses any of the BUG() reporting, but leaves the
  logic to trap and kill the task in place when CONFIG_BUG is disabled.


From swarren at wwwdotorg.org  Mon Jul 15 19:02:29 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 17:02:29 -0600
Subject: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property
In-Reply-To: <51E44ED9.9020807@gmail.com>
References: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
 <1373913629-32179-5-git-send-email-swarren@wwwdotorg.org>
 <51E44ED9.9020807@gmail.com>
Message-ID: <51E47F85.4050905@wwwdotorg.org>

On 07/15/2013 01:34 PM, Rob Herring wrote:
> On 07/15/2013 01:40 PM, Stephen Warren wrote:
>> From: Stephen Warren <swarren at nvidia.com>
>>
>> This property is no longer required by the GPIO binding. Remove it.
> 
> Won't this break compatibility with older kernel? It is one thing to
> deprecate, but removal is another. If the relevant maintainers don't
> care, then I guess it is fine.

Yes.

I had originally hoped this could sneak in late for 3.11, but I suppose
it's too late now. vf610.dtsi is a new file in 3.11 so has no legacy to
protect.

Admittedly, the #gpio-cells property was added into the SPEAr files in 3.10.


From swarren at wwwdotorg.org  Mon Jul 15 19:06:38 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 17:06:38 -0600
Subject: [PATCH V2 3/5] of: introduce of_parse_phandle_with_fixed_args
In-Reply-To: <51E44688.3050805@cogentembedded.com>
References: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
 <1373913629-32179-3-git-send-email-swarren@wwwdotorg.org>
 <51E44688.3050805@cogentembedded.com>
Message-ID: <51E4807E.3090505@wwwdotorg.org>

On 07/15/2013 12:59 PM, Sergei Shtylyov wrote:
> On 07/15/2013 10:40 PM, Stephen Warren wrote:
> 
>> From: Stephen Warren <swarren at nvidia.com>
> 
>> This is identical to of_parse_phandle_with_args(), except that the
>> number of argument cells is fixed, rather than being parsed out of the
>> node referenced by each phandle.

>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index 23e7073..ad799d9 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -1106,7 +1106,8 @@ EXPORT_SYMBOL(of_parse_phandle);
>>
>>   static int __of_parse_phandle_with_args(const struct device_node *np,
>>                       const char *list_name,
>> -                    const char *cells_name, int index,
>> +                    const char *cells_name,
>> +                    int cells_count, int index,
> 
>    The correct grammar would be 'cell_name' and 'cell_count' I think.

I guess I can see the argument for cell_count, but "cells_name" is named
based on the DT property named "gpio-cells", so "cells" seems correct
here (and is a pre-existing issue anyway).

I'll fix up cell_count and the brace issue locally, but hold off reposting.


From dinguyen at altera.com  Mon Jul 15 19:08:50 2013
From: dinguyen at altera.com (dinguyen at altera.com)
Date: Mon, 15 Jul 2013 18:08:50 -0500
Subject: [PATCH] phy: micrel: Add definitions for common Micrel PHY registers
Message-ID: <1373929730-28130-1-git-send-email-dinguyen@altera.com>

From: Dinh Nguyen <dinguyen at altera.com>

Add defines for common Micrel PHY setups so that other platforms
can use them. Update imx61 and sama5 hardware to use the micrel_phy.h
PHY defines.

Also add support for the KSZ9021RLRN PHY.

Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
Cc: David S. Miller <davem at davemloft.net>
Cc: Shawn Guo <shawn.guo at linaro.org>
CC: Andrew Victor <linux at maxim.org.za>
CC: Nicolas Ferre <nicolas.ferre at atmel.com>
CC: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
CC: Pavel Machek <pavel at denx.de>
---
 arch/arm/mach-at91/board-dt-sama5.c |   17 ++++++-----------
 arch/arm/mach-imx/mach-imx6q.c      |   13 ++++++++-----
 include/linux/micrel_phy.h          |    6 ++++++
 3 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-at91/board-dt-sama5.c b/arch/arm/mach-at91/board-dt-sama5.c
index ad95f6a..bf00d15 100644
--- a/arch/arm/mach-at91/board-dt-sama5.c
+++ b/arch/arm/mach-at91/board-dt-sama5.c
@@ -42,20 +42,15 @@ static int ksz9021rn_phy_fixup(struct phy_device *phy)
 {
 	int value;
 
-#define GMII_RCCPSR	260
-#define GMII_RRDPSR	261
-#define GMII_ERCR	11
-#define GMII_ERDWR	12
-
 	/* Set delay values */
-	value = GMII_RCCPSR | 0x8000;
-	phy_write(phy, GMII_ERCR, value);
+	value = MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW | 0x8000;
+	phy_write(phy, MICREL_KSZ9021_EXTREG_CTRL, value);
 	value = 0xF2F4;
-	phy_write(phy, GMII_ERDWR, value);
-	value = GMII_RRDPSR | 0x8000;
-	phy_write(phy, GMII_ERCR, value);
+	phy_write(phy, MICREL_KSZ9021_EXTREG_DATA_WRITE, value);
+	value = MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW | 0x8000;
+	phy_write(phy, MICREL_KSZ9021_EXTREG_CTRL, value);
 	value = 0x2222;
-	phy_write(phy, GMII_ERDWR, value);
+	phy_write(phy, MICREL_KSZ9021_EXTREG_DATA_WRITE, value);
 
 	return 0;
 }
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 7be13f8..c8d7814 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -103,13 +103,16 @@ static int ksz9021rn_phy_fixup(struct phy_device *phydev)
 {
 	if (IS_BUILTIN(CONFIG_PHYLIB)) {
 		/* min rx data delay */
-		phy_write(phydev, 0x0b, 0x8105);
-		phy_write(phydev, 0x0c, 0x0000);
+		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
+			0x8000 | MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW);
+		phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
 
 		/* max rx/tx clock delay, min rx/tx control delay */
-		phy_write(phydev, 0x0b, 0x8104);
-		phy_write(phydev, 0x0c, 0xf0f0);
-		phy_write(phydev, 0x0b, 0x104);
+		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
+			0x8000 | MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW);
+		phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0xf0f0);
+		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
+			MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW);
 	}
 
 	return 0;
diff --git a/include/linux/micrel_phy.h b/include/linux/micrel_phy.h
index 8752dbb..ad05ce6 100644
--- a/include/linux/micrel_phy.h
+++ b/include/linux/micrel_phy.h
@@ -17,6 +17,7 @@
 
 #define PHY_ID_KSZ8873MLL	0x000e7237
 #define PHY_ID_KSZ9021		0x00221610
+#define PHY_ID_KSZ9021RLRN	0x00221611
 #define PHY_ID_KS8737		0x00221720
 #define PHY_ID_KSZ8021		0x00221555
 #define PHY_ID_KSZ8031		0x00221556
@@ -35,4 +36,9 @@
 /* struct phy_device dev_flags definitions */
 #define MICREL_PHY_50MHZ_CLK	0x00000001
 
+#define MICREL_KSZ9021_EXTREG_CTRL	0xB
+#define MICREL_KSZ9021_EXTREG_DATA_WRITE	0xC
+#define MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW	0x104
+#define MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW	0x105
+
 #endif /* _MICREL_PHY_H */
-- 
1.7.9.5




From daniel.lezcano at linaro.org  Mon Jul 15 19:28:25 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 16 Jul 2013 01:28:25 +0200
Subject: pull request for cpuidle/arm
Message-ID: <51E48599.8000104@linaro.org>

The following changes since commit 68ba7add2f6e216227c3a3d225316987624b71c8:

Merge branch 'pm-cpufreq-next' into linux-next (2013-07-15 14:12:32 +0200)

are available in the git repository at:


git://git.linaro.org/people/dlezcano/linux.git cpuidle/arm-next

for you to fetch changes up to 6a814a059092c3934d13c19c34123827d0e1dc95:

ARM: ux500: cpuidle: Move ux500 cpuidle driver to drivers/cpuidle
(2013-07-16 00:55:05 +0200)

----------------------------------------------------------------
Daniel Lezcano (2):
ARM: davinci: cpuidle: Fix target residency
ARM: ux500: cpuidle: Move ux500 cpuidle driver to drivers/cpuidle

Linus Walleij (2):
ARM: ux500: cpuidle: Instantiate the driver from platform device
ARM: ux500: cpuidle: Remove pointless include

arch/arm/mach-davinci/cpuidle.c | 2 +-
arch/arm/mach-ux500/Makefile | 1 -
drivers/cpuidle/Kconfig.arm | 8 ++++++++
drivers/cpuidle/Makefile | 1 +
.../cpuidle.c => drivers/cpuidle/cpuidle-ux500.c | 19 +++++++++++--------
drivers/mfd/db8500-prcmu.c | 4 ++++
6 files changed, 25 insertions(+), 10 deletions(-)
rename arch/arm/mach-ux500/cpuidle.c => drivers/cpuidle/cpuidle-ux500.c
(90%)

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog




From ezequiel.garcia at free-electrons.com  Mon Jul 15 19:32:33 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 20:32:33 -0300
Subject: [PATCH 00/10] Orion Watchdog fixes
Message-ID: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>

This patchset introduces a bunch of fixes that removes the direct use of
the shared timer control register, and also removes the need to include
a mach-specific header.

With this changes the driver can be included in multiplatforms builds,
and in particular be used for the Armada 370/XP SoC.

I'm sending this early patchset mainly to discuss the possibility of
introducing this changes. As cleared stated in each patch, this series
breaks device-tree compatilibity by changing the meaning of the watchdog
node 'reg' property.

I'm aware of the implications of this, but I'm not sure how 'stable' the
Kirkwood DT is considered. So, given we're currently moving things around,
maybe there is still a chance to do this.

This patchset applies on top of Sebastian Hesselbarth's branch:

  git://github.com/shesselba/linux-dove.git orion-irqchip-for-v3.11_v4

Ezequiel Garcia (10):
  clocksource: orion: Add thread-safe API header
  watchdog: orion: Use thread-safe clocksource API
  watchdog: orion: Rename device-tree binding documentation
  watchdog: orion: Use the proper watchdog register
  watchdog: orion: Add a memory resource for RSTOUT register
  watchdog: orion: Update device-tree binding documentation
  watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
  watchdog: orion: Remove mach-specific unneeded header
  watchdog: orion: Use BIT()
  ARM: kirkwood: Fix the device-tree watchdog's node reg property

 .../watchdog/{marvel.txt => orion-wdt.txt}         |  8 ++--
 arch/arm/boot/dts/kirkwood.dtsi                    |  3 +-
 arch/arm/mach-kirkwood/include/mach/bridge-regs.h  |  2 +
 arch/arm/mach-orion5x/include/mach/bridge-regs.h   |  2 +
 arch/arm/plat-orion/common.c                       | 10 +++--
 drivers/watchdog/orion_wdt.c                       | 46 +++++++++-------------
 include/linux/time-orion.h                         |  7 ++++
 7 files changed, 42 insertions(+), 36 deletions(-)
 rename Documentation/devicetree/bindings/watchdog/{marvel.txt => orion-wdt.txt} (58%)
 create mode 100644 include/linux/time-orion.h

-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 19:32:34 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 20:32:34 -0300
Subject: [PATCH 01/10] clocksource: orion: Add thread-safe API header
In-Reply-To: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373931163-12670-2-git-send-email-ezequiel.garcia@free-electrons.com>

Add a header declaration to allow drivers (such as watchdog)
to access this exported API.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 include/linux/time-orion.h | 7 +++++++
 1 file changed, 7 insertions(+)
 create mode 100644 include/linux/time-orion.h

diff --git a/include/linux/time-orion.h b/include/linux/time-orion.h
new file mode 100644
index 0000000..c7e6458
--- /dev/null
+++ b/include/linux/time-orion.h
@@ -0,0 +1,7 @@
+
+#ifndef __TIME_ORION_H
+#define __TIME_ORION_H
+
+void orion_timer_ctrl_clrset(u32 clr, u32 set);
+
+#endif
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 19:32:35 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 20:32:35 -0300
Subject: [PATCH 02/10] watchdog: orion: Use thread-safe clocksource API
In-Reply-To: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373931163-12670-3-git-send-email-ezequiel.garcia@free-electrons.com>

The TIMER_CTRL register allows to control timer and watchdog counters,
so it's a register shared between the clocksource and the watchdog
drivers. In order to prevent race-conditions the clocksource driver
exposed a thread-safe API. Use the API.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/watchdog/orion_wdt.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index da57798..c0597f4 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -25,12 +25,12 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/of.h>
+#include <linux/time-orion.h>
 #include <mach/bridge-regs.h>
 
 /*
  * Watchdog timer block registers.
  */
-#define TIMER_CTRL		0x0000
 #define WDT_EN			0x0010
 #define WDT_VAL			0x0024
 
@@ -72,9 +72,7 @@ static int orion_wdt_start(struct watchdog_device *wdt_dev)
 	writel(reg, BRIDGE_CAUSE);
 
 	/* Enable watchdog timer */
-	reg = readl(wdt_reg + TIMER_CTRL);
-	reg |= WDT_EN;
-	writel(reg, wdt_reg + TIMER_CTRL);
+	orion_timer_ctrl_clrset(0, WDT_EN);
 
 	/* Enable reset on watchdog */
 	reg = readl(RSTOUTn_MASK);
@@ -97,9 +95,7 @@ static int orion_wdt_stop(struct watchdog_device *wdt_dev)
 	writel(reg, RSTOUTn_MASK);
 
 	/* Disable watchdog timer */
-	reg = readl(wdt_reg + TIMER_CTRL);
-	reg &= ~WDT_EN;
-	writel(reg, wdt_reg + TIMER_CTRL);
+	orion_timer_ctrl_clrset(WDT_EN, 0);
 
 	spin_unlock(&wdt_lock);
 	return 0;
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 19:32:36 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 20:32:36 -0300
Subject: [PATCH 03/10] watchdog: orion: Rename device-tree binding
 documentation
In-Reply-To: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373931163-12670-4-git-send-email-ezequiel.garcia@free-electrons.com>

Name this file to something a bit more judicious.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 Documentation/devicetree/bindings/watchdog/{marvel.txt => orion-wdt.txt} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/watchdog/{marvel.txt => orion-wdt.txt} (100%)

diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt b/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
similarity index 100%
rename from Documentation/devicetree/bindings/watchdog/marvel.txt
rename to Documentation/devicetree/bindings/watchdog/orion-wdt.txt
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 19:32:37 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 20:32:37 -0300
Subject: [PATCH 04/10] watchdog: orion: Use the proper watchdog register
In-Reply-To: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373931163-12670-5-git-send-email-ezequiel.garcia@free-electrons.com>

Until now the watchdog driver was using the timer control register
to access the watchdog counter register. This is not appropriate,
given the timer control register should be controlled by the clocksource
driver alone.

Fix this by passing the correct register address to the driver and making
direct use of it. Note that this breaks the current device-tree binding
compatibility since it changes the meaning of the 'reg' property.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/mach-kirkwood/include/mach/bridge-regs.h | 1 +
 arch/arm/mach-orion5x/include/mach/bridge-regs.h  | 1 +
 arch/arm/plat-orion/common.c                      | 2 +-
 drivers/watchdog/orion_wdt.c                      | 7 +++----
 4 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
index d4cbe5e..c3f361d 100644
--- a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
+++ b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
@@ -40,6 +40,7 @@
 
 #define TIMER_VIRT_BASE		(BRIDGE_VIRT_BASE + 0x0300)
 #define TIMER_PHYS_BASE		(BRIDGE_PHYS_BASE + 0x0300)
+#define WDT_PHYS_BASE		(BRIDGE_PHYS_BASE + 0x0324)
 
 #define L2_CONFIG_REG		(BRIDGE_VIRT_BASE + 0x0128)
 #define L2_WRITETHROUGH		0x00000010
diff --git a/arch/arm/mach-orion5x/include/mach/bridge-regs.h b/arch/arm/mach-orion5x/include/mach/bridge-regs.h
index 461fd69..aa35de3 100644
--- a/arch/arm/mach-orion5x/include/mach/bridge-regs.h
+++ b/arch/arm/mach-orion5x/include/mach/bridge-regs.h
@@ -36,4 +36,5 @@
 
 #define TIMER_VIRT_BASE		(ORION5X_BRIDGE_VIRT_BASE + 0x300)
 #define TIMER_PHYS_BASE		(ORION5X_BRIDGE_PHYS_BASE + 0x300)
+#define WDT_PHYS_BASE		(ORION5X_BRIDGE_PHYS_BASE + 0x324)
 #endif
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index c019b7a..77fac6c 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -595,7 +595,7 @@ void __init orion_spi_1_init(unsigned long mapbase)
  * Watchdog
  ****************************************************************************/
 static struct resource orion_wdt_resource =
-		DEFINE_RES_MEM(TIMER_PHYS_BASE, 0x28);
+		DEFINE_RES_MEM(WDT_PHYS_BASE, 0x04);
 
 static struct platform_device orion_wdt_device = {
 	.name		= "orion_wdt",
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index c0597f4..01bcf53 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -32,7 +32,6 @@
  * Watchdog timer block registers.
  */
 #define WDT_EN			0x0010
-#define WDT_VAL			0x0024
 
 #define WDT_MAX_CYCLE_COUNT	0xffffffff
 #define WDT_IN_USE		0
@@ -51,7 +50,7 @@ static int orion_wdt_ping(struct watchdog_device *wdt_dev)
 	spin_lock(&wdt_lock);
 
 	/* Reload watchdog duration */
-	writel(wdt_tclk * wdt_dev->timeout, wdt_reg + WDT_VAL);
+	writel(wdt_tclk * wdt_dev->timeout, wdt_reg);
 
 	spin_unlock(&wdt_lock);
 	return 0;
@@ -64,7 +63,7 @@ static int orion_wdt_start(struct watchdog_device *wdt_dev)
 	spin_lock(&wdt_lock);
 
 	/* Set watchdog duration */
-	writel(wdt_tclk * wdt_dev->timeout, wdt_reg + WDT_VAL);
+	writel(wdt_tclk * wdt_dev->timeout, wdt_reg);
 
 	/* Clear watchdog timer interrupt */
 	reg = readl(BRIDGE_CAUSE);
@@ -106,7 +105,7 @@ static unsigned int orion_wdt_get_timeleft(struct watchdog_device *wdt_dev)
 	unsigned int time_left;
 
 	spin_lock(&wdt_lock);
-	time_left = readl(wdt_reg + WDT_VAL) / wdt_tclk;
+	time_left = readl(wdt_reg) / wdt_tclk;
 	spin_unlock(&wdt_lock);
 
 	return time_left;
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 19:32:38 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 20:32:38 -0300
Subject: [PATCH 05/10] watchdog: orion: Add a memory resource for RSTOUT
 register
In-Reply-To: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373931163-12670-6-git-send-email-ezequiel.garcia@free-electrons.com>

Instead of accessing the RSTOUT register directly, this commit
adds a platform memory resource to map this register into the driver.

Note that by adding a required 2nd-cell for the reg property,
this change breaks the device-tree binding compatibility.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/mach-kirkwood/include/mach/bridge-regs.h |  1 +
 arch/arm/mach-orion5x/include/mach/bridge-regs.h  |  1 +
 arch/arm/plat-orion/common.c                      | 10 ++++++----
 drivers/watchdog/orion_wdt.c                      | 18 ++++++++++--------
 4 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
index c3f361d..dead75a 100644
--- a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
+++ b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
@@ -21,6 +21,7 @@
 #define CPU_RESET		0x00000002
 
 #define RSTOUTn_MASK		(BRIDGE_VIRT_BASE + 0x0108)
+#define RSTOUT_PHYS_BASE	(BRIDGE_PHYS_BASE + 0x0108)
 #define WDT_RESET_OUT_EN	0x00000002
 #define SOFT_RESET_OUT_EN	0x00000004
 
diff --git a/arch/arm/mach-orion5x/include/mach/bridge-regs.h b/arch/arm/mach-orion5x/include/mach/bridge-regs.h
index aa35de3..ccd91c9 100644
--- a/arch/arm/mach-orion5x/include/mach/bridge-regs.h
+++ b/arch/arm/mach-orion5x/include/mach/bridge-regs.h
@@ -18,6 +18,7 @@
 #define CPU_CTRL		(ORION5X_BRIDGE_VIRT_BASE + 0x104)
 
 #define RSTOUTn_MASK		(ORION5X_BRIDGE_VIRT_BASE + 0x108)
+#define RSTOUT_PHYS_BASE	(ORION5X_BRIDGE_PHYS_BASE + 0x108)
 #define WDT_RESET_OUT_EN	0x0002
 
 #define CPU_SOFT_RESET		(ORION5X_BRIDGE_VIRT_BASE + 0x10c)
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index 77fac6c..37924f8 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -594,14 +594,16 @@ void __init orion_spi_1_init(unsigned long mapbase)
 /*****************************************************************************
  * Watchdog
  ****************************************************************************/
-static struct resource orion_wdt_resource =
-		DEFINE_RES_MEM(WDT_PHYS_BASE, 0x04);
+static struct resource orion_wdt_resource[] = {
+		DEFINE_RES_MEM(WDT_PHYS_BASE, 0x04),
+		DEFINE_RES_MEM(RSTOUT_PHYS_BASE, 0x04)
+};
 
 static struct platform_device orion_wdt_device = {
 	.name		= "orion_wdt",
 	.id		= -1,
-	.num_resources	= 1,
-	.resource	= &orion_wdt_resource,
+	.num_resources	= ARRAY_SIZE(orion_wdt_resource),
+	.resource	= orion_wdt_resource,
 };
 
 void __init orion_wdt_init(void)
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 01bcf53..3c9b3d2 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -43,6 +43,7 @@ static unsigned int wdt_max_duration;	/* (seconds) */
 static struct clk *clk;
 static unsigned int wdt_tclk;
 static void __iomem *wdt_reg;
+static void __iomem *rstout_reg;
 static DEFINE_SPINLOCK(wdt_lock);
 
 static int orion_wdt_ping(struct watchdog_device *wdt_dev)
@@ -74,9 +75,7 @@ static int orion_wdt_start(struct watchdog_device *wdt_dev)
 	orion_timer_ctrl_clrset(0, WDT_EN);
 
 	/* Enable reset on watchdog */
-	reg = readl(RSTOUTn_MASK);
-	reg |= WDT_RESET_OUT_EN;
-	writel(reg, RSTOUTn_MASK);
+	writel(readl(rstout_reg) | WDT_RESET_OUT_EN, rstout_reg);
 
 	spin_unlock(&wdt_lock);
 	return 0;
@@ -84,14 +83,10 @@ static int orion_wdt_start(struct watchdog_device *wdt_dev)
 
 static int orion_wdt_stop(struct watchdog_device *wdt_dev)
 {
-	u32 reg;
-
 	spin_lock(&wdt_lock);
 
 	/* Disable reset on watchdog */
-	reg = readl(RSTOUTn_MASK);
-	reg &= ~WDT_RESET_OUT_EN;
-	writel(reg, RSTOUTn_MASK);
+	writel(readl(rstout_reg) & ~WDT_RESET_OUT_EN, rstout_reg);
 
 	/* Disable watchdog timer */
 	orion_timer_ctrl_clrset(WDT_EN, 0);
@@ -158,6 +153,13 @@ static int orion_wdt_probe(struct platform_device *pdev)
 	if (!wdt_reg)
 		return -ENOMEM;
 
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	if (!res)
+		return -ENODEV;
+	rstout_reg = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+	if (!rstout_reg)
+		return -ENOMEM;
+
 	wdt_max_duration = WDT_MAX_CYCLE_COUNT / wdt_tclk;
 
 	orion_wdt.timeout = wdt_max_duration;
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 19:32:39 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 20:32:39 -0300
Subject: [PATCH 06/10] watchdog: orion: Update device-tree binding
 documentation
In-Reply-To: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373931163-12670-7-git-send-email-ezequiel.garcia@free-electrons.com>

Now that the 'reg' property meaning has been changed,
this commit updates the deivce-tree binding documentation.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 Documentation/devicetree/bindings/watchdog/orion-wdt.txt | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/watchdog/orion-wdt.txt b/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
index 5dc8d30..48a71fc 100644
--- a/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
@@ -3,7 +3,8 @@
 Required Properties:
 
 - Compatibility : "marvell,orion-wdt"
-- reg		: Address of the timer registers
+- reg		: First cell contains the register for the watchdog counter.
+		  Second cell contains the register for the RSTOUT mask.
 
 Optional properties:
 
@@ -11,9 +12,10 @@ Optional properties:
 
 Example:
 
-	wdt at 20300 {
+	wdt at 20324 {
 		compatible = "marvell,orion-wdt";
-		reg = <0x20300 0x28>;
+		reg = <0x20324 0x4
+		       0x20108 0x4>;
 		timeout-sec = <10>;
 		status = "okay";
 	};
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 19:32:40 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 20:32:40 -0300
Subject: [PATCH 07/10] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
In-Reply-To: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373931163-12670-8-git-send-email-ezequiel.garcia@free-electrons.com>

With the introduction of the orion irqchip driver, now the BRIDGE_CAUSE
bit is cleared by it. There's no longer a need to do it in the watchdog
driver, so we can simply remove it.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/watchdog/orion_wdt.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 3c9b3d2..4a0ab47 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -59,18 +59,11 @@ static int orion_wdt_ping(struct watchdog_device *wdt_dev)
 
 static int orion_wdt_start(struct watchdog_device *wdt_dev)
 {
-	u32 reg;
-
 	spin_lock(&wdt_lock);
 
 	/* Set watchdog duration */
 	writel(wdt_tclk * wdt_dev->timeout, wdt_reg);
 
-	/* Clear watchdog timer interrupt */
-	reg = readl(BRIDGE_CAUSE);
-	reg &= ~WDT_INT_REQ;
-	writel(reg, BRIDGE_CAUSE);
-
 	/* Enable watchdog timer */
 	orion_timer_ctrl_clrset(0, WDT_EN);
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 19:32:41 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 20:32:41 -0300
Subject: [PATCH 08/10] watchdog: orion: Remove mach-specific unneeded header
In-Reply-To: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373931163-12670-9-git-send-email-ezequiel.garcia@free-electrons.com>

The mach/bridge-regs.h header is not needed anymore, so we can remove it.
This commit allows to use this driver on multiplatforms builds.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/watchdog/orion_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 4a0ab47..4ed7a74 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -26,12 +26,12 @@
 #include <linux/err.h>
 #include <linux/of.h>
 #include <linux/time-orion.h>
-#include <mach/bridge-regs.h>
 
 /*
  * Watchdog timer block registers.
  */
 #define WDT_EN			0x0010
+#define WDT_RESET_OUT_EN	0x0002
 
 #define WDT_MAX_CYCLE_COUNT	0xffffffff
 #define WDT_IN_USE		0
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 19:32:42 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 20:32:42 -0300
Subject: [PATCH 09/10] watchdog: orion: Use BIT()
In-Reply-To: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373931163-12670-10-git-send-email-ezequiel.garcia@free-electrons.com>

This is a purely cosmetic commit: we replace hardcoded values that
representing bits by BIT(), which is slightly more readable.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/watchdog/orion_wdt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 4ed7a74..ae64cec 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -30,8 +30,8 @@
 /*
  * Watchdog timer block registers.
  */
-#define WDT_EN			0x0010
-#define WDT_RESET_OUT_EN	0x0002
+#define WDT_EN			BIT(4)
+#define WDT_RESET_OUT_EN	BIT(1)
 
 #define WDT_MAX_CYCLE_COUNT	0xffffffff
 #define WDT_IN_USE		0
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Mon Jul 15 19:32:43 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 15 Jul 2013 20:32:43 -0300
Subject: [PATCH 10/10] ARM: kirkwood: Fix the device-tree watchdog's node reg
 property
In-Reply-To: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1373931163-12670-11-git-send-email-ezequiel.garcia@free-electrons.com>

The watchdog driver now needs two 'reg' property cells. The first one
is for the register containing the watchdog counter, while the second
one is for the RSTOUT register.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/kirkwood.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index ca296c3..0d74ee9 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -116,7 +116,8 @@
 
 		wdt: watchdog-timer at 20300 {
 			compatible = "marvell,orion-wdt";
-			reg = <0x20300 0x28>;
+			reg = <0x20324 0x04
+			       0x20108 0x04>;
 			interrupt-parent = <&bridge_intc>;
 			interrupts = <3>;
 			clocks = <&gate_clk 7>;
-- 
1.8.1.5



From weiyj.lk at gmail.com  Mon Jul 15 20:07:14 2013
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Tue, 16 Jul 2013 08:07:14 +0800
Subject: [PATCH] video: nuc900fb: fix to pass correct device identity to
 request_irq()
Message-ID: <CAPgLHd9CZ=VponJTbTGKTXVTdvMQM6_T+-RWuPMrk0WYZPbW1Q@mail.gmail.com>

The IRQ handler nuc900fb_irqhandler() use dev_id as a type of
struct nuc900fb_info *, so we should pass fbi as the device
identity to request_irq().

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
Was 'video: nuc900fb: fix to pass correct device identity to free_irq()'
---
 drivers/video/nuc900fb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
index 8c527e5..796e511 100644
--- a/drivers/video/nuc900fb.c
+++ b/drivers/video/nuc900fb.c
@@ -587,8 +587,7 @@ static int nuc900fb_probe(struct platform_device *pdev)
 	fbinfo->flags			= FBINFO_FLAG_DEFAULT;
 	fbinfo->pseudo_palette		= &fbi->pseudo_pal;
 
-	ret = request_irq(irq, nuc900fb_irqhandler, 0,
-			  pdev->name, fbinfo);
+	ret = request_irq(irq, nuc900fb_irqhandler, 0, pdev->name, fbi);
 	if (ret) {
 		dev_err(&pdev->dev, "cannot register irq handler %d -err %d\n",
 			irq, ret);




From shawn.guo at linaro.org  Mon Jul 15 20:11:22 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 08:11:22 +0800
Subject: [PATCH] phy: micrel: Add definitions for common Micrel PHY
 registers
In-Reply-To: <1373929730-28130-1-git-send-email-dinguyen@altera.com>
References: <1373929730-28130-1-git-send-email-dinguyen@altera.com>
Message-ID: <20130716001120.GE23589@S2101-09.ap.freescale.net>

On Mon, Jul 15, 2013 at 06:08:50PM -0500, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen at altera.com>
> 
> Add defines for common Micrel PHY setups so that other platforms
> can use them. Update imx61 and sama5 hardware to use the micrel_phy.h
> PHY defines.
> 
> Also add support for the KSZ9021RLRN PHY.
> 
> Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
> Cc: David S. Miller <davem at davemloft.net>
> Cc: Shawn Guo <shawn.guo at linaro.org>

Acked-by: Shawn Guo <shawn.guo at linaro.org>



From jg1.han at samsung.com  Mon Jul 15 20:49:12 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Tue, 16 Jul 2013 09:49:12 +0900
Subject: [PATCH 2/3] video: hx8357: Make IM pins optional
In-Reply-To: <1373902022-20439-3-git-send-email-maxime.ripard@free-electrons.com>
References: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
 <1373902022-20439-3-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <003501ce81be$4a945ed0$dfbd1c70$@samsung.com>

On Tuesday, July 16, 2013 12:27 AM, Maxime Ripard wrote:
> 
> The IM pins of the HX8357 controller are used to define the interface
> used to feed pixel stream to the LCD panel.
> 
> Most of the time, these pins are directly routed to either the ground or
> the VCC to set their values.
> 
> Remove the need to assign GPIOs to these pins when we are in such a case.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  drivers/video/backlight/hx8357.c | 52 +++++++++++++++++++++++-----------------
>  1 file changed, 30 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
> index a0482b5..ed94796 100644
> --- a/drivers/video/backlight/hx8357.c
> +++ b/drivers/video/backlight/hx8357.c
> @@ -76,6 +76,7 @@ struct hx8357_data {
>  	unsigned		reset;
>  	struct spi_device	*spi;
>  	int			state;
> +	bool			use_im_pins;
>  };
> 
>  static u8 hx8357_seq_power[] = {
> @@ -250,9 +251,11 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
>  	 * Set the interface selection pins to SPI mode, with three
>  	 * wires
>  	 */
> -	gpio_set_value_cansleep(lcd->im_pins[0], 1);
> -	gpio_set_value_cansleep(lcd->im_pins[1], 0);
> -	gpio_set_value_cansleep(lcd->im_pins[2], 1);
> +	if (lcd->use_im_pins) {
> +		gpio_set_value_cansleep(lcd->im_pins[0], 1);
> +		gpio_set_value_cansleep(lcd->im_pins[1], 0);
> +		gpio_set_value_cansleep(lcd->im_pins[2], 1);
> +	}
> 
>  	/* Reset the screen */
>  	gpio_set_value(lcd->reset, 1);
> @@ -424,26 +427,31 @@ static int hx8357_probe(struct spi_device *spi)
>  		return -EINVAL;
>  	}
> 
> -	for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
> -		lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
> -						"im-gpios", i);
> -		if (lcd->im_pins[i] == -EPROBE_DEFER) {
> -			dev_info(&spi->dev, "GPIO requested is not here yet, deferring the probe\n");
> -			return -EPROBE_DEFER;
> -		}
> -		if (!gpio_is_valid(lcd->im_pins[i])) {
> -			dev_err(&spi->dev, "Missing dt property: im-gpios\n");
> -			return -EINVAL;
> +	if (of_find_property(spi->dev.of_node, "im-gpios", NULL)) {
> +		lcd->use_im_pins = 1;
> +
> +		for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
> +			lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
> +							    "im-gpios", i);
> +			if (lcd->im_pins[i] == -EPROBE_DEFER) {
> +				dev_info(&spi->dev, "GPIO requested is not here yet, deferring the
> probe\n");
> +				return -EPROBE_DEFER;
> +			}
> +			if (!gpio_is_valid(lcd->im_pins[i])) {
> +				dev_err(&spi->dev, "Missing dt property: im-gpios\n");
> +				return -EINVAL;
> +			}
> +
> +			ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
> +						    GPIOF_OUT_INIT_LOW, "im_pins");

This makes a checkpatch warning such as 'WARNING: line over 80 characters'.
How about the following?

			ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
						GPIOF_OUT_INIT_LOW, "im_pins");

> +			if (ret) {
> +				dev_err(&spi->dev, "failed to request gpio %d: %d\n",
> +					lcd->im_pins[i], ret);
> +				return -EINVAL;
> +			}
>  		}
> -
> -		ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
> -					GPIOF_OUT_INIT_LOW, "im_pins");
> -		if (ret) {
> -			dev_err(&spi->dev, "failed to request gpio %d: %d\n",
> -				lcd->im_pins[i], ret);
> -			return -EINVAL;
> -		}
> -	}
> +	} else
> +		lcd->use_im_pins = 0;

According to the 'Documentation/CodingStyle', braces are necessary as below.

	} else {
		lcd->use_im_pins = 0;
	}


Others look good.
Acked-by: Jingoo Han <jg1.han at samsung.com>

Best regards,
Jingoo Han

> 
>  	lcdev = lcd_device_register("mxsfb", &spi->dev, lcd, &hx8357_ops);
>  	if (IS_ERR(lcdev)) {
> --
> 1.8.3.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From laurent.pinchart at ideasonboard.com  Mon Jul 15 21:10:45 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 16 Jul 2013 03:10:45 +0200
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <51E015E1.2090906@wwwdotorg.org>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <2172485.AZTjvkLGcM@avalon> <51E015E1.2090906@wwwdotorg.org>
Message-ID: <2883016.87pKJk9n0R@avalon>

Hi Stephen,

On Friday 12 July 2013 08:42:41 Stephen Warren wrote:
> On 07/12/2013 05:01 AM, Laurent Pinchart wrote:
> > On Thursday 11 July 2013 14:06:44 Stephen Warren wrote:
> >> On 07/11/2013 01:32 PM, Thierry Reding wrote:
> >>> On Thu, Jul 11, 2013 at 11:50:48AM -0600, Stephen Warren wrote:
> >>>> On 07/11/2013 09:36 AM, Thierry Reding wrote:
> >>>>> On Thu, Jul 11, 2013 at 04:37:48PM +0200, Laurent Pinchart
> >>>>> wrote: [...]
> >>>>> 
> >>>>>> diff --git
> >>>>>> a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> >>>>>> b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> >>>>>> index de0eaed..be09be4 100644 ---
> >>>>>> a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> >>>>>> +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> >>>>>> @@ -4,9 +4,9 @@ Required properties: - compatible: should be
> >>>>>> "atmel,tcb-pwm" - #pwm-cells: Should be 3.  The first cell
> >>>>>> specifies the per-chip index of the PWM to use, the second
> >>>>>> cell is the period in nanoseconds and -  bit 0 in the third
> >>>>>> cell is used to encode the polarity of PWM output. -  Set bit
> >>>>>> 0 of the third cell in PWM specifier to 1 for inverse
> >>>>>> polarity & -  set to 0 for normal polarity. +  the third cell
> >>>>>> is used to encode the polarity of PWM output. Set the +
> >>>>>> PWM_POLARITY_NORMAL flag for normal polarity or the
> >>>>>> PWM_POLARITY_INVERSED +  flag for inverted polarity. PWM
> >>>>>> flags are defined in <dt-bindings/pwm/pwm.h>. - tc-block: The
> >>>>>> Timer Counter block to use as a PWM chip.
> >>>>> 
> >>>>>> Example:
> >>>>> I'd prefer for the original text to stay in place and the reference to
> >>>>> the dt-bindings/pwm/pwm.h file to go below that block.
> >>>> 
> >>>> I disagree here. The whole point of creating header files for the
> >>>> constants in binding definitions was so that you wouldn't have to
> >>>> duplicate all the values into the binding definitions. Rather, you'd
> >>>> simply say "see <dt-bindings/xxx.h>".
> >>> 
> >>> But that's not something that this patch solves.
> >> 
> >> Well, if the comments I made on the patch re: that <linux/pwm.h> should
> >> simply #include <dt-bindings/pwm/pwm.h> instead of duplicating the
> >> constants, then yet this patch will solve that. There will be a single
> >> place where the constants are defined.
> > 
> > As explained in another reply, this would require replacing the enum with
> > an unsigned int. I can write a patch if we agree on this.
> > 
> >>> And it could be solved even in the absence of the header file defining
> >>> the symbolic constants. If all the standard flags that
> >>> dt-bindings/pwm/pwm.txt now specifies were to be listed in pwm.txt (they
> >>> actually are) then referring to that document as the canonical source
> >>> works equally well.
> >> 
> >> If that's all the happens, then there will still be duplication
> >> between pwm.txt and <linux/pwm.h>.
> > 
> > I've explicitly mentioned the flags in individual DT bindings to ease
> > adding new flags in the future. At the moment the defined flags are
> > either all supported or not used at all by drivers. If we later add a new
> > flag supported by a subset of drivers only the driver bindings should
> > list supported flags for each driver.
> > 
> > I'm fine with removing the explicit mentions of individual flags right now
> > and adding it back when needed if you think that's better.
> 
> I think the values for any common system-wide flags should be defined
> once in some system-wide place, and the values for any HW-specific
> values should be defined only in the documentation for that specific HW.
> You could try and avoid conflicts by either:
> 
> a) Allocating system-wide flags from bit 0 up, and HW-specific flags
> from bit 31 down.
> 
> or:
> 
> b) Using 1 cell for standard flags, and a separate cell for any
> HW-specific flags. Drivers can quite easily adapt to adding extra cells
> to #pwm-cells, thus making adding a HW-specific cell later
> backwards-compatible.

I wasn't referring to HW-specific flags, but rather to system-wide flags that 
might not be supported by all drivers. If we later add new system-wide flags I 
think the individual DT bindings should explicitly document which flags they 
support.

-- 
Regards,

Laurent Pinchart



From laurent.pinchart at ideasonboard.com  Mon Jul 15 21:16:48 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 16 Jul 2013 03:16:48 +0200
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <51E03F9C.2060903@wwwdotorg.org>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <20130712172441.GB9620@dhcp-172-17-186-34.nvidia.com>
 <51E03F9C.2060903@wwwdotorg.org>
Message-ID: <6105968.TjP9HSeA1l@avalon>

Hello,

On Friday 12 July 2013 11:40:44 Stephen Warren wrote:
> On 07/12/2013 11:24 AM, Thierry Reding wrote:
> > On Fri, Jul 12, 2013 at 08:40:07AM -0600, Stephen Warren wrote:
> >> On 07/12/2013 04:41 AM, Laurent Pinchart wrote:
> >>> Hi Stephen,
> > 
> > [...]
> > 
> >>> What about splitting it in three patches that
> >>> 
> >>> - add the include/dt-bindings/pwm/pwm.h header, and update
> >>> include/linux/pwm.h and
> >>> Documentation/devicetree/bindings/pwm/pwm.txt
> >>> 
> >>> - update the rest of the documentation
> >>> 
> >>> - update the .dts files
> >> 
> >> I think that sounds reasonable.
> > 
> > Shouldn't the addition of include/dt-bindings/pwm/pwm.h be separate from
> > its inclusion in include/linux/pwm.h so that it can be moved more easily
> > (cherry-picked) to a separate repository?
> 
> I'm fine with that being another separate patch. However, I doubt cherry-
> picking is an issue here; when the separate DT repo is created, it seems
> likely that someone will simply copy the latest files from the latest Linux
> kernel in order to populate the tree. cherry-picking probably won't work
> because:
> 
> a) I doubt that the DT binding/header additions have always been kept
> separate from kernel code changes in all of Linux's history.
> 
> b) I wouldn't be remotely surprised if the layout of the new repo was
> entirely different to the kernel source tree layout, so direct cherry-pick
> wouldn't work.
> 
> c) Not having a common git history would make adding a kernel remote into
> the DT repo rather odd.
> 
> (b) and (c)  would at leat require some kind of git filter operation rather
> than cherry-pick, and this issue could be solve in that filter definition.

I agree with the reasoning, so I'll implement the patch split scheme described 
above unless someone objects.

> >>>>> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> >>>>> 
> >>>>> enum pwm_polarity {
> >>>>> 
> >>>>> -	PWM_POLARITY_NORMAL, -	PWM_POLARITY_INVERSED, +
> >>>>> PWM_POLARITY_NORMAL = 0, +	PWM_POLARITY_INVERSED = 1,
> >>>>> 
> >>>>> };
> >>>> 
> >>>> Rather than manually editing that to ensure the enum matches the DT
> >>>> bindings header, the whole point of making a separate <dt-bindings/...>
> >>>> directory was that drivers could include the binding header files
> >>>> directly to avoid having to duplicate the constant definitions. Can't
> >>>> <linux/pwm.h> include <dt- bindings/pwm.h> and remove that enum?
> >>> 
> >>> We could do that, but we would then need to modify all drivers to
> >>> replace enum_pwm_polarity with unsigned int. Thierry, what's your
> >>> opinion on this ?
> >> 
> >> Or perhaps we could keep the enums around, but force the values to match
> >> the DT constants:
> >> 
> >> enum pwm_polarity { PWM_POLARITY_NORMAL = PWM_POLARITY_NORMAL,
> >> PWM_POLARITY_INVERTED = PWM_POLARITY_INVERTED, };
> >> 
> >> (although obviously you'd need to avoid the enum and DT constants having
> >> the same name).
> > 
> > I think I've seen stuff like the following done in a few header files to
> > keep compatibility between enums and defines.
> > 
> > enum foo { BAR, #define BAR BAR BAZ, #define BAZ BAZ };
> > 
> > Which, as I understand it, won't work in this case because DTC can only
> > cope with plain cpp files?
> 
> Yeah, dtc doesn't understand "enum", so you can't include an enum definition
> in a DT file. You have to share simple #define headers between DT and kernel
> code.
> 
> >> Although this brings up one point: let's say we support ACPI/..
> >> bindings in the future. The enum possibly can't match the binding
> >> values from every different kind of binding definition (DT, ACPI,
> >> ...) so perhaps rather than changing the enum definition in
> >> <linux/pwm.h>, what we should be doing is mapping between the
> >> different name-spaces in whatever of_xlate function exists for
> >> the PWM flags cell. That would be more flexible.
> > 
> > I'm not quite sure what exactly you are suggesting here. Can you
> > elaborate?
> 
> Suppose ACPI (or whatever else) starts representing PWM devices. Suppose the
> author isn't aware that DT exists, represents PWM devices and/or has already
> defined some PWM-related flags. So, ACPI picks bit 5 in some data value to
> represent inverted, rather than bit 0. Then, there is no way that all of [
> (a) DT binding PWM flags (b) ACPI PWM flags (c) Linux's enum foo ] can use
> the same values. Hence, some mapping is required between them.
> 
> The typical way to do this is to define an "of_xlate" function which
> converts from DT cell values to Linux-internal representation. Presumably if
> we added an ACPI parser, there'd be some equivalent for that.
> 
> So, what I'm arguing for is that of_pwm_simple_xlate() (or any other custom
> xlate function) should include both <dt-bindings/pwm/pwm.h> and
> <linux/pwm.h>, and contain explicit code to convert between the two name-
> spaces of flags definitions. Since those two name-spaces currently are 100%
> identical, presumably if the code is written in the right way, the compiler
> will actually just optimize it all away...

If ACPI (or any other source of device information) uses different numerical 
values for the flags we will need an xlate function. In the DT case we're 
designing bindings so we're free to pick the numerical values currently used 
by the kernel, and even use the same symbolic names. I'm however fine with 
renamed the #define's in dt-bindings/pwm/pwm.h. Does anyone have a preference 
regarding the names I should use ?

-- 
Regards,

Laurent Pinchart



From horms at verge.net.au  Mon Jul 15 21:20:41 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 16 Jul 2013 10:20:41 +0900
Subject: [PATCH] dmaengine: shdma: fix a build failure on platforms with
 no DMA support
In-Reply-To: <1373422152-29976-1-git-send-email-horms+renesas@verge.net.au>
References: <1373422152-29976-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130716012041.GA942@verge.net.au>

On Wed, Jul 10, 2013 at 11:09:12AM +0900, Simon Horman wrote:
> From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
> 
> On platforms with no support for the shdma dmaengine driver build is
> currently failing with
> 
> drivers/built-in.o: In function `sh_mobile_sdhi_probe':
> drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference to`shdma_chan_filter'
> 
> Fix the breakage by defining shdma_chan_filter to NULL in such
> configurations.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> [horms+renesas at verge.net.au: Apply change to shdma-base.h instead of sh_dma.h]
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> ---
>  include/linux/shdma-base.h | 4 ++++
>  1 file changed, 4 insertions(+)

> 
> Hi Vinod,
> 
> please consider this fix from Guennadi for v3.11 which I have rebased on top of
> next-20130709. It fixes a build problem on a number of shmobile defconfigs
> including bockw.

Ping.

Would it be appropriate for me to take this change through my tree?
It seems to resolve a regression in v3.11-rc1.

> diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
> index 382cf71..5b1c984 100644
> --- a/include/linux/shdma-base.h
> +++ b/include/linux/shdma-base.h
> @@ -124,6 +124,10 @@ void shdma_chan_remove(struct shdma_chan *schan);
>  int shdma_init(struct device *dev, struct shdma_dev *sdev,
>  		    int chan_num);
>  void shdma_cleanup(struct shdma_dev *sdev);
> +#if IS_ENABLED(CONFIG_SH_DMAE_BASE)
>  bool shdma_chan_filter(struct dma_chan *chan, void *arg);
> +#else
> +#define shdma_chan_filter NULL
> +#endif
>  
>  #endif
> -- 
> 1.8.2.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From shawn.guo at linaro.org  Mon Jul 15 21:22:11 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 09:22:11 +0800
Subject: [RFC PATCH 06/11] cpufreq: imx6q-cpufreq: remove device tree
 parsing for cpu nodes
In-Reply-To: <1373883732-26303-7-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1373883732-26303-7-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <20130716012209.GA28375@S2101-09.ap.freescale.net>

On Mon, Jul 15, 2013 at 11:22:07AM +0100, Sudeep.KarkadaNagesha at arm.com wrote:
> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> Now that the cpu device registration initialises the of_node(if available)
> appropriately for all the cpus, parsing here is redundant.
> 
> This patch removes all DT parsing and uses cpu->of_node instead.
> 
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Acked-by: Shawn Guo <shawn.guo at linaro.org>

> ---
>  arch/arm/mach-imx/mach-imx6q.c  | 3 +--
>  drivers/cpufreq/imx6q-cpufreq.c | 4 +---
>  2 files changed, 2 insertions(+), 5 deletions(-)



From shawn.guo at linaro.org  Mon Jul 15 21:26:01 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 09:26:01 +0800
Subject: [RFC PATCH 07/11] cpufreq: cpufreq-cpu0: remove device tree
 parsing for cpu nodes
In-Reply-To: <1373883732-26303-8-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1373883732-26303-8-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <20130716012559.GB28375@S2101-09.ap.freescale.net>

On Mon, Jul 15, 2013 at 11:22:08AM +0100, Sudeep.KarkadaNagesha at arm.com wrote:
> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> Now that the cpu device registration initialises the of_node(if available)
> appropriately for all the cpus, parsing here is redundant.
> 
> This patch removes all DT parsing and uses cpu->of_node instead.
> 
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Acked-by: Shawn Guo <shawn.guo at linaro.org>



From mcuos.com at gmail.com  Mon Jul 15 21:25:45 2013
From: mcuos.com at gmail.com (Wan ZongShun)
Date: Tue, 16 Jul 2013 09:25:45 +0800
Subject: [PATCH] video: nuc900fb: fix to pass correct device identity to
 request_irq()
In-Reply-To: <CAPgLHd9CZ=VponJTbTGKTXVTdvMQM6_T+-RWuPMrk0WYZPbW1Q@mail.gmail.com>
References: <CAPgLHd9CZ=VponJTbTGKTXVTdvMQM6_T+-RWuPMrk0WYZPbW1Q@mail.gmail.com>
Message-ID: <CAKT61h8v2mSHqdREgpvtuQAKC-4j3sKHtJ=c=6-YQdj=JUDyFg@mail.gmail.com>

2013/7/16 Wei Yongjun <weiyj.lk at gmail.com>:
> The IRQ handler nuc900fb_irqhandler() use dev_id as a type of
> struct nuc900fb_info *, so we should pass fbi as the device
> identity to request_irq().
>
> Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Acked-by: Wan Zongshun <mcuos.com at gmail.com>

Thanks!
Vincent Wan.

> ---
> Was 'video: nuc900fb: fix to pass correct device identity to free_irq()'
> ---
>  drivers/video/nuc900fb.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index 8c527e5..796e511 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -587,8 +587,7 @@ static int nuc900fb_probe(struct platform_device *pdev)
>         fbinfo->flags                   = FBINFO_FLAG_DEFAULT;
>         fbinfo->pseudo_palette          = &fbi->pseudo_pal;
>
> -       ret = request_irq(irq, nuc900fb_irqhandler, 0,
> -                         pdev->name, fbinfo);
> +       ret = request_irq(irq, nuc900fb_irqhandler, 0, pdev->name, fbi);
>         if (ret) {
>                 dev_err(&pdev->dev, "cannot register irq handler %d -err %d\n",
>                         irq, ret);
>
>



--
Wan ZongShun.
www.mcuos.com


From shawn.guo at linaro.org  Mon Jul 15 21:30:04 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 09:30:04 +0800
Subject: [PATCH 1/5] ARM: dts: imx23-evk: enable USB PHY and controller
In-Reply-To: <CAP9ODKpr82mMoxhiv=K70RKdn01b=ZM2J9E4vV-AM5nwXxUR+g@mail.gmail.com>
References: <1373898160-8460-1-git-send-email-otavio@ossystems.com.br>
 <CAOMZO5C_7nJ9RVYvuKJHP2u0mYY6P2UyGVA6OpPzqTnd7YXN2Q@mail.gmail.com>
 <CAP9ODKpr82mMoxhiv=K70RKdn01b=ZM2J9E4vV-AM5nwXxUR+g@mail.gmail.com>
Message-ID: <20130716013002.GC28375@S2101-09.ap.freescale.net>

On Mon, Jul 15, 2013 at 01:39:13PM -0300, Otavio Salvador wrote:
> On Mon, Jul 15, 2013 at 12:39 PM, Fabio Estevam <festevam at gmail.com> wrote:
> > Hi Otavio,
> >
> > On Mon, Jul 15, 2013 at 11:22 AM, Otavio Salvador
> > <otavio at ossystems.com.br> wrote:
> >> The i.MX23EVK board provides a USB port so the USB PHY and controller
> >> need to be enabled for it to be usable.
> >>
> >> Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
> >> ---
> >
> > You should have Cc'd Shawn Guo on this series.
> 
> Oh; thanks for fix my mistake. I am new to kernel development :-)

I'm on copy of patches 1, 3 and 4.  2 and 5 are missing?

Shawn



From jh80.chung at samsung.com  Mon Jul 15 21:36:22 2013
From: jh80.chung at samsung.com (Jaehoon Chung)
Date: Tue, 16 Jul 2013 10:36:22 +0900
Subject: [PATCH v3 3/5] mmc: dw_mmc: Add exynos resume_noirq callback to
 clear WAKEUP_INT
In-Reply-To: <1373470926-19314-4-git-send-email-dianders@chromium.org>
References: <1373411961-23812-1-git-send-email-dianders@chromium.org>
 <1373470926-19314-1-git-send-email-dianders@chromium.org>
 <1373470926-19314-4-git-send-email-dianders@chromium.org>
Message-ID: <51E4A396.7010202@samsung.com>

Hi Doug,

I think these patch-set didn't base on latest mmc-next.
If you can rebase on latest mmc-next, it's helpful to me for testing.

Best Regards,
Jaehoon Chung

On 07/11/2013 12:42 AM, Doug Anderson wrote:
> If the WAKEUP_INT is asserted at wakeup and not cleared, we'll end up
> looping around forever.  This has been seen to happen on exynos5420
> silicon despite the fact that we haven't enabled any wakeup events.
> 
> Signed-off-by: Doug Anderson <dianders at chromium.org>
> ---
> Changes in v3: None
> Changes in v2:
> - Use suspend_noirq as per James Hogan.
> 
>  drivers/mmc/host/dw_mmc-exynos.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
> index f013e7e..36b9620 100644
> --- a/drivers/mmc/host/dw_mmc-exynos.c
> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> @@ -30,6 +30,7 @@
>  #define SDMMC_CLKSEL_TIMING(x, y, z)	(SDMMC_CLKSEL_CCLK_SAMPLE(x) |	\
>  					SDMMC_CLKSEL_CCLK_DRIVE(y) |	\
>  					SDMMC_CLKSEL_CCLK_DIVIDER(z))
> +#define SDMMC_CLKSEL_WAKEUP_INT		BIT(11)
>  
>  #define SDMMC_CMD_USE_HOLD_REG		BIT(29)
>  
> @@ -102,6 +103,27 @@ static int dw_mci_exynos_setup_clock(struct dw_mci *host)
>  	return 0;
>  }
>  
> +/**
> + * dw_mci_exynos_resume_noirq - Exynos-specific resume code
> + *
> + * We have seen cases (at least on the exynos5420) where turning off the INT
> + * power rail during suspend will leave the WAKEUP_INT bit in the CLKSEL
> + * register asserted.  This bit is 1 to indicate that it fired and we can
> + * clear it by writing a 1 back.  Clear it to prevent interrupts from going off
> + * constantly.
> + */
> +
> +static int dw_mci_exynos_resume_noirq(struct dw_mci *host)
> +{
> +	u32 clksel;
> +
> +	clksel = mci_readl(host, CLKSEL);
> +	if (clksel & SDMMC_CLKSEL_WAKEUP_INT)
> +		mci_writel(host, CLKSEL, clksel);
> +
> +	return 0;
> +}
> +
>  static void dw_mci_exynos_prepare_command(struct dw_mci *host, u32 *cmdr)
>  {
>  	/*
> @@ -165,6 +187,7 @@ static const struct dw_mci_drv_data exynos_drv_data = {
>  	.caps			= exynos_dwmmc_caps,
>  	.init			= dw_mci_exynos_priv_init,
>  	.setup_clock		= dw_mci_exynos_setup_clock,
> +	.resume_noirq		= dw_mci_exynos_resume_noirq,
>  	.prepare_command	= dw_mci_exynos_prepare_command,
>  	.set_ios		= dw_mci_exynos_set_ios,
>  	.parse_dt		= dw_mci_exynos_parse_dt,
> 



From shawn.guo at linaro.org  Mon Jul 15 21:50:42 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 09:50:42 +0800
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20130716015038.GD28375@S2101-09.ap.freescale.net>

Hi Philipp,

On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
> This driver implements a reset controller device that toggle a gpio
> connected to a reset pin of a peripheral IC. The delay between assertion
> and de-assertion of the reset signal can be configured via device tree.
> 
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> Reviewed-by: Stephen Warren <swarren at nvidia.com>

I see this patch is very useful, as GPIOs are widely used to reset
components/devices on board.  But I do not find the patch in v3.11-rc1.
What's your plan about it?

Also, I'm wondering if we should register the driver a little bit
early.  Please see the following patch.  If it makes sense to you,
I can send the patch to you, or you can just quash it into yours.

Shawn

---8<--------

>From 2f8ce9e5d6525b98f3828b707458e83fabb39d50 Mon Sep 17 00:00:00 2001
From: Shawn Guo <shawn.guo at linaro.org>
Date: Sun, 14 Jul 2013 20:41:00 +0800
Subject: [PATCH] ENGR00269945: reset: register gpio-reset driver in
 arch_initcall

It's a little bit late to register gpio-reset driver at module_init
time, because gpio-reset provides reset control via gpio for other
devices which are mostly probed at module_init time too.  And it
becomes even worse, when the gpio comes from IO expander on I2C bus,
e.g. pca953x.  In that case, gpio-reset needs to be ready before I2C
bus driver which is generally ready at subsys_initcall time.  Let's
register gpio-reset driver in arch_initcall() to have it ready early
enough.

The defer probe mechanism is not used here, because a reset controller
driver should be reasonably registered early than other devices.  More
importantly, defer probe doe not help in some nasty cases, e.g. the
gpio-pca953x device itself needs a reset from gpio-reset driver to start
working.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/reset/gpio-reset.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
index 4f372f9..a7f214f 100644
--- a/drivers/reset/gpio-reset.c
+++ b/drivers/reset/gpio-reset.c
@@ -168,7 +168,17 @@ static struct platform_driver gpio_reset_driver = {
 	},
 };
 
-module_platform_driver(gpio_reset_driver);
+static int __init gpio_reset_init(void)
+{
+	return platform_driver_register(&gpio_reset_driver);
+}
+arch_initcall(gpio_reset_init);
+
+static void __exit gpio_reset_exit(void)
+{
+	platform_driver_unregister(&gpio_reset_driver);
+}
+module_exit(gpio_reset_exit);
 
 MODULE_AUTHOR("Philipp Zabel <p.zabel at pengutronix.de>");
 MODULE_DESCRIPTION("gpio reset controller");
-- 
1.7.9.5




From juha.lumme at gmail.com  Mon Jul 15 21:59:22 2013
From: juha.lumme at gmail.com (Juha Lumme)
Date: Tue, 16 Jul 2013 10:59:22 +0900
Subject: Can't get FIQ interrupt to work on i.mx233
Message-ID: <CAF-Ht3z3GQLwEWoB+UgOGepHfMFUD7pTRHfYWR9Ynk3rM4dD=Q@mail.gmail.com>

Hi,

I'm trying to get my head around FIQ's on imx233, with Maxime Ripard's
article at free electrons (
http://free-electrons.com/blog/fiq-handlers-in-the-arm-linux-kernel/ )
as my original inspiration.

Unfortunately, for some reason I'm unable to get similar results on my
board (Olimex olinuxino maxi), even though the cpu is very close to
his (he was using imx28).

Im working with 3.10 kernel (Freescales mainline), and I had to add
some code to drivers/irqchip/irq-mxs.c for mxs_icoll_set_irq_fiq. This
is the code I added:
http://codetidy.com/6195/

Maxime used timer 2 to trigger interrupts in his design, but it seems
that in imx233, timer 0 and 2 are being used by the kernel, so I chose
timer3 for my purpose.
According to the reference manual, the mx233 timer3 uses interrupt 31.

As a first step, I'm now just trying to trigger FIQ once, and in FIQ I
want to acknowledge the interrupt, and set GPIO state high.
My driver code looks like this:
http://codetidy.com/6194/

I have carried over a simple header file from 2.6 kernel, that has
register addresses defined, it can be seen here:
http://codetidy.com/6192/

In the driver I:
1. map memory areas for HW_PINCTRL_DOUT1 (to trigger GPIO)
HW_TIMROT_TIMCTRL3 (to initalize timer3 settings) HW_TIMROT_TIMCOUNT3
(setup the actual timer values) HW_ICOLL_INTERRUPT31 (directly access
interrupt 31 register)
2. Reserve and setup the GPIO 38 as output (the pin I want to
trigger), and initialize the timer3 settings.
3. Claim the FIQ, setup it's assembly handler, and pass mapped memory
pointers of HW_PINCTRL_DOUT1 (to trigger gpio) and HW_TIMROT_TIMCTRL3
(to acknowledge the interrupt bit) to the handler via pt_regs struct.
4. Call mxs_icoll_set_irq_fiq(irq) and enable_fiq(irq) to enable the IRQ/FIQ.

For now the assembly handler is only 6 instructions: http://codetidy.com/6193/
I first want to just clear the interrupt bit in HW_ICOLL_INTERRUPT31,
and then I write 0xFF to HW_PINCTRL_DOUT1

Now when I compile this driver to the kernel, I see during the boot
that driver is initialized, and from the register printouts I can see
that timer3 is initialized as I request.
When I cat /proc/interrupts, I can see that my FIQ handler appears installed:
# cat /proc/interrupts
           CPU0
 16:       2082         -  MXS Timer Tick
 17:          0         -  mxs-spi
 18:       2147         -  mxs-dma
118:          0         -  mxs-spi
119:          0         -  mxs-dma
120:          0         -  RTC alarm
124:          0         -  8006c000.serial
127:         76         -  uart-pl011
128:        258         -  ci13xxx_imx
FIQ:              beagle_fiq_handler
Err:          0

In user space, I made a simple register reading application, and when
I read HW_TIMROT_TIMCOUNT3, I can see that as requested first 16 bits
of the register (fixed count part), is set to 4096 (bit 12), and bits
16-31(running count part) vary all the time, so the timer appears
running.
Also, when I read HW_TIMROT_TIMCTRL3 in userspace, I can see that IRQ
bit (bit 15) is now set, implying that timer3 has decremented to 0.
This bit was not set during the initial driver loading. Now because of
this, I am assuming that my assembly handler is never called, since
the first task is to clear this bit:
lsl r11, r11, #15?
str r11, [r9, #BIT_CLR]

This is basically where I am now, I don't know why my FIQ handler is
never called, even though the IRQ bit is triggered in interrupt 31,
and my handler appears to be created.

I did try to do a bit of debugging in the IRQ setup part, and it seems
that when I call mxs_icoll_set_irq_fiq(31); in the function it calls
__raw_writel(BM_ICOLL_INTERRUPTn_FIQ_ENABLE, icoll_base +
HW_ICOLL_INTERRUPTn_SET(d->hwirq));
Now this d->hwirq is actually a value "8", not "31" as I thought it
should be ? Im not exactly sure though here.
Also enable_fiq(31) will use same irq_desc in kernel/irq/manage.c that
has incorrect (?) value for hwirq.. but, again, I'm not sure this is
the cause.

If in user-space I check the value in HW_ICOLL_INTERRUPT31 I do NOT
see the bit 4 (ENFIQ) set, it actually seems to be 0.
Should the HW_ICOLL_INTERRUPT31 have bits 2 (enable) and 4 (enfiq) set ?

Another difference with Maxime's code is that currently I do not have
definition for my "HW" (gpio pin) and driver in dts file, I have
hardcoded the values for now to the driver.

I wonder what I might be doing wrong now, and where I should look more
closer with this ? I'm a newbie with IRQ's and FIQ's, so please don't
hesitate to confirm even some simple stuff I might have overlooked..
Thank you for any advice,
Juha Lumme


From jg1.han at samsung.com  Mon Jul 15 22:04:09 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Tue, 16 Jul 2013 11:04:09 +0900
Subject: [PATCH 3/3] fb: backlight: HX8357: Add HX8369 support
In-Reply-To: <1373902022-20439-4-git-send-email-maxime.ripard@free-electrons.com>
References: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
 <1373902022-20439-4-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <003601ce81c8$c2573320$47059960$@samsung.com>

On Tuesday, July 16, 2013 12:27 AM, Maxime Ripard wrote:
> 
> From: Alexandre Belloni <alexandre.belloni at free-electrons.com>
> 
> Add support for the Himax HX8369 controller as it is quite similar to the
> hx8357.
> 
> Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Hi Maxime Ripard,

I reviewed this patch with Himax HX8369 datasheet.
I cannot find any problems. It looks good.

However, if possible, please add comment on huge delays such as
msleep(120), msleep(100), etc.


Acked-by: Jingoo Han <jg1.han at samsung.com>

Best regards,
Jingoo Han

> ---
>  drivers/video/backlight/hx8357.c | 203 ++++++++++++++++++++++++++++++++++++---
>  1 file changed, 188 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
> index ed94796..b035fab 100644
> --- a/drivers/video/backlight/hx8357.c
> +++ b/drivers/video/backlight/hx8357.c
> @@ -71,6 +71,18 @@
>  #define HX8357_SET_POWER_NORMAL		0xd2
>  #define HX8357_SET_PANEL_RELATED	0xe9
> 
> +#define HX8369_SET_DISPLAY_BRIGHTNESS		0x51
> +#define HX8369_WRITE_CABC_DISPLAY_VALUE		0x53
> +#define HX8369_WRITE_CABC_BRIGHT_CTRL		0x55
> +#define HX8369_WRITE_CABC_MIN_BRIGHTNESS	0x5e
> +#define HX8369_SET_POWER			0xb1
> +#define HX8369_SET_DISPLAY_MODE			0xb2
> +#define HX8369_SET_DISPLAY_WAVEFORM_CYC		0xb4
> +#define HX8369_SET_VCOM				0xb6
> +#define HX8369_SET_EXTENSION_COMMAND		0xb9
> +#define HX8369_SET_GIP				0xd5
> +#define HX8369_SET_GAMMA_CURVE_RELATED		0xe0
> +
>  struct hx8357_data {
>  	unsigned		im_pins[HX8357_NUM_IM_PINS];
>  	unsigned		reset;
> @@ -144,6 +156,61 @@ static u8 hx8357_seq_display_mode[] = {
>  	HX8357_SET_DISPLAY_MODE_RGB_INTERFACE,
>  };
> 
> +static u8 hx8369_seq_write_CABC_min_brightness[] = {
> +	HX8369_WRITE_CABC_MIN_BRIGHTNESS, 0x00,
> +};
> +
> +static u8 hx8369_seq_write_CABC_control[] = {
> +	HX8369_WRITE_CABC_DISPLAY_VALUE, 0x24,
> +};
> +
> +static u8 hx8369_seq_set_display_brightness[] = {
> +	HX8369_SET_DISPLAY_BRIGHTNESS, 0xFF,
> +};
> +
> +static u8 hx8369_seq_write_CABC_control_setting[] = {
> +	HX8369_WRITE_CABC_BRIGHT_CTRL, 0x02,
> +};
> +
> +static u8 hx8369_seq_extension_command[] = {
> +	HX8369_SET_EXTENSION_COMMAND, 0xff, 0x83, 0x69,
> +};
> +
> +static u8 hx8369_seq_display_related[] = {
> +	HX8369_SET_DISPLAY_MODE, 0x00, 0x2b, 0x03, 0x03, 0x70, 0x00,
> +	0xff, 0x00, 0x00, 0x00, 0x00, 0x03, 0x03, 0x00,	0x01,
> +};
> +
> +static u8 hx8369_seq_panel_waveform_cycle[] = {
> +	HX8369_SET_DISPLAY_WAVEFORM_CYC, 0x0a, 0x1d, 0x80, 0x06, 0x02,
> +};
> +
> +static u8 hx8369_seq_set_address_mode[] = {
> +	HX8357_SET_ADDRESS_MODE, 0x00,
> +};
> +
> +static u8 hx8369_seq_vcom[] = {
> +	HX8369_SET_VCOM, 0x3e, 0x3e,
> +};
> +
> +static u8 hx8369_seq_gip[] = {
> +	HX8369_SET_GIP, 0x00, 0x01, 0x03, 0x25, 0x01, 0x02, 0x28, 0x70,
> +	0x11, 0x13, 0x00, 0x00, 0x40, 0x26, 0x51, 0x37, 0x00, 0x00, 0x71,
> +	0x35, 0x60, 0x24, 0x07, 0x0f, 0x04, 0x04,
> +};
> +
> +static u8 hx8369_seq_power[] = {
> +	HX8369_SET_POWER, 0x01, 0x00, 0x34, 0x03, 0x00, 0x11, 0x11, 0x32,
> +	0x2f, 0x3f, 0x3f, 0x01, 0x3a, 0x01, 0xe6, 0xe6, 0xe6, 0xe6, 0xe6,
> +};
> +
> +static u8 hx8369_seq_gamma_curve_related[] = {
> +	HX8369_SET_GAMMA_CURVE_RELATED, 0x00, 0x0d, 0x19, 0x2f, 0x3b, 0x3d,
> +	0x2e, 0x4a, 0x08, 0x0e, 0x0f, 0x14, 0x16, 0x14, 0x14, 0x14, 0x1e,
> +	0x00, 0x0d, 0x19, 0x2f, 0x3b, 0x3d, 0x2e, 0x4a, 0x08, 0x0e, 0x0f,
> +	0x14, 0x16, 0x14, 0x14, 0x14, 0x1e,
> +};
> +
>  static int hx8357_spi_write_then_read(struct lcd_device *lcdev,
>  				u8 *txbuf, u16 txlen,
>  				u8 *rxbuf, u16 rxlen)
> @@ -242,6 +309,18 @@ static int hx8357_exit_standby(struct lcd_device *lcdev)
>  	return 0;
>  }
> 
> +static void hx8357_lcd_reset(struct lcd_device *lcdev)
> +{
> +	struct hx8357_data *lcd = lcd_get_data(lcdev);
> +
> +	gpio_set_value(lcd->reset, 1);
> +	usleep_range(10000, 12000);
> +	gpio_set_value(lcd->reset, 0);
> +	usleep_range(10000, 12000);
> +	gpio_set_value(lcd->reset, 1);
> +	msleep(120);
> +}
> +
>  static int hx8357_lcd_init(struct lcd_device *lcdev)
>  {
>  	struct hx8357_data *lcd = lcd_get_data(lcdev);
> @@ -257,14 +336,6 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
>  		gpio_set_value_cansleep(lcd->im_pins[2], 1);
>  	}
> 
> -	/* Reset the screen */
> -	gpio_set_value(lcd->reset, 1);
> -	usleep_range(10000, 12000);
> -	gpio_set_value(lcd->reset, 0);
> -	usleep_range(10000, 12000);
> -	gpio_set_value(lcd->reset, 1);
> -	msleep(120);
> -
>  	ret = hx8357_spi_write_array(lcdev, hx8357_seq_power,
>  				ARRAY_SIZE(hx8357_seq_power));
>  	if (ret < 0)
> @@ -359,6 +430,94 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
>  	return 0;
>  }
> 
> +static int hx8369_lcd_init(struct lcd_device *lcdev)
> +{
> +	int ret;
> +
> +	ret = hx8357_spi_write_array(lcdev, hx8369_seq_extension_command,
> +				ARRAY_SIZE(hx8369_seq_extension_command));
> +	if (ret < 0)
> +		return ret;
> +	usleep_range(10000, 12000);
> +
> +	ret = hx8357_spi_write_array(lcdev, hx8369_seq_display_related,
> +				ARRAY_SIZE(hx8369_seq_display_related));
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = hx8357_spi_write_array(lcdev, hx8369_seq_panel_waveform_cycle,
> +				ARRAY_SIZE(hx8369_seq_panel_waveform_cycle));
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = hx8357_spi_write_array(lcdev, hx8369_seq_set_address_mode,
> +				ARRAY_SIZE(hx8369_seq_set_address_mode));
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = hx8357_spi_write_array(lcdev, hx8369_seq_vcom,
> +				ARRAY_SIZE(hx8369_seq_vcom));
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = hx8357_spi_write_array(lcdev, hx8369_seq_gip,
> +				ARRAY_SIZE(hx8369_seq_gip));
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = hx8357_spi_write_array(lcdev, hx8369_seq_power,
> +				ARRAY_SIZE(hx8369_seq_power));
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = hx8357_spi_write_byte(lcdev, HX8357_EXIT_SLEEP_MODE);
> +	if (ret < 0)
> +		return ret;
> +
> +	msleep(120);
> +
> +	ret = hx8357_spi_write_array(lcdev, hx8369_seq_gamma_curve_related,
> +				ARRAY_SIZE(hx8369_seq_gamma_curve_related));
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = hx8357_spi_write_byte(lcdev, HX8357_EXIT_SLEEP_MODE);
> +	if (ret < 0)
> +		return ret;
> +	usleep_range(1000, 1200);
> +
> +	ret = hx8357_spi_write_array(lcdev, hx8369_seq_write_CABC_control,
> +				ARRAY_SIZE(hx8369_seq_write_CABC_control));
> +	if (ret < 0)
> +		return ret;
> +	usleep_range(10000, 12000);
> +
> +	ret = hx8357_spi_write_array(lcdev,
> +			hx8369_seq_write_CABC_control_setting,
> +			ARRAY_SIZE(hx8369_seq_write_CABC_control_setting));
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = hx8357_spi_write_array(lcdev,
> +			hx8369_seq_write_CABC_min_brightness,
> +			ARRAY_SIZE(hx8369_seq_write_CABC_min_brightness));
> +	if (ret < 0)
> +		return ret;
> +	usleep_range(10000, 12000);
> +
> +	ret = hx8357_spi_write_array(lcdev, hx8369_seq_set_display_brightness,
> +				ARRAY_SIZE(hx8369_seq_set_display_brightness));
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_ON);
> +	if (ret < 0)
> +		return ret;
> +	msleep(100);
> +
> +	return 0;
> +}
> +
>  #define POWER_IS_ON(pwr)	((pwr) <= FB_BLANK_NORMAL)
> 
>  static int hx8357_set_power(struct lcd_device *lcdev, int power)
> @@ -391,10 +550,24 @@ static struct lcd_ops hx8357_ops = {
>  	.get_power	= hx8357_get_power,
>  };
> 
> +static const struct of_device_id hx8357_dt_ids[] = {
> +	{
> +		.compatible = "himax,hx8357",
> +		.data = hx8357_lcd_init,
> +	},
> +	{
> +		.compatible = "himax,hx8369",
> +		.data = hx8369_lcd_init,
> +	},
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, hx8357_dt_ids);
> +
>  static int hx8357_probe(struct spi_device *spi)
>  {
>  	struct lcd_device *lcdev;
>  	struct hx8357_data *lcd;
> +	const struct of_device_id *match;
>  	int i, ret;
> 
>  	lcd = devm_kzalloc(&spi->dev, sizeof(*lcd), GFP_KERNEL);
> @@ -411,6 +584,10 @@ static int hx8357_probe(struct spi_device *spi)
> 
>  	lcd->spi = spi;
> 
> +	match = of_match_device(hx8357_dt_ids, &spi->dev);
> +	if (!match || !match->data)
> +		return -EINVAL;
> +
>  	lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0);
>  	if (!gpio_is_valid(lcd->reset)) {
>  		dev_err(&spi->dev, "Missing dt property: gpios-reset\n");
> @@ -460,7 +637,9 @@ static int hx8357_probe(struct spi_device *spi)
>  	}
>  	spi_set_drvdata(spi, lcdev);
> 
> -	ret = hx8357_lcd_init(lcdev);
> +	hx8357_lcd_reset(lcdev);
> +
> +	ret = ((int (*)(struct lcd_device *))match->data)(lcdev);
>  	if (ret) {
>  		dev_err(&spi->dev, "Couldn't initialize panel\n");
>  		goto init_error;
> @@ -483,12 +662,6 @@ static int hx8357_remove(struct spi_device *spi)
>  	return 0;
>  }
> 
> -static const struct of_device_id hx8357_dt_ids[] = {
> -	{ .compatible = "himax,hx8357" },
> -	{},
> -};
> -MODULE_DEVICE_TABLE(of, hx8357_dt_ids);
> -
>  static struct spi_driver hx8357_driver = {
>  	.probe  = hx8357_probe,
>  	.remove = hx8357_remove,
> --
> 1.8.3.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From peter.chen at freescale.com  Mon Jul 15 22:23:20 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Tue, 16 Jul 2013 10:23:20 +0800
Subject: [PATCH v2 1/1] ARM: imx: clk-pllv3: improve the timeout waiting method
Message-ID: <1373941400-32274-1-git-send-email-peter.chen@freescale.com>

There are two improvements for this commit:

- Add comparing pll lock condition after while loop. It can
fix potential fake timeout problem caused by the code is just
scheduled out before compare the timeout, and the time of
scheduling out are more than one jiffies.

- Move timeout assignment more close to compare the timeout.
It can reduce the possibility the code is scheduled out, and
the timeout can be more precise.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---

Changes for v2:
- Add more description for this improvement according to
Fabio's suggstion.
- Add comparsion after while loop according to Sascha's
suggestion.

 arch/arm/mach-imx/clk-pllv3.c |   15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/clk-pllv3.c b/arch/arm/mach-imx/clk-pllv3.c
index 36aac94..4499db5 100644
--- a/arch/arm/mach-imx/clk-pllv3.c
+++ b/arch/arm/mach-imx/clk-pllv3.c
@@ -50,7 +50,7 @@ struct clk_pllv3 {
 static int clk_pllv3_prepare(struct clk_hw *hw)
 {
 	struct clk_pllv3 *pll = to_clk_pllv3(hw);
-	unsigned long timeout = jiffies + msecs_to_jiffies(10);
+	unsigned long timeout;
 	u32 val;
 
 	val = readl_relaxed(pll->base);
@@ -61,12 +61,19 @@ static int clk_pllv3_prepare(struct clk_hw *hw)
 		val &= ~BM_PLL_POWER;
 	writel_relaxed(val, pll->base);
 
+	timeout = jiffies + msecs_to_jiffies(10);
 	/* Wait for PLL to lock */
-	while (!(readl_relaxed(pll->base) & BM_PLL_LOCK))
+	do {
+		if (readl_relaxed(pll->base) & BM_PLL_LOCK)
+			break;
 		if (time_after(jiffies, timeout))
-			return -ETIMEDOUT;
+			break;
+	} while (1);
 
-	return 0;
+	if (readl_relaxed(pll->base) & BM_PLL_LOCK)
+		return 0;
+	else
+		return -ETIMEDOUT;
 }
 
 static void clk_pllv3_unprepare(struct clk_hw *hw)
-- 
1.7.0.4




From elen.song at atmel.com  Mon Jul 15 22:43:39 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 16 Jul 2013 10:43:39 +0800
Subject: [PATCH V2 0/8] serial: at91: make usart and uart support dma transfer
Message-ID: <1373942627-7121-1-git-send-email-elen.song@atmel.com>

After at91sam9g45 socs, the usart only support dma transfer.
This patch serial focus on:
1) distinguish pdc and dma transfer
2) support usart dma rx and tx transfer
3) distinguish usart and uart
4) support uart dma rx and tx transfer

For those only support PDC transfer socs, we use "atmel,use-dma-rx/tx" to establish a PDC transfer.
For those only support DMA transfer socs, we not only use "atmel,use-dma-rx/tx", but also describe dma binding to establish a DMA transfer. 
We switch the name from "use-dma" to "use-pdc" in serial driver to state more clearly.
We also distinguish usart and uart by read ip name, the dbgu is regard as a uart.
Because uart lack timeout function, we use software timer to trigger rx.

Compare to v1, this patch serials improve:
1) use function pointer instead of if/else
2) "atmel,use-dma-rx/tx" represent a PDC transfer,
   but when add the dma bindings, it is a dma transfer
3) do not use strncmp in get ip name
4) remove modification in documentation part

Elen Song (7):
  serial: at91: correct definition from DMA to PDC
  serial: at91: add tx dma support
  serial: at91: add rx dma support
  serial: at91: make DBGU support dma and pdc transfers
  serial: at91: distinguish usart and uart
  serial: at91: modify UART to use software timer to trigger rx
  serial: at91: add dma support in usart binding descriptions

 Documentation/devicetree/bindings/serial/rs485.txt |    4 +-
 .../devicetree/bindings/tty/serial/atmel-usart.txt |   29 +-
 arch/arm/boot/dts/at91rm9200.dtsi                  |   16 +-
 arch/arm/boot/dts/at91sam9260.dtsi                 |   24 +-
 arch/arm/boot/dts/at91sam9263.dtsi                 |   12 +-
 arch/arm/boot/dts/at91sam9g45.dtsi                 |   16 +-
 arch/arm/mach-at91/at91rm9200_devices.c            |   20 +-
 arch/arm/mach-at91/at91sam9260_devices.c           |   28 +-
 arch/arm/mach-at91/at91sam9261_devices.c           |   16 +-
 arch/arm/mach-at91/at91sam9263_devices.c           |   16 +-
 arch/arm/mach-at91/at91sam9g45_devices.c           |   20 +-
 arch/arm/mach-at91/at91sam9rl_devices.c            |   20 +-
 drivers/tty/serial/atmel_serial.c                  |  582 ++++++++++++++++++--
 include/linux/atmel_serial.h                       |    2 +
 include/linux/platform_data/atmel.h                |    2 +
 15 files changed, 665 insertions(+), 142 deletions(-)

-- 
1.7.9.5



From elen.song at atmel.com  Mon Jul 15 22:43:40 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 16 Jul 2013 10:43:40 +0800
Subject: [PATCH V2 1/8] serial: at91: correct definition from DMA to PDC
In-Reply-To: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373942627-7121-2-git-send-email-elen.song@atmel.com>

The DMA is available since at91sam9x5 socs, before that, we use PDC.

Signed-off-by: Elen Song <elen.song at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |   71 +++++++++++++++++++------------------
 1 file changed, 36 insertions(+), 35 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 3467462..6c71ccf 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -140,11 +140,11 @@ struct atmel_uart_port {
 	u32			backup_imr;	/* IMR saved during suspend */
 	int			break_active;	/* break being received */
 
-	short			use_dma_rx;	/* enable PDC receiver */
+	short			use_pdc_rx;	/* enable PDC receiver */
 	short			pdc_rx_idx;	/* current PDC RX buffer */
 	struct atmel_dma_buffer	pdc_rx[2];	/* PDC receier */
 
-	short			use_dma_tx;	/* enable PDC transmitter */
+	short			use_pdc_tx;	/* enable PDC transmitter */
 	struct atmel_dma_buffer	pdc_tx;		/* PDC transmitter */
 
 	struct tasklet_struct	tasklet;
@@ -181,26 +181,26 @@ to_atmel_uart_port(struct uart_port *uart)
 }
 
 #ifdef CONFIG_SERIAL_ATMEL_PDC
-static bool atmel_use_dma_rx(struct uart_port *port)
+static bool atmel_use_pdc_rx(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	return atmel_port->use_dma_rx;
+	return atmel_port->use_pdc_rx;
 }
 
-static bool atmel_use_dma_tx(struct uart_port *port)
+static bool atmel_use_pdc_tx(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	return atmel_port->use_dma_tx;
+	return atmel_port->use_pdc_tx;
 }
 #else
-static bool atmel_use_dma_rx(struct uart_port *port)
+static bool atmel_use_pdc_rx(struct uart_port *port)
 {
 	return false;
 }
 
-static bool atmel_use_dma_tx(struct uart_port *port)
+static bool atmel_use_pdc_tx(struct uart_port *port)
 {
 	return false;
 }
@@ -233,7 +233,7 @@ void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
 		mode |= ATMEL_US_USMODE_RS485;
 	} else {
 		dev_dbg(port->dev, "Setting UART to RS232\n");
-		if (atmel_use_dma_tx(port))
+		if (atmel_use_pdc_tx(port))
 			atmel_port->tx_done_mask = ATMEL_US_ENDTX |
 				ATMEL_US_TXBUFE;
 		else
@@ -345,7 +345,7 @@ static void atmel_stop_tx(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		/* disable PDC transmit */
 		UART_PUT_PTCR(port, ATMEL_PDC_TXTDIS);
 	}
@@ -364,7 +364,7 @@ static void atmel_start_tx(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		if (UART_GET_PTSR(port) & ATMEL_PDC_TXTEN)
 			/* The transmitter is already running.  Yes, we
 			   really need this.*/
@@ -390,7 +390,7 @@ static void atmel_start_rx(struct uart_port *port)
 
 	UART_PUT_CR(port, ATMEL_US_RXEN);
 
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		/* enable PDC controller */
 		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
 			port->read_status_mask);
@@ -407,7 +407,7 @@ static void atmel_stop_rx(struct uart_port *port)
 {
 	UART_PUT_CR(port, ATMEL_US_RXDIS);
 
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		/* disable PDC receive */
 		UART_PUT_PTCR(port, ATMEL_PDC_RXTDIS);
 		UART_PUT_IDR(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
@@ -572,7 +572,7 @@ atmel_handle_receive(struct uart_port *port, unsigned int pending)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		/*
 		 * PDC receive. Just schedule the tasklet and let it
 		 * figure out the details.
@@ -661,7 +661,7 @@ static irqreturn_t atmel_interrupt(int irq, void *dev_id)
 /*
  * Called from tasklet with ENDTX and TXBUFE interrupts disabled.
  */
-static void atmel_tx_dma(struct uart_port *port)
+static void atmel_tx_pdc(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 	struct circ_buf *xmit = &port->state->xmit;
@@ -778,7 +778,7 @@ static void atmel_rx_from_ring(struct uart_port *port)
 	spin_lock(&port->lock);
 }
 
-static void atmel_rx_from_dma(struct uart_port *port)
+static void atmel_rx_from_pdc(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 	struct tty_port *tport = &port->state->port;
@@ -868,8 +868,8 @@ static void atmel_tasklet_func(unsigned long data)
 	/* The interrupt handler does not take the lock */
 	spin_lock(&port->lock);
 
-	if (atmel_use_dma_tx(port))
-		atmel_tx_dma(port);
+	if (atmel_use_pdc_tx(port))
+		atmel_tx_pdc(port);
 	else
 		atmel_tx_chars(port);
 
@@ -893,8 +893,8 @@ static void atmel_tasklet_func(unsigned long data)
 		atmel_port->irq_status_prev = status;
 	}
 
-	if (atmel_use_dma_rx(port))
-		atmel_rx_from_dma(port);
+	if (atmel_use_pdc_rx(port))
+		atmel_rx_from_pdc(port);
 	else
 		atmel_rx_from_ring(port);
 
@@ -930,7 +930,7 @@ static int atmel_startup(struct uart_port *port)
 	/*
 	 * Initialize DMA (if necessary)
 	 */
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		int i;
 
 		for (i = 0; i < 2; i++) {
@@ -964,7 +964,7 @@ static int atmel_startup(struct uart_port *port)
 		UART_PUT_RNPR(port, atmel_port->pdc_rx[1].dma_addr);
 		UART_PUT_RNCR(port, PDC_BUFFER_SIZE);
 	}
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
 		struct circ_buf *xmit = &port->state->xmit;
 
@@ -1000,7 +1000,7 @@ static int atmel_startup(struct uart_port *port)
 	/* enable xmit & rcvr */
 	UART_PUT_CR(port, ATMEL_US_TXEN | ATMEL_US_RXEN);
 
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		/* set UART timeout */
 		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
 		UART_PUT_CR(port, ATMEL_US_STTTO);
@@ -1031,7 +1031,7 @@ static void atmel_shutdown(struct uart_port *port)
 	/*
 	 * Shut-down the DMA.
 	 */
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		int i;
 
 		for (i = 0; i < 2; i++) {
@@ -1044,7 +1044,7 @@ static void atmel_shutdown(struct uart_port *port)
 			kfree(pdc->buf);
 		}
 	}
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
 
 		dma_unmap_single(port->dev,
@@ -1080,7 +1080,7 @@ static void atmel_flush_buffer(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		UART_PUT_TCR(port, 0);
 		atmel_port->pdc_tx.ofs = 0;
 	}
@@ -1193,7 +1193,7 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
 	if (termios->c_iflag & (BRKINT | PARMRK))
 		port->read_status_mask |= ATMEL_US_RXBRK;
 
-	if (atmel_use_dma_rx(port))
+	if (atmel_use_pdc_rx(port))
 		/* need to enable error interrupts */
 		UART_PUT_IER(port, port->read_status_mask);
 
@@ -1430,13 +1430,14 @@ static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
 
 	/* DMA/PDC usage specification */
 	if (of_get_property(np, "atmel,use-dma-rx", NULL))
-		atmel_port->use_dma_rx	= 1;
+		atmel_port->use_pdc_rx	= 1;
 	else
-		atmel_port->use_dma_rx	= 0;
+		atmel_port->use_pdc_rx	= 0;
+
 	if (of_get_property(np, "atmel,use-dma-tx", NULL))
-		atmel_port->use_dma_tx	= 1;
+		atmel_port->use_pdc_tx	= 1;
 	else
-		atmel_port->use_dma_tx	= 0;
+		atmel_port->use_pdc_tx	= 0;
 
 	/* rs485 properties */
 	if (of_property_read_u32_array(np, "rs485-rts-delay",
@@ -1467,8 +1468,8 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 	if (pdev->dev.of_node) {
 		atmel_of_init_port(atmel_port, pdev->dev.of_node);
 	} else {
-		atmel_port->use_dma_rx	= pdata->use_dma_rx;
-		atmel_port->use_dma_tx	= pdata->use_dma_tx;
+		atmel_port->use_pdc_rx	= pdata->use_dma_rx;
+		atmel_port->use_pdc_tx	= pdata->use_dma_tx;
 		atmel_port->rs485	= pdata->rs485;
 	}
 
@@ -1505,7 +1506,7 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 	/* Use TXEMPTY for interrupt when rs485 else TXRDY or ENDTX|TXBUFE */
 	if (atmel_port->rs485.flags & SER_RS485_ENABLED)
 		atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
-	else if (atmel_use_dma_tx(port)) {
+	else if (atmel_use_pdc_tx(port)) {
 		port->fifosize = PDC_BUFFER_SIZE;
 		atmel_port->tx_done_mask = ATMEL_US_ENDTX | ATMEL_US_TXBUFE;
 	} else {
@@ -1794,7 +1795,7 @@ static int atmel_serial_probe(struct platform_device *pdev)
 		goto err;
 	}
 
-	if (!atmel_use_dma_rx(&port->uart)) {
+	if (!atmel_use_pdc_rx(&port->uart)) {
 		ret = -ENOMEM;
 		data = kmalloc(sizeof(struct atmel_uart_char)
 				* ATMEL_SERIAL_RINGSIZE, GFP_KERNEL);
-- 
1.7.9.5



From elen.song at atmel.com  Mon Jul 15 22:43:41 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 16 Jul 2013 10:43:41 +0800
Subject: [PATCH V2 2/8] serial: at91: use function pointer to choose pdc or pio
In-Reply-To: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373942627-7121-3-git-send-email-elen.song@atmel.com>

use function pointer can avoid define atmel_use_pdc_tx/rx everywhere.
(*prepare_rx/tx)() is in setup transfer stage.
(*schedule_rx/tx)() is in tasklet schedule stage.
(*release_rx/tx)() is used when shutdown the transfer.

Signed-off-by: Elen Song <elen.song at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |  203 ++++++++++++++++++++++++-------------
 1 file changed, 130 insertions(+), 73 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 6c71ccf..2b0fe2e 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -155,6 +155,12 @@ struct atmel_uart_port {
 
 	struct serial_rs485	rs485;		/* rs485 settings */
 	unsigned int		tx_done_mask;
+	int (*prepare_rx)(struct uart_port *port);
+	int (*prepare_tx)(struct uart_port *port);
+	void (*schedule_rx)(struct uart_port *port);
+	void (*schedule_tx)(struct uart_port *port);
+	void (*release_rx)(struct uart_port *port);
+	void (*release_tx)(struct uart_port *port);
 };
 
 static struct atmel_uart_port atmel_ports[ATMEL_MAX_UART];
@@ -658,6 +664,17 @@ static irqreturn_t atmel_interrupt(int irq, void *dev_id)
 	return pass_counter ? IRQ_HANDLED : IRQ_NONE;
 }
 
+static void atmel_release_tx_pdc(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
+
+	dma_unmap_single(port->dev,
+			 pdc->dma_addr,
+			 pdc->dma_size,
+			 DMA_TO_DEVICE);
+}
+
 /*
  * Called from tasklet with ENDTX and TXBUFE interrupts disabled.
  */
@@ -710,6 +727,23 @@ static void atmel_tx_pdc(struct uart_port *port)
 		uart_write_wakeup(port);
 }
 
+static int atmel_prepare_tx_pdc(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
+	struct circ_buf *xmit = &port->state->xmit;
+
+	pdc->buf = xmit->buf;
+	pdc->dma_addr = dma_map_single(port->dev,
+					pdc->buf,
+					UART_XMIT_SIZE,
+					DMA_TO_DEVICE);
+	pdc->dma_size = UART_XMIT_SIZE;
+	pdc->ofs = 0;
+
+	return 0;
+}
+
 static void atmel_rx_from_ring(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
@@ -778,6 +812,22 @@ static void atmel_rx_from_ring(struct uart_port *port)
 	spin_lock(&port->lock);
 }
 
+static void atmel_release_rx_pdc(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	int i;
+
+	for (i = 0; i < 2; i++) {
+		struct atmel_dma_buffer *pdc = &atmel_port->pdc_rx[i];
+
+		dma_unmap_single(port->dev,
+				 pdc->dma_addr,
+				 pdc->dma_size,
+				 DMA_FROM_DEVICE);
+		kfree(pdc->buf);
+	}
+}
+
 static void atmel_rx_from_pdc(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
@@ -855,6 +905,45 @@ static void atmel_rx_from_pdc(struct uart_port *port)
 	UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
 }
 
+static int atmel_prepare_rx_pdc(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	int i;
+
+	for (i = 0; i < 2; i++) {
+		struct atmel_dma_buffer *pdc = &atmel_port->pdc_rx[i];
+
+		pdc->buf = kmalloc(PDC_BUFFER_SIZE, GFP_KERNEL);
+		if (pdc->buf == NULL) {
+			if (i != 0) {
+				dma_unmap_single(port->dev,
+					atmel_port->pdc_rx[0].dma_addr,
+					PDC_BUFFER_SIZE,
+					DMA_FROM_DEVICE);
+				kfree(atmel_port->pdc_rx[0].buf);
+			}
+			atmel_port->use_pdc_rx = 0;
+			return -ENOMEM;
+		}
+		pdc->dma_addr = dma_map_single(port->dev,
+						pdc->buf,
+						PDC_BUFFER_SIZE,
+						DMA_FROM_DEVICE);
+		pdc->dma_size = PDC_BUFFER_SIZE;
+		pdc->ofs = 0;
+	}
+
+	atmel_port->pdc_rx_idx = 0;
+
+	UART_PUT_RPR(port, atmel_port->pdc_rx[0].dma_addr);
+	UART_PUT_RCR(port, PDC_BUFFER_SIZE);
+
+	UART_PUT_RNPR(port, atmel_port->pdc_rx[1].dma_addr);
+	UART_PUT_RNCR(port, PDC_BUFFER_SIZE);
+
+	return 0;
+}
+
 /*
  * tasklet handling tty stuff outside the interrupt handler.
  */
@@ -868,10 +957,7 @@ static void atmel_tasklet_func(unsigned long data)
 	/* The interrupt handler does not take the lock */
 	spin_lock(&port->lock);
 
-	if (atmel_use_pdc_tx(port))
-		atmel_tx_pdc(port);
-	else
-		atmel_tx_chars(port);
+	atmel_port->schedule_tx(port);
 
 	status = atmel_port->irq_status;
 	status_change = status ^ atmel_port->irq_status_prev;
@@ -893,14 +979,36 @@ static void atmel_tasklet_func(unsigned long data)
 		atmel_port->irq_status_prev = status;
 	}
 
-	if (atmel_use_pdc_rx(port))
-		atmel_rx_from_pdc(port);
-	else
-		atmel_rx_from_ring(port);
+	atmel_port->schedule_rx(port);
 
 	spin_unlock(&port->lock);
 }
 
+static void atmel_set_ops(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+	if (atmel_use_pdc_rx(port)) {
+		atmel_port->prepare_rx = &atmel_prepare_rx_pdc;
+		atmel_port->schedule_rx = &atmel_rx_from_pdc;
+		atmel_port->release_rx = &atmel_release_rx_pdc;
+	} else {
+		atmel_port->prepare_rx = NULL;
+		atmel_port->schedule_rx = &atmel_rx_from_ring;
+		atmel_port->release_rx = NULL;
+	}
+
+	if (atmel_use_pdc_tx(port)) {
+		atmel_port->prepare_tx = &atmel_prepare_tx_pdc;
+		atmel_port->schedule_tx = &atmel_tx_pdc;
+		atmel_port->release_tx = &atmel_release_tx_pdc;
+	} else {
+		atmel_port->prepare_tx = NULL;
+		atmel_port->schedule_tx = &atmel_tx_chars;
+		atmel_port->release_tx = NULL;
+	}
+}
+
 /*
  * Perform initialization and enable port for reception
  */
@@ -930,53 +1038,17 @@ static int atmel_startup(struct uart_port *port)
 	/*
 	 * Initialize DMA (if necessary)
 	 */
-	if (atmel_use_pdc_rx(port)) {
-		int i;
-
-		for (i = 0; i < 2; i++) {
-			struct atmel_dma_buffer *pdc = &atmel_port->pdc_rx[i];
-
-			pdc->buf = kmalloc(PDC_BUFFER_SIZE, GFP_KERNEL);
-			if (pdc->buf == NULL) {
-				if (i != 0) {
-					dma_unmap_single(port->dev,
-						atmel_port->pdc_rx[0].dma_addr,
-						PDC_BUFFER_SIZE,
-						DMA_FROM_DEVICE);
-					kfree(atmel_port->pdc_rx[0].buf);
-				}
-				free_irq(port->irq, port);
-				return -ENOMEM;
-			}
-			pdc->dma_addr = dma_map_single(port->dev,
-						       pdc->buf,
-						       PDC_BUFFER_SIZE,
-						       DMA_FROM_DEVICE);
-			pdc->dma_size = PDC_BUFFER_SIZE;
-			pdc->ofs = 0;
-		}
-
-		atmel_port->pdc_rx_idx = 0;
-
-		UART_PUT_RPR(port, atmel_port->pdc_rx[0].dma_addr);
-		UART_PUT_RCR(port, PDC_BUFFER_SIZE);
-
-		UART_PUT_RNPR(port, atmel_port->pdc_rx[1].dma_addr);
-		UART_PUT_RNCR(port, PDC_BUFFER_SIZE);
+	if (atmel_port->prepare_rx) {
+		retval = atmel_port->prepare_rx(port);
+		if (retval < 0)
+			atmel_set_ops(port);
 	}
-	if (atmel_use_pdc_tx(port)) {
-		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
-		struct circ_buf *xmit = &port->state->xmit;
 
-		pdc->buf = xmit->buf;
-		pdc->dma_addr = dma_map_single(port->dev,
-					       pdc->buf,
-					       UART_XMIT_SIZE,
-					       DMA_TO_DEVICE);
-		pdc->dma_size = UART_XMIT_SIZE;
-		pdc->ofs = 0;
+	if (atmel_port->prepare_tx) {
+		retval = atmel_port->prepare_tx(port);
+		if (retval < 0)
+			atmel_set_ops(port);
 	}
-
 	/*
 	 * If there is a specific "open" function (to register
 	 * control line interrupts)
@@ -1031,27 +1103,10 @@ static void atmel_shutdown(struct uart_port *port)
 	/*
 	 * Shut-down the DMA.
 	 */
-	if (atmel_use_pdc_rx(port)) {
-		int i;
-
-		for (i = 0; i < 2; i++) {
-			struct atmel_dma_buffer *pdc = &atmel_port->pdc_rx[i];
-
-			dma_unmap_single(port->dev,
-					 pdc->dma_addr,
-					 pdc->dma_size,
-					 DMA_FROM_DEVICE);
-			kfree(pdc->buf);
-		}
-	}
-	if (atmel_use_pdc_tx(port)) {
-		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
-
-		dma_unmap_single(port->dev,
-				 pdc->dma_addr,
-				 pdc->dma_size,
-				 DMA_TO_DEVICE);
-	}
+	if (atmel_port->release_rx)
+		atmel_port->release_rx(port);
+	if (atmel_port->release_tx)
+		atmel_port->release_tx(port);
 
 	/*
 	 * Disable all interrupts, port and break condition.
@@ -1473,6 +1528,8 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 		atmel_port->rs485	= pdata->rs485;
 	}
 
+	atmel_set_ops(port);
+
 	port->iotype		= UPIO_MEM;
 	port->flags		= UPF_BOOT_AUTOCONF;
 	port->ops		= &atmel_pops;
-- 
1.7.9.5



From elen.song at atmel.com  Mon Jul 15 22:43:42 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 16 Jul 2013 10:43:42 +0800
Subject: [PATCH V3 3/8] serial: at91: add tx dma support
In-Reply-To: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373942627-7121-4-git-send-email-elen.song@atmel.com>

Request a slave dma channel for tx dma use. Tx dma will setup a single transfer,
when transfer complete, it will call atmel_complete_tx_dma to do finish stuff.

Signed-off-by: Elen Song <elen.song at atmel.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |  210 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 206 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 2b0fe2e..1176daa 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -144,9 +144,15 @@ struct atmel_uart_port {
 	short			pdc_rx_idx;	/* current PDC RX buffer */
 	struct atmel_dma_buffer	pdc_rx[2];	/* PDC receier */
 
+	short                   use_dma_tx;     /* enable DMA transmitter */
 	short			use_pdc_tx;	/* enable PDC transmitter */
 	struct atmel_dma_buffer	pdc_tx;		/* PDC transmitter */
 
+	spinlock_t			lock_tx;	/* port lock */
+	struct dma_chan			*chan_tx;
+	struct dma_async_tx_descriptor	*desc_tx;
+	dma_cookie_t			cookie_tx;
+	struct scatterlist		sg_tx;
 	struct tasklet_struct	tasklet;
 	unsigned int		irq_status;
 	unsigned int		irq_status_prev;
@@ -212,6 +218,13 @@ static bool atmel_use_pdc_tx(struct uart_port *port)
 }
 #endif
 
+static bool atmel_use_dma_tx(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+	return atmel_port->use_dma_tx;
+}
+
 /* Enable or disable the rs485 support */
 void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
 {
@@ -570,6 +583,182 @@ static void atmel_tx_chars(struct uart_port *port)
 		UART_PUT_IER(port, atmel_port->tx_done_mask);
 }
 
+static void atmel_complete_tx_dma(void *arg)
+{
+	struct atmel_uart_port *atmel_port = arg;
+	struct uart_port *port = &atmel_port->uart;
+	struct circ_buf *xmit = &port->state->xmit;
+	struct dma_chan *chan = atmel_port->chan_tx;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	if (chan)
+		dmaengine_terminate_all(chan);
+	xmit->tail += sg_dma_len(&atmel_port->sg_tx);
+	xmit->tail &= UART_XMIT_SIZE - 1;
+
+	port->icount.tx += sg_dma_len(&atmel_port->sg_tx);
+
+	spin_lock_irq(&atmel_port->lock_tx);
+	async_tx_ack(atmel_port->desc_tx);
+	atmel_port->cookie_tx = -EINVAL;
+	atmel_port->desc_tx = NULL;
+	spin_unlock_irq(&atmel_port->lock_tx);
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+
+	/* Do we really need this? */
+	if (!uart_circ_empty(xmit))
+		tasklet_schedule(&atmel_port->tasklet);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static void atmel_release_tx_dma(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct dma_chan *chan = atmel_port->chan_tx;
+
+	if (chan) {
+		dmaengine_terminate_all(chan);
+		dma_release_channel(chan);
+		dma_unmap_sg(port->dev, &atmel_port->sg_tx, 1,
+				DMA_MEM_TO_DEV);
+	}
+
+	atmel_port->desc_tx = NULL;
+	atmel_port->chan_tx = NULL;
+	atmel_port->cookie_tx = -EINVAL;
+}
+
+/*
+ * Called from tasklet with TXRDY interrupt is disabled.
+ */
+static void atmel_tx_dma(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct circ_buf *xmit = &port->state->xmit;
+	struct dma_chan *chan = atmel_port->chan_tx;
+	struct dma_async_tx_descriptor *desc;
+	struct scatterlist *sg = &atmel_port->sg_tx;
+
+	/* Make sure we have an idle channel */
+	if (atmel_port->desc_tx != NULL)
+		return;
+
+	if (!uart_circ_empty(xmit) && !uart_tx_stopped(port)) {
+		/*
+		 * DMA is idle now.
+		 * Port xmit buffer is already mapped,
+		 * and it is one page... Just adjust
+		 * offsets and lengths. Since it is a circular buffer,
+		 * we have to transmit till the end, and then the rest.
+		 * Take the port lock to get a
+		 * consistent xmit buffer state.
+		 */
+		sg->offset = xmit->tail & (UART_XMIT_SIZE - 1);
+		sg_dma_address(sg) = (sg_dma_address(sg) &
+					~(UART_XMIT_SIZE - 1))
+					+ sg->offset;
+		sg_dma_len(sg) = CIRC_CNT_TO_END(xmit->head,
+						xmit->tail,
+						UART_XMIT_SIZE);
+		BUG_ON(!sg_dma_len(sg));
+
+		desc = dmaengine_prep_slave_sg(chan,
+						sg,
+						1,
+						DMA_MEM_TO_DEV,
+						DMA_PREP_INTERRUPT |
+						DMA_CTRL_ACK);
+		if (!desc) {
+			dev_err(port->dev, "Failed to send via dma!\n");
+			return;
+		}
+
+		dma_sync_sg_for_device(port->dev, sg, 1, DMA_MEM_TO_DEV);
+
+		atmel_port->desc_tx = desc;
+		desc->callback = atmel_complete_tx_dma;
+		desc->callback_param = atmel_port;
+		atmel_port->cookie_tx = dmaengine_submit(desc);
+
+	} else {
+		if (atmel_port->rs485.flags & SER_RS485_ENABLED) {
+			/* DMA done, stop TX, start RX for RS485 */
+			atmel_start_rx(port);
+		}
+	}
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+}
+
+static int atmel_prepare_tx_dma(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	dma_cap_mask_t		mask;
+	struct dma_slave_config config;
+	int ret, nent;
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+
+	atmel_port->chan_tx = dma_request_slave_channel(port->dev, "tx");
+	if (atmel_port->chan_tx == NULL)
+		goto chan_err;
+	dev_info(port->dev, "using %s for tx DMA transfers\n",
+		dma_chan_name(atmel_port->chan_tx));
+
+	spin_lock_init(&atmel_port->lock_tx);
+	sg_init_table(&atmel_port->sg_tx, 1);
+	/* UART circular tx buffer is an aligned page. */
+	BUG_ON((int)port->state->xmit.buf & ~PAGE_MASK);
+	sg_set_page(&atmel_port->sg_tx,
+			virt_to_page(port->state->xmit.buf),
+			UART_XMIT_SIZE,
+			(int)port->state->xmit.buf & ~PAGE_MASK);
+	nent = dma_map_sg(port->dev,
+				&atmel_port->sg_tx,
+				1,
+				DMA_MEM_TO_DEV);
+
+	if (!nent) {
+		dev_dbg(port->dev, "need to release resource of dma\n");
+		goto chan_err;
+	} else {
+		dev_dbg(port->dev, "%s: mapped %d@%p to %x\n", __func__,
+			sg_dma_len(&atmel_port->sg_tx),
+			port->state->xmit.buf,
+			sg_dma_address(&atmel_port->sg_tx));
+	}
+
+	/* Configure the slave DMA */
+	memset(&config, 0, sizeof(config));
+	config.direction = DMA_MEM_TO_DEV;
+	config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	config.dst_addr = port->mapbase + ATMEL_US_THR;
+
+	ret = dmaengine_device_control(atmel_port->chan_tx,
+					DMA_SLAVE_CONFIG,
+					(unsigned long)&config);
+	if (ret) {
+		dev_err(port->dev, "DMA tx slave configuration failed\n");
+		goto chan_err;
+	}
+
+	return 0;
+
+chan_err:
+	dev_err(port->dev, "TX channel not available, switch to pio\n");
+	atmel_port->use_dma_tx = 0;
+	if (atmel_port->chan_tx)
+		atmel_release_tx_dma(port);
+	return -EINVAL;
+}
+
 /*
  * receive interrupt handler.
  */
@@ -998,7 +1187,11 @@ static void atmel_set_ops(struct uart_port *port)
 		atmel_port->release_rx = NULL;
 	}
 
-	if (atmel_use_pdc_tx(port)) {
+	if (atmel_use_dma_tx(port)) {
+		atmel_port->prepare_tx = &atmel_prepare_tx_dma;
+		atmel_port->schedule_tx = &atmel_tx_dma;
+		atmel_port->release_tx = &atmel_release_tx_dma;
+	} else if (atmel_use_pdc_tx(port)) {
 		atmel_port->prepare_tx = &atmel_prepare_tx_pdc;
 		atmel_port->schedule_tx = &atmel_tx_pdc;
 		atmel_port->release_tx = &atmel_release_tx_pdc;
@@ -1489,10 +1682,18 @@ static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
 	else
 		atmel_port->use_pdc_rx	= 0;
 
-	if (of_get_property(np, "atmel,use-dma-tx", NULL))
-		atmel_port->use_pdc_tx	= 1;
-	else
+	if (of_get_property(np, "atmel,use-dma-tx", NULL)) {
+		if (of_get_property(np, "dmas", NULL)) {
+			atmel_port->use_dma_tx	= 1;
+			atmel_port->use_pdc_tx	= 0;
+		} else {
+			atmel_port->use_dma_tx	= 0;
+			atmel_port->use_pdc_tx	= 1;
+		}
+	} else {
+		atmel_port->use_dma_tx	= 0;
 		atmel_port->use_pdc_tx	= 0;
+	}
 
 	/* rs485 properties */
 	if (of_property_read_u32_array(np, "rs485-rts-delay",
@@ -1525,6 +1726,7 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 	} else {
 		atmel_port->use_pdc_rx	= pdata->use_dma_rx;
 		atmel_port->use_pdc_tx	= pdata->use_dma_tx;
+		atmel_port->use_dma_tx	= 0;
 		atmel_port->rs485	= pdata->rs485;
 	}
 
-- 
1.7.9.5



From elen.song at atmel.com  Mon Jul 15 22:43:43 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 16 Jul 2013 10:43:43 +0800
Subject: [PATCH V2 4/8] serial: at91: add rx dma support
In-Reply-To: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373942627-7121-5-git-send-email-elen.song@atmel.com>

Request a cyclic dma channel for rx dma use. Use cyclic transfer is to prevent
receive data overrun.

We allocate a cycle dma cookie after request channel,
after that, enable uart timeout interrupt in startup stage, when data successful
received, the timeout callback will check the residual bytes and insert
receiving datas into the framework during the transfer interval.

When current descriptor finished, the dma callback will also check the residual
bytes and filp the receiving data.

Signed-off-by: Elen Song <elen.song at atmel.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |  224 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 220 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 1176daa..298b58c 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -140,6 +140,7 @@ struct atmel_uart_port {
 	u32			backup_imr;	/* IMR saved during suspend */
 	int			break_active;	/* break being received */
 
+	short			use_dma_rx;	/* enable DMA receiver */
 	short			use_pdc_rx;	/* enable PDC receiver */
 	short			pdc_rx_idx;	/* current PDC RX buffer */
 	struct atmel_dma_buffer	pdc_rx[2];	/* PDC receier */
@@ -149,10 +150,15 @@ struct atmel_uart_port {
 	struct atmel_dma_buffer	pdc_tx;		/* PDC transmitter */
 
 	spinlock_t			lock_tx;	/* port lock */
+	spinlock_t			lock_rx;	/* port lock */
 	struct dma_chan			*chan_tx;
+	struct dma_chan			*chan_rx;
 	struct dma_async_tx_descriptor	*desc_tx;
+	struct dma_async_tx_descriptor	*desc_rx;
 	dma_cookie_t			cookie_tx;
+	dma_cookie_t			cookie_rx;
 	struct scatterlist		sg_tx;
+	struct scatterlist		sg_rx;
 	struct tasklet_struct	tasklet;
 	unsigned int		irq_status;
 	unsigned int		irq_status_prev;
@@ -225,6 +231,13 @@ static bool atmel_use_dma_tx(struct uart_port *port)
 	return atmel_port->use_dma_tx;
 }
 
+static bool atmel_use_dma_rx(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+	return atmel_port->use_dma_rx;
+}
+
 /* Enable or disable the rs485 support */
 void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
 {
@@ -759,6 +772,184 @@ chan_err:
 	return -EINVAL;
 }
 
+static void atmel_flip_buffer_rx_dma(struct uart_port *port,
+					char *buf, size_t count)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct tty_port *tport = &port->state->port;
+
+	dma_sync_sg_for_cpu(port->dev,
+				&atmel_port->sg_rx,
+				1,
+				DMA_DEV_TO_MEM);
+
+	tty_insert_flip_string(tport, buf, count);
+
+	dma_sync_sg_for_device(port->dev,
+				&atmel_port->sg_rx,
+				1,
+				DMA_DEV_TO_MEM);
+	/*
+	 * Drop the lock here since it might end up calling
+	 * uart_start(), which takes the lock.
+	 */
+	spin_unlock(&port->lock);
+	tty_flip_buffer_push(tport);
+	spin_lock(&port->lock);
+}
+
+static void atmel_complete_rx_dma(void *arg)
+{
+	struct uart_port *port = arg;
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+	tasklet_schedule(&atmel_port->tasklet);
+}
+
+static void atmel_release_rx_dma(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct dma_chan *chan = atmel_port->chan_rx;
+
+	if (chan) {
+		dmaengine_terminate_all(chan);
+		dma_release_channel(chan);
+		dma_unmap_sg(port->dev, &atmel_port->sg_rx, 1,
+				DMA_DEV_TO_MEM);
+	}
+
+	atmel_port->desc_rx = NULL;
+	atmel_port->chan_rx = NULL;
+	atmel_port->cookie_rx = -EINVAL;
+}
+
+static void atmel_rx_from_dma(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct circ_buf *ring = &atmel_port->rx_ring;
+	struct dma_chan *chan = atmel_port->chan_rx;
+	struct dma_tx_state state;
+	enum dma_status dmastat;
+	size_t pending, count;
+
+
+	/* Reset the UART timeout early so that we don't miss one */
+	UART_PUT_CR(port, ATMEL_US_STTTO);
+	dmastat = dmaengine_tx_status(chan,
+				atmel_port->cookie_rx,
+				&state);
+	/* Restart a new tasklet if DMA status is error */
+	if (dmastat == DMA_ERROR) {
+		dev_dbg(port->dev, "Get residue error, restart tasklet\n");
+		UART_PUT_IER(port, ATMEL_US_TIMEOUT);
+		tasklet_schedule(&atmel_port->tasklet);
+		return;
+	}
+	/* current transfer size should no larger than dma buffer */
+	pending = sg_dma_len(&atmel_port->sg_rx) - state.residue;
+	BUG_ON(pending > sg_dma_len(&atmel_port->sg_rx));
+
+	/*
+	 * This will take the chars we have so far,
+	 * ring->head will record the transfer size, only new bytes come
+	 * will insert into the framework.
+	 */
+	if (pending > ring->head) {
+		count = pending - ring->head;
+
+		atmel_flip_buffer_rx_dma(port, ring->buf + ring->head, count);
+
+		ring->head += count;
+		if (ring->head == sg_dma_len(&atmel_port->sg_rx))
+			ring->head = 0;
+
+		port->icount.rx += count;
+	}
+
+	UART_PUT_IER(port, ATMEL_US_TIMEOUT);
+}
+
+static int atmel_prepare_rx_dma(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct dma_async_tx_descriptor *desc;
+	dma_cap_mask_t		mask;
+	struct dma_slave_config config;
+	struct circ_buf		*ring;
+	int ret, nent;
+
+	ring = &atmel_port->rx_ring;
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_CYCLIC, mask);
+
+	atmel_port->chan_rx = dma_request_slave_channel(port->dev, "rx");
+	if (atmel_port->chan_rx == NULL)
+		goto chan_err;
+	dev_info(port->dev, "using %s for rx DMA transfers\n",
+		dma_chan_name(atmel_port->chan_rx));
+
+	spin_lock_init(&atmel_port->lock_rx);
+	sg_init_table(&atmel_port->sg_rx, 1);
+	/* UART circular rx buffer is an aligned page. */
+	BUG_ON((int)port->state->xmit.buf & ~PAGE_MASK);
+	sg_set_page(&atmel_port->sg_rx,
+			virt_to_page(ring->buf),
+			ATMEL_SERIAL_RINGSIZE,
+			(int)ring->buf & ~PAGE_MASK);
+			nent = dma_map_sg(port->dev,
+					&atmel_port->sg_rx,
+					1,
+					DMA_DEV_TO_MEM);
+
+	if (!nent) {
+		dev_dbg(port->dev, "need to release resource of dma\n");
+		goto chan_err;
+	} else {
+		dev_dbg(port->dev, "%s: mapped %d@%p to %x\n", __func__,
+			sg_dma_len(&atmel_port->sg_rx),
+			ring->buf,
+			sg_dma_address(&atmel_port->sg_rx));
+	}
+
+	/* Configure the slave DMA */
+	memset(&config, 0, sizeof(config));
+	config.direction = DMA_DEV_TO_MEM;
+	config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	config.src_addr = port->mapbase + ATMEL_US_RHR;
+
+	ret = dmaengine_device_control(atmel_port->chan_rx,
+					DMA_SLAVE_CONFIG,
+					(unsigned long)&config);
+	if (ret) {
+		dev_err(port->dev, "DMA rx slave configuration failed\n");
+		goto chan_err;
+	}
+	/*
+	 * Prepare a cyclic dma transfer, assign 2 descriptors,
+	 * each one is half ring buffer size
+	 */
+	desc = dmaengine_prep_dma_cyclic(atmel_port->chan_rx,
+				sg_dma_address(&atmel_port->sg_rx),
+				sg_dma_len(&atmel_port->sg_rx),
+				sg_dma_len(&atmel_port->sg_rx)/2,
+				DMA_DEV_TO_MEM,
+				DMA_PREP_INTERRUPT);
+	desc->callback = atmel_complete_rx_dma;
+	desc->callback_param = port;
+	atmel_port->desc_rx = desc;
+	atmel_port->cookie_rx = dmaengine_submit(desc);
+
+	return 0;
+
+chan_err:
+	dev_err(port->dev, "RX channel not available, switch to pio\n");
+	atmel_port->use_dma_rx = 0;
+	if (atmel_port->chan_rx)
+		atmel_release_rx_dma(port);
+	return -EINVAL;
+}
+
 /*
  * receive interrupt handler.
  */
@@ -786,6 +977,13 @@ atmel_handle_receive(struct uart_port *port, unsigned int pending)
 			atmel_pdc_rxerr(port, pending);
 	}
 
+	if (atmel_use_dma_rx(port)) {
+		if (pending & ATMEL_US_TIMEOUT) {
+			UART_PUT_IDR(port, ATMEL_US_TIMEOUT);
+			tasklet_schedule(&atmel_port->tasklet);
+		}
+	}
+
 	/* Interrupt receive */
 	if (pending & ATMEL_US_RXRDY)
 		atmel_rx_chars(port);
@@ -1177,7 +1375,11 @@ static void atmel_set_ops(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_pdc_rx(port)) {
+	if (atmel_use_dma_rx(port)) {
+		atmel_port->prepare_rx = &atmel_prepare_rx_dma;
+		atmel_port->schedule_rx = &atmel_rx_from_dma;
+		atmel_port->release_rx = &atmel_release_rx_dma;
+	} else if (atmel_use_pdc_rx(port)) {
 		atmel_port->prepare_rx = &atmel_prepare_rx_pdc;
 		atmel_port->schedule_rx = &atmel_rx_from_pdc;
 		atmel_port->release_rx = &atmel_release_rx_pdc;
@@ -1273,6 +1475,11 @@ static int atmel_startup(struct uart_port *port)
 		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
 		/* enable PDC controller */
 		UART_PUT_PTCR(port, ATMEL_PDC_RXTEN);
+	} else if (atmel_use_dma_rx(port)) {
+		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
+		UART_PUT_CR(port, ATMEL_US_STTTO);
+
+		UART_PUT_IER(port, ATMEL_US_TIMEOUT);
 	} else {
 		/* enable receive only */
 		UART_PUT_IER(port, ATMEL_US_RXRDY);
@@ -1677,10 +1884,18 @@ static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
 	u32 rs485_delay[2];
 
 	/* DMA/PDC usage specification */
-	if (of_get_property(np, "atmel,use-dma-rx", NULL))
-		atmel_port->use_pdc_rx	= 1;
-	else
+	if (of_get_property(np, "atmel,use-dma-rx", NULL)) {
+		if (of_get_property(np, "dmas", NULL)) {
+			atmel_port->use_dma_rx	= 1;
+			atmel_port->use_pdc_rx	= 0;
+		} else {
+			atmel_port->use_dma_rx	= 0;
+			atmel_port->use_pdc_rx	= 1;
+		}
+	} else {
+		atmel_port->use_dma_rx	= 0;
 		atmel_port->use_pdc_rx	= 0;
+	}
 
 	if (of_get_property(np, "atmel,use-dma-tx", NULL)) {
 		if (of_get_property(np, "dmas", NULL)) {
@@ -1726,6 +1941,7 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 	} else {
 		atmel_port->use_pdc_rx	= pdata->use_dma_rx;
 		atmel_port->use_pdc_tx	= pdata->use_dma_tx;
+		atmel_port->use_dma_rx	= 0;
 		atmel_port->use_dma_tx	= 0;
 		atmel_port->rs485	= pdata->rs485;
 	}
-- 
1.7.9.5



From elen.song at atmel.com  Mon Jul 15 22:43:44 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 16 Jul 2013 10:43:44 +0800
Subject: [PATCH V2 5/8] serial: at91: support run time switch transfer mode
In-Reply-To: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373942627-7121-6-git-send-email-elen.song@atmel.com>

We will switch to pio mode when request of dma or pdc fail.
But soon or later, when the request is success, the transfer mode can switch to them at
next open serial port action.
So in startup stage, we should get original transfer mode.

Signed-off-by: Elen Song <elen.song at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |  139 +++++++++++++++++++++----------------
 1 file changed, 80 insertions(+), 59 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 298b58c..ad787fd1 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1371,6 +1371,80 @@ static void atmel_tasklet_func(unsigned long data)
 	spin_unlock(&port->lock);
 }
 
+static int atmel_init_property(struct atmel_uart_port *atmel_port,
+				struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct atmel_uart_data *pdata = pdev->dev.platform_data;
+
+	if (np) {
+		/* DMA/PDC usage specification */
+		if (of_get_property(np, "atmel,use-dma-rx", NULL)) {
+			if (of_get_property(np, "dmas", NULL)) {
+				atmel_port->use_dma_rx  = 1;
+				atmel_port->use_pdc_rx  = 0;
+			} else {
+				atmel_port->use_dma_rx  = 0;
+				atmel_port->use_pdc_rx  = 1;
+			}
+		} else {
+			atmel_port->use_dma_rx  = 0;
+			atmel_port->use_pdc_rx  = 0;
+		}
+
+		if (of_get_property(np, "atmel,use-dma-tx", NULL)) {
+			if (of_get_property(np, "dmas", NULL)) {
+				atmel_port->use_dma_tx  = 1;
+				atmel_port->use_pdc_tx  = 0;
+			} else {
+				atmel_port->use_dma_tx  = 0;
+				atmel_port->use_pdc_tx  = 1;
+			}
+		} else {
+			atmel_port->use_dma_tx  = 0;
+			atmel_port->use_pdc_tx  = 0;
+		}
+
+	} else {
+		atmel_port->use_pdc_rx  = pdata->use_dma_rx;
+		atmel_port->use_pdc_tx  = pdata->use_dma_tx;
+		atmel_port->use_dma_rx  = 0;
+		atmel_port->use_dma_tx  = 0;
+	}
+
+	return 0;
+}
+
+static void atmel_init_rs485(struct atmel_uart_port *atmel_port,
+				struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct atmel_uart_data *pdata = pdev->dev.platform_data;
+
+	if (np) {
+		u32 rs485_delay[2];
+		/* rs485 properties */
+		if (of_property_read_u32_array(np, "rs485-rts-delay",
+					rs485_delay, 2) == 0) {
+			struct serial_rs485 *rs485conf = &atmel_port->rs485;
+
+			rs485conf->delay_rts_before_send = rs485_delay[0];
+			rs485conf->delay_rts_after_send = rs485_delay[1];
+			rs485conf->flags = 0;
+
+		if (of_get_property(np, "rs485-rx-during-tx", NULL))
+			rs485conf->flags |= SER_RS485_RX_DURING_TX;
+
+		if (of_get_property(np, "linux,rs485-enabled-at-boot-time",
+								NULL))
+			rs485conf->flags |= SER_RS485_ENABLED;
+		}
+	} else {
+		atmel_port->rs485       = pdata->rs485;
+	}
+
+}
+
 static void atmel_set_ops(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
@@ -1409,6 +1483,7 @@ static void atmel_set_ops(struct uart_port *port)
  */
 static int atmel_startup(struct uart_port *port)
 {
+	struct platform_device *pdev = to_platform_device(port->dev);
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 	struct tty_struct *tty = port->state->port.tty;
 	int retval;
@@ -1433,6 +1508,8 @@ static int atmel_startup(struct uart_port *port)
 	/*
 	 * Initialize DMA (if necessary)
 	 */
+	atmel_init_property(atmel_port, pdev);
+
 	if (atmel_port->prepare_rx) {
 		retval = atmel_port->prepare_rx(port);
 		if (retval < 0)
@@ -1878,55 +1955,6 @@ static struct uart_ops atmel_pops = {
 #endif
 };
 
-static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
-					 struct device_node *np)
-{
-	u32 rs485_delay[2];
-
-	/* DMA/PDC usage specification */
-	if (of_get_property(np, "atmel,use-dma-rx", NULL)) {
-		if (of_get_property(np, "dmas", NULL)) {
-			atmel_port->use_dma_rx	= 1;
-			atmel_port->use_pdc_rx	= 0;
-		} else {
-			atmel_port->use_dma_rx	= 0;
-			atmel_port->use_pdc_rx	= 1;
-		}
-	} else {
-		atmel_port->use_dma_rx	= 0;
-		atmel_port->use_pdc_rx	= 0;
-	}
-
-	if (of_get_property(np, "atmel,use-dma-tx", NULL)) {
-		if (of_get_property(np, "dmas", NULL)) {
-			atmel_port->use_dma_tx	= 1;
-			atmel_port->use_pdc_tx	= 0;
-		} else {
-			atmel_port->use_dma_tx	= 0;
-			atmel_port->use_pdc_tx	= 1;
-		}
-	} else {
-		atmel_port->use_dma_tx	= 0;
-		atmel_port->use_pdc_tx	= 0;
-	}
-
-	/* rs485 properties */
-	if (of_property_read_u32_array(np, "rs485-rts-delay",
-					    rs485_delay, 2) == 0) {
-		struct serial_rs485 *rs485conf = &atmel_port->rs485;
-
-		rs485conf->delay_rts_before_send = rs485_delay[0];
-		rs485conf->delay_rts_after_send = rs485_delay[1];
-		rs485conf->flags = 0;
-
-		if (of_get_property(np, "rs485-rx-during-tx", NULL))
-			rs485conf->flags |= SER_RS485_RX_DURING_TX;
-
-		if (of_get_property(np, "linux,rs485-enabled-at-boot-time", NULL))
-			rs485conf->flags |= SER_RS485_ENABLED;
-	}
-}
-
 /*
  * Configure the port from the platform device resource info.
  */
@@ -1936,17 +1964,10 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 	struct uart_port *port = &atmel_port->uart;
 	struct atmel_uart_data *pdata = pdev->dev.platform_data;
 
-	if (pdev->dev.of_node) {
-		atmel_of_init_port(atmel_port, pdev->dev.of_node);
-	} else {
-		atmel_port->use_pdc_rx	= pdata->use_dma_rx;
-		atmel_port->use_pdc_tx	= pdata->use_dma_tx;
-		atmel_port->use_dma_rx	= 0;
-		atmel_port->use_dma_tx	= 0;
-		atmel_port->rs485	= pdata->rs485;
-	}
+	if (!atmel_init_property(atmel_port, pdev))
+		atmel_set_ops(port);
 
-	atmel_set_ops(port);
+	atmel_init_rs485(atmel_port, pdev);
 
 	port->iotype		= UPIO_MEM;
 	port->flags		= UPF_BOOT_AUTOCONF;
-- 
1.7.9.5



From elen.song at atmel.com  Mon Jul 15 22:43:45 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 16 Jul 2013 10:43:45 +0800
Subject: [PATCH V2 6/8] serial: at91: make DBGU support dma and pdc transfers
In-Reply-To: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373942627-7121-7-git-send-email-elen.song@atmel.com>

Because the DBGU lack of receive timeout register, so we use a timer to trigger
data receive.

Signed-off-by: Elen Song <elen.song at atmel.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |   48 ++++++++++++++++++++++++++++++++-----
 1 file changed, 42 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index ad787fd1..afecdfa 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -41,6 +41,7 @@
 #include <linux/uaccess.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/platform_data/atmel.h>
+#include <linux/timer.h>
 
 #include <asm/io.h>
 #include <asm/ioctls.h>
@@ -167,6 +168,7 @@ struct atmel_uart_port {
 
 	struct serial_rs485	rs485;		/* rs485 settings */
 	unsigned int		tx_done_mask;
+	struct timer_list       uart_timer;     /* dbgu timer */
 	int (*prepare_rx)(struct uart_port *port);
 	int (*prepare_tx)(struct uart_port *port);
 	void (*schedule_rx)(struct uart_port *port);
@@ -821,6 +823,9 @@ static void atmel_release_rx_dma(struct uart_port *port)
 	atmel_port->desc_rx = NULL;
 	atmel_port->chan_rx = NULL;
 	atmel_port->cookie_rx = -EINVAL;
+
+	if (port->line == 0)
+		del_timer_sync(&atmel_port->uart_timer);
 }
 
 static void atmel_rx_from_dma(struct uart_port *port)
@@ -950,6 +955,15 @@ chan_err:
 	return -EINVAL;
 }
 
+static void atmel_uart_timer_callback(unsigned long data)
+{
+	struct uart_port *port = (void *)data;
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+	tasklet_schedule(&atmel_port->tasklet);
+	mod_timer(&atmel_port->uart_timer, jiffies + uart_poll_timeout(port));
+}
+
 /*
  * receive interrupt handler.
  */
@@ -1213,6 +1227,9 @@ static void atmel_release_rx_pdc(struct uart_port *port)
 				 DMA_FROM_DEVICE);
 		kfree(pdc->buf);
 	}
+
+	if (port->line == 0)
+		del_timer_sync(&atmel_port->uart_timer);
 }
 
 static void atmel_rx_from_pdc(struct uart_port *port)
@@ -1546,17 +1563,36 @@ static int atmel_startup(struct uart_port *port)
 
 	if (atmel_use_pdc_rx(port)) {
 		/* set UART timeout */
-		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
-		UART_PUT_CR(port, ATMEL_US_STTTO);
+		if (port->line == 0) {
+			setup_timer(&atmel_port->uart_timer,
+					atmel_uart_timer_callback,
+					(unsigned long)port);
+			mod_timer(&atmel_port->uart_timer,
+					jiffies + uart_poll_timeout(port));
+		/* set USART timeout */
+		} else {
+			UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
+			UART_PUT_CR(port, ATMEL_US_STTTO);
 
-		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
+			UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
+		}
 		/* enable PDC controller */
 		UART_PUT_PTCR(port, ATMEL_PDC_RXTEN);
 	} else if (atmel_use_dma_rx(port)) {
-		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
-		UART_PUT_CR(port, ATMEL_US_STTTO);
+		/* set UART timeout */
+		if (port->line == 0) {
+			setup_timer(&atmel_port->uart_timer,
+					atmel_uart_timer_callback,
+					(unsigned long)port);
+			mod_timer(&atmel_port->uart_timer,
+					jiffies + uart_poll_timeout(port));
+		/* set USART timeout */
+		} else {
+			UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
+			UART_PUT_CR(port, ATMEL_US_STTTO);
 
-		UART_PUT_IER(port, ATMEL_US_TIMEOUT);
+			UART_PUT_IER(port, ATMEL_US_TIMEOUT);
+		}
 	} else {
 		/* enable receive only */
 		UART_PUT_IER(port, ATMEL_US_RXRDY);
-- 
1.7.9.5



From elen.song at atmel.com  Mon Jul 15 22:43:46 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 16 Jul 2013 10:43:46 +0800
Subject: [PATCH V2 7/8] serial: at91: distinguish usart and uart
In-Reply-To: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373942627-7121-8-git-send-email-elen.song@atmel.com>

Distinguish usart and uart by read ip name register,
dbgu regards as uart.

Signed-off-by: Elen Song <elen.song at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |   37 +++++++++++++++++++++++++++++++++++++
 include/linux/atmel_serial.h      |    2 ++
 2 files changed, 39 insertions(+)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index afecdfa..769b90b 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -99,6 +99,7 @@ static void atmel_stop_rx(struct uart_port *port);
 #define UART_PUT_BRGR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_BRGR)
 #define UART_PUT_RTOR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_RTOR)
 #define UART_PUT_TTGR(port, v)	__raw_writel(v, (port)->membase + ATMEL_US_TTGR)
+#define UART_GET_IP_NAME(port)	__raw_readl((port)->membase + ATMEL_US_NAME)
 
  /* PDC registers */
 #define UART_PUT_PTCR(port,v)	__raw_writel(v, (port)->membase + ATMEL_PDC_PTCR)
@@ -169,6 +170,7 @@ struct atmel_uart_port {
 	struct serial_rs485	rs485;		/* rs485 settings */
 	unsigned int		tx_done_mask;
 	struct timer_list       uart_timer;     /* dbgu timer */
+	bool			is_usart;	/* usart or uart */
 	int (*prepare_rx)(struct uart_port *port);
 	int (*prepare_tx)(struct uart_port *port);
 	void (*schedule_rx)(struct uart_port *port);
@@ -1496,6 +1498,34 @@ static void atmel_set_ops(struct uart_port *port)
 }
 
 /*
+ * Get ip name usart or uart
+ */
+static int atmel_get_ip_name(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	int name = UART_GET_IP_NAME(port);
+	int usart, uart;
+	/* usart and uart ascii */
+	usart = 0x55534152;
+	uart = 0x44424755;
+
+	atmel_port->is_usart = false;
+
+	if (name == usart) {
+		dev_dbg(port->dev, "This is usart\n");
+		atmel_port->is_usart = true;
+	} else if (name == uart) {
+		dev_dbg(port->dev, "This is uart\n");
+		atmel_port->is_usart = false;
+	} else {
+		dev_err(port->dev, "Not supported ip name, set to uart\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/*
  * Perform initialization and enable port for reception
  */
 static int atmel_startup(struct uart_port *port)
@@ -2359,6 +2389,13 @@ static int atmel_serial_probe(struct platform_device *pdev)
 		UART_PUT_CR(&port->uart, ATMEL_US_RTSEN);
 	}
 
+	/*
+	 * Get port name of usart or uart
+	 */
+	ret = atmel_get_ip_name(&port->uart);
+	if (ret < 0)
+		goto err_add_port;
+
 	return 0;
 
 err_add_port:
diff --git a/include/linux/atmel_serial.h b/include/linux/atmel_serial.h
index fd68337..be201ca 100644
--- a/include/linux/atmel_serial.h
+++ b/include/linux/atmel_serial.h
@@ -124,4 +124,6 @@
 #define ATMEL_US_NER		0x44			/* Number of Errors Register */
 #define ATMEL_US_IF		0x4c			/* IrDA Filter Register */
 
+#define ATMEL_US_NAME		0xf0			/* Ip Name */
+
 #endif
-- 
1.7.9.5



From elen.song at atmel.com  Mon Jul 15 22:43:47 2013
From: elen.song at atmel.com (Elen Song)
Date: Tue, 16 Jul 2013 10:43:47 +0800
Subject: [PATCH V2 8/8] serial: at91: modify UART to use software timer to
 trigger rx
In-Reply-To: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
Message-ID: <1373942627-7121-9-git-send-email-elen.song@atmel.com>

Signed-off-by: Elen Song <elen.song at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 769b90b..67617a8 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -826,7 +826,7 @@ static void atmel_release_rx_dma(struct uart_port *port)
 	atmel_port->chan_rx = NULL;
 	atmel_port->cookie_rx = -EINVAL;
 
-	if (port->line == 0)
+	if (!atmel_port->is_usart)
 		del_timer_sync(&atmel_port->uart_timer);
 }
 
@@ -1230,7 +1230,7 @@ static void atmel_release_rx_pdc(struct uart_port *port)
 		kfree(pdc->buf);
 	}
 
-	if (port->line == 0)
+	if (!atmel_port->is_usart)
 		del_timer_sync(&atmel_port->uart_timer);
 }
 
@@ -1593,7 +1593,7 @@ static int atmel_startup(struct uart_port *port)
 
 	if (atmel_use_pdc_rx(port)) {
 		/* set UART timeout */
-		if (port->line == 0) {
+		if (!atmel_port->is_usart) {
 			setup_timer(&atmel_port->uart_timer,
 					atmel_uart_timer_callback,
 					(unsigned long)port);
@@ -1610,7 +1610,7 @@ static int atmel_startup(struct uart_port *port)
 		UART_PUT_PTCR(port, ATMEL_PDC_RXTEN);
 	} else if (atmel_use_dma_rx(port)) {
 		/* set UART timeout */
-		if (port->line == 0) {
+		if (!atmel_port->is_usart) {
 			setup_timer(&atmel_port->uart_timer,
 					atmel_uart_timer_callback,
 					(unsigned long)port);
-- 
1.7.9.5



From kgene.kim at samsung.com  Mon Jul 15 23:22:14 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 16 Jul 2013 12:22:14 +0900
Subject: [PATCH] irqchip: exynos: cleanup non-DT stuff in exynos-combiner
Message-ID: <027401ce81d3$ad706570$08513050$%kim@samsung.com>


For EXYNOS SoCs, only can support for DT so removes non-DT stuff
in exynos-combiner.

Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
---
 drivers/irqchip/exynos-combiner.c |   44 +------------------------------------
 1 file changed, 1 insertion(+), 43 deletions(-)

diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c
index 4c68265..868ed40 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -19,10 +19,6 @@
 #include <linux/of_irq.h>
 #include <asm/mach/irq.h>
 
-#ifdef CONFIG_EXYNOS_ATAGS
-#include <plat/cpu.h>
-#endif
-
 #include "irqchip.h"
 
 #define COMBINER_ENABLE_SET	0x0
@@ -138,7 +134,6 @@ static void __init combiner_init_one(struct combiner_chip_data *combiner_data,
 	__raw_writel(combiner_data->irq_mask, base + COMBINER_ENABLE_CLEAR);
 }
 
-#ifdef CONFIG_OF
 static int combiner_irq_domain_xlate(struct irq_domain *d,
 				     struct device_node *controller,
 				     const u32 *intspec, unsigned int intsize,
@@ -156,16 +151,6 @@ static int combiner_irq_domain_xlate(struct irq_domain *d,
 
 	return 0;
 }
-#else
-static int combiner_irq_domain_xlate(struct irq_domain *d,
-				     struct device_node *controller,
-				     const u32 *intspec, unsigned int intsize,
-				     unsigned long *out_hwirq,
-				     unsigned int *out_type)
-{
-	return -EINVAL;
-}
-#endif
 
 static int combiner_irq_domain_map(struct irq_domain *d, unsigned int irq,
 				   irq_hw_number_t hw)
@@ -184,26 +169,6 @@ static struct irq_domain_ops combiner_irq_domain_ops = {
 	.map	= combiner_irq_domain_map,
 };
 
-static unsigned int combiner_lookup_irq(int group)
-{
-#ifdef CONFIG_EXYNOS_ATAGS
-	if (group < EXYNOS4210_MAX_COMBINER_NR || soc_is_exynos5250())
-		return IRQ_SPI(group);
-
-	switch (group) {
-	case 16:
-		return IRQ_SPI(107);
-	case 17:
-		return IRQ_SPI(108);
-	case 18:
-		return IRQ_SPI(48);
-	case 19:
-		return IRQ_SPI(42);
-	}
-#endif
-	return 0;
-}
-
 static void __init combiner_init(void __iomem *combiner_base,
 				 struct device_node *np,
 				 unsigned int max_nr,
@@ -229,12 +194,7 @@ static void __init combiner_init(void __iomem *combiner_base,
 	}
 
 	for (i = 0; i < max_nr; i++) {
-#ifdef CONFIG_OF
-		if (np)
-			irq = irq_of_parse_and_map(np, i);
-		else
-#endif
-			irq = combiner_lookup_irq(i);
+		irq = irq_of_parse_and_map(np, i);
 
 		combiner_init_one(&combiner_data[i], i,
 				  combiner_base + (i >> 2) * 0x10, irq);
@@ -242,7 +202,6 @@ static void __init combiner_init(void __iomem *combiner_base,
 	}
 }
 
-#ifdef CONFIG_OF
 static int __init combiner_of_init(struct device_node *np,
 				   struct device_node *parent)
 {
@@ -275,4 +234,3 @@ static int __init combiner_of_init(struct device_node *np,
 }
 IRQCHIP_DECLARE(exynos4210_combiner, "samsung,exynos4210-combiner",
 		combiner_of_init);
-#endif
-- 
1.7.10.4



From richard.zhuhongxing at gmail.com  Mon Jul 15 23:28:45 2013
From: richard.zhuhongxing at gmail.com (Richard Zhu)
Date: Tue, 16 Jul 2013 11:28:45 +0800
Subject: [PATCH v7 0/3] ahci: enable ahci sata support on imx6q
Message-ID: <1373945328-20893-1-git-send-email-Hong-Xing.Zhu@freescale.com>

v7: add imx6q specific ahci sata support
  Thanks to Sergei Shtylyow and Shawn.
  - According to ePAPR [1] section 2.2.2, re-name
  the node from 'ahci' to 'sata'
  - Move the initialization of the ahb clock of the private
  data to the probe function.
  - Remove the platform_set_drvdata(..., NULL), and devm_clk_put
  (..., ...).
  - 

v6: http://www.spinics.net/lists/linux-ide/msg45719.html
  Thanks for Shawn's comments.
  - Speicify the ahb clock in the sata related dts changes.
  - Move the initialization of the sata PHY clock of the private
  data to the probe function.
  - Remove the empty device release function.
  - In order to be more readable, rename the imx_dev/imx_ahci_pdev
  to be ahci_dev/ahci_pdev, and do some other changes, such as typo
  error, more readable name of the variable.
  - 

v5: http://www.spinics.net/lists/linux-ide/msg45712.html
  - Fix the wrong referrence usage of the private data.
  - Use the private data to contain the poninter of the PHY
  signals adjustment window(gpr)
  - Tested on imx6q sd board.
  - 

v4: http://www.spinics.net/lists/linux-ide/msg45699.html
  Thanks for the review comments provided by Sascha, and Alexander.
  - Use the private data and keep a pointer to the PHY clock.
  - Don't use the global platform device variable, because that
  it would make the driver broken for mutiple instances.
  - Don't do the "writel" with assignment.
  - Other minor changes, such as print the error code when printing
  error message, use a u32 type to store readl results, and so on.

v3: http://www.spinics.net/lists/linux-ide/msg45688.html
  - Keep arch/arm and ahci_platform driver clean.
  - Add the sata_imx standalone driver contained all the
  specific setup
  - Add the release function, support the loadable module
  driver.
  - Tested on imx6q sd board.

v2: http://www.spinics.net/lists/linux-ide/msg45666.html 
 - Setup standalone imx ahci sata driver, because of
 the misalignments of the bits definition of the HBA register.
 - Replace the node by the label in the board dts.
 - 

v1: http://www.spinics.net/lists/linux-ide/msg45581.html
 - add imx6q specific ahci sata support to arch/arm/mach-imx/mach-imx6q.c

These patches is based on imx/dt branch of
"http://git.linaro.org/git-ro/people/shawnguo/linux-2.6.git"

[v7 1/3] ARM: dtsi: enable ahci sata on imx6q platforms
[v7 2/3] ARM: imx6q: update the sata bits definitions of gpr13
[v7 3/3] sata: imx: add ahci sata support on imx platforms

arch/arm/boot/dts/imx6q-sabreauto.dts       |    4 +
arch/arm/boot/dts/imx6q-sabrelite.dts       |    4 +
arch/arm/boot/dts/imx6q-sabresd.dts         |    4 +
arch/arm/boot/dts/imx6q.dtsi                |    9 +
drivers/ata/Kconfig                         |    9 +
drivers/ata/Makefile                        |    1 +
drivers/ata/sata_imx.c                      |  236 +++++++++++++++++++++++++++
include/linux/mfd/syscon/imx6q-iomuxc-gpr.h |  121 ++++++++++----
8 files changed, 351 insertions(+), 37 deletions(-)


From kgene.kim at samsung.com  Mon Jul 15 23:27:51 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 16 Jul 2013 12:27:51 +0900
Subject: [PATCH] ARM: EXYNOS: skip pm support on exynos5440
Message-ID: <027501ce81d4$73a0a200$5ae1e600$%kim@samsung.com>


EXYNOS5440 doesn't support PM and current single image for EXYNOS
will be break without this patch. Actually, SSDK5440 cannot boot
without this so this should be merged during -rc.

Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
---
 arch/arm/mach-exynos/pm.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 41c2069..c679db5 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -217,6 +217,9 @@ static __init int exynos_pm_drvinit(void)
 	struct clk *pll_base;
 	unsigned int tmp;
 
+	if (soc_is_exynos5440())
+		return 0;
+
 	s3c_pm_init();
 
 	/* All wakeup disable */
@@ -340,6 +343,9 @@ static struct syscore_ops exynos_pm_syscore_ops = {
 
 static __init int exynos_pm_syscore_init(void)
 {
+	if (soc_is_exynos5440())
+		return 0;
+
 	register_syscore_ops(&exynos_pm_syscore_ops);
 	return 0;
 }
-- 
1.7.10.4



From bitbucket at online.de  Mon Jul 15 23:29:40 2013
From: bitbucket at online.de (Mike Galbraith)
Date: Tue, 16 Jul 2013 05:29:40 +0200
Subject: [PATCH 2/3] video: hx8357: Make IM pins optional
In-Reply-To: <003501ce81be$4a945ed0$dfbd1c70$@samsung.com>
References: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
 <1373902022-20439-3-git-send-email-maxime.ripard@free-electrons.com>
 <003501ce81be$4a945ed0$dfbd1c70$@samsung.com>
Message-ID: <1373945380.7549.26.camel@marge.simpson.net>

On Tue, 2013-07-16 at 09:49 +0900, Jingoo Han wrote: 
> On Tuesday, July 16, 2013 12:27 AM, Maxime Ripard wrote:

> > +
> > +			ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
> > +						    GPIOF_OUT_INIT_LOW, "im_pins");
> 
> This makes a checkpatch warning such as 'WARNING: line over 80 characters'.
> How about the following?
> 
> 			ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
> 						GPIOF_OUT_INIT_LOW, "im_pins");

IIRC, some maintainers gripe (davem?) when they see such alignment,
preferring the original arg below arg alignment vs strict 80 column.

-Mike



From shawn.guo at linaro.org  Mon Jul 15 23:36:43 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 11:36:43 +0800
Subject: [v7 1/3] ARM: dtsi: enable ahci sata on imx6q platforms
In-Reply-To: <1373945328-20893-2-git-send-email-Hong-Xing.Zhu@freescale.com>
References: <1373945328-20893-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373945328-20893-2-git-send-email-Hong-Xing.Zhu@freescale.com>
Message-ID: <20130716033639.GE28375@S2101-09.ap.freescale.net>

On Tue, Jul 16, 2013 at 11:28:46AM +0800, Richard Zhu wrote:
> From: Richard Zhu <r65037 at freescale.com>
> 
> Only imx6q has the ahci sata controller, enable
> it on imx6q platforms.
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>

Applied, thanks.



From shawn.guo at linaro.org  Mon Jul 15 23:37:15 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 11:37:15 +0800
Subject: [v7 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <1373945328-20893-4-git-send-email-Hong-Xing.Zhu@freescale.com>
References: <1373945328-20893-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373945328-20893-4-git-send-email-Hong-Xing.Zhu@freescale.com>
Message-ID: <20130716033711.GF28375@S2101-09.ap.freescale.net>

On Tue, Jul 16, 2013 at 11:28:48AM +0800, Richard Zhu wrote:
> From: Richard Zhu <r65037 at freescale.com>
> 
> imx6q contains one Synopsys AHCI SATA controller,
> But it can't share ahci_platform driver with other
> controllers.
> Because there are some misalignments of the generic
> AHCI controller.
> The bits definitions of the HBA registers, the Vendor
> Specific registers, the AHCI PHY clock and the AHCI
> signals adjustment window(GPR13 register).
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>  value is '0', should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the
>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>  should be configured regarding to the frequency of AHB
>  bus clock.
>  - Configurations of the AHCI PHY clock, and the signal
>  parameters of the GPR13
> 
> Setup its own ahci sata driver, contained the imx6q specific
> initialized codes, re-use the generic ahci_platform driver, and
> keep the generic ahci_platform driver clean as much as possible.
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>

Reviewed-by: Shawn Guo <shawn.guo at linaro.org>



From kgene.kim at samsung.com  Mon Jul 15 23:38:43 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 16 Jul 2013 12:38:43 +0900
Subject: [PATCH] ARM: exynos: change the PHYSMEM_BITS and SECTION_SIZE
In-Reply-To: <1370956861-18710-1-git-send-email-subash.rp@samsung.com>
References: <1370956861-18710-1-git-send-email-subash.rp@samsung.com>
Message-ID: <027601ce81d5$f87bc080$e9734180$%kim@samsung.com>

Subash Patel wrote:
> 
> On exynos5440 there is DRAM on the 36-bit address range. Hence
> this patch converts the MAX_PHYSMEM_BITS macro to 36 if LPAE is
> enabled for the ARM architecture.
> 
> The conventional section size on exynos is 256M due to sparsemem.
> Since exynos5440 has memory in multiples of 1G in 32-bit and 36-bit
> range, this has now been modified to 31.
> 
> Signed-off-by: Subash Patel <subash.rp at samsung.com>
> ---
>  arch/arm/mach-exynos/include/mach/memory.h |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/mach-exynos/include/mach/memory.h
b/arch/arm/mach-exynos/include/mach/memory.h
> index 374ef2c..2a4cdb7 100644
> --- a/arch/arm/mach-exynos/include/mach/memory.h
> +++ b/arch/arm/mach-exynos/include/mach/memory.h
> @@ -15,8 +15,13 @@
> 
>  #define PLAT_PHYS_OFFSET		UL(0x40000000)
> 
> +#ifndef CONFIG_ARM_LPAE
>  /* Maximum of 256MiB in one bank */
>  #define MAX_PHYSMEM_BITS	32
>  #define SECTION_SIZE_BITS	28
> +#else
> +#define MAX_PHYSMEM_BITS	36
> +#define SECTION_SIZE_BITS	31
> +#endif
> 
>  #endif /* __ASM_ARCH_MEMORY_H */
> --
> 1.7.10.4

OK, current EXYNOS5440(SSDK5440 and SD5v1) cannot boot without this because
of enabling LPAE and bootargs for over 4GiB memory. So let me sort this out
for v3.11-rc.

Thanks,
- Kukjin



From swarren at wwwdotorg.org  Mon Jul 15 23:39:31 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 21:39:31 -0600
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <2883016.87pKJk9n0R@avalon>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <2172485.AZTjvkLGcM@avalon> <51E015E1.2090906@wwwdotorg.org>
 <2883016.87pKJk9n0R@avalon>
Message-ID: <51E4C073.4020407@wwwdotorg.org>

On 07/15/2013 07:10 PM, Laurent Pinchart wrote:
> On Friday 12 July 2013 08:42:41 Stephen Warren wrote:
...
>> I think the values for any common system-wide flags should be defined
>> once in some system-wide place, and the values for any HW-specific
>> values should be defined only in the documentation for that specific HW.
>> You could try and avoid conflicts by either:
>>
>> a) Allocating system-wide flags from bit 0 up, and HW-specific flags
>> from bit 31 down.
>>
>> or:
>>
>> b) Using 1 cell for standard flags, and a separate cell for any
>> HW-specific flags. Drivers can quite easily adapt to adding extra cells
>> to #pwm-cells, thus making adding a HW-specific cell later
>> backwards-compatible.
> 
> I wasn't referring to HW-specific flags, but rather to system-wide flags that 
> might not be supported by all drivers. If we later add new system-wide flags I 
> think the individual DT bindings should explicitly document which flags they 
> support.

Shouldn't all system-wide flags be supported by all HW, perhaps being
implemented by the core subsystem rather than individual drivers to
ensure that? Consider the case of the GPIO active-low flag which is
actually implemented in SW, hence can work with any GPIO controller.

Perhaps that's not possible in all cases, in which case, yes, it does
make sense to define which of the common flags a particular HW module
supports.

But then there's a problem where people assume that the common flags are
always available, and somewhere they aren't... Care is needed in the
choice of which common flags to define and/or how they're used.


From kgene.kim at samsung.com  Mon Jul 15 23:39:42 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 16 Jul 2013 12:39:42 +0900
Subject: [PATCH] ARM: EXYNOS: Enable 64-bit DMA for EXYNOS5440 if LPAE is
 enabled
In-Reply-To: <109701ce667b$179822e0$46c868a0$%kim@samsung.com>
References: <109701ce667b$179822e0$46c868a0$%kim@samsung.com>
Message-ID: <027701ce81d6$1b857a80$52906f80$%kim@samsung.com>

Kukjin Kim wrote:
> 
> From: Thomas Abraham <thomas.ab at samsung.com>
> 
> Allow 64-bit DMA addresses if LPAE is enabled on EXYNOS5440.
> 
> Signed-off-by: Thomas Abraham <thomas.ab at samsung.com>
> Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
> ---
>  arch/arm/mach-exynos/Kconfig |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index e101b14..0f7d308 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -81,6 +81,7 @@ config SOC_EXYNOS5440
>  	bool "SAMSUNG EXYNOS5440"
>  	default y
>  	depends on ARCH_EXYNOS5
> +	select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
>  	select ARCH_HAS_OPP
>  	select ARM_ARCH_TIMER
>  	select AUTO_ZRELADDR
> --
> 1.7.10.4

OK, applied into -fixes for 3.11-rc because current SSDK5440 cannot boot
without this.

Thanks,
- Kukjin



From shawn.guo at linaro.org  Mon Jul 15 23:39:54 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 11:39:54 +0800
Subject: [v7 2/3] ARM: imx6q: update the sata bits definitions of gpr13
In-Reply-To: <1373945328-20893-3-git-send-email-Hong-Xing.Zhu@freescale.com>
References: <1373945328-20893-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373945328-20893-3-git-send-email-Hong-Xing.Zhu@freescale.com>
Message-ID: <20130716033951.GG28375@S2101-09.ap.freescale.net>

On Tue, Jul 16, 2013 at 11:28:47AM +0800, Richard Zhu wrote:
> From: Richard Zhu <r65037 at freescale.com>
> 
> Replace the SATA_PHY_# by the more readable definitons.
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>

Hi Tejun,

The patch needs to go through your tree to keep patch #3 compilable.  So

Acked-by: Shawn Guo <shawn.guo at linaro.org>



From festevam at gmail.com  Mon Jul 15 23:42:15 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 16 Jul 2013 00:42:15 -0300
Subject: [PATCH 1/5] ARM: dts: imx23-evk: enable USB PHY and controller
In-Reply-To: <1373898160-8460-1-git-send-email-otavio@ossystems.com.br>
References: <1373898160-8460-1-git-send-email-otavio@ossystems.com.br>
Message-ID: <CAOMZO5D+szAgY6+CHjwFRw2qwvusv2_Ach0hv=hj4X1cmMnHfA@mail.gmail.com>

On Mon, Jul 15, 2013 at 11:22 AM, Otavio Salvador
<otavio at ossystems.com.br> wrote:
> The i.MX23EVK board provides a USB port so the USB PHY and controller
> need to be enabled for it to be usable.

Has this been tested? I don't see in this patch any code to enable USB power.


From swarren at wwwdotorg.org  Mon Jul 15 23:35:52 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 15 Jul 2013 21:35:52 -0600
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <20130716015038.GD28375@S2101-09.ap.freescale.net>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
Message-ID: <51E4BF98.8030604@wwwdotorg.org>

On 07/15/2013 07:50 PM, Shawn Guo wrote:
> Hi Philipp,
> 
> On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
>> This driver implements a reset controller device that toggle a gpio
>> connected to a reset pin of a peripheral IC. The delay between assertion
>> and de-assertion of the reset signal can be configured via device tree.
>>
>> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
>> Reviewed-by: Stephen Warren <swarren at nvidia.com>
> 
> I see this patch is very useful, as GPIOs are widely used to reset
> components/devices on board.  But I do not find the patch in v3.11-rc1.
> What's your plan about it?
> 
> Also, I'm wondering if we should register the driver a little bit
> early.  Please see the following patch.  If it makes sense to you,
> I can send the patch to you, or you can just quash it into yours.
> 
> Shawn
> 
> ---8<--------
> 
> From 2f8ce9e5d6525b98f3828b707458e83fabb39d50 Mon Sep 17 00:00:00 2001
> From: Shawn Guo <shawn.guo at linaro.org>
> Date: Sun, 14 Jul 2013 20:41:00 +0800
> Subject: [PATCH] ENGR00269945: reset: register gpio-reset driver in
>  arch_initcall
> 
> It's a little bit late to register gpio-reset driver at module_init
> time, because gpio-reset provides reset control via gpio for other
> devices which are mostly probed at module_init time too.  And it
> becomes even worse, when the gpio comes from IO expander on I2C bus,
> e.g. pca953x.  In that case, gpio-reset needs to be ready before I2C
> bus driver which is generally ready at subsys_initcall time.  Let's
> register gpio-reset driver in arch_initcall() to have it ready early
> enough.

There's no need for the reset driver to be registered before its users;
the users of the reset GPIO will simply have their probe deferred until
the reset controller is available, and then everything will work out
just fine.

> The defer probe mechanism is not used here, because a reset controller
> driver should be reasonably registered early than other devices.  More
> importantly, defer probe doe not help in some nasty cases, e.g. the
> gpio-pca953x device itself needs a reset from gpio-reset driver to start
> working.

That should work fine with deferred probe.


From kgene.kim at samsung.com  Tue Jul 16 00:01:18 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 16 Jul 2013 13:01:18 +0900
Subject: Single zImage and A15/LPAE
In-Reply-To: <201305292351.41096.arnd@arndb.de>
References: <50735B75.8070109@wwwdotorg.org> <2274563.opVbLLPT1p@wuerfel>
 <20130529151555.GP17767@MacBook-Pro.local> <201305292351.41096.arnd@arndb.de>
Message-ID: <028201ce81d9$200ecbd0$602c6370$%kim@samsung.com>

Arnd Bergmann wrote:
> 
> On Wednesday 29 May 2013, Catalin Marinas wrote:
> > > I think to do this right, we need to treat ARMv7+LPAE as a separate
> > > architecture level, just like we treat ARMv6, ARMv7 as separate
> > > compatible architectures. BTW, is there an official name for that
> > > architecture?
> >
> > The official is Large Physical Address Extension which is an extension
> > to ARMv7, so not a new architecture.
> 
> Ah, too bad. I had hoped there were still postfixes like v6K or v4T.
> I guess there is no complete list of ARMv7 extensions anywhere, right?
> 
Just note, EXYNOS4 SoCs and EXYNOS5250 cannot boot when LPAE is enabled so I
think, single zImage should be handled separately for non-LPAE and LPAE. I
need to sort out EXYNOS SoCs for it and prepare registering
exynos5440_defconfig. Of course, EXYNOS5440 can be supported without LPAE
enabling but current bootargs in v3.11-rc1 break the kernel booting.

Thanks,
- Kukjin



From shawn.guo at linaro.org  Tue Jul 16 00:10:58 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 12:10:58 +0800
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <51E4BF98.8030604@wwwdotorg.org>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
Message-ID: <20130716041056.GA30067@S2101-09.ap.freescale.net>

On Mon, Jul 15, 2013 at 09:35:52PM -0600, Stephen Warren wrote:
> > It's a little bit late to register gpio-reset driver at module_init
> > time, because gpio-reset provides reset control via gpio for other
> > devices which are mostly probed at module_init time too.  And it
> > becomes even worse, when the gpio comes from IO expander on I2C bus,
> > e.g. pca953x.  In that case, gpio-reset needs to be ready before I2C
> > bus driver which is generally ready at subsys_initcall time.  Let's
> > register gpio-reset driver in arch_initcall() to have it ready early
> > enough.
> 
> There's no need for the reset driver to be registered before its users;
> the users of the reset GPIO will simply have their probe deferred until
> the reset controller is available, and then everything will work out
> just fine.
> 
> > The defer probe mechanism is not used here, because a reset controller
> > driver should be reasonably registered early than other devices.  More
> > importantly, defer probe doe not help in some nasty cases, e.g. the
> > gpio-pca953x device itself needs a reset from gpio-reset driver to start
> > working.
> 
> That should work fine with deferred probe.

I should probably rework the commit log.  But I do not see a problem
to register gpio-reset driver a little bit earlier.  On the other hand,
if we reply on deferred probe, many drivers probe could be deferred.
For example, on my system, the gpio-pca953x on I2C bus works as a GPIO
controller and provides resets to many board level components.
Deferring probe of gpio-pca953x on I2C bus means every single probe of
all these components gets deferred.  IMO, this situation should be
reasonably avoided.

Shawn



From r.sricharan at ti.com  Tue Jul 16 01:21:44 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Tue, 16 Jul 2013 10:51:44 +0530
Subject: [PATCH 8/8] ARM: DRA7: Kconfig: Increase the default gpio count
In-Reply-To: <51E29482.7060208@linaro.org>
References: <1373354873-12359-1-git-send-email-rnayak@ti.com>
 <1373354873-12359-9-git-send-email-rnayak@ti.com>
 <51E29482.7060208@linaro.org>
Message-ID: <51E4D868.8010609@ti.com>

On Sunday 14 July 2013 05:37 PM, Kevin Hilman wrote:
> On 07/09/2013 08:27 AM, Rajendra Nayak wrote:
>> From: R Sricharan <r.sricharan at ti.com>
>>
>> DRA7xx has 8 GPIO banks so that there are 32x8 = 256 GPIOs.
>> In order for the gpiolib to detect and initialize these
>> additional GPIOs and other TWL GPIOs, ARCH_NR_GPIO is set
>> to 512 instead of present 256.
> nit: the patch itself doesn't change 256 to 512, but just adds another
> Kconfig default.
>
> Kevin
 hmm, ok. Will reword the $subject and commit accordingly

Regards,
 Sricharan
>> Signed-off-by: R Sricharan <r.sricharan at ti.com>
>> Signed-off-by: Rajendra Nayak <rnayak at ti.com>
>> ---
>>  arch/arm/Kconfig |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 5ef7af0..9faed52 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1599,7 +1599,7 @@ config LOCAL_TIMERS
>>  config ARCH_NR_GPIO
>>  	int
>>  	default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
>> -	default 512 if SOC_OMAP5
>> +	default 512 if SOC_OMAP5 || SOC_DRA7XX
>>  	default 512 if ARCH_KEYSTONE
>>  	default 392 if ARCH_U8500
>>  	default 352 if ARCH_VT8500
>>



From anup at brainfault.org  Tue Jul 16 01:50:11 2013
From: anup at brainfault.org (Anup Patel)
Date: Tue, 16 Jul 2013 11:20:11 +0530
Subject: [PATCH] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene host
In-Reply-To: <CAFEAcA-0Csn9NuHGKjL1TuNVVnmA0woUvAhuwxTv3r5a+3nMGg@mail.gmail.com>
References: <1373888788-8055-1-git-send-email-anup.patel@linaro.org>
 <51E3ED7A.7050207@arm.com>
 <CAAhSdy25WVnynDyPcOMtqVNEepGGq9WFT3b1PV34P6iSBm-FUg@mail.gmail.com>
 <73A8FA0E-9F7F-4866-9544-57838F30BB91@suse.de>
 <CAAhSdy1tYsdm-2kJzoRfqb-FaPa0-t9x2+=jtMjgFqes+Pco6Q@mail.gmail.com>
 <03C760B4-A395-491C-B589-0689BC2C48BB@suse.de>
 <CAFEAcA-0Csn9NuHGKjL1TuNVVnmA0woUvAhuwxTv3r5a+3nMGg@mail.gmail.com>
Message-ID: <CAAhSdy2=VMUR48x7pYcP_+B9K6LtTfDbvgoyGhos+nzGpWUhcQ@mail.gmail.com>

On Mon, Jul 15, 2013 at 9:29 PM, Peter Maydell <peter.maydell at linaro.org> wrote:
> On 15 July 2013 15:21, Alexander Graf <agraf at suse.de> wrote:
>> On 15.07.2013, at 16:04, Anup Patel wrote:
>>> On Mon, Jul 15, 2013 at 6:32 PM, Alexander Graf <agraf at suse.de> wrote:
>>>> Anything that is compatible is compatible :). I don't know
>>>> the product roadmaps for X-Gene cores, but you will want to
>>>> make the field here as coarse grained as possible, while
>>>> maintaining the guarantee that a guest still behaves the same.
>>>
>>> Actually, I don't see X-Gene cores changing in-terms of register
>>> interface available to EL1 and EL0 in near future. This is the
>>> reason why I had named the target as KVM_ARM_TARGET_XGENE_V8.
>>
>> So where does the v8 come from? Is there any non-ARMv8 XGene? If
>> not, this is v1 really, right? What if we just call it v1 instead?
>> Then when a new core comes up that needs different treatment, we
>> create a new target.
>
> I think what we're actually seeing here is that we started with
> a design that specifically said (in the v7 space) "only A15
> on A15", and we're now trying to broaden that out, only we
> haven't actually set out anywhere how that broadening is
> supposed to work (ie what range of hosts will work with
> what range of guests, and how, and whether we want to have
> a "give me a guest CPU that looks like the host CPU" option).
>
> I think the original idea was that userspace would say
> which CPU it wanted, and the kernel would know about that
> CPU (including details like ID and feature registers which
> are going to vary from core to core).
>
> thanks
> -- PMM

I am fine in naming the target as KVM_ARM_TARGET_XGENE_POTENZA.
Selecting this target for given X-Gene host (now and in-future) would mean
that KVM VCPU is X-Gene Potenza compatible. I will send revised patch
for this.

Also, further refining PMM's suggestion, we can have user-space specify
what CPU type it wants and what CPU features it wants. The KVM ARM
or KVM ARM64 will try to give all desired CPU features but it may change
the CPU features based on underlying host CPU features.

IMHO, user-space should be capable of enabling/disabling certain CPU
features of KVM VCPU. Of course, some features like arch_timer would
be mandatory and always available to all VCPU target types.

Regards,
Anup


From alekskartashov at parallels.com  Tue Jul 16 01:37:15 2013
From: alekskartashov at parallels.com (Alexander Kartashov)
Date: Tue, 16 Jul 2013 09:37:15 +0400
Subject: [PATCH] arm: align shared memory unconditionally to the SHMLBA
 boundary
In-Reply-To: <20130715185739.GK1730@moon>
References: <1361254269-3444-1-git-send-email-alekskartashov@parallels.com>
 <20130715173238.GJ1730@moon> <20130715180846.GV24642@n2100.arm.linux.org.uk>
 <20130715185739.GK1730@moon>
Message-ID: <51E4DC0B.8040908@parallels.com>

On 07/15/2013 10:57 PM, Cyrill Gorcunov wrote:
> Alexander, mind to remind
> where exactly we're failing in c/r procedure

It isn't always possible to pin an IPC SHM region
using shmat() at the address returned by shmget()
so sometimes it's impossible to restore a process
that uses the IPC SHM.

-- 
Sincerely yours,
Alexander Kartashov

Intern
Core team

www.parallels.com

Skype: aleksandr.kartashov
Email: alekskartashov at parallels.com



From kishon at ti.com  Tue Jul 16 01:52:38 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 16 Jul 2013 11:22:38 +0530
Subject: [PATCH v2 0/4] usb: musb: fix USB enumeration issue in OMAP3
 platform
In-Reply-To: <1373282057-20181-1-git-send-email-kishon@ti.com>
References: <1373282057-20181-1-git-send-email-kishon@ti.com>
Message-ID: <51E4DFA6.2010501@ti.com>

Tony,

On Monday 08 July 2013 04:44 PM, Kishon Vijay Abraham I wrote:
> This series fixes the USB enumeration issue caused because of the controller
> not able to get a reference to the PHY because of incorrect binding in the
> board file.
> 
> In the case of non-dt boot, the platform specific initialization file
> (board file) will do usb_bind_phy that binds the usb controller with the
> PHY using device names. After the device names are created using 
> PLATFORM_DEVID_AUTO, our original method of binding by device names doesn't
> work reliably (since the device name changes). Hence the usb controller
> is made to use labels for getting the PHY.
> 
> Here the PHY name is added in the plat data of USB controller device which
> should be used by the controller driver to get the PHY.
> Two new APIs usb_get_phy_by_name and devm_usb_get_phy_by_name are added to
> be used by the controller to get the PHY by name.

You haven't picked this patch series?

-Kishon


From gsi at denx.de  Tue Jul 16 02:05:04 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Tue, 16 Jul 2013 08:05:04 +0200
Subject: [PATCH v1 16/24] clk: mpc512x: remove now obsolete clkdev registration
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373954707-23909-1-git-send-email-gsi@denx.de>

after the PSC drivers for UART and SPI mode got converted to device tree
based clock lookup, the former MCLK name which depends on the PSC index
isn't needed any longer -- remove the clk_register_clkdev() invocation

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |   10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index f31f895..31707b5 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -529,16 +529,6 @@ static void mpc512x_clk_setup_mclk(struct mclk_setup_data *entry)
 				entry->name_mclk,
 				entry->name_mux1, 1, 1);
 	}
-
-	/*
-	 * without this "clock device" registration, "simple" lookups in
-	 * the SPI master initialization and serial port setup will fail
-	 *
-	 * those drivers need to get adjusted to lookup their required
-	 * clocks from OF specs, before this clkdev registration becomes
-	 * obsolete
-	 */
-	clk_register_clkdev(clks[clks_idx_pub], entry->name_mclk, NULL);
 }
 
 static void mpc512x_clk_setup_mclks(struct mclk_setup_data *table, size_t count)
-- 
1.7.10.4



From gsi at denx.de  Tue Jul 16 02:05:07 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Tue, 16 Jul 2013 08:05:07 +0200
Subject: [PATCH v1 19/24] USB: fsl-mph-dr-of: OF clock lookup,
 prepare and enable
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373954707-23909-4-git-send-email-gsi@denx.de>

device tree based clock lookup in the MPC512x initialization (lookup
'per' for register access), add error check in the clock setup, must
prepare clocks before they can get enabled, unprepare after disable

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/usb/host/fsl-mph-dr-of.c |   24 +++++++++---------------
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 11e0b79..eb564f3 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -260,25 +260,19 @@ int fsl_usb2_mpc5121_init(struct platform_device *pdev)
 {
 	struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
 	struct clk *clk;
-	char clk_name[10];
-	int base, clk_num;
-
-	base = pdev->resource->start & 0xf000;
-	if (base == 0x3000)
-		clk_num = 1;
-	else if (base == 0x4000)
-		clk_num = 2;
-	else
-		return -ENODEV;
+	int err;
 
-	snprintf(clk_name, sizeof(clk_name), "usb%d_clk", clk_num);
-	clk = clk_get(&pdev->dev, clk_name);
+	clk = clk_get(&pdev->dev, "per");
 	if (IS_ERR(clk)) {
 		dev_err(&pdev->dev, "failed to get clk\n");
 		return PTR_ERR(clk);
 	}
-
-	clk_enable(clk);
+	err = clk_prepare_enable(clk);
+	if (err) {
+		dev_err(&pdev->dev, "failed to enable clk\n");
+		clk_put(clk);
+		return err;
+	}
 	pdata->clk = clk;
 
 	if (pdata->phy_mode == FSL_USB2_PHY_UTMI_WIDE) {
@@ -303,7 +297,7 @@ static void fsl_usb2_mpc5121_exit(struct platform_device *pdev)
 	pdata->regs = NULL;
 
 	if (pdata->clk) {
-		clk_disable(pdata->clk);
+		clk_disable_unprepare(pdata->clk);
 		clk_put(pdata->clk);
 	}
 }
-- 
1.7.10.4



From gsi at denx.de  Tue Jul 16 02:05:06 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Tue, 16 Jul 2013 08:05:06 +0200
Subject: [PATCH v1 18/24] i2c: mpc: OF clock lookup for MPC512x
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373954707-23909-3-git-send-email-gsi@denx.de>

make the MPC I2C driver prepare and enable the peripheral clock
('per' for register access) in the MPC512x setup routine,
make this clock setup non-fatal to allow for a migration period,
remove the pre-enabling hack in the platform's clock driver

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |    1 -
 drivers/i2c/busses/i2c-mpc.c                  |    9 +++++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index 2c6da07..29c51a5 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -693,7 +693,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	/* some are not yet acquired by their respective drivers */
 	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
 	clk_prepare_enable(clks[MPC512x_CLK_FEC]);	/* network, NFS */
-	clk_prepare_enable(clks[MPC512x_CLK_I2C]);
 	/*
 	 * some have their individual clock subtree with separate clock
 	 * items and their individual enable counters, yet share a
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 7607dc0..13d6822 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -21,6 +21,7 @@
 #include <linux/of_i2c.h>
 #include <linux/slab.h>
 
+#include <linux/clk.h>
 #include <linux/io.h>
 #include <linux/fsl_devices.h>
 #include <linux/i2c.h>
@@ -264,11 +265,19 @@ static void mpc_i2c_setup_512x(struct device_node *node,
 					 struct mpc_i2c *i2c,
 					 u32 clock, u32 prescaler)
 {
+	struct clk *clk;
 	struct device_node *node_ctrl;
 	void __iomem *ctrl;
 	const u32 *pval;
 	u32 idx;
 
+	/* enable clock for the I2C peripheral (non fatal) */
+	clk = of_clk_get_by_name(node, "per");
+	if (!IS_ERR(clk)) {
+		clk_prepare_enable(clk);
+		clk_put(clk);
+	}
+
 	/* Enable I2C interrupts for mpc5121 */
 	node_ctrl = of_find_compatible_node(NULL, NULL,
 					    "fsl,mpc5121-i2c-ctrl");
-- 
1.7.10.4



From gsi at denx.de  Tue Jul 16 02:05:05 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Tue, 16 Jul 2013 08:05:05 +0200
Subject: [PATCH v1 17/24] serial: mpc512x: setup the PSC FIFO clock as well
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373954707-23909-2-git-send-email-gsi@denx.de>

prepare and enable the FIFO clock upon PSC FIFO initialization, disable
and unprepare the FIFO clock upon PSC FIFO uninitialization, remove the
pre-enable workaround from the platform's clock driver

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |    2 --
 drivers/tty/serial/mpc52xx_uart.c             |   47 +++++++++++++++++++++----
 2 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index 31707b5..2c6da07 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -690,8 +690,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	clk_prepare_enable(clks[MPC512x_CLK_MEM]);	/* SRAM */
 	clk_prepare_enable(clks[MPC512x_CLK_IPS]);	/* SoC periph */
 	clk_prepare_enable(clks[MPC512x_CLK_LPC]);	/* boot media */
-	/* some are required yet no dependencies were declared */
-	clk_prepare_enable(clks[MPC512x_CLK_PSC_FIFO]);
 	/* some are not yet acquired by their respective drivers */
 	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
 	clk_prepare_enable(clks[MPC512x_CLK_FEC]);	/* network, NFS */
diff --git a/drivers/tty/serial/mpc52xx_uart.c b/drivers/tty/serial/mpc52xx_uart.c
index 221fb89..e67d4c0 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -567,35 +567,70 @@ static unsigned int mpc512x_psc_set_baudrate(struct uart_port *port,
 static int __init mpc512x_psc_fifoc_init(void)
 {
 	struct device_node *np;
+	struct clk *clk;
 
 	np = of_find_compatible_node(NULL, NULL,
 				     "fsl,mpc5121-psc-fifo");
 	if (!np) {
 		pr_err("%s: Can't find FIFOC node\n", __func__);
-		return -ENODEV;
+		goto out_err;
+	}
+
+	clk = of_clk_get_by_name(np, "per");
+	if (IS_ERR(clk)) {
+		pr_err("%s: Can't lookup FIFO clock\n", __func__);
+		goto out_ofnode_put;
+	}
+	if (clk_prepare_enable(clk)) {
+		pr_err("%s: Can't enable FIFO clock\n", __func__);
+		goto out_clk_put;
 	}
 
 	psc_fifoc = of_iomap(np, 0);
 	if (!psc_fifoc) {
 		pr_err("%s: Can't map FIFOC\n", __func__);
-		of_node_put(np);
-		return -ENODEV;
+		goto out_clk_disable;
 	}
 
 	psc_fifoc_irq = irq_of_parse_and_map(np, 0);
-	of_node_put(np);
 	if (psc_fifoc_irq == 0) {
 		pr_err("%s: Can't get FIFOC irq\n", __func__);
-		iounmap(psc_fifoc);
-		return -ENODEV;
+		goto out_unmap;
 	}
 
+	clk_put(clk);
+	of_node_put(np);
 	return 0;
+
+out_unmap:
+	iounmap(psc_fifoc);
+out_clk_disable:
+	clk_disable_unprepare(clk);
+out_clk_put:
+	clk_put(clk);
+out_ofnode_put:
+	of_node_put(np);
+out_err:
+	return -ENODEV;
 }
 
 static void __exit mpc512x_psc_fifoc_uninit(void)
 {
+	struct device_node *np;
+	struct clk *clk;
+
 	iounmap(psc_fifoc);
+
+	/* disable the clock, errors are not fatal */
+	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-psc-fifo");
+	if (np) {
+		clk = of_clk_get_by_name(np, "per");
+		if (!IS_ERR(clk)) {
+			clk_disable_unprepare(clk);
+			clk_put(clk);
+		}
+		of_node_put(np);
+	}
 }
 
 /* 512x specific interrupt handler. The caller holds the port lock */
-- 
1.7.10.4



From gsi at denx.de  Tue Jul 16 02:05:55 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Tue, 16 Jul 2013 08:05:55 +0200
Subject: [PATCH v1 20/24] fs_enet: OF clock lookup (non-fatal),
 prepare and enable
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373954759-23947-1-git-send-email-gsi@denx.de>

device tree based clock lookup, must prepare clocks before enabling
them, unprepare after disable, error check in the clock setup, remove
the pre-enable workaround in the MPC512x platform's clock driver

this change implements non-fatal clock lookup since not all platforms
provide device tree specs for clocks, but failure to enable a specified
clock is considered fatal

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c      |    1 -
 .../net/ethernet/freescale/fs_enet/fs_enet-main.c  |   27 +++++++++++++++++++-
 include/linux/fs_enet_pd.h                         |    3 +++
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index 29c51a5..31d0cf3 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -692,7 +692,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	clk_prepare_enable(clks[MPC512x_CLK_LPC]);	/* boot media */
 	/* some are not yet acquired by their respective drivers */
 	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
-	clk_prepare_enable(clks[MPC512x_CLK_FEC]);	/* network, NFS */
 	/*
 	 * some have their individual clock subtree with separate clock
 	 * items and their individual enable counters, yet share a
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 8de53a1..df92e12 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -1020,6 +1020,21 @@ static int fs_enet_probe(struct platform_device *ofdev)
 		fpi->cp_command = *data;
 	}
 
+	/* make clock lookup non-fatal (the driver is shared among platforms),
+	 * but require enable to succeed when a clock was specified/found
+	 */
+	fpi->clk_per = clk_get(&ofdev->dev, "per");
+	if (IS_ERR(fpi->clk_per))
+		fpi->clk_per = NULL;
+	if (fpi->clk_per) {
+		int err;
+		err = clk_prepare_enable(fpi->clk_per);
+		if (err) {
+			ret = err;
+			goto out_clk_put;
+		}
+	}
+
 	fpi->rx_ring = 32;
 	fpi->tx_ring = 32;
 	fpi->rx_copybreak = 240;
@@ -1028,7 +1043,7 @@ static int fs_enet_probe(struct platform_device *ofdev)
 	fpi->phy_node = of_parse_phandle(ofdev->dev.of_node, "phy-handle", 0);
 	if ((!fpi->phy_node) && (!of_get_property(ofdev->dev.of_node, "fixed-link",
 						  NULL)))
-		goto out_free_fpi;
+		goto out_clk_dis;
 
 	if (of_device_is_compatible(ofdev->dev.of_node, "fsl,mpc5125-fec")) {
 		phy_connection_type = of_get_property(ofdev->dev.of_node,
@@ -1108,6 +1123,12 @@ out_free_dev:
 	free_netdev(ndev);
 out_put:
 	of_node_put(fpi->phy_node);
+out_clk_dis:
+	if (fpi->clk_per)
+		clk_disable_unprepare(fpi->clk_per);
+out_clk_put:
+	if (fpi->clk_per)
+		clk_put(fpi->clk_per);
 out_free_fpi:
 	kfree(fpi);
 	return ret;
@@ -1124,6 +1145,10 @@ static int fs_enet_remove(struct platform_device *ofdev)
 	fep->ops->cleanup_data(ndev);
 	dev_set_drvdata(fep->dev, NULL);
 	of_node_put(fep->fpi->phy_node);
+	if (fep->fpi->clk_per) {
+		clk_disable_unprepare(fep->fpi->clk_per);
+		clk_put(fep->fpi->clk_per);
+	}
 	free_netdev(ndev);
 	return 0;
 }
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 51b7934..a978d0d 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -16,6 +16,7 @@
 #ifndef FS_ENET_PD_H
 #define FS_ENET_PD_H
 
+#include <linux/clk.h>
 #include <linux/string.h>
 #include <linux/of_mdio.h>
 #include <asm/types.h>
@@ -142,6 +143,8 @@ struct fs_platform_info {
 
 	int use_rmii;		/* use RMII mode 	       */
 	int has_phy;            /* if the network is phy container as well...*/
+
+	struct clk *clk_per;	/* 'per' clock for register access */
 };
 struct fs_mii_fec_platform_info {
 	u32 irq[32];
-- 
1.7.10.4



From viresh.kumar at linaro.org  Tue Jul 16 02:27:02 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Tue, 16 Jul 2013 11:57:02 +0530
Subject: [RFC PATCH 01/11] driver/core: cpu: initialize of_node in cpu's
 device struture
In-Reply-To: <1373883732-26303-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1373883732-26303-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <CAKohpom-u3hCZrxWi-oaneXY_7ewLn06C8Wn78nE28mn9=TOHQ@mail.gmail.com>

On 15 July 2013 15:52,  <Sudeep.KarkadaNagesha at arm.com> wrote:
> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>
> CPUs are also registered as devices but the of_node in these cpu
> devices are not initialized. Currently different drivers requiring
> to access cpu device node are parsing the nodes themselves and
> initialising the of_node in cpu device.
>
> The of_node in all the cpu devices properly needs to be initialized

s/properly /

> properly and at one place. The best place to update this is CPU
> subsystem driver when registering the cpu devices.
>
> This patch introduces a new function arch_of_get_cpu_node and uses it
> to assign of_node. The definition of this function can be overridden
> by architecture specific implementation.
>
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> ---
>  drivers/base/cpu.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>
> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> index a16d20e..4b3047a 100644
> --- a/drivers/base/cpu.c
> +++ b/drivers/base/cpu.c
> @@ -28,6 +28,24 @@ static int cpu_subsys_match(struct device *dev, struct device_driver *drv)
>         return 0;
>  }
>
> +/**
> + * arch_of_get_cpu_node - Get device node associated with the given logical CPU
> + * @cpu: CPU number(logical index) for which device node is required
> + *
> + * The only purpose of this function is to retrieve the device node for the
> + * given logical CPU index. It should be used to intialise the of_node in
> + * cpu device. Once of_node in cpu device is populated, all the further
> + * references can use that instead.
> + *
> + * CPU logical to physical index mapping is architecure specific and is built
> + * before booting secondary cores. Hence this function is marked __weak and
> + * can be overridden by architecture specific implementation.
> + */
> +struct device_node * __weak arch_of_get_cpu_node(int cpu)
> +{
> +       return NULL;
> +}
> +
>  #ifdef CONFIG_HOTPLUG_CPU
>  static void change_cpu_under_node(struct cpu *cpu,
>                         unsigned int from_nid, unsigned int to_nid)
> @@ -289,6 +307,7 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
>         cpu->dev.release = cpu_device_release;
>         cpu->dev.offline_disabled = !cpu->hotpluggable;
>         cpu->dev.offline = !cpu_online(num);
> +       cpu->dev.of_node = arch_of_get_cpu_node(num);
>  #ifdef CONFIG_ARCH_HAS_CPU_AUTOPROBE
>         cpu->dev.bus->uevent = arch_cpu_uevent;
>  #endif
> --
> 1.8.1.2
>
>


From viresh.kumar at linaro.org  Tue Jul 16 02:29:11 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Tue, 16 Jul 2013 11:59:11 +0530
Subject: [RFC PATCH 02/11] ARM: DT/kernel: define ARM specific
 arch_of_get_cpu_node
In-Reply-To: <51E44943.7000600@gmail.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1373883732-26303-3-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <51E44943.7000600@gmail.com>
Message-ID: <CAKohponBwiHfty8er+xhT7CksfFDYZ=3cNyvZA-G0UDCj=tLsA@mail.gmail.com>

On 16 July 2013 00:40, Rob Herring <robherring2 at gmail.com> wrote:
> The powermac cpufreq driver could probably also be converted
> (arch/powerpc/platforms/powermac/cpufreq_64.c).

Its called: drivers/cpufreq/pmac64-cpufreq.c now.


From rnayak at ti.com  Tue Jul 16 02:30:03 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 16 Jul 2013 12:00:03 +0530
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51E44C48.3090905@ti.com>
References: <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <87mwpuakod.fsf@linaro.org>
 <20130710142633.GV5523@atomide.com> <20130710160704.GH18966@arwen.pp.htv.fi>
 <20130710161158.GA19716@arwen.pp.htv.fi> <20130711063209.GZ5523@atomide.com>
 <51DE8215.5060306@ti.com> <51DF508F.3050703@ti.com> <51E39A3F.6080106@ti.com>
 <51E3C85D.2010008@ti.com> <51E44C48.3090905@ti.com>
Message-ID: <51E4E86B.30807@ti.com>

On Tuesday 16 July 2013 12:53 AM, Suman Anna wrote:
> On 07/15/2013 05:01 AM, Rajendra Nayak wrote:
>> On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote:
>>> On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
>>>> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>>>>> Hi,
>>>>>
>>>>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>>>>>> * Felipe Balbi <balbi at ti.com> [130710 09:18]:
>>>>>>>
>>>>>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>>>>>> how about something like below ? It makes omap_device/hwmod and
>>>>>>>> pm_runtime agree on the initial state of the device and will prevent
>>>>>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>>>>>> during probe.
>>>>>>>>
>>>>>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>>>>>
>>>>>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>>>>>> Author: Felipe Balbi <balbi at ti.com>
>>>>>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>>>>>
>>>>>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>>>>>
>>>>>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>>>>>      initial state of the device, we will unidle the device
>>>>>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>>>>>      that the device is really active.
>>>>> Don't think that it's good idea (
>>>>> I've checked some driver's and think this patch will enable some devices
>>>>> unpredictably:
>>>>> - hwspinlock
>>>>> - mailbox
>>>>> - iommu
>>>>> - ipu
>>>>> All above devices need to be enabled on demand only (no
>>>>> pm_runtime_get*() calls in probe). More over, some of them have very
>>>>> specific enabling sequence - like ipu).
>>>>>
>>>>> May be Summan can say more on that.
>>>>
>>>> Indeed, this is a problem for any of the slave processor devices.
>>>> mailbox and iommu would be slaves to the remoteproc and the drivers have
>>>> a specific sequence of bringing up a processor. The current
>>>> hwmod/omap_device code is such that these devices will be left in reset
>>>> and the driver code use the omap_device_(de)assert_hardreset API
>>>> together with omap_device_enable code to bring up the devices. The
>>>> remoteproc driver also needs to assert the resets (there are other
>>>> problems associated with using omap_device_idle for remoteproc and
>>>> iommu) for bringing up the devices after a suspend sequence. hwspinlock
>>>> and mailbox may get away since they are in CORE domain, but definitely
>>>> an issue for iommu and remoteproc. I would think that this would also
>>>> affect other compute devices like IVAHD, ISS, SGX.
>>>
>>> Today, for these IPs I guess hwmod waits for the resets to be de-asserted, right?
> 
> Yes, the omap_device_enable bails out if the reset lines are still
> asserted, and the driver code deals with the resets currently. This code
> essentially achieves the same as if a HWMOD_INIT_NO_RESET flag is
> added to the corresponding hwmods - we do not want the hwmod/omap_device
> code to enable the processor IPs and leave the enabling/device
> management to the driver.
> 
>>>
>>>         /*
>>>          * If an IP block contains HW reset lines and all of them are
>>>          * asserted, we let integration code associated with that
>>>          * block handle the enable.  We've received very little
>>>          * information on what those driver authors need, and until
>>>          * detailed information is provided and the driver code is
>>>          * posted to the public lists, this is probably the best we
>>>          * can do.
>>>          */
>>>         if (_are_all_hardreset_lines_asserted(oh))
>>>                 return 0;
>>>
>>> What if this information is send back to omap_device() through a return value
>>> so omap_device() knows about this too, so it avoids marking the omap device as
>>> enabled? Wouldn't that fix the issue?
>>
>> I meant something like this..
>>
>> From 2fbea0dde0f72897089ef2e8e441b5e5bd6ea967 Mon Sep 17 00:00:00 2001
>> From: Rajendra Nayak <rnayak at ti.com>
>> Date: Mon, 15 Jul 2013 15:23:07 +0530
>> Subject: [PATCH] ARM: OMAP2+: Make omap_device aware of hwmod failing to
>>  enable/idle/shutdown the hwmods
>>
>> For IP blocks (mainly processors) which have hard reset lines, hwmod avoids
>> enable/idle/shutdown operations as long as all the hard reset lines are
>> kept asserted. However it does not return an error back to the caller (in some
>> cases the omap_device layer) to communicate back the failure to operate on the
>> hwmod.
>>
>> Fix this by making _enable()/_idle()/_shutdown() all return an error in such
>> cases, and also fix the omap_device layer to look at the return values coming
>> from hwmod operations before doing a omap_device level state transition.
>>
>> Signed-off-by: Rajendra Nayak <rnayak at ti.com>
> 
> Let me test this and get back to you if there are any issues.

Great, thanks for testing.

> 
> regards
> Suman
> 



From viresh.kumar at linaro.org  Tue Jul 16 02:31:37 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Tue, 16 Jul 2013 12:01:37 +0530
Subject: [RFC PATCH 00/11] ARM: DT: update cpu device of_node
In-Reply-To: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <CAKohponiPd6YZFiQGY3UXdtb0WDWsqsPoZJ-53z6Qjm4e7ap_w@mail.gmail.com>

On 15 July 2013 15:52,  <Sudeep.KarkadaNagesha at arm.com> wrote:
> Sudeep KarkadaNagesha (11):
>   cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes
>   cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
>   cpufreq: highbank-cpufreq: remove device tree parsing for cpu nodes
>   cpufreq: spear-cpufreq: remove device tree parsing for cpu nodes
>   cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes
>   cpufreq: arm_big_little: remove device tree parsing for cpu nodes

For cpufreq part:

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>


From s.hauer at pengutronix.de  Tue Jul 16 02:45:19 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 16 Jul 2013 08:45:19 +0200
Subject: [PATCH v2 1/1] ARM: imx: clk-pllv3: improve the timeout waiting
 method
In-Reply-To: <1373941400-32274-1-git-send-email-peter.chen@freescale.com>
References: <1373941400-32274-1-git-send-email-peter.chen@freescale.com>
Message-ID: <20130716064519.GH10995@pengutronix.de>

On Tue, Jul 16, 2013 at 10:23:20AM +0800, Peter Chen wrote:
> There are two improvements for this commit:
> 
> - Add comparing pll lock condition after while loop. It can
> fix potential fake timeout problem caused by the code is just
> scheduled out before compare the timeout, and the time of
> scheduling out are more than one jiffies.
> 
> - Move timeout assignment more close to compare the timeout.
> It can reduce the possibility the code is scheduled out, and
> the timeout can be more precise.
> 
> Signed-off-by: Peter Chen <peter.chen at freescale.com>

Acked-by: Sascha Hauer <s.hauer at pengutronix.de>

Sascha

> ---
> 
> Changes for v2:
> - Add more description for this improvement according to
> Fabio's suggstion.
> - Add comparsion after while loop according to Sascha's
> suggestion.
> 
>  arch/arm/mach-imx/clk-pllv3.c |   15 +++++++++++----
>  1 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/clk-pllv3.c b/arch/arm/mach-imx/clk-pllv3.c
> index 36aac94..4499db5 100644
> --- a/arch/arm/mach-imx/clk-pllv3.c
> +++ b/arch/arm/mach-imx/clk-pllv3.c
> @@ -50,7 +50,7 @@ struct clk_pllv3 {
>  static int clk_pllv3_prepare(struct clk_hw *hw)
>  {
>  	struct clk_pllv3 *pll = to_clk_pllv3(hw);
> -	unsigned long timeout = jiffies + msecs_to_jiffies(10);
> +	unsigned long timeout;
>  	u32 val;
>  
>  	val = readl_relaxed(pll->base);
> @@ -61,12 +61,19 @@ static int clk_pllv3_prepare(struct clk_hw *hw)
>  		val &= ~BM_PLL_POWER;
>  	writel_relaxed(val, pll->base);
>  
> +	timeout = jiffies + msecs_to_jiffies(10);
>  	/* Wait for PLL to lock */
> -	while (!(readl_relaxed(pll->base) & BM_PLL_LOCK))
> +	do {
> +		if (readl_relaxed(pll->base) & BM_PLL_LOCK)
> +			break;
>  		if (time_after(jiffies, timeout))
> -			return -ETIMEDOUT;
> +			break;
> +	} while (1);
>  
> -	return 0;
> +	if (readl_relaxed(pll->base) & BM_PLL_LOCK)
> +		return 0;
> +	else
> +		return -ETIMEDOUT;
>  }
>  
>  static void clk_pllv3_unprepare(struct clk_hw *hw)
> -- 
> 1.7.0.4
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From shawn.guo at linaro.org  Tue Jul 16 02:51:33 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 14:51:33 +0800
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <20130716015038.GD28375@S2101-09.ap.freescale.net>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
Message-ID: <20130716065130.GB30067@S2101-09.ap.freescale.net>

On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote:
> Hi Philipp,
> 
> On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
> > This driver implements a reset controller device that toggle a gpio
> > connected to a reset pin of a peripheral IC. The delay between assertion
> > and de-assertion of the reset signal can be configured via device tree.
> > 
> > Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> > Reviewed-by: Stephen Warren <swarren at nvidia.com>
> 
> I see this patch is very useful, as GPIOs are widely used to reset
> components/devices on board.  But I do not find the patch in v3.11-rc1.
> What's your plan about it?
> 
> Also, I'm wondering if we should register the driver a little bit
> early.  Please see the following patch.  If it makes sense to you,
> I can send the patch to you, or you can just quash it into yours.

And here is another change request.

Shawn

----8<---------------

>From 822a0c4fb7c99b371844ba7e957affcaa8cb1cfe Mon Sep 17 00:00:00 2001
From: Shawn Guo <shawn.guo at linaro.org>
Date: Sun, 14 Jul 2013 20:28:05 +0800
Subject: [PATCH] ENGR00269945: reset: handle cansleep case in gpio-reset

Some gpio reset may be backed by a gpio that can sleep, e.g. pca953x
gpio output.  For such gpio, gpio_set_value_cansleep() should be
called.  Otherwise, the WARN_ON(chip->can_sleep) in gpiod_set_value()
will be hit.  Add a gpio_cansleep() check to handle cansleep gpio.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/reset/gpio-reset.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
index 5d2515a..4f372f9 100644
--- a/drivers/reset/gpio-reset.c
+++ b/drivers/reset/gpio-reset.c
@@ -32,7 +32,10 @@ static void gpio_reset_set(struct reset_controller_dev *rcdev, int asserted)
 	if (drvdata->active_low)
 		value = !value;
 
-	gpio_set_value(drvdata->gpio, value);
+	if (gpio_cansleep(drvdata->gpio))
+		gpio_set_value_cansleep(drvdata->gpio, value);
+	else
+		gpio_set_value(drvdata->gpio, value);
 }
 
 static int gpio_reset(struct reset_controller_dev *rcdev, unsigned long id)
-- 
1.7.9.5




From anup.patel at linaro.org  Tue Jul 16 02:55:34 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Tue, 16 Jul 2013 12:25:34 +0530
Subject: [PATCH V2] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene host
Message-ID: <1373957734-21482-1-git-send-email-anup.patel@linaro.org>

This patch allows us to have X-Gene guest VCPU when using KVM arm64
on APM X-Gene host.

We add KVM_ARM_TARGET_XGENE_POTENZA for X-Gene Potenza compatible
guest VCPU and we return KVM_ARM_TARGET_XGENE_POTENZA in kvm_target_cpu()
when running on X-Gene host with Potenza core.

V2:
 - Renamed KVM_ARM_TARGET_XGENE_V8 to KVM_ARM_TARGET_XGENE_POTENZA

V1:
 - Initial patch with target named as KVM_ARM_TARGET_XGENE_V8

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
 arch/arm64/kvm/guest.c               |   34 ++++++++++++++++++++++------------
 arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
 3 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 5031f42..d9f026b 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -55,8 +55,9 @@ struct kvm_regs {
 #define KVM_ARM_TARGET_AEM_V8		0
 #define KVM_ARM_TARGET_FOUNDATION_V8	1
 #define KVM_ARM_TARGET_CORTEX_A57	2
+#define KVM_ARM_TARGET_XGENE_POTENZA	3
 
-#define KVM_ARM_NUM_TARGETS		3
+#define KVM_ARM_NUM_TARGETS		4
 
 /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
 #define KVM_ARM_DEVICE_TYPE_SHIFT	0
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 2c3ff67..a466244 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -207,19 +207,29 @@ int __attribute_const__ kvm_target_cpu(void)
 	unsigned long implementor = read_cpuid_implementor();
 	unsigned long part_number = read_cpuid_part_number();
 
-	if (implementor != ARM_CPU_IMP_ARM)
-		return -EINVAL;
-
-	switch (part_number) {
-	case ARM_CPU_PART_AEM_V8:
-		return KVM_ARM_TARGET_AEM_V8;
-	case ARM_CPU_PART_FOUNDATION:
-		return KVM_ARM_TARGET_FOUNDATION_V8;
-	case ARM_CPU_PART_CORTEX_A57:
-		/* Currently handled by the generic backend */
-		return KVM_ARM_TARGET_CORTEX_A57;
+	switch (implementor) {
+	case ARM_CPU_IMP_ARM:
+		switch (part_number) {
+		case ARM_CPU_PART_AEM_V8:
+			return KVM_ARM_TARGET_AEM_V8;
+		case ARM_CPU_PART_FOUNDATION:
+			return KVM_ARM_TARGET_FOUNDATION_V8;
+		case ARM_CPU_PART_CORTEX_A57:
+			return KVM_ARM_TARGET_CORTEX_A57;
+		default:
+			return -EINVAL;
+		}
+		break;
+	case ARM_CPU_IMP_APM:
+		switch (part_number) {
+		case APM_CPU_PART_POTENZA:
+			return KVM_ARM_TARGET_XGENE_POTENZA;
+		default:
+			return -EINVAL;
+		}
+		break;
 	default:
-		return -EINVAL;
+ 		return -EINVAL;
 	}
 }
 
diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
index 4268ab9..8fe6f76 100644
--- a/arch/arm64/kvm/sys_regs_generic_v8.c
+++ b/arch/arm64/kvm/sys_regs_generic_v8.c
@@ -90,6 +90,9 @@ static int __init sys_reg_genericv8_init(void)
 					  &genericv8_target_table);
 	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_CORTEX_A57,
 					  &genericv8_target_table);
+	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_XGENE_POTENZA,
+					  &genericv8_target_table);
+
 	return 0;
 }
 late_initcall(sys_reg_genericv8_init);
-- 
1.7.9.5



From andrew at lunn.ch  Tue Jul 16 02:59:52 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 16 Jul 2013 08:59:52 +0200
Subject: [PATCH 00/10] Orion Watchdog fixes
In-Reply-To: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130716065952.GA25043@lunn.ch>

On Mon, Jul 15, 2013 at 08:32:33PM -0300, Ezequiel Garcia wrote:
> This patchset introduces a bunch of fixes that removes the direct use of
> the shared timer control register, and also removes the need to include
> a mach-specific header.
> 
> With this changes the driver can be included in multiplatforms builds,
> and in particular be used for the Armada 370/XP SoC.

Hi Ezequiel

Maybe i'm missing something here. You are making use of
orion_timer_ctrl_clrset() from time-orion.c. How will this work on
370/XP which has a different clocksource driver?

Thanks
	Andrew


From shawn.guo at linaro.org  Tue Jul 16 03:04:22 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 15:04:22 +0800
Subject: [PATCH v2 1/1] ARM: imx: clk-pllv3: improve the timeout waiting
 method
In-Reply-To: <1373941400-32274-1-git-send-email-peter.chen@freescale.com>
References: <1373941400-32274-1-git-send-email-peter.chen@freescale.com>
Message-ID: <20130716070419.GC30067@S2101-09.ap.freescale.net>

On Tue, Jul 16, 2013 at 10:23:20AM +0800, Peter Chen wrote:
> There are two improvements for this commit:
> 
> - Add comparing pll lock condition after while loop. It can
> fix potential fake timeout problem caused by the code is just
> scheduled out before compare the timeout, and the time of
> scheduling out are more than one jiffies.
> 
> - Move timeout assignment more close to compare the timeout.
> It can reduce the possibility the code is scheduled out, and
> the timeout can be more precise.
> 
> Signed-off-by: Peter Chen <peter.chen at freescale.com>

Applied, thanks.



From kgene.kim at samsung.com  Tue Jul 16 03:09:24 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 16 Jul 2013 16:09:24 +0900
Subject: [PATCH v2 6/6] ARM: S3C24XX: Convert s3c2416 and s3c2443 to common
 clock framework
In-Reply-To: <201307100100.28992.heiko@sntech.de>
References: <201307100057.06061.heiko@sntech.de>
 <201307100100.28992.heiko@sntech.de>
Message-ID: <02cf01ce81f3$6777e5f0$3667b1d0$%kim@samsung.com>

Heiko St?bner wrote:
> 
> This converts the mentioned platforms to use the newly introduced driver
> for the common clock framework for them.
> 
> With this the whole legacy clock structure can go away too.
> 
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> ---
>  arch/arm/boot/dts/s3c2416-smdk2416.dts  |    7 +
>  arch/arm/boot/dts/s3c2416.dtsi          |   42 ++
>  arch/arm/mach-s3c24xx/Kconfig           |   14 +-
>  arch/arm/mach-s3c24xx/Makefile          |    5 +-
>  arch/arm/mach-s3c24xx/clock-s3c2416.c   |  171 --------
>  arch/arm/mach-s3c24xx/clock-s3c2443.c   |  212 ----------
>  arch/arm/mach-s3c24xx/common-s3c2443.c  |  677 ---------------------------
> ----

In this case, to use '-D' in format-patch would be better :-)

>  arch/arm/mach-s3c24xx/common.c          |   18 +-
>  arch/arm/mach-s3c24xx/common.h          |    8 +
>  arch/arm/mach-s3c24xx/mach-s3c2416-dt.c |   45 +-
>  arch/arm/mach-s3c24xx/mach-smdk2416.c   |    9 +-
>  arch/arm/mach-s3c24xx/mach-smdk2443.c   |    9 +-
>  12 files changed, 102 insertions(+), 1115 deletions(-)
>  delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2416.c
>  delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2443.c
>  delete mode 100644 arch/arm/mach-s3c24xx/common-s3c2443.c
> 
> diff --git a/arch/arm/boot/dts/s3c2416-smdk2416.dts
> b/arch/arm/boot/dts/s3c2416-smdk2416.dts
> index 59594cf..9caeb89 100644
> --- a/arch/arm/boot/dts/s3c2416-smdk2416.dts
> +++ b/arch/arm/boot/dts/s3c2416-smdk2416.dts
> @@ -19,6 +19,13 @@
>  		reg =  <0x30000000 0x4000000>;
>  	};
> 
> +	fixed-rate-clocks {
> +		xti {
> +			compatible = "samsung,clock-xti";
> +			clock-frequency = <12000000>;
> +		};
> +	};
> +
>  	serial at 50000000 {
>  		status = "okay";
>  		pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/s3c2416.dtsi
> b/arch/arm/boot/dts/s3c2416.dtsi
> index e6555bd..c19d99c 100644
> --- a/arch/arm/boot/dts/s3c2416.dtsi
> +++ b/arch/arm/boot/dts/s3c2416.dtsi
> @@ -8,6 +8,7 @@
>   * published by the Free Software Foundation.
>   */
> 
> +#include <dt-bindings/clock/samsung,s3c2443-clock.h>
>  #include "s3c24xx.dtsi"
>  #include "s3c2416-pinctrl.dtsi"
> 
> @@ -28,26 +29,53 @@
>  		compatible = "samsung,s3c2416-irq";
>  	};
> 
> +	clocks: clock-controller at 0x4c000000 {

+	clock: clock-controller at 0x4c000000 {

for keeping same format for Samsung stuff...

> +		compatible = "samsung,s3c2416-clock";
> +		reg = <0x4c000000 0x40>;
> +		#clock-cells = <1>;
> +	};
> +
>  	pinctrl at 56000000 {
>  		compatible = "samsung,s3c2416-pinctrl";
>  	};
> 
> +	timer at 51000000 {
> +		clocks = <&clocks PCLK_PWM>;

+		clocks = <&clock PCLK_PWM>;

And I'm not sure using definition PCLK_PWM is better here...

> +		clock-names = "timers";
> +	};
> +
>  	serial at 50000000 {
>  		compatible = "samsung,s3c2440-uart";
> +		clock-names = "uart", "clk_uart_baud2",
> +				"clk_uart_baud3";
> +		clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>,
> +				<&clocks SCLK_UART>;

Please use same ordering...for 'clocks' and 'clock-names'.
See above the timers...'clocks' then 'clock-names'...

>  	};
> 
>  	serial at 50004000 {
>  		compatible = "samsung,s3c2440-uart";
> +		clock-names = "uart", "clk_uart_baud2",
> +				"clk_uart_baud3";
> +		clocks = <&clocks PCLK_UART1>, <&clocks PCLK_UART1>,
> +				<&clocks SCLK_UART>;

Same as above.

>  	};
> 
>  	serial at 50008000 {
>  		compatible = "samsung,s3c2440-uart";
> +		clock-names = "uart", "clk_uart_baud2",
> +				"clk_uart_baud3";
> +		clocks = <&clocks PCLK_UART2>, <&clocks PCLK_UART2>,
> +				<&clocks SCLK_UART>;

Same as above.

>  	};
> 
>  	serial at 5000C000 {
>  		compatible = "samsung,s3c2440-uart";
>  		reg = <0x5000C000 0x4000>;
>  		interrupts = <1 18 24 4>, <1 18 25 4>;
> +		clock-names = "uart", "clk_uart_baud2",
> +				"clk_uart_baud3";
> +		clocks = <&clocks PCLK_UART3>, <&clocks PCLK_UART3>,
> +				<&clocks SCLK_UART>;

Same as above.

>  		status = "disabled";
>  	};
> 
> @@ -55,6 +83,10 @@
>  		compatible = "samsung,s3c6410-sdhci";
>  		reg = <0x4AC00000 0x100>;
>  		interrupts = <0 0 21 3>;
> +		clock-names = "hsmmc", "mmc_busclk.0",
> +				"mmc_busclk.2";
> +		clocks = <&clocks HCLK_HSMMC0>, <&clocks HCLK_HSMMC0>,
> +				<&clocks MUX_HSMMC0>;

Same.

>  		status = "disabled";
>  	};
> 
> @@ -62,18 +94,28 @@
>  		compatible = "samsung,s3c6410-sdhci";
>  		reg = <0x4A800000 0x100>;
>  		interrupts = <0 0 20 3>;
> +		clock-names = "hsmmc", "mmc_busclk.0",
> +				"mmc_busclk.2";
> +		clocks = <&clocks HCLK_HSMMC1>, <&clocks HCLK_HSMMC1>,
> +				<&clocks MUX_HSMMC1>;

Same.

>  		status = "disabled";
>  	};
> 
>  	watchdog at 53000000 {
>  		interrupts = <1 9 27 3>;
> +		clocks = <&clocks PCLK_WDT>;
> +		clock-names = "watchdog";
>  	};
> 
>  	rtc at 57000000 {
>  		compatible = "samsung,s3c2416-rtc";
> +		clocks = <&clocks PCLK_RTC>;
> +		clock-names = "rtc";
>  	};
> 
>  	i2c at 54000000 {
>  		compatible = "samsung,s3c2440-i2c";
> +		clocks = <&clocks PCLK_I2C0>;
> +		clock-names = "i2c";
>  	};
>  };
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index b8ec0ec..37cbe5f 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -49,9 +49,9 @@ config CPU_S3C2416
>  	select CPU_ARM926T
>  	select CPU_LLSERIAL_S3C2440
>  	select S3C2416_PM if PM
> -	select S3C2443_COMMON
>  	select S3C2443_DMA if S3C24XX_DMA
> -	select SAMSUNG_CLKSRC
> +	select COMMON_CLK
> +	select COMMON_CLK_S3C2443

Please put them in alphabetical ordering...

>  	help
>  	  Support for the S3C2416 SoC from the S3C24XX line
> 
> @@ -83,9 +83,9 @@ config CPU_S3C2443
>  	bool "SAMSUNG S3C2443"
>  	select CPU_ARM920T
>  	select CPU_LLSERIAL_S3C2440
> -	select S3C2443_COMMON
>  	select S3C2443_DMA if S3C24XX_DMA
> -	select SAMSUNG_CLKSRC
> +	select COMMON_CLK
> +	select COMMON_CLK_S3C2443

Same as above.

>  	help
>  	  Support for the S3C2443 SoC from the S3C24XX line
> 
> @@ -663,12 +663,6 @@ endif	# CPU_S3C2442
> 
>  if CPU_S3C2443 || CPU_S3C2416
> 
> -config S3C2443_COMMON
> -	bool
> -	help
> -	  Common code for the S3C2443 and similar processors, which
> includes
> -	  the S3C2416 and S3C2450.
> -
>  config S3C2443_DMA
>  	bool
>  	help

[...]

Thanks,
- Kukjin



From hesham.mahmoud at gmail.com  Tue Jul 16 03:11:39 2013
From: hesham.mahmoud at gmail.com (Hesham Mahmoud)
Date: Tue, 16 Jul 2013 07:11:39 +0000 (UTC)
Subject: Problems with semaphores, mutexes, and atomic?
References: <BANLkTikwGgrK0FFiee1a8PvDicJa-bUedg@mail.gmail.com>
Message-ID: <loom.20130716T090824-983@post.gmane.org>


Dave Hylands <dhylands <at> gmail.com> writes:

> 
> Hi,
> 
> I wrote a small test module to test semaphores, mutexes and atomic
> increments, and I've tested it with CONFIG_SMP=y with 1 and 2
> processors and with CONFIG_SMP disabled.
> 
> My test code can be found here:
> http://svn.hylands.org/linux/test-mutex/test-mutex.c
> (it's about 133 lines long).
> 
> For each test, I launch 100 threads, and then increment a counter,
> either inside a mutex_lock/unlock, a down/up, or do an atomic_inc.
> 
> Each thread performs the loop a number of times, and at the end the
> count often doesn't have the expected value if the locks were in fact
> atomic.
> 
> Typical output looks like:
> 
> 192.168.0.50  ~ # modprobe test-mutex
> [   26.220000] Testing mutex...
> [   26.230000]     Launching threads ..........
> [   26.300000]     Waiting for threads to finish ..........
> [   26.310000]   counter = 999888 FAIL
> [   26.310000] Testing semaphore...
> [   26.310000]     Launching threads ..........
> [   26.440000]     Waiting for threads to finish ..........
> [   27.810000]   counter = 999575 FAIL
> [   27.810000] Testing atomic...
> [   27.820000]     Launching threads ..........
> [   28.030000]     Waiting for threads to finish ..........
> [   28.040000]  counter = 9910929 FAIL
> 
> My processor info from /proc/cpuinfo looks like:
> 
> 192.168.0.50  ~ # cat /proc/cpuinfo
> Processor       : ARMv7 Processor rev 5 (v7l)
> processor       : 0
> BogoMIPS        : 1893.99
> 
> processor       : 1
> BogoMIPS        : 1893.99
> 
> Features        : swp half thumb fastmult vfp edsp neon vfpv3
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x2
> CPU part        : 0xc09
> CPU revision    : 5
> 
> I'm running 2.6.36.3, and some snippets from my boot log:
> 
> Uncompressing Linux... done, booting the kernel.
> Linux version 2.6.36.3 (dhylands <at> dave-ubuntu) (gcc version 4.5.1 (GCC)
> ) #40 SMP PREEMPT Sun Jun 19 13:41:47 PDT 2011
> CPU: ARMv7 Processor [412fc095] revision 5 (ARMv7), cr=10c53c7f
> CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
> 
> [    0.280000] CPU: Testing write buffer coherency: ok
> [    0.280000] Calibrating local timer... 474.46MHz.
> [    0.340000] L310 cache controller enabled
> [    0.340000] l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x7a450000
> 
> So given that I'm seeing failures even with CONFIG_SMP disabled, I
> have to wonder whether my test is valid, or whether our SoC has issues
> some where.
> 
> I even tried adding:
> 
>     smp_mb();
>     dsb();
> 
> after acquiring the lock and before releasing the lock, but I still
> see failures.
> 
> Any feedback would be appreciated, and I can provide more information,
> if needed.
> 

I ran this test on a PC. It gave me a FAILED result. I fixed it by
initializing the thread_Wait semaphore to locked state. It worked fine.

Failed:

Jul 16 02:57:12 ubuntu kernel: [ 1837.858846] Testing mutex...
Jul 16 02:57:12 ubuntu kernel: [ 1837.858868]     Launching threads .
Jul 16 02:57:12 ubuntu kernel: [ 1837.876590]     Waiting for threads to
finish .
Jul 16 02:57:12 ubuntu kernel: [ 1837.876652]   counter = 90000 FAIL
Jul 16 02:57:12 ubuntu kernel: [ 1837.876660] Testing semaphore...
Jul 16 02:57:12 ubuntu kernel: [ 1837.876688]     Launching threads .
Jul 16 02:57:12 ubuntu kernel: [ 1837.901929]     Waiting for threads to
finish .
Jul 16 02:57:12 ubuntu kernel: [ 1837.901956]   counter = 90000 FAIL
Jul 16 02:57:12 ubuntu kernel: [ 1837.901966] Testing atomic...
Jul 16 02:57:12 ubuntu kernel: [ 1837.901974]     Launching threads .
Jul 16 02:57:12 ubuntu kernel: [ 1837.931911]     Waiting for threads to
finish .
Jul 16 02:57:12 ubuntu kernel: [ 1837.931938]  counter = 900000 FAIL


Passed:
Jul 16 03:08:22 ubuntu kernel: [ 2507.982633] test_mutex_exit: called
Jul 16 03:11:06 ubuntu kernel: [ 2671.515674] Testing mutex...
Jul 16 03:11:06 ubuntu kernel: [ 2671.515700]     Launching threads ..........
Jul 16 03:11:06 ubuntu kernel: [ 2671.607958]     Waiting for threads to
finish ..........
Jul 16 03:11:06 ubuntu kernel: [ 2671.609115]   counter = 1000000 Pass
Jul 16 03:11:06 ubuntu kernel: [ 2671.609125] Testing semaphore...
Jul 16 03:11:06 ubuntu kernel: [ 2671.609153]     Launching threads ..........
Jul 16 03:11:06 ubuntu kernel: [ 2671.743826]     Waiting for threads to
finish ..........
Jul 16 03:11:06 ubuntu kernel: [ 2671.745109]   counter = 1000000 Pass
Jul 16 03:11:06 ubuntu kernel: [ 2671.745119] Testing atomic...
Jul 16 03:11:06 ubuntu kernel: [ 2671.745127]     Launching threads ..........
Jul 16 03:11:06 ubuntu kernel: [ 2671.950545]     Waiting for threads to
finish ..........
Jul 16 03:11:06 ubuntu kernel: [ 2671.952532]  counter = 10000000 Pass

$ uname -r
2.6.32-34-generic

Thanks,
-Hesham





From thomas.petazzoni at free-electrons.com  Tue Jul 16 03:20:59 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Jul 2013 09:20:59 +0200
Subject: [PATCH 00/10] Orion Watchdog fixes
In-Reply-To: <20130716065952.GA25043@lunn.ch>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130716065952.GA25043@lunn.ch>
Message-ID: <20130716092059.237ea729@skate>

Dear Andrew Lunn,

On Tue, 16 Jul 2013 08:59:52 +0200, Andrew Lunn wrote:

> Maybe i'm missing something here. You are making use of
> orion_timer_ctrl_clrset() from time-orion.c. How will this work on
> 370/XP which has a different clocksource driver?

I *think* the idea is that the Armada 370/XP driver will expose the
same function, so from the point of view of the watchdog driver, it
will just work. This set of patches is just some preparation patches on
the Orion watchdog driver, to later make it usable on Armada 370/XP.
The patches enabling its usage on Armada 370/XP will follow.

But Ezequiel will confirm all that, we had a discussion together about
this yesterday, so I guess what I said should be the plan, but it's
better if Ezequiel confirms, obviously :)

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From b32955 at freescale.com  Tue Jul 16 02:55:30 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 16 Jul 2013 14:55:30 +0800
Subject: [PATCH v2 1/3] serial: mxs: remove the MXS_AUART_DMA_CONFIG
In-Reply-To: <1373957732-16638-1-git-send-email-b32955@freescale.com>
References: <1373957732-16638-1-git-send-email-b32955@freescale.com>
Message-ID: <1373957732-16638-2-git-send-email-b32955@freescale.com>

The MXS_AUART_DMA_CONFIG is originally used to check if the DT node
is configured with the DMA property.

But now, the MXS_AUART_DMA_CONFIG is set unconditionally in the
serial_mxs_probe_dt(), so the check in the mxs_auart_settermios() is
not necessary anymore. This patch removes it.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 drivers/tty/serial/mxs-auart.c |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 4f5f161..465ef0b 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -134,7 +134,6 @@ enum mxs_auart_type {
 struct mxs_auart_port {
 	struct uart_port port;
 
-#define MXS_AUART_DMA_CONFIG	0x1
 #define MXS_AUART_DMA_ENABLED	0x2
 #define MXS_AUART_DMA_TX_SYNC	2  /* bit 2 */
 #define MXS_AUART_DMA_RX_READY	3  /* bit 3 */
@@ -640,7 +639,7 @@ static void mxs_auart_settermios(struct uart_port *u,
 		 * we can only implement the DMA support for auart
 		 * in mx28.
 		 */
-		if (is_imx28_auart(s) && (s->flags & MXS_AUART_DMA_CONFIG)) {
+		if (is_imx28_auart(s)) {
 			if (!mxs_auart_dma_init(s))
 				/* enable DMA tranfer */
 				ctrl2 |= AUART_CTRL2_TXDMAE | AUART_CTRL2_RXDMAE
@@ -1002,8 +1001,6 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
 	}
 	s->port.line = ret;
 
-	s->flags |= MXS_AUART_DMA_CONFIG;
-
 	return 0;
 }
 
-- 
1.7.1




From b32955 at freescale.com  Tue Jul 16 02:55:31 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 16 Jul 2013 14:55:31 +0800
Subject: [PATCH v2 2/3] serial: mxs: enable the DMA only when the RTS/CTS is
 valid
In-Reply-To: <1373957732-16638-1-git-send-email-b32955@freescale.com>
References: <1373957732-16638-1-git-send-email-b32955@freescale.com>
Message-ID: <1373957732-16638-3-git-send-email-b32955@freescale.com>

The original DMA support works only when RTS/CTS is enabled.
But after several patches, DMA support has lost this limit.

This patch adds an optional property for the UART DT node
which indicates the UART has RTS and CTS lines.

This patch also adds a macro MXS_AUART_RTSCTS, and uses it to check
RTS/CTS before we enable the DMA for the UART.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 .../bindings/tty/serial/fsl-mxs-auart.txt          |    4 ++++
 drivers/tty/serial/mxs-auart.c                     |    5 ++++-
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
index 2c00ec6..59a40f1 100644
--- a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
@@ -10,6 +10,10 @@ Required properties:
   Refer to dma.txt and fsl-mxs-dma.txt for details.
 - dma-names: "rx" for RX channel, "tx" for TX channel.
 
+Optional properties:
+- fsl,uart-has-rtscts : Indicate the UART has RTS and CTS lines,
+	it also means you enable the DMA support for this UART.
+
 Example:
 auart0: serial at 8006a000 {
 	compatible = "fsl,imx28-auart", "fsl,imx23-auart";
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 465ef0b..27532fd 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -134,6 +134,7 @@ enum mxs_auart_type {
 struct mxs_auart_port {
 	struct uart_port port;
 
+#define MXS_AUART_RTSCTS	1
 #define MXS_AUART_DMA_ENABLED	0x2
 #define MXS_AUART_DMA_TX_SYNC	2  /* bit 2 */
 #define MXS_AUART_DMA_RX_READY	3  /* bit 3 */
@@ -639,7 +640,7 @@ static void mxs_auart_settermios(struct uart_port *u,
 		 * we can only implement the DMA support for auart
 		 * in mx28.
 		 */
-		if (is_imx28_auart(s)) {
+		if (is_imx28_auart(s) && (s->flags & MXS_AUART_RTSCTS)) {
 			if (!mxs_auart_dma_init(s))
 				/* enable DMA tranfer */
 				ctrl2 |= AUART_CTRL2_TXDMAE | AUART_CTRL2_RXDMAE
@@ -1001,6 +1002,8 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
 	}
 	s->port.line = ret;
 
+	if (of_get_property(np, "fsl,uart-has-rtscts", NULL))
+		s->flags |= MXS_AUART_RTSCTS;
 	return 0;
 }
 
-- 
1.7.1




From b32955 at freescale.com  Tue Jul 16 02:55:29 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 16 Jul 2013 14:55:29 +0800
Subject: [PATCH v2 0/3] serial: mxs-auart: add RTS/CTS check for DMA support
Message-ID: <1373957732-16638-1-git-send-email-b32955@freescale.com>

The original DMA support works only when RTS/CTS is enabled.
But after several patches, DMA support has lost this limit.
So a UART without the RTS/CTS lines may also enables the DMA support
for it, but it may does not work or works abnormally (since without the
RTS/CTS signals, the TX/RX may not works)		

This patch set remove the unnecessary macro MXS_AUART_DMA_CONFIG,
and adds an optional property "fsl,uart-has-rtscts" for the UART DT node
which indicates the UART has RTS and CTS lines.

This patch set also adds a macro MXS_AUART_RTSCTS, and uses it to check
RTS/CTS before we enable the DMA for the UART.

At last, enable the DMA support for auart0 in the imx28-evk boards.

v1 --> v2:
	[0] changed the comments.
	[1] fix the typos.

Huang Shijie (3):
  serial: mxs: remove the MXS_AUART_DMA_CONFIG
  serial: mxs: enable the DMA only when the RTS/CTS is valid
  ARM: dts: imx28-evk: add the RTS/CTS property for auart0

 .../bindings/tty/serial/fsl-mxs-auart.txt          |    4 ++++
 arch/arm/boot/dts/imx28-evk.dts                    |    1 +
 drivers/tty/serial/mxs-auart.c                     |    8 ++++----
 3 files changed, 9 insertions(+), 4 deletions(-)




From b32955 at freescale.com  Tue Jul 16 02:55:32 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 16 Jul 2013 14:55:32 +0800
Subject: [PATCH v2 3/3] ARM: dts: imx28-evk: add the RTS/CTS property for
 auart0
In-Reply-To: <1373957732-16638-1-git-send-email-b32955@freescale.com>
References: <1373957732-16638-1-git-send-email-b32955@freescale.com>
Message-ID: <1373957732-16638-4-git-send-email-b32955@freescale.com>

Add the RTS/CTS property for auart0 which means we enable the
DMA support for it.

Signed-off-by: Huang Shijie <b32955 at freescale.com>
---
 arch/arm/boot/dts/imx28-evk.dts |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index e035f46..15715d9 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -220,6 +220,7 @@
 			auart0: serial at 8006a000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&auart0_pins_a>;
+				fsl,uart-has-rtscts;
 				status = "okay";
 			};
 
-- 
1.7.1




From kgene.kim at samsung.com  Tue Jul 16 03:30:19 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 16 Jul 2013 16:30:19 +0900
Subject: [PATCH 2/6] clk: exynos4: Remove unused function
In-Reply-To: <1373533334-5169-3-git-send-email-sachin.kamat@linaro.org>
References: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
 <1373533334-5169-3-git-send-email-sachin.kamat@linaro.org>
Message-ID: <02d701ce81f6$532ab9d0$f9802d70$%kim@samsung.com>

Sachin Kamat wrote:
> 
> Subsequent to the cleanup in commit 3c70348c7c ("ARM: EXYNOS:
> Remove legacy timer initialization code"), this function has no more
> users. Hence remove it.
> 
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> ---
>  drivers/clk/samsung/clk-exynos4.c |   14 --------------
>  1 file changed, 14 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-
> exynos4.c
> index 18eadc4..75635eb 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -969,20 +969,6 @@ static void __init
> exynos4_clk_register_finpll(unsigned long xom)
> 
>  }
> 
> -/*
> - * This function allows non-dt platforms to specify the clock speed of
> the
> - * xxti and xusbxti clocks. These clocks are then registered with the
> specified
> - * clock speed.
> - */
> -void __init exynos4_clk_register_fixed_ext(unsigned long xxti_f,
> -						  unsigned long xusbxti_f)
> -{
> -	exynos4_fixed_rate_ext_clks[0].fixed_rate = xxti_f;
> -	exynos4_fixed_rate_ext_clks[1].fixed_rate = xusbxti_f;
> -	samsung_clk_register_fixed_rate(exynos4_fixed_rate_ext_clks,
> -			ARRAY_SIZE(exynos4_fixed_rate_ext_clks));
> -}
> -
>  static __initdata struct of_device_id ext_clk_match[] = {
>  	{ .compatible = "samsung,clock-xxti", .data = (void *)0, },
>  	{ .compatible = "samsung,clock-xusbxti", .data = (void *)1, },
> --
> 1.7.9.5

And need following?

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 3e156bc..1037da0 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -27,7 +27,6 @@ void exynos_init_late(void);

 /* ToDo: remove these after migrating legacy exynos4 platforms to dt */
 void exynos4_clk_init(struct device_node *np, int is_exynos4210, void
__iomem *reg_base, unsigned long xom);
-void exynos4_clk_register_fixed_ext(unsigned long, unsigned long);

 void exynos_firmware_init(void);

- Kukjin



From andrew at lunn.ch  Tue Jul 16 03:31:01 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 16 Jul 2013 09:31:01 +0200
Subject: [PATCH 00/10] Orion Watchdog fixes
In-Reply-To: <20130716092059.237ea729@skate>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130716065952.GA25043@lunn.ch> <20130716092059.237ea729@skate>
Message-ID: <20130716073101.GB25043@lunn.ch>

On Tue, Jul 16, 2013 at 09:20:59AM +0200, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Tue, 16 Jul 2013 08:59:52 +0200, Andrew Lunn wrote:
> 
> > Maybe i'm missing something here. You are making use of
> > orion_timer_ctrl_clrset() from time-orion.c. How will this work on
> > 370/XP which has a different clocksource driver?
> 
> I *think* the idea is that the Armada 370/XP driver will expose the
> same function, so from the point of view of the watchdog driver, it
> will just work.

Hi Thomas

That was what i was thinking would happen. And then i started to
wonder how well the kernel linker deals with multiple definitions of
the same symbol. Dove and 370/XP can end up in the same kernel. So we
need to have both orion-timer and the 370/XP timer in the same kernel,
so we end up with the same symbol in the kernel twice...

Lets wait for Ezequiel to answer.

   Andrew


From u.kleine-koenig at pengutronix.de  Tue Jul 16 03:33:05 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Tue, 16 Jul 2013 09:33:05 +0200
Subject: [PATCH 2/3] serial: mxs: enable the DMA only when the rts/cts is
 enabled
In-Reply-To: <51E3D499.3060902@freescale.com>
References: <1373857736-30108-1-git-send-email-b32955@freescale.com>
 <1373857736-30108-2-git-send-email-b32955@freescale.com>
 <20130715082716.GM12139@pengutronix.de>
 <51E3B5B5.1030706@freescale.com>
 <20130715090755.GN12139@pengutronix.de>
 <51E3D499.3060902@freescale.com>
Message-ID: <20130716073305.GP12139@pengutronix.de>

On Mon, Jul 15, 2013 at 06:53:13PM +0800, Huang Shijie wrote:
> ? 2013?07?15? 17:07, Uwe Kleine-K?nig ??:
> >Hello,
> >
> >On Mon, Jul 15, 2013 at 04:41:25PM +0800, Huang Shijie wrote:
> >>? 2013?07?15? 16:27, Uwe Kleine-K?nig ??:
> >>>do you want to say that the driver fails to only enable DMA when RTS/CTS
> >>>are available; or that today the driver can handle DMA just fine even
> >>>without RTS/CTS? I interpret your commit log as the latter, your patch
> >>>implements the former however.
> >>in the mxs-auart, if the RTS/CTS is not invalid, the DMA should be
> >>not enabled.
> >>
> >>But current code lost the limit, a uart without the RTS/CTS may also
> >>enables the DMA in which case the uart
> >>may does not run or run in a abnormal way.
> >So this sounds like a fix that should go into stable and so preferably
> >should be the first patch in your series.
> This patch depends on the first patch. :)
But it's not a hard dependency.

> >Something like:
> >
> >	serial: mxs-auart: DMA unreliable without RTS/CTS
> >
> >	According to [add some document name here] DMA doesn't work
> >	reliable without hardware handshaking. So make DMA dependant on
> >	a newly introdused property "fsl,uart-has-rtscts".
> >
> >	Cc: stable at kernel.org # [first affected version]
> >
> >The flag is only used to decide if dma should be enabled. So I think an
> >in-code comment would be nice, too. Is it still correct to set
> ok.
> >AUART_CTRL2_RTSEN and AUART_CTRL2_RTS and read AUART_STAT_CTS when
> >fsl,uart-has-rtscts is not provided?
> i think it's correct. (if i have a imx28-evk board, i can test it.)
> 
> If you enable the RTS/CTS from the application, the
> tty_port_cts_enabled() will be true.
> we will set the AUART_CTRL2_RTSEN in the end when the
> "fsl,uart-has-rtscts" is enabled.
> 
> 
> >(BTW, mxs_auart_set_mctrl has:
> >
> >	u32 ctrl = readl(u->membase + AUART_CTRL2);
> >
> >	ctrl&= ~(AUART_CTRL2_RTSEN | AUART_CTRL2_RTS);
> >         if (mctrl&  TIOCM_RTS) {
> >                 if (tty_port_cts_enabled(&u->state->port))
> >                         ctrl |= AUART_CTRL2_RTSEN;
> >                 else
> >                         ctrl |= AUART_CTRL2_RTS;
> >         }
> >
> >	s->ctrl = mctrl;
> >
> >A comment for the diligent reader about the difference between RTSEN and
> >RTS would be nice. Also I wonder if shadowing mctrl is sensible and used
> Please see the spec about the RTSEN and RTS.
Right, it's not hard for me. Other might not have the manual handy, so
a comment telling:

> RTSEN enable the flow control by the hardware;
> RTS enable the flow control by the software.

would be nice.

Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From kgene.kim at samsung.com  Tue Jul 16 03:34:23 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 16 Jul 2013 16:34:23 +0900
Subject: [PATCH 1/6] clk: exynos4: Staticize local symbols
In-Reply-To: <1373533334-5169-2-git-send-email-sachin.kamat@linaro.org>
References: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
 <1373533334-5169-2-git-send-email-sachin.kamat@linaro.org>
Message-ID: <02d801ce81f6$e480fe80$ad82fb80$%kim@samsung.com>

Sachin Kamat wrote:
> 
> Symbols referenced only in this file are made static.
> 
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> ---
>  drivers/clk/samsung/clk-exynos4.c |   30 ++++++++++++++++--------------
>  1 file changed, 16 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-
> exynos4.c
> index 1bdb882..18eadc4 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c

[...]

> @@ -975,7 +975,7 @@ static void __init
> exynos4_clk_register_finpll(unsigned long xom)
>   * clock speed.
>   */
>  void __init exynos4_clk_register_fixed_ext(unsigned long xxti_f,
> -						unsigned long xusbxti_f)
> +						  unsigned long xusbxti_f)

Why?

>  {
>  	exynos4_fixed_rate_ext_clks[0].fixed_rate = xxti_f;
>  	exynos4_fixed_rate_ext_clks[1].fixed_rate = xusbxti_f;
> @@ -990,7 +990,9 @@ static __initdata struct of_device_id ext_clk_match[]
> = {
>  };
> 
>  /* register exynos4 clocks */
> -void __init exynos4_clk_init(struct device_node *np, enum exynos4_soc
> exynos4_soc, void __iomem *reg_base, unsigned long xom)
> +static void __init exynos4_clk_init(struct device_node *np,
> +				    enum exynos4_soc exynos4_soc,
> +				    void __iomem *reg_base, unsigned long
xom)
>  {
>  	struct clk *apll, *mpll, *epll, *vpll;
> 
> --
> 1.7.9.5

And don't we need following?

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 3e156bc..3a34f1e 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -26,7 +26,6 @@ void exynos5_restart(enum reboot_mode mode, const char
*cmd);
 void exynos_init_late(void);

 /* ToDo: remove these after migrating legacy exynos4 platforms to dt */
-void exynos4_clk_init(struct device_node *np, int is_exynos4210, void
__iomem *reg_base, unsigned long xom);
 void exynos4_clk_register_fixed_ext(unsigned long, unsigned long);

 void exynos_firmware_init(void);

- Kukjin



From kgene.kim at samsung.com  Tue Jul 16 03:36:26 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 16 Jul 2013 16:36:26 +0900
Subject: [PATCH 0/6] clk: exynos: Some fixes and cleanup
In-Reply-To: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
References: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <02dc01ce81f7$2d9fb6b0$88df2410$%kim@samsung.com>

Sachin Kamat wrote:
> 
> Resending some of patches (1, 3 and 5) as per discussion in thread [1].
> Other patches in the series are new.
> 
> [1] http://comments.gmane.org/gmane.linux.kernel.samsung-soc/19933
> 
> Sachin Kamat (6):
>   clk: exynos4: Staticize local symbols
>   clk: exynos4: Remove unused function
>   clk: exynos5250: Staticize local symbols
>   clk: exynos5420: Staticize local symbols
>   clk: exynos5440: Staticize local symbols
>   clk: exynos-audss: Staticize exynos_audss_clk_init
> 
>  drivers/clk/samsung/clk-exynos-audss.c |    2 +-
>  drivers/clk/samsung/clk-exynos4.c      |   42
++++++++++++-----------------
> ---
>  drivers/clk/samsung/clk-exynos5250.c   |   14 +++++------
>  drivers/clk/samsung/clk-exynos5420.c   |   14 +++++------
>  drivers/clk/samsung/clk-exynos5440.c   |   14 +++++------
>  5 files changed, 37 insertions(+), 49 deletions(-)
> 
> --
> 1.7.9.5

There are small comments on 1st and 2nd patches.
Others look good to me.

For 3rd~6th patches:
Acked-by: Kukjin Kim <kgene.kim at samsung.com>

Thanks,
- Kukjin



From shawn.guo at linaro.org  Tue Jul 16 03:46:54 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 15:46:54 +0800
Subject: [PATCH 03/22] pinctrl: pinctrl-imx: add imx25 pinctrl driver
In-Reply-To: <1373900227-341-4-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-4-git-send-email-denis@eukrea.com>
Message-ID: <20130716074650.GD30067@S2101-09.ap.freescale.net>

On Mon, Jul 15, 2013 at 04:56:48PM +0200, Denis Carikli wrote:
> This is mostly cut and paste from the imx35 pinctrl driver.
> The data was generated using sed and awk on
>   arch/arm/plat-mxc/include/mach/iomux-mx25.h.
> 
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  .../bindings/pinctrl/fsl,imx25-pinctrl.txt         |   33 ++
>  arch/arm/boot/dts/imx25-pinfunc.h                  |  513 ++++++++++++++++++++
>  arch/arm/boot/dts/imx25.dtsi                       |    1 +
>  arch/arm/mach-imx/Kconfig                          |    2 +
>  drivers/pinctrl/Kconfig                            |    8 +
>  drivers/pinctrl/Makefile                           |    1 +
>  drivers/pinctrl/pinctrl-imx25.c                    |  351 ++++++++++++++

Either we split it into driver part and mach part, or I need an ACK from
pinctrl maintainer to take the patch via IMX tree.

Shawn



From akpm at linux-foundation.org  Tue Jul 16 03:47:27 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 16 Jul 2013 00:47:27 -0700
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <51E472D4.5060307@zytor.com>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130712075602.GA4002@gmail.com>
 <20130715150342.35f7620ffe0835e3e2bc37d0@linux-foundation.org>
 <51E472D4.5060307@zytor.com>
Message-ID: <20130716004727.b60b2c96.akpm@linux-foundation.org>

On Mon, 15 Jul 2013 15:08:20 -0700 "H. Peter Anvin" <hpa at zytor.com> wrote:

> On 07/15/2013 03:03 PM, Andrew Morton wrote:
> > 
> > I don't know how to do this.  Any suggestions?
> > 
> > It has to be done at `make config' time.  We'd need to probe for the
> > presence of lz4c and then....  what?
> > 
> > Is there any precedent for this?
> > 
> > I don't think we can just ignore the absence of lz4c - the user has
> > selected a config which his system cannot build.  The problem lies
> > within randconfig itself.
> > 
> 
> We keep running over the need to be able to have kconfig run tests on
> the build system (for toolchain support or for optional tools needed);
> running them in the Makefiles (i.e. at Kbuild time) is simply too late.
> 

Would it make sense to extend Kconfig's `depends'?

	depends on $(shell-command)

I don't know how practical that would be to implement...


From shawn.guo at linaro.org  Tue Jul 16 03:49:34 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 15:49:34 +0800
Subject: [PATCH 04/22] arm/dts: imx25.dtsi: Add some pinmux pins.
In-Reply-To: <1373900227-341-5-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-5-git-send-email-denis@eukrea.com>
Message-ID: <20130716074931.GE30067@S2101-09.ap.freescale.net>

On Mon, Jul 15, 2013 at 04:56:49PM +0200, Denis Carikli wrote:
> Uart1, fec, i2c1,esdhc1 and audmux were added.
> 
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  arch/arm/boot/dts/imx25.dtsi |   56 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 56 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
> index f098603..b318106 100644
> --- a/arch/arm/boot/dts/imx25.dtsi
> +++ b/arch/arm/boot/dts/imx25.dtsi
> @@ -177,6 +177,62 @@
>  			iomuxc at 43fac000{
>  				compatible = "fsl,imx25-iomuxc";
>  				reg = <0x43fac000 0x4000>;

Have a blank line here.

> +				audmux {
> +					pinctrl_audmux_1: audmuxgrp-1 {
> +						fsl,pins = <
> +							MX25_PAD_KPP_COL3__AUD5_TXFS 0xe0
> +							MX25_PAD_KPP_COL2__AUD5_TXC  0xe0
> +							MX25_PAD_KPP_COL1__AUD5_RXD  0xe0
> +							MX25_PAD_KPP_COL0__AUD5_TXD  0xe0
> +						>;
> +					};
> +				};

Please have a blank line between nodes, and sort the these nodes
in alphabet.

Shawn

> +				uart1 {
> +					pinctrl_uart1_1: uartgrp-1 {
> +						fsl,pins = <
> +							MX25_PAD_UART1_RTS__UART1_RTS 0xe0
> +							MX25_PAD_UART1_CTS__UART1_CTS 0xe0
> +							MX25_PAD_UART1_TXD__UART1_TXD 0x10000
> +							MX25_PAD_UART1_RXD__UART1_RXD 0xc0
> +						>;
> +					};
> +				};
> +				fec {
> +					pinctrl_fec_1: fecgrp-1 {
> +						fsl,pins = <
> +							MX25_PAD_FEC_MDC__FEC_MDC       0x10000
> +							MX25_PAD_FEC_MDIO__FEC_MDIO     0x1f0
> +							MX25_PAD_FEC_TDATA0__FEC_TDATA0 0x10000
> +							MX25_PAD_FEC_TDATA1__FEC_TDATA1 0x10000
> +							MX25_PAD_FEC_TX_EN__FEC_TX_EN   0x10000
> +							MX25_PAD_FEC_RDATA0__FEC_RDATA0 0x100c0
> +							MX25_PAD_FEC_RDATA1__FEC_RDATA1 0x100c0
> +							MX25_PAD_FEC_RX_DV__FEC_RX_DV   0x100c0
> +							MX25_PAD_FEC_TX_CLK__FEC_TX_CLK 0x1c0
> +						>;
> +					};
> +
> +				};
> +				i2c1 {
> +					pinctrl_i2c1_1: i2c1grp-1 {
> +						fsl,pins = <
> +							MX25_PAD_I2C1_CLK__I2C1_CLK 0x10000
> +							MX25_PAD_I2C1_DAT__I2C1_DAT 0x10000
> +						>;
> +					};
> +				};
> +				esdhc1 {
> +					pinctrl_esdhc1_1: esdhc1grp-1 {
> +						fsl,pins = <
> +							MX25_PAD_SD1_CMD__SD1_CMD      0xd0
> +							MX25_PAD_SD1_CLK__SD1_CLK      0xd0
> +							MX25_PAD_SD1_DATA0__SD1_DATA0  0xd0
> +							MX25_PAD_SD1_DATA1__SD1_DATA1  0xd0
> +							MX25_PAD_SD1_DATA2__SD1_DATA2  0xd0
> +							MX25_PAD_SD1_DATA3__SD1_DATA3  0xd0
> +						>;
> +					};
> +				};
>  			};
>  
>  			audmux at 43fb0000 {
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From sebastian.hesselbarth at gmail.com  Tue Jul 16 03:48:56 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue, 16 Jul 2013 09:48:56 +0200
Subject: [PATCH 00/10] Orion Watchdog fixes
In-Reply-To: <20130716073101.GB25043@lunn.ch>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130716065952.GA25043@lunn.ch> <20130716092059.237ea729@skate>
 <20130716073101.GB25043@lunn.ch>
Message-ID: <13fe673f255.2784.107cef0f820c2f5d7b7f41463071c310@gmail.com>

Andrew, Thomas,

In the discussion about orion clocksource Russell was proposing a generic 
thread-safe write. That puts a single lock around all those writes. Of 
course, it will also blocked by totally unrelated thread-safe register 
accesses but should prevent us from having dozens of locks and solves the 
symbol issue.

Sebastian



On July 16, 2013 9:31:01 AM Andrew Lunn <andrew at lunn.ch> wrote:
> On Tue, Jul 16, 2013 at 09:20:59AM +0200, Thomas Petazzoni wrote:
> > Dear Andrew Lunn,
> > On Tue, 16 Jul 2013 08:59:52 +0200, Andrew Lunn wrote:
> > > Maybe i'm missing something here. You are making use of
> > > orion_timer_ctrl_clrset() from time-orion.c. How will this work on
> > > 370/XP which has a different clocksource driver?
> > I *think* the idea is that the Armada 370/XP driver will expose the
> > same function, so from the point of view of the watchdog driver, it
> > will just work.
>
> Hi Thomas
>
> That was what i was thinking would happen. And then i started to
> wonder how well the kernel linker deals with multiple definitions of
> the same symbol. Dove and 370/XP can end up in the same kernel. So we
> need to have both orion-timer and the 370/XP timer in the same kernel,
> so we end up with the same symbol in the kernel twice...
>
> Lets wait for Ezequiel to answer.
>
>    Andrew




From josh.wu at atmel.com  Tue Jul 16 03:54:54 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Tue, 16 Jul 2013 15:54:54 +0800
Subject: [PATCH 1/5] iio: at91: use adc_clk_khz to make the calculation
 not easy to large than u32.
In-Reply-To: <20130715125213.GB2962@lukather>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-2-git-send-email-josh.wu@atmel.com>
 <20130715125213.GB2962@lukather>
Message-ID: <51E4FC4E.2010203@atmel.com>

Hi, Maxime

On 7/15/2013 8:52 PM, Maxime Ripard wrote:
> Hi Josh,
>
> On Sun, Jul 14, 2013 at 04:04:25PM +0800, Josh Wu wrote:
>> for example, if adc_clk is 20Mhz and start-up time set as larger than 215us.
>> then the calculation "st->startup_time * adc_clk_khz" will out of u32.
>>
>> In this patch, it will use khz unit for adc_clk, that avoids above problem.
>>
>> Signed-off-by: Josh Wu <josh.wu at atmel.com>
> Maybe we can have a slightly better commit log here, like:
>
> ------8<-----------
> iio: at91: Fix adc_clk overflow
>
> The adc_clk variable is currently defined using a 32-bits unsigned
> integer, which will overflow under some very valid range of operations.
>
> Such overflow will occur if, for example, the parent clock is set to a
> 20MHz frequency and the ADC startup time is larger than 215ns.
>
> To fix this, introduce an intermediate variable holding the clock rate
> in kHz.
>
> --------8<---------------
>
> Or something like that.
>
> For the patch itself, I'm happy about it. You can add my Acked-by.

Thank you. Your commit log is better. I will fix the commit log base on 
your commit in next version.

>
> Thanks!
> Maxime
>

Best Regards,
Josh Wu


From akpm at linux-foundation.org  Tue Jul 16 03:56:11 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 16 Jul 2013 00:56:11 -0700
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130716004727.b60b2c96.akpm@linux-foundation.org>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130712075602.GA4002@gmail.com>
 <20130715150342.35f7620ffe0835e3e2bc37d0@linux-foundation.org>
 <51E472D4.5060307@zytor.com>
 <20130716004727.b60b2c96.akpm@linux-foundation.org>
Message-ID: <20130716005611.e4ccab02.akpm@linux-foundation.org>

On Tue, 16 Jul 2013 00:47:27 -0700 Andrew Morton <akpm at linux-foundation.org> wrote:

> On Mon, 15 Jul 2013 15:08:20 -0700 "H. Peter Anvin" <hpa at zytor.com> wrote:
> 
> > On 07/15/2013 03:03 PM, Andrew Morton wrote:
> > > 
> > > I don't know how to do this.  Any suggestions?
> > > 
> > > It has to be done at `make config' time.  We'd need to probe for the
> > > presence of lz4c and then....  what?
> > > 
> > > Is there any precedent for this?
> > > 
> > > I don't think we can just ignore the absence of lz4c - the user has
> > > selected a config which his system cannot build.  The problem lies
> > > within randconfig itself.
> > > 
> > 
> > We keep running over the need to be able to have kconfig run tests on
> > the build system (for toolchain support or for optional tools needed);
> > running them in the Makefiles (i.e. at Kbuild time) is simply too late.
> > 
> 
> Would it make sense to extend Kconfig's `depends'?
> 
> 	depends on $(shell-command)
> 
> I don't know how practical that would be to implement...

Or, easier and faster, run some front-end script which generates
once-off Kconfig symbols.

	if [ -x /bin/lz4c ]
	then
		echo CONFIG_HAVE_LZ4C
	fi

then munge the output of that script into the Kconfig run and do

	depends on HAVE_LZ4C


From josh.wu at atmel.com  Tue Jul 16 03:55:28 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Tue, 16 Jul 2013 15:55:28 +0800
Subject: [PATCH 4/5] iio: at91: add an optional dt property for for adc
 clock hz.
In-Reply-To: <20130715130610.GD2962@lukather>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-5-git-send-email-josh.wu@atmel.com>
 <20130715130610.GD2962@lukather>
Message-ID: <51E4FC70.3050207@atmel.com>

Hi, Maxime

On 7/15/2013 9:06 PM, Maxime Ripard wrote:
> Hi Josh,
>
> On Sun, Jul 14, 2013 at 04:04:28PM +0800, Josh Wu wrote:
>> Signed-off-by: Josh Wu <josh.wu at atmel.com>
>> ---
>>   Documentation/devicetree/bindings/arm/atmel-adc.txt |    2 ++
>>   drivers/iio/adc/at91_adc.c                          |    8 +++++++-
>>   2 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> index 16769d9..0db2945 100644
>> --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> @@ -27,6 +27,8 @@ Optional properties:
>>   		       resolution will be used.
>>     - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
>>     - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
>> +  - atmel,adc-clock-rate: ADC clock rate. If not specified, use the default
>> +			  adc_op_clk.
>>    
>>   Optional trigger Nodes:
>>     - Required properties:
>> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
>> index e93a075..8f1386f 100644
>> --- a/drivers/iio/adc/at91_adc.c
>> +++ b/drivers/iio/adc/at91_adc.c
>> @@ -47,6 +47,7 @@ struct at91_adc_caps {
>>   
>>   struct at91_adc_state {
>>   	struct clk		*adc_clk;
>> +	u32			adc_clk_rate;
>>   	u16			*buffer;
>>   	unsigned long		channels_mask;
>>   	struct clk		*clk;
>> @@ -448,6 +449,10 @@ static int at91_adc_probe_dt(struct at91_adc_state *st,
>>   	if (!node)
>>   		return -EINVAL;
>>   
>> +	prop = 0;
>> +	of_property_read_u32(node, "atmel,adc-clock-rate", &prop);
>> +	st->adc_clk_rate = prop;
>> +
>>   	st->use_external = of_property_read_bool(node, "atmel,adc-use-external-triggers");
>>   
>>   	if (of_property_read_u32(node, "atmel,adc-channels-used", &prop)) {
>> @@ -723,7 +728,8 @@ static int at91_adc_probe(struct platform_device *pdev)
>>   	 * specified by the electrical characteristics of the board.
>>   	 */
>>   	mstrclk = clk_get_rate(st->clk);
>> -	adc_clk = clk_get_rate(st->adc_clk);
>> +	adc_clk = st->adc_clk_rate ?
>> +		st->adc_clk_rate : clk_get_rate(st->adc_clk);
> Why is that needed? Isn't it completely redundant with the clocks
> property?

As st->adc_clk rate is specified in arch/arm/mach-at91/sama5d3.c (take 
sama5d3 for example), changing the clock rate should recompile the 
kernel binary.
Use dt parameter will let us easily specify the clock rate instead of 
recompile the code.

And yes, it is redundant that we can define the adc_op_clk rate in two 
places (clock property in .c and adc-clock-rate in dts). But this can be 
compatible with the non-dt platform.

After a further thinking of this, maybe remove the adc_op_clk is better 
since it is a fake clock, and only used to specify the clock rate.
To specify the clock rate use a dt property or platform data parameter 
is better.

>
> Maxime
>
>

Best Regards,
Josh Wu


From r65037 at freescale.com  Tue Jul 16 03:56:52 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Tue, 16 Jul 2013 07:56:52 +0000
Subject: [v7 2/3] ARM: imx6q: update the sata bits definitions of gpr13
In-Reply-To: <20130716033951.GG28375@S2101-09.ap.freescale.net>
References: <1373945328-20893-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373945328-20893-3-git-send-email-Hong-Xing.Zhu@freescale.com>
 <20130716033951.GG28375@S2101-09.ap.freescale.net>
Message-ID: <0E83723C55F66F43A6041464FE31119D33D959@039-SN2MPN1-011.039d.mgd.msft.net>

Hi Shawn:
Thanks.

Hi Tejun:
Can you help to pick up the #3 of this patch-set?
Thanks in advance.

Best Regards
Richard Zhu

-----Original Message-----
From: Shawn Guo [mailto:shawn.guo at linaro.org] 
Sent: Tuesday, July 16, 2013 11:40 AM
To: Richard Zhu
Cc: linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; tj at kernel.org; rob.herring at calxeda.com; s.hauer at pengutronix.de; linux-ide at vger.kernel.org; Zhu Richard-R65037
Subject: Re: [v7 2/3] ARM: imx6q: update the sata bits definitions of gpr13

On Tue, Jul 16, 2013 at 11:28:47AM +0800, Richard Zhu wrote:
> From: Richard Zhu <r65037 at freescale.com>
> 
> Replace the SATA_PHY_# by the more readable definitons.
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>

Hi Tejun,

The patch needs to go through your tree to keep patch #3 compilable.  So

Acked-by: Shawn Guo <shawn.guo at linaro.org>



From jgq516 at gmail.com  Tue Jul 16 04:00:40 2013
From: jgq516 at gmail.com (jgq516 at gmail.com)
Date: Tue, 16 Jul 2013 16:00:40 +0800
Subject: v3.10 - big endian core support
In-Reply-To: <51E3CE41.5010807@codethink.co.uk>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate> <51DFEF75.8080600@codethink.co.uk>
 <20130714215325.GB7382@mudshark.cambridge.arm.com>
 <51E3ACD0.8040209@codethink.co.uk> <20130715103658.068ac6b7@skate>
 <51E3CE41.5010807@codethink.co.uk>
Message-ID: <51E4FDA8.9030306@gmail.com>

On 07/15/2013 06:26 PM, Ben Dooks wrote:
> On 15/07/13 09:36, Thomas Petazzoni wrote:
>> Dear Ben Dooks,
>>
>> On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:
>>
>>>> As for building a Thumb-2 kernel; just enable the option in 
>>>> menuconfig and
>>>> you're done. The compiler should "do the right thing".
>>>
>>> I can build it, I just don't have the time and hardware to give it a
>>> test at the moment. However it seems that changing to using 'rev16'
>>> instead of 'rev'. I will make the necessary changes and get this ready
>>> to go.
>>
>> I am willing to give some testing to early patches, if needed. Do not
>> hesitate to send me things to test.
>
> I've pushed out two new branches on git.baserock.org/delta/linux.git
> as:
>     baserock/311/be/core-v2
I have tested the 10 patches on this branch with latest mainline kernel 
(commit 47188d).
Vexpress a15 tc2 boards works with the combos: BE+LPAE on/off, 
BE+THUMB2+LPAE on and LE.

There are some conflicts existed between your patch set and latest kernel.

Thanks,
Xiao
>     baserock/311/be/atags-v2
>



From maxime.ripard at free-electrons.com  Tue Jul 16 04:05:03 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 16 Jul 2013 10:05:03 +0200
Subject: [PATCH 1/3] i2c-mv64xxx: Add I2C Transaction Generator support
In-Reply-To: <1373898278-4805-2-git-send-email-gregory.clement@free-electrons.com>
References: <1373898278-4805-1-git-send-email-gregory.clement@free-electrons.com>
 <1373898278-4805-2-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20130716080503.GA3125@lukather>

Hi Gregory,

On Mon, Jul 15, 2013 at 04:24:36PM +0200, Gregory CLEMENT wrote:
> The I2C Transaction Generator offloads CPU from managing I2C
> transfer step by step.
> 
> This feature is currently only available on Armada XP, so usage of
> this mechanism is activated through device tree.
> 
> Based on the work of Piotr Ziecik and rewrote to use the new way of
> handling multiples i2c messages.
> 
> Signed-off-by: Piotr Ziecik <kosmo at semihalf.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  drivers/i2c/busses/i2c-mv64xxx.c | 207 ++++++++++++++++++++++++++++++++++++---
>  1 file changed, 196 insertions(+), 11 deletions(-)

[...]

> +	/*
> +	 * For controllers embedded in new SoCs activate the
> +	 * Transaction Generator support.
> +	 */
> +	if (of_device_is_compatible(np, "marvell,mv78230-i2c"))
> +		drv_data->offload_enabled = true;
> +

Do you have a reason for not adding it to the match table? I mean, you
will introduce a new compatible here, but if that compatible is used
alone, won't probe the driver? That doesn't seem very right to me.

Also, you should probably add it to the bindings documentation.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130716/512ddec5/attachment.sig>

From shawn.guo at linaro.org  Tue Jul 16 04:05:23 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 16:05:23 +0800
Subject: [v7 2/3] ARM: imx6q: update the sata bits definitions of gpr13
In-Reply-To: <0E83723C55F66F43A6041464FE31119D33D959@039-SN2MPN1-011.039d.mgd.msft.net>
References: <1373945328-20893-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373945328-20893-3-git-send-email-Hong-Xing.Zhu@freescale.com>
 <20130716033951.GG28375@S2101-09.ap.freescale.net>
 <0E83723C55F66F43A6041464FE31119D33D959@039-SN2MPN1-011.039d.mgd.msft.net>
Message-ID: <20130716080521.GI28375@S2101-09.ap.freescale.net>

On Tue, Jul 16, 2013 at 07:56:52AM +0000, Zhu Richard-R65037 wrote:
> Hi Shawn:
> Thanks.
> 
> Hi Tejun:
> Can you help to pick up the #3 of this patch-set?

#2 and #3, I think.

Shawn



From shawn.guo at linaro.org  Tue Jul 16 04:06:11 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 16:06:11 +0800
Subject: [PATCH] ARM: dts: imx: use generic DMA bindings for SSI nodes
Message-ID: <1373961971-5375-1-git-send-email-shawn.guo@linaro.org>

Updates SDMA and SSI nodes to adopt generic DMA bindings.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx51.dtsi   |   12 +++++++++---
 arch/arm/boot/dts/imx53.dtsi   |   12 +++++++++---
 arch/arm/boot/dts/imx6qdl.dtsi |   12 +++++++++---
 3 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index d086e07..cca3ef9 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -154,8 +154,10 @@
 					reg = <0x70014000 0x4000>;
 					interrupts = <30>;
 					clocks = <&clks 49>;
+					dmas = <&sdma 24 1 0>,
+					       <&sdma 25 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
-					fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */
 					status = "disabled";
 				};
 
@@ -735,8 +737,10 @@
 				reg = <0x83fcc000 0x4000>;
 				interrupts = <29>;
 				clocks = <&clks 48>;
+				dmas = <&sdma 28 0 0>,
+				       <&sdma 29 0 0>;
+				dma-names = "rx", "tx";
 				fsl,fifo-depth = <15>;
-				fsl,ssi-dma-events = <29 28 27 26>; /* TX0 RX0 TX1 RX1 */
 				status = "disabled";
 			};
 
@@ -784,8 +788,10 @@
 				reg = <0x83fe8000 0x4000>;
 				interrupts = <96>;
 				clocks = <&clks 50>;
+				dmas = <&sdma 46 0 0>,
+				       <&sdma 47 0 0>;
+				dma-names = "rx", "tx";
 				fsl,fifo-depth = <15>;
-				fsl,ssi-dma-events = <47 46 37 35>; /* TX0 RX0 TX1 RX1 */
 				status = "disabled";
 			};
 
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 51b93c9..a6b6d95 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -153,8 +153,10 @@
 					reg = <0x50014000 0x4000>;
 					interrupts = <30>;
 					clocks = <&clks 49>;
+					dmas = <&sdma 24 1 0>,
+					       <&sdma 25 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
-					fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */
 					status = "disabled";
 				};
 
@@ -1050,8 +1052,10 @@
 				reg = <0x63fcc000 0x4000>;
 				interrupts = <29>;
 				clocks = <&clks 48>;
+				dmas = <&sdma 28 0 0>,
+				       <&sdma 29 0 0>;
+				dma-names = "rx", "tx";
 				fsl,fifo-depth = <15>;
-				fsl,ssi-dma-events = <29 28 27 26>; /* TX0 RX0 TX1 RX1 */
 				status = "disabled";
 			};
 
@@ -1074,8 +1078,10 @@
 				reg = <0x63fe8000 0x4000>;
 				interrupts = <96>;
 				clocks = <&clks 50>;
+				dmas = <&sdma 46 0 0>,
+				       <&sdma 47 0 0>;
+				dma-names = "rx", "tx";
 				fsl,fifo-depth = <15>;
-				fsl,ssi-dma-events = <47 46 45 44>; /* TX0 RX0 TX1 RX1 */
 				status = "disabled";
 			};
 
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 9c64d17..d08048b 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -212,8 +212,10 @@
 					reg = <0x02028000 0x4000>;
 					interrupts = <0 46 0x04>;
 					clocks = <&clks 178>;
+					dmas = <&sdma 37 1 0>,
+					       <&sdma 38 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
-					fsl,ssi-dma-events = <38 37>;
 					status = "disabled";
 				};
 
@@ -222,8 +224,10 @@
 					reg = <0x0202c000 0x4000>;
 					interrupts = <0 47 0x04>;
 					clocks = <&clks 179>;
+					dmas = <&sdma 41 1 0>,
+					       <&sdma 42 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
-					fsl,ssi-dma-events = <42 41>;
 					status = "disabled";
 				};
 
@@ -232,8 +236,10 @@
 					reg = <0x02030000 0x4000>;
 					interrupts = <0 48 0x04>;
 					clocks = <&clks 180>;
+					dmas = <&sdma 45 1 0>,
+					       <&sdma 46 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
-					fsl,ssi-dma-events = <46 45>;
 					status = "disabled";
 				};
 
-- 
1.7.9.5




From b32955 at freescale.com  Tue Jul 16 04:11:19 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Tue, 16 Jul 2013 16:11:19 +0800
Subject: [PATCH 2/3] serial: mxs: enable the DMA only when the rts/cts
 is enabled
In-Reply-To: <20130716073305.GP12139@pengutronix.de>
References: <1373857736-30108-1-git-send-email-b32955@freescale.com>
 <1373857736-30108-2-git-send-email-b32955@freescale.com>
 <20130715082716.GM12139@pengutronix.de> <51E3B5B5.1030706@freescale.com>
 <20130715090755.GN12139@pengutronix.de> <51E3D499.3060902@freescale.com>
 <20130716073305.GP12139@pengutronix.de>
Message-ID: <51E50027.4020701@freescale.com>

? 2013?07?16? 15:33, Uwe Kleine-K?nig ??:
>> This patch depends on the first patch. :)
> But it's not a hard dependency.
>
do you mean i should merge the patch 1 and patch 2 into a single patch?

>>> Something like:
>>>
>>> 	serial: mxs-auart: DMA unreliable without RTS/CTS
>>>
>>> 	According to [add some document name here] DMA doesn't work
>>> 	reliable without hardware handshaking. So make DMA dependant on
>>>   
>> Please see the spec about the RTSEN and RTS.
> Right, it's not hard for me. Other might not have the manual handy, so
> a comment telling:
>
>> RTSEN enable the flow control by the hardware;
>> RTS enable the flow control by the software.
> would be nice.
i think we need another patch to add this comment.

thanks
Huang Shijie



From yann.morin.1998 at free.fr  Tue Jul 16 04:08:07 2013
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Tue, 16 Jul 2013 10:08:07 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130716005611.e4ccab02.akpm@linux-foundation.org>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716004727.b60b2c96.akpm@linux-foundation.org>
 <20130716005611.e4ccab02.akpm@linux-foundation.org>
Message-ID: <201307161008.07643.yann.morin.1998@free.fr>

Andrew, All,

On Tuesday 16 July 2013 09:56:11 Andrew Morton wrote:
> On Tue, 16 Jul 2013 00:47:27 -0700 Andrew Morton <akpm at linux-foundation.org> wrote:
> > On Mon, 15 Jul 2013 15:08:20 -0700 "H. Peter Anvin" <hpa at zytor.com> wrote:
> > > On 07/15/2013 03:03 PM, Andrew Morton wrote:
[--SNIP--]
> > > We keep running over the need to be able to have kconfig run tests on
> > > the build system (for toolchain support or for optional tools needed);
> > > running them in the Makefiles (i.e. at Kbuild time) is simply too late.
> > > 
> > 
> > Would it make sense to extend Kconfig's `depends'?
> > 
> > 	depends on $(shell-command)
> > 
> > I don't know how practical that would be to implement...

I'm afraid this will get rather ugly and not trivial.

Can we mix 'depends on SYMBOL' and 'depends on $(command)' ?
Can we mix both in a boolean expression such as 'depends on SYMBOL
&& $(command)' ?

What would be the condition for evaluating the dependency rule? Evaluation
at Kconfig read-time might not be enough, given this construct:

    config FOO
        depends on $(foo)
    comment "'foo' is missing, please install it"
        depends on !$(foo)

Also, I believe Kconfig should stay a config-only language, without
much esoteric features.

> Or, easier and faster, run some front-end script which generates
> once-off Kconfig symbols.
> 
> 	if [ -x /bin/lz4c ]
> 	then
> 		echo CONFIG_HAVE_LZ4C
> 	fi
> 
> then munge the output of that script into the Kconfig run and do
> 
> 	depends on HAVE_LZ4C

Yes, this is a better solution.

For what it's worth, this is what I'm doing in crosstool-NG: a script
checks for optional pre-requisites, spits out a Kconfig blob which is
included by the top-level Kconfig file.

Here is a snippet of generated Kconfig blob:
    config HAVE_XZ
        def_bool y
    config HAVE_LZMA
        bool

Which means we do have 'xz', but not 'lzma'. This is relatively trivial
to do, so I'll tackle this this evening when I'm back home (unless
someone beats me to it).

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'


From hector.palacios at digi.com  Tue Jul 16 04:04:32 2013
From: hector.palacios at digi.com (Hector Palacios)
Date: Tue, 16 Jul 2013 10:04:32 +0200
Subject: Freescale MXS battery driver
Message-ID: <51E4FE90.9010700@digi.com>

Greetings,

Does anybody know if there is any on-going work to support Freescale's MXS battery driver?

Best regards,
--
Hector Palacios


From linux at arm.linux.org.uk  Tue Jul 16 04:11:32 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 16 Jul 2013 09:11:32 +0100
Subject: Can't get FIQ interrupt to work on i.mx233
In-Reply-To: <CAF-Ht3z3GQLwEWoB+UgOGepHfMFUD7pTRHfYWR9Ynk3rM4dD=Q@mail.gmail.com>
References: <CAF-Ht3z3GQLwEWoB+UgOGepHfMFUD7pTRHfYWR9Ynk3rM4dD=Q@mail.gmail.com>
Message-ID: <20130716081132.GB24642@n2100.arm.linux.org.uk>

On Tue, Jul 16, 2013 at 10:59:22AM +0900, Juha Lumme wrote:
> For now the assembly handler is only 6 instructions: http://codetidy.com/6193/
> I first want to just clear the interrupt bit in HW_ICOLL_INTERRUPT31,
> and then I write 0xFF to HW_PINCTRL_DOUT1

Unfortunately, the code doesn't match your description.  You set r10 to
0xff, and then _load_ the value from the address at r8 into r10.

Maybe that ldr r10, [r8] should be str r10, [r8] ?


From shawn.guo at linaro.org  Tue Jul 16 04:17:09 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 16:17:09 +0800
Subject: [PATCH 06/22] arm/dts: i.MX25: Add ssi clocks and DMA events.
In-Reply-To: <1373900227-341-7-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-7-git-send-email-denis@eukrea.com>
Message-ID: <20130716081703.GF30067@S2101-09.ap.freescale.net>

On Mon, Jul 15, 2013 at 04:56:51PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  arch/arm/boot/dts/imx25.dtsi |    6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
> index b318106..fb37111 100644
> --- a/arch/arm/boot/dts/imx25.dtsi
> +++ b/arch/arm/boot/dts/imx25.dtsi
> @@ -293,6 +293,9 @@
>  				compatible = "fsl,imx25-ssi", "fsl,imx21-ssi";
>  				reg = <0x50014000 0x4000>;
>  				interrupts = <11>;
> +				clocks = <&clks 118>;
> +				clock-names = "ssi2_ipg";
> +				fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */

The imx-sdma driver adopts generic DMA bindings since v3.11-rc1.  I just
sent a patch [1] to update DTS for that.

Shawn

[1] http://www.spinics.net/lists/arm-kernel/msg258803.html



From marex at denx.de  Tue Jul 16 04:26:14 2013
From: marex at denx.de (Marek Vasut)
Date: Tue, 16 Jul 2013 10:26:14 +0200
Subject: Freescale MXS battery driver
In-Reply-To: <51E4FE90.9010700@digi.com>
References: <51E4FE90.9010700@digi.com>
Message-ID: <201307161026.14916.marex@denx.de>

Dear Hector Palacios,

> Greetings,
> 
> Does anybody know if there is any on-going work to support Freescale's MXS
> battery driver?

Nothing I know of, but implementing charger itself should be rather easy. 
Implementing overcharging protection and all this stuff would be hell. Good luck 
;-)

Best regards,
Marek Vasut


From akpm at linux-foundation.org  Tue Jul 16 04:27:56 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 16 Jul 2013 01:27:56 -0700
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <201307161008.07643.yann.morin.1998@free.fr>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716004727.b60b2c96.akpm@linux-foundation.org>
 <20130716005611.e4ccab02.akpm@linux-foundation.org>
 <201307161008.07643.yann.morin.1998@free.fr>
Message-ID: <20130716012756.31936d8d.akpm@linux-foundation.org>

On Tue, 16 Jul 2013 10:08:07 +0200 "Yann E. MORIN" <yann.morin.1998 at free.fr> wrote:

> > Or, easier and faster, run some front-end script which generates
> > once-off Kconfig symbols.
> > 
> > 	if [ -x /bin/lz4c ]
> > 	then
> > 		echo CONFIG_HAVE_LZ4C
> > 	fi
> > 
> > then munge the output of that script into the Kconfig run and do
> > 
> > 	depends on HAVE_LZ4C
> 
> Yes, this is a better solution.
> 
> For what it's worth, this is what I'm doing in crosstool-NG: a script
> checks for optional pre-requisites, spits out a Kconfig blob which is
> included by the top-level Kconfig file.
> 
> Here is a snippet of generated Kconfig blob:
>     config HAVE_XZ
>         def_bool y
>     config HAVE_LZMA
>         bool
> 
> Which means we do have 'xz', but not 'lzma'. This is relatively trivial
> to do, so I'll tackle this this evening when I'm back home (unless
> someone beats me to it).

Cool, thanks.

It seems a bit inefficient to be evaluating commands in a Kconfig
setting where doesn't need that done.  For example, if someone has
selected LZO compression then they don't need to probe for lz4c.

That example sounds hard to solve in a simple fashion, but what about
the case where the config system is not going to look at an entire
subsystem?  Suppose for example, drivers/media/firewire wants to probe
for some executable, but the user hasn't selected firewire at all.

What I'm angling at is, rather than a single global front-end script,
can we embed the scripts in some fashion within the various Kconfig
files?  Say,

	script ./some-script.sh

and the config system will only evaluate that command if it is working
on that Kconfig file.  Obviously that requires a multiple-pass thing.

It's late, but you see what I mean ;)



From nicolas.ferre at atmel.com  Tue Jul 16 04:29:32 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Jul 2013 10:29:32 +0200
Subject: [PATCH] phy: micrel: Add definitions for common Micrel PHY
 registers
In-Reply-To: <1373929730-28130-1-git-send-email-dinguyen@altera.com>
References: <1373929730-28130-1-git-send-email-dinguyen@altera.com>
Message-ID: <51E5046C.60101@atmel.com>

On 16/07/2013 01:08, dinguyen at altera.com :
> From: Dinh Nguyen <dinguyen at altera.com>
>
> Add defines for common Micrel PHY setups so that other platforms
> can use them. Update imx61 and sama5 hardware to use the micrel_phy.h
> PHY defines.
>
> Also add support for the KSZ9021RLRN PHY.
>
> Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
> Cc: David S. Miller <davem at davemloft.net>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> CC: Andrew Victor <linux at maxim.org.za>
> CC: Nicolas Ferre <nicolas.ferre at atmel.com>

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

BTW, which way do you plan to use to merge it upstream?

Thanks a lot, bye,

> CC: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
> CC: Pavel Machek <pavel at denx.de>
> ---
>   arch/arm/mach-at91/board-dt-sama5.c |   17 ++++++-----------
>   arch/arm/mach-imx/mach-imx6q.c      |   13 ++++++++-----
>   include/linux/micrel_phy.h          |    6 ++++++
>   3 files changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/mach-at91/board-dt-sama5.c b/arch/arm/mach-at91/board-dt-sama5.c
> index ad95f6a..bf00d15 100644
> --- a/arch/arm/mach-at91/board-dt-sama5.c
> +++ b/arch/arm/mach-at91/board-dt-sama5.c
> @@ -42,20 +42,15 @@ static int ksz9021rn_phy_fixup(struct phy_device *phy)
>   {
>   	int value;
>
> -#define GMII_RCCPSR	260
> -#define GMII_RRDPSR	261
> -#define GMII_ERCR	11
> -#define GMII_ERDWR	12
> -
>   	/* Set delay values */
> -	value = GMII_RCCPSR | 0x8000;
> -	phy_write(phy, GMII_ERCR, value);
> +	value = MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW | 0x8000;
> +	phy_write(phy, MICREL_KSZ9021_EXTREG_CTRL, value);
>   	value = 0xF2F4;
> -	phy_write(phy, GMII_ERDWR, value);
> -	value = GMII_RRDPSR | 0x8000;
> -	phy_write(phy, GMII_ERCR, value);
> +	phy_write(phy, MICREL_KSZ9021_EXTREG_DATA_WRITE, value);
> +	value = MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW | 0x8000;
> +	phy_write(phy, MICREL_KSZ9021_EXTREG_CTRL, value);
>   	value = 0x2222;
> -	phy_write(phy, GMII_ERDWR, value);
> +	phy_write(phy, MICREL_KSZ9021_EXTREG_DATA_WRITE, value);
>
>   	return 0;
>   }
> diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> index 7be13f8..c8d7814 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -103,13 +103,16 @@ static int ksz9021rn_phy_fixup(struct phy_device *phydev)
>   {
>   	if (IS_BUILTIN(CONFIG_PHYLIB)) {
>   		/* min rx data delay */
> -		phy_write(phydev, 0x0b, 0x8105);
> -		phy_write(phydev, 0x0c, 0x0000);
> +		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> +			0x8000 | MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW);
> +		phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
>
>   		/* max rx/tx clock delay, min rx/tx control delay */
> -		phy_write(phydev, 0x0b, 0x8104);
> -		phy_write(phydev, 0x0c, 0xf0f0);
> -		phy_write(phydev, 0x0b, 0x104);
> +		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> +			0x8000 | MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW);
> +		phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0xf0f0);
> +		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> +			MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW);
>   	}
>
>   	return 0;
> diff --git a/include/linux/micrel_phy.h b/include/linux/micrel_phy.h
> index 8752dbb..ad05ce6 100644
> --- a/include/linux/micrel_phy.h
> +++ b/include/linux/micrel_phy.h
> @@ -17,6 +17,7 @@
>
>   #define PHY_ID_KSZ8873MLL	0x000e7237
>   #define PHY_ID_KSZ9021		0x00221610
> +#define PHY_ID_KSZ9021RLRN	0x00221611
>   #define PHY_ID_KS8737		0x00221720
>   #define PHY_ID_KSZ8021		0x00221555
>   #define PHY_ID_KSZ8031		0x00221556
> @@ -35,4 +36,9 @@
>   /* struct phy_device dev_flags definitions */
>   #define MICREL_PHY_50MHZ_CLK	0x00000001
>
> +#define MICREL_KSZ9021_EXTREG_CTRL	0xB
> +#define MICREL_KSZ9021_EXTREG_DATA_WRITE	0xC
> +#define MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW	0x104
> +#define MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW	0x105
> +
>   #endif /* _MICREL_PHY_H */
>


-- 
Nicolas Ferre


From thomas.petazzoni at free-electrons.com  Tue Jul 16 04:29:50 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Jul 2013 10:29:50 +0200
Subject: [PATCHv5 08/11] ARM: pci: add ->add_bus() and ->remove_bus()
 hooks to hw_pci
In-Reply-To: <1373889167-27878-9-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-9-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130716102950.6a7023ae@skate>

Hello Russell,

Would it be possible to have your opinion on the below patch? It has
already been sent on June, 19th and July, 1st, and I'd really like to
see it merged for 3.12, as part of this series enabling MSI support for
the Marvell PCIe driver.

Thanks!

Thomas

On Mon, 15 Jul 2013 13:52:44 +0200, Thomas Petazzoni wrote:
> Some PCI drivers may need to adjust the pci_bus structure after it has
> been allocated by the Linux PCI core. The PCI core allows
> architectures to implement the pcibios_add_bus() and
> pcibios_remove_bus() for this purpose. This commit therefore extends
> the hw_pci and pci_sys_data structures of the ARM PCI core to allow
> PCI drivers to register ->add_bus() and ->remove_bus() in hw_pci,
> which will get called when a bus is added or removed from the system.
> 
> This will be used for example by the Marvell PCIe driver to connect a
> particular PCI bus with its corresponding MSI chip to handle Message
> Signaled Interrupts.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Reviewed-by: Thierry Reding <thierry.reding at gmail.com>
> ---
>  arch/arm/include/asm/mach/pci.h |  4 ++++
>  arch/arm/kernel/bios32.c        | 16 ++++++++++++++++
>  2 files changed, 20 insertions(+)
> 
> diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
> index a1c90d7..487155c 100644
> --- a/arch/arm/include/asm/mach/pci.h
> +++ b/arch/arm/include/asm/mach/pci.h
> @@ -36,6 +36,8 @@ struct hw_pci {
>  					  resource_size_t start,
>  					  resource_size_t size,
>  					  resource_size_t align);
> +	void            (*add_bus)(struct pci_bus *bus);
> +	void            (*remove_bus)(struct pci_bus *bus);
>  };
>  
>  /*
> @@ -63,6 +65,8 @@ struct pci_sys_data {
>  					  resource_size_t start,
>  					  resource_size_t size,
>  					  resource_size_t align);
> +	void            (*add_bus)(struct pci_bus *bus);
> +	void            (*remove_bus)(struct pci_bus *bus);
>  	void		*private_data;	/* platform controller private data	*/
>  };
>  
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index 261fcc8..530e59d 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -363,6 +363,20 @@ void pcibios_fixup_bus(struct pci_bus *bus)
>  }
>  EXPORT_SYMBOL(pcibios_fixup_bus);
>  
> +void pcibios_add_bus(struct pci_bus *bus)
> +{
> +	struct pci_sys_data *sys = bus->sysdata;
> +	if (sys->add_bus)
> +		sys->add_bus(bus);
> +}
> +
> +void pcibios_remove_bus(struct pci_bus *bus)
> +{
> +	struct pci_sys_data *sys = bus->sysdata;
> +	if (sys->remove_bus)
> +		sys->remove_bus(bus);
> +}
> +
>  /*
>   * Swizzle the device pin each time we cross a bridge.  If a platform does
>   * not provide a swizzle function, we perform the standard PCI swizzling.
> @@ -464,6 +478,8 @@ static void pcibios_init_hw(struct device *parent, struct hw_pci *hw,
>  		sys->swizzle = hw->swizzle;
>  		sys->map_irq = hw->map_irq;
>  		sys->align_resource = hw->align_resource;
> +		sys->add_bus        = hw->add_bus;
> +		sys->remove_bus     = hw->remove_bus;
>  		INIT_LIST_HEAD(&sys->resources);
>  
>  		if (hw->private_data)



-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From thomas.petazzoni at free-electrons.com  Tue Jul 16 04:31:15 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Jul 2013 10:31:15 +0200
Subject: [PATCHv5 01/11] irqdomain: add irq_alloc_mapping() function
In-Reply-To: <1373889167-27878-2-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-2-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130716103115.552dcbd6@skate>

Grant,

Would it be possible to get your opinion on the below patch? We have
already discussed it in the past, and it was implemented according to
your suggestions, so I guess it should be fine, but I'd like to have
your formal Acked-by if possible, or additional comments. It is needed
for the MSI support on Marvell PCIe, but now the Tegra people are also
interested by it, and we hope to get this merged in 3.12.

Thanks!

Thomas

On Mon, 15 Jul 2013 13:52:37 +0200, Thomas Petazzoni wrote:
> This commit extends the irqdomain subsystem with an
> irq_alloc_mapping() function which allows to let the irqdomain code
> find an available hwirq number in the range [ 0 ; domain size ] for
> the given domain, and create a virq mapping for it.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  include/linux/irqdomain.h |  2 ++
>  kernel/irq/irqdomain.c    | 32 ++++++++++++++++++++++++++++++++
>  2 files changed, 34 insertions(+)
> 
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index c983ed1..1ffa336 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -195,6 +195,8 @@ static inline unsigned int irq_linear_revmap(struct irq_domain *domain,
>  extern unsigned int irq_find_mapping(struct irq_domain *host,
>  				     irq_hw_number_t hwirq);
>  extern unsigned int irq_create_direct_mapping(struct irq_domain *host);
> +extern unsigned int irq_alloc_mapping(struct irq_domain *host,
> +				      irq_hw_number_t *hwirq);
>  extern int irq_create_strict_mappings(struct irq_domain *domain,
>  				      unsigned int irq_base,
>  				      irq_hw_number_t hwirq_base, int count);
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 706724e..b9ddb94 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -375,6 +375,38 @@ unsigned int irq_create_direct_mapping(struct irq_domain *domain)
>  EXPORT_SYMBOL_GPL(irq_create_direct_mapping);
>  
>  /**
> + * irq_alloc_mapping() - Allocate an irq for mapping
> + * @domain: domain to allocate the irq for or NULL for default domain
> + * @hwirq:  reference to the returned hwirq
> + *
> + * This routine are used for irq controllers which can choose the
> + * hardware interrupt number from a range [ 0 ; domain size ], such as
> + * is often the case with PCI MSI controllers. The function will
> + * returned the allocated hwirq number in the hwirq pointer, and the
> + * corresponding virq number as the return value.
> + */
> +unsigned int irq_alloc_mapping(struct irq_domain *domain,
> +			       irq_hw_number_t *out_hwirq)
> +{
> +	irq_hw_number_t hwirq;
> +
> +	pr_debug("irq_alloc_mapping(0x%p)\n", domain);
> +
> +	for (hwirq = 0; hwirq < domain->hwirq_max; hwirq++)
> +		if (!irq_find_mapping(domain, hwirq))
> +			break;
> +
> +	if (hwirq == domain->hwirq_max) {
> +		pr_debug("-> no available hwirq found\n");
> +		return 0;
> +	}
> +
> +	*out_hwirq = hwirq;
> +	return irq_create_mapping(domain, hwirq);
> +}
> +EXPORT_SYMBOL_GPL(irq_alloc_mapping);
> +
> +/**
>   * irq_create_mapping() - Map a hardware interrupt into linux irq space
>   * @domain: domain owning this hardware interrupt or NULL for default domain
>   * @hwirq: hardware irq number in that domain space



-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From thomas.petazzoni at free-electrons.com  Tue Jul 16 04:33:51 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Jul 2013 10:33:51 +0200
Subject: [PATCHv5 00/11] MSI support for Marvell EBU PCIe driver
In-Reply-To: <20130715162709.GA24625@dhcp-172-17-186-34.nvidia.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E4167B.4000208@wwwdotorg.org>
 <20130715162709.GA24625@dhcp-172-17-186-34.nvidia.com>
Message-ID: <20130716103351.15b0fb50@skate>

Dear Thierry Reding,

On Mon, 15 Jul 2013 09:27:10 -0700, Thierry Reding wrote:

> We need at least patches 2, 4 and 8 for Tegra.

Are you sure you don't want patch 1 ? It allows to replace the
allocation of MSI interrupt numbers for the MSI driver by a generic
facility based on irq domains.

> There's still the option
> of working around patch 8 by using the custom root bus scan function
> that we have to use anyway, so I guess we could even trim the
> requirement down to patches 2 and 4 if we really need.

Bjorn said he didn't like having the msi chip assignment in the middle
of the root bus scan function, because he was hoping someday to
refactor this function. Quoting Bjorn:

"""
> +	bus->msi = pcie->msi;  

Ideally, arches could use pci_scan_root_bus(), which does the
pci_scan_child_bus() itself, so I never like to add arch-specific code
between pci_create_root_bus() and pci_scan_child_bus().

But you should be able to accomplish this by setting bus->msi in a
pcibios_add_bus() hook.  There is a corresponding pcibios_remove_bus()
hook that might be useful for deallocating the msi_chip.  I'm not too
clear on how you manage the msi_chip lifetime -- I see the alloc in
armada_370_xp_msi_init(), but I'm not sure whether you ever deallocate
it or how you know when it would be safe to do so.
"""

This is from:

Subject: Re: [PATCH v2 6/8] pci: mvebu: add support for MSI
Date: Tue, 18 Jun 2013 16:57:11 -0600

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From josh.wu at atmel.com  Tue Jul 16 04:35:54 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Tue, 16 Jul 2013 16:35:54 +0800
Subject: [PATCH 2/5] iio: at91: Use different prescal, startup mask in
 MR for different IP
In-Reply-To: <20130715125815.GC2962@lukather>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
 <20130715125815.GC2962@lukather>
Message-ID: <51E505EA.4060502@atmel.com>

Hi, Maxime

On 7/15/2013 8:58 PM, Maxime Ripard wrote:
> Hi Josh,
>
> On Sun, Jul 14, 2013 at 04:04:26PM +0800, Josh Wu wrote:
>> For at91 boards, there are different IPs for adc. Different IPs has different
>> STARTUP & PRESCAL mask in ADC_MR.
>>
>> This patch can change the masks according to the different IP version.
>>
>> Signed-off-by: Josh Wu <josh.wu at atmel.com>
>> ---
>>   arch/arm/mach-at91/include/mach/at91_adc.h |    9 ++++--
>>   drivers/iio/adc/at91_adc.c                 |   48 ++++++++++++++++++++++++++--
>>   2 files changed, 53 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-at91/include/mach/at91_adc.h b/arch/arm/mach-at91/include/mach/at91_adc.h
>> index 8e7ed5c..ab273ee 100644
>> --- a/arch/arm/mach-at91/include/mach/at91_adc.h
>> +++ b/arch/arm/mach-at91/include/mach/at91_adc.h
>> @@ -28,9 +28,12 @@
>>   #define			AT91_ADC_TRGSEL_EXTERNAL	(6 << 1)
>>   #define		AT91_ADC_LOWRES		(1 << 4)	/* Low Resolution */
>>   #define		AT91_ADC_SLEEP		(1 << 5)	/* Sleep Mode */
>> -#define		AT91_ADC_PRESCAL	(0x3f << 8)	/* Prescalar Rate Selection */
>> +#define		AT91_ADC_PRESCAL	(0xff << 8)	/* Prescalar Rate Selection */
>> +#define		AT91_ADC_PRESCAL_9260	(0x3f << 8)
>>   #define			AT91_ADC_PRESCAL_(x)	((x) << 8)
>> -#define		AT91_ADC_STARTUP	(0x1f << 16)	/* Startup Up Time */
>> +#define		AT91_ADC_STARTUP	(0xf << 16)	/* Startup Up Time */
>> +#define		AT91_ADC_STARTUP_9260	(0x1f << 16)
>> +#define		AT91_ADC_STARTUP_9G45	(0x7f << 16)
>>   #define			AT91_ADC_STARTUP_(x)	((x) << 16)
>>   #define		AT91_ADC_SHTIM		(0xf  << 24)	/* Sample & Hold Time */
>>   #define			AT91_ADC_SHTIM_(x)	((x) << 24)
>> @@ -58,4 +61,6 @@
>>   #define AT91_ADC_CHR(n)		(0x30 + ((n) * 4))	/* Channel Data Register N */
>>   #define		AT91_ADC_DATA		(0x3ff)
>>   
>> +#define AT91_ADC_VERSION	0xFC
>> +
>>   #endif
>> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
>> index 18bd54f..14e99ba 100644
>> --- a/drivers/iio/adc/at91_adc.c
>> +++ b/drivers/iio/adc/at91_adc.c
>> @@ -39,6 +39,12 @@
>>   #define at91_adc_writel(st, reg, val) \
>>   	(writel_relaxed(val, st->reg_base + reg))
>>   
>> +struct at91_adc_caps {
>> +	bool	has_tsmr;	/* only at91sam9x5, sama5d3 have TSMR reg */
>> +	u32	mr_prescal_mask;
>> +	u32	mr_startup_mask;
>> +};
>> +
>>   struct at91_adc_state {
>>   	struct clk		*adc_clk;
>>   	u16			*buffer;
>> @@ -62,6 +68,7 @@ struct at91_adc_state {
>>   	u32			res;		/* resolution used for convertions */
>>   	bool			low_res;	/* the resolution corresponds to the lowest one */
>>   	wait_queue_head_t	wq_data_avail;
>> +	struct at91_adc_caps	caps;
>>   };
>>   
>>   static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
>> @@ -580,6 +587,41 @@ static const struct iio_info at91_adc_info = {
>>   	.read_raw = &at91_adc_read_raw,
>>   };
>>   
>> +/*
>> + * Since atmel adc support different ip for touchscreen mode. Through the
>> + * IP check, we will know the touchscreen capbilities.
>> + */
>> +static void atmel_adc_get_cap(struct at91_adc_state *st)
>> +{
>> +	unsigned int version;
>> +	struct iio_dev *idev = iio_priv_to_dev(st);
>> +
>> +	version = at91_adc_readl(st, AT91_ADC_VERSION);
>> +	dev_dbg(&idev->dev, "version: 0x%x\n", version);
>> +
>> +	st->caps.mr_prescal_mask = AT91_ADC_PRESCAL_9260;
>> +	st->caps.mr_startup_mask = AT91_ADC_STARTUP_9260;
>> +
>> +	/* keep only major version number */
>> +	switch (version & 0xf00) {
>> +	case 0x500:	/* SAMA5D3 */
>> +	case 0x400:	/* AT91SAM9X5/9N12 */
>> +		st->caps.has_tsmr = 1;
>> +		st->caps.mr_startup_mask = AT91_ADC_STARTUP;
>> +	case 0x200:	/* AT91SAM9M10/9G45 */
>> +		st->caps.mr_prescal_mask = AT91_ADC_PRESCAL;
>> +
>> +		if ((version & 0xf00) == 0x200)
>> +			st->caps.mr_startup_mask = AT91_ADC_STARTUP_9G45;
>> +	case 0x100:	/* AT91SAM9260/9G20 */
>> +		break;
>> +	default:
>> +		dev_warn(&idev->dev,
>> +				"Unmanaged adc version, use minimal capabilities\n");
>> +		break;
>> +	};
>> +}
> Why don't you use different compatible names and derive your
> capabilities from which compatible is declared.
>
> It seems safer.

Ok, that make sense. I will use compatible names for the capabilities in 
next version. Thanks.

>
> Maxime
>

Best Regards,
Josh Wu


From shawn.guo at linaro.org  Tue Jul 16 04:37:50 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 16:37:50 +0800
Subject: [PATCH 07/22] arm/dts: i.MX25: Add sdma script path.
In-Reply-To: <1373900227-341-8-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-8-git-send-email-denis@eukrea.com>
Message-ID: <20130716083747.GG30067@S2101-09.ap.freescale.net>

On Mon, Jul 15, 2013 at 04:56:52PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  arch/arm/boot/dts/imx25.dtsi |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
> index fb37111..f7f024f 100644
> --- a/arch/arm/boot/dts/imx25.dtsi
> +++ b/arch/arm/boot/dts/imx25.dtsi
> @@ -506,6 +506,7 @@
>  				clock-names = "ipg", "ahb";
>  				#dma-cells = <3>;
>  				interrupts = <34>;
> +				fsl,sdma-ram-script-name = "imx/sdma/sdma-imx25-to1.bin";

Please drop "-to1" from the name.

Shawn

>  			};
>  
>  			wdog at 53fdc000 {
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From shawn.guo at linaro.org  Tue Jul 16 04:40:59 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 16:40:59 +0800
Subject: [PATCH 08/22] ASoC: eukrea-tlv320: Add DT support.
In-Reply-To: <1373900227-341-9-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-9-git-send-email-denis@eukrea.com>
Message-ID: <20130716084057.GH30067@S2101-09.ap.freescale.net>

On Mon, Jul 15, 2013 at 04:56:53PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  sound/soc/fsl/Kconfig         |    5 +-
>  sound/soc/fsl/eukrea-tlv320.c |  105 +++++++++++++++++++++++++++++++++--------
>  2 files changed, 90 insertions(+), 20 deletions(-)
> 

This patch should be sent to alsa-devel at alsa-project.org with Mark Brown
<broonie at kernel.org> on copy.

Shawn



From m.szyprowski at samsung.com  Tue Jul 16 04:42:38 2013
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Jul 2013 10:42:38 +0200
Subject: [PATCH v3 2/2] drivers: dma-contiguous: add initialization from
 device tree
In-Reply-To: <CACxGe6uzau+g0gd=hkNYw1zdkfq18zt_m9OEaiJKR6=q1U4rag@mail.gmail.com>
References: <1372254009-25307-1-git-send-email-m.szyprowski@samsung.com>
 <1372254009-25307-3-git-send-email-m.szyprowski@samsung.com>
 <CACxGe6uzau+g0gd=hkNYw1zdkfq18zt_m9OEaiJKR6=q1U4rag@mail.gmail.com>
Message-ID: <51E5077E.8070900@samsung.com>

Hello Grant,

On 7/11/2013 4:56 PM, Grant Likely wrote:
> Hi Marek,
>
> Thanks for working on this. Comments below...
>
> On Wed, Jun 26, 2013 at 2:40 PM, Marek Szyprowski
> <m.szyprowski at samsung.com> wrote:
> > Add device tree support for contiguous memory regions defined in device
> > tree. Initialization is done in 2 steps. First, the contiguous memory is
> > reserved, what happens very early when only flattened device tree is
> > available. Then on device initialization the corresponding cma regions are
> > assigned to each device structure.
> >
> > Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
> > Acked-by: Kyungmin Park <kyungmin.park at samsung.com>
> > ---
> >  .../devicetree/bindings/contiguous-memory.txt      |   94 ++++++++++++++
> >  arch/arm/boot/dts/skeleton.dtsi                    |    7 +-
> >  drivers/base/dma-contiguous.c                      |  132 ++++++++++++++++++++
> >  3 files changed, 232 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/devicetree/bindings/contiguous-memory.txt
> >
> > diff --git a/Documentation/devicetree/bindings/contiguous-memory.txt b/Documentation/devicetree/bindings/contiguous-memory.txt
> > new file mode 100644
> > index 0000000..a733df2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/contiguous-memory.txt
> > @@ -0,0 +1,94 @@
> > +*** Contiguous Memory binding ***
> > +
> > +The /chosen/contiguous-memory node provides runtime configuration of
> > +contiguous memory regions for Linux kernel. Such regions can be created
> > +for special usage by various device drivers. A good example are
> > +contiguous memory allocations or memory sharing with other operating
> > +system(s) on the same hardware board. Those special memory regions might
> > +depend on the selected board configuration and devices used on the target
> > +system.
> > +
> > +Parameters for each memory region can be encoded into the device tree
> > +with the following convention:
> > +
> > +contiguous-memory {
> > +
> > +       (name): region@(base-address) {
> > +               reg = <(baseaddr) (size)>;
> > +               (linux,default-contiguous-region);
> > +               device = <&device_0 &device_1 ...>
> > +       };
> > +};
>
> Okay, I've gone and read all of the backlog on the 3 versions of the
> patch series, and I think I understand the issues. I actually think it
> was better off to have the regions specified as children of the memory
> node. I understand the argument about how would firmware know what
> size the kernel wants and that it would be better to have a kernel
> parameter to override the default. However, it is also reasonable for
> the kernel to be provided with a default amount of CMA based on the
> usage profile of the device. In that regard it is absolutely
> appropriate to put the CMA region data into the memory node. I don't
> think /chosen is the right place for that.

Thanks for your comments! I will prepare a new version, which will use
/memory node as it was in the first version. I hope that with Your ack
such version can be finally merged.

> > +
> > +name:          an name given to the defined region;
>
> In the above node example, "name:" is a label used for creating
> phandles. That information doesn't appear in the resulting .dtb
> output. The label is actually optional It should instead be:
>          [(label):] (name)@(address) { }
>
> > +base-address:  the base address of the defined region;
> > +size:          the size of the memory region (bytes);
>
> The reg property should follow the normal reg rules which are well
> defined. That also means that a memory region could have multiple reg
> entries if appropriate.

Well, I'm not sure if it really makes sense to support multiple reg 
entries.
I also wonder how to provide entries for LPAE systems. They are 32-bit 
systems,
but physical addresses can be up to 36bit. How to specify them in device 
tree?

> > +linux,default-contiguous-region: property indicating that the region
> > +               is the default region for all contiguous memory
> > +               allocations, Linux specific (optional);
> > +device:                array of phandles to the client device nodes, which
> > +               will use the defined contiguous region.
>
> This is backwards compared to the way device references usually work.
> It would be more consistent for each device node to have a
> "dma-memory-region" property with phandles to one or more memory
> regions that it cares about.
>
> > +Each defined region must use unique name. It is optional to specify the
> > +base address, so if one wants to use autoconfiguration of the base
> > +address, he must specify the '0' as base address in the 'reg' property
> > +and assign ann uniqe name to such regions, following the convention:
> > +'region at 0', 'region at 1', 'region at 2', ...
>
> Drop the use of 'region'. "name at 0" is more typical. It would be
> appropriate to have compatible = "reserved-memory-region" in each of
> the reserved regions. That would avoid the problem of two regions
> based at the same address having a conflict in name.

Ok.

 > ...

Best regards
-- 
Marek Szyprowski
Samsung R&D Institute Poland




From thomas.petazzoni at free-electrons.com  Tue Jul 16 04:43:47 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Jul 2013 10:43:47 +0200
Subject: [PATCHv5 00/11] MSI support for Marvell EBU PCIe driver
In-Reply-To: <51E4167B.4000208@wwwdotorg.org>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E4167B.4000208@wwwdotorg.org>
Message-ID: <20130716104347.045a612a@skate>

Dear Stephen Warren,

On Mon, 15 Jul 2013 09:34:19 -0600, Stephen Warren wrote:

> > This patch set is intended for merging in 3.12, so the respective
> > maintainers of the different areas are invited to review/ack the
> > patches, see below for the details. This set of patches applies on top
> > of 3.11-rc1.
> 
> Thomas, who is going to merge this series?

I don't know. There are quite a few build dependencies in there:

 * PATCH 7 build depends on PATCH 1 and PATCH 5, and obviously depends
   on PATCH 6.

 * PATCH 2 to 5 really are one thing, they depend on each other.

 * PATCH 10 build depends on PATCH 5 and PATCH 8.

A quick diagram of the dependencies, best viewed with a fixed-size font
mailer.

kernel/irq/irqdomain    drivers/pci        arch/arm/kernel
     patch 1           patch 2, 3, 4           patch 8
        ||                  ||                   ||
        ||                  \/                   \/
        ||               drivers/of   ==> drivers/pci/host
        ||                patch 5           patch 10
        ||                  ||
        \\__________________//
                  ||
                  \/
            drivers/irqchip
              patch 6, 7

Patches 9 and 11 are DT patches, so they are not mentioned in this
diagram.

Normally tegra would require 1, 2, 3, 4, 5 and 8, so ideally, with
the respective maintainers ACKs, Jason Cooper could take them in a
specific topic stable branch that would not be rebased, on top of which
both the Marvell work and Tegra work could be done.

I really would like to see those patches very soon in linux-next, in
order to get some build coverage, especially for the 2, 3 and 4 patches
that touch a number of architectures.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From gsi at denx.de  Tue Jul 16 04:45:37 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Tue, 16 Jul 2013 10:45:37 +0200
Subject: [PATCH v1 21/24] [media] fsl-viu: OF clock lookup,
 prepare before enable
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373964341-25228-1-git-send-email-gsi@denx.de>

device tree based clock lookup, must prepare clocks before enabling
them, unprepare after disable, error check in the clock setup

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/media/platform/fsl-viu.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index 221ec42..b95aa43 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -1582,8 +1582,11 @@ static int viu_of_probe(struct platform_device *op)
 		dev_err(&op->dev, "failed to find the clock module!\n");
 		ret = -ENODEV;
 		goto err_clk;
-	} else {
-		clk_enable(viu_dev->clk);
+	}
+	ret = clk_prepare_enable(viu_dev->clk);
+	if (ret) {
+		dev_err(&op->dev, "failed to enable the clock!\n");
+		goto err_clk_put;
 	}
 
 	/* reset VIU module */
@@ -1602,7 +1605,8 @@ static int viu_of_probe(struct platform_device *op)
 	return ret;
 
 err_irq:
-	clk_disable(viu_dev->clk);
+	clk_disable_unprepare(viu_dev->clk);
+err_clk_put:
 	clk_put(viu_dev->clk);
 err_clk:
 	video_unregister_device(viu_dev->vdev);
@@ -1626,7 +1630,7 @@ static int viu_of_remove(struct platform_device *op)
 	free_irq(dev->irq, (void *)dev);
 	irq_dispose_mapping(dev->irq);
 
-	clk_disable(dev->clk);
+	clk_disable_unprepare(dev->clk);
 	clk_put(dev->clk);
 
 	video_unregister_device(dev->vdev);
-- 
1.7.10.4



From gsi at denx.de  Tue Jul 16 04:45:40 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Tue, 16 Jul 2013 10:45:40 +0200
Subject: [PATCH v1 24/24] net: can: mscan: remove MPC512x non-COMMON_CLK code
 path
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373964341-25228-4-git-send-email-gsi@denx.de>

transition to the COMMON_CLK framework has completed for the MPC512x
platform, remove the now obsolete code path of the mpc5xxx mscan
driver which accessed clock control module registers directly

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/net/can/mscan/mpc5xxx_can.c |  136 -----------------------------------
 1 file changed, 136 deletions(-)

diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index dd26ab6..cf5e4cfc 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -108,9 +108,6 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
 #endif /* CONFIG_PPC_MPC52xx */
 
 #ifdef CONFIG_PPC_MPC512x
-
-#if IS_ENABLED(CONFIG_COMMON_CLK)
-
 static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 				 const char *clock_source, int *mscan_clksrc)
 {
@@ -244,139 +241,6 @@ err_notavail:
 	dev_err(&ofdev->dev, "cannot acquire or setup clock source\n");
 	return 0;
 }
-#else	/* COMMON_CLK */
-struct mpc512x_clockctl {
-	u32 spmr;		/* System PLL Mode Reg */
-	u32 sccr[2];		/* System Clk Ctrl Reg 1 & 2 */
-	u32 scfr1;		/* System Clk Freq Reg 1 */
-	u32 scfr2;		/* System Clk Freq Reg 2 */
-	u32 reserved;
-	u32 bcr;		/* Bread Crumb Reg */
-	u32 pccr[12];		/* PSC Clk Ctrl Reg 0-11 */
-	u32 spccr;		/* SPDIF Clk Ctrl Reg */
-	u32 cccr;		/* CFM Clk Ctrl Reg */
-	u32 dccr;		/* DIU Clk Cnfg Reg */
-	u32 mccr[4];		/* MSCAN Clk Ctrl Reg 1-3 */
-};
-
-static struct of_device_id mpc512x_clock_ids[] = {
-	{ .compatible = "fsl,mpc5121-clock", },
-	{}
-};
-
-static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
-				 const char *clock_name, int *mscan_clksrc)
-{
-	struct mpc512x_clockctl __iomem *clockctl;
-	struct device_node *np_clock;
-	struct clk *sys_clk, *ref_clk;
-	int plen, clockidx, clocksrc = -1;
-	u32 sys_freq, val, clockdiv = 1, freq = 0;
-	const u32 *pval;
-
-	np_clock = of_find_matching_node(NULL, mpc512x_clock_ids);
-	if (!np_clock) {
-		dev_err(&ofdev->dev, "couldn't find clock node\n");
-		return 0;
-	}
-	clockctl = of_iomap(np_clock, 0);
-	if (!clockctl) {
-		dev_err(&ofdev->dev, "couldn't map clock registers\n");
-		goto exit_put;
-	}
-
-	/* Determine the MSCAN device index from the peripheral's
-	 * physical address. Register address offsets against the
-	 * IMMR base are:  0x1300, 0x1380, 0x2300, 0x2380
-	 */
-	pval = of_get_property(ofdev->dev.of_node, "reg", &plen);
-	BUG_ON(!pval || plen < sizeof(*pval));
-	clockidx = (*pval & 0x80) ? 1 : 0;
-	if (*pval & 0x2000)
-		clockidx += 2;
-
-	/*
-	 * Clock source and divider selection: 3 different clock sources
-	 * can be selected: "ip", "ref" or "sys". For the latter two, a
-	 * clock divider can be defined as well. If the clock source is
-	 * not specified by the device tree, we first try to find an
-	 * optimal CAN source clock based on the system clock. If that
-	 * is not posslible, the reference clock will be used.
-	 */
-	if (clock_name && !strcmp(clock_name, "ip")) {
-		*mscan_clksrc = MSCAN_CLKSRC_IPS;
-		freq = mpc5xxx_get_bus_frequency(ofdev->dev.of_node);
-	} else {
-		*mscan_clksrc = MSCAN_CLKSRC_BUS;
-
-		pval = of_get_property(ofdev->dev.of_node,
-				       "fsl,mscan-clock-divider", &plen);
-		if (pval && plen == sizeof(*pval))
-			clockdiv = *pval;
-		if (!clockdiv)
-			clockdiv = 1;
-
-		if (!clock_name || !strcmp(clock_name, "sys")) {
-			sys_clk = clk_get(&ofdev->dev, "sys_clk");
-			if (IS_ERR(sys_clk)) {
-				dev_err(&ofdev->dev, "couldn't get sys_clk\n");
-				goto exit_unmap;
-			}
-			/* Get and round up/down sys clock rate */
-			sys_freq = 1000000 *
-				((clk_get_rate(sys_clk) + 499999) / 1000000);
-
-			if (!clock_name) {
-				/* A multiple of 16 MHz would be optimal */
-				if ((sys_freq % 16000000) == 0) {
-					clocksrc = 0;
-					clockdiv = sys_freq / 16000000;
-					freq = sys_freq / clockdiv;
-				}
-			} else {
-				clocksrc = 0;
-				freq = sys_freq / clockdiv;
-			}
-		}
-
-		if (clocksrc < 0) {
-			ref_clk = clk_get(&ofdev->dev, "ref_clk");
-			if (IS_ERR(ref_clk)) {
-				dev_err(&ofdev->dev, "couldn't get ref_clk\n");
-				goto exit_unmap;
-			}
-			clocksrc = 1;
-			freq = clk_get_rate(ref_clk) / clockdiv;
-		}
-	}
-
-	/* Disable clock */
-	out_be32(&clockctl->mccr[clockidx], 0x0);
-	if (clocksrc >= 0) {
-		/* Set source and divider */
-		val = (clocksrc << 14) | ((clockdiv - 1) << 17);
-		out_be32(&clockctl->mccr[clockidx], val);
-		/* Enable clock */
-		out_be32(&clockctl->mccr[clockidx], val | 0x10000);
-	}
-
-	/* Enable MSCAN clock domain */
-	val = in_be32(&clockctl->sccr[1]);
-	if (!(val & (1 << 25)))
-		out_be32(&clockctl->sccr[1], val | (1 << 25));
-
-	dev_dbg(&ofdev->dev, "using '%s' with frequency divider %d\n",
-		*mscan_clksrc == MSCAN_CLKSRC_IPS ? "ips_clk" :
-		clocksrc == 1 ? "ref_clk" : "sys_clk", clockdiv);
-
-exit_unmap:
-	iounmap(clockctl);
-exit_put:
-	of_node_put(np_clock);
-	return freq;
-}
-#endif	/* COMMON_CLK */
-
 #else /* !CONFIG_PPC_MPC512x */
 static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 				 const char *clock_name, int *mscan_clksrc)
-- 
1.7.10.4



From gsi at denx.de  Tue Jul 16 04:45:38 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Tue, 16 Jul 2013 10:45:38 +0200
Subject: [PATCH v1 22/24] powerpc/fsl-pci: OF clock lookup,
 prepare before enable
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373964341-25228-2-git-send-email-gsi@denx.de>

device tree based clock lookup, must prepare clocks before enabling
them, error check in the clock setup

this change implements non-fatal clock lookup for compatibility with
platforms that don't provide OF clock specs, but failure to enable a
specified clock is considered fatal

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/sysdev/fsl_pci.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 46ac1dd..cb2ed92 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -17,6 +17,8 @@
  * Free Software Foundation;  either version 2 of the  License, or (at your
  * option) any later version.
  */
+
+#include <linux/clk.h>
 #include <linux/kernel.h>
 #include <linux/pci.h>
 #include <linux/delay.h>
@@ -741,6 +743,7 @@ err0:
 
 int __init mpc83xx_add_bridge(struct device_node *dev)
 {
+	struct clk *clk;
 	int ret;
 	int len;
 	struct pci_controller *hose;
@@ -758,6 +761,18 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
 	}
 	pr_debug("Adding PCI host bridge %s\n", dev->full_name);
 
+	/* non-fatal OF clock lookup, but fatal when a clock
+	 * was specified yet could not get enabled */
+	clk = of_clk_get_by_name(dev, "per");
+	if (!IS_ERR(clk)) {
+		ret = clk_prepare_enable(clk);
+		clk_put(clk);
+		if (ret) {
+			pr_err("Could not enable peripheral clock\n");
+			return ret;
+		}
+	}
+
 	/* Fetch host bridge registers address */
 	if (of_address_to_resource(dev, 0, &rsrc_reg)) {
 		printk(KERN_WARNING "Can't get pci register base!\n");
-- 
1.7.10.4



From gsi at denx.de  Tue Jul 16 04:45:39 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Tue, 16 Jul 2013 10:45:39 +0200
Subject: [PATCH v1 23/24] clk: mpc512x: switch to COMMON_CLK, remove PPC_CLOCK
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1373964341-25228-3-git-send-email-gsi@denx.de>

completely switch to, i.e. unconditionally use COMMON_CLK for the
MPC512x platform, and retire the PPC_CLOCK implementation for that
platform after the transition has completed

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/Kconfig  |   14 +-
 arch/powerpc/platforms/512x/Makefile |    3 +-
 arch/powerpc/platforms/512x/clock.c  |  753 ----------------------------------
 3 files changed, 2 insertions(+), 768 deletions(-)
 delete mode 100644 arch/powerpc/platforms/512x/clock.c

diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig
index c5fcdd0..5aa3f4b 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -1,21 +1,9 @@
-config MPC512x_COMMON_CLK
-	bool "MPC512x platform uses COMMON_CLK"
-	default y
-	depends on PPC_MPC512x
-	help
-	  This option is only here to support tests and comparison
-	  during development and migration.  This option will get
-	  removed after the COMMON_CLK support for MPC512x has become
-	  fully operational and all drivers were adjusted to explicitly
-	  acquire their required clocks.
-
 config PPC_MPC512x
 	bool "512x-based boards"
 	depends on 6xx
+	select COMMON_CLK
 	select FSL_SOC
 	select IPIC
-	select PPC_CLOCK if !MPC512x_COMMON_CLK
-	select COMMON_CLK if MPC512x_COMMON_CLK
 	select PPC_PCI_CHOICE
 	select FSL_PCI if PCI
 	select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/powerpc/platforms/512x/Makefile b/arch/powerpc/platforms/512x/Makefile
index 1e05f9d..bb20116 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -1,8 +1,7 @@
 #
 # Makefile for the Freescale PowerPC 512x linux kernel.
 #
-obj-$(CONFIG_PPC_CLOCK)		+= clock.o
-obj-$(CONFIG_COMMON_CLK)	+= clock-commonclk.o
+obj-y				+= clock-commonclk.o
 obj-y				+= mpc512x_shared.o
 obj-$(CONFIG_MPC5121_ADS)	+= mpc5121_ads.o mpc5121_ads_cpld.o
 obj-$(CONFIG_MPC512x_GENERIC)	+= mpc512x_generic.o
diff --git a/arch/powerpc/platforms/512x/clock.c b/arch/powerpc/platforms/512x/clock.c
deleted file mode 100644
index e504166..0000000
--- a/arch/powerpc/platforms/512x/clock.c
+++ /dev/null
@@ -1,753 +0,0 @@
-/*
- * Copyright (C) 2007,2008 Freescale Semiconductor, Inc. All rights reserved.
- *
- * Author: John Rigby <jrigby at freescale.com>
- *
- * Implements the clk api defined in include/linux/clk.h
- *
- *    Original based on linux/arch/arm/mach-integrator/clock.c
- *
- *    Copyright (C) 2004 ARM Limited.
- *    Written by Deep Blue Solutions Limited.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <linux/kernel.h>
-#include <linux/list.h>
-#include <linux/errno.h>
-#include <linux/err.h>
-#include <linux/module.h>
-#include <linux/string.h>
-#include <linux/clk.h>
-#include <linux/mutex.h>
-#include <linux/io.h>
-
-#include <linux/of_platform.h>
-#include <asm/mpc5xxx.h>
-#include <asm/mpc5121.h>
-#include <asm/clk_interface.h>
-
-#include "mpc512x.h"
-
-#undef CLK_DEBUG
-
-static int clocks_initialized;
-
-#define CLK_HAS_RATE	0x1	/* has rate in MHz */
-#define CLK_HAS_CTRL	0x2	/* has control reg and bit */
-
-struct clk {
-	struct list_head node;
-	char name[32];
-	int flags;
-	struct device *dev;
-	unsigned long rate;
-	struct module *owner;
-	void (*calc) (struct clk *);
-	struct clk *parent;
-	int reg, bit;		/* CLK_HAS_CTRL */
-	int div_shift;		/* only used by generic_div_clk_calc */
-};
-
-static LIST_HEAD(clocks);
-static DEFINE_MUTEX(clocks_mutex);
-
-static struct clk *mpc5121_clk_get(struct device *dev, const char *id)
-{
-	struct clk *p, *clk = ERR_PTR(-ENOENT);
-	int dev_match;
-	int id_match;
-
-	if (dev == NULL || id == NULL)
-		return clk;
-
-	mutex_lock(&clocks_mutex);
-	list_for_each_entry(p, &clocks, node) {
-		dev_match = id_match = 0;
-
-		if (dev == p->dev)
-			dev_match++;
-		if (strcmp(id, p->name) == 0)
-			id_match++;
-		if ((dev_match || id_match) && try_module_get(p->owner)) {
-			clk = p;
-			break;
-		}
-	}
-	mutex_unlock(&clocks_mutex);
-
-	return clk;
-}
-
-#ifdef CLK_DEBUG
-static void dump_clocks(void)
-{
-	struct clk *p;
-
-	mutex_lock(&clocks_mutex);
-	printk(KERN_INFO "CLOCKS:\n");
-	list_for_each_entry(p, &clocks, node) {
-		pr_info("  %s=%ld", p->name, p->rate);
-		if (p->parent)
-			pr_cont(" %s=%ld", p->parent->name,
-			       p->parent->rate);
-		if (p->flags & CLK_HAS_CTRL)
-			pr_cont(" reg/bit=%d/%d", p->reg, p->bit);
-		pr_cont("\n");
-	}
-	mutex_unlock(&clocks_mutex);
-}
-#define	DEBUG_CLK_DUMP() dump_clocks()
-#else
-#define	DEBUG_CLK_DUMP()
-#endif
-
-
-static void mpc5121_clk_put(struct clk *clk)
-{
-	module_put(clk->owner);
-}
-
-#define NRPSC 12
-
-struct mpc512x_clockctl {
-	u32 spmr;		/* System PLL Mode Reg */
-	u32 sccr[2];		/* System Clk Ctrl Reg 1 & 2 */
-	u32 scfr1;		/* System Clk Freq Reg 1 */
-	u32 scfr2;		/* System Clk Freq Reg 2 */
-	u32 reserved;
-	u32 bcr;		/* Bread Crumb Reg */
-	u32 pccr[NRPSC];	/* PSC Clk Ctrl Reg 0-11 */
-	u32 spccr;		/* SPDIF Clk Ctrl Reg */
-	u32 cccr;		/* CFM Clk Ctrl Reg */
-	u32 dccr;		/* DIU Clk Cnfg Reg */
-};
-
-static struct mpc512x_clockctl __iomem *clockctl;
-
-static int mpc5121_clk_enable(struct clk *clk)
-{
-	unsigned int mask;
-
-	if (clk->flags & CLK_HAS_CTRL) {
-		mask = in_be32(&clockctl->sccr[clk->reg]);
-		mask |= 1 << clk->bit;
-		out_be32(&clockctl->sccr[clk->reg], mask);
-	}
-	return 0;
-}
-
-static void mpc5121_clk_disable(struct clk *clk)
-{
-	unsigned int mask;
-
-	if (clk->flags & CLK_HAS_CTRL) {
-		mask = in_be32(&clockctl->sccr[clk->reg]);
-		mask &= ~(1 << clk->bit);
-		out_be32(&clockctl->sccr[clk->reg], mask);
-	}
-}
-
-static unsigned long mpc5121_clk_get_rate(struct clk *clk)
-{
-	if (clk->flags & CLK_HAS_RATE)
-		return clk->rate;
-	else
-		return 0;
-}
-
-static long mpc5121_clk_round_rate(struct clk *clk, unsigned long rate)
-{
-	return rate;
-}
-
-static int mpc5121_clk_set_rate(struct clk *clk, unsigned long rate)
-{
-	return 0;
-}
-
-static int clk_register(struct clk *clk)
-{
-	mutex_lock(&clocks_mutex);
-	list_add(&clk->node, &clocks);
-	mutex_unlock(&clocks_mutex);
-	return 0;
-}
-
-static unsigned long spmf_mult(void)
-{
-	/*
-	 * Convert spmf to multiplier
-	 */
-	static int spmf_to_mult[] = {
-		68, 1, 12, 16,
-		20, 24, 28, 32,
-		36, 40, 44, 48,
-		52, 56, 60, 64
-	};
-	int spmf = (in_be32(&clockctl->spmr) >> 24) & 0xf;
-	return spmf_to_mult[spmf];
-}
-
-static unsigned long sysdiv_div_x_2(void)
-{
-	/*
-	 * Convert sysdiv to divisor x 2
-	 * Some divisors have fractional parts so
-	 * multiply by 2 then divide by this value
-	 */
-	static int sysdiv_to_div_x_2[] = {
-		4, 5, 6, 7,
-		8, 9, 10, 14,
-		12, 16, 18, 22,
-		20, 24, 26, 30,
-		28, 32, 34, 38,
-		36, 40, 42, 46,
-		44, 48, 50, 54,
-		52, 56, 58, 62,
-		60, 64, 66,
-	};
-	int sysdiv = (in_be32(&clockctl->scfr2) >> 26) & 0x3f;
-	return sysdiv_to_div_x_2[sysdiv];
-}
-
-static unsigned long ref_to_sys(unsigned long rate)
-{
-	rate *= spmf_mult();
-	rate *= 2;
-	rate /= sysdiv_div_x_2();
-
-	return rate;
-}
-
-static unsigned long sys_to_ref(unsigned long rate)
-{
-	rate *= sysdiv_div_x_2();
-	rate /= 2;
-	rate /= spmf_mult();
-
-	return rate;
-}
-
-static long ips_to_ref(unsigned long rate)
-{
-	int ips_div = (in_be32(&clockctl->scfr1) >> 23) & 0x7;
-
-	rate *= ips_div;	/* csb_clk = ips_clk * ips_div */
-	rate *= 2;		/* sys_clk = csb_clk * 2 */
-	return sys_to_ref(rate);
-}
-
-static unsigned long devtree_getfreq(char *clockname)
-{
-	struct device_node *np;
-	const unsigned int *prop;
-	unsigned int val = 0;
-
-	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-immr");
-	if (np) {
-		prop = of_get_property(np, clockname, NULL);
-		if (prop)
-			val = *prop;
-	    of_node_put(np);
-	}
-	return val;
-}
-
-static void ref_clk_calc(struct clk *clk)
-{
-	unsigned long rate;
-
-	rate = devtree_getfreq("bus-frequency");
-	if (rate == 0) {
-		printk(KERN_ERR "No bus-frequency in dev tree\n");
-		clk->rate = 0;
-		return;
-	}
-	clk->rate = ips_to_ref(rate);
-}
-
-static struct clk ref_clk = {
-	.name = "ref_clk",
-	.calc = ref_clk_calc,
-};
-
-
-static void sys_clk_calc(struct clk *clk)
-{
-	clk->rate = ref_to_sys(ref_clk.rate);
-}
-
-static struct clk sys_clk = {
-	.name = "sys_clk",
-	.calc = sys_clk_calc,
-};
-
-static void diu_clk_calc(struct clk *clk)
-{
-	int diudiv_x_2 = in_be32(&clockctl->scfr1) & 0xff;
-	unsigned long rate;
-
-	rate = sys_clk.rate;
-
-	rate *= 2;
-	rate /= diudiv_x_2;
-
-	clk->rate = rate;
-}
-
-static void viu_clk_calc(struct clk *clk)
-{
-	unsigned long rate;
-
-	rate = sys_clk.rate;
-	rate /= 2;
-	clk->rate = rate;
-}
-
-static void half_clk_calc(struct clk *clk)
-{
-	clk->rate = clk->parent->rate / 2;
-}
-
-static void generic_div_clk_calc(struct clk *clk)
-{
-	int div = (in_be32(&clockctl->scfr1) >> clk->div_shift) & 0x7;
-
-	clk->rate = clk->parent->rate / div;
-}
-
-static void unity_clk_calc(struct clk *clk)
-{
-	clk->rate = clk->parent->rate;
-}
-
-static struct clk csb_clk = {
-	.name = "csb_clk",
-	.calc = half_clk_calc,
-	.parent = &sys_clk,
-};
-
-static void e300_clk_calc(struct clk *clk)
-{
-	int spmf = (in_be32(&clockctl->spmr) >> 16) & 0xf;
-	int ratex2 = clk->parent->rate * spmf;
-
-	clk->rate = ratex2 / 2;
-}
-
-static struct clk e300_clk = {
-	.name = "e300_clk",
-	.calc = e300_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk ips_clk = {
-	.name = "ips_clk",
-	.calc = generic_div_clk_calc,
-	.parent = &csb_clk,
-	.div_shift = 23,
-};
-
-/*
- * Clocks controlled by SCCR1 (.reg = 0)
- */
-static struct clk lpc_clk = {
-	.name = "lpc_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 30,
-	.calc = generic_div_clk_calc,
-	.parent = &ips_clk,
-	.div_shift = 11,
-};
-
-static struct clk nfc_clk = {
-	.name = "nfc_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 29,
-	.calc = generic_div_clk_calc,
-	.parent = &ips_clk,
-	.div_shift = 8,
-};
-
-static struct clk pata_clk = {
-	.name = "pata_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 28,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-/*
- * PSC clocks (bits 27 - 16)
- * are setup elsewhere
- */
-
-static struct clk sata_clk = {
-	.name = "sata_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 14,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk fec_clk = {
-	.name = "fec_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 13,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk pci_clk = {
-	.name = "pci_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 11,
-	.calc = generic_div_clk_calc,
-	.parent = &csb_clk,
-	.div_shift = 20,
-};
-
-/*
- * Clocks controlled by SCCR2 (.reg = 1)
- */
-static struct clk diu_clk = {
-	.name = "diu_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 31,
-	.calc = diu_clk_calc,
-};
-
-static struct clk viu_clk = {
-	.name = "viu_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 18,
-	.calc = viu_clk_calc,
-};
-
-static struct clk axe_clk = {
-	.name = "axe_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 30,
-	.calc = unity_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk usb1_clk = {
-	.name = "usb1_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 28,
-	.calc = unity_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk usb2_clk = {
-	.name = "usb2_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 27,
-	.calc = unity_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk i2c_clk = {
-	.name = "i2c_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 26,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk mscan_clk = {
-	.name = "mscan_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 25,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk sdhc_clk = {
-	.name = "sdhc_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 24,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk mbx_bus_clk = {
-	.name = "mbx_bus_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 22,
-	.calc = half_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk mbx_clk = {
-	.name = "mbx_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 21,
-	.calc = unity_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk mbx_3d_clk = {
-	.name = "mbx_3d_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 20,
-	.calc = generic_div_clk_calc,
-	.parent = &mbx_bus_clk,
-	.div_shift = 14,
-};
-
-static void psc_mclk_in_calc(struct clk *clk)
-{
-	clk->rate = devtree_getfreq("psc_mclk_in");
-	if (!clk->rate)
-		clk->rate = 25000000;
-}
-
-static struct clk psc_mclk_in = {
-	.name = "psc_mclk_in",
-	.calc = psc_mclk_in_calc,
-};
-
-static struct clk spdif_txclk = {
-	.name = "spdif_txclk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 23,
-};
-
-static struct clk spdif_rxclk = {
-	.name = "spdif_rxclk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 23,
-};
-
-static void ac97_clk_calc(struct clk *clk)
-{
-	/* ac97 bit clock is always 24.567 MHz */
-	clk->rate = 24567000;
-}
-
-static struct clk ac97_clk = {
-	.name = "ac97_clk_in",
-	.calc = ac97_clk_calc,
-};
-
-static struct clk *rate_clks[] = {
-	&ref_clk,
-	&sys_clk,
-	&diu_clk,
-	&viu_clk,
-	&csb_clk,
-	&e300_clk,
-	&ips_clk,
-	&fec_clk,
-	&sata_clk,
-	&pata_clk,
-	&nfc_clk,
-	&lpc_clk,
-	&mbx_bus_clk,
-	&mbx_clk,
-	&mbx_3d_clk,
-	&axe_clk,
-	&usb1_clk,
-	&usb2_clk,
-	&i2c_clk,
-	&mscan_clk,
-	&sdhc_clk,
-	&pci_clk,
-	&psc_mclk_in,
-	&spdif_txclk,
-	&spdif_rxclk,
-	&ac97_clk,
-	NULL
-};
-
-static void rate_clk_init(struct clk *clk)
-{
-	if (clk->calc) {
-		clk->calc(clk);
-		clk->flags |= CLK_HAS_RATE;
-		clk_register(clk);
-	} else {
-		printk(KERN_WARNING
-		       "Could not initialize clk %s without a calc routine\n",
-		       clk->name);
-	}
-}
-
-static void rate_clks_init(void)
-{
-	struct clk **cpp, *clk;
-
-	cpp = rate_clks;
-	while ((clk = *cpp++))
-		rate_clk_init(clk);
-}
-
-/*
- * There are two clk enable registers with 32 enable bits each
- * psc clocks and device clocks are all stored in dev_clks
- */
-static struct clk dev_clks[2][32];
-
-/*
- * Given a psc number return the dev_clk
- * associated with it
- */
-static struct clk *psc_dev_clk(int pscnum)
-{
-	int reg, bit;
-	struct clk *clk;
-
-	reg = 0;
-	bit = 27 - pscnum;
-
-	clk = &dev_clks[reg][bit];
-	clk->reg = 0;
-	clk->bit = bit;
-	return clk;
-}
-
-/*
- * PSC clock rate calculation
- */
-static void psc_calc_rate(struct clk *clk, int pscnum, struct device_node *np)
-{
-	unsigned long mclk_src = sys_clk.rate;
-	unsigned long mclk_div;
-
-	/*
-	 * Can only change value of mclk divider
-	 * when the divider is disabled.
-	 *
-	 * Zero is not a valid divider so minimum
-	 * divider is 1
-	 *
-	 * disable/set divider/enable
-	 */
-	out_be32(&clockctl->pccr[pscnum], 0);
-	out_be32(&clockctl->pccr[pscnum], 0x00020000);
-	out_be32(&clockctl->pccr[pscnum], 0x00030000);
-
-	if (in_be32(&clockctl->pccr[pscnum]) & 0x80) {
-		clk->rate = spdif_rxclk.rate;
-		return;
-	}
-
-	switch ((in_be32(&clockctl->pccr[pscnum]) >> 14) & 0x3) {
-	case 0:
-		mclk_src = sys_clk.rate;
-		break;
-	case 1:
-		mclk_src = ref_clk.rate;
-		break;
-	case 2:
-		mclk_src = psc_mclk_in.rate;
-		break;
-	case 3:
-		mclk_src = spdif_txclk.rate;
-		break;
-	}
-
-	mclk_div = ((in_be32(&clockctl->pccr[pscnum]) >> 17) & 0x7fff) + 1;
-	clk->rate = mclk_src / mclk_div;
-}
-
-/*
- * Find all psc nodes in device tree and assign a clock
- * with name "psc%d_mclk" and dev pointing at the device
- * returned from of_find_device_by_node
- */
-static void psc_clks_init(void)
-{
-	struct device_node *np;
-	struct platform_device *ofdev;
-	u32 reg;
-	const char *psc_compat;
-
-	psc_compat = mpc512x_select_psc_compat();
-	if (!psc_compat)
-		return;
-
-	for_each_compatible_node(np, NULL, psc_compat) {
-		if (!of_property_read_u32(np, "reg", &reg)) {
-			int pscnum = (reg & 0xf00) >> 8;
-			struct clk *clk = psc_dev_clk(pscnum);
-
-			clk->flags = CLK_HAS_RATE | CLK_HAS_CTRL;
-			ofdev = of_find_device_by_node(np);
-			clk->dev = &ofdev->dev;
-			/*
-			 * AC97 is special rate clock does
-			 * not go through normal path
-			 */
-			if (of_device_is_compatible(np, "fsl,mpc5121-psc-ac97"))
-				clk->rate = ac97_clk.rate;
-			else
-				psc_calc_rate(clk, pscnum, np);
-			sprintf(clk->name, "psc%d_mclk", pscnum);
-			clk_register(clk);
-			clk_enable(clk);
-		}
-	}
-}
-
-static struct clk_interface mpc5121_clk_functions = {
-	.clk_get		= mpc5121_clk_get,
-	.clk_enable		= mpc5121_clk_enable,
-	.clk_disable		= mpc5121_clk_disable,
-	.clk_get_rate		= mpc5121_clk_get_rate,
-	.clk_put		= mpc5121_clk_put,
-	.clk_round_rate		= mpc5121_clk_round_rate,
-	.clk_set_rate		= mpc5121_clk_set_rate,
-	.clk_set_parent		= NULL,
-	.clk_get_parent		= NULL,
-};
-
-int __init mpc5121_clk_init(void)
-{
-	struct device_node *np;
-
-	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-clock");
-	if (np) {
-		clockctl = of_iomap(np, 0);
-		of_node_put(np);
-	}
-
-	if (!clockctl) {
-		printk(KERN_ERR "Could not map clock control registers\n");
-		return 0;
-	}
-
-	rate_clks_init();
-	psc_clks_init();
-
-	/* leave clockctl mapped forever */
-	/*iounmap(clockctl); */
-	DEBUG_CLK_DUMP();
-	clocks_initialized++;
-	clk_functions = mpc5121_clk_functions;
-	return 0;
-}
-- 
1.7.10.4



From nicolas.ferre at atmel.com  Tue Jul 16 04:46:28 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 16 Jul 2013 10:46:28 +0200
Subject: [PATCH 2/5] iio: at91: Use different prescal, startup mask in
 MR for different IP
In-Reply-To: <51E505EA.4060502@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
 <20130715125815.GC2962@lukather> <51E505EA.4060502@atmel.com>
Message-ID: <51E50864.6020904@atmel.com>

On 16/07/2013 10:35, Josh Wu :
> Hi, Maxime
>
> On 7/15/2013 8:58 PM, Maxime Ripard wrote:
>> Hi Josh,
>>
>> On Sun, Jul 14, 2013 at 04:04:26PM +0800, Josh Wu wrote:
>>> For at91 boards, there are different IPs for adc. Different IPs has
>>> different
>>> STARTUP & PRESCAL mask in ADC_MR.
>>>
>>> This patch can change the masks according to the different IP version.
>>>
>>> Signed-off-by: Josh Wu <josh.wu at atmel.com>
>>> ---
>>>   arch/arm/mach-at91/include/mach/at91_adc.h |    9 ++++--
>>>   drivers/iio/adc/at91_adc.c                 |   48
>>> ++++++++++++++++++++++++++--
>>>   2 files changed, 53 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-at91/include/mach/at91_adc.h
>>> b/arch/arm/mach-at91/include/mach/at91_adc.h
>>> index 8e7ed5c..ab273ee 100644
>>> --- a/arch/arm/mach-at91/include/mach/at91_adc.h
>>> +++ b/arch/arm/mach-at91/include/mach/at91_adc.h
>>> @@ -28,9 +28,12 @@
>>>   #define            AT91_ADC_TRGSEL_EXTERNAL    (6 << 1)
>>>   #define        AT91_ADC_LOWRES        (1 << 4)    /* Low Resolution */
>>>   #define        AT91_ADC_SLEEP        (1 << 5)    /* Sleep Mode */
>>> -#define        AT91_ADC_PRESCAL    (0x3f << 8)    /* Prescalar Rate
>>> Selection */
>>> +#define        AT91_ADC_PRESCAL    (0xff << 8)    /* Prescalar Rate
>>> Selection */
>>> +#define        AT91_ADC_PRESCAL_9260    (0x3f << 8)
>>>   #define            AT91_ADC_PRESCAL_(x)    ((x) << 8)
>>> -#define        AT91_ADC_STARTUP    (0x1f << 16)    /* Startup Up
>>> Time */
>>> +#define        AT91_ADC_STARTUP    (0xf << 16)    /* Startup Up Time */
>>> +#define        AT91_ADC_STARTUP_9260    (0x1f << 16)
>>> +#define        AT91_ADC_STARTUP_9G45    (0x7f << 16)
>>>   #define            AT91_ADC_STARTUP_(x)    ((x) << 16)
>>>   #define        AT91_ADC_SHTIM        (0xf  << 24)    /* Sample &
>>> Hold Time */
>>>   #define            AT91_ADC_SHTIM_(x)    ((x) << 24)
>>> @@ -58,4 +61,6 @@
>>>   #define AT91_ADC_CHR(n)        (0x30 + ((n) * 4))    /* Channel
>>> Data Register N */
>>>   #define        AT91_ADC_DATA        (0x3ff)
>>> +#define AT91_ADC_VERSION    0xFC
>>> +
>>>   #endif
>>> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
>>> index 18bd54f..14e99ba 100644
>>> --- a/drivers/iio/adc/at91_adc.c
>>> +++ b/drivers/iio/adc/at91_adc.c
>>> @@ -39,6 +39,12 @@
>>>   #define at91_adc_writel(st, reg, val) \
>>>       (writel_relaxed(val, st->reg_base + reg))
>>> +struct at91_adc_caps {
>>> +    bool    has_tsmr;    /* only at91sam9x5, sama5d3 have TSMR reg */
>>> +    u32    mr_prescal_mask;
>>> +    u32    mr_startup_mask;
>>> +};
>>> +
>>>   struct at91_adc_state {
>>>       struct clk        *adc_clk;
>>>       u16            *buffer;
>>> @@ -62,6 +68,7 @@ struct at91_adc_state {
>>>       u32            res;        /* resolution used for convertions */
>>>       bool            low_res;    /* the resolution corresponds to
>>> the lowest one */
>>>       wait_queue_head_t    wq_data_avail;
>>> +    struct at91_adc_caps    caps;
>>>   };
>>>   static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
>>> @@ -580,6 +587,41 @@ static const struct iio_info at91_adc_info = {
>>>       .read_raw = &at91_adc_read_raw,
>>>   };
>>> +/*
>>> + * Since atmel adc support different ip for touchscreen mode.
>>> Through the
>>> + * IP check, we will know the touchscreen capbilities.
>>> + */
>>> +static void atmel_adc_get_cap(struct at91_adc_state *st)
>>> +{
>>> +    unsigned int version;
>>> +    struct iio_dev *idev = iio_priv_to_dev(st);
>>> +
>>> +    version = at91_adc_readl(st, AT91_ADC_VERSION);
>>> +    dev_dbg(&idev->dev, "version: 0x%x\n", version);
>>> +
>>> +    st->caps.mr_prescal_mask = AT91_ADC_PRESCAL_9260;
>>> +    st->caps.mr_startup_mask = AT91_ADC_STARTUP_9260;
>>> +
>>> +    /* keep only major version number */
>>> +    switch (version & 0xf00) {
>>> +    case 0x500:    /* SAMA5D3 */
>>> +    case 0x400:    /* AT91SAM9X5/9N12 */
>>> +        st->caps.has_tsmr = 1;
>>> +        st->caps.mr_startup_mask = AT91_ADC_STARTUP;
>>> +    case 0x200:    /* AT91SAM9M10/9G45 */
>>> +        st->caps.mr_prescal_mask = AT91_ADC_PRESCAL;
>>> +
>>> +        if ((version & 0xf00) == 0x200)
>>> +            st->caps.mr_startup_mask = AT91_ADC_STARTUP_9G45;
>>> +    case 0x100:    /* AT91SAM9260/9G20 */
>>> +        break;
>>> +    default:
>>> +        dev_warn(&idev->dev,
>>> +                "Unmanaged adc version, use minimal capabilities\n");
>>> +        break;
>>> +    };
>>> +}
>> Why don't you use different compatible names and derive your
>> capabilities from which compatible is declared.
>>
>> It seems safer.

I see it as handier in the sense that a different IP version can be 
compatible with an older IP version: so we do not need to modify the 
driver just to use another SoC.

On your side Maxime, what makes you say that it is "safer"?

> Ok, that make sense. I will use compatible names for the capabilities in
> next version. Thanks.

Hold on a little bit Josh, I know that Jean-Christophe is not in favor 
of the use of multiple compatible strings. So, as the code is already 
there, let's wait and see if we find another argument...

Bye,
-- 
Nicolas Ferre


From shawn.guo at linaro.org  Tue Jul 16 04:47:36 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 16:47:36 +0800
Subject: [PATCH 10/22] arm/dts: Add support for the cpuimx25 board from
 Eukrea and its baseboard.
In-Reply-To: <1373900227-341-11-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-11-git-send-email-denis@eukrea.com>
Message-ID: <20130716084733.GI30067@S2101-09.ap.freescale.net>

On Mon, Jul 15, 2013 at 04:56:55PM +0200, Denis Carikli wrote:
> Only the following devices/functionalities were added:
>  * Main UART
>  * Memory node
>  * NAND
>  * i2c and its pcf8563
>  * Ethernet
>  * LCD controller
>  * Sound
>  * ESDHC
> 
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  Documentation/devicetree/bindings/arm/fsl.txt     |    4 ++
>  arch/arm/boot/dts/eukrea_cpuimx25.dts             |   48 +++++++++++++++++
>  arch/arm/boot/dts/eukrea_mbimxsd25-baseboard.dtsi |   59 +++++++++++++++++++++
>  3 files changed, 111 insertions(+)
>  create mode 100644 arch/arm/boot/dts/eukrea_cpuimx25.dts
>  create mode 100644 arch/arm/boot/dts/eukrea_mbimxsd25-baseboard.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
> index e935d7d..2c19348 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.txt
> +++ b/Documentation/devicetree/bindings/arm/fsl.txt
> @@ -9,6 +9,10 @@ i.MX25 Product Development Kit
>  Required root node properties:
>      - compatible = "fsl,imx25-pdk", "fsl,imx25";
>  
> +i.MX25 Eukrea CPUIMX25 Board.
> +Required root node properties:
> +    - compatible = "fsl,eukrea_cpuimx25", "fsl,imx25";
> +

This is not a board produced by Freescale, and shouldn't be added here.
Also recently, it seems that documenting custom board compatible is not
required as hard as before.

>  i.MX27 Product Development Kit
>  Required root node properties:
>      - compatible = "fsl,imx27-pdk", "fsl,imx27";
> diff --git a/arch/arm/boot/dts/eukrea_cpuimx25.dts b/arch/arm/boot/dts/eukrea_cpuimx25.dts
> new file mode 100644
> index 0000000..a65243c
> --- /dev/null
> +++ b/arch/arm/boot/dts/eukrea_cpuimx25.dts
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright 2013 Eukr?a Electromatique <denis at eukrea.com>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/dts-v1/;
> +#include "imx25.dtsi"
> +#include "eukrea_mbimxsd25-baseboard.dtsi"
> +
> +/ {
> +	model = "Eukrea CPUIMX25";
> +	compatible = "fsl,eukrea_cpuimx25", "fsl,imx25";
> +
> +	memory {
> +		reg = <0x80000000 0x4000000>; /* 64M */
> +	};
> +};
> +
> +&fec {
> +	phy-mode = "rmii";
> +	status = "okay";

Please consistently put "status" at the end of property list.

> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_fec_1>;
> +};
> +
> +&nfc {
> +	nand-bus-width = <8>;
> +	nand-ecc-mode = "hw";
> +	nand-on-flash-bbt;
> +	status = "okay";
> +};
> +
> +&i2c1 {

Please sort the nodes in alphabet order.

Shawn

> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c1_1>;
> +
> +	pcf8563 at 51 {
> +		compatible = "nxp,pcf8563";
> +		reg = <0x51>;
> +	};
> +};
> diff --git a/arch/arm/boot/dts/eukrea_mbimxsd25-baseboard.dtsi b/arch/arm/boot/dts/eukrea_mbimxsd25-baseboard.dtsi
> new file mode 100644
> index 0000000..ffaf657
> --- /dev/null
> +++ b/arch/arm/boot/dts/eukrea_mbimxsd25-baseboard.dtsi
> @@ -0,0 +1,59 @@
> +/*
> + * Copyright 2013 Eukr?a Electromatique <denis at eukrea.com>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#include "skeleton.dtsi"
> +
> +/ {
> +	sound {
> +		compatible = "fsl,eukrea-tlv320";
> +		model = "imx25-eukrea-tlv320aic23";
> +		ssi-controller = <&ssi1>;
> +		fsl,audio-codec = <&tlv320aic23>;
> +		mux-int-port = <1>;
> +		mux-ext-port = <5>;
> +	};
> +};
> +
> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart1_1>;
> +	fsl,uart-has-rtscts;
> +	status = "okay";
> +};
> +
> +&lcdc {
> +	status = "okay";
> +};
> +
> +&audmux {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_audmux_1>;
> +};
> +
> +&ssi1 {
> +	fsl,mode = "i2s-slave";
> +	status = "okay";
> +};
> +
> +&i2c1 {
> +	tlv320aic23: codec at 1a {
> +		compatible = "ti,tlv320aic23";
> +		reg = <0x1a>;
> +	};
> +};
> +
> +&esdhc1 {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_esdhc1_1>;
> +	cd-gpios = <&gpio1 20>;
> +};
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From shawn.guo at linaro.org  Tue Jul 16 04:49:41 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 16:49:41 +0800
Subject: [PATCH 12/22] video: backlight: Add GPIO Backlight driver.
In-Reply-To: <1373900227-341-13-git-send-email-denis@eukrea.com>
References: <1373900227-341-1-git-send-email-denis@eukrea.com>
 <1373900227-341-13-git-send-email-denis@eukrea.com>
Message-ID: <20130716084926.GJ30067@S2101-09.ap.freescale.net>

On Mon, Jul 15, 2013 at 04:56:57PM +0200, Denis Carikli wrote:
> This initial driver uses and depends on DT bindings.
> 
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> ---
>  .../bindings/video/backlight/gpio-backlight.txt    |   18 ++
>  drivers/video/backlight/Kconfig                    |    7 +
>  drivers/video/backlight/Makefile                   |    1 +
>  drivers/video/backlight/gpio_bl.c                  |  226 ++++++++++++++++++++
>  4 files changed, 252 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt
>  create mode 100644 drivers/video/backlight/gpio_bl.c

Please send the patch to subsystem mailing list and maintainers.

Shawn



From Sudeep.KarkadaNagesha at arm.com  Tue Jul 16 05:03:21 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Tue, 16 Jul 2013 10:03:21 +0100
Subject: [RFC PATCH 02/11] ARM: DT/kernel: define ARM specific
 arch_of_get_cpu_node
In-Reply-To: <51E44943.7000600@gmail.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1373883732-26303-3-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <51E44943.7000600@gmail.com>
Message-ID: <51E50C59.50900@arm.com>

On 15/07/13 20:10, Rob Herring wrote:
> On 07/15/2013 05:22 AM, Sudeep.KarkadaNagesha at arm.com wrote:
>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>>
>> CPU subsystem now provides architecture specific hook to retrieve the
>> of_node. Most of the cpu DT node parsing and initialisation is contained
>> in devtree.c. It's better to contain all CPU device node parsing there.
>>
>> arch_of_get_cpu_node is mainly used to assign cpu->of_node when CPUs get
>> registered. This patch overrides the defination of the same. It can also
>> act as the helper function in pre-SMP/early initialisation stages to
>> retrieve CPU device node pointers in logical ordering.
>>
>> This mainly helps to avoid replication of the code doing CPU node parsing
>> and physical(MPIDR) to logical mapping.
>>
>> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> [snip]
> 
>> +struct device_node * __init arch_of_get_cpu_node(int cpu)
>> +{
>> +	struct device_node *cpun, *cpus;
>> +	const u32 *cell;
>> +	u64 hwid;
>> +	int ac;
>> +
>> +	cpus = of_find_node_by_path("/cpus");
>> +	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
>> +		return NULL;
>> +
>> +	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
>> +		ac = of_n_addr_cells(cpus);
>> +
>> +	for_each_child_of_node(cpus, cpun) {
>> +		if (of_node_cmp(cpun->type, "cpu"))
>> +			continue;
>> +		cell = of_get_property(cpun, "reg", NULL);
>> +		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
>> +			continue;
>> +
>> +		hwid = of_read_number(cell, ac);
>> +		if ((hwid & MPIDR_HWID_BITMASK) == cpu_logical_map(cpu))
> 
> Most of this function is not ARM specific, so it would be nice if we
> could shrink the arch specific part down to just this match. A default
> match of reg == logical cpu number might be useful.
> 
I completely agree, in fact that was my initial idea too.

But when I had a look at powerpc implementation of "of_get_cpu_node" in
arch/powerpc/kernel/prom.c, it looked like PPC is using some
compatibles(e.g. ibm,ppc-interrupt-server#s) which are not specified in
ePAPR. I am not sure is that's allowed or not, if allowed then we can't
have generic of_get_cpu_node with just arch specific hwid matching function.

Let me know how would you prefer me to proceed on this.

Regards,
Sudeep



From tony at atomide.com  Tue Jul 16 05:05:24 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 02:05:24 -0700
Subject: [PATCH 0/4] improved support for runtime muxing for pinctrl
Message-ID: <20130716090310.5541.36777.stgit@localhost>

Hi all,

As discussed earlier, the pinctrl support for changing some of the
consumer device pins during runtime needs some improvment.

Here are the patches to do that, I'll also post a minimal sample
patch as a reply to this thread on how to do the muxing for
runtime PM.

Regards,

Tony

---

Tony Lindgren (4):
      pinctrl: Remove duplicate code in pinctrl_pm_select_state functions
      pinctrl: Allow pinctrl to have multiple active states
      pinctrl: Add support for additional dynamic states
      drivers: Add pinctrl handling for dynamic pin states


 drivers/base/pinctrl.c                |   39 +++++
 drivers/pinctrl/core.c                |  250 ++++++++++++++++++++++++++++-----
 drivers/pinctrl/core.h                |   10 +
 include/linux/pinctrl/consumer.h      |   46 ++++++
 include/linux/pinctrl/devinfo.h       |    4 +
 include/linux/pinctrl/pinctrl-state.h |   15 ++
 6 files changed, 321 insertions(+), 43 deletions(-)

-- 
Signature


From tony at atomide.com  Tue Jul 16 05:05:34 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 02:05:34 -0700
Subject: [PATCH 2/4] pinctrl: Allow pinctrl to have multiple active states
In-Reply-To: <20130716090310.5541.36777.stgit@localhost>
References: <20130716090310.5541.36777.stgit@localhost>
Message-ID: <20130716090534.5541.60381.stgit@localhost>

It's quite common that we need to dynamically change some pins for a
device for runtime PM, or toggle a pin between rx and tx. Changing all
the pins for a device is not efficient way of doing it.

So let's allow setting up multiple active states for pinctrl. Currently
we only need PINCTRL_STATIC and PINCTRL_DYNAMIC, where PINCTRL_STATIC
covers the current default pins, and PINCTRL_DYNAMIC holds the dynamic
pins that need to be toggled.

Cc: Stephen Warren <swarren at wwwdotorg.org>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 drivers/pinctrl/core.c |   18 ++++++++++--------
 drivers/pinctrl/core.h |   10 ++++++++--
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index bda2c61..8da11d5 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -885,7 +885,8 @@ static void pinctrl_free(struct pinctrl *p, bool inlist)
 	mutex_lock(&pinctrl_list_mutex);
 	list_for_each_entry_safe(state, n1, &p->states, node) {
 		list_for_each_entry_safe(setting, n2, &state->settings, node) {
-			pinctrl_free_setting(state == p->state, setting);
+			pinctrl_free_setting(state == p->state[PINCTRL_STATIC],
+					     setting);
 			list_del(&setting->node);
 			kfree(setting);
 		}
@@ -955,13 +956,13 @@ EXPORT_SYMBOL_GPL(pinctrl_lookup_state);
 int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
 {
 	struct pinctrl_setting *setting, *setting2;
-	struct pinctrl_state *old_state = p->state;
+	struct pinctrl_state *old_state = p->state[PINCTRL_STATIC];
 	int ret;
 
-	if (p->state == state)
+	if (old_state == state)
 		return 0;
 
-	if (p->state) {
+	if (old_state) {
 		/*
 		 * The set of groups with a mux configuration in the old state
 		 * may not be identical to the set of groups with a mux setting
@@ -971,7 +972,7 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
 		 * but not in the new state, this code puts that group into a
 		 * safe/disabled state.
 		 */
-		list_for_each_entry(setting, &p->state->settings, node) {
+		list_for_each_entry(setting, &old_state->settings, node) {
 			bool found = false;
 			if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
 				continue;
@@ -989,7 +990,7 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
 		}
 	}
 
-	p->state = NULL;
+	p->state[PINCTRL_STATIC] = NULL;
 
 	/* Apply all the settings for the new state */
 	list_for_each_entry(setting, &state->settings, node) {
@@ -1011,7 +1012,7 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
 		}
 	}
 
-	p->state = state;
+	p->state[PINCTRL_STATIC] = state;
 
 	return 0;
 
@@ -1484,7 +1485,8 @@ static int pinctrl_show(struct seq_file *s, void *what)
 	list_for_each_entry(p, &pinctrl_list, node) {
 		seq_printf(s, "device: %s current state: %s\n",
 			   dev_name(p->dev),
-			   p->state ? p->state->name : "none");
+			   p->state[PINCTRL_STATIC] ?
+			   p->state[PINCTRL_STATIC]->name : "none");
 
 		list_for_each_entry(state, &p->states, node) {
 			seq_printf(s, "  state: %s\n", state->name);
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
index 75476b3..b99e4b3 100644
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -53,12 +53,18 @@ struct pinctrl_dev {
 #endif
 };
 
+enum pinctr_states {
+	PINCTRL_STATIC,
+	PINCTRL_DYNAMIC,
+	PINCTRL_NR_STATES,
+};
+
 /**
  * struct pinctrl - per-device pin control state holder
  * @node: global list node
  * @dev: the device using this pin control handle
  * @states: a list of states for this device
- * @state: the current state
+ * @state: the current state(s)
  * @dt_maps: the mapping table chunks dynamically parsed from device tree for
  *	this device, if any
  * @users: reference count
@@ -67,7 +73,7 @@ struct pinctrl {
 	struct list_head node;
 	struct device *dev;
 	struct list_head states;
-	struct pinctrl_state *state;
+	struct pinctrl_state *state[PINCTRL_NR_STATES];
 	struct list_head dt_maps;
 	struct kref users;
 };



From tony at atomide.com  Tue Jul 16 05:05:29 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 02:05:29 -0700
Subject: [PATCH 1/4] pinctrl: Remove duplicate code in
 pinctrl_pm_select_state functions
In-Reply-To: <20130716090310.5541.36777.stgit@localhost>
References: <20130716090310.5541.36777.stgit@localhost>
Message-ID: <20130716090529.5541.54331.stgit@localhost>

There's no need to duplicate essentially the same functions. Let's
introduce static int pinctrl_pm_select_state() and make the other
related functions call that.

This allows us to add support later on for multiple active states,
and more optimized dynamic remuxing.

Note that we still need to export the various pinctrl_pm_select
functions as we want to keep struct pinctrl_state private to the
pinctrl code, and cannot replace those with inline functions.

Cc: Stephen Warren <swarren at wwwdotorg.org>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 drivers/pinctrl/core.c |   47 +++++++++++++++++++----------------------------
 1 file changed, 19 insertions(+), 28 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 5b272bf..bda2c61 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1227,23 +1227,34 @@ EXPORT_SYMBOL_GPL(pinctrl_force_default);
 #ifdef CONFIG_PM
 
 /**
- * pinctrl_pm_select_default_state() - select default pinctrl state for PM
+ * pinctrl_pm_select_state() - select pinctrl state for PM
  * @dev: device to select default state for
+ * @state: state to set
  */
-int pinctrl_pm_select_default_state(struct device *dev)
+static int pinctrl_pm_select_state(struct device *dev, struct pinctrl_state *state)
 {
 	struct dev_pin_info *pins = dev->pins;
 	int ret;
 
 	if (!pins)
 		return 0;
-	if (IS_ERR(pins->default_state))
-		return 0; /* No default state */
-	ret = pinctrl_select_state(pins->p, pins->default_state);
+	if (IS_ERR(state))
+		return 0; /* No such state */
+	ret = pinctrl_select_state(pins->p, state);
 	if (ret)
-		dev_err(dev, "failed to activate default pinctrl state\n");
+		dev_err(dev, "failed to activate pinctrl state %s\n",
+			state->name);
 	return ret;
 }
+
+/**
+ * pinctrl_pm_select_default_state() - select default pinctrl state for PM
+ * @dev: device to select default state for
+ */
+int pinctrl_pm_select_default_state(struct device *dev)
+{
+	return pinctrl_pm_select_state(dev, dev->pins->default_state);
+}
 EXPORT_SYMBOL_GPL(pinctrl_pm_select_default_state);
 
 /**
@@ -1252,17 +1263,7 @@ EXPORT_SYMBOL_GPL(pinctrl_pm_select_default_state);
  */
 int pinctrl_pm_select_sleep_state(struct device *dev)
 {
-	struct dev_pin_info *pins = dev->pins;
-	int ret;
-
-	if (!pins)
-		return 0;
-	if (IS_ERR(pins->sleep_state))
-		return 0; /* No sleep state */
-	ret = pinctrl_select_state(pins->p, pins->sleep_state);
-	if (ret)
-		dev_err(dev, "failed to activate pinctrl sleep state\n");
-	return ret;
+	return pinctrl_pm_select_state(dev, dev->pins->sleep_state);
 }
 EXPORT_SYMBOL_GPL(pinctrl_pm_select_sleep_state);
 
@@ -1272,17 +1273,7 @@ EXPORT_SYMBOL_GPL(pinctrl_pm_select_sleep_state);
  */
 int pinctrl_pm_select_idle_state(struct device *dev)
 {
-	struct dev_pin_info *pins = dev->pins;
-	int ret;
-
-	if (!pins)
-		return 0;
-	if (IS_ERR(pins->idle_state))
-		return 0; /* No idle state */
-	ret = pinctrl_select_state(pins->p, pins->idle_state);
-	if (ret)
-		dev_err(dev, "failed to activate pinctrl idle state\n");
-	return ret;
+	return pinctrl_pm_select_state(dev, dev->pins->idle_state);
 }
 EXPORT_SYMBOL_GPL(pinctrl_pm_select_idle_state);
 #endif



From tony at atomide.com  Tue Jul 16 05:05:36 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 02:05:36 -0700
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130716090310.5541.36777.stgit@localhost>
References: <20130716090310.5541.36777.stgit@localhost>
Message-ID: <20130716090536.5541.36289.stgit@localhost>

To toggle dynamic states, let's add the optional active state in
addition to the static default state. Then if the optional active
state is defined, we can require that idle and sleep states cover
the same pingroups as the active state.

Then let's add pinctrl_check_dynamic() and pinctrl_select_dynamic()
to use instead of pinctrl_select() to avoid breaking existing users.

With pinctrl_check_dynamic() we can check that idle and sleep states
match the active state for pingroups during init, and don't need to
do it during runtime.

Then with the states pre-validated, pinctrl_select_dynamic() can
just toggle between the dynamic states without extra checks.

Note that pinctr_select_state() still has valid use cases, such as
changing states when the pins can be shared between two drivers
and don't necessarily cover the same pingroups. For dynamic runtime
toggling of pin states, we should eventually always use just
pinctrl_select_dynamic().

Cc: Stephen Warren <swarren at wwwdotorg.org>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 drivers/pinctrl/core.c                |  189 ++++++++++++++++++++++++++++++++-
 include/linux/pinctrl/consumer.h      |   46 ++++++++
 include/linux/pinctrl/devinfo.h       |    4 +
 include/linux/pinctrl/pinctrl-state.h |   15 ++-
 4 files changed, 249 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 8da11d5..4f58a97 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -887,6 +887,8 @@ static void pinctrl_free(struct pinctrl *p, bool inlist)
 		list_for_each_entry_safe(setting, n2, &state->settings, node) {
 			pinctrl_free_setting(state == p->state[PINCTRL_STATIC],
 					     setting);
+			pinctrl_free_setting(state == p->state[PINCTRL_DYNAMIC],
+					     setting);
 			list_del(&setting->node);
 			kfree(setting);
 		}
@@ -1041,6 +1043,134 @@ unapply_new_state:
 }
 EXPORT_SYMBOL_GPL(pinctrl_select_state);
 
+/**
+ * pinctrl_check_dynamic() - compare two states for the pins
+ * @dev: pinctrl consumer device pointer
+ * @st1: state handle
+ * @st2: state handle
+ *
+ * This function checks that the group pins match between the two
+ * states to avoid runtime checking. Use this to check dynamic pin
+ * states during init.
+ */
+int pinctrl_check_dynamic(struct device *dev, struct pinctrl_state *st1,
+			  struct pinctrl_state *st2)
+{
+	struct pinctrl_setting *s1, *s2;
+
+	list_for_each_entry(s1, &st1->settings, node) {
+		struct pinctrl_dev *pctldev1;
+		const struct pinctrl_ops *pctlops1;
+		const unsigned *pins1;
+		unsigned num_pins1;
+		int res;
+
+		if (s1->type != PIN_MAP_TYPE_MUX_GROUP)
+			continue;
+
+		pctldev1 = s1->pctldev;
+		pctlops1 = pctldev1->desc->pctlops;
+		res = pctlops1->get_group_pins(pctldev1, s1->data.mux.group,
+					       &pins1, &num_pins1);
+		if (res) {
+			dev_dbg(dev, "could not get state1 group pins\n");
+			return -EINVAL;
+		}
+
+		list_for_each_entry(s2, &st2->settings, node) {
+			struct pinctrl_dev *pctldev2;
+			const struct pinctrl_ops *pctlops2;
+			const unsigned *pins2;
+			unsigned num_pins2;
+			int i, j, found = 0;
+
+			if (s2->type != PIN_MAP_TYPE_MUX_GROUP)
+				continue;
+
+			pctldev2 = s2->pctldev;
+			if (pctldev1 != pctldev2) {
+				dev_dbg(dev, "pctldev must be the same for states\n");
+				return -EINVAL;
+			}
+			pctlops2 = pctldev2->desc->pctlops;
+			res = pctlops2->get_group_pins(pctldev2,
+						       s2->data.mux.group,
+						       &pins2, &num_pins2);
+			if (res) {
+				dev_dbg(dev, "could not get state2 group pins\n");
+				return -EINVAL;
+			}
+
+			for (i = 0; i < num_pins1; i++) {
+				int pin1 = pins1[i];
+
+				for (j = 0; j < num_pins2; j++) {
+					int pin2 = pins2[j];
+
+					if (pin1 == pin2) {
+						found++;
+						break;
+					}
+				}
+			}
+
+			if (found != num_pins1) {
+				dev_dbg(dev, "found only %i of %i pins\n",
+					found, num_pins1);
+				return -EINVAL;
+			}
+		}
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pinctrl_check_dynamic);
+
+/**
+ * pinctrl_select_dynamic() - fast path for toggling pre-validated sets of pins
+ * @p: the pinctrl handle for the device that requests configuration
+ * @state: the state handle to select/activate/program
+ *
+ * Note that as we've already checked that the PINCTRL_DYNAMIC pins always
+ * cover the same sets for active/idle, or rx/tx, there's no need to call
+ * pinux_disable_settings() on these pins. Calling it could also cause
+ * issues for the connected peripheral as it potentially could change the
+ * values of data lines for example.
+ */
+int pinctrl_select_dynamic(struct pinctrl *p, struct pinctrl_state *state)
+{
+	struct pinctrl_setting *setting;
+	int ret;
+
+	if (p->state[PINCTRL_DYNAMIC] == state)
+		return 0;
+
+	list_for_each_entry(setting, &state->settings, node) {
+		switch (setting->type) {
+		case PIN_MAP_TYPE_MUX_GROUP:
+			ret = pinmux_enable_setting(setting);
+			break;
+		case PIN_MAP_TYPE_CONFIGS_PIN:
+		case PIN_MAP_TYPE_CONFIGS_GROUP:
+			ret = pinconf_apply_setting(setting);
+			break;
+		default:
+			ret = -EINVAL;
+			break;
+		}
+
+		if (ret < 0) {
+			dev_err(p->dev, "Error applying dynamic settings\n");
+			return ret;
+		}
+	}
+
+	p->state[PINCTRL_DYNAMIC] = state;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pinctrl_select_dynamic);
+
 static void devm_pinctrl_release(struct device *dev, void *res)
 {
 	pinctrl_put(*(struct pinctrl **)res);
@@ -1241,7 +1371,13 @@ static int pinctrl_pm_select_state(struct device *dev, struct pinctrl_state *sta
 		return 0;
 	if (IS_ERR(state))
 		return 0; /* No such state */
-	ret = pinctrl_select_state(pins->p, state);
+
+	/* Configured for proper dynamic muxing? */
+	if (!IS_ERR(dev->pins->active_state))
+		ret = pinctrl_select_dynamic(pins->p, state);
+	else
+		ret = pinctrl_select_state(pins->p, state);
+
 	if (ret)
 		dev_err(dev, "failed to activate pinctrl state %s\n",
 			state->name);
@@ -1259,6 +1395,16 @@ int pinctrl_pm_select_default_state(struct device *dev)
 EXPORT_SYMBOL_GPL(pinctrl_pm_select_default_state);
 
 /**
+ * pinctrl_pm_select_active_state() - select active pinctrl state for PM
+ * @dev: device to select default state for
+ */
+int pinctrl_pm_select_active_state(struct device *dev)
+{
+	return pinctrl_pm_select_state(dev, dev->pins->active_state);
+}
+EXPORT_SYMBOL_GPL(pinctrl_pm_select_active_state);
+
+/**
  * pinctrl_pm_select_sleep_state() - select sleep pinctrl state for PM
  * @dev: device to select sleep state for
  */
@@ -1277,6 +1423,41 @@ int pinctrl_pm_select_idle_state(struct device *dev)
 	return pinctrl_pm_select_state(dev, dev->pins->idle_state);
 }
 EXPORT_SYMBOL_GPL(pinctrl_pm_select_idle_state);
+
+static int pinctrl_pm_check_state(struct device *dev,
+				  struct pinctrl_state *state)
+{
+	if (!dev)
+		return -EINVAL;
+
+	return IS_ERR(state);
+}
+
+/**
+ * pinctrl_pm_check_sleep_state() - check if sleep state is configured
+ * @dev: consumer device
+ *
+ * Call this from consumer driver to check if the sleep state
+ * has been properly configured on the device.
+ */
+int pinctrl_pm_check_sleep_state(struct device *dev)
+{
+	return pinctrl_pm_check_state(dev, dev->pins->sleep_state);
+}
+EXPORT_SYMBOL_GPL(pinctrl_pm_check_sleep_state);
+
+/**
+ * pinctrl_pm_check_idle_state() - check if idle state is configured
+ * @dev: consumer device
+ *
+ * Call this from consumer driver to check if the idle state
+ * has been properly configured on the device.
+ */
+int pinctrl_pm_check_idle_state(struct device *dev)
+{
+	return pinctrl_pm_check_state(dev, dev->pins->idle_state);
+}
+EXPORT_SYMBOL_GPL(pinctrl_pm_check_idle_state);
 #endif
 
 #ifdef CONFIG_DEBUG_FS
@@ -1483,10 +1664,12 @@ static int pinctrl_show(struct seq_file *s, void *what)
 	mutex_lock(&pinctrl_list_mutex);
 
 	list_for_each_entry(p, &pinctrl_list, node) {
-		seq_printf(s, "device: %s current state: %s\n",
+		seq_printf(s, "device: %s current states: %s %s\n",
 			   dev_name(p->dev),
 			   p->state[PINCTRL_STATIC] ?
-			   p->state[PINCTRL_STATIC]->name : "none");
+			   p->state[PINCTRL_STATIC]->name : "none",
+			   p->state[PINCTRL_DYNAMIC] ?
+			   p->state[PINCTRL_DYNAMIC]->name : "none");
 
 		list_for_each_entry(state, &p->states, node) {
 			seq_printf(s, "  state: %s\n", state->name);
diff --git a/include/linux/pinctrl/consumer.h b/include/linux/pinctrl/consumer.h
index 18eccef..73a82f1 100644
--- a/include/linux/pinctrl/consumer.h
+++ b/include/linux/pinctrl/consumer.h
@@ -36,19 +36,29 @@ extern struct pinctrl_state * __must_check pinctrl_lookup_state(
 							struct pinctrl *p,
 							const char *name);
 extern int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *s);
+extern int pinctrl_check_dynamic(struct device *dev, struct pinctrl_state *s1,
+				 struct pinctrl_state *s2);
+extern int pinctrl_select_dynamic(struct pinctrl *p, struct pinctrl_state *s);
 
 extern struct pinctrl * __must_check devm_pinctrl_get(struct device *dev);
 extern void devm_pinctrl_put(struct pinctrl *p);
 
 #ifdef CONFIG_PM
 extern int pinctrl_pm_select_default_state(struct device *dev);
+extern int pinctrl_pm_select_active_state(struct device *dev);
 extern int pinctrl_pm_select_sleep_state(struct device *dev);
 extern int pinctrl_pm_select_idle_state(struct device *dev);
+extern int pinctrl_pm_check_sleep_state(struct device *dev);
+extern int pinctrl_pm_check_idle_state(struct device *dev);
 #else
 static inline int pinctrl_pm_select_default_state(struct device *dev)
 {
 	return 0;
 }
+static inline int pinctrl_pm_select_active_state(struct device *dev)
+{
+	return 0;
+}
 static inline int pinctrl_pm_select_sleep_state(struct device *dev)
 {
 	return 0;
@@ -57,6 +67,14 @@ static inline int pinctrl_pm_select_idle_state(struct device *dev)
 {
 	return 0;
 }
+static inline int pinctrl_pm_check_sleep_state(struct device *dev)
+{
+	return -ENODEV;
+}
+static inline int pinctrl_pm_check_idle_state(struct device *dev)
+{
+	return -ENODEV;
+}
 #endif
 
 #else /* !CONFIG_PINCTRL */
@@ -102,6 +120,19 @@ static inline int pinctrl_select_state(struct pinctrl *p,
 	return 0;
 }
 
+static inline int pinctrl_check_dynamic(struct device *dev,
+					struct pinctrl_state *s1,
+					struct pinctrl_state *s2)
+{
+	return 0;
+}
+
+static inline int pinctrl_select_dynamic(struct pinctrl *p,
+				       struct pinctrl_state *s)
+{
+	return 0;
+}
+
 static inline struct pinctrl * __must_check devm_pinctrl_get(struct device *dev)
 {
 	return NULL;
@@ -116,6 +147,11 @@ static inline int pinctrl_pm_select_default_state(struct device *dev)
 	return 0;
 }
 
+static inline int pinctrl_pm_select_active_state(struct device *dev)
+{
+	return 0;
+}
+
 static inline int pinctrl_pm_select_sleep_state(struct device *dev)
 {
 	return 0;
@@ -126,6 +162,16 @@ static inline int pinctrl_pm_select_idle_state(struct device *dev)
 	return 0;
 }
 
+static inline int pinctrl_pm_check_sleep_state(struct device *dev)
+{
+	return -ENODEV;
+}
+
+static inline int pinctrl_pm_check_idle_state(struct device *dev)
+{
+	return -ENODEV;
+}
+
 #endif /* CONFIG_PINCTRL */
 
 static inline struct pinctrl * __must_check pinctrl_get_select(
diff --git a/include/linux/pinctrl/devinfo.h b/include/linux/pinctrl/devinfo.h
index 281cb91..2857a7b 100644
--- a/include/linux/pinctrl/devinfo.h
+++ b/include/linux/pinctrl/devinfo.h
@@ -24,10 +24,14 @@
  * struct dev_pin_info - pin state container for devices
  * @p: pinctrl handle for the containing device
  * @default_state: the default state for the handle, if found
+ * @active_state: the default state for the handle, if found
+ * @sleep_state: the default state for the handle, if found
+ * @idle_state: the default state for the handle, if found
  */
 struct dev_pin_info {
 	struct pinctrl *p;
 	struct pinctrl_state *default_state;
+	struct pinctrl_state *active_state;
 #ifdef CONFIG_PM
 	struct pinctrl_state *sleep_state;
 	struct pinctrl_state *idle_state;
diff --git a/include/linux/pinctrl/pinctrl-state.h b/include/linux/pinctrl/pinctrl-state.h
index b5919f8..c136e82 100644
--- a/include/linux/pinctrl/pinctrl-state.h
+++ b/include/linux/pinctrl/pinctrl-state.h
@@ -9,16 +9,27 @@
  *	hogs to configure muxing and pins at boot, and also as a state
  *	to go into when returning from sleep and idle in
  *	.pm_runtime_resume() or ordinary .resume() for example.
+ * @PINCTRL_STATE_ACTIVE: optional state of dynamic pins in addition to
+ *	PINCTRL_STATE_DEFAULT that are needed during runtime.
  * @PINCTRL_STATE_IDLE: the state the pinctrl handle shall be put into
  *	when the pins are idle. This is a state where the system is relaxed
  *	but not fully sleeping - some power may be on but clocks gated for
  *	example. Could typically be set from a pm_runtime_suspend() or
- *	pm_runtime_idle() operation.
+ *	pm_runtime_idle() operation. If PINCTRL_STATE_ACTIVE pins are
+ *	defined, PINCTRL_STATE_IDLE pin groups must cover the same pin
+ *	groups as PINCTRL_STATE_ACTIVE and selecting PINCTRL_STATE_IDLE
+ *	must be done using pinctrl_select_state_dynamic() instead of
+ *	pinctrl_select_state().
  * @PINCTRL_STATE_SLEEP: the state the pinctrl handle shall be put into
  *	when the pins are sleeping. This is a state where the system is in
  *	its lowest sleep state. Could typically be set from an
- *	ordinary .suspend() function.
+ *	ordinary .suspend() function. If PINCTRL_STATE_ACTIVE pins are
+ *	defined, PINCTRL_STATE_SLEEP pin groups must cover the same pin
+ *	groups as PINCTRL_STATE_ACTIVE and selecting PINCTRL_STATE_SLEEP
+ *	must be done using pinctrl_select_state_dynamic() instead of
+ *	pinctrl_select_state().
  */
 #define PINCTRL_STATE_DEFAULT "default"
+#define PINCTRL_STATE_ACTIVE "active"
 #define PINCTRL_STATE_IDLE "idle"
 #define PINCTRL_STATE_SLEEP "sleep"



From tony at atomide.com  Tue Jul 16 05:05:39 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 02:05:39 -0700
Subject: [PATCH 4/4] drivers: Add pinctrl handling for dynamic pin states
In-Reply-To: <20130716090310.5541.36777.stgit@localhost>
References: <20130716090310.5541.36777.stgit@localhost>
Message-ID: <20130716090539.5541.980.stgit@localhost>

We want to have static pin states handled separately from
dynamic pin states, so let's add optional state_active.

Then if state_active is defined, let's check and make sure
state_idle and state_sleep match state_active for the
pin groups to avoid checking them during runtime as the
active and idle pins may need to be toggled for many
devices every time we enter and exit idle.

Cc: Stephen Warren <swarren at wwwdotorg.org>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 drivers/base/pinctrl.c |   39 +++++++++++++++++++++++++++++++++++++--
 1 file changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
index 5fb74b4..49644ed 100644
--- a/drivers/base/pinctrl.c
+++ b/drivers/base/pinctrl.c
@@ -34,6 +34,7 @@ int pinctrl_bind_pins(struct device *dev)
 		goto cleanup_alloc;
 	}
 
+	/* Default static pins that don't need to change */
 	dev->pins->default_state = pinctrl_lookup_state(dev->pins->p,
 					PINCTRL_STATE_DEFAULT);
 	if (IS_ERR(dev->pins->default_state)) {
@@ -48,23 +49,57 @@ int pinctrl_bind_pins(struct device *dev)
 		goto cleanup_get;
 	}
 
+	/* Optional runtime dynamic pins in addition to the static pins */
+	dev->pins->active_state = pinctrl_lookup_state(dev->pins->p,
+					PINCTRL_STATE_ACTIVE);
+	if (IS_ERR(dev->pins->active_state)) {
+		/* Not supplying this state is perfectly legal */
+		dev_dbg(dev, "no active pinctrl state\n");
+	} else {
+		ret = pinctrl_select_dynamic(dev->pins->p,
+				dev->pins->active_state);
+		if (ret) {
+			dev_dbg(dev, "failed to select active pinctrl state\n");
+			goto cleanup_get;
+		}
+	}
+
 #ifdef CONFIG_PM
 	/*
 	 * If power management is enabled, we also look for the optional
 	 * sleep and idle pin states, with semantics as defined in
 	 * <linux/pinctrl/pinctrl-state.h>
+	 *
+	 * Note that if active state is defined, sleep and idle states must
+	 * cover the same pin groups as active state.
 	 */
 	dev->pins->sleep_state = pinctrl_lookup_state(dev->pins->p,
 					PINCTRL_STATE_SLEEP);
-	if (IS_ERR(dev->pins->sleep_state))
+	if (IS_ERR(dev->pins->sleep_state)) {
 		/* Not supplying this state is perfectly legal */
 		dev_dbg(dev, "no sleep pinctrl state\n");
+	} else if (!IS_ERR(dev->pins->active_state)) {
+		ret = pinctrl_check_dynamic(dev, dev->pins->active_state,
+					    dev->pins->sleep_state);
+		if (ret) {
+			dev_err(dev, "sleep state groups do not match active state\n");
+			dev->pins->sleep_state = ERR_PTR(-EINVAL);
+		}
+	}
 
 	dev->pins->idle_state = pinctrl_lookup_state(dev->pins->p,
 					PINCTRL_STATE_IDLE);
-	if (IS_ERR(dev->pins->idle_state))
+	if (IS_ERR(dev->pins->idle_state)) {
 		/* Not supplying this state is perfectly legal */
 		dev_dbg(dev, "no idle pinctrl state\n");
+	} else if (!IS_ERR(dev->pins->active_state)) {
+		ret = pinctrl_check_dynamic(dev, dev->pins->active_state,
+					    dev->pins->idle_state);
+		if (ret) {
+			dev_err(dev, "idle state groups do not match active state\n");
+			dev->pins->idle_state = ERR_PTR(-EINVAL);
+		}
+	}
 #endif
 
 	return 0;



From bp at alien8.de  Tue Jul 16 05:05:46 2013
From: bp at alien8.de (Borislav Petkov)
Date: Tue, 16 Jul 2013 11:05:46 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130716012756.31936d8d.akpm@linux-foundation.org>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716004727.b60b2c96.akpm@linux-foundation.org>
 <20130716005611.e4ccab02.akpm@linux-foundation.org>
 <201307161008.07643.yann.morin.1998@free.fr>
 <20130716012756.31936d8d.akpm@linux-foundation.org>
Message-ID: <20130716090546.GB4402@pd.tnic>

On Tue, Jul 16, 2013 at 01:27:56AM -0700, Andrew Morton wrote:
> What I'm angling at is, rather than a single global front-end script,
> can we embed the scripts in some fashion within the various Kconfig
> files?  Say,
> 
> 	script ./some-script.sh
> 
> and the config system will only evaluate that command if it is working
> on that Kconfig file.  Obviously that requires a multiple-pass thing.

What's wrong with simply grepping the .config we've just created for
*enabled* symbols which require userspace support, check for the
presence of said support and bail out if none?

I.e., those steps:

1. make <whatever>config
2. make => A prereq. target runs the shell script.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--


From sachin.kamat at linaro.org  Tue Jul 16 05:08:05 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Tue, 16 Jul 2013 14:38:05 +0530
Subject: [PATCH 1/6] clk: exynos4: Staticize local symbols
In-Reply-To: <02d801ce81f6$e480fe80$ad82fb80$%kim@samsung.com>
References: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
 <1373533334-5169-2-git-send-email-sachin.kamat@linaro.org>
 <02d801ce81f6$e480fe80$ad82fb80$%kim@samsung.com>
Message-ID: <CAK9yfHziYb8AyD+FK9_aDpcM1Pxmg2nr30NvvTHZ62JiYKq9kg@mail.gmail.com>

On 16 July 2013 13:04, Kukjin Kim <kgene.kim at samsung.com> wrote:
> Sachin Kamat wrote:
>>
>> Symbols referenced only in this file are made static.
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
>> ---
>>  drivers/clk/samsung/clk-exynos4.c |   30 ++++++++++++++++--------------
>>  1 file changed, 16 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-
>> exynos4.c
>> index 1bdb882..18eadc4 100644
>> --- a/drivers/clk/samsung/clk-exynos4.c
>> +++ b/drivers/clk/samsung/clk-exynos4.c
>
> [...]
>
>> @@ -975,7 +975,7 @@ static void __init
>> exynos4_clk_register_finpll(unsigned long xom)
>>   * clock speed.
>>   */
>>  void __init exynos4_clk_register_fixed_ext(unsigned long xxti_f,
>> -                                             unsigned long xusbxti_f)
>> +                                               unsigned long xusbxti_f)
>
> Why?

Yes this is unrelated and should not have been there.

>
>>  {
>>       exynos4_fixed_rate_ext_clks[0].fixed_rate = xxti_f;
>>       exynos4_fixed_rate_ext_clks[1].fixed_rate = xusbxti_f;
>> @@ -990,7 +990,9 @@ static __initdata struct of_device_id ext_clk_match[]
>> = {
>>  };
>>
>>  /* register exynos4 clocks */
>> -void __init exynos4_clk_init(struct device_node *np, enum exynos4_soc
>> exynos4_soc, void __iomem *reg_base, unsigned long xom)
>> +static void __init exynos4_clk_init(struct device_node *np,
>> +                                 enum exynos4_soc exynos4_soc,
>> +                                 void __iomem *reg_base, unsigned long
> xom)
>>  {
>>       struct clk *apll, *mpll, *epll, *vpll;
>>
>> --
>> 1.7.9.5
>
> And don't we need following?

This has been done (along with other cleanups) in the following patch:
http://www.spinics.net/lists/linux-samsung-soc/msg20284.html

>
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index 3e156bc..3a34f1e 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -26,7 +26,6 @@ void exynos5_restart(enum reboot_mode mode, const char
> *cmd);
>  void exynos_init_late(void);
>
>  /* ToDo: remove these after migrating legacy exynos4 platforms to dt */
> -void exynos4_clk_init(struct device_node *np, int is_exynos4210, void
> __iomem *reg_base, unsigned long xom);
>  void exynos4_clk_register_fixed_ext(unsigned long, unsigned long);
>
>  void exynos_firmware_init(void);
>
> - Kukjin
>



-- 
With warm regards,
Sachin


From sachin.kamat at linaro.org  Tue Jul 16 05:08:45 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Tue, 16 Jul 2013 14:38:45 +0530
Subject: [PATCH 2/6] clk: exynos4: Remove unused function
In-Reply-To: <02d701ce81f6$532ab9d0$f9802d70$%kim@samsung.com>
References: <1373533334-5169-1-git-send-email-sachin.kamat@linaro.org>
 <1373533334-5169-3-git-send-email-sachin.kamat@linaro.org>
 <02d701ce81f6$532ab9d0$f9802d70$%kim@samsung.com>
Message-ID: <CAK9yfHy6Lp=1C8CgviXp9s-F963UQcGpPUQFpJSu+qEW9_90Ug@mail.gmail.com>

On 16 July 2013 13:00, Kukjin Kim <kgene.kim at samsung.com> wrote:
> Sachin Kamat wrote:
>>
>> Subsequent to the cleanup in commit 3c70348c7c ("ARM: EXYNOS:
>> Remove legacy timer initialization code"), this function has no more
>> users. Hence remove it.
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
>> ---
>>  drivers/clk/samsung/clk-exynos4.c |   14 --------------
>>  1 file changed, 14 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-
>> exynos4.c
>> index 18eadc4..75635eb 100644
>> --- a/drivers/clk/samsung/clk-exynos4.c
>> +++ b/drivers/clk/samsung/clk-exynos4.c
>> @@ -969,20 +969,6 @@ static void __init
>> exynos4_clk_register_finpll(unsigned long xom)
>>
>>  }
>>
>> -/*
>> - * This function allows non-dt platforms to specify the clock speed of
>> the
>> - * xxti and xusbxti clocks. These clocks are then registered with the
>> specified
>> - * clock speed.
>> - */
>> -void __init exynos4_clk_register_fixed_ext(unsigned long xxti_f,
>> -                                               unsigned long xusbxti_f)
>> -{
>> -     exynos4_fixed_rate_ext_clks[0].fixed_rate = xxti_f;
>> -     exynos4_fixed_rate_ext_clks[1].fixed_rate = xusbxti_f;
>> -     samsung_clk_register_fixed_rate(exynos4_fixed_rate_ext_clks,
>> -                     ARRAY_SIZE(exynos4_fixed_rate_ext_clks));
>> -}
>> -
>>  static __initdata struct of_device_id ext_clk_match[] = {
>>       { .compatible = "samsung,clock-xxti", .data = (void *)0, },
>>       { .compatible = "samsung,clock-xusbxti", .data = (void *)1, },
>> --
>> 1.7.9.5
>
> And need following?

This has been done (along with other cleanups) in the following patch:
http://www.spinics.net/lists/linux-samsung-soc/msg20284.html

>
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index 3e156bc..1037da0 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -27,7 +27,6 @@ void exynos_init_late(void);
>
>  /* ToDo: remove these after migrating legacy exynos4 platforms to dt */
>  void exynos4_clk_init(struct device_node *np, int is_exynos4210, void
> __iomem *reg_base, unsigned long xom);
> -void exynos4_clk_register_fixed_ext(unsigned long, unsigned long);
>
>  void exynos_firmware_init(void);
>
> - Kukjin
>



-- 
With warm regards,
Sachin


From josh.wu at atmel.com  Tue Jul 16 05:09:32 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Tue, 16 Jul 2013 17:09:32 +0800
Subject: [PATCH 5/5] iio: at91: introduce touch screen support in iio
 adc driver
In-Reply-To: <20130715131507.GE2962@lukather>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-6-git-send-email-josh.wu@atmel.com>
 <20130715131507.GE2962@lukather>
Message-ID: <51E50DCC.4010107@atmel.com>

Hi, Maxime

On 7/15/2013 9:15 PM, Maxime Ripard wrote:
> Hi Josh,
>
> On Sun, Jul 14, 2013 at 04:04:29PM +0800, Josh Wu wrote:
>> AT91 ADC hardware integrate touch screen support. So this patch add touch
>> screen support for at91 adc iio driver.
>> To enable touch screen support in adc, you need to add the dt parameters:
>>    which type of touch are used? (4 or 5 wires), sample period time,
>>    pen detect debounce time, average samples and pen detect resistor.
>>
>> In the meantime, since touch screen will use a interal period trigger of adc,
>> so it is conflict to other hardware triggers. Driver will disable the hardware
>> trigger support if touch screen is enabled.
>>
>> This driver has been tested in AT91SAM9X5-EK and SAMA5D3x-EK.
>>
>> Signed-off-by: Josh Wu <josh.wu at atmel.com>
>> Cc: Dmitry Torokhov <dmitry.torokhov at gmail.com>
>> ---
>>   .../devicetree/bindings/arm/atmel-adc.txt          |   13 +
>>   arch/arm/mach-at91/include/mach/at91_adc.h         |   34 ++
>>   drivers/iio/adc/at91_adc.c                         |  389 ++++++++++++++++++--
>>   3 files changed, 412 insertions(+), 24 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> index 0db2945..925d656 100644
>> --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> @@ -29,6 +29,19 @@ Optional properties:
>>     - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
>>     - atmel,adc-clock-rate: ADC clock rate. If not specified, use the default
>>   			  adc_op_clk.
>> +  - atmel,adc-touchscreen-wires: Number of touch screen wires. Only support
>> +				 4 and 5 wires touch screen.
>> +    NOTE: when adc touch screen enabled, the adc hardware trigger will be
>> +          disabled. Since touch screen will occupied the trigger register.
>> +  - atmel,adc-ts-pendet-debounce: Debounce time in microsecond for touch pen
>> +				  detect.
>> +  - atmel,adc-ts-sample-period-time: Sample Period Time in microsecond for
>> +				     touch screen
>> +  - atmel,adc-ts-filter-average: Numbers of sampling data will be averaged.
>> +    0 means no average. 1 means average two samples. 2 means average four
>> +    samples. 3 means average eight samples.
>> +  - atmel,adc-ts-pendet-sensitivity: Pen Detection input pull-up resistor.
>> +    It can be 0, 1, 2, 3.
> Could you expand a bit on what are these properties for? Are they
> board-specific? IP-specific?

+  - atmel,adc-touchscreen-wires: Number of touch screen wires. Only support
+                 4 and 5 wires touch screen.
+    NOTE: when adc touch screen enabled, the adc hardware trigger will be
+          disabled. Since touch screen will occupied the trigger register.

It is board specific. Currently in AT91SAM9M10G45EK, AT91SAM9X5-EK, 
SAMA5D3x-EK all use 4 wire touch.
Now the driver not support 5 wire yet.

+  - atmel,adc-ts-pendet-debounce: Debounce time in microsecond for 
touch pen
+                  detect.

de-glitch time for pen detect. Board specific.

+  - atmel,adc-ts-sample-period-time: Sample Period Time in microsecond for
+                     touch screen

The period to sample a touch data after pen is touched. Board specific.

+  - atmel,adc-ts-filter-average: Numbers of sampling data will be averaged.
+    0 means no average. 1 means average two samples. 2 means average four
+    samples. 3 means average eight samples.
+  - atmel,adc-ts-pendet-sensitivity: Pen Detection input pull-up resistor.
+    It can be 0, 1, 2, 3.

Above two properties only supported in SAM9X5, SAMA5D3 IP.

>
> [...]
>
>> +#define DRIVER_NAME		"at91_adc"
> This looks like this part doesn't belong to another cleanup patch.

it is part of this patch. As it's a little cleanup, I integrate it as 
add touch feature.

>
>> +#define MAX_POS_BITS		12
>> +
>> +#define ZTHRESHOLD		9000
>> +
>>   struct at91_adc_caps {
>> +	bool	has_12bits_xy;	/* true means use 12 bits. Otherwise 10 bits */
> Isn't that redundant with the low_res boolean?

yes, right. I will remove it.

>
>>   	bool	has_tsmr;	/* only at91sam9x5, sama5d3 have TSMR reg */
>>   	u32	mr_prescal_mask;
>>   	u32	mr_startup_mask;
>>   };
>>   
>> +enum atmel_adc_ts_type {
>> +	ATMEL_ADC_TOUCHSCREEN_NONE = 0,
>> +	ATMEL_ADC_TOUCHSCREEN_4WIRE,
>> +	ATMEL_ADC_TOUCHSCREEN_5WIRE,
>> +};
>> +
>>   struct at91_adc_state {
>>   	struct clk		*adc_clk;
>>   	u32			adc_clk_rate;
>> @@ -70,6 +83,29 @@ struct at91_adc_state {
>>   	bool			low_res;	/* the resolution corresponds to the lowest one */
>>   	wait_queue_head_t	wq_data_avail;
>>   	struct at91_adc_caps	caps;
>> +
>> +	/*
>> +	 * Following ADC channels are shared by touchscreen:
>> +	 *
>> +	 * CH0 -- Touch screen XP/UL
>> +	 * CH1 -- Touch screen XM/UR
>> +	 * CH2 -- Touch screen YP/LL
>> +	 * CH3 -- Touch screen YM/Sense
>> +	 * CH4 -- Touch screen LR(5-wire only)
>> +	 *
>> +	 * The bitfields below represents the reserved channel in the
>> +	 * touchscreen mode.
>> +	 */
>> +#define CHAN_MASK_TOUCHSCREEN_4WIRE	(0xf << 0)
>> +#define CHAN_MASK_TOUCHSCREEN_5WIRE	(0x1f << 0)
>> +	enum atmel_adc_ts_type	touchscreen_type;
>> +	struct input_dev		*ts_input;
>> +
>> +	u8			ts_filter_average;
>> +	u16			ts_pen_detect_debounce;
>> +	u8			ts_pen_detect_sensitivity;
>> +	u16			ts_sample_period_time;
>> +	u16			ts_sample_period_val;
>>   };
>>   
>>   static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
>> @@ -104,14 +140,10 @@ static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
>>   	return IRQ_HANDLED;
>>   }
>>   
>> -static irqreturn_t at91_adc_eoc_trigger(int irq, void *private)
>> +/* Handler for classic adc channel eoc trigger */
>> +void handle_adc_eoc_trigger(int irq, struct iio_dev *idev)
>>   {
>> -	struct iio_dev *idev = private;
>>   	struct at91_adc_state *st = iio_priv(idev);
>> -	u32 status = at91_adc_readl(st, st->registers->status_register);
>> -
>> -	if (!(status & st->registers->drdy_mask))
>> -		return IRQ_HANDLED;
> Why are you changing the prototype and remove most of the useful part
> out of the handler?

I change the protype because I make it as a sub interrupt handler.
Since I just add a new interrupt handler which will check the interrupt 
type, if DRDY interrupt is coming, it will call your original handler.
Otherwise use touch screen interrupt handler code.

Following is the new interrupt handler code in this patch:

+static irqreturn_t at91_adc_interrupt(int irq, void *private)
+{
+	struct iio_dev *idev = private;
+	struct at91_adc_state *st = iio_priv(idev);
+	u32 status = at91_adc_readl(st, st->registers->status_register);
+	const uint32_t ts_data_irq_mask =
+		AT91_ADC_IER_XRDY |
+		AT91_ADC_IER_YRDY |
+		AT91_ADC_IER_PRDY;
+
+	if (status & st->registers->drdy_mask)
+		handle_adc_eoc_trigger(irq, idev);

                              ^
                              |
here we call original trigger handler.

+
+	if (status & AT91_ADC_IER_PEN) {
+		at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_PEN);
+		at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_NOPEN |
+			ts_data_irq_mask);
+		/* Set up period trigger for sampling */
+		at91_adc_writel(st, st->registers->trigger_register,
+			AT91_ADC_TRGR_MOD_PERIOD_TRIG |
+			AT91_ADC_TRGR_TRGPER_(st->ts_sample_period_val));
+	} else if (status & AT91_ADC_IER_NOPEN) {
+		at91_adc_writel(st, st->registers->trigger_register, 0);
+		at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_NOPEN |
+			ts_data_irq_mask);
+		at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_PEN);
+
+		input_report_key(st->ts_input, BTN_TOUCH, 0);
+		input_sync(st->ts_input);
+	} else if ((status & ts_data_irq_mask) == ts_data_irq_mask) {

Those code will handle for the Touch screen interrupt.

>
> Maxime
>

Thanks.
Best Regards,
Josh Wu


From yann.morin.1998 at free.fr  Tue Jul 16 05:12:17 2013
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Tue, 16 Jul 2013 11:12:17 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130716090546.GB4402@pd.tnic>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716012756.31936d8d.akpm@linux-foundation.org>
 <20130716090546.GB4402@pd.tnic>
Message-ID: <201307161112.17901.yann.morin.1998@free.fr>

Borislav, All,

On Tuesday 16 July 2013 11:05:46 Borislav Petkov wrote:
> On Tue, Jul 16, 2013 at 01:27:56AM -0700, Andrew Morton wrote:
> > What I'm angling at is, rather than a single global front-end script,
> > can we embed the scripts in some fashion within the various Kconfig
> > files?  Say,
> > 
> > 	script ./some-script.sh
> > 
> > and the config system will only evaluate that command if it is working
> > on that Kconfig file.  Obviously that requires a multiple-pass thing.
> 
> What's wrong with simply grepping the .config we've just created for
> *enabled* symbols which require userspace support, check for the
> presence of said support and bail out if none?

The goal is to avoid generating a non-buildable kernel in the first place.
This is very usefull for automatic check harness that run randconfig, for
example (but may have more use-cases).

> I.e., those steps:
> 1. make <whatever>config
> 2. make => A prereq. target runs the shell script.

This is too late, since this will bail out, and will give a false-positive
failure.

While if we were to check for _known_ needed tools before calling into
Kconfig, we can simply hide non-available config options, and even inform
the user *why* the option is not available.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'


From florian at openwrt.org  Tue Jul 16 05:13:24 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Tue, 16 Jul 2013 10:13:24 +0100
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130716005611.e4ccab02.akpm@linux-foundation.org>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <1367829775-4434-2-git-send-email-kyungsik.lee@lge.com>
 <20130712075602.GA4002@gmail.com>
 <20130715150342.35f7620ffe0835e3e2bc37d0@linux-foundation.org>
 <51E472D4.5060307@zytor.com>
 <20130716004727.b60b2c96.akpm@linux-foundation.org>
 <20130716005611.e4ccab02.akpm@linux-foundation.org>
Message-ID: <CAGVrzcaTMckMKUObknT8abPyOzetuHzWtNPkF=Ae4zz7huShkQ@mail.gmail.com>

2013/7/16 Andrew Morton <akpm at linux-foundation.org>:
> On Tue, 16 Jul 2013 00:47:27 -0700 Andrew Morton <akpm at linux-foundation.org> wrote:
>
>> On Mon, 15 Jul 2013 15:08:20 -0700 "H. Peter Anvin" <hpa at zytor.com> wrote:
>>
>> > On 07/15/2013 03:03 PM, Andrew Morton wrote:
>> > >
>> > > I don't know how to do this.  Any suggestions?
>> > >
>> > > It has to be done at `make config' time.  We'd need to probe for the
>> > > presence of lz4c and then....  what?
>> > >
>> > > Is there any precedent for this?
>> > >
>> > > I don't think we can just ignore the absence of lz4c - the user has
>> > > selected a config which his system cannot build.  The problem lies
>> > > within randconfig itself.
>> > >
>> >
>> > We keep running over the need to be able to have kconfig run tests on
>> > the build system (for toolchain support or for optional tools needed);
>> > running them in the Makefiles (i.e. at Kbuild time) is simply too late.
>> >
>>
>> Would it make sense to extend Kconfig's `depends'?
>>
>>       depends on $(shell-command)
>>
>> I don't know how practical that would be to implement...
>
> Or, easier and faster, run some front-end script which generates
> once-off Kconfig symbols.
>
>         if [ -x /bin/lz4c ]
>         then
>                 echo CONFIG_HAVE_LZ4C
>         fi
>
> then munge the output of that script into the Kconfig run and do
>
>         depends on HAVE_LZ4C

That does sound nice to avoid the build error, but will eventually
make it harder to diagnose why the kernel has not been compressed with
the specific compression tool, some kind of warning should also be
emitted maybe?
--
Florian


From tony at atomide.com  Tue Jul 16 05:14:14 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 02:14:14 -0700
Subject: [PATCH 0/4] improved support for runtime muxing for pinctrl
In-Reply-To: <20130716090310.5541.36777.stgit@localhost>
References: <20130716090310.5541.36777.stgit@localhost>
Message-ID: <20130716091413.GT7656@atomide.com>

* Tony Lindgren <tony at atomide.com> [130716 02:12]:
> 
> As discussed earlier, the pinctrl support for changing some of the
> consumer device pins during runtime needs some improvment.
> 
> Here are the patches to do that, I'll also post a minimal sample
> patch as a reply to this thread on how to do the muxing for
> runtime PM.

Here's a patch showing the suggested usage remuxing SDIO IRQ
to GPIO mode for runtime PM. Note that this patch depends on
three other patches for the hsmmc driver, I'll post that series
separately.

Regards,

Tony


From: Tony Lindgren <tony at atomide.com>
Date: Mon, 15 Jul 2013 07:39:39 -0700
Subject: [PATCH] mmc: omap_hsmmc: Remux pins to support SDIO interrupt and PM runtime

On some omaps we need to remux MMC pins for PM, and for some omaps
we need to remux the SDIO IRQ pin.

Based on an earlier patch by Andreas Fenkart <afenkart at gmail.com>.

Cc: Andreas Fenkart <afenkart at gmail.com>
Cc: Balaji T K <balajitk at ti.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Tony Lindgren <tony at atomide.com>

--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1869,7 +1869,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
 	const struct of_device_id *match;
 	dma_cap_mask_t mask;
 	unsigned tx_req, rx_req;
-	struct pinctrl *pinctrl;
 
 	match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev);
 	if (match) {
@@ -2114,21 +2113,19 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
 
 	omap_hsmmc_disable_irq(host);
 
-	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
-	if (IS_ERR(pinctrl))
-		dev_warn(&pdev->dev,
-			"pins are not configured from the driver\n");
-
 	/*
-	 * For now, only support SDIO interrupt if we are doing
-	 * muxing of dat1 when booted with DT. This is because the
+	 * For now, only support SDIO interrupt if we are doing dynamic
+	 * remuxing of dat1 when booted with DT. This is because the
 	 * supposedly the wake-up events for CTPL don't work from deeper
 	 * idle states. And we don't want to add new legacy mux platform
 	 * init code callbacks any longer as we are moving to DT based
 	 * booting anyways.
 	 */
 	if (match) {
-		if (!IS_ERR(pinctrl) && mmc_slot(host).sdio_irq)
+		struct device *dev = &pdev->dev;
+
+		if (!pinctrl_pm_check_idle_state(dev) &&
+		    mmc_slot(host).sdio_irq)
 			mmc->caps |= MMC_CAP_SDIO_IRQ;
 	}
 
@@ -2348,6 +2345,10 @@ static int omap_hsmmc_runtime_suspend(struct device *dev)
 		OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
 		spin_unlock_irqrestore(&host->irq_lock, flags);
 
+		ret = pinctrl_pm_select_idle_state(dev);
+		if (ret < 0)
+			dev_err(dev, "Unable to select idle pinmux\n");
+
 		if (mmc_slot(host).sdio_irq)
 			enable_irq(mmc_slot(host).sdio_irq);
 	}
@@ -2371,6 +2372,10 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
 		if (mmc_slot(host).sdio_irq)
 			disable_irq(mmc_slot(host).sdio_irq);
 
+		ret = pinctrl_pm_select_active_state(dev);
+		if (ret < 0)
+			dev_err(dev, "Unable to select active pinmux\n");
+
 		spin_lock_irqsave(&host->irq_lock, flags);
 		host->active_pinmux = true;
 


From mark.rutland at arm.com  Tue Jul 16 05:14:17 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 16 Jul 2013 10:14:17 +0100
Subject: [PATCH V2] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene
 host
In-Reply-To: <1373957734-21482-1-git-send-email-anup.patel@linaro.org>
References: <1373957734-21482-1-git-send-email-anup.patel@linaro.org>
Message-ID: <20130716091417.GC14486@e106331-lin.cambridge.arm.com>

On Tue, Jul 16, 2013 at 07:55:34AM +0100, Anup Patel wrote:
> This patch allows us to have X-Gene guest VCPU when using KVM arm64
> on APM X-Gene host.
> 
> We add KVM_ARM_TARGET_XGENE_POTENZA for X-Gene Potenza compatible
> guest VCPU and we return KVM_ARM_TARGET_XGENE_POTENZA in kvm_target_cpu()
> when running on X-Gene host with Potenza core.
> 
> V2:
>  - Renamed KVM_ARM_TARGET_XGENE_V8 to KVM_ARM_TARGET_XGENE_POTENZA
> 
> V1:
>  - Initial patch with target named as KVM_ARM_TARGET_XGENE_V8
> 
> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> ---
>  arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
>  arch/arm64/kvm/guest.c               |   34 ++++++++++++++++++++++------------
>  arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
>  3 files changed, 27 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 5031f42..d9f026b 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -55,8 +55,9 @@ struct kvm_regs {
>  #define KVM_ARM_TARGET_AEM_V8		0
>  #define KVM_ARM_TARGET_FOUNDATION_V8	1
>  #define KVM_ARM_TARGET_CORTEX_A57	2
> +#define KVM_ARM_TARGET_XGENE_POTENZA	3
>  
> -#define KVM_ARM_NUM_TARGETS		3
> +#define KVM_ARM_NUM_TARGETS		4
>  
>  /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
>  #define KVM_ARM_DEVICE_TYPE_SHIFT	0
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 2c3ff67..a466244 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -207,19 +207,29 @@ int __attribute_const__ kvm_target_cpu(void)
>  	unsigned long implementor = read_cpuid_implementor();
>  	unsigned long part_number = read_cpuid_part_number();
>  
> -	if (implementor != ARM_CPU_IMP_ARM)
> -		return -EINVAL;
> -
> -	switch (part_number) {
> -	case ARM_CPU_PART_AEM_V8:
> -		return KVM_ARM_TARGET_AEM_V8;
> -	case ARM_CPU_PART_FOUNDATION:
> -		return KVM_ARM_TARGET_FOUNDATION_V8;
> -	case ARM_CPU_PART_CORTEX_A57:
> -		/* Currently handled by the generic backend */
> -		return KVM_ARM_TARGET_CORTEX_A57;
> +	switch (implementor) {
> +	case ARM_CPU_IMP_ARM:
> +		switch (part_number) {
> +		case ARM_CPU_PART_AEM_V8:
> +			return KVM_ARM_TARGET_AEM_V8;
> +		case ARM_CPU_PART_FOUNDATION:
> +			return KVM_ARM_TARGET_FOUNDATION_V8;
> +		case ARM_CPU_PART_CORTEX_A57:
> +			return KVM_ARM_TARGET_CORTEX_A57;
> +		default:
> +			return -EINVAL;
> +		}
> +		break;
> +	case ARM_CPU_IMP_APM:
> +		switch (part_number) {
> +		case APM_CPU_PART_POTENZA:
> +			return KVM_ARM_TARGET_XGENE_POTENZA;
> +		default:
> +			return -EINVAL;
> +		}
> +		break;
>  	default:
> -		return -EINVAL;
> + 		return -EINVAL;
>  	}

Why not place a return -EINVAL here, outside of the outer switch
statement? That way you don't need to duplicate it for an unknown
implementor or a known implementor's unknown CPU, as long as you keep
the break at the end of each implementor's case.

Thanks,
Mark.

>  }
>  
> diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
> index 4268ab9..8fe6f76 100644
> --- a/arch/arm64/kvm/sys_regs_generic_v8.c
> +++ b/arch/arm64/kvm/sys_regs_generic_v8.c
> @@ -90,6 +90,9 @@ static int __init sys_reg_genericv8_init(void)
>  					  &genericv8_target_table);
>  	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_CORTEX_A57,
>  					  &genericv8_target_table);
> +	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_XGENE_POTENZA,
> +					  &genericv8_target_table);
> +
>  	return 0;
>  }
>  late_initcall(sys_reg_genericv8_init);
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From tony at atomide.com  Tue Jul 16 05:18:16 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 02:18:16 -0700
Subject: [GIT PULL] pinctrl-single SoC specific support for v3.12
Message-ID: <20130716091816.GU7656@atomide.com>

Hi Linus,

Here's a pull request for the pinctrl-single changes posted
few weeks ago. Assuming this pull request and the patches
are OK, I'd like to also merge this branch into omap tree so
we can have the wake-up events working. So we'd have to
establish keeping these commits immutable.

Note that this series does not depend on the dynamic remuxing
patches I just posted. These patches can be used without the
dynamic remuxing support for devices that have dedicated
wake-up path and don't need remuxing, such as UART on most
omaps.

Regards,

Tony


The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/pinctrl-single-for-linus

for you to fetch changes up to 8f406c0772ace721f0350c92acd043732285ba9f:

  pinctrl: single: omap: Add SoC specific module for wake-up events (2013-07-15 00:17:07 -0700)

----------------------------------------------------------------
Pinctrl single changes to add support for SoC specific features
that were too late for v3.11. This branch is needed as a dependency
also for the omap tree for off-idle and USB wake-up events, so
posting it as a pull request.

----------------------------------------------------------------
Tony Lindgren (3):
      pinctrl: single: Prepare for supporting SoC specific features
      pinctrl: single: Add hardware specific hooks for IRQ and GPIO wake-up events
      pinctrl: single: omap: Add SoC specific module for wake-up events

 .../devicetree/bindings/pinctrl/pinctrl-single.txt |   5 +
 drivers/pinctrl/Makefile                           |   3 +-
 drivers/pinctrl/pinctrl-single-omap.c              | 287 +++++++++++++++++++++
 drivers/pinctrl/pinctrl-single.c                   | 158 +++++++++---
 drivers/pinctrl/pinctrl-single.h                   |  43 +++
 include/linux/platform_data/pinctrl-single-omap.h  |   4 +
 6 files changed, 468 insertions(+), 32 deletions(-)
 create mode 100644 drivers/pinctrl/pinctrl-single-omap.c
 create mode 100644 drivers/pinctrl/pinctrl-single.h
 create mode 100644 include/linux/platform_data/pinctrl-single-omap.h


From r65037 at freescale.com  Tue Jul 16 05:18:25 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Tue, 16 Jul 2013 09:18:25 +0000
Subject: [v7 2/3] ARM: imx6q: update the sata bits definitions of gpr13
In-Reply-To: <20130716080521.GI28375@S2101-09.ap.freescale.net>
References: <1373945328-20893-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373945328-20893-3-git-send-email-Hong-Xing.Zhu@freescale.com>
 <20130716033951.GG28375@S2101-09.ap.freescale.net>
 <0E83723C55F66F43A6041464FE31119D33D959@039-SN2MPN1-011.039d.mgd.msft.net>
 <20130716080521.GI28375@S2101-09.ap.freescale.net>
Message-ID: <0E83723C55F66F43A6041464FE31119D33DA0D@039-SN2MPN1-011.039d.mgd.msft.net>

Thanks.
Yes, it is. Both #2 and #3 should be merged together.

Best Regards
Richard Zhu


-----Original Message-----
From: Shawn Guo [mailto:shawn.guo at linaro.org] 
Sent: Tuesday, July 16, 2013 4:05 PM
To: Zhu Richard-R65037
Cc: tj at kernel.org; linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; rob.herring at calxeda.com; s.hauer at pengutronix.de; linux-ide at vger.kernel.org
Subject: Re: [v7 2/3] ARM: imx6q: update the sata bits definitions of gpr13

On Tue, Jul 16, 2013 at 07:56:52AM +0000, Zhu Richard-R65037 wrote:
> Hi Shawn:
> Thanks.
> 
> Hi Tejun:
> Can you help to pick up the #3 of this patch-set?

#2 and #3, I think.

Shawn



From bp at alien8.de  Tue Jul 16 05:22:42 2013
From: bp at alien8.de (Borislav Petkov)
Date: Tue, 16 Jul 2013 11:22:42 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <201307161112.17901.yann.morin.1998@free.fr>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716012756.31936d8d.akpm@linux-foundation.org>
 <20130716090546.GB4402@pd.tnic>
 <201307161112.17901.yann.morin.1998@free.fr>
Message-ID: <20130716092242.GD4402@pd.tnic>

On Tue, Jul 16, 2013 at 11:12:17AM +0200, Yann E. MORIN wrote:
> The goal is to avoid generating a non-buildable kernel in the first place.

I know, that's why I'm proposing to fail the build with the script run
as one of the first things by make.

> > I.e., those steps:
> > 1. make <whatever>config
> > 2. make => A prereq. target runs the shell script.
> 
> This is too late, since this will bail out, and will give a false-positive
> failure.

Huh? This will tell you: "you've selected X, but I don't have toolX
needed for the build".

You install the tool and run make again. Checks pass, the build
continues.

> While if we were to check for _known_ needed tools before calling into
> Kconfig,

How would you do that? How do you know what the user is going to select
*before* she even selects it?

You need to have a prepared .config to act upon.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--


From yann.morin.1998 at free.fr  Tue Jul 16 05:25:14 2013
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Tue, 16 Jul 2013 11:25:14 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <CAGVrzcaTMckMKUObknT8abPyOzetuHzWtNPkF=Ae4zz7huShkQ@mail.gmail.com>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716005611.e4ccab02.akpm@linux-foundation.org>
 <CAGVrzcaTMckMKUObknT8abPyOzetuHzWtNPkF=Ae4zz7huShkQ@mail.gmail.com>
Message-ID: <201307161125.14491.yann.morin.1998@free.fr>

Florian, All,

On Tuesday 16 July 2013 11:13:24 Florian Fainelli wrote:
> 2013/7/16 Andrew Morton <akpm at linux-foundation.org>:
> > On Tue, 16 Jul 2013 00:47:27 -0700 Andrew Morton <akpm at linux-foundation.org> wrote:
> >
> >> On Mon, 15 Jul 2013 15:08:20 -0700 "H. Peter Anvin" <hpa at zytor.com> wrote:
> >>
> >> > On 07/15/2013 03:03 PM, Andrew Morton wrote:
> >> > >
> >> > > I don't know how to do this.  Any suggestions?
> >> > >
> >> > > It has to be done at `make config' time.  We'd need to probe for the
> >> > > presence of lz4c and then....  what?
> >> > >
> >> > > Is there any precedent for this?
> >> > >
> >> > > I don't think we can just ignore the absence of lz4c - the user has
> >> > > selected a config which his system cannot build.  The problem lies
> >> > > within randconfig itself.
> >> > >
> >> >
> >> > We keep running over the need to be able to have kconfig run tests on
> >> > the build system (for toolchain support or for optional tools needed);
> >> > running them in the Makefiles (i.e. at Kbuild time) is simply too late.
> >> >
> >>
> >> Would it make sense to extend Kconfig's `depends'?
> >>
> >>       depends on $(shell-command)
> >>
> >> I don't know how practical that would be to implement...
> >
> > Or, easier and faster, run some front-end script which generates
> > once-off Kconfig symbols.
> >
> >         if [ -x /bin/lz4c ]
> >         then
> >                 echo CONFIG_HAVE_LZ4C
> >         fi
> >
> > then munge the output of that script into the Kconfig run and do
> >
> >         depends on HAVE_LZ4C
> 
> That does sound nice to avoid the build error, but will eventually
> make it harder to diagnose why the kernel has not been compressed with
> the specific compression tool, some kind of warning should also be
> emitted maybe?

Either a warning at check-time, or a comment in Kconfig, such as:
    config COMPRESS_LZ4
        depends on HAVE_LZ4
    comment "'lz4' missing, LZ4 compression not available"
        depends on !HAVE_LZ4

Either way is fine with me. ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'


From shawn.guo at linaro.org  Tue Jul 16 05:28:46 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 17:28:46 +0800
Subject: [PATCH] dma: mxs-dma: remove code left from generic DMA binding
 conversion
Message-ID: <1373966926-13809-1-git-send-email-shawn.guo@linaro.org>

With all mxs-dma clients moved to use generic DMA helper, the code
left from generic DMA binding conversion can be removed now.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
Reviewed-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/dma/mxs-dma.c       |   23 -----------------------
 include/linux/fsl/mxs-dma.h |   20 --------------------
 2 files changed, 43 deletions(-)
 delete mode 100644 include/linux/fsl/mxs-dma.h

diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index 7195930..099be73 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -23,7 +23,6 @@
 #include <linux/dmaengine.h>
 #include <linux/delay.h>
 #include <linux/module.h>
-#include <linux/fsl/mxs-dma.h>
 #include <linux/stmp_device.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
@@ -197,24 +196,6 @@ static struct mxs_dma_chan *to_mxs_dma_chan(struct dma_chan *chan)
 	return container_of(chan, struct mxs_dma_chan, chan);
 }
 
-int mxs_dma_is_apbh(struct dma_chan *chan)
-{
-	struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(chan);
-	struct mxs_dma_engine *mxs_dma = mxs_chan->mxs_dma;
-
-	return dma_is_apbh(mxs_dma);
-}
-EXPORT_SYMBOL_GPL(mxs_dma_is_apbh);
-
-int mxs_dma_is_apbx(struct dma_chan *chan)
-{
-	struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(chan);
-	struct mxs_dma_engine *mxs_dma = mxs_chan->mxs_dma;
-
-	return !dma_is_apbh(mxs_dma);
-}
-EXPORT_SYMBOL_GPL(mxs_dma_is_apbx);
-
 static void mxs_dma_reset_chan(struct mxs_dma_chan *mxs_chan)
 {
 	struct mxs_dma_engine *mxs_dma = mxs_chan->mxs_dma;
@@ -349,13 +330,9 @@ static irqreturn_t mxs_dma_int_handler(int irq, void *dev_id)
 static int mxs_dma_alloc_chan_resources(struct dma_chan *chan)
 {
 	struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(chan);
-	struct mxs_dma_data *data = chan->private;
 	struct mxs_dma_engine *mxs_dma = mxs_chan->mxs_dma;
 	int ret;
 
-	if (data)
-		mxs_chan->chan_irq = data->chan_irq;
-
 	mxs_chan->ccw = dma_alloc_coherent(mxs_dma->dma_device.dev,
 				CCW_BLOCK_SIZE, &mxs_chan->ccw_phys,
 				GFP_KERNEL);
diff --git a/include/linux/fsl/mxs-dma.h b/include/linux/fsl/mxs-dma.h
deleted file mode 100644
index 55d8702..0000000
--- a/include/linux/fsl/mxs-dma.h
+++ /dev/null
@@ -1,20 +0,0 @@
-/*
- * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef __MACH_MXS_DMA_H__
-#define __MACH_MXS_DMA_H__
-
-#include <linux/dmaengine.h>
-
-struct mxs_dma_data {
-	int chan_irq;
-};
-
-extern int mxs_dma_is_apbh(struct dma_chan *chan);
-extern int mxs_dma_is_apbx(struct dma_chan *chan);
-#endif /* __MACH_MXS_DMA_H__ */
-- 
1.7.9.5




From yann.morin.1998 at free.fr  Tue Jul 16 05:32:39 2013
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Tue, 16 Jul 2013 11:32:39 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130716092242.GD4402@pd.tnic>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <201307161112.17901.yann.morin.1998@free.fr> <20130716092242.GD4402@pd.tnic>
Message-ID: <201307161132.39845.yann.morin.1998@free.fr>

Borislav, All,

On Tuesday 16 July 2013 11:22:42 Borislav Petkov wrote:
> On Tue, Jul 16, 2013 at 11:12:17AM +0200, Yann E. MORIN wrote:
> > The goal is to avoid generating a non-buildable kernel in the first place.
> 
> I know, that's why I'm proposing to fail the build with the script run
> as one of the first things by make.

No, this is already too late: the given .config *is* already broken and
unbuildable.

> > > I.e., those steps:
> > > 1. make <whatever>config
> > > 2. make => A prereq. target runs the shell script.
> > 
> > This is too late, since this will bail out, and will give a false-positive
> > failure.
> 
> Huh? This will tell you: "you've selected X, but I don't have toolX
> needed for the build".
> 
> You install the tool and run make again. Checks pass, the build
> continues.

That does not work in two cases:
  - older distros that do not have the tool packaged
  - automatic test-harness that run thousands of randconfig a day

In the first case, this /could/ be overcome by the user compiling and
installing the package manually, but is mostly undoable in enterprise
environment with shared build machines, where each user would have to
install the same tool(s) again and again.

In the second case, this would yield a lot of false-positive in daily
reports.

Your solution mostly works with minimum overhead for a human user
interactively building a kernel, not with automated test harnesses.

> > While if we were to check for _known_ needed tools before calling into
> > Kconfig,
> 
> How would you do that? How do you know what the user is going to select
> *before* she even selects it?

The idea is to *avoid* the user being able to select unavailable options.

> You need to have a prepared .config to act upon.

The idea is to be always have a .config that is buildable with the current
toolset of the system, especially for esoteric and/or recent tools that are
not packaged and/or installed by default by the distros.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'


From balbi at ti.com  Tue Jul 16 05:35:41 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 16 Jul 2013 12:35:41 +0300
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130716090536.5541.36289.stgit@localhost>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
Message-ID: <20130716093541.GK8880@arwen.pp.htv.fi>

Hi,

On Tue, Jul 16, 2013 at 02:05:36AM -0700, Tony Lindgren wrote:
> +int pinctrl_check_dynamic(struct device *dev, struct pinctrl_state *st1,
> +			  struct pinctrl_state *st2)
> +{
> +	struct pinctrl_setting *s1, *s2;
> +
> +	list_for_each_entry(s1, &st1->settings, node) {
> +		struct pinctrl_dev *pctldev1;
> +		const struct pinctrl_ops *pctlops1;
> +		const unsigned *pins1;
> +		unsigned num_pins1;
> +		int res;
> +
> +		if (s1->type != PIN_MAP_TYPE_MUX_GROUP)
> +			continue;
> +
> +		pctldev1 = s1->pctldev;
> +		pctlops1 = pctldev1->desc->pctlops;
> +		res = pctlops1->get_group_pins(pctldev1, s1->data.mux.group,
> +					       &pins1, &num_pins1);
> +		if (res) {
> +			dev_dbg(dev, "could not get state1 group pins\n");
> +			return -EINVAL;
> +		}
> +
> +		list_for_each_entry(s2, &st2->settings, node) {
> +			struct pinctrl_dev *pctldev2;
> +			const struct pinctrl_ops *pctlops2;
> +			const unsigned *pins2;
> +			unsigned num_pins2;
> +			int i, j, found = 0;
> +
> +			if (s2->type != PIN_MAP_TYPE_MUX_GROUP)
> +				continue;
> +
> +			pctldev2 = s2->pctldev;
> +			if (pctldev1 != pctldev2) {
> +				dev_dbg(dev, "pctldev must be the same for states\n");
> +				return -EINVAL;
> +			}
> +			pctlops2 = pctldev2->desc->pctlops;
> +			res = pctlops2->get_group_pins(pctldev2,
> +						       s2->data.mux.group,
> +						       &pins2, &num_pins2);
> +			if (res) {
> +				dev_dbg(dev, "could not get state2 group pins\n");
> +				return -EINVAL;
> +			}
> +
> +			for (i = 0; i < num_pins1; i++) {
> +				int pin1 = pins1[i];
> +
> +				for (j = 0; j < num_pins2; j++) {
> +					int pin2 = pins2[j];
> +
> +					if (pin1 == pin2) {
> +						found++;
> +						break;
> +					}
> +				}
> +			}

4 levels of nested loops ? Isn't this way too much ? OTOH, it points to
the fact that, perhaps, a list isn't the best data structure for
pinctrl ??

Or perhaps you could just assume that if num_pins1 == num_pins2 it's
enough ? But that will, likely, leave some uncovered corners...

-- 
balbi
-------------- 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/20130716/bb3331b7/attachment.sig>

From gerlando.falauto at keymile.com  Tue Jul 16 05:37:30 2013
From: gerlando.falauto at keymile.com (Gerlando Falauto)
Date: Tue, 16 Jul 2013 11:37:30 +0200
Subject: [PATCH] ARM: Kirkwood: Fix the internal register ranges
 translation
In-Reply-To: <1371569479-31498-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1371569479-31498-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <51E5145A.90404@keymile.com>

Hi Ezequiel,

apologies in advance for commenting on an already-merged patch.

On 06/18/2013 05:31 PM, Ezequiel Garcia wrote:
> Although the internal register window size is 1 MiB, the previous
> ranges translation for the internal register space had a size of
> 0x4000000. This was done to allow the crypto and nand node to access
> the corresponding 'sram' and 'nand' decoding windows.
>
> In order to describe the hardware more accurately, we declare the
> real 1 MiB internal register space in the ranges, and add a translation
> entry for the nand node to access the 'nand' window.
>
> This commit will make future improvements on the MBus DT binding easier.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8 at public.gmane.org>
> ---
> Tested on Plathome Openblocks A6 board.
>
>   arch/arm/boot/dts/kirkwood.dtsi | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
> index 8a1e3bb..910fabc 100644
> --- a/arch/arm/boot/dts/kirkwood.dtsi
> +++ b/arch/arm/boot/dts/kirkwood.dtsi
> @@ -38,7 +38,8 @@
>
>   	ocp at f1000000 {
>   		compatible = "simple-bus";
> -		ranges = <0x00000000 0xf1000000 0x4000000
> +		ranges = <0x00000000 0xf1000000 0x0100000
> +		          0xf4000000 0xf4000000 0x0000400
>   		          0xf5000000 0xf5000000 0x0000400>;

Apart from "consistency" with the following range (0xf5000000) used by 
the crypto node, is there any reason why you did not do something like 
this instead (which Valentin suggested, but I will take the blame for):

-		ranges = <0x00000000 0xf1000000 0x4000000
+		ranges = <0x00000000 0xf1000000 0x0100000
+		          0x03000000 0xf4000000 0x0000400
   		          0xf5000000 0xf5000000 0x0000400>;

This would keep a consistent addressing within the child device bus, and 
avoid a later incosistency between the "unit-address" and the first 
"reg" address:

>   		#address-cells = <1>;
>   		#size-cells = <1>;
> @@ -171,7 +172,7 @@
 >   		nand at 3000000 {
		     ^^^^^^^
 >   			#address-cells = <1>;
 >   			#size-cells = <1>;
 >   			cle = <0>;
>   			ale = <1>;
>   			bank-width = <1>;
>   			compatible = "marvell,orion-nand";
> -			reg = <0x3000000 0x400>;
> +			reg = <0xf4000000 0x400>;
				^^^^^^^^^
>   			chip-delay = <25>;
>   			/* set partition map and/or chip-delay in board dts */
>   			clocks = <&gate_clk 7>;
>

I guess the same could be done for the third range and for the crypto 
node as well:

-		ranges = <0x00000000 0xf1000000 0x4000000
-  		          0xf5000000 0xf5000000 0x0000400>;
+		ranges = <0x00000000 0xf1000000 0x0100000
+		          0x03000000 0xf4000000 0x0000400
+		          0x04000000 0xf5000000 0x0000400>;

		crypto at 30000 {
			compatible = "marvell,orion-crypto";
			reg = <0x30000 0x10000>,
-			      <0xf5000000 0x800>;
+			      <0x04000000 0x800>;
			reg-names = "regs", "sram";
			interrupts = <22>;
			clocks = <&gate_clk 17>;
			status = "okay";
		};

Does the above make sense?
Or would that clash with your latest mvebu-mbus device tree binding?
(Which, BTW, I have not quite understood yet).

Thank you,
Gerlando


From bp at alien8.de  Tue Jul 16 05:38:20 2013
From: bp at alien8.de (Borislav Petkov)
Date: Tue, 16 Jul 2013 11:38:20 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <201307161132.39845.yann.morin.1998@free.fr>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <201307161112.17901.yann.morin.1998@free.fr>
 <20130716092242.GD4402@pd.tnic>
 <201307161132.39845.yann.morin.1998@free.fr>
Message-ID: <20130716093820.GE4402@pd.tnic>

On Tue, Jul 16, 2013 at 11:32:39AM +0200, Yann E. MORIN wrote:
> No, this is already too late: the given .config *is* already broken and
> unbuildable.

Yes, and we don't build it because we fail the build.

> That does not work in two cases:
>   - older distros that do not have the tool packaged

This point is moot - distro kernels are built by the distro people.

>   - automatic test-harness that run thousands of randconfig a day

randconfigs are not guaranteed to build successfully.

> The idea is to be always have a .config that is buildable with the
> current toolset of the system, especially for esoteric and/or recent
> tools that are not packaged and/or installed by default by the
> distros.

How are you going to tell the user running make <something>config to
install the missing tools?

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--


From laurent.pinchart at ideasonboard.com  Tue Jul 16 05:42:12 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 16 Jul 2013 11:42:12 +0200
Subject: [PATCH v4 0/3]  ARM: shmobile: lager: enable Ether
In-Reply-To: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
References: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <7990652.CKWzcoj3FL@avalon>

Hi Simon,

On Monday 01 July 2013 16:20:31 Simon Horman wrote:
> Hi,
> 
> this short series enables the on-board ethernet
> of the r8a7790 SoC for on lager board.
> 
> It has a run-time dependency on
> "sh_eth: add support for r8a7790 SoC"
> 
> It has been built on top of renesas-next-20130701.

Do you plan to respin this series on top of your latest devel branch ? I've 
quickly rebased it and now get receive FIFO overflows when booting over NFS, 
followed by the kernel disabling the sh-eth IRQ.

> Simon Horman (3):
>   ARM: shmobile: r8a7790: add Ether support
>   ARM: shmobile: lager: enable Ether
>   ARM: shmobile: lager: enable nfsroot in DTS
> 
>  arch/arm/boot/dts/r8a7790-lager.dts           |  2 +-
>  arch/arm/mach-shmobile/board-lager.c          | 24 ++++++++++++++++++++++++
> arch/arm/mach-shmobile/clock-r8a7790.c        |  4 ++++
>  arch/arm/mach-shmobile/include/mach/r8a7790.h |  3 +++
>  arch/arm/mach-shmobile/setup-r8a7790.c        | 14 ++++++++++++++
>  5 files changed, 46 insertions(+), 1 deletion(-)

-- 
Regards,

Laurent Pinchart



From peter.chen at freescale.com  Tue Jul 16 05:43:21 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Tue, 16 Jul 2013 17:43:21 +0800
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <201307121518.31501.marex@denx.de>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <201307120604.43642.marex@denx.de>
 <20130712082642.GB16202@nchen-desktop>
 <201307121518.31501.marex@denx.de>
Message-ID: <20130716094320.GA29679@nchen-desktop>

On Fri, Jul 12, 2013 at 03:18:31PM +0200, Marek Vasut wrote:
> Hi Peter,
> 
> > On Fri, Jul 12, 2013 at 06:04:43AM +0200, Marek Vasut wrote:
> > > Hi Peter,
> > > 
> > > > On Thu, Jul 11, 2013 at 07:57:19PM +0200, Marek Vasut wrote:
> > > > > Hi Peter,
> > > > > 
> > > > > > This patchset adds tested otg id switch function and
> > > > > > vbus connect and disconnect detection for chipidea driver.
> > > > > > And fix kinds of bugs found at chipidea drivers after enabling
> > > > > > id and vbus detection.
> > > > > > 
> > > > > > This patch is fully tested at imx6 sabresd platform.
> > > > > > My chipidea repo: https://github.com/hzpeterchen/linux-usb.git
> > > > > > 
> > > > > > Changes for v12:
> > > > > > - Rebased greg's usb-next tree (3.10.0-rc7+)
> > > > > > - Split more small patches for single function and fix.
> > > > > 
> > > > > I tested the patchset. Here are the results:
> > > > > 
> > > > > - VBUS switching
> > > > > 
> > > > > I'm no longer getting any ID interrupts at all when I apply the patch
> > > > > below. The board stays in HOST mode all the time. If I configure it
> > > > > as peripheral, it works as peripheral. Note with [1], I was able to
> > > > > switch from Peripheral->Host , not the other way around.
> > > > 
> > > > Thanks for your testing. But first, can you have me check
> > > > if your ID wakeup is enabled?
> > > 
> > > ID wakeup? How do I check?
> > 
> > See otgsc at controller register, the ID wakeup enable is bit 24.
> 
> Yes, ID interrupt (IDIE) is set.
> 
> I noticed this backtrace in the kernel bootlog, but this only happens if the 
> dr_mode="otg" , it comes from the host-mode irq handler :
> 
> [    2.757563] irq 238: nobody cared (try booting with the "irqpoll" option)
> [    2.764398] CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-
> next-20130711-00013-g011c4b3-dirty #703
> [    2.773445] [<80013878>] (unwind_backtrace+0x0/0xe8) from [<80011644>] 
> (show_stack+0x10/0x14)
> [    2.782027] [<80011644>] (show_stack+0x10/0x14) from [<800659f4>] 
> (__report_bad_irq.isra.6+0x20/0xe0)
> [    2.791286] [<800659f4>] (__report_bad_irq.isra.6+0x20/0xe0) from 
> [<80065c98>] (note_interrupt+0x16c/0x230)
> [    2.801063] [<80065c98>] (note_interrupt+0x16c/0x230) from [<80064000>] 
> (handle_irq_event_percpu+0x10c/0x1a4)
> [    2.811010] [<80064000>] (handle_irq_event_percpu+0x10c/0x1a4) from 
> [<800640e8>] (handle_irq_event+0x50/0x78)
> [    2.820958] [<800640e8>] (handle_irq_event+0x50/0x78) from [<8006652c>] 
> (handle_level_irq+0x88/0x10c)
> [    2.830210] [<8006652c>] (handle_level_irq+0x88/0x10c) from [<800638d0>] 
> (generic_handle_irq+0x28/0x3c)
> [    2.839637] [<800638d0>] (generic_handle_irq+0x28/0x3c) from [<8000f84c>] 
> (handle_IRQ+0x30/0x84)
> [    2.848461] [<8000f84c>] (handle_IRQ+0x30/0x84) from [<80012160>] 
> (__irq_svc+0x40/0x6c)
> [    2.856510] [<80012160>] (__irq_svc+0x40/0x6c) from [<80022a44>] 
> (__do_softirq+0x90/0x1d8)
> [    2.864812] [<80022a44>] (__do_softirq+0x90/0x1d8) from [<80022edc>] 
> (irq_exit+0x98/0xd4)
> [    2.873025] [<80022edc>] (irq_exit+0x98/0xd4) from [<8000f850>] 
> (handle_IRQ+0x34/0x84)
> [    2.880980] [<8000f850>] (handle_IRQ+0x34/0x84) from [<80012160>] 
> (__irq_svc+0x40/0x6c)
> [    2.889020] [<80012160>] (__irq_svc+0x40/0x6c) from [<8001d724>] 
> (vprintk_emit+0x1bc/0x524)
> [    2.897411] [<8001d724>] (vprintk_emit+0x1bc/0x524) from [<804da5a4>] 
> (printk+0x30/0x40)
> [    2.905551] [<804da5a4>] (printk+0x30/0x40) from [<80630138>] 
> (mousedev_init+0x4c/0x60)
> [    2.913617] [<80630138>] (mousedev_init+0x4c/0x60) from [<806178fc>] 
> (do_one_initcall+0x94/0x14c)
> [    2.922537] [<806178fc>] (do_one_initcall+0x94/0x14c) from [<80617b20>] 
> (kernel_init_freeable+0x16c/0x22c)
> [    2.932230] [<80617b20>] (kernel_init_freeable+0x16c/0x22c) from [<804d8cbc>] 
> (kernel_init+0x8/0x150)
> [    2.941486] [<804d8cbc>] (kernel_init+0x8/0x150) from [<8000ea70>] 
> (ret_from_fork+0x14/0x24)
> [    2.949932] handlers:
> [    2.952227] [<8033fc58>] ci_irq
> [    2.955388] Disabling IRQ #238
> 

Marek, I have a test at imx28evk (Freescale imx28evk) for this patchset,
it works well for dual-role switch after adding below dts change.
There is a kernel dump when works at udc mode(due to enable CONFIG_LOCKUP_DETECTOR),
at the first connect, but it does not affect function, it should be a common
chipidea problem, I will check later.

diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 3637bf3..e8e2f09 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -240,6 +240,8 @@
 	ahb at 80080000 {
 		usb0: usb at 80080000 {
 			vbus-supply = <&reg_usb0_vbus>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&usbphy0_pins_c>;
 			status = "okay";
 		};
 
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 600f7cb..a11e015 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -657,6 +657,16 @@
 					fsl,pull-up = <0>;
 				};
 
+				usbphy0_pins_c: usbphy0 at 2 {
+					reg = <2>;
+					fsl,pinmux-ids = <
+						0x3071 /* MX28_PAD_AUART1_RTS__USB0_ID */
+					>;
+					fsl,drive-strength = <2>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <1>;
+				};
+
 				usbphy1_pins_a: usbphy1 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <

-- 

Best Regards,
Peter Chen



From lorenzo.pieralisi at arm.com  Tue Jul 16 05:45:08 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 16 Jul 2013 10:45:08 +0100
Subject: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu
 nodes bindings updates
In-Reply-To: <51E44486.7050806@gmail.com>
References: <1368804061-4421-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1368804061-4421-4-git-send-email-lorenzo.pieralisi@arm.com>
 <CAL_JsqLANi5UoVyRMsa6XoQ+_KnmTQDfTz++shEh-dZ3FQGZaQ@mail.gmail.com>
 <20130715093406.GC15904@e102568-lin.cambridge.arm.com>
 <51E44486.7050806@gmail.com>
Message-ID: <20130716094508.GA28503@e102568-lin.cambridge.arm.com>

On Mon, Jul 15, 2013 at 07:50:46PM +0100, Rob Herring wrote:
> On 07/15/2013 04:34 AM, Lorenzo Pieralisi wrote:
> > On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote:
> >> On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi
> >> <lorenzo.pieralisi at arm.com> wrote:
> >>> In order to extend the current cpu nodes bindings to newer CPUs
> >>> inclusive of AArch64 and to update support for older ARM CPUs this
> >>> patch updates device tree documentation for the cpu nodes bindings.
> >>
> >> Sorry for the long delay on this, but I'm still not happy with the binding here.
> > 
> > I had to ask Russell again to drop the bindings patches from the patch
> > system, and this is not acceptable since two months have passed and the
> > entire series was reviewed, acked and partially merged. I will review
> > these bindings again but I would like to understand who should give the final
> > go ahead to get these patches queued for upstreaming, I can't continue
> > updating this stuff forever.
> 
> Most of my comments are for 64-bit. So don't blame me that it had to be
> reverted. I said up front I was concerned about this change breaking
> things and it appears it did. New kernels must not require a new DT.

The patches in Russell's tree do not break anything, I asked him to drop
them since, if we change the bindings again, those patches change and have
to be reworked. It was not meant to blame you at all, just saying that
the process to get this stuff in the kernel should be defined properly
and patches reviewed in a timely fashion.

And for legacy reasons the situation related to cpu/cpus node bindings
is a complicated one, there are bindings in the ePAPR, bindings in the
kernel, people are confused and with this set we wanted to draw a
line. For arm64 this is an absolute must.

I disagree with you on the "new kernels must not require a new DT".
That's true if bindings are well defined, not for a mix of legacy ePAPR and
bindings-in-the-kernel.

What's the DT standard for ARM cpu/cpus node ? ePAPR ? In kernel docs ?
A combination thereof ? Things are not clear cut and I do not like that, it
is confusing.

> But yes, this should have been reviewed more quickly. We're working on a
> plan to help address DT binding reviews. We have not enforced that Grant
> and I must ack all bindings, but in this case you certainly need mine
> since I have reviewed it and if you want to me to pull it.

Good, that's all I wanted to know, thanks.

> >>> Main changes:
> >>>     - adds 64-bit bindings
> >>>     - define usage of #address-cells
> >>>     - define 32/64 dts compatibility settings
> >>>     - defines behaviour on pre and post v7 uniprocessor systems
> >>>     - adds ARM 11MPcore specific reg property definition
> >>>
> >>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> >>> ---
> >>>  Documentation/devicetree/bindings/arm/cpus.txt | 459 ++++++++++++++++++++++---
> >>>  1 file changed, 412 insertions(+), 47 deletions(-)
> >>
> >> [snip]
> >>
> >>> +                       # On ARM v8 64-bit systems, where the reg property
> >>> +                         size can be 1 or 2 cells (as defined by cpus node's
> >>> +                         #address-cells property), this property is
> >>> +                         required and matches:
> >>> +
> >>> +                         - On systems running the OS in AArch32:
> >>
> >> The DTS cannot change based on 32-bit or 64-bit OS.
> > 
> > "On systems running the OS in AArch32" implies a dependency on the
> > HW execution state. Since the DT is used to configure OSs I thought that
> > could be a valid sentence. Unfortunately this stuff is not C, so I
> > reiterate my point above, before changing it I would like to understand
> > who should say the wording is ok otherwise we could argue forever.
> 
> It does configure the OS, but not for 32 vs. 64 bit. That is more of a
> problem for the bootloader to know which mode to boot in and covered
> under something like Documentation/arm/Booting. Booting ARM vs. Thumb
> mode would be similar situation.
> 
> Think about how your PC boots and add to that having a DTB as part of
> the firmware shipped with your PC. Then the end user can install a
> 32-bit or 64-bit OS on it. That is the usecase that needs to be
> supported and having different DTB for 32 and 64 bit is totally broken
> and doesn't even help solve that problem.

I will give it more thought, point taken.

> >>> +
> >>> +       - cpu-release-addr
> >>> +               Usage: required for systems that have an "enable-method"
> >>> +                      property value of "spin-table".
> >>> +               Value type: <prop-encoded-array>
> >>> +               Definition:
> >>> +                       # On ARM v8 64-bit systems must be a two cell
> >>> +                         property identifying a 64-bit zero-initialised
> >>> +                         memory location.
> >>
> >> As I mentioned previously, isn't some wake-up method needed? Most
> >> systems will be in wfi or wfe rather than continuously spinning.
> > 
> > Mmm...this can become a minefield, wfe, wfi, CPU in reset..this needs some
> > thought.
> 
> Yes, it is today and standardizing this is a good thing. Which is what
> PSCI does. So why are you adding the spintable at all? Are you trying to
> set this as the standard for non-PSCI enabled platforms? Why not just
> say v8 boot interface is PSCI. Sure, we'll probably have to deal with
> other methods, but documenting something else here is not going to
> prevent that problem. I don't think a simple spintable would even work
> for any/most current platforms. I'd think we'd want to define something
> that would work for existing platforms (chances are new platforms will
> work like vendors' existing 32-bit platforms).

"spin-table" is how the current v8 kernel boots, I am not adding
anything. It is documented in Documentation/arm64/booting.txt.
I have to add the possible wake-up method(s) to the definition of
spin-table here.

Just adding PSCI is tempting but not viable, that would make people
think that's the only allowed method and that's not acceptable.

While defining the process for the introduction of new DT bindings
please consider how we have to deal with legacy bindings designed for
PowerPC that people tend to reuse for ARM ("status" property in cpu
nodes is next, as James highlighted in another thread).

We are doing that in a case by case fashion and that's becoming a nightmare.

Thank you !
Lorenzo



From yann.morin.1998 at free.fr  Tue Jul 16 05:45:27 2013
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Tue, 16 Jul 2013 11:45:27 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130716093820.GE4402@pd.tnic>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <201307161132.39845.yann.morin.1998@free.fr> <20130716093820.GE4402@pd.tnic>
Message-ID: <201307161145.27810.yann.morin.1998@free.fr>

Borislav, All,

On Tuesday 16 July 2013 11:38:20 Borislav Petkov wrote:
> On Tue, Jul 16, 2013 at 11:32:39AM +0200, Yann E. MORIN wrote:
> > That does not work in two cases:
> >   - older distros that do not have the tool packaged
> 
> This point is moot - distro kernels are built by the distro people.

It's not about building distro kernels. It's about building the current
kernel on a distro, for example for cross-compilation.

> >   - automatic test-harness that run thousands of randconfig a day
> randconfigs are not guaranteed to build successfully.

Well, mostly agreed. However, there was a request (in this thread) that
using such new tools that are not yet widely available in distros, does
not break randconfig.

This is a *new* requirement.

> > The idea is to be always have a .config that is buildable with the
> > current toolset of the system, especially for esoteric and/or recent
> > tools that are not packaged and/or installed by default by the
> > distros.
> How are you going to tell the user running make <something>config to
> install the missing tools?

As discussed with Florian in this thread, either one of:
  - a warning at check time
  - a comment in Kconfig

which both are easy enough to achieve. As I said earlier in this thread,
I've been using a similar scheme in crosstool-NG (which uses Kconfig as
its configuration infrastructure), and it has been proven effective
over the past feew years.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'


From peter.chen at freescale.com  Tue Jul 16 05:45:06 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Tue, 16 Jul 2013 17:45:06 +0800
Subject: [PATCH v12 06/13] usb: chipidea: add otg_cap attribute for otg
 capable
In-Reply-To: <87r4f4dsi5.fsf@ashishki-desk.ger.corp.intel.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <1373524041-10482-7-git-send-email-peter.chen@freescale.com>
 <871u742o4u.fsf@ashishki-desk.ger.corp.intel.com>
 <20130712082500.GA16202@nchen-desktop>
 <87r4f4dsi5.fsf@ashishki-desk.ger.corp.intel.com>
Message-ID: <20130716094506.GB29679@nchen-desktop>

On Fri, Jul 12, 2013 at 12:42:10PM +0300, Alexander Shishkin wrote:
> Peter Chen <peter.chen at freescale.com> writes:
> 

Hi Alex, do you have any other comments for this patchset?
If you haven't, I will send the v13 patchset with current
comments.

-- 

Best Regards,
Peter Chen



From p.zabel at pengutronix.de  Tue Jul 16 05:49:26 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 16 Jul 2013 11:49:26 +0200
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <20130716041056.GA30067@S2101-09.ap.freescale.net>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <20130716041056.GA30067@S2101-09.ap.freescale.net>
Message-ID: <1373968166.4327.11.camel@pizza.hi.pengutronix.de>

Hi Shawn,

Am Dienstag, den 16.07.2013, 12:10 +0800 schrieb Shawn Guo:
> On Mon, Jul 15, 2013 at 09:35:52PM -0600, Stephen Warren wrote:
> > > It's a little bit late to register gpio-reset driver at module_init
> > > time, because gpio-reset provides reset control via gpio for other
> > > devices which are mostly probed at module_init time too.  And it
> > > becomes even worse, when the gpio comes from IO expander on I2C bus,
> > > e.g. pca953x.  In that case, gpio-reset needs to be ready before I2C
> > > bus driver which is generally ready at subsys_initcall time.  Let's
> > > register gpio-reset driver in arch_initcall() to have it ready early
> > > enough.
> > 
> > There's no need for the reset driver to be registered before its users;
> > the users of the reset GPIO will simply have their probe deferred until
> > the reset controller is available, and then everything will work out
> > just fine.
> > 
> > > The defer probe mechanism is not used here, because a reset controller
> > > driver should be reasonably registered early than other devices.  More
> > > importantly, defer probe doe not help in some nasty cases, e.g. the
> > > gpio-pca953x device itself needs a reset from gpio-reset driver to start
> > > working.
> > 
> > That should work fine with deferred probe.
> 
> I should probably rework the commit log.  But I do not see a problem
> to register gpio-reset driver a little bit earlier.  On the other hand,
> if we reply on deferred probe, many drivers probe could be deferred.
> For example, on my system, the gpio-pca953x on I2C bus works as a GPIO
> controller and provides resets to many board level components.
> Deferring probe of gpio-pca953x on I2C bus means every single probe of
> all these components gets deferred.  IMO, this situation should be
> reasonably avoided.

so you want to have gpio-reset probed at arch_initcall time and you have
gpio-pca953x probed at subsys_initcall time. Won't then all gpio-reset
devices that use gpios on pca953x to reset other peripherals need to be
deferred?

regards
Philipp



From p.zabel at pengutronix.de  Tue Jul 16 05:51:19 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 16 Jul 2013 11:51:19 +0200
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <20130716065130.GB30067@S2101-09.ap.freescale.net>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <20130716065130.GB30067@S2101-09.ap.freescale.net>
Message-ID: <1373968279.4327.13.camel@pizza.hi.pengutronix.de>

Am Dienstag, den 16.07.2013, 14:51 +0800 schrieb Shawn Guo:
> On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote:
> > Hi Philipp,
> > 
> > On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
> > > This driver implements a reset controller device that toggle a gpio
> > > connected to a reset pin of a peripheral IC. The delay between assertion
> > > and de-assertion of the reset signal can be configured via device tree.
> > > 
> > > Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> > > Reviewed-by: Stephen Warren <swarren at nvidia.com>
> > 
> > I see this patch is very useful, as GPIOs are widely used to reset
> > components/devices on board.  But I do not find the patch in v3.11-rc1.
> > What's your plan about it?
> > 
> > Also, I'm wondering if we should register the driver a little bit
> > early.  Please see the following patch.  If it makes sense to you,
> > I can send the patch to you, or you can just quash it into yours.
> 
> And here is another change request.

Looks good to me. I can squash it into the original patch and resend if
you like.

regards
Philipp

> Shawn
> 
> ----8<---------------
> 
> From 822a0c4fb7c99b371844ba7e957affcaa8cb1cfe Mon Sep 17 00:00:00 2001
> From: Shawn Guo <shawn.guo at linaro.org>
> Date: Sun, 14 Jul 2013 20:28:05 +0800
> Subject: [PATCH] ENGR00269945: reset: handle cansleep case in gpio-reset
> 
> Some gpio reset may be backed by a gpio that can sleep, e.g. pca953x
> gpio output.  For such gpio, gpio_set_value_cansleep() should be
> called.  Otherwise, the WARN_ON(chip->can_sleep) in gpiod_set_value()
> will be hit.  Add a gpio_cansleep() check to handle cansleep gpio.
> 
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> ---
>  drivers/reset/gpio-reset.c |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
> index 5d2515a..4f372f9 100644
> --- a/drivers/reset/gpio-reset.c
> +++ b/drivers/reset/gpio-reset.c
> @@ -32,7 +32,10 @@ static void gpio_reset_set(struct reset_controller_dev *rcdev, int asserted)
>  	if (drvdata->active_low)
>  		value = !value;
>  
> -	gpio_set_value(drvdata->gpio, value);
> +	if (gpio_cansleep(drvdata->gpio))
> +		gpio_set_value_cansleep(drvdata->gpio, value);
> +	else
> +		gpio_set_value(drvdata->gpio, value);
>  }
>  
>  static int gpio_reset(struct reset_controller_dev *rcdev, unsigned long id)




From gorcunov at gmail.com  Tue Jul 16 05:53:49 2013
From: gorcunov at gmail.com (Cyrill Gorcunov)
Date: Tue, 16 Jul 2013 13:53:49 +0400
Subject: [PATCH] arm: align shared memory unconditionally to the SHMLBA
 boundary
In-Reply-To: <51E4DC0B.8040908@parallels.com>
References: <1361254269-3444-1-git-send-email-alekskartashov@parallels.com>
 <20130715173238.GJ1730@moon>
 <20130715180846.GV24642@n2100.arm.linux.org.uk>
 <20130715185739.GK1730@moon> <51E4DC0B.8040908@parallels.com>
Message-ID: <20130716095349.GB16370@moon>

On Tue, Jul 16, 2013 at 09:37:15AM +0400, Alexander Kartashov wrote:
> On 07/15/2013 10:57 PM, Cyrill Gorcunov wrote:
> >Alexander, mind to remind where exactly we're failing in c/r procedure
> 
> It isn't always possible to pin an IPC SHM region
> using shmat() at the address returned by shmget()
> so sometimes it's impossible to restore a process
> that uses the IPC SHM.

Does it mean that we simply can't checkpoint and restore on same
node (ie same arm family) if this patch is not applied, right?
Is there any possibility to somehow workaround this problem
completely in user-space?


From u.kleine-koenig at pengutronix.de  Tue Jul 16 05:54:49 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Tue, 16 Jul 2013 11:54:49 +0200
Subject: [PATCH v2 2/3] serial: mxs: enable the DMA only when the RTS/CTS
 is valid
In-Reply-To: <1373957732-16638-3-git-send-email-b32955@freescale.com>
References: <1373957732-16638-1-git-send-email-b32955@freescale.com>
 <1373957732-16638-3-git-send-email-b32955@freescale.com>
Message-ID: <20130716095449.GS12139@pengutronix.de>

On Tue, Jul 16, 2013 at 02:55:31PM +0800, Huang Shijie wrote:
> The original DMA support works only when RTS/CTS is enabled.
What is original here?

> But after several patches, DMA support has lost this limit.
This is still misleading.

> This patch adds an optional property for the UART DT node
> which indicates the UART has RTS and CTS lines.
> 
> This patch also adds a macro MXS_AUART_RTSCTS, and uses it to check
> RTS/CTS before we enable the DMA for the UART.

I still think this should go to stable. The options are:

	a) also take patch 1 into stable
	b) apply this patch without patch 1

I don't know if option a) is OK, b) is probably preferable. And as Greg
has much to do anyhow, better move this patch first. (Otherwise he will
probably only say: That patch doesn't apply, please help.)

> Signed-off-by: Huang Shijie <b32955 at freescale.com>
> ---
>  .../bindings/tty/serial/fsl-mxs-auart.txt          |    4 ++++
>  drivers/tty/serial/mxs-auart.c                     |    5 ++++-
>  2 files changed, 8 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
> index 2c00ec6..59a40f1 100644
> --- a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
> +++ b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
> @@ -10,6 +10,10 @@ Required properties:
>    Refer to dma.txt and fsl-mxs-dma.txt for details.
>  - dma-names: "rx" for RX channel, "tx" for TX channel.
>  
> +Optional properties:
> +- fsl,uart-has-rtscts : Indicate the UART has RTS and CTS lines,
> +	it also means you enable the DMA support for this UART.
> +
>  Example:
>  auart0: serial at 8006a000 {
>  	compatible = "fsl,imx28-auart", "fsl,imx23-auart";
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index 465ef0b..27532fd 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -134,6 +134,7 @@ enum mxs_auart_type {
>  struct mxs_auart_port {
>  	struct uart_port port;
>  
> +#define MXS_AUART_RTSCTS	1
>  #define MXS_AUART_DMA_ENABLED	0x2
>  #define MXS_AUART_DMA_TX_SYNC	2  /* bit 2 */
>  #define MXS_AUART_DMA_RX_READY	3  /* bit 3 */
> @@ -639,7 +640,7 @@ static void mxs_auart_settermios(struct uart_port *u,
>  		 * we can only implement the DMA support for auart
>  		 * in mx28.
>  		 */
> -		if (is_imx28_auart(s)) {
> +		if (is_imx28_auart(s) && (s->flags & MXS_AUART_RTSCTS)) {
I thought you wanted to add a comment here. Without knowing the details

	if (RTSCTS)
		enable_dma();

looks strange.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From p.zabel at pengutronix.de  Tue Jul 16 05:59:18 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 16 Jul 2013 11:59:18 +0200
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <51E4BF98.8030604@wwwdotorg.org>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
Message-ID: <1373968758.4327.17.camel@pizza.hi.pengutronix.de>

Hi Stephen,

Am Montag, den 15.07.2013, 21:35 -0600 schrieb Stephen Warren:
> On 07/15/2013 07:50 PM, Shawn Guo wrote:
> > Hi Philipp,
> > 
> > On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
> >> This driver implements a reset controller device that toggle a gpio
> >> connected to a reset pin of a peripheral IC. The delay between assertion
> >> and de-assertion of the reset signal can be configured via device tree.
> >>
> >> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> >> Reviewed-by: Stephen Warren <swarren at nvidia.com>
> > 
> > I see this patch is very useful, as GPIOs are widely used to reset
> > components/devices on board.  But I do not find the patch in v3.11-rc1.
> > What's your plan about it?
> > 
> > Also, I'm wondering if we should register the driver a little bit
> > early.  Please see the following patch.  If it makes sense to you,
> > I can send the patch to you, or you can just quash it into yours.
> > 
> > Shawn
> > 
> > ---8<--------
> > 
> > From 2f8ce9e5d6525b98f3828b707458e83fabb39d50 Mon Sep 17 00:00:00 2001
> > From: Shawn Guo <shawn.guo at linaro.org>
> > Date: Sun, 14 Jul 2013 20:41:00 +0800
> > Subject: [PATCH] ENGR00269945: reset: register gpio-reset driver in
> >  arch_initcall
> > 
> > It's a little bit late to register gpio-reset driver at module_init
> > time, because gpio-reset provides reset control via gpio for other
> > devices which are mostly probed at module_init time too.  And it
> > becomes even worse, when the gpio comes from IO expander on I2C bus,
> > e.g. pca953x.  In that case, gpio-reset needs to be ready before I2C
> > bus driver which is generally ready at subsys_initcall time.  Let's
> > register gpio-reset driver in arch_initcall() to have it ready early
> > enough.
> 
> There's no need for the reset driver to be registered before its users;
> the users of the reset GPIO will simply have their probe deferred until
> the reset controller is available, and then everything will work out
> just fine.
> 
> > The defer probe mechanism is not used here, because a reset controller
> > driver should be reasonably registered early than other devices.  More
> > importantly, defer probe doe not help in some nasty cases, e.g. the
> > gpio-pca953x device itself needs a reset from gpio-reset driver to start
> > working.
> 
> That should work fine with deferred probe.

Deferred probing is fine, but it'd be nice to keep the probe deferral
loops to a minimum where possible and/or reasonable.

regards
Philipp



From bp at alien8.de  Tue Jul 16 05:59:38 2013
From: bp at alien8.de (Borislav Petkov)
Date: Tue, 16 Jul 2013 11:59:38 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <201307161145.27810.yann.morin.1998@free.fr>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <201307161132.39845.yann.morin.1998@free.fr>
 <20130716093820.GE4402@pd.tnic>
 <201307161145.27810.yann.morin.1998@free.fr>
Message-ID: <20130716095938.GA4962@pd.tnic>

On Tue, Jul 16, 2013 at 11:45:27AM +0200, Yann E. MORIN wrote:
> As discussed with Florian in this thread, either one of:
>   - a warning at check time
>   - a comment in Kconfig

Whatever you do, make sure to make it quite clear to users what she
needs to do.

What I really have a problem with is options being hidden just because I
haven't selected something they depend on and having to run around the
Kconfig maze to find what I also need to select in order for the option
to appear.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--


From florian at openwrt.org  Tue Jul 16 06:04:41 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Tue, 16 Jul 2013 11:04:41 +0100
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130716095938.GA4962@pd.tnic>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <201307161132.39845.yann.morin.1998@free.fr> <20130716093820.GE4402@pd.tnic>
 <201307161145.27810.yann.morin.1998@free.fr> <20130716095938.GA4962@pd.tnic>
Message-ID: <CAGVrzcbJrhmxCHqZOhSZH9FeTNj_x674+CSBS0bSRaKDk3nRLA@mail.gmail.com>

2013/7/16 Borislav Petkov <bp at alien8.de>:
> On Tue, Jul 16, 2013 at 11:45:27AM +0200, Yann E. MORIN wrote:
>> As discussed with Florian in this thread, either one of:
>>   - a warning at check time
>>   - a comment in Kconfig
>
> Whatever you do, make sure to make it quite clear to users what she
> needs to do.
>
> What I really have a problem with is options being hidden just because I
> haven't selected something they depend on and having to run around the
> Kconfig maze to find what I also need to select in order for the option
> to appear.

Yes, me too, which is why I suggested the warning, as in "a warning
printed to stdout/stderr" rather than a Kconfig comment which will be
easy to be ignored.
--
Florian


From u.kleine-koenig at pengutronix.de  Tue Jul 16 06:05:11 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Tue, 16 Jul 2013 12:05:11 +0200
Subject: Freescale MXS battery driver
In-Reply-To: <51E4FE90.9010700@digi.com>
References: <51E4FE90.9010700@digi.com>
Message-ID: <20130716100511.GT12139@pengutronix.de>

Hello Hector,

On Tue, Jul 16, 2013 at 10:04:32AM +0200, Hector Palacios wrote:
> Does anybody know if there is any on-going work to support Freescale's
> MXS battery driver?
I didn't check the details, but Rockbox supports the imx23. So you might
find something there.

Best regards from Germany,
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From alekskartashov at parallels.com  Tue Jul 16 06:22:41 2013
From: alekskartashov at parallels.com (Alexander Kartashov)
Date: Tue, 16 Jul 2013 14:22:41 +0400
Subject: [PATCH] arm: align shared memory unconditionally to the SHMLBA
 boundary
In-Reply-To: <20130716095349.GB16370@moon>
References: <1361254269-3444-1-git-send-email-alekskartashov@parallels.com>
 <20130715173238.GJ1730@moon> <20130715180846.GV24642@n2100.arm.linux.org.uk>
 <20130715185739.GK1730@moon> <51E4DC0B.8040908@parallels.com>
 <20130716095349.GB16370@moon>
Message-ID: <51E51EF1.3010104@parallels.com>

On 07/16/2013 01:53 PM, Cyrill Gorcunov wrote:
> Does it mean that we simply can't checkpoint and restore on same
> node (ie same arm family) if this patch is not applied, right?
Yes, it does.
> Is there any possibility to somehow workaround this problem
> completely in user-space?
No, it's impossible since an IPC SHM region is allocated
by the routine shmget() in the dumpee; if the routine
returns an incorrectly aligned address it's impossible
to reattach the region at this address while restoring
the dumpee.

-- 
Sincerely yours,
Alexander Kartashov

Intern
Core team

www.parallels.com

Skype: aleksandr.kartashov
Email: alekskartashov at parallels.com



From pdeschrijver at nvidia.com  Tue Jul 16 06:19:17 2013
From: pdeschrijver at nvidia.com (Peter De Schrijver)
Date: Tue, 16 Jul 2013 13:19:17 +0300
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <51E439BC.9030608@wwwdotorg.org>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
Message-ID: <20130716101917.GZ21962@tbergstrom-lnx.Nvidia.com>

On Mon, Jul 15, 2013 at 08:04:44PM +0200, Stephen Warren wrote:
> On 06/25/2013 03:23 AM, Joseph Lo wrote:
> > Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
> > to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
> > this state.
> 
> I tried applying this patch, your series "[PATCH V3 0/3] ARM: tegra114:
> cpuidle: add power down state", and your series "[PATCH V2 00/11] ARM:
> tegra114: add support for system suspend", all on top of v3.11-rc1.
> 
> On Dalmore, the new cpuidle mode /appears/ to work (I see increasing
> values in the sysfs cpuidle "usage" file for all defined cpuidle
> states), but I don't see the "CPU VDD off" LED light up; I'm not
> convinced that the CPU is actually being powered off in the idle mode.

The current patchset only powergates the individual cores on Tegra114. The
entire cluster (including L2 cache etc) isn't railgated as a CPUidle state.
Hence the CPU VDD off LED will never be on.

Cheers,

Peter.



From grygorii.strashko at ti.com  Tue Jul 16 06:27:02 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Tue, 16 Jul 2013 13:27:02 +0300
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51DE780C.2070701@ti.com>
References: <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <87mwpuakod.fsf@linaro.org>
 <20130710142633.GV5523@atomide.com> <20130710160704.GH18966@arwen.pp.htv.fi>
 <51DE780C.2070701@ti.com>
Message-ID: <51E51FF6.60608@ti.com>

Hi Rajendra,

On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
> On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
>> how about something like below ? It makes omap_device/hwmod and
>> pm_runtime agree on the initial state of the device and will prevent
>> ->runtime_resume() from being called on first pm_runtime_get*() done
>> during probe.
>>
>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>
> I tried something similar [1] but what I found is that the serial
> runtime resume was called despite it being marked as active using
> pm_runtime_set_active().
>
> That seems to be because of the pm_runtime_set_autosuspend_delay()
> because we have the autosuspend_delay = -1
>
> -----
> static void update_autosuspend(struct device *dev, int old_delay, int old_use)
> {
>          int delay = dev->power.autosuspend_delay;
>
>          /* Should runtime suspend be prevented now? */
>          if (dev->power.use_autosuspend && delay < 0) {
>
>                  /* If it used to be allowed then prevent it. */
>                  if (!old_use || old_delay >= 0) {
>                          atomic_inc(&dev->power.usage_count);
>                          rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
>                  }
>          }
> -----
>
> So we end up with the same issue with serial resume being called before set_termios()
>
> [1]
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 5cc9287..c71d47d 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>          struct device_node *node = pdev->dev.of_node;
>          const char *oh_name;
>          int oh_cnt, i, ret = 0;
> +       bool device_active = false;
>
>          oh_cnt = of_property_count_strings(node, "ti,hwmods");
>          if (oh_cnt <= 0) {
> @@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>                          goto odbfd_exit1;
>                  }
>                  hwmods[i] = oh;
> +               if (oh->flags & HWMOD_INIT_NO_IDLE)
> +                       device_active = true;
> +
>          }
>
>          od = omap_device_alloc(pdev, hwmods, oh_cnt);
> @@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>
>          pdev->dev.pm_domain = &omap_device_pm_domain;
>
> +       if (device_active) {
> +               omap_device_enable(pdev);
> +               pm_runtime_set_active(&pdev->dev);
> +       }
> +
>   odbfd_exit1:
>          kfree(hwmods);
>   odbfd_exit:

This solution works good for me in combination with
"serial: omap: enable PM runtime only when its fully configured"
http://www.spinics.net/lists/linux-serial/msg10317.html
(earlyprintk use case)

And I think the best way would be to move forward with yours solution.
- it will affect only on needed IPs drivers - not on all, so no issues 
with iommu and etc.

But issue with *non console" UARTs will still be here and, I think,
there are no way ti solve it from OMAP device/hwmod frameworks side,
because only driver can know when his context is ready.
To test do: #echo 0xDEAD > dev/ttyO3

Regards,
-grygorii


From maxime.ripard at free-electrons.com  Tue Jul 16 06:30:14 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 16 Jul 2013 12:30:14 +0200
Subject: [PATCH 4/5] iio: at91: add an optional dt property for for adc
 clock hz.
In-Reply-To: <51E4FC70.3050207@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-5-git-send-email-josh.wu@atmel.com>
 <20130715130610.GD2962@lukather> <51E4FC70.3050207@atmel.com>
Message-ID: <20130716103014.GB3125@lukather>

On Tue, Jul 16, 2013 at 03:55:28PM +0800, Josh Wu wrote:
> >On Sun, Jul 14, 2013 at 04:04:28PM +0800, Josh Wu wrote:
> >>diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> >>index e93a075..8f1386f 100644
> >>--- a/drivers/iio/adc/at91_adc.c
> >>+++ b/drivers/iio/adc/at91_adc.c
> >>@@ -47,6 +47,7 @@ struct at91_adc_caps {
> >>  struct at91_adc_state {
> >>  	struct clk		*adc_clk;
> >>+	u32			adc_clk_rate;
> >>  	u16			*buffer;
> >>  	unsigned long		channels_mask;
> >>  	struct clk		*clk;
> >>@@ -448,6 +449,10 @@ static int at91_adc_probe_dt(struct at91_adc_state *st,
> >>  	if (!node)
> >>  		return -EINVAL;
> >>+	prop = 0;
> >>+	of_property_read_u32(node, "atmel,adc-clock-rate", &prop);
> >>+	st->adc_clk_rate = prop;
> >>+
> >>  	st->use_external = of_property_read_bool(node, "atmel,adc-use-external-triggers");
> >>  	if (of_property_read_u32(node, "atmel,adc-channels-used", &prop)) {
> >>@@ -723,7 +728,8 @@ static int at91_adc_probe(struct platform_device *pdev)
> >>  	 * specified by the electrical characteristics of the board.
> >>  	 */
> >>  	mstrclk = clk_get_rate(st->clk);
> >>-	adc_clk = clk_get_rate(st->adc_clk);
> >>+	adc_clk = st->adc_clk_rate ?
> >>+		st->adc_clk_rate : clk_get_rate(st->adc_clk);
> >Why is that needed? Isn't it completely redundant with the clocks
> >property?
> 
> As st->adc_clk rate is specified in arch/arm/mach-at91/sama5d3.c
> (take sama5d3 for example), changing the clock rate should recompile
> the kernel binary.
> Use dt parameter will let us easily specify the clock rate instead
> of recompile the code.
>
> And yes, it is redundant that we can define the adc_op_clk rate in
> two places (clock property in .c and adc-clock-rate in dts). But
> this can be compatible with the non-dt platform.

Yet, it's not, while, like you pointed at, the common clock framework
actually *is* usable for both DT and non-DT platforms at no cost.

The fact that AT91 isn't using the DT to retrieve its clock tree yet is
another story (but I believe that it's a work in progress).

> After a further thinking of this, maybe remove the adc_op_clk is
> better since it is a fake clock, and only used to specify the clock
> rate.
> To specify the clock rate use a dt property or platform data
> parameter is better.

No, to specify *any* clock, the common clock framework is the better
solution.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130716/4fd79342/attachment-0001.sig>

From linux at arm.linux.org.uk  Tue Jul 16 06:36:49 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 16 Jul 2013 11:36:49 +0100
Subject: [PATCH] arm: align shared memory unconditionally to the SHMLBA
 boundary
In-Reply-To: <51E51EF1.3010104@parallels.com>
References: <1361254269-3444-1-git-send-email-alekskartashov@parallels.com>
 <20130715173238.GJ1730@moon> <20130715180846.GV24642@n2100.arm.linux.org.uk>
 <20130715185739.GK1730@moon> <51E4DC0B.8040908@parallels.com>
 <20130716095349.GB16370@moon> <51E51EF1.3010104@parallels.com>
Message-ID: <20130716103649.GC24642@n2100.arm.linux.org.uk>

On Tue, Jul 16, 2013 at 02:22:41PM +0400, Alexander Kartashov wrote:
> On 07/16/2013 01:53 PM, Cyrill Gorcunov wrote:
>> Does it mean that we simply can't checkpoint and restore on same
>> node (ie same arm family) if this patch is not applied, right?
> Yes, it does.
>> Is there any possibility to somehow workaround this problem
>> completely in user-space?
> No, it's impossible since an IPC SHM region is allocated
> by the routine shmget() in the dumpee; if the routine
> returns an incorrectly aligned address it's impossible
> to reattach the region at this address while restoring
> the dumpee.

shmget() doesn't allocate space in the process for the SHM region.  It
merely creates the shm memory and returns an identifier for it which can
later be used by shmat() to map it.


From ben.dooks at codethink.co.uk  Tue Jul 16 06:38:39 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Tue, 16 Jul 2013 11:38:39 +0100
Subject: v3.10 - big endian core support
In-Reply-To: <51E4FDA8.9030306@gmail.com>
References: <CALicx6u89THSiRa4FzGZrcoG8q+o_BD8qVEC4CYXEjPUVK_fJw@mail.gmail.com>
 <20130712134726.0a909165@skate> <51DFEF75.8080600@codethink.co.uk>
 <20130714215325.GB7382@mudshark.cambridge.arm.com>
 <51E3ACD0.8040209@codethink.co.uk> <20130715103658.068ac6b7@skate>
 <51E3CE41.5010807@codethink.co.uk> <51E4FDA8.9030306@gmail.com>
Message-ID: <51E522AF.90708@codethink.co.uk>

On 16/07/13 09:00, jgq516 at gmail.com wrote:
> On 07/15/2013 06:26 PM, Ben Dooks wrote:
>> On 15/07/13 09:36, Thomas Petazzoni wrote:
>>> Dear Ben Dooks,
>>>
>>> On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:
>>>
>>>>> As for building a Thumb-2 kernel; just enable the option in
>>>>> menuconfig and
>>>>> you're done. The compiler should "do the right thing".
>>>>
>>>> I can build it, I just don't have the time and hardware to give it a
>>>> test at the moment. However it seems that changing to using 'rev16'
>>>> instead of 'rev'. I will make the necessary changes and get this ready
>>>> to go.
>>>
>>> I am willing to give some testing to early patches, if needed. Do not
>>> hesitate to send me things to test.
>>
>> I've pushed out two new branches on git.baserock.org/delta/linux.git
>> as:
>> baserock/311/be/core-v2
> I have tested the 10 patches on this branch with latest mainline kernel
> (commit 47188d).
> Vexpress a15 tc2 boards works with the combos: BE+LPAE on/off,
> BE+THUMB2+LPAE on and LE.
>
> There are some conflicts existed between your patch set and latest kernel.

I will do a rebase onto HEAD in the next few days and then see if it
can be prepared for merging in the next merge window.


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From alekskartashov at parallels.com  Tue Jul 16 06:47:45 2013
From: alekskartashov at parallels.com (Alexander Kartashov)
Date: Tue, 16 Jul 2013 14:47:45 +0400
Subject: [PATCH] arm: align shared memory unconditionally to the SHMLBA
 boundary
In-Reply-To: <20130716103649.GC24642@n2100.arm.linux.org.uk>
References: <1361254269-3444-1-git-send-email-alekskartashov@parallels.com>
 <20130715173238.GJ1730@moon> <20130715180846.GV24642@n2100.arm.linux.org.uk>
 <20130715185739.GK1730@moon> <51E4DC0B.8040908@parallels.com>
 <20130716095349.GB16370@moon> <51E51EF1.3010104@parallels.com>
 <20130716103649.GC24642@n2100.arm.linux.org.uk>
Message-ID: <51E524D1.2090504@parallels.com>

On 07/16/2013 02:36 PM, Russell King - ARM Linux wrote:
> shmget() doesn't allocate space in the process for the SHM region.  It
> merely creates the shm memory and returns an identifier for it which can
> later be used by shmat() to map it.
Thank you for the correction, I meant shmat() in that comment indeed.
I'm sorry for the inconvenience.

-- 
Sincerely yours,
Alexander Kartashov

Intern
Core team

www.parallels.com

Skype: aleksandr.kartashov
Email: alekskartashov at parallels.com



From linux at arm.linux.org.uk  Tue Jul 16 07:07:21 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 16 Jul 2013 12:07:21 +0100
Subject: [PATCH] arm: align shared memory unconditionally to the SHMLBA
 boundary
In-Reply-To: <51E524D1.2090504@parallels.com>
References: <1361254269-3444-1-git-send-email-alekskartashov@parallels.com>
 <20130715173238.GJ1730@moon> <20130715180846.GV24642@n2100.arm.linux.org.uk>
 <20130715185739.GK1730@moon> <51E4DC0B.8040908@parallels.com>
 <20130716095349.GB16370@moon> <51E51EF1.3010104@parallels.com>
 <20130716103649.GC24642@n2100.arm.linux.org.uk>
 <51E524D1.2090504@parallels.com>
Message-ID: <20130716110721.GD24642@n2100.arm.linux.org.uk>

On Tue, Jul 16, 2013 at 02:47:45PM +0400, Alexander Kartashov wrote:
> On 07/16/2013 02:36 PM, Russell King - ARM Linux wrote:
>> shmget() doesn't allocate space in the process for the SHM region.  It
>> merely creates the shm memory and returns an identifier for it which can
>> later be used by shmat() to map it.
> Thank you for the correction, I meant shmat() in that comment indeed.
> I'm sorry for the inconvenience.

Right, so it appears that there's a difference between shmat() with an
address and with a NULL address, because the enforcement is done by two
completely different bits of code in unrelated parts of the kernel.

I notice Sparc32 seems to have a fix for this along the lines of the
(untested) patch below, so let's do the same on ARM.  Please test this
and let me know if this solves your problem.

Thanks.

 arch/arm/include/asm/shmparam.h |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/shmparam.h b/arch/arm/include/asm/shmparam.h
index a5223b3..843db59 100644
--- a/arch/arm/include/asm/shmparam.h
+++ b/arch/arm/include/asm/shmparam.h
@@ -1,16 +1,16 @@
 #ifndef _ASMARM_SHMPARAM_H
 #define _ASMARM_SHMPARAM_H
 
+#include <asm/cachetype.h>
+
 /*
  * This should be the size of the virtually indexed cache/ways,
  * or page size, whichever is greater since the cache aliases
  * every size/ways bytes.
  */
-#define	SHMLBA	(4 * PAGE_SIZE)		 /* attach addr a multiple of this */
+#define	SHMLBA	(cache_is_vipt_aliasing() ? (4 * PAGE_SIZE) : PAGE_SIZE)
 
-/*
- * Enforce SHMLBA in shmat
- */
+/* Enforce SHMLBA in shmat */
 #define __ARCH_FORCE_SHMLBA
 
 #endif /* _ASMARM_SHMPARAM_H */


From lars at metafoo.de  Tue Jul 16 07:16:43 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Tue, 16 Jul 2013 13:16:43 +0200
Subject: [PATCH 4/5] iio: at91: add an optional dt property for for adc
 clock hz.
In-Reply-To: <20130716103014.GB3125@lukather>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-5-git-send-email-josh.wu@atmel.com>
 <20130715130610.GD2962@lukather> <51E4FC70.3050207@atmel.com>
 <20130716103014.GB3125@lukather>
Message-ID: <51E52B9B.5030407@metafoo.de>

On 07/16/2013 12:30 PM, Maxime Ripard wrote:
[...]
>> After a further thinking of this, maybe remove the adc_op_clk is
>> better since it is a fake clock, and only used to specify the clock
>> rate.
>> To specify the clock rate use a dt property or platform data
>> parameter is better.
> 
> No, to specify *any* clock, the common clock framework is the better
> solution.

Yep, this patch is not the right approach. It's trying to work around the
limitations of the platforms clock API implementation. Please fix the at91
clock implementation instead (e.g. by switching to the common clock framework).

- Lars



From josephl at nvidia.com  Tue Jul 16 07:17:27 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 16 Jul 2013 19:17:27 +0800
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <51E439BC.9030608@wwwdotorg.org>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
Message-ID: <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>

On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
> On 06/25/2013 03:23 AM, Joseph Lo wrote:
> > Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
> > to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
> > this state.
> 
> I tried applying this patch, your series "[PATCH V3 0/3] ARM: tegra114:
> cpuidle: add power down state", and your series "[PATCH V2 00/11] ARM:
> tegra114: add support for system suspend", all on top of v3.11-rc1.
> 
> On Dalmore, the new cpuidle mode /appears/ to work (I see increasing
> values in the sysfs cpuidle "usage" file for all defined cpuidle
> states), but I don't see the "CPU VDD off" LED light up; I'm not
> convinced that the CPU is actually being powered off in the idle mode.
> 
The LED of the CPU Vdd indicates the power of CPU cluster. But the
series of CPU idle power down mode support for Tegra114 only supports
per core power down. It did not support cluster power down yet in idle
mode. That needs some extra work to support cluster power down in idle
mode.
There are some items that I plat to do:
1. integrate the MCPM (multi cluster power management) code into Tegra
CPU PM code
2. integrate coupled CPUidle framework into Tegra CPU idle driver
3. normalize the Tegra CPU idle driver to single one

> With these patches applies, Harmony acts very strangely. After
> hot-unplug and re-plug of CPU1, the system is hung or almost hung. The
> patches appear to reduce the amount of time CPU VDD is off judging by
> the LEDs. The patches might cause issues with system suspend too, but
> I'm not 100% sure.
> 
Actually I didn't add anything about hotplug or something can increase
the loading or make regressions. But I think you are testing with USB
device attached, right? That might cause some extra loading. You can
give it a try after just removing USB device. And I double confirm that
on Seaboard. Except that, the test result looks OK for me.

> As such, I haven't applied any of these. Can you please test boards for
> all of Tegra20/30/114, and validate that on Dalmore the CPU power is
> actually being turned off, and report back? Thanks.

I have tested all these patches based on next-20130716. And verified the
functions on Seaboard, Cardhu and Dalmore. Looks good for me. And the
per core power down in idle is OK too. The cluster power down only
support when the system goes into suspend mode right now for Tegra114.

Thanks,
Joseph



From maxime.ripard at free-electrons.com  Tue Jul 16 07:20:17 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 16 Jul 2013 13:20:17 +0200
Subject: [PATCH 2/5] iio: at91: Use different prescal, startup mask in MR
 for different IP
In-Reply-To: <51E50864.6020904@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
 <20130715125815.GC2962@lukather> <51E505EA.4060502@atmel.com>
 <51E50864.6020904@atmel.com>
Message-ID: <20130716112017.GC3125@lukather>

On Tue, Jul 16, 2013 at 10:46:28AM +0200, Nicolas Ferre wrote:
> >>capabilities from which compatible is declared.
> >>
> >>It seems safer.
> 
> I see it as handier in the sense that a different IP version can be
> compatible with an older IP version: so we do not need to modify the
> driver just to use another SoC.
> 
> On your side Maxime, what makes you say that it is "safer"?

Well, the register holding the IP version seem to be not programmed in
some cases (or, at least, the driver handles this case).

So, what would happen if one SoC was in such case? You wouldn't be able
to use the ADC/touchscreen, even though the IP in itself might very well
work, which doesn't sound very nice, while the DT will always be there,
and will always have a compatible property.

> >Ok, that make sense. I will use compatible names for the capabilities in
> >next version. Thanks.
> 
> Hold on a little bit Josh, I know that Jean-Christophe is not in
> favor of the use of multiple compatible strings. So, as the code is
> already there, let's wait and see if we find another argument...

And you know my feeling about this for quite some time already ;)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130716/17f0b0cb/attachment-0001.sig>

From Dave.Martin at arm.com  Tue Jul 16 07:25:26 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Tue, 16 Jul 2013 12:25:26 +0100
Subject: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu
 nodes bindings updates
In-Reply-To: <CAL_JsqLANi5UoVyRMsa6XoQ+_KnmTQDfTz++shEh-dZ3FQGZaQ@mail.gmail.com>
References: <1368804061-4421-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1368804061-4421-4-git-send-email-lorenzo.pieralisi@arm.com>
 <CAL_JsqLANi5UoVyRMsa6XoQ+_KnmTQDfTz++shEh-dZ3FQGZaQ@mail.gmail.com>
Message-ID: <20130716112520.GA3428@localhost.localdomain>

On Fri, Jul 12, 2013 at 09:47:17AM -0500, Rob Herring wrote:
> On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi
> <lorenzo.pieralisi at arm.com> wrote:
> > In order to extend the current cpu nodes bindings to newer CPUs
> > inclusive of AArch64 and to update support for older ARM CPUs this
> > patch updates device tree documentation for the cpu nodes bindings.
> 
> Sorry for the long delay on this, but I'm still not happy with the binding here.
> 
> > Main changes:
> >     - adds 64-bit bindings
> >     - define usage of #address-cells
> >     - define 32/64 dts compatibility settings
> >     - defines behaviour on pre and post v7 uniprocessor systems
> >     - adds ARM 11MPcore specific reg property definition
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > ---
> >  Documentation/devicetree/bindings/arm/cpus.txt | 459 ++++++++++++++++++++++---
> >  1 file changed, 412 insertions(+), 47 deletions(-)
> 
> [snip]
> 
> > +                       # On ARM v8 64-bit systems, where the reg property
> > +                         size can be 1 or 2 cells (as defined by cpus node's
> > +                         #address-cells property), this property is
> > +                         required and matches:
> > +
> > +                         - On systems running the OS in AArch32:
> 
> The DTS cannot change based on 32-bit or 64-bit OS.
> 
> > +
> > +                           * If the cpus node's #address-cells value is 2:
> > +
> > +                             The first reg cell must be set to 0.
> > +
> > +                             The second reg cell bits [23:0] must be set to
> > +                             bits [23:0] of MPIDR_EL1.
> > +
> > +                             All other bits in the reg cells must be set to 0.
> > +
> > +                           * If the cpus node's #address-cells value is 1:
> > +
> > +                             Bits [23:0] in the reg cell must be set to
> > +                             bits [23:0] in MPIDR_EL1.
> > +
> > +                             All other bits in the reg cell must be 0.
> > +
> > +                         - On systems running the OS in AArch64:
> > +
> > +                           * If the cpus node's #address-cells value is 2:
> > +
> > +                             The first reg cell bits [7:0] must be set to
> > +                             bits [39:32] of MPIDR_EL1.
> > +
> > +                             The second reg cell bits [23:0] must be set to
> > +                             bits [23:0] of MPIDR_EL1.
> > +
> > +                             All other bits in the reg cells must be set to 0.
> > +
> > +                           * If the cpus node's #address-cells value is 1:
> > +
> > +                             MPIDR_EL1[63:32] is 0 on all processors in the
> > +                             system.
> 
> Your logic is backwards here. If the MPIDR_EL1[63:32] is 0, then
> #address-cells can be 1. You could say the upper bits are ignored and
> treated as 0. However, you should simplify all this and just mandate
> that #address-cells must be 2 for ARMv8 or more generally must match
> the size of the MPIDR. If we want to boot a 32-bit kernel, then the
> kernel will have to adapt to support this.

I'd support this, opting for a clean split.

Strictly speaking, it should be this:

AArch64-capable hardware: #address-cells = 2
non-AArch64-capable hardware: #address-cells = 1

The only time it is valid to have #address-cells = 1 on AArch64-capable
hardware is in an AArch32 virtual machine (in which case, the DT anyway
describes the VM and not the real hardware).


However, due to the awkwardness of defining precisely what "AArch64-
capable hardware" means in a world containing firmware and hypervisors,
it might be better (if slightly less correct) to go with:

v8 hardware: #address-cells must be 2
<=v7 hardware: #address-cells must be 1


If the firmware boots an AArch32 payload natively on AArch64-capable
v8 hardware, it's the firmware's job to ensure that non-addressable
CPUs are properly quiesced and shut down, otherwise the setup is
pretty broken -- DT can't solve that one, nor can Linux, so we shouldn't
try.  Linux just needs to discard the non-addressable CPUs and maybe
print out a warning.


Cheers
---Dave


From oleksandr.kozaruk at ti.com  Tue Jul 16 07:27:01 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Tue, 16 Jul 2013 14:27:01 +0300
Subject: [PATCH v4 0/2] TWL6030, TWL6032 GPADC driver
Message-ID: <1373974023-23521-1-git-send-email-oleksandr.kozaruk@ti.com>

Hello,

v4 - addressed comments: fixed style violation, bug in freeing memory,
     added comments explaining calibration method, removed test network
     channels from exposing to userspace, error handling for 
     wait_for_complition
v3 - fixed compiler warning
v2 - the driver put in drivers/iio, and
converted using iio facilities as suggested by Graeme.

TWL603[02] GPADC is used to measure battery voltage,
battery temperature, battery presence ID, and could
be used to measure twl603[02] die temperature.
This is used on TI blaze, blaze tablet platforms.

The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19
channels respectively. Some channels have current
source and are used for measuring voltage drop
on resistive load for detecting battery ID resistance,
or measuring voltage drop on NTC resistors for external
temperature measurements, other channels measure voltage,
(i.e. battery voltage), and have inbuilt voltage dividers,
thus, capable to scale voltage. Some channels are dedicated
for measuring die temperature.

Some channels could be calibrated in 2 points, having
offsets from ideal values in trim registers.

The difference between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i. e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

The driver is derived from git://git.omapzoom.org/kernel/omap.git
The original driver's authors and contributors are Balaji T K,
Graeme Gregory, Ambresh K, Girish S Ghongdemath.

The changes to the original driver:
- device tree adaptation;
- drop ioctl support - never been used;
- unified measurement method for both devices;
- get rid of "if (device == X)" code style to data driven;
- drop polling end of conversion and use interrupt instead;
- iio framework is used

Tested with on blaze tablet 2 with OMAP4430(twl6030), and
OMAP4470(twl6032) SOMs.

The patches were tested against 3.10-rc7

Oleksandr Kozaruk (2):
  ARM: dts: twl: Add GPADC data to device tree
  iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

 arch/arm/boot/dts/twl6030.dtsi  |    6 +
 drivers/iio/adc/Kconfig         |   14 +
 drivers/iio/adc/Makefile        |    1 +
 drivers/iio/adc/twl6030-gpadc.c | 1008 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 1029 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

-- 
1.8.1.2



From oleksandr.kozaruk at ti.com  Tue Jul 16 07:27:02 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Tue, 16 Jul 2013 14:27:02 +0300
Subject: [PATCH 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <1373974023-23521-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1373974023-23521-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1373974023-23521-2-git-send-email-oleksandr.kozaruk@ti.com>

GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.

Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..434842c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
 		compatible = "ti,twl6030-pwmled";
 		#pwm-cells = <2>;
 	};
+
+	gpadc: twl6030_gpadc {
+		compatible = "ti,twl6030_gpadc";
+		interrupts = <3>;
+		#io-channel-cells = <1>;
+	};
 };
-- 
1.8.1.2



From oleksandr.kozaruk at ti.com  Tue Jul 16 07:27:03 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Tue, 16 Jul 2013 14:27:03 +0300
Subject: [PATCH 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <1373974023-23521-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1373974023-23521-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1373974023-23521-3-git-send-email-oleksandr.kozaruk@ti.com>

The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
known also as Phoenix and PhoenixLite.

The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
respectively. Some channels have current source and are used for
measuring voltage drop on resistive load for detecting battery ID
resistance, or measuring voltage drop on NTC resistors for external
temperature measurements. Some channels measure voltage, (i.e. battery
voltage), and have voltage dividers, thus, capable to scale voltage.
Some channels are dedicated for measuring die temperature.

Some channels are calibrated in 2 points, having offsets from ideal
values kept in trim registers. This is used to correct measurements.

The differences between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i.e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
Girish S Ghongdemath.

Signed-off-by: Balaji T K <balajitk at ti.com>
Signed-off-by: Graeme Gregory <gg at slimlogic.co.uk>
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 drivers/iio/adc/Kconfig         |   14 +
 drivers/iio/adc/Makefile        |    1 +
 drivers/iio/adc/twl6030-gpadc.c | 1008 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 1023 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index ab0767e6..3172461 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -150,6 +150,20 @@ config TI_AM335X_ADC
 	  Say yes here to build support for Texas Instruments ADC
 	  driver which is also a MFD client.
 
+config TWL6030_GPADC
+	tristate "TWL6030 GPADC (General Purpose A/D Converter) Support"
+	depends on TWL4030_CORE
+	default n
+	help
+	  Say yes here if you want support for the TWL6030/TWL6032 General
+	  Purpose A/D Converter. This will add support for battery type
+	  detection, battery voltage and temperature measurement, die
+	  temperature measurement, system supply voltage, audio accessory,
+	  USB ID detection.
+
+	  This driver can also be built as a module. If so, the module will be
+	  called twl6030-gpadc.
+
 config VIPERBOARD_ADC
 	tristate "Viperboard ADC support"
 	depends on MFD_VIPERBOARD && USB
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 0a825be..996ba09 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -16,4 +16,5 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
 obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
+obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
 obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
new file mode 100644
index 0000000..658f35b
--- /dev/null
+++ b/drivers/iio/adc/twl6030-gpadc.c
@@ -0,0 +1,1008 @@
+/*
+ * TWL6030 GPADC module driver
+ *
+ * Copyright (C) 2009-2013 Texas Instruments Inc.
+ * Nishant Kamat <nskamat at ti.com>
+ * Balaji T K <balajitk at ti.com>
+ * Graeme Gregory <gg at slimlogic.co.uk>
+ * Girish S Ghongdemath <girishsg at ti.com>
+ * Ambresh K <ambresh at ti.com>
+ * Oleksandr Kozaruk <oleksandr.kozaruk at ti.com
+ *
+ * Based on twl4030-madc.c
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen <mikko.k.ylinen at nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of_platform.h>
+#include <linux/i2c/twl.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define DRIVER_NAME		"twl6030_gpadc"
+
+#define TWL6030_GPADC_MAX_CHANNELS 17
+#define TWL6032_GPADC_MAX_CHANNELS 19
+
+#define TWL6030_GPADC_CTRL_P1			0x05
+
+#define TWL6032_GPADC_GPSELECT_ISB		0x07
+#define TWL6032_GPADC_CTRL_P1			0x08
+
+#define TWL6032_GPADC_GPCH0_LSB			0x0d
+#define TWL6032_GPADC_GPCH0_MSB			0x0e
+
+#define TWL6030_GPADC_CTRL_P1_SP1		BIT(3)
+
+#define TWL6030_GPADC_GPCH0_LSB			(0x29)
+
+#define TWL6030_GPADC_RT_SW1_EOC_MASK		BIT(5)
+
+#define TWL6030_GPADC_TRIM1			0xCD
+
+#define TWL6030_REG_TOGGLE1			0x90
+#define TWL6030_GPADCS				BIT(1)
+#define TWL6030_GPADCR				BIT(0)
+
+/**
+ * struct twl6030_chnl_calib - channel calibration
+ * @gain:		slope coefficient for ideal curve
+ * @gain_error:		gain error
+ * @offset_error:	offset of the real curve
+ */
+struct twl6030_chnl_calib {
+	s32 gain;
+	s32 gain_error;
+	s32 offset_error;
+};
+
+/**
+ * struct twl6030_ideal_code - GPADC calibration parameters
+ * GPADC is calibrated in two points: close to the beginning and
+ * to the and of the measurable input range
+ *
+ * @code1:	ideal code for the input at the beginning
+ * @code2:	ideal code for at the end of the range
+ * @volt1:	voltage input at the beginning(low voltage)
+ * @volt2:	voltage input at the end(high voltage)
+ */
+struct twl6030_ideal_code {
+	u16 code1;
+	u16 code2;
+	u16 volt1;
+	u16 volt2;
+};
+
+struct twl6030_gpadc_data;
+
+/**
+ * struct twl6030_gpadc_platform_data - platform specific data
+ * @nchannels:		number of GPADC channels
+ * @iio_channels:	iio channels
+ * @twl6030_ideal:	pointer to calibration parameters
+ * @start_conversion:	pointer to ADC start conversion function
+ * @channel_to_reg	pointer to ADC function to convert channel to
+ * 			register address for reading conversion result
+ * @calibrate:		pointer to calibration function
+ */
+struct twl6030_gpadc_platform_data {
+	const int nchannels;
+	const struct iio_chan_spec *iio_channels;
+	const struct twl6030_ideal_code *ideal;
+	int (*start_conversion)(int channel);
+	u8 (*channel_to_reg)(int channel);
+	int (*calibrate)(struct twl6030_gpadc_data *gpadc);
+};
+
+/**
+ * struct twl6030_gpadc_data - GPADC data
+ * @dev:		device pointer
+ * @lock:		mutual exclusion lock for the structure
+ * @irq_complete:	completion to signal end of conversion
+ * @twl6030_cal_tbl:	pointer to calibration data for each
+ * 			channel with gain error and offset
+ * @pdata:		pointer to device specific data
+ */
+struct twl6030_gpadc_data {
+	struct device	*dev;
+	struct mutex	lock;
+	struct completion	irq_complete;
+	struct twl6030_chnl_calib	*twl6030_cal_tbl;
+	const struct twl6030_gpadc_platform_data *pdata;
+};
+
+/*
+ * channels 11, 12, 13, 15 and 16 have no calibration data
+ * calibration offset is same for channels 1, 3, 4, 5
+ *
+ * The data is taken from GPADC_TRIM registers description.
+ * GPADC_TRIM registers keeps difference between the code measured
+ * at volt1 and volt2 input voltages and corresponding code1 and code2
+ */
+static const struct twl6030_ideal_code
+	twl6030_ideal[TWL6030_GPADC_MAX_CHANNELS] = {
+	[0] = { /* ch 0, external, battery type, resistor value */
+		.code1 = 116,
+		.code2 = 745,
+		.volt1 = 141,
+		.volt2 = 910,
+	},
+	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[2] = { /* ch 2, external, audio accessory/general purpose */
+		.code1 = 55,
+		.code2 = 818,
+		.volt1 = 101,
+		.volt2 = 1499,
+	},
+	[3] = { /* ch 3, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[4] = { /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[5] = { /* ch 5, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[6] = { /* ch 6, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[7] = { /* ch 7, internal, main battery */
+		.code1 = 614,
+		.code2 = 941,
+		.volt1 = 3001,
+		.volt2 = 4599,
+	},
+	[8] = { /* ch 8, internal, backup battery */
+		.code1 = 82,
+		.code2 = 688,
+		.volt1 = 501,
+		.volt2 = 4203,
+	},
+	[9] = { /* ch 9, internal, external charger input */
+		.code1 = 182,
+		.code2 = 818,
+		.volt1 = 2001,
+		.volt2 = 8996,
+	},
+	[10] = { /* ch 10, internal, VBUS */
+		.code1 = 149,
+		.code2 = 818,
+		.volt1 = 1001,
+		.volt2 = 5497,
+	},
+	[11] = {},	/* ch 11, internal, VBUS charging current */
+	[12] = {},	/* ch 12, internal, Die temperature */
+	[13] = {},	/* ch 13, internal, Die temperature */
+	[14] = { /* ch 14, internal, USB ID line */
+		.code1 = 48,
+		.code2 = 714,
+		.volt1 = 323,
+		.volt2 = 4800,
+	},
+	[15] = {},	/* ch 15, internal, test network */
+	[16] = {},	/* ch 16, internal, test network */
+};
+
+static const struct twl6030_ideal_code
+			twl6032_ideal[TWL6032_GPADC_MAX_CHANNELS] = {
+	[0] = { /* ch 0, external, battery type, resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[2] = { /* ch 2, external, audio accessory/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 660,
+		.volt2 = 1500,
+	},
+	[3] = { /* ch 3, external, temperature with external diode/general
+								purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[4] = { /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[5] = { /* ch 5, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[6] = { /* ch 6, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[7] = { /* ch7, internal, system supply */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+	[8] = { /* ch8, internal, backup battery */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+	[9] = { /* ch 9, internal, external charger input */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 3960,
+		.volt2 = 9000,
+	},
+	[10] = { /* ch10, internal, VBUS */
+		.code1 = 150,
+		.code2 = 751,
+		.volt1 = 1000,
+		.volt2 = 5000,
+	},
+	[11] = { /* ch 11, internal, VBUS DC-DC output current */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 660,
+		.volt2 = 1500,
+	},
+	[12] = { /* ch 12, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[13] = { /* ch 13, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[14] = { /* ch 14, internal, USB ID line */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2420,
+		.volt2 = 5500,
+	},
+	[15] = {},	/* ch 15, internal, test network */
+	[16] = {},	/* ch 16, internal, test network */
+	[17] = {},	/* ch 17, internal, battery charging current */
+	[18] = { /* ch 18, internal, battery voltage */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+};
+
+static inline int twl6030_gpadc_write(u8 reg, u8 val)
+{
+	return twl_i2c_write_u8(TWL6030_MODULE_GPADC, val, reg);
+}
+
+static inline int twl6030_gpadc_read(u8 reg, u8 *val)
+{
+
+	return twl_i2c_read(TWL6030_MODULE_GPADC, val, reg, 2);
+}
+
+static int twl6030_gpadc_enable_irq(u8 mask)
+{
+	int ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_LINE_B);
+	if (ret < 0)
+		return ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_STS_B);
+
+	return ret;
+}
+
+static void twl6030_gpadc_disable_irq(u8 mask)
+{
+	twl6030_interrupt_mask(mask, REG_INT_MSK_LINE_B);
+	twl6030_interrupt_mask(mask, REG_INT_MSK_STS_B);
+}
+
+static irqreturn_t twl6030_gpadc_irq_handler(int irq, void *_gpadc)
+{
+	struct twl6030_gpadc_data *gpadc = _gpadc;
+
+	complete(&gpadc->irq_complete);
+
+	return IRQ_HANDLED;
+}
+
+static int twl6030_start_conversion(int channel)
+{
+	return twl6030_gpadc_write(TWL6030_GPADC_CTRL_P1,
+					TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static int twl6032_start_conversion(int channel)
+{
+	int ret;
+
+	ret = twl6030_gpadc_write(TWL6032_GPADC_GPSELECT_ISB, channel);
+	if (ret)
+		return ret;
+
+	return twl6030_gpadc_write(TWL6032_GPADC_CTRL_P1,
+						TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static u8 twl6030_channel_to_reg(int channel)
+{
+	return TWL6030_GPADC_GPCH0_LSB + 2 * channel;
+}
+
+static u8 twl6032_channel_to_reg(int channel)
+{
+	/*
+	 * for any prior chosen channel, when the conversion is ready
+	 * the result is avalable in GPCH0_LSB, GPCH0_MSB.
+	 */
+
+	return TWL6032_GPADC_GPCH0_LSB;
+}
+
+static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
+		int channel, int *res)
+{
+	u8 reg = gpadc->pdata->channel_to_reg(channel);
+	__le16 val;
+	int ret;
+
+	ret = twl6030_gpadc_read(reg, (u8 *)&val);
+	if (ret) {
+		dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
+		return ret;
+	}
+
+	*res = le16_to_cpup(&val);
+
+	return ret;
+}
+
+static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
+		int channel, int *val)
+{
+	int raw_code;
+	int corrected_code;
+	int channel_value;
+	int ret;
+
+	ret = twl6030_gpadc_get_raw(gpadc, channel, &raw_code);
+	if (ret)
+		return ret;
+
+	corrected_code = ((raw_code * 1000) -
+		gpadc->twl6030_cal_tbl[channel].offset_error) /
+		gpadc->twl6030_cal_tbl[channel].gain_error;
+
+	channel_value = corrected_code *
+			gpadc->twl6030_cal_tbl[channel].gain;
+
+	/* Shift back into mV range */
+	channel_value /= 1000;
+
+	dev_dbg(gpadc->dev, "GPADC raw code: %d", raw_code);
+	dev_dbg(gpadc->dev, "GPADC corrected code: %d", corrected_code);
+	dev_dbg(gpadc->dev, "GPADC value: %d", channel_value);
+
+	*val = channel_value;
+
+	return ret;
+}
+
+static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
+			     const struct iio_chan_spec *chan,
+			     int *val, int *val2, long mask)
+{
+	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
+	int ret = -EINVAL;
+	long timeout;
+
+	mutex_lock(&gpadc->lock);
+
+	ret = gpadc->pdata->start_conversion(chan->channel);
+	if (ret) {
+		dev_err(gpadc->dev, "failed to start conversion\n");
+		goto err;
+	}
+	/* wait for conversion to complete */
+	timeout = wait_for_completion_interruptible_timeout(
+				&gpadc->irq_complete, msecs_to_jiffies(5000));
+	if (!timeout)
+		return -ETIMEDOUT;
+	else if (timeout < 0)
+		return EINTR;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	case IIO_CHAN_INFO_PROCESSED:
+		ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	default:
+		break;
+	}
+err:
+	mutex_unlock(&gpadc->lock);
+
+	return ret;
+}
+
+/*
+ * The GPADC channels are calibrated using a two point calibration method.
+ * The channels measured with two known values: volt1 and volt2, and
+ * ideal corresponding output codes are known: code1, code2.
+ * The difference(d1, d2) between ideal and measured codes stored in trim
+ * registers.
+ * The goal is to find offset and gain of the real curve for each calibrated
+ * channel.
+ * gain: k = 1 + ((d2 - d1) / (x2 - x1))
+ * offset: b = d1 + (k - 1) * x1
+ */
+static void twl6030_calibrate_channel(struct twl6030_gpadc_data *gpadc,
+					int channel, int d1, int d2)
+{
+	int b, k, gain, x1, x2;
+	const struct twl6030_ideal_code *ideal = gpadc->pdata->ideal;
+
+	/* Gain */
+	gain = ((ideal[channel].volt2 - ideal[channel].volt1) * 1000) /
+		(ideal[channel].code2 - ideal[channel].code1);
+
+	x1 = ideal[channel].code1;
+	x2 = ideal[channel].code2;
+
+	/* k - real curve gain */
+	k = 1000 + (((d2 - d1) * 1000) / (x2 - x1));
+
+	/* b - offset of the real curve gain */
+	b = (d1 * 1000) - (k - 1000) * x1;
+
+	gpadc->twl6030_cal_tbl[channel].gain = gain;
+	gpadc->twl6030_cal_tbl[channel].gain_error = k;
+	gpadc->twl6030_cal_tbl[channel].offset_error = b;
+
+	dev_dbg(gpadc->dev, "GPADC d1   for Chn: %d = %d\n", channel, d1);
+	dev_dbg(gpadc->dev, "GPADC d2   for Chn: %d = %d\n", channel, d2);
+	dev_dbg(gpadc->dev, "GPADC x1   for Chn: %d = %d\n", channel, x1);
+	dev_dbg(gpadc->dev, "GPADC x2   for Chn: %d = %d\n", channel, x2);
+	dev_dbg(gpadc->dev, "GPADC Gain for Chn: %d = %d\n", channel, gain);
+	dev_dbg(gpadc->dev, "GPADC k    for Chn: %d = %d\n", channel, k);
+	dev_dbg(gpadc->dev, "GPADC b    for Chn: %d = %d\n", channel, b);
+}
+
+static inline int twl6030_gpadc_get_trim_offset(s8 d)
+{
+	/*
+	 * XXX NOTE!
+	 * bit 0 - sign, bit 7 - reserved, 6..1 - trim value
+	 * though, the documentation states that trim value
+	 * is absolute value, the correct conversion results are
+	 * obtained if the value is interpreted as 2's complement.
+	 */
+	__u32 temp = ((d & 0x7f) >> 1) | ((d & 1) << 6);
+
+	return sign_extend32(temp, 6);
+}
+
+static int twl6030_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int ret;
+	int chn;
+	u8 trim_regs[TWL6030_GPADC_MAX_CHANNELS];
+	s8 d1, d2;
+
+	/*
+	 * for calibration two measurements have been performed at
+	 * factory, for some channels, during the production test and
+	 * have been stored in registers. This two stored values are
+	 * used to correct the measurements. The values represent
+	 * offsets for the given input from the output on ideal curve.
+	 */
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs,
+			TWL6030_GPADC_TRIM1, 16);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	for (chn = 0; chn < TWL6030_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+			d1 = trim_regs[0];
+			d2 = trim_regs[1];
+			break;
+		case 1:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+			d1 = trim_regs[4];
+			d2 = trim_regs[5];
+			break;
+		case 2:
+			d1 = trim_regs[12];
+			d2 = trim_regs[13];
+			break;
+		case 7:
+			d1 = trim_regs[6];
+			d2 = trim_regs[7];
+			break;
+		case 8:
+			d1 = trim_regs[2];
+			d2 = trim_regs[3];
+			break;
+		case 9:
+			d1 = trim_regs[8];
+			d2 = trim_regs[9];
+			break;
+		case 10:
+			d1 = trim_regs[10];
+			d2 = trim_regs[11];
+			break;
+		case 14:
+			d1 = trim_regs[14];
+			d2 = trim_regs[15];
+			break;
+		default:
+			continue;
+		}
+
+		d1 = twl6030_gpadc_get_trim_offset(d1);
+		d2 = twl6030_gpadc_get_trim_offset(d2);
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int chn, d1 = 0, d2 = 0, temp;
+	u8 trim_regs[17];
+	int ret;
+
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
+			TWL6030_GPADC_TRIM1, 16);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	/*
+	 * Loop to calculate the value needed for returning voltages from
+	 * GPADC not values.
+	 *
+	 * gain is calculated to 3 decimal places fixed point.
+	 */
+	for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+		case 1:
+		case 2:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+		case 11:
+		case 12:
+		case 13:
+		case 14:
+			/* D1 */
+			d1 = (trim_regs[3] & 0x1F) << 2;
+			d1 |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				d1 = -d1;
+
+			/* D2 */
+			d2 = (trim_regs[4] & 0x3F) << 2;
+			d2 |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				d2 = -d2;
+			break;
+		case 8:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[8] & 0x18) << 1;
+			d1 |= (trim_regs[7] & 0x1E) >> 1;
+			if (trim_regs[7] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[10] & 0x1F) << 2;
+			d2 |= (trim_regs[8] & 0x06) >> 1;
+			if (trim_regs[8] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		case 9:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[14] & 0x18) << 1;
+			d1 |= (trim_regs[12] & 0x1E) >> 1;
+			if (trim_regs[12] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[16] & 0x1F) << 2;
+			d2 |= (trim_regs[14] & 0x06) >> 1;
+			if (trim_regs[14] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+		case 10:
+			/* D1 */
+			d1 = (trim_regs[11] & 0x0F) << 3;
+			d1 |= (trim_regs[9] & 0x0E) >> 1;
+			if (trim_regs[9] & 0x01)
+				d1 = -d1;
+
+			/* D2 */
+			d2 = (trim_regs[15] & 0x0F) << 3;
+			d2 |= (trim_regs[13] & 0x0E) >> 1;
+			if (trim_regs[13] & 0x01)
+				d2 = -d2;
+			break;
+		case 7:
+		case 18:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[5] & 0x7E) >> 1;
+			if (trim_regs[5] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[6] & 0xFE) >> 1;
+			if (trim_regs[6] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		default:
+			/* No data for other channels */
+			continue;
+		}
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+#define TWL6030_GPADC_CHAN(chn, chan_info) {		\
+	.type = IIO_VOLTAGE,				\
+	.channel = chn,					\
+	.info_mask = BIT(chan_info),			\
+	.info_mask_separate = BIT(chan_info), 		\
+	.indexed = 1,					\
+}
+
+/* internal test network channel */
+#define TWL6030_GPADC_TEST_CHAN(chn, chan_info) {	\
+	.type = IIO_VOLTAGE,				\
+	.channel = chn,					\
+	.info_mask = BIT(chan_info),			\
+	.indexed = 1,					\
+}
+
+static const struct iio_chan_spec twl6030_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(2, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(5, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(12, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(13, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(14, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_TEST_CHAN(15, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_TEST_CHAN(16, IIO_CHAN_INFO_RAW),
+};
+
+static const struct iio_chan_spec twl6032_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(2, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(5, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(12, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(13, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(14, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_TEST_CHAN(15, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_TEST_CHAN(16, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(17, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(18, IIO_CHAN_INFO_PROCESSED),
+};
+
+static const struct iio_info twl6030_gpadc_iio_info = {
+	.read_raw = &twl6030_gpadc_read_raw,
+	.driver_module = THIS_MODULE,
+};
+
+static const struct twl6030_gpadc_platform_data twl6030_pdata = {
+	.iio_channels = twl6030_gpadc_iio_channels,
+	.nchannels = TWL6030_GPADC_MAX_CHANNELS,
+	.ideal = twl6030_ideal,
+	.start_conversion = twl6030_start_conversion,
+	.channel_to_reg = twl6030_channel_to_reg,
+	.calibrate = twl6030_calibration,
+};
+
+static const struct twl6030_gpadc_platform_data twl6032_pdata = {
+	.iio_channels = twl6032_gpadc_iio_channels,
+	.nchannels = TWL6032_GPADC_MAX_CHANNELS,
+	.ideal = twl6032_ideal,
+	.start_conversion = twl6032_start_conversion,
+	.channel_to_reg = twl6032_channel_to_reg,
+	.calibrate = twl6032_calibration,
+};
+
+static const struct of_device_id of_twl6030_match_tbl[] = {
+	{
+		.compatible = "ti,twl6030_gpadc",
+		.data = &twl6030_pdata,
+	},
+	{
+		.compatible = "ti,twl6032_gpadc",
+		.data = &twl6032_pdata,
+	},
+	{ /* end */ }
+};
+
+static int twl6030_gpadc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct twl6030_gpadc_data *gpadc;
+	const struct twl6030_gpadc_platform_data *pdata;
+	const struct of_device_id *match;
+	struct iio_dev *indio_dev;
+	int irq;
+	int ret;
+
+	match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
+	pdata = match ? match->data : dev->platform_data;
+
+	if (!pdata)
+		return -EINVAL;
+
+	indio_dev = iio_device_alloc(sizeof(*gpadc));
+	if (!indio_dev) {
+		dev_err(dev, "failed allocating iio device\n");
+		ret = -ENOMEM;
+	}
+
+	gpadc = iio_priv(indio_dev);
+
+	gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
+					sizeof(struct twl6030_chnl_calib) *
+					pdata->nchannels, GFP_KERNEL);
+	if (!gpadc->twl6030_cal_tbl)
+		goto err_free_device;
+
+	gpadc->dev = dev;
+	gpadc->pdata = pdata;
+
+	platform_set_drvdata(pdev, indio_dev);
+	mutex_init(&gpadc->lock);
+	init_completion(&gpadc->irq_complete);
+
+	ret = pdata->calibrate(gpadc);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to read calibration registers\n");
+		goto err_free_device;
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "failed to get irq\n");
+		goto err_free_device;
+	}
+
+	ret = request_threaded_irq(irq, NULL, twl6030_gpadc_irq_handler,
+				IRQF_ONESHOT, "twl6030_gpadc", gpadc);
+	if (ret) {
+		dev_dbg(&pdev->dev, "could not request irq\n");
+		goto err_free_device;
+	}
+
+	ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
+		goto err_free_irq;
+	}
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+					TWL6030_REG_TOGGLE1);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC module\n");
+		goto err_free_irq;
+	}
+
+	indio_dev->name = DRIVER_NAME;
+	indio_dev->dev.parent = dev;
+	indio_dev->info = &twl6030_gpadc_iio_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->channels = pdata->iio_channels;
+	indio_dev->num_channels = pdata->nchannels;
+
+	ret = iio_device_register(indio_dev);
+	if (ret)
+		goto err_free_irq;
+
+	return ret;
+
+err_free_irq:
+	free_irq(irq, indio_dev);
+err_free_device:
+	iio_device_free(indio_dev);
+
+	return ret;
+}
+
+static int twl6030_gpadc_remove(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+
+	twl6030_gpadc_disable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	free_irq(platform_get_irq(pdev, 0), indio_dev);
+	iio_device_unregister(indio_dev);
+	iio_device_free(indio_dev);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int twl6030_gpadc_suspend(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCR,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error reseting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+
+static int twl6030_gpadc_resume(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error setting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+#endif
+
+SIMPLE_DEV_PM_OPS(twl6030_gpadc_pm_ops, twl6030_gpadc_suspend,
+					twl6030_gpadc_resume);
+
+static struct platform_driver twl6030_gpadc_driver = {
+	.probe		= twl6030_gpadc_probe,
+	.remove		= twl6030_gpadc_remove,
+	.driver		= {
+		.name	= DRIVER_NAME,
+		.owner	= THIS_MODULE,
+		.pm	= &twl6030_gpadc_pm_ops,
+		.of_match_table = of_twl6030_match_tbl,
+	},
+};
+
+module_platform_driver(twl6030_gpadc_driver);
+
+MODULE_ALIAS("platform: " DRIVER_NAME);
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_DESCRIPTION("twl6030 ADC driver");
+MODULE_LICENSE("GPL");
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Tue Jul 16 07:30:03 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Jul 2013 13:30:03 +0200
Subject: [PATCH 2/5] iio: at91: Use different prescal, startup mask in
 MR for different IP
In-Reply-To: <51E50864.6020904@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
 <20130715125815.GC2962@lukather> <51E505EA.4060502@atmel.com>
 <51E50864.6020904@atmel.com>
Message-ID: <20130716133003.7c208cdf@skate>

Dear Nicolas Ferre,

On Tue, 16 Jul 2013 10:46:28 +0200, Nicolas Ferre wrote:

> > Ok, that make sense. I will use compatible names for the capabilities in
> > next version. Thanks.
> 
> Hold on a little bit Josh, I know that Jean-Christophe is not in favor 
> of the use of multiple compatible strings. So, as the code is already 
> there, let's wait and see if we find another argument...

I've asked exactly this question last week at Linaro Connect during the
ARM SoC consolidation panel/discussion, where Grant Likely, Arnd
Bergmann, Olof and others were answering Device Tree related questions.

My question, which precisely had the at91-adc DT binding in mind was
precisely whether we should use different compatible properties to
identify different revisions of an IP block and let the driver handle
those differences, or whether the DT binding should provide sufficient
properties (register offsets, bit numbers, etc.) to make the driver
independent of the IP revisions. And clearly, the answer was that
different compatible properties should be used to identify the
different versions of the IP block, and the driver should abstract out
the differences. I.e, was has been done for at91-adc is completely the
opposite of the best practices for Device Tree on ARM.

See
http://www.youtube.com/watch?v=zF_AXLgkFy4&feature=player_detailpage#t=1581s
where I ask exactly this question, and get answers from Olof Johansson
and Grant Likely. They clearly say that the solution of having separate
compatible properties and a driver that handles the differences is the
way to go. So the way at91-adc (and possibly other at91 drivers) is
using the Device Tree is wrong, there should have been multiple
compatible properties. It's a shame because this is something we did say
when we submitted at91-adc and during the reviews, but the maintainer
wasn't listening to our comments...

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From oleksandr.kozaruk at ti.com  Tue Jul 16 07:34:59 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Tue, 16 Jul 2013 14:34:59 +0300
Subject: [PATCH v4 1/2] ARM: dts: twl: Add GPADC data to device tree
Message-ID: <1373974500-23609-1-git-send-email-oleksandr.kozaruk@ti.com>

GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.

Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..434842c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
 		compatible = "ti,twl6030-pwmled";
 		#pwm-cells = <2>;
 	};
+
+	gpadc: twl6030_gpadc {
+		compatible = "ti,twl6030_gpadc";
+		interrupts = <3>;
+		#io-channel-cells = <1>;
+	};
 };
-- 
1.8.1.2



From oleksandr.kozaruk at ti.com  Tue Jul 16 07:35:00 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Tue, 16 Jul 2013 14:35:00 +0300
Subject: [PATCH v4 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <1373974500-23609-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1373974500-23609-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1373974500-23609-2-git-send-email-oleksandr.kozaruk@ti.com>

The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
known also as Phoenix and PhoenixLite.

The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
respectively. Some channels have current source and are used for
measuring voltage drop on resistive load for detecting battery ID
resistance, or measuring voltage drop on NTC resistors for external
temperature measurements. Some channels measure voltage, (i.e. battery
voltage), and have voltage dividers, thus, capable to scale voltage.
Some channels are dedicated for measuring die temperature.

Some channels are calibrated in 2 points, having offsets from ideal
values kept in trim registers. This is used to correct measurements.

The differences between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i.e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
Girish S Ghongdemath.

Signed-off-by: Balaji T K <balajitk at ti.com>
Signed-off-by: Graeme Gregory <gg at slimlogic.co.uk>
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 drivers/iio/adc/Kconfig         |   14 +
 drivers/iio/adc/Makefile        |    1 +
 drivers/iio/adc/twl6030-gpadc.c | 1008 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 1023 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index ab0767e6..3172461 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -150,6 +150,20 @@ config TI_AM335X_ADC
 	  Say yes here to build support for Texas Instruments ADC
 	  driver which is also a MFD client.
 
+config TWL6030_GPADC
+	tristate "TWL6030 GPADC (General Purpose A/D Converter) Support"
+	depends on TWL4030_CORE
+	default n
+	help
+	  Say yes here if you want support for the TWL6030/TWL6032 General
+	  Purpose A/D Converter. This will add support for battery type
+	  detection, battery voltage and temperature measurement, die
+	  temperature measurement, system supply voltage, audio accessory,
+	  USB ID detection.
+
+	  This driver can also be built as a module. If so, the module will be
+	  called twl6030-gpadc.
+
 config VIPERBOARD_ADC
 	tristate "Viperboard ADC support"
 	depends on MFD_VIPERBOARD && USB
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 0a825be..996ba09 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -16,4 +16,5 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
 obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
+obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
 obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
new file mode 100644
index 0000000..658f35b
--- /dev/null
+++ b/drivers/iio/adc/twl6030-gpadc.c
@@ -0,0 +1,1008 @@
+/*
+ * TWL6030 GPADC module driver
+ *
+ * Copyright (C) 2009-2013 Texas Instruments Inc.
+ * Nishant Kamat <nskamat at ti.com>
+ * Balaji T K <balajitk at ti.com>
+ * Graeme Gregory <gg at slimlogic.co.uk>
+ * Girish S Ghongdemath <girishsg at ti.com>
+ * Ambresh K <ambresh at ti.com>
+ * Oleksandr Kozaruk <oleksandr.kozaruk at ti.com
+ *
+ * Based on twl4030-madc.c
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen <mikko.k.ylinen at nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of_platform.h>
+#include <linux/i2c/twl.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define DRIVER_NAME		"twl6030_gpadc"
+
+#define TWL6030_GPADC_MAX_CHANNELS 17
+#define TWL6032_GPADC_MAX_CHANNELS 19
+
+#define TWL6030_GPADC_CTRL_P1			0x05
+
+#define TWL6032_GPADC_GPSELECT_ISB		0x07
+#define TWL6032_GPADC_CTRL_P1			0x08
+
+#define TWL6032_GPADC_GPCH0_LSB			0x0d
+#define TWL6032_GPADC_GPCH0_MSB			0x0e
+
+#define TWL6030_GPADC_CTRL_P1_SP1		BIT(3)
+
+#define TWL6030_GPADC_GPCH0_LSB			(0x29)
+
+#define TWL6030_GPADC_RT_SW1_EOC_MASK		BIT(5)
+
+#define TWL6030_GPADC_TRIM1			0xCD
+
+#define TWL6030_REG_TOGGLE1			0x90
+#define TWL6030_GPADCS				BIT(1)
+#define TWL6030_GPADCR				BIT(0)
+
+/**
+ * struct twl6030_chnl_calib - channel calibration
+ * @gain:		slope coefficient for ideal curve
+ * @gain_error:		gain error
+ * @offset_error:	offset of the real curve
+ */
+struct twl6030_chnl_calib {
+	s32 gain;
+	s32 gain_error;
+	s32 offset_error;
+};
+
+/**
+ * struct twl6030_ideal_code - GPADC calibration parameters
+ * GPADC is calibrated in two points: close to the beginning and
+ * to the and of the measurable input range
+ *
+ * @code1:	ideal code for the input at the beginning
+ * @code2:	ideal code for at the end of the range
+ * @volt1:	voltage input at the beginning(low voltage)
+ * @volt2:	voltage input at the end(high voltage)
+ */
+struct twl6030_ideal_code {
+	u16 code1;
+	u16 code2;
+	u16 volt1;
+	u16 volt2;
+};
+
+struct twl6030_gpadc_data;
+
+/**
+ * struct twl6030_gpadc_platform_data - platform specific data
+ * @nchannels:		number of GPADC channels
+ * @iio_channels:	iio channels
+ * @twl6030_ideal:	pointer to calibration parameters
+ * @start_conversion:	pointer to ADC start conversion function
+ * @channel_to_reg	pointer to ADC function to convert channel to
+ * 			register address for reading conversion result
+ * @calibrate:		pointer to calibration function
+ */
+struct twl6030_gpadc_platform_data {
+	const int nchannels;
+	const struct iio_chan_spec *iio_channels;
+	const struct twl6030_ideal_code *ideal;
+	int (*start_conversion)(int channel);
+	u8 (*channel_to_reg)(int channel);
+	int (*calibrate)(struct twl6030_gpadc_data *gpadc);
+};
+
+/**
+ * struct twl6030_gpadc_data - GPADC data
+ * @dev:		device pointer
+ * @lock:		mutual exclusion lock for the structure
+ * @irq_complete:	completion to signal end of conversion
+ * @twl6030_cal_tbl:	pointer to calibration data for each
+ * 			channel with gain error and offset
+ * @pdata:		pointer to device specific data
+ */
+struct twl6030_gpadc_data {
+	struct device	*dev;
+	struct mutex	lock;
+	struct completion	irq_complete;
+	struct twl6030_chnl_calib	*twl6030_cal_tbl;
+	const struct twl6030_gpadc_platform_data *pdata;
+};
+
+/*
+ * channels 11, 12, 13, 15 and 16 have no calibration data
+ * calibration offset is same for channels 1, 3, 4, 5
+ *
+ * The data is taken from GPADC_TRIM registers description.
+ * GPADC_TRIM registers keeps difference between the code measured
+ * at volt1 and volt2 input voltages and corresponding code1 and code2
+ */
+static const struct twl6030_ideal_code
+	twl6030_ideal[TWL6030_GPADC_MAX_CHANNELS] = {
+	[0] = { /* ch 0, external, battery type, resistor value */
+		.code1 = 116,
+		.code2 = 745,
+		.volt1 = 141,
+		.volt2 = 910,
+	},
+	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[2] = { /* ch 2, external, audio accessory/general purpose */
+		.code1 = 55,
+		.code2 = 818,
+		.volt1 = 101,
+		.volt2 = 1499,
+	},
+	[3] = { /* ch 3, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[4] = { /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[5] = { /* ch 5, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[6] = { /* ch 6, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[7] = { /* ch 7, internal, main battery */
+		.code1 = 614,
+		.code2 = 941,
+		.volt1 = 3001,
+		.volt2 = 4599,
+	},
+	[8] = { /* ch 8, internal, backup battery */
+		.code1 = 82,
+		.code2 = 688,
+		.volt1 = 501,
+		.volt2 = 4203,
+	},
+	[9] = { /* ch 9, internal, external charger input */
+		.code1 = 182,
+		.code2 = 818,
+		.volt1 = 2001,
+		.volt2 = 8996,
+	},
+	[10] = { /* ch 10, internal, VBUS */
+		.code1 = 149,
+		.code2 = 818,
+		.volt1 = 1001,
+		.volt2 = 5497,
+	},
+	[11] = {},	/* ch 11, internal, VBUS charging current */
+	[12] = {},	/* ch 12, internal, Die temperature */
+	[13] = {},	/* ch 13, internal, Die temperature */
+	[14] = { /* ch 14, internal, USB ID line */
+		.code1 = 48,
+		.code2 = 714,
+		.volt1 = 323,
+		.volt2 = 4800,
+	},
+	[15] = {},	/* ch 15, internal, test network */
+	[16] = {},	/* ch 16, internal, test network */
+};
+
+static const struct twl6030_ideal_code
+			twl6032_ideal[TWL6032_GPADC_MAX_CHANNELS] = {
+	[0] = { /* ch 0, external, battery type, resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[2] = { /* ch 2, external, audio accessory/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 660,
+		.volt2 = 1500,
+	},
+	[3] = { /* ch 3, external, temperature with external diode/general
+								purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[4] = { /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[5] = { /* ch 5, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[6] = { /* ch 6, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[7] = { /* ch7, internal, system supply */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+	[8] = { /* ch8, internal, backup battery */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+	[9] = { /* ch 9, internal, external charger input */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 3960,
+		.volt2 = 9000,
+	},
+	[10] = { /* ch10, internal, VBUS */
+		.code1 = 150,
+		.code2 = 751,
+		.volt1 = 1000,
+		.volt2 = 5000,
+	},
+	[11] = { /* ch 11, internal, VBUS DC-DC output current */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 660,
+		.volt2 = 1500,
+	},
+	[12] = { /* ch 12, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[13] = { /* ch 13, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[14] = { /* ch 14, internal, USB ID line */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2420,
+		.volt2 = 5500,
+	},
+	[15] = {},	/* ch 15, internal, test network */
+	[16] = {},	/* ch 16, internal, test network */
+	[17] = {},	/* ch 17, internal, battery charging current */
+	[18] = { /* ch 18, internal, battery voltage */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+};
+
+static inline int twl6030_gpadc_write(u8 reg, u8 val)
+{
+	return twl_i2c_write_u8(TWL6030_MODULE_GPADC, val, reg);
+}
+
+static inline int twl6030_gpadc_read(u8 reg, u8 *val)
+{
+
+	return twl_i2c_read(TWL6030_MODULE_GPADC, val, reg, 2);
+}
+
+static int twl6030_gpadc_enable_irq(u8 mask)
+{
+	int ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_LINE_B);
+	if (ret < 0)
+		return ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_STS_B);
+
+	return ret;
+}
+
+static void twl6030_gpadc_disable_irq(u8 mask)
+{
+	twl6030_interrupt_mask(mask, REG_INT_MSK_LINE_B);
+	twl6030_interrupt_mask(mask, REG_INT_MSK_STS_B);
+}
+
+static irqreturn_t twl6030_gpadc_irq_handler(int irq, void *_gpadc)
+{
+	struct twl6030_gpadc_data *gpadc = _gpadc;
+
+	complete(&gpadc->irq_complete);
+
+	return IRQ_HANDLED;
+}
+
+static int twl6030_start_conversion(int channel)
+{
+	return twl6030_gpadc_write(TWL6030_GPADC_CTRL_P1,
+					TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static int twl6032_start_conversion(int channel)
+{
+	int ret;
+
+	ret = twl6030_gpadc_write(TWL6032_GPADC_GPSELECT_ISB, channel);
+	if (ret)
+		return ret;
+
+	return twl6030_gpadc_write(TWL6032_GPADC_CTRL_P1,
+						TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static u8 twl6030_channel_to_reg(int channel)
+{
+	return TWL6030_GPADC_GPCH0_LSB + 2 * channel;
+}
+
+static u8 twl6032_channel_to_reg(int channel)
+{
+	/*
+	 * for any prior chosen channel, when the conversion is ready
+	 * the result is avalable in GPCH0_LSB, GPCH0_MSB.
+	 */
+
+	return TWL6032_GPADC_GPCH0_LSB;
+}
+
+static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
+		int channel, int *res)
+{
+	u8 reg = gpadc->pdata->channel_to_reg(channel);
+	__le16 val;
+	int ret;
+
+	ret = twl6030_gpadc_read(reg, (u8 *)&val);
+	if (ret) {
+		dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
+		return ret;
+	}
+
+	*res = le16_to_cpup(&val);
+
+	return ret;
+}
+
+static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
+		int channel, int *val)
+{
+	int raw_code;
+	int corrected_code;
+	int channel_value;
+	int ret;
+
+	ret = twl6030_gpadc_get_raw(gpadc, channel, &raw_code);
+	if (ret)
+		return ret;
+
+	corrected_code = ((raw_code * 1000) -
+		gpadc->twl6030_cal_tbl[channel].offset_error) /
+		gpadc->twl6030_cal_tbl[channel].gain_error;
+
+	channel_value = corrected_code *
+			gpadc->twl6030_cal_tbl[channel].gain;
+
+	/* Shift back into mV range */
+	channel_value /= 1000;
+
+	dev_dbg(gpadc->dev, "GPADC raw code: %d", raw_code);
+	dev_dbg(gpadc->dev, "GPADC corrected code: %d", corrected_code);
+	dev_dbg(gpadc->dev, "GPADC value: %d", channel_value);
+
+	*val = channel_value;
+
+	return ret;
+}
+
+static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
+			     const struct iio_chan_spec *chan,
+			     int *val, int *val2, long mask)
+{
+	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
+	int ret = -EINVAL;
+	long timeout;
+
+	mutex_lock(&gpadc->lock);
+
+	ret = gpadc->pdata->start_conversion(chan->channel);
+	if (ret) {
+		dev_err(gpadc->dev, "failed to start conversion\n");
+		goto err;
+	}
+	/* wait for conversion to complete */
+	timeout = wait_for_completion_interruptible_timeout(
+				&gpadc->irq_complete, msecs_to_jiffies(5000));
+	if (!timeout)
+		return -ETIMEDOUT;
+	else if (timeout < 0)
+		return EINTR;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	case IIO_CHAN_INFO_PROCESSED:
+		ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	default:
+		break;
+	}
+err:
+	mutex_unlock(&gpadc->lock);
+
+	return ret;
+}
+
+/*
+ * The GPADC channels are calibrated using a two point calibration method.
+ * The channels measured with two known values: volt1 and volt2, and
+ * ideal corresponding output codes are known: code1, code2.
+ * The difference(d1, d2) between ideal and measured codes stored in trim
+ * registers.
+ * The goal is to find offset and gain of the real curve for each calibrated
+ * channel.
+ * gain: k = 1 + ((d2 - d1) / (x2 - x1))
+ * offset: b = d1 + (k - 1) * x1
+ */
+static void twl6030_calibrate_channel(struct twl6030_gpadc_data *gpadc,
+					int channel, int d1, int d2)
+{
+	int b, k, gain, x1, x2;
+	const struct twl6030_ideal_code *ideal = gpadc->pdata->ideal;
+
+	/* Gain */
+	gain = ((ideal[channel].volt2 - ideal[channel].volt1) * 1000) /
+		(ideal[channel].code2 - ideal[channel].code1);
+
+	x1 = ideal[channel].code1;
+	x2 = ideal[channel].code2;
+
+	/* k - real curve gain */
+	k = 1000 + (((d2 - d1) * 1000) / (x2 - x1));
+
+	/* b - offset of the real curve gain */
+	b = (d1 * 1000) - (k - 1000) * x1;
+
+	gpadc->twl6030_cal_tbl[channel].gain = gain;
+	gpadc->twl6030_cal_tbl[channel].gain_error = k;
+	gpadc->twl6030_cal_tbl[channel].offset_error = b;
+
+	dev_dbg(gpadc->dev, "GPADC d1   for Chn: %d = %d\n", channel, d1);
+	dev_dbg(gpadc->dev, "GPADC d2   for Chn: %d = %d\n", channel, d2);
+	dev_dbg(gpadc->dev, "GPADC x1   for Chn: %d = %d\n", channel, x1);
+	dev_dbg(gpadc->dev, "GPADC x2   for Chn: %d = %d\n", channel, x2);
+	dev_dbg(gpadc->dev, "GPADC Gain for Chn: %d = %d\n", channel, gain);
+	dev_dbg(gpadc->dev, "GPADC k    for Chn: %d = %d\n", channel, k);
+	dev_dbg(gpadc->dev, "GPADC b    for Chn: %d = %d\n", channel, b);
+}
+
+static inline int twl6030_gpadc_get_trim_offset(s8 d)
+{
+	/*
+	 * XXX NOTE!
+	 * bit 0 - sign, bit 7 - reserved, 6..1 - trim value
+	 * though, the documentation states that trim value
+	 * is absolute value, the correct conversion results are
+	 * obtained if the value is interpreted as 2's complement.
+	 */
+	__u32 temp = ((d & 0x7f) >> 1) | ((d & 1) << 6);
+
+	return sign_extend32(temp, 6);
+}
+
+static int twl6030_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int ret;
+	int chn;
+	u8 trim_regs[TWL6030_GPADC_MAX_CHANNELS];
+	s8 d1, d2;
+
+	/*
+	 * for calibration two measurements have been performed at
+	 * factory, for some channels, during the production test and
+	 * have been stored in registers. This two stored values are
+	 * used to correct the measurements. The values represent
+	 * offsets for the given input from the output on ideal curve.
+	 */
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs,
+			TWL6030_GPADC_TRIM1, 16);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	for (chn = 0; chn < TWL6030_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+			d1 = trim_regs[0];
+			d2 = trim_regs[1];
+			break;
+		case 1:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+			d1 = trim_regs[4];
+			d2 = trim_regs[5];
+			break;
+		case 2:
+			d1 = trim_regs[12];
+			d2 = trim_regs[13];
+			break;
+		case 7:
+			d1 = trim_regs[6];
+			d2 = trim_regs[7];
+			break;
+		case 8:
+			d1 = trim_regs[2];
+			d2 = trim_regs[3];
+			break;
+		case 9:
+			d1 = trim_regs[8];
+			d2 = trim_regs[9];
+			break;
+		case 10:
+			d1 = trim_regs[10];
+			d2 = trim_regs[11];
+			break;
+		case 14:
+			d1 = trim_regs[14];
+			d2 = trim_regs[15];
+			break;
+		default:
+			continue;
+		}
+
+		d1 = twl6030_gpadc_get_trim_offset(d1);
+		d2 = twl6030_gpadc_get_trim_offset(d2);
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int chn, d1 = 0, d2 = 0, temp;
+	u8 trim_regs[17];
+	int ret;
+
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
+			TWL6030_GPADC_TRIM1, 16);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	/*
+	 * Loop to calculate the value needed for returning voltages from
+	 * GPADC not values.
+	 *
+	 * gain is calculated to 3 decimal places fixed point.
+	 */
+	for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+		case 1:
+		case 2:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+		case 11:
+		case 12:
+		case 13:
+		case 14:
+			/* D1 */
+			d1 = (trim_regs[3] & 0x1F) << 2;
+			d1 |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				d1 = -d1;
+
+			/* D2 */
+			d2 = (trim_regs[4] & 0x3F) << 2;
+			d2 |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				d2 = -d2;
+			break;
+		case 8:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[8] & 0x18) << 1;
+			d1 |= (trim_regs[7] & 0x1E) >> 1;
+			if (trim_regs[7] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[10] & 0x1F) << 2;
+			d2 |= (trim_regs[8] & 0x06) >> 1;
+			if (trim_regs[8] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		case 9:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[14] & 0x18) << 1;
+			d1 |= (trim_regs[12] & 0x1E) >> 1;
+			if (trim_regs[12] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[16] & 0x1F) << 2;
+			d2 |= (trim_regs[14] & 0x06) >> 1;
+			if (trim_regs[14] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+		case 10:
+			/* D1 */
+			d1 = (trim_regs[11] & 0x0F) << 3;
+			d1 |= (trim_regs[9] & 0x0E) >> 1;
+			if (trim_regs[9] & 0x01)
+				d1 = -d1;
+
+			/* D2 */
+			d2 = (trim_regs[15] & 0x0F) << 3;
+			d2 |= (trim_regs[13] & 0x0E) >> 1;
+			if (trim_regs[13] & 0x01)
+				d2 = -d2;
+			break;
+		case 7:
+		case 18:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[5] & 0x7E) >> 1;
+			if (trim_regs[5] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[6] & 0xFE) >> 1;
+			if (trim_regs[6] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		default:
+			/* No data for other channels */
+			continue;
+		}
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+#define TWL6030_GPADC_CHAN(chn, chan_info) {		\
+	.type = IIO_VOLTAGE,				\
+	.channel = chn,					\
+	.info_mask = BIT(chan_info),			\
+	.info_mask_separate = BIT(chan_info), 		\
+	.indexed = 1,					\
+}
+
+/* internal test network channel */
+#define TWL6030_GPADC_TEST_CHAN(chn, chan_info) {	\
+	.type = IIO_VOLTAGE,				\
+	.channel = chn,					\
+	.info_mask = BIT(chan_info),			\
+	.indexed = 1,					\
+}
+
+static const struct iio_chan_spec twl6030_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(2, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(5, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(12, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(13, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(14, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_TEST_CHAN(15, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_TEST_CHAN(16, IIO_CHAN_INFO_RAW),
+};
+
+static const struct iio_chan_spec twl6032_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(2, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(5, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(12, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(13, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(14, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_TEST_CHAN(15, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_TEST_CHAN(16, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(17, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(18, IIO_CHAN_INFO_PROCESSED),
+};
+
+static const struct iio_info twl6030_gpadc_iio_info = {
+	.read_raw = &twl6030_gpadc_read_raw,
+	.driver_module = THIS_MODULE,
+};
+
+static const struct twl6030_gpadc_platform_data twl6030_pdata = {
+	.iio_channels = twl6030_gpadc_iio_channels,
+	.nchannels = TWL6030_GPADC_MAX_CHANNELS,
+	.ideal = twl6030_ideal,
+	.start_conversion = twl6030_start_conversion,
+	.channel_to_reg = twl6030_channel_to_reg,
+	.calibrate = twl6030_calibration,
+};
+
+static const struct twl6030_gpadc_platform_data twl6032_pdata = {
+	.iio_channels = twl6032_gpadc_iio_channels,
+	.nchannels = TWL6032_GPADC_MAX_CHANNELS,
+	.ideal = twl6032_ideal,
+	.start_conversion = twl6032_start_conversion,
+	.channel_to_reg = twl6032_channel_to_reg,
+	.calibrate = twl6032_calibration,
+};
+
+static const struct of_device_id of_twl6030_match_tbl[] = {
+	{
+		.compatible = "ti,twl6030_gpadc",
+		.data = &twl6030_pdata,
+	},
+	{
+		.compatible = "ti,twl6032_gpadc",
+		.data = &twl6032_pdata,
+	},
+	{ /* end */ }
+};
+
+static int twl6030_gpadc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct twl6030_gpadc_data *gpadc;
+	const struct twl6030_gpadc_platform_data *pdata;
+	const struct of_device_id *match;
+	struct iio_dev *indio_dev;
+	int irq;
+	int ret;
+
+	match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
+	pdata = match ? match->data : dev->platform_data;
+
+	if (!pdata)
+		return -EINVAL;
+
+	indio_dev = iio_device_alloc(sizeof(*gpadc));
+	if (!indio_dev) {
+		dev_err(dev, "failed allocating iio device\n");
+		ret = -ENOMEM;
+	}
+
+	gpadc = iio_priv(indio_dev);
+
+	gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
+					sizeof(struct twl6030_chnl_calib) *
+					pdata->nchannels, GFP_KERNEL);
+	if (!gpadc->twl6030_cal_tbl)
+		goto err_free_device;
+
+	gpadc->dev = dev;
+	gpadc->pdata = pdata;
+
+	platform_set_drvdata(pdev, indio_dev);
+	mutex_init(&gpadc->lock);
+	init_completion(&gpadc->irq_complete);
+
+	ret = pdata->calibrate(gpadc);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to read calibration registers\n");
+		goto err_free_device;
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "failed to get irq\n");
+		goto err_free_device;
+	}
+
+	ret = request_threaded_irq(irq, NULL, twl6030_gpadc_irq_handler,
+				IRQF_ONESHOT, "twl6030_gpadc", gpadc);
+	if (ret) {
+		dev_dbg(&pdev->dev, "could not request irq\n");
+		goto err_free_device;
+	}
+
+	ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
+		goto err_free_irq;
+	}
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+					TWL6030_REG_TOGGLE1);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC module\n");
+		goto err_free_irq;
+	}
+
+	indio_dev->name = DRIVER_NAME;
+	indio_dev->dev.parent = dev;
+	indio_dev->info = &twl6030_gpadc_iio_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->channels = pdata->iio_channels;
+	indio_dev->num_channels = pdata->nchannels;
+
+	ret = iio_device_register(indio_dev);
+	if (ret)
+		goto err_free_irq;
+
+	return ret;
+
+err_free_irq:
+	free_irq(irq, indio_dev);
+err_free_device:
+	iio_device_free(indio_dev);
+
+	return ret;
+}
+
+static int twl6030_gpadc_remove(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+
+	twl6030_gpadc_disable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	free_irq(platform_get_irq(pdev, 0), indio_dev);
+	iio_device_unregister(indio_dev);
+	iio_device_free(indio_dev);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int twl6030_gpadc_suspend(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCR,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error reseting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+
+static int twl6030_gpadc_resume(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error setting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+#endif
+
+SIMPLE_DEV_PM_OPS(twl6030_gpadc_pm_ops, twl6030_gpadc_suspend,
+					twl6030_gpadc_resume);
+
+static struct platform_driver twl6030_gpadc_driver = {
+	.probe		= twl6030_gpadc_probe,
+	.remove		= twl6030_gpadc_remove,
+	.driver		= {
+		.name	= DRIVER_NAME,
+		.owner	= THIS_MODULE,
+		.pm	= &twl6030_gpadc_pm_ops,
+		.of_match_table = of_twl6030_match_tbl,
+	},
+};
+
+module_platform_driver(twl6030_gpadc_driver);
+
+MODULE_ALIAS("platform: " DRIVER_NAME);
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_DESCRIPTION("twl6030 ADC driver");
+MODULE_LICENSE("GPL");
-- 
1.8.1.2



From maxime.ripard at free-electrons.com  Tue Jul 16 07:43:05 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 16 Jul 2013 13:43:05 +0200
Subject: [PATCH 5/5] iio: at91: introduce touch screen support in iio adc
 driver
In-Reply-To: <51E50DCC.4010107@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-6-git-send-email-josh.wu@atmel.com>
 <20130715131507.GE2962@lukather> <51E50DCC.4010107@atmel.com>
Message-ID: <20130716114305.GD3125@lukather>

Hi Josh,

On Tue, Jul 16, 2013 at 05:09:32PM +0800, Josh Wu wrote:
> On 7/15/2013 9:15 PM, Maxime Ripard wrote:
> >Hi Josh,
> >
> >On Sun, Jul 14, 2013 at 04:04:29PM +0800, Josh Wu wrote:
> >>AT91 ADC hardware integrate touch screen support. So this patch add touch
> >>screen support for at91 adc iio driver.
> >>To enable touch screen support in adc, you need to add the dt parameters:
> >>   which type of touch are used? (4 or 5 wires), sample period time,
> >>   pen detect debounce time, average samples and pen detect resistor.
> >>
> >>In the meantime, since touch screen will use a interal period trigger of adc,
> >>so it is conflict to other hardware triggers. Driver will disable the hardware
> >>trigger support if touch screen is enabled.
> >>
> >>This driver has been tested in AT91SAM9X5-EK and SAMA5D3x-EK.
> >>
> >>Signed-off-by: Josh Wu <josh.wu at atmel.com>
> >>Cc: Dmitry Torokhov <dmitry.torokhov at gmail.com>
> >>---
> >>  .../devicetree/bindings/arm/atmel-adc.txt          |   13 +
> >>  arch/arm/mach-at91/include/mach/at91_adc.h         |   34 ++
> >>  drivers/iio/adc/at91_adc.c                         |  389 ++++++++++++++++++--
> >>  3 files changed, 412 insertions(+), 24 deletions(-)
> >>
> >>diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> >>index 0db2945..925d656 100644
> >>--- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
> >>+++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> >>@@ -29,6 +29,19 @@ Optional properties:
> >>    - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
> >>    - atmel,adc-clock-rate: ADC clock rate. If not specified, use the default
> >>  			  adc_op_clk.
> >>+  - atmel,adc-touchscreen-wires: Number of touch screen wires. Only support
> >>+				 4 and 5 wires touch screen.
> >>+    NOTE: when adc touch screen enabled, the adc hardware trigger will be
> >>+          disabled. Since touch screen will occupied the trigger register.
> >>+  - atmel,adc-ts-pendet-debounce: Debounce time in microsecond for touch pen
> >>+				  detect.
> >>+  - atmel,adc-ts-sample-period-time: Sample Period Time in microsecond for
> >>+				     touch screen
> >>+  - atmel,adc-ts-filter-average: Numbers of sampling data will be averaged.
> >>+    0 means no average. 1 means average two samples. 2 means average four
> >>+    samples. 3 means average eight samples.
> >>+  - atmel,adc-ts-pendet-sensitivity: Pen Detection input pull-up resistor.
> >>+    It can be 0, 1, 2, 3.
> >Could you expand a bit on what are these properties for? Are they
> >board-specific? IP-specific?
> 
> +  - atmel,adc-touchscreen-wires: Number of touch screen wires. Only support
> +                 4 and 5 wires touch screen.
> +    NOTE: when adc touch screen enabled, the adc hardware trigger will be
> +          disabled. Since touch screen will occupied the trigger register.
> 
> It is board specific. Currently in AT91SAM9M10G45EK, AT91SAM9X5-EK,
> SAMA5D3x-EK all use 4 wire touch.
> Now the driver not support 5 wire yet.

I see, maybe you should add this in the documentation then

> +  - atmel,adc-ts-pendet-debounce: Debounce time in microsecond for
> touch pen
> +                  detect.
> 
> de-glitch time for pen detect. Board specific.
> 
> +  - atmel,adc-ts-sample-period-time: Sample Period Time in microsecond for
> +                     touch screen
> 
> The period to sample a touch data after pen is touched. Board specific.
> 
> +  - atmel,adc-ts-filter-average: Numbers of sampling data will be averaged.
> +    0 means no average. 1 means average two samples. 2 means average four
> +    samples. 3 means average eight samples.
> +  - atmel,adc-ts-pendet-sensitivity: Pen Detection input pull-up resistor.
> +    It can be 0, 1, 2, 3.
> 
> Above two properties only supported in SAM9X5, SAMA5D3 IP.

Ok, that should go to the documentation as well. What do the values of
atmel,adc-ts-pendet-sensitivity correspond to?

> >>@@ -104,14 +140,10 @@ static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
> >>  	return IRQ_HANDLED;
> >>  }
> >>-static irqreturn_t at91_adc_eoc_trigger(int irq, void *private)
> >>+/* Handler for classic adc channel eoc trigger */
> >>+void handle_adc_eoc_trigger(int irq, struct iio_dev *idev)
> >>  {
> >>-	struct iio_dev *idev = private;
> >>  	struct at91_adc_state *st = iio_priv(idev);
> >>-	u32 status = at91_adc_readl(st, st->registers->status_register);
> >>-
> >>-	if (!(status & st->registers->drdy_mask))
> >>-		return IRQ_HANDLED;
> >Why are you changing the prototype and remove most of the useful part
> >out of the handler?
> 
> I change the protype because I make it as a sub interrupt handler.
> Since I just add a new interrupt handler which will check the
> interrupt type, if DRDY interrupt is coming, it will call your
> original handler.
> Otherwise use touch screen interrupt handler code.
> 
> Following is the new interrupt handler code in this patch:
> 
> +static irqreturn_t at91_adc_interrupt(int irq, void *private)
> +{
> +	struct iio_dev *idev = private;
> +	struct at91_adc_state *st = iio_priv(idev);
> +	u32 status = at91_adc_readl(st, st->registers->status_register);
> +	const uint32_t ts_data_irq_mask =
> +		AT91_ADC_IER_XRDY |
> +		AT91_ADC_IER_YRDY |
> +		AT91_ADC_IER_PRDY;
> +
> +	if (status & st->registers->drdy_mask)
> +		handle_adc_eoc_trigger(irq, idev);
> 
>                              ^
>                              |
> here we call original trigger handler.
> 
> +
> +	if (status & AT91_ADC_IER_PEN) {
> +		at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_PEN);
> +		at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_NOPEN |
> +			ts_data_irq_mask);
> +		/* Set up period trigger for sampling */
> +		at91_adc_writel(st, st->registers->trigger_register,
> +			AT91_ADC_TRGR_MOD_PERIOD_TRIG |
> +			AT91_ADC_TRGR_TRGPER_(st->ts_sample_period_val));
> +	} else if (status & AT91_ADC_IER_NOPEN) {
> +		at91_adc_writel(st, st->registers->trigger_register, 0);
> +		at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_NOPEN |
> +			ts_data_irq_mask);
> +		at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_PEN);
> +
> +		input_report_key(st->ts_input, BTN_TOUCH, 0);
> +		input_sync(st->ts_input);
> +	} else if ((status & ts_data_irq_mask) == ts_data_irq_mask) {
> 
> Those code will handle for the Touch screen interrupt.

Ah, right.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130716/ccb648f8/attachment.sig>

From juha.lumme at gmail.com  Tue Jul 16 07:44:43 2013
From: juha.lumme at gmail.com (Juha Lumme)
Date: Tue, 16 Jul 2013 20:44:43 +0900
Subject: Can't get FIQ interrupt to work on i.mx233
In-Reply-To: <20130716081132.GB24642@n2100.arm.linux.org.uk>
References: <CAF-Ht3z3GQLwEWoB+UgOGepHfMFUD7pTRHfYWR9Ynk3rM4dD=Q@mail.gmail.com>
 <20130716081132.GB24642@n2100.arm.linux.org.uk>
Message-ID: <51E5322B.8080602@gmail.com>

Hi Russel,

Thanks for your reply.
And thanks for pointing out the wrong instruction there with the ldr 
instruction.

However, unfortunately the code still doesn't seem to trigger anything 
(neither to clear the IRQ bit in the timer, nor the GPIO output).. It 
seems to me as if the handler never gets called. Is there a good way to 
confirm that any activity is actually triggered when timer3 reaches 0, 
and the IRQ bit is set to 1 ?

Best regards,
Juha

On 07/16/2013 05:11 PM, Russell King - ARM Linux wrote:
> On Tue, Jul 16, 2013 at 10:59:22AM +0900, Juha Lumme wrote:
>> For now the assembly handler is only 6 instructions: http://codetidy.com/6193/
>> I first want to just clear the interrupt bit in HW_ICOLL_INTERRUPT31,
>> and then I write 0xFF to HW_PINCTRL_DOUT1
> Unfortunately, the code doesn't match your description.  You set r10 to
> 0xff, and then _load_ the value from the address at r8 into r10.
>
> Maybe that ldr r10, [r8] should be str r10, [r8] ?



From oleksandr.kozaruk at ti.com  Tue Jul 16 07:47:32 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Tue, 16 Jul 2013 14:47:32 +0300
Subject: [PATCH v4 0/2] TWL6030, TWL6032 GPADC driver
Message-ID: <1373975254-23764-1-git-send-email-oleksandr.kozaruk@ti.com>

Hello,

v4 - addressed comments: fixed style violation, bug in freeing memory,
     added comments explaining calibration method, removed test network
     channels from exposing to userspace, error handling for 
     wait_for_complition
v3 - fixed compiler warning
v2 - the driver put in drivers/iio, and
converted using iio facilities as suggested by Graeme.

TWL603[02] GPADC is used to measure battery voltage,
battery temperature, battery presence ID, and could
be used to measure twl603[02] die temperature.
This is used on TI blaze, blaze tablet platforms.

The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19
channels respectively. Some channels have current
source and are used for measuring voltage drop
on resistive load for detecting battery ID resistance,
or measuring voltage drop on NTC resistors for external
temperature measurements, other channels measure voltage,
(i.e. battery voltage), and have inbuilt voltage dividers,
thus, capable to scale voltage. Some channels are dedicated
for measuring die temperature.

Some channels could be calibrated in 2 points, having
offsets from ideal values in trim registers.

The difference between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i. e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

The driver is derived from git://git.omapzoom.org/kernel/omap.git
The original driver's authors and contributors are Balaji T K,
Graeme Gregory, Ambresh K, Girish S Ghongdemath.

The changes to the original driver:
- device tree adaptation;
- drop ioctl support - never been used;
- unified measurement method for both devices;
- get rid of "if (device == X)" code style to data driven;
- drop polling end of conversion and use interrupt instead;
- iio framework is used

Tested with on blaze tablet 2 with OMAP4430(twl6030), and
OMAP4470(twl6032) SOMs.

The patches were tested against 3.10-rc7

Oleksandr Kozaruk (2):
  ARM: dts: twl: Add GPADC data to device tree
  iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

 arch/arm/boot/dts/twl6030.dtsi  |    6 +
 drivers/iio/adc/Kconfig         |   14 +
 drivers/iio/adc/Makefile        |    1 +
 drivers/iio/adc/twl6030-gpadc.c | 1008 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 1029 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

-- 
1.8.1.2



From oleksandr.kozaruk at ti.com  Tue Jul 16 07:47:33 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Tue, 16 Jul 2013 14:47:33 +0300
Subject: [PATCH v4 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <1373975254-23764-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1373975254-23764-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1373975254-23764-2-git-send-email-oleksandr.kozaruk@ti.com>

GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.

Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..434842c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
 		compatible = "ti,twl6030-pwmled";
 		#pwm-cells = <2>;
 	};
+
+	gpadc: twl6030_gpadc {
+		compatible = "ti,twl6030_gpadc";
+		interrupts = <3>;
+		#io-channel-cells = <1>;
+	};
 };
-- 
1.8.1.2



From oleksandr.kozaruk at ti.com  Tue Jul 16 07:47:34 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Tue, 16 Jul 2013 14:47:34 +0300
Subject: [PATCH v4 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <1373975254-23764-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1373975254-23764-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1373975254-23764-3-git-send-email-oleksandr.kozaruk@ti.com>

The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
known also as Phoenix and PhoenixLite.

The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
respectively. Some channels have current source and are used for
measuring voltage drop on resistive load for detecting battery ID
resistance, or measuring voltage drop on NTC resistors for external
temperature measurements. Some channels measure voltage, (i.e. battery
voltage), and have voltage dividers, thus, capable to scale voltage.
Some channels are dedicated for measuring die temperature.

Some channels are calibrated in 2 points, having offsets from ideal
values kept in trim registers. This is used to correct measurements.

The differences between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i.e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
Girish S Ghongdemath.

Signed-off-by: Balaji T K <balajitk at ti.com>
Signed-off-by: Graeme Gregory <gg at slimlogic.co.uk>
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 drivers/iio/adc/Kconfig         |   14 +
 drivers/iio/adc/Makefile        |    1 +
 drivers/iio/adc/twl6030-gpadc.c | 1008 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 1023 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index ab0767e6..3172461 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -150,6 +150,20 @@ config TI_AM335X_ADC
 	  Say yes here to build support for Texas Instruments ADC
 	  driver which is also a MFD client.
 
+config TWL6030_GPADC
+	tristate "TWL6030 GPADC (General Purpose A/D Converter) Support"
+	depends on TWL4030_CORE
+	default n
+	help
+	  Say yes here if you want support for the TWL6030/TWL6032 General
+	  Purpose A/D Converter. This will add support for battery type
+	  detection, battery voltage and temperature measurement, die
+	  temperature measurement, system supply voltage, audio accessory,
+	  USB ID detection.
+
+	  This driver can also be built as a module. If so, the module will be
+	  called twl6030-gpadc.
+
 config VIPERBOARD_ADC
 	tristate "Viperboard ADC support"
 	depends on MFD_VIPERBOARD && USB
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 0a825be..996ba09 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -16,4 +16,5 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
 obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
+obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
 obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
new file mode 100644
index 0000000..658f35b
--- /dev/null
+++ b/drivers/iio/adc/twl6030-gpadc.c
@@ -0,0 +1,1008 @@
+/*
+ * TWL6030 GPADC module driver
+ *
+ * Copyright (C) 2009-2013 Texas Instruments Inc.
+ * Nishant Kamat <nskamat at ti.com>
+ * Balaji T K <balajitk at ti.com>
+ * Graeme Gregory <gg at slimlogic.co.uk>
+ * Girish S Ghongdemath <girishsg at ti.com>
+ * Ambresh K <ambresh at ti.com>
+ * Oleksandr Kozaruk <oleksandr.kozaruk at ti.com
+ *
+ * Based on twl4030-madc.c
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen <mikko.k.ylinen at nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of_platform.h>
+#include <linux/i2c/twl.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define DRIVER_NAME		"twl6030_gpadc"
+
+#define TWL6030_GPADC_MAX_CHANNELS 17
+#define TWL6032_GPADC_MAX_CHANNELS 19
+
+#define TWL6030_GPADC_CTRL_P1			0x05
+
+#define TWL6032_GPADC_GPSELECT_ISB		0x07
+#define TWL6032_GPADC_CTRL_P1			0x08
+
+#define TWL6032_GPADC_GPCH0_LSB			0x0d
+#define TWL6032_GPADC_GPCH0_MSB			0x0e
+
+#define TWL6030_GPADC_CTRL_P1_SP1		BIT(3)
+
+#define TWL6030_GPADC_GPCH0_LSB			(0x29)
+
+#define TWL6030_GPADC_RT_SW1_EOC_MASK		BIT(5)
+
+#define TWL6030_GPADC_TRIM1			0xCD
+
+#define TWL6030_REG_TOGGLE1			0x90
+#define TWL6030_GPADCS				BIT(1)
+#define TWL6030_GPADCR				BIT(0)
+
+/**
+ * struct twl6030_chnl_calib - channel calibration
+ * @gain:		slope coefficient for ideal curve
+ * @gain_error:		gain error
+ * @offset_error:	offset of the real curve
+ */
+struct twl6030_chnl_calib {
+	s32 gain;
+	s32 gain_error;
+	s32 offset_error;
+};
+
+/**
+ * struct twl6030_ideal_code - GPADC calibration parameters
+ * GPADC is calibrated in two points: close to the beginning and
+ * to the and of the measurable input range
+ *
+ * @code1:	ideal code for the input at the beginning
+ * @code2:	ideal code for at the end of the range
+ * @volt1:	voltage input at the beginning(low voltage)
+ * @volt2:	voltage input at the end(high voltage)
+ */
+struct twl6030_ideal_code {
+	u16 code1;
+	u16 code2;
+	u16 volt1;
+	u16 volt2;
+};
+
+struct twl6030_gpadc_data;
+
+/**
+ * struct twl6030_gpadc_platform_data - platform specific data
+ * @nchannels:		number of GPADC channels
+ * @iio_channels:	iio channels
+ * @twl6030_ideal:	pointer to calibration parameters
+ * @start_conversion:	pointer to ADC start conversion function
+ * @channel_to_reg	pointer to ADC function to convert channel to
+ * 			register address for reading conversion result
+ * @calibrate:		pointer to calibration function
+ */
+struct twl6030_gpadc_platform_data {
+	const int nchannels;
+	const struct iio_chan_spec *iio_channels;
+	const struct twl6030_ideal_code *ideal;
+	int (*start_conversion)(int channel);
+	u8 (*channel_to_reg)(int channel);
+	int (*calibrate)(struct twl6030_gpadc_data *gpadc);
+};
+
+/**
+ * struct twl6030_gpadc_data - GPADC data
+ * @dev:		device pointer
+ * @lock:		mutual exclusion lock for the structure
+ * @irq_complete:	completion to signal end of conversion
+ * @twl6030_cal_tbl:	pointer to calibration data for each
+ * 			channel with gain error and offset
+ * @pdata:		pointer to device specific data
+ */
+struct twl6030_gpadc_data {
+	struct device	*dev;
+	struct mutex	lock;
+	struct completion	irq_complete;
+	struct twl6030_chnl_calib	*twl6030_cal_tbl;
+	const struct twl6030_gpadc_platform_data *pdata;
+};
+
+/*
+ * channels 11, 12, 13, 15 and 16 have no calibration data
+ * calibration offset is same for channels 1, 3, 4, 5
+ *
+ * The data is taken from GPADC_TRIM registers description.
+ * GPADC_TRIM registers keeps difference between the code measured
+ * at volt1 and volt2 input voltages and corresponding code1 and code2
+ */
+static const struct twl6030_ideal_code
+	twl6030_ideal[TWL6030_GPADC_MAX_CHANNELS] = {
+	[0] = { /* ch 0, external, battery type, resistor value */
+		.code1 = 116,
+		.code2 = 745,
+		.volt1 = 141,
+		.volt2 = 910,
+	},
+	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[2] = { /* ch 2, external, audio accessory/general purpose */
+		.code1 = 55,
+		.code2 = 818,
+		.volt1 = 101,
+		.volt2 = 1499,
+	},
+	[3] = { /* ch 3, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[4] = { /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[5] = { /* ch 5, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[6] = { /* ch 6, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[7] = { /* ch 7, internal, main battery */
+		.code1 = 614,
+		.code2 = 941,
+		.volt1 = 3001,
+		.volt2 = 4599,
+	},
+	[8] = { /* ch 8, internal, backup battery */
+		.code1 = 82,
+		.code2 = 688,
+		.volt1 = 501,
+		.volt2 = 4203,
+	},
+	[9] = { /* ch 9, internal, external charger input */
+		.code1 = 182,
+		.code2 = 818,
+		.volt1 = 2001,
+		.volt2 = 8996,
+	},
+	[10] = { /* ch 10, internal, VBUS */
+		.code1 = 149,
+		.code2 = 818,
+		.volt1 = 1001,
+		.volt2 = 5497,
+	},
+	[11] = {},	/* ch 11, internal, VBUS charging current */
+	[12] = {},	/* ch 12, internal, Die temperature */
+	[13] = {},	/* ch 13, internal, Die temperature */
+	[14] = { /* ch 14, internal, USB ID line */
+		.code1 = 48,
+		.code2 = 714,
+		.volt1 = 323,
+		.volt2 = 4800,
+	},
+	[15] = {},	/* ch 15, internal, test network */
+	[16] = {},	/* ch 16, internal, test network */
+};
+
+static const struct twl6030_ideal_code
+			twl6032_ideal[TWL6032_GPADC_MAX_CHANNELS] = {
+	[0] = { /* ch 0, external, battery type, resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[2] = { /* ch 2, external, audio accessory/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 660,
+		.volt2 = 1500,
+	},
+	[3] = { /* ch 3, external, temperature with external diode/general
+								purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[4] = { /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[5] = { /* ch 5, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[6] = { /* ch 6, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[7] = { /* ch7, internal, system supply */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+	[8] = { /* ch8, internal, backup battery */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+	[9] = { /* ch 9, internal, external charger input */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 3960,
+		.volt2 = 9000,
+	},
+	[10] = { /* ch10, internal, VBUS */
+		.code1 = 150,
+		.code2 = 751,
+		.volt1 = 1000,
+		.volt2 = 5000,
+	},
+	[11] = { /* ch 11, internal, VBUS DC-DC output current */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 660,
+		.volt2 = 1500,
+	},
+	[12] = { /* ch 12, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[13] = { /* ch 13, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[14] = { /* ch 14, internal, USB ID line */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2420,
+		.volt2 = 5500,
+	},
+	[15] = {},	/* ch 15, internal, test network */
+	[16] = {},	/* ch 16, internal, test network */
+	[17] = {},	/* ch 17, internal, battery charging current */
+	[18] = { /* ch 18, internal, battery voltage */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+};
+
+static inline int twl6030_gpadc_write(u8 reg, u8 val)
+{
+	return twl_i2c_write_u8(TWL6030_MODULE_GPADC, val, reg);
+}
+
+static inline int twl6030_gpadc_read(u8 reg, u8 *val)
+{
+
+	return twl_i2c_read(TWL6030_MODULE_GPADC, val, reg, 2);
+}
+
+static int twl6030_gpadc_enable_irq(u8 mask)
+{
+	int ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_LINE_B);
+	if (ret < 0)
+		return ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_STS_B);
+
+	return ret;
+}
+
+static void twl6030_gpadc_disable_irq(u8 mask)
+{
+	twl6030_interrupt_mask(mask, REG_INT_MSK_LINE_B);
+	twl6030_interrupt_mask(mask, REG_INT_MSK_STS_B);
+}
+
+static irqreturn_t twl6030_gpadc_irq_handler(int irq, void *_gpadc)
+{
+	struct twl6030_gpadc_data *gpadc = _gpadc;
+
+	complete(&gpadc->irq_complete);
+
+	return IRQ_HANDLED;
+}
+
+static int twl6030_start_conversion(int channel)
+{
+	return twl6030_gpadc_write(TWL6030_GPADC_CTRL_P1,
+					TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static int twl6032_start_conversion(int channel)
+{
+	int ret;
+
+	ret = twl6030_gpadc_write(TWL6032_GPADC_GPSELECT_ISB, channel);
+	if (ret)
+		return ret;
+
+	return twl6030_gpadc_write(TWL6032_GPADC_CTRL_P1,
+						TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static u8 twl6030_channel_to_reg(int channel)
+{
+	return TWL6030_GPADC_GPCH0_LSB + 2 * channel;
+}
+
+static u8 twl6032_channel_to_reg(int channel)
+{
+	/*
+	 * for any prior chosen channel, when the conversion is ready
+	 * the result is avalable in GPCH0_LSB, GPCH0_MSB.
+	 */
+
+	return TWL6032_GPADC_GPCH0_LSB;
+}
+
+static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
+		int channel, int *res)
+{
+	u8 reg = gpadc->pdata->channel_to_reg(channel);
+	__le16 val;
+	int ret;
+
+	ret = twl6030_gpadc_read(reg, (u8 *)&val);
+	if (ret) {
+		dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
+		return ret;
+	}
+
+	*res = le16_to_cpup(&val);
+
+	return ret;
+}
+
+static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
+		int channel, int *val)
+{
+	int raw_code;
+	int corrected_code;
+	int channel_value;
+	int ret;
+
+	ret = twl6030_gpadc_get_raw(gpadc, channel, &raw_code);
+	if (ret)
+		return ret;
+
+	corrected_code = ((raw_code * 1000) -
+		gpadc->twl6030_cal_tbl[channel].offset_error) /
+		gpadc->twl6030_cal_tbl[channel].gain_error;
+
+	channel_value = corrected_code *
+			gpadc->twl6030_cal_tbl[channel].gain;
+
+	/* Shift back into mV range */
+	channel_value /= 1000;
+
+	dev_dbg(gpadc->dev, "GPADC raw code: %d", raw_code);
+	dev_dbg(gpadc->dev, "GPADC corrected code: %d", corrected_code);
+	dev_dbg(gpadc->dev, "GPADC value: %d", channel_value);
+
+	*val = channel_value;
+
+	return ret;
+}
+
+static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
+			     const struct iio_chan_spec *chan,
+			     int *val, int *val2, long mask)
+{
+	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
+	int ret = -EINVAL;
+	long timeout;
+
+	mutex_lock(&gpadc->lock);
+
+	ret = gpadc->pdata->start_conversion(chan->channel);
+	if (ret) {
+		dev_err(gpadc->dev, "failed to start conversion\n");
+		goto err;
+	}
+	/* wait for conversion to complete */
+	timeout = wait_for_completion_interruptible_timeout(
+				&gpadc->irq_complete, msecs_to_jiffies(5000));
+	if (!timeout)
+		return -ETIMEDOUT;
+	else if (timeout < 0)
+		return EINTR;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	case IIO_CHAN_INFO_PROCESSED:
+		ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	default:
+		break;
+	}
+err:
+	mutex_unlock(&gpadc->lock);
+
+	return ret;
+}
+
+/*
+ * The GPADC channels are calibrated using a two point calibration method.
+ * The channels measured with two known values: volt1 and volt2, and
+ * ideal corresponding output codes are known: code1, code2.
+ * The difference(d1, d2) between ideal and measured codes stored in trim
+ * registers.
+ * The goal is to find offset and gain of the real curve for each calibrated
+ * channel.
+ * gain: k = 1 + ((d2 - d1) / (x2 - x1))
+ * offset: b = d1 + (k - 1) * x1
+ */
+static void twl6030_calibrate_channel(struct twl6030_gpadc_data *gpadc,
+					int channel, int d1, int d2)
+{
+	int b, k, gain, x1, x2;
+	const struct twl6030_ideal_code *ideal = gpadc->pdata->ideal;
+
+	/* Gain */
+	gain = ((ideal[channel].volt2 - ideal[channel].volt1) * 1000) /
+		(ideal[channel].code2 - ideal[channel].code1);
+
+	x1 = ideal[channel].code1;
+	x2 = ideal[channel].code2;
+
+	/* k - real curve gain */
+	k = 1000 + (((d2 - d1) * 1000) / (x2 - x1));
+
+	/* b - offset of the real curve gain */
+	b = (d1 * 1000) - (k - 1000) * x1;
+
+	gpadc->twl6030_cal_tbl[channel].gain = gain;
+	gpadc->twl6030_cal_tbl[channel].gain_error = k;
+	gpadc->twl6030_cal_tbl[channel].offset_error = b;
+
+	dev_dbg(gpadc->dev, "GPADC d1   for Chn: %d = %d\n", channel, d1);
+	dev_dbg(gpadc->dev, "GPADC d2   for Chn: %d = %d\n", channel, d2);
+	dev_dbg(gpadc->dev, "GPADC x1   for Chn: %d = %d\n", channel, x1);
+	dev_dbg(gpadc->dev, "GPADC x2   for Chn: %d = %d\n", channel, x2);
+	dev_dbg(gpadc->dev, "GPADC Gain for Chn: %d = %d\n", channel, gain);
+	dev_dbg(gpadc->dev, "GPADC k    for Chn: %d = %d\n", channel, k);
+	dev_dbg(gpadc->dev, "GPADC b    for Chn: %d = %d\n", channel, b);
+}
+
+static inline int twl6030_gpadc_get_trim_offset(s8 d)
+{
+	/*
+	 * XXX NOTE!
+	 * bit 0 - sign, bit 7 - reserved, 6..1 - trim value
+	 * though, the documentation states that trim value
+	 * is absolute value, the correct conversion results are
+	 * obtained if the value is interpreted as 2's complement.
+	 */
+	__u32 temp = ((d & 0x7f) >> 1) | ((d & 1) << 6);
+
+	return sign_extend32(temp, 6);
+}
+
+static int twl6030_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int ret;
+	int chn;
+	u8 trim_regs[TWL6030_GPADC_MAX_CHANNELS];
+	s8 d1, d2;
+
+	/*
+	 * for calibration two measurements have been performed at
+	 * factory, for some channels, during the production test and
+	 * have been stored in registers. This two stored values are
+	 * used to correct the measurements. The values represent
+	 * offsets for the given input from the output on ideal curve.
+	 */
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs,
+			TWL6030_GPADC_TRIM1, 16);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	for (chn = 0; chn < TWL6030_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+			d1 = trim_regs[0];
+			d2 = trim_regs[1];
+			break;
+		case 1:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+			d1 = trim_regs[4];
+			d2 = trim_regs[5];
+			break;
+		case 2:
+			d1 = trim_regs[12];
+			d2 = trim_regs[13];
+			break;
+		case 7:
+			d1 = trim_regs[6];
+			d2 = trim_regs[7];
+			break;
+		case 8:
+			d1 = trim_regs[2];
+			d2 = trim_regs[3];
+			break;
+		case 9:
+			d1 = trim_regs[8];
+			d2 = trim_regs[9];
+			break;
+		case 10:
+			d1 = trim_regs[10];
+			d2 = trim_regs[11];
+			break;
+		case 14:
+			d1 = trim_regs[14];
+			d2 = trim_regs[15];
+			break;
+		default:
+			continue;
+		}
+
+		d1 = twl6030_gpadc_get_trim_offset(d1);
+		d2 = twl6030_gpadc_get_trim_offset(d2);
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int chn, d1 = 0, d2 = 0, temp;
+	u8 trim_regs[17];
+	int ret;
+
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
+			TWL6030_GPADC_TRIM1, 16);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	/*
+	 * Loop to calculate the value needed for returning voltages from
+	 * GPADC not values.
+	 *
+	 * gain is calculated to 3 decimal places fixed point.
+	 */
+	for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+		case 1:
+		case 2:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+		case 11:
+		case 12:
+		case 13:
+		case 14:
+			/* D1 */
+			d1 = (trim_regs[3] & 0x1F) << 2;
+			d1 |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				d1 = -d1;
+
+			/* D2 */
+			d2 = (trim_regs[4] & 0x3F) << 2;
+			d2 |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				d2 = -d2;
+			break;
+		case 8:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[8] & 0x18) << 1;
+			d1 |= (trim_regs[7] & 0x1E) >> 1;
+			if (trim_regs[7] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[10] & 0x1F) << 2;
+			d2 |= (trim_regs[8] & 0x06) >> 1;
+			if (trim_regs[8] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		case 9:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[14] & 0x18) << 1;
+			d1 |= (trim_regs[12] & 0x1E) >> 1;
+			if (trim_regs[12] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[16] & 0x1F) << 2;
+			d2 |= (trim_regs[14] & 0x06) >> 1;
+			if (trim_regs[14] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+		case 10:
+			/* D1 */
+			d1 = (trim_regs[11] & 0x0F) << 3;
+			d1 |= (trim_regs[9] & 0x0E) >> 1;
+			if (trim_regs[9] & 0x01)
+				d1 = -d1;
+
+			/* D2 */
+			d2 = (trim_regs[15] & 0x0F) << 3;
+			d2 |= (trim_regs[13] & 0x0E) >> 1;
+			if (trim_regs[13] & 0x01)
+				d2 = -d2;
+			break;
+		case 7:
+		case 18:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[5] & 0x7E) >> 1;
+			if (trim_regs[5] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[6] & 0xFE) >> 1;
+			if (trim_regs[6] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		default:
+			/* No data for other channels */
+			continue;
+		}
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+#define TWL6030_GPADC_CHAN(chn, chan_info) {		\
+	.type = IIO_VOLTAGE,				\
+	.channel = chn,					\
+	.info_mask = BIT(chan_info),			\
+	.info_mask_separate = BIT(chan_info), 		\
+	.indexed = 1,					\
+}
+
+/* internal test network channel */
+#define TWL6030_GPADC_TEST_CHAN(chn, chan_info) {	\
+	.type = IIO_VOLTAGE,				\
+	.channel = chn,					\
+	.info_mask = BIT(chan_info),			\
+	.indexed = 1,					\
+}
+
+static const struct iio_chan_spec twl6030_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(2, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(5, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(12, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(13, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(14, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_TEST_CHAN(15, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_TEST_CHAN(16, IIO_CHAN_INFO_RAW),
+};
+
+static const struct iio_chan_spec twl6032_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(2, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(5, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(12, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(13, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(14, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_TEST_CHAN(15, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_TEST_CHAN(16, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(17, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(18, IIO_CHAN_INFO_PROCESSED),
+};
+
+static const struct iio_info twl6030_gpadc_iio_info = {
+	.read_raw = &twl6030_gpadc_read_raw,
+	.driver_module = THIS_MODULE,
+};
+
+static const struct twl6030_gpadc_platform_data twl6030_pdata = {
+	.iio_channels = twl6030_gpadc_iio_channels,
+	.nchannels = TWL6030_GPADC_MAX_CHANNELS,
+	.ideal = twl6030_ideal,
+	.start_conversion = twl6030_start_conversion,
+	.channel_to_reg = twl6030_channel_to_reg,
+	.calibrate = twl6030_calibration,
+};
+
+static const struct twl6030_gpadc_platform_data twl6032_pdata = {
+	.iio_channels = twl6032_gpadc_iio_channels,
+	.nchannels = TWL6032_GPADC_MAX_CHANNELS,
+	.ideal = twl6032_ideal,
+	.start_conversion = twl6032_start_conversion,
+	.channel_to_reg = twl6032_channel_to_reg,
+	.calibrate = twl6032_calibration,
+};
+
+static const struct of_device_id of_twl6030_match_tbl[] = {
+	{
+		.compatible = "ti,twl6030_gpadc",
+		.data = &twl6030_pdata,
+	},
+	{
+		.compatible = "ti,twl6032_gpadc",
+		.data = &twl6032_pdata,
+	},
+	{ /* end */ }
+};
+
+static int twl6030_gpadc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct twl6030_gpadc_data *gpadc;
+	const struct twl6030_gpadc_platform_data *pdata;
+	const struct of_device_id *match;
+	struct iio_dev *indio_dev;
+	int irq;
+	int ret;
+
+	match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
+	pdata = match ? match->data : dev->platform_data;
+
+	if (!pdata)
+		return -EINVAL;
+
+	indio_dev = iio_device_alloc(sizeof(*gpadc));
+	if (!indio_dev) {
+		dev_err(dev, "failed allocating iio device\n");
+		ret = -ENOMEM;
+	}
+
+	gpadc = iio_priv(indio_dev);
+
+	gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
+					sizeof(struct twl6030_chnl_calib) *
+					pdata->nchannels, GFP_KERNEL);
+	if (!gpadc->twl6030_cal_tbl)
+		goto err_free_device;
+
+	gpadc->dev = dev;
+	gpadc->pdata = pdata;
+
+	platform_set_drvdata(pdev, indio_dev);
+	mutex_init(&gpadc->lock);
+	init_completion(&gpadc->irq_complete);
+
+	ret = pdata->calibrate(gpadc);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to read calibration registers\n");
+		goto err_free_device;
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "failed to get irq\n");
+		goto err_free_device;
+	}
+
+	ret = request_threaded_irq(irq, NULL, twl6030_gpadc_irq_handler,
+				IRQF_ONESHOT, "twl6030_gpadc", gpadc);
+	if (ret) {
+		dev_dbg(&pdev->dev, "could not request irq\n");
+		goto err_free_device;
+	}
+
+	ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
+		goto err_free_irq;
+	}
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+					TWL6030_REG_TOGGLE1);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC module\n");
+		goto err_free_irq;
+	}
+
+	indio_dev->name = DRIVER_NAME;
+	indio_dev->dev.parent = dev;
+	indio_dev->info = &twl6030_gpadc_iio_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->channels = pdata->iio_channels;
+	indio_dev->num_channels = pdata->nchannels;
+
+	ret = iio_device_register(indio_dev);
+	if (ret)
+		goto err_free_irq;
+
+	return ret;
+
+err_free_irq:
+	free_irq(irq, indio_dev);
+err_free_device:
+	iio_device_free(indio_dev);
+
+	return ret;
+}
+
+static int twl6030_gpadc_remove(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+
+	twl6030_gpadc_disable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	free_irq(platform_get_irq(pdev, 0), indio_dev);
+	iio_device_unregister(indio_dev);
+	iio_device_free(indio_dev);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int twl6030_gpadc_suspend(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCR,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error reseting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+
+static int twl6030_gpadc_resume(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error setting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+#endif
+
+SIMPLE_DEV_PM_OPS(twl6030_gpadc_pm_ops, twl6030_gpadc_suspend,
+					twl6030_gpadc_resume);
+
+static struct platform_driver twl6030_gpadc_driver = {
+	.probe		= twl6030_gpadc_probe,
+	.remove		= twl6030_gpadc_remove,
+	.driver		= {
+		.name	= DRIVER_NAME,
+		.owner	= THIS_MODULE,
+		.pm	= &twl6030_gpadc_pm_ops,
+		.of_match_table = of_twl6030_match_tbl,
+	},
+};
+
+module_platform_driver(twl6030_gpadc_driver);
+
+MODULE_ALIAS("platform: " DRIVER_NAME);
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_DESCRIPTION("twl6030 ADC driver");
+MODULE_LICENSE("GPL");
-- 
1.8.1.2



From yadi.brar at samsung.com  Sun Jul  7 07:44:19 2013
From: yadi.brar at samsung.com (Yadwinder Singh Brar)
Date: Sun, 07 Jul 2013 17:14:19 +0530
Subject: [PATCH 0/3] Add clk driver to register s2mps11 clocks
Message-ID: <1373197462-4033-1-git-send-email-yadi.brar@samsung.com>

This series adds support to register three(AP/CP/BT) buffered 32.768 KHz
outputs of mfd-s2mps11 with common clock framework and removes clocks from
regulators list.

Yadwinder Singh Brar (3):
  clk: s2mps11: Add support for s2mps11
  mfd: sec: Add clock cell for s2mps11
  mfd: s2mps11: Remove clocks from regulators list

 Documentation/devicetree/bindings/mfd/s2mps11.txt |   20 ++
 drivers/clk/Kconfig                               |    6 +
 drivers/clk/Makefile                              |    1 +
 drivers/clk/clk-s2mps11.c                         |  273 +++++++++++++++++++++
 drivers/mfd/sec-core.c                            |    4 +-
 include/linux/mfd/samsung/s2mps11.h               |    6 +-
 6 files changed, 304 insertions(+), 6 deletions(-)
 create mode 100644 drivers/clk/clk-s2mps11.c



From yadi.brar at samsung.com  Sun Jul  7 07:44:20 2013
From: yadi.brar at samsung.com (Yadwinder Singh Brar)
Date: Sun, 07 Jul 2013 17:14:20 +0530
Subject: [PATCH 1/3] clk: s2mps11: Add support for s2mps11
In-Reply-To: <1373197462-4033-1-git-send-email-yadi.brar@samsung.com>
References: <1373197462-4033-1-git-send-email-yadi.brar@samsung.com>
Message-ID: <1373197462-4033-2-git-send-email-yadi.brar@samsung.com>

This patch adds support to register three(AP/CP/BT) buffered 32.768 KHz
outputs of mfd-s2mps11 with common clock framework.

Signed-off-by: Yadwinder Singh Brar <yadi.brar at samsung.com>
---
 drivers/clk/Kconfig       |    6 +
 drivers/clk/Makefile      |    1 +
 drivers/clk/clk-s2mps11.c |  273 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 280 insertions(+), 0 deletions(-)
 create mode 100644 drivers/clk/clk-s2mps11.c

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 0357ac4..3fdf10e 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -65,6 +65,12 @@ config COMMON_CLK_SI5351
 	  This driver supports Silicon Labs 5351A/B/C programmable clock
 	  generators.
 
+config COMMON_CLK_S2MPS11
+	tristate "Clock driver for S2MPS11 MFD"
+	depends on MFD_SEC_CORE
+	---help---
+	  This driver supports S2MPS11 crystal oscillator clock.
+
 config CLK_TWL6040
 	tristate "External McPDM functional clock from twl6040"
 	depends on TWL6040_CORE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 137d3e7..5fd642d 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -38,4 +38,5 @@ obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
 obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
 obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
 obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
+obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
 obj-$(CONFIG_CLK_TWL6040)	+= clk-twl6040.o
diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
new file mode 100644
index 0000000..7be41e6
--- /dev/null
+++ b/drivers/clk/clk-s2mps11.c
@@ -0,0 +1,273 @@
+/*
+ * clk-s2mps11.c - Clock driver for S2MPS11.
+ *
+ * Copyright (C) 2013 Samsung Electornics
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/clkdev.h>
+#include <linux/regmap.h>
+#include <linux/clk-provider.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/samsung/s2mps11.h>
+#include <linux/mfd/samsung/core.h>
+
+#define s2mps11_name(a) (a->hw.init->name)
+
+static struct clk **clk_table;
+static struct clk_onecell_data clk_data;
+
+enum {
+	S2MPS11_CLK_AP = 0,
+	S2MPS11_CLK_CP,
+	S2MPS11_CLK_BT,
+	S2MPS11_CLKS_NUM,
+};
+
+struct s2mps11_clk {
+	struct sec_pmic_dev *iodev;
+	struct clk_hw hw;
+	struct clk *clk;
+	struct clk_lookup *lookup;
+	u32 mask;
+	bool enabled;
+};
+
+static struct s2mps11_clk *to_s2mps11_clk(struct clk_hw *hw)
+{
+	return container_of(hw, struct s2mps11_clk, hw);
+}
+
+static int s2mps11_clk_prepare(struct clk_hw *hw)
+{
+	struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
+	int ret;
+
+	ret = regmap_update_bits(s2mps11->iodev->regmap,
+				S2MPS11_REG_RTC_CTRL,
+				 s2mps11->mask, s2mps11->mask);
+	if (!ret)
+		s2mps11->enabled = true;
+
+	return ret;
+}
+
+static void s2mps11_clk_unprepare(struct clk_hw *hw)
+{
+	struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
+	int ret;
+
+	ret = regmap_update_bits(s2mps11->iodev->regmap, S2MPS11_REG_RTC_CTRL,
+			   s2mps11->mask, ~s2mps11->mask);
+
+	if (!ret)
+		s2mps11->enabled = false;
+}
+
+static int s2mps11_clk_is_enabled(struct clk_hw *hw)
+{
+	struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
+
+	return s2mps11->enabled;
+}
+
+static unsigned long s2mps11_clk_recalc_rate(struct clk_hw *hw,
+					     unsigned long parent_rate)
+{
+	struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
+	if (s2mps11->enabled)
+		return 32768;
+	else
+		return 0;
+}
+
+static struct clk_ops s2mps11_clk_ops = {
+	.prepare	= s2mps11_clk_prepare,
+	.unprepare	= s2mps11_clk_unprepare,
+	.is_enabled	= s2mps11_clk_is_enabled,
+	.recalc_rate	= s2mps11_clk_recalc_rate,
+};
+
+static struct clk_init_data s2mps11_clks_init[S2MPS11_CLKS_NUM] = {
+	[S2MPS11_CLK_AP] = {
+		.name = "s2mps11_ap",
+		.ops = &s2mps11_clk_ops,
+		.flags = CLK_IS_ROOT,
+	},
+	[S2MPS11_CLK_CP] = {
+		.name = "s2mps11_cp",
+		.ops = &s2mps11_clk_ops,
+		.flags = CLK_IS_ROOT,
+	},
+	[S2MPS11_CLK_BT] = {
+		.name = "s2mps11_bt",
+		.ops = &s2mps11_clk_ops,
+		.flags = CLK_IS_ROOT,
+	},
+};
+
+static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev)
+{
+	struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
+	struct device_node *clk_np;
+	int i;
+
+	if (!iodev->dev->of_node)
+		return NULL;
+
+	clk_np = of_find_node_by_name(iodev->dev->of_node, "clocks");
+	if (!clk_np) {
+		dev_err(&pdev->dev, "could not find clock sub-node\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	clk_table = devm_kzalloc(&pdev->dev, sizeof(struct clk *) *
+				 S2MPS11_CLKS_NUM, GFP_KERNEL);
+	if (!clk_table)
+		return ERR_PTR(-ENOMEM);
+
+	for (i = 0; i < S2MPS11_CLKS_NUM; i++)
+		of_property_read_string_index(clk_np, "clock-output-names", i,
+				&s2mps11_clks_init[i].name);
+
+	return clk_np;
+}
+
+static int s2mps11_clk_probe(struct platform_device *pdev)
+{
+	struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
+	struct s2mps11_clk *s2mps11_clks, *s2mps11_clk;
+	struct device_node *clk_np = NULL;
+	int i, ret = 0;
+	u32 val;
+
+	s2mps11_clks = devm_kzalloc(&pdev->dev, sizeof(*s2mps11_clk) *
+					S2MPS11_CLKS_NUM, GFP_KERNEL);
+	if (!s2mps11_clks)
+		return -ENOMEM;
+
+	s2mps11_clk = s2mps11_clks;
+
+	clk_np = s2mps11_clk_parse_dt(pdev);
+	if (IS_ERR(clk_np))
+		return PTR_ERR(clk_np);
+
+	for (i = 0; i < S2MPS11_CLKS_NUM; i++, s2mps11_clk++) {
+		s2mps11_clk->iodev = iodev;
+		s2mps11_clk->hw.init = &s2mps11_clks_init[i];
+		s2mps11_clk->mask = 1 << i;
+
+		ret = regmap_read(s2mps11_clk->iodev->regmap,
+				  S2MPS11_REG_RTC_CTRL, &val);
+		if (ret < 0)
+			goto err_reg;
+
+		s2mps11_clk->enabled = val & s2mps11_clk->mask;
+
+		s2mps11_clk->clk = devm_clk_register(&pdev->dev,
+							&s2mps11_clk->hw);
+		if (IS_ERR(s2mps11_clk->clk)) {
+			dev_err(&pdev->dev, "Fail to register : %s\n",
+						s2mps11_name(s2mps11_clk));
+			ret = PTR_ERR(s2mps11_clk->clk);
+			goto err_reg;
+		}
+
+		s2mps11_clk->lookup = devm_kzalloc(&pdev->dev,
+					sizeof(struct clk_lookup), GFP_KERNEL);
+		if (!s2mps11_clk->lookup) {
+			ret = -ENOMEM;
+			goto err_lup;
+		}
+
+		s2mps11_clk->lookup->con_id = s2mps11_name(s2mps11_clk);
+		s2mps11_clk->lookup->clk = s2mps11_clk->clk;
+
+		clkdev_add(s2mps11_clk->lookup);
+	}
+
+	if (clk_table) {
+		for (i = 0; i < S2MPS11_CLKS_NUM; i++)
+			clk_table[i] = s2mps11_clks[i].clk;
+
+		clk_data.clks = clk_table;
+		clk_data.clk_num = S2MPS11_CLKS_NUM;
+		of_clk_add_provider(clk_np, of_clk_src_onecell_get, &clk_data);
+	}
+
+	platform_set_drvdata(pdev, s2mps11_clks);
+
+	return ret;
+err_lup:
+	devm_clk_unregister(&pdev->dev, s2mps11_clk->clk);
+err_reg:
+	while (s2mps11_clk > s2mps11_clks) {
+		if (s2mps11_clk->lookup) {
+			clkdev_drop(s2mps11_clk->lookup);
+			devm_clk_unregister(&pdev->dev, s2mps11_clk->clk);
+		}
+		s2mps11_clk--;
+	}
+
+	return ret;
+}
+
+static int s2mps11_clk_remove(struct platform_device *pdev)
+{
+	struct s2mps11_clk *s2mps11_clks = platform_get_drvdata(pdev);
+	int i;
+
+	for (i = 0; i < S2MPS11_CLKS_NUM; i++)
+		clkdev_drop(s2mps11_clks[i].lookup);
+
+	return 0;
+}
+
+static const struct platform_device_id s2mps11_clk_id[] = {
+	{ "s2mps11-clk", 0},
+	{ },
+};
+MODULE_DEVICE_TABLE(platform, s2mps11_clk_id);
+
+static struct platform_driver s2mps11_clk_driver = {
+	.driver = {
+		.name  = "s2mps11-clk",
+		.owner = THIS_MODULE,
+	},
+	.probe = s2mps11_clk_probe,
+	.remove = s2mps11_clk_remove,
+	.id_table = s2mps11_clk_id,
+};
+
+static int __init s2mps11_clk_init(void)
+{
+	return platform_driver_register(&s2mps11_clk_driver);
+}
+subsys_initcall(s2mps11_clk_init);
+
+static void __init s2mps11_clk_cleanup(void)
+{
+	platform_driver_unregister(&s2mps11_clk_driver);
+}
+module_exit(s2mps11_clk_cleanup);
+
+MODULE_DESCRIPTION("S2MPS11 Clock Driver");
+MODULE_AUTHOR("Yadwinder Singh Brar <yadi.brar at samsung.com>");
+MODULE_LICENSE("GPL");
-- 
1.7.0.4



From yadi.brar at samsung.com  Sun Jul  7 07:44:22 2013
From: yadi.brar at samsung.com (Yadwinder Singh Brar)
Date: Sun, 07 Jul 2013 17:14:22 +0530
Subject: [PATCH 3/3] mfd: s2mps11: Remove clocks from regulators list
In-Reply-To: <1373197462-4033-1-git-send-email-yadi.brar@samsung.com>
References: <1373197462-4033-1-git-send-email-yadi.brar@samsung.com>
Message-ID: <1373197462-4033-4-git-send-email-yadi.brar@samsung.com>

Since these are fixed rate clocks which are registered with common clock
framework so remove these from list of regulators which were unnecessarily
incrementing the count(S2MPS11_REGULATOR_MAX) of regulators.

Signed-off-by: Yadwinder Singh Brar <yadi.brar at samsung.com>
---
 include/linux/mfd/samsung/s2mps11.h |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/include/linux/mfd/samsung/s2mps11.h b/include/linux/mfd/samsung/s2mps11.h
index d0d52ea..b3ddf98 100644
--- a/include/linux/mfd/samsung/s2mps11.h
+++ b/include/linux/mfd/samsung/s2mps11.h
@@ -167,11 +167,8 @@ enum s2mps11_regulators {
 	S2MPS11_BUCK8,
 	S2MPS11_BUCK9,
 	S2MPS11_BUCK10,
-	S2MPS11_AP_EN32KHZ,
-	S2MPS11_CP_EN32KHZ,
-	S2MPS11_BT_EN32KHZ,
 
-	S2MPS11_REG_MAX,
+	S2MPS11_REGULATOR_MAX,
 };
 
 #define S2MPS11_BUCK_MIN1	600000
@@ -203,6 +200,5 @@ enum s2mps11_regulators {
 #define S2MPS11_BUCK4_RAMP_EN_SHIFT	1
 #define S2MPS11_BUCK6_RAMP_EN_SHIFT	0
 #define S2MPS11_PMIC_EN_SHIFT	6
-#define S2MPS11_REGULATOR_MAX (S2MPS11_REG_MAX - 3)
 
 #endif /*  __LINUX_MFD_S2MPS11_H */
-- 
1.7.0.4



From yadi.brar at samsung.com  Sun Jul  7 07:44:21 2013
From: yadi.brar at samsung.com (Yadwinder Singh Brar)
Date: Sun, 07 Jul 2013 17:14:21 +0530
Subject: [PATCH 2/3] mfd: sec: Add clock cell for s2mps11
In-Reply-To: <1373197462-4033-1-git-send-email-yadi.brar@samsung.com>
References: <1373197462-4033-1-git-send-email-yadi.brar@samsung.com>
Message-ID: <1373197462-4033-3-git-send-email-yadi.brar@samsung.com>

This patch adds clock to list of mfd cells for s2mps11 and DT documentation
for clock part.

Signed-off-by: Yadwinder Singh Brar <yadi.brar at samsung.com>
---
 Documentation/devicetree/bindings/mfd/s2mps11.txt |   20 ++++++++++++++++++++
 drivers/mfd/sec-core.c                            |    4 +++-
 2 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 36269c4..e41dd16 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -16,6 +16,21 @@ Optional properties:
 - interrupts: Interrupt specifiers for interrupt sources.
 
 Optional nodes:
+- clocks: s2mps11 provides three(AP/CP/BT) buffered 32.768 KHz outputs, so to
+  register these as clocks with common clock framework instantiate a sub-node
+  named "clocks". It uses the common clock binding documented in :
+  [Documentation/devicetree/bindings/clock/clock-bindings.txt]
+  - #clock-cells: should be 1.
+
+  - The following is the list of clocks generated by the controller. Each clock
+    is assigned an identifier and client nodes use this identifier to specify
+    the clock which they consume.
+    Clock               ID
+    ----------------------
+    32KhzAP		0
+    32KhzCP		1
+    32KhzBT		2
+
 - regulators: The regulators of s2mps11 that have to be instantiated should be
 included in a sub-node named 'regulators'. Regulator nodes included in this
 sub-node should be of the format as listed below.
@@ -55,6 +70,11 @@ Example:
 		compatible = "samsung,s2mps11-pmic";
 		reg = <0x66>;
 
+		s2m_osc: clocks{
+			#clock-cells = 1;
+			clock-output-names = "xx", "yy", "zz";
+		};
+
 		regulators {
 			ldo1_reg: LDO1 {
 				regulator-name = "VDD_ABB_3.3V";
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 760da8a..eaee5ec 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -58,7 +58,9 @@ static struct mfd_cell s5m8767_devs[] = {
 static struct mfd_cell s2mps11_devs[] = {
 	{
 		.name = "s2mps11-pmic",
-	},
+	}, {
+		.name = "s2mps11-clk",
+	}
 };
 
 #ifdef CONFIG_OF
-- 
1.7.0.4



From jonas.jensen at gmail.com  Tue Jul 16 08:00:52 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Tue, 16 Jul 2013 14:00:52 +0200
Subject: [PATCH v2] gpio: Add MOXA ART GPIO driver
In-Reply-To: <1373464158-27881-1-git-send-email-jonas.jensen@gmail.com>
References: <1373464158-27881-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1373976052-16779-1-git-send-email-jonas.jensen@gmail.com>

Add GPIO driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v1:
    
    1. don't use hardcoded GPIO numbers, use of_get_named_gpio
    2. check gpiochip_add return value
    3. set gpio_chip .dev member to platform device
    
    Applies to next-20130703

 drivers/gpio/Kconfig       |   7 ++
 drivers/gpio/Makefile      |   1 +
 drivers/gpio/gpio-moxart.c | 189 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 197 insertions(+)
 create mode 100644 drivers/gpio/gpio-moxart.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b2450ba..521fd97 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -714,6 +714,13 @@ config GPIO_MSIC
 	  Enable support for GPIO on intel MSIC controllers found in
 	  intel MID devices
 
+config GPIO_MOXART
+	bool "MOXART GPIO support"
+	depends on ARCH_MOXART
+	help
+	  Select this option to enable GPIO driver for
+	  MOXA ART SoC devices.
+
 comment "USB GPIO expanders:"
 
 config GPIO_VIPERBOARD
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index ef3e983..44b0de4 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_GPIO_MC9S08DZ60)	+= gpio-mc9s08dz60.o
 obj-$(CONFIG_GPIO_MCP23S08)	+= gpio-mcp23s08.o
 obj-$(CONFIG_GPIO_ML_IOH)	+= gpio-ml-ioh.o
 obj-$(CONFIG_GPIO_MM_LANTIQ)	+= gpio-mm-lantiq.o
+obj-$(CONFIG_GPIO_MOXART)	+= gpio-moxart.o
 obj-$(CONFIG_GPIO_MPC5200)	+= gpio-mpc5200.o
 obj-$(CONFIG_GPIO_MPC8XXX)	+= gpio-mpc8xxx.o
 obj-$(CONFIG_GPIO_MSIC)		+= gpio-msic.o
diff --git a/drivers/gpio/gpio-moxart.c b/drivers/gpio/gpio-moxart.c
new file mode 100644
index 0000000..19d4e3b
--- /dev/null
+++ b/drivers/gpio/gpio-moxart.c
@@ -0,0 +1,189 @@
+/*
+ * MOXA ART SoCs GPIO driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/io.h>
+#include <linux/gpio.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_gpio.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/delay.h>
+#include <linux/timer.h>
+
+#define GPIO_DATA_OUT		0x00
+#define GPIO_DATA_IN		0x04
+#define GPIO_PIN_DIRECTION	0x08
+
+static void __iomem *moxart_pincontrol_base;
+static void __iomem *moxart_gpio_base;
+
+void moxart_gpio_enable(u32 gpio)
+{
+	writel(readl(moxart_pincontrol_base) | gpio, moxart_pincontrol_base);
+}
+
+void moxart_gpio_disable(u32 gpio)
+{
+	writel(readl(moxart_pincontrol_base) & ~gpio, moxart_pincontrol_base);
+}
+
+static int moxart_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+	moxart_gpio_enable(1 << offset);
+	return pinctrl_request_gpio(offset);
+}
+
+static void moxart_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+	pinctrl_free_gpio(offset);
+	moxart_gpio_disable(1 << offset);
+}
+
+static int moxart_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+	void __iomem *ioaddr = moxart_gpio_base + GPIO_PIN_DIRECTION;
+
+	writel(readl(ioaddr) & ~(1 << offset), ioaddr);
+	return 0;
+}
+
+static int moxart_gpio_direction_output(struct gpio_chip *chip,
+					unsigned offset, int value)
+{
+	void __iomem *ioaddr = moxart_gpio_base + GPIO_PIN_DIRECTION;
+
+	writel(readl(ioaddr) | (1 << offset), ioaddr);
+	return 0;
+}
+
+static void moxart_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+	void __iomem *ioaddr = moxart_gpio_base + GPIO_DATA_OUT;
+	u32 reg = readl(ioaddr);
+
+	(value) ?	writel(reg | (1 << offset), ioaddr) :
+			writel(reg & ~(1 << offset), ioaddr);
+}
+
+static int moxart_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+	u32 ret = readl(moxart_gpio_base + GPIO_PIN_DIRECTION);
+
+	if (ret & (1 << offset))
+		ret = readl(moxart_gpio_base + GPIO_DATA_OUT) & (1 << offset);
+	else
+		ret = readl(moxart_gpio_base + GPIO_DATA_IN) & (1 << offset);
+
+	return ret;
+}
+
+static struct gpio_chip moxart_gpio_chip = {
+	.label			= "moxart-gpio",
+	.request		= moxart_gpio_request,
+	.free			= moxart_gpio_free,
+	.direction_input	= moxart_gpio_direction_input,
+	.direction_output	= moxart_gpio_direction_output,
+	.set			= moxart_gpio_set,
+	.get			= moxart_gpio_get,
+	.base			= 0,
+	.ngpio			= 32,
+	.can_sleep		= 0,
+};
+
+static int moxart_gpio_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct resource *res;
+	int ret, gpio_ready_led, gpio_reset_switch;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	moxart_gpio_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_gpio_base)) {
+		dev_err(dev, "%s: devm_ioremap_resource res_gpio failed\n",
+			dev->of_node->full_name);
+		return PTR_ERR(moxart_gpio_base);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	moxart_pincontrol_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_pincontrol_base)) {
+		dev_err(dev, "%s: devm_ioremap_resource res_pmu failed\n",
+			dev->of_node->full_name);
+		return PTR_ERR(moxart_pincontrol_base);
+	}
+
+	moxart_gpio_chip.dev = dev;
+
+	ret = gpiochip_add(&moxart_gpio_chip);
+	if (ret)
+		dev_err(dev, "%s: gpiochip_add failed\n",
+			dev->of_node->full_name);
+
+
+	gpio_ready_led = of_get_named_gpio(pdev->dev.of_node,
+					   "gpio-ready-led", 0);
+	if (!gpio_is_valid(gpio_ready_led)) {
+		dev_err(&pdev->dev, "invalid gpio (gpio-ready-led): %d\n",
+			gpio_ready_led);
+		return gpio_ready_led;
+	}
+
+	gpio_reset_switch = of_get_named_gpio(pdev->dev.of_node,
+					      "gpio-reset-switch", 0);
+	if (!gpio_is_valid(gpio_reset_switch)) {
+		dev_err(&pdev->dev, "invalid gpio (gpio-reset-switch): %d\n",
+			gpio_reset_switch);
+		return gpio_reset_switch;
+	}
+
+	moxart_gpio_enable(gpio_ready_led | gpio_reset_switch);
+
+	moxart_gpio_direction_input(&moxart_gpio_chip, gpio_reset_switch);
+
+	/*
+	 * gpio_ready_led=0 ready LED on
+	 * gpio_ready_led=1 ready LED off
+	 */
+	moxart_gpio_direction_output(&moxart_gpio_chip, gpio_ready_led, 0);
+	moxart_gpio_set(&moxart_gpio_chip, gpio_ready_led, 0);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_gpio_match[] = {
+	{ .compatible = "moxa,moxart-gpio" },
+	{ }
+};
+
+static struct platform_driver moxart_gpio_driver = {
+	.driver	= {
+		.name		= "moxart-gpio",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_gpio_match,
+	},
+	.probe	= moxart_gpio_probe,
+};
+
+static int __init moxart_gpio_init(void)
+{
+	return platform_driver_register(&moxart_gpio_driver);
+}
+
+postcore_initcall(moxart_gpio_init);
+
+MODULE_DESCRIPTION("MOXART GPIO chip driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From tony at atomide.com  Tue Jul 16 08:06:50 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 05:06:50 -0700
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130716093541.GK8880@arwen.pp.htv.fi>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
 <20130716093541.GK8880@arwen.pp.htv.fi>
Message-ID: <20130716120650.GW7656@atomide.com>

* Felipe Balbi <balbi at ti.com> [130716 02:42]:
> Hi,
> 
> On Tue, Jul 16, 2013 at 02:05:36AM -0700, Tony Lindgren wrote:
> > +int pinctrl_check_dynamic(struct device *dev, struct pinctrl_state *st1,
> > +			  struct pinctrl_state *st2)
> > +{
> > +	struct pinctrl_setting *s1, *s2;
> > +
> > +	list_for_each_entry(s1, &st1->settings, node) {
> > +		struct pinctrl_dev *pctldev1;
> > +		const struct pinctrl_ops *pctlops1;
> > +		const unsigned *pins1;
> > +		unsigned num_pins1;
> > +		int res;
> > +
> > +		if (s1->type != PIN_MAP_TYPE_MUX_GROUP)
> > +			continue;
> > +
> > +		pctldev1 = s1->pctldev;
> > +		pctlops1 = pctldev1->desc->pctlops;
> > +		res = pctlops1->get_group_pins(pctldev1, s1->data.mux.group,
> > +					       &pins1, &num_pins1);
> > +		if (res) {
> > +			dev_dbg(dev, "could not get state1 group pins\n");
> > +			return -EINVAL;
> > +		}
> > +
> > +		list_for_each_entry(s2, &st2->settings, node) {
> > +			struct pinctrl_dev *pctldev2;
> > +			const struct pinctrl_ops *pctlops2;
> > +			const unsigned *pins2;
> > +			unsigned num_pins2;
> > +			int i, j, found = 0;
> > +
> > +			if (s2->type != PIN_MAP_TYPE_MUX_GROUP)
> > +				continue;
> > +
> > +			pctldev2 = s2->pctldev;
> > +			if (pctldev1 != pctldev2) {
> > +				dev_dbg(dev, "pctldev must be the same for states\n");
> > +				return -EINVAL;
> > +			}
> > +			pctlops2 = pctldev2->desc->pctlops;
> > +			res = pctlops2->get_group_pins(pctldev2,
> > +						       s2->data.mux.group,
> > +						       &pins2, &num_pins2);
> > +			if (res) {
> > +				dev_dbg(dev, "could not get state2 group pins\n");
> > +				return -EINVAL;
> > +			}
> > +
> > +			for (i = 0; i < num_pins1; i++) {
> > +				int pin1 = pins1[i];
> > +
> > +				for (j = 0; j < num_pins2; j++) {
> > +					int pin2 = pins2[j];
> > +
> > +					if (pin1 == pin2) {
> > +						found++;
> > +						break;
> > +					}
> > +				}
> > +			}
> 
> 4 levels of nested loops ? Isn't this way too much ? OTOH, it points to
> the fact that, perhaps, a list isn't the best data structure for
> pinctrl ??

This check is only done during init to avoid constantly diffing the
pins during runtime like we currently do. And it's only done for the
pins that need to change during runtime for wake-up events etc. So
that's typically few to ten pins per device that need to be checked.

I agree there are things to improve for the data structures,
but that's a different patch set.
 
> Or perhaps you could just assume that if num_pins1 == num_pins2 it's
> enough ? But that will, likely, leave some uncovered corners...

Yes I considered that, but checking for the number of pins is not
enough. It's best to check them properly during init.

Regards,

Tony


From weiyj.lk at gmail.com  Tue Jul 16 08:10:46 2013
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Tue, 16 Jul 2013 20:10:46 +0800
Subject: [PATCH] ARM: OMAP: dma: fix error return code in
 omap_system_dma_probe()
Message-ID: <CAPgLHd-yE_qW1NeK5KkPSUtA1wGfQcnROywrcfa7cH+Dtwfezw@mail.gmail.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
 arch/arm/plat-omap/dma.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 4d463ca..0376606 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2083,6 +2083,7 @@ static int omap_system_dma_probe(struct platform_device *pdev)
 		dma_irq = platform_get_irq_byname(pdev, irq_name);
 		if (dma_irq < 0) {
 			dev_err(&pdev->dev, "failed: request IRQ %d", dma_irq);
+			ret = dma_irq;
 			goto exit_dma_lch_fail;
 		}
 		ret = setup_irq(dma_irq, &omap24xx_dma_irq);



From daniel.lezcano at linaro.org  Tue Jul 16 08:04:21 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 16 Jul 2013 14:04:21 +0200
Subject: [RESEND] cpuidle for ARM pull request
Message-ID: <51E536C5.1020609@linaro.org>


Hi,

The first PR was against the linux-pm-next tree including the patch:

"cpuidle: Add Kconfig.arm and move calxeda, kirkwood and zynq"

This patch has been dropped in the meantime.

Here is a new PR where my tree has been rebased against linux-pm-next
and adding the patch mentioned above.

As stated by Rafael, I will handle the ARM specific patches from now.

The following changes since commit 48f99d5a97d32d70c0738d6e314d9f4dbefd89bf:

  Merge branch 'pm-cpuidle-next' into linux-next (2013-07-16 02:41:06 +0200)

are available in the git repository at:


  git://git.linaro.org/people/dlezcano/linux.git cpuidle/arm-next

for you to fetch changes up to 2b7e79f4a75e803184f483985a25cc751a990f06:

  ARM: ux500: cpuidle: Move ux500 cpuidle driver to drivers/cpuidle
(2013-07-16 13:57:24 +0200)

----------------------------------------------------------------
Daniel Lezcano (2):
      ARM: davinci: cpuidle: Fix target residency
      ARM: ux500: cpuidle: Move ux500 cpuidle driver to drivers/cpuidle

Linus Walleij (2):
      ARM: ux500: cpuidle: Instantiate the driver from platform device
      ARM: ux500: cpuidle: Remove pointless include

Sahara (1):
      cpuidle: Add Kconfig.arm and move calxeda, kirkwood and zynq

 arch/arm/mach-davinci/cpuidle.c                    |    2 +-
 arch/arm/mach-ux500/Makefile                       |    1 -
 drivers/cpuidle/Kconfig                            |   20 +++++---------
 drivers/cpuidle/Kconfig.arm                        |   29
++++++++++++++++++++
 drivers/cpuidle/Makefile                           |    9 ++++--
 .../cpuidle.c => drivers/cpuidle/cpuidle-ux500.c   |   19 +++++++------
 drivers/mfd/db8500-prcmu.c                         |    4 +++
 7 files changed, 58 insertions(+), 26 deletions(-)
 create mode 100644 drivers/cpuidle/Kconfig.arm
 rename arch/arm/mach-ux500/cpuidle.c => drivers/cpuidle/cpuidle-ux500.c
(90%)


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Tue Jul 16 08:11:04 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 16 Jul 2013 14:11:04 +0200
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <51E53858.6090207@linaro.org>

On 07/16/2013 01:17 PM, Joseph Lo wrote:
> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
>>> this state.
>>
>> I tried applying this patch, your series "[PATCH V3 0/3] ARM: tegra114:
>> cpuidle: add power down state", and your series "[PATCH V2 00/11] ARM:
>> tegra114: add support for system suspend", all on top of v3.11-rc1.
>>
>> On Dalmore, the new cpuidle mode /appears/ to work (I see increasing
>> values in the sysfs cpuidle "usage" file for all defined cpuidle
>> states), but I don't see the "CPU VDD off" LED light up; I'm not
>> convinced that the CPU is actually being powered off in the idle mode.
>>
> The LED of the CPU Vdd indicates the power of CPU cluster. But the
> series of CPU idle power down mode support for Tegra114 only supports
> per core power down. It did not support cluster power down yet in idle
> mode. That needs some extra work to support cluster power down in idle
> mode.
> There are some items that I plat to do:
> 1. integrate the MCPM (multi cluster power management) code into Tegra
> CPU PM code

+1

> 2. integrate coupled CPUidle framework into Tegra CPU idle driver

If you are using the MCPM, I suggest you rely on the MCPM to replace the
coupled idle state by it. The code will look much more consistent.

> 3. normalize the Tegra CPU idle driver to single one

I am working on making a single ARM driver, so may be instead of doing a
single tegra driver, we can sync up to move the code forward to the same
scheme than the others driver, then consolidating the tegra drivers
would be easier and consistent.

That would be very nice, if you can separate in the code the PM arch
specific blocks and encapsulate the driver specific code, so no more
include from <mach/...> are needed. That will allow to move the drivers
to drivers/cpuidle directory.

>> With these patches applies, Harmony acts very strangely. After
>> hot-unplug and re-plug of CPU1, the system is hung or almost hung. The
>> patches appear to reduce the amount of time CPU VDD is off judging by
>> the LEDs. The patches might cause issues with system suspend too, but
>> I'm not 100% sure.
>>
> Actually I didn't add anything about hotplug or something can increase
> the loading or make regressions. But I think you are testing with USB
> device attached, right? That might cause some extra loading. You can
> give it a try after just removing USB device. And I double confirm that
> on Seaboard. Except that, the test result looks OK for me.
> 
>> As such, I haven't applied any of these. Can you please test boards for
>> all of Tegra20/30/114, and validate that on Dalmore the CPU power is
>> actually being turned off, and report back? Thanks.
> 
> I have tested all these patches based on next-20130716. And verified the
> functions on Seaboard, Cardhu and Dalmore. Looks good for me. And the
> per core power down in idle is OK too. The cluster power down only
> support when the system goes into suspend mode right now for Tegra114.
> 
> Thanks,
> Joseph
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From ezequiel.garcia at free-electrons.com  Tue Jul 16 08:14:33 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 16 Jul 2013 09:14:33 -0300
Subject: [PATCH 00/10] Orion Watchdog fixes
In-Reply-To: <20130716073101.GB25043@lunn.ch>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130716065952.GA25043@lunn.ch> <20130716092059.237ea729@skate>
 <20130716073101.GB25043@lunn.ch>
Message-ID: <20130716121432.GA2317@localhost>

Hi Thomas, Andrew:

Thanks for looking at this!

On Tue, Jul 16, 2013 at 09:31:01AM +0200, Andrew Lunn wrote:
> On Tue, Jul 16, 2013 at 09:20:59AM +0200, Thomas Petazzoni wrote:
> > 
> > On Tue, 16 Jul 2013 08:59:52 +0200, Andrew Lunn wrote:
> > 
> > > Maybe i'm missing something here. You are making use of
> > > orion_timer_ctrl_clrset() from time-orion.c. How will this work on
> > > 370/XP which has a different clocksource driver?
> > 
> > I *think* the idea is that the Armada 370/XP driver will expose the
> > same function, so from the point of view of the watchdog driver, it
> > will just work.

Indeed that was one of the ideas. As Thomas said, this was just
preparation work.

> 
> That was what i was thinking would happen. And then i started to
> wonder how well the kernel linker deals with multiple definitions of
> the same symbol. Dove and 370/XP can end up in the same kernel. So we
> need to have both orion-timer and the 370/XP timer in the same kernel,
> so we end up with the same symbol in the kernel twice...
> 

Yeah, well... I wasn't sure about using the same name, so another approach
would be adding a new compatible to the driver and then make it use the
appropriate function in the 370/XP clocksource driver (with a different name).

And, yet another approach, is what Sebastian just said, although I'm
not sure I understood it :). In any case, we have already several solutions,
which is why I'm not too worried about this particular issue.

On the other side, I'm much interested in knowing if you are OK with
breaking the watchdog DT compatibility. If you NACK this, then I'll
start preparing a different watchdog driver for 370/XP, since I don't
want to extend a driver that is a bit dirty.

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From shawn.guo at linaro.org  Tue Jul 16 08:15:39 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 20:15:39 +0800
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <1373968279.4327.13.camel@pizza.hi.pengutronix.de>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <20130716065130.GB30067@S2101-09.ap.freescale.net>
 <1373968279.4327.13.camel@pizza.hi.pengutronix.de>
Message-ID: <20130716121537.GK28375@S2101-09.ap.freescale.net>

On Tue, Jul 16, 2013 at 11:51:19AM +0200, Philipp Zabel wrote:
> Looks good to me. I can squash it into the original patch and resend if
> you like.

Yes, please.  Thanks.

Shawn



From ezequiel.garcia at free-electrons.com  Tue Jul 16 08:17:44 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 16 Jul 2013 09:17:44 -0300
Subject: [PATCH 00/10] Orion Watchdog fixes
In-Reply-To: <13fe673f255.2784.107cef0f820c2f5d7b7f41463071c310@gmail.com>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130716065952.GA25043@lunn.ch> <20130716092059.237ea729@skate>
 <20130716073101.GB25043@lunn.ch>
 <13fe673f255.2784.107cef0f820c2f5d7b7f41463071c310@gmail.com>
Message-ID: <20130716121743.GB2317@localhost>

Hi Sebastian,

On Tue, Jul 16, 2013 at 09:48:56AM +0200, Sebastian Hesselbarth wrote:
> 
> In the discussion about orion clocksource Russell was proposing a generic 
> thread-safe write. That puts a single lock around all those writes. Of 
> course, it will also blocked by totally unrelated thread-safe register 
> accesses but should prevent us from having dozens of locks and solves the 
> symbol issue.
> 

Thanks for the insight! I'll try to dig this suggestion in the clocksource
discussion. Do you have any plans for posting the clocksource soon?
This way I can base this series on something that's in Jason's trees...

Thanks!
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From weiyj.lk at gmail.com  Tue Jul 16 08:17:45 2013
From: weiyj.lk at gmail.com (Wei Yongjun)
Date: Tue, 16 Jul 2013 20:17:45 +0800
Subject: [PATCH -next] clk: sunxi: fix return value check
Message-ID: <CAPgLHd_RTeUgZtsLd=GqW7tG0q-ccDcd8gBNgDxo3E8qLE141g@mail.gmail.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

In case of error, the function clk_register_composite() and
clk_register_factors() returns ERR_PTR() not NULL. The NULL test
in the return value check should be replaced with IS_ERR().

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
 drivers/clk/sunxi/clk-sunxi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 412912b..02e440b 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -64,7 +64,7 @@ static void __init sunxi_osc_clk_setup(struct device_node *node)
 			&gate->hw, &clk_gate_ops,
 			CLK_IS_ROOT);
 
-	if (clk) {
+	if (!IS_ERR(clk)) {
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
 		clk_register_clkdev(clk, clk_name, NULL);
 	}
@@ -221,7 +221,7 @@ static void __init sunxi_factors_clk_setup(struct device_node *node,
 	clk = clk_register_factors(NULL, clk_name, parent, 0, reg,
 				   data->table, data->getter, &clk_lock);
 
-	if (clk) {
+	if (!IS_ERR(clk)) {
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
 		clk_register_clkdev(clk, clk_name, NULL);
 	}



From maxime.ripard at free-electrons.com  Tue Jul 16 08:22:37 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 16 Jul 2013 14:22:37 +0200
Subject: [PATCH -next] clk: sunxi: fix return value check
In-Reply-To: <CAPgLHd_RTeUgZtsLd=GqW7tG0q-ccDcd8gBNgDxo3E8qLE141g@mail.gmail.com>
References: <CAPgLHd_RTeUgZtsLd=GqW7tG0q-ccDcd8gBNgDxo3E8qLE141g@mail.gmail.com>
Message-ID: <20130716122237.GF3125@lukather>

Hi Wei,

On Tue, Jul 16, 2013 at 08:17:45PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> 
> In case of error, the function clk_register_composite() and
> clk_register_factors() returns ERR_PTR() not NULL. The NULL test
> in the return value check should be replaced with IS_ERR().
> 
> Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Thanks for this patch, but Axel Lin already sent a equivalent patch for
this issue last week:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/183138.html

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130716/db544376/attachment.sig>

From otavio at ossystems.com.br  Tue Jul 16 08:24:10 2013
From: otavio at ossystems.com.br (Otavio Salvador)
Date: Tue, 16 Jul 2013 09:24:10 -0300
Subject: [PATCH 1/5] ARM: dts: imx23-evk: enable USB PHY and controller
In-Reply-To: <CAOMZO5D+szAgY6+CHjwFRw2qwvusv2_Ach0hv=hj4X1cmMnHfA@mail.gmail.com>
References: <1373898160-8460-1-git-send-email-otavio@ossystems.com.br>
 <CAOMZO5D+szAgY6+CHjwFRw2qwvusv2_Ach0hv=hj4X1cmMnHfA@mail.gmail.com>
Message-ID: <CAP9ODKpByXLm1xkbfxJoktYr2ZNSD1cwNmtV95pfnjQ0jgeWYg@mail.gmail.com>

On Tue, Jul 16, 2013 at 12:42 AM, Fabio Estevam <festevam at gmail.com> wrote:
> On Mon, Jul 15, 2013 at 11:22 AM, Otavio Salvador
> <otavio at ossystems.com.br> wrote:
>> The i.MX23EVK board provides a USB port so the USB PHY and controller
>> need to be enabled for it to be usable.
>
> Has this been tested? I don't see in this patch any code to enable USB power.

It does, I am using it.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750


From tony at atomide.com  Tue Jul 16 08:24:32 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 05:24:32 -0700
Subject: [PATCH 2/4] arm: omap5: hwmod: add missing ocp2scp hwmod data
In-Reply-To: <20130715154603.GC32035@arwen.pp.htv.fi>
References: <1373902423-28654-1-git-send-email-balbi@ti.com>
 <1373902423-28654-3-git-send-email-balbi@ti.com>
 <51E418A4.9000109@ti.com> <20130715154603.GC32035@arwen.pp.htv.fi>
Message-ID: <20130716122432.GX7656@atomide.com>

* Felipe Balbi <balbi at ti.com> [130715 08:52]:
> On Mon, Jul 15, 2013 at 09:13:32PM +0530, Kishon Vijay Abraham I wrote:
> > Hi,
> > 
> > On Monday 15 July 2013 09:03 PM, Felipe Balbi wrote:
> > > From: Benoit Cousson <benoit.cousson at linaro.org>
> > > 
> > > without that hwmod data, USB3 will not in OMAP5 boards.
> > > 
> > > While at that, also fix DTS data to pass reg property,
> > > otherwise driver won't probe.
> > > 
> > > Signed-off-by: Benoit Cousson <benoit.cousson at linaro.org>
> > > Signed-off-by: Felipe Balbi <balbi at ti.com>
> > > ---
> > >  arch/arm/boot/dts/omap5.dtsi               |  3 +-
> > >  arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45 ++++++++++++++++++++++++++++++
> > >  2 files changed, 47 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> > > index 5c99f19..4e41409 100644
> > > --- a/arch/arm/boot/dts/omap5.dtsi
> > > +++ b/arch/arm/boot/dts/omap5.dtsi
> > > @@ -652,10 +652,11 @@
> > >  			};
> > >  		};
> > >  
> > > -		ocp2scp {
> > > +		ocp2scp at 4a080000 {
> > 
> > While at that, can we also name it ocp2scp1 since we have 3 instances of
> > ocp2scp and it'll conflict when we want to add it for SATA and PCIE.

Hmm the differentiatior is the name, so ocp2scp at 4a800000 should
be enough and actually follows the naming standars where the name
should describe the type. I guess it could be just ocp at 4a080000
or scp at 4a080000 but I think it translates both ways, so ocp2scp
is probably pretty good.
 
> Tony/Benoit, you want that in same patch or as a separate patch
> altogether ?

Please do the .dts changes in separate patches as they should
get merged separately for most part.

Regards,

Tony


From otavio at ossystems.com.br  Tue Jul 16 08:25:16 2013
From: otavio at ossystems.com.br (Otavio Salvador)
Date: Tue, 16 Jul 2013 09:25:16 -0300
Subject: [PATCH 1/5] ARM: dts: imx23-evk: enable USB PHY and controller
In-Reply-To: <20130716013002.GC28375@S2101-09.ap.freescale.net>
References: <1373898160-8460-1-git-send-email-otavio@ossystems.com.br>
 <CAOMZO5C_7nJ9RVYvuKJHP2u0mYY6P2UyGVA6OpPzqTnd7YXN2Q@mail.gmail.com>
 <CAP9ODKpr82mMoxhiv=K70RKdn01b=ZM2J9E4vV-AM5nwXxUR+g@mail.gmail.com>
 <20130716013002.GC28375@S2101-09.ap.freescale.net>
Message-ID: <CAP9ODKqrXBybj=Xk5NsXQRvyOWppCEgR+CgzB1C=d0v2NXj4AQ@mail.gmail.com>

On Mon, Jul 15, 2013 at 10:30 PM, Shawn Guo <shawn.guo at linaro.org> wrote:
> On Mon, Jul 15, 2013 at 01:39:13PM -0300, Otavio Salvador wrote:
>> On Mon, Jul 15, 2013 at 12:39 PM, Fabio Estevam <festevam at gmail.com> wrote:
>> > Hi Otavio,
>> >
>> > On Mon, Jul 15, 2013 at 11:22 AM, Otavio Salvador
>> > <otavio at ossystems.com.br> wrote:
>> >> The i.MX23EVK board provides a USB port so the USB PHY and controller
>> >> need to be enabled for it to be usable.
>> >>
>> >> Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
>> >> ---
>> >
>> > You should have Cc'd Shawn Guo on this series.
>>
>> Oh; thanks for fix my mistake. I am new to kernel development :-)
>
> I'm on copy of patches 1, 3 and 4.  2 and 5 are missing?

I will prepare a v2, as per Jonathan feedback and will add you in all them.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750


From sergei.shtylyov at cogentembedded.com  Tue Jul 16 08:28:37 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 16 Jul 2013 16:28:37 +0400
Subject: [PATCH v4 0/3]  ARM: shmobile: lager: enable Ether
In-Reply-To: <7990652.CKWzcoj3FL@avalon>
References: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
 <7990652.CKWzcoj3FL@avalon>
Message-ID: <51E53C75.10904@cogentembedded.com>

Hello.

On 16-07-2013 13:42, Laurent Pinchart wrote:

>> this short series enables the on-board ethernet
>> of the r8a7790 SoC for on lager board.

>> It has a run-time dependency on
>> "sh_eth: add support for r8a7790 SoC"

>> It has been built on top of renesas-next-20130701.

> Do you plan to respin this series on top of your latest devel branch ? I've
> quickly rebased it and now get receive FIFO overflows when booting over NFS,
> followed by the kernel disabling the sh-eth IRQ.

    That disabling of IRQ should have been fixed in 3.10.

WBR, Sergei



From tony at atomide.com  Tue Jul 16 08:32:56 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 05:32:56 -0700
Subject: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock
In-Reply-To: <51E40199.9070906@ti.com>
References: <1371571487-14389-1-git-send-email-rogerq@ti.com>
 <1371571487-14389-5-git-send-email-rogerq@ti.com>
 <51E40199.9070906@ti.com>
Message-ID: <20130716123256.GY7656@atomide.com>

* Roger Quadros <rogerq at ti.com> [130715 07:11]:
> Hi Tony,
> 
> On 06/18/2013 07:04 PM, Roger Quadros wrote:
> > Till the OMAP clocks are correctly defined in device tree, use
> > this temporary hack to provide clock alias to the USB PHY clocks.
> > 
> > Without this, USB Host & Ethernet will not be functional with
> > device tree boots on Panda and uEVM.
> 
> Looks like this one got missed out.
> 
> USB host no longer works on Panda with DT boot.
> Could you please queue this for next 3.11-rc? Thanks.

OK thanks for checking, applying into omap-for-v3.11/fixes.

Looks like I also have some pending the .dts changes in
omap-for-v3.11/dt branch:

4cf2198b1e3cee47a1cccbb500b67782c36615d5 ARM: dts: omap3-beagle-xm: Add USB host supprot for Rev. Ax/Bx
9bc44515819a00c0ffaf751ad497ddf275089ede ARM: dts: omap3-beagle-xm: Add USB Host support
fd65d7df4598c1d2ad27d664c719611a1a070edc ARM: dts: omap3-beagle: Make USB host pin naming consistent
39ea891d9da6ae1824bc9f689db3f306f5ce0724 ARM: dts: omap4-panda: Add USB Host support

Those should get merged as fixes, right? Can you please
check and see if they're still OK or if we also need
something else?

Regards,

Tony


From balbi at ti.com  Tue Jul 16 08:37:09 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 16 Jul 2013 15:37:09 +0300
Subject: Division by zero caused by CCF
Message-ID: <20130716123709.GA15036@arwen.pp.htv.fi>

Hi,

trying to get USB host verified on OMAP5 uEVM with v3.11-rc1. The
clk_set_rate() call ends up in a division by zero, which is quite
interesting provided the driver will only call clk_set_rate() if the
clock is valid and clk_rate is != 0.


[   22.009238] Division by zero in kernel.
[   22.009250] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W    3.11.0-rc1-00081-g3310d44-dirty #118
[   22.009275] [<c001c83c>] (unwind_backtrace+0x0/0xf0) from [<c0018a1c>] (show_stack+0x10/0x14)
[   22.009289] [<c0018a1c>] (show_stack+0x10/0x14) from [<c057403c>] (dump_stack+0x70/0x8c)
[   22.009304] [<c057403c>] (dump_stack+0x70/0x8c) from [<c02e4154>] (Ldiv0+0x8/0x10)
[   22.009319] [<c02e4154>] (Ldiv0+0x8/0x10) from [<c048d460>] (clk_divider_set_rate+0x10/0xdc)
[   22.009331] [<c048d460>] (clk_divider_set_rate+0x10/0xdc) from [<c048c124>] (clk_change_rate+0x38/0xb0)
[   22.009341] [<c048c124>] (clk_change_rate+0x38/0xb0) from [<c048c20c>] (clk_set_rate+0x70/0xa8)
[   22.009354] [<c048c20c>] (clk_set_rate+0x70/0xa8) from [<c042b244>] (nop_usb_xceiv_probe+0x1fc/0x2f8)
[   22.009369] [<c042b244>] (nop_usb_xceiv_probe+0x1fc/0x2f8) from [<c036b47c>] (platform_drv_probe+0x18/0x1c)
[   22.009380] [<c036b47c>] (platform_drv_probe+0x18/0x1c) from [<c0369f44>] (really_probe+0x70/0x1f4)
[   22.009390] [<c0369f44>] (really_probe+0x70/0x1f4) from [<c036a1dc>] (driver_probe_device+0x30/0x48)
[   22.009401] [<c036a1dc>] (driver_probe_device+0x30/0x48) from [<c036a288>] (__driver_attach+0x94/0x98)
[   22.009411] [<c036a288>] (__driver_attach+0x94/0x98) from [<c0368748>] (bus_for_each_dev+0x54/0x88)
[   22.009420] [<c0368748>] (bus_for_each_dev+0x54/0x88) from [<c036972c>] (bus_add_driver+0xdc/0x29c)
[   22.009430] [<c036972c>] (bus_add_driver+0xdc/0x29c) from [<c036a760>] (driver_register+0x78/0x190)
[   22.009440] [<c036a760>] (driver_register+0x78/0x190) from [<c00087b0>] (do_one_initcall+0x34/0x164)
[   22.009453] [<c00087b0>] (do_one_initcall+0x34/0x164) from [<c07b18f4>] (do_basic_setup+0x90/0xc4)
[   22.009466] [<c07b18f4>] (do_basic_setup+0x90/0xc4) from [<c07b199c>] (kernel_init_freeable+0x74/0x110)
[   22.009478] [<c07b199c>] (kernel_init_freeable+0x74/0x110) from [<c05676c4>] (kernel_init+0x8/0xe4)
[   22.009491] [<c05676c4>] (kernel_init+0x8/0xe4) from [<c0014648>] (ret_from_fork+0x14/0x2c)

I believe the problem is the actual division reaching
clk_divider_set_rate().

drivers/clk/clk-divider.c::clk_divider_set_rate()

| static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
|                                 unsigned long parent_rate)
| {
|         struct clk_divider *divider = to_clk_divider(hw);
|         unsigned int div, value;
|         unsigned long flags = 0;
|         u32 val;
| 
|         div = parent_rate / rate;

right here, but how come rate would zero provided driver checks for it
as below.

drivers/usb/phy/phy-nop.c::nop_usb_xceiv_probe()

|         if (!IS_ERR(nop->clk) && clk_rate) {
|                 err = clk_set_rate(nop->clk, clk_rate);
|                 if (err) {
|                         dev_err(&pdev->dev, "Error setting clock rate\n");
|                         return err;
|                 }
|         }

I've added a few prints around CCF to try and track what's going on:

[   21.592690] ====> nop_usb_xceiv_probe rate 19200000
[   21.592700] ====> clk_set_rate rate 19200000
[   21.592707] ====> clk_calc_new_rates rate 19200000
[   21.592713] ====> clk_divider_round_rate rate 19200000
[   21.592719] ====> clk_divider_bestdiv rate 19200000
[   21.592726] ====> clk_change_rate best_parent_rate 0
[   21.592732] ====> clk_divider_set_rate rate 0
[   21.592737] Division by zero in kernel.
[   21.592747] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W    3.11.0-rc1-00081-g3310d44-dirty #121
[   21.592773] [<c001c83c>] (unwind_backtrace+0x0/0xf0) from [<c0018a1c>] (show_stack+0x10/0x14)
[   21.592787] [<c0018a1c>] (show_stack+0x10/0x14) from [<c057400c>] (dump_stack+0x70/0x8c)
[   21.592803] [<c057400c>] (dump_stack+0x70/0x8c) from [<c02e4154>] (Ldiv0+0x8/0x10)
[   21.592819] [<c02e4154>] (Ldiv0+0x8/0x10) from [<c048d3e0>] (clk_divider_set_rate+0x2c/0x100)
[   21.592831] [<c048d3e0>] (clk_divider_set_rate+0x2c/0x100) from [<c048c050>] (clk_change_rate+0x48/0xe0)
[   21.592841] [<c048c050>] (clk_change_rate+0x48/0xe0) from [<c048c174>] (clk_set_rate+0x8c/0xc0)
[   21.592855] [<c048c174>] (clk_set_rate+0x8c/0xc0) from [<c042b254>] (nop_usb_xceiv_probe+0x20c/0x304)
[   21.592869] [<c042b254>] (nop_usb_xceiv_probe+0x20c/0x304) from [<c036b47c>] (platform_drv_probe+0x18/0x1c)
[   21.592880] [<c036b47c>] (platform_drv_probe+0x18/0x1c) from [<c0369f44>] (really_probe+0x70/0x1f4)
[   21.592891] [<c0369f44>] (really_probe+0x70/0x1f4) from [<c036a1dc>] (driver_probe_device+0x30/0x48)
[   21.592901] [<c036a1dc>] (driver_probe_device+0x30/0x48) from [<c036a288>] (__driver_attach+0x94/0x98)
[   21.592911] [<c036a288>] (__driver_attach+0x94/0x98) from [<c0368748>] (bus_for_each_dev+0x54/0x88)
[   21.592921] [<c0368748>] (bus_for_each_dev+0x54/0x88) from [<c036972c>] (bus_add_driver+0xdc/0x29c)
[   21.592930] [<c036972c>] (bus_add_driver+0xdc/0x29c) from [<c036a760>] (driver_register+0x78/0x190)
[   21.592941] [<c036a760>] (driver_register+0x78/0x190) from [<c00087b0>] (do_one_initcall+0x34/0x164)
[   21.592954] [<c00087b0>] (do_one_initcall+0x34/0x164) from [<c07b18f4>] (do_basic_setup+0x90/0xc4)
[   21.592966] [<c07b18f4>] (do_basic_setup+0x90/0xc4) from [<c07b199c>] (kernel_init_freeable+0x74/0x110)
[   21.592980] [<c07b199c>] (kernel_init_freeable+0x74/0x110) from [<c0567694>] (kernel_init+0x8/0xe4)
[   21.592992] [<c0567694>] (kernel_init+0x8/0xe4) from [<c0014648>] (ret_from_fork+0x14/0x2c)

even though driver passed 19.2MHz, best_parent_rate ends up being zero
which triggers the division by zero above.

cheers

-- 
balbi
-------------- 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/20130716/a4ee87da/attachment.sig>

From kishon at ti.com  Tue Jul 16 08:38:26 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 16 Jul 2013 18:08:26 +0530
Subject: [GIT PULL] PHY Framework for 3.12 merge window
Message-ID: <51E53EC2.5080401@ti.com>

Hi Greg,

Here's the pull request for the PHY Framework which I've been working on for a
while.

I've applied these patches on the current linux mainline HEAD (which has one
commit after 3.11-rc1 is tagged).

Even before this framework is merged, quite a few people started using it. I've
queued those patches along with the PHY framework as well.

I'm also planning to maintain this framework henceforth and will be sending
pull requests for anything related to this framework or users of this framework.

Let me know if you want any changes on this pull request

Thanks
Kishon

The following changes since commit 47188d39b5deeebf41f87a02af1b3935866364cf:

  Merge tag 'ext4_for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2013-07-14 21:47:51
-0700)

are available in the git repository at:


  git://gitorious.org/linuxphy/linuxphy.git tags/phy-for-v3.12

for you to fetch changes up to 827c292242da5723345e5649e38279c721125ca8:

  video: exynos_dp: Use the generic PHY driver (2013-07-16 14:37:04 +0530)

----------------------------------------------------------------
PHY: patches for 3.12 merge window

We're introducing a new kernel wide generic PHY framework.

This framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a
reference to the PHY with or without using phandle.

This framework will be of use only to devices that uses external PHY (PHY
functionality is not embedded within the controller).

The intention of creating this framework is to bring the phy drivers spread
all over the Linux kernel to drivers/phy to increase code re-use and for
better code maintainability.

There are already quite a few users for this framework.
Samsung Exynos SoC Display Port PHY and MIPI PHY are some of the early users
of this framework in addition to OMAP-USB2 PHY and TWL4030-USB.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>

----------------------------------------------------------------
Jingoo Han (3):
      phy: Add driver for Exynos DP PHY
      video: exynos_dp: remove non-DT support for Exynos Display Port
      video: exynos_dp: Use the generic PHY driver

Kishon Vijay Abraham I (8):
      drivers: phy: add generic PHY framework
      usb: phy: omap-usb2: use the new generic PHY framework
      usb: phy: twl4030: use the new generic PHY framework
      ARM: OMAP: USB: Add phy binding information
      ARM: dts: omap: update usb_otg_hs data
      usb: musb: omap2430: use the new generic PHY framework
      usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
      usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

Sylwester Nawrocki (4):
      phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
      video: exynos_mipi_dsim: Use the generic PHY driver
      exynos4-is: Use the generic MIPI CSIS PHY driver
      ARM: Samsung: Remove the MIPI PHY setup code

 .../devicetree/bindings/phy/phy-bindings.txt       |   66 +++
 .../devicetree/bindings/phy/samsung-phy.txt        |   22 +
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 +
 .../devicetree/bindings/video/exynos_dp.txt        |   12 +-
 Documentation/phy.txt                              |  129 +++++
 MAINTAINERS                                        |    7 +
 arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 +
 arch/arm/boot/dts/omap3-evm.dts                    |    2 +
 arch/arm/boot/dts/omap3-overo.dtsi                 |    2 +
 arch/arm/boot/dts/omap4.dtsi                       |    3 +
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 arch/arm/mach-exynos/include/mach/regs-pmu.h       |    5 -
 arch/arm/mach-omap2/usb-musb.c                     |    3 +
 arch/arm/mach-s5pv210/include/mach/regs-clock.h    |    4 -
 arch/arm/plat-samsung/Kconfig                      |    5 -
 arch/arm/plat-samsung/Makefile                     |    1 -
 arch/arm/plat-samsung/setup-mipiphy.c              |   60 ---
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/media/platform/exynos4-is/mipi-csis.c      |   16 +-
 drivers/phy/Kconfig                                |   28 +
 drivers/phy/Makefile                               |    7 +
 drivers/phy/phy-core.c                             |  544 ++++++++++++++++++++
 drivers/phy/phy-exynos-dp-video.c                  |  111 ++++
 drivers/phy/phy-exynos-mipi-video.c                |  169 ++++++
 drivers/usb/musb/Kconfig                           |    1 +
 drivers/usb/musb/musb_core.c                       |    1 +
 drivers/usb/musb/musb_core.h                       |    3 +
 drivers/usb/musb/omap2430.c                        |   26 +-
 drivers/usb/phy/Kconfig                            |    1 +
 drivers/usb/phy/phy-omap-usb2.c                    |   60 ++-
 drivers/usb/phy/phy-twl4030-usb.c                  |   63 ++-
 drivers/video/exynos/Kconfig                       |    2 +-
 drivers/video/exynos/exynos_dp_core.c              |  132 ++---
 drivers/video/exynos/exynos_dp_core.h              |  110 ++++
 drivers/video/exynos/exynos_dp_reg.c               |    2 -
 drivers/video/exynos/exynos_mipi_dsi.c             |   19 +-
 include/linux/phy/phy.h                            |  344 +++++++++++++
 include/linux/platform_data/mipi-csis.h            |   11 +-
 include/linux/usb/musb.h                           |    3 +
 include/video/exynos_dp.h                          |  131 -----
 include/video/exynos_mipi_dsim.h                   |    6 +-
 43 files changed, 1746 insertions(+), 383 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/devicetree/bindings/phy/samsung-phy.txt
 create mode 100644 Documentation/phy.txt
 delete mode 100644 arch/arm/plat-samsung/setup-mipiphy.c
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 drivers/phy/phy-exynos-dp-video.c
 create mode 100644 drivers/phy/phy-exynos-mipi-video.c
 create mode 100644 include/linux/phy/phy.h
 delete mode 100644 include/video/exynos_dp.h


From jonas.jensen at gmail.com  Tue Jul 16 08:41:25 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Tue, 16 Jul 2013 14:41:25 +0200
Subject: [PATCH v3] rtc: Add MOXA ART RTC driver
In-Reply-To: <1373550711-18828-1-git-send-email-jonas.jensen@gmail.com>
References: <1373550711-18828-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1373978485-17496-1-git-send-email-jonas.jensen@gmail.com>

Add RTC driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Thanks for the replies. This should fix the remaining issues mentioned by Mark and Arnd.
    
    Changes since v2:
    
    1. don't use hardcoded GPIO numbers, use of_get_named_gpio
    2. make two functions static, moxart_rtc_write_byte and moxart_rtc_read_byte
    3. use devm_gpio_request_one where appropriate
    4. add gpio_is_valid check to all of_get_named_gpio
    5. check devm_gpio_request return value
    6. use devm_rtc_device_register instead of rtc_device_register
    7. remove label "out" from moxart_rtc_probe
    8. remove moxart_rtc_remove function
    
    Applies to next-20130716

 drivers/rtc/Kconfig      |   9 ++
 drivers/rtc/Makefile     |   1 +
 drivers/rtc/rtc-moxart.c | 330 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 340 insertions(+)
 create mode 100644 drivers/rtc/rtc-moxart.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 9e3498b..9654aa3 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1249,6 +1249,15 @@ config RTC_DRV_SIRFSOC
 	  Say "yes" here to support the real time clock on SiRF SOC chips.
 	  This driver can also be built as a module called rtc-sirfsoc.
 
+config RTC_DRV_MOXART
+	tristate "MOXA ART RTC"
+	help
+	   If you say yes here you get support for the MOXA ART
+	   RTC module.
+
+	   This driver can also be built as a module. If so, the module
+	   will be called rtc-moxart
+
 comment "HID Sensor RTC drivers"
 
 config RTC_DRV_HID_SENSOR_TIME
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index d3b4488..2dff3d2 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -130,3 +130,4 @@ obj-$(CONFIG_RTC_DRV_WM831X)	+= rtc-wm831x.o
 obj-$(CONFIG_RTC_DRV_WM8350)	+= rtc-wm8350.o
 obj-$(CONFIG_RTC_DRV_X1205)	+= rtc-x1205.o
 obj-$(CONFIG_RTC_DRV_SIRFSOC)	+= rtc-sirfsoc.o
+obj-$(CONFIG_RTC_DRV_MOXART)	+= rtc-moxart.o
diff --git a/drivers/rtc/rtc-moxart.c b/drivers/rtc/rtc-moxart.c
new file mode 100644
index 0000000..c29dee0
--- /dev/null
+++ b/drivers/rtc/rtc-moxart.c
@@ -0,0 +1,330 @@
+/*
+ * MOXA ART RTC driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/rtc.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+
+#define GPIO_RTC_RESERVED			0x0C
+#define GPIO_RTC_DATA_SET			0x10
+#define GPIO_RTC_DATA_CLEAR			0x14
+#define GPIO_RTC_PIN_PULL_ENABLE		0x18
+#define GPIO_RTC_PIN_PULL_TYPE			0x1C
+#define GPIO_RTC_INT_ENABLE			0x20
+#define GPIO_RTC_INT_RAW_STATE			0x24
+#define GPIO_RTC_INT_MASKED_STATE		0x28
+#define GPIO_RTC_INT_MASK			0x2C
+#define GPIO_RTC_INT_CLEAR			0x30
+#define GPIO_RTC_INT_TRIGGER			0x34
+#define GPIO_RTC_INT_BOTH			0x38
+#define GPIO_RTC_INT_RISE_NEG			0x3C
+#define GPIO_RTC_BOUNCE_ENABLE			0x40
+#define GPIO_RTC_BOUNCE_PRE_SCALE		0x44
+#define GPIO_RTC_PROTECT_W			0x8E
+#define GPIO_RTC_PROTECT_R			0x8F
+#define GPIO_RTC_YEAR_W				0x8C
+#define GPIO_RTC_YEAR_R				0x8D
+#define GPIO_RTC_DAY_W				0x8A
+#define GPIO_RTC_DAY_R				0x8B
+#define GPIO_RTC_MONTH_W			0x88
+#define GPIO_RTC_MONTH_R			0x89
+#define GPIO_RTC_DATE_W				0x86
+#define GPIO_RTC_DATE_R				0x87
+#define GPIO_RTC_HOURS_W			0x84
+#define GPIO_RTC_HOURS_R			0x85
+#define GPIO_RTC_MINUTES_W			0x82
+#define GPIO_RTC_MINUTES_R			0x83
+#define GPIO_RTC_SECONDS_W			0x80
+#define GPIO_RTC_SECONDS_R			0x81
+#define GPIO_RTC_DELAY_TIME			8
+
+struct moxart_rtc {
+	struct rtc_device *rtc;
+	spinlock_t rtc_lock;
+	int gpio_data, gpio_sclk, gpio_reset;
+};
+
+static int day_of_year[12] =	{ 0, 31, 59, 90, 120, 151, 181,
+				  212, 243, 273, 304, 334 };
+
+static void moxart_rtc_write_byte(struct device *dev, u8 data)
+{
+	struct moxart_rtc *moxart_rtc = dev_get_drvdata(dev);
+	int i;
+
+	for (i = 0; i < 8; i++, data >>= 1) {
+		gpio_set_value(moxart_rtc->gpio_sclk, 0);
+		gpio_set_value(moxart_rtc->gpio_data, ((data & 1) == 1));
+		udelay(GPIO_RTC_DELAY_TIME);
+		gpio_set_value(moxart_rtc->gpio_sclk, 1);
+		udelay(GPIO_RTC_DELAY_TIME);
+	}
+}
+
+static u8 moxart_rtc_read_byte(struct device *dev)
+{
+	struct moxart_rtc *moxart_rtc = dev_get_drvdata(dev);
+	int i;
+	u8 data = 0;
+
+	for (i = 0; i < 8; i++) {
+		gpio_set_value(moxart_rtc->gpio_sclk, 0);
+		udelay(GPIO_RTC_DELAY_TIME);
+		gpio_set_value(moxart_rtc->gpio_sclk, 1);
+		udelay(GPIO_RTC_DELAY_TIME);
+		if (gpio_get_value(moxart_rtc->gpio_data))
+			data |= (1 << i);
+		udelay(GPIO_RTC_DELAY_TIME);
+	}
+	return data;
+}
+
+static u8 moxart_rtc_read_register(struct device *dev, u8 cmd)
+{
+	struct moxart_rtc *moxart_rtc = dev_get_drvdata(dev);
+	u8 data;
+	unsigned long flags;
+
+	local_irq_save(flags);
+
+	gpio_direction_output(moxart_rtc->gpio_data, 0);
+	gpio_set_value(moxart_rtc->gpio_reset, 1);
+	udelay(GPIO_RTC_DELAY_TIME);
+	moxart_rtc_write_byte(dev, cmd);
+	gpio_direction_input(moxart_rtc->gpio_data);
+	udelay(GPIO_RTC_DELAY_TIME);
+	data = moxart_rtc_read_byte(dev);
+	gpio_set_value(moxart_rtc->gpio_sclk, 0);
+	gpio_set_value(moxart_rtc->gpio_reset, 0);
+	udelay(GPIO_RTC_DELAY_TIME);
+
+	local_irq_restore(flags);
+
+	return data;
+}
+
+static void moxart_rtc_write_register(struct device *dev, u8 cmd, u8 data)
+{
+	struct moxart_rtc *moxart_rtc = dev_get_drvdata(dev);
+	unsigned long flags;
+
+	local_irq_save(flags);
+
+	gpio_direction_output(moxart_rtc->gpio_data, 0);
+	gpio_set_value(moxart_rtc->gpio_reset, 1);
+	udelay(GPIO_RTC_DELAY_TIME);
+	moxart_rtc_write_byte(dev, cmd);
+	moxart_rtc_write_byte(dev, data);
+	gpio_set_value(moxart_rtc->gpio_sclk, 0);
+	gpio_set_value(moxart_rtc->gpio_reset, 0);
+	udelay(GPIO_RTC_DELAY_TIME);
+
+	local_irq_restore(flags);
+}
+
+static int moxart_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+	struct moxart_rtc *moxart_rtc = dev_get_drvdata(dev);
+
+	spin_lock_irq(&moxart_rtc->rtc_lock);
+
+	moxart_rtc_write_register(dev, GPIO_RTC_PROTECT_W, 0);
+	moxart_rtc_write_register(dev, GPIO_RTC_YEAR_W,
+				  (((tm->tm_year - 100) / 10) << 4) |
+				  ((tm->tm_year - 100) % 10));
+
+	moxart_rtc_write_register(dev, GPIO_RTC_MONTH_W,
+				  (((tm->tm_mon + 1) / 10) << 4) |
+				  ((tm->tm_mon + 1) % 10));
+
+	moxart_rtc_write_register(dev, GPIO_RTC_DATE_W,
+				  ((tm->tm_mday / 10) << 4) |
+				  (tm->tm_mday % 10));
+
+	moxart_rtc_write_register(dev, GPIO_RTC_HOURS_W,
+				  ((tm->tm_hour / 10) << 4) |
+				  (tm->tm_hour % 10));
+
+	moxart_rtc_write_register(dev, GPIO_RTC_MINUTES_W,
+				  ((tm->tm_min / 10) << 4) |
+				  (tm->tm_min % 10));
+
+	moxart_rtc_write_register(dev, GPIO_RTC_SECONDS_W,
+				  ((tm->tm_sec / 10) << 4) |
+				  (tm->tm_sec % 10));
+
+	moxart_rtc_write_register(dev, GPIO_RTC_PROTECT_W, 0x80);
+
+	spin_unlock_irq(&moxart_rtc->rtc_lock);
+
+	dev_dbg(dev, "%s: success tm_year=%d tm_mon=%d\n"
+		"tm_mday=%d tm_hour=%d tm_min=%d tm_sec=%d\n",
+		__func__, tm->tm_year, tm->tm_mon, tm->tm_mday,
+		tm->tm_hour, tm->tm_min, tm->tm_sec);
+
+	return 0;
+}
+
+static int moxart_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+	struct moxart_rtc *moxart_rtc = dev_get_drvdata(dev);
+	unsigned char v;
+
+	spin_lock_irq(&moxart_rtc->rtc_lock);
+
+	v = moxart_rtc_read_register(dev, GPIO_RTC_SECONDS_R);
+	tm->tm_sec = (((v & 0x70) >> 4) * 10) + (v & 0x0F);
+
+	v = moxart_rtc_read_register(dev, GPIO_RTC_MINUTES_R);
+	tm->tm_min = (((v & 0x70) >> 4) * 10) + (v & 0x0F);
+
+	v = moxart_rtc_read_register(dev, GPIO_RTC_HOURS_R);
+	if (v & 0x80) { /* 12-hour mode */
+		tm->tm_hour = (((v & 0x10) >> 4) * 10) + (v & 0x0F);
+		if (v & 0x20) { /* PM mode */
+			tm->tm_hour += 12;
+			if (tm->tm_hour >= 24)
+				tm->tm_hour = 0;
+		}
+	} else { /* 24-hour mode */
+		tm->tm_hour = (((v & 0x30) >> 4) * 10) + (v & 0x0F);
+	}
+
+	v = moxart_rtc_read_register(dev, GPIO_RTC_DATE_R);
+	tm->tm_mday = (((v & 0x30) >> 4) * 10) + (v & 0x0F);
+
+	v = moxart_rtc_read_register(dev, GPIO_RTC_MONTH_R);
+	tm->tm_mon = (((v & 0x10) >> 4) * 10) + (v & 0x0F);
+	tm->tm_mon--;
+
+	v = moxart_rtc_read_register(dev, GPIO_RTC_YEAR_R);
+	tm->tm_year = (((v & 0xF0) >> 4) * 10) + (v & 0x0F);
+	tm->tm_year += 100;
+	if (tm->tm_year <= 69)
+		tm->tm_year += 100;
+
+	v = moxart_rtc_read_register(dev, GPIO_RTC_DAY_R);
+	tm->tm_wday = (v & 0x0f) - 1;
+	tm->tm_yday = day_of_year[tm->tm_mon];
+	tm->tm_yday += (tm->tm_mday - 1);
+	if (tm->tm_mon >= 2) {
+		if (!(tm->tm_year % 4) && (tm->tm_year % 100))
+			tm->tm_yday++;
+	}
+
+	tm->tm_isdst = 0;
+
+	spin_unlock_irq(&moxart_rtc->rtc_lock);
+
+	return 0;
+}
+
+static const struct rtc_class_ops moxart_rtc_ops = {
+	.read_time	= moxart_rtc_read_time,
+	.set_time	= moxart_rtc_set_time,
+};
+
+static int moxart_rtc_probe(struct platform_device *pdev)
+{
+	struct moxart_rtc *moxart_rtc;
+	int ret = 0;
+
+	moxart_rtc = devm_kzalloc(&pdev->dev, sizeof(*moxart_rtc), GFP_KERNEL);
+	if (!moxart_rtc) {
+		dev_err(&pdev->dev, "devm_kzalloc failed\n");
+		return -ENOMEM;
+	}
+
+	moxart_rtc->gpio_data = of_get_named_gpio(pdev->dev.of_node,
+						  "gpio-rtc-data", 0);
+	if (!gpio_is_valid(moxart_rtc->gpio_data)) {
+		dev_err(&pdev->dev, "invalid gpio (data): %d\n",
+			moxart_rtc->gpio_data);
+		return moxart_rtc->gpio_data;
+	}
+
+	moxart_rtc->gpio_sclk = of_get_named_gpio(pdev->dev.of_node,
+						  "gpio-rtc-sclk", 0);
+	if (!gpio_is_valid(moxart_rtc->gpio_sclk)) {
+		dev_err(&pdev->dev, "invalid gpio (sclk): %d\n",
+			moxart_rtc->gpio_sclk);
+		return moxart_rtc->gpio_sclk;
+	}
+
+	moxart_rtc->gpio_reset = of_get_named_gpio(pdev->dev.of_node,
+						   "gpio-rtc-reset", 0);
+	if (!gpio_is_valid(moxart_rtc->gpio_reset)) {
+		dev_err(&pdev->dev, "invalid gpio (reset): %d\n",
+			moxart_rtc->gpio_reset);
+		return moxart_rtc->gpio_reset;
+	}
+
+	spin_lock_init(&moxart_rtc->rtc_lock);
+	platform_set_drvdata(pdev, moxart_rtc);
+
+	ret = devm_gpio_request(&pdev->dev, moxart_rtc->gpio_data, "rtc_data");
+	if (ret) {
+		dev_err(&pdev->dev, "can't get rtc_data gpio\n");
+		return ret;
+	}
+
+	ret = devm_gpio_request_one(&pdev->dev, moxart_rtc->gpio_sclk,
+				    GPIOF_DIR_OUT, "rtc_sclk");
+	if (ret) {
+		dev_err(&pdev->dev, "can't get rtc_sclk gpio\n");
+		return ret;
+	}
+
+	ret = devm_gpio_request_one(&pdev->dev, moxart_rtc->gpio_reset,
+				    GPIOF_DIR_OUT, "rtc_reset");
+	if (ret) {
+		dev_err(&pdev->dev, "can't get rtc_reset gpio\n");
+		return ret;
+	}
+
+	moxart_rtc->rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
+						   &moxart_rtc_ops,
+						   THIS_MODULE);
+	if (IS_ERR(moxart_rtc->rtc)) {
+		dev_err(&pdev->dev, "devm_rtc_device_register failed\n");
+		return PTR_ERR(moxart_rtc->rtc);
+	}
+
+	return 0;
+}
+
+static const struct of_device_id moxart_rtc_match[] = {
+	{ .compatible = "moxa,moxart-rtc" },
+	{ },
+};
+
+static struct platform_driver moxart_rtc_driver = {
+	.probe	= moxart_rtc_probe,
+	.driver	= {
+		.name		= "moxart-rtc",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_rtc_match,
+	},
+};
+module_platform_driver(moxart_rtc_driver);
+
+MODULE_DESCRIPTION("MOXART RTC driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From balbi at ti.com  Tue Jul 16 08:42:27 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 16 Jul 2013 15:42:27 +0300
Subject: [PATCH v2 0/4] usb: musb: fix USB enumeration issue in OMAP3
 platform
In-Reply-To: <51E4DFA6.2010501@ti.com>
References: <1373282057-20181-1-git-send-email-kishon@ti.com>
 <51E4DFA6.2010501@ti.com>
Message-ID: <20130716124227.GC15036@arwen.pp.htv.fi>

Hi,

On Tue, Jul 16, 2013 at 11:22:38AM +0530, Kishon Vijay Abraham I wrote:
> Tony,
> 
> On Monday 08 July 2013 04:44 PM, Kishon Vijay Abraham I wrote:
> > This series fixes the USB enumeration issue caused because of the controller
> > not able to get a reference to the PHY because of incorrect binding in the
> > board file.
> > 
> > In the case of non-dt boot, the platform specific initialization file
> > (board file) will do usb_bind_phy that binds the usb controller with the
> > PHY using device names. After the device names are created using 
> > PLATFORM_DEVID_AUTO, our original method of binding by device names doesn't
> > work reliably (since the device name changes). Hence the usb controller
> > is made to use labels for getting the PHY.
> > 
> > Here the PHY name is added in the plat data of USB controller device which
> > should be used by the controller driver to get the PHY.
> > Two new APIs usb_get_phy_by_name and devm_usb_get_phy_by_name are added to
> > be used by the controller to get the PHY by name.
> 
> You haven't picked this patch series?

yeah and now it's too much to send during the -rc series. Here's what we
can do, we can to minimum fix for -rc series (patching the names again)
and I'll queue everything else for mailine if tony gives me his Ack for
all arch/arm/*omap* parts.

Sounds good ?

-- 
balbi
-------------- 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/20130716/376cd3a8/attachment.sig>

From tony at atomide.com  Tue Jul 16 08:44:43 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 05:44:43 -0700
Subject: [PATCH v2 1/4] arm: omap: Add phy binding info for musb in
 plat data
In-Reply-To: <1373282057-20181-2-git-send-email-kishon@ti.com>
References: <1373282057-20181-1-git-send-email-kishon@ti.com>
 <1373282057-20181-2-git-send-email-kishon@ti.com>
Message-ID: <20130716124442.GZ7656@atomide.com>

* Kishon Vijay Abraham I <kishon at ti.com> [130708 04:20]:
> In order for controllers to get PHY in case of non dt boot, the phy
> binding information (phy label) should be added in the platform
> data of the controller.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> Acked-by: Felipe Balbi <balbi at ti.com>
> Tested-by: Tomi Valkeinen <tomi.valkeinen at ti.com>

Acked-by: Tony Lindgren <tony at atomide.com>

> ---
>  arch/arm/mach-omap2/usb-musb.c |    3 +++
>  include/linux/usb/musb.h       |    3 +++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> index 8c4de27..20b42de 100644
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -85,6 +85,9 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
>  	musb_plat.mode = board_data->mode;
>  	musb_plat.extvbus = board_data->extvbus;
>  
> +	if (cpu_is_omap34xx())
> +		musb_plat.phy_name = "twl4030";
> +
>  	if (soc_is_am35xx()) {
>  		oh_name = "am35x_otg_hs";
>  		name = "musb-am35x";
> diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
> index 053c268..c05d46d 100644
> --- a/include/linux/usb/musb.h
> +++ b/include/linux/usb/musb.h
> @@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
>  	/* for clk_get() */
>  	const char	*clock;
>  
> +	/* phy device label */
> +	const char	*phy_name;
> +
>  	/* (HOST or OTG) switch VBUS on/off */
>  	int		(*set_vbus)(struct device *dev, int is_on);
>  
> -- 
> 1.7.10.4
> 


From tony at atomide.com  Tue Jul 16 08:46:18 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 05:46:18 -0700
Subject: [PATCH v2 4/4] arm: omap: remove using usb_bind_phy for
 binding musb and phy
In-Reply-To: <1373282057-20181-5-git-send-email-kishon@ti.com>
References: <1373282057-20181-1-git-send-email-kishon@ti.com>
 <1373282057-20181-5-git-send-email-kishon@ti.com>
Message-ID: <20130716124618.GA7656@atomide.com>

* Kishon Vijay Abraham I <kishon at ti.com> [130708 04:21]:
> Now that MUSB for OMAP started using devm_usb_get_phy_by_name
> which does not require PHY library to already have the binding
> information, removed usb_bind_phy calls that binds the MUSB controller
> with the PHY from the board files.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> Acked-by: Felipe Balbi <balbi at ti.com>
> Tested-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
>
> ---
>  arch/arm/mach-omap2/board-2430sdp.c          |    1 -
>  arch/arm/mach-omap2/board-3430sdp.c          |    1 -
>  arch/arm/mach-omap2/board-cm-t35.c           |    1 -
>  arch/arm/mach-omap2/board-devkit8000.c       |    1 -
>  arch/arm/mach-omap2/board-igep0020.c         |    1 -
>  arch/arm/mach-omap2/board-ldp.c              |    1 -
>  arch/arm/mach-omap2/board-omap3beagle.c      |    1 -
>  arch/arm/mach-omap2/board-omap3evm.c         |    1 -
>  arch/arm/mach-omap2/board-omap3logic.c       |    1 -
>  arch/arm/mach-omap2/board-omap3pandora.c     |    1 -
>  arch/arm/mach-omap2/board-omap3stalker.c     |    1 -
>  arch/arm/mach-omap2/board-omap3touchbook.c   |    1 -
>  arch/arm/mach-omap2/board-overo.c            |    1 -
>  arch/arm/mach-omap2/board-rm680.c            |    1 -
>  arch/arm/mach-omap2/board-rx51.c             |    1 -
>  arch/arm/mach-omap2/board-zoom-peripherals.c |    1 -
>  16 files changed, 16 deletions(-)

It's best that I queue this as a follow up patch after
the other patches are merged. Otherwise we'll be introducing
pointless merge conflicts with board-*.c files changing
and disappearing as we move to DT based booting.

Regards,

Tony


From tony at atomide.com  Tue Jul 16 08:47:22 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 05:47:22 -0700
Subject: [PATCH v2 0/4] usb: musb: fix USB enumeration issue in OMAP3
 platform
In-Reply-To: <20130716124227.GC15036@arwen.pp.htv.fi>
References: <1373282057-20181-1-git-send-email-kishon@ti.com>
 <51E4DFA6.2010501@ti.com> <20130716124227.GC15036@arwen.pp.htv.fi>
Message-ID: <20130716124721.GB7656@atomide.com>

* Felipe Balbi <balbi at ti.com> [130716 05:49]:
> Hi,
> 
> On Tue, Jul 16, 2013 at 11:22:38AM +0530, Kishon Vijay Abraham I wrote:
> > Tony,
> > 
> > On Monday 08 July 2013 04:44 PM, Kishon Vijay Abraham I wrote:
> > > This series fixes the USB enumeration issue caused because of the controller
> > > not able to get a reference to the PHY because of incorrect binding in the
> > > board file.
> > > 
> > > In the case of non-dt boot, the platform specific initialization file
> > > (board file) will do usb_bind_phy that binds the usb controller with the
> > > PHY using device names. After the device names are created using 
> > > PLATFORM_DEVID_AUTO, our original method of binding by device names doesn't
> > > work reliably (since the device name changes). Hence the usb controller
> > > is made to use labels for getting the PHY.
> > > 
> > > Here the PHY name is added in the plat data of USB controller device which
> > > should be used by the controller driver to get the PHY.
> > > Two new APIs usb_get_phy_by_name and devm_usb_get_phy_by_name are added to
> > > be used by the controller to get the PHY by name.
> > 
> > You haven't picked this patch series?
> 
> yeah and now it's too much to send during the -rc series. Here's what we
> can do, we can to minimum fix for -rc series (patching the names again)
> and I'll queue everything else for mailine if tony gives me his Ack for
> all arch/arm/*omap* parts.
> 
> Sounds good ?

Sounds good to me, except let's queue the last patch separately as cleanup
after the others are merged. I've acked the first patch, that should not
cause merge conflicts.

Regards,

Tony


From balbi at ti.com  Tue Jul 16 08:50:34 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 16 Jul 2013 15:50:34 +0300
Subject: [PATCH v2 2/5] arm: omap5: dts: fix ocp2scp DTS data
In-Reply-To: <1373979037-27587-1-git-send-email-balbi@ti.com>
References: <1373979037-27587-1-git-send-email-balbi@ti.com>
Message-ID: <1373979037-27587-3-git-send-email-balbi@ti.com>

this patch fixes the DTS data for ocp2scp
node by adding the missing reg property.

Signed-off-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/boot/dts/omap5.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 5c99f19..4e41409 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -652,10 +652,11 @@
 			};
 		};
 
-		ocp2scp {
+		ocp2scp at 4a080000 {
 			compatible = "ti,omap-ocp2scp";
 			#address-cells = <1>;
 			#size-cells = <1>;
+			reg = <0x4a080000 0x20>;
 			ranges;
 			ti,hwmods = "ocp2scp1";
 			usb2_phy: usb2phy at 4a084000 {
-- 
1.8.3.3.754.g9c3c367



From balbi at ti.com  Tue Jul 16 08:50:33 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 16 Jul 2013 15:50:33 +0300
Subject: [PATCH v2 1/5] arm: omap5: dts: fix reg property size
In-Reply-To: <1373979037-27587-1-git-send-email-balbi@ti.com>
References: <1373979037-27587-1-git-send-email-balbi@ti.com>
Message-ID: <1373979037-27587-2-git-send-email-balbi@ti.com>

USB3 block has a 64KiB space, another 64KiB is
used for the wrapper.

Without this change, resource_size() will get
confused and driver won't probe because size
will be negative.

Signed-off-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/boot/dts/omap5.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..5c99f19 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -637,7 +637,7 @@
 		omap_dwc3 at 4a020000 {
 			compatible = "ti,dwc3";
 			ti,hwmods = "usb_otg_ss";
-			reg = <0x4a020000 0x1000>;
+			reg = <0x4a020000 0x10000>;
 			interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
 			#address-cells = <1>;
 			#size-cells = <1>;
@@ -645,7 +645,7 @@
 			ranges;
 			dwc3 at 4a030000 {
 				compatible = "synopsys,dwc3";
-				reg = <0x4a030000 0x1000>;
+				reg = <0x4a030000 0x10000>;
 				interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
 				usb-phy = <&usb2_phy>, <&usb3_phy>;
 				tx-fifo-resize;
-- 
1.8.3.3.754.g9c3c367



From balbi at ti.com  Tue Jul 16 08:50:32 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 16 Jul 2013 15:50:32 +0300
Subject: [PATCH v2 0/5] ARM: OMAP: DTS/HWMOD/defconfig changes for USB3
Message-ID: <1373979037-27587-1-git-send-email-balbi@ti.com>

With these patches (plus a few others on the driver side which
will be going upstream soon) I could get functional USB3 with my
omap5-uevm platform.

Changes since v1:
	- split ocp2scp dts and hwmod data into separate patches
	- reorganize the series in order to group DTS, hwmod and defconfig
	  changes

Benoit Cousson (1):
  arm: omap5: hwmod: add missing ocp2scp hwmod data

Felipe Balbi (4):
  arm: omap5: dts: fix reg property size
  arm: omap5: dts: fix ocp2scp DTS data
  arm: omap5: dts: add palmas-usb node
  arm: omap2plus_defconfig: enable dwc3 and dependencies

 arch/arm/boot/dts/omap5-uevm.dts           | 10 +++++++
 arch/arm/boot/dts/omap5.dtsi               |  9 +++---
 arch/arm/configs/omap2plus_defconfig       |  9 ++++++
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45 ++++++++++++++++++++++++++++++
 4 files changed, 69 insertions(+), 4 deletions(-)

-- 
1.8.3.3.754.g9c3c367



From balbi at ti.com  Tue Jul 16 08:50:35 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 16 Jul 2013 15:50:35 +0300
Subject: [PATCH v2 3/5] arm: omap5: dts: add palmas-usb node
In-Reply-To: <1373979037-27587-1-git-send-email-balbi@ti.com>
References: <1373979037-27587-1-git-send-email-balbi@ti.com>
Message-ID: <1373979037-27587-4-git-send-email-balbi@ti.com>

Without this node, there will be no palmas
driver to notify dwc3 that a cable has
been connected and, without that, dwc3
will never initialize.

Signed-off-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/boot/dts/omap5-uevm.dts | 10 ++++++++++
 arch/arm/boot/dts/omap5.dtsi     |  2 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..badceb8 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -272,6 +272,11 @@
 		interrupt-controller;
 		#interrupt-cells = <2>;
 
+		extcon_usb3: palmas_usb {
+			compatible = "ti,palmas-usb";
+			ti,wakeup;
+		};
+
 		palmas_pmic {
 			compatible = "ti,palmas-pmic";
 			interrupt-parent = <&palmas>;
@@ -450,6 +455,11 @@
 	phys = <0 &hsusb2_phy &hsusb3_phy>;
 };
 
+&usb3 {
+	extcon = <&extcon_usb3>;
+	vbus-supply = <&smps10_reg>;
+};
+
 &mcspi1 {
 
 };
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 4e41409..1659246 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -634,7 +634,7 @@
 			ti,type = <2>;
 		};
 
-		omap_dwc3 at 4a020000 {
+		usb3: omap_dwc3 at 4a020000 {
 			compatible = "ti,dwc3";
 			ti,hwmods = "usb_otg_ss";
 			reg = <0x4a020000 0x10000>;
-- 
1.8.3.3.754.g9c3c367



From balbi at ti.com  Tue Jul 16 08:50:36 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 16 Jul 2013 15:50:36 +0300
Subject: [PATCH v2 4/5] arm: omap5: hwmod: add missing ocp2scp hwmod data
In-Reply-To: <1373979037-27587-1-git-send-email-balbi@ti.com>
References: <1373979037-27587-1-git-send-email-balbi@ti.com>
Message-ID: <1373979037-27587-5-git-send-email-balbi@ti.com>

From: Benoit Cousson <benoit.cousson at linaro.org>

without that hwmod data, USB3 will not in OMAP5 boards.

Signed-off-by: Benoit Cousson <benoit.cousson at linaro.org>
Signed-off-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45 ++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index f37ae96..542eddd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1114,6 +1114,42 @@ static struct omap_hwmod omap54xx_mpu_hwmod = {
 };
 
 /*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_ocp2scp_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+			SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_ocp2scp_hwmod_class = {
+	.name	= "ocp2scp",
+	.sysc	= &omap54xx_ocp2scp_sysc,
+};
+
+/* ocp2scp1 */
+static struct omap_hwmod omap54xx_ocp2scp1_hwmod = {
+	.name		= "ocp2scp1",
+	.class		= &omap54xx_ocp2scp_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.main_clk	= "l4_root_clk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L3INIT_OCP2SCP1_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L3INIT_OCP2SCP1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/*
  * 'timer' class
  * general purpose timer module with accurate 1ms tick
  * This class contains several variants: ['timer_1ms', 'timer']
@@ -1919,6 +1955,14 @@ static struct omap_hwmod_ocp_if omap54xx_l4_cfg__mpu = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_cfg -> ocp2scp1 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp1 = {
+	.master		= &omap54xx_l4_cfg_hwmod,
+	.slave		= &omap54xx_ocp2scp1_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_wkup -> timer1 */
 static struct omap_hwmod_ocp_if omap54xx_l4_wkup__timer1 = {
 	.master		= &omap54xx_l4_wkup_hwmod,
@@ -2121,6 +2165,7 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] __initdata = {
 	&omap54xx_l4_per__mmc4,
 	&omap54xx_l4_per__mmc5,
 	&omap54xx_l4_cfg__mpu,
+	&omap54xx_l4_cfg__ocp2scp1,
 	&omap54xx_l4_wkup__timer1,
 	&omap54xx_l4_per__timer2,
 	&omap54xx_l4_per__timer3,
-- 
1.8.3.3.754.g9c3c367



From balbi at ti.com  Tue Jul 16 08:50:37 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 16 Jul 2013 15:50:37 +0300
Subject: [PATCH v2 5/5] arm: omap2plus_defconfig: enable dwc3 and dependencies
In-Reply-To: <1373979037-27587-1-git-send-email-balbi@ti.com>
References: <1373979037-27587-1-git-send-email-balbi@ti.com>
Message-ID: <1373979037-27587-6-git-send-email-balbi@ti.com>

DWC3 enables USB3 functionality for OMAP5 boards,
it's safe to enable those drivers in omap2plus_defconfig.

Signed-off-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/configs/omap2plus_defconfig | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 5339e6a..aed3cce 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -81,6 +81,7 @@ CONFIG_CMA=y
 CONFIG_CONNECTOR=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_OMAP_OCP2SCP=y
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_CHAR=y
@@ -167,9 +168,11 @@ CONFIG_THERMAL_GOV_USER_SPACE=y
 CONFIG_CPU_THERMAL=y
 CONFIG_OMAP_WATCHDOG=y
 CONFIG_TWL4030_WATCHDOG=y
+CONFIG_MFD_PALMAS=y
 CONFIG_MFD_TPS65217=y
 CONFIG_MFD_TPS65910=y
 CONFIG_TWL6040_CORE=y
+CONFIG_REGULATOR_PALMAS=y
 CONFIG_REGULATOR_TWL4030=y
 CONFIG_REGULATOR_TPS65023=y
 CONFIG_REGULATOR_TPS6507X=y
@@ -222,10 +225,14 @@ CONFIG_USB_MON=y
 CONFIG_USB_WDM=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_LIBUSUAL=y
+CONFIG_USB_DWC3=m
+CONFIG_USB_DWC3_OMAP=m
 CONFIG_USB_TEST=y
 CONFIG_USB_PHY=y
 CONFIG_NOP_USB_XCEIV=y
 CONFIG_USB_GADGET=y
+CONFIG_OMAP_USB2=y
+CONFIG_OMAP_USB3=y
 CONFIG_USB_GADGET_DEBUG=y
 CONFIG_USB_GADGET_DEBUG_FILES=y
 CONFIG_USB_GADGET_DEBUG_FS=y
@@ -258,6 +265,8 @@ CONFIG_TI_THERMAL=y
 CONFIG_OMAP4_THERMAL=y
 CONFIG_OMAP5_THERMAL=y
 CONFIG_DRA752_THERMAL=y
+CONFIG_EXTCON=y
+CONFIG_EXTCON_PALMAS=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 # CONFIG_EXT3_FS_XATTR is not set
-- 
1.8.3.3.754.g9c3c367



From ezequiel.garcia at free-electrons.com  Tue Jul 16 08:56:02 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 16 Jul 2013 09:56:02 -0300
Subject: [PATCH] ARM: Kirkwood: Fix the internal register ranges
 translation
In-Reply-To: <51E5145A.90404@keymile.com>
References: <1371569479-31498-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <51E5145A.90404@keymile.com>
Message-ID: <20130716125531.GD2317@localhost>

Hi Gerlando,

On Tue, Jul 16, 2013 at 11:37:30AM +0200, Gerlando Falauto wrote:
> 
> apologies in advance for commenting on an already-merged patch.

Sure, no problem.

> 
> On 06/18/2013 05:31 PM, Ezequiel Garcia wrote:
> > Although the internal register window size is 1 MiB, the previous
> > ranges translation for the internal register space had a size of
> > 0x4000000. This was done to allow the crypto and nand node to access
> > the corresponding 'sram' and 'nand' decoding windows.
> >
> > In order to describe the hardware more accurately, we declare the
> > real 1 MiB internal register space in the ranges, and add a translation
> > entry for the nand node to access the 'nand' window.
> >
> > This commit will make future improvements on the MBus DT binding easier.
> >
> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8 at public.gmane.org>
> > ---
> > Tested on Plathome Openblocks A6 board.
> >
> >   arch/arm/boot/dts/kirkwood.dtsi | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
> > index 8a1e3bb..910fabc 100644
> > --- a/arch/arm/boot/dts/kirkwood.dtsi
> > +++ b/arch/arm/boot/dts/kirkwood.dtsi
> > @@ -38,7 +38,8 @@
> >
> >   	ocp at f1000000 {
> >   		compatible = "simple-bus";
> > -		ranges = <0x00000000 0xf1000000 0x4000000
> > +		ranges = <0x00000000 0xf1000000 0x0100000
> > +		          0xf4000000 0xf4000000 0x0000400
> >   		          0xf5000000 0xf5000000 0x0000400>;
> 
> Apart from "consistency" with the following range (0xf5000000) used by 
> the crypto node, is there any reason why you did not do something like 
> this instead (which Valentin suggested, but I will take the blame for):
> 

I'm not sure the reason is "consistency with the crypto node".
There's an MBus window at 0xf4000000 for NAND, and that is what is described
in the snippet above; and this is a better reason.

That said, technically speaking, you can have any translation scheme you want,
as long as it ends up in 0xf4000000.

> -		ranges = <0x00000000 0xf1000000 0x4000000
> +		ranges = <0x00000000 0xf1000000 0x0100000
> +		          0x03000000 0xf4000000 0x0000400
>    		          0xf5000000 0xf5000000 0x0000400>;
> 
> This would keep a consistent addressing within the child device bus, and 

Could you explain how this "keeps a consistent addressing"?
Frankly, I don't understand why you choose 0x3000000 ... am I missing something?

Also, speaking of "device bus" this nand node should be behind a devicebus node.

		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000   /* internal-regs */
			  MBUS_ID(0x01, 0x2f) 0 0 0xf4000000 0x400>;

		devbus {
			status = "okay";
			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x400>;

			/* nand */
			nand {
				compatible = "marvell,orion-nand";
				reg = <0 0x400>;
			};
		};

(notice this will allow you to relocate the base address of the NAND windows
easily if it conflicts with your PCIe needs).

> avoid a later incosistency between the "unit-address" and the first 
> "reg" address:
> 
> >   		#address-cells = <1>;
> >   		#size-cells = <1>;
> > @@ -171,7 +172,7 @@
>  >   		nand at 3000000 {
> 		     ^^^^^^^

Oh, this should be fixed. I just missed it, and nobody noticed either.

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From otavio at ossystems.com.br  Tue Jul 16 08:56:12 2013
From: otavio at ossystems.com.br (Otavio Salvador)
Date: Tue, 16 Jul 2013 09:56:12 -0300
Subject: [PATCH v2 1/4] ARM: dts: imx23-evk: enable USB PHY and controller
Message-ID: <1373979376-31583-1-git-send-email-otavio@ossystems.com.br>

The i.MX23EVK board provides a USB port so the USB PHY and controller
need to be enabled for it to be usable.

Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
---
Changes in v2: None

 arch/arm/boot/dts/imx23-evk.dts | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index da0588a..dc3ab45 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -107,6 +107,16 @@
 				pinctrl-0 = <&duart_pins_a>;
 				status = "okay";
 			};
+
+			usbphy0: usbphy at 8007c000 {
+				status = "okay";
+			};
+		};
+	};
+
+	ahb at 80080000 {
+		usb0: usb at 80080000 {
+			status = "okay";
 		};
 	};
 
-- 
1.8.3.2



From otavio at ossystems.com.br  Tue Jul 16 08:56:13 2013
From: otavio at ossystems.com.br (Otavio Salvador)
Date: Tue, 16 Jul 2013 09:56:13 -0300
Subject: [PATCH v2 2/4] ARM: dts: imx23-evk: enable Low Resolution ADC
In-Reply-To: <1373979376-31583-1-git-send-email-otavio@ossystems.com.br>
References: <1373979376-31583-1-git-send-email-otavio@ossystems.com.br>
Message-ID: <1373979376-31583-2-git-send-email-otavio@ossystems.com.br>

The i.XM23 has a internal Low Resolution ADC; this enables the support
for this device.

Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
---
Changes in v2: None

 arch/arm/boot/dts/imx23-evk.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index dc3ab45..185c7c0 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -90,6 +90,11 @@
 		};
 
 		apbx at 80040000 {
+			lradc at 80050000 {
+				status = "okay";
+				fsl,lradc-touchscreen-wires = <4>;
+			};
+
 			pwm: pwm at 80064000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&pwm2_pins_a>;
-- 
1.8.3.2



From otavio at ossystems.com.br  Tue Jul 16 08:56:14 2013
From: otavio at ossystems.com.br (Otavio Salvador)
Date: Tue, 16 Jul 2013 09:56:14 -0300
Subject: [PATCH v2 3/4] ARM: dts: imx23-olinuxino: enable Low Resolution ADC
In-Reply-To: <1373979376-31583-1-git-send-email-otavio@ossystems.com.br>
References: <1373979376-31583-1-git-send-email-otavio@ossystems.com.br>
Message-ID: <1373979376-31583-3-git-send-email-otavio@ossystems.com.br>

The i.XM23 has a internal Low Resolution ADC; this enables the support
for this device.

Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
---
Changes in v2: None

 arch/arm/boot/dts/imx23-olinuxino.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts b/arch/arm/boot/dts/imx23-olinuxino.dts
index d107c4a..fc766ae 100644
--- a/arch/arm/boot/dts/imx23-olinuxino.dts
+++ b/arch/arm/boot/dts/imx23-olinuxino.dts
@@ -69,6 +69,10 @@
 		};
 
 		apbx at 80040000 {
+			lradc at 80050000 {
+				status = "okay";
+			};
+
 			duart: serial at 80070000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&duart_pins_a>;
-- 
1.8.3.2



From shawn.guo at linaro.org  Tue Jul 16 08:56:48 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 20:56:48 +0800
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <1373968166.4327.11.camel@pizza.hi.pengutronix.de>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <20130716041056.GA30067@S2101-09.ap.freescale.net>
 <1373968166.4327.11.camel@pizza.hi.pengutronix.de>
Message-ID: <20130716125646.GM28375@S2101-09.ap.freescale.net>

On Tue, Jul 16, 2013 at 11:49:26AM +0200, Philipp Zabel wrote:
> so you want to have gpio-reset probed at arch_initcall time and you have
> gpio-pca953x probed at subsys_initcall time. Won't then all gpio-reset
> devices that use gpios on pca953x to reset other peripherals need to be
> deferred?

Yes, they will be deferred, but they will be probed and ready at
subsys_initcall time when gpio-pca953x probes.  This is still good since
most of component device drivers probes at module_init time.

Shawn



From pullip.cho at samsung.com  Tue Jul 16 09:05:10 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Tue, 16 Jul 2013 22:05:10 +0900
Subject: [PATCH v7 00/12] iommu/exynos: Fixes and Enhancements of System
 MMU driver with DT
In-Reply-To: <CANEJEGu0VJdFZmS800EKRSH0GXLGomC973BON7Vtr1qjjqi_nw@mail.gmail.com>
References: <002801ce797b$3d2fbc80$b78f3580$@samsung.com>
 <CANEJEGvajhgzUPG6ppbjwBb4-9TdU9em3T_SejBpz8NCjGHYTQ@mail.gmail.com>
 <00a701ce8155$be139240$3a3ab6c0$@samsung.com>
 <CANEJEGu0VJdFZmS800EKRSH0GXLGomC973BON7Vtr1qjjqi_nw@mail.gmail.com>
Message-ID: <002001ce8225$1a844540$4f8ccfc0$@samsung.com>

> From: grundler at google.com [mailto:grundler at google.com] On Behalf Of Grant Grundler
> Sent: Tuesday, July 16, 2013 12:56 AM
> 
> On Mon, Jul 15, 2013 at 5:20 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> ...
> >> > Cho,
> >> > Of the above patches, nearly all have been applied to chromeos-3.8
> >> > (kernel-next git tree) by Doug Anderson and others.
> >> >
> >> > AFAICT, the only ones not applied are:
> >> >    [v7,3/9] iommu/exynos: fix page table maintenance
> >> >    [v7,6/9] clk: exynos5250: add gate clock descriptions of System MMU
> >> > (conflicts in this one)
> >> >    [v7,7/9] ARM: dts: Add description of System MMU of Exynos SoCs
> >> > (depends on 6/9)
> >> >
> >> > We also already have parts of:
> >> >    [v7,9/9] iommu/exynos: add bus notifier for registering System MMU
> >> >
> >> > Some of those are being further discussed but I've lost track now
> >> > exactly which ones.
> >> >
> >> > I'm telling you about chromeos-3.8 status since the adopted changes
> >> > have been reviewed (by me and others) are being tested manually here
> >> > on several different Samsung Exynos platforms (including 5250 which is
> >> > our "snow" platform). Not sure how you should to mark those patches
> >> > since they aren't identical to your changes (which apply to post 3.10
> >> > kernels, not 3.8).  You might consider splitting those patches out
> >> > from the 4 I've listed above to get that series accepted upstream
> >> > since the additional review/testing should provide some confidence
> >> > those patches are good.
> >> >
> >>
> >> I understand what you are concerning about.
> >> Have you applied v6 patchset?
> 
> I did not though it's possible some of the code that was applied to
> chromeos-3.8 kernel came from v6 (or earlier) patches. I just compared
> with v7. Since it's a "backport", the code I found in chromeos-3.8 is
> the same if not identical to v7.
> 
Ok.
I think chromeos-3.8 kernel must work well with v7 also.
But there're a lot of changes in device tree of exynos SoC
and exynos-iommu driver followed by the changes in device tree
since 3.8 kernel.
I worry that back-porting of v7 is not trivial.

> >>
> >> I will try to split the patches and make the changes from v6
> >> on top of the v6 patcheset.
> 
> Ok.
> 
> > Actually, as you know, the previous patches include setting a System MMU
> > as the parent device of its master device in probe() of System MMU.
> > I asked Greg KH about changing device hierarchy in probe() and he answered
> > that it is not a good idea because it modifies sysfs even though probe() of
> > System MMU driver is called before sysfs is constructed.
> 
> SysMMU primarily provides DMA API, right? Can sysfs be initialized
> before DMA is available?
> On some (many?) platforms the SysMMU is also responsible for "child"
> bus controllers and MMIO resource routing, and on ARM platforms,
> clocks for rest of the IO devices.
> 
> SysMMU might be needed for early gfx support (or something). Maybe the
> right answer is to "discover" the SysMMU twice: once very early to get
> the SysMMU operational and then again later in a "normal" probe
> sequence to register with the sysfs. Any reason a driver couldn't
> register two different module_init() routines in different parts of
> the init call table?
> 
I agree with you.
Actually, exynos-iommu driver in Android devices based on 3.4 kernel
sets System MMUs as the parent of their Master devices in the different
initcalls.
(You can find it in the kernel of Galaxy S4 which contains Exynos SoC.)
There are several reasons.
Some devices are not involved in generic IO powerdomain and
genpd_pm_ops is not called for the devices.
Some devices are not proper to handle System MMU with genpd_pm_ops.

I wished that every device which has System MMU uses generic IO powerdomain
for its power management.

If I can be convince myself of that setting System MMU as the parent of
its master device is not a problem, I will not hesitate to do so.

> 
> > That's why I uses genpd_pm_ops.
> > It results in big change in the patches after registering device tree.
> >
> > I want to ask your opinion about this change :)
> 
> I have no objection to large changes if they work well and are easy to
> understand.
> 
Thank you.

> <rant>
> I personally not happy with the direction the Linux IOMMU "subsystem"
> has taken. I think the generic IOMMU subsystem should be discarded.
> Strong words for someone who's not a key contributor but I'll explain.
> 
> I wrote the IOMMU support for PA-RISC (three different IOMMUs) 10+
> years ago. I rewrote the HPUX implementations in the 90's and then
> around 2000 wrote the implementation for PA-RISC (one of which Alex
> Williamson used for IA64 IOMMU support - sba_iommu.c).  It's pretty
> straight forward. There is "page allocation policy", code to do TLB
> shoot down, and code to manage the IO Pdir. This is the same as for
> CPU MMU.  The *efficiency* of the TLB depends on the page allocation
> (SW) to work together with the HW TLB replacement policy. In other
> words, the page allocation policy needs to avoid thrashing the IO TLB.
> A generic IOTLB allocation policy can't do that for every platform.
> 
> Exynos 5250 has an 8-way associative TLB. That's likely very different
> from the Intel and TI (omap) IOMMU the IOMMU subsystem code was
> originally implemented for. The "optimal" size of page to allocate
> will be different too.  Older Exynos products are likely different
> 
> The "2cd layer" of indirect function calls between the generic IOMMU
> support and the platform specific code makes it harder to understand
> the code.  While jump tables are good for some things, I don't think
> this is a good use. We should "flip" this design around. Let the
> platform specific code "own" the DMA ops API and it can decide which
> services it should or should not use.
> 
> E.g. The IOTLB shoot down can be divorced from the "unmap" call. The
> efficiency of shooting down one IOTLB entry at a time is horrible on
> most platforms. One answer is to add a new API to shoot down an array
> of IOVAs. But the tradeoffs in the size of the array and the events
> that might trigger a TLB shoot down should be left up to the
> platform/chipset specific code (e.g. "lazy TLB shootdown").
> 
> Sorry...this got rant got alot longer than it should have been. I hope
> this helps people understand the design tradeoffs that linux IOMMU
> subsystem never will be able to cleanly address. My hope is this rant
> will help developers like you justify small steps to move away from
> generic IOMMU code.
> </rant>
> 
I understand what you are talking about.
Many people including me are finding a way to abstract different types
of H/W. I think IOMMU API is one of the result and DMA mapping framework
for ARM architecture is already finished with IOMMU API.

One of the inefficiency in the current implementation of DMA mapping for
ARM architecture is TLB invalidation which you addressed above.
TLB invalidation interface in IOMMU API was introduced earlier but it was
discarded. We can propose that if any others also agree.

Actually, I defined several custom TLB maintenance interfaces
for the kernel of our product to manage TLB efficiently.

> cheers,
> grant

Thank you very much, Grant.

Cho KyongHo.



From alekskartashov at parallels.com  Tue Jul 16 09:12:06 2013
From: alekskartashov at parallels.com (Alexander Kartashov)
Date: Tue, 16 Jul 2013 17:12:06 +0400
Subject: [PATCH] arm: align shared memory unconditionally to the SHMLBA
 boundary
In-Reply-To: <20130716110721.GD24642@n2100.arm.linux.org.uk>
References: <1361254269-3444-1-git-send-email-alekskartashov@parallels.com>
 <20130715173238.GJ1730@moon> <20130715180846.GV24642@n2100.arm.linux.org.uk>
 <20130715185739.GK1730@moon> <51E4DC0B.8040908@parallels.com>
 <20130716095349.GB16370@moon> <51E51EF1.3010104@parallels.com>
 <20130716103649.GC24642@n2100.arm.linux.org.uk>
 <51E524D1.2090504@parallels.com>
 <20130716110721.GD24642@n2100.arm.linux.org.uk>
Message-ID: <51E546A6.7010606@parallels.com>

On 07/16/2013 03:07 PM, Russell King - ARM Linux wrote:
> On Tue, Jul 16, 2013 at 02:47:45PM +0400, Alexander Kartashov wrote:
>> On 07/16/2013 02:36 PM, Russell King - ARM Linux wrote:
>>> shmget() doesn't allocate space in the process for the SHM region.  It
>>> merely creates the shm memory and returns an identifier for it which can
>>> later be used by shmat() to map it.
>> Thank you for the correction, I meant shmat() in that comment indeed.
>> I'm sorry for the inconvenience.
> Right, so it appears that there's a difference between shmat() with an
> address and with a NULL address, because the enforcement is done by two
> completely different bits of code in unrelated parts of the kernel.
>
> I notice Sparc32 seems to have a fix for this along the lines of the
> (untested) patch below, so let's do the same on ARM.  Please test this
> and let me know if this solves your problem.
>
> Thanks.
>
>   arch/arm/include/asm/shmparam.h |    8 ++++----
>   1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/shmparam.h b/arch/arm/include/asm/shmparam.h
> index a5223b3..843db59 100644
> --- a/arch/arm/include/asm/shmparam.h
> +++ b/arch/arm/include/asm/shmparam.h
> @@ -1,16 +1,16 @@
>   #ifndef _ASMARM_SHMPARAM_H
>   #define _ASMARM_SHMPARAM_H
>   
> +#include <asm/cachetype.h>
> +
>   /*
>    * This should be the size of the virtually indexed cache/ways,
>    * or page size, whichever is greater since the cache aliases
>    * every size/ways bytes.
>    */
> -#define	SHMLBA	(4 * PAGE_SIZE)		 /* attach addr a multiple of this */
> +#define	SHMLBA	(cache_is_vipt_aliasing() ? (4 * PAGE_SIZE) : PAGE_SIZE)
This change breaks compilation:

arch/arm/mm/copypage-v6.c:23:5: warning: "cacheid_is" is not defined 
[-Wundef]
arch/arm/mm/copypage-v6.c:23:5: error: missing binary operator before 
token "("
make[1]: *** [arch/arm/mm/copypage-v6.o] Error 1
make: *** [arch/arm/mm] Error 2

The lines in trouble is

#if SHMLBA > 16384
#error FIX ME
#endif


>   
> -/*
> - * Enforce SHMLBA in shmat
> - */
> +/* Enforce SHMLBA in shmat */
>   #define __ARCH_FORCE_SHMLBA
>   
>   #endif /* _ASMARM_SHMPARAM_H */


-- 
Sincerely yours,
Alexander Kartashov

Intern
Core team

www.parallels.com

Skype: aleksandr.kartashov
Email: alekskartashov at parallels.com



From pullip.cho at samsung.com  Tue Jul 16 09:07:46 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Tue, 16 Jul 2013 22:07:46 +0900
Subject: [PATCH v7 3/9] iommu/exynos: fix page table maintenance
In-Reply-To: <CANEJEGs_8a9dPCYtDT8u2NEv5HUUD5gcdmRmbsrKU-_aagztgg@mail.gmail.com>
References: <002b01ce797b$44d4ad10$ce7e0730$@samsung.com>
 <1933986.4vddYccClk@amdc1032> <009a01ce814d$840b48c0$8c21da40$@samsung.com>
 <CANEJEGs_8a9dPCYtDT8u2NEv5HUUD5gcdmRmbsrKU-_aagztgg@mail.gmail.com>
Message-ID: <002101ce8225$775a71e0$660f55a0$@samsung.com>

> From: grundler at google.com [mailto:grundler at google.com] On Behalf Of Grant Grundler
> Sent: Tuesday, July 16, 2013 1:19 AM
> 
> On Mon, Jul 15, 2013 at 4:21 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> ...
> >> Maybe you could add LV1TABLE_SIZE define and use it here (there is
> >> already a LV2TABLE_SIZE define)?
> >
> > Yes. But, LV2TABLE_SIZE is used in more places than one.
> > I do not feel that it is needed to define LV1TABLE_SIZE for the single line.
> 
> Cho,
> #define's are part of the code "documentation". Doesn't really matter
> how often it's used. I think Bartlomiej's suggestion is a good one.
> 
> Key is to use "consistent" names so they makes sense to someone not
> familiar with the code. In this case, we want to show this use is the
> same way LV2TABLE_SIZE is used and serves the same purpose.
> 
Ok.
I agree the error handling code is not pretty to understand.
I will change it in the next patch.

> cheers.
> grant

Thank you.

Cho KyongHo.



From eduardo.valentin at ti.com  Tue Jul 16 09:10:55 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Tue, 16 Jul 2013 09:10:55 -0400
Subject: Division by zero caused by CCF
In-Reply-To: <20130716123709.GA15036@arwen.pp.htv.fi>
References: <20130716123709.GA15036@arwen.pp.htv.fi>
Message-ID: <51E5465F.3090801@ti.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Hi,

Adding Mike's correct address.

On 16-07-2013 08:37, Felipe Balbi wrote:
> Hi,
> 
> trying to get USB host verified on OMAP5 uEVM with v3.11-rc1. The
> clk_set_rate() call ends up in a division by zero, which is quite
> interesting provided the driver will only call clk_set_rate() if the
> clock is valid and clk_rate is != 0.
> 
> 
> [   22.009238] Division by zero in kernel.
> [   22.009250] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W    3.11.0-rc1-00081-g3310d44-dirty #118
> [   22.009275] [<c001c83c>] (unwind_backtrace+0x0/0xf0) from [<c0018a1c>] (show_stack+0x10/0x14)
> [   22.009289] [<c0018a1c>] (show_stack+0x10/0x14) from [<c057403c>] (dump_stack+0x70/0x8c)
> [   22.009304] [<c057403c>] (dump_stack+0x70/0x8c) from [<c02e4154>] (Ldiv0+0x8/0x10)
> [   22.009319] [<c02e4154>] (Ldiv0+0x8/0x10) from [<c048d460>] (clk_divider_set_rate+0x10/0xdc)
> [   22.009331] [<c048d460>] (clk_divider_set_rate+0x10/0xdc) from [<c048c124>] (clk_change_rate+0x38/0xb0)
> [   22.009341] [<c048c124>] (clk_change_rate+0x38/0xb0) from [<c048c20c>] (clk_set_rate+0x70/0xa8)
> [   22.009354] [<c048c20c>] (clk_set_rate+0x70/0xa8) from [<c042b244>] (nop_usb_xceiv_probe+0x1fc/0x2f8)
> [   22.009369] [<c042b244>] (nop_usb_xceiv_probe+0x1fc/0x2f8) from [<c036b47c>] (platform_drv_probe+0x18/0x1c)
> [   22.009380] [<c036b47c>] (platform_drv_probe+0x18/0x1c) from [<c0369f44>] (really_probe+0x70/0x1f4)
> [   22.009390] [<c0369f44>] (really_probe+0x70/0x1f4) from [<c036a1dc>] (driver_probe_device+0x30/0x48)
> [   22.009401] [<c036a1dc>] (driver_probe_device+0x30/0x48) from [<c036a288>] (__driver_attach+0x94/0x98)
> [   22.009411] [<c036a288>] (__driver_attach+0x94/0x98) from [<c0368748>] (bus_for_each_dev+0x54/0x88)
> [   22.009420] [<c0368748>] (bus_for_each_dev+0x54/0x88) from [<c036972c>] (bus_add_driver+0xdc/0x29c)
> [   22.009430] [<c036972c>] (bus_add_driver+0xdc/0x29c) from [<c036a760>] (driver_register+0x78/0x190)
> [   22.009440] [<c036a760>] (driver_register+0x78/0x190) from [<c00087b0>] (do_one_initcall+0x34/0x164)
> [   22.009453] [<c00087b0>] (do_one_initcall+0x34/0x164) from [<c07b18f4>] (do_basic_setup+0x90/0xc4)
> [   22.009466] [<c07b18f4>] (do_basic_setup+0x90/0xc4) from [<c07b199c>] (kernel_init_freeable+0x74/0x110)
> [   22.009478] [<c07b199c>] (kernel_init_freeable+0x74/0x110) from [<c05676c4>] (kernel_init+0x8/0xe4)
> [   22.009491] [<c05676c4>] (kernel_init+0x8/0xe4) from [<c0014648>] (ret_from_fork+0x14/0x2c)
> 
> I believe the problem is the actual division reaching
> clk_divider_set_rate().
> 
> drivers/clk/clk-divider.c::clk_divider_set_rate()
> 
> | static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
> |                                 unsigned long parent_rate)
> | {
> |         struct clk_divider *divider = to_clk_divider(hw);
> |         unsigned int div, value;
> |         unsigned long flags = 0;
> |         u32 val;
> | 
> |         div = parent_rate / rate;
> 
> right here, but how come rate would zero provided driver checks for it
> as below.
> 
> drivers/usb/phy/phy-nop.c::nop_usb_xceiv_probe()
> 
> |         if (!IS_ERR(nop->clk) && clk_rate) {
> |                 err = clk_set_rate(nop->clk, clk_rate);
> |                 if (err) {
> |                         dev_err(&pdev->dev, "Error setting clock rate\n");
> |                         return err;
> |                 }
> |         }
> 
> I've added a few prints around CCF to try and track what's going on:
> 
> [   21.592690] ====> nop_usb_xceiv_probe rate 19200000
> [   21.592700] ====> clk_set_rate rate 19200000
> [   21.592707] ====> clk_calc_new_rates rate 19200000
> [   21.592713] ====> clk_divider_round_rate rate 19200000
> [   21.592719] ====> clk_divider_bestdiv rate 19200000
> [   21.592726] ====> clk_change_rate best_parent_rate 0

or because we reach:
	if (clk->ops->set_rate)
		clk->ops->set_rate(clk->hw, clk->new_rate, best_parent_rate);

with clk->new_rate == 0.


> [   21.592732] ====> clk_divider_set_rate rate 0
> [   21.592737] Division by zero in kernel.
> [   21.592747] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W    3.11.0-rc1-00081-g3310d44-dirty #121
> [   21.592773] [<c001c83c>] (unwind_backtrace+0x0/0xf0) from [<c0018a1c>] (show_stack+0x10/0x14)
> [   21.592787] [<c0018a1c>] (show_stack+0x10/0x14) from [<c057400c>] (dump_stack+0x70/0x8c)
> [   21.592803] [<c057400c>] (dump_stack+0x70/0x8c) from [<c02e4154>] (Ldiv0+0x8/0x10)
> [   21.592819] [<c02e4154>] (Ldiv0+0x8/0x10) from [<c048d3e0>] (clk_divider_set_rate+0x2c/0x100)
> [   21.592831] [<c048d3e0>] (clk_divider_set_rate+0x2c/0x100) from [<c048c050>] (clk_change_rate+0x48/0xe0)
> [   21.592841] [<c048c050>] (clk_change_rate+0x48/0xe0) from [<c048c174>] (clk_set_rate+0x8c/0xc0)
> [   21.592855] [<c048c174>] (clk_set_rate+0x8c/0xc0) from [<c042b254>] (nop_usb_xceiv_probe+0x20c/0x304)
> [   21.592869] [<c042b254>] (nop_usb_xceiv_probe+0x20c/0x304) from [<c036b47c>] (platform_drv_probe+0x18/0x1c)
> [   21.592880] [<c036b47c>] (platform_drv_probe+0x18/0x1c) from [<c0369f44>] (really_probe+0x70/0x1f4)
> [   21.592891] [<c0369f44>] (really_probe+0x70/0x1f4) from [<c036a1dc>] (driver_probe_device+0x30/0x48)
> [   21.592901] [<c036a1dc>] (driver_probe_device+0x30/0x48) from [<c036a288>] (__driver_attach+0x94/0x98)
> [   21.592911] [<c036a288>] (__driver_attach+0x94/0x98) from [<c0368748>] (bus_for_each_dev+0x54/0x88)
> [   21.592921] [<c0368748>] (bus_for_each_dev+0x54/0x88) from [<c036972c>] (bus_add_driver+0xdc/0x29c)
> [   21.592930] [<c036972c>] (bus_add_driver+0xdc/0x29c) from [<c036a760>] (driver_register+0x78/0x190)
> [   21.592941] [<c036a760>] (driver_register+0x78/0x190) from [<c00087b0>] (do_one_initcall+0x34/0x164)
> [   21.592954] [<c00087b0>] (do_one_initcall+0x34/0x164) from [<c07b18f4>] (do_basic_setup+0x90/0xc4)
> [   21.592966] [<c07b18f4>] (do_basic_setup+0x90/0xc4) from [<c07b199c>] (kernel_init_freeable+0x74/0x110)
> [   21.592980] [<c07b199c>] (kernel_init_freeable+0x74/0x110) from [<c0567694>] (kernel_init+0x8/0xe4)
> [   21.592992] [<c0567694>] (kernel_init+0x8/0xe4) from [<c0014648>] (ret_from_fork+0x14/0x2c)
> 
> even though driver passed 19.2MHz, best_parent_rate ends up being zero
> which triggers the division by zero above.
> 
> cheers
> 


- -- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlHlRl8ACgkQCXcVR3XQvP00XQEAtQgDEJLt8OFCJiIhUj46Zq1h
PvNq67RSFTRXcq/zHa8A/0IZSPitTXt1TqDfalTKof/DR6n9/W6md8/C2Ovqb59o
=AKnu
-----END PGP SIGNATURE-----


From arend at broadcom.com  Tue Jul 16 09:12:50 2013
From: arend at broadcom.com (Arend van Spriel)
Date: Tue, 16 Jul 2013 15:12:50 +0200
Subject: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock
In-Reply-To: <51E40199.9070906@ti.com>
References: <1371571487-14389-1-git-send-email-rogerq@ti.com>
 <1371571487-14389-5-git-send-email-rogerq@ti.com>
 <51E40199.9070906@ti.com>
Message-ID: <51E546D2.6000100@broadcom.com>

On 07/15/2013 04:05 PM, Roger Quadros wrote:
> Hi Tony,
>
> On 06/18/2013 07:04 PM, Roger Quadros wrote:
>> Till the OMAP clocks are correctly defined in device tree, use
>> this temporary hack to provide clock alias to the USB PHY clocks.
>>
>> Without this, USB Host & Ethernet will not be functional with
>> device tree boots on Panda and uEVM.
>
> Looks like this one got missed out.

Could it be because you promised to resend it (see [1]). I was upgrading 
our test stuff to 3.11-rc1 and made a DT appended image. Boot went fine, 
but no USB/ethernet. Should I pickup all four patches?

Regards,
Arend

[1] http://mid.gmane.org/51C2EC5F.8050703 at ti.com

> USB host no longer works on Panda with DT boot.
> Could you please queue this for next 3.11-rc? Thanks.
>
> cheers,
> -roger
>




From broonie at kernel.org  Tue Jul 16 09:13:32 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Jul 2013 14:13:32 +0100
Subject: [PATCH v3] rtc: Add MOXA ART RTC driver
In-Reply-To: <1373978485-17496-1-git-send-email-jonas.jensen@gmail.com>
References: <1373550711-18828-1-git-send-email-jonas.jensen@gmail.com>
 <1373978485-17496-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <20130716131332.GL22506@sirena.org.uk>

On Tue, Jul 16, 2013 at 02:41:25PM +0200, Jonas Jensen wrote:

>     1. don't use hardcoded GPIO numbers, use of_get_named_gpio

Since you're now using OF you should also be including a binding
document.
-------------- 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/20130716/e65a6be3/attachment-0001.sig>

From jason at lakedaemon.net  Tue Jul 16 09:15:47 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 16 Jul 2013 09:15:47 -0400
Subject: [PATCHv5 00/11] MSI support for Marvell EBU PCIe driver
In-Reply-To: <20130716104347.045a612a@skate>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E4167B.4000208@wwwdotorg.org> <20130716104347.045a612a@skate>
Message-ID: <20130716131547.GC12062@titan.lakedaemon.net>

On Tue, Jul 16, 2013 at 10:43:47AM +0200, Thomas Petazzoni wrote:
> Dear Stephen Warren,
> 
> On Mon, 15 Jul 2013 09:34:19 -0600, Stephen Warren wrote:
> 
> > > This patch set is intended for merging in 3.12, so the respective
> > > maintainers of the different areas are invited to review/ack the
> > > patches, see below for the details. This set of patches applies on top
> > > of 3.11-rc1.
> > 
> > Thomas, who is going to merge this series?
> 
> I don't know. There are quite a few build dependencies in there:
> 
>  * PATCH 7 build depends on PATCH 1 and PATCH 5, and obviously depends
>    on PATCH 6.
> 
>  * PATCH 2 to 5 really are one thing, they depend on each other.
> 
>  * PATCH 10 build depends on PATCH 5 and PATCH 8.
> 
> A quick diagram of the dependencies, best viewed with a fixed-size font
> mailer.
> 
> kernel/irq/irqdomain    drivers/pci        arch/arm/kernel
>      patch 1           patch 2, 3, 4           patch 8
>         ||                  ||                   ||
>         ||                  \/                   \/
>         ||               drivers/of   ==> drivers/pci/host
>         ||                patch 5           patch 10
>         ||                  ||
>         \\__________________//
>                   ||
>                   \/
>             drivers/irqchip
>               patch 6, 7

Well, that got more complicated.  :(  No cookie for you.

> Patches 9 and 11 are DT patches, so they are not mentioned in this
> diagram.
> 
> Normally tegra would require 1, 2, 3, 4, 5 and 8, so ideally, with
> the respective maintainers ACKs, Jason Cooper could take them in a
> specific topic stable branch that would not be rebased, on top of which
> both the Marvell work and Tegra work could be done.

After my recent discussions with tglx, here's my proposal:

- rmk creates a dedicated topic branch with patch 8

- Bjorn creates a dedicated topic branch based on rmk's with 2, 3, 4, 5,
  and 10

- tglx creates a dedicated topic branch based on Bjorn's with 1, 6, 7

- I take 9 and 11.

For Tegra, tglx can tag patch 1 for merging.  Tegra will 'adopt' patch
10, but that shouldn't hurt anything.

thx,

Jason.


From grygorii.strashko at ti.com  Tue Jul 16 09:15:07 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Tue, 16 Jul 2013 16:15:07 +0300
Subject: [PATCH 1/4] pinctrl: Remove duplicate code in
 pinctrl_pm_select_state functions
In-Reply-To: <20130716090529.5541.54331.stgit@localhost>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090529.5541.54331.stgit@localhost>
Message-ID: <51E5475B.1050900@ti.com>

Hi Tony,

This patch causes boot failure when I've applied my patch
"[RFC] ARM: OMAP2+: omap_device: add pinctrl handling"
https://lkml.org/lkml/2013/6/21/309

on top of it:

[    0.264007] L310 cache controller enabled
[    0.268310] l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000, 
Cache size: 1048576 B
[    0.282440] CPU1: Booted secondary processor
[    0.366760] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.367401] Brought up 2 CPUs
[    0.380920] SMP: Total of 2 processors activated (2387.96 BogoMIPS).
[    0.387573] CPU: All CPU(s) started in SVC mode.
[    0.395324] devtmpfs: initialized
[    0.468658] pinctrl core: initialized pinctrl subsystem
[    0.477996] regulator-dummy: no parameters
[    0.485412] NET: Registered protocol family 16
[    0.499145] DMA: preallocated 256 KiB pool for atomic coherent 
allocations
[    0.573181] Unable to handle kernel NULL pointer dereference at 
virtual address 00000008
[    0.581573] pgd = c0004000
[    0.584472] [00000008] *pgd=00000000
[    0.588226] Internal error: Oops: 5 [#1] SMP ARM
[    0.593078] Modules linked in:
[    0.596313] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
3.11.0-rc1-00005-g37e15e6-dirty #100
[    0.604888] task: de07f3c0 ti: de080000 task.ti: de080000
[    0.610565] PC is at pinctrl_pm_select_active_state+0x4/0xc
[    0.616394] LR is at _od_runtime_resume+0xc/0x20
[    0.621215] pc : [<c02d4e2c>]    lr : [<c002e930>]    psr: 60000193
[    0.621215] sp : de081cc0  ip : 60000193  fp : 00000000
[    0.633209] r10: de080000  r9 : c0067e90  r8 : 00000004
[    0.638671] r7 : c07800c0  r6 : c002e924  r5 : de0cf4a0  r4 : de0cf410
[    0.645477] r3 : 00000000  r2 : 00000004  r1 : 00000470  r0 : de0cf410
[    0.652282] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM 
Segment kernel
[    0.660003] Control: 10c53c7d  Table: 8000404a  DAC: 00000017
[    0.665985] Process swapper/0 (pid: 1, stack limit = 0xde080240)
[    0.672241] Stack: (0xde081cc0 to 0xde082000)
[    0.676818] 1cc0: de0cf410 c0335310 de0cf410 de0cb410 00000001 
c0335374 de0cf410 de0cb410
[    0.685333] 1ce0: 00000001 c033664c c0336b14 00000004 c1bbdedc 
00000000 00000000 c0507c5c
[    0.693847] 1d00: de0cf4a0 de0cf410 60000113 00000004 c1bbdedc 
00000000 00000000 c0336b24
[    0.702362] 1d20: de07f3c0 de11ea10 de0cf410 de0cf400 de0cd780 
c02df144 de0cd740 00000000
[    0.710845] 1d40: de0cf410 c0d6a634 de0cf410 00000000 00000000 
c07efe7c 00000000 00000000
[    0.719360] 1d60: 00000000 c032d794 c032d77c c032c554 de0cf410 
c032c784 00000000 00000000
[    0.727874] 1d80: c0d6a5f0 c032ac98 de07bed8 de0fd714 de0cf410 
de0cf444 c07f65e8 c032c48c
[    0.736389] 1da0: de0cf410 de0cf410 c07f65e8 c032b[RFC] ARM: OMAP2+: 
omap_device: add pinctrl handlinga94 de0cf410 de0cf418 de0cb410 c0329ef8
[    0.744873] 1dc0: 4a3101ff 00000000 00000200 00000000 00000000 
00000000 c076f630 00000000
[    0.753387] 1de0: de0cf400 00000000 de0cb410 c076f630 de0cb410 
00000000 00000000 c042c2dc
[    0.761901] 1e00: de0cb410 c1bbdedc 00000000 00000000 00000001 
c042c3dc 00000001 c076f630
[    0.770385] 1e20: 00000000 de0cb410 00000000 c0099068 60000113 
c080b22c c1bbdd98 00000001
[    0.778900] 1e40: c076f630 c1bbcaec 00000000 c1bbdedc 00000001 
c076f630 00000000 de0cb410
[    0.787414] 1e60: 00000000 c042c440 00000001 c076f630 00000000 
00000001 00000000 c0099068
[    0.795928] 1e80: 60000113 c080b22c 00000000 00000000 c076f630 
c1bbcaec c1bbc09c 00000000
[    0.804412] 1ea0: 00000000 c076f630 00000000 00000001 00000000 
c042c4e4 00000001 c072c37c
[    0.812927] 1ec0: c07221e0 de080000 c0762648 00000000 000000a4 
c077979c c071f1c8 c0730a6c
[    0.821441] 1ee0: c0760aec c07221fc 00000000 c0008978 00000083 
de07f3c0 60000193 00000000
[    0.829925] 1f00: 00000006 c07dbcd4 c07dbcd4 60000113 c02bf100 
00000000 c07dbcd0 c07dbcd0
[    0.838439] 1f20: 00000000 c0507c5c 00000002 de080000 c06f1920 
c1bc531d 000000a4 c00655ec
[    0.846954] 1f40: c06b2bd8 c06f0ee0 00000003 00000003 60000113 
c0762668 00000003 c0762648
[    0.855468] 1f60: c0817500 000000a4 c077979c c071f1c8 00000000 
c071f91c 00000003 00000003
[    0.863952] 1f80: c071f1c8 00000000 00000000 c04fd9ac 00000000 
00000000 00000000 00000000
[    0.872467] 1fa0: 00000000 c04fd9b4 00000000 c0013ac8 00000000 
00000000 00000000 00000000
[    0.880981] 1fc0: 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00000000
[    0.889465] 1fe0: 00000000 00000000 00000000 00000000 00000013 
00000000 ce5331ac 3153ceac
[    0.898010] [<c02d4e2c>] (pinctrl_pm_select_active_state+0x4/0xc) 
from [<c002e930>] (_od_runtime_resume+0xc/0x20)
[    0.908660] [<c002e930>] (_od_runtime_resume+0xc/0x20) from 
[<c0335310>] (__rpm_callback+0x34/0x70)
[    0.918060] [<c0335310>] (__rpm_callback+0x34/0x70) from [<c0335374>] 
(rpm_callback+0x28/0x88)
[    0.927032] [<c0335374>] (rpm_callback+0x28/0x88) from [<c033664c>] 
(rpm_resume+0x3c8/0x624)
[    0.935821] [<c033664c>] (rpm_resume+0x3c8/0x624) from [<c0336b24>] 
(__pm_runtime_resume+0x48/0x60)
[    0.945220] [<c0336b24>] (__pm_runtime_resume+0x48/0x60) from 
[<c02df144>] (omap_gpio_probe+0x254/0x6c0)
[    0.955078] [<c02df144>] (omap_gpio_probe+0x254/0x6c0) from 
[<c032d794>] (platform_drv_probe+0x18/0x1c)
[    0.964843] [<c032d794>] (platform_drv_probe+0x18/0x1c) from 
[<c032c554>] (driver_probe_device+0x88/0x220)
[    0.974884] [<c032c554>] (driver_probe_device+0x88/0x220) from 
[<c032ac98>] (bus_for_each_drv+0x5c/0x88)
[    0.984710] [<c032ac98>] (bus_for_each_drv+0x5c/0x88) from 
[<c032c48c>] (device_attach+0x80/0xa4)
[    0.993957] [<c032c48c>] (device_attach+0x80/0xa4) from [<c032ba94>] 
(bus_probe_device+0x88/0xac)
[    1.003173] [<c032ba94>] (bus_probe_device+0x88/0xac) from 
[<c0329ef8>] (device_add+0x418/0x61c)
[    1.012329] [<c0329ef8>] (device_add+0x418/0x61c) from [<c042c2dc>] 
(of_platform_device_create_pdata+0x5c/0x80)
[    1.022796] [<c042c2dc>] (of_platform_device_create_pdata+0x5c/0x80) 
from [<c042c3dc>] (of_platform_bus_create+0xdc/0x184)
[    1.034271] [<c042c3dc>] (of_platform_bus_create+0xdc/0x184) from 
[<c042c440>] (of_platform_bus_create+0x140/0x184)
[    1.045104] [<c042c440>] (of_platform_bus_create+0x140/0x184) from 
[<c042c4e4>] (of_platform_populate+0x60/0x98)
[    1.055664] [<c042c4e4>] (of_platform_populate+0x60/0x98) from 
[<c0730a6c>] (omap_generic_init+0x24/0x60)
[    1.065612] [<c0730a6c>] (omap_generic_init+0x24/0x60) from 
[<c07221fc>] (customize_machine+0x1c/0x40)
[    1.075286] [<c07221fc>] (customize_machine+0x1c/0x40) from 
[<c0008978>] (do_one_initcall+0xe4/0x148)
[    1.084869] [<c0008978>] (do_one_initcall+0xe4/0x148) from 
[<c071f91c>] (kernel_init_freeable+0xfc/0x1c8)
[    1.094818] [<c071f91c>] (kernel_init_freeable+0xfc/0x1c8) from 
[<c04fd9b4>] (kernel_init+0x8/0xe4)
[    1.104248] [<c04fd9b4>] (kernel_init+0x8/0xe4) from [<c0013ac8>] 
(ret_from_fork+0x14/0x2c)
[    1.112915] Code: e59031b4 e593100c eaffffde e59031b4 (e5931008)
[    1.119323] ---[ end trace fd7907bbe82cc699 ]---
[    1.124206] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0000000b
[    1.124206]
[    1.133789] CPU1: stopping
[    1.136657] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D 
3.11.0-rc1-00005-g37e15e6-dirty #100
[    1.146270] [<c001b62c>] (unwind_backtrace+0x0/0xf0) from 
[<c00177fc>] (show_stack+0x10/0x14)
[    1.155151] [<c00177fc>] (show_stack+0x10/0x14) from [<c05027cc>] 
(dump_stack+0x70/0x8c)
[    1.163574] [<c05027cc>] (dump_stack+0x70/0x8c) from [<c0019384>] 
(handle_IPI+0x130/0x158)
[    1.172180] [<c0019384>] (handle_IPI+0x130/0x158) from [<c0008760>] 
(gic_handle_irq+0x54/0x5c)
[    1.181121] [<c0008760>] (gic_handle_irq+0x54/0x5c) from [<c0508624>] 
(__irq_svc+0x44/0x5c)
[    1.189819] Exception stack(0xde0a7f90 to 0xde0a7fd8)
[    1.195098] 7f80:                                     c0014ca8 
000002da 00000000 00000000
[    1.203613] 7fa0: de0a6000 00000000 10c03c7d c0817774 c0514820 
c0815e40 c07869a8 00000000
[    1.212097] 7fc0: 01000000 de0a7fd8 c0014ca8 c0014cac 60000113 ffffffff
[    1.219024] [<c0508624>] (__irq_svc+0x44/0x5c) from [<c0014cac>] 
(arch_cpu_idle+0x38/0x44)
[    1.227630] [<c0014cac>] (arch_cpu_idle+0x38/0x44) from [<c00875d4>] 
(cpu_startup_entry+0xa8/0x228)
[    1.237030] [<c00875d4>] (cpu_startup_entry+0xa8/0x228) from 
[<80008264>] (0x80008264)


On 07/16/2013 12:05 PM, Tony Lindgren wrote:
> There's no need to duplicate essentially the same functions. Let's
> introduce static int pinctrl_pm_select_state() and make the other
> related functions call that.
>
> This allows us to add support later on for multiple active states,
> and more optimized dynamic remuxing.
>
> Note that we still need to export the various pinctrl_pm_select
> functions as we want to keep struct pinctrl_state private to the
> pinctrl code, and cannot replace those with inline functions.
>
> Cc: Stephen Warren <swarren at wwwdotorg.org>
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---
>   drivers/pinctrl/core.c |   47 +++++++++++++++++++----------------------------
>   1 file changed, 19 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> index 5b272bf..bda2c61 100644
> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -1227,23 +1227,34 @@ EXPORT_SYMBOL_GPL(pinctrl_force_default);
>   #ifdef CONFIG_PM
>
>   /**
> - * pinctrl_pm_select_default_state() - select default pinctrl state for PM
> + * pinctrl_pm_select_state() - select pinctrl state for PM
>    * @dev: device to select default state for
> + * @state: state to set
>    */
> -int pinctrl_pm_select_default_state(struct device *dev)
> +static int pinctrl_pm_select_state(struct device *dev, struct pinctrl_state *state)
>   {
>   	struct dev_pin_info *pins = dev->pins;
>   	int ret;
>
>   	if (!pins)
>   		return 0;
> -	if (IS_ERR(pins->default_state))
> -		return 0; /* No default state */
> -	ret = pinctrl_select_state(pins->p, pins->default_state);
> +	if (IS_ERR(state))
> +		return 0; /* No such state */
> +	ret = pinctrl_select_state(pins->p, state);
>   	if (ret)
> -		dev_err(dev, "failed to activate default pinctrl state\n");
> +		dev_err(dev, "failed to activate pinctrl state %s\n",
> +			state->name);
>   	return ret;
>   }
> +
> +/**
> + * pinctrl_pm_select_default_state() - select default pinctrl state for PM
> + * @dev: device to select default state for
> + */
> +int pinctrl_pm_select_default_state(struct device *dev)
> +{

Seems, need to keep check for !dev->pins here
if (!dev->pins)
	                return 0;

> +	return pinctrl_pm_select_state(dev, dev->pins->default_state);
> +}
>   EXPORT_SYMBOL_GPL(pinctrl_pm_select_default_state);
>
>   /**
> @@ -1252,17 +1263,7 @@ EXPORT_SYMBOL_GPL(pinctrl_pm_select_default_state);
>    */
>   int pinctrl_pm_select_sleep_state(struct device *dev)
>   {
> -	struct dev_pin_info *pins = dev->pins;
> -	int ret;
> -
> -	if (!pins)
> -		return 0;
> -	if (IS_ERR(pins->sleep_state))
> -		return 0; /* No sleep state */
> -	ret = pinctrl_select_state(pins->p, pins->sleep_state);
> -	if (ret)
> -		dev_err(dev, "failed to activate pinctrl sleep state\n");
> -	return ret;
here
if (!dev->pins)
	                return 0;
> +	return pinctrl_pm_select_state(dev, dev->pins->sleep_state);
>   }
>   EXPORT_SYMBOL_GPL(pinctrl_pm_select_sleep_state);
>
> @@ -1272,17 +1273,7 @@ EXPORT_SYMBOL_GPL(pinctrl_pm_select_sleep_state);
>    */
>   int pinctrl_pm_select_idle_state(struct device *dev)
>   {
> -	struct dev_pin_info *pins = dev->pins;
> -	int ret;
> -
> -	if (!pins)
> -		return 0;
> -	if (IS_ERR(pins->idle_state))
> -		return 0; /* No idle state */
> -	ret = pinctrl_select_state(pins->p, pins->idle_state);
> -	if (ret)
> -		dev_err(dev, "failed to activate pinctrl idle state\n");
> -	return ret;
here
if (!dev->pins)
	                return 0;
> +	return pinctrl_pm_select_state(dev, dev->pins->idle_state);
>   }
>   EXPORT_SYMBOL_GPL(pinctrl_pm_select_idle_state);
>   #endif
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



From arend at broadcom.com  Tue Jul 16 09:18:55 2013
From: arend at broadcom.com (Arend van Spriel)
Date: Tue, 16 Jul 2013 15:18:55 +0200
Subject: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock
In-Reply-To: <51E546D2.6000100@broadcom.com>
References: <1371571487-14389-1-git-send-email-rogerq@ti.com>
 <1371571487-14389-5-git-send-email-rogerq@ti.com>
 <51E40199.9070906@ti.com> <51E546D2.6000100@broadcom.com>
Message-ID: <51E5483F.4020209@broadcom.com>

On 07/16/2013 03:12 PM, Arend van Spriel wrote:
> On 07/15/2013 04:05 PM, Roger Quadros wrote:
>> Hi Tony,
>>
>> On 06/18/2013 07:04 PM, Roger Quadros wrote:
>>> Till the OMAP clocks are correctly defined in device tree, use
>>> this temporary hack to provide clock alias to the USB PHY clocks.
>>>
>>> Without this, USB Host & Ethernet will not be functional with
>>> device tree boots on Panda and uEVM.
>>
>> Looks like this one got missed out.
>
> Could it be because you promised to resend it (see [1]). I was upgrading
> our test stuff to 3.11-rc1 and made a DT appended image. Boot went fine,
> but no USB/ethernet. Should I pickup all four patches?

Nevermind. The first three seem to be in already.

> Regards,
> Arend
>
> [1] http://mid.gmane.org/51C2EC5F.8050703 at ti.com
>
>> USB host no longer works on Panda with DT boot.
>> Could you please queue this for next 3.11-rc? Thanks.
>>
>> cheers,
>> -roger
>>
>




From jonas.jensen at gmail.com  Tue Jul 16 09:24:15 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Tue, 16 Jul 2013 15:24:15 +0200
Subject: [PATCH v2] watchdog: Add MOXA ART watchdog driver
In-Reply-To: <1373545786-7151-1-git-send-email-jonas.jensen@gmail.com>
References: <1373545786-7151-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1373981055-18515-1-git-send-email-jonas.jensen@gmail.com>

Add watchdog driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Thanks for the review Guenter.
    
    Changes since v1:
    
    1. remove moxart_wdt_ping
    2. remove unnecessary max timeout check in moxart_wdt_set_timeout
    3. remove arm_pm_restart and moxart_wdt_restart function
       (moved to moxart platform startup code)
    4. remove unnecessary watchdog_set_drvdata from moxart_wdt_remove
    5. stop the watchdog on driver remove
    
    Applies to next-20130716

 drivers/watchdog/Kconfig      |  10 +++
 drivers/watchdog/Makefile     |   1 +
 drivers/watchdog/moxart_wdt.c | 171 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 182 insertions(+)
 create mode 100644 drivers/watchdog/moxart_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 362085d..6883aab 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -382,6 +382,16 @@ config RETU_WATCHDOG
 	  To compile this driver as a module, choose M here: the
 	  module will be called retu_wdt.
 
+config MOXART_WDT
+	tristate "MOXART watchdog"
+	depends on ARCH_MOXART
+	help
+	  Say Y here to include Watchdog timer support for the watchdog
+	  existing on the MOXA ART SoC series platforms.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called moxart_wdt.
+
 # AVR32 Architecture
 
 config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 2f26a0b..7cab53a 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
 obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
 obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
 obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
+obj-$(CONFIG_MOXART_WDT) += moxart_wdt.o
 
 # AVR32 Architecture
 obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
new file mode 100644
index 0000000..966855d
--- /dev/null
+++ b/drivers/watchdog/moxart_wdt.c
@@ -0,0 +1,171 @@
+/*
+ * MOXA ART SoCs watchdog driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+#include <linux/watchdog.h>
+
+#include <asm/system_misc.h>
+
+#define REG_COUNT			0x4
+#define REG_MODE			0x8
+#define REG_ENABLE			0xC
+
+struct moxart_wdt_dev {
+	struct watchdog_device wdt_dev;
+	void __iomem *wdt_base;
+};
+
+static struct moxart_wdt_dev *moxart_wdt;
+static bool nowayout = WATCHDOG_NOWAYOUT;
+static int heartbeat;
+static unsigned int clock_frequency;
+static unsigned int max_timeout;
+
+static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+	void __iomem *wdt_base = moxart_wdt->wdt_base;
+
+	writel(0, wdt_base + REG_ENABLE);
+
+	return 0;
+}
+
+static int moxart_wdt_start(struct watchdog_device *wdt_dev)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+	void __iomem *wdt_base = moxart_wdt->wdt_base;
+
+	writel(clock_frequency * moxart_wdt->wdt_dev.timeout,
+	       wdt_base + REG_COUNT);
+	writel(0x5ab9, wdt_base + REG_MODE);
+	writel(0x03, wdt_base + REG_ENABLE);
+
+	return 0;
+}
+
+static int moxart_wdt_set_timeout(struct watchdog_device *wdt_dev,
+				  unsigned int timeout)
+{
+	dev_dbg(wdt_dev->dev, "%s: timeout=%u\n", __func__, timeout);
+
+	moxart_wdt->wdt_dev.timeout = timeout;
+
+	return 0;
+}
+
+static const struct watchdog_info moxart_wdt_info = {
+	.identity       = "moxart-wdt",
+	.options        = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
+static const struct watchdog_ops moxart_wdt_ops = {
+	.owner          = THIS_MODULE,
+	.start          = moxart_wdt_start,
+	.stop           = moxart_wdt_stop,
+	.set_timeout    = moxart_wdt_set_timeout,
+};
+
+static int moxart_wdt_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct resource *res;
+	struct clk *clk;
+	int err;
+
+	moxart_wdt = devm_kzalloc(&pdev->dev, sizeof(*moxart_wdt), GFP_KERNEL);
+	if (!moxart_wdt)
+		return -EINVAL;
+
+	platform_set_drvdata(pdev, moxart_wdt);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	moxart_wdt->wdt_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_wdt->wdt_base))
+		return PTR_ERR(moxart_wdt->wdt_base);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk)) {
+		pr_err("%s: of_clk_get failed\n", __func__);
+		return PTR_ERR(clk);
+	}
+
+	clock_frequency = clk_get_rate(clk);
+
+	max_timeout = UINT_MAX / clock_frequency;
+
+	moxart_wdt->wdt_dev.info = &moxart_wdt_info;
+	moxart_wdt->wdt_dev.ops = &moxart_wdt_ops;
+	moxart_wdt->wdt_dev.timeout = max_timeout;
+	moxart_wdt->wdt_dev.min_timeout = 1;
+	moxart_wdt->wdt_dev.max_timeout = max_timeout;
+	moxart_wdt->wdt_dev.parent = &pdev->dev;
+
+	watchdog_init_timeout(&moxart_wdt->wdt_dev, heartbeat, &pdev->dev);
+	watchdog_set_nowayout(&moxart_wdt->wdt_dev, nowayout);
+
+	watchdog_set_drvdata(&moxart_wdt->wdt_dev, moxart_wdt);
+
+	err = watchdog_register_device(&moxart_wdt->wdt_dev);
+	if (unlikely(err))
+		return err;
+
+	dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
+		moxart_wdt->wdt_dev.timeout, nowayout);
+
+	return 0;
+}
+
+static int moxart_wdt_remove(struct platform_device *pdev)
+{
+	struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
+
+	moxart_wdt_stop(&moxart_wdt->wdt_dev);
+	watchdog_unregister_device(&moxart_wdt->wdt_dev);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_watchdog_match[] = {
+	{ .compatible = "moxa,moxart-watchdog" },
+	{ },
+};
+
+static struct platform_driver moxart_wdt_driver = {
+	.probe      = moxart_wdt_probe,
+	.remove     = moxart_wdt_remove,
+	.driver     = {
+		.name		= "moxart-watchdog",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_watchdog_match,
+	},
+};
+module_platform_driver(moxart_wdt_driver);
+
+module_param(heartbeat, int, 0);
+MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");
+
+MODULE_DESCRIPTION("MOXART watchdog driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From jason at lakedaemon.net  Tue Jul 16 09:24:30 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 16 Jul 2013 09:24:30 -0400
Subject: [PATCH 06/10] watchdog: orion: Update device-tree binding
 documentation
In-Reply-To: <1373931163-12670-7-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1373931163-12670-7-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130716132430.GD12062@titan.lakedaemon.net>

On Mon, Jul 15, 2013 at 08:32:39PM -0300, Ezequiel Garcia wrote:
> Now that the 'reg' property meaning has been changed,
> this commit updates the deivce-tree binding documentation.

nit. s/deivce/device/

> 
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> ---
>  Documentation/devicetree/bindings/watchdog/orion-wdt.txt | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/orion-wdt.txt b/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
> index 5dc8d30..48a71fc 100644
> --- a/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
> @@ -3,7 +3,8 @@
>  Required Properties:
>  
>  - Compatibility : "marvell,orion-wdt"
> -- reg		: Address of the timer registers
> +- reg		: First cell contains the register for the watchdog counter.
> +		  Second cell contains the register for the RSTOUT mask.
>  
>  Optional properties:
>  
> @@ -11,9 +12,10 @@ Optional properties:
>  
>  Example:
>  
> -	wdt at 20300 {
> +	wdt at 20324 {
>  		compatible = "marvell,orion-wdt";
> -		reg = <0x20300 0x28>;
> +		reg = <0x20324 0x4
> +		       0x20108 0x4>;
>  		timeout-sec = <10>;
>  		status = "okay";
>  	};
> -- 
> 1.8.1.5
> 


From shawn.guo at linaro.org  Tue Jul 16 09:31:02 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 21:31:02 +0800
Subject: [PATCH] ARM: imx: add low-level debug for vybrid
Message-ID: <1373981462-22670-1-git-send-email-shawn.guo@linaro.org>

Add low-level debug support for vybrid, so that earlyprintk can be
enabled for debugging early boot issue.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/Kconfig.debug      |    8 ++++++++
 arch/arm/include/debug/vf.S |   26 ++++++++++++++++++++++++++
 2 files changed, 34 insertions(+)
 create mode 100644 arch/arm/include/debug/vf.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e401a76..0aa5b9d 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -355,6 +355,13 @@ choice
 		  when u-boot hands over to the kernel, the system
 		  silently crashes, with no serial output at all.
 
+	config DEBUG_VF_UART
+		bool "Vybrid UART"
+		depends on SOC_VF610
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Vybrid based platforms.
+
 	config DEBUG_NOMADIK_UART
 		bool "Kernel low-level debugging messages via NOMADIK UART"
 		depends on ARCH_NOMADIK
@@ -798,6 +805,7 @@ config DEBUG_LL_INCLUDE
 	default "debug/vexpress.S" if DEBUG_VEXPRESS_UART0_DETECT || \
 		DEBUG_VEXPRESS_UART0_CA9 || DEBUG_VEXPRESS_UART0_RS1 || \
 		DEBUG_VEXPRESS_UART0_CRX
+	default "debug/vf.S" if DEBUG_VF_UART
 	default "debug/vt8500.S" if DEBUG_VT8500_UART0
 	default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
 	default "mach/debug-macro.S"
diff --git a/arch/arm/include/debug/vf.S b/arch/arm/include/debug/vf.S
new file mode 100644
index 0000000..ba12cc4
--- /dev/null
+++ b/arch/arm/include/debug/vf.S
@@ -0,0 +1,26 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =0x40028000	@ physical
+	ldr	\rv, =0xfe028000	@ virtual
+	.endm
+
+	.macro	senduart, rd, rx
+	strb	\rd, [\rx, #0x7]	@ Data Register
+	.endm
+
+	.macro	busyuart, rd, rx
+1001:	ldrb	\rd, [\rx, #0x4]	@ Status Register 1
+	tst	\rd, #1 << 6		@ TC
+	beq	1001b			@ wait until transmit done
+	.endm
+
+	.macro	waituart,rd,rx
+	.endm
-- 
1.7.9.5




From fabio.estevam at freescale.com  Tue Jul 16 09:32:39 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Tue, 16 Jul 2013 10:32:39 -0300
Subject: [PATCH] ARM: mxs: pm: Include "pm.h"
Message-ID: <1373981559-23743-1-git-send-email-fabio.estevam@freescale.com>

Fix the following sparse warning:

arch/arm/mach-mxs/pm.c:37:13: warning: symbol 'mxs_pm_init' was not declared. Should it be static?

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/mach-mxs/pm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mxs/pm.c b/arch/arm/mach-mxs/pm.c
index b2494d2..0170e99 100644
--- a/arch/arm/mach-mxs/pm.c
+++ b/arch/arm/mach-mxs/pm.c
@@ -15,6 +15,7 @@
 #include <linux/kernel.h>
 #include <linux/suspend.h>
 #include <linux/io.h>
+#include "pm.h"
 
 static int mxs_suspend_enter(suspend_state_t state)
 {
-- 
1.8.1.2




From fabio.estevam at freescale.com  Tue Jul 16 09:33:43 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Tue, 16 Jul 2013 10:33:43 -0300
Subject: [PATCH] clk: mxs: clk-imx23: Include <linux/clk/mxs.h>
Message-ID: <1373981623-23800-1-git-send-email-fabio.estevam@freescale.com>

Fix the following sparse warning:

drivers/clk/mxs/clk-imx23.c:102:12: warning: symbol 'mx23_clocks_init' was not declared. Should it be static?

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 drivers/clk/mxs/clk-imx23.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/mxs/clk-imx23.c b/drivers/clk/mxs/clk-imx23.c
index f6a7487..c396fe3 100644
--- a/drivers/clk/mxs/clk-imx23.c
+++ b/drivers/clk/mxs/clk-imx23.c
@@ -10,6 +10,7 @@
  */
 
 #include <linux/clk.h>
+#include <linux/clk/mxs.h>
 #include <linux/clkdev.h>
 #include <linux/err.h>
 #include <linux/init.h>
-- 
1.8.1.2




From thomas.petazzoni at free-electrons.com  Tue Jul 16 09:39:11 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Jul 2013 15:39:11 +0200
Subject: [PATCHv5 00/11] MSI support for Marvell EBU PCIe driver
In-Reply-To: <20130716131547.GC12062@titan.lakedaemon.net>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E4167B.4000208@wwwdotorg.org> <20130716104347.045a612a@skate>
 <20130716131547.GC12062@titan.lakedaemon.net>
Message-ID: <20130716153911.423cc408@skate>

Dear Jason Cooper,

On Tue, 16 Jul 2013 09:15:47 -0400, Jason Cooper wrote:

> > A quick diagram of the dependencies, best viewed with a fixed-size font
> > mailer.
> > 
> > kernel/irq/irqdomain    drivers/pci        arch/arm/kernel
> >      patch 1           patch 2, 3, 4           patch 8
> >         ||                  ||                   ||
> >         ||                  \/                   \/
> >         ||               drivers/of   ==> drivers/pci/host
> >         ||                patch 5           patch 10
> >         ||                  ||
> >         \\__________________//
> >                   ||
> >                   \/
> >             drivers/irqchip
> >               patch 6, 7
> 
> Well, that got more complicated.  :(  No cookie for you.

Yeah, sorry about this. I'm not sure how to handle that differently.

> > Patches 9 and 11 are DT patches, so they are not mentioned in this
> > diagram.
> > 
> > Normally tegra would require 1, 2, 3, 4, 5 and 8, so ideally, with
> > the respective maintainers ACKs, Jason Cooper could take them in a
> > specific topic stable branch that would not be rebased, on top of which
> > both the Marvell work and Tegra work could be done.
> 
> After my recent discussions with tglx, here's my proposal:
> 
> - rmk creates a dedicated topic branch with patch 8
> 
> - Bjorn creates a dedicated topic branch based on rmk's with 2, 3, 4, 5,
>   and 10
> 
> - tglx creates a dedicated topic branch based on Bjorn's with 1, 6, 7

I am wondering if this merge strategy isn't too complicated to work
nicely. Would it be easier if one person took all of those patches in a
stable topic branch, with the ACKs from the proper maintainers?

But anyway, as long as things get merged, I don't really mind what
merge strategy is used, so I'll trust on what will be the best option
on this.

Thanks a lot for taking care of this!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From rogerq at ti.com  Tue Jul 16 09:39:25 2013
From: rogerq at ti.com (Roger Quadros)
Date: Tue, 16 Jul 2013 16:39:25 +0300
Subject: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock
In-Reply-To: <20130716123256.GY7656@atomide.com>
References: <1371571487-14389-1-git-send-email-rogerq@ti.com>
 <1371571487-14389-5-git-send-email-rogerq@ti.com> <51E40199.9070906@ti.com>
 <20130716123256.GY7656@atomide.com>
Message-ID: <51E54D0D.3030200@ti.com>

On 07/16/2013 03:32 PM, Tony Lindgren wrote:
> * Roger Quadros <rogerq at ti.com> [130715 07:11]:
>> Hi Tony,
>>
>> On 06/18/2013 07:04 PM, Roger Quadros wrote:
>>> Till the OMAP clocks are correctly defined in device tree, use
>>> this temporary hack to provide clock alias to the USB PHY clocks.
>>>
>>> Without this, USB Host & Ethernet will not be functional with
>>> device tree boots on Panda and uEVM.
>>
>> Looks like this one got missed out.
>>
>> USB host no longer works on Panda with DT boot.
>> Could you please queue this for next 3.11-rc? Thanks.
> 
> OK thanks for checking, applying into omap-for-v3.11/fixes.

Thanks.

> 
> Looks like I also have some pending the .dts changes in
> omap-for-v3.11/dt branch:
> 
> 4cf2198b1e3cee47a1cccbb500b67782c36615d5 ARM: dts: omap3-beagle-xm: Add USB host supprot for Rev. Ax/Bx
> 9bc44515819a00c0ffaf751ad497ddf275089ede ARM: dts: omap3-beagle-xm: Add USB Host support
> fd65d7df4598c1d2ad27d664c719611a1a070edc ARM: dts: omap3-beagle: Make USB host pin naming consistent

Please disregard those. They are old versions.

Benoit had agreed to take the newer version of those for 3.12.

Please pick this one to get usb host working on 3.11 with DT.

http://www.spinics.net/lists/arm-kernel/msg253612.html

> 39ea891d9da6ae1824bc9f689db3f306f5ce0724 ARM: dts: omap4-panda: Add USB Host support

This one is already in through Benoit.

cheers,
-roger


From yadi.brar01 at gmail.com  Tue Jul 16 09:40:34 2013
From: yadi.brar01 at gmail.com (Yadwinder Singh Brar)
Date: Tue, 16 Jul 2013 19:10:34 +0530
Subject: [PATCH v7 00/11] Add generic set_rate clk_ops for PLL35xx and
 PLL36xx for samsung SoCs
In-Reply-To: <007001ce7149$1f683f40$5e38bdc0$%kim@samsung.com>
References: <1370943076-13461-1-git-send-email-yadi.brar@samsung.com>
 <CAKew6eUOy4=D08v_iq7CTRY5gvt37VAN7Z7WOr2Yt25znDJb2g@mail.gmail.com>
 <CAGm_ybiVZOPBJJ0bYX33wafn1So6aqSAnk7myXZ+Z+RfLBeBQw@mail.gmail.com>
 <1524664.UCV47tfIRU@flatron> <20130621163143.9136.28807@quantum>
 <51C85F8F.9050501@samsung.com> <20130624190227.20448.68120@quantum>
 <007001ce7149$1f683f40$5e38bdc0$%kim@samsung.com>
Message-ID: <CAKew6eVW6dOzLRN2CG8jT3Oo1uzKrXqi1aRYkAHmUu61dBSDpA@mail.gmail.com>

Hi Kukjin / Mike,

On Tue, Jun 25, 2013 at 7:40 AM, Kukjin Kim <kgene.kim at samsung.com> wrote:
> Mike Turquette wrote:
>>
>> Quoting Kukjin Kim (2013-06-24 08:02:39)
>> > On 06/22/13 01:31, Mike Turquette wrote:
>> > >
>> > > Acked-by: Mike Turquette<mturquette at linaro.org>
>> > >
>> > > Or I can take this through the clk tree. Either way is fine.
>> > >
>> > Mike, please go ahead taking this series into the clk tree for 3.11.
>>
>> Actually it might be better for you to take it. Patch #5 relies on
>> drivers/clk/samsung/clk-exynos5420.c which only exists in the samsung
>> tree.  It was introduced by commit 1609027f, "clk: exynos5420: register
>> clocks using common clock framework".
>>
> Yes, you're right. It depends on soc-exynos5420 stuff in samsung tree.
>
>> And these patches need to be applied with some fuzz to the clk tree due
>> to other changes which are not in my tree and only present in yours.
>>
>> The best two options are either for you to take this series or it can be
>> rebased on top of clk-next, after which I'll apply it.
>>
> Let me try to send this series via samsung tree for v3.11 but I'm not sure because it's a little bit late for arm-soc tree.
>
> Thanks for your ack, just note I will send to arm-soc tonight in my time.
>

Can we get this series merge now in any of trees.
Please let me if its required to rebase it.

Regards,
Yadwinder


From tony at atomide.com  Tue Jul 16 09:41:18 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 06:41:18 -0700
Subject: [PATCH 1/4] pinctrl: Remove duplicate code in
 pinctrl_pm_select_state functions
In-Reply-To: <51E5475B.1050900@ti.com>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090529.5541.54331.stgit@localhost>
 <51E5475B.1050900@ti.com>
Message-ID: <20130716134118.GC7656@atomide.com>

* Grygorii Strashko <grygorii.strashko at ti.com> [130716 06:22]:
> Hi Tony,
> 
> This patch causes boot failure when I've applied my patch
> "[RFC] ARM: OMAP2+: omap_device: add pinctrl handling"
> https://lkml.org/lkml/2013/6/21/309
>
> on top of it:

Hmm this patch alone removes duplicate code and if it causes
issues I must have made a typo somewhere.

I cannot see a typo though, but in your dmesg I see something..

> [    0.610565] PC is at pinctrl_pm_select_active_state+0x4/0xc

..looks like you have something applied for the active_state
that only gets introduced later on in this series.

Maybe you have the earlier version of drivers/base/pinctrl.c
active_state patch that was in linux next for a while but
got reverted as we noticed we had to rework some things?

So maybe try with v3.11-rc1 + these four patches + your
omap_device patch?

Regards,

Tony


From tony at atomide.com  Tue Jul 16 09:43:50 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 06:43:50 -0700
Subject: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock
In-Reply-To: <51E54D0D.3030200@ti.com>
References: <1371571487-14389-1-git-send-email-rogerq@ti.com>
 <1371571487-14389-5-git-send-email-rogerq@ti.com>
 <51E40199.9070906@ti.com> <20130716123256.GY7656@atomide.com>
 <51E54D0D.3030200@ti.com>
Message-ID: <20130716134350.GD7656@atomide.com>

* Roger Quadros <rogerq at ti.com> [130716 06:45]:
> On 07/16/2013 03:32 PM, Tony Lindgren wrote:
> > * Roger Quadros <rogerq at ti.com> [130715 07:11]:
> >> Hi Tony,
> >>
> >> On 06/18/2013 07:04 PM, Roger Quadros wrote:
> >>> Till the OMAP clocks are correctly defined in device tree, use
> >>> this temporary hack to provide clock alias to the USB PHY clocks.
> >>>
> >>> Without this, USB Host & Ethernet will not be functional with
> >>> device tree boots on Panda and uEVM.
> >>
> >> Looks like this one got missed out.
> >>
> >> USB host no longer works on Panda with DT boot.
> >> Could you please queue this for next 3.11-rc? Thanks.
> > 
> > OK thanks for checking, applying into omap-for-v3.11/fixes.
> 
> Thanks.
> 
> > 
> > Looks like I also have some pending the .dts changes in
> > omap-for-v3.11/dt branch:
> > 
> > 4cf2198b1e3cee47a1cccbb500b67782c36615d5 ARM: dts: omap3-beagle-xm: Add USB host supprot for Rev. Ax/Bx
> > 9bc44515819a00c0ffaf751ad497ddf275089ede ARM: dts: omap3-beagle-xm: Add USB Host support
> > fd65d7df4598c1d2ad27d664c719611a1a070edc ARM: dts: omap3-beagle: Make USB host pin naming consistent
> 
> Please disregard those. They are old versions.

OK, poof that branch is now gone.
 
> Benoit had agreed to take the newer version of those for 3.12.
> 
> Please pick this one to get usb host working on 3.11 with DT.
> 
> http://www.spinics.net/lists/arm-kernel/msg253612.html
> 
> > 39ea891d9da6ae1824bc9f689db3f306f5ce0724 ARM: dts: omap4-panda: Add USB Host support
> 
> This one is already in through Benoit.

It's best that Benoit queue all those to avoid more confusion :)

Regards,

Tony


From jason at lakedaemon.net  Tue Jul 16 09:44:22 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 16 Jul 2013 09:44:22 -0400
Subject: [PATCH 00/10] Orion Watchdog fixes
In-Reply-To: <20130716121432.GA2317@localhost>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130716065952.GA25043@lunn.ch> <20130716092059.237ea729@skate>
 <20130716073101.GB25043@lunn.ch> <20130716121432.GA2317@localhost>
Message-ID: <20130716134422.GE12062@titan.lakedaemon.net>

On Tue, Jul 16, 2013 at 09:14:33AM -0300, Ezequiel Garcia wrote:
> On the other side, I'm much interested in knowing if you are OK with
> breaking the watchdog DT compatibility. If you NACK this, then I'll
> start preparing a different watchdog driver for 370/XP, since I don't
> want to extend a driver that is a bit dirty.

Apparently there is some agreement that the bindings are still in flux
and that they need to be for a bit longer in order to hammer out
problems such as this.

Arnd and Olof both mentioned that something (a doc, and email?) is
forthcoming about marking some bindings as stable.  Whatever form that
takes, this one wouldn't get the stable marking yet. ;-)

Oh, and one more nit.  The work 'fix' triggers a whole bunch of "get on
this right away, does it need to go to stable?  Has anyone confirmed it?
Which commit caused the regression? etc."  Although I hate the word, I
think 'refactoring' is much more appropriate description for this series.

thx,

Jason.



From mperttunen at nvidia.com  Tue Jul 16 09:51:13 2013
From: mperttunen at nvidia.com (Mikko Perttunen)
Date: Tue, 16 Jul 2013 16:51:13 +0300
Subject: [PATCH V2] ARM: tegra: enable palmas device for dalmore
In-Reply-To: <1373441852-27176-1-git-send-email-ldewangan@nvidia.com>
References: <1373441852-27176-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <51E54FD1.1010404@nvidia.com>

On 07/10/2013 10:37 AM, Laxman Dewangan wrote:
> Make the entry of Dalmore Power Management Unit device TPS65913
> in dalmore DTS file. The Palma driver support this device.
>
> Enable following submodule of the TPS65913:
> - GPIO driver
> - RTC driver.
> - Power regulator driver.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> ---
> Changes from V1:
> - renames nodes from palams_* to simple as gpio, rtc, pmic etc.
> - Added line gap properly.
> - Remove comment for palams-gpio reference as the entry itself explain.
> - Remove unit address for tps65913.
>
>   arch/arm/boot/dts/tegra114-dalmore.dts |  184 +++++++++++++++++++++++++++++++-
>   1 files changed, 183 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
> index a42bfa4..7bdad77 100644
> --- a/arch/arm/boot/dts/tegra114-dalmore.dts
> +++ b/arch/arm/boot/dts/tegra114-dalmore.dts
> @@ -791,7 +791,7 @@
>   					regulator-boot-on;
>   				};
>
> -				dcdc3 {
> +				tps65090_dcdc3_reg: dcdc3 {
>   					regulator-name = "vdd-ao";
>   					regulator-always-on;
>   					regulator-boot-on;
> @@ -836,6 +836,178 @@
>   				};
>   			};
>   		};
> +
> +		palmas: tps65913 {
> +			compatible = "ti,palmas";
> +			reg = <0x58>;
> +			interrupts = <0 86 0x4>;
> +
> +			#interrupt-cells = <2>;
> +			interrupt-controller;
> +
> +			palmas_gpio: gpio {
> +				compatible = "ti,palmas-gpio";
> +				gpio-controller;
> +				#gpio-cells = <2>;
> +			};

I don't think the palmas-gpio driver ever gets probed since it doesn't
have device tree compability strings?

> ...


From hauke at hauke-m.de  Tue Jul 16 09:52:07 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Tue, 16 Jul 2013 15:52:07 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM
 CPU
Message-ID: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>

This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU.
Currently just booting to a shell is working and nothing else, no
Ethernet, wifi, flash, ...

This SoC uses a Dual core CPU, but this is currently not implemented.
More information about this SoC can be found here:
http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers

Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
---

A bootlog can be found here:
http://pastebin.com/0MYYC7Fx

 MAINTAINERS                                  |    7 +++
 arch/arm/Kconfig                             |    2 +
 arch/arm/Kconfig.debug                       |    5 ++
 arch/arm/Makefile                            |    1 +
 arch/arm/boot/dts/Makefile                   |    1 +
 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts |   20 +++++++
 arch/arm/boot/dts/bcm5301x.dtsi              |   72 ++++++++++++++++++++++++++
 arch/arm/include/debug/bcm53xx.S             |   19 +++++++
 arch/arm/mach-bcm53xx/Kconfig                |   10 ++++
 arch/arm/mach-bcm53xx/Makefile               |    1 +
 arch/arm/mach-bcm53xx/bcm53xx.c              |   68 ++++++++++++++++++++++++
 11 files changed, 206 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
 create mode 100644 arch/arm/boot/dts/bcm5301x.dtsi
 create mode 100644 arch/arm/include/debug/bcm53xx.S
 create mode 100644 arch/arm/mach-bcm53xx/Kconfig
 create mode 100644 arch/arm/mach-bcm53xx/Makefile
 create mode 100644 arch/arm/mach-bcm53xx/bcm53xx.c

diff --git a/MAINTAINERS b/MAINTAINERS
index bf61e04..b72ba65 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1795,6 +1795,13 @@ F:	arch/arm/boot/dts/bcm2835*
 F:	arch/arm/configs/bcm2835_defconfig
 F:	drivers/*/*bcm2835*
 
+BROADCOM BCM53XX ARM ARCHICTURE
+M:	Hauke Mehrtens <hauke at hauke-m.de>
+L:	linux-arm-kernel at lists.infradead.org
+S:	Maintained
+F:	arch/arm/mach-bcm53xx/
+F:	arch/arm/boot/dts/bcm53*
+
 BROADCOM TG3 GIGABIT ETHERNET DRIVER
 M:	Nithin Nayak Sujir <nsujir at broadcom.com>
 M:	Michael Chan <mchan at broadcom.com>
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..ee7362e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -930,6 +930,8 @@ source "arch/arm/mach-bcm/Kconfig"
 
 source "arch/arm/mach-bcm2835/Kconfig"
 
+source "arch/arm/mach-bcm53xx/Kconfig"
+
 source "arch/arm/mach-clps711x/Kconfig"
 
 source "arch/arm/mach-cns3xxx/Kconfig"
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e401a76..74e32f6 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -93,6 +93,10 @@ choice
 		bool "Kernel low-level debugging on BCM2835 PL011 UART"
 		depends on ARCH_BCM2835
 
+	config DEBUG_BCM53XX
+		bool "Kernel low-level debugging on BCM53XX UART1"
+		depends on ARCH_BCM53XX
+
 	config DEBUG_CLPS711X_UART1
 		bool "Kernel low-level debugging messages via UART1"
 		depends on ARCH_CLPS711X
@@ -762,6 +766,7 @@ endchoice
 config DEBUG_LL_INCLUDE
 	string
 	default "debug/bcm2835.S" if DEBUG_BCM2835
+	default "debug/bcm53xx.S" if DEBUG_BCM53XX
 	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
 	default "debug/exynos.S" if DEBUG_EXYNOS_UART
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c0ac0f5..4a69cd5 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 machine-$(CONFIG_ARCH_AT91)		+= at91
 machine-$(CONFIG_ARCH_BCM)		+= bcm
 machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
+machine-$(CONFIG_ARCH_BCM53XX)		+= bcm53xx
 machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
 machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
 machine-$(CONFIG_ARCH_DAVINCI)		+= davinci
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..480a68e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -242,6 +242,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
 dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
 	zynq-zc706.dtb \
 	zynq-zed.dtb
+dtb-$(CONFIG_ARCH_BCM53XX) += bcm5301x-netgear-r6250.dtb
 
 targets += dtbs
 targets += $(dtb-y)
diff --git a/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
new file mode 100644
index 0000000..d1b97aa
--- /dev/null
+++ b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
@@ -0,0 +1,20 @@
+/*
+ * Broadcom BCM47XX / BCM53XX arm platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+/dts-v1/;
+
+/include/ "bcm5301x.dtsi"
+
+/ {
+	model = "Netgear R6250 V1 (BCM4708)";
+	compatible = "netgear,r6250v1", "brcm,bcm5301x";
+
+	memory {
+		reg = <0x00000000 0x08000000>;
+	};
+};
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
new file mode 100644
index 0000000..638350d
--- /dev/null
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -0,0 +1,72 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "brcm,bcm5301x";
+	model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC";
+	interrupt-parent = <&gic>;
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk debug";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+		};
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk_periph: periph {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <400000000>;
+		};
+	};
+
+	uart at 18000300 {
+		compatible = "ns16550";
+		reg = <0x18000300 0x100>;
+		interrupts = <0 85 4>;
+		clock-frequency = <100000000>;
+	};
+
+	uart at 18000400 {
+		compatible = "ns16550";
+		reg = <0x18000400 0x100>;
+		interrupts = <0 85 4>;
+		clock-frequency = <100000000>;
+	};
+
+	gic: interrupt-controller at 19021000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x19021000 0x1000>,
+		      <0x19020100 0x100>;
+	};
+
+	timer at 19020200 {
+		compatible = "arm,cortex-a9-global-timer";
+		reg = <0x19020200 0x100>;
+		interrupts = <1 11 0xf04>;
+		clocks = <&clk_periph>;
+		#clock-cells = <0>;
+	};
+};
diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S
new file mode 100644
index 0000000..98c836b
--- /dev/null
+++ b/arch/arm/include/debug/bcm53xx.S
@@ -0,0 +1,19 @@
+/*
+ * Macros used for EARLY_PRINTK, in low-level UART debug console
+ *
+ * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#define BCM53XX_UART1_PHYS	0x18000300
+#define BCM53XX_UART1_VIRT	0xf1000300
+#define BCM53XX_UART1_SH	0
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =BCM53XX_UART1_PHYS 	@ MMU off, Physical
+	ldr	\rv, =BCM53XX_UART1_VIRT 	@ MMU on, Virtual
+	.endm
+
+#define UART_SHIFT	BCM53XX_UART1_SH
+#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig
new file mode 100644
index 0000000..1e16e87
--- /dev/null
+++ b/arch/arm/mach-bcm53xx/Kconfig
@@ -0,0 +1,10 @@
+config ARCH_BCM53XX
+	bool "Broadcom BCM47XX / BCM53XX ARM SoC"
+	select CPU_V7
+	select ARM_GIC
+	select HAVE_CLK
+	select GENERIC_CLOCKEVENTS
+	select GENERIC_TIME
+	select ARM_GLOBAL_TIMER
+	help
+	  Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores.
diff --git a/arch/arm/mach-bcm53xx/Makefile b/arch/arm/mach-bcm53xx/Makefile
new file mode 100644
index 0000000..88da84d
--- /dev/null
+++ b/arch/arm/mach-bcm53xx/Makefile
@@ -0,0 +1 @@
+obj-y += bcm53xx.o
diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c
new file mode 100644
index 0000000..aa5bd397
--- /dev/null
+++ b/arch/arm/mach-bcm53xx/bcm53xx.c
@@ -0,0 +1,68 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/irqchip.h>
+#include <linux/clocksource.h>
+#include <linux/clk-provider.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/signal.h>
+
+static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason
+	 * possibly left over from CFE
+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+
+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void bcm53xx_aborts_enable(void)
+{
+	/* Install our hook */
+	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
+			"imprecise external abort");
+}
+
+static void __init bcm53xx_timer_init(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+void __init bcm53xx_map_io(void)
+{
+	debug_ll_io_init();
+	bcm53xx_aborts_enable();
+}
+
+static void __init bcm53xx_dt_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char const *bcm53xx_dt_compat[] = {
+	"brcm,bcm5301x",
+	"netgear,r6250v1",
+	NULL,
+};
+
+DT_MACHINE_START(BCM53XX, "BCM53XX")
+	.init_machine = bcm53xx_dt_init,
+	.map_io = bcm53xx_map_io,
+	.init_irq = irqchip_init,
+	.init_time = bcm53xx_timer_init,
+	.dt_compat = bcm53xx_dt_compat,
+MACHINE_END
-- 
1.7.10.4



From daniel.lezcano at linaro.org  Tue Jul 16 09:52:26 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 16 Jul 2013 15:52:26 +0200
Subject: [PATCH v7] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <1373024773-24574-1-git-send-email-jonas.jensen@gmail.com>
References: <1373018653-18421-1-git-send-email-jonas.jensen@gmail.com>
 <1373024773-24574-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <51E5501A.6070403@linaro.org>

On 07/05/2013 01:46 PM, Jonas Jensen wrote:
> This patch adds an clocksource driver for the main timer(s)
> found on MOXA ART SoCs.
> 
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
> ---
> 
> Notes:
>     Applies to next-20130703
>     
>     Changes since v6:
>     
>     1. remove TIMER_CR read back
>     2. set TIMER_CR from constants
> 

Except for the few comments below, it looks ok for me.

[ ... ]

> + */
> +#define TIMEREG_CR_1_ENABLE	(1 << 0)
> +#define TIMEREG_CR_1_CLOCK	(1 << 1)
> +#define TIMEREG_CR_1_INT	(1 << 2)
> +#define TIMEREG_CR_2_ENABLE	(1 << 3)
> +#define TIMEREG_CR_2_CLOCK	(1 << 4)
> +#define TIMEREG_CR_2_INT	(1 << 5)
> +#define TIMEREG_CR_3_ENABLE	(1 << 6)
> +#define TIMEREG_CR_3_CLOCK	(1 << 7)
> +#define TIMEREG_CR_3_INT	(1 << 8)
> +#define TIMEREG_CR_COUNT_UP	(1 << 9)
> +#define TIMEREG_CR_COUNT_DOWN	(0 << 9)

Could you replace this by the BIT macro ?

[ ... ]

> +
> +	irq = irq_of_parse_and_map(node, 0);
> +	if (irq <= 0)
> +		panic("%s: irq_of_parse_and_map failed\n", node->full_name);
> +
> +	ret = setup_irq(irq, &moxart_timer_irq);
> +	if (ret)
> +		panic("%s: setup_irq failed\n", node->full_name);
> +
> +	clk = of_clk_get(node, 0);
> +	if (IS_ERR(clk))
> +		panic("%s: of_clk_get failed\n", node->full_name);
> +
> +	pclk = clk_get_rate(clk);
> +
> +	if (clocksource_mmio_init(base + TIMER2_BASE + REG_COUNT,
> +				  "moxart_timer", pclk, 200, 32,
> +				  clocksource_mmio_readl_down))
> +		panic("%s: clocksource_mmio_init failed\n", node->full_name);
> +
> +	clock_count_per_tick = DIV_ROUND_CLOSEST(pclk, HZ);
> +
> +	writel(~0, base + TIMER2_BASE + REG_LOAD);
> +	writel(TIMEREG_CR_2_ENABLE, base + TIMER_CR);
> +
> +	moxart_clockevent.cpumask = cpumask_of(0);

	moxart_clockevent.irq = irq;

> +
> +	/*
> +	 * documentation is not publicly available:
> +	 * min_delta / max_delta obtained by trial-and-error,
> +	 * max_delta 0xfffffffe should be ok because count
> +	 * register size is u32
> +	 */
> +	clockevents_config_and_register(&moxart_clockevent, pclk,
> +					0x4, 0xfffffffe);
> +}
> +CLOCKSOURCE_OF_DECLARE(moxart, "moxa,moxart-timer", moxart_timer_init);


Thanks
  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From jonas.jensen at gmail.com  Tue Jul 16 10:04:07 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Tue, 16 Jul 2013 16:04:07 +0200
Subject: [PATCH v3] rtc: Add MOXA ART RTC driver
In-Reply-To: <20130716131332.GL22506@sirena.org.uk>
References: <1373550711-18828-1-git-send-email-jonas.jensen@gmail.com>
 <1373978485-17496-1-git-send-email-jonas.jensen@gmail.com>
 <20130716131332.GL22506@sirena.org.uk>
Message-ID: <CACmBeS3jU2csACZCqXfRvCYAEHaK7S3AcJ++Yd=L-mgfeqg68A@mail.gmail.com>

On 16 July 2013 15:13, Mark Brown <broonie at kernel.org> wrote:
> Since you're now using OF you should also be including a binding
> document.

The binding document already exist in set of patches adding MOXA ART
SoC support ( I intend to mail out v4 once I know how to proceed ):

"[PATCH v3 2/4] ARM: mach-moxart: add MOXA ART device tree files" -
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181757.html

Can it remain as a part of that set?

Or should it be moved here to a new v4 patch?

Changes are available in my public git repository, see
Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt:

http://code.google.com/p/linux-next-20130703-moxart/source/detail?r=55b2a92724f36ecc852208bb1f8e1b7bd7c7904b

Best regards,
Jonas


From ezequiel.garcia at free-electrons.com  Tue Jul 16 10:04:36 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 16 Jul 2013 11:04:36 -0300
Subject: [PATCH 00/10] Orion Watchdog fixes
In-Reply-To: <20130716134422.GE12062@titan.lakedaemon.net>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130716065952.GA25043@lunn.ch> <20130716092059.237ea729@skate>
 <20130716073101.GB25043@lunn.ch> <20130716121432.GA2317@localhost>
 <20130716134422.GE12062@titan.lakedaemon.net>
Message-ID: <20130716140435.GA23904@localhost>

On Tue, Jul 16, 2013 at 09:44:22AM -0400, Jason Cooper wrote:
> On Tue, Jul 16, 2013 at 09:14:33AM -0300, Ezequiel Garcia wrote:
> > On the other side, I'm much interested in knowing if you are OK with
> > breaking the watchdog DT compatibility. If you NACK this, then I'll
> > start preparing a different watchdog driver for 370/XP, since I don't
> > want to extend a driver that is a bit dirty.
> 
> Apparently there is some agreement that the bindings are still in flux
> and that they need to be for a bit longer in order to hammer out
> problems such as this.
> 
> Arnd and Olof both mentioned that something (a doc, and email?) is
> forthcoming about marking some bindings as stable.  Whatever form that
> takes, this one wouldn't get the stable marking yet. ;-)
> 

Yup, that's my understanding as well. But on the other side, I don't
want to break possible users out there.

So, just to check, you say it's early enough to safely do such change?

In that case, I'll extend this patchset to include Armada 370/XP support
and post it as soon as Sebastian's clocksource stuff gets in.

> Oh, and one more nit.  The work 'fix' triggers a whole bunch of "get on
> this right away, does it need to go to stable?  Has anyone confirmed it?
> Which commit caused the regression? etc."  Although I hate the word, I
> think 'refactoring' is much more appropriate description for this series.
> 

Oh, good observation. I wrote the cover letter at 8 PM, after ten long
hours (*) of hacking and smashing this into something easy to review,
and that's the best title I could come up with. I'll change it on v2.

Thanks,

(*) yes, I have another pair of eyes, in case these wear out.
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From andrew at lunn.ch  Tue Jul 16 10:04:15 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 16 Jul 2013 16:04:15 +0200
Subject: [PATCH 05/10] watchdog: orion: Add a memory resource for RSTOUT
 register
In-Reply-To: <1373931163-12670-6-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1373931163-12670-6-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130716140415.GB19448@lunn.ch>

On Mon, Jul 15, 2013 at 08:32:38PM -0300, Ezequiel Garcia wrote:
> Instead of accessing the RSTOUT register directly, this commit
> adds a platform memory resource to map this register into the driver.

Hi Ezequiel

Have you looked at:

arch/arm/mach-mvebu/system-controller.c

It is also using this register. Are we going to have a similar problem
as the TIMER_CTRL register, which you refactered in an earlier patch?

"marvell,orion-system-controller" is not actually used yet, but once
kirkwood moves into mach-mvebu, it will start using it.

Andrew


> 
> Note that by adding a required 2nd-cell for the reg property,
> this change breaks the device-tree binding compatibility.
> 
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> ---
>  arch/arm/mach-kirkwood/include/mach/bridge-regs.h |  1 +
>  arch/arm/mach-orion5x/include/mach/bridge-regs.h  |  1 +
>  arch/arm/plat-orion/common.c                      | 10 ++++++----
>  drivers/watchdog/orion_wdt.c                      | 18 ++++++++++--------
>  4 files changed, 18 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
> index c3f361d..dead75a 100644
> --- a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
> +++ b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
> @@ -21,6 +21,7 @@
>  #define CPU_RESET		0x00000002
>  
>  #define RSTOUTn_MASK		(BRIDGE_VIRT_BASE + 0x0108)
> +#define RSTOUT_PHYS_BASE	(BRIDGE_PHYS_BASE + 0x0108)
>  #define WDT_RESET_OUT_EN	0x00000002
>  #define SOFT_RESET_OUT_EN	0x00000004
>  
> diff --git a/arch/arm/mach-orion5x/include/mach/bridge-regs.h b/arch/arm/mach-orion5x/include/mach/bridge-regs.h
> index aa35de3..ccd91c9 100644
> --- a/arch/arm/mach-orion5x/include/mach/bridge-regs.h
> +++ b/arch/arm/mach-orion5x/include/mach/bridge-regs.h
> @@ -18,6 +18,7 @@
>  #define CPU_CTRL		(ORION5X_BRIDGE_VIRT_BASE + 0x104)
>  
>  #define RSTOUTn_MASK		(ORION5X_BRIDGE_VIRT_BASE + 0x108)
> +#define RSTOUT_PHYS_BASE	(ORION5X_BRIDGE_PHYS_BASE + 0x108)
>  #define WDT_RESET_OUT_EN	0x0002
>  
>  #define CPU_SOFT_RESET		(ORION5X_BRIDGE_VIRT_BASE + 0x10c)
> diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
> index 77fac6c..37924f8 100644
> --- a/arch/arm/plat-orion/common.c
> +++ b/arch/arm/plat-orion/common.c
> @@ -594,14 +594,16 @@ void __init orion_spi_1_init(unsigned long mapbase)
>  /*****************************************************************************
>   * Watchdog
>   ****************************************************************************/
> -static struct resource orion_wdt_resource =
> -		DEFINE_RES_MEM(WDT_PHYS_BASE, 0x04);
> +static struct resource orion_wdt_resource[] = {
> +		DEFINE_RES_MEM(WDT_PHYS_BASE, 0x04),
> +		DEFINE_RES_MEM(RSTOUT_PHYS_BASE, 0x04)
> +};
>  
>  static struct platform_device orion_wdt_device = {
>  	.name		= "orion_wdt",
>  	.id		= -1,
> -	.num_resources	= 1,
> -	.resource	= &orion_wdt_resource,
> +	.num_resources	= ARRAY_SIZE(orion_wdt_resource),
> +	.resource	= orion_wdt_resource,
>  };
>  
>  void __init orion_wdt_init(void)
> diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
> index 01bcf53..3c9b3d2 100644
> --- a/drivers/watchdog/orion_wdt.c
> +++ b/drivers/watchdog/orion_wdt.c
> @@ -43,6 +43,7 @@ static unsigned int wdt_max_duration;	/* (seconds) */
>  static struct clk *clk;
>  static unsigned int wdt_tclk;
>  static void __iomem *wdt_reg;
> +static void __iomem *rstout_reg;
>  static DEFINE_SPINLOCK(wdt_lock);
>  
>  static int orion_wdt_ping(struct watchdog_device *wdt_dev)
> @@ -74,9 +75,7 @@ static int orion_wdt_start(struct watchdog_device *wdt_dev)
>  	orion_timer_ctrl_clrset(0, WDT_EN);
>  
>  	/* Enable reset on watchdog */
> -	reg = readl(RSTOUTn_MASK);
> -	reg |= WDT_RESET_OUT_EN;
> -	writel(reg, RSTOUTn_MASK);
> +	writel(readl(rstout_reg) | WDT_RESET_OUT_EN, rstout_reg);
>  
>  	spin_unlock(&wdt_lock);
>  	return 0;
> @@ -84,14 +83,10 @@ static int orion_wdt_start(struct watchdog_device *wdt_dev)
>  
>  static int orion_wdt_stop(struct watchdog_device *wdt_dev)
>  {
> -	u32 reg;
> -
>  	spin_lock(&wdt_lock);
>  
>  	/* Disable reset on watchdog */
> -	reg = readl(RSTOUTn_MASK);
> -	reg &= ~WDT_RESET_OUT_EN;
> -	writel(reg, RSTOUTn_MASK);
> +	writel(readl(rstout_reg) & ~WDT_RESET_OUT_EN, rstout_reg);
>  
>  	/* Disable watchdog timer */
>  	orion_timer_ctrl_clrset(WDT_EN, 0);
> @@ -158,6 +153,13 @@ static int orion_wdt_probe(struct platform_device *pdev)
>  	if (!wdt_reg)
>  		return -ENOMEM;
>  
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +	if (!res)
> +		return -ENODEV;
> +	rstout_reg = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> +	if (!rstout_reg)
> +		return -ENOMEM;
> +
>  	wdt_max_duration = WDT_MAX_CYCLE_COUNT / wdt_tclk;
>  
>  	orion_wdt.timeout = wdt_max_duration;
> -- 
> 1.8.1.5
> 


From shawn.guo at linaro.org  Tue Jul 16 10:18:35 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 16 Jul 2013 22:18:35 +0800
Subject: [PATCH] ARM: dts: imx: add LVDS panel for imx6qdl-sabresd
Message-ID: <1373984315-28189-1-git-send-email-shawn.guo@linaro.org>

Add HannStar HSD100PXN1 XGA panel support on LVDS1 port of
imx6qdl-sabresd board.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi |   25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 0408472..166b9ae 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -148,6 +148,31 @@
 	};
 };
 
+&ldb {
+	status = "okay";
+
+	lvds-channel at 1 {
+		fsl,data-mapping = "spwg";
+		fsl,data-width = <18>;
+		status = "okay";
+
+		display-timings {
+			native-mode = <&timing0>;
+			timing0: hsd100pxn1 {
+				clock-frequency = <65000000>;
+				hactive = <1024>;
+				vactive = <768>;
+				hback-porch = <220>;
+				hfront-porch = <40>;
+				vback-porch = <21>;
+				vfront-porch = <7>;
+				hsync-len = <60>;
+				vsync-len = <10>;
+			};
+		};
+	};
+};
+
 &ssi2 {
 	fsl,mode = "i2s-slave";
 	status = "okay";
-- 
1.7.9.5




From ezequiel.garcia at free-electrons.com  Tue Jul 16 10:18:51 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 16 Jul 2013 11:18:51 -0300
Subject: [PATCH 05/10] watchdog: orion: Add a memory resource for RSTOUT
 register
In-Reply-To: <20130716140415.GB19448@lunn.ch>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1373931163-12670-6-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130716140415.GB19448@lunn.ch>
Message-ID: <20130716141850.GB23904@localhost>

Andrew,

On Tue, Jul 16, 2013 at 04:04:15PM +0200, Andrew Lunn wrote:
> On Mon, Jul 15, 2013 at 08:32:38PM -0300, Ezequiel Garcia wrote:
> > Instead of accessing the RSTOUT register directly, this commit
> > adds a platform memory resource to map this register into the driver.
> 
> 
> Have you looked at:
> 
> arch/arm/mach-mvebu/system-controller.c
> 

Mmm... I saw the use of the RSTOUT register in kirkwood_restart()
but wasn't sure who should be the real 'owner' of this register.

> It is also using this register. Are we going to have a similar problem
> as the TIMER_CTRL register, which you refactered in an earlier patch?
> 

Probably.

> "marvell,orion-system-controller" is not actually used yet, but once
> kirkwood moves into mach-mvebu, it will start using it.
> 

I guess so. We should take that into account *now*. Let me think about
it and see if I can have something sane for v2.

Thanks!
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From sergei.shtylyov at cogentembedded.com  Tue Jul 16 10:22:08 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 16 Jul 2013 18:22:08 +0400
Subject: [PATCH v4 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <1373974500-23609-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1373974500-23609-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <51E55710.8060907@cogentembedded.com>

Hello.

On 07/16/2013 03:34 PM, Oleksandr Kozaruk wrote:

> GPADC is the general purpose ADC present on twl6030.
> The dt data is interrupt used to trigger end of ADC
> conversion.

> Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
> ---
>   arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
>   1 file changed, 6 insertions(+)

> diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
> index 2e3bd31..434842c 100644
> --- a/arch/arm/boot/dts/twl6030.dtsi
> +++ b/arch/arm/boot/dts/twl6030.dtsi
> @@ -103,4 +103,10 @@
>   		compatible = "ti,twl6030-pwmled";
>   		#pwm-cells = <2>;
>   	};
> +
> +	gpadc: twl6030_gpadc {
> +		compatible = "ti,twl6030_gpadc";
> +		interrupts = <3>;
> +		#io-channel-cells = <1>;
> +	};

    ePAPR [1] says: "The name of a node should be somewhat generic, 
reflecting the function of the device and not its precise programming 
model."

[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei



From nm at ti.com  Tue Jul 16 10:23:52 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 16 Jul 2013 09:23:52 -0500
Subject: [PATCH 0/2] regulator: palmas-pmic: doc: update device tree bindings
Message-ID: <1373984635-14958-1-git-send-email-nm@ti.com>

We seem to have a few missing updates to device tree bindings with the
latest set of changes getting merged in.

Based on v3.11-rc1 tag

Nishanth Menon (2):
  regulator: palmas-pmic: doc: fix typo for sleep-mode
  regulator: palmas-pmic: doc: remove ti,tstep

 .../devicetree/bindings/regulator/palmas-pmic.txt  |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

-- 
1.7.9.5

Regards,
Nishanth Menon


From nm at ti.com  Tue Jul 16 10:23:53 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 16 Jul 2013 09:23:53 -0500
Subject: [PATCH 1/2] regulator: palmas-pmic: doc: fix typo for sleep-mode
In-Reply-To: <1373984635-14958-1-git-send-email-nm@ti.com>
References: <1373984635-14958-1-git-send-email-nm@ti.com>
Message-ID: <1373984635-14958-2-git-send-email-nm@ti.com>

commit 3c870e3f9d9d98f1ab98614b3b1fd5c79287d361
(regulator: palmas: Change the DT node property names to follow the convention)

Missed updating mode-sleep from sleep-mode. Fix the same.
Documentation seems proper for this property.

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../devicetree/bindings/regulator/palmas-pmic.txt  |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index d5a3086..04d67f0 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -31,7 +31,7 @@ Optional nodes:
 	       Optional sub-node properties:
 	       ti,warm-reset - maintain voltage during warm reset(boolean)
 	       ti,roof-floor - control voltage selection by pin(boolean)
-	       ti,sleep-mode - mode to adopt in pmic sleep 0 - off, 1 - auto,
+	       ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
 	       2 - eco, 3 - forced pwm
 	       ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 2.5mV/us
 	       ti,smps-range - OTP has the wrong range set for the hardware so override
-- 
1.7.9.5



From nm at ti.com  Tue Jul 16 10:23:54 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 16 Jul 2013 09:23:54 -0500
Subject: [PATCH 2/2] regulator: palmas-pmic: doc: remove ti,tstep
In-Reply-To: <1373984635-14958-1-git-send-email-nm@ti.com>
References: <1373984635-14958-1-git-send-email-nm@ti.com>
Message-ID: <1373984635-14958-3-git-send-email-nm@ti.com>

commit 28d1e8cd671a53d6b4f967abbbc2a55f7bd333f6
(regulator: palma: add ramp delay support through regulator constraints)

Removed the regulator's ti,step option from driver without updating the
documentation. remove the support from documentation and example as well.

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../devicetree/bindings/regulator/palmas-pmic.txt  |    2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index 04d67f0..30b0581 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -33,7 +33,6 @@ Optional nodes:
 	       ti,roof-floor - control voltage selection by pin(boolean)
 	       ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
 	       2 - eco, 3 - forced pwm
-	       ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 2.5mV/us
 	       ti,smps-range - OTP has the wrong range set for the hardware so override
 	       0 - low range, 1 - high range.
 
@@ -59,7 +58,6 @@ pmic {
 			ti,warm-reset;
 			ti,roof-floor;
 			ti,mode-sleep = <0>;
-			ti,tstep = <0>;
 			ti,smps-range = <1>;
 		};
 
-- 
1.7.9.5



From grygorii.strashko at ti.com  Tue Jul 16 10:25:21 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Tue, 16 Jul 2013 17:25:21 +0300
Subject: [PATCH 1/4] pinctrl: Remove duplicate code in
 pinctrl_pm_select_state functions
In-Reply-To: <20130716134118.GC7656@atomide.com>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090529.5541.54331.stgit@localhost> <51E5475B.1050900@ti.com>
 <20130716134118.GC7656@atomide.com>
Message-ID: <51E557D1.4000707@ti.com>

Hi Tony,

On 07/16/2013 04:41 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko at ti.com> [130716 06:22]:
>> Hi Tony,
>>
>> This patch causes boot failure when I've applied my patch
>> "[RFC] ARM: OMAP2+: omap_device: add pinctrl handling"
>> https://lkml.org/lkml/2013/6/21/309
>>
>> on top of it:
>
> Hmm this patch alone removes duplicate code and if it causes
> issues I must have made a typo somewhere.

No typo :) You've removed the check for !dev-pins.
And the failure place is:
int pinctrl_pm_select_active_state(struct device *dev)
{
    return pinctrl_pm_select_state(dev, dev->pins->active_state);
                                                 ^^^^ here
}

If I understand everything right, the pinctrl support in Device core
assumed to be optional - so, It's valid case, when there are no
definition for device's pinctrl in DT at all.

And in this case dev->pins == NULL and  pinctrl_pm_select_*() API
should return 0 always.

>
> I cannot see a typo though, but in your dmesg I see something..
>
>> [    0.610565] PC is at pinctrl_pm_select_active_state+0x4/0xc
Yep. This will happen if there are no pinctrl states defined in DT
- currently it's crashed when GPIO driver probed.
>
> ..looks like you have something applied for the active_state
> that only gets introduced later on in this series.
>
> Maybe you have the earlier version of drivers/base/pinctrl.c
> active_state patch that was in linux next for a while but
> got reverted as we noticed we had to rework some things?
>
> So maybe try with v3.11-rc1 + these four patches + your
> omap_device patch?
I'm on v3.11-rc1

>
> Regards,
>
> Tony
>



From nm at ti.com  Tue Jul 16 10:27:10 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 16 Jul 2013 09:27:10 -0500
Subject: [PATCH 0/2] regulator: palmas-pmic: doc: update device tree
 bindings
In-Reply-To: <1373984635-14958-1-git-send-email-nm@ti.com>
References: <1373984635-14958-1-git-send-email-nm@ti.com>
Message-ID: <20130716142710.GA15015@kahuna>

On 09:23-20130716, Nishanth Menon wrote:
> We seem to have a few missing updates to device tree bindings with the
> latest set of changes getting merged in.

Oops.. seems like I have an old mailID for Mark :(

> 
> Based on v3.11-rc1 tag
> 
> Nishanth Menon (2):
>   regulator: palmas-pmic: doc: fix typo for sleep-mode
>   regulator: palmas-pmic: doc: remove ti,tstep
> 
>  .../devicetree/bindings/regulator/palmas-pmic.txt  |    4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> -- 
> 1.7.9.5
> 
> Regards,
> Nishanth Menon

-- 
Regards,
Nishanth Menon


From jason at lakedaemon.net  Tue Jul 16 10:29:30 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 16 Jul 2013 10:29:30 -0400
Subject: [PATCH 00/10] Orion Watchdog fixes
In-Reply-To: <20130716140435.GA23904@localhost>
References: <1373931163-12670-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130716065952.GA25043@lunn.ch> <20130716092059.237ea729@skate>
 <20130716073101.GB25043@lunn.ch> <20130716121432.GA2317@localhost>
 <20130716134422.GE12062@titan.lakedaemon.net>
 <20130716140435.GA23904@localhost>
Message-ID: <20130716142930.GF12062@titan.lakedaemon.net>

On Tue, Jul 16, 2013 at 11:04:36AM -0300, Ezequiel Garcia wrote:
> On Tue, Jul 16, 2013 at 09:44:22AM -0400, Jason Cooper wrote:
> > On Tue, Jul 16, 2013 at 09:14:33AM -0300, Ezequiel Garcia wrote:
> > > On the other side, I'm much interested in knowing if you are OK with
> > > breaking the watchdog DT compatibility. If you NACK this, then I'll
> > > start preparing a different watchdog driver for 370/XP, since I don't
> > > want to extend a driver that is a bit dirty.
> > 
> > Apparently there is some agreement that the bindings are still in flux
> > and that they need to be for a bit longer in order to hammer out
> > problems such as this.
> > 
> > Arnd and Olof both mentioned that something (a doc, and email?) is
> > forthcoming about marking some bindings as stable.  Whatever form that
> > takes, this one wouldn't get the stable marking yet. ;-)
> > 
> 
> Yup, that's my understanding as well. But on the other side, I don't
> want to break possible users out there.

I agree, but living with a sub-standard binding is worse imho.

> So, just to check, you say it's early enough to safely do such change?

Well, it's not *safe*.  But most consumers on mainline kernels are
currently developer/hackers/distro maintainers.  eg, folks who can
handle it.  It's better to do it now.

> In that case, I'll extend this patchset to include Armada 370/XP support
> and post it as soon as Sebastian's clocksource stuff gets in.

Cool.

thx,

Jason.


From p.zabel at pengutronix.de  Tue Jul 16 10:33:22 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 16 Jul 2013 16:33:22 +0200
Subject: [PATCH v9] reset: Add driver for gpio-controlled reset pins
Message-ID: <1373985202-16353-1-git-send-email-p.zabel@pengutronix.de>

This driver implements a reset controller device that toggle a gpio
connected to a reset pin of a peripheral IC. The delay between assertion
and de-assertion of the reset signal can be configured via device tree.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
Reviewed-by: Stephen Warren <swarren at nvidia.com>
---
Changes since v8, as suggested by Shawn:
 - added support for I2C gpios via gpio_set_value_cansleep
 - switched from module_init to arch_initcall to avoid unnecessary
   probe deferral of subsys_initcall drivers like gpio-pca953x.
---
 .../devicetree/bindings/reset/gpio-reset.txt       |  35 ++++
 drivers/reset/Kconfig                              |  11 ++
 drivers/reset/Makefile                             |   1 +
 drivers/reset/gpio-reset.c                         | 188 +++++++++++++++++++++
 4 files changed, 235 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/gpio-reset.txt
 create mode 100644 drivers/reset/gpio-reset.c

diff --git a/Documentation/devicetree/bindings/reset/gpio-reset.txt b/Documentation/devicetree/bindings/reset/gpio-reset.txt
new file mode 100644
index 0000000..bca5348
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/gpio-reset.txt
@@ -0,0 +1,35 @@
+GPIO reset controller
+=====================
+
+A GPIO reset controller controls a single GPIO that is connected to the reset
+pin of a peripheral IC. Please also refer to reset.txt in this directory for
+common reset controller binding usage.
+
+Required properties:
+- compatible: Should be "gpio-reset"
+- reset-gpios: A gpio used as reset line. The gpio specifier for this property
+               depends on the gpio controller that provides the gpio.
+- #reset-cells: 0, see below
+
+Optional properties:
+- reset-delay-us: delay in microseconds. The gpio reset line will be asserted for
+                  this duration to reset.
+- initially-in-reset: boolean. If not set, the initial state should be a
+                      deasserted reset line. If this property exists, the
+                      reset line should be kept in reset.
+
+example:
+
+sii902x_reset: gpio-reset {
+	compatible = "gpio-reset";
+	reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+	reset-delay-us = <10000>;
+	initially-in-reset;
+	#reset-cells = <0>;
+};
+
+/* Device with nRESET pin connected to GPIO5_0 */
+sii902x at 39 {
+	/* ... */
+	resets = <&sii902x_reset>; /* active-low GPIO5_0, 10 ms delay */
+};
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index c9d04f7..1a862df 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -11,3 +11,14 @@ menuconfig RESET_CONTROLLER
 	  via GPIOs or SoC-internal reset controller modules.
 
 	  If unsure, say no.
+
+if RESET_CONTROLLER
+
+config RESET_GPIO
+	tristate "GPIO reset controller support"
+	depends on GPIOLIB && OF
+	help
+	  This driver provides support for reset lines that are controlled
+	  directly by GPIOs.
+
+endif
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 1e2d83f..b854f20 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_RESET_CONTROLLER) += core.o
+obj-$(CONFIG_RESET_GPIO) += gpio-reset.o
diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
new file mode 100644
index 0000000..e9c15c0
--- /dev/null
+++ b/drivers/reset/gpio-reset.c
@@ -0,0 +1,188 @@
+/*
+ * GPIO Reset Controller driver
+ *
+ * Copyright 2013 Philipp Zabel, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+
+struct gpio_reset_data {
+	struct reset_controller_dev rcdev;
+	unsigned int gpio;
+	bool active_low;
+	s32 delay_us;
+};
+
+static void gpio_reset_set(struct reset_controller_dev *rcdev, int asserted)
+{
+	struct gpio_reset_data *drvdata = container_of(rcdev,
+			struct gpio_reset_data, rcdev);
+	int value = asserted;
+
+	if (drvdata->active_low)
+		value = !value;
+
+	gpio_set_value(drvdata->gpio, value);
+	if (gpio_cansleep(drvdata->gpio))
+		gpio_set_value_cansleep(drvdata->gpio, value);
+	else
+		gpio_set_value(drvdata->gpio, value);
+}
+
+static int gpio_reset(struct reset_controller_dev *rcdev, unsigned long id)
+{
+	struct gpio_reset_data *drvdata = container_of(rcdev,
+			struct gpio_reset_data, rcdev);
+
+	if (drvdata->delay_us < 0)
+		return -ENOSYS;
+
+	gpio_reset_set(rcdev, 1);
+	udelay(drvdata->delay_us);
+	gpio_reset_set(rcdev, 0);
+
+	return 0;
+}
+
+static int gpio_reset_assert(struct reset_controller_dev *rcdev,
+		unsigned long id)
+{
+	gpio_reset_set(rcdev, 1);
+
+	return 0;
+}
+
+static int gpio_reset_deassert(struct reset_controller_dev *rcdev,
+		unsigned long id)
+{
+	gpio_reset_set(rcdev, 0);
+
+	return 0;
+}
+
+static struct reset_control_ops gpio_reset_ops = {
+	.reset = gpio_reset,
+	.assert = gpio_reset_assert,
+	.deassert = gpio_reset_deassert,
+};
+
+static int of_gpio_reset_xlate(struct reset_controller_dev *rcdev,
+			       const struct of_phandle_args *reset_spec)
+{
+	if (WARN_ON(reset_spec->args_count != 0))
+		return -EINVAL;
+
+	return 0;
+}
+
+static int gpio_reset_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct gpio_reset_data *drvdata;
+	enum of_gpio_flags flags;
+	unsigned long gpio_flags;
+	bool initially_in_reset;
+	int ret;
+
+	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (drvdata == NULL)
+		return -ENOMEM;
+
+	if (of_gpio_named_count(np, "reset-gpios") != 1) {
+		dev_err(&pdev->dev,
+			"reset-gpios property missing, or not a single gpio\n");
+		return -EINVAL;
+	}
+
+	drvdata->gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
+	if (drvdata->gpio == -EPROBE_DEFER) {
+		return drvdata->gpio;
+	} else if (!gpio_is_valid(drvdata->gpio)) {
+		dev_err(&pdev->dev, "invalid reset gpio: %d\n", drvdata->gpio);
+		return drvdata->gpio;
+	}
+
+	drvdata->active_low = flags & OF_GPIO_ACTIVE_LOW;
+
+	ret = of_property_read_u32(np, "reset-delay-us", &drvdata->delay_us);
+	if (ret < 0)
+		drvdata->delay_us = -1;
+	else if (drvdata->delay_us < 0)
+		dev_warn(&pdev->dev, "reset delay too high\n");
+
+	initially_in_reset = of_property_read_bool(np, "initially-in-reset");
+	if (drvdata->active_low ^ initially_in_reset)
+		gpio_flags = GPIOF_OUT_INIT_HIGH;
+	else
+		gpio_flags = GPIOF_OUT_INIT_LOW;
+
+	ret = devm_gpio_request_one(&pdev->dev, drvdata->gpio, gpio_flags, NULL);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to request gpio %d: %d\n",
+			drvdata->gpio, ret);
+		return ret;
+	}
+
+	platform_set_drvdata(pdev, drvdata);
+
+	drvdata->rcdev.of_node = np;
+	drvdata->rcdev.owner = THIS_MODULE;
+	drvdata->rcdev.nr_resets = 1;
+	drvdata->rcdev.ops = &gpio_reset_ops;
+	drvdata->rcdev.of_xlate = of_gpio_reset_xlate;
+	reset_controller_register(&drvdata->rcdev);
+
+	return 0;
+}
+
+static int gpio_reset_remove(struct platform_device *pdev)
+{
+	struct gpio_reset_data *drvdata = platform_get_drvdata(pdev);
+
+	reset_controller_unregister(&drvdata->rcdev);
+
+	return 0;
+}
+
+static struct of_device_id gpio_reset_dt_ids[] = {
+	{ .compatible = "gpio-reset" },
+	{ }
+};
+
+static struct platform_driver gpio_reset_driver = {
+	.probe = gpio_reset_probe,
+	.remove = gpio_reset_remove,
+	.driver = {
+		.name = "gpio-reset",
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(gpio_reset_dt_ids),
+	},
+};
+
+static int __init gpio_reset_init(void)
+{
+	return platform_driver_register(&gpio_reset_driver);
+}
+arch_initcall(gpio_reset_init);
+
+static void __exit gpio_reset_exit(void)
+{
+	platform_driver_unregister(&gpio_reset_driver);
+}
+module_exit(gpio_reset_exit);
+
+MODULE_AUTHOR("Philipp Zabel <p.zabel at pengutronix.de>");
+MODULE_DESCRIPTION("gpio reset controller");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:gpio-reset");
+MODULE_DEVICE_TABLE(of, gpio_reset_dt_ids);
-- 
1.8.3.2



From rogerq at ti.com  Tue Jul 16 10:37:34 2013
From: rogerq at ti.com (Roger Quadros)
Date: Tue, 16 Jul 2013 17:37:34 +0300
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51E3B1B1.3060202@denx.de>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de> <51DE87D3.5030600@ti.com>
 <51DEA7F1.1050902@denx.de> <51DEC2CE.70400@ti.com> <51DED076.3040000@denx.de>
 <51DEF0DE.4050607@denx.de> <51DFC92F.1050701@ti.com>
 <51DFDFD4.3040900@denx.de> <51E3AFF4.7060607@ti.com>
 <51E3B1B1.3060202@denx.de>
Message-ID: <51E55AAE.3000209@ti.com>

+Alan

On 07/15/2013 11:24 AM, Stefan Roese wrote:
> On 07/15/2013 10:16 AM, Roger Quadros wrote:
>>>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>>>> as I don't have an external USB-ethernet adapter.
>>>
>>> Too bad. This difference in boards makes the tests a bit less
>>> meaningful. Is there really no USB-ethernet adapter somewhere in your
>>> department (perhaps a non-SMSC95xx might serve as well?)? I might
>>> send/order you one if necessary. ;)
>>
>> Thanks for the offer :). I'll just get one for myself by today/tomorrow.
>> The one available here uses this driver "drivers/net/usb/asix.c"
> 
> Great.
> 

OK. Finally managed to reproduce the problem.

Don't know the root cause yet. Will need to investigate.

[   92.054138] ------------[ cut here ]------------
[   92.059082] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x278/0x29c()
[   92.066741] NETDEV WATCHDOG: eth0 (asix): transmit queue 0 timed out
[   92.073425] Modules linked in:
[   92.076721] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-06007-g83bebb4 #837
[   92.084594] [<c001b868>] (unwind_backtrace+0x0/0xf0) from [<c0017bbc>] (show_stack+0x10/0x14)
[   92.093597] [<c0017bbc>] (show_stack+0x10/0x14) from [<c04f7658>] (dump_stack+0x78/0x94)
[   92.102172] [<c04f7658>] (dump_stack+0x78/0x94) from [<c00440b8>] (warn_slowpath_common+0x4c/0x6c)
[   92.111694] [<c00440b8>] (warn_slowpath_common+0x4c/0x6c) from [<c004416c>] (warn_slowpath_fmt+0x30/0x40)
[   92.121826] [<c004416c>] (warn_slowpath_fmt+0x30/0x40) from [<c045aa28>] (dev_watchdog+0x278/0x29c)
[   92.131439] [<c045aa28>] (dev_watchdog+0x278/0x29c) from [<c0052d0c>] (call_timer_fn+0x80/0x168)
[   92.140747] [<c0052d0c>] (call_timer_fn+0x80/0x168) from [<c0052f98>] (run_timer_softirq+0x1a4/0x290)
[   92.150512] [<c0052f98>] (run_timer_softirq+0x1a4/0x290) from [<c004bddc>] (__do_softirq+0x100/0x27c)
[   92.160308] [<c004bddc>] (__do_softirq+0x100/0x27c) from [<c004c2fc>] (irq_exit+0xa0/0xdc)
[   92.169067] [<c004c2fc>] (irq_exit+0xa0/0xdc) from [<c0014ccc>] (handle_IRQ+0x50/0xb0)
[   92.177490] [<c0014ccc>] (handle_IRQ+0x50/0xb0) from [<c000862c>] (omap3_intc_handle_irq+0x60/0x74)
[   92.187072] [<c000862c>] (omap3_intc_handle_irq+0x60/0x74) from [<c04fd5a4>] (__irq_svc+0x44/0x5c)
[   92.196563] Exception stack(0xc0775f58 to 0xc0775fa0)
[   92.201873] 5f40:                                                       00000001 00000001
[   92.210540] 5f60: 00000000 c077fd08 c0774000 00000000 c080acc0 c080a5ee c080acc0 c0509860
[   92.219207] 5f80: c077c9a8 c0774000 ce0ce578 c0775fa0 c0097b18 c0015034 200f0013 ffffffff
[   92.227874] [<c04fd5a4>] (__irq_svc+0x44/0x5c) from [<c0015034>] (arch_cpu_idle+0x20/0x3c)
[   92.236663] [<c0015034>] (arch_cpu_idle+0x20/0x3c) from [<c0086268>] (cpu_startup_entry+0x80/0x21c)
[   92.246276] [<c0086268>] (cpu_startup_entry+0x80/0x21c) from [<c0714820>] (start_kernel+0x2c4/0x320)
[   92.255950] ---[ end trace 29c2af54cf6c8fa8 ]---
[   92.272674] ehci-omap 48064800.ehci: IAA watchdog: status e008 cmd 10075
[   92.291137] ehci-omap 48064800.ehci: IAA watchdog: status e008 cmd 10075

cheers,
-roger


From jonas.jensen at gmail.com  Tue Jul 16 10:44:40 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Tue, 16 Jul 2013 16:44:40 +0200
Subject: [PATCH v8] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <1373024773-24574-1-git-send-email-jonas.jensen@gmail.com>
References: <1373024773-24574-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1373985880-23469-1-git-send-email-jonas.jensen@gmail.com>

This patch adds an clocksource driver for the main timer(s)
found on MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v7:
    
    1. use BIT macro
    2. set moxart_clockevent.irq
    
    Applies to next-20130716

 drivers/clocksource/Makefile       |   1 +
 drivers/clocksource/moxart_timer.c | 164 +++++++++++++++++++++++++++++++++++++
 2 files changed, 165 insertions(+)
 create mode 100644 drivers/clocksource/moxart_timer.c

diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 8b00c5c..704d6d3 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
 obj-$(CONFIG_ORION_TIMER)	+= time-orion.o
 obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
 obj-$(CONFIG_ARCH_MARCO)	+= timer-marco.o
+obj-$(CONFIG_ARCH_MOXART)	+= moxart_timer.o
 obj-$(CONFIG_ARCH_MXS)		+= mxs_timer.o
 obj-$(CONFIG_ARCH_PRIMA2)	+= timer-prima2.o
 obj-$(CONFIG_SUN4I_TIMER)	+= sun4i_timer.o
diff --git a/drivers/clocksource/moxart_timer.c b/drivers/clocksource/moxart_timer.c
new file mode 100644
index 0000000..08a5943
--- /dev/null
+++ b/drivers/clocksource/moxart_timer.c
@@ -0,0 +1,164 @@
+/*
+ * MOXA ART SoCs timer handling.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqreturn.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/io.h>
+#include <linux/clocksource.h>
+
+#define TIMER1_BASE		0x00
+#define TIMER2_BASE		0x10
+#define TIMER3_BASE		0x20
+
+#define REG_COUNT		0x0 /* writable */
+#define REG_LOAD		0x4
+#define REG_MATCH1		0x8
+#define REG_MATCH2		0xC
+
+#define TIMER_CR		0x30
+#define TIMER_INTR_STATE	0x34
+#define TIMER_INTR_MASK		0x38
+
+/*
+ * TIMER_CR flags:
+ *
+ * TIMEREG_CR_*_CLOCK	0: PCLK, 1: EXT1CLK
+ * TIMEREG_CR_*_INT	overflow interrupt enable bit
+ */
+#define TIMEREG_CR_1_ENABLE	BIT(0)
+#define TIMEREG_CR_1_CLOCK	BIT(1)
+#define TIMEREG_CR_1_INT	BIT(2)
+#define TIMEREG_CR_2_ENABLE	BIT(3)
+#define TIMEREG_CR_2_CLOCK	BIT(4)
+#define TIMEREG_CR_2_INT	BIT(5)
+#define TIMEREG_CR_3_ENABLE	BIT(6)
+#define TIMEREG_CR_3_CLOCK	BIT(7)
+#define TIMEREG_CR_3_INT	BIT(8)
+#define TIMEREG_CR_COUNT_UP	BIT(9)
+
+#define TIMER1_ENABLE		(TIMEREG_CR_2_ENABLE | TIMEREG_CR_1_ENABLE)
+#define TIMER1_DISABLE		(TIMEREG_CR_2_ENABLE)
+
+static void __iomem *base;
+static unsigned int clock_count_per_tick;
+
+static void moxart_clkevt_mode(enum clock_event_mode mode,
+			       struct clock_event_device *clk)
+{
+	switch (mode) {
+	case CLOCK_EVT_MODE_RESUME:
+	case CLOCK_EVT_MODE_ONESHOT:
+		writel(TIMER1_DISABLE, base + TIMER_CR);
+		writel(~0, base + TIMER1_BASE + REG_LOAD);
+		break;
+	case CLOCK_EVT_MODE_PERIODIC:
+		writel(clock_count_per_tick, base + TIMER1_BASE + REG_LOAD);
+		writel(TIMER1_ENABLE, base + TIMER_CR);
+		break;
+	case CLOCK_EVT_MODE_UNUSED:
+	case CLOCK_EVT_MODE_SHUTDOWN:
+	default:
+		writel(TIMER1_DISABLE, base + TIMER_CR);
+		break;
+	}
+}
+
+static int moxart_clkevt_next_event(unsigned long cycles,
+				    struct clock_event_device *unused)
+{
+	u32 u;
+
+	writel(TIMER1_DISABLE, base + TIMER_CR);
+
+	u = readl(base + TIMER1_BASE + REG_COUNT) - cycles;
+	writel(u, base + TIMER1_BASE + REG_MATCH1);
+
+	writel(TIMER1_ENABLE, base + TIMER_CR);
+
+	return 0;
+}
+
+static struct clock_event_device moxart_clockevent = {
+	.name		= "moxart_timer",
+	.rating		= 200,
+	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
+	.set_mode	= moxart_clkevt_mode,
+	.set_next_event	= moxart_clkevt_next_event,
+};
+
+static irqreturn_t moxart_timer_interrupt(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+	evt->event_handler(evt);
+	return IRQ_HANDLED;
+}
+
+static struct irqaction moxart_timer_irq = {
+	.name		= "moxart-timer",
+	.flags		= IRQF_TIMER,
+	.handler	= moxart_timer_interrupt,
+	.dev_id		= &moxart_clockevent,
+};
+
+static void __init moxart_timer_init(struct device_node *node)
+{
+	int ret, irq;
+	unsigned long pclk;
+	struct clk *clk;
+
+	base = of_iomap(node, 0);
+	if (!base)
+		panic("%s: of_iomap failed\n", node->full_name);
+
+	irq = irq_of_parse_and_map(node, 0);
+	if (irq <= 0)
+		panic("%s: irq_of_parse_and_map failed\n", node->full_name);
+
+	ret = setup_irq(irq, &moxart_timer_irq);
+	if (ret)
+		panic("%s: setup_irq failed\n", node->full_name);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk))
+		panic("%s: of_clk_get failed\n", node->full_name);
+
+	pclk = clk_get_rate(clk);
+
+	if (clocksource_mmio_init(base + TIMER2_BASE + REG_COUNT,
+				  "moxart_timer", pclk, 200, 32,
+				  clocksource_mmio_readl_down))
+		panic("%s: clocksource_mmio_init failed\n", node->full_name);
+
+	clock_count_per_tick = DIV_ROUND_CLOSEST(pclk, HZ);
+
+	writel(~0, base + TIMER2_BASE + REG_LOAD);
+	writel(TIMEREG_CR_2_ENABLE, base + TIMER_CR);
+
+	moxart_clockevent.cpumask = cpumask_of(0);
+	moxart_clockevent.irq = irq;
+
+	/*
+	 * documentation is not publicly available:
+	 * min_delta / max_delta obtained by trial-and-error,
+	 * max_delta 0xfffffffe should be ok because count
+	 * register size is u32
+	 */
+	clockevents_config_and_register(&moxart_clockevent, pclk,
+					0x4, 0xfffffffe);
+}
+CLOCKSOURCE_OF_DECLARE(moxart, "moxa,moxart-timer", moxart_timer_init);
-- 
1.8.2.1



From daniel.lezcano at linaro.org  Tue Jul 16 10:47:57 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 16 Jul 2013 16:47:57 +0200
Subject: [PATCHv5 00/10] clocksource: sunxi: Timer fixes and cleanup
In-Reply-To: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373560282-15184-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <51E55D1D.6080809@linaro.org>

On 07/11/2013 06:31 PM, Maxime Ripard wrote:

Applied to my tree for 3.12.

Thanks
  -- Daniel


> Hi everyone,
> 
> The first timer code we merged when adding support for the A13 some
> time back was mostly a clean up from the source drop we had, without
> any documentation.  This happened to work, but the code merged in
> turned out to be far from perfect, and had several flaws.
> 
> This patchset hopefully fixes these flaws, and cleanup most of the
> driver as well, to end up in an almost complete rewrite of it (even
> though it's not that long).
> 
> It also finally adds a clocksource driver using the second timer as
> our monotonic clock source.
> 
> These flaws have all been spotted when trying to add the A31 support,
> work that is still ongoing, but will hopefully benefit from this
> patchset as well.
> 
> Thanks,
> Maxime
> 
> Changes from v4:
>   - Removed the last clk_get_rate() user
>   - Got a few beers
> 
> Changes from v3:
>   - Reintroduce the rate variable to cache the parent clock rate
>   - Remove the interval programming at probe time that was
>     reintroduced in the v3 due to a poor rebase.
> 
> Changes from v2:
>   - Use the clocksource timer to get the amount of time we have to
>     wait for when disabling and enabling back a timer
>   - Added patch to add parenthesis around the macros arguments
>   - Renamed the AUTORELOAD register define to the more meaningful
>     RELOAD name
> 
> Changes from v1:
>   - Rebased on top of linux-next to benefit from the move to all
>     architectures of the sched_clock functions
>   - Moved the clock source to the second timer instead of the 64 bits
>     free-running counter like suggested by Thomas.
> 
> Maxime Ripard (10):
>   clocksource: sun4i: Use the BIT macros where possible
>   clocksource: sun4i: Wrap macros arguments in parenthesis
>   clocksource: sun4i: rename AUTORELOAD define to RELOAD
>   clocksource: sun4i: Add clocksource and sched clock drivers
>   clocksource: sun4i: Don't forget to enable the clock we use
>   clocksource: sun4i: Fix the next event code
>   clocksource: sun4i: Factor out some timer code
>   clocksource: sun4i: Remove TIMER_SCAL variable
>   clocksource: sun4i: Cleanup parent clock setup
>   clocksource: sun4i: Fix bug when switching from periodic to oneshot
>     modes
> 
>  drivers/clocksource/sun4i_timer.c | 110 +++++++++++++++++++++++++++-----------
>  1 file changed, 78 insertions(+), 32 deletions(-)
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From dinguyen at altera.com  Tue Jul 16 10:54:37 2013
From: dinguyen at altera.com (Dinh Nguyen)
Date: Tue, 16 Jul 2013 09:54:37 -0500
Subject: [PATCH] phy: micrel: Add definitions for common Micrel PHY
 registers
In-Reply-To: <51E5046C.60101@atmel.com>
References: <1373929730-28130-1-git-send-email-dinguyen@altera.com>
 <51E5046C.60101@atmel.com>
Message-ID: <1373986477.3164.1.camel@linux-builds1>

On Tue, 2013-07-16 at 10:29 +0200, Nicolas Ferre wrote:
> On 16/07/2013 01:08, dinguyen at altera.com :
> > From: Dinh Nguyen <dinguyen at altera.com>
> >
> > Add defines for common Micrel PHY setups so that other platforms
> > can use them. Update imx61 and sama5 hardware to use the micrel_phy.h
> > PHY defines.
> >
> > Also add support for the KSZ9021RLRN PHY.
> >
> > Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
> > Cc: David S. Miller <davem at davemloft.net>
> > Cc: Shawn Guo <shawn.guo at linaro.org>
> > CC: Andrew Victor <linux at maxim.org.za>
> > CC: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> BTW, which way do you plan to use to merge it upstream?

Thanks Nicolas, I was hoping to have either Shawn or you pick it up?

Dinh
> 
> Thanks a lot, bye,
> 
> > CC: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
> > CC: Pavel Machek <pavel at denx.de>
> > ---
> >   arch/arm/mach-at91/board-dt-sama5.c |   17 ++++++-----------
> >   arch/arm/mach-imx/mach-imx6q.c      |   13 ++++++++-----
> >   include/linux/micrel_phy.h          |    6 ++++++
> >   3 files changed, 20 insertions(+), 16 deletions(-)
> >
> > diff --git a/arch/arm/mach-at91/board-dt-sama5.c b/arch/arm/mach-at91/board-dt-sama5.c
> > index ad95f6a..bf00d15 100644
> > --- a/arch/arm/mach-at91/board-dt-sama5.c
> > +++ b/arch/arm/mach-at91/board-dt-sama5.c
> > @@ -42,20 +42,15 @@ static int ksz9021rn_phy_fixup(struct phy_device *phy)
> >   {
> >   	int value;
> >
> > -#define GMII_RCCPSR	260
> > -#define GMII_RRDPSR	261
> > -#define GMII_ERCR	11
> > -#define GMII_ERDWR	12
> > -
> >   	/* Set delay values */
> > -	value = GMII_RCCPSR | 0x8000;
> > -	phy_write(phy, GMII_ERCR, value);
> > +	value = MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW | 0x8000;
> > +	phy_write(phy, MICREL_KSZ9021_EXTREG_CTRL, value);
> >   	value = 0xF2F4;
> > -	phy_write(phy, GMII_ERDWR, value);
> > -	value = GMII_RRDPSR | 0x8000;
> > -	phy_write(phy, GMII_ERCR, value);
> > +	phy_write(phy, MICREL_KSZ9021_EXTREG_DATA_WRITE, value);
> > +	value = MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW | 0x8000;
> > +	phy_write(phy, MICREL_KSZ9021_EXTREG_CTRL, value);
> >   	value = 0x2222;
> > -	phy_write(phy, GMII_ERDWR, value);
> > +	phy_write(phy, MICREL_KSZ9021_EXTREG_DATA_WRITE, value);
> >
> >   	return 0;
> >   }
> > diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> > index 7be13f8..c8d7814 100644
> > --- a/arch/arm/mach-imx/mach-imx6q.c
> > +++ b/arch/arm/mach-imx/mach-imx6q.c
> > @@ -103,13 +103,16 @@ static int ksz9021rn_phy_fixup(struct phy_device *phydev)
> >   {
> >   	if (IS_BUILTIN(CONFIG_PHYLIB)) {
> >   		/* min rx data delay */
> > -		phy_write(phydev, 0x0b, 0x8105);
> > -		phy_write(phydev, 0x0c, 0x0000);
> > +		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> > +			0x8000 | MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW);
> > +		phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
> >
> >   		/* max rx/tx clock delay, min rx/tx control delay */
> > -		phy_write(phydev, 0x0b, 0x8104);
> > -		phy_write(phydev, 0x0c, 0xf0f0);
> > -		phy_write(phydev, 0x0b, 0x104);
> > +		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> > +			0x8000 | MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW);
> > +		phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0xf0f0);
> > +		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> > +			MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW);
> >   	}
> >
> >   	return 0;
> > diff --git a/include/linux/micrel_phy.h b/include/linux/micrel_phy.h
> > index 8752dbb..ad05ce6 100644
> > --- a/include/linux/micrel_phy.h
> > +++ b/include/linux/micrel_phy.h
> > @@ -17,6 +17,7 @@
> >
> >   #define PHY_ID_KSZ8873MLL	0x000e7237
> >   #define PHY_ID_KSZ9021		0x00221610
> > +#define PHY_ID_KSZ9021RLRN	0x00221611
> >   #define PHY_ID_KS8737		0x00221720
> >   #define PHY_ID_KSZ8021		0x00221555
> >   #define PHY_ID_KSZ8031		0x00221556
> > @@ -35,4 +36,9 @@
> >   /* struct phy_device dev_flags definitions */
> >   #define MICREL_PHY_50MHZ_CLK	0x00000001
> >
> > +#define MICREL_KSZ9021_EXTREG_CTRL	0xB
> > +#define MICREL_KSZ9021_EXTREG_DATA_WRITE	0xC
> > +#define MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW	0x104
> > +#define MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW	0x105
> > +
> >   #endif /* _MICREL_PHY_H */
> >
> 
> 





From daniel.lezcano at linaro.org  Tue Jul 16 11:01:23 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 16 Jul 2013 17:01:23 +0200
Subject: [PATCH v8] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <1373985880-23469-1-git-send-email-jonas.jensen@gmail.com>
References: <1373024773-24574-1-git-send-email-jonas.jensen@gmail.com>
 <1373985880-23469-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <51E56043.1010509@linaro.org>

On 07/16/2013 04:44 PM, Jonas Jensen wrote:
> This patch adds an clocksource driver for the main timer(s)
> found on MOXA ART SoCs.
> 
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
> ---

Ok, I will ask you two more things before taking your patch. I missed
them at the previous review, sorry for asking a new version.

1. could you elaborate the patch log: as it is a new driver, a nice
description of the timer hardware would be valuable for people willing
to understand the code (eg. some specificities of the driver).

2. fix the alignment below

Thanks
  -- Daniel

[ ... ]

> +
> +#define TIMER_CR		0x30
> +#define TIMER_INTR_STATE	0x34
> +#define TIMER_INTR_MASK		0x38


[ ... ]

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From b.brezillon at overkiz.com  Tue Jul 16 11:03:15 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Tue, 16 Jul 2013 17:03:15 +0200
Subject: [PATCH v3 0/7] ARM: at91: prepare transition to common clk framework
Message-ID: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>

Hello,

This patch series prepares the transition to common clk framework by
1) replacing all the clk_enable and clk_disable calls by clk_prepare_unable and
   clk_disable_unprepare to avoid common clock framework warnings.
2) adding explicit configuration of clk (set_rate) within drivers instead of
   default configuration done in arch/arm/mach-at91/clock.c (udc and ohci
   drivers)

If the second part of this patch series (the last 2 patches) does not belong
here, please tell me and I'll move it into the "move to common clk framework"
series.

Best Regards,
Boris

Changes since v2:
 - add configuraton of usb clock in ohci and udc drivers
 - add clk_prepare patch for usba udc driver
 - add clk_prepare patch for spi driver
 - remove already applied udc clk_prepare patch

Changes since v1:
 - remove unneeded clk_unprepare in mci driver
 - remove already applied patches (ehci, ohci, dma and serial)

Changes since common clk patch series:
 - add clk_prepare_enable return check
 - fix a deadlock in atmel-mci (missing spin_unlock)
 - remove already applied patches (atmel-ssc and pwm-atmel-tcb)


Boris BREZILLON (7):
  ARM: at91/tc/clocksource: replace clk_enable/disable with
    clk_prepare_enable/disable_unprepare.
  mmc: atmel-mci: prepare clk before calling enable
  at91/avr32/atmel_lcdfb: prepare clk before calling enable
  USB: gadget: atmel_usba: prepare clk before calling enable
  spi: atmel: prepare clk before calling enable
  USB: ohci-at91: add usb_clk for transition to common clk framework
  usb: gadget: at91_udc: add usb_clk for transition to common clk
    framework

 drivers/clocksource/tcb_clksrc.c    |   10 +++++-----
 drivers/mmc/host/atmel-mci.c        |   27 ++++++++++++++++++---------
 drivers/spi/spi-atmel.c             |   12 +++++++-----
 drivers/usb/gadget/at91_udc.c       |   12 ++++++++++++
 drivers/usb/gadget/at91_udc.h       |    2 +-
 drivers/usb/gadget/atmel_usba_udc.c |   28 +++++++++++++++++++++-------
 drivers/usb/host/ohci-at91.c        |   18 +++++++++++++++---
 drivers/video/atmel_lcdfb.c         |    8 ++++----
 8 files changed, 83 insertions(+), 34 deletions(-)

-- 
1.7.9.5



From b.brezillon at overkiz.com  Tue Jul 16 11:05:14 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Tue, 16 Jul 2013 17:05:14 +0200
Subject: [PATCH v3 1/7] ARM: at91/tc/clocksource: replace clk_enable/disable
 with clk_prepare_enable/disable_unprepare.
In-Reply-To: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
References: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1373987114-24009-1-git-send-email-b.brezillon@overkiz.com>

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/clocksource/tcb_clksrc.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index 8a61872..229c019 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -100,7 +100,7 @@ static void tc_mode(enum clock_event_mode m, struct clock_event_device *d)
 			|| tcd->clkevt.mode == CLOCK_EVT_MODE_ONESHOT) {
 		__raw_writel(0xff, regs + ATMEL_TC_REG(2, IDR));
 		__raw_writel(ATMEL_TC_CLKDIS, regs + ATMEL_TC_REG(2, CCR));
-		clk_disable(tcd->clk);
+		clk_disable_unprepare(tcd->clk);
 	}
 
 	switch (m) {
@@ -109,7 +109,7 @@ static void tc_mode(enum clock_event_mode m, struct clock_event_device *d)
 	 * of oneshot, we get lower overhead and improved accuracy.
 	 */
 	case CLOCK_EVT_MODE_PERIODIC:
-		clk_enable(tcd->clk);
+		clk_prepare_enable(tcd->clk);
 
 		/* slow clock, count up to RC, then irq and restart */
 		__raw_writel(timer_clock
@@ -126,7 +126,7 @@ static void tc_mode(enum clock_event_mode m, struct clock_event_device *d)
 		break;
 
 	case CLOCK_EVT_MODE_ONESHOT:
-		clk_enable(tcd->clk);
+		clk_prepare_enable(tcd->clk);
 
 		/* slow clock, count up to RC, then irq and stop */
 		__raw_writel(timer_clock | ATMEL_TC_CPCSTOP
@@ -275,7 +275,7 @@ static int __init tcb_clksrc_init(void)
 	pdev = tc->pdev;
 
 	t0_clk = tc->clk[0];
-	clk_enable(t0_clk);
+	clk_prepare_enable(t0_clk);
 
 	/* How fast will we be counting?  Pick something over 5 MHz.  */
 	rate = (u32) clk_get_rate(t0_clk);
@@ -313,7 +313,7 @@ static int __init tcb_clksrc_init(void)
 		/* tclib will give us three clocks no matter what the
 		 * underlying platform supports.
 		 */
-		clk_enable(tc->clk[1]);
+		clk_prepare_enable(tc->clk[1]);
 		/* setup both channel 0 & 1 */
 		tcb_setup_dual_chan(tc, best_divisor_idx);
 	}
-- 
1.7.9.5



From b.brezillon at overkiz.com  Tue Jul 16 11:06:48 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Tue, 16 Jul 2013 17:06:48 +0200
Subject: [PATCH v3 2/7] mmc: atmel-mci: prepare clk before calling enable
In-Reply-To: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
References: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1373987208-24120-1-git-send-email-b.brezillon@overkiz.com>

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
Acked-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/mmc/host/atmel-mci.c |   27 ++++++++++++++++++---------
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index bdb84da..4636af6 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -378,6 +378,8 @@ static int atmci_regs_show(struct seq_file *s, void *v)
 {
 	struct atmel_mci	*host = s->private;
 	u32			*buf;
+	int			ret = 0;
+
 
 	buf = kmalloc(ATMCI_REGS_SIZE, GFP_KERNEL);
 	if (!buf)
@@ -389,9 +391,13 @@ static int atmci_regs_show(struct seq_file *s, void *v)
 	 * consistent.
 	 */
 	spin_lock_bh(&host->lock);
-	clk_enable(host->mck);
+	ret = clk_prepare_enable(host->mck);
+	if (ret) {
+		spin_unlock_bh(&host->lock);
+		goto out;
+	}
 	memcpy_fromio(buf, host->regs, ATMCI_REGS_SIZE);
-	clk_disable(host->mck);
+	clk_disable_unprepare(host->mck);
 	spin_unlock_bh(&host->lock);
 
 	seq_printf(s, "MR:\t0x%08x%s%s ",
@@ -442,9 +448,10 @@ static int atmci_regs_show(struct seq_file *s, void *v)
 				val & ATMCI_CFG_LSYNC ? " LSYNC" : "");
 	}
 
+out:
 	kfree(buf);
 
-	return 0;
+	return ret;
 }
 
 static int atmci_regs_open(struct inode *inode, struct file *file)
@@ -1279,7 +1286,7 @@ static void atmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 
 		spin_lock_bh(&host->lock);
 		if (!host->mode_reg) {
-			clk_enable(host->mck);
+			clk_prepare_enable(host->mck);
 			atmci_writel(host, ATMCI_CR, ATMCI_CR_SWRST);
 			atmci_writel(host, ATMCI_CR, ATMCI_CR_MCIEN);
 			if (host->caps.has_cfg_reg)
@@ -1359,7 +1366,7 @@ static void atmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 			atmci_writel(host, ATMCI_CR, ATMCI_CR_MCIDIS);
 			if (host->mode_reg) {
 				atmci_readl(host, ATMCI_MR);
-				clk_disable(host->mck);
+				clk_disable_unprepare(host->mck);
 			}
 			host->mode_reg = 0;
 		}
@@ -2376,10 +2383,12 @@ static int __init atmci_probe(struct platform_device *pdev)
 	if (!host->regs)
 		goto err_ioremap;
 
-	clk_enable(host->mck);
+	ret = clk_prepare_enable(host->mck);
+	if (ret)
+		goto err_request_irq;
 	atmci_writel(host, ATMCI_CR, ATMCI_CR_SWRST);
 	host->bus_hz = clk_get_rate(host->mck);
-	clk_disable(host->mck);
+	clk_disable_unprepare(host->mck);
 
 	host->mapbase = regs->start;
 
@@ -2482,11 +2491,11 @@ static int __exit atmci_remove(struct platform_device *pdev)
 			atmci_cleanup_slot(host->slot[i], i);
 	}
 
-	clk_enable(host->mck);
+	clk_prepare_enable(host->mck);
 	atmci_writel(host, ATMCI_IDR, ~0UL);
 	atmci_writel(host, ATMCI_CR, ATMCI_CR_MCIDIS);
 	atmci_readl(host, ATMCI_SR);
-	clk_disable(host->mck);
+	clk_disable_unprepare(host->mck);
 
 	if (host->dma.chan)
 		dma_release_channel(host->dma.chan);
-- 
1.7.9.5



From b.brezillon at overkiz.com  Tue Jul 16 11:08:14 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Tue, 16 Jul 2013 17:08:14 +0200
Subject: [PATCH v3 3/7] at91/avr32/atmel_lcdfb: prepare clk before calling
 enable
In-Reply-To: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
References: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1373987294-24227-1-git-send-email-b.brezillon@overkiz.com>

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 drivers/video/atmel_lcdfb.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index ece49d5..bf9c5d0 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -954,14 +954,14 @@ static int __init atmel_lcdfb_init_fbinfo(struct atmel_lcdfb_info *sinfo)
 
 static void atmel_lcdfb_start_clock(struct atmel_lcdfb_info *sinfo)
 {
-	clk_enable(sinfo->bus_clk);
-	clk_enable(sinfo->lcdc_clk);
+	clk_prepare_enable(sinfo->bus_clk);
+	clk_prepare_enable(sinfo->lcdc_clk);
 }
 
 static void atmel_lcdfb_stop_clock(struct atmel_lcdfb_info *sinfo)
 {
-	clk_disable(sinfo->bus_clk);
-	clk_disable(sinfo->lcdc_clk);
+	clk_disable_unprepare(sinfo->bus_clk);
+	clk_disable_unprepare(sinfo->lcdc_clk);
 }
 
 #ifdef CONFIG_OF
-- 
1.7.9.5



From b.brezillon at overkiz.com  Tue Jul 16 11:10:26 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Tue, 16 Jul 2013 17:10:26 +0200
Subject: [PATCH v3 4/7] USB: gadget: atmel_usba: prepare clk before calling
 enable
In-Reply-To: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
References: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1373987426-24338-1-git-send-email-b.brezillon@overkiz.com>

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/usb/gadget/atmel_usba_udc.c |   28 +++++++++++++++++++++-------
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/gadget/atmel_usba_udc.c b/drivers/usb/gadget/atmel_usba_udc.c
index 1d97222..f018017 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -1772,6 +1772,7 @@ out:
 static int atmel_usba_start(struct usb_gadget *gadget,
 		struct usb_gadget_driver *driver)
 {
+	int ret = 0;
 	struct usba_udc *udc = container_of(gadget, struct usba_udc, gadget);
 	unsigned long flags;
 
@@ -1781,8 +1782,14 @@ static int atmel_usba_start(struct usb_gadget *gadget,
 	udc->driver = driver;
 	spin_unlock_irqrestore(&udc->lock, flags);
 
-	clk_enable(udc->pclk);
-	clk_enable(udc->hclk);
+	ret = clk_prepare_enable(udc->pclk);
+	if (ret)
+		goto out;
+	ret = clk_prepare_enable(udc->hclk);
+	if (ret) {
+		clk_disable_unprepare(udc->pclk);
+		goto out;
+	}
 
 	DBG(DBG_GADGET, "registered driver `%s'\n", driver->driver.name);
 
@@ -1797,9 +1804,11 @@ static int atmel_usba_start(struct usb_gadget *gadget,
 		usba_writel(udc, CTRL, USBA_ENABLE_MASK);
 		usba_writel(udc, INT_ENB, USBA_END_OF_RESET);
 	}
+
+out:
 	spin_unlock_irqrestore(&udc->lock, flags);
 
-	return 0;
+	return ret;
 }
 
 static int atmel_usba_stop(struct usb_gadget *gadget,
@@ -1822,8 +1831,8 @@ static int atmel_usba_stop(struct usb_gadget *gadget,
 
 	udc->driver = NULL;
 
-	clk_disable(udc->hclk);
-	clk_disable(udc->pclk);
+	clk_disable_unprepare(udc->hclk);
+	clk_disable_unprepare(udc->pclk);
 
 	DBG(DBG_GADGET, "unregistered driver `%s'\n", driver->driver.name);
 
@@ -2022,10 +2031,14 @@ static int __init usba_udc_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, udc);
 
 	/* Make sure we start from a clean slate */
-	clk_enable(pclk);
+	ret = clk_prepare_enable(pclk);
+	if (ret) {
+		dev_err(&pdev->dev, "Unable to enable pclk, aborting.\n");
+		goto err_clk_enable;
+	}
 	toggle_bias(0);
 	usba_writel(udc, CTRL, USBA_DISABLE_MASK);
-	clk_disable(pclk);
+	clk_disable_unprepare(pclk);
 
 	if (pdev->dev.of_node)
 		udc->usba_ep = atmel_udc_of_init(pdev, udc);
@@ -2081,6 +2094,7 @@ err_add_udc:
 	free_irq(irq, udc);
 err_request_irq:
 err_alloc_ep:
+err_clk_enable:
 	iounmap(udc->fifo);
 err_map_fifo:
 	iounmap(udc->regs);
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Jul 16 11:13:24 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Jul 2013 17:13:24 +0200
Subject: [PATCH v3 2/7] mmc: atmel-mci: prepare clk before calling enable
In-Reply-To: <1373987208-24120-1-git-send-email-b.brezillon@overkiz.com>
References: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
 <1373987208-24120-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <20130716171324.7d483ada@skate>

Dear Boris BREZILLON,

On Tue, 16 Jul 2013 17:06:48 +0200, Boris BREZILLON wrote:

>  	buf = kmalloc(ATMCI_REGS_SIZE, GFP_KERNEL);
>  	if (!buf)
> @@ -389,9 +391,13 @@ static int atmci_regs_show(struct seq_file *s, void *v)
>  	 * consistent.
>  	 */
>  	spin_lock_bh(&host->lock);
> -	clk_enable(host->mck);
> +	ret = clk_prepare_enable(host->mck);

I am not very familiar with the spin_lock_bh() variant, but are you
sure we are allowed to sleep within a spin_lock_bh()-protected critical
section?

Remember that clk_prepare_enable() calls both ->prepare() and
->enable() for the clock, and ->prepare() is allowed to sleep, while
->enable() is guaranteed not to sleep.

Therefore, clk_prepare() is usually called at probe time, while
clk_enable() is called whenever enabling/disabling the clock is really
needed. So not all clk_enable() can transparently be converted into a
clk_prepare_enable().

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From b.brezillon at overkiz.com  Tue Jul 16 11:16:22 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Tue, 16 Jul 2013 17:16:22 +0200
Subject: [PATCH v3 5/7] spi: atmel: prepare clk before calling enable
In-Reply-To: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
References: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1373987782-24463-1-git-send-email-b.brezillon@overkiz.com>

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/spi/spi-atmel.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index ea1ec00..4c6c455 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1579,7 +1579,9 @@ static int atmel_spi_probe(struct platform_device *pdev)
 		goto out_unmap_regs;
 
 	/* Initialize the hardware */
-	clk_enable(clk);
+	ret = clk_prepare_enable(clk);
+	if (ret)
+		goto out_unmap_regs;
 	spi_writel(as, CR, SPI_BIT(SWRST));
 	spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
 	if (as->caps.has_wdrbt) {
@@ -1609,7 +1611,7 @@ out_free_dma:
 
 	spi_writel(as, CR, SPI_BIT(SWRST));
 	spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
-	clk_disable(clk);
+	clk_disable_unprepare(clk);
 	free_irq(irq, master);
 out_unmap_regs:
 	iounmap(as->regs);
@@ -1661,7 +1663,7 @@ static int atmel_spi_remove(struct platform_device *pdev)
 	dma_free_coherent(&pdev->dev, BUFFER_SIZE, as->buffer,
 			as->buffer_dma);
 
-	clk_disable(as->clk);
+	clk_disable_unprepare(as->clk);
 	clk_put(as->clk);
 	free_irq(as->irq, master);
 	iounmap(as->regs);
@@ -1678,7 +1680,7 @@ static int atmel_spi_suspend(struct platform_device *pdev, pm_message_t mesg)
 	struct spi_master	*master = platform_get_drvdata(pdev);
 	struct atmel_spi	*as = spi_master_get_devdata(master);
 
-	clk_disable(as->clk);
+	clk_disable_unprepare(as->clk);
 	return 0;
 }
 
@@ -1687,7 +1689,7 @@ static int atmel_spi_resume(struct platform_device *pdev)
 	struct spi_master	*master = platform_get_drvdata(pdev);
 	struct atmel_spi	*as = spi_master_get_devdata(master);
 
-	clk_enable(as->clk);
+	return clk_prepare_enable(as->clk);
 	return 0;
 }
 
-- 
1.7.9.5



From thomas.petazzoni at free-electrons.com  Tue Jul 16 11:20:23 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Jul 2013 17:20:23 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
Message-ID: <20130716172023.64337690@skate>

Dear Hauke Mehrtens,

On Tue, 16 Jul 2013 15:52:07 +0200, Hauke Mehrtens wrote:
> +/include/ "bcm5301x.dtsi"
> +
> +/ {
> +	model = "Netgear R6250 V1 (BCM4708)";
> +	compatible = "netgear,r6250v1", "brcm,bcm5301x";

I don't think using "brcm,bcm5301x" has a compatible string is very
appropriate. It should really reflect which particular SoC this board
is using.

> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
> new file mode 100644
> index 0000000..638350d
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> @@ -0,0 +1,72 @@
> +/*
> + * Broadcom BCM47XX / BCM53XX ARM platform code.
> + *
> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> + *
> + * Licensed under the GNU/GPL. See COPYING for details.
> + */
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	compatible = "brcm,bcm5301x";
> +	model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC";

Same here. Most likely, there will be difference between those SoCs, so
a compatible string of bcm5301x doesn't seem right, and also the model
that says this will handle all those platforms.

> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig
> new file mode 100644
> index 0000000..1e16e87
> --- /dev/null
> +++ b/arch/arm/mach-bcm53xx/Kconfig
> @@ -0,0 +1,10 @@
> +config ARCH_BCM53XX
> +	bool "Broadcom BCM47XX / BCM53XX ARM SoC"

So the directory is named mach-bcm53xx, but you also handle BCM47xx
SoCs. This doesn't sound really easy to follow.

> +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
> +				 struct pt_regs *regs)
> +{
> +	/*
> +	 * These happen for no good reason
> +	 * possibly left over from CFE

CFE ?

> +	 */
> +	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
> +		addr, fsr);
> +
> +	/* Returning non-zero causes fault display and panic */
> +	return 0;
> +}
> +
> +static void bcm53xx_aborts_enable(void)
> +{
> +	/* Install our hook */
> +	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
> +			"imprecise external abort");
> +}
> +
> +static void __init bcm53xx_timer_init(void)
> +{
> +	of_clk_init(NULL);
> +	clocksource_of_init();
> +}
> +
> +void __init bcm53xx_map_io(void)
> +{
> +	debug_ll_io_init();
> +	bcm53xx_aborts_enable();
> +}

That's a nitpick, but I personally tend to like when callbacks are
ordered as they are called, i.e ->map_io() first, and then
->init_time().

> +static void __init bcm53xx_dt_init(void)
> +{
> +	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +}

Not needed, this is the default. When ->init_machine() is NULL, the ARM
core already calls automatically of_platform_populate().

> +
> +static const char const *bcm53xx_dt_compat[] = {
> +	"brcm,bcm5301x",
> +	"netgear,r6250v1",
> +	NULL,

Don't list the boards here, only the SoCs. Otherwise, this place is
going to become a nightmare of conflicts.

> +DT_MACHINE_START(BCM53XX, "BCM53XX")
> +	.init_machine = bcm53xx_dt_init,
> +	.map_io = bcm53xx_map_io,
> +	.init_irq = irqchip_init,
> +	.init_time = bcm53xx_timer_init,
> +	.dt_compat = bcm53xx_dt_compat,
> +MACHINE_END

You also probably want to add this new platform to the
multi_v7_defconfig.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From matt.porter at linaro.org  Tue Jul 16 11:14:36 2013
From: matt.porter at linaro.org (Matt Porter)
Date: Tue, 16 Jul 2013 11:14:36 -0400
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
Message-ID: <20130716151435.GB3871@linaro.org>

Hi Hauke,

On Tue, Jul 16, 2013 at 03:52:07PM +0200, Hauke Mehrtens wrote:
> This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU.
> Currently just booting to a shell is working and nothing else, no
> Ethernet, wifi, flash, ...
> 
> This SoC uses a Dual core CPU, but this is currently not implemented.
> More information about this SoC can be found here:
> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers
> 
> Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
> ---
> 
> A bootlog can be found here:
> http://pastebin.com/0MYYC7Fx
> 
>  MAINTAINERS                                  |    7 +++
>  arch/arm/Kconfig                             |    2 +
>  arch/arm/Kconfig.debug                       |    5 ++
>  arch/arm/Makefile                            |    1 +
>  arch/arm/boot/dts/Makefile                   |    1 +
>  arch/arm/boot/dts/bcm5301x-netgear-r6250.dts |   20 +++++++
>  arch/arm/boot/dts/bcm5301x.dtsi              |   72 ++++++++++++++++++++++++++
>  arch/arm/include/debug/bcm53xx.S             |   19 +++++++
>  arch/arm/mach-bcm53xx/Kconfig                |   10 ++++
>  arch/arm/mach-bcm53xx/Makefile               |    1 +
>  arch/arm/mach-bcm53xx/bcm53xx.c              |   68 ++++++++++++++++++++++++
>  11 files changed, 206 insertions(+)
>  create mode 100644 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
>  create mode 100644 arch/arm/boot/dts/bcm5301x.dtsi
>  create mode 100644 arch/arm/include/debug/bcm53xx.S
>  create mode 100644 arch/arm/mach-bcm53xx/Kconfig
>  create mode 100644 arch/arm/mach-bcm53xx/Makefile
>  create mode 100644 arch/arm/mach-bcm53xx/bcm53xx.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bf61e04..b72ba65 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1795,6 +1795,13 @@ F:	arch/arm/boot/dts/bcm2835*
>  F:	arch/arm/configs/bcm2835_defconfig
>  F:	drivers/*/*bcm2835*
>  
> +BROADCOM BCM53XX ARM ARCHICTURE
> +M:	Hauke Mehrtens <hauke at hauke-m.de>
> +L:	linux-arm-kernel at lists.infradead.org
> +S:	Maintained
> +F:	arch/arm/mach-bcm53xx/
> +F:	arch/arm/boot/dts/bcm53*
> +
>  BROADCOM TG3 GIGABIT ETHERNET DRIVER
>  M:	Nithin Nayak Sujir <nsujir at broadcom.com>
>  M:	Michael Chan <mchan at broadcom.com>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index ba412e0..ee7362e 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -930,6 +930,8 @@ source "arch/arm/mach-bcm/Kconfig"
>  
>  source "arch/arm/mach-bcm2835/Kconfig"
>  
> +source "arch/arm/mach-bcm53xx/Kconfig"
> +
>  source "arch/arm/mach-clps711x/Kconfig"
>  
>  source "arch/arm/mach-cns3xxx/Kconfig"
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index e401a76..74e32f6 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -93,6 +93,10 @@ choice
>  		bool "Kernel low-level debugging on BCM2835 PL011 UART"
>  		depends on ARCH_BCM2835
>  
> +	config DEBUG_BCM53XX
> +		bool "Kernel low-level debugging on BCM53XX UART1"
> +		depends on ARCH_BCM53XX
> +
>  	config DEBUG_CLPS711X_UART1
>  		bool "Kernel low-level debugging messages via UART1"
>  		depends on ARCH_CLPS711X
> @@ -762,6 +766,7 @@ endchoice
>  config DEBUG_LL_INCLUDE
>  	string
>  	default "debug/bcm2835.S" if DEBUG_BCM2835
> +	default "debug/bcm53xx.S" if DEBUG_BCM53XX
>  	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
>  	default "debug/exynos.S" if DEBUG_EXYNOS_UART
>  	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index c0ac0f5..4a69cd5 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
>  machine-$(CONFIG_ARCH_AT91)		+= at91
>  machine-$(CONFIG_ARCH_BCM)		+= bcm
>  machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
> +machine-$(CONFIG_ARCH_BCM53XX)		+= bcm53xx
>  machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
>  machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
>  machine-$(CONFIG_ARCH_DAVINCI)		+= davinci
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 641b3c9..480a68e 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -242,6 +242,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
>  dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
>  	zynq-zc706.dtb \
>  	zynq-zed.dtb
> +dtb-$(CONFIG_ARCH_BCM53XX) += bcm5301x-netgear-r6250.dtb
>  
>  targets += dtbs
>  targets += $(dtb-y)
> diff --git a/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
> new file mode 100644
> index 0000000..d1b97aa
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
> @@ -0,0 +1,20 @@
> +/*
> + * Broadcom BCM47XX / BCM53XX arm platform code.
> + *
> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> + *
> + * Licensed under the GNU/GPL. See COPYING for details.
> + */
> +
> +/dts-v1/;
> +
> +/include/ "bcm5301x.dtsi"
> +
> +/ {
> +	model = "Netgear R6250 V1 (BCM4708)";
> +	compatible = "netgear,r6250v1", "brcm,bcm5301x";
> +
> +	memory {
> +		reg = <0x00000000 0x08000000>;
> +	};
> +};
> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
> new file mode 100644
> index 0000000..638350d
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> @@ -0,0 +1,72 @@
> +/*
> + * Broadcom BCM47XX / BCM53XX ARM platform code.
> + *
> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> + *
> + * Licensed under the GNU/GPL. See COPYING for details.
> + */
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see
the "brcm" vendor prefix as a real consistency problem. I noticed on the
bcm281xx/kona family, we have been using "bcm" which is not logged in
vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
already established use of "brcm" before any of the bcm281xx support
came in. Ideally, the vendor prefix should change to "bcm" since every
reference in the family names is BCM. However, if others want the least
amount of churn in making this consistent, we might have to go with
"brcm" across the board.

Arnd, any thoughts here?

Another thing is that this is missing a binding definition for this
compatible string. See Documentation/devicetree/bindings/arm/bcm2835.txt
for an example. You should split this patch out separately as the DT
maintainers generally want to see bindings as a separate patch for easy
independent review.

Last thing, compatible strings are not to have wildcards in them. See
http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
and note the Warning at the bottom. Also see how bcm2835.txt and
bcm11351.txt use a specific model.

> +	model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC";
> +	interrupt-parent = <&gic>;
> +
> +	chosen {
> +		bootargs = "console=ttyS0,115200 earlyprintk debug";
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a9";
> +			reg = <0>;
> +		};
> +	};
> +
> +	clocks {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		clk_periph: periph {
> +			compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-frequency = <400000000>;
> +		};
> +	};
> +
> +	uart at 18000300 {
> +		compatible = "ns16550";
> +		reg = <0x18000300 0x100>;
> +		interrupts = <0 85 4>;

The DT files should be switched to use the C preprocessor like several
other machines have already done (see bcm11351.dtsi, for example), you
can use the existing GIC includes and have human-redable defines for the
edge/level values here and throughout all interrupt properties.

> +		clock-frequency = <100000000>;
> +	};
> +
> +	uart at 18000400 {
> +		compatible = "ns16550";
> +		reg = <0x18000400 0x100>;
> +		interrupts = <0 85 4>;
> +		clock-frequency = <100000000>;
> +	};
> +
> +	gic: interrupt-controller at 19021000 {
> +		compatible = "arm,cortex-a9-gic";
> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +		interrupt-controller;
> +		reg = <0x19021000 0x1000>,
> +		      <0x19020100 0x100>;
> +	};
> +
> +	timer at 19020200 {
> +		compatible = "arm,cortex-a9-global-timer";
> +		reg = <0x19020200 0x100>;
> +		interrupts = <1 11 0xf04>;
> +		clocks = <&clk_periph>;
> +		#clock-cells = <0>;
> +	};
> +};
> diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S
> new file mode 100644
> index 0000000..98c836b
> --- /dev/null
> +++ b/arch/arm/include/debug/bcm53xx.S
> @@ -0,0 +1,19 @@
> +/*
> + * Macros used for EARLY_PRINTK, in low-level UART debug console
> + *
> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> + *
> + * Licensed under the GNU/GPL. See COPYING for details.
> + */
> +
> +#define BCM53XX_UART1_PHYS	0x18000300
> +#define BCM53XX_UART1_VIRT	0xf1000300
> +#define BCM53XX_UART1_SH	0
> +
> +	.macro	addruart, rp, rv, tmp
> +	ldr	\rp, =BCM53XX_UART1_PHYS 	@ MMU off, Physical
> +	ldr	\rv, =BCM53XX_UART1_VIRT 	@ MMU on, Virtual
> +	.endm
> +
> +#define UART_SHIFT	BCM53XX_UART1_SH
> +#include <asm/hardware/debug-8250.S>
> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig
> new file mode 100644
> index 0000000..1e16e87
> --- /dev/null
> +++ b/arch/arm/mach-bcm53xx/Kconfig
> @@ -0,0 +1,10 @@
> +config ARCH_BCM53XX
> +	bool "Broadcom BCM47XX / BCM53XX ARM SoC"
> +	select CPU_V7
> +	select ARM_GIC
> +	select HAVE_CLK
> +	select GENERIC_CLOCKEVENTS
> +	select GENERIC_TIME
> +	select ARM_GLOBAL_TIMER
> +	help
> +	  Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores.
> diff --git a/arch/arm/mach-bcm53xx/Makefile b/arch/arm/mach-bcm53xx/Makefile
> new file mode 100644
> index 0000000..88da84d
> --- /dev/null
> +++ b/arch/arm/mach-bcm53xx/Makefile
> @@ -0,0 +1 @@
> +obj-y += bcm53xx.o
> diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c
> new file mode 100644
> index 0000000..aa5bd397
> --- /dev/null
> +++ b/arch/arm/mach-bcm53xx/bcm53xx.c
> @@ -0,0 +1,68 @@
> +/*
> + * Broadcom BCM47XX / BCM53XX ARM platform code.
> + *
> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> + *
> + * Licensed under the GNU/GPL. See COPYING for details.
> + */
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/irqchip.h>
> +#include <linux/clocksource.h>
> +#include <linux/clk-provider.h>
> +
> +#include <asm/mach/arch.h>
> +#include <asm/mach/map.h>
> +#include <asm/signal.h>
> +
> +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
> +				 struct pt_regs *regs)
> +{
> +	/*
> +	 * These happen for no good reason
> +	 * possibly left over from CFE
> +	 */
> +	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
> +		addr, fsr);
> +
> +	/* Returning non-zero causes fault display and panic */
> +	return 0;
> +}
> +
> +static void bcm53xx_aborts_enable(void)
> +{
> +	/* Install our hook */
> +	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
> +			"imprecise external abort");
> +}
> +
> +static void __init bcm53xx_timer_init(void)
> +{
> +	of_clk_init(NULL);
> +	clocksource_of_init();
> +}
> +
> +void __init bcm53xx_map_io(void)
> +{
> +	debug_ll_io_init();
> +	bcm53xx_aborts_enable();
> +}
> +
> +static void __init bcm53xx_dt_init(void)
> +{
> +	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +}
> +
> +static const char const *bcm53xx_dt_compat[] = {
> +	"brcm,bcm5301x",
> +	"netgear,r6250v1",
> +	NULL,
> +};
> +
> +DT_MACHINE_START(BCM53XX, "BCM53XX")
> +	.init_machine = bcm53xx_dt_init,
> +	.map_io = bcm53xx_map_io,
> +	.init_irq = irqchip_init,
> +	.init_time = bcm53xx_timer_init,
> +	.dt_compat = bcm53xx_dt_compat,
> +MACHINE_END
> -- 
> 1.7.10.4
> 


From b.brezillon at overkiz.com  Tue Jul 16 11:22:15 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Tue, 16 Jul 2013 17:22:15 +0200
Subject: [PATCH v3 6/7] USB: ohci-at91: add usb_clk for transition to common
 clk framework
In-Reply-To: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
References: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1373988136-24622-1-git-send-email-b.brezillon@overkiz.com>

The AT91 PMC (Power Management Controller) provides an USB clock used by
USB Full Speed host (ohci) and USB Full Speed device (udc).
The usb drivers (ohci and udc) must configure this clock to 48Mhz.
This configuration was formely done in mach-at91/clock.c, but this
implementation will be removed when moving to common clk framework.

This patch add support for usb clock retrieval and configuration, and is
backward compatible with the current at91 clk implementation (if usb clk
is not found, it does not configure/enable the usb clk).

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/usb/host/ohci-at91.c |   18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 9677f68..426c7d2 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -31,8 +31,8 @@
 #define at91_for_each_port(index)	\
 		for ((index) = 0; (index) < AT91_MAX_USBH_PORTS; (index)++)
 
-/* interface and function clocks; sometimes also an AHB clock */
-static struct clk *iclk, *fclk, *hclk;
+/* interface, function and usb clocks; sometimes also an AHB clock */
+static struct clk *iclk, *fclk, *uclk, *hclk;
 static int clocked;
 
 extern int usb_disabled(void);
@@ -41,6 +41,10 @@ extern int usb_disabled(void);
 
 static void at91_start_clock(void)
 {
+	if (uclk) {
+		clk_set_rate(uclk, 48000000);
+		clk_prepare_enable(uclk);
+	}
 	clk_prepare_enable(hclk);
 	clk_prepare_enable(iclk);
 	clk_prepare_enable(fclk);
@@ -52,6 +56,8 @@ static void at91_stop_clock(void)
 	clk_disable_unprepare(fclk);
 	clk_disable_unprepare(iclk);
 	clk_disable_unprepare(hclk);
+	if (uclk)
+		clk_disable_unprepare(uclk);
 	clocked = 0;
 }
 
@@ -144,6 +150,11 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
 		goto err2;
 	}
 
+	uclk = clk_get(&pdev->dev, "usb_clk");
+	if (IS_ERR(uclk)) {
+		uclk = NULL;
+		dev_warn(&pdev->dev, "failed to get usb_clk\n");
+	}
 	iclk = clk_get(&pdev->dev, "ohci_clk");
 	if (IS_ERR(iclk)) {
 		dev_err(&pdev->dev, "failed to get ohci_clk\n");
@@ -212,10 +223,11 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
 	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
 	usb_put_hcd(hcd);
 
+	clk_put(uclk);
 	clk_put(hclk);
 	clk_put(fclk);
 	clk_put(iclk);
-	fclk = iclk = hclk = NULL;
+	fclk = iclk = hclk = uclk = NULL;
 
 	dev_set_drvdata(&pdev->dev, NULL);
 }
-- 
1.7.9.5



From b.brezillon at overkiz.com  Tue Jul 16 11:25:10 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Tue, 16 Jul 2013 17:25:10 +0200
Subject: [PATCH v3 7/7] usb: gadget: at91_udc: add usb_clk for transition to
 common clk framework
In-Reply-To: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
References: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1373988310-24734-1-git-send-email-b.brezillon@overkiz.com>

The AT91 PMC (Power Management Controller) provides an USB clock used by
USB Full Speed host (ohci) and USB Full Speed device (udc).
The usb drivers (ohci and udc) must configure this clock to 48Mhz.
This configuration was formely done in mach-at91/clock.c, but this
implementation will be removed when moving to common clk framework.

This patch add support for usb clock retrieval and configuration, and is
backward compatible with the current at91 clk implementation (if usb clk
is not found, it does not configure/enable the usb clk).

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/usb/gadget/at91_udc.c |   12 ++++++++++++
 drivers/usb/gadget/at91_udc.h |    2 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
index fce8e4e..1306a02 100644
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -870,6 +870,10 @@ static void clk_on(struct at91_udc *udc)
 	if (udc->clocked)
 		return;
 	udc->clocked = 1;
+	if (udc->uclk) {
+		clk_set_rate(udc->uclk, 48000000);
+		clk_prepare_enable(udc->uclk);
+	}
 	clk_prepare_enable(udc->iclk);
 	clk_prepare_enable(udc->fclk);
 }
@@ -882,6 +886,8 @@ static void clk_off(struct at91_udc *udc)
 	udc->gadget.speed = USB_SPEED_UNKNOWN;
 	clk_disable_unprepare(udc->fclk);
 	clk_disable_unprepare(udc->iclk);
+	if (udc->uclk)
+		clk_disable_unprepare(udc->uclk);
 }
 
 /*
@@ -1781,6 +1787,10 @@ static int at91udc_probe(struct platform_device *pdev)
 		goto fail1;
 	}
 
+	udc->uclk = clk_get(dev, "usb_clk");
+	if (IS_ERR(udc->uclk))
+		udc->uclk = NULL;
+
 	/* don't do anything until we have both gadget driver and VBUS */
 	retval = clk_prepare_enable(udc->iclk);
 	if (retval)
@@ -1894,6 +1904,8 @@ static int __exit at91udc_remove(struct platform_device *pdev)
 
 	clk_put(udc->iclk);
 	clk_put(udc->fclk);
+	if (udc->uclk)
+		clk_put(udc->uclk);
 
 	return 0;
 }
diff --git a/drivers/usb/gadget/at91_udc.h b/drivers/usb/gadget/at91_udc.h
index e647d1c..0175246 100644
--- a/drivers/usb/gadget/at91_udc.h
+++ b/drivers/usb/gadget/at91_udc.h
@@ -126,7 +126,7 @@ struct at91_udc {
 	unsigned			active_suspend:1;
 	u8				addr;
 	struct at91_udc_data		board;
-	struct clk			*iclk, *fclk;
+	struct clk			*iclk, *fclk, *uclk;
 	struct platform_device		*pdev;
 	struct proc_dir_entry		*pde;
 	void __iomem			*udp_baseaddr;
-- 
1.7.9.5



From nsekhar at ti.com  Tue Jul 16 11:27:44 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 16 Jul 2013 20:57:44 +0530
Subject: [PATCH -next] ARM: edma: remove duplicated include from edma.c
In-Reply-To: <CAPgLHd_j_JmDOsGSwLO_eBZnWteMzLVKJa93fY2iaSe31Ozo_w@mail.gmail.com>
References: <CAPgLHd_j_JmDOsGSwLO_eBZnWteMzLVKJa93fY2iaSe31Ozo_w@mail.gmail.com>
Message-ID: <51E56670.6020802@ti.com>

On 6/26/2013 7:28 AM, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> 
> Remove duplicated include.
> 
> Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Sending this for inclusion in v3.11-rc2. This is technically a clean-up,
but this is still -rc1, so lets see.

Thanks,
Sekhar


From daniel.lezcano at linaro.org  Tue Jul 16 11:32:41 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 16 Jul 2013 17:32:41 +0200
Subject: [PATCH v2 2/2] clocksource/cadence_ttc: Reuse clocksource as
 sched_clock
In-Reply-To: <51DFF1AA.8080407@monstr.eu>
References: <1373302298-27957-1-git-send-email-soren.brinkmann@xilinx.com>
 <1373302298-27957-3-git-send-email-soren.brinkmann@xilinx.com>
 <51DFF1AA.8080407@monstr.eu>
Message-ID: <51E56799.2090601@linaro.org>

On 07/12/2013 02:08 PM, Michal Simek wrote:
> Acked-by: Michal Simek <monstr at monstr.eu>

Applied to my tree for 3.12

Thanks
  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From hauke at hauke-m.de  Tue Jul 16 11:35:21 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Tue, 16 Jul 2013 17:35:21 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <20130716172023.64337690@skate>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716172023.64337690@skate>
Message-ID: <51E56839.8010205@hauke-m.de>

On 07/16/2013 05:20 PM, Thomas Petazzoni wrote:
> Dear Hauke Mehrtens,
> 
> On Tue, 16 Jul 2013 15:52:07 +0200, Hauke Mehrtens wrote:
>> +/include/ "bcm5301x.dtsi"
>> +
>> +/ {
>> +	model = "Netgear R6250 V1 (BCM4708)";
>> +	compatible = "netgear,r6250v1", "brcm,bcm5301x";
> 
> I don't think using "brcm,bcm5301x" has a compatible string is very
> appropriate. It should really reflect which particular SoC this board
> is using.

Ok I will change this to brcm,bcm4708

> 
>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
>> new file mode 100644
>> index 0000000..638350d
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>> @@ -0,0 +1,72 @@
>> +/*
>> + * Broadcom BCM47XX / BCM53XX ARM platform code.
>> + *
>> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
>> + *
>> + * Licensed under the GNU/GPL. See COPYING for details.
>> + */
>> +
>> +/include/ "skeleton.dtsi"
>> +
>> +/ {
>> +	compatible = "brcm,bcm5301x";
>> +	model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC";
> 
> Same here. Most likely, there will be difference between those SoCs, so
> a compatible string of bcm5301x doesn't seem right, and also the model
> that says this will handle all those platforms.

This should just be a generic file describing the SoC series. I do not
know how different the SoCs from this series are, because I just own one
device. ;-) For the older Mips versions of this SoC line all the SoCs
announced together just had very tiny differences according to the
vendor code it is the same here.

> 
>> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig
>> new file mode 100644
>> index 0000000..1e16e87
>> --- /dev/null
>> +++ b/arch/arm/mach-bcm53xx/Kconfig
>> @@ -0,0 +1,10 @@
>> +config ARCH_BCM53XX
>> +	bool "Broadcom BCM47XX / BCM53XX ARM SoC"
> 
> So the directory is named mach-bcm53xx, but you also handle BCM47xx
> SoCs. This doesn't sound really easy to follow.

Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I
do not know why there are two different names, probably marketing.

Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a
MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to
not conflict with the MIPS part now. I know this could still cause
problems and people will get confused, but I do not know a better name.

> 
>> +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
>> +				 struct pt_regs *regs)
>> +{
>> +	/*
>> +	 * These happen for no good reason
>> +	 * possibly left over from CFE
> 
> CFE ?

Common Firmware Environment

This is the boot loader used by Broadcom on these devices:
https://en.wikipedia.org/wiki/Common_Firmware_Environment

>> +	 */
>> +	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
>> +		addr, fsr);
>> +
>> +	/* Returning non-zero causes fault display and panic */
>> +	return 0;
>> +}
>> +
>> +static void bcm53xx_aborts_enable(void)
>> +{
>> +	/* Install our hook */
>> +	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
>> +			"imprecise external abort");
>> +}
>> +
>> +static void __init bcm53xx_timer_init(void)
>> +{
>> +	of_clk_init(NULL);
>> +	clocksource_of_init();
>> +}
>> +
>> +void __init bcm53xx_map_io(void)
>> +{
>> +	debug_ll_io_init();
>> +	bcm53xx_aborts_enable();
>> +}
> 
> That's a nitpick, but I personally tend to like when callbacks are
> ordered as they are called, i.e ->map_io() first, and then
> ->init_time().

Good point.


>> +static void __init bcm53xx_dt_init(void)
>> +{
>> +	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>> +}
> 
> Not needed, this is the default. When ->init_machine() is NULL, the ARM
> core already calls automatically of_platform_populate().

Thanks for the Info.

>> +
>> +static const char const *bcm53xx_dt_compat[] = {
>> +	"brcm,bcm5301x",
>> +	"netgear,r6250v1",
>> +	NULL,
> 
> Don't list the boards here, only the SoCs. Otherwise, this place is
> going to become a nightmare of conflicts.

Ok I will change this.

>> +DT_MACHINE_START(BCM53XX, "BCM53XX")
>> +	.init_machine = bcm53xx_dt_init,
>> +	.map_io = bcm53xx_map_io,
>> +	.init_irq = irqchip_init,
>> +	.init_time = bcm53xx_timer_init,
>> +	.dt_compat = bcm53xx_dt_compat,
>> +MACHINE_END
> 
> You also probably want to add this new platform to the
> multi_v7_defconfig.
> 
> Best regards,
> 
> Thomas
> 



From hauke at hauke-m.de  Tue Jul 16 11:39:46 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Tue, 16 Jul 2013 17:39:46 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <20130716151435.GB3871@linaro.org>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org>
Message-ID: <51E56942.8030801@hauke-m.de>

On 07/16/2013 05:14 PM, Matt Porter wrote:
> Hi Hauke,
> 
> On Tue, Jul 16, 2013 at 03:52:07PM +0200, Hauke Mehrtens wrote:
>> This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU.
>> Currently just booting to a shell is working and nothing else, no
>> Ethernet, wifi, flash, ...
>>
>> This SoC uses a Dual core CPU, but this is currently not implemented.
>> More information about this SoC can be found here:
>> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers
>>
>> Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
>> ---
>>
>> A bootlog can be found here:
>> http://pastebin.com/0MYYC7Fx
>>
>>  MAINTAINERS                                  |    7 +++
>>  arch/arm/Kconfig                             |    2 +
>>  arch/arm/Kconfig.debug                       |    5 ++
>>  arch/arm/Makefile                            |    1 +
>>  arch/arm/boot/dts/Makefile                   |    1 +
>>  arch/arm/boot/dts/bcm5301x-netgear-r6250.dts |   20 +++++++
>>  arch/arm/boot/dts/bcm5301x.dtsi              |   72 ++++++++++++++++++++++++++
>>  arch/arm/include/debug/bcm53xx.S             |   19 +++++++
>>  arch/arm/mach-bcm53xx/Kconfig                |   10 ++++
>>  arch/arm/mach-bcm53xx/Makefile               |    1 +
>>  arch/arm/mach-bcm53xx/bcm53xx.c              |   68 ++++++++++++++++++++++++
>>  11 files changed, 206 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
>>  create mode 100644 arch/arm/boot/dts/bcm5301x.dtsi
>>  create mode 100644 arch/arm/include/debug/bcm53xx.S
>>  create mode 100644 arch/arm/mach-bcm53xx/Kconfig
>>  create mode 100644 arch/arm/mach-bcm53xx/Makefile
>>  create mode 100644 arch/arm/mach-bcm53xx/bcm53xx.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index bf61e04..b72ba65 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1795,6 +1795,13 @@ F:	arch/arm/boot/dts/bcm2835*
>>  F:	arch/arm/configs/bcm2835_defconfig
>>  F:	drivers/*/*bcm2835*
>>  
>> +BROADCOM BCM53XX ARM ARCHICTURE
>> +M:	Hauke Mehrtens <hauke at hauke-m.de>
>> +L:	linux-arm-kernel at lists.infradead.org
>> +S:	Maintained
>> +F:	arch/arm/mach-bcm53xx/
>> +F:	arch/arm/boot/dts/bcm53*
>> +
>>  BROADCOM TG3 GIGABIT ETHERNET DRIVER
>>  M:	Nithin Nayak Sujir <nsujir at broadcom.com>
>>  M:	Michael Chan <mchan at broadcom.com>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index ba412e0..ee7362e 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -930,6 +930,8 @@ source "arch/arm/mach-bcm/Kconfig"
>>  
>>  source "arch/arm/mach-bcm2835/Kconfig"
>>  
>> +source "arch/arm/mach-bcm53xx/Kconfig"
>> +
>>  source "arch/arm/mach-clps711x/Kconfig"
>>  
>>  source "arch/arm/mach-cns3xxx/Kconfig"
>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>> index e401a76..74e32f6 100644
>> --- a/arch/arm/Kconfig.debug
>> +++ b/arch/arm/Kconfig.debug
>> @@ -93,6 +93,10 @@ choice
>>  		bool "Kernel low-level debugging on BCM2835 PL011 UART"
>>  		depends on ARCH_BCM2835
>>  
>> +	config DEBUG_BCM53XX
>> +		bool "Kernel low-level debugging on BCM53XX UART1"
>> +		depends on ARCH_BCM53XX
>> +
>>  	config DEBUG_CLPS711X_UART1
>>  		bool "Kernel low-level debugging messages via UART1"
>>  		depends on ARCH_CLPS711X
>> @@ -762,6 +766,7 @@ endchoice
>>  config DEBUG_LL_INCLUDE
>>  	string
>>  	default "debug/bcm2835.S" if DEBUG_BCM2835
>> +	default "debug/bcm53xx.S" if DEBUG_BCM53XX
>>  	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
>>  	default "debug/exynos.S" if DEBUG_EXYNOS_UART
>>  	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
>> index c0ac0f5..4a69cd5 100644
>> --- a/arch/arm/Makefile
>> +++ b/arch/arm/Makefile
>> @@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
>>  machine-$(CONFIG_ARCH_AT91)		+= at91
>>  machine-$(CONFIG_ARCH_BCM)		+= bcm
>>  machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
>> +machine-$(CONFIG_ARCH_BCM53XX)		+= bcm53xx
>>  machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
>>  machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
>>  machine-$(CONFIG_ARCH_DAVINCI)		+= davinci
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 641b3c9..480a68e 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -242,6 +242,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
>>  dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
>>  	zynq-zc706.dtb \
>>  	zynq-zed.dtb
>> +dtb-$(CONFIG_ARCH_BCM53XX) += bcm5301x-netgear-r6250.dtb
>>  
>>  targets += dtbs
>>  targets += $(dtb-y)
>> diff --git a/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
>> new file mode 100644
>> index 0000000..d1b97aa
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
>> @@ -0,0 +1,20 @@
>> +/*
>> + * Broadcom BCM47XX / BCM53XX arm platform code.
>> + *
>> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
>> + *
>> + * Licensed under the GNU/GPL. See COPYING for details.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +/include/ "bcm5301x.dtsi"
>> +
>> +/ {
>> +	model = "Netgear R6250 V1 (BCM4708)";
>> +	compatible = "netgear,r6250v1", "brcm,bcm5301x";
>> +
>> +	memory {
>> +		reg = <0x00000000 0x08000000>;
>> +	};
>> +};
>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
>> new file mode 100644
>> index 0000000..638350d
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>> @@ -0,0 +1,72 @@
>> +/*
>> + * Broadcom BCM47XX / BCM53XX ARM platform code.
>> + *
>> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
>> + *
>> + * Licensed under the GNU/GPL. See COPYING for details.
>> + */
>> +
>> +/include/ "skeleton.dtsi"
>> +
>> +/ {
>> +	compatible = "brcm,bcm5301x";
> 
> Ok, this was nagging at me before I went on my very long vacation. I see
> the "brcm" vendor prefix as a real consistency problem. I noticed on the
> bcm281xx/kona family, we have been using "bcm" which is not logged in
> vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
> already established use of "brcm" before any of the bcm281xx support
> came in. Ideally, the vendor prefix should change to "bcm" since every
> reference in the family names is BCM. However, if others want the least
> amount of churn in making this consistent, we might have to go with
> "brcm" across the board.
> 
> Arnd, any thoughts here?

I have no problem with bcm or with brcm. This is a Broadcom Chip and
their names are starting with bcm.

> Another thing is that this is missing a binding definition for this
> compatible string. See Documentation/devicetree/bindings/arm/bcm2835.txt
> for an example. You should split this patch out separately as the DT
> maintainers generally want to see bindings as a separate patch for easy
> independent review.

Ok I will do that. This will then be merged by Linus in the 3.12 merge
window into a working version or how does this work?

Currently I have based this patch on top of 3.11-rc1 on which tree
should I base my changes?

> Last thing, compatible strings are not to have wildcards in them. See
> http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
> and note the Warning at the bottom. Also see how bcm2835.txt and
> bcm11351.txt use a specific model.

Ok will do that.

>> +	model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC";
>> +	interrupt-parent = <&gic>;
>> +
>> +	chosen {
>> +		bootargs = "console=ttyS0,115200 earlyprintk debug";
>> +	};
>> +
>> +	cpus {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		cpu at 0 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a9";
>> +			reg = <0>;
>> +		};
>> +	};
>> +
>> +	clocks {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		clk_periph: periph {
>> +			compatible = "fixed-clock";
>> +			#clock-cells = <0>;
>> +			clock-frequency = <400000000>;
>> +		};
>> +	};
>> +
>> +	uart at 18000300 {
>> +		compatible = "ns16550";
>> +		reg = <0x18000300 0x100>;
>> +		interrupts = <0 85 4>;
> 
> The DT files should be switched to use the C preprocessor like several
> other machines have already done (see bcm11351.dtsi, for example), you
> can use the existing GIC includes and have human-redable defines for the
> edge/level values here and throughout all interrupt properties.

Ok I will read that and change it.

>> +		clock-frequency = <100000000>;
>> +	};
>> +
>> +	uart at 18000400 {
>> +		compatible = "ns16550";
>> +		reg = <0x18000400 0x100>;
>> +		interrupts = <0 85 4>;
>> +		clock-frequency = <100000000>;
>> +	};
>> +
>> +	gic: interrupt-controller at 19021000 {
>> +		compatible = "arm,cortex-a9-gic";
>> +		#interrupt-cells = <3>;
>> +		#address-cells = <0>;
>> +		interrupt-controller;
>> +		reg = <0x19021000 0x1000>,
>> +		      <0x19020100 0x100>;
>> +	};
>> +
>> +	timer at 19020200 {
>> +		compatible = "arm,cortex-a9-global-timer";
>> +		reg = <0x19020200 0x100>;
>> +		interrupts = <1 11 0xf04>;
>> +		clocks = <&clk_periph>;
>> +		#clock-cells = <0>;
>> +	};
>> +};
>> diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S
>> new file mode 100644
>> index 0000000..98c836b
>> --- /dev/null
>> +++ b/arch/arm/include/debug/bcm53xx.S
>> @@ -0,0 +1,19 @@
>> +/*
>> + * Macros used for EARLY_PRINTK, in low-level UART debug console
>> + *
>> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
>> + *
>> + * Licensed under the GNU/GPL. See COPYING for details.
>> + */
>> +
>> +#define BCM53XX_UART1_PHYS	0x18000300
>> +#define BCM53XX_UART1_VIRT	0xf1000300
>> +#define BCM53XX_UART1_SH	0
>> +
>> +	.macro	addruart, rp, rv, tmp
>> +	ldr	\rp, =BCM53XX_UART1_PHYS 	@ MMU off, Physical
>> +	ldr	\rv, =BCM53XX_UART1_VIRT 	@ MMU on, Virtual
>> +	.endm
>> +
>> +#define UART_SHIFT	BCM53XX_UART1_SH
>> +#include <asm/hardware/debug-8250.S>
>> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig
>> new file mode 100644
>> index 0000000..1e16e87
>> --- /dev/null
>> +++ b/arch/arm/mach-bcm53xx/Kconfig
>> @@ -0,0 +1,10 @@
>> +config ARCH_BCM53XX
>> +	bool "Broadcom BCM47XX / BCM53XX ARM SoC"
>> +	select CPU_V7
>> +	select ARM_GIC
>> +	select HAVE_CLK
>> +	select GENERIC_CLOCKEVENTS
>> +	select GENERIC_TIME
>> +	select ARM_GLOBAL_TIMER
>> +	help
>> +	  Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores.
>> diff --git a/arch/arm/mach-bcm53xx/Makefile b/arch/arm/mach-bcm53xx/Makefile
>> new file mode 100644
>> index 0000000..88da84d
>> --- /dev/null
>> +++ b/arch/arm/mach-bcm53xx/Makefile
>> @@ -0,0 +1 @@
>> +obj-y += bcm53xx.o
>> diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c
>> new file mode 100644
>> index 0000000..aa5bd397
>> --- /dev/null
>> +++ b/arch/arm/mach-bcm53xx/bcm53xx.c
>> @@ -0,0 +1,68 @@
>> +/*
>> + * Broadcom BCM47XX / BCM53XX ARM platform code.
>> + *
>> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
>> + *
>> + * Licensed under the GNU/GPL. See COPYING for details.
>> + */
>> +#include <linux/of_address.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/irqchip.h>
>> +#include <linux/clocksource.h>
>> +#include <linux/clk-provider.h>
>> +
>> +#include <asm/mach/arch.h>
>> +#include <asm/mach/map.h>
>> +#include <asm/signal.h>
>> +
>> +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
>> +				 struct pt_regs *regs)
>> +{
>> +	/*
>> +	 * These happen for no good reason
>> +	 * possibly left over from CFE
>> +	 */
>> +	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
>> +		addr, fsr);
>> +
>> +	/* Returning non-zero causes fault display and panic */
>> +	return 0;
>> +}
>> +
>> +static void bcm53xx_aborts_enable(void)
>> +{
>> +	/* Install our hook */
>> +	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
>> +			"imprecise external abort");
>> +}
>> +
>> +static void __init bcm53xx_timer_init(void)
>> +{
>> +	of_clk_init(NULL);
>> +	clocksource_of_init();
>> +}
>> +
>> +void __init bcm53xx_map_io(void)
>> +{
>> +	debug_ll_io_init();
>> +	bcm53xx_aborts_enable();
>> +}
>> +
>> +static void __init bcm53xx_dt_init(void)
>> +{
>> +	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>> +}
>> +
>> +static const char const *bcm53xx_dt_compat[] = {
>> +	"brcm,bcm5301x",
>> +	"netgear,r6250v1",
>> +	NULL,
>> +};
>> +
>> +DT_MACHINE_START(BCM53XX, "BCM53XX")
>> +	.init_machine = bcm53xx_dt_init,
>> +	.map_io = bcm53xx_map_io,
>> +	.init_irq = irqchip_init,
>> +	.init_time = bcm53xx_timer_init,
>> +	.dt_compat = bcm53xx_dt_compat,
>> +MACHINE_END
>> -- 
>> 1.7.10.4
>>



From swarren at wwwdotorg.org  Tue Jul 16 11:45:43 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 09:45:43 -0600
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <20130716041056.GA30067@S2101-09.ap.freescale.net>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <20130716041056.GA30067@S2101-09.ap.freescale.net>
Message-ID: <51E56AA7.7020103@wwwdotorg.org>

On 07/15/2013 10:10 PM, Shawn Guo wrote:
> On Mon, Jul 15, 2013 at 09:35:52PM -0600, Stephen Warren wrote:
>>> It's a little bit late to register gpio-reset driver at module_init
>>> time, because gpio-reset provides reset control via gpio for other
>>> devices which are mostly probed at module_init time too.  And it
>>> becomes even worse, when the gpio comes from IO expander on I2C bus,
>>> e.g. pca953x.  In that case, gpio-reset needs to be ready before I2C
>>> bus driver which is generally ready at subsys_initcall time.  Let's
>>> register gpio-reset driver in arch_initcall() to have it ready early
>>> enough.
>>
>> There's no need for the reset driver to be registered before its users;
>> the users of the reset GPIO will simply have their probe deferred until
>> the reset controller is available, and then everything will work out
>> just fine.
>>
>>> The defer probe mechanism is not used here, because a reset controller
>>> driver should be reasonably registered early than other devices.  More
>>> importantly, defer probe doe not help in some nasty cases, e.g. the
>>> gpio-pca953x device itself needs a reset from gpio-reset driver to start
>>> working.
>>
>> That should work fine with deferred probe.
> 
> I should probably rework the commit log.  But I do not see a problem
> to register gpio-reset driver a little bit earlier. 

Registering the driver earlier won't cause any bugs. However, it's not
the correct approach.

Deferred probe /is/ the approach for assuring correct dependencies
between drivers. It works and should be used. There are not enough
initcall levels to play games using initcalls and solve all the issues,
and the ordering requirements vary board-to-board. Deferred probe at
runtime handles this without having to manually place all the drivers
into specific initcall levels, and dynamically adjusts to board
differences, since it all happens automatically at run-time.

Consider a SoC that has:

* An external PMIC, which the CPU has to communicate with to enable
power to all SoC components outside the CPU and a single I2C instance
dedicated to communicating with the PMIC.
* An on-SoC reset controller (for on-SoC) modules that resets other
on-SoC I2C controllers
* An on-SoC I2C controller which communicates with a GPIO expander
* One of the GPIOs on that expander is the reset GPIO for some other
device connected by I2C

What initcall levels are you going to use for all the drivers
(PM-related I2C, PMIC, on-SoC reset controller, secondary I2C
controller, GPIO expander IC, GPIO-reset "device", the final device
affected by the GPIO reset controller).

Now wonder whether that same order is going to be suitable for every
single other board. That's quite unlikely...

 On the other hand,
> if we reply on deferred probe, many drivers probe could be deferred.
> For example, on my system, the gpio-pca953x on I2C bus works as a GPIO
> controller and provides resets to many board level components.
> Deferring probe of gpio-pca953x on I2C bus means every single probe of
> all these components gets deferred.  IMO, this situation should be
> reasonably avoided.

Yes, deferred probe will happen. If we want to solve that, I believe we
need a more generic solution specifically targeted at that, rather that
playing games with initcalls.

(It'd be nice if each DT node declared all its resources in a way the DT
core could parse them and determine the dependency graph itself, without
having to write code in all drivers to extract that information from DT.
This would need a standardized resource representation in DT, and as
such would mean throwing out all the bindings and starting again...
Perhaps some parallel set of properties could be invented to hint at the
order, but still fall back to deferred probe where that information was
missing or inaccurate.)


From maxime.ripard at free-electrons.com  Tue Jul 16 11:46:16 2013
From: maxime.ripard at free-electrons.com ('Maxime Ripard')
Date: Tue, 16 Jul 2013 17:46:16 +0200
Subject: [PATCH 3/3] fb: backlight: HX8357: Add HX8369 support
In-Reply-To: <003601ce81c8$c2573320$47059960$@samsung.com>
References: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
 <1373902022-20439-4-git-send-email-maxime.ripard@free-electrons.com>
 <003601ce81c8$c2573320$47059960$@samsung.com>
Message-ID: <20130716154616.GK3125@lukather>

Hi Jingoo,

On Tue, Jul 16, 2013 at 11:04:09AM +0900, Jingoo Han wrote:
> On Tuesday, July 16, 2013 12:27 AM, Maxime Ripard wrote:
> > 
> > From: Alexandre Belloni <alexandre.belloni at free-electrons.com>
> > 
> > Add support for the Himax HX8369 controller as it is quite similar to the
> > hx8357.
> > 
> > Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> 
> Hi Maxime Ripard,
> 
> I reviewed this patch with Himax HX8369 datasheet.
> I cannot find any problems. It looks good.
> 
> However, if possible, please add comment on huge delays such as
> msleep(120), msleep(100), etc.

Right. I'll send a follow-up patch if this is merged right away, or
merge the comments in the next iteration of the patches.

> Acked-by: Jingoo Han <jg1.han at samsung.com>

Thanks for taking the time to review this!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130716/67432efb/attachment.sig>

From swarren at wwwdotorg.org  Tue Jul 16 11:47:02 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 09:47:02 -0600
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <20130716065130.GB30067@S2101-09.ap.freescale.net>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <20130716065130.GB30067@S2101-09.ap.freescale.net>
Message-ID: <51E56AF6.30506@wwwdotorg.org>

On 07/16/2013 12:51 AM, Shawn Guo wrote:
> On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote:
>> Hi Philipp,
>>
>> On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
>>> This driver implements a reset controller device that toggle a gpio
>>> connected to a reset pin of a peripheral IC. The delay between assertion
>>> and de-assertion of the reset signal can be configured via device tree.
>>>
>>> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
>>> Reviewed-by: Stephen Warren <swarren at nvidia.com>
>>
>> I see this patch is very useful, as GPIOs are widely used to reset
>> components/devices on board.  But I do not find the patch in v3.11-rc1.
>> What's your plan about it?
>>
>> Also, I'm wondering if we should register the driver a little bit
>> early.  Please see the following patch.  If it makes sense to you,
>> I can send the patch to you, or you can just quash it into yours.
> 
> And here is another change request.

> diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c

> -	gpio_set_value(drvdata->gpio, value);
> +	if (gpio_cansleep(drvdata->gpio))
> +		gpio_set_value_cansleep(drvdata->gpio, value);
> +	else
> +		gpio_set_value(drvdata->gpio, value);

That's not right. Calling gpio_set_value() v.s.
gpio_set_value_cansleep() should be based on the properties of the
calling context, not the GPIO being controlled. In other words, if it's
permissible to call gpio_set_value_cansleep() at this point in the code,
simply always call that, and remove the conditional logic.


From swarren at wwwdotorg.org  Tue Jul 16 11:48:00 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 09:48:00 -0600
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <1373968758.4327.17.camel@pizza.hi.pengutronix.de>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <1373968758.4327.17.camel@pizza.hi.pengutronix.de>
Message-ID: <51E56B30.7030302@wwwdotorg.org>

On 07/16/2013 03:59 AM, Philipp Zabel wrote:
...
> Deferred probing is fine, but it'd be nice to keep the probe deferral
> loops to a minimum where possible and/or reasonable.

I agree, but manually selecting initcalls for drivers is not the
solution. See my other email.



From daniel.lezcano at linaro.org  Tue Jul 16 11:48:36 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 16 Jul 2013 17:48:36 +0200
Subject: [PATCH v3 1/7] ARM: at91/tc/clocksource: replace
 clk_enable/disable with clk_prepare_enable/disable_unprepare.
In-Reply-To: <1373987114-24009-1-git-send-email-b.brezillon@overkiz.com>
References: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
 <1373987114-24009-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <51E56B54.1010800@linaro.org>

On 07/16/2013 05:05 PM, Boris BREZILLON wrote:
> Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
> avoid common clk framework warnings.
> 
> Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
> ---

This patch is part of a series and the recipients are also Thomas and
John (clocksource maintainers).

Is this patch going through Nicolas's tree or Thomas's tree ?

Thanks
  -- Daniel

>  drivers/clocksource/tcb_clksrc.c |   10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
> index 8a61872..229c019 100644
> --- a/drivers/clocksource/tcb_clksrc.c
> +++ b/drivers/clocksource/tcb_clksrc.c
> @@ -100,7 +100,7 @@ static void tc_mode(enum clock_event_mode m, struct clock_event_device *d)
>  			|| tcd->clkevt.mode == CLOCK_EVT_MODE_ONESHOT) {
>  		__raw_writel(0xff, regs + ATMEL_TC_REG(2, IDR));
>  		__raw_writel(ATMEL_TC_CLKDIS, regs + ATMEL_TC_REG(2, CCR));
> -		clk_disable(tcd->clk);
> +		clk_disable_unprepare(tcd->clk);
>  	}
>  
>  	switch (m) {
> @@ -109,7 +109,7 @@ static void tc_mode(enum clock_event_mode m, struct clock_event_device *d)
>  	 * of oneshot, we get lower overhead and improved accuracy.
>  	 */
>  	case CLOCK_EVT_MODE_PERIODIC:
> -		clk_enable(tcd->clk);
> +		clk_prepare_enable(tcd->clk);
>  
>  		/* slow clock, count up to RC, then irq and restart */
>  		__raw_writel(timer_clock
> @@ -126,7 +126,7 @@ static void tc_mode(enum clock_event_mode m, struct clock_event_device *d)
>  		break;
>  
>  	case CLOCK_EVT_MODE_ONESHOT:
> -		clk_enable(tcd->clk);
> +		clk_prepare_enable(tcd->clk);
>  
>  		/* slow clock, count up to RC, then irq and stop */
>  		__raw_writel(timer_clock | ATMEL_TC_CPCSTOP
> @@ -275,7 +275,7 @@ static int __init tcb_clksrc_init(void)
>  	pdev = tc->pdev;
>  
>  	t0_clk = tc->clk[0];
> -	clk_enable(t0_clk);
> +	clk_prepare_enable(t0_clk);
>  
>  	/* How fast will we be counting?  Pick something over 5 MHz.  */
>  	rate = (u32) clk_get_rate(t0_clk);
> @@ -313,7 +313,7 @@ static int __init tcb_clksrc_init(void)
>  		/* tclib will give us three clocks no matter what the
>  		 * underlying platform supports.
>  		 */
> -		clk_enable(tc->clk[1]);
> +		clk_prepare_enable(tc->clk[1]);
>  		/* setup both channel 0 & 1 */
>  		tcb_setup_dual_chan(tc, best_divisor_idx);
>  	}
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From b.brezillon at overkiz.com  Tue Jul 16 11:49:11 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Tue, 16 Jul 2013 17:49:11 +0200
Subject: [PATCH v3 2/7] mmc: atmel-mci: prepare clk before calling enable
In-Reply-To: <20130716171324.7d483ada@skate>
References: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
 <1373987208-24120-1-git-send-email-b.brezillon@overkiz.com>
 <20130716171324.7d483ada@skate>
Message-ID: <51E56B77.2050105@overkiz.com>

Hello Thomas,

On 16/07/2013 17:13, Thomas Petazzoni wrote:
> Dear Boris BREZILLON,
>
> On Tue, 16 Jul 2013 17:06:48 +0200, Boris BREZILLON wrote:
>
>>   	buf = kmalloc(ATMCI_REGS_SIZE, GFP_KERNEL);
>>   	if (!buf)
>> @@ -389,9 +391,13 @@ static int atmci_regs_show(struct seq_file *s, void *v)
>>   	 * consistent.
>>   	 */
>>   	spin_lock_bh(&host->lock);
>> -	clk_enable(host->mck);
>> +	ret = clk_prepare_enable(host->mck);
> I am not very familiar with the spin_lock_bh() variant, but are you
> sure we are allowed to sleep within a spin_lock_bh()-protected critical
> section?
>
> Remember that clk_prepare_enable() calls both ->prepare() and
> ->enable() for the clock, and ->prepare() is allowed to sleep, while
> ->enable() is guaranteed not to sleep.
>
> Therefore, clk_prepare() is usually called at probe time, while
> clk_enable() is called whenever enabling/disabling the clock is really
> needed. So not all clk_enable() can transparently be converted into a
> clk_prepare_enable().
You're absolutely right. We should not call clk_prepare/unprepare inside 
a critical section,
as the prepare/unprepare callback may sleep.

In this particular case it won't hurt as the mci clk is a peripheral clk 
which does not
implement the prepare callback (and as a result won't sleep).

Anyway, I will fix it.

What is the best approach to do so ?
1) call clk_prepare/unprepare in the probe/remove functions and call 
clk_enable/disable
     in resume/suspend functions
2) get clk_prepare_enable/disable_unprepare outside of the critical 
sections (I don't think
     there is any need for the mci host lock to be held when enabling 
the clk,
     clk framework already handle concurrent accesses to clks)

I will check other patches of this series to see if they introduce 
similar issues.

> Best regards,
>
> Thomas



From soren.brinkmann at xilinx.com  Tue Jul 16 11:51:13 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Tue, 16 Jul 2013 08:51:13 -0700
Subject: [PATCH v2 2/2] clocksource/cadence_ttc: Reuse clocksource as
 sched_clock
In-Reply-To: <51E56799.2090601@linaro.org>
References: <1373302298-27957-1-git-send-email-soren.brinkmann@xilinx.com>
 <1373302298-27957-3-git-send-email-soren.brinkmann@xilinx.com>
 <51DFF1AA.8080407@monstr.eu> <51E56799.2090601@linaro.org>
Message-ID: <9616f33f-9b1b-4f0c-9b2c-51806fc1c4c6@CO1EHSMHS007.ehs.local>

On Tue, Jul 16, 2013 at 05:32:41PM +0200, Daniel Lezcano wrote:
> On 07/12/2013 02:08 PM, Michal Simek wrote:
> > Acked-by: Michal Simek <monstr at monstr.eu>
> 
> Applied to my tree for 3.12
thanks




From daniel.lezcano at linaro.org  Tue Jul 16 11:55:41 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 16 Jul 2013 17:55:41 +0200
Subject: [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer
In-Reply-To: <alpine.DEB.2.02.1307081041290.32106@ionos.tec.linutronix.de>
References: <51B8D310.4050404@linaro.org> <51D9548B.9040907@gmail.com>
 <alpine.DEB.2.02.1307071508030.32106@ionos.tec.linutronix.de>
 <20130707144645.GA11908@titan.lakedaemon.net>
 <alpine.DEB.2.02.1307071723220.32106@ionos.tec.linutronix.de>
 <20130707235819.GB11908@titan.lakedaemon.net>
 <alpine.DEB.2.02.1307081041290.32106@ionos.tec.linutronix.de>
Message-ID: <51E56CFD.9050508@linaro.org>

On 07/08/2013 10:45 AM, Thomas Gleixner wrote:
> On Sun, 7 Jul 2013, Jason Cooper wrote:
>> On Sun, Jul 07, 2013 at 05:30:31PM +0200, Thomas Gleixner wrote:
>> I don't mind delaying half of a series so the drivers/ portion can land
>> in mainline, and the rest can land in the next cycle.  But when things
>> don't go according to that plan, I'd like a little consideration /
>> flexibility about solving the problem.  Especially considering I'm
>> *trying* to do the right thing by pushing to appropriate maintainers
>> first.
>>
>> Of course, this is a moot point since, as you clarified above, this
>> dependency doesn't have the hazards typically associated with
>> out-of-tree dependencies.
> 
> There is a very simple procedure for stuff like this.
> 
> Series has parts which go through tree A and B and another larger part
> for tree C which depends on the A and B parts.
> 
> So ask the maintainers of A and B to apply this to separate branches,
> which are based on some commit in Linus tree. These branches can be
> pulled into C and C can apply the depending stuff on top.
> 
> Now the maintainers of A and B merge these branches into their main
> devel branch, can do further fixups and stuff on top. And the whole
> thing just works without glitches during the merge window.
> 
> We do this all the time.

Ok, I was about to send to both of you a PR with a common ancestor [1]
for this patch but finally this patch has been taken for timers/urgent.

I don't have to send the PR, right ?

timers/urgent will be merged into timers/core, correct ?

Thanks
  -- Daniel

[1]
https://git.linaro.org/gitweb?p=people/dlezcano/clockevents.git;a=shortlog;h=refs/heads/timers/mvebu-deps-3.12


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From broonie at kernel.org  Tue Jul 16 11:57:40 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Jul 2013 16:57:40 +0100
Subject: [PATCH v3] rtc: Add MOXA ART RTC driver
In-Reply-To: <CACmBeS3jU2csACZCqXfRvCYAEHaK7S3AcJ++Yd=L-mgfeqg68A@mail.gmail.com>
References: <1373550711-18828-1-git-send-email-jonas.jensen@gmail.com>
 <1373978485-17496-1-git-send-email-jonas.jensen@gmail.com>
 <20130716131332.GL22506@sirena.org.uk>
 <CACmBeS3jU2csACZCqXfRvCYAEHaK7S3AcJ++Yd=L-mgfeqg68A@mail.gmail.com>
Message-ID: <20130716155740.GO22506@sirena.org.uk>

On Tue, Jul 16, 2013 at 04:04:07PM +0200, Jonas Jensen wrote:
> On 16 July 2013 15:13, Mark Brown <broonie at kernel.org> wrote:
> > Since you're now using OF you should also be including a binding
> > document.

> The binding document already exist in set of patches adding MOXA ART
> SoC support ( I intend to mail out v4 once I know how to proceed ):

If that's the case then you need to point people at the binding document
when posting the driver but...

> Or should it be moved here to a new v4 patch?

...it's more normal to push the binding along with the driver.
-------------- 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/20130716/7e5b010a/attachment.sig>

From swarren at wwwdotorg.org  Tue Jul 16 11:58:23 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 09:58:23 -0600
Subject: [PATCH v9] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <1373985202-16353-1-git-send-email-p.zabel@pengutronix.de>
References: <1373985202-16353-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <51E56D9F.30801@wwwdotorg.org>

On 07/16/2013 08:33 AM, Philipp Zabel wrote:
> This driver implements a reset controller device that toggle a gpio
> connected to a reset pin of a peripheral IC. The delay between assertion
> and de-assertion of the reset signal can be configured via device tree.
> 
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> Reviewed-by: Stephen Warren <swarren at nvidia.com>
> ---
> Changes since v8, as suggested by Shawn:
>  - added support for I2C gpios via gpio_set_value_cansleep
>  - switched from module_init to arch_initcall to avoid unnecessary
>    probe deferral of subsys_initcall drivers like gpio-pca953x.

For the record, I'm not convinced that either of those changes is correct.


From lorenzo.pieralisi at arm.com  Tue Jul 16 12:05:42 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 16 Jul 2013 17:05:42 +0100
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
Message-ID: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>

Hello,

version v5 of VExpress SPC driver, please read on the changelog for major
changes and explanations.

The probing scheme is unchanged, since after trying the early platform
devices approach it appeared that the end result was no better than the
current one. The only clean solution relies either on changing how
secondaries are brought up in the kernel (later than now) or enable
early platform device registration through DT. Please check this
thread for the related discussion:

https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036542.html

The interface was adapted to regmap and again reverted to old driver for
the following reasons:

- Power down registers locking is hairy and requires arch spinlocks in
  the MCPM back end to work properly, normal spinlocks cannot be used
- Regmap adds unnecessary code to manage SPC since it is just a bunch of
  registers used to control power management flags, the overhead is just
  not worth it (talking about power down registers, not the vexpress config
  interface)
- The locking scheme behind regmap requires all registers in the map
  to be protected with the same lock, which is not exactly what we want
  here
- Given the reasons above, adding a regmap interface buys us nothing from
  a driver readability and maintainability perspective (again just talking
  about the power interface, a few registers) because for the SPC it would
  simply not be used

/drivers/mfd is probably not the right place for this code as it stands (but
probably will be when the entire driver, with DVFS and config interface, is
complete).

Thank you for the review in advance,
Lorenzo

This patch is v5 of a previous posting:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/177150.html

v5 changes:

- Completely removed vexpress-config interface waiting for refactoring
  based on regmap
- Removed frequency scaling interface and operating points programming
  retrieval
- Trimmed the driver code and DT bindings

v4 changes:
- Applied review comments (trimmed function names, added comments, refactored
  some APIs)
- Added comments throughout the set
- Fixed irq handler bug in checking the transaction status
- Improved commit log to explain early init synchro scheme
- Created a single static structure for variables dynamically allocated to
  remove usage of static
- Improved Kconfig entry

v3 changes:

- added __refdata to spc_check_loaded pointer
- removed some exported symbols
- added node pointer check in vexpress_spc_init()

v2 changes:

- Dropped timeout interface patch
- Converted interfaces to non-timeout ones, integrated and retested
- Removed mutex used at init
- Refactored code to work around init sections warning
- Fixed two minor bugs

Lorenzo Pieralisi (1):
  drivers: mfd: vexpress: add Serial Power Controller (SPC) support

 Documentation/devicetree/bindings/mfd/vexpress-spc.txt |  36 ++
 drivers/mfd/Kconfig                                    |  10 +
 drivers/mfd/Makefile                                   |   1 +
 drivers/mfd/vexpress-spc.c                             | 253 ++++++++++
 include/linux/vexpress.h                               |  17 +
 5 files changed, 317 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/vexpress-spc.txt
 create mode 100644 drivers/mfd/vexpress-spc.c

-- 
1.8.2.2




From lorenzo.pieralisi at arm.com  Tue Jul 16 12:05:43 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 16 Jul 2013 17:05:43 +0100
Subject: [RFC PATCH v5 1/1] drivers: mfd: vexpress: add Serial Power
 Controller (SPC) support
In-Reply-To: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1373990743-23106-2-git-send-email-lorenzo.pieralisi@arm.com>

The TC2 versatile express core tile integrates a logic block that provides the
interface between the dual cluster test-chip and the M3 microcontroller that
carries out power management. The logic block, called Serial Power Controller
(SPC), contains several memory mapped registers to control among other things
low-power states, wake-up irqs and per-CPU jump addresses registers.

This patch provides a driver that enables run-time control of features
implemented by the SPC power management control logic.

The SPC control logic is required to be programmed very early in the boot
process to reset secondary CPUs on the TC2 testchip, set-up jump addresses and
wake-up IRQs for power management. Hence, waiting for core changes to be
made in the device core code to enable early registration of platform
devices, the driver puts in place an early init scheme that allows kernel
drivers to initialize the SPC driver directly from the components requiring
it, if their initialization routine is called before the driver init
function by the boot process.

Device tree bindings documentation for the SPC component is provided with
the patchset.

Cc: Samuel Ortiz <sameo at linux.intel.com>
Cc: Olof Johansson <olof at lixom.net>
Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Amit Kucheria <amit.kucheria at linaro.org>
Cc: Jon Medhurst <tixy at linaro.org>
Signed-off-by: Achin Gupta <achin.gupta at arm.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha at arm.com>
---
 Documentation/devicetree/bindings/mfd/vexpress-spc.txt |  36 ++
 drivers/mfd/Kconfig                                    |  10 +
 drivers/mfd/Makefile                                   |   1 +
 drivers/mfd/vexpress-spc.c                             | 253 ++++++++++
 include/linux/vexpress.h                               |  17 +
 5 files changed, 317 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/vexpress-spc.txt b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
new file mode 100644
index 0000000..1614725
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
@@ -0,0 +1,36 @@
+* ARM Versatile Express Serial Power Controller device tree bindings
+
+Latest ARM development boards implement a power management interface (serial
+power controller - SPC) that is capable of managing power states transitions,
+wake-up IRQs and resume addresses for ARM multiprocessor testchips.
+The serial controller can be programmed through a memory mapped interface
+that enables communication between firmware running on the microcontroller
+managing power states and the application processors.
+
+The SPC DT bindings are defined as follows:
+
+- spc node
+
+	- compatible:
+		Usage: required
+		Value type: <stringlist>
+		Definition: must be
+			    "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc"
+	- reg:
+		Usage: required
+		Value type: <prop-encode-array>
+		Definition: A standard property that specifies the base address
+			    and the size of the SPC address space
+	- interrupts:
+		Usage: required
+		Value type: <prop-encoded-array>
+		Definition:  SPC interrupt configuration. A standard property
+			     that follows ePAPR interrupts specifications
+
+Example:
+
+spc: spc at 7fff0000 {
+	compatible = "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc";
+	reg = <0x7fff0000 0x1000>;
+	interrupts = <0 95 4>;
+};
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6959b8d..ebd23f4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1149,3 +1149,13 @@ config VEXPRESS_CONFIG
 	help
 	  Platform configuration infrastructure for the ARM Ltd.
 	  Versatile Express.
+
+config VEXPRESS_SPC
+	bool "Versatile Express SPC driver support"
+	depends on ARM
+	help
+	  The Serial Power Controller (SPC) for ARM Ltd. test chips, is
+	  an IP that provides a memory mapped interface to power controller
+	  HW. The driver provides an API abstraction allowing to program
+	  registers controlling low-level power management features like power
+	  down flags, global and per-cpu wake-up IRQs.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 718e94a..3a01203 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -153,5 +153,6 @@ obj-$(CONFIG_MFD_SEC_CORE)	+= sec-core.o sec-irq.o
 obj-$(CONFIG_MFD_SYSCON)	+= syscon.o
 obj-$(CONFIG_MFD_LM3533)	+= lm3533-core.o lm3533-ctrlbank.o
 obj-$(CONFIG_VEXPRESS_CONFIG)	+= vexpress-config.o vexpress-sysreg.o
+obj-$(CONFIG_VEXPRESS_SPC)	+= vexpress-spc.o
 obj-$(CONFIG_MFD_RETU)		+= retu-mfd.o
 obj-$(CONFIG_MFD_AS3711)	+= as3711.o
diff --git a/drivers/mfd/vexpress-spc.c b/drivers/mfd/vexpress-spc.c
new file mode 100644
index 0000000..aa8c2a4
--- /dev/null
+++ b/drivers/mfd/vexpress-spc.c
@@ -0,0 +1,253 @@
+/*
+ * Versatile Express Serial Power Controller (SPC) support
+ *
+ * Copyright (C) 2013 ARM Ltd.
+ *
+ * Authors: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
+ *          Achin Gupta           <achin.gupta at arm.com>
+ *          Lorenzo Pieralisi     <lorenzo.pieralisi at arm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <linux/vexpress.h>
+
+#include <asm/cacheflush.h>
+
+#define SPCLOG "vexpress-spc: "
+
+/* SCC conf registers */
+#define A15_CONF		0x400
+#define SYS_INFO		0x700
+
+/* SPC registers base */
+#define SPC_BASE		0xB00
+
+/* SPC wake-up IRQs status and mask */
+#define WAKE_INT_MASK		(SPC_BASE + 0x24)
+#define WAKE_INT_RAW		(SPC_BASE + 0x28)
+#define WAKE_INT_STAT		(SPC_BASE + 0x2c)
+/* SPC power down registers */
+#define A15_PWRDN_EN		(SPC_BASE + 0x30)
+#define A7_PWRDN_EN		(SPC_BASE + 0x34)
+/* SPC per-CPU mailboxes */
+#define A15_BX_ADDR0		(SPC_BASE + 0x68)
+#define A7_BX_ADDR0		(SPC_BASE + 0x78)
+
+/* wake-up interrupt masks */
+#define GBL_WAKEUP_INT_MSK	(0x3 << 10)
+
+/* TC2 static dual-cluster configuration */
+#define MAX_CLUSTERS		2
+
+struct ve_spc_drvdata {
+	void __iomem *baseaddr;
+	/*
+	 * A15s cluster identifier
+	 * It corresponds to A15 processors MPIDR[15:8] bitfield
+	 */
+	u32 a15_clusid;
+};
+
+static struct ve_spc_drvdata *info;
+
+static inline bool cluster_is_a15(u32 cluster)
+{
+	return cluster == info->a15_clusid;
+}
+
+/**
+ * ve_spc_global_wakeup_irq()
+ *
+ * Function to set/clear global wakeup IRQs. Not protected by locking since
+ * it might be used in code paths where normal cacheable locks are not
+ * working. Locking must be provided by the caller to ensure atomicity.
+ *
+ * @set: if true, global wake-up IRQs are set, if false they are cleared
+ */
+void ve_spc_global_wakeup_irq(bool set)
+{
+	u32 reg;
+
+	reg = readl_relaxed(info->baseaddr + WAKE_INT_MASK);
+
+	if (set)
+		reg |= GBL_WAKEUP_INT_MSK;
+	else
+		reg &= ~GBL_WAKEUP_INT_MSK;
+
+	writel_relaxed(reg, info->baseaddr + WAKE_INT_MASK);
+}
+
+/**
+ * ve_spc_cpu_wakeup_irq()
+ *
+ * Function to set/clear per-CPU wake-up IRQs. Not protected by locking since
+ * it might be used in code paths where normal cacheable locks are not
+ * working. Locking must be provided by the caller to ensure atomicity.
+ *
+ * @cluster: mpidr[15:8] bitfield describing cluster affinity level
+ * @cpu: mpidr[7:0] bitfield describing cpu affinity level
+ * @set: if true, wake-up IRQs are set, if false they are cleared
+ */
+void ve_spc_cpu_wakeup_irq(u32 cluster, u32 cpu, bool set)
+{
+	u32 mask, reg;
+
+	if (cluster >= MAX_CLUSTERS)
+		return;
+
+	mask = 1 << cpu;
+
+	if (!cluster_is_a15(cluster))
+		mask <<= 4;
+
+	reg = readl_relaxed(info->baseaddr + WAKE_INT_MASK);
+
+	if (set)
+		reg |= mask;
+	else
+		reg &= ~mask;
+
+	writel_relaxed(reg, info->baseaddr + WAKE_INT_MASK);
+}
+
+/**
+ * ve_spc_set_resume_addr() - set the jump address used for warm boot
+ *
+ * @cluster: mpidr[15:8] bitfield describing cluster affinity level
+ * @cpu: mpidr[7:0] bitfield describing cpu affinity level
+ * @addr: physical resume address
+ */
+void ve_spc_set_resume_addr(u32 cluster, u32 cpu, u32 addr)
+{
+	void __iomem *baseaddr;
+
+	if (cluster >= MAX_CLUSTERS)
+		return;
+
+	if (cluster_is_a15(cluster))
+		baseaddr = info->baseaddr + A15_BX_ADDR0 + (cpu << 2);
+	else
+		baseaddr = info->baseaddr + A7_BX_ADDR0 + (cpu << 2);
+
+	writel_relaxed(addr, baseaddr);
+}
+
+/**
+ * ve_spc_get_nr_cpus() - get number of cpus in a cluster
+ *
+ * @cluster: mpidr[15:8] bitfield describing cluster affinity level
+ *
+ * Return: > 0 number of cpus in the cluster
+ *         or 0 if cluster number invalid
+ */
+u32 ve_spc_get_nr_cpus(u32 cluster)
+{
+	u32 val;
+
+	if (cluster >= MAX_CLUSTERS)
+		return 0;
+
+	val = readl_relaxed(info->baseaddr + SYS_INFO);
+	val = cluster_is_a15(cluster) ? (val >> 16) : (val >> 20);
+	return val & 0xf;
+}
+
+/**
+ * ve_spc_powerdown()
+ *
+ * Function to enable/disable cluster powerdown. Not protected by locking
+ * since it might be used in code paths where normal cacheable locks are not
+ * working. Locking must be provided by the caller to ensure atomicity.
+ *
+ * @cluster: mpidr[15:8] bitfield describing cluster affinity level
+ * @enable: if true enables powerdown, if false disables it
+ */
+void ve_spc_powerdown(u32 cluster, bool enable)
+{
+	u32 pwdrn_reg;
+
+	if (cluster >= MAX_CLUSTERS)
+		return;
+
+	pwdrn_reg = cluster_is_a15(cluster) ? A15_PWRDN_EN : A7_PWRDN_EN;
+	writel_relaxed(enable, info->baseaddr + pwdrn_reg);
+}
+
+static const struct of_device_id ve_spc_ids[] __initconst = {
+	{ .compatible = "arm,vexpress-spc,v2p-ca15_a7" },
+	{ .compatible = "arm,vexpress-spc" },
+	{},
+};
+
+static int __init ve_spc_probe(void)
+{
+	int ret;
+	struct device_node *node = of_find_matching_node(NULL, ve_spc_ids);
+
+	if (!node)
+		return -ENODEV;
+
+	info = kzalloc(sizeof(*info), GFP_KERNEL);
+	if (!info) {
+		pr_err(SPCLOG "unable to allocate mem\n");
+		return -ENOMEM;
+	}
+
+	info->baseaddr = of_iomap(node, 0);
+	if (!info->baseaddr) {
+		pr_err(SPCLOG "unable to ioremap memory\n");
+		ret = -ENXIO;
+		goto mem_free;
+	}
+
+	info->a15_clusid = readl_relaxed(info->baseaddr + A15_CONF) & 0xf;
+
+	/*
+	 * Multi-cluster systems may need this data when non-coherent, during
+	 * cluster power-up/power-down. Make sure driver info reaches main
+	 * memory.
+	 */
+	sync_cache_w(info);
+	sync_cache_w(&info);
+	pr_info("vexpress-spc loaded at %p\n", info->baseaddr);
+	return 0;
+
+mem_free:
+	kfree(info);
+	return ret;
+}
+
+/**
+ * ve_spc_init()
+ *
+ * Function exported to manage pre early_initcall initialization.
+ * SPC code is needed very early in the boot process to bring CPUs out of
+ * reset and initialize power management back-end so an init interface is
+ * provided to platform code to allow early initialization. The init
+ * interface can be removed as soon as the DT layer and platform bus allow
+ * platform device creation and probing before SMP boot.
+ */
+int __init ve_spc_init(void)
+{
+	static int ve_spc_init_status __initdata = -EAGAIN;
+
+	if (ve_spc_init_status == -EAGAIN)
+		ve_spc_init_status = ve_spc_probe();
+
+	return ve_spc_init_status;
+}
+early_initcall(ve_spc_init);
diff --git a/include/linux/vexpress.h b/include/linux/vexpress.h
index 50368e0..d0106ef 100644
--- a/include/linux/vexpress.h
+++ b/include/linux/vexpress.h
@@ -132,4 +132,21 @@ void vexpress_clk_of_register_spc(void);
 void vexpress_clk_init(void __iomem *sp810_base);
 void vexpress_clk_of_init(void);
 
+/* SPC */
+
+#ifdef CONFIG_VEXPRESS_SPC
+int __init ve_spc_init(void);
+void ve_spc_global_wakeup_irq(bool set);
+void ve_spc_cpu_wakeup_irq(u32 cluster, u32 cpu, bool set);
+void ve_spc_set_resume_addr(u32 cluster, u32 cpu, u32 addr);
+u32 ve_spc_get_nr_cpus(u32 cluster);
+void ve_spc_powerdown(u32 cluster, bool enable);
+#else
+static inline int ve_spc_init(void) { return -ENODEV; }
+static inline void ve_spc_global_wakeup_irq(bool set) { }
+static inline void ve_spc_cpu_wakeup_irq(u32 cluster, u32 cpu, bool set) { }
+static inline void ve_spc_set_resume_addr(u32 cluster, u32 cpu, u32 addr) { }
+static inline u32 ve_spc_get_nr_cpus(u32 cluster) { return 0; }
+static inline void ve_spc_powerdown(u32 cluster, bool enable) { }
+#endif
 #endif
-- 
1.8.2.2




From Dave.Martin at arm.com  Tue Jul 16 12:16:43 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Tue, 16 Jul 2013 17:16:43 +0100
Subject: Can't get FIQ interrupt to work on i.mx233
In-Reply-To: <51E5322B.8080602@gmail.com>
References: <CAF-Ht3z3GQLwEWoB+UgOGepHfMFUD7pTRHfYWR9Ynk3rM4dD=Q@mail.gmail.com>
 <20130716081132.GB24642@n2100.arm.linux.org.uk>
 <51E5322B.8080602@gmail.com>
Message-ID: <20130716161643.GB3428@localhost.localdomain>

On Tue, Jul 16, 2013 at 08:44:43PM +0900, Juha Lumme wrote:
> Hi Russel,
> 
> Thanks for your reply.
> And thanks for pointing out the wrong instruction there with the ldr
> instruction.
> 
> However, unfortunately the code still doesn't seem to trigger
> anything (neither to clear the IRQ bit in the timer, nor the GPIO
> output).. It seems to me as if the handler never gets called. Is
> there a good way to confirm that any activity is actually triggered
> when timer3 reaches 0, and the IRQ bit is set to 1 ?
> 

A brutal, but simple, way to confirm that your handler is being called
is to try putting an infinite loop in there:

	b	.

If your board then locks up, the handler is almost certainly getting
called.

Cheers
---Dave


From sr at denx.de  Tue Jul 16 12:19:07 2013
From: sr at denx.de (Stefan Roese)
Date: Tue, 16 Jul 2013 18:19:07 +0200
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51E55AAE.3000209@ti.com>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de> <51DE87D3.5030600@ti.com>
 <51DEA7F1.1050902@denx.de> <51DEC2CE.70400@ti.com> <51DED076.3040000@denx.de>
 <51DEF0DE.4050607@denx.de> <51DFC92F.1050701@ti.com>
 <51DFDFD4.3040900@denx.de> <51E3AFF4.7060607@ti.com>
 <51E3B1B1.3060202@denx.de> <51E55AAE.3000209@ti.com>
Message-ID: <51E5727B.2010500@denx.de>

Hi Roger,

On 07/16/2013 04:37 PM, Roger Quadros wrote:
> On 07/15/2013 11:24 AM, Stefan Roese wrote:
>> On 07/15/2013 10:16 AM, Roger Quadros wrote:
>>>>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>>>>> as I don't have an external USB-ethernet adapter.
>>>>
>>>> Too bad. This difference in boards makes the tests a bit less
>>>> meaningful. Is there really no USB-ethernet adapter somewhere in your
>>>> department (perhaps a non-SMSC95xx might serve as well?)? I might
>>>> send/order you one if necessary. ;)
>>>
>>> Thanks for the offer :). I'll just get one for myself by today/tomorrow.
>>> The one available here uses this driver "drivers/net/usb/asix.c"
>>
>> Great.
>>
> 
> OK. Finally managed to reproduce the problem.

Ahh, great. Thanks for the effort.

> Don't know the root cause yet. Will need to investigate.

Thanks. Just let me know if I can be of any assistance (testing etc).

Cheers,
Stefan


From broonie at kernel.org  Tue Jul 16 12:19:40 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Jul 2013 17:19:40 +0100
Subject: [PATCH 0/2] regulator: palmas-pmic: doc: update device tree
 bindings
In-Reply-To: <20130716142710.GA15015@kahuna>
References: <1373984635-14958-1-git-send-email-nm@ti.com>
 <20130716142710.GA15015@kahuna>
Message-ID: <20130716161939.GR22506@sirena.org.uk>

On Tue, Jul 16, 2013 at 09:27:10AM -0500, Nishanth Menon wrote:
> On 09:23-20130716, Nishanth Menon wrote:

> > We seem to have a few missing updates to device tree bindings with the
> > latest set of changes getting merged in.

> Oops.. seems like I have an old mailID for Mark :(

I'll need the actual patches as well...
-------------- 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/20130716/36acce69/attachment-0001.sig>

From nsekhar at ti.com  Tue Jul 16 12:19:53 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 16 Jul 2013 21:49:53 +0530
Subject: [GIT PULL] DaVinci fixes for v3.11-rc2
Message-ID: <51E572A9.2080201@ti.com>

Hi Arnd, Olof,

Can you please pull the following fixes for v3.11-rc2?

Thanks,
Sekhar

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v3.11-rc2

for you to fetch changes up to cf690331642010a837c026088588761f61528ddf:

  ARM: davinci: defconfig: enable EDMA driver (2013-07-16 20:39:39 +0530)

----------------------------------------------------------------
DaVinci fixes for v3.11-rc2

The pull request includes fixes for sparse
warnings, defconfig changes to enable DMA
usage on peripherals and removal of a duplicated
include file.

----------------------------------------------------------------
Sekhar Nori (2):
      ARM: davinci: make file local variables static
      ARM: davinci: defconfig: enable EDMA driver

Wei Yongjun (1):
      ARM: edma: remove duplicated include from edma.c

 arch/arm/common/edma.c                  |    1 -
 arch/arm/configs/da8xx_omapl_defconfig  |    2 ++
 arch/arm/configs/davinci_all_defconfig  |    2 ++
 arch/arm/mach-davinci/board-dm365-evm.c |    2 +-
 arch/arm/mach-davinci/dm355.c           |    2 +-
 arch/arm/mach-davinci/dm365.c           |    2 +-
 6 files changed, 7 insertions(+), 4 deletions(-)


From gregkh at linuxfoundation.org  Tue Jul 16 02:41:07 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Mon, 15 Jul 2013 23:41:07 -0700
Subject: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner's
 Security ID fuses
In-Reply-To: <51E466A3.4010503@schinagl.nl>
References: <20130624160440.GA15201@kroah.com> <51C87DC7.50005@schinagl.nl>
 <20130624181509.GA8847@kroah.com> <51C8B84C.3020200@schinagl.nl>
 <20130624214615.GA17604@kroah.com> <51CAA709.4060801@schinagl.nl>
 <20130626175144.GC2222@kroah.com> <51D674BF.9030207@schinagl.nl>
 <20130706193646.GB9778@kroah.com> <51E466A3.4010503@schinagl.nl>
Message-ID: <20130716064107.GA10868@kroah.com>

On Mon, Jul 15, 2013 at 11:16:19PM +0200, Oliver Schinagl wrote:
> 
> With your latest patches for binary attributes and your blog post, I 
> thought that you want to create your binary attributes before the probe 
> function, to avoid the userspace race. To do that, we have two options, 
> create them in init (ugly?) or fill the .group member if available so it 
> gets automatically created from the register function.

Yes, the .group thing should be what is needed here.

> Well in my case, I'm using the module_platform_driver() macro which 
> expects the struct platform_driver. Platform_driver has a device_driver 
> member .driver where the .groups is located. Great, using that works and 
> we should have the sysfs entry race-free. However I don't know hot to 
> exchange data between that and the rest of my driver.
> 
> Before I used to_platform_device(kobj_to_dev(kobj)) as passed via the 
> .read function to obtain a platform_device where i could use 
> platform_get_drvdata on. All was good, but that doesn't fly now and my 
> knowledge is a bit short as to why.

I don't understand, why not use the platform device that was passed to
the binary attribute write function?

> The second method is finding some other shared structure given that we 
> get a platform_device in the probe function, yet I couldn't find 
> anything and this platform_device isn't the same as the one from the .read.

It should be, why isn't it?

> Of course using a global var bypasses this issue, but I'm sure it won't 
> pass review ;)

The platform device structure should have what you need, right?

> So using these new patches for binary attributes, how can I pass data 
> between my driver and the sysfs files using a platform_driver? Or are 
> other 'hacks' needed and using the .groups attribute from 
> platform_driver->device_driver->groups is really the wrong approach.
> 
> I did ask around and still haven't figured it out so far, so I do 
> apologize if you feel I'm wasting your precious time.

How is the platform device not the same thing that was passed to your
probe function?

> 
> Oliver

> /*
>  * Copyright (c) 2013 Oliver Schinagl
>  * http://www.linux-sunxi.org
>  *
>  * Oliver Schinagl <oliver at schinagl.nl>
>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License as published by
>  * the Free Software Foundation; either version 2 of the License, or
>  * (at your option) any later version.
>  *
>  * This 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.
>  *
>  * This driver exposes the Allwinner security ID, a 128 bit eeprom, in byte
>  * sized chunks.
>  */
> 
> #include <linux/compiler.h>
> #include <linux/device.h>
> #include <linux/err.h>
> #include <linux/export.h>
> #include <linux/fs.h>
> #include <linux/init.h>
> #include <linux/io.h>
> #include <linux/kernel.h>
> #include <linux/kobject.h>
> #include <linux/module.h>
> #include <linux/platform_device.h>
> #include <linux/random.h>
> #include <linux/sysfs.h>
> #include <linux/types.h>
> 
> #define DRV_NAME "sunxi-sid"
> 
> /* There are 4 32-bit keys */
> #define SID_KEYS 4
> /* Each key is 4 bytes long */
> #define SID_SIZE (SID_KEYS * 4)
> 
> /* We read the entire key, due to a 32 bit read alignment requirement. Since we
>  * want to return the requested byte, this resuls in somewhat slower code and
>  * uses 4 times more reads as needed but keeps code simpler. Since the SID is
>  * only very rarly probed, this is not really an issue.
>  */
> static u8 sunxi_sid_read_byte(const void __iomem *sid_reg_base,
> 			      const unsigned int offset)
> {
> 	u32 sid_key;
> 
> 	if (offset >= SID_SIZE)
> 		return 0;
> 
> 	sid_key = ioread32be(sid_reg_base + round_down(offset, 4));
> 	sid_key >>= (offset % 4) * 8;
> 
> 	return sid_key; /* Only return the last byte */
> }
> 
> static ssize_t eeprom_read(struct file *fd, struct kobject *kobj,
> 			struct bin_attribute *attr, char *buf,
> 			loff_t pos, size_t size)
> {
> 	struct platform_device *pdev;
> 	void __iomem *sid_reg_base;
> 	int i;
> 
> 	pdev = to_platform_device(kobj_to_dev(kobj));
> 	sid_reg_base = (void __iomem *)platform_get_drvdata(pdev);

Great, isn't that what you need?

> 	printk("0x%x, 0x%x 0x%x 0x%x\n", kobj, kobj_to_dev(kobj), pdev, sid_reg_base);
> 
> 	if (pos < 0 || pos >= SID_SIZE)
> 		return 0;
> 	if (size > SID_SIZE - pos)
> 		size = SID_SIZE - pos;
> 
> 	for (i = 0; i < size; i++)
> 		buf[i] = sunxi_sid_read_byte(sid_reg_base, pos + i);
> 
> 	return i;
> }

What are you missing in this function that you have in your probe
function?

This driver looks fine, what is not working properly?

totally confused,

greg k-h


From swarren at wwwdotorg.org  Tue Jul 16 12:21:31 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 10:21:31 -0600
Subject: [PATCH] ARM: tegra: remove tegra114-pluto.dts
In-Reply-To: <1373914547-6075-1-git-send-email-swarren@wwwdotorg.org>
References: <1373914547-6075-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <51E5730B.50705@wwwdotorg.org>

On 07/15/2013 12:55 PM, Stephen Warren wrote:
> Early upstream work on Tegra114 was performed on the Pluto board.
> However, it's not used any more, and the DT doesn't contain anything
> beyond a serial port, so the file isn't useful either. Remove it.

Applied to Tegra's for-3.12/dt branch.


From linux at arm.linux.org.uk  Tue Jul 16 12:32:43 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 16 Jul 2013 17:32:43 +0100
Subject: [PATCH RFC v2 0/14] Clean up debugging support
Message-ID: <20130716163243.GY21614@n2100.arm.linux.org.uk>

This is the second posting of this series, with a few additional patches
on top to go a little further.  Changes since the last posting:

- we now provide a couple of generic options to allow the 8250 and PL01x
  ports to be configured via Kconfig manually.  What this means is that
  I do not expect to see further entries to the debug menu for platforms
  which have PL01x or 8250 debug ports - use the generic options instead.

- I've converted a bunch of the dependencies to select statements here
  to clean things up a little more.

- Made the '8250 32-bit access size" option depend on a shift >= 2
  (it would be silly to do 32-bit accesses to byte offsets.)

- Made all 8250 options available to the user when 8250 support is
  selected, allowing full configuration of 8250 options.

- Removed DEBUG_ROCKCHIP_UART which wasn't doing anything after this
  cleanup.

- Converted Keystone, Davinci, and Spear to also use the generic 8250/PL01x
  code; these had their own private implementations of the same without
  using the generic versions for no reason that I could see.

The rest is the same boilerplate from last time with the exception of
the diffstat.

This patch series cleans up some aspects of the LL debug support by:
- Removing the multi-level choice madness
- Consolidating the 8250 debug UART support
- Consolidating the PL01x debug UART support

The differences between the various 8250 debug UART implementations are:
- Physical/Virtual addresses
- Register offset shift
- Access size
- Flow control

These are now parameterised in the Kconfig.  I've left OMAP because
that's a complex case, but it looks like it can be adapted to it if
some of the unnecessary complexity is eliminated.

Similar is done with the PL01x implementation, except a few complex
cases are left - automatic detection on Versatile Express, and the
Ux500 support which looks like it'll take some picking through header
files to work out what the base addresses are.

The approach I've taken is to consolidate without losing any information
- what that means it that the Kconfig parameters have rather a lot of
dependencies/defaults associated with them, and the main choice
statement keeps all its options.

Nevertheless, even avoiding the loss of information, I think the diffstat
is quite impressive:

 arch/arm/Kconfig.debug                             |  553 ++++++++++++++------
 arch/arm/include/asm/hardware/debug-8250.S         |   29 -
 arch/arm/include/debug/8250.S                      |   54 ++
 arch/arm/include/debug/8250_32.S                   |   27 -
 arch/arm/include/debug/bcm2835.S                   |   22 -
 arch/arm/include/debug/cns3xxx.S                   |   19 -
 arch/arm/include/debug/highbank.S                  |   17 -
 arch/arm/include/debug/keystone.S                  |   43 --
 arch/arm/include/debug/mvebu.S                     |   30 -
 arch/arm/include/debug/mxs.S                       |   27 -
 arch/arm/include/debug/nomadik.S                   |   20 -
 arch/arm/include/debug/nspire.S                    |   28 -
 arch/arm/include/debug/picoxcell.S                 |   19 -
 .../{asm/hardware/debug-pl01x.S => debug/pl01x.S}  |    9 +-
 arch/arm/include/debug/pxa.S                       |   33 --
 arch/arm/include/debug/rockchip.S                  |   42 --
 arch/arm/include/debug/socfpga.S                   |   21 -
 arch/arm/include/debug/sunxi.S                     |   27 -
 arch/arm/include/debug/u300.S                      |   18 -
 arch/arm/include/debug/ux500.S                     |    2 +-
 arch/arm/include/debug/vexpress.S                  |   48 +--
 arch/arm/mach-davinci/include/mach/debug-macro.S   |   65 ---
 arch/arm/mach-dove/include/mach/debug-macro.S      |   19 -
 arch/arm/mach-ebsa110/include/mach/debug-macro.S   |   22 -
 arch/arm/mach-ep93xx/include/mach/debug-macro.S    |   21 -
 .../arm/mach-footbridge/include/mach/debug-macro.S |   15 -
 arch/arm/mach-gemini/include/mach/debug-macro.S    |   21 -
 .../arm/mach-integrator/include/mach/debug-macro.S |   20 -
 arch/arm/mach-iop13xx/include/mach/debug-macro.S   |   24 -
 arch/arm/mach-iop32x/include/mach/debug-macro.S    |   21 -
 arch/arm/mach-iop33x/include/mach/debug-macro.S    |   22 -
 arch/arm/mach-ixp4xx/include/mach/debug-macro.S    |   26 -
 arch/arm/mach-kirkwood/include/mach/debug-macro.S  |   19 -
 arch/arm/mach-lpc32xx/include/mach/debug-macro.S   |   29 -
 arch/arm/mach-mv78xx0/include/mach/debug-macro.S   |   19 -
 arch/arm/mach-orion5x/include/mach/debug-macro.S   |   21 -
 arch/arm/mach-realview/include/mach/debug-macro.S  |   29 -
 arch/arm/mach-rpc/include/mach/debug-macro.S       |   23 -
 arch/arm/mach-spear/include/mach/debug-macro.S     |   36 --
 arch/arm/mach-spear/include/mach/spear.h           |    2 -
 arch/arm/mach-versatile/include/mach/debug-macro.S |   21 -
 41 files changed, 457 insertions(+), 1106 deletions(-)
 delete mode 100644 arch/arm/include/asm/hardware/debug-8250.S
 create mode 100644 arch/arm/include/debug/8250.S
 delete mode 100644 arch/arm/include/debug/8250_32.S
 delete mode 100644 arch/arm/include/debug/bcm2835.S
 delete mode 100644 arch/arm/include/debug/cns3xxx.S
 delete mode 100644 arch/arm/include/debug/highbank.S
 delete mode 100644 arch/arm/include/debug/keystone.S
 delete mode 100644 arch/arm/include/debug/mvebu.S
 delete mode 100644 arch/arm/include/debug/mxs.S
 delete mode 100644 arch/arm/include/debug/nomadik.S
 delete mode 100644 arch/arm/include/debug/nspire.S
 delete mode 100644 arch/arm/include/debug/picoxcell.S
 rename arch/arm/include/{asm/hardware/debug-pl01x.S => debug/pl01x.S} (78%)
 delete mode 100644 arch/arm/include/debug/pxa.S
 delete mode 100644 arch/arm/include/debug/rockchip.S
 delete mode 100644 arch/arm/include/debug/socfpga.S
 delete mode 100644 arch/arm/include/debug/sunxi.S
 delete mode 100644 arch/arm/include/debug/u300.S
 delete mode 100644 arch/arm/mach-davinci/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-dove/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ebsa110/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ep93xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-gemini/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-integrator/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop13xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop32x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop33x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ixp4xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-lpc32xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-mv78xx0/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-orion5x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-realview/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-rpc/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-spear/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-versatile/include/mach/debug-macro.S


From Dave.Martin at arm.com  Tue Jul 16 12:35:28 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Tue, 16 Jul 2013 17:35:28 +0100
Subject: [PATCH] ARM: locks: remove opencoded #16 for ticket shift
In-Reply-To: <1373894879-30559-1-git-send-email-will.deacon@arm.com>
References: <1373894879-30559-1-git-send-email-will.deacon@arm.com>
Message-ID: <20130716163528.GC3428@localhost.localdomain>

On Mon, Jul 15, 2013 at 02:27:59PM +0100, Will Deacon wrote:
> The ticket width of our spinlocks is defined by TICKET_SHIFT, so remove
> the opencoded #16 from the trylock implementation.
> 
> Signed-off-by: Will Deacon <will.deacon at arm.com>
> ---
>  arch/arm/include/asm/spinlock.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
> index f8b8965..fa3ccce 100644
> --- a/arch/arm/include/asm/spinlock.h
> +++ b/arch/arm/include/asm/spinlock.h
> @@ -104,11 +104,11 @@ static inline int arch_spin_trylock(arch_spinlock_t *lock)
>  		__asm__ __volatile__(
>  		"	ldrex	%0, [%3]\n"
>  		"	mov	%2, #0\n"
> -		"	subs	%1, %0, %0, ror #16\n"
> -		"	addeq	%0, %0, %4\n"
> +		"	subs	%1, %0, %0, ror %4\n"
> +		"	addeq	%0, %0, %5\n"

%5!  Argh.

>  		"	strexeq	%2, %0, [%3]"
>  		: "=&r" (slock), "=&r" (contended), "=r" (res)
> -		: "r" (&lock->slock), "I" (1 << TICKET_SHIFT)
> +		: "r" (&lock->slock), "I" (TICKET_SHIFT), "I" (1 << TICKET_SHIFT)

I guess that should work.

Strictly speaking, "M" is the right constraint to use for explicit shift
counts, though it won't make much difference in practice.

(Unless it ICEs the compiler for you ... seems to work on the 4.6.3
GCC I have here.)

Cheers
---Dave

>  		: "cc");
>  	} while (res);
>  
> -- 
> 1.8.2.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From rmk+kernel at arm.linux.org.uk  Tue Jul 16 12:34:11 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 16 Jul 2013 17:34:11 +0100
Subject: [PATCH RFC v2 01/14] ARM: debug: fix wording error in
 DEBUG_LL_UART_NONE option help
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <E1Uz8CZ-00047K-U8@rmk-PC.arm.linux.org.uk>

The DEBUG_LL_UART_NONE option was moved from the top of the list to
the bottom - unfortunately, it still referred to the options "below"
rather than "above".

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e401a76..7d8e9a9 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -579,7 +579,7 @@ choice
 		depends on !ARCH_MULTIPLATFORM
 		help
 		  Say Y here if your platform doesn't provide a UART option
-		  below. This relies on your platform choosing the right UART
+		  above. This relies on your platform choosing the right UART
 		  definition internally in order for low-level debugging to
 		  work.
 
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Tue Jul 16 12:35:12 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 16 Jul 2013 17:35:12 +0100
Subject: [PATCH RFC v2 02/14] ARM: debug: clean up low level kernel debugging
 selection
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <E1Uz8DY-00047S-1c@rmk-PC.arm.linux.org.uk>

It is silly to bury UART selection under multiple levels of choice
statements, where the top level choice statement will only list
about four entries when a single SoC is selected.  Move the UART
selection up into the top level choice statement as it was always
intended to be.

Acked-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug |  328 ++++++++++++++++++++++++++++--------------------
 1 files changed, 191 insertions(+), 137 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 7d8e9a9..608f0f9 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -376,12 +376,72 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on TI-NSPIRE CX models.
 
-	config DEBUG_OMAP2PLUS_UART
-		bool "Kernel low-level debugging messages via OMAP2PLUS UART"
+	config DEBUG_OMAP2UART1
+		bool "OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards)"
 		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
 		help
-		  Say Y here if you want kernel low-level debugging support
-		  on OMAP2PLUS based platforms.
+		  This covers at least h4, 2430sdp, 3430sdp, 3630sdp,
+		  omap3 torpedo and 3530 lv som.
+
+	config DEBUG_OMAP2UART2
+		bool "Kernel low-level debugging messages via OMAP2/3/4 UART2"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_OMAP2UART3
+		bool "Kernel low-level debugging messages via OMAP2 UART3 (n8x0)"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_OMAP3UART3
+		bool "Kernel low-level debugging messages via OMAP3 UART3 (most omap3 boards)"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+		help
+		  This covers at least cm_t3x, beagle, crane, devkit8000,
+		  igep00x0, ldp, n900, n9(50), pandora, overo, touchbook,
+		  and 3517evm.
+
+	config DEBUG_OMAP4UART3
+		bool "Kernel low-level debugging messages via OMAP4/5 UART3 (omap4 blaze, panda, omap5 sevm)"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_OMAP3UART4
+		bool "Kernel low-level debugging messages via OMAP36XX UART4"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_OMAP4UART4
+		bool "Kernel low-level debugging messages via OMAP4/5 UART4"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_TI81XXUART1
+		bool "Kernel low-level debugging messages via TI81XX UART1 (ti8148evm)"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_TI81XXUART2
+		bool "Kernel low-level debugging messages via TI81XX UART2"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_TI81XXUART3
+		bool "Kernel low-level debugging messages via TI81XX UART3 (ti8168evm)"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_AM33XXUART1
+		bool "Kernel low-level debugging messages via AM33XX UART1"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
+
+	config DEBUG_ZOOM_UART
+		bool "Kernel low-level debugging messages via Zoom2/3 UART"
+		depends on ARCH_OMAP2PLUS
+		select DEBUG_OMAP2PLUS_UART
 
 	config DEBUG_PICOXCELL_UART
 		depends on ARCH_PICOXCELL
@@ -413,9 +473,58 @@ choice
 		  their output to the standard serial port on the RealView
 		  PB1176 platform.
 
-	config DEBUG_ROCKCHIP_UART
-		bool "Kernel low-level debugging messages via Rockchip UART"
+	config DEBUG_RK29_UART0
+		bool "Kernel low-level debugging messages via Rockchip RK29 UART0"
+		depends on ARCH_ROCKCHIP
+		select DEBUG_ROCKCHIP_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Rockchip based platforms.
+
+	config DEBUG_RK29_UART1
+		bool "Kernel low-level debugging messages via Rockchip RK29 UART1"
+		depends on ARCH_ROCKCHIP
+		select DEBUG_ROCKCHIP_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Rockchip based platforms.
+
+	config DEBUG_RK29_UART2
+		bool "Kernel low-level debugging messages via Rockchip RK29 UART2"
+		depends on ARCH_ROCKCHIP
+		select DEBUG_ROCKCHIP_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Rockchip based platforms.
+
+	config DEBUG_RK3X_UART0
+		bool "Kernel low-level debugging messages via Rockchip RK3X UART0"
+		depends on ARCH_ROCKCHIP
+		select DEBUG_ROCKCHIP_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Rockchip based platforms.
+
+	config DEBUG_RK3X_UART1
+		bool "Kernel low-level debugging messages via Rockchip RK3X UART1"
 		depends on ARCH_ROCKCHIP
+		select DEBUG_ROCKCHIP_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Rockchip based platforms.
+
+	config DEBUG_RK3X_UART2
+		bool "Kernel low-level debugging messages via Rockchip RK3X UART2"
+		depends on ARCH_ROCKCHIP
+		select DEBUG_ROCKCHIP_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Rockchip based platforms.
+
+	config DEBUG_RK3X_UART3
+		bool "Kernel low-level debugging messages via Rockchip RK3X UART3"
+		depends on ARCH_ROCKCHIP
+		select DEBUG_ROCKCHIP_UART
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Rockchip based platforms.
@@ -489,9 +598,54 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on Allwinner A1X based platforms on the UART1.
 
-	config DEBUG_TEGRA_UART
+	config TEGRA_DEBUG_UART_AUTO_ODMDATA
+		bool "Kernel low-level debugging messages via Tegra UART via ODMDATA"
 		depends on ARCH_TEGRA
-		bool "Use Tegra UART for low-level debug"
+		select DEBUG_TEGRA_UART
+		help
+		  Automatically determines which UART to use for low-level
+		  debug based on the ODMDATA value. This value is part of
+		  the BCT, and is written to the boot memory device using
+		  nvflash, or other flashing tool.  When bits 19:18 are 3,
+		  then bits 17:15 indicate which UART to use; 0/1/2/3/4
+		  are UART A/B/C/D/E.
+
+	config TEGRA_DEBUG_UARTA
+		bool "Kernel low-level debugging messages via Tegra UART A"
+		depends on ARCH_TEGRA
+		select DEBUG_TEGRA_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Tegra based platforms.
+
+	config TEGRA_DEBUG_UARTB
+		bool "Kernel low-level debugging messages via Tegra UART B"
+		depends on ARCH_TEGRA
+		select DEBUG_TEGRA_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Tegra based platforms.
+
+	config TEGRA_DEBUG_UARTC
+		bool "Kernel low-level debugging messages via Tegra UART C"
+		depends on ARCH_TEGRA
+		select DEBUG_TEGRA_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Tegra based platforms.
+
+	config TEGRA_DEBUG_UARTD
+		bool "Kernel low-level debugging messages via Tegra UART D"
+		depends on ARCH_TEGRA
+		select DEBUG_TEGRA_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Tegra based platforms.
+
+	config TEGRA_DEBUG_UARTE
+		bool "Kernel low-level debugging messages via Tegra UART E"
+		depends on ARCH_TEGRA
+		select DEBUG_TEGRA_UART
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Tegra based platforms.
@@ -510,13 +664,25 @@ choice
 		  Say Y here if you want the debug print routines to direct
 		  their output to the uart1 port on SiRFmarco devices.
 
-	config DEBUG_STI_UART
+	config STIH41X_DEBUG_ASC2
+		bool "Use StiH415/416 ASC2 UART for low-level debug"
+		depends on ARCH_STI
+		select DEBUG_STI_UART
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on STiH415/416 based platforms like b2000, which has
+		  default UART wired up to ASC2.
+
+		  If unsure, say N.
+
+	config STIH41X_DEBUG_SBC_ASC1
+		bool "Use StiH415/416 SBC ASC1 UART for low-level debug"
 		depends on ARCH_STI
-		bool "Use StiH415/416 ASC for low-level debug"
+		select DEBUG_STI_UART
 		help
 		  Say Y here if you want kernel low-level debugging support
-		  on StiH415/416 based platforms like B2000, B2020.
-		  It support UART2 and SBC_UART1.
+		  on STiH415/416 based platforms like b2020. which has
+		  default UART wired up to SBC ASC1.
 
 		  If unsure, say N.
 
@@ -615,6 +781,10 @@ endchoice
 config DEBUG_EXYNOS_UART
 	bool
 
+config DEBUG_OMAP2PLUS_UART
+	bool
+	depends on ARCH_OMAP2PLUS
+
 config DEBUG_IMX_UART_PORT
 	int "i.MX Debug UART Port Selection" if DEBUG_IMX1_UART || \
 						DEBUG_IMX25_UART || \
@@ -631,133 +801,17 @@ config DEBUG_IMX_UART_PORT
 	  Choose UART port on which kernel low-level debug messages
 	  should be output.
 
-choice
-	prompt "Low-level debug console UART"
-	depends on DEBUG_OMAP2PLUS_UART
-
-	config DEBUG_OMAP2UART1
-		bool "OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards)"
-		help
-		  This covers at least h4, 2430sdp, 3430sdp, 3630sdp,
-		  omap3 torpedo and 3530 lv som.
-
-	config DEBUG_OMAP2UART2
-		bool "OMAP2/3/4 UART2"
-
-	config DEBUG_OMAP2UART3
-		bool "OMAP2 UART3 (n8x0)"
-
-	config DEBUG_OMAP3UART3
-		bool "OMAP3 UART3 (most omap3 boards)"
-		help
-		  This covers at least cm_t3x, beagle, crane, devkit8000,
-		  igep00x0, ldp, n900, n9(50), pandora, overo, touchbook,
-		  and 3517evm.
-
-	config DEBUG_OMAP4UART3
-		bool "OMAP4/5 UART3 (omap4 blaze, panda, omap5 sevm)"
-
-	config DEBUG_OMAP3UART4
-		bool "OMAP36XX UART4"
-
-	config DEBUG_OMAP4UART4
-		bool "OMAP4/5 UART4"
-
-	config DEBUG_TI81XXUART1
-		bool "TI81XX UART1 (ti8148evm)"
-
-	config DEBUG_TI81XXUART2
-		bool "TI81XX UART2"
-
-	config DEBUG_TI81XXUART3
-		bool "TI81XX UART3 (ti8168evm)"
-
-	config DEBUG_AM33XXUART1
-		bool "AM33XX UART1"
-
-	config DEBUG_ZOOM_UART
-		bool "Zoom2/3 UART"
-endchoice
-
-choice
-	prompt "Low-level debug console UART"
-	depends on DEBUG_ROCKCHIP_UART
-
-	config DEBUG_RK29_UART0
-		bool "RK29 UART0"
-
-	config DEBUG_RK29_UART1
-		bool "RK29 UART1"
-
-	config DEBUG_RK29_UART2
-		bool "RK29 UART2"
-
-	config DEBUG_RK3X_UART0
-		bool "RK3X UART0"
-
-	config DEBUG_RK3X_UART1
-		bool "RK3X UART1"
-
-	config DEBUG_RK3X_UART2
-		bool "RK3X UART2"
-
-	config DEBUG_RK3X_UART3
-		bool "RK3X UART3"
-endchoice
-
-choice
-	prompt "Low-level debug console UART"
-	depends on DEBUG_LL && DEBUG_TEGRA_UART
-
-	config TEGRA_DEBUG_UART_AUTO_ODMDATA
-	bool "Via ODMDATA"
-	help
-	  Automatically determines which UART to use for low-level debug based
-	  on the ODMDATA value. This value is part of the BCT, and is written
-	  to the boot memory device using nvflash, or other flashing tool.
-	  When bits 19:18 are 3, then bits 17:15 indicate which UART to use;
-	  0/1/2/3/4 are UART A/B/C/D/E.
-
-	config TEGRA_DEBUG_UARTA
-		bool "UART A"
-
-	config TEGRA_DEBUG_UARTB
-		bool "UART B"
-
-	config TEGRA_DEBUG_UARTC
-		bool "UART C"
-
-	config TEGRA_DEBUG_UARTD
-		bool "UART D"
-
-	config TEGRA_DEBUG_UARTE
-		bool "UART E"
-
-endchoice
-
-choice
-	prompt "Low-level debug console UART"
-	depends on DEBUG_LL && DEBUG_STI_UART
-
-	config STIH41X_DEBUG_ASC2
-		bool "ASC2 UART"
-		help
-		  Say Y here if you want kernel low-level debugging support
-		  on STiH415/416 based platforms like b2000, which has
-		  default UART wired up to ASC2.
-
-		  If unsure, say N.
-
-	config STIH41X_DEBUG_SBC_ASC1
-		bool "SBC ASC1 UART"
-		help
-		  Say Y here if you want kernel low-level debugging support
-		  on STiH415/416 based platforms like b2020. which has
-		  default UART wired up to SBC ASC1.
+config DEBUG_ROCKCHIP_UART
+	bool
+	depends on ARCH_ROCKCHIP
 
-		  If unsure, say N.
+config DEBUG_TEGRA_UART
+	bool
+	depends on ARCH_TEGRA
 
-endchoice
+config DEBUG_STI_UART
+	bool
+	depends on ARCH_STI
 
 config DEBUG_LL_INCLUDE
 	string
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Tue Jul 16 12:37:12 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 16 Jul 2013 17:37:12 +0100
Subject: [PATCH RFC v2 04/14] ARM: debug: provide 8250 debug uart register
 shift configuration option
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <E1Uz8FU-00047a-AB@rmk-PC.arm.linux.org.uk>

Move the definition of the UART register shift out of the platform
specific header file into the Kconfig files.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug                             |   28 ++++++++++++++++++-
 arch/arm/include/asm/hardware/debug-8250.S         |    4 +++
 arch/arm/include/debug/mvebu.S                     |    1 -
 arch/arm/include/debug/nspire.S                    |    1 -
 arch/arm/include/debug/pxa.S                       |    1 -
 arch/arm/include/debug/rockchip.S                  |    1 -
 arch/arm/include/debug/sunxi.S                     |    1 -
 arch/arm/mach-dove/include/mach/debug-macro.S      |    1 -
 arch/arm/mach-ebsa110/include/mach/debug-macro.S   |    1 -
 .../arm/mach-footbridge/include/mach/debug-macro.S |    1 -
 arch/arm/mach-gemini/include/mach/debug-macro.S    |    1 -
 arch/arm/mach-iop13xx/include/mach/debug-macro.S   |    1 -
 arch/arm/mach-iop32x/include/mach/debug-macro.S    |    1 -
 arch/arm/mach-iop33x/include/mach/debug-macro.S    |    1 -
 arch/arm/mach-ixp4xx/include/mach/debug-macro.S    |    1 -
 arch/arm/mach-kirkwood/include/mach/debug-macro.S  |    1 -
 arch/arm/mach-lpc32xx/include/mach/debug-macro.S   |    1 -
 arch/arm/mach-mv78xx0/include/mach/debug-macro.S   |    1 -
 arch/arm/mach-orion5x/include/mach/debug-macro.S   |    1 -
 arch/arm/mach-rpc/include/mach/debug-macro.S       |    1 -
 20 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 07ff149..5b44881 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -275,6 +275,7 @@ choice
 	config DEBUG_MMP_UART2
 		bool "Kernel low-level debugging message via MMP UART2"
 		depends on ARCH_MMP
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on MMP UART2.
@@ -282,6 +283,7 @@ choice
 	config DEBUG_MMP_UART3
 		bool "Kernel low-level debugging message via MMP UART3"
 		depends on ARCH_MMP
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on MMP UART3.
@@ -326,6 +328,7 @@ choice
 	config DEBUG_MVEBU_UART
 		bool "Kernel low-level debugging messages via MVEBU UART (old bootloaders)"
 		depends on ARCH_MVEBU
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on MVEBU based platforms.
@@ -344,6 +347,7 @@ choice
 	config DEBUG_MVEBU_UART_ALTERNATE
 		bool "Kernel low-level debugging messages via MVEBU UART (new bootloaders)"
 		depends on ARCH_MVEBU
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on MVEBU based platforms.
@@ -365,6 +369,7 @@ choice
 	config DEBUG_NSPIRE_CLASSIC_UART
 		bool "Kernel low-level debugging via TI-NSPIRE 8250 UART"
 		depends on ARCH_NSPIRE
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on TI-NSPIRE classic models.
@@ -453,6 +458,7 @@ choice
 	config DEBUG_PXA_UART1
 		depends on ARCH_PXA
 		bool "Use PXA UART1 for low-level debug"
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on PXA UART1.
@@ -477,6 +483,7 @@ choice
 		bool "Kernel low-level debugging messages via Rockchip RK29 UART0"
 		depends on ARCH_ROCKCHIP
 		select DEBUG_ROCKCHIP_UART
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Rockchip based platforms.
@@ -485,6 +492,7 @@ choice
 		bool "Kernel low-level debugging messages via Rockchip RK29 UART1"
 		depends on ARCH_ROCKCHIP
 		select DEBUG_ROCKCHIP_UART
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Rockchip based platforms.
@@ -493,6 +501,7 @@ choice
 		bool "Kernel low-level debugging messages via Rockchip RK29 UART2"
 		depends on ARCH_ROCKCHIP
 		select DEBUG_ROCKCHIP_UART
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Rockchip based platforms.
@@ -501,6 +510,7 @@ choice
 		bool "Kernel low-level debugging messages via Rockchip RK3X UART0"
 		depends on ARCH_ROCKCHIP
 		select DEBUG_ROCKCHIP_UART
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Rockchip based platforms.
@@ -509,6 +519,7 @@ choice
 		bool "Kernel low-level debugging messages via Rockchip RK3X UART1"
 		depends on ARCH_ROCKCHIP
 		select DEBUG_ROCKCHIP_UART
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Rockchip based platforms.
@@ -517,6 +528,7 @@ choice
 		bool "Kernel low-level debugging messages via Rockchip RK3X UART2"
 		depends on ARCH_ROCKCHIP
 		select DEBUG_ROCKCHIP_UART
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Rockchip based platforms.
@@ -525,6 +537,7 @@ choice
 		bool "Kernel low-level debugging messages via Rockchip RK3X UART3"
 		depends on ARCH_ROCKCHIP
 		select DEBUG_ROCKCHIP_UART
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Rockchip based platforms.
@@ -587,6 +600,7 @@ choice
 	config DEBUG_SUNXI_UART0
 		bool "Kernel low-level debugging messages via sunXi UART0"
 		depends on ARCH_SUNXI
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Allwinner A1X based platforms on the UART0.
@@ -594,6 +608,7 @@ choice
 	config DEBUG_SUNXI_UART1
 		bool "Kernel low-level debugging messages via sunXi UART1"
 		depends on ARCH_SUNXI
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Allwinner A1X based platforms on the UART1.
@@ -857,8 +872,17 @@ config DEBUG_LL_INCLUDE
 	default "mach/debug-macro.S"
 
 config DEBUG_UART_8250
-	def_bool ARCH_EBSA110 || (FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
-		ARCH_GEMINI || ARCH_RPC
+	def_bool ARCH_DOVE || ARCH_EBSA110 || \
+		(FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
+		ARCH_GEMINI || ARCH_IOP13XX || ARCH_IOP32X || \
+		ARCH_IOP33X || ARCH_IXP4XX || ARCH_KIRKWOOD || \
+		ARCH_LPC32XX || ARCH_MV78XX0 || ARCH_ORION5X || ARCH_RPC
+
+config DEBUG_UART_8250_SHIFT
+	int "Register offset shift for the 8250 debug UART"
+	depends on DEBUG_UART_8250
+	default 0 if FOOTBRIDGE || ARCH_IOP32X
+	default 2
 
 config DEBUG_UART_8250_FLOW_CONTROL
 	bool "Enable flow control for 8250 UART"
diff --git a/arch/arm/include/asm/hardware/debug-8250.S b/arch/arm/include/asm/hardware/debug-8250.S
index bca3045..a0e6e17 100644
--- a/arch/arm/include/asm/hardware/debug-8250.S
+++ b/arch/arm/include/asm/hardware/debug-8250.S
@@ -9,6 +9,10 @@
  */
 #include <linux/serial_reg.h>
 
+#ifndef UART_SHIFT
+#define UART_SHIFT CONFIG_DEBUG_UART_8250_SHIFT
+#endif
+
 		.macro	senduart,rd,rx
 		strb	\rd, [\rx, #UART_TX << UART_SHIFT]
 		.endm
diff --git a/arch/arm/include/debug/mvebu.S b/arch/arm/include/debug/mvebu.S
index 6517311..0d0d820 100644
--- a/arch/arm/include/debug/mvebu.S
+++ b/arch/arm/include/debug/mvebu.S
@@ -26,5 +26,4 @@
 	orr	\rv, \rv, #0x00012000
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/nspire.S b/arch/arm/include/debug/nspire.S
index 886fd27..8874636 100644
--- a/arch/arm/include/debug/nspire.S
+++ b/arch/arm/include/debug/nspire.S
@@ -23,6 +23,5 @@
 #endif
 
 #ifdef CONFIG_DEBUG_NSPIRE_CLASSIC_UART
-#define UART_SHIFT 2
 #include <asm/hardware/debug-8250.S>
 #endif
diff --git a/arch/arm/include/debug/pxa.S b/arch/arm/include/debug/pxa.S
index e1e795a..f10fba50 100644
--- a/arch/arm/include/debug/pxa.S
+++ b/arch/arm/include/debug/pxa.S
@@ -29,5 +29,4 @@
 	ldr	\rv, =PXA_UART_REG_VIRT_BASE
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/rockchip.S b/arch/arm/include/debug/rockchip.S
index cfd883e..80ae8ca 100644
--- a/arch/arm/include/debug/rockchip.S
+++ b/arch/arm/include/debug/rockchip.S
@@ -38,5 +38,4 @@
 	ldr	\rv, =ROCKCHIP_UART_DEBUG_VIRT_BASE
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/sunxi.S b/arch/arm/include/debug/sunxi.S
index 04eb56d..65d0981 100644
--- a/arch/arm/include/debug/sunxi.S
+++ b/arch/arm/include/debug/sunxi.S
@@ -23,5 +23,4 @@
 	ldr	\rv, =SUNXI_UART_DEBUG_VIRT_BASE
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-dove/include/mach/debug-macro.S b/arch/arm/mach-dove/include/mach/debug-macro.S
index 5929cbc..182a610 100644
--- a/arch/arm/mach-dove/include/mach/debug-macro.S
+++ b/arch/arm/mach-dove/include/mach/debug-macro.S
@@ -15,5 +15,4 @@
 	orr	\rv, \rv, #0x00012000
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-ebsa110/include/mach/debug-macro.S b/arch/arm/mach-ebsa110/include/mach/debug-macro.S
index 9b66e79..984f0fa 100644
--- a/arch/arm/mach-ebsa110/include/mach/debug-macro.S
+++ b/arch/arm/mach-ebsa110/include/mach/debug-macro.S
@@ -17,5 +17,4 @@
 		mov	\rp, \rv
 		.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-footbridge/include/mach/debug-macro.S b/arch/arm/mach-footbridge/include/mach/debug-macro.S
index 18130fe..a209936 100644
--- a/arch/arm/mach-footbridge/include/mach/debug-macro.S
+++ b/arch/arm/mach-footbridge/include/mach/debug-macro.S
@@ -22,7 +22,6 @@
 		orr	\rp, \rp, #0x7c000000	@ physical
 		.endm
 
-#define UART_SHIFT	0
 #include <asm/hardware/debug-8250.S>
 
 #else
diff --git a/arch/arm/mach-gemini/include/mach/debug-macro.S b/arch/arm/mach-gemini/include/mach/debug-macro.S
index cdee448..2d94ea4 100644
--- a/arch/arm/mach-gemini/include/mach/debug-macro.S
+++ b/arch/arm/mach-gemini/include/mach/debug-macro.S
@@ -16,5 +16,4 @@
 	ldr	\rv, =IO_ADDRESS(GEMINI_UART_BASE)	@ virtual
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop13xx/include/mach/debug-macro.S b/arch/arm/mach-iop13xx/include/mach/debug-macro.S
index d869a6f..4a776ca 100644
--- a/arch/arm/mach-iop13xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-iop13xx/include/mach/debug-macro.S
@@ -20,5 +20,4 @@
 	orr	\rp, \rp, #0x00d80000
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop32x/include/mach/debug-macro.S b/arch/arm/mach-iop32x/include/mach/debug-macro.S
index 363bdf9..a090573 100644
--- a/arch/arm/mach-iop32x/include/mach/debug-macro.S
+++ b/arch/arm/mach-iop32x/include/mach/debug-macro.S
@@ -17,5 +17,4 @@
 		mov	\rv, \rp
 		.endm
 
-#define UART_SHIFT	0
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop33x/include/mach/debug-macro.S b/arch/arm/mach-iop33x/include/mach/debug-macro.S
index 361be1f..894bf7c 100644
--- a/arch/arm/mach-iop33x/include/mach/debug-macro.S
+++ b/arch/arm/mach-iop33x/include/mach/debug-macro.S
@@ -18,5 +18,4 @@
 		orr	\rp, #0xff000000	@ physical
 		.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-ixp4xx/include/mach/debug-macro.S b/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
index ff686cb..403bd35 100644
--- a/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
@@ -22,5 +22,4 @@
                 orr     \rp, \rp, #0xc8000000	@ physical
                 .endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-kirkwood/include/mach/debug-macro.S b/arch/arm/mach-kirkwood/include/mach/debug-macro.S
index f785d40..51eee02 100644
--- a/arch/arm/mach-kirkwood/include/mach/debug-macro.S
+++ b/arch/arm/mach-kirkwood/include/mach/debug-macro.S
@@ -15,5 +15,4 @@
 	orr	\rv, \rv, #0x00012000
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-lpc32xx/include/mach/debug-macro.S b/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
index 351bd6c..11f986e 100644
--- a/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
@@ -25,5 +25,4 @@
 	ldrne	\rv, =0xF4090000
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S b/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
index a7df02b..0fce467 100644
--- a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
+++ b/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
@@ -15,5 +15,4 @@
 	orr	\rv, \rv, #0x00012000
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-orion5x/include/mach/debug-macro.S b/arch/arm/mach-orion5x/include/mach/debug-macro.S
index f340ed8..52f29ef 100644
--- a/arch/arm/mach-orion5x/include/mach/debug-macro.S
+++ b/arch/arm/mach-orion5x/include/mach/debug-macro.S
@@ -17,5 +17,4 @@
 	orr	\rv, \rv, #0x00012000
 	.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-rpc/include/mach/debug-macro.S b/arch/arm/mach-rpc/include/mach/debug-macro.S
index a92753d..fcb5450 100644
--- a/arch/arm/mach-rpc/include/mach/debug-macro.S
+++ b/arch/arm/mach-rpc/include/mach/debug-macro.S
@@ -18,5 +18,4 @@
 		orr	\rp, \rp, #0x03000000	@ physical
 		.endm
 
-#define UART_SHIFT	2
 #include <asm/hardware/debug-8250.S>
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Tue Jul 16 12:38:12 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 16 Jul 2013 17:38:12 +0100
Subject: [PATCH RFC v2 05/14] ARM: debug: provide 8250 debug uart phys/virt
 address configuration options
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <E1Uz8GS-00047e-E1@rmk-PC.arm.linux.org.uk>

Move the definition of the UART register addresses out of the platform
specific header file into the Kconfig files.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug                             |   59 ++++++++++++++++++++
 arch/arm/include/asm/hardware/debug-8250.S         |    9 +++-
 arch/arm/include/debug/mvebu.S                     |   16 -----
 arch/arm/include/debug/nspire.S                    |    4 +-
 arch/arm/include/debug/pxa.S                       |   19 ------
 arch/arm/include/debug/rockchip.S                  |   29 ----------
 arch/arm/include/debug/sunxi.S                     |   14 -----
 arch/arm/mach-dove/include/mach/debug-macro.S      |   10 ---
 arch/arm/mach-ebsa110/include/mach/debug-macro.S   |    7 --
 .../arm/mach-footbridge/include/mach/debug-macro.S |    9 ---
 arch/arm/mach-gemini/include/mach/debug-macro.S    |    7 --
 arch/arm/mach-iop13xx/include/mach/debug-macro.S   |   10 ---
 arch/arm/mach-iop32x/include/mach/debug-macro.S    |    7 --
 arch/arm/mach-iop33x/include/mach/debug-macro.S    |    8 ---
 arch/arm/mach-ixp4xx/include/mach/debug-macro.S    |   13 ----
 arch/arm/mach-kirkwood/include/mach/debug-macro.S  |   10 ---
 arch/arm/mach-lpc32xx/include/mach/debug-macro.S   |   10 ---
 arch/arm/mach-mv78xx0/include/mach/debug-macro.S   |   10 ---
 arch/arm/mach-orion5x/include/mach/debug-macro.S   |   10 ---
 arch/arm/mach-rpc/include/mach/debug-macro.S       |    8 ---
 20 files changed, 68 insertions(+), 201 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 5b44881..15ff64b 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -878,6 +878,65 @@ config DEBUG_UART_8250
 		ARCH_IOP33X || ARCH_IXP4XX || ARCH_KIRKWOOD || \
 		ARCH_LPC32XX || ARCH_MV78XX0 || ARCH_ORION5X || ARCH_RPC
 
+config DEBUG_UART_PHYS
+	hex "Physical base address of debug UART"
+	default 0x01c28000 if DEBUG_SUNXI_UART0
+	default 0x01c28400 if DEBUG_SUNXI_UART1
+	default 0x03010fe0 if ARCH_RPC
+	default 0x10124000 if DEBUG_RK3X_UART0
+	default 0x10126000 if DEBUG_RK3X_UART1
+	default 0x20060000 if DEBUG_RK29_UART0
+	default 0x20064000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
+	default 0x20068000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
+	default 0x40090000 if ARCH_LPC32XX
+	default 0x40100000 if DEBUG_PXA_UART1
+	default 0x42000000 if ARCH_GEMINI
+	default 0x7c0003f8 if FOOTBRIDGE
+	default 0x90020000 if DEBUG_NSPIRE_CLASSIC_UART
+	default 0xc8000000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
+	default 0xc8000003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
+	default 0xd0012000 if DEBUG_MVEBU_UART
+	default 0xd4017000 if DEBUG_MMP_UART2
+	default 0xd4018000 if DEBUG_MMP_UART3
+	default 0xf0000be0 if ARCH_EBSA110
+	default 0xf1012000 if DEBUG_MVEBU_UART_ALTERNATE
+	default 0xf1012000 if ARCH_DOVE || ARCH_KIRKWOOD || ARCH_MV78XX0 || \
+				ARCH_ORION5X
+	default 0xfe800000 if ARCH_IOP32X
+	default 0xffd82340 if ARCH_IOP13XX
+	default 0xfffff700 if ARCH_IOP33X
+	depends on DEBUG_UART_8250
+
+config DEBUG_UART_VIRT
+	hex "Virtual base address of debug UART"
+	default 0xe0010fe0 if ARCH_RPC
+	default 0xf0000be0 if ARCH_EBSA110
+	default 0xf1c28000 if DEBUG_SUNXI_UART0
+	default 0xf1c28400 if DEBUG_SUNXI_UART1
+	default 0xf2100000 if DEBUG_PXA_UART1
+	default 0xf4090000 if ARCH_LPC32XX
+	default 0xf4200000 if ARCH_GEMINI
+	default 0xfd012000 if ARCH_MV78XX0
+	default 0xfde12000 if ARCH_DOVE
+	default 0xfe012000 if ARCH_ORION5X
+	default 0xfe017000 if DEBUG_MMP_UART2
+	default 0xfe018000 if DEBUG_MMP_UART3
+	default 0xfe800000 if ARCH_IOP32X
+	default 0xfeb24000 if DEBUG_RK3X_UART0
+	default 0xfeb26000 if DEBUG_RK3X_UART1
+	default 0xfec12000 if DEBUG_MVEBU_UART || DEBUG_MVEBU_UART_ALTERNATE
+	default 0xfed60000 if DEBUG_RK29_UART0
+	default 0xfed64000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
+	default 0xfed68000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
+	default 0xfed12000 if ARCH_KIRKWOOD
+	default 0xfee003f8 if FOOTBRIDGE
+	default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART
+	default 0xfee82340 if ARCH_IOP13XX
+	default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
+	default 0xfef00003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
+	default 0xfefff700 if ARCH_IOP33X
+	depends on DEBUG_UART_8250
+
 config DEBUG_UART_8250_SHIFT
 	int "Register offset shift for the 8250 debug UART"
 	depends on DEBUG_UART_8250
diff --git a/arch/arm/include/asm/hardware/debug-8250.S b/arch/arm/include/asm/hardware/debug-8250.S
index a0e6e17..ea5f171 100644
--- a/arch/arm/include/asm/hardware/debug-8250.S
+++ b/arch/arm/include/asm/hardware/debug-8250.S
@@ -1,7 +1,7 @@
 /*
  * arch/arm/include/asm/hardware/debug-8250.S
  *
- *  Copyright (C) 1994-1999 Russell King
+ *  Copyright (C) 1994-2013 Russell King
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -9,6 +9,13 @@
  */
 #include <linux/serial_reg.h>
 
+#ifdef CONFIG_DEBUG_UART_PHYS
+		.macro	addruart, rp, rv, tmp
+		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
+		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
+		.endm
+#endif
+
 #ifndef UART_SHIFT
 #define UART_SHIFT CONFIG_DEBUG_UART_8250_SHIFT
 #endif
diff --git a/arch/arm/include/debug/mvebu.S b/arch/arm/include/debug/mvebu.S
index 0d0d820..6309be5 100644
--- a/arch/arm/include/debug/mvebu.S
+++ b/arch/arm/include/debug/mvebu.S
@@ -10,20 +10,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#ifdef CONFIG_DEBUG_MVEBU_UART_ALTERNATE
-#define ARMADA_370_XP_REGS_PHYS_BASE	0xf1000000
-#else
-#define ARMADA_370_XP_REGS_PHYS_BASE	0xd0000000
-#endif
-
-#define ARMADA_370_XP_REGS_VIRT_BASE	0xfec00000
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =ARMADA_370_XP_REGS_PHYS_BASE
-	ldr	\rv, =ARMADA_370_XP_REGS_VIRT_BASE
-	orr	\rp, \rp, #0x00012000
-	orr	\rv, \rv, #0x00012000
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/nspire.S b/arch/arm/include/debug/nspire.S
index 8874636..3e9329a 100644
--- a/arch/arm/include/debug/nspire.S
+++ b/arch/arm/include/debug/nspire.S
@@ -8,7 +8,7 @@
  * published by the Free Software Foundation.
  *
  */
-
+#ifdef CONFIG_DEBUG_NSPIRE_CX_UART
 #define NSPIRE_EARLY_UART_PHYS_BASE	   0x90020000
 #define NSPIRE_EARLY_UART_VIRT_BASE	   0xfee20000
 
@@ -17,8 +17,6 @@
 	ldr \rv, =(NSPIRE_EARLY_UART_VIRT_BASE)		@ virtual base address
 .endm
 
-
-#ifdef CONFIG_DEBUG_NSPIRE_CX_UART
 #include <asm/hardware/debug-pl01x.S>
 #endif
 
diff --git a/arch/arm/include/debug/pxa.S b/arch/arm/include/debug/pxa.S
index f10fba50..09e54f3 100644
--- a/arch/arm/include/debug/pxa.S
+++ b/arch/arm/include/debug/pxa.S
@@ -10,23 +10,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#if defined(CONFIG_DEBUG_PXA_UART1)
-#define PXA_UART_REG_PHYS_BASE	0x40100000
-#define PXA_UART_REG_VIRT_BASE	0xf2100000
-#elif defined(CONFIG_DEBUG_MMP_UART2)
-#define PXA_UART_REG_PHYS_BASE	0xd4017000
-#define PXA_UART_REG_VIRT_BASE	0xfe017000
-#elif defined(CONFIG_DEBUG_MMP_UART3)
-#define PXA_UART_REG_PHYS_BASE	0xd4018000
-#define PXA_UART_REG_VIRT_BASE	0xfe018000
-#else
-#error "Select uart for DEBUG_LL"
-#endif
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =PXA_UART_REG_PHYS_BASE
-	ldr	\rv, =PXA_UART_REG_VIRT_BASE
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/rockchip.S b/arch/arm/include/debug/rockchip.S
index 80ae8ca..3ad0238 100644
--- a/arch/arm/include/debug/rockchip.S
+++ b/arch/arm/include/debug/rockchip.S
@@ -9,33 +9,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#if defined(CONFIG_DEBUG_RK29_UART0)
-#define ROCKCHIP_UART_DEBUG_PHYS_BASE 0x20060000
-#define ROCKCHIP_UART_DEBUG_VIRT_BASE 0xfed60000
-#elif defined(CONFIG_DEBUG_RK29_UART1)
-#define ROCKCHIP_UART_DEBUG_PHYS_BASE 0x20064000
-#define ROCKCHIP_UART_DEBUG_VIRT_BASE 0xfed64000
-#elif defined(CONFIG_DEBUG_RK29_UART2)
-#define ROCKCHIP_UART_DEBUG_PHYS_BASE 0x20068000
-#define ROCKCHIP_UART_DEBUG_VIRT_BASE 0xfed68000
-#elif defined(CONFIG_DEBUG_RK3X_UART0)
-#define ROCKCHIP_UART_DEBUG_PHYS_BASE 0x10124000
-#define ROCKCHIP_UART_DEBUG_VIRT_BASE 0xfeb24000
-#elif defined(CONFIG_DEBUG_RK3X_UART1)
-#define ROCKCHIP_UART_DEBUG_PHYS_BASE 0x10126000
-#define ROCKCHIP_UART_DEBUG_VIRT_BASE 0xfeb26000
-#elif defined(CONFIG_DEBUG_RK3X_UART2)
-#define ROCKCHIP_UART_DEBUG_PHYS_BASE 0x20064000
-#define ROCKCHIP_UART_DEBUG_VIRT_BASE 0xfed64000
-#elif defined(CONFIG_DEBUG_RK3X_UART3)
-#define ROCKCHIP_UART_DEBUG_PHYS_BASE 0x20068000
-#define ROCKCHIP_UART_DEBUG_VIRT_BASE 0xfed68000
-#endif
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =ROCKCHIP_UART_DEBUG_PHYS_BASE
-	ldr	\rv, =ROCKCHIP_UART_DEBUG_VIRT_BASE
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/sunxi.S b/arch/arm/include/debug/sunxi.S
index 65d0981..4c3d89c 100644
--- a/arch/arm/include/debug/sunxi.S
+++ b/arch/arm/include/debug/sunxi.S
@@ -9,18 +9,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#if defined(CONFIG_DEBUG_SUNXI_UART0)
-#define SUNXI_UART_DEBUG_PHYS_BASE 0x01c28000
-#define SUNXI_UART_DEBUG_VIRT_BASE 0xf1c28000
-#elif defined(CONFIG_DEBUG_SUNXI_UART1)
-#define SUNXI_UART_DEBUG_PHYS_BASE 0x01c28400
-#define SUNXI_UART_DEBUG_VIRT_BASE 0xf1c28400
-#endif
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =SUNXI_UART_DEBUG_PHYS_BASE
-	ldr	\rv, =SUNXI_UART_DEBUG_VIRT_BASE
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-dove/include/mach/debug-macro.S b/arch/arm/mach-dove/include/mach/debug-macro.S
index 182a610..9b85a81 100644
--- a/arch/arm/mach-dove/include/mach/debug-macro.S
+++ b/arch/arm/mach-dove/include/mach/debug-macro.S
@@ -5,14 +5,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#include <mach/bridge-regs.h>
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =DOVE_SB_REGS_PHYS_BASE
-	ldr	\rv, =DOVE_SB_REGS_VIRT_BASE
-	orr	\rp, \rp, #0x00012000
-	orr	\rv, \rv, #0x00012000
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-ebsa110/include/mach/debug-macro.S b/arch/arm/mach-ebsa110/include/mach/debug-macro.S
index 984f0fa..0cea548 100644
--- a/arch/arm/mach-ebsa110/include/mach/debug-macro.S
+++ b/arch/arm/mach-ebsa110/include/mach/debug-macro.S
@@ -10,11 +10,4 @@
  * published by the Free Software Foundation.
  *
 **/
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0xf0000000
-		orr	\rp, \rp, #0x00000be0
-		mov	\rp, \rv
-		.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-footbridge/include/mach/debug-macro.S b/arch/arm/mach-footbridge/include/mach/debug-macro.S
index a209936..553c47d 100644
--- a/arch/arm/mach-footbridge/include/mach/debug-macro.S
+++ b/arch/arm/mach-footbridge/include/mach/debug-macro.S
@@ -14,16 +14,7 @@
 #include <asm/hardware/dec21285.h>
 
 #ifndef CONFIG_DEBUG_DC21285_PORT
-	/* For NetWinder debugging */
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0x000003f8
-		orr	\rv, \rp, #0xfe000000	@ virtual
-		orr	\rv, \rv, #0x00e00000	@ virtual
-		orr	\rp, \rp, #0x7c000000	@ physical
-		.endm
-
 #include <asm/hardware/debug-8250.S>
-
 #else
 #include <mach/hardware.h>
 	/* For EBSA285 debugging */
diff --git a/arch/arm/mach-gemini/include/mach/debug-macro.S b/arch/arm/mach-gemini/include/mach/debug-macro.S
index 2d94ea4..9dabd4b 100644
--- a/arch/arm/mach-gemini/include/mach/debug-macro.S
+++ b/arch/arm/mach-gemini/include/mach/debug-macro.S
@@ -9,11 +9,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-#include <mach/hardware.h>
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =GEMINI_UART_BASE			@ physical
-	ldr	\rv, =IO_ADDRESS(GEMINI_UART_BASE)	@ virtual
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop13xx/include/mach/debug-macro.S b/arch/arm/mach-iop13xx/include/mach/debug-macro.S
index 4a776ca..90b5e64 100644
--- a/arch/arm/mach-iop13xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-iop13xx/include/mach/debug-macro.S
@@ -10,14 +10,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-
-	.macro	addruart, rp, rv, tmp
-	mov	\rp, #0x00002300
-	orr	\rp, \rp, #0x00000040
-	orr	\rv, \rp, #0xfe000000	@ virtual
-	orr	\rv, \rv, #0x00e80000
-	orr	\rp, \rp, #0xff000000	@ physical
-	orr	\rp, \rp, #0x00d80000
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop32x/include/mach/debug-macro.S b/arch/arm/mach-iop32x/include/mach/debug-macro.S
index a090573..7ea745e 100644
--- a/arch/arm/mach-iop32x/include/mach/debug-macro.S
+++ b/arch/arm/mach-iop32x/include/mach/debug-macro.S
@@ -10,11 +10,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0xfe000000	@ physical as well as virtual
-		orr	\rp, \rp, #0x00800000	@ location of the UART
-		mov	\rv, \rp
-		.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop33x/include/mach/debug-macro.S b/arch/arm/mach-iop33x/include/mach/debug-macro.S
index 894bf7c..52781ae 100644
--- a/arch/arm/mach-iop33x/include/mach/debug-macro.S
+++ b/arch/arm/mach-iop33x/include/mach/debug-macro.S
@@ -10,12 +10,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0x00ff0000
-		orr	\rp, \rp, #0x0000f700
-		orr	\rv, #0xfe000000	@ virtual
-		orr	\rp, #0xff000000	@ physical
-		.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-ixp4xx/include/mach/debug-macro.S b/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
index 403bd35..ff706fa 100644
--- a/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
@@ -9,17 +9,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-                .macro  addruart, rp, rv, tmp
-#ifdef __ARMEB__
-                mov     \rp, #3         @ Uart regs are at off set of 3 if
-					@ byte writes used - Big Endian.
-#else
-		mov	\rp, #0
-#endif
-		orr	\rv, \rp, #0xfe000000	@ virtual
-		orr	\rv, \rv, #0x00f00000
-                orr     \rp, \rp, #0xc8000000	@ physical
-                .endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-kirkwood/include/mach/debug-macro.S b/arch/arm/mach-kirkwood/include/mach/debug-macro.S
index 51eee02..011ec25 100644
--- a/arch/arm/mach-kirkwood/include/mach/debug-macro.S
+++ b/arch/arm/mach-kirkwood/include/mach/debug-macro.S
@@ -5,14 +5,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#include <mach/bridge-regs.h>
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =KIRKWOOD_REGS_PHYS_BASE
-	ldr	\rv, =KIRKWOOD_REGS_VIRT_BASE
-	orr	\rp, \rp, #0x00012000
-	orr	\rv, \rv, #0x00012000
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-lpc32xx/include/mach/debug-macro.S b/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
index 11f986e..c7bb4bc 100644
--- a/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
@@ -15,14 +15,4 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  */
-
-/*
- * Debug output is hardcoded to standard UART 5
-*/
-
-	.macro	addruart, rp, rv, tmp
-	ldreq	\rp, =0x40090000
-	ldrne	\rv, =0xF4090000
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S b/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
index 0fce467..c8284a2 100644
--- a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
+++ b/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
@@ -5,14 +5,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#include <mach/mv78xx0.h>
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =MV78XX0_REGS_PHYS_BASE
-	ldr	\rv, =MV78XX0_REGS_VIRT_BASE
-	orr	\rp, \rp, #0x00012000
-	orr	\rv, \rv, #0x00012000
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-orion5x/include/mach/debug-macro.S b/arch/arm/mach-orion5x/include/mach/debug-macro.S
index 52f29ef..7489963 100644
--- a/arch/arm/mach-orion5x/include/mach/debug-macro.S
+++ b/arch/arm/mach-orion5x/include/mach/debug-macro.S
@@ -7,14 +7,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
 */
-
-#include <mach/orion5x.h>
-
-	.macro  addruart, rp, rv, tmp
-	ldr	\rp, =ORION5X_REGS_PHYS_BASE
-	ldr	\rv, =ORION5X_REGS_VIRT_BASE
-	orr	\rp, \rp, #0x00012000
-	orr	\rv, \rv, #0x00012000
-	.endm
-
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-rpc/include/mach/debug-macro.S b/arch/arm/mach-rpc/include/mach/debug-macro.S
index fcb5450..88a575e 100644
--- a/arch/arm/mach-rpc/include/mach/debug-macro.S
+++ b/arch/arm/mach-rpc/include/mach/debug-macro.S
@@ -10,12 +10,4 @@
  * published by the Free Software Foundation.
  *
 */
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0x00010000
-		orr	\rp, \rp, #0x00000fe0
-		orr	\rv, \rp, #0xe0000000	@ virtual
-		orr	\rp, \rp, #0x03000000	@ physical
-		.endm
-
 #include <asm/hardware/debug-8250.S>
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Tue Jul 16 12:36:12 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 16 Jul 2013 17:36:12 +0100
Subject: [PATCH RFC v2 03/14] ARM: debug: provide 8250 debug uart flow
 control configuration option
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <E1Uz8EW-00047W-6F@rmk-PC.arm.linux.org.uk>

Move the definition out of the machine class debug-macro.S header
into the Kconfig files.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug                             |    9 +++++++++
 arch/arm/include/asm/hardware/debug-8250.S         |    2 +-
 arch/arm/mach-ebsa110/include/mach/debug-macro.S   |    1 -
 .../arm/mach-footbridge/include/mach/debug-macro.S |    1 -
 arch/arm/mach-gemini/include/mach/debug-macro.S    |    1 -
 arch/arm/mach-rpc/include/mach/debug-macro.S       |    1 -
 6 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 608f0f9..07ff149 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -856,6 +856,15 @@ config DEBUG_LL_INCLUDE
 	default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
 	default "mach/debug-macro.S"
 
+config DEBUG_UART_8250
+	def_bool ARCH_EBSA110 || (FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
+		ARCH_GEMINI || ARCH_RPC
+
+config DEBUG_UART_8250_FLOW_CONTROL
+	bool "Enable flow control for 8250 UART"
+	depends on DEBUG_UART_8250
+	default y if ARCH_EBSA110 || FOOTBRIDGE || ARCH_GEMINI || ARCH_RPC
+
 config DEBUG_UNCOMPRESS
 	bool
 	default y if ARCH_MULTIPLATFORM && DEBUG_LL && \
diff --git a/arch/arm/include/asm/hardware/debug-8250.S b/arch/arm/include/asm/hardware/debug-8250.S
index 22c6892..bca3045 100644
--- a/arch/arm/include/asm/hardware/debug-8250.S
+++ b/arch/arm/include/asm/hardware/debug-8250.S
@@ -21,7 +21,7 @@
 		.endm
 
 		.macro	waituart,rd,rx
-#ifdef FLOW_CONTROL
+#ifdef CONFIG_DEBUG_UART_8250_FLOW_CONTROL
 1001:		ldrb	\rd, [\rx, #UART_MSR << UART_SHIFT]
 		tst	\rd, #UART_MSR_CTS
 		beq	1001b
diff --git a/arch/arm/mach-ebsa110/include/mach/debug-macro.S b/arch/arm/mach-ebsa110/include/mach/debug-macro.S
index bb02c05..9b66e79 100644
--- a/arch/arm/mach-ebsa110/include/mach/debug-macro.S
+++ b/arch/arm/mach-ebsa110/include/mach/debug-macro.S
@@ -18,5 +18,4 @@
 		.endm
 
 #define UART_SHIFT	2
-#define FLOW_CONTROL
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-footbridge/include/mach/debug-macro.S b/arch/arm/mach-footbridge/include/mach/debug-macro.S
index c169f0c..18130fe 100644
--- a/arch/arm/mach-footbridge/include/mach/debug-macro.S
+++ b/arch/arm/mach-footbridge/include/mach/debug-macro.S
@@ -23,7 +23,6 @@
 		.endm
 
 #define UART_SHIFT	0
-#define FLOW_CONTROL
 #include <asm/hardware/debug-8250.S>
 
 #else
diff --git a/arch/arm/mach-gemini/include/mach/debug-macro.S b/arch/arm/mach-gemini/include/mach/debug-macro.S
index 8376707..cdee448 100644
--- a/arch/arm/mach-gemini/include/mach/debug-macro.S
+++ b/arch/arm/mach-gemini/include/mach/debug-macro.S
@@ -17,5 +17,4 @@
 	.endm
 
 #define UART_SHIFT	2
-#define FLOW_CONTROL
 #include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-rpc/include/mach/debug-macro.S b/arch/arm/mach-rpc/include/mach/debug-macro.S
index 6d28cc9..a92753d 100644
--- a/arch/arm/mach-rpc/include/mach/debug-macro.S
+++ b/arch/arm/mach-rpc/include/mach/debug-macro.S
@@ -19,5 +19,4 @@
 		.endm
 
 #define UART_SHIFT	2
-#define FLOW_CONTROL
 #include <asm/hardware/debug-8250.S>
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Tue Jul 16 12:39:12 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 16 Jul 2013 17:39:12 +0100
Subject: [PATCH RFC v2 06/14] ARM: debug: move 8250 debug include into
 arch/arm/include/debug/
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <E1Uz8HQ-00047j-Hq@rmk-PC.arm.linux.org.uk>

Now that the 8250 debug include can stand alone without requiring
platforms to provide any macros, move it into the debug directory
so it can be directly included.  This allows us to get rid of a lot
of debug-macros include files.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug                             |   10 +----
 arch/arm/include/asm/hardware/debug-8250.S         |   40 --------------------
 arch/arm/include/debug/8250.S                      |   36 ++++++++++++++++++
 arch/arm/include/debug/mvebu.S                     |   13 ------
 arch/arm/include/debug/nspire.S                    |    4 --
 arch/arm/include/debug/pxa.S                       |   13 ------
 arch/arm/include/debug/rockchip.S                  |   12 ------
 arch/arm/include/debug/sunxi.S                     |   12 ------
 arch/arm/mach-dove/include/mach/debug-macro.S      |    8 ----
 arch/arm/mach-ebsa110/include/mach/debug-macro.S   |   13 ------
 .../arm/mach-footbridge/include/mach/debug-macro.S |    4 --
 arch/arm/mach-gemini/include/mach/debug-macro.S    |   12 ------
 arch/arm/mach-iop13xx/include/mach/debug-macro.S   |   13 ------
 arch/arm/mach-iop32x/include/mach/debug-macro.S    |   13 ------
 arch/arm/mach-iop33x/include/mach/debug-macro.S    |   13 ------
 arch/arm/mach-ixp4xx/include/mach/debug-macro.S    |   12 ------
 arch/arm/mach-kirkwood/include/mach/debug-macro.S  |    8 ----
 arch/arm/mach-lpc32xx/include/mach/debug-macro.S   |   18 ---------
 arch/arm/mach-mv78xx0/include/mach/debug-macro.S   |    8 ----
 arch/arm/mach-orion5x/include/mach/debug-macro.S   |   10 -----
 arch/arm/mach-rpc/include/mach/debug-macro.S       |   13 ------
 21 files changed, 38 insertions(+), 247 deletions(-)
 delete mode 100644 arch/arm/include/asm/hardware/debug-8250.S
 create mode 100644 arch/arm/include/debug/8250.S
 delete mode 100644 arch/arm/include/debug/mvebu.S
 delete mode 100644 arch/arm/include/debug/pxa.S
 delete mode 100644 arch/arm/include/debug/rockchip.S
 delete mode 100644 arch/arm/include/debug/sunxi.S
 delete mode 100644 arch/arm/mach-dove/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ebsa110/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-gemini/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop13xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop32x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop33x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ixp4xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-lpc32xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-mv78xx0/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-orion5x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-rpc/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 15ff64b..0ba460d 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -830,6 +830,7 @@ config DEBUG_STI_UART
 
 config DEBUG_LL_INCLUDE
 	string
+	default "debug/8250.S" if DEBUG_UART_8250
 	default "debug/bcm2835.S" if DEBUG_BCM2835
 	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
 	default "debug/exynos.S" if DEBUG_EXYNOS_UART
@@ -846,21 +847,14 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX6SL_UART
 	default "debug/keystone.S" if DEBUG_KEYSTONE_UART0 || \
 				      DEBUG_KEYSTONE_UART1
-	default "debug/mvebu.S" if DEBUG_MVEBU_UART || \
-				   DEBUG_MVEBU_UART_ALTERNATE
 	default "debug/mxs.S" if DEBUG_IMX23_UART || DEBUG_IMX28_UART
 	default "debug/nomadik.S" if DEBUG_NOMADIK_UART
-	default "debug/nspire.S" if 	DEBUG_NSPIRE_CX_UART || \
-					DEBUG_NSPIRE_CLASSIC_UART
+	default "debug/nspire.S" if DEBUG_NSPIRE_CX_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 	default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
-	default "debug/pxa.S" if DEBUG_PXA_UART1 || DEBUG_MMP_UART2 || \
-				 DEBUG_MMP_UART3
-	default "debug/rockchip.S" if DEBUG_ROCKCHIP_UART
 	default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
 	default "debug/socfpga.S" if DEBUG_SOCFPGA_UART
 	default "debug/sti.S" if DEBUG_STI_UART
-	default "debug/sunxi.S" if DEBUG_SUNXI_UART0 || DEBUG_SUNXI_UART1
 	default "debug/tegra.S" if DEBUG_TEGRA_UART
 	default "debug/u300.S" if DEBUG_U300_UART
 	default "debug/ux500.S" if DEBUG_UX500_UART
diff --git a/arch/arm/include/asm/hardware/debug-8250.S b/arch/arm/include/asm/hardware/debug-8250.S
deleted file mode 100644
index ea5f171..0000000
--- a/arch/arm/include/asm/hardware/debug-8250.S
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- * arch/arm/include/asm/hardware/debug-8250.S
- *
- *  Copyright (C) 1994-2013 Russell King
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <linux/serial_reg.h>
-
-#ifdef CONFIG_DEBUG_UART_PHYS
-		.macro	addruart, rp, rv, tmp
-		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
-		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
-		.endm
-#endif
-
-#ifndef UART_SHIFT
-#define UART_SHIFT CONFIG_DEBUG_UART_8250_SHIFT
-#endif
-
-		.macro	senduart,rd,rx
-		strb	\rd, [\rx, #UART_TX << UART_SHIFT]
-		.endm
-
-		.macro	busyuart,rd,rx
-1002:		ldrb	\rd, [\rx, #UART_LSR << UART_SHIFT]
-		and	\rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
-		teq	\rd, #UART_LSR_TEMT | UART_LSR_THRE
-		bne	1002b
-		.endm
-
-		.macro	waituart,rd,rx
-#ifdef CONFIG_DEBUG_UART_8250_FLOW_CONTROL
-1001:		ldrb	\rd, [\rx, #UART_MSR << UART_SHIFT]
-		tst	\rd, #UART_MSR_CTS
-		beq	1001b
-#endif
-		.endm
diff --git a/arch/arm/include/debug/8250.S b/arch/arm/include/debug/8250.S
new file mode 100644
index 0000000..92cab39
--- /dev/null
+++ b/arch/arm/include/debug/8250.S
@@ -0,0 +1,36 @@
+/*
+ * arch/arm/include/debug/8250.S
+ *
+ *  Copyright (C) 1994-2013 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/serial_reg.h>
+
+		.macro	addruart, rp, rv, tmp
+		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
+		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
+		.endm
+
+#define UART_SHIFT CONFIG_DEBUG_UART_8250_SHIFT
+
+		.macro	senduart,rd,rx
+		strb	\rd, [\rx, #UART_TX << UART_SHIFT]
+		.endm
+
+		.macro	busyuart,rd,rx
+1002:		ldrb	\rd, [\rx, #UART_LSR << UART_SHIFT]
+		and	\rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
+		teq	\rd, #UART_LSR_TEMT | UART_LSR_THRE
+		bne	1002b
+		.endm
+
+		.macro	waituart,rd,rx
+#ifdef CONFIG_DEBUG_UART_8250_FLOW_CONTROL
+1001:		ldrb	\rd, [\rx, #UART_MSR << UART_SHIFT]
+		tst	\rd, #UART_MSR_CTS
+		beq	1001b
+#endif
+		.endm
diff --git a/arch/arm/include/debug/mvebu.S b/arch/arm/include/debug/mvebu.S
deleted file mode 100644
index 6309be5..0000000
--- a/arch/arm/include/debug/mvebu.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/*
- * Early serial output macro for Marvell  SoC
- *
- * Copyright (C) 2012 Marvell
- *
- * Lior Amsalem <alior at marvell.com>
- * Gregory Clement <gregory.clement at free-electrons.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/nspire.S b/arch/arm/include/debug/nspire.S
index 3e9329a..9c2fbec 100644
--- a/arch/arm/include/debug/nspire.S
+++ b/arch/arm/include/debug/nspire.S
@@ -19,7 +19,3 @@
 
 #include <asm/hardware/debug-pl01x.S>
 #endif
-
-#ifdef CONFIG_DEBUG_NSPIRE_CLASSIC_UART
-#include <asm/hardware/debug-8250.S>
-#endif
diff --git a/arch/arm/include/debug/pxa.S b/arch/arm/include/debug/pxa.S
deleted file mode 100644
index 09e54f3..0000000
--- a/arch/arm/include/debug/pxa.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/*
- * Early serial output macro for Marvell PXA/MMP SoC
- *
- * Copyright (C) 1994-1999 Russell King
- * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * Copyright (C) 2013 Haojian Zhuang
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/rockchip.S b/arch/arm/include/debug/rockchip.S
deleted file mode 100644
index 3ad0238..0000000
--- a/arch/arm/include/debug/rockchip.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/*
- * Early serial output macro for Rockchip SoCs
- *
- * Copyright (C) 2012 Maxime Ripard
- *
- * Maxime Ripard <maxime.ripard at free-electrons.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/include/debug/sunxi.S b/arch/arm/include/debug/sunxi.S
deleted file mode 100644
index 4c3d89c..0000000
--- a/arch/arm/include/debug/sunxi.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/*
- * Early serial output macro for Allwinner A1X SoCs
- *
- * Copyright (C) 2012 Maxime Ripard
- *
- * Maxime Ripard <maxime.ripard at free-electrons.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-dove/include/mach/debug-macro.S b/arch/arm/mach-dove/include/mach/debug-macro.S
deleted file mode 100644
index 9b85a81..0000000
--- a/arch/arm/mach-dove/include/mach/debug-macro.S
+++ /dev/null
@@ -1,8 +0,0 @@
-/*
- * arch/arm/mach-dove/include/mach/debug-macro.S
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-ebsa110/include/mach/debug-macro.S b/arch/arm/mach-ebsa110/include/mach/debug-macro.S
deleted file mode 100644
index 0cea548..0000000
--- a/arch/arm/mach-ebsa110/include/mach/debug-macro.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/* arch/arm/mach-ebsa110/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
-**/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-footbridge/include/mach/debug-macro.S b/arch/arm/mach-footbridge/include/mach/debug-macro.S
index 553c47d..02247f3 100644
--- a/arch/arm/mach-footbridge/include/mach/debug-macro.S
+++ b/arch/arm/mach-footbridge/include/mach/debug-macro.S
@@ -13,9 +13,6 @@
 
 #include <asm/hardware/dec21285.h>
 
-#ifndef CONFIG_DEBUG_DC21285_PORT
-#include <asm/hardware/debug-8250.S>
-#else
 #include <mach/hardware.h>
 	/* For EBSA285 debugging */
 		.equ	dc21285_high, ARMCSR_BASE & 0xff000000
@@ -43,4 +40,3 @@
 
 		.macro	waituart,rd,rx
 		.endm
-#endif
diff --git a/arch/arm/mach-gemini/include/mach/debug-macro.S b/arch/arm/mach-gemini/include/mach/debug-macro.S
deleted file mode 100644
index 9dabd4b..0000000
--- a/arch/arm/mach-gemini/include/mach/debug-macro.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/*
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Copyright (C) 2001-2006 Storlink, Corp.
- *  Copyright (C) 2008-2009 Paulius Zaleckas <paulius.zaleckas at teltonika.lt>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop13xx/include/mach/debug-macro.S b/arch/arm/mach-iop13xx/include/mach/debug-macro.S
deleted file mode 100644
index 90b5e64..0000000
--- a/arch/arm/mach-iop13xx/include/mach/debug-macro.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/*
- * arch/arm/mach-iop13xx/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- * Copyright (C) 1994-1999 Russell King
- * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop32x/include/mach/debug-macro.S b/arch/arm/mach-iop32x/include/mach/debug-macro.S
deleted file mode 100644
index 7ea745e..0000000
--- a/arch/arm/mach-iop32x/include/mach/debug-macro.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/*
- * arch/arm/mach-iop32x/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- * Copyright (C) 1994-1999 Russell King
- * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-iop33x/include/mach/debug-macro.S b/arch/arm/mach-iop33x/include/mach/debug-macro.S
deleted file mode 100644
index 52781ae..0000000
--- a/arch/arm/mach-iop33x/include/mach/debug-macro.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/*
- * arch/arm/mach-iop33x/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- * Copyright (C) 1994-1999 Russell King
- * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-ixp4xx/include/mach/debug-macro.S b/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
deleted file mode 100644
index ff706fa..0000000
--- a/arch/arm/mach-ixp4xx/include/mach/debug-macro.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/* arch/arm/mach-ixp4xx/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-kirkwood/include/mach/debug-macro.S b/arch/arm/mach-kirkwood/include/mach/debug-macro.S
deleted file mode 100644
index 011ec25..0000000
--- a/arch/arm/mach-kirkwood/include/mach/debug-macro.S
+++ /dev/null
@@ -1,8 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/include/mach/debug-macro.S
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-lpc32xx/include/mach/debug-macro.S b/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
deleted file mode 100644
index c7bb4bc..0000000
--- a/arch/arm/mach-lpc32xx/include/mach/debug-macro.S
+++ /dev/null
@@ -1,18 +0,0 @@
-/*
- * arch/arm/mach-lpc32xx/include/mach/debug-macro.S
- *
- * Author: Kevin Wells <kevin.wells at nxp.com>
- *
- * Copyright (C) 2010 NXP Semiconductors
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This 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.
- */
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S b/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
deleted file mode 100644
index c8284a2..0000000
--- a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S
+++ /dev/null
@@ -1,8 +0,0 @@
-/*
- * arch/arm/mach-mv78xx0/include/mach/debug-macro.S
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-orion5x/include/mach/debug-macro.S b/arch/arm/mach-orion5x/include/mach/debug-macro.S
deleted file mode 100644
index 7489963..0000000
--- a/arch/arm/mach-orion5x/include/mach/debug-macro.S
+++ /dev/null
@@ -1,10 +0,0 @@
-/*
- * arch/arm/mach-orion5x/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-rpc/include/mach/debug-macro.S b/arch/arm/mach-rpc/include/mach/debug-macro.S
deleted file mode 100644
index 88a575e..0000000
--- a/arch/arm/mach-rpc/include/mach/debug-macro.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/* arch/arm/mach-rpc/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
-*/
-#include <asm/hardware/debug-8250.S>
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Tue Jul 16 12:40:12 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 16 Jul 2013 17:40:12 +0100
Subject: [PATCH RFC v2 07/14] ARM: debug: add support for word accesses to
 debug/8250.S
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <E1Uz8IO-00047s-LQ@rmk-PC.arm.linux.org.uk>

Add 32-bit word access support to debug/8250.S and convert Picoxcell
and SoCFPGA to this.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug             |   14 ++++++++++++--
 arch/arm/include/debug/8250.S      |   24 +++++++++++++++++++++---
 arch/arm/include/debug/8250_32.S   |   27 ---------------------------
 arch/arm/include/debug/picoxcell.S |   19 -------------------
 arch/arm/include/debug/socfpga.S   |   21 ---------------------
 5 files changed, 33 insertions(+), 72 deletions(-)
 delete mode 100644 arch/arm/include/debug/8250_32.S
 delete mode 100644 arch/arm/include/debug/picoxcell.S
 delete mode 100644 arch/arm/include/debug/socfpga.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 0ba460d..0e8202e 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -451,6 +451,7 @@ choice
 	config DEBUG_PICOXCELL_UART
 		depends on ARCH_PICOXCELL
 		bool "Use PicoXcell UART for low-level debug"
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on PicoXcell based platforms.
@@ -593,6 +594,7 @@ choice
 	config DEBUG_SOCFPGA_UART
 		depends on ARCH_SOCFPGA
 		bool "Use SOCFPGA UART for low-level debug"
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on SOCFPGA based platforms.
@@ -851,9 +853,7 @@ config DEBUG_LL_INCLUDE
 	default "debug/nomadik.S" if DEBUG_NOMADIK_UART
 	default "debug/nspire.S" if DEBUG_NSPIRE_CX_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
-	default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
 	default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
-	default "debug/socfpga.S" if DEBUG_SOCFPGA_UART
 	default "debug/sti.S" if DEBUG_STI_UART
 	default "debug/tegra.S" if DEBUG_TEGRA_UART
 	default "debug/u300.S" if DEBUG_U300_UART
@@ -886,6 +886,7 @@ config DEBUG_UART_PHYS
 	default 0x40100000 if DEBUG_PXA_UART1
 	default 0x42000000 if ARCH_GEMINI
 	default 0x7c0003f8 if FOOTBRIDGE
+	default 0x80230000 if DEBUG_PICOXCELL_UART
 	default 0x90020000 if DEBUG_NSPIRE_CLASSIC_UART
 	default 0xc8000000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
 	default 0xc8000003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
@@ -897,6 +898,7 @@ config DEBUG_UART_PHYS
 	default 0xf1012000 if ARCH_DOVE || ARCH_KIRKWOOD || ARCH_MV78XX0 || \
 				ARCH_ORION5X
 	default 0xfe800000 if ARCH_IOP32X
+	default 0xffc02000 if DEBUG_SOCFPGA_UART
 	default 0xffd82340 if ARCH_IOP13XX
 	default 0xfffff700 if ARCH_IOP33X
 	depends on DEBUG_UART_8250
@@ -915,6 +917,7 @@ config DEBUG_UART_VIRT
 	default 0xfe012000 if ARCH_ORION5X
 	default 0xfe017000 if DEBUG_MMP_UART2
 	default 0xfe018000 if DEBUG_MMP_UART3
+	default 0xfe230000 if DEBUG_PICOXCELL_UART
 	default 0xfe800000 if ARCH_IOP32X
 	default 0xfeb24000 if DEBUG_RK3X_UART0
 	default 0xfeb26000 if DEBUG_RK3X_UART1
@@ -922,6 +925,7 @@ config DEBUG_UART_VIRT
 	default 0xfed60000 if DEBUG_RK29_UART0
 	default 0xfed64000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
 	default 0xfed68000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
+	default 0xfec02000 if DEBUG_SOCFPGA_UART
 	default 0xfed12000 if ARCH_KIRKWOOD
 	default 0xfee003f8 if FOOTBRIDGE
 	default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART
@@ -937,6 +941,12 @@ config DEBUG_UART_8250_SHIFT
 	default 0 if FOOTBRIDGE || ARCH_IOP32X
 	default 2
 
+config DEBUG_UART_8250_WORD
+	bool "Use 32-bit accesses for 8250 UART"
+	depends on DEBUG_UART_8250
+	depends on DEBUG_UART_8250_SHIFT >= 2
+	default y if DEBUG_PICOXCELL_UART || DEBUG_SOCFPGA_UART
+
 config DEBUG_UART_8250_FLOW_CONTROL
 	bool "Enable flow control for 8250 UART"
 	depends on DEBUG_UART_8250
diff --git a/arch/arm/include/debug/8250.S b/arch/arm/include/debug/8250.S
index 92cab39..7a2baf9 100644
--- a/arch/arm/include/debug/8250.S
+++ b/arch/arm/include/debug/8250.S
@@ -14,14 +14,32 @@
 		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
 		.endm
 
+#ifdef CONFIG_DEBUG_UART_8250_WORD
+		.macro	store, rd, rx:vararg
+		str	\rd, \rx
+		.endm
+
+		.macro	load, rd, rx:vararg
+		ldr	\rd, \rx
+		.endm
+#else
+		.macro	store, rd, rx:vararg
+		strb	\rd, \rx
+		.endm
+
+		.macro	load, rd, rx:vararg
+		ldrb	\rd, \rx
+		.endm
+#endif
+
 #define UART_SHIFT CONFIG_DEBUG_UART_8250_SHIFT
 
 		.macro	senduart,rd,rx
-		strb	\rd, [\rx, #UART_TX << UART_SHIFT]
+		store	\rd, [\rx, #UART_TX << UART_SHIFT]
 		.endm
 
 		.macro	busyuart,rd,rx
-1002:		ldrb	\rd, [\rx, #UART_LSR << UART_SHIFT]
+1002:		load	\rd, [\rx, #UART_LSR << UART_SHIFT]
 		and	\rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
 		teq	\rd, #UART_LSR_TEMT | UART_LSR_THRE
 		bne	1002b
@@ -29,7 +47,7 @@
 
 		.macro	waituart,rd,rx
 #ifdef CONFIG_DEBUG_UART_8250_FLOW_CONTROL
-1001:		ldrb	\rd, [\rx, #UART_MSR << UART_SHIFT]
+1001:		load	\rd, [\rx, #UART_MSR << UART_SHIFT]
 		tst	\rd, #UART_MSR_CTS
 		beq	1001b
 #endif
diff --git a/arch/arm/include/debug/8250_32.S b/arch/arm/include/debug/8250_32.S
deleted file mode 100644
index 8db01ee..0000000
--- a/arch/arm/include/debug/8250_32.S
+++ /dev/null
@@ -1,27 +0,0 @@
-/*
- * Copyright (c) 2011 Picochip Ltd., Jamie Iles
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * Derived from arch/arm/mach-davinci/include/mach/debug-macro.S to use 32-bit
- * accesses to the 8250.
- */
-
-#include <linux/serial_reg.h>
-
-		.macro	senduart,rd,rx
-		str	\rd, [\rx, #UART_TX << UART_SHIFT]
-		.endm
-
-		.macro	busyuart,rd,rx
-1002:		ldr	\rd, [\rx, #UART_LSR << UART_SHIFT]
-		and	\rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
-		teq	\rd, #UART_LSR_TEMT | UART_LSR_THRE
-		bne	1002b
-		.endm
-
-		/* The UART's don't have any flow control IO's wired up. */
-		.macro	waituart,rd,rx
-		.endm
diff --git a/arch/arm/include/debug/picoxcell.S b/arch/arm/include/debug/picoxcell.S
deleted file mode 100644
index bc1f07c..0000000
--- a/arch/arm/include/debug/picoxcell.S
+++ /dev/null
@@ -1,19 +0,0 @@
-/*
- * Copyright (c) 2011 Picochip Ltd., Jamie Iles
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#define UART_SHIFT 2
-#define PICOXCELL_UART1_BASE		0x80230000
-#define PHYS_TO_IO(x)			(((x) & 0x00ffffff) | 0xfe000000)
-
-		.macro	addruart, rp, rv, tmp
-		ldr	\rv, =PHYS_TO_IO(PICOXCELL_UART1_BASE)
-		ldr	\rp, =PICOXCELL_UART1_BASE
-		.endm
-
-#include "8250_32.S"
diff --git a/arch/arm/include/debug/socfpga.S b/arch/arm/include/debug/socfpga.S
deleted file mode 100644
index 966b2f9..0000000
--- a/arch/arm/include/debug/socfpga.S
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#define UART_SHIFT 2
-#define DEBUG_LL_UART_OFFSET	0x00002000
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #DEBUG_LL_UART_OFFSET
-		orr	\rp, \rp, #0x00c00000
-		orr	\rv, \rp, #0xfe000000	@ virtual base
-		orr	\rp, \rp, #0xff000000	@ physical base
-		.endm
-
-#include "8250_32.S"
-
-- 
1.7.4.4



From nm at ti.com  Tue Jul 16 12:41:10 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 16 Jul 2013 11:41:10 -0500
Subject: [PATCH V2 2/2] regulator: palmas-pmic: doc: remove ti,tstep
In-Reply-To: <1373992870-20725-1-git-send-email-nm@ti.com>
References: <20130716161939.GR22506@sirena.org.uk>
 <1373992870-20725-1-git-send-email-nm@ti.com>
Message-ID: <1373992870-20725-3-git-send-email-nm@ti.com>

commit 28d1e8cd671a53d6b4f967abbbc2a55f7bd333f6
(regulator: palma: add ramp delay support through regulator constraints)

Removed the regulator's ti,step option from driver without updating the
documentation.

So, remove from documentation and example as well.

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../devicetree/bindings/regulator/palmas-pmic.txt  |    2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index 04d67f0..30b0581 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -33,7 +33,6 @@ Optional nodes:
 	       ti,roof-floor - control voltage selection by pin(boolean)
 	       ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
 	       2 - eco, 3 - forced pwm
-	       ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 2.5mV/us
 	       ti,smps-range - OTP has the wrong range set for the hardware so override
 	       0 - low range, 1 - high range.
 
@@ -59,7 +58,6 @@ pmic {
 			ti,warm-reset;
 			ti,roof-floor;
 			ti,mode-sleep = <0>;
-			ti,tstep = <0>;
 			ti,smps-range = <1>;
 		};
 
-- 
1.7.9.5



From nm at ti.com  Tue Jul 16 12:41:09 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 16 Jul 2013 11:41:09 -0500
Subject: [PATCH V2 1/2] regulator: palmas-pmic: doc: fix typo for sleep-mode
In-Reply-To: <1373992870-20725-1-git-send-email-nm@ti.com>
References: <20130716161939.GR22506@sirena.org.uk>
 <1373992870-20725-1-git-send-email-nm@ti.com>
Message-ID: <1373992870-20725-2-git-send-email-nm@ti.com>

commit 3c870e3f9d9d98f1ab98614b3b1fd5c79287d361
(regulator: palmas: Change the DT node property names to follow the convention)

Missed updating mode-sleep from sleep-mode. Fix the same.

Documentation example seems proper for this property.

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../devicetree/bindings/regulator/palmas-pmic.txt  |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index d5a3086..04d67f0 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -31,7 +31,7 @@ Optional nodes:
 	       Optional sub-node properties:
 	       ti,warm-reset - maintain voltage during warm reset(boolean)
 	       ti,roof-floor - control voltage selection by pin(boolean)
-	       ti,sleep-mode - mode to adopt in pmic sleep 0 - off, 1 - auto,
+	       ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
 	       2 - eco, 3 - forced pwm
 	       ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 2.5mV/us
 	       ti,smps-range - OTP has the wrong range set for the hardware so override
-- 
1.7.9.5



From nm at ti.com  Tue Jul 16 12:41:08 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 16 Jul 2013 11:41:08 -0500
Subject: [PATCH V2 0/2] regulator: palmas-pmic: doc: update device tree
 bindings
In-Reply-To: <20130716161939.GR22506@sirena.org.uk>
References: <20130716161939.GR22506@sirena.org.uk>
Message-ID: <1373992870-20725-1-git-send-email-nm@ti.com>

We seem to have a few missing updates to device tree bindings with the
latest set of changes getting merged in.

Changes since V1:
	Apologies on the spam, looks like I got the wrong mail ID first time around :(
	minor commit message cleanups

V1: http://marc.info/?l=linux-doc&m=137398467901450&w=2

Based on v3.11-rc1 tag

Nishanth Menon (2):
  regulator: palmas-pmic: doc: fix typo for sleep-mode
  regulator: palmas-pmic: doc: remove ti,tstep

 .../devicetree/bindings/regulator/palmas-pmic.txt  |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

-- 
1.7.9.5

Regards,
Nishanth Menon


From rmk+kernel at arm.linux.org.uk  Tue Jul 16 12:41:12 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 16 Jul 2013 17:41:12 +0100
Subject: [PATCH RFC v2 08/14] ARM: debug: provide PL01x debug uart phys/virt
 address configuration options
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <E1Uz8JM-00047w-PP@rmk-PC.arm.linux.org.uk>

Move the definition of the UART register addresses out of the platform
specific header files into the Kconfig files.

Acked-by: Ryan Mallon <rmallon at gmail.com>
Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug                             |   54 ++++++++++++++++++--
 arch/arm/include/asm/hardware/debug-pl01x.S        |    7 +++
 arch/arm/include/debug/bcm2835.S                   |    9 ---
 arch/arm/include/debug/cns3xxx.S                   |    7 ---
 arch/arm/include/debug/highbank.S                  |    6 --
 arch/arm/include/debug/mxs.S                       |   14 -----
 arch/arm/include/debug/nomadik.S                   |    8 ---
 arch/arm/include/debug/nspire.S                    |   10 ----
 arch/arm/include/debug/u300.S                      |   11 ----
 arch/arm/include/debug/vexpress.S                  |   46 -----------------
 arch/arm/mach-ep93xx/include/mach/debug-macro.S    |    9 ---
 .../arm/mach-integrator/include/mach/debug-macro.S |    7 ---
 arch/arm/mach-realview/include/mach/debug-macro.S  |   17 ------
 arch/arm/mach-versatile/include/mach/debug-macro.S |    8 ---
 14 files changed, 57 insertions(+), 156 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 0e8202e..f1cde5e 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -92,6 +92,7 @@ choice
 	config DEBUG_BCM2835
 		bool "Kernel low-level debugging on BCM2835 PL011 UART"
 		depends on ARCH_BCM2835
+		select DEBUG_UART_PL01X
 
 	config DEBUG_CLPS711X_UART1
 		bool "Kernel low-level debugging messages via UART1"
@@ -110,6 +111,7 @@ choice
 	config DEBUG_CNS3XXX
 		bool "Kernel Kernel low-level debugging on Cavium Networks CNS3xxx"
 		depends on ARCH_CNS3XXX
+		select DEBUG_UART_PL01X
 		help
 		  Say Y here if you want the debug print routines to direct
                   their output to the CNS3xxx UART0.
@@ -177,6 +179,7 @@ choice
 	config DEBUG_HIGHBANK_UART
 		bool "Kernel low-level debugging messages via Highbank UART"
 		depends on ARCH_HIGHBANK
+		select DEBUG_UART_PL01X
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the UART on Highbank based devices.
@@ -191,6 +194,7 @@ choice
 	config DEBUG_IMX23_UART
 		bool "i.MX23 Debug UART"
 		depends on SOC_IMX23
+		select DEBUG_UART_PL01X
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on i.MX23.
@@ -212,6 +216,7 @@ choice
 	config DEBUG_IMX28_UART
 		bool "i.MX28 Debug UART"
 		depends on SOC_IMX28
+		select DEBUG_UART_PL01X
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on i.MX28.
@@ -362,6 +367,7 @@ choice
 	config DEBUG_NOMADIK_UART
 		bool "Kernel low-level debugging messages via NOMADIK UART"
 		depends on ARCH_NOMADIK
+		select DEBUG_UART_PL01X
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on NOMADIK based platforms.
@@ -377,6 +383,7 @@ choice
 	config DEBUG_NSPIRE_CX_UART
 		bool "Kernel low-level debugging via TI-NSPIRE PL011 UART"
 		depends on ARCH_NSPIRE
+		select DEBUG_UART_PL01X
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on TI-NSPIRE CX models.
@@ -467,6 +474,7 @@ choice
 	config DEBUG_REALVIEW_STD_PORT
 		bool "RealView Default UART"
 		depends on ARCH_REALVIEW
+		select DEBUG_UART_PL01X
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the serial port on RealView EB, PB11MP, PBA8
@@ -475,6 +483,7 @@ choice
 	config DEBUG_REALVIEW_PB1176_PORT
 		bool "RealView PB1176 UART"
 		depends on MACH_REALVIEW_PB1176
+		select DEBUG_UART_PL01X
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the standard serial port on the RealView
@@ -706,6 +715,7 @@ choice
 	config DEBUG_U300_UART
 		bool "Kernel low-level debugging messages via U300 UART0"
 		depends on ARCH_U300
+		select DEBUG_UART_PL01X
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to the uart port on U300 devices.
@@ -731,6 +741,7 @@ choice
 	config DEBUG_VEXPRESS_UART0_CA9
 		bool "Use PL011 UART0 at 0x10009000 (V2P-CA9 core tile)"
 		depends on ARCH_VEXPRESS
+		select DEBUG_UART_PL01X
 		help
 		  This option selects UART0 at 0x10009000. Except for custom models,
 		  this applies only to the V2P-CA9 tile.
@@ -738,6 +749,7 @@ choice
 	config DEBUG_VEXPRESS_UART0_RS1
 		bool "Use PL011 UART0 at 0x1c090000 (RS1 complaint tiles)"
 		depends on ARCH_VEXPRESS
+		select DEBUG_UART_PL01X
 		help
 		  This option selects UART0 at 0x1c090000. This applies to most
 		  of the tiles using the RS1 memory map, including all new A-class
@@ -746,6 +758,7 @@ choice
 	config DEBUG_VEXPRESS_UART0_CRX
 		bool "Use PL011 UART0 at 0xb0090000 (Cortex-R compliant tiles)"
 		depends on ARCH_VEXPRESS && !MMU
+		select DEBUG_UART_PL01X
 		help
 		  This option selects UART0 at 0xb0090000. This is appropriate for
 		  Cortex-R series tiles and SMMs, such as Cortex-R5 and Cortex-R7
@@ -865,6 +878,11 @@ config DEBUG_LL_INCLUDE
 	default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
 	default "mach/debug-macro.S"
 
+config DEBUG_UART_PL01X
+	def_bool ARCH_EP93XX || \
+		ARCH_INTEGRATOR || \
+		ARCH_VERSATILE
+
 config DEBUG_UART_8250
 	def_bool ARCH_DOVE || ARCH_EBSA110 || \
 		(FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
@@ -877,17 +895,30 @@ config DEBUG_UART_PHYS
 	default 0x01c28000 if DEBUG_SUNXI_UART0
 	default 0x01c28400 if DEBUG_SUNXI_UART1
 	default 0x03010fe0 if ARCH_RPC
+	default 0x10009000 if DEBUG_REALVIEW_STD_PORT || DEBUG_CNS3XXX || \
+				DEBUG_VEXPRESS_UART0_CA9
+	default 0x1010c000 if DEBUG_REALVIEW_PB1176_PORT
 	default 0x10124000 if DEBUG_RK3X_UART0
 	default 0x10126000 if DEBUG_RK3X_UART1
+	default 0x101f1000 if ARCH_VERSATILE
+	default 0x101fb000 if DEBUG_NOMADIK_UART
+	default 0x16000000 if ARCH_INTEGRATOR
+	default 0x1c090000 if DEBUG_VEXPRESS_UART0_RS1
 	default 0x20060000 if DEBUG_RK29_UART0
 	default 0x20064000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
 	default 0x20068000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
+	default 0x20201000 if DEBUG_BCM2835
 	default 0x40090000 if ARCH_LPC32XX
 	default 0x40100000 if DEBUG_PXA_UART1
 	default 0x42000000 if ARCH_GEMINI
 	default 0x7c0003f8 if FOOTBRIDGE
 	default 0x80230000 if DEBUG_PICOXCELL_UART
-	default 0x90020000 if DEBUG_NSPIRE_CLASSIC_UART
+	default 0x80070000 if DEBUG_IMX23_UART
+	default 0x80074000 if DEBUG_IMX28_UART
+	default 0x808c0000 if ARCH_EP93XX
+	default 0x90020000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART
+	default 0xb0090000 if DEBUG_VEXPRESS_UART0_CRX
+	default 0xc0013000 if DEBUG_U300_UART
 	default 0xc8000000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
 	default 0xc8000003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
 	default 0xd0012000 if DEBUG_MVEBU_UART
@@ -900,23 +931,34 @@ config DEBUG_UART_PHYS
 	default 0xfe800000 if ARCH_IOP32X
 	default 0xffc02000 if DEBUG_SOCFPGA_UART
 	default 0xffd82340 if ARCH_IOP13XX
+	default 0xfff36000 if DEBUG_HIGHBANK_UART
 	default 0xfffff700 if ARCH_IOP33X
-	depends on DEBUG_UART_8250
+	depends on DEBUG_UART_8250 || DEBUG_UART_PL01X
 
 config DEBUG_UART_VIRT
 	hex "Virtual base address of debug UART"
 	default 0xe0010fe0 if ARCH_RPC
 	default 0xf0000be0 if ARCH_EBSA110
+	default 0xf0009000 if DEBUG_CNS3XXX
+	default 0xf01fb000 if DEBUG_NOMADIK_UART
+	default 0xf0201000 if DEBUG_BCM2835
+	default 0xf11f1000 if ARCH_VERSATILE
+	default 0xf1600000 if ARCH_INTEGRATOR
 	default 0xf1c28000 if DEBUG_SUNXI_UART0
 	default 0xf1c28400 if DEBUG_SUNXI_UART1
 	default 0xf2100000 if DEBUG_PXA_UART1
 	default 0xf4090000 if ARCH_LPC32XX
 	default 0xf4200000 if ARCH_GEMINI
+	default 0xf8009000 if DEBUG_VEXPRESS_UART0_CA9
+	default 0xf8090000 if DEBUG_VEXPRESS_UART0_RS1
+	default 0xfb009000 if DEBUG_REALVIEW_STD_PORT
+	default 0xfb10c000 if DEBUG_REALVIEW_PB1176_PORT
 	default 0xfd012000 if ARCH_MV78XX0
 	default 0xfde12000 if ARCH_DOVE
 	default 0xfe012000 if ARCH_ORION5X
 	default 0xfe017000 if DEBUG_MMP_UART2
 	default 0xfe018000 if DEBUG_MMP_UART3
+	default 0xfe100000 if DEBUG_IMX23_UART || DEBUG_IMX28_UART
 	default 0xfe230000 if DEBUG_PICOXCELL_UART
 	default 0xfe800000 if ARCH_IOP32X
 	default 0xfeb24000 if DEBUG_RK3X_UART0
@@ -927,13 +969,17 @@ config DEBUG_UART_VIRT
 	default 0xfed68000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
 	default 0xfec02000 if DEBUG_SOCFPGA_UART
 	default 0xfed12000 if ARCH_KIRKWOOD
+	default 0xfedc0000 if ARCH_EP93XX
 	default 0xfee003f8 if FOOTBRIDGE
-	default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART
+	default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART
+	default 0xfee36000 if DEBUG_HIGHBANK_UART
 	default 0xfee82340 if ARCH_IOP13XX
 	default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
 	default 0xfef00003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
 	default 0xfefff700 if ARCH_IOP33X
-	depends on DEBUG_UART_8250
+	default 0xff003000 if DEBUG_U300_UART
+	default DEBUG_UART_PHYS if !MMU
+	depends on DEBUG_UART_8250 || DEBUG_UART_PL01X
 
 config DEBUG_UART_8250_SHIFT
 	int "Register offset shift for the 8250 debug UART"
diff --git a/arch/arm/include/asm/hardware/debug-pl01x.S b/arch/arm/include/asm/hardware/debug-pl01x.S
index f9fd083..9d1e286 100644
--- a/arch/arm/include/asm/hardware/debug-pl01x.S
+++ b/arch/arm/include/asm/hardware/debug-pl01x.S
@@ -12,6 +12,13 @@
 */
 #include <linux/amba/serial.h>
 
+#ifdef CONFIG_DEBUG_UART_PHYS
+		.macro	addruart, rp, rv, tmp
+		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
+		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
+		.endm
+#endif
+
 		.macro	senduart,rd,rx
 		strb	\rd, [\rx, #UART01x_DR]
 		.endm
diff --git a/arch/arm/include/debug/bcm2835.S b/arch/arm/include/debug/bcm2835.S
index aed9199..726e069 100644
--- a/arch/arm/include/debug/bcm2835.S
+++ b/arch/arm/include/debug/bcm2835.S
@@ -10,13 +10,4 @@
  * published by the Free Software Foundation.
  *
  */
-
-#define BCM2835_DEBUG_PHYS 0x20201000
-#define BCM2835_DEBUG_VIRT 0xf0201000
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rp, =BCM2835_DEBUG_PHYS
-	ldr	\rv, =BCM2835_DEBUG_VIRT
-	.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/cns3xxx.S b/arch/arm/include/debug/cns3xxx.S
index d04c150..2d5fb51 100644
--- a/arch/arm/include/debug/cns3xxx.S
+++ b/arch/arm/include/debug/cns3xxx.S
@@ -9,11 +9,4 @@
  * it under the terms of the GNU General Public License, Version 2, as
  * published by the Free Software Foundation.
  */
-
-		.macro	addruart,rp,rv,tmp
-		mov	\rp, #0x00009000
-		orr	\rv, \rp, #0xf0000000	@ virtual base
-		orr	\rp, \rp, #0x10000000
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/highbank.S b/arch/arm/include/debug/highbank.S
index 8cad432..3c6f63f 100644
--- a/arch/arm/include/debug/highbank.S
+++ b/arch/arm/include/debug/highbank.S
@@ -8,10 +8,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-
-		.macro	addruart,rp,rv,tmp
-		ldr	\rv, =0xfee36000
-		ldr	\rp, =0xfff36000
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/mxs.S b/arch/arm/include/debug/mxs.S
index d869515..8a10ed2 100644
--- a/arch/arm/include/debug/mxs.S
+++ b/arch/arm/include/debug/mxs.S
@@ -10,18 +10,4 @@
  * published by the Free Software Foundation.
  *
  */
-
-#ifdef CONFIG_DEBUG_IMX23_UART
-#define UART_PADDR	0x80070000
-#elif defined (CONFIG_DEBUG_IMX28_UART)
-#define UART_PADDR	0x80074000
-#endif
-
-#define UART_VADDR	0xfe100000
-
-		.macro	addruart, rp, rv, tmp
-		ldr	\rp, =UART_PADDR	@ physical
-		ldr	\rv, =UART_VADDR	@ virtual
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/nomadik.S b/arch/arm/include/debug/nomadik.S
index 7354179..a6d238e 100644
--- a/arch/arm/include/debug/nomadik.S
+++ b/arch/arm/include/debug/nomadik.S
@@ -9,12 +9,4 @@
  * published by the Free Software Foundation.
  *
 */
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0x00100000
-		add	\rp, \rp, #0x000fb000
-		add	\rv, \rp, #0xf0000000	@ virtual base
-		add	\rp, \rp, #0x10000000	@ physical base address
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/nspire.S b/arch/arm/include/debug/nspire.S
index 9c2fbec..fc17e50 100644
--- a/arch/arm/include/debug/nspire.S
+++ b/arch/arm/include/debug/nspire.S
@@ -8,14 +8,4 @@
  * published by the Free Software Foundation.
  *
  */
-#ifdef CONFIG_DEBUG_NSPIRE_CX_UART
-#define NSPIRE_EARLY_UART_PHYS_BASE	   0x90020000
-#define NSPIRE_EARLY_UART_VIRT_BASE	   0xfee20000
-
-.macro	addruart, rp, rv, tmp
-	ldr \rp, =(NSPIRE_EARLY_UART_PHYS_BASE)		@ physical base address
-	ldr \rv, =(NSPIRE_EARLY_UART_VIRT_BASE)		@ virtual base address
-.endm
-
 #include <asm/hardware/debug-pl01x.S>
-#endif
diff --git a/arch/arm/include/debug/u300.S b/arch/arm/include/debug/u300.S
index 6f04f08..58b9d62 100644
--- a/arch/arm/include/debug/u300.S
+++ b/arch/arm/include/debug/u300.S
@@ -4,15 +4,4 @@
  * Debugging macro include header.
  * Author: Linus Walleij <linus.walleij at stericsson.com>
  */
-#define U300_SLOW_PER_PHYS_BASE		0xc0010000
-#define U300_SLOW_PER_VIRT_BASE		0xff000000
-
-	.macro	addruart, rp, rv, tmp
-	/* If we move the address using MMU, use this. */
-	ldr	\rp,	  = U300_SLOW_PER_PHYS_BASE @ MMU off, physical address
-	ldr	\rv,	  = U300_SLOW_PER_VIRT_BASE @ MMU on, virtual address
-	orr	\rp, \rp, #0x00003000
-	orr	\rv, \rv, #0x00003000
-	.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/vexpress.S b/arch/arm/include/debug/vexpress.S
index acafb22..114bf4c 100644
--- a/arch/arm/include/debug/vexpress.S
+++ b/arch/arm/include/debug/vexpress.S
@@ -48,50 +48,4 @@
 		.endm
 
 #include <asm/hardware/debug-pl01x.S>
-
-#elif defined(CONFIG_DEBUG_VEXPRESS_UART0_CA9)
-
-		.macro	addruart,rp,rv,tmp
-		mov	\rp, #DEBUG_LL_UART_OFFSET
-		orr	\rv, \rp, #DEBUG_LL_VIRT_BASE
-		orr	\rp, \rp, #DEBUG_LL_PHYS_BASE
-		.endm
-
-#include <asm/hardware/debug-pl01x.S>
-
-#elif defined(CONFIG_DEBUG_VEXPRESS_UART0_RS1)
-
-		.macro	addruart,rp,rv,tmp
-		mov	\rp, #DEBUG_LL_UART_OFFSET_RS1
-		orr	\rv, \rp, #DEBUG_LL_VIRT_BASE
-		orr	\rp, \rp, #DEBUG_LL_PHYS_BASE_RS1
-		.endm
-
-#include <asm/hardware/debug-pl01x.S>
-
-#elif defined(CONFIG_DEBUG_VEXPRESS_UART0_CRX)
-
-		.macro	addruart,rp,tmp,tmp2
-		ldr	\rp, =DEBUG_LL_UART_PHYS_CRX
-		.endm
-
-#include <asm/hardware/debug-pl01x.S>
-
-#else /* CONFIG_DEBUG_LL_UART_NONE */
-
-		.macro	addruart, rp, rv, tmp
-		/* Safe dummy values */
-		mov	\rp, #0
-		mov	\rv, #DEBUG_LL_VIRT_BASE
-		.endm
-
-		.macro	senduart,rd,rx
-		.endm
-
-		.macro	waituart,rd,rx
-		.endm
-
-		.macro	busyuart,rd,rx
-		.endm
-
 #endif
diff --git a/arch/arm/mach-ep93xx/include/mach/debug-macro.S b/arch/arm/mach-ep93xx/include/mach/debug-macro.S
index af54e43..a1bfe4c 100644
--- a/arch/arm/mach-ep93xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-ep93xx/include/mach/debug-macro.S
@@ -9,13 +9,4 @@
  * the Free Software Foundation; either version 2 of the License, or (at
  * your option) any later version.
  */
-#include <mach/ep93xx-regs.h>
-
-		.macro	addruart, rp, rv, tmp
-		ldr	\rp, =EP93XX_APB_PHYS_BASE	@ Physical base
-		ldr	\rv, =EP93XX_APB_VIRT_BASE	@ virtual base
-		orr	\rp, \rp, #0x000c0000
-		orr	\rv, \rv, #0x000c0000
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/mach-integrator/include/mach/debug-macro.S b/arch/arm/mach-integrator/include/mach/debug-macro.S
index 411b116..03ee0fd 100644
--- a/arch/arm/mach-integrator/include/mach/debug-macro.S
+++ b/arch/arm/mach-integrator/include/mach/debug-macro.S
@@ -10,11 +10,4 @@
  * published by the Free Software Foundation.
  *
 */
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #0x16000000	@ physical base address
-		mov	\rv, #0xf0000000	@ virtual base
-		add	\rv, \rv, #0x16000000 >> 4
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/mach-realview/include/mach/debug-macro.S b/arch/arm/mach-realview/include/mach/debug-macro.S
index 8cc372d..99488f4 100644
--- a/arch/arm/mach-realview/include/mach/debug-macro.S
+++ b/arch/arm/mach-realview/include/mach/debug-macro.S
@@ -9,21 +9,4 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-
-#ifdef CONFIG_DEBUG_REALVIEW_STD_PORT
-#define DEBUG_LL_UART_OFFSET	0x00009000
-#elif defined(CONFIG_DEBUG_REALVIEW_PB1176_PORT)
-#define DEBUG_LL_UART_OFFSET	0x0010c000
-#endif
-
-#ifndef DEBUG_LL_UART_OFFSET
-#error "Unknown RealView platform"
-#endif
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #DEBUG_LL_UART_OFFSET
-		orr	\rv, \rp, #0xfb000000	@ virtual base
-		orr	\rp, \rp, #0x10000000	@ physical base
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/mach-versatile/include/mach/debug-macro.S b/arch/arm/mach-versatile/include/mach/debug-macro.S
index d0fbd7f..c256977 100644
--- a/arch/arm/mach-versatile/include/mach/debug-macro.S
+++ b/arch/arm/mach-versatile/include/mach/debug-macro.S
@@ -10,12 +10,4 @@
  * published by the Free Software Foundation.
  *
 */
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp,      #0x001F0000
-		orr	\rp, \rp, #0x00001000
-		orr	\rv, \rp, #0xf1000000	@ virtual base
-		orr	\rp, \rp,  #0x10000000	@ physical base
-		.endm
-
 #include <asm/hardware/debug-pl01x.S>
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Tue Jul 16 12:42:12 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 16 Jul 2013 17:42:12 +0100
Subject: [PATCH RFC v2 09/14] ARM: debug: move PL01X debug include into
 arch/arm/include/debug/
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <E1Uz8KK-000481-Sx@rmk-PC.arm.linux.org.uk>

Now that the PL01X debug include can mostly stand alone without
requiring platforms to provide any macros, move it into the debug
directory so it can be directly included.  This allows us to get rid of
a lot of debug-macros include files.

The autodetect case for Versatile Express and the ux500 are left alone;
these are more complicated implementations.

Acked-by: Rob Herring <rob.herring at calxeda.com>
Acked-by: Ryan Mallon <rmallon at gmail.com>
Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug                             |   12 +-----
 arch/arm/include/asm/hardware/debug-pl01x.S        |   36 --------------------
 arch/arm/include/debug/bcm2835.S                   |   13 -------
 arch/arm/include/debug/cns3xxx.S                   |   12 ------
 arch/arm/include/debug/highbank.S                  |   11 ------
 arch/arm/include/debug/mxs.S                       |   13 -------
 arch/arm/include/debug/nomadik.S                   |   12 ------
 arch/arm/include/debug/nspire.S                    |   11 ------
 arch/arm/include/debug/pl01x.S                     |   36 ++++++++++++++++++++
 arch/arm/include/debug/u300.S                      |    7 ----
 arch/arm/include/debug/ux500.S                     |    2 +-
 arch/arm/include/debug/vexpress.S                  |    2 +-
 arch/arm/mach-ep93xx/include/mach/debug-macro.S    |   12 ------
 .../arm/mach-integrator/include/mach/debug-macro.S |   13 -------
 arch/arm/mach-realview/include/mach/debug-macro.S  |   12 ------
 arch/arm/mach-versatile/include/mach/debug-macro.S |   13 -------
 16 files changed, 40 insertions(+), 177 deletions(-)
 delete mode 100644 arch/arm/include/asm/hardware/debug-pl01x.S
 delete mode 100644 arch/arm/include/debug/bcm2835.S
 delete mode 100644 arch/arm/include/debug/cns3xxx.S
 delete mode 100644 arch/arm/include/debug/highbank.S
 delete mode 100644 arch/arm/include/debug/mxs.S
 delete mode 100644 arch/arm/include/debug/nomadik.S
 delete mode 100644 arch/arm/include/debug/nspire.S
 create mode 100644 arch/arm/include/debug/pl01x.S
 delete mode 100644 arch/arm/include/debug/u300.S
 delete mode 100644 arch/arm/mach-ep93xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-integrator/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-realview/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-versatile/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index f1cde5e..6bab4b0 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -846,10 +846,8 @@ config DEBUG_STI_UART
 config DEBUG_LL_INCLUDE
 	string
 	default "debug/8250.S" if DEBUG_UART_8250
-	default "debug/bcm2835.S" if DEBUG_BCM2835
-	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
+	default "debug/pl01x.S" if DEBUG_UART_PL01X
 	default "debug/exynos.S" if DEBUG_EXYNOS_UART
-	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
 	default "debug/icedcc.S" if DEBUG_ICEDCC
 	default "debug/imx.S" if DEBUG_IMX1_UART || \
 				 DEBUG_IMX25_UART || \
@@ -862,18 +860,12 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX6SL_UART
 	default "debug/keystone.S" if DEBUG_KEYSTONE_UART0 || \
 				      DEBUG_KEYSTONE_UART1
-	default "debug/mxs.S" if DEBUG_IMX23_UART || DEBUG_IMX28_UART
-	default "debug/nomadik.S" if DEBUG_NOMADIK_UART
-	default "debug/nspire.S" if DEBUG_NSPIRE_CX_UART
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 	default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
 	default "debug/sti.S" if DEBUG_STI_UART
 	default "debug/tegra.S" if DEBUG_TEGRA_UART
-	default "debug/u300.S" if DEBUG_U300_UART
 	default "debug/ux500.S" if DEBUG_UX500_UART
-	default "debug/vexpress.S" if DEBUG_VEXPRESS_UART0_DETECT || \
-		DEBUG_VEXPRESS_UART0_CA9 || DEBUG_VEXPRESS_UART0_RS1 || \
-		DEBUG_VEXPRESS_UART0_CRX
+	default "debug/vexpress.S" if DEBUG_VEXPRESS_UART0_DETECT
 	default "debug/vt8500.S" if DEBUG_VT8500_UART0
 	default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
 	default "mach/debug-macro.S"
diff --git a/arch/arm/include/asm/hardware/debug-pl01x.S b/arch/arm/include/asm/hardware/debug-pl01x.S
deleted file mode 100644
index 9d1e286..0000000
--- a/arch/arm/include/asm/hardware/debug-pl01x.S
+++ /dev/null
@@ -1,36 +0,0 @@
-/* arch/arm/include/asm/hardware/debug-pl01x.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
-*/
-#include <linux/amba/serial.h>
-
-#ifdef CONFIG_DEBUG_UART_PHYS
-		.macro	addruart, rp, rv, tmp
-		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
-		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
-		.endm
-#endif
-
-		.macro	senduart,rd,rx
-		strb	\rd, [\rx, #UART01x_DR]
-		.endm
-
-		.macro	waituart,rd,rx
-1001:		ldr	\rd, [\rx, #UART01x_FR]
-		tst	\rd, #UART01x_FR_TXFF
-		bne	1001b
-		.endm
-
-		.macro	busyuart,rd,rx
-1001:		ldr	\rd, [\rx, #UART01x_FR]
-		tst	\rd, #UART01x_FR_BUSY
-		bne	1001b
-		.endm
diff --git a/arch/arm/include/debug/bcm2835.S b/arch/arm/include/debug/bcm2835.S
deleted file mode 100644
index 726e069..0000000
--- a/arch/arm/include/debug/bcm2835.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/*
- * Debugging macro include header
- *
- * Copyright (C) 2010 Broadcom
- * Copyright (C) 1994-1999 Russell King
- * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/cns3xxx.S b/arch/arm/include/debug/cns3xxx.S
deleted file mode 100644
index 2d5fb51..0000000
--- a/arch/arm/include/debug/cns3xxx.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/*
- * Debugging macro include header
- *
- * Copyright 1994-1999 Russell King
- * Copyright 2008 Cavium Networks
- * Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This file is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License, Version 2, as
- * published by the Free Software Foundation.
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/highbank.S b/arch/arm/include/debug/highbank.S
deleted file mode 100644
index 3c6f63f..0000000
--- a/arch/arm/include/debug/highbank.S
+++ /dev/null
@@ -1,11 +0,0 @@
-/*
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/mxs.S b/arch/arm/include/debug/mxs.S
deleted file mode 100644
index 8a10ed2..0000000
--- a/arch/arm/include/debug/mxs.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/* arch/arm/mach-mxs/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/nomadik.S b/arch/arm/include/debug/nomadik.S
deleted file mode 100644
index a6d238e..0000000
--- a/arch/arm/include/debug/nomadik.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/*
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
-*/
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/nspire.S b/arch/arm/include/debug/nspire.S
deleted file mode 100644
index fc17e50..0000000
--- a/arch/arm/include/debug/nspire.S
+++ /dev/null
@@ -1,11 +0,0 @@
-/*
- *	linux/arch/arm/include/debug/nspire.S
- *
- *	Copyright (C) 2013 Daniel Tang <tangrs at tangrs.id.au>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2, as
- * published by the Free Software Foundation.
- *
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/pl01x.S b/arch/arm/include/debug/pl01x.S
new file mode 100644
index 0000000..37c6895b
--- /dev/null
+++ b/arch/arm/include/debug/pl01x.S
@@ -0,0 +1,36 @@
+/* arch/arm/include/debug/pl01x.S
+ *
+ * Debugging macro include header
+ *
+ *  Copyright (C) 1994-1999 Russell King
+ *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+*/
+#include <linux/amba/serial.h>
+
+#ifdef CONFIG_DEBUG_UART_PHYS
+		.macro	addruart, rp, rv, tmp
+		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
+		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
+		.endm
+#endif
+
+		.macro	senduart,rd,rx
+		strb	\rd, [\rx, #UART01x_DR]
+		.endm
+
+		.macro	waituart,rd,rx
+1001:		ldr	\rd, [\rx, #UART01x_FR]
+		tst	\rd, #UART01x_FR_TXFF
+		bne	1001b
+		.endm
+
+		.macro	busyuart,rd,rx
+1001:		ldr	\rd, [\rx, #UART01x_FR]
+		tst	\rd, #UART01x_FR_BUSY
+		bne	1001b
+		.endm
diff --git a/arch/arm/include/debug/u300.S b/arch/arm/include/debug/u300.S
deleted file mode 100644
index 58b9d62..0000000
--- a/arch/arm/include/debug/u300.S
+++ /dev/null
@@ -1,7 +0,0 @@
-/*
- * Copyright (C) 2006-2013 ST-Ericsson AB
- * License terms: GNU General Public License (GPL) version 2
- * Debugging macro include header.
- * Author: Linus Walleij <linus.walleij at stericsson.com>
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/include/debug/ux500.S b/arch/arm/include/debug/ux500.S
index fbd24be..aa7f63a 100644
--- a/arch/arm/include/debug/ux500.S
+++ b/arch/arm/include/debug/ux500.S
@@ -45,4 +45,4 @@
 	ldr	\rv, =UART_VIRT_BASE		@ yes, virtual address
 	.endm
 
-#include <asm/hardware/debug-pl01x.S>
+#include <debug/pl01x.S>
diff --git a/arch/arm/include/debug/vexpress.S b/arch/arm/include/debug/vexpress.S
index 114bf4c..524acd5 100644
--- a/arch/arm/include/debug/vexpress.S
+++ b/arch/arm/include/debug/vexpress.S
@@ -47,5 +47,5 @@
 
 		.endm
 
-#include <asm/hardware/debug-pl01x.S>
+#include <debug/pl01x.S>
 #endif
diff --git a/arch/arm/mach-ep93xx/include/mach/debug-macro.S b/arch/arm/mach-ep93xx/include/mach/debug-macro.S
deleted file mode 100644
index a1bfe4c..0000000
--- a/arch/arm/mach-ep93xx/include/mach/debug-macro.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/*
- * arch/arm/mach-ep93xx/include/mach/debug-macro.S
- * Debugging macro include header
- *
- * Copyright (C) 2006 Lennert Buytenhek <buytenh at wantstofly.org>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or (at
- * your option) any later version.
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/mach-integrator/include/mach/debug-macro.S b/arch/arm/mach-integrator/include/mach/debug-macro.S
deleted file mode 100644
index 03ee0fd..0000000
--- a/arch/arm/mach-integrator/include/mach/debug-macro.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/* arch/arm/mach-integrator/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
-*/
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/mach-realview/include/mach/debug-macro.S b/arch/arm/mach-realview/include/mach/debug-macro.S
deleted file mode 100644
index 99488f4..0000000
--- a/arch/arm/mach-realview/include/mach/debug-macro.S
+++ /dev/null
@@ -1,12 +0,0 @@
-/* arch/arm/mach-realview/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <asm/hardware/debug-pl01x.S>
diff --git a/arch/arm/mach-versatile/include/mach/debug-macro.S b/arch/arm/mach-versatile/include/mach/debug-macro.S
deleted file mode 100644
index c256977..0000000
--- a/arch/arm/mach-versatile/include/mach/debug-macro.S
+++ /dev/null
@@ -1,13 +0,0 @@
-/* arch/arm/mach-versatile/include/mach/debug-macro.S
- *
- * Debugging macro include header
- *
- *  Copyright (C) 1994-1999 Russell King
- *  Moved from linux/arch/arm/kernel/debug.S by Ben Dooks
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
-*/
-#include <asm/hardware/debug-pl01x.S>
-- 
1.7.4.4



From anup at brainfault.org  Tue Jul 16 12:42:25 2013
From: anup at brainfault.org (Anup Patel)
Date: Tue, 16 Jul 2013 22:12:25 +0530
Subject: [PATCH V2] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene
 host
In-Reply-To: <20130716091417.GC14486@e106331-lin.cambridge.arm.com>
References: <1373957734-21482-1-git-send-email-anup.patel@linaro.org>
 <20130716091417.GC14486@e106331-lin.cambridge.arm.com>
Message-ID: <CAAhSdy3B8HVAixeLt2rRnFFvGLepkxfW86gnbr6CMw+LfJw_Sw@mail.gmail.com>

On Tue, Jul 16, 2013 at 2:44 PM, Mark Rutland <mark.rutland at arm.com> wrote:
> On Tue, Jul 16, 2013 at 07:55:34AM +0100, Anup Patel wrote:
>> This patch allows us to have X-Gene guest VCPU when using KVM arm64
>> on APM X-Gene host.
>>
>> We add KVM_ARM_TARGET_XGENE_POTENZA for X-Gene Potenza compatible
>> guest VCPU and we return KVM_ARM_TARGET_XGENE_POTENZA in kvm_target_cpu()
>> when running on X-Gene host with Potenza core.
>>
>> V2:
>>  - Renamed KVM_ARM_TARGET_XGENE_V8 to KVM_ARM_TARGET_XGENE_POTENZA
>>
>> V1:
>>  - Initial patch with target named as KVM_ARM_TARGET_XGENE_V8
>>
>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>> ---
>>  arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
>>  arch/arm64/kvm/guest.c               |   34 ++++++++++++++++++++++------------
>>  arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
>>  3 files changed, 27 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 5031f42..d9f026b 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -55,8 +55,9 @@ struct kvm_regs {
>>  #define KVM_ARM_TARGET_AEM_V8                0
>>  #define KVM_ARM_TARGET_FOUNDATION_V8 1
>>  #define KVM_ARM_TARGET_CORTEX_A57    2
>> +#define KVM_ARM_TARGET_XGENE_POTENZA 3
>>
>> -#define KVM_ARM_NUM_TARGETS          3
>> +#define KVM_ARM_NUM_TARGETS          4
>>
>>  /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
>>  #define KVM_ARM_DEVICE_TYPE_SHIFT    0
>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>> index 2c3ff67..a466244 100644
>> --- a/arch/arm64/kvm/guest.c
>> +++ b/arch/arm64/kvm/guest.c
>> @@ -207,19 +207,29 @@ int __attribute_const__ kvm_target_cpu(void)
>>       unsigned long implementor = read_cpuid_implementor();
>>       unsigned long part_number = read_cpuid_part_number();
>>
>> -     if (implementor != ARM_CPU_IMP_ARM)
>> -             return -EINVAL;
>> -
>> -     switch (part_number) {
>> -     case ARM_CPU_PART_AEM_V8:
>> -             return KVM_ARM_TARGET_AEM_V8;
>> -     case ARM_CPU_PART_FOUNDATION:
>> -             return KVM_ARM_TARGET_FOUNDATION_V8;
>> -     case ARM_CPU_PART_CORTEX_A57:
>> -             /* Currently handled by the generic backend */
>> -             return KVM_ARM_TARGET_CORTEX_A57;
>> +     switch (implementor) {
>> +     case ARM_CPU_IMP_ARM:
>> +             switch (part_number) {
>> +             case ARM_CPU_PART_AEM_V8:
>> +                     return KVM_ARM_TARGET_AEM_V8;
>> +             case ARM_CPU_PART_FOUNDATION:
>> +                     return KVM_ARM_TARGET_FOUNDATION_V8;
>> +             case ARM_CPU_PART_CORTEX_A57:
>> +                     return KVM_ARM_TARGET_CORTEX_A57;
>> +             default:
>> +                     return -EINVAL;
>> +             }
>> +             break;
>> +     case ARM_CPU_IMP_APM:
>> +             switch (part_number) {
>> +             case APM_CPU_PART_POTENZA:
>> +                     return KVM_ARM_TARGET_XGENE_POTENZA;
>> +             default:
>> +                     return -EINVAL;
>> +             }
>> +             break;
>>       default:
>> -             return -EINVAL;
>> +             return -EINVAL;
>>       }
>
> Why not place a return -EINVAL here, outside of the outer switch
> statement? That way you don't need to duplicate it for an unknown
> implementor or a known implementor's unknown CPU, as long as you keep
> the break at the end of each implementor's case.

Sure, I will update the switch statement accordingly.

>
> Thanks,
> Mark.
>
>>  }
>>
>> diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
>> index 4268ab9..8fe6f76 100644
>> --- a/arch/arm64/kvm/sys_regs_generic_v8.c
>> +++ b/arch/arm64/kvm/sys_regs_generic_v8.c
>> @@ -90,6 +90,9 @@ static int __init sys_reg_genericv8_init(void)
>>                                         &genericv8_target_table);
>>       kvm_register_target_sys_reg_table(KVM_ARM_TARGET_CORTEX_A57,
>>                                         &genericv8_target_table);
>> +     kvm_register_target_sys_reg_table(KVM_ARM_TARGET_XGENE_POTENZA,
>> +                                       &genericv8_target_table);
>> +
>>       return 0;
>>  }
>>  late_initcall(sys_reg_genericv8_init);
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Regards,
Anup


From rmk+kernel at arm.linux.org.uk  Tue Jul 16 12:43:13 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 16 Jul 2013 17:43:13 +0100
Subject: [PATCH RFC v2 10/14] ARM: debug: provide generic option choices for
 8250 and PL01x ports
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <E1Uz8LJ-000485-0g@rmk-PC.arm.linux.org.uk>

Provide generic option choices for 8250 and PL01x UART ports; these can
now be selected by UART type rather than asking about the platform.
This means that a kernel configuration user can manually choose the
various parameters of the debug UART without resorting to the platform
having to encode the possible settings.

These two generic options are preferred over further debug entries for
these ports; the existing options which refer back to the 8250 and PL01x
ports are now considered deprecated.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug |   44 +++++++++++++++++++++++++++++++++++++-------
 1 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 6bab4b0..ecb3b32 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -770,6 +770,32 @@ choice
 		  This option selects UART0 on VIA/Wondermedia System-on-a-chip
 		  devices, including VT8500, WM8505, WM8650 and WM8850.
 
+	config DEBUG_LL_UART_8250
+		bool "Kernel low-level debugging via 8250 UART"
+		help
+		  Say Y here if you wish the debug print routes to direct
+		  their output to an 8250 UART.  You can use this option
+		  to provide the parameters for the 8250 UART rather than
+		  selecting one of the platform specific options above if
+		  you know the parameters for the port.
+
+		  This option is preferred over the platform specific
+		  options; the platform specific options are deprecated
+		  and will be soon removed.
+
+	config DEBUG_LL_UART_PL01X
+		bool "Kernel low-level debugging via ARM Ltd PL01x Primecell UART"
+		help
+		  Say Y here if you wish the debug print routes to direct
+		  their output to a PL01x Primecell UART.  You can use
+		  this option to provide the parameters for the UART
+		  rather than selecting one of the platform specific
+		  options above if you know the parameters for the port.
+
+		  This option is preferred over the platform specific
+		  options; the platform specific options are deprecated
+		  and will be soon removed.
+
 	config DEBUG_LL_UART_NONE
 		bool "No low-level debugging UART"
 		depends on !ARCH_MULTIPLATFORM
@@ -845,8 +871,8 @@ config DEBUG_STI_UART
 
 config DEBUG_LL_INCLUDE
 	string
-	default "debug/8250.S" if DEBUG_UART_8250
-	default "debug/pl01x.S" if DEBUG_UART_PL01X
+	default "debug/8250.S" if DEBUG_LL_UART_8250 || DEBUG_UART_8250
+	default "debug/pl01x.S" if DEBUG_LL_UART_PL01X || DEBUG_UART_PL01X
 	default "debug/exynos.S" if DEBUG_EXYNOS_UART
 	default "debug/icedcc.S" if DEBUG_ICEDCC
 	default "debug/imx.S" if DEBUG_IMX1_UART || \
@@ -870,11 +896,13 @@ config DEBUG_LL_INCLUDE
 	default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
 	default "mach/debug-macro.S"
 
+# Compatibility options for PL01x
 config DEBUG_UART_PL01X
 	def_bool ARCH_EP93XX || \
 		ARCH_INTEGRATOR || \
 		ARCH_VERSATILE
 
+# Compatibility options for 8250
 config DEBUG_UART_8250
 	def_bool ARCH_DOVE || ARCH_EBSA110 || \
 		(FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
@@ -925,7 +953,8 @@ config DEBUG_UART_PHYS
 	default 0xffd82340 if ARCH_IOP13XX
 	default 0xfff36000 if DEBUG_HIGHBANK_UART
 	default 0xfffff700 if ARCH_IOP33X
-	depends on DEBUG_UART_8250 || DEBUG_UART_PL01X
+	depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
+		DEBUG_UART_8250 || DEBUG_UART_PL01X
 
 config DEBUG_UART_VIRT
 	hex "Virtual base address of debug UART"
@@ -971,23 +1000,24 @@ config DEBUG_UART_VIRT
 	default 0xfefff700 if ARCH_IOP33X
 	default 0xff003000 if DEBUG_U300_UART
 	default DEBUG_UART_PHYS if !MMU
-	depends on DEBUG_UART_8250 || DEBUG_UART_PL01X
+	depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
+		DEBUG_UART_8250 || DEBUG_UART_PL01X
 
 config DEBUG_UART_8250_SHIFT
 	int "Register offset shift for the 8250 debug UART"
-	depends on DEBUG_UART_8250
+	depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250
 	default 0 if FOOTBRIDGE || ARCH_IOP32X
 	default 2
 
 config DEBUG_UART_8250_WORD
 	bool "Use 32-bit accesses for 8250 UART"
-	depends on DEBUG_UART_8250
+	depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250
 	depends on DEBUG_UART_8250_SHIFT >= 2
 	default y if DEBUG_PICOXCELL_UART || DEBUG_SOCFPGA_UART
 
 config DEBUG_UART_8250_FLOW_CONTROL
 	bool "Enable flow control for 8250 UART"
-	depends on DEBUG_UART_8250
+	depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250
 	default y if ARCH_EBSA110 || FOOTBRIDGE || ARCH_GEMINI || ARCH_RPC
 
 config DEBUG_UNCOMPRESS
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Tue Jul 16 12:44:13 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 16 Jul 2013 17:44:13 +0100
Subject: [PATCH RFC v2 11/14] ARM: debug: remove DEBUG_ROCKCHIP_UART
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <E1Uz8MH-000489-44@rmk-PC.arm.linux.org.uk>

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug |   11 -----------
 1 files changed, 0 insertions(+), 11 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index ecb3b32..605bfa8 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -492,7 +492,6 @@ choice
 	config DEBUG_RK29_UART0
 		bool "Kernel low-level debugging messages via Rockchip RK29 UART0"
 		depends on ARCH_ROCKCHIP
-		select DEBUG_ROCKCHIP_UART
 		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
@@ -501,7 +500,6 @@ choice
 	config DEBUG_RK29_UART1
 		bool "Kernel low-level debugging messages via Rockchip RK29 UART1"
 		depends on ARCH_ROCKCHIP
-		select DEBUG_ROCKCHIP_UART
 		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
@@ -510,7 +508,6 @@ choice
 	config DEBUG_RK29_UART2
 		bool "Kernel low-level debugging messages via Rockchip RK29 UART2"
 		depends on ARCH_ROCKCHIP
-		select DEBUG_ROCKCHIP_UART
 		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
@@ -519,7 +516,6 @@ choice
 	config DEBUG_RK3X_UART0
 		bool "Kernel low-level debugging messages via Rockchip RK3X UART0"
 		depends on ARCH_ROCKCHIP
-		select DEBUG_ROCKCHIP_UART
 		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
@@ -528,7 +524,6 @@ choice
 	config DEBUG_RK3X_UART1
 		bool "Kernel low-level debugging messages via Rockchip RK3X UART1"
 		depends on ARCH_ROCKCHIP
-		select DEBUG_ROCKCHIP_UART
 		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
@@ -537,7 +532,6 @@ choice
 	config DEBUG_RK3X_UART2
 		bool "Kernel low-level debugging messages via Rockchip RK3X UART2"
 		depends on ARCH_ROCKCHIP
-		select DEBUG_ROCKCHIP_UART
 		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
@@ -546,7 +540,6 @@ choice
 	config DEBUG_RK3X_UART3
 		bool "Kernel low-level debugging messages via Rockchip RK3X UART3"
 		depends on ARCH_ROCKCHIP
-		select DEBUG_ROCKCHIP_UART
 		select DEBUG_UART_8250
 		help
 		  Say Y here if you want kernel low-level debugging support
@@ -857,10 +850,6 @@ config DEBUG_IMX_UART_PORT
 	  Choose UART port on which kernel low-level debug messages
 	  should be output.
 
-config DEBUG_ROCKCHIP_UART
-	bool
-	depends on ARCH_ROCKCHIP
-
 config DEBUG_TEGRA_UART
 	bool
 	depends on ARCH_TEGRA
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Tue Jul 16 12:45:13 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 16 Jul 2013 17:45:13 +0100
Subject: [PATCH RFC v2 12/14] ARM: debug: move keystone debug to generic 8250
 code
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <E1Uz8NF-00048J-8B@rmk-PC.arm.linux.org.uk>

Keystone's debugging is just a copy of the old 8250_32 code with a
different base address.  Incorporate this into the generic 8250
debug code.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug            |   11 +++++++--
 arch/arm/include/debug/keystone.S |   43 -------------------------------------
 2 files changed, 8 insertions(+), 46 deletions(-)
 delete mode 100644 arch/arm/include/debug/keystone.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 605bfa8..c147e07 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -266,6 +266,7 @@ choice
 	config DEBUG_KEYSTONE_UART0
 		bool "Kernel low-level debugging on KEYSTONE2 using UART0"
 		depends on ARCH_KEYSTONE
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to UART0 serial port on KEYSTONE2 devices.
@@ -273,6 +274,7 @@ choice
 	config DEBUG_KEYSTONE_UART1
 		bool "Kernel low-level debugging on KEYSTONE2 using UART1"
 		depends on ARCH_KEYSTONE
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to UART1 serial port on KEYSTONE2 devices.
@@ -873,8 +875,6 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX53_UART ||\
 				 DEBUG_IMX6Q_UART || \
 				 DEBUG_IMX6SL_UART
-	default "debug/keystone.S" if DEBUG_KEYSTONE_UART0 || \
-				      DEBUG_KEYSTONE_UART1
 	default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
 	default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
 	default "debug/sti.S" if DEBUG_STI_UART
@@ -903,6 +903,8 @@ config DEBUG_UART_PHYS
 	hex "Physical base address of debug UART"
 	default 0x01c28000 if DEBUG_SUNXI_UART0
 	default 0x01c28400 if DEBUG_SUNXI_UART1
+	default 0x02530c00 if DEBUG_KEYSTONE_UART0
+	default 0x02531000 if DEBUG_KEYSTONE_UART1
 	default 0x03010fe0 if ARCH_RPC
 	default 0x10009000 if DEBUG_REALVIEW_STD_PORT || DEBUG_CNS3XXX || \
 				DEBUG_VEXPRESS_UART0_CA9
@@ -973,6 +975,8 @@ config DEBUG_UART_VIRT
 	default 0xfe800000 if ARCH_IOP32X
 	default 0xfeb24000 if DEBUG_RK3X_UART0
 	default 0xfeb26000 if DEBUG_RK3X_UART1
+	default 0xfeb30c00 if DEBUG_KEYSTONE_UART0
+	default 0xfeb31000 if DEBUG_KEYSTONE_UART1
 	default 0xfec12000 if DEBUG_MVEBU_UART || DEBUG_MVEBU_UART_ALTERNATE
 	default 0xfed60000 if DEBUG_RK29_UART0
 	default 0xfed64000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
@@ -1002,7 +1006,8 @@ config DEBUG_UART_8250_WORD
 	bool "Use 32-bit accesses for 8250 UART"
 	depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250
 	depends on DEBUG_UART_8250_SHIFT >= 2
-	default y if DEBUG_PICOXCELL_UART || DEBUG_SOCFPGA_UART
+	default y if DEBUG_PICOXCELL_UART || DEBUG_SOCFPGA_UART || \
+		ARCH_KEYSTONE
 
 config DEBUG_UART_8250_FLOW_CONTROL
 	bool "Enable flow control for 8250 UART"
diff --git a/arch/arm/include/debug/keystone.S b/arch/arm/include/debug/keystone.S
deleted file mode 100644
index 9aef9ba..0000000
--- a/arch/arm/include/debug/keystone.S
+++ /dev/null
@@ -1,43 +0,0 @@
-/*
- * Early serial debug output macro for Keystone SOCs
- *
- * Copyright 2013 Texas Instruments, Inc.
- *	Santosh Shilimkar <santosh.shilimkar at ti.com>
- *
- * Based on RMKs low level debug code.
- *  Copyright (C) 1994-1999 Russell King
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/serial_reg.h>
-
-#define UART_SHIFT 2
-#if defined(CONFIG_DEBUG_KEYSTONE_UART0)
-#define UART_PHYS		0x02530c00
-#define UART_VIRT		0xfeb30c00
-#elif defined(CONFIG_DEBUG_KEYSTONE_UART1)
-#define UART_PHYS		0x02531000
-#define UART_VIRT		0xfeb31000
-#endif
-
-	.macro	addruart, rp, rv, tmp
-	ldr	\rv, =UART_VIRT			@ physical base address
-	ldr	\rp, =UART_PHYS			@ virtual base address
-	.endm
-
-	.macro	senduart,rd,rx
-	str	\rd, [\rx, #UART_TX << UART_SHIFT]
-	.endm
-
-	.macro	busyuart,rd,rx
-1002:	ldr	\rd, [\rx, #UART_LSR << UART_SHIFT]
-	and	\rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
-	teq	\rd, #UART_LSR_TEMT | UART_LSR_THRE
-	bne	1002b
-	.endm
-
-	.macro	waituart,rd,rx
-	.endm
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Tue Jul 16 12:46:13 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 16 Jul 2013 17:46:13 +0100
Subject: [PATCH RFC v2 13/14] ARM: debug: move davinci debug to generic 8250
 code
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <E1Uz8OD-00048N-Be@rmk-PC.arm.linux.org.uk>

Davinci's debugging is just a copy of the old 8250_32 code with a
different base address.  Incorporate this into the generic 8250
debug code.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug                           |   16 +++++-
 arch/arm/mach-davinci/include/mach/debug-macro.S |   65 ----------------------
 2 files changed, 15 insertions(+), 66 deletions(-)
 delete mode 100644 arch/arm/mach-davinci/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index c147e07..4cfed9d 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -119,6 +119,7 @@ choice
 	config DEBUG_DAVINCI_DA8XX_UART1
 		bool "Kernel low-level debugging on DaVinci DA8XX using UART1"
 		depends on ARCH_DAVINCI_DA8XX
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to UART1 serial port on DaVinci DA8XX devices.
@@ -126,6 +127,7 @@ choice
 	config DEBUG_DAVINCI_DA8XX_UART2
 		bool "Kernel low-level debugging on DaVinci DA8XX using UART2"
 		depends on ARCH_DAVINCI_DA8XX
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to UART2 serial port on DaVinci DA8XX devices.
@@ -133,6 +135,7 @@ choice
 	config DEBUG_DAVINCI_DMx_UART0
 		bool "Kernel low-level debugging on DaVinci DMx using UART0"
 		depends on ARCH_DAVINCI_DMx
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to UART0 serial port on DaVinci DMx devices.
@@ -140,6 +143,7 @@ choice
 	config DEBUG_DAVINCI_TNETV107X_UART1
 		bool "Kernel low-level debugging on DaVinci TNETV107x using UART1"
 		depends on ARCH_DAVINCI_TNETV107X
+		select DEBUG_UART_8250
 		help
 		  Say Y here if you want the debug print routines to direct
 		  their output to UART1 serial port on DaVinci TNETV107X
@@ -901,11 +905,15 @@ config DEBUG_UART_8250
 
 config DEBUG_UART_PHYS
 	hex "Physical base address of debug UART"
+	default 0x01c20000 if DEBUG_DAVINCI_DMx_UART0
 	default 0x01c28000 if DEBUG_SUNXI_UART0
 	default 0x01c28400 if DEBUG_SUNXI_UART1
+	default 0x01d0c000 if DEBUG_DAVINCI_DA8XX_UART1
+	default 0x01d0d000 if DEBUG_DAVINCI_DA8XX_UART2
 	default 0x02530c00 if DEBUG_KEYSTONE_UART0
 	default 0x02531000 if DEBUG_KEYSTONE_UART1
 	default 0x03010fe0 if ARCH_RPC
+	default 0x08108300 if DEBUG_DAVINCI_TNETV107X_UART1
 	default 0x10009000 if DEBUG_REALVIEW_STD_PORT || DEBUG_CNS3XXX || \
 				DEBUG_VEXPRESS_UART0_CA9
 	default 0x1010c000 if DEBUG_REALVIEW_PB1176_PORT
@@ -982,9 +990,13 @@ config DEBUG_UART_VIRT
 	default 0xfed64000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
 	default 0xfed68000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
 	default 0xfec02000 if DEBUG_SOCFPGA_UART
+	default 0xfec20000 if DEBUG_DAVINCI_DMx_UART0
+	default 0xfed0c000 if DEBUG_DAVINCI_DA8XX_UART1
+	default 0xfed0d000 if DEBUG_DAVINCI_DA8XX_UART2
 	default 0xfed12000 if ARCH_KIRKWOOD
 	default 0xfedc0000 if ARCH_EP93XX
 	default 0xfee003f8 if FOOTBRIDGE
+	default 0xfee08300 if DEBUG_DAVINCI_TNETV107X_UART1
 	default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART
 	default 0xfee36000 if DEBUG_HIGHBANK_UART
 	default 0xfee82340 if ARCH_IOP13XX
@@ -1007,7 +1019,9 @@ config DEBUG_UART_8250_WORD
 	depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250
 	depends on DEBUG_UART_8250_SHIFT >= 2
 	default y if DEBUG_PICOXCELL_UART || DEBUG_SOCFPGA_UART || \
-		ARCH_KEYSTONE
+		ARCH_KEYSTONE || \
+		DEBUG_DAVINCI_DMx_UART0 || DEBUG_DAVINCI_DA8XX_UART1 || \
+		DEBUG_DAVINCI_DA8XX_UART2 || DEBUG_DAVINCI_TNETV107X_UART1
 
 config DEBUG_UART_8250_FLOW_CONTROL
 	bool "Enable flow control for 8250 UART"
diff --git a/arch/arm/mach-davinci/include/mach/debug-macro.S b/arch/arm/mach-davinci/include/mach/debug-macro.S
deleted file mode 100644
index b18b8eb..0000000
--- a/arch/arm/mach-davinci/include/mach/debug-macro.S
+++ /dev/null
@@ -1,65 +0,0 @@
-/*
- * Debugging macro for DaVinci
- *
- * Author: Kevin Hilman, MontaVista Software, Inc. <source at mvista.com>
- *
- * 2007 (c) MontaVista Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- */
-
-/* Modifications
- * Jan 2009	Chaithrika U S	Added senduart, busyuart, waituart
- *				macros, based on debug-8250.S file
- *				but using 32-bit accesses required for
- *                              some davinci devices.
- */
-
-#include <linux/serial_reg.h>
-
-#include <mach/serial.h>
-
-#define UART_SHIFT	2
-
-#if defined(CONFIG_DEBUG_DAVINCI_DMx_UART0)
-#define UART_BASE	DAVINCI_UART0_BASE
-#elif defined(CONFIG_DEBUG_DAVINCI_DA8XX_UART1)
-#define UART_BASE	DA8XX_UART1_BASE
-#elif defined(CONFIG_DEBUG_DAVINCI_DA8XX_UART2)
-#define UART_BASE	DA8XX_UART2_BASE
-#elif defined(CONFIG_DEBUG_DAVINCI_TNETV107X_UART1)
-#define UART_BASE	TNETV107X_UART2_BASE
-#define UART_VIRTBASE	TNETV107X_UART2_VIRT
-#else
-#error "Select a specifc port for DEBUG_LL"
-#endif
-
-#ifndef UART_VIRTBASE
-#define UART_VIRTBASE	IO_ADDRESS(UART_BASE)
-#endif
-
-		.macro addruart, rp, rv, tmp
-		ldr	\rp, =UART_BASE
-		ldr	\rv, =UART_VIRTBASE
-		.endm
-
-		.macro	senduart,rd,rx
-		str	\rd, [\rx, #UART_TX << UART_SHIFT]
-		.endm
-
-		.macro	busyuart,rd,rx
-1002:		ldr	\rd, [\rx, #UART_LSR << UART_SHIFT]
-		and	\rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
-		teq	\rd, #UART_LSR_TEMT | UART_LSR_THRE
-		bne	1002b
-		.endm
-
-		.macro	waituart,rd,rx
-#ifdef FLOW_CONTROL
-1001:		ldr	\rd, [\rx, #UART_MSR << UART_SHIFT]
-		tst	\rd, #UART_MSR_CTS
-		beq	1001b
-#endif
-		.endm
-
-- 
1.7.4.4



From rmk+kernel at arm.linux.org.uk  Tue Jul 16 12:47:13 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 16 Jul 2013 17:47:13 +0100
Subject: [PATCH RFC v2 14/14] ARM: debug: move Spear debug to generic PL01x
 code
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <E1Uz8PB-00048R-F3@rmk-PC.arm.linux.org.uk>

The Spear debug code is a copy of the PL01x debugging code, so rather
than have this pointless code duplication, lets just use the standard
implementation instead.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/Kconfig.debug                         |    7 ++++
 arch/arm/mach-spear/include/mach/debug-macro.S |   36 ------------------------
 arch/arm/mach-spear/include/mach/spear.h       |    2 -
 3 files changed, 7 insertions(+), 38 deletions(-)
 delete mode 100644 arch/arm/mach-spear/include/mach/debug-macro.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 4cfed9d..974359f 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -893,6 +893,9 @@ config DEBUG_LL_INCLUDE
 config DEBUG_UART_PL01X
 	def_bool ARCH_EP93XX || \
 		ARCH_INTEGRATOR || \
+		ARCH_SPEAR3XX || \
+		ARCH_SPEAR6XX || \
+		ARCH_SPEAR13XX || \
 		ARCH_VERSATILE
 
 # Compatibility options for 8250
@@ -940,9 +943,11 @@ config DEBUG_UART_PHYS
 	default 0xc0013000 if DEBUG_U300_UART
 	default 0xc8000000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
 	default 0xc8000003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
+	default 0xd0000000 if ARCH_SPEAR3XX || ARCH_SPEAR6XX
 	default 0xd0012000 if DEBUG_MVEBU_UART
 	default 0xd4017000 if DEBUG_MMP_UART2
 	default 0xd4018000 if DEBUG_MMP_UART3
+	default 0xe0000000 if ARCH_SPEAR13XX
 	default 0xf0000be0 if ARCH_EBSA110
 	default 0xf1012000 if DEBUG_MVEBU_UART_ALTERNATE
 	default 0xf1012000 if ARCH_DOVE || ARCH_KIRKWOOD || ARCH_MV78XX0 || \
@@ -973,6 +978,8 @@ config DEBUG_UART_VIRT
 	default 0xf8090000 if DEBUG_VEXPRESS_UART0_RS1
 	default 0xfb009000 if DEBUG_REALVIEW_STD_PORT
 	default 0xfb10c000 if DEBUG_REALVIEW_PB1176_PORT
+	default 0xfd000000 if ARCH_SPEAR3XX || ARCH_SPEAR6XX
+	default 0xfd000000 if ARCH_SPEAR13XX
 	default 0xfd012000 if ARCH_MV78XX0
 	default 0xfde12000 if ARCH_DOVE
 	default 0xfe012000 if ARCH_ORION5X
diff --git a/arch/arm/mach-spear/include/mach/debug-macro.S b/arch/arm/mach-spear/include/mach/debug-macro.S
deleted file mode 100644
index 75b05ad..0000000
--- a/arch/arm/mach-spear/include/mach/debug-macro.S
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * arch/arm/plat-spear/include/plat/debug-macro.S
- *
- * Debugging macro include header for spear platform
- *
- * Copyright (C) 2009 ST Microelectronics
- * Viresh Kumar <viresh.linux at gmail.com>
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include <linux/amba/serial.h>
-#include <mach/spear.h>
-
-		.macro	addruart, rp, rv, tmp
-		mov	\rp, #SPEAR_DBG_UART_BASE		@ Physical base
-		mov	\rv, #VA_SPEAR_DBG_UART_BASE		@ Virtual base
-		.endm
-
-		.macro	senduart, rd, rx
-		strb	\rd, [\rx, #UART01x_DR]			@ ASC_TX_BUFFER
-		.endm
-
-		.macro	waituart, rd, rx
-1001:		ldr	\rd, [\rx, #UART01x_FR]			@ FLAG REGISTER
-		tst	\rd, #UART01x_FR_TXFF			@ TX_FULL
-		bne	1001b
-		.endm
-
-		.macro	busyuart, rd, rx
-1002:		ldr	\rd, [\rx, #UART01x_FR]			@ FLAG REGISTER
-		tst	\rd, #UART011_FR_TXFE			@ TX_EMPTY
-		beq	1002b
-		.endm
diff --git a/arch/arm/mach-spear/include/mach/spear.h b/arch/arm/mach-spear/include/mach/spear.h
index cf3a536..5cdc53d 100644
--- a/arch/arm/mach-spear/include/mach/spear.h
+++ b/arch/arm/mach-spear/include/mach/spear.h
@@ -39,7 +39,6 @@
 
 /* Debug uart for linux, will be used for debug and uncompress messages */
 #define SPEAR_DBG_UART_BASE		SPEAR_ICM1_UART_BASE
-#define VA_SPEAR_DBG_UART_BASE		VA_SPEAR_ICM1_UART_BASE
 
 /* Sysctl base for spear platform */
 #define SPEAR_SYS_CTRL_BASE		SPEAR_ICM3_SYS_CTRL_BASE
@@ -86,7 +85,6 @@
 
 /* Debug uart for linux, will be used for debug and uncompress messages */
 #define SPEAR_DBG_UART_BASE			UART_BASE
-#define VA_SPEAR_DBG_UART_BASE			VA_UART_BASE
 
 #endif /* SPEAR13XX */
 
-- 
1.7.4.4



From stern at rowland.harvard.edu  Tue Jul 16 12:48:53 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 16 Jul 2013 12:48:53 -0400 (EDT)
Subject: [PATCH v3 6/7] USB: ohci-at91: add usb_clk for transition to
 common clk framework
In-Reply-To: <1373988136-24622-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <Pine.LNX.4.44L0.1307161246130.1032-100000@iolanthe.rowland.org>

On Tue, 16 Jul 2013, Boris BREZILLON wrote:

> The AT91 PMC (Power Management Controller) provides an USB clock used by
> USB Full Speed host (ohci) and USB Full Speed device (udc).
> The usb drivers (ohci and udc) must configure this clock to 48Mhz.
> This configuration was formely done in mach-at91/clock.c, but this
> implementation will be removed when moving to common clk framework.
> 
> This patch add support for usb clock retrieval and configuration, and is
> backward compatible with the current at91 clk implementation (if usb clk
> is not found, it does not configure/enable the usb clk).

But it does print a warning in the system log, right?

> @@ -144,6 +150,11 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
>  		goto err2;
>  	}
>  
> +	uclk = clk_get(&pdev->dev, "usb_clk");
> +	if (IS_ERR(uclk)) {
> +		uclk = NULL;
> +		dev_warn(&pdev->dev, "failed to get usb_clk\n");
> +	}

Is this really what you want for backward compatibility?

Alan Stern



From will.deacon at arm.com  Tue Jul 16 12:49:05 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 16 Jul 2013 17:49:05 +0100
Subject: [PATCH] ARM: a.out: remove partial a.out support
In-Reply-To: <20130715140825.GU24642@n2100.arm.linux.org.uk>
References: <1373894897-30607-1-git-send-email-will.deacon@arm.com>
 <20130715140825.GU24642@n2100.arm.linux.org.uk>
Message-ID: <20130716164905.GA3428@mudshark.cambridge.arm.com>

Hi Russell,

On Mon, Jul 15, 2013 at 03:08:25PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 15, 2013 at 02:28:17PM +0100, Will Deacon wrote:
> >  arch/arm/include/uapi/asm/Kbuild  |  1 -
> >  arch/arm/include/uapi/asm/a.out.h | 34 -----------------------------
> 
> I don't think we can remove this quite as easily as this - this is
> a user visible API change as it's part of the userland headers, and
> will break anything in userspace which includes <a.out.h>

Does this actually matter? If we're removing aout support anyway, those
programs will be broken by that. Looking at powerpc, sparc, sh and others it
seems as though their a.out.h headers were removed a while ago despite being
exported to userspace. I managed to get a 2.6.25 tree to generate headers
confirming this.

Will


From b.brezillon at overkiz.com  Tue Jul 16 13:08:12 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Tue, 16 Jul 2013 19:08:12 +0200
Subject: [PATCH v3 6/7] USB: ohci-at91: add usb_clk for transition to
 common clk framework
In-Reply-To: <Pine.LNX.4.44L0.1307161246130.1032-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307161246130.1032-100000@iolanthe.rowland.org>
Message-ID: <51E57DFC.5030302@overkiz.com>

Hello Alan,

On 16/07/2013 18:48, Alan Stern wrote:
> On Tue, 16 Jul 2013, Boris BREZILLON wrote:
>
>> The AT91 PMC (Power Management Controller) provides an USB clock used by
>> USB Full Speed host (ohci) and USB Full Speed device (udc).
>> The usb drivers (ohci and udc) must configure this clock to 48Mhz.
>> This configuration was formely done in mach-at91/clock.c, but this
>> implementation will be removed when moving to common clk framework.
>>
>> This patch add support for usb clock retrieval and configuration, and is
>> backward compatible with the current at91 clk implementation (if usb clk
>> is not found, it does not configure/enable the usb clk).
> But it does print a warning in the system log, right?
Yes it does.
>
>> @@ -144,6 +150,11 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
>>   		goto err2;
>>   	}
>>   
>> +	uclk = clk_get(&pdev->dev, "usb_clk");
>> +	if (IS_ERR(uclk)) {
>> +		uclk = NULL;
>> +		dev_warn(&pdev->dev, "failed to get usb_clk\n");
>> +	}
> Is this really what you want for backward compatibility?
Here are some proposition to remove the warning message:

1) replace it with a dev_info and change the message:
     dev_info(&pdev->dev, "failed to get usb_clk (most likely using old 
at91 clk implementation)\n");
2) drop the log and silently ignore the missing clk (I'm not a big fan 
of this solution
     as it may lead to some errors if we're using new clk implem and the 
clock is really missing)
3) rework the current clk_set_rate function to accept clk_set_rate on 
usb clk and add clk_lookup entries
     for the usb clk (I'm not a big fan of this solution neither as this 
modifications will only be used for a short time
     until the transition to common clk framework is completed).
> Alan Stern
>

Thanks for your review.

Best Regards,

Boris


From linux at arm.linux.org.uk  Tue Jul 16 13:07:39 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 16 Jul 2013 18:07:39 +0100
Subject: [PATCH v3 6/7] USB: ohci-at91: add usb_clk for transition to
 common clk framework
In-Reply-To: <1373988136-24622-1-git-send-email-b.brezillon@overkiz.com>
References: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
 <1373988136-24622-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <20130716170739.GE24642@n2100.arm.linux.org.uk>

On Tue, Jul 16, 2013 at 05:22:15PM +0200, Boris BREZILLON wrote:
> @@ -41,6 +41,10 @@ extern int usb_disabled(void);
>  
>  static void at91_start_clock(void)
>  {
> +	if (uclk) {

	if (!IS_ERR(uclk)) {

> +		clk_set_rate(uclk, 48000000);
> +		clk_prepare_enable(uclk);
> +	}
>  	clk_prepare_enable(hclk);
>  	clk_prepare_enable(iclk);
>  	clk_prepare_enable(fclk);
> @@ -52,6 +56,8 @@ static void at91_stop_clock(void)
>  	clk_disable_unprepare(fclk);
>  	clk_disable_unprepare(iclk);
>  	clk_disable_unprepare(hclk);
> +	if (uclk)

	if (!IS_ERR(uclk))

> +		clk_disable_unprepare(uclk);
>  	clocked = 0;
>  }
>  
> @@ -144,6 +150,11 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
>  		goto err2;
>  	}
>  
> +	uclk = clk_get(&pdev->dev, "usb_clk");
> +	if (IS_ERR(uclk)) {
> +		uclk = NULL;

Remove this line.

> +		dev_warn(&pdev->dev, "failed to get usb_clk\n");
> +	}
>  	iclk = clk_get(&pdev->dev, "ohci_clk");
>  	if (IS_ERR(iclk)) {
>  		dev_err(&pdev->dev, "failed to get ohci_clk\n");
> @@ -212,10 +223,11 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
>  	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
>  	usb_put_hcd(hcd);
>  

What if uclk is NULL here?

	if (!IS_ERR(uclk))

> +	clk_put(uclk);
>  	clk_put(hclk);
>  	clk_put(fclk);
>  	clk_put(iclk);
> -	fclk = iclk = hclk = NULL;
> +	fclk = iclk = hclk = uclk = NULL;

Don't.

Range of invalid struct clk pointers: those which IS_ERR(clk) returns true.
Therefore, the range of valid struct clk pointers is: _____________________
(answer on a post card, stamped and addressed to...)


From linux at arm.linux.org.uk  Tue Jul 16 13:13:24 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 16 Jul 2013 18:13:24 +0100
Subject: [PATCH v3 2/7] mmc: atmel-mci: prepare clk before calling enable
In-Reply-To: <1373987208-24120-1-git-send-email-b.brezillon@overkiz.com>
References: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
 <1373987208-24120-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <20130716171324.GF24642@n2100.arm.linux.org.uk>

On Tue, Jul 16, 2013 at 05:06:48PM +0200, Boris BREZILLON wrote:
> @@ -389,9 +391,13 @@ static int atmci_regs_show(struct seq_file *s, void *v)
>  	 * consistent.
>  	 */
>  	spin_lock_bh(&host->lock);
> -	clk_enable(host->mck);
> +	ret = clk_prepare_enable(host->mck);
> +	if (ret) {
> +		spin_unlock_bh(&host->lock);
> +		goto out;
> +	}

NAK.  This is buggy.  clk_prepare() can sleep.  Calling clk_prepare()
even via clk_prepare_enable() is a blatent bug.

>  	memcpy_fromio(buf, host->regs, ATMCI_REGS_SIZE);
> -	clk_disable(host->mck);
> +	clk_disable_unprepare(host->mck);
>  	spin_unlock_bh(&host->lock);

Now, given that the CLK API counts enables/disables, having the spin lock
around the clk API calls is utterly pointless.  This should be:

	ret = clk_prepare_enable(host->mck);
	if (ret)
		goto out;

	spin_lock_bh(&host->lock);
	memcpy_fromio(buf, host->regs, ATMCI_REGS_SIZE);
	spin_unlock_bh(&host->lock);

	clk_disable_unprepare(host->mclk);

or, if you really need to have the clock enabled/disabled within the
spinlock (very very very unlikely):

	ret = clk_prepare(host->mck);
	if (ret)
		goto out;

	spin_lock_bh(&host->lock);
	ret = clk_enable(host->mck);
	if (ret == 0) {
		memcpy_fromio(buf, host->regs, ATMCI_REGS_SIZE);
		clk_disable(host->mck);
	}
	spin_unlock_bh(&host->lock);

	clk_unprepare(host->mclk);
	if (ret)
		goto out;

> @@ -1279,7 +1286,7 @@ static void atmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>  
>  		spin_lock_bh(&host->lock);
>  		if (!host->mode_reg) {
> -			clk_enable(host->mck);
> +			clk_prepare_enable(host->mck);

Again, buggy - calling clk_prepare beneath a spinlock is illegal.


From jonathan.austin at arm.com  Tue Jul 16 13:31:23 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Tue, 16 Jul 2013 18:31:23 +0100
Subject: arm: Only load TLS values when needed
In-Reply-To: <51E42E11.1010903@dawncrow.de>
References: <51E42E11.1010903@dawncrow.de>
Message-ID: <51E5836B.1010904@arm.com>

Hi Andr?,

On 15/07/13 18:14, Andr? Hentschel wrote:
> From: Andr? Hentschel <nerv at dawncrow.de>
>
> This patch intents to reduce loading instructions when the resulting value is not used.
> It's a follow up on a4780adeefd042482f624f5e0d577bf9cdcbb760
>

Have you done any benchmarking to see that this has any real impact? Or 
tested on a !Vv6k system? It looks possible that the only case where 
this will perform better is where we're using switch_tls_none or 
switch_tls_software (both rare cases, I think) and there's some change 
it will make things worse in other cases?

One of the reasons for Russell's suggestion of placing the ldrd (which 
became the two ldr instructions you've removed from __switch_to, in 
order to maintain building for older cores) where it is was in order to 
reduce the chance of pipeline stalls.

As I've pointed out below, there is some risk that changing that has 
implications for the v6 only case below (and the v6k case is now more 
prone to stalls with !CONFIG_CPU_USE_DOMAINS, but newer cores should 
have more advanced scheduling to avoid such issues anyway...)

> Signed-off-by: Andr? Hentschel <nerv at dawncrow.de>
>
> ---
> This patch is against Linux 3.11-rc1 (ad81f0545ef01ea651886dddac4bef6cec930092)
>
> Thanks to everyone who helped me with a4780adeefd042482f624f5e0d577bf9cdcbb760
>
> diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h
> index 83259b8..3742722 100644
> --- a/arch/arm/include/asm/tls.h
> +++ b/arch/arm/include/asm/tls.h
> @@ -3,29 +3,32 @@
>
>   #ifdef __ASSEMBLY__
>   #include <asm/asm-offsets.h>
> -	.macro switch_tls_none, base, tp, tpuser, tmp1, tmp2
> +	.macro switch_tls_none, prev, next, tp, tpuser, tmp1, tmp2
>   	.endm
>
> -	.macro switch_tls_v6k, base, tp, tpuser, tmp1, tmp2
> +	.macro switch_tls_v6k, prev, next, tp, tpuser, tmp1, tmp2
> +	ldrd	\tp, \tpuser, [\next, #TI_TP_VALUE]	@ get the next TLS and user r/w register
>   	mrc	p15, 0, \tmp2, c13, c0, 2	@ get the user r/w register
>   	mcr	p15, 0, \tp, c13, c0, 3		@ set TLS register
>   	mcr	p15, 0, \tpuser, c13, c0, 2	@ and the user r/w register
> -	str	\tmp2, [\base, #TI_TP_VALUE + 4] @ save it
> +	str	\tmp2, [\prev, #TI_TP_VALUE + 4] @ save it
>   	.endm
>
> -	.macro switch_tls_v6, base, tp, tpuser, tmp1, tmp2
> +	.macro switch_tls_v6, prev, next, tp, tpuser, tmp1, tmp2
>   	ldr	\tmp1, =elf_hwcap
>   	ldr	\tmp1, [\tmp1, #0]
>   	mov	\tmp2, #0xffff0fff
> +	ldr	\tp, [\next, #TI_TP_VALUE]	@ get the next TLS register
>   	tst	\tmp1, #HWCAP_TLS		@ hardware TLS available?
>   	streq	\tp, [\tmp2, #-15]		@ set TLS value at 0xffff0ff0
> -	mrcne	p15, 0, \tmp2, c13, c0, 2	@ get the user r/w register
> +	mrcne	p15, 0, \tmp2, c13, c0, 2	@ get the previous user r/w register
> +	ldrne	\tpuser, [\next, #TI_TP_VALUE + 4]	@ get the next user r/w register
>   	mcrne	p15, 0, \tp, c13, c0, 3		@ yes, set TLS register
>   	mcrne	p15, 0, \tpuser, c13, c0, 2	@ set user r/w register

Now we've only got one instruction between the store and the load and 
risk stalling the pipeline...

Dave M cautiously says "The ancient advice was that one instruction was 
enough" but this is very core dependent... I wonder if anyone has a good 
idea about whether this is an issue here...?

> -	strne	\tmp2, [\base, #TI_TP_VALUE + 4] @ save it
> +	strne	\tmp2, [\prev, #TI_TP_VALUE + 4] @ save it
>   	.endm
>
> -	.macro switch_tls_software, base, tp, tpuser, tmp1, tmp2
> +	.macro switch_tls_software, prev, next, tp, tpuser, tmp1, tmp2
>   	mov	\tmp1, #0xffff0fff
>   	str	\tp, [\tmp1, #-15]		@ set TLS value at 0xffff0ff0
>   	.endm
> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> index a39cfc2a1..1484b59 100644
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -689,12 +689,10 @@ ENTRY(__switch_to)
>    THUMB(	stmia	ip!, {r4 - sl, fp}	   )	@ Store most regs on stack
>    THUMB(	str	sp, [ip], #4		   )
>    THUMB(	str	lr, [ip], #4		   )
> -	ldr	r4, [r2, #TI_TP_VALUE]
> -	ldr	r5, [r2, #TI_TP_VALUE + 4]
>   #ifdef CONFIG_CPU_USE_DOMAINS
>   	ldr	r6, [r2, #TI_CPU_DOMAIN]
>   #endif
> -	switch_tls r1, r4, r5, r3, r7
> +	switch_tls r1, r2, r4, r5, r3, r7
>   #if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
>   	ldr	r7, [r2, #TI_TASK]
>   	ldr	r8, =__stack_chk_guard
>

Jonny



From fabio.estevam at freescale.com  Tue Jul 16 13:40:29 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Tue, 16 Jul 2013 14:40:29 -0300
Subject: [PATCH 1/2] ARM: dts: imx6: Add support for imx6q wandboard
Message-ID: <1373996430-19854-1-git-send-email-fabio.estevam@freescale.com>

Add support for the imx6q wanboard variant.

Since imx6q/dl are pin to pin compatible, introduce the imx6qdl-wandboard.dtsi 
file that contains the common peripheral nodes.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/Makefile               |   1 +
 arch/arm/boot/dts/imx6dl-wandboard.dts   | 121 +---------------------------
 arch/arm/boot/dts/imx6q-wandboard.dts    |  22 ++++++
 arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 132 +++++++++++++++++++++++++++++++
 4 files changed, 156 insertions(+), 120 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6q-wandboard.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-wandboard.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 2cec2ff..ce1b3a3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -133,6 +133,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx6q-sabrelite.dtb \
 	imx6q-sabresd.dtb \
 	imx6q-sbc6x.dtb \
+	imx6q-wandboard.dtb \
 	imx6sl-evk.dtb \
 	vf610-twr.dtb
 dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts b/arch/arm/boot/dts/imx6dl-wandboard.dts
index 15014bb..e672891 100644
--- a/arch/arm/boot/dts/imx6dl-wandboard.dts
+++ b/arch/arm/boot/dts/imx6dl-wandboard.dts
@@ -10,6 +10,7 @@
  */
 /dts-v1/;
 #include "imx6dl.dtsi"
+#include "imx6qdl-wandboard.dtsi"
 
 / {
 	model = "Wandboard i.MX6 Dual Lite Board";
@@ -18,124 +19,4 @@
 	memory {
 		reg = <0x10000000 0x40000000>;
 	};
-
-	regulators {
-		compatible = "simple-bus";
-
-		reg_2p5v: 2p5v {
-			compatible = "regulator-fixed";
-			regulator-name = "2P5V";
-			regulator-min-microvolt = <2500000>;
-			regulator-max-microvolt = <2500000>;
-			regulator-always-on;
-		};
-
-		reg_3p3v: 3p3v {
-			compatible = "regulator-fixed";
-			regulator-name = "3P3V";
-			regulator-min-microvolt = <3300000>;
-			regulator-max-microvolt = <3300000>;
-			regulator-always-on;
-		};
-	};
-
-	sound {
-		compatible = "fsl,imx6dl-wandboard-sgtl5000",
-			     "fsl,imx-audio-sgtl5000";
-		model = "imx6dl-wandboard-sgtl5000";
-		ssi-controller = <&ssi1>;
-		audio-codec = <&codec>;
-		audio-routing =
-			"MIC_IN", "Mic Jack",
-			"Mic Jack", "Mic Bias",
-			"Headphone Jack", "HP_OUT";
-		mux-int-port = <1>;
-		mux-ext-port = <3>;
-	};
-};
-
-&audmux {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_audmux_2>;
-	status = "okay";
-};
-
-&i2c2 {
-	clock-frequency = <100000>;
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_i2c2_2>;
-	status = "okay";
-
-	codec: sgtl5000 at 0a {
-		compatible = "fsl,sgtl5000";
-		reg = <0x0a>;
-		clocks = <&clks 169>;
-		VDDA-supply = <&reg_2p5v>;
-		VDDIO-supply = <&reg_3p3v>;
-	};
-};
-
-&iomuxc {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_hog>;
-
-	hog {
-		pinctrl_hog: hoggrp {
-			fsl,pins = <
-				MX6QDL_PAD_GPIO_0__CCM_CLKO1 	0x130b0
-				MX6QDL_PAD_GPIO_2__GPIO1_IO02	0x80000000
-				MX6QDL_PAD_EIM_DA9__GPIO3_IO09	0x80000000
-			>;
-		};
-	};
-};
-
-&fec {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet_1>;
-	phy-mode = "rgmii";
-	status = "okay";
-};
-
-&ssi1 {
-	fsl,mode = "i2s-slave";
-	status = "okay";
-};
-
-&uart1 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_uart1_1>;
-	status = "okay";
-};
-
-&uart3 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_uart3_2>;
-	fsl,uart-has-rtscts;
-	status = "okay";
-};
-
-&usbh1 {
-	status = "okay";
-};
-
-&usdhc1 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_usdhc1_2>;
-	cd-gpios = <&gpio1 2 0>;
-	status = "okay";
-};
-
-&usdhc2 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_usdhc2_2>;
-	non-removable;
-	status = "okay";
-};
-
-&usdhc3 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_usdhc3_2>;
-	cd-gpios = <&gpio3 9 0>;
-	status = "okay";
 };
diff --git a/arch/arm/boot/dts/imx6q-wandboard.dts b/arch/arm/boot/dts/imx6q-wandboard.dts
new file mode 100644
index 0000000..5dd6342
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-wandboard.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Fabio Estevam <fabio.estevam at freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-wandboard.dtsi"
+
+/ {
+	model = "Wandboard i.MX6 Quad Board";
+	compatible = "wand,imx6q-wandboard", "fsl,imx6q";
+
+	memory {
+		reg = <0x10000000 0x80000000>;
+	};
+};
diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
new file mode 100644
index 0000000..7a46f64
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -0,0 +1,132 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Fabio Estevam <fabio.estevam at freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+/ {
+	regulators {
+		compatible = "simple-bus";
+
+		reg_2p5v: 2p5v {
+			compatible = "regulator-fixed";
+			regulator-name = "2P5V";
+			regulator-min-microvolt = <2500000>;
+			regulator-max-microvolt = <2500000>;
+			regulator-always-on;
+		};
+
+		reg_3p3v: 3p3v {
+			compatible = "regulator-fixed";
+			regulator-name = "3P3V";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
+	};
+
+	sound {
+		compatible = "fsl,imx6-wandboard-sgtl5000",
+			     "fsl,imx-audio-sgtl5000";
+		model = "imx6-wandboard-sgtl5000";
+		ssi-controller = <&ssi1>;
+		audio-codec = <&codec>;
+		audio-routing =
+			"MIC_IN", "Mic Jack",
+			"Mic Jack", "Mic Bias",
+			"Headphone Jack", "HP_OUT";
+		mux-int-port = <1>;
+		mux-ext-port = <3>;
+	};
+};
+
+&audmux {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_audmux_2>;
+	status = "okay";
+};
+
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2_2>;
+	status = "okay";
+
+	codec: sgtl5000 at 0a {
+		compatible = "fsl,sgtl5000";
+		reg = <0x0a>;
+		clocks = <&clks 169>;
+		VDDA-supply = <&reg_2p5v>;
+		VDDIO-supply = <&reg_3p3v>;
+	};
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	hog {
+		pinctrl_hog: hoggrp {
+			fsl,pins = <
+				MX6QDL_PAD_GPIO_0__CCM_CLKO1 	0x130b0
+				MX6QDL_PAD_GPIO_2__GPIO1_IO02	0x80000000
+				MX6QDL_PAD_EIM_DA9__GPIO3_IO09	0x80000000
+			>;
+		};
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet_1>;
+	phy-mode = "rgmii";
+	status = "okay";
+};
+
+&ssi1 {
+	fsl,mode = "i2s-slave";
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1_1>;
+	status = "okay";
+};
+
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart3_2>;
+	fsl,uart-has-rtscts;
+	status = "okay";
+};
+
+&usbh1 {
+	status = "okay";
+};
+
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1_2>;
+	cd-gpios = <&gpio1 2 0>;
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2_2>;
+	non-removable;
+	status = "okay";
+};
+
+&usdhc3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc3_2>;
+	cd-gpios = <&gpio3 9 0>;
+	status = "okay";
+};
-- 
1.8.1.2




From fabio.estevam at freescale.com  Tue Jul 16 13:40:30 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Tue, 16 Jul 2013 14:40:30 -0300
Subject: [PATCH 2/2] ARM: dts: imx6q-wandboard: Add sata support
In-Reply-To: <1373996430-19854-1-git-send-email-fabio.estevam@freescale.com>
References: <1373996430-19854-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <1373996430-19854-2-git-send-email-fabio.estevam@freescale.com>

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/imx6q-wandboard.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q-wandboard.dts b/arch/arm/boot/dts/imx6q-wandboard.dts
index dde9b5d..78e1273 100644
--- a/arch/arm/boot/dts/imx6q-wandboard.dts
+++ b/arch/arm/boot/dts/imx6q-wandboard.dts
@@ -20,3 +20,7 @@
 		reg = <0x10000000 0x80000000>;
 	};
 };
+
+&sata {
+	status = "okay";
+};
-- 
1.8.1.2




From mturquette at linaro.org  Tue Jul 16 13:45:38 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 16 Jul 2013 10:45:38 -0700
Subject: Division by zero caused by CCF
In-Reply-To: <51E5465F.3090801@ti.com>
References: <20130716123709.GA15036@arwen.pp.htv.fi> <51E5465F.3090801@ti.com>
Message-ID: <CAPtuhTiUsLffRaC+8Gd8me2OYeMUOuFM4CqW3vnXmkkp53P_yg@mail.gmail.com>

On Tue, Jul 16, 2013 at 6:10 AM, Eduardo Valentin
<eduardo.valentin at ti.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
> Hi,
>
> Adding Mike's correct address.
>
> On 16-07-2013 08:37, Felipe Balbi wrote:
>> Hi,
>>
>> trying to get USB host verified on OMAP5 uEVM with v3.11-rc1. The
>> clk_set_rate() call ends up in a division by zero, which is quite
>> interesting provided the driver will only call clk_set_rate() if the
>> clock is valid and clk_rate is != 0.
>>
>>
>> [   22.009238] Division by zero in kernel.
>> [   22.009250] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W    3.11.0-rc1-00081-g3310d44-dirty #118
>> [   22.009275] [<c001c83c>] (unwind_backtrace+0x0/0xf0) from [<c0018a1c>] (show_stack+0x10/0x14)
>> [   22.009289] [<c0018a1c>] (show_stack+0x10/0x14) from [<c057403c>] (dump_stack+0x70/0x8c)
>> [   22.009304] [<c057403c>] (dump_stack+0x70/0x8c) from [<c02e4154>] (Ldiv0+0x8/0x10)
>> [   22.009319] [<c02e4154>] (Ldiv0+0x8/0x10) from [<c048d460>] (clk_divider_set_rate+0x10/0xdc)
>> [   22.009331] [<c048d460>] (clk_divider_set_rate+0x10/0xdc) from [<c048c124>] (clk_change_rate+0x38/0xb0)
>> [   22.009341] [<c048c124>] (clk_change_rate+0x38/0xb0) from [<c048c20c>] (clk_set_rate+0x70/0xa8)
>> [   22.009354] [<c048c20c>] (clk_set_rate+0x70/0xa8) from [<c042b244>] (nop_usb_xceiv_probe+0x1fc/0x2f8)
>> [   22.009369] [<c042b244>] (nop_usb_xceiv_probe+0x1fc/0x2f8) from [<c036b47c>] (platform_drv_probe+0x18/0x1c)
>> [   22.009380] [<c036b47c>] (platform_drv_probe+0x18/0x1c) from [<c0369f44>] (really_probe+0x70/0x1f4)
>> [   22.009390] [<c0369f44>] (really_probe+0x70/0x1f4) from [<c036a1dc>] (driver_probe_device+0x30/0x48)
>> [   22.009401] [<c036a1dc>] (driver_probe_device+0x30/0x48) from [<c036a288>] (__driver_attach+0x94/0x98)
>> [   22.009411] [<c036a288>] (__driver_attach+0x94/0x98) from [<c0368748>] (bus_for_each_dev+0x54/0x88)
>> [   22.009420] [<c0368748>] (bus_for_each_dev+0x54/0x88) from [<c036972c>] (bus_add_driver+0xdc/0x29c)
>> [   22.009430] [<c036972c>] (bus_add_driver+0xdc/0x29c) from [<c036a760>] (driver_register+0x78/0x190)
>> [   22.009440] [<c036a760>] (driver_register+0x78/0x190) from [<c00087b0>] (do_one_initcall+0x34/0x164)
>> [   22.009453] [<c00087b0>] (do_one_initcall+0x34/0x164) from [<c07b18f4>] (do_basic_setup+0x90/0xc4)
>> [   22.009466] [<c07b18f4>] (do_basic_setup+0x90/0xc4) from [<c07b199c>] (kernel_init_freeable+0x74/0x110)
>> [   22.009478] [<c07b199c>] (kernel_init_freeable+0x74/0x110) from [<c05676c4>] (kernel_init+0x8/0xe4)
>> [   22.009491] [<c05676c4>] (kernel_init+0x8/0xe4) from [<c0014648>] (ret_from_fork+0x14/0x2c)
>>
>> I believe the problem is the actual division reaching
>> clk_divider_set_rate().
>>
>> drivers/clk/clk-divider.c::clk_divider_set_rate()
>>
>> | static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
>> |                                 unsigned long parent_rate)
>> | {
>> |         struct clk_divider *divider = to_clk_divider(hw);
>> |         unsigned int div, value;
>> |         unsigned long flags = 0;
>> |         u32 val;
>> |
>> |         div = parent_rate / rate;
>>
>> right here, but how come rate would zero provided driver checks for it
>> as below.
>>
>> drivers/usb/phy/phy-nop.c::nop_usb_xceiv_probe()
>>
>> |         if (!IS_ERR(nop->clk) && clk_rate) {
>> |                 err = clk_set_rate(nop->clk, clk_rate);
>> |                 if (err) {
>> |                         dev_err(&pdev->dev, "Error setting clock rate\n");
>> |                         return err;
>> |                 }
>> |         }
>>
>> I've added a few prints around CCF to try and track what's going on:
>>
>> [   21.592690] ====> nop_usb_xceiv_probe rate 19200000
>> [   21.592700] ====> clk_set_rate rate 19200000
>> [   21.592707] ====> clk_calc_new_rates rate 19200000
>> [   21.592713] ====> clk_divider_round_rate rate 19200000
>> [   21.592719] ====> clk_divider_bestdiv rate 19200000
>> [   21.592726] ====> clk_change_rate best_parent_rate 0
>
> or because we reach:
>         if (clk->ops->set_rate)
>                 clk->ops->set_rate(clk->hw, clk->new_rate, best_parent_rate);
>
> with clk->new_rate == 0.

Hmm, I'll look into this. We used to have a check which would at least
WARN on division by zero, but looks like that was replaced by some
other code at some point.

Also does your clock have the CLK_SET_RATE_PARENT flag set? If so then
you could be propagating a rate request of zero up to the next parent,
which would be a neat trick... however based on the dump that doesn't
seem to be what is happening.

Regards,
Mike

>
>
>> [   21.592732] ====> clk_divider_set_rate rate 0
>> [   21.592737] Division by zero in kernel.
>> [   21.592747] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W    3.11.0-rc1-00081-g3310d44-dirty #121
>> [   21.592773] [<c001c83c>] (unwind_backtrace+0x0/0xf0) from [<c0018a1c>] (show_stack+0x10/0x14)
>> [   21.592787] [<c0018a1c>] (show_stack+0x10/0x14) from [<c057400c>] (dump_stack+0x70/0x8c)
>> [   21.592803] [<c057400c>] (dump_stack+0x70/0x8c) from [<c02e4154>] (Ldiv0+0x8/0x10)
>> [   21.592819] [<c02e4154>] (Ldiv0+0x8/0x10) from [<c048d3e0>] (clk_divider_set_rate+0x2c/0x100)
>> [   21.592831] [<c048d3e0>] (clk_divider_set_rate+0x2c/0x100) from [<c048c050>] (clk_change_rate+0x48/0xe0)
>> [   21.592841] [<c048c050>] (clk_change_rate+0x48/0xe0) from [<c048c174>] (clk_set_rate+0x8c/0xc0)
>> [   21.592855] [<c048c174>] (clk_set_rate+0x8c/0xc0) from [<c042b254>] (nop_usb_xceiv_probe+0x20c/0x304)
>> [   21.592869] [<c042b254>] (nop_usb_xceiv_probe+0x20c/0x304) from [<c036b47c>] (platform_drv_probe+0x18/0x1c)
>> [   21.592880] [<c036b47c>] (platform_drv_probe+0x18/0x1c) from [<c0369f44>] (really_probe+0x70/0x1f4)
>> [   21.592891] [<c0369f44>] (really_probe+0x70/0x1f4) from [<c036a1dc>] (driver_probe_device+0x30/0x48)
>> [   21.592901] [<c036a1dc>] (driver_probe_device+0x30/0x48) from [<c036a288>] (__driver_attach+0x94/0x98)
>> [   21.592911] [<c036a288>] (__driver_attach+0x94/0x98) from [<c0368748>] (bus_for_each_dev+0x54/0x88)
>> [   21.592921] [<c0368748>] (bus_for_each_dev+0x54/0x88) from [<c036972c>] (bus_add_driver+0xdc/0x29c)
>> [   21.592930] [<c036972c>] (bus_add_driver+0xdc/0x29c) from [<c036a760>] (driver_register+0x78/0x190)
>> [   21.592941] [<c036a760>] (driver_register+0x78/0x190) from [<c00087b0>] (do_one_initcall+0x34/0x164)
>> [   21.592954] [<c00087b0>] (do_one_initcall+0x34/0x164) from [<c07b18f4>] (do_basic_setup+0x90/0xc4)
>> [   21.592966] [<c07b18f4>] (do_basic_setup+0x90/0xc4) from [<c07b199c>] (kernel_init_freeable+0x74/0x110)
>> [   21.592980] [<c07b199c>] (kernel_init_freeable+0x74/0x110) from [<c0567694>] (kernel_init+0x8/0xe4)
>> [   21.592992] [<c0567694>] (kernel_init+0x8/0xe4) from [<c0014648>] (ret_from_fork+0x14/0x2c)
>>
>> even though driver passed 19.2MHz, best_parent_rate ends up being zero
>> which triggers the division by zero above.
>>
>> cheers
>>
>
>
> - --
> You have got to be excited about what you are doing. (L. Lamport)
>
> Eduardo Valentin
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iF4EAREIAAYFAlHlRl8ACgkQCXcVR3XQvP00XQEAtQgDEJLt8OFCJiIhUj46Zq1h
> PvNq67RSFTRXcq/zHa8A/0IZSPitTXt1TqDfalTKof/DR6n9/W6md8/C2Ovqb59o
> =AKnu
> -----END PGP SIGNATURE-----


From dsd at laptop.org  Tue Jul 16 14:06:05 2013
From: dsd at laptop.org (Daniel Drake)
Date: Tue, 16 Jul 2013 14:06:05 -0400 (EDT)
Subject: [PATCH RESEND 1/2] ARM: mmp: Add compatible entries for OLPC XO
 laptops
Message-ID: <20130716180605.A63C7FAAF3@dev.laptop.org>

Add compatible entries to enable booting of OLPC XO-1.75 (MMP2) and
OLPC XO-4 (MMP3).

Signed-off-by: Chris Ball <cjb at laptop.org>
Signed-off-by: Daniel Drake <dsd at laptop.org>
---
 Documentation/devicetree/bindings/arm/mrvl/intc.txt | 4 ++--
 Documentation/devicetree/bindings/arm/mrvl/mrvl.txt | 8 ++++++++
 arch/arm/mach-mmp/irq.c                             | 1 +
 arch/arm/mach-mmp/mmp2-dt.c                         | 2 ++
 4 files changed, 13 insertions(+), 2 deletions(-)

Resending after 1 month with no response.

diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 8b53273..3554fb9 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -1,8 +1,8 @@
 * Marvell MMP Interrupt controller
 
 Required properties:
-- compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or
-  "mrvl,mmp2-mux-intc"
+- compatible : One of: mrvl,mmp-intc mrvl,mmp2-intc mrvl,mmp3-intc
+  mrvl,mmp2-mux-intc
 - reg : Address and length of the register set of the interrupt controller.
   If the interrupt controller is intc, address and length means the range
   of the whold interrupt controller. If the interrupt controller is mux-intc,
diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
index 117d741..236e884 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
@@ -12,3 +12,11 @@ Required root node properties:
 MMP2 Brownstone Board
 Required root node properties:
 	- compatible = "mrvl,mmp2-brownstone";
+
+OLPC XO-1.75 (CL2) based on MMP2
+Required root node properties:
+	- compatible = "olpc,xo-1.75";
+
+OLPC XO-4 (CL4) based on MMP3
+Required root node properties:
+	- compatible = "olpc,xo-cl4";
diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c
index 3c71246..d60b85a 100644
--- a/arch/arm/mach-mmp/irq.c
+++ b/arch/arm/mach-mmp/irq.c
@@ -329,6 +329,7 @@ void __init mmp2_init_icu(void)
 static const struct of_device_id intc_ids[] __initconst = {
 	{ .compatible = "mrvl,mmp-intc", .data = &mmp_conf },
 	{ .compatible = "mrvl,mmp2-intc", .data = &mmp2_conf },
+	{ .compatible = "mrvl,mmp3-intc", .data = &mmp2_conf },
 	{}
 };
 
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index 4ac2567..e67bd9f 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -44,6 +44,8 @@ static void __init mmp2_dt_init(void)
 
 static const char *mmp2_dt_board_compat[] __initdata = {
 	"mrvl,mmp2-brownstone",
+	"olpc,xo-1.75",
+	"olpc,xo-cl4",
 	NULL,
 };
 
-- 
1.8.1.4



From dsd at laptop.org  Tue Jul 16 14:06:25 2013
From: dsd at laptop.org (Daniel Drake)
Date: Tue, 16 Jul 2013 14:06:25 -0400 (EDT)
Subject: [PATCH RESEND 2/2] ARM: mmp: irq: Improve DT layout
Message-ID: <20130716180625.E0AF1FAAF3@dev.laptop.org>

In the mmp2 device tree, the interrupt mux nodes were peers of the
interrupt controller, yet they mapped registers in conflict with the
interrupt controller's register block. Furthermore, the reg properties of
the muxes disagreed with the unit address specified after the node's @-sign.

Move the interrupt mux nodes underneath the interrupt controller node,
because the registers are subordinate to the interrupt controller device,
and update the documentation accordingly.

In the platform code, avoid using of_address_to_resource(). Treating a
reg value of 0x150 as a resource effectively is mapping to memory
location 0x150, which is not what's happening here. Use of_get_address()
instead, to better reflect that we're dealing with an address offset
being read from the device tree.

This adds support for the device tree shipped in the OLPC XO-4 and
additionally these code changes do not break compatibility with the
old DT layout.

Based on work by Mitch Bradley.

Signed-off-by: Daniel Drake <dsd at laptop.org>
---
 .../devicetree/bindings/arm/mrvl/intc.txt          |  41 ++++---
 arch/arm/boot/dts/mmp2.dtsi                        | 128 ++++++++++-----------
 arch/arm/mach-mmp/irq.c                            |  16 +--
 3 files changed, 95 insertions(+), 90 deletions(-)

Resending after 1 month with no response.

diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 3554fb9..0c020ff 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -2,21 +2,24 @@
 
 Required properties:
 - compatible : One of: mrvl,mmp-intc mrvl,mmp2-intc mrvl,mmp3-intc
-  mrvl,mmp2-mux-intc
-- reg : Address and length of the register set of the interrupt controller.
-  If the interrupt controller is intc, address and length means the range
-  of the whold interrupt controller. If the interrupt controller is mux-intc,
-  address and length means one register. Since address of mux-intc is in the
-  range of intc. mux-intc is secondary interrupt controller.
-- reg-names : Name of the register set of the interrupt controller. It's
-  only required in mux-intc interrupt controller.
-- interrupts : Should be the port interrupt shared by mux interrupts. It's
-  only required in mux-intc interrupt controller.
+- reg : Address and length of the register set of the whole interrupt
+  controller.
 - interrupt-controller : Identifies the node as an interrupt controller.
 - #interrupt-cells : Specifies the number of cells needed to encode an
   interrupt source.
 - mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
   controller.
+
+* Marvell MMP Secondary Interrupt controller (mux)
+
+Required properties:
+ - compatible : Shall be mrvl,mmp2-mux-intc
+  Address and length of one register offset into the register address space of
+  the parent interrupt controller node.
+- reg-names : Name of the register set of the interrupt controller.
+- interrupts : Should be the port interrupt shared by mux interrupts.
+- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
+  controller.
 - mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
   detection first.
 
@@ -27,16 +30,16 @@ Example:
 		#interrupt-cells = <1>;
 		reg = <0xd4282000 0x1000>;
 		mrvl,intc-nr-irqs = <64>;
-	};
 
-	intcmux4 at d4282150 {
-		compatible = "mrvl,mmp2-mux-intc";
-		interrupts = <4>;
-		interrupt-controller;
-		#interrupt-cells = <1>;
-		reg = <0x150 0x4>, <0x168 0x4>;
-		reg-names = "mux status", "mux mask";
-		mrvl,intc-nr-irqs = <2>;
+		intcmux4 at 150 {
+			compatible = "mrvl,mmp2-mux-intc";
+			interrupts = <4>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			reg = <0x150 0x4>, <0x168 0x4>;
+			reg-names = "mux status", "mux mask";
+			mrvl,intc-nr-irqs = <2>;
+		};
 	};
 
 * Marvell Orion Interrupt controller
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 4e8b08c..1f63c8f 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -44,77 +44,77 @@
 				#interrupt-cells = <1>;
 				reg = <0xd4282000 0x1000>;
 				mrvl,intc-nr-irqs = <64>;
-			};
 
-			intcmux4: interrupt-controller at d4282150 {
-				compatible = "mrvl,mmp2-mux-intc";
-				interrupts = <4>;
-				interrupt-controller;
-				#interrupt-cells = <1>;
-				reg = <0x150 0x4>, <0x168 0x4>;
-				reg-names = "mux status", "mux mask";
-				mrvl,intc-nr-irqs = <2>;
-			};
+				intcmux4: interrupt-controller at 150 {
+					compatible = "mrvl,mmp2-mux-intc";
+					interrupts = <4>;
+					interrupt-controller;
+					#interrupt-cells = <1>;
+					reg = <0x150 0x4>, <0x168 0x4>;
+					reg-names = "mux status", "mux mask";
+					mrvl,intc-nr-irqs = <2>;
+				};
 
-			intcmux5: interrupt-controller at d4282154 {
-				compatible = "mrvl,mmp2-mux-intc";
-				interrupts = <5>;
-				interrupt-controller;
-				#interrupt-cells = <1>;
-				reg = <0x154 0x4>, <0x16c 0x4>;
-				reg-names = "mux status", "mux mask";
-				mrvl,intc-nr-irqs = <2>;
-				mrvl,clr-mfp-irq = <1>;
-			};
+				intcmux5: interrupt-controller at 154 {
+					compatible = "mrvl,mmp2-mux-intc";
+					interrupts = <5>;
+					interrupt-controller;
+					#interrupt-cells = <1>;
+					reg = <0x154 0x4>, <0x16c 0x4>;
+					reg-names = "mux status", "mux mask";
+					mrvl,intc-nr-irqs = <2>;
+					mrvl,clr-mfp-irq = <1>;
+				};
 
-			intcmux9: interrupt-controller at d4282180 {
-				compatible = "mrvl,mmp2-mux-intc";
-				interrupts = <9>;
-				interrupt-controller;
-				#interrupt-cells = <1>;
-				reg = <0x180 0x4>, <0x17c 0x4>;
-				reg-names = "mux status", "mux mask";
-				mrvl,intc-nr-irqs = <3>;
-			};
+				intcmux9: interrupt-controller at 180 {
+					compatible = "mrvl,mmp2-mux-intc";
+					interrupts = <9>;
+					interrupt-controller;
+					#interrupt-cells = <1>;
+					reg = <0x180 0x4>, <0x17c 0x4>;
+					reg-names = "mux status", "mux mask";
+					mrvl,intc-nr-irqs = <3>;
+				};
 
-			intcmux17: interrupt-controller at d4282158 {
-				compatible = "mrvl,mmp2-mux-intc";
-				interrupts = <17>;
-				interrupt-controller;
-				#interrupt-cells = <1>;
-				reg = <0x158 0x4>, <0x170 0x4>;
-				reg-names = "mux status", "mux mask";
-				mrvl,intc-nr-irqs = <5>;
-			};
+				intcmux17: interrupt-controller at 158 {
+					compatible = "mrvl,mmp2-mux-intc";
+					interrupts = <17>;
+					interrupt-controller;
+					#interrupt-cells = <1>;
+					reg = <0x158 0x4>, <0x170 0x4>;
+					reg-names = "mux status", "mux mask";
+					mrvl,intc-nr-irqs = <5>;
+				};
 
-			intcmux35: interrupt-controller at d428215c {
-				compatible = "mrvl,mmp2-mux-intc";
-				interrupts = <35>;
-				interrupt-controller;
-				#interrupt-cells = <1>;
-				reg = <0x15c 0x4>, <0x174 0x4>;
-				reg-names = "mux status", "mux mask";
-				mrvl,intc-nr-irqs = <15>;
-			};
+				intcmux35: interrupt-controller at 15c {
+					compatible = "mrvl,mmp2-mux-intc";
+					interrupts = <35>;
+					interrupt-controller;
+					#interrupt-cells = <1>;
+					reg = <0x15c 0x4>, <0x174 0x4>;
+					reg-names = "mux status", "mux mask";
+					mrvl,intc-nr-irqs = <15>;
+				};
 
-			intcmux51: interrupt-controller at d4282160 {
-				compatible = "mrvl,mmp2-mux-intc";
-				interrupts = <51>;
-				interrupt-controller;
-				#interrupt-cells = <1>;
-				reg = <0x160 0x4>, <0x178 0x4>;
-				reg-names = "mux status", "mux mask";
-				mrvl,intc-nr-irqs = <2>;
-			};
+				intcmux51: interrupt-controller at 160 {
+					compatible = "mrvl,mmp2-mux-intc";
+					interrupts = <51>;
+					interrupt-controller;
+					#interrupt-cells = <1>;
+					reg = <0x160 0x4>, <0x178 0x4>;
+					reg-names = "mux status", "mux mask";
+					mrvl,intc-nr-irqs = <2>;
+				};
 
-			intcmux55: interrupt-controller at d4282188 {
-				compatible = "mrvl,mmp2-mux-intc";
-				interrupts = <55>;
-				interrupt-controller;
-				#interrupt-cells = <1>;
-				reg = <0x188 0x4>, <0x184 0x4>;
-				reg-names = "mux status", "mux mask";
-				mrvl,intc-nr-irqs = <2>;
+				intcmux55: interrupt-controller at 188 {
+					compatible = "mrvl,mmp2-mux-intc";
+					interrupts = <55>;
+					interrupt-controller;
+					#interrupt-cells = <1>;
+					reg = <0x188 0x4>, <0x184 0x4>;
+					reg-names = "mux status", "mux mask";
+					mrvl,intc-nr-irqs = <2>;
+				};
 			};
 		};
 
diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c
index d60b85a..ac92433 100644
--- a/arch/arm/mach-mmp/irq.c
+++ b/arch/arm/mach-mmp/irq.c
@@ -342,7 +342,9 @@ int __init mmp2_mux_init(struct device_node *parent)
 {
 	struct device_node *node;
 	const struct of_device_id *of_id;
-	struct resource res;
+	const __be32    *addrp;
+	u64		size;
+	unsigned int	flags;
 	int i, irq_base, ret, irq;
 	u32 nr_irqs, mfp_irq;
 
@@ -360,20 +362,20 @@ int __init mmp2_mux_init(struct device_node *parent)
 			ret = -EINVAL;
 			goto err;
 		}
-		ret = of_address_to_resource(node, 0, &res);
-		if (ret < 0) {
+		addrp = of_get_address(node, 0, &size, &flags);
+		if (addrp == NULL) {
 			pr_err("Not found reg property\n");
 			ret = -EINVAL;
 			goto err;
 		}
-		icu_data[i].reg_status = mmp_icu_base + res.start;
-		ret = of_address_to_resource(node, 1, &res);
-		if (ret < 0) {
+		icu_data[i].reg_status = mmp_icu_base + of_read_ulong(addrp, 1);
+		addrp = of_get_address(node, 1, &size, &flags);
+		if (addrp == NULL) {
 			pr_err("Not found reg property\n");
 			ret = -EINVAL;
 			goto err;
 		}
-		icu_data[i].reg_mask = mmp_icu_base + res.start;
+		icu_data[i].reg_mask = mmp_icu_base + of_read_ulong(addrp, 1);
 		icu_data[i].cascade_irq = irq_of_parse_and_map(node, 0);
 		if (!icu_data[i].cascade_irq) {
 			ret = -EINVAL;
-- 
1.8.1.4



From dsd at laptop.org  Tue Jul 16 14:10:29 2013
From: dsd at laptop.org (Daniel Drake)
Date: Tue, 16 Jul 2013 14:10:29 -0400 (EDT)
Subject: [PATCH RESEND 1/2] clk: mmp: use global clock lock
Message-ID: <20130716181029.C08D8FAAF3@dev.laptop.org>

The mmp platform shares a lock between different clock types, and all
clocks are currently initialized by static bindings.

Move this static/private lock into global context so that it can
easily be shared by clocks that will be defined by the device tree in
followup patches.

Signed-off-by: Daniel Drake <dsd at laptop.org>
---
 drivers/clk/mmp/Makefile   |   2 +-
 drivers/clk/mmp/clk-apbc.c |  38 +++++----------
 drivers/clk/mmp/clk-apmu.c |  20 ++------
 drivers/clk/mmp/clk-mmp2.c | 116 ++++++++++++++++++++++-----------------------
 drivers/clk/mmp/clk.h      |   8 ++--
 drivers/clk/mmp/common.c   |  13 +++++
 6 files changed, 92 insertions(+), 105 deletions(-)
 create mode 100644 drivers/clk/mmp/common.c

Resending after a month without review.

diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 392d780..31aacb5 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -2,7 +2,7 @@
 # Makefile for mmp specific clk
 #
 
-obj-y += clk-apbc.o clk-apmu.o clk-frac.o
+obj-y += common.o clk-apbc.o clk-apmu.o clk-frac.o
 
 obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
 obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
diff --git a/drivers/clk/mmp/clk-apbc.c b/drivers/clk/mmp/clk-apbc.c
index d14120e..89a146a 100644
--- a/drivers/clk/mmp/clk-apbc.c
+++ b/drivers/clk/mmp/clk-apbc.c
@@ -30,7 +30,6 @@ struct clk_apbc {
 	void __iomem		*base;
 	unsigned int		delay;
 	unsigned int		flags;
-	spinlock_t		*lock;
 };
 
 static int clk_apbc_prepare(struct clk_hw *hw)
@@ -43,8 +42,7 @@ static int clk_apbc_prepare(struct clk_hw *hw)
 	 * It may share same register as MUX clock,
 	 * and it will impact FNCLK enable. Spinlock is needed
 	 */
-	if (apbc->lock)
-		spin_lock_irqsave(apbc->lock, flags);
+	spin_lock_irqsave(&mmp_clk_lock, flags);
 
 	data = readl_relaxed(apbc->base);
 	if (apbc->flags & APBC_POWER_CTRL)
@@ -52,33 +50,26 @@ static int clk_apbc_prepare(struct clk_hw *hw)
 	data |= APBC_FNCLK;
 	writel_relaxed(data, apbc->base);
 
-	if (apbc->lock)
-		spin_unlock_irqrestore(apbc->lock, flags);
-
+	spin_unlock_irqrestore(&mmp_clk_lock, flags);
 	udelay(apbc->delay);
-
-	if (apbc->lock)
-		spin_lock_irqsave(apbc->lock, flags);
+	spin_lock_irqsave(&mmp_clk_lock, flags);
 
 	data = readl_relaxed(apbc->base);
 	data |= APBC_APBCLK;
 	writel_relaxed(data, apbc->base);
 
-	if (apbc->lock)
-		spin_unlock_irqrestore(apbc->lock, flags);
+	spin_unlock_irqrestore(&mmp_clk_lock, flags);
 
 	udelay(apbc->delay);
 
 	if (!(apbc->flags & APBC_NO_BUS_CTRL)) {
-		if (apbc->lock)
-			spin_lock_irqsave(apbc->lock, flags);
+		spin_lock_irqsave(&mmp_clk_lock, flags);
 
 		data = readl_relaxed(apbc->base);
 		data &= ~APBC_RST;
 		writel_relaxed(data, apbc->base);
 
-		if (apbc->lock)
-			spin_unlock_irqrestore(apbc->lock, flags);
+		spin_unlock_irqrestore(&mmp_clk_lock, flags);
 	}
 
 	return 0;
@@ -90,8 +81,7 @@ static void clk_apbc_unprepare(struct clk_hw *hw)
 	unsigned long data;
 	unsigned long flags = 0;
 
-	if (apbc->lock)
-		spin_lock_irqsave(apbc->lock, flags);
+	spin_lock_irqsave(&mmp_clk_lock, flags);
 
 	data = readl_relaxed(apbc->base);
 	if (apbc->flags & APBC_POWER_CTRL)
@@ -99,20 +89,15 @@ static void clk_apbc_unprepare(struct clk_hw *hw)
 	data &= ~APBC_FNCLK;
 	writel_relaxed(data, apbc->base);
 
-	if (apbc->lock)
-		spin_unlock_irqrestore(apbc->lock, flags);
-
+	spin_unlock_irqrestore(&mmp_clk_lock, flags);
 	udelay(10);
-
-	if (apbc->lock)
-		spin_lock_irqsave(apbc->lock, flags);
+	spin_lock_irqsave(&mmp_clk_lock, flags);
 
 	data = readl_relaxed(apbc->base);
 	data &= ~APBC_APBCLK;
 	writel_relaxed(data, apbc->base);
 
-	if (apbc->lock)
-		spin_unlock_irqrestore(apbc->lock, flags);
+	spin_unlock_irqrestore(&mmp_clk_lock, flags);
 }
 
 struct clk_ops clk_apbc_ops = {
@@ -122,7 +107,7 @@ struct clk_ops clk_apbc_ops = {
 
 struct clk *mmp_clk_register_apbc(const char *name, const char *parent_name,
 		void __iomem *base, unsigned int delay,
-		unsigned int apbc_flags, spinlock_t *lock)
+		unsigned int apbc_flags)
 {
 	struct clk_apbc *apbc;
 	struct clk *clk;
@@ -141,7 +126,6 @@ struct clk *mmp_clk_register_apbc(const char *name, const char *parent_name,
 	apbc->base = base;
 	apbc->delay = delay;
 	apbc->flags = apbc_flags;
-	apbc->lock = lock;
 	apbc->hw.init = &init;
 
 	clk = clk_register(NULL, &apbc->hw);
diff --git a/drivers/clk/mmp/clk-apmu.c b/drivers/clk/mmp/clk-apmu.c
index abe182b..4f4d8c5 100644
--- a/drivers/clk/mmp/clk-apmu.c
+++ b/drivers/clk/mmp/clk-apmu.c
@@ -24,7 +24,6 @@ struct clk_apmu {
 	void __iomem    *base;
 	u32		rst_mask;
 	u32		enable_mask;
-	spinlock_t	*lock;
 };
 
 static int clk_apmu_enable(struct clk_hw *hw)
@@ -33,14 +32,10 @@ static int clk_apmu_enable(struct clk_hw *hw)
 	unsigned long data;
 	unsigned long flags = 0;
 
-	if (apmu->lock)
-		spin_lock_irqsave(apmu->lock, flags);
-
+	spin_lock_irqsave(&mmp_clk_lock, flags);
 	data = readl_relaxed(apmu->base) | apmu->enable_mask;
 	writel_relaxed(data, apmu->base);
-
-	if (apmu->lock)
-		spin_unlock_irqrestore(apmu->lock, flags);
+	spin_unlock_irqrestore(&mmp_clk_lock, flags);
 
 	return 0;
 }
@@ -51,14 +46,10 @@ static void clk_apmu_disable(struct clk_hw *hw)
 	unsigned long data;
 	unsigned long flags = 0;
 
-	if (apmu->lock)
-		spin_lock_irqsave(apmu->lock, flags);
-
+	spin_lock_irqsave(&mmp_clk_lock, flags);
 	data = readl_relaxed(apmu->base) & ~apmu->enable_mask;
 	writel_relaxed(data, apmu->base);
-
-	if (apmu->lock)
-		spin_unlock_irqrestore(apmu->lock, flags);
+	spin_unlock_irqrestore(&mmp_clk_lock, flags);
 }
 
 struct clk_ops clk_apmu_ops = {
@@ -67,7 +58,7 @@ struct clk_ops clk_apmu_ops = {
 };
 
 struct clk *mmp_clk_register_apmu(const char *name, const char *parent_name,
-		void __iomem *base, u32 enable_mask, spinlock_t *lock)
+		void __iomem *base, u32 enable_mask)
 {
 	struct clk_apmu *apmu;
 	struct clk *clk;
@@ -85,7 +76,6 @@ struct clk *mmp_clk_register_apmu(const char *name, const char *parent_name,
 
 	apmu->base = base;
 	apmu->enable_mask = enable_mask;
-	apmu->lock = lock;
 	apmu->hw.init = &init;
 
 	clk = clk_register(NULL, &apmu->hw);
diff --git a/drivers/clk/mmp/clk-mmp2.c b/drivers/clk/mmp/clk-mmp2.c
index d1f1a19..cb1b0b6 100644
--- a/drivers/clk/mmp/clk-mmp2.c
+++ b/drivers/clk/mmp/clk-mmp2.c
@@ -52,8 +52,6 @@
 #define APMU_CCIC1	0xf4
 #define MPMU_UART_PLL	0x14
 
-static DEFINE_SPINLOCK(clk_lock);
-
 static struct clk_factor_masks uart_factor_masks = {
 	.factor = 2,
 	.num_mask = 0x1fff,
@@ -196,254 +194,254 @@ void __init mmp2_clk_init(void)
 	clk_register_clkdev(clk, "uart_pll", NULL);
 
 	clk = mmp_clk_register_apbc("twsi0", "vctcxo",
-				apbc_base + APBC_TWSI0, 10, 0, &clk_lock);
+				apbc_base + APBC_TWSI0, 10, 0);
 	clk_register_clkdev(clk, NULL, "pxa2xx-i2c.0");
 
 	clk = mmp_clk_register_apbc("twsi1", "vctcxo",
-				apbc_base + APBC_TWSI1, 10, 0, &clk_lock);
+				apbc_base + APBC_TWSI1, 10, 0);
 	clk_register_clkdev(clk, NULL, "pxa2xx-i2c.1");
 
 	clk = mmp_clk_register_apbc("twsi2", "vctcxo",
-				apbc_base + APBC_TWSI2, 10, 0, &clk_lock);
+				apbc_base + APBC_TWSI2, 10, 0);
 	clk_register_clkdev(clk, NULL, "pxa2xx-i2c.2");
 
 	clk = mmp_clk_register_apbc("twsi3", "vctcxo",
-				apbc_base + APBC_TWSI3, 10, 0, &clk_lock);
+				apbc_base + APBC_TWSI3, 10, 0);
 	clk_register_clkdev(clk, NULL, "pxa2xx-i2c.3");
 
 	clk = mmp_clk_register_apbc("twsi4", "vctcxo",
-				apbc_base + APBC_TWSI4, 10, 0, &clk_lock);
+				apbc_base + APBC_TWSI4, 10, 0);
 	clk_register_clkdev(clk, NULL, "pxa2xx-i2c.4");
 
 	clk = mmp_clk_register_apbc("twsi5", "vctcxo",
-				apbc_base + APBC_TWSI5, 10, 0, &clk_lock);
+				apbc_base + APBC_TWSI5, 10, 0);
 	clk_register_clkdev(clk, NULL, "pxa2xx-i2c.5");
 
 	clk = mmp_clk_register_apbc("gpio", "vctcxo",
-				apbc_base + APBC_GPIO, 10, 0, &clk_lock);
+				apbc_base + APBC_GPIO, 10, 0);
 	clk_register_clkdev(clk, NULL, "mmp2-gpio");
 
 	clk = mmp_clk_register_apbc("kpc", "clk32",
-				apbc_base + APBC_KPC, 10, 0, &clk_lock);
+				apbc_base + APBC_KPC, 10, 0);
 	clk_register_clkdev(clk, NULL, "pxa27x-keypad");
 
 	clk = mmp_clk_register_apbc("rtc", "clk32",
-				apbc_base + APBC_RTC, 10, 0, &clk_lock);
+				apbc_base + APBC_RTC, 10, 0);
 	clk_register_clkdev(clk, NULL, "mmp-rtc");
 
 	clk = mmp_clk_register_apbc("pwm0", "vctcxo",
-				apbc_base + APBC_PWM0, 10, 0, &clk_lock);
+				apbc_base + APBC_PWM0, 10, 0);
 	clk_register_clkdev(clk, NULL, "mmp2-pwm.0");
 
 	clk = mmp_clk_register_apbc("pwm1", "vctcxo",
-				apbc_base + APBC_PWM1, 10, 0, &clk_lock);
+				apbc_base + APBC_PWM1, 10, 0);
 	clk_register_clkdev(clk, NULL, "mmp2-pwm.1");
 
 	clk = mmp_clk_register_apbc("pwm2", "vctcxo",
-				apbc_base + APBC_PWM2, 10, 0, &clk_lock);
+				apbc_base + APBC_PWM2, 10, 0);
 	clk_register_clkdev(clk, NULL, "mmp2-pwm.2");
 
 	clk = mmp_clk_register_apbc("pwm3", "vctcxo",
-				apbc_base + APBC_PWM3, 10, 0, &clk_lock);
+				apbc_base + APBC_PWM3, 10, 0);
 	clk_register_clkdev(clk, NULL, "mmp2-pwm.3");
 
 	clk = clk_register_mux(NULL, "uart0_mux", uart_parent,
 				ARRAY_SIZE(uart_parent), CLK_SET_RATE_PARENT,
-				apbc_base + APBC_UART0, 4, 3, 0, &clk_lock);
+				apbc_base + APBC_UART0, 4, 3, 0, &mmp_clk_lock);
 	clk_set_parent(clk, vctcxo);
 	clk_register_clkdev(clk, "uart_mux.0", NULL);
 
 	clk = mmp_clk_register_apbc("uart0", "uart0_mux",
-				apbc_base + APBC_UART0, 10, 0, &clk_lock);
+				apbc_base + APBC_UART0, 10, 0);
 	clk_register_clkdev(clk, NULL, "pxa2xx-uart.0");
 
 	clk = clk_register_mux(NULL, "uart1_mux", uart_parent,
 				ARRAY_SIZE(uart_parent), CLK_SET_RATE_PARENT,
-				apbc_base + APBC_UART1, 4, 3, 0, &clk_lock);
+				apbc_base + APBC_UART1, 4, 3, 0, &mmp_clk_lock);
 	clk_set_parent(clk, vctcxo);
 	clk_register_clkdev(clk, "uart_mux.1", NULL);
 
 	clk = mmp_clk_register_apbc("uart1", "uart1_mux",
-				apbc_base + APBC_UART1, 10, 0, &clk_lock);
+				apbc_base + APBC_UART1, 10, 0);
 	clk_register_clkdev(clk, NULL, "pxa2xx-uart.1");
 
 	clk = clk_register_mux(NULL, "uart2_mux", uart_parent,
 				ARRAY_SIZE(uart_parent), CLK_SET_RATE_PARENT,
-				apbc_base + APBC_UART2, 4, 3, 0, &clk_lock);
+				apbc_base + APBC_UART2, 4, 3, 0, &mmp_clk_lock);
 	clk_set_parent(clk, vctcxo);
 	clk_register_clkdev(clk, "uart_mux.2", NULL);
 
 	clk = mmp_clk_register_apbc("uart2", "uart2_mux",
-				apbc_base + APBC_UART2, 10, 0, &clk_lock);
+				apbc_base + APBC_UART2, 10, 0);
 	clk_register_clkdev(clk, NULL, "pxa2xx-uart.2");
 
 	clk = clk_register_mux(NULL, "uart3_mux", uart_parent,
 				ARRAY_SIZE(uart_parent), CLK_SET_RATE_PARENT,
-				apbc_base + APBC_UART3, 4, 3, 0, &clk_lock);
+				apbc_base + APBC_UART3, 4, 3, 0, &mmp_clk_lock);
 	clk_set_parent(clk, vctcxo);
 	clk_register_clkdev(clk, "uart_mux.3", NULL);
 
 	clk = mmp_clk_register_apbc("uart3", "uart3_mux",
-				apbc_base + APBC_UART3, 10, 0, &clk_lock);
+				apbc_base + APBC_UART3, 10, 0);
 	clk_register_clkdev(clk, NULL, "pxa2xx-uart.3");
 
 	clk = clk_register_mux(NULL, "ssp0_mux", ssp_parent,
 				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
-				apbc_base + APBC_SSP0, 4, 3, 0, &clk_lock);
+				apbc_base + APBC_SSP0, 4, 3, 0, &mmp_clk_lock);
 	clk_register_clkdev(clk, "uart_mux.0", NULL);
 
 	clk = mmp_clk_register_apbc("ssp0", "ssp0_mux",
-				apbc_base + APBC_SSP0, 10, 0, &clk_lock);
+				apbc_base + APBC_SSP0, 10, 0);
 	clk_register_clkdev(clk, NULL, "mmp-ssp.0");
 
 	clk = clk_register_mux(NULL, "ssp1_mux", ssp_parent,
 				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
-				apbc_base + APBC_SSP1, 4, 3, 0, &clk_lock);
+				apbc_base + APBC_SSP1, 4, 3, 0, &mmp_clk_lock);
 	clk_register_clkdev(clk, "ssp_mux.1", NULL);
 
 	clk = mmp_clk_register_apbc("ssp1", "ssp1_mux",
-				apbc_base + APBC_SSP1, 10, 0, &clk_lock);
+				apbc_base + APBC_SSP1, 10, 0);
 	clk_register_clkdev(clk, NULL, "mmp-ssp.1");
 
 	clk = clk_register_mux(NULL, "ssp2_mux", ssp_parent,
 				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
-				apbc_base + APBC_SSP2, 4, 3, 0, &clk_lock);
+				apbc_base + APBC_SSP2, 4, 3, 0, &mmp_clk_lock);
 	clk_register_clkdev(clk, "ssp_mux.2", NULL);
 
 	clk = mmp_clk_register_apbc("ssp2", "ssp2_mux",
-				apbc_base + APBC_SSP2, 10, 0, &clk_lock);
+				apbc_base + APBC_SSP2, 10, 0);
 	clk_register_clkdev(clk, NULL, "mmp-ssp.2");
 
 	clk = clk_register_mux(NULL, "ssp3_mux", ssp_parent,
 				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
-				apbc_base + APBC_SSP3, 4, 3, 0, &clk_lock);
+				apbc_base + APBC_SSP3, 4, 3, 0, &mmp_clk_lock);
 	clk_register_clkdev(clk, "ssp_mux.3", NULL);
 
 	clk = mmp_clk_register_apbc("ssp3", "ssp3_mux",
-				apbc_base + APBC_SSP3, 10, 0, &clk_lock);
+				apbc_base + APBC_SSP3, 10, 0);
 	clk_register_clkdev(clk, NULL, "mmp-ssp.3");
 
 	clk = clk_register_mux(NULL, "sdh_mux", sdh_parent,
 				ARRAY_SIZE(sdh_parent), CLK_SET_RATE_PARENT,
-				apmu_base + APMU_SDH0, 8, 2, 0, &clk_lock);
+				apmu_base + APMU_SDH0, 8, 2, 0, &mmp_clk_lock);
 	clk_register_clkdev(clk, "sdh_mux", NULL);
 
 	clk = clk_register_divider(NULL, "sdh_div", "sdh_mux",
 				CLK_SET_RATE_PARENT, apmu_base + APMU_SDH0,
-				10, 4, CLK_DIVIDER_ONE_BASED, &clk_lock);
+				10, 4, CLK_DIVIDER_ONE_BASED, &mmp_clk_lock);
 	clk_register_clkdev(clk, "sdh_div", NULL);
 
 	clk = mmp_clk_register_apmu("sdh0", "sdh_div", apmu_base + APMU_SDH0,
-				0x1b, &clk_lock);
+				0x1b);
 	clk_register_clkdev(clk, NULL, "sdhci-pxav3.0");
 
 	clk = mmp_clk_register_apmu("sdh1", "sdh_div", apmu_base + APMU_SDH1,
-				0x1b, &clk_lock);
+				0x1b);
 	clk_register_clkdev(clk, NULL, "sdhci-pxav3.1");
 
 	clk = mmp_clk_register_apmu("sdh2", "sdh_div", apmu_base + APMU_SDH2,
-				0x1b, &clk_lock);
+				0x1b);
 	clk_register_clkdev(clk, NULL, "sdhci-pxav3.2");
 
 	clk = mmp_clk_register_apmu("sdh3", "sdh_div", apmu_base + APMU_SDH3,
-				0x1b, &clk_lock);
+				0x1b);
 	clk_register_clkdev(clk, NULL, "sdhci-pxav3.3");
 
 	clk = mmp_clk_register_apmu("usb", "usb_pll", apmu_base + APMU_USB,
-				0x9, &clk_lock);
+				0x9);
 	clk_register_clkdev(clk, "usb_clk", NULL);
 
 	clk = clk_register_mux(NULL, "disp0_mux", disp_parent,
 				ARRAY_SIZE(disp_parent), CLK_SET_RATE_PARENT,
-				apmu_base + APMU_DISP0, 6, 2, 0, &clk_lock);
+				apmu_base + APMU_DISP0, 6, 2, 0, &mmp_clk_lock);
 	clk_register_clkdev(clk, "disp_mux.0", NULL);
 
 	clk = clk_register_divider(NULL, "disp0_div", "disp0_mux",
 				CLK_SET_RATE_PARENT, apmu_base + APMU_DISP0,
-				8, 4, CLK_DIVIDER_ONE_BASED, &clk_lock);
+				8, 4, CLK_DIVIDER_ONE_BASED, &mmp_clk_lock);
 	clk_register_clkdev(clk, "disp_div.0", NULL);
 
 	clk = mmp_clk_register_apmu("disp0", "disp0_div",
-				apmu_base + APMU_DISP0, 0x1b, &clk_lock);
+				apmu_base + APMU_DISP0, 0x1b);
 	clk_register_clkdev(clk, NULL, "mmp-disp.0");
 
 	clk = clk_register_divider(NULL, "disp0_sphy_div", "disp0_mux", 0,
-				apmu_base + APMU_DISP0, 15, 5, 0, &clk_lock);
+				apmu_base + APMU_DISP0, 15, 5, 0, &mmp_clk_lock);
 	clk_register_clkdev(clk, "disp_sphy_div.0", NULL);
 
 	clk = mmp_clk_register_apmu("disp0_sphy", "disp0_sphy_div",
-				apmu_base + APMU_DISP0, 0x1024, &clk_lock);
+				apmu_base + APMU_DISP0, 0x1024);
 	clk_register_clkdev(clk, "disp_sphy.0", NULL);
 
 	clk = clk_register_mux(NULL, "disp1_mux", disp_parent,
 				ARRAY_SIZE(disp_parent), CLK_SET_RATE_PARENT,
-				apmu_base + APMU_DISP1, 6, 2, 0, &clk_lock);
+				apmu_base + APMU_DISP1, 6, 2, 0, &mmp_clk_lock);
 	clk_register_clkdev(clk, "disp_mux.1", NULL);
 
 	clk = clk_register_divider(NULL, "disp1_div", "disp1_mux",
 				CLK_SET_RATE_PARENT, apmu_base + APMU_DISP1,
-				8, 4, CLK_DIVIDER_ONE_BASED, &clk_lock);
+				8, 4, CLK_DIVIDER_ONE_BASED, &mmp_clk_lock);
 	clk_register_clkdev(clk, "disp_div.1", NULL);
 
 	clk = mmp_clk_register_apmu("disp1", "disp1_div",
-				apmu_base + APMU_DISP1, 0x1b, &clk_lock);
+				apmu_base + APMU_DISP1, 0x1b);
 	clk_register_clkdev(clk, NULL, "mmp-disp.1");
 
 	clk = mmp_clk_register_apmu("ccic_arbiter", "vctcxo",
-				apmu_base + APMU_CCIC0, 0x1800, &clk_lock);
+				apmu_base + APMU_CCIC0, 0x1800);
 	clk_register_clkdev(clk, "ccic_arbiter", NULL);
 
 	clk = clk_register_mux(NULL, "ccic0_mux", ccic_parent,
 				ARRAY_SIZE(ccic_parent), CLK_SET_RATE_PARENT,
-				apmu_base + APMU_CCIC0, 6, 2, 0, &clk_lock);
+				apmu_base + APMU_CCIC0, 6, 2, 0, &mmp_clk_lock);
 	clk_register_clkdev(clk, "ccic_mux.0", NULL);
 
 	clk = clk_register_divider(NULL, "ccic0_div", "ccic0_mux",
 				CLK_SET_RATE_PARENT, apmu_base + APMU_CCIC0,
-				17, 4, CLK_DIVIDER_ONE_BASED, &clk_lock);
+				17, 4, CLK_DIVIDER_ONE_BASED, &mmp_clk_lock);
 	clk_register_clkdev(clk, "ccic_div.0", NULL);
 
 	clk = mmp_clk_register_apmu("ccic0", "ccic0_div",
-				apmu_base + APMU_CCIC0, 0x1b, &clk_lock);
+				apmu_base + APMU_CCIC0, 0x1b);
 	clk_register_clkdev(clk, "fnclk", "mmp-ccic.0");
 
 	clk = mmp_clk_register_apmu("ccic0_phy", "ccic0_div",
-				apmu_base + APMU_CCIC0, 0x24, &clk_lock);
+				apmu_base + APMU_CCIC0, 0x24);
 	clk_register_clkdev(clk, "phyclk", "mmp-ccic.0");
 
 	clk = clk_register_divider(NULL, "ccic0_sphy_div", "ccic0_div",
 				CLK_SET_RATE_PARENT, apmu_base + APMU_CCIC0,
-				10, 5, 0, &clk_lock);
+				10, 5, 0, &mmp_clk_lock);
 	clk_register_clkdev(clk, "sphyclk_div", "mmp-ccic.0");
 
 	clk = mmp_clk_register_apmu("ccic0_sphy", "ccic0_sphy_div",
-				apmu_base + APMU_CCIC0, 0x300, &clk_lock);
+				apmu_base + APMU_CCIC0, 0x300);
 	clk_register_clkdev(clk, "sphyclk", "mmp-ccic.0");
 
 	clk = clk_register_mux(NULL, "ccic1_mux", ccic_parent,
 				ARRAY_SIZE(ccic_parent), CLK_SET_RATE_PARENT,
-				apmu_base + APMU_CCIC1, 6, 2, 0, &clk_lock);
+				apmu_base + APMU_CCIC1, 6, 2, 0, &mmp_clk_lock);
 	clk_register_clkdev(clk, "ccic_mux.1", NULL);
 
 	clk = clk_register_divider(NULL, "ccic1_div", "ccic1_mux",
 				CLK_SET_RATE_PARENT, apmu_base + APMU_CCIC1,
-				16, 4, CLK_DIVIDER_ONE_BASED, &clk_lock);
+				16, 4, CLK_DIVIDER_ONE_BASED, &mmp_clk_lock);
 	clk_register_clkdev(clk, "ccic_div.1", NULL);
 
 	clk = mmp_clk_register_apmu("ccic1", "ccic1_div",
-				apmu_base + APMU_CCIC1, 0x1b, &clk_lock);
+				apmu_base + APMU_CCIC1, 0x1b);
 	clk_register_clkdev(clk, "fnclk", "mmp-ccic.1");
 
 	clk = mmp_clk_register_apmu("ccic1_phy", "ccic1_div",
-				apmu_base + APMU_CCIC1, 0x24, &clk_lock);
+				apmu_base + APMU_CCIC1, 0x24);
 	clk_register_clkdev(clk, "phyclk", "mmp-ccic.1");
 
 	clk = clk_register_divider(NULL, "ccic1_sphy_div", "ccic1_div",
 				CLK_SET_RATE_PARENT, apmu_base + APMU_CCIC1,
-				10, 5, 0, &clk_lock);
+				10, 5, 0, &mmp_clk_lock);
 	clk_register_clkdev(clk, "sphyclk_div", "mmp-ccic.1");
 
 	clk = mmp_clk_register_apmu("ccic1_sphy", "ccic1_sphy_div",
-				apmu_base + APMU_CCIC1, 0x300, &clk_lock);
+				apmu_base + APMU_CCIC1, 0x300);
 	clk_register_clkdev(clk, "sphyclk", "mmp-ccic.1");
 }
diff --git a/drivers/clk/mmp/clk.h b/drivers/clk/mmp/clk.h
index ab86dd4..d697d9b 100644
--- a/drivers/clk/mmp/clk.h
+++ b/drivers/clk/mmp/clk.h
@@ -3,6 +3,9 @@
 
 #include <linux/clk-provider.h>
 #include <linux/clkdev.h>
+#include <linux/spinlock.h>
+
+extern spinlock_t mmp_clk_lock;
 
 #define APBC_NO_BUS_CTRL	BIT(0)
 #define APBC_POWER_CTRL		BIT(1)
@@ -24,10 +27,9 @@ extern struct clk *mmp_clk_register_pll2(const char *name,
 		const char *parent_name, unsigned long flags);
 extern struct clk *mmp_clk_register_apbc(const char *name,
 		const char *parent_name, void __iomem *base,
-		unsigned int delay, unsigned int apbc_flags, spinlock_t *lock);
+		unsigned int delay, unsigned int apbc_flags);
 extern struct clk *mmp_clk_register_apmu(const char *name,
-		const char *parent_name, void __iomem *base, u32 enable_mask,
-		spinlock_t *lock);
+		const char *parent_name, void __iomem *base, u32 enable_mask);
 extern struct clk *mmp_clk_register_factor(const char *name,
 		const char *parent_name, unsigned long flags,
 		void __iomem *base, struct clk_factor_masks *masks,
diff --git a/drivers/clk/mmp/common.c b/drivers/clk/mmp/common.c
new file mode 100644
index 0000000..dadce5f
--- /dev/null
+++ b/drivers/clk/mmp/common.c
@@ -0,0 +1,13 @@
+/*
+ * mmp clock common elements
+ *
+ * Copyright (C) 2013 One Laptop per Child
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/spinlock.h>
+
+DEFINE_SPINLOCK(mmp_clk_lock);
-- 
1.8.1.4



From dsd at laptop.org  Tue Jul 16 14:11:19 2013
From: dsd at laptop.org (Daniel Drake)
Date: Tue, 16 Jul 2013 14:11:19 -0400 (EDT)
Subject: [PATCH RESEND 2/2] clk: mmp: add support for DT-defined clocks
Message-ID: <20130716181119.46C08FAAF3@dev.laptop.org>

Add support to the existing mmp clock drivers for clocks to be defined
in the device tree. This will be used on OLPC MMP2/MMP3-based laptops.

If clock info cannot be found in the device tree, we fall back to the
static clock initialization already present.

Signed-off-by: Daniel Drake <dsd at laptop.org>
---
 .../devicetree/bindings/clock/mmp-apbc.txt         | 30 ++++++++++
 .../devicetree/bindings/clock/mmp-apmu.txt         | 30 ++++++++++
 drivers/clk/mmp/clk-apbc.c                         | 66 +++++++++++++++++++++-
 drivers/clk/mmp/clk-apmu.c                         | 37 +++++++++++-
 drivers/clk/mmp/clk-mmp2.c                         | 19 ++++++-
 5 files changed, 179 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/mmp-apbc.txt
 create mode 100644 Documentation/devicetree/bindings/clock/mmp-apmu.txt

Resending after a month without review.

diff --git a/Documentation/devicetree/bindings/clock/mmp-apbc.txt b/Documentation/devicetree/bindings/clock/mmp-apbc.txt
new file mode 100644
index 0000000..88e1253
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp-apbc.txt
@@ -0,0 +1,30 @@
+* Clock bindings for Marvell MMP Advanced Peripheral Bus clock
+
+Parent apb-clock node
+=====================
+Required properties:
+- reg: Address and length of the APB clock unit registers
+
+
+Child peripheral clock nodes
+============================
+Required properties:
+- compatible : shall be "marvell,mmp-apb-clock"
+- #clock-cells : from common clock binding; shall be set to 1
+- clocks : parent clock, from common clock binding
+- clock-output-names : Array of clock names, from common clock binding
+- reg : Array of control register offsets into APB clock unit register space
+
+
+Example:
+apbc: apb-clock {
+	reg = <0xd4015000 0x1000>;
+
+	twsi-clocks {
+		compatible = "marvell,mmp-apb-clock";
+		#clock-cells = <1>;
+		clocks = <&vctvxo-clock>;
+		clock-output-names = "TWSI0", "TWSI1";
+		reg = <0x04 0x08>;
+	};
+};
diff --git a/Documentation/devicetree/bindings/clock/mmp-apmu.txt b/Documentation/devicetree/bindings/clock/mmp-apmu.txt
new file mode 100644
index 0000000..18bb0f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp-apmu.txt
@@ -0,0 +1,30 @@
+* Clock bindings for Marvell MMP Application Subsystem Power Management Unit
+
+Parent apmu-clock node
+=====================
+Required properties:
+- reg: Address and length of the CPU Subsystem PMU registers
+
+
+Child peripheral clock nodes
+============================
+Required properties:
+- compatible : shall be "marvell,mmp-apmu-clock"
+- #clock-cells : from common clock binding; shall be set to 0
+- clocks : parent clock, from common clock binding
+- reg : Control register offsets into parent register space
+- enable-mask : The bits to be set in the register to enable the clock, or
+                cleared to disable.
+
+Example:
+apmu-clock {
+	reg = <0xd4282800 0x1000>;
+
+	usb-clock {
+		compatible = "marvell,mmp-apmu-clock";
+		#clock-cells = <0>;
+		clocks = <&usb_pll>;
+		reg = <0x5c>;
+		enable-mask = <0x09>;
+	};
+};
diff --git a/drivers/clk/mmp/clk-apbc.c b/drivers/clk/mmp/clk-apbc.c
index 89a146a..d53bc79 100644
--- a/drivers/clk/mmp/clk-apbc.c
+++ b/drivers/clk/mmp/clk-apbc.c
@@ -15,6 +15,8 @@
 #include <linux/err.h>
 #include <linux/delay.h>
 #include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
 
 #include "clk.h"
 
@@ -129,8 +131,70 @@ struct clk *mmp_clk_register_apbc(const char *name, const char *parent_name,
 	apbc->hw.init = &init;
 
 	clk = clk_register(NULL, &apbc->hw);
-	if (IS_ERR(clk))
+	if (WARN_ON(IS_ERR(clk)))
 		kfree(apbc);
 
 	return clk;
 }
+
+static void __init mmp_apbc_dt_init(struct device_node *node)
+{
+	struct device_node *parent = of_get_parent(node);
+	const __be32 *regs;
+	struct clk *clk;
+	int rc;
+	int len;
+	int num_clocks;
+	int clock_num;
+	void __iomem *baseaddr;
+	const char *clock_name;
+	const char *parent_name;
+	struct clk **clks;
+	struct clk_onecell_data *clk_data;
+
+	regs = of_get_property(node, "reg", &len);
+	if (WARN_ON(!regs || (len % sizeof(__be32) != 0)))
+		return;
+	num_clocks = len / sizeof(__be32);
+
+	baseaddr = of_iomap(parent, 0);
+	of_node_put(parent);
+	if (WARN_ON(!baseaddr))
+		return;
+
+	clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
+	if (WARN_ON(!clk_data))
+		goto err_clk_data;
+
+	clks = kzalloc(num_clocks * sizeof(*clks), GFP_KERNEL);
+	if (WARN_ON(!clks))
+		goto err_clks;
+
+	clock_name = of_get_property(node, "clock-output-names", NULL);
+	parent_name = of_clk_get_parent_name(node, 0);
+
+	for (clock_num = 0; clock_num < num_clocks; clock_num++) {
+		void __iomem *clock_addr;
+		clock_addr = baseaddr + be32_to_cpup(regs + clock_num);
+
+		clk = mmp_clk_register_apbc(clock_name, parent_name,
+					    clock_addr, 10, 0);
+		if (IS_ERR(clk))
+			return;
+		clock_name += strlen(clock_name) + 1;
+		clks[clock_num] = clk;
+	}
+
+	clk_data->clk_num = num_clocks;
+	clk_data->clks = clks;
+	rc = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+	WARN_ON(rc);
+	return;
+
+err_clks:
+	kfree(clk_data);
+err_clk_data:
+	iounmap(baseaddr);
+
+}
+CLK_OF_DECLARE(mmp2_apbc, "marvell,mmp-apb-clock", mmp_apbc_dt_init);
diff --git a/drivers/clk/mmp/clk-apmu.c b/drivers/clk/mmp/clk-apmu.c
index 4f4d8c5..dfcecc9 100644
--- a/drivers/clk/mmp/clk-apmu.c
+++ b/drivers/clk/mmp/clk-apmu.c
@@ -15,6 +15,8 @@
 #include <linux/err.h>
 #include <linux/delay.h>
 #include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
 
 #include "clk.h"
 
@@ -22,7 +24,6 @@
 struct clk_apmu {
 	struct clk_hw   hw;
 	void __iomem    *base;
-	u32		rst_mask;
 	u32		enable_mask;
 };
 
@@ -85,3 +86,37 @@ struct clk *mmp_clk_register_apmu(const char *name, const char *parent_name,
 
 	return clk;
 }
+
+static void __init mmp_apmu_dt_init(struct device_node *node)
+{
+	struct device_node *parent = of_get_parent(node);
+	const char *clk_name = node->name;
+	void __iomem *baseaddr;
+	struct clk *clk;
+	u32 reg;
+	u32 enable_mask;
+	int rc;
+
+	rc = of_property_read_u32(node, "reg", &reg);
+	if (WARN_ON(rc))
+		return;
+
+	rc = of_property_read_u32(node, "enable-mask", &enable_mask);
+	if (WARN_ON(rc))
+		return;
+
+	baseaddr = of_iomap(parent, 0);
+	of_node_put(parent);
+	if (WARN_ON(!baseaddr))
+		return;
+
+	of_property_read_string(node, "clock-output-names", &clk_name);
+	clk = mmp_clk_register_apmu(clk_name, of_clk_get_parent_name(node, 0),
+				    baseaddr + reg, enable_mask);
+	if (WARN_ON(IS_ERR(clk)))
+		return;
+
+	rc = of_clk_add_provider(node, of_clk_src_simple_get, clk);
+	WARN_ON(rc);
+}
+CLK_OF_DECLARE(mmp2_apmu, "marvell,mmp-apmu-clock", mmp_apmu_dt_init);
diff --git a/drivers/clk/mmp/clk-mmp2.c b/drivers/clk/mmp/clk-mmp2.c
index cb1b0b6..774193b 100644
--- a/drivers/clk/mmp/clk-mmp2.c
+++ b/drivers/clk/mmp/clk-mmp2.c
@@ -15,6 +15,7 @@
 #include <linux/io.h>
 #include <linux/delay.h>
 #include <linux/err.h>
+#include <linux/of.h>
 
 #include <mach/addr-map.h>
 
@@ -73,7 +74,7 @@ static const char *sdh_parent[] = {"pll1_4", "pll2", "usb_pll", "pll1"};
 static const char *disp_parent[] = {"pll1", "pll1_16", "pll2", "vctcxo"};
 static const char *ccic_parent[] = {"pll1_2", "pll1_16", "vctcxo"};
 
-void __init mmp2_clk_init(void)
+static void __init mmp2_clk_init_static(void)
 {
 	struct clk *clk;
 	struct clk *vctcxo;
@@ -445,3 +446,19 @@ void __init mmp2_clk_init(void)
 				apmu_base + APMU_CCIC1, 0x300);
 	clk_register_clkdev(clk, "sphyclk", "mmp-ccic.1");
 }
+
+void __init mmp2_clk_init(void)
+{
+	struct device_node *node;
+
+	/* The presence of the ABP clock node in the device tree indicates
+	 * that we should use the DT for clock setup. */
+	node = of_find_compatible_node(NULL, NULL, "marvell,mmp-apb-clock");
+	if (node) {
+		of_node_put(node);
+		of_clk_init(NULL);
+	} else {
+		/* Fallback to static setup */
+		mmp2_clk_init_static();
+	}
+}
-- 
1.8.1.4



From hauke at hauke-m.de  Tue Jul 16 14:13:09 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Tue, 16 Jul 2013 20:13:09 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <51E56942.8030801@hauke-m.de>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <51E56942.8030801@hauke-m.de>
Message-ID: <51E58D35.4060602@hauke-m.de>

On 07/16/2013 05:39 PM, Hauke Mehrtens wrote:
> On 07/16/2013 05:14 PM, Matt Porter wrote:
>> Hi Hauke,
>>
>> On Tue, Jul 16, 2013 at 03:52:07PM +0200, Hauke Mehrtens wrote:
>>> This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU.
>>> Currently just booting to a shell is working and nothing else, no
>>> Ethernet, wifi, flash, ...
>>>
>>> This SoC uses a Dual core CPU, but this is currently not implemented.
>>> More information about this SoC can be found here:
>>> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers
>>>
>>> Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
>>> ---

....

>>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
>>> new file mode 100644
>>> index 0000000..638350d
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>>> @@ -0,0 +1,72 @@
>>> +/*
>>> + * Broadcom BCM47XX / BCM53XX ARM platform code.
>>> + *
>>> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
>>> + *
>>> + * Licensed under the GNU/GPL. See COPYING for details.
>>> + */
>>> +
>>> +/include/ "skeleton.dtsi"
>>> +
>>> +/ {
>>> +	compatible = "brcm,bcm5301x";
>>
>> Ok, this was nagging at me before I went on my very long vacation. I see
>> the "brcm" vendor prefix as a real consistency problem. I noticed on the
>> bcm281xx/kona family, we have been using "bcm" which is not logged in
>> vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
>> already established use of "brcm" before any of the bcm281xx support
>> came in. Ideally, the vendor prefix should change to "bcm" since every
>> reference in the family names is BCM. However, if others want the least
>> amount of churn in making this consistent, we might have to go with
>> "brcm" across the board.
>>
>> Arnd, any thoughts here?
> 
> I have no problem with bcm or with brcm. This is a Broadcom Chip and
> their names are starting with bcm.
> 
>> Another thing is that this is missing a binding definition for this
>> compatible string. See Documentation/devicetree/bindings/arm/bcm2835.txt
>> for an example. You should split this patch out separately as the DT
>> maintainers generally want to see bindings as a separate patch for easy
>> independent review.
> 
> Ok I will do that. This will then be merged by Linus in the 3.12 merge
> window into a working version or how does this work?
> 
> Currently I have based this patch on top of 3.11-rc1 on which tree
> should I base my changes?

Should I split out the *.dts files in arch/arm/boot/dts/ and the
documentation for brcm,bcm4708 into an other patch?

>> Last thing, compatible strings are not to have wildcards in them. See
>> http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
>> and note the Warning at the bottom. Also see how bcm2835.txt and
>> bcm11351.txt use a specific model.
> 
> Ok will do that.

Do I understand this right that I should currently name it exactly like
the SoC I know and when a new SoC pops up I should make it compatible to
this SoC?

I would change this to:
compatible = "brcm,bcm4708";

If I find a BCM4709 SoC I will add this like to its dts file, assuming
they are mostly the same?
compatible = "brcm,bcm4709", "brcm,bcm4708";

> 
>>> +	model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC";
>>> +	interrupt-parent = <&gic>;
>>> +
>>> +	chosen {
>>> +		bootargs = "console=ttyS0,115200 earlyprintk debug";
>>> +	};
>>> +
>>> +	cpus {
>>> +		#address-cells = <1>;
>>> +		#size-cells = <0>;
>>> +
>>> +		cpu at 0 {
>>> +			device_type = "cpu";
>>> +			compatible = "arm,cortex-a9";
>>> +			reg = <0>;
>>> +		};
>>> +	};
>>> +
>>> +	clocks {
>>> +		#address-cells = <1>;
>>> +		#size-cells = <0>;
>>> +
>>> +		clk_periph: periph {
>>> +			compatible = "fixed-clock";
>>> +			#clock-cells = <0>;
>>> +			clock-frequency = <400000000>;
>>> +		};
>>> +	};
>>> +
>>> +	uart at 18000300 {
>>> +		compatible = "ns16550";
>>> +		reg = <0x18000300 0x100>;
>>> +		interrupts = <0 85 4>;
>>
>> The DT files should be switched to use the C preprocessor like several
>> other machines have already done (see bcm11351.dtsi, for example), you
>> can use the existing GIC includes and have human-redable defines for the
>> edge/level values here and throughout all interrupt properties.
> 
> Ok I will read that and change it.
> 
>>> +		clock-frequency = <100000000>;
>>> +	};
>>> +
>>> +	uart at 18000400 {
>>> +		compatible = "ns16550";
>>> +		reg = <0x18000400 0x100>;
>>> +		interrupts = <0 85 4>;
>>> +		clock-frequency = <100000000>;
>>> +	};
>>> +
>>> +	gic: interrupt-controller at 19021000 {
>>> +		compatible = "arm,cortex-a9-gic";
>>> +		#interrupt-cells = <3>;
>>> +		#address-cells = <0>;
>>> +		interrupt-controller;
>>> +		reg = <0x19021000 0x1000>,
>>> +		      <0x19020100 0x100>;
>>> +	};
>>> +
>>> +	timer at 19020200 {
>>> +		compatible = "arm,cortex-a9-global-timer";
>>> +		reg = <0x19020200 0x100>;
>>> +		interrupts = <1 11 0xf04>;
>>> +		clocks = <&clk_periph>;
>>> +		#clock-cells = <0>;
>>> +	};
>>> +};
>>> diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S
>>> new file mode 100644
>>> index 0000000..98c836b
>>> --- /dev/null
>>> +++ b/arch/arm/include/debug/bcm53xx.S
>>> @@ -0,0 +1,19 @@
>>> +/*
>>> + * Macros used for EARLY_PRINTK, in low-level UART debug console
>>> + *
>>> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
>>> + *
>>> + * Licensed under the GNU/GPL. See COPYING for details.
>>> + */
>>> +
>>> +#define BCM53XX_UART1_PHYS	0x18000300
>>> +#define BCM53XX_UART1_VIRT	0xf1000300
>>> +#define BCM53XX_UART1_SH	0
>>> +
>>> +	.macro	addruart, rp, rv, tmp
>>> +	ldr	\rp, =BCM53XX_UART1_PHYS 	@ MMU off, Physical
>>> +	ldr	\rv, =BCM53XX_UART1_VIRT 	@ MMU on, Virtual
>>> +	.endm
>>> +
>>> +#define UART_SHIFT	BCM53XX_UART1_SH
>>> +#include <asm/hardware/debug-8250.S>
>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig
>>> new file mode 100644
>>> index 0000000..1e16e87
>>> --- /dev/null
>>> +++ b/arch/arm/mach-bcm53xx/Kconfig
>>> @@ -0,0 +1,10 @@
>>> +config ARCH_BCM53XX
>>> +	bool "Broadcom BCM47XX / BCM53XX ARM SoC"
>>> +	select CPU_V7
>>> +	select ARM_GIC
>>> +	select HAVE_CLK
>>> +	select GENERIC_CLOCKEVENTS
>>> +	select GENERIC_TIME
>>> +	select ARM_GLOBAL_TIMER
>>> +	help
>>> +	  Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores.
>>> diff --git a/arch/arm/mach-bcm53xx/Makefile b/arch/arm/mach-bcm53xx/Makefile
>>> new file mode 100644
>>> index 0000000..88da84d
>>> --- /dev/null
>>> +++ b/arch/arm/mach-bcm53xx/Makefile
>>> @@ -0,0 +1 @@
>>> +obj-y += bcm53xx.o
>>> diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c
>>> new file mode 100644
>>> index 0000000..aa5bd397
>>> --- /dev/null
>>> +++ b/arch/arm/mach-bcm53xx/bcm53xx.c
>>> @@ -0,0 +1,68 @@
>>> +/*
>>> + * Broadcom BCM47XX / BCM53XX ARM platform code.
>>> + *
>>> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
>>> + *
>>> + * Licensed under the GNU/GPL. See COPYING for details.
>>> + */
>>> +#include <linux/of_address.h>
>>> +#include <linux/of_platform.h>
>>> +#include <linux/irqchip.h>
>>> +#include <linux/clocksource.h>
>>> +#include <linux/clk-provider.h>
>>> +
>>> +#include <asm/mach/arch.h>
>>> +#include <asm/mach/map.h>
>>> +#include <asm/signal.h>
>>> +
>>> +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
>>> +				 struct pt_regs *regs)
>>> +{
>>> +	/*
>>> +	 * These happen for no good reason
>>> +	 * possibly left over from CFE
>>> +	 */
>>> +	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
>>> +		addr, fsr);
>>> +
>>> +	/* Returning non-zero causes fault display and panic */
>>> +	return 0;
>>> +}
>>> +
>>> +static void bcm53xx_aborts_enable(void)
>>> +{
>>> +	/* Install our hook */
>>> +	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
>>> +			"imprecise external abort");
>>> +}
>>> +
>>> +static void __init bcm53xx_timer_init(void)
>>> +{
>>> +	of_clk_init(NULL);
>>> +	clocksource_of_init();
>>> +}
>>> +
>>> +void __init bcm53xx_map_io(void)
>>> +{
>>> +	debug_ll_io_init();
>>> +	bcm53xx_aborts_enable();
>>> +}
>>> +
>>> +static void __init bcm53xx_dt_init(void)
>>> +{
>>> +	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>>> +}
>>> +
>>> +static const char const *bcm53xx_dt_compat[] = {
>>> +	"brcm,bcm5301x",
>>> +	"netgear,r6250v1",
>>> +	NULL,
>>> +};
>>> +
>>> +DT_MACHINE_START(BCM53XX, "BCM53XX")
>>> +	.init_machine = bcm53xx_dt_init,
>>> +	.map_io = bcm53xx_map_io,
>>> +	.init_irq = irqchip_init,
>>> +	.init_time = bcm53xx_timer_init,
>>> +	.dt_compat = bcm53xx_dt_compat,
>>> +MACHINE_END
>>> -- 
>>> 1.7.10.4
>>>
> 



From sam at ravnborg.org  Tue Jul 16 14:04:08 2013
From: sam at ravnborg.org (Sam Ravnborg)
Date: Tue, 16 Jul 2013 20:04:08 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the
 new streaming format
In-Reply-To: <201307161008.07643.yann.morin.1998@free.fr>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716004727.b60b2c96.akpm@linux-foundation.org>
 <20130716005611.e4ccab02.akpm@linux-foundation.org>
 <201307161008.07643.yann.morin.1998@free.fr>
Message-ID: <20130716180408.GA19863@merkur.ravnborg.org>

On Tue, Jul 16, 2013 at 10:08:07AM +0200, Yann E. MORIN wrote:
> Andrew, All,
> 
> On Tuesday 16 July 2013 09:56:11 Andrew Morton wrote:
> > On Tue, 16 Jul 2013 00:47:27 -0700 Andrew Morton <akpm at linux-foundation.org> wrote:
> > > On Mon, 15 Jul 2013 15:08:20 -0700 "H. Peter Anvin" <hpa at zytor.com> wrote:
> > > > On 07/15/2013 03:03 PM, Andrew Morton wrote:
> [--SNIP--]
> > > > We keep running over the need to be able to have kconfig run tests on
> > > > the build system (for toolchain support or for optional tools needed);
> > > > running them in the Makefiles (i.e. at Kbuild time) is simply too late.
> > > > 
> > > 
> > > Would it make sense to extend Kconfig's `depends'?
> > > 
> > > 	depends on $(shell-command)
> > > 
> > > I don't know how practical that would be to implement...
> 
> I'm afraid this will get rather ugly and not trivial.
> 
> Can we mix 'depends on SYMBOL' and 'depends on $(command)' ?
> Can we mix both in a boolean expression such as 'depends on SYMBOL
> && $(command)' ?
> 
> What would be the condition for evaluating the dependency rule? Evaluation
> at Kconfig read-time might not be enough, given this construct:
> 
>     config FOO
>         depends on $(foo)
>     comment "'foo' is missing, please install it"
>         depends on !$(foo)
> 
> Also, I believe Kconfig should stay a config-only language, without
> much esoteric features.

We could extend the symbol option part to retreive values from a binary.
Something like this:

config FOOBAR
        bool
        option exec="true"

FOOBAR would assume the value "y" if the command true has exit code == 0, otherwise "n".
And similar conversions for other types.

This only extendt Kconfig slightly - using an already present method to import
external values.

The drawback I see with this approach is that we may execute a lot of small programs
where the value is never used.
Implementing lazy evaluation of a symbol value will not be easy I think.

	Sam


From santosh.shilimkar at ti.com  Tue Jul 16 14:35:48 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 16 Jul 2013 14:35:48 -0400
Subject: [PATCH RFC v2 12/14] ARM: debug: move keystone debug to generic
 8250 code
In-Reply-To: <E1Uz8NF-00048J-8B@rmk-PC.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
 <E1Uz8NF-00048J-8B@rmk-PC.arm.linux.org.uk>
Message-ID: <51E59284.7040109@ti.com>

On Tuesday 16 July 2013 12:45 PM, Russell King wrote:
> Keystone's debugging is just a copy of the old 8250_32 code with a
> different base address.  Incorporate this into the generic 8250
> debug code.
> 
> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
> ---
Just tried the series on Keystone EVM and as expected it works.
Thanks for the conversion.

Acked-by: Santosh Shilimkar <santosh.shilimkar at ti.com>



From santosh.shilimkar at ti.com  Tue Jul 16 14:38:48 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 16 Jul 2013 14:38:48 -0400
Subject: [PATCH RFC v2 04/14] ARM: debug: provide 8250 debug uart register
 shift configuration option
In-Reply-To: <E1Uz8FU-00047a-AB@rmk-PC.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
 <E1Uz8FU-00047a-AB@rmk-PC.arm.linux.org.uk>
Message-ID: <51E59338.6020102@ti.com>

On Tuesday 16 July 2013 12:37 PM, Russell King wrote:
> Move the definition of the UART register shift out of the platform
> specific header file into the Kconfig files.
> 
> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
> ---
[..]

> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 07ff149..5b44881 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -275,6 +275,7 @@ choice

[..]
> @@ -857,8 +872,17 @@ config DEBUG_LL_INCLUDE
>  	default "mach/debug-macro.S"
>  
>  config DEBUG_UART_8250
> -	def_bool ARCH_EBSA110 || (FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
> -		ARCH_GEMINI || ARCH_RPC
> +	def_bool ARCH_DOVE || ARCH_EBSA110 || \
> +		(FOOTBRIDGE && !DEBUG_DC21285_PORT) || \
> +		ARCH_GEMINI || ARCH_IOP13XX || ARCH_IOP32X || \
> +		ARCH_IOP33X || ARCH_IXP4XX || ARCH_KIRKWOOD || \
> +		ARCH_LPC32XX || ARCH_MV78XX0 || ARCH_ORION5X || ARCH_RPC
> +
> +config DEBUG_UART_8250_SHIFT
> +	int "Register offset shift for the 8250 debug UART"
> +	depends on DEBUG_UART_8250
> +	default 0 if FOOTBRIDGE || ARCH_IOP32X
> +	default 2
>  
Just a question. Exposing selection choice for UART port
and probably flow control is just fine, but do we need to
really need config entries for SHIFT, PA, VA etc ?

Regards,
Santosh



From santosh.shilimkar at ti.com  Tue Jul 16 14:42:55 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 16 Jul 2013 14:42:55 -0400
Subject: [PATCH 0/8] ARM: mm: Extend the runtime patch stub for PAE systems
In-Reply-To: <alpine.LFD.2.03.1306212149130.18597@syhkavp.arg>
References: <1371858502-10083-1-git-send-email-santosh.shilimkar@ti.com>
 <alpine.LFD.2.03.1306212149130.18597@syhkavp.arg>
Message-ID: <51E5942F.9020701@ti.com>

Russell, Nico,

Ping.

On Friday 21 June 2013 09:51 PM, Nicolas Pitre wrote:
> On Fri, 21 Jun 2013, Santosh Shilimkar wrote:
> 
>> Based on discussion/debate on Cyril's generic code patching framework,
>> we cooked up this series which basically trying to extend the existing
>> v2p runtime patching for LPAE machines which can have physical memory
>> beyond 4 GB. Keystone is one such ARM machine.
>>
>> We think the 64 bit patching can be still made better than the proposed
>> patch in the series and hence seeking expert comments from RMK, Nico and
>> others. Last patch in the series added to just give perspective on how
>> machine code will make use of the available bits from the series.
> 
> FYI I'm currently on vacation and only handling quick emails.
> 
> I'll review your series in a week or so.
> 



From stern at rowland.harvard.edu  Tue Jul 16 14:47:02 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 16 Jul 2013 14:47:02 -0400 (EDT)
Subject: [PATCH v3 6/7] USB: ohci-at91: add usb_clk for transition to
 common clk framework
In-Reply-To: <51E57DFC.5030302@overkiz.com>
Message-ID: <Pine.LNX.4.44L0.1307161441350.1032-100000@iolanthe.rowland.org>

On Tue, 16 Jul 2013, boris brezillon wrote:

> >> +	uclk = clk_get(&pdev->dev, "usb_clk");
> >> +	if (IS_ERR(uclk)) {
> >> +		uclk = NULL;
> >> +		dev_warn(&pdev->dev, "failed to get usb_clk\n");
> >> +	}
> > Is this really what you want for backward compatibility?
> Here are some proposition to remove the warning message:
> 
> 1) replace it with a dev_info and change the message:
>      dev_info(&pdev->dev, "failed to get usb_clk (most likely using old 
> at91 clk implementation)\n");
> 2) drop the log and silently ignore the missing clk (I'm not a big fan 
> of this solution
>      as it may lead to some errors if we're using new clk implem and the 
> clock is really missing)
> 3) rework the current clk_set_rate function to accept clk_set_rate on 
> usb clk and add clk_lookup entries
>      for the usb clk (I'm not a big fan of this solution neither as this 
> modifications will only be used for a short time
>      until the transition to common clk framework is completed).

Another possibility is to combine this change with the clock 
implementation update, and do them in a single patch.  Then backward 
compatibility would not be an issue.

Alan Stern



From gerlando.falauto at keymile.com  Tue Jul 16 14:51:37 2013
From: gerlando.falauto at keymile.com (Gerlando Falauto)
Date: Tue, 16 Jul 2013 20:51:37 +0200
Subject: [PATCH] ARM: Kirkwood: Fix the internal register ranges
 translation
In-Reply-To: <20130716125531.GD2317@localhost>
References: <1371569479-31498-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <51E5145A.90404@keymile.com> <20130716125531.GD2317@localhost>
Message-ID: <51E59639.3000207@keymile.com>

Hi Ezequiel,

On 07/16/2013 02:56 PM, Ezequiel Garcia wrote:
> Hi Gerlando,
>
> On Tue, Jul 16, 2013 at 11:37:30AM +0200, Gerlando Falauto wrote:
>>
>> apologies in advance for commenting on an already-merged patch.
>
> Sure, no problem.
>
>>
>> On 06/18/2013 05:31 PM, Ezequiel Garcia wrote:
>>> Although the internal register window size is 1 MiB, the previous
>>> ranges translation for the internal register space had a size of
>>> 0x4000000. This was done to allow the crypto and nand node to access
>>> the corresponding 'sram' and 'nand' decoding windows.
>>>
>>> In order to describe the hardware more accurately, we declare the
>>> real 1 MiB internal register space in the ranges, and add a translation
>>> entry for the nand node to access the 'nand' window.
>>>
>>> This commit will make future improvements on the MBus DT binding easier.
>>>
>>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8 at public.gmane.org>
>>> ---
>>> Tested on Plathome Openblocks A6 board.
>>>
>>>    arch/arm/boot/dts/kirkwood.dtsi | 5 +++--
>>>    1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
>>> index 8a1e3bb..910fabc 100644
>>> --- a/arch/arm/boot/dts/kirkwood.dtsi
>>> +++ b/arch/arm/boot/dts/kirkwood.dtsi
>>> @@ -38,7 +38,8 @@
>>>
>>>    	ocp at f1000000 {
>>>    		compatible = "simple-bus";
>>> -		ranges = <0x00000000 0xf1000000 0x4000000
>>> +		ranges = <0x00000000 0xf1000000 0x0100000
>>> +		          0xf4000000 0xf4000000 0x0000400
>>>    		          0xf5000000 0xf5000000 0x0000400>;
>>
>> Apart from "consistency" with the following range (0xf5000000) used by
>> the crypto node, is there any reason why you did not do something like
>> this instead (which Valentin suggested, but I will take the blame for):
>>
>
> I'm not sure the reason is "consistency with the crypto node".
> There's an MBus window at 0xf4000000 for NAND, and that is what is described
> in the snippet above; and this is a better reason.
>
> That said, technically speaking, you can have any translation scheme you want,
> as long as it ends up in 0xf4000000.
>
>> -		ranges = <0x00000000 0xf1000000 0x4000000
>> +		ranges = <0x00000000 0xf1000000 0x0100000
>> +		          0x03000000 0xf4000000 0x0000400
>>     		          0xf5000000 0xf5000000 0x0000400>;
>>
>> This would keep a consistent addressing within the child device bus, and
>
> Could you explain how this "keeps a consistent addressing"?
> Frankly, I don't understand why you choose 0x3000000 ... am I missing something?

Actually, the only one missing something here is myself, as I do not 
quite have the full picture :-)
Mine was a bit of a "reverse allocation" -- we know we must end up at 
0xf4000000. Since all the addresses are shifted by 0xf1000000, here 
comes 0x03000000... But please see my last question further down.

>
> Also, speaking of "device bus" this nand node should be behind a devicebus node.
>
> 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000   /* internal-regs */
> 			  MBUS_ID(0x01, 0x2f) 0 0 0xf4000000 0x400>;
>
> 		devbus {
> 			status = "okay";
> 			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x400>;
>
> 			/* nand */
> 			nand {
> 				compatible = "marvell,orion-nand";
> 				reg = <0 0x400>;
> 			};
> 		};

I believe that makes a lot more sense this way... I guess this feature 
(device bus) requires your latest set of patches, right? (either v7 as 
you posted yesterday or your tree at 
git://github.com/MISL-EBU-System-SW/mainline-public.git/marvell-mvebu-mbus-v7)

> (notice this will allow you to relocate the base address of the NAND windows
> easily if it conflicts with your PCIe needs).

I sort of had the impression I could do already do that somehow, though 
I am not quite sure anymore...

>> avoid a later incosistency between the "unit-address" and the first
>> "reg" address:
>>
>>>    		#address-cells = <1>;
>>>    		#size-cells = <1>;
>>> @@ -171,7 +172,7 @@
>>   >   		nand at 3000000 {
>> 		     ^^^^^^^
>
> Oh, this should be fixed. I just missed it, and nobody noticed either.
>

So, in the end, you think it's OK to have a set of nodes with "relative" 
addresses (gpio at 10140, serial at 12000 etc...) and some with "absolute" 
addresses (nand at 0xf4000000, where the ranges property does a 0-offset 
translation)?
Even though I understand this is just some transitional state, and it 
will all be fixed like your example above, once we get the rest of the 
rework merged (mbus/devbus).

Thanks a lot for your patience!
Gerlando


From zonque at gmail.com  Tue Jul 16 14:52:57 2013
From: zonque at gmail.com (Daniel Mack)
Date: Tue, 16 Jul 2013 20:52:57 +0200
Subject: [PATCH] ARM: omap2: fix musb usage for n8x0
Message-ID: <1374000777-5626-1-git-send-email-zonque@gmail.com>

Commit b7e2e75a8c ("usb: gadget: drop unused USB_GADGET_MUSB_HDRC")
dropped a config symbol that was unused by the musb core, but it turns
out that board support code had references to it.

As the core now has a fall-back to host-only mode if support for
dual-role is not compiled in, so we can just pass MUSB_OTG as
mode from board files.

Signed-off-by: Daniel Mack <zonque at gmail.com>
Reported-and-tested-by: Aaro Koskinen <aaro.koskinen at iki.fi>
---
 arch/arm/mach-omap2/board-n8x0.c | 4 ----
 arch/arm/mach-omap2/usb-musb.c   | 5 +----
 2 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index f6eeb87..827d150 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -122,11 +122,7 @@ static struct musb_hdrc_config musb_config = {
 };
 
 static struct musb_hdrc_platform_data tusb_data = {
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
 	.mode		= MUSB_OTG,
-#else
-	.mode		= MUSB_HOST,
-#endif
 	.set_power	= tusb_set_power,
 	.min_power	= 25,	/* x2 = 50 mA drawn from VBUS as peripheral */
 	.power		= 100,	/* Max 100 mA VBUS for host mode */
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 8c4de27..bc89723 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -38,11 +38,8 @@ static struct musb_hdrc_config musb_config = {
 };
 
 static struct musb_hdrc_platform_data musb_plat = {
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
 	.mode		= MUSB_OTG,
-#else
-	.mode		= MUSB_HOST,
-#endif
+
 	/* .clock is set dynamically */
 	.config		= &musb_config,
 
-- 
1.8.1.4



From jic23 at kernel.org  Tue Jul 16 15:03:38 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Tue, 16 Jul 2013 20:03:38 +0100
Subject: [PATCH 2/5] iio: at91: Use different prescal, startup mask in
 MR for different IP
In-Reply-To: <20130716133003.7c208cdf@skate>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
 <20130715125815.GC2962@lukather> <51E505EA.4060502@atmel.com>
 <51E50864.6020904@atmel.com> <20130716133003.7c208cdf@skate>
Message-ID: <51E5990A.4050709@kernel.org>

On 07/16/2013 12:30 PM, Thomas Petazzoni wrote:
> Dear Nicolas Ferre,
> 
> On Tue, 16 Jul 2013 10:46:28 +0200, Nicolas Ferre wrote:
> 
>>> Ok, that make sense. I will use compatible names for the capabilities in
>>> next version. Thanks.
>>
>> Hold on a little bit Josh, I know that Jean-Christophe is not in favor 
>> of the use of multiple compatible strings. So, as the code is already 
>> there, let's wait and see if we find another argument...
> 
> I've asked exactly this question last week at Linaro Connect during the
> ARM SoC consolidation panel/discussion, where Grant Likely, Arnd
> Bergmann, Olof and others were answering Device Tree related questions.
> 
> My question, which precisely had the at91-adc DT binding in mind was
> precisely whether we should use different compatible properties to
> identify different revisions of an IP block and let the driver handle
> those differences, or whether the DT binding should provide sufficient
> properties (register offsets, bit numbers, etc.) to make the driver
> independent of the IP revisions. And clearly, the answer was that
> different compatible properties should be used to identify the
> different versions of the IP block, and the driver should abstract out
> the differences. I.e, was has been done for at91-adc is completely the
> opposite of the best practices for Device Tree on ARM.
> 
> See
> http://www.youtube.com/watch?v=zF_AXLgkFy4&feature=player_detailpage#t=1581s
> where I ask exactly this question, and get answers from Olof Johansson
> and Grant Likely. They clearly say that the solution of having separate
> compatible properties and a driver that handles the differences is the
> way to go. So the way at91-adc (and possibly other at91 drivers) is
> using the Device Tree is wrong, there should have been multiple
> compatible properties. It's a shame because this is something we did say
> when we submitted at91-adc and during the reviews, but the maintainer
> wasn't listening to our comments...
> 

Thanks for getting some clarity on this Thomas.  So I'll ask the somewhat obvious
question - how do we unwind from where we are to where we want to be wrt to the
bindings?





From b.brezillon at overkiz.com  Tue Jul 16 15:06:10 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Tue, 16 Jul 2013 21:06:10 +0200
Subject: [PATCH v3 6/7] USB: ohci-at91: add usb_clk for transition to
 common clk framework
In-Reply-To: <Pine.LNX.4.44L0.1307161441350.1032-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307161441350.1032-100000@iolanthe.rowland.org>
Message-ID: <51E599A2.3040306@overkiz.com>

On 16/07/2013 20:47, Alan Stern wrote:
> On Tue, 16 Jul 2013, boris brezillon wrote:
>
>>>> +	uclk = clk_get(&pdev->dev, "usb_clk");
>>>> +	if (IS_ERR(uclk)) {
>>>> +		uclk = NULL;
>>>> +		dev_warn(&pdev->dev, "failed to get usb_clk\n");
>>>> +	}
>>> Is this really what you want for backward compatibility?
>> Here are some proposition to remove the warning message:
>>
>> 1) replace it with a dev_info and change the message:
>>       dev_info(&pdev->dev, "failed to get usb_clk (most likely using old
>> at91 clk implementation)\n");
>> 2) drop the log and silently ignore the missing clk (I'm not a big fan
>> of this solution
>>       as it may lead to some errors if we're using new clk implem and the
>> clock is really missing)
>> 3) rework the current clk_set_rate function to accept clk_set_rate on
>> usb clk and add clk_lookup entries
>>       for the usb clk (I'm not a big fan of this solution neither as this
>> modifications will only be used for a short time
>>       until the transition to common clk framework is completed).
> Another possibility is to combine this change with the clock
> implementation update, and do them in a single patch.  Then backward
> compatibility would not be an issue.
Yes, that was one of the question I asked in the cover-letter.

I think I'll move these patches in the "move to common clk" series.

Thanks
> Alan Stern
>



From hauke at hauke-m.de  Tue Jul 16 15:14:21 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Tue, 16 Jul 2013 21:14:21 +0200
Subject: [RFC v2 1/2] ARM: BCM53XX: initial support for the BCM5301/BCM470X
 SoCs with ARM CPU
Message-ID: <1374002062-28952-1-git-send-email-hauke@hauke-m.de>

This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPUs.
Currently just booting to a shell is working and nothing else, no
Ethernet, wifi, flash, ...

This SoC is used in Small office and Home Router with Broadcom SoCs.
This code should support the BCM4707, BCM4708, BCM4709, BCM53010,
BCM53011 and BCM53012 SoC. It uses one or two ARM Cortex A9
Cores, some highlights are 2 PCIe 2.0 controllers, 4 Gigabit Ethernet
MACs and a USB 3.0 host controller.

This SoC uses a Dual core CPU, but this is currently not implemented.
More information about this SoC can be found here:
http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers

Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
---

A bootlog can be found here:
http://pastebin.com/0MYYC7Fx

Changes since v1:
 * add file Documentation/devicetree/bindings/arm/bcm4708.txt
 * rename bcm5301x to bcm4708 in dts files
 * use preprocessor includes in dts file
 * add CONFIG_ARCH_BCM53XX to multi_v7_defconfig
 * remove init_machine callback
 * rename vendor prefix from brcm to bcm
 * split into two patches


 Documentation/devicetree/bindings/arm/bcm4708.txt |    8 +++
 MAINTAINERS                                       |    8 +++
 arch/arm/Kconfig                                  |    2 +
 arch/arm/Kconfig.debug                            |    5 ++
 arch/arm/Makefile                                 |    1 +
 arch/arm/boot/dts/Makefile                        |    1 +
 arch/arm/configs/multi_v7_defconfig               |    1 +
 arch/arm/include/debug/bcm53xx.S                  |   19 +++++++
 arch/arm/mach-bcm53xx/Kconfig                     |   10 ++++
 arch/arm/mach-bcm53xx/Makefile                    |    1 +
 arch/arm/mach-bcm53xx/bcm53xx.c                   |   61 +++++++++++++++++++++
 11 files changed, 117 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm4708.txt
 create mode 100644 arch/arm/include/debug/bcm53xx.S
 create mode 100644 arch/arm/mach-bcm53xx/Kconfig
 create mode 100644 arch/arm/mach-bcm53xx/Makefile
 create mode 100644 arch/arm/mach-bcm53xx/bcm53xx.c

diff --git a/Documentation/devicetree/bindings/arm/bcm4708.txt b/Documentation/devicetree/bindings/arm/bcm4708.txt
new file mode 100644
index 0000000..2d4588c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm4708.txt
@@ -0,0 +1,8 @@
+Broadcom BCM4708 device tree bindings
+-------------------------------------------
+
+Boards with the BCM4708 SoC shall have the following properties:
+
+Required root node property:
+
+compatible = "bcm,bcm4708";
diff --git a/MAINTAINERS b/MAINTAINERS
index bf61e04..ade242b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1795,6 +1795,14 @@ F:	arch/arm/boot/dts/bcm2835*
 F:	arch/arm/configs/bcm2835_defconfig
 F:	drivers/*/*bcm2835*
 
+BROADCOM BCM53XX ARM ARCHICTURE
+M:	Hauke Mehrtens <hauke at hauke-m.de>
+L:	linux-arm-kernel at lists.infradead.org
+S:	Maintained
+F:	arch/arm/mach-bcm53xx/
+F:	arch/arm/boot/dts/bcm53*
+F:	arch/arm/boot/dts/bcm47*
+
 BROADCOM TG3 GIGABIT ETHERNET DRIVER
 M:	Nithin Nayak Sujir <nsujir at broadcom.com>
 M:	Michael Chan <mchan at broadcom.com>
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..ee7362e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -930,6 +930,8 @@ source "arch/arm/mach-bcm/Kconfig"
 
 source "arch/arm/mach-bcm2835/Kconfig"
 
+source "arch/arm/mach-bcm53xx/Kconfig"
+
 source "arch/arm/mach-clps711x/Kconfig"
 
 source "arch/arm/mach-cns3xxx/Kconfig"
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e401a76..74e32f6 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -93,6 +93,10 @@ choice
 		bool "Kernel low-level debugging on BCM2835 PL011 UART"
 		depends on ARCH_BCM2835
 
+	config DEBUG_BCM53XX
+		bool "Kernel low-level debugging on BCM53XX UART1"
+		depends on ARCH_BCM53XX
+
 	config DEBUG_CLPS711X_UART1
 		bool "Kernel low-level debugging messages via UART1"
 		depends on ARCH_CLPS711X
@@ -762,6 +766,7 @@ endchoice
 config DEBUG_LL_INCLUDE
 	string
 	default "debug/bcm2835.S" if DEBUG_BCM2835
+	default "debug/bcm53xx.S" if DEBUG_BCM53XX
 	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
 	default "debug/exynos.S" if DEBUG_EXYNOS_UART
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c0ac0f5..4a69cd5 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 machine-$(CONFIG_ARCH_AT91)		+= at91
 machine-$(CONFIG_ARCH_BCM)		+= bcm
 machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
+machine-$(CONFIG_ARCH_BCM53XX)		+= bcm53xx
 machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
 machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
 machine-$(CONFIG_ARCH_DAVINCI)		+= davinci
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..28c3351b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -242,6 +242,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
 dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
 	zynq-zc706.dtb \
 	zynq-zed.dtb
+dtb-$(CONFIG_ARCH_BCM53XX) += bcm4708-netgear-r6250.dtb
 
 targets += dtbs
 targets += $(dtb-y)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index fe0bdc3..1d52727 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -6,6 +6,7 @@ CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_XP=y
 CONFIG_ARCH_BCM=y
+CONFIG_ARCH_BCM53XX=y
 CONFIG_GPIO_PCA953X=y
 CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_KEYSTONE=y
diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S
new file mode 100644
index 0000000..98c836b
--- /dev/null
+++ b/arch/arm/include/debug/bcm53xx.S
@@ -0,0 +1,19 @@
+/*
+ * Macros used for EARLY_PRINTK, in low-level UART debug console
+ *
+ * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#define BCM53XX_UART1_PHYS	0x18000300
+#define BCM53XX_UART1_VIRT	0xf1000300
+#define BCM53XX_UART1_SH	0
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =BCM53XX_UART1_PHYS 	@ MMU off, Physical
+	ldr	\rv, =BCM53XX_UART1_VIRT 	@ MMU on, Virtual
+	.endm
+
+#define UART_SHIFT	BCM53XX_UART1_SH
+#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig
new file mode 100644
index 0000000..1e16e87
--- /dev/null
+++ b/arch/arm/mach-bcm53xx/Kconfig
@@ -0,0 +1,10 @@
+config ARCH_BCM53XX
+	bool "Broadcom BCM47XX / BCM53XX ARM SoC"
+	select CPU_V7
+	select ARM_GIC
+	select HAVE_CLK
+	select GENERIC_CLOCKEVENTS
+	select GENERIC_TIME
+	select ARM_GLOBAL_TIMER
+	help
+	  Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores.
diff --git a/arch/arm/mach-bcm53xx/Makefile b/arch/arm/mach-bcm53xx/Makefile
new file mode 100644
index 0000000..88da84d
--- /dev/null
+++ b/arch/arm/mach-bcm53xx/Makefile
@@ -0,0 +1 @@
+obj-y += bcm53xx.o
diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c
new file mode 100644
index 0000000..912d9dd
--- /dev/null
+++ b/arch/arm/mach-bcm53xx/bcm53xx.c
@@ -0,0 +1,61 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/irqchip.h>
+#include <linux/clocksource.h>
+#include <linux/clk-provider.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/signal.h>
+
+static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason
+	 * possibly left over from CFE
+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+
+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void bcm53xx_aborts_enable(void)
+{
+	/* Install our hook */
+	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
+			"imprecise external abort");
+}
+
+void __init bcm53xx_map_io(void)
+{
+	debug_ll_io_init();
+	bcm53xx_aborts_enable();
+}
+
+static void __init bcm53xx_timer_init(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+static const char const *bcm53xx_dt_compat[] = {
+	"bcm,bcm4708",
+	NULL,
+};
+
+DT_MACHINE_START(BCM53XX, "BCM53XX")
+	.map_io = bcm53xx_map_io,
+	.init_irq = irqchip_init,
+	.init_time = bcm53xx_timer_init,
+	.dt_compat = bcm53xx_dt_compat,
+MACHINE_END
-- 
1.7.10.4



From thomas.petazzoni at free-electrons.com  Tue Jul 16 15:17:06 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Jul 2013 21:17:06 +0200
Subject: [PATCH 2/5] iio: at91: Use different prescal, startup mask in
 MR for different IP
In-Reply-To: <51E5990A.4050709@kernel.org>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
 <20130715125815.GC2962@lukather> <51E505EA.4060502@atmel.com>
 <51E50864.6020904@atmel.com> <20130716133003.7c208cdf@skate>
 <51E5990A.4050709@kernel.org>
Message-ID: <20130716211706.39665234@skate>

Dear Jonathan Cameron,

On Tue, 16 Jul 2013 20:03:38 +0100, Jonathan Cameron wrote:

> On 07/16/2013 12:30 PM, Thomas Petazzoni wrote:
> > I've asked exactly this question last week at Linaro Connect during the
> > ARM SoC consolidation panel/discussion, where Grant Likely, Arnd
> > Bergmann, Olof and others were answering Device Tree related questions.
> > 
> > My question, which precisely had the at91-adc DT binding in mind was
> > precisely whether we should use different compatible properties to
> > identify different revisions of an IP block and let the driver handle
> > those differences, or whether the DT binding should provide sufficient
> > properties (register offsets, bit numbers, etc.) to make the driver
> > independent of the IP revisions. And clearly, the answer was that
> > different compatible properties should be used to identify the
> > different versions of the IP block, and the driver should abstract out
> > the differences. I.e, was has been done for at91-adc is completely the
> > opposite of the best practices for Device Tree on ARM.
> > 
> > See
> > http://www.youtube.com/watch?v=zF_AXLgkFy4&feature=player_detailpage#t=1581s
> > where I ask exactly this question, and get answers from Olof Johansson
> > and Grant Likely. They clearly say that the solution of having separate
> > compatible properties and a driver that handles the differences is the
> > way to go. So the way at91-adc (and possibly other at91 drivers) is
> > using the Device Tree is wrong, there should have been multiple
> > compatible properties. It's a shame because this is something we did say
> > when we submitted at91-adc and during the reviews, but the maintainer
> > wasn't listening to our comments...
> > 
> 
> Thanks for getting some clarity on this Thomas.  So I'll ask the somewhat obvious
> question - how do we unwind from where we are to where we want to be wrt to the
> bindings?

During Linaro Connect last week, there was some discussion about
marking DT bindings as unstable for a little while, once they get
reviewed by a group of DT "experts" that mark them as stable. Until
they are stable, the kernel does not offer any ABI guarantees, and we
are free to change the DT bindings as needed.

Now, since this unstable/stable thing is not in place at the moment,
deciding whether to break or not existing bindings is something to be
decided by the maintainer of this platform, judging what is the best
option depending on whether there are already many users of the DT for
this platform or not, for example.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From linux at arm.linux.org.uk  Tue Jul 16 15:16:58 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 16 Jul 2013 20:16:58 +0100
Subject: [PATCH RFC v2 04/14] ARM: debug: provide 8250 debug uart
 register shift configuration option
In-Reply-To: <51E59338.6020102@ti.com>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
 <E1Uz8FU-00047a-AB@rmk-PC.arm.linux.org.uk> <51E59338.6020102@ti.com>
Message-ID: <20130716191658.GG24642@n2100.arm.linux.org.uk>

On Tue, Jul 16, 2013 at 02:38:48PM -0400, Santosh Shilimkar wrote:
> Just a question. Exposing selection choice for UART port
> and probably flow control is just fine, but do we need to
> really need config entries for SHIFT, PA, VA etc ?

Let's look at the original problem.  We have lots of files in
arch/arm/include/debug who's sole purpose is to define a pair of base
addresses.  Maybe around 500 lines of code doing just that - though
much of it is copyright notices (can someone explain to me the point
of claiming copyright on four lines of code defining a base address of
a UART which is, apart from the addresses themselves, identical with
every other damned file?)

What this series does is remove many of those files by consolidating
much of them into a much denser way to represent all this variability.
However, this doesn't really address the root problem, which is that
we have all this information in the kernel, which needs to be added
to every single time we have a new platform come along no matter what
it is.

We need to stop that from happening - we need a way for people to tell
the kernel where their UART is without having to load the kernel up
with lots of platform specific information [*].

Also, even without this, the debug menu has become something of a
sprawling mess, with various people re-implementing what's already
there presumably because they don't look/don't bother to research what
support is already there - and is another source of constant additions.

So, the idea that every platform gets to somehow put its UART addresses
into the kernel image isn't scalable.  Either we end up with lots of
defaults in a Kconfig wihch are also prone to merge conflicts, or we
end up with lots of files in arch/arm/include/debug defining the base
addresses.

We need to stop all of these problems from happening before they
become a big headache for us - imagine Linus' reaction when our debug
menu grows to be the largest Kconfig file in the kernel tree!  Do you
want to be there when that happens?  We're the 22nd biggest Kconfig
file already at 25K - there's only one debug Kconfig larger and that's
the main lib/Kconfig.debug one which has recently been through a cleanup.

Therefore, the idea is to provide _generic_ options which people can
set according to their platforms needs.  Remember, this is *supposed*
to be a developer tool, not a user tool, so asking for addresses and
other parameters is perfectly acceptable - just make sure that they're
documented in a reasonable place.


Lastly, if you want to moan at someone about this, you only have to look
at the hardware guys who have made ARM hardware be soo diverse that we
have ended up with all these different implementations in the first place.
It is *their* problem that we have every platform doing this basic stuff
differently, and it is they who need to realise that this mentality
doesn't scale and hurts.  The "oh it's just software, they can deal
with it" attitude needs to be fought.


* - We've been around all the discussions before about getting this
information from DT, and quite frankly I'm *really* not in the mood for
a rehash of those arguments yet again - we'll only end up at the same
point.  (If anyone feels that they need to state their opinion on that,
please *first* go back and read the previous discussions about what the
LL debug infrastructure is about, it's purpose, etc.  If you don't do
your homework before piping up, I'm not going to bother replying to you.)



From linux at arm.linux.org.uk  Tue Jul 16 15:24:04 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 16 Jul 2013 20:24:04 +0100
Subject: [PATCH RFC v2 04/14] ARM: debug: provide 8250 debug uart
 register shift configuration option
In-Reply-To: <20130716191658.GG24642@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
 <E1Uz8FU-00047a-AB@rmk-PC.arm.linux.org.uk> <51E59338.6020102@ti.com>
 <20130716191658.GG24642@n2100.arm.linux.org.uk>
Message-ID: <20130716192403.GA13150@n2100.arm.linux.org.uk>

On Tue, Jul 16, 2013 at 08:16:58PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 16, 2013 at 02:38:48PM -0400, Santosh Shilimkar wrote:
> > Just a question. Exposing selection choice for UART port
> > and probably flow control is just fine, but do we need to
> > really need config entries for SHIFT, PA, VA etc ?
> 
> Let's look at the original problem.  We have lots of files in
> arch/arm/include/debug who's sole purpose is to define a pair of base
> addresses.  Maybe around 500 lines of code doing just that - though
> much of it is copyright notices (can someone explain to me the point
> of claiming copyright on four lines of code defining a base address of
> a UART which is, apart from the addresses themselves, identical with
> every other damned file?)
> 
> What this series does is remove many of those files by consolidating
> much of them into a much denser way to represent all this variability.
> However, this doesn't really address the root problem, which is that
> we have all this information in the kernel, which needs to be added
> to every single time we have a new platform come along no matter what
> it is.
> 
> We need to stop that from happening - we need a way for people to tell
> the kernel where their UART is without having to load the kernel up
> with lots of platform specific information [*].
> 
> Also, even without this, the debug menu has become something of a
> sprawling mess, with various people re-implementing what's already
> there presumably because they don't look/don't bother to research what
> support is already there - and is another source of constant additions.
> 
> So, the idea that every platform gets to somehow put its UART addresses
> into the kernel image isn't scalable.  Either we end up with lots of
> defaults in a Kconfig wihch are also prone to merge conflicts, or we
> end up with lots of files in arch/arm/include/debug defining the base
> addresses.
> 
> We need to stop all of these problems from happening before they
> become a big headache for us - imagine Linus' reaction when our debug
> menu grows to be the largest Kconfig file in the kernel tree!  Do you
> want to be there when that happens?  We're the 22nd biggest Kconfig
> file already at 25K - there's only one debug Kconfig larger and that's
> the main lib/Kconfig.debug one which has recently been through a cleanup.
> 
> Therefore, the idea is to provide _generic_ options which people can
> set according to their platforms needs.  Remember, this is *supposed*
> to be a developer tool, not a user tool, so asking for addresses and
> other parameters is perfectly acceptable - just make sure that they're
> documented in a reasonable place.

And as if to prove the point, while writing that email, a patch dropped
into my mailbox:

"ARM: BCM53XX: initial support for the BCM5301/BCM470X"

which adds yet another 8250 debug UART where the only difference between
it and the others are its two base addresses, and in order to do that
it needs to add 25 or so more lines - 19 lines in a header file and six
in arch/arm/Kconfig.debug.

With the solution I'm proposing above, that could be:

- zero lines if you just set the options via Kconfig
- one, two or maybe at most three lines if you include it with some
  documentation file already in the kernel



From nerv at dawncrow.de  Tue Jul 16 15:27:11 2013
From: nerv at dawncrow.de (=?UTF-8?B?QW5kcsOpIEhlbnRzY2hlbA==?=)
Date: Tue, 16 Jul 2013 21:27:11 +0200
Subject: arm: Only load TLS values when needed
In-Reply-To: <51E5836B.1010904@arm.com>
References: <51E42E11.1010903@dawncrow.de> <51E5836B.1010904@arm.com>
Message-ID: <51E59E8F.1060501@dawncrow.de>

Hi Jonathan,
First, thank you for your review.

Am 16.07.2013 19:31, schrieb Jonathan Austin:
> Hi Andr?,
> 
> On 15/07/13 18:14, Andr? Hentschel wrote:
>> From: Andr? Hentschel <nerv at dawncrow.de>
>>
>> This patch intents to reduce loading instructions when the resulting value is not used.
>> It's a follow up on a4780adeefd042482f624f5e0d577bf9cdcbb760
>>
> 
> Have you done any benchmarking to see that this has any real impact? Or tested on a !Vv6k system? It looks possible that the only case where this will perform better is where we're using switch_tls_none or switch_tls_software (both rare cases, I think) and there's some change it will make things worse in other cases?

I have to admit that i only tested it on v6k and did no benchmark.

> One of the reasons for Russell's suggestion of placing the ldrd (which became the two ldr instructions you've removed from __switch_to, in order to maintain building for older cores) where it is was in order to reduce the chance of pipeline stalls.
> 
> As I've pointed out below, there is some risk that changing that has implications for the v6 only case below (and the v6k case is now more prone to stalls with !CONFIG_CPU_USE_DOMAINS, but newer cores should have more advanced scheduling to avoid such issues anyway...)

I'm not sure how this could make things worse on v6k, could you elaborate please?
Besides of the ldr and str being too close to each other i thought this patch is a good idea, because it removes two ldr which are always executed.
(Continuing below...)

>> Signed-off-by: Andr? Hentschel <nerv at dawncrow.de>
>>
>> ---
>> This patch is against Linux 3.11-rc1 (ad81f0545ef01ea651886dddac4bef6cec930092)
>>
>> Thanks to everyone who helped me with a4780adeefd042482f624f5e0d577bf9cdcbb760
>>
>> diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h
>> index 83259b8..3742722 100644
>> --- a/arch/arm/include/asm/tls.h
>> +++ b/arch/arm/include/asm/tls.h
>> @@ -3,29 +3,32 @@
>>
>>   #ifdef __ASSEMBLY__
>>   #include <asm/asm-offsets.h>
>> -    .macro switch_tls_none, base, tp, tpuser, tmp1, tmp2
>> +    .macro switch_tls_none, prev, next, tp, tpuser, tmp1, tmp2
>>       .endm
>>
>> -    .macro switch_tls_v6k, base, tp, tpuser, tmp1, tmp2
>> +    .macro switch_tls_v6k, prev, next, tp, tpuser, tmp1, tmp2
>> +    ldrd    \tp, \tpuser, [\next, #TI_TP_VALUE]    @ get the next TLS and user r/w register
>>       mrc    p15, 0, \tmp2, c13, c0, 2    @ get the user r/w register
>>       mcr    p15, 0, \tp, c13, c0, 3        @ set TLS register
>>       mcr    p15, 0, \tpuser, c13, c0, 2    @ and the user r/w register
>> -    str    \tmp2, [\base, #TI_TP_VALUE + 4] @ save it
>> +    str    \tmp2, [\prev, #TI_TP_VALUE + 4] @ save it
>>       .endm
>>
>> -    .macro switch_tls_v6, base, tp, tpuser, tmp1, tmp2
>> +    .macro switch_tls_v6, prev, next, tp, tpuser, tmp1, tmp2
>>       ldr    \tmp1, =elf_hwcap
>>       ldr    \tmp1, [\tmp1, #0]
>>       mov    \tmp2, #0xffff0fff
>> +    ldr    \tp, [\next, #TI_TP_VALUE]    @ get the next TLS register
>>       tst    \tmp1, #HWCAP_TLS        @ hardware TLS available?
>>       streq    \tp, [\tmp2, #-15]        @ set TLS value at 0xffff0ff0
>> -    mrcne    p15, 0, \tmp2, c13, c0, 2    @ get the user r/w register
>> +    mrcne    p15, 0, \tmp2, c13, c0, 2    @ get the previous user r/w register
>> +    ldrne    \tpuser, [\next, #TI_TP_VALUE + 4]    @ get the next user r/w register
>>       mcrne    p15, 0, \tp, c13, c0, 3        @ yes, set TLS register
>>       mcrne    p15, 0, \tpuser, c13, c0, 2    @ set user r/w register
> 
> Now we've only got one instruction between the store and the load and risk stalling the pipeline...
> 
> Dave M cautiously says "The ancient advice was that one instruction was enough" but this is very core dependent... I wonder if anyone has a good idea about whether this is an issue here...?

We could use a ldrd at the top, that'd be nearly what we have right now, don't we?




From davem at davemloft.net  Tue Jul 16 15:35:37 2013
From: davem at davemloft.net (David Miller)
Date: Tue, 16 Jul 2013 12:35:37 -0700 (PDT)
Subject: [PATCH 0/2] net: mvneta: big endian support
In-Reply-To: <1373894846-1147-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373894846-1147-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130716.123537.431798541962909293.davem@davemloft.net>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Date: Mon, 15 Jul 2013 15:27:24 +0200

> You'll find in this patch series two small patches that add support
> for big-endian in the mvneta driver, for the network interface found
> in ARM Marvell Armada 370 and Armada XP SOCs. They are based on
> 3.11-rc1.

Please resubmit this when the net-next tree opens back up.

Thanks.


From swarren at wwwdotorg.org  Tue Jul 16 15:51:20 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 13:51:20 -0600
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <51E5A438.10004@wwwdotorg.org>

On 07/16/2013 05:17 AM, Joseph Lo wrote:
> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
>>> this state.
>>
>> I tried applying this patch, your series "[PATCH V3 0/3] ARM: tegra114:
>> cpuidle: add power down state", and your series "[PATCH V2 00/11] ARM:
>> tegra114: add support for system suspend", all on top of v3.11-rc1.
>>
>> On Dalmore, the new cpuidle mode /appears/ to work (I see increasing
>> values in the sysfs cpuidle "usage" file for all defined cpuidle
>> states), but I don't see the "CPU VDD off" LED light up; I'm not
>> convinced that the CPU is actually being powered off in the idle mode.
>
> The LED of the CPU Vdd indicates the power of CPU cluster. But the
> series of CPU idle power down mode support for Tegra114 only supports
> per core power down.

OK, that's fine then.

>> With these patches applies, Harmony acts very strangely. After
>> hot-unplug and re-plug of CPU1, the system is hung or almost hung. The
>> patches appear to reduce the amount of time CPU VDD is off judging by
>> the LEDs. The patches might cause issues with system suspend too, but
>> I'm not 100% sure.
>
> Actually I didn't add anything about hotplug

Well, the patches do touch the CPU reset vector and related code. That's
shared with hotplug, right? But anyway, it turns out the CPU hotplug is
not related to the issue; the system acts strangely even without/before
performing any hotplug. I just hadn't noticed that before.

> or something can increase
> the loading or make regressions. But I think you are testing with USB
> device attached, right? That might cause some extra loading. You can
> give it a try after just removing USB device. And I double confirm that
> on Seaboard. Except that, the test result looks OK for me.

Yes, having a USB device plugged in does affect the issue. In summary:

next-20130716, with or without USB devices plugged in: Works fine.

next-20130716 with your patches, without USB device plugged in:
Occasional short problems (detailed below).

next-20130716 with your patches, with USB device plugged in: Continual
long problems (detailed below).

The testing I did was to log in over the serial console, hit <enter>
around five times, and watch the shell prompt echo back, then type
"ls<enter" and watch the (directory listing appear (I have about 20
files in my directory, with long-ish names), then repeat. With plain
next-20130716, this is nice and fast and there are no pauses. With your
patches applied, there are occasional or continual pauses, which last
for either a short time (tenths of a second), or even a second or two,
both depending on whether a USB device is plugged in or not.

I believe this is the same issue I saw when I applied your patches to
the Tegra tree on top of v3.11-rc1.

So, either your patch causes a bug, or exposes some pre-existing bug.
Either way, I can't apply them because they cause a regression.

I wonder if this is at all related to NVIDIA bug 1286857 "Upstreaming
task: Enabling LP2 causes slow serial console"? I tried the WAR there:

echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state1/disable
echo 1 > /sys/devices/system/cpu/cpu1/cpuidle/state1/disable

... and the system locked up solid very soon after; I had just enough
time to type "ls<enter>", then it locked up. Again, performing those
same echos on next-20130716 without your patches works fine.


From balbi at ti.com  Tue Jul 16 16:03:53 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 16 Jul 2013 23:03:53 +0300
Subject: [PATCH] ARM: omap2: fix musb usage for n8x0
In-Reply-To: <1374000777-5626-1-git-send-email-zonque@gmail.com>
References: <1374000777-5626-1-git-send-email-zonque@gmail.com>
Message-ID: <20130716200353.GC31293@arwen.pp.htv.fi>

On Tue, Jul 16, 2013 at 08:52:57PM +0200, Daniel Mack wrote:
> Commit b7e2e75a8c ("usb: gadget: drop unused USB_GADGET_MUSB_HDRC")
> dropped a config symbol that was unused by the musb core, but it turns
> out that board support code had references to it.
> 
> As the core now has a fall-back to host-only mode if support for
> dual-role is not compiled in, so we can just pass MUSB_OTG as
> mode from board files.
> 
> Signed-off-by: Daniel Mack <zonque at gmail.com>
> Reported-and-tested-by: Aaro Koskinen <aaro.koskinen at iki.fi>

Acked-by: Felipe Balbi <balbi at ti.com>

-- 
balbi
-------------- 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/20130716/dbae9985/attachment.sig>

From robherring2 at gmail.com  Tue Jul 16 16:05:25 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 16 Jul 2013 15:05:25 -0500
Subject: [RFC PATCH v5 1/1] drivers: mfd: vexpress: add Serial Power
 Controller (SPC) support
In-Reply-To: <1373990743-23106-2-git-send-email-lorenzo.pieralisi@arm.com>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1373990743-23106-2-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <51E5A785.1040805@gmail.com>

On 07/16/2013 11:05 AM, Lorenzo Pieralisi wrote:
> The TC2 versatile express core tile integrates a logic block that provides the
> interface between the dual cluster test-chip and the M3 microcontroller that
> carries out power management. The logic block, called Serial Power Controller
> (SPC), contains several memory mapped registers to control among other things
> low-power states, wake-up irqs and per-CPU jump addresses registers.
> 
> This patch provides a driver that enables run-time control of features
> implemented by the SPC power management control logic.
> 
> The SPC control logic is required to be programmed very early in the boot
> process to reset secondary CPUs on the TC2 testchip, set-up jump addresses and
> wake-up IRQs for power management. Hence, waiting for core changes to be
> made in the device core code to enable early registration of platform
> devices, the driver puts in place an early init scheme that allows kernel
> drivers to initialize the SPC driver directly from the components requiring
> it, if their initialization routine is called before the driver init
> function by the boot process.
> 
> Device tree bindings documentation for the SPC component is provided with
> the patchset.

Just curious, wouldn't a TC2 PSCI implementation eliminate the need for
most/all of this code?

Rob

> 
> Cc: Samuel Ortiz <sameo at linux.intel.com>
> Cc: Olof Johansson <olof at lixom.net>
> Cc: Pawel Moll <pawel.moll at arm.com>
> Cc: Amit Kucheria <amit.kucheria at linaro.org>
> Cc: Jon Medhurst <tixy at linaro.org>
> Signed-off-by: Achin Gupta <achin.gupta at arm.com>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> Signed-off-by: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha at arm.com>
> ---
>  Documentation/devicetree/bindings/mfd/vexpress-spc.txt |  36 ++
>  drivers/mfd/Kconfig                                    |  10 +
>  drivers/mfd/Makefile                                   |   1 +
>  drivers/mfd/vexpress-spc.c                             | 253 ++++++++++
>  include/linux/vexpress.h                               |  17 +
>  5 files changed, 317 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/vexpress-spc.txt b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
> new file mode 100644
> index 0000000..1614725
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
> @@ -0,0 +1,36 @@
> +* ARM Versatile Express Serial Power Controller device tree bindings
> +
> +Latest ARM development boards implement a power management interface (serial
> +power controller - SPC) that is capable of managing power states transitions,
> +wake-up IRQs and resume addresses for ARM multiprocessor testchips.
> +The serial controller can be programmed through a memory mapped interface
> +that enables communication between firmware running on the microcontroller
> +managing power states and the application processors.
> +
> +The SPC DT bindings are defined as follows:
> +
> +- spc node
> +
> +	- compatible:
> +		Usage: required
> +		Value type: <stringlist>
> +		Definition: must be
> +			    "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc"
> +	- reg:
> +		Usage: required
> +		Value type: <prop-encode-array>
> +		Definition: A standard property that specifies the base address
> +			    and the size of the SPC address space
> +	- interrupts:
> +		Usage: required
> +		Value type: <prop-encoded-array>
> +		Definition:  SPC interrupt configuration. A standard property
> +			     that follows ePAPR interrupts specifications
> +
> +Example:
> +
> +spc: spc at 7fff0000 {
> +	compatible = "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc";
> +	reg = <0x7fff0000 0x1000>;
> +	interrupts = <0 95 4>;
> +};
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 6959b8d..ebd23f4 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1149,3 +1149,13 @@ config VEXPRESS_CONFIG
>  	help
>  	  Platform configuration infrastructure for the ARM Ltd.
>  	  Versatile Express.
> +
> +config VEXPRESS_SPC
> +	bool "Versatile Express SPC driver support"
> +	depends on ARM
> +	help
> +	  The Serial Power Controller (SPC) for ARM Ltd. test chips, is
> +	  an IP that provides a memory mapped interface to power controller
> +	  HW. The driver provides an API abstraction allowing to program
> +	  registers controlling low-level power management features like power
> +	  down flags, global and per-cpu wake-up IRQs.
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 718e94a..3a01203 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -153,5 +153,6 @@ obj-$(CONFIG_MFD_SEC_CORE)	+= sec-core.o sec-irq.o
>  obj-$(CONFIG_MFD_SYSCON)	+= syscon.o
>  obj-$(CONFIG_MFD_LM3533)	+= lm3533-core.o lm3533-ctrlbank.o
>  obj-$(CONFIG_VEXPRESS_CONFIG)	+= vexpress-config.o vexpress-sysreg.o
> +obj-$(CONFIG_VEXPRESS_SPC)	+= vexpress-spc.o
>  obj-$(CONFIG_MFD_RETU)		+= retu-mfd.o
>  obj-$(CONFIG_MFD_AS3711)	+= as3711.o
> diff --git a/drivers/mfd/vexpress-spc.c b/drivers/mfd/vexpress-spc.c
> new file mode 100644
> index 0000000..aa8c2a4
> --- /dev/null
> +++ b/drivers/mfd/vexpress-spc.c
> @@ -0,0 +1,253 @@
> +/*
> + * Versatile Express Serial Power Controller (SPC) support
> + *
> + * Copyright (C) 2013 ARM Ltd.
> + *
> + * Authors: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> + *          Achin Gupta           <achin.gupta at arm.com>
> + *          Lorenzo Pieralisi     <lorenzo.pieralisi at arm.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/of_address.h>
> +#include <linux/slab.h>
> +#include <linux/vexpress.h>
> +
> +#include <asm/cacheflush.h>
> +
> +#define SPCLOG "vexpress-spc: "
> +
> +/* SCC conf registers */
> +#define A15_CONF		0x400
> +#define SYS_INFO		0x700
> +
> +/* SPC registers base */
> +#define SPC_BASE		0xB00
> +
> +/* SPC wake-up IRQs status and mask */
> +#define WAKE_INT_MASK		(SPC_BASE + 0x24)
> +#define WAKE_INT_RAW		(SPC_BASE + 0x28)
> +#define WAKE_INT_STAT		(SPC_BASE + 0x2c)
> +/* SPC power down registers */
> +#define A15_PWRDN_EN		(SPC_BASE + 0x30)
> +#define A7_PWRDN_EN		(SPC_BASE + 0x34)
> +/* SPC per-CPU mailboxes */
> +#define A15_BX_ADDR0		(SPC_BASE + 0x68)
> +#define A7_BX_ADDR0		(SPC_BASE + 0x78)
> +
> +/* wake-up interrupt masks */
> +#define GBL_WAKEUP_INT_MSK	(0x3 << 10)
> +
> +/* TC2 static dual-cluster configuration */
> +#define MAX_CLUSTERS		2
> +
> +struct ve_spc_drvdata {
> +	void __iomem *baseaddr;
> +	/*
> +	 * A15s cluster identifier
> +	 * It corresponds to A15 processors MPIDR[15:8] bitfield
> +	 */
> +	u32 a15_clusid;
> +};
> +
> +static struct ve_spc_drvdata *info;
> +
> +static inline bool cluster_is_a15(u32 cluster)
> +{
> +	return cluster == info->a15_clusid;
> +}
> +
> +/**
> + * ve_spc_global_wakeup_irq()
> + *
> + * Function to set/clear global wakeup IRQs. Not protected by locking since
> + * it might be used in code paths where normal cacheable locks are not
> + * working. Locking must be provided by the caller to ensure atomicity.
> + *
> + * @set: if true, global wake-up IRQs are set, if false they are cleared
> + */
> +void ve_spc_global_wakeup_irq(bool set)
> +{
> +	u32 reg;
> +
> +	reg = readl_relaxed(info->baseaddr + WAKE_INT_MASK);
> +
> +	if (set)
> +		reg |= GBL_WAKEUP_INT_MSK;
> +	else
> +		reg &= ~GBL_WAKEUP_INT_MSK;
> +
> +	writel_relaxed(reg, info->baseaddr + WAKE_INT_MASK);
> +}
> +
> +/**
> + * ve_spc_cpu_wakeup_irq()
> + *
> + * Function to set/clear per-CPU wake-up IRQs. Not protected by locking since
> + * it might be used in code paths where normal cacheable locks are not
> + * working. Locking must be provided by the caller to ensure atomicity.
> + *
> + * @cluster: mpidr[15:8] bitfield describing cluster affinity level
> + * @cpu: mpidr[7:0] bitfield describing cpu affinity level
> + * @set: if true, wake-up IRQs are set, if false they are cleared
> + */
> +void ve_spc_cpu_wakeup_irq(u32 cluster, u32 cpu, bool set)
> +{
> +	u32 mask, reg;
> +
> +	if (cluster >= MAX_CLUSTERS)
> +		return;
> +
> +	mask = 1 << cpu;
> +
> +	if (!cluster_is_a15(cluster))
> +		mask <<= 4;
> +
> +	reg = readl_relaxed(info->baseaddr + WAKE_INT_MASK);
> +
> +	if (set)
> +		reg |= mask;
> +	else
> +		reg &= ~mask;
> +
> +	writel_relaxed(reg, info->baseaddr + WAKE_INT_MASK);
> +}
> +
> +/**
> + * ve_spc_set_resume_addr() - set the jump address used for warm boot
> + *
> + * @cluster: mpidr[15:8] bitfield describing cluster affinity level
> + * @cpu: mpidr[7:0] bitfield describing cpu affinity level
> + * @addr: physical resume address
> + */
> +void ve_spc_set_resume_addr(u32 cluster, u32 cpu, u32 addr)
> +{
> +	void __iomem *baseaddr;
> +
> +	if (cluster >= MAX_CLUSTERS)
> +		return;
> +
> +	if (cluster_is_a15(cluster))
> +		baseaddr = info->baseaddr + A15_BX_ADDR0 + (cpu << 2);
> +	else
> +		baseaddr = info->baseaddr + A7_BX_ADDR0 + (cpu << 2);
> +
> +	writel_relaxed(addr, baseaddr);
> +}
> +
> +/**
> + * ve_spc_get_nr_cpus() - get number of cpus in a cluster
> + *
> + * @cluster: mpidr[15:8] bitfield describing cluster affinity level
> + *
> + * Return: > 0 number of cpus in the cluster
> + *         or 0 if cluster number invalid
> + */
> +u32 ve_spc_get_nr_cpus(u32 cluster)
> +{
> +	u32 val;
> +
> +	if (cluster >= MAX_CLUSTERS)
> +		return 0;
> +
> +	val = readl_relaxed(info->baseaddr + SYS_INFO);
> +	val = cluster_is_a15(cluster) ? (val >> 16) : (val >> 20);
> +	return val & 0xf;
> +}
> +
> +/**
> + * ve_spc_powerdown()
> + *
> + * Function to enable/disable cluster powerdown. Not protected by locking
> + * since it might be used in code paths where normal cacheable locks are not
> + * working. Locking must be provided by the caller to ensure atomicity.
> + *
> + * @cluster: mpidr[15:8] bitfield describing cluster affinity level
> + * @enable: if true enables powerdown, if false disables it
> + */
> +void ve_spc_powerdown(u32 cluster, bool enable)
> +{
> +	u32 pwdrn_reg;
> +
> +	if (cluster >= MAX_CLUSTERS)
> +		return;
> +
> +	pwdrn_reg = cluster_is_a15(cluster) ? A15_PWRDN_EN : A7_PWRDN_EN;
> +	writel_relaxed(enable, info->baseaddr + pwdrn_reg);
> +}
> +
> +static const struct of_device_id ve_spc_ids[] __initconst = {
> +	{ .compatible = "arm,vexpress-spc,v2p-ca15_a7" },
> +	{ .compatible = "arm,vexpress-spc" },
> +	{},
> +};
> +
> +static int __init ve_spc_probe(void)
> +{
> +	int ret;
> +	struct device_node *node = of_find_matching_node(NULL, ve_spc_ids);
> +
> +	if (!node)
> +		return -ENODEV;
> +
> +	info = kzalloc(sizeof(*info), GFP_KERNEL);
> +	if (!info) {
> +		pr_err(SPCLOG "unable to allocate mem\n");
> +		return -ENOMEM;
> +	}
> +
> +	info->baseaddr = of_iomap(node, 0);
> +	if (!info->baseaddr) {
> +		pr_err(SPCLOG "unable to ioremap memory\n");
> +		ret = -ENXIO;
> +		goto mem_free;
> +	}
> +
> +	info->a15_clusid = readl_relaxed(info->baseaddr + A15_CONF) & 0xf;
> +
> +	/*
> +	 * Multi-cluster systems may need this data when non-coherent, during
> +	 * cluster power-up/power-down. Make sure driver info reaches main
> +	 * memory.
> +	 */
> +	sync_cache_w(info);
> +	sync_cache_w(&info);
> +	pr_info("vexpress-spc loaded at %p\n", info->baseaddr);
> +	return 0;
> +
> +mem_free:
> +	kfree(info);
> +	return ret;
> +}
> +
> +/**
> + * ve_spc_init()
> + *
> + * Function exported to manage pre early_initcall initialization.
> + * SPC code is needed very early in the boot process to bring CPUs out of
> + * reset and initialize power management back-end so an init interface is
> + * provided to platform code to allow early initialization. The init
> + * interface can be removed as soon as the DT layer and platform bus allow
> + * platform device creation and probing before SMP boot.
> + */
> +int __init ve_spc_init(void)
> +{
> +	static int ve_spc_init_status __initdata = -EAGAIN;
> +
> +	if (ve_spc_init_status == -EAGAIN)
> +		ve_spc_init_status = ve_spc_probe();
> +
> +	return ve_spc_init_status;
> +}
> +early_initcall(ve_spc_init);
> diff --git a/include/linux/vexpress.h b/include/linux/vexpress.h
> index 50368e0..d0106ef 100644
> --- a/include/linux/vexpress.h
> +++ b/include/linux/vexpress.h
> @@ -132,4 +132,21 @@ void vexpress_clk_of_register_spc(void);
>  void vexpress_clk_init(void __iomem *sp810_base);
>  void vexpress_clk_of_init(void);
>  
> +/* SPC */
> +
> +#ifdef CONFIG_VEXPRESS_SPC
> +int __init ve_spc_init(void);
> +void ve_spc_global_wakeup_irq(bool set);
> +void ve_spc_cpu_wakeup_irq(u32 cluster, u32 cpu, bool set);
> +void ve_spc_set_resume_addr(u32 cluster, u32 cpu, u32 addr);
> +u32 ve_spc_get_nr_cpus(u32 cluster);
> +void ve_spc_powerdown(u32 cluster, bool enable);
> +#else
> +static inline int ve_spc_init(void) { return -ENODEV; }
> +static inline void ve_spc_global_wakeup_irq(bool set) { }
> +static inline void ve_spc_cpu_wakeup_irq(u32 cluster, u32 cpu, bool set) { }
> +static inline void ve_spc_set_resume_addr(u32 cluster, u32 cpu, u32 addr) { }
> +static inline u32 ve_spc_get_nr_cpus(u32 cluster) { return 0; }
> +static inline void ve_spc_powerdown(u32 cluster, bool enable) { }
> +#endif
>  #endif
> 



From santosh.shilimkar at ti.com  Tue Jul 16 16:09:54 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 16 Jul 2013 16:09:54 -0400
Subject: [PATCH RFC v2 04/14] ARM: debug: provide 8250 debug uart register
 shift configuration option
In-Reply-To: <20130716192403.GA13150@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
 <E1Uz8FU-00047a-AB@rmk-PC.arm.linux.org.uk> <51E59338.6020102@ti.com>
 <20130716191658.GG24642@n2100.arm.linux.org.uk>
 <20130716192403.GA13150@n2100.arm.linux.org.uk>
Message-ID: <51E5A892.7060309@ti.com>

On Tuesday 16 July 2013 03:24 PM, Russell King - ARM Linux wrote:
> On Tue, Jul 16, 2013 at 08:16:58PM +0100, Russell King - ARM Linux wrote:
>> On Tue, Jul 16, 2013 at 02:38:48PM -0400, Santosh Shilimkar wrote:
>>> Just a question. Exposing selection choice for UART port
>>> and probably flow control is just fine, but do we need to
>>> really need config entries for SHIFT, PA, VA etc ?
>>
>> Let's look at the original problem.  We have lots of files in
>> arch/arm/include/debug who's sole purpose is to define a pair of base
>> addresses.  Maybe around 500 lines of code doing just that - though
>> much of it is copyright notices (can someone explain to me the point
>> of claiming copyright on four lines of code defining a base address of
>> a UART which is, apart from the addresses themselves, identical with
>> every other damned file?)
>>
>> What this series does is remove many of those files by consolidating
>> much of them into a much denser way to represent all this variability.
>> However, this doesn't really address the root problem, which is that
>> we have all this information in the kernel, which needs to be added
>> to every single time we have a new platform come along no matter what
>> it is.
>>
>> We need to stop that from happening - we need a way for people to tell
>> the kernel where their UART is without having to load the kernel up
>> with lots of platform specific information [*].
>>
>> Also, even without this, the debug menu has become something of a
>> sprawling mess, with various people re-implementing what's already
>> there presumably because they don't look/don't bother to research what
>> support is already there - and is another source of constant additions.
>>
>> So, the idea that every platform gets to somehow put its UART addresses
>> into the kernel image isn't scalable.  Either we end up with lots of
>> defaults in a Kconfig wihch are also prone to merge conflicts, or we
>> end up with lots of files in arch/arm/include/debug defining the base
>> addresses.
>>
>> We need to stop all of these problems from happening before they
>> become a big headache for us - imagine Linus' reaction when our debug
>> menu grows to be the largest Kconfig file in the kernel tree!  Do you
>> want to be there when that happens?  We're the 22nd biggest Kconfig
>> file already at 25K - there's only one debug Kconfig larger and that's
>> the main lib/Kconfig.debug one which has recently been through a cleanup.
>>
>> Therefore, the idea is to provide _generic_ options which people can
>> set according to their platforms needs.  Remember, this is *supposed*
>> to be a developer tool, not a user tool, so asking for addresses and
>> other parameters is perfectly acceptable - just make sure that they're
>> documented in a reasonable place.
> 
> And as if to prove the point, while writing that email, a patch dropped
> into my mailbox:
> 
> "ARM: BCM53XX: initial support for the BCM5301/BCM470X"
> 
> which adds yet another 8250 debug UART where the only difference between
> it and the others are its two base addresses, and in order to do that
> it needs to add 25 or so more lines - 19 lines in a header file and six
> in arch/arm/Kconfig.debug.
> 
> With the solution I'm proposing above, that could be:
> 
> - zero lines if you just set the options via Kconfig
> - one, two or maybe at most three lines if you include it with some
>   documentation file already in the kernel
> 
Fair enough. Sorry I missed the point about providing the LL debug
information with config entries than adding the code. It indeed
doable as long as the information is documented as you said.

Thanks for explaining the goal of the series again.

Regards,
Santosh 




From oliver at schinagl.nl  Tue Jul 16 17:02:22 2013
From: oliver at schinagl.nl (Oliver Schinagl)
Date: Tue, 16 Jul 2013 23:02:22 +0200
Subject: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner's
 Security ID fuses
In-Reply-To: <20130716064107.GA10868@kroah.com>
References: <20130624160440.GA15201@kroah.com> <51C87DC7.50005@schinagl.nl>
 <20130624181509.GA8847@kroah.com> <51C8B84C.3020200@schinagl.nl>
 <20130624214615.GA17604@kroah.com> <51CAA709.4060801@schinagl.nl>
 <20130626175144.GC2222@kroah.com> <51D674BF.9030207@schinagl.nl>
 <20130706193646.GB9778@kroah.com> <51E466A3.4010503@schinagl.nl>
 <20130716064107.GA10868@kroah.com>
Message-ID: <51E5B4DE.5060002@schinagl.nl>

On 07/16/13 08:41, Greg KH wrote:
> On Mon, Jul 15, 2013 at 11:16:19PM +0200, Oliver Schinagl wrote:
>> With your latest patches for binary attributes and your blog post, I
>> thought that you want to create your binary attributes before the probe
>> function, to avoid the userspace race. To do that, we have two options,
>> create them in init (ugly?) or fill the .group member if available so it
>> gets automatically created from the register function.
> Yes, the .group thing should be what is needed here.
That's what I thought (and used).
>
>> Well in my case, I'm using the module_platform_driver() macro which
>> expects the struct platform_driver. Platform_driver has a device_driver
>> member .driver where the .groups is located. Great, using that works and
>> we should have the sysfs entry race-free. However I don't know hot to
>> exchange data between that and the rest of my driver.
>>
>> Before I used to_platform_device(kobj_to_dev(kobj)) as passed via the
>> .read function to obtain a platform_device where i could use
>> platform_get_drvdata on. All was good, but that doesn't fly now and my
>> knowledge is a bit short as to why.
> I don't understand, why not use the platform device that was passed to
> the binary attribute write function?
Because the pointers don't match and I get a null pointer from 
platform_get_data
>
>> The second method is finding some other shared structure given that we
>> get a platform_device in the probe function, yet I couldn't find
>> anything and this platform_device isn't the same as the one from the .read.
> It should be, why isn't it?
I think that's a little above my grasp :p
>
>> Of course using a global var bypasses this issue, but I'm sure it won't
>> pass review ;)
> The platform device structure should have what you need, right?
Should, but doesn't :(
>
>> So using these new patches for binary attributes, how can I pass data
>> between my driver and the sysfs files using a platform_driver? Or are
>> other 'hacks' needed and using the .groups attribute from
>> platform_driver->device_driver->groups is really the wrong approach.
>>
>> I did ask around and still haven't figured it out so far, so I do
>> apologize if you feel I'm wasting your precious time.
> How is the platform device not the same thing that was passed to your
> probe function?
I don't know :( But i'll add the relevant sections with printk results 
below, which I should have done before, then again those printk's were 
not supposed to be in that e-mail to begin with ;)

So if I'm not seeing something stupidly obvious, feel free to shout at me :)

static ssize_t sid_read(struct file *fd, struct kobject *kobj,
             struct bin_attribute *attr, char *buf,
             loff_t pos, size_t size)
{
     struct platform_device *pdev;
     void __iomem *sid_reg_base;
     int i;

     pdev = to_platform_device(kobj_to_dev(kobj));
     sid_reg_base = (void __iomem *)platform_get_drvdata(pdev);
     printk("0x%p, 0x%p, 0x%p, 0x%p\n", kobj, kobj_to_dev(kobj), pdev, 
sid_reg_base);

0xef1e7c80, 0xef1e7c78, 0xef1e7c68, 0x  (null)

     if (pos < 0 || pos >= SID_SIZE)
         return 0;
     if (size > SID_SIZE - pos)
         size = SID_SIZE - pos;

     for (i = 0; i < size; i++)
         buf[i] = sunxi_sid_read_byte(sid_reg_base, pos + i);

     return i;
}


static struct bin_attribute sid_bin_attr = {
     .attr = { .name = "eeprom", .mode = S_IRUGO, },
     .size = SID_SIZE,
     .read = sid_read,
};

static struct bin_attribute *sunxi_sid_attrs[] = {
     &sid_bin_attr,
     NULL,
};

static const struct attribute_group sunxi_sid_group = {
     .bin_attrs = sunxi_sid_attrs,
};

static const struct attribute_group *sunxi_sid_groups[] = {
     &sunxi_sid_group,
     NULL,
};

static int __init sunxi_sid_probe(struct platform_device *pdev)
{
     struct resource *res;
     void __iomem *sid_reg_base;
     u8 entropy[SID_SIZE];
     unsigned int i;

     res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
     sid_reg_base = devm_ioremap_resource(&pdev->dev, res);
     if (IS_ERR(sid_reg_base))
         return PTR_ERR(sid_reg_base);
     platform_set_drvdata(pdev, sid_reg_base);

     for (i = 0; i < SID_SIZE; i++)
         entropy[i] = sunxi_sid_read_byte(sid_reg_base, i);
     add_device_randomness(entropy, SID_SIZE);
     dev_dbg(&pdev->dev, "%s loaded\n", DRV_NAME);
     printk("0x%p, 0x%p\n", pdev, sid_reg_base);

0xef02b000, 0xf1c23800

     return 0;
}




From thierry.reding at gmail.com  Tue Jul 16 17:05:10 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 16 Jul 2013 14:05:10 -0700
Subject: [PATCHv5 00/11] MSI support for Marvell EBU PCIe driver
In-Reply-To: <20130716103351.15b0fb50@skate>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E4167B.4000208@wwwdotorg.org>
 <20130715162709.GA24625@dhcp-172-17-186-34.nvidia.com>
 <20130716103351.15b0fb50@skate>
Message-ID: <20130716210509.GA29318@dhcp-172-17-186-34.nvidia.com>

On Tue, Jul 16, 2013 at 10:33:51AM +0200, Thomas Petazzoni wrote:
> Dear Thierry Reding,
> 
> On Mon, 15 Jul 2013 09:27:10 -0700, Thierry Reding wrote:
> 
> > We need at least patches 2, 4 and 8 for Tegra.
> 
> Are you sure you don't want patch 1 ? It allows to replace the
> allocation of MSI interrupt numbers for the MSI driver by a generic
> facility based on irq domains.

Yes, I could use it to replace some of the functionality. I was just
saying that we don't absolutely need it. If it makes things easier for
the merge, it would be trivial to convert the Tegra driver to using the
new generic facility in a follow-up patch.

> > There's still the option
> > of working around patch 8 by using the custom root bus scan function
> > that we have to use anyway, so I guess we could even trim the
> > requirement down to patches 2 and 4 if we really need.
> 
> Bjorn said he didn't like having the msi chip assignment in the middle
> of the root bus scan function, because he was hoping someday to
> refactor this function. Quoting Bjorn:
> 
> """
> > +	bus->msi = pcie->msi;  
> 
> Ideally, arches could use pci_scan_root_bus(), which does the
> pci_scan_child_bus() itself, so I never like to add arch-specific code
> between pci_create_root_bus() and pci_scan_child_bus().
> 
> But you should be able to accomplish this by setting bus->msi in a
> pcibios_add_bus() hook.  There is a corresponding pcibios_remove_bus()
> hook that might be useful for deallocating the msi_chip.  I'm not too
> clear on how you manage the msi_chip lifetime -- I see the alloc in
> armada_370_xp_msi_init(), but I'm not sure whether you ever deallocate
> it or how you know when it would be safe to do so.
> """
> 
> This is from:
> 
> Subject: Re: [PATCH v2 6/8] pci: mvebu: add support for MSI
> Date: Tue, 18 Jun 2013 16:57:11 -0600

Yes, I'm aware of that discussion. However we currently need to have the
custom root bus scan implementation anyway because pci_scan_root_bus()
just doesn't work on ARM. So again, since we'll have to rework the
driver anyway in order to use pci_scan_root_bus() once the issues have
been resolved, it wouldn't hurt to postpone the transition to the new
ARM pcibios_add_bus() support until that point.

All I was trying to do was reduce the list of common dependencies in an
attempt to make merging it easier.

Thierry
-------------- 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/20130716/917057ff/attachment.sig>

From carlo.caione at gmail.com  Tue Jul 16 17:25:03 2013
From: carlo.caione at gmail.com (Carlo Caione)
Date: Tue, 16 Jul 2013 23:25:03 +0200
Subject: [PATCH v6] ARM: sunxi: New watchdog driver for Allwinner A10/A13
Message-ID: <1374009903-10203-1-git-send-email-carlo.caione@gmail.com>

This patch adds the driver for the watchdog found in the Allwinner A10 and
A13 SoCs. It has DT-support and uses the new watchdog framework.

Signed-off-by: Carlo Caione <carlo.caione at gmail.com>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/watchdog/Kconfig     |  10 ++
 drivers/watchdog/Makefile    |   1 +
 drivers/watchdog/sunxi_wdt.c | 241 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 252 insertions(+)
 create mode 100644 drivers/watchdog/sunxi_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 362085d..d1d53f3 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -290,6 +290,16 @@ config ORION_WATCHDOG
 	  To compile this driver as a module, choose M here: the
 	  module will be called orion_wdt.
 
+config SUNXI_WATCHDOG
+	tristate "Allwinner SoCs watchdog support"
+	depends on ARCH_SUNXI
+	select WATCHDOG_CORE
+	help
+	  Say Y here to include support for the watchdog timer
+	  in Allwinner SoCs.
+	  To compile this driver as a module, choose M here: the
+	  module will be called sunxi_wdt.
+
 config COH901327_WATCHDOG
 	bool "ST-Ericsson COH 901 327 watchdog"
 	depends on ARCH_U300
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 2f26a0b..6c5bb27 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_PNX4008_WATCHDOG) += pnx4008_wdt.o
 obj-$(CONFIG_IOP_WATCHDOG) += iop_wdt.o
 obj-$(CONFIG_DAVINCI_WATCHDOG) += davinci_wdt.o
 obj-$(CONFIG_ORION_WATCHDOG) += orion_wdt.o
+obj-$(CONFIG_SUNXI_WATCHDOG) += sunxi_wdt.o
 obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
 obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
 obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
diff --git a/drivers/watchdog/sunxi_wdt.c b/drivers/watchdog/sunxi_wdt.c
new file mode 100644
index 0000000..11bfaf2
--- /dev/null
+++ b/drivers/watchdog/sunxi_wdt.c
@@ -0,0 +1,241 @@
+/*
+ *      sunxi Watchdog Driver
+ *
+ *      Copyright (c) 2013 Carlo Caione
+ *                    2012 Henrik Nordstrom
+ *
+ *      This program is free software; you can redistribute it and/or
+ *      modify it under the terms of the GNU General Public License
+ *      as published by the Free Software Foundation; either version
+ *      2 of the License, or (at your option) any later version.
+ *
+ *      Based on xen_wdt.c
+ *      (c) Copyright 2010 Novell, Inc.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+#include <linux/watchdog.h>
+
+#define WDT_MAX_TIMEOUT         16
+#define WDT_MIN_TIMEOUT         1
+#define WDT_MODE_TIMEOUT(n)     ((n) << 3)
+#define WDT_TIMEOUT_MASK        WDT_MODE_TIMEOUT(0x0F)
+
+#define WDT_CTRL                0x00
+#define WDT_CTRL_RELOAD         ((1 << 0) | (0x0a57 << 1))
+
+#define WDT_MODE                0x04
+#define WDT_MODE_EN             (1 << 0)
+#define WDT_MODE_RST_EN         (1 << 1)
+
+#define DRV_NAME		"sunxi-wdt"
+#define DRV_VERSION		"1.0"
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+static unsigned int timeout = WDT_MAX_TIMEOUT;
+
+struct sunxi_wdt_dev {
+	struct watchdog_device wdt_dev;
+	void __iomem *wdt_base;
+};
+
+/*
+ * wdt_timeout_map maps the watchdog timer interval value in seconds to
+ * the value of the register WDT_MODE bit 3:6
+ *
+ * [timeout seconds] = register value
+ *
+ */
+
+static const int wdt_timeout_map[] = {
+	[1] = 0b0001,  /* 1s  */
+	[2] = 0b0010,  /* 2s  */
+	[3] = 0b0011,  /* 3s  */
+	[4] = 0b0100,  /* 4s  */
+	[5] = 0b0101,  /* 5s  */
+	[6] = 0b0110,  /* 6s  */
+	[8] = 0b0111,  /* 8s  */
+	[10] = 0b1000, /* 10s */
+	[12] = 0b1001, /* 12s */
+	[14] = 0b1010, /* 14s */
+	[16] = 0b1011, /* 16s */
+};
+
+static int sunxi_wdt_ping(struct watchdog_device *wdt_dev)
+{
+	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
+	void __iomem *wdt_base = sunxi_wdt->wdt_base;
+
+	iowrite32(WDT_CTRL_RELOAD, wdt_base + WDT_CTRL);
+
+	return 0;
+}
+
+static int sunxi_wdt_set_timeout(struct watchdog_device *wdt_dev,
+		unsigned int timeout)
+{
+	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
+	void __iomem *wdt_base = sunxi_wdt->wdt_base;
+	u32 reg;
+
+	if (timeout > WDT_MAX_TIMEOUT)
+		return -EINVAL;
+
+	if (wdt_timeout_map[timeout] == 0)
+		timeout++;
+
+	sunxi_wdt->wdt_dev.timeout = timeout;
+
+	reg = ioread32(wdt_base + WDT_MODE);
+	reg &= ~WDT_TIMEOUT_MASK;
+	reg |= WDT_MODE_TIMEOUT(wdt_timeout_map[timeout]);
+	iowrite32(reg, wdt_base + WDT_MODE);
+
+	sunxi_wdt_ping(wdt_dev);
+
+	return 0;
+}
+
+static int sunxi_wdt_stop(struct watchdog_device *wdt_dev)
+{
+	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
+	void __iomem *wdt_base = sunxi_wdt->wdt_base;
+
+	iowrite32(0, wdt_base + WDT_MODE);
+
+	return 0;
+}
+
+static int sunxi_wdt_start(struct watchdog_device *wdt_dev)
+{
+	u32 reg;
+	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
+	void __iomem *wdt_base = sunxi_wdt->wdt_base;
+	int ret;
+
+	ret = sunxi_wdt_set_timeout(&sunxi_wdt->wdt_dev,
+			sunxi_wdt->wdt_dev.timeout);
+	if (ret < 0)
+		return ret;
+
+	reg = ioread32(wdt_base + WDT_MODE);
+	reg |= (WDT_MODE_RST_EN | WDT_MODE_EN);
+	iowrite32(reg, wdt_base + WDT_MODE);
+
+	return 0;
+}
+
+static const struct watchdog_info sunxi_wdt_info = {
+	.identity	= DRV_NAME,
+	.options	= WDIOF_SETTIMEOUT |
+			  WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
+static const struct watchdog_ops sunxi_wdt_ops = {
+	.owner		= THIS_MODULE,
+	.start		= sunxi_wdt_start,
+	.stop		= sunxi_wdt_stop,
+	.ping		= sunxi_wdt_ping,
+	.set_timeout	= sunxi_wdt_set_timeout,
+};
+
+static int __init sunxi_wdt_probe(struct platform_device *pdev)
+{
+	struct sunxi_wdt_dev *sunxi_wdt;
+	struct resource *res;
+	int err;
+
+	sunxi_wdt = devm_kzalloc(&pdev->dev, sizeof(*sunxi_wdt), GFP_KERNEL);
+	if (!sunxi_wdt)
+		return -EINVAL;
+
+	platform_set_drvdata(pdev, sunxi_wdt);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	sunxi_wdt->wdt_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(sunxi_wdt->wdt_base))
+		return PTR_ERR(sunxi_wdt->wdt_base);
+
+	sunxi_wdt->wdt_dev.info = &sunxi_wdt_info;
+	sunxi_wdt->wdt_dev.ops = &sunxi_wdt_ops;
+	sunxi_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
+	sunxi_wdt->wdt_dev.max_timeout = WDT_MAX_TIMEOUT;
+	sunxi_wdt->wdt_dev.min_timeout = WDT_MIN_TIMEOUT;
+	sunxi_wdt->wdt_dev.parent = &pdev->dev;
+
+	watchdog_init_timeout(&sunxi_wdt->wdt_dev, timeout, &pdev->dev);
+	watchdog_set_nowayout(&sunxi_wdt->wdt_dev, nowayout);
+
+	watchdog_set_drvdata(&sunxi_wdt->wdt_dev, sunxi_wdt);
+
+	sunxi_wdt_stop(&sunxi_wdt->wdt_dev);
+
+	err = watchdog_register_device(&sunxi_wdt->wdt_dev);
+	if (unlikely(err))
+		return err;
+
+	dev_info(&pdev->dev, "Watchdog enabled (timeout=%d sec, nowayout=%d)",
+			sunxi_wdt->wdt_dev.timeout, nowayout);
+
+	return 0;
+}
+
+static int __exit sunxi_wdt_remove(struct platform_device *pdev)
+{
+	struct sunxi_wdt_dev *sunxi_wdt = platform_get_drvdata(pdev);
+
+	watchdog_unregister_device(&sunxi_wdt->wdt_dev);
+	watchdog_set_drvdata(&sunxi_wdt->wdt_dev, NULL);
+
+	return 0;
+}
+
+static void sunxi_wdt_shutdown(struct platform_device *pdev)
+{
+	struct sunxi_wdt_dev *sunxi_wdt = platform_get_drvdata(pdev);
+
+	sunxi_wdt_stop(&sunxi_wdt->wdt_dev);
+}
+
+static const struct of_device_id sunxi_wdt_dt_ids[] = {
+	{ .compatible = "allwinner,sun4i-wdt" },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sunxi_wdt_dt_ids);
+
+static struct platform_driver sunxi_wdt_driver = {
+	.probe		= sunxi_wdt_probe,
+	.remove		= sunxi_wdt_remove,
+	.shutdown	= sunxi_wdt_shutdown,
+	.driver		= {
+		.owner		= THIS_MODULE,
+		.name		= DRV_NAME,
+		.of_match_table	= of_match_ptr(sunxi_wdt_dt_ids)
+	},
+};
+
+module_platform_driver(sunxi_wdt_driver);
+
+module_param(timeout, uint, 0);
+MODULE_PARM_DESC(timeout, "Watchdog heartbeat in seconds");
+
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
+		"(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Carlo Caione <carlo.caione at gmail.com>");
+MODULE_AUTHOR("Henrik Nordstrom <henrik at henriknordstrom.net>");
+MODULE_DESCRIPTION("sunxi WatchDog Timer Driver");
+MODULE_VERSION(DRV_VERSION);
-- 
1.8.3.3



From thomas.petazzoni at free-electrons.com  Tue Jul 16 17:43:07 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Jul 2013 23:43:07 +0200
Subject: [PATCHv5 00/11] MSI support for Marvell EBU PCIe driver
In-Reply-To: <20130716210509.GA29318@dhcp-172-17-186-34.nvidia.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E4167B.4000208@wwwdotorg.org>
 <20130715162709.GA24625@dhcp-172-17-186-34.nvidia.com>
 <20130716103351.15b0fb50@skate>
 <20130716210509.GA29318@dhcp-172-17-186-34.nvidia.com>
Message-ID: <20130716234307.3d5ed229@skate>

Thierry,

On Tue, 16 Jul 2013 14:05:10 -0700, Thierry Reding wrote:

> > This is from:
> > 
> > Subject: Re: [PATCH v2 6/8] pci: mvebu: add support for MSI
> > Date: Tue, 18 Jun 2013 16:57:11 -0600
> 
> Yes, I'm aware of that discussion. However we currently need to have the
> custom root bus scan implementation anyway because pci_scan_root_bus()
> just doesn't work on ARM. So again, since we'll have to rework the
> driver anyway in order to use pci_scan_root_bus() once the issues have
> been resolved, it wouldn't hurt to postpone the transition to the new
> ARM pcibios_add_bus() support until that point.
> 
> All I was trying to do was reduce the list of common dependencies in an
> attempt to make merging it easier.

Understood. Bjorn, since you are the one who originally requested
the usage of pcibios_add_bus(), would you agree with the idea proposed
by Thierry? It would remove one dependency for both the Marvell MSI
support and Tegra PCIe support, which would help getting this code
merged.

As Thierry points out, this can easily be resolved at a later point,
once the new hooks are merged in the ARM PCI core.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From swarren at wwwdotorg.org  Tue Jul 16 18:12:17 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 16:12:17 -0600
Subject: [PATCH V3] ARM: mm: restrict early_alloc to section-aligned memory
In-Reply-To: <1373481831-31459-1-git-send-email-swarren@wwwdotorg.org>
References: <1373481831-31459-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <51E5C541.4080800@wwwdotorg.org>

On 07/10/2013 12:43 PM, Stephen Warren wrote:
> From: Russell King <rmk at arm.linux.org.uk>
> 
> When map_lowmem() runs, and processes a memory bank whose start or end
> is not section-aligned, memory must be allocated to store the 2nd-level
> page tables. Those allocations are made by calling memblock_alloc().
> 
> At this point, the only memory that is free *and* mapped is memory which
> has already been mapped by map_lowmem() itself. For this reason, we must
> calculate the first point at which map_lowmem() will need to allocate
> memory, and set the memblock allocation limit to a lower address, so that
> memblock_alloc() is guaranteed to return memory that is already mapped.
> 
> This patch enhances sanity_check_meminfo() to calculate that memory
> address, and pass it to memblock_set_current_limit(), rather than just
> assuming the limit is arm_lowmem_limit.
> 
> The algorithm applied is:
> 
> * Default memblock_limit to arm_lowmem_limit in the absence of any other
>   limit; arm_lowmem_limit is the highest memory that is mapped by
>   map_lowmem().
> 
> * While walking the list of memblocks, if the start of a block is not
>   aligned, 2nd-level page tables will need to be allocated to map the
>   first few pages of the block. Hence, the memblock_limit must be before
>   the start of the block.
> 
> * Similarly, if the end of any block is not aligned, 2nd-level page
>   tables will need to be allocated to map the last few pages of the
>   block. Hence, the memblock_limit must point at the end of the block,
>   rounded down to section-alignment.
> 
> * The memory blocks are assumed to be sorted in address order, so the
>   first unaligned block start or end is used to set the limit.
> 
> With this algorithm, the start or end of almost any bank can be non-
> section-aligned. The only exception is that the start of bank 0 must
> be section-aligned, since otherwise memory would need to be allocated
> when mapping the start of bank 0, which occurs before any free memory
> is mapped.
> 
> Not-yet-signed-off-by: Russell King <rmk at arm.linux.org.uk>
> [swarren, wrote commit description, rewrote calculation of memblock_limit]
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> ---
> V3: completely new implementation based on Russell's suggestion.
> 
> Russell, since this is strongly based on your patch, I set you as the
> author in git. I assume that's OK. If not, let me know and I'll change
> the patch to my authorship and add a note to the commit description
> that it's based on your original.

Russell, should I assume that no comment implies this is OK and I should
send it to the ARM patch tracker?


From swarren at wwwdotorg.org  Tue Jul 16 18:17:22 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 16:17:22 -0600
Subject: [PATCH 3/4] ARM: tegra: sort Makefile and fix whitespace
In-Reply-To: <1374013043-4693-1-git-send-email-swarren@wwwdotorg.org>
References: <1374013043-4693-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1374013043-4693-3-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Sort Makefile alphabetically, and consistently use TABs not spaces for
all indentation.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/Makefile | 41 +++++++++++++++++++----------------------
 1 file changed, 19 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index efb1e01..6ac978b 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -1,34 +1,31 @@
 asflags-y				+= -march=armv7-a
 
-obj-y                                   += common.o
-obj-y                                   += io.o
-obj-y                                   += irq.o
+obj-y					+= apbio.o
+obj-y					+= board-harmony-pcie.o
+obj-y					+= board-paz00.o
+obj-y					+= common.o
+obj-$(CONFIG_CPU_IDLE)			+= cpuidle.o
+obj-$(CONFIG_CPU_IDLE)			+= cpuidle-tegra20.o
+obj-$(CONFIG_CPU_IDLE)			+= cpuidle-tegra30.o
+obj-$(CONFIG_CPU_IDLE)			+= cpuidle-tegra114.o
+obj-y					+= flowctrl.o
 obj-y					+= fuse.o
+obj-$(CONFIG_SMP)			+= headsmp.o
+obj-$(CONFIG_HOTPLUG_CPU)		+= hotplug.o
+obj-y					+= io.o
+obj-y					+= irq.o
+obj-$(CONFIG_TEGRA_PCI)			+= pcie.o
+obj-$(CONFIG_SMP)			+= platsmp.o
+obj-y					+= pm.o
 obj-y					+= pmc.o
-obj-y					+= flowctrl.o
 obj-y					+= powergate.o
-obj-y					+= apbio.o
-obj-y					+= pm.o
 obj-y					+= reset.o
 obj-y					+= reset-handler.o
-obj-y					+= sleep.o
 obj-y					+= tegra.o
-obj-$(CONFIG_CPU_IDLE)			+= cpuidle.o
-obj-y					+= tegra20_speedo.o
 obj-y					+= tegra2_emc.o
-obj-y					+= sleep-tegra20.o
-obj-$(CONFIG_CPU_IDLE)			+= cpuidle-tegra20.o
+obj-y					+= tegra20_speedo.o
 obj-y					+= tegra30_speedo.o
-obj-y					+= sleep-tegra30.o
-obj-$(CONFIG_CPU_IDLE)			+= cpuidle-tegra30.o
-obj-$(CONFIG_SMP)			+= platsmp.o headsmp.o
-obj-$(CONFIG_HOTPLUG_CPU)               += hotplug.o
-obj-$(CONFIG_TEGRA_PCI)			+= pcie.o
-
 obj-y					+= tegra114_speedo.o
+obj-y					+= sleep.o
+obj-y					+= sleep-tegra20.o
 obj-y					+= sleep-tegra30.o
-obj-$(CONFIG_CPU_IDLE)			+= cpuidle-tegra114.o
-
-obj-y		+= board-harmony-pcie.o
-
-obj-y		+= board-paz00.o
-- 
1.8.1.5



From swarren at wwwdotorg.org  Tue Jul 16 18:17:23 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 16:17:23 -0600
Subject: [PATCH 4/4] ARM: tegra: move config TEGRA_AHB
In-Reply-To: <1374013043-4693-1-git-send-email-swarren@wwwdotorg.org>
References: <1374013043-4693-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1374013043-4693-4-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

The Tegra AHB driver is located in drivers/amba. Move the Kconfig option
that enables it to the Kconfig file in that directory. This completely
decouples it from arch/arm/mach-tegra.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/Kconfig | 8 --------
 drivers/Kconfig             | 2 ++
 drivers/amba/Kconfig        | 8 ++++++++
 3 files changed, 10 insertions(+), 8 deletions(-)
 create mode 100644 drivers/amba/Kconfig

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 9a4ec62..94713e4 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -57,14 +57,6 @@ config TEGRA_PCI
 	depends on ARCH_TEGRA
 	select PCI
 
-config TEGRA_AHB
-	bool "Enable AHB driver for NVIDIA Tegra SoCs"
-	default y
-	help
-	  Adds AHB configuration functionality for NVIDIA Tegra SoCs,
-	  which controls AHB bus master arbitration and some
-	  performance parameters(priority, prefech size).
-
 config TEGRA_EMC_SCALING_ENABLE
 	bool "Enable scaling the memory frequency"
 
diff --git a/drivers/Kconfig b/drivers/Kconfig
index aa43b91..5603bc3 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -166,4 +166,6 @@ source "drivers/reset/Kconfig"
 
 source "drivers/fmc/Kconfig"
 
+source "drivers/amba/Kconfig"
+
 endmenu
diff --git a/drivers/amba/Kconfig b/drivers/amba/Kconfig
new file mode 100644
index 0000000..9244e48
--- /dev/null
+++ b/drivers/amba/Kconfig
@@ -0,0 +1,8 @@
+config TEGRA_AHB
+	bool "AHB driver for NVIDIA Tegra SoCs"
+	depends on ARCH_TEGRA
+	default y
+	help
+	  Adds AHB configuration functionality for NVIDIA Tegra SoCs,
+	  which controls AHB bus master arbitration and some
+	  performance parameters (priority, prefetch size).
-- 
1.8.1.5



From swarren at wwwdotorg.org  Tue Jul 16 18:17:20 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 16:17:20 -0600
Subject: [PATCH 1/4] ARM: tegra: hide CONFIG_ARCH_TEGRA_*_SOC
Message-ID: <1374013043-4693-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Enable all or none of Tegra support, rather than using separate Kconfig
options for individual SoCs. This will allow various conditional logic
to be simplified, as well as presenting fewer Kconfig options to the
user.

Once all use of ARCH_TEGRA_*_SOC has been replaced with ARCH_TEGRA, the
SoC-specific options will be removed.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
I'll follow this up with patches for driver/memory, iommu, clk, pinctrl
and sound/soc which remove use of ARCH_TEGRA_*_SOC, and finally with a
series to remove those config options from the Tegra tree; that can be
applied once everything else is merged together.

 arch/arm/configs/tegra_defconfig |  3 --
 arch/arm/mach-tegra/Kconfig      | 67 +++++++++++++++-------------------------
 2 files changed, 25 insertions(+), 45 deletions(-)

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index efb03b3..9760a0f 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -24,9 +24,6 @@ CONFIG_PARTITION_ADVANCED=y
 # CONFIG_IOSCHED_CFQ is not set
 CONFIG_GPIO_PCA953X=y
 CONFIG_ARCH_TEGRA=y
-CONFIG_ARCH_TEGRA_2x_SOC=y
-CONFIG_ARCH_TEGRA_3x_SOC=y
-CONFIG_ARCH_TEGRA_114_SOC=y
 CONFIG_TEGRA_PCI=y
 CONFIG_TEGRA_EMC_SCALING_ENABLE=y
 CONFIG_SMP=y
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index add345e..44cb28c 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -1,19 +1,41 @@
 config ARCH_TEGRA
 	bool "NVIDIA Tegra" if ARCH_MULTI_V7
 	select ARCH_HAS_CPUFREQ
+	select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
 	select ARCH_REQUIRE_GPIOLIB
+	select ARCH_TEGRA_2x_SOC
+	select ARCH_TEGRA_3x_SOC
+	select ARCH_TEGRA_114_SOC
+	select ARM_ERRATA_720789
+	select ARM_ERRATA_754322
+	select ARM_ERRATA_754327 if SMP
+	select ARM_ERRATA_764369 if SMP
+	select ARM_ERRATA_798181
+	select ARM_GIC
+	select ARM_L1_CACHE_SHIFT_6
 	select CLKDEV_LOOKUP
 	select CLKSRC_MMIO
 	select CLKSRC_OF
 	select COMMON_CLK
+	select CPU_V7
 	select GENERIC_CLOCKEVENTS
+	select HAVE_ARM_ARCH_TIMER
 	select HAVE_ARM_SCU if SMP
 	select HAVE_ARM_TWD if LOCAL_TIMERS
 	select HAVE_CLK
 	select HAVE_SMP
 	select MIGHT_HAVE_CACHE_L2X0
+	select PINCTRL
+	select PINCTRL_TEGRA114
+	select PINCTRL_TEGRA20
+	select PINCTRL_TEGRA30
+	select PL310_ERRATA_727915 if CACHE_L2X0
+	select PL310_ERRATA_769419 if CACHE_L2X0
 	select SOC_BUS
 	select SPARSE_IRQ
+	select USB_ARCH_HAS_EHCI if USB_SUPPORT
+	select USB_ULPI if USB_PHY
+	select USB_ULPI_VIEWPORT if USB_PHY
 	select USE_OF
 	help
 	  This enables support for NVIDIA Tegra based systems.
@@ -22,52 +44,13 @@ menu "NVIDIA Tegra options"
 	depends on ARCH_TEGRA
 
 config ARCH_TEGRA_2x_SOC
-	bool "Enable support for Tegra20 family"
-	select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
-	select ARM_ERRATA_720789
-	select ARM_ERRATA_754327 if SMP
-	select ARM_ERRATA_764369 if SMP
-	select ARM_GIC
-	select CPU_V7
-	select PINCTRL
-	select PINCTRL_TEGRA20
-	select PL310_ERRATA_727915 if CACHE_L2X0
-	select PL310_ERRATA_769419 if CACHE_L2X0
-	select USB_ARCH_HAS_EHCI if USB_SUPPORT
-	select USB_ULPI if USB_PHY
-	select USB_ULPI_VIEWPORT if USB_PHY
-	help
-	  Support for NVIDIA Tegra AP20 and T20 processors, based on the
-	  ARM CortexA9MP CPU and the ARM PL310 L2 cache controller
+	bool
 
 config ARCH_TEGRA_3x_SOC
-	bool "Enable support for Tegra30 family"
-	select ARM_ERRATA_754322
-	select ARM_ERRATA_764369 if SMP
-	select ARM_GIC
-	select CPU_V7
-	select PINCTRL
-	select PINCTRL_TEGRA30
-	select PL310_ERRATA_769419 if CACHE_L2X0
-	select USB_ARCH_HAS_EHCI if USB_SUPPORT
-	select USB_ULPI if USB_PHY
-	select USB_ULPI_VIEWPORT if USB_PHY
-	help
-	  Support for NVIDIA Tegra T30 processor family, based on the
-	  ARM CortexA9MP CPU and the ARM PL310 L2 cache controller
+	bool
 
 config ARCH_TEGRA_114_SOC
-	bool "Enable support for Tegra114 family"
-	select HAVE_ARM_ARCH_TIMER
-	select ARM_ERRATA_798181
-	select ARM_GIC
-	select ARM_L1_CACHE_SHIFT_6
-	select CPU_V7
-	select PINCTRL
-	select PINCTRL_TEGRA114
-	help
-	  Support for NVIDIA Tegra T114 processor family, based on the
-	  ARM CortexA15MP CPU
+	bool
 
 config TEGRA_PCI
 	bool "PCI Express support"
-- 
1.8.1.5



From swarren at wwwdotorg.org  Tue Jul 16 18:17:21 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 16:17:21 -0600
Subject: [PATCH 2/4] ARM: tegra: remove use of CONFIG_ARCH_TEGRA_*_SOC
In-Reply-To: <1374013043-4693-1-git-send-email-swarren@wwwdotorg.org>
References: <1374013043-4693-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1374013043-4693-2-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

Modify code in mach-tegra not to use ARCH_TEGRA_*_SOC, but just
ARCH_TEGRA. This simplifies various conditional logic.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/Kconfig         |  2 +-
 arch/arm/mach-tegra/Makefile        | 30 ++++++++++++------------------
 arch/arm/mach-tegra/board.h         |  2 +-
 arch/arm/mach-tegra/cpuidle.c       |  9 +++------
 arch/arm/mach-tegra/fuse.h          | 14 --------------
 arch/arm/mach-tegra/hotplug.c       | 11 ++++++++---
 arch/arm/mach-tegra/platsmp.c       | 12 +++++++-----
 arch/arm/mach-tegra/pm.c            |  6 ++----
 arch/arm/mach-tegra/reset-handler.S | 16 ++--------------
 arch/arm/mach-tegra/sleep.h         |  6 ------
 arch/arm/mach-tegra/tegra.c         |  3 +--
 11 files changed, 37 insertions(+), 74 deletions(-)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 44cb28c..9a4ec62 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -54,7 +54,7 @@ config ARCH_TEGRA_114_SOC
 
 config TEGRA_PCI
 	bool "PCI Express support"
-	depends on ARCH_TEGRA_2x_SOC
+	depends on ARCH_TEGRA
 	select PCI
 
 config TEGRA_AHB
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 98b184e..efb1e01 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -14,27 +14,21 @@ obj-y					+= reset-handler.o
 obj-y					+= sleep.o
 obj-y					+= tegra.o
 obj-$(CONFIG_CPU_IDLE)			+= cpuidle.o
-obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= tegra20_speedo.o
-obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= tegra2_emc.o
-obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= sleep-tegra20.o
-ifeq ($(CONFIG_CPU_IDLE),y)
-obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= cpuidle-tegra20.o
-endif
-obj-$(CONFIG_ARCH_TEGRA_3x_SOC)		+= tegra30_speedo.o
-obj-$(CONFIG_ARCH_TEGRA_3x_SOC)		+= sleep-tegra30.o
-ifeq ($(CONFIG_CPU_IDLE),y)
-obj-$(CONFIG_ARCH_TEGRA_3x_SOC)		+= cpuidle-tegra30.o
-endif
+obj-y					+= tegra20_speedo.o
+obj-y					+= tegra2_emc.o
+obj-y					+= sleep-tegra20.o
+obj-$(CONFIG_CPU_IDLE)			+= cpuidle-tegra20.o
+obj-y					+= tegra30_speedo.o
+obj-y					+= sleep-tegra30.o
+obj-$(CONFIG_CPU_IDLE)			+= cpuidle-tegra30.o
 obj-$(CONFIG_SMP)			+= platsmp.o headsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)               += hotplug.o
 obj-$(CONFIG_TEGRA_PCI)			+= pcie.o
 
-obj-$(CONFIG_ARCH_TEGRA_114_SOC)	+= tegra114_speedo.o
-obj-$(CONFIG_ARCH_TEGRA_114_SOC)	+= sleep-tegra30.o
-ifeq ($(CONFIG_CPU_IDLE),y)
-obj-$(CONFIG_ARCH_TEGRA_114_SOC)	+= cpuidle-tegra114.o
-endif
+obj-y					+= tegra114_speedo.o
+obj-y					+= sleep-tegra30.o
+obj-$(CONFIG_CPU_IDLE)			+= cpuidle-tegra114.o
 
-obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= board-harmony-pcie.o
+obj-y		+= board-harmony-pcie.o
 
-obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= board-paz00.o
+obj-y		+= board-paz00.o
diff --git a/arch/arm/mach-tegra/board.h b/arch/arm/mach-tegra/board.h
index 9a6659f..e86604f 100644
--- a/arch/arm/mach-tegra/board.h
+++ b/arch/arm/mach-tegra/board.h
@@ -42,7 +42,7 @@ static inline int tegra_clk_debugfs_init(void) { return 0; }
 #endif
 
 int __init tegra_powergate_init(void);
-#if defined(CONFIG_ARCH_TEGRA_2x_SOC) && defined(CONFIG_DEBUG_FS)
+#if defined(CONFIG_DEBUG_FS)
 int __init tegra_powergate_debugfs_init(void);
 #else
 static inline int tegra_powergate_debugfs_init(void) { return 0; }
diff --git a/arch/arm/mach-tegra/cpuidle.c b/arch/arm/mach-tegra/cpuidle.c
index e85973c..44bad5d 100644
--- a/arch/arm/mach-tegra/cpuidle.c
+++ b/arch/arm/mach-tegra/cpuidle.c
@@ -31,16 +31,13 @@ void __init tegra_cpuidle_init(void)
 {
 	switch (tegra_chip_id) {
 	case TEGRA20:
-		if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC))
-			tegra20_cpuidle_init();
+		tegra20_cpuidle_init();
 		break;
 	case TEGRA30:
-		if (IS_ENABLED(CONFIG_ARCH_TEGRA_3x_SOC))
-			tegra30_cpuidle_init();
+		tegra30_cpuidle_init();
 		break;
 	case TEGRA114:
-		if (IS_ENABLED(CONFIG_ARCH_TEGRA_114_SOC))
-			tegra114_cpuidle_init();
+		tegra114_cpuidle_init();
 		break;
 	}
 }
diff --git a/arch/arm/mach-tegra/fuse.h b/arch/arm/mach-tegra/fuse.h
index def7968..e589322 100644
--- a/arch/arm/mach-tegra/fuse.h
+++ b/arch/arm/mach-tegra/fuse.h
@@ -56,23 +56,9 @@ void tegra_init_fuse(void);
 bool tegra_spare_fuse(int bit);
 u32 tegra_fuse_readl(unsigned long offset);
 
-#ifdef CONFIG_ARCH_TEGRA_2x_SOC
 void tegra20_init_speedo_data(void);
-#else
-static inline void tegra20_init_speedo_data(void) {}
-#endif
-
-#ifdef CONFIG_ARCH_TEGRA_3x_SOC
 void tegra30_init_speedo_data(void);
-#else
-static inline void tegra30_init_speedo_data(void) {}
-#endif
-
-#ifdef CONFIG_ARCH_TEGRA_114_SOC
 void tegra114_init_speedo_data(void);
-#else
-static inline void tegra114_init_speedo_data(void) {}
-#endif
 #endif /* __ASSEMBLY__ */
 
 #endif
diff --git a/arch/arm/mach-tegra/hotplug.c b/arch/arm/mach-tegra/hotplug.c
index a52c10e..8b79d83 100644
--- a/arch/arm/mach-tegra/hotplug.c
+++ b/arch/arm/mach-tegra/hotplug.c
@@ -62,10 +62,15 @@ void __init tegra_hotplug_init(void)
 	if (!IS_ENABLED(CONFIG_HOTPLUG_CPU))
 		return;
 
-	if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) && tegra_chip_id == TEGRA20)
+	switch (tegra_chip_id) {
+	case TEGRA20:
 		tegra_hotplug_shutdown = tegra20_hotplug_shutdown;
-	if (IS_ENABLED(CONFIG_ARCH_TEGRA_3x_SOC) && tegra_chip_id == TEGRA30)
+		break;
+	case TEGRA30:
 		tegra_hotplug_shutdown = tegra30_hotplug_shutdown;
-	if (IS_ENABLED(CONFIG_ARCH_TEGRA_114_SOC) && tegra_chip_id == TEGRA114)
+		break;
+	case TEGRA114:
 		tegra_hotplug_shutdown = tegra30_hotplug_shutdown;
+		break;
+	}
 }
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index 97b33a2..b76a5d8 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -170,14 +170,16 @@ static int tegra114_boot_secondary(unsigned int cpu, struct task_struct *idle)
 static int tegra_boot_secondary(unsigned int cpu,
 					  struct task_struct *idle)
 {
-	if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) && tegra_chip_id == TEGRA20)
+	switch (tegra_chip_id) {
+	case TEGRA20:
 		return tegra20_boot_secondary(cpu, idle);
-	if (IS_ENABLED(CONFIG_ARCH_TEGRA_3x_SOC) && tegra_chip_id == TEGRA30)
+	case TEGRA30:
 		return tegra30_boot_secondary(cpu, idle);
-	if (IS_ENABLED(CONFIG_ARCH_TEGRA_114_SOC) && tegra_chip_id == TEGRA114)
+	case TEGRA114:
 		return tegra114_boot_secondary(cpu, idle);
-
-	return -EINVAL;
+	default:
+		return -EINVAL;
+	}
 }
 
 static void __init tegra_smp_prepare_cpus(unsigned int max_cpus)
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index 261fec1..cae6894 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -48,12 +48,10 @@ static void tegra_tear_down_cpu_init(void)
 {
 	switch (tegra_chip_id) {
 	case TEGRA20:
-		if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC))
-			tegra_tear_down_cpu = tegra20_tear_down_cpu;
+		tegra_tear_down_cpu = tegra20_tear_down_cpu;
 		break;
 	case TEGRA30:
-		if (IS_ENABLED(CONFIG_ARCH_TEGRA_3x_SOC))
-			tegra_tear_down_cpu = tegra30_tear_down_cpu;
+		tegra_tear_down_cpu = tegra30_tear_down_cpu;
 		break;
 	}
 }
diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
index 39dc9e78..57fafb7 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -123,10 +123,9 @@ ENTRY(__tegra_cpu_reset_handler)
 	cpsid	aif, 0x13			@ SVC mode, interrupts disabled
 
 	tegra_get_soc_id TEGRA_APB_MISC_BASE, r6
-#ifdef CONFIG_ARCH_TEGRA_2x_SOC
 t20_check:
 	cmp	r6, #TEGRA20
-	bne	after_t20_check
+	bne	t30_check
 t20_errata:
 	# Tegra20 is a Cortex-A9 r1p1
 	mrc	p15, 0, r0, c1, c0, 0   @ read system control register
@@ -137,12 +136,9 @@ t20_errata:
 	orr	r0, r0, #1 << 11        @ erratum 751472
 	mcr	p15, 0, r0, c15, c0, 1  @ write diagnostic register
 	b	after_errata
-after_t20_check:
-#endif
-#ifdef CONFIG_ARCH_TEGRA_3x_SOC
 t30_check:
 	cmp	r6, #TEGRA30
-	bne	after_t30_check
+	bne	after_errata
 t30_errata:
 	# Tegra30 is a Cortex-A9 r2p9
 	mrc	p15, 0, r0, c15, c0, 1  @ read diagnostic register
@@ -150,8 +146,6 @@ t30_errata:
 	orr	r0, r0, #1 << 11        @ erratum 751472
 	mcr	p15, 0, r0, c15, c0, 1  @ write diagnostic register
 	b	after_errata
-after_t30_check:
-#endif
 after_errata:
 	mrc	p15, 0, r10, c0, c0, 5		@ MPIDR
 	and	r10, r10, #0x3			@ R10 = CPU number
@@ -166,7 +160,6 @@ after_errata:
 	bleq	__die				@ CPU not present (to OS)
 #endif
 
-#ifdef CONFIG_ARCH_TEGRA_2x_SOC
 	/* Are we on Tegra20? */
 	cmp	r6, #TEGRA20
 	bne	1f
@@ -176,7 +169,6 @@ after_errata:
 	cmp	r10, #0
 	strne	r0, [r5, #PMC_SCRATCH41]
 1:
-#endif
 
 	/* Waking up from LP2? */
 	ldr	r9, [r12, #RESET_DATA(MASK_LP2)]
@@ -221,13 +213,10 @@ __die:
 	cmp	r6, #TEGRA20
 	bne	1f
 
-#ifdef CONFIG_ARCH_TEGRA_2x_SOC
 	mov32	r0, 0x1111
 	mov	r1, r0, lsl r10
 	str	r1, [r7, #0x340]		@ CLK_RST_CPU_CMPLX_SET
-#endif
 1:
-#ifdef CONFIG_ARCH_TEGRA_3x_SOC
 	mov32	r6, TEGRA_FLOW_CTRL_BASE
 
 	cmp	r10, #0
@@ -257,7 +246,6 @@ __die:
 
 	mov	r0, r11, lsl #8
 	str	r0, [r7, #348]			@ CLK_CPU_CMPLX_SET
-#endif
 
 	/* If the CPU still isn't dead, just spin here. */
 	b	.
diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
index 98b7da6..461ff1b 100644
--- a/arch/arm/mach-tegra/sleep.h
+++ b/arch/arm/mach-tegra/sleep.h
@@ -35,11 +35,9 @@
 #define PMC_SCRATCH39	0x138
 #define PMC_SCRATCH41	0x140
 
-#ifdef CONFIG_ARCH_TEGRA_2x_SOC
 #define CPU_RESETTABLE		2
 #define CPU_RESETTABLE_SOON	1
 #define CPU_NOT_RESETTABLE	0
-#endif
 
 #ifdef __ASSEMBLY__
 /* returns the offset of the flow controller halt register for a cpu */
@@ -157,11 +155,7 @@ static inline void tegra_hotplug_init(void) {}
 void tegra20_cpu_shutdown(int cpu);
 int tegra20_cpu_is_resettable_soon(void);
 void tegra20_cpu_clear_resettable(void);
-#ifdef CONFIG_ARCH_TEGRA_2x_SOC
 void tegra20_cpu_set_resettable_soon(void);
-#else
-static inline void tegra20_cpu_set_resettable_soon(void) {}
-#endif
 
 int tegra20_sleep_cpu_secondary_finish(unsigned long);
 void tegra20_tear_down_cpu(void);
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index fc97cfd..5334252 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -104,8 +104,7 @@ static void __init harmony_init(void)
 
 static void __init paz00_init(void)
 {
-	if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC))
-		tegra_paz00_wifikill_init();
+	tegra_paz00_wifikill_init();
 }
 
 static struct {
-- 
1.8.1.5



From swarren at wwwdotorg.org  Tue Jul 16 18:19:07 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 16:19:07 -0600
Subject: [PATCH] memory: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
Message-ID: <1374013147-4775-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

I'm planning to remove CONFIG_ARCH_TEGRA_*_SOC, leaving just ARCH_TEGRA.
This will reduce the number of configurations that need to be supported
by core Tegra code, e.g. CPU idle, hotplug. As a precursor, we need to
update Kconfig for all Tegra drivers not to reference ARCH_TEGRA_*_SOC.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 drivers/memory/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 29a11db..0ed76f7 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -33,7 +33,7 @@ config MVEBU_DEVBUS
 config TEGRA20_MC
 	bool "Tegra20 Memory Controller(MC) driver"
 	default y
-	depends on ARCH_TEGRA_2x_SOC
+	depends on ARCH_TEGRA
 	help
 	  This driver is for the Memory Controller(MC) module available
 	  in Tegra20 SoCs, mainly for a address translation fault
@@ -43,7 +43,7 @@ config TEGRA20_MC
 config TEGRA30_MC
 	bool "Tegra30 Memory Controller(MC) driver"
 	default y
-	depends on ARCH_TEGRA_3x_SOC
+	depends on ARCH_TEGRA
 	help
 	  This driver is for the Memory Controller(MC) module available
 	  in Tegra30 SoCs, mainly for a address translation fault
-- 
1.8.1.5



From swarren at wwwdotorg.org  Tue Jul 16 18:20:22 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 16:20:22 -0600
Subject: [PATCH] iommu: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
Message-ID: <1374013222-4856-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

I'm planning to remove CONFIG_ARCH_TEGRA_*_SOC, leaving just ARCH_TEGRA.
This will reduce the number of configurations that need to be supported
by core Tegra code, e.g. CPU idle, hotplug. As a precursor, we need to
update Kconfig for all Tegra drivers not to reference ARCH_TEGRA_*_SOC.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 drivers/iommu/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 820d85c..0da7938 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -148,7 +148,7 @@ config OMAP_IOMMU_DEBUG
 
 config TEGRA_IOMMU_GART
 	bool "Tegra GART IOMMU Support"
-	depends on ARCH_TEGRA_2x_SOC
+	depends on ARCH_TEGRA
 	select IOMMU_API
 	help
 	  Enables support for remapping discontiguous physical memory
-- 
1.8.1.5



From swarren at wwwdotorg.org  Tue Jul 16 18:27:47 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 16:27:47 -0600
Subject: [PATCH] ASoC: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
Message-ID: <1374013667-21435-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

I'm planning to remove CONFIG_ARCH_TEGRA_*_SOC, leaving just ARCH_TEGRA.
This will reduce the number of configurations that need to be supported
by core Tegra code, e.g. CPU idle, hotplug. As a precursor, we need to
update Kconfig for all Tegra drivers not to reference ARCH_TEGRA_*_SOC.

Stop selecting I2S/AC97/SPDIF controller drivers from the machine driver
config options; this doesn't really work if we don't know which specific
SoC(s) we're building for. However, set their default values based on
SND_SOC_TEGRA, since most people will probably want to enable support for
all SoCs. This also avoids the need to change any defconfig files.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 sound/soc/tegra/Kconfig | 36 +++++++++++++++---------------------
 1 file changed, 15 insertions(+), 21 deletions(-)

diff --git a/sound/soc/tegra/Kconfig b/sound/soc/tegra/Kconfig
index 68fd6d0..321a6c9 100644
--- a/sound/soc/tegra/Kconfig
+++ b/sound/soc/tegra/Kconfig
@@ -7,8 +7,9 @@ config SND_SOC_TEGRA
 	  Say Y or M here if you want support for SoC audio on Tegra.
 
 config SND_SOC_TEGRA20_AC97
-	tristate
-	depends on SND_SOC_TEGRA && ARCH_TEGRA_2x_SOC
+	tristate "Tegra20 AC97 controller"
+	depends on SND_SOC_TEGRA
+	default SND_SOC_TEGRA
 	select SND_SOC_AC97_BUS
 	select SND_SOC_TEGRA20_DAS
 	help
@@ -18,15 +19,16 @@ config SND_SOC_TEGRA20_AC97
 
 config SND_SOC_TEGRA20_DAS
 	tristate
-	depends on SND_SOC_TEGRA && ARCH_TEGRA_2x_SOC
+	depends on SND_SOC_TEGRA
 	help
 	  Say Y or M if you want to add support for the Tegra20 DAS module.
 	  You will also need to select the individual machine drivers to
 	  support below.
 
 config SND_SOC_TEGRA20_I2S
-	tristate
-	depends on SND_SOC_TEGRA && ARCH_TEGRA_2x_SOC
+	tristate "Tegra20 I2C controller"
+	depends on SND_SOC_TEGRA
+	default SND_SOC_TEGRA
 	select SND_SOC_TEGRA20_DAS
 	help
 	  Say Y or M if you want to add support for codecs attached to the
@@ -34,9 +36,9 @@ config SND_SOC_TEGRA20_I2S
 	  machine drivers to support below.
 
 config SND_SOC_TEGRA20_SPDIF
-	tristate
-	depends on SND_SOC_TEGRA && ARCH_TEGRA_2x_SOC
-	default m
+	tristate "Tegra20 SPDIF controller"
+	default SND_SOC_TEGRA
+	depends on SND_SOC_TEGRA
 	help
 	  Say Y or M if you want to add support for the Tegra20 SPDIF interface.
 	  You will also need to select the individual machine drivers to support
@@ -44,15 +46,16 @@ config SND_SOC_TEGRA20_SPDIF
 
 config SND_SOC_TEGRA30_AHUB
 	tristate
-	depends on SND_SOC_TEGRA && ARCH_TEGRA_3x_SOC
+	depends on SND_SOC_TEGRA
 	help
 	  Say Y or M if you want to add support for the Tegra20 AHUB module.
 	  You will also need to select the individual machine drivers to
 	  support below.
 
 config SND_SOC_TEGRA30_I2S
-	tristate
-	depends on SND_SOC_TEGRA && ARCH_TEGRA_3x_SOC
+	tristate "Tegra30 I2S controller"
+	depends on SND_SOC_TEGRA
+	default SND_SOC_TEGRA
 	select SND_SOC_TEGRA30_AHUB
 	help
 	  Say Y or M if you want to add support for codecs attached to the
@@ -62,8 +65,6 @@ config SND_SOC_TEGRA30_I2S
 config SND_SOC_TEGRA_RT5640
 	tristate "SoC Audio support for Tegra boards using an RT5640 codec"
 	depends on SND_SOC_TEGRA && I2C && GPIOLIB
-	select SND_SOC_TEGRA20_I2S if ARCH_TEGRA_2x_SOC
-	select SND_SOC_TEGRA30_I2S if ARCH_TEGRA_3x_SOC
 	select SND_SOC_RT5640
 	help
 	  Say Y or M here if you want to add support for SoC audio on Tegra
@@ -72,8 +73,6 @@ config SND_SOC_TEGRA_RT5640
 config SND_SOC_TEGRA_WM8753
 	tristate "SoC Audio support for Tegra boards using a WM8753 codec"
 	depends on SND_SOC_TEGRA && I2C && GPIOLIB
-	select SND_SOC_TEGRA20_I2S if ARCH_TEGRA_2x_SOC
-	select SND_SOC_TEGRA30_I2S if ARCH_TEGRA_3x_SOC
 	select SND_SOC_WM8753
 	help
 	  Say Y or M here if you want to add support for SoC audio on Tegra
@@ -82,8 +81,6 @@ config SND_SOC_TEGRA_WM8753
 config SND_SOC_TEGRA_WM8903
 	tristate "SoC Audio support for Tegra boards using a WM8903 codec"
 	depends on SND_SOC_TEGRA && I2C && GPIOLIB
-	select SND_SOC_TEGRA20_I2S if ARCH_TEGRA_2x_SOC
-	select SND_SOC_TEGRA30_I2S if ARCH_TEGRA_3x_SOC
 	select SND_SOC_WM8903
 	help
 	  Say Y or M here if you want to add support for SoC audio on Tegra
@@ -92,8 +89,7 @@ config SND_SOC_TEGRA_WM8903
 
 config SND_SOC_TEGRA_WM9712
 	tristate "SoC Audio support for Tegra boards using a WM9712 codec"
-	depends on SND_SOC_TEGRA && ARCH_TEGRA_2x_SOC && GPIOLIB
-	select SND_SOC_TEGRA20_AC97
+	depends on SND_SOC_TEGRA && GPIOLIB
 	select SND_SOC_WM9712
 	help
 	  Say Y or M here if you want to add support for SoC audio on Tegra
@@ -102,7 +98,6 @@ config SND_SOC_TEGRA_WM9712
 config SND_SOC_TEGRA_TRIMSLICE
 	tristate "SoC Audio support for TrimSlice board"
 	depends on SND_SOC_TEGRA && I2C
-	select SND_SOC_TEGRA20_I2S if ARCH_TEGRA_2x_SOC
 	select SND_SOC_TLV320AIC23
 	help
 	  Say Y or M here if you want to add support for SoC audio on the
@@ -111,7 +106,6 @@ config SND_SOC_TEGRA_TRIMSLICE
 config SND_SOC_TEGRA_ALC5632
 	tristate "SoC Audio support for Tegra boards using an ALC5632 codec"
 	depends on SND_SOC_TEGRA && I2C && GPIOLIB
-	select SND_SOC_TEGRA20_I2S if ARCH_TEGRA_2x_SOC
 	select SND_SOC_ALC5632
 	help
 	  Say Y or M here if you want to add support for SoC audio on the
-- 
1.8.1.5



From swarren at wwwdotorg.org  Tue Jul 16 18:33:59 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 16:33:59 -0600
Subject: [PATCH] clk: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
Message-ID: <1374014039-22469-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

I'm planning to remove CONFIG_ARCH_TEGRA_*_SOC, leaving just ARCH_TEGRA.
This will reduce the number of configurations that need to be supported
by core Tegra code, e.g. CPU idle, hotplug. As a precursor, we need to
update Kconfig for all Tegra drivers not to reference ARCH_TEGRA_*_SOC.

The Tegra clock driver contains a fairly large amount of SoC-specific
code and data. Introduce explicit config options so that the user can
trim the set of supported SoCs if they wish. Default these to on, since
most people will probably want to enable support for all SoCs. This also
avoids the need to change any defconfig files.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 drivers/clk/Kconfig         |  2 ++
 drivers/clk/Makefile        |  2 +-
 drivers/clk/tegra/Kconfig   | 24 ++++++++++++++++++++++++
 drivers/clk/tegra/Makefile  |  6 +++---
 drivers/clk/tegra/clk-pll.c |  4 ++--
 5 files changed, 32 insertions(+), 6 deletions(-)
 create mode 100644 drivers/clk/tegra/Kconfig

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 51380d6..8efaf3e 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -87,6 +87,8 @@ config CLK_PPC_CORENET
 	  This adds the clock driver support for Freescale PowerPC corenet
 	  platforms using common clock framework.
 
+source "drivers/clk/tegra/Kconfig"
+
 endmenu
 
 source "drivers/clk/mvebu/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4038c2b..3368f03 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -30,7 +30,7 @@ obj-$(CONFIG_ARCH_SUNXI)	+= sunxi/
 obj-$(CONFIG_ARCH_U8500)	+= ux500/
 obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500.o
 obj-$(CONFIG_ARCH_ZYNQ)		+= zynq/
-obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
+obj-$(CONFIG_CLK_TEGRA)		+= tegra/
 obj-$(CONFIG_PLAT_SAMSUNG)	+= samsung/
 
 obj-$(CONFIG_X86)		+= x86/
diff --git a/drivers/clk/tegra/Kconfig b/drivers/clk/tegra/Kconfig
new file mode 100644
index 0000000..abe609b
--- /dev/null
+++ b/drivers/clk/tegra/Kconfig
@@ -0,0 +1,24 @@
+config CLK_TEGRA
+	bool "Clock driver for NVIDIA Tegra SoCs"
+	depends on ARCH_TEGRA
+	default y
+	help
+	  Say y here to enable clock driver support for NVIDIA Tegra SoCs.
+
+	  This option provides core functionality; enable support for specific
+	  individual SoCs using the options below.
+
+config CLK_TEGRA20
+	bool "Tegra20 clock support"
+	depends on CLK_TEGRA
+	default y
+
+config CLK_TEGRA30
+	bool "Tegra30 clock support"
+	depends on CLK_TEGRA
+	default y
+
+config CLK_TEGRA114
+	bool "Tegra114 clock support"
+	depends on CLK_TEGRA
+	default y
diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index f49fac2..7b1a929 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -7,6 +7,6 @@ obj-y					+= clk-pll.o
 obj-y					+= clk-pll-out.o
 obj-y					+= clk-super.o
 
-obj-$(CONFIG_ARCH_TEGRA_2x_SOC)         += clk-tegra20.o
-obj-$(CONFIG_ARCH_TEGRA_3x_SOC)         += clk-tegra30.o
-obj-$(CONFIG_ARCH_TEGRA_114_SOC)	+= clk-tegra114.o
+obj-$(CONFIG_CLK_TEGRA20)		+= clk-tegra20.o
+obj-$(CONFIG_CLK_TEGRA30)		+= clk-tegra30.o
+obj-$(CONFIG_CLK_TEGRA114)		+= clk-tegra114.o
diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 197074a..87520c6 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -744,7 +744,7 @@ const struct clk_ops tegra_clk_plle_ops = {
 	.enable = clk_plle_enable,
 };
 
-#ifdef CONFIG_ARCH_TEGRA_114_SOC
+#ifdef CONFIG_CLK_TEGRA114
 
 static int _pll_fixed_mdiv(struct tegra_clk_pll_params *pll_params,
 			   unsigned long parent_rate)
@@ -1339,7 +1339,7 @@ struct clk *tegra_clk_register_plle(const char *name, const char *parent_name,
 	return clk;
 }
 
-#ifdef CONFIG_ARCH_TEGRA_114_SOC
+#ifdef CONFIG_CLK_TEGRA114
 const struct clk_ops tegra_clk_pllxc_ops = {
 	.is_enabled = clk_pll_is_enabled,
 	.enable = clk_pll_iddq_enable,
-- 
1.8.1.5



From swarren at wwwdotorg.org  Tue Jul 16 18:34:37 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 16:34:37 -0600
Subject: [PATCH] pinctrl: tegra: expose config options for individual SoCs
Message-ID: <1374014077-22536-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

I'm planning to remove CONFIG_ARCH_TEGRA_*_SOC, leaving just ARCH_TEGRA.
This will reduce the number of configurations that need to be supported
by core Tegra code, e.g. CPU idle, hotplug. As a precursor, we need to
update Kconfig for all Tegra drivers not to reference ARCH_TEGRA_*_SOC.

The Tegra pinctrl driver contains a fairly large amount of SoC-specific
code and data. Introduce explicit config options so that the user can
trim the set of supported SoCs if they wish. Default these to on, since
most people will probably want to enable support for all SoCs. This also
avoids the need to change any defconfig files.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 drivers/pinctrl/Kconfig | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 5a8ad51..25a56b5 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -207,15 +207,21 @@ config PINCTRL_TEGRA
 	select PINCONF
 
 config PINCTRL_TEGRA20
-	bool
+	bool "NVIDIA Tegra20 pin control driver"
+	depends on ARCH_TEGRA
+	default y
 	select PINCTRL_TEGRA
 
 config PINCTRL_TEGRA30
-	bool
+	bool "NVIDIA Tegra30 pin control driver"
+	depends on ARCH_TEGRA
+	default y
 	select PINCTRL_TEGRA
 
 config PINCTRL_TEGRA114
-	bool
+	bool "NVIDIA Tegra114 pin control driver"
+	depends on ARCH_TEGRA
+	default y
 	select PINCTRL_TEGRA
 
 config PINCTRL_TZ1090
-- 
1.8.1.5



From swarren at wwwdotorg.org  Tue Jul 16 18:36:20 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 16:36:20 -0600
Subject: [PATCH 1/2] ARM: tegra: remove CONFIG_ARCH_TEGRA_*_SOC
Message-ID: <1374014181-22605-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

These kconfig symbols are no longer used, so delete them.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
These will need to be applied after all the various subsystems have
merged the other patches I sent related to ARCH_TEGRA_*_SOC, and those
subsystem trees have all been merged together. So, after v3.12-rc1 some
time.

 arch/arm/mach-tegra/Kconfig | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 94713e4..b1fabe6 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -3,9 +3,6 @@ config ARCH_TEGRA
 	select ARCH_HAS_CPUFREQ
 	select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
 	select ARCH_REQUIRE_GPIOLIB
-	select ARCH_TEGRA_2x_SOC
-	select ARCH_TEGRA_3x_SOC
-	select ARCH_TEGRA_114_SOC
 	select ARM_ERRATA_720789
 	select ARM_ERRATA_754322
 	select ARM_ERRATA_754327 if SMP
@@ -43,15 +40,6 @@ config ARCH_TEGRA
 menu "NVIDIA Tegra options"
 	depends on ARCH_TEGRA
 
-config ARCH_TEGRA_2x_SOC
-	bool
-
-config ARCH_TEGRA_3x_SOC
-	bool
-
-config ARCH_TEGRA_114_SOC
-	bool
-
 config TEGRA_PCI
 	bool "PCI Express support"
 	depends on ARCH_TEGRA
-- 
1.8.1.5



From swarren at wwwdotorg.org  Tue Jul 16 18:36:21 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 16:36:21 -0600
Subject: [PATCH 2/2] ARM: tegra: don't select all pinctrl drivers
In-Reply-To: <1374014181-22605-1-git-send-email-swarren@wwwdotorg.org>
References: <1374014181-22605-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1374014181-22605-2-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

The Tegra pinctrl drivers now have their own user-visible config options.
Don't select all of these when ARCH_TEGRA is enabled; that prevents the
user from selectively disabling pinctrl drivers for SoCs that they don't
care about.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/mach-tegra/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index b1fabe6..6715621 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -23,9 +23,6 @@ config ARCH_TEGRA
 	select HAVE_SMP
 	select MIGHT_HAVE_CACHE_L2X0
 	select PINCTRL
-	select PINCTRL_TEGRA114
-	select PINCTRL_TEGRA20
-	select PINCTRL_TEGRA30
 	select PL310_ERRATA_727915 if CACHE_L2X0
 	select PL310_ERRATA_769419 if CACHE_L2X0
 	select SOC_BUS
-- 
1.8.1.5



From swarren at wwwdotorg.org  Tue Jul 16 18:57:03 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 16:57:03 -0600
Subject: [PATCH v2 01/22] [HACK] of: dev_node has struct device pointer
In-Reply-To: <1373021097-32420-2-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-2-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E5CFBF.5080407@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> To prevent of_platform_populate() from trying to populate duplicate
> devices if a device has been already populated.

You need to send drivers/of patches to the DT maintainer and
devicetree-discuss mailing list.

> Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
> ---
> Need to take care of early_platform_devices, or alternative solution.

I assume that's a TODO item... Are you planning on fleshing out this
patch to address that issue?

> diff --git a/drivers/of/base.c b/drivers/of/base.c

> +struct device *of_get_device(const struct device_node *node)
> +{
> +	struct device *dev;
> +	unsigned long flags;
> +
> +	raw_spin_lock_irqsave(&devtree_lock, flags);
> +	dev = node->dev;
> +	raw_spin_unlock_irqrestore(&devtree_lock, flags);

The read (and write in of_set_device()) aren't atomic already? I guess
perhaps they aren't necessarily. It sure seems like some higher-level
locking is needed in of_platform_create_pdata() though, since there's
quite a window there between the get() and set() calls. Or, is there
already some locking in place above that, in which case, I 'm not sure
why there's a need for this level of locking here...

> diff --git a/drivers/of/platform.c b/drivers/of/platform.c

> +	tmp = of_get_device(np);
> +	if (tmp) {
> +		dev_info(tmp, "Already populated\n");
> +		return to_platform_device(tmp);
> +	}

Did you check all callers of this function to make sure that they also
don't do any kind of double-processing?


> diff --git a/include/linux/of.h b/include/linux/of.h

> @@ -60,6 +60,9 @@ struct device_node {
>  	struct	kref kref;
>  	unsigned long _flags;
>  	void	*data;
> +
> +	struct device *dev;		/* Set only after populated */
> +
>  #if defined(CONFIG_SPARC)

Are the extra blank lines needed?


From swarren at wwwdotorg.org  Tue Jul 16 19:03:31 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 17:03:31 -0600
Subject: [PATCH v2 02/22] ARM: tegra: Populate AHB/IOMMU earlier than
 others
In-Reply-To: <1373021097-32420-3-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-3-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E5D143.3000602@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> Populate AHB/IOMMU earlier than others. IOMMU depends on AHB. IOMMU
> needs to be instanciated earlier than others so that IOMMU can
> register other platform devices as IOMMU'able. Once IOMMU is
> populated, IOMMU/AHB nodes are detached to prevent another
> registeration.

Hmmm. I'm still in two minds about this. If just the IOMMU was needed,
then this wouldn't be too bad. But then there's the dependency on the
AHB device too. And in general, there could be, say, a dependency on a
SoC power-controller, clock controller, reset module, etc. This could
become a huge slippery slope.

Modelling the IOMMU as an explicit bus with the bus-master-capable
devices underneath it would make everything work automatically...

> diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c

> +static void tegra_of_platform_populate_iommu(void)
> +{
> +	int i;
> +	struct platform_device *pdev;
> +	const char * const path[] = {"/ahb", "/iommu", };
> +
> +	for (i = 0; i < ARRAY_SIZE(path); i++) {
> +		struct device_node *np;
> +
> +		np  = of_find_node_by_path(path[i]);

I think this should at least look up the nodes by compatible value. See
how e.g. mach-tegra/pmc.c finds the right DT node.


From swarren at wwwdotorg.org  Tue Jul 16 19:07:12 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 17:07:12 -0600
Subject: [PATCH v2 03/22] ARM: tegra: Create a DT header defining swgroups
 ID
In-Reply-To: <1373021097-32420-4-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-4-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E5D220.1070708@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> Create a header file to define the swgroup IDs used by the IOMMU(SMMU)
> binding. "swgroup" is a group of H/W clients in Tegra SoC from S/W POV.
> 
> This will allow the same header to be used by both device tree files,
> and drivers implementing this binding, which guarantees that the two
> stay in sync. This also makes device trees more readable by using names
> instead of magic numbers.

Why does the driver need these constants; shouldn't it simply support
0..n SW group IDs that all work the same way? Or, is there some reason
for it to know the identities?

> diff --git a/include/dt-bindings/memory/tegra-swgroup.h b/include/dt-bindings/memory/tegra-swgroup.h

s/memory/iommu/?

s/tegra-swgroup.h/tegra-smmu.h/?

> +#define TEGRA_SWGROUP_AFI 0

Should this file document which values are valid for which SoCs? Should
there be separate files for each SoC; I don't know if it's guaranteed
that IDs won't be re-assigned between different SoCs.

> +#define TEGRA_SWGROUP_BIT(x)	(1ULL << TEGRA_SWGROUP_##x)
> +
> +#define TEGRA30_SWGROUP_ALL	<0x00000000 0x000779ff>
> +#define TEGRA114_SWGROUP_ALL	<0x00000000 0x01b659fe>

Are those 3 values needed by DT files, or just the driver?


From f.fainelli at gmail.com  Tue Jul 16 19:08:30 2013
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Wed, 17 Jul 2013 00:08:30 +0100
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with
 ARM CPU
In-Reply-To: <20130716151435.GB3871@linaro.org>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org>
Message-ID: <2043662.BcW19XTTMG@lenovo>

Hello,

Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :
> > +	compatible = "brcm,bcm5301x";
> 
> Ok, this was nagging at me before I went on my very long vacation. I see
> the "brcm" vendor prefix as a real consistency problem. I noticed on the
> bcm281xx/kona family, we have been using "bcm" which is not logged in
> vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
> already established use of "brcm" before any of the bcm281xx support
> came in. Ideally, the vendor prefix should change to "bcm" since every
> reference in the family names is BCM. However, if others want the least
> amount of churn in making this consistent, we might have to go with
> "brcm" across the board.

I would like to keep "brcm" here because that is what has been defined as a 
vendor prefix, and is used beyond the scope of the ARM Linux kernel support 
even within Broadcom. Maybe it was an oversight, or rather a mistake to let 
the bcm281x/kona family support code be merged and use "bcm" there, without 
registering it. Besides, a simple rule of number here wins:

git grep "brcm," * | wc -l
63
git grep "bcm," * | wc -l
25

(as of Linux 3.11-rc1)

So consistency we should get the bcm281x/kona DT bindings to rename their 
vendor prefix as well.
-- 
Florian


From swarren at wwwdotorg.org  Tue Jul 16 19:10:32 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 17:10:32 -0600
Subject: [PATCH v2 04/22] ARM: dt: tegra30: iommu: Add "nvidia,swgroup"
In-Reply-To: <1373021097-32420-5-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-5-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E5D2E8.5060200@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> This is a bitmap that indicates which HardWare Accelerators(HWA) are
> supported on Tegra30 SoC.

> diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi

> +		nvidia,swgroup = TEGRA30_SWGROUP_ALL;

That property isn't in the binding document. We can't add properties
that aren't documented.

Macros should not include structural syntax; the < > around the cell
value is part of the macro the way you've written it, but shouldn't be.
It'd be simpler to just write:

	nvidia,swgroup = <0x00000000 0x000779ff>;

We should only extend the binding in a backwards-compatible fashion, so
we can't require that DTs contain this value. At least, there should be
a default value defined for when the property doesn't exist.


From swarren at wwwdotorg.org  Tue Jul 16 19:14:33 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 17:14:33 -0600
Subject: [PATCH v2 05/22] ARM: dt: tegra30: iommu: Add "nvidia,
 memory-client"
In-Reply-To: <1373021097-32420-6-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-6-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E5D3D9.2090608@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> Add "nvidia,memory-client" to identify which swgroup ID a device
> belongs to.

This property also isn't in the documentation.

Again, if client devices are required to have this new property, the DT
isn't backwards-compatible; fail:-(

> diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi

> +		nvidia,memory-client = <TEGRA_SWGROUP_HC>;

What if there's more than one SMMU in the system, e.g. since there are
multiple different master-capable buses? Including the SMMU phandle in
the property seems like a good idea so that the SMMU driver knows which
devices are affected by it (although a bus structure with affected
devices under the SMMU represented as nodes under the SMMU DT node seems
a slightly more direct way of representing that, although that solution
does only support systems where bus-master transactions flow up the bus
structure in the same way that CPU transactions flow down it).

What about:

nvidia,smmu = <&smmu TEGRA_SWGROUP_HC>;

?

> @@ -69,6 +75,8 @@
>  			reg = <0x54180000 0x00040000>;
>  			clocks = <&tegra_car 24 &tegra_car 98>;
>  			clock-names = "3d", "3d2";
> +			nvidia,memory-client = <TEGRA_SWGROUP_NV
> +						TEGRA_SWGROUP_NV2>;

Oh, if there can be more than one, I suggest adding "s" to the end of
the property name.


From thierry.reding at gmail.com  Tue Jul 16 19:16:30 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 16 Jul 2013 16:16:30 -0700
Subject: [PATCH v2 01/22] [HACK] of: dev_node has struct device pointer
In-Reply-To: <51E5CFBF.5080407@wwwdotorg.org>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-2-git-send-email-hdoyu@nvidia.com>
 <51E5CFBF.5080407@wwwdotorg.org>
Message-ID: <20130716231629.GA12189@dhcp-172-17-186-34.nvidia.com>

On Tue, Jul 16, 2013 at 04:57:03PM -0600, Stephen Warren wrote:
> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> > To prevent of_platform_populate() from trying to populate duplicate
> > devices if a device has been already populated.
> 
> You need to send drivers/of patches to the DT maintainer and
> devicetree-discuss mailing list.
> 
> > Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
> > ---
> > Need to take care of early_platform_devices, or alternative solution.
> 
> I assume that's a TODO item... Are you planning on fleshing out this
> patch to address that issue?

There was some more discussion about it, which can be found in the
following thread:

	https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036934.html

That's one of the last messages and it should have most of the
background. If not you may have to walk up the thread for more context.
In a nutshell I raised the question as to why we can't simply call
of_platform_populate() earlier and side-step all the workarounds that
have found their way into the kernel to side-step the issue of their not
being a struct device associated with the struct device_node.

If of_platform_populate() can be made to run early, then we can restore
a whole lot of consistency in how "early" drivers on an OF kernel work.

Thierry
-------------- 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/20130716/db0a8b7f/attachment.sig>

From swarren at wwwdotorg.org  Tue Jul 16 19:18:29 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 17:18:29 -0600
Subject: [PATCH v2 06/22] ARM: dt: tegra114: iommu: Fix IOMMU register
 address
In-Reply-To: <1373021097-32420-7-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-7-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E5D4C5.4090109@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> Fix IOMMU register address.

Oh dear, how serious is this?

That incorrect node got added in v3.9 - a long time ago. Does the SMMU
driver touch registers during probe() or under any other condition right
now? If so, can that hang the CPU or end up trashing some other HW
module's registers?

I'm trying to determine whether we need to urgently send this patch as a
fix Cc: stable.


From linux at arm.linux.org.uk  Tue Jul 16 19:19:34 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 00:19:34 +0100
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <20130716172023.64337690@skate>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716172023.64337690@skate>
Message-ID: <20130716231934.GH24642@n2100.arm.linux.org.uk>

On Tue, Jul 16, 2013 at 05:20:23PM +0200, Thomas Petazzoni wrote:
> Dear Hauke Mehrtens,
> 
> On Tue, 16 Jul 2013 15:52:07 +0200, Hauke Mehrtens wrote:
> > +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
> > +				 struct pt_regs *regs)
> > +{
> > +	/*
> > +	 * These happen for no good reason
> > +	 * possibly left over from CFE
> 
> CFE ?
> 
> > +	 */
> > +	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
> > +		addr, fsr);
> > +
> > +	/* Returning non-zero causes fault display and panic */
> > +	return 0;
> > +}
> > +
> > +static void bcm53xx_aborts_enable(void)
> > +{
> > +	/* Install our hook */
> > +	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
> > +			"imprecise external abort");
> > +}
> > +
> > +static void __init bcm53xx_timer_init(void)
> > +{
> > +	of_clk_init(NULL);
> > +	clocksource_of_init();
> > +}
> > +
> > +void __init bcm53xx_map_io(void)
> > +{
> > +	debug_ll_io_init();
> > +	bcm53xx_aborts_enable();
> > +}
> 
> That's a nitpick, but I personally tend to like when callbacks are
> ordered as they are called, i.e ->map_io() first, and then
> ->init_time().

A more important nitpick is... it would be better to have the call to
the aborts enable function in the init_early() callback, not the map_io()
callback.  Too often people overload stuff into these specific callbacks
which makes maintanence of non-platform code pain in the butt.

The init_early() callback was specifically added by me to remove this
kind of crappage of map_io().  Please use it.  Thanks.


From swarren at wwwdotorg.org  Tue Jul 16 19:20:04 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 17:20:04 -0600
Subject: [PATCH v2 09/22] amba: Move AHB to core_initcall
In-Reply-To: <1373021097-32420-10-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-10-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E5D524.1000903@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> Move AHB to core_initcall in order to instanciate this device earlier
> than others since IOMMU depends on AHB and then IOMMU driver needs to
> reigster other platform devices as IOMMU'able.

Oh dear, this really is looking like we shouldn't be playing games by
attempting to force the initialization order. An explicit bus structure
and/or having client devices go and attach to the SMMU, would mean we
didn't have to play games like this:-(


From swarren at wwwdotorg.org  Tue Jul 16 19:21:58 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 17:21:58 -0600
Subject: [PATCH v2 10/22] iommu/tegra: smmu: Move IOMMU to core_initcall
In-Reply-To: <1373021097-32420-11-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-11-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E5D596.3030002@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> Move IOMMU to core_initcall in order to instanciate this device earlier
> than others since IOMMU driver needs to reigster other platform
> devices as IOMMU'able.

If both the AHB and SMMU driver are core_initcall, there's no guarantee
at all re: which order they'll get probed in. Deferred probe won't help
here, since I don't think it's guaranteed to be repeated, so if the
probe order is:

1) SMMU (fails since AHB isn't available)
2) AHB

... then the SMMU might not get probed until /much/ later; probably
after devices that are affected by the SMMU are probed.

However, it all works out if the probe order just accidentally happens
to be:

1) AHB
2) SMMU.

So, this really doesn't look like a viable solution.


From linux at arm.linux.org.uk  Tue Jul 16 19:22:34 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 00:22:34 +0100
Subject: [PATCH V3] ARM: mm: restrict early_alloc to section-aligned memory
In-Reply-To: <51E5C541.4080800@wwwdotorg.org>
References: <1373481831-31459-1-git-send-email-swarren@wwwdotorg.org>
 <51E5C541.4080800@wwwdotorg.org>
Message-ID: <20130716232234.GI24642@n2100.arm.linux.org.uk>

On Tue, Jul 16, 2013 at 04:12:17PM -0600, Stephen Warren wrote:
> On 07/10/2013 12:43 PM, Stephen Warren wrote:
> > From: Russell King <rmk at arm.linux.org.uk>
> > 
> > When map_lowmem() runs, and processes a memory bank whose start or end
> > is not section-aligned, memory must be allocated to store the 2nd-level
> > page tables. Those allocations are made by calling memblock_alloc().
> > 
> > At this point, the only memory that is free *and* mapped is memory which
> > has already been mapped by map_lowmem() itself. For this reason, we must
> > calculate the first point at which map_lowmem() will need to allocate
> > memory, and set the memblock allocation limit to a lower address, so that
> > memblock_alloc() is guaranteed to return memory that is already mapped.
> > 
> > This patch enhances sanity_check_meminfo() to calculate that memory
> > address, and pass it to memblock_set_current_limit(), rather than just
> > assuming the limit is arm_lowmem_limit.
> > 
> > The algorithm applied is:
> > 
> > * Default memblock_limit to arm_lowmem_limit in the absence of any other
> >   limit; arm_lowmem_limit is the highest memory that is mapped by
> >   map_lowmem().
> > 
> > * While walking the list of memblocks, if the start of a block is not
> >   aligned, 2nd-level page tables will need to be allocated to map the
> >   first few pages of the block. Hence, the memblock_limit must be before
> >   the start of the block.
> > 
> > * Similarly, if the end of any block is not aligned, 2nd-level page
> >   tables will need to be allocated to map the last few pages of the
> >   block. Hence, the memblock_limit must point at the end of the block,
> >   rounded down to section-alignment.
> > 
> > * The memory blocks are assumed to be sorted in address order, so the
> >   first unaligned block start or end is used to set the limit.
> > 
> > With this algorithm, the start or end of almost any bank can be non-
> > section-aligned. The only exception is that the start of bank 0 must
> > be section-aligned, since otherwise memory would need to be allocated
> > when mapping the start of bank 0, which occurs before any free memory
> > is mapped.
> > 
> > Not-yet-signed-off-by: Russell King <rmk at arm.linux.org.uk>
> > [swarren, wrote commit description, rewrote calculation of memblock_limit]
> > Signed-off-by: Stephen Warren <swarren at nvidia.com>
> > ---
> > V3: completely new implementation based on Russell's suggestion.
> > 
> > Russell, since this is strongly based on your patch, I set you as the
> > author in git. I assume that's OK. If not, let me know and I'll change
> > the patch to my authorship and add a note to the commit description
> > that it's based on your original.
> 
> Russell, should I assume that no comment implies this is OK and I should
> send it to the ARM patch tracker?

Sure, I think it's fine - it should result in no change for most people.


From thierry.reding at gmail.com  Tue Jul 16 19:27:09 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 16 Jul 2013 16:27:09 -0700
Subject: [PATCH v2 06/22] ARM: dt: tegra114: iommu: Fix IOMMU register
 address
In-Reply-To: <51E5D4C5.4090109@wwwdotorg.org>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-7-git-send-email-hdoyu@nvidia.com>
 <51E5D4C5.4090109@wwwdotorg.org>
Message-ID: <20130716232708.GB12189@dhcp-172-17-186-34.nvidia.com>

On Tue, Jul 16, 2013 at 05:18:29PM -0600, Stephen Warren wrote:
> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> > Fix IOMMU register address.
> 
> Oh dear, how serious is this?
> 
> That incorrect node got added in v3.9 - a long time ago. Does the SMMU
> driver touch registers during probe() or under any other condition right
> now? If so, can that hang the CPU or end up trashing some other HW
> module's registers?
> 
> I'm trying to determine whether we need to urgently send this patch as a
> fix Cc: stable.

Judging by the TRM there's nothing in the range from 0x7000ec00 to
0x7000f7ff, so hopefully we got lucky.

Thierry
-------------- 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/20130716/346a833a/attachment.sig>

From mgreer at animalcreek.com  Tue Jul 16 19:29:26 2013
From: mgreer at animalcreek.com (Mark A. Greer)
Date: Tue, 16 Jul 2013 16:29:26 -0700
Subject: [PATCH 0/2] ARM: dts: Add SHAM and AES DT information
Message-ID: <1374017368-5267-1-git-send-email-mgreer@animalcreek.com>

From: "Mark A. Greer" <mgreer at animalcreek.com>

Long overdue patches to add the device tree updates and
documentation for the SHAM and AES modules on the am33xx.
The supporting code is already in the mainline kernel.

Mark A. Greer (2):
  ARM: dts: Add SHAM data and documentation for AM33XX
  ARM: dts: Add AES data and documentation for AM33XX

 .../devicetree/bindings/crypto/omap-aes.txt        | 35 ++++++++++++++++++++++
 .../devicetree/bindings/crypto/omap-sham.txt       | 33 ++++++++++++++++++++
 arch/arm/boot/dts/am335x-bone.dts                  |  8 +++++
 arch/arm/boot/dts/am335x-evm.dts                   |  8 +++++
 arch/arm/boot/dts/am335x-evmsk.dts                 |  7 +++++
 arch/arm/boot/dts/am33xx.dtsi                      | 20 +++++++++++++
 6 files changed, 111 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/omap-aes.txt
 create mode 100644 Documentation/devicetree/bindings/crypto/omap-sham.txt

-- 
1.7.12



From mgreer at animalcreek.com  Tue Jul 16 19:29:27 2013
From: mgreer at animalcreek.com (Mark A. Greer)
Date: Tue, 16 Jul 2013 16:29:27 -0700
Subject: [PATCH 1/2] ARM: dts: Add SHAM data and documentation for AM33XX
In-Reply-To: <1374017368-5267-1-git-send-email-mgreer@animalcreek.com>
References: <1374017368-5267-1-git-send-email-mgreer@animalcreek.com>
Message-ID: <1374017368-5267-2-git-send-email-mgreer@animalcreek.com>

From: "Mark A. Greer" <mgreer at animalcreek.com>

Add the generic AM33XX SHAM module's device tree data and
enable it for the am335x-evm, am335x-evmsk, and am335x-bone
platforms.  Also add Documentation file describing the data
for the SHAM module.

CC: Paul Walmsley <paul at pwsan.com>
Signed-off-by: Mark A. Greer <mgreer at animalcreek.com>
---
 .../devicetree/bindings/crypto/omap-sham.txt       | 33 ++++++++++++++++++++++
 arch/arm/boot/dts/am335x-bone.dts                  |  4 +++
 arch/arm/boot/dts/am335x-evm.dts                   |  4 +++
 arch/arm/boot/dts/am335x-evmsk.dts                 |  3 ++
 arch/arm/boot/dts/am33xx.dtsi                      |  9 ++++++
 5 files changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/omap-sham.txt

diff --git a/Documentation/devicetree/bindings/crypto/omap-sham.txt b/Documentation/devicetree/bindings/crypto/omap-sham.txt
new file mode 100644
index 0000000..c6d1202
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/omap-sham.txt
@@ -0,0 +1,33 @@
+OMAP SoC SHA crypto Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+  SHAM versions:
+  - "ti,omap2-sham" for OMAP2 & OMAP3.
+  - "ti,omap4-sham" for OMAP4 and AM33XX.
+  Note that these two versions are incompatible.
+- ti,hwmods: Name of the hwmod associated with the SHAM module
+- reg : Offset and length of the register set for the module
+- interrupt-parent : the phandle for the interrupt controller that
+  services interrupts for this module.
+- interrupts : the interrupt number for the SHAM module.
+
+Optional properties:
+- dmas: DMA controller phandle and DMA request ordered pair.
+	Only one rx pair is valid per SHAM module.
+- dma-names: DMA request name. This string corresponds 1:1 with
+	the ordered pair in dmas. The string naming is to be
+	"rx" for RX request.
+
+Example:
+	/* AM335x */
+	sham: sham at 53100000 {
+		compatible = "ti,omap4-sham";
+		ti,hwmods = "sham";
+		reg = <0x53100000 0x200>;
+		interrupt-parent = <&intc>;
+		interrupts = <109>;
+		dmas = <&edma 36>;
+		dma-names = "rx";
+	};
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 444b4ed..bc75b2c 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -234,3 +234,7 @@
 	pinctrl-0 = <&davinci_mdio_default>;
 	pinctrl-1 = <&davinci_mdio_sleep>;
 };
+
+&sham {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 3aee1a4..9b8c56d 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -488,3 +488,7 @@
 		ti,adc-channels = <4 5 6 7>;
 	};
 };
+
+&sham {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 0c8ad17..b04aea1 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -401,4 +401,7 @@
 &cpsw_emac1 {
 	phy_id = <&davinci_mdio>, <1>;
 	phy-mode = "rgmii-txid";
+
+&sham {
+	status = "okay";
 };
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..eb0e719 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -529,6 +529,15 @@
 			#address-cells = <2>;
 			#size-cells = <1>;
 			status = "disabled";
+
+		sham: sham at 53100000 {
+			compatible = "ti,omap4-sham";
+			ti,hwmods = "sham";
+			reg = <0x53100000 0x200>;
+			interrupt-parent = <&intc>;
+			interrupts = <109>;
+			dmas = <&edma 36>;
+			dma-names = "rx";
 		};
 	};
 };
-- 
1.7.12



From mgreer at animalcreek.com  Tue Jul 16 19:29:28 2013
From: mgreer at animalcreek.com (Mark A. Greer)
Date: Tue, 16 Jul 2013 16:29:28 -0700
Subject: [PATCH 2/2] ARM: dts: Add AES data and documentation for AM33XX
In-Reply-To: <1374017368-5267-1-git-send-email-mgreer@animalcreek.com>
References: <1374017368-5267-1-git-send-email-mgreer@animalcreek.com>
Message-ID: <1374017368-5267-3-git-send-email-mgreer@animalcreek.com>

From: "Mark A. Greer" <mgreer at animalcreek.com>

Add the generic AM33XX AES module's device tree data and
enable it for the am335x-evm, am335x-evmsk, and am335x-bone
platforms.  Also add Documentation file describing the data
for the AES module.

CC: Paul Walmsley <paul at pwsan.com>
Signed-off-by: Mark A. Greer <mgreer at animalcreek.com>
---
 .../devicetree/bindings/crypto/omap-aes.txt        | 35 ++++++++++++++++++++++
 arch/arm/boot/dts/am335x-bone.dts                  |  4 +++
 arch/arm/boot/dts/am335x-evm.dts                   |  4 +++
 arch/arm/boot/dts/am335x-evmsk.dts                 |  4 +++
 arch/arm/boot/dts/am33xx.dtsi                      | 11 +++++++
 5 files changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/omap-aes.txt

diff --git a/Documentation/devicetree/bindings/crypto/omap-aes.txt b/Documentation/devicetree/bindings/crypto/omap-aes.txt
new file mode 100644
index 0000000..b51d12f
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/omap-aes.txt
@@ -0,0 +1,35 @@
+OMAP SoC AES crypto Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+  AES versions:
+  - "ti,omap2-aes" for OMAP2.
+  - "ti,omap3-aes" for OMAP3.
+  - "ti,omap4-aes" for OMAP4 and AM33XX.
+  Note that the OMAP2 and 3 versions are compatible (OMAP3 supports
+  more algorithms) but they are incompatible with OMAP4.
+- ti,hwmods: Name of the hwmod associated with the AES odule
+- reg : Offset and length of the register set for the module
+- interrupt-parent : the phandle for the interrupt controller that
+  services interrupts for this module.
+- interrupts : the interrupt number for the AES odule.
+
+Optional properties:
+- dmas: DMA controller phandle and DMA request ordered pairs.
+- dma-names: DMA request names. This string corresponds 1:1 with
+	the ordered pairs in dmas. The string naming is to be
+	"tx" for TX request and "rx" for RX request.
+
+Example:
+	/* AM335x */
+	aes: aes at 53500000 {
+		compatible = "ti,omap4-aes";
+		ti,hwmods = "aes";
+		reg = <0x53500000 0xa0>;
+		interrupt-parent = <&intc>;
+		interrupts = <102>;
+		dmas = <&edma 6
+			&edma 5>;
+		dma-names = "tx", "rx";
+	};
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index bc75b2c..0cb454e 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -238,3 +238,7 @@
 &sham {
 	status = "okay";
 };
+
+&aes {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 9b8c56d..76ba004 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -492,3 +492,7 @@
 &sham {
 	status = "okay";
 };
+
+&aes {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index b04aea1..483d263 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -405,3 +405,7 @@
 &sham {
 	status = "okay";
 };
+
+&aes {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index eb0e719..b20265a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -539,5 +539,16 @@
 			dmas = <&edma 36>;
 			dma-names = "rx";
 		};
+
+		aes: aes at 53500000 {
+			compatible = "ti,omap4-aes";
+			ti,hwmods = "aes";
+			reg = <0x53500000 0xa0>;
+			interrupt-parent = <&intc>;
+			interrupts = <102>;
+			dmas = <&edma 6
+				&edma 5>;
+			dma-names = "tx", "rx";
+		};
 	};
 };
-- 
1.7.12



From swarren at wwwdotorg.org  Tue Jul 16 19:30:23 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 17:30:23 -0600
Subject: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property
In-Reply-To: <51E47F85.4050905@wwwdotorg.org>
References: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
 <1373913629-32179-5-git-send-email-swarren@wwwdotorg.org>
 <51E44ED9.9020807@gmail.com> <51E47F85.4050905@wwwdotorg.org>
Message-ID: <51E5D78F.8060400@wwwdotorg.org>

On 07/15/2013 05:02 PM, Stephen Warren wrote:
> On 07/15/2013 01:34 PM, Rob Herring wrote:
>> On 07/15/2013 01:40 PM, Stephen Warren wrote:
>>> From: Stephen Warren <swarren at nvidia.com>
>>>
>>> This property is no longer required by the GPIO binding. Remove it.
>>
>> Won't this break compatibility with older kernel? It is one thing to
>> deprecate, but removal is another. If the relevant maintainers don't
>> care, then I guess it is fine.
> 
> Yes.
> 
> I had originally hoped this could sneak in late for 3.11, but I suppose
> it's too late now. vf610.dtsi is a new file in 3.11 so has no legacy to
> protect.
> 
> Admittedly, the #gpio-cells property was added into the SPEAr files in 3.10.

One more thought here:

I know DT bindings are supposed to evolve so that a new kernel will
support arbitrary old DTs. I'll call that backwards-compatibility for
the DT parsing code.

However, this situation is the reverse; this patch would prevent a new
DT running on an older kernel. I'll call that forwards-compatibility.
I'm not sure if the intent is to support this or not? It's certainly the
first I explicitly thought about compatibility in this direction...


From nicolas.pitre at linaro.org  Tue Jul 16 19:32:48 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 16 Jul 2013 19:32:48 -0400 (EDT)
Subject: [RFC PATCH v5 1/1] drivers: mfd: vexpress: add Serial Power
 Controller (SPC) support
In-Reply-To: <51E5A785.1040805@gmail.com>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1373990743-23106-2-git-send-email-lorenzo.pieralisi@arm.com>
 <51E5A785.1040805@gmail.com>
Message-ID: <alpine.LFD.2.03.1307161917580.14924@syhkavp.arg>

On Tue, 16 Jul 2013, Rob Herring wrote:

> On 07/16/2013 11:05 AM, Lorenzo Pieralisi wrote:
> > The TC2 versatile express core tile integrates a logic block that provides the
> > interface between the dual cluster test-chip and the M3 microcontroller that
> > carries out power management. The logic block, called Serial Power Controller
> > (SPC), contains several memory mapped registers to control among other things
> > low-power states, wake-up irqs and per-CPU jump addresses registers.
> > 
> > This patch provides a driver that enables run-time control of features
> > implemented by the SPC power management control logic.
> > 
> > The SPC control logic is required to be programmed very early in the boot
> > process to reset secondary CPUs on the TC2 testchip, set-up jump addresses and
> > wake-up IRQs for power management. Hence, waiting for core changes to be
> > made in the device core code to enable early registration of platform
> > devices, the driver puts in place an early init scheme that allows kernel
> > drivers to initialize the SPC driver directly from the components requiring
> > it, if their initialization routine is called before the driver init
> > function by the boot process.
> > 
> > Device tree bindings documentation for the SPC component is provided with
> > the patchset.
> 
> Just curious, wouldn't a TC2 PSCI implementation eliminate the need for
> most/all of this code?

There is a PSCI equivalent for the above already, in the sense that 
there is a simple MCPM backend that bypass most of the MCPM race 
avoidance code paths and simply calls into PSCI instead.  But not all 
the world is going to be PSCI, and therefore we need to ensure good 
support for non-PSCI platforms as well.

This is why TC2 supports both, and this also ensure that the PSCI 
implementation, which won't be part of the kernel and therefore unlikely 
to get the same level of scrutiny, is properly implemented and doesn't 
introduce any regression when compared to the non PSCI case.

Remember that TC2 is multi-cluster which means that the PSCI 
implementation has to carry the same amount of complexity as the whole 
in-kernel MCPM layer and that doesn't make me overly confident it is 
going to always be right.

All this to say that we do need this code despite PSCI availability.


Nicolas


From hartleys at visionengravers.com  Tue Jul 16 19:36:19 2013
From: hartleys at visionengravers.com (H Hartley Sweeten)
Date: Tue, 16 Jul 2013 18:36:19 -0500
Subject: [PATCH RFC v2 0/14] Clean up debugging support
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <ADE657CA350FB648AAC2C43247A983F0021DAC4AB4FC@AUSP01VMBX24.collaborationhost.net>

On Tuesday, July 16, 2013 9:33 AM, Russell King wrote:
> This is the second posting of this series, with a few additional patches
> on top to go a little further.  Changes since the last posting:

<snip>

Boot tested on ep93xx. For the ep93xx parts:

Acked-by: H Hartley Sweeten <hsweeten at visionengravers.com>



From matt.porter at linaro.org  Tue Jul 16 19:42:10 2013
From: matt.porter at linaro.org (Matt Porter)
Date: Tue, 16 Jul 2013 19:42:10 -0400
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <2043662.BcW19XTTMG@lenovo>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
Message-ID: <20130716234209.GC3871@linaro.org>

On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote:
> Hello,
> 
> Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :
> > > +	compatible = "brcm,bcm5301x";
> > 
> > Ok, this was nagging at me before I went on my very long vacation. I see
> > the "brcm" vendor prefix as a real consistency problem. I noticed on the
> > bcm281xx/kona family, we have been using "bcm" which is not logged in
> > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
> > already established use of "brcm" before any of the bcm281xx support
> > came in. Ideally, the vendor prefix should change to "bcm" since every
> > reference in the family names is BCM. However, if others want the least
> > amount of churn in making this consistent, we might have to go with
> > "brcm" across the board.
> 
> I would like to keep "brcm" here because that is what has been defined as a 
> vendor prefix, and is used beyond the scope of the ARM Linux kernel support 
> even within Broadcom. Maybe it was an oversight, or rather a mistake to let 
> the bcm281x/kona family support code be merged and use "bcm" there, without 
> registering it. Besides, a simple rule of number here wins:
> 
> git grep "brcm," * | wc -l
> 63
> git grep "bcm," * | wc -l
> 25
> 
> (as of Linux 3.11-rc1)
> 
> So consistency we should get the bcm281x/kona DT bindings to rename their 
> vendor prefix as well.

Yeah, this is why I grudgingly agree that it should go bcm->brcm, brcm
was already established and bcm is only in used on this one family so far.
Even though I don't like the extra character. :)

Christian: if you don't have objections here I can generate a series to
update this across the board.

-Matt


From matt.porter at linaro.org  Tue Jul 16 19:44:57 2013
From: matt.porter at linaro.org (Matt Porter)
Date: Tue, 16 Jul 2013 19:44:57 -0400
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <51E56942.8030801@hauke-m.de>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <51E56942.8030801@hauke-m.de>
Message-ID: <20130716234456.GD3871@linaro.org>

On Tue, Jul 16, 2013 at 05:39:46PM +0200, Hauke Mehrtens wrote:
> On 07/16/2013 05:14 PM, Matt Porter wrote:
> > Hi Hauke,
> > 
> > On Tue, Jul 16, 2013 at 03:52:07PM +0200, Hauke Mehrtens wrote:
> >> This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU.
> >> Currently just booting to a shell is working and nothing else, no
> >> Ethernet, wifi, flash, ...
> >>
> >> This SoC uses a Dual core CPU, but this is currently not implemented.
> >> More information about this SoC can be found here:
> >> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers
> >>
> >> Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
> >> ---
> >>
> >> A bootlog can be found here:
> >> http://pastebin.com/0MYYC7Fx
> >>
> >>  MAINTAINERS                                  |    7 +++
> >>  arch/arm/Kconfig                             |    2 +
> >>  arch/arm/Kconfig.debug                       |    5 ++
> >>  arch/arm/Makefile                            |    1 +
> >>  arch/arm/boot/dts/Makefile                   |    1 +
> >>  arch/arm/boot/dts/bcm5301x-netgear-r6250.dts |   20 +++++++
> >>  arch/arm/boot/dts/bcm5301x.dtsi              |   72 ++++++++++++++++++++++++++
> >>  arch/arm/include/debug/bcm53xx.S             |   19 +++++++
> >>  arch/arm/mach-bcm53xx/Kconfig                |   10 ++++
> >>  arch/arm/mach-bcm53xx/Makefile               |    1 +
> >>  arch/arm/mach-bcm53xx/bcm53xx.c              |   68 ++++++++++++++++++++++++
> >>  11 files changed, 206 insertions(+)
> >>  create mode 100644 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
> >>  create mode 100644 arch/arm/boot/dts/bcm5301x.dtsi
> >>  create mode 100644 arch/arm/include/debug/bcm53xx.S
> >>  create mode 100644 arch/arm/mach-bcm53xx/Kconfig
> >>  create mode 100644 arch/arm/mach-bcm53xx/Makefile
> >>  create mode 100644 arch/arm/mach-bcm53xx/bcm53xx.c
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index bf61e04..b72ba65 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -1795,6 +1795,13 @@ F:	arch/arm/boot/dts/bcm2835*
> >>  F:	arch/arm/configs/bcm2835_defconfig
> >>  F:	drivers/*/*bcm2835*
> >>  
> >> +BROADCOM BCM53XX ARM ARCHICTURE
> >> +M:	Hauke Mehrtens <hauke at hauke-m.de>
> >> +L:	linux-arm-kernel at lists.infradead.org
> >> +S:	Maintained
> >> +F:	arch/arm/mach-bcm53xx/
> >> +F:	arch/arm/boot/dts/bcm53*
> >> +
> >>  BROADCOM TG3 GIGABIT ETHERNET DRIVER
> >>  M:	Nithin Nayak Sujir <nsujir at broadcom.com>
> >>  M:	Michael Chan <mchan at broadcom.com>
> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> index ba412e0..ee7362e 100644
> >> --- a/arch/arm/Kconfig
> >> +++ b/arch/arm/Kconfig
> >> @@ -930,6 +930,8 @@ source "arch/arm/mach-bcm/Kconfig"
> >>  
> >>  source "arch/arm/mach-bcm2835/Kconfig"
> >>  
> >> +source "arch/arm/mach-bcm53xx/Kconfig"
> >> +
> >>  source "arch/arm/mach-clps711x/Kconfig"
> >>  
> >>  source "arch/arm/mach-cns3xxx/Kconfig"
> >> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> >> index e401a76..74e32f6 100644
> >> --- a/arch/arm/Kconfig.debug
> >> +++ b/arch/arm/Kconfig.debug
> >> @@ -93,6 +93,10 @@ choice
> >>  		bool "Kernel low-level debugging on BCM2835 PL011 UART"
> >>  		depends on ARCH_BCM2835
> >>  
> >> +	config DEBUG_BCM53XX
> >> +		bool "Kernel low-level debugging on BCM53XX UART1"
> >> +		depends on ARCH_BCM53XX
> >> +
> >>  	config DEBUG_CLPS711X_UART1
> >>  		bool "Kernel low-level debugging messages via UART1"
> >>  		depends on ARCH_CLPS711X
> >> @@ -762,6 +766,7 @@ endchoice
> >>  config DEBUG_LL_INCLUDE
> >>  	string
> >>  	default "debug/bcm2835.S" if DEBUG_BCM2835
> >> +	default "debug/bcm53xx.S" if DEBUG_BCM53XX
> >>  	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
> >>  	default "debug/exynos.S" if DEBUG_EXYNOS_UART
> >>  	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
> >> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> >> index c0ac0f5..4a69cd5 100644
> >> --- a/arch/arm/Makefile
> >> +++ b/arch/arm/Makefile
> >> @@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> >>  machine-$(CONFIG_ARCH_AT91)		+= at91
> >>  machine-$(CONFIG_ARCH_BCM)		+= bcm
> >>  machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
> >> +machine-$(CONFIG_ARCH_BCM53XX)		+= bcm53xx
> >>  machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
> >>  machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
> >>  machine-$(CONFIG_ARCH_DAVINCI)		+= davinci
> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> index 641b3c9..480a68e 100644
> >> --- a/arch/arm/boot/dts/Makefile
> >> +++ b/arch/arm/boot/dts/Makefile
> >> @@ -242,6 +242,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
> >>  dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
> >>  	zynq-zc706.dtb \
> >>  	zynq-zed.dtb
> >> +dtb-$(CONFIG_ARCH_BCM53XX) += bcm5301x-netgear-r6250.dtb
> >>  
> >>  targets += dtbs
> >>  targets += $(dtb-y)
> >> diff --git a/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
> >> new file mode 100644
> >> index 0000000..d1b97aa
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
> >> @@ -0,0 +1,20 @@
> >> +/*
> >> + * Broadcom BCM47XX / BCM53XX arm platform code.
> >> + *
> >> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> >> + *
> >> + * Licensed under the GNU/GPL. See COPYING for details.
> >> + */
> >> +
> >> +/dts-v1/;
> >> +
> >> +/include/ "bcm5301x.dtsi"
> >> +
> >> +/ {
> >> +	model = "Netgear R6250 V1 (BCM4708)";
> >> +	compatible = "netgear,r6250v1", "brcm,bcm5301x";
> >> +
> >> +	memory {
> >> +		reg = <0x00000000 0x08000000>;
> >> +	};
> >> +};
> >> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
> >> new file mode 100644
> >> index 0000000..638350d
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> >> @@ -0,0 +1,72 @@
> >> +/*
> >> + * Broadcom BCM47XX / BCM53XX ARM platform code.
> >> + *
> >> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> >> + *
> >> + * Licensed under the GNU/GPL. See COPYING for details.
> >> + */
> >> +
> >> +/include/ "skeleton.dtsi"
> >> +
> >> +/ {
> >> +	compatible = "brcm,bcm5301x";
> > 
> > Ok, this was nagging at me before I went on my very long vacation. I see
> > the "brcm" vendor prefix as a real consistency problem. I noticed on the
> > bcm281xx/kona family, we have been using "bcm" which is not logged in
> > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
> > already established use of "brcm" before any of the bcm281xx support
> > came in. Ideally, the vendor prefix should change to "bcm" since every
> > reference in the family names is BCM. However, if others want the least
> > amount of churn in making this consistent, we might have to go with
> > "brcm" across the board.
> > 
> > Arnd, any thoughts here?
> 
> I have no problem with bcm or with brcm. This is a Broadcom Chip and
> their names are starting with bcm.

See Florian's quantified argument for using brcm.

> 
> > Another thing is that this is missing a binding definition for this
> > compatible string. See Documentation/devicetree/bindings/arm/bcm2835.txt
> > for an example. You should split this patch out separately as the DT
> > maintainers generally want to see bindings as a separate patch for easy
> > independent review.
> 
> Ok I will do that. This will then be merged by Linus in the 3.12 merge
> window into a working version or how does this work?

Yes, your target is the 3.12 merge window at this point.

> Currently I have based this patch on top of 3.11-rc1 on which tree
> should I base my changes?

That's good. Unless some major change comes into the arm-soc tree and
you are asked to rebase versus that.

> > Last thing, compatible strings are not to have wildcards in them. See
> > http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
> > and note the Warning at the bottom. Also see how bcm2835.txt and
> > bcm11351.txt use a specific model.
> 
> Ok will do that.
> 
> >> +	model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC";
> >> +	interrupt-parent = <&gic>;
> >> +
> >> +	chosen {
> >> +		bootargs = "console=ttyS0,115200 earlyprintk debug";
> >> +	};
> >> +
> >> +	cpus {
> >> +		#address-cells = <1>;
> >> +		#size-cells = <0>;
> >> +
> >> +		cpu at 0 {
> >> +			device_type = "cpu";
> >> +			compatible = "arm,cortex-a9";
> >> +			reg = <0>;
> >> +		};
> >> +	};
> >> +
> >> +	clocks {
> >> +		#address-cells = <1>;
> >> +		#size-cells = <0>;
> >> +
> >> +		clk_periph: periph {
> >> +			compatible = "fixed-clock";
> >> +			#clock-cells = <0>;
> >> +			clock-frequency = <400000000>;
> >> +		};
> >> +	};
> >> +
> >> +	uart at 18000300 {
> >> +		compatible = "ns16550";
> >> +		reg = <0x18000300 0x100>;
> >> +		interrupts = <0 85 4>;
> > 
> > The DT files should be switched to use the C preprocessor like several
> > other machines have already done (see bcm11351.dtsi, for example), you
> > can use the existing GIC includes and have human-redable defines for the
> > edge/level values here and throughout all interrupt properties.
> 
> Ok I will read that and change it.
> 
> >> +		clock-frequency = <100000000>;
> >> +	};
> >> +
> >> +	uart at 18000400 {
> >> +		compatible = "ns16550";
> >> +		reg = <0x18000400 0x100>;
> >> +		interrupts = <0 85 4>;
> >> +		clock-frequency = <100000000>;
> >> +	};
> >> +
> >> +	gic: interrupt-controller at 19021000 {
> >> +		compatible = "arm,cortex-a9-gic";
> >> +		#interrupt-cells = <3>;
> >> +		#address-cells = <0>;
> >> +		interrupt-controller;
> >> +		reg = <0x19021000 0x1000>,
> >> +		      <0x19020100 0x100>;
> >> +	};
> >> +
> >> +	timer at 19020200 {
> >> +		compatible = "arm,cortex-a9-global-timer";
> >> +		reg = <0x19020200 0x100>;
> >> +		interrupts = <1 11 0xf04>;
> >> +		clocks = <&clk_periph>;
> >> +		#clock-cells = <0>;
> >> +	};
> >> +};
> >> diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S
> >> new file mode 100644
> >> index 0000000..98c836b
> >> --- /dev/null
> >> +++ b/arch/arm/include/debug/bcm53xx.S
> >> @@ -0,0 +1,19 @@
> >> +/*
> >> + * Macros used for EARLY_PRINTK, in low-level UART debug console
> >> + *
> >> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> >> + *
> >> + * Licensed under the GNU/GPL. See COPYING for details.
> >> + */
> >> +
> >> +#define BCM53XX_UART1_PHYS	0x18000300
> >> +#define BCM53XX_UART1_VIRT	0xf1000300
> >> +#define BCM53XX_UART1_SH	0
> >> +
> >> +	.macro	addruart, rp, rv, tmp
> >> +	ldr	\rp, =BCM53XX_UART1_PHYS 	@ MMU off, Physical
> >> +	ldr	\rv, =BCM53XX_UART1_VIRT 	@ MMU on, Virtual
> >> +	.endm
> >> +
> >> +#define UART_SHIFT	BCM53XX_UART1_SH
> >> +#include <asm/hardware/debug-8250.S>
> >> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig
> >> new file mode 100644
> >> index 0000000..1e16e87
> >> --- /dev/null
> >> +++ b/arch/arm/mach-bcm53xx/Kconfig
> >> @@ -0,0 +1,10 @@
> >> +config ARCH_BCM53XX
> >> +	bool "Broadcom BCM47XX / BCM53XX ARM SoC"
> >> +	select CPU_V7
> >> +	select ARM_GIC
> >> +	select HAVE_CLK
> >> +	select GENERIC_CLOCKEVENTS
> >> +	select GENERIC_TIME
> >> +	select ARM_GLOBAL_TIMER
> >> +	help
> >> +	  Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores.
> >> diff --git a/arch/arm/mach-bcm53xx/Makefile b/arch/arm/mach-bcm53xx/Makefile
> >> new file mode 100644
> >> index 0000000..88da84d
> >> --- /dev/null
> >> +++ b/arch/arm/mach-bcm53xx/Makefile
> >> @@ -0,0 +1 @@
> >> +obj-y += bcm53xx.o
> >> diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c
> >> new file mode 100644
> >> index 0000000..aa5bd397
> >> --- /dev/null
> >> +++ b/arch/arm/mach-bcm53xx/bcm53xx.c
> >> @@ -0,0 +1,68 @@
> >> +/*
> >> + * Broadcom BCM47XX / BCM53XX ARM platform code.
> >> + *
> >> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> >> + *
> >> + * Licensed under the GNU/GPL. See COPYING for details.
> >> + */
> >> +#include <linux/of_address.h>
> >> +#include <linux/of_platform.h>
> >> +#include <linux/irqchip.h>
> >> +#include <linux/clocksource.h>
> >> +#include <linux/clk-provider.h>
> >> +
> >> +#include <asm/mach/arch.h>
> >> +#include <asm/mach/map.h>
> >> +#include <asm/signal.h>
> >> +
> >> +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
> >> +				 struct pt_regs *regs)
> >> +{
> >> +	/*
> >> +	 * These happen for no good reason
> >> +	 * possibly left over from CFE
> >> +	 */
> >> +	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
> >> +		addr, fsr);
> >> +
> >> +	/* Returning non-zero causes fault display and panic */
> >> +	return 0;
> >> +}
> >> +
> >> +static void bcm53xx_aborts_enable(void)
> >> +{
> >> +	/* Install our hook */
> >> +	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
> >> +			"imprecise external abort");
> >> +}
> >> +
> >> +static void __init bcm53xx_timer_init(void)
> >> +{
> >> +	of_clk_init(NULL);
> >> +	clocksource_of_init();
> >> +}
> >> +
> >> +void __init bcm53xx_map_io(void)
> >> +{
> >> +	debug_ll_io_init();
> >> +	bcm53xx_aborts_enable();
> >> +}
> >> +
> >> +static void __init bcm53xx_dt_init(void)
> >> +{
> >> +	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> >> +}
> >> +
> >> +static const char const *bcm53xx_dt_compat[] = {
> >> +	"brcm,bcm5301x",
> >> +	"netgear,r6250v1",
> >> +	NULL,
> >> +};
> >> +
> >> +DT_MACHINE_START(BCM53XX, "BCM53XX")
> >> +	.init_machine = bcm53xx_dt_init,
> >> +	.map_io = bcm53xx_map_io,
> >> +	.init_irq = irqchip_init,
> >> +	.init_time = bcm53xx_timer_init,
> >> +	.dt_compat = bcm53xx_dt_compat,
> >> +MACHINE_END
> >> -- 
> >> 1.7.10.4
> >>
> 


From horms at verge.net.au  Tue Jul 16 19:49:58 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 17 Jul 2013 08:49:58 +0900
Subject: [PATCH v4 0/3]  ARM: shmobile: lager: enable Ether
In-Reply-To: <7990652.CKWzcoj3FL@avalon>
References: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
 <7990652.CKWzcoj3FL@avalon>
Message-ID: <20130716234958.GB30268@verge.net.au>

On Tue, Jul 16, 2013 at 11:42:12AM +0200, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Monday 01 July 2013 16:20:31 Simon Horman wrote:
> > Hi,
> > 
> > this short series enables the on-board ethernet
> > of the r8a7790 SoC for on lager board.
> > 
> > It has a run-time dependency on
> > "sh_eth: add support for r8a7790 SoC"
> > 
> > It has been built on top of renesas-next-20130701.
> 
> Do you plan to respin this series on top of your latest devel branch ? I've 
> quickly rebased it and now get receive FIFO overflows when booting over NFS, 
> followed by the kernel disabling the sh-eth IRQ.

I am planning to respin it and the driver changes once
net-next re-opens. Which I am expecting to be next week.

> > Simon Horman (3):
> >   ARM: shmobile: r8a7790: add Ether support
> >   ARM: shmobile: lager: enable Ether
> >   ARM: shmobile: lager: enable nfsroot in DTS
> > 
> >  arch/arm/boot/dts/r8a7790-lager.dts           |  2 +-
> >  arch/arm/mach-shmobile/board-lager.c          | 24 ++++++++++++++++++++++++
> > arch/arm/mach-shmobile/clock-r8a7790.c        |  4 ++++
> >  arch/arm/mach-shmobile/include/mach/r8a7790.h |  3 +++
> >  arch/arm/mach-shmobile/setup-r8a7790.c        | 14 ++++++++++++++
> >  5 files changed, 46 insertions(+), 1 deletion(-)
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From matt.porter at linaro.org  Tue Jul 16 19:52:44 2013
From: matt.porter at linaro.org (Matt Porter)
Date: Tue, 16 Jul 2013 19:52:44 -0400
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <51E58D35.4060602@hauke-m.de>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <51E56942.8030801@hauke-m.de>
 <51E58D35.4060602@hauke-m.de>
Message-ID: <20130716235244.GE3871@linaro.org>

On Tue, Jul 16, 2013 at 08:13:09PM +0200, Hauke Mehrtens wrote:
> On 07/16/2013 05:39 PM, Hauke Mehrtens wrote:
> > On 07/16/2013 05:14 PM, Matt Porter wrote:
> >> Hi Hauke,
> >>
> >> On Tue, Jul 16, 2013 at 03:52:07PM +0200, Hauke Mehrtens wrote:
> >>> This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU.
> >>> Currently just booting to a shell is working and nothing else, no
> >>> Ethernet, wifi, flash, ...
> >>>
> >>> This SoC uses a Dual core CPU, but this is currently not implemented.
> >>> More information about this SoC can be found here:
> >>> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers
> >>>
> >>> Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
> >>> ---
> 
> ....
> 
> >>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
> >>> new file mode 100644
> >>> index 0000000..638350d
> >>> --- /dev/null
> >>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> >>> @@ -0,0 +1,72 @@
> >>> +/*
> >>> + * Broadcom BCM47XX / BCM53XX ARM platform code.
> >>> + *
> >>> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> >>> + *
> >>> + * Licensed under the GNU/GPL. See COPYING for details.
> >>> + */
> >>> +
> >>> +/include/ "skeleton.dtsi"
> >>> +
> >>> +/ {
> >>> +	compatible = "brcm,bcm5301x";
> >>
> >> Ok, this was nagging at me before I went on my very long vacation. I see
> >> the "brcm" vendor prefix as a real consistency problem. I noticed on the
> >> bcm281xx/kona family, we have been using "bcm" which is not logged in
> >> vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
> >> already established use of "brcm" before any of the bcm281xx support
> >> came in. Ideally, the vendor prefix should change to "bcm" since every
> >> reference in the family names is BCM. However, if others want the least
> >> amount of churn in making this consistent, we might have to go with
> >> "brcm" across the board.
> >>
> >> Arnd, any thoughts here?
> > 
> > I have no problem with bcm or with brcm. This is a Broadcom Chip and
> > their names are starting with bcm.
> > 
> >> Another thing is that this is missing a binding definition for this
> >> compatible string. See Documentation/devicetree/bindings/arm/bcm2835.txt
> >> for an example. You should split this patch out separately as the DT
> >> maintainers generally want to see bindings as a separate patch for easy
> >> independent review.
> > 
> > Ok I will do that. This will then be merged by Linus in the 3.12 merge
> > window into a working version or how does this work?
> > 
> > Currently I have based this patch on top of 3.11-rc1 on which tree
> > should I base my changes?
> 
> Should I split out the *.dts files in arch/arm/boot/dts/ and the
> documentation for brcm,bcm4708 into an other patch?

It's common to keep the binding separate for easy standalone review by
the DT maintainers (now changing) and on devicetree-discuss). Since the
.dts files are separate logical change, it's common to separate that out
as well.

> >> Last thing, compatible strings are not to have wildcards in them. See
> >> http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
> >> and note the Warning at the bottom. Also see how bcm2835.txt and
> >> bcm11351.txt use a specific model.
> > 
> > Ok will do that.
> 
> Do I understand this right that I should currently name it exactly like
> the SoC I know and when a new SoC pops up I should make it compatible to
> this SoC?

Yes.

> I would change this to:
> compatible = "brcm,bcm4708";
> 
> If I find a BCM4709 SoC I will add this like to its dts file, assuming
> they are mostly the same?
> compatible = "brcm,bcm4709", "brcm,bcm4708";

You want the base one to be the first in the family as best as you
know. Everything else is then compatible to that. On the bcm281xx
family side, you can see that the numbering scheme is wacky such that
the first in family is bcm11351, but we refer to it by the wildcarded
name of the latest parts in the family.

-Matt


From joelf at ti.com  Tue Jul 16 19:53:07 2013
From: joelf at ti.com (Joel Fernandes)
Date: Tue, 16 Jul 2013 18:53:07 -0500
Subject: [PATCH 1/2] ARM: dts: Add SHAM data and documentation for AM33XX
In-Reply-To: <1374017368-5267-2-git-send-email-mgreer@animalcreek.com>
References: <1374017368-5267-1-git-send-email-mgreer@animalcreek.com>
 <1374017368-5267-2-git-send-email-mgreer@animalcreek.com>
Message-ID: <51E5DCE3.7060306@ti.com>

On 07/16/2013 06:29 PM, Mark A. Greer wrote:
> From: "Mark A. Greer" <mgreer at animalcreek.com>
> 
> Add the generic AM33XX SHAM module's device tree data and
> enable it for the am335x-evm, am335x-evmsk, and am335x-bone
> platforms.  Also add Documentation file describing the data
> for the SHAM module.
> 
> CC: Paul Walmsley <paul at pwsan.com>
> Signed-off-by: Mark A. Greer <mgreer at animalcreek.com>

Tested-by: Joel Fernandes <joelf at ti.com>

Thanks,

-Joel


From joelf at ti.com  Tue Jul 16 19:53:43 2013
From: joelf at ti.com (Joel Fernandes)
Date: Tue, 16 Jul 2013 18:53:43 -0500
Subject: [PATCH 2/2] ARM: dts: Add AES data and documentation for AM33XX
In-Reply-To: <1374017368-5267-3-git-send-email-mgreer@animalcreek.com>
References: <1374017368-5267-1-git-send-email-mgreer@animalcreek.com>
 <1374017368-5267-3-git-send-email-mgreer@animalcreek.com>
Message-ID: <51E5DD07.6020801@ti.com>

On 07/16/2013 06:29 PM, Mark A. Greer wrote:
> From: "Mark A. Greer" <mgreer at animalcreek.com>
> 
> Add the generic AM33XX AES module's device tree data and
> enable it for the am335x-evm, am335x-evmsk, and am335x-bone
> platforms.  Also add Documentation file describing the data
> for the AES module.
> 
> CC: Paul Walmsley <paul at pwsan.com>
> Signed-off-by: Mark A. Greer <mgreer at animalcreek.com>

Tested-by: Joel Fernandes <joelf at ti.com>

Thanks,

-Joel


From shawn.guo at linaro.org  Tue Jul 16 21:45:12 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Jul 2013 09:45:12 +0800
Subject: [PATCH v2] ARM: dts: imx: use generic DMA bindings for SSI nodes
Message-ID: <1374025512-23437-1-git-send-email-shawn.guo@linaro.org>

Updates SDMA and SSI nodes to adopt generic DMA bindings.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
Changes since v1:
 * Include imx6sl.dtsi update

 arch/arm/boot/dts/imx51.dtsi   |   12 +++++++++---
 arch/arm/boot/dts/imx53.dtsi   |   12 +++++++++---
 arch/arm/boot/dts/imx6qdl.dtsi |   12 +++++++++---
 arch/arm/boot/dts/imx6sl.dtsi  |    9 +++++++++
 4 files changed, 36 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index d086e07..cca3ef9 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -154,8 +154,10 @@
 					reg = <0x70014000 0x4000>;
 					interrupts = <30>;
 					clocks = <&clks 49>;
+					dmas = <&sdma 24 1 0>,
+					       <&sdma 25 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
-					fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */
 					status = "disabled";
 				};
 
@@ -735,8 +737,10 @@
 				reg = <0x83fcc000 0x4000>;
 				interrupts = <29>;
 				clocks = <&clks 48>;
+				dmas = <&sdma 28 0 0>,
+				       <&sdma 29 0 0>;
+				dma-names = "rx", "tx";
 				fsl,fifo-depth = <15>;
-				fsl,ssi-dma-events = <29 28 27 26>; /* TX0 RX0 TX1 RX1 */
 				status = "disabled";
 			};
 
@@ -784,8 +788,10 @@
 				reg = <0x83fe8000 0x4000>;
 				interrupts = <96>;
 				clocks = <&clks 50>;
+				dmas = <&sdma 46 0 0>,
+				       <&sdma 47 0 0>;
+				dma-names = "rx", "tx";
 				fsl,fifo-depth = <15>;
-				fsl,ssi-dma-events = <47 46 37 35>; /* TX0 RX0 TX1 RX1 */
 				status = "disabled";
 			};
 
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 51b93c9..a6b6d95 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -153,8 +153,10 @@
 					reg = <0x50014000 0x4000>;
 					interrupts = <30>;
 					clocks = <&clks 49>;
+					dmas = <&sdma 24 1 0>,
+					       <&sdma 25 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
-					fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */
 					status = "disabled";
 				};
 
@@ -1050,8 +1052,10 @@
 				reg = <0x63fcc000 0x4000>;
 				interrupts = <29>;
 				clocks = <&clks 48>;
+				dmas = <&sdma 28 0 0>,
+				       <&sdma 29 0 0>;
+				dma-names = "rx", "tx";
 				fsl,fifo-depth = <15>;
-				fsl,ssi-dma-events = <29 28 27 26>; /* TX0 RX0 TX1 RX1 */
 				status = "disabled";
 			};
 
@@ -1074,8 +1078,10 @@
 				reg = <0x63fe8000 0x4000>;
 				interrupts = <96>;
 				clocks = <&clks 50>;
+				dmas = <&sdma 46 0 0>,
+				       <&sdma 47 0 0>;
+				dma-names = "rx", "tx";
 				fsl,fifo-depth = <15>;
-				fsl,ssi-dma-events = <47 46 45 44>; /* TX0 RX0 TX1 RX1 */
 				status = "disabled";
 			};
 
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 7c18fa0..d84f8da 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -211,8 +211,10 @@
 					reg = <0x02028000 0x4000>;
 					interrupts = <0 46 0x04>;
 					clocks = <&clks 178>;
+					dmas = <&sdma 37 1 0>,
+					       <&sdma 38 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
-					fsl,ssi-dma-events = <38 37>;
 					status = "disabled";
 				};
 
@@ -221,8 +223,10 @@
 					reg = <0x0202c000 0x4000>;
 					interrupts = <0 47 0x04>;
 					clocks = <&clks 179>;
+					dmas = <&sdma 41 1 0>,
+					       <&sdma 42 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
-					fsl,ssi-dma-events = <42 41>;
 					status = "disabled";
 				};
 
@@ -231,8 +235,10 @@
 					reg = <0x02030000 0x4000>;
 					interrupts = <0 48 0x04>;
 					clocks = <&clks 180>;
+					dmas = <&sdma 45 1 0>,
+					       <&sdma 46 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
-					fsl,ssi-dma-events = <46 45>;
 					status = "disabled";
 				};
 
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index d048a78..c46651e 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -195,6 +195,9 @@
 					reg = <0x02028000 0x4000>;
 					interrupts = <0 46 0x04>;
 					clocks = <&clks IMX6SL_CLK_SSI1>;
+					dmas = <&sdma 37 1 0>,
+					       <&sdma 38 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
 					status = "disabled";
 				};
@@ -204,6 +207,9 @@
 					reg = <0x0202c000 0x4000>;
 					interrupts = <0 47 0x04>;
 					clocks = <&clks IMX6SL_CLK_SSI2>;
+					dmas = <&sdma 41 1 0>,
+					       <&sdma 42 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
 					status = "disabled";
 				};
@@ -213,6 +219,9 @@
 					reg = <0x02030000 0x4000>;
 					interrupts = <0 48 0x04>;
 					clocks = <&clks IMX6SL_CLK_SSI3>;
+					dmas = <&sdma 45 1 0>,
+					       <&sdma 46 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
 					status = "disabled";
 				};
-- 
1.7.9.5




From robherring2 at gmail.com  Tue Jul 16 21:50:01 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 16 Jul 2013 20:50:01 -0500
Subject: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property
In-Reply-To: <51E5D78F.8060400@wwwdotorg.org>
References: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
 <1373913629-32179-5-git-send-email-swarren@wwwdotorg.org>
 <51E44ED9.9020807@gmail.com> <51E47F85.4050905@wwwdotorg.org>
 <51E5D78F.8060400@wwwdotorg.org>
Message-ID: <CAL_JsqJ7CYUieGbvAZtQDEYsUKdM3yYBHSu871jUqOLeASc08g@mail.gmail.com>

On Tue, Jul 16, 2013 at 6:30 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/15/2013 05:02 PM, Stephen Warren wrote:
>> On 07/15/2013 01:34 PM, Rob Herring wrote:
>>> On 07/15/2013 01:40 PM, Stephen Warren wrote:
>>>> From: Stephen Warren <swarren at nvidia.com>
>>>>
>>>> This property is no longer required by the GPIO binding. Remove it.
>>>
>>> Won't this break compatibility with older kernel? It is one thing to
>>> deprecate, but removal is another. If the relevant maintainers don't
>>> care, then I guess it is fine.
>>
>> Yes.
>>
>> I had originally hoped this could sneak in late for 3.11, but I suppose
>> it's too late now. vf610.dtsi is a new file in 3.11 so has no legacy to
>> protect.
>>
>> Admittedly, the #gpio-cells property was added into the SPEAr files in 3.10.
>
> One more thought here:
>
> I know DT bindings are supposed to evolve so that a new kernel will
> support arbitrary old DTs. I'll call that backwards-compatibility for
> the DT parsing code.

That is the more common case.

> However, this situation is the reverse; this patch would prevent a new
> DT running on an older kernel. I'll call that forwards-compatibility.
> I'm not sure if the intent is to support this or not? It's certainly the
> first I explicitly thought about compatibility in this direction...

So you would be okay if your computer stopped booting a kernel after a
BIOS update? It's the same deal. It's both forwards and backwards
compatibility that is needed.

Rob


From myron.stowe at gmail.com  Tue Jul 16 22:21:26 2013
From: myron.stowe at gmail.com (Myron Stowe)
Date: Tue, 16 Jul 2013 20:21:26 -0600
Subject: Linux Plumbers ACPI/PM, PCI Microconference
Message-ID: <CAL-B5D03ki8NHsM6EuESTH2K-Eh+XyFHNXPDYwgDq+oagDjtMQ@mail.gmail.com>

Linux Plumbers has approved an ACPI/PM, PCI microconference. The
overview page is here:

http://wiki.linuxplumbersconf.org/2013:pci_subsystem

We would like to start receiving volunteers for presenting topics of
interest.  There is a lot of activity in these subsystems so please
respond by submitting presentation or discussion proposals that you
would be willing to cover for consideration.  You should also feel
free to submit ideas as proposals that others could cover.  The
instructions for submitting ideas should be at:

http://www.linuxplumbersconf.org/2013/submitting-topic/

This is the "Plumbers" conference so topics concerning userspace
interaction with the kernel and not just topics concerning pure kernel
subsystem internals would be greatly welcomed.  As a possible aid
towards promoting topics for submissions we have listed a few
candidates that seem to meet the criteria in the microconference
proposals wiki located at
http://wiki.linuxplumbersconf.org/2013:pci_subsystem

Last year, we had a good discussion on general issues in PCI space -
that also might be worth giving updates on.

If you have topics that you would like to add, wait until the
instructions get posted at the link above. If you are impatient, feel
free to email me directly (but probably best to drop the broad mailing
lists from the reply).

Thanks!

Len, Bjorn, Myron, Rafael



Yinghai - An update on host bridge hot-add capabilities, what is in
place and what still remains to be done, would seem like a good topic.

Shuah - You brought up the idea about "Converting drivers from Legacy
PM ops to dev_pm_ops"; would you like to present what you have
done/encountered so far?


From swarren at wwwdotorg.org  Tue Jul 16 22:58:19 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 16 Jul 2013 20:58:19 -0600
Subject: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property
In-Reply-To: <CAL_JsqJ7CYUieGbvAZtQDEYsUKdM3yYBHSu871jUqOLeASc08g@mail.gmail.com>
References: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
 <1373913629-32179-5-git-send-email-swarren@wwwdotorg.org>
 <51E44ED9.9020807@gmail.com> <51E47F85.4050905@wwwdotorg.org>
 <51E5D78F.8060400@wwwdotorg.org>
 <CAL_JsqJ7CYUieGbvAZtQDEYsUKdM3yYBHSu871jUqOLeASc08g@mail.gmail.com>
Message-ID: <51E6084B.30500@wwwdotorg.org>

On 07/16/2013 07:50 PM, Rob Herring wrote:
> On Tue, Jul 16, 2013 at 6:30 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 07/15/2013 05:02 PM, Stephen Warren wrote:
>>> On 07/15/2013 01:34 PM, Rob Herring wrote:
>>>> On 07/15/2013 01:40 PM, Stephen Warren wrote:
>>>>> From: Stephen Warren <swarren at nvidia.com>
>>>>>
>>>>> This property is no longer required by the GPIO binding. Remove it.
>>>>
>>>> Won't this break compatibility with older kernel? It is one thing to
>>>> deprecate, but removal is another. If the relevant maintainers don't
>>>> care, then I guess it is fine.
>>>
>>> Yes.
>>>
>>> I had originally hoped this could sneak in late for 3.11, but I suppose
>>> it's too late now. vf610.dtsi is a new file in 3.11 so has no legacy to
>>> protect.
>>>
>>> Admittedly, the #gpio-cells property was added into the SPEAr files in 3.10.
>>
>> One more thought here:
>>
>> I know DT bindings are supposed to evolve so that a new kernel will
>> support arbitrary old DTs. I'll call that backwards-compatibility for
>> the DT parsing code.
> 
> That is the more common case.
> 
>> However, this situation is the reverse; this patch would prevent a new
>> DT running on an older kernel. I'll call that forwards-compatibility.
>> I'm not sure if the intent is to support this or not? It's certainly the
>> first I explicitly thought about compatibility in this direction...
> 
> So you would be okay if your computer stopped booting a kernel after a
> BIOS update? It's the same deal. It's both forwards and backwards
> compatibility that is needed.

I would strongly hope the BIOS/bootloader/... would have nothing to do
with the DT content. There's a reason that Grant asserted early on that
DTBs shouldn't be part of the BIOS/bootloader, but rather stored
separately, so the DTB could be updated without updating firmware, just
like the kernel. And I see no real problem with a new DTB requiring a
new kernel or even vice-versa to be honest.


From shawn.guo at linaro.org  Tue Jul 16 23:02:48 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Jul 2013 11:02:48 +0800
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <51E56AA7.7020103@wwwdotorg.org>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <20130716041056.GA30067@S2101-09.ap.freescale.net>
 <51E56AA7.7020103@wwwdotorg.org>
Message-ID: <20130717030246.GA4541@S2101-09.ap.freescale.net>

On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote:
> Registering the driver earlier won't cause any bugs. However, it's not
> the correct approach.
> 
> Deferred probe /is/ the approach for assuring correct dependencies
> between drivers. It works and should be used. There are not enough
> initcall levels to play games using initcalls and solve all the issues,
> and the ordering requirements vary board-to-board. Deferred probe at
> runtime handles this without having to manually place all the drivers
> into specific initcall levels, and dynamically adjusts to board
> differences, since it all happens automatically at run-time.

I do not quite follow the argument here.  I agree with you that
deferred probe is the approach to solve dependencies.  But it does not
necessarily mean that initcall can not be used to help it save some
nasty or nested deferring.  Deferred probe and initcalls are not two
mutually exclusive mechanisms but two which can help each other.

Shawn



From robherring2 at gmail.com  Tue Jul 16 23:22:22 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 16 Jul 2013 22:22:22 -0500
Subject: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu
 nodes bindings updates
In-Reply-To: <20130716094508.GA28503@e102568-lin.cambridge.arm.com>
References: <1368804061-4421-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1368804061-4421-4-git-send-email-lorenzo.pieralisi@arm.com>
 <CAL_JsqLANi5UoVyRMsa6XoQ+_KnmTQDfTz++shEh-dZ3FQGZaQ@mail.gmail.com>
 <20130715093406.GC15904@e102568-lin.cambridge.arm.com>
 <51E44486.7050806@gmail.com>
 <20130716094508.GA28503@e102568-lin.cambridge.arm.com>
Message-ID: <51E60DEE.6090403@gmail.com>

On 07/16/2013 04:45 AM, Lorenzo Pieralisi wrote:
> On Mon, Jul 15, 2013 at 07:50:46PM +0100, Rob Herring wrote:
>> On 07/15/2013 04:34 AM, Lorenzo Pieralisi wrote:
>>> On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote:
>>>> On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi
>>>> <lorenzo.pieralisi at arm.com> wrote:
>>>>> In order to extend the current cpu nodes bindings to newer CPUs
>>>>> inclusive of AArch64 and to update support for older ARM CPUs this
>>>>> patch updates device tree documentation for the cpu nodes bindings.
>>>>
>>>> Sorry for the long delay on this, but I'm still not happy with the binding here.
>>>
>>> I had to ask Russell again to drop the bindings patches from the patch
>>> system, and this is not acceptable since two months have passed and the
>>> entire series was reviewed, acked and partially merged. I will review
>>> these bindings again but I would like to understand who should give the final
>>> go ahead to get these patches queued for upstreaming, I can't continue
>>> updating this stuff forever.
>>
>> Most of my comments are for 64-bit. So don't blame me that it had to be
>> reverted. I said up front I was concerned about this change breaking
>> things and it appears it did. New kernels must not require a new DT.
> 
> The patches in Russell's tree do not break anything, I asked him to drop
> them since, if we change the bindings again, those patches change and have
> to be reworked. It was not meant to blame you at all, just saying that
> the process to get this stuff in the kernel should be defined properly
> and patches reviewed in a timely fashion.
> 
> And for legacy reasons the situation related to cpu/cpus node bindings
> is a complicated one, there are bindings in the ePAPR, bindings in the
> kernel, people are confused and with this set we wanted to draw a
> line. For arm64 this is an absolute must.
> 
> I disagree with you on the "new kernels must not require a new DT".
> That's true if bindings are well defined, not for a mix of legacy ePAPR and
> bindings-in-the-kernel.

Well defined depends on the platform. For purposes of a single cluster
ARM system, the ePAPR was pretty much sufficient for cpu node
description. The initial discussion was whether we even needed cpu nodes
at all.

We're always going to have something new that we did not account for. So
even for well defined bindings, we'll have to make changes/extensions at
some point. It just needs to be years, not months for changes.

> What's the DT standard for ARM cpu/cpus node ? ePAPR ? In kernel docs ?
> A combination thereof ? Things are not clear cut and I do not like that, it
> is confusing.

ePAPR is a guideline, but in the end it is a PowerPC document. In some
cases we can just use what it defines and in others we need to deviate.
In an ideal world, we would create the equivalent for ARM or figure out
how to merge ARM requirements with ePAPR. However, since UEFI and ACPI
are going to solve all our problems, no one seems interested in defining
a more formal document.

To further complicate things, there is also the original OF
specification to follow as well. So I would say all the docs apply and
the order of priority is DT binding docs, ePAPR, OF specs. The DT
binding docs need to be complete enough to avoid confusion.

Rob



From nicolas.pitre at linaro.org  Tue Jul 16 23:26:49 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 16 Jul 2013 23:26:49 -0400 (EDT)
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <alpine.LFD.2.03.1307162323530.14924@syhkavp.arg>

On Tue, 16 Jul 2013, Lorenzo Pieralisi wrote:

> Hello,
> 
> version v5 of VExpress SPC driver, please read on the changelog for major
> changes and explanations.
> 
> The probing scheme is unchanged, since after trying the early platform
> devices approach it appeared that the end result was no better than the
> current one. The only clean solution relies either on changing how
> secondaries are brought up in the kernel (later than now) or enable
> early platform device registration through DT. Please check this
> thread for the related discussion:
> 
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036542.html
> 
> The interface was adapted to regmap and again reverted to old driver for
> the following reasons:
> 
> - Power down registers locking is hairy and requires arch spinlocks in
>   the MCPM back end to work properly, normal spinlocks cannot be used
> - Regmap adds unnecessary code to manage SPC since it is just a bunch of
>   registers used to control power management flags, the overhead is just
>   not worth it (talking about power down registers, not the vexpress config
>   interface)
> - The locking scheme behind regmap requires all registers in the map
>   to be protected with the same lock, which is not exactly what we want
>   here
> - Given the reasons above, adding a regmap interface buys us nothing from
>   a driver readability and maintainability perspective (again just talking
>   about the power interface, a few registers) because for the SPC it would
>   simply not be used
> 
> /drivers/mfd is probably not the right place for this code as it stands (but
> probably will be when the entire driver, with DVFS and config interface, is
> complete).
> 
> Thank you for the review in advance,
> Lorenzo

I've integrated this patch in my MCPM backend for TC2 patch series.

ACKs from concerned/interested people would be appreciated so I could 
send this for ARM-SOC inclusion right away.


Nicolas


From shawn.guo at linaro.org  Tue Jul 16 23:43:15 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Jul 2013 11:43:15 +0800
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <51E56AF6.30506@wwwdotorg.org>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <20130716065130.GB30067@S2101-09.ap.freescale.net>
 <51E56AF6.30506@wwwdotorg.org>
Message-ID: <20130717034314.GB4541@S2101-09.ap.freescale.net>

On Tue, Jul 16, 2013 at 09:47:02AM -0600, Stephen Warren wrote:
> > diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
> 
> > -	gpio_set_value(drvdata->gpio, value);
> > +	if (gpio_cansleep(drvdata->gpio))
> > +		gpio_set_value_cansleep(drvdata->gpio, value);
> > +	else
> > +		gpio_set_value(drvdata->gpio, value);
> 
> That's not right. Calling gpio_set_value() v.s.
> gpio_set_value_cansleep() should be based on the properties of the
> calling context, not the GPIO being controlled. In other words, if it's
> permissible to call gpio_set_value_cansleep() at this point in the code,
> simply always call that, and remove the conditional logic.

Ah, yes.  I was confused by the API gpio_cansleep().  Which API we
should call depends on the calling context.  And the context should
come from the gpio-reset client device driver.  IOW, we have no idea
what the context is in gpio-reset driver.  To start with something
simple, we may want to define the gpio-reset as a sleepable interface
and always call gpio_set_value_cansleep() in there.

Shawn



From shawn.guo at linaro.org  Tue Jul 16 23:50:11 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Jul 2013 11:50:11 +0800
Subject: [PATCH v2 1/4] ARM: dts: imx23-evk: enable USB PHY and controller
In-Reply-To: <1373979376-31583-1-git-send-email-otavio@ossystems.com.br>
References: <1373979376-31583-1-git-send-email-otavio@ossystems.com.br>
Message-ID: <20130717035010.GC4541@S2101-09.ap.freescale.net>

On Tue, Jul 16, 2013 at 09:56:12AM -0300, Otavio Salvador wrote:
> The i.MX23EVK board provides a USB port so the USB PHY and controller
> need to be enabled for it to be usable.
> 
> Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>

There is a typo i.XM23 in commit log of patch #2 and #3.  I fixed them
up and applied all 3.

Shawn



From shawn.guo at linaro.org  Tue Jul 16 23:51:27 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Jul 2013 11:51:27 +0800
Subject: [PATCH] clk: mxs: clk-imx23: Include <linux/clk/mxs.h>
In-Reply-To: <1373981623-23800-1-git-send-email-fabio.estevam@freescale.com>
References: <1373981623-23800-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <20130717035125.GD4541@S2101-09.ap.freescale.net>

On Tue, Jul 16, 2013 at 10:33:43AM -0300, Fabio Estevam wrote:
> Fix the following sparse warning:
> 
> drivers/clk/mxs/clk-imx23.c:102:12: warning: symbol 'mx23_clocks_init' was not declared. Should it be static?
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Acked-by: Shawn Guo <shawn.guo at linaro.org>

> ---
>  drivers/clk/mxs/clk-imx23.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clk/mxs/clk-imx23.c b/drivers/clk/mxs/clk-imx23.c
> index f6a7487..c396fe3 100644
> --- a/drivers/clk/mxs/clk-imx23.c
> +++ b/drivers/clk/mxs/clk-imx23.c
> @@ -10,6 +10,7 @@
>   */
>  
>  #include <linux/clk.h>
> +#include <linux/clk/mxs.h>
>  #include <linux/clkdev.h>
>  #include <linux/err.h>
>  #include <linux/init.h>
> -- 
> 1.8.1.2
> 
> 



From shawn.guo at linaro.org  Tue Jul 16 23:53:23 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Jul 2013 11:53:23 +0800
Subject: [PATCH] ARM: mxs: pm: Include "pm.h"
In-Reply-To: <1373981559-23743-1-git-send-email-fabio.estevam@freescale.com>
References: <1373981559-23743-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <20130717035321.GE4541@S2101-09.ap.freescale.net>

On Tue, Jul 16, 2013 at 10:32:39AM -0300, Fabio Estevam wrote:
> Fix the following sparse warning:
> 
> arch/arm/mach-mxs/pm.c:37:13: warning: symbol 'mxs_pm_init' was not declared. Should it be static?
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Applied, thanks.



From gregkh at linuxfoundation.org  Wed Jul 17 00:13:27 2013
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Tue, 16 Jul 2013 21:13:27 -0700
Subject: [GIT PULL] PHY Framework for 3.12 merge window
In-Reply-To: <51E53EC2.5080401@ti.com>
References: <51E53EC2.5080401@ti.com>
Message-ID: <20130717041327.GA20201@kroah.com>

On Tue, Jul 16, 2013 at 06:08:26PM +0530, Kishon Vijay Abraham I wrote:
> Hi Greg,
> 
> Here's the pull request for the PHY Framework which I've been working on for a
> while.
> 
> I've applied these patches on the current linux mainline HEAD (which has one
> commit after 3.11-rc1 is tagged).
> 
> Even before this framework is merged, quite a few people started using it. I've
> queued those patches along with the PHY framework as well.
> 
> I'm also planning to maintain this framework henceforth and will be sending
> pull requests for anything related to this framework or users of this framework.
> 
> Let me know if you want any changes on this pull request
> 
> Thanks
> Kishon
> 
> The following changes since commit 47188d39b5deeebf41f87a02af1b3935866364cf:
> 
>   Merge tag 'ext4_for_linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2013-07-14 21:47:51
> -0700)
> 
> are available in the git repository at:
> 
> 
>   git://gitorious.org/linuxphy/linuxphy.git tags/phy-for-v3.12

I'm sorry, but I can't pull from a non-kernel.org account.  And, why is
this a pull request at all?   There aren't many patches in this series,
I can take them just fine through email.  I only do pull requests from a
_very_ limited number of people whom I have been working with for a long
time, everyone else I handle just fine with email.

Also, why me for this?   Should it go through my "char/misc" tree?  Do
you have sign-offs for the subsystems that you touch?  Will you be
moving more phy code from the different subsystems (like all the USB phy
code), into here as well?  Or is this just for new devices?

thanks,

greg k-h


From gregkh at linuxfoundation.org  Wed Jul 17 00:20:37 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 16 Jul 2013 21:20:37 -0700
Subject: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner's
 Security ID fuses
In-Reply-To: <51E5B4DE.5060002@schinagl.nl>
References: <20130624181509.GA8847@kroah.com> <51C8B84C.3020200@schinagl.nl>
 <20130624214615.GA17604@kroah.com> <51CAA709.4060801@schinagl.nl>
 <20130626175144.GC2222@kroah.com> <51D674BF.9030207@schinagl.nl>
 <20130706193646.GB9778@kroah.com> <51E466A3.4010503@schinagl.nl>
 <20130716064107.GA10868@kroah.com> <51E5B4DE.5060002@schinagl.nl>
Message-ID: <20130717042037.GB20312@kroah.com>

On Tue, Jul 16, 2013 at 11:02:22PM +0200, Oliver Schinagl wrote:
> On 07/16/13 08:41, Greg KH wrote:
> > On Mon, Jul 15, 2013 at 11:16:19PM +0200, Oliver Schinagl wrote:
> >> With your latest patches for binary attributes and your blog post, I
> >> thought that you want to create your binary attributes before the probe
> >> function, to avoid the userspace race. To do that, we have two options,
> >> create them in init (ugly?) or fill the .group member if available so it
> >> gets automatically created from the register function.
> > Yes, the .group thing should be what is needed here.
> That's what I thought (and used).
> >
> >> Well in my case, I'm using the module_platform_driver() macro which
> >> expects the struct platform_driver. Platform_driver has a device_driver
> >> member .driver where the .groups is located. Great, using that works and
> >> we should have the sysfs entry race-free. However I don't know hot to
> >> exchange data between that and the rest of my driver.
> >>
> >> Before I used to_platform_device(kobj_to_dev(kobj)) as passed via the
> >> .read function to obtain a platform_device where i could use
> >> platform_get_drvdata on. All was good, but that doesn't fly now and my
> >> knowledge is a bit short as to why.
> > I don't understand, why not use the platform device that was passed to
> > the binary attribute write function?
> Because the pointers don't match and I get a null pointer from 
> platform_get_data

That's not good, that shouldn't happen.

> >> The second method is finding some other shared structure given that we
> >> get a platform_device in the probe function, yet I couldn't find
> >> anything and this platform_device isn't the same as the one from the .read.
> > It should be, why isn't it?
> I think that's a little above my grasp :p
> >
> >> Of course using a global var bypasses this issue, but I'm sure it won't
> >> pass review ;)
> > The platform device structure should have what you need, right?
> Should, but doesn't :(
> >
> >> So using these new patches for binary attributes, how can I pass data
> >> between my driver and the sysfs files using a platform_driver? Or are
> >> other 'hacks' needed and using the .groups attribute from
> >> platform_driver->device_driver->groups is really the wrong approach.
> >>
> >> I did ask around and still haven't figured it out so far, so I do
> >> apologize if you feel I'm wasting your precious time.
> > How is the platform device not the same thing that was passed to your
> > probe function?
> I don't know :( But i'll add the relevant sections with printk results 
> below, which I should have done before, then again those printk's were 
> not supposed to be in that e-mail to begin with ;)
> 
> So if I'm not seeing something stupidly obvious, feel free to shout at me :)

Your code looks good, and correct, to me, I don't see anything obviously
wrong.  What creates your platform device in the first place?

> 
> static ssize_t sid_read(struct file *fd, struct kobject *kobj,
>              struct bin_attribute *attr, char *buf,
>              loff_t pos, size_t size)
> {
>      struct platform_device *pdev;
>      void __iomem *sid_reg_base;
>      int i;
> 
>      pdev = to_platform_device(kobj_to_dev(kobj));
>      sid_reg_base = (void __iomem *)platform_get_drvdata(pdev);
>      printk("0x%p, 0x%p, 0x%p, 0x%p\n", kobj, kobj_to_dev(kobj), pdev, 
> sid_reg_base);
> 
> 0xef1e7c80, 0xef1e7c78, 0xef1e7c68, 0x  (null)
> 
>      if (pos < 0 || pos >= SID_SIZE)
>          return 0;
>      if (size > SID_SIZE - pos)
>          size = SID_SIZE - pos;
> 
>      for (i = 0; i < size; i++)
>          buf[i] = sunxi_sid_read_byte(sid_reg_base, pos + i);
> 
>      return i;
> }
> 
> 
> static struct bin_attribute sid_bin_attr = {
>      .attr = { .name = "eeprom", .mode = S_IRUGO, },
>      .size = SID_SIZE,
>      .read = sid_read,
> };
> 
> static struct bin_attribute *sunxi_sid_attrs[] = {
>      &sid_bin_attr,
>      NULL,
> };
> 
> static const struct attribute_group sunxi_sid_group = {
>      .bin_attrs = sunxi_sid_attrs,
> };

If you create a "normal" attribute here as well, does that work
properly?

> 
> static const struct attribute_group *sunxi_sid_groups[] = {
>      &sunxi_sid_group,
>      NULL,
> };
> 
> static int __init sunxi_sid_probe(struct platform_device *pdev)
> {
>      struct resource *res;
>      void __iomem *sid_reg_base;
>      u8 entropy[SID_SIZE];
>      unsigned int i;
> 
>      res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>      sid_reg_base = devm_ioremap_resource(&pdev->dev, res);
>      if (IS_ERR(sid_reg_base))
>          return PTR_ERR(sid_reg_base);
>      platform_set_drvdata(pdev, sid_reg_base);
> 
>      for (i = 0; i < SID_SIZE; i++)
>          entropy[i] = sunxi_sid_read_byte(sid_reg_base, i);
>      add_device_randomness(entropy, SID_SIZE);
>      dev_dbg(&pdev->dev, "%s loaded\n", DRV_NAME);
>      printk("0x%p, 0x%p\n", pdev, sid_reg_base);
> 
> 0xef02b000, 0xf1c23800

The memory locations are really different here, that's strange, I don't
know what is going on, sorry.

Try a text attribute to ensure that works properly.

greg k-h


From lokeshvutla at ti.com  Wed Jul 17 00:42:22 2013
From: lokeshvutla at ti.com (Lokesh Vutla)
Date: Wed, 17 Jul 2013 10:12:22 +0530
Subject: [PATCH 1/2] ARM: dts: Add SHAM data and documentation for AM33XX
In-Reply-To: <1374017368-5267-2-git-send-email-mgreer@animalcreek.com>
References: <1374017368-5267-1-git-send-email-mgreer@animalcreek.com>
 <1374017368-5267-2-git-send-email-mgreer@animalcreek.com>
Message-ID: <51E620AE.8090602@ti.com>

Hi Mark,

On Wednesday 17 July 2013 04:59 AM, Mark A. Greer wrote:
> From: "Mark A. Greer" <mgreer at animalcreek.com>
> 
> Add the generic AM33XX SHAM module's device tree data and
> enable it for the am335x-evm, am335x-evmsk, and am335x-bone
> platforms.  Also add Documentation file describing the data
> for the SHAM module.
> 
> CC: Paul Walmsley <paul at pwsan.com>
> Signed-off-by: Mark A. Greer <mgreer at animalcreek.com>
> ---
>  .../devicetree/bindings/crypto/omap-sham.txt       | 33 ++++++++++++++++++++++
>  arch/arm/boot/dts/am335x-bone.dts                  |  4 +++
>  arch/arm/boot/dts/am335x-evm.dts                   |  4 +++
>  arch/arm/boot/dts/am335x-evmsk.dts                 |  3 ++
>  arch/arm/boot/dts/am33xx.dtsi                      |  9 ++++++
>  5 files changed, 53 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/crypto/omap-sham.txt
> 
> diff --git a/Documentation/devicetree/bindings/crypto/omap-sham.txt b/Documentation/devicetree/bindings/crypto/omap-sham.txt
> new file mode 100644
> index 0000000..c6d1202
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/omap-sham.txt
> @@ -0,0 +1,33 @@
> +OMAP SoC SHA crypto Module
> +
> +Required properties:
> +
> +- compatible : Should contain entries for this and backward compatible
> +  SHAM versions:
> +  - "ti,omap2-sham" for OMAP2 & OMAP3.
> +  - "ti,omap4-sham" for OMAP4 and AM33XX.
> +  Note that these two versions are incompatible.
> +- ti,hwmods: Name of the hwmod associated with the SHAM module
> +- reg : Offset and length of the register set for the module
> +- interrupt-parent : the phandle for the interrupt controller that
> +  services interrupts for this module.
> +- interrupts : the interrupt number for the SHAM module.
> +
> +Optional properties:
> +- dmas: DMA controller phandle and DMA request ordered pair.
> +	Only one rx pair is valid per SHAM module.
> +- dma-names: DMA request name. This string corresponds 1:1 with
> +	the ordered pair in dmas. The string naming is to be
> +	"rx" for RX request.
> +
> +Example:
> +	/* AM335x */
> +	sham: sham at 53100000 {
> +		compatible = "ti,omap4-sham";
> +		ti,hwmods = "sham";
> +		reg = <0x53100000 0x200>;
> +		interrupt-parent = <&intc>;
> +		interrupts = <109>;
> +		dmas = <&edma 36>;
> +		dma-names = "rx";
> +	};
> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> index 444b4ed..bc75b2c 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -234,3 +234,7 @@
>  	pinctrl-0 = <&davinci_mdio_default>;
>  	pinctrl-1 = <&davinci_mdio_sleep>;
>  };
> +
> +&sham {
> +	status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
> index 3aee1a4..9b8c56d 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -488,3 +488,7 @@
>  		ti,adc-channels = <4 5 6 7>;
>  	};
>  };
> +
> +&sham {
> +	status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
> index 0c8ad17..b04aea1 100644
> --- a/arch/arm/boot/dts/am335x-evmsk.dts
> +++ b/arch/arm/boot/dts/am335x-evmsk.dts
> @@ -401,4 +401,7 @@
>  &cpsw_emac1 {
>  	phy_id = <&davinci_mdio>, <1>;
>  	phy-mode = "rgmii-txid";
> +
> +&sham {
> +	status = "okay";
 "};" is missing here.
>  };
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 38b446b..eb0e719 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -529,6 +529,15 @@
>  			#address-cells = <2>;
>  			#size-cells = <1>;
>  			status = "disabled";
> +
> +		sham: sham at 53100000 {
> +			compatible = "ti,omap4-sham";
> +			ti,hwmods = "sham";
> +			reg = <0x53100000 0x200>;
> +			interrupt-parent = <&intc>;
> +			interrupts = <109>;
> +			dmas = <&edma 36>;
> +			dma-names = "rx";
ditto...

And please specify in commit log that this series is dependent on
Joel's "[PATCH 1/2] ARM: dts: add AM33XX EDMA support" series.

Thanks,
Lokesh 
>  		};
>  	};
>  };
> 



From thierry.reding at gmail.com  Wed Jul 17 00:56:08 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Wed, 17 Jul 2013 06:56:08 +0200
Subject: [PATCH V3 3/4] ARM: dts: tegra: Correct PCIe entry
In-Reply-To: <20130611073048.GR3847@tbergstrom-lnx.Nvidia.com>
References: <1370372252-4332-1-git-send-email-jagarwal@nvidia.com>
 <1370372252-4332-3-git-send-email-jagarwal@nvidia.com>
 <20130610195511.GC25859@mithrandir>
 <20130611073048.GR3847@tbergstrom-lnx.Nvidia.com>
Message-ID: <20130717045607.GC11359@mithrandir>

On Tue, Jun 11, 2013 at 10:30:48AM +0300, Peter De Schrijver wrote:
> On Mon, Jun 10, 2013 at 09:55:12PM +0200, Thierry Reding wrote:
> > * PGP Signed by an unknown key
> > 
> > On Wed, Jun 05, 2013 at 12:27:31AM +0530, Jay Agarwal wrote:
> > [...]
> > > @@ -29,7 +29,7 @@
> > >  		ranges = <0x82000000 0 0x00000000 0x00000000 0 0x00001000   /* port 0 configuration space */
> > >  			  0x82000000 0 0x00001000 0x00001000 0 0x00001000   /* port 1 configuration space */
> > >  			  0x82000000 0 0x00004000 0x00004000 0 0x00001000   /* port 2 configuration space */
> > > -			  0x81000000 0 0          0x02000000 0 0x00010000   /* downstream I/O */
> > > +			  0x81000000 0 0          0x02000000 0 0x00100000   /* downstream I/O */
> > >  			  0x82000000 0 0x20000000 0x20000000 0 0x10000000   /* non-prefetchable memory */
> > >  			  0xc2000000 0 0x30000000 0x30000000 0 0x10000000>; /* prefetchable memory */
> > 
> > That increases the I/O region size from 64 KiB to 1 MiB. Why is that
> > necessary? I/O operations can only address 64 KiB, so I don't think
> > adding more makes any sense.
> 
> At least PCI allows 32bit I/O addresses. No idea if anyone uses them though.

I just realized that we are constrained to 64 KiB by the implementation
of pci_ioremap_io(), which assumes each mapping is 64 KiB. Not that it
couldn't be changed, but unless there actually is a use-case where more
than 64 KiB are required I don't think we should worry about it.

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/20130717/db9411c6/attachment.sig>

From thierry.reding at gmail.com  Wed Jul 17 01:07:49 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Wed, 17 Jul 2013 07:07:49 +0200
Subject: [PATCH V5 1/3] pci: Add PCIe driver for Samsung Exynos
In-Reply-To: <3309315.fJN6KWK0oA@wuerfel>
References: <000b01ce6839$0f0455d0$2d0d0170$@samsung.com>
 <000001ce68d7$ca762200$5f626600$@samsung.com>
 <20130614105310.GA19060@manwe> <3309315.fJN6KWK0oA@wuerfel>
Message-ID: <20130717050748.GD11359@mithrandir>

On Fri, Jun 14, 2013 at 02:38:49PM +0200, Arnd Bergmann wrote:
> On Friday 14 June 2013 12:53:11 Thierry Reding wrote:
> > 
> > I think the biggest missing piece is pci_common_exit(), the counterpart
> > of pci_common_init(), to cleanup a host bridge on ARM. I haven't looked
> > in detail at the other architectures, but I suspect there must be some
> > code to call when a host bridge is removed.
> > 
> > Looking at drivers/pci/remove.c, it seems like pci_remove_root_bus()
> > might be what we're looking at. It isn't exported so it can't be used by
> > modules, but that can be changed. Is that how a host bridge is typically
> > removed from the system?
> 
> It's fairly new to have host bridges in loadable modules, so I'm pretty
> sure it's not supported by the core yet, but it also doesn't seem hard
> to do. I think you are right with regard to pci_remove_root_bus,
> and Bjorn might be able to provide more information.
> 
> Ideally we should be able to load and unload the pci host driver
> in a loop indefinitely without crashing or exposing any races
> or leaks, but I would not bet on that working without bugs in the
> core, since that goes beyond the normal pci (device) hotplug case.

I've done some preliminary testing on Tegra using sysfs to unbind and
rebind the device from and to the driver. Some code needs to be added
for this to work, but it doesn't crash and PCI even continues to work
after unbinding and rebinding (tested using gigabit ethernet).

However I haven't looked for leaks yet, and I'm pretty sure some more
code is required to undo some of what pci_common_init() does on ARM.
Looking more closely, I think most (if not all) remaining leaks could
be fixed by keeping the list of pci_sys_data structures around and
cleaning them up properly.

Given the experimental nature of this I don't want to make that part of
the driver for 3.12 and I've opted to just disable any means of removing
the driver for now. But I do want to get back to this after the driver
has been merged.

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/20130717/f8bfe607/attachment.sig>

From festevam at gmail.com  Wed Jul 17 01:11:09 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 17 Jul 2013 02:11:09 -0300
Subject: [PATCH] ARM: dts: imx6qdl-sabresd: Drop the chip variant suffix
Message-ID: <1374037869-17443-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

imx6qdl-sabresd.dtsi is a common file for mx6q and mx6dl versions of sabresd
board, so let's get rid of the 'quad' reference in the compatible string.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 4dec80c..f70db40 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -52,7 +52,7 @@
 	};
 
 	sound {
-		compatible = "fsl,imx6q-sabresd-wm8962",
+		compatible = "fsl,imx6-sabresd-wm8962",
 			   "fsl,imx-audio-wm8962";
 		model = "wm8962-audio";
 		ssi-controller = <&ssi2>;
-- 
1.8.1.2



From viresh.kumar at linaro.org  Wed Jul 17 01:18:57 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Wed, 17 Jul 2013 10:48:57 +0530
Subject: [PATCH RFC v2 14/14] ARM: debug: move Spear debug to generic
 PL01x code
In-Reply-To: <E1Uz8PB-00048R-F3@rmk-PC.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
 <E1Uz8PB-00048R-F3@rmk-PC.arm.linux.org.uk>
Message-ID: <CAOh2x==PCWa_eOK1S5oy+B-tbwin2ceeb92-ihJ6J_XmC2irUQ@mail.gmail.com>

On Tue, Jul 16, 2013 at 10:17 PM, Russell King
<rmk+kernel at arm.linux.org.uk> wrote:
> The Spear debug code is a copy of the PL01x debugging code, so rather
> than have this pointless code duplication, lets just use the standard
> implementation instead.
>
> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
> ---
>  arch/arm/Kconfig.debug                         |    7 ++++
>  arch/arm/mach-spear/include/mach/debug-macro.S |   36 ------------------------
>  arch/arm/mach-spear/include/mach/spear.h       |    2 -
>  3 files changed, 7 insertions(+), 38 deletions(-)
>  delete mode 100644 arch/arm/mach-spear/include/mach/debug-macro.S

s/Spear/SPEAr

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>


From shawn.guo at linaro.org  Wed Jul 17 01:23:36 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Jul 2013 13:23:36 +0800
Subject: [PATCH] ARM: dts: imx6qdl-sabresd: Drop the chip variant suffix
In-Reply-To: <1374037869-17443-1-git-send-email-festevam@gmail.com>
References: <1374037869-17443-1-git-send-email-festevam@gmail.com>
Message-ID: <20130717052334.GF4541@S2101-09.ap.freescale.net>

On Wed, Jul 17, 2013 at 02:11:09AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> imx6qdl-sabresd.dtsi is a common file for mx6q and mx6dl versions of sabresd
> board, so let's get rid of the 'quad' reference in the compatible string.
> 
The change makes no sense.  Look at it in this way: imx6dl sabresd
wm8962 is compatible to imx6q one.

Shawn

> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> index 4dec80c..f70db40 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> @@ -52,7 +52,7 @@
>  	};
>  
>  	sound {
> -		compatible = "fsl,imx6q-sabresd-wm8962",
> +		compatible = "fsl,imx6-sabresd-wm8962",
>  			   "fsl,imx-audio-wm8962";
>  		model = "wm8962-audio";
>  		ssi-controller = <&ssi2>;
> -- 
> 1.8.1.2
> 



From shawn.guo at linaro.org  Wed Jul 17 01:57:48 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 17 Jul 2013 13:57:48 +0800
Subject: [PATCH v3] ARM: dts: imx: use generic DMA bindings for SSI nodes
Message-ID: <1374040668-14325-1-git-send-email-shawn.guo@linaro.org>

Updates SSI nodes to adopt generic DMA bindings.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
Changes since v2:
 * Keep custom fsl,ssi-dma-events property until fsl_ssi driver moves
   to use generic DMA bindings.

 arch/arm/boot/dts/imx51.dtsi   |    9 +++++++++
 arch/arm/boot/dts/imx53.dtsi   |    9 +++++++++
 arch/arm/boot/dts/imx6qdl.dtsi |    9 +++++++++
 arch/arm/boot/dts/imx6sl.dtsi  |    9 +++++++++
 4 files changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index d086e07..d7b0646 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -154,6 +154,9 @@
 					reg = <0x70014000 0x4000>;
 					interrupts = <30>;
 					clocks = <&clks 49>;
+					dmas = <&sdma 24 1 0>,
+					       <&sdma 25 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
 					fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */
 					status = "disabled";
@@ -735,6 +738,9 @@
 				reg = <0x83fcc000 0x4000>;
 				interrupts = <29>;
 				clocks = <&clks 48>;
+				dmas = <&sdma 28 0 0>,
+				       <&sdma 29 0 0>;
+				dma-names = "rx", "tx";
 				fsl,fifo-depth = <15>;
 				fsl,ssi-dma-events = <29 28 27 26>; /* TX0 RX0 TX1 RX1 */
 				status = "disabled";
@@ -784,6 +790,9 @@
 				reg = <0x83fe8000 0x4000>;
 				interrupts = <96>;
 				clocks = <&clks 50>;
+				dmas = <&sdma 46 0 0>,
+				       <&sdma 47 0 0>;
+				dma-names = "rx", "tx";
 				fsl,fifo-depth = <15>;
 				fsl,ssi-dma-events = <47 46 37 35>; /* TX0 RX0 TX1 RX1 */
 				status = "disabled";
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 51b93c9..fb26830 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -153,6 +153,9 @@
 					reg = <0x50014000 0x4000>;
 					interrupts = <30>;
 					clocks = <&clks 49>;
+					dmas = <&sdma 24 1 0>,
+					       <&sdma 25 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
 					fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */
 					status = "disabled";
@@ -1050,6 +1053,9 @@
 				reg = <0x63fcc000 0x4000>;
 				interrupts = <29>;
 				clocks = <&clks 48>;
+				dmas = <&sdma 28 0 0>,
+				       <&sdma 29 0 0>;
+				dma-names = "rx", "tx";
 				fsl,fifo-depth = <15>;
 				fsl,ssi-dma-events = <29 28 27 26>; /* TX0 RX0 TX1 RX1 */
 				status = "disabled";
@@ -1074,6 +1080,9 @@
 				reg = <0x63fe8000 0x4000>;
 				interrupts = <96>;
 				clocks = <&clks 50>;
+				dmas = <&sdma 46 0 0>,
+				       <&sdma 47 0 0>;
+				dma-names = "rx", "tx";
 				fsl,fifo-depth = <15>;
 				fsl,ssi-dma-events = <47 46 45 44>; /* TX0 RX0 TX1 RX1 */
 				status = "disabled";
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 7c18fa0..bc4ca03 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -211,6 +211,9 @@
 					reg = <0x02028000 0x4000>;
 					interrupts = <0 46 0x04>;
 					clocks = <&clks 178>;
+					dmas = <&sdma 37 1 0>,
+					       <&sdma 38 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
 					fsl,ssi-dma-events = <38 37>;
 					status = "disabled";
@@ -221,6 +224,9 @@
 					reg = <0x0202c000 0x4000>;
 					interrupts = <0 47 0x04>;
 					clocks = <&clks 179>;
+					dmas = <&sdma 41 1 0>,
+					       <&sdma 42 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
 					fsl,ssi-dma-events = <42 41>;
 					status = "disabled";
@@ -231,6 +237,9 @@
 					reg = <0x02030000 0x4000>;
 					interrupts = <0 48 0x04>;
 					clocks = <&clks 180>;
+					dmas = <&sdma 45 1 0>,
+					       <&sdma 46 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
 					fsl,ssi-dma-events = <46 45>;
 					status = "disabled";
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index d048a78..c46651e 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -195,6 +195,9 @@
 					reg = <0x02028000 0x4000>;
 					interrupts = <0 46 0x04>;
 					clocks = <&clks IMX6SL_CLK_SSI1>;
+					dmas = <&sdma 37 1 0>,
+					       <&sdma 38 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
 					status = "disabled";
 				};
@@ -204,6 +207,9 @@
 					reg = <0x0202c000 0x4000>;
 					interrupts = <0 47 0x04>;
 					clocks = <&clks IMX6SL_CLK_SSI2>;
+					dmas = <&sdma 41 1 0>,
+					       <&sdma 42 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
 					status = "disabled";
 				};
@@ -213,6 +219,9 @@
 					reg = <0x02030000 0x4000>;
 					interrupts = <0 48 0x04>;
 					clocks = <&clks IMX6SL_CLK_SSI3>;
+					dmas = <&sdma 45 1 0>,
+					       <&sdma 46 1 0>;
+					dma-names = "rx", "tx";
 					fsl,fifo-depth = <15>;
 					status = "disabled";
 				};
-- 
1.7.9.5




From Baohua.Song at csr.com  Wed Jul 17 02:12:14 2013
From: Baohua.Song at csr.com (Barry Song)
Date: Wed, 17 Jul 2013 14:12:14 +0800
Subject: [PATCH 1/3] ASoC: bt-sco: enable OF support
Message-ID: <1374041536-27643-1-git-send-email-Baohua.Song@csr.com>

From: Rongjun Ying <Rongjun.Ying at csr.com>

this makes users be able to add a bt-sco node in dts instead of
hardcoding a platform device in mach.

Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 sound/soc/codecs/bt-sco.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/sound/soc/codecs/bt-sco.c b/sound/soc/codecs/bt-sco.c
index a081d9f..39e7ebe 100644
--- a/sound/soc/codecs/bt-sco.c
+++ b/sound/soc/codecs/bt-sco.c
@@ -46,6 +46,14 @@ static int bt_sco_remove(struct platform_device *pdev)
 	return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id bt_sco_of_match[] = {
+	{ .compatible = "bt-sco-codec", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, bt_sco_of_match);
+#endif
+
 static struct platform_device_id bt_sco_driver_ids[] = {
 	{
 		.name		= "dfbmcs320",
@@ -58,6 +66,9 @@ static struct platform_driver bt_sco_driver = {
 	.driver = {
 		.name = "bt-sco",
 		.owner = THIS_MODULE,
+#ifdef CONFIG_OF
+		.of_match_table = bt_sco_of_match,
+#endif
 	},
 	.probe = bt_sco_probe,
 	.remove = bt_sco_remove,
-- 
1.8.2.3



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog


From Baohua.Song at csr.com  Wed Jul 17 02:12:16 2013
From: Baohua.Song at csr.com (Barry Song)
Date: Wed, 17 Jul 2013 14:12:16 +0800
Subject: [PATCH 3/3] ASoC: hdmi-codec: let the driver support HDMI sink
In-Reply-To: <1374041536-27643-1-git-send-email-Baohua.Song@csr.com>
References: <1374041536-27643-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <1374041536-27643-3-git-send-email-Baohua.Song@csr.com>

From: Rongjun Ying <Rongjun.Ying at csr.com>

Devices like mobilephones, computers are typically used as
HDMI sources, but devices like TV, navigators will be HDMI
sinks.

for auto scenerios, In-Vehicle Infotainment(IVI) can be HDMI
sink to display movies from mobilephones.

Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 sound/soc/codecs/hdmi.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/sound/soc/codecs/hdmi.c b/sound/soc/codecs/hdmi.c
index 78c7b15..0fdcaf9 100644
--- a/sound/soc/codecs/hdmi.c
+++ b/sound/soc/codecs/hdmi.c
@@ -37,6 +37,17 @@ static struct snd_soc_dai_driver hdmi_codec_dai = {
 		.formats = SNDRV_PCM_FMTBIT_S16_LE |
 			SNDRV_PCM_FMTBIT_S24_LE,
 	},
+	.capture = {
+		.channels_min = 2,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_32000 |
+			SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 |
+			SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000 |
+			SNDRV_PCM_RATE_176400 | SNDRV_PCM_RATE_192000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE |
+			SNDRV_PCM_FMTBIT_S24_LE,
+	},
+
 };
 
 static int hdmi_codec_probe(struct platform_device *pdev)
-- 
1.8.2.3



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog


From Baohua.Song at csr.com  Wed Jul 17 02:12:15 2013
From: Baohua.Song at csr.com (Barry Song)
Date: Wed, 17 Jul 2013 14:12:15 +0800
Subject: [PATCH 2/3] ASoC: hdmi-codec: enable OF support
In-Reply-To: <1374041536-27643-1-git-send-email-Baohua.Song@csr.com>
References: <1374041536-27643-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <1374041536-27643-2-git-send-email-Baohua.Song@csr.com>

From: Rongjun Ying <Rongjun.Ying at csr.com>

this makes users be able to add a hdmi-codec node in dts instead of
hardcoding a platform device in mach.

Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 sound/soc/codecs/hdmi.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/sound/soc/codecs/hdmi.c b/sound/soc/codecs/hdmi.c
index 2bcae2b..78c7b15 100644
--- a/sound/soc/codecs/hdmi.c
+++ b/sound/soc/codecs/hdmi.c
@@ -51,10 +51,21 @@ static int hdmi_codec_remove(struct platform_device *pdev)
 	return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id hdmi_audio_codec_ids[] = {
+	{ .compatible = "hdmi-audio-codec", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, hdmi_audio_codec_ids);
+#endif
+
 static struct platform_driver hdmi_codec_driver = {
 	.driver		= {
 		.name	= DRV_NAME,
 		.owner	= THIS_MODULE,
+#ifdef CONFIG_OF
+		.of_match_table = hdmi_audio_codec_ids,
+#endif
 	},
 
 	.probe		= hdmi_codec_probe,
-- 
1.8.2.3



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog


From josephl at nvidia.com  Wed Jul 17 02:19:14 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 17 Jul 2013 14:19:14 +0800
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <51E53858.6090207@linaro.org>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E53858.6090207@linaro.org>
Message-ID: <1374041954.10997.1.camel@jlo-ubuntu-64.nvidia.com>

On Tue, 2013-07-16 at 20:11 +0800, Daniel Lezcano wrote:
> On 07/16/2013 01:17 PM, Joseph Lo wrote:
> > On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
> >> On 06/25/2013 03:23 AM, Joseph Lo wrote:
> >>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
> >>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
> >>> this state.
> >>
> >> I tried applying this patch, your series "[PATCH V3 0/3] ARM: tegra114:
> >> cpuidle: add power down state", and your series "[PATCH V2 00/11] ARM:
> >> tegra114: add support for system suspend", all on top of v3.11-rc1.
> >>
> >> On Dalmore, the new cpuidle mode /appears/ to work (I see increasing
> >> values in the sysfs cpuidle "usage" file for all defined cpuidle
> >> states), but I don't see the "CPU VDD off" LED light up; I'm not
> >> convinced that the CPU is actually being powered off in the idle mode.
> >>
> > The LED of the CPU Vdd indicates the power of CPU cluster. But the
> > series of CPU idle power down mode support for Tegra114 only supports
> > per core power down. It did not support cluster power down yet in idle
> > mode. That needs some extra work to support cluster power down in idle
> > mode.
> > There are some items that I plat to do:
> > 1. integrate the MCPM (multi cluster power management) code into Tegra
> > CPU PM code
> 
> +1
> 
> > 2. integrate coupled CPUidle framework into Tegra CPU idle driver
> 
> If you are using the MCPM, I suggest you rely on the MCPM to replace the
> coupled idle state by it. The code will look much more consistent.
> 
Yes, true. Thanks for your advise.

Joseph



From baruch at tkos.co.il  Wed Jul 17 02:19:25 2013
From: baruch at tkos.co.il (Baruch Siach)
Date: Wed, 17 Jul 2013 09:19:25 +0300
Subject: sched_clock always 0 and no process time accounting with 3.11-rc1
In-Reply-To: <CAMo8BfLO31GgMMA_hENr0xm=qaUz3EVLtaQ8hewiQHdbV+s6sA@mail.gmail.com>
References: <CAMo8BfLO31GgMMA_hENr0xm=qaUz3EVLtaQ8hewiQHdbV+s6sA@mail.gmail.com>
Message-ID: <20130717061925.GC6950@tarshish>

Hi Max,

On Mon, Jul 15, 2013 at 06:18:33PM +0400, Max Filippov wrote:
> with 3.11-rc1 printk timestamps are always zero (which means that
> sched_clock is always 0) and process time accounting always shows
> 0 for system/user time. I see it regardless of HZ_PERIODIC/NO_HZ_IDLE
> and HIGH_RES_TIMERS settings. Am I missing any necessary config
> options? Can you see the same issue?

The following patch fixes the issue for me:

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index a326f27..0b479a6 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -121,7 +121,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
 	BUG_ON(bits > 32);
 	WARN_ON(!irqs_disabled());
 	read_sched_clock = read;
-	sched_clock_mask = (1 << bits) - 1;
+	sched_clock_mask = (1ULL << bits) - 1;
 	cd.rate = rate;
 
 	/* calculate the mult/shift to convert counter ticks to ns. */

Apparently the expression '(1 << 32)' evaluates to 1 on xtensa cross gcc, and 
x86_84 native gcc. According to my limited understanding, the C compiler is 
allowed to do so. This caused sched_clock_32() to return constant 0. I wonder 
how it didn't bite the ARM people who are using this code from quite some time 
(added LAKL to CC).

If this patch proves correct I'll send a formal patch to the timekeeping 
maintainers.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -


From gregkh at linuxfoundation.org  Wed Jul 17 02:29:44 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 16 Jul 2013 23:29:44 -0700
Subject: [PATCH v9 1/8] drivers: phy: add generic PHY framework
In-Reply-To: <1372247257-30186-2-git-send-email-kishon@ti.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <1372247257-30186-2-git-send-email-kishon@ti.com>
Message-ID: <20130717062944.GA24968@kroah.com>

On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
> +menuconfig GENERIC_PHY
> +	tristate "PHY Subsystem"
> +	help
> +	  Generic PHY support.
> +
> +	  This framework is designed to provide a generic interface for PHY
> +	  devices present in the kernel. This layer will have the generic
> +	  API by which phy drivers can create PHY using the phy framework and
> +	  phy users can obtain reference to the PHY.

Shouldn't this be something that other drivers select?  How will anyone
know if they need this or not?

> --- /dev/null
> +++ b/drivers/phy/phy-core.c
> @@ -0,0 +1,544 @@
> +/*
> + * phy-core.c  --  Generic Phy framework.
> + *
> + * Copyright (C) 2013 Texas Instruments
> + *
> + * Author: Kishon Vijay Abraham I <kishon at ti.com>
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.

You really mean "any later version" (I have to ask)?

> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.

Are these two paragraphs needed?  This isn't a "program", and they got a
copy of the GPL already with the kernel.

> +static struct class *phy_class;

Why do you need a class?

When modifying/adding new sysfs stuff, you need a Documentation/ABI/
entry as well.

thanks,

greg k-h


From tony at atomide.com  Wed Jul 17 02:31:44 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 16 Jul 2013 23:31:44 -0700
Subject: [PATCH 1/4] pinctrl: Remove duplicate code in
 pinctrl_pm_select_state functions
In-Reply-To: <51E557D1.4000707@ti.com>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090529.5541.54331.stgit@localhost>
 <51E5475B.1050900@ti.com> <20130716134118.GC7656@atomide.com>
 <51E557D1.4000707@ti.com>
Message-ID: <20130717063144.GE7656@atomide.com>

* Grygorii Strashko <grygorii.strashko at ti.com> [130716 07:32]:
> Hi Tony,
> 
> On 07/16/2013 04:41 PM, Tony Lindgren wrote:
> >* Grygorii Strashko <grygorii.strashko at ti.com> [130716 06:22]:
> >>Hi Tony,
> >>
> >>This patch causes boot failure when I've applied my patch
> >>"[RFC] ARM: OMAP2+: omap_device: add pinctrl handling"
> >>https://lkml.org/lkml/2013/6/21/309
> >>
> >>on top of it:
> >
> >Hmm this patch alone removes duplicate code and if it causes
> >issues I must have made a typo somewhere.
> 
> No typo :) You've removed the check for !dev-pins.

Oh OK, sorry that was not intentional.

> And the failure place is:
> int pinctrl_pm_select_active_state(struct device *dev)
> {
>    return pinctrl_pm_select_state(dev, dev->pins->active_state);
>                                                 ^^^^ here
> }
> 
> If I understand everything right, the pinctrl support in Device core
> assumed to be optional - so, It's valid case, when there are no
> definition for device's pinctrl in DT at all.
> 
> And in this case dev->pins == NULL and  pinctrl_pm_select_*() API
> should return 0 always.

Care to post your patch as it sounds like you have it fixed
and tested?

Regards,

Tony


From gerlando.falauto at keymile.com  Wed Jul 17 02:35:38 2013
From: gerlando.falauto at keymile.com (Gerlando Falauto)
Date: Wed, 17 Jul 2013 08:35:38 +0200
Subject: [PATCH] ARM: Kirkwood: Fix the internal register ranges
 translation
In-Reply-To: <20130716125531.GD2317@localhost>
References: <1371569479-31498-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <51E5145A.90404@keymile.com> <20130716125531.GD2317@localhost>
Message-ID: <51E63B3A.2010807@keymile.com>

Hi Ezequiel,

On 07/16/2013 02:56 PM, Ezequiel Garcia wrote:
[...]
> Also, speaking of "device bus" this nand node should be behind a devicebus node.
>
> 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000   /* internal-regs */
> 			  MBUS_ID(0x01, 0x2f) 0 0 0xf4000000 0x400>;
>
> 		devbus {
> 			status = "okay";
> 			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x400>;
>
> 			/* nand */
> 			nand {
> 				compatible = "marvell,orion-nand";
> 				reg = <0 0x400>;
> 			};
> 		};
>
> (notice this will allow you to relocate the base address of the NAND windows
> easily if it conflicts with your PCIe needs).

I am MAYBE slowly starting to understand this whole mbus rework.
Just one remark though: don't you think it would make sense to add 
something like:

#define MBUS_ID_INTERNAL_REGS	MBUS_ID(0xf0, 0x01)
#define MBUS_ID_NAND		MBUS_ID(0x01, 0x2f)

I personally have a hard time reading numeric values for 
GPIO_ACTIVE_LOW/GPIO_ACTIVE_HIGH.

Thanks,
Gerlando

>
>> avoid a later incosistency between the "unit-address" and the first
>> "reg" address:
>>
>>>    		#address-cells = <1>;
>>>    		#size-cells = <1>;
>>> @@ -171,7 +172,7 @@
>>   >   		nand at 3000000 {
>> 		     ^^^^^^^
>
> Oh, this should be fixed. I just missed it, and nobody noticed either.
>



From jcmvbkbc at gmail.com  Wed Jul 17 02:39:51 2013
From: jcmvbkbc at gmail.com (Max Filippov)
Date: Wed, 17 Jul 2013 10:39:51 +0400
Subject: sched_clock always 0 and no process time accounting with 3.11-rc1
In-Reply-To: <20130717061925.GC6950@tarshish>
References: <CAMo8BfLO31GgMMA_hENr0xm=qaUz3EVLtaQ8hewiQHdbV+s6sA@mail.gmail.com>
 <20130717061925.GC6950@tarshish>
Message-ID: <CAMo8Bf+UY2Lj=7=Y2AxeUfM3LqJkbQqPviH81PEjwo8irtiGJg@mail.gmail.com>

On Wed, Jul 17, 2013 at 10:19 AM, Baruch Siach <baruch at tkos.co.il> wrote:
> Hi Max,
>
> On Mon, Jul 15, 2013 at 06:18:33PM +0400, Max Filippov wrote:
>> with 3.11-rc1 printk timestamps are always zero (which means that
>> sched_clock is always 0) and process time accounting always shows
>> 0 for system/user time. I see it regardless of HZ_PERIODIC/NO_HZ_IDLE
>> and HIGH_RES_TIMERS settings. Am I missing any necessary config
>> options? Can you see the same issue?
>
> The following patch fixes the issue for me:
>
> diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
> index a326f27..0b479a6 100644
> --- a/kernel/time/sched_clock.c
> +++ b/kernel/time/sched_clock.c
> @@ -121,7 +121,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
>         BUG_ON(bits > 32);
>         WARN_ON(!irqs_disabled());
>         read_sched_clock = read;
> -       sched_clock_mask = (1 << bits) - 1;
> +       sched_clock_mask = (1ULL << bits) - 1;
>         cd.rate = rate;
>
>         /* calculate the mult/shift to convert counter ticks to ns. */
>
> Apparently the expression '(1 << 32)' evaluates to 1 on xtensa cross gcc, and
> x86_84 native gcc. According to my limited understanding, the C compiler is
> allowed to do so. This caused sched_clock_32() to return constant 0. I wonder
> how it didn't bite the ARM people who are using this code from quite some time
> (added LAKL to CC).

Cool, it works now, thanks Baruch.
According to C99 the behaviour of (1 << 32) is undefined on platforms with
32 bit int, so it could yield any value.

> If this patch proves correct I'll send a formal patch to the timekeeping
> maintainers.

-- 
Thanks.
-- Max


From baruch at tkos.co.il  Wed Jul 17 02:47:09 2013
From: baruch at tkos.co.il (Baruch Siach)
Date: Wed, 17 Jul 2013 09:47:09 +0300
Subject: [Linux-Xtensa] Re: sched_clock always 0 and no process time
 accounting with 3.11-rc1
In-Reply-To: <CAMo8Bf+UY2Lj=7=Y2AxeUfM3LqJkbQqPviH81PEjwo8irtiGJg@mail.gmail.com>
References: <CAMo8BfLO31GgMMA_hENr0xm=qaUz3EVLtaQ8hewiQHdbV+s6sA@mail.gmail.com>
 <20130717061925.GC6950@tarshish>
 <CAMo8Bf+UY2Lj=7=Y2AxeUfM3LqJkbQqPviH81PEjwo8irtiGJg@mail.gmail.com>
Message-ID: <20130717064709.GD6950@tarshish>

Hi Max,

On Wed, Jul 17, 2013 at 10:39:51AM +0400, Max Filippov wrote:
> On Wed, Jul 17, 2013 at 10:19 AM, Baruch Siach <baruch at tkos.co.il> wrote:
> > On Mon, Jul 15, 2013 at 06:18:33PM +0400, Max Filippov wrote:
> >> with 3.11-rc1 printk timestamps are always zero (which means that
> >> sched_clock is always 0) and process time accounting always shows
> >> 0 for system/user time. I see it regardless of HZ_PERIODIC/NO_HZ_IDLE
> >> and HIGH_RES_TIMERS settings. Am I missing any necessary config
> >> options? Can you see the same issue?
> >
> > The following patch fixes the issue for me:
> >
> > diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
> > index a326f27..0b479a6 100644
> > --- a/kernel/time/sched_clock.c
> > +++ b/kernel/time/sched_clock.c
> > @@ -121,7 +121,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
> >         BUG_ON(bits > 32);
> >         WARN_ON(!irqs_disabled());
> >         read_sched_clock = read;
> > -       sched_clock_mask = (1 << bits) - 1;
> > +       sched_clock_mask = (1ULL << bits) - 1;
> >         cd.rate = rate;
> >
> >         /* calculate the mult/shift to convert counter ticks to ns. */
> >
> > Apparently the expression '(1 << 32)' evaluates to 1 on xtensa cross gcc, and
> > x86_64 native gcc. According to my limited understanding, the C compiler is
> > allowed to do so. This caused sched_clock_32() to return constant 0. I wonder
> > how it didn't bite the ARM people who are using this code from quite some time
> > (added LAKL to CC).
> 
> Cool, it works now, thanks Baruch.

Thanks for testing.

> According to C99 the behaviour of (1 << 32) is undefined on platforms with
> 32 bit int, so it could yield any value.

But so is ARM, isn't it?

> > If this patch proves correct I'll send a formal patch to the timekeeping
> > maintainers.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -


From koba at kmckk.co.jp  Wed Jul 17 02:48:29 2013
From: koba at kmckk.co.jp (Tetsuyuki Kobayashi)
Date: Wed, 17 Jul 2013 15:48:29 +0900
Subject: [PATCH] ARM: bugfix: Features of /proc/cpuinfo is wrong
Message-ID: <1374043709-24770-1-git-send-email-koba@kmckk.co.jp>

Array hwcap_str[19] should be "vfpd32" and hwcap_str[20] should be "lpae".
But actually "vfpd32" was missing and "lpae" was at wrong place.

Signed-off-by: Tetsuyuki Kobayashi <koba at kmckk.co.jp>
---
Hello, 

The output of features string of /proc/cpuinfo is changed at v3.11-rc1.
In case of KZM-A9-GT board, which cpu is ARM Corex-A9
$ grep Features /proc/cpuinfo

Features	: swp half thumb fastmult vfp edsp neon vfpv3 tls lpae 

This is wrong. Cortex-A9 does not have lpae (Large Physical Address Extension).

I tried git bisect and found this commit is related.

a469abd0f868c902b75532579bf87553dcf1b360
 ARM: elf: add new hwcap for identifying atomic ldrd/strd instructions

Variable elf_hwcap = 0x0008b0d7. This seems good.
HWCAP_LPAE (1 << 20) is not set in elf_hwcap.
Finally I found "lpae" string was wrong place in the array hwcap_str[].
hwcap_str[19] should be "vfpd32" and hwcap_str[20] should be "lpae".
But actually "vfpd32" was missing and "lpae" was at wrong place.

After this patch, features of /proc/cpuinfo of the same board is

Features	: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 

I tested only in Cortex-A9.
Someone, please test on Cortex-A15 or A7. "lpae" should be appeared.


 arch/arm/kernel/setup.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 63af9a7..96286cb 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -971,6 +971,7 @@ static const char *hwcap_str[] = {
 	"vfpv4",
 	"idiva",
 	"idivt",
+	"vfpd32",
 	"lpae",
 	NULL
 };
-- 
1.7.9.5



From chris at zankel.net  Wed Jul 17 03:02:10 2013
From: chris at zankel.net (Chris Zankel)
Date: Wed, 17 Jul 2013 00:02:10 -0700
Subject: [Linux-Xtensa] Re: sched_clock always 0 and no process time
 accounting with 3.11-rc1
In-Reply-To: <20130717064709.GD6950@tarshish>
References: <CAMo8BfLO31GgMMA_hENr0xm=qaUz3EVLtaQ8hewiQHdbV+s6sA@mail.gmail.com>
 <20130717061925.GC6950@tarshish>
 <CAMo8Bf+UY2Lj=7=Y2AxeUfM3LqJkbQqPviH81PEjwo8irtiGJg@mail.gmail.com>
 <20130717064709.GD6950@tarshish>
Message-ID: <51E64172.9050808@zankel.net>

On 07/16/2013 11:47 PM, Baruch Siach wrote:
>> According to C99 the behaviour of (1 << 32) is undefined on platforms with
>> 32 bit int, so it could yield any value.
> But so is ARM, isn't it?

The handling of constants might be target-architecture dependent.

On a somewhat related issue, are you using a 32-bit host or 64-bit host?
Note that 64-bit cross compilation is known to be broken for Xtensa, I
had a problem running glibc when compiled with cross compiler on a
64-bit host.

Cheers!
-Chris


From rnayak at ti.com  Wed Jul 17 03:10:39 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Wed, 17 Jul 2013 12:40:39 +0530
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
In-Reply-To: <51E51FF6.60608@ti.com>
References: <20130705115959.GQ5523@atomide.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94489@DBDE04.ent.ti.com>
 <B5906170F1614E41A8A28DE3B8D121433EE94520@DBDE04.ent.ti.com>
 <20130708112553.GU5523@atomide.com> <51DAB394.3050104@ti.com>
 <20130708131033.GA5523@atomide.com> <51DABC81.3080409@ti.com>
 <20130708133512.GD31221@arwen.pp.htv.fi> <87mwpuakod.fsf@linaro.org>
 <20130710142633.GV5523@atomide.com> <20130710160704.GH18966@arwen.pp.htv.fi>
 <51DE780C.2070701@ti.com> <51E51FF6.60608@ti.com>
Message-ID: <51E6436F.5010301@ti.com>

On Tuesday 16 July 2013 03:57 PM, Grygorii Strashko wrote:
> Hi Rajendra,
> 
> On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
>> On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
>>> how about something like below ? It makes omap_device/hwmod and
>>> pm_runtime agree on the initial state of the device and will prevent
>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>> during probe.
>>>
>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>
>> I tried something similar [1] but what I found is that the serial
>> runtime resume was called despite it being marked as active using
>> pm_runtime_set_active().
>>
>> That seems to be because of the pm_runtime_set_autosuspend_delay()
>> because we have the autosuspend_delay = -1
>>
>> -----
>> static void update_autosuspend(struct device *dev, int old_delay, int old_use)
>> {
>>          int delay = dev->power.autosuspend_delay;
>>
>>          /* Should runtime suspend be prevented now? */
>>          if (dev->power.use_autosuspend && delay < 0) {
>>
>>                  /* If it used to be allowed then prevent it. */
>>                  if (!old_use || old_delay >= 0) {
>>                          atomic_inc(&dev->power.usage_count);
>>                          rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
>>                  }
>>          }
>> -----
>>
>> So we end up with the same issue with serial resume being called before set_termios()
>>
>> [1]
>>
>> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
>> index 5cc9287..c71d47d 100644
>> --- a/arch/arm/mach-omap2/omap_device.c
>> +++ b/arch/arm/mach-omap2/omap_device.c
>> @@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>>          struct device_node *node = pdev->dev.of_node;
>>          const char *oh_name;
>>          int oh_cnt, i, ret = 0;
>> +       bool device_active = false;
>>
>>          oh_cnt = of_property_count_strings(node, "ti,hwmods");
>>          if (oh_cnt <= 0) {
>> @@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>>                          goto odbfd_exit1;
>>                  }
>>                  hwmods[i] = oh;
>> +               if (oh->flags & HWMOD_INIT_NO_IDLE)
>> +                       device_active = true;
>> +
>>          }
>>
>>          od = omap_device_alloc(pdev, hwmods, oh_cnt);
>> @@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>>
>>          pdev->dev.pm_domain = &omap_device_pm_domain;
>>
>> +       if (device_active) {
>> +               omap_device_enable(pdev);
>> +               pm_runtime_set_active(&pdev->dev);
>> +       }
>> +
>>   odbfd_exit1:
>>          kfree(hwmods);
>>   odbfd_exit:
> 
> This solution works good for me in combination with
> "serial: omap: enable PM runtime only when its fully configured"
> http://www.spinics.net/lists/linux-serial/msg10317.html
> (earlyprintk use case)
> 
> And I think the best way would be to move forward with yours solution.
> - it will affect only on needed IPs drivers - not on all, so no issues with iommu and etc.

Ok, good to know that this solution works. Anyone has any other thoughts on whats the best
way to fix this for the -rcs? (Note that we have bootup broken on all OMAPs with DEBUG_LL
for now, atleast for all DT only platforms)

The other option of course is to use the patch posted by Felipe [1], thought that had issues
handling processor IPs as pointed out by Grygorii and Suman [2], the fix I posted [3] to make
omap_device aware of hwmod bypassing these IPs might fix some of those, but this solution in
general would need more testing as it affects all modules on the bus.

[1] http://www.spinics.net/lists/arm-kernel/msg258062.html
[2] http://www.spinics.net/lists/arm-kernel/msg258061.html
[3] http://www.spinics.net/lists/arm-kernel/msg258465.html

> 
> But issue with *non console" UARTs will still be here and, I think,
> there are no way ti solve it from OMAP device/hwmod frameworks side,
> because only driver can know when his context is ready.
> To test do: #echo 0xDEAD > dev/ttyO3
> 
> Regards,
> -grygorii



From baruch at tkos.co.il  Wed Jul 17 03:14:06 2013
From: baruch at tkos.co.il (Baruch Siach)
Date: Wed, 17 Jul 2013 10:14:06 +0300
Subject: [Linux-Xtensa] Re: sched_clock always 0 and no process time
 accounting with 3.11-rc1
In-Reply-To: <51E64172.9050808@zankel.net>
References: <CAMo8BfLO31GgMMA_hENr0xm=qaUz3EVLtaQ8hewiQHdbV+s6sA@mail.gmail.com>
 <20130717061925.GC6950@tarshish>
 <CAMo8Bf+UY2Lj=7=Y2AxeUfM3LqJkbQqPviH81PEjwo8irtiGJg@mail.gmail.com>
 <20130717064709.GD6950@tarshish> <51E64172.9050808@zankel.net>
Message-ID: <20130717071406.GE6950@tarshish>

Hi Chris,

On Wed, Jul 17, 2013 at 12:02:10AM -0700, Chris Zankel wrote:
> On 07/16/2013 11:47 PM, Baruch Siach wrote:
> >> According to C99 the behaviour of (1 << 32) is undefined on platforms with
> >> 32 bit int, so it could yield any value.
> > But so is ARM, isn't it?
> 
> The handling of constants might be target-architecture dependent.
> 
> On a somewhat related issue, are you using a 32-bit host or 64-bit host?
> Note that 64-bit cross compilation is known to be broken for Xtensa, I
> had a problem running glibc when compiled with cross compiler on a
> 64-bit host.

Yes, my host is x86_64. I haven't encountered any problem yet. But thanks for 
the warning, I'll keep that in mind. I think it's worth a mention in the 
linux-xtensa wiki. It surly worth a fix as well, I guess. Are there any 
samples of code that are known to be break with 64 bit host?

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -


From p.zabel at pengutronix.de  Wed Jul 17 03:17:04 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Wed, 17 Jul 2013 09:17:04 +0200
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <51E56AF6.30506@wwwdotorg.org>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <20130716065130.GB30067@S2101-09.ap.freescale.net>
 <51E56AF6.30506@wwwdotorg.org>
Message-ID: <1374045424.4350.5.camel@pizza.hi.pengutronix.de>

Am Dienstag, den 16.07.2013, 09:47 -0600 schrieb Stephen Warren:
> On 07/16/2013 12:51 AM, Shawn Guo wrote:
> > On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote:
> >> Hi Philipp,
> >>
> >> On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
> >>> This driver implements a reset controller device that toggle a gpio
> >>> connected to a reset pin of a peripheral IC. The delay between assertion
> >>> and de-assertion of the reset signal can be configured via device tree.
> >>>
> >>> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> >>> Reviewed-by: Stephen Warren <swarren at nvidia.com>
> >>
> >> I see this patch is very useful, as GPIOs are widely used to reset
> >> components/devices on board.  But I do not find the patch in v3.11-rc1.
> >> What's your plan about it?
> >>
> >> Also, I'm wondering if we should register the driver a little bit
> >> early.  Please see the following patch.  If it makes sense to you,
> >> I can send the patch to you, or you can just quash it into yours.
> > 
> > And here is another change request.
> 
> > diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
> 
> > -	gpio_set_value(drvdata->gpio, value);
> > +	if (gpio_cansleep(drvdata->gpio))
> > +		gpio_set_value_cansleep(drvdata->gpio, value);
> > +	else
> > +		gpio_set_value(drvdata->gpio, value);
> 
> That's not right. Calling gpio_set_value() v.s.
> gpio_set_value_cansleep() should be based on the properties of the
> calling context, not the GPIO being controlled. In other words, if it's
> permissible to call gpio_set_value_cansleep() at this point in the code,
> simply always call that, and remove the conditional logic.

In which case I'd say let's just call the _cansleep variant here
unconditionally and declare that reset_control_assert/deassert() may
sleep, just as reset_control_reset() has to anyway.

regards
Philipp



From b32955 at freescale.com  Wed Jul 17 03:28:48 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 17 Jul 2013 15:28:48 +0800
Subject: [PATCH v2] serial: imx: remove the uart_console() check
In-Reply-To: <20130701160833.GC14172@S2101-09.ap.freescale.net>
References: <1372397982-19017-1-git-send-email-b32955@freescale.com>
 <20130701160833.GC14172@S2101-09.ap.freescale.net>
Message-ID: <51E647B0.7010509@freescale.com>

? 2013?07?02? 00:08, Shawn Guo ??:
> On Fri, Jun 28, 2013 at 01:39:42PM +0800, Huang Shijie wrote:
>> The uart_console() check makes the clocks(clk_per and clk_ipg) opened
>> even when we close the console uart.
>>
>> This patch enable/disable the clocks in imx_console_write(),
>> so we can keep the clocks closed when the console uart is closed.
>>
>> Also remove the clock enable/disable oprations in the probe, we do not
>> need them any more.
>>
>> Signed-off-by: Huang Shijie<b32955 at freescale.com>
> Acked-by: Shawn Guo<shawn.guo at linaro.org>
Hi Greg:
could you merge this patch?

thanks
Huang Shijie



From b32955 at freescale.com  Wed Jul 17 03:30:12 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 17 Jul 2013 15:30:12 +0800
Subject: [PATCH v4 0/6] serial: imx: add DMA support for imx6
In-Reply-To: <1373274862-2695-1-git-send-email-b32955@freescale.com>
References: <1373274862-2695-1-git-send-email-b32955@freescale.com>
Message-ID: <51E64804.4080902@freescale.com>

? 2013?07?08? 17:14, Huang Shijie ??:
> (1) This patch set adds the DMA support for the imx serial driver.
>     The uart with the dma support is usually used by the Bluetooth.
>
>     For the firmware's limit, i only enable the DMA for imx6 serials.
>     If we have proper firmware for imx53 (or other chips), we can also
>     enable the DMA for it.
>
> (2) We only enable the DMA support when the following are meet:
>
>     [1] The uart port supports the hardware flow control(CTS/RTS).
>       (Some uart port does not support the CTS/RTS.)
>
>     [2] The application enables the CTS/RTS.
>
>     [3] The Soc is imx6 serials.
>       For the sdma's firmware limit, we do not support the DMA except
>       the imx6 platform.
>
>     [4] The uart is not used as a console.
>
>
> (3) Tested this patch set by:
> 	connecting a imx6q-arm2 board(DTE) with a imx53 board(DCE).
>
> v3 --> v4:
> 	[0] add DTE pad for uart2
>
> v2 --> v3:
> 	[0] add a new patch to fix the RTS/CTS pad name issue.
> 	[1] rename the uart DTE pinctrl, remove the "dte" from the pinctrl.
> 	[2] add a similar UART DTE pinctrl for IMX6DL.
> 	[3] move the "fsl,imx6q-uart" to the first of the compatible table.
>
> v1 --> v2:
> 	[0] use the "fsl,imx6q-uart" as the new compatible value.
> 	[1] move dma_is_inited to imx_uart_dma_init();
> 	    move dma_is_enabled to imx_enable_dma();
> 	[2] move imx_disable_dma() to the front place of the imx_shutdown(),
> 	    just before calls the imx_uart_dma_exit().
> 	[3] misc    
> 	
>
> Huang Shijie (6):
>   serial: imx: distinguish the imx6q uart from the others
>   serial: imx: add DMA support for imx6q 
Hi Greg:
Could you merge the two patches as above?


thanks
Huang Shijie



From b32955 at freescale.com  Wed Jul 17 03:33:22 2013
From: b32955 at freescale.com (Huang Shijie)
Date: Wed, 17 Jul 2013 15:33:22 +0800
Subject: [PATCH v2 2/3] serial: mxs: enable the DMA only when the RTS/CTS
 is valid
In-Reply-To: <20130716095449.GS12139@pengutronix.de>
References: <1373957732-16638-1-git-send-email-b32955@freescale.com>
 <1373957732-16638-3-git-send-email-b32955@freescale.com>
 <20130716095449.GS12139@pengutronix.de>
Message-ID: <51E648C2.3010304@freescale.com>

? 2013?07?16? 17:54, Uwe Kleine-K?nig ??:
> On Tue, Jul 16, 2013 at 02:55:31PM +0800, Huang Shijie wrote:
>> The original DMA support works only when RTS/CTS is enabled.
> What is original here?
>
i will add more information for this in the next version.
>> But after several patches, DMA support has lost this limit.
> This is still misleading.
>
>> This patch adds an optional property for the UART DT node
>> which indicates the UART has RTS and CTS lines.
>>
>> This patch also adds a macro MXS_AUART_RTSCTS, and uses it to check
>> RTS/CTS before we enable the DMA for the UART.
> I still think this should go to stable. The options are:
>
> 	a) also take patch 1 into stable
> 	b) apply this patch without patch 1
>
> I don't know if option a) is OK, b) is probably preferable. And as Greg
to Greg:

I think a) is ok to me. what's your opinion?


> has much to do anyhow, better move this patch first. (Otherwise he will
> probably only say: That patch doesn't apply, please help.)
>
>> Signed-off-by: Huang Shijie<b32955 at freescale.com>
>> ---
>>   .../bindings/tty/serial/fsl-mxs-auart.txt          |    4 ++++
>>   drivers/tty/serial/mxs-auart.c                     |    5 ++++-
>>   2 files changed, 8 insertions(+), 1 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
>> index 2c00ec6..59a40f1 100644
>> --- a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
>> +++ b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
>> @@ -10,6 +10,10 @@ Required properties:
>>     Refer to dma.txt and fsl-mxs-dma.txt for details.
>>   - dma-names: "rx" for RX channel, "tx" for TX channel.
>>
>> +Optional properties:
>> +- fsl,uart-has-rtscts : Indicate the UART has RTS and CTS lines,
>> +	it also means you enable the DMA support for this UART.
>> +
>>   Example:
>>   auart0: serial at 8006a000 {
>>   	compatible = "fsl,imx28-auart", "fsl,imx23-auart";
>> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
>> index 465ef0b..27532fd 100644
>> --- a/drivers/tty/serial/mxs-auart.c
>> +++ b/drivers/tty/serial/mxs-auart.c
>> @@ -134,6 +134,7 @@ enum mxs_auart_type {
>>   struct mxs_auart_port {
>>   	struct uart_port port;
>>
>> +#define MXS_AUART_RTSCTS	1
>>   #define MXS_AUART_DMA_ENABLED	0x2
>>   #define MXS_AUART_DMA_TX_SYNC	2  /* bit 2 */
>>   #define MXS_AUART_DMA_RX_READY	3  /* bit 3 */
>> @@ -639,7 +640,7 @@ static void mxs_auart_settermios(struct uart_port *u,
>>   		 * we can only implement the DMA support for auart
>>   		 * in mx28.
>>   		 */
>> -		if (is_imx28_auart(s)) {
>> +		if (is_imx28_auart(s)&&  (s->flags&  MXS_AUART_RTSCTS)) {
> I thought you wanted to add a comment here. Without knowing the details
>
> 	if (RTSCTS)
> 		enable_dma();
>
ok, no problem.


thanks
Huang Shijie



From nicolas.ferre at atmel.com  Wed Jul 17 03:58:51 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 17 Jul 2013 09:58:51 +0200
Subject: [PATCH 2/5] iio: at91: Use different prescal, startup mask in
 MR for different IP
In-Reply-To: <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
Message-ID: <51E64EBB.30700@atmel.com>

On 14/07/2013 10:04, Josh Wu :
> For at91 boards, there are different IPs for adc. Different IPs has different
> STARTUP & PRESCAL mask in ADC_MR.
>
> This patch can change the masks according to the different IP version.
>
> Signed-off-by: Josh Wu <josh.wu at atmel.com>
> ---
>   arch/arm/mach-at91/include/mach/at91_adc.h |    9 ++++--
>   drivers/iio/adc/at91_adc.c                 |   48 ++++++++++++++++++++++++++--
>   2 files changed, 53 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-at91/include/mach/at91_adc.h b/arch/arm/mach-at91/include/mach/at91_adc.h
> index 8e7ed5c..ab273ee 100644
> --- a/arch/arm/mach-at91/include/mach/at91_adc.h
> +++ b/arch/arm/mach-at91/include/mach/at91_adc.h
> @@ -28,9 +28,12 @@
>   #define			AT91_ADC_TRGSEL_EXTERNAL	(6 << 1)
>   #define		AT91_ADC_LOWRES		(1 << 4)	/* Low Resolution */
>   #define		AT91_ADC_SLEEP		(1 << 5)	/* Sleep Mode */
> -#define		AT91_ADC_PRESCAL	(0x3f << 8)	/* Prescalar Rate Selection */
> +#define		AT91_ADC_PRESCAL	(0xff << 8)	/* Prescalar Rate Selection */
> +#define		AT91_ADC_PRESCAL_9260	(0x3f << 8)
>   #define			AT91_ADC_PRESCAL_(x)	((x) << 8)
> -#define		AT91_ADC_STARTUP	(0x1f << 16)	/* Startup Up Time */
> +#define		AT91_ADC_STARTUP	(0xf << 16)	/* Startup Up Time */

Which product has this kind of startup mask: 0xf? Compared with 9260 and 
9g45 values, it seems strange to me: maybe a little comment should be added.


> +#define		AT91_ADC_STARTUP_9260	(0x1f << 16)
> +#define		AT91_ADC_STARTUP_9G45	(0x7f << 16)
>   #define			AT91_ADC_STARTUP_(x)	((x) << 16)
>   #define		AT91_ADC_SHTIM		(0xf  << 24)	/* Sample & Hold Time */
>   #define			AT91_ADC_SHTIM_(x)	((x) << 24)
> @@ -58,4 +61,6 @@
>   #define AT91_ADC_CHR(n)		(0x30 + ((n) * 4))	/* Channel Data Register N */
>   #define		AT91_ADC_DATA		(0x3ff)
>
> +#define AT91_ADC_VERSION	0xFC
> +
>   #endif
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index 18bd54f..14e99ba 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -39,6 +39,12 @@
>   #define at91_adc_writel(st, reg, val) \
>   	(writel_relaxed(val, st->reg_base + reg))
>
> +struct at91_adc_caps {
> +	bool	has_tsmr;	/* only at91sam9x5, sama5d3 have TSMR reg */
> +	u32	mr_prescal_mask;
> +	u32	mr_startup_mask;
> +};
> +

If we move to DT and compatible string for these values, maybe a 
separate structure won't be needed....


>   struct at91_adc_state {
>   	struct clk		*adc_clk;
>   	u16			*buffer;
> @@ -62,6 +68,7 @@ struct at91_adc_state {
>   	u32			res;		/* resolution used for convertions */
>   	bool			low_res;	/* the resolution corresponds to the lowest one */
>   	wait_queue_head_t	wq_data_avail;
> +	struct at91_adc_caps	caps;
>   };
>
>   static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
> @@ -580,6 +587,41 @@ static const struct iio_info at91_adc_info = {
>   	.read_raw = &at91_adc_read_raw,
>   };
>
> +/*
> + * Since atmel adc support different ip for touchscreen mode. Through the
> + * IP check, we will know the touchscreen capbilities.
> + */
> +static void atmel_adc_get_cap(struct at91_adc_state *st)
> +{
> +	unsigned int version;
> +	struct iio_dev *idev = iio_priv_to_dev(st);
> +
> +	version = at91_adc_readl(st, AT91_ADC_VERSION);
> +	dev_dbg(&idev->dev, "version: 0x%x\n", version);
> +
> +	st->caps.mr_prescal_mask = AT91_ADC_PRESCAL_9260;
> +	st->caps.mr_startup_mask = AT91_ADC_STARTUP_9260;
> +
> +	/* keep only major version number */
> +	switch (version & 0xf00) {
> +	case 0x500:	/* SAMA5D3 */
> +	case 0x400:	/* AT91SAM9X5/9N12 */
> +		st->caps.has_tsmr = 1;
> +		st->caps.mr_startup_mask = AT91_ADC_STARTUP;

Here is where AT91_ADC_STARTUP may need another name: what about 
AT91_ADC_STARTUP_9x5 to match the "compatibility" of this value?


> +	case 0x200:	/* AT91SAM9M10/9G45 */
> +		st->caps.mr_prescal_mask = AT91_ADC_PRESCAL;
> +
> +		if ((version & 0xf00) == 0x200)

Sorry but I do not understand this test in a switch/case entry where it 
should always be true...


> +			st->caps.mr_startup_mask = AT91_ADC_STARTUP_9G45;
> +	case 0x100:	/* AT91SAM9260/9G20 */
> +		break;
> +	default:
> +		dev_warn(&idev->dev,
> +				"Unmanaged adc version, use minimal capabilities\n");
> +		break;
> +	};
> +}
> +
>   static int at91_adc_probe(struct platform_device *pdev)
>   {
>   	unsigned int prsc, mstrclk, ticks, adc_clk, adc_clk_khz, shtim;
> @@ -645,6 +687,8 @@ static int at91_adc_probe(struct platform_device *pdev)
>   		goto error_free_device;
>   	}
>
> +	atmel_adc_get_cap(st);
> +
>   	st->clk = devm_clk_get(&pdev->dev, "adc_clk");
>   	if (IS_ERR(st->clk)) {
>   		dev_err(&pdev->dev, "Failed to get the clock.\n");
> @@ -704,8 +748,8 @@ static int at91_adc_probe(struct platform_device *pdev)
>   	shtim = round_up((st->sample_hold_time * adc_clk_khz /
>   			  1000) - 1, 1);
>
> -	reg = AT91_ADC_PRESCAL_(prsc) & AT91_ADC_PRESCAL;
> -	reg |= AT91_ADC_STARTUP_(ticks) & AT91_ADC_STARTUP;
> +	reg = AT91_ADC_PRESCAL_(prsc) & st->caps.mr_prescal_mask;
> +	reg |= AT91_ADC_STARTUP_(ticks) & st->caps.mr_startup_mask;
>   	if (st->low_res)
>   		reg |= AT91_ADC_LOWRES;
>   	if (st->sleep_mode)
>


-- 
Nicolas Ferre


From jonas.jensen at gmail.com  Wed Jul 17 04:04:57 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 17 Jul 2013 10:04:57 +0200
Subject: [PATCH v9] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <1373985880-23469-1-git-send-email-jonas.jensen@gmail.com>
References: <1373985880-23469-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1374048297-4321-1-git-send-email-jonas.jensen@gmail.com>

This patch adds an clocksource driver for the main timer(s)
found on MOXA ART SoCs.

The MOXA ART SoC provides three separate timers with individual
count/load/match registers, two are used here:

TIMER1: clockevents, used to support oneshot and periodic events
TIMER2: set up as a free running counter, used as clocksource

Timers are preconfigured by bootloader to count down and interrupt
on match or zero. Count increments every APB clock cycle and is
automatically reloaded when it reaches zero.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v8:
    
    1. add devicetree bindings document
    
    Applies to next-20130716

 .../bindings/timer/moxa,moxart-timer.txt           |  17 +++
 drivers/clocksource/Makefile                       |   1 +
 drivers/clocksource/moxart_timer.c                 | 164 +++++++++++++++++++++
 3 files changed, 182 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt
 create mode 100644 drivers/clocksource/moxart_timer.c

diff --git a/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt b/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt
new file mode 100644
index 0000000..77c4cfa
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt
@@ -0,0 +1,17 @@
+MOXA ART timer
+
+Required properties:
+
+- compatible : Should be "moxa,moxart-timer"
+- reg : Should contain registers location and length
+- interrupts : Should contain the timer interrupt number
+- clocks : Should contain phandle for APB clock "clkapb"
+
+Example:
+
+	timer: timer at 98400000 {
+		compatible = "moxa,moxart-timer";
+		reg = <0x98400000 0x42>;
+		interrupts = <19 1>;
+		clocks = <&clkapb>;
+	};
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 8b00c5c..704d6d3 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
 obj-$(CONFIG_ORION_TIMER)	+= time-orion.o
 obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
 obj-$(CONFIG_ARCH_MARCO)	+= timer-marco.o
+obj-$(CONFIG_ARCH_MOXART)	+= moxart_timer.o
 obj-$(CONFIG_ARCH_MXS)		+= mxs_timer.o
 obj-$(CONFIG_ARCH_PRIMA2)	+= timer-prima2.o
 obj-$(CONFIG_SUN4I_TIMER)	+= sun4i_timer.o
diff --git a/drivers/clocksource/moxart_timer.c b/drivers/clocksource/moxart_timer.c
new file mode 100644
index 0000000..08a5943
--- /dev/null
+++ b/drivers/clocksource/moxart_timer.c
@@ -0,0 +1,164 @@
+/*
+ * MOXA ART SoCs timer handling.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqreturn.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/io.h>
+#include <linux/clocksource.h>
+
+#define TIMER1_BASE		0x00
+#define TIMER2_BASE		0x10
+#define TIMER3_BASE		0x20
+
+#define REG_COUNT		0x0 /* writable */
+#define REG_LOAD		0x4
+#define REG_MATCH1		0x8
+#define REG_MATCH2		0xC
+
+#define TIMER_CR		0x30
+#define TIMER_INTR_STATE	0x34
+#define TIMER_INTR_MASK		0x38
+
+/*
+ * TIMER_CR flags:
+ *
+ * TIMEREG_CR_*_CLOCK	0: PCLK, 1: EXT1CLK
+ * TIMEREG_CR_*_INT	overflow interrupt enable bit
+ */
+#define TIMEREG_CR_1_ENABLE	BIT(0)
+#define TIMEREG_CR_1_CLOCK	BIT(1)
+#define TIMEREG_CR_1_INT	BIT(2)
+#define TIMEREG_CR_2_ENABLE	BIT(3)
+#define TIMEREG_CR_2_CLOCK	BIT(4)
+#define TIMEREG_CR_2_INT	BIT(5)
+#define TIMEREG_CR_3_ENABLE	BIT(6)
+#define TIMEREG_CR_3_CLOCK	BIT(7)
+#define TIMEREG_CR_3_INT	BIT(8)
+#define TIMEREG_CR_COUNT_UP	BIT(9)
+
+#define TIMER1_ENABLE		(TIMEREG_CR_2_ENABLE | TIMEREG_CR_1_ENABLE)
+#define TIMER1_DISABLE		(TIMEREG_CR_2_ENABLE)
+
+static void __iomem *base;
+static unsigned int clock_count_per_tick;
+
+static void moxart_clkevt_mode(enum clock_event_mode mode,
+			       struct clock_event_device *clk)
+{
+	switch (mode) {
+	case CLOCK_EVT_MODE_RESUME:
+	case CLOCK_EVT_MODE_ONESHOT:
+		writel(TIMER1_DISABLE, base + TIMER_CR);
+		writel(~0, base + TIMER1_BASE + REG_LOAD);
+		break;
+	case CLOCK_EVT_MODE_PERIODIC:
+		writel(clock_count_per_tick, base + TIMER1_BASE + REG_LOAD);
+		writel(TIMER1_ENABLE, base + TIMER_CR);
+		break;
+	case CLOCK_EVT_MODE_UNUSED:
+	case CLOCK_EVT_MODE_SHUTDOWN:
+	default:
+		writel(TIMER1_DISABLE, base + TIMER_CR);
+		break;
+	}
+}
+
+static int moxart_clkevt_next_event(unsigned long cycles,
+				    struct clock_event_device *unused)
+{
+	u32 u;
+
+	writel(TIMER1_DISABLE, base + TIMER_CR);
+
+	u = readl(base + TIMER1_BASE + REG_COUNT) - cycles;
+	writel(u, base + TIMER1_BASE + REG_MATCH1);
+
+	writel(TIMER1_ENABLE, base + TIMER_CR);
+
+	return 0;
+}
+
+static struct clock_event_device moxart_clockevent = {
+	.name		= "moxart_timer",
+	.rating		= 200,
+	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
+	.set_mode	= moxart_clkevt_mode,
+	.set_next_event	= moxart_clkevt_next_event,
+};
+
+static irqreturn_t moxart_timer_interrupt(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+	evt->event_handler(evt);
+	return IRQ_HANDLED;
+}
+
+static struct irqaction moxart_timer_irq = {
+	.name		= "moxart-timer",
+	.flags		= IRQF_TIMER,
+	.handler	= moxart_timer_interrupt,
+	.dev_id		= &moxart_clockevent,
+};
+
+static void __init moxart_timer_init(struct device_node *node)
+{
+	int ret, irq;
+	unsigned long pclk;
+	struct clk *clk;
+
+	base = of_iomap(node, 0);
+	if (!base)
+		panic("%s: of_iomap failed\n", node->full_name);
+
+	irq = irq_of_parse_and_map(node, 0);
+	if (irq <= 0)
+		panic("%s: irq_of_parse_and_map failed\n", node->full_name);
+
+	ret = setup_irq(irq, &moxart_timer_irq);
+	if (ret)
+		panic("%s: setup_irq failed\n", node->full_name);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk))
+		panic("%s: of_clk_get failed\n", node->full_name);
+
+	pclk = clk_get_rate(clk);
+
+	if (clocksource_mmio_init(base + TIMER2_BASE + REG_COUNT,
+				  "moxart_timer", pclk, 200, 32,
+				  clocksource_mmio_readl_down))
+		panic("%s: clocksource_mmio_init failed\n", node->full_name);
+
+	clock_count_per_tick = DIV_ROUND_CLOSEST(pclk, HZ);
+
+	writel(~0, base + TIMER2_BASE + REG_LOAD);
+	writel(TIMEREG_CR_2_ENABLE, base + TIMER_CR);
+
+	moxart_clockevent.cpumask = cpumask_of(0);
+	moxart_clockevent.irq = irq;
+
+	/*
+	 * documentation is not publicly available:
+	 * min_delta / max_delta obtained by trial-and-error,
+	 * max_delta 0xfffffffe should be ok because count
+	 * register size is u32
+	 */
+	clockevents_config_and_register(&moxart_clockevent, pclk,
+					0x4, 0xfffffffe);
+}
+CLOCKSOURCE_OF_DECLARE(moxart, "moxa,moxart-timer", moxart_timer_init);
-- 
1.8.2.1



From broonie at kernel.org  Wed Jul 17 04:10:41 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Jul 2013 09:10:41 +0100
Subject: [PATCH v3 5/7] spi: atmel: prepare clk before calling enable
In-Reply-To: <1373987782-24463-1-git-send-email-b.brezillon@overkiz.com>
References: <1373986995-23899-1-git-send-email-b.brezillon@overkiz.com>
 <1373987782-24463-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <20130717081041.GZ22506@sirena.org.uk>

On Tue, Jul 16, 2013 at 05:16:22PM +0200, Boris BREZILLON wrote:
> Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
> avoid common clk framework warnings.

Applied, thanks.
-------------- 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/20130717/58069644/attachment.sig>

From nicolas.ferre at atmel.com  Wed Jul 17 04:12:05 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 17 Jul 2013 10:12:05 +0200
Subject: [PATCH 2/5] iio: at91: Use different prescal, startup mask in
 MR for different IP
In-Reply-To: <20130715125815.GC2962@lukather>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
 <20130715125815.GC2962@lukather>
Message-ID: <51E651D5.7050906@atmel.com>

On 15/07/2013 14:58, Maxime Ripard :
> Hi Josh,
>
> On Sun, Jul 14, 2013 at 04:04:26PM +0800, Josh Wu wrote:
>> For at91 boards, there are different IPs for adc. Different IPs has different
>> STARTUP & PRESCAL mask in ADC_MR.
>>
>> This patch can change the masks according to the different IP version.
>>
>> Signed-off-by: Josh Wu <josh.wu at atmel.com>
>> ---
>>   arch/arm/mach-at91/include/mach/at91_adc.h |    9 ++++--
>>   drivers/iio/adc/at91_adc.c                 |   48 ++++++++++++++++++++++++++--
>>   2 files changed, 53 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-at91/include/mach/at91_adc.h b/arch/arm/mach-at91/include/mach/at91_adc.h
>> index 8e7ed5c..ab273ee 100644
>> --- a/arch/arm/mach-at91/include/mach/at91_adc.h
>> +++ b/arch/arm/mach-at91/include/mach/at91_adc.h
>> @@ -28,9 +28,12 @@
>>   #define			AT91_ADC_TRGSEL_EXTERNAL	(6 << 1)
>>   #define		AT91_ADC_LOWRES		(1 << 4)	/* Low Resolution */
>>   #define		AT91_ADC_SLEEP		(1 << 5)	/* Sleep Mode */
>> -#define		AT91_ADC_PRESCAL	(0x3f << 8)	/* Prescalar Rate Selection */
>> +#define		AT91_ADC_PRESCAL	(0xff << 8)	/* Prescalar Rate Selection */
>> +#define		AT91_ADC_PRESCAL_9260	(0x3f << 8)
>>   #define			AT91_ADC_PRESCAL_(x)	((x) << 8)
>> -#define		AT91_ADC_STARTUP	(0x1f << 16)	/* Startup Up Time */
>> +#define		AT91_ADC_STARTUP	(0xf << 16)	/* Startup Up Time */
>> +#define		AT91_ADC_STARTUP_9260	(0x1f << 16)
>> +#define		AT91_ADC_STARTUP_9G45	(0x7f << 16)
>>   #define			AT91_ADC_STARTUP_(x)	((x) << 16)
>>   #define		AT91_ADC_SHTIM		(0xf  << 24)	/* Sample & Hold Time */
>>   #define			AT91_ADC_SHTIM_(x)	((x) << 24)
>> @@ -58,4 +61,6 @@
>>   #define AT91_ADC_CHR(n)		(0x30 + ((n) * 4))	/* Channel Data Register N */
>>   #define		AT91_ADC_DATA		(0x3ff)
>>
>> +#define AT91_ADC_VERSION	0xFC
>> +
>>   #endif
>> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
>> index 18bd54f..14e99ba 100644
>> --- a/drivers/iio/adc/at91_adc.c
>> +++ b/drivers/iio/adc/at91_adc.c
>> @@ -39,6 +39,12 @@
>>   #define at91_adc_writel(st, reg, val) \
>>   	(writel_relaxed(val, st->reg_base + reg))
>>
>> +struct at91_adc_caps {
>> +	bool	has_tsmr;	/* only at91sam9x5, sama5d3 have TSMR reg */
>> +	u32	mr_prescal_mask;
>> +	u32	mr_startup_mask;
>> +};
>> +
>>   struct at91_adc_state {
>>   	struct clk		*adc_clk;
>>   	u16			*buffer;
>> @@ -62,6 +68,7 @@ struct at91_adc_state {
>>   	u32			res;		/* resolution used for convertions */
>>   	bool			low_res;	/* the resolution corresponds to the lowest one */
>>   	wait_queue_head_t	wq_data_avail;
>> +	struct at91_adc_caps	caps;
>>   };
>>
>>   static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
>> @@ -580,6 +587,41 @@ static const struct iio_info at91_adc_info = {
>>   	.read_raw = &at91_adc_read_raw,
>>   };
>>
>> +/*
>> + * Since atmel adc support different ip for touchscreen mode. Through the
>> + * IP check, we will know the touchscreen capbilities.
>> + */
>> +static void atmel_adc_get_cap(struct at91_adc_state *st)
>> +{
>> +	unsigned int version;
>> +	struct iio_dev *idev = iio_priv_to_dev(st);
>> +
>> +	version = at91_adc_readl(st, AT91_ADC_VERSION);
>> +	dev_dbg(&idev->dev, "version: 0x%x\n", version);
>> +
>> +	st->caps.mr_prescal_mask = AT91_ADC_PRESCAL_9260;
>> +	st->caps.mr_startup_mask = AT91_ADC_STARTUP_9260;
>> +
>> +	/* keep only major version number */
>> +	switch (version & 0xf00) {
>> +	case 0x500:	/* SAMA5D3 */
>> +	case 0x400:	/* AT91SAM9X5/9N12 */
>> +		st->caps.has_tsmr = 1;
>> +		st->caps.mr_startup_mask = AT91_ADC_STARTUP;
>> +	case 0x200:	/* AT91SAM9M10/9G45 */
>> +		st->caps.mr_prescal_mask = AT91_ADC_PRESCAL;
>> +
>> +		if ((version & 0xf00) == 0x200)
>> +			st->caps.mr_startup_mask = AT91_ADC_STARTUP_9G45;
>> +	case 0x100:	/* AT91SAM9260/9G20 */
>> +		break;
>> +	default:
>> +		dev_warn(&idev->dev,
>> +				"Unmanaged adc version, use minimal capabilities\n");
>> +		break;
>> +	};
>> +}
>
> Why don't you use different compatible names and derive your
> capabilities from which compatible is declared.

Do not forget that we still have a handful of platforms that do not 
support DT (and never will).

Josh, do you think that we can deal with this with different compatible 
string instead of checking the IP revision?

Bye,
-- 
Nicolas Ferre


From anup.patel at linaro.org  Wed Jul 17 04:11:58 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Wed, 17 Jul 2013 13:41:58 +0530
Subject: [PATCH V3] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene host
Message-ID: <1374048718-9455-1-git-send-email-anup.patel@linaro.org>

This patch allows us to have X-Gene guest VCPU when using KVM arm64
on APM X-Gene host.

We add KVM_ARM_TARGET_XGENE_POTENZA for X-Gene Potenza compatible
guest VCPU and we return KVM_ARM_TARGET_XGENE_POTENZA in kvm_target_cpu()
when running on X-Gene host with Potenza core.

V3:
 - Reduce multiple "return -EINVAL" in kvm_target_cpu()

V2:
 - Renamed KVM_ARM_TARGET_XGENE_V8 to KVM_ARM_TARGET_XGENE_POTENZA

V1:
 - Initial patch with target named as KVM_ARM_TARGET_XGENE_V8

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
 arch/arm64/kvm/guest.c               |   36 ++++++++++++++++++++++------------
 arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
 3 files changed, 29 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 5031f42..d9f026b 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -55,8 +55,9 @@ struct kvm_regs {
 #define KVM_ARM_TARGET_AEM_V8		0
 #define KVM_ARM_TARGET_FOUNDATION_V8	1
 #define KVM_ARM_TARGET_CORTEX_A57	2
+#define KVM_ARM_TARGET_XGENE_POTENZA	3
 
-#define KVM_ARM_NUM_TARGETS		3
+#define KVM_ARM_NUM_TARGETS		4
 
 /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
 #define KVM_ARM_DEVICE_TYPE_SHIFT	0
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 2c3ff67..143d179 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -207,20 +207,32 @@ int __attribute_const__ kvm_target_cpu(void)
 	unsigned long implementor = read_cpuid_implementor();
 	unsigned long part_number = read_cpuid_part_number();
 
-	if (implementor != ARM_CPU_IMP_ARM)
-		return -EINVAL;
-
-	switch (part_number) {
-	case ARM_CPU_PART_AEM_V8:
-		return KVM_ARM_TARGET_AEM_V8;
-	case ARM_CPU_PART_FOUNDATION:
-		return KVM_ARM_TARGET_FOUNDATION_V8;
-	case ARM_CPU_PART_CORTEX_A57:
-		/* Currently handled by the generic backend */
-		return KVM_ARM_TARGET_CORTEX_A57;
+	switch (implementor) {
+	case ARM_CPU_IMP_ARM:
+		switch (part_number) {
+		case ARM_CPU_PART_AEM_V8:
+			return KVM_ARM_TARGET_AEM_V8;
+		case ARM_CPU_PART_FOUNDATION:
+			return KVM_ARM_TARGET_FOUNDATION_V8;
+		case ARM_CPU_PART_CORTEX_A57:
+			return KVM_ARM_TARGET_CORTEX_A57;
+		default:
+	 		break;
+		}
+		break;
+	case ARM_CPU_IMP_APM:
+		switch (part_number) {
+		case APM_CPU_PART_POTENZA:
+			return KVM_ARM_TARGET_XGENE_POTENZA;
+		default:
+	 		break;
+		}
+		break;
 	default:
-		return -EINVAL;
+ 		break;
 	}
+
+	return -EINVAL;
 }
 
 int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
index 4268ab9..8fe6f76 100644
--- a/arch/arm64/kvm/sys_regs_generic_v8.c
+++ b/arch/arm64/kvm/sys_regs_generic_v8.c
@@ -90,6 +90,9 @@ static int __init sys_reg_genericv8_init(void)
 					  &genericv8_target_table);
 	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_CORTEX_A57,
 					  &genericv8_target_table);
+	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_XGENE_POTENZA,
+					  &genericv8_target_table);
+
 	return 0;
 }
 late_initcall(sys_reg_genericv8_init);
-- 
1.7.9.5



From jonas.jensen at gmail.com  Wed Jul 17 04:14:56 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 17 Jul 2013 10:14:56 +0200
Subject: [PATCH v8] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <51E56043.1010509@linaro.org>
References: <1373024773-24574-1-git-send-email-jonas.jensen@gmail.com>
 <1373985880-23469-1-git-send-email-jonas.jensen@gmail.com>
 <51E56043.1010509@linaro.org>
Message-ID: <CACmBeS129VOmFjnF+-iRH1viS+zpoaNMYMaWZ_UiPVxa6ncYeQ@mail.gmail.com>

On 16 July 2013 17:01, Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
> 1. could you elaborate the patch log: as it is a new driver, a nice
> description of the timer hardware would be valuable for people willing
> to understand the code (eg. some specificities of the driver).

A short description is now added to the commit message, I hope this is
what you wanted, I can reformat the text if needed.

> 2. fix the alignment below

I don't see the alignment error, I think this is because git adds the
one '+' character, it should be correct once applied?


Best regards,
Jonas


From nicolas.ferre at atmel.com  Wed Jul 17 04:23:17 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 17 Jul 2013 10:23:17 +0200
Subject: [PATCH 2/5] iio: at91: Use different prescal, startup mask in
 MR for different IP
In-Reply-To: <20130716211706.39665234@skate>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
 <20130715125815.GC2962@lukather> <51E505EA.4060502@atmel.com>
 <51E50864.6020904@atmel.com> <20130716133003.7c208cdf@skate>
 <51E5990A.4050709@kernel.org> <20130716211706.39665234@skate>
Message-ID: <51E65475.4010109@atmel.com>

On 16/07/2013 21:17, Thomas Petazzoni :
> Dear Jonathan Cameron,
>
> On Tue, 16 Jul 2013 20:03:38 +0100, Jonathan Cameron wrote:
>
>> On 07/16/2013 12:30 PM, Thomas Petazzoni wrote:
>>> I've asked exactly this question last week at Linaro Connect during the
>>> ARM SoC consolidation panel/discussion, where Grant Likely, Arnd
>>> Bergmann, Olof and others were answering Device Tree related questions.
>>>
>>> My question, which precisely had the at91-adc DT binding in mind was
>>> precisely whether we should use different compatible properties to
>>> identify different revisions of an IP block and let the driver handle
>>> those differences, or whether the DT binding should provide sufficient
>>> properties (register offsets, bit numbers, etc.) to make the driver
>>> independent of the IP revisions. And clearly, the answer was that
>>> different compatible properties should be used to identify the
>>> different versions of the IP block, and the driver should abstract out
>>> the differences. I.e, was has been done for at91-adc is completely the
>>> opposite of the best practices for Device Tree on ARM.
>>>
>>> See
>>> http://www.youtube.com/watch?v=zF_AXLgkFy4&feature=player_detailpage#t=1581s
>>> where I ask exactly this question, and get answers from Olof Johansson
>>> and Grant Likely. They clearly say that the solution of having separate
>>> compatible properties and a driver that handles the differences is the
>>> way to go. So the way at91-adc (and possibly other at91 drivers) is
>>> using the Device Tree is wrong, there should have been multiple
>>> compatible properties. It's a shame because this is something we did say
>>> when we submitted at91-adc and during the reviews, but the maintainer
>>> wasn't listening to our comments...
>>>
>>
>> Thanks for getting some clarity on this Thomas.  So I'll ask the somewhat obvious
>> question - how do we unwind from where we are to where we want to be wrt to the
>> bindings?
>
> During Linaro Connect last week, there was some discussion about
> marking DT bindings as unstable for a little while, once they get
> reviewed by a group of DT "experts" that mark them as stable. Until
> they are stable, the kernel does not offer any ABI guarantees, and we
> are free to change the DT bindings as needed.
>
> Now, since this unstable/stable thing is not in place at the moment,
> deciding whether to break or not existing bindings is something to be
> decided by the maintainer of this platform, judging what is the best
> option depending on whether there are already many users of the DT for
> this platform or not, for example.

I didn't had in mind that the current discussion about the addition of 
some properties could cast doubt on the entire at91-adc binding!

The binding itself has several drawbacks and is kind of over engineered, 
I agree with that. Some register offsets in particular have nothing to 
do in a DT binding.
On the other hand, some values are highly dependent on the SoC process 
itself and can't be stored in the driver because it would require to 
change the driver for each new SoC, depending on the electrical 
characteristics.
In conclusion, we have to be cautious with this binding and make sure 
that we don't throw the baby out with the bath water.

Moreover, at the time we are just beginning to be comfortable with DT on 
AT91 and beginning to overcome the difficulty of converting our 
platforms, I see this new step on the path to "mainline + DT stable" as 
another slowdown.

Bye,
-- 
Nicolas Ferre


From broonie at kernel.org  Wed Jul 17 04:30:03 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Jul 2013 09:30:03 +0100
Subject: [PATCH] ASoC: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
In-Reply-To: <1374013667-21435-1-git-send-email-swarren@wwwdotorg.org>
References: <1374013667-21435-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130717083003.GA22506@sirena.org.uk>

On Tue, Jul 16, 2013 at 04:27:47PM -0600, Stephen Warren wrote:

> Stop selecting I2S/AC97/SPDIF controller drivers from the machine driver
> config options; this doesn't really work if we don't know which specific
> SoC(s) we're building for. However, set their default values based on
> SND_SOC_TEGRA, since most people will probably want to enable support for
> all SoCs. This also avoids the need to change any defconfig files.

This doesn't seem terribly clever and is definitely not idiomatic for
ASoC.  If you want to just select all CPUs that'd be fine but forcing
the user to select the individual components isn't the style anything
else uses.
-------------- 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/20130717/400e5d30/attachment-0001.sig>

From mark.rutland at arm.com  Wed Jul 17 04:40:39 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Jul 2013 09:40:39 +0100
Subject: [PATCH 1/3] ASoC: bt-sco: enable OF support
In-Reply-To: <1374041536-27643-1-git-send-email-Baohua.Song@csr.com>
References: <1374041536-27643-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <20130717084039.GA15981@e106331-lin.cambridge.arm.com>

On Wed, Jul 17, 2013 at 07:12:14AM +0100, Barry Song wrote:
> From: Rongjun Ying <Rongjun.Ying at csr.com>
> 
> this makes users be able to add a bt-sco node in dts instead of
> hardcoding a platform device in mach.

I'm slightly confused by this. The driver doesn't seem to pick up any
information out of the dts, and the binding doesn't even describe any
linkage to a piece of hardware. I'm not familiar with bluetooth or ASoC,
could you give an explanation as to why this is needed?

I don't think this should be in the dt as is. Could this not be
registered based on the presence of a bluetooth controller that supports
this?

Thanks,
Mark.

> 
> Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
> Signed-off-by: Barry Song <Baohua.Song at csr.com>
> ---
>  sound/soc/codecs/bt-sco.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/sound/soc/codecs/bt-sco.c b/sound/soc/codecs/bt-sco.c
> index a081d9f..39e7ebe 100644
> --- a/sound/soc/codecs/bt-sco.c
> +++ b/sound/soc/codecs/bt-sco.c
> @@ -46,6 +46,14 @@ static int bt_sco_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_OF
> +static const struct of_device_id bt_sco_of_match[] = {
> +	{ .compatible = "bt-sco-codec", },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, bt_sco_of_match);
> +#endif
> +
>  static struct platform_device_id bt_sco_driver_ids[] = {
>  	{
>  		.name		= "dfbmcs320",
> @@ -58,6 +66,9 @@ static struct platform_driver bt_sco_driver = {
>  	.driver = {
>  		.name = "bt-sco",
>  		.owner = THIS_MODULE,
> +#ifdef CONFIG_OF
> +		.of_match_table = bt_sco_of_match,
> +#endif
>  	},
>  	.probe = bt_sco_probe,
>  	.remove = bt_sco_remove,
> -- 
> 1.8.2.3
> 
> 
> 
> Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From mkl at pengutronix.de  Wed Jul 17 04:41:19 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Wed, 17 Jul 2013 10:41:19 +0200
Subject: BUG: commit "ARM: Remove __ARCH_WANT_INTERRUPTS_ON_CTXSW on
 pre-ARMv6 CPUs" breaks armv5 with CONFIG_PREEMPT
In-Reply-To: <20130621135219.GC4099@arm.com>
References: <51C2C0B5.8020802@pengutronix.de> <20130620095705.GA18536@arm.com>
 <51C2D5EF.3040803@pengutronix.de> <20130620102856.GC18536@arm.com>
 <20130620111255.GD18536@arm.com> <51C2E917.9000708@pengutronix.de>
 <51C2EA04.4060701@pengutronix.de> <51C2EBCD.4070206@pengutronix.de>
 <51C42AE0.9070506@pengutronix.de> <20130621135219.GC4099@arm.com>
Message-ID: <51E658AF.1090009@pengutronix.de>

On 06/21/2013 03:52 PM, Catalin Marinas wrote:
> On Fri, Jun 21, 2013 at 11:28:48AM +0100, Marc Kleine-Budde wrote:
>> On 06/20/2013 01:47 PM, Marc Kleine-Budde wrote:
>>> From 306d84d5f0645a86e86d539be0546c4ac758d3d4 Mon Sep 17 00:00:00 2001
>>> From: Catalin Marinas <catalin.marinas at arm.com>
>>> Date: Thu, 20 Jun 2013 12:12:55 +0100
>>> Subject: [PATCH] arm: Fix deferred mm switch on VIVT processors
>>>
>>> As of commit b9d4d42ad9 (ARM: Remove __ARCH_WANT_INTERRUPTS_ON_CTXSW on
>>> pre-ARMv6 CPUs), the mm switching on VIVT processors is done in the
>>> finish_arch_post_lock_switch() function to avoid whole cache flushing
>>> with interrupts disabled. The need for deferred mm switch is stored as a
>>> thread flag (TIF_SWITCH_MM). However, with preemption enabled, we can
>>> have another thread switch before finish_arch_post_lock_switch(). If the
>>> new thread has the same mm as the previous 'next' thread, the scheduler
>>> will not call switch_mm() and the TIF_SWITCH_MM flag won't be set for
>>> the new thread.
>>>
>>> This patch moves the switch pending flag to the mm_context_t structure
>>> since this is specific to the mm rather than thread.
>>>
>>> Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
>>> Reported-by: Marc Kleine-Budde <mkl at pengutronix.de>
>>> [mkl: add check for mm]
>>> Signed-off-by: Marc Kleine-Budde <mkl at pengutronix.de>
>>
>> Works on $CUSTOMERS's hardware.
>>
>> Tested-by: Marc Kleine-Budde <mkl at pengutronix.de>
> 
> Thanks.
> 
>> Catalin, do you take care of the patch? Please add stable on Cc. The fix
>> is needed on kernels >= v3.5.
> 
> I'll send it to Russell, if possible it should go in for 3.10. I already
> added CC stable in my copy (3.5+).

What happend to that patch? I cannot find it in v3.10.x nor in linus/master.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130717/dcf37d41/attachment.sig>

From ldewangan at nvidia.com  Wed Jul 17 04:57:24 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 17 Jul 2013 14:27:24 +0530
Subject: [PATCH V2] ARM: tegra: enable palmas device for dalmore
In-Reply-To: <51E54FD1.1010404@nvidia.com>
References: <1373441852-27176-1-git-send-email-ldewangan@nvidia.com>
 <51E54FD1.1010404@nvidia.com>
Message-ID: <51E65C74.8060405@nvidia.com>

On Tuesday 16 July 2013 07:21 PM, Mikko Perttunen wrote:
> On 07/10/2013 10:37 AM, Laxman Dewangan wrote:
>> +
>> +			palmas_gpio: gpio {
>> +				compatible = "ti,palmas-gpio";
>> +				gpio-controller;
>> +				#gpio-cells = <2>;
>> +			};
> I don't think the palmas-gpio driver ever gets probed since it doesn't
> have device tree compability strings?
>
You will need the patch
[PATCH V3] gpio: palmas: add dt support

which is under review from last few days.



From mark.rutland at arm.com  Wed Jul 17 04:49:10 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Jul 2013 09:49:10 +0100
Subject: [PATCH 2/3] ASoC: hdmi-codec: enable OF support
In-Reply-To: <1374041536-27643-2-git-send-email-Baohua.Song@csr.com>
References: <1374041536-27643-1-git-send-email-Baohua.Song@csr.com>
 <1374041536-27643-2-git-send-email-Baohua.Song@csr.com>
Message-ID: <20130717084910.GB15981@e106331-lin.cambridge.arm.com>

On Wed, Jul 17, 2013 at 07:12:15AM +0100, Barry Song wrote:
> From: Rongjun Ying <Rongjun.Ying at csr.com>
> 
> this makes users be able to add a hdmi-codec node in dts instead of
> hardcoding a platform device in mach.

Similarly to my comment on the first patch, I'm not sure this is the
best way to wire this up to devicetree. Can this not be hung off of hdmi
controller drivers?

Thanks,
Mark.

> 
> Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
> Signed-off-by: Barry Song <Baohua.Song at csr.com>
> ---
>  sound/soc/codecs/hdmi.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/sound/soc/codecs/hdmi.c b/sound/soc/codecs/hdmi.c
> index 2bcae2b..78c7b15 100644
> --- a/sound/soc/codecs/hdmi.c
> +++ b/sound/soc/codecs/hdmi.c
> @@ -51,10 +51,21 @@ static int hdmi_codec_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_OF
> +static const struct of_device_id hdmi_audio_codec_ids[] = {
> +	{ .compatible = "hdmi-audio-codec", },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, hdmi_audio_codec_ids);
> +#endif
> +
>  static struct platform_driver hdmi_codec_driver = {
>  	.driver		= {
>  		.name	= DRV_NAME,
>  		.owner	= THIS_MODULE,
> +#ifdef CONFIG_OF
> +		.of_match_table = hdmi_audio_codec_ids,
> +#endif
>  	},
>  
>  	.probe		= hdmi_codec_probe,
> -- 
> 1.8.2.3
> 
> 
> 
> Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From tom.leiming at gmail.com  Wed Jul 17 04:51:30 2013
From: tom.leiming at gmail.com (Ming Lei)
Date: Wed, 17 Jul 2013 16:51:30 +0800
Subject: [PATCH] [RFC] EHCI: add to memory barrier to updating hw_next
In-Reply-To: <000001ce82aa$feac9ee0$fc05dca0$@lge.com>
References: <000001ce82aa$feac9ee0$fc05dca0$@lge.com>
Message-ID: <CACVXFVOu-2q74JmHLEo3mCVSAzfc7n8GmqPDMPhEDp0wL37w_w@mail.gmail.com>

Cc: ARM list

On Wed, Jul 17, 2013 at 1:03 PM, ??? <gioh.kim at lge.com> wrote:
> Hi,
>
> I have a missing urb completion problem on ARMv7 based platform.
>
> I thought the above problem was caused by coherent memory between the
> EHCI device and CPU so I tryied to allocates device type memory
> for EHCI via dma_declare_coherent_memory at machine initialization step
> so that EHCI always allocates from those device type memory.
> It seems to solve the issue because I didn't see any problem.
>
> But I am not sure it is acceptable solution. So I applied the patch
> https://lkml.org/lkml/2011/8/31/344.
> But it could not solve the problem so that I added another wmb()
> as my patch, and now my platform works fine.

I remember the previous problem reported on Pandaboard firstly was
fixed by Will's commit 11ed0ba1(ARM: 7161/1: errata: no automatic store
buffer drain), so could you try to enable PL310_ERRATA_769419 and
see if your problem can be fixed?

>
> I am not sure what's the exact problem and what wmb I added could solve
> but I just think the problem is related to store buffer flush of hw_next.

Yes, per the above commit, but it might be one hardware problem.

> Anyway, important thing is that it fixed my problem so I expect
> you expert guys could find what I am missing and a right solution.
> IMHO, the patch might miss updating hw_next pointer.
> Am I correct?
>
> I understand the wmb() is just memory barrier, not write-buffer flush.
> But it is true that wmb() can flush write buffer in ARM.
> Anyhow I think that memory type, "normal memory, non-cacheable", may
> have a problem for some devices that needs device type memory.

Currently on ARMv7 DMA coherent buffer has to be bufferable, in theory
we might need one API to flush CPU write buffer, as described in
Documentation/DMA-API-HOWTO.txt:

             Also, on some platforms your driver may need to flush CPU write
             buffers in much the same way as it needs to flush write buffers
             found in PCI bridges (such as by reading a register's value
             after writing it).

But actually on hardware without the problem(such as A15), I don't see
any effect without flushing store buffer explicitly.

>
> I cannot get conclusion from the discussion at
> https://lkml.org/lkml/2011/8/31/344.
> Which can I do for my platform, wmb() or dma_coherent_write_sync()?

If your hardware is covered by PL310_ERRATA_769419, maybe it is
better to enable the errata.

>
> Signed-off-by: Gioh Kim <gioh.kim at lge.com>
> ---
>  drivers/usb/host/ehci-q.c |    1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
> index d34b399..779d9e8 100644
> --- a/drivers/usb/host/ehci-q.c
> +++ b/drivers/usb/host/ehci-q.c
> @@ -501,6 +501,7 @@ qh_completions (struct ehci_hcd *ehci, struct ehci_qh *qh)
>                         last = list_entry (qtd->qtd_list.prev,
>                                         struct ehci_qtd, qtd_list);
>                         last->hw_next = qtd->hw_next;
> +                       wmb();
>                 }
>
>                 /* remove qtd; it's recycled after possible urb completion */
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Thanks,
-- 
Ming Lei


From linux at arm.linux.org.uk  Wed Jul 17 04:51:39 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 09:51:39 +0100
Subject: BUG: commit "ARM: Remove __ARCH_WANT_INTERRUPTS_ON_CTXSW on
 pre-ARMv6 CPUs" breaks armv5 with CONFIG_PREEMPT
In-Reply-To: <51E658AF.1090009@pengutronix.de>
References: <20130620095705.GA18536@arm.com> <51C2D5EF.3040803@pengutronix.de>
 <20130620102856.GC18536@arm.com> <20130620111255.GD18536@arm.com>
 <51C2E917.9000708@pengutronix.de> <51C2EA04.4060701@pengutronix.de>
 <51C2EBCD.4070206@pengutronix.de> <51C42AE0.9070506@pengutronix.de>
 <20130621135219.GC4099@arm.com> <51E658AF.1090009@pengutronix.de>
Message-ID: <20130717085139.GJ24642@n2100.arm.linux.org.uk>

On Wed, Jul 17, 2013 at 10:41:19AM +0200, Marc Kleine-Budde wrote:
> What happend to that patch? I cannot find it in v3.10.x nor in linus/master.

Catalin sent it to me, and I didn't apply it because it's still racy.

We have stateful context switches (due to cache clearing) and this does
nothing to solve the problem there.  If we get preempted during the
cache clearing, things will still go wrong.

See:

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7771/1

I've no idea what's happening about this.  It looks to me like nothing
happened after Catalin's last comment there.


From mperttunen at nvidia.com  Wed Jul 17 04:53:32 2013
From: mperttunen at nvidia.com (Mikko Perttunen)
Date: Wed, 17 Jul 2013 11:53:32 +0300
Subject: [PATCH V2] ARM: tegra: enable palmas device for dalmore
In-Reply-To: <51E65C74.8060405@nvidia.com>
References: <1373441852-27176-1-git-send-email-ldewangan@nvidia.com>
 <51E54FD1.1010404@nvidia.com> <51E65C74.8060405@nvidia.com>
Message-ID: <51E65B8C.1000405@nvidia.com>

On 07/17/2013 11:57 AM, Laxman Dewangan wrote:
> On Tuesday 16 July 2013 07:21 PM, Mikko Perttunen wrote:
>> On 07/10/2013 10:37 AM, Laxman Dewangan wrote:
>>> +
>>> +			palmas_gpio: gpio {
>>> +				compatible = "ti,palmas-gpio";
>>> +				gpio-controller;
>>> +				#gpio-cells = <2>;
>>> +			};
>> I don't think the palmas-gpio driver ever gets probed since it doesn't
>> have device tree compability strings?
>>
> You will need the patch
> [PATCH V3] gpio: palmas: add dt support
>
> which is under review from last few days.
>

Ah, ok. I guess I'm not on the proper ML for that one.


From linux at arm.linux.org.uk  Wed Jul 17 05:03:55 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 10:03:55 +0100
Subject: sched_clock always 0 and no process time accounting with 3.11-rc1
In-Reply-To: <20130717061925.GC6950@tarshish>
References: <CAMo8BfLO31GgMMA_hENr0xm=qaUz3EVLtaQ8hewiQHdbV+s6sA@mail.gmail.com>
 <20130717061925.GC6950@tarshish>
Message-ID: <20130717090354.GK24642@n2100.arm.linux.org.uk>

On Wed, Jul 17, 2013 at 09:19:25AM +0300, Baruch Siach wrote:
> Apparently the expression '(1 << 32)' evaluates to 1 on xtensa cross gcc, and 
> x86_84 native gcc. According to my limited understanding, the C compiler is 
> allowed to do so. This caused sched_clock_32() to return constant 0. I wonder 
> how it didn't bite the ARM people who are using this code from quite some time 
> (added LAKL to CC).

It (a) used to be only 32-bit, and (b) <<32 on ARM evaluates to zero in
a 32-bit context (it's not a rotate).

Patch looks fine.  I wonder who takes it... after all, I used to look
after that code (after all, I'm the author of it), but now I guess as
it's been moved under kernel/time, it's someone elses responsibility.


From jonas.jensen at gmail.com  Wed Jul 17 05:04:10 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 17 Jul 2013 11:04:10 +0200
Subject: [PATCH v3 2/4] ARM: mach-moxart: add MOXA ART device tree files
In-Reply-To: <1372949115-8190-1-git-send-email-jonas.jensen@gmail.com>
References: <1371040448-28742-3-git-send-email-jonas.jensen@gmail.com>
 <1372949115-8190-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <CACmBeS0LHqm8=4hM4VaDCBZZEP9-er7rP+SfJ7GnpgiGvJm+2Q@mail.gmail.com>

Just as a reminder, I intend to update this set with some minor changes:

1. remove devicetree bindings for drivers, I will mail those out separately
2. a devicetree node for DMA was added
3. GPIO numbers are now in DT aswell

Best regards,
Jonas


From josh.wu at atmel.com  Wed Jul 17 05:07:54 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Wed, 17 Jul 2013 17:07:54 +0800
Subject: [PATCH 2/5] iio: at91: Use different prescal, startup mask in
 MR for different IP
In-Reply-To: <51E651D5.7050906@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
 <20130715125815.GC2962@lukather> <51E651D5.7050906@atmel.com>
Message-ID: <51E65EEA.2050306@atmel.com>

Hi, Nicolas

On 7/17/2013 4:12 PM, Nicolas Ferre wrote:
> On 15/07/2013 14:58, Maxime Ripard :
>> Hi Josh,
>>
>> On Sun, Jul 14, 2013 at 04:04:26PM +0800, Josh Wu wrote:
>>> For at91 boards, there are different IPs for adc. Different IPs has 
>>> different
>>> STARTUP & PRESCAL mask in ADC_MR.
>>>
>>> This patch can change the masks according to the different IP version.
>>>
>>> Signed-off-by: Josh Wu <josh.wu at atmel.com>
>>> ---
>>>   arch/arm/mach-at91/include/mach/at91_adc.h |    9 ++++--
>>>   drivers/iio/adc/at91_adc.c                 |   48 
>>> ++++++++++++++++++++++++++--
>>>   2 files changed, 53 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-at91/include/mach/at91_adc.h 
>>> b/arch/arm/mach-at91/include/mach/at91_adc.h
>>> index 8e7ed5c..ab273ee 100644
>>> --- a/arch/arm/mach-at91/include/mach/at91_adc.h
>>> +++ b/arch/arm/mach-at91/include/mach/at91_adc.h
>>> @@ -28,9 +28,12 @@
>>>   #define            AT91_ADC_TRGSEL_EXTERNAL    (6 << 1)
>>>   #define        AT91_ADC_LOWRES        (1 << 4)    /* Low 
>>> Resolution */
>>>   #define        AT91_ADC_SLEEP        (1 << 5)    /* Sleep Mode */
>>> -#define        AT91_ADC_PRESCAL    (0x3f << 8)    /* Prescalar Rate 
>>> Selection */
>>> +#define        AT91_ADC_PRESCAL    (0xff << 8)    /* Prescalar Rate 
>>> Selection */
>>> +#define        AT91_ADC_PRESCAL_9260    (0x3f << 8)
>>>   #define            AT91_ADC_PRESCAL_(x)    ((x) << 8)
>>> -#define        AT91_ADC_STARTUP    (0x1f << 16)    /* Startup Up 
>>> Time */
>>> +#define        AT91_ADC_STARTUP    (0xf << 16)    /* Startup Up 
>>> Time */
>>> +#define        AT91_ADC_STARTUP_9260    (0x1f << 16)
>>> +#define        AT91_ADC_STARTUP_9G45    (0x7f << 16)
>>>   #define            AT91_ADC_STARTUP_(x)    ((x) << 16)
>>>   #define        AT91_ADC_SHTIM        (0xf  << 24) /* Sample & Hold 
>>> Time */
>>>   #define            AT91_ADC_SHTIM_(x)    ((x) << 24)
>>> @@ -58,4 +61,6 @@
>>>   #define AT91_ADC_CHR(n)        (0x30 + ((n) * 4))    /* Channel 
>>> Data Register N */
>>>   #define        AT91_ADC_DATA        (0x3ff)
>>>
>>> +#define AT91_ADC_VERSION    0xFC
>>> +
>>>   #endif
>>> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
>>> index 18bd54f..14e99ba 100644
>>> --- a/drivers/iio/adc/at91_adc.c
>>> +++ b/drivers/iio/adc/at91_adc.c
>>> @@ -39,6 +39,12 @@
>>>   #define at91_adc_writel(st, reg, val) \
>>>       (writel_relaxed(val, st->reg_base + reg))
>>>
>>> +struct at91_adc_caps {
>>> +    bool    has_tsmr;    /* only at91sam9x5, sama5d3 have TSMR reg */
>>> +    u32    mr_prescal_mask;
>>> +    u32    mr_startup_mask;
>>> +};
>>> +
>>>   struct at91_adc_state {
>>>       struct clk        *adc_clk;
>>>       u16            *buffer;
>>> @@ -62,6 +68,7 @@ struct at91_adc_state {
>>>       u32            res;        /* resolution used for convertions */
>>>       bool            low_res;    /* the resolution corresponds to 
>>> the lowest one */
>>>       wait_queue_head_t    wq_data_avail;
>>> +    struct at91_adc_caps    caps;
>>>   };
>>>
>>>   static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
>>> @@ -580,6 +587,41 @@ static const struct iio_info at91_adc_info = {
>>>       .read_raw = &at91_adc_read_raw,
>>>   };
>>>
>>> +/*
>>> + * Since atmel adc support different ip for touchscreen mode. 
>>> Through the
>>> + * IP check, we will know the touchscreen capbilities.
>>> + */
>>> +static void atmel_adc_get_cap(struct at91_adc_state *st)
>>> +{
>>> +    unsigned int version;
>>> +    struct iio_dev *idev = iio_priv_to_dev(st);
>>> +
>>> +    version = at91_adc_readl(st, AT91_ADC_VERSION);
>>> +    dev_dbg(&idev->dev, "version: 0x%x\n", version);
>>> +
>>> +    st->caps.mr_prescal_mask = AT91_ADC_PRESCAL_9260;
>>> +    st->caps.mr_startup_mask = AT91_ADC_STARTUP_9260;
>>> +
>>> +    /* keep only major version number */
>>> +    switch (version & 0xf00) {
>>> +    case 0x500:    /* SAMA5D3 */
>>> +    case 0x400:    /* AT91SAM9X5/9N12 */
>>> +        st->caps.has_tsmr = 1;
>>> +        st->caps.mr_startup_mask = AT91_ADC_STARTUP;
>>> +    case 0x200:    /* AT91SAM9M10/9G45 */
>>> +        st->caps.mr_prescal_mask = AT91_ADC_PRESCAL;
>>> +
>>> +        if ((version & 0xf00) == 0x200)
>>> +            st->caps.mr_startup_mask = AT91_ADC_STARTUP_9G45;
>>> +    case 0x100:    /* AT91SAM9260/9G20 */
>>> +        break;
>>> +    default:
>>> +        dev_warn(&idev->dev,
>>> +                "Unmanaged adc version, use minimal capabilities\n");
>>> +        break;
>>> +    };
>>> +}
>>
>> Why don't you use different compatible names and derive your
>> capabilities from which compatible is declared.
>
> Do not forget that we still have a handful of platforms that do not 
> support DT (and never will).
>
> Josh, do you think that we can deal with this with different 
> compatible string instead of checking the IP revision?

yes, the simplest way is define additional adc_cap structure for 
different compatible string.
like following:

static const struct of_device_id at91_adc_dt_ids[] = {
     { .compatible = "atmel,at91sam9260-adc", .data 
=&at91sam9260-adc-caps },
     { .compatible = "atmel,at91sam9x5-adc", .data =&at91sam9x5-adc-caps },
     {},
};

Then we can define the capability for different chip very easy.

>
> Bye,

Best Regards,
Josh Wu


From mark.rutland at arm.com  Wed Jul 17 05:11:03 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Jul 2013 10:11:03 +0100
Subject: [PATCH v4 1/3] ARM: shmobile: r8a7790: add Ether support
In-Reply-To: <1372663234-13486-2-git-send-email-horms+renesas@verge.net.au>
References: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
 <1372663234-13486-2-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130717091103.GD15981@e106331-lin.cambridge.arm.com>

On Mon, Jul 01, 2013 at 08:20:32AM +0100, Simon Horman wrote:
> Add Ether clock and platform device for R8A7779 SoC; add a function to
> register this device with board-specific platform data.
> 
> Based on a similar change for the r8a7779 by Sergei Shtylyov.
> 
> Cc: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> ---
> 
> This patch has a run-time dependency on "sh_eth: add support for r8a7790 SoC".
> 
> v3
> * Use newly added "r8a7790-ether" instead of "sh-eth"
> 
> v2
> * Do not add MSTP812, EtherAVB. It is not used.
> * As suggested by Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>   - Move Ethernet element of MSTP enum to a separate line
>   - Move declaration of r8a7790_add_ether_device() to immediately
>     after that of r8a7790_add_standard_devices()
>   - Add __initdata annotation to ether_resource.
> ---
>  arch/arm/mach-shmobile/clock-r8a7790.c        |  4 ++++
>  arch/arm/mach-shmobile/include/mach/r8a7790.h |  3 +++
>  arch/arm/mach-shmobile/setup-r8a7790.c        | 14 ++++++++++++++
>  3 files changed, 21 insertions(+)
> 
> diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c b/arch/arm/mach-shmobile/clock-r8a7790.c
> index 62d8162..2f52c0f 100644
> --- a/arch/arm/mach-shmobile/clock-r8a7790.c
> +++ b/arch/arm/mach-shmobile/clock-r8a7790.c
> @@ -52,6 +52,7 @@
>  #define SMSTPCR3 0xe615013c
>  #define SMSTPCR5 0xe6150144
>  #define SMSTPCR7 0xe615014c
> +#define SMSTPCR8 0xe6150990
>  
>  #define MODEMR		0xE6160060
>  #define SDCKCR		0xE6150074
> @@ -182,6 +183,7 @@ static struct clk div6_clks[DIV6_NR] = {
>  
>  /* MSTP */
>  enum {
> +	MSTP813,
>  	MSTP721, MSTP720,
>  	MSTP717, MSTP716,
>  	MSTP522,
> @@ -192,6 +194,7 @@ enum {
>  };
>  
>  static struct clk mstp_clks[MSTP_NR] = {
> +	[MSTP813] = SH_CLK_MSTP32(&p_clk, SMSTPCR8, 13, 0), /* Ether */
>  	[MSTP721] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 21, 0), /* SCIF0 */
>  	[MSTP720] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 20, 0), /* SCIF1 */
>  	[MSTP717] = SH_CLK_MSTP32(&zs_clk, SMSTPCR7, 17, 0), /* HSCIF0 */
> @@ -260,6 +263,7 @@ static struct clk_lookup lookups[] = {
>  	CLKDEV_DEV_ID("sh-sci.7", &mstp_clks[MSTP720]),
>  	CLKDEV_DEV_ID("sh-sci.8", &mstp_clks[MSTP717]),
>  	CLKDEV_DEV_ID("sh-sci.9", &mstp_clks[MSTP716]),
> +	CLKDEV_DEV_ID("r8a7790-ether", &mstp_clks[MSTP813]),
>  	CLKDEV_DEV_ID("rcar_thermal", &mstp_clks[MSTP522]),
>  	CLKDEV_DEV_ID("ee200000.mmcif", &mstp_clks[MSTP315]),
>  	CLKDEV_DEV_ID("sh_mmcif.0", &mstp_clks[MSTP315]),
> diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h b/arch/arm/mach-shmobile/include/mach/r8a7790.h
> index 7851cc1..b827b49 100644
> --- a/arch/arm/mach-shmobile/include/mach/r8a7790.h
> +++ b/arch/arm/mach-shmobile/include/mach/r8a7790.h
> @@ -1,7 +1,10 @@
>  #ifndef __ASM_R8A7790_H__
>  #define __ASM_R8A7790_H__
>  
> +#include <linux/sh_eth.h>
> +
>  void r8a7790_add_standard_devices(void);
> +void r8a7790_add_ether_device(struct sh_eth_plat_data *pdata);
>  void r8a7790_clock_init(void);
>  void r8a7790_pinmux_init(void);
>  void r8a7790_init_delay(void);
> diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
> index d89cd83..fad4251 100644
> --- a/arch/arm/mach-shmobile/setup-r8a7790.c
> +++ b/arch/arm/mach-shmobile/setup-r8a7790.c
> @@ -31,6 +31,20 @@
>  #include <mach/r8a7790.h>
>  #include <asm/mach/arch.h>
>  
> +/* Ether */
> +static struct resource ether_resources[] __initdata = {
> +	DEFINE_RES_MEM(0xee700000, 0x400),
> +	DEFINE_RES_IRQ(gic_spi(162)), /* IRQ0 */
> +};
> +
> +void __init r8a7790_add_ether_device(struct sh_eth_plat_data *pdata)
> +{
> +	platform_device_register_resndata(&platform_bus, "r8a7790-ether", -1,
> +					  ether_resources,
> +					  ARRAY_SIZE(ether_resources),
> +					  pdata, sizeof(*pdata));
> +}

Why are we hardcoding the address and interrupt of a device rather than
describing it in the devicetree? This is the most trivial case to
describe.

Thanks,
Mark.

> +
>  static struct resource pfc_resources[] __initdata = {
>  	DEFINE_RES_MEM(0xe6060000, 0x250),
>  };
> -- 
> 1.8.2.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From baruch at tkos.co.il  Wed Jul 17 05:12:09 2013
From: baruch at tkos.co.il (Baruch Siach)
Date: Wed, 17 Jul 2013 12:12:09 +0300
Subject: sched_clock always 0 and no process time accounting with 3.11-rc1
In-Reply-To: <20130717090354.GK24642@n2100.arm.linux.org.uk>
References: <CAMo8BfLO31GgMMA_hENr0xm=qaUz3EVLtaQ8hewiQHdbV+s6sA@mail.gmail.com>
 <20130717061925.GC6950@tarshish>
 <20130717090354.GK24642@n2100.arm.linux.org.uk>
Message-ID: <20130717091209.GL6950@tarshish>

Hi Russell,

On Wed, Jul 17, 2013 at 10:03:55AM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 09:19:25AM +0300, Baruch Siach wrote:
> > Apparently the expression '(1 << 32)' evaluates to 1 on xtensa cross gcc, and 
> > x86_84 native gcc. According to my limited understanding, the C compiler is 
> > allowed to do so. This caused sched_clock_32() to return constant 0. I wonder 
> > how it didn't bite the ARM people who are using this code from quite some time 
> > (added LAKL to CC).
> 
> It (a) used to be only 32-bit, and (b) <<32 on ARM evaluates to zero in
> a 32-bit context (it's not a rotate).
> 
> Patch looks fine.

Thanks for the confirmation, I'll take it as an ack if you don't mind.

> I wonder who takes it... after all, I used to look
> after that code (after all, I'm the author of it), but now I guess as
> it's been moved under kernel/time, it's someone elses responsibility.

Since the code move went through the tree of the timekeepers, John Stultz and 
Thomas Gleixner, I guess they should handle it.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -


From jonas.jensen at gmail.com  Wed Jul 17 05:14:04 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 17 Jul 2013 11:14:04 +0200
Subject: [PATCH v4] rtc: Add MOXA ART RTC driver
In-Reply-To: <1373978485-17496-1-git-send-email-jonas.jensen@gmail.com>
References: <1373978485-17496-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1374052444-5420-1-git-send-email-jonas.jensen@gmail.com>

Add RTC driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v3:
    
    1. add devicetree bindings document
    
    Applies to next-20130716

 .../devicetree/bindings/rtc/moxa,moxart-rtc.txt    |  17 ++
 drivers/rtc/Kconfig                                |   9 +
 drivers/rtc/Makefile                               |   1 +
 drivers/rtc/rtc-moxart.c                           | 330 +++++++++++++++++++++
 4 files changed, 357 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
 create mode 100644 drivers/rtc/rtc-moxart.c

diff --git a/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt b/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
new file mode 100644
index 0000000..c9d3ac1
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/moxa,moxart-rtc.txt
@@ -0,0 +1,17 @@
+MOXA ART real-time clock
+
+Required properties:
+
+- compatible : Should be "moxa,moxart-rtc"
+- gpio-rtc-sclk : RTC sclk gpio, with zero flags
+- gpio-rtc-data : RTC data gpio, with zero flags
+- gpio-rtc-reset : RTC reset gpio, with zero flags
+
+Example:
+
+	rtc: rtc {
+		compatible = "moxa,moxart-rtc";
+		gpio-rtc-sclk = <&gpio 5 0>;
+		gpio-rtc-data = <&gpio 6 0>;
+		gpio-rtc-reset = <&gpio 7 0>;
+	};
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 9e3498b..9654aa3 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1249,6 +1249,15 @@ config RTC_DRV_SIRFSOC
 	  Say "yes" here to support the real time clock on SiRF SOC chips.
 	  This driver can also be built as a module called rtc-sirfsoc.
 
+config RTC_DRV_MOXART
+	tristate "MOXA ART RTC"
+	help
+	   If you say yes here you get support for the MOXA ART
+	   RTC module.
+
+	   This driver can also be built as a module. If so, the module
+	   will be called rtc-moxart
+
 comment "HID Sensor RTC drivers"
 
 config RTC_DRV_HID_SENSOR_TIME
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index d3b4488..2dff3d2 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -130,3 +130,4 @@ obj-$(CONFIG_RTC_DRV_WM831X)	+= rtc-wm831x.o
 obj-$(CONFIG_RTC_DRV_WM8350)	+= rtc-wm8350.o
 obj-$(CONFIG_RTC_DRV_X1205)	+= rtc-x1205.o
 obj-$(CONFIG_RTC_DRV_SIRFSOC)	+= rtc-sirfsoc.o
+obj-$(CONFIG_RTC_DRV_MOXART)	+= rtc-moxart.o
diff --git a/drivers/rtc/rtc-moxart.c b/drivers/rtc/rtc-moxart.c
new file mode 100644
index 0000000..c29dee0
--- /dev/null
+++ b/drivers/rtc/rtc-moxart.c
@@ -0,0 +1,330 @@
+/*
+ * MOXA ART RTC driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/rtc.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+
+#define GPIO_RTC_RESERVED			0x0C
+#define GPIO_RTC_DATA_SET			0x10
+#define GPIO_RTC_DATA_CLEAR			0x14
+#define GPIO_RTC_PIN_PULL_ENABLE		0x18
+#define GPIO_RTC_PIN_PULL_TYPE			0x1C
+#define GPIO_RTC_INT_ENABLE			0x20
+#define GPIO_RTC_INT_RAW_STATE			0x24
+#define GPIO_RTC_INT_MASKED_STATE		0x28
+#define GPIO_RTC_INT_MASK			0x2C
+#define GPIO_RTC_INT_CLEAR			0x30
+#define GPIO_RTC_INT_TRIGGER			0x34
+#define GPIO_RTC_INT_BOTH			0x38
+#define GPIO_RTC_INT_RISE_NEG			0x3C
+#define GPIO_RTC_BOUNCE_ENABLE			0x40
+#define GPIO_RTC_BOUNCE_PRE_SCALE		0x44
+#define GPIO_RTC_PROTECT_W			0x8E
+#define GPIO_RTC_PROTECT_R			0x8F
+#define GPIO_RTC_YEAR_W				0x8C
+#define GPIO_RTC_YEAR_R				0x8D
+#define GPIO_RTC_DAY_W				0x8A
+#define GPIO_RTC_DAY_R				0x8B
+#define GPIO_RTC_MONTH_W			0x88
+#define GPIO_RTC_MONTH_R			0x89
+#define GPIO_RTC_DATE_W				0x86
+#define GPIO_RTC_DATE_R				0x87
+#define GPIO_RTC_HOURS_W			0x84
+#define GPIO_RTC_HOURS_R			0x85
+#define GPIO_RTC_MINUTES_W			0x82
+#define GPIO_RTC_MINUTES_R			0x83
+#define GPIO_RTC_SECONDS_W			0x80
+#define GPIO_RTC_SECONDS_R			0x81
+#define GPIO_RTC_DELAY_TIME			8
+
+struct moxart_rtc {
+	struct rtc_device *rtc;
+	spinlock_t rtc_lock;
+	int gpio_data, gpio_sclk, gpio_reset;
+};
+
+static int day_of_year[12] =	{ 0, 31, 59, 90, 120, 151, 181,
+				  212, 243, 273, 304, 334 };
+
+static void moxart_rtc_write_byte(struct device *dev, u8 data)
+{
+	struct moxart_rtc *moxart_rtc = dev_get_drvdata(dev);
+	int i;
+
+	for (i = 0; i < 8; i++, data >>= 1) {
+		gpio_set_value(moxart_rtc->gpio_sclk, 0);
+		gpio_set_value(moxart_rtc->gpio_data, ((data & 1) == 1));
+		udelay(GPIO_RTC_DELAY_TIME);
+		gpio_set_value(moxart_rtc->gpio_sclk, 1);
+		udelay(GPIO_RTC_DELAY_TIME);
+	}
+}
+
+static u8 moxart_rtc_read_byte(struct device *dev)
+{
+	struct moxart_rtc *moxart_rtc = dev_get_drvdata(dev);
+	int i;
+	u8 data = 0;
+
+	for (i = 0; i < 8; i++) {
+		gpio_set_value(moxart_rtc->gpio_sclk, 0);
+		udelay(GPIO_RTC_DELAY_TIME);
+		gpio_set_value(moxart_rtc->gpio_sclk, 1);
+		udelay(GPIO_RTC_DELAY_TIME);
+		if (gpio_get_value(moxart_rtc->gpio_data))
+			data |= (1 << i);
+		udelay(GPIO_RTC_DELAY_TIME);
+	}
+	return data;
+}
+
+static u8 moxart_rtc_read_register(struct device *dev, u8 cmd)
+{
+	struct moxart_rtc *moxart_rtc = dev_get_drvdata(dev);
+	u8 data;
+	unsigned long flags;
+
+	local_irq_save(flags);
+
+	gpio_direction_output(moxart_rtc->gpio_data, 0);
+	gpio_set_value(moxart_rtc->gpio_reset, 1);
+	udelay(GPIO_RTC_DELAY_TIME);
+	moxart_rtc_write_byte(dev, cmd);
+	gpio_direction_input(moxart_rtc->gpio_data);
+	udelay(GPIO_RTC_DELAY_TIME);
+	data = moxart_rtc_read_byte(dev);
+	gpio_set_value(moxart_rtc->gpio_sclk, 0);
+	gpio_set_value(moxart_rtc->gpio_reset, 0);
+	udelay(GPIO_RTC_DELAY_TIME);
+
+	local_irq_restore(flags);
+
+	return data;
+}
+
+static void moxart_rtc_write_register(struct device *dev, u8 cmd, u8 data)
+{
+	struct moxart_rtc *moxart_rtc = dev_get_drvdata(dev);
+	unsigned long flags;
+
+	local_irq_save(flags);
+
+	gpio_direction_output(moxart_rtc->gpio_data, 0);
+	gpio_set_value(moxart_rtc->gpio_reset, 1);
+	udelay(GPIO_RTC_DELAY_TIME);
+	moxart_rtc_write_byte(dev, cmd);
+	moxart_rtc_write_byte(dev, data);
+	gpio_set_value(moxart_rtc->gpio_sclk, 0);
+	gpio_set_value(moxart_rtc->gpio_reset, 0);
+	udelay(GPIO_RTC_DELAY_TIME);
+
+	local_irq_restore(flags);
+}
+
+static int moxart_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+	struct moxart_rtc *moxart_rtc = dev_get_drvdata(dev);
+
+	spin_lock_irq(&moxart_rtc->rtc_lock);
+
+	moxart_rtc_write_register(dev, GPIO_RTC_PROTECT_W, 0);
+	moxart_rtc_write_register(dev, GPIO_RTC_YEAR_W,
+				  (((tm->tm_year - 100) / 10) << 4) |
+				  ((tm->tm_year - 100) % 10));
+
+	moxart_rtc_write_register(dev, GPIO_RTC_MONTH_W,
+				  (((tm->tm_mon + 1) / 10) << 4) |
+				  ((tm->tm_mon + 1) % 10));
+
+	moxart_rtc_write_register(dev, GPIO_RTC_DATE_W,
+				  ((tm->tm_mday / 10) << 4) |
+				  (tm->tm_mday % 10));
+
+	moxart_rtc_write_register(dev, GPIO_RTC_HOURS_W,
+				  ((tm->tm_hour / 10) << 4) |
+				  (tm->tm_hour % 10));
+
+	moxart_rtc_write_register(dev, GPIO_RTC_MINUTES_W,
+				  ((tm->tm_min / 10) << 4) |
+				  (tm->tm_min % 10));
+
+	moxart_rtc_write_register(dev, GPIO_RTC_SECONDS_W,
+				  ((tm->tm_sec / 10) << 4) |
+				  (tm->tm_sec % 10));
+
+	moxart_rtc_write_register(dev, GPIO_RTC_PROTECT_W, 0x80);
+
+	spin_unlock_irq(&moxart_rtc->rtc_lock);
+
+	dev_dbg(dev, "%s: success tm_year=%d tm_mon=%d\n"
+		"tm_mday=%d tm_hour=%d tm_min=%d tm_sec=%d\n",
+		__func__, tm->tm_year, tm->tm_mon, tm->tm_mday,
+		tm->tm_hour, tm->tm_min, tm->tm_sec);
+
+	return 0;
+}
+
+static int moxart_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+	struct moxart_rtc *moxart_rtc = dev_get_drvdata(dev);
+	unsigned char v;
+
+	spin_lock_irq(&moxart_rtc->rtc_lock);
+
+	v = moxart_rtc_read_register(dev, GPIO_RTC_SECONDS_R);
+	tm->tm_sec = (((v & 0x70) >> 4) * 10) + (v & 0x0F);
+
+	v = moxart_rtc_read_register(dev, GPIO_RTC_MINUTES_R);
+	tm->tm_min = (((v & 0x70) >> 4) * 10) + (v & 0x0F);
+
+	v = moxart_rtc_read_register(dev, GPIO_RTC_HOURS_R);
+	if (v & 0x80) { /* 12-hour mode */
+		tm->tm_hour = (((v & 0x10) >> 4) * 10) + (v & 0x0F);
+		if (v & 0x20) { /* PM mode */
+			tm->tm_hour += 12;
+			if (tm->tm_hour >= 24)
+				tm->tm_hour = 0;
+		}
+	} else { /* 24-hour mode */
+		tm->tm_hour = (((v & 0x30) >> 4) * 10) + (v & 0x0F);
+	}
+
+	v = moxart_rtc_read_register(dev, GPIO_RTC_DATE_R);
+	tm->tm_mday = (((v & 0x30) >> 4) * 10) + (v & 0x0F);
+
+	v = moxart_rtc_read_register(dev, GPIO_RTC_MONTH_R);
+	tm->tm_mon = (((v & 0x10) >> 4) * 10) + (v & 0x0F);
+	tm->tm_mon--;
+
+	v = moxart_rtc_read_register(dev, GPIO_RTC_YEAR_R);
+	tm->tm_year = (((v & 0xF0) >> 4) * 10) + (v & 0x0F);
+	tm->tm_year += 100;
+	if (tm->tm_year <= 69)
+		tm->tm_year += 100;
+
+	v = moxart_rtc_read_register(dev, GPIO_RTC_DAY_R);
+	tm->tm_wday = (v & 0x0f) - 1;
+	tm->tm_yday = day_of_year[tm->tm_mon];
+	tm->tm_yday += (tm->tm_mday - 1);
+	if (tm->tm_mon >= 2) {
+		if (!(tm->tm_year % 4) && (tm->tm_year % 100))
+			tm->tm_yday++;
+	}
+
+	tm->tm_isdst = 0;
+
+	spin_unlock_irq(&moxart_rtc->rtc_lock);
+
+	return 0;
+}
+
+static const struct rtc_class_ops moxart_rtc_ops = {
+	.read_time	= moxart_rtc_read_time,
+	.set_time	= moxart_rtc_set_time,
+};
+
+static int moxart_rtc_probe(struct platform_device *pdev)
+{
+	struct moxart_rtc *moxart_rtc;
+	int ret = 0;
+
+	moxart_rtc = devm_kzalloc(&pdev->dev, sizeof(*moxart_rtc), GFP_KERNEL);
+	if (!moxart_rtc) {
+		dev_err(&pdev->dev, "devm_kzalloc failed\n");
+		return -ENOMEM;
+	}
+
+	moxart_rtc->gpio_data = of_get_named_gpio(pdev->dev.of_node,
+						  "gpio-rtc-data", 0);
+	if (!gpio_is_valid(moxart_rtc->gpio_data)) {
+		dev_err(&pdev->dev, "invalid gpio (data): %d\n",
+			moxart_rtc->gpio_data);
+		return moxart_rtc->gpio_data;
+	}
+
+	moxart_rtc->gpio_sclk = of_get_named_gpio(pdev->dev.of_node,
+						  "gpio-rtc-sclk", 0);
+	if (!gpio_is_valid(moxart_rtc->gpio_sclk)) {
+		dev_err(&pdev->dev, "invalid gpio (sclk): %d\n",
+			moxart_rtc->gpio_sclk);
+		return moxart_rtc->gpio_sclk;
+	}
+
+	moxart_rtc->gpio_reset = of_get_named_gpio(pdev->dev.of_node,
+						   "gpio-rtc-reset", 0);
+	if (!gpio_is_valid(moxart_rtc->gpio_reset)) {
+		dev_err(&pdev->dev, "invalid gpio (reset): %d\n",
+			moxart_rtc->gpio_reset);
+		return moxart_rtc->gpio_reset;
+	}
+
+	spin_lock_init(&moxart_rtc->rtc_lock);
+	platform_set_drvdata(pdev, moxart_rtc);
+
+	ret = devm_gpio_request(&pdev->dev, moxart_rtc->gpio_data, "rtc_data");
+	if (ret) {
+		dev_err(&pdev->dev, "can't get rtc_data gpio\n");
+		return ret;
+	}
+
+	ret = devm_gpio_request_one(&pdev->dev, moxart_rtc->gpio_sclk,
+				    GPIOF_DIR_OUT, "rtc_sclk");
+	if (ret) {
+		dev_err(&pdev->dev, "can't get rtc_sclk gpio\n");
+		return ret;
+	}
+
+	ret = devm_gpio_request_one(&pdev->dev, moxart_rtc->gpio_reset,
+				    GPIOF_DIR_OUT, "rtc_reset");
+	if (ret) {
+		dev_err(&pdev->dev, "can't get rtc_reset gpio\n");
+		return ret;
+	}
+
+	moxart_rtc->rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
+						   &moxart_rtc_ops,
+						   THIS_MODULE);
+	if (IS_ERR(moxart_rtc->rtc)) {
+		dev_err(&pdev->dev, "devm_rtc_device_register failed\n");
+		return PTR_ERR(moxart_rtc->rtc);
+	}
+
+	return 0;
+}
+
+static const struct of_device_id moxart_rtc_match[] = {
+	{ .compatible = "moxa,moxart-rtc" },
+	{ },
+};
+
+static struct platform_driver moxart_rtc_driver = {
+	.probe	= moxart_rtc_probe,
+	.driver	= {
+		.name		= "moxart-rtc",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_rtc_match,
+	},
+};
+module_platform_driver(moxart_rtc_driver);
+
+MODULE_DESCRIPTION("MOXART RTC driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From linux at arm.linux.org.uk  Wed Jul 17 05:15:19 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 10:15:19 +0100
Subject: sched_clock always 0 and no process time accounting with 3.11-rc1
In-Reply-To: <20130717091209.GL6950@tarshish>
References: <CAMo8BfLO31GgMMA_hENr0xm=qaUz3EVLtaQ8hewiQHdbV+s6sA@mail.gmail.com>
 <20130717061925.GC6950@tarshish>
 <20130717090354.GK24642@n2100.arm.linux.org.uk>
 <20130717091209.GL6950@tarshish>
Message-ID: <20130717091519.GL24642@n2100.arm.linux.org.uk>

On Wed, Jul 17, 2013 at 12:12:09PM +0300, Baruch Siach wrote:
> Hi Russell,
> 
> On Wed, Jul 17, 2013 at 10:03:55AM +0100, Russell King - ARM Linux wrote:
> > On Wed, Jul 17, 2013 at 09:19:25AM +0300, Baruch Siach wrote:
> > > Apparently the expression '(1 << 32)' evaluates to 1 on xtensa cross gcc, and 
> > > x86_84 native gcc. According to my limited understanding, the C compiler is 
> > > allowed to do so. This caused sched_clock_32() to return constant 0. I wonder 
> > > how it didn't bite the ARM people who are using this code from quite some time 
> > > (added LAKL to CC).
> > 
> > It (a) used to be only 32-bit, and (b) <<32 on ARM evaluates to zero in
> > a 32-bit context (it's not a rotate).
> > 
> > Patch looks fine.
> 
> Thanks for the confirmation, I'll take it as an ack if you don't mind.

If you want it as an ack, use rmk+kernel at arm.linux.org.uk as the email
address please.


From pawel.moll at arm.com  Wed Jul 17 05:18:25 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Wed, 17 Jul 2013 10:18:25 +0100
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1374052705.3146.86.camel@hornet>

On Tue, 2013-07-16 at 17:05 +0100, Lorenzo Pieralisi wrote:
> /drivers/mfd is probably not the right place for this code as it stands (but
> probably will be when the entire driver, with DVFS and config interface, is
> complete).

Not that it really matters now, but my vexpress-sysreg rework will -
most likely - leave only skeleton in the MFD (registering mfd_cells) and
other stuff is going to be spread all around. Then I'm planning to move
the remaining of the vexpress-specific initialization to
drivers/platform/arm/vexpress.c, so maybe sticking vexpress-spc.c to
this (non-existing yet) directory would be the right thing to do?

Other than that:

Acked-by: Pawel Moll <pawel.moll at arm.com>

Thanks!

Pawe?




From jonas.jensen at gmail.com  Wed Jul 17 05:24:51 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 17 Jul 2013 11:24:51 +0200
Subject: [PATCH v3] watchdog: Add MOXA ART watchdog driver
In-Reply-To: <1373981055-18515-1-git-send-email-jonas.jensen@gmail.com>
References: <1373981055-18515-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1374053091-5907-1-git-send-email-jonas.jensen@gmail.com>

Add watchdog driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v2:
    
    1. add devicetree bindings document
    
    Applies to next-20130716

 .../bindings/watchdog/moxa,moxart-watchdog.txt     |  15 ++
 drivers/watchdog/Kconfig                           |  10 ++
 drivers/watchdog/Makefile                          |   1 +
 drivers/watchdog/moxart_wdt.c                      | 171 +++++++++++++++++++++
 4 files changed, 197 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
 create mode 100644 drivers/watchdog/moxart_wdt.c

diff --git a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
new file mode 100644
index 0000000..fb99e50
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
@@ -0,0 +1,15 @@
+MOXA ART Watchdog timer
+
+Required properties:
+
+- compatible : Should be "moxa,moxart-watchdog"
+- reg : Should contain registers location and length
+- clocks : Should contain phandle for APB clock "clkapb"
+
+Example:
+
+	watchdog: watchdog at 98500000 {
+		compatible = "moxa,moxart-watchdog";
+		reg = <0x98500000 0x10>;
+		clocks = <&clkapb>;
+	};
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 362085d..6883aab 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -382,6 +382,16 @@ config RETU_WATCHDOG
 	  To compile this driver as a module, choose M here: the
 	  module will be called retu_wdt.
 
+config MOXART_WDT
+	tristate "MOXART watchdog"
+	depends on ARCH_MOXART
+	help
+	  Say Y here to include Watchdog timer support for the watchdog
+	  existing on the MOXA ART SoC series platforms.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called moxart_wdt.
+
 # AVR32 Architecture
 
 config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 2f26a0b..7cab53a 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
 obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
 obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
 obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
+obj-$(CONFIG_MOXART_WDT) += moxart_wdt.o
 
 # AVR32 Architecture
 obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
new file mode 100644
index 0000000..966855d
--- /dev/null
+++ b/drivers/watchdog/moxart_wdt.c
@@ -0,0 +1,171 @@
+/*
+ * MOXA ART SoCs watchdog driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+#include <linux/watchdog.h>
+
+#include <asm/system_misc.h>
+
+#define REG_COUNT			0x4
+#define REG_MODE			0x8
+#define REG_ENABLE			0xC
+
+struct moxart_wdt_dev {
+	struct watchdog_device wdt_dev;
+	void __iomem *wdt_base;
+};
+
+static struct moxart_wdt_dev *moxart_wdt;
+static bool nowayout = WATCHDOG_NOWAYOUT;
+static int heartbeat;
+static unsigned int clock_frequency;
+static unsigned int max_timeout;
+
+static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+	void __iomem *wdt_base = moxart_wdt->wdt_base;
+
+	writel(0, wdt_base + REG_ENABLE);
+
+	return 0;
+}
+
+static int moxart_wdt_start(struct watchdog_device *wdt_dev)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+	void __iomem *wdt_base = moxart_wdt->wdt_base;
+
+	writel(clock_frequency * moxart_wdt->wdt_dev.timeout,
+	       wdt_base + REG_COUNT);
+	writel(0x5ab9, wdt_base + REG_MODE);
+	writel(0x03, wdt_base + REG_ENABLE);
+
+	return 0;
+}
+
+static int moxart_wdt_set_timeout(struct watchdog_device *wdt_dev,
+				  unsigned int timeout)
+{
+	dev_dbg(wdt_dev->dev, "%s: timeout=%u\n", __func__, timeout);
+
+	moxart_wdt->wdt_dev.timeout = timeout;
+
+	return 0;
+}
+
+static const struct watchdog_info moxart_wdt_info = {
+	.identity       = "moxart-wdt",
+	.options        = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
+static const struct watchdog_ops moxart_wdt_ops = {
+	.owner          = THIS_MODULE,
+	.start          = moxart_wdt_start,
+	.stop           = moxart_wdt_stop,
+	.set_timeout    = moxart_wdt_set_timeout,
+};
+
+static int moxart_wdt_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct resource *res;
+	struct clk *clk;
+	int err;
+
+	moxart_wdt = devm_kzalloc(&pdev->dev, sizeof(*moxart_wdt), GFP_KERNEL);
+	if (!moxart_wdt)
+		return -EINVAL;
+
+	platform_set_drvdata(pdev, moxart_wdt);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	moxart_wdt->wdt_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_wdt->wdt_base))
+		return PTR_ERR(moxart_wdt->wdt_base);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk)) {
+		pr_err("%s: of_clk_get failed\n", __func__);
+		return PTR_ERR(clk);
+	}
+
+	clock_frequency = clk_get_rate(clk);
+
+	max_timeout = UINT_MAX / clock_frequency;
+
+	moxart_wdt->wdt_dev.info = &moxart_wdt_info;
+	moxart_wdt->wdt_dev.ops = &moxart_wdt_ops;
+	moxart_wdt->wdt_dev.timeout = max_timeout;
+	moxart_wdt->wdt_dev.min_timeout = 1;
+	moxart_wdt->wdt_dev.max_timeout = max_timeout;
+	moxart_wdt->wdt_dev.parent = &pdev->dev;
+
+	watchdog_init_timeout(&moxart_wdt->wdt_dev, heartbeat, &pdev->dev);
+	watchdog_set_nowayout(&moxart_wdt->wdt_dev, nowayout);
+
+	watchdog_set_drvdata(&moxart_wdt->wdt_dev, moxart_wdt);
+
+	err = watchdog_register_device(&moxart_wdt->wdt_dev);
+	if (unlikely(err))
+		return err;
+
+	dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
+		moxart_wdt->wdt_dev.timeout, nowayout);
+
+	return 0;
+}
+
+static int moxart_wdt_remove(struct platform_device *pdev)
+{
+	struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
+
+	moxart_wdt_stop(&moxart_wdt->wdt_dev);
+	watchdog_unregister_device(&moxart_wdt->wdt_dev);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_watchdog_match[] = {
+	{ .compatible = "moxa,moxart-watchdog" },
+	{ },
+};
+
+static struct platform_driver moxart_wdt_driver = {
+	.probe      = moxart_wdt_probe,
+	.remove     = moxart_wdt_remove,
+	.driver     = {
+		.name		= "moxart-watchdog",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_watchdog_match,
+	},
+};
+module_platform_driver(moxart_wdt_driver);
+
+module_param(heartbeat, int, 0);
+MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");
+
+MODULE_DESCRIPTION("MOXART watchdog driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From pawel.moll at arm.com  Wed Jul 17 05:26:47 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Wed, 17 Jul 2013 10:26:47 +0100
Subject: [PATCH RFC v2 08/14] ARM: debug: provide PL01x debug uart
 phys/virt address configuration options
In-Reply-To: <E1Uz8JM-00047w-PP@rmk-PC.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
 <E1Uz8JM-00047w-PP@rmk-PC.arm.linux.org.uk>
Message-ID: <1374053207.3146.90.camel@hornet>

On Tue, 2013-07-16 at 17:41 +0100, Russell King wrote:
> Move the definition of the UART register addresses out of the platform
> specific header files into the Kconfig files.
> 
> Acked-by: Ryan Mallon <rmallon at gmail.com>
> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>

For the vexpress parts:

Acked-by: Pawel Moll <pawel.moll at arm.com>




From kishon at ti.com  Wed Jul 17 05:32:59 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 17 Jul 2013 15:02:59 +0530
Subject: [PATCH v9 1/8] drivers: phy: add generic PHY framework
In-Reply-To: <20130717062944.GA24968@kroah.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <1372247257-30186-2-git-send-email-kishon@ti.com>
 <20130717062944.GA24968@kroah.com>
Message-ID: <51E664CB.8050906@ti.com>

Hi,

On Wednesday 17 July 2013 11:59 AM, Greg KH wrote:
> On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
>> +menuconfig GENERIC_PHY
>> +	tristate "PHY Subsystem"
>> +	help
>> +	  Generic PHY support.
>> +
>> +	  This framework is designed to provide a generic interface for PHY
>> +	  devices present in the kernel. This layer will have the generic
>> +	  API by which phy drivers can create PHY using the phy framework and
>> +	  phy users can obtain reference to the PHY.
> 
> Shouldn't this be something that other drivers select?  How will anyone
> know if they need this or not?

All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those
PHY drivers can be selected like in [1].
The PHY consumer driver should ideally use *depends on* in their Kconfig.

[1] ->
http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> 
>> --- /dev/null
>> +++ b/drivers/phy/phy-core.c
>> @@ -0,0 +1,544 @@
>> +/*
>> + * phy-core.c  --  Generic Phy framework.
>> + *
>> + * Copyright (C) 2013 Texas Instruments
>> + *
>> + * Author: Kishon Vijay Abraham I <kishon at ti.com>
>> + *
>> + * This program is free software; you can redistribute  it and/or modify it
>> + * under  the terms of  the GNU General  Public License as published by the
>> + * Free Software Foundation;  either version 2 of the  License, or (at your
>> + * option) any later version.
> 
> You really mean "any later version" (I have to ask)?

That was copied from somewhere :-s
> 
>> + * 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> 
> Are these two paragraphs needed?  This isn't a "program", and they got a
> copy of the GPL already with the kernel.

hmm.. I can remove that.
> 
>> +static struct class *phy_class;
> 
> Why do you need a class?

Wanted to group all the PHY drivers to be used by different subsystems
(SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
initial version [3] on using a bus_type instead of class but then it was
decided to go with class itself.

[3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
> 
> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
> entry as well.

I'm not actually adding any new sysfs entry other than what a *class_create*
must have created. Do I need to add one for that?

Thanks
Kishon


From jonas.jensen at gmail.com  Wed Jul 17 05:34:53 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 17 Jul 2013 11:34:53 +0200
Subject: [PATCH v3] gpio: Add MOXA ART GPIO driver
In-Reply-To: <1373976052-16779-1-git-send-email-jonas.jensen@gmail.com>
References: <1373976052-16779-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1374053693-6166-1-git-send-email-jonas.jensen@gmail.com>

Add GPIO driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v2:
    
    1. add devicetree bindings document
    
    Applies to next-20130716

 .../devicetree/bindings/gpio/moxa,moxart-gpio.txt  |  23 +++
 drivers/gpio/Kconfig                               |   7 +
 drivers/gpio/Makefile                              |   1 +
 drivers/gpio/gpio-moxart.c                         | 189 +++++++++++++++++++++
 4 files changed, 220 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt
 create mode 100644 drivers/gpio/gpio-moxart.c

diff --git a/Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt b/Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt
new file mode 100644
index 0000000..496c081
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt
@@ -0,0 +1,23 @@
+MOXA ART GPIO Controller
+
+Required properties:
+
+- #gpio-cells : Should be 2
+- compatible : Should be "moxa,moxart-gpio"
+- reg : Should contain registers location and length
+	index 0 : input, output, and direction control
+	index 1 : enable/disable individual pins, pin 0-31
+- gpio-ready-led : ready LED gpio, with zero flags
+- gpio-reset-switch : reset switch gpio, with zero flags
+
+Example:
+
+	gpio: gpio at 98700000 {
+		gpio-controller;
+		#gpio-cells = <2>;
+		compatible = "moxa,moxart-gpio";
+		reg =	<0x98700000 0xC>,
+			<0x98100100 0x4>;
+		gpio-ready-led = <&gpio 27 0>;
+		gpio-reset-switch = <&gpio 25 0>;
+	};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b2450ba..521fd97 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -714,6 +714,13 @@ config GPIO_MSIC
 	  Enable support for GPIO on intel MSIC controllers found in
 	  intel MID devices
 
+config GPIO_MOXART
+	bool "MOXART GPIO support"
+	depends on ARCH_MOXART
+	help
+	  Select this option to enable GPIO driver for
+	  MOXA ART SoC devices.
+
 comment "USB GPIO expanders:"
 
 config GPIO_VIPERBOARD
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index ef3e983..44b0de4 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_GPIO_MC9S08DZ60)	+= gpio-mc9s08dz60.o
 obj-$(CONFIG_GPIO_MCP23S08)	+= gpio-mcp23s08.o
 obj-$(CONFIG_GPIO_ML_IOH)	+= gpio-ml-ioh.o
 obj-$(CONFIG_GPIO_MM_LANTIQ)	+= gpio-mm-lantiq.o
+obj-$(CONFIG_GPIO_MOXART)	+= gpio-moxart.o
 obj-$(CONFIG_GPIO_MPC5200)	+= gpio-mpc5200.o
 obj-$(CONFIG_GPIO_MPC8XXX)	+= gpio-mpc8xxx.o
 obj-$(CONFIG_GPIO_MSIC)		+= gpio-msic.o
diff --git a/drivers/gpio/gpio-moxart.c b/drivers/gpio/gpio-moxart.c
new file mode 100644
index 0000000..19d4e3b
--- /dev/null
+++ b/drivers/gpio/gpio-moxart.c
@@ -0,0 +1,189 @@
+/*
+ * MOXA ART SoCs GPIO driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/io.h>
+#include <linux/gpio.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_gpio.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/delay.h>
+#include <linux/timer.h>
+
+#define GPIO_DATA_OUT		0x00
+#define GPIO_DATA_IN		0x04
+#define GPIO_PIN_DIRECTION	0x08
+
+static void __iomem *moxart_pincontrol_base;
+static void __iomem *moxart_gpio_base;
+
+void moxart_gpio_enable(u32 gpio)
+{
+	writel(readl(moxart_pincontrol_base) | gpio, moxart_pincontrol_base);
+}
+
+void moxart_gpio_disable(u32 gpio)
+{
+	writel(readl(moxart_pincontrol_base) & ~gpio, moxart_pincontrol_base);
+}
+
+static int moxart_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+	moxart_gpio_enable(1 << offset);
+	return pinctrl_request_gpio(offset);
+}
+
+static void moxart_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+	pinctrl_free_gpio(offset);
+	moxart_gpio_disable(1 << offset);
+}
+
+static int moxart_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+	void __iomem *ioaddr = moxart_gpio_base + GPIO_PIN_DIRECTION;
+
+	writel(readl(ioaddr) & ~(1 << offset), ioaddr);
+	return 0;
+}
+
+static int moxart_gpio_direction_output(struct gpio_chip *chip,
+					unsigned offset, int value)
+{
+	void __iomem *ioaddr = moxart_gpio_base + GPIO_PIN_DIRECTION;
+
+	writel(readl(ioaddr) | (1 << offset), ioaddr);
+	return 0;
+}
+
+static void moxart_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+	void __iomem *ioaddr = moxart_gpio_base + GPIO_DATA_OUT;
+	u32 reg = readl(ioaddr);
+
+	(value) ?	writel(reg | (1 << offset), ioaddr) :
+			writel(reg & ~(1 << offset), ioaddr);
+}
+
+static int moxart_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+	u32 ret = readl(moxart_gpio_base + GPIO_PIN_DIRECTION);
+
+	if (ret & (1 << offset))
+		ret = readl(moxart_gpio_base + GPIO_DATA_OUT) & (1 << offset);
+	else
+		ret = readl(moxart_gpio_base + GPIO_DATA_IN) & (1 << offset);
+
+	return ret;
+}
+
+static struct gpio_chip moxart_gpio_chip = {
+	.label			= "moxart-gpio",
+	.request		= moxart_gpio_request,
+	.free			= moxart_gpio_free,
+	.direction_input	= moxart_gpio_direction_input,
+	.direction_output	= moxart_gpio_direction_output,
+	.set			= moxart_gpio_set,
+	.get			= moxart_gpio_get,
+	.base			= 0,
+	.ngpio			= 32,
+	.can_sleep		= 0,
+};
+
+static int moxart_gpio_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct resource *res;
+	int ret, gpio_ready_led, gpio_reset_switch;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	moxart_gpio_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_gpio_base)) {
+		dev_err(dev, "%s: devm_ioremap_resource res_gpio failed\n",
+			dev->of_node->full_name);
+		return PTR_ERR(moxart_gpio_base);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	moxart_pincontrol_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_pincontrol_base)) {
+		dev_err(dev, "%s: devm_ioremap_resource res_pmu failed\n",
+			dev->of_node->full_name);
+		return PTR_ERR(moxart_pincontrol_base);
+	}
+
+	moxart_gpio_chip.dev = dev;
+
+	ret = gpiochip_add(&moxart_gpio_chip);
+	if (ret)
+		dev_err(dev, "%s: gpiochip_add failed\n",
+			dev->of_node->full_name);
+
+
+	gpio_ready_led = of_get_named_gpio(pdev->dev.of_node,
+					   "gpio-ready-led", 0);
+	if (!gpio_is_valid(gpio_ready_led)) {
+		dev_err(&pdev->dev, "invalid gpio (gpio-ready-led): %d\n",
+			gpio_ready_led);
+		return gpio_ready_led;
+	}
+
+	gpio_reset_switch = of_get_named_gpio(pdev->dev.of_node,
+					      "gpio-reset-switch", 0);
+	if (!gpio_is_valid(gpio_reset_switch)) {
+		dev_err(&pdev->dev, "invalid gpio (gpio-reset-switch): %d\n",
+			gpio_reset_switch);
+		return gpio_reset_switch;
+	}
+
+	moxart_gpio_enable(gpio_ready_led | gpio_reset_switch);
+
+	moxart_gpio_direction_input(&moxart_gpio_chip, gpio_reset_switch);
+
+	/*
+	 * gpio_ready_led=0 ready LED on
+	 * gpio_ready_led=1 ready LED off
+	 */
+	moxart_gpio_direction_output(&moxart_gpio_chip, gpio_ready_led, 0);
+	moxart_gpio_set(&moxart_gpio_chip, gpio_ready_led, 0);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_gpio_match[] = {
+	{ .compatible = "moxa,moxart-gpio" },
+	{ }
+};
+
+static struct platform_driver moxart_gpio_driver = {
+	.driver	= {
+		.name		= "moxart-gpio",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_gpio_match,
+	},
+	.probe	= moxart_gpio_probe,
+};
+
+static int __init moxart_gpio_init(void)
+{
+	return platform_driver_register(&moxart_gpio_driver);
+}
+
+postcore_initcall(moxart_gpio_init);
+
+MODULE_DESCRIPTION("MOXART GPIO chip driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From damien.riegel.ext at parrot.com  Wed Jul 17 05:45:32 2013
From: damien.riegel.ext at parrot.com (Damien Riegel)
Date: Wed, 17 Jul 2013 11:45:32 +0200
Subject: Issue with gpio and pinmux
Message-ID: <51E667BC.3070804@parrot.com>

Hi,


In our ARM-based SoC, we can multiplex up to 4 functions on each pin,
but we have an issue when using a pin as a gpio: it can still be muxed
as another function.

In the gpio driver, we delegate calls to "request" to
"pinctrl_request_gpio":

	static int p7gpio_request(struct gpio_chip *chip, unsigned int offset)
	{
		return pinctrl_request_gpio(chip->base + offset);
	}

	static const struct gpio_chip p7gpio_chip_defaults = {
		.request            = p7gpio_request,
		[...]
	};

pinctrl_request_gpio will result in a call to pin_request, which behaves
differently if we request a gpio or another function, so at kernel
level they are not exclusive, but at hardware level they must be.

To avoid conflicts, the workaround I use is to implement "request" and
"gpio_request_enable" as below in a pinctrl driver to make mux and gpio
exclusive. But I really feel like I should not do so and let the kernel
do this for me.

	static int p7ctl_enable_gpio(struct pinctrl_dev* pctl,
					struct pinctrl_gpio_range* range,
					unsigned int gpio)
	{
		struct pin_desc *desc;
		desc = pin_desc_get(pctl, gpio);
		if (desc->mux_owner)
			return -EBUSY;
		
		[...]
	}

	static int p7ctl_request(struct pinctrl_dev* pctl, unsigned int pin)
	{
		struct pin_desc *desc;
		desc = pin_desc_get(pctl, pin);
		if (desc->gpio_owner)
			return -EBUSY;

		return 0;
	}

	static struct pinmux_ops p7ctl_mux_ops = {
		.request                = p7ctl_request,
		.gpio_request_enable    = p7ctl_enable_gpio,
		[...]
	};

Is this solution correct or is there a better way to claim the mux when
using a pin as a gpio ?

Note: we are using a kernel based on 3.4.11, but as far as I can tell,
pinctrl_request_gpio have the same behavior in the upstream kernel.


Thanks,
Damien


From broonie at kernel.org  Wed Jul 17 05:47:18 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Jul 2013 10:47:18 +0100
Subject: [PATCH 1/3] ASoC: bt-sco: enable OF support
In-Reply-To: <20130717084039.GA15981@e106331-lin.cambridge.arm.com>
References: <1374041536-27643-1-git-send-email-Baohua.Song@csr.com>
 <20130717084039.GA15981@e106331-lin.cambridge.arm.com>
Message-ID: <20130717094718.GE22506@sirena.org.uk>

On Wed, Jul 17, 2013 at 09:40:39AM +0100, Mark Rutland wrote:
> On Wed, Jul 17, 2013 at 07:12:14AM +0100, Barry Song wrote:

> > this makes users be able to add a bt-sco node in dts instead of
> > hardcoding a platform device in mach.

> I'm slightly confused by this. The driver doesn't seem to pick up any
> information out of the dts, and the binding doesn't even describe any
> linkage to a piece of hardware. I'm not familiar with bluetooth or ASoC,
> could you give an explanation as to why this is needed?

> I don't think this should be in the dt as is. Could this not be
> registered based on the presence of a bluetooth controller that supports
> this?

Audio devices are linked together by a separate board binding which
specifies how all the different components in the audio subsystem on the
board are wired together.  Even where things have no meanignful software
control (as is the case here and for a lot of simple DACs or ADCs) the
rest of the system needs information on their capabilites and ideally
the ability to interchange them with more substantial devices.  If there
were meaningful control there'd be a control bus here.

There is likely to be a control interface for the BT device hanging off
a UART but it's not clear there's much more meaningful data for those
than there is here.
-------------- 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/20130717/419fecfc/attachment.sig>

From baruch at tkos.co.il  Wed Jul 17 05:46:53 2013
From: baruch at tkos.co.il (Baruch Siach)
Date: Wed, 17 Jul 2013 12:46:53 +0300
Subject: [PATCH] time: sched_clock: fix integer overflow
Message-ID: <232c026d1b8d2556679aea56cf77a6811f9a96c5.1374054369.git.baruch@tkos.co.il>

The expression '(1 << 32)' happens to evaluate as 0 on ARM, but it evaluates as
1 on xtensa and x86_64. This zeros sched_clock_mask, and breaks sched_clock().
Set the type of 1 to 'unsigned long long' to get the value we need.

Reported-by: Max Filippov <jcmvbkbc at gmail.com>
Tested-by: Max Filippov <jcmvbkbc at gmail.com>
Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>
Signed-off-by: Baruch Siach <baruch at tkos.co.il>
---
 kernel/time/sched_clock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index a326f27..0b479a6 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -121,7 +121,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
 	BUG_ON(bits > 32);
 	WARN_ON(!irqs_disabled());
 	read_sched_clock = read;
-	sched_clock_mask = (1 << bits) - 1;
+	sched_clock_mask = (1ULL << bits) - 1;
 	cd.rate = rate;
 
 	/* calculate the mult/shift to convert counter ticks to ns. */
-- 
1.8.3.2



From oleksandr.kozaruk at ti.com  Wed Jul 17 05:49:40 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Wed, 17 Jul 2013 12:49:40 +0300
Subject: [PATCH 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <c8f86766-822b-4fe3-ae2a-e0b12412ef39@email.android.com>
References: <1373974023-23521-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1373974023-23521-3-git-send-email-oleksandr.kozaruk@ti.com>
 <c8f86766-822b-4fe3-ae2a-e0b12412ef39@email.android.com>
Message-ID: <51E668B4.1010000@ti.com>

Hello Jonathan,

 >Two very quick comments based on quick glance as it may be a while 
before I can do a full review.

 >We still have channels that are only usable for temperature being 
output to user space as voltage channels? Is the conversion so very hard?

Can you please clarify what should return temperature channel for 
in_tempX_input (processed)? Is it voltage or Celsius degree?
in_tempX_raw should return ADC code? Right?

Regards,
OK.


From broonie at kernel.org  Wed Jul 17 05:52:22 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Jul 2013 10:52:22 +0100
Subject: [PATCH 3/3] ASoC: hdmi-codec: let the driver support HDMI sink
In-Reply-To: <1374041536-27643-3-git-send-email-Baohua.Song@csr.com>
References: <1374041536-27643-1-git-send-email-Baohua.Song@csr.com>
 <1374041536-27643-3-git-send-email-Baohua.Song@csr.com>
Message-ID: <20130717095222.GF22506@sirena.org.uk>

On Wed, Jul 17, 2013 at 02:12:16PM +0800, Barry Song wrote:
> From: Rongjun Ying <Rongjun.Ying at csr.com>
> 
> Devices like mobilephones, computers are typically used as
> HDMI sources, but devices like TV, navigators will be HDMI
> sinks.

Applied, thanks.
-------------- 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/20130717/3e21df67/attachment.sig>

From broonie at kernel.org  Wed Jul 17 05:57:08 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Jul 2013 10:57:08 +0100
Subject: [PATCH 2/3] ASoC: hdmi-codec: enable OF support
In-Reply-To: <20130717084910.GB15981@e106331-lin.cambridge.arm.com>
References: <1374041536-27643-1-git-send-email-Baohua.Song@csr.com>
 <1374041536-27643-2-git-send-email-Baohua.Song@csr.com>
 <20130717084910.GB15981@e106331-lin.cambridge.arm.com>
Message-ID: <20130717095708.GG22506@sirena.org.uk>

On Wed, Jul 17, 2013 at 09:49:10AM +0100, Mark Rutland wrote:
> On Wed, Jul 17, 2013 at 07:12:15AM +0100, Barry Song wrote:

> > this makes users be able to add a hdmi-codec node in dts instead of
> > hardcoding a platform device in mach.

> Similarly to my comment on the first patch, I'm not sure this is the
> best way to wire this up to devicetree. Can this not be hung off of hdmi
> controller drivers?

This one is different to the BT case - as you say it's hanging off the
HDMI controller so the HDMI controller ought to enumerate it either as a
stub or by actually seeing a device.  The platform device is fine but
it's not something that should appear in the DT unless it's conveying
some information about what's connected there (eg, power supplies for
something soldered down on the board).
-------------- 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/20130717/2dca995c/attachment.sig>

From broonie at kernel.org  Wed Jul 17 06:06:24 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Jul 2013 11:06:24 +0100
Subject: [PATCH V2 0/2] regulator: palmas-pmic: doc: update device tree
 bindings
In-Reply-To: <1373992870-20725-1-git-send-email-nm@ti.com>
References: <20130716161939.GR22506@sirena.org.uk>
 <1373992870-20725-1-git-send-email-nm@ti.com>
Message-ID: <20130717100624.GJ22506@sirena.org.uk>

On Tue, Jul 16, 2013 at 11:41:08AM -0500, Nishanth Menon wrote:
> We seem to have a few missing updates to device tree bindings with the
> latest set of changes getting merged in.

Applied both, thanks.
-------------- 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/20130717/443b43b4/attachment.sig>

From jonas.jensen at gmail.com  Wed Jul 17 06:06:24 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 17 Jul 2013 12:06:24 +0200
Subject: [PATCH v3] dmaengine: Add MOXA ART DMA engine driver
In-Reply-To: <1373460239-20102-1-git-send-email-jonas.jensen@gmail.com>
References: <1373460239-20102-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1374055584-15746-1-git-send-email-jonas.jensen@gmail.com>

Add dmaengine driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v2:
    
    1. add devicetree bindings document
    2. remove DMA_VIRTUAL_CHANNELS and "default n" from Kconfig
    
    Applies to next-20130716

 .../devicetree/bindings/dma/moxa,moxart-dma.txt    |  19 +
 drivers/dma/Kconfig                                |   7 +
 drivers/dma/Makefile                               |   1 +
 drivers/dma/moxart-dma.c                           | 477 +++++++++++++++++++++
 drivers/dma/moxart-dma.h                           | 188 ++++++++
 5 files changed, 692 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt
 create mode 100644 drivers/dma/moxart-dma.c
 create mode 100644 drivers/dma/moxart-dma.h

diff --git a/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt b/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt
new file mode 100644
index 0000000..61a019d
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt
@@ -0,0 +1,19 @@
+MOXA ART DMA Controller
+
+See dma.txt first
+
+Required properties:
+
+- compatible : Should be "moxa,moxart-dma"
+- reg : Should contain registers location and length
+- interrupts : Should contain the interrupt number
+- #dma-cells : see dma.txt, should be 1
+
+Example:
+
+	dma: dma at 90500000 {
+		compatible = "moxa,moxart-dma";
+		reg = <0x90500000 0x1000>;
+		interrupts = <24 0>;
+		#dma-cells = <1>;
+	};
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..56c3aaa 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -300,6 +300,13 @@ config DMA_JZ4740
 	select DMA_ENGINE
 	select DMA_VIRTUAL_CHANNELS
 
+config MOXART_DMA
+	tristate "MOXART DMA support"
+	depends on ARCH_MOXART
+	select DMA_ENGINE
+	help
+	  Enable support for the MOXA ART SoC DMA controller.
+
 config DMA_ENGINE
 	bool
 
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 5e0f2ef..470c11b 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_MMP_TDMA) += mmp_tdma.o
 obj-$(CONFIG_DMA_OMAP) += omap-dma.o
 obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o
 obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
+obj-$(CONFIG_MOXART_DMA) += moxart-dma.o
diff --git a/drivers/dma/moxart-dma.c b/drivers/dma/moxart-dma.c
new file mode 100644
index 0000000..16fddf4
--- /dev/null
+++ b/drivers/dma/moxart-dma.c
@@ -0,0 +1,477 @@
+/*
+ * MOXA ART SoCs DMA Engine support.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/irq.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+
+#include <asm/cacheflush.h>
+
+#include "dmaengine.h"
+#include "moxart-dma.h"
+
+static DEFINE_SPINLOCK(dma_lock);
+
+struct moxart_dma_chan {
+	struct dma_chan			chan;
+	int				ch_num;
+	bool				allocated;
+	int				error_flag;
+	struct moxart_dma_reg		*reg;
+	void				(*callback)(void *param);
+	void				*callback_param;
+	struct completion		dma_complete;
+	struct dma_slave_config		cfg;
+	struct dma_async_tx_descriptor	tx_desc;
+};
+
+struct moxart_dma_container {
+	int			ctlr;
+	struct dma_device	dma_slave;
+	struct moxart_dma_chan	slave_chans[APB_DMA_MAX_CHANNEL];
+};
+
+struct moxart_dma_container *mdc;
+
+static struct device *chan2dev(struct dma_chan *chan)
+{
+	return &chan->dev->device;
+}
+
+static inline struct moxart_dma_container
+*to_moxart_dma_container(struct dma_device *d)
+{
+	return container_of(d, struct moxart_dma_container, dma_slave);
+}
+
+static inline struct moxart_dma_chan *to_moxart_dma_chan(struct dma_chan *c)
+{
+	return container_of(c, struct moxart_dma_chan, chan);
+}
+
+static int moxart_terminate_all(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+
+	dev_dbg(chan2dev(chan), "%s: mchan=%p\n", __func__, mchan);
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.ul &= ~(APB_DMA_ENABLE | APB_DMA_FIN_INT_EN | APB_DMA_ERR_INT_EN);
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return 0;
+}
+
+static int moxart_slave_config(struct dma_chan *chan,
+			       struct dma_slave_config *cfg)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+	unsigned int data_width, data_inc;
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	memcpy(&mchan->cfg, cfg, sizeof(mchan->cfg));
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.bits.burst = APB_DMAB_BURST_MODE;
+
+	switch (mchan->cfg.src_addr_width) {
+	case DMA_SLAVE_BUSWIDTH_1_BYTE:
+		data_width = APB_DMAB_DATA_WIDTH_1;
+		data_inc = APB_DMAB_DEST_INC_1_4;
+		break;
+	case DMA_SLAVE_BUSWIDTH_2_BYTES:
+		data_width = APB_DMAB_DATA_WIDTH_2;
+		data_inc = APB_DMAB_DEST_INC_2_8;
+		break;
+	default:
+		data_width = APB_DMAB_DATA_WIDTH_4;
+		data_inc = APB_DMAB_DEST_INC_4_16;
+		break;
+	}
+
+	if (mchan->cfg.direction == DMA_MEM_TO_DEV) {
+		mcfg.bits.data_width = data_width;
+		mcfg.bits.dest_sel = APB_DMAB_DEST_APB;
+		mcfg.bits.dest_inc = APB_DMAB_DEST_INC_0;
+		mcfg.bits.source_sel = APB_DMAB_SOURCE_AHB;
+		mcfg.bits.source_inc = data_inc;
+
+		mcfg.bits.dest_req_no = mchan->cfg.slave_id;
+		mcfg.bits.source_req_no = 0;
+	} else {
+		mcfg.bits.data_width = data_width;
+		mcfg.bits.dest_sel = APB_DMAB_SOURCE_AHB;
+		mcfg.bits.dest_inc = data_inc;
+		mcfg.bits.source_sel = APB_DMAB_DEST_APB;
+		mcfg.bits.source_inc = APB_DMAB_DEST_INC_0;
+
+		mcfg.bits.dest_req_no = 0;
+		mcfg.bits.source_req_no = mchan->cfg.slave_id;
+	}
+
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return 0;
+}
+
+static int moxart_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
+			  unsigned long arg)
+{
+	int ret = 0;
+	struct dma_slave_config *config;
+
+	switch (cmd) {
+	case DMA_TERMINATE_ALL:
+		moxart_terminate_all(chan);
+		break;
+	case DMA_SLAVE_CONFIG:
+		config = (struct dma_slave_config *)arg;
+		ret = moxart_slave_config(chan, config);
+		break;
+	default:
+		ret = -ENOSYS;
+	}
+
+	return ret;
+}
+
+static dma_cookie_t moxart_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(tx->chan);
+	dma_cookie_t cookie;
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+
+	mchan->callback = tx->callback;
+	mchan->callback_param = tx->callback_param;
+	mchan->error_flag = 0;
+
+	dev_dbg(chan2dev(tx->chan), "%s: mchan=%p mchan->ch_num=%d mchan->reg=%p\n",
+		__func__, mchan, mchan->ch_num, mchan->reg);
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	cookie = dma_cookie_assign(tx);
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.ul |= (APB_DMA_FIN_INT_EN | APB_DMA_ERR_INT_EN);
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return cookie;
+}
+
+static struct dma_async_tx_descriptor
+*moxart_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
+		      unsigned int sg_len,
+		      enum dma_transfer_direction direction,
+		      unsigned long tx_flags, void *context)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	unsigned long flags;
+	union moxart_dma_reg_cfg mcfg;
+	unsigned int size, adr_width;
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	if (direction == DMA_MEM_TO_DEV) {
+		writel(virt_to_phys((void *)sg_dma_address(&sgl[0])),
+		       &mchan->reg->source_addr);
+		writel(mchan->cfg.dst_addr, &mchan->reg->dest_addr);
+		adr_width = mchan->cfg.src_addr_width;
+	} else {
+		writel(mchan->cfg.src_addr, &mchan->reg->source_addr);
+		writel(virt_to_phys((void *)sg_dma_address(&sgl[0])),
+		       &mchan->reg->dest_addr);
+		adr_width = mchan->cfg.dst_addr_width;
+	}
+
+	size = sgl->length >> adr_width;
+
+	/*
+	 * size is 4 on 64 bytes copied, i.e. once cycle copies 16 bytes
+	 * ( when data_width == APB_DMAB_DATA_WIDTH_4 )
+	 */
+	writel(size, &mchan->reg->cycles);
+
+	dev_dbg(chan2dev(chan), "%s: set %d DMA cycles (sgl->length=%d adr_width=%d)\n",
+		__func__, size, sgl->length, adr_width);
+
+	dev_dbg(chan2dev(chan), "%s: mcfg.ul=%x read from &mchan->reg->cfg.ul=%x\n",
+		__func__, mcfg.ul, (unsigned int)&mchan->reg->cfg.ul);
+
+	dma_async_tx_descriptor_init(&mchan->tx_desc, chan);
+	mchan->tx_desc.tx_submit = moxart_tx_submit;
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return &mchan->tx_desc;
+}
+
+static struct platform_driver moxart_driver;
+
+bool moxart_filter_fn(struct dma_chan *chan, void *param)
+{
+	if (chan->device->dev->driver == &moxart_driver.driver) {
+		struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+		unsigned int ch_req = *(unsigned int *)param;
+		dev_dbg(chan2dev(chan), "%s: mchan=%p ch_req=%d mchan->ch_num=%d\n",
+			__func__, mchan, ch_req, mchan->ch_num);
+		return ch_req == mchan->ch_num;
+	} else {
+		dev_dbg(chan2dev(chan), "%s: device not registered to this DMA engine\n",
+			__func__);
+		return false;
+	}
+}
+EXPORT_SYMBOL(moxart_filter_fn);
+
+static int moxart_alloc_chan_resources(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	int i;
+	bool found = false;
+
+	for (i = 0; i < APB_DMA_MAX_CHANNEL; i++) {
+		if (i == mchan->ch_num
+			&& !mchan->allocated) {
+			dev_dbg(chan2dev(chan), "%s: allocating channel #%d\n",
+				__func__, mchan->ch_num);
+			mchan->allocated = true;
+			found = true;
+			break;
+		}
+	}
+
+	if (!found)
+		return -ENODEV;
+
+	return 0;
+}
+
+static void moxart_free_chan_resources(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+
+	mchan->allocated = false;
+
+	dev_dbg(chan2dev(chan), "%s: freeing channel #%u\n",
+		__func__, mchan->ch_num);
+}
+
+static void moxart_issue_pending(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+
+	dev_dbg(chan2dev(chan), "%s: mchan=%p\n", __func__, mchan);
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.ul |= APB_DMA_ENABLE;
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+}
+
+static enum dma_status moxart_tx_status(struct dma_chan *chan,
+					dma_cookie_t cookie,
+					struct dma_tx_state *txstate)
+{
+	enum dma_status ret;
+
+	ret = dma_cookie_status(chan, cookie, txstate);
+	if (ret == DMA_SUCCESS || !txstate)
+		return ret;
+
+	return ret;
+}
+
+static void moxart_dma_init(struct dma_device *dma, struct device *dev)
+{
+	dma->device_prep_slave_sg		= moxart_prep_slave_sg;
+	dma->device_alloc_chan_resources	= moxart_alloc_chan_resources;
+	dma->device_free_chan_resources		= moxart_free_chan_resources;
+	dma->device_issue_pending		= moxart_issue_pending;
+	dma->device_tx_status			= moxart_tx_status;
+	dma->device_control			= moxart_control;
+	dma->dev				= dev;
+
+	INIT_LIST_HEAD(&dma->channels);
+}
+
+static irqreturn_t moxart_dma_interrupt(int irq, void *devid)
+{
+	struct device *dev = devid;
+	struct moxart_dma_chan *mchan = &mdc->slave_chans[0];
+	unsigned int i;
+	union moxart_dma_reg_cfg mcfg;
+
+	dev_dbg(dev, "%s\n", __func__);
+
+	for (i = 0; i < APB_DMA_MAX_CHANNEL; i++, mchan++) {
+		if (mchan->allocated) {
+			mcfg.ul = readl(&mchan->reg->cfg.ul);
+			if (mcfg.ul & APB_DMA_FIN_INT_STS) {
+				mcfg.ul &= ~APB_DMA_FIN_INT_STS;
+				dma_cookie_complete(&mchan->tx_desc);
+			}
+			if (mcfg.ul & APB_DMA_ERR_INT_STS) {
+				mcfg.ul &= ~APB_DMA_ERR_INT_STS;
+				mchan->error_flag = 1;
+			}
+			if (mchan->callback) {
+				dev_dbg(dev, "%s: call callback for mchan=%p\n",
+					__func__, mchan);
+				mchan->callback(mchan->callback_param);
+			}
+			mchan->error_flag = 0;
+			writel(mcfg.ul, &mchan->reg->cfg.ul);
+		}
+	}
+
+	return IRQ_HANDLED;
+}
+
+static struct irqaction moxart_dma_irq = {
+	.name       = "moxart-dma-engine",
+	.flags      = IRQF_DISABLED,
+	.handler    = moxart_dma_interrupt,
+};
+
+static int moxart_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct resource res_dma;
+	static void __iomem *dma_base_addr;
+	int ret, i;
+	unsigned int irq;
+	struct moxart_dma_chan *mchan;
+
+	mdc = devm_kzalloc(dev, sizeof(*mdc), GFP_KERNEL);
+	if (!mdc) {
+		dev_err(dev, "can't allocate DMA container\n");
+		return -ENOMEM;
+	}
+
+	ret = of_address_to_resource(node, 0, &res_dma);
+	if (ret) {
+		dev_err(dev, "can't get DMA base resource\n");
+		return ret;
+	}
+
+	irq = irq_of_parse_and_map(node, 0);
+
+	dma_base_addr = devm_ioremap_resource(dev, &res_dma);
+	if (IS_ERR(dma_base_addr)) {
+		dev_err(dev, "devm_ioremap_resource failed\n");
+		return PTR_ERR(dma_base_addr);
+	}
+
+	mdc->ctlr = pdev->id;
+
+	dma_cap_zero(mdc->dma_slave.cap_mask);
+	dma_cap_set(DMA_SLAVE, mdc->dma_slave.cap_mask);
+
+	moxart_dma_init(&mdc->dma_slave, dev);
+
+	mchan = &mdc->slave_chans[0];
+	for (i = 0; i < APB_DMA_MAX_CHANNEL; i++, mchan++) {
+		mchan->ch_num = i;
+		mchan->reg = (struct moxart_dma_reg *)(dma_base_addr + 0x80
+			     + i * sizeof(struct moxart_dma_reg));
+		mchan->callback = NULL;
+		mchan->allocated = 0;
+		mchan->callback_param = NULL;
+
+		dma_cookie_init(&mchan->chan);
+		mchan->chan.device = &mdc->dma_slave;
+		list_add_tail(&mchan->chan.device_node,
+			      &mdc->dma_slave.channels);
+
+		dev_dbg(dev, "%s: mchans[%d]: mchan->ch_num=%d mchan->reg=%p\n",
+			__func__, i, mchan->ch_num, mchan->reg);
+	}
+
+	ret = dma_async_device_register(&mdc->dma_slave);
+	platform_set_drvdata(pdev, mdc);
+
+	moxart_dma_irq.dev_id = dev;
+	setup_irq(irq, &moxart_dma_irq);
+
+	dev_dbg(dev, "%s: IRQ=%d\n", __func__, irq);
+
+	return ret;
+}
+
+static int moxart_remove(struct platform_device *pdev)
+{
+	struct moxart_dma_container *m = dev_get_drvdata(&pdev->dev);
+	dma_async_device_unregister(&m->dma_slave);
+	return 0;
+}
+
+static const struct of_device_id moxart_dma_match[] = {
+	{ .compatible = "moxa,moxart-dma" },
+	{ }
+};
+
+static struct platform_driver moxart_driver = {
+	.probe	= moxart_probe,
+	.remove	= moxart_remove,
+	.driver = {
+		.name		= "moxart-dma-engine",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_dma_match,
+	},
+};
+
+static int moxart_init(void)
+{
+	return platform_driver_register(&moxart_driver);
+}
+subsys_initcall(moxart_init);
+
+static void __exit moxart_exit(void)
+{
+	platform_driver_unregister(&moxart_driver);
+}
+module_exit(moxart_exit);
+
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
+MODULE_DESCRIPTION("MOXART DMA engine driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/dma/moxart-dma.h b/drivers/dma/moxart-dma.h
new file mode 100644
index 0000000..358c006
--- /dev/null
+++ b/drivers/dma/moxart-dma.h
@@ -0,0 +1,188 @@
+/*
+ * MOXA ART SoCs DMA Engine support.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __DMA_MOXART_H
+#define __DMA_MOXART_H
+
+#define APB_DMA_MAX_CHANNEL			4
+
+union moxart_dma_reg_cfg {
+
+#define APB_DMA_ENABLE				(1<<0)
+#define APB_DMA_FIN_INT_STS			(1<<1)
+#define APB_DMA_FIN_INT_EN			(1<<2)
+#define APB_DMA_BURST_MODE			(1<<3)
+#define APB_DMA_ERR_INT_STS			(1<<4)
+#define APB_DMA_ERR_INT_EN			(1<<5)
+#define APB_DMA_SOURCE_AHB			(1<<6)
+#define APB_DMA_SOURCE_APB			0
+#define APB_DMA_DEST_AHB			(1<<7)
+#define APB_DMA_DEST_APB			0
+#define APB_DMA_SOURCE_INC_0			0
+#define APB_DMA_SOURCE_INC_1_4			(1<<8)
+#define APB_DMA_SOURCE_INC_2_8			(2<<8)
+#define APB_DMA_SOURCE_INC_4_16			(3<<8)
+#define APB_DMA_SOURCE_DEC_1_4			(5<<8)
+#define APB_DMA_SOURCE_DEC_2_8			(6<<8)
+#define APB_DMA_SOURCE_DEC_4_16			(7<<8)
+#define APB_DMA_SOURCE_INC_MASK			(7<<8)
+#define APB_DMA_DEST_INC_0			0
+#define APB_DMA_DEST_INC_1_4			(1<<12)
+#define APB_DMA_DEST_INC_2_8			(2<<12)
+#define APB_DMA_DEST_INC_4_16			(3<<12)
+#define APB_DMA_DEST_DEC_1_4			(5<<12)
+#define APB_DMA_DEST_DEC_2_8			(6<<12)
+#define APB_DMA_DEST_DEC_4_16			(7<<12)
+#define APB_DMA_DEST_INC_MASK			(7<<12)
+#define APB_DMA_DEST_REQ_NO_MASK		(15<<16)
+#define APB_DMA_DATA_WIDTH_MASK			(3<<20)
+#define APB_DMA_DATA_WIDTH_4			0
+#define APB_DMA_DATA_WIDTH_2			(1<<20)
+#define APB_DMA_DATA_WIDTH_1			(2<<20)
+#define APB_DMA_SOURCE_REQ_NO_MASK		(15<<24)
+	unsigned int ul;
+
+	struct {
+
+#define APB_DMAB_ENABLE				1
+		/* enable DMA */
+		unsigned int enable:1;
+
+#define APB_DMAB_FIN_INT_STS			1
+		/* finished interrupt status */
+		unsigned int fin_int_sts:1;
+
+#define APB_DMAB_FIN_INT_EN			1
+		/* finished interrupt enable */
+		unsigned int fin_int_en:1;
+
+#define APB_DMAB_BURST_MODE			1
+		/* burst mode */
+		unsigned int burst:1;
+
+#define APB_DMAB_ERR_INT_STS			1
+		/* error interrupt status */
+		unsigned int err_int_sts:1;
+
+#define APB_DMAB_ERR_INT_EN			1
+		/* error interrupt enable */
+		unsigned int err_int_en:1;
+
+#define APB_DMAB_SOURCE_AHB			1
+#define APB_DMAB_SOURCE_APB			0
+		/* 0:APB (device), 1:AHB (RAM) */
+		unsigned int source_sel:1;
+
+#define APB_DMAB_DEST_AHB			1
+#define APB_DMAB_DEST_APB			0
+		/* 0:APB, 1:AHB */
+		unsigned int dest_sel:1;
+
+#define APB_DMAB_SOURCE_INC_0			0
+#define APB_DMAB_SOURCE_INC_1_4			1
+#define APB_DMAB_SOURCE_INC_2_8			2
+#define APB_DMAB_SOURCE_INC_4_16		3
+#define APB_DMAB_SOURCE_DEC_1_4			5
+#define APB_DMAB_SOURCE_DEC_2_8			6
+#define APB_DMAB_SOURCE_DEC_4_16		7
+#define APB_DMAB_SOURCE_INC_MASK		7
+		/*
+		 * 000: no increment
+		 * 001: +1 (busrt=0), +4  (burst=1)
+		 * 010: +2 (burst=0), +8  (burst=1)
+		 * 011: +4 (burst=0), +16 (burst=1)
+		 * 101: -1 (burst=0), -4  (burst=1)
+		 * 110: -2 (burst=0), -8  (burst=1)
+		 * 111: -4 (burst=0), -16 (burst=1)
+		 */
+		unsigned int source_inc:3;
+
+		unsigned int reserved1:1;
+
+#define APB_DMAB_DEST_INC_0			0
+#define APB_DMAB_DEST_INC_1_4			1
+#define APB_DMAB_DEST_INC_2_8			2
+#define APB_DMAB_DEST_INC_4_16			3
+#define APB_DMAB_DEST_DEC_1_4			5
+#define APB_DMAB_DEST_DEC_2_8			6
+#define APB_DMAB_DEST_DEC_4_16			7
+#define APB_DMAB_DEST_INC_MASK			7
+		/*
+		 * 000: no increment
+		 * 001: +1 (busrt=0), +4  (burst=1)
+		 * 010: +2 (burst=0), +8  (burst=1)
+		 * 011: +4 (burst=0), +16 (burst=1)
+		 * 101: -1 (burst=0), -4  (burst=1)
+		 * 110: -2 (burst=0), -8  (burst=1)
+		 * 111: -4 (burst=0), -16 (burst=1)
+		*/
+		unsigned int dest_inc:3;
+
+		unsigned int reserved2:1;
+
+#define APB_DMAB_DEST_REQ_NO_MASK		15
+		/*
+		 * request signal select of destination
+		 * address for DMA hardware handshake
+		 *
+		 * the request line number is a property of
+		 * the DMA controller itself, e.g. MMC must
+		 * always request channels where
+		 * dma_slave_config->slave_id == 5
+		 *
+		 * 0:	 no request / grant signal
+		 * 1-15: request / grant signal
+		 */
+		unsigned int dest_req_no:4;
+
+#define APB_DMAB_DATA_WIDTH_MASK		3
+#define APB_DMAB_DATA_WIDTH_4			0
+#define APB_DMAB_DATA_WIDTH_2			1
+#define APB_DMAB_DATA_WIDTH_1			2
+		/*
+		 * data width of transfer
+		 * 00: word
+		 * 01: half
+		 * 10: byte
+		 */
+		unsigned int data_width:2;
+
+		unsigned int reserved3:2;
+
+#define APB_DMAB_SOURCE_REQ_NO_MASK		15
+		/*
+		 * request signal select of source
+		 * address for DMA hardware handshake
+		 *
+		 * the request line number is a property of
+		 * the DMA controller itself, e.g. MMC must
+		 * always request channels where
+		 * dma_slave_config->slave_id == 5
+		 *
+		 * 0:	 no request / grant signal
+		 * 1-15: request / grant signal
+		 */
+		unsigned int source_req_no:4;
+
+		unsigned int reserved4:4;
+	} bits;
+};
+
+struct moxart_dma_reg {
+	unsigned int source_addr;
+	unsigned int dest_addr;
+#define APB_DMA_CYCLES_MASK			0x00ffffff
+	unsigned int cycles;	/* depend on burst mode */
+	union moxart_dma_reg_cfg cfg;
+};
+
+#endif
-- 
1.8.2.1



From josh.wu at atmel.com  Wed Jul 17 06:09:34 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Wed, 17 Jul 2013 18:09:34 +0800
Subject: [PATCH 2/5] iio: at91: Use different prescal, startup mask in
 MR for different IP
In-Reply-To: <51E64EBB.30700@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
 <51E64EBB.30700@atmel.com>
Message-ID: <51E66D5E.1060608@atmel.com>

Hi, Nicolas

Thanks for your review.

On 7/17/2013 3:58 PM, Nicolas Ferre wrote:
> On 14/07/2013 10:04, Josh Wu :
>> For at91 boards, there are different IPs for adc. Different IPs has 
>> different
>> STARTUP & PRESCAL mask in ADC_MR.
>>
>> This patch can change the masks according to the different IP version.
>>
>> Signed-off-by: Josh Wu <josh.wu at atmel.com>
>> ---
>>   arch/arm/mach-at91/include/mach/at91_adc.h |    9 ++++--
>>   drivers/iio/adc/at91_adc.c                 |   48 
>> ++++++++++++++++++++++++++--
>>   2 files changed, 53 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-at91/include/mach/at91_adc.h 
>> b/arch/arm/mach-at91/include/mach/at91_adc.h
>> index 8e7ed5c..ab273ee 100644
>> --- a/arch/arm/mach-at91/include/mach/at91_adc.h
>> +++ b/arch/arm/mach-at91/include/mach/at91_adc.h
>> @@ -28,9 +28,12 @@
>>   #define            AT91_ADC_TRGSEL_EXTERNAL    (6 << 1)
>>   #define        AT91_ADC_LOWRES        (1 << 4)    /* Low Resolution */
>>   #define        AT91_ADC_SLEEP        (1 << 5)    /* Sleep Mode */
>> -#define        AT91_ADC_PRESCAL    (0x3f << 8)    /* Prescalar Rate 
>> Selection */
>> +#define        AT91_ADC_PRESCAL    (0xff << 8)    /* Prescalar Rate 
>> Selection */
>> +#define        AT91_ADC_PRESCAL_9260    (0x3f << 8)
>>   #define            AT91_ADC_PRESCAL_(x)    ((x) << 8)
>> -#define        AT91_ADC_STARTUP    (0x1f << 16)    /* Startup Up 
>> Time */
>> +#define        AT91_ADC_STARTUP    (0xf << 16)    /* Startup Up Time */
>
> Which product has this kind of startup mask: 0xf? Compared with 9260 
> and 9g45 values, it seems strange to me: maybe a little comment should 
> be added.

 From the datasheet, In at91sam9x5 and sama5d3x, the startup time mask 
is become 0xf. In meanwhile, the startup time calculation method is also 
changed.

Before at91sam9x5, Startup Time = (STARTUP+1) * 8/ADCCLK

Since at91sam9x5,  Startup Time = <find the following lookup table>
         0 SUT0 0 periods of ADCClock
         1 SUT8 8 periods of ADCClock
         2 SUT16 16 periods of ADCClock
         3 SUT24 24 periods of ADCClock
         4 SUT64 64 periods of ADCClock
         5 SUT80 80 periods of ADCClock
         ...    ...
         14 SUT896 896 periods of ADCClock
         15 SUT960 960 periods of ADCClock

so only 4bits, it still can define < 960's ADC clock.

In my 3/5 patch, it implement this calculation method.

>
>
>> +#define        AT91_ADC_STARTUP_9260 (0x1f << 16)
>> +#define        AT91_ADC_STARTUP_9G45    (0x7f << 16)
>>   #define            AT91_ADC_STARTUP_(x)    ((x) << 16)
>>   #define        AT91_ADC_SHTIM        (0xf  << 24)    /* Sample & 
>> Hold Time */
>>   #define            AT91_ADC_SHTIM_(x)    ((x) << 24)
>> @@ -58,4 +61,6 @@
>>   #define AT91_ADC_CHR(n)        (0x30 + ((n) * 4))    /* Channel 
>> Data Register N */
>>   #define        AT91_ADC_DATA        (0x3ff)
>>
>> +#define AT91_ADC_VERSION    0xFC
>> +
>>   #endif
>> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
>> index 18bd54f..14e99ba 100644
>> --- a/drivers/iio/adc/at91_adc.c
>> +++ b/drivers/iio/adc/at91_adc.c
>> @@ -39,6 +39,12 @@
>>   #define at91_adc_writel(st, reg, val) \
>>       (writel_relaxed(val, st->reg_base + reg))
>>
>> +struct at91_adc_caps {
>> +    bool    has_tsmr;    /* only at91sam9x5, sama5d3 have TSMR reg */
>> +    u32    mr_prescal_mask;
>> +    u32    mr_startup_mask;
>> +};
>> +
>
> If we move to DT and compatible string for these values, maybe a 
> separate structure won't be needed....

yes, if we move the mask as DT property.
But another way is define above structure in driver. Driver will load 
the correct mask by checking the compatible string. In this way, we 
don't exposure all IP details out to DT.
I prefer the second way in the moment.

By answer this question, I just had a second thought of the ADC 
compatible implementation:
For touch ADC, there should have 3 catalogs:
   9260/9g20: not support touch.
   9g45: support touch, but no average, no TSMR. Need a software filter
   9x5, sama5: support touch, with average, TSMR. Sample data function 
changed a lot from 9g45.

>
>
>>   struct at91_adc_state {
>>       struct clk        *adc_clk;
>>       u16            *buffer;
>> @@ -62,6 +68,7 @@ struct at91_adc_state {
>>       u32            res;        /* resolution used for convertions */
>>       bool            low_res;    /* the resolution corresponds to 
>> the lowest one */
>>       wait_queue_head_t    wq_data_avail;
>> +    struct at91_adc_caps    caps;
>>   };
>>
>>   static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
>> @@ -580,6 +587,41 @@ static const struct iio_info at91_adc_info = {
>>       .read_raw = &at91_adc_read_raw,
>>   };
>>
>> +/*
>> + * Since atmel adc support different ip for touchscreen mode. 
>> Through the
>> + * IP check, we will know the touchscreen capbilities.
>> + */
>> +static void atmel_adc_get_cap(struct at91_adc_state *st)
>> +{
>> +    unsigned int version;
>> +    struct iio_dev *idev = iio_priv_to_dev(st);
>> +
>> +    version = at91_adc_readl(st, AT91_ADC_VERSION);
>> +    dev_dbg(&idev->dev, "version: 0x%x\n", version);
>> +
>> +    st->caps.mr_prescal_mask = AT91_ADC_PRESCAL_9260;
>> +    st->caps.mr_startup_mask = AT91_ADC_STARTUP_9260;
>> +
>> +    /* keep only major version number */
>> +    switch (version & 0xf00) {
>> +    case 0x500:    /* SAMA5D3 */
>> +    case 0x400:    /* AT91SAM9X5/9N12 */
>> +        st->caps.has_tsmr = 1;
>> +        st->caps.mr_startup_mask = AT91_ADC_STARTUP;
>
> Here is where AT91_ADC_STARTUP may need another name: what about 
> AT91_ADC_STARTUP_9x5 to match the "compatibility" of this value?

ok.

>
>
>> +    case 0x200:    /* AT91SAM9M10/9G45 */
>> +        st->caps.mr_prescal_mask = AT91_ADC_PRESCAL;
>> +
>> +        if ((version & 0xf00) == 0x200)
>
> Sorry but I do not understand this test in a switch/case entry where 
> it should always be true...

Since the switch case is fall through, that means the higher IP 
(at91sam9x5, sama5) will also running this check, but this line only for 
9G45 chip.

a little bit hard to read  :)

>
>
>> +            st->caps.mr_startup_mask = AT91_ADC_STARTUP_9G45;
>> +    case 0x100:    /* AT91SAM9260/9G20 */
>> +        break;
>> +    default:
>> +        dev_warn(&idev->dev,
>> +                "Unmanaged adc version, use minimal capabilities\n");
>> +        break;
>> +    };
>> +}
>> +
>>   static int at91_adc_probe(struct platform_device *pdev)
>>   {
>>       unsigned int prsc, mstrclk, ticks, adc_clk, adc_clk_khz, shtim;
>> @@ -645,6 +687,8 @@ static int at91_adc_probe(struct platform_device 
>> *pdev)
>>           goto error_free_device;
>>       }
>>
>> +    atmel_adc_get_cap(st);
>> +
>>       st->clk = devm_clk_get(&pdev->dev, "adc_clk");
>>       if (IS_ERR(st->clk)) {
>>           dev_err(&pdev->dev, "Failed to get the clock.\n");
>> @@ -704,8 +748,8 @@ static int at91_adc_probe(struct platform_device 
>> *pdev)
>>       shtim = round_up((st->sample_hold_time * adc_clk_khz /
>>                 1000) - 1, 1);
>>
>> -    reg = AT91_ADC_PRESCAL_(prsc) & AT91_ADC_PRESCAL;
>> -    reg |= AT91_ADC_STARTUP_(ticks) & AT91_ADC_STARTUP;
>> +    reg = AT91_ADC_PRESCAL_(prsc) & st->caps.mr_prescal_mask;
>> +    reg |= AT91_ADC_STARTUP_(ticks) & st->caps.mr_startup_mask;
>>       if (st->low_res)
>>           reg |= AT91_ADC_LOWRES;
>>       if (st->sleep_mode)
>>
>
>

Thanks again.
Best Regards,
Josh Wu


From broonie at kernel.org  Wed Jul 17 06:09:36 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Jul 2013 11:09:36 +0100
Subject: [PATCH v4] rtc: Add MOXA ART RTC driver
In-Reply-To: <1374052444-5420-1-git-send-email-jonas.jensen@gmail.com>
References: <1373978485-17496-1-git-send-email-jonas.jensen@gmail.com>
 <1374052444-5420-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <20130717100936.GL22506@sirena.org.uk>

On Wed, Jul 17, 2013 at 11:14:04AM +0200, Jonas Jensen wrote:
> Add RTC driver for MOXA ART SoCs.
> 
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>

Reviewed-by: Mark Brown <broonie at linaro.org>
-------------- 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/20130717/cabf25e8/attachment.sig>

From josephl at nvidia.com  Wed Jul 17 06:15:30 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 17 Jul 2013 18:15:30 +0800
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <51E5A438.10004@wwwdotorg.org>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
Message-ID: <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>

On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
> On 07/16/2013 05:17 AM, Joseph Lo wrote:
> > On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
> >> On 06/25/2013 03:23 AM, Joseph Lo wrote:
> >>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
> >>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
> >>> this state.
> > or something can increase
> > the loading or make regressions. But I think you are testing with USB
> > device attached, right? That might cause some extra loading. You can
> > give it a try after just removing USB device. And I double confirm that
> > on Seaboard. Except that, the test result looks OK for me.
> 
> Yes, having a USB device plugged in does affect the issue. In summary:
> 
> next-20130716, with or without USB devices plugged in: Works fine.
> 
> next-20130716 with your patches, without USB device plugged in:
> Occasional short problems (detailed below).
> 
> next-20130716 with your patches, with USB device plugged in: Continual
> long problems (detailed below).
> 
> The testing I did was to log in over the serial console, hit <enter>
> around five times, and watch the shell prompt echo back, then type
> "ls<enter" and watch the (directory listing appear (I have about 20
> files in my directory, with long-ish names), then repeat. With plain
> next-20130716, this is nice and fast and there are no pauses. With your
> patches applied, there are occasional or continual pauses, which last
> for either a short time (tenths of a second), or even a second or two,
> both depending on whether a USB device is plugged in or not.
> 
> I believe this is the same issue I saw when I applied your patches to
> the Tegra tree on top of v3.11-rc1.
> 
OK. I did more stress tests last night and today. I found it cause by
the patch "ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag" and
only impact the Tegra20 platform. The hot plug regression seems due to
this patch. After dropping this patch on top of v3.11-rc1, the Tegra20
can back to normal.

And the hop plug and suspend stress test can pass on Tegra30/114 too.

Can the other two patch series for Tegra114 to support CPU idle power
down mode and system suspend still moving forward, not be blocked by
this patch?

Looks the CPUIDLE_FLAG_TIMER_STOP flag still cause some other issue for
hot plug on Tegra20, I will continue to check this. You can just drop
this patch.

Thanks,
Joseph




From daniel.lezcano at linaro.org  Wed Jul 17 06:21:18 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 17 Jul 2013 12:21:18 +0200
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <51E6701E.2070909@linaro.org>

On 07/17/2013 12:15 PM, Joseph Lo wrote:
> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
>>>>> this state.
>>> or something can increase
>>> the loading or make regressions. But I think you are testing with USB
>>> device attached, right? That might cause some extra loading. You can
>>> give it a try after just removing USB device. And I double confirm that
>>> on Seaboard. Except that, the test result looks OK for me.
>>
>> Yes, having a USB device plugged in does affect the issue. In summary:
>>
>> next-20130716, with or without USB devices plugged in: Works fine.
>>
>> next-20130716 with your patches, without USB device plugged in:
>> Occasional short problems (detailed below).
>>
>> next-20130716 with your patches, with USB device plugged in: Continual
>> long problems (detailed below).
>>
>> The testing I did was to log in over the serial console, hit <enter>
>> around five times, and watch the shell prompt echo back, then type
>> "ls<enter" and watch the (directory listing appear (I have about 20
>> files in my directory, with long-ish names), then repeat. With plain
>> next-20130716, this is nice and fast and there are no pauses. With your
>> patches applied, there are occasional or continual pauses, which last
>> for either a short time (tenths of a second), or even a second or two,
>> both depending on whether a USB device is plugged in or not.
>>
>> I believe this is the same issue I saw when I applied your patches to
>> the Tegra tree on top of v3.11-rc1.
>>
> OK. I did more stress tests last night and today. I found it cause by
> the patch "ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag" and
> only impact the Tegra20 platform. The hot plug regression seems due to
> this patch. After dropping this patch on top of v3.11-rc1, the Tegra20
> can back to normal.
> 
> And the hop plug and suspend stress test can pass on Tegra30/114 too.
> 
> Can the other two patch series for Tegra114 to support CPU idle power
> down mode and system suspend still moving forward, not be blocked by
> this patch?
> 
> Looks the CPUIDLE_FLAG_TIMER_STOP flag still cause some other issue for
> hot plug on Tegra20, I will continue to check this. You can just drop
> this patch.

Please in the future Cc me when problems occur with some patches I
submitted. That would be easier for me to track the issues and fix them
when they happen.

Thanks
  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From josephl at nvidia.com  Wed Jul 17 06:29:34 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 17 Jul 2013 18:29:34 +0800
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <51E6701E.2070909@linaro.org>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
 <51E6701E.2070909@linaro.org>
Message-ID: <1374056974.1000.1.camel@jlo-ubuntu-64.nvidia.com>

On Wed, 2013-07-17 at 18:21 +0800, Daniel Lezcano wrote:
> On 07/17/2013 12:15 PM, Joseph Lo wrote:
> > On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
> >> On 07/16/2013 05:17 AM, Joseph Lo wrote:
> >>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
> >>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
> >>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
> >>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
> >>>>> this state.
> >>> or something can increase
> >>> the loading or make regressions. But I think you are testing with USB
> >>> device attached, right? That might cause some extra loading. You can
> >>> give it a try after just removing USB device. And I double confirm that
> >>> on Seaboard. Except that, the test result looks OK for me.
> >>
> >> Yes, having a USB device plugged in does affect the issue. In summary:
> >>
> >> next-20130716, with or without USB devices plugged in: Works fine.
> >>
> >> next-20130716 with your patches, without USB device plugged in:
> >> Occasional short problems (detailed below).
> >>
> >> next-20130716 with your patches, with USB device plugged in: Continual
> >> long problems (detailed below).
> >>
> >> The testing I did was to log in over the serial console, hit <enter>
> >> around five times, and watch the shell prompt echo back, then type
> >> "ls<enter" and watch the (directory listing appear (I have about 20
> >> files in my directory, with long-ish names), then repeat. With plain
> >> next-20130716, this is nice and fast and there are no pauses. With your
> >> patches applied, there are occasional or continual pauses, which last
> >> for either a short time (tenths of a second), or even a second or two,
> >> both depending on whether a USB device is plugged in or not.
> >>
> >> I believe this is the same issue I saw when I applied your patches to
> >> the Tegra tree on top of v3.11-rc1.
> >>
> > OK. I did more stress tests last night and today. I found it cause by
> > the patch "ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag" and
> > only impact the Tegra20 platform. The hot plug regression seems due to
> > this patch. After dropping this patch on top of v3.11-rc1, the Tegra20
> > can back to normal.
> > 
> > And the hop plug and suspend stress test can pass on Tegra30/114 too.
> > 
> > Can the other two patch series for Tegra114 to support CPU idle power
> > down mode and system suspend still moving forward, not be blocked by
> > this patch?
> > 
> > Looks the CPUIDLE_FLAG_TIMER_STOP flag still cause some other issue for
> > hot plug on Tegra20, I will continue to check this. You can just drop
> > this patch.
> 
> Please in the future Cc me when problems occur with some patches I
> submitted. That would be easier for me to track the issues and fix them
> when they happen.
> 
Ah, sorry for that. I should always Cc you. Will do next time. Thanks
for take care.

Joseph




From lorenzo.pieralisi at arm.com  Wed Jul 17 06:44:17 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 17 Jul 2013 11:44:17 +0100
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <1374052705.3146.86.camel@hornet>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374052705.3146.86.camel@hornet>
Message-ID: <20130717104416.GA1896@e102568-lin.cambridge.arm.com>

On Wed, Jul 17, 2013 at 10:18:25AM +0100, Pawel Moll wrote:
> On Tue, 2013-07-16 at 17:05 +0100, Lorenzo Pieralisi wrote:
> > /drivers/mfd is probably not the right place for this code as it stands (but
> > probably will be when the entire driver, with DVFS and config interface, is
> > complete).
> 
> Not that it really matters now, but my vexpress-sysreg rework will -
> most likely - leave only skeleton in the MFD (registering mfd_cells) and
> other stuff is going to be spread all around. Then I'm planning to move
> the remaining of the vexpress-specific initialization to
> drivers/platform/arm/vexpress.c, so maybe sticking vexpress-spc.c to
> this (non-existing yet) directory would be the right thing to do?

Done. I do not think there is a point in splitting the patch to create
the dir and make infrastructure, so I squashed everything in the
original patch. I have not added any maintainer for that dir/file, I
guess it can wait till you finish the rework so that you can add
yourself there.

If that's all I need to change I do not even think that reposting is
necessary.

It does matter though, since it implies changes on who is in charge of
ack/nack'ing this code, if it is no more an mfd matter.

I will wait to check all interested/concerned parties opinions, that are
always welcome.

> Other than that:
> 
> Acked-by: Pawel Moll <pawel.moll at arm.com>

Thank you !!!
Lorenzo



From laurent.pinchart at ideasonboard.com  Wed Jul 17 07:00:21 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Wed, 17 Jul 2013 13:00:21 +0200
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <51E4C073.4020407@wwwdotorg.org>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <2883016.87pKJk9n0R@avalon> <51E4C073.4020407@wwwdotorg.org>
Message-ID: <2989497.8E7gzkcamn@avalon>

Hi Stephen,

On Monday 15 July 2013 21:39:31 Stephen Warren wrote:
> On 07/15/2013 07:10 PM, Laurent Pinchart wrote:
> > On Friday 12 July 2013 08:42:41 Stephen Warren wrote:
> ...
> 
> >> I think the values for any common system-wide flags should be defined
> >> once in some system-wide place, and the values for any HW-specific
> >> values should be defined only in the documentation for that specific HW.
> >> You could try and avoid conflicts by either:
> >> 
> >> a) Allocating system-wide flags from bit 0 up, and HW-specific flags
> >> from bit 31 down.
> >> 
> >> or:
> >> 
> >> b) Using 1 cell for standard flags, and a separate cell for any
> >> HW-specific flags. Drivers can quite easily adapt to adding extra cells
> >> to #pwm-cells, thus making adding a HW-specific cell later
> >> backwards-compatible.
> > 
> > I wasn't referring to HW-specific flags, but rather to system-wide flags
> > that might not be supported by all drivers. If we later add new
> > system-wide flags I think the individual DT bindings should explicitly
> > document which flags they support.
> 
> Shouldn't all system-wide flags be supported by all HW, perhaps being
> implemented by the core subsystem rather than individual drivers to
> ensure that? Consider the case of the GPIO active-low flag which is
> actually implemented in SW, hence can work with any GPIO controller.
> 
> Perhaps that's not possible in all cases, in which case, yes, it does
> make sense to define which of the common flags a particular HW module
> supports.

It largely depends on what we consider as system flags. We should probably be 
talking about common flags instead of system flags. I usually try to 
standardize DT properties that are common to multiple devices. Some of those 
properties can apply to all devices of the same class (possibly 
implemented/emulated in software when the hardware doesn't support them), but 
others are just commonly seen properties that don't make sense for all the 
devices.

One example I'm familiar with can be found in V4L2 DT bindings. We've 
standardized properties to specify what kind of video synchronization signals 
devices support/use. Not all synchronization signals are supported by a given 
video transmitter, so DT bindings for such chips list (or at least should 
list) the common properties supported by a given device. The definitions of 
the properties should of course not be duplicated to all individual DT 
bindings.

> But then there's a problem where people assume that the common flags are
> always available, and somewhere they aren't... Care is needed in the
> choice of which common flags to define and/or how they're used.

Exactly. That's why I think listing the supported common flags in individual 
bindings makes sense when some of the flags are not supported by all devices. 
As the only PWM flags currently used are common to all PWM devices I can leave 
this out now. I have no strong preference, I'll follow your opinion on this.

-- 
Regards,

Laurent Pinchart



From jonathan.austin at arm.com  Wed Jul 17 07:10:16 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Wed, 17 Jul 2013 12:10:16 +0100
Subject: arm: Only load TLS values when needed
In-Reply-To: <51E59E8F.1060501@dawncrow.de>
References: <51E42E11.1010903@dawncrow.de> <51E5836B.1010904@arm.com>
 <51E59E8F.1060501@dawncrow.de>
Message-ID: <51E67B98.9040101@arm.com>

Hi Andr?,

On 16/07/13 20:27, Andr? Hentschel wrote:
> Hi Jonathan, First, thank you for your review.
>
> Am 16.07.2013 19:31, schrieb Jonathan Austin:
>> Hi Andr?,
>>
>> On 15/07/13 18:14, Andr? Hentschel wrote:
>>> From: Andr? Hentschel <nerv at dawncrow.de>
>>>
>>> This patch intents to reduce loading instructions when the
>>> resulting value is not used. It's a follow up on
>>> a4780adeefd042482f624f5e0d577bf9cdcbb760
>>>
>>
>> Have you done any benchmarking to see that this has any real
>> impact? Or tested on a !Vv6k system? It looks possible that the
>> only case where this will perform better is where we're using
>> switch_tls_none or switch_tls_software (both rare cases, I think)
>> and there's some change it will make things worse in other cases?
>
> I have to admit that i only tested it on v6k and did no benchmark.
>
Do you have access to anything v6-NOT-k-ish? If not I can try and test 
this on something appropriate. How does your test-case access tpidrurw? 
If it uses inline asm then it won't work on v6-not-k, as those 
instructions aren't defined...

>> One of the reasons for Russell's suggestion of placing the ldrd
>> (which became the two ldr instructions you've removed from
>> __switch_to, in order to maintain building for older cores) where
>> it is was in order to reduce the chance of pipeline stalls.
>>
>> As I've pointed out below, there is some risk that changing that
>> has implications for the v6 only case below (and the v6k case is
>> now more prone to stalls with !CONFIG_CPU_USE_DOMAINS, but newer
>> cores should have more advanced scheduling to avoid such issues
>> anyway...)
>
> I'm not sure how this could make things worse on v6k, could you
> elaborate please? Besides of the ldr and str being too close to each
> other

Yea, that's the only issue, and in the !CONFIG_CPU_USE_DOMAINS case 
things are slightly worse than they were before

> i thought this patch is a good idea, because it removes two ldr
> which are always executed. (Continuing below...)

Indeed, as long as it doesn't cause pipeline stalls then that's a gain 
for some cases :)

[...]
>> Now we've only got one instruction between the store and the load
>> and risk stalling the pipeline...
>>
>> Dave M cautiously says "The ancient advice was that one instruction
>> was enough" but this is very core dependent... I wonder if anyone
>> has a good idea about whether this is an issue here...?
>
> We could use a ldrd at the top, that'd be nearly what we have right
> now, don't we?

Yea, that'd be good - as far as I can see from an 1136 TRM, the ldrd 
*may* be two cycles (depending on alignment of the words) but the ldr 
and ldrne will always be two cycles. Ahhh, the joys of modifying the 
fast path ;)

Jonny
>
>
>




From oleksandr.kozaruk at ti.com  Wed Jul 17 07:12:43 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Wed, 17 Jul 2013 14:12:43 +0300
Subject: [PATCH v5 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <1374059564-6872-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1374059564-6872-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1374059564-6872-2-git-send-email-oleksandr.kozaruk@ti.com>

GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.

Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..322aa8e 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
 		compatible = "ti,twl6030-pwmled";
 		#pwm-cells = <2>;
 	};
+
+	adc: twl6030_gpadc {
+		compatible = "ti,twl6030_gpadc";
+		interrupts = <3>;
+		#io-channel-cells = <1>;
+	};
 };
-- 
1.8.1.2



From oleksandr.kozaruk at ti.com  Wed Jul 17 07:12:44 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Wed, 17 Jul 2013 14:12:44 +0300
Subject: [PATCH v5 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <1374059564-6872-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1374059564-6872-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1374059564-6872-3-git-send-email-oleksandr.kozaruk@ti.com>

The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
known also as Phoenix and PhoenixLite.

The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
respectively. Some channels have current source and are used for
measuring voltage drop on resistive load for detecting battery ID
resistance, or measuring voltage drop on NTC resistors for external
temperature measurements. Some channels measure voltage, (i.e. battery
voltage), and have voltage dividers, thus, capable to scale voltage.
Some channels are dedicated for measuring die temperature.

Some channels are calibrated in 2 points, having offsets from ideal
values kept in trim registers. This is used to correct measurements.

The differences between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i.e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
Girish S Ghongdemath.

Signed-off-by: Balaji T K <balajitk at ti.com>
Signed-off-by: Graeme Gregory <gg at slimlogic.co.uk>
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 drivers/iio/adc/Kconfig         |   14 +
 drivers/iio/adc/Makefile        |    1 +
 drivers/iio/adc/twl6030-gpadc.c | 1026 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 1041 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index ab0767e6..3172461 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -150,6 +150,20 @@ config TI_AM335X_ADC
 	  Say yes here to build support for Texas Instruments ADC
 	  driver which is also a MFD client.
 
+config TWL6030_GPADC
+	tristate "TWL6030 GPADC (General Purpose A/D Converter) Support"
+	depends on TWL4030_CORE
+	default n
+	help
+	  Say yes here if you want support for the TWL6030/TWL6032 General
+	  Purpose A/D Converter. This will add support for battery type
+	  detection, battery voltage and temperature measurement, die
+	  temperature measurement, system supply voltage, audio accessory,
+	  USB ID detection.
+
+	  This driver can also be built as a module. If so, the module will be
+	  called twl6030-gpadc.
+
 config VIPERBOARD_ADC
 	tristate "Viperboard ADC support"
 	depends on MFD_VIPERBOARD && USB
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 0a825be..996ba09 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -16,4 +16,5 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
 obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
+obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
 obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
new file mode 100644
index 0000000..97fad5b
--- /dev/null
+++ b/drivers/iio/adc/twl6030-gpadc.c
@@ -0,0 +1,1026 @@
+/*
+ * TWL6030 GPADC module driver
+ *
+ * Copyright (C) 2009-2013 Texas Instruments Inc.
+ * Nishant Kamat <nskamat at ti.com>
+ * Balaji T K <balajitk at ti.com>
+ * Graeme Gregory <gg at slimlogic.co.uk>
+ * Girish S Ghongdemath <girishsg at ti.com>
+ * Ambresh K <ambresh at ti.com>
+ * Oleksandr Kozaruk <oleksandr.kozaruk at ti.com
+ *
+ * Based on twl4030-madc.c
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen <mikko.k.ylinen at nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of_platform.h>
+#include <linux/i2c/twl.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define DRIVER_NAME		"twl6030_gpadc"
+
+#define TWL6030_GPADC_MAX_CHANNELS 17
+#define TWL6032_GPADC_MAX_CHANNELS 19
+
+#define TWL6030_GPADC_CTRL_P1			0x05
+
+#define TWL6032_GPADC_GPSELECT_ISB		0x07
+#define TWL6032_GPADC_CTRL_P1			0x08
+
+#define TWL6032_GPADC_GPCH0_LSB			0x0d
+#define TWL6032_GPADC_GPCH0_MSB			0x0e
+
+#define TWL6030_GPADC_CTRL_P1_SP1		BIT(3)
+
+#define TWL6030_GPADC_GPCH0_LSB			(0x29)
+
+#define TWL6030_GPADC_RT_SW1_EOC_MASK		BIT(5)
+
+#define TWL6030_GPADC_TRIM1			0xCD
+
+#define TWL6030_REG_TOGGLE1			0x90
+#define TWL6030_GPADCS				BIT(1)
+#define TWL6030_GPADCR				BIT(0)
+
+/**
+ * struct twl6030_chnl_calib - channel calibration
+ * @gain:		slope coefficient for ideal curve
+ * @gain_error:		gain error
+ * @offset_error:	offset of the real curve
+ */
+struct twl6030_chnl_calib {
+	s32 gain;
+	s32 gain_error;
+	s32 offset_error;
+};
+
+/**
+ * struct twl6030_ideal_code - GPADC calibration parameters
+ * GPADC is calibrated in two points: close to the beginning and
+ * to the and of the measurable input range
+ *
+ * @code1:	ideal code for the input at the beginning
+ * @code2:	ideal code for at the end of the range
+ * @volt1:	voltage input at the beginning(low voltage)
+ * @volt2:	voltage input at the end(high voltage)
+ */
+struct twl6030_ideal_code {
+	u16 code1;
+	u16 code2;
+	u16 volt1;
+	u16 volt2;
+};
+
+struct twl6030_gpadc_data;
+
+/**
+ * struct twl6030_gpadc_platform_data - platform specific data
+ * @nchannels:		number of GPADC channels
+ * @iio_channels:	iio channels
+ * @twl6030_ideal:	pointer to calibration parameters
+ * @start_conversion:	pointer to ADC start conversion function
+ * @channel_to_reg	pointer to ADC function to convert channel to
+ * 			register address for reading conversion result
+ * @calibrate:		pointer to calibration function
+ */
+struct twl6030_gpadc_platform_data {
+	const int nchannels;
+	const struct iio_chan_spec *iio_channels;
+	const struct twl6030_ideal_code *ideal;
+	int (*start_conversion)(int channel);
+	u8 (*channel_to_reg)(int channel);
+	int (*calibrate)(struct twl6030_gpadc_data *gpadc);
+};
+
+/**
+ * struct twl6030_gpadc_data - GPADC data
+ * @dev:		device pointer
+ * @lock:		mutual exclusion lock for the structure
+ * @irq_complete:	completion to signal end of conversion
+ * @twl6030_cal_tbl:	pointer to calibration data for each
+ * 			channel with gain error and offset
+ * @pdata:		pointer to device specific data
+ */
+struct twl6030_gpadc_data {
+	struct device	*dev;
+	struct mutex	lock;
+	struct completion	irq_complete;
+	struct twl6030_chnl_calib	*twl6030_cal_tbl;
+	const struct twl6030_gpadc_platform_data *pdata;
+};
+
+/*
+ * channels 11, 12, 13, 15 and 16 have no calibration data
+ * calibration offset is same for channels 1, 3, 4, 5
+ *
+ * The data is taken from GPADC_TRIM registers description.
+ * GPADC_TRIM registers keeps difference between the code measured
+ * at volt1 and volt2 input voltages and corresponding code1 and code2
+ */
+static const struct twl6030_ideal_code
+	twl6030_ideal[TWL6030_GPADC_MAX_CHANNELS] = {
+	[0] = { /* ch 0, external, battery type, resistor value */
+		.code1 = 116,
+		.code2 = 745,
+		.volt1 = 141,
+		.volt2 = 910,
+	},
+	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[2] = { /* ch 2, external, audio accessory/general purpose */
+		.code1 = 55,
+		.code2 = 818,
+		.volt1 = 101,
+		.volt2 = 1499,
+	},
+	[3] = { /* ch 3, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[4] = { /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[5] = { /* ch 5, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[6] = { /* ch 6, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[7] = { /* ch 7, internal, main battery */
+		.code1 = 614,
+		.code2 = 941,
+		.volt1 = 3001,
+		.volt2 = 4599,
+	},
+	[8] = { /* ch 8, internal, backup battery */
+		.code1 = 82,
+		.code2 = 688,
+		.volt1 = 501,
+		.volt2 = 4203,
+	},
+	[9] = { /* ch 9, internal, external charger input */
+		.code1 = 182,
+		.code2 = 818,
+		.volt1 = 2001,
+		.volt2 = 8996,
+	},
+	[10] = { /* ch 10, internal, VBUS */
+		.code1 = 149,
+		.code2 = 818,
+		.volt1 = 1001,
+		.volt2 = 5497,
+	},
+	[11] = {},	/* ch 11, internal, VBUS charging current */
+	[12] = {},	/* ch 12, internal, Die temperature */
+	[13] = {},	/* ch 13, internal, Die temperature */
+	[14] = { /* ch 14, internal, USB ID line */
+		.code1 = 48,
+		.code2 = 714,
+		.volt1 = 323,
+		.volt2 = 4800,
+	},
+	[15] = {},	/* ch 15, internal, test network */
+	[16] = {},	/* ch 16, internal, test network */
+};
+
+static const struct twl6030_ideal_code
+			twl6032_ideal[TWL6032_GPADC_MAX_CHANNELS] = {
+	[0] = { /* ch 0, external, battery type, resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[2] = { /* ch 2, external, audio accessory/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 660,
+		.volt2 = 1500,
+	},
+	[3] = { /* ch 3, external, temperature with external diode/general
+								purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[4] = { /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[5] = { /* ch 5, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[6] = { /* ch 6, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[7] = { /* ch7, internal, system supply */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+	[8] = { /* ch8, internal, backup battery */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+	[9] = { /* ch 9, internal, external charger input */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 3960,
+		.volt2 = 9000,
+	},
+	[10] = { /* ch10, internal, VBUS */
+		.code1 = 150,
+		.code2 = 751,
+		.volt1 = 1000,
+		.volt2 = 5000,
+	},
+	[11] = { /* ch 11, internal, VBUS DC-DC output current */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 660,
+		.volt2 = 1500,
+	},
+	[12] = { /* ch 12, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[13] = { /* ch 13, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[14] = { /* ch 14, internal, USB ID line */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2420,
+		.volt2 = 5500,
+	},
+	[15] = {},	/* ch 15, internal, test network */
+	[16] = {},	/* ch 16, internal, test network */
+	[17] = {},	/* ch 17, internal, battery charging current */
+	[18] = { /* ch 18, internal, battery voltage */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+};
+
+static inline int twl6030_gpadc_write(u8 reg, u8 val)
+{
+	return twl_i2c_write_u8(TWL6030_MODULE_GPADC, val, reg);
+}
+
+static inline int twl6030_gpadc_read(u8 reg, u8 *val)
+{
+
+	return twl_i2c_read(TWL6030_MODULE_GPADC, val, reg, 2);
+}
+
+static int twl6030_gpadc_enable_irq(u8 mask)
+{
+	int ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_LINE_B);
+	if (ret < 0)
+		return ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_STS_B);
+
+	return ret;
+}
+
+static void twl6030_gpadc_disable_irq(u8 mask)
+{
+	twl6030_interrupt_mask(mask, REG_INT_MSK_LINE_B);
+	twl6030_interrupt_mask(mask, REG_INT_MSK_STS_B);
+}
+
+static irqreturn_t twl6030_gpadc_irq_handler(int irq, void *_gpadc)
+{
+	struct twl6030_gpadc_data *gpadc = _gpadc;
+
+	complete(&gpadc->irq_complete);
+
+	return IRQ_HANDLED;
+}
+
+static int twl6030_start_conversion(int channel)
+{
+	return twl6030_gpadc_write(TWL6030_GPADC_CTRL_P1,
+					TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static int twl6032_start_conversion(int channel)
+{
+	int ret;
+
+	ret = twl6030_gpadc_write(TWL6032_GPADC_GPSELECT_ISB, channel);
+	if (ret)
+		return ret;
+
+	return twl6030_gpadc_write(TWL6032_GPADC_CTRL_P1,
+						TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static u8 twl6030_channel_to_reg(int channel)
+{
+	return TWL6030_GPADC_GPCH0_LSB + 2 * channel;
+}
+
+static u8 twl6032_channel_to_reg(int channel)
+{
+	/*
+	 * for any prior chosen channel, when the conversion is ready
+	 * the result is avalable in GPCH0_LSB, GPCH0_MSB.
+	 */
+
+	return TWL6032_GPADC_GPCH0_LSB;
+}
+
+static int twl6030_channel_calibrated(const struct twl6030_gpadc_platform_data
+                                       *pdata, int channel)
+{
+       /* not calibrated channels have 0 in all structure members */
+       return pdata->ideal[channel].code2;
+}
+
+static int twl6030_gpadc_make_correction(struct twl6030_gpadc_data *gpadc,
+				int channel, int raw_code)
+{
+	int corrected_code;
+
+	corrected_code = ((raw_code * 1000) -
+		gpadc->twl6030_cal_tbl[channel].offset_error) /
+		gpadc->twl6030_cal_tbl[channel].gain_error;
+
+	return corrected_code;
+}
+
+static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
+		int channel, int *res)
+{
+	u8 reg = gpadc->pdata->channel_to_reg(channel);
+	__le16 val;
+	int raw_code;
+	int ret;
+
+	ret = twl6030_gpadc_read(reg, (u8 *)&val);
+	if (ret) {
+		dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
+		return ret;
+	}
+
+	raw_code = le16_to_cpup(&val);
+	dev_dbg(gpadc->dev, "GPADC raw code: %d", raw_code);
+
+	if (twl6030_channel_calibrated(gpadc->pdata, channel))
+		*res = twl6030_gpadc_make_correction(gpadc, channel, raw_code);
+	else
+		*res = raw_code;
+
+	return ret;
+}
+
+static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
+		int channel, int *val)
+{
+	int corrected_code;
+	int channel_value;
+	int ret;
+
+	ret = twl6030_gpadc_get_raw(gpadc, channel, &corrected_code);
+	if (ret)
+		return ret;
+
+	channel_value = corrected_code *
+			gpadc->twl6030_cal_tbl[channel].gain;
+
+	/* Shift back into mV range */
+	channel_value /= 1000;
+
+	dev_dbg(gpadc->dev, "GPADC corrected code: %d", corrected_code);
+	dev_dbg(gpadc->dev, "GPADC value: %d", channel_value);
+
+	*val = channel_value;
+
+	return ret;
+}
+
+static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
+			     const struct iio_chan_spec *chan,
+			     int *val, int *val2, long mask)
+{
+	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
+	int ret = -EINVAL;
+	long timeout;
+
+	mutex_lock(&gpadc->lock);
+
+	ret = gpadc->pdata->start_conversion(chan->channel);
+	if (ret) {
+		dev_err(gpadc->dev, "failed to start conversion\n");
+		goto err;
+	}
+	/* wait for conversion to complete */
+	timeout = wait_for_completion_interruptible_timeout(
+				&gpadc->irq_complete, msecs_to_jiffies(5000));
+	if (!timeout)
+		return -ETIMEDOUT;
+	else if (timeout < 0)
+		return EINTR;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	case IIO_CHAN_INFO_PROCESSED:
+		ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	default:
+		break;
+	}
+err:
+	mutex_unlock(&gpadc->lock);
+
+	return ret;
+}
+
+/*
+ * The GPADC channels are calibrated using a two point calibration method.
+ * The channels measured with two known values: volt1 and volt2, and
+ * ideal corresponding output codes are known: code1, code2.
+ * The difference(d1, d2) between ideal and measured codes stored in trim
+ * registers.
+ * The goal is to find offset and gain of the real curve for each calibrated
+ * channel.
+ * gain: k = 1 + ((d2 - d1) / (x2 - x1))
+ * offset: b = d1 + (k - 1) * x1
+ */
+static void twl6030_calibrate_channel(struct twl6030_gpadc_data *gpadc,
+					int channel, int d1, int d2)
+{
+	int b, k, gain, x1, x2;
+	const struct twl6030_ideal_code *ideal = gpadc->pdata->ideal;
+
+	/* Gain */
+	gain = ((ideal[channel].volt2 - ideal[channel].volt1) * 1000) /
+		(ideal[channel].code2 - ideal[channel].code1);
+
+	x1 = ideal[channel].code1;
+	x2 = ideal[channel].code2;
+
+	/* k - real curve gain */
+	k = 1000 + (((d2 - d1) * 1000) / (x2 - x1));
+
+	/* b - offset of the real curve gain */
+	b = (d1 * 1000) - (k - 1000) * x1;
+
+	gpadc->twl6030_cal_tbl[channel].gain = gain;
+	gpadc->twl6030_cal_tbl[channel].gain_error = k;
+	gpadc->twl6030_cal_tbl[channel].offset_error = b;
+
+	dev_dbg(gpadc->dev, "GPADC d1   for Chn: %d = %d\n", channel, d1);
+	dev_dbg(gpadc->dev, "GPADC d2   for Chn: %d = %d\n", channel, d2);
+	dev_dbg(gpadc->dev, "GPADC x1   for Chn: %d = %d\n", channel, x1);
+	dev_dbg(gpadc->dev, "GPADC x2   for Chn: %d = %d\n", channel, x2);
+	dev_dbg(gpadc->dev, "GPADC Gain for Chn: %d = %d\n", channel, gain);
+	dev_dbg(gpadc->dev, "GPADC k    for Chn: %d = %d\n", channel, k);
+	dev_dbg(gpadc->dev, "GPADC b    for Chn: %d = %d\n", channel, b);
+}
+
+static inline int twl6030_gpadc_get_trim_offset(s8 d)
+{
+	/*
+	 * XXX NOTE!
+	 * bit 0 - sign, bit 7 - reserved, 6..1 - trim value
+	 * though, the documentation states that trim value
+	 * is absolute value, the correct conversion results are
+	 * obtained if the value is interpreted as 2's complement.
+	 */
+	__u32 temp = ((d & 0x7f) >> 1) | ((d & 1) << 6);
+
+	return sign_extend32(temp, 6);
+}
+
+static int twl6030_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int ret;
+	int chn;
+	u8 trim_regs[TWL6030_GPADC_MAX_CHANNELS];
+	s8 d1, d2;
+
+	/*
+	 * for calibration two measurements have been performed at
+	 * factory, for some channels, during the production test and
+	 * have been stored in registers. This two stored values are
+	 * used to correct the measurements. The values represent
+	 * offsets for the given input from the output on ideal curve.
+	 */
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs,
+			TWL6030_GPADC_TRIM1, 16);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	for (chn = 0; chn < TWL6030_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+			d1 = trim_regs[0];
+			d2 = trim_regs[1];
+			break;
+		case 1:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+			d1 = trim_regs[4];
+			d2 = trim_regs[5];
+			break;
+		case 2:
+			d1 = trim_regs[12];
+			d2 = trim_regs[13];
+			break;
+		case 7:
+			d1 = trim_regs[6];
+			d2 = trim_regs[7];
+			break;
+		case 8:
+			d1 = trim_regs[2];
+			d2 = trim_regs[3];
+			break;
+		case 9:
+			d1 = trim_regs[8];
+			d2 = trim_regs[9];
+			break;
+		case 10:
+			d1 = trim_regs[10];
+			d2 = trim_regs[11];
+			break;
+		case 14:
+			d1 = trim_regs[14];
+			d2 = trim_regs[15];
+			break;
+		default:
+			continue;
+		}
+
+		d1 = twl6030_gpadc_get_trim_offset(d1);
+		d2 = twl6030_gpadc_get_trim_offset(d2);
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int chn, d1 = 0, d2 = 0, temp;
+	u8 trim_regs[17];
+	int ret;
+
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
+			TWL6030_GPADC_TRIM1, 16);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	/*
+	 * Loop to calculate the value needed for returning voltages from
+	 * GPADC not values.
+	 *
+	 * gain is calculated to 3 decimal places fixed point.
+	 */
+	for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+		case 1:
+		case 2:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+		case 11:
+		case 12:
+		case 13:
+		case 14:
+			/* D1 */
+			d1 = (trim_regs[3] & 0x1F) << 2;
+			d1 |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				d1 = -d1;
+
+			/* D2 */
+			d2 = (trim_regs[4] & 0x3F) << 2;
+			d2 |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				d2 = -d2;
+			break;
+		case 8:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[8] & 0x18) << 1;
+			d1 |= (trim_regs[7] & 0x1E) >> 1;
+			if (trim_regs[7] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[10] & 0x1F) << 2;
+			d2 |= (trim_regs[8] & 0x06) >> 1;
+			if (trim_regs[8] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		case 9:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[14] & 0x18) << 1;
+			d1 |= (trim_regs[12] & 0x1E) >> 1;
+			if (trim_regs[12] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[16] & 0x1F) << 2;
+			d2 |= (trim_regs[14] & 0x06) >> 1;
+			if (trim_regs[14] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+		case 10:
+			/* D1 */
+			d1 = (trim_regs[11] & 0x0F) << 3;
+			d1 |= (trim_regs[9] & 0x0E) >> 1;
+			if (trim_regs[9] & 0x01)
+				d1 = -d1;
+
+			/* D2 */
+			d2 = (trim_regs[15] & 0x0F) << 3;
+			d2 |= (trim_regs[13] & 0x0E) >> 1;
+			if (trim_regs[13] & 0x01)
+				d2 = -d2;
+			break;
+		case 7:
+		case 18:
+			/* D1 */
+			temp = (trim_regs[3] & 0x1F) << 2;
+			temp |= (trim_regs[1] & 0x06) >> 1;
+			if (trim_regs[1] & 0x01)
+				temp = -temp;
+
+			d1 = (trim_regs[5] & 0x7E) >> 1;
+			if (trim_regs[5] & 0x01)
+				d1 = -d1;
+
+			d1 += temp;
+
+			/* D2 */
+			temp = (trim_regs[4] & 0x3F) << 2;
+			temp |= (trim_regs[2] & 0x06) >> 1;
+			if (trim_regs[2] & 0x01)
+				temp = -temp;
+
+			d2 = (trim_regs[6] & 0xFE) >> 1;
+			if (trim_regs[6] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		default:
+			/* No data for other channels */
+			continue;
+		}
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+#define TWL6030_GPADC_CHAN(chn, _type, chan_info) {	\
+	.type = _type,					\
+	.channel = chn,					\
+	.info_mask_separate = BIT(chan_info), 		\
+	.indexed = 1,					\
+}
+
+/* internal test network channel */
+#define TWL6030_GPADC_TEST_CHAN(chn, chan_info) {	\
+	.type = IIO_VOLTAGE,				\
+	.channel = chn,					\
+	.indexed = 1,					\
+}
+
+static const struct iio_chan_spec twl6030_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_TEMP, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(2, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_TEMP, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(5, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(12, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(13, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(14, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_TEST_CHAN(15, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_TEST_CHAN(16, IIO_CHAN_INFO_RAW),
+};
+
+static const struct iio_chan_spec twl6032_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_TEMP, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(2, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_TEMP, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(5, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(12, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(13, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(14, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_TEST_CHAN(15, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_TEST_CHAN(16, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(17, IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(18, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+};
+
+static const struct iio_info twl6030_gpadc_iio_info = {
+	.read_raw = &twl6030_gpadc_read_raw,
+	.driver_module = THIS_MODULE,
+};
+
+static const struct twl6030_gpadc_platform_data twl6030_pdata = {
+	.iio_channels = twl6030_gpadc_iio_channels,
+	.nchannels = TWL6030_GPADC_MAX_CHANNELS,
+	.ideal = twl6030_ideal,
+	.start_conversion = twl6030_start_conversion,
+	.channel_to_reg = twl6030_channel_to_reg,
+	.calibrate = twl6030_calibration,
+};
+
+static const struct twl6030_gpadc_platform_data twl6032_pdata = {
+	.iio_channels = twl6032_gpadc_iio_channels,
+	.nchannels = TWL6032_GPADC_MAX_CHANNELS,
+	.ideal = twl6032_ideal,
+	.start_conversion = twl6032_start_conversion,
+	.channel_to_reg = twl6032_channel_to_reg,
+	.calibrate = twl6032_calibration,
+};
+
+static const struct of_device_id of_twl6030_match_tbl[] = {
+	{
+		.compatible = "ti,twl6030_gpadc",
+		.data = &twl6030_pdata,
+	},
+	{
+		.compatible = "ti,twl6032_gpadc",
+		.data = &twl6032_pdata,
+	},
+	{ /* end */ }
+};
+
+static int twl6030_gpadc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct twl6030_gpadc_data *gpadc;
+	const struct twl6030_gpadc_platform_data *pdata;
+	const struct of_device_id *match;
+	struct iio_dev *indio_dev;
+	int irq;
+	int ret;
+
+	match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
+	pdata = match ? match->data : dev->platform_data;
+
+	if (!pdata)
+		return -EINVAL;
+
+	indio_dev = iio_device_alloc(sizeof(*gpadc));
+	if (!indio_dev) {
+		dev_err(dev, "failed allocating iio device\n");
+		ret = -ENOMEM;
+	}
+
+	gpadc = iio_priv(indio_dev);
+
+	gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
+					sizeof(struct twl6030_chnl_calib) *
+					pdata->nchannels, GFP_KERNEL);
+	if (!gpadc->twl6030_cal_tbl)
+		goto err_free_device;
+
+	gpadc->dev = dev;
+	gpadc->pdata = pdata;
+
+	platform_set_drvdata(pdev, indio_dev);
+	mutex_init(&gpadc->lock);
+	init_completion(&gpadc->irq_complete);
+
+	ret = pdata->calibrate(gpadc);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to read calibration registers\n");
+		goto err_free_device;
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "failed to get irq\n");
+		goto err_free_device;
+	}
+
+	ret = request_threaded_irq(irq, NULL, twl6030_gpadc_irq_handler,
+				IRQF_ONESHOT, "twl6030_gpadc", gpadc);
+	if (ret) {
+		dev_dbg(&pdev->dev, "could not request irq\n");
+		goto err_free_device;
+	}
+
+	ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
+		goto err_free_irq;
+	}
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+					TWL6030_REG_TOGGLE1);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC module\n");
+		goto err_free_irq;
+	}
+
+	indio_dev->name = DRIVER_NAME;
+	indio_dev->dev.parent = dev;
+	indio_dev->info = &twl6030_gpadc_iio_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->channels = pdata->iio_channels;
+	indio_dev->num_channels = pdata->nchannels;
+
+	ret = iio_device_register(indio_dev);
+	if (ret)
+		goto err_free_irq;
+
+	return ret;
+
+err_free_irq:
+	free_irq(irq, indio_dev);
+err_free_device:
+	iio_device_free(indio_dev);
+
+	return ret;
+}
+
+static int twl6030_gpadc_remove(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+
+	twl6030_gpadc_disable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	free_irq(platform_get_irq(pdev, 0), indio_dev);
+	iio_device_unregister(indio_dev);
+	iio_device_free(indio_dev);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int twl6030_gpadc_suspend(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCR,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error reseting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+
+static int twl6030_gpadc_resume(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error setting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+#endif
+
+SIMPLE_DEV_PM_OPS(twl6030_gpadc_pm_ops, twl6030_gpadc_suspend,
+					twl6030_gpadc_resume);
+
+static struct platform_driver twl6030_gpadc_driver = {
+	.probe		= twl6030_gpadc_probe,
+	.remove		= twl6030_gpadc_remove,
+	.driver		= {
+		.name	= DRIVER_NAME,
+		.owner	= THIS_MODULE,
+		.pm	= &twl6030_gpadc_pm_ops,
+		.of_match_table = of_twl6030_match_tbl,
+	},
+};
+
+module_platform_driver(twl6030_gpadc_driver);
+
+MODULE_ALIAS("platform: " DRIVER_NAME);
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_DESCRIPTION("twl6030 ADC driver");
+MODULE_LICENSE("GPL");
-- 
1.8.1.2



From oleksandr.kozaruk at ti.com  Wed Jul 17 07:12:42 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Wed, 17 Jul 2013 14:12:42 +0300
Subject: [PATCH v5 0/2] TWL6030, TWL6032 GPADC driver
Message-ID: <1374059564-6872-1-git-send-email-oleksandr.kozaruk@ti.com>

Hello,

v5 - gpadc DT node renamed from "gpadc" to generic "adc", added
     temperature channels; raw code is corracted with calibration
     data.
v4 - addressed comments: fixed style violation, bug in freeing memory,
     added comments explaining calibration method, removed test network
     channels from exposing to userspace, error handling for 
     wait_for_complition
v3 - fixed compiler warning
v2 - the driver put in drivers/iio, and
converted using iio facilities as suggested by Graeme.

TWL603[02] GPADC is used to measure battery voltage,
battery temperature, battery presence ID, and could
be used to measure twl603[02] die temperature.
This is used on TI blaze, blaze tablet platforms.

The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19
channels respectively. Some channels have current
source and are used for measuring voltage drop
on resistive load for detecting battery ID resistance,
or measuring voltage drop on NTC resistors for external
temperature measurements, other channels measure voltage,
(i.e. battery voltage), and have inbuilt voltage dividers,
thus, capable to scale voltage. Some channels are dedicated
for measuring die temperature.

Some channels could be calibrated in 2 points, having
offsets from ideal values in trim registers.

The difference between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i. e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

The driver is derived from git://git.omapzoom.org/kernel/omap.git
The original driver's authors and contributors are Balaji T K,
Graeme Gregory, Ambresh K, Girish S Ghongdemath.

The changes to the original driver:
- device tree adaptation;
- drop ioctl support - never been used;
- unified measurement method for both devices;
- get rid of "if (device == X)" code style to data driven;
- drop polling end of conversion and use interrupt instead;
- iio framework is used

Tested with on blaze tablet 2 with OMAP4430(twl6030), and
OMAP4470(twl6032) SOMs.

The patches were tested against 3.10-rc7

Oleksandr Kozaruk (2):
  ARM: dts: twl: Add GPADC data to device tree
  iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

 arch/arm/boot/dts/twl6030.dtsi  |    6 +
 drivers/iio/adc/Kconfig         |   14 +
 drivers/iio/adc/Makefile        |    1 +
 drivers/iio/adc/twl6030-gpadc.c | 1026 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 1047 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

-- 
1.8.1.2



From gsi at denx.de  Wed Jul 17 07:22:29 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Wed, 17 Jul 2013 13:22:29 +0200
Subject: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them
In-Reply-To: <20130715201734.GF11538@sirena.org.uk>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1373914074-20889-2-git-send-email-gsi@denx.de>
 <20130715201734.GF11538@sirena.org.uk>
Message-ID: <20130717112229.GK7080@book.gsilab.sittig.org>

On Mon, Jul 15, 2013 at 21:17 +0100, Mark Brown wrote:
> 
> On Mon, Jul 15, 2013 at 08:47:30PM +0200, Gerhard Sittig wrote:
> > clocks need to get prepared before they can get enabled,
> > fix the MPC512x PSC SPI master's initialization
> 
> > Signed-off-by: Gerhard Sittig <gsi at denx.de>
> > ---
> >  drivers/spi/spi-mpc512x-psc.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
> > index 29fce6a..76b20ea 100644
> > --- a/drivers/spi/spi-mpc512x-psc.c
> > +++ b/drivers/spi/spi-mpc512x-psc.c
> > @@ -395,7 +395,7 @@ static int mpc512x_psc_spi_port_config(struct spi_master *master,
> >  
> >  	sprintf(name, "psc%d_mclk", master->bus_num);
> >  	spiclk = clk_get(&master->dev, name);
> > -	clk_enable(spiclk);
> > +	clk_prepare_enable(spiclk);
> >  	mps->mclk = clk_get_rate(spiclk);
> >  	clk_put(spiclk);
> 
> This code is *clearly* buggy and should be fixed rather than papered
> over.  Not only is there no matching put the driver is also dropping the
> reference to the clock rather than holding on to it while it's in use.

"This code" refers to the driver's original condition, right?  I
agree that the driver has been suffering from incomplete clock
handling since it was born three years ago.  And that this issue
shall get addressed.  The question is just whether it needs to be
part of this series which has a different focus.

What the above patch addresses is prevention of an immediate and
fatal breakage, when common clock gets used but clocks aren't
prepared before getting enabled.  So I consider it appropriate as
a step in preparation before introducing support for common clock
on the platform.  (It's funny that I had a comment in this spirit
in the commit message, but trimmed it to not be overly verbose.)

What the patch does not address is to fix any other deficiencies
in the driver which might have been lurking there for ages.  This
would be the scope of a different patch or series, as addressing
it here as well would mix orthogonal issues within one series,
and would complicate review and test (and would delay or even
potentially kill the introduction of desirable support for common
infrastructure just because other legacy non-fatal issues aren't
addressed as well in bypassing).

I will look into what I can do to address your concerns about
proper general clock handling in this specific driver.  But I'm
unable to do this for all other drivers as well which I happen to
pass by as I work on platform code (partially due to lack of
knowledge).  In any case I won't be able to test all of these
changes in all subsystems (mostly due to lack of hardware and
test setups).

So I suggest to leave these general cleanup activities for a
separate series.  The current series certainly improves general
platform code, transparently brings new drivers into successful
operation, and keeps the quality of existing code (doesn't break
anything, does even actively prevent breakage).  So it shall be
acceptable despite its not being perfect (like addressing each
and every other aspect which may arise elsewhere).  Where would I
stop then?

Sorry for the lengthy reply, but I guess it's about just one
general aspect which equally applies to other parts of the
series, not just the specific SPI driver which the feedback was
provided for.  And I do appreciate your looking at the
submission.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


From lee.jones at linaro.org  Wed Jul 17 07:23:29 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 17 Jul 2013 12:23:29 +0100
Subject: [PATCH 2/3] mfd: sec: Add clock cell for s2mps11
In-Reply-To: <1373197462-4033-3-git-send-email-yadi.brar@samsung.com>
References: <1373197462-4033-1-git-send-email-yadi.brar@samsung.com>
 <1373197462-4033-3-git-send-email-yadi.brar@samsung.com>
Message-ID: <20130717112329.GC3336@laptop>

On Sun, 07 Jul 2013, Yadwinder Singh Brar wrote:

> This patch adds clock to list of mfd cells for s2mps11 and DT documentation
> for clock part.
> 
> Signed-off-by: Yadwinder Singh Brar <yadi.brar at samsung.com>
> ---
>  Documentation/devicetree/bindings/mfd/s2mps11.txt |   20 ++++++++++++++++++++
>  drivers/mfd/sec-core.c                            |    4 +++-
>  2 files changed, 23 insertions(+), 1 deletions(-)

For drivers/mfd/sec-core.c:

Acked-by: Lee Jones <lee.jones at linaro.org>

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From gsi at denx.de  Wed Jul 17 07:27:50 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Wed, 17 Jul 2013 13:27:50 +0200
Subject: [PATCH v1 15/24] serial: mpc512x: OF clock lookup, use the
 'mclk' name
In-Reply-To: <20130715215423.GU14452@pengutronix.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1373924770-22599-1-git-send-email-gsi@denx.de>
 <20130715215423.GU14452@pengutronix.de>
Message-ID: <20130717112750.GL7080@book.gsilab.sittig.org>

On Mon, Jul 15, 2013 at 23:54 +0200, Sascha Hauer wrote:
> 
> On Mon, Jul 15, 2013 at 11:46:01PM +0200, Gerhard Sittig wrote:
> > with device tree based clock lookup, the MCLK name no longer
> > depends on the PSC index
> > 
> > Signed-off-by: Gerhard Sittig <gsi at denx.de>
> > ---
> >  drivers/tty/serial/mpc52xx_uart.c |    8 ++------
> >  1 file changed, 2 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/tty/serial/mpc52xx_uart.c b/drivers/tty/serial/mpc52xx_uart.c
> > index 53c1093..221fb89 100644
> > --- a/drivers/tty/serial/mpc52xx_uart.c
> > +++ b/drivers/tty/serial/mpc52xx_uart.c
> > @@ -619,21 +619,17 @@ static irqreturn_t mpc512x_psc_handle_irq(struct uart_port *port)
> >  static int mpc512x_psc_clock(struct uart_port *port, int enable)
> >  {
> >  	struct clk *psc_clk;
> > -	int psc_num;
> > -	char clk_name[10];
> >  
> >  	if (uart_console(port))
> >  		return 0;
> >  
> > -	psc_num = (port->mapbase & 0xf00) >> 8;
> > -	snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
> > -	psc_clk = clk_get(port->dev, clk_name);
> > +	psc_clk = clk_get(port->dev, "mclk");
> 
> Same comment applies here as Mark made to the spi driver.

So I'd like to respond in the same way as I did for the SPI
driver. :)

The scope of this series is the introduction of support for the
common clock framework.  Addressing other (legacy non-fatal and
previously accepted) issues as they get identified in bypassing
would be the scope of a separate patch or series.

I'm not questioning the need to fix other additionally identified
issues.  I'm just asking whether they shall be in the scope of
this very series.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


From lee.jones at linaro.org  Wed Jul 17 07:27:59 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 17 Jul 2013 12:27:59 +0100
Subject: [PATCH 3/3] mfd: s2mps11: Remove clocks from regulators list
In-Reply-To: <1373197462-4033-4-git-send-email-yadi.brar@samsung.com>
References: <1373197462-4033-1-git-send-email-yadi.brar@samsung.com>
 <1373197462-4033-4-git-send-email-yadi.brar@samsung.com>
Message-ID: <20130717112759.GD3336@laptop>

On Sun, 07 Jul 2013, Yadwinder Singh Brar wrote:

> Since these are fixed rate clocks which are registered with common clock
> framework so remove these from list of regulators which were unnecessarily
> incrementing the count(S2MPS11_REGULATOR_MAX) of regulators.
> 
> Signed-off-by: Yadwinder Singh Brar <yadi.brar at samsung.com>
> ---
>  include/linux/mfd/samsung/s2mps11.h |    6 +-----
>  1 files changed, 1 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/mfd/samsung/s2mps11.h b/include/linux/mfd/samsung/s2mps11.h
> index d0d52ea..b3ddf98 100644
> --- a/include/linux/mfd/samsung/s2mps11.h
> +++ b/include/linux/mfd/samsung/s2mps11.h
> @@ -167,11 +167,8 @@ enum s2mps11_regulators {
>  	S2MPS11_BUCK8,
>  	S2MPS11_BUCK9,
>  	S2MPS11_BUCK10,
> -	S2MPS11_AP_EN32KHZ,
> -	S2MPS11_CP_EN32KHZ,
> -	S2MPS11_BT_EN32KHZ,

These aren't mentioned anywhere else in the kernel, so I'll just apply
the patch.

> -	S2MPS11_REG_MAX,
> +	S2MPS11_REGULATOR_MAX,
>  };
>  
>  #define S2MPS11_BUCK_MIN1	600000
> @@ -203,6 +200,5 @@ enum s2mps11_regulators {
>  #define S2MPS11_BUCK4_RAMP_EN_SHIFT	1
>  #define S2MPS11_BUCK6_RAMP_EN_SHIFT	0
>  #define S2MPS11_PMIC_EN_SHIFT	6
> -#define S2MPS11_REGULATOR_MAX (S2MPS11_REG_MAX - 3)
>  
>  #endif /*  __LINUX_MFD_S2MPS11_H */

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From s.nawrocki at samsung.com  Wed Jul 17 07:28:30 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 17 Jul 2013 13:28:30 +0200
Subject: [PATCH v3] clk: implement clk_unregister
In-Reply-To: <1370248626-3760-1-git-send-email-jiada_wang@mentor.com>
References: <1370248626-3760-1-git-send-email-jiada_wang@mentor.com>
Message-ID: <51E67FDE.7000301@samsung.com>

Hello,

On 06/03/2013 10:37 AM, Jiada Wang wrote:
> Currently clk_unregister is unimplemented, it is required in case
> sub modules want actually remove clk device registered by clk_register.
> This patch adds the implementation of clk_unregister.
> 
> Signed-off-by: Jiada Wang <jiada_wang at mentor.com>
> ---
>  drivers/clk/clk.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 57 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 934cfd1..0b9e13c 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -342,6 +342,25 @@ out:
>  	return ret;
>  }
>  
> + /**
> + * clk_debug_unregister - remove a clk node from the debugfs clk tree
> + * @clk: the clk being removed from the debugfs clk tree
> + *
> + * Dynamically removes a clk and all it's children clk nodes from the
> + * debugfs clk tree if clk->dentry points to debugfs created by
> + * clk_debug_register in __clk_init.
> + *
> + * Caller must hold prepare_lock.
> + *
> + */
> +static void clk_debug_unregister(struct clk *clk)
> +{
> +	if (!clk || !clk->dentry)
> +		return;
> +
> +	debugfs_remove_recursive(clk->dentry);
> +}
> +
>  /**
>   * clk_debug_reparent - reparent clk node in the debugfs clk tree
>   * @clk: the clk being reparented
> @@ -432,6 +451,9 @@ static inline int clk_debug_register(struct clk *clk) { return 0; }
>  static inline void clk_debug_reparent(struct clk *clk, struct clk *new_parent)
>  {
>  }
> +static inline void clk_debug_unregister(struct clk *clk)
> +{
> +}
>  #endif
>  
>  /* caller must hold prepare_lock */
> @@ -1790,9 +1812,42 @@ EXPORT_SYMBOL_GPL(clk_register);
>   * clk_unregister - unregister a currently registered clock
>   * @clk: clock to unregister
>   *
> - * Currently unimplemented.
>   */
> -void clk_unregister(struct clk *clk) {}
> +void clk_unregister(struct clk *clk)
> +{
> +	int i;
> +
> +	if (!clk)
> +		return;
> +
> +	mutex_lock(&prepare_lock);
> +	if (clk->prepare_count) {
> +		pr_debug("%s: can't unregister clk %s, it is prepared\n",
> +				__func__, clk->name);
> +		goto out;
> +	}
> +
> +	if (!hlist_empty(&clk->children)) {
> +		pr_debug("%s: clk %s has registered children\n",
> +				__func__, clk->name);
> +		goto out;

How about moving the clock to the orphan list instead, as Mike
suggested [1] ?

> +	}
> +
> +	clk_debug_unregister(clk);
> +
> +	hlist_del_init(&clk->child_node);
> +
> +	kfree(clk->parents);
> +	i = clk->num_parents;
> +	while (--i >= 0)
> +		kfree(clk->parent_names[i]);
> +	kfree(clk->parent_names);
> +	kfree(clk->name);
> +	kfree(clk);
> +out:
> +	mutex_unlock(&prepare_lock);
> +	return;

Redundant return statement.

> +}

Shouldn't we also free the clock supplier specific data structure
for the clock, i.e. the structure struct clk_hw is embedded in ?

One possible way to solve this could be to provide, e.g. destroy()
operation in struct clk_ops ? Alternatively clock providers would
need to store a list of their clock specific data structures
associated with each struct clk they have registered.

[1] http://www.spinics.net/lists/arm-kernel/msg250613.html


Thanks,
Sylwester


From grygorii.strashko at ti.com  Wed Jul 17 07:41:49 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Wed, 17 Jul 2013 14:41:49 +0300
Subject: [PATCH 0/3] ARM: OMAP2+: omap_device: add dynamic pinctrl handling
Message-ID: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>

Hi Tony, Kevin

This patch series introduces dynamic pinctrl handling in OMAP device framework
in the same way as it was before switching to DT. 
This allow OMAP devices driver's developers to simply add dynamic pinctrl
handling for "default", "active", "idle", "sleep" PIN states in their drivers
by modifying DT definitions only - no modifications in drivers code are not needed.

Tested on OMAP4 SDP(Tablet2) board using omap4-sdp.dts
- UART3/4 autoidle
- suspend, by adding some fake "sleep" pin state
- wake up (PRCM) IRQ generation by ading call to omap44xx_prm_reconfigure_io_chain()
  right after each call to pinctrl_pm_select_xx() API.

UART3(console) reg dumps:
- active 
 0x4A100140(RTS/CTS) - 0x00000118
 0x4A100140(TX/RX) - 0x00000100
- idle
 0x4A100140(RTS/CTS) - 0x00000118
 0x4A100144(TX/RX) - 0x00004100

UART4 reg dumps:
- active 
 0x4A10015C(TX/RX) - 0x00000100
- idle
 0x4A10015C(TX/RX) - 0x00004100

Debugfs:
# cat sys/kernel/debug/pinctrl/4a100040.pinmux/pinmux-pins
[snip]
pin 128 (4a100140.0): 48020000.serial (GPIO UNCLAIMED) function pinmux_uart3_pins group pinmux_uart3_pins
pin 129 (4a100142.0): 48020000.serial (GPIO UNCLAIMED) function pinmux_uart3_pins group pinmux_uart3_pins
pin 130 (4a100144.0): 48020000.serial (GPIO UNCLAIMED) function pinmux_uart3_pins_active group pinmux_uart3_pins_active
pin 131 (4a100146.0): 48020000.serial (GPIO UNCLAIMED) function pinmux_uart3_pins group pinmux_uart3_pins
[snip]
pin 142 (4a10015c.0): 4806e000.serial (GPIO UNCLAIMED) function pinmux_uart4_pins_idle group pinmux_uart4_pins_idle
pin 143 (4a10015e.0): 4806e000.serial (GPIO UNCLAIMED) function pinmux_uart4_pins group pinmux_uart4_pins

Changes since RFC:
- _od_resume_noirq() fixed - "idle" state was not selected on resume
- description updated

RFC: https://lkml.org/lkml/2013/6/21/309

Based on v3.11-rc1 plus patch series from Tony Lindgren
"[PATCH 0/4] improved support for runtime muxing for pinctrl"
http://www.spinics.net/lists/arm-kernel/msg258827.html:

fd7937b drivers: Add pinctrl handling for dynamic pin states
479246b pinctrl: Add support for additional dynamic states
c9f37e8 pinctrl: Allow pinctrl to have multiple active states
756f10b pinctrl: Remove duplicate code in pinctrl_pm_select_state functions
ad81f05 Linux 3.11-rc1

Related discussions:
- drivers: pinctrl sleep and idle states in the core
 http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html
- [PATCH] drivers: pinctrl: add active state to core
 http://marc.info/?l=linux-kernel&m=137094012703340&w=2
- [PATCH] pinctrl: document the pinctrl PM states
 https://lkml.org/lkml/2013/6/11/501
- [3/3] i2c: nomadik: use pinctrl PM helpers
 https://patchwork.kernel.org/patch/2670291/
- mmc: omap_hsmmc: Remux pins to support SDIO interrupt and PM runtime
 https://patchwork.kernel.org/patch/2690191/
- [PATCH 00/11] drivers: Add Pinctrl PM support
 https://lkml.org/lkml/2013/5/31/210


Grygorii Strashko (3):
  pinctrl: rollback check for !dev->pins in pinctrl_pm_select*() APIs
  ARM: OMAP2+: omap_device: add pinctrl handling
  ARM: dts: omap4-sdp: add dynamic pin states for uart3/4

 arch/arm/boot/dts/omap4-sdp.dts   |   34 +++++++++++++++++++++++++++----
 arch/arm/mach-omap2/omap_device.c |   40 +++++++++++++++++++++++++++++++------
 drivers/pinctrl/core.c            |   12 +++++++++++
 3 files changed, 76 insertions(+), 10 deletions(-)

Regards,
-grygorii

CC: Linus Walleij <linus.walleij at linaro.org>
CC: Stephen Warren <swarren at wwwdotorg.org>
CC: Roger Quadros <rogerq at ti.com>
-- 
1.7.9.5



From grygorii.strashko at ti.com  Wed Jul 17 07:41:51 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Wed, 17 Jul 2013 14:41:51 +0300
Subject: [PATCH 2/3] ARM: OMAP2+: omap_device: add pinctrl handling
In-Reply-To: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
Message-ID: <1374061312-25469-3-git-send-email-grygorii.strashko@ti.com>

Before switching to DT pinctrl states of OMAP IPs have been handled by hwmod
framework. After switching to DT-boot the pinctrl handling was dropped from
hwmod framework and, as it was recommended, OMAP IP's drivers have to be updated
to handle pinctrl states by itself using pinctrl_pm_select_xx() helpers
(see http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html)

But this is not right for OMAP2+ SoC where real IPs state is controlled
by omap_device core which enables/disables modules & clocks actually.

For example, if OMAP I2C driver will handle pinctrl state during system wide
suspend the following issue may occure:
- suspend_noirq - I2C device can be still active because of PM auto-suspend
  |-_od_suspend_noirq
     |- omap_i2c_suspend_noirq
        |- PINs state set to SLEEP
  |- pm_generic_runtime_suspend
     |- omap_i2c_runtime_suspend()
        |- PINs state set to IDLE  <--- *oops* PINs state is IDLE and not SLEEP
  |- omap_device_idle()
     |- omap_hwmod_idle()
        |- _idle()
           |- disbale module (sysc&clocks)

- resume_noirq - I2C was active before suspend
  |-_od_resume_noirq
     |- omap_hwmod_enable()
        |- _enable()
           |- enable module (sysc&clocks)
     |- pm_generic_runtime_resume
        |- omap_i2c_runtime_resume()
           |- PINs state set to DEFAULT  <--- !!!!
     |- omap_i2c_resume_noirq
        |- PINs state set to DEFAULT
        |- PINs state set to IDLE  <--- *big oops* we have active module and its
                                         PINs state is IDLE
(see https://patchwork.kernel.org/patch/2642101/)

Of course, everything can be handled by adding a tons of code in ecah driver to
check PM state of device and override default behavior of omap_device core, but
this not good.

Hence, add pinctrl handling in omap_device core as shown below:
                                         +
                                         |
                                         |  .probe()
                                         |
                                   +-----v--------+
                                   |              |
                                   |  default     |
                                   |              |
                                   +----+--+------+
                                        |  |
                        pm_runtime_get()|  | pm_runtime_put()
                       +----------------+  +------------+
                       |                                |
                +------v------+ pm_runtime_put()+-------v-----+
                |             +----------------->             |
    +----------->  Active     |pm_runtime_get() |   Idle      <----------+
    |           |             <-----------------+             |          |
    |           +-------+-----+                 +-------+-----+          |
    |                   |.suspend_noirq()               |.suspend_noirq()|
    |                   |                               |                |
    |                   |                               |                |
    |                   |                               |                |
    |                   |                               |                |
    |           +-------v-----+                 +-------v-----+          |
    |           |             |                 |             |          |
    +-----------+  Sleep      ------+           |  Sleep      +----------+
.resume_noirq() |             |     |           |             |.resume_noirq()
                +-------|-----+     |           +-------------+
                        |  Idle     |
                        +-----------+
1) on PM runtime resume
- switch pinctrl state to "active"
2) on PM runtime suspend
- switch pinctrl state to "idle"
3) during system wide suspend
- switch pinctrl state to "sleep" or "idle" if omap_device core disables device
- switch pinctrl state to "sleep" if device has been disabled already
4) during system wide resume
- switch pinctrl state to "active" if omap_device core has
  disabled device during suspend
- switch pinctrl state to "idle" if device was already disabled before suspend

This will enable pinctrl for all OMAP2+ IP's drivers by default -
no changes in code is needed and only DT data will need to be updated
(add "default", "active", "idle", "sleep" states).

Related discussions:
- [3/3] i2c: nomadik: use pinctrl PM helpers
 https://patchwork.kernel.org/patch/2670291/
- mmc: omap_hsmmc: Remux pins to support SDIO interrupt and PM runtime
 https://patchwork.kernel.org/patch/2690191/
- [PATCH 00/11] drivers: Add Pinctrl PM support
 https://lkml.org/lkml/2013/5/31/210

CC: Linus Walleij <linus.walleij at linaro.org>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
---
 arch/arm/mach-omap2/omap_device.c |   40 +++++++++++++++++++++++++++++++------
 1 file changed, 34 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..4ebdbd7 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -39,6 +39,7 @@
 #include "soc.h"
 #include "omap_device.h"
 #include "omap_hwmod.h"
+#include "iomap.h"
 
 /* Private functions */
 
@@ -582,8 +583,10 @@ static int _od_runtime_suspend(struct device *dev)
 
 	ret = pm_generic_runtime_suspend(dev);
 
-	if (!ret)
+	if (!ret) {
 		omap_device_idle(pdev);
+		pinctrl_pm_select_idle_state(dev);
+	}
 
 	return ret;
 }
@@ -592,12 +595,25 @@ static int _od_runtime_resume(struct device *dev)
 {
 	struct platform_device *pdev = to_platform_device(dev);
 
+	pinctrl_pm_select_active_state(dev);
+
 	omap_device_enable(pdev);
 
 	return pm_generic_runtime_resume(dev);
 }
 #endif
 
+void _od_suspend_sel_pinctrl_state(struct device *dev)
+{
+	if (!dev->pins)
+		return;
+	/* try to select *deepest* pinctrl state */
+	if (IS_ERR(dev->pins->sleep_state))
+		pinctrl_pm_select_idle_state(dev);
+	else
+		pinctrl_pm_select_sleep_state(dev);
+}
+
 #ifdef CONFIG_SUSPEND
 static int _od_suspend_noirq(struct device *dev)
 {
@@ -610,11 +626,19 @@ static int _od_suspend_noirq(struct device *dev)
 		return 0;
 
 	ret = pm_generic_suspend_noirq(dev);
-
-	if (!ret && !pm_runtime_status_suspended(dev)) {
-		if (pm_generic_runtime_suspend(dev) == 0) {
-			omap_device_idle(pdev);
-			od->flags |= OMAP_DEVICE_SUSPENDED;
+	if (!ret) {
+		if (!pm_runtime_status_suspended(dev)) {
+			if (pm_generic_runtime_suspend(dev) == 0) {
+				omap_device_idle(pdev);
+				od->flags |= OMAP_DEVICE_SUSPENDED;
+				_od_suspend_sel_pinctrl_state(dev);
+			}
+		} else {
+			/*
+			 * "idle" pinctrl state already applied -
+			 * try to set "sleep" state
+			 */
+			pinctrl_pm_select_sleep_state(dev);
 		}
 	}
 
@@ -630,7 +654,11 @@ static int _od_resume_noirq(struct device *dev)
 	    !pm_runtime_status_suspended(dev)) {
 		od->flags &= ~OMAP_DEVICE_SUSPENDED;
 		omap_device_enable(pdev);
+		pinctrl_pm_select_active_state(dev);
 		pm_generic_runtime_resume(dev);
+	} else if (pm_runtime_status_suspended(dev)) {
+		/* switch back to "idle" pinctrl state */
+		pinctrl_pm_select_idle_state(dev);
 	}
 
 	return pm_generic_resume_noirq(dev);
-- 
1.7.9.5



From grygorii.strashko at ti.com  Wed Jul 17 07:41:50 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Wed, 17 Jul 2013 14:41:50 +0300
Subject: [PATCH 1/3] pinctrl: rollback check for !dev->pins in
 pinctrl_pm_select*() APIs
In-Reply-To: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
Message-ID: <1374061312-25469-2-git-send-email-grygorii.strashko@ti.com>

The pinctrl support in Device core assumed to be optional - so, It's
valid case, when there are no definition for default device's pinctrl
states in DT at all ("default", "active", "idle", "sleep").
And in this case dev->pins == NULL and pinctrl_pm_select*() API
should return 0 always.

Now the checks for !dev->pins have been removed from
pinctrl_pm_select*() API mistakenly by the patch
pinctrl: Remove duplicate code in pinctrl_pm_select_state functions
http://www.spinics.net/lists/arm-kernel/msg258829.html

Hence, rollback these checks in in pinctrl_pm_select*() APIs.

CC: Linus Walleij <linus.walleij at linaro.org>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
---
Seems this one can be squashed in series
[PATCH 0/4] improved support for runtime muxing for pinctrl"
http://www.spinics.net/lists/arm-kernel/msg258827.html

 drivers/pinctrl/core.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 4f58a97..ace4eb8 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1390,6 +1390,9 @@ static int pinctrl_pm_select_state(struct device *dev, struct pinctrl_state *sta
  */
 int pinctrl_pm_select_default_state(struct device *dev)
 {
+	if (!dev->pins)
+		return 0;
+
 	return pinctrl_pm_select_state(dev, dev->pins->default_state);
 }
 EXPORT_SYMBOL_GPL(pinctrl_pm_select_default_state);
@@ -1400,6 +1403,9 @@ EXPORT_SYMBOL_GPL(pinctrl_pm_select_default_state);
  */
 int pinctrl_pm_select_active_state(struct device *dev)
 {
+	if (!dev->pins)
+		return 0;
+
 	return pinctrl_pm_select_state(dev, dev->pins->active_state);
 }
 EXPORT_SYMBOL_GPL(pinctrl_pm_select_active_state);
@@ -1410,6 +1416,9 @@ EXPORT_SYMBOL_GPL(pinctrl_pm_select_active_state);
  */
 int pinctrl_pm_select_sleep_state(struct device *dev)
 {
+	if (!dev->pins)
+		return 0;
+
 	return pinctrl_pm_select_state(dev, dev->pins->sleep_state);
 }
 EXPORT_SYMBOL_GPL(pinctrl_pm_select_sleep_state);
@@ -1420,6 +1429,9 @@ EXPORT_SYMBOL_GPL(pinctrl_pm_select_sleep_state);
  */
 int pinctrl_pm_select_idle_state(struct device *dev)
 {
+	if (!dev->pins)
+		return 0;
+
 	return pinctrl_pm_select_state(dev, dev->pins->idle_state);
 }
 EXPORT_SYMBOL_GPL(pinctrl_pm_select_idle_state);
-- 
1.7.9.5



From grygorii.strashko at ti.com  Wed Jul 17 07:41:52 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Wed, 17 Jul 2013 14:41:52 +0300
Subject: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for uart3/4
In-Reply-To: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
Message-ID: <1374061312-25469-4-git-send-email-grygorii.strashko@ti.com>

Add dynamic "active"/"idle" pin states for uart3/4 which will be applied
when uart3/4 state is switched from active to idle and back by Runtime
PM or during system suspend.

CC: Benoit Cousson <benoit.cousson at linaro.org>
CC: Linus Walleij <linus.walleij at linaro.org>
CC: Stephen Warren <swarren at wwwdotorg.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
---
 arch/arm/boot/dts/omap4-sdp.dts |   34 ++++++++++++++++++++++++++++++----
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..2624504 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -181,18 +181,40 @@
 		pinctrl-single,pins = <
 			0x100 (PIN_INPUT_PULLUP | MUX_MODE0)	/* uart3_cts_rctx.uart3_cts_rctx */
 			0x102 (PIN_OUTPUT | MUX_MODE0)		/* uart3_rts_sd.uart3_rts_sd */
-			0x104 (PIN_INPUT | MUX_MODE0)		/* uart3_rx_irrx.uart3_rx_irrx */
 			0x106 (PIN_OUTPUT | MUX_MODE0)		/* uart3_tx_irtx.uart3_tx_irtx */
 		>;
 	};
 
+	uart3_pins_active: pinmux_uart3_pins_active {
+		pinctrl-single,pins = <
+			0x104 (PIN_INPUT | MUX_MODE0)		/* uart3_rx_irrx.uart3_rx_irrx */
+		>;
+	};
+
+	uart3_pins_idle: pinmux_uart3_pins_idle {
+		pinctrl-single,pins = <
+			0x104 (WAKEUP_EN | PIN_INPUT | MUX_MODE0)	/* uart3_rx_irrx.uart3_rx_irrx */
+		>;
+	};
+
 	uart4_pins: pinmux_uart4_pins {
 		pinctrl-single,pins = <
-			0x11c (PIN_INPUT | MUX_MODE0)		/* uart4_rx.uart4_rx */
 			0x11e (PIN_OUTPUT | MUX_MODE0)		/* uart4_tx.uart4_tx */
 		>;
 	};
 
+	uart4_pins_active: pinmux_uart4_pins_active {
+		pinctrl-single,pins = <
+			0x11c (PIN_INPUT | MUX_MODE0)		/* uart3_rx_irrx.uart3_rx_irrx */
+		>;
+	};
+
+	uart4_pins_idle: pinmux_uart4_pins_idle {
+		pinctrl-single,pins = <
+			0x11c (WAKEUP_EN | PIN_INPUT | MUX_MODE0)	/* uart3_rx_irrx.uart3_rx_irrx */
+		>;
+	};
+
 	twl6030_pins: pinmux_twl6030_pins {
 		pinctrl-single,pins = <
 			0x15e (WAKEUP_EN | PIN_INPUT_PULLUP | MUX_MODE0)	/* sys_nirq1.sys_nirq1 */
@@ -510,13 +532,17 @@
 };
 
 &uart3 {
-	pinctrl-names = "default";
+	pinctrl-names = "default", "active", "idle";
 	pinctrl-0 = <&uart3_pins>;
+	pinctrl-1 = <&uart3_pins_active>;
+	pinctrl-2 = <&uart3_pins_idle>;
 };
 
 &uart4 {
-	pinctrl-names = "default";
+	pinctrl-names = "default", "active", "idle";
 	pinctrl-0 = <&uart4_pins>;
+	pinctrl-1 = <&uart4_pins_active>;
+	pinctrl-2 = <&uart4_pins_idle>;
 };
 
 &mcbsp3 {
-- 
1.7.9.5



From maxime.ripard at free-electrons.com  Wed Jul 17 07:46:50 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 17 Jul 2013 13:46:50 +0200
Subject: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner's
 Security ID fuses
In-Reply-To: <20130716064107.GA10868@kroah.com>
References: <51C87DC7.50005@schinagl.nl> <20130624181509.GA8847@kroah.com>
 <51C8B84C.3020200@schinagl.nl> <20130624214615.GA17604@kroah.com>
 <51CAA709.4060801@schinagl.nl> <20130626175144.GC2222@kroah.com>
 <51D674BF.9030207@schinagl.nl> <20130706193646.GB9778@kroah.com>
 <51E466A3.4010503@schinagl.nl> <20130716064107.GA10868@kroah.com>
Message-ID: <20130717114650.GN3125@lukather>

On Mon, Jul 15, 2013 at 11:41:07PM -0700, Greg KH wrote:
> On Mon, Jul 15, 2013 at 11:16:19PM +0200, Oliver Schinagl wrote:
> > So using these new patches for binary attributes, how can I pass data 
> > between my driver and the sysfs files using a platform_driver? Or are 
> > other 'hacks' needed and using the .groups attribute from 
> > platform_driver->device_driver->groups is really the wrong approach.
> > 
> > I did ask around and still haven't figured it out so far, so I do 
> > apologize if you feel I'm wasting your precious time.
> 
> How is the platform device not the same thing that was passed to your
> probe function?

One thing I don't get here is why it should be set in the
platform_driver structure. From my understanding of the device model,
and since what Oliver is trying to do is exposing a few bytes of memory
to sysfs, shouldn't the sysfs file be attached to the device instead?

I mean, here, the sysfs file will be created under something like
.../drivers/sunxi-sid/eeprom. What happens when you have several
instances of that driver loaded? I'd expect it to have several sysfs
files created, one for each instance. So to me, it should be in the
device structure, not the driver one.

Couldn't that be also the reason of Oliver's NULL pointer? If the kobj
is attached to the platform_driver and not to the platform_device, it
should definitely get nasty when we try to cast it and retrieve data
from it (and that would match the different pointers stuff as well.)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130717/bc403ec4/attachment-0001.sig>

From mkl at pengutronix.de  Wed Jul 17 07:48:45 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Wed, 17 Jul 2013 13:48:45 +0200
Subject: BUG: commit "ARM: Remove __ARCH_WANT_INTERRUPTS_ON_CTXSW on
 pre-ARMv6 CPUs" breaks armv5 with CONFIG_PREEMPT
In-Reply-To: <20130717085139.GJ24642@n2100.arm.linux.org.uk>
References: <20130620095705.GA18536@arm.com> <51C2D5EF.3040803@pengutronix.de>
 <20130620102856.GC18536@arm.com> <20130620111255.GD18536@arm.com>
 <51C2E917.9000708@pengutronix.de> <51C2EA04.4060701@pengutronix.de>
 <51C2EBCD.4070206@pengutronix.de> <51C42AE0.9070506@pengutronix.de>
 <20130621135219.GC4099@arm.com> <51E658AF.1090009@pengutronix.de>
 <20130717085139.GJ24642@n2100.arm.linux.org.uk>
Message-ID: <51E6849D.7080505@pengutronix.de>

On 07/17/2013 10:51 AM, Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 10:41:19AM +0200, Marc Kleine-Budde wrote:
>> What happend to that patch? I cannot find it in v3.10.x nor in linus/master.
> 
> Catalin sent it to me, and I didn't apply it because it's still racy.
> 
> We have stateful context switches (due to cache clearing) and this does
> nothing to solve the problem there.  If we get preempted during the
> cache clearing, things will still go wrong.

Thanks for the update.

> See:
> 
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7771/1
> 
> I've no idea what's happening about this.  It looks to me like nothing
> happened after Catalin's last comment there.

Catalin, what's next?

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130717/e01fe949/attachment.sig>

From grygorii.strashko at ti.com  Wed Jul 17 07:49:55 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Wed, 17 Jul 2013 14:49:55 +0300
Subject: [PATCH 0/4] improved support for runtime muxing for pinctrl
In-Reply-To: <20130716090310.5541.36777.stgit@localhost>
References: <20130716090310.5541.36777.stgit@localhost>
Message-ID: <51E684E3.2040104@ti.com>

Hi Tony,

On 07/16/2013 12:05 PM, Tony Lindgren wrote:
> Hi all,
>
> As discussed earlier, the pinctrl support for changing some of the
> consumer device pins during runtime needs some improvment.
>
> Here are the patches to do that, I'll also post a minimal sample
> patch as a reply to this thread on how to do the muxing for
> runtime PM.

I've posted my patch and tested this patch series.
Seems everything is ok (except patch "pinctrl: Remove duplicate code in 
pinctrl_pm_select_state functions").
See http://www.spinics.net/lists/arm-kernel/msg259180.html

So,  Tested-By: Grygorii Strashko <grygorii.strashko at ti.com>

>
> Regards,
>
> Tony
>
> ---
>
> Tony Lindgren (4):
>        pinctrl: Remove duplicate code in pinctrl_pm_select_state functions
>        pinctrl: Allow pinctrl to have multiple active states
>        pinctrl: Add support for additional dynamic states
>        drivers: Add pinctrl handling for dynamic pin states
>
>
>   drivers/base/pinctrl.c                |   39 +++++
>   drivers/pinctrl/core.c                |  250 ++++++++++++++++++++++++++++-----
>   drivers/pinctrl/core.h                |   10 +
>   include/linux/pinctrl/consumer.h      |   46 ++++++
>   include/linux/pinctrl/devinfo.h       |    4 +
>   include/linux/pinctrl/pinctrl-state.h |   15 ++
>   6 files changed, 321 insertions(+), 43 deletions(-)
>

Regards,
-grygorii


From otavio at ossystems.com.br  Wed Jul 17 07:56:18 2013
From: otavio at ossystems.com.br (Otavio Salvador)
Date: Wed, 17 Jul 2013 08:56:18 -0300
Subject: [PATCH v2 1/4] ARM: dts: imx23-evk: enable USB PHY and controller
In-Reply-To: <20130717035010.GC4541@S2101-09.ap.freescale.net>
References: <1373979376-31583-1-git-send-email-otavio@ossystems.com.br>
 <20130717035010.GC4541@S2101-09.ap.freescale.net>
Message-ID: <CAP9ODKruGc+mOs3uvNzfCgPqnXgxqTJbaPXVRDFt9TwtnwumYQ@mail.gmail.com>

On Wed, Jul 17, 2013 at 12:50 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> On Tue, Jul 16, 2013 at 09:56:12AM -0300, Otavio Salvador wrote:
>> The i.MX23EVK board provides a USB port so the USB PHY and controller
>> need to be enabled for it to be usable.
>>
>> Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
>
> There is a typo i.XM23 in commit log of patch #2 and #3.  I fixed them
> up and applied all 3.

Thanks Shawn :)

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750


From rogerq at ti.com  Wed Jul 17 07:57:53 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 17 Jul 2013 14:57:53 +0300
Subject: [PATCH 0/3] ARM: OMAP2+: omap_device: add dynamic pinctrl handling
In-Reply-To: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
Message-ID: <51E686C1.8020801@ti.com>

Hi Grygorii,

On 07/17/2013 02:41 PM, Grygorii Strashko wrote:
> Hi Tony, Kevin
> 
> This patch series introduces dynamic pinctrl handling in OMAP device framework
> in the same way as it was before switching to DT. 
> This allow OMAP devices driver's developers to simply add dynamic pinctrl
> handling for "default", "active", "idle", "sleep" PIN states in their drivers
> by modifying DT definitions only - no modifications in drivers code are not needed.
> 

Overall I like the idea but can we make a provision for device drivers to override
this default pin state handling?

The OMAP EHCI driver is one such special case where the wakeup mechanism is tied to pinctrl states
as it uses IO daisy chaining to implement wakeup.
So depending on whether wakeup needs to be enabled or not I must be able to chose whether
I put the pin in just "sleep" state or "sleep with wakeup" state.

cheers,
-roger


From nsekhar at ti.com  Wed Jul 17 08:05:19 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 17 Jul 2013 17:35:19 +0530
Subject: [PATCH RFC v2 13/14] ARM: debug: move davinci debug to generic
 8250 code
In-Reply-To: <E1Uz8OD-00048N-Be@rmk-PC.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
 <E1Uz8OD-00048N-Be@rmk-PC.arm.linux.org.uk>
Message-ID: <51E6887F.3090808@ti.com>

On 7/16/2013 10:16 PM, Russell King wrote:
> Davinci's debugging is just a copy of the old 8250_32 code with a
> different base address.  Incorporate this into the generic 8250
> debug code.
> 
> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>

Tested on DA850 EVM

Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar


From gsi at denx.de  Wed Jul 17 08:07:42 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Wed, 17 Jul 2013 14:07:42 +0200
Subject: [PATCH v1 05/24] clk: wrap I/O access for improved portability
In-Reply-To: <20130715193829.GS14452@pengutronix.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1373914074-20889-6-git-send-email-gsi@denx.de>
 <20130715193829.GS14452@pengutronix.de>
Message-ID: <20130717120742.GM7080@book.gsilab.sittig.org>

On Mon, Jul 15, 2013 at 21:38 +0200, Sascha Hauer wrote:
> 
> On Mon, Jul 15, 2013 at 08:47:34PM +0200, Gerhard Sittig wrote:
> > diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> > index 6d55eb2..2c07061 100644
> > --- a/drivers/clk/clk-divider.c
> > +++ b/drivers/clk/clk-divider.c
> > @@ -104,7 +104,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
> >  	struct clk_divider *divider = to_clk_divider(hw);
> >  	unsigned int div, val;
> >  
> > -	val = readl(divider->reg) >> divider->shift;
> > +	val = clk_readl(divider->reg) >> divider->shift;
> >  	val &= div_mask(divider);
> 
> Would it be an option to use regmap for the generic dividers/muxes
> instead? This should be suitable for ppc and also for people who want to
> use the generic clocks on i2c devices.

Does regmap assume that those registers form a (dense) array of
equal sized items?  Does it introduce unconditional indirection
and requirement for explicit setup beyond mere mapping?  What's
the overhead compared to the readl/inbe32 approach that's
currently resolved at compile time?

Neither of the above needs to be a blocker, just needs to be
acceptable after consideration.  So far nobody appears to have
felt pain with the LE32 register assumption.


BTW does the common clock support that I introduce for MPC512x
only cover those parts from crystal over internal busses to
internal peripherals (register files).

It does not include bitrate generation within the peripherals --
this appears to remain the domain of individual drivers, which
keep manipulating register fields to derive wire bitrates from
internal references.  Sharing drivers between platforms with and
without common clock support forbids the switch anyway, or both
CCF abstraction as well as local register manipulation need to
get implemented in parallel, as I did for the mscan(4) driver.

Some of these bitrate related registers aren't 32bit entities and
thus could not get managed by the common clock primitives in
their current form.  Some of the IP blocks may even spread
integer values across several non-adjacent bit fields for legacy
reasons, but I guess that these aren't in the scope of the shared
primitives either (and they may not be popular either).


While we are at improvements for the common clock primitives:

What I missed was support for fractional dividers, i.e. dividers
with a register bitfield backed divider part but a fixed factor
multiplier part.  Currently there's only dividers (bitfield
factor or bitfield with table lookup for the factor) and
fixed-factor (multiplier and divider, but both of them fixed and
not adjustable by register manipulation).  This was addressed by
"intermediate" clock items ("ungated", "x4")


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


From broonie at kernel.org  Wed Jul 17 08:07:58 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Jul 2013 13:07:58 +0100
Subject: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them
In-Reply-To: <20130717112229.GK7080@book.gsilab.sittig.org>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1373914074-20889-2-git-send-email-gsi@denx.de>
 <20130715201734.GF11538@sirena.org.uk>
 <20130717112229.GK7080@book.gsilab.sittig.org>
Message-ID: <20130717120758.GR22506@sirena.org.uk>

On Wed, Jul 17, 2013 at 01:22:29PM +0200, Gerhard Sittig wrote:
> On Mon, Jul 15, 2013 at 21:17 +0100, Mark Brown wrote:
> > On Mon, Jul 15, 2013 at 08:47:30PM +0200, Gerhard Sittig wrote:

> > >   sprintf(name, "psc%d_mclk", master->bus_num);
> > >  	spiclk = clk_get(&master->dev, name);
> > > -	clk_enable(spiclk);
> > > +	clk_prepare_enable(spiclk);
> > >  	mps->mclk = clk_get_rate(spiclk);
> > >  	clk_put(spiclk);

> > This code is *clearly* buggy and should be fixed rather than papered
> > over.  Not only is there no matching put the driver is also dropping the
> > reference to the clock rather than holding on to it while it's in use.

> "This code" refers to the driver's original condition, right?  I
> agree that the driver has been suffering from incomplete clock
> handling since it was born three years ago.  And that this issue
> shall get addressed.  The question is just whether it needs to be
> part of this series which has a different focus.

This is a pretty long e-mail.  It'd probably have taken less time to
fix the issues than to reply to the e-mail...  but anyway.

A big part of the issue with the state of the driver is that there's
obvious clock API abuse going on that isn't corrected here - the main
one is that the sprintf() for the clock name is a fairly clear warning
sign, the driver should be using a fixed value there.  This raises a
warning flag for me about the quality of the common clock API
implementation that's being sent and/or the potential for bugs to be
noticed with the common clock framework.  I'd not expect this code to
actually work, and looking at the rest of the series I don't see how it
does since I can't see what forces the name.
-------------- 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/20130717/245057e2/attachment-0001.sig>

From daniel.lezcano at linaro.org  Wed Jul 17 08:13:58 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 17 Jul 2013 14:13:58 +0200
Subject: [PATCH v8] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <CACmBeS129VOmFjnF+-iRH1viS+zpoaNMYMaWZ_UiPVxa6ncYeQ@mail.gmail.com>
References: <1373024773-24574-1-git-send-email-jonas.jensen@gmail.com>
 <1373985880-23469-1-git-send-email-jonas.jensen@gmail.com>
 <51E56043.1010509@linaro.org>
 <CACmBeS129VOmFjnF+-iRH1viS+zpoaNMYMaWZ_UiPVxa6ncYeQ@mail.gmail.com>
Message-ID: <51E68A86.3020703@linaro.org>

On 07/17/2013 10:14 AM, Jonas Jensen wrote:
> On 16 July 2013 17:01, Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
>> 1. could you elaborate the patch log: as it is a new driver, a nice
>> description of the timer hardware would be valuable for people willing
>> to understand the code (eg. some specificities of the driver).
> 
> A short description is now added to the commit message, I hope this is
> what you wanted, I can reformat the text if needed.

It is ok. Thanks for the update.


>> 2. fix the alignment below
> 
> I don't see the alignment error, I think this is because git adds the
> one '+' character, it should be correct once applied?

Ok. I will check it.

Thanks
  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From grygorii.strashko at ti.com  Wed Jul 17 08:30:36 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Wed, 17 Jul 2013 15:30:36 +0300
Subject: [PATCH 0/3] ARM: OMAP2+: omap_device: add dynamic pinctrl handling
In-Reply-To: <51E686C1.8020801@ti.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
 <51E686C1.8020801@ti.com>
Message-ID: <51E68E6C.60100@ti.com>

On 07/17/2013 02:57 PM, Roger Quadros wrote:
> Hi Grygorii,
>
> On 07/17/2013 02:41 PM, Grygorii Strashko wrote:
>> Hi Tony, Kevin
>>
>> This patch series introduces dynamic pinctrl handling in OMAP device framework
>> in the same way as it was before switching to DT.
>> This allow OMAP devices driver's developers to simply add dynamic pinctrl
>> handling for "default", "active", "idle", "sleep" PIN states in their drivers
>> by modifying DT definitions only - no modifications in drivers code are not needed.
>>
>
> Overall I like the idea but can we make a provision for device drivers to override
> this default pin state handling?
>
> The OMAP EHCI driver is one such special case where the wakeup mechanism is tied to pinctrl states
> as it uses IO daisy chaining to implement wakeup.
> So depending on whether wakeup needs to be enabled or not I must be able to chose whether
> I put the pin in just "sleep" state or "sleep with wakeup" state.

I think, in this case you can't use default behavior and need to define
custom pins states like "sleep_wakeup"/"sleep_no_wakeup" and do not
define pins state with name "sleep', so Device core and OMAP device
framework will not touch your pins.

>
> cheers,
> -roger
>

Regards,
-grygorii


From nicolas.pitre at linaro.org  Wed Jul 17 08:33:02 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Jul 2013 08:33:02 -0400 (EDT)
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <1374052705.3146.86.camel@hornet>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374052705.3146.86.camel@hornet>
Message-ID: <alpine.LFD.2.03.1307170825240.14924@syhkavp.arg>

On Wed, 17 Jul 2013, Pawel Moll wrote:

> On Tue, 2013-07-16 at 17:05 +0100, Lorenzo Pieralisi wrote:
> > /drivers/mfd is probably not the right place for this code as it stands (but
> > probably will be when the entire driver, with DVFS and config interface, is
> > complete).
> 
> Not that it really matters now, but my vexpress-sysreg rework will -
> most likely - leave only skeleton in the MFD (registering mfd_cells) and
> other stuff is going to be spread all around. Then I'm planning to move
> the remaining of the vexpress-specific initialization to
> drivers/platform/arm/vexpress.c, so maybe sticking vexpress-spc.c to
> this (non-existing yet) directory would be the right thing to do?

I don't like this idea.  We worked hard to shrink platform specific 
directories such as arch/arm/mach-*/ as much as possible.  Simply moving 
stuff to drivers/platform/arm/* doesn't make the situation any much 
better.

If this is really miscelaneous code that really doesn't fit 
anywhere else, it should rather go into drivers/misc/ as a last resort.


Nicolas


From mpfj-list at newflow.co.uk  Wed Jul 17 08:08:02 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Wed, 17 Jul 2013 13:08:02 +0100
Subject: [PATCH v2] ARM: dts: add AM33XX MMC support
In-Reply-To: <1372303956-30208-1-git-send-email-joelf@ti.com>
References: <1372303956-30208-1-git-send-email-joelf@ti.com>
Message-ID: <51E68922.5020503@newflow.co.uk>

On 27/06/13 04:32, Joel Fernandes wrote:
> From: Matt Porter <mporter at ti.com>
> 
> Adds AM33XX MMC support for am335x-bone, am335x-evm, and am335x-evmsk.
> Also added is the DMA binding definitions based on the generic DMA
> request binding.
> 
> The HWMOD data removal was breaking MMC so some new properties like reg,
> interrupt etc were added.
> 
> Changes to DTS:
> Interrupt and reg added by: Joel Fernandes <joelf at ti.com>
> Compatible added by Balaji TK <balajitk at ti.com>
> ti,needs-special-hs-handling added by Gururaja Hebbar <gururaja.hebbar at ti.com>
> 
> Signed-off-by: Matt Porter <mporter at ti.com>
> Acked-by: Tony Lindgren <tony at atomide.com>
> Signed-off-by: Joel Fernandes <joelf at ti.com>
> ---
>  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   26 +++++++++++++-
>  arch/arm/boot/dts/am335x-bone.dts                  |    7 ++++
>  arch/arm/boot/dts/am335x-evm.dts                   |    7 ++++
>  arch/arm/boot/dts/am335x-evmsk.dts                 |    7 ++++
>  arch/arm/boot/dts/am33xx.dtsi                      |   38 ++++++++++++++++++++
>  5 files changed, 84 insertions(+), 1 deletion(-)

Excuse my ignorance, but which git repository is this against ?



From 21cnbao at gmail.com  Wed Jul 17 08:41:37 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Wed, 17 Jul 2013 20:41:37 +0800
Subject: [PATCH] rtc: SiRF: fix kernel warning during wakeup
Message-ID: <1374064897-29134-1-git-send-email-Baohua.Song@csr.com>

From: Xianglong Du <Xianglong.Du at csr.com>

enable_irq_wake() might fail, if so, we will see kernel warning in resume entries
due to it always calls disable_irq_wake().

[  200.659501] ------------[ cut here ]------------
[  200.661292] WARNING: at /home/ASIA/xd01/temp/atlas6-3.x/kernel/kernel/irq/manage.c:529 irq_set_irq_wake+0xc4/0xf0()
[  200.671686] Unbalanced IRQ 52 wake disable
[  200.675764] Modules linked in: ipv6 libcomposite configfs
[  200.681153] CPU: 0 PID: 1591 Comm: ash Tainted: G        W    3.10.0-00854-gdbd86d4-dirty #100
[  200.689761] [<c0014e28>] (unwind_backtrace+0x0/0xf8) from [<c0011ef4>] (show_stack+0x10/0x14)
[  200.698263] [<c0011ef4>] (show_stack+0x10/0x14) from [<c001fee4>] (warn_slowpath_common+0x54/0x68)
[  200.707198] [<c001fee4>] (warn_slowpath_common+0x54/0x68) from [<c001ff8c>] (warn_slowpath_fmt+0x30/0x40)
[  200.716749] [<c001ff8c>] (warn_slowpath_fmt+0x30/0x40) from [<c0074588>] (irq_set_irq_wake+0xc4/0xf0)
[  200.725951] [<c0074588>] (irq_set_irq_wake+0xc4/0xf0) from [<c027b31c>] (sirfsoc_rtc_restore+0x30/0x38)
[  200.735325] [<c027b31c>] (sirfsoc_rtc_restore+0x30/0x38) from [<c0211c0c>] (platform_pm_restore+0x2c/0x50)
[  200.744959] [<c0211c0c>] (platform_pm_restore+0x2c/0x50) from [<c02163e4>] (dpm_run_callback.clone.6+0x30/0xb0)
[  200.755024] [<c02163e4>] (dpm_run_callback.clone.6+0x30/0xb0) from [<c02169d0>] (device_resume+0x88/0x134)
[  200.764657] [<c02169d0>] (device_resume+0x88/0x134) from [<c0217698>] (dpm_resume+0x114/0x230)
[  200.773253] [<c0217698>] (dpm_resume+0x114/0x230) from [<c0057118>] (hibernation_snapshot+0x178/0x1d0)
[  200.782540] [<c0057118>] (hibernation_snapshot+0x178/0x1d0) from [<c0057820>] (hibernate+0x130/0x1dc)
[  200.791739] [<c0057820>] (hibernate+0x130/0x1dc) from [<c00556cc>] (state_store+0xb4/0xc0)
[  200.799990] [<c00556cc>] (state_store+0xb4/0xc0) from [<c019af68>] (kobj_attr_store+0x14/0x20)
[  200.808585] [<c019af68>] (kobj_attr_store+0x14/0x20) from [<c011b268>] (sysfs_write_file+0xfc/0x17c)
[  200.817696] [<c011b268>] (sysfs_write_file+0xfc/0x17c) from [<c00c4da8>] (vfs_write+0xc8/0x194)
[  200.826372] [<c00c4da8>] (vfs_write+0xc8/0x194) from [<c00c515c>] (SyS_write+0x40/0x6c)
[  200.834362] [<c00c515c>] (SyS_write+0x40/0x6c) from [<c000e280>] (ret_fast_syscall+0x0/0x30)
[  200.842771] ---[ end trace 10f52d38a3bc59c7 ]---

To avoid unbalanced "IRQ wake disable", ensure that disable_irq_wake() is called only when
enable_irq_wake() have been successfully enabled.

Signed-off-by: Xianglong Du <Xianglong.Du at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 drivers/rtc/rtc-sirfsoc.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-sirfsoc.c b/drivers/rtc/rtc-sirfsoc.c
index aa7ed4b..63460cf 100644
--- a/drivers/rtc/rtc-sirfsoc.c
+++ b/drivers/rtc/rtc-sirfsoc.c
@@ -44,6 +44,7 @@ struct sirfsoc_rtc_drv {
 	struct rtc_device	*rtc;
 	u32			rtc_base;
 	u32			irq;
+	unsigned		irq_wake;
 	/* Overflow for every 8 years extra time */
 	u32			overflow_rtc;
 #ifdef CONFIG_PM
@@ -355,8 +356,8 @@ static int sirfsoc_rtc_suspend(struct device *dev)
 	rtcdrv->saved_counter =
 		sirfsoc_rtc_iobrg_readl(rtcdrv->rtc_base + RTC_CN);
 	rtcdrv->saved_overflow_rtc = rtcdrv->overflow_rtc;
-	if (device_may_wakeup(&pdev->dev))
-		enable_irq_wake(rtcdrv->irq);
+	if (device_may_wakeup(&pdev->dev) && !enable_irq_wake(rtcdrv->irq))
+		rtcdrv->irq_wake = 1;
 
 	return 0;
 }
@@ -423,8 +424,10 @@ static int sirfsoc_rtc_resume(struct device *dev)
 	struct platform_device *pdev = to_platform_device(dev);
 	struct sirfsoc_rtc_drv *rtcdrv = platform_get_drvdata(pdev);
 	sirfsoc_rtc_thaw(dev);
-	if (device_may_wakeup(&pdev->dev))
+	if (device_may_wakeup(&pdev->dev) && rtcdrv->irq_wake) {
 		disable_irq_wake(rtcdrv->irq);
+		rtcdrv->irq_wake = 0;
+	}
 
 	return 0;
 }
@@ -434,8 +437,10 @@ static int sirfsoc_rtc_restore(struct device *dev)
 	struct platform_device *pdev = to_platform_device(dev);
 	struct sirfsoc_rtc_drv *rtcdrv = platform_get_drvdata(pdev);
 
-	if (device_may_wakeup(&pdev->dev))
+	if (device_may_wakeup(&pdev->dev) && rtcdrv->irq_wake) {
 		disable_irq_wake(rtcdrv->irq);
+		rtcdrv->irq_wake = 0;
+	}
 	return 0;
 }
 
-- 
1.8.2.3



From jonas.jensen at gmail.com  Wed Jul 17 08:51:42 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 17 Jul 2013 14:51:42 +0200
Subject: [PATCH v2] mmc: sdhci-moxart: Add MOXA ART SDHCI driver
In-Reply-To: <1373448533-9401-1-git-send-email-jonas.jensen@gmail.com>
References: <1373448533-9401-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1374065502-27110-1-git-send-email-jonas.jensen@gmail.com>

Add SDHCI driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v1:
    
    1. remove IRQF_DISABLED
    2. use devm_request_irq, remove free_irq
    3. remove unnecessary dev_set_drvdata in moxart_remove
    4. add devicetree bindings document
    5. use BIT macro in header file
    
    Applies to next-20130716

 .../devicetree/bindings/mmc/moxa,moxart-mmc.txt    |  17 +
 drivers/mmc/host/Kconfig                           |   9 +
 drivers/mmc/host/Makefile                          |   1 +
 drivers/mmc/host/sdhci-moxart.c                    | 780 +++++++++++++++++++++
 drivers/mmc/host/sdhci-moxart.h                    | 155 ++++
 5 files changed, 962 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt
 create mode 100644 drivers/mmc/host/sdhci-moxart.c
 create mode 100644 drivers/mmc/host/sdhci-moxart.h

diff --git a/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt b/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt
new file mode 100644
index 0000000..9ec8650
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt
@@ -0,0 +1,17 @@
+MOXA ART SD Host Controller Interface
+
+Required properties:
+
+- compatible : Should be "moxa,moxart-mmc"
+- reg : Should contain registers location and length
+- interrupts : Should contain the interrupt number
+- clocks : Should contain phandle for APB clock "clkapb"
+
+Example:
+
+	mmc: mmc at 98e00000 {
+		compatible = "moxa,moxart-mmc";
+		reg = <0x98e00000 0x5C>;
+		interrupts = <5 0>;
+		clocks = <&clkapb>;
+	};
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8a4c066..3c246390 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -271,6 +271,15 @@ config MMC_SDHCI_BCM2835
 
 	  If unsure, say N.
 
+config MMC_SDHCI_MOXART
+	tristate "MOXART SD Host Controller Interface support"
+	depends on ARCH_MOXART && MMC
+	help
+	  This selects the MOXART SD Host Controller Interface.
+	  MOXA provides one multi-functional card reader which can
+	  be found on some embedded hardware such as UC-7112-LX.
+	  If you have a controller with this interface, say Y here.
+
 config MMC_OMAP
 	tristate "TI OMAP Multimedia Card Interface support"
 	depends on ARCH_OMAP
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index d422e21..c91317f 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_MMC_SDHCI_OF_ESDHC)	+= sdhci-of-esdhc.o
 obj-$(CONFIG_MMC_SDHCI_OF_HLWD)		+= sdhci-of-hlwd.o
 obj-$(CONFIG_MMC_SDHCI_BCM_KONA)	+= sdhci-bcm-kona.o
 obj-$(CONFIG_MMC_SDHCI_BCM2835)		+= sdhci-bcm2835.o
+obj-$(CONFIG_MMC_SDHCI_MOXART)		+= sdhci-moxart.o
 
 ifeq ($(CONFIG_CB710_DEBUG),y)
 	CFLAGS-cb710-mmc	+= -DDEBUG
diff --git a/drivers/mmc/host/sdhci-moxart.c b/drivers/mmc/host/sdhci-moxart.c
new file mode 100644
index 0000000..9d809b5
--- /dev/null
+++ b/drivers/mmc/host/sdhci-moxart.c
@@ -0,0 +1,780 @@
+/*
+ * MOXA ART MMC host driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/blkdev.h>
+#include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
+#include <linux/mmc/host.h>
+#include <linux/mmc/sd.h>
+#include <linux/mmc/mmc.h>
+#include <linux/sched.h>
+#include <linux/io.h>
+#include <linux/gpio.h>
+#include <linux/sizes.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/clk.h>
+
+#include <asm/dma.h>
+#include <asm/irq.h>
+
+#include "sdhci-moxart.h"
+
+#define DMA_FIFO_LEN_FORCE		0
+#define APB_DMA_SD_REQ_NO		5
+#define MIN_POWER (MMC_VDD_360 - MSD_SD_POWER_MASK)
+
+static inline void moxart_init_sg(struct moxart_host *host,
+				  struct mmc_data *data)
+{
+	host->cur_sg = data->sg;
+	host->num_sg = data->sg_len;
+	host->remain = host->cur_sg->length;
+
+	if (host->remain > host->size)
+		host->remain = host->size;
+
+	data->error = MMC_ERR_NONE;
+}
+
+static inline int moxart_next_sg(struct moxart_host *host)
+{
+	int remain;
+	struct mmc_data *data = host->mrq->cmd->data;
+
+	host->cur_sg++;
+	host->num_sg--;
+
+	if (host->num_sg > 0) {
+		host->remain = host->cur_sg->length;
+		remain = host->size - data->bytes_xfered;
+		if (remain > 0 && remain < host->remain)
+			host->remain = remain;
+	}
+
+	return host->num_sg;
+}
+
+static void moxart_send_command(struct moxart_host *host,
+	struct mmc_command *cmd)
+{
+	unsigned int status, cmdctrl;
+	int retry = 0;
+
+	dev_dbg(mmc_dev(host->mmc), "%s: cmd->opcode=%d\n",
+		__func__, cmd->opcode);
+
+	cmd->error = MMC_ERR_TIMEOUT;
+
+	writel(MSD_RSP_TIMEOUT | MSD_RSP_CRC_OK |
+	       MSD_RSP_CRC_FAIL | MSD_CMD_SENT, &host->reg->clear);
+	writel(cmd->arg, &host->reg->argument);
+
+	cmdctrl = cmd->opcode & MSD_CMD_IDX_MASK;
+	if (cmdctrl == SD_APP_SET_BUS_WIDTH || cmdctrl == SD_APP_OP_COND ||
+	    cmdctrl == SD_APP_SEND_SCR || cmdctrl == SD_APP_SD_STATUS ||
+	    cmdctrl == SD_APP_SEND_NUM_WR_BLKS)
+		cmdctrl |= MSD_APP_CMD;
+
+	if (cmd->flags & MMC_RSP_136)
+		cmdctrl |= (MSD_LONG_RSP | MSD_NEED_RSP);
+	else
+		cmdctrl |= MSD_NEED_RSP;
+
+	writel(cmdctrl | MSD_CMD_EN, &host->reg->command);
+
+	while (retry++ < MSD_RETRY_COUNT) {
+		udelay(10);
+		status = readl(&host->reg->status);
+		if (status & MSD_CARD_DETECT) {
+			dev_dbg(mmc_dev(host->mmc), "%s: MSD_CARD_DETECT\n",
+				__func__);
+			cmd->error = MMC_ERR_TIMEOUT;
+			break;
+		}
+		if (cmdctrl & MSD_NEED_RSP) {
+			dev_dbg(mmc_dev(host->mmc), "%s: MSD_NEED_RSP\n",
+				__func__);
+			if (status & MSD_RSP_TIMEOUT) {
+				dev_dbg(mmc_dev(host->mmc), "%s: MSD_RSP_TIMEOUT\n",
+					__func__);
+				writel(MSD_RSP_TIMEOUT, &host->reg->clear);
+				cmd->error = MMC_ERR_TIMEOUT;
+				break;
+			}
+			if ((cmd->flags & MMC_RSP_CRC) &&
+				(status & MSD_RSP_CRC_FAIL)) {
+				dev_dbg(mmc_dev(host->mmc), "%s: MSD_RSP_CRC_FAIL\n",
+					__func__);
+				writel(MSD_RSP_CRC_FAIL, &host->reg->clear);
+				cmd->error = MMC_ERR_BADCRC;
+				break;
+			}
+			if (status & MSD_RSP_CRC_OK) {
+				dev_dbg(mmc_dev(host->mmc), "%s: MSD_RSP_CRC_OK\n",
+					__func__);
+				writel(MSD_RSP_CRC_OK, &host->reg->clear);
+
+				if (cmd->flags & MMC_RSP_136) {
+					cmd->resp[3] =
+						readl(&host->reg->response0);
+					cmd->resp[2] =
+						readl(&host->reg->response1);
+					cmd->resp[1] =
+						readl(&host->reg->response2);
+					cmd->resp[0] =
+						readl(&host->reg->response3);
+				} else {
+					cmd->resp[0] =
+						readl(&host->reg->response0);
+				}
+
+				cmd->error = MMC_ERR_NONE;
+				break;
+			}
+		} else {
+			dev_dbg(mmc_dev(host->mmc), "%s: !(cmdctrl & MSD_NEED_RSP)\n",
+				__func__);
+			if (status & MSD_CMD_SENT) {
+				writel(MSD_CMD_SENT, &host->reg->clear);
+				cmd->error = MMC_ERR_NONE;
+				break;
+			}
+		}
+	}
+
+	if (retry >= (MSD_RETRY_COUNT - 1)) {
+		/*
+		 * this seems to happen a lot on or after CMD25
+		 * (MMC_WRITE_MULTIPLE_BLOCK) with more than 4 blocks
+		 * (>4096), possibly because the transfer is too big
+		 * or takes too long to complete.
+		 * when this happens the controller is usually rendered
+		 * unresponsive and can only be recovered with reboot.
+		 */
+		dev_dbg(mmc_dev(host->mmc), "%s: WARNING! no valid status found!\n",
+			__func__);
+	}
+}
+
+static void moxart_dma_complete(void *param)
+{
+	struct moxart_host *host = param;
+
+	dev_dbg(mmc_dev(host->mmc), "%s: host=%p\n", __func__, host);
+	complete(&host->dma_complete);
+}
+
+static void moxart_transfer_dma(struct mmc_data *data, struct moxart_host *host)
+{
+	unsigned int len, direction_dev;
+	struct dma_async_tx_descriptor *desc = NULL;
+
+	if (host->size == data->bytes_xfered)
+		return;
+
+	direction_dev = (data->flags & MMC_DATA_WRITE) ?
+			DMA_MEM_TO_DEV : DMA_DEV_TO_MEM;
+
+	/*
+	 * because dma_map_sg takes both sg and sg_len as arguments
+	 * (and maps the entire list of buffers) data->sg does not
+	 * have to be incremented between calls (as is required
+	 * in moxart_transfer_pio)
+	 */
+	len = dma_map_sg(host->dma_chan_cur->device->dev, data->sg,
+			 data->sg_len, host->dma_direction);
+
+	if (len > 0) {
+		/* host->dma_active = true;*/
+		desc = dmaengine_prep_slave_sg(host->dma_chan_cur, data->sg,
+					       len, direction_dev,
+					       DMA_PREP_INTERRUPT |
+					       DMA_CTRL_ACK);
+	} else {
+		pr_err("%s: dma_map_sg returned zero length\n",
+			__func__);
+	}
+
+	if (desc) {
+		desc->callback = moxart_dma_complete;
+		desc->callback_param = host;
+		dmaengine_submit(desc);
+		dma_async_issue_pending(host->dma_chan_cur);
+	}
+
+	data->bytes_xfered += host->remain;
+}
+
+/* when DMA is available this is used only for SD_APP_SEND_SCR */
+static void moxart_transfer_pio(struct moxart_host *host)
+{
+	unsigned char *buffer;
+	unsigned int wcnt, i;
+	struct mmc_data *data = host->mrq->cmd->data;
+
+	if (host->size == data->bytes_xfered)
+		goto transfer_complete;
+
+	buffer = sg_virt(host->cur_sg);
+	wcnt = host->remain >> 2;
+
+	if (data->flags & MMC_DATA_WRITE) {
+		for (i = 0; i < wcnt; i++, buffer += 4) {
+			writel(*(unsigned int *)buffer,
+			       &host->reg->data_window);
+			udelay(10);
+		}
+	} else {
+		for (i = 0; i < wcnt; i++, buffer += 4) {
+			/* byte order reversed only when reading SCR */
+			if (data->mrq->cmd->opcode == SD_APP_SEND_SCR) {
+				*(unsigned int *)buffer = ioread32be(
+					&host->reg->data_window);
+			} else {
+				*(unsigned int *)buffer =
+					readl(&host->reg->data_window);
+			}
+			udelay(10);
+		}
+	}
+	wcnt <<= 2;
+	host->remain -= wcnt;
+	data->bytes_xfered += wcnt;
+
+	if (host->size != data->bytes_xfered) {
+		moxart_next_sg(host);
+		/*
+		 * used to goto "transfer_start" label here,
+		 * there is no need, this function will be
+		 * called again from interrupt.
+		 *
+		 * compare with DMA where sg increment is
+		 * redundant thanks to dma_map_sg
+		 */
+	} else {
+		complete(&host->pio_complete);
+	}
+
+transfer_complete:
+	dev_dbg(mmc_dev(host->mmc), "%s: host->size=%d host->remain=%u\n",
+		__func__, host->size, host->remain);
+}
+
+static void moxart_prepare_data(struct moxart_host *host)
+{
+	struct mmc_data *data = host->mrq->cmd->data;
+	unsigned int timeout, datactrl;
+	int blksz_bits;
+
+	dev_dbg(mmc_dev(host->mmc), "%s\n", __func__);
+
+	if (!data)
+		return;
+
+	host->size = data->blocks * data->blksz;
+	blksz_bits = ffs(data->blksz) - 1;
+	BUG_ON(1 << blksz_bits != data->blksz);
+
+	moxart_init_sg(host, data);
+
+	timeout = (host->mmc->f_max / 1000) * (data->timeout_ns / 1000);
+	timeout *= 2;
+
+	datactrl = (blksz_bits & MSD_BLK_SIZE_MASK) | MSD_DATA_EN;
+
+	if (data->flags & MMC_DATA_WRITE)
+		datactrl |= MSD_DATA_WRITE;
+
+	if (((host->size > MSD_FIFO_LENB) || DMA_FIFO_LEN_FORCE)
+	    && host->have_dma) {
+		datactrl |= MSD_DMA_EN;
+	}
+
+	dev_dbg(mmc_dev(host->mmc), "%s: blocks=%d blksz=%d datactrl=0x%08x\n",
+		__func__, data->blocks,	data->blksz, datactrl);
+	dev_dbg(mmc_dev(host->mmc), "%s: timeout=%u timeout_ns=%u\n",
+		__func__, timeout, data->timeout_ns);
+
+	writel(timeout, &host->reg->data_timer);
+	writel(host->size, &host->reg->data_length);
+	writel(datactrl, &host->reg->data_control);
+}
+
+static void moxart_transfer_check(struct mmc_data *data,
+				  struct moxart_host *host)
+{
+	unsigned int status, count = 0;
+
+	dev_dbg(mmc_dev(host->mmc), "%s\n", __func__);
+
+	while (1) {
+		udelay(10);
+		status = readl(&host->reg->status);
+		if (status & (MSD_DATA_CRC_OK | MSD_DATA_CRC_FAIL
+			| MSD_DATA_END)	|| count > 10)
+			break;
+		dev_dbg(mmc_dev(host->mmc), "%s: waiting for status=%08x ..\n",
+			__func__, status);
+		count++;
+	}
+	if (status & MSD_DATA_CRC_OK) {
+		dev_dbg(mmc_dev(host->mmc), "%s: MSD_DATA_CRC_OK\n", __func__);
+		writel(MSD_DATA_CRC_OK, &host->reg->clear);
+	}
+	if (status & MSD_DATA_CRC_FAIL) {
+		dev_dbg(mmc_dev(host->mmc), "%s: MSD_DATA_CRC_FAIL\n",
+			__func__);
+		writel(MSD_DATA_CRC_FAIL, &host->reg->clear);
+		data->error = MMC_ERR_TIMEOUT;
+	}
+	if (status & MSD_DATA_END) {
+		dev_dbg(mmc_dev(host->mmc), "%s: MSD_DATA_END\n",
+			__func__);
+		writel(MSD_DATA_END, &host->reg->clear);
+	}
+	if (status & MSD_DATA_TIMEOUT) {
+		dev_dbg(mmc_dev(host->mmc), "%s: MSD_DATA_TIMEOUT\n",
+			__func__);
+		writel(MSD_DATA_TIMEOUT, &host->reg->clear);
+	}
+}
+
+static void moxart_card_change(struct moxart_host *host)
+{
+	int delay;
+	unsigned long flags;
+
+	spin_lock_irqsave(&host->lock, flags);
+
+	if (readl(&host->reg->status) & MSD_CARD_DETECT) {
+		dev_dbg(mmc_dev(host->mmc), "%s: card removed\n", __func__);
+		if (host->have_dma && host->size > MSD_FIFO_LENB) {
+			dev_dbg(mmc_dev(host->mmc), "%s: call dmaengine_terminate_all\n",
+				__func__);
+			dmaengine_terminate_all(host->dma_chan_rx);
+			dmaengine_terminate_all(host->dma_chan_tx);
+		}
+		host->removed = true;
+		delay = 0;
+	} else {
+		dev_dbg(mmc_dev(host->mmc), "%s: card inserted\n", __func__);
+		host->removed = false;
+		delay = 500;
+	}
+
+	/*
+	 * clearing FIFO interrupts here does not stop a follow up
+	 * MSD_FIFO_*RUN after MSD_CARD_CHANGE. instead, check
+	 * host->mrq != NULL in moxart_irq to avoid unnecessary calls
+	 * to moxart_transfer_pio
+	 * if this happens during transfer the mmc_request in
+	 * moxart_request should still be valid
+	 * (which is why host->mrq can be set NULL here)
+	 */
+	host->mrq = NULL;
+	writel(MSD_CARD_CHANGE | MSD_FIFO_ORUN | MSD_FIFO_URUN,
+	       &host->reg->clear);
+	writel(MSD_CARD_CHANGE, &host->reg->interrupt_mask);
+
+	spin_unlock_irqrestore(&host->lock, flags);
+	dev_dbg(mmc_dev(host->mmc), "%s: call mmc_detect_change\n", __func__);
+	mmc_detect_change(host->mmc, msecs_to_jiffies(delay));
+}
+
+static void moxart_request(struct mmc_host *mmc, struct mmc_request *mrq)
+{
+	struct moxart_host *host = mmc_priv(mmc);
+	unsigned long dma_time, pio_time, flags;
+	unsigned int status;
+
+	dev_dbg(mmc_dev(host->mmc), "%s\n", __func__);
+
+	spin_lock_irqsave(&host->lock, flags);
+
+	init_completion(&host->dma_complete);
+	init_completion(&host->pio_complete);
+
+	host->mrq = mrq;
+
+	if (readl(&host->reg->status) & MSD_CARD_DETECT) {
+		mrq->cmd->error = MMC_ERR_TIMEOUT;
+		goto request_done;
+	}
+
+	moxart_prepare_data(host);
+	moxart_send_command(host, host->mrq->cmd);
+
+	if (mrq->cmd->data) {
+		/* only use DMA/PIO (and wait) when there is data */
+		if (((host->size > MSD_FIFO_LENB) || DMA_FIFO_LEN_FORCE)
+			&& host->have_dma) {
+
+			writel(MSD_CARD_CHANGE, &host->reg->interrupt_mask);
+
+			spin_unlock_irqrestore(&host->lock, flags);
+
+			host->dma_direction = (mrq->cmd->data->flags
+					      & MMC_DATA_WRITE) ?
+					      DMA_TO_DEVICE : DMA_FROM_DEVICE;
+			host->dma_chan_cur = (mrq->cmd->data->flags
+					     & MMC_DATA_WRITE) ?
+					     host->dma_chan_tx :
+					     host->dma_chan_rx;
+			moxart_transfer_dma(mrq->cmd->data, host);
+
+			dma_time = wait_for_completion_interruptible_timeout(
+				   &host->dma_complete, host->timeout);
+			dev_dbg(mmc_dev(host->mmc), "%s: dma_time=%lu (DMA wait time)\n",
+				__func__, dma_time);
+
+			dma_unmap_sg(host->dma_chan_cur->device->dev,
+				     mrq->cmd->data->sg, mrq->cmd->data->sg_len,
+				     host->dma_direction);
+
+			spin_lock_irqsave(&host->lock, flags);
+		} else {
+
+			writel(MSD_FIFO_URUN | MSD_FIFO_ORUN | MSD_CARD_CHANGE,
+			       &host->reg->interrupt_mask);
+
+			status = readl(&host->reg->status);
+			dev_dbg(mmc_dev(host->mmc), "%s: status=%08x\n",
+				__func__, status);
+
+			spin_unlock_irqrestore(&host->lock, flags);
+
+			/* PIO transfer started from interrupt */
+			pio_time = wait_for_completion_interruptible_timeout(
+				   &host->pio_complete, host->timeout);
+			dev_dbg(mmc_dev(host->mmc), "%s: pio_time=%lu (PIO wait time)\n",
+				__func__, pio_time);
+
+			spin_lock_irqsave(&host->lock, flags);
+		}
+
+		/* removed during transfer? (interrupts were just enabled..) */
+		if (host->removed) {
+			dev_dbg(mmc_dev(host->mmc), "%s: host removed during transfer!\n",
+				__func__);
+			mrq->cmd->error = MMC_ERR_TIMEOUT;
+		}
+
+		moxart_transfer_check(mrq->cmd->data, host);
+
+		if (mrq->cmd->data->stop)
+			moxart_send_command(host, mrq->cmd->data->stop);
+	}
+
+request_done:
+	spin_unlock_irqrestore(&host->lock, flags);
+	mmc_request_done(host->mmc, mrq);
+}
+
+static irqreturn_t moxart_irq(int irq, void *devid)
+{
+	struct moxart_host *host = (struct moxart_host *)devid;
+	unsigned int status;
+	unsigned long flags;
+
+	status = readl(&host->reg->status);
+
+	dev_dbg(mmc_dev(host->mmc), "%s: host=%p status=%08x\n",
+		__func__, host, status);
+
+	if (status & MSD_CARD_CHANGE) {
+		dev_dbg(mmc_dev(host->mmc), "%s: call moxart_card_change\n",
+			__func__);
+		moxart_card_change(host);
+	}
+	if (status & (MSD_FIFO_ORUN | MSD_FIFO_URUN) && host->mrq) {
+		writel(status & (MSD_FIFO_ORUN | MSD_FIFO_URUN),
+		       &host->reg->clear);
+		dev_dbg(mmc_dev(host->mmc), "%s: call moxart_transfer_pio\n",
+			__func__);
+		spin_lock_irqsave(&host->lock, flags);
+		moxart_transfer_pio(host);
+		spin_unlock_irqrestore(&host->lock, flags);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static void moxart_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
+{
+	struct moxart_host *host = mmc_priv(mmc);
+	unsigned long flags;
+	unsigned short power;
+	int div;
+
+	spin_lock_irqsave(&host->lock, flags);
+	if (ios->clock) {
+		div = (host->sysclk / (host->mmc->f_max * 2)) - 1;
+
+		if (div > MSD_CLK_DIV_MASK)
+			div = MSD_CLK_DIV_MASK;
+		else if (div < 0)
+			div = 0;
+
+		div |= MSD_CLK_SD;
+		writel(div, &host->reg->clock_control);
+	} else if (!(readl(&host->reg->clock_control) & MSD_CLK_DIS)) {
+		writel(readl(&host->reg->clock_control) | MSD_CLK_DIS,
+		       &host->reg->clock_control);
+	}
+
+	if (ios->power_mode == MMC_POWER_OFF) {
+		writel(readl(&host->reg->power_control) & ~MSD_SD_POWER_ON,
+		       &host->reg->power_control);
+	} else {
+		if (ios->vdd < MIN_POWER)
+			power = 0;
+		else
+			power = ios->vdd - MIN_POWER;
+
+		writel(MSD_SD_POWER_ON | (unsigned int) power,
+		       &host->reg->power_control);
+	}
+
+	if (ios->bus_width == MMC_BUS_WIDTH_1)
+		writel(MSD_SINGLE_BUS, &host->reg->bus_width);
+	else
+		writel(MSD_WIDE_BUS, &host->reg->bus_width);
+
+	spin_unlock_irqrestore(&host->lock, flags);
+}
+
+
+static int moxart_get_ro(struct mmc_host *mmc)
+{
+	int ret;
+	struct moxart_host *host = mmc_priv(mmc);
+
+	(readl(&host->reg->status) & MSD_WRITE_PROT) ? (ret = 1) : (ret = 0);
+	return ret;
+}
+
+static struct mmc_host_ops moxart_ops = {
+	.request = moxart_request,
+	.set_ios = moxart_set_ios,
+	.get_ro = moxart_get_ro,
+};
+
+static int moxart_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct resource res_mmc;
+	struct mmc_host *mmc;
+	struct moxart_host *host = NULL;
+	void __iomem *reg_mmc;
+	dma_cap_mask_t mask;
+	int ret;
+	struct dma_slave_config cfg;
+	unsigned int irq;
+	struct clk *clk;
+	unsigned int dma_chan_rx_req = 1;
+	unsigned int dma_chan_tx_req = 0;
+
+	mmc = mmc_alloc_host(sizeof(struct moxart_host), dev);
+	if (!mmc) {
+		dev_err(dev, "%s: mmc_alloc_host failed\n", __func__);
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	ret = of_address_to_resource(node, 0, &res_mmc);
+	if (ret) {
+		dev_err(dev, "%s: could not get MMC base resource\n", __func__);
+		goto out;
+	}
+
+	irq = irq_of_parse_and_map(node, 0);
+
+	reg_mmc = devm_ioremap_resource(dev, &res_mmc);
+	if (IS_ERR(reg_mmc)) {
+		dev_err(dev, "%s: devm_ioremap_resource res_mmc failed\n",
+			__func__);
+		return PTR_ERR(reg_mmc);
+	}
+
+	mmc->ops = &moxart_ops;
+
+	/*
+	 * hardware does not support MMC_CAP_SD_HIGHSPEED
+	 * CMD6 will timeout and make things not work
+	 */
+	mmc->caps = MMC_CAP_4_BIT_DATA;
+
+	mmc->f_min = 400000;
+	mmc->f_max = 25000000;
+	mmc->ocr_avail = 0xffff00;	/* support 2.0v - 3.6v power */
+	mmc->max_segs = 32;
+	mmc->max_blk_size = 512;
+	mmc->max_blk_count = mmc->max_req_size / mmc->max_blk_size;
+	mmc->max_seg_size = mmc->max_req_size;
+
+	host = mmc_priv(mmc);
+	host->mmc = mmc;
+	host->reg = (struct moxart_reg *)reg_mmc;
+	host->reg_phys = res_mmc.start;
+	host->timeout = msecs_to_jiffies(1000);
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk)) {
+		dev_err(dev, "%s: of_clk_get failed\n", __func__);
+		return PTR_ERR(clk);
+	}
+	host->sysclk = clk_get_rate(clk);
+
+	spin_lock_init(&host->lock);
+
+	/* disable all interrupt */
+	writel(0, &host->reg->interrupt_mask);
+
+	/* reset chip */
+	writel(MSD_SDC_RST, &host->reg->command);
+
+	/* wait for reset finished */
+	while (readl(&host->reg->command) & MSD_SDC_RST)
+		udelay(10);
+
+	host->dma_chan_tx = dma_request_channel(mask, moxart_filter_fn,
+						(void *)&dma_chan_tx_req);
+	host->dma_chan_rx = dma_request_channel(mask, moxart_filter_fn,
+						(void *)&dma_chan_rx_req);
+	dev_dbg(dev, "%s: using 2 DMA channels rx=%p tx=%p\n",
+		__func__, host->dma_chan_rx, host->dma_chan_tx);
+
+	if (!host->dma_chan_rx || !host->dma_chan_tx) {
+		host->have_dma = false;
+		mmc->max_blk_count = 1;
+	} else {
+		cfg.slave_id = APB_DMA_SD_REQ_NO;
+		cfg.direction = DMA_MEM_TO_DEV;
+		cfg.src_addr = 0;
+		cfg.dst_addr = (unsigned int)host->reg_phys + MSD_DATA_WIN_REG;
+		cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+		dmaengine_slave_config(host->dma_chan_tx, &cfg);
+
+		cfg.slave_id = APB_DMA_SD_REQ_NO;
+		cfg.direction = DMA_DEV_TO_MEM;
+		cfg.src_addr = (unsigned int)host->reg_phys + MSD_DATA_WIN_REG;
+		cfg.dst_addr = 0;
+		cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+		dmaengine_slave_config(host->dma_chan_rx, &cfg);
+
+		host->have_dma = true;
+
+		/*
+		 * there seems to be a max size on transfers so
+		 * set max_blk_count low for both DMA and PIO
+		 *
+		 * sending large chunks result either in timeout
+		 * or render the MMC controller unresponsive
+		 * (status register 0 on consecutive read retries,
+		 * also see comments in moxart_send_command)
+		 *
+		 * obviously, DMA is quicker and can handle
+		 * larger chunks but setting it higher than 16
+		 * can still bug the controller
+		 */
+		mmc->max_blk_count = 16;
+	}
+
+	devm_request_irq(dev, irq, moxart_irq, 0, "moxart-mmc", host);
+
+	if (ret)
+		goto out;
+
+	dev_set_drvdata(dev, mmc);
+	mmc_add_host(mmc);
+
+	dev_dbg(dev, "%s: IRQ=%d\n", __func__, irq);
+
+	return 0;
+
+out:
+	if (mmc)
+		mmc_free_host(mmc);
+	return ret;
+}
+
+static void moxart_release_dma(struct moxart_host *host)
+{
+	if (host->dma_chan_tx) {
+		struct dma_chan *chan = host->dma_chan_tx;
+		host->dma_chan_tx = NULL;
+		dma_release_channel(chan);
+	}
+	if (host->dma_chan_rx) {
+		struct dma_chan *chan = host->dma_chan_rx;
+		host->dma_chan_rx = NULL;
+		dma_release_channel(chan);
+	}
+}
+
+static int moxart_remove(struct platform_device *pdev)
+{
+	struct mmc_host *mmc = dev_get_drvdata(&pdev->dev);
+	struct moxart_host *host = mmc_priv(mmc);
+
+	if (mmc) {
+		moxart_release_dma(host);
+		mmc_remove_host(mmc);
+		mmc_free_host(mmc);
+
+		writel(0, &host->reg->interrupt_mask);
+		writel(0, &host->reg->power_control);
+		writel(readl(&host->reg->clock_control) | MSD_CLK_DIS,
+		       &host->reg->clock_control);
+	}
+
+	kfree(host);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_mmc_match[] = {
+	{ .compatible = "moxa,moxart-mmc" },
+	{ }
+};
+
+static struct platform_driver moxart_mmc_driver = {
+	.probe      = moxart_probe,
+	.remove     = moxart_remove,
+	.driver     = {
+		.name		= "sdhci-moxart",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_mmc_match,
+	},
+};
+module_platform_driver(moxart_mmc_driver);
+
+MODULE_ALIAS("platform:sdhci-moxart");
+MODULE_DESCRIPTION("MOXART SDHCI driver");
+MODULE_VERSION("1.0");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
diff --git a/drivers/mmc/host/sdhci-moxart.h b/drivers/mmc/host/sdhci-moxart.h
new file mode 100644
index 0000000..7269d40
--- /dev/null
+++ b/drivers/mmc/host/sdhci-moxart.h
@@ -0,0 +1,155 @@
+/*
+ * MOXA ART MMC host driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _SDHCI_MOXART_H
+#define _SDHCI_MOXART_H
+
+extern bool moxart_filter_fn(struct dma_chan *chan, void *param);
+
+#define MSD_CMD_REG		0
+#define MSD_ARG_REG		4
+#define MSD_RESP0_REG		8
+#define MSD_RESP1_REG		0x0c
+#define MSD_RESP2_REG		0x10
+#define MSD_RESP3_REG		0x14
+#define MSD_RESP_CMD_REG	0x18
+#define MSD_DATA_CTRL_REG	0x1c
+#define MSD_DATA_TIMER_REG	0x20
+#define MSD_DATA_LEN_REG	0x24
+#define MSD_STATUS_REG		0x28
+#define MSD_CLEAR_REG		0x2c
+#define MSD_INT_MASK_REG	0x30
+#define MSD_POWER_CTRL_REG	0x34
+#define MSD_CLOCK_CTRL_REG	0x38
+#define MSD_BUS_WIDTH_REG	0x3c
+#define MSD_DATA_WIN_REG	0x40
+#define MSD_FEATURE_REG		0x44
+#define MSD_REVISION_REG	0x48
+
+#define MMC_RSP_SHORT		1
+#define MMC_RSP_LONG		2
+#define MMC_RSP_MASK		3
+#define MMC_ERR_NONE		0
+#define MMC_ERR_TIMEOUT		1
+#define MMC_MODE_MMC		0
+#define MMC_MODE_SD		1
+#define MMC_ERR_BADCRC		2
+#define MMC_VDD_360		23
+
+#define MSD_RETRY_COUNT		10
+
+struct moxart_reg {
+
+#define MSD_SDC_RST		BIT(10)
+#define MSD_CMD_EN		BIT(9)
+#define MSD_APP_CMD		BIT(8)
+#define MSD_LONG_RSP		BIT(7)
+#define MSD_NEED_RSP		BIT(6)
+#define MSD_CMD_IDX_MASK	0x3f
+	unsigned int	command;
+
+	unsigned int	argument;
+	unsigned int	response0;
+	unsigned int	response1;
+	unsigned int	response2;
+	unsigned int	response3;
+
+#define MSD_RSP_CMD_APP		BIT(6)
+#define MSD_RSP_CMD_IDX_MASK	0x3f
+	unsigned int	response_command;
+
+#define MSD_DATA_EN		BIT(6)
+#define MSD_DMA_EN		BIT(5)
+#define MSD_DATA_WRITE		BIT(4)
+#define MSD_BLK_SIZE_MASK	0x0f
+	unsigned int	data_control;
+
+	unsigned int	data_timer;
+
+#define MSD_DATA_LEN_MASK	0xffffff
+	unsigned int	data_length;
+
+#define MSD_WRITE_PROT		BIT(12)
+#define MSD_CARD_DETECT		BIT(11)
+/* 1-10 below can be sent to interrupt or clear register */
+#define MSD_CARD_CHANGE		BIT(10)
+#define MSD_FIFO_ORUN		BIT(9)
+#define MSD_FIFO_URUN		BIT(8)
+#define MSD_DATA_END		BIT(7)
+#define MSD_CMD_SENT		BIT(6)
+#define MSD_DATA_CRC_OK		BIT(5)
+#define MSD_RSP_CRC_OK		BIT(4)
+#define MSD_DATA_TIMEOUT	BIT(3)
+#define MSD_RSP_TIMEOUT		BIT(2)
+#define MSD_DATA_CRC_FAIL	BIT(1)
+#define MSD_RSP_CRC_FAIL	BIT(0)
+	unsigned int	status;
+
+	unsigned int	clear;
+	unsigned int	interrupt_mask;
+
+#define MSD_SD_POWER_ON		BIT(4)
+#define MSD_SD_POWER_MASK	0x0f
+	unsigned int	power_control;
+
+#define MSD_CLK_DIS		BIT(8)
+#define MSD_CLK_SD		BIT(7)
+#define MSD_CLK_DIV_MASK	0x7f
+	unsigned int	clock_control;
+
+#define MSD_WIDE_BUS_SUPPORT	BIT(3)
+#define MSD_WIDE_BUS		BIT(2)	/* bus width is 4 bytes */
+#define MSD_SINGLE_BUS		BIT(0)	/* bus width is 1 byte */
+	unsigned int	bus_width;
+
+	unsigned int	data_window;
+
+#define MSD_CPRM_FUNCTION	BIT(8)
+	unsigned int	feature;
+
+	unsigned int	revision;
+};
+
+struct moxart_host {
+	spinlock_t		lock;
+	struct moxart_reg	*reg;
+	phys_addr_t		reg_phys;
+
+	struct dma_chan		*dma_chan_rx;
+	struct dma_chan		*dma_chan_tx;
+	struct dma_chan		*dma_chan_cur;
+	unsigned int		dma_direction;
+	bool			have_dma;
+	struct completion	dma_complete;
+	struct completion	pio_complete;
+
+	struct mmc_host		*mmc;
+	struct mmc_request	*mrq;
+
+	struct scatterlist	*cur_sg;
+	unsigned int		num_sg;
+	unsigned int		remain;
+	int			size;
+
+	unsigned int		wait_for;
+	unsigned int		timeout;
+	long			sysclk;
+	bool			removed;
+};
+
+#define MSD_FIFO_LENW	4	/* 4 words, total 4 * 4 = 16 bytes */
+#define MSD_FIFO_LENB	16	/* 16 bytes */
+
+#endif	/* _SDHCI_MOXART_H */
-- 
1.8.2.1



From daniel.lezcano at linaro.org  Wed Jul 17 08:57:30 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 17 Jul 2013 14:57:30 +0200
Subject: [PATCH 1/3] ARM: EXYNOS: remove non-working AFTR mode support
In-Reply-To: <5509794.32CckI9OQ8@amdc1032>
References: <1372241627-22695-1-git-send-email-b.zolnierkie@samsung.com>
 <2484012.IH9WOi4iIR@amdc1032> <51CE0485.8020109@linaro.org>
 <5509794.32CckI9OQ8@amdc1032>
Message-ID: <51E694BA.3030906@linaro.org>

On 07/11/2013 03:14 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Friday, June 28, 2013 11:47:49 PM Daniel Lezcano wrote:
>> On 06/28/2013 06:27 PM, Bartlomiej Zolnierkiewicz wrote:
>>> On Friday, June 28, 2013 01:20:09 PM Daniel Lezcano wrote:
>>>> On 06/28/2013 12:11 PM, Tomasz Figa wrote:
>>>>> Hi Daniel,
>>>>>
>>>>> I've been fighting with this whole AFTR state as well, before Bartlomiej. 
>>>>> Let me share my thoughts on this.
>>>>>
>>
>> [ ... ]
>>
>>>>>
>>>>> If you don't unplug all the CPUs >0 the state is obviously never reached. 
>>>>> Otherwise the whole system hangs after it tries to enter this mode without 
>>>>> any reaction for external events, other than reset.
>>>>
>>>> Need investigation.
>>>>
>>>> What is the exynos board version where that occurs ?
>>>
>>> Could you please tell me what exactly do you mean by that?
>>>
>>> I already wrote that we can reproduce the problem on EXYNOS4210 rev0
>>> and rev1.1 (we don't have rev1.0). Tomek has also reproduced the problem
>>> on some later SoCs (I hope that he can give you exact revisions).
>>>
>>> In our testing we didn't encounter the board on which the problem
>>> doesn't occur. Our current working theory is that the problem may be
>>> u-boot (or first stage bootloader) related.
>>
>> Ok, the status for what I know:
>>
>> Origen Exynos4210, board ver A: works for me
>> Arndale Exynos5250: works for me but only if u-boot does not enable the
>> hypervisor mode.
>> Chromebook Exynos5250: works for me
> 
> I've also done some more testing. First I tested on some Exynos4412 devices
> (M0 and SLP_PQ) and AFTR was not working on them. Then I got my hands on
> Origen Exynos4210 (thanks to Tomek Figa for providing it) and AFTR is working
> just fine on it. Finally I tried Trats board again but with the upstream
> u-boot instead of our custom modified version (thanks to help from Lukasz
> Majewski) and I found out that after this change AFTR works fine on it! It
> also gives quite nice power savings (~80mA less current drawn in AFTR mode
> compared to just WFI one).

Is the 80mA power saving comparing with:

 * (cpu0/cpu1 online) vs (cpu0 AFTR and cpu1 offline)
or
 * (cpu0 AFTR and cpu1 offline) vs (cpu0 WFI and cpu1 offline)

?

> With the above findings it now seems that the issue is on our side and is
> outside the kernel. Thanks for help with narrowing down the problem and
> sorry for wasting your time.

May be we were not working on the same tree.

I am on the linux-pm-next tree.

Now the merge window occurred, the AFTR is no longer working on my board.

After git bisecting:

commit 87107d89052bcec1fe91b309631de4ed294a5171
Author: Arnd Bergmann <arnd at arndb.de>
Date:   Wed Jun 19 01:36:52 2013 +0900

    ARM: EXYNOS: Remove legacy L2X0 initialization

    Since Exynos is now supporting only DT-based boot, the old L2X0
    initialization code is not needed anymore, so exynos4_l2x0_cache_init()
    can be greatly simplified.

    Signed-off-by: Arnd Bergmann <arnd at arndb.de>
    Signed-off-by: Tomasz Figa <t.figa at samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
    Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>

:040000 040000 79e1adfd6386256ba71b3f609592d5acf9c08222
9cb0026563b3b8657d906767493d26c501963269 M	arch

Reverting the patch solves the problem.

Any ideas ?

Thanks
  -- Daniel


> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
> 
>> I found the following drivers:
>>
>> https://github.com/AndreiLux/Perseus-UNIVERSAL5410/blob/samsung/arch/arm/mach-exynos/cpuidle.c
>>
>> https://github.com/CyanogenMod/hardkernel-kernel-4412/blob/cm-10.1/arch/arm/mach-exynos/cpuidle-exynos4.c
>>
>> Sounds like the num cpus > 1 is still there.
>>
>> [ ... ]
>>
>>>> The kernel is not a playground where you can upstream code and then
>>>> remove it because a feature seems broken and you don't have an idea of why.
>>>
>>> Neither me or Tomek did upstream this code and we couldn't react in
>>> time because we haven't noticed that it is completely unusable for us
>>> as EXYNOS cpuidle driver is not even used by default on EXYNOS (it is
>>> not enabled either in defconfig or Kconfig).
>>>
>>> Moreover the feature we are talking about (AFTR mode) is also not used
>>> by default (except EXYNOS4210 rev0 on which it lockups system for us)
>>> even with EXYNOS cpuidle driver being enabled (because this specific
>>> feature depends on CPU hot-unplug which is not done automatically right
>>> now).
>>>
>>> Such things like unused/broken code removal is not something very
>>> unusual in the upstream kernel (I'm speaking from the experience here
>>> having maintained large subsystem for a couple of years). In this
>>> particular case we are talking about ~130 lines of code which can
>>> be trivially brought back later when/if needed.
>>>
>>> Anyway if the code removal is controversial for you we can just disable
>>> AFTR mode by default and enable it only when special command line option
>>> is given (i.e. "aftr"). This would fix all the broken configuration
>>> while still allowing the feature to be enabled on systems that had it
>>> working previously (since you claim that it works on some chipset/u-boot
>>> configurations).
>>
>> Actually, there are several reasons I am not in favor for the moment to
>> remove this code:
>>
>> 1) code can't be pushed upstream and then removed so easily
>> 2) I asked several times what was this cpu1 hack, I had no answer
>> 3) I tried to make both cpus entering the AFTR state, but the cpu1 never
>> wakes up, I asked but no answer.
>>
>> I would like to have some answers :)
>>
>> Before taking the decision to remove this state (btw you can remove the
>> driver directly, no ? the default idle function is WFI), IMO it is worth
>> to investigate and to spend some time to clarify what is happening. Then
>> we can take a decision.
>>
>> I am willing to help.
>>
>>>> I asked several times the reasons of why the AFTR state couldn't work
>>>> with multiple CPUs and I had no answer.
>>>
>>> Unfortunately I don't know the answer for your question.
>>>
>>> The AFTR mode doesn't work for us *at*all* (even with *one* CPU).
>>>
>>>> Frankly speaking I have a couple of hypothesis:
>>>>
>>>> 1. something is not correctly setup and the PMU does not wake up the CPU1
>>>> 2. there is a silicon bug and no one wants to tell it is the case
>>>>
>>>> In any case, this must be investigated and identified. And then we can
>>>> take a decision about this state.
>>>
>>> I don't have good idea currently how to investigate it further.
>>>
>>> I also don't have any prove that the actual work is worth it
>>> (and this work can easily take some weeks).
>>>
>>> One of main responsibilities of the maintainer it to make sure that
>>> the code does indeed work and that regressions (like these caused by
>>> AFTR mode feature) are fixed in the timely manner, not let the code
>>> sit in the limbo state for large periods of time.  It is already very
>>> bad situation that the regression we are hitting was present since
>>> v3.4 and we are in v3.10 now, I would like to have it fixed ASAP so
>>> we may actually consider enabling cpuidle in our exynos_defconfig.
>>
>> I agree.
>>
>> Thanks
>>   -- Daniel
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From jonas.jensen at gmail.com  Wed Jul 17 09:23:16 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 17 Jul 2013 15:23:16 +0200
Subject: [PATCH v3] clk: add MOXA ART SoCs clock driver
In-Reply-To: <1372943292-6960-1-git-send-email-jonas.jensen@gmail.com>
References: <1372943292-6960-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1374067396-30155-1-git-send-email-jonas.jensen@gmail.com>

This patch adds MOXA ART SoCs clock driver support.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v2:
    
    1. add devicetree bindings document
    
    Applies to next-20130716

 .../bindings/clock/moxa,moxart-core-clock.txt      | 19 +++++
 drivers/clk/Makefile                               |  1 +
 drivers/clk/clk-moxart.c                           | 82 ++++++++++++++++++++++
 3 files changed, 102 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
 create mode 100644 drivers/clk/clk-moxart.c

diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
new file mode 100644
index 0000000..cf69361
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
@@ -0,0 +1,19 @@
+Device Tree Clock bindings for arch-moxart
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+MOXA ART SoCs allow to determine core clock frequencies by reading
+a register.
+
+Required properties:
+- compatible : Should be "moxa,moxart-core-clock"
+- reg : Should contain registers location and length
+
+For example:
+
+	clk: core-clock at 98100000 {
+		compatible = "moxa,moxart-core-clock";
+		reg = <0x98100000 0x34>;
+	};
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4038c2b..933622f 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_COMMON_CLK)	+= clk-composite.o
 
 # SoCs specific
 obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
+obj-$(CONFIG_ARCH_MOXART)	+= clk-moxart.o
 obj-$(CONFIG_ARCH_NOMADIK)	+= clk-nomadik.o
 obj-$(CONFIG_ARCH_HIGHBANK)	+= clk-highbank.o
 obj-$(CONFIG_ARCH_NSPIRE)	+= clk-nspire.o
diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
new file mode 100644
index 0000000..79c27f4
--- /dev/null
+++ b/drivers/clk/clk-moxart.c
@@ -0,0 +1,82 @@
+/*
+ * MOXA ART SoCs clock driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/platform_device.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/slab.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/clkdev.h>
+
+static const struct of_device_id moxart_apb_clock_match[] = {
+	{ .compatible = "moxa,moxart-apb-clock" },
+	{ }
+};
+
+void __init moxart_of_clk_init(struct device_node *node)
+{
+	static void __iomem *base;
+	struct device_node *clk_node;
+	struct clk *clk;
+	unsigned long rate;
+	unsigned int mul, val, div;
+
+	base = of_iomap(node, 0);
+	if (IS_ERR(base))
+		panic("%s: of_iomap failed\n", node->full_name);
+
+	clk_node = of_find_matching_node(NULL, moxart_apb_clock_match);
+	if (!clk_node)
+		panic("%s: can't find clock DT node\n", node->full_name);
+
+	mul = (readl(base + 0x30) >> 3) & 0x1ff;
+	val = (readl(base + 0x0c) >> 4) & 0x7;
+
+	switch (val) {
+	case 1:
+		div = 3;
+		break;
+	case 2:
+		div = 4;
+		break;
+	case 3:
+		div = 6;
+		break;
+	case 4:
+		div = 8;
+		break;
+	default:
+		div = 2;
+		break;
+	}
+
+	/*
+	 * the rate calculation below is only tested and proven
+	 * to be true for UC-7112-LX
+	 *
+	 * UC-7112-LX: mul=80 val=0
+	 *
+	 * to support other moxart SoC hardware, this may need
+	 * a change, though it's possible it works there too
+	 */
+	rate = (mul * 1200000 / div);
+
+	clk = clk_register_fixed_rate(NULL, "clkapb", NULL, CLK_IS_ROOT, rate);
+	clk_register_clkdev(clk, NULL, "clkapb");
+	of_clk_add_provider(clk_node, of_clk_src_simple_get, clk);
+
+	iounmap(base);
+}
+CLK_OF_DECLARE(moxart_core_clock, "moxa,moxart-core-clock", moxart_of_clk_init);
-- 
1.8.2.1



From stefano.stabellini at eu.citrix.com  Wed Jul 17 09:25:38 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 17 Jul 2013 14:25:38 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabled
In-Reply-To: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
Message-ID: <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>

On Mon, 15 Jul 2013, Julien Grall wrote:
> Even if uncompress debug is disabled, some board will continue to print
> information during uncompress step.

Are you talking about DEBUG_UNCOMPRESS?
Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
some board will continue to print information during the uncompress step"?

Isn't this a bug in the platform specific code that should be fixed anyway?


> By using debug/uncompress.h include, all debug output will be disabled.

I am not sure if this is the right solution to the problem.
I think it might be better to add the appropriate ifdefs into the
platform specific code.

Arnd, what do you think?


> This is usefull in Xen environment for DOM0 because the UART is stolen by
> Xen.
> 
> Signed-off-by: Julien Grall <julien.grall at linaro.org>
>
>  arch/arm/Kconfig.debug |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 21cc8a7..86c023d 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -679,7 +679,7 @@ config DEBUG_UNCOMPRESS
>  
>  config UNCOMPRESS_INCLUDE
>  	string
> -	default "debug/uncompress.h" if ARCH_MULTIPLATFORM
> +	default "debug/uncompress.h" if ARCH_MULTIPLATFORM || !DEBUG_UNCOMPRESS
>  	default "mach/uncompress.h"
>  
>  config EARLY_PRINTK
> -- 
> 1.7.10.4
> 


From steve.capper at linaro.org  Wed Jul 17 09:26:12 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Wed, 17 Jul 2013 14:26:12 +0100
Subject: [PATCH 0/2] ARM: Tidying up huge pages in 3.11-rc1
Message-ID: <1374067574-32034-1-git-send-email-steve.capper@linaro.org>

Hello,

These two patches tidy up the huge page support in ARM that was
introduced in 3.11-rc1.

The first patch removes some duplicate code from arch/arm/mm by
referencing the mm/ functions introduced in my ARM64 huge page
series.

Whilst the second patch removes a compiler warning in the DMA
allocator that appears when huge pages are enabled.

Steve Capper (2):
  ARM: mm: Remove general hugetlb code from ARM.
  ARM: mm: Remove HugeTLB warning from dma-mapping.c

 arch/arm/Kconfig          |  3 +++
 arch/arm/mm/dma-mapping.c |  3 ---
 arch/arm/mm/hugetlbpage.c | 43 -------------------------------------------
 3 files changed, 3 insertions(+), 46 deletions(-)

-- 
1.8.1.4



From steve.capper at linaro.org  Wed Jul 17 09:26:13 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Wed, 17 Jul 2013 14:26:13 +0100
Subject: [PATCH 1/2] ARM: mm: Remove general hugetlb code from ARM.
In-Reply-To: <1374067574-32034-1-git-send-email-steve.capper@linaro.org>
References: <1374067574-32034-1-git-send-email-steve.capper@linaro.org>
Message-ID: <1374067574-32034-2-git-send-email-steve.capper@linaro.org>

General forms of huge_pte_alloc, huge_pte_offset and follow_huge_pmd
are now available in mm/hugetlb.c.

This patch removes the ARM copies of these functions and activates
the general ones by enabling:
CONFIG_ARCH_WANT_GENERAL_HUGETLB

Signed-off-by: Steve Capper <steve.capper at linaro.org>
---
 arch/arm/Kconfig          |  3 +++
 arch/arm/mm/hugetlbpage.c | 43 -------------------------------------------
 2 files changed, 3 insertions(+), 43 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..d0fd5bf 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1757,6 +1757,9 @@ config HAVE_ARCH_TRANSPARENT_HUGEPAGE
        def_bool y
        depends on ARM_LPAE
 
+config ARCH_WANT_GENERAL_HUGETLB
+	def_bool y
+
 source "mm/Kconfig"
 
 config FORCE_MAX_ZONEORDER
diff --git a/arch/arm/mm/hugetlbpage.c b/arch/arm/mm/hugetlbpage.c
index 3d1e4a2..66781bf 100644
--- a/arch/arm/mm/hugetlbpage.c
+++ b/arch/arm/mm/hugetlbpage.c
@@ -36,22 +36,6 @@
  * of type casting from pmd_t * to pte_t *.
  */
 
-pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
-{
-	pgd_t *pgd;
-	pud_t *pud;
-	pmd_t *pmd = NULL;
-
-	pgd = pgd_offset(mm, addr);
-	if (pgd_present(*pgd)) {
-		pud = pud_offset(pgd, addr);
-		if (pud_present(*pud))
-			pmd = pmd_offset(pud, addr);
-	}
-
-	return (pte_t *)pmd;
-}
-
 struct page *follow_huge_addr(struct mm_struct *mm, unsigned long address,
 			      int write)
 {
@@ -68,33 +52,6 @@ int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep)
 	return 0;
 }
 
-pte_t *huge_pte_alloc(struct mm_struct *mm,
-			unsigned long addr, unsigned long sz)
-{
-	pgd_t *pgd;
-	pud_t *pud;
-	pte_t *pte = NULL;
-
-	pgd = pgd_offset(mm, addr);
-	pud = pud_alloc(mm, pgd, addr);
-	if (pud)
-		pte = (pte_t *)pmd_alloc(mm, pud, addr);
-
-	return pte;
-}
-
-struct page *
-follow_huge_pmd(struct mm_struct *mm, unsigned long address,
-		pmd_t *pmd, int write)
-{
-	struct page *page;
-
-	page = pte_page(*(pte_t *)pmd);
-	if (page)
-		page += ((address & ~PMD_MASK) >> PAGE_SHIFT);
-	return page;
-}
-
 int pmd_huge(pmd_t pmd)
 {
 	return pmd_val(pmd) && !(pmd_val(pmd) & PMD_TABLE_BIT);
-- 
1.8.1.4



From steve.capper at linaro.org  Wed Jul 17 09:26:14 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Wed, 17 Jul 2013 14:26:14 +0100
Subject: [PATCH 2/2] ARM: mm: Remove HugeTLB warning from dma-mapping.c
In-Reply-To: <1374067574-32034-1-git-send-email-steve.capper@linaro.org>
References: <1374067574-32034-1-git-send-email-steve.capper@linaro.org>
Message-ID: <1374067574-32034-3-git-send-email-steve.capper@linaro.org>

The coherant DMA allocator code contained a compile time warning
when HugeTLB support was enabled. It stated that huge pages were
not supported by the DMA allocator.

Apart from memory pressure, HugeTLB should not affect (or be
affected by) the higher order pages operated on by the DMA
allocator. Also, the user space mappings returned by arm_dma_mmap
are done via remap_pfn_range, so the Transparent Huge Page daemon
will leave them alone too.

This patch removes the huge page warning from dma-mapping.c.

Signed-off-by: Steve Capper <steve.capper at linaro.org>
---
 arch/arm/mm/dma-mapping.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 7f9b179..9486048 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -249,9 +249,6 @@ static void __dma_free_buffer(struct page *page, size_t size)
 }
 
 #ifdef CONFIG_MMU
-#ifdef CONFIG_HUGETLB_PAGE
-#warning ARM Coherent DMA allocator does not (yet) support huge TLB
-#endif
 
 static void *__alloc_from_contiguous(struct device *dev, size_t size,
 				     pgprot_t prot, struct page **ret_page,
-- 
1.8.1.4



From stefano.stabellini at eu.citrix.com  Wed Jul 17 09:28:43 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 17 Jul 2013 14:28:43 +0100
Subject: [Xen-devel] [PATCH] xen/arm: disable cpuidle when linux is
 running as dom0
In-Reply-To: <20130715152532.GC5774@phenom.dumpdata.com>
References: <1373898101-15633-1-git-send-email-julien.grall@linaro.org>
 <20130715152532.GC5774@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1307171426300.8258@kaball.uk.xensource.com>

On Mon, 15 Jul 2013, Konrad Rzeszutek Wilk wrote:
> On Mon, Jul 15, 2013 at 03:21:41PM +0100, Julien Grall wrote:
> > When linux is running as dom0, Xen doesn't show the physical cpu but a
> > virtual CPU.
> > On some ARM SOC (for instance the exynos 5250), linux registers callbacks
> > for cpuidle. When these callbacks are called, they will modify
> > directly the physical cpu not the virtual one.
> It can impact the whole board
> > instead of dom0.

Certainly this is something that should be fixed at the hypervisor level
too. However I agree that Linux should try to avoid doing that when
running on Xen.



> Should you also call disable_cpufreq() ?

Sounds like a good idea.
Julien, could you add that to this patch?


> > 
> > Signed-off-by: Julien Grall <julien.grall at linaro.org>
> > ---
> >  arch/arm/xen/enlighten.c |    7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index 49839d8..a98999f 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -24,6 +24,8 @@
> >  #include <linux/of.h>
> >  #include <linux/of_irq.h>
> >  #include <linux/of_address.h>
> > +#include <linux/cpuidle.h>
> > +#include <linux/cpufreq.h>
> >  
> >  #include <linux/mm.h>
> >  
> > @@ -292,6 +294,11 @@ static int __init xen_pm_init(void)
> >  {
> >  	pm_power_off = xen_power_off;
> >  	arm_pm_restart = xen_restart;
> > +	/*
> > +	 * Making sure board specific code will not set up ops for
> > +	 * cpu idle.
> > +	 */
> > +	disable_cpuidle();
> >  
> >  	return 0;
> >  }
> > -- 
> > 1.7.10.4
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel at lists.xen.org
> > http://lists.xen.org/xen-devel
> 


From pawel.moll at arm.com  Wed Jul 17 09:29:46 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Wed, 17 Jul 2013 14:29:46 +0100
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <alpine.LFD.2.03.1307170825240.14924@syhkavp.arg>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374052705.3146.86.camel@hornet>
 <alpine.LFD.2.03.1307170825240.14924@syhkavp.arg>
Message-ID: <1374067786.3146.123.camel@hornet>

On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote:
> If this is really miscelaneous code that really doesn't fit 
> anywhere else, it should rather go into drivers/misc/ as a last resort.

Interestingly enough drivers/misc was my first choice for all the
vexpress stuff, but it wasn't received well...

Anyway, the SPC driver as it is now seem to be a "power management
system driver". Maybe a relevant directory would be in place? Wouldn't
PSCI belong there as well? (there are two psci.c files in arch/arm and
arch/arm64, surprisingly similar ones ;-)

The bottom line is: today it is not an MFD driver.

Pawe?




From lorenzo.pieralisi at arm.com  Wed Jul 17 09:31:23 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 17 Jul 2013 14:31:23 +0100
Subject: [PATCH 1/3] ARM: EXYNOS: remove non-working AFTR mode support
In-Reply-To: <51E694BA.3030906@linaro.org>
References: <1372241627-22695-1-git-send-email-b.zolnierkie@samsung.com>
 <2484012.IH9WOi4iIR@amdc1032> <51CE0485.8020109@linaro.org>
 <5509794.32CckI9OQ8@amdc1032> <51E694BA.3030906@linaro.org>
Message-ID: <20130717133123.GA5453@e102568-lin.cambridge.arm.com>

On Wed, Jul 17, 2013 at 01:57:30PM +0100, Daniel Lezcano wrote:
> On 07/11/2013 03:14 PM, Bartlomiej Zolnierkiewicz wrote:
> > 
> > Hi,
> > 
> > On Friday, June 28, 2013 11:47:49 PM Daniel Lezcano wrote:
> >> On 06/28/2013 06:27 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> On Friday, June 28, 2013 01:20:09 PM Daniel Lezcano wrote:
> >>>> On 06/28/2013 12:11 PM, Tomasz Figa wrote:
> >>>>> Hi Daniel,
> >>>>>
> >>>>> I've been fighting with this whole AFTR state as well, before Bartlomiej. 
> >>>>> Let me share my thoughts on this.
> >>>>>
> >>
> >> [ ... ]
> >>
> >>>>>
> >>>>> If you don't unplug all the CPUs >0 the state is obviously never reached. 
> >>>>> Otherwise the whole system hangs after it tries to enter this mode without 
> >>>>> any reaction for external events, other than reset.
> >>>>
> >>>> Need investigation.
> >>>>
> >>>> What is the exynos board version where that occurs ?
> >>>
> >>> Could you please tell me what exactly do you mean by that?
> >>>
> >>> I already wrote that we can reproduce the problem on EXYNOS4210 rev0
> >>> and rev1.1 (we don't have rev1.0). Tomek has also reproduced the problem
> >>> on some later SoCs (I hope that he can give you exact revisions).
> >>>
> >>> In our testing we didn't encounter the board on which the problem
> >>> doesn't occur. Our current working theory is that the problem may be
> >>> u-boot (or first stage bootloader) related.
> >>
> >> Ok, the status for what I know:
> >>
> >> Origen Exynos4210, board ver A: works for me
> >> Arndale Exynos5250: works for me but only if u-boot does not enable the
> >> hypervisor mode.
> >> Chromebook Exynos5250: works for me
> > 
> > I've also done some more testing. First I tested on some Exynos4412 devices
> > (M0 and SLP_PQ) and AFTR was not working on them. Then I got my hands on
> > Origen Exynos4210 (thanks to Tomek Figa for providing it) and AFTR is working
> > just fine on it. Finally I tried Trats board again but with the upstream
> > u-boot instead of our custom modified version (thanks to help from Lukasz
> > Majewski) and I found out that after this change AFTR works fine on it! It
> > also gives quite nice power savings (~80mA less current drawn in AFTR mode
> > compared to just WFI one).
> 
> Is the 80mA power saving comparing with:
> 
>  * (cpu0/cpu1 online) vs (cpu0 AFTR and cpu1 offline)
> or
>  * (cpu0 AFTR and cpu1 offline) vs (cpu0 WFI and cpu1 offline)
> 
> ?
> 
> > With the above findings it now seems that the issue is on our side and is
> > outside the kernel. Thanks for help with narrowing down the problem and
> > sorry for wasting your time.
> 
> May be we were not working on the same tree.
> 
> I am on the linux-pm-next tree.
> 
> Now the merge window occurred, the AFTR is no longer working on my board.
> 
> After git bisecting:
> 
> commit 87107d89052bcec1fe91b309631de4ed294a5171
> Author: Arnd Bergmann <arnd at arndb.de>
> Date:   Wed Jun 19 01:36:52 2013 +0900
> 
>     ARM: EXYNOS: Remove legacy L2X0 initialization
> 
>     Since Exynos is now supporting only DT-based boot, the old L2X0
>     initialization code is not needed anymore, so exynos4_l2x0_cache_init()
>     can be greatly simplified.
> 
>     Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>     Signed-off-by: Tomasz Figa <t.figa at samsung.com>
>     Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
>     Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
> 
> :040000 040000 79e1adfd6386256ba71b3f609592d5acf9c08222
> 9cb0026563b3b8657d906767493d26c501963269 M	arch
> 
> Reverting the patch solves the problem.
> 
> Any ideas ?

It is certainly a problem related to restoring L2 control registers in
plat-samsung/s5p-sleep.S, probably DT init misses some registers
(prefetch and power control) that are restored to zero values most
likely, or the cluster cannot be shut down owing to those values not
being programmed properly. Chander posted a patch to fix that but I could
not follow that thread, I have no idea where he got to and if that fixes
the issue, I think so.

Lorenzo



From b.brezillon at overkiz.com  Wed Jul 17 09:34:29 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 15:34:29 +0200
Subject: [PATCH v2 00/42] ARM: at91: move to common clk framework
Message-ID: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>

Hello,

This patch series is a proposal to move at91 clock implementation
to common clk framework.

Most of the clock provided by the PMC (Power Management Controller) are
implemented :
- main clock (main oscillator)
- pll clocks
- master clock
- programmable clocks
- utmi clock
- peripheral clocks
- system clocks

This implementation is compatible with device tree: the goal is
to define the whole clock tree in the device tree (all currently
available dt SoCs and boards are patched to support dt clocks).
Please feel free to comment the dt bindinds.

I removed the register_clocks function in SoC supporting dt boards only:
- at91sam9x5 SoCs
- at91sam9n12 SoC
- sama5d3 SoCs

This patch series is based on linux-next and has been tested on sama5d31ek
board using device tree. It compiles for other SoCs and both with and without
dt support, but it has not been tested.

BTW could other people test it on other boards (I only have a kizbox and
a sama5d31ek dev kit).

Best Regards,
Boris

Changes since v1:
 - fix bugs in pll, programmable and system clock implementations
   (wrong bit position).
 - add usb clock configuration support (ohci and udc drivers +
   clk_lookup for non dt boards)
 - rework of the system clock interfaces (no need to define a parent clock,
   system clock is a gate with no rate info)
 - change system, peripheral and programmable clk dt bindings (1 master node
   and multiple child nodes each defining a system/peripheral or prog clock)
 - fix bugs in sama5 dt definition

Boris BREZILLON (42):
  ARM: at91: move at91_pmc.h to include/linux/clk/at91.h
  ARM: at91: add PMC main clock
  ARM: at91: add PMC pll clocks
  ARM: at91: add PMC master clock
  ARM: at91: add PMC system clocks
  ARM: at91: add PMC peripheral clocks
  ARM: at91: add PMC programmable clocks
  ARM: at91: add PMC utmi clock
  ARM: at91: add PMC usb clock
  ARM: at91: add PMC smd clock
  ARM: at91: add PMC clk device tree binding doc.
  ARM: at91: move to common clk framework
  ARM: at91: move at91rm9200 SoC to new at91 clk implem
  ARM: at91: move at91sam9260 SoC to new at91 clk implem
  ARM: at91: move at91sam9261 SoC to new at91 clk implem
  ARM: at91: move at91sam9263 SoC to new at91 clk implem
  ARM: at91: move at91sam9g45 SoC to new at91 clk implem
  ARM: at91: move at91sam9n12 SoC to new at91 clk implem
  ARM: at91: move at91sam9rl SoC to new at91 clk implem
  ARM: at91: move at91sam9x5 SoCs to new at91 clk implem
  ARM: at91: move at91sam9 SoCs to new at91 clk implem
  ARM: at91: move sama5d3 SoCs to new at91 clk implem
  ARM: at91: move at91rm9200 boards to new at91 clk implem
  ARM: at91: move at91sam9 boards to new at91 clk implem
  ARM: at91: move pit timer to common clk framework
  USB: ohci-at91: add usb_clk for transition to common clk framework
  usb: gadget: at91_udc: add usb_clk for transition to common clk
    framework
  ARM: at91/dt: move at91rm9200 SoC to new at91 clk implem
  ARM: at91/dt: move at91sam9260 SoC to new at91 clk implem
  ARM: at91/dt: move at91sam9263 SoC to new at91 clk implem
  ARM: at91/dt: move at91sam9g45 SoC to new at91 clk implem
  ARM: at91/dt: move at91sam9n12 SoC to new at91 clk implem
  ARM: at91/dt: move at91sam9x5 SoCs to new at91 clk implem
  ARM: at91/dt: move at91sam9g20 SoC to new at91 clk implem
  ARM: at91/dt: move sama5d3 SoCs to new at91 clk implem
  ARM: at91/dt: move sam9260/sam9g20 to new at91 clk implem
  ARM: at91/dt: move rm9200 boards to new at91 clk implem
  ARM: at91/dt: move sam9263 boards to new at91 clk implem
  ARM: at91/dt: move sam9g45 boards to new at91 clk implem
  ARM: at91/dt: move sam9n12 boards to new at91 clk implem
  ARM: at91/dt: move sam9x5 boards to new at91 clk implem
  ARM: at91/dt: move sama5d3 boards to new at91 clk implem

 .../devicetree/bindings/clock/at91-clock.txt       |  262 ++++++
 arch/arm/boot/dts/animeo_ip.dts                    |   17 +-
 arch/arm/boot/dts/at91-ariag25.dts                 |   17 +-
 arch/arm/boot/dts/at91rm9200.dtsi                  |  231 +++++
 arch/arm/boot/dts/at91rm9200ek.dts                 |   17 +-
 arch/arm/boot/dts/at91sam9260.dtsi                 |  236 +++++
 arch/arm/boot/dts/at91sam9263.dtsi                 |  237 +++++
 arch/arm/boot/dts/at91sam9263ek.dts                |   17 +-
 arch/arm/boot/dts/at91sam9g15.dtsi                 |    1 +
 arch/arm/boot/dts/at91sam9g20.dtsi                 |   37 +
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi        |   17 +-
 arch/arm/boot/dts/at91sam9g25.dtsi                 |    3 +
 arch/arm/boot/dts/at91sam9g35.dtsi                 |    2 +
 arch/arm/boot/dts/at91sam9g45.dtsi                 |  257 +++++
 arch/arm/boot/dts/at91sam9m10g45ek.dts             |   17 +-
 arch/arm/boot/dts/at91sam9n12.dtsi                 |  251 +++++
 arch/arm/boot/dts/at91sam9n12ek.dts                |   17 +-
 arch/arm/boot/dts/at91sam9x25.dtsi                 |   25 +-
 arch/arm/boot/dts/at91sam9x35.dtsi                 |    3 +
 arch/arm/boot/dts/at91sam9x5.dtsi                  |  319 +++++--
 arch/arm/boot/dts/at91sam9x5_can.dtsi              |   26 +
 arch/arm/boot/dts/at91sam9x5_isi.dtsi              |   22 +
 arch/arm/boot/dts/at91sam9x5_lcdc.dtsi             |   28 +
 arch/arm/boot/dts/at91sam9x5_macb0.dtsi            |   66 ++
 arch/arm/boot/dts/at91sam9x5_macb1.dtsi            |   54 ++
 arch/arm/boot/dts/at91sam9x5_usart3.dtsi           |   58 ++
 arch/arm/boot/dts/ge863-pro3.dtsi                  |   16 +-
 arch/arm/boot/dts/kizbox.dts                       |    5 +
 arch/arm/boot/dts/mpa1600.dts                      |   16 +-
 arch/arm/boot/dts/pm9g45.dts                       |   16 +-
 arch/arm/boot/dts/sama5d3.dtsi                     |  510 ++++++----
 arch/arm/boot/dts/sama5d31ek.dts                   |    4 +
 arch/arm/boot/dts/sama5d33ek.dts                   |    2 +
 arch/arm/boot/dts/sama5d34ek.dts                   |    4 +
 arch/arm/boot/dts/sama5d35ek.dts                   |    6 +
 arch/arm/boot/dts/sama5d3_can.dtsi                 |   71 ++
 arch/arm/boot/dts/sama5d3_emac.dtsi                |   54 ++
 arch/arm/boot/dts/sama5d3_gmac.dtsi                |   87 ++
 arch/arm/boot/dts/sama5d3_lcd.dtsi                 |   69 ++
 arch/arm/boot/dts/sama5d3_mci2.dtsi                |   57 ++
 arch/arm/boot/dts/sama5d3_tcb1.dtsi                |   38 +
 arch/arm/boot/dts/sama5d3_uart.dtsi                |   46 +
 arch/arm/boot/dts/sama5d3xcm.dtsi                  |   17 +-
 arch/arm/boot/dts/tny_a9260_common.dtsi            |   17 +-
 arch/arm/boot/dts/tny_a9263.dts                    |   17 +-
 arch/arm/boot/dts/usb_a9260_common.dtsi            |   17 +-
 arch/arm/boot/dts/usb_a9263.dts                    |   17 +-
 arch/arm/mach-at91/Kconfig                         |   26 +
 arch/arm/mach-at91/Makefile                        |    2 +-
 arch/arm/mach-at91/at91rm9200.c                    |  568 +++++++-----
 arch/arm/mach-at91/at91sam9260.c                   |  689 +++++++++-----
 arch/arm/mach-at91/at91sam9261.c                   |  572 ++++++++----
 arch/arm/mach-at91/at91sam9263.c                   |  595 +++++++-----
 arch/arm/mach-at91/at91sam926x_time.c              |   21 +-
 arch/arm/mach-at91/at91sam9g45.c                   |  704 ++++++++------
 arch/arm/mach-at91/at91sam9g45_devices.c           |    1 -
 arch/arm/mach-at91/at91sam9n12.c                   |  196 +---
 arch/arm/mach-at91/at91sam9rl.c                    |  502 ++++++----
 arch/arm/mach-at91/at91sam9x5.c                    |  293 +-----
 arch/arm/mach-at91/board-1arm.c                    |   12 +-
 arch/arm/mach-at91/board-afeb-9260v1.c             |   11 +-
 arch/arm/mach-at91/board-cam60.c                   |   13 +-
 arch/arm/mach-at91/board-carmeva.c                 |   13 +-
 arch/arm/mach-at91/board-cpu9krea.c                |   12 +-
 arch/arm/mach-at91/board-cpuat91.c                 |   12 +-
 arch/arm/mach-at91/board-csb337.c                  |   11 +-
 arch/arm/mach-at91/board-csb637.c                  |   11 +-
 arch/arm/mach-at91/board-dt-rm9200.c               |    9 +-
 arch/arm/mach-at91/board-dt-sam9.c                 |    9 +-
 arch/arm/mach-at91/board-dt-sama5.c                |    9 +-
 arch/arm/mach-at91/board-eb9200.c                  |   11 +-
 arch/arm/mach-at91/board-ecbat91.c                 |   12 +-
 arch/arm/mach-at91/board-eco920.c                  |   13 +-
 arch/arm/mach-at91/board-flexibity.c               |   12 +-
 arch/arm/mach-at91/board-foxg20.c                  |   12 +-
 arch/arm/mach-at91/board-gsia18s.c                 |    8 +-
 arch/arm/mach-at91/board-kafa.c                    |   12 +-
 arch/arm/mach-at91/board-kb9202.c                  |   12 +-
 arch/arm/mach-at91/board-pcontrol-g20.c            |    9 +-
 arch/arm/mach-at91/board-picotux200.c              |   11 +-
 arch/arm/mach-at91/board-qil-a9260.c               |   11 +-
 arch/arm/mach-at91/board-rm9200ek.c                |   11 +-
 arch/arm/mach-at91/board-rsi-ews.c                 |   12 +-
 arch/arm/mach-at91/board-sam9-l9260.c              |   11 +-
 arch/arm/mach-at91/board-sam9260ek.c               |   11 +-
 arch/arm/mach-at91/board-sam9261ek.c               |   15 +-
 arch/arm/mach-at91/board-sam9263ek.c               |   11 +-
 arch/arm/mach-at91/board-sam9g20ek.c               |   15 +-
 arch/arm/mach-at91/board-sam9m10g45ek.c            |   11 +-
 arch/arm/mach-at91/board-sam9rlek.c                |   11 +-
 arch/arm/mach-at91/board-snapper9260.c             |   12 +-
 arch/arm/mach-at91/board-stamp9g20.c               |   15 +-
 arch/arm/mach-at91/board-yl-9200.c                 |   12 +-
 arch/arm/mach-at91/clock.c                         |  977 --------------------
 arch/arm/mach-at91/clock.h                         |   49 -
 arch/arm/mach-at91/generic.h                       |   10 +-
 arch/arm/mach-at91/pm.c                            |    2 +-
 arch/arm/mach-at91/pm_slowclock.S                  |    2 +-
 arch/arm/mach-at91/pmc.c                           |   58 ++
 arch/arm/mach-at91/sama5d3.c                       |  344 +------
 arch/arm/mach-at91/setup.c                         |   38 +-
 arch/arm/mach-at91/stamp9g20.h                     |    2 +-
 drivers/clk/Makefile                               |    1 +
 drivers/clk/at91/Makefile                          |   11 +
 drivers/clk/at91/clk-main.c                        |  106 +++
 drivers/clk/at91/clk-master.c                      |  317 +++++++
 drivers/clk/at91/clk-peripheral.c                  |  371 ++++++++
 drivers/clk/at91/clk-pll.c                         |  438 +++++++++
 drivers/clk/at91/clk-plldiv.c                      |  125 +++
 drivers/clk/at91/clk-programmable.c                |  368 ++++++++
 drivers/clk/at91/clk-smd.c                         |  157 ++++
 drivers/clk/at91/clk-system.c                      |  184 ++++
 drivers/clk/at91/clk-usb.c                         |  303 ++++++
 drivers/clk/at91/clk-utmi.c                        |  114 +++
 drivers/usb/gadget/at91_udc.c                      |   31 +-
 drivers/usb/gadget/at91_udc.h                      |    2 +-
 drivers/usb/gadget/atmel_usba_udc.c                |    2 +-
 drivers/usb/host/ohci-at91.c                       |   16 +-
 .../mach/at91_pmc.h => include/linux/clk/at91.h    |  116 ++-
 119 files changed, 8193 insertions(+), 3835 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/at91-clock.txt
 create mode 100644 arch/arm/boot/dts/at91sam9x5_can.dtsi
 create mode 100644 arch/arm/boot/dts/at91sam9x5_isi.dtsi
 create mode 100644 arch/arm/boot/dts/at91sam9x5_lcdc.dtsi
 create mode 100644 arch/arm/boot/dts/at91sam9x5_macb0.dtsi
 create mode 100644 arch/arm/boot/dts/at91sam9x5_macb1.dtsi
 create mode 100644 arch/arm/boot/dts/at91sam9x5_usart3.dtsi
 create mode 100644 arch/arm/boot/dts/sama5d3_can.dtsi
 create mode 100644 arch/arm/boot/dts/sama5d3_emac.dtsi
 create mode 100644 arch/arm/boot/dts/sama5d3_gmac.dtsi
 create mode 100644 arch/arm/boot/dts/sama5d3_lcd.dtsi
 create mode 100644 arch/arm/boot/dts/sama5d3_mci2.dtsi
 create mode 100644 arch/arm/boot/dts/sama5d3_tcb1.dtsi
 create mode 100644 arch/arm/boot/dts/sama5d3_uart.dtsi
 delete mode 100644 arch/arm/mach-at91/clock.c
 delete mode 100644 arch/arm/mach-at91/clock.h
 create mode 100644 arch/arm/mach-at91/pmc.c
 create mode 100644 drivers/clk/at91/Makefile
 create mode 100644 drivers/clk/at91/clk-main.c
 create mode 100644 drivers/clk/at91/clk-master.c
 create mode 100644 drivers/clk/at91/clk-peripheral.c
 create mode 100644 drivers/clk/at91/clk-pll.c
 create mode 100644 drivers/clk/at91/clk-plldiv.c
 create mode 100644 drivers/clk/at91/clk-programmable.c
 create mode 100644 drivers/clk/at91/clk-smd.c
 create mode 100644 drivers/clk/at91/clk-system.c
 create mode 100644 drivers/clk/at91/clk-usb.c
 create mode 100644 drivers/clk/at91/clk-utmi.c
 rename arch/arm/mach-at91/include/mach/at91_pmc.h => include/linux/clk/at91.h (78%)

-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 09:37:27 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 15:37:27 +0200
Subject: [PATCH v2 01/42] ARM: at91: move at91_pmc.h to
 include/linux/clk/at91.h
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374068247-13574-1-git-send-email-b.brezillon@overkiz.com>

This patch moves at91_pmc.h header from machine specific directory
(arch/arm/mach-at91/include/mach/at91_pmc.h) to clk include directory
(include/linux/clk/at91.h).
We need this to avoid reference to machine specific headers in clk
drivers.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/at91rm9200.c                    |    2 +-
 arch/arm/mach-at91/at91sam9260.c                   |    2 +-
 arch/arm/mach-at91/at91sam9261.c                   |    2 +-
 arch/arm/mach-at91/at91sam9263.c                   |    2 +-
 arch/arm/mach-at91/at91sam9g45.c                   |    2 +-
 arch/arm/mach-at91/at91sam9n12.c                   |    2 +-
 arch/arm/mach-at91/at91sam9rl.c                    |    2 +-
 arch/arm/mach-at91/at91sam9x5.c                    |    2 +-
 arch/arm/mach-at91/clock.c                         |    2 +-
 arch/arm/mach-at91/pm.c                            |    2 +-
 arch/arm/mach-at91/pm_slowclock.S                  |    2 +-
 arch/arm/mach-at91/sama5d3.c                       |    2 +-
 arch/arm/mach-at91/setup.c                         |    2 +-
 drivers/usb/gadget/atmel_usba_udc.c                |    2 +-
 .../mach/at91_pmc.h => include/linux/clk/at91.h    |    2 +-
 15 files changed, 15 insertions(+), 15 deletions(-)
 rename arch/arm/mach-at91/include/mach/at91_pmc.h => include/linux/clk/at91.h (99%)

diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
index 4aad93d..8de5b02 100644
--- a/arch/arm/mach-at91/at91rm9200.c
+++ b/arch/arm/mach-at91/at91rm9200.c
@@ -12,13 +12,13 @@
 
 #include <linux/module.h>
 #include <linux/reboot.h>
+#include <linux/clk/at91.h>
 
 #include <asm/irq.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <asm/system_misc.h>
 #include <mach/at91rm9200.h>
-#include <mach/at91_pmc.h>
 #include <mach/at91_st.h>
 #include <mach/cpu.h>
 
diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
index 5de6074..db9d89a 100644
--- a/arch/arm/mach-at91/at91sam9260.c
+++ b/arch/arm/mach-at91/at91sam9260.c
@@ -11,6 +11,7 @@
  */
 
 #include <linux/module.h>
+#include <linux/clk/at91.h>
 
 #include <asm/proc-fns.h>
 #include <asm/irq.h>
@@ -20,7 +21,6 @@
 #include <mach/cpu.h>
 #include <mach/at91_dbgu.h>
 #include <mach/at91sam9260.h>
-#include <mach/at91_pmc.h>
 
 #include "at91_aic.h"
 #include "at91_rstc.h"
diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
index 0e07932..a4123bd 100644
--- a/arch/arm/mach-at91/at91sam9261.c
+++ b/arch/arm/mach-at91/at91sam9261.c
@@ -11,6 +11,7 @@
  */
 
 #include <linux/module.h>
+#include <linux/clk/at91.h>
 
 #include <asm/proc-fns.h>
 #include <asm/irq.h>
@@ -19,7 +20,6 @@
 #include <asm/system_misc.h>
 #include <mach/cpu.h>
 #include <mach/at91sam9261.h>
-#include <mach/at91_pmc.h>
 
 #include "at91_aic.h"
 #include "at91_rstc.h"
diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
index 6ce7d18..e0a1a68 100644
--- a/arch/arm/mach-at91/at91sam9263.c
+++ b/arch/arm/mach-at91/at91sam9263.c
@@ -11,6 +11,7 @@
  */
 
 #include <linux/module.h>
+#include <linux/clk/at91.h>
 
 #include <asm/proc-fns.h>
 #include <asm/irq.h>
@@ -18,7 +19,6 @@
 #include <asm/mach/map.h>
 #include <asm/system_misc.h>
 #include <mach/at91sam9263.h>
-#include <mach/at91_pmc.h>
 
 #include "at91_aic.h"
 #include "at91_rstc.h"
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index 474ee04..29ba2ca 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -12,13 +12,13 @@
 
 #include <linux/module.h>
 #include <linux/dma-mapping.h>
+#include <linux/clk/at91.h>
 
 #include <asm/irq.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <asm/system_misc.h>
 #include <mach/at91sam9g45.h>
-#include <mach/at91_pmc.h>
 #include <mach/cpu.h>
 
 #include "at91_aic.h"
diff --git a/arch/arm/mach-at91/at91sam9n12.c b/arch/arm/mach-at91/at91sam9n12.c
index c7d670d..c270503 100644
--- a/arch/arm/mach-at91/at91sam9n12.c
+++ b/arch/arm/mach-at91/at91sam9n12.c
@@ -8,12 +8,12 @@
 
 #include <linux/module.h>
 #include <linux/dma-mapping.h>
+#include <linux/clk/at91.h>
 
 #include <asm/irq.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <mach/at91sam9n12.h>
-#include <mach/at91_pmc.h>
 #include <mach/cpu.h>
 
 #include "board.h"
diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c
index d4ec0d9..2694bd1 100644
--- a/arch/arm/mach-at91/at91sam9rl.c
+++ b/arch/arm/mach-at91/at91sam9rl.c
@@ -10,6 +10,7 @@
  */
 
 #include <linux/module.h>
+#include <linux/clk/at91.h>
 
 #include <asm/proc-fns.h>
 #include <asm/irq.h>
@@ -19,7 +20,6 @@
 #include <mach/cpu.h>
 #include <mach/at91_dbgu.h>
 #include <mach/at91sam9rl.h>
-#include <mach/at91_pmc.h>
 
 #include "at91_aic.h"
 #include "at91_rstc.h"
diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
index 2abee66..9fdea07 100644
--- a/arch/arm/mach-at91/at91sam9x5.c
+++ b/arch/arm/mach-at91/at91sam9x5.c
@@ -8,12 +8,12 @@
 
 #include <linux/module.h>
 #include <linux/dma-mapping.h>
+#include <linux/clk/at91.h>
 
 #include <asm/irq.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <mach/at91sam9x5.h>
-#include <mach/at91_pmc.h>
 #include <mach/cpu.h>
 
 #include "board.h"
diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
index 6b2630a..cc263d0 100644
--- a/arch/arm/mach-at91/clock.c
+++ b/arch/arm/mach-at91/clock.c
@@ -24,9 +24,9 @@
 #include <linux/clk.h>
 #include <linux/io.h>
 #include <linux/of_address.h>
+#include <linux/clk/at91.h>
 
 #include <mach/hardware.h>
-#include <mach/at91_pmc.h>
 #include <mach/cpu.h>
 
 #include <asm/proc-fns.h>
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 15afb5d..de425e0 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -19,13 +19,13 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/io.h>
+#include <linux/clk/at91.h>
 
 #include <asm/irq.h>
 #include <linux/atomic.h>
 #include <asm/mach/time.h>
 #include <asm/mach/irq.h>
 
-#include <mach/at91_pmc.h>
 #include <mach/cpu.h>
 
 #include "at91_aic.h"
diff --git a/arch/arm/mach-at91/pm_slowclock.S b/arch/arm/mach-at91/pm_slowclock.S
index 098c28d..76387e0 100644
--- a/arch/arm/mach-at91/pm_slowclock.S
+++ b/arch/arm/mach-at91/pm_slowclock.S
@@ -13,8 +13,8 @@
  */
 
 #include <linux/linkage.h>
+#include <linux/clk/at91.h>
 #include <mach/hardware.h>
-#include <mach/at91_pmc.h>
 #include <mach/at91_ramc.h>
 
 
diff --git a/arch/arm/mach-at91/sama5d3.c b/arch/arm/mach-at91/sama5d3.c
index 4012797..32e0522 100644
--- a/arch/arm/mach-at91/sama5d3.c
+++ b/arch/arm/mach-at91/sama5d3.c
@@ -9,12 +9,12 @@
 
 #include <linux/module.h>
 #include <linux/dma-mapping.h>
+#include <linux/clk/at91.h>
 
 #include <asm/irq.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <mach/sama5d3.h>
-#include <mach/at91_pmc.h>
 #include <mach/cpu.h>
 
 #include "soc.h"
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index b17fbcf..de3c519 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -11,6 +11,7 @@
 #include <linux/pm.h>
 #include <linux/of_address.h>
 #include <linux/pinctrl/machine.h>
+#include <linux/clk/at91.h>
 
 #include <asm/system_misc.h>
 #include <asm/mach/map.h>
@@ -18,7 +19,6 @@
 #include <mach/hardware.h>
 #include <mach/cpu.h>
 #include <mach/at91_dbgu.h>
-#include <mach/at91_pmc.h>
 
 #include "at91_shdwc.h"
 #include "soc.h"
diff --git a/drivers/usb/gadget/atmel_usba_udc.c b/drivers/usb/gadget/atmel_usba_udc.c
index f018017..a678537 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -326,7 +326,7 @@ static int vbus_is_present(struct usba_udc *udc)
 
 #if defined(CONFIG_ARCH_AT91SAM9RL)
 
-#include <mach/at91_pmc.h>
+#include <linux/clk/at91.h>
 
 static void toggle_bias(int is_on)
 {
diff --git a/arch/arm/mach-at91/include/mach/at91_pmc.h b/include/linux/clk/at91.h
similarity index 99%
rename from arch/arm/mach-at91/include/mach/at91_pmc.h
rename to include/linux/clk/at91.h
index c604cc6..0ce9586 100644
--- a/arch/arm/mach-at91/include/mach/at91_pmc.h
+++ b/include/linux/clk/at91.h
@@ -1,5 +1,5 @@
 /*
- * arch/arm/mach-at91/include/mach/at91_pmc.h
+ * include/linux/clk/at91.h
  *
  * Copyright (C) 2005 Ivan Kokshaysky
  * Copyright (C) SAN People
-- 
1.7.9.5



From zhangwm at marvell.com  Wed Jul 17 09:37:57 2013
From: zhangwm at marvell.com (Neil Zhang)
Date: Wed, 17 Jul 2013 06:37:57 -0700
Subject: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
In-Reply-To: <201307142129.43271.arnd@arndb.de>
References: <1373352166-10064-1-git-send-email-zhangwm@marvell.com>
 <20130710214922.GQ11908@titan.lakedaemon.net>
 <175CCF5F49938B4D99B2E3EF7F558EBE3DBC97FDFA@SC-VEXCH4.marvell.com>
 <201307142129.43271.arnd@arndb.de>
Message-ID: <175CCF5F49938B4D99B2E3EF7F558EBE3DBCDAF7C4@SC-VEXCH4.marvell.com>

Arnd

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 2013?7?15? 3:30
> To: Neil Zhang
> Cc: Jason Cooper; Matt Sealey; grant.likely at linaro.org;
> haojian.zhuang at gmail.com; devicetree-discuss at lists.ozlabs.org;
> linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
> 
> On Thursday 11 July 2013, Neil Zhang wrote:
> > > > > To do this properly, the drivers are going to have to be
> > > > > compatible with the old and the new names, and the binding docs
> > > > > updated to reflect the legacy name and the preferred name.
> > > >
> > > > Properly would be as above. You can stop using stock tickers for
> > > > new company names, but anything that has been defined in a device
> > > > tree before has to stay that way, and all the manufacturer
> > > > prefixes to device names should be the same. What you're proposing
> > > > is purely driver bloat and increasing the size of kernel.
> > >
> > > *I'm* not proposing to change the name, Neil is.  I'm proposing that
> > > iff they chose to do that, don't break sh*t along the way.
> > >
> >
> > What's your opinion?
> 
> We discussed the topic of fixing bad bindings vs. keeping backwards compatibility
> during last week's Linaro Connect.
> 
> The main outcome was that we need to have a better review for new bindings
> getting merged to avoid this situation in the future, but the general consensus
> seems that bindings that are already in use but were never reviewed properly
> (which should have caught this) should be changed.

So would you mind if I leave it there (discard this patch) and still use the current 'mvrl' prefix for this patch set.

> We will likely establish an annotation in the binding soon to mark those that can
> not be changed as opposed to those that are not considered stable yet.
> 
> 	Arnd


Best Regards,
Neil Zhang

From b.brezillon at overkiz.com  Wed Jul 17 09:40:04 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 15:40:04 +0200
Subject: [PATCH v2 02/42] ARM: at91: add PMC main clock
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374068404-13654-1-git-send-email-b.brezillon@overkiz.com>

This is the at91 main oscillator clock implementation using common
clk framework.

If rate is not provided during clock registraction it is computed using
the slow clock (main clk parent in this case) rate and the MCFR register.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/clk/at91/Makefile   |    5 ++
 drivers/clk/at91/clk-main.c |  106 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/clk/at91.h    |   10 ++++
 3 files changed, 121 insertions(+)
 create mode 100644 drivers/clk/at91/Makefile
 create mode 100644 drivers/clk/at91/clk-main.c

diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
new file mode 100644
index 0000000..42c084e
--- /dev/null
+++ b/drivers/clk/at91/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for at91 specific clk
+#
+
+obj-y += clk-main.o
diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
new file mode 100644
index 0000000..738fa39
--- /dev/null
+++ b/drivers/clk/at91/clk-main.c
@@ -0,0 +1,106 @@
+/*
+ * drivers/clk/at91/clk-main.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * This mainram is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/clk/at91.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+
+#define to_clk_main(hw) container_of(hw, struct clk_main, hw)
+struct clk_main {
+	struct clk_hw hw;
+	unsigned long rate;
+};
+
+static unsigned long clk_main_recalc_rate(struct clk_hw *hw,
+					  unsigned long parent_rate)
+{
+	u32 tmp;
+	struct clk_main *clkmain = to_clk_main(hw);
+	if (clkmain->rate)
+		return clkmain->rate;
+	while ((tmp = at91_pmc_read(AT91_CKGR_MCFR)) & AT91_PMC_MAINRDY)
+		;
+	tmp &= AT91_PMC_MAINF;
+	clkmain->rate = (tmp * parent_rate) / 16;
+	return clkmain->rate;
+}
+
+static const struct clk_ops main_ops = {
+	.recalc_rate = clk_main_recalc_rate,
+};
+
+struct clk * __init
+at91_clk_register_main(const char *name,
+		       const char *parent_name,
+		       unsigned long rate)
+{
+	struct clk_main *clkmain;
+	struct clk *clk = NULL;
+	struct clk_init_data init;
+
+	if (!rate && !parent_name)
+		return ERR_PTR(-EINVAL);
+
+	clkmain = kzalloc(sizeof(*clkmain), GFP_KERNEL);
+	if (!clkmain)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &main_ops;
+	init.parent_names = parent_name ? &parent_name : NULL;
+	init.num_parents = parent_name ? 1 : 0;
+	init.flags = parent_name ? 0 : CLK_IS_ROOT;
+
+	clkmain->hw.init = &init;
+	clkmain->rate = rate;
+
+	clk = clk_register(NULL, &clkmain->hw);
+
+	if (IS_ERR(clk))
+		kfree(clkmain);
+
+	return clk;
+}
+
+
+
+#if defined(CONFIG_OF)
+static void __init
+of_at91_clk_main_setup(struct device_node *np)
+{
+	struct clk *clk;
+	const char *parent_name;
+	const char *name = np->name;
+	u32 rate = 0;
+
+	parent_name = of_clk_get_parent_name(np, 0);
+	of_property_read_string(np, "clock-output-names", &name);
+	of_property_read_u32(np, "clock-frequency", &rate);
+
+	clk = at91_clk_register_main(name, parent_name, rate);
+
+	if (!IS_ERR(clk))
+		return;
+
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+}
+
+static void __init of_at91rm9200_clk_main_setup(struct device_node *np)
+{
+	of_at91_clk_main_setup(np);
+}
+CLK_OF_DECLARE(at91rm9200_clk_main, "atmel,at91rm9200-clk-main",
+	       of_at91rm9200_clk_main_setup);
+#endif
diff --git a/include/linux/clk/at91.h b/include/linux/clk/at91.h
index 0ce9586..8e83942 100644
--- a/include/linux/clk/at91.h
+++ b/include/linux/clk/at91.h
@@ -16,6 +16,8 @@
 #ifndef AT91_PMC_H
 #define AT91_PMC_H
 
+#include <linux/clk-provider.h>
+
 #ifndef __ASSEMBLY__
 extern void __iomem *at91_pmc_base;
 
@@ -187,4 +189,12 @@ extern void __iomem *at91_pmc_base;
 #define			AT91_PMC_PCR_DIV8	0x3			/* Peripheral clock is MCK/8 */
 #define		AT91_PMC_PCR_EN		(0x1  <<  28)		/* Enable */
 
+
+
+
+struct clk * __init
+at91_clk_register_main(const char *name,
+		       const char *parent_name,
+		       unsigned long rate);
+
 #endif
-- 
1.7.9.5



From stefano.stabellini at eu.citrix.com  Wed Jul 17 09:40:31 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 17 Jul 2013 14:40:31 +0100
Subject: [PATCH] xen/arm: enable PV control for ARM
In-Reply-To: <1373898219-15713-1-git-send-email-julien.grall@linaro.org>
References: <1373898219-15713-1-git-send-email-julien.grall@linaro.org>
Message-ID: <alpine.DEB.2.02.1307171435000.8258@kaball.uk.xensource.com>

On Mon, 15 Jul 2013, Julien Grall wrote:
> Enable power management from the toolstack for ARM guest.
> 
> Signed-off-by: Julien Grall <julien.grall at linaro.org>

Considering that now we support both ARM and ARM64, could you please
add an ifneq ($(CONFIG_ARM64),y) too around cpu_hotplug.o, since you are
at it?


>  drivers/xen/Makefile |    3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 2bf461a..a5f12bd 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -1,9 +1,8 @@
>  ifneq ($(CONFIG_ARM),y)
> -obj-y	+= manage.o
>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>  endif
>  obj-$(CONFIG_X86)			+= fallback.o
> -obj-y	+= grant-table.o features.o events.o balloon.o time.o
> +obj-y	+= grant-table.o features.o events.o balloon.o time.o manage.o
>  obj-y	+= xenbus/
>  
>  nostackp := $(call cc-option, -fno-stack-protector)
> -- 
> 1.7.10.4
> 


From juha.lumme at gmail.com  Wed Jul 17 09:42:26 2013
From: juha.lumme at gmail.com (Juha Lumme)
Date: Wed, 17 Jul 2013 22:42:26 +0900
Subject: Can't get FIQ interrupt to work on i.mx233
In-Reply-To: <20130716161643.GB3428@localhost.localdomain>
References: <CAF-Ht3z3GQLwEWoB+UgOGepHfMFUD7pTRHfYWR9Ynk3rM4dD=Q@mail.gmail.com>
 <20130716081132.GB24642@n2100.arm.linux.org.uk> <51E5322B.8080602@gmail.com>
 <20130716161643.GB3428@localhost.localdomain>
Message-ID: <51E69F42.2060106@gmail.com>

Hi Dave,

Thanks for the idea, that's indeed a dead simple way to find out.
Being sure that I will get stuck in FIQ handler, I started experimenting 
different things, and it seems that if instead of calling 
mxs_icoll_set_irq_fiq(31) (which only sets FIQ bit), I directly set bits 
4 (FIQ) and 2 (ENABLE) in HW_ICOLL_INTERRUPT31 register, my interrupt 
starts working as expected. Maybe I can also leave enable_fiq out this way.

So it currently seems like mxs_icoll_set_irq_fiq (which I patched in) 
and enable_fiq (already there) are not working as expected currently in 
freescale's mainline 3.10.
I will try to find out the reason, and create patches for this - but if 
you have any pointers on what might help me on a right path, I would 
appreciate it.

Anyway, thanks for helping me this far already,
Juha

On 07/17/2013 01:16 AM, Dave Martin wrote:
> On Tue, Jul 16, 2013 at 08:44:43PM +0900, Juha Lumme wrote:
>> Hi Russel,
>>
>> Thanks for your reply.
>> And thanks for pointing out the wrong instruction there with the ldr
>> instruction.
>>
>> However, unfortunately the code still doesn't seem to trigger
>> anything (neither to clear the IRQ bit in the timer, nor the GPIO
>> output).. It seems to me as if the handler never gets called. Is
>> there a good way to confirm that any activity is actually triggered
>> when timer3 reaches 0, and the IRQ bit is set to 1 ?
>>
> A brutal, but simple, way to confirm that your handler is being called
> is to try putting an infinite loop in there:
>
> 	b	.
>
> If your board then locks up, the handler is almost certainly getting
> called.
>
> Cheers
> ---Dave



From b.brezillon at overkiz.com  Wed Jul 17 09:42:57 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 15:42:57 +0200
Subject: [PATCH v2 03/42] ARM: at91: add PMC pll clocks
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374068578-13740-1-git-send-email-b.brezillon@overkiz.com>

This is the at91 pll clock implementation using common clk framework.

The pll clock layout describe the PLLX register layout.
There's four pll clock layouts:
- at91rm9200
- at91sam9g20
- at91sam9g45
- sama5d3

PLL clocks are given characteristics:
- min/max clock source rate
- ranges of valid clock output rates
- values to set in out and icpll fields for each supported output range

These characteristics are checked during rate change to avoid
over/underclocking.

These characteristics are described in atmel's SoC datasheet in
"Electrical Characteristics" paragraph.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/clk/at91/Makefile     |    2 +-
 drivers/clk/at91/clk-pll.c    |  438 +++++++++++++++++++++++++++++++++++++++++
 drivers/clk/at91/clk-plldiv.c |  125 ++++++++++++
 include/linux/clk/at91.h      |   39 ++++
 4 files changed, 603 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/at91/clk-pll.c
 create mode 100644 drivers/clk/at91/clk-plldiv.c

diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 42c084e..564076f 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -2,4 +2,4 @@
 # Makefile for at91 specific clk
 #
 
-obj-y += clk-main.o
+obj-y += clk-main.o clk-pll.o clk-plldiv.o
diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c
new file mode 100644
index 0000000..e9390e2
--- /dev/null
+++ b/drivers/clk/at91/clk-pll.c
@@ -0,0 +1,438 @@
+/*
+ * drivers/clk/at91/clk-pll.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * This pllram is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/clk/at91.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+
+#define to_clk_pll(hw) container_of(hw, struct clk_pll, hw)
+
+struct clk_pll {
+	struct clk_hw hw;
+	u8 id;
+	u8 div;
+	u8 range;
+	u16 mul;
+	struct clk_pll_layout *layout;
+	struct clk_pll_characteristics *characteristics;
+};
+
+static int clk_pll_prepare(struct clk_hw *hw)
+{
+	struct clk_pll *pll = to_clk_pll(hw);
+	while (!(at91_pmc_read(AT91_PMC_SR) &
+		 (1 << (1 + pll->id))))
+		;
+	return 0;
+}
+
+static int clk_pll_is_prepared(struct clk_hw *hw)
+{
+	struct clk_pll *pll = to_clk_pll(hw);
+	return !!(at91_pmc_read(AT91_PMC_SR) &
+		  (1 << (1 + pll->id)));
+}
+
+static int clk_pll_enable(struct clk_hw *hw)
+{
+	return 0;
+}
+
+static void clk_pll_disable(struct clk_hw *hw)
+{
+	struct clk_pll *pll = to_clk_pll(hw);
+	struct clk_pll_layout *layout = pll->layout;
+	int offset = AT91_CKGR_PLLAR + (pll->id * 4);
+	u32 tmp = at91_pmc_read(offset) & ~(layout->pllr_mask);
+	at91_pmc_write(offset, tmp);
+}
+
+static int clk_pll_is_enabled(struct clk_hw *hw)
+{
+	struct clk_pll *pll = to_clk_pll(hw);
+	return !!(at91_pmc_read(AT91_PMC_SR) &
+		  (1 << (1 + pll->id)));
+}
+
+static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
+					 unsigned long parent_rate)
+{
+	struct clk_pll *pll = to_clk_pll(hw);
+	struct clk_pll_layout *layout = pll->layout;
+	int offset = AT91_CKGR_PLLAR + (pll->id * 4);
+	u32 tmp = at91_pmc_read(offset) & layout->pllr_mask;
+	u8 div = tmp & 0xFF;
+	u16 mul = (tmp >> layout->mul_shift) & layout->mul_mask;
+	if (!div || !mul)
+		return 0;
+
+	return (parent_rate * (mul + 1)) / div;
+}
+
+static long clk_pll_get_best_div_mul(struct clk_pll *pll, unsigned long rate,
+				     unsigned long parent_rate,
+				     u32 *div, u32 *mul,
+				     u32 *index) {
+	unsigned long maxrate;
+	unsigned long minrate;
+	unsigned long divrate;
+	unsigned long bestdiv = 1;
+	unsigned long bestmul;
+	unsigned long tmpdiv;
+	unsigned long roundup;
+	unsigned long rounddown;
+	unsigned long remainder;
+	unsigned long bestremainder;
+	unsigned long maxmul;
+	unsigned long maxdiv;
+	unsigned long mindiv;
+	int i = 0;
+	struct clk_pll_layout *layout = pll->layout;
+	struct clk_pll_characteristics *characteristics = pll->characteristics;
+
+	/* Minimum divider = 1 */
+	/* Maximum multiplier = max_mul */
+	maxmul = layout->mul_mask + 1;
+	maxrate = (parent_rate * maxmul) / 1;
+
+	/* Maximum divider = max_div */
+	/* Minimum multiplier = 2 */
+	maxdiv = 0xFF;
+	minrate = (parent_rate * 2) / maxdiv;
+
+	if (parent_rate < characteristics->input.min ||
+	    parent_rate < characteristics->input.max)
+		return -ERANGE;
+
+	if (parent_rate < minrate || parent_rate > maxrate)
+		return -ERANGE;
+
+	for (i = 0; i < characteristics->num_output; ++i) {
+		if (parent_rate >= characteristics->output[i].min &&
+		    parent_rate <= characteristics->output[i].max)
+			break;
+		++i;
+	}
+
+	if (i >= characteristics->num_output)
+		return -ERANGE;
+
+	bestmul = rate / parent_rate;
+	rounddown = parent_rate % rate;
+	roundup = rate - rounddown;
+	bestremainder = roundup < rounddown ? roundup : rounddown;
+
+	if (!bestremainder) {
+		if (div)
+			*div = bestdiv;
+		if (mul)
+			*mul = bestmul;
+		if (index)
+			*index = i;
+		return rate;
+	}
+
+	maxdiv = 255 / (bestmul + 1);
+	if (parent_rate / maxdiv < characteristics->input.min)
+		maxdiv = parent_rate / characteristics->input.min;
+	mindiv = parent_rate / characteristics->input.max;
+	if (parent_rate % characteristics->input.max)
+		mindiv++;
+
+	for (tmpdiv = mindiv; tmpdiv < maxdiv; tmpdiv++) {
+		divrate = parent_rate / tmpdiv;
+
+		rounddown = rate % divrate;
+		roundup = divrate - rounddown;
+		remainder = roundup < rounddown ? roundup : rounddown;
+
+		if (remainder < bestremainder) {
+			bestremainder = remainder;
+			bestmul = rate / divrate;
+			bestdiv = tmpdiv;
+		}
+
+		if (!remainder)
+			break;
+	}
+
+	rate = (parent_rate / bestdiv) * bestmul;
+
+	if (div)
+		*div = bestdiv;
+	if (mul)
+		*mul = bestmul;
+	if (index)
+		*index = i;
+
+	return rate;
+}
+
+static long clk_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+					unsigned long *parent_rate)
+{
+	struct clk_pll *pll = to_clk_pll(hw);
+	return clk_pll_get_best_div_mul(pll, rate, *parent_rate,
+					NULL, NULL, NULL);
+
+}
+
+static int clk_pll_set_rate(struct clk_hw *hw, unsigned long rate,
+			    unsigned long parent_rate)
+{
+	struct clk_pll *pll = to_clk_pll(hw);
+	struct clk_pll_layout *layout = pll->layout;
+	struct clk_pll_characteristics *characteristics = pll->characteristics;
+	int offset = AT91_CKGR_PLLAR + (pll->id * 4);
+	long ret;
+	u32 div;
+	u32 mul;
+	u32 index;
+	u32 tmp;
+	u8 out = 0;
+	ret = clk_pll_get_best_div_mul(pll, rate, parent_rate,
+				       &div, &mul, &index);
+
+	if (ret < 0)
+		return ret;
+
+	if (characteristics->out)
+		out = characteristics->out[pll->range];
+	if (characteristics->icpll) {
+		tmp = at91_pmc_read(AT91_PMC_PLLICPR) &
+		      ~(0xFFFF << (16 * pll->id));
+		tmp |= characteristics->icpll[pll->range] << (16 * pll->id);
+		at91_pmc_write(AT91_PMC_PLLICPR, tmp);
+	}
+	tmp = at91_pmc_read(offset) & ~(layout->pllr_mask);
+	tmp |= layout->pllr_mask & (div | 0x3F << 8 | out << 14 |
+				    (mul & layout->mul_mask) <<
+				    layout->mul_shift);
+	at91_pmc_write(offset, tmp);
+
+	return 0;
+}
+
+static const struct clk_ops pll_ops = {
+	.prepare = clk_pll_prepare,
+	.is_prepared = clk_pll_is_prepared,
+	.enable = clk_pll_enable,
+	.disable = clk_pll_disable,
+	.is_enabled = clk_pll_is_enabled,
+	.recalc_rate = clk_pll_recalc_rate,
+	.round_rate = clk_pll_round_rate,
+	.set_rate = clk_pll_set_rate,
+};
+
+struct clk * __init
+at91_clk_register_pll(const char *name, const char *parent_name, u8 id,
+		      struct clk_pll_layout *layout,
+		      struct clk_pll_characteristics *characteristics)
+{
+	struct clk_pll *pll;
+	struct clk *clk = NULL;
+	struct clk_init_data init;
+
+	id &= 3;
+
+	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+	if (!pll)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &pll_ops;
+	init.parent_names = parent_name ? &parent_name : NULL;
+	init.num_parents = parent_name ? 1 : 0;
+	init.flags = CLK_SET_RATE_GATE;
+
+	pll->id = id;
+	pll->hw.init = &init;
+	pll->layout = layout;
+	pll->characteristics = characteristics;
+
+	clk = clk_register(NULL, &pll->hw);
+
+	if (IS_ERR(clk))
+		kfree(pll);
+
+	return clk;
+}
+
+
+struct clk_pll_layout at91rm9200_pll_layout = {
+	.pllr_mask = 0x7FFFFFF,
+	.mul_shift = 16,
+	.mul_mask = 0x7FF,
+};
+
+struct clk_pll_layout at91sam9g45_pll_layout = {
+	.pllr_mask = 0xFFFFFF,
+	.mul_shift = 16,
+	.mul_mask = 0xFF,
+};
+
+struct clk_pll_layout at91sam9g20_pllb_layout = {
+	.pllr_mask = 0x3FFFFF,
+	.mul_shift = 16,
+	.mul_mask = 0x3F,
+};
+
+struct clk_pll_layout sama5d3_pll_layout = {
+	.pllr_mask = 0x1FFFFFF,
+	.mul_shift = 18,
+	.mul_mask = 0x7F,
+};
+
+
+#if defined(CONFIG_OF)
+static struct clk_pll_characteristics * __init
+of_at91_clk_pll_get_characteristics(struct device_node *np)
+{
+	int i;
+	u32 tmp;
+	int num_output;
+	struct clk_range *output = NULL;
+	u8 *out = NULL;
+	u16 *icpll = NULL;
+	struct clk_pll_characteristics *characteristics = NULL;
+	characteristics = kzalloc(sizeof(*characteristics), GFP_KERNEL);
+	if (!characteristics)
+		return NULL;
+
+	if (of_property_read_u32_index(np, "input", 0, &tmp))
+		goto out_free_characteristics;
+
+	characteristics->input.min = tmp;
+
+	if (of_property_read_u32_index(np, "input", 1, &tmp))
+		goto out_free_characteristics;
+
+	characteristics->input.max = tmp;
+
+	if (!of_get_property(np, "output", &num_output))
+		goto out_free_characteristics;
+	num_output /= (sizeof(u32) * 2);
+
+	output = kzalloc(sizeof(*output) * num_output, GFP_KERNEL);
+	for (i = 0; i < num_output; i++) {
+		if (of_property_read_u32_index(np, "output", i * 2, &tmp))
+			goto out_free_output;
+		output[i].min = tmp;
+		if (of_property_read_u32_index(np, "output", (i * 2) + 1, &tmp))
+			goto out_free_output;
+		output[i].max = tmp;
+	}
+
+	if (of_get_property(np, "out", NULL)) {
+		out = kzalloc(sizeof(*out) * num_output, GFP_KERNEL);
+		if (!out)
+			goto out_free_output;
+		for (i = 0; i < num_output; i++) {
+			if (of_property_read_u32_index(np, "out", i, &tmp))
+				goto out_free_out;
+			out[i] = tmp;
+		}
+	}
+
+	if (of_get_property(np, "icpll", NULL)) {
+		icpll = kzalloc(sizeof(*icpll) * num_output, GFP_KERNEL);
+		if (!icpll)
+			goto out_free_out;
+		for (i = 0; i < num_output; i++) {
+			if (of_property_read_u32_index(np, "icpll", i, &tmp))
+				goto out_free_icpll;
+			icpll[i] = tmp;
+		}
+	}
+
+	characteristics->num_output = num_output;
+	characteristics->output = output;
+	characteristics->out = out;
+	characteristics->icpll = icpll;
+	return characteristics;
+
+out_free_icpll:
+	kfree(icpll);
+out_free_out:
+	kfree(out);
+out_free_output:
+	kfree(output);
+out_free_characteristics:
+	kfree(characteristics);
+	return NULL;
+}
+
+static void __init
+of_at91_clk_pll_setup(struct device_node *np,
+		      struct clk_pll_layout *layout)
+{
+	u32 id;
+	struct clk *clk;
+	const char *parent_name;
+	const char *name = np->name;
+	struct clk_pll_characteristics *characteristics;
+
+	if (of_property_read_u32(np, "id", &id))
+		return;
+
+	parent_name = of_clk_get_parent_name(np, 0);
+
+	of_property_read_string(np, "clock-output-names", &name);
+
+	characteristics = of_at91_clk_pll_get_characteristics(np);
+	if (!characteristics)
+		return;
+
+	clk = at91_clk_register_pll(name, parent_name, id, layout,
+				    characteristics);
+
+	if (IS_ERR(clk))
+		goto out_free_characteristics;
+
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	return;
+
+out_free_characteristics:
+	kfree(characteristics);
+}
+
+static void __init of_at91rm9200_clk_pll_setup(struct device_node *np)
+{
+	of_at91_clk_pll_setup(np, &at91rm9200_pll_layout);
+}
+CLK_OF_DECLARE(at91rm9200_clk_pll, "atmel,at91rm9200-clk-pll",
+	       of_at91rm9200_clk_pll_setup);
+
+static void __init of_at91sam9g45_clk_pll_setup(struct device_node *np)
+{
+	of_at91_clk_pll_setup(np, &at91sam9g45_pll_layout);
+}
+CLK_OF_DECLARE(at91sam9g45_clk_pll, "atmel,at91sam9g45-clk-pll",
+	       of_at91sam9g45_clk_pll_setup);
+
+static void __init of_at91sam9g20_clk_pllb_setup(struct device_node *np)
+{
+	of_at91_clk_pll_setup(np, &at91sam9g20_pllb_layout);
+}
+CLK_OF_DECLARE(at91sam9g20_clk_pllb, "atmel,at91sam9g20-clk-pllb",
+	       of_at91sam9g20_clk_pllb_setup);
+
+static void __init of_sama5d3_clk_pll_setup(struct device_node *np)
+{
+	of_at91_clk_pll_setup(np, &sama5d3_pll_layout);
+}
+CLK_OF_DECLARE(sama5d3_clk_pll, "atmel,sama5d3-clk-pll",
+	       of_sama5d3_clk_pll_setup);
+#endif
diff --git a/drivers/clk/at91/clk-plldiv.c b/drivers/clk/at91/clk-plldiv.c
new file mode 100644
index 0000000..430de9b
--- /dev/null
+++ b/drivers/clk/at91/clk-plldiv.c
@@ -0,0 +1,125 @@
+/*
+ * drivers/clk/at91/clk-plldiv.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * This plldivram is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/clk/at91.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+
+#define to_clk_plldiv(hw) container_of(hw, struct clk_plldiv, hw)
+
+struct clk_plldiv {
+	struct clk_hw hw;
+};
+
+static unsigned long clk_plldiv_recalc_rate(struct clk_hw *hw,
+					    unsigned long parent_rate)
+{
+	if (at91_pmc_read(AT91_PMC_MCKR) & AT91_PMC_PLLADIV2)
+		return parent_rate / 2;
+	return parent_rate;
+}
+
+static long clk_plldiv_round_rate(struct clk_hw *hw, unsigned long rate,
+					unsigned long *parent_rate)
+{
+	unsigned long div;
+	if (rate > *parent_rate)
+		return *parent_rate;
+	div = *parent_rate / 2;
+	if (rate < div)
+		return div;
+
+	if (rate - div < *parent_rate - rate)
+		return div;
+
+	return *parent_rate;
+}
+
+static int clk_plldiv_set_rate(struct clk_hw *hw, unsigned long rate,
+			       unsigned long parent_rate)
+{
+	u32 tmp;
+	if (parent_rate != rate && (parent_rate / 2) != rate)
+		return -EINVAL;
+
+	tmp = at91_pmc_read(AT91_PMC_MCKR) & ~AT91_PMC_PLLADIV2;
+	if ((parent_rate / 2) == rate)
+		tmp |= AT91_PMC_PLLADIV2;
+	at91_pmc_write(AT91_PMC_MCKR, tmp);
+
+	return 0;
+}
+
+static const struct clk_ops plldiv_ops = {
+	.recalc_rate = clk_plldiv_recalc_rate,
+	.round_rate = clk_plldiv_round_rate,
+	.set_rate = clk_plldiv_set_rate,
+};
+
+struct clk * __init
+at91_clk_register_plldiv(const char *name, const char *parent_name)
+{
+	struct clk_plldiv *plldiv;
+	struct clk *clk = NULL;
+	struct clk_init_data init;
+
+	plldiv = kzalloc(sizeof(*plldiv), GFP_KERNEL);
+	if (!plldiv)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &plldiv_ops;
+	init.parent_names = parent_name ? &parent_name : NULL;
+	init.num_parents = parent_name ? 1 : 0;
+	init.flags = CLK_SET_RATE_GATE;
+
+	plldiv->hw.init = &init;
+
+	clk = clk_register(NULL, &plldiv->hw);
+
+	if (IS_ERR(clk))
+		kfree(plldiv);
+
+	return clk;
+}
+
+#if defined(CONFIG_OF)
+static void __init
+of_at91_clk_plldiv_setup(struct device_node *np)
+{
+	struct clk *clk;
+	const char *parent_name;
+	const char *name = np->name;
+
+	parent_name = of_clk_get_parent_name(np, 0);
+
+	of_property_read_string(np, "clock-output-names", &name);
+
+	clk = at91_clk_register_plldiv(name, parent_name);
+
+	if (IS_ERR(clk))
+		return;
+
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	return;
+}
+
+static void __init of_at91sam9x5_clk_plldiv_setup(struct device_node *np)
+{
+	of_at91_clk_plldiv_setup(np);
+}
+CLK_OF_DECLARE(at91sam9x5_clk_plldiv, "atmel,at91sam9x5-clk-plldiv",
+	       of_at91sam9x5_clk_plldiv_setup);
+#endif
diff --git a/include/linux/clk/at91.h b/include/linux/clk/at91.h
index 8e83942..51b7134 100644
--- a/include/linux/clk/at91.h
+++ b/include/linux/clk/at91.h
@@ -166,6 +166,8 @@ extern void __iomem *at91_pmc_base;
 #define		AT91_PMC_CFDEV		(1 << 18)		/* Clock Failure Detector Event [some SAM9] */
 #define	AT91_PMC_IMR		0x6c			/* Interrupt Mask Register */
 
+#define AT91_PMC_PLLICPR	0x80			/* PLL Charge Pump Current Register */
+
 #define AT91_PMC_PROT		0xe4			/* Write Protect Mode Register [some SAM9] */
 #define		AT91_PMC_WPEN		(0x1  <<  0)		/* Write Protect Enable */
 #define		AT91_PMC_WPKEY		(0xffffff << 8)		/* Write Protect Key */
@@ -190,6 +192,26 @@ extern void __iomem *at91_pmc_base;
 #define		AT91_PMC_PCR_EN		(0x1  <<  28)		/* Enable */
 
 
+struct clk_range {
+	unsigned long min;
+	unsigned long max;
+};
+
+#define CLK_RANGE(MIN, MAX) {.min = MIN, .max = MAX,}
+
+struct clk_pll_characteristics {
+	struct clk_range input;
+	int num_output;
+	struct clk_range *output;
+	u16 *icpll;
+	u8 *out;
+};
+
+struct clk_pll_layout {
+	u32 pllr_mask;
+	u16 mul_mask;
+	u8 mul_shift;
+};
 
 
 struct clk * __init
@@ -197,4 +219,21 @@ at91_clk_register_main(const char *name,
 		       const char *parent_name,
 		       unsigned long rate);
 
+
+extern struct clk_pll_layout at91rm9200_pll_layout;
+
+extern struct clk_pll_layout at91sam9g45_pll_layout;
+
+extern struct clk_pll_layout at91sam9g20_pllb_layout;
+
+extern struct clk_pll_layout sama5d3_pll_layout;
+
+struct clk * __init
+at91_clk_register_pll(const char *name, const char *parent_name, u8 id,
+		      struct clk_pll_layout *layout,
+		      struct clk_pll_characteristics *characteristics);
+
+struct clk * __init
+at91_clk_register_plldiv(const char *name, const char *parent_name);
+
 #endif
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 09:44:33 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 15:44:33 +0200
Subject: [PATCH v2 04/42] ARM: at91: add PMC master clock
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374068673-13818-1-git-send-email-b.brezillon@overkiz.com>

This is the at91 master clock implementation using common clk framework.

The pll clock layout describe the MCKR register layout.
There's four pll clock layouts:
- at91rm9200
- at91sam9x5

Master clocks are given characteristics:
- min/max clock output rate

These characteristics are checked during rate change to avoid
over/underclocking.

These characteristics are described in atmel's SoC datasheet in
"Electrical Characteristics" paragraph.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/clk/at91/Makefile     |    2 +-
 drivers/clk/at91/clk-master.c |  317 +++++++++++++++++++++++++++++++++++++++++
 include/linux/clk/at91.h      |   23 +++
 3 files changed, 341 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/at91/clk-master.c

diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 564076f..d41f616 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -2,4 +2,4 @@
 # Makefile for at91 specific clk
 #
 
-obj-y += clk-main.o clk-pll.o clk-plldiv.o
+obj-y += clk-main.o clk-pll.o clk-plldiv.o clk-master.o
diff --git a/drivers/clk/at91/clk-master.c b/drivers/clk/at91/clk-master.c
new file mode 100644
index 0000000..71ade7d
--- /dev/null
+++ b/drivers/clk/at91/clk-master.c
@@ -0,0 +1,317 @@
+/*
+ * drivers/clk/at91/clk-master.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * This masterram is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/clk/at91.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+
+#define MASTER_SOURCE_MAX	4
+
+#define to_clk_master(hw) container_of(hw, struct clk_master, hw)
+
+struct clk_master {
+	struct clk_hw hw;
+	struct clk_master_layout *layout;
+	struct clk_master_characteristics *characteristics;
+};
+
+static unsigned long clk_master_recalc_rate(struct clk_hw *hw,
+					    unsigned long parent_rate)
+{
+	u8 pres;
+	u8 div;
+	unsigned long rate = parent_rate;
+	struct clk_master *master = to_clk_master(hw);
+	struct clk_master_layout *layout = master->layout;
+	struct clk_master_characteristics *characteristics =
+						master->characteristics;
+	u32 tmp = at91_pmc_read(AT91_PMC_MCKR) & layout->mask;
+
+	pres = (tmp >> layout->pres_shift) & 0x7;
+	div = (tmp >> 8) & 0x3;
+
+	if (characteristics->have_div3_pres && pres == 7)
+		rate /= 3;
+	else
+		rate >>= pres;
+
+	rate /= characteristics->divisors[div];
+
+	/* print overclocking or underclocking error */
+	/*
+	if (rate < characteristics->output.min ||
+	    rate > characteristics->output.max) {
+	}
+	*/
+	return rate;
+}
+
+static long clk_master_round_rate(struct clk_hw *hw, unsigned long rate,
+				  unsigned long *parent_rate)
+{
+	int mdiv;
+	int pres;
+	u32 div;
+	long best_rate = -EINVAL;
+	unsigned long best_diff = 0;
+	unsigned long cur_diff;
+	unsigned long pres_rate;
+	unsigned long cur_rate;
+	struct clk_master *master = to_clk_master(hw);
+	struct clk_master_characteristics *characteristics =
+						master->characteristics;
+
+	if (rate < characteristics->output.min ||
+	    rate > characteristics->output.max)
+		return -EINVAL;
+
+	for (pres = 0; pres < 7; pres++) {
+		if (pres < 7)
+			pres_rate = *parent_rate >> pres;
+		else {
+			if (!characteristics->have_div3_pres)
+				break;
+			pres_rate = *parent_rate / 3;
+		}
+		for (mdiv = 0; mdiv < 4; mdiv++) {
+			div = characteristics->divisors[mdiv];
+			if (!div)
+				continue;
+			cur_rate = pres_rate / div;
+			if (rate < cur_rate)
+				cur_diff = cur_rate - rate;
+			else
+				cur_diff = rate - cur_rate;
+
+			if (best_rate < 0 || cur_diff < best_diff) {
+				best_rate = cur_rate;
+				best_diff = cur_diff;
+				if (!best_diff)
+					return best_rate;
+			}
+		}
+	}
+
+	return best_rate;
+}
+
+static int clk_master_set_parent(struct clk_hw *hw, u8 index)
+{
+	u32 tmp;
+	if (index > AT91_PMC_CSS)
+		return -EINVAL;
+	tmp = at91_pmc_read(AT91_PMC_MCKR) & ~AT91_PMC_CSS;
+	tmp |= index;
+
+	at91_pmc_write(AT91_PMC_MCKR, tmp);
+	while (!(at91_pmc_read(AT91_PMC_SR) & AT91_PMC_MCKRDY))
+		;
+	return 0;
+}
+
+static u8 clk_master_get_parent(struct clk_hw *hw)
+{
+	return at91_pmc_read(AT91_PMC_MCKR) & AT91_PMC_CSS;
+}
+
+static int clk_master_set_rate(struct clk_hw *hw, unsigned long rate,
+			       unsigned long parent_rate)
+{
+	int mdiv;
+	int pres;
+	u32 div;
+	u32 tmp;
+	unsigned long cur_rate;
+	unsigned long pres_rate;
+	struct clk_master *master = to_clk_master(hw);
+	struct clk_master_layout *layout = master->layout;
+	struct clk_master_characteristics *characteristics =
+						master->characteristics;
+	for (pres = 0; pres < 7; pres++) {
+		if (pres < 7)
+			pres_rate = parent_rate >> pres;
+		else {
+			if (!characteristics->have_div3_pres)
+				break;
+			pres_rate = parent_rate / 3;
+		}
+		for (mdiv = 0; mdiv < 4; mdiv++) {
+			div = characteristics->divisors[mdiv];
+			if (!div)
+				continue;
+			cur_rate = pres_rate / div;
+			if (cur_rate == rate) {
+				tmp = at91_pmc_read(AT91_PMC_MCKR);
+				tmp &= layout->mask;
+				tmp &= ~AT91_PMC_CSS;
+				tmp |= pres << layout->pres_shift | mdiv << 8;
+
+				at91_pmc_write(AT91_PMC_MCKR, tmp);
+				while (!(at91_pmc_read(AT91_PMC_SR) &
+					 AT91_PMC_MCKRDY))
+					;
+				return 0;
+			}
+		}
+	}
+
+	return -EINVAL;
+}
+
+static const struct clk_ops master_ops = {
+	.recalc_rate = clk_master_recalc_rate,
+	.round_rate = clk_master_round_rate,
+	.get_parent = clk_master_get_parent,
+	.set_parent = clk_master_set_parent,
+	.set_rate = clk_master_set_rate,
+};
+
+struct clk * __init
+at91_clk_register_master(const char *name,
+			 int num_parents,
+			 const char **parent_names,
+			 struct clk_master_layout *layout,
+			 struct clk_master_characteristics *characteristics)
+{
+	struct clk_master *master;
+	struct clk *clk = NULL;
+	struct clk_init_data init;
+
+	master = kzalloc(sizeof(*master), GFP_KERNEL);
+	if (!master)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &master_ops;
+	init.parent_names = parent_names;
+	init.num_parents = num_parents;
+	init.flags = CLK_SET_RATE_GATE | CLK_SET_PARENT_GATE;
+
+	master->hw.init = &init;
+	master->layout = layout;
+	master->characteristics = characteristics;
+
+	clk = clk_register(NULL, &master->hw);
+
+	if (IS_ERR(clk))
+		kfree(master);
+
+	return clk;
+}
+
+
+struct clk_master_layout at91rm9200_master_layout = {
+	.mask = 0x31F,
+	.pres_shift = 2,
+};
+
+struct clk_master_layout at91sam9x5_master_layout = {
+	.mask = 0x373,
+	.pres_shift = 4,
+};
+
+
+#if defined(CONFIG_OF)
+static struct clk_master_characteristics * __init
+of_at91_clk_master_get_characteristics(struct device_node *np)
+{
+	int i;
+	u32 tmp;
+	struct clk_master_characteristics *characteristics = NULL;
+
+	characteristics = kzalloc(sizeof(*characteristics), GFP_KERNEL);
+	if (!characteristics)
+		return NULL;
+
+	if (of_property_read_u32_index(np, "output", 0, &tmp))
+		goto out_free_characteristics;
+
+	characteristics->output.min = tmp;
+
+	if (of_property_read_u32_index(np, "output", 1, &tmp))
+		goto out_free_characteristics;
+
+	characteristics->output.max = tmp;
+
+	for (i = 0; i < 4; i++) {
+		tmp = 0;
+		of_property_read_u32_index(np, "divisors", i, &tmp);
+		characteristics->divisors[i] = tmp;
+	}
+
+	characteristics->have_div3_pres =
+		of_property_read_bool(np, "have-div3-pres");
+
+	return characteristics;
+
+out_free_characteristics:
+	kfree(characteristics);
+	return NULL;
+}
+
+static void __init
+of_at91_clk_master_setup(struct device_node *np,
+			 struct clk_master_layout *layout)
+{
+	struct clk *clk;
+	int num_parents;
+	int i;
+	const char *parent_names[MASTER_SOURCE_MAX];
+	const char *name = np->name;
+	struct clk_master_characteristics *characteristics;
+
+	num_parents = of_count_phandle_with_args(np, "clocks", "#clock-cells");
+	if (num_parents <= 0 || num_parents > MASTER_SOURCE_MAX)
+		return;
+
+	for (i = 0; i < num_parents; ++i) {
+		parent_names[i] = of_clk_get_parent_name(np, i);
+		if (!parent_names[i])
+			return;
+	}
+
+	of_property_read_string(np, "clock-output-names", &name);
+
+	characteristics = of_at91_clk_master_get_characteristics(np);
+	if (!characteristics)
+		return;
+
+	clk = at91_clk_register_master(name, num_parents, parent_names,
+				       layout, characteristics);
+
+	if (IS_ERR(clk))
+		goto out_free_characteristics;
+
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	return;
+
+out_free_characteristics:
+	kfree(characteristics);
+}
+
+static void __init of_at91rm9200_clk_master_setup(struct device_node *np)
+{
+	of_at91_clk_master_setup(np, &at91rm9200_master_layout);
+}
+CLK_OF_DECLARE(at91rm9200_clk_master, "atmel,at91rm9200-clk-master",
+	       of_at91rm9200_clk_master_setup);
+
+static void __init of_at91sam9x5_clk_master_setup(struct device_node *np)
+{
+	of_at91_clk_master_setup(np, &at91sam9x5_master_layout);
+}
+CLK_OF_DECLARE(at91sam9x5_clk_master, "atmel,at91sam9x5-clk-master",
+	       of_at91sam9x5_clk_master_setup);
+#endif
diff --git a/include/linux/clk/at91.h b/include/linux/clk/at91.h
index 51b7134..324134c 100644
--- a/include/linux/clk/at91.h
+++ b/include/linux/clk/at91.h
@@ -213,6 +213,17 @@ struct clk_pll_layout {
 	u8 mul_shift;
 };
 
+struct clk_master_characteristics {
+	struct clk_range output;
+	u32 divisors[4];
+	u8 have_div3_pres;
+};
+
+struct clk_master_layout {
+	u32 mask;
+	u8 pres_shift;
+};
+
 
 struct clk * __init
 at91_clk_register_main(const char *name,
@@ -236,4 +247,16 @@ at91_clk_register_pll(const char *name, const char *parent_name, u8 id,
 struct clk * __init
 at91_clk_register_plldiv(const char *name, const char *parent_name);
 
+
+extern struct clk_master_layout at91rm9200_master_layout;
+
+extern struct clk_master_layout at91sam9x5_master_layout;
+
+struct clk * __init
+at91_clk_register_master(const char *name, int num_parents,
+			 const char **parent_names,
+			 struct clk_master_layout *layout,
+			 struct clk_master_characteristics *characteristics);
+
+
 #endif
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 09:45:31 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 15:45:31 +0200
Subject: [PATCH v2 05/42] ARM: at91: add PMC system clocks
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374068732-13894-1-git-send-email-b.brezillon@overkiz.com>

This is the at91 system clock implementation using common clk framework.

Some peripheral needs to enable a "system" clock in order to work properly.
Each system clock is given an id which is the bit offset used in SCER/SCDR
registers.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/clk/at91/Makefile     |    1 +
 drivers/clk/at91/clk-system.c |  184 +++++++++++++++++++++++++++++++++++++++++
 include/linux/clk/at91.h      |    3 +
 3 files changed, 188 insertions(+)
 create mode 100644 drivers/clk/at91/clk-system.c

diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index d41f616..13e5714 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-y += clk-main.o clk-pll.o clk-plldiv.o clk-master.o
+obj-y += clk-system.o
diff --git a/drivers/clk/at91/clk-system.c b/drivers/clk/at91/clk-system.c
new file mode 100644
index 0000000..17e092a
--- /dev/null
+++ b/drivers/clk/at91/clk-system.c
@@ -0,0 +1,184 @@
+/*
+ * drivers/clk/at91/clk-system.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/clk/at91.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+
+#define SYSTEM_MAX		32
+
+#define to_clk_system(hw) container_of(hw, struct clk_system, hw)
+struct clk_system {
+	struct clk_hw hw;
+	u8 id;
+};
+
+static int clk_system_enable(struct clk_hw *hw)
+{
+	struct clk_system *sys = to_clk_system(hw);
+	at91_pmc_write(AT91_PMC_SCER, 1 << sys->id);
+	return 0;
+}
+
+static void clk_system_disable(struct clk_hw *hw)
+{
+	struct clk_system *sys = to_clk_system(hw);
+	at91_pmc_write(AT91_PMC_SCDR, 1 << sys->id);
+}
+
+static int clk_system_is_enabled(struct clk_hw *hw)
+{
+	struct clk_system *sys = to_clk_system(hw);
+	return !!(at91_pmc_read(AT91_PMC_SCSR) & (1 << sys->id));
+}
+
+static const struct clk_ops system_ops = {
+	.enable = clk_system_enable,
+	.disable = clk_system_disable,
+	.is_enabled = clk_system_is_enabled,
+};
+
+struct clk * __init
+at91_clk_register_system(const char *name, u8 id)
+{
+	struct clk_system *sys;
+	struct clk *clk = NULL;
+	struct clk_init_data init;
+
+	id &= 31;
+
+	sys = kzalloc(sizeof(*sys), GFP_KERNEL);
+	if (!sys)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &system_ops;
+	init.parent_names = NULL;
+	init.num_parents = 0;
+	/*
+	 * CLK_IGNORE_UNUSED is used to avoid ddrck switch off.
+	 * TODO : we should implement a driver supporting at91 ddr controller
+	 * (see drivers/memory) which would request and enable the ddrck clock.
+	 * When this is done we will be able to remove CLK_IGNORE_UNUSED flag.
+	 */
+	init.flags = CLK_IS_ROOT | CLK_IGNORE_UNUSED;
+
+	sys->id = id;
+	sys->hw.init = &init;
+
+	clk = clk_register(NULL, &sys->hw);
+
+	if (IS_ERR(clk))
+		kfree(sys);
+
+	return clk;
+}
+
+#if defined(CONFIG_OF)
+struct clk_system_data {
+	struct clk **clks;
+	u8 *ids;
+	unsigned int clk_num;
+};
+
+static struct clk * __init
+of_clk_src_system_get(struct of_phandle_args *clkspec, void *data)
+{
+	struct clk_system_data *clk_data = data;
+	unsigned int id = clkspec->args[0];
+	int i;
+
+	if (id >= SYSTEM_MAX)
+		goto err;
+
+	for (i = 0; i < clk_data->clk_num; i++) {
+		if (clk_data->ids[i] == id)
+			return clk_data->clks[i];
+	}
+
+err:
+	pr_err("%s: invalid clock id %d\n", __func__, id);
+	return ERR_PTR(-EINVAL);
+}
+
+static void __init
+of_at91_clk_sys_setup(struct device_node *np)
+{
+	int i;
+	int num;
+	u32 id;
+	struct clk *clk;
+	u8 *ids;
+	struct clk **clks;
+	struct clk_system_data *clktab;
+	const char *name;
+	struct device_node *sysclknp;
+
+	num = of_get_child_count(np);
+	if (num > SYSTEM_MAX)
+		return;
+
+	clktab = kzalloc(sizeof(*clktab), GFP_KERNEL);
+	if (!clktab)
+		return;
+
+	ids = kzalloc(num * sizeof(*ids), GFP_KERNEL);
+	if (!ids)
+		goto out_free_clktab;
+
+	clks = kzalloc(num * sizeof(*clks), GFP_KERNEL);
+	if (!clks)
+		goto out_free_ids;
+
+	i = 0;
+	for_each_child_of_node(np, sysclknp) {
+		name = sysclknp->name;
+
+		if (of_property_read_u32(sysclknp, "id", &id))
+			goto out_free_clks;
+		if (id >= SYSTEM_MAX)
+			goto out_free_clks;
+
+		clk = at91_clk_register_system(name, id);
+		if (IS_ERR(clk))
+			goto out_free_clks;
+
+		clks[i] = clk;
+		ids[i] = id;
+
+		i++;
+	}
+
+	clktab->clk_num = num;
+	clktab->clks = clks;
+	clktab->ids = ids;
+	of_clk_add_provider(np, of_clk_src_system_get, clktab);
+	return;
+
+out_free_clks:
+	kfree(clks);
+out_free_ids:
+	kfree(ids);
+out_free_clktab:
+	kfree(clktab);
+}
+
+static void __init of_at91rm9200_clk_sys_setup(struct device_node *np)
+{
+	of_at91_clk_sys_setup(np);
+}
+CLK_OF_DECLARE(at91rm9200_clk_sys, "atmel,at91rm9200-clk-system",
+	       of_at91rm9200_clk_sys_setup);
+#endif
diff --git a/include/linux/clk/at91.h b/include/linux/clk/at91.h
index 324134c..518a568 100644
--- a/include/linux/clk/at91.h
+++ b/include/linux/clk/at91.h
@@ -259,4 +259,7 @@ at91_clk_register_master(const char *name, int num_parents,
 			 struct clk_master_characteristics *characteristics);
 
 
+struct clk * __init
+at91_clk_register_system(const char *name, u8 id);
+
 #endif
-- 
1.7.9.5



From oleksandr.kozaruk at ti.com  Wed Jul 17 09:45:57 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Wed, 17 Jul 2013 16:45:57 +0300
Subject: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <51E3DE21.9060105@metafoo.de>
References: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1373613482-28390-3-git-send-email-oleksandr.kozaruk@ti.com>,
 <51E05F6C.1060506@metafoo.de>
 <2A7ABDFCE21540479A5AEB0244A684D5E3D067@DNCE04.ent.ti.com>
 <51E3DE21.9060105@metafoo.de>
Message-ID: <51E6A015.8040705@ti.com>

On Mon, Jul 15, 2013 at 01:33:53PM +0200, Lars-Peter Clausen wrote:
 > On 07/15/2013 01:09 PM, Kozaruk, Oleksandr wrote:
 > [...]
 > >
 > >>> +     ret = devm_request_threaded_irq(dev, irq, NULL,
 > >>> + twl6030_gpadc_irq_handler,
 > >>> + IRQF_ONESHOT, "twl6030_gpadc", gpadc);
 > >>
 > >> You access memory in the interrupt handler which is freed before 
the interrupt
 > >> handler is freed.
 > > Thanks for pointing this. devm_* will free memory for irq after the 
driver
 > > is removed and memory for the device is freed. I took me awhile to 
understand
 > > this. Is there going to be something like devm_iio_device_alloc? 
whould it be helpfull?
 > >
 >
 > Yes, I think it certainly makes sense to add a 
devm_iio_device_alloc(), care
 > to send a patch?

Anything like this? (of course it's not a patch)

struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv)
{
     struct iio_dev *indio_dev;
     size_t alloc_size;

     alloc_size = sizeof(struct iio_dev);
     if (sizeof_priv) {
         alloc_size = ALIGN(alloc_size, IIO_ALIGN);
         alloc_size += sizeof_priv;
     }
     /* ensure 32-byte alignment of whole construct ? */
     alloc_size += IIO_ALIGN - 1;

     indio_dev = devm_kzalloc(dev, alloc_size, GFP_KERNEL);
     if (indio_dev) {
         indio_dev->dev.groups = indio_dev->groups;
         indio_dev->dev.type = &iio_device_type;
         indio_dev->dev.bus = &iio_bus_type;
         device_initialize(&indio_dev->dev);
         dev_set_drvdata(&indio_dev->dev, (void *)indio_dev);
         mutex_init(&indio_dev->mlock);
         mutex_init(&indio_dev->info_exist_lock);
         INIT_LIST_HEAD(&indio_dev->channel_attr_list);

         indio_dev->id = ida_simple_get(&iio_ida, 0, 0, GFP_KERNEL);
         if (indio_dev->id < 0) {
             /* cannot use a dev_err as the name isn't available */
             printk(KERN_ERR "Failed to get id\n");
             kfree(dev);
             return NULL;
         }
         dev_set_name(&indio_dev->dev, "iio:device%d", indio_dev->id);
         INIT_LIST_HEAD(&indio_dev->buffer_list);
     }

     return indio_dev;
}
EXPORT_SYMBOL(devm_iio_device_alloc);

Regards,
OK


From b.brezillon at overkiz.com  Wed Jul 17 09:46:56 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 15:46:56 +0200
Subject: [PATCH v2 06/42] ARM: at91: add PMC peripheral clocks
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374068816-13935-1-git-send-email-b.brezillon@overkiz.com>

This is the at91 peripheral clock implementation using common clk framework.

Almost all peripherals provided by an at91 SoC need a clock to work properly.
This clock is enabled/disabled using PCER/PCDR resgisters.

Each peripheral is given an id (see atmel's datasheets) which is used as bit
position in SCER/SCDR registers.

Some new SoCs (at91sam9x5 and sama5d3) provide a new register (PCR) where you
can configure the peripheral clock as a division of the master clock.
This will help reducing the peripherals power comsumption.

This patch fixes erronous AT91_PMC_PCR_DIV values.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/clk/at91/Makefile         |    2 +-
 drivers/clk/at91/clk-peripheral.c |  371 +++++++++++++++++++++++++++++++++++++
 include/linux/clk/at91.h          |    8 +
 3 files changed, 380 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/at91/clk-peripheral.c

diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 13e5714..3e2a670 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -3,4 +3,4 @@
 #
 
 obj-y += clk-main.o clk-pll.o clk-plldiv.o clk-master.o
-obj-y += clk-system.o
+obj-y += clk-system.o clk-peripheral.o
diff --git a/drivers/clk/at91/clk-peripheral.c b/drivers/clk/at91/clk-peripheral.c
new file mode 100644
index 0000000..11be85ea
--- /dev/null
+++ b/drivers/clk/at91/clk-peripheral.c
@@ -0,0 +1,371 @@
+/*
+ * drivers/clk/at91/clk-peripheral.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/clk/at91.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+
+#define PERIPHERAL_MAX		64
+
+#define PERIPHERAL_AT91RM9200	0
+#define PERIPHERAL_AT91SAM9X5	1
+
+#define to_clk_peripheral(hw) container_of(hw, struct clk_peripheral, hw)
+struct clk_peripheral {
+	struct clk_hw hw;
+	u32 id;
+};
+
+#define to_clk_sam9x5_peripheral(hw) \
+	container_of(hw, struct clk_sam9x5_peripheral, hw)
+struct clk_sam9x5_peripheral {
+	struct clk_hw hw;
+	u32 id;
+	u8 div;
+	u8 have_div_support;
+};
+
+static int clk_peripheral_enable(struct clk_hw *hw)
+{
+	struct clk_peripheral *periph = to_clk_peripheral(hw);
+	int offset = AT91_PMC_PCER;
+	if (periph->id < 2)
+		return 0;
+	if (periph->id > 31)
+		offset = AT91_PMC_PCER1;
+	at91_pmc_write(offset, 1 << (periph->id & 31));
+	return 0;
+}
+
+static void clk_peripheral_disable(struct clk_hw *hw)
+{
+	struct clk_peripheral *periph = to_clk_peripheral(hw);
+	int offset = AT91_PMC_PCDR;
+	if (periph->id < 2)
+		return;
+	if (periph->id > 31)
+		offset = AT91_PMC_PCDR1;
+	at91_pmc_write(offset, 1 << (periph->id & 31));
+}
+
+static int clk_peripheral_is_enabled(struct clk_hw *hw)
+{
+	struct clk_peripheral *periph = to_clk_peripheral(hw);
+	int offset = AT91_PMC_PCSR;
+	if (periph->id < 2)
+		return 1;
+	if (periph->id > 31)
+		offset = AT91_PMC_PCSR1;
+	return !!(at91_pmc_read(offset) & (1 << (periph->id & 31)));
+}
+
+static const struct clk_ops peripheral_ops = {
+	.enable = clk_peripheral_enable,
+	.disable = clk_peripheral_disable,
+	.is_enabled = clk_peripheral_is_enabled,
+};
+
+struct clk * __init at91_clk_register_peripheral(const char *name,
+						 const char *parent_name,
+						 u32 id)
+{
+	struct clk_peripheral *periph;
+	struct clk *clk = NULL;
+	struct clk_init_data init;
+
+	id &= 31;
+	periph = kzalloc(sizeof(*periph), GFP_KERNEL);
+	if (!periph)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &peripheral_ops;
+	init.parent_names = (parent_name ? &parent_name : NULL);
+	init.num_parents = (parent_name ? 1 : 0);
+	init.flags = 0;
+
+	periph->id = id;
+	periph->hw.init = &init;
+
+	clk = clk_register(NULL, &periph->hw);
+	if (IS_ERR(clk))
+		kfree(periph);
+
+	return clk;
+}
+
+static int clk_sam9x5_peripheral_enable(struct clk_hw *hw)
+{
+	struct clk_sam9x5_peripheral *periph = to_clk_sam9x5_peripheral(hw);
+	if (periph->id < 2)
+		return 0;
+	at91_pmc_write(AT91_PMC_PCR,
+		       (periph->id & AT91_PMC_PCR_PID) |
+		       AT91_PMC_PCR_CMD |
+		       AT91_PMC_PCR_DIV(periph->div) |
+		       AT91_PMC_PCR_EN);
+	return 0;
+}
+
+static void clk_sam9x5_peripheral_disable(struct clk_hw *hw)
+{
+	struct clk_sam9x5_peripheral *periph = to_clk_sam9x5_peripheral(hw);
+	if (periph->id < 2)
+		return;
+
+	at91_pmc_write(AT91_PMC_PCR,
+		       (periph->id & AT91_PMC_PCR_PID) |
+		       AT91_PMC_PCR_CMD);
+}
+
+static int clk_sam9x5_peripheral_is_enabled(struct clk_hw *hw)
+{
+	struct clk_sam9x5_peripheral *periph = to_clk_sam9x5_peripheral(hw);
+	if (periph->id < 2)
+		return 1;
+	at91_pmc_write(AT91_PMC_PCR,
+		       (periph->id & AT91_PMC_PCR_PID));
+	return !!(at91_pmc_read(AT91_PMC_PCR) & AT91_PMC_PCR_EN);
+}
+
+static unsigned long
+clk_sam9x5_peripheral_recalc_rate(struct clk_hw *hw,
+				  unsigned long parent_rate)
+{
+	struct clk_sam9x5_peripheral *periph = to_clk_sam9x5_peripheral(hw);
+	u32 shift;
+	if (periph->id < 2 || !periph->have_div_support)
+		return parent_rate;
+	at91_pmc_write(AT91_PMC_PCR,
+		       (periph->id & AT91_PMC_PCR_PID));
+	shift = (at91_pmc_read(AT91_PMC_PCR) >> 16) & 0x3;
+	return parent_rate >> shift;
+}
+
+static long clk_sam9x5_peripheral_round_rate(struct clk_hw *hw,
+					     unsigned long rate,
+					     unsigned long *parent_rate)
+{
+	int shift;
+	unsigned long best_rate;
+	unsigned long best_diff;
+	unsigned long cur_rate;
+	unsigned long cur_diff;
+	struct clk_sam9x5_peripheral *periph = to_clk_sam9x5_peripheral(hw);
+	if (periph->id < 2 || !periph->have_div_support)
+		return *parent_rate;
+	if (rate >= *parent_rate)
+		return rate;
+	best_diff = *parent_rate - rate;
+	best_rate = *parent_rate;
+	for (shift = 1; shift < 4; shift++) {
+		cur_rate = *parent_rate >> shift;
+		if (cur_rate < rate)
+			cur_diff = rate - cur_rate;
+		else
+			cur_diff = cur_rate - rate;
+		if (cur_diff < best_diff) {
+			best_diff = cur_diff;
+			best_rate = cur_rate;
+		}
+		if (!best_diff || cur_rate < rate)
+			break;
+	}
+	return best_rate;
+}
+
+static int clk_sam9x5_peripheral_set_rate(struct clk_hw *hw,
+					  unsigned long rate,
+					  unsigned long parent_rate)
+{
+	int shift;
+	struct clk_sam9x5_peripheral *periph = to_clk_sam9x5_peripheral(hw);
+	if (periph->id < 2 || !periph->have_div_support) {
+		if (parent_rate == rate)
+			return 0;
+		else
+			return -EINVAL;
+	}
+
+	for (shift = 0; shift < 4; shift++) {
+		if (parent_rate >> shift == rate) {
+			periph->div = shift;
+			return 0;
+		}
+	}
+
+	return -EINVAL;
+}
+
+static const struct clk_ops sam9x5_peripheral_ops = {
+	.enable = clk_sam9x5_peripheral_enable,
+	.disable = clk_sam9x5_peripheral_disable,
+	.is_enabled = clk_sam9x5_peripheral_is_enabled,
+	.recalc_rate = clk_sam9x5_peripheral_recalc_rate,
+	.round_rate = clk_sam9x5_peripheral_round_rate,
+	.set_rate = clk_sam9x5_peripheral_set_rate,
+};
+
+struct clk * __init
+at91_clk_register_sam9x5_peripheral(const char *name,
+				    const char *parent_name,
+				    u32 id, u32 default_div)
+{
+	struct clk_sam9x5_peripheral *periph;
+	struct clk *clk = NULL;
+	struct clk_init_data init;
+
+	periph = kzalloc(sizeof(*periph), GFP_KERNEL);
+	if (!periph)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &sam9x5_peripheral_ops;
+	init.parent_names = (parent_name ? &parent_name : NULL);
+	init.num_parents = (parent_name ? 1 : 0);
+	init.flags = CLK_SET_RATE_GATE;
+
+	periph->id = id;
+	periph->hw.init = &init;
+	periph->div = default_div;
+
+	clk = clk_register(NULL, &periph->hw);
+
+	if (IS_ERR(clk))
+		kfree(periph);
+
+	return clk;
+}
+
+#if defined(CONFIG_OF)
+struct clk_periph_data {
+	struct clk **clks;
+	u8 *ids;
+	unsigned int clk_num;
+};
+
+static struct clk * __init
+of_clk_src_periph_get(struct of_phandle_args *clkspec, void *data)
+{
+	struct clk_periph_data *clk_data = data;
+	unsigned int id = clkspec->args[0];
+	int i;
+
+	if (id >= PERIPHERAL_MAX)
+		goto err;
+
+	for (i = 0; i < clk_data->clk_num; i++) {
+		if (clk_data->ids[i] == id)
+			return clk_data->clks[i];
+	}
+
+err:
+	pr_err("%s: invalid clock id %d\n", __func__, id);
+	return ERR_PTR(-EINVAL);
+}
+
+static void __init
+of_at91_clk_periph_setup(struct device_node *np, u8 type)
+{
+	int num;
+	int i;
+	u32 id;
+	struct clk *clk;
+	const char *parent_name;
+	const char *name;
+	u32 divisor;
+	struct clk **clks;
+	u8 *ids;
+	struct clk_periph_data *clktab;
+	struct device_node *periphclknp;
+
+	parent_name = of_clk_get_parent_name(np, 0);
+	if (!parent_name)
+		return;
+
+	num = of_get_child_count(np);
+	if (!num || num > PERIPHERAL_MAX)
+		return;
+
+	clktab = kzalloc(sizeof(*clktab), GFP_KERNEL);
+	if (!clktab)
+		return;
+
+	ids = kzalloc(num * sizeof(*ids), GFP_KERNEL);
+	if (!ids)
+		goto out_free_clktab;
+
+	clks = kzalloc(num * sizeof(*clks), GFP_KERNEL);
+	if (!clks)
+		goto out_free_ids;
+
+	i = 0;
+	for_each_child_of_node(np, periphclknp) {
+		name = periphclknp->name;
+
+		if (of_property_read_u32(periphclknp, "id", &id))
+			goto out_free_clks;
+		if (id >= PERIPHERAL_MAX)
+			goto out_free_clks;
+
+		if (type == PERIPHERAL_AT91RM9200) {
+			clk = at91_clk_register_peripheral(name,
+							   parent_name, id);
+		} else {
+			if (of_property_read_u32(periphclknp,
+						 "default-divisor",
+						 &divisor))
+				divisor = 0;
+
+			clk = at91_clk_register_sam9x5_peripheral(name,
+								  parent_name,
+								  id,
+								  divisor);
+		}
+		if (IS_ERR(clk))
+			goto out_free_clks;
+
+		clks[i] = clk;
+		ids[i++] = id;
+	}
+
+	clktab->clk_num = num;
+	clktab->clks = clks;
+	clktab->ids = ids;
+	of_clk_add_provider(np, of_clk_src_periph_get, clktab);
+	return;
+
+out_free_clks:
+	kfree(clks);
+out_free_ids:
+	kfree(ids);
+out_free_clktab:
+	kfree(clktab);
+}
+
+static void __init of_at91rm9200_clk_periph_setup(struct device_node *np)
+{
+	of_at91_clk_periph_setup(np, PERIPHERAL_AT91RM9200);
+}
+CLK_OF_DECLARE(at91rm9200_clk_periph, "atmel,at91rm9200-clk-peripheral",
+	       of_at91rm9200_clk_periph_setup);
+
+static void __init of_at91sam9x5_clk_periph_setup(struct device_node *np)
+{
+	of_at91_clk_periph_setup(np, PERIPHERAL_AT91SAM9X5);
+}
+CLK_OF_DECLARE(at91sam9x5_clk_periph, "atmel,at91sam9x5-clk-peripheral",
+	       of_at91sam9x5_clk_periph_setup);
+#endif
diff --git a/include/linux/clk/at91.h b/include/linux/clk/at91.h
index 518a568..112a060 100644
--- a/include/linux/clk/at91.h
+++ b/include/linux/clk/at91.h
@@ -262,4 +262,12 @@ at91_clk_register_master(const char *name, int num_parents,
 struct clk * __init
 at91_clk_register_system(const char *name, u8 id);
 
+struct clk * __init
+at91_clk_register_peripheral(const char *name, const char *parent_name,
+			     u32 id);
+
+struct clk * __init
+at91_clk_register_sam9x5_peripheral(const char *name, const char *parent_name,
+				    u32 id, u32 default_div);
+
 #endif
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 09:47:46 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 15:47:46 +0200
Subject: [PATCH v2 07/42] ARM: at91: add PMC programmable clocks
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374068866-13977-1-git-send-email-b.brezillon@overkiz.com>

This is the at91 programmable clocks implementation using common clk
framework.
A programmable clock is a clock which can be exported on a given pin to clock
external devices.
Each programmable clock is given an id (from 0 to 8).
The number of available programmable clocks depends on the SoC you're using.
Programmable clock driver only implements the clock setting (clock rate and
parent setting). It must be chained to a system clock in order to
enable/disable the generated clock.
The PCKX pins used to output the clock signals must be assigned to the
appropriate peripheral (see atmel's datasheets).

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/clk/at91/Makefile           |    2 +
 drivers/clk/at91/clk-programmable.c |  368 +++++++++++++++++++++++++++++++++++
 include/linux/clk/at91.h            |   18 ++
 3 files changed, 388 insertions(+)
 create mode 100644 drivers/clk/at91/clk-programmable.c

diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 3e2a670..2d7c119 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -4,3 +4,5 @@
 
 obj-y += clk-main.o clk-pll.o clk-plldiv.o clk-master.o
 obj-y += clk-system.o clk-peripheral.o
+
+obj-$(CONFIG_AT91_PROGRAMMABLE_CLOCKS)	+= clk-programmable.o
diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
new file mode 100644
index 0000000..21829fc
--- /dev/null
+++ b/drivers/clk/at91/clk-programmable.c
@@ -0,0 +1,368 @@
+/*
+ * drivers/clk/at91/clk-programmable.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/clk/at91.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+
+#define PROG_SOURCE_MAX		5
+#define PROG_MAX		8
+
+#define to_clk_programmable(hw) container_of(hw, struct clk_programmable, hw)
+struct clk_programmable {
+	struct clk_hw hw;
+	u8 id;
+	u8 css;
+	u8 pres;
+	u8 slckmck;
+	struct clk_programmable_layout *layout;
+};
+
+static int clk_programmable_prepare(struct clk_hw *hw)
+{
+	u32 tmp;
+	struct clk_programmable *prog = to_clk_programmable(hw);
+	struct clk_programmable_layout *layout = prog->layout;
+	tmp = prog->css | (prog->pres << layout->pres_shift);
+	if (layout->have_slck_mck && prog->slckmck)
+		tmp |= 1 << 8;
+	at91_pmc_write(AT91_PMC_PCKR(prog->id), tmp);
+	while (!(at91_pmc_read(AT91_PMC_SR) & (1 << (prog->id + 8))))
+		;
+	return 0;
+}
+
+static int clk_programmable_is_prepared(struct clk_hw *hw)
+{
+	struct clk_programmable *prog = to_clk_programmable(hw);
+	return !!(at91_pmc_read(AT91_PMC_SR) & (1 << (prog->id + 8)));
+}
+
+static unsigned long clk_programmable_recalc_rate(struct clk_hw *hw,
+						  unsigned long parent_rate)
+{
+	u32 tmp;
+	struct clk_programmable *prog = to_clk_programmable(hw);
+	struct clk_programmable_layout *layout = prog->layout;
+	tmp = at91_pmc_read(AT91_PMC_PCKR(prog->id));
+	prog->pres = (tmp >> layout->pres_shift) & 0x7;
+	return parent_rate >> prog->pres;
+}
+
+static long clk_programmable_round_rate(struct clk_hw *hw, unsigned long rate,
+					unsigned long *parent_rate)
+{
+	unsigned long best_rate = *parent_rate;
+	unsigned long best_diff;
+	unsigned long new_diff;
+	unsigned long cur_rate;
+	int shift = shift;
+
+	if (rate > *parent_rate)
+		return *parent_rate;
+	else
+		best_diff = *parent_rate - rate;
+
+	if (!best_diff)
+		return best_rate;
+
+	for (shift = 1; shift < 7; shift++) {
+		cur_rate = *parent_rate >> shift;
+
+		if (cur_rate > rate)
+			new_diff = cur_rate - rate;
+		else
+			new_diff = rate - cur_rate;
+
+		if (!new_diff)
+			return cur_rate;
+
+		if (new_diff < best_diff) {
+			best_diff = new_diff;
+			best_rate = cur_rate;
+		}
+
+		if (rate > cur_rate)
+			break;
+
+	}
+
+	return best_rate;
+}
+
+static int clk_programmable_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct clk_programmable *prog = to_clk_programmable(hw);
+	struct clk_programmable_layout *layout = prog->layout;
+	if (index > layout->css_mask) {
+		if (index == 4 && layout->have_slck_mck) {
+			prog->css = 0;
+			prog->slckmck = 1;
+			return 0;
+		} else
+			return -EINVAL;
+	}
+
+	prog->css = index;
+	return 0;
+}
+
+static u8 clk_programmable_get_parent(struct clk_hw *hw)
+{
+	u32 tmp;
+	u8 ret;
+	struct clk_programmable *prog = to_clk_programmable(hw);
+	struct clk_programmable_layout *layout = prog->layout;
+	tmp = at91_pmc_read(AT91_PMC_PCKR(prog->id));
+	prog->css = tmp & layout->css_mask;
+	ret = prog->css;
+	if (layout->have_slck_mck) {
+		prog->slckmck = !!(tmp & (1 << 8));
+		if (prog->slckmck && !ret)
+			ret = 4;
+	}
+
+	return ret;
+}
+
+static int clk_programmable_set_rate(struct clk_hw *hw, unsigned long rate,
+				     unsigned long parent_rate)
+{
+	struct clk_programmable *prog = to_clk_programmable(hw);
+	unsigned long best_rate = parent_rate;
+	unsigned long best_diff;
+	unsigned long new_diff;
+	unsigned long cur_rate;
+	int shift = 0;
+
+	if (rate > parent_rate)
+		return parent_rate;
+	else
+		best_diff = parent_rate - rate;
+
+	if (!best_diff) {
+		prog->pres = shift;
+		return 0;
+	}
+
+	for (shift = 1; shift < 7; shift++) {
+		cur_rate = parent_rate >> shift;
+
+		if (cur_rate > rate)
+			new_diff = cur_rate - rate;
+		else
+			new_diff = rate - cur_rate;
+
+		if (!new_diff)
+			break;
+
+		if (new_diff < best_diff) {
+			best_diff = new_diff;
+			best_rate = cur_rate;
+		}
+
+		if (rate > cur_rate)
+			break;
+
+	}
+
+	prog->pres = shift;
+	return 0;
+}
+
+static const struct clk_ops programmable_ops = {
+	.prepare = clk_programmable_prepare,
+	.is_prepared = clk_programmable_is_prepared,
+	.recalc_rate = clk_programmable_recalc_rate,
+	.round_rate = clk_programmable_round_rate,
+	.get_parent = clk_programmable_get_parent,
+	.set_parent = clk_programmable_set_parent,
+	.set_rate = clk_programmable_set_rate,
+};
+
+struct clk * __init
+at91_clk_register_programmable(const char *name, const char **parent_names,
+			       u8 num_parents, u8 id,
+			       struct clk_programmable_layout *layout)
+{
+	struct clk_programmable *prog;
+	struct clk *clk = NULL;
+	struct clk_init_data init;
+
+	id &= 7;
+
+	prog = kzalloc(sizeof(*prog), GFP_KERNEL);
+	if (!prog)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &programmable_ops;
+	init.parent_names = parent_names;
+	init.num_parents = num_parents;
+	init.flags = CLK_SET_RATE_GATE | CLK_SET_PARENT_GATE;
+
+	prog->id = id;
+	prog->layout = layout;
+	prog->hw.init = &init;
+
+	clk = clk_register(NULL, &prog->hw);
+
+	if (IS_ERR(clk))
+		kfree(prog);
+
+	return clk;
+}
+
+struct clk_programmable_layout at91rm9200_programmable_layout = {
+	.pres_shift = 2,
+	.css_mask = 0x3,
+	.have_slck_mck = 0,
+};
+
+struct clk_programmable_layout at91sam9g45_programmable_layout = {
+	.pres_shift = 2,
+	.css_mask = 0x3,
+	.have_slck_mck = 1,
+};
+
+struct clk_programmable_layout at91sam9x5_programmable_layout = {
+	.pres_shift = 4,
+	.css_mask = 0x7,
+	.have_slck_mck = 0,
+};
+
+#if defined(CONFIG_OF)
+struct clk_prog_data {
+	struct clk **clks;
+	u8 *ids;
+	unsigned int clk_num;
+};
+
+static struct clk * __init
+of_clk_src_periph_get(struct of_phandle_args *clkspec, void *data)
+{
+	struct clk_prog_data *clk_data = data;
+	unsigned int id = clkspec->args[0];
+	int i;
+
+	if (id >= PROG_MAX)
+		goto err;
+
+	for (i = 0; i < clk_data->clk_num; i++) {
+		if (clk_data->ids[i] == id)
+			return clk_data->clks[i];
+	}
+
+err:
+	pr_err("%s: invalid clock id %d\n", __func__, id);
+	return ERR_PTR(-EINVAL);
+}
+
+static void __init
+of_at91_clk_prog_setup(struct device_node *np,
+		       struct clk_programmable_layout *layout)
+{
+	int num;
+	u32 id;
+	int i;
+	struct clk *clk;
+	int num_parents;
+	u8 *ids;
+	struct clk **clks;
+	struct clk_prog_data *clktab;
+	const char *parent_names[PROG_SOURCE_MAX];
+	const char *name;
+	struct device_node *progclknp;
+
+	num_parents = of_count_phandle_with_args(np, "clocks", "#clock-cells");
+	if (num_parents <= 0 || num_parents > PROG_SOURCE_MAX)
+		return;
+
+	for (i = 0; i < num_parents; ++i) {
+		parent_names[i] = of_clk_get_parent_name(np, i);
+		if (!parent_names[i])
+			return;
+	}
+
+	num = of_get_child_count(np);
+	if (!num || num > PROG_MAX)
+		return;
+
+	clktab = kzalloc(sizeof(*clktab), GFP_KERNEL);
+	if (!clktab)
+		return;
+
+	ids = kzalloc(num * sizeof(*ids), GFP_KERNEL);
+	if (!ids)
+		goto out_free_clktab;
+
+	clks = kzalloc(num * sizeof(*clks), GFP_KERNEL);
+	if (!clks)
+		goto out_free_ids;
+
+	i = 0;
+	for_each_child_of_node(np, progclknp) {
+		name = progclknp->name;
+
+		if (of_property_read_u32(progclknp, "id", &id))
+			goto out_free_clks;
+		if (id >= PROG_MAX)
+			goto out_free_clks;
+
+		clk = at91_clk_register_programmable(name, parent_names,
+						     num_parents, id, layout);
+		if (IS_ERR(clk))
+			goto out_free_clks;
+
+		clks[i] = clk;
+		ids[i++] = id;
+	}
+
+	clktab->clk_num = num;
+	clktab->clks = clks;
+	clktab->ids = ids;
+	of_clk_add_provider(np, of_clk_src_periph_get, clktab);
+	return;
+
+out_free_clks:
+	kfree(clks);
+out_free_ids:
+	kfree(ids);
+out_free_clktab:
+	kfree(clktab);
+}
+
+
+static void __init of_at91rm9200_clk_prog_setup(struct device_node *np)
+{
+	of_at91_clk_prog_setup(np, &at91rm9200_programmable_layout);
+}
+CLK_OF_DECLARE(at91rm9200_clk_prog, "atmel,at91rm9200-clk-programmable",
+	       of_at91rm9200_clk_prog_setup);
+
+static void __init of_at91sam9g45_clk_prog_setup(struct device_node *np)
+{
+	of_at91_clk_prog_setup(np, &at91sam9g45_programmable_layout);
+}
+CLK_OF_DECLARE(at91sam9g45_clk_prog, "atmel,at91sam9g45-clk-programmable",
+	       of_at91sam9g45_clk_prog_setup);
+
+static void __init of_at91sam9x5_clk_prog_setup(struct device_node *np)
+{
+	of_at91_clk_prog_setup(np, &at91sam9x5_programmable_layout);
+}
+CLK_OF_DECLARE(at91sam9x5_clk_prog, "atmel,at91sam9x5-clk-programmable",
+	       of_at91sam9x5_clk_prog_setup);
+#endif
diff --git a/include/linux/clk/at91.h b/include/linux/clk/at91.h
index 112a060..3cafd36 100644
--- a/include/linux/clk/at91.h
+++ b/include/linux/clk/at91.h
@@ -224,6 +224,12 @@ struct clk_master_layout {
 	u8 pres_shift;
 };
 
+struct clk_programmable_layout {
+	u8 pres_shift;
+	u8 css_mask;
+	u8 have_slck_mck;
+};
+
 
 struct clk * __init
 at91_clk_register_main(const char *name,
@@ -270,4 +276,16 @@ struct clk * __init
 at91_clk_register_sam9x5_peripheral(const char *name, const char *parent_name,
 				    u32 id, u32 default_div);
 
+
+extern struct clk_programmable_layout at91rm9200_programmable_layout;
+
+extern struct clk_programmable_layout at91sam9g45_programmable_layout;
+
+extern struct clk_programmable_layout at91sam9x5_programmable_layout;
+
+struct clk * __init
+at91_clk_register_programmable(const char *name, const char **parent_names,
+			       u8 num_parents, u8 id,
+			       struct clk_programmable_layout *layout);
+
 #endif
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 09:50:50 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 15:50:50 +0200
Subject: [PATCH v2 08/42] ARM: at91: add PMC utmi clock
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374069050-14060-1-git-send-email-b.brezillon@overkiz.com>

This is the at91 utmi clock implementation using common clk framework.

This clock is a pll with a fixed factor (x40).
It is used as a source for usb clock.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/Kconfig  |    7 +++
 drivers/clk/at91/Makefile   |    1 +
 drivers/clk/at91/clk-utmi.c |  114 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/clk/at91.h    |    4 ++
 4 files changed, 126 insertions(+)
 create mode 100644 drivers/clk/at91/clk-utmi.c

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 699b71e..1a24a1f 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -1,5 +1,8 @@
 if ARCH_AT91
 
+config HAVE_AT91_UTMI
+	bool
+
 config HAVE_AT91_DBGU0
 	bool
 
@@ -65,6 +68,7 @@ config SOC_SAMA5D3
 	select SOC_SAMA5
 	select HAVE_FB_ATMEL
 	select HAVE_AT91_DBGU1
+	select HAVE_AT91_UTMI
 	help
 	  Select this if you are using one of Atmel's SAMA5D3 family SoC.
 	  This support covers SAMA5D31, SAMA5D33, SAMA5D34, SAMA5D35.
@@ -106,12 +110,14 @@ config SOC_AT91SAM9RL
 	select HAVE_AT91_DBGU0
 	select HAVE_FB_ATMEL
 	select SOC_AT91SAM9
+	select HAVE_AT91_UTMI
 
 config SOC_AT91SAM9G45
 	bool "AT91SAM9G45 or AT91SAM9M10 families"
 	select HAVE_AT91_DBGU1
 	select HAVE_FB_ATMEL
 	select SOC_AT91SAM9
+	select HAVE_AT91_UTMI
 	help
 	  Select this if you are using one of Atmel's AT91SAM9G45 family SoC.
 	  This support covers AT91SAM9G45, AT91SAM9G46, AT91SAM9M10 and AT91SAM9M11.
@@ -121,6 +127,7 @@ config SOC_AT91SAM9X5
 	select HAVE_AT91_DBGU0
 	select HAVE_FB_ATMEL
 	select SOC_AT91SAM9
+	select HAVE_AT91_UTMI
 	help
 	  Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
 	  This means that your SAM9 name finishes with a '5' (except if it is
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 2d7c119..76d09f0 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -6,3 +6,4 @@ obj-y += clk-main.o clk-pll.o clk-plldiv.o clk-master.o
 obj-y += clk-system.o clk-peripheral.o
 
 obj-$(CONFIG_AT91_PROGRAMMABLE_CLOCKS)	+= clk-programmable.o
+obj-$(CONFIG_HAVE_AT91_UTMI)		+= clk-utmi.o
diff --git a/drivers/clk/at91/clk-utmi.c b/drivers/clk/at91/clk-utmi.c
new file mode 100644
index 0000000..c0dd596
--- /dev/null
+++ b/drivers/clk/at91/clk-utmi.c
@@ -0,0 +1,114 @@
+/*
+ * drivers/clk/at91/clk-utmi.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/clk/at91.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+
+#define to_clk_utmi(hw) container_of(hw, struct clk_utmi, hw)
+
+struct clk_utmi {
+	struct clk_hw hw;
+};
+
+static int clk_utmi_prepare(struct clk_hw *hw)
+{
+	u32 tmp = at91_pmc_read(AT91_CKGR_UCKR) | AT91_PMC_UPLLEN |
+		  AT91_PMC_UPLLCOUNT;
+	at91_pmc_write(AT91_CKGR_UCKR, tmp);
+	while (!(at91_pmc_read(AT91_PMC_SR) & AT91_PMC_LOCKU))
+		;
+	return 0;
+}
+
+static int clk_utmi_is_prepared(struct clk_hw *hw)
+{
+	return !!(at91_pmc_read(AT91_PMC_SR) & AT91_PMC_LOCKU);
+}
+
+static void clk_utmi_disable(struct clk_hw *hw)
+{
+	u32 tmp = at91_pmc_read(AT91_CKGR_UCKR) & ~AT91_PMC_UPLLEN;
+	at91_pmc_write(AT91_CKGR_UCKR, tmp);
+}
+
+static unsigned long clk_utmi_recalc_rate(struct clk_hw *hw,
+					  unsigned long parent_rate)
+{
+	return parent_rate * 40;
+}
+
+static const struct clk_ops utmi_ops = {
+	.prepare = clk_utmi_prepare,
+	.is_prepared = clk_utmi_is_prepared,
+	.disable = clk_utmi_disable,
+	.recalc_rate = clk_utmi_recalc_rate,
+};
+
+struct clk * __init
+at91_clk_register_utmi(const char *name, const char *parent_name)
+{
+	struct clk_utmi *utmi;
+	struct clk *clk = NULL;
+	struct clk_init_data init;
+
+	utmi = kzalloc(sizeof(*utmi), GFP_KERNEL);
+	if (!utmi)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &utmi_ops;
+	init.parent_names = parent_name ? &parent_name : NULL;
+	init.num_parents = parent_name ? 1 : 0;
+	init.flags = CLK_SET_RATE_GATE;
+
+	utmi->hw.init = &init;
+
+	clk = clk_register(NULL, &utmi->hw);
+
+	if (IS_ERR(clk))
+		kfree(utmi);
+
+	return clk;
+}
+
+#if defined(CONFIG_OF)
+static void __init
+of_at91_clk_utmi_setup(struct device_node *np)
+{
+	struct clk *clk;
+	const char *parent_name;
+	const char *name = np->name;
+
+	parent_name = of_clk_get_parent_name(np, 0);
+
+	of_property_read_string(np, "clock-output-names", &name);
+
+	clk = at91_clk_register_utmi(name, parent_name);
+
+	if (IS_ERR(clk))
+		return;
+
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	return;
+}
+
+static void __init of_at91sam9x5_clk_utmi_setup(struct device_node *np)
+{
+	of_at91_clk_utmi_setup(np);
+}
+CLK_OF_DECLARE(at91sam9x5_clk_utmi, "atmel,at91sam9x5-clk-utmi",
+	       of_at91sam9x5_clk_utmi_setup);
+#endif
diff --git a/include/linux/clk/at91.h b/include/linux/clk/at91.h
index 3cafd36..47ef7e8 100644
--- a/include/linux/clk/at91.h
+++ b/include/linux/clk/at91.h
@@ -288,4 +288,8 @@ at91_clk_register_programmable(const char *name, const char **parent_names,
 			       u8 num_parents, u8 id,
 			       struct clk_programmable_layout *layout);
 
+
+struct clk * __init
+at91_clk_register_utmi(const char *name, const char *parent_name);
+
 #endif
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 09:52:18 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 15:52:18 +0200
Subject: [PATCH v2 09/42] ARM: at91: add PMC usb clock
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374069138-14101-1-git-send-email-b.brezillon@overkiz.com>

This is the at91 usb clock implementation using common clk framework.
This clock is used to clock usb ports (ohci, ehci and udc).

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/Kconfig |   11 ++
 drivers/clk/at91/Makefile  |    1 +
 drivers/clk/at91/clk-usb.c |  303 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/clk/at91.h   |    9 ++
 4 files changed, 324 insertions(+)
 create mode 100644 drivers/clk/at91/clk-usb.c

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 1a24a1f..ac18755 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -3,6 +3,9 @@ if ARCH_AT91
 config HAVE_AT91_UTMI
 	bool
 
+config HAVE_AT91_USB_CLK
+	bool
+
 config HAVE_AT91_DBGU0
 	bool
 
@@ -69,6 +72,7 @@ config SOC_SAMA5D3
 	select HAVE_FB_ATMEL
 	select HAVE_AT91_DBGU1
 	select HAVE_AT91_UTMI
+	select HAVE_AT91_USB_CLK
 	help
 	  Select this if you are using one of Atmel's SAMA5D3 family SoC.
 	  This support covers SAMA5D31, SAMA5D33, SAMA5D34, SAMA5D35.
@@ -82,11 +86,13 @@ config SOC_AT91RM9200
 	select HAVE_AT91_DBGU0
 	select MULTI_IRQ_HANDLER
 	select SPARSE_IRQ
+	select HAVE_AT91_USB_CLK
 
 config SOC_AT91SAM9260
 	bool "AT91SAM9260, AT91SAM9XE or AT91SAM9G20"
 	select HAVE_AT91_DBGU0
 	select SOC_AT91SAM9
+	select HAVE_AT91_USB_CLK
 	help
 	  Select this if you are using one of Atmel's AT91SAM9260, AT91SAM9XE
 	  or AT91SAM9G20 SoC.
@@ -96,6 +102,7 @@ config SOC_AT91SAM9261
 	select HAVE_AT91_DBGU0
 	select HAVE_FB_ATMEL
 	select SOC_AT91SAM9
+	select HAVE_AT91_USB_CLK
 	help
 	  Select this if you are using one of Atmel's AT91SAM9261 or AT91SAM9G10 SoC.
 
@@ -104,6 +111,7 @@ config SOC_AT91SAM9263
 	select HAVE_AT91_DBGU1
 	select HAVE_FB_ATMEL
 	select SOC_AT91SAM9
+	select HAVE_AT91_USB_CLK
 
 config SOC_AT91SAM9RL
 	bool "AT91SAM9RL"
@@ -118,6 +126,7 @@ config SOC_AT91SAM9G45
 	select HAVE_FB_ATMEL
 	select SOC_AT91SAM9
 	select HAVE_AT91_UTMI
+	select HAVE_AT91_USB_CLK
 	help
 	  Select this if you are using one of Atmel's AT91SAM9G45 family SoC.
 	  This support covers AT91SAM9G45, AT91SAM9G46, AT91SAM9M10 and AT91SAM9M11.
@@ -128,6 +137,7 @@ config SOC_AT91SAM9X5
 	select HAVE_FB_ATMEL
 	select SOC_AT91SAM9
 	select HAVE_AT91_UTMI
+	select HAVE_AT91_USB_CLK
 	help
 	  Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
 	  This means that your SAM9 name finishes with a '5' (except if it is
@@ -140,6 +150,7 @@ config SOC_AT91SAM9N12
 	select HAVE_AT91_DBGU0
 	select HAVE_FB_ATMEL
 	select SOC_AT91SAM9
+	select HAVE_AT91_USB_CLK
 	help
 	  Select this if you are using Atmel's AT91SAM9N12 SoC.
 
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 76d09f0..bbfd245 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -7,3 +7,4 @@ obj-y += clk-system.o clk-peripheral.o
 
 obj-$(CONFIG_AT91_PROGRAMMABLE_CLOCKS)	+= clk-programmable.o
 obj-$(CONFIG_HAVE_AT91_UTMI)		+= clk-utmi.o
+obj-$(CONFIG_HAVE_AT91_USB_CLK)		+= clk-usb.o
diff --git a/drivers/clk/at91/clk-usb.c b/drivers/clk/at91/clk-usb.c
new file mode 100644
index 0000000..4af0fe3
--- /dev/null
+++ b/drivers/clk/at91/clk-usb.c
@@ -0,0 +1,303 @@
+/*
+ * drivers/clk/at91/clk-usb.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/clk/at91.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+
+#define USB_SOURCE_MAX		2
+
+#define to_at91sam9x5_clk_usb(hw) \
+	container_of(hw, struct at91sam9x5_clk_usb, hw)
+struct at91sam9x5_clk_usb {
+	struct clk_hw hw;
+	u8 usbs0_unused; /* sam9n12 uses usbs0 to disable usb clock */
+};
+
+#define to_at91rm9200_clk_usb(hw) \
+	container_of(hw, struct at91rm9200_clk_usb, hw)
+struct at91rm9200_clk_usb {
+	struct clk_hw hw;
+	u32 divisors[4];
+};
+
+static unsigned long at91sam9x5_clk_usb_recalc_rate(struct clk_hw *hw,
+						    unsigned long parent_rate)
+{
+	u32 tmp;
+	u8 usbdiv;
+	tmp = at91_pmc_read(AT91_PMC_USB);
+	usbdiv = (tmp & AT91_PMC_OHCIUSBDIV) >> 8;
+	return parent_rate / (usbdiv + 1);
+}
+
+static long at91sam9x5_clk_usb_round_rate(struct clk_hw *hw, unsigned long rate,
+					  unsigned long *parent_rate)
+{
+	unsigned long div;
+	unsigned long bestrate;
+	unsigned long tmp;
+
+	if (rate >= *parent_rate)
+		return *parent_rate;
+
+	div = *parent_rate / rate;
+	if (div > 15)
+		return *parent_rate / 16;
+
+	bestrate = *parent_rate / div;
+	tmp = *parent_rate / (div + 1);
+	if (bestrate - rate > rate - tmp)
+		bestrate = tmp;
+
+	return bestrate;
+}
+
+static int at91sam9x5_clk_usb_set_parent(struct clk_hw *hw, u8 index)
+{
+	u32 tmp;
+	struct at91sam9x5_clk_usb *usb = to_at91sam9x5_clk_usb(hw);
+	if (usb->usbs0_unused)
+		index++;
+	if (index > 1)
+		return -EINVAL;
+	tmp = at91_pmc_read(AT91_PMC_USB) & ~AT91_PMC_USBS;
+	if (index)
+		tmp |= AT91_PMC_USBS;
+	at91_pmc_write(AT91_PMC_USB, tmp);
+	return 0;
+}
+
+static u8 at91sam9x5_clk_usb_get_parent(struct clk_hw *hw)
+{
+	struct at91sam9x5_clk_usb *usb = to_at91sam9x5_clk_usb(hw);
+	if (usb->usbs0_unused)
+		return 0;
+	return at91_pmc_read(AT91_PMC_USB) & AT91_PMC_USBS;
+}
+
+static int at91sam9x5_clk_usb_set_rate(struct clk_hw *hw, unsigned long rate,
+				       unsigned long parent_rate)
+{
+	u32 tmp;
+	unsigned long div = parent_rate / rate;
+	if (parent_rate % rate || div < 1 || div > 16)
+		return -EINVAL;
+	tmp = at91_pmc_read(AT91_PMC_USB) & ~AT91_PMC_OHCIUSBDIV;
+	tmp |= (div - 1) << 8;
+	at91_pmc_write(AT91_PMC_USB, tmp);
+
+	return 0;
+}
+
+static const struct clk_ops at91sam9x5_usb_ops = {
+	.recalc_rate = at91sam9x5_clk_usb_recalc_rate,
+	.round_rate = at91sam9x5_clk_usb_round_rate,
+	.get_parent = at91sam9x5_clk_usb_get_parent,
+	.set_parent = at91sam9x5_clk_usb_set_parent,
+	.set_rate = at91sam9x5_clk_usb_set_rate,
+};
+
+struct clk * __init
+at91sam9x5_clk_register_usb(const char *name, const char **parent_names,
+			    u8 num_parents, u8 usbs0_unused)
+{
+	struct at91sam9x5_clk_usb *usb;
+	struct clk *clk = NULL;
+	struct clk_init_data init;
+
+	usb = kzalloc(sizeof(*usb), GFP_KERNEL);
+	if (!usb)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &at91sam9x5_usb_ops;
+	init.parent_names = parent_names;
+	init.num_parents = num_parents;
+	init.flags = CLK_SET_RATE_GATE | CLK_SET_PARENT_GATE;
+
+	usb->usbs0_unused = usbs0_unused;
+	usb->hw.init = &init;
+
+	clk = clk_register(NULL, &usb->hw);
+
+	if (IS_ERR(clk))
+		kfree(usb);
+
+	return clk;
+}
+
+static unsigned long at91rm9200_clk_usb_recalc_rate(struct clk_hw *hw,
+						    unsigned long parent_rate)
+{
+	struct at91rm9200_clk_usb *usb = to_at91rm9200_clk_usb(hw);
+	u32 tmp;
+	u8 usbdiv;
+	tmp = at91_pmc_read(AT91_CKGR_PLLBR);
+	usbdiv = (tmp & AT91_PMC_USBDIV) >> 28;
+	if (usb->divisors[usbdiv])
+		return parent_rate / usb->divisors[usbdiv];
+	return 0;
+}
+
+static long at91rm9200_clk_usb_round_rate(struct clk_hw *hw, unsigned long rate,
+					  unsigned long *parent_rate)
+{
+	struct at91rm9200_clk_usb *usb = to_at91rm9200_clk_usb(hw);
+	unsigned long bestrate = 0;
+	int bestdiff = -1;
+	unsigned long tmprate;
+	int tmpdiff;
+	int i = 0;
+
+	for (i = 0; i < 4; i++) {
+		if (!usb->divisors[i])
+			continue;
+		tmprate = *parent_rate / usb->divisors[i];
+		if (tmprate < rate)
+			tmpdiff = rate - tmprate;
+		else
+			tmpdiff = tmprate - rate;
+
+		if (bestdiff < 0 || bestdiff > tmpdiff) {
+			bestrate = tmprate;
+			bestdiff = tmpdiff;
+		}
+
+		if (!bestdiff)
+			break;
+	}
+
+	return bestrate;
+}
+
+static int at91rm9200_clk_usb_set_rate(struct clk_hw *hw, unsigned long rate,
+				       unsigned long parent_rate)
+{
+	u32 tmp;
+	int i;
+	struct at91rm9200_clk_usb *usb = to_at91rm9200_clk_usb(hw);
+	unsigned long div = parent_rate / rate;
+	if (parent_rate % rate)
+		return -EINVAL;
+	for (i = 0; i < 4; i++) {
+		if (usb->divisors[i] == div) {
+			tmp = at91_pmc_read(AT91_CKGR_PLLBR) &
+			      ~AT91_PMC_USBDIV;
+			tmp |= i << 8;
+			at91_pmc_write(AT91_PMC_USB, tmp);
+			return 0;
+		}
+	}
+
+	return -EINVAL;
+}
+
+static const struct clk_ops at91rm9200_usb_ops = {
+	.recalc_rate = at91rm9200_clk_usb_recalc_rate,
+	.round_rate = at91rm9200_clk_usb_round_rate,
+	.set_rate = at91rm9200_clk_usb_set_rate,
+};
+
+struct clk * __init
+at91rm9200_clk_register_usb(const char *name, const char *parent_name,
+			    const u32 *divisors)
+{
+	struct at91rm9200_clk_usb *usb;
+	struct clk *clk = NULL;
+	struct clk_init_data init;
+
+	usb = kzalloc(sizeof(*usb), GFP_KERNEL);
+	if (!usb)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &at91rm9200_usb_ops;
+	init.parent_names = &parent_name;
+	init.num_parents = 1;
+	init.flags = 0;
+
+	usb->hw.init = &init;
+	memcpy(usb->divisors, divisors, sizeof(usb->divisors));
+
+	clk = clk_register(NULL, &usb->hw);
+
+	if (IS_ERR(clk))
+		kfree(usb);
+
+	return clk;
+}
+
+#if defined(CONFIG_OF)
+static void __init of_at91sam9x5_clk_usb_setup(struct device_node *np)
+{
+	struct clk *clk;
+	int i;
+	int num_parents;
+	u8 usbs0_unused;
+	const char *parent_names[USB_SOURCE_MAX];
+	const char *name = np->name;
+
+	num_parents = of_count_phandle_with_args(np, "clocks", "#clock-cells");
+	if (num_parents <= 0 || num_parents > USB_SOURCE_MAX)
+		return;
+
+	for (i = 0; i < num_parents; i++) {
+		parent_names[i] = of_clk_get_parent_name(np, i);
+		if (!parent_names[i])
+			return;
+	}
+
+	usbs0_unused = of_property_read_bool(np, "usbs0-unused");
+	of_property_read_string(np, "clock-output-names", &name);
+
+	clk = at91sam9x5_clk_register_usb(name, parent_names, num_parents,
+					  usbs0_unused);
+
+	if (IS_ERR(clk))
+		return;
+
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+}
+CLK_OF_DECLARE(at91sam9x5_clk_usb, "atmel,at91sam9x5-clk-usb",
+	       of_at91sam9x5_clk_usb_setup);
+
+static void __init of_at91rm9200_clk_usb_setup(struct device_node *np)
+{
+	struct clk *clk;
+	const char *parent_name;
+	const char *name = np->name;
+	u32 divisors[4] = {0, 0, 0, 0};
+
+	parent_name = of_clk_get_parent_name(np, 0);
+	if (!parent_name)
+		return;
+
+	of_property_read_u32_array(np, "divisors", divisors, 4);
+	if (!divisors[0])
+		return;
+
+	of_property_read_string(np, "clock-output-names", &name);
+
+	clk = at91rm9200_clk_register_usb(name, parent_name, divisors);
+
+	if (IS_ERR(clk))
+		return;
+
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+}
+CLK_OF_DECLARE(at91rm9200_clk_usb, "atmel,at91rm9200-clk-usb",
+	       of_at91rm9200_clk_usb_setup);
+#endif
diff --git a/include/linux/clk/at91.h b/include/linux/clk/at91.h
index 47ef7e8..2d083d1 100644
--- a/include/linux/clk/at91.h
+++ b/include/linux/clk/at91.h
@@ -292,4 +292,13 @@ at91_clk_register_programmable(const char *name, const char **parent_names,
 struct clk * __init
 at91_clk_register_utmi(const char *name, const char *parent_name);
 
+
+struct clk * __init
+at91rm9200_clk_register_usb(const char *name, const char *parent_name,
+			    const u32 *divisors);
+
+struct clk * __init
+at91sam9x5_clk_register_usb(const char *name, const char **parent_names,
+			    u8 num_parents, u8 usbs0_unused);
+
 #endif
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 09:53:31 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 15:53:31 +0200
Subject: [PATCH v2 10/42] ARM: at91: add PMC smd clock
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374069211-14142-1-git-send-email-b.brezillon@overkiz.com>

This is the at91 smd (Soft Modem) clock implementation using common clk
framework.

Not used by any driver right now.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/Kconfig |    5 ++
 drivers/clk/at91/Makefile  |    1 +
 drivers/clk/at91/clk-smd.c |  157 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 163 insertions(+)
 create mode 100644 drivers/clk/at91/clk-smd.c

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index ac18755..c8e02ca 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -27,6 +27,9 @@ config AT91_SAM9G45_RESET
 config AT91_SAM9_TIME
 	bool
 
+config HAVE_AT91_SMD
+	bool
+
 config SOC_AT91SAM9
 	bool
 	select AT91_SAM9_TIME
@@ -72,6 +75,7 @@ config SOC_SAMA5D3
 	select HAVE_FB_ATMEL
 	select HAVE_AT91_DBGU1
 	select HAVE_AT91_UTMI
+	select HAVE_AT91_SMD
 	select HAVE_AT91_USB_CLK
 	help
 	  Select this if you are using one of Atmel's SAMA5D3 family SoC.
@@ -137,6 +141,7 @@ config SOC_AT91SAM9X5
 	select HAVE_FB_ATMEL
 	select SOC_AT91SAM9
 	select HAVE_AT91_UTMI
+	select HAVE_AT91_SMD
 	select HAVE_AT91_USB_CLK
 	help
 	  Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index bbfd245..7206f4c 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -8,3 +8,4 @@ obj-y += clk-system.o clk-peripheral.o
 obj-$(CONFIG_AT91_PROGRAMMABLE_CLOCKS)	+= clk-programmable.o
 obj-$(CONFIG_HAVE_AT91_UTMI)		+= clk-utmi.o
 obj-$(CONFIG_HAVE_AT91_USB_CLK)		+= clk-usb.o
+obj-$(CONFIG_HAVE_AT91_SMD)		+= clk-smd.o
diff --git a/drivers/clk/at91/clk-smd.c b/drivers/clk/at91/clk-smd.c
new file mode 100644
index 0000000..61bd8a5
--- /dev/null
+++ b/drivers/clk/at91/clk-smd.c
@@ -0,0 +1,157 @@
+/*
+ * drivers/clk/at91/clk-smd.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/clk/at91.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+
+#define SMD_SOURCE_MAX		2
+
+#define to_at91sam9x5_clk_smd(hw) \
+	container_of(hw, struct at91sam9x5_clk_smd, hw)
+struct at91sam9x5_clk_smd {
+	struct clk_hw hw;
+};
+
+static unsigned long at91sam9x5_clk_smd_recalc_rate(struct clk_hw *hw,
+						    unsigned long parent_rate)
+{
+	u32 tmp;
+	u8 smddiv;
+	tmp = at91_pmc_read(AT91_PMC_SMD);
+	smddiv = (tmp & AT91_PMC_SMD_DIV) >> 8;
+	return parent_rate / (smddiv + 1);
+}
+
+static long at91sam9x5_clk_smd_round_rate(struct clk_hw *hw, unsigned long rate,
+					  unsigned long *parent_rate)
+{
+	unsigned long div;
+	unsigned long bestrate;
+	unsigned long tmp;
+
+	if (rate >= *parent_rate)
+		return *parent_rate;
+
+	div = *parent_rate / rate;
+	if (div > 15)
+		return *parent_rate / 16;
+
+	bestrate = *parent_rate / div;
+	tmp = *parent_rate / (div + 1);
+	if (bestrate - rate > rate - tmp)
+		bestrate = tmp;
+
+	return bestrate;
+}
+
+static int at91sam9x5_clk_smd_set_parent(struct clk_hw *hw, u8 index)
+{
+	u32 tmp;
+	if (index > 1)
+		return -EINVAL;
+	tmp = at91_pmc_read(AT91_PMC_SMD) & ~AT91_PMC_SMDS;
+	if (index)
+		tmp |= AT91_PMC_SMDS;
+	at91_pmc_write(AT91_PMC_SMD, tmp);
+	return 0;
+}
+
+static u8 at91sam9x5_clk_smd_get_parent(struct clk_hw *hw)
+{
+	return at91_pmc_read(AT91_PMC_SMD) & AT91_PMC_SMDS;
+}
+
+static int at91sam9x5_clk_smd_set_rate(struct clk_hw *hw, unsigned long rate,
+				       unsigned long parent_rate)
+{
+	u32 tmp;
+	unsigned long div = parent_rate / rate;
+	if (parent_rate % rate || div < 1 || div > 16)
+		return -EINVAL;
+	tmp = at91_pmc_read(AT91_PMC_SMD) & ~AT91_PMC_SMD_DIV;
+	tmp |= (div - 1) << 8;
+	at91_pmc_write(AT91_PMC_SMD, tmp);
+
+	return 0;
+}
+
+static const struct clk_ops at91sam9x5_smd_ops = {
+	.recalc_rate = at91sam9x5_clk_smd_recalc_rate,
+	.round_rate = at91sam9x5_clk_smd_round_rate,
+	.get_parent = at91sam9x5_clk_smd_get_parent,
+	.set_parent = at91sam9x5_clk_smd_set_parent,
+	.set_rate = at91sam9x5_clk_smd_set_rate,
+};
+
+struct clk * __init
+at91sam9x5_clk_register_smd(const char *name, const char **parent_names,
+			    u8 num_parents)
+{
+	struct at91sam9x5_clk_smd *smd;
+	struct clk *clk = NULL;
+	struct clk_init_data init;
+
+	smd = kzalloc(sizeof(*smd), GFP_KERNEL);
+	if (!smd)
+		return ERR_PTR(-ENOMEM);
+
+	init.name = name;
+	init.ops = &at91sam9x5_smd_ops;
+	init.parent_names = parent_names;
+	init.num_parents = num_parents;
+	init.flags = CLK_SET_RATE_GATE | CLK_SET_PARENT_GATE;
+
+	smd->hw.init = &init;
+
+	clk = clk_register(NULL, &smd->hw);
+
+	if (IS_ERR(clk))
+		kfree(smd);
+
+	return clk;
+}
+
+#if defined(CONFIG_OF)
+static void __init of_at91sam9x5_clk_smd_setup(struct device_node *np)
+{
+	struct clk *clk;
+	int i;
+	int num_parents;
+	const char *parent_names[SMD_SOURCE_MAX];
+	const char *name = np->name;
+
+	num_parents = of_count_phandle_with_args(np, "clocks", "#clock-cells");
+	if (num_parents <= 0 || num_parents >= SMD_SOURCE_MAX)
+		return;
+
+	for (i = 0; i < num_parents; i++) {
+		parent_names[i] = of_clk_get_parent_name(np, i);
+		if (!parent_names[i])
+			return;
+	}
+
+	of_property_read_string(np, "clock-output-names", &name);
+
+	clk = at91sam9x5_clk_register_smd(name, parent_names, num_parents);
+
+	if (IS_ERR(clk))
+		return;
+
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+}
+CLK_OF_DECLARE(at91sam9x5_clk_smd, "atmel,at91sam9x5-clk-smd",
+	       of_at91sam9x5_clk_smd_setup);
+#endif
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 09:55:41 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 15:55:41 +0200
Subject: [PATCH v2 11/42] ARM: at91: add PMC clk device tree binding doc.
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374069341-14216-1-git-send-email-b.brezillon@overkiz.com>

This is the documentation of the dt bindings used by at91 clks.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 .../devicetree/bindings/clock/at91-clock.txt       |  262 ++++++++++++++++++++
 1 file changed, 262 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/at91-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt
new file mode 100644
index 0000000..ca98783
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
@@ -0,0 +1,262 @@
+Device Tree Clock bindings for arch-at91
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of the following:
+	"atmel,at91rm9200-clk-main":
+		at91 main oscillator
+
+	"atmel,at91rm9200-clk-master" or
+	"atmel,at91sam9x5-clk-master":
+		at91 master clock
+
+	"atmel,at91sam9x5-clk-peripheral" or
+	"atmel,at91rm9200-clk-peripheral":
+		at91 peripheral clocks
+
+	"atmel,at91rm9200-clk-pll" or
+	"atmel,at91sam9g45-clk-pll" or
+	"atmel,at91sam9g20-clk-pllb" or
+	"atmel,sama5d3-clk-pll":
+		at91 pll clocks
+
+	"atmel,at91sam9x5-clk-plldiv":
+		at91 plla divisor
+
+	"atmel,at91rm9200-clk-programmable" or
+	"atmel,at91sam9g45-clk-programmable" or
+	"atmel,at91sam9x5-clk-programmable":
+		at91 programmable clocks
+
+	"atmel,at91sam9x5-clk-smd":
+		at91 SMD (Soft Modem) clock
+
+	"atmel,at91rm9200-clk-system":
+		at91 system clocks
+
+	"atmel,at91rm9200-clk-usb" or
+	"atmel,at91sam9x5-clk-usb":
+		at91 usb clock
+
+	"atmel,at91sam9x5-clk-utmi":
+		at91 utmi clock
+
+
+Required properties for main clock:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks (optional if clock-frequency is provided) : shall be the slow clock
+	phandle. This clock is used to compute the main clock rate if
+	"clock-frequency" is not provided.
+- clock-frequency: the main oscillator frequency.Prefer the use of
+	"clock-frequency" over automatic clock rate computation.
+
+For example:
+	main: mainck {
+		compatible = "atmel,at91rm9200-clk-main";
+		#clock-cells = <0>;
+		clocks = <&ck32k>;
+		clock-frequency = <18432000>;
+	};
+
+Required properties for master clock:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the master clock sources (see atmel datasheet) phandles.
+	e.g. "<&ck32k>, <&main>, <&plla>, <&pllb>".
+- characteristics : device tree node describing master clock characteristics.
+	You can find these characteristics in atmel's SoC datasheets.
+	* output : minimum and maximum clock frequency (two u32 fields).
+		e.g. output = <0 133000000>; <=> 0 to 133MHz.
+	* divisors : master clock divisors table (four u32 fields).
+		0 <=> reserved value.
+		e.g. divisors = <1 2 4 6>;
+	* have-div3-pres : some SoC use the reserved value 7 in the PRES field
+		as CLOCK_DIV3 (e.g sam9x5).
+
+For example:
+	mck: mck {
+		compatible = "atmel,at91rm9200-clk-master";
+		#clock-cells = <0>;
+		characteristics = {
+			output = <0 133000000>;
+			divisors = <1 2 4 0>;
+		};
+	};
+
+Required properties for peripheral clocks:
+- #clock-cells : from common clock binding; shall be set to 1. The second cell
+	is used to encode the peripheral id. Peripheral ids are defined in
+	atmel's SoC datasheets.
+- clocks : shall be the master clock phandle.
+	e.g. clocks = <&mck>;
+- name at id: device tree node describing a specific system clock.
+	* id: peripheral id.
+	* default-divisor (optional, only available for
+	  "atmel,at91sam9x5-clk-peripheral"): sam9x5 and sama5d3 SoC provides
+	  configurable peripheral clock divisor. If you define this property
+	  (u32), the default divisor will be applied when enabling
+	  peripheral clock. If not provided the peripheral clock is not divided.
+
+For example:
+	periph: periphck {
+		compatible = "atmel,at91sam9x5-clk-peripheral";
+		#clock-cells = <1>;
+		clocks = <&mck>;
+
+		pioA_clk at 1 {
+			id = <1>;
+			default-divisor = <1>;
+		};
+
+		pioB_clk at 2 {
+			id = <2>;
+			default-divisor = <2>;
+		};
+	};
+
+
+Required properties for pll clocks:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the main clock phandle.
+- id : pll id
+	* 0 <=> plla
+	* 1 <=> pllb
+- characteristics : device tree node describing pll clock characteristics.
+	You can find these characteristics in atmel's SoC datasheets.
+	* input : minimum and maximum source clock frequency (two u32 fields).
+		e.g. input = <1 32000000>; <=> 1 to 32MHz.
+	* output : output frequency ranges.
+	* out: out field value for output frequency ranges.
+	* icpll (not available on some SoC): icpll field value for output
+		frequency ranges.
+
+For example:
+	plla: pllack {
+		compatible = "atmel,at91sam9g45-clk-pll";
+		#clock-cells = <0>;
+		clocks = <&main>;
+		id = <0>;
+		input = <2000000 32000000>;
+		output = <74500000 800000000
+			  69500000 750000000
+			  64500000 700000000
+			  59500000 650000000
+			  54500000 600000000
+			  49500000 550000000
+			  44500000 500000000
+			  40000000 450000000>;
+		out = <0 1 2 3 0 1 2 3>;
+		icpll = <0 0 0 0 1 1 1 1>;
+	};
+
+Required properties for plldiv clocks:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the plla clock phandle.
+
+For example:
+	plladiv: plladivck {
+		compatible = "atmel,at91sam9x5-clk-plldiv";
+		#clock-cells = <0>;
+		clocks = <&plla>;
+	};
+
+Required properties for programmable clocks:
+- #clock-cells : from common clock binding; shall be set to 1. The second cell
+	is used to encode the programmable clock id.
+	Peripheral ids are in atmel's SoC
+	datasheets.
+- clocks : shall be the programmable clock source phandles.
+	e.g. clocks = <&clk32k>, <&main>, <&plla>, <&pllb>;
+- name at id: device tree node describing a specific prog clock.
+	* id: programmable clock id (register offset from  PCKx register).
+
+For example:
+	prog: progck {
+		compatible = "atmel,at91sam9g45-clk-programmable";
+		#clock-cells = <1>;
+		clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>;
+
+		prog0 at 0 {
+			id = <0>;
+		};
+
+		prog1 at 1 {
+			id = <1>;
+		};
+	};
+
+
+Required properties for smd clock:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the smd clock source phandles.
+	e.g. clocks = <&plladiv>, <&utmi>;
+
+For example:
+	smd: smdck {
+		compatible = "atmel,at91sam9x5-clk-smd";
+		#clock-cells = <0>;
+		clocks = <&plladiv>, <&utmi>;
+	};
+
+Required properties for system clocks:
+- #clock-cells : from common clock binding; shall be set to 1. The second cell
+	is used to encode the system clock id (bit used in SCER/SCDR register).
+- name at id: device tree node describing a specific system clock.
+	* id: system clock id (bit position in SCER/SCDR/SCSR registers).
+
+For example:
+	system: systemck {
+		compatible = "atmel,at91rm9200-clk-system";
+		#clock-cells = <1>;
+
+		ddrck at 2 {
+			id = <2>;
+		};
+
+		uhpck at 6 {
+			id = <6>;
+		};
+
+		udpck at 7 {
+			id = <7>;
+		};
+	};
+
+
+Required properties for usb clock:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the smd clock source phandles.
+	e.g. clocks = <&pllb>;
+- divisors (only available for "atmel,at91rm9200-clk-usb"):
+	usb clock divisor table.
+	e.g. divisors = <1 2 4 0>;
+- usbs0-unused (only available for "atmel,at91sam9x5-clk-usb"):
+	Some SoC (sam9n12) use usb source 0 to disable the usb clock.
+
+For example:
+	usb: usbck {
+		compatible = "atmel,at91sam9x5-clk-usb";
+		#clock-cells = <0>;
+		clocks = <&plladiv>, <&utmi>;
+	};
+
+	usb: usbck {
+		compatible = "atmel,at91rm9200-clk-usb";
+		#clock-cells = <0>;
+		clocks = <&pllb>;
+		divisors = <1 2 4 0>;
+	};
+
+
+Required properties for utmi clock:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the main clock source phandle.
+
+For example:
+	utmi: utmick {
+		compatible = "atmel,at91sam9x5-clk-utmi";
+		#clock-cells = <0>;
+		clocks = <&main>;
+	};
-- 
1.7.9.5



From nico at linaro.org  Wed Jul 17 09:56:59 2013
From: nico at linaro.org (Nicolas Pitre)
Date: Wed, 17 Jul 2013 09:56:59 -0400 (EDT)
Subject: [PATCH] ARM: locks: remove opencoded #16 for ticket shift
In-Reply-To: <1373894879-30559-1-git-send-email-will.deacon@arm.com>
References: <1373894879-30559-1-git-send-email-will.deacon@arm.com>
Message-ID: <alpine.LFD.2.03.1307170952580.14924@syhkavp.arg>

On Mon, 15 Jul 2013, Will Deacon wrote:

> The ticket width of our spinlocks is defined by TICKET_SHIFT, so remove
> the opencoded #16 from the trylock implementation.
> 
> Signed-off-by: Will Deacon <will.deacon at arm.com>

This is pointless.

>  		"	ldrex	%0, [%3]\n"
>  		"	mov	%2, #0\n"
> -		"	subs	%1, %0, %0, ror #16\n"

Any value other than 16 would break that code.  You'd rather ensure it 
never gets defined to anything else.


Nicolas


From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:15 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:15 +0100
Subject: [RFC PATCH v2 06/15] drivers/bus: arm-cci: avoid parsing DT for cpu
 device nodes
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-7-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Since the CPU device nodes can be retrieved using arch_of_get_cpu_node,
we can use it to avoid parsing the cpus node searching the cpu nodes and
mapping to logical index.

This patch removes parsing DT for cpu nodes by using of_get_cpu_node.

Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/bus/arm-cci.c | 28 +++++++---------------------
 1 file changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 7332889..7dd891c 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -122,17 +122,8 @@ EXPORT_SYMBOL_GPL(cci_ace_get_port);
 
 static void __init cci_ace_init_ports(void)
 {
-	int port, ac, cpu;
-	u64 hwid;
-	const u32 *cell;
-	struct device_node *cpun, *cpus;
-
-	cpus = of_find_node_by_path("/cpus");
-	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
-		return;
-
-	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
-		ac = of_n_addr_cells(cpus);
+	int port, cpu;
+	struct device_node *cpun;
 
 	/*
 	 * Port index look-up speeds up the function disabling ports by CPU,
@@ -141,18 +132,13 @@ static void __init cci_ace_init_ports(void)
 	 * The stashed index array is initialized for all possible CPUs
 	 * at probe time.
 	 */
-	for_each_child_of_node(cpus, cpun) {
-		if (of_node_cmp(cpun->type, "cpu"))
-			continue;
-		cell = of_get_property(cpun, "reg", NULL);
-		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
-			continue;
-
-		hwid = of_read_number(cell, ac);
-		cpu = get_logical_index(hwid & MPIDR_HWID_BITMASK);
+	for_each_possible_cpu(cpu) {
+		/* too early to use cpu->of_node */
+		cpun = of_get_cpu_node(cpu);
 
-		if (cpu < 0 || !cpu_possible(cpu))
+		if (WARN(!cpun, "Missing cpu device node\n"))
 			continue;
+
 		port = __cci_ace_get_port(cpun, ACE_PORT);
 		if (port < 0)
 			continue;
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:10 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:10 +0100
Subject: [RFC PATCH v2 01/15] of: add support for retrieving cpu node for a
 given logical cpu index
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Currently different drivers requiring to access cpu device node are
parsing the device tree themselves. Since the ordering in the DT need
not match the logical cpu ordering, the parsing logic needs to consider
that. However, this has resulted in lots of code duplication and in some
cases even incorrect logic.

It's better to consolidate them by adding support for getting cpu
device node for a given logical cpu index in DT core library. However
logical to physical index mapping can be architecture specific.

This patch adds of_get_cpu_node to retrieve a cpu device node for a
given logical cpu index. The default matching of the physical id to the
logical cpu index can be overridden by architecture specific code.

It is recommended to use these helper function only in pre-SMP/early
initialisation stages to retrieve CPU device node pointers in logical
ordering. Once the cpu devices are registered, it can be retrieved easily
from cpu device of_node which avoids unnecessary parsing and matching.

Cc: Rob Herring <rob.herring at calxeda.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/of/base.c  | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of.h |  5 +++++
 2 files changed, 71 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5c54279..363b8f9 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -230,6 +230,72 @@ const void *of_get_property(const struct device_node *np, const char *name,
 }
 EXPORT_SYMBOL(of_get_property);
 
+/*
+ * arch_match_cpu_phys_id - Match the given logical CPU and physical id
+ *
+ * @cpu: logical index of a cpu
+ * @phys_id: physical identifier of a cpu
+ *
+ * CPU logical to physical index mapping is architecure specific.
+ * However this __weak function provides a default match of physical
+ * id to logical cpu index.
+ *
+ * Returns 1 if the physical identifier and the logical index correspond
+ * to the same cpu, 0 otherwise.
+ */
+int __weak arch_match_cpu_phys_id(int cpu, u64 phys_id)
+{
+	return (u32)phys_id == cpu;
+}
+
+/**
+ * of_get_cpu_node - Get device node associated with the given logical CPU
+ *
+ * @cpu: CPU number(logical index) for which device node is required
+ *
+ * The main purpose of this function is to retrieve the device node for the
+ * given logical CPU index. It should be used to intialise the of_node in
+ * cpu device. Once of_node in cpu device is populated, all the further
+ * references can use that instead.
+ *
+ * CPU logical to physical index mapping is architecure specific and is built
+ * before booting secondary cores. This function uses arch_match_cpu_phys_id
+ * which can be overridden by architecture specific implementation.
+ *
+ * Returns a node pointer for the logical cpu if found, else NULL.
+ */
+struct device_node *of_get_cpu_node(int cpu)
+{
+	struct device_node *cpun, *cpus;
+	const u32 *cell;
+	u64 hwid;
+	int ac, prop_len;
+
+	cpus = of_find_node_by_path("/cpus");
+	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
+		return NULL;
+
+	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
+		ac = of_n_addr_cells(cpus);
+
+	for_each_child_of_node(cpus, cpun) {
+		if (of_node_cmp(cpun->type, "cpu"))
+			continue;
+		cell = of_get_property(cpun, "reg", &prop_len);
+		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
+			continue;
+
+		while (prop_len) {
+			hwid = of_read_number(cell, ac);
+			prop_len -= ac;
+			if (arch_match_cpu_phys_id(cpu, hwid))
+				return cpun;
+		}
+	}
+
+	return NULL;
+}
+
 /** Checks if the given "compat" string matches one of the strings in
  * the device's "compatible" property
  */
diff --git a/include/linux/of.h b/include/linux/of.h
index 1fd08ca..150b48e 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -266,6 +266,7 @@ extern int of_device_is_available(const struct device_node *device);
 extern const void *of_get_property(const struct device_node *node,
 				const char *name,
 				int *lenp);
+extern struct device_node *of_get_cpu_node(int cpu);
 #define for_each_property_of_node(dn, pp) \
 	for (pp = dn->properties; pp != NULL; pp = pp->next)
 
@@ -458,6 +459,10 @@ static inline const void *of_get_property(const struct device_node *node,
 {
 	return NULL;
 }
+static inline struct device_node *of_get_cpu_node(int cpu)
+{
+	return NULL;
+}
 
 static inline int of_property_read_u64(const struct device_node *np,
 				       const char *propname, u64 *out_value)
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:11 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:11 +0100
Subject: [RFC PATCH v2 02/15] driver/core: cpu: initialize of_node in cpu's
 device struture
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-3-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

CPUs are also registered as devices but the of_node in these cpu
devices are not initialized. Currently different drivers requiring
to access cpu device node are parsing the nodes themselves and
initialising the of_node in cpu device.

The of_node in all the cpu devices needs to be initialized properly
and at one place. The best place to update this is CPU subsystem
driver when registering the cpu devices.

The OF/DT core library now provides of_get_cpu_node to retrieve a cpu
device node for a given logical index by abstracting the architecture
specific details.

This patch uses of_get_cpu_node to assign of_node when registering the
cpu devices.

Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/base/cpu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index a16d20e..c0f7a08 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -14,6 +14,7 @@
 #include <linux/slab.h>
 #include <linux/percpu.h>
 #include <linux/acpi.h>
+#include <linux/of.h>
 
 #include "base.h"
 
@@ -289,6 +290,7 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
 	cpu->dev.release = cpu_device_release;
 	cpu->dev.offline_disabled = !cpu->hotpluggable;
 	cpu->dev.offline = !cpu_online(num);
+	cpu->dev.of_node = of_get_cpu_node(num);
 #ifdef CONFIG_ARCH_HAS_CPU_AUTOPROBE
 	cpu->dev.bus->uevent = arch_cpu_uevent;
 #endif
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:16 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:16 +0100
Subject: [RFC PATCH v2 07/15] cpufreq: imx6q-cpufreq: remove device tree
 parsing for cpu nodes
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-8-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Acked-by: Shawn Guo <shawn.guo at linaro.org>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/mach-imx/mach-imx6q.c  | 3 +--
 drivers/cpufreq/imx6q-cpufreq.c | 4 +---
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 7be13f8..a02f275 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -254,13 +254,12 @@ static void __init imx6q_opp_init(struct device *cpu_dev)
 {
 	struct device_node *np;
 
-	np = of_find_node_by_path("/cpus/cpu at 0");
+	np = of_node_get(cpu_dev->of_node);
 	if (!np) {
 		pr_warn("failed to find cpu0 node\n");
 		return;
 	}
 
-	cpu_dev->of_node = np;
 	if (of_init_opp_table(cpu_dev)) {
 		pr_warn("failed to init OPP table\n");
 		goto put_node;
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index e37cdae..b16632b 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -221,14 +221,12 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev)
 
 	cpu_dev = &pdev->dev;
 
-	np = of_find_node_by_path("/cpus/cpu at 0");
+	np = of_node_get(cpu_dev->of_node);
 	if (!np) {
 		dev_err(cpu_dev, "failed to find cpu0 node\n");
 		return -ENOENT;
 	}
 
-	cpu_dev->of_node = np;
-
 	arm_clk = devm_clk_get(cpu_dev, "arm");
 	pll1_sys_clk = devm_clk_get(cpu_dev, "pll1_sys");
 	pll1_sw_clk = devm_clk_get(cpu_dev, "pll1_sw");
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:17 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:17 +0100
Subject: [RFC PATCH v2 08/15] cpufreq: cpufreq-cpu0: remove device tree
 parsing for cpu nodes
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-9-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Acked-by: Shawn Guo <shawn.guo at linaro.org>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/cpufreq-cpu0.c | 23 ++++-------------------
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..5b05c26 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -174,29 +174,17 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
 
 static int cpu0_cpufreq_probe(struct platform_device *pdev)
 {
-	struct device_node *np, *parent;
+	struct device_node *np;
 	int ret;
 
-	parent = of_find_node_by_path("/cpus");
-	if (!parent) {
-		pr_err("failed to find OF /cpus\n");
-		return -ENOENT;
-	}
-
-	for_each_child_of_node(parent, np) {
-		if (of_get_property(np, "operating-points", NULL))
-			break;
-	}
+	cpu_dev = &pdev->dev;
 
+	np = of_node_get(cpu_dev->of_node);
 	if (!np) {
 		pr_err("failed to find cpu0 node\n");
-		ret = -ENOENT;
-		goto out_put_parent;
+		return -ENOENT;
 	}
 
-	cpu_dev = &pdev->dev;
-	cpu_dev->of_node = np;
-
 	cpu_reg = devm_regulator_get(cpu_dev, "cpu0");
 	if (IS_ERR(cpu_reg)) {
 		/*
@@ -269,15 +257,12 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
 	}
 
 	of_node_put(np);
-	of_node_put(parent);
 	return 0;
 
 out_free_table:
 	opp_free_cpufreq_table(cpu_dev, &freq_table);
 out_put_node:
 	of_node_put(np);
-out_put_parent:
-	of_node_put(parent);
 	return ret;
 }
 
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:14 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:14 +0100
Subject: [RFC PATCH v2 05/15] ARM: mvebu: remove device tree parsing for cpu
 nodes
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-6-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Currently set_secondary_cpus_clock assume the CPU logical ordering
and the MPDIR in DT are same, which is incorrect.

Since the CPU device nodes can be retrieved in the logical ordering
using the DT helper, we can remove the devices tree parsing.

This patch removes DT parsing by making use of of_get_cpu_node.

Cc: Gregory Clement <gregory.clement at free-electrons.com>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Jason Cooper <jason at lakedaemon.net>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/mach-mvebu/platsmp.c | 52 ++++++++++++++++++++-----------------------
 1 file changed, 24 insertions(+), 28 deletions(-)

diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 93f2f3a..12585ad 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -23,51 +23,47 @@
 #include <linux/of.h>
 #include <linux/mbus.h>
 #include <asm/cacheflush.h>
+#include <asm/prom.h>
 #include <asm/smp_plat.h>
 #include "common.h"
 #include "armada-370-xp.h"
 #include "pmsu.h"
 #include "coherency.h"
 
+static struct clk *__init get_cpu_clk(int cpu)
+{
+	struct clk *cpu_clk;
+	struct device_node *np = of_get_cpu_node(cpu);
+
+	if (WARN(!np, "missing cpu node\n"))
+		return NULL;
+	cpu_clk = of_clk_get(np, 0);
+	if (WARN_ON(IS_ERR(cpu_clk)))
+		return NULL;
+	return cpu_clk;
+}
+
 void __init set_secondary_cpus_clock(void)
 {
-	int thiscpu;
+	int thiscpu, cpu;
 	unsigned long rate;
-	struct clk *cpu_clk = NULL;
-	struct device_node *np = NULL;
+	struct clk *cpu_clk;
 
 	thiscpu = smp_processor_id();
-	for_each_node_by_type(np, "cpu") {
-		int err;
-		int cpu;
-
-		err = of_property_read_u32(np, "reg", &cpu);
-		if (WARN_ON(err))
-			return;
-
-		if (cpu == thiscpu) {
-			cpu_clk = of_clk_get(np, 0);
-			break;
-		}
-	}
-	if (WARN_ON(IS_ERR(cpu_clk)))
+	cpu_clk = get_cpu_clk(thiscpu);
+	if (!cpu_clk)
 		return;
 	clk_prepare_enable(cpu_clk);
 	rate = clk_get_rate(cpu_clk);
 
 	/* set all the other CPU clk to the same rate than the boot CPU */
-	for_each_node_by_type(np, "cpu") {
-		int err;
-		int cpu;
-
-		err = of_property_read_u32(np, "reg", &cpu);
-		if (WARN_ON(err))
+	for_each_possible_cpu(cpu) {
+		if (cpu == thiscpu)
+			continue;
+		cpu_clk = get_cpu_clk(cpu);
+		if (!cpu_clk)
 			return;
-
-		if (cpu != thiscpu) {
-			cpu_clk = of_clk_get(np, 0);
-			clk_set_rate(cpu_clk, rate);
-		}
+		clk_set_rate(cpu_clk, rate);
 	}
 }
 
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:12 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:12 +0100
Subject: [RFC PATCH v2 03/15] ARM: DT/kernel: define ARM specific
 arch_match_cpu_phys_id
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-4-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

OF/DT core library now provides architecture specific hook to match the
logical cpu index with the corresponding physical identifier. Most of the
cpu DT node parsing and initialisation is contained in devtree.c. So it's
better to define ARM specific arch_match_cpu_phys_id there.

This mainly helps to avoid replication of the code doing CPU node parsing
and physical(MPIDR) to logical mapping.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/kernel/devtree.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 5859c8b..5a36f32 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -169,6 +169,11 @@ void __init arm_dt_init_cpu_maps(void)
 	}
 }
 
+int arch_match_cpu_phys_id(int cpu, u64 phys_id)
+{
+	return (phys_id & MPIDR_HWID_BITMASK) == cpu_logical_map(cpu);
+}
+
 /**
  * setup_machine_fdt - Machine setup when an dtb was passed to the kernel
  * @dt_phys: physical address of dt blob
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:13 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:13 +0100
Subject: [RFC PATCH v2 04/15] ARM: topology: remove hwid/MPIDR dependency from
 cpu_capacity
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-5-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Currently the topology code computes cpu capacity and stores it in
the list along with hwid(which is MPIDR) as it parses the CPU nodes
in the device tree. This is required as it needs to be mapped to the
logical CPU later.

Since the CPU device nodes can be retrieved in the logical ordering
using DT/OF helpers, its possible to store cpu_capacity also in logical
ordering and avoid storing hwid for each entry.

This patch removes hwid by making use of of_get_cpu_node.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/kernel/topology.c | 61 +++++++++++++++-------------------------------
 1 file changed, 19 insertions(+), 42 deletions(-)

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index c5a5954..28ef27a 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -74,12 +74,8 @@ struct cpu_efficiency table_efficiency[] = {
 	{NULL, },
 };
 
-struct cpu_capacity {
-	unsigned long hwid;
-	unsigned long capacity;
-};
-
-struct cpu_capacity *cpu_capacity;
+unsigned long *__cpu_capacity;
+#define cpu_capacity(cpu)	__cpu_capacity[cpu]
 
 unsigned long middle_capacity = 1;
 
@@ -100,15 +96,19 @@ static void __init parse_dt_topology(void)
 	unsigned long capacity = 0;
 	int alloc_size, cpu = 0;
 
-	alloc_size = nr_cpu_ids * sizeof(struct cpu_capacity);
-	cpu_capacity = kzalloc(alloc_size, GFP_NOWAIT);
+	alloc_size = nr_cpu_ids * sizeof(*__cpu_capacity);
+	__cpu_capacity = kzalloc(alloc_size, GFP_NOWAIT);
 
-	while ((cn = of_find_node_by_type(cn, "cpu"))) {
-		const u32 *rate, *reg;
+	for_each_possible_cpu(cpu) {
+		const u32 *rate;
 		int len;
 
-		if (cpu >= num_possible_cpus())
-			break;
+		/* too early to use cpu->of_node */
+		cn = of_get_cpu_node(cpu);
+		if (!cn) {
+			pr_err("missing device node for CPU %d\n", cpu);
+			continue;
+		}
 
 		for (cpu_eff = table_efficiency; cpu_eff->compatible; cpu_eff++)
 			if (of_device_is_compatible(cn, cpu_eff->compatible))
@@ -124,12 +124,6 @@ static void __init parse_dt_topology(void)
 			continue;
 		}
 
-		reg = of_get_property(cn, "reg", &len);
-		if (!reg || len != 4) {
-			pr_err("%s missing reg property\n", cn->full_name);
-			continue;
-		}
-
 		capacity = ((be32_to_cpup(rate)) >> 20) * cpu_eff->efficiency;
 
 		/* Save min capacity of the system */
@@ -140,13 +134,9 @@ static void __init parse_dt_topology(void)
 		if (capacity > max_capacity)
 			max_capacity = capacity;
 
-		cpu_capacity[cpu].capacity = capacity;
-		cpu_capacity[cpu++].hwid = be32_to_cpup(reg);
+		cpu_capacity(cpu) = capacity;
 	}
 
-	if (cpu < num_possible_cpus())
-		cpu_capacity[cpu].hwid = (unsigned long)(-1);
-
 	/* If min and max capacities are equals, we bypass the update of the
 	 * cpu_scale because all CPUs have the same capacity. Otherwise, we
 	 * compute a middle_capacity factor that will ensure that the capacity
@@ -154,9 +144,7 @@ static void __init parse_dt_topology(void)
 	 * SCHED_POWER_SCALE, which is the default value, but with the
 	 * constraint explained near table_efficiency[].
 	 */
-	if (min_capacity == max_capacity)
-		cpu_capacity[0].hwid = (unsigned long)(-1);
-	else if (4*max_capacity < (3*(max_capacity + min_capacity)))
+	if (4*max_capacity < (3*(max_capacity + min_capacity)))
 		middle_capacity = (min_capacity + max_capacity)
 				>> (SCHED_POWER_SHIFT+1);
 	else
@@ -170,23 +158,12 @@ static void __init parse_dt_topology(void)
  * boot. The update of all CPUs is in O(n^2) for heteregeneous system but the
  * function returns directly for SMP system.
  */
-void update_cpu_power(unsigned int cpu, unsigned long hwid)
+void update_cpu_power(unsigned int cpu)
 {
-	unsigned int idx = 0;
-
-	/* look for the cpu's hwid in the cpu capacity table */
-	for (idx = 0; idx < num_possible_cpus(); idx++) {
-		if (cpu_capacity[idx].hwid == hwid)
-			break;
-
-		if (cpu_capacity[idx].hwid == -1)
-			return;
-	}
-
-	if (idx == num_possible_cpus())
+	if (!cpu_capacity(cpu))
 		return;
 
-	set_power_scale(cpu, cpu_capacity[idx].capacity / middle_capacity);
+	set_power_scale(cpu, cpu_capacity(cpu) / middle_capacity);
 
 	printk(KERN_INFO "CPU%u: update cpu_power %lu\n",
 		cpu, arch_scale_freq_power(NULL, cpu));
@@ -194,7 +171,7 @@ void update_cpu_power(unsigned int cpu, unsigned long hwid)
 
 #else
 static inline void parse_dt_topology(void) {}
-static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {}
+static inline void update_cpu_power(unsigned int cpuid) {}
 #endif
 
  /*
@@ -281,7 +258,7 @@ void store_cpu_topology(unsigned int cpuid)
 
 	update_siblings_masks(cpuid);
 
-	update_cpu_power(cpuid, mpidr & MPIDR_HWID_BITMASK);
+	update_cpu_power(cpuid);
 
 	printk(KERN_INFO "CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n",
 		cpuid, cpu_topology[cpuid].thread_id,
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:18 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:18 +0100
Subject: [RFC PATCH v2 09/15] cpufreq: highbank-cpufreq: remove device tree
 parsing for cpu nodes
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-10-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Cc: Mark Langsdorf <mark.langsdorf at calxeda.com>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/highbank-cpufreq.c | 18 ++++++------------
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/cpufreq/highbank-cpufreq.c b/drivers/cpufreq/highbank-cpufreq.c
index b61b5a3..794123f 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -69,23 +69,17 @@ static int hb_cpufreq_driver_init(void)
 	if (!of_machine_is_compatible("calxeda,highbank"))
 		return -ENODEV;
 
-	for_each_child_of_node(of_find_node_by_path("/cpus"), np)
-		if (of_get_property(np, "operating-points", NULL))
-			break;
-
-	if (!np) {
-		pr_err("failed to find highbank cpufreq node\n");
-		return -ENOENT;
-	}
-
 	cpu_dev = get_cpu_device(0);
 	if (!cpu_dev) {
 		pr_err("failed to get highbank cpufreq device\n");
-		ret = -ENODEV;
-		goto out_put_node;
+		return -ENODEV;
 	}
 
-	cpu_dev->of_node = np;
+	np = of_node_get(cpu_dev->of_node);
+	if (!np) {
+		pr_err("failed to find highbank cpufreq node\n");
+		return -ENOENT;
+	}
 
 	cpu_clk = clk_get(cpu_dev, NULL);
 	if (IS_ERR(cpu_clk)) {
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:19 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:19 +0100
Subject: [RFC PATCH v2 10/15] cpufreq: spear-cpufreq: remove device tree
 parsing for cpu nodes
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-11-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Cc: Deepak Sikri <deepak.sikri at st.com>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/spear-cpufreq.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/spear-cpufreq.c b/drivers/cpufreq/spear-cpufreq.c
index c3efa7f..eb73c47 100644
--- a/drivers/cpufreq/spear-cpufreq.c
+++ b/drivers/cpufreq/spear-cpufreq.c
@@ -14,6 +14,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include <linux/clk.h>
+#include <linux/cpu.h>
 #include <linux/cpufreq.h>
 #include <linux/err.h>
 #include <linux/init.h>
@@ -218,12 +219,19 @@ static struct cpufreq_driver spear_cpufreq_driver = {
 static int spear_cpufreq_driver_init(void)
 {
 	struct device_node *np;
+	struct device *cpu_dev;
 	const struct property *prop;
 	struct cpufreq_frequency_table *freq_tbl;
 	const __be32 *val;
 	int cnt, i, ret;
 
-	np = of_find_node_by_path("/cpus/cpu at 0");
+	cpu_dev = get_cpu_device(0);
+	if (!cpu_dev) {
+		pr_err("failed to get cpu device\n");
+		return -ENODEV;
+	}
+
+	np = of_node_get(cpu_dev->of_node);
 	if (!np) {
 		pr_err("No cpu node found");
 		return -ENODEV;
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:20 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:20 +0100
Subject: [RFC PATCH v2 11/15] cpufreq: kirkwood-cpufreq: remove device tree
 parsing for cpu nodes
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-12-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Jason Cooper <jason at lakedaemon.net>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/kirkwood-cpufreq.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
index c233ea6..18aa3eb 100644
--- a/drivers/cpufreq/kirkwood-cpufreq.c
+++ b/drivers/cpufreq/kirkwood-cpufreq.c
@@ -13,6 +13,7 @@
 #include <linux/module.h>
 #include <linux/clk.h>
 #include <linux/clk-provider.h>
+#include <linux/cpu.h>
 #include <linux/cpufreq.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
@@ -165,6 +166,7 @@ static struct cpufreq_driver kirkwood_cpufreq_driver = {
 static int kirkwood_cpufreq_probe(struct platform_device *pdev)
 {
 	struct device_node *np;
+	struct device *cpu_dev;
 	struct resource *res;
 	int err;
 
@@ -175,9 +177,17 @@ static int kirkwood_cpufreq_probe(struct platform_device *pdev)
 	if (IS_ERR(priv.base))
 		return PTR_ERR(priv.base);
 
-	np = of_find_node_by_path("/cpus/cpu at 0");
-	if (!np)
+	cpu_dev = get_cpu_device(0);
+	if (!cpu_dev) {
+		dev_err(&pdev->dev, "failed to get cpu device\n");
 		return -ENODEV;
+	}
+
+	np = of_node_get(cpu_dev->of_node);
+	if (!np) {
+		dev_err(&pdev->dev, "failed to get cpu device node\n");
+		return -ENODEV;
+	}
 
 	priv.cpu_clk = of_clk_get_by_name(np, "cpu_clk");
 	if (IS_ERR(priv.cpu_clk)) {
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:09 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:09 +0100
Subject: [RFC PATCH v2 00/15] DT/core: update cpu device of_node
Message-ID: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

As more and more information is getting added into the cpu node, the number
of drivers needing to parse the device tree for CPU nodes are increasing.
Most of the time, the information needed from the cpu node is preferred
in the logical CPU order. Hence many drivers first parse and search the
CPU node, match them to logical index if needed and then search for the
required property inside a particular cpu node. Some of them assume the
logical and physical CPU ordering to be same which is incorrect.

This patch series initialises the of_node in all the cpu devices when
registering the CPU device.
1. This avoids different drivers having to parse the cpu nodes to obtain
   different attributes like operating points, latency,...etc.
2. This handles different physical and logical cpu ordering which is not
   the case in current code.
3. Also all the cpu nodes will have their of_node initialised correctly.
   Currently different drivers assign them partially and incorrectly.
4. Removes all the reduntant parsing in various drivers.

Changes v1->v2:
1. Moved most of arch_of_get_cpu_node to OF/DT core as of_get_cpu_node
   adding a provision for architecture specific hooks for matching
   logical and physical ids.
2. Extended removal of DT cpu node parsing to PPC cpufreq drivers
3. Added Acks from Viresh and Shawn

Regards,
Sudeep

Sudeep KarkadaNagesha (15):
  of: add support for retrieving cpu node for a given logical cpu index
  driver/core: cpu: initialize of_node in cpu's device struture
  ARM: DT/kernel: define ARM specific arch_match_cpu_phys_id
  ARM: topology: remove hwid/MPIDR dependency from cpu_capacity
  ARM: mvebu: remove device tree parsing for cpu nodes
  drivers/bus: arm-cci: avoid parsing DT for cpu device nodes
  cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
  cpufreq: highbank-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: spear-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: arm_big_little: remove device tree parsing for cpu nodes
  cpufreq: maple-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: pmac64-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: pmac32-cpufreq: remove device tree parsing for cpu nodes

 arch/arm/kernel/devtree.c           |  5 +++
 arch/arm/kernel/topology.c          | 61 +++++++++++-----------------------
 arch/arm/mach-imx/mach-imx6q.c      |  3 +-
 arch/arm/mach-mvebu/platsmp.c       | 52 ++++++++++++++---------------
 drivers/base/cpu.c                  |  2 ++
 drivers/bus/arm-cci.c               | 28 ++++------------
 drivers/cpufreq/arm_big_little_dt.c | 39 ++++++++++------------
 drivers/cpufreq/cpufreq-cpu0.c      | 23 +++----------
 drivers/cpufreq/highbank-cpufreq.c  | 18 ++++------
 drivers/cpufreq/imx6q-cpufreq.c     |  4 +--
 drivers/cpufreq/kirkwood-cpufreq.c  | 14 ++++++--
 drivers/cpufreq/maple-cpufreq.c     | 23 ++++---------
 drivers/cpufreq/pmac32-cpufreq.c    | 11 ++++++-
 drivers/cpufreq/pmac64-cpufreq.c    | 54 ++++++++++--------------------
 drivers/cpufreq/spear-cpufreq.c     | 10 +++++-
 drivers/of/base.c                   | 66 +++++++++++++++++++++++++++++++++++++
 include/linux/of.h                  |  5 +++
 17 files changed, 213 insertions(+), 205 deletions(-)

-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:21 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:21 +0100
Subject: [RFC PATCH v2 12/15] cpufreq: arm_big_little: remove device tree
 parsing for cpu nodes
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-13-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/arm_big_little_dt.c | 39 ++++++++++++++++---------------------
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/drivers/cpufreq/arm_big_little_dt.c b/drivers/cpufreq/arm_big_little_dt.c
index fd9e3ea..d2648d1 100644
--- a/drivers/cpufreq/arm_big_little_dt.c
+++ b/drivers/cpufreq/arm_big_little_dt.c
@@ -34,27 +34,19 @@
 /* get cpu node with valid operating-points */
 static struct device_node *get_cpu_node_with_valid_op(int cpu)
 {
-	struct device_node *np = NULL, *parent;
-	int count = 0;
+	struct device *cpu_dev = get_cpu_device(cpu);
+	struct device_node *np;
 
-	parent = of_find_node_by_path("/cpus");
-	if (!parent) {
-		pr_err("failed to find OF /cpus\n");
+	if (!cpu_dev) {
+		pr_err("failed to get cpu device\n");
 		return NULL;
 	}
-
-	for_each_child_of_node(parent, np) {
-		if (count++ != cpu)
-			continue;
-		if (!of_get_property(np, "operating-points", NULL)) {
-			of_node_put(np);
-			np = NULL;
-		}
-
-		break;
+	np = of_node_get(cpu_dev->of_node);
+	if (!of_get_property(np, "operating-points", NULL)) {
+		of_node_put(np);
+		np = NULL;
 	}
 
-	of_node_put(parent);
 	return np;
 }
 
@@ -63,11 +55,12 @@ static int dt_init_opp_table(struct device *cpu_dev)
 	struct device_node *np;
 	int ret;
 
-	np = get_cpu_node_with_valid_op(cpu_dev->id);
-	if (!np)
-		return -ENODATA;
+	np = of_node_get(cpu_dev->of_node);
+	if (!np) {
+		pr_err("failed to find cpu%d node\n", cpu_dev->id);
+		return -ENOENT;
+	}
 
-	cpu_dev->of_node = np;
 	ret = of_init_opp_table(cpu_dev);
 	of_node_put(np);
 
@@ -79,9 +72,11 @@ static int dt_get_transition_latency(struct device *cpu_dev)
 	struct device_node *np;
 	u32 transition_latency = CPUFREQ_ETERNAL;
 
-	np = get_cpu_node_with_valid_op(cpu_dev->id);
-	if (!np)
+	np = of_node_get(cpu_dev->of_node);
+	if (!np) {
+		pr_info("Failed to find cpu node. Use CPUFREQ_ETERNAL transition latency\n");
 		return CPUFREQ_ETERNAL;
+	}
 
 	of_property_read_u32(np, "clock-latency", &transition_latency);
 	of_node_put(np);
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:24 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:24 +0100
Subject: [RFC PATCH v2 15/15] cpufreq: pmac32-cpufreq: remove device tree
 parsing for cpu nodes
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-16-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes DT parsing and uses cpu->of_node instead.

Cc: Viresh Kumar <viresh.kumar at linaro.org>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/pmac32-cpufreq.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/pmac32-cpufreq.c b/drivers/cpufreq/pmac32-cpufreq.c
index 3104fad..b6822ee 100644
--- a/drivers/cpufreq/pmac32-cpufreq.c
+++ b/drivers/cpufreq/pmac32-cpufreq.c
@@ -21,6 +21,7 @@
 #include <linux/sched.h>
 #include <linux/adb.h>
 #include <linux/pmu.h>
+#include <linux/cpu.h>
 #include <linux/cpufreq.h>
 #include <linux/init.h>
 #include <linux/device.h>
@@ -643,6 +644,7 @@ static int pmac_cpufreq_init_750FX(struct device_node *cpunode)
  */
 static int __init pmac_cpufreq_setup(void)
 {
+	struct device *cpu_dev;
 	struct device_node	*cpunode;
 	const u32		*value;
 
@@ -650,7 +652,14 @@ static int __init pmac_cpufreq_setup(void)
 		return 0;
 
 	/* Assume only one CPU */
-	cpunode = of_find_node_by_type(NULL, "cpu");
+	cpu_dev = get_cpu_device(0);
+	if (!cpu_dev) {
+		pr_err("failed to get cpu device\n");
+		return -ENODEV;
+	}
+
+	/* Get first CPU node */
+	cpunode = of_node_get(cpu_dev->of_node);
 	if (!cpunode)
 		goto out;
 
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:22 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:22 +0100
Subject: [RFC PATCH v2 13/15] cpufreq: maple-cpufreq: remove device tree
 parsing for cpu nodes
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-14-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Cc: Viresh Kumar <viresh.kumar at linaro.org>
Cc: Dmitry Eremin-Solenikov <dbaryshkov at gmail.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/maple-cpufreq.c | 23 +++++++----------------
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/cpufreq/maple-cpufreq.c b/drivers/cpufreq/maple-cpufreq.c
index cdd6291..bc7233b 100644
--- a/drivers/cpufreq/maple-cpufreq.c
+++ b/drivers/cpufreq/maple-cpufreq.c
@@ -19,6 +19,7 @@
 #include <linux/kernel.h>
 #include <linux/delay.h>
 #include <linux/sched.h>
+#include <linux/cpu.h>
 #include <linux/cpufreq.h>
 #include <linux/init.h>
 #include <linux/completion.h>
@@ -201,7 +202,7 @@ static struct cpufreq_driver maple_cpufreq_driver = {
 
 static int __init maple_cpufreq_init(void)
 {
-	struct device_node *cpus;
+	struct device *cpu_dev;
 	struct device_node *cpunode;
 	unsigned int psize;
 	unsigned long max_freq;
@@ -217,24 +218,17 @@ static int __init maple_cpufreq_init(void)
 	    !of_machine_is_compatible("Momentum,Apache"))
 		return 0;
 
-	cpus = of_find_node_by_path("/cpus");
-	if (cpus == NULL) {
-		DBG("No /cpus node !\n");
+	cpu_dev = get_cpu_device(0);
+	if (!cpu_dev) {
+		pr_err("failed to get cpu device\n");
 		return -ENODEV;
 	}
 
 	/* Get first CPU node */
-	for (cpunode = NULL;
-	     (cpunode = of_get_next_child(cpus, cpunode)) != NULL;) {
-		const u32 *reg = of_get_property(cpunode, "reg", NULL);
-		if (reg == NULL || (*reg) != 0)
-			continue;
-		if (!strcmp(cpunode->type, "cpu"))
-			break;
-	}
+	cpunode = of_node_get(cpu_dev->of_node);
 	if (cpunode == NULL) {
 		printk(KERN_ERR "cpufreq: Can't find any CPU 0 node\n");
-		goto bail_cpus;
+		goto bail_noprops;
 	}
 
 	/* Check 970FX for now */
@@ -290,14 +284,11 @@ static int __init maple_cpufreq_init(void)
 	rc = cpufreq_register_driver(&maple_cpufreq_driver);
 
 	of_node_put(cpunode);
-	of_node_put(cpus);
 
 	return rc;
 
 bail_noprops:
 	of_node_put(cpunode);
-bail_cpus:
-	of_node_put(cpus);
 
 	return rc;
 }
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:06:23 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep.KarkadaNagesha at arm.com)
Date: Wed, 17 Jul 2013 15:06:23 +0100
Subject: [RFC PATCH v2 14/15] cpufreq: pmac64-cpufreq: remove device tree
 parsing for cpu nodes
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374069984-20567-15-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Cc: Viresh Kumar <viresh.kumar at linaro.org>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/pmac64-cpufreq.c | 54 ++++++++++++++--------------------------
 1 file changed, 18 insertions(+), 36 deletions(-)

diff --git a/drivers/cpufreq/pmac64-cpufreq.c b/drivers/cpufreq/pmac64-cpufreq.c
index 7ba4234..b60ccea 100644
--- a/drivers/cpufreq/pmac64-cpufreq.c
+++ b/drivers/cpufreq/pmac64-cpufreq.c
@@ -18,6 +18,7 @@
 #include <linux/kernel.h>
 #include <linux/delay.h>
 #include <linux/sched.h>
+#include <linux/cpu.h>
 #include <linux/cpufreq.h>
 #include <linux/init.h>
 #include <linux/completion.h>
@@ -383,9 +384,8 @@ static struct cpufreq_driver g5_cpufreq_driver = {
 
 #ifdef CONFIG_PMAC_SMU
 
-static int __init g5_neo2_cpufreq_init(struct device_node *cpus)
+static int __init g5_neo2_cpufreq_init(struct device_node *cpunode)
 {
-	struct device_node *cpunode;
 	unsigned int psize, ssize;
 	unsigned long max_freq;
 	char *freq_method, *volt_method;
@@ -405,20 +405,6 @@ static int __init g5_neo2_cpufreq_init(struct device_node *cpus)
 	else
 		return -ENODEV;
 
-	/* Get first CPU node */
-	for (cpunode = NULL;
-	     (cpunode = of_get_next_child(cpus, cpunode)) != NULL;) {
-		const u32 *reg = of_get_property(cpunode, "reg", NULL);
-		if (reg == NULL || (*reg) != 0)
-			continue;
-		if (!strcmp(cpunode->type, "cpu"))
-			break;
-	}
-	if (cpunode == NULL) {
-		printk(KERN_ERR "cpufreq: Can't find any CPU 0 node\n");
-		return -ENODEV;
-	}
-
 	/* Check 970FX for now */
 	valp = of_get_property(cpunode, "cpu-version", NULL);
 	if (!valp) {
@@ -537,9 +523,9 @@ static int __init g5_neo2_cpufreq_init(struct device_node *cpus)
 #endif /* CONFIG_PMAC_SMU */
 
 
-static int __init g5_pm72_cpufreq_init(struct device_node *cpus)
+static int __init g5_pm72_cpufreq_init(struct device_node *cpunode)
 {
-	struct device_node *cpuid = NULL, *hwclock = NULL, *cpunode = NULL;
+	struct device_node *cpuid = NULL, *hwclock = NULL;
 	const u8 *eeprom = NULL;
 	const u32 *valp;
 	u64 max_freq, min_freq, ih, il;
@@ -548,17 +534,6 @@ static int __init g5_pm72_cpufreq_init(struct device_node *cpus)
 	DBG("cpufreq: Initializing for PowerMac7,2, PowerMac7,3 and"
 	    " RackMac3,1...\n");
 
-	/* Get first CPU node */
-	for (cpunode = NULL;
-	     (cpunode = of_get_next_child(cpus, cpunode)) != NULL;) {
-		if (!strcmp(cpunode->type, "cpu"))
-			break;
-	}
-	if (cpunode == NULL) {
-		printk(KERN_ERR "cpufreq: Can't find any CPU node\n");
-		return -ENODEV;
-	}
-
 	/* Lookup the cpuid eeprom node */
         cpuid = of_find_node_by_path("/u3 at 0,f8000000/i2c at f8001000/cpuid at a0");
 	if (cpuid != NULL)
@@ -718,25 +693,32 @@ static int __init g5_pm72_cpufreq_init(struct device_node *cpus)
 
 static int __init g5_cpufreq_init(void)
 {
-	struct device_node *cpus;
+	struct device *cpu_dev;
+	struct device_node *cpunode;
 	int rc = 0;
 
-	cpus = of_find_node_by_path("/cpus");
-	if (cpus == NULL) {
-		DBG("No /cpus node !\n");
+	cpu_dev = get_cpu_device(0);
+	if (!cpu_dev) {
+		pr_err("failed to get cpu device\n");
+		return -ENODEV;
+	}
+
+	/* Get first CPU node */
+	cpunode = of_node_get(cpu_dev->of_node);
+	if (cpunode == NULL) {
+		pr_err("cpufreq: Can't find any CPU node\n");
 		return -ENODEV;
 	}
 
 	if (of_machine_is_compatible("PowerMac7,2") ||
 	    of_machine_is_compatible("PowerMac7,3") ||
 	    of_machine_is_compatible("RackMac3,1"))
-		rc = g5_pm72_cpufreq_init(cpus);
+		rc = g5_pm72_cpufreq_init(cpunode);
 #ifdef CONFIG_PMAC_SMU
 	else
-		rc = g5_neo2_cpufreq_init(cpus);
+		rc = g5_neo2_cpufreq_init(cpunode);
 #endif /* CONFIG_PMAC_SMU */
 
-	of_node_put(cpus);
 	return rc;
 }
 
-- 
1.8.1.2




From t.figa at samsung.com  Wed Jul 17 10:07:35 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Wed, 17 Jul 2013 16:07:35 +0200
Subject: [PATCH 1/3] ARM: EXYNOS: remove non-working AFTR mode support
In-Reply-To: <20130717133123.GA5453@e102568-lin.cambridge.arm.com>
References: <1372241627-22695-1-git-send-email-b.zolnierkie@samsung.com>
 <51E694BA.3030906@linaro.org>
 <20130717133123.GA5453@e102568-lin.cambridge.arm.com>
Message-ID: <3222513.hHN6nfv2Cl@amdc1227>

Hi,

On Wednesday 17 of July 2013 14:31:23 Lorenzo Pieralisi wrote:
> On Wed, Jul 17, 2013 at 01:57:30PM +0100, Daniel Lezcano wrote:
> > On 07/11/2013 03:14 PM, Bartlomiej Zolnierkiewicz wrote:
> > > Hi,
> > > 
> > > On Friday, June 28, 2013 11:47:49 PM Daniel Lezcano wrote:
> > >> On 06/28/2013 06:27 PM, Bartlomiej Zolnierkiewicz wrote:
> > >>> On Friday, June 28, 2013 01:20:09 PM Daniel Lezcano wrote:
> > >>>> On 06/28/2013 12:11 PM, Tomasz Figa wrote:
> > >>>>> Hi Daniel,
> > >>>>> 
> > >>>>> I've been fighting with this whole AFTR state as well, before
> > >>>>> Bartlomiej. Let me share my thoughts on this.
> > >> 
> > >> [ ... ]
> > >> 
> > >>>>> If you don't unplug all the CPUs >0 the state is obviously never
> > >>>>> reached. Otherwise the whole system hangs after it tries to
> > >>>>> enter this mode without any reaction for external events, other
> > >>>>> than reset.
> > >>>> 
> > >>>> Need investigation.
> > >>>> 
> > >>>> What is the exynos board version where that occurs ?
> > >>> 
> > >>> Could you please tell me what exactly do you mean by that?
> > >>> 
> > >>> I already wrote that we can reproduce the problem on EXYNOS4210
> > >>> rev0
> > >>> and rev1.1 (we don't have rev1.0). Tomek has also reproduced the
> > >>> problem
> > >>> on some later SoCs (I hope that he can give you exact revisions).
> > >>> 
> > >>> In our testing we didn't encounter the board on which the problem
> > >>> doesn't occur. Our current working theory is that the problem may
> > >>> be
> > >>> u-boot (or first stage bootloader) related.
> > >> 
> > >> Ok, the status for what I know:
> > >> 
> > >> Origen Exynos4210, board ver A: works for me
> > >> Arndale Exynos5250: works for me but only if u-boot does not enable
> > >> the
> > >> hypervisor mode.
> > >> Chromebook Exynos5250: works for me
> > > 
> > > I've also done some more testing. First I tested on some Exynos4412
> > > devices (M0 and SLP_PQ) and AFTR was not working on them. Then I got
> > > my hands on Origen Exynos4210 (thanks to Tomek Figa for providing
> > > it) and AFTR is working just fine on it. Finally I tried Trats board
> > > again but with the upstream u-boot instead of our custom modified
> > > version (thanks to help from Lukasz Majewski) and I found out that
> > > after this change AFTR works fine on it! It also gives quite nice
> > > power savings (~80mA less current drawn in AFTR mode compared to
> > > just WFI one).
> > 
> > Is the 80mA power saving comparing with:
> >  * (cpu0/cpu1 online) vs (cpu0 AFTR and cpu1 offline)
> > 
> > or
> > 
> >  * (cpu0 AFTR and cpu1 offline) vs (cpu0 WFI and cpu1 offline)
> > 
> > ?
> > 
> > > With the above findings it now seems that the issue is on our side
> > > and is outside the kernel. Thanks for help with narrowing down the
> > > problem and sorry for wasting your time.
> > 
> > May be we were not working on the same tree.
> > 
> > I am on the linux-pm-next tree.
> > 
> > Now the merge window occurred, the AFTR is no longer working on my
> > board.
> > 
> > After git bisecting:
> > 
> > commit 87107d89052bcec1fe91b309631de4ed294a5171
> > Author: Arnd Bergmann <arnd at arndb.de>
> > Date:   Wed Jun 19 01:36:52 2013 +0900
> > 
> >     ARM: EXYNOS: Remove legacy L2X0 initialization
> >     
> >     Since Exynos is now supporting only DT-based boot, the old L2X0
> >     initialization code is not needed anymore, so
> >     exynos4_l2x0_cache_init()
> >     can be greatly simplified.
> >     
> >     Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> >     Signed-off-by: Tomasz Figa <t.figa at samsung.com>
> >     Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> >     Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
> > :
> > :040000 040000 79e1adfd6386256ba71b3f609592d5acf9c08222
> > 
> > 9cb0026563b3b8657d906767493d26c501963269 M	arch
> > 
> > Reverting the patch solves the problem.
> > 
> > Any ideas ?
> 
> It is certainly a problem related to restoring L2 control registers in
> plat-samsung/s5p-sleep.S, probably DT init misses some registers
> (prefetch and power control) that are restored to zero values most
> likely, or the cluster cannot be shut down owing to those values not
> being programmed properly.

Looks like it.

> Chander posted a patch to fix that but I could
> not follow that thread, I have no idea where he got to and if that fixes
> the issue, I think so.

I will be doing a lot of cleanup of PM code for Samsung platforms starting 
from next week. Mostly low level suspend/resume handling (Samsung PM core), 
but since AFTR mode has much in common with sleep mode (e.g. both go 
through s5p-sleep.S after waking up), so I can look at this issue too, on 
our internal boards and Origen.

As for L2 suspend/resume on Samsung platforms, it has to be reworked 
completely, because on newer boards which have secure firmware it can't be 
resumed normally, because this requires calling several firmware operations. 
I already have patches for this, but need to do more testing, including 
checking how this interferes with things like AFTR mode.

Best regards,
Tomasz



From nicolas.pitre at linaro.org  Wed Jul 17 10:16:25 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Jul 2013 10:16:25 -0400 (EDT)
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <1374067786.3146.123.camel@hornet>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374052705.3146.86.camel@hornet>
 <alpine.LFD.2.03.1307170825240.14924@syhkavp.arg>
 <1374067786.3146.123.camel@hornet>
Message-ID: <alpine.LFD.2.03.1307171014510.14924@syhkavp.arg>

On Wed, 17 Jul 2013, Pawel Moll wrote:

> On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote:
> > If this is really miscelaneous code that really doesn't fit 
> > anywhere else, it should rather go into drivers/misc/ as a last resort.
> 
> Interestingly enough drivers/misc was my first choice for all the
> vexpress stuff, but it wasn't received well...
> 
> Anyway, the SPC driver as it is now seem to be a "power management
> system driver". Maybe a relevant directory would be in place? Wouldn't
> PSCI belong there as well? (there are two psci.c files in arch/arm and
> arch/arm64, surprisingly similar ones ;-)
> 
> The bottom line is: today it is not an MFD driver.

But we know it will, right?  So better  save some churn by storing the 
initial code where it would end up anyway once complete.


Nicolas


From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 10:16:54 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Wed, 17 Jul 2013 15:16:54 +0100
Subject: [RFC PATCH 02/11] ARM: DT/kernel: define ARM specific
 arch_of_get_cpu_node
In-Reply-To: <51E50C59.50900@arm.com>
References: <1373883732-26303-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1373883732-26303-3-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <51E44943.7000600@gmail.com> <51E50C59.50900@arm.com>
Message-ID: <51E6A756.1000300@arm.com>

On 16/07/13 10:03, Sudeep KarkadaNagesha wrote:
> On 15/07/13 20:10, Rob Herring wrote:
>> On 07/15/2013 05:22 AM, Sudeep.KarkadaNagesha at arm.com wrote:
>>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>>>
>>> CPU subsystem now provides architecture specific hook to retrieve the
>>> of_node. Most of the cpu DT node parsing and initialisation is contained
>>> in devtree.c. It's better to contain all CPU device node parsing there.
>>>
>>> arch_of_get_cpu_node is mainly used to assign cpu->of_node when CPUs get
>>> registered. This patch overrides the defination of the same. It can also
>>> act as the helper function in pre-SMP/early initialisation stages to
>>> retrieve CPU device node pointers in logical ordering.
>>>
>>> This mainly helps to avoid replication of the code doing CPU node parsing
>>> and physical(MPIDR) to logical mapping.
>>>
>>> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>>
>> [snip]
>>
>>> +struct device_node * __init arch_of_get_cpu_node(int cpu)
>>> +{
>>> +	struct device_node *cpun, *cpus;
>>> +	const u32 *cell;
>>> +	u64 hwid;
>>> +	int ac;
>>> +
>>> +	cpus = of_find_node_by_path("/cpus");
>>> +	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
>>> +		return NULL;
>>> +
>>> +	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
>>> +		ac = of_n_addr_cells(cpus);
>>> +
>>> +	for_each_child_of_node(cpus, cpun) {
>>> +		if (of_node_cmp(cpun->type, "cpu"))
>>> +			continue;
>>> +		cell = of_get_property(cpun, "reg", NULL);
>>> +		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
>>> +			continue;
>>> +
>>> +		hwid = of_read_number(cell, ac);
>>> +		if ((hwid & MPIDR_HWID_BITMASK) == cpu_logical_map(cpu))
>>
>> Most of this function is not ARM specific, so it would be nice if we
>> could shrink the arch specific part down to just this match. A default
>> match of reg == logical cpu number might be useful.
>>
> I completely agree, in fact that was my initial idea too.
> 
> But when I had a look at powerpc implementation of "of_get_cpu_node" in
> arch/powerpc/kernel/prom.c, it looked like PPC is using some
> compatibles(e.g. ibm,ppc-interrupt-server#s) which are not specified in
> ePAPR. I am not sure is that's allowed or not, if allowed then we can't
> have generic of_get_cpu_node with just arch specific hwid matching function.

I meant property names not compatibles. Looks like PPC and SPARC seem to
use non-standard property names like "cpuid",
"ibm,ppc-interrupt-server#s" instead of single "reg" property for all
cpus/threads

Since the cpufreq driver doesn't depend on those properties, I moved
arch_of_get_cpu_node to OF/DT core in v2.

Regards,
Sudeep



From pawel.moll at arm.com  Wed Jul 17 10:20:11 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Wed, 17 Jul 2013 15:20:11 +0100
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <alpine.LFD.2.03.1307171014510.14924@syhkavp.arg>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374052705.3146.86.camel@hornet>
 <alpine.LFD.2.03.1307170825240.14924@syhkavp.arg>
 <1374067786.3146.123.camel@hornet>
 <alpine.LFD.2.03.1307171014510.14924@syhkavp.arg>
Message-ID: <1374070811.3146.124.camel@hornet>

On Wed, 2013-07-17 at 15:16 +0100, Nicolas Pitre wrote:
> On Wed, 17 Jul 2013, Pawel Moll wrote:
> 
> > On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote:
> > > If this is really miscelaneous code that really doesn't fit 
> > > anywhere else, it should rather go into drivers/misc/ as a last resort.
> > 
> > Interestingly enough drivers/misc was my first choice for all the
> > vexpress stuff, but it wasn't received well...
> > 
> > Anyway, the SPC driver as it is now seem to be a "power management
> > system driver". Maybe a relevant directory would be in place? Wouldn't
> > PSCI belong there as well? (there are two psci.c files in arch/arm and
> > arch/arm64, surprisingly similar ones ;-)
> > 
> > The bottom line is: today it is not an MFD driver.
> 
> But we know it will, right?  So better  save some churn by storing the 
> initial code where it would end up anyway once complete.

Not in that form, no. The code living in mfd will just register
mfd_cells while "functional" parts are going to live elsewhere. This is
how I understand what Samuel asked me to do and that's what is happening
to vexpress-sysreg now.

Pawe?




From gsi at denx.de  Wed Jul 17 10:26:28 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Wed, 17 Jul 2013 16:26:28 +0200
Subject: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them
In-Reply-To: <20130717120758.GR22506@sirena.org.uk>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1373914074-20889-2-git-send-email-gsi@denx.de>
 <20130715201734.GF11538@sirena.org.uk>
 <20130717112229.GK7080@book.gsilab.sittig.org>
 <20130717120758.GR22506@sirena.org.uk>
Message-ID: <20130717142628.GN7080@book.gsilab.sittig.org>

On Wed, Jul 17, 2013 at 13:07 +0100, Mark Brown wrote:
> 
> On Wed, Jul 17, 2013 at 01:22:29PM +0200, Gerhard Sittig wrote:
> > On Mon, Jul 15, 2013 at 21:17 +0100, Mark Brown wrote:
> > > On Mon, Jul 15, 2013 at 08:47:30PM +0200, Gerhard Sittig wrote:
> 
> > > >   sprintf(name, "psc%d_mclk", master->bus_num);
> > > >  	spiclk = clk_get(&master->dev, name);
> > > > -	clk_enable(spiclk);
> > > > +	clk_prepare_enable(spiclk);
> > > >  	mps->mclk = clk_get_rate(spiclk);
> > > >  	clk_put(spiclk);
> 
> > > This code is *clearly* buggy and should be fixed rather than papered
> > > over.  Not only is there no matching put the driver is also dropping the
> > > reference to the clock rather than holding on to it while it's in use.
> 
> > "This code" refers to the driver's original condition, right?  I
> > agree that the driver has been suffering from incomplete clock
> > handling since it was born three years ago.  And that this issue
> > shall get addressed.  The question is just whether it needs to be
> > part of this series which has a different focus.
> 
> This is a pretty long e-mail.  It'd probably have taken less time to
> fix the issues than to reply to the e-mail...  but anyway.

[ this is meta stuff, technical details are after the next quotation ]

Not quite.  Please consider that careful submission is as
expensive as thorough review is, and that a lot of work is done
before v1 gets submitted, which you may not always notice from
looking at a concentrated series that may no longer suggest how
much it took to get there (especially when prepared carefully).

As mentioned before I did not question the need to fix issues as
they get identified.  I just asked whether reworking the serial
driver is in the scope of this series which provides a different
clock driver implementation for the platform.  To me these two
things are orthogonal, while I did promise to see how I can
address your concerns.

Let's provide the technical information you need to judge the
quality of the submission and see why it shall be acceptable:


> A big part of the issue with the state of the driver is that there's
> obvious clock API abuse going on that isn't corrected here - the main
> one is that the sprintf() for the clock name is a fairly clear warning
> sign, the driver should be using a fixed value there.  This raises a
> warning flag for me about the quality of the common clock API
> implementation that's being sent and/or the potential for bugs to be
> noticed with the common clock framework.  I'd not expect this code to
> actually work, and looking at the rest of the series I don't see how it
> does since I can't see what forces the name.

Why the code does work:

OK, here is why the driver keeps its state throughout the set and
is operational as good or as bad as it was before:

The sprintf() in the SPI driver used to construct a name which
includes the PSC index.  This applies to the UART driver as well,
as they both use the PSC controller hardware to implement their
serial communication.

The corresponding clock name was found in the previous PPC_CLOCK
implementation since the clock driver provided those names which
include the PSC index (fixed strings in a table).

The initial COMMON_CLK implementation in part 09/24 registers
clkdev items for compatibility during migration.  The string
isn't greppable since it's constructed by the preprocessor in the
MCLK data setup, see the MCLK_SETUP_DATA_PSC() macro.

Part 13/24 adjusts the SPI driver to no longer construct a name,
but instead use a fixed string after OF based clock lookup became
available.  This shall meet your expectation and simplifies the
client side.  Part 15/24 does the same for the UART driver.

Part 16/24 removes the clkdev registration in the clock driver
after both the UART and SPI clients switched to OF clock lookups.

At this stage things are the way you would expect:  The client
uses a fixed string in the lookup, while lookup occurs via device
tree, and instances are supported without the clients'
constructing something based on a component index.

Remaining issues are not with the common clock support of the
platform, but in the serial driver and are identical to the
previous (actually: the initial) status.  While we agree on the
existance of the remaining issue and the desire to address it.
Just not on which context that fix shall be done in.


The series' status and perspective:

The UART and SPI drivers did work before, while it's true that
clock handling wasn't complete (in non-fatal ways).  This has
been the case in the past, and has been identified just now.

The serial drivers are kept operational during migration, and
still are operational after the series.  But now they use common
clock and OF lookups, which is an improvement for the platform in
my eyes.

It's true that the status of the serial driver isn't improved
with the series -- but it isn't degraded either, while
(additional) breakage actively gets prevented.

Now let me see how I can improve the SPI driver with regard to
overall clock handling and beyond mere operation by coincidence
in the absence of errors.  But please understand that I don't
want to stall the common clock support for a whole platform just
because some of the drivers it needs to touch to keep them
operational have other issues that weren't addressed yet, while
these issues aren't introduced with the series but preceed it.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


From nicolas.pitre at linaro.org  Wed Jul 17 10:30:10 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Jul 2013 10:30:10 -0400 (EDT)
Subject: [RFC PATCH v2 01/15] of: add support for retrieving cpu node
 for a given logical cpu index
In-Reply-To: <1374069984-20567-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374069984-20567-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <alpine.LFD.2.03.1307171023410.14924@syhkavp.arg>

On Wed, 17 Jul 2013, Sudeep.KarkadaNagesha at arm.com wrote:

> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> Currently different drivers requiring to access cpu device node are
> parsing the device tree themselves. Since the ordering in the DT need
> not match the logical cpu ordering, the parsing logic needs to consider
> that. However, this has resulted in lots of code duplication and in some
> cases even incorrect logic.
> 
> It's better to consolidate them by adding support for getting cpu
> device node for a given logical cpu index in DT core library. However
> logical to physical index mapping can be architecture specific.
> 
> This patch adds of_get_cpu_node to retrieve a cpu device node for a
> given logical cpu index. The default matching of the physical id to the
> logical cpu index can be overridden by architecture specific code.
> 
> It is recommended to use these helper function only in pre-SMP/early
> initialisation stages to retrieve CPU device node pointers in logical
> ordering. Once the cpu devices are registered, it can be retrieved easily
> from cpu device of_node which avoids unnecessary parsing and matching.
> 
> Cc: Rob Herring <rob.herring at calxeda.com>
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> ---
>  drivers/of/base.c  | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of.h |  5 +++++
>  2 files changed, 71 insertions(+)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 5c54279..363b8f9 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -230,6 +230,72 @@ const void *of_get_property(const struct device_node *np, const char *name,
>  }
>  EXPORT_SYMBOL(of_get_property);
>  
> +/*
> + * arch_match_cpu_phys_id - Match the given logical CPU and physical id
> + *
> + * @cpu: logical index of a cpu
> + * @phys_id: physical identifier of a cpu
> + *
> + * CPU logical to physical index mapping is architecure specific.

Typo.

> + * However this __weak function provides a default match of physical
> + * id to logical cpu index.
> + *
> + * Returns 1 if the physical identifier and the logical index correspond
> + * to the same cpu, 0 otherwise.
> + */
> +int __weak arch_match_cpu_phys_id(int cpu, u64 phys_id)

Please use a bool return type, and use true/false rather than 1/0 in the 
comment.

> +{
> +	return (u32)phys_id == cpu;
> +}
> +
> +/**
> + * of_get_cpu_node - Get device node associated with the given logical CPU
> + *
> + * @cpu: CPU number(logical index) for which device node is required
> + *
> + * The main purpose of this function is to retrieve the device node for the
> + * given logical CPU index. It should be used to intialise the of_node in

Typo.

> + * cpu device. Once of_node in cpu device is populated, all the further
> + * references can use that instead.
> + *
> + * CPU logical to physical index mapping is architecure specific and is built

Typo.

> + * before booting secondary cores. This function uses arch_match_cpu_phys_id
> + * which can be overridden by architecture specific implementation.
> + *
> + * Returns a node pointer for the logical cpu if found, else NULL.
> + */
> +struct device_node *of_get_cpu_node(int cpu)
> +{
> +	struct device_node *cpun, *cpus;
> +	const u32 *cell;
> +	u64 hwid;
> +	int ac, prop_len;
> +
> +	cpus = of_find_node_by_path("/cpus");
> +	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
> +		return NULL;
> +
> +	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
> +		ac = of_n_addr_cells(cpus);
> +
> +	for_each_child_of_node(cpus, cpun) {
> +		if (of_node_cmp(cpun->type, "cpu"))
> +			continue;
> +		cell = of_get_property(cpun, "reg", &prop_len);
> +		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
> +			continue;
> +
> +		while (prop_len) {
> +			hwid = of_read_number(cell, ac);
> +			prop_len -= ac;
> +			if (arch_match_cpu_phys_id(cpu, hwid))
> +				return cpun;
> +		}
> +	}
> +
> +	return NULL;
> +}
> +
>  /** Checks if the given "compat" string matches one of the strings in
>   * the device's "compatible" property
>   */
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 1fd08ca..150b48e 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -266,6 +266,7 @@ extern int of_device_is_available(const struct device_node *device);
>  extern const void *of_get_property(const struct device_node *node,
>  				const char *name,
>  				int *lenp);
> +extern struct device_node *of_get_cpu_node(int cpu);
>  #define for_each_property_of_node(dn, pp) \
>  	for (pp = dn->properties; pp != NULL; pp = pp->next)
>  
> @@ -458,6 +459,10 @@ static inline const void *of_get_property(const struct device_node *node,
>  {
>  	return NULL;
>  }
> +static inline struct device_node *of_get_cpu_node(int cpu)
> +{
> +	return NULL;
> +}
>  
>  static inline int of_property_read_u64(const struct device_node *np,
>  				       const char *propname, u64 *out_value)
> -- 
> 1.8.1.2
> 
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 


From shuahkhan at gmail.com  Wed Jul 17 10:31:55 2013
From: shuahkhan at gmail.com (Shuah Khan)
Date: Wed, 17 Jul 2013 08:31:55 -0600
Subject: Linux Plumbers ACPI/PM, PCI Microconference
In-Reply-To: <CAL-B5D03ki8NHsM6EuESTH2K-Eh+XyFHNXPDYwgDq+oagDjtMQ@mail.gmail.com>
References: <CAL-B5D03ki8NHsM6EuESTH2K-Eh+XyFHNXPDYwgDq+oagDjtMQ@mail.gmail.com>
Message-ID: <CAKocOOOgEb5h1dZWP_2UqBKhSK9U-kxKUbvTdzHfds=RiDzNJg@mail.gmail.com>

Myron,

On Tue, Jul 16, 2013 at 8:21 PM, Myron Stowe <myron.stowe at gmail.com> wrote:

>
> Shuah - You brought up the idea about "Converting drivers from Legacy
> PM ops to dev_pm_ops"; would you like to present what you have
> done/encountered so far?
>

Awesome. Yes, I would like to present what I have done so far and I do
have a couple of things that could benefit from a face to face
discussion which would help me make progress on the rest of the work
that needs to get done.

Thanks for putting this item on the agenda.

-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research
America (Silicon Valley) shuah.kh at samsung.com | (970) 672-0658


From sergei.shtylyov at cogentembedded.com  Wed Jul 17 10:33:56 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Jul 2013 18:33:56 +0400
Subject: [PATCH v5 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <1374059564-6872-2-git-send-email-oleksandr.kozaruk@ti.com>
References: <1374059564-6872-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1374059564-6872-2-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <51E6AB54.103@cogentembedded.com>

Hello.

On 17-07-2013 15:12, Oleksandr Kozaruk wrote:

> GPADC is the general purpose ADC present on twl6030.
> The dt data is interrupt used to trigger end of ADC
> conversion.

> Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
> ---
>   arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
>   1 file changed, 6 insertions(+)

> diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
> index 2e3bd31..322aa8e 100644
> --- a/arch/arm/boot/dts/twl6030.dtsi
> +++ b/arch/arm/boot/dts/twl6030.dtsi
> @@ -103,4 +103,10 @@
>   		compatible = "ti,twl6030-pwmled";
>   		#pwm-cells = <2>;
>   	};
> +
> +	adc: twl6030_gpadc {

    I was talking about the device name, not label. The "twl6030_gpadc" part.

WBR, Sergei



From b.brezillon at overkiz.com  Wed Jul 17 10:35:42 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 16:35:42 +0200
Subject: [PATCH v2 12/42] ARM: at91: move to common clk framework
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374071742-19349-1-git-send-email-b.brezillon@overkiz.com>

This patch removes the old at91 clk implementation, and keep the
PMC initialization and sam9idle functions in pmc.c.

The at91_initialize function no longer initiliaze at91 clks: the new clk
registration process requires kzalloc which is not available when early_init
is called.
The clk registration is moved to at91_clk_init function which should be called
before timer_init (pit timer request at91 master clock).

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/Makefile  |    2 +-
 arch/arm/mach-at91/clock.c   |  977 ------------------------------------------
 arch/arm/mach-at91/clock.h   |   49 ---
 arch/arm/mach-at91/generic.h |   10 +-
 arch/arm/mach-at91/pmc.c     |   58 +++
 arch/arm/mach-at91/setup.c   |   36 +-
 drivers/clk/Makefile         |    1 +
 7 files changed, 86 insertions(+), 1047 deletions(-)
 delete mode 100644 arch/arm/mach-at91/clock.c
 delete mode 100644 arch/arm/mach-at91/clock.h
 create mode 100644 arch/arm/mach-at91/pmc.c

diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index 3b0a953..66c1796 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -7,7 +7,7 @@ obj-m		:=
 obj-n		:=
 obj-		:=
 
-obj-$(CONFIG_AT91_PMC_UNIT)	+= clock.o
+obj-$(CONFIG_AT91_PMC_UNIT)	+= pmc.o
 obj-$(CONFIG_AT91_SAM9_ALT_RESET) += at91sam9_alt_reset.o
 obj-$(CONFIG_AT91_SAM9G45_RESET) += at91sam9g45_reset.o
 obj-$(CONFIG_AT91_SAM9_TIME)	+= at91sam926x_time.o
diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
deleted file mode 100644
index cc263d0..0000000
--- a/arch/arm/mach-at91/clock.c
+++ /dev/null
@@ -1,977 +0,0 @@
-/*
- * linux/arch/arm/mach-at91/clock.c
- *
- * Copyright (C) 2005 David Brownell
- * Copyright (C) 2005 Ivan Kokshaysky
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/fs.h>
-#include <linux/debugfs.h>
-#include <linux/seq_file.h>
-#include <linux/list.h>
-#include <linux/errno.h>
-#include <linux/err.h>
-#include <linux/spinlock.h>
-#include <linux/delay.h>
-#include <linux/clk.h>
-#include <linux/io.h>
-#include <linux/of_address.h>
-#include <linux/clk/at91.h>
-
-#include <mach/hardware.h>
-#include <mach/cpu.h>
-
-#include <asm/proc-fns.h>
-
-#include "clock.h"
-#include "generic.h"
-
-void __iomem *at91_pmc_base;
-EXPORT_SYMBOL_GPL(at91_pmc_base);
-
-/*
- * There's a lot more which can be done with clocks, including cpufreq
- * integration, slow clock mode support (for system suspend), letting
- * PLLB be used at other rates (on boards that don't need USB), etc.
- */
-
-#define clk_is_primary(x)	((x)->type & CLK_TYPE_PRIMARY)
-#define clk_is_programmable(x)	((x)->type & CLK_TYPE_PROGRAMMABLE)
-#define clk_is_peripheral(x)	((x)->type & CLK_TYPE_PERIPHERAL)
-#define clk_is_sys(x)		((x)->type & CLK_TYPE_SYSTEM)
-
-
-/*
- * Chips have some kind of clocks : group them by functionality
- */
-#define cpu_has_utmi()		(  cpu_is_at91sam9rl() \
-				|| cpu_is_at91sam9g45() \
-				|| cpu_is_at91sam9x5() \
-				|| cpu_is_sama5d3())
-
-#define cpu_has_1056M_plla()	(cpu_is_sama5d3())
-
-#define cpu_has_800M_plla()	(  cpu_is_at91sam9g20() \
-				|| cpu_is_at91sam9g45() \
-				|| cpu_is_at91sam9x5() \
-				|| cpu_is_at91sam9n12())
-
-#define cpu_has_300M_plla()	(cpu_is_at91sam9g10())
-
-#define cpu_has_240M_plla()	(cpu_is_at91sam9261() \
-				|| cpu_is_at91sam9263() \
-				|| cpu_is_at91sam9rl())
-
-#define cpu_has_210M_plla()	(cpu_is_at91sam9260())
-
-#define cpu_has_pllb()		(!(cpu_is_at91sam9rl() \
-				|| cpu_is_at91sam9g45() \
-				|| cpu_is_at91sam9x5() \
-				|| cpu_is_sama5d3()))
-
-#define cpu_has_upll()		(cpu_is_at91sam9g45() \
-				|| cpu_is_at91sam9x5() \
-				|| cpu_is_sama5d3())
-
-/* USB host HS & FS */
-#define cpu_has_uhp()		(!cpu_is_at91sam9rl())
-
-/* USB device FS only */
-#define cpu_has_udpfs()		(!(cpu_is_at91sam9rl() \
-				|| cpu_is_at91sam9g45() \
-				|| cpu_is_at91sam9x5() \
-				|| cpu_is_sama5d3()))
-
-#define cpu_has_plladiv2()	(cpu_is_at91sam9g45() \
-				|| cpu_is_at91sam9x5() \
-				|| cpu_is_at91sam9n12() \
-				|| cpu_is_sama5d3())
-
-#define cpu_has_mdiv3()		(cpu_is_at91sam9g45() \
-				|| cpu_is_at91sam9x5() \
-				|| cpu_is_at91sam9n12() \
-				|| cpu_is_sama5d3())
-
-#define cpu_has_alt_prescaler()	(cpu_is_at91sam9x5() \
-				|| cpu_is_at91sam9n12() \
-				|| cpu_is_sama5d3())
-
-static LIST_HEAD(clocks);
-static DEFINE_SPINLOCK(clk_lock);
-
-static u32 at91_pllb_usb_init;
-
-/*
- * Four primary clock sources:  two crystal oscillators (32K, main), and
- * two PLLs.  PLLA usually runs the master clock; and PLLB must run at
- * 48 MHz (unless no USB function clocks are needed).  The main clock and
- * both PLLs are turned off to run in "slow clock mode" (system suspend).
- */
-static struct clk clk32k = {
-	.name		= "clk32k",
-	.rate_hz	= AT91_SLOW_CLOCK,
-	.users		= 1,		/* always on */
-	.id		= 0,
-	.type		= CLK_TYPE_PRIMARY,
-};
-static struct clk main_clk = {
-	.name		= "main",
-	.pmc_mask	= AT91_PMC_MOSCS,	/* in PMC_SR */
-	.id		= 1,
-	.type		= CLK_TYPE_PRIMARY,
-};
-static struct clk plla = {
-	.name		= "plla",
-	.parent		= &main_clk,
-	.pmc_mask	= AT91_PMC_LOCKA,	/* in PMC_SR */
-	.id		= 2,
-	.type		= CLK_TYPE_PRIMARY | CLK_TYPE_PLL,
-};
-
-static void pllb_mode(struct clk *clk, int is_on)
-{
-	u32	value;
-
-	if (is_on) {
-		is_on = AT91_PMC_LOCKB;
-		value = at91_pllb_usb_init;
-	} else
-		value = 0;
-
-	// REVISIT: Add work-around for AT91RM9200 Errata #26 ?
-	at91_pmc_write(AT91_CKGR_PLLBR, value);
-
-	do {
-		cpu_relax();
-	} while ((at91_pmc_read(AT91_PMC_SR) & AT91_PMC_LOCKB) != is_on);
-}
-
-static struct clk pllb = {
-	.name		= "pllb",
-	.parent		= &main_clk,
-	.pmc_mask	= AT91_PMC_LOCKB,	/* in PMC_SR */
-	.mode		= pllb_mode,
-	.id		= 3,
-	.type		= CLK_TYPE_PRIMARY | CLK_TYPE_PLL,
-};
-
-static void pmc_sys_mode(struct clk *clk, int is_on)
-{
-	if (is_on)
-		at91_pmc_write(AT91_PMC_SCER, clk->pmc_mask);
-	else
-		at91_pmc_write(AT91_PMC_SCDR, clk->pmc_mask);
-}
-
-static void pmc_uckr_mode(struct clk *clk, int is_on)
-{
-	unsigned int uckr = at91_pmc_read(AT91_CKGR_UCKR);
-
-	if (is_on) {
-		is_on = AT91_PMC_LOCKU;
-		at91_pmc_write(AT91_CKGR_UCKR, uckr | clk->pmc_mask);
-	} else
-		at91_pmc_write(AT91_CKGR_UCKR, uckr & ~(clk->pmc_mask));
-
-	do {
-		cpu_relax();
-	} while ((at91_pmc_read(AT91_PMC_SR) & AT91_PMC_LOCKU) != is_on);
-}
-
-/* USB function clocks (PLLB must be 48 MHz) */
-static struct clk udpck = {
-	.name		= "udpck",
-	.parent		= &pllb,
-	.mode		= pmc_sys_mode,
-};
-struct clk utmi_clk = {
-	.name		= "utmi_clk",
-	.parent		= &main_clk,
-	.pmc_mask	= AT91_PMC_UPLLEN,	/* in CKGR_UCKR */
-	.mode		= pmc_uckr_mode,
-	.type		= CLK_TYPE_PLL,
-};
-static struct clk uhpck = {
-	.name		= "uhpck",
-	/*.parent		= ... we choose parent at runtime */
-	.mode		= pmc_sys_mode,
-};
-
-
-/*
- * The master clock is divided from the CPU clock (by 1-4).  It's used for
- * memory, interfaces to on-chip peripherals, the AIC, and sometimes more
- * (e.g baud rate generation).  It's sourced from one of the primary clocks.
- */
-struct clk mck = {
-	.name		= "mck",
-	.pmc_mask	= AT91_PMC_MCKRDY,	/* in PMC_SR */
-};
-
-static void pmc_periph_mode(struct clk *clk, int is_on)
-{
-	u32 regval = 0;
-
-	/*
-	 * With sama5d3 devices, we are managing clock division so we have to
-	 * use the Peripheral Control Register introduced from at91sam9x5
-	 * devices.
-	 */
-	if (cpu_is_sama5d3()) {
-		regval |= AT91_PMC_PCR_CMD; /* write command */
-		regval |= clk->pid & AT91_PMC_PCR_PID; /* peripheral selection */
-		regval |= AT91_PMC_PCR_DIV(clk->div);
-		if (is_on)
-			regval |= AT91_PMC_PCR_EN; /* enable clock */
-		at91_pmc_write(AT91_PMC_PCR, regval);
-	} else {
-		if (is_on)
-			at91_pmc_write(AT91_PMC_PCER, clk->pmc_mask);
-		else
-			at91_pmc_write(AT91_PMC_PCDR, clk->pmc_mask);
-	}
-}
-
-static struct clk __init *at91_css_to_clk(unsigned long css)
-{
-	switch (css) {
-		case AT91_PMC_CSS_SLOW:
-			return &clk32k;
-		case AT91_PMC_CSS_MAIN:
-			return &main_clk;
-		case AT91_PMC_CSS_PLLA:
-			return &plla;
-		case AT91_PMC_CSS_PLLB:
-			if (cpu_has_upll())
-				/* CSS_PLLB == CSS_UPLL */
-				return &utmi_clk;
-			else if (cpu_has_pllb())
-				return &pllb;
-			break;
-		/* alternate PMC: can use master clock */
-		case AT91_PMC_CSS_MASTER:
-			return &mck;
-	}
-
-	return NULL;
-}
-
-static int pmc_prescaler_divider(u32 reg)
-{
-	if (cpu_has_alt_prescaler()) {
-		return 1 << ((reg & AT91_PMC_ALT_PRES) >> PMC_ALT_PRES_OFFSET);
-	} else {
-		return 1 << ((reg & AT91_PMC_PRES) >> PMC_PRES_OFFSET);
-	}
-}
-
-static void __clk_enable(struct clk *clk)
-{
-	if (clk->parent)
-		__clk_enable(clk->parent);
-	if (clk->users++ == 0 && clk->mode)
-		clk->mode(clk, 1);
-}
-
-int clk_enable(struct clk *clk)
-{
-	unsigned long	flags;
-
-	spin_lock_irqsave(&clk_lock, flags);
-	__clk_enable(clk);
-	spin_unlock_irqrestore(&clk_lock, flags);
-	return 0;
-}
-EXPORT_SYMBOL(clk_enable);
-
-static void __clk_disable(struct clk *clk)
-{
-	BUG_ON(clk->users == 0);
-	if (--clk->users == 0 && clk->mode)
-		clk->mode(clk, 0);
-	if (clk->parent)
-		__clk_disable(clk->parent);
-}
-
-void clk_disable(struct clk *clk)
-{
-	unsigned long	flags;
-
-	spin_lock_irqsave(&clk_lock, flags);
-	__clk_disable(clk);
-	spin_unlock_irqrestore(&clk_lock, flags);
-}
-EXPORT_SYMBOL(clk_disable);
-
-unsigned long clk_get_rate(struct clk *clk)
-{
-	unsigned long	flags;
-	unsigned long	rate;
-
-	spin_lock_irqsave(&clk_lock, flags);
-	for (;;) {
-		rate = clk->rate_hz;
-		if (rate || !clk->parent)
-			break;
-		clk = clk->parent;
-	}
-	spin_unlock_irqrestore(&clk_lock, flags);
-	return rate;
-}
-EXPORT_SYMBOL(clk_get_rate);
-
-/*------------------------------------------------------------------------*/
-
-#ifdef CONFIG_AT91_PROGRAMMABLE_CLOCKS
-
-/*
- * For now, only the programmable clocks support reparenting (MCK could
- * do this too, with care) or rate changing (the PLLs could do this too,
- * ditto MCK but that's more for cpufreq).  Drivers may reparent to get
- * a better rate match; we don't.
- */
-
-long clk_round_rate(struct clk *clk, unsigned long rate)
-{
-	unsigned long	flags;
-	unsigned	prescale;
-	unsigned long	actual;
-	unsigned long	prev = ULONG_MAX;
-
-	if (!clk_is_programmable(clk))
-		return -EINVAL;
-	spin_lock_irqsave(&clk_lock, flags);
-
-	actual = clk->parent->rate_hz;
-	for (prescale = 0; prescale < 7; prescale++) {
-		if (actual > rate)
-			prev = actual;
-
-		if (actual && actual <= rate) {
-			if ((prev - rate) < (rate - actual)) {
-				actual = prev;
-				prescale--;
-			}
-			break;
-		}
-		actual >>= 1;
-	}
-
-	spin_unlock_irqrestore(&clk_lock, flags);
-	return (prescale < 7) ? actual : -ENOENT;
-}
-EXPORT_SYMBOL(clk_round_rate);
-
-int clk_set_rate(struct clk *clk, unsigned long rate)
-{
-	unsigned long	flags;
-	unsigned	prescale;
-	unsigned long	prescale_offset, css_mask;
-	unsigned long	actual;
-
-	if (!clk_is_programmable(clk))
-		return -EINVAL;
-	if (clk->users)
-		return -EBUSY;
-
-	if (cpu_has_alt_prescaler()) {
-		prescale_offset = PMC_ALT_PRES_OFFSET;
-		css_mask = AT91_PMC_ALT_PCKR_CSS;
-	} else {
-		prescale_offset = PMC_PRES_OFFSET;
-		css_mask = AT91_PMC_CSS;
-	}
-
-	spin_lock_irqsave(&clk_lock, flags);
-
-	actual = clk->parent->rate_hz;
-	for (prescale = 0; prescale < 7; prescale++) {
-		if (actual && actual <= rate) {
-			u32	pckr;
-
-			pckr = at91_pmc_read(AT91_PMC_PCKR(clk->id));
-			pckr &= css_mask;	/* keep clock selection */
-			pckr |= prescale << prescale_offset;
-			at91_pmc_write(AT91_PMC_PCKR(clk->id), pckr);
-			clk->rate_hz = actual;
-			break;
-		}
-		actual >>= 1;
-	}
-
-	spin_unlock_irqrestore(&clk_lock, flags);
-	return (prescale < 7) ? actual : -ENOENT;
-}
-EXPORT_SYMBOL(clk_set_rate);
-
-struct clk *clk_get_parent(struct clk *clk)
-{
-	return clk->parent;
-}
-EXPORT_SYMBOL(clk_get_parent);
-
-int clk_set_parent(struct clk *clk, struct clk *parent)
-{
-	unsigned long	flags;
-
-	if (clk->users)
-		return -EBUSY;
-	if (!clk_is_primary(parent) || !clk_is_programmable(clk))
-		return -EINVAL;
-
-	if (cpu_is_at91sam9rl() && parent->id == AT91_PMC_CSS_PLLB)
-		return -EINVAL;
-
-	spin_lock_irqsave(&clk_lock, flags);
-
-	clk->rate_hz = parent->rate_hz;
-	clk->parent = parent;
-	at91_pmc_write(AT91_PMC_PCKR(clk->id), parent->id);
-
-	spin_unlock_irqrestore(&clk_lock, flags);
-	return 0;
-}
-EXPORT_SYMBOL(clk_set_parent);
-
-/* establish PCK0..PCKN parentage and rate */
-static void __init init_programmable_clock(struct clk *clk)
-{
-	struct clk	*parent;
-	u32		pckr;
-	unsigned int	css_mask;
-
-	if (cpu_has_alt_prescaler())
-		css_mask = AT91_PMC_ALT_PCKR_CSS;
-	else
-		css_mask = AT91_PMC_CSS;
-
-	pckr = at91_pmc_read(AT91_PMC_PCKR(clk->id));
-	parent = at91_css_to_clk(pckr & css_mask);
-	clk->parent = parent;
-	clk->rate_hz = parent->rate_hz / pmc_prescaler_divider(pckr);
-}
-
-#endif	/* CONFIG_AT91_PROGRAMMABLE_CLOCKS */
-
-/*------------------------------------------------------------------------*/
-
-#ifdef CONFIG_DEBUG_FS
-
-static int at91_clk_show(struct seq_file *s, void *unused)
-{
-	u32		scsr, pcsr, pcsr1 = 0, uckr = 0, sr;
-	struct clk	*clk;
-
-	scsr = at91_pmc_read(AT91_PMC_SCSR);
-	pcsr = at91_pmc_read(AT91_PMC_PCSR);
-	if (cpu_is_sama5d3())
-		pcsr1 = at91_pmc_read(AT91_PMC_PCSR1);
-	sr = at91_pmc_read(AT91_PMC_SR);
-	seq_printf(s, "SCSR = %8x\n", scsr);
-	seq_printf(s, "PCSR = %8x\n", pcsr);
-	if (cpu_is_sama5d3())
-		seq_printf(s, "PCSR1 = %8x\n", pcsr1);
-	seq_printf(s, "MOR  = %8x\n", at91_pmc_read(AT91_CKGR_MOR));
-	seq_printf(s, "MCFR = %8x\n", at91_pmc_read(AT91_CKGR_MCFR));
-	seq_printf(s, "PLLA = %8x\n", at91_pmc_read(AT91_CKGR_PLLAR));
-	if (cpu_has_pllb())
-		seq_printf(s, "PLLB = %8x\n", at91_pmc_read(AT91_CKGR_PLLBR));
-	if (cpu_has_utmi()) {
-		uckr = at91_pmc_read(AT91_CKGR_UCKR);
-		seq_printf(s, "UCKR = %8x\n", uckr);
-	}
-	seq_printf(s, "MCKR = %8x\n", at91_pmc_read(AT91_PMC_MCKR));
-	if (cpu_has_upll() || cpu_is_at91sam9n12())
-		seq_printf(s, "USB  = %8x\n", at91_pmc_read(AT91_PMC_USB));
-	seq_printf(s, "SR   = %8x\n", sr);
-
-	seq_printf(s, "\n");
-
-	list_for_each_entry(clk, &clocks, node) {
-		char	*state;
-
-		if (clk->mode == pmc_sys_mode) {
-			state = (scsr & clk->pmc_mask) ? "on" : "off";
-		} else if (clk->mode == pmc_periph_mode) {
-			if (cpu_is_sama5d3()) {
-				u32 pmc_mask = 1 << (clk->pid % 32);
-
-				if (clk->pid > 31)
-					state = (pcsr1 & pmc_mask) ? "on" : "off";
-				else
-					state = (pcsr & pmc_mask) ? "on" : "off";
-			} else {
-				state = (pcsr & clk->pmc_mask) ? "on" : "off";
-			}
-		} else if (clk->mode == pmc_uckr_mode) {
-			state = (uckr & clk->pmc_mask) ? "on" : "off";
-		} else if (clk->pmc_mask) {
-			state = (sr & clk->pmc_mask) ? "on" : "off";
-		} else if (clk == &clk32k || clk == &main_clk) {
-			state = "on";
-		} else {
-			state = "";
-		}
-
-		seq_printf(s, "%-10s users=%2d %-3s %9lu Hz %s\n",
-			clk->name, clk->users, state, clk_get_rate(clk),
-			clk->parent ? clk->parent->name : "");
-	}
-	return 0;
-}
-
-static int at91_clk_open(struct inode *inode, struct file *file)
-{
-	return single_open(file, at91_clk_show, NULL);
-}
-
-static const struct file_operations at91_clk_operations = {
-	.open		= at91_clk_open,
-	.read		= seq_read,
-	.llseek		= seq_lseek,
-	.release	= single_release,
-};
-
-static int __init at91_clk_debugfs_init(void)
-{
-	/* /sys/kernel/debug/at91_clk */
-	(void) debugfs_create_file("at91_clk", S_IFREG | S_IRUGO, NULL, NULL, &at91_clk_operations);
-
-	return 0;
-}
-postcore_initcall(at91_clk_debugfs_init);
-
-#endif
-
-/*------------------------------------------------------------------------*/
-
-/* Register a new clock */
-static void __init at91_clk_add(struct clk *clk)
-{
-	list_add_tail(&clk->node, &clocks);
-
-	clk->cl.con_id = clk->name;
-	clk->cl.clk = clk;
-	clkdev_add(&clk->cl);
-}
-
-int __init clk_register(struct clk *clk)
-{
-	if (clk_is_peripheral(clk)) {
-		if (!clk->parent)
-			clk->parent = &mck;
-		if (cpu_is_sama5d3())
-			clk->rate_hz = DIV_ROUND_UP(clk->parent->rate_hz,
-						    1 << clk->div);
-		clk->mode = pmc_periph_mode;
-	}
-	else if (clk_is_sys(clk)) {
-		clk->parent = &mck;
-		clk->mode = pmc_sys_mode;
-	}
-#ifdef CONFIG_AT91_PROGRAMMABLE_CLOCKS
-	else if (clk_is_programmable(clk)) {
-		clk->mode = pmc_sys_mode;
-		init_programmable_clock(clk);
-	}
-#endif
-
-	at91_clk_add(clk);
-
-	return 0;
-}
-
-/*------------------------------------------------------------------------*/
-
-static u32 __init at91_pll_rate(struct clk *pll, u32 freq, u32 reg)
-{
-	unsigned mul, div;
-
-	div = reg & 0xff;
-	if (cpu_is_sama5d3())
-		mul = AT91_PMC3_MUL_GET(reg);
-	else
-		mul = AT91_PMC_MUL_GET(reg);
-
-	if (div && mul) {
-		freq /= div;
-		freq *= mul + 1;
-	} else
-		freq = 0;
-
-	return freq;
-}
-
-static u32 __init at91_usb_rate(struct clk *pll, u32 freq, u32 reg)
-{
-	if (pll == &pllb && (reg & AT91_PMC_USB96M))
-		return freq / 2;
-	else if (pll == &utmi_clk || cpu_is_at91sam9n12())
-		return freq / (1 + ((reg & AT91_PMC_OHCIUSBDIV) >> 8));
-	else
-		return freq;
-}
-
-static unsigned __init at91_pll_calc(unsigned main_freq, unsigned out_freq)
-{
-	unsigned i, div = 0, mul = 0, diff = 1 << 30;
-	unsigned ret = (out_freq > 155000000) ? 0xbe00 : 0x3e00;
-
-	/* PLL output max 240 MHz (or 180 MHz per errata) */
-	if (out_freq > 240000000)
-		goto fail;
-
-	for (i = 1; i < 256; i++) {
-		int diff1;
-		unsigned input, mul1;
-
-		/*
-		 * PLL input between 1MHz and 32MHz per spec, but lower
-		 * frequences seem necessary in some cases so allow 100K.
-		 * Warning: some newer products need 2MHz min.
-		 */
-		input = main_freq / i;
-		if (cpu_is_at91sam9g20() && input < 2000000)
-			continue;
-		if (input < 100000)
-			continue;
-		if (input > 32000000)
-			continue;
-
-		mul1 = out_freq / input;
-		if (cpu_is_at91sam9g20() && mul > 63)
-			continue;
-		if (mul1 > 2048)
-			continue;
-		if (mul1 < 2)
-			goto fail;
-
-		diff1 = out_freq - input * mul1;
-		if (diff1 < 0)
-			diff1 = -diff1;
-		if (diff > diff1) {
-			diff = diff1;
-			div = i;
-			mul = mul1;
-			if (diff == 0)
-				break;
-		}
-	}
-	if (i == 256 && diff > (out_freq >> 5))
-		goto fail;
-	return ret | ((mul - 1) << 16) | div;
-fail:
-	return 0;
-}
-
-static struct clk *const standard_pmc_clocks[] __initconst = {
-	/* four primary clocks */
-	&clk32k,
-	&main_clk,
-	&plla,
-
-	/* MCK */
-	&mck
-};
-
-/* PLLB generated USB full speed clock init */
-static void __init at91_pllb_usbfs_clock_init(unsigned long main_clock)
-{
-	unsigned int reg;
-
-	/*
-	 * USB clock init:  choose 48 MHz PLLB value,
-	 * disable 48MHz clock during usb peripheral suspend.
-	 *
-	 * REVISIT:  assumes MCK doesn't derive from PLLB!
-	 */
-	uhpck.parent = &pllb;
-
-	reg = at91_pllb_usb_init = at91_pll_calc(main_clock, 48000000 * 2);
-	pllb.rate_hz = at91_pll_rate(&pllb, main_clock, at91_pllb_usb_init);
-	if (cpu_is_at91rm9200()) {
-		reg = at91_pllb_usb_init |= AT91_PMC_USB96M;
-		uhpck.pmc_mask = AT91RM9200_PMC_UHP;
-		udpck.pmc_mask = AT91RM9200_PMC_UDP;
-		at91_pmc_write(AT91_PMC_SCER, AT91RM9200_PMC_MCKUDP);
-	} else if (cpu_is_at91sam9260() || cpu_is_at91sam9261() ||
-		   cpu_is_at91sam9263() || cpu_is_at91sam9g20() ||
-		   cpu_is_at91sam9g10()) {
-		reg = at91_pllb_usb_init |= AT91_PMC_USB96M;
-		uhpck.pmc_mask = AT91SAM926x_PMC_UHP;
-		udpck.pmc_mask = AT91SAM926x_PMC_UDP;
-	} else if (cpu_is_at91sam9n12()) {
-		/* Divider for USB clock is in USB clock register for 9n12 */
-		reg = AT91_PMC_USBS_PLLB;
-
-		/* For PLLB output 96M, set usb divider 2 (USBDIV + 1) */
-		reg |= AT91_PMC_OHCIUSBDIV_2;
-		at91_pmc_write(AT91_PMC_USB, reg);
-
-		/* Still setup masks */
-		uhpck.pmc_mask = AT91SAM926x_PMC_UHP;
-		udpck.pmc_mask = AT91SAM926x_PMC_UDP;
-	}
-	at91_pmc_write(AT91_CKGR_PLLBR, 0);
-
-	udpck.rate_hz = at91_usb_rate(&pllb, pllb.rate_hz, reg);
-	uhpck.rate_hz = at91_usb_rate(&pllb, pllb.rate_hz, reg);
-}
-
-/* UPLL generated USB full speed clock init */
-static void __init at91_upll_usbfs_clock_init(unsigned long main_clock)
-{
-	/*
-	 * USB clock init: choose 480 MHz from UPLL,
-	 */
-	unsigned int usbr = AT91_PMC_USBS_UPLL;
-
-	/* Setup divider by 10 to reach 48 MHz */
-	usbr |= ((10 - 1) << 8) & AT91_PMC_OHCIUSBDIV;
-
-	at91_pmc_write(AT91_PMC_USB, usbr);
-
-	/* Now set uhpck values */
-	uhpck.parent = &utmi_clk;
-	uhpck.pmc_mask = AT91SAM926x_PMC_UHP;
-	uhpck.rate_hz = at91_usb_rate(&utmi_clk, utmi_clk.rate_hz, usbr);
-}
-
-static int __init at91_pmc_init(unsigned long main_clock)
-{
-	unsigned tmp, freq, mckr;
-	int i;
-	int pll_overclock = false;
-
-	/*
-	 * When the bootloader initialized the main oscillator correctly,
-	 * there's no problem using the cycle counter.  But if it didn't,
-	 * or when using oscillator bypass mode, we must be told the speed
-	 * of the main clock.
-	 */
-	if (!main_clock) {
-		do {
-			tmp = at91_pmc_read(AT91_CKGR_MCFR);
-		} while (!(tmp & AT91_PMC_MAINRDY));
-		main_clock = (tmp & AT91_PMC_MAINF) * (AT91_SLOW_CLOCK / 16);
-	}
-	main_clk.rate_hz = main_clock;
-
-	/* report if PLLA is more than mildly overclocked */
-	plla.rate_hz = at91_pll_rate(&plla, main_clock, at91_pmc_read(AT91_CKGR_PLLAR));
-	if (cpu_has_1056M_plla()) {
-		if (plla.rate_hz > 1056000000)
-			pll_overclock = true;
-	} else if (cpu_has_800M_plla()) {
-		if (plla.rate_hz > 800000000)
-			pll_overclock = true;
-	} else if (cpu_has_300M_plla()) {
-		if (plla.rate_hz > 300000000)
-			pll_overclock = true;
-	} else if (cpu_has_240M_plla()) {
-		if (plla.rate_hz > 240000000)
-			pll_overclock = true;
-	} else if (cpu_has_210M_plla()) {
-		if (plla.rate_hz > 210000000)
-			pll_overclock = true;
-	} else {
-		if (plla.rate_hz > 209000000)
-			pll_overclock = true;
-	}
-	if (pll_overclock)
-		pr_info("Clocks: PLLA overclocked, %ld MHz\n", plla.rate_hz / 1000000);
-
-	if (cpu_has_plladiv2()) {
-		mckr = at91_pmc_read(AT91_PMC_MCKR);
-		plla.rate_hz /= (1 << ((mckr & AT91_PMC_PLLADIV2) >> 12));	/* plla divisor by 2 */
-	}
-
-	if (!cpu_has_pllb() && cpu_has_upll()) {
-		/* setup UTMI clock as the fourth primary clock
-		 * (instead of pllb) */
-		utmi_clk.type |= CLK_TYPE_PRIMARY;
-		utmi_clk.id = 3;
-	}
-
-
-	/*
-	 * USB HS clock init
-	 */
-	if (cpu_has_utmi()) {
-		/*
-		 * multiplier is hard-wired to 40
-		 * (obtain the USB High Speed 480 MHz when input is 12 MHz)
-		 */
-		utmi_clk.rate_hz = 40 * utmi_clk.parent->rate_hz;
-
-		/* UTMI bias and PLL are managed at the same time */
-		if (cpu_has_upll())
-			utmi_clk.pmc_mask |= AT91_PMC_BIASEN;
-	}
-
-	/*
-	 * USB FS clock init
-	 */
-	if (cpu_has_pllb())
-		at91_pllb_usbfs_clock_init(main_clock);
-	if (cpu_has_upll())
-		/* assumes that we choose UPLL for USB and not PLLA */
-		at91_upll_usbfs_clock_init(main_clock);
-
-	/*
-	 * MCK and CPU derive from one of those primary clocks.
-	 * For now, assume this parentage won't change.
-	 */
-	mckr = at91_pmc_read(AT91_PMC_MCKR);
-	mck.parent = at91_css_to_clk(mckr & AT91_PMC_CSS);
-	freq = mck.parent->rate_hz;
-	freq /= pmc_prescaler_divider(mckr);					/* prescale */
-	if (cpu_is_at91rm9200()) {
-		mck.rate_hz = freq / (1 + ((mckr & AT91_PMC_MDIV) >> 8));	/* mdiv */
-	} else if (cpu_is_at91sam9g20()) {
-		mck.rate_hz = (mckr & AT91_PMC_MDIV) ?
-			freq / ((mckr & AT91_PMC_MDIV) >> 7) : freq;	/* mdiv ; (x >> 7) = ((x >> 8) * 2) */
-		if (mckr & AT91_PMC_PDIV)
-			freq /= 2;		/* processor clock division */
-	} else if (cpu_has_mdiv3()) {
-		mck.rate_hz = (mckr & AT91_PMC_MDIV) == AT91SAM9_PMC_MDIV_3 ?
-			freq / 3 : freq / (1 << ((mckr & AT91_PMC_MDIV) >> 8));	/* mdiv */
-	} else {
-		mck.rate_hz = freq / (1 << ((mckr & AT91_PMC_MDIV) >> 8));		/* mdiv */
-	}
-
-	if (cpu_has_alt_prescaler()) {
-		/* Programmable clocks can use MCK */
-		mck.type |= CLK_TYPE_PRIMARY;
-		mck.id = 4;
-	}
-
-	/* Register the PMC's standard clocks */
-	for (i = 0; i < ARRAY_SIZE(standard_pmc_clocks); i++)
-		at91_clk_add(standard_pmc_clocks[i]);
-
-	if (cpu_has_pllb())
-		at91_clk_add(&pllb);
-
-	if (cpu_has_uhp())
-		at91_clk_add(&uhpck);
-
-	if (cpu_has_udpfs())
-		at91_clk_add(&udpck);
-
-	if (cpu_has_utmi())
-		at91_clk_add(&utmi_clk);
-
-	/* MCK and CPU clock are "always on" */
-	clk_enable(&mck);
-
-	printk("Clocks: CPU %u MHz, master %u MHz, main %u.%03u MHz\n",
-		freq / 1000000, (unsigned) mck.rate_hz / 1000000,
-		(unsigned) main_clock / 1000000,
-		((unsigned) main_clock % 1000000) / 1000);
-
-	return 0;
-}
-
-#if defined(CONFIG_OF)
-static struct of_device_id pmc_ids[] = {
-	{ .compatible = "atmel,at91rm9200-pmc" },
-	{ /*sentinel*/ }
-};
-
-static struct of_device_id osc_ids[] = {
-	{ .compatible = "atmel,osc" },
-	{ /*sentinel*/ }
-};
-
-int __init at91_dt_clock_init(void)
-{
-	struct device_node *np;
-	u32 main_clock = 0;
-
-	np = of_find_matching_node(NULL, pmc_ids);
-	if (!np)
-		panic("unable to find compatible pmc node in dtb\n");
-
-	at91_pmc_base = of_iomap(np, 0);
-	if (!at91_pmc_base)
-		panic("unable to map pmc cpu registers\n");
-
-	of_node_put(np);
-
-	/* retrieve the freqency of fixed clocks from device tree */
-	np = of_find_matching_node(NULL, osc_ids);
-	if (np) {
-		u32 rate;
-		if (!of_property_read_u32(np, "clock-frequency", &rate))
-			main_clock = rate;
-	}
-
-	of_node_put(np);
-
-	return at91_pmc_init(main_clock);
-}
-#endif
-
-int __init at91_clock_init(unsigned long main_clock)
-{
-	at91_pmc_base = ioremap(AT91_PMC, 256);
-	if (!at91_pmc_base)
-		panic("Impossible to ioremap AT91_PMC 0x%x\n", AT91_PMC);
-
-	return at91_pmc_init(main_clock);
-}
-
-/*
- * Several unused clocks may be active.  Turn them off.
- */
-static int __init at91_clock_reset(void)
-{
-	unsigned long pcdr = 0;
-	unsigned long pcdr1 = 0;
-	unsigned long scdr = 0;
-	struct clk *clk;
-
-	list_for_each_entry(clk, &clocks, node) {
-		if (clk->users > 0)
-			continue;
-
-		if (clk->mode == pmc_periph_mode) {
-			if (cpu_is_sama5d3()) {
-				u32 pmc_mask = 1 << (clk->pid % 32);
-
-				if (clk->pid > 31)
-					pcdr1 |= pmc_mask;
-				else
-					pcdr |= pmc_mask;
-			} else
-				pcdr |= clk->pmc_mask;
-		}
-
-		if (clk->mode == pmc_sys_mode)
-			scdr |= clk->pmc_mask;
-
-		pr_debug("Clocks: disable unused %s\n", clk->name);
-	}
-
-	at91_pmc_write(AT91_PMC_SCDR, scdr);
-	if (cpu_is_sama5d3())
-		at91_pmc_write(AT91_PMC_PCDR1, pcdr1);
-
-	return 0;
-}
-late_initcall(at91_clock_reset);
-
-void at91sam9_idle(void)
-{
-	at91_pmc_write(AT91_PMC_SCDR, AT91_PMC_PCK);
-	cpu_do_idle();
-}
diff --git a/arch/arm/mach-at91/clock.h b/arch/arm/mach-at91/clock.h
deleted file mode 100644
index a98a39b..0000000
--- a/arch/arm/mach-at91/clock.h
+++ /dev/null
@@ -1,49 +0,0 @@
-/*
- * linux/arch/arm/mach-at91/clock.h
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/clkdev.h>
-
-#define CLK_TYPE_PRIMARY	0x1
-#define CLK_TYPE_PLL		0x2
-#define CLK_TYPE_PROGRAMMABLE	0x4
-#define CLK_TYPE_PERIPHERAL	0x8
-#define CLK_TYPE_SYSTEM		0x10
-
-
-struct clk {
-	struct list_head node;
-	const char	*name;		/* unique clock name */
-	struct clk_lookup cl;
-	unsigned long	rate_hz;
-	unsigned	div;		/* parent clock divider */
-	struct clk	*parent;
-	unsigned	pid;		/* peripheral ID */
-	u32		pmc_mask;
-	void		(*mode)(struct clk *, int);
-	unsigned	id:3;		/* PCK0..4, or 32k/main/a/b */
-	unsigned	type;		/* clock type */
-	u16		users;
-};
-
-
-extern int __init clk_register(struct clk *clk);
-extern struct clk mck;
-extern struct clk utmi_clk;
-
-#define CLKDEV_CON_ID(_id, _clk)			\
-	{						\
-		.con_id = _id,				\
-		.clk = _clk,				\
-	}
-
-#define CLKDEV_CON_DEV_ID(_con_id, _dev_id, _clk)	\
-	{						\
-		.con_id = _con_id,			\
-		.dev_id = _dev_id,			\
-		.clk = _clk,				\
-	}
diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index dc6e2f5..684befb 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -19,10 +19,12 @@ extern void __init at91_init_sram(int bank, unsigned long base,
 
  /* Processors */
 extern void __init at91rm9200_set_type(int type);
-extern void __init at91_initialize(unsigned long main_clock);
+extern void __init at91_initialize(void);
+extern void __init at91_clk_init(unsigned long main_clock);
 extern void __init at91x40_initialize(unsigned long main_clock);
 extern void __init at91rm9200_dt_initialize(void);
 extern void __init at91_dt_initialize(void);
+extern void __init at91_dt_clk_init(void);
 
  /* Interrupts */
 extern void __init at91_init_irq_default(void);
@@ -45,10 +47,10 @@ extern void at91x40_timer_init(void);
 
  /* Clocks */
 #ifdef CONFIG_AT91_PMC_UNIT
-extern int __init at91_clock_init(unsigned long main_clock);
-extern int __init at91_dt_clock_init(void);
+extern int __init at91_pmc_init(void);
+extern int __init at91_dt_pmc_init(void);
 #else
-static int inline at91_clock_init(unsigned long main_clock) { return 0; }
+static int inline at91_pmc_init() { return 0; }
 #endif
 struct device;
 
diff --git a/arch/arm/mach-at91/pmc.c b/arch/arm/mach-at91/pmc.c
new file mode 100644
index 0000000..2a8a6cf
--- /dev/null
+++ b/arch/arm/mach-at91/pmc.c
@@ -0,0 +1,58 @@
+/*
+ *  linux/arch/arm/mach-at91/pmc.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/clk/at91.h>
+
+#include <asm/io.h>
+#include <asm/proc-fns.h>
+
+void __iomem *at91_pmc_base;
+EXPORT_SYMBOL_GPL(at91_pmc_base);
+
+void at91sam9_idle(void)
+{
+	at91_pmc_write(AT91_PMC_SCDR, AT91_PMC_PCK);
+	cpu_do_idle();
+}
+
+#if defined(CONFIG_OF)
+static struct of_device_id pmc_ids[] = {
+	{ .compatible = "atmel,at91rm9200-pmc" },
+	{ /*sentinel*/ }
+};
+
+int __init at91_dt_pmc_init(void)
+{
+	struct device_node *np;
+
+	np = of_find_matching_node(NULL, pmc_ids);
+	if (!np)
+		panic("unable to find compatible pmc node in dtb\n");
+
+	at91_pmc_base = of_iomap(np, 0);
+	if (!at91_pmc_base)
+		panic("unable to map pmc cpu registers\n");
+
+	of_node_put(np);
+
+	return 0;
+}
+#endif
+
+int __init at91_pmc_init(void)
+{
+	at91_pmc_base = ioremap(AT91_PMC, 256);
+	if (!at91_pmc_base)
+		panic("Impossible to ioremap AT91_PMC 0x%x\n", AT91_PMC);
+
+	return 0;
+}
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index de3c519..9a8d58c 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -479,41 +479,45 @@ void __init at91rm9200_dt_initialize(void)
 {
 	at91_dt_ramc();
 
-	/* Init clock subsystem */
-	at91_dt_clock_init();
-
-	/* Register the processor-specific clocks */
-	at91_boot_soc.register_clocks();
+	at91_dt_pmc_init();
 
 	at91_boot_soc.init();
 }
 
-void __init at91_dt_initialize(void)
+void __init at91_dt_initialize()
 {
 	at91_dt_rstc();
 	at91_dt_ramc();
 	at91_dt_shdwc();
 
-	/* Init clock subsystem */
-	at91_dt_clock_init();
-
-	/* Register the processor-specific clocks */
-	at91_boot_soc.register_clocks();
+	at91_dt_pmc_init();
 
 	if (at91_boot_soc.init)
 		at91_boot_soc.init();
 }
-#endif
 
-void __init at91_initialize(unsigned long main_clock)
+void __init at91_dt_clk_init(void)
 {
-	at91_boot_soc.ioremap_registers();
+	of_clk_init(NULL);
+}
+#endif
 
-	/* Init clock subsystem */
-	at91_clock_init(main_clock);
+void __init at91_clk_init(unsigned long main_clock)
+{
+	clk_register_fixed_rate(NULL, "clk32k", NULL, CLK_IS_ROOT,
+				AT91_SLOW_CLOCK);
+	at91_clk_register_main("main", "clk32k", main_clock);
 
 	/* Register the processor-specific clocks */
 	at91_boot_soc.register_clocks();
+}
+
+void __init at91_initialize(void)
+{
+	at91_boot_soc.ioremap_registers();
+
+	/* Init clock subsystem */
+	at91_pmc_init();
 
 	at91_boot_soc.init();
 
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4038c2b..8c91671 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500.o
 obj-$(CONFIG_ARCH_ZYNQ)		+= zynq/
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
 obj-$(CONFIG_PLAT_SAMSUNG)	+= samsung/
+obj-$(CONFIG_ARCH_AT91)		+= at91/
 
 obj-$(CONFIG_X86)		+= x86/
 
-- 
1.7.9.5



From b.zolnierkie at samsung.com  Wed Jul 17 10:36:26 2013
From: b.zolnierkie at samsung.com (Bartlomiej Zolnierkiewicz)
Date: Wed, 17 Jul 2013 16:36:26 +0200
Subject: [PATCH 1/3] ARM: EXYNOS: remove non-working AFTR mode support
In-Reply-To: <51E694BA.3030906@linaro.org>
References: <1372241627-22695-1-git-send-email-b.zolnierkie@samsung.com>
 <5509794.32CckI9OQ8@amdc1032> <51E694BA.3030906@linaro.org>
Message-ID: <8703473.ctkuh2YRQb@amdc1032>

On Wednesday, July 17, 2013 02:57:30 PM Daniel Lezcano wrote:
> On 07/11/2013 03:14 PM, Bartlomiej Zolnierkiewicz wrote:
> > 
> > Hi,
> > 
> > On Friday, June 28, 2013 11:47:49 PM Daniel Lezcano wrote:
> >> On 06/28/2013 06:27 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> On Friday, June 28, 2013 01:20:09 PM Daniel Lezcano wrote:
> >>>> On 06/28/2013 12:11 PM, Tomasz Figa wrote:
> >>>>> Hi Daniel,
> >>>>>
> >>>>> I've been fighting with this whole AFTR state as well, before Bartlomiej. 
> >>>>> Let me share my thoughts on this.
> >>>>>
> >>
> >> [ ... ]
> >>
> >>>>>
> >>>>> If you don't unplug all the CPUs >0 the state is obviously never reached. 
> >>>>> Otherwise the whole system hangs after it tries to enter this mode without 
> >>>>> any reaction for external events, other than reset.
> >>>>
> >>>> Need investigation.
> >>>>
> >>>> What is the exynos board version where that occurs ?
> >>>
> >>> Could you please tell me what exactly do you mean by that?
> >>>
> >>> I already wrote that we can reproduce the problem on EXYNOS4210 rev0
> >>> and rev1.1 (we don't have rev1.0). Tomek has also reproduced the problem
> >>> on some later SoCs (I hope that he can give you exact revisions).
> >>>
> >>> In our testing we didn't encounter the board on which the problem
> >>> doesn't occur. Our current working theory is that the problem may be
> >>> u-boot (or first stage bootloader) related.
> >>
> >> Ok, the status for what I know:
> >>
> >> Origen Exynos4210, board ver A: works for me
> >> Arndale Exynos5250: works for me but only if u-boot does not enable the
> >> hypervisor mode.
> >> Chromebook Exynos5250: works for me
> > 
> > I've also done some more testing. First I tested on some Exynos4412 devices
> > (M0 and SLP_PQ) and AFTR was not working on them. Then I got my hands on
> > Origen Exynos4210 (thanks to Tomek Figa for providing it) and AFTR is working
> > just fine on it. Finally I tried Trats board again but with the upstream
> > u-boot instead of our custom modified version (thanks to help from Lukasz
> > Majewski) and I found out that after this change AFTR works fine on it! It
> > also gives quite nice power savings (~80mA less current drawn in AFTR mode
> > compared to just WFI one).
> 
> Is the 80mA power saving comparing with:
> 
>  * (cpu0/cpu1 online) vs (cpu0 AFTR and cpu1 offline)
> or
>  * (cpu0 AFTR and cpu1 offline) vs (cpu0 WFI and cpu1 offline)
> ?

The latter one and the following scenario:

 * (cpu0/cpu1 online) vs (cpu0 WFI and cpu1 offline)

gives only ~10mA saving. Maybe something is not working as it should be in
the hotplug support and the code is not doing as much as it could but these
are the actual results (using vanilla v3.10).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> > With the above findings it now seems that the issue is on our side and is
> > outside the kernel. Thanks for help with narrowing down the problem and
> > sorry for wasting your time.
> 
> May be we were not working on the same tree.
> 
> I am on the linux-pm-next tree.
> 
> Now the merge window occurred, the AFTR is no longer working on my board.
> 
> After git bisecting:
> 
> commit 87107d89052bcec1fe91b309631de4ed294a5171
> Author: Arnd Bergmann <arnd at arndb.de>
> Date:   Wed Jun 19 01:36:52 2013 +0900
> 
>     ARM: EXYNOS: Remove legacy L2X0 initialization
> 
>     Since Exynos is now supporting only DT-based boot, the old L2X0
>     initialization code is not needed anymore, so exynos4_l2x0_cache_init()
>     can be greatly simplified.
> 
>     Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>     Signed-off-by: Tomasz Figa <t.figa at samsung.com>
>     Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
>     Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
> 
> :040000 040000 79e1adfd6386256ba71b3f609592d5acf9c08222
> 9cb0026563b3b8657d906767493d26c501963269 M	arch
> 
> Reverting the patch solves the problem.
> 
> Any ideas ?
> 
> Thanks
>   -- Daniel
> 
> 
> > 
> > Best regards,
> > --
> > Bartlomiej Zolnierkiewicz
> > Samsung R&D Institute Poland
> > Samsung Electronics
> > 
> >> I found the following drivers:
> >>
> >> https://github.com/AndreiLux/Perseus-UNIVERSAL5410/blob/samsung/arch/arm/mach-exynos/cpuidle.c
> >>
> >> https://github.com/CyanogenMod/hardkernel-kernel-4412/blob/cm-10.1/arch/arm/mach-exynos/cpuidle-exynos4.c
> >>
> >> Sounds like the num cpus > 1 is still there.
> >>
> >> [ ... ]
> >>
> >>>> The kernel is not a playground where you can upstream code and then
> >>>> remove it because a feature seems broken and you don't have an idea of why.
> >>>
> >>> Neither me or Tomek did upstream this code and we couldn't react in
> >>> time because we haven't noticed that it is completely unusable for us
> >>> as EXYNOS cpuidle driver is not even used by default on EXYNOS (it is
> >>> not enabled either in defconfig or Kconfig).
> >>>
> >>> Moreover the feature we are talking about (AFTR mode) is also not used
> >>> by default (except EXYNOS4210 rev0 on which it lockups system for us)
> >>> even with EXYNOS cpuidle driver being enabled (because this specific
> >>> feature depends on CPU hot-unplug which is not done automatically right
> >>> now).
> >>>
> >>> Such things like unused/broken code removal is not something very
> >>> unusual in the upstream kernel (I'm speaking from the experience here
> >>> having maintained large subsystem for a couple of years). In this
> >>> particular case we are talking about ~130 lines of code which can
> >>> be trivially brought back later when/if needed.
> >>>
> >>> Anyway if the code removal is controversial for you we can just disable
> >>> AFTR mode by default and enable it only when special command line option
> >>> is given (i.e. "aftr"). This would fix all the broken configuration
> >>> while still allowing the feature to be enabled on systems that had it
> >>> working previously (since you claim that it works on some chipset/u-boot
> >>> configurations).
> >>
> >> Actually, there are several reasons I am not in favor for the moment to
> >> remove this code:
> >>
> >> 1) code can't be pushed upstream and then removed so easily
> >> 2) I asked several times what was this cpu1 hack, I had no answer
> >> 3) I tried to make both cpus entering the AFTR state, but the cpu1 never
> >> wakes up, I asked but no answer.
> >>
> >> I would like to have some answers :)
> >>
> >> Before taking the decision to remove this state (btw you can remove the
> >> driver directly, no ? the default idle function is WFI), IMO it is worth
> >> to investigate and to spend some time to clarify what is happening. Then
> >> we can take a decision.
> >>
> >> I am willing to help.
> >>
> >>>> I asked several times the reasons of why the AFTR state couldn't work
> >>>> with multiple CPUs and I had no answer.
> >>>
> >>> Unfortunately I don't know the answer for your question.
> >>>
> >>> The AFTR mode doesn't work for us *at*all* (even with *one* CPU).
> >>>
> >>>> Frankly speaking I have a couple of hypothesis:
> >>>>
> >>>> 1. something is not correctly setup and the PMU does not wake up the CPU1
> >>>> 2. there is a silicon bug and no one wants to tell it is the case
> >>>>
> >>>> In any case, this must be investigated and identified. And then we can
> >>>> take a decision about this state.
> >>>
> >>> I don't have good idea currently how to investigate it further.
> >>>
> >>> I also don't have any prove that the actual work is worth it
> >>> (and this work can easily take some weeks).
> >>>
> >>> One of main responsibilities of the maintainer it to make sure that
> >>> the code does indeed work and that regressions (like these caused by
> >>> AFTR mode feature) are fixed in the timely manner, not let the code
> >>> sit in the limbo state for large periods of time.  It is already very
> >>> bad situation that the regression we are hitting was present since
> >>> v3.4 and we are in v3.10 now, I would like to have it fixed ASAP so
> >>> we may actually consider enabling cpuidle in our exynos_defconfig.
> >>
> >> I agree.
> >>
> >> Thanks
> >>   -- Daniel



From b.brezillon at overkiz.com  Wed Jul 17 10:41:04 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 16:41:04 +0200
Subject: [PATCH v2 13/42] ARM: at91: move at91rm9200 SoC to new at91 clk implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374072064-19461-1-git-send-email-b.brezillon@overkiz.com>

This patch removes all references to the old at91 clks implementation and
make use of the new at91 clk implem for at91rm9200 SoC.

All dt specific lookups are removed (handled in clk device tree binding).

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/Kconfig      |    1 +
 arch/arm/mach-at91/at91rm9200.c |  566 +++++++++++++++++++++++----------------
 2 files changed, 341 insertions(+), 226 deletions(-)

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index c8e02ca..3253373 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -85,6 +85,7 @@ endif
 if SOC_SAM_V4_V5
 config SOC_AT91RM9200
 	bool "AT91RM9200"
+	select COMMON_CLK
 	select CPU_ARM920T
 	select GENERIC_CLOCKEVENTS
 	select HAVE_AT91_DBGU0
diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
index 8de5b02..3454c8b 100644
--- a/arch/arm/mach-at91/at91rm9200.c
+++ b/arch/arm/mach-at91/at91rm9200.c
@@ -13,6 +13,7 @@
 #include <linux/module.h>
 #include <linux/reboot.h>
 #include <linux/clk/at91.h>
+#include <linux/clkdev.h>
 
 #include <asm/irq.h>
 #include <asm/mach/arch.h>
@@ -25,7 +26,6 @@
 #include "at91_aic.h"
 #include "soc.h"
 #include "generic.h"
-#include "clock.h"
 #include "sam9_smc.h"
 
 /* --------------------------------------------------------------------
@@ -35,245 +35,359 @@
 /*
  * The peripheral clocks.
  */
-static struct clk udc_clk = {
-	.name		= "udc_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_UDP,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ohci_clk = {
-	.name		= "ohci_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_UHP,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ether_clk = {
-	.name		= "ether_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_EMAC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc_clk = {
-	.name		= "mci_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_MCI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi_clk = {
-	.name		= "twi_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_TWI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
-	.name		= "usart0_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_US0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
-	.name		= "usart1_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_US1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
-	.name		= "usart2_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_US2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart3_clk = {
-	.name		= "usart3_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_US3,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi_clk = {
-	.name		= "spi_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_SPI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioA_clk = {
-	.name		= "pioA_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_PIOA,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioB_clk = {
-	.name		= "pioB_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_PIOB,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioC_clk = {
-	.name		= "pioC_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_PIOC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioD_clk = {
-	.name		= "pioD_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_PIOD,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc0_clk = {
-	.name		= "ssc0_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_SSC0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc1_clk = {
-	.name		= "ssc1_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_SSC1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc2_clk = {
-	.name		= "ssc2_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_SSC2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc0_clk = {
-	.name		= "tc0_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_TC0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc1_clk = {
-	.name		= "tc1_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_TC1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc2_clk = {
-	.name		= "tc2_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_TC2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc3_clk = {
-	.name		= "tc3_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_TC3,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc4_clk = {
-	.name		= "tc4_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_TC4,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc5_clk = {
-	.name		= "tc5_clk",
-	.pmc_mask	= 1 << AT91RM9200_ID_TC5,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-
-static struct clk *periph_clocks[] __initdata = {
-	&pioA_clk,
-	&pioB_clk,
-	&pioC_clk,
-	&pioD_clk,
-	&usart0_clk,
-	&usart1_clk,
-	&usart2_clk,
-	&usart3_clk,
-	&mmc_clk,
-	&udc_clk,
-	&twi_clk,
-	&spi_clk,
-	&ssc0_clk,
-	&ssc1_clk,
-	&ssc2_clk,
-	&tc0_clk,
-	&tc1_clk,
-	&tc2_clk,
-	&tc3_clk,
-	&tc4_clk,
-	&tc5_clk,
-	&ohci_clk,
-	&ether_clk,
-	// irq0 .. irq6
-};
-
-static struct clk_lookup periph_clocks_lookups[] = {
-	CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk),
-	CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.0", &tc1_clk),
-	CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tc3_clk),
-	CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk),
-	CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk),
-	CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk),
-	CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk),
-	CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk),
-	CLKDEV_CON_DEV_ID("pclk", "fffd0000.ssc", &ssc0_clk),
-	CLKDEV_CON_DEV_ID("pclk", "fffd4000.ssc", &ssc1_clk),
-	CLKDEV_CON_DEV_ID("pclk", "fffd8000.ssc", &ssc2_clk),
-	CLKDEV_CON_DEV_ID(NULL, "i2c-at91rm9200.0", &twi_clk),
-	/* fake hclk clock */
-	CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk),
-	CLKDEV_CON_ID("pioA", &pioA_clk),
-	CLKDEV_CON_ID("pioB", &pioB_clk),
-	CLKDEV_CON_ID("pioC", &pioC_clk),
-	CLKDEV_CON_ID("pioD", &pioD_clk),
-	/* usart lookup table for DT entries */
-	CLKDEV_CON_DEV_ID("usart", "fffff200.serial", &mck),
-	CLKDEV_CON_DEV_ID("usart", "fffc0000.serial", &usart0_clk),
-	CLKDEV_CON_DEV_ID("usart", "fffc4000.serial", &usart1_clk),
-	CLKDEV_CON_DEV_ID("usart", "fffc8000.serial", &usart2_clk),
-	CLKDEV_CON_DEV_ID("usart", "fffcc000.serial", &usart3_clk),
-	/* tc lookup table for DT entries */
-	CLKDEV_CON_DEV_ID("t0_clk", "fffa0000.timer", &tc0_clk),
-	CLKDEV_CON_DEV_ID("t1_clk", "fffa0000.timer", &tc1_clk),
-	CLKDEV_CON_DEV_ID("t2_clk", "fffa0000.timer", &tc2_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "fffa4000.timer", &tc3_clk),
-	CLKDEV_CON_DEV_ID("t1_clk", "fffa4000.timer", &tc4_clk),
-	CLKDEV_CON_DEV_ID("t2_clk", "fffa4000.timer", &tc5_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "fffb4000.mmc", &mmc_clk),
-	CLKDEV_CON_DEV_ID("emac_clk", "fffbc000.ethernet", &ether_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffb8000.i2c", &twi_clk),
-	CLKDEV_CON_DEV_ID("hclk", "300000.ohci", &ohci_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff400.gpio", &pioA_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff600.gpio", &pioB_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff800.gpio", &pioC_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffffa00.gpio", &pioD_clk),
-};
-
-static struct clk_lookup usart_clocks_lookups[] = {
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.0", &mck),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.1", &usart0_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.2", &usart1_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.3", &usart2_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.4", &usart3_clk),
+static struct clk_lookup pioA_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioA_clk", NULL),
+	CLKDEV_INIT(NULL, "pioA", NULL),
+};
+
+static struct clk_lookup pioB_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioB_clk", NULL),
+	CLKDEV_INIT(NULL, "pioB", NULL),
+};
+
+static struct clk_lookup pioC_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioC_clk", NULL),
+	CLKDEV_INIT(NULL, "pioC", NULL),
+};
+
+static struct clk_lookup pioD_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioD_clk", NULL),
+	CLKDEV_INIT(NULL, "pioD", NULL),
+};
+
+static struct clk_lookup usart0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart0_clk", NULL),
+	CLKDEV_INIT("atmel_usart.1", "usart", NULL),
+};
+
+static struct clk_lookup usart1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart1_clk", NULL),
+	CLKDEV_INIT("atmel_usart.2", "usart", NULL),
+};
+
+static struct clk_lookup usart2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart2_clk", NULL),
+	CLKDEV_INIT("atmel_usart.3", "usart", NULL),
+};
+
+static struct clk_lookup usart3_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart3_clk", NULL),
+	CLKDEV_INIT("atmel_usart.4", "usart", NULL),
+};
+
+static struct clk_lookup mci_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "mci_clk", NULL),
+};
+
+static struct clk_lookup udc_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "udc_clk", NULL),
+};
+
+static struct clk_lookup twi_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "twi_clk", NULL),
+	CLKDEV_INIT("i2c-at91rm9200.0", NULL, NULL),
+};
+
+static struct clk_lookup ssc0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ssc0_clk", NULL),
+	CLKDEV_INIT("at91rm9200_ssc.0", "pclk", NULL),
+};
+
+static struct clk_lookup ssc1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ssc1_clk", NULL),
+	CLKDEV_INIT("at91rm9200_ssc.1", "pclk", NULL),
+};
+
+static struct clk_lookup ssc2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ssc2_clk", NULL),
+	CLKDEV_INIT("at91rm9200_ssc.2", "pclk", NULL),
+};
+
+static struct clk_lookup tc0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc0_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.0", "t0_clk", NULL),
+};
+
+static struct clk_lookup tc1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc1_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.0", "t1_clk", NULL),
+};
+
+static struct clk_lookup tc2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc2_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.0", "t2_clk", NULL),
+};
+
+static struct clk_lookup tc3_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc3_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.1", "t0_clk", NULL),
+};
+
+static struct clk_lookup tc4_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc4_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.1", "t1_clk", NULL),
+};
+
+static struct clk_lookup tc5_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc5_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.1", "t2_clk", NULL),
+};
+
+static struct clk_lookup ohci_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ohci_clk", NULL),
+	CLKDEV_INIT("at91_ohci", "hclk", NULL),
+};
+
+static struct clk_lookup ether_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ether_clk", NULL),
+	CLKDEV_INIT("emac_clk", "fffbc000.ethernet", NULL),
+};
+
+static size_t periph_clock_lookup_sizes[] __initdata = {
+	0,
+	0,
+	ARRAY_SIZE(pioA_clk_lookup),
+	ARRAY_SIZE(pioB_clk_lookup),
+	ARRAY_SIZE(pioC_clk_lookup),
+	ARRAY_SIZE(pioD_clk_lookup),
+	ARRAY_SIZE(usart0_clk_lookup),
+	ARRAY_SIZE(usart1_clk_lookup),
+	ARRAY_SIZE(usart2_clk_lookup),
+	ARRAY_SIZE(usart3_clk_lookup),
+	ARRAY_SIZE(mci_clk_lookup),
+	ARRAY_SIZE(udc_clk_lookup),
+	ARRAY_SIZE(twi_clk_lookup),
+	0,
+	ARRAY_SIZE(ssc0_clk_lookup),
+	ARRAY_SIZE(ssc1_clk_lookup),
+	ARRAY_SIZE(ssc2_clk_lookup),
+	ARRAY_SIZE(tc0_clk_lookup),
+	ARRAY_SIZE(tc1_clk_lookup),
+	ARRAY_SIZE(tc2_clk_lookup),
+	ARRAY_SIZE(tc3_clk_lookup),
+	ARRAY_SIZE(tc4_clk_lookup),
+	ARRAY_SIZE(tc5_clk_lookup),
+	ARRAY_SIZE(ohci_clk_lookup),
+	ARRAY_SIZE(ether_clk_lookup),
+};
+
+static struct clk_lookup *periph_clock_lookups[] __initdata = {
+	NULL,
+	NULL,
+	pioA_clk_lookup,
+	pioB_clk_lookup,
+	pioC_clk_lookup,
+	pioD_clk_lookup,
+	usart0_clk_lookup,
+	usart1_clk_lookup,
+	usart2_clk_lookup,
+	usart3_clk_lookup,
+	mci_clk_lookup,
+	udc_clk_lookup,
+	twi_clk_lookup,
+	NULL,
+	ssc0_clk_lookup,
+	ssc1_clk_lookup,
+	ssc2_clk_lookup,
+	tc0_clk_lookup,
+	tc1_clk_lookup,
+	tc2_clk_lookup,
+	tc3_clk_lookup,
+	tc4_clk_lookup,
+	tc5_clk_lookup,
+	ohci_clk_lookup,
+	ether_clk_lookup,
+};
+
+/*
+ * The system clocks.
+ */
+static struct clk_lookup udp_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "udpck", NULL),
+};
+
+static struct clk_lookup uhp_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "uhpck", NULL),
+};
+
+static struct clk_lookup pck0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck0", NULL),
+};
+
+static struct clk_lookup pck1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck1", NULL),
+};
+
+static struct clk_lookup pck2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck2", NULL),
+};
+
+static struct clk_lookup pck3_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck3", NULL),
+};
+
+static size_t system_clock_lookup_sizes[] __initdata = {
+	0,
+	ARRAY_SIZE(udp_clk_lookup),
+	0,
+	0,
+	ARRAY_SIZE(uhp_clk_lookup),
+	0,
+	0,
+	0,
+	ARRAY_SIZE(pck0_clk_lookup),
+	ARRAY_SIZE(pck1_clk_lookup),
+	ARRAY_SIZE(pck2_clk_lookup),
+	ARRAY_SIZE(pck3_clk_lookup),
+};
+
+static struct clk_lookup *system_clock_lookups[] __initdata = {
+	NULL,
+	udp_clk_lookup,
+	NULL,
+	NULL,
+	uhp_clk_lookup,
+	NULL,
+	NULL,
+	NULL,
+	pck0_clk_lookup,
+	pck1_clk_lookup,
+	pck2_clk_lookup,
+	pck3_clk_lookup,
 };
 
 /*
  * The four programmable clocks.
  * You must configure pin multiplexing to bring these signals out.
  */
-static struct clk pck0 = {
-	.name		= "pck0",
-	.pmc_mask	= AT91_PMC_PCK0,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 0,
-};
-static struct clk pck1 = {
-	.name		= "pck1",
-	.pmc_mask	= AT91_PMC_PCK1,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 1,
-};
-static struct clk pck2 = {
-	.name		= "pck2",
-	.pmc_mask	= AT91_PMC_PCK2,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 2,
-};
-static struct clk pck3 = {
-	.name		= "pck3",
-	.pmc_mask	= AT91_PMC_PCK3,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 3,
+static const char *prog_clock_parent_names[] __initdata = {
+	"clk32k",
+	"main",
+	"plla",
+	"pllb",
+};
+
+static const char *prog_clock_names[] __initdata = {
+	"prog0",
+	"prog1",
+	"prog2",
+	"prog3",
+};
+
+/*
+ * The pll clocks.
+ */
+static struct clk_lookup pll_clk_lookup[] __initdata = {
+	CLKDEV_INIT(NULL, "plla", NULL),
+	CLKDEV_INIT(NULL, "pllb", NULL),
+};
+
+static struct clk_range at91rm9200_pll_output[] = {
+	CLK_RANGE(80000000, 160000000),
+	CLK_RANGE(150000000, 180000000),
 };
+static u8 at91rm9200_pll_out[] = {0, 2};
+
+struct clk_pll_characteristics at91rm9200_pll_characteristics = {
+	.input = CLK_RANGE(1000000, 32000000),
+	.num_output = ARRAY_SIZE(at91rm9200_pll_output),
+	.output = at91rm9200_pll_output,
+	.out = at91rm9200_pll_out,
+};
+
+
+/*
+ * The master clock.
+ */
+static struct clk_lookup mck_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "mck", NULL),
+	CLKDEV_INIT("atmel_usart.0", "usart", NULL),
+};
+
+struct clk_master_characteristics at91rm9200_master_characteristics = {
+	.output = CLK_RANGE(0, 80000000),
+	.have_div3_pres = 0,
+	.divisors = {1, 2, 3, 4},
+};
+
+static const char *master_clock_parent_names[] __initdata = {
+	"clk32k",
+	"main",
+	"plla",
+	"pllb",
+};
+
+/*
+ * The USB clock.
+ */
+static u32 usb_divisors[] = {1, 2, 0, 0};
 
 static void __init at91rm9200_register_clocks(void)
 {
 	int i;
+	int k;
+	size_t size;
+	struct clk *clk;
+	const char *name;
+	struct clk_lookup *lookup;
+
+	for (i = 0; i < ARRAY_SIZE(pll_clk_lookup); i++) {
+		name = pll_clk_lookup[i].con_id;
+		clk = at91_clk_register_pll(name, "main", i,
+					    &at91rm9200_pll_layout,
+					    &at91rm9200_pll_characteristics);
+		pll_clk_lookup[i].clk = clk;
+	}
+	clkdev_add_table(pll_clk_lookup, ARRAY_SIZE(pll_clk_lookup));
+
+	clk = at91_clk_register_master("mck",
+				       ARRAY_SIZE(master_clock_parent_names),
+				       master_clock_parent_names,
+				       &at91rm9200_master_layout,
+				       &at91rm9200_master_characteristics);
 
-	for (i = 0; i < ARRAY_SIZE(periph_clocks); i++)
-		clk_register(periph_clocks[i]);
+	for (i = 0; i < ARRAY_SIZE(mck_clk_lookup); i++)
+		mck_clk_lookup[i].clk = clk;
+	clkdev_add_table(mck_clk_lookup, ARRAY_SIZE(mck_clk_lookup));
 
-	clkdev_add_table(periph_clocks_lookups,
-			 ARRAY_SIZE(periph_clocks_lookups));
-	clkdev_add_table(usart_clocks_lookups,
-			 ARRAY_SIZE(usart_clocks_lookups));
+	for (i = 0; i < ARRAY_SIZE(periph_clock_lookup_sizes); i++) {
+		size = periph_clock_lookup_sizes[i];
+		lookup = periph_clock_lookups[i];
+		if (!size || !lookup)
+			continue;
+		name = periph_clock_lookups[i][0].con_id;
+		if (!name)
+			continue;
+		clk = at91_clk_register_peripheral(name, "mck", i);
 
-	clk_register(&pck0);
-	clk_register(&pck1);
-	clk_register(&pck2);
-	clk_register(&pck3);
+		for (k = 0; k < size; k++)
+			lookup[k].clk = clk;
+		clkdev_add_table(lookup, size);
+	}
+
+	for (i = 0; i < ARRAY_SIZE(prog_clock_names); i++) {
+		name = prog_clock_names[i];
+		clk = at91_clk_register_programmable(name,
+					prog_clock_parent_names,
+					ARRAY_SIZE(prog_clock_parent_names),
+					i, &at91rm9200_programmable_layout);
+	}
+
+	clk = at91rm9200_clk_register_usb("usbck", "pllb", usb_divisors);
+
+	for (i = 0; i < ARRAY_SIZE(system_clock_lookup_sizes); i++) {
+		size = system_clock_lookup_sizes[i];
+		lookup = system_clock_lookups[i];
+		if (!size || !lookup)
+			continue;
+		name = system_clock_lookups[i][0].con_id;
+		if (!name)
+			continue;
+		clk = at91_clk_register_system(name, i);
+		for (k = 0; k < size; k++)
+			lookup[k].clk = clk;
+		clkdev_add_table(lookup, size);
+	}
 }
 
 /* --------------------------------------------------------------------
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 10:42:07 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 16:42:07 +0200
Subject: [PATCH v2 14/42] ARM: at91: move at91sam9260 SoC to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374072127-19501-1-git-send-email-b.brezillon@overkiz.com>

This patch removes all references to the old at91 clks implementation and
make use of the new at91 clk implem for at91sam9260 SoC.

All dt specific lookups are removed (handled in clk device tree binding).

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/at91sam9260.c |  687 +++++++++++++++++++++++++-------------
 1 file changed, 452 insertions(+), 235 deletions(-)

diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
index db9d89a..3becd5a 100644
--- a/arch/arm/mach-at91/at91sam9260.c
+++ b/arch/arm/mach-at91/at91sam9260.c
@@ -26,7 +26,6 @@
 #include "at91_rstc.h"
 #include "soc.h"
 #include "generic.h"
-#include "clock.h"
 #include "sam9_smc.h"
 
 /* --------------------------------------------------------------------
@@ -36,255 +35,473 @@
 /*
  * The peripheral clocks.
  */
-static struct clk pioA_clk = {
-	.name		= "pioA_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_PIOA,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioB_clk = {
-	.name		= "pioB_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_PIOB,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioC_clk = {
-	.name		= "pioC_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_PIOC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk adc_clk = {
-	.name		= "adc_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_ADC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-
-static struct clk adc_op_clk = {
-	.name		= "adc_op_clk",
-	.type		= CLK_TYPE_PERIPHERAL,
-	.rate_hz	= 5000000,
-};
-
-static struct clk usart0_clk = {
-	.name		= "usart0_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_US0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
-	.name		= "usart1_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_US1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
-	.name		= "usart2_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_US2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc_clk = {
-	.name		= "mci_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_MCI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk udc_clk = {
-	.name		= "udc_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_UDP,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi_clk = {
-	.name		= "twi_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_TWI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi0_clk = {
-	.name		= "spi0_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_SPI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi1_clk = {
-	.name		= "spi1_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_SPI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc_clk = {
-	.name		= "ssc_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_SSC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc0_clk = {
-	.name		= "tc0_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_TC0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc1_clk = {
-	.name		= "tc1_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_TC1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc2_clk = {
-	.name		= "tc2_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_TC2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ohci_clk = {
-	.name		= "ohci_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_UHP,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk macb_clk = {
-	.name		= "pclk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_EMAC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk isi_clk = {
-	.name		= "isi_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_ISI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart3_clk = {
-	.name		= "usart3_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_US3,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart4_clk = {
-	.name		= "usart4_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_US4,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart5_clk = {
-	.name		= "usart5_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_US5,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc3_clk = {
-	.name		= "tc3_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_TC3,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc4_clk = {
-	.name		= "tc4_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_TC4,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc5_clk = {
-	.name		= "tc5_clk",
-	.pmc_mask	= 1 << AT91SAM9260_ID_TC5,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-
-static struct clk *periph_clocks[] __initdata = {
-	&pioA_clk,
-	&pioB_clk,
-	&pioC_clk,
-	&adc_clk,
-	&adc_op_clk,
-	&usart0_clk,
-	&usart1_clk,
-	&usart2_clk,
-	&mmc_clk,
-	&udc_clk,
-	&twi_clk,
-	&spi0_clk,
-	&spi1_clk,
-	&ssc_clk,
-	&tc0_clk,
-	&tc1_clk,
-	&tc2_clk,
-	&ohci_clk,
-	&macb_clk,
-	&isi_clk,
-	&usart3_clk,
-	&usart4_clk,
-	&usart5_clk,
-	&tc3_clk,
-	&tc4_clk,
-	&tc5_clk,
-	// irq0 .. irq2
-};
-
-static struct clk_lookup periph_clocks_lookups[] = {
-	/* One additional fake clock for macb_hclk */
-	CLKDEV_CON_ID("hclk", &macb_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.1", &spi1_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk),
-	CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.0", &tc1_clk),
-	CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tc3_clk),
-	CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk),
-	CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk),
-	CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc_clk),
-	CLKDEV_CON_DEV_ID("pclk", "fffbc000.ssc", &ssc_clk),
-	CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260.0", &twi_clk),
-	CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.0", &twi_clk),
-	/* more usart lookup table for DT entries */
-	CLKDEV_CON_DEV_ID("usart", "fffff200.serial", &mck),
-	CLKDEV_CON_DEV_ID("usart", "fffb0000.serial", &usart0_clk),
-	CLKDEV_CON_DEV_ID("usart", "fffb4000.serial", &usart1_clk),
-	CLKDEV_CON_DEV_ID("usart", "fffb8000.serial", &usart2_clk),
-	CLKDEV_CON_DEV_ID("usart", "fffd0000.serial", &usart3_clk),
-	CLKDEV_CON_DEV_ID("usart", "fffd4000.serial", &usart4_clk),
-	CLKDEV_CON_DEV_ID("usart", "fffd8000.serial", &usart5_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffac000.i2c", &twi_clk),
-	/* more tc lookup table for DT entries */
-	CLKDEV_CON_DEV_ID("t0_clk", "fffa0000.timer", &tc0_clk),
-	CLKDEV_CON_DEV_ID("t1_clk", "fffa0000.timer", &tc1_clk),
-	CLKDEV_CON_DEV_ID("t2_clk", "fffa0000.timer", &tc2_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "fffdc000.timer", &tc3_clk),
-	CLKDEV_CON_DEV_ID("t1_clk", "fffdc000.timer", &tc4_clk),
-	CLKDEV_CON_DEV_ID("t2_clk", "fffdc000.timer", &tc5_clk),
-	CLKDEV_CON_DEV_ID("hclk", "500000.ohci", &ohci_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "fffa8000.mmc", &mmc_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "fffc8000.spi", &spi0_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "fffcc000.spi", &spi1_clk),
-	/* fake hclk clock */
-	CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk),
-	CLKDEV_CON_ID("pioA", &pioA_clk),
-	CLKDEV_CON_ID("pioB", &pioB_clk),
-	CLKDEV_CON_ID("pioC", &pioC_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff400.gpio", &pioA_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff600.gpio", &pioB_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff800.gpio", &pioC_clk),
-};
-
-static struct clk_lookup usart_clocks_lookups[] = {
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.0", &mck),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.1", &usart0_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.2", &usart1_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.3", &usart2_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.4", &usart3_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.5", &usart4_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.6", &usart5_clk),
+static struct clk_lookup pioA_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioA_clk", NULL),
+	CLKDEV_INIT(NULL, "pioA", NULL),
+};
+
+static struct clk_lookup pioB_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioB_clk", NULL),
+	CLKDEV_INIT(NULL, "pioB", NULL),
+};
+
+static struct clk_lookup pioC_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioC_clk", NULL),
+	CLKDEV_INIT(NULL, "pioC", NULL),
+};
+
+static struct clk_lookup adc_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "adc_clk", NULL),
+};
+
+static struct clk_lookup usart0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart0_clk", NULL),
+	CLKDEV_INIT("atmel_usart.1", "usart", NULL),
+};
+
+static struct clk_lookup usart1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart1_clk", NULL),
+	CLKDEV_INIT("atmel_usart.2", "usart", NULL),
+};
+
+static struct clk_lookup usart2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart2_clk", NULL),
+	CLKDEV_INIT("atmel_usart.3", "usart", NULL),
+};
+
+static struct clk_lookup mci_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "mci_clk", NULL),
+};
+
+static struct clk_lookup udc_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "udc_clk", NULL),
+};
+
+static struct clk_lookup twi_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "twi_clk", NULL),
+	CLKDEV_INIT("i2c-at91sam9260.0", NULL, NULL),
+	CLKDEV_INIT("i2c-at91sam9g20.0", NULL, NULL),
+};
+
+static struct clk_lookup spi0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "spi0_clk", NULL),
+	CLKDEV_INIT("atmel_spi.0", "spi_clk", NULL),
+};
+
+static struct clk_lookup spi1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "spi1_clk", NULL),
+	CLKDEV_INIT("atmel_spi.1", "spi_clk", NULL),
+};
+
+static struct clk_lookup ssc_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ssc_clk", NULL),
+	CLKDEV_INIT("at91rm9200_ssc.0", "pclk", NULL),
+};
+
+static struct clk_lookup tc0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc0_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.0", "t0_clk", NULL),
+};
+
+static struct clk_lookup tc1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc1_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.0", "t1_clk", NULL),
+};
+
+static struct clk_lookup tc2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc2_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.0", "t2_clk", NULL),
+};
+
+static struct clk_lookup ohci_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ohci_clk", NULL),
+	CLKDEV_INIT("at91_ohci", "hclk", NULL),
+};
+
+static struct clk_lookup macb_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pclk", NULL),
+	CLKDEV_INIT(NULL, "hclk", NULL),
+};
+
+static struct clk_lookup usart3_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart3_clk", NULL),
+	CLKDEV_INIT("atmel_usart.4", "usart", NULL),
+};
+
+static struct clk_lookup usart4_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart4_clk", NULL),
+	CLKDEV_INIT("atmel_usart.5", "usart", NULL),
+};
+
+static struct clk_lookup usart5_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart5_clk", NULL),
+	CLKDEV_INIT("atmel_usart.6", "usart", NULL),
+};
+
+static struct clk_lookup tc3_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc3_clk", NULL),
+	CLKDEV_INIT("t0_clk", "atmel_tcb.1", NULL),
+};
+
+static struct clk_lookup tc4_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc4_clk", NULL),
+	CLKDEV_INIT("t1_clk", "atmel_tcb.1", NULL),
+};
+
+static struct clk_lookup tc5_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc5_clk", NULL),
+	CLKDEV_INIT("t2_clk", "atmel_tcb.1", NULL),
+};
+
+static size_t periph_clock_lookup_sizes[] __initdata = {
+	0,
+	0,
+	ARRAY_SIZE(pioA_clk_lookup),
+	ARRAY_SIZE(pioB_clk_lookup),
+	ARRAY_SIZE(pioC_clk_lookup),
+	ARRAY_SIZE(adc_clk_lookup),
+	ARRAY_SIZE(usart0_clk_lookup),
+	ARRAY_SIZE(usart1_clk_lookup),
+	ARRAY_SIZE(usart2_clk_lookup),
+	ARRAY_SIZE(mci_clk_lookup),
+	ARRAY_SIZE(udc_clk_lookup),
+	ARRAY_SIZE(twi_clk_lookup),
+	0,
+	ARRAY_SIZE(spi0_clk_lookup),
+	ARRAY_SIZE(spi1_clk_lookup),
+	ARRAY_SIZE(ssc_clk_lookup),
+	0,
+	0,
+	ARRAY_SIZE(tc0_clk_lookup),
+	ARRAY_SIZE(tc1_clk_lookup),
+	ARRAY_SIZE(tc2_clk_lookup),
+	ARRAY_SIZE(ohci_clk_lookup),
+	ARRAY_SIZE(macb_clk_lookup),
+	0,
+	ARRAY_SIZE(usart3_clk_lookup),
+	ARRAY_SIZE(usart4_clk_lookup),
+	ARRAY_SIZE(usart5_clk_lookup),
+	ARRAY_SIZE(tc3_clk_lookup),
+	ARRAY_SIZE(tc4_clk_lookup),
+	ARRAY_SIZE(tc5_clk_lookup),
+};
+
+static struct clk_lookup *periph_clock_lookups[] __initdata = {
+	NULL,
+	NULL,
+	pioA_clk_lookup,
+	pioB_clk_lookup,
+	pioC_clk_lookup,
+	adc_clk_lookup,
+	usart0_clk_lookup,
+	usart1_clk_lookup,
+	usart2_clk_lookup,
+	mci_clk_lookup,
+	udc_clk_lookup,
+	twi_clk_lookup,
+	NULL,
+	spi0_clk_lookup,
+	spi1_clk_lookup,
+	ssc_clk_lookup,
+	NULL,
+	NULL,
+	tc0_clk_lookup,
+	tc1_clk_lookup,
+	tc2_clk_lookup,
+	ohci_clk_lookup,
+	macb_clk_lookup,
+	NULL,
+	usart3_clk_lookup,
+	usart4_clk_lookup,
+	usart5_clk_lookup,
+	tc3_clk_lookup,
+	tc4_clk_lookup,
+	tc5_clk_lookup,
+};
+
+
+/*
+ * The system clocks.
+ */
+static struct clk_lookup udp_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "udpck", NULL),
+};
+
+static struct clk_lookup uhp_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "uhpck", NULL),
+};
+
+static struct clk_lookup pck0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck0", NULL),
+};
+
+static struct clk_lookup pck1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck1", NULL),
+};
+
+static size_t system_clock_lookup_sizes[] __initdata = {
+	0,
+	0,
+	0,
+	0,
+	0,
+	0,
+	ARRAY_SIZE(uhp_clk_lookup),
+	ARRAY_SIZE(udp_clk_lookup),
+	ARRAY_SIZE(pck0_clk_lookup),
+	ARRAY_SIZE(pck1_clk_lookup),
+};
+
+static struct clk_lookup *system_clock_lookups[] __initdata = {
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	uhp_clk_lookup,
+	udp_clk_lookup,
+	pck0_clk_lookup,
+	pck1_clk_lookup,
 };
 
 /*
  * The two programmable clocks.
  * You must configure pin multiplexing to bring these signals out.
  */
-static struct clk pck0 = {
-	.name		= "pck0",
-	.pmc_mask	= AT91_PMC_PCK0,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 0,
+static const char *prog_clock_parent_names[] __initdata = {
+	"clk32k",
+	"main",
+	"plla",
+	"pllb",
+};
+
+static const char *prog_clock_names[] __initdata = {
+	"prog0",
+	"prog1",
+};
+
+/*
+ * The pll clocks.
+ */
+static struct clk_lookup pll_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "plla", NULL),
+	CLKDEV_INIT(NULL, "pllb", NULL),
+};
+
+static struct clk_range at91sam9260_plla_output[] = {
+	CLK_RANGE(80000000, 160000000),
+	CLK_RANGE(150000000, 240000000),
+};
+static u8 at91sam9260_plla_out[] = {0, 2};
+
+static struct clk_range at91sam9260_pllb_output[] = {
+	CLK_RANGE(70000000, 130000000),
+};
+static u8 at91sam9260_pllb_out[] = {1,};
+
+struct clk_pll_characteristics at91sam9260_pll_characteristics[] = {
+	{
+		.input = CLK_RANGE(1000000, 32000000),
+		.num_output = ARRAY_SIZE(at91sam9260_plla_output),
+		.output = at91sam9260_plla_output,
+		.out = at91sam9260_plla_out,
+	},
+	{
+		.input = CLK_RANGE(1000000, 5000000),
+		.num_output = ARRAY_SIZE(at91sam9260_pllb_output),
+		.output = at91sam9260_pllb_output,
+		.out = at91sam9260_pllb_out,
+	},
+};
+
+static struct clk_range at91sam9xe_plla_output[] = {
+	CLK_RANGE(80000000, 160000000),
+	CLK_RANGE(150000000, 220000000),
+};
+
+struct clk_pll_characteristics at91sam9xe_pll_characteristics[] = {
+	{
+		.input = CLK_RANGE(1000000, 32000000),
+		.num_output = ARRAY_SIZE(at91sam9xe_plla_output),
+		.output = at91sam9xe_plla_output,
+		.out = at91sam9260_plla_out,
+	},
+	{
+		.input = CLK_RANGE(1000000, 5000000),
+		.num_output = ARRAY_SIZE(at91sam9260_pllb_output),
+		.output = at91sam9260_pllb_output,
+		.out = at91sam9260_pllb_out,
+	},
+};
+
+static struct clk_range at91sam9g20_plla_output[] = {
+	CLK_RANGE(745000000, 800000000),
+	CLK_RANGE(695000000, 750000000),
+	CLK_RANGE(645000000, 700000000),
+	CLK_RANGE(595000000, 650000000),
+	CLK_RANGE(545000000, 600000000),
+	CLK_RANGE(495000000, 550000000),
+	CLK_RANGE(445000000, 500000000),
+	CLK_RANGE(400000000, 450000000),
+};
+static u8 at91sam9g20_plla_out[] = {0, 1, 2, 3, 0, 1, 2, 3};
+static u16 at91sam9g20_plla_icpll[] = {0, 0, 0, 0, 1, 1, 1, 1};
+
+static struct clk_range at91sam9g20_pllb_output[] = {
+	CLK_RANGE(30000000, 100000000),
+};
+static u8 at91sam9g20_pllb_out[] = {0};
+
+struct clk_pll_characteristics at91sam9g20_pll_characteristics[] = {
+	{
+		.input = CLK_RANGE(2000000, 32000000),
+		.num_output = ARRAY_SIZE(at91sam9g20_plla_output),
+		.output = at91sam9g20_plla_output,
+		.out = at91sam9g20_plla_out,
+		.icpll = at91sam9g20_plla_icpll,
+	},
+	{
+		.input = CLK_RANGE(2000000, 32000000),
+		.num_output = ARRAY_SIZE(at91sam9g20_pllb_output),
+		.output = at91sam9g20_pllb_output,
+		.out = at91sam9g20_pllb_out,
+	},
+};
+
+
+/*
+ * The master clock.
+ */
+static struct clk_lookup mck_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "mck", NULL),
+	CLKDEV_INIT("atmel_usart.0", "usart", NULL),
+};
+
+struct clk_master_characteristics at91sam9260_master_characteristics = {
+	.output = CLK_RANGE(0, 105000000),
+	.have_div3_pres = 0,
+	.divisors = {1, 2, 4, 0},
+};
+
+struct clk_master_characteristics at91sam9xe_master_characteristics = {
+	.output = CLK_RANGE(0, 90000000),
+	.have_div3_pres = 0,
+	.divisors = {1, 2, 4, 0},
+};
+
+struct clk_master_characteristics at91sam9g20_master_characteristics = {
+	.output = CLK_RANGE(0, 133000000),
+	.have_div3_pres = 0,
+	.divisors = {1, 2, 4, 6},
 };
-static struct clk pck1 = {
-	.name		= "pck1",
-	.pmc_mask	= AT91_PMC_PCK1,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 1,
+
+static const char *master_clock_parent_names[] __initdata = {
+	"clk32k",
+	"main",
+	"plla",
+	"pllb",
+};
+
+/*
+ * The USB clock.
+ */
+static u32 usb_divisors[] = {1, 2, 4, 0};
+
+static struct clk_lookup usb_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usb_clk", NULL),
 };
 
 static void __init at91sam9260_register_clocks(void)
 {
 	int i;
+	int k;
+	size_t size;
+	struct clk *clk;
+	const char *name;
+	struct clk_lookup *lookup;
+	struct clk_pll_characteristics *pll_characteristics;
+	struct clk_pll_layout *pll_layout;
+	struct clk_master_characteristics *master_characteristics;
+
+	if (cpu_is_at91sam9xe()) {
+		pll_characteristics = at91sam9xe_pll_characteristics;
+		master_characteristics = &at91sam9xe_master_characteristics;
+	} else if (cpu_is_at91sam9g20()) {
+		pll_characteristics = at91sam9g20_pll_characteristics;
+		master_characteristics = &at91sam9g20_master_characteristics;
+	} else {
+		pll_characteristics = at91sam9260_pll_characteristics;
+		master_characteristics = &at91sam9260_master_characteristics;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(pll_clk_lookup); i++) {
+		name = pll_clk_lookup[i].con_id;
+		pll_layout = &at91rm9200_pll_layout;
+		if (cpu_is_at91sam9g20()) {
+			if (!i)
+				pll_layout = &at91sam9g45_pll_layout;
+			else
+				pll_layout = &at91sam9g20_pllb_layout;
+		}
+		clk = at91_clk_register_pll(name, "main", i, pll_layout,
+					    &pll_characteristics[i]);
+		pll_clk_lookup[i].clk = clk;
+	}
+	clkdev_add_table(pll_clk_lookup, ARRAY_SIZE(pll_clk_lookup));
+
+	clk = at91_clk_register_master("mck",
+				       ARRAY_SIZE(master_clock_parent_names),
+				       master_clock_parent_names,
+				       &at91rm9200_master_layout,
+				       master_characteristics);
+	for (i = 0; i < ARRAY_SIZE(mck_clk_lookup); i++)
+		mck_clk_lookup[i].clk = clk;
+	clkdev_add_table(mck_clk_lookup, ARRAY_SIZE(mck_clk_lookup));
+
+	for (i = 0; i < ARRAY_SIZE(periph_clock_lookup_sizes); i++) {
+		size = periph_clock_lookup_sizes[i];
+		lookup = periph_clock_lookups[i];
+		if (!size || !lookup)
+			continue;
+		name = periph_clock_lookups[i][0].con_id;
+		if (!name)
+			continue;
+		clk = at91_clk_register_peripheral(name, "mck", i);
+
+		for (k = 0; k < size; k++)
+			lookup[k].clk = clk;
+		clkdev_add_table(lookup, size);
+	}
+
+	for (i = 0; i < ARRAY_SIZE(prog_clock_names); i++) {
+		name = prog_clock_names[i];
+		clk = at91_clk_register_programmable(name,
+					prog_clock_parent_names,
+					ARRAY_SIZE(prog_clock_parent_names),
+					i, &at91rm9200_programmable_layout);
+	}
 
-	for (i = 0; i < ARRAY_SIZE(periph_clocks); i++)
-		clk_register(periph_clocks[i]);
+	clk = at91rm9200_clk_register_usb("usbck", "pllb", usb_divisors);
+	for (i = 0; i < ARRAY_SIZE(usb_clk_lookup); i++)
+		usb_clk_lookup[i].clk = clk;
+	clkdev_add_table(usb_clk_lookup, ARRAY_SIZE(usb_clk_lookup));
 
-	clkdev_add_table(periph_clocks_lookups,
-			 ARRAY_SIZE(periph_clocks_lookups));
-	clkdev_add_table(usart_clocks_lookups,
-			 ARRAY_SIZE(usart_clocks_lookups));
+	for (i = 0; i < ARRAY_SIZE(system_clock_lookup_sizes); i++) {
+		size = system_clock_lookup_sizes[i];
+		lookup = system_clock_lookups[i];
+		if (!size || !lookup)
+			continue;
+		name = system_clock_lookups[i][0].con_id;
+		if (!name)
+			continue;
+		clk = at91_clk_register_system(name, i);
+		for (k = 0; k < size; k++)
+			lookup[k].clk = clk;
+		clkdev_add_table(lookup, size);
+	}
 
-	clk_register(&pck0);
-	clk_register(&pck1);
+	clk_register_fixed_rate(NULL, "adc_op_clk", "mck", 0, 5000000);
 }
 
 /* --------------------------------------------------------------------
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 10:44:39 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 16:44:39 +0200
Subject: [PATCH v2 15/42] ARM: at91: move at91sam9261 SoC to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374072279-19585-1-git-send-email-b.brezillon@overkiz.com>

This patch removes all references to the old at91 clks implementation and
make use of the new at91 clk implem for at91sam9261 SoC.

All dt specific lookups are removed (handled in clk device tree binding).

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/at91sam9261.c |  570 +++++++++++++++++++++++++-------------
 1 file changed, 374 insertions(+), 196 deletions(-)

diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
index a4123bd..50695e8 100644
--- a/arch/arm/mach-at91/at91sam9261.c
+++ b/arch/arm/mach-at91/at91sam9261.c
@@ -25,7 +25,6 @@
 #include "at91_rstc.h"
 #include "soc.h"
 #include "generic.h"
-#include "clock.h"
 #include "sam9_smc.h"
 
 /* --------------------------------------------------------------------
@@ -35,216 +34,395 @@
 /*
  * The peripheral clocks.
  */
-static struct clk pioA_clk = {
-	.name		= "pioA_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_PIOA,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioB_clk = {
-	.name		= "pioB_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_PIOB,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioC_clk = {
-	.name		= "pioC_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_PIOC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
-	.name		= "usart0_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_US0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
-	.name		= "usart1_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_US1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
-	.name		= "usart2_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_US2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc_clk = {
-	.name		= "mci_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_MCI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk udc_clk = {
-	.name		= "udc_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_UDP,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi_clk = {
-	.name		= "twi_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_TWI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi0_clk = {
-	.name		= "spi0_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_SPI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi1_clk = {
-	.name		= "spi1_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_SPI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc0_clk = {
-	.name		= "ssc0_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_SSC0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc1_clk = {
-	.name		= "ssc1_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_SSC1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc2_clk = {
-	.name		= "ssc2_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_SSC2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc0_clk = {
-	.name		= "tc0_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_TC0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc1_clk = {
-	.name		= "tc1_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_TC1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc2_clk = {
-	.name		= "tc2_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_TC2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ohci_clk = {
-	.name		= "ohci_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_UHP,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk lcdc_clk = {
-	.name		= "lcdc_clk",
-	.pmc_mask	= 1 << AT91SAM9261_ID_LCDC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-
-/* HClocks */
-static struct clk hck0 = {
-	.name		= "hck0",
-	.pmc_mask	= AT91_PMC_HCK0,
-	.type		= CLK_TYPE_SYSTEM,
-	.id		= 0,
-};
-static struct clk hck1 = {
-	.name		= "hck1",
-	.pmc_mask	= AT91_PMC_HCK1,
-	.type		= CLK_TYPE_SYSTEM,
-	.id		= 1,
-};
-
-static struct clk *periph_clocks[] __initdata = {
-	&pioA_clk,
-	&pioB_clk,
-	&pioC_clk,
-	&usart0_clk,
-	&usart1_clk,
-	&usart2_clk,
-	&mmc_clk,
-	&udc_clk,
-	&twi_clk,
-	&spi0_clk,
-	&spi1_clk,
-	&ssc0_clk,
-	&ssc1_clk,
-	&ssc2_clk,
-	&tc0_clk,
-	&tc1_clk,
-	&tc2_clk,
-	&ohci_clk,
-	&lcdc_clk,
-	// irq0 .. irq2
-};
-
-static struct clk_lookup periph_clocks_lookups[] = {
-	CLKDEV_CON_DEV_ID("hclk", "at91sam9261-lcdfb.0", &hck1),
-	CLKDEV_CON_DEV_ID("hclk", "at91sam9g10-lcdfb.0", &hck1),
-	CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.1", &spi1_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk),
-	CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.0", &tc1_clk),
-	CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk),
-	CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk),
-	CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk),
-	CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk),
-	CLKDEV_CON_DEV_ID("pclk", "fffbc000.ssc", &ssc0_clk),
-	CLKDEV_CON_DEV_ID("pclk", "fffc0000.ssc", &ssc1_clk),
-	CLKDEV_CON_DEV_ID("pclk", "fffc4000.ssc", &ssc2_clk),
-	CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &hck0),
-	CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9261.0", &twi_clk),
-	CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.0", &twi_clk),
-	CLKDEV_CON_ID("pioA", &pioA_clk),
-	CLKDEV_CON_ID("pioB", &pioB_clk),
-	CLKDEV_CON_ID("pioC", &pioC_clk),
-};
-
-static struct clk_lookup usart_clocks_lookups[] = {
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.0", &mck),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.1", &usart0_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.2", &usart1_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.3", &usart2_clk),
+static struct clk_lookup pioA_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioA_clk", NULL),
+	CLKDEV_INIT(NULL, "pioA", NULL),
+};
+
+static struct clk_lookup pioB_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioB_clk", NULL),
+	CLKDEV_INIT(NULL, "pioB", NULL),
+};
+
+static struct clk_lookup pioC_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioB_clk", NULL),
+	CLKDEV_INIT(NULL, "pioB", NULL),
+};
+
+static struct clk_lookup usart0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart0_clk", NULL),
+	CLKDEV_INIT("atmel_usart.1", "usart", NULL),
+};
+
+static struct clk_lookup usart1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart1_clk", NULL),
+	CLKDEV_INIT("atmel_usart.2", "usart", NULL),
+};
+
+static struct clk_lookup usart2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart2_clk", NULL),
+	CLKDEV_INIT("atmel_usart.3", "usart", NULL),
+};
+
+static struct clk_lookup mci_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "mci_clk", NULL),
+};
+
+static struct clk_lookup udc_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "udc_clk", NULL),
+};
+
+static struct clk_lookup twi_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "twi_clk", NULL),
+	CLKDEV_INIT("i2c-at91sam9261.0", NULL, NULL),
+	CLKDEV_INIT("i2c-at91sam9g10.0", NULL, NULL),
+};
+
+static struct clk_lookup spi0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "spi0_clk", NULL),
+	CLKDEV_INIT("atmel_spi.0", "spi_clk", NULL),
+};
+
+static struct clk_lookup spi1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "spi1_clk", NULL),
+	CLKDEV_INIT("atmel_spi.1", "spi_clk", NULL),
+};
+
+static struct clk_lookup ssc0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ssc0_clk", NULL),
+	CLKDEV_INIT("at91rm9200_ssc.0", "pclk", NULL),
+};
+
+static struct clk_lookup ssc1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ssc1_clk", NULL),
+	CLKDEV_INIT("at91rm9200_ssc.1", "pclk", NULL),
+};
+
+static struct clk_lookup ssc2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ssc2_clk", NULL),
+	CLKDEV_INIT("at91rm9200_ssc.2", "pclk", NULL),
+};
+
+static struct clk_lookup tc0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc0_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.0", "t0_clk", NULL),
+};
+
+static struct clk_lookup tc1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc1_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.0", "t1_clk", NULL),
+};
+
+static struct clk_lookup tc2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc2_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.2", "t2_clk", NULL),
+};
+
+static struct clk_lookup ohci_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ohci_clk", NULL),
+};
+
+static struct clk_lookup lcdc_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "lcdc_clk", NULL),
+};
+
+static size_t periph_clock_lookup_sizes[] __initdata = {
+	0,
+	0,
+	ARRAY_SIZE(pioA_clk_lookup),
+	ARRAY_SIZE(pioB_clk_lookup),
+	ARRAY_SIZE(pioC_clk_lookup),
+	0,
+	ARRAY_SIZE(usart0_clk_lookup),
+	ARRAY_SIZE(usart1_clk_lookup),
+	ARRAY_SIZE(usart2_clk_lookup),
+	ARRAY_SIZE(mci_clk_lookup),
+	ARRAY_SIZE(udc_clk_lookup),
+	ARRAY_SIZE(twi_clk_lookup),
+	ARRAY_SIZE(spi0_clk_lookup),
+	ARRAY_SIZE(spi1_clk_lookup),
+	ARRAY_SIZE(ssc0_clk_lookup),
+	ARRAY_SIZE(ssc1_clk_lookup),
+	ARRAY_SIZE(ssc2_clk_lookup),
+	ARRAY_SIZE(tc0_clk_lookup),
+	ARRAY_SIZE(tc1_clk_lookup),
+	ARRAY_SIZE(tc2_clk_lookup),
+	ARRAY_SIZE(ohci_clk_lookup),
+	ARRAY_SIZE(lcdc_clk_lookup),
+};
+
+static struct clk_lookup *periph_clock_lookups[] __initdata = {
+	NULL,
+	NULL,
+	pioA_clk_lookup,
+	pioB_clk_lookup,
+	pioC_clk_lookup,
+	NULL,
+	usart0_clk_lookup,
+	usart1_clk_lookup,
+	usart2_clk_lookup,
+	mci_clk_lookup,
+	udc_clk_lookup,
+	twi_clk_lookup,
+	spi0_clk_lookup,
+	spi1_clk_lookup,
+	ssc0_clk_lookup,
+	ssc1_clk_lookup,
+	ssc2_clk_lookup,
+	tc0_clk_lookup,
+	tc1_clk_lookup,
+	tc2_clk_lookup,
+	ohci_clk_lookup,
+	lcdc_clk_lookup,
+};
+
+
+/*
+ * The system clocks.
+ */
+static struct clk_lookup udp_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "udpck", NULL),
+};
+
+static struct clk_lookup uhp_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "uhpck", NULL),
+};
+
+static struct clk_lookup pck0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck0", NULL),
+};
+
+static struct clk_lookup pck1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck1", NULL),
+};
+
+static struct clk_lookup pck2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck2", NULL),
+};
+
+static struct clk_lookup pck3_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck3", NULL),
+};
+
+static struct clk_lookup hck0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "hck0", NULL),
+	CLKDEV_INIT("at91_ohci", "hclk", NULL),
+};
+
+static struct clk_lookup hck1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "hck1", NULL),
+	CLKDEV_INIT("at91sam9261-lcdfb.0", "hclk", NULL),
+	CLKDEV_INIT("at91sam9g10-lcdfb.0", "hclk", NULL),
+};
+
+static size_t system_clock_lookup_sizes[] __initdata = {
+	0,
+	0,
+	0,
+	0,
+	0,
+	0,
+	ARRAY_SIZE(uhp_clk_lookup),
+	ARRAY_SIZE(udp_clk_lookup),
+	ARRAY_SIZE(pck0_clk_lookup),
+	ARRAY_SIZE(pck1_clk_lookup),
+	ARRAY_SIZE(pck2_clk_lookup),
+	ARRAY_SIZE(pck3_clk_lookup),
+	0,
+	0,
+	0,
+	0,
+	ARRAY_SIZE(hck0_clk_lookup),
+	ARRAY_SIZE(hck1_clk_lookup),
+};
+
+static struct clk_lookup *system_clock_lookups[] __initdata = {
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	uhp_clk_lookup,
+	udp_clk_lookup,
+	pck0_clk_lookup,
+	pck1_clk_lookup,
+	pck2_clk_lookup,
+	pck3_clk_lookup,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	hck0_clk_lookup,
+	hck1_clk_lookup,
 };
 
 /*
  * The four programmable clocks.
  * You must configure pin multiplexing to bring these signals out.
  */
-static struct clk pck0 = {
-	.name		= "pck0",
-	.pmc_mask	= AT91_PMC_PCK0,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 0,
-};
-static struct clk pck1 = {
-	.name		= "pck1",
-	.pmc_mask	= AT91_PMC_PCK1,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 1,
-};
-static struct clk pck2 = {
-	.name		= "pck2",
-	.pmc_mask	= AT91_PMC_PCK2,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 2,
-};
-static struct clk pck3 = {
-	.name		= "pck3",
-	.pmc_mask	= AT91_PMC_PCK3,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 3,
+static const char *prog_clock_parent_names[] __initdata = {
+	"clk32k",
+	"main",
+	"plla",
+	"pllb",
+};
+
+static const char *prog_clock_names[] __initdata = {
+	"prog0",
+	"prog1",
+	"prog2",
+	"prog3",
+};
+
+/*
+ * The pll clocks.
+ */
+static struct clk_lookup pll_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "plla", NULL),
+	CLKDEV_INIT(NULL, "pllb", NULL),
+};
+
+static struct clk_range at91sam9261_pll_output[] = {
+	CLK_RANGE(80000000, 200000000),
+	CLK_RANGE(190000000, 240000000),
+};
+static u8 at91sam9261_pll_out[] = {0, 2};
+
+struct clk_pll_characteristics at91sam9261_pll_characteristics = {
+	.input = CLK_RANGE(1000000, 32000000),
+	.num_output = ARRAY_SIZE(at91sam9261_pll_output),
+	.output = at91sam9261_pll_output,
+	.out = at91sam9261_pll_out,
+};
+
+static struct clk_range at91sam9g10_pll_output[] = {
+	CLK_RANGE(80000000, 266000000),
+};
+static u8 at91sam9g10_pll_out[] = {0};
+
+struct clk_pll_characteristics at91sam9g10_pll_characteristics = {
+	.input = CLK_RANGE(1000000, 32000000),
+	.num_output = ARRAY_SIZE(at91sam9g10_pll_output),
+	.output = at91sam9g10_pll_output,
+	.out = at91sam9g10_pll_out,
+};
+
+
+/*
+ * The master clock.
+ */
+static struct clk_lookup mck_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "mck", NULL),
+	CLKDEV_INIT("atmel_usart.0", "usart", NULL),
+};
+
+struct clk_master_characteristics at91sam9261_master_characteristics = {
+	.output = CLK_RANGE(0, 94000000),
+	.have_div3_pres = 0,
+	.divisors = {1, 2, 4, 0},
+};
+
+struct clk_master_characteristics at91sam9g10_master_characteristics = {
+	.output = CLK_RANGE(0, 133000000),
+	.have_div3_pres = 0,
+	.divisors = {1, 2, 4, 0},
+};
+
+static const char *master_clock_parent_names[] __initdata = {
+	"clk32k",
+	"main",
+	"plla",
+	"pllb",
+};
+
+/*
+ * The USB clock.
+ */
+static u32 usb_divisors[] = {1, 2, 4, 0};
+
+static struct clk_lookup usb_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usb_clk", NULL),
 };
 
 static void __init at91sam9261_register_clocks(void)
 {
 	int i;
+	int k;
+	size_t size;
+	struct clk *clk;
+	const char *name;
+	struct clk_lookup *lookup;
+	struct clk_pll_characteristics *pll_characteristics;
+	struct clk_master_characteristics *master_characteristics;
+
+	if (cpu_is_at91sam9g10()) {
+		pll_characteristics = &at91sam9g10_pll_characteristics;
+		master_characteristics = &at91sam9g10_master_characteristics;
+	} else {
+		pll_characteristics = &at91sam9261_pll_characteristics;
+		master_characteristics = &at91sam9261_master_characteristics;
+	}
 
-	for (i = 0; i < ARRAY_SIZE(periph_clocks); i++)
-		clk_register(periph_clocks[i]);
+	for (i = 0; i < ARRAY_SIZE(pll_clk_lookup); i++) {
+		name = pll_clk_lookup[i].con_id;
+		clk = at91_clk_register_pll(name, "main", i,
+					    &at91rm9200_pll_layout,
+					    &pll_characteristics[i]);
+		pll_clk_lookup[i].clk = clk;
+	}
+	clkdev_add_table(pll_clk_lookup, ARRAY_SIZE(pll_clk_lookup));
+
+	clk = at91_clk_register_master("mck",
+				       ARRAY_SIZE(master_clock_parent_names),
+				       master_clock_parent_names,
+				       &at91rm9200_master_layout,
+				       master_characteristics);
+	for (i = 0; i < ARRAY_SIZE(mck_clk_lookup); i++)
+		mck_clk_lookup[i].clk = clk;
+	clkdev_add_table(mck_clk_lookup, ARRAY_SIZE(mck_clk_lookup));
 
-	clkdev_add_table(periph_clocks_lookups,
-			 ARRAY_SIZE(periph_clocks_lookups));
-	clkdev_add_table(usart_clocks_lookups,
-			 ARRAY_SIZE(usart_clocks_lookups));
+	for (i = 0; i < ARRAY_SIZE(periph_clock_lookup_sizes); i++) {
+		size = periph_clock_lookup_sizes[i];
+		lookup = periph_clock_lookups[i];
+		if (!size || !lookup)
+			continue;
+		name = periph_clock_lookups[i][0].con_id;
+		if (!name)
+			continue;
+		clk = at91_clk_register_peripheral(name, "mck", i);
 
-	clk_register(&pck0);
-	clk_register(&pck1);
-	clk_register(&pck2);
-	clk_register(&pck3);
+		for (k = 0; k < size; k++)
+			lookup[k].clk = clk;
+		clkdev_add_table(lookup, size);
+	}
 
-	clk_register(&hck0);
-	clk_register(&hck1);
+	for (i = 0; i < ARRAY_SIZE(prog_clock_names); i++) {
+		name = prog_clock_names[i];
+		clk = at91_clk_register_programmable(name,
+					prog_clock_parent_names,
+					ARRAY_SIZE(prog_clock_parent_names),
+					i, &at91rm9200_programmable_layout);
+	}
+
+	clk = at91rm9200_clk_register_usb("usbck", "pllb", usb_divisors);
+	for (i = 0; i < ARRAY_SIZE(usb_clk_lookup); i++)
+		usb_clk_lookup[i].clk = clk;
+	clkdev_add_table(usb_clk_lookup, ARRAY_SIZE(usb_clk_lookup));
+
+	for (i = 0; i < ARRAY_SIZE(system_clock_lookup_sizes); i++) {
+		size = system_clock_lookup_sizes[i];
+		lookup = system_clock_lookups[i];
+		if (!size || !lookup)
+			continue;
+		name = system_clock_lookups[i][0].con_id;
+		if (!name)
+			continue;
+		clk = at91_clk_register_system(name, i);
+		for (k = 0; k < size; k++)
+			lookup[k].clk = clk;
+		clkdev_add_table(lookup, size);
+	}
 }
 
 /* --------------------------------------------------------------------
-- 
1.7.9.5



From andrew at lunn.ch  Wed Jul 17 10:43:55 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 17 Jul 2013 16:43:55 +0200
Subject: [RFC PATCH v2 11/15] cpufreq: kirkwood-cpufreq: remove device
 tree parsing for cpu nodes
In-Reply-To: <1374069984-20567-12-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374069984-20567-12-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <20130717144355.GE1026@lunn.ch>

On Wed, Jul 17, 2013 at 03:06:20PM +0100, Sudeep.KarkadaNagesha at arm.com wrote:
> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> Now that the cpu device registration initialises the of_node(if available)
> appropriately for all the cpus, parsing here is redundant.
> 
> This patch removes all DT parsing and uses cpu->of_node instead.
> 
> Cc: Andrew Lunn <andrew at lunn.ch>
> Cc: Jason Cooper <jason at lakedaemon.net>
> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> ---
>  drivers/cpufreq/kirkwood-cpufreq.c | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
> index c233ea6..18aa3eb 100644
> --- a/drivers/cpufreq/kirkwood-cpufreq.c
> +++ b/drivers/cpufreq/kirkwood-cpufreq.c
> @@ -13,6 +13,7 @@
>  #include <linux/module.h>
>  #include <linux/clk.h>
>  #include <linux/clk-provider.h>
> +#include <linux/cpu.h>
>  #include <linux/cpufreq.h>
>  #include <linux/of.h>
>  #include <linux/platform_device.h>
> @@ -165,6 +166,7 @@ static struct cpufreq_driver kirkwood_cpufreq_driver = {
>  static int kirkwood_cpufreq_probe(struct platform_device *pdev)
>  {
>  	struct device_node *np;
> +	struct device *cpu_dev;
>  	struct resource *res;
>  	int err;
>  
> @@ -175,9 +177,17 @@ static int kirkwood_cpufreq_probe(struct platform_device *pdev)
>  	if (IS_ERR(priv.base))
>  		return PTR_ERR(priv.base);
>  
> -	np = of_find_node_by_path("/cpus/cpu at 0");
> -	if (!np)
> +	cpu_dev = get_cpu_device(0);
> +	if (!cpu_dev) {
> +		dev_err(&pdev->dev, "failed to get cpu device\n");
>  		return -ENODEV;
> +	}
> +
> +	np = of_node_get(cpu_dev->of_node);
> +	if (!np) {
> +		dev_err(&pdev->dev, "failed to get cpu device node\n");
> +		return -ENODEV;
> +	}

Hi Sudeep

Are we not going a bit backwards here? You are replacing two lines
with 10 lines.

How about putting these 10 lines into some helper,
of_get_cpu_device()?  It would be useful for spear, kirkwood and
imx6q, and maybe others.

    Thanks
	Andrew


From b.brezillon at overkiz.com  Wed Jul 17 10:45:54 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 16:45:54 +0200
Subject: [PATCH v2 16/42] ARM: at91: move at91sam9263 SoC to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374072354-19624-1-git-send-email-b.brezillon@overkiz.com>

This patch removes all references to the old at91 clks implementation and
make use of the new at91 clk implem for at91sam9263 SoC.

All dt specific lookups are removed (handled in clk device tree binding).

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/at91sam9263.c |  593 +++++++++++++++++++++++---------------
 1 file changed, 364 insertions(+), 229 deletions(-)

diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
index e0a1a68..339b9ef 100644
--- a/arch/arm/mach-at91/at91sam9263.c
+++ b/arch/arm/mach-at91/at91sam9263.c
@@ -24,7 +24,6 @@
 #include "at91_rstc.h"
 #include "soc.h"
 #include "generic.h"
-#include "clock.h"
 #include "sam9_smc.h"
 
 /* --------------------------------------------------------------------
@@ -34,248 +33,384 @@
 /*
  * The peripheral clocks.
  */
-static struct clk pioA_clk = {
-	.name		= "pioA_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_PIOA,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioB_clk = {
-	.name		= "pioB_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_PIOB,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioCDE_clk = {
-	.name		= "pioCDE_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_PIOCDE,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
-	.name		= "usart0_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_US0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
-	.name		= "usart1_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_US1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
-	.name		= "usart2_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_US2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc0_clk = {
-	.name		= "mci0_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_MCI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc1_clk = {
-	.name		= "mci1_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_MCI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk can_clk = {
-	.name		= "can_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_CAN,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi_clk = {
-	.name		= "twi_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_TWI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi0_clk = {
-	.name		= "spi0_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_SPI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi1_clk = {
-	.name		= "spi1_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_SPI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc0_clk = {
-	.name		= "ssc0_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_SSC0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc1_clk = {
-	.name		= "ssc1_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_SSC1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ac97_clk = {
-	.name		= "ac97_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_AC97C,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tcb_clk = {
-	.name		= "tcb_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_TCB,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pwm_clk = {
-	.name		= "pwm_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_PWMC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk macb_clk = {
-	.name		= "pclk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_EMAC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk dma_clk = {
-	.name		= "dma_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_DMA,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk twodge_clk = {
-	.name		= "2dge_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_2DGE,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk udc_clk = {
-	.name		= "udc_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_UDP,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk isi_clk = {
-	.name		= "isi_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_ISI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk lcdc_clk = {
-	.name		= "lcdc_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_LCDC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ohci_clk = {
-	.name		= "ohci_clk",
-	.pmc_mask	= 1 << AT91SAM9263_ID_UHP,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-
-static struct clk *periph_clocks[] __initdata = {
-	&pioA_clk,
-	&pioB_clk,
-	&pioCDE_clk,
-	&usart0_clk,
-	&usart1_clk,
-	&usart2_clk,
-	&mmc0_clk,
-	&mmc1_clk,
-	&can_clk,
-	&twi_clk,
-	&spi0_clk,
-	&spi1_clk,
-	&ssc0_clk,
-	&ssc1_clk,
-	&ac97_clk,
-	&tcb_clk,
-	&pwm_clk,
-	&macb_clk,
-	&twodge_clk,
-	&udc_clk,
-	&isi_clk,
-	&lcdc_clk,
-	&dma_clk,
-	&ohci_clk,
-	// irq0 .. irq1
-};
-
-static struct clk_lookup periph_clocks_lookups[] = {
-	/* One additional fake clock for macb_hclk */
-	CLKDEV_CON_ID("hclk", &macb_clk),
-	CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk),
-	CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk),
-	CLKDEV_CON_DEV_ID("pclk", "fff98000.ssc", &ssc0_clk),
-	CLKDEV_CON_DEV_ID("pclk", "fff9c000.ssc", &ssc1_clk),
-	CLKDEV_CON_DEV_ID("hclk", "at91sam9263-lcdfb.0", &lcdc_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.0", &mmc0_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.1", &mmc1_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.1", &spi1_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tcb_clk),
-	CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260.0", &twi_clk),
-	/* fake hclk clock */
-	CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk),
-	CLKDEV_CON_ID("pioA", &pioA_clk),
-	CLKDEV_CON_ID("pioB", &pioB_clk),
-	CLKDEV_CON_ID("pioC", &pioCDE_clk),
-	CLKDEV_CON_ID("pioD", &pioCDE_clk),
-	CLKDEV_CON_ID("pioE", &pioCDE_clk),
-	/* more usart lookup table for DT entries */
-	CLKDEV_CON_DEV_ID("usart", "ffffee00.serial", &mck),
-	CLKDEV_CON_DEV_ID("usart", "fff8c000.serial", &usart0_clk),
-	CLKDEV_CON_DEV_ID("usart", "fff90000.serial", &usart1_clk),
-	CLKDEV_CON_DEV_ID("usart", "fff94000.serial", &usart2_clk),
-	/* more tc lookup table for DT entries */
-	CLKDEV_CON_DEV_ID("t0_clk", "fff7c000.timer", &tcb_clk),
-	CLKDEV_CON_DEV_ID("hclk", "a00000.ohci", &ohci_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "fffa4000.spi", &spi0_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "fffa8000.spi", &spi1_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "fff80000.mmc", &mmc0_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "fff84000.mmc", &mmc1_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fff88000.i2c", &twi_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff200.gpio", &pioA_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff400.gpio", &pioB_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff600.gpio", &pioCDE_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff800.gpio", &pioCDE_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffffa00.gpio", &pioCDE_clk),
-};
-
-static struct clk_lookup usart_clocks_lookups[] = {
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.0", &mck),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.1", &usart0_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.2", &usart1_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.3", &usart2_clk),
+static struct clk_lookup pioA_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioA_clk", NULL),
+	CLKDEV_INIT(NULL, "pioA", NULL),
+};
+
+static struct clk_lookup pioB_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioB_clk", NULL),
+	CLKDEV_INIT(NULL, "pioB", NULL),
+};
+
+static struct clk_lookup pioCDE_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioCDE_clk", NULL),
+	CLKDEV_INIT(NULL, "pioC", NULL),
+	CLKDEV_INIT(NULL, "pioD", NULL),
+	CLKDEV_INIT(NULL, "pioE", NULL),
+};
+
+static struct clk_lookup usart0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart0_clk", NULL),
+	CLKDEV_INIT("atmel_usart.1", "usart", NULL),
+};
+
+static struct clk_lookup usart1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart1_clk", NULL),
+	CLKDEV_INIT("atmel_usart.2", "usart", NULL),
+};
+
+static struct clk_lookup usart2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart2_clk", NULL),
+	CLKDEV_INIT("atmel_usart.3", "usart", NULL),
+};
+
+static struct clk_lookup mci0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "mci0_clk", NULL),
+	CLKDEV_INIT("atmel_mci.0", "mci_clk", NULL),
+};
+
+static struct clk_lookup mci1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "mci1_clk", NULL),
+	CLKDEV_INIT("atmel_mci.1", "mci_clk", NULL),
+};
+
+static struct clk_lookup can_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "can_clk", NULL),
+};
+
+static struct clk_lookup twi_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "twi_clk", NULL),
+	CLKDEV_INIT("i2c-at91sam9260.0", NULL, NULL),
+};
+
+static struct clk_lookup spi0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "spi0_clk", NULL),
+	CLKDEV_INIT("atmel_spi.0", "spi_clk", NULL),
+};
+
+static struct clk_lookup spi1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "spi1_clk", NULL),
+	CLKDEV_INIT("atmel_spi.1", "spi_clk", NULL),
+};
+
+static struct clk_lookup ssc0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ssc0_clk", NULL),
+	CLKDEV_INIT("at91rm9200_ssc.0", "pclk", NULL),
+};
+
+static struct clk_lookup ssc1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ssc1_clk", NULL),
+	CLKDEV_INIT("at91rm9200_ssc.1", "pclk", NULL),
+};
+
+static struct clk_lookup ac97_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ac97_clk", NULL),
+};
+
+static struct clk_lookup tcb_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tcb_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.0", "t0_clk", NULL),
+};
+
+static struct clk_lookup pwm_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pwm_clk", NULL),
+};
+
+static struct clk_lookup macb_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pclk", NULL),
+	CLKDEV_INIT(NULL, "hclk", NULL),
+};
+
+static struct clk_lookup twodge_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "2dge_clk", NULL),
+};
+
+static struct clk_lookup udc_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "udc_clk", NULL),
+};
+
+static struct clk_lookup isi_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "isi_clk", NULL),
+};
+
+static struct clk_lookup lcdc_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "lcdc_clk", NULL),
+	CLKDEV_INIT("at91sam9263-lcdfb.0", "hclk", NULL),
+};
+
+static struct clk_lookup dma_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "dma_clk", NULL),
+};
+
+static struct clk_lookup ohci_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ohci_clk", NULL),
+	CLKDEV_INIT("at91_ohci", "hclk", NULL),
+};
+
+static size_t periph_clock_lookup_sizes[] __initdata = {
+	0,
+	0,
+	ARRAY_SIZE(pioA_clk_lookup),
+	ARRAY_SIZE(pioB_clk_lookup),
+	ARRAY_SIZE(pioCDE_clk_lookup),
+	0,
+	0,
+	ARRAY_SIZE(usart0_clk_lookup),
+	ARRAY_SIZE(usart1_clk_lookup),
+	ARRAY_SIZE(usart2_clk_lookup),
+	ARRAY_SIZE(mci0_clk_lookup),
+	ARRAY_SIZE(mci1_clk_lookup),
+	ARRAY_SIZE(can_clk_lookup),
+	ARRAY_SIZE(twi_clk_lookup),
+	ARRAY_SIZE(spi0_clk_lookup),
+	ARRAY_SIZE(spi1_clk_lookup),
+	ARRAY_SIZE(ssc0_clk_lookup),
+	ARRAY_SIZE(ssc1_clk_lookup),
+	ARRAY_SIZE(ac97_clk_lookup),
+	ARRAY_SIZE(tcb_clk_lookup),
+	ARRAY_SIZE(pwm_clk_lookup),
+	ARRAY_SIZE(macb_clk_lookup),
+	0,
+	ARRAY_SIZE(twodge_clk_lookup),
+	ARRAY_SIZE(udc_clk_lookup),
+	ARRAY_SIZE(isi_clk_lookup),
+	ARRAY_SIZE(lcdc_clk_lookup),
+	ARRAY_SIZE(dma_clk_lookup),
+	0,
+	ARRAY_SIZE(ohci_clk_lookup),
+};
+
+static struct clk_lookup *periph_clock_lookups[] __initdata = {
+	NULL,
+	NULL,
+	pioA_clk_lookup,
+	pioB_clk_lookup,
+	pioCDE_clk_lookup,
+	NULL,
+	NULL,
+	usart0_clk_lookup,
+	usart1_clk_lookup,
+	usart2_clk_lookup,
+	mci0_clk_lookup,
+	mci1_clk_lookup,
+	can_clk_lookup,
+	twi_clk_lookup,
+	spi0_clk_lookup,
+	spi1_clk_lookup,
+	ssc0_clk_lookup,
+	ssc1_clk_lookup,
+	ac97_clk_lookup,
+	tcb_clk_lookup,
+	pwm_clk_lookup,
+	macb_clk_lookup,
+	NULL,
+	twodge_clk_lookup,
+	udc_clk_lookup,
+	isi_clk_lookup,
+	lcdc_clk_lookup,
+	dma_clk_lookup,
+	NULL,
+	ohci_clk_lookup,
+};
+
+
+/*
+ * The system clocks.
+ */
+static struct clk_lookup udp_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "udpck", NULL),
+};
+
+static struct clk_lookup uhp_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "uhpck", NULL),
+};
+
+static struct clk_lookup pck0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck0", NULL),
+};
+
+static struct clk_lookup pck1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck1", NULL),
+};
+
+static struct clk_lookup pck2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck2", NULL),
+};
+
+static struct clk_lookup pck3_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck3", NULL),
+};
+
+static size_t system_clock_lookup_sizes[] __initdata = {
+	0,
+	0,
+	0,
+	0,
+	0,
+	0,
+	ARRAY_SIZE(uhp_clk_lookup),
+	ARRAY_SIZE(udp_clk_lookup),
+	ARRAY_SIZE(pck0_clk_lookup),
+	ARRAY_SIZE(pck1_clk_lookup),
+	ARRAY_SIZE(pck2_clk_lookup),
+	ARRAY_SIZE(pck3_clk_lookup),
+};
+
+static struct clk_lookup *system_clock_lookups[] __initdata = {
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	uhp_clk_lookup,
+	udp_clk_lookup,
+	pck0_clk_lookup,
+	pck1_clk_lookup,
+	pck2_clk_lookup,
+	pck3_clk_lookup,
 };
 
 /*
  * The four programmable clocks.
  * You must configure pin multiplexing to bring these signals out.
  */
-static struct clk pck0 = {
-	.name		= "pck0",
-	.pmc_mask	= AT91_PMC_PCK0,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 0,
-};
-static struct clk pck1 = {
-	.name		= "pck1",
-	.pmc_mask	= AT91_PMC_PCK1,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 1,
-};
-static struct clk pck2 = {
-	.name		= "pck2",
-	.pmc_mask	= AT91_PMC_PCK2,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 2,
-};
-static struct clk pck3 = {
-	.name		= "pck3",
-	.pmc_mask	= AT91_PMC_PCK3,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 3,
+static const char *prog_clock_parent_names[] __initdata = {
+	"clk32k",
+	"main",
+	"plla",
+	"pllb",
+};
+
+static const char *prog_clock_names[] __initdata = {
+	"prog0",
+	"prog1",
+	"prog2",
+	"prog3",
+};
+
+/*
+ * The pll clocks.
+ */
+static struct clk_lookup pll_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "plla", NULL),
+	CLKDEV_INIT(NULL, "pllb", NULL),
+};
+
+static struct clk_range at91sam9263_pll_output[] = {
+	CLK_RANGE(80000000, 200000000),
+	CLK_RANGE(190000000, 240000000),
+};
+static u8 at91sam9263_pll_out[] = {0, 2};
+
+struct clk_pll_characteristics at91sam9263_pll_characteristics = {
+	.input = CLK_RANGE(2000000, 32000000),
+	.num_output = ARRAY_SIZE(at91sam9263_pll_output),
+	.output = at91sam9263_pll_output,
+	.out = at91sam9263_pll_out,
+};
+
+struct clk_master_characteristics at91sam9263_master_characteristics = {
+	.output = CLK_RANGE(0, 120000000),
+	.have_div3_pres = 0,
+	.divisors = {1, 2, 4, 0},
+};
+
+
+/*
+ * The master clock.
+ */
+static struct clk_lookup mck_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "mck", NULL),
+	CLKDEV_INIT("atmel_usart.0", "usart", NULL),
+};
+
+static const char *master_clock_parent_names[] __initdata = {
+	"clk32k",
+	"main",
+	"plla",
+	"pllb",
+};
+
+
+/*
+ * The USB clock.
+ */
+static u32 usb_divisors[] = {1, 2, 4, 0};
+
+static struct clk_lookup usb_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usb_clk", NULL),
 };
 
 static void __init at91sam9263_register_clocks(void)
 {
 	int i;
+	int k;
+	size_t size;
+	struct clk *clk;
+	const char *name;
+	struct clk_lookup *lookup;
+
+	for (i = 0; i < ARRAY_SIZE(pll_clk_lookup); i++) {
+		name = pll_clk_lookup[i].con_id;
+		clk = at91_clk_register_pll(name, "main", i,
+					    &at91rm9200_pll_layout,
+					    &at91sam9263_pll_characteristics);
+		pll_clk_lookup[i].clk = clk;
+	}
+	clkdev_add_table(pll_clk_lookup, ARRAY_SIZE(pll_clk_lookup));
+
+	clk = at91_clk_register_master("mck",
+				       ARRAY_SIZE(master_clock_parent_names),
+				       master_clock_parent_names,
+				       &at91rm9200_master_layout,
+				       &at91sam9263_master_characteristics);
+	for (i = 0; i < ARRAY_SIZE(mck_clk_lookup); i++)
+		mck_clk_lookup[i].clk = clk;
+	clkdev_add_table(mck_clk_lookup, ARRAY_SIZE(mck_clk_lookup));
 
-	for (i = 0; i < ARRAY_SIZE(periph_clocks); i++)
-		clk_register(periph_clocks[i]);
+	for (i = 0; i < ARRAY_SIZE(periph_clock_lookup_sizes); i++) {
+		size = periph_clock_lookup_sizes[i];
+		lookup = periph_clock_lookups[i];
+		if (!size || !lookup)
+			continue;
+		name = periph_clock_lookups[i][0].con_id;
+		if (!name)
+			continue;
+		clk = at91_clk_register_peripheral(name, "mck", i);
 
-	clkdev_add_table(periph_clocks_lookups,
-			 ARRAY_SIZE(periph_clocks_lookups));
-	clkdev_add_table(usart_clocks_lookups,
-			 ARRAY_SIZE(usart_clocks_lookups));
+		for (k = 0; k < size; k++)
+			lookup[k].clk = clk;
+		clkdev_add_table(lookup, size);
+	}
 
-	clk_register(&pck0);
-	clk_register(&pck1);
-	clk_register(&pck2);
-	clk_register(&pck3);
+	for (i = 0; i < ARRAY_SIZE(prog_clock_names); i++) {
+		name = prog_clock_names[i];
+		clk = at91_clk_register_programmable(name,
+					prog_clock_parent_names,
+					ARRAY_SIZE(prog_clock_parent_names),
+					i, &at91rm9200_programmable_layout);
+	}
+
+	clk = at91rm9200_clk_register_usb("usbck", "pllb", usb_divisors);
+	for (i = 0; i < ARRAY_SIZE(usb_clk_lookup); i++)
+		usb_clk_lookup[i].clk = clk;
+	clkdev_add_table(usb_clk_lookup, ARRAY_SIZE(usb_clk_lookup));
+
+	for (i = 0; i < ARRAY_SIZE(system_clock_lookup_sizes); i++) {
+		size = system_clock_lookup_sizes[i];
+		lookup = system_clock_lookups[i];
+		if (!size || !lookup)
+			continue;
+		name = system_clock_lookups[i][0].con_id;
+		if (!name)
+			continue;
+		clk = at91_clk_register_system(name, i);
+		for (k = 0; k < size; k++)
+			lookup[k].clk = clk;
+		clkdev_add_table(lookup, size);
+	}
 }
 
 /* --------------------------------------------------------------------
-- 
1.7.9.5



From lars at metafoo.de  Wed Jul 17 10:47:14 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Wed, 17 Jul 2013 16:47:14 +0200
Subject: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <51E6A015.8040705@ti.com>
References: <1373613482-28390-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1373613482-28390-3-git-send-email-oleksandr.kozaruk@ti.com>,
 <51E05F6C.1060506@metafoo.de>
 <2A7ABDFCE21540479A5AEB0244A684D5E3D067@DNCE04.ent.ti.com>
 <51E3DE21.9060105@metafoo.de> <51E6A015.8040705@ti.com>
Message-ID: <51E6AE72.2060008@metafoo.de>

On 07/17/2013 03:45 PM, Oleksandr Kozaruk wrote:
> On Mon, Jul 15, 2013 at 01:33:53PM +0200, Lars-Peter Clausen wrote:
>> On 07/15/2013 01:09 PM, Kozaruk, Oleksandr wrote:
>> [...]
>> >
>> >>> +     ret = devm_request_threaded_irq(dev, irq, NULL,
>> >>> + twl6030_gpadc_irq_handler,
>> >>> + IRQF_ONESHOT, "twl6030_gpadc", gpadc);
>> >>
>> >> You access memory in the interrupt handler which is freed before the
> interrupt
>> >> handler is freed.
>> > Thanks for pointing this. devm_* will free memory for irq after the driver
>> > is removed and memory for the device is freed. I took me awhile to
> understand
>> > this. Is there going to be something like devm_iio_device_alloc? whould
> it be helpfull?
>> >
>>
>> Yes, I think it certainly makes sense to add a devm_iio_device_alloc(), care
>> to send a patch?
> 
> Anything like this? (of course it's not a patch)
> 

No. I think you can for example use devm_regulator_get() as a template. But
instead of regulator_get() and regulator_put() use iio_device_alloc() and
iio_device_free().

> struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv)
> {
>     struct iio_dev *indio_dev;
>     size_t alloc_size;
> 
>     alloc_size = sizeof(struct iio_dev);
>     if (sizeof_priv) {
>         alloc_size = ALIGN(alloc_size, IIO_ALIGN);
>         alloc_size += sizeof_priv;
>     }
>     /* ensure 32-byte alignment of whole construct ? */
>     alloc_size += IIO_ALIGN - 1;
> 
>     indio_dev = devm_kzalloc(dev, alloc_size, GFP_KERNEL);
>     if (indio_dev) {
>         indio_dev->dev.groups = indio_dev->groups;
>         indio_dev->dev.type = &iio_device_type;
>         indio_dev->dev.bus = &iio_bus_type;
>         device_initialize(&indio_dev->dev);
>         dev_set_drvdata(&indio_dev->dev, (void *)indio_dev);
>         mutex_init(&indio_dev->mlock);
>         mutex_init(&indio_dev->info_exist_lock);
>         INIT_LIST_HEAD(&indio_dev->channel_attr_list);
> 
>         indio_dev->id = ida_simple_get(&iio_ida, 0, 0, GFP_KERNEL);
>         if (indio_dev->id < 0) {
>             /* cannot use a dev_err as the name isn't available */
>             printk(KERN_ERR "Failed to get id\n");
>             kfree(dev);
>             return NULL;
>         }
>         dev_set_name(&indio_dev->dev, "iio:device%d", indio_dev->id);
>         INIT_LIST_HEAD(&indio_dev->buffer_list);
>     }
> 
>     return indio_dev;
> }
> EXPORT_SYMBOL(devm_iio_device_alloc);
> 
> Regards,
> OK



From lars at metafoo.de  Wed Jul 17 10:48:34 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Wed, 17 Jul 2013 16:48:34 +0200
Subject: [PATCH v5 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <51E6AB54.103@cogentembedded.com>
References: <1374059564-6872-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1374059564-6872-2-git-send-email-oleksandr.kozaruk@ti.com>
 <51E6AB54.103@cogentembedded.com>
Message-ID: <51E6AEC2.3050308@metafoo.de>

On 07/17/2013 04:33 PM, Sergei Shtylyov wrote:
> Hello.
> 
> On 17-07-2013 15:12, Oleksandr Kozaruk wrote:
> 
>> GPADC is the general purpose ADC present on twl6030.
>> The dt data is interrupt used to trigger end of ADC
>> conversion.
> 
>> Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
>> ---
>>   arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
>>   1 file changed, 6 insertions(+)
> 
>> diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
>> index 2e3bd31..322aa8e 100644
>> --- a/arch/arm/boot/dts/twl6030.dtsi
>> +++ b/arch/arm/boot/dts/twl6030.dtsi
>> @@ -103,4 +103,10 @@
>>           compatible = "ti,twl6030-pwmled";
>>           #pwm-cells = <2>;
>>       };
>> +
>> +    adc: twl6030_gpadc {
> 
>    I was talking about the device name, not label. The "twl6030_gpadc" part.

The compatible property should also be: 'twl6030-gpadc' instead of
'twl6030_gpadc' and you need to add documentation for it.

- Lars


From b.brezillon at overkiz.com  Wed Jul 17 10:49:08 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 16:49:08 +0200
Subject: [PATCH v2 17/42] ARM: at91: move at91sam9g45 SoC to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374072548-19702-1-git-send-email-b.brezillon@overkiz.com>

This patch removes all references to the old at91 clks implementation and
make use of the new at91 clk implem for at91sam9g45 SoC.

All dt specific lookups are removed (handled in clk device tree binding).

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/at91sam9g45.c         |  702 ++++++++++++++++++------------
 arch/arm/mach-at91/at91sam9g45_devices.c |    1 -
 2 files changed, 424 insertions(+), 279 deletions(-)

diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index 29ba2ca..a24915a 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -24,7 +24,6 @@
 #include "at91_aic.h"
 #include "soc.h"
 #include "generic.h"
-#include "clock.h"
 #include "sam9_smc.h"
 
 /* --------------------------------------------------------------------
@@ -34,299 +33,446 @@
 /*
  * The peripheral clocks.
  */
-static struct clk pioA_clk = {
-	.name		= "pioA_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_PIOA,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioB_clk = {
-	.name		= "pioB_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_PIOB,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioC_clk = {
-	.name		= "pioC_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_PIOC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioDE_clk = {
-	.name		= "pioDE_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_PIODE,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk trng_clk = {
-	.name		= "trng_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_TRNG,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
-	.name		= "usart0_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_US0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
-	.name		= "usart1_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_US1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
-	.name		= "usart2_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_US2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart3_clk = {
-	.name		= "usart3_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_US3,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc0_clk = {
-	.name		= "mci0_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_MCI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi0_clk = {
-	.name		= "twi0_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_TWI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi1_clk = {
-	.name		= "twi1_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_TWI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi0_clk = {
-	.name		= "spi0_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_SPI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi1_clk = {
-	.name		= "spi1_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_SPI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc0_clk = {
-	.name		= "ssc0_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_SSC0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc1_clk = {
-	.name		= "ssc1_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_SSC1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tcb0_clk = {
-	.name		= "tcb0_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_TCB,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pwm_clk = {
-	.name		= "pwm_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_PWMC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tsc_clk = {
-	.name		= "tsc_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_TSC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk dma_clk = {
-	.name		= "dma_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_DMA,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk uhphs_clk = {
-	.name		= "uhphs_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_UHPHS,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk lcdc_clk = {
-	.name		= "lcdc_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_LCDC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ac97_clk = {
-	.name		= "ac97_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_AC97C,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk macb_clk = {
-	.name		= "pclk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_EMAC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk isi_clk = {
-	.name		= "isi_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_ISI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk udphs_clk = {
-	.name		= "udphs_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_UDPHS,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc1_clk = {
-	.name		= "mci1_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_MCI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-
-/* Video decoder clock - Only for sam9m10/sam9m11 */
-static struct clk vdec_clk = {
-	.name		= "vdec_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_VDEC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-
-static struct clk adc_op_clk = {
-	.name		= "adc_op_clk",
-	.type		= CLK_TYPE_PERIPHERAL,
-	.rate_hz	= 13200000,
-};
-
-/* AES/TDES/SHA clock - Only for sam9m11/sam9g56 */
-static struct clk aestdessha_clk = {
-	.name		= "aestdessha_clk",
-	.pmc_mask	= 1 << AT91SAM9G45_ID_AESTDESSHA,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-
-static struct clk *periph_clocks[] __initdata = {
-	&pioA_clk,
-	&pioB_clk,
-	&pioC_clk,
-	&pioDE_clk,
-	&trng_clk,
-	&usart0_clk,
-	&usart1_clk,
-	&usart2_clk,
-	&usart3_clk,
-	&mmc0_clk,
-	&twi0_clk,
-	&twi1_clk,
-	&spi0_clk,
-	&spi1_clk,
-	&ssc0_clk,
-	&ssc1_clk,
-	&tcb0_clk,
-	&pwm_clk,
-	&tsc_clk,
-	&dma_clk,
-	&uhphs_clk,
-	&lcdc_clk,
-	&ac97_clk,
-	&macb_clk,
-	&isi_clk,
-	&udphs_clk,
-	&mmc1_clk,
-	&adc_op_clk,
-	&aestdessha_clk,
-	// irq0
-};
-
-static struct clk_lookup periph_clocks_lookups[] = {
-	/* One additional fake clock for macb_hclk */
-	CLKDEV_CON_ID("hclk", &macb_clk),
-	/* One additional fake clock for ohci */
-	CLKDEV_CON_ID("ohci_clk", &uhphs_clk),
-	CLKDEV_CON_DEV_ID("hclk", "at91sam9g45-lcdfb.0", &lcdc_clk),
-	CLKDEV_CON_DEV_ID("hclk", "at91sam9g45es-lcdfb.0", &lcdc_clk),
-	CLKDEV_CON_DEV_ID("ehci_clk", "atmel-ehci", &uhphs_clk),
-	CLKDEV_CON_DEV_ID("hclk", "atmel_usba_udc", &utmi_clk),
-	CLKDEV_CON_DEV_ID("pclk", "atmel_usba_udc", &udphs_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.0", &mmc0_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.1", &mmc1_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.1", &spi1_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tcb0_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tcb0_clk),
-	CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.0", &twi0_clk),
-	CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.1", &twi1_clk),
-	CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", &ssc0_clk),
-	CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.1", &ssc1_clk),
-	CLKDEV_CON_DEV_ID("pclk", "fff9c000.ssc", &ssc0_clk),
-	CLKDEV_CON_DEV_ID("pclk", "fffa0000.ssc", &ssc1_clk),
-	CLKDEV_CON_DEV_ID(NULL, "atmel-trng", &trng_clk),
-	CLKDEV_CON_DEV_ID(NULL, "atmel_sha", &aestdessha_clk),
-	CLKDEV_CON_DEV_ID(NULL, "atmel_tdes", &aestdessha_clk),
-	CLKDEV_CON_DEV_ID(NULL, "atmel_aes", &aestdessha_clk),
-	/* more usart lookup table for DT entries */
-	CLKDEV_CON_DEV_ID("usart", "ffffee00.serial", &mck),
-	CLKDEV_CON_DEV_ID("usart", "fff8c000.serial", &usart0_clk),
-	CLKDEV_CON_DEV_ID("usart", "fff90000.serial", &usart1_clk),
-	CLKDEV_CON_DEV_ID("usart", "fff94000.serial", &usart2_clk),
-	CLKDEV_CON_DEV_ID("usart", "fff98000.serial", &usart3_clk),
-	/* more tc lookup table for DT entries */
-	CLKDEV_CON_DEV_ID("t0_clk", "fff7c000.timer", &tcb0_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "fffd4000.timer", &tcb0_clk),
-	CLKDEV_CON_DEV_ID("hclk", "700000.ohci", &uhphs_clk),
-	CLKDEV_CON_DEV_ID("ehci_clk", "800000.ehci", &uhphs_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "fff80000.mmc", &mmc0_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "fffd0000.mmc", &mmc1_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fff84000.i2c", &twi0_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fff88000.i2c", &twi1_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "fffa4000.spi", &spi0_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "fffa8000.spi", &spi1_clk),
-	CLKDEV_CON_DEV_ID("hclk", "600000.gadget", &utmi_clk),
-	CLKDEV_CON_DEV_ID("pclk", "600000.gadget", &udphs_clk),
-	/* fake hclk clock */
-	CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &uhphs_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff200.gpio", &pioA_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff400.gpio", &pioB_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff600.gpio", &pioC_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff800.gpio", &pioDE_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffffa00.gpio", &pioDE_clk),
-
-	CLKDEV_CON_ID("pioA", &pioA_clk),
-	CLKDEV_CON_ID("pioB", &pioB_clk),
-	CLKDEV_CON_ID("pioC", &pioC_clk),
-	CLKDEV_CON_ID("pioD", &pioDE_clk),
-	CLKDEV_CON_ID("pioE", &pioDE_clk),
-	/* Fake adc clock */
-	CLKDEV_CON_ID("adc_clk", &tsc_clk),
-};
-
-static struct clk_lookup usart_clocks_lookups[] = {
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.0", &mck),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.1", &usart0_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.2", &usart1_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.3", &usart2_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.4", &usart3_clk),
+static struct clk_lookup pioA_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioA_clk", NULL),
+	CLKDEV_INIT(NULL, "pioA", NULL),
+};
+
+static struct clk_lookup pioB_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioB_clk", NULL),
+	CLKDEV_INIT(NULL, "pioB", NULL),
+};
+
+static struct clk_lookup pioC_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioC_clk", NULL),
+	CLKDEV_INIT(NULL, "pioC", NULL),
+};
+
+static struct clk_lookup pioDE_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioDE_clk", NULL),
+	CLKDEV_INIT(NULL, "pioD", NULL),
+	CLKDEV_INIT(NULL, "pioE", NULL),
+};
+
+static struct clk_lookup trng_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "trng_clk", NULL),
+	CLKDEV_INIT("atmel-trng", NULL, NULL),
+};
+
+static struct clk_lookup usart0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart0_clk", NULL),
+	CLKDEV_INIT("atmel_usart.1", "usart", NULL),
+};
+
+static struct clk_lookup usart1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart1_clk", NULL),
+	CLKDEV_INIT("atmel_usart.2", "usart", NULL),
+};
+
+static struct clk_lookup usart2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart2_clk", NULL),
+	CLKDEV_INIT("atmel_usart.3", "usart", NULL),
+};
+
+static struct clk_lookup usart3_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart3_clk", NULL),
+	CLKDEV_INIT("atmel_usart.4", "usart", NULL),
+};
+
+static struct clk_lookup mci0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "mci0_clk", NULL),
+	CLKDEV_INIT("atmel_mci.0", "mci_clk", NULL),
+};
+
+static struct clk_lookup twi0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "twi0_clk", NULL),
+	CLKDEV_INIT("i2c-at91sam9g10.0", NULL, NULL),
+};
+
+static struct clk_lookup twi1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "twi1_clk", NULL),
+	CLKDEV_INIT("i2c-at91sam9g10.1", NULL, NULL),
+};
+
+static struct clk_lookup spi0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "spi0_clk", NULL),
+	CLKDEV_INIT("atmel_spi.0", "spi_clk", NULL),
+};
+
+static struct clk_lookup spi1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "spi0_clk", NULL),
+	CLKDEV_INIT("atmel_spi.1", "spi_clk", NULL),
+};
+
+static struct clk_lookup ssc0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ssc0_clk", NULL),
+	CLKDEV_INIT("at91sam9g45_ssc.0", "pclk", NULL),
+};
+
+static struct clk_lookup ssc1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ssc1_clk", NULL),
+	CLKDEV_INIT("at91sam9g45_ssc.0", "pclk", NULL),
+};
+
+static struct clk_lookup tcb0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tcb0_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.0", "t0_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.1", "t0_clk", NULL),
+};
+
+static struct clk_lookup pwm_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pwm_clk", NULL),
+};
+
+static struct clk_lookup tsc_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tsc_clk", NULL),
+	CLKDEV_INIT("adc_clk", NULL, NULL),
+};
+
+static struct clk_lookup dma_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "dma_clk", NULL),
+};
+
+static struct clk_lookup uhphs_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "uhphs_clk", NULL),
+	CLKDEV_INIT(NULL, "ohci_clk", NULL),
+	CLKDEV_INIT("atmel-ehci", "ehci_clk", NULL),
+	CLKDEV_INIT("at91_ohci", "hclk", NULL),
+};
+
+static struct clk_lookup lcdc_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "lcdc_clk", NULL),
+	CLKDEV_INIT("hclk", "at91sam9g45-lcdfb.0", NULL),
+	CLKDEV_INIT("hclk", "at91sam9g45es-lcdfb.0", NULL),
+};
+
+static struct clk_lookup ac97_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ac97_clk", NULL),
+};
+
+static struct clk_lookup macb_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pclk", NULL),
+	CLKDEV_INIT(NULL, "hclk", NULL),
+};
+
+static struct clk_lookup isi_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "isi_clk", NULL),
+};
+
+static struct clk_lookup udphs_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "udphs_clk", NULL),
+	CLKDEV_INIT("atmel_usba_udc", "pclk", NULL),
+};
+
+static struct clk_lookup aestdessha_clk_lookup[] = {
+	CLKDEV_INIT("atmel_sha", NULL, NULL),
+	CLKDEV_INIT("atmel_tdes", NULL, NULL),
+	CLKDEV_INIT("atmel_aes", NULL, NULL),
+};
+
+static struct clk_lookup mci1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "mci1_clk", NULL),
+	CLKDEV_INIT("atmel_mci.1", "mci_clk", NULL),
+};
+
+static struct clk_lookup vdec_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "vdec_clk", NULL),
+};
+
+static size_t periph_clock_lookup_sizes[] __initdata = {
+	0,
+	0,
+	ARRAY_SIZE(pioA_clk_lookup),
+	ARRAY_SIZE(pioB_clk_lookup),
+	ARRAY_SIZE(pioC_clk_lookup),
+	ARRAY_SIZE(pioDE_clk_lookup),
+	ARRAY_SIZE(trng_clk_lookup),
+	ARRAY_SIZE(usart0_clk_lookup),
+	ARRAY_SIZE(usart1_clk_lookup),
+	ARRAY_SIZE(usart2_clk_lookup),
+	ARRAY_SIZE(usart3_clk_lookup),
+	ARRAY_SIZE(mci0_clk_lookup),
+	ARRAY_SIZE(twi0_clk_lookup),
+	ARRAY_SIZE(twi1_clk_lookup),
+	ARRAY_SIZE(spi0_clk_lookup),
+	ARRAY_SIZE(spi1_clk_lookup),
+	ARRAY_SIZE(ssc0_clk_lookup),
+	ARRAY_SIZE(ssc1_clk_lookup),
+	ARRAY_SIZE(tcb0_clk_lookup),
+	ARRAY_SIZE(pwm_clk_lookup),
+	ARRAY_SIZE(tsc_clk_lookup),
+	ARRAY_SIZE(dma_clk_lookup),
+	ARRAY_SIZE(uhphs_clk_lookup),
+	ARRAY_SIZE(lcdc_clk_lookup),
+	ARRAY_SIZE(ac97_clk_lookup),
+	ARRAY_SIZE(macb_clk_lookup),
+	ARRAY_SIZE(isi_clk_lookup),
+	ARRAY_SIZE(udphs_clk_lookup),
+	0,
+	ARRAY_SIZE(mci1_clk_lookup),
+};
+
+static struct clk_lookup *periph_clock_lookups[] __initdata = {
+	NULL,
+	NULL,
+	pioA_clk_lookup,
+	pioB_clk_lookup,
+	pioC_clk_lookup,
+	pioDE_clk_lookup,
+	trng_clk_lookup,
+	usart0_clk_lookup,
+	usart1_clk_lookup,
+	usart2_clk_lookup,
+	usart3_clk_lookup,
+	mci0_clk_lookup,
+	twi0_clk_lookup,
+	twi1_clk_lookup,
+	spi0_clk_lookup,
+	spi1_clk_lookup,
+	ssc0_clk_lookup,
+	ssc1_clk_lookup,
+	tcb0_clk_lookup,
+	pwm_clk_lookup,
+	tsc_clk_lookup,
+	dma_clk_lookup,
+	uhphs_clk_lookup,
+	lcdc_clk_lookup,
+	ac97_clk_lookup,
+	macb_clk_lookup,
+	isi_clk_lookup,
+	udphs_clk_lookup,
+	NULL,
+	mci1_clk_lookup,
+};
+
+
+/*
+ * The system clocks.
+ */
+static struct clk_lookup ddr_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ddrck", NULL),
+};
+
+static struct clk_lookup uhp_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "uhpck", NULL),
+};
+
+static struct clk_lookup pck0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck0", NULL),
+};
+
+static struct clk_lookup pck1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck1", NULL),
+};
+
+static size_t system_clock_lookup_sizes[] __initdata = {
+	0,
+	0,
+	ARRAY_SIZE(ddr_clk_lookup),
+	0,
+	0,
+	0,
+	ARRAY_SIZE(uhp_clk_lookup),
+	0,
+	ARRAY_SIZE(pck0_clk_lookup),
+	ARRAY_SIZE(pck1_clk_lookup),
+};
+
+static struct clk_lookup *system_clock_lookups[] __initdata = {
+	NULL,
+	NULL,
+	ddr_clk_lookup,
+	NULL,
+	NULL,
+	NULL,
+	uhp_clk_lookup,
+	NULL,
+	pck0_clk_lookup,
+	pck1_clk_lookup,
 };
 
 /*
  * The two programmable clocks.
  * You must configure pin multiplexing to bring these signals out.
  */
-static struct clk pck0 = {
-	.name		= "pck0",
-	.pmc_mask	= AT91_PMC_PCK0,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 0,
+static const char *prog_clock_parent_names[] __initdata = {
+	"clk32k",
+	"main",
+	"plladiv",
+	"utmi_clk",
+	"mck",
 };
-static struct clk pck1 = {
-	.name		= "pck1",
-	.pmc_mask	= AT91_PMC_PCK1,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 1,
+
+static const char *prog_clock_names[] __initdata = {
+	"prog0",
+	"prog1",
+};
+
+/*
+ * The pll clocks.
+ */
+static struct clk_lookup pll_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "plla", NULL),
+};
+
+static struct clk_range at91sam9g45_plla_output[] = {
+	CLK_RANGE(745000000, 800000000),
+	CLK_RANGE(695000000, 750000000),
+	CLK_RANGE(645000000, 700000000),
+	CLK_RANGE(595000000, 650000000),
+	CLK_RANGE(545000000, 600000000),
+	CLK_RANGE(495000000, 550000000),
+	CLK_RANGE(445000000, 500000000),
+	CLK_RANGE(400000000, 450000000),
+};
+static u8 at91sam9g45_plla_out[] = {0, 1, 2, 3, 0, 1, 2, 3};
+static u16 at91sam9g45_plla_icpll[] = {0, 0, 0, 0, 1, 1, 1, 1};
+
+struct clk_pll_characteristics at91sam9g45_plla_characteristics = {
+	.input = CLK_RANGE(2000000, 32000000),
+	.num_output = ARRAY_SIZE(at91sam9g45_plla_output),
+	.output = at91sam9g45_plla_output,
+	.out = at91sam9g45_plla_out,
+	.icpll = at91sam9g45_plla_icpll,
+};
+
+
+/*
+ * The master clock.
+ */
+static struct clk_lookup mck_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "mck", NULL),
+	CLKDEV_INIT("atmel_usart.0", "usart", NULL),
+};
+
+struct clk_master_characteristics at91sam9g45_master_characteristics = {
+	.output = CLK_RANGE(0, 133000000),
+	.have_div3_pres = 0,
+	.divisors = {1, 2, 4, 3},
+};
+
+static const char *master_clock_parent_names[] __initdata = {
+	"clk32k",
+	"main",
+	"plladiv",
+	"utmi_clk",
+};
+
+/*
+ * UTMI clock.
+ */
+static struct clk_lookup utmi_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "utmi_clk", NULL),
+	CLKDEV_INIT("atmel_usba_udc", "hclk", NULL),
+};
+
+/*
+ * USB clock.
+ */
+static const char *usb_clock_parent_names[] __initdata = {
+	"plladiv",
+	"utmi_clk",
+};
+
+static struct clk_lookup usb_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usb_clk", NULL),
 };
 
 static void __init at91sam9g45_register_clocks(void)
 {
 	int i;
+	int k;
+	size_t size;
+	struct clk *clk;
+	const char *name;
+	struct clk_lookup *lookup;
+
+	clk = at91_clk_register_pll("plla", "main", 0,
+				    &at91sam9g45_pll_layout,
+				    &at91sam9g45_plla_characteristics);
+	for (i = 0; i < ARRAY_SIZE(pll_clk_lookup); i++)
+		pll_clk_lookup[i].clk = clk;
+	clkdev_add_table(pll_clk_lookup, ARRAY_SIZE(pll_clk_lookup));
+	clk = at91_clk_register_plldiv("plladiv", "plla");
 
-	for (i = 0; i < ARRAY_SIZE(periph_clocks); i++)
-		clk_register(periph_clocks[i]);
+	clk = at91_clk_register_utmi("utmi_clk", "main");
+	for (i = 0; i < ARRAY_SIZE(utmi_clk_lookup); i++)
+		utmi_clk_lookup[i].clk = clk;
+	clkdev_add_table(utmi_clk_lookup, ARRAY_SIZE(utmi_clk_lookup));
 
-	clkdev_add_table(periph_clocks_lookups,
-			 ARRAY_SIZE(periph_clocks_lookups));
-	clkdev_add_table(usart_clocks_lookups,
-			 ARRAY_SIZE(usart_clocks_lookups));
+	clk = at91_clk_register_master("mck",
+				       ARRAY_SIZE(master_clock_parent_names),
+				       master_clock_parent_names,
+				       &at91rm9200_master_layout,
+				       &at91sam9g45_master_characteristics);
+	for (i = 0; i < ARRAY_SIZE(mck_clk_lookup); i++)
+		mck_clk_lookup[i].clk = clk;
+	clkdev_add_table(mck_clk_lookup, ARRAY_SIZE(mck_clk_lookup));
 
-	if (cpu_is_at91sam9m10() || cpu_is_at91sam9m11())
-		clk_register(&vdec_clk);
+	for (i = 0; i < ARRAY_SIZE(periph_clock_lookup_sizes); i++) {
+		size = periph_clock_lookup_sizes[i];
+		lookup = periph_clock_lookups[i];
+		if (!size || !lookup)
+			continue;
+		name = periph_clock_lookups[i][0].con_id;
+		if (!name)
+			continue;
+		clk = at91_clk_register_peripheral(name, "mck", i);
+
+		for (k = 0; k < size; k++)
+			lookup[k].clk = clk;
+		clkdev_add_table(lookup, size);
+	}
+
+	if (cpu_is_at91sam9m10() || cpu_is_at91sam9m11()) {
+		clk = at91_clk_register_peripheral(vdec_clk_lookup[0].con_id,
+						   "mck",
+						   AT91SAM9G45_ID_VDEC);
+		for (k = 0; k < ARRAY_SIZE(vdec_clk_lookup); k++)
+			vdec_clk_lookup[k].clk = clk;
+		clkdev_add_table(vdec_clk_lookup, ARRAY_SIZE(vdec_clk_lookup));
+	}
+
+	if (cpu_is_at91sam9m11() || cpu_is_at91sam9g46()) {
+		clk = at91_clk_register_peripheral(vdec_clk_lookup[0].con_id,
+						   "mck",
+						   AT91SAM9G45_ID_AESTDESSHA);
+		for (k = 0; k < ARRAY_SIZE(aestdessha_clk_lookup); k++)
+			aestdessha_clk_lookup[k].clk = clk;
+		clkdev_add_table(vdec_clk_lookup,
+				 ARRAY_SIZE(aestdessha_clk_lookup));
+	}
+
+	for (i = 0; i < ARRAY_SIZE(prog_clock_names); i++) {
+		name = prog_clock_names[i];
+		clk = at91_clk_register_programmable(name,
+					prog_clock_parent_names,
+					ARRAY_SIZE(prog_clock_parent_names),
+					i, &at91sam9g45_programmable_layout);
+	}
+
+	clk = at91sam9x5_clk_register_usb("usbck", usb_clock_parent_names,
+					  ARRAY_SIZE(usb_clock_parent_names),
+					  0);
+	for (i = 0; i < ARRAY_SIZE(usb_clk_lookup); i++)
+		usb_clk_lookup[i].clk = clk;
+	clkdev_add_table(usb_clk_lookup, ARRAY_SIZE(usb_clk_lookup));
+
+	for (i = 0; i < ARRAY_SIZE(system_clock_lookup_sizes); i++) {
+		size = system_clock_lookup_sizes[i];
+		lookup = system_clock_lookups[i];
+		if (!size || !lookup)
+			continue;
+		name = system_clock_lookups[i][0].con_id;
+		if (!name)
+			continue;
+		clk = at91_clk_register_system(name, i);
+		for (k = 0; k < size; k++)
+			lookup[k].clk = clk;
+		clkdev_add_table(lookup, size);
+	}
 
-	clk_register(&pck0);
-	clk_register(&pck1);
+	clk_register_fixed_rate(NULL, "adc_op_clk", "mck", 0, 13200000);
 }
 
 /* --------------------------------------------------------------------
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index cb36fa8..13c650c 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -37,7 +37,6 @@
 
 #include "board.h"
 #include "generic.h"
-#include "clock.h"
 
 
 /* --------------------------------------------------------------------
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 10:49:53 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 16:49:53 +0200
Subject: [PATCH v2 18/42] ARM: at91: move at91sam9n12 SoC to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374072593-19740-1-git-send-email-b.brezillon@overkiz.com>

This patch removes all references to the old at91 clks for at91sam9n12 SoC.
This SoC only supports dt boards: we can remove register_clocks
(all clocks are defined in dt).

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/at91sam9n12.c |  194 --------------------------------------
 1 file changed, 194 deletions(-)

diff --git a/arch/arm/mach-at91/at91sam9n12.c b/arch/arm/mach-at91/at91sam9n12.c
index c270503..e4863fc 100644
--- a/arch/arm/mach-at91/at91sam9n12.c
+++ b/arch/arm/mach-at91/at91sam9n12.c
@@ -19,202 +19,9 @@
 #include "board.h"
 #include "soc.h"
 #include "generic.h"
-#include "clock.h"
 #include "sam9_smc.h"
 
 /* --------------------------------------------------------------------
- *  Clocks
- * -------------------------------------------------------------------- */
-
-/*
- * The peripheral clocks.
- */
-static struct clk pioAB_clk = {
-	.name		= "pioAB_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_PIOAB,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioCD_clk = {
-	.name		= "pioCD_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_PIOCD,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
-	.name		= "usart0_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_USART0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
-	.name		= "usart1_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_USART1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
-	.name		= "usart2_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_USART2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart3_clk = {
-	.name		= "usart3_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_USART3,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi0_clk = {
-	.name		= "twi0_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_TWI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi1_clk = {
-	.name		= "twi1_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_TWI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc_clk = {
-	.name		= "mci_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_MCI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi0_clk = {
-	.name		= "spi0_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_SPI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi1_clk = {
-	.name		= "spi1_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_SPI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk uart0_clk = {
-	.name		= "uart0_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_UART0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk uart1_clk = {
-	.name		= "uart1_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_UART1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tcb_clk = {
-	.name		= "tcb_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_TCB,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pwm_clk = {
-	.name		= "pwm_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_PWM,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk adc_clk = {
-	.name		= "adc_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_ADC,
-	.type	= CLK_TYPE_PERIPHERAL,
-};
-static struct clk dma_clk = {
-	.name		= "dma_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_DMA,
-	.type	= CLK_TYPE_PERIPHERAL,
-};
-static struct clk uhp_clk = {
-	.name		= "uhp",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_UHP,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk udp_clk = {
-	.name		= "udp_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_UDP,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk lcdc_clk = {
-	.name		= "lcdc_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_LCDC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc_clk = {
-	.name		= "ssc_clk",
-	.pmc_mask	= 1 << AT91SAM9N12_ID_SSC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-
-static struct clk *periph_clocks[] __initdata = {
-	&pioAB_clk,
-	&pioCD_clk,
-	&usart0_clk,
-	&usart1_clk,
-	&usart2_clk,
-	&usart3_clk,
-	&twi0_clk,
-	&twi1_clk,
-	&mmc_clk,
-	&spi0_clk,
-	&spi1_clk,
-	&lcdc_clk,
-	&uart0_clk,
-	&uart1_clk,
-	&tcb_clk,
-	&pwm_clk,
-	&adc_clk,
-	&dma_clk,
-	&uhp_clk,
-	&udp_clk,
-	&ssc_clk,
-};
-
-static struct clk_lookup periph_clocks_lookups[] = {
-	/* lookup table for DT entries */
-	CLKDEV_CON_DEV_ID("usart", "fffff200.serial", &mck),
-	CLKDEV_CON_DEV_ID("usart", "f801c000.serial", &usart0_clk),
-	CLKDEV_CON_DEV_ID("usart", "f8020000.serial", &usart1_clk),
-	CLKDEV_CON_DEV_ID("usart", "f8024000.serial", &usart2_clk),
-	CLKDEV_CON_DEV_ID("usart", "f8028000.serial", &usart3_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "f8008000.timer", &tcb_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "f800c000.timer", &tcb_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "f0008000.mmc", &mmc_clk),
-	CLKDEV_CON_DEV_ID("dma_clk", "ffffec00.dma-controller", &dma_clk),
-	CLKDEV_CON_DEV_ID(NULL, "f8010000.i2c", &twi0_clk),
-	CLKDEV_CON_DEV_ID(NULL, "f8014000.i2c", &twi1_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "f0000000.spi", &spi0_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "f0004000.spi", &spi1_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff400.gpio", &pioAB_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff600.gpio", &pioAB_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff800.gpio", &pioCD_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffffa00.gpio", &pioCD_clk),
-	/* additional fake clock for macb_hclk */
-	CLKDEV_CON_DEV_ID("hclk", "500000.ohci", &uhp_clk),
-	CLKDEV_CON_DEV_ID("ohci_clk", "500000.ohci", &uhp_clk),
-};
-
-/*
- * The two programmable clocks.
- * You must configure pin multiplexing to bring these signals out.
- */
-static struct clk pck0 = {
-	.name		= "pck0",
-	.pmc_mask	= AT91_PMC_PCK0,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 0,
-};
-static struct clk pck1 = {
-	.name		= "pck1",
-	.pmc_mask	= AT91_PMC_PCK1,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 1,
-};
-
-static void __init at91sam9n12_register_clocks(void)
-{
-	int i;
-
-	for (i = 0; i < ARRAY_SIZE(periph_clocks); i++)
-		clk_register(periph_clocks[i]);
-	clk_register(&pck0);
-	clk_register(&pck1);
-
-	clkdev_add_table(periph_clocks_lookups,
-			 ARRAY_SIZE(periph_clocks_lookups));
-
-}
-
-/* --------------------------------------------------------------------
  *  AT91SAM9N12 processor initialization
  * -------------------------------------------------------------------- */
 
@@ -225,5 +32,4 @@ static void __init at91sam9n12_map_io(void)
 
 AT91_SOC_START(at91sam9n12)
 	.map_io = at91sam9n12_map_io,
-	.register_clocks = at91sam9n12_register_clocks,
 AT91_SOC_END
-- 
1.7.9.5



From robherring2 at gmail.com  Wed Jul 17 10:50:49 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 17 Jul 2013 09:50:49 -0500
Subject: [RFC PATCH v2 01/15] of: add support for retrieving cpu node
 for a given logical cpu index
In-Reply-To: <1374069984-20567-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374069984-20567-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <51E6AF49.20403@gmail.com>

On 07/17/2013 09:06 AM, Sudeep.KarkadaNagesha at arm.com wrote:
> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> Currently different drivers requiring to access cpu device node are
> parsing the device tree themselves. Since the ordering in the DT need
> not match the logical cpu ordering, the parsing logic needs to consider
> that. However, this has resulted in lots of code duplication and in some
> cases even incorrect logic.
> 
> It's better to consolidate them by adding support for getting cpu
> device node for a given logical cpu index in DT core library. However
> logical to physical index mapping can be architecture specific.
> 
> This patch adds of_get_cpu_node to retrieve a cpu device node for a
> given logical cpu index. The default matching of the physical id to the
> logical cpu index can be overridden by architecture specific code.
> 
> It is recommended to use these helper function only in pre-SMP/early
> initialisation stages to retrieve CPU device node pointers in logical
> ordering. Once the cpu devices are registered, it can be retrieved easily
> from cpu device of_node which avoids unnecessary parsing and matching.
> 
> Cc: Rob Herring <rob.herring at calxeda.com>
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

One comment below, but otherwise for patches 1-4, 8 and 9:

Acked-by: Rob Herring <rob.herring at calxeda.com>

Also, patch 3 needs to come before patch 2 or the matching will be wrong
if patch 3 is not applied.

> ---
>  drivers/of/base.c  | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of.h |  5 +++++
>  2 files changed, 71 insertions(+)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 5c54279..363b8f9 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -230,6 +230,72 @@ const void *of_get_property(const struct device_node *np, const char *name,
>  }
>  EXPORT_SYMBOL(of_get_property);
>  
> +/*
> + * arch_match_cpu_phys_id - Match the given logical CPU and physical id
> + *
> + * @cpu: logical index of a cpu
> + * @phys_id: physical identifier of a cpu
> + *
> + * CPU logical to physical index mapping is architecure specific.
> + * However this __weak function provides a default match of physical
> + * id to logical cpu index.
> + *
> + * Returns 1 if the physical identifier and the logical index correspond
> + * to the same cpu, 0 otherwise.
> + */
> +int __weak arch_match_cpu_phys_id(int cpu, u64 phys_id)
> +{
> +	return (u32)phys_id == cpu;
> +}
> +
> +/**
> + * of_get_cpu_node - Get device node associated with the given logical CPU
> + *
> + * @cpu: CPU number(logical index) for which device node is required
> + *
> + * The main purpose of this function is to retrieve the device node for the
> + * given logical CPU index. It should be used to intialise the of_node in
> + * cpu device. Once of_node in cpu device is populated, all the further
> + * references can use that instead.
> + *
> + * CPU logical to physical index mapping is architecure specific and is built
> + * before booting secondary cores. This function uses arch_match_cpu_phys_id
> + * which can be overridden by architecture specific implementation.
> + *
> + * Returns a node pointer for the logical cpu if found, else NULL.
> + */
> +struct device_node *of_get_cpu_node(int cpu)
> +{
> +	struct device_node *cpun, *cpus;
> +	const u32 *cell;
> +	u64 hwid;
> +	int ac, prop_len;
> +
> +	cpus = of_find_node_by_path("/cpus");
> +	if (WARN(!cpus, "Missing cpus node, bailing out\n"))

What happens on a system with no /cpus nodes? Seems like this is another
case of adding new warnings to existing working systems.

I'd replace all the WARN's with a single pr_warn on any errors below.
For missing /cpus, I would just silently return.

Rob

> +		return NULL;
> +
> +	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
> +		ac = of_n_addr_cells(cpus);
> +
> +	for_each_child_of_node(cpus, cpun) {
> +		if (of_node_cmp(cpun->type, "cpu"))
> +			continue;
> +		cell = of_get_property(cpun, "reg", &prop_len);
> +		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
> +			continue;
> +
> +		while (prop_len) {
> +			hwid = of_read_number(cell, ac);
> +			prop_len -= ac;
> +			if (arch_match_cpu_phys_id(cpu, hwid))
> +				return cpun;
> +		}
> +	}
> +
> +	return NULL;
> +}



From b.brezillon at overkiz.com  Wed Jul 17 10:52:57 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 16:52:57 +0200
Subject: [PATCH v2 19/42] ARM: at91: move at91sam9rl SoC to new at91 clk implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374072777-19818-1-git-send-email-b.brezillon@overkiz.com>

This patch removes all references to the old at91 clks implementation and
make use of the new at91 clk implem for at91sam9rl SoC.

All dt specific lookups are removed (handled in clk device tree binding).

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/at91sam9rl.c |  500 ++++++++++++++++++++++++---------------
 1 file changed, 311 insertions(+), 189 deletions(-)

diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c
index 2694bd1..57ef54b 100644
--- a/arch/arm/mach-at91/at91sam9rl.c
+++ b/arch/arm/mach-at91/at91sam9rl.c
@@ -25,7 +25,6 @@
 #include "at91_rstc.h"
 #include "soc.h"
 #include "generic.h"
-#include "clock.h"
 #include "sam9_smc.h"
 
 /* --------------------------------------------------------------------
@@ -35,207 +34,330 @@
 /*
  * The peripheral clocks.
  */
-static struct clk pioA_clk = {
-	.name		= "pioA_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_PIOA,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioB_clk = {
-	.name		= "pioB_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_PIOB,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioC_clk = {
-	.name		= "pioC_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_PIOC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioD_clk = {
-	.name		= "pioD_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_PIOD,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
-	.name		= "usart0_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_US0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
-	.name		= "usart1_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_US1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
-	.name		= "usart2_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_US2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart3_clk = {
-	.name		= "usart3_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_US3,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc_clk = {
-	.name		= "mci_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_MCI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi0_clk = {
-	.name		= "twi0_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_TWI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi1_clk = {
-	.name		= "twi1_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_TWI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi_clk = {
-	.name		= "spi_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_SPI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc0_clk = {
-	.name		= "ssc0_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_SSC0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc1_clk = {
-	.name		= "ssc1_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_SSC1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc0_clk = {
-	.name		= "tc0_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_TC0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc1_clk = {
-	.name		= "tc1_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_TC1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tc2_clk = {
-	.name		= "tc2_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_TC2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pwm_clk = {
-	.name		= "pwm_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_PWMC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tsc_clk = {
-	.name		= "tsc_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_TSC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk dma_clk = {
-	.name		= "dma_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_DMA,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk udphs_clk = {
-	.name		= "udphs_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_UDPHS,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk lcdc_clk = {
-	.name		= "lcdc_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_LCDC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ac97_clk = {
-	.name		= "ac97_clk",
-	.pmc_mask	= 1 << AT91SAM9RL_ID_AC97C,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-
-static struct clk *periph_clocks[] __initdata = {
-	&pioA_clk,
-	&pioB_clk,
-	&pioC_clk,
-	&pioD_clk,
-	&usart0_clk,
-	&usart1_clk,
-	&usart2_clk,
-	&usart3_clk,
-	&mmc_clk,
-	&twi0_clk,
-	&twi1_clk,
-	&spi_clk,
-	&ssc0_clk,
-	&ssc1_clk,
-	&tc0_clk,
-	&tc1_clk,
-	&tc2_clk,
-	&pwm_clk,
-	&tsc_clk,
-	&dma_clk,
-	&udphs_clk,
-	&lcdc_clk,
-	&ac97_clk,
-	// irq0
-};
-
-static struct clk_lookup periph_clocks_lookups[] = {
-	CLKDEV_CON_DEV_ID("hclk", "at91sam9rl-lcdfb.0", &lcdc_clk),
-	CLKDEV_CON_DEV_ID("hclk", "atmel_usba_udc", &utmi_clk),
-	CLKDEV_CON_DEV_ID("pclk", "atmel_usba_udc", &udphs_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk),
-	CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.0", &tc1_clk),
-	CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk),
-	CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk),
-	CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk),
-	CLKDEV_CON_DEV_ID("pclk", "fffc0000.ssc", &ssc0_clk),
-	CLKDEV_CON_DEV_ID("pclk", "fffc4000.ssc", &ssc1_clk),
-	CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.0", &twi0_clk),
-	CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.1", &twi1_clk),
-	CLKDEV_CON_ID("pioA", &pioA_clk),
-	CLKDEV_CON_ID("pioB", &pioB_clk),
-	CLKDEV_CON_ID("pioC", &pioC_clk),
-	CLKDEV_CON_ID("pioD", &pioD_clk),
-};
-
-static struct clk_lookup usart_clocks_lookups[] = {
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.0", &mck),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.1", &usart0_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.2", &usart1_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.3", &usart2_clk),
-	CLKDEV_CON_DEV_ID("usart", "atmel_usart.4", &usart3_clk),
+static struct clk_lookup pioA_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioA_clk", NULL),
+	CLKDEV_INIT(NULL, "pioA", NULL),
+};
+
+static struct clk_lookup pioB_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioB_clk", NULL),
+	CLKDEV_INIT(NULL, "pioB", NULL),
+};
+
+static struct clk_lookup pioC_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioC_clk", NULL),
+	CLKDEV_INIT(NULL, "pioC", NULL),
+};
+
+static struct clk_lookup pioD_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pioD_clk", NULL),
+	CLKDEV_INIT(NULL, "pioD", NULL),
+};
+
+static struct clk_lookup usart0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart0_clk", NULL),
+	CLKDEV_INIT("atmel_usart.1", "usart", NULL),
+};
+
+static struct clk_lookup usart1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart1_clk", NULL),
+	CLKDEV_INIT("atmel_usart.2", "usart", NULL),
+};
+
+static struct clk_lookup usart2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart2_clk", NULL),
+	CLKDEV_INIT("atmel_usart.3", "usart", NULL),
+};
+
+static struct clk_lookup usart3_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "usart3_clk", NULL),
+	CLKDEV_INIT("atmel_usart.4", "usart", NULL),
+};
+
+static struct clk_lookup mci_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "mci_clk", NULL),
+};
+
+static struct clk_lookup twi0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "twi0_clk", NULL),
+	CLKDEV_INIT("i2c-at91sam9g20.0", NULL, NULL),
+};
+
+static struct clk_lookup twi1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "twi1_clk", NULL),
+	CLKDEV_INIT("i2c-at91sam9g20.1", NULL, NULL),
+};
+
+static struct clk_lookup spi_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "spi_clk", NULL),
+};
+
+static struct clk_lookup ssc0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ssc0_clk", NULL),
+	CLKDEV_INIT("at91rm9200_ssc.0", "pclk", NULL),
+};
+
+static struct clk_lookup ssc1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ssc1_clk", NULL),
+	CLKDEV_INIT("at91rm9200_ssc.1", "pclk", NULL),
+};
+
+static struct clk_lookup tc0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc0_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.0", "t0_clk", NULL),
+};
+
+static struct clk_lookup tc1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc1_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.0", "t1_clk", NULL),
+};
+
+static struct clk_lookup tc2_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tc2_clk", NULL),
+	CLKDEV_INIT("atmel_tcb.0", "t2_clk", NULL),
+};
+
+static struct clk_lookup pwm_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pwm_clk", NULL),
+};
+
+static struct clk_lookup tsc_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "tsc_clk", NULL),
+};
+
+static struct clk_lookup dma_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "dma_clk", NULL),
+};
+
+static struct clk_lookup udphs_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "udphs_clk", NULL),
+	CLKDEV_INIT("atmel_usba_udc", "pclk", NULL),
+};
+
+static struct clk_lookup lcdc_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "lcdc_clk", NULL),
+	CLKDEV_INIT("at91sam9rl-lcdfb.0", "hclk", NULL),
+};
+
+static struct clk_lookup ac97_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "ac97_clk", NULL),
+};
+
+static size_t periph_clock_lookup_sizes[] __initdata = {
+	0,
+	0,
+	ARRAY_SIZE(pioA_clk_lookup),
+	ARRAY_SIZE(pioB_clk_lookup),
+	ARRAY_SIZE(pioC_clk_lookup),
+	ARRAY_SIZE(pioD_clk_lookup),
+	ARRAY_SIZE(usart0_clk_lookup),
+	ARRAY_SIZE(usart1_clk_lookup),
+	ARRAY_SIZE(usart2_clk_lookup),
+	ARRAY_SIZE(usart3_clk_lookup),
+	ARRAY_SIZE(mci_clk_lookup),
+	ARRAY_SIZE(twi0_clk_lookup),
+	ARRAY_SIZE(twi1_clk_lookup),
+	ARRAY_SIZE(spi_clk_lookup),
+	ARRAY_SIZE(ssc0_clk_lookup),
+	ARRAY_SIZE(ssc1_clk_lookup),
+	ARRAY_SIZE(tc0_clk_lookup),
+	ARRAY_SIZE(tc1_clk_lookup),
+	ARRAY_SIZE(tc2_clk_lookup),
+	ARRAY_SIZE(pwm_clk_lookup),
+	ARRAY_SIZE(tsc_clk_lookup),
+	ARRAY_SIZE(dma_clk_lookup),
+	ARRAY_SIZE(udphs_clk_lookup),
+	ARRAY_SIZE(lcdc_clk_lookup),
+	ARRAY_SIZE(ac97_clk_lookup),
+};
+
+static struct clk_lookup *periph_clock_lookups[] __initdata = {
+	NULL,
+	NULL,
+	pioA_clk_lookup,
+	pioB_clk_lookup,
+	pioC_clk_lookup,
+	pioD_clk_lookup,
+	usart0_clk_lookup,
+	usart1_clk_lookup,
+	usart2_clk_lookup,
+	usart3_clk_lookup,
+	mci_clk_lookup,
+	twi0_clk_lookup,
+	twi1_clk_lookup,
+	spi_clk_lookup,
+	ssc0_clk_lookup,
+	ssc1_clk_lookup,
+	tc0_clk_lookup,
+	tc1_clk_lookup,
+	tc2_clk_lookup,
+	pwm_clk_lookup,
+	tsc_clk_lookup,
+	dma_clk_lookup,
+	udphs_clk_lookup,
+	lcdc_clk_lookup,
+	ac97_clk_lookup,
+};
+
+
+/*
+ * The system clocks.
+ */
+static struct clk_lookup pck0_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck0", NULL),
+};
+
+static struct clk_lookup pck1_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "pck1", NULL),
+};
+
+static size_t system_clock_lookup_sizes[] __initdata = {
+	0,
+	0,
+	0,
+	0,
+	0,
+	0,
+	0,
+	0,
+	ARRAY_SIZE(pck0_clk_lookup),
+	ARRAY_SIZE(pck1_clk_lookup),
+};
+
+static struct clk_lookup *system_clock_lookups[] __initdata = {
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	pck0_clk_lookup,
+	pck1_clk_lookup,
 };
 
 /*
- * The two programmable clocks.
- * You must configure pin multiplexing to bring these signals out.
+ * The pll clocks.
  */
-static struct clk pck0 = {
-	.name		= "pck0",
-	.pmc_mask	= AT91_PMC_PCK0,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 0,
+static struct clk_lookup pll_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "plla", NULL),
 };
-static struct clk pck1 = {
-	.name		= "pck1",
-	.pmc_mask	= AT91_PMC_PCK1,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 1,
+
+static struct clk_range at91sam9rl_pll_output[] = {
+	CLK_RANGE(80000000, 200000000),
+	CLK_RANGE(190000000, 240000000),
+};
+static u8 at91sam9rl_pll_out[] = {0, 2,};
+
+struct clk_pll_characteristics at91sam9rl_pll_characteristics = {
+	.input = CLK_RANGE(1000000, 32000000),
+	.num_output = ARRAY_SIZE(at91sam9rl_pll_output),
+	.output = at91sam9rl_pll_output,
+	.out = at91sam9rl_pll_out,
 };
 
+
+/*
+ * The master clock.
+ */
+static struct clk_lookup mck_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "mck", NULL),
+	CLKDEV_INIT("atmel_usart.0", "usart", NULL),
+};
+
+struct clk_master_characteristics at91sam9rl_master_characteristics = {
+	.output = CLK_RANGE(0, 100000000),
+	.have_div3_pres = 0,
+	.divisors = {1, 2, 4, 0},
+};
+
+static const char *master_prog_clock_parent_names[] __initdata = {
+	"clk32k",
+	"main",
+	"plla",
+};
+
+static const char *prog_clock_names[] __initdata = {
+	"prog0",
+	"prog1",
+};
+
+/*
+ * UTMI clock.
+ */
+static struct clk_lookup utmi_clk_lookup[] = {
+	CLKDEV_INIT(NULL, "utmi_clk", NULL),
+	CLKDEV_INIT("atmel_usba_udc", "hclk", NULL),
+};
+
+
 static void __init at91sam9rl_register_clocks(void)
 {
 	int i;
+	int k;
+	size_t size;
+	struct clk *clk;
+	const char *name;
+	struct clk_lookup *lookup;
+
+	clk = at91_clk_register_pll("plla", "main", 0,
+				    &at91rm9200_pll_layout,
+				    &at91sam9rl_pll_characteristics);
+	for (i = 0; i < ARRAY_SIZE(pll_clk_lookup); i++)
+		pll_clk_lookup[i].clk = clk;
+	clkdev_add_table(pll_clk_lookup, ARRAY_SIZE(pll_clk_lookup));
+
+	clk = at91_clk_register_utmi("utmi_clk", "main");
+	for (i = 0; i < ARRAY_SIZE(utmi_clk_lookup); i++)
+		utmi_clk_lookup[i].clk = clk;
+	clkdev_add_table(utmi_clk_lookup, ARRAY_SIZE(utmi_clk_lookup));
 
-	for (i = 0; i < ARRAY_SIZE(periph_clocks); i++)
-		clk_register(periph_clocks[i]);
+	clk = at91_clk_register_master("mck",
+				ARRAY_SIZE(master_prog_clock_parent_names),
+				master_prog_clock_parent_names,
+				&at91rm9200_master_layout,
+				&at91sam9rl_master_characteristics);
+	for (i = 0; i < ARRAY_SIZE(mck_clk_lookup); i++)
+		mck_clk_lookup[i].clk = clk;
+	clkdev_add_table(mck_clk_lookup, ARRAY_SIZE(mck_clk_lookup));
 
-	clkdev_add_table(periph_clocks_lookups,
-			 ARRAY_SIZE(periph_clocks_lookups));
-	clkdev_add_table(usart_clocks_lookups,
-			 ARRAY_SIZE(usart_clocks_lookups));
+	for (i = 0; i < ARRAY_SIZE(periph_clock_lookup_sizes); i++) {
+		size = periph_clock_lookup_sizes[i];
+		lookup = periph_clock_lookups[i];
+		if (!size || !lookup)
+			continue;
+		name = periph_clock_lookups[i][0].con_id;
+		if (!name)
+			continue;
+		clk = at91_clk_register_peripheral(name, "mck", i);
 
-	clk_register(&pck0);
-	clk_register(&pck1);
+		for (k = 0; k < size; k++)
+			lookup[k].clk = clk;
+		clkdev_add_table(lookup, size);
+	}
+
+	for (i = 0; i < ARRAY_SIZE(prog_clock_names); i++) {
+		name = prog_clock_names[i];
+		clk = at91_clk_register_programmable(name,
+				master_prog_clock_parent_names,
+				ARRAY_SIZE(master_prog_clock_parent_names),
+				i, &at91rm9200_programmable_layout);
+	}
+
+	for (i = 0; i < ARRAY_SIZE(system_clock_lookup_sizes); i++) {
+		size = system_clock_lookup_sizes[i];
+		lookup = system_clock_lookups[i];
+		if (!size || !lookup)
+			continue;
+		name = system_clock_lookups[i][0].con_id;
+		if (!name)
+			continue;
+		clk = at91_clk_register_system(name, i);
+		for (k = 0; k < size; k++)
+			lookup[k].clk = clk;
+		clkdev_add_table(lookup, size);
+	}
 }
 
 /* --------------------------------------------------------------------
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 10:53:20 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 16:53:20 +0200
Subject: [PATCH v2 20/42] ARM: at91: move at91sam9x5 SoCs to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374072800-19856-1-git-send-email-b.brezillon@overkiz.com>

This patch removes all references to the old at91 clks for at91sam9x5 SoCs.
These SoCs only supports dt boards: we can remove register_clocks
(all clocks are defined in dt).

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/at91sam9x5.c |  291 ---------------------------------------
 1 file changed, 291 deletions(-)

diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
index 9fdea07..583a3d5 100644
--- a/arch/arm/mach-at91/at91sam9x5.c
+++ b/arch/arm/mach-at91/at91sam9x5.c
@@ -19,299 +19,9 @@
 #include "board.h"
 #include "soc.h"
 #include "generic.h"
-#include "clock.h"
 #include "sam9_smc.h"
 
 /* --------------------------------------------------------------------
- *  Clocks
- * -------------------------------------------------------------------- */
-
-/*
- * The peripheral clocks.
- */
-static struct clk pioAB_clk = {
-	.name		= "pioAB_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_PIOAB,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioCD_clk = {
-	.name		= "pioCD_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_PIOCD,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk smd_clk = {
-	.name		= "smd_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_SMD,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
-	.name		= "usart0_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_USART0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart1_clk = {
-	.name		= "usart1_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_USART1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart2_clk = {
-	.name		= "usart2_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_USART2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-/* USART3 clock - Only for sam9g25/sam9x25 */
-static struct clk usart3_clk = {
-	.name		= "usart3_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_USART3,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi0_clk = {
-	.name		= "twi0_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_TWI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi1_clk = {
-	.name		= "twi1_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_TWI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk twi2_clk = {
-	.name		= "twi2_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_TWI2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc0_clk = {
-	.name		= "mci0_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_MCI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi0_clk = {
-	.name		= "spi0_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_SPI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi1_clk = {
-	.name		= "spi1_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_SPI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk uart0_clk = {
-	.name		= "uart0_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_UART0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk uart1_clk = {
-	.name		= "uart1_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_UART1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tcb0_clk = {
-	.name		= "tcb0_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_TCB,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pwm_clk = {
-	.name		= "pwm_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_PWM,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk adc_clk = {
-	.name		= "adc_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_ADC,
-	.type	= CLK_TYPE_PERIPHERAL,
-};
-static struct clk adc_op_clk = {
-	.name		= "adc_op_clk",
-	.type		= CLK_TYPE_PERIPHERAL,
-	.rate_hz	= 5000000,
-};
-static struct clk dma0_clk = {
-	.name		= "dma0_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_DMA0,
-	.type	= CLK_TYPE_PERIPHERAL,
-};
-static struct clk dma1_clk = {
-	.name		= "dma1_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_DMA1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk uhphs_clk = {
-	.name		= "uhphs",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_UHPHS,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk udphs_clk = {
-	.name		= "udphs_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_UDPHS,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-/* emac0 clock - Only for sam9g25/sam9x25/sam9g35/sam9x35 */
-static struct clk macb0_clk = {
-	.name		= "pclk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_EMAC0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-/* lcd clock - Only for sam9g15/sam9g35/sam9x35 */
-static struct clk lcdc_clk = {
-	.name		= "lcdc_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_LCDC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-/* isi clock - Only for sam9g25 */
-static struct clk isi_clk = {
-	.name		= "isi_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_ISI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc1_clk = {
-	.name		= "mci1_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_MCI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-/* emac1 clock - Only for sam9x25 */
-static struct clk macb1_clk = {
-	.name		= "pclk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_EMAC1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk ssc_clk = {
-	.name		= "ssc_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_SSC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-/* can0 clock - Only for sam9x35 */
-static struct clk can0_clk = {
-	.name		= "can0_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_CAN0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-/* can1 clock - Only for sam9x35 */
-static struct clk can1_clk = {
-	.name		= "can1_clk",
-	.pmc_mask	= 1 << AT91SAM9X5_ID_CAN1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-
-static struct clk *periph_clocks[] __initdata = {
-	&pioAB_clk,
-	&pioCD_clk,
-	&smd_clk,
-	&usart0_clk,
-	&usart1_clk,
-	&usart2_clk,
-	&twi0_clk,
-	&twi1_clk,
-	&twi2_clk,
-	&mmc0_clk,
-	&spi0_clk,
-	&spi1_clk,
-	&uart0_clk,
-	&uart1_clk,
-	&tcb0_clk,
-	&pwm_clk,
-	&adc_clk,
-	&adc_op_clk,
-	&dma0_clk,
-	&dma1_clk,
-	&uhphs_clk,
-	&udphs_clk,
-	&mmc1_clk,
-	&ssc_clk,
-	// irq0
-};
-
-static struct clk_lookup periph_clocks_lookups[] = {
-	/* lookup table for DT entries */
-	CLKDEV_CON_DEV_ID("usart", "fffff200.serial", &mck),
-	CLKDEV_CON_DEV_ID("usart", "f801c000.serial", &usart0_clk),
-	CLKDEV_CON_DEV_ID("usart", "f8020000.serial", &usart1_clk),
-	CLKDEV_CON_DEV_ID("usart", "f8024000.serial", &usart2_clk),
-	CLKDEV_CON_DEV_ID("usart", "f8028000.serial", &usart3_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "f8008000.timer", &tcb0_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "f800c000.timer", &tcb0_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "f0008000.mmc", &mmc0_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "f000c000.mmc", &mmc1_clk),
-	CLKDEV_CON_DEV_ID("dma_clk", "ffffec00.dma-controller", &dma0_clk),
-	CLKDEV_CON_DEV_ID("dma_clk", "ffffee00.dma-controller", &dma1_clk),
-	CLKDEV_CON_DEV_ID("pclk", "f0010000.ssc", &ssc_clk),
-	CLKDEV_CON_DEV_ID(NULL, "f8010000.i2c", &twi0_clk),
-	CLKDEV_CON_DEV_ID(NULL, "f8014000.i2c", &twi1_clk),
-	CLKDEV_CON_DEV_ID(NULL, "f8018000.i2c", &twi2_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "f0000000.spi", &spi0_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "f0004000.spi", &spi1_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff400.gpio", &pioAB_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff600.gpio", &pioAB_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff800.gpio", &pioCD_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffffa00.gpio", &pioCD_clk),
-	/* additional fake clock for macb_hclk */
-	CLKDEV_CON_DEV_ID("hclk", "f802c000.ethernet", &macb0_clk),
-	CLKDEV_CON_DEV_ID("hclk", "f8030000.ethernet", &macb1_clk),
-	CLKDEV_CON_DEV_ID("hclk", "600000.ohci", &uhphs_clk),
-	CLKDEV_CON_DEV_ID("ohci_clk", "600000.ohci", &uhphs_clk),
-	CLKDEV_CON_DEV_ID("ehci_clk", "700000.ehci", &uhphs_clk),
-	CLKDEV_CON_DEV_ID("hclk", "500000.gadget", &utmi_clk),
-	CLKDEV_CON_DEV_ID("pclk", "500000.gadget", &udphs_clk),
-};
-
-/*
- * The two programmable clocks.
- * You must configure pin multiplexing to bring these signals out.
- */
-static struct clk pck0 = {
-	.name		= "pck0",
-	.pmc_mask	= AT91_PMC_PCK0,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 0,
-};
-static struct clk pck1 = {
-	.name		= "pck1",
-	.pmc_mask	= AT91_PMC_PCK1,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 1,
-};
-
-static void __init at91sam9x5_register_clocks(void)
-{
-	int i;
-
-	for (i = 0; i < ARRAY_SIZE(periph_clocks); i++)
-		clk_register(periph_clocks[i]);
-
-	clkdev_add_table(periph_clocks_lookups,
-			 ARRAY_SIZE(periph_clocks_lookups));
-
-	if (cpu_is_at91sam9g25()
-	|| cpu_is_at91sam9x25())
-		clk_register(&usart3_clk);
-
-	if (cpu_is_at91sam9g25()
-	|| cpu_is_at91sam9x25()
-	|| cpu_is_at91sam9g35()
-	|| cpu_is_at91sam9x35())
-		clk_register(&macb0_clk);
-
-	if (cpu_is_at91sam9g15()
-	|| cpu_is_at91sam9g35()
-	|| cpu_is_at91sam9x35())
-		clk_register(&lcdc_clk);
-
-	if (cpu_is_at91sam9g25())
-		clk_register(&isi_clk);
-
-	if (cpu_is_at91sam9x25())
-		clk_register(&macb1_clk);
-
-	if (cpu_is_at91sam9x25()
-	|| cpu_is_at91sam9x35()) {
-		clk_register(&can0_clk);
-		clk_register(&can1_clk);
-	}
-
-	clk_register(&pck0);
-	clk_register(&pck1);
-}
-
-/* --------------------------------------------------------------------
  *  AT91SAM9x5 processor initialization
  * -------------------------------------------------------------------- */
 
@@ -326,5 +36,4 @@ static void __init at91sam9x5_map_io(void)
 
 AT91_SOC_START(at91sam9x5)
 	.map_io = at91sam9x5_map_io,
-	.register_clocks = at91sam9x5_register_clocks,
 AT91_SOC_END
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 10:59:04 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 16:59:04 +0200
Subject: [PATCH v2 21/42] ARM: at91: move at91sam9 SoCs to new at91 clk implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374073144-19933-1-git-send-email-b.brezillon@overkiz.com>

Make use of common clk framework for all at91sam9 SoCs

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 3253373..9901316 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -32,6 +32,7 @@ config HAVE_AT91_SMD
 
 config SOC_AT91SAM9
 	bool
+	select COMMON_CLK
 	select AT91_SAM9_TIME
 	select CPU_ARM926T
 	select GENERIC_CLOCKEVENTS
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 10:59:30 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 16:59:30 +0200
Subject: [PATCH v2 22/42] ARM: at91: move sama5d3 SoCs to new at91 clk implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374073170-19972-1-git-send-email-b.brezillon@overkiz.com>

This patch removes all references to the old at91 clks for sama5d3 SoCs.
These SoCs only supports dt boards: we can remove register_clocks
(all clocks are defined in dt).

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/Kconfig   |    1 +
 arch/arm/mach-at91/sama5d3.c |  342 ------------------------------------------
 2 files changed, 1 insertion(+), 342 deletions(-)

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 9901316..5a51254 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -41,6 +41,7 @@ config SOC_AT91SAM9
 
 config SOC_SAMA5
 	bool
+	select COMMON_CLK
 	select AT91_SAM9_TIME
 	select CPU_V7
 	select GENERIC_CLOCKEVENTS
diff --git a/arch/arm/mach-at91/sama5d3.c b/arch/arm/mach-at91/sama5d3.c
index 32e0522..5e53be8 100644
--- a/arch/arm/mach-at91/sama5d3.c
+++ b/arch/arm/mach-at91/sama5d3.c
@@ -19,350 +19,9 @@
 
 #include "soc.h"
 #include "generic.h"
-#include "clock.h"
 #include "sam9_smc.h"
 
 /* --------------------------------------------------------------------
- *  Clocks
- * -------------------------------------------------------------------- */
-
-/*
- * The peripheral clocks.
- */
-
-static struct clk pioA_clk = {
-	.name		= "pioA_clk",
-	.pid		= SAMA5D3_ID_PIOA,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioB_clk = {
-	.name		= "pioB_clk",
-	.pid		= SAMA5D3_ID_PIOB,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioC_clk = {
-	.name		= "pioC_clk",
-	.pid		= SAMA5D3_ID_PIOC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioD_clk = {
-	.name		= "pioD_clk",
-	.pid		= SAMA5D3_ID_PIOD,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk pioE_clk = {
-	.name		= "pioE_clk",
-	.pid		= SAMA5D3_ID_PIOE,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk usart0_clk = {
-	.name		= "usart0_clk",
-	.pid		= SAMA5D3_ID_USART0,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk usart1_clk = {
-	.name		= "usart1_clk",
-	.pid		= SAMA5D3_ID_USART1,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk usart2_clk = {
-	.name		= "usart2_clk",
-	.pid		= SAMA5D3_ID_USART2,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk usart3_clk = {
-	.name		= "usart3_clk",
-	.pid		= SAMA5D3_ID_USART3,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk uart0_clk = {
-	.name		= "uart0_clk",
-	.pid		= SAMA5D3_ID_UART0,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk uart1_clk = {
-	.name		= "uart1_clk",
-	.pid		= SAMA5D3_ID_UART1,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk twi0_clk = {
-	.name		= "twi0_clk",
-	.pid		= SAMA5D3_ID_TWI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk twi1_clk = {
-	.name		= "twi1_clk",
-	.pid		= SAMA5D3_ID_TWI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk twi2_clk = {
-	.name		= "twi2_clk",
-	.pid		= SAMA5D3_ID_TWI2,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk mmc0_clk = {
-	.name		= "mci0_clk",
-	.pid		= SAMA5D3_ID_HSMCI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc1_clk = {
-	.name		= "mci1_clk",
-	.pid		= SAMA5D3_ID_HSMCI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk mmc2_clk = {
-	.name		= "mci2_clk",
-	.pid		= SAMA5D3_ID_HSMCI2,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi0_clk = {
-	.name		= "spi0_clk",
-	.pid		= SAMA5D3_ID_SPI0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk spi1_clk = {
-	.name		= "spi1_clk",
-	.pid		= SAMA5D3_ID_SPI1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tcb0_clk = {
-	.name		= "tcb0_clk",
-	.pid		= SAMA5D3_ID_TC0,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk tcb1_clk = {
-	.name		= "tcb1_clk",
-	.pid		= SAMA5D3_ID_TC1,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk adc_clk = {
-	.name		= "adc_clk",
-	.pid		= SAMA5D3_ID_ADC,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk adc_op_clk = {
-	.name		= "adc_op_clk",
-	.type		= CLK_TYPE_PERIPHERAL,
-	.rate_hz	= 5000000,
-};
-static struct clk dma0_clk = {
-	.name		= "dma0_clk",
-	.pid		= SAMA5D3_ID_DMA0,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk dma1_clk = {
-	.name		= "dma1_clk",
-	.pid		= SAMA5D3_ID_DMA1,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk uhphs_clk = {
-	.name		= "uhphs",
-	.pid		= SAMA5D3_ID_UHPHS,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk udphs_clk = {
-	.name		= "udphs_clk",
-	.pid		= SAMA5D3_ID_UDPHS,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-/* gmac only for sama5d33, sama5d34, sama5d35 */
-static struct clk macb0_clk = {
-	.name		= "macb0_clk",
-	.pid		= SAMA5D3_ID_GMAC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-/* emac only for sama5d31, sama5d35 */
-static struct clk macb1_clk = {
-	.name		= "macb1_clk",
-	.pid		= SAMA5D3_ID_EMAC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-/* lcd only for sama5d31, sama5d33, sama5d34 */
-static struct clk lcdc_clk = {
-	.name		= "lcdc_clk",
-	.pid		= SAMA5D3_ID_LCDC,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-/* isi only for sama5d33, sama5d35 */
-static struct clk isi_clk = {
-	.name		= "isi_clk",
-	.pid		= SAMA5D3_ID_ISI,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk can0_clk = {
-	.name		= "can0_clk",
-	.pid		= SAMA5D3_ID_CAN0,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk can1_clk = {
-	.name		= "can1_clk",
-	.pid		= SAMA5D3_ID_CAN1,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk ssc0_clk = {
-	.name		= "ssc0_clk",
-	.pid		= SAMA5D3_ID_SSC0,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk ssc1_clk = {
-	.name		= "ssc1_clk",
-	.pid		= SAMA5D3_ID_SSC1,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV2,
-};
-static struct clk sha_clk = {
-	.name		= "sha_clk",
-	.pid		= SAMA5D3_ID_SHA,
-	.type		= CLK_TYPE_PERIPHERAL,
-	.div		= AT91_PMC_PCR_DIV8,
-};
-static struct clk aes_clk = {
-	.name		= "aes_clk",
-	.pid		= SAMA5D3_ID_AES,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-static struct clk tdes_clk = {
-	.name		= "tdes_clk",
-	.pid		= SAMA5D3_ID_TDES,
-	.type		= CLK_TYPE_PERIPHERAL,
-};
-
-static struct clk *periph_clocks[] __initdata = {
-	&pioA_clk,
-	&pioB_clk,
-	&pioC_clk,
-	&pioD_clk,
-	&pioE_clk,
-	&usart0_clk,
-	&usart1_clk,
-	&usart2_clk,
-	&usart3_clk,
-	&uart0_clk,
-	&uart1_clk,
-	&twi0_clk,
-	&twi1_clk,
-	&twi2_clk,
-	&mmc0_clk,
-	&mmc1_clk,
-	&mmc2_clk,
-	&spi0_clk,
-	&spi1_clk,
-	&tcb0_clk,
-	&tcb1_clk,
-	&adc_clk,
-	&adc_op_clk,
-	&dma0_clk,
-	&dma1_clk,
-	&uhphs_clk,
-	&udphs_clk,
-	&macb0_clk,
-	&macb1_clk,
-	&lcdc_clk,
-	&isi_clk,
-	&can0_clk,
-	&can1_clk,
-	&ssc0_clk,
-	&ssc1_clk,
-	&sha_clk,
-	&aes_clk,
-	&tdes_clk,
-};
-
-static struct clk pck0 = {
-	.name		= "pck0",
-	.pmc_mask	= AT91_PMC_PCK0,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 0,
-};
-
-static struct clk pck1 = {
-	.name		= "pck1",
-	.pmc_mask	= AT91_PMC_PCK1,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 1,
-};
-
-static struct clk pck2 = {
-	.name		= "pck2",
-	.pmc_mask	= AT91_PMC_PCK2,
-	.type		= CLK_TYPE_PROGRAMMABLE,
-	.id		= 2,
-};
-
-static struct clk_lookup periph_clocks_lookups[] = {
-	/* lookup table for DT entries */
-	CLKDEV_CON_DEV_ID("usart", "ffffee00.serial", &mck),
-	CLKDEV_CON_DEV_ID(NULL, "fffff200.gpio", &pioA_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff400.gpio", &pioB_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff600.gpio", &pioC_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffff800.gpio", &pioD_clk),
-	CLKDEV_CON_DEV_ID(NULL, "fffffa00.gpio", &pioE_clk),
-	CLKDEV_CON_DEV_ID("usart", "f001c000.serial", &usart0_clk),
-	CLKDEV_CON_DEV_ID("usart", "f0020000.serial", &usart1_clk),
-	CLKDEV_CON_DEV_ID("usart", "f8020000.serial", &usart2_clk),
-	CLKDEV_CON_DEV_ID("usart", "f8024000.serial", &usart3_clk),
-	CLKDEV_CON_DEV_ID(NULL, "f0014000.i2c", &twi0_clk),
-	CLKDEV_CON_DEV_ID(NULL, "f0018000.i2c", &twi1_clk),
-	CLKDEV_CON_DEV_ID(NULL, "f801c000.i2c", &twi2_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "f0000000.mmc", &mmc0_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "f8000000.mmc", &mmc1_clk),
-	CLKDEV_CON_DEV_ID("mci_clk", "f8004000.mmc", &mmc2_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "f0004000.spi", &spi0_clk),
-	CLKDEV_CON_DEV_ID("spi_clk", "f8008000.spi", &spi1_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "f0010000.timer", &tcb0_clk),
-	CLKDEV_CON_DEV_ID("t0_clk", "f8014000.timer", &tcb1_clk),
-	CLKDEV_CON_DEV_ID("tsc_clk", "f8018000.tsadcc", &adc_clk),
-	CLKDEV_CON_DEV_ID("dma_clk", "ffffe600.dma-controller", &dma0_clk),
-	CLKDEV_CON_DEV_ID("dma_clk", "ffffe800.dma-controller", &dma1_clk),
-	CLKDEV_CON_DEV_ID("hclk", "600000.ohci", &uhphs_clk),
-	CLKDEV_CON_DEV_ID("ohci_clk", "600000.ohci", &uhphs_clk),
-	CLKDEV_CON_DEV_ID("ehci_clk", "700000.ehci", &uhphs_clk),
-	CLKDEV_CON_DEV_ID("pclk", "500000.gadget", &udphs_clk),
-	CLKDEV_CON_DEV_ID("hclk", "500000.gadget", &utmi_clk),
-	CLKDEV_CON_DEV_ID("hclk", "f0028000.ethernet", &macb0_clk),
-	CLKDEV_CON_DEV_ID("pclk", "f0028000.ethernet", &macb0_clk),
-	CLKDEV_CON_DEV_ID("hclk", "f802c000.ethernet", &macb1_clk),
-	CLKDEV_CON_DEV_ID("pclk", "f802c000.ethernet", &macb1_clk),
-	CLKDEV_CON_DEV_ID("pclk", "f0008000.ssc", &ssc0_clk),
-	CLKDEV_CON_DEV_ID("pclk", "f000c000.ssc", &ssc1_clk),
-	CLKDEV_CON_DEV_ID("can_clk", "f000c000.can", &can0_clk),
-	CLKDEV_CON_DEV_ID("can_clk", "f8010000.can", &can1_clk),
-	CLKDEV_CON_DEV_ID("sha_clk", "f8034000.sha", &sha_clk),
-	CLKDEV_CON_DEV_ID("aes_clk", "f8038000.aes", &aes_clk),
-	CLKDEV_CON_DEV_ID("tdes_clk", "f803c000.tdes", &tdes_clk),
-};
-
-static void __init sama5d3_register_clocks(void)
-{
-	int i;
-
-	for (i = 0; i < ARRAY_SIZE(periph_clocks); i++)
-		clk_register(periph_clocks[i]);
-
-	clkdev_add_table(periph_clocks_lookups,
-			 ARRAY_SIZE(periph_clocks_lookups));
-
-	clk_register(&pck0);
-	clk_register(&pck1);
-	clk_register(&pck2);
-}
-
-/* --------------------------------------------------------------------
  *  AT91SAM9x5 processor initialization
  * -------------------------------------------------------------------- */
 
@@ -373,5 +32,4 @@ static void __init sama5d3_map_io(void)
 
 AT91_SOC_START(sama5d3)
 	.map_io = sama5d3_map_io,
-	.register_clocks = sama5d3_register_clocks,
 AT91_SOC_END
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 11:00:17 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 17:00:17 +0200
Subject: [PATCH v2 23/42] ARM: at91: move at91rm9200 boards to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374073217-20011-1-git-send-email-b.brezillon@overkiz.com>

Move at91 clk init from early_init to timer_init for all at91rm9200 non dt
boards.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/board-1arm.c       |   12 ++++++++++--
 arch/arm/mach-at91/board-carmeva.c    |   13 ++++++++-----
 arch/arm/mach-at91/board-cpuat91.c    |   12 ++++++++++--
 arch/arm/mach-at91/board-csb337.c     |   11 +++++++----
 arch/arm/mach-at91/board-csb637.c     |   11 +++++++----
 arch/arm/mach-at91/board-dt-rm9200.c  |    9 ++++++++-
 arch/arm/mach-at91/board-eb9200.c     |   11 +++++++----
 arch/arm/mach-at91/board-ecbat91.c    |   12 ++++++++++--
 arch/arm/mach-at91/board-eco920.c     |   13 +++++++++++--
 arch/arm/mach-at91/board-kafa.c       |   12 ++++++++++--
 arch/arm/mach-at91/board-kb9202.c     |   12 ++++++++++--
 arch/arm/mach-at91/board-picotux200.c |   11 +++++++----
 arch/arm/mach-at91/board-rm9200ek.c   |   11 +++++++----
 arch/arm/mach-at91/board-rsi-ews.c    |   12 ++++++++----
 arch/arm/mach-at91/board-yl-9200.c    |   12 ++++++++++--
 15 files changed, 130 insertions(+), 44 deletions(-)

diff --git a/arch/arm/mach-at91/board-1arm.c b/arch/arm/mach-at91/board-1arm.c
index 35ab632..1ccfa2d 100644
--- a/arch/arm/mach-at91/board-1arm.c
+++ b/arch/arm/mach-at91/board-1arm.c
@@ -46,8 +46,16 @@ static void __init onearm_init_early(void)
 	/* Set cpu type: PQFP */
 	at91rm9200_set_type(ARCH_REVISON_9200_PQFP);
 
+	at91_initialize();
+}
+
+static void __init onearm_timer_init(void)
+{
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init rm9200 timer */
+	at91rm9200_timer_init();
 }
 
 static struct macb_platform_data __initdata onearm_eth_data = {
@@ -90,7 +98,7 @@ static void __init onearm_board_init(void)
 
 MACHINE_START(ONEARM, "Ajeco 1ARM single board computer")
 	/* Maintainer: Lennert Buytenhek <buytenh at wantstofly.org> */
-	.init_time	= at91rm9200_timer_init,
+	.init_time	= onearm_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
 	.init_early	= onearm_init_early,
diff --git a/arch/arm/mach-at91/board-carmeva.c b/arch/arm/mach-at91/board-carmeva.c
index 9298305..591ff4c 100644
--- a/arch/arm/mach-at91/board-carmeva.c
+++ b/arch/arm/mach-at91/board-carmeva.c
@@ -41,10 +41,13 @@
 #include "generic.h"
 
 
-static void __init carmeva_init_early(void)
+static void __init carmeva_timer_init(void)
 {
-	/* Initialize processor: 20.000 MHz crystal */
-	at91_initialize(20000000);
+	/* Initialize processor: 18.432 MHz crystal */
+	at91_clk_init(20000000);
+
+	/* Init rm9200 timer */
+	at91rm9200_timer_init();
 }
 
 static struct macb_platform_data __initdata carmeva_eth_data = {
@@ -157,10 +160,10 @@ static void __init carmeva_board_init(void)
 
 MACHINE_START(CARMEVA, "Carmeva")
 	/* Maintainer: Conitec Datasystems */
-	.init_time	= at91rm9200_timer_init,
+	.init_time	= carmeva_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= carmeva_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= carmeva_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-cpuat91.c b/arch/arm/mach-at91/board-cpuat91.c
index 42f1353..42b51d9 100644
--- a/arch/arm/mach-at91/board-cpuat91.c
+++ b/arch/arm/mach-at91/board-cpuat91.c
@@ -58,8 +58,16 @@ static void __init cpuat91_init_early(void)
 	/* Set cpu type: PQFP */
 	at91rm9200_set_type(ARCH_REVISON_9200_PQFP);
 
+	at91_initialize();
+}
+
+static void __init cpuat91_timer_init(void)
+{
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init rm9200 timer */
+	at91rm9200_timer_init();
 }
 
 static struct macb_platform_data __initdata cpuat91_eth_data = {
@@ -178,7 +186,7 @@ static void __init cpuat91_board_init(void)
 
 MACHINE_START(CPUAT91, "Eukrea")
 	/* Maintainer: Eric Benard - EUKREA Electromatique */
-	.init_time	= at91rm9200_timer_init,
+	.init_time	= cpuat91_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
 	.init_early	= cpuat91_init_early,
diff --git a/arch/arm/mach-at91/board-csb337.c b/arch/arm/mach-at91/board-csb337.c
index e5fde215..b772ec2 100644
--- a/arch/arm/mach-at91/board-csb337.c
+++ b/arch/arm/mach-at91/board-csb337.c
@@ -44,10 +44,13 @@
 #include "generic.h"
 
 
-static void __init csb337_init_early(void)
+static void __init csb337_timer_init(void)
 {
 	/* Initialize processor: 3.6864 MHz crystal */
-	at91_initialize(3686400);
+	at91_clk_init(3686400);
+
+	/* Init rm9200 timer */
+	at91rm9200_timer_init();
 }
 
 static struct macb_platform_data __initdata csb337_eth_data = {
@@ -251,10 +254,10 @@ static void __init csb337_board_init(void)
 
 MACHINE_START(CSB337, "Cogent CSB337")
 	/* Maintainer: Bill Gatliff */
-	.init_time	= at91rm9200_timer_init,
+	.init_time	= csb337_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= csb337_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= csb337_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-csb637.c b/arch/arm/mach-at91/board-csb637.c
index fdf1106..4815dbe 100644
--- a/arch/arm/mach-at91/board-csb637.c
+++ b/arch/arm/mach-at91/board-csb637.c
@@ -41,10 +41,13 @@
 #include "generic.h"
 
 
-static void __init csb637_init_early(void)
+static void __init csb637_timer_init(void)
 {
 	/* Initialize processor: 3.6864 MHz crystal */
-	at91_initialize(3686400);
+	at91_clk_init(3686400);
+
+	/* Init rm9200 timer */
+	at91rm9200_timer_init();
 }
 
 static struct macb_platform_data __initdata csb637_eth_data = {
@@ -132,10 +135,10 @@ static void __init csb637_board_init(void)
 
 MACHINE_START(CSB637, "Cogent CSB637")
 	/* Maintainer: Bill Gatliff */
-	.init_time	= at91rm9200_timer_init,
+	.init_time	= csb637_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= csb637_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= csb637_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-dt-rm9200.c b/arch/arm/mach-at91/board-dt-rm9200.c
index 3fcb662..4f3882e 100644
--- a/arch/arm/mach-at91/board-dt-rm9200.c
+++ b/arch/arm/mach-at91/board-dt-rm9200.c
@@ -15,6 +15,7 @@
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
+#include <linux/clk-provider.h>
 
 #include <asm/setup.h>
 #include <asm/irq.h>
@@ -26,6 +27,12 @@
 #include "generic.h"
 
 
+static void __init at91rm9200_dt_timer_init(void)
+{
+	of_clk_init(NULL);
+	at91rm9200_timer_init();
+}
+
 static const struct of_device_id irq_of_match[] __initconst = {
 	{ .compatible = "atmel,at91rm9200-aic", .data = at91_aic_of_init },
 	{ /*sentinel*/ }
@@ -47,7 +54,7 @@ static const char *at91rm9200_dt_board_compat[] __initdata = {
 };
 
 DT_MACHINE_START(at91rm9200_dt, "Atmel AT91RM9200 (Device Tree)")
-	.init_time      = at91rm9200_timer_init,
+	.init_time      = at91rm9200_dt_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
 	.init_early	= at91rm9200_dt_initialize,
diff --git a/arch/arm/mach-at91/board-eb9200.c b/arch/arm/mach-at91/board-eb9200.c
index f9be816..84cc538 100644
--- a/arch/arm/mach-at91/board-eb9200.c
+++ b/arch/arm/mach-at91/board-eb9200.c
@@ -40,10 +40,13 @@
 #include "generic.h"
 
 
-static void __init eb9200_init_early(void)
+static void __init eb9200_timer_init(void)
 {
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init rm9200 timer */
+	at91rm9200_timer_init();
 }
 
 static struct macb_platform_data __initdata eb9200_eth_data = {
@@ -116,10 +119,10 @@ static void __init eb9200_board_init(void)
 }
 
 MACHINE_START(ATEB9200, "Embest ATEB9200")
-	.init_time	= at91rm9200_timer_init,
+	.init_time	= eb9200_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= eb9200_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= eb9200_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-ecbat91.c b/arch/arm/mach-at91/board-ecbat91.c
index b2fcd71..fc767bd 100644
--- a/arch/arm/mach-at91/board-ecbat91.c
+++ b/arch/arm/mach-at91/board-ecbat91.c
@@ -49,8 +49,16 @@ static void __init ecb_at91init_early(void)
 	/* Set cpu type: PQFP */
 	at91rm9200_set_type(ARCH_REVISON_9200_PQFP);
 
+	at91_initialize();
+}
+
+static void __init ecbat91_timer_init(void)
+{
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init rm9200 timer */
+	at91rm9200_timer_init();
 }
 
 static struct macb_platform_data __initdata ecb_at91eth_data = {
@@ -181,7 +189,7 @@ static void __init ecb_at91board_init(void)
 
 MACHINE_START(ECBAT91, "emQbit's ECB_AT91")
 	/* Maintainer: emQbit.com */
-	.init_time	= at91rm9200_timer_init,
+	.init_time	= ecbat91_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
 	.init_early	= ecb_at91init_early,
diff --git a/arch/arm/mach-at91/board-eco920.c b/arch/arm/mach-at91/board-eco920.c
index 77de410..b910c41 100644
--- a/arch/arm/mach-at91/board-eco920.c
+++ b/arch/arm/mach-at91/board-eco920.c
@@ -37,7 +37,16 @@ static void __init eco920_init_early(void)
 	/* Set cpu type: PQFP */
 	at91rm9200_set_type(ARCH_REVISON_9200_PQFP);
 
-	at91_initialize(18432000);
+	at91_initialize();
+}
+
+static void __init eco920_timer_init(void)
+{
+	/* Initialize processor: 18.432 MHz crystal */
+	at91_clk_init(18432000);
+
+	/* Init rm9200 timer */
+	at91rm9200_timer_init();
 }
 
 static struct macb_platform_data __initdata eco920_eth_data = {
@@ -149,7 +158,7 @@ static void __init eco920_board_init(void)
 
 MACHINE_START(ECO920, "eco920")
 	/* Maintainer: Sascha Hauer */
-	.init_time	= at91rm9200_timer_init,
+	.init_time	= eco920_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
 	.init_early	= eco920_init_early,
diff --git a/arch/arm/mach-at91/board-kafa.c b/arch/arm/mach-at91/board-kafa.c
index 88e2f5d..e7378c4 100644
--- a/arch/arm/mach-at91/board-kafa.c
+++ b/arch/arm/mach-at91/board-kafa.c
@@ -46,8 +46,16 @@ static void __init kafa_init_early(void)
 	/* Set cpu type: PQFP */
 	at91rm9200_set_type(ARCH_REVISON_9200_PQFP);
 
+	at91_initialize();
+}
+
+static void __init kafa_timer_init(void)
+{
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init rm9200 timer */
+	at91rm9200_timer_init();
 }
 
 static struct macb_platform_data __initdata kafa_eth_data = {
@@ -103,7 +111,7 @@ static void __init kafa_board_init(void)
 
 MACHINE_START(KAFA, "Sperry-Sun KAFA")
 	/* Maintainer: Sergei Sharonov */
-	.init_time	= at91rm9200_timer_init,
+	.init_time	= kafa_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
 	.init_early	= kafa_init_early,
diff --git a/arch/arm/mach-at91/board-kb9202.c b/arch/arm/mach-at91/board-kb9202.c
index 0c519d9..58f2069 100644
--- a/arch/arm/mach-at91/board-kb9202.c
+++ b/arch/arm/mach-at91/board-kb9202.c
@@ -49,8 +49,16 @@ static void __init kb9202_init_early(void)
 	/* Set cpu type: PQFP */
 	at91rm9200_set_type(ARCH_REVISON_9200_PQFP);
 
+	at91_initialize();
+}
+
+static void __init kafa_timer_init(void)
+{
 	/* Initialize processor: 10 MHz crystal */
-	at91_initialize(10000000);
+	at91_clk_init(10000000);
+
+	/* Init rm9200 timer */
+	at91rm9200_timer_init();
 }
 
 static struct macb_platform_data __initdata kb9202_eth_data = {
@@ -149,7 +157,7 @@ static void __init kb9202_board_init(void)
 
 MACHINE_START(KB9200, "KB920x")
 	/* Maintainer: KwikByte, Inc. */
-	.init_time	= at91rm9200_timer_init,
+	.init_time	= kafa_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
 	.init_early	= kb9202_init_early,
diff --git a/arch/arm/mach-at91/board-picotux200.c b/arch/arm/mach-at91/board-picotux200.c
index ab2b2ec..8855fad 100644
--- a/arch/arm/mach-at91/board-picotux200.c
+++ b/arch/arm/mach-at91/board-picotux200.c
@@ -45,10 +45,13 @@
 #include "generic.h"
 
 
-static void __init picotux200_init_early(void)
+static void __init picotux200_timer_init(void)
 {
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init rm9200 timer */
+	at91rm9200_timer_init();
 }
 
 static struct macb_platform_data __initdata picotux200_eth_data = {
@@ -119,10 +122,10 @@ static void __init picotux200_board_init(void)
 
 MACHINE_START(PICOTUX2XX, "picotux 200")
 	/* Maintainer: Kleinhenz Elektronik GmbH */
-	.init_time	= at91rm9200_timer_init,
+	.init_time	= picotux200_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= picotux200_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= picotux200_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-rm9200ek.c b/arch/arm/mach-at91/board-rm9200ek.c
index 8b17dad..5d3abac 100644
--- a/arch/arm/mach-at91/board-rm9200ek.c
+++ b/arch/arm/mach-at91/board-rm9200ek.c
@@ -47,10 +47,13 @@
 #include "generic.h"
 
 
-static void __init ek_init_early(void)
+static void __init ek_timer_init(void)
 {
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init rm9200 timer */
+	at91rm9200_timer_init();
 }
 
 static struct macb_platform_data __initdata ek_eth_data = {
@@ -186,10 +189,10 @@ static void __init ek_board_init(void)
 
 MACHINE_START(AT91RM9200EK, "Atmel AT91RM9200-EK")
 	/* Maintainer: SAN People/Atmel */
-	.init_time	= at91rm9200_timer_init,
+	.init_time	= ek_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= ek_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= ek_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-rsi-ews.c b/arch/arm/mach-at91/board-rsi-ews.c
index f6d7f19..31738f9 100644
--- a/arch/arm/mach-at91/board-rsi-ews.c
+++ b/arch/arm/mach-at91/board-rsi-ews.c
@@ -32,10 +32,14 @@
 #include "board.h"
 #include "generic.h"
 
-static void __init rsi_ews_init_early(void)
+
+static void __init rsi_ews_timer_init(void)
 {
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init rm9200 timer */
+	at91rm9200_timer_init();
 }
 
 /*
@@ -222,10 +226,10 @@ static void __init rsi_ews_board_init(void)
 
 MACHINE_START(RSI_EWS, "RSI EWS")
 	/* Maintainer: Josef Holzmayr <holzmayr at rsi-elektrotechnik.de> */
-	.init_time	= at91rm9200_timer_init,
+	.init_time	= rsi_ews_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= rsi_ews_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= rsi_ews_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-yl-9200.c b/arch/arm/mach-at91/board-yl-9200.c
index be08377..78a0780 100644
--- a/arch/arm/mach-at91/board-yl-9200.c
+++ b/arch/arm/mach-at91/board-yl-9200.c
@@ -57,8 +57,16 @@ static void __init yl9200_init_early(void)
 	/* Set cpu type: PQFP */
 	at91rm9200_set_type(ARCH_REVISON_9200_PQFP);
 
+	at91_initialize();
+}
+
+static void __init yl9200_timer_init(void)
+{
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init rm9200 timer */
+	at91rm9200_timer_init();
 }
 
 /*
@@ -587,7 +595,7 @@ static void __init yl9200_board_init(void)
 
 MACHINE_START(YL9200, "uCdragon YL-9200")
 	/* Maintainer: S.Birtles */
-	.init_time	= at91rm9200_timer_init,
+	.init_time	= yl9200_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
 	.init_early	= yl9200_init_early,
-- 
1.7.9.5



From eduardo.valentin at ti.com  Wed Jul 17 11:02:44 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Wed, 17 Jul 2013 11:02:44 -0400
Subject: [PATCH 4/9] arm: dts: flag omap4430 with needs-cooling for cpu node
In-Reply-To: <1374073374-30946-1-git-send-email-eduardo.valentin@ti.com>
References: <1374073374-30946-1-git-send-email-eduardo.valentin@ti.com>
Message-ID: <1374073374-30946-9-git-send-email-eduardo.valentin@ti.com>

OMAP4430 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the flag so that cpufreq-cpu0 driver
loads the cooling device to use cpufreq on OMAP4430.

Cc: "Beno?t Cousson" <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin at ti.com>
---
 arch/arm/boot/dts/omap443x.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..4a4dcc3 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -22,6 +22,7 @@
 				1008000 1375000
 			>;
 			clock-latency = <300000>; /* From legacy driver */
+			needs-cooling; /* make sure we have cpufreq-cooling */
 		};
 	};
 
-- 
1.8.2.1.342.gfa7285d



From eduardo.valentin at ti.com  Wed Jul 17 11:02:46 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Wed, 17 Jul 2013 11:02:46 -0400
Subject: [PATCH 5/8] arm: dts: add omap4430 thermal data
In-Reply-To: <1374073374-30946-1-git-send-email-eduardo.valentin@ti.com>
References: <1374073374-30946-1-git-send-email-eduardo.valentin@ti.com>
Message-ID: <1374073374-30946-11-git-send-email-eduardo.valentin@ti.com>

This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.

Cc: "Beno?t Cousson" <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin at ti.com>
---
 arch/arm/boot/dts/omap443x.dtsi | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..c9a1c89 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -8,6 +8,7 @@
  * kind, whether express or implied.
  */
 
+#include <dt-bindings/thermal/thermal.h>
 #include "omap4.dtsi"
 
 / {
@@ -26,8 +27,34 @@
 	};
 
 	bandgap {
-		reg = <0x4a002260 0x4
-		       0x4a00232C 0x4>;
+		reg = <0x4a002260 0x4 0x4a00232C 0x4>;
 		compatible = "ti,omap4430-bandgap";
+		thermal_zone {
+			type = "CPU";
+			mask = <0x03>; /* trips writability */
+			passive_delay = <250>; /* milliseconds */
+			polling_delay = <1000>; /* milliseconds */
+			governor = "step_wise";
+			trips {
+				alert at 100000{
+					temperature = <100000>; /* milliCelsius */
+					hysteresis = <2000>; /* milliCelsius */
+					type = <THERMAL_TRIP_PASSIVE>;
+				};
+				crit at 125000{
+					temperature = <125000>; /* milliCelsius */
+					hysteresis = <2000>; /* milliCelsius */
+					type = <THERMAL_TRIP_CRITICAL>;
+				};
+			};
+			bind_params {
+				action at 0{
+					cooling_device = "thermal-cpufreq";
+					weight = <100>; /* percentage */
+					mask = <0x01>;
+					/* no limits, using defaults */
+				};
+			};
+		};
 	};
 };
-- 
1.8.2.1.342.gfa7285d



From eduardo.valentin at ti.com  Wed Jul 17 11:02:48 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Wed, 17 Jul 2013 11:02:48 -0400
Subject: [PATCH 6/8] arm: dts: flag omap4430 with needs-cooling for cpu node
In-Reply-To: <1374073374-30946-1-git-send-email-eduardo.valentin@ti.com>
References: <1374073374-30946-1-git-send-email-eduardo.valentin@ti.com>
Message-ID: <1374073374-30946-13-git-send-email-eduardo.valentin@ti.com>

OMAP4430 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the flag so that cpufreq-cpu0 driver
loads the cooling device to use cpufreq on OMAP4430.

Cc: "Beno?t Cousson" <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin at ti.com>
---
 arch/arm/boot/dts/omap443x.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index c9a1c89..27f0e0f 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -23,6 +23,7 @@
 				1008000 1375000
 			>;
 			clock-latency = <300000>; /* From legacy driver */
+			needs-cooling; /* make sure we have cpufreq-cooling */
 		};
 	};
 
-- 
1.8.2.1.342.gfa7285d



From eduardo.valentin at ti.com  Wed Jul 17 11:02:50 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Wed, 17 Jul 2013 11:02:50 -0400
Subject: [PATCH 7/9] arm: dts: add omap4430 thermal data
In-Reply-To: <1374073374-30946-1-git-send-email-eduardo.valentin@ti.com>
References: <1374073374-30946-1-git-send-email-eduardo.valentin@ti.com>
Message-ID: <1374073374-30946-15-git-send-email-eduardo.valentin@ti.com>

This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.

Cc: "Beno?t Cousson" <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin at ti.com>
---
 arch/arm/boot/dts/omap443x.dtsi | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index 4a4dcc3..27f0e0f 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -8,6 +8,7 @@
  * kind, whether express or implied.
  */
 
+#include <dt-bindings/thermal/thermal.h>
 #include "omap4.dtsi"
 
 / {
@@ -27,8 +28,34 @@
 	};
 
 	bandgap {
-		reg = <0x4a002260 0x4
-		       0x4a00232C 0x4>;
+		reg = <0x4a002260 0x4 0x4a00232C 0x4>;
 		compatible = "ti,omap4430-bandgap";
+		thermal_zone {
+			type = "CPU";
+			mask = <0x03>; /* trips writability */
+			passive_delay = <250>; /* milliseconds */
+			polling_delay = <1000>; /* milliseconds */
+			governor = "step_wise";
+			trips {
+				alert at 100000{
+					temperature = <100000>; /* milliCelsius */
+					hysteresis = <2000>; /* milliCelsius */
+					type = <THERMAL_TRIP_PASSIVE>;
+				};
+				crit at 125000{
+					temperature = <125000>; /* milliCelsius */
+					hysteresis = <2000>; /* milliCelsius */
+					type = <THERMAL_TRIP_CRITICAL>;
+				};
+			};
+			bind_params {
+				action at 0{
+					cooling_device = "thermal-cpufreq";
+					weight = <100>; /* percentage */
+					mask = <0x01>;
+					/* no limits, using defaults */
+				};
+			};
+		};
 	};
 };
-- 
1.8.2.1.342.gfa7285d



From linux at arm.linux.org.uk  Wed Jul 17 11:11:48 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 16:11:48 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabled
In-Reply-To: <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
Message-ID: <20130717151148.GM24642@n2100.arm.linux.org.uk>

On Wed, Jul 17, 2013 at 02:25:38PM +0100, Stefano Stabellini wrote:
> On Mon, 15 Jul 2013, Julien Grall wrote:
> > Even if uncompress debug is disabled, some board will continue to print
> > information during uncompress step.
> 
> Are you talking about DEBUG_UNCOMPRESS?
> Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> some board will continue to print information during the uncompress step"?
> 
> Isn't this a bug in the platform specific code that should be fixed anyway?

Hang on, let's be clear what's going on here.

1. The normal output from the decompressor is *not* debugging.  By that
   I mean the "Uncompressing kernel... done" message.  That is part of
   user output.

2. In non-multiplatform environments, the decompressor will normally use
   the putc/flush functions found in arch/arm/mach-*/include/mach/uncompress.h
   to implement its output, irrespective of the DEBUG_UNCOMPRESS setting.
   (An interesting point is that DEBUG_UNCOMPRESS really should depend on
   MULTIPLATFORM so that this point is explicit - the option requires
   MULTIPLATFORM to be set.)

3. DEBUG_UNCOMPRESS allows the functions which we've implemented for LL
   debug to be re-used for decompressor output.

4. When DEBUG_UNCOMPRESS is not set in a multiplatform kernel, the
   decompressors putc() and flush() functions are stubbed out.

So, it's quite right that you get output from the decompressor even when
DEBUG_UNCOMPRESS is not set.  There's no problem with that.


From dh.herrmann at gmail.com  Wed Jul 17 11:14:13 2013
From: dh.herrmann at gmail.com (David Herrmann)
Date: Wed, 17 Jul 2013 17:14:13 +0200
Subject: [PATCH] Route kbd LEDs through the generic LEDs layer
In-Reply-To: <20130715190803.GG11600@type.youpi.perso.aquilenet.fr>
References: <201011112205.oABM5KVJ005298@imap1.linux-foundation.org>
 <201011111440.07882.dmitry.torokhov@gmail.com>
 <20110102090935.GV32469@atrey.karlin.mff.cuni.cz>
 <20110102103210.GA25662@core.coreip.homeip.net>
 <20110102225741.GX5480@const.famille.thibault.fr>
 <20110112182702.GA9168@core.coreip.homeip.net>
 <20111114040613.GA4992@type.famille.thibault.fr>
 <20121221003449.GA6999@type.youpi.perso.aquilenet.fr>
 <20130707101028.GD5651@type.youpi.perso.aquilenet.fr>
 <CANq1E4TRAOp+=w4oqPt4sjV7iLyDygxxpwrZy7dSB8UK288aNA@mail.gmail.com>
 <20130715190803.GG11600@type.youpi.perso.aquilenet.fr>
Message-ID: <CANq1E4QicuuD6iSkR-TUp99QTaxq_FZGwing2w30=nN0cw5hpw@mail.gmail.com>

Hi

On Mon, Jul 15, 2013 at 9:08 PM, Samuel Thibault
<samuel.thibault at ens-lyon.org> wrote:
> Hello,
>
> David Herrmann, le Mon 15 Jul 2013 17:03:08 +0200, a ?crit :
>> > @@ -13,6 +13,10 @@
>> >         bool "Virtual terminal" if EXPERT
>> >         depends on !S390 && !UML
>> >         select INPUT
>> > +       select NEW_LEDS
>> > +       select LEDS_CLASS
>> > +       select LEDS_TRIGGERS
>> > +       select INPUT_LEDS
>>
>> This looks odd. Any dependency changes in the input-layer will break
>> this. But I guess that's what we get for a non-recursive "select". Hmm
>
> Yes, that's the issue.
>
>> I also think that the macros don't really simplify this. So:
>>   [VC_SHIFTLOCK] = { .name = "shiftlock", .activate =
>> kbd_lockstate_trigger_activate },
>> isn't much longer than:
>>   DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTLOCK,  "shiftlock"),
>
> That makes it more than 80 columns, at least.

Indeed, I missed that.

>> > +       for (i = 0; i < ARRAY_SIZE(ledtrig_ledstate); i++)
>> > +               led_trigger_register(&ledtrig_ledstate[i]);
>> > +       for (i = 0; i < ARRAY_SIZE(ledtrig_lockstate); i++)
>> > +               led_trigger_register(&ledtrig_lockstate[i]);
>> > +
>>
>> This returns "int", are you sure no error-handling is needed?
>
> ATM only registering the same name several times can happen, and
> shouldn't ever happen. But better warn than be sorry, indeed.

Yepp, it also avoids ignoring any future errors that we might
introduce in led_trigger_register().

>> > + * Keyboard LEDs are propagated by default like the following example:
>> > + *
>> > + * VT keyboard numlock trigger
>> > + * -> vt::numl VT LED
>> > + * -> vt-numl VT trigger
>>
>> Nitpick: What's the reason for the syntax difference? "vt-numl" vs. "vt::numl"
>
> vt::numl is a clear LED classification convention. For triggers, I don't
> see a clear convention, but at least I have never seen "::", only "-".
> That makes me realize that for keyboard triggers I haven't introduced a
> prefix, and only used "scrollock", "numlock", etc. Perhaps
> "kbd-scrollock" etc. or (in phase with LEDs), "kbd::scrollock" etc.?

I understand. Due to lack of insight, I cannot really comment on that,
sorry. Just wanted to go sure you're aware of that. So feel free to
pick any of them.

Thanks
David


From marc at tensilica.com  Wed Jul 17 11:15:08 2013
From: marc at tensilica.com (Marc Gauthier)
Date: Wed, 17 Jul 2013 08:15:08 -0700
Subject: [Linux-Xtensa] Re: sched_clock always 0 and no process time
 accounting with 3.11-rc1
In-Reply-To: <20130717061925.GC6950@tarshish>
References: <CAMo8BfLO31GgMMA_hENr0xm=qaUz3EVLtaQ8hewiQHdbV+s6sA@mail.gmail.com>
 <20130717061925.GC6950@tarshish>
Message-ID: <8572CFB6-0D88-46F4-B055-7834F8B9BDA5@tensilica.com>

Hi Baruch,

On 2013-07-16, at 11:19 PM, Baruch Siach <baruch at tkos.co.il> wrote:
> -    sched_clock_mask = (1 << bits) - 1;
> +    sched_clock_mask = (1ULL << bits) - 1;

Might it be more efficient to use:

   sched_clock_mask = 0xffffffff >> (32 - bits);

to avoid using 64 bit ints?
(assuming bits > 0, didn't check)

-Marc



From eduardo.valentin at ti.com  Wed Jul 17 11:17:23 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Wed, 17 Jul 2013 11:17:23 -0400
Subject: [RESEND PATCH V1 4/9] arm: dts: flag omap4430 with needs-cooling for
 cpu node
In-Reply-To: <1374074248-31690-1-git-send-email-eduardo.valentin@ti.com>
References: <1374074248-31690-1-git-send-email-eduardo.valentin@ti.com>
Message-ID: <1374074248-31690-5-git-send-email-eduardo.valentin@ti.com>

OMAP4430 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.

This patch adds the flag so that cpufreq-cpu0 driver
loads the cooling device to use cpufreq on OMAP4430.

Cc: "Beno?t Cousson" <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin at ti.com>
---
 arch/arm/boot/dts/omap443x.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..4a4dcc3 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -22,6 +22,7 @@
 				1008000 1375000
 			>;
 			clock-latency = <300000>; /* From legacy driver */
+			needs-cooling; /* make sure we have cpufreq-cooling */
 		};
 	};
 
-- 
1.8.2.1.342.gfa7285d



From Sudeep.KarkadaNagesha at arm.com  Wed Jul 17 11:18:17 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Wed, 17 Jul 2013 16:18:17 +0100
Subject: [RFC PATCH v2 01/15] of: add support for retrieving cpu node
 for a given logical cpu index
In-Reply-To: <51E6AF49.20403@gmail.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374069984-20567-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <51E6AF49.20403@gmail.com>
Message-ID: <51E6B5B9.4090506@arm.com>

On 17/07/13 15:50, Rob Herring wrote:
> On 07/17/2013 09:06 AM, Sudeep.KarkadaNagesha at arm.com wrote:
>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>>
>> Currently different drivers requiring to access cpu device node are
>> parsing the device tree themselves. Since the ordering in the DT need
>> not match the logical cpu ordering, the parsing logic needs to consider
>> that. However, this has resulted in lots of code duplication and in some
>> cases even incorrect logic.
>>
>> It's better to consolidate them by adding support for getting cpu
>> device node for a given logical cpu index in DT core library. However
>> logical to physical index mapping can be architecture specific.
>>
>> This patch adds of_get_cpu_node to retrieve a cpu device node for a
>> given logical cpu index. The default matching of the physical id to the
>> logical cpu index can be overridden by architecture specific code.
>>
>> It is recommended to use these helper function only in pre-SMP/early
>> initialisation stages to retrieve CPU device node pointers in logical
>> ordering. Once the cpu devices are registered, it can be retrieved easily
>> from cpu device of_node which avoids unnecessary parsing and matching.
>>
>> Cc: Rob Herring <rob.herring at calxeda.com>
>> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> One comment below, but otherwise for patches 1-4, 8 and 9:
> 
> Acked-by: Rob Herring <rob.herring at calxeda.com>
> 
> Also, patch 3 needs to come before patch 2 or the matching will be wrong
> if patch 3 is not applied.
Ah, correct will fix it in next version.

> 
>> ---
>>  drivers/of/base.c  | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  include/linux/of.h |  5 +++++
>>  2 files changed, 71 insertions(+)
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index 5c54279..363b8f9 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -230,6 +230,72 @@ const void *of_get_property(const struct device_node *np, const char *name,
>>  }
>>  EXPORT_SYMBOL(of_get_property);
>>  
>> +/*
>> + * arch_match_cpu_phys_id - Match the given logical CPU and physical id
>> + *
>> + * @cpu: logical index of a cpu
>> + * @phys_id: physical identifier of a cpu
>> + *
>> + * CPU logical to physical index mapping is architecure specific.
>> + * However this __weak function provides a default match of physical
>> + * id to logical cpu index.
>> + *
>> + * Returns 1 if the physical identifier and the logical index correspond
>> + * to the same cpu, 0 otherwise.
>> + */
>> +int __weak arch_match_cpu_phys_id(int cpu, u64 phys_id)
>> +{
>> +	return (u32)phys_id == cpu;
>> +}
>> +
>> +/**
>> + * of_get_cpu_node - Get device node associated with the given logical CPU
>> + *
>> + * @cpu: CPU number(logical index) for which device node is required
>> + *
>> + * The main purpose of this function is to retrieve the device node for the
>> + * given logical CPU index. It should be used to intialise the of_node in
>> + * cpu device. Once of_node in cpu device is populated, all the further
>> + * references can use that instead.
>> + *
>> + * CPU logical to physical index mapping is architecure specific and is built
>> + * before booting secondary cores. This function uses arch_match_cpu_phys_id
>> + * which can be overridden by architecture specific implementation.
>> + *
>> + * Returns a node pointer for the logical cpu if found, else NULL.
>> + */
>> +struct device_node *of_get_cpu_node(int cpu)
>> +{
>> +	struct device_node *cpun, *cpus;
>> +	const u32 *cell;
>> +	u64 hwid;
>> +	int ac, prop_len;
>> +
>> +	cpus = of_find_node_by_path("/cpus");
>> +	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
> 
> What happens on a system with no /cpus nodes? Seems like this is another
> case of adding new warnings to existing working systems.
> 
> I'd replace all the WARN's with a single pr_warn on any errors below.
> For missing /cpus, I would just silently return.

Ah, forgot recent discussions on this, will fix it.

Regards,
Sudeep



From linux at arm.linux.org.uk  Wed Jul 17 11:18:16 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 16:18:16 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabled
In-Reply-To: <20130717151148.GM24642@n2100.arm.linux.org.uk>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
 <20130717151148.GM24642@n2100.arm.linux.org.uk>
Message-ID: <20130717151816.GN24642@n2100.arm.linux.org.uk>

On Wed, Jul 17, 2013 at 04:11:48PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 02:25:38PM +0100, Stefano Stabellini wrote:
> > On Mon, 15 Jul 2013, Julien Grall wrote:
> > > Even if uncompress debug is disabled, some board will continue to print
> > > information during uncompress step.
> > 
> > Are you talking about DEBUG_UNCOMPRESS?
> > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > some board will continue to print information during the uncompress step"?
> > 
> > Isn't this a bug in the platform specific code that should be fixed anyway?
> 
> Hang on, let's be clear what's going on here.
> 
> 1. The normal output from the decompressor is *not* debugging.  By that
>    I mean the "Uncompressing kernel... done" message.  That is part of
>    user output.
> 
> 2. In non-multiplatform environments, the decompressor will normally use
>    the putc/flush functions found in arch/arm/mach-*/include/mach/uncompress.h
>    to implement its output, irrespective of the DEBUG_UNCOMPRESS setting.
>    (An interesting point is that DEBUG_UNCOMPRESS really should depend on
>    MULTIPLATFORM so that this point is explicit - the option requires
>    MULTIPLATFORM to be set.)
> 
> 3. DEBUG_UNCOMPRESS allows the functions which we've implemented for LL
>    debug to be re-used for decompressor output.
> 
> 4. When DEBUG_UNCOMPRESS is not set in a multiplatform kernel, the
>    decompressors putc() and flush() functions are stubbed out.
> 
> So, it's quite right that you get output from the decompressor even when
> DEBUG_UNCOMPRESS is not set.  There's no problem with that.

Does this patch help to explain this?

 arch/arm/Kconfig.debug |   14 ++++++++++++--
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e401a76..583f4a0 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -804,9 +804,19 @@ config DEBUG_LL_INCLUDE
 
 config DEBUG_UNCOMPRESS
 	bool
-	default y if ARCH_MULTIPLATFORM && DEBUG_LL && \
-		     !DEBUG_OMAP2PLUS_UART && \
+	depends on ARCH_MULTIPLATFORM
+	default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \
 		     !DEBUG_TEGRA_UART
+	help
+	  This option influences the normal decompressor output only for
+	  multiplatform kernels.  Normally, multiplatform kernels disable
+	  decompressor output because it is not possible to know where to
+	  send the decompressor output.
+
+	  When this option is set, the selected DEBUG_LL output method
+	  will be re-used for normal decompressor output on multiplatform
+	  kernels.
+	  
 
 config UNCOMPRESS_INCLUDE
 	string


From sergei.shtylyov at cogentembedded.com  Wed Jul 17 11:18:37 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Jul 2013 19:18:37 +0400
Subject: [PATCH 1/3] ASoC: bt-sco: enable OF support
In-Reply-To: <1374041536-27643-1-git-send-email-Baohua.Song@csr.com>
References: <1374041536-27643-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <51E6B5CD.1010001@cogentembedded.com>

Hello.

On 17-07-2013 10:12, Barry Song wrote:

> From: Rongjun Ying <Rongjun.Ying at csr.com>

> this makes users be able to add a bt-sco node in dts instead of
> hardcoding a platform device in mach.

> Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
> Signed-off-by: Barry Song <Baohua.Song at csr.com>
> ---
>   sound/soc/codecs/bt-sco.c | 11 +++++++++++
>   1 file changed, 11 insertions(+)

> diff --git a/sound/soc/codecs/bt-sco.c b/sound/soc/codecs/bt-sco.c
> index a081d9f..39e7ebe 100644
> --- a/sound/soc/codecs/bt-sco.c
> +++ b/sound/soc/codecs/bt-sco.c
[...]
> @@ -58,6 +66,9 @@ static struct platform_driver bt_sco_driver = {
>   	.driver = {
>   		.name = "bt-sco",
>   		.owner = THIS_MODULE,
> +#ifdef CONFIG_OF
> +		.of_match_table = bt_sco_of_match,
> +#endif

		.of_match_table = of_match_ptr(bt_sco_of_match),

will get rid of #ifdef here.

WBR, Sergei



From eduardo.valentin at ti.com  Wed Jul 17 11:17:26 2013
From: eduardo.valentin at ti.com (Eduardo Valentin)
Date: Wed, 17 Jul 2013 11:17:26 -0400
Subject: [RESEND PATCH V1 7/9] arm: dts: add omap4430 thermal data
In-Reply-To: <1374074248-31690-1-git-send-email-eduardo.valentin@ti.com>
References: <1374074248-31690-1-git-send-email-eduardo.valentin@ti.com>
Message-ID: <1374074248-31690-8-git-send-email-eduardo.valentin@ti.com>

This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.

Cc: "Beno?t Cousson" <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: linux-omap at vger.kernel.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin at ti.com>
---
 arch/arm/boot/dts/omap443x.dtsi | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index 4a4dcc3..27f0e0f 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -8,6 +8,7 @@
  * kind, whether express or implied.
  */
 
+#include <dt-bindings/thermal/thermal.h>
 #include "omap4.dtsi"
 
 / {
@@ -27,8 +28,34 @@
 	};
 
 	bandgap {
-		reg = <0x4a002260 0x4
-		       0x4a00232C 0x4>;
+		reg = <0x4a002260 0x4 0x4a00232C 0x4>;
 		compatible = "ti,omap4430-bandgap";
+		thermal_zone {
+			type = "CPU";
+			mask = <0x03>; /* trips writability */
+			passive_delay = <250>; /* milliseconds */
+			polling_delay = <1000>; /* milliseconds */
+			governor = "step_wise";
+			trips {
+				alert at 100000{
+					temperature = <100000>; /* milliCelsius */
+					hysteresis = <2000>; /* milliCelsius */
+					type = <THERMAL_TRIP_PASSIVE>;
+				};
+				crit at 125000{
+					temperature = <125000>; /* milliCelsius */
+					hysteresis = <2000>; /* milliCelsius */
+					type = <THERMAL_TRIP_CRITICAL>;
+				};
+			};
+			bind_params {
+				action at 0{
+					cooling_device = "thermal-cpufreq";
+					weight = <100>; /* percentage */
+					mask = <0x01>;
+					/* no limits, using defaults */
+				};
+			};
+		};
 	};
 };
-- 
1.8.2.1.342.gfa7285d



From linux at arm.linux.org.uk  Wed Jul 17 11:24:44 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 16:24:44 +0100
Subject: [Linux-Xtensa] Re: sched_clock always 0 and no process time
 accounting with 3.11-rc1
In-Reply-To: <8572CFB6-0D88-46F4-B055-7834F8B9BDA5@tensilica.com>
References: <CAMo8BfLO31GgMMA_hENr0xm=qaUz3EVLtaQ8hewiQHdbV+s6sA@mail.gmail.com>
 <20130717061925.GC6950@tarshish>
 <8572CFB6-0D88-46F4-B055-7834F8B9BDA5@tensilica.com>
Message-ID: <20130717152443.GO24642@n2100.arm.linux.org.uk>

On Wed, Jul 17, 2013 at 08:15:08AM -0700, Marc Gauthier wrote:
> Hi Baruch,
> 
> On 2013-07-16, at 11:19 PM, Baruch Siach <baruch at tkos.co.il> wrote:
> > -    sched_clock_mask = (1 << bits) - 1;
> > +    sched_clock_mask = (1ULL << bits) - 1;
> 
> Might it be more efficient to use:
> 
>    sched_clock_mask = 0xffffffff >> (32 - bits);
> 
> to avoid using 64 bit ints?
> (assuming bits > 0, didn't check)

bits being 0 would be rather silly (it implies a mask of zero, and therefore
no bits available for the clock.)  We could modify the BUG_ON() above to
make that point, or add it as commentry against the function.

Given that, and that sched_clock_mask is a u32, then I agree with you - the
above would be a better way to do this.  Personally, I'd suggest ~0u rather
than 0xffffffff because its less typing.


From samuel.thibault at ens-lyon.org  Wed Jul 17 11:29:16 2013
From: samuel.thibault at ens-lyon.org (Samuel Thibault)
Date: Wed, 17 Jul 2013 17:29:16 +0200
Subject: [PATCHv2] Route kbd LEDs through the generic LEDs layer
Message-ID: <20130717152916.GI5883@type.bordeaux.inria.fr>

This permits to reassign keyboard LEDs to something else than keyboard "leds"
state, by adding keyboard led and modifier triggers connected to a series
of VT input LEDs, themselves connected to VT input triggers, which
per-input device LEDs use by default.  Userland can thus easily change the LED
behavior of (a priori) all input devices, or of particular input devices.

This also permits to fix #7063 from userland by using a modifier to implement
proper CapsLock behavior and have the keyboard caps lock led show that modifier
state.

Signed-off-by: Samuel Thibault <samuel.thibault at ens-lyon.org>
[ebroder at mokafive.com: Rebased to 3.2-rc1 or so, cleaned up some includes, and fixed some constants]
Signed-off-by: Evan Broder <evan at ebroder.net>
Tested-by: Pavel Machek <pavel at ucw.cz>
Acked-by: Peter Korsgaard <jacmet at sunsite.dk>

---

Difference from v1:
- address style comments
- prepend keyboard triggers with "kbd-"

--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -2,9 +2,6 @@
 LED handling under Linux
 ========================
 
-If you're reading this and thinking about keyboard leds, these are
-handled by the input subsystem and the led class is *not* needed.
-
 In its simplest form, the LED class just allows control of LEDs from
 userspace. LEDs appear in /sys/class/leds/. The maximum brightness of the
 LED is defined in max_brightness file. The brightness file will set the brightness
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -708,6 +708,9 @@ static void input_disconnect_device(stru
 		handle->open = 0;
 
 	spin_unlock_irq(&dev->event_lock);
+
+	if (is_event_supported(EV_LED, dev->evbit, EV_MAX))
+		input_led_disconnect(dev);
 }
 
 /**
@@ -2092,6 +2095,9 @@ int input_register_device(struct input_d
 
 	list_add_tail(&dev->node, &input_dev_list);
 
+	if (is_event_supported(EV_LED, dev->evbit, EV_MAX))
+		input_led_connect(dev);
+
 	list_for_each_entry(handler, &input_handler_list, node)
 		input_attach_handler(dev, handler);
 
--- a/drivers/input/Kconfig
+++ b/drivers/input/Kconfig
@@ -178,6 +178,15 @@ comment "Input Device Drivers"
 
 source "drivers/input/keyboard/Kconfig"
 
+config INPUT_LEDS
+	tristate "LED Support"
+	depends on LEDS_CLASS
+	select LEDS_TRIGGERS
+	default y
+	help
+	  This option enables support for LEDs on keyboards managed
+	  by the input layer.
+
 source "drivers/input/mouse/Kconfig"
 
 source "drivers/input/joystick/Kconfig"
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_INPUT_MOUSEDEV)	+= mousedev
 obj-$(CONFIG_INPUT_JOYDEV)	+= joydev.o
 obj-$(CONFIG_INPUT_EVDEV)	+= evdev.o
 obj-$(CONFIG_INPUT_EVBUG)	+= evbug.o
+obj-$(CONFIG_INPUT_LEDS)	+= leds.o
 
 obj-$(CONFIG_INPUT_KEYBOARD)	+= keyboard/
 obj-$(CONFIG_INPUT_MOUSE)	+= mouse/
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -11,9 +11,6 @@ menuconfig NEW_LEDS
 	  Say Y to enable Linux LED support.  This allows control of supported
 	  LEDs from both userspace and optionally, by kernel events (triggers).
 
-	  This is not related to standard keyboard LEDs which are controlled
-	  via the input system.
-
 if NEW_LEDS
 
 config LEDS_CLASS
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -13,6 +13,10 @@ config VT
 	bool "Virtual terminal" if EXPERT
 	depends on !S390 && !UML
 	select INPUT
+	select NEW_LEDS
+	select LEDS_CLASS
+	select LEDS_TRIGGERS
+	select INPUT_LEDS
 	default y
 	---help---
 	  If you say Y here, you will get support for terminal devices with
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -33,6 +33,7 @@
 #include <linux/string.h>
 #include <linux/init.h>
 #include <linux/slab.h>
+#include <linux/leds.h>
 
 #include <linux/kbd_kern.h>
 #include <linux/kbd_diacr.h>
@@ -130,6 +131,7 @@ static char rep;					/* flag telling cha
 static int shift_state = 0;
 
 static unsigned char ledstate = 0xff;			/* undefined */
+static unsigned char lockstate = 0xff;			/* undefined */
 static unsigned char ledioctl;
 
 static struct ledptr {
@@ -967,6 +969,41 @@ static void k_brl(struct vc_data *vc, un
 	}
 }
 
+/* We route VT keyboard "leds" through triggers */
+static void kbd_ledstate_trigger_activate(struct led_classdev *cdev);
+
+static struct led_trigger ledtrig_ledstate[] = {
+#define DEFINE_LEDSTATE_TRIGGER(kbd_led, nam) \
+	[kbd_led] = { \
+		.name = nam, \
+		.activate = kbd_ledstate_trigger_activate, \
+	}
+	DEFINE_LEDSTATE_TRIGGER(VC_SCROLLOCK, "kbd-scrollock"),
+	DEFINE_LEDSTATE_TRIGGER(VC_NUMLOCK,   "kbd-numlock"),
+	DEFINE_LEDSTATE_TRIGGER(VC_CAPSLOCK,  "kbd-capslock"),
+	DEFINE_LEDSTATE_TRIGGER(VC_KANALOCK,  "kbd-kanalock"),
+#undef DEFINE_LEDSTATE_TRIGGER
+};
+
+static void kbd_lockstate_trigger_activate(struct led_classdev *cdev);
+
+static struct led_trigger ledtrig_lockstate[] = {
+#define DEFINE_LOCKSTATE_TRIGGER(kbd_led, nam) \
+	[kbd_led] = { \
+		.name = nam, \
+		.activate = kbd_lockstate_trigger_activate, \
+	}
+	DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTLOCK,  "kbd-shiftlock"),
+	DEFINE_LOCKSTATE_TRIGGER(VC_ALTGRLOCK,  "kbd-altgrlock"),
+	DEFINE_LOCKSTATE_TRIGGER(VC_CTRLLOCK,   "kbd-ctrllock"),
+	DEFINE_LOCKSTATE_TRIGGER(VC_ALTLOCK,    "kbd-altlock"),
+	DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTLLOCK, "kbd-shiftllock"),
+	DEFINE_LOCKSTATE_TRIGGER(VC_SHIFTRLOCK, "kbd-shiftrlock"),
+	DEFINE_LOCKSTATE_TRIGGER(VC_CTRLLLOCK,  "kbd-ctrlllock"),
+	DEFINE_LOCKSTATE_TRIGGER(VC_CTRLRLOCK,  "kbd-ctrlrlock"),
+#undef DEFINE_LOCKSTATE_TRIGGER
+};
+
 /*
  * The leds display either (i) the status of NumLock, CapsLock, ScrollLock,
  * or (ii) whatever pattern of lights people want to show using KDSETLED,
@@ -1002,6 +1039,7 @@ static inline unsigned char getleds(void
 
 	leds = kbd->ledflagstate;
 
+	/* TODO: should be replaced by a LED trigger */
 	if (kbd->ledmode == LED_SHOW_MEM) {
 		for (i = 0; i < 3; i++)
 			if (ledptrs[i].valid) {
@@ -1014,18 +1052,25 @@ static inline unsigned char getleds(void
 	return leds;
 }
 
-static int kbd_update_leds_helper(struct input_handle *handle, void *data)
+/* Called on trigger connection, to set initial state */
+static void kbd_ledstate_trigger_activate(struct led_classdev *cdev)
 {
-	unsigned char leds = *(unsigned char *)data;
+	struct led_trigger *trigger = cdev->trigger;
+	int led = trigger - ledtrig_ledstate;
 
-	if (test_bit(EV_LED, handle->dev->evbit)) {
-		input_inject_event(handle, EV_LED, LED_SCROLLL, !!(leds & 0x01));
-		input_inject_event(handle, EV_LED, LED_NUML,    !!(leds & 0x02));
-		input_inject_event(handle, EV_LED, LED_CAPSL,   !!(leds & 0x04));
-		input_inject_event(handle, EV_SYN, SYN_REPORT, 0);
-	}
+	tasklet_disable(&keyboard_tasklet);
+	led_trigger_event(trigger, ledstate & (1 << led) ? LED_FULL : LED_OFF);
+	tasklet_enable(&keyboard_tasklet);
+}
 
-	return 0;
+static void kbd_lockstate_trigger_activate(struct led_classdev *cdev)
+{
+	struct led_trigger *trigger = cdev->trigger;
+	int led = trigger - ledtrig_lockstate;
+
+	tasklet_disable(&keyboard_tasklet);
+	led_trigger_event(trigger, lockstate & (1 << led) ? LED_FULL : LED_OFF);
+	tasklet_enable(&keyboard_tasklet);
 }
 
 /**
@@ -1114,16 +1159,29 @@ static void kbd_bh(unsigned long dummy)
 {
 	unsigned char leds;
 	unsigned long flags;
-	
+	int i;
+
 	spin_lock_irqsave(&led_lock, flags);
 	leds = getleds();
 	spin_unlock_irqrestore(&led_lock, flags);
 
 	if (leds != ledstate) {
-		input_handler_for_each_handle(&kbd_handler, &leds,
-					      kbd_update_leds_helper);
+		for (i = 0; i < ARRAY_SIZE(ledtrig_ledstate); i++)
+			if ((leds ^ ledstate) & (1 << i))
+				led_trigger_event(&ledtrig_ledstate[i],
+						leds & (1 << i)
+						? LED_FULL : LED_OFF);
 		ledstate = leds;
 	}
+
+	if (kbd->lockstate != lockstate) {
+		for (i = 0; i < ARRAY_SIZE(ledtrig_lockstate); i++)
+			if ((kbd->lockstate ^ lockstate) & (1 << i))
+				led_trigger_event(&ledtrig_lockstate[i],
+						kbd->lockstate & (1 << i)
+						? LED_FULL : LED_OFF);
+		lockstate = kbd->lockstate;
+	}
 }
 
 DECLARE_TASKLET_DISABLED(keyboard_tasklet, kbd_bh, 0);
@@ -1461,20 +1519,6 @@ static void kbd_disconnect(struct input_
 	kfree(handle);
 }
 
-/*
- * Start keyboard handler on the new keyboard by refreshing LED state to
- * match the rest of the system.
- */
-static void kbd_start(struct input_handle *handle)
-{
-	tasklet_disable(&keyboard_tasklet);
-
-	if (ledstate != 0xff)
-		kbd_update_leds_helper(handle, &ledstate);
-
-	tasklet_enable(&keyboard_tasklet);
-}
-
 static const struct input_device_id kbd_ids[] = {
 	{
 		.flags = INPUT_DEVICE_ID_MATCH_EVBIT,
@@ -1496,7 +1540,6 @@ static struct input_handler kbd_handler
 	.match		= kbd_match,
 	.connect	= kbd_connect,
 	.disconnect	= kbd_disconnect,
-	.start		= kbd_start,
 	.name		= "kbd",
 	.id_table	= kbd_ids,
 };
@@ -1520,6 +1563,20 @@ int __init kbd_init(void)
 	if (error)
 		return error;
 
+	for (i = 0; i < ARRAY_SIZE(ledtrig_ledstate); i++) {
+		error = led_trigger_register(&ledtrig_ledstate[i]);
+		if (error)
+			pr_err("error %d while registering trigger %s\n",
+					error, ledtrig_ledstate[i].name);
+	}
+
+	for (i = 0; i < ARRAY_SIZE(ledtrig_lockstate); i++) {
+		error = led_trigger_register(&ledtrig_lockstate[i]);
+		if (error)
+			pr_err("error %d while registering trigger %s\n",
+					error, ledtrig_lockstate[i].name);
+	}
+
 	tasklet_enable(&keyboard_tasklet);
 	tasklet_schedule(&keyboard_tasklet);
 
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -164,6 +164,8 @@ struct input_dev {
 	unsigned long snd[BITS_TO_LONGS(SND_CNT)];
 	unsigned long sw[BITS_TO_LONGS(SW_CNT)];
 
+	struct led_classdev *leds;
+
 	int (*open)(struct input_dev *dev);
 	void (*close)(struct input_dev *dev);
 	int (*flush)(struct input_dev *dev, struct file *file);
@@ -531,4 +533,22 @@ int input_ff_erase(struct input_dev *dev
 int input_ff_create_memless(struct input_dev *dev, void *data,
 		int (*play_effect)(struct input_dev *, void *, struct ff_effect *));
 
+#ifdef CONFIG_INPUT_LEDS
+
+int input_led_connect(struct input_dev *dev);
+void input_led_disconnect(struct input_dev *dev);
+
+#else
+
+int input_led_connect(struct input_dev *dev)
+{
+	return 0;
+}
+
+void input_led_disconnect(struct input_dev *dev)
+{
+}
+
+#endif
+
 #endif
--- /dev/null
+++ b/drivers/input/leds.c
@@ -0,0 +1,247 @@
+/*
+ * LED support for the input layer
+ *
+ * Copyright 2010-2013 Samuel Thibault <samuel.thibault at ens-lyon.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/leds.h>
+#include <linux/input.h>
+
+/*
+ * Keyboard LEDs are propagated by default like the following example:
+ *
+ * VT keyboard numlock trigger
+ * -> vt::numl VT LED
+ * -> vt-numl VT trigger
+ * -> per-device inputX::numl LED
+ *
+ * Userland can however choose the trigger for the vt::numl LED, or
+ * independently choose the trigger for any inputx::numl LED.
+ *
+ *
+ * VT LED classes and triggers are registered on-demand according to
+ * existing LED devices
+ */
+
+/* Handler for VT LEDs, just triggers the corresponding VT trigger. */
+static void vt_led_set(struct led_classdev *cdev,
+			  enum led_brightness brightness);
+static struct led_classdev vt_leds[LED_CNT] = {
+#define DEFINE_INPUT_LED(vt_led, nam, deftrig) \
+	[vt_led] = { \
+		.name = "vt::"nam, \
+		.max_brightness = 1, \
+		.brightness_set = vt_led_set, \
+		.default_trigger = deftrig, \
+	}
+/* Default triggers for the VT LEDs just correspond to the legacy
+ * usage. */
+	DEFINE_INPUT_LED(LED_NUML, "numl", "kbd-numlock"),
+	DEFINE_INPUT_LED(LED_CAPSL, "capsl", "kbd-capslock"),
+	DEFINE_INPUT_LED(LED_SCROLLL, "scrolll", "kbd-scrollock"),
+	DEFINE_INPUT_LED(LED_COMPOSE, "compose", NULL),
+	DEFINE_INPUT_LED(LED_KANA, "kana", "kbd-kanalock"),
+	DEFINE_INPUT_LED(LED_SLEEP, "sleep", NULL),
+	DEFINE_INPUT_LED(LED_SUSPEND, "suspend", NULL),
+	DEFINE_INPUT_LED(LED_MUTE, "mute", NULL),
+	DEFINE_INPUT_LED(LED_MISC, "misc", NULL),
+	DEFINE_INPUT_LED(LED_MAIL, "mail", NULL),
+	DEFINE_INPUT_LED(LED_CHARGING, "charging", NULL),
+};
+static const char *const vt_led_names[LED_CNT] = {
+	[LED_NUML] = "numl",
+	[LED_CAPSL] = "capsl",
+	[LED_SCROLLL] = "scrolll",
+	[LED_COMPOSE] = "compose",
+	[LED_KANA] = "kana",
+	[LED_SLEEP] = "sleep",
+	[LED_SUSPEND] = "suspend",
+	[LED_MUTE] = "mute",
+	[LED_MISC] = "misc",
+	[LED_MAIL] = "mail",
+	[LED_CHARGING] = "charging",
+};
+/* Handler for hotplug initialization */
+static void vt_led_trigger_activate(struct led_classdev *cdev);
+/* VT triggers */
+static struct led_trigger vt_led_triggers[LED_CNT] = {
+#define DEFINE_INPUT_LED_TRIGGER(vt_led, nam) \
+	[vt_led] = { \
+		.name = "vt-"nam, \
+		.activate = vt_led_trigger_activate, \
+	}
+	DEFINE_INPUT_LED_TRIGGER(LED_NUML, "numl"),
+	DEFINE_INPUT_LED_TRIGGER(LED_CAPSL, "capsl"),
+	DEFINE_INPUT_LED_TRIGGER(LED_SCROLLL, "scrolll"),
+	DEFINE_INPUT_LED_TRIGGER(LED_COMPOSE, "compose"),
+	DEFINE_INPUT_LED_TRIGGER(LED_KANA, "kana"),
+	DEFINE_INPUT_LED_TRIGGER(LED_SLEEP, "sleep"),
+	DEFINE_INPUT_LED_TRIGGER(LED_SUSPEND, "suspend"),
+	DEFINE_INPUT_LED_TRIGGER(LED_MUTE, "mute"),
+	DEFINE_INPUT_LED_TRIGGER(LED_MISC, "misc"),
+	DEFINE_INPUT_LED_TRIGGER(LED_MAIL, "mail"),
+	DEFINE_INPUT_LED_TRIGGER(LED_CHARGING, "charging"),
+};
+
+/* Lock for registration coherency */
+static DEFINE_MUTEX(vt_led_registered_lock);
+
+/* Which VT LED classes and triggers are registered */
+static unsigned long vt_led_registered[BITS_TO_LONGS(LED_CNT)];
+
+/* Number of input devices having each LED */
+static int vt_led_references[LED_CNT];
+
+/* VT LED state change, tell the VT trigger.  */
+static void vt_led_set(struct led_classdev *cdev,
+			  enum led_brightness brightness)
+{
+	int led = cdev - vt_leds;
+
+	led_trigger_event(&vt_led_triggers[led], !!brightness);
+}
+
+/* LED state change for some keyboard, notify that keyboard.  */
+static void perdevice_input_led_set(struct led_classdev *cdev,
+			  enum led_brightness brightness)
+{
+	struct input_dev *dev;
+	struct led_classdev *leds;
+	int led;
+
+	dev = cdev->dev->platform_data;
+	if (!dev)
+		/* Still initializing */
+		return;
+	leds = dev->leds;
+	led = cdev - leds;
+
+	input_event(dev, EV_LED, led, !!brightness);
+	input_event(dev, EV_SYN, SYN_REPORT, 0);
+}
+
+/* Keyboard hotplug, initialize its LED status */
+static void vt_led_trigger_activate(struct led_classdev *cdev)
+{
+	struct led_trigger *trigger = cdev->trigger;
+	int led = trigger - vt_led_triggers;
+
+	if (cdev->brightness_set)
+		cdev->brightness_set(cdev, vt_leds[led].brightness);
+}
+
+/* Free led stuff from input device, used at abortion and disconnection.  */
+static void input_led_delete(struct input_dev *dev)
+{
+	if (dev) {
+		struct led_classdev *leds = dev->leds;
+		if (leds) {
+			int i;
+			for (i = 0; i < LED_CNT; i++)
+				kfree(leds[i].name);
+			kfree(leds);
+			dev->leds = NULL;
+		}
+	}
+}
+
+/* A new input device with potential LEDs to connect.  */
+int input_led_connect(struct input_dev *dev)
+{
+	int i, error = 0;
+	struct led_classdev *leds;
+
+	dev->leds = leds = kzalloc(sizeof(*leds) * LED_CNT, GFP_KERNEL);
+	if (!dev->leds)
+		return -ENOMEM;
+
+	/* lazily register missing VT LEDs */
+	mutex_lock(&vt_led_registered_lock);
+	for (i = 0; i < LED_CNT; i++)
+		if (vt_leds[i].name && test_bit(i, dev->ledbit)) {
+			if (!vt_led_references[i]) {
+				led_trigger_register(&vt_led_triggers[i]);
+				/* This keyboard is first to have led i,
+				 * try to register it */
+				if (!led_classdev_register(NULL, &vt_leds[i]))
+					vt_led_references[i] = 1;
+				else
+					led_trigger_unregister(&vt_led_triggers[i]);
+			} else
+				vt_led_references[i]++;
+		}
+	mutex_unlock(&vt_led_registered_lock);
+
+	/* and register this device's LEDs */
+	for (i = 0; i < LED_CNT; i++)
+		if (vt_leds[i].name && test_bit(i, dev->ledbit)) {
+			leds[i].name = kasprintf(GFP_KERNEL, "%s::%s",
+						dev_name(&dev->dev),
+						vt_led_names[i]);
+			if (!leds[i].name) {
+				error = -ENOMEM;
+				goto err;
+			}
+			leds[i].max_brightness = 1;
+			leds[i].brightness_set = perdevice_input_led_set;
+			leds[i].default_trigger = vt_led_triggers[i].name;
+		}
+
+	/* No issue so far, we can register for real.  */
+	for (i = 0; i < LED_CNT; i++)
+		if (leds[i].name) {
+			led_classdev_register(&dev->dev, &leds[i]);
+			leds[i].dev->platform_data = dev;
+			perdevice_input_led_set(&leds[i],
+					vt_leds[i].brightness);
+		}
+
+	return 0;
+
+err:
+	input_led_delete(dev);
+	return error;
+}
+
+/* Disconnected input device. Clean it, and deregister now-useless VT LEDs
+ * and triggers.  */
+extern void input_led_disconnect(struct input_dev *dev)
+{
+	int i;
+	struct led_classdev *leds = dev->leds;
+
+	for (i = 0; i < LED_CNT; i++)
+		if (leds[i].name)
+			led_classdev_unregister(&leds[i]);
+
+	input_led_delete(dev);
+
+	mutex_lock(&vt_led_registered_lock);
+	for (i = 0; i < LED_CNT; i++) {
+		if (!vt_leds[i].name || !test_bit(i, dev->ledbit))
+			continue;
+
+		vt_led_references[i]--;
+		if (vt_led_references[i]) {
+			/* Still some devices needing it */
+			continue;
+		}
+
+		led_classdev_unregister(&vt_leds[i]);
+		led_trigger_unregister(&vt_led_triggers[i]);
+		clear_bit(i, vt_led_registered);
+	}
+	mutex_unlock(&vt_led_registered_lock);
+}
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("User LED support for input layer");
+MODULE_AUTHOR("Samuel Thibault <samuel.thibault at ens-lyon.org>");


From tony at atomide.com  Wed Jul 17 11:32:49 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 17 Jul 2013 08:32:49 -0700
Subject: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for
 uart3/4
In-Reply-To: <1374061312-25469-4-git-send-email-grygorii.strashko@ti.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
 <1374061312-25469-4-git-send-email-grygorii.strashko@ti.com>
Message-ID: <20130717153248.GI7656@atomide.com>

* Grygorii Strashko <grygorii.strashko at ti.com> [130717 04:49]:
> Add dynamic "active"/"idle" pin states for uart3/4 which will be applied
> when uart3/4 state is switched from active to idle and back by Runtime
> PM or during system suspend.

This is good for testing code, but should not be merged because
omap4 has the iopad wake-ups available for uarts. So those can
be always enabled.
 
> --- a/arch/arm/boot/dts/omap4-sdp.dts
> +++ b/arch/arm/boot/dts/omap4-sdp.dts
> @@ -181,18 +181,40 @@
>  		pinctrl-single,pins = <
>  			0x100 (PIN_INPUT_PULLUP | MUX_MODE0)	/* uart3_cts_rctx.uart3_cts_rctx */
>  			0x102 (PIN_OUTPUT | MUX_MODE0)		/* uart3_rts_sd.uart3_rts_sd */
> -			0x104 (PIN_INPUT | MUX_MODE0)		/* uart3_rx_irrx.uart3_rx_irrx */
>  			0x106 (PIN_OUTPUT | MUX_MODE0)		/* uart3_tx_irtx.uart3_tx_irtx */
>  		>;
>  	};

This just need to become:
		pinctrl-single,pins = <
			...
			0x104 (WAKEUP_EN | PIN_INPUT_MUX_MODE0)	/* uart3_rx_irrx.uart3_rx_irrx */
			...
		>;
		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
	};

And so on. For am33xx you need to remux things to GPIO for the wake-up
events, so you should maybe test on that instead.

Regards,

Tony


From stern at rowland.harvard.edu  Wed Jul 17 11:33:54 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Wed, 17 Jul 2013 11:33:54 -0400 (EDT)
Subject: [PATCH v3 6/7] USB: ohci-at91: add usb_clk for transition to
 common clk framework
In-Reply-To: <1373988136-24622-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <Pine.LNX.4.44L0.1307171131580.1555-100000@iolanthe.rowland.org>

On Tue, 16 Jul 2013, Boris BREZILLON wrote:

> The AT91 PMC (Power Management Controller) provides an USB clock used by
> USB Full Speed host (ohci) and USB Full Speed device (udc).
> The usb drivers (ohci and udc) must configure this clock to 48Mhz.
> This configuration was formely done in mach-at91/clock.c, but this
> implementation will be removed when moving to common clk framework.
> 
> This patch add support for usb clock retrieval and configuration, and is
> backward compatible with the current at91 clk implementation (if usb clk
> is not found, it does not configure/enable the usb clk).

This does not take into account any of the changes you discussed with 
Russell King and me -- it is exactly the same as the previous version.

> @@ -144,6 +150,11 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
>  		goto err2;
>  	}
>  
> +	uclk = clk_get(&pdev->dev, "usb_clk");
> +	if (IS_ERR(uclk)) {
> +		uclk = NULL;
> +		dev_warn(&pdev->dev, "failed to get usb_clk\n");
> +	}
>  	iclk = clk_get(&pdev->dev, "ohci_clk");
>  	if (IS_ERR(iclk)) {
>  		dev_err(&pdev->dev, "failed to get ohci_clk\n");
> @@ -212,10 +223,11 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
>  	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
>  	usb_put_hcd(hcd);
>  
> +	clk_put(uclk);

What will clk_put() do when uclk is NULL?

Alan Stern



From b.brezillon at overkiz.com  Wed Jul 17 11:37:13 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 17:37:13 +0200
Subject: [PATCH v2 24/42] ARM: at91: move at91sam9 boards to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374075433-20170-1-git-send-email-b.brezillon@overkiz.com>

Move at91 clk init from early_init to timer_init for all at91sam9 non dt
boards.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/board-afeb-9260v1.c  |   11 +++++++----
 arch/arm/mach-at91/board-cam60.c        |   13 ++++++++-----
 arch/arm/mach-at91/board-cpu9krea.c     |   12 ++++++++----
 arch/arm/mach-at91/board-dt-sam9.c      |    9 ++++++++-
 arch/arm/mach-at91/board-dt-sama5.c     |    9 ++++++++-
 arch/arm/mach-at91/board-flexibity.c    |   12 ++++++++----
 arch/arm/mach-at91/board-foxg20.c       |   12 +++++++-----
 arch/arm/mach-at91/board-gsia18s.c      |    8 ++------
 arch/arm/mach-at91/board-pcontrol-g20.c |    9 ++-------
 arch/arm/mach-at91/board-qil-a9260.c    |   11 +++++++----
 arch/arm/mach-at91/board-sam9-l9260.c   |   11 +++++++----
 arch/arm/mach-at91/board-sam9260ek.c    |   11 +++++++----
 arch/arm/mach-at91/board-sam9261ek.c    |   15 +++++++++------
 arch/arm/mach-at91/board-sam9263ek.c    |   11 +++++++----
 arch/arm/mach-at91/board-sam9g20ek.c    |   15 +++++++++------
 arch/arm/mach-at91/board-sam9m10g45ek.c |   11 +++++++----
 arch/arm/mach-at91/board-sam9rlek.c     |   11 +++++++----
 arch/arm/mach-at91/board-snapper9260.c  |   12 ++++++++----
 arch/arm/mach-at91/board-stamp9g20.c    |   15 +++++++++------
 arch/arm/mach-at91/stamp9g20.h          |    2 +-
 20 files changed, 136 insertions(+), 84 deletions(-)

diff --git a/arch/arm/mach-at91/board-afeb-9260v1.c b/arch/arm/mach-at91/board-afeb-9260v1.c
index f95e31c..c6849e1 100644
--- a/arch/arm/mach-at91/board-afeb-9260v1.c
+++ b/arch/arm/mach-at91/board-afeb-9260v1.c
@@ -48,10 +48,13 @@
 #include "generic.h"
 
 
-static void __init afeb9260_init_early(void)
+static void __init afeb9260_timer_init(void)
 {
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 /*
@@ -210,10 +213,10 @@ static void __init afeb9260_board_init(void)
 
 MACHINE_START(AFEB9260, "Custom afeb9260 board")
 	/* Maintainer: Sergey Lapin <slapin at ossfans.org> */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= afeb9260_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= afeb9260_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= afeb9260_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-cam60.c b/arch/arm/mach-at91/board-cam60.c
index ade948b..75c89a0 100644
--- a/arch/arm/mach-at91/board-cam60.c
+++ b/arch/arm/mach-at91/board-cam60.c
@@ -46,10 +46,13 @@
 #include "generic.h"
 
 
-static void __init cam60_init_early(void)
+static void __init cam60_timer_init(void)
 {
-	/* Initialize processor: 10 MHz crystal */
-	at91_initialize(10000000);
+	/* Initialize processor: 18.432 MHz crystal */
+	at91_clk_init(10000000);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 /*
@@ -187,10 +190,10 @@ static void __init cam60_board_init(void)
 
 MACHINE_START(CAM60, "KwikByte CAM60")
 	/* Maintainer: KwikByte */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= cam60_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= cam60_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= cam60_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-cpu9krea.c b/arch/arm/mach-at91/board-cpu9krea.c
index 008527e..a88d8ec 100644
--- a/arch/arm/mach-at91/board-cpu9krea.c
+++ b/arch/arm/mach-at91/board-cpu9krea.c
@@ -49,10 +49,14 @@
 #include "sam9_smc.h"
 #include "generic.h"
 
-static void __init cpu9krea_init_early(void)
+
+static void __init cpu9krea_timer_init(void)
 {
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 /*
@@ -374,10 +378,10 @@ MACHINE_START(CPUAT9260, "Eukrea CPU9260")
 MACHINE_START(CPUAT9G20, "Eukrea CPU9G20")
 #endif
 	/* Maintainer: Eric Benard - EUKREA Electromatique */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= cpu9krea_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= cpu9krea_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= cpu9krea_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-dt-sam9.c b/arch/arm/mach-at91/board-dt-sam9.c
index 8db3013..a7ea21f 100644
--- a/arch/arm/mach-at91/board-dt-sam9.c
+++ b/arch/arm/mach-at91/board-dt-sam9.c
@@ -14,6 +14,7 @@
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
+#include <linux/clk-provider.h>
 
 #include <asm/setup.h>
 #include <asm/irq.h>
@@ -26,6 +27,12 @@
 #include "generic.h"
 
 
+static void __init at91sam_dt_timer_init(void)
+{
+	of_clk_init(NULL);
+	at91sam926x_pit_init();
+}
+
 static const struct of_device_id irq_of_match[] __initconst = {
 
 	{ .compatible = "atmel,at91rm9200-aic", .data = at91_aic_of_init },
@@ -49,7 +56,7 @@ static const char *at91_dt_board_compat[] __initdata = {
 
 DT_MACHINE_START(at91sam_dt, "Atmel AT91SAM (Device Tree)")
 	/* Maintainer: Atmel */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= at91sam_dt_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
 	.init_early	= at91_dt_initialize,
diff --git a/arch/arm/mach-at91/board-dt-sama5.c b/arch/arm/mach-at91/board-dt-sama5.c
index ad95f6a..7ad3d96 100644
--- a/arch/arm/mach-at91/board-dt-sama5.c
+++ b/arch/arm/mach-at91/board-dt-sama5.c
@@ -16,6 +16,7 @@
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/phy.h>
+#include <linux/clk-provider.h>
 
 #include <asm/setup.h>
 #include <asm/irq.h>
@@ -27,6 +28,12 @@
 #include "generic.h"
 
 
+static void __init at91sama5_dt_timer_init(void)
+{
+	of_clk_init(NULL);
+	at91sam926x_pit_init();
+}
+
 static const struct of_device_id irq_of_match[] __initconst = {
 
 	{ .compatible = "atmel,sama5d3-aic", .data = at91_aic5_of_init },
@@ -77,7 +84,7 @@ static const char *sama5_dt_board_compat[] __initdata = {
 
 DT_MACHINE_START(sama5_dt, "Atmel SAMA5 (Device Tree)")
 	/* Maintainer: Atmel */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= at91sama5_dt_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic5_handle_irq,
 	.init_early	= at91_dt_initialize,
diff --git a/arch/arm/mach-at91/board-flexibity.c b/arch/arm/mach-at91/board-flexibity.c
index 737c085..f64b47a 100644
--- a/arch/arm/mach-at91/board-flexibity.c
+++ b/arch/arm/mach-at91/board-flexibity.c
@@ -38,10 +38,14 @@
 #include "board.h"
 #include "generic.h"
 
-static void __init flexibity_init_early(void)
+
+static void __init flexibity_timer_init(void)
 {
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 /* USB Host port */
@@ -159,10 +163,10 @@ static void __init flexibity_board_init(void)
 
 MACHINE_START(FLEXIBITY, "Flexibity Connect")
 	/* Maintainer: Maxim Osipov */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= flexibity_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= flexibity_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= flexibity_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-foxg20.c b/arch/arm/mach-at91/board-foxg20.c
index c20a870..c4caeb3 100644
--- a/arch/arm/mach-at91/board-foxg20.c
+++ b/arch/arm/mach-at91/board-foxg20.c
@@ -57,11 +57,13 @@
  * For more info visit: http://www.acmesystems.it/foxg20
  */
 
-
-static void __init foxg20_init_early(void)
+static void __init foxg20_timer_init(void)
 {
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 /*
@@ -262,10 +264,10 @@ static void __init foxg20_board_init(void)
 
 MACHINE_START(ACMENETUSFOXG20, "Acme Systems srl FOX Board G20")
 	/* Maintainer: Sergio Tanzilli */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= foxg20_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= foxg20_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= foxg20_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-gsia18s.c b/arch/arm/mach-at91/board-gsia18s.c
index c1d61d2..4ed7ef4 100644
--- a/arch/arm/mach-at91/board-gsia18s.c
+++ b/arch/arm/mach-at91/board-gsia18s.c
@@ -39,10 +39,6 @@
 #include "gsia18s.h"
 #include "stamp9g20.h"
 
-static void __init gsia18s_init_early(void)
-{
-	stamp9g20_init_early();
-}
 
 /*
  * Two USB Host ports
@@ -574,10 +570,10 @@ static void __init gsia18s_board_init(void)
 }
 
 MACHINE_START(GSIA18S, "GS_IA18_S")
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= stamp9g20_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= gsia18s_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= gsia18s_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-pcontrol-g20.c b/arch/arm/mach-at91/board-pcontrol-g20.c
index 65c0d6b..6602e14 100644
--- a/arch/arm/mach-at91/board-pcontrol-g20.c
+++ b/arch/arm/mach-at91/board-pcontrol-g20.c
@@ -38,11 +38,6 @@
 #include "stamp9g20.h"
 
 
-static void __init pcontrol_g20_init_early(void)
-{
-	stamp9g20_init_early();
-}
-
 static struct sam9_smc_config __initdata pcontrol_smc_config[2] = { {
 	.ncs_read_setup		= 16,
 	.nrd_setup		= 18,
@@ -217,10 +212,10 @@ static void __init pcontrol_g20_board_init(void)
 
 MACHINE_START(PCONTROL_G20, "PControl G20")
 	/* Maintainer: pgsellmann at portner-elektronik.at */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= stamp9g20_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= pcontrol_g20_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= pcontrol_g20_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-qil-a9260.c b/arch/arm/mach-at91/board-qil-a9260.c
index aa3bc9b..b7a9976 100644
--- a/arch/arm/mach-at91/board-qil-a9260.c
+++ b/arch/arm/mach-at91/board-qil-a9260.c
@@ -49,10 +49,13 @@
 #include "generic.h"
 
 
-static void __init ek_init_early(void)
+static void __init ek_timer_init(void)
 {
 	/* Initialize processor: 12.000 MHz crystal */
-	at91_initialize(12000000);
+	at91_clk_init(12000000);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 /*
@@ -257,10 +260,10 @@ static void __init ek_board_init(void)
 
 MACHINE_START(QIL_A9260, "CALAO QIL_A9260")
 	/* Maintainer: calao-systems */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= ek_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= ek_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= ek_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-sam9-l9260.c b/arch/arm/mach-at91/board-sam9-l9260.c
index 43ee4dc..f078f94 100644
--- a/arch/arm/mach-at91/board-sam9-l9260.c
+++ b/arch/arm/mach-at91/board-sam9-l9260.c
@@ -45,10 +45,13 @@
 #include "generic.h"
 
 
-static void __init ek_init_early(void)
+static void __init ek_timer_init(void)
 {
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 /*
@@ -218,10 +221,10 @@ static void __init ek_board_init(void)
 
 MACHINE_START(SAM9_L9260, "Olimex SAM9-L9260")
 	/* Maintainer: Olimex */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= ek_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= ek_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= ek_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-sam9260ek.c b/arch/arm/mach-at91/board-sam9260ek.c
index 0b153c8..2737a5c 100644
--- a/arch/arm/mach-at91/board-sam9260ek.c
+++ b/arch/arm/mach-at91/board-sam9260ek.c
@@ -51,10 +51,13 @@
 #include "generic.h"
 
 
-static void __init ek_init_early(void)
+static void __init ek_timer_init(void)
 {
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 /*
@@ -343,10 +346,10 @@ static void __init ek_board_init(void)
 
 MACHINE_START(AT91SAM9260EK, "Atmel AT91SAM9260-EK")
 	/* Maintainer: Atmel */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= ek_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= ek_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= ek_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-sam9261ek.c b/arch/arm/mach-at91/board-sam9261ek.c
index 473546b..212210e 100644
--- a/arch/arm/mach-at91/board-sam9261ek.c
+++ b/arch/arm/mach-at91/board-sam9261ek.c
@@ -55,10 +55,13 @@
 #include "generic.h"
 
 
-static void __init ek_init_early(void)
+static void __init ek_timer_init(void)
 {
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 /*
@@ -602,20 +605,20 @@ static void __init ek_board_init(void)
 
 MACHINE_START(AT91SAM9261EK, "Atmel AT91SAM9261-EK")
 	/* Maintainer: Atmel */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= ek_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= ek_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= ek_board_init,
 MACHINE_END
 
 MACHINE_START(AT91SAM9G10EK, "Atmel AT91SAM9G10-EK")
 	/* Maintainer: Atmel */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= ek_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= ek_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= ek_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-sam9263ek.c b/arch/arm/mach-at91/board-sam9263ek.c
index 8b4942c..c427d62 100644
--- a/arch/arm/mach-at91/board-sam9263ek.c
+++ b/arch/arm/mach-at91/board-sam9263ek.c
@@ -54,10 +54,13 @@
 #include "generic.h"
 
 
-static void __init ek_init_early(void)
+static void __init ek_timer_init(void)
 {
 	/* Initialize processor: 16.367 MHz crystal */
-	at91_initialize(16367660);
+	at91_clk_init(16367660);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 /*
@@ -443,10 +446,10 @@ static void __init ek_board_init(void)
 
 MACHINE_START(AT91SAM9263EK, "Atmel AT91SAM9263-EK")
 	/* Maintainer: Atmel */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= ek_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= ek_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= ek_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-sam9g20ek.c b/arch/arm/mach-at91/board-sam9g20ek.c
index f9cd1f2..10abb59 100644
--- a/arch/arm/mach-at91/board-sam9g20ek.c
+++ b/arch/arm/mach-at91/board-sam9g20ek.c
@@ -64,10 +64,13 @@ static int inline ek_have_2mmc(void)
 }
 
 
-static void __init ek_init_early(void)
+static void __init ek_timer_init(void)
 {
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 /*
@@ -409,20 +412,20 @@ static void __init ek_board_init(void)
 
 MACHINE_START(AT91SAM9G20EK, "Atmel AT91SAM9G20-EK")
 	/* Maintainer: Atmel */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= ek_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= ek_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= ek_board_init,
 MACHINE_END
 
 MACHINE_START(AT91SAM9G20EK_2MMC, "Atmel AT91SAM9G20-EK 2 MMC Slot Mod")
 	/* Maintainer: Atmel */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= ek_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= ek_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= ek_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-sam9m10g45ek.c b/arch/arm/mach-at91/board-sam9m10g45ek.c
index ef39078..4125b82 100644
--- a/arch/arm/mach-at91/board-sam9m10g45ek.c
+++ b/arch/arm/mach-at91/board-sam9m10g45ek.c
@@ -52,10 +52,13 @@
 #include "generic.h"
 
 
-static void __init ek_init_early(void)
+static void __init ek_timer_init(void)
 {
 	/* Initialize processor: 12.000 MHz crystal */
-	at91_initialize(12000000);
+	at91_clk_init(12000000);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 /*
@@ -502,10 +505,10 @@ static void __init ek_board_init(void)
 
 MACHINE_START(AT91SAM9M10G45EK, "Atmel AT91SAM9M10G45-EK")
 	/* Maintainer: Atmel */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= ek_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= ek_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= ek_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-sam9rlek.c b/arch/arm/mach-at91/board-sam9rlek.c
index 604eecf..1490d91 100644
--- a/arch/arm/mach-at91/board-sam9rlek.c
+++ b/arch/arm/mach-at91/board-sam9rlek.c
@@ -40,10 +40,13 @@
 #include "generic.h"
 
 
-static void __init ek_init_early(void)
+static void __init ek_timer_init(void)
 {
 	/* Initialize processor: 12.000 MHz crystal */
-	at91_initialize(12000000);
+	at91_clk_init(12000000);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 /*
@@ -320,10 +323,10 @@ static void __init ek_board_init(void)
 
 MACHINE_START(AT91SAM9RLEK, "Atmel AT91SAM9RL-EK")
 	/* Maintainer: Atmel */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= ek_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= ek_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= ek_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-snapper9260.c b/arch/arm/mach-at91/board-snapper9260.c
index 3aaa978..afe48fd 100644
--- a/arch/arm/mach-at91/board-snapper9260.c
+++ b/arch/arm/mach-at91/board-snapper9260.c
@@ -41,9 +41,13 @@
 
 #define SNAPPER9260_IO_EXP_GPIO(x)	(NR_BUILTIN_GPIO + (x))
 
-static void __init snapper9260_init_early(void)
+static void __init snapper9260_timer_init(void)
 {
-	at91_initialize(18432000);
+	/* Initialize processor: 18.432 MHz crystal */
+	at91_clk_init(18432000);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 static struct at91_usbh_data __initdata snapper9260_usbh_data = {
@@ -177,10 +181,10 @@ static void __init snapper9260_board_init(void)
 }
 
 MACHINE_START(SNAPPER_9260, "Bluewater Systems Snapper 9260/9G20 module")
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= snapper9260_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= snapper9260_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= snapper9260_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/board-stamp9g20.c b/arch/arm/mach-at91/board-stamp9g20.c
index 869cbec..e4cee53 100644
--- a/arch/arm/mach-at91/board-stamp9g20.c
+++ b/arch/arm/mach-at91/board-stamp9g20.c
@@ -33,10 +33,13 @@
 #include "generic.h"
 
 
-void __init stamp9g20_init_early(void)
+void __init stamp9g20_timer_init(void)
 {
 	/* Initialize processor: 18.432 MHz crystal */
-	at91_initialize(18432000);
+	at91_clk_init(18432000);
+
+	/* Init sam9 PIT timer */
+	at91sam926x_pit_init();
 }
 
 /*
@@ -273,20 +276,20 @@ static void __init stamp9g20evb_board_init(void)
 
 MACHINE_START(PORTUXG20, "taskit PortuxG20")
 	/* Maintainer: taskit GmbH */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= stamp9g20_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= stamp9g20_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= portuxg20_board_init,
 MACHINE_END
 
 MACHINE_START(STAMP9G20, "taskit Stamp9G20")
 	/* Maintainer: taskit GmbH */
-	.init_time	= at91sam926x_pit_init,
+	.init_time	= stamp9g20_timer_init,
 	.map_io		= at91_map_io,
 	.handle_irq	= at91_aic_handle_irq,
-	.init_early	= stamp9g20_init_early,
+	.init_early	= at91_initialize,
 	.init_irq	= at91_init_irq_default,
 	.init_machine	= stamp9g20evb_board_init,
 MACHINE_END
diff --git a/arch/arm/mach-at91/stamp9g20.h b/arch/arm/mach-at91/stamp9g20.h
index f62c0ab..26a37b5 100644
--- a/arch/arm/mach-at91/stamp9g20.h
+++ b/arch/arm/mach-at91/stamp9g20.h
@@ -1,7 +1,7 @@
 #ifndef __MACH_STAMP9G20_H
 #define __MACH_STAMP9G20_H
 
-void stamp9g20_init_early(void);
+void stamp9g20_timer_init(void);
 void stamp9g20_board_init(void);
 
 #endif
-- 
1.7.9.5



From tony at atomide.com  Wed Jul 17 11:38:38 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 17 Jul 2013 08:38:38 -0700
Subject: [PATCH 2/3] ARM: OMAP2+: omap_device: add pinctrl handling
In-Reply-To: <1374061312-25469-3-git-send-email-grygorii.strashko@ti.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
 <1374061312-25469-3-git-send-email-grygorii.strashko@ti.com>
Message-ID: <20130717153838.GJ7656@atomide.com>

* Grygorii Strashko <grygorii.strashko at ti.com> [130717 04:49]:
> Before switching to DT pinctrl states of OMAP IPs have been handled by hwmod
> framework. After switching to DT-boot the pinctrl handling was dropped from
> hwmod framework and, as it was recommended, OMAP IP's drivers have to be updated
> to handle pinctrl states by itself using pinctrl_pm_select_xx() helpers
> (see http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html)
> 
> But this is not right for OMAP2+ SoC where real IPs state is controlled
> by omap_device core which enables/disables modules & clocks actually.

I'm not convinced we should try to handle this in a generic way
as only some devices need dynamic remuxing of some pins.

> For example, if OMAP I2C driver will handle pinctrl state during system wide
> suspend the following issue may occure:
> - suspend_noirq - I2C device can be still active because of PM auto-suspend
>   |-_od_suspend_noirq
>      |- omap_i2c_suspend_noirq
>         |- PINs state set to SLEEP
>   |- pm_generic_runtime_suspend
>      |- omap_i2c_runtime_suspend()
>         |- PINs state set to IDLE  <--- *oops* PINs state is IDLE and not SLEEP
>   |- omap_device_idle()
>      |- omap_hwmod_idle()
>         |- _idle()
>            |- disbale module (sysc&clocks)

And in this example you are assuming that you need separate idle and
sleep states, which is not true at least for most cases I've seen.

It is possible that am33xx needs separate idle and sleep states, but
most likely only for some pins. For omap[345] we can get away with
just the default state for most cases.

Regards,

Tony


From maxime.ripard at free-electrons.com  Wed Jul 17 11:40:10 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 17 Jul 2013 17:40:10 +0200
Subject: [PATCH 2/5] iio: at91: Use different prescal, startup mask in MR
 for different IP
In-Reply-To: <51E651D5.7050906@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
 <20130715125815.GC2962@lukather> <51E651D5.7050906@atmel.com>
Message-ID: <20130717154010.GB21549@lukather>

Hi Nicolas,

On Wed, Jul 17, 2013 at 10:12:05AM +0200, Nicolas Ferre wrote:
> On 15/07/2013 14:58, Maxime Ripard :
> >On Sun, Jul 14, 2013 at 04:04:26PM +0800, Josh Wu wrote:
> >>+/*
> >>+ * Since atmel adc support different ip for touchscreen mode. Through the
> >>+ * IP check, we will know the touchscreen capbilities.
> >>+ */
> >>+static void atmel_adc_get_cap(struct at91_adc_state *st)
> >>+{
> >>+	unsigned int version;
> >>+	struct iio_dev *idev = iio_priv_to_dev(st);
> >>+
> >>+	version = at91_adc_readl(st, AT91_ADC_VERSION);
> >>+	dev_dbg(&idev->dev, "version: 0x%x\n", version);
> >>+
> >>+	st->caps.mr_prescal_mask = AT91_ADC_PRESCAL_9260;
> >>+	st->caps.mr_startup_mask = AT91_ADC_STARTUP_9260;
> >>+
> >>+	/* keep only major version number */
> >>+	switch (version & 0xf00) {
> >>+	case 0x500:	/* SAMA5D3 */
> >>+	case 0x400:	/* AT91SAM9X5/9N12 */
> >>+		st->caps.has_tsmr = 1;
> >>+		st->caps.mr_startup_mask = AT91_ADC_STARTUP;
> >>+	case 0x200:	/* AT91SAM9M10/9G45 */
> >>+		st->caps.mr_prescal_mask = AT91_ADC_PRESCAL;
> >>+
> >>+		if ((version & 0xf00) == 0x200)
> >>+			st->caps.mr_startup_mask = AT91_ADC_STARTUP_9G45;
> >>+	case 0x100:	/* AT91SAM9260/9G20 */
> >>+		break;
> >>+	default:
> >>+		dev_warn(&idev->dev,
> >>+				"Unmanaged adc version, use minimal capabilities\n");
> >>+		break;
> >>+	};
> >>+}
> >
> >Why don't you use different compatible names and derive your
> >capabilities from which compatible is declared.
> 
> Do not forget that we still have a handful of platforms that do not
> support DT (and never will).

You can do pretty much the same thing with board-file-probed device
drivers, using the id_table field of the platform_driver structure and
use the driver_data field of the associated platform_device_id array to
store the needed values.

(see for example drivers/gpio/gpio-mxs.c)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130717/71912aca/attachment-0001.sig>

From tony at atomide.com  Wed Jul 17 11:40:39 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 17 Jul 2013 08:40:39 -0700
Subject: [PATCH 1/3] pinctrl: rollback check for !dev->pins in
 pinctrl_pm_select*() APIs
In-Reply-To: <1374061312-25469-2-git-send-email-grygorii.strashko@ti.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
 <1374061312-25469-2-git-send-email-grygorii.strashko@ti.com>
Message-ID: <20130717154038.GK7656@atomide.com>

* Grygorii Strashko <grygorii.strashko at ti.com> [130717 04:49]:
> The pinctrl support in Device core assumed to be optional - so, It's
> valid case, when there are no definition for default device's pinctrl
> states in DT at all ("default", "active", "idle", "sleep").
> And in this case dev->pins == NULL and pinctrl_pm_select*() API
> should return 0 always.
> 
> Now the checks for !dev->pins have been removed from
> pinctrl_pm_select*() API mistakenly by the patch
> pinctrl: Remove duplicate code in pinctrl_pm_select_state functions
> http://www.spinics.net/lists/arm-kernel/msg258829.html
> 
> Hence, rollback these checks in in pinctrl_pm_select*() APIs.

Thanks, it's best that I fold this fix into my patch as it has not
been committed yet.

Regards,

Tony


From catalin.marinas at arm.com  Wed Jul 17 11:43:38 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 17 Jul 2013 16:43:38 +0100
Subject: [PATCH 1/2] ARM: mm: Remove general hugetlb code from ARM.
In-Reply-To: <1374067574-32034-2-git-send-email-steve.capper@linaro.org>
References: <1374067574-32034-1-git-send-email-steve.capper@linaro.org>
 <1374067574-32034-2-git-send-email-steve.capper@linaro.org>
Message-ID: <20130717154338.GI27948@arm.com>

On Wed, Jul 17, 2013 at 02:26:13PM +0100, Steve Capper wrote:
> General forms of huge_pte_alloc, huge_pte_offset and follow_huge_pmd
> are now available in mm/hugetlb.c.
> 
> This patch removes the ARM copies of these functions and activates
> the general ones by enabling:
> CONFIG_ARCH_WANT_GENERAL_HUGETLB
> 
> Signed-off-by: Steve Capper <steve.capper at linaro.org>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From b.brezillon at overkiz.com  Wed Jul 17 11:45:39 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Wed, 17 Jul 2013 17:45:39 +0200
Subject: [PATCH v3 6/7] USB: ohci-at91: add usb_clk for transition to
 common clk framework
In-Reply-To: <Pine.LNX.4.44L0.1307171131580.1555-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307171131580.1555-100000@iolanthe.rowland.org>
Message-ID: <51E6BC23.6020700@overkiz.com>

On 17/07/2013 17:33, Alan Stern wrote:
> On Tue, 16 Jul 2013, Boris BREZILLON wrote:
>
>> The AT91 PMC (Power Management Controller) provides an USB clock used by
>> USB Full Speed host (ohci) and USB Full Speed device (udc).
>> The usb drivers (ohci and udc) must configure this clock to 48Mhz.
>> This configuration was formely done in mach-at91/clock.c, but this
>> implementation will be removed when moving to common clk framework.
>>
>> This patch add support for usb clock retrieval and configuration, and is
>> backward compatible with the current at91 clk implementation (if usb clk
>> is not found, it does not configure/enable the usb clk).
> This does not take into account any of the changes you discussed with
> Russell King and me -- it is exactly the same as the previous version.
Sorry, I don't understand. I didn't send any new version since yesterday.

I'm sending it right now and it's part of the
"ARM: at91: move to common clk framework" series (as discussed with you).


>> @@ -144,6 +150,11 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
>>   		goto err2;
>>   	}
>>   
>> +	uclk = clk_get(&pdev->dev, "usb_clk");
>> +	if (IS_ERR(uclk)) {
>> +		uclk = NULL;
>> +		dev_warn(&pdev->dev, "failed to get usb_clk\n");
>> +	}
>>   	iclk = clk_get(&pdev->dev, "ohci_clk");
>>   	if (IS_ERR(iclk)) {
>>   		dev_err(&pdev->dev, "failed to get ohci_clk\n");
>> @@ -212,10 +223,11 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
>>   	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
>>   	usb_put_hcd(hcd);
>>   
>> +	clk_put(uclk);
> What will clk_put() do when uclk is NULL?
>
> Alan Stern
>



From b.brezillon at overkiz.com  Wed Jul 17 11:46:11 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 17:46:11 +0200
Subject: [PATCH v2 25/42] ARM: at91: move pit timer to common clk framework
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374075971-20254-1-git-send-email-b.brezillon@overkiz.com>

Use device tree to get the source clock of the PIT (Periodic Interval Timer).
If the clock is not found in device tree (or dt is not enabled) we'll try to
get it using clk_lookup definitions.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/mach-at91/at91sam926x_time.c |   21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-at91/at91sam926x_time.c b/arch/arm/mach-at91/at91sam926x_time.c
index 3a4bc2e..fba7bd6 100644
--- a/arch/arm/mach-at91/at91sam926x_time.c
+++ b/arch/arm/mach-at91/at91sam926x_time.c
@@ -39,6 +39,7 @@
 static u32 pit_cycle;		/* write-once */
 static u32 pit_cnt;		/* access only w/system irq blocked */
 static void __iomem *pit_base_addr __read_mostly;
+static struct clk *mck;
 
 static inline unsigned int pit_read(unsigned int reg_offset)
 {
@@ -186,6 +187,7 @@ static int __init of_at91sam926x_pit_init(void)
 {
 	struct device_node	*np;
 	int			ret;
+	int			err = -EINVAL;
 
 	np = of_find_matching_node(NULL, pit_timer_ids);
 	if (!np)
@@ -195,10 +197,19 @@ static int __init of_at91sam926x_pit_init(void)
 	if (!pit_base_addr)
 		goto node_err;
 
+	mck = of_clk_get(np, 0);
+	if (IS_ERR(mck)) {
+		err = PTR_RET(mck);
+		mck = NULL;
+		pr_crit("AT91: PIT: Unable to get mck clk from DT\n");
+		goto ioremap_err;
+	}
+
 	/* Get the interrupts property */
 	ret = irq_of_parse_and_map(np, 0);
 	if (!ret) {
 		pr_crit("AT91: PIT: Unable to get IRQ from DT\n");
+		clk_put(mck);
 		goto ioremap_err;
 	}
 	at91sam926x_pit_irq.irq = ret;
@@ -212,7 +223,7 @@ ioremap_err:
 node_err:
 	of_node_put(np);
 err:
-	return -EINVAL;
+	return err;
 }
 #else
 static int __init of_at91sam926x_pit_init(void)
@@ -237,7 +248,13 @@ void __init at91sam926x_pit_init(void)
 	 * Use our actual MCK to figure out how many MCK/16 ticks per
 	 * 1/HZ period (instead of a compile-time constant LATCH).
 	 */
-	pit_rate = clk_get_rate(clk_get(NULL, "mck")) / 16;
+	if (!mck)
+		mck = clk_get(NULL, "mck");
+
+	if (IS_ERR(mck))
+		panic("AT91: PIT: Unable to get mck clk\n");
+	pit_rate = clk_get_rate(mck) / 16;
+	pr_notice("AT91: PIT: mck rate = %lu\n", pit_rate);
 	pit_cycle = (pit_rate + HZ/2) / HZ;
 	WARN_ON(((pit_cycle - 1) & ~AT91_PIT_PIV) != 0);
 
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 11:47:42 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 17:47:42 +0200
Subject: [PATCH v2 26/42] USB: ohci-at91: add usb_clk for transition to common
 clk framework
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374076062-20293-1-git-send-email-b.brezillon@overkiz.com>

The AT91 PMC (Power Management Controller) provides an USB clock used by
USB Full Speed host (ohci) and USB Full Speed device (udc).
The usb drivers (ohci and udc) must configure this clock to 48Mhz.
This configuration was formely done in mach-at91/clock.c, but this
implementation will be removed when moving to common clk framework.

This patch add support for usb clock retrieval and configuration.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/usb/host/ohci-at91.c |   16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 9677f68..ca1cdd6 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -31,8 +31,8 @@
 #define at91_for_each_port(index)	\
 		for ((index) = 0; (index) < AT91_MAX_USBH_PORTS; (index)++)
 
-/* interface and function clocks; sometimes also an AHB clock */
-static struct clk *iclk, *fclk, *hclk;
+/* interface, function and usb clocks; sometimes also an AHB clock */
+static struct clk *iclk, *fclk, *uclk, *hclk;
 static int clocked;
 
 extern int usb_disabled(void);
@@ -41,6 +41,8 @@ extern int usb_disabled(void);
 
 static void at91_start_clock(void)
 {
+	clk_set_rate(uclk, 48000000);
+	clk_prepare_enable(uclk);
 	clk_prepare_enable(hclk);
 	clk_prepare_enable(iclk);
 	clk_prepare_enable(fclk);
@@ -52,6 +54,7 @@ static void at91_stop_clock(void)
 	clk_disable_unprepare(fclk);
 	clk_disable_unprepare(iclk);
 	clk_disable_unprepare(hclk);
+	clk_disable_unprepare(uclk);
 	clocked = 0;
 }
 
@@ -162,6 +165,12 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
 		retval = PTR_ERR(hclk);
 		goto err5;
 	}
+	uclk = clk_get(&pdev->dev, "usb_clk");
+	if (IS_ERR(uclk)) {
+		dev_err(&pdev->dev, "failed to get usb_clk\n");
+		retval = PTR_ERR(uclk);
+		goto err6;
+	}
 
 	at91_start_hc(pdev);
 	ohci_hcd_init(hcd_to_ohci(hcd));
@@ -173,6 +182,8 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
 	/* Error handling */
 	at91_stop_hc(pdev);
 
+	clk_put(uclk);
+ err6:
 	clk_put(hclk);
  err5:
 	clk_put(fclk);
@@ -212,6 +223,7 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
 	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
 	usb_put_hcd(hcd);
 
+	clk_put(uclk);
 	clk_put(hclk);
 	clk_put(fclk);
 	clk_put(iclk);
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 11:49:23 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 17:49:23 +0200
Subject: [PATCH v2 27/42] usb: gadget: at91_udc: add usb_clk for transition to
 common clk framework
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374076163-20332-1-git-send-email-b.brezillon@overkiz.com>

The AT91 PMC (Power Management Controller) provides an USB clock used by
USB Full Speed host (ohci) and USB Full Speed device (udc).
The usb drivers (ohci and udc) must configure this clock to 48Mhz.
This configuration was formely done in mach-at91/clock.c, but this
implementation will be removed when moving to common clk framework.

This patch add support for usb clock retrieval and configuration.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/usb/gadget/at91_udc.c |   31 ++++++++++++++++++++++++++-----
 drivers/usb/gadget/at91_udc.h |    2 +-
 2 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
index fce8e4e..05aac04 100644
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -870,6 +870,8 @@ static void clk_on(struct at91_udc *udc)
 	if (udc->clocked)
 		return;
 	udc->clocked = 1;
+	clk_set_rate(udc->uclk, 48000000);
+	clk_prepare_enable(udc->uclk);
 	clk_prepare_enable(udc->iclk);
 	clk_prepare_enable(udc->fclk);
 }
@@ -882,6 +884,7 @@ static void clk_off(struct at91_udc *udc)
 	udc->gadget.speed = USB_SPEED_UNKNOWN;
 	clk_disable_unprepare(udc->fclk);
 	clk_disable_unprepare(udc->iclk);
+	clk_disable_unprepare(udc->uclk);
 }
 
 /*
@@ -1773,18 +1776,28 @@ static int at91udc_probe(struct platform_device *pdev)
 
 	/* get interface and function clocks */
 	udc->iclk = clk_get(dev, "udc_clk");
-	udc->fclk = clk_get(dev, "udpck");
-	if (IS_ERR(udc->iclk) || IS_ERR(udc->fclk)) {
-		DBG("clocks missing\n");
+	if (IS_ERR(udc->iclk)) {
+		DBG("interface clock missing\n");
 		retval = -ENODEV;
-		/* NOTE: we "know" here that refcounts on these are NOPs */
 		goto fail1;
 	}
+	udc->fclk = clk_get(dev, "udpck");
+	if (IS_ERR(udc->fclk)) {
+		DBG("function clock missing\n");
+		retval = -ENODEV;
+		goto fail1a;
+	}
+	udc->uclk = clk_get(dev, "usb_clk");
+	if (IS_ERR(udc->uclk)) {
+		DBG("usb clock missing\n");
+		retval = -ENODEV;
+		goto fail1b;
+	}
 
 	/* don't do anything until we have both gadget driver and VBUS */
 	retval = clk_prepare_enable(udc->iclk);
 	if (retval)
-		goto fail1;
+		goto fail1c;
 	at91_udp_write(udc, AT91_UDP_TXVC, AT91_UDP_TXVC_TXVDIS);
 	at91_udp_write(udc, AT91_UDP_IDR, 0xffffffff);
 	/* Clear all pending interrupts - UDP may be used by bootloader. */
@@ -1850,6 +1863,13 @@ fail3:
 		gpio_free(udc->board.vbus_pin);
 fail2:
 	free_irq(udc->udp_irq, udc);
+
+fail1c:
+	clk_put(udc->uclk);
+fail1b:
+	clk_put(udc->fclk);
+fail1a:
+	clk_put(udc->iclk);
 fail1:
 	iounmap(udc->udp_baseaddr);
 fail0a:
@@ -1894,6 +1914,7 @@ static int __exit at91udc_remove(struct platform_device *pdev)
 
 	clk_put(udc->iclk);
 	clk_put(udc->fclk);
+	clk_put(udc->uclk);
 
 	return 0;
 }
diff --git a/drivers/usb/gadget/at91_udc.h b/drivers/usb/gadget/at91_udc.h
index e647d1c..0175246 100644
--- a/drivers/usb/gadget/at91_udc.h
+++ b/drivers/usb/gadget/at91_udc.h
@@ -126,7 +126,7 @@ struct at91_udc {
 	unsigned			active_suspend:1;
 	u8				addr;
 	struct at91_udc_data		board;
-	struct clk			*iclk, *fclk;
+	struct clk			*iclk, *fclk, *uclk;
 	struct platform_device		*pdev;
 	struct proc_dir_entry		*pde;
 	void __iomem			*udp_baseaddr;
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 11:51:44 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 17:51:44 +0200
Subject: [PATCH v2 28/42] ARM: at91/dt: move at91rm9200 SoC to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374076304-20371-1-git-send-email-b.brezillon@overkiz.com>

Define at91rm9200 clocks in at91rm9200 device tree.
Add references to the appropriate clocks in each peripheral.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/at91rm9200.dtsi |  231 +++++++++++++++++++++++++++++++++++++
 1 file changed, 231 insertions(+)

diff --git a/arch/arm/boot/dts/at91rm9200.dtsi b/arch/arm/boot/dts/at91rm9200.dtsi
index 92b9e21..5596b1f 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -79,6 +79,204 @@
 			pmc: pmc at fffffc00 {
 				compatible = "atmel,at91rm9200-pmc";
 				reg = <0xfffffc00 0x100>;
+
+				clk32k: slck {
+					compatible = "fixed-clock";
+					#clock-cells = <0>;
+					clock-frequency = <32768>;
+				};
+
+				main: mainck {
+					compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
+					#clock-cells = <0>;
+					clocks = <&clk32k>;
+				};
+
+				plla: pllack {
+					compatible = "atmel,at91rm9200-clk-pll";
+					#clock-cells = <0>;
+					clocks = <&main>;
+					id = <0>;
+					input = <1000000 32000000>;
+					output = <80000000 160000000
+						  150000000 180000000>;
+					out = <0 2>;
+				};
+
+				pllb: pllbck {
+					compatible = "atmel,at91rm9200-clk-pll";
+					#clock-cells = <0>;
+					clocks = <&main>;
+					id = <1>;
+					input = <1000000 32000000>;
+					output = <80000000 160000000
+						  150000000 180000000>;
+					out = <0 2>;
+				};
+
+				mck: masterck {
+					compatible = "atmel,at91rm9200-clk-master";
+					#clock-cells = <0>;
+					clocks = <&clk32k>, <&main>, <&plla>, <&pllb>;
+					output = <0 80000000>;
+					divisors = <1 2 3 4>;
+				};
+
+				usb: usbck {
+					compatible = "atmel,at91rm9200-clk-usb";
+					#clock-cells = <0>;
+					clocks = <&pllb>;
+					divisors = <1 2 0 0>;
+				};
+
+				prog: progck {
+					compatible = "atmel,at91rm9200-clk-programmable";
+					#clock-cells = <1>;
+					clocks = <&clk32k>, <&main>, <&plla>, <&pllb>;
+
+					prog0 at 0 {
+						id = <0>;
+					};
+
+					prog1 at 1 {
+						id = <1>;
+					};
+
+					prog2 at 2 {
+						id = <2>;
+					};
+
+					prog3 at 3 {
+						id = <3>;
+					};
+				};
+
+				system: systemck {
+					compatible = "atmel,at91rm9200-clk-system";
+					#clock-cells = <1>;
+
+					udpck at 1 {
+						id = <1>;
+					};
+
+					uhpck at 4 {
+						id = <4>;
+					};
+
+					pck0 at 8 {
+						id = <8>;
+					};
+
+					pck1 at 9 {
+						id = <9>;
+					};
+
+					pck2 at 10 {
+						id = <10>;
+					};
+
+					pck3 at 11 {
+						id = <11>;
+					};
+				};
+
+				periph: periphck {
+					compatible = "atmel,at91rm9200-clk-peripheral";
+					#clock-cells = <1>;
+					clocks = <&mck>;
+
+					pioA_clk at 2 {
+						id = <2>;
+					};
+
+					pioB_clk at 3 {
+						id = <3>;
+					};
+
+					pioC_clk at 4 {
+						id = <4>;
+					};
+
+					pioD_clk at 5 {
+						id = <5>;
+					};
+
+					usart0_clk at 6 {
+						id = <6>;
+					};
+
+					usart1_clk at 7 {
+						id = <7>;
+					};
+
+					usart2_clk at 8 {
+						id = <8>;
+					};
+
+					usart3_clk at 9 {
+						id = <9>;
+					};
+
+					mci_clk at 10 {
+						id = <10>;
+					};
+
+					udc_clk at 11 {
+						id = <11>;
+					};
+
+					twi_clk at 12 {
+						id = <12>;
+					};
+
+					spi_clk at 13 {
+						id = <13>;
+					};
+
+					ssc0_clk at 14 {
+						id = <14>;
+					};
+
+					ssc1_clk at 15 {
+						id = <15>;
+					};
+
+					ssc2_clk at 16 {
+						id = <16>;
+					};
+
+					tc0_clk at 17 {
+						id = <17>;
+					};
+
+					tc1_clk at 18 {
+						id = <18>;
+					};
+
+					tc2_clk at 19 {
+						id = <19>;
+					};
+
+					tc3_clk at 20 {
+						id = <20>;
+					};
+
+					tc4_clk at 21 {
+						id = <21>;
+					};
+
+					tc5_clk at 22 {
+						id = <22>;
+					};
+
+					ohci_clk at 23 {
+						id = <23>;
+					};
+
+					pclk at 24 {
+						id = <24>;
+					};
+				};
 			};
 
 			st: timer at fffffd00 {
@@ -93,6 +291,8 @@
 				interrupts = <17 IRQ_TYPE_LEVEL_HIGH 0
 					      18 IRQ_TYPE_LEVEL_HIGH 0
 					      19 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 17>, <&periph 18>, <&periph 19>;
+				clock-names = "t0_clk", "t1_clk", "t2_clk";
 			};
 
 			tcb1: timer at fffa4000 {
@@ -101,6 +301,8 @@
 				interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0
 					      21 IRQ_TYPE_LEVEL_HIGH 0
 					      22 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 20>, <&periph 21>, <&periph 22>;
+				clock-names = "t0_clk", "t1_clk", "t2_clk";
 			};
 
 			i2c0: i2c at fffb8000 {
@@ -111,6 +313,7 @@
 				pinctrl-0 = <&pinctrl_twi>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 12>;
 				status = "disabled";
 			};
 
@@ -120,6 +323,8 @@
 				interrupts = <10 IRQ_TYPE_LEVEL_HIGH 0>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 10>;
+				clock-names = "mci_clk";
 				status = "disabled";
 			};
 
@@ -129,6 +334,8 @@
 				interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+				clocks = <&periph 14>;
+				clock-names = "pclk";
 				status = "disable";
 			};
 
@@ -138,6 +345,8 @@
 				interrupts = <15 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc1_tx &pinctrl_ssc1_rx>;
+				clocks = <&periph 15>;
+				clock-names = "pclk";
 				status = "disable";
 			};
 
@@ -147,6 +356,8 @@
 				interrupts = <16 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc2_tx &pinctrl_ssc2_rx>;
+				clocks = <&periph 16>;
+				clock-names = "pclk";
 				status = "disable";
 			};
 
@@ -157,6 +368,8 @@
 				phy-mode = "rmii";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_macb_rmii>;
+				clocks = <&periph 24>, <&periph 24>;
+				clock-names = "hclk", "pclk";
 				status = "disabled";
 			};
 
@@ -495,6 +708,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 2>;
 				};
 
 				pioB: gpio at fffff600 {
@@ -505,6 +719,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 3>;
 				};
 
 				pioC: gpio at fffff800 {
@@ -515,6 +730,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 4>;
 				};
 
 				pioD: gpio at fffffa00 {
@@ -525,6 +741,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 5>;
 				};
 			};
 
@@ -534,6 +751,8 @@
 				interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_dbgu>;
+				clocks = <&mck>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -545,6 +764,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_uart0>;
+				clocks = <&periph 6>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -556,6 +777,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_uart1>;
+				clocks = <&periph 7>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -567,6 +790,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_uart2>;
+				clocks = <&periph 8>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -578,6 +803,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_uart3>;
+				clocks = <&periph 9>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -585,6 +812,8 @@
 				compatible = "atmel,at91rm9200-udc";
 				reg = <0xfffb0000 0x4000>;
 				interrupts = <11 IRQ_TYPE_LEVEL_HIGH 2>;
+				clocks = <&periph 11>, <&system 1>;
+				clock-names = "udc_clk", "udpck";
 				status = "disabled";
 			};
 
@@ -621,6 +850,8 @@
 			compatible = "atmel,at91rm9200-ohci", "usb-ohci";
 			reg = <0x00300000 0x100000>;
 			interrupts = <23 IRQ_TYPE_LEVEL_HIGH 2>;
+			clocks = <&usb>, <&periph 23>, <&periph 23>, <&system 4>;
+			clock-names = "usb_clk", "ohci_clk", "hclk", "uhpck";
 			status = "disabled";
 		};
 	};
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 11:53:57 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 17:53:57 +0200
Subject: [PATCH v2 29/42] ARM: at91/dt: move at91sam9260 SoC to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374076437-20418-1-git-send-email-b.brezillon@overkiz.com>

Define at91sam9260 clocks in at91sam9260 device tree.
Add references to the appropriate clocks in each peripheral.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/at91sam9260.dtsi |  236 ++++++++++++++++++++++++++++++++++++
 1 file changed, 236 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index c7ccbcb..24b0165 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -48,6 +48,14 @@
 		reg = <0x20000000 0x04000000>;
 	};
 
+	clocks {
+		adc_op_clk: adc_op_clk{
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <5000000>;
+		};
+	};
+
 	ahb {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -76,6 +84,195 @@
 			pmc: pmc at fffffc00 {
 				compatible = "atmel,at91rm9200-pmc";
 				reg = <0xfffffc00 0x100>;
+
+				clk32k: slck {
+					compatible = "fixed-clock";
+					#clock-cells = <0>;
+					clock-frequency = <32768>;
+				};
+
+				main: mainck {
+					compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
+					#clock-cells = <0>;
+					clocks = <&clk32k>;
+				};
+
+				plla: pllack {
+					compatible = "atmel,at91rm9200-clk-pll";
+					#clock-cells = <0>;
+					clocks = <&main>;
+					id = <0>;
+					input = <1000000 32000000>;
+					output = <80000000 160000000
+						  150000000 240000000>;
+					out = <0 2>;
+				};
+
+				pllb: pllbck {
+					compatible = "atmel,at91rm9200-clk-pll";
+					#clock-cells = <0>;
+					clocks = <&main>;
+					id = <1>;
+					input = <1000000 5000000>;
+					output = <70000000 130000000>;
+					out = <1>;
+				};
+
+				mck: masterck {
+					compatible = "atmel,at91rm9200-clk-master";
+					#clock-cells = <0>;
+					clocks = <&clk32k>, <&main>, <&plla>, <&pllb>;
+					output = <0 105000000>;
+					divisors = <1 2 4 0>;
+				};
+
+				usb: usbck {
+					compatible = "atmel,at91rm9200-clk-usb";
+					#clock-cells = <0>;
+					clocks = <&pllb>;
+					divisors = <1 2 4 0>;
+				};
+
+				prog: progck {
+					compatible = "atmel,at91rm9200-clk-programmable";
+					#clock-cells = <1>;
+					clocks = <&clk32k>, <&main>, <&plla>, <&pllb>;
+
+					prog0 at 0 {
+						id = <0>;
+					};
+
+					prog1 at 1 {
+						id = <1>;
+					};
+				};
+
+				system: systemck {
+					compatible = "atmel,at91rm9200-clk-system";
+					#clock-cells = <1>;
+
+					udpck at 6 {
+						id = <6>;
+					};
+
+					uhpck at 7 {
+						id = <7>;
+					};
+
+					pck0 at 8 {
+						id = <8>;
+					};
+
+					pck1 at 9 {
+						id = <9>;
+					};
+				};
+
+				periph: periphck {
+					compatible = "atmel,at91rm9200-clk-peripheral";
+					#clock-cells = <1>;
+					clocks = <&mck>;
+
+					pioA_clk at 2 {
+						id = <2>;
+					};
+
+					pioB_clk at 3 {
+						id = <3>;
+					};
+
+					pioC_clk at 4 {
+						id = <4>;
+					};
+
+					adc_clk at 5 {
+						id = <5>;
+					};
+
+					usart0_clk at 6 {
+						id = <6>;
+					};
+
+					usart1_clk at 7 {
+						id = <7>;
+					};
+
+					usart2_clk at 8 {
+						id = <8>;
+					};
+
+					mci_clk at 9 {
+						id = <9>;
+					};
+
+					udc_clk at 10 {
+						id = <10>;
+					};
+
+					twi_clk at 11 {
+						id = <11>;
+					};
+
+					spi0_clk at 12 {
+						id = <12>;
+					};
+
+					spi1_clk at 13 {
+						id = <13>;
+					};
+
+					ssc_clk at 14 {
+						id = <14>;
+					};
+
+					tc0_clk at 17 {
+						id = <17>;
+					};
+
+					tc1_clk at 18 {
+						id = <18>;
+					};
+
+					tc2_clk at 19 {
+						id = <19>;
+					};
+
+					ohci_clk at 20 {
+						id = <20>;
+					};
+
+					pclk at 21 {
+						id = <21>;
+					};
+
+					isi_clk at 22 {
+						id = <22>;
+					};
+
+					usart3 at 23 {
+						id = <23>;
+					};
+
+					usart4 at 24 {
+						id = <24>;
+					};
+
+					usart5 at 25 {
+						id = <25>;
+					};
+
+					tc3_clk at 26 {
+						id = <26>;
+					};
+
+					tc4_clk at 27 {
+						id = <27>;
+					};
+
+					tc5_clk at 28 {
+						id = <28>;
+					};
+				};
 			};
 
 			rstc at fffffd00 {
@@ -92,6 +289,7 @@
 				compatible = "atmel,at91sam9260-pit";
 				reg = <0xfffffd30 0xf>;
 				interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+				clocks = <&mck>;
 			};
 
 			tcb0: timer at fffa0000 {
@@ -100,6 +298,8 @@
 				interrupts = <17 IRQ_TYPE_LEVEL_HIGH 0
 					      18 IRQ_TYPE_LEVEL_HIGH 0
 					      19 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 17>, <&periph 18>, <&periph 19>;
+				clock-names = "t0_clk", "t1_clk", "t2_clk";
 			};
 
 			tcb1: timer at fffdc000 {
@@ -108,6 +308,8 @@
 				interrupts = <26 IRQ_TYPE_LEVEL_HIGH 0
 					      27 IRQ_TYPE_LEVEL_HIGH 0
 					      28 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 26>, <&periph 27>, <&periph 28>;
+				clock-names = "t0_clk", "t1_clk", "t2_clk";
 			};
 
 			pinctrl at fffff400 {
@@ -443,6 +645,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 2>;
 				};
 
 				pioB: gpio at fffff600 {
@@ -453,6 +656,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 3>;
 				};
 
 				pioC: gpio at fffff800 {
@@ -463,6 +667,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 4>;
 				};
 			};
 
@@ -472,6 +677,8 @@
 				interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_dbgu>;
+				clocks = <&mck>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -483,6 +690,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart0>;
+				clocks = <&periph 6>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -494,6 +703,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart1>;
+				clocks = <&periph 7>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -505,6 +716,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart2>;
+				clocks = <&periph 8>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -516,6 +729,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart3>;
+				clocks = <&periph 23>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -527,6 +742,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_uart0>;
+				clocks = <&periph 24>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -538,6 +755,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_uart1>;
+				clocks = <&periph 25>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -547,6 +766,8 @@
 				interrupts = <21 IRQ_TYPE_LEVEL_HIGH 3>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_macb_rmii>;
+				clocks = <&periph 21>, <&periph 21>;
+				clock-names = "hclk", "pclk";
 				status = "disabled";
 			};
 
@@ -554,6 +775,8 @@
 				compatible = "atmel,at91rm9200-udc";
 				reg = <0xfffa4000 0x4000>;
 				interrupts = <10 IRQ_TYPE_LEVEL_HIGH 2>;
+				clocks = <&periph 10>, <&system 6>;
+				clock-names = "udc_clk", "udpck";
 				status = "disabled";
 			};
 
@@ -563,6 +786,7 @@
 				interrupts = <11 IRQ_TYPE_LEVEL_HIGH 6>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 11>;
 				status = "disabled";
 			};
 
@@ -572,6 +796,8 @@
 				interrupts = <9 IRQ_TYPE_LEVEL_HIGH 0>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 9>;
+				clock-names = "mci_clk";
 				status = "disabled";
 			};
 
@@ -581,6 +807,8 @@
 				interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+				clocks = <&periph 14>;
+				clock-names = "pclk";
 				status = "disabled";
 			};
 
@@ -592,6 +820,8 @@
 				interrupts = <12 IRQ_TYPE_LEVEL_HIGH 3>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_spi0>;
+				clocks = <&periph 12>;
+				clock-names = "spi_clk";
 				status = "disabled";
 			};
 
@@ -603,6 +833,8 @@
 				interrupts = <13 IRQ_TYPE_LEVEL_HIGH 3>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_spi1>;
+				clocks = <&periph 13>;
+				clock-names = "spi_clk";
 				status = "disabled";
 			};
 
@@ -610,6 +842,8 @@
 				compatible = "atmel,at91sam9260-adc";
 				reg = <0xfffe0000 0x100>;
 				interrupts = <5 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 5>, <&adc_op_clk>;
+				clock-names = "adc_clk", "adc_op_clk";
 				atmel,adc-use-external-triggers;
 				atmel,adc-channels-used = <0xf>;
 				atmel,adc-vref = <3300>;
@@ -673,6 +907,8 @@
 			compatible = "atmel,at91rm9200-ohci", "usb-ohci";
 			reg = <0x00500000 0x100000>;
 			interrupts = <20 IRQ_TYPE_LEVEL_HIGH 2>;
+			clocks = <&usb>, <&periph 20>, <&periph 20>, <&system 7>;
+			clock-names = "usb_clk", "ohci_clk", "hclk", "uhpck";
 			status = "disabled";
 		};
 	};
-- 
1.7.9.5



From mpfj-list at newflow.co.uk  Wed Jul 17 11:55:48 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Wed, 17 Jul 2013 16:55:48 +0100
Subject: ARM: AM335x: Kernel oops when using EDMA and MMC
Message-ID: <51E6BE84.6080905@newflow.co.uk>

I'm trying to get the MMC port working on our custom AM3352 CPU board.

I have added MMC entries to out dts file (similar to [1]), and I've
enabled CONFIG_TI_EDMA.

Our board boots fine without an SD card inserted ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.11.0-rc1-00025-g95b9b72 (mpfj at mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #309 Wed Jul 17 16:37:28 BST 2013
...
[    2.789028] VFS: Mounted root (ubifs filesystem) on device 0:12.
[    2.797268] devtmpfs: mounted
[    2.801032] Freeing unused kernel memory: 200K (c0551000 - c0583000)
...
Welcome to Buildroot
nanobone login:

But when I boot with a card already inserted, I get the following oops ...

...
[    1.827343] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
[    1.835868] pgd = c0004000
[    1.838774] [0000000c] *pgd=00000000
[    1.842556] Internal error: Oops: 5 [#1] ARM
[    1.847063] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.11.0-rc1-00025-g95b9b72 #309
[    1.855511] Workqueue: kmmcd mmc_rescan
[    1.859556] task: cf06a080 ti: cf072000 task.ti: cf072000
[    1.865257] PC is at omap_hsmmc_start_command+0x74/0xf4
[    1.870761] LR is at omap_hsmmc_request+0xec/0x4dc
[    1.875806] pc : [<c0305b70>]    lr : [<c0306c64>]    psr: 60000113
[    1.875806] sp : cf073ca0  ip : 00000000  fp : 00000008
[    1.887885] r10: cf073de8  r9 : 00000001  r8 : cf11d918
[    1.893382] r7 : 00000003  r6 : cf33cc80  r5 : 00000001  r4 : 00000033
[    1.900250] r3 : 00020000  r2 : cf073db8  r1 : cf073d84  r0 : cf33cc80
[    1.907122] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    1.914813] Control: 10c5387d  Table: 80004019  DAC: 00000015
[    1.920859] Process kworker/u2:0 (pid: 6, stack limit = 0xcf072238)
[    1.927454] Stack: (0xcf073ca0 to 0xcf074000)
[    1.932048] 3ca0: cf33c800 cf073d40 00000003 00000000 c0076a8c cf073d40 48060220 48060220
[    1.940659] 3cc0: 00000004 00000004 00000002 00000002 cf073ec8 c0421a9c c051835c cf073d40
[    1.949271] 3ce0: cf33c800 00000001 00000008 00000008 00000002 cf073db8 cf073ec8 c02f0f28
[    1.957882] 3d00: 00000200 00000064 00000000 cf073db8 cf073ec8 cf073d40 cf073d50 00000000
[    1.966493] 3d20: cf33c800 c02f18a4 cf369800 cf369a80 00000000 cf360880 00000008 c02f9964
[    1.975104] 3d40: 00000000 cf073d84 cf073db8 00000000 00000001 00000001 dead4ead ffffffff
[    1.983717] 3d60: ffffffff c0af722c c06aa3e4 00000000 c04ddadc cf073d74 cf073d74 c02f0dc4
[    1.992327] 3d80: 00000000 00000033 00000000 00000000 00000000 00000000 00000000 000000b5
[    2.000938] 3da0: 00000000 00000000 00000000 00000000 cf073db8 cf073d40 05f5e100 00000000
[    2.009548] 3dc0: 00000008 00000001 00000000 00000200 00000000 00000000 cf073d40 00000001
[    2.018159] 3de0: cf073de8 00000000 c0cf1c02 00000880 00000008 8f360880 00000000 cf369800
[    2.026771] 3e00: cf33c800 00000000 cf369800 cf073e4c cf072000 c02f8740 00000000 00000015
[    2.035382] 3e20: 00000003 cf33c800 00000000 00000000 cf369800 cf073e4c cf072000 c02f8b20
[    2.043994] 3e40: 00000002 c02f25cc 00000002 02544d53 41303447 1026c914 2600bbbd c0ff8000
[    2.052605] 3e60: c0455884 cf33c800 00000000 c0455884 c0455890 00000000 cf072000 c02f92bc
[    2.061217] 3e80: c0455890 00ff8000 00000002 cf33cb14 cf33c800 c02f3a28 cf041ac0 cf33cb14
[    2.069829] 3ea0: cf050c00 cf051c00 00000000 c00507ec 00000002 00000000 c0050778 c0050f10
[    2.078441] 3ec0: 00000000 00000000 c0af7268 c06aa1c4 00000000 c0518cd0 cf06a080 cf041ac0
[    2.087054] 3ee0: cf050c00 cf072000 cf050c30 cf041ad8 00000089 c05d7b5c cf050c00 c0050e4c
[    2.095665] 3f00: 00000000 cf072000 60000113 cf04dda8 00000000 cf041ac0 c0050d08 00000000
[    2.104276] 3f20: 00000000 00000000 00000000 c0056c94 c0429a18 00000000 00000001 cf041ac0
[    2.112888] 3f40: 00000000 00000001 dead4ead ffffffff ffffffff c05ec0a0 00000000 00000000
[    2.121499] 3f60: c04ddadc cf073f64 cf073f64 00000000 00000001 dead4ead ffffffff ffffffff
[    2.130112] 3f80: c05ec0a0 00000000 00000000 c04ddadc cf073f90 cf073f90 cf073fac cf04dda8
[    2.138724] 3fa0: c0056bf0 00000000 00000000 c0013588 00000000 00000000 00000000 00000000
[    2.147334] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    2.155946] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 57e0c5db 5ffb7d3c
[    2.164565] [<c0305b70>] (omap_hsmmc_start_command+0x74/0xf4) from [<00000003>] (0x3)
[    2.172814] Code: 13a03801 0a00001b e590c008 e5914000 (e59cc00c)
[    2.179314] ---[ end trace 6ec9899a56aef6aa ]---

I have also noticed that when the kernel boots okay (without a card inserted), if
I then insert a card, nothing happens (even with CONFIG_MMC_DEBUG=y) ... including
no kernel oops.

Can anyone shed light on what's wrong ?

Cheers
Mark J.

[1] https://lkml.org/lkml/2013/6/25/784



From b.brezillon at overkiz.com  Wed Jul 17 11:55:25 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 17:55:25 +0200
Subject: [PATCH v2 30/42] ARM: at91/dt: move at91sam9263 SoC to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374076525-20459-1-git-send-email-b.brezillon@overkiz.com>

Define at91sam9263 clocks in at91sam9263 device tree.
Add references to the appropriate clocks in each peripheral.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/at91sam9263.dtsi |  237 ++++++++++++++++++++++++++++++++++++
 1 file changed, 237 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
index d5bd65f..f4b0d3b 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -68,6 +68,208 @@
 			pmc: pmc at fffffc00 {
 				compatible = "atmel,at91rm9200-pmc";
 				reg = <0xfffffc00 0x100>;
+
+				clk32k: slck {
+					compatible = "fixed-clock";
+					#clock-cells = <0>;
+					clock-frequency = <32768>;
+				};
+
+				main: mainck {
+					compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
+					#clock-cells = <0>;
+					clocks = <&clk32k>;
+				};
+
+				plla: pllack {
+					compatible = "atmel,at91rm9200-clk-pll";
+					#clock-cells = <0>;
+					clocks = <&main>;
+					id = <0>;
+					input = <1000000 32000000>;
+					output = <80000000 200000000
+						  190000000 240000000>;
+					out = <0 2>;
+				};
+
+				pllb: pllbck {
+					compatible = "atmel,at91rm9200-clk-pll";
+					#clock-cells = <0>;
+					clocks = <&main>;
+					id = <1>;
+					input = <1000000 32000000>;
+					output = <80000000 200000000
+						  190000000 240000000>;
+					out = <0 2>;
+				};
+
+				mck: masterck {
+					compatible = "atmel,at91rm9200-clk-master";
+					#clock-cells = <0>;
+					clocks = <&clk32k>, <&main>, <&plla>, <&pllb>;
+					output = <0 120000000>;
+					divisors = <1 2 4 0>;
+				};
+
+				usb: usbck {
+					compatible = "atmel,at91rm9200-clk-usb";
+					#clock-cells = <0>;
+					clocks = <&pllb>;
+					divisors = <1 2 4 0>;
+				};
+
+				prog: progck {
+					compatible = "atmel,at91rm9200-clk-programmable";
+					#clock-cells = <1>;
+					clocks = <&clk32k>, <&main>, <&plla>, <&pllb>;
+
+					prog0 at 0 {
+						id = <0>;
+					};
+
+					prog1 at 1 {
+						id = <1>;
+					};
+
+					prog2 at 2 {
+						id = <2>;
+					};
+
+					prog3 at 3 {
+						id = <3>;
+					};
+				};
+
+				system: systemck {
+					compatible = "atmel,at91rm9200-clk-system";
+					#clock-cells = <1>;
+
+					udpck at 6 {
+						id = <6>;
+					};
+
+					uhpck at 7 {
+						id = <7>;
+					};
+
+					pck0 at 8 {
+						id = <8>;
+					};
+
+					pck1 at 9 {
+						id = <9>;
+					};
+
+					pck2 at 10 {
+						id = <10>;
+					};
+
+					pck3 at 11 {
+						id = <11>;
+					};
+				};
+
+				periph: periphck {
+					compatible = "atmel,at91rm9200-clk-peripheral";
+					#clock-cells = <1>;
+					clocks = <&mck>;
+
+					pioA_clk at 2 {
+						id = <2>;
+					};
+
+					pioB_clk at 3 {
+						id = <3>;
+					};
+
+					pioCDE_clk at 4 {
+						id = <4>;
+					};
+
+					usart0_clk at 7 {
+						id = <7>;
+					};
+
+					usart1_clk at 8 {
+						id = <8>;
+					};
+
+					usart2_clk at 9 {
+						id = <9>;
+					};
+
+					mci0_clk at 10 {
+						id = <10>;
+					};
+
+					mci1_clk at 11 {
+						id = <11>;
+					};
+
+					can_clk at 12 {
+						id = <12>;
+					};
+
+					twi_clk at 13 {
+						id = <13>;
+					};
+
+					spi0_clk at 14 {
+						id = <14>;
+					};
+
+					spi1_clk at 15 {
+						id = <15>;
+					};
+
+					ssc0_clk at 16 {
+						id = <16>;
+					};
+
+					ssc1_clk at 17 {
+						id = <17>;
+					};
+
+					ac97_clk at 18 {
+						id = <18>;
+					};
+
+					tcb_clk at 19 {
+						id = <19>;
+					};
+
+					pwm_clk at 20 {
+						id = <20>;
+					};
+
+					pclk at 21 {
+						id = <21>;
+					};
+
+					2dge_clk at 23 {
+						id = <23>;
+					};
+
+					udc_clk at 24 {
+						id = <24>;
+					};
+
+					isi_clk at 25 {
+						id = <25>;
+					};
+
+					lcdc_clk at 26 {
+						id = <26>;
+					};
+
+					dma_clk at 27 {
+						id = <27>;
+					};
+
+					ohci_clk at 29 {
+						id = <29>;
+					};
+				};
 			};
 
 			ramc: ramc at ffffe200 {
@@ -80,12 +282,15 @@
 				compatible = "atmel,at91sam9260-pit";
 				reg = <0xfffffd30 0xf>;
 				interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+				clocks = <&mck>;
 			};
 
 			tcb0: timer at fff7c000 {
 				compatible = "atmel,at91rm9200-tcb";
 				reg = <0xfff7c000 0x100>;
 				interrupts = <19 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 19>;
+				clock-names = "t0_clk";
 			};
 
 			rstc at fffffd00 {
@@ -374,6 +579,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 2>;
 				};
 
 				pioB: gpio at fffff400 {
@@ -384,6 +590,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 3>;
 				};
 
 				pioC: gpio at fffff600 {
@@ -394,6 +601,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 4>;
 				};
 
 				pioD: gpio at fffff800 {
@@ -404,6 +612,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 4>;
 				};
 
 				pioE: gpio at fffffa00 {
@@ -414,6 +623,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 4>;
 				};
 			};
 
@@ -423,6 +633,8 @@
 				interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_dbgu>;
+				clocks = <&mck>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -434,6 +646,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart0>;
+				clocks = <&periph 7>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -445,6 +659,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart1>;
+				clocks = <&periph 8>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -456,6 +672,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart2>;
+				clocks = <&periph 9>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -465,6 +683,8 @@
 				interrupts = <16 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+				clocks = <&periph 16>;
+				clock-names = "pclk";
 				status = "disabled";
 			};
 
@@ -474,6 +694,8 @@
 				interrupts = <17 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc1_tx &pinctrl_ssc1_rx>;
+				clocks = <&periph 17>;
+				clock-names = "pclk";
 				status = "disabled";
 			};
 
@@ -483,6 +705,8 @@
 				interrupts = <21 IRQ_TYPE_LEVEL_HIGH 3>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_macb_rmii>;
+				clocks = <&periph 21>, <&periph 21>;
+				clock-names = "hclk", "pclk";
 				status = "disabled";
 			};
 
@@ -490,6 +714,8 @@
 				compatible = "atmel,at91rm9200-udc";
 				reg = <0xfff78000 0x4000>;
 				interrupts = <24 IRQ_TYPE_LEVEL_HIGH 2>;
+				clocks = <&periph 24>, <&system 7>;
+				clock-names = "udc_clk", "udpck";
 				status = "disabled";
 			};
 
@@ -499,6 +725,7 @@
 				interrupts = <13 IRQ_TYPE_LEVEL_HIGH 6>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 13>;
 				status = "disabled";
 			};
 
@@ -508,6 +735,8 @@
 				interrupts = <10 IRQ_TYPE_LEVEL_HIGH 0>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 10>;
+				clock-names = "mci_clk";
 				status = "disabled";
 			};
 
@@ -517,6 +746,8 @@
 				interrupts = <11 IRQ_TYPE_LEVEL_HIGH 0>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 11>;
+				clock-names = "mci_clk";
 				status = "disabled";
 			};
 
@@ -534,6 +765,8 @@
 				interrupts = <14 IRQ_TYPE_LEVEL_HIGH 3>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_spi0>;
+				clocks = <&periph 14>;
+				clock-names = "spi_clk";
 				status = "disabled";
 			};
 
@@ -545,6 +778,8 @@
 				interrupts = <15 IRQ_TYPE_LEVEL_HIGH 3>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_spi1>;
+				clocks = <&periph 15>;
+				clock-names = "spi_clk";
 				status = "disabled";
 			};
 		};
@@ -571,6 +806,8 @@
 			compatible = "atmel,at91rm9200-ohci", "usb-ohci";
 			reg = <0x00a00000 0x100000>;
 			interrupts = <29 IRQ_TYPE_LEVEL_HIGH 2>;
+			clocks = <&usb>, <&periph 29>, <&periph 29>, <&system 6>;
+			clock-names = "usb_clk", "ohci_clk", "hclk", "uhpck";
 			status = "disabled";
 		};
 	};
-- 
1.7.9.5



From nicolas.pitre at linaro.org  Wed Jul 17 11:57:55 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Jul 2013 11:57:55 -0400 (EDT)
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <1374070811.3146.124.camel@hornet>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374052705.3146.86.camel@hornet>
 <alpine.LFD.2.03.1307170825240.14924@syhkavp.arg>
 <1374067786.3146.123.camel@hornet>
 <alpine.LFD.2.03.1307171014510.14924@syhkavp.arg>
 <1374070811.3146.124.camel@hornet>
Message-ID: <alpine.LFD.2.03.1307171148160.14924@syhkavp.arg>

On Wed, 17 Jul 2013, Pawel Moll wrote:

> On Wed, 2013-07-17 at 15:16 +0100, Nicolas Pitre wrote:
> > On Wed, 17 Jul 2013, Pawel Moll wrote:
> > 
> > > On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote:
> > > > If this is really miscelaneous code that really doesn't fit 
> > > > anywhere else, it should rather go into drivers/misc/ as a last resort.
> > > 
> > > Interestingly enough drivers/misc was my first choice for all the
> > > vexpress stuff, but it wasn't received well...
> > > 
> > > Anyway, the SPC driver as it is now seem to be a "power management
> > > system driver". Maybe a relevant directory would be in place? Wouldn't
> > > PSCI belong there as well? (there are two psci.c files in arch/arm and
> > > arch/arm64, surprisingly similar ones ;-)
> > > 
> > > The bottom line is: today it is not an MFD driver.
> > 
> > But we know it will, right?  So better  save some churn by storing the 
> > initial code where it would end up anyway once complete.
> 
> Not in that form, no. The code living in mfd will just register
> mfd_cells while "functional" parts are going to live elsewhere. This is
> how I understand what Samuel asked me to do and that's what is happening
> to vexpress-sysreg now.

A drivers/pm/ or drivers/power/ could be created, but that implies sort 
of a more defined subsystem with a common API and the SPC code doesn't 
fit that as it is only providing services to actual drivers on top of 
it.

The sanest location at this point might simply be 
drivers/platform/vexpress_spc.c or drivers/platform/vexpress/spc.c 
depending on whether or not more such driver glue is expected in the 
vexpress future.  No point putting "arm" in the path, especially if this 
is later reused on arm64.


Nicolas


From b.brezillon at overkiz.com  Wed Jul 17 12:00:33 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 18:00:33 +0200
Subject: [PATCH v2 31/42] ARM: at91/dt: move at91sam9g45 SoC to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374076833-20540-1-git-send-email-b.brezillon@overkiz.com>

Define at91sam9g45 clocks in at91sam9g45 device tree.
Add references to the appropriate clocks in each peripheral.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/at91sam9g45.dtsi |  257 ++++++++++++++++++++++++++++++++++++
 1 file changed, 257 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index c3e5148..dfca115 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -52,6 +52,14 @@
 		reg = <0x70000000 0x10000000>;
 	};
 
+	clocks {
+		adc_op_clk: adc_op_clk{
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <13200000>;
+		};
+	};
+
 	ahb {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -81,6 +89,211 @@
 			pmc: pmc at fffffc00 {
 				compatible = "atmel,at91rm9200-pmc";
 				reg = <0xfffffc00 0x100>;
+
+				clk32k: slck {
+					compatible = "fixed-clock";
+					#clock-cells = <0>;
+					clock-frequency = <32768>;
+				};
+
+				main: mainck {
+					compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
+					#clock-cells = <0>;
+					clocks = <&clk32k>;
+				};
+
+				plla: pllack {
+					compatible = "atmel,at91sam9g45-clk-pll";
+					#clock-cells = <0>;
+					clocks = <&main>;
+					id = <0>;
+					input = <2000000 32000000>;
+					output = <74500000 800000000
+						  69500000 750000000
+						  64500000 700000000
+						  59500000 650000000
+						  54500000 600000000
+						  49500000 550000000
+						  44500000 500000000
+						  40000000 450000000>;
+					out = <0 1 2 3 0 1 2 3>;
+					icpll = <0 0 0 0 1 1 1 1>;
+				};
+
+				plladiv: plladivck {
+					compatible = "atmel,at91sam9x5-clk-plldiv";
+					#clock-cells = <0>;
+					clocks = <&plla>;
+				};
+
+				utmi: utmick {
+					compatible = "atmel,at91sam9x5-clk-utmi";
+					#clock-cells = <0>;
+					clocks = <&main>;
+				};
+
+				mck: masterck {
+					compatible = "atmel,at91rm9200-clk-master";
+					#clock-cells = <0>;
+					clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>;
+					output = <0 133000000>;
+					divisors = <1 2 4 3>;
+				};
+
+				usb: usbck {
+					compatible = "atmel,at91sam9x5-clk-usb";
+					#clock-cells = <0>;
+					clocks = <&plladiv>, <&utmi>;
+				};
+
+				prog: progck {
+					compatible = "atmel,at91sam9g45-clk-programmable";
+					#clock-cells = <1>;
+					clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>;
+
+					prog0 at 0 {
+						id = <0>;
+					};
+
+					prog1 at 1 {
+						id = <1>;
+					};
+				};
+
+				system: systemck {
+					compatible = "atmel,at91rm9200-clk-system";
+					#clock-cells = <1>;
+
+					ddrck at 2 {
+						id = <2>;
+					};
+
+					uhpck at 6 {
+						id = <6>;
+					};
+
+					pck0 at 8 {
+						id = <8>;
+					};
+
+					pck1 at 9 {
+						id = <9>;
+					};
+				};
+
+				periph: periphck {
+					compatible = "atmel,at91rm9200-clk-peripheral";
+					#clock-cells = <1>;
+					clocks = <&mck>;
+
+					pioA_clk at 2 {
+						id = <2>;
+					};
+
+					pioB_clk at 3 {
+						id = <3>;
+					};
+
+					pioC_clk at 4 {
+						id = <4>;
+					};
+
+					pioDE_clk at 5 {
+						id = <5>;
+					};
+
+					trng_clk at 6 {
+						id = <6>;
+					};
+
+					usart0_clk at 7 {
+						id = <7>;
+					};
+
+					usart1_clk at 8 {
+						id = <8>;
+					};
+
+					usart2_clk at 9 {
+						id = <9>;
+					};
+
+					usart3_clk at 10 {
+						id = <10>;
+					};
+
+					mci0_clk at 11 {
+						id = <11>;
+					};
+
+					twi0_clk at 12 {
+						id = <12>;
+					};
+
+					twi1_clk at 13 {
+						id = <13>;
+					};
+
+					spi0_clk at 14 {
+						id = <14>;
+					};
+
+					spi1_clk at 15 {
+						id = <15>;
+					};
+
+					ssc0_clk at 16 {
+						id = <16>;
+					};
+
+					ssc1_clk at 17 {
+						id = <17>;
+					};
+
+					tcb0_clk at 18 {
+						id = <18>;
+					};
+
+					pwm_clk at 19 {
+						id = <19>;
+					};
+
+					tsc_clk at 20 {
+						id = <20>;
+					};
+
+					dma_clk at 21 {
+						id = <21>;
+					};
+
+					uhphs_clk at 22 {
+						id = <22>;
+					};
+
+					lcdc_clk at 23 {
+						id = <23>;
+					};
+
+					ac97_clk at 24 {
+						id = <24>;
+					};
+
+					pclk at 25 {
+						id = <25>;
+					};
+
+					isi_clk at 26 {
+						id = <26>;
+					};
+
+					udphs_clk at 27 {
+						id = <27>;
+					};
+
+					mci1_clk at 29 {
+						id = <29>;
+					};
+				};
 			};
 
 			rstc at fffffd00 {
@@ -92,6 +305,7 @@
 				compatible = "atmel,at91sam9260-pit";
 				reg = <0xfffffd30 0xf>;
 				interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+				clocks = <&mck>;
 			};
 
 
@@ -104,12 +318,16 @@
 				compatible = "atmel,at91rm9200-tcb";
 				reg = <0xfff7c000 0x100>;
 				interrupts = <18 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 18>;
+				clock-names = "t0_clk";
 			};
 
 			tcb1: timer at fffd4000 {
 				compatible = "atmel,at91rm9200-tcb";
 				reg = <0xfffd4000 0x100>;
 				interrupts = <18 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 18>;
+				clock-names = "t0_clk";
 			};
 
 			dma: dma-controller at ffffec00 {
@@ -117,6 +335,8 @@
 				reg = <0xffffec00 0x200>;
 				interrupts = <21 IRQ_TYPE_LEVEL_HIGH 0>;
 				#dma-cells = <2>;
+				clocks = <&periph 21>;
+				clock-names = "dma_clk";
 			};
 
 			pinctrl at fffff200 {
@@ -433,6 +653,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 2>;
 				};
 
 				pioB: gpio at fffff400 {
@@ -443,6 +664,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 3>;
 				};
 
 				pioC: gpio at fffff600 {
@@ -453,6 +675,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 4>;
 				};
 
 				pioD: gpio at fffff800 {
@@ -463,6 +686,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 5>;
 				};
 
 				pioE: gpio at fffffa00 {
@@ -473,6 +697,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 5>;
 				};
 			};
 
@@ -482,6 +707,8 @@
 				interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_dbgu>;
+				clocks = <&mck>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -493,6 +720,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart0>;
+				clocks = <&periph 7>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -504,6 +733,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart1>;
+				clocks = <&periph 8>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -515,6 +746,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart2>;
+				clocks = <&periph 9>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -526,6 +759,8 @@
 				atmel,use-dma-tx;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart3>;
+				clocks = <&periph 10>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -535,6 +770,8 @@
 				interrupts = <25 IRQ_TYPE_LEVEL_HIGH 3>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_macb_rmii>;
+				clocks = <&periph 25>, <&periph 25>;
+				clock-names = "hclk", "pclk";
 				status = "disabled";
 			};
 
@@ -544,6 +781,7 @@
 				interrupts = <12 IRQ_TYPE_LEVEL_HIGH 6>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 12>;
 				status = "disabled";
 			};
 
@@ -553,6 +791,7 @@
 				interrupts = <13 IRQ_TYPE_LEVEL_HIGH 6>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 13>;
 				status = "disabled";
 			};
 
@@ -562,6 +801,8 @@
 				interrupts = <16 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+				clocks = <&periph 16>;
+				clock-names = "pclk";
 				status = "disabled";
 			};
 
@@ -571,6 +812,8 @@
 				interrupts = <17 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc1_tx &pinctrl_ssc1_rx>;
+				clocks = <&periph 17>;
+				clock-names = "pclk";
 				status = "disabled";
 			};
 
@@ -578,6 +821,8 @@
 				compatible = "atmel,at91sam9260-adc";
 				reg = <0xfffb0000 0x100>;
 				interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 20>, <&adc_op_clk>;
+				clock-names = "adc_clk", "adc_op_clk";
 				atmel,adc-use-external-triggers;
 				atmel,adc-channels-used = <0xff>;
 				atmel,adc-vref = <3300>;
@@ -622,6 +867,8 @@
 				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 29>;
+				clock-names = "mci_clk";
 				status = "disabled";
 			};
 
@@ -633,6 +880,8 @@
 				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 29>;
+				clock-names = "mci_clk";
 				status = "disabled";
 			};
 
@@ -650,6 +899,8 @@
 				interrupts = <14 4 3>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_spi0>;
+				clocks = <&periph 14>;
+				clock-names = "spi_clk";
 				status = "disabled";
 			};
 
@@ -661,6 +912,8 @@
 				interrupts = <15 4 3>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_spi1>;
+				clocks = <&periph 15>;
+				clock-names = "spi_clk";
 				status = "disabled";
 			};
 
@@ -749,6 +1002,8 @@
 			compatible = "atmel,at91rm9200-ohci", "usb-ohci";
 			reg = <0x00700000 0x100000>;
 			interrupts = <22 IRQ_TYPE_LEVEL_HIGH 2>;
+			clocks = <&usb>, <&periph 22>, <&periph 22>, <&system 6>;
+			clock-names = "usb_clk", "ohci_clk", "hclk", "uhpck";
 			status = "disabled";
 		};
 
@@ -756,6 +1011,8 @@
 			compatible = "atmel,at91sam9g45-ehci", "usb-ehci";
 			reg = <0x00800000 0x100000>;
 			interrupts = <22 IRQ_TYPE_LEVEL_HIGH 2>;
+			clocks = <&periph 22>, <&system 6>;
+			clock-names = "ehci_clk", "uhpck";
 			status = "disabled";
 		};
 	};
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 12:02:05 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 18:02:05 +0200
Subject: [PATCH v2 32/42] ARM: at91/dt: move at91sam9n12 SoC to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374076925-20580-1-git-send-email-b.brezillon@overkiz.com>

Define at91sam9n12 clocks in at91sam9n12 device tree.
Add references to the appropriate clocks in each peripheral.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/at91sam9n12.dtsi |  251 ++++++++++++++++++++++++++++++++++++
 1 file changed, 251 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index bb7f564..a12ad9f 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -76,6 +76,224 @@
 			pmc: pmc at fffffc00 {
 				compatible = "atmel,at91rm9200-pmc";
 				reg = <0xfffffc00 0x100>;
+
+				clk32k: slck {
+					compatible = "fixed-clock";
+					#clock-cells = <0>;
+					clock-frequency = <32768>;
+				};
+
+				main: mainck {
+					compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
+					#clock-cells = <0>;
+					clocks = <&clk32k>;
+				};
+
+				plla: pllack {
+					compatible = "atmel,at91rm9200-clk-pll";
+					#clock-cells = <0>;
+					clocks = <&main>;
+					id = <0>;
+					input = <2000000 32000000>;
+					output = <74500000 800000000
+						  69500000 750000000
+						  64500000 700000000
+						  59500000 650000000
+						  54500000 600000000
+						  49500000 550000000
+						  44500000 500000000
+						  40000000 450000000>;
+					out = <0 1 2 3 0 1 2 3>;
+					icpll = <0 0 0 0 1 1 1 1>;
+				};
+
+				pllb: pllbck {
+					compatible = "atmel,at91rm9200-clk-pll";
+					#clock-cells = <0>;
+					clocks = <&main>;
+					id = <1>;
+					input = <2000000 32000000>;
+					output = <74500000 800000000
+						  69500000 750000000
+						  64500000 700000000
+						  59500000 650000000
+						  54500000 600000000
+						  49500000 550000000
+						  44500000 500000000
+						  40000000 450000000>;
+					out = <0 1 2 3 0 1 2 3>;
+					icpll = <0 0 0 0 1 1 1 1>;
+				};
+
+				plladiv: plladivck {
+					compatible = "atmel,at91sam9x5-clk-plldiv";
+					#clock-cells = <0>;
+					clocks = <&plla>;
+				};
+
+				mck: masterck {
+					compatible = "atmel,at91sam9x5-clk-master";
+					#clock-cells = <0>;
+					clocks = <&clk32k>, <&main>, <&plladiv>, <&pllb>;
+					output = <0 133000000>;
+					divisors = <1 2 4 3>;
+				};
+
+				usb: usbck {
+					compatible = "atmel,at91sam9x5-clk-usb";
+					#clock-cells = <0>;
+					clocks = <&pllb>;
+					usbs0-unused;
+				};
+
+				prog: progck {
+					compatible = "atmel,at91rm9200-clk-programmable";
+					#clock-cells = <1>;
+					clocks = <&clk32k>, <&main>, <&plladiv>, <&pllb>, <&mck>;
+
+					prog0 at 0 {
+						id = <0>;
+					};
+
+					prog1 at 1 {
+						id = <1>;
+					};
+				};
+
+				system: systemck {
+					compatible = "atmel,at91rm9200-clk-system";
+					#clock-cells = <1>;
+
+					ddrck at 2 {
+						id = <2>;
+					};
+
+					lcdck at 3 {
+						id = <3>;
+					};
+
+					uhpck at 6 {
+						id = <6>;
+					};
+
+					udpck at 7 {
+						id = <7>;
+					};
+
+					pck0 at 8 {
+						id = <8>;
+					};
+
+					pck1 at 9 {
+						id = <9>;
+					};
+				};
+
+				periph: periphck {
+					compatible = "atmel,at91rm9200-clk-peripheral";
+					#clock-cells = <1>;
+					clocks = <&mck>;
+
+					pioAB_clk at 2 {
+						id = <2>;
+					};
+
+					pioCD_clk at 3 {
+						id = <3>;
+					};
+
+					fuse_clk at 4 {
+						id = <4>;
+					};
+
+					usart0_clk at 5 {
+						id = <5>;
+					};
+
+					usart1_clk at 6 {
+						id = <6>;
+					};
+
+					usart2_clk at 7 {
+						id = <7>;
+					};
+
+					usart3_clk at 8 {
+						id = <8>;
+					};
+
+					twi0_ck at 9 {
+						id = <9>;
+					};
+
+					twi1_ck at 10 {
+						id = <10>;
+					};
+
+					hsmci_clk at 12 {
+						id = <12>;
+					};
+
+					spi0_clk at 13 {
+						id = <13>;
+					};
+
+					spi1_clk at 14 {
+						id = <14>;
+					};
+
+					uart0_clk at 15 {
+						id = <15>;
+					};
+
+					uart1_clk at 16 {
+						id = <16>;
+					};
+
+					tcb_clk at 17 {
+						id = <17>;
+					};
+
+					pwm_clk at 18 {
+						id = <18>;
+					};
+
+					adc_clk at 19 {
+						id = <19>;
+					};
+
+					dma_clk at 20 {
+						id = <20>;
+					};
+
+					uhp_clk at 22 {
+						id = <22>;
+					};
+
+					udc_clk at 23 {
+						id = <23>;
+					};
+
+					lcdc_clk at 25 {
+						id = <25>;
+					};
+
+					sha_clk at 27 {
+						id = <27>;
+					};
+
+					ssc_clk at 28 {
+						id = <28>;
+					};
+
+					aes_clk at 29 {
+						id = <29>;
+					};
+
+					trng_clk at 30 {
+						id = <30>;
+					};
+				};
 			};
 
 			rstc at fffffe00 {
@@ -87,6 +305,7 @@
 				compatible = "atmel,at91sam9260-pit";
 				reg = <0xfffffe30 0xf>;
 				interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+				clocks = <&mck>;
 			};
 
 			shdwc at fffffe10 {
@@ -102,6 +321,8 @@
 				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 12>;
+				clock-names = "mci_clk";
 				status = "disabled";
 			};
 
@@ -109,12 +330,16 @@
 				compatible = "atmel,at91sam9x5-tcb";
 				reg = <0xf8008000 0x100>;
 				interrupts = <17 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 17>;
+				clock-names = "t0_clk";
 			};
 
 			tcb1: timer at f800c000 {
 				compatible = "atmel,at91sam9x5-tcb";
 				reg = <0xf800c000 0x100>;
 				interrupts = <17 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 17>;
+				clock-names = "t0_clk";
 			};
 
 			dma: dma-controller at ffffec00 {
@@ -122,6 +347,8 @@
 				reg = <0xffffec00 0x200>;
 				interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0>;
 				#dma-cells = <2>;
+				clocks = <&periph 20>;
+				clock-names = "dma_clk";
 			};
 
 			pinctrl at fffff400 {
@@ -375,6 +602,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 2>;
 				};
 
 				pioB: gpio at fffff600 {
@@ -385,6 +613,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 2>;
 				};
 
 				pioC: gpio at fffff800 {
@@ -395,6 +624,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 3>;
 				};
 
 				pioD: gpio at fffffa00 {
@@ -405,6 +635,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 3>;
 				};
 			};
 
@@ -414,6 +645,8 @@
 				interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_dbgu>;
+				clocks = <&mck>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -423,6 +656,8 @@
 				interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+				clocks = <&periph 28>;
+				clock-names = "pclk";
 				status = "disabled";
 			};
 
@@ -432,6 +667,8 @@
 				interrupts = <5 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart0>;
+				clocks = <&periph 5>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -441,6 +678,8 @@
 				interrupts = <6 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart1>;
+				clocks = <&periph 6>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -450,6 +689,8 @@
 				interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart2>;
+				clocks = <&periph 7>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -459,6 +700,8 @@
 				interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart3>;
+				clocks = <&periph 8>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -471,6 +714,7 @@
 				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 9>;
 				status = "disabled";
 			};
 
@@ -483,6 +727,7 @@
 				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 10>;
 				status = "disabled";
 			};
 
@@ -497,6 +742,8 @@
 				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_spi0>;
+				clocks = <&periph 13>;
+				clock-names = "spi_clk";
 				status = "disabled";
 			};
 
@@ -511,6 +758,8 @@
 				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_spi1>;
+				clocks = <&periph 14>;
+				clock-names = "spi_clk";
 				status = "disabled";
 			};
 
@@ -546,6 +795,8 @@
 			compatible = "atmel,at91rm9200-ohci", "usb-ohci";
 			reg = <0x00500000 0x00100000>;
 			interrupts = <22 IRQ_TYPE_LEVEL_HIGH 2>;
+			clocks = <&usb>, <&periph 22>, <&periph 22>, <&system 6>;
+			clock-names = "usb_clk", "ohci_clk", "hclk", "uhpck";
 			status = "disabled";
 		};
 	};
-- 
1.7.9.5



From rric at kernel.org  Wed Jul 17 12:05:06 2013
From: rric at kernel.org (Robert Richter)
Date: Wed, 17 Jul 2013 18:05:06 +0200
Subject: [PATCH] arm, kbuild: make "make install" not depend on vmlinux
In-Reply-To: <20130712105721.GF8731@rric.localhost>
References: <20130710133742.GA29368@emu.suse.cz>
 <CA+55aFxtvT3Yvbxe5JGBThZS13payymFJ7jCLyEiE2iNDvsZtQ@mail.gmail.com>
 <20130711135445.GA21500@sepie.suse.cz>
 <CA+55aFyVjugxM7cUDWi0ASWttYthCxa6e7X3CADknBcSFxWgew@mail.gmail.com>
 <20130712105721.GF8731@rric.localhost>
Message-ID: <20130717160506.GI8731@rric.localhost>

(trimmed cc list)

On 12.07.13 11:57:21, Robert Richter wrote:
> On 11.07.13 10:16:18, Linus Torvalds wrote:
> > On Thu, Jul 11, 2013 at 6:54 AM, Michal Marek <mmarek at suse.cz> wrote:
> > >
> > > Yeah. It also reveals another bug that we rewrite the kernel.release
> > > file each time.
> 
> The odd thing I have in a specific configuration is that depmod is
> missing the kernelrelease when I only build install rules, though I
> had built everything before and kernelrelease should be there:
> 
>  $ make <makeflags>
>  $ make <makeflags> modules_install zinstall
>  ...
>    DEPMOD  
>  Usage: .../scripts/depmod.sh /sbin/depmod <kernelrelease>
> 
> Note that makeflags include the -j option, INSTALL_MOD_PATH and
> INSTALL_PATH variables set, so no root perms required in this case.

I narrowed this down. The problem is that zinstall on ARCH=arm has a
dependency to vmlinux which does a prepare/prepare3 and finally does a
forced rebuild of kernel.release even if it exists already.

Rebuilding it removes kernel.release first and then recreates it. This
might race with another parallel make job running depmod.

So on arm and maybe other archs we need the same as for x86:

 1648e4f8 x86, kbuild: make "make install" not depend on vmlinux

The patch below fixes this for arm. It is build-tested in my
environment, but please test it in others too if possible.

Thanks,

-Robert



>From 7e751c909830af4459296e7f2e0cb2321295e661 Mon Sep 17 00:00:00 2001
From: Robert Richter <robert.richter at linaro.org>
Date: Wed, 17 Jul 2013 16:17:20 +0200
Subject: [PATCH] arm, kbuild: make "make install" not depend on vmlinux

Install targets (install, zinstall, uinstall) on arm have a dependency
to vmlinux. This may cause parts of the kernel to be rebuilt during
installation. We must avoid this since this may run as root. Install
targets "ABSOLUTELY MUST NOT MODIFY THE SOURCE TREE." as Linus
emphasized this in:

 http://lkml.org/lkml/2013/7/10/600

So on arm and maybe other archs we need the same as for x86:

 1648e4f8 x86, kbuild: make "make install" not depend on vmlinux

This patch fixes this for arm. Dependencies are removed and instead a
check to install.sh is added for the files that are needed.

This issue was uncovered by this build error where the -j option is
used in conjunction with install targets:

 $ make <makeflags>
 $ make <makeflags> zinstall
 ...
   DEPMOD
 Usage: .../scripts/depmod.sh /sbin/depmod <kernelrelease>

(INSTALL_MOD_PATH and INSTALL_PATH variables set, so no root perms
required in this case.)

The problem is that zinstall on arm due to its dependency to vmlinux
does a prepare/prepare3 and finally does a forced rewrite of
kernel.release even if it exists already.

Rebuilding kernel.release removes it first and then recreates it. This
might race with another parallel make job running depmod.

So this patch should fix this one too.

Also quoting $(KERNELRELEASE) arg for install.sh as this messes
argument order in case it is empty (which is the case if the kernel
was not built yet).

Signed-off-by: Robert Richter <robert.richter at linaro.org>
Signed-off-by: Robert Richter <rric at kernel.org>
---
 arch/arm/Makefile        |    9 +++++++--
 arch/arm/boot/Makefile   |   16 ++++++++--------
 arch/arm/boot/install.sh |   14 ++++++++++++++
 3 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c0ac0f5..fe63986 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -295,10 +295,15 @@ archprepare:
 # Convert bzImage to zImage
 bzImage: zImage
 
-zImage Image xipImage bootpImage uImage: vmlinux
+BOOT_TARGETS	= zImage Image xipImage bootpImage uImage
+INSTALL_TARGETS	= zinstall uinstall install
+
+PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
+
+$(BOOT_TARGETS): vmlinux
 	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
 
-zinstall uinstall install: vmlinux
+$(INSTALL_TARGETS):
 	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
 
 %.dtb: | scripts
diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index 84aa2ca..ec2f806 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -95,24 +95,24 @@ initrd:
 	@test "$(INITRD)" != "" || \
 	(echo You must specify INITRD; exit -1)
 
-install: $(obj)/Image
-	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
+install:
+	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
 	$(obj)/Image System.map "$(INSTALL_PATH)"
 
-zinstall: $(obj)/zImage
-	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
+zinstall:
+	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
 	$(obj)/zImage System.map "$(INSTALL_PATH)"
 
-uinstall: $(obj)/uImage
-	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
+uinstall:
+	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
 	$(obj)/uImage System.map "$(INSTALL_PATH)"
 
 zi:
-	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
+	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
 	$(obj)/zImage System.map "$(INSTALL_PATH)"
 
 i:
-	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
+	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
 	$(obj)/Image System.map "$(INSTALL_PATH)"
 
 subdir-	    := bootp compressed dts
diff --git a/arch/arm/boot/install.sh b/arch/arm/boot/install.sh
index 06ea7d4..2a45092 100644
--- a/arch/arm/boot/install.sh
+++ b/arch/arm/boot/install.sh
@@ -20,6 +20,20 @@
 #   $4 - default install path (blank if root directory)
 #
 
+verify () {
+	if [ ! -f "$1" ]; then
+		echo ""                                                   1>&2
+		echo " *** Missing file: $1"                              1>&2
+		echo ' *** You need to run "make" before "make install".' 1>&2
+		echo ""                                                   1>&2
+		exit 1
+	fi
+}
+
+# Make sure the files actually exist
+verify "$2"
+verify "$3"
+
 # User may have a custom install script
 if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi
 if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi
-- 
1.7.7.6



From b.brezillon at overkiz.com  Wed Jul 17 12:05:27 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 18:05:27 +0200
Subject: [PATCH v2 33/42] ARM: at91/dt: move at91sam9x5 SoCs to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374077127-20633-1-git-send-email-b.brezillon@overkiz.com>

Define at91sam9x5 clocks in at91sam9x5 device tree.
Add references to the appropriate clocks in each peripheral.
Split optional sam9x5 peripherals in several device tree files. These
files are included by each SoC according to it's availability.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/at91sam9g15.dtsi       |    1 +
 arch/arm/boot/dts/at91sam9g25.dtsi       |    3 +
 arch/arm/boot/dts/at91sam9g35.dtsi       |    2 +
 arch/arm/boot/dts/at91sam9x25.dtsi       |   25 +--
 arch/arm/boot/dts/at91sam9x35.dtsi       |    3 +
 arch/arm/boot/dts/at91sam9x5.dtsi        |  319 +++++++++++++++++++++++-------
 arch/arm/boot/dts/at91sam9x5_can.dtsi    |   26 +++
 arch/arm/boot/dts/at91sam9x5_isi.dtsi    |   22 +++
 arch/arm/boot/dts/at91sam9x5_lcdc.dtsi   |   28 +++
 arch/arm/boot/dts/at91sam9x5_macb0.dtsi  |   66 +++++++
 arch/arm/boot/dts/at91sam9x5_macb1.dtsi  |   54 +++++
 arch/arm/boot/dts/at91sam9x5_usart3.dtsi |   58 ++++++
 12 files changed, 519 insertions(+), 88 deletions(-)
 create mode 100644 arch/arm/boot/dts/at91sam9x5_can.dtsi
 create mode 100644 arch/arm/boot/dts/at91sam9x5_isi.dtsi
 create mode 100644 arch/arm/boot/dts/at91sam9x5_lcdc.dtsi
 create mode 100644 arch/arm/boot/dts/at91sam9x5_macb0.dtsi
 create mode 100644 arch/arm/boot/dts/at91sam9x5_macb1.dtsi
 create mode 100644 arch/arm/boot/dts/at91sam9x5_usart3.dtsi

diff --git a/arch/arm/boot/dts/at91sam9g15.dtsi b/arch/arm/boot/dts/at91sam9g15.dtsi
index cfd7044..e0d8d84 100644
--- a/arch/arm/boot/dts/at91sam9g15.dtsi
+++ b/arch/arm/boot/dts/at91sam9g15.dtsi
@@ -7,6 +7,7 @@
  */
 
 #include "at91sam9x5.dtsi"
+#include "at91sam9x5_lcdc.dtsi"
 
 / {
 	model = "Atmel AT91SAM9G15 SoC";
diff --git a/arch/arm/boot/dts/at91sam9g25.dtsi b/arch/arm/boot/dts/at91sam9g25.dtsi
index b4ec6fe..49f5122 100644
--- a/arch/arm/boot/dts/at91sam9g25.dtsi
+++ b/arch/arm/boot/dts/at91sam9g25.dtsi
@@ -7,6 +7,9 @@
  */
 
 #include "at91sam9x5.dtsi"
+#include "at91sam9x5_usart3.dtsi"
+#include "at91sam9x5_macb0.dtsi"
+#include "at91sam9x5_isi.dtsi"
 
 / {
 	model = "Atmel AT91SAM9G25 SoC";
diff --git a/arch/arm/boot/dts/at91sam9g35.dtsi b/arch/arm/boot/dts/at91sam9g35.dtsi
index bebf9f5..cde7626 100644
--- a/arch/arm/boot/dts/at91sam9g35.dtsi
+++ b/arch/arm/boot/dts/at91sam9g35.dtsi
@@ -7,6 +7,8 @@
  */
 
 #include "at91sam9x5.dtsi"
+#include "at91sam9x5_macb0.dtsi"
+#include "at91sam9x5_isi.dtsi"
 
 / {
 	model = "Atmel AT91SAM9G35 SoC";
diff --git a/arch/arm/boot/dts/at91sam9x25.dtsi b/arch/arm/boot/dts/at91sam9x25.dtsi
index 49e94ab..3c5fa33 100644
--- a/arch/arm/boot/dts/at91sam9x25.dtsi
+++ b/arch/arm/boot/dts/at91sam9x25.dtsi
@@ -7,6 +7,10 @@
  */
 
 #include "at91sam9x5.dtsi"
+#include "at91sam9x5_usart3.dtsi"
+#include "at91sam9x5_macb0.dtsi"
+#include "at91sam9x5_macb1.dtsi"
+#include "at91sam9x5_can.dtsi"
 
 / {
 	model = "Atmel AT91SAM9X25 SoC";
@@ -22,27 +26,6 @@
 				       0x80000000 0xfffd0000 0xb83fffff  /* pioC */
 				       0x003fffff 0x003f8000 0x00000000  /* pioD */
 				      >;
-
-				macb1 {
-					pinctrl_macb1_rmii: macb1_rmii-0 {
-						atmel,pins =
-							<AT91_PIOC 16 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC16 periph B */
-							 AT91_PIOC 18 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC18 periph B */
-							 AT91_PIOC 19 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC19 periph B */
-							 AT91_PIOC 20 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC20 periph B */
-							 AT91_PIOC 21 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC21 periph B */
-							 AT91_PIOC 27 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC27 periph B */
-							 AT91_PIOC 28 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC28 periph B */
-							 AT91_PIOC 29 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC29 periph B */
-							 AT91_PIOC 30 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC30 periph B */
-							 AT91_PIOC 31 AT91_PERIPH_B AT91_PINCTRL_NONE>;	/* PC31 periph B */
-					};
-				};
-			};
-
-			macb1: ethernet at f8030000 {
-				pinctrl-names = "default";
-				pinctrl-0 = <&pinctrl_macb1_rmii>;
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/at91sam9x35.dtsi b/arch/arm/boot/dts/at91sam9x35.dtsi
index 1a3d525..ecbdf5d 100644
--- a/arch/arm/boot/dts/at91sam9x35.dtsi
+++ b/arch/arm/boot/dts/at91sam9x35.dtsi
@@ -7,6 +7,9 @@
  */
 
 #include "at91sam9x5.dtsi"
+#include "at91sam9x5_macb0.dtsi"
+#include "at91sam9x5_lcdc.dtsi"
+#include "at91sam9x5_can.dtsi"
 
 / {
 	model = "Atmel AT91SAM9X35 SoC";
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 57d45f5..1dd5d11 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -50,6 +50,14 @@
 		reg = <0x20000000 0x10000000>;
 	};
 
+	clocks {
+		adc_op_clk: adc_op_clk{
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <13200000>;
+		};
+	};
+
 	ahb {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -78,6 +86,210 @@
 			pmc: pmc at fffffc00 {
 				compatible = "atmel,at91rm9200-pmc";
 				reg = <0xfffffc00 0x100>;
+
+				clk32k: slck {
+					compatible = "fixed-clock";
+					#clock-cells = <0>;
+					clock-frequency = <32768>;
+				};
+
+				main: mainck {
+					compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
+					#clock-cells = <0>;
+					clocks = <&clk32k>;
+				};
+
+				plla: pllack {
+					compatible = "atmel,at91rm9200-clk-pll";
+					#clock-cells = <0>;
+					clocks = <&main>;
+					id = <0>;
+					input = <2000000 32000000>;
+					output = <74500000 800000000
+						  69500000 750000000
+						  64500000 700000000
+						  59500000 650000000
+						  54500000 600000000
+						  49500000 550000000
+						  44500000 500000000
+						  40000000 450000000>;
+					out = <0 1 2 3 0 1 2 3>;
+					icpll = <0 0 0 0 1 1 1 1>;
+				};
+
+				plladiv: plladivck {
+					compatible = "atmel,at91sam9x5-clk-plldiv";
+					#clock-cells = <0>;
+					clocks = <&plla>;
+				};
+
+				utmi: utmick {
+					compatible = "atmel,at91sam9x5-clk-utmi";
+					#clock-cells = <0>;
+					clocks = <&main>;
+				};
+
+				mck: masterck {
+					compatible = "atmel,at91sam9x5-clk-master";
+					#clock-cells = <0>;
+					clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>;
+					output = <0 133000000>;
+					divisors = <1 2 4 3>;
+					have-div3-pres;
+				};
+
+				usb: usbck {
+					compatible = "atmel,at91sam9x5-clk-usb";
+					#clock-cells = <0>;
+					clocks = <&plladiv>, <&utmi>;
+				};
+
+				prog: progck {
+					compatible = "atmel,at91sam9x5-clk-programmable";
+					#clock-cells = <1>;
+					clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>;
+
+					prog0 at 0 {
+						id = <0>;
+					};
+
+					prog1 at 1 {
+						id = <1>;
+					};
+				};
+
+				smd: smdclk {
+					compatible = "atmel,at91sam9x5-clk-smd";
+					#clock-cells = <0>;
+					clocks = <&plladiv>, <&utmi>;
+				};
+
+				system: systemck {
+					compatible = "atmel,at91rm9200-clk-system";
+					#clock-cells = <1>;
+
+					ddrck at 2 {
+						id = <2>;
+					};
+
+					smdck at 4 {
+						id = <4>;
+					};
+
+					udpck at 6 {
+						id = <6>;
+					};
+
+					uhpck at 7 {
+						id = <7>;
+					};
+
+					pck0 at 8 {
+						id = <8>;
+					};
+
+					pck1 at 9 {
+						id = <9>;
+					};
+				};
+
+				periph: periphck {
+					compatible = "atmel,at91sam9x5-clk-peripheral";
+					#clock-cells = <1>;
+					clocks = <&mck>;
+
+					pioAB_clk at 2 {
+						id = <2>;
+					};
+
+					pioCD_clk at 3 {
+						id = <3>;
+					};
+
+					smd_clk at 4 {
+						id = <4>;
+					};
+
+					usart0_clk at 5 {
+						id = <5>;
+					};
+
+					usart1_clk at 6 {
+						id = <6>;
+					};
+
+					usart2_clk at 7 {
+						id = <7>;
+					};
+
+					twi0_clk at 9 {
+						id = <9>;
+					};
+
+					twi1_clk at 10 {
+						id = <10>;
+					};
+
+					twi2_clk at 11 {
+						id = <11>;
+					};
+
+					mci0_clk at 12 {
+						id = <12>;
+					};
+
+					spi0_clk at 13 {
+						id = <13>;
+					};
+
+					spi1_clk at 14 {
+						id = <14>;
+					};
+
+					uart0_clk at 15 {
+						id = <15>;
+					};
+
+					uart1_clk at 16 {
+						id = <16>;
+					};
+
+					tcb_clk at 17 {
+						id = <17>;
+					};
+
+					pwm_clk at 18 {
+						id = <18>;
+					};
+
+					adc_clk at 19 {
+						id = <19>;
+					};
+
+					dma0_clk at 20 {
+						id = <20>;
+					};
+
+					dma1_clk at 21 {
+						id = <21>;
+					};
+
+					uhphs_clk at 22 {
+						id = <22>;
+					};
+
+					udphs_clk at 23 {
+						id = <23>;
+					};
+
+					mci1_clk at 26 {
+						id = <26>;
+					};
+
+					ssc_clk at 27 {
+						id = <27>;
+					};
+				};
 			};
 
 			rstc at fffffe00 {
@@ -94,18 +306,23 @@
 				compatible = "atmel,at91sam9260-pit";
 				reg = <0xfffffe30 0xf>;
 				interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+				clocks = <&mck>;
 			};
 
 			tcb0: timer at f8008000 {
 				compatible = "atmel,at91sam9x5-tcb";
 				reg = <0xf8008000 0x100>;
 				interrupts = <17 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 17>;
+				clock-names = "t0_clk";
 			};
 
 			tcb1: timer at f800c000 {
 				compatible = "atmel,at91sam9x5-tcb";
 				reg = <0xf800c000 0x100>;
 				interrupts = <17 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 17>;
+				clock-names = "t0_clk";
 			};
 
 			dma0: dma-controller at ffffec00 {
@@ -113,6 +330,8 @@
 				reg = <0xffffec00 0x200>;
 				interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0>;
 				#dma-cells = <2>;
+				clocks = <&periph 20>;
+				clock-names = "dma_clk";
 			};
 
 			dma1: dma-controller at ffffee00 {
@@ -120,6 +339,8 @@
 				reg = <0xffffee00 0x200>;
 				interrupts = <21 IRQ_TYPE_LEVEL_HIGH 0>;
 				#dma-cells = <2>;
+				clocks = <&periph 21>;
+				clock-names = "dma_clk";
 			};
 
 			pinctrl at fffff400 {
@@ -206,29 +427,6 @@
 					};
 				};
 
-				usart3 {
-					pinctrl_usart3: usart3-0 {
-						atmel,pins =
-							<AT91_PIOC 22 AT91_PERIPH_B AT91_PINCTRL_PULL_UP	/* PC22 periph B with pullup */
-							 AT91_PIOC 23 AT91_PERIPH_B AT91_PINCTRL_NONE>;	/* PC23 periph B */
-					};
-
-					pinctrl_usart3_rts: usart3_rts-0 {
-						atmel,pins =
-							<AT91_PIOC 24 AT91_PERIPH_B AT91_PINCTRL_NONE>;	/* PC24 periph B */
-					};
-
-					pinctrl_usart3_cts: usart3_cts-0 {
-						atmel,pins =
-							<AT91_PIOC 25 AT91_PERIPH_B AT91_PINCTRL_NONE>;	/* PC25 periph B */
-					};
-
-					pinctrl_usart3_sck: usart3_sck-0 {
-						atmel,pins =
-							<AT91_PIOC 26 AT91_PERIPH_B AT91_PINCTRL_NONE>;	/* PC26 periph B */
-					};
-				};
-
 				uart0 {
 					pinctrl_uart0: uart0-0 {
 						atmel,pins =
@@ -277,34 +475,6 @@
 					};
 				};
 
-				macb0 {
-					pinctrl_macb0_rmii: macb0_rmii-0 {
-						atmel,pins =
-							<AT91_PIOB 0 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB0 periph A */
-							 AT91_PIOB 1 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB1 periph A */
-							 AT91_PIOB 2 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB2 periph A */
-							 AT91_PIOB 3 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB3 periph A */
-							 AT91_PIOB 4 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB4 periph A */
-							 AT91_PIOB 5 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB5 periph A */
-							 AT91_PIOB 6 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB6 periph A */
-							 AT91_PIOB 7 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB7 periph A */
-							 AT91_PIOB 9 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB9 periph A */
-							 AT91_PIOB 10 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PB10 periph A */
-					};
-
-					pinctrl_macb0_rmii_mii: macb0_rmii_mii-0 {
-						atmel,pins =
-							<AT91_PIOB 8 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB8 periph A */
-							 AT91_PIOB 11 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB11 periph A */
-							 AT91_PIOB 12 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB12 periph A */
-							 AT91_PIOB 13 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB13 periph A */
-							 AT91_PIOB 14 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB14 periph A */
-							 AT91_PIOB 15 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB15 periph A */
-							 AT91_PIOB 16 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB16 periph A */
-							 AT91_PIOB 17 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PB17 periph A */
-					};
-				};
-
 				mmc0 {
 					pinctrl_mmc0_slot0_clk_cmd_dat0: mmc0_slot0_clk_cmd_dat0-0 {
 						atmel,pins =
@@ -503,6 +673,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 2>;
 				};
 
 				pioB: gpio at fffff600 {
@@ -514,6 +685,7 @@
 					#gpio-lines = <19>;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 2>;
 				};
 
 				pioC: gpio at fffff800 {
@@ -524,6 +696,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 3>;
 				};
 
 				pioD: gpio at fffffa00 {
@@ -535,6 +708,7 @@
 					#gpio-lines = <22>;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 3>;
 				};
 			};
 
@@ -544,6 +718,8 @@
 				interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+				clocks = <&periph 28>;
+				clock-names = "pclk";
 				status = "disabled";
 			};
 
@@ -555,6 +731,8 @@
 				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 12>;
+				clock-names = "mci_clk";
 				status = "disabled";
 			};
 
@@ -566,6 +744,8 @@
 				dma-names = "rxtx";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 26>;
+				clock-names = "mci_clk";
 				status = "disabled";
 			};
 
@@ -575,6 +755,8 @@
 				interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_dbgu>;
+				clocks = <&mck>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -584,6 +766,8 @@
 				interrupts = <5 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart0>;
+				clocks = <&periph 5>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -593,6 +777,8 @@
 				interrupts = <6 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart1>;
+				clocks = <&periph 6>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -602,22 +788,8 @@
 				interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart2>;
-				status = "disabled";
-			};
-
-			macb0: ethernet at f802c000 {
-				compatible = "cdns,at32ap7000-macb", "cdns,macb";
-				reg = <0xf802c000 0x100>;
-				interrupts = <24 IRQ_TYPE_LEVEL_HIGH 3>;
-				pinctrl-names = "default";
-				pinctrl-0 = <&pinctrl_macb0_rmii>;
-				status = "disabled";
-			};
-
-			macb1: ethernet at f8030000 {
-				compatible = "cdns,at32ap7000-macb", "cdns,macb";
-				reg = <0xf8030000 0x100>;
-				interrupts = <27 IRQ_TYPE_LEVEL_HIGH 3>;
+				clocks = <&periph 7>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -632,6 +804,7 @@
 				#size-cells = <0>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_i2c0>;
+				clocks = <&periph 9>;
 				status = "disabled";
 			};
 
@@ -646,6 +819,7 @@
 				#size-cells = <0>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_i2c1>;
+				clocks = <&periph 10>;
 				status = "disabled";
 			};
 
@@ -660,6 +834,7 @@
 				#size-cells = <0>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_i2c2>;
+				clocks = <&periph 11>;
 				status = "disabled";
 			};
 
@@ -685,6 +860,8 @@
 				compatible = "atmel,at91sam9260-adc";
 				reg = <0xf804c000 0x100>;
 				interrupts = <19 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 19>, <&adc_op_clk>;
+				clock-names = "adc_clk", "adc_op_clk";
 				atmel,adc-use-external;
 				atmel,adc-channels-used = <0xffff>;
 				atmel,adc-vref = <3300>;
@@ -733,6 +910,8 @@
 				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_spi0>;
+				clocks = <&periph 13>;
+				clock-names = "spi_clk";
 				status = "disabled";
 			};
 
@@ -747,6 +926,8 @@
 				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_spi1>;
+				clocks = <&periph 14>;
+				clock-names = "spi_clk";
 				status = "disabled";
 			};
 
@@ -851,6 +1032,8 @@
 			compatible = "atmel,at91rm9200-ohci", "usb-ohci";
 			reg = <0x00600000 0x100000>;
 			interrupts = <22 IRQ_TYPE_LEVEL_HIGH 2>;
+			clocks = <&usb>, <&periph 22>, <&periph 22>, <&system 6>;
+			clock-names = "usb_clk", "ohci_clk", "hclk", "uhpck";
 			status = "disabled";
 		};
 
@@ -858,6 +1041,8 @@
 			compatible = "atmel,at91sam9g45-ehci", "usb-ehci";
 			reg = <0x00700000 0x100000>;
 			interrupts = <22 IRQ_TYPE_LEVEL_HIGH 2>;
+			clocks = <&periph 22>, <&system 6>;
+			clock-names = "ehci_clk", "uhpck";
 			status = "disabled";
 		};
 	};
diff --git a/arch/arm/boot/dts/at91sam9x5_can.dtsi b/arch/arm/boot/dts/at91sam9x5_can.dtsi
new file mode 100644
index 0000000..e6db2f2
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9x5_can.dtsi
@@ -0,0 +1,26 @@
+/*
+ * at91sam9x5_can.dtsi - Device Tree Include file for AT91SAM9x5 SoC with
+ * CAN support.
+ *
+ * Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * Licensed under GPLv2.
+ */
+
+/ {
+	ahb {
+		apb {
+			pmc: pmc at fffffc00 {
+				periph: periphck {
+					can0_clk at 29 {
+						id = <29>;
+					};
+
+					can1_clk at 30 {
+						id = <30>;
+					};
+				};
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/at91sam9x5_isi.dtsi b/arch/arm/boot/dts/at91sam9x5_isi.dtsi
new file mode 100644
index 0000000..593c9e4
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9x5_isi.dtsi
@@ -0,0 +1,22 @@
+/*
+ * at91sam9x5_isi.dtsi - Device Tree Include file for AT91SAM9x5 SoC with
+ * ISI (Image Sensor Interface) support.
+ *
+ * Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * Licensed under GPLv2.
+ */
+
+/ {
+	ahb {
+		apb {
+			pmc: pmc at fffffc00 {
+				periph: periphck {
+					isi_clk at 25 {
+						id = <25>;
+					};
+				};
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/at91sam9x5_lcdc.dtsi b/arch/arm/boot/dts/at91sam9x5_lcdc.dtsi
new file mode 100644
index 0000000..5e04c50
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9x5_lcdc.dtsi
@@ -0,0 +1,28 @@
+/*
+ * at91sam9x5_lcdc.dtsi - Device Tree Include file for AT91SAM9x5 SoC with
+ * LCDC (LCD controller) support.
+ *
+ * Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * Licensed under GPLv2.
+ */
+
+/ {
+	ahb {
+		apb {
+			pmc: pmc at fffffc00 {
+				system: systemck {
+					lcdck at 3 {
+						id = <3>;
+					};
+				};
+
+				periph: periphck {
+					lcdc_clk at 25 {
+						id = <25>;
+					};
+				};
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/at91sam9x5_macb0.dtsi b/arch/arm/boot/dts/at91sam9x5_macb0.dtsi
new file mode 100644
index 0000000..5483e1a
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9x5_macb0.dtsi
@@ -0,0 +1,66 @@
+/*
+ * at91sam9x5_macb0.dtsi - Device Tree Include file for AT91SAM9x5 SoC with 1
+ * Ethernet interface.
+ *
+ * Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * Licensed under GPLv2.
+ */
+
+#include <dt-bindings/pinctrl/at91.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	ahb {
+		apb {
+			pinctrl at fffff400 {
+				macb0 {
+					pinctrl_macb0_rmii: macb0_rmii-0 {
+						atmel,pins =
+							<AT91_PIOB 0 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB0 periph A */
+							 AT91_PIOB 1 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB1 periph A */
+							 AT91_PIOB 2 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB2 periph A */
+							 AT91_PIOB 3 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB3 periph A */
+							 AT91_PIOB 4 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB4 periph A */
+							 AT91_PIOB 5 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB5 periph A */
+							 AT91_PIOB 6 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB6 periph A */
+							 AT91_PIOB 7 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB7 periph A */
+							 AT91_PIOB 9 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB9 periph A */
+							 AT91_PIOB 10 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PB10 periph A */
+					};
+
+					pinctrl_macb0_rmii_mii: macb0_rmii_mii-0 {
+						atmel,pins =
+							<AT91_PIOB 8 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB8 periph A */
+							 AT91_PIOB 11 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB11 periph A */
+							 AT91_PIOB 12 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB12 periph A */
+							 AT91_PIOB 13 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB13 periph A */
+							 AT91_PIOB 14 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB14 periph A */
+							 AT91_PIOB 15 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB15 periph A */
+							 AT91_PIOB 16 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB16 periph A */
+							 AT91_PIOB 17 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PB17 periph A */
+					};
+				};
+			};
+
+			pmc: pmc at fffffc00 {
+				periph: periphck {
+					macb0_clk at 24 {
+						id = <24>;
+					};
+				};
+			};
+
+			macb0: ethernet at f802c000 {
+				compatible = "cdns,at32ap7000-macb", "cdns,macb";
+				reg = <0xf802c000 0x100>;
+				interrupts = <24 IRQ_TYPE_LEVEL_HIGH 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_macb0_rmii>;
+				clocks = <&periph 24>, <&periph 24>;
+				clock-names = "hclk", "pclk";
+				status = "disabled";
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/at91sam9x5_macb1.dtsi b/arch/arm/boot/dts/at91sam9x5_macb1.dtsi
new file mode 100644
index 0000000..d20a680
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9x5_macb1.dtsi
@@ -0,0 +1,54 @@
+/*
+ * at91sam9x5_macb1.dtsi - Device Tree Include file for AT91SAM9x5 SoC with 2
+ * Ethernet interfaces.
+ *
+ * Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * Licensed under GPLv2.
+ */
+
+#include <dt-bindings/pinctrl/at91.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	ahb {
+		apb {
+			pinctrl at fffff400 {
+				macb1 {
+					pinctrl_macb1_rmii: macb1_rmii-0 {
+						atmel,pins =
+							<AT91_PIOC 16 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC16 periph B */
+							 AT91_PIOC 18 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC18 periph B */
+							 AT91_PIOC 19 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC19 periph B */
+							 AT91_PIOC 20 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC20 periph B */
+							 AT91_PIOC 21 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC21 periph B */
+							 AT91_PIOC 27 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC27 periph B */
+							 AT91_PIOC 28 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC28 periph B */
+							 AT91_PIOC 29 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC29 periph B */
+							 AT91_PIOC 30 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PC30 periph B */
+							 AT91_PIOC 31 AT91_PERIPH_B AT91_PINCTRL_NONE>;	/* PC31 periph B */
+					};
+				};
+			};
+
+			pmc: pmc at fffffc00 {
+				periph: periphck {
+					macb1_clk at 27 {
+						id = <27>;
+					};
+				};
+			};
+
+			macb1: ethernet at f8030000 {
+				compatible = "cdns,at32ap7000-macb", "cdns,macb";
+				reg = <0xf8030000 0x100>;
+				interrupts = <27 IRQ_TYPE_LEVEL_HIGH 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_macb1_rmii>;
+				clocks = <&periph 27>, <&periph 27>;
+				clock-names = "hclk", "pclk";
+				status = "disabled";
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/at91sam9x5_usart3.dtsi b/arch/arm/boot/dts/at91sam9x5_usart3.dtsi
new file mode 100644
index 0000000..292b276
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9x5_usart3.dtsi
@@ -0,0 +1,58 @@
+/*
+ * at91sam9x5_lcdc.dtsi - Device Tree Include file for AT91SAM9x5 SoC with
+ * 4 USART.
+ *
+ * Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * Licensed under GPLv2.
+ */
+
+/ {
+	ahb {
+		apb {
+			pinctrl at fffff400 {
+				usart3 {
+					pinctrl_usart3: usart3-0 {
+						atmel,pins =
+							<AT91_PIOC 22 AT91_PERIPH_B AT91_PINCTRL_PULL_UP	/* PC22 periph B with pullup */
+							 AT91_PIOC 23 AT91_PERIPH_B AT91_PINCTRL_NONE>;		/* PC23 periph B */
+					};
+
+					pinctrl_usart3_rts: usart3_rts-0 {
+						atmel,pins =
+							<AT91_PIOC 24 AT91_PERIPH_B AT91_PINCTRL_NONE>;		/* PC24 periph B */
+					};
+
+					pinctrl_usart3_cts: usart3_cts-0 {
+						atmel,pins =
+							<AT91_PIOC 25 AT91_PERIPH_B AT91_PINCTRL_NONE>;		/* PC25 periph B */
+					};
+
+					pinctrl_usart3_sck: usart3_sck-0 {
+						atmel,pins =
+							<AT91_PIOC 26 AT91_PERIPH_B AT91_PINCTRL_NONE>;		/* PC26 periph B */
+					};
+				};
+			};
+
+			pmc: pmc at fffffc00 {
+				periph: periphck {
+					usart3_clk at 8 {
+						id = <8>;
+					};
+				};
+			};
+
+			usart3: serial at f8028000 {
+				compatible = "atmel,at91sam9260-usart";
+				reg = <0xf8028000 0x200>;
+				interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_usart3>;
+				clocks = <&periph 8>;
+				clock-names = "usart";
+				status = "disabled";
+			};
+		};
+	};
+};
-- 
1.7.9.5



From mgreer at animalcreek.com  Wed Jul 17 12:10:23 2013
From: mgreer at animalcreek.com (Mark A. Greer)
Date: Wed, 17 Jul 2013 09:10:23 -0700
Subject: [PATCH 1/2] ARM: dts: Add SHAM data and documentation for AM33XX
In-Reply-To: <51E620AE.8090602@ti.com>
References: <1374017368-5267-1-git-send-email-mgreer@animalcreek.com>
 <1374017368-5267-2-git-send-email-mgreer@animalcreek.com>
 <51E620AE.8090602@ti.com>
Message-ID: <20130717161023.GA12124@animalcreek.com>

On Wed, Jul 17, 2013 at 10:12:22AM +0530, Lokesh Vutla wrote:
> Hi Mark,

Hi Lokesh.

> On Wednesday 17 July 2013 04:59 AM, Mark A. Greer wrote:
> > From: "Mark A. Greer" <mgreer at animalcreek.com>

> > diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
> > index 0c8ad17..b04aea1 100644
> > --- a/arch/arm/boot/dts/am335x-evmsk.dts
> > +++ b/arch/arm/boot/dts/am335x-evmsk.dts
> > @@ -401,4 +401,7 @@
> >  &cpsw_emac1 {
> >  	phy_id = <&davinci_mdio>, <1>;
> >  	phy-mode = "rgmii-txid";
> > +
> > +&sham {
> > +	status = "okay";
>  "};" is missing here.
> >  };

Ugh, yeah, I somehow mess that out.

Thanks for pointing that out.

Mark
--


From stern at rowland.harvard.edu  Wed Jul 17 12:17:24 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Wed, 17 Jul 2013 12:17:24 -0400 (EDT)
Subject: [PATCH v3 6/7] USB: ohci-at91: add usb_clk for transition to
 common clk framework
In-Reply-To: <51E6BC23.6020700@overkiz.com>
Message-ID: <Pine.LNX.4.44L0.1307171215000.1555-100000@iolanthe.rowland.org>

On Wed, 17 Jul 2013, boris brezillon wrote:

> On 17/07/2013 17:33, Alan Stern wrote:
> > On Tue, 16 Jul 2013, Boris BREZILLON wrote:
> >
> >> The AT91 PMC (Power Management Controller) provides an USB clock used by
> >> USB Full Speed host (ohci) and USB Full Speed device (udc).
> >> The usb drivers (ohci and udc) must configure this clock to 48Mhz.
> >> This configuration was formely done in mach-at91/clock.c, but this
> >> implementation will be removed when moving to common clk framework.
> >>
> >> This patch add support for usb clock retrieval and configuration, and is
> >> backward compatible with the current at91 clk implementation (if usb clk
> >> is not found, it does not configure/enable the usb clk).
> > This does not take into account any of the changes you discussed with
> > Russell King and me -- it is exactly the same as the previous version.
> Sorry, I don't understand. I didn't send any new version since yesterday.

Oh.  Never mind.  That message was the _same_ one that I replied to
yesterday.  I got two copies of it, because you sent it both to me
directly and to linux-usb.  For some reason one of the copies was
delayed for many hours, so I thought it was a new message.

Alan Stern



From Marc.Gauthier at tensilica.com  Wed Jul 17 12:17:19 2013
From: Marc.Gauthier at tensilica.com (Marc Gauthier)
Date: Wed, 17 Jul 2013 09:17:19 -0700
Subject: [Linux-Xtensa] Re: sched_clock always 0 and no process time
 accounting with 3.11-rc1
In-Reply-To: <20130717152443.GO24642@n2100.arm.linux.org.uk>
References: <CAMo8BfLO31GgMMA_hENr0xm=qaUz3EVLtaQ8hewiQHdbV+s6sA@mail.gmail.com>
 <20130717061925.GC6950@tarshish>
 <8572CFB6-0D88-46F4-B055-7834F8B9BDA5@tensilica.com>
 <20130717152443.GO24642@n2100.arm.linux.org.uk>
Message-ID: <522C1DF17AF50042AD8AE87F7887BD3D0B789F2A53@exch>

Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 08:15:08AM -0700, Marc Gauthier wrote:
> > Hi Baruch,
> >
> > On 2013-07-16, at 11:19 PM, Baruch Siach <baruch at tkos.co.il> wrote:
> > > -    sched_clock_mask = (1 << bits) - 1;
> > > +    sched_clock_mask = (1ULL << bits) - 1;
> >
> > Might it be more efficient to use:
> >
> >    sched_clock_mask = 0xffffffff >> (32 - bits);
> >
> > to avoid using 64 bit ints?
> > (assuming bits > 0, didn't check)
>
> bits being 0 would be rather silly (it implies a mask of
> zero, and therefore
> no bits available for the clock.)  We could modify the
> BUG_ON() above to
> make that point, or add it as commentry against the function.

Sounds good.


> Given that, and that sched_clock_mask is a u32, then I agree
> with you - the above would be a better way to do this.

> Personally, I'd suggest ~0u rather
> than 0xffffffff because its less typing.

Am not sure though, on machines with 64-bit int, ~0u might
end up being 0xffffffffffffffff which is unintended.

-Marc


From gregkh at linuxfoundation.org  Wed Jul 17 12:17:58 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Wed, 17 Jul 2013 09:17:58 -0700
Subject: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner's
 Security ID fuses
In-Reply-To: <20130717114650.GN3125@lukather>
References: <20130624181509.GA8847@kroah.com> <51C8B84C.3020200@schinagl.nl>
 <20130624214615.GA17604@kroah.com> <51CAA709.4060801@schinagl.nl>
 <20130626175144.GC2222@kroah.com> <51D674BF.9030207@schinagl.nl>
 <20130706193646.GB9778@kroah.com> <51E466A3.4010503@schinagl.nl>
 <20130716064107.GA10868@kroah.com> <20130717114650.GN3125@lukather>
Message-ID: <20130717161758.GA9822@kroah.com>

On Wed, Jul 17, 2013 at 01:46:50PM +0200, Maxime Ripard wrote:
> On Mon, Jul 15, 2013 at 11:41:07PM -0700, Greg KH wrote:
> > On Mon, Jul 15, 2013 at 11:16:19PM +0200, Oliver Schinagl wrote:
> > > So using these new patches for binary attributes, how can I pass data 
> > > between my driver and the sysfs files using a platform_driver? Or are 
> > > other 'hacks' needed and using the .groups attribute from 
> > > platform_driver->device_driver->groups is really the wrong approach.
> > > 
> > > I did ask around and still haven't figured it out so far, so I do 
> > > apologize if you feel I'm wasting your precious time.
> > 
> > How is the platform device not the same thing that was passed to your
> > probe function?
> 
> One thing I don't get here is why it should be set in the
> platform_driver structure. From my understanding of the device model,
> and since what Oliver is trying to do is exposing a few bytes of memory
> to sysfs, shouldn't the sysfs file be attached to the device instead?

It will be created by the driver core for any device attached to the
driver automatically.

> I mean, here, the sysfs file will be created under something like
> .../drivers/sunxi-sid/eeprom. What happens when you have several
> instances of that driver loaded? I'd expect it to have several sysfs
> files created, one for each instance. So to me, it should be in the
> device structure, not the driver one.

You can't have multiple drivers with the same name loaded (or the same
module loaded multiple times.)  You can have multiple devices for a
single driver, which is what we do all the time.

> Couldn't that be also the reason of Oliver's NULL pointer? If the kobj
> is attached to the platform_driver and not to the platform_device, it
> should definitely get nasty when we try to cast it and retrieve data
> from it (and that would match the different pointers stuff as well.)

No, he's getting a kobject that looks quite different at probe that is
different from when the file callback happens, something is odd here...

greg k-h


From mgreer at animalcreek.com  Wed Jul 17 12:23:41 2013
From: mgreer at animalcreek.com (Mark A. Greer)
Date: Wed, 17 Jul 2013 09:23:41 -0700
Subject: [PATCH v2 1/2] ARM: dts: Add SHAM data and documentation for AM33XX
In-Reply-To: <1374078222-12883-1-git-send-email-mgreer@animalcreek.com>
References: <1374078222-12883-1-git-send-email-mgreer@animalcreek.com>
Message-ID: <1374078222-12883-2-git-send-email-mgreer@animalcreek.com>

From: "Mark A. Greer" <mgreer at animalcreek.com>

Add the generic AM33XX SHAM module's device tree data and
enable it for the am335x-evm, am335x-evmsk, and am335x-bone
platforms.  Also add Documentation file describing the data
for the SHAM module.

CC: Paul Walmsley <paul at pwsan.com>
Signed-off-by: Mark A. Greer <mgreer at animalcreek.com>
---
 .../devicetree/bindings/crypto/omap-sham.txt       | 33 ++++++++++++++++++++++
 arch/arm/boot/dts/am335x-bone.dts                  |  4 +++
 arch/arm/boot/dts/am335x-evm.dts                   |  4 +++
 arch/arm/boot/dts/am335x-evmsk.dts                 |  4 +++
 arch/arm/boot/dts/am33xx.dtsi                      | 10 +++++++
 5 files changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/omap-sham.txt

diff --git a/Documentation/devicetree/bindings/crypto/omap-sham.txt b/Documentation/devicetree/bindings/crypto/omap-sham.txt
new file mode 100644
index 0000000..c6d1202
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/omap-sham.txt
@@ -0,0 +1,33 @@
+OMAP SoC SHA crypto Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+  SHAM versions:
+  - "ti,omap2-sham" for OMAP2 & OMAP3.
+  - "ti,omap4-sham" for OMAP4 and AM33XX.
+  Note that these two versions are incompatible.
+- ti,hwmods: Name of the hwmod associated with the SHAM module
+- reg : Offset and length of the register set for the module
+- interrupt-parent : the phandle for the interrupt controller that
+  services interrupts for this module.
+- interrupts : the interrupt number for the SHAM module.
+
+Optional properties:
+- dmas: DMA controller phandle and DMA request ordered pair.
+	Only one rx pair is valid per SHAM module.
+- dma-names: DMA request name. This string corresponds 1:1 with
+	the ordered pair in dmas. The string naming is to be
+	"rx" for RX request.
+
+Example:
+	/* AM335x */
+	sham: sham at 53100000 {
+		compatible = "ti,omap4-sham";
+		ti,hwmods = "sham";
+		reg = <0x53100000 0x200>;
+		interrupt-parent = <&intc>;
+		interrupts = <109>;
+		dmas = <&edma 36>;
+		dma-names = "rx";
+	};
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 444b4ed..bc75b2c 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -234,3 +234,7 @@
 	pinctrl-0 = <&davinci_mdio_default>;
 	pinctrl-1 = <&davinci_mdio_sleep>;
 };
+
+&sham {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 3aee1a4..9b8c56d 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -488,3 +488,7 @@
 		ti,adc-channels = <4 5 6 7>;
 	};
 };
+
+&sham {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 0c8ad17..61dc5d4 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -402,3 +402,7 @@
 	phy_id = <&davinci_mdio>, <1>;
 	phy-mode = "rgmii-txid";
 };
+
+&sham {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..63a5e95 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -530,5 +530,15 @@
 			#size-cells = <1>;
 			status = "disabled";
 		};
+
+		sham: sham at 53100000 {
+			compatible = "ti,omap4-sham";
+			ti,hwmods = "sham";
+			reg = <0x53100000 0x200>;
+			interrupt-parent = <&intc>;
+			interrupts = <109>;
+			dmas = <&edma 36>;
+			dma-names = "rx";
+		};
 	};
 };
-- 
1.7.12



From mgreer at animalcreek.com  Wed Jul 17 12:23:40 2013
From: mgreer at animalcreek.com (Mark A. Greer)
Date: Wed, 17 Jul 2013 09:23:40 -0700
Subject: [PATCH v2 0/2] ARM: dts: Add SHAM and AES DT information
Message-ID: <1374078222-12883-1-git-send-email-mgreer@animalcreek.com>

From: "Mark A. Greer" <mgreer at animalcreek.com>

Long overdue patches to add the device tree updates and
documentation for the SHAM and AES modules on the am33xx.
The supporting code is already in the mainline kernel.

This series is based on the current mainline kernel,
c0d15cc (linked-list: Remove __list_for_each).

Changes from v1:
 - Added missing '};' as pointed out by Lokesh Vutla <lokeshvutla at ti.com>

Mark A. Greer (2):
  ARM: dts: Add SHAM data and documentation for AM33XX
  ARM: dts: Add AES data and documentation for AM33XX

 .../devicetree/bindings/crypto/omap-aes.txt        | 35 ++++++++++++++++++++++
 .../devicetree/bindings/crypto/omap-sham.txt       | 33 ++++++++++++++++++++
 arch/arm/boot/dts/am335x-bone.dts                  |  8 +++++
 arch/arm/boot/dts/am335x-evm.dts                   |  8 +++++
 arch/arm/boot/dts/am335x-evmsk.dts                 |  8 +++++
 arch/arm/boot/dts/am33xx.dtsi                      | 21 +++++++++++++
 6 files changed, 113 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/omap-aes.txt
 create mode 100644 Documentation/devicetree/bindings/crypto/omap-sham.txt

-- 
1.7.12



From mgreer at animalcreek.com  Wed Jul 17 12:23:42 2013
From: mgreer at animalcreek.com (Mark A. Greer)
Date: Wed, 17 Jul 2013 09:23:42 -0700
Subject: [PATCH v2 2/2] ARM: dts: Add AES data and documentation for AM33XX
In-Reply-To: <1374078222-12883-1-git-send-email-mgreer@animalcreek.com>
References: <1374078222-12883-1-git-send-email-mgreer@animalcreek.com>
Message-ID: <1374078222-12883-3-git-send-email-mgreer@animalcreek.com>

From: "Mark A. Greer" <mgreer at animalcreek.com>

Add the generic AM33XX AES module's device tree data and
enable it for the am335x-evm, am335x-evmsk, and am335x-bone
platforms.  Also add Documentation file describing the data
for the AES module.

CC: Paul Walmsley <paul at pwsan.com>
Signed-off-by: Mark A. Greer <mgreer at animalcreek.com>
---
 .../devicetree/bindings/crypto/omap-aes.txt        | 35 ++++++++++++++++++++++
 arch/arm/boot/dts/am335x-bone.dts                  |  4 +++
 arch/arm/boot/dts/am335x-evm.dts                   |  4 +++
 arch/arm/boot/dts/am335x-evmsk.dts                 |  4 +++
 arch/arm/boot/dts/am33xx.dtsi                      | 11 +++++++
 5 files changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/omap-aes.txt

diff --git a/Documentation/devicetree/bindings/crypto/omap-aes.txt b/Documentation/devicetree/bindings/crypto/omap-aes.txt
new file mode 100644
index 0000000..b51d12f
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/omap-aes.txt
@@ -0,0 +1,35 @@
+OMAP SoC AES crypto Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+  AES versions:
+  - "ti,omap2-aes" for OMAP2.
+  - "ti,omap3-aes" for OMAP3.
+  - "ti,omap4-aes" for OMAP4 and AM33XX.
+  Note that the OMAP2 and 3 versions are compatible (OMAP3 supports
+  more algorithms) but they are incompatible with OMAP4.
+- ti,hwmods: Name of the hwmod associated with the AES odule
+- reg : Offset and length of the register set for the module
+- interrupt-parent : the phandle for the interrupt controller that
+  services interrupts for this module.
+- interrupts : the interrupt number for the AES odule.
+
+Optional properties:
+- dmas: DMA controller phandle and DMA request ordered pairs.
+- dma-names: DMA request names. This string corresponds 1:1 with
+	the ordered pairs in dmas. The string naming is to be
+	"tx" for TX request and "rx" for RX request.
+
+Example:
+	/* AM335x */
+	aes: aes at 53500000 {
+		compatible = "ti,omap4-aes";
+		ti,hwmods = "aes";
+		reg = <0x53500000 0xa0>;
+		interrupt-parent = <&intc>;
+		interrupts = <102>;
+		dmas = <&edma 6
+			&edma 5>;
+		dma-names = "tx", "rx";
+	};
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index bc75b2c..0cb454e 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -238,3 +238,7 @@
 &sham {
 	status = "okay";
 };
+
+&aes {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 9b8c56d..76ba004 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -492,3 +492,7 @@
 &sham {
 	status = "okay";
 };
+
+&aes {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 61dc5d4..025a47e 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -406,3 +406,7 @@
 &sham {
 	status = "okay";
 };
+
+&aes {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 63a5e95..2a7ff0f 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -540,5 +540,16 @@
 			dmas = <&edma 36>;
 			dma-names = "rx";
 		};
+
+		aes: aes at 53500000 {
+			compatible = "ti,omap4-aes";
+			ti,hwmods = "aes";
+			reg = <0x53500000 0xa0>;
+			interrupt-parent = <&intc>;
+			interrupts = <102>;
+			dmas = <&edma 6
+				&edma 5>;
+			dma-names = "tx", "rx";
+		};
 	};
 };
-- 
1.7.12



From cb at sgoc.de  Wed Jul 17 12:27:37 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Wed, 17 Jul 2013 18:27:37 +0200
Subject: [PATCH v2 0/3] mxs: add driver for On Chip OTP
In-Reply-To: <1372855154-8422-1-git-send-email-cb@sgoc.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
Message-ID: <1374078460-4126-1-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <cb at sgoc.de>

This patch brings read/write support for the On Chip OTP cells in the i.MX23
and i.MX28 processor. The driver uses files (one for each cell) in /sys/fsl_otp
as interface. The original code from Freescale was stripped down to the
required minimum and ported to 3.x kernels.

Christoph G. Baumann (3):
  mxs: enable ocotp in device tree
  mxs: register clkdev "hbus" as it is required by OCOTP driver
  mxs: added driver for OCOTP in i.MX23 and i.MX28

 arch/arm/boot/dts/imx23.dtsi |    1 -
 arch/arm/boot/dts/imx28.dtsi |    1 -
 drivers/clk/mxs/clk-imx23.c  |    2 +
 drivers/clk/mxs/clk-imx28.c  |    1 +
 drivers/misc/Kconfig         |   14 ++
 drivers/misc/Makefile        |    1 +
 drivers/misc/fsl_otp.c       |  363 ++++++++++++++++++++++++++++++++++++++++++
 drivers/misc/fsl_otp.h       |  126 +++++++++++++++
 8 files changed, 507 insertions(+), 2 deletions(-)
 create mode 100644 drivers/misc/fsl_otp.c
 create mode 100644 drivers/misc/fsl_otp.h

-- 
1.7.9.5



From cb at sgoc.de  Wed Jul 17 12:27:38 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Wed, 17 Jul 2013 18:27:38 +0200
Subject: [PATCH v2 1/3] mxs: enable ocotp in device tree
In-Reply-To: <1374078460-4126-1-git-send-email-cb@sgoc.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
 <1374078460-4126-1-git-send-email-cb@sgoc.de>
Message-ID: <1374078460-4126-2-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <cb at sgoc.de>

Signed-off-by: "Christoph G. Baumann" <cb at sgoc.de>
---
 arch/arm/boot/dts/imx23.dtsi |    1 -
 arch/arm/boot/dts/imx28.dtsi |    1 -
 2 files changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 587ceef..dc70ea9 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -348,7 +348,6 @@
 			ocotp at 8002c000 {
 				compatible = "fsl,ocotp";
 				reg = <0x8002c000 0x2000>;
-				status = "disabled";
 			};
 
 			axi-ahb at 8002e000 {
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 6a8acb0..968244a 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -748,7 +748,6 @@
 			ocotp at 8002c000 {
 				compatible = "fsl,ocotp";
 				reg = <0x8002c000 0x2000>;
-				status = "disabled";
 			};
 
 			axi-ahb at 8002e000 {
-- 
1.7.9.5



From mpfj-list at newflow.co.uk  Wed Jul 17 12:28:37 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Wed, 17 Jul 2013 17:28:37 +0100
Subject: ARM: AM335x: Kernel oops when using EDMA and MMC
In-Reply-To: <51E6BE84.6080905@newflow.co.uk>
References: <51E6BE84.6080905@newflow.co.uk>
Message-ID: <51E6C635.5020506@newflow.co.uk>

On 17/07/13 16:55, Mark Jackson wrote:
> I'm trying to get the MMC port working on our custom AM3352 CPU board.
> 
> I have added MMC entries to out dts file (similar to [1]), and I've
> enabled CONFIG_TI_EDMA.
> 
> Our board boots fine without an SD card inserted ...
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 3.11.0-rc1-00025-g95b9b72 (mpfj at mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #309 Wed Jul 17 16:37:28 BST 2013
> ...
> [    2.789028] VFS: Mounted root (ubifs filesystem) on device 0:12.
> [    2.797268] devtmpfs: mounted
> [    2.801032] Freeing unused kernel memory: 200K (c0551000 - c0583000)
> ...
> Welcome to Buildroot
> nanobone login:

I have just noticed the following in the boot log:-

...
[    1.225698] omap_hsmmc 48060000.mmc: unable to obtain RX DMA engine channel 3227000204
...


From cb at sgoc.de  Wed Jul 17 12:27:39 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Wed, 17 Jul 2013 18:27:39 +0200
Subject: [PATCH v2 2/3] mxs: register clkdev "hbus" as it is required by OCOTP
In-Reply-To: <1374078460-4126-1-git-send-email-cb@sgoc.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
 <1374078460-4126-1-git-send-email-cb@sgoc.de>
Message-ID: <1374078460-4126-3-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <cb at sgoc.de>

The OCOTP driver needs to switch the HBUS clock when burning OTP bits.
For this purpose it uses the CLK-API and requests a handler for "hbus".
Trying to burn bits without registered "hbus" CLK results in a blocked user
process.

Signed-off-by: "Christoph G. Baumann" <cb at sgoc.de>
---
 drivers/clk/mxs/clk-imx23.c |    2 ++
 drivers/clk/mxs/clk-imx28.c |    1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/clk/mxs/clk-imx23.c b/drivers/clk/mxs/clk-imx23.c
index f6a7487..ec76d00 100644
--- a/drivers/clk/mxs/clk-imx23.c
+++ b/drivers/clk/mxs/clk-imx23.c
@@ -168,6 +168,8 @@ int __init mx23_clocks_init(void)
 	clk_data.clk_num = ARRAY_SIZE(clks);
 	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
 
+	clk_register_clkdev(clks[hbus], NULL, "hbus");
+
 	for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
 		clk_prepare_enable(clks[clks_init_on[i]]);
 
diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c
index 4faf0af..792fcaf 100644
--- a/drivers/clk/mxs/clk-imx28.c
+++ b/drivers/clk/mxs/clk-imx28.c
@@ -247,6 +247,7 @@ int __init mx28_clocks_init(void)
 	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
 
 	clk_register_clkdev(clks[enet_out], NULL, "enet_out");
+	clk_register_clkdev(clks[hbus], NULL, "hbus");
 
 	for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
 		clk_prepare_enable(clks[clks_init_on[i]]);
-- 
1.7.9.5



From cb at sgoc.de  Wed Jul 17 12:27:40 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Wed, 17 Jul 2013 18:27:40 +0200
Subject: [PATCH v2 3/3] mxs: added driver for OCOTP in i.MX23 and i.MX28
In-Reply-To: <1374078460-4126-1-git-send-email-cb@sgoc.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
 <1374078460-4126-1-git-send-email-cb@sgoc.de>
Message-ID: <1374078460-4126-4-git-send-email-cb@sgoc.de>

From: "Christoph G. Baumann" <cb at sgoc.de>

Signed-off-by: "Christoph G. Baumann" <cb at sgoc.de>
---
 drivers/misc/Kconfig   |   14 ++
 drivers/misc/Makefile  |    1 +
 drivers/misc/fsl_otp.c |  363 ++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/misc/fsl_otp.h |  126 +++++++++++++++++
 4 files changed, 504 insertions(+)
 create mode 100644 drivers/misc/fsl_otp.c
 create mode 100644 drivers/misc/fsl_otp.h

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 8dacd4c..0740312 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -528,6 +528,20 @@ config SRAM
 	  the genalloc API. It is supposed to be used for small on-chip SRAM
 	  areas found on many SoCs.
 
+config FSL_OTP
+	tristate "Freescale On-Chip OTP Memory Support"
+	depends on SOC_IMX23 || SOC_IMX28
+	default n
+	help
+		If you say Y here, you will get support for a SysFS interface for
+		the One Time Programmable memory pages that are stored on the
+		iMX23/28 processor.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called fsl_otp.
+
+	  If unsure, it is safe to say N.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index c235d5b..e622e01 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_INTEL_MEI)		+= mei/
 obj-$(CONFIG_VMWARE_VMCI)	+= vmw_vmci/
 obj-$(CONFIG_LATTICE_ECP3_CONFIG)	+= lattice-ecp3-config.o
 obj-$(CONFIG_SRAM)		+= sram.o
+obj-$(CONFIG_FSL_OTP)           += fsl_otp.o
diff --git a/drivers/misc/fsl_otp.c b/drivers/misc/fsl_otp.c
new file mode 100644
index 0000000..7ae6ea0
--- /dev/null
+++ b/drivers/misc/fsl_otp.c
@@ -0,0 +1,363 @@
+/*
+ * Freescale On-Chip OTP driver
+ *
+ * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Huang Shijie <b32955 at freescale.com>
+ *
+ * Ported to 3.x by Christoph G. Baumann <cgb at debian.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ */
+#include <linux/kobject.h>
+#include <linux/string.h>
+#include <linux/sysfs.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/delay.h>
+#include <linux/fcntl.h>
+#include <linux/mutex.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+
+#include "fsl_otp.h"
+
+static DEFINE_MUTEX(otp_mutex);
+static struct kobject *otp_kobj;
+static struct attribute **attrs;
+static struct kobj_attribute *kattr;
+static struct attribute_group attr_group;
+static unsigned long otp_hclk_saved;
+static u32 otp_voltage_saved;
+static resource_size_t otp_base_address;
+struct regulator *regu;
+
+static struct fsl_otp_data otp_data = {
+	.fuse_name	= (char **)bank_reg_desc,
+	.regulator_name	= "vddio-sd0",
+	.fuse_num	= MXS_OTP_BANKS * MXS_OTP_BANK_ITEMS,
+};
+
+
+/* forward declaration */
+static int otp_wait_busy(u32 flags);
+
+/* open the bank for the imx23/imx28 */
+static int otp_read_prepare(void)
+{
+	int r;
+
+	/* [1] set the HCLK */
+	/* [2] check BUSY and ERROR bit */
+	r = otp_wait_busy(0);
+	if (r < 0)
+		goto error;
+
+	/* [3] open bank */
+	__raw_writel(BM_OCOTP_CTRL_RD_BANK_OPEN,
+		REGS_OCOTP_BASE + HW_OCOTP_CTRL_SET);
+	udelay(10);
+
+	/* [4] wait for BUSY */
+	r = otp_wait_busy(0);
+	return 0;
+error:
+	return r;
+}
+
+static int otp_read_post(void)
+{
+	/* [5] close bank */
+	__raw_writel(BM_OCOTP_CTRL_RD_BANK_OPEN,
+		REGS_OCOTP_BASE + HW_OCOTP_CTRL_CLR);
+	return 0;
+}
+
+static int otp_write_prepare(void)
+{
+	struct clk *hclk;
+	int err = 0;
+
+	/* [1] HCLK to 24MHz. */
+	hclk = clk_get_sys("hbus", NULL);
+	if (IS_ERR(hclk)) {
+		err = PTR_ERR(hclk);
+		goto out;
+	}
+	/*
+	   WARNING  ACHTUNG  UWAGA
+
+	   the code below changes HCLK clock rate to 24M. This is
+	   required to write OTP bits (7.2.2 in STMP378x Target
+	   Specification), and might affect LCD operation, for example.
+	   Moreover, this hacky code changes VDDIO to 2.8V; and resto-
+	   res it only on otp_close(). This may affect... anything.
+
+	   You are warned now.
+	 */
+	otp_hclk_saved = clk_get_rate(hclk);
+	clk_set_rate(hclk, 24000000);
+
+	/* [2] The voltage is set to 2.8V */
+	regu = regulator_get(NULL, otp_data.regulator_name);
+	otp_voltage_saved = regulator_get_voltage(regu);
+	regulator_set_voltage(regu, 2800000, 2800000);
+
+	/* [3] wait for BUSY and ERROR */
+	err = otp_wait_busy(BM_OCOTP_CTRL_RD_BANK_OPEN);
+out:
+	return err;
+}
+
+static int otp_write_post(void)
+{
+	struct clk *hclk;
+
+	hclk = clk_get_sys("hbus", NULL);
+	if (IS_ERR(hclk))
+		return PTR_ERR(hclk);
+
+	/* restore the clock and voltage */
+	clk_set_rate(hclk, otp_hclk_saved);
+	regulator_set_voltage(regu, otp_voltage_saved, otp_voltage_saved);
+	otp_wait_busy(0);
+
+	/* reset */
+	__raw_writel(BM_OCOTP_CTRL_RELOAD_SHADOWS,
+			REGS_OCOTP_BASE + HW_OCOTP_CTRL_SET);
+	otp_wait_busy(BM_OCOTP_CTRL_RELOAD_SHADOWS);
+	return 0;
+}
+
+static int __init map_ocotp_addr(struct platform_device *pdev)
+{
+	return 0;
+}
+static void unmap_ocotp_addr(void)
+{
+}
+
+static inline unsigned int get_reg_index(struct kobj_attribute *tmp)
+{
+	return tmp - kattr;
+}
+
+static int otp_wait_busy(u32 flags)
+{
+	int count;
+	u32 c;
+
+	for (count = 10000; count >= 0; count--) {
+		c = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CTRL);
+		if (!(c & (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR | flags)))
+			break;
+		cpu_relax();
+	}
+
+	if (count < 0)
+		return -ETIMEDOUT;
+	return 0;
+}
+
+static ssize_t otp_show(struct kobject *kobj, struct kobj_attribute *attr,
+		      char *buf)
+{
+	unsigned int index = get_reg_index(attr);
+	u32 value = 0;
+
+	/* sanity check */
+	if (index >= otp_data.fuse_num)
+		return 0;
+
+	mutex_lock(&otp_mutex);
+
+	if (otp_read_prepare()) {
+		mutex_unlock(&otp_mutex);
+		return 0;
+	}
+	value = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CUST_N(index));
+	otp_read_post();
+
+	mutex_unlock(&otp_mutex);
+	return sprintf(buf, "0x%x\n", value);
+}
+
+static int otp_write_bits(int addr, u32 data, u32 magic)
+{
+	u32 c; /* for control register */
+
+	/* init the control register */
+	c = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CTRL);
+	c &= ~BM_OCOTP_CTRL_ADDR;
+	c |= BF(addr, OCOTP_CTRL_ADDR);
+	c |= BF(magic, OCOTP_CTRL_WR_UNLOCK);
+	__raw_writel(c, REGS_OCOTP_BASE + HW_OCOTP_CTRL);
+
+	/* init the data register */
+	__raw_writel(data, REGS_OCOTP_BASE + HW_OCOTP_DATA);
+	otp_wait_busy(0);
+
+	mdelay(2); /* Write Postamble */
+	return 0;
+}
+
+static ssize_t otp_store(struct kobject *kobj, struct kobj_attribute *attr,
+		       const char *buf, size_t count)
+{
+	unsigned int index = get_reg_index(attr);
+	int value;
+
+	/* sanity check */
+	if (index >= otp_data.fuse_num)
+		return 0;
+
+	sscanf(buf, "0x%x", &value);
+
+	mutex_lock(&otp_mutex);
+	if (otp_write_prepare()) {
+		mutex_unlock(&otp_mutex);
+		return 0;
+	}
+	otp_write_bits(index, value, 0x3e77);
+	otp_write_post();
+	mutex_unlock(&otp_mutex);
+
+	return count;
+}
+
+static void free_otp_attr(void)
+{
+	kfree(attrs);
+	attrs = NULL;
+
+	kfree(kattr);
+	kattr = NULL;
+}
+
+static int alloc_otp_attr(void)
+{
+	int i;
+
+	/* The last one is NULL, which is used to detect the end */
+	attrs = kzalloc((otp_data.fuse_num + 1) * sizeof(attrs[0]),
+			GFP_KERNEL);
+	kattr = kzalloc(otp_data.fuse_num * sizeof(struct kobj_attribute),
+			GFP_KERNEL);
+
+	if (!attrs || !kattr)
+		goto error_out;
+
+	for (i = 0; i < otp_data.fuse_num; i++) {
+		kattr[i].attr.name = otp_data.fuse_name[i];
+		kattr[i].attr.mode = 0600;
+		kattr[i].show  = otp_show;
+		kattr[i].store = otp_store;
+		attrs[i] = &kattr[i].attr;
+		sysfs_attr_init(attrs[i]);
+	}
+	memset(&attr_group, 0, sizeof(attr_group));
+	attr_group.attrs = attrs;
+	return 0;
+
+error_out:
+	free_otp_attr();
+	return -ENOMEM;
+}
+
+static int fsl_otp_probe(struct platform_device *pdev)
+{
+	int retval;
+	struct fsl_otp_data *pdata;
+
+	/* get device base address */
+	otp_base_address = pdev->resource->start;
+	dev_info(&pdev->dev, "i.MX23/28 OCOTP at %p\n", otp_base_address);
+
+	pdata = &otp_data;
+	if (pdev->dev.platform_data == NULL)
+		pdev->dev.platform_data = &otp_data;
+
+	retval = alloc_otp_attr();
+	if (retval)
+		return retval;
+
+	retval = map_ocotp_addr(pdev);
+	if (retval)
+		goto error;
+
+	otp_kobj = kobject_create_and_add("fsl_otp", NULL);
+	if (!otp_kobj) {
+		retval = -ENOMEM;
+		goto error;
+	}
+
+	retval = sysfs_create_group(otp_kobj, &attr_group);
+	if (retval)
+		goto error;
+
+	mutex_init(&otp_mutex);
+	return 0;
+error:
+	kobject_put(otp_kobj);
+	otp_kobj = NULL;
+	free_otp_attr();
+	unmap_ocotp_addr();
+	return retval;
+}
+
+static int otp_remove(struct platform_device *pdev)
+{
+	kobject_put(otp_kobj);
+	otp_kobj = NULL;
+
+	free_otp_attr();
+	unmap_ocotp_addr();
+	return 0;
+}
+
+static const struct of_device_id mxs_otp_dt_ids[] = {
+	{ .compatible = "fsl,ocotp", .data = NULL, },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mxs_otp_dt_ids);
+
+static struct platform_driver ocotp_driver = {
+	.probe		= fsl_otp_probe,
+	.remove		= otp_remove,
+	.driver		= {
+		.name   = "ocotp",
+		.owner	= THIS_MODULE,
+		.of_match_table = mxs_otp_dt_ids,
+	},
+};
+
+static int __init fsl_otp_init(void)
+{
+	return platform_driver_register(&ocotp_driver);
+}
+
+static void __exit fsl_otp_exit(void)
+{
+	platform_driver_unregister(&ocotp_driver);
+}
+module_init(fsl_otp_init);
+module_exit(fsl_otp_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Christoph G. Baumann <cgb at debian.org>");
+MODULE_DESCRIPTION("driver for OCOTP in i.MX23 and i.MX28");
diff --git a/drivers/misc/fsl_otp.h b/drivers/misc/fsl_otp.h
new file mode 100644
index 0000000..9449f94
--- /dev/null
+++ b/drivers/misc/fsl_otp.h
@@ -0,0 +1,126 @@
+/*
+ * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Ported to 3.7 by Christoph G. Baumann <cgb at debian.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+#ifndef __FREESCALE_OTP__
+#define __FREESCALE_OTP__
+
+
+/* IMX23 and IMX28 share most of the defination ========================= */
+#if (defined(CONFIG_SOC_IMX23) || defined(CONFIG_SOC_IMX28))
+
+#if defined(CONFIG_SOC_IMX28) && defined(CONFIG_SOC_IMX23)
+#undef CONFIG_SOC_IMX23
+#endif
+
+
+#define OCOTP_PHYS_ADDR         otp_base_address
+#define REGS_OCOTP_BASE		(MXS_IO_ADDRESS(OCOTP_PHYS_ADDR))
+#define BF(value, field)	(((value) << BP_##field) & BM_##field)
+
+/* MXS IO mappings */
+
+/*
+ * It maps the whole address space to [0xf4000000, 0xf50fffff].
+ *
+ *	OCRAM	0x00000000+0x020000	->	0xf4000000+0x020000
+ *	IO	0x80000000+0x100000	->	0xf5000000+0x100000
+ */
+#define MXS_IO_P2V(x)	(0xf4000000 +					\
+			(((x) & 0x80000000) >> 7) +			\
+			(((x) & 0x000fffff)))
+
+#define MXS_IO_ADDRESS(x)	IOMEM(MXS_IO_P2V(x))
+
+
+/* OCOTP registers and bits */
+#define HW_OCOTP_CTRL		(0x00000000)
+#define HW_OCOTP_CTRL_SET	(0x00000004)
+#define HW_OCOTP_CTRL_CLR	(0x00000008)
+#define HW_OCOTP_CTRL_TOG	(0x0000000c)
+
+#define BM_OCOTP_CTRL_RELOAD_SHADOWS	0x00002000
+#define BM_OCOTP_CTRL_RD_BANK_OPEN	0x00001000
+#define BM_OCOTP_CTRL_ERROR		0x00000200
+#define BM_OCOTP_CTRL_BUSY		0x00000100
+#define BP_OCOTP_CTRL_ADDR		0
+#if defined(CONFIG_SOC_IMX28)
+#define BM_OCOTP_CTRL_ADDR		0x0000003F
+#endif
+#if defined(CONFIG_SOC_IMX23)
+#define BM_OCOTP_CTRL_ADDR		0x0000001F
+#endif
+#define BP_OCOTP_CTRL_WR_UNLOCK		16
+#define BM_OCOTP_CTRL_WR_UNLOCK		0xFFFF0000
+
+#define HW_OCOTP_DATA	(0x00000010)
+
+#define HW_OCOTP_CUST_N(n)	(0x00000020 + (n) * 0x10)
+#define BP_OCOTP_CUST_N_BITS	0
+#define BM_OCOTP_CUST_N_BITS	0xFFFFFFFF
+#define BF_OCOTP_CUST_N_BITS(v)	(v)
+
+
+
+#if defined(CONFIG_SOC_IMX28)
+/* Building up eight registers's names of a bank */
+#define MXS_OTP_BANK(a, b, c, d, e, f, g, h)	\
+	{\
+	("HW_OCOTP_"#a), ("HW_OCOTP_"#b), ("HW_OCOTP_"#c), ("HW_OCOTP_"#d), \
+	("HW_OCOTP_"#e), ("HW_OCOTP_"#f), ("HW_OCOTP_"#g), ("HW_OCOTP_"#h) \
+	}
+
+#define MXS_OTP_BANKS		(5)
+#define MXS_OTP_BANK_ITEMS	(8)
+static const char *bank_reg_desc[MXS_OTP_BANKS][MXS_OTP_BANK_ITEMS] = {
+MXS_OTP_BANK(CUST0, CUST1, CUST2, CUST3, CRYPTO0, CRYPTO1, CRYPTO2, CRYPTO3),
+MXS_OTP_BANK(HWCAP0, HWCAP1, HWCAP2, HWCAP3, HWCAP4, HWCAP5, SWCAP, CUSTCAP),
+MXS_OTP_BANK(LOCK, OPS0, OPS1, OPS2, OPS3, UN0, UN1, UN2),
+MXS_OTP_BANK(ROM0, ROM1, ROM2, ROM3, ROM4, ROM5, ROM6, ROM7),
+MXS_OTP_BANK(SRK0, SRK1, SRK2, SRK3, SRK4, SRK5, SRK6, SRK7),
+};
+#endif /* if defined(CONFIG_SOC_IMX28) */
+
+
+#if defined(CONFIG_SOC_IMX23)
+/* Building up eight registers's names of a bank */
+#define MXS_OTP_BANK(a, b, c, d, e, f, g, h)	\
+	{\
+	("HW_OCOTP_"#a), ("HW_OCOTP_"#b), ("HW_OCOTP_"#c), ("HW_OCOTP_"#d), \
+	("HW_OCOTP_"#e), ("HW_OCOTP_"#f), ("HW_OCOTP_"#g), ("HW_OCOTP_"#h) \
+	}
+
+#define MXS_OTP_BANKS		(4)
+#define MXS_OTP_BANK_ITEMS	(8)
+static const char *bank_reg_desc[MXS_OTP_BANKS][MXS_OTP_BANK_ITEMS] = {
+MXS_OTP_BANK(CUST0, CUST1, CUST2, CUST3, CRYPTO0, CRYPTO1, CRYPTO2, CRYPTO3),
+MXS_OTP_BANK(HWCAP0, HWCAP1, HWCAP2, HWCAP3, HWCAP4, HWCAP5, SWCAP, CUSTCAP),
+MXS_OTP_BANK(LOCK, OPS0, OPS1, OPS2, OPS3, UN0, UN1, UN2),
+MXS_OTP_BANK(ROM0, ROM1, ROM2, ROM3, ROM4, ROM5, ROM6, ROM7),
+};
+
+#endif/* if defined(CONFIG_SOC_IMX23) */
+
+struct fsl_otp_data {
+	char		**fuse_name;
+	char		*regulator_name;
+	unsigned int	fuse_num;
+};
+
+#endif /* (defined(CONFIG_SOC_IMX23) || defined(CONFIG_SOC_IMX28)) */
+#endif
-- 
1.7.9.5



From torvalds at linux-foundation.org  Wed Jul 17 12:36:57 2013
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Wed, 17 Jul 2013 09:36:57 -0700
Subject: [PATCH] arm, kbuild: make "make install" not depend on vmlinux
In-Reply-To: <20130717160506.GI8731@rric.localhost>
References: <20130710133742.GA29368@emu.suse.cz>
 <CA+55aFxtvT3Yvbxe5JGBThZS13payymFJ7jCLyEiE2iNDvsZtQ@mail.gmail.com>
 <20130711135445.GA21500@sepie.suse.cz>
 <CA+55aFyVjugxM7cUDWi0ASWttYthCxa6e7X3CADknBcSFxWgew@mail.gmail.com>
 <20130712105721.GF8731@rric.localhost>
 <20130717160506.GI8731@rric.localhost>
Message-ID: <CA+55aFx4G5gME3ByqE0Wr-_t2x_6WkP3Ta4k1z4jfW+PrcK0og@mail.gmail.com>

On Wed, Jul 17, 2013 at 9:05 AM, Robert Richter <rric at kernel.org> wrote:
>
> I narrowed this down. The problem is that zinstall on ARCH=arm has a
> dependency to vmlinux which does a prepare/prepare3 and finally does a
> forced rebuild of kernel.release even if it exists already.
>
> Rebuilding it removes kernel.release first and then recreates it. This
> might race with another parallel make job running depmod.
>
> So on arm and maybe other archs we need the same as for x86:
>
>  1648e4f8 x86, kbuild: make "make install" not depend on vmlinux
>
> The patch below fixes this for arm. It is build-tested in my
> environment, but please test it in others too if possible.

Ack. This looks like the right thing to do.

That said, I think for clarity you might perhaps want to make the
unrelated change of adding double quotes around $(KERNELRELEASE) a
separate patch. Not a big deal, but it took me a moment to say "why
did he do that" (in fact, I'm not sure KERNEL_RELEASE can actually
validly have spaces in it, but quoting it is certainly not wrong
either - but it might be unnecessary.

              Linus


From joelf at ti.com  Wed Jul 17 12:38:35 2013
From: joelf at ti.com (Joel Fernandes)
Date: Wed, 17 Jul 2013 11:38:35 -0500
Subject: ARM: AM335x: Kernel oops when using EDMA and MMC
In-Reply-To: <51E6BE84.6080905@newflow.co.uk>
References: <51E6BE84.6080905@newflow.co.uk>
Message-ID: <51E6C88B.8090608@ti.com>

On 07/17/2013 10:55 AM, Mark Jackson wrote:
> I'm trying to get the MMC port working on our custom AM3352 CPU board.
> 
> I have added MMC entries to out dts file (similar to [1]), and I've
> enabled CONFIG_TI_EDMA.
> 
> Our board boots fine without an SD card inserted ...
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 3.11.0-rc1-00025-g95b9b72 (mpfj at mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #309 Wed Jul 17 16:37:28 BST 2013
> ...
> [    2.789028] VFS: Mounted root (ubifs filesystem) on device 0:12.
> [    2.797268] devtmpfs: mounted
> [    2.801032] Freeing unused kernel memory: 200K (c0551000 - c0583000)
> ...
> Welcome to Buildroot
> nanobone login:
> 
> But when I boot with a card already inserted, I get the following oops ...
> 
> ...
> [    1.827343] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
> [    1.835868] pgd = c0004000
> [    1.838774] [0000000c] *pgd=00000000
> [    1.842556] Internal error: Oops: 5 [#1] ARM
> [    1.847063] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.11.0-rc1-00025-g95b9b72 #309
> [    1.855511] Workqueue: kmmcd mmc_rescan
> [    1.859556] task: cf06a080 ti: cf072000 task.ti: cf072000
> [    1.865257] PC is at omap_hsmmc_start_command+0x74/0xf4
> [    1.870761] LR is at omap_hsmmc_request+0xec/0x4dc
> [    1.875806] pc : [<c0305b70>]    lr : [<c0306c64>]    psr: 60000113
> [    1.875806] sp : cf073ca0  ip : 00000000  fp : 00000008
> [    1.887885] r10: cf073de8  r9 : 00000001  r8 : cf11d918
> [    1.893382] r7 : 00000003  r6 : cf33cc80  r5 : 00000001  r4 : 00000033
> [    1.900250] r3 : 00020000  r2 : cf073db8  r1 : cf073d84  r0 : cf33cc80
> [    1.907122] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> [    1.914813] Control: 10c5387d  Table: 80004019  DAC: 00000015
> [    1.920859] Process kworker/u2:0 (pid: 6, stack limit = 0xcf072238)
> [    1.927454] Stack: (0xcf073ca0 to 0xcf074000)
> [    1.932048] 3ca0: cf33c800 cf073d40 00000003 00000000 c0076a8c cf073d40 48060220 48060220
> [    1.940659] 3cc0: 00000004 00000004 00000002 00000002 cf073ec8 c0421a9c c051835c cf073d40
> [    1.949271] 3ce0: cf33c800 00000001 00000008 00000008 00000002 cf073db8 cf073ec8 c02f0f28
> [    1.957882] 3d00: 00000200 00000064 00000000 cf073db8 cf073ec8 cf073d40 cf073d50 00000000
> [    1.966493] 3d20: cf33c800 c02f18a4 cf369800 cf369a80 00000000 cf360880 00000008 c02f9964
> [    1.975104] 3d40: 00000000 cf073d84 cf073db8 00000000 00000001 00000001 dead4ead ffffffff
> [    1.983717] 3d60: ffffffff c0af722c c06aa3e4 00000000 c04ddadc cf073d74 cf073d74 c02f0dc4
> [    1.992327] 3d80: 00000000 00000033 00000000 00000000 00000000 00000000 00000000 000000b5
> [    2.000938] 3da0: 00000000 00000000 00000000 00000000 cf073db8 cf073d40 05f5e100 00000000
> [    2.009548] 3dc0: 00000008 00000001 00000000 00000200 00000000 00000000 cf073d40 00000001
> [    2.018159] 3de0: cf073de8 00000000 c0cf1c02 00000880 00000008 8f360880 00000000 cf369800
> [    2.026771] 3e00: cf33c800 00000000 cf369800 cf073e4c cf072000 c02f8740 00000000 00000015
> [    2.035382] 3e20: 00000003 cf33c800 00000000 00000000 cf369800 cf073e4c cf072000 c02f8b20
> [    2.043994] 3e40: 00000002 c02f25cc 00000002 02544d53 41303447 1026c914 2600bbbd c0ff8000
> [    2.052605] 3e60: c0455884 cf33c800 00000000 c0455884 c0455890 00000000 cf072000 c02f92bc
> [    2.061217] 3e80: c0455890 00ff8000 00000002 cf33cb14 cf33c800 c02f3a28 cf041ac0 cf33cb14
> [    2.069829] 3ea0: cf050c00 cf051c00 00000000 c00507ec 00000002 00000000 c0050778 c0050f10
> [    2.078441] 3ec0: 00000000 00000000 c0af7268 c06aa1c4 00000000 c0518cd0 cf06a080 cf041ac0
> [    2.087054] 3ee0: cf050c00 cf072000 cf050c30 cf041ad8 00000089 c05d7b5c cf050c00 c0050e4c
> [    2.095665] 3f00: 00000000 cf072000 60000113 cf04dda8 00000000 cf041ac0 c0050d08 00000000
> [    2.104276] 3f20: 00000000 00000000 00000000 c0056c94 c0429a18 00000000 00000001 cf041ac0
> [    2.112888] 3f40: 00000000 00000001 dead4ead ffffffff ffffffff c05ec0a0 00000000 00000000
> [    2.121499] 3f60: c04ddadc cf073f64 cf073f64 00000000 00000001 dead4ead ffffffff ffffffff
> [    2.130112] 3f80: c05ec0a0 00000000 00000000 c04ddadc cf073f90 cf073f90 cf073fac cf04dda8
> [    2.138724] 3fa0: c0056bf0 00000000 00000000 c0013588 00000000 00000000 00000000 00000000
> [    2.147334] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    2.155946] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 57e0c5db 5ffb7d3c
> [    2.164565] [<c0305b70>] (omap_hsmmc_start_command+0x74/0xf4) from [<00000003>] (0x3)
> [    2.172814] Code: 13a03801 0a00001b e590c008 e5914000 (e59cc00c)
> [    2.179314] ---[ end trace 6ec9899a56aef6aa ]---
> 
> I have also noticed that when the kernel boots okay (without a card inserted), if
> I then insert a card, nothing happens (even with CONFIG_MMC_DEBUG=y) ... including
> no kernel oops.
> 
> Can anyone shed light on what's wrong ?

I see this issue too on -rc1. The mmc host pointer is mangled but this could be
due to something totally unrelated.

Can you first please try rebasing on 3.10 instead of 3.11-rc1?

Thanks,

-Joel


From b.brezillon at overkiz.com  Wed Jul 17 12:39:29 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Wed, 17 Jul 2013 18:39:29 +0200
Subject: [PATCH v2 02/42] ARM: at91: add PMC main clock
In-Reply-To: <1374068404-13654-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <1374068404-13654-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <51E6C8C1.4050401@overkiz.com>

On 17/07/2013 15:40, Boris BREZILLON wrote:
> This is the at91 main oscillator clock implementation using common
> clk framework.
>
> If rate is not provided during clock registraction it is computed using
> the slow clock (main clk parent in this case) rate and the MCFR register.
>
> Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
> ---
>   drivers/clk/at91/Makefile   |    5 ++
>   drivers/clk/at91/clk-main.c |  106 +++++++++++++++++++++++++++++++++++++++++++
>   include/linux/clk/at91.h    |   10 ++++
>   3 files changed, 121 insertions(+)
>   create mode 100644 drivers/clk/at91/Makefile
>   create mode 100644 drivers/clk/at91/clk-main.c
>
> diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
> new file mode 100644
> index 0000000..42c084e
> --- /dev/null
> +++ b/drivers/clk/at91/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for at91 specific clk
> +#
> +
> +obj-y += clk-main.o
> diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
> new file mode 100644
> index 0000000..738fa39
> --- /dev/null
> +++ b/drivers/clk/at91/clk-main.c
> @@ -0,0 +1,106 @@
> +/*
> + * drivers/clk/at91/clk-main.c
> + *
> + *  Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
> + *
> + * This mainram is free software; you can redistribute it and/or modify
                  ^program not mainram

This typo error is still present in pll, main and master clock 
implementations.
I will fix it for the next version.

> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk/at91.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/io.h>
> +
> +#define to_clk_main(hw) container_of(hw, struct clk_main, hw)
> +struct clk_main {
> +	struct clk_hw hw;
> +	unsigned long rate;
> +};
> +
> +static unsigned long clk_main_recalc_rate(struct clk_hw *hw,
> +					  unsigned long parent_rate)
> +{
> +	u32 tmp;
> +	struct clk_main *clkmain = to_clk_main(hw);
> +	if (clkmain->rate)
> +		return clkmain->rate;
> +	while ((tmp = at91_pmc_read(AT91_CKGR_MCFR)) & AT91_PMC_MAINRDY)
> +		;
> +	tmp &= AT91_PMC_MAINF;
> +	clkmain->rate = (tmp * parent_rate) / 16;
> +	return clkmain->rate;
> +}
> +
> +static const struct clk_ops main_ops = {
> +	.recalc_rate = clk_main_recalc_rate,
> +};
> +
> +struct clk * __init
> +at91_clk_register_main(const char *name,
> +		       const char *parent_name,
> +		       unsigned long rate)
> +{
> +	struct clk_main *clkmain;
> +	struct clk *clk = NULL;
> +	struct clk_init_data init;
> +
> +	if (!rate && !parent_name)
> +		return ERR_PTR(-EINVAL);
> +
> +	clkmain = kzalloc(sizeof(*clkmain), GFP_KERNEL);
> +	if (!clkmain)
> +		return ERR_PTR(-ENOMEM);
> +
> +	init.name = name;
> +	init.ops = &main_ops;
> +	init.parent_names = parent_name ? &parent_name : NULL;
> +	init.num_parents = parent_name ? 1 : 0;
> +	init.flags = parent_name ? 0 : CLK_IS_ROOT;
> +
> +	clkmain->hw.init = &init;
> +	clkmain->rate = rate;
> +
> +	clk = clk_register(NULL, &clkmain->hw);
> +
> +	if (IS_ERR(clk))
> +		kfree(clkmain);
> +
> +	return clk;
> +}
> +
> +
> +
> +#if defined(CONFIG_OF)
> +static void __init
> +of_at91_clk_main_setup(struct device_node *np)
> +{
> +	struct clk *clk;
> +	const char *parent_name;
> +	const char *name = np->name;
> +	u32 rate = 0;
> +
> +	parent_name = of_clk_get_parent_name(np, 0);
> +	of_property_read_string(np, "clock-output-names", &name);
> +	of_property_read_u32(np, "clock-frequency", &rate);
> +
> +	clk = at91_clk_register_main(name, parent_name, rate);
> +
> +	if (!IS_ERR(clk))
> +		return;
> +
> +	of_clk_add_provider(np, of_clk_src_simple_get, clk);
> +}
> +
> +static void __init of_at91rm9200_clk_main_setup(struct device_node *np)
> +{
> +	of_at91_clk_main_setup(np);
> +}
> +CLK_OF_DECLARE(at91rm9200_clk_main, "atmel,at91rm9200-clk-main",
> +	       of_at91rm9200_clk_main_setup);
> +#endif
> diff --git a/include/linux/clk/at91.h b/include/linux/clk/at91.h
> index 0ce9586..8e83942 100644
> --- a/include/linux/clk/at91.h
> +++ b/include/linux/clk/at91.h
> @@ -16,6 +16,8 @@
>   #ifndef AT91_PMC_H
>   #define AT91_PMC_H
>
> +#include <linux/clk-provider.h>
> +
>   #ifndef __ASSEMBLY__
>   extern void __iomem *at91_pmc_base;
>
> @@ -187,4 +189,12 @@ extern void __iomem *at91_pmc_base;
>   #define			AT91_PMC_PCR_DIV8	0x3			/* Peripheral clock is MCK/8 */
>   #define		AT91_PMC_PCR_EN		(0x1  <<  28)		/* Enable */
>
> +
> +
> +
> +struct clk * __init
> +at91_clk_register_main(const char *name,
> +		       const char *parent_name,
> +		       unsigned long rate);
> +
>   #endif



From grygorii.strashko at ti.com  Wed Jul 17 12:41:29 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Wed, 17 Jul 2013 19:41:29 +0300
Subject: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for
 uart3/4
In-Reply-To: <20130717153248.GI7656@atomide.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
 <1374061312-25469-4-git-send-email-grygorii.strashko@ti.com>
 <20130717153248.GI7656@atomide.com>
Message-ID: <51E6C939.40208@ti.com>

Hi,

On 07/17/2013 06:32 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko at ti.com> [130717 04:49]:
>> Add dynamic "active"/"idle" pin states for uart3/4 which will be applied
>> when uart3/4 state is switched from active to idle and back by Runtime
>> PM or during system suspend.
>
> This is good for testing code, but should not be merged because
> omap4 has the iopad wake-ups available for uarts. So those can
> be always enabled.

In this case, 2 IRQ will be received per each UART RX event - one from
PRCM and from UART - and that's not good from PM perspective (It will
affect on CPUIdle and CPUFreq at least).

-- log when wake-up enabled always
106:        729          0       GIC 106  OMAP UART2
115:         13          0       GIC 115  mmc0
118:         68          0       GIC 118  mmc1
151:          0          0       GIC 151  twl6040
361:        322          0      PRCM  hwmod_io
             ^^^^
-- log when wake-up enabled only when UART3 (console) is active
106:       1104          0       GIC 106  OMAP UART2
115:         13          0       GIC 115  mmc0
118:         68          0       GIC 118  mmc1
151:          0          0       GIC 151  twl6040
361:          7          0      PRCM  hwmod_io

The same is valid for all devices which will leave WAKEUP_EN set
all the time (

>
>> --- a/arch/arm/boot/dts/omap4-sdp.dts
>> +++ b/arch/arm/boot/dts/omap4-sdp.dts
>> @@ -181,18 +181,40 @@
>>   		pinctrl-single,pins = <
>>   			0x100 (PIN_INPUT_PULLUP | MUX_MODE0)	/* uart3_cts_rctx.uart3_cts_rctx */
>>   			0x102 (PIN_OUTPUT | MUX_MODE0)		/* uart3_rts_sd.uart3_rts_sd */
>> -			0x104 (PIN_INPUT | MUX_MODE0)		/* uart3_rx_irrx.uart3_rx_irrx */
>>   			0x106 (PIN_OUTPUT | MUX_MODE0)		/* uart3_tx_irtx.uart3_tx_irtx */
>>   		>;
>>   	};
>
> This just need to become:
> 		pinctrl-single,pins = <
> 			...
> 			0x104 (WAKEUP_EN | PIN_INPUT_MUX_MODE0)	/* uart3_rx_irrx.uart3_rx_irrx */
> 			...
> 		>;
> 		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
> 	};
>
> And so on. For am33xx you need to remux things to GPIO for the wake-up
> events, so you should maybe test on that instead.
>
> Regards,
>
> Tony
>

Regards,
- grygorii


From nm at ti.com  Wed Jul 17 12:45:36 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 17 Jul 2013 11:45:36 -0500
Subject: [PATCH 7/9] ARM: dts: omap5-uevm: update LDO6 voltage to 1.2V
In-Reply-To: <1374079538-19548-1-git-send-email-nm@ti.com>
References: <1374079538-19548-1-git-send-email-nm@ti.com>
Message-ID: <1374079538-19548-8-git-send-email-nm@ti.com>

commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.

LDO6 supplies the board specified VDDS_1V2_WKUP supply going to
ldo_emu_wkup/vdds_hsic. To stay within the SoC specification supply
1.2V instead of 1.5V.

Reported-by: Marc J?ttner <m-juettner at ti.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
 arch/arm/boot/dts/omap5-uevm.dts |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 1550d6a..3ff5874 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -388,8 +388,8 @@
 				ldo6_reg: ldo6 {
 					/* VDDS_1V2_WKUP: hsic/ldo_emu_wkup */
 					regulator-name = "ldo6";
-					regulator-min-microvolt = <1500000>;
-					regulator-max-microvolt = <1500000>;
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
 					regulator-always-on;
 					regulator-boot-on;
 				};
-- 
1.7.9.5



From nm at ti.com  Wed Jul 17 12:45:37 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 17 Jul 2013 11:45:37 -0500
Subject: [PATCH 8/9] ARM: dts: omap5-uevm: update LDO7 voltage to 2V and
 settings
In-Reply-To: <1374079538-19548-1-git-send-email-nm@ti.com>
References: <1374079538-19548-1-git-send-email-nm@ti.com>
Message-ID: <1374079538-19548-9-git-send-email-nm@ti.com>

commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.

LDO4 supplies VDD_VPP which is vpp1. This is currently configured for
1.5V which as per data manual "A pulse width of 1000 ns and an amplitude
of 2V is required to program each eFuse bit. Otherwise, VPP1 must not
be supplied".

So, fix the voltage to 2V. and disable the supply since we have no plans
of programming efuse bits - it can only be done once - in factory.

Further it is not enabled by default by PMIC so, 'boot-on' must be
removed, and the 'always-on' needs to be removed to achieve pulsing
if efuse needs to be programmed.

Reported-by: Marc J?ttner <m-juettner at ti.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
 arch/arm/boot/dts/omap5-uevm.dts |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 3ff5874..ef05676 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -397,10 +397,10 @@
 				ldo7_reg: ldo7 {
 					/* VDD_VPP: vpp1 */
 					regulator-name = "ldo7";
-					regulator-min-microvolt = <1500000>;
-					regulator-max-microvolt = <1500000>;
-					regulator-always-on;
-					regulator-boot-on;
+					regulator-min-microvolt = <2000000>;
+					regulator-max-microvolt = <2000000>;
+					/* Only for efuse reprograming! */
+					status = "disabled";
 				};
 
 				ldo8_reg: ldo8 {
-- 
1.7.9.5



From nm at ti.com  Wed Jul 17 12:45:29 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 17 Jul 2013 11:45:29 -0500
Subject: [PATCH 0/9] ARM: dts: omap5-uevm: fixup wrong regulator configuration
Message-ID: <1374079538-19548-1-git-send-email-nm@ti.com>

Due to wrong older revision of documentation used as reference, we
seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
series is based power tree on production board 750-2628-XXX platform.
Unfortunately, the wrong voltages may be detrimental to OMAP5 as they
supply hardware blocks at voltages that are out of specification.

Also available at:
based on v3.11-rc1 tag
http link: https://github.com/nmenon/linux-2.6-playground/commits/push/omap5-palmas-fixes
git link: git://github.com/nmenon/linux-2.6-playground.git
branch: push/omap5-palmas-fixes

Tested with https://patchwork.kernel.org/patch/2545061/
 + https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=for_3.11/out_of_tree/omap5_clk_data
Test result: http://pastebin.com/YqASYkXG

Relevant documentation:
- OMAP5 uEVM documentation: https://www.svtronics.com/omap/omap54xx?product_id=33
- OMAP5432 Data Manual: http://www.ti.com/product/OMAP5432
- TWL6037 / OTP information: Currently available only under NDA

Nishanth Menon (9):
  ARM: dts: omap5-uevm: document regulator signals used on the actual
    board
  ARM: dts: omap5-uevm: update SMPS9 settings
  ARM: dts: omap5-uevm: update and disable unused regulators LDO[28]
  ARM: dts: omap5-uevm: update LDO1 voltage to 1.5V and settings
  ARM: dts: omap5-uevm: update LDO3 voltage to 1.5V and settings
  ARM: dts: omap5-uevm: update LDO4 voltage to 1.5V and settings
  ARM: dts: omap5-uevm: update LDO6 voltage to 1.2V
  ARM: dts: omap5-uevm: update LDO7 voltage to 2V and settings
  ARM: dts: omap5-uevm: update SDCARD LDO9 and resource REGEN3

 arch/arm/boot/dts/omap5-uevm.dts |   78 ++++++++++++++++++++++++--------------
 1 file changed, 49 insertions(+), 29 deletions(-)

-- 
1.7.9.5

Regards,
Nishanth Menon


From nm at ti.com  Wed Jul 17 12:45:31 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 17 Jul 2013 11:45:31 -0500
Subject: [PATCH 2/9] ARM: dts: omap5-uevm: update SMPS9 settings
In-Reply-To: <1374079538-19548-1-git-send-email-nm@ti.com>
References: <1374079538-19548-1-git-send-email-nm@ti.com>
Message-ID: <1374079538-19548-3-git-send-email-nm@ti.com>

commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.

SMPS9 supplies TWL6040 over VDDA_2v1_AUD. This regulator needs to be
enabled only when audio is active. Since it does not come active by
default, it does not require "always-on" or "boot-on".

Reported-by: Marc J?ttner <m-juettner at ti.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
 arch/arm/boot/dts/omap5-uevm.dts |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index b430b8f..6709f1e 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -331,8 +331,6 @@
 					regulator-name = "smps9";
 					regulator-min-microvolt = <2100000>;
 					regulator-max-microvolt = <2100000>;
-					regulator-always-on;
-					regulator-boot-on;
 					ti,smps-range = <0x80>;
 				};
 
-- 
1.7.9.5



From nm at ti.com  Wed Jul 17 12:45:35 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 17 Jul 2013 11:45:35 -0500
Subject: [PATCH 6/9] ARM: dts: omap5-uevm: update LDO4 voltage to 1.5V and
 settings
In-Reply-To: <1374079538-19548-1-git-send-email-nm@ti.com>
References: <1374079538-19548-1-git-send-email-nm@ti.com>
Message-ID: <1374079538-19548-7-git-send-email-nm@ti.com>

commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.

LDO4 supplies VDDAPHY_DISP which is vdda_dsiporta/c/vdda_hdmi

This can only be supplied at 1.5V or 1.8V and we currently
supply 2.2V.

To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.

Remove 'always-on' and 'boot-on' settings here as it is a 'on need'
supply to SoC IP and is not enabled by PMIC by default at boot.

Reported-by: Marc J?ttner <m-juettner at ti.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
 arch/arm/boot/dts/omap5-uevm.dts |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index c6d560b..1550d6a 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -372,10 +372,8 @@
 				ldo4_reg: ldo4 {
 					/* VDDAPHY_DISP: vdda_dsiport/hdmi */
 					regulator-name = "ldo4";
-					regulator-min-microvolt = <2200000>;
-					regulator-max-microvolt = <2200000>;
-					regulator-always-on;
-					regulator-boot-on;
+					regulator-min-microvolt = <1500000>;
+					regulator-max-microvolt = <1800000>;
 				};
 
 				ldo5_reg: ldo5 {
-- 
1.7.9.5



From nm at ti.com  Wed Jul 17 12:45:34 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 17 Jul 2013 11:45:34 -0500
Subject: [PATCH 5/9] ARM: dts: omap5-uevm: update LDO3 voltage to 1.5V and
 settings
In-Reply-To: <1374079538-19548-1-git-send-email-nm@ti.com>
References: <1374079538-19548-1-git-send-email-nm@ti.com>
Message-ID: <1374079538-19548-6-git-send-email-nm@ti.com>

commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.

LDO3 supplies Low Latency Interface(LLI) hardware module which is a
special hardware to communicate with Modem. However since uEVM is
not setup by default for this communication, this should be disabled
by default.

Further, vdda_lli is supposed to be 1.5V and not 3V.

Reported-by: Marc J?ttner <m-juettner at ti.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
 arch/arm/boot/dts/omap5-uevm.dts |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index a55f4d8..c6d560b 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -362,10 +362,11 @@
 				ldo3_reg: ldo3 {
 					/* VDDAPHY_MDM: vdda_lli */
 					regulator-name = "ldo3";
-					regulator-min-microvolt = <3000000>;
-					regulator-max-microvolt = <3000000>;
-					regulator-always-on;
+					regulator-min-microvolt = <1500000>;
+					regulator-max-microvolt = <1500000>;
 					regulator-boot-on;
+					/* Only if Modem is used */
+					status = "disabled";
 				};
 
 				ldo4_reg: ldo4 {
-- 
1.7.9.5



From nm at ti.com  Wed Jul 17 12:45:30 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 17 Jul 2013 11:45:30 -0500
Subject: [PATCH 1/9] ARM: dts: omap5-uevm: document regulator signals used on
 the actual board
In-Reply-To: <1374079538-19548-1-git-send-email-nm@ti.com>
References: <1374079538-19548-1-git-send-email-nm@ti.com>
Message-ID: <1374079538-19548-2-git-send-email-nm@ti.com>

commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, currently we use the Palmas regulator names which is used for
different purposes on uEVM. Document the same based on 750-2628-XXX
boards - which is meant to be supported by this dts.

Reported-by: Marc J?ttner <m-juettner at ti.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
 arch/arm/boot/dts/omap5-uevm.dts |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b430b8f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -282,6 +282,7 @@
 
 			regulators {
 				smps123_reg: smps123 {
+					/* VDD_OPP_MPU */
 					regulator-name = "smps123";
 					regulator-min-microvolt = < 600000>;
 					regulator-max-microvolt = <1500000>;
@@ -290,6 +291,7 @@
 				};
 
 				smps45_reg: smps45 {
+					/* VDD_OPP_MM */
 					regulator-name = "smps45";
 					regulator-min-microvolt = < 600000>;
 					regulator-max-microvolt = <1310000>;
@@ -298,6 +300,7 @@
 				};
 
 				smps6_reg: smps6 {
+					/* VDD_DDR3 - over VDD_SMPS6 */
 					regulator-name = "smps6";
 					regulator-min-microvolt = <1200000>;
 					regulator-max-microvolt = <1200000>;
@@ -306,6 +309,7 @@
 				};
 
 				smps7_reg: smps7 {
+					/* VDDS_1v8_OMAP over VDDS_1v8_MAIN */
 					regulator-name = "smps7";
 					regulator-min-microvolt = <1800000>;
 					regulator-max-microvolt = <1800000>;
@@ -314,6 +318,7 @@
 				};
 
 				smps8_reg: smps8 {
+					/* VDD_OPP_CORE */
 					regulator-name = "smps8";
 					regulator-min-microvolt = < 600000>;
 					regulator-max-microvolt = <1310000>;
@@ -322,6 +327,7 @@
 				};
 
 				smps9_reg: smps9 {
+					/* VDDA_2v1_AUD over VDD_2v1 */
 					regulator-name = "smps9";
 					regulator-min-microvolt = <2100000>;
 					regulator-max-microvolt = <2100000>;
@@ -331,6 +337,7 @@
 				};
 
 				smps10_reg: smps10 {
+					/* VBUS_5V_OTG */
 					regulator-name = "smps10";
 					regulator-min-microvolt = <5000000>;
 					regulator-max-microvolt = <5000000>;
@@ -339,6 +346,7 @@
 				};
 
 				ldo1_reg: ldo1 {
+					/* VDDAPHY_CAM: vdda_csiport */
 					regulator-name = "ldo1";
 					regulator-min-microvolt = <2800000>;
 					regulator-max-microvolt = <2800000>;
@@ -347,6 +355,7 @@
 				};
 
 				ldo2_reg: ldo2 {
+					/* VCC_2V8_DISP: Does not go anywhere */
 					regulator-name = "ldo2";
 					regulator-min-microvolt = <2900000>;
 					regulator-max-microvolt = <2900000>;
@@ -355,6 +364,7 @@
 				};
 
 				ldo3_reg: ldo3 {
+					/* VDDAPHY_MDM: vdda_lli */
 					regulator-name = "ldo3";
 					regulator-min-microvolt = <3000000>;
 					regulator-max-microvolt = <3000000>;
@@ -363,6 +373,7 @@
 				};
 
 				ldo4_reg: ldo4 {
+					/* VDDAPHY_DISP: vdda_dsiport/hdmi */
 					regulator-name = "ldo4";
 					regulator-min-microvolt = <2200000>;
 					regulator-max-microvolt = <2200000>;
@@ -371,6 +382,7 @@
 				};
 
 				ldo5_reg: ldo5 {
+					/* VDDA_1V8_PHY: usb/sata/hdmi.. */
 					regulator-name = "ldo5";
 					regulator-min-microvolt = <1800000>;
 					regulator-max-microvolt = <1800000>;
@@ -379,6 +391,7 @@
 				};
 
 				ldo6_reg: ldo6 {
+					/* VDDS_1V2_WKUP: hsic/ldo_emu_wkup */
 					regulator-name = "ldo6";
 					regulator-min-microvolt = <1500000>;
 					regulator-max-microvolt = <1500000>;
@@ -387,6 +400,7 @@
 				};
 
 				ldo7_reg: ldo7 {
+					/* VDD_VPP: vpp1 */
 					regulator-name = "ldo7";
 					regulator-min-microvolt = <1500000>;
 					regulator-max-microvolt = <1500000>;
@@ -395,6 +409,7 @@
 				};
 
 				ldo8_reg: ldo8 {
+					/* VDD_3v0: Does not go anywhere */
 					regulator-name = "ldo8";
 					regulator-min-microvolt = <1500000>;
 					regulator-max-microvolt = <1500000>;
@@ -403,6 +418,7 @@
 				};
 
 				ldo9_reg: ldo9 {
+					/* VCC_DV_SDIO: vdds_sdcard */
 					regulator-name = "ldo9";
 					regulator-min-microvolt = <1800000>;
 					regulator-max-microvolt = <3300000>;
@@ -411,6 +427,7 @@
 				};
 
 				ldoln_reg: ldoln {
+					/* VDDA_1v8_REF: vdds_osc/mm_l4per.. */
 					regulator-name = "ldoln";
 					regulator-min-microvolt = <1800000>;
 					regulator-max-microvolt = <1800000>;
@@ -419,6 +436,7 @@
 				};
 
 				ldousb_reg: ldousb {
+					/* VDDA_3V_USB: VDDA_USBHS33 */
 					regulator-name = "ldousb";
 					regulator-min-microvolt = <3250000>;
 					regulator-max-microvolt = <3250000>;
-- 
1.7.9.5



From nm at ti.com  Wed Jul 17 12:45:38 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 17 Jul 2013 11:45:38 -0500
Subject: [PATCH 9/9] ARM: dts: omap5-uevm: update SDCARD LDO9 and resource
 REGEN3
In-Reply-To: <1374079538-19548-1-git-send-email-nm@ti.com>
References: <1374079538-19548-1-git-send-email-nm@ti.com>
Message-ID: <1374079538-19548-10-git-send-email-nm@ti.com>

commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.

LDO9 supplies the board specified vdds_sdcard supply going within SoC
specification of 1.8V or 3.0V. Further the supply is controlled by
switch enabled by REGEN3. So, introduce REGEN3 and map sdcard slot to
be powered by LDO9. Remove 'always-on' allowing the LDO to be disabled
on need basis.

Reported-by: Marc J?ttner <m-juettner at ti.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
 arch/arm/boot/dts/omap5-uevm.dts |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index ef05676..65d7b60 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -235,7 +235,7 @@
 };
 
 &mmc1 {
-	vmmc-supply = <&vmmcsd_fixed>;
+	vmmc-supply = <&ldo9_reg>;
 	bus-width = <4>;
 };
 
@@ -417,8 +417,7 @@
 					/* VCC_DV_SDIO: vdds_sdcard */
 					regulator-name = "ldo9";
 					regulator-min-microvolt = <1800000>;
-					regulator-max-microvolt = <3300000>;
-					regulator-always-on;
+					regulator-max-microvolt = <3000000>;
 					regulator-boot-on;
 				};
 
@@ -439,6 +438,13 @@
 					regulator-always-on;
 					regulator-boot-on;
 				};
+
+				regen3_reg: regen3 {
+					/* REGEN3 controls LDO9 supply to card */
+					regulator-name = "regen3";
+					regulator-always-on;
+					regulator-boot-on;
+				};
 			};
 		};
 	};
-- 
1.7.9.5



From nm at ti.com  Wed Jul 17 12:45:33 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 17 Jul 2013 11:45:33 -0500
Subject: [PATCH 4/9] ARM: dts: omap5-uevm: update LDO1 voltage to 1.5V and
 settings
In-Reply-To: <1374079538-19548-1-git-send-email-nm@ti.com>
References: <1374079538-19548-1-git-send-email-nm@ti.com>
Message-ID: <1374079538-19548-5-git-send-email-nm@ti.com>

commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.

LDO1 supplies VDDAPHY_CAM which is OMAP5's vdda_csiporta/b/c. This
can only be supplied at 1.5V or 1.8V and we currently supply 2.8V.

To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.

Remove 'always-on' and 'boot-on' settings here as it is
a 'on need' supply to SoC IP and is not enabled by PMIC by
default at boot.

Reported-by: Marc J?ttner <m-juettner at ti.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
 arch/arm/boot/dts/omap5-uevm.dts |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 87b3e9e..a55f4d8 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -346,10 +346,8 @@
 				ldo1_reg: ldo1 {
 					/* VDDAPHY_CAM: vdda_csiport */
 					regulator-name = "ldo1";
-					regulator-min-microvolt = <2800000>;
-					regulator-max-microvolt = <2800000>;
-					regulator-always-on;
-					regulator-boot-on;
+					regulator-min-microvolt = <1500000>;
+					regulator-max-microvolt = <1800000>;
 				};
 
 				ldo2_reg: ldo2 {
-- 
1.7.9.5



From nm at ti.com  Wed Jul 17 12:45:32 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 17 Jul 2013 11:45:32 -0500
Subject: [PATCH 3/9] ARM: dts: omap5-uevm: update and disable unused
 regulators LDO[28]
In-Reply-To: <1374079538-19548-1-git-send-email-nm@ti.com>
References: <1374079538-19548-1-git-send-email-nm@ti.com>
Message-ID: <1374079538-19548-4-git-send-email-nm@ti.com>

commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards - On production boards, LDO2 and 8 are unused.

LDO2 and LDO8 do not go to any peripheral or connector on the board.
Further, these unused regulators should have been 2.8V for LDO2 and
3.0V for LDO8. Mark these LDOs as disabled in the dts until needed.

Reported-by: Marc J?ttner <m-juettner at ti.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
 arch/arm/boot/dts/omap5-uevm.dts |   15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 6709f1e..87b3e9e 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -355,10 +355,10 @@
 				ldo2_reg: ldo2 {
 					/* VCC_2V8_DISP: Does not go anywhere */
 					regulator-name = "ldo2";
-					regulator-min-microvolt = <2900000>;
-					regulator-max-microvolt = <2900000>;
-					regulator-always-on;
-					regulator-boot-on;
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+					/* Unused */
+					status = "disabled";
 				};
 
 				ldo3_reg: ldo3 {
@@ -409,10 +409,11 @@
 				ldo8_reg: ldo8 {
 					/* VDD_3v0: Does not go anywhere */
 					regulator-name = "ldo8";
-					regulator-min-microvolt = <1500000>;
-					regulator-max-microvolt = <1500000>;
-					regulator-always-on;
+					regulator-min-microvolt = <3000000>;
+					regulator-max-microvolt = <3000000>;
 					regulator-boot-on;
+					/* Unused */
+					status = "disabled";
 				};
 
 				ldo9_reg: ldo9 {
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 12:45:53 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 18:45:53 +0200
Subject: [PATCH v2 34/42] ARM: at91/dt: move at91sam9g20 SoC to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374079553-20942-1-git-send-email-b.brezillon@overkiz.com>

Define at91sam9g20 clocks in at91sam9g20 device tree.
Add references to the appropriate clocks in each peripheral.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/at91sam9g20.dtsi |   37 ++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi b/arch/arm/boot/dts/at91sam9g20.dtsi
index b8e7946..60a20ec 100644
--- a/arch/arm/boot/dts/at91sam9g20.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20.dtsi
@@ -25,6 +25,43 @@
 			adc0: adc at fffe0000 {
 				atmel,adc-startup-time = <40>;
 			};
+
+			pmc: pmc at fffffc00 {
+				plla: pllack {
+					compatible = "atmel,at91sam9g45-clk-pll";
+					#clock-cells = <0>;
+					clocks = <&main>;
+					id = <0>;
+					input = <2000000 32000000>;
+					output = <74500000 800000000
+							  69500000 750000000
+							  64500000 700000000
+							  59500000 650000000
+							  54500000 600000000
+							  49500000 550000000
+							  44500000 500000000
+							  40000000 450000000>;
+					out = <0 1 2 3 0 1 2 3>;
+					icpll = <0 0 0 0 1 1 1 1>;
+				};
+
+				pllb: pllbck {
+					compatible = "atmel,at91sam9g20-clk-pllb";
+					#clock-cells = <0>;
+					clocks = <&main>;
+					id = <1>;
+					input = <2000000 32000000>;
+					output = <30000000 100000000>;
+					out = <0>;
+				};
+
+				mck: masterck {
+					#clock-cells = <0>;
+					clocks = <&clk32k>, <&main>, <&plla>, <&pllb>;
+					output = <0 133000000>;
+					divisors = <1 2 4 6>;
+				};
+			};
 		};
 	};
 };
-- 
1.7.9.5



From stefano.stabellini at eu.citrix.com  Wed Jul 17 12:48:48 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 17 Jul 2013 17:48:48 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabled
In-Reply-To: <20130717151816.GN24642@n2100.arm.linux.org.uk>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
 <20130717151148.GM24642@n2100.arm.linux.org.uk>
 <20130717151816.GN24642@n2100.arm.linux.org.uk>
Message-ID: <alpine.DEB.2.02.1307171748310.8258@kaball.uk.xensource.com>

On Wed, 17 Jul 2013, Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 04:11:48PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Jul 17, 2013 at 02:25:38PM +0100, Stefano Stabellini wrote:
> > > On Mon, 15 Jul 2013, Julien Grall wrote:
> > > > Even if uncompress debug is disabled, some board will continue to print
> > > > information during uncompress step.
> > > 
> > > Are you talking about DEBUG_UNCOMPRESS?
> > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > > some board will continue to print information during the uncompress step"?
> > > 
> > > Isn't this a bug in the platform specific code that should be fixed anyway?
> > 
> > Hang on, let's be clear what's going on here.
> > 
> > 1. The normal output from the decompressor is *not* debugging.  By that
> >    I mean the "Uncompressing kernel... done" message.  That is part of
> >    user output.
> > 
> > 2. In non-multiplatform environments, the decompressor will normally use
> >    the putc/flush functions found in arch/arm/mach-*/include/mach/uncompress.h
> >    to implement its output, irrespective of the DEBUG_UNCOMPRESS setting.
> >    (An interesting point is that DEBUG_UNCOMPRESS really should depend on
> >    MULTIPLATFORM so that this point is explicit - the option requires
> >    MULTIPLATFORM to be set.)
> > 
> > 3. DEBUG_UNCOMPRESS allows the functions which we've implemented for LL
> >    debug to be re-used for decompressor output.
> > 
> > 4. When DEBUG_UNCOMPRESS is not set in a multiplatform kernel, the
> >    decompressors putc() and flush() functions are stubbed out.
> > 
> > So, it's quite right that you get output from the decompressor even when
> > DEBUG_UNCOMPRESS is not set.  There's no problem with that.
> 
> Does this patch help to explain this?

Yes it does, thanks.


>  arch/arm/Kconfig.debug |   14 ++++++++++++--
>  1 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index e401a76..583f4a0 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -804,9 +804,19 @@ config DEBUG_LL_INCLUDE
>  
>  config DEBUG_UNCOMPRESS
>  	bool
> -	default y if ARCH_MULTIPLATFORM && DEBUG_LL && \
> -		     !DEBUG_OMAP2PLUS_UART && \
> +	depends on ARCH_MULTIPLATFORM
> +	default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \
>  		     !DEBUG_TEGRA_UART
> +	help
> +	  This option influences the normal decompressor output only for
> +	  multiplatform kernels.  Normally, multiplatform kernels disable
> +	  decompressor output because it is not possible to know where to
> +	  send the decompressor output.
> +
> +	  When this option is set, the selected DEBUG_LL output method
> +	  will be re-used for normal decompressor output on multiplatform
> +	  kernels.
> +	  
>  
>  config UNCOMPRESS_INCLUDE
>  	string
> 


From b.brezillon at overkiz.com  Wed Jul 17 12:50:46 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 18:50:46 +0200
Subject: [PATCH v2 35/42] ARM: at91/dt: move sama5d3 SoCs to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374079846-20991-1-git-send-email-b.brezillon@overkiz.com>

Define sama5d3 clocks in sama5d3 device tree.
Add references to the appropriate clocks in each peripheral.
Split optional sam9x5 peripherals in several device tree files. These
files are included by each SoC according to it's availability.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/sama5d3.dtsi      |  510 +++++++++++++++++++++--------------
 arch/arm/boot/dts/sama5d3_can.dtsi  |   71 +++++
 arch/arm/boot/dts/sama5d3_emac.dtsi |   54 ++++
 arch/arm/boot/dts/sama5d3_gmac.dtsi |   87 ++++++
 arch/arm/boot/dts/sama5d3_lcd.dtsi  |   69 +++++
 arch/arm/boot/dts/sama5d3_mci2.dtsi |   57 ++++
 arch/arm/boot/dts/sama5d3_tcb1.dtsi |   38 +++
 arch/arm/boot/dts/sama5d3_uart.dtsi |   46 ++++
 8 files changed, 729 insertions(+), 203 deletions(-)
 create mode 100644 arch/arm/boot/dts/sama5d3_can.dtsi
 create mode 100644 arch/arm/boot/dts/sama5d3_emac.dtsi
 create mode 100644 arch/arm/boot/dts/sama5d3_gmac.dtsi
 create mode 100644 arch/arm/boot/dts/sama5d3_lcd.dtsi
 create mode 100644 arch/arm/boot/dts/sama5d3_mci2.dtsi
 create mode 100644 arch/arm/boot/dts/sama5d3_tcb1.dtsi
 create mode 100644 arch/arm/boot/dts/sama5d3_uart.dtsi

diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index a1d5e25..6980c4d 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -31,7 +31,6 @@
 		gpio3 = &pioD;
 		gpio4 = &pioE;
 		tcb0 = &tcb0;
-		tcb1 = &tcb1;
 		i2c0 = &i2c0;
 		i2c1 = &i2c1;
 		i2c2 = &i2c2;
@@ -52,6 +51,14 @@
 		reg = <0x20000000 0x8000000>;
 	};
 
+	clocks {
+		adc_op_clk: adc_op_clk{
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <20000000>;
+		};
+	};
+
 	ahb {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -75,6 +82,8 @@
 				status = "disabled";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 21>;
+				clock-names = "mci_clk";
 			};
 
 			spi0: spi at f0004000 {
@@ -88,6 +97,8 @@
 				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_spi0>;
+				clocks = <&periph 24>;
+				clock-names = "spi_clk";
 				status = "disabled";
 			};
 
@@ -97,15 +108,8 @@
 				interrupts = <38 IRQ_TYPE_LEVEL_HIGH 4>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
-				status = "disabled";
-			};
-
-			can0: can at f000c000 {
-				compatible = "atmel,at91sam9x5-can";
-				reg = <0xf000c000 0x300>;
-				interrupts = <40 IRQ_TYPE_LEVEL_HIGH 3>;
-				pinctrl-names = "default";
-				pinctrl-0 = <&pinctrl_can0_rx_tx>;
+				clocks = <&periph 38>;
+				clock-names = "pclk";
 				status = "disabled";
 			};
 
@@ -113,6 +117,8 @@
 				compatible = "atmel,at91sam9x5-tcb";
 				reg = <0xf0010000 0x100>;
 				interrupts = <26 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 26>;
+				clock-names = "t0_clk";
 			};
 
 			i2c0: i2c at f0014000 {
@@ -126,6 +132,7 @@
 				pinctrl-0 = <&pinctrl_i2c0>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 18>;
 				status = "disabled";
 			};
 
@@ -140,6 +147,7 @@
 				pinctrl-0 = <&pinctrl_i2c1>;
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 19>;
 				status = "disabled";
 			};
 
@@ -149,6 +157,8 @@
 				interrupts = <12 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart0>;
+				clocks = <&periph 12>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -158,15 +168,8 @@
 				interrupts = <13 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart1>;
-				status = "disabled";
-			};
-
-			macb0: ethernet at f0028000 {
-				compatible = "cdns,pc302-gem", "cdns,gem";
-				reg = <0xf0028000 0x100>;
-				interrupts = <34 IRQ_TYPE_LEVEL_HIGH 3>;
-				pinctrl-names = "default";
-				pinctrl-0 = <&pinctrl_macb0_data_rgmii &pinctrl_macb0_signal_rgmii>;
+				clocks = <&periph 13>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -188,19 +191,8 @@
 				status = "disabled";
 				#address-cells = <1>;
 				#size-cells = <0>;
-			};
-
-			mmc2: mmc at f8004000 {
-				compatible = "atmel,hsmci";
-				reg = <0xf8004000 0x600>;
-				interrupts = <23 IRQ_TYPE_LEVEL_HIGH 0>;
-				dmas = <&dma1 2 AT91_DMA_CFG_PER_ID(1)>;
-				dma-names = "rxtx";
-				pinctrl-names = "default";
-				pinctrl-0 = <&pinctrl_mmc2_clk_cmd_dat0 &pinctrl_mmc2_dat1_3>;
-				status = "disabled";
-				#address-cells = <1>;
-				#size-cells = <0>;
+				clocks = <&periph 22>;
+				clock-names = "mci_clk";
 			};
 
 			spi1: spi at f8008000 {
@@ -214,6 +206,8 @@
 				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_spi1>;
+				clocks = <&periph 25>;
+				clock-names = "spi_clk";
 				status = "disabled";
 			};
 
@@ -223,23 +217,11 @@
 				interrupts = <39 IRQ_TYPE_LEVEL_HIGH 4>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc1_tx &pinctrl_ssc1_rx>;
+				clocks = <&periph 39>;
+				clock-names = "pclk";
 				status = "disabled";
 			};
 
-			can1: can at f8010000 {
-				compatible = "atmel,at91sam9x5-can";
-				reg = <0xf8010000 0x300>;
-				interrupts = <41 IRQ_TYPE_LEVEL_HIGH 3>;
-				pinctrl-names = "default";
-				pinctrl-0 = <&pinctrl_can1_rx_tx>;
-			};
-
-			tcb1: timer at f8014000 {
-				compatible = "atmel,at91sam9x5-tcb";
-				reg = <0xf8014000 0x100>;
-				interrupts = <27 IRQ_TYPE_LEVEL_HIGH 0>;
-			};
-
 			adc0: adc at f8018000 {
 				compatible = "atmel,at91sam9260-adc";
 				reg = <0xf8018000 0x100>;
@@ -260,6 +242,8 @@
 					&pinctrl_adc0_ad10
 					&pinctrl_adc0_ad11
 					>;
+				clocks = <&periph 29>, <&adc_op_clk>;
+				clock-names = "adc_clk", "adc_op_clk";
 				atmel,adc-channel-base = <0x50>;
 				atmel,adc-channels-used = <0xfff>;
 				atmel,adc-drdy-mask = <0x1000000>;
@@ -315,6 +299,7 @@
 				dma-names = "tx", "rx";
 				#address-cells = <1>;
 				#size-cells = <0>;
+				clocks = <&periph 20>;
 				status = "disabled";
 			};
 
@@ -324,6 +309,8 @@
 				interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart2>;
+				clocks = <&periph 14>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -333,15 +320,8 @@
 				interrupts = <15 IRQ_TYPE_LEVEL_HIGH 5>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usart3>;
-				status = "disabled";
-			};
-
-			macb1: ethernet at f802c000 {
-				compatible = "cdns,at32ap7000-macb", "cdns,macb";
-				reg = <0xf802c000 0x100>;
-				interrupts = <35 IRQ_TYPE_LEVEL_HIGH 3>;
-				pinctrl-names = "default";
-				pinctrl-0 = <&pinctrl_macb1_rmii>;
+				clocks = <&periph 15>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -368,6 +348,8 @@
 				reg = <0xffffe600 0x200>;
 				interrupts = <30 IRQ_TYPE_LEVEL_HIGH 0>;
 				#dma-cells = <2>;
+				clocks = <&periph 30>;
+				clock-names = "dma_clk";
 			};
 
 			dma1: dma-controller at ffffe800 {
@@ -375,6 +357,8 @@
 				reg = <0xffffe800 0x200>;
 				interrupts = <31 IRQ_TYPE_LEVEL_HIGH 0>;
 				#dma-cells = <2>;
+				clocks = <&periph 31>;
+				clock-names = "dma_clk";
 			};
 
 			ramc0: ramc at ffffea00 {
@@ -388,6 +372,8 @@
 				interrupts = <2 IRQ_TYPE_LEVEL_HIGH 7>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_dbgu>;
+				clocks = <&periph 2>;
+				clock-names = "usart";
 				status = "disabled";
 			};
 
@@ -469,22 +455,6 @@
 					};
 				};
 
-				can0 {
-					pinctrl_can0_rx_tx: can0_rx_tx {
-						atmel,pins =
-							<AT91_PIOD 14 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PD14 periph C RX, conflicts with SCK0, SPI0_NPCS1 */
-							 AT91_PIOD 15 AT91_PERIPH_C AT91_PINCTRL_NONE>;	/* PD15 periph C TX, conflicts with CTS0, SPI0_NPCS2 */
-					};
-				};
-
-				can1 {
-					pinctrl_can1_rx_tx: can1_rx_tx {
-						atmel,pins =
-							<AT91_PIOB 14 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB14 periph B RX, conflicts with GCRS */
-							 AT91_PIOB 15 AT91_PERIPH_B AT91_PINCTRL_NONE>;	/* PB15 periph B TX, conflicts with GCOL */
-					};
-				};
-
 				dbgu {
 					pinctrl_dbgu: dbgu-0 {
 						atmel,pins =
@@ -532,107 +502,6 @@
 					};
 				};
 
-				lcd {
-					pinctrl_lcd: lcd-0 {
-						atmel,pins =
-							<AT91_PIOA 24 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA24 periph A LCDPWM */
-							 AT91_PIOA 26 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA26 periph A LCDVSYNC */
-							 AT91_PIOA 27 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA27 periph A LCDHSYNC */
-							 AT91_PIOA 25 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA25 periph A LCDDISP */
-							 AT91_PIOA 29 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA29 periph A LCDDEN */
-							 AT91_PIOA 28 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA28 periph A LCDPCK */
-							 AT91_PIOA 0 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA0 periph A LCDD0 pin */
-							 AT91_PIOA 1 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA1 periph A LCDD1 pin */
-							 AT91_PIOA 2 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA2 periph A LCDD2 pin */
-							 AT91_PIOA 3 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA3 periph A LCDD3 pin */
-							 AT91_PIOA 4 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA4 periph A LCDD4 pin */
-							 AT91_PIOA 5 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA5 periph A LCDD5 pin */
-							 AT91_PIOA 6 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA6 periph A LCDD6 pin */
-							 AT91_PIOA 7 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA7 periph A LCDD7 pin */
-							 AT91_PIOA 8 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA8 periph A LCDD8 pin */
-							 AT91_PIOA 9 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA9 periph A LCDD9 pin */
-							 AT91_PIOA 10 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA10 periph A LCDD10 pin */
-							 AT91_PIOA 11 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA11 periph A LCDD11 pin */
-							 AT91_PIOA 12 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA12 periph A LCDD12 pin */
-							 AT91_PIOA 13 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA13 periph A LCDD13 pin */
-							 AT91_PIOA 14 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA14 periph A LCDD14 pin */
-							 AT91_PIOA 15 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA15 periph A LCDD15 pin */
-							 AT91_PIOC 14 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC14 periph C LCDD16 pin */
-							 AT91_PIOC 13 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC13 periph C LCDD17 pin */
-							 AT91_PIOC 12 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC12 periph C LCDD18 pin */
-							 AT91_PIOC 11 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC11 periph C LCDD19 pin */
-							 AT91_PIOC 10 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC10 periph C LCDD20 pin */
-							 AT91_PIOC 15 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC15 periph C LCDD21 pin */
-							 AT91_PIOE 27 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PE27 periph C LCDD22 pin */
-							 AT91_PIOE 28 AT91_PERIPH_C AT91_PINCTRL_NONE>;	/* PE28 periph C LCDD23 pin */
-					};
-				};
-
-				macb0 {
-					pinctrl_macb0_data_rgmii: macb0_data_rgmii {
-						atmel,pins =
-							<AT91_PIOB 0 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB0 periph A GTX0, conflicts with PWMH0 */
-							 AT91_PIOB 1 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB1 periph A GTX1, conflicts with PWML0 */
-							 AT91_PIOB 2 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB2 periph A GTX2, conflicts with TK1 */
-							 AT91_PIOB 3 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB3 periph A GTX3, conflicts with TF1 */
-							 AT91_PIOB 4 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB4 periph A GRX0, conflicts with PWMH1 */
-							 AT91_PIOB 5 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB5 periph A GRX1, conflicts with PWML1 */
-							 AT91_PIOB 6 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB6 periph A GRX2, conflicts with TD1 */
-							 AT91_PIOB 7 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PB7 periph A GRX3, conflicts with RK1 */
-					};
-					pinctrl_macb0_data_gmii: macb0_data_gmii {
-						atmel,pins =
-							<AT91_PIOB 19 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB19 periph B GTX4, conflicts with MCI1_CDA */
-							 AT91_PIOB 20 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB20 periph B GTX5, conflicts with MCI1_DA0 */
-							 AT91_PIOB 21 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB21 periph B GTX6, conflicts with MCI1_DA1 */
-							 AT91_PIOB 22 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB22 periph B GTX7, conflicts with MCI1_DA2 */
-							 AT91_PIOB 23 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB23 periph B GRX4, conflicts with MCI1_DA3 */
-							 AT91_PIOB 24 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB24 periph B GRX5, conflicts with MCI1_CK */
-							 AT91_PIOB 25 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB25 periph B GRX6, conflicts with SCK1 */
-							 AT91_PIOB 26 AT91_PERIPH_B AT91_PINCTRL_NONE>;	/* PB26 periph B GRX7, conflicts with CTS1 */
-					};
-					pinctrl_macb0_signal_rgmii: macb0_signal_rgmii {
-						atmel,pins =
-							<AT91_PIOB 8 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB8 periph A GTXCK, conflicts with PWMH2 */
-							 AT91_PIOB 9 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB9 periph A GTXEN, conflicts with PWML2 */
-							 AT91_PIOB 11 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB11 periph A GRXCK, conflicts with RD1 */
-							 AT91_PIOB 13 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB13 periph A GRXER, conflicts with PWML3 */
-							 AT91_PIOB 16 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB16 periph A GMDC */
-							 AT91_PIOB 17 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB17 periph A GMDIO */
-							 AT91_PIOB 18 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PB18 periph A G125CK */
-					};
-					pinctrl_macb0_signal_gmii: macb0_signal_gmii {
-						atmel,pins =
-							<AT91_PIOB 9 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB9 periph A GTXEN, conflicts with PWML2 */
-							 AT91_PIOB 10 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB10 periph A GTXER, conflicts with RF1 */
-							 AT91_PIOB 11 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB11 periph A GRXCK, conflicts with RD1 */
-							 AT91_PIOB 12 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB12 periph A GRXDV, conflicts with PWMH3 */
-							 AT91_PIOB 13 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB13 periph A GRXER, conflicts with PWML3 */
-							 AT91_PIOB 14 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB14 periph A GCRS, conflicts with CANRX1 */
-							 AT91_PIOB 15 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB15 periph A GCOL, conflicts with CANTX1 */
-							 AT91_PIOB 16 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB16 periph A GMDC */
-							 AT91_PIOB 17 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB17 periph A GMDIO */
-							 AT91_PIOB 27 AT91_PERIPH_B AT91_PINCTRL_NONE>;	/* PB27 periph B G125CKO */
-					};
-
-				};
-
-				macb1 {
-					pinctrl_macb1_rmii: macb1_rmii-0 {
-						atmel,pins =
-							<AT91_PIOC 0 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC0 periph A ETX0, conflicts with TIOA3 */
-							 AT91_PIOC 1 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC1 periph A ETX1, conflicts with TIOB3 */
-							 AT91_PIOC 2 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC2 periph A ERX0, conflicts with TCLK3 */
-							 AT91_PIOC 3 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC3 periph A ERX1, conflicts with TIOA4 */
-							 AT91_PIOC 4 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC4 periph A ETXEN, conflicts with TIOB4 */
-							 AT91_PIOC 5 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC5 periph A ECRSDV,conflicts with TCLK4 */
-							 AT91_PIOC 6 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC6 periph A ERXER, conflicts with TIOA5 */
-							 AT91_PIOC 7 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC7 periph A EREFCK, conflicts with TIOB5 */
-							 AT91_PIOC 8 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC8 periph A EMDC, conflicts with TCLK5 */
-							 AT91_PIOC 9 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PC9 periph A EMDIO  */
-					};
-				};
-
 				mmc0 {
 					pinctrl_mmc0_clk_cmd_dat0: mmc0_clk_cmd_dat0 {
 						atmel,pins =
@@ -670,21 +539,6 @@
 					};
 				};
 
-				mmc2 {
-					pinctrl_mmc2_clk_cmd_dat0: mmc2_clk_cmd_dat0 {
-						atmel,pins =
-							<AT91_PIOC 15 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC15 periph A MCI2_CK, conflicts with PCK2 */
-							 AT91_PIOC 10 AT91_PERIPH_A AT91_PINCTRL_PULL_UP	/* PC10 periph A MCI2_CDA with pullup */
-							 AT91_PIOC 11 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;	/* PC11 periph A MCI2_DA0 with pullup */
-					};
-					pinctrl_mmc2_dat1_3: mmc2_dat1_3 {
-						atmel,pins =
-							<AT91_PIOC 12 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC12 periph A MCI2_DA1 with pullup, conflicts with TIOA1 */
-							 AT91_PIOC 13 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC13 periph A MCI2_DA2 with pullup, conflicts with TIOB1 */
-							 AT91_PIOC 14 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PC14 periph A MCI2_DA3 with pullup, conflicts with TCLK1 */
-					};
-				};
-
 				nand0 {
 					pinctrl_nand0_ale_cle: nand0_ale_cle-0 {
 						atmel,pins =
@@ -743,22 +597,6 @@
 					};
 				};
 
-				uart0 {
-					pinctrl_uart0: uart0-0 {
-						atmel,pins =
-							<AT91_PIOC 29 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC29 periph A, conflicts with PWMFI2, ISI_D8 */
-							 AT91_PIOC 30 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;	/* PC30 periph A with pullup, conflicts with ISI_PCK */
-					};
-				};
-
-				uart1 {
-					pinctrl_uart1: uart1-0 {
-						atmel,pins =
-							<AT91_PIOA 30 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PA30 periph B, conflicts with TWD0, ISI_VSYNC */
-							 AT91_PIOA 31 AT91_PERIPH_B AT91_PINCTRL_PULL_UP>;	/* PA31 periph B with pullup, conflicts with TWCK0, ISI_HSYNC */
-					};
-				};
-
 				usart0 {
 					pinctrl_usart0: usart0-0 {
 						atmel,pins =
@@ -824,6 +662,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 6>;
 				};
 
 				pioB: gpio at fffff400 {
@@ -834,6 +673,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 7>;
 				};
 
 				pioC: gpio at fffff600 {
@@ -844,6 +684,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 8>;
 				};
 
 				pioD: gpio at fffff800 {
@@ -854,6 +695,7 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 9>;
 				};
 
 				pioE: gpio at fffffa00 {
@@ -864,12 +706,267 @@
 					gpio-controller;
 					interrupt-controller;
 					#interrupt-cells = <2>;
+					clocks = <&periph 10>;
 				};
 			};
 
 			pmc: pmc at fffffc00 {
 				compatible = "atmel,at91rm9200-pmc";
 				reg = <0xfffffc00 0x120>;
+
+				clk32k: slck {
+					compatible = "fixed-clock";
+					#clock-cells = <0>;
+					clock-frequency = <32768>;
+				};
+
+				main: mainck {
+					compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
+					#clock-cells = <0>;
+					clocks = <&clk32k>;
+				};
+
+				plla: pllack {
+					compatible = "atmel,sama5d3-clk-pll";
+					#clock-cells = <0>;
+					clocks = <&main>;
+					id = <0>;
+					input = <8000000 50000000>;
+					output = <400000000 1000000000>;
+					out = <0>;
+					icpll = <0>;
+				};
+
+				plladiv: plladivck {
+					compatible = "atmel,at91sam9x5-clk-plldiv";
+					#clock-cells = <0>;
+					clocks = <&plla>;
+				};
+
+				utmi: utmick {
+					compatible = "atmel,at91sam9x5-clk-utmi";
+					#clock-cells = <0>;
+					clocks = <&main>;
+				};
+
+				mck: masterck {
+					compatible = "atmel,at91sam9x5-clk-master";
+					#clock-cells = <0>;
+					clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>;
+					output = <0 166000000>;
+					divisors = <1 2 4 3>;
+				};
+
+				usb: usbck {
+					compatible = "atmel,at91sam9x5-clk-usb";
+					#clock-cells = <0>;
+					clocks = <&plladiv>, <&utmi>;
+				};
+
+				prog: progck {
+					compatible = "atmel,at91sam9x5-clk-programmable";
+					#clock-cells = <1>;
+					clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>;
+
+					prog0 at 0 {
+						id = <0>;
+					};
+
+					prog1 at 1 {
+						id = <1>;
+					};
+
+					prog2 at 2 {
+						id = <2>;
+					};
+				};
+
+				smd: smdclk {
+					compatible = "atmel,at91sam9x5-clk-smd";
+					#clock-cells = <0>;
+					clocks = <&plladiv>, <&utmi>;
+				};
+
+				system: systemck {
+					compatible = "atmel,at91rm9200-clk-system";
+					#clock-cells = <1>;
+
+					ddrck at 2 {
+						id = <2>;
+					};
+
+					smdck at 4 {
+						id = <4>;
+					};
+
+					uhpck at 6 {
+						id = <6>;
+					};
+
+					udpck at 7 {
+						id = <7>;
+					};
+
+					pck0 at 8 {
+						id = <8>;
+					};
+
+					pck1 at 9 {
+						id = <9>;
+					};
+
+					pck2 at 10 {
+						id = <10>;
+					};
+				};
+
+				periph: periphck {
+					compatible = "atmel,at91sam9x5-clk-peripheral";
+					#clock-cells = <1>;
+					clocks = <&mck>;
+					ids = <2 6 7 8 9 10 12 13 14 15 18 19 20 21 22 24 25
+					       26 28 29 30 31 32 33 37 38 39 42 43 44 45 48>;
+
+					dbgu_clk at 2 {
+						id = <2>;
+					};
+
+					pioA_clk at 6 {
+						id = <6>;
+					};
+
+					pioB_clk at 7 {
+						id = <7>;
+					};
+
+					pioC_clk at 8 {
+						id = <8>;
+					};
+
+					pioD_clk at 9 {
+						id = <9>;
+					};
+
+					pioE_clk at 10 {
+						id = <10>;
+					};
+
+					usart0_clk at 12 {
+						id = <12>;
+						default-divisor = <1>;
+					};
+
+					usart1_clk at 13 {
+						id = <13>;
+						default-divisor = <1>;
+					};
+
+					usart2_clk at 14 {
+						id = <14>;
+						default-divisor = <1>;
+					};
+
+					usart3_clk at 15 {
+						id = <15>;
+						default-divisor = <1>;
+					};
+
+					twi0_clk at 18 {
+						id = <18>;
+						default-divisor = <1>;
+					};
+
+					twi1_clk at 19 {
+						id = <19>;
+						default-divisor = <1>;
+					};
+
+					twi2_clk at 20 {
+						id = <20>;
+						default-divisor = <1>;
+					};
+
+					mci0_clk at 21 {
+						id = <21>;
+					};
+
+					mci1_clk at 22 {
+						id = <22>;
+					};
+
+					spi0_clk at 24 {
+						id = <24>;
+					};
+
+					spi1_clk at 25 {
+						id = <25>;
+					};
+
+					tcb0_clk at 26 {
+						id = <26>;
+						default-divisor = <1>;
+					};
+
+					pwm_clk at 28 {
+						id = <28>;
+					};
+
+					adc_clk at 29 {
+						id = <29>;
+						default-divisor = <1>;
+					};
+
+					dma0_clk at 30 {
+						id = <30>;
+					};
+
+					dma1_clk at 31 {
+						id = <31>;
+					};
+
+					uhphs_clk at 32 {
+						id = <32>;
+					};
+
+					udphs_clk at 33 {
+						id = <33>;
+					};
+
+					isi_clk at 37 {
+						id = <37>;
+					};
+
+					ssc0_clk at 38 {
+						id = <38>;
+						default-divisor = <1>;
+					};
+
+					ssc1_clk at 39 {
+						id = <39>;
+						default-divisor = <1>;
+					};
+
+					sha_clk at 42 {
+						id = <42>;
+						default-divisor = <3>;
+					};
+
+					aes_clk at 43 {
+						id = <43>;
+					};
+
+					tdes_clk at 44 {
+						id = <44>;
+					};
+
+					trng_clk at 45 {
+						id = <45>;
+					};
+
+					fuse_clk at 48 {
+						id = <48>;
+					};
+				};
 			};
 
 			rstc at fffffe00 {
@@ -881,6 +978,7 @@
 				compatible = "atmel,at91sam9260-pit";
 				reg = <0xfffffe30 0xf>;
 				interrupts = <3 IRQ_TYPE_LEVEL_HIGH 5>;
+				clocks = <&mck>;
 			};
 
 			watchdog at fffffe40 {
@@ -903,6 +1001,8 @@
 			reg = <0x00500000 0x100000
 			       0xf8030000 0x4000>;
 			interrupts = <33 IRQ_TYPE_LEVEL_HIGH 2>;
+			clocks = <&periph 33>, <&utmi>;
+			clock-names = "pclk", "hclk";
 			status = "disabled";
 
 			ep0 {
@@ -1015,6 +1115,8 @@
 			compatible = "atmel,at91rm9200-ohci", "usb-ohci";
 			reg = <0x00600000 0x100000>;
 			interrupts = <32 IRQ_TYPE_LEVEL_HIGH 2>;
+			clocks = <&usb>, <&periph 32>, <&periph 32>, <&system 6>;
+			clock-names = "usb_clk", "ohci_clk", "hclk", "uhpck";
 			status = "disabled";
 		};
 
@@ -1022,6 +1124,8 @@
 			compatible = "atmel,at91sam9g45-ehci", "usb-ehci";
 			reg = <0x00700000 0x100000>;
 			interrupts = <32 IRQ_TYPE_LEVEL_HIGH 2>;
+			clocks = <&periph 32>, <&system 6>;
+			clock-names = "ehci_clk", "uhpck";
 			status = "disabled";
 		};
 
diff --git a/arch/arm/boot/dts/sama5d3_can.dtsi b/arch/arm/boot/dts/sama5d3_can.dtsi
new file mode 100644
index 0000000..a90075f
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3_can.dtsi
@@ -0,0 +1,71 @@
+/*
+ * at91sama5d3_can.dtsi - Device Tree Include file for AT91SAM9x5 SoC with
+ * CAN support
+ *
+ * Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * Licensed under GPLv2.
+ */
+
+#include <dt-bindings/pinctrl/at91.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	ahb {
+		apb {
+			pinctrl at fffff200 {
+				can0 {
+					pinctrl_can0_rx_tx: can0_rx_tx {
+						atmel,pins =
+							<AT91_PIOD 14 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PD14 periph C RX, conflicts with SCK0, SPI0_NPCS1 */
+							 AT91_PIOD 15 AT91_PERIPH_C AT91_PINCTRL_NONE>;	/* PD15 periph C TX, conflicts with CTS0, SPI0_NPCS2 */
+					};
+				};
+
+				can1 {
+					pinctrl_can1_rx_tx: can1_rx_tx {
+						atmel,pins =
+							<AT91_PIOB 14 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB14 periph B RX, conflicts with GCRS */
+							 AT91_PIOB 15 AT91_PERIPH_B AT91_PINCTRL_NONE>;	/* PB15 periph B TX, conflicts with GCOL */
+					};
+				};
+
+			};
+
+			pmc: pmc at fffffc00 {
+				periph: periphck {
+					can0_clk at 40 {
+						id = <40>;
+						default-divisor = <1>;
+					};
+
+					can1_clk at 41 {
+						id = <41>;
+						default-divisor = <1>;
+					};
+				};
+			};
+
+			can0: can at f000c000 {
+				compatible = "atmel,at91sam9x5-can";
+				reg = <0xf000c000 0x300>;
+				interrupts = <40 IRQ_TYPE_LEVEL_HIGH 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_can0_rx_tx>;
+				clocks = <&periph 40>;
+				clock-names = "can_clk";
+				status = "disabled";
+			};
+
+			can1: can at f8010000 {
+				compatible = "atmel,at91sam9x5-can";
+				reg = <0xf8010000 0x300>;
+				interrupts = <41 IRQ_TYPE_LEVEL_HIGH 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_can1_rx_tx>;
+				clocks = <&periph 41>;
+				clock-names = "can_clk";
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/sama5d3_emac.dtsi b/arch/arm/boot/dts/sama5d3_emac.dtsi
new file mode 100644
index 0000000..68d537d
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3_emac.dtsi
@@ -0,0 +1,54 @@
+/*
+ * at91sama5d3_emac.dtsi - Device Tree Include file for AT91SAM9x5 SoC with
+ * Ethernet.
+ *
+ * Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * Licensed under GPLv2.
+ */
+
+#include <dt-bindings/pinctrl/at91.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	ahb {
+		apb {
+			pinctrl at fffff200 {
+				macb1 {
+					pinctrl_macb1_rmii: macb1_rmii-0 {
+						atmel,pins =
+							<AT91_PIOC 0 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC0 periph A ETX0, conflicts with TIOA3 */
+							 AT91_PIOC 1 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC1 periph A ETX1, conflicts with TIOB3 */
+							 AT91_PIOC 2 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC2 periph A ERX0, conflicts with TCLK3 */
+							 AT91_PIOC 3 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC3 periph A ERX1, conflicts with TIOA4 */
+							 AT91_PIOC 4 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC4 periph A ETXEN, conflicts with TIOB4 */
+							 AT91_PIOC 5 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC5 periph A ECRSDV,conflicts with TCLK4 */
+							 AT91_PIOC 6 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC6 periph A ERXER, conflicts with TIOA5 */
+							 AT91_PIOC 7 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC7 periph A EREFCK, conflicts with TIOB5 */
+							 AT91_PIOC 8 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC8 periph A EMDC, conflicts with TCLK5 */
+							 AT91_PIOC 9 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PC9 periph A EMDIO  */
+					};
+				};
+			};
+
+			pmc: pmc at fffffc00 {
+				periph: periphck {
+					macb1_clk at 35 {
+						id = <35>;
+					};
+				};
+			};
+
+			macb1: ethernet at f802c000 {
+				compatible = "cdns,at32ap7000-macb", "cdns,macb";
+				reg = <0xf802c000 0x100>;
+				interrupts = <35 IRQ_TYPE_LEVEL_HIGH 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_macb1_rmii>;
+				clocks = <&periph 35>, <&periph 35>;
+				clock-names = "hclk", "pclk";
+				status = "disabled";
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/sama5d3_gmac.dtsi b/arch/arm/boot/dts/sama5d3_gmac.dtsi
new file mode 100644
index 0000000..c87425e
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3_gmac.dtsi
@@ -0,0 +1,87 @@
+/*
+ * at91sama5d3_gmac.dtsi - Device Tree Include file for AT91SAM9x5 SoC with
+ * Gigabit Ethernet.
+ *
+ * Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * Licensed under GPLv2.
+ */
+
+#include <dt-bindings/pinctrl/at91.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	ahb {
+		apb {
+			pinctrl at fffff200 {
+				macb0 {
+					pinctrl_macb0_data_rgmii: macb0_data_rgmii {
+						atmel,pins =
+							<AT91_PIOB 0 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB0 periph A GTX0, conflicts with PWMH0 */
+							 AT91_PIOB 1 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB1 periph A GTX1, conflicts with PWML0 */
+							 AT91_PIOB 2 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB2 periph A GTX2, conflicts with TK1 */
+							 AT91_PIOB 3 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB3 periph A GTX3, conflicts with TF1 */
+							 AT91_PIOB 4 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB4 periph A GRX0, conflicts with PWMH1 */
+							 AT91_PIOB 5 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB5 periph A GRX1, conflicts with PWML1 */
+							 AT91_PIOB 6 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB6 periph A GRX2, conflicts with TD1 */
+							 AT91_PIOB 7 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PB7 periph A GRX3, conflicts with RK1 */
+					};
+					pinctrl_macb0_data_gmii: macb0_data_gmii {
+						atmel,pins =
+							<AT91_PIOB 19 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB19 periph B GTX4, conflicts with MCI1_CDA */
+							 AT91_PIOB 20 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB20 periph B GTX5, conflicts with MCI1_DA0 */
+							 AT91_PIOB 21 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB21 periph B GTX6, conflicts with MCI1_DA1 */
+							 AT91_PIOB 22 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB22 periph B GTX7, conflicts with MCI1_DA2 */
+							 AT91_PIOB 23 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB23 periph B GRX4, conflicts with MCI1_DA3 */
+							 AT91_PIOB 24 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB24 periph B GRX5, conflicts with MCI1_CK */
+							 AT91_PIOB 25 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PB25 periph B GRX6, conflicts with SCK1 */
+							 AT91_PIOB 26 AT91_PERIPH_B AT91_PINCTRL_NONE>;	/* PB26 periph B GRX7, conflicts with CTS1 */
+					};
+					pinctrl_macb0_signal_rgmii: macb0_signal_rgmii {
+						atmel,pins =
+							<AT91_PIOB 8 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB8 periph A GTXCK, conflicts with PWMH2 */
+							 AT91_PIOB 9 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB9 periph A GTXEN, conflicts with PWML2 */
+							 AT91_PIOB 11 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB11 periph A GRXCK, conflicts with RD1 */
+							 AT91_PIOB 13 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB13 periph A GRXER, conflicts with PWML3 */
+							 AT91_PIOB 16 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB16 periph A GMDC */
+							 AT91_PIOB 17 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB17 periph A GMDIO */
+							 AT91_PIOB 18 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PB18 periph A G125CK */
+					};
+					pinctrl_macb0_signal_gmii: macb0_signal_gmii {
+						atmel,pins =
+							<AT91_PIOB 9 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB9 periph A GTXEN, conflicts with PWML2 */
+							 AT91_PIOB 10 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB10 periph A GTXER, conflicts with RF1 */
+							 AT91_PIOB 11 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB11 periph A GRXCK, conflicts with RD1 */
+							 AT91_PIOB 12 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB12 periph A GRXDV, conflicts with PWMH3 */
+							 AT91_PIOB 13 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB13 periph A GRXER, conflicts with PWML3 */
+							 AT91_PIOB 14 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB14 periph A GCRS, conflicts with CANRX1 */
+							 AT91_PIOB 15 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB15 periph A GCOL, conflicts with CANTX1 */
+							 AT91_PIOB 16 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB16 periph A GMDC */
+							 AT91_PIOB 17 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PB17 periph A GMDIO */
+							 AT91_PIOB 27 AT91_PERIPH_B AT91_PINCTRL_NONE>;	/* PB27 periph B G125CKO */
+					};
+
+				};
+			};
+
+			pmc: pmc at fffffc00 {
+				periph: periphck {
+					macb0_clk at 34 {
+						id = <34>;
+					};
+				};
+			};
+
+			macb0: ethernet at f0028000 {
+				compatible = "cdns,pc302-gem", "cdns,gem";
+				reg = <0xf0028000 0x100>;
+				interrupts = <34 IRQ_TYPE_LEVEL_HIGH 3>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_macb0_data_rgmii &pinctrl_macb0_signal_rgmii>;
+				clocks = <&periph 34>, <&periph 34>;
+				clock-names = "hclk", "pclk";
+				status = "disabled";
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/sama5d3_lcd.dtsi b/arch/arm/boot/dts/sama5d3_lcd.dtsi
new file mode 100644
index 0000000..924a102
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3_lcd.dtsi
@@ -0,0 +1,69 @@
+/*
+ * at91sama5d3_lcd.dtsi - Device Tree Include file for AT91SAM9x5 SoC with
+ * LCD support
+ *
+ * Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * Licensed under GPLv2.
+ */
+
+#include <dt-bindings/pinctrl/at91.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	ahb {
+		apb {
+			pinctrl at fffff200 {
+				lcd {
+					pinctrl_lcd: lcd-0 {
+						atmel,pins =
+							<AT91_PIOA 24 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA24 periph A LCDPWM */
+							 AT91_PIOA 26 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA26 periph A LCDVSYNC */
+							 AT91_PIOA 27 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA27 periph A LCDHSYNC */
+							 AT91_PIOA 25 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA25 periph A LCDDISP */
+							 AT91_PIOA 29 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA29 periph A LCDDEN */
+							 AT91_PIOA 28 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA28 periph A LCDPCK */
+							 AT91_PIOA 0 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA0 periph A LCDD0 pin */
+							 AT91_PIOA 1 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA1 periph A LCDD1 pin */
+							 AT91_PIOA 2 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA2 periph A LCDD2 pin */
+							 AT91_PIOA 3 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA3 periph A LCDD3 pin */
+							 AT91_PIOA 4 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA4 periph A LCDD4 pin */
+							 AT91_PIOA 5 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA5 periph A LCDD5 pin */
+							 AT91_PIOA 6 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA6 periph A LCDD6 pin */
+							 AT91_PIOA 7 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA7 periph A LCDD7 pin */
+							 AT91_PIOA 8 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA8 periph A LCDD8 pin */
+							 AT91_PIOA 9 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA9 periph A LCDD9 pin */
+							 AT91_PIOA 10 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA10 periph A LCDD10 pin */
+							 AT91_PIOA 11 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA11 periph A LCDD11 pin */
+							 AT91_PIOA 12 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA12 periph A LCDD12 pin */
+							 AT91_PIOA 13 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA13 periph A LCDD13 pin */
+							 AT91_PIOA 14 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA14 periph A LCDD14 pin */
+							 AT91_PIOA 15 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA15 periph A LCDD15 pin */
+							 AT91_PIOC 14 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC14 periph C LCDD16 pin */
+							 AT91_PIOC 13 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC13 periph C LCDD17 pin */
+							 AT91_PIOC 12 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC12 periph C LCDD18 pin */
+							 AT91_PIOC 11 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC11 periph C LCDD19 pin */
+							 AT91_PIOC 10 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC10 periph C LCDD20 pin */
+							 AT91_PIOC 15 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PC15 periph C LCDD21 pin */
+							 AT91_PIOE 27 AT91_PERIPH_C AT91_PINCTRL_NONE	/* PE27 periph C LCDD22 pin */
+							 AT91_PIOE 28 AT91_PERIPH_C AT91_PINCTRL_NONE>;	/* PE28 periph C LCDD23 pin */
+					};
+				};
+			};
+
+			pmc: pmc at fffffc00 {
+				periph: periphck {
+					lcdc_clk at 36 {
+						id = <36>;
+					};
+				};
+
+				system: systemck {
+					lcdck at 3 {
+						id = <3>;
+					};
+				};
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/sama5d3_mci2.dtsi b/arch/arm/boot/dts/sama5d3_mci2.dtsi
new file mode 100644
index 0000000..b40926b
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3_mci2.dtsi
@@ -0,0 +1,57 @@
+/*
+ * at91sama5d3_mci2.dtsi - Device Tree Include file for AT91SAM9x5 SoC with
+ * 3 MMC ports
+ *
+ * Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * Licensed under GPLv2.
+ */
+
+#include <dt-bindings/pinctrl/at91.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	ahb {
+		apb {
+			pinctrl at fffff200 {
+				mmc2 {
+					pinctrl_mmc2_clk_cmd_dat0: mmc2_clk_cmd_dat0 {
+						atmel,pins =
+							<AT91_PIOC 15 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC15 periph A MCI2_CK, conflicts with PCK2 */
+							 AT91_PIOC 10 AT91_PERIPH_A AT91_PINCTRL_PULL_UP	/* PC10 periph A MCI2_CDA with pullup */
+							 AT91_PIOC 11 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;	/* PC11 periph A MCI2_DA0 with pullup */
+					};
+					pinctrl_mmc2_dat1_3: mmc2_dat1_3 {
+						atmel,pins =
+							<AT91_PIOC 12 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC12 periph A MCI2_DA1 with pullup, conflicts with TIOA1 */
+							 AT91_PIOC 13 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC13 periph A MCI2_DA2 with pullup, conflicts with TIOB1 */
+							 AT91_PIOC 14 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PC14 periph A MCI2_DA3 with pullup, conflicts with TCLK1 */
+					};
+				};
+			};
+
+			pmc: pmc at fffffc00 {
+				periph: periphck {
+					mci2_clk at 23 {
+						id = <23>;
+					};
+				};
+			};
+
+			mmc2: mmc at f8004000 {
+				compatible = "atmel,hsmci";
+				reg = <0xf8004000 0x600>;
+				interrupts = <23 IRQ_TYPE_LEVEL_HIGH 0>;
+				dmas = <&dma1 2 AT91_DMA_CFG_PER_ID(1)>;
+				dma-names = "rxtx";
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_mmc2_clk_cmd_dat0 &pinctrl_mmc2_dat1_3>;
+				status = "disabled";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				clocks = <&periph 23>;
+				clock-names = "mci_clk";
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/sama5d3_tcb1.dtsi b/arch/arm/boot/dts/sama5d3_tcb1.dtsi
new file mode 100644
index 0000000..1a46ec9
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3_tcb1.dtsi
@@ -0,0 +1,38 @@
+/*
+ * at91sama5d3_tcb1.dtsi - Device Tree Include file for AT91SAM9x5 SoC with
+ * 2 TC blocks.
+ *
+ * Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * Licensed under GPLv2.
+ */
+
+#include <dt-bindings/pinctrl/at91.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	aliases {
+		tcb1 = &tcb1;
+	};
+
+	ahb {
+		apb {
+			pmc: pmc at fffffc00 {
+				periph: periphck {
+					tcb1_clk at 27 {
+						id = <27>;
+						default-divisor = <1>;
+					};
+				};
+			};
+
+			tcb1: timer at f8014000 {
+				compatible = "atmel,at91sam9x5-tcb";
+				reg = <0xf8014000 0x100>;
+				interrupts = <27 IRQ_TYPE_LEVEL_HIGH 0>;
+				clocks = <&periph 27>;
+				clock-names = "t0_clk";
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/sama5d3_uart.dtsi b/arch/arm/boot/dts/sama5d3_uart.dtsi
new file mode 100644
index 0000000..e46626a
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3_uart.dtsi
@@ -0,0 +1,46 @@
+/*
+ * at91sama5d3_uart.dtsi - Device Tree Include file for AT91SAM9x5 SoC with
+ * UART support
+ *
+ * Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
+ *
+ * Licensed under GPLv2.
+ */
+
+/ {
+	ahb {
+		apb {
+			pinctrl at fffff200 {
+				uart0 {
+					pinctrl_uart0: uart0-0 {
+						atmel,pins =
+							<AT91_PIOC 29 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PC29 periph A, conflicts with PWMFI2, ISI_D8 */
+							 AT91_PIOC 30 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>;	/* PC30 periph A with pullup, conflicts with ISI_PCK */
+					};
+				};
+
+				uart1 {
+					pinctrl_uart1: uart1-0 {
+						atmel,pins =
+							<AT91_PIOA 30 AT91_PERIPH_B AT91_PINCTRL_NONE	/* PA30 periph B, conflicts with TWD0, ISI_VSYNC */
+							 AT91_PIOA 31 AT91_PERIPH_B AT91_PINCTRL_PULL_UP>;	/* PA31 periph B with pullup, conflicts with TWCK0, ISI_HSYNC */
+					};
+				};
+			};
+
+			pmc: pmc at fffffc00 {
+				periph: periphck {
+					uart0_clk at 16 {
+						id = <16>;
+						default-divisor = <1>;
+					};
+
+					uart1_clk at 17 {
+						id = <17>;
+						default-divisor = <1>;
+					};
+				};
+			};
+		};
+	};
+};
-- 
1.7.9.5



From andrew at lunn.ch  Wed Jul 17 12:51:48 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 17 Jul 2013 18:51:48 +0200
Subject: [PATCH 0/2] Support for another NSA310 
Message-ID: <1374079910-24345-1-git-send-email-andrew@lunn.ch>

There are apparently three different designs of the ZyXEL NSA310 NAS
box. This patchset adds support for a second one, refactoring the
common DTS parts into a shared DTSI file.

What is not clear is naming. There is no obvious marketing name
difference, hardware version label, etc. So for the same of argument,
this new device uses the name NSA310a in DTS.

The second patch adds to the kirkwood_defconfig drivers not already in
the default configuration, plus some additional drivers used by other
kirkwood devices. The aim is to improve build test coverage.

	 Andrew


Andrew Lunn (2):
  ARM: Kirkwood: Add support for another ZyXEL NSA210 variant
  ARM: Kirkwood: update defconfig for used i2c devices, EXT4 FS, r8169

 arch/arm/boot/dts/Makefile                    |    1 +
 arch/arm/boot/dts/kirkwood-nsa310-common.dtsi |  107 ++++++++++++++++
 arch/arm/boot/dts/kirkwood-nsa310.dts         |  100 +--------------
 arch/arm/boot/dts/kirkwood-nsa310a.dts        |  165 +++++++++++++++++++++++++
 arch/arm/configs/kirkwood_defconfig           |   10 +-
 5 files changed, 283 insertions(+), 100 deletions(-)
 create mode 100644 arch/arm/boot/dts/kirkwood-nsa310-common.dtsi
 create mode 100644 arch/arm/boot/dts/kirkwood-nsa310a.dts

-- 
1.7.10.4



From andrew at lunn.ch  Wed Jul 17 12:51:50 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 17 Jul 2013 18:51:50 +0200
Subject: [PATCH 2/2] ARM: Kirkwood: update defconfig for used i2c devices,
 EXT4 FS, r8169
In-Reply-To: <1374079910-24345-1-git-send-email-andrew@lunn.ch>
References: <1374079910-24345-1-git-send-email-andrew@lunn.ch>
Message-ID: <1374079910-24345-3-git-send-email-andrew@lunn.ch>

Various kirkwood boards make use of i2c devices. Ensure the defconfig
builds them. Also, EXT4 FS is also common on NAS boxes, so include it
as well. And lastly, NSA310 has a RealTek 8169 onboard.

Signed-off-by: Andrew Lunn <andrew at lunn.ch>
---
 arch/arm/configs/kirkwood_defconfig |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
index 0f2aa61..4f2bf73 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig
@@ -92,6 +92,7 @@ CONFIG_MTD_M25P80=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_ORION=y
 CONFIG_BLK_DEV_LOOP=y
+CONFIG_EEPROM_AT24=y
 # CONFIG_SCSI_PROC_FS is not set
 CONFIG_BLK_DEV_SD=y
 CONFIG_BLK_DEV_SR=m
@@ -103,6 +104,7 @@ CONFIG_NETDEVICES=y
 CONFIG_MII=y
 CONFIG_NET_DSA_MV88E6123_61_65=y
 CONFIG_MV643XX_ETH=y
+CONFIG_R8169=y
 CONFIG_MARVELL_PHY=y
 CONFIG_LIBERTAS=y
 CONFIG_LIBERTAS_SDIO=y
@@ -123,7 +125,10 @@ CONFIG_I2C_MV64XXX=y
 CONFIG_SPI=y
 CONFIG_SPI_ORION=y
 CONFIG_GPIO_SYSFS=y
-# CONFIG_HWMON is not set
+CONFIG_SENSORS_ADT7475=y
+CONFIG_SENSORS_LM63=y
+CONFIG_SENSORS_LM75=y
+CONFIG_SENSORS_LM85=y
 CONFIG_THERMAL=y
 CONFIG_KIRKWOOD_THERMAL=y
 CONFIG_WATCHDOG=y
@@ -164,6 +169,8 @@ CONFIG_LEDS_TRIGGER_TIMER=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
 CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_RS5C372=y
+CONFIG_RTC_DRV_PCF8563=y
 CONFIG_RTC_DRV_S35390A=y
 CONFIG_RTC_DRV_MV=y
 CONFIG_DMADEVICES=y
@@ -171,6 +178,7 @@ CONFIG_MV_XOR=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 # CONFIG_EXT3_FS_XATTR is not set
+CONFIG_EXT4_FS=y
 CONFIG_ISO9660_FS=m
 CONFIG_JOLIET=y
 CONFIG_UDF_FS=m
-- 
1.7.10.4



From andrew at lunn.ch  Wed Jul 17 12:51:49 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 17 Jul 2013 18:51:49 +0200
Subject: [PATCH 1/2] ARM: Kirkwood: Add support for another ZyXEL NSA310
 variant
In-Reply-To: <1374079910-24345-1-git-send-email-andrew@lunn.ch>
References: <1374079910-24345-1-git-send-email-andrew@lunn.ch>
Message-ID: <1374079910-24345-2-git-send-email-andrew@lunn.ch>

There are a number of variants of the ZyXEL NSA310, with slightly
different LEDs, buttons and i2c devices. Add a DTS file to support one
more of these variants.

Signed-off-by: Andrew Lunn <andrew at lunn.ch>
---
 arch/arm/boot/dts/Makefile                    |    1 +
 arch/arm/boot/dts/kirkwood-nsa310-common.dtsi |  107 ++++++++++++++++
 arch/arm/boot/dts/kirkwood-nsa310.dts         |  100 +--------------
 arch/arm/boot/dts/kirkwood-nsa310a.dts        |  165 +++++++++++++++++++++++++
 4 files changed, 274 insertions(+), 99 deletions(-)
 create mode 100644 arch/arm/boot/dts/kirkwood-nsa310-common.dtsi
 create mode 100644 arch/arm/boot/dts/kirkwood-nsa310a.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..d2ffa39 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -89,6 +89,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
 	kirkwood-ns2max.dtb \
 	kirkwood-ns2mini.dtb \
 	kirkwood-nsa310.dtb \
+	kirkwood-nsa310a.dtb \
 	kirkwood-sheevaplug.dtb \
 	kirkwood-sheevaplug-esata.dtb \
 	kirkwood-topkick.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-nsa310-common.dtsi b/arch/arm/boot/dts/kirkwood-nsa310-common.dtsi
new file mode 100644
index 0000000..8f739c8
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-nsa310-common.dtsi
@@ -0,0 +1,107 @@
+/include/ "kirkwood.dtsi"
+/include/ "kirkwood-6281.dtsi"
+
+/ {
+	model = "ZyXEL NSA310";
+
+	ocp at f1000000 {
+		pinctrl: pinctrl at 10000 {
+
+			pmx_usb_power_off: pmx-usb-power-off {
+				marvell,pins = "mpp21";
+				marvell,function = "gpio";
+			};
+			pmx_pwr_off: pmx-pwr-off {
+				marvell,pins = "mpp48";
+				marvell,function = "gpio";
+			};
+
+		};
+
+		serial at 12000 {
+			status = "ok";
+		};
+
+		sata at 80000 {
+			status = "okay";
+			nr-ports = <2>;
+		};
+
+		nand at 3000000 {
+			status = "okay";
+			chip-delay = <35>;
+
+			partition at 0 {
+				label = "uboot";
+				reg = <0x0000000 0x0100000>;
+				read-only;
+			};
+			partition at 100000 {
+				label = "uboot_env";
+				reg = <0x0100000 0x0080000>;
+			};
+			partition at 180000 {
+				label = "key_store";
+				reg = <0x0180000 0x0080000>;
+			};
+			partition at 200000 {
+				label = "info";
+				reg = <0x0200000 0x0080000>;
+			};
+			partition at 280000 {
+				label = "etc";
+				reg = <0x0280000 0x0a00000>;
+			};
+			partition at c80000 {
+				label = "kernel_1";
+				reg = <0x0c80000 0x0a00000>;
+			};
+			partition at 1680000 {
+				label = "rootfs1";
+				reg = <0x1680000 0x2fc0000>;
+			};
+			partition at 4640000 {
+				label = "kernel_2";
+				reg = <0x4640000 0x0a00000>;
+			};
+			partition at 5040000 {
+				label = "rootfs2";
+				reg = <0x5040000 0x2fc0000>;
+			};
+		};
+
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+
+	gpio_poweroff {
+		compatible = "gpio-poweroff";
+		pinctrl-0 = <&pmx_pwr_off>;
+		pinctrl-names = "default";
+		gpios = <&gpio1 16 0>;
+	};
+
+	regulators {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		pinctrl-0 = <&pmx_usb_power_off>;
+		pinctrl-names = "default";
+
+		usb0_power_off: regulator at 1 {
+			compatible = "regulator-fixed";
+			reg = <1>;
+			regulator-name = "USB Power Off";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			regulator-always-on;
+			regulator-boot-on;
+			gpio = <&gpio0 21 0>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-nsa310.dts b/arch/arm/boot/dts/kirkwood-nsa310.dts
index 6900359..62fb0a9 100644
--- a/arch/arm/boot/dts/kirkwood-nsa310.dts
+++ b/arch/arm/boot/dts/kirkwood-nsa310.dts
@@ -1,10 +1,8 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+/include/ "kirkwood-nsa310-common.dtsi"
 
 / {
-	model = "ZyXEL NSA310";
 	compatible = "zyxel,nsa310", "marvell,kirkwood-88f6281", "marvell,kirkwood";
 
 	memory {
@@ -41,11 +39,6 @@
 				marvell,function = "gpio";
 			};
 
-			pmx_usb_power_off: pmx-usb-power-off {
-				marvell,pins = "mpp21";
-				marvell,function = "gpio";
-			};
-
 			pmx_led_sys_green: pmx-led-sys-green {
 				marvell,pins = "mpp28";
 				marvell,function = "gpio";
@@ -95,20 +88,6 @@
 				marvell,pins = "mpp46";
 				marvell,function = "gpio";
 			};
-
-			pmx_pwr_off: pmx-pwr-off {
-				marvell,pins = "mpp48";
-				marvell,function = "gpio";
-			};
-		};
-
-		serial at 12000 {
-			status = "ok";
-		};
-
-		sata at 80000 {
-			status = "okay";
-			nr-ports = <2>;
 		};
 
 		i2c at 11000 {
@@ -119,57 +98,6 @@
 				reg = <0x2e>;
 			};
 		};
-
-		nand at 3000000 {
-			status = "okay";
-			chip-delay = <35>;
-
-			partition at 0 {
-				label = "uboot";
-				reg = <0x0000000 0x0100000>;
-				read-only;
-			};
-			partition at 100000 {
-				label = "uboot_env";
-				reg = <0x0100000 0x0080000>;
-			};
-			partition at 180000 {
-				label = "key_store";
-				reg = <0x0180000 0x0080000>;
-			};
-			partition at 200000 {
-				label = "info";
-				reg = <0x0200000 0x0080000>;
-			};
-			partition at 280000 {
-				label = "etc";
-				reg = <0x0280000 0x0a00000>;
-			};
-			partition at c80000 {
-				label = "kernel_1";
-				reg = <0x0c80000 0x0a00000>;
-			};
-			partition at 1680000 {
-				label = "rootfs1";
-				reg = <0x1680000 0x2fc0000>;
-			};
-			partition at 4640000 {
-				label = "kernel_2";
-				reg = <0x4640000 0x0a00000>;
-			};
-			partition at 5040000 {
-				label = "rootfs2";
-				reg = <0x5040000 0x2fc0000>;
-			};
-		};
-
-		pcie-controller {
-			status = "okay";
-
-			pcie at 1,0 {
-				status = "okay";
-			};
-		};
 	};
 
 	gpio_keys {
@@ -246,30 +174,4 @@
 			gpios = <&gpio1 8 0>;
 		};
 	};
-
-	gpio_poweroff {
-		compatible = "gpio-poweroff";
-		pinctrl-0 = <&pmx_pwr_off>;
-		pinctrl-names = "default";
-		gpios = <&gpio1 16 0>;
-	};
-
-	regulators {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <0>;
-		pinctrl-0 = <&pmx_usb_power_off>;
-		pinctrl-names = "default";
-
-		usb0_power_off: regulator at 1 {
-			compatible = "regulator-fixed";
-			reg = <1>;
-			regulator-name = "USB Power Off";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			regulator-always-on;
-			regulator-boot-on;
-			gpio = <&gpio0 21 0>;
-		};
-	};
 };
diff --git a/arch/arm/boot/dts/kirkwood-nsa310a.dts b/arch/arm/boot/dts/kirkwood-nsa310a.dts
new file mode 100644
index 0000000..1070e9d
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-nsa310a.dts
@@ -0,0 +1,165 @@
+/dts-v1/;
+
+/include/ "kirkwood-nsa310-common.dtsi"
+
+/*
+ * There are at least two different NSA310 designs. This variant does
+ * not have the red USB Led.
+ */
+
+/ {
+	compatible = "zyxel,nsa310a", "zyxel,nsa310", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x10000000>;
+	};
+
+	chosen {
+		bootargs = "console=ttyS0,115200";
+	};
+
+	ocp at f1000000 {
+		pinctrl: pinctrl at 10000 {
+			pinctrl-names = "default";
+
+			pmx_led_esata_green: pmx-led-esata-green {
+				marvell,pins = "mpp12";
+				marvell,function = "gpio";
+			};
+
+			pmx_led_esata_red: pmx-led-esata-red {
+				marvell,pins = "mpp13";
+				marvell,function = "gpio";
+			};
+
+			pmx_led_usb_green: pmx-led-usb-green {
+				marvell,pins = "mpp15";
+				marvell,function = "gpio";
+			};
+
+			pmx_usb_power_off: pmx-usb-power-off {
+				marvell,pins = "mpp21";
+				marvell,function = "gpio";
+			};
+
+			pmx_led_sys_green: pmx-led-sys-green {
+				marvell,pins = "mpp28";
+				marvell,function = "gpio";
+			};
+
+			pmx_led_sys_red: pmx-led-sys-red {
+				marvell,pins = "mpp29";
+				marvell,function = "gpio";
+			};
+
+			pmx_btn_reset: pmx-btn-reset {
+				marvell,pins = "mpp36";
+				marvell,function = "gpio";
+			};
+
+			pmx_btn_copy: pmx-btn-copy {
+				marvell,pins = "mpp37";
+				marvell,function = "gpio";
+			};
+
+			pmx_led_copy_green: pmx-led-copy-green {
+				marvell,pins = "mpp39";
+				marvell,function = "gpio";
+			};
+
+			pmx_led_copy_red: pmx-led-copy-red {
+				marvell,pins = "mpp40";
+				marvell,function = "gpio";
+			};
+
+			pmx_led_hdd_green: pmx-led-hdd-green {
+				marvell,pins = "mpp41";
+				marvell,function = "gpio";
+			};
+
+			pmx_led_hdd_red: pmx-led-hdd-red {
+				marvell,pins = "mpp42";
+				marvell,function = "gpio";
+			};
+
+			pmx_btn_power: pmx-btn-power {
+				marvell,pins = "mpp46";
+				marvell,function = "gpio";
+			};
+
+		};
+
+		i2c at 11000 {
+			status = "okay";
+
+			lm85: lm85 at 2e {
+				compatible = "lm85";
+				reg = <0x2e>;
+			};
+		};
+	};
+
+	gpio_keys {
+		compatible = "gpio-keys";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		button at 1 {
+			label = "Power Button";
+			linux,code = <116>;
+			gpios = <&gpio1 14 0>;
+		};
+		button at 2 {
+			label = "Copy Button";
+			linux,code = <133>;
+			gpios = <&gpio1 5 1>;
+		};
+		button at 3 {
+			label = "Reset Button";
+			linux,code = <0x198>;
+			gpios = <&gpio1 4 1>;
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		green-sys {
+			label = "nsa310:green:sys";
+			gpios = <&gpio0 28 0>;
+		};
+		red-sys {
+			label = "nsa310:red:sys";
+			gpios = <&gpio0 29 0>;
+		};
+		green-hdd {
+			label = "nsa310:green:hdd";
+			gpios = <&gpio1 9 0>;
+		};
+		red-hdd {
+			label = "nsa310:red:hdd";
+			gpios = <&gpio1 10 0>;
+		};
+		green-esata {
+			label = "nsa310:green:esata";
+			gpios = <&gpio0 12 0>;
+		};
+		red-esata {
+			label = "nsa310:red:esata";
+			gpios = <&gpio0 13 0>;
+		};
+		green-usb {
+			label = "nsa310:green:usb";
+			gpios = <&gpio0 15 0>;
+		};
+		green-copy {
+			label = "nsa310:green:copy";
+			gpios = <&gpio1 7 0>;
+		};
+		red-copy {
+			label = "nsa310:red:copy";
+			gpios = <&gpio1 8 0>;
+		};
+	};
+};
-- 
1.7.10.4



From broonie at kernel.org  Wed Jul 17 12:53:00 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Jul 2013 17:53:00 +0100
Subject: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them
In-Reply-To: <20130717142628.GN7080@book.gsilab.sittig.org>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1373914074-20889-2-git-send-email-gsi@denx.de>
 <20130715201734.GF11538@sirena.org.uk>
 <20130717112229.GK7080@book.gsilab.sittig.org>
 <20130717120758.GR22506@sirena.org.uk>
 <20130717142628.GN7080@book.gsilab.sittig.org>
Message-ID: <20130717165300.GU22506@sirena.org.uk>

On Wed, Jul 17, 2013 at 04:26:28PM +0200, Gerhard Sittig wrote:
> On Wed, Jul 17, 2013 at 13:07 +0100, Mark Brown wrote:

> > This is a pretty long e-mail.  It'd probably have taken less time to
> > fix the issues than to reply to the e-mail...  but anyway.

> Not quite.  Please consider that careful submission is as
> expensive as thorough review is, and that a lot of work is done
> before v1 gets submitted, which you may not always notice from
> looking at a concentrated series that may no longer suggest how
> much it took to get there (especially when prepared carefully).

This is rather undermined the more time and effort gets spent pushing
back against doing trival fixes, of course...  besides, the issues here
are all really simple to fix and test.  It's not a major or risky
rewrite of the driver or anything like that - most of this can be tested
by just probing the driver.

> As mentioned before I did not question the need to fix issues as
> they get identified.  I just asked whether reworking the serial

OK, so send patches then.

> The initial COMMON_CLK implementation in part 09/24 registers
> clkdev items for compatibility during migration.  The string
> isn't greppable since it's constructed by the preprocessor in the
> MCLK data setup, see the MCLK_SETUP_DATA_PSC() macro.

Ugh, right - it didn't show up in searches due to being hidden by the
macro.

> Now let me see how I can improve the SPI driver with regard to
> overall clock handling and beyond mere operation by coincidence
> in the absence of errors.  But please understand that I don't
> want to stall the common clock support for a whole platform just
> because some of the drivers it needs to touch to keep them
> operational have other issues that weren't addressed yet, while
> these issues aren't introduced with the series but preceed it.

Again, you're not being asked to implement substantial new functionality
here.  From my point of view I can't test this at all so I'm looking at
code that's obviously not good for the standard clock API and wondering
if it even works or how robust it's going to be going forward as the
common clock code changes which makes me relucatant to say it'll be OK.

The fact that you're switching over to use generic code is itself a
reason to make sure that the API usage is sane, dodgy API usage against
open coded clock implementations is less risky than against the common
code.
-------------- 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/20130717/df54aed2/attachment.sig>

From swarren at wwwdotorg.org  Wed Jul 17 12:57:08 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Jul 2013 10:57:08 -0600
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <20130717030246.GA4541@S2101-09.ap.freescale.net>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <20130716041056.GA30067@S2101-09.ap.freescale.net>
 <51E56AA7.7020103@wwwdotorg.org>
 <20130717030246.GA4541@S2101-09.ap.freescale.net>
Message-ID: <51E6CCE4.20705@wwwdotorg.org>

On 07/16/2013 09:02 PM, Shawn Guo wrote:
> On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote:
>> Registering the driver earlier won't cause any bugs. However, it's not
>> the correct approach.
>>
>> Deferred probe /is/ the approach for assuring correct dependencies
>> between drivers. It works and should be used. There are not enough
>> initcall levels to play games using initcalls and solve all the issues,
>> and the ordering requirements vary board-to-board. Deferred probe at
>> runtime handles this without having to manually place all the drivers
>> into specific initcall levels, and dynamically adjusts to board
>> differences, since it all happens automatically at run-time.
> 
> I do not quite follow the argument here.  I agree with you that
> deferred probe is the approach to solve dependencies.  But it does not
> necessarily mean that initcall can not be used to help it save some
> nasty or nested deferring.  Deferred probe and initcalls are not two
> mutually exclusive mechanisms but two which can help each other.

My understanding is that deferred probe was implemented specifically to
avoid having to, or allowing, the use of initcall levels to determine
probe order.

However, if someone closely associated with the implementation of
deferred probe (e.g. Grant, or a device core maintainer) is willing to
step up and say I'm wrong, I'll drop my objection.


From rric at kernel.org  Wed Jul 17 12:57:43 2013
From: rric at kernel.org (Robert Richter)
Date: Wed, 17 Jul 2013 18:57:43 +0200
Subject: [PATCH] arm, kbuild: make "make install" not depend on vmlinux
In-Reply-To: <CA+55aFx4G5gME3ByqE0Wr-_t2x_6WkP3Ta4k1z4jfW+PrcK0og@mail.gmail.com>
References: <20130710133742.GA29368@emu.suse.cz>
 <CA+55aFxtvT3Yvbxe5JGBThZS13payymFJ7jCLyEiE2iNDvsZtQ@mail.gmail.com>
 <20130711135445.GA21500@sepie.suse.cz>
 <CA+55aFyVjugxM7cUDWi0ASWttYthCxa6e7X3CADknBcSFxWgew@mail.gmail.com>
 <20130712105721.GF8731@rric.localhost>
 <20130717160506.GI8731@rric.localhost>
 <CA+55aFx4G5gME3ByqE0Wr-_t2x_6WkP3Ta4k1z4jfW+PrcK0og@mail.gmail.com>
Message-ID: <20130717165743.GK8731@rric.localhost>

On 17.07.13 09:36:57, Linus Torvalds wrote:
> On Wed, Jul 17, 2013 at 9:05 AM, Robert Richter <rric at kernel.org> wrote:
> >
> > I narrowed this down. The problem is that zinstall on ARCH=arm has a
> > dependency to vmlinux which does a prepare/prepare3 and finally does a
> > forced rebuild of kernel.release even if it exists already.
> >
> > Rebuilding it removes kernel.release first and then recreates it. This
> > might race with another parallel make job running depmod.
> >
> > So on arm and maybe other archs we need the same as for x86:
> >
> >  1648e4f8 x86, kbuild: make "make install" not depend on vmlinux
> >
> > The patch below fixes this for arm. It is build-tested in my
> > environment, but please test it in others too if possible.
> 
> Ack. This looks like the right thing to do.

Thanks for looking at this.

> That said, I think for clarity you might perhaps want to make the
> unrelated change of adding double quotes around $(KERNELRELEASE) a
> separate patch. Not a big deal, but it took me a moment to say "why
> did he do that" (in fact, I'm not sure KERNEL_RELEASE can actually
> validly have spaces in it, but quoting it is certainly not wrong
> either - but it might be unnecessary.

If kernel.release doen't exist KERNEL_RELEASE is empty, thus all args
for install.sh shift one arg left. Putting it in quotes avoids this.
Noticed this since the first verified file in install.sh ($2) should
be the image file but was already System.map ($3).

Will splitt the patches and resend.

-Robert


From swarren at wwwdotorg.org  Wed Jul 17 13:01:30 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Jul 2013 11:01:30 -0600
Subject: [PATCH] ASoC: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
In-Reply-To: <20130717083003.GA22506@sirena.org.uk>
References: <1374013667-21435-1-git-send-email-swarren@wwwdotorg.org>
 <20130717083003.GA22506@sirena.org.uk>
Message-ID: <51E6CDEA.7060003@wwwdotorg.org>

On 07/17/2013 02:30 AM, Mark Brown wrote:
> On Tue, Jul 16, 2013 at 04:27:47PM -0600, Stephen Warren wrote:
> 
>> Stop selecting I2S/AC97/SPDIF controller drivers from the machine
>> driver config options; this doesn't really work if we don't know
>> which specific SoC(s) we're building for. However, set their
>> default values based on SND_SOC_TEGRA, since most people will
>> probably want to enable support for all SoCs. This also avoids
>> the need to change any defconfig files.
> 
> This doesn't seem terribly clever and is definitely not idiomatic
> for ASoC.  If you want to just select all CPUs that'd be fine but
> forcing the user to select the individual components isn't the
> style anything else uses.

So I think what you're saying is that machine drivers should be
changed like:

-       select SND_SOC_TEGRA20_I2S if ARCH_TEGRA_2x_SOC
-       select SND_SOC_TEGRA30_I2S if ARCH_TEGRA_3x_SOC
+       select SND_SOC_TEGRA20_I2S
+       select SND_SOC_TEGRA30_I2S

But then, it won't be possible to disable support for older SoCs,
since simply enabling a machine driver that might support Tegra20
would force ASoC support for Tegra20 to be enabled, even if the user
only cares about Tegra30.


From linux at arm.linux.org.uk  Wed Jul 17 13:00:39 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 18:00:39 +0100
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <alpine.LFD.2.03.1307171148160.14924@syhkavp.arg>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374052705.3146.86.camel@hornet>
 <alpine.LFD.2.03.1307170825240.14924@syhkavp.arg>
 <1374067786.3146.123.camel@hornet>
 <alpine.LFD.2.03.1307171014510.14924@syhkavp.arg>
 <1374070811.3146.124.camel@hornet>
 <alpine.LFD.2.03.1307171148160.14924@syhkavp.arg>
Message-ID: <20130717170038.GP24642@n2100.arm.linux.org.uk>

On Wed, Jul 17, 2013 at 11:57:55AM -0400, Nicolas Pitre wrote:
> The sanest location at this point might simply be 
> drivers/platform/vexpress_spc.c or drivers/platform/vexpress/spc.c 
> depending on whether or not more such driver glue is expected in the 
> vexpress future.  No point putting "arm" in the path, especially if this 
> is later reused on arm64.

You wouldn't be making that argument if it were arch/arm64 and arch/arm32 -
you'd probably be arguing that "arm" made perfect sense.

Don't get too hung up on names please, it's really not worth the time
and effort being soo pedantic, and being soo pedantic leads to "pointless
churn" when someone comes along and wants to pedantically change the
names because it no longer matches the users.


From torvalds at linux-foundation.org  Wed Jul 17 13:03:20 2013
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Wed, 17 Jul 2013 10:03:20 -0700
Subject: [PATCH] arm, kbuild: make "make install" not depend on vmlinux
In-Reply-To: <20130717165743.GK8731@rric.localhost>
References: <20130710133742.GA29368@emu.suse.cz>
 <CA+55aFxtvT3Yvbxe5JGBThZS13payymFJ7jCLyEiE2iNDvsZtQ@mail.gmail.com>
 <20130711135445.GA21500@sepie.suse.cz>
 <CA+55aFyVjugxM7cUDWi0ASWttYthCxa6e7X3CADknBcSFxWgew@mail.gmail.com>
 <20130712105721.GF8731@rric.localhost>
 <20130717160506.GI8731@rric.localhost>
 <CA+55aFx4G5gME3ByqE0Wr-_t2x_6WkP3Ta4k1z4jfW+PrcK0og@mail.gmail.com>
 <20130717165743.GK8731@rric.localhost>
Message-ID: <CA+55aFzhmV7iq+Pv37trMCmdNzk53ORAoj0a6rV14fzKta3Dhw@mail.gmail.com>

On Wed, Jul 17, 2013 at 9:57 AM, Robert Richter <rric at kernel.org> wrote:
>
> If kernel.release doen't exist KERNEL_RELEASE is empty, thus all args
> for install.sh shift one arg left.

You know what? I read the patch, but I didn't read your changelog well
enough. You already explained that in the commit log, and I just
missed it like some blind monkey. My bad.

> Will splitt the patches and resend.

No need to split, I was wrong, it wasn't some unrelated cleanup, and
you were right the first time.

So Michal (or ARM people - whoever wants to take the patch), just take
my ack. No objections.

                 Linus


From linux at arm.linux.org.uk  Wed Jul 17 13:02:33 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 18:02:33 +0100
Subject: [PATCH RFC v2 13/14] ARM: debug: move davinci debug to generic
 8250 code
In-Reply-To: <51E6887F.3090808@ti.com>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
 <E1Uz8OD-00048N-Be@rmk-PC.arm.linux.org.uk> <51E6887F.3090808@ti.com>
Message-ID: <20130717170233.GQ24642@n2100.arm.linux.org.uk>

On Wed, Jul 17, 2013 at 05:35:19PM +0530, Sekhar Nori wrote:
> On 7/16/2013 10:16 PM, Russell King wrote:
> > Davinci's debugging is just a copy of the old 8250_32 code with a
> > different base address.  Incorporate this into the generic 8250
> > debug code.
> > 
> > Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
> 
> Tested on DA850 EVM
> 
> Acked-by: Sekhar Nori <nsekhar at ti.com>

You may wish to consider whether a Tested-by tag would be a more accurate
attributation if you actually tested the patch.


From linux at arm.linux.org.uk  Wed Jul 17 13:04:06 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 18:04:06 +0100
Subject: [PATCH RFC v2 0/14] Clean up debugging support
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <20130717170406.GR24642@n2100.arm.linux.org.uk>

On Tue, Jul 16, 2013 at 05:32:43PM +0100, Russell King - ARM Linux wrote:
> This is the second posting of this series, with a few additional patches
> on top to go a little further.  Changes since the last posting:

Okay, I think everyone is happy with this, and it's time to go into
linux-next, so it'll be visible in my tree from tomorrow.

Please keep the tested-by/acked-by etc coming.


From grygorii.strashko at ti.com  Wed Jul 17 12:56:22 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Wed, 17 Jul 2013 19:56:22 +0300
Subject: [PATCH 2/3] ARM: OMAP2+: omap_device: add pinctrl handling
In-Reply-To: <20130717153838.GJ7656@atomide.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
 <1374061312-25469-3-git-send-email-grygorii.strashko@ti.com>
 <20130717153838.GJ7656@atomide.com>
Message-ID: <51E6CCB6.2000907@ti.com>

On 07/17/2013 06:38 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko at ti.com> [130717 04:49]:
>> Before switching to DT pinctrl states of OMAP IPs have been handled by hwmod
>> framework. After switching to DT-boot the pinctrl handling was dropped from
>> hwmod framework and, as it was recommended, OMAP IP's drivers have to be updated
>> to handle pinctrl states by itself using pinctrl_pm_select_xx() helpers
>> (see http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html)
>>
>> But this is not right for OMAP2+ SoC where real IPs state is controlled
>> by omap_device core which enables/disables modules & clocks actually.
>
> I'm not convinced we should try to handle this in a generic way
> as only some devices need dynamic remuxing of some pins.
>
>> For example, if OMAP I2C driver will handle pinctrl state during system wide
>> suspend the following issue may occure:
>> - suspend_noirq - I2C device can be still active because of PM auto-suspend
>>    |-_od_suspend_noirq
>>       |- omap_i2c_suspend_noirq
>>          |- PINs state set to SLEEP
>>    |- pm_generic_runtime_suspend
>>       |- omap_i2c_runtime_suspend()
>>          |- PINs state set to IDLE  <--- *oops* PINs state is IDLE and not SLEEP
>>    |- omap_device_idle()
>>       |- omap_hwmod_idle()
>>          |- _idle()
>>             |- disbale module (sysc&clocks)
>
> And in this example you are assuming that you need separate idle and
> sleep states, which is not true at least for most cases I've seen.

I don't need both states (at least right now) :), but
- if any OMAP2+ driver will have two states defined: "idle" and "sleep"
- and if it will try to manage them from drivers callbacks only using
   pure calls to pinctrl_pm_select_xx() helpers

the "idle" state will be selected during suspend and *not* "sleep".

>
> It is possible that am33xx needs separate idle and sleep states, but
> most likely only for some pins. For omap[345] we can get away with
> just the default state for most cases.
>


In case, if only "default" state is defined for device - nothing will
  be done by OMAP device framework for it (I mean any call to
pinctrl_pm_select_xx() will do nothing - it just checks that there is
no state and returns 0).

> Regards,
>
> Tony
>

Regards,
- grygorii


From marex at denx.de  Wed Jul 17 13:05:30 2013
From: marex at denx.de (Marek Vasut)
Date: Wed, 17 Jul 2013 19:05:30 +0200
Subject: [PATCH 2/2] ARM: dts: imx28: Adjust i2c interrupt bindings
In-Reply-To: <201305221219.43558.jbe@pengutronix.de>
References: <1368713639-21485-1-git-send-email-fabio.estevam@freescale.com>
 <CAOMZO5AKKVeTMsXpG9wa-eeLocBStUwPjQEe3n6fRVY2aSc7Nw@mail.gmail.com>
 <201305221219.43558.jbe@pengutronix.de>
Message-ID: <201307171905.30981.marex@denx.de>

Dear Juergen Beisert,

> Hi Fabio,
> 
> > i2c slowness is a different issue.
> 
> Same happens here for my i.M23 based platform. It seems the PIO mode does
> not work, or at least not like it works on a i.MX28. Each short transfer
> needs about one second (without an error message) but does not send
> anything on the I2C lines.
> 
> I need the following patches to make I2C master work within a 3.10-rc2
> kernel:
> 
> Subject: [PATCH] I2C/MXS: distinguish i.MX23 and i.MX28 based I2C
> controller Signed-off-by: Juergen Beisert <jbe at pengutronix.de>

Can you please properly submit this patch ?

Best regards,
Marek Vasut


From soren.brinkmann at xilinx.com  Wed Jul 17 13:10:12 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Wed, 17 Jul 2013 10:10:12 -0700
Subject: [PATCH 0/3] arm: zynq: SLCR clean up
Message-ID: <1374081015-31431-1-git-send-email-soren.brinkmann@xilinx.com>

These are just a few patches cleaning up the driver - well at least I
find it cleaner this way.
3/3 though adds correct read-modify-write for some register accesses.
The current implementation doesn't seem to do any harm, but this looks
better, IMHO.

	S?ren

Soren Brinkmann (3):
  arm: zynq: slcr: Remove redundant header #includes
  arm: zynq: slcr: Clean up #defines
  arm: zynq: slcr: Use read-modify-write for register writes

 arch/arm/mach-zynq/slcr.c | 45 +++++++++++++++++----------------------------
 1 file changed, 17 insertions(+), 28 deletions(-)

-- 
1.8.3.3



From soren.brinkmann at xilinx.com  Wed Jul 17 13:10:13 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Wed, 17 Jul 2013 10:10:13 -0700
Subject: [PATCH 1/3] arm: zynq: slcr: Remove redundant header #includes
In-Reply-To: <1374081015-31431-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1374081015-31431-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <1374081015-31431-2-git-send-email-soren.brinkmann@xilinx.com>

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
---
 arch/arm/mach-zynq/slcr.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/mach-zynq/slcr.c b/arch/arm/mach-zynq/slcr.c
index 50d008d..232c275 100644
--- a/arch/arm/mach-zynq/slcr.c
+++ b/arch/arm/mach-zynq/slcr.c
@@ -14,18 +14,8 @@
  * 02139, USA.
  */
 
-#include <linux/export.h>
 #include <linux/io.h>
-#include <linux/fs.h>
-#include <linux/interrupt.h>
-#include <linux/init.h>
-#include <linux/kernel.h>
-#include <linux/module.h>
 #include <linux/of_address.h>
-#include <linux/uaccess.h>
-#include <linux/platform_device.h>
-#include <linux/slab.h>
-#include <linux/string.h>
 #include <linux/clk/zynq.h>
 #include "common.h"
 
-- 
1.8.3.3



From soren.brinkmann at xilinx.com  Wed Jul 17 13:10:14 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Wed, 17 Jul 2013 10:10:14 -0700
Subject: [PATCH 2/3] arm: zynq: slcr: Clean up #defines
In-Reply-To: <1374081015-31431-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1374081015-31431-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <1374081015-31431-3-git-send-email-soren.brinkmann@xilinx.com>

Use a common naming scheme for register offset #defines:
Some of those used a '_OFFSET' suffix to distinguish them from others.
This scheme is used for all register offsets now.

Separate the register offset #defines from others and sort them in
increasing order.

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
---
 arch/arm/mach-zynq/slcr.c | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-zynq/slcr.c b/arch/arm/mach-zynq/slcr.c
index 232c275..44a4ab6 100644
--- a/arch/arm/mach-zynq/slcr.c
+++ b/arch/arm/mach-zynq/slcr.c
@@ -19,17 +19,16 @@
 #include <linux/clk/zynq.h>
 #include "common.h"
 
-#define SLCR_UNLOCK_MAGIC		0xDF0D
-#define SLCR_UNLOCK			0x8   /* SCLR unlock register */
-
+/* register offsets */
+#define SLCR_UNLOCK_OFFSET		0x8   /* SCLR unlock register */
 #define SLCR_PS_RST_CTRL_OFFSET		0x200 /* PS Software Reset Control */
+#define SLCR_A9_CPU_RST_CTRL_OFFSET	0x244 /* CPU Software Reset Control */
+#define SLCR_REBOOT_STATUS_OFFSET	0x258 /* PS Reboot Status */
 
+#define SLCR_UNLOCK_MAGIC		0xDF0D
 #define SLCR_A9_CPU_CLKSTOP		0x10
 #define SLCR_A9_CPU_RST			0x1
 
-#define SLCR_A9_CPU_RST_CTRL		0x244 /* CPU Software Reset Control */
-#define SLCR_REBOOT_STATUS		0x258 /* PS Reboot Status */
-
 void __iomem *zynq_slcr_base;
 
 /**
@@ -44,15 +43,15 @@ void zynq_slcr_system_reset(void)
 	 * Note that this seems to require raw i/o
 	 * functions or there's a lockup?
 	 */
-	writel(SLCR_UNLOCK_MAGIC, zynq_slcr_base + SLCR_UNLOCK);
+	writel(SLCR_UNLOCK_MAGIC, zynq_slcr_base + SLCR_UNLOCK_OFFSET);
 
 	/*
 	 * Clear 0x0F000000 bits of reboot status register to workaround
 	 * the FSBL not loading the bitstream after soft-reboot
 	 * This is a temporary solution until we know more.
 	 */
-	reboot = readl(zynq_slcr_base + SLCR_REBOOT_STATUS);
-	writel(reboot & 0xF0FFFFFF, zynq_slcr_base + SLCR_REBOOT_STATUS);
+	reboot = readl(zynq_slcr_base + SLCR_REBOOT_STATUS_OFFSET);
+	writel(reboot & 0xF0FFFFFF, zynq_slcr_base + SLCR_REBOOT_STATUS_OFFSET);
 	writel(1, zynq_slcr_base + SLCR_PS_RST_CTRL_OFFSET);
 }
 
@@ -64,9 +63,9 @@ void zynq_slcr_cpu_start(int cpu)
 {
 	/* enable CPUn */
 	writel(SLCR_A9_CPU_CLKSTOP << cpu,
-	       zynq_slcr_base + SLCR_A9_CPU_RST_CTRL);
+	       zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
 	/* enable CLK for CPUn */
-	writel(0x0 << cpu, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL);
+	writel(0x0 << cpu, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
 }
 
 /**
@@ -77,7 +76,7 @@ void zynq_slcr_cpu_stop(int cpu)
 {
 	/* stop CLK and reset CPUn */
 	writel((SLCR_A9_CPU_CLKSTOP | SLCR_A9_CPU_RST) << cpu,
-	       zynq_slcr_base + SLCR_A9_CPU_RST_CTRL);
+	       zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
 }
 
 /**
@@ -103,7 +102,7 @@ int __init zynq_slcr_init(void)
 	}
 
 	/* unlock the SLCR so that registers can be changed */
-	writel(SLCR_UNLOCK_MAGIC, zynq_slcr_base + SLCR_UNLOCK);
+	writel(SLCR_UNLOCK_MAGIC, zynq_slcr_base + SLCR_UNLOCK_OFFSET);
 
 	pr_info("%s mapped to %p\n", np->name, zynq_slcr_base);
 
-- 
1.8.3.3



From soren.brinkmann at xilinx.com  Wed Jul 17 13:10:15 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Wed, 17 Jul 2013 10:10:15 -0700
Subject: [PATCH 3/3] arm: zynq: slcr: Use read-modify-write for register writes
In-Reply-To: <1374081015-31431-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1374081015-31431-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <1374081015-31431-4-git-send-email-soren.brinkmann@xilinx.com>

zynq_slcr_cpu_start/stop() ignored the current register state when
writing to a register. Fixing this by implementing proper
read-modify-write.

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
---
 arch/arm/mach-zynq/slcr.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-zynq/slcr.c b/arch/arm/mach-zynq/slcr.c
index 44a4ab6..1836d5a 100644
--- a/arch/arm/mach-zynq/slcr.c
+++ b/arch/arm/mach-zynq/slcr.c
@@ -61,11 +61,11 @@ void zynq_slcr_system_reset(void)
  */
 void zynq_slcr_cpu_start(int cpu)
 {
-	/* enable CPUn */
-	writel(SLCR_A9_CPU_CLKSTOP << cpu,
-	       zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
-	/* enable CLK for CPUn */
-	writel(0x0 << cpu, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
+	u32 reg = readl(zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
+	reg &= ~(SLCR_A9_CPU_RST << cpu);
+	writel(reg, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
+	reg &= ~(SLCR_A9_CPU_CLKSTOP << cpu);
+	writel(reg, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
 }
 
 /**
@@ -74,9 +74,9 @@ void zynq_slcr_cpu_start(int cpu)
  */
 void zynq_slcr_cpu_stop(int cpu)
 {
-	/* stop CLK and reset CPUn */
-	writel((SLCR_A9_CPU_CLKSTOP | SLCR_A9_CPU_RST) << cpu,
-	       zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
+	u32 reg = readl(zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
+	reg |= (SLCR_A9_CPU_CLKSTOP | SLCR_A9_CPU_RST) << cpu;
+	writel(reg, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
 }
 
 /**
-- 
1.8.3.3



From swarren at wwwdotorg.org  Wed Jul 17 13:11:19 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Jul 2013 11:11:19 -0600
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <2989497.8E7gzkcamn@avalon>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <2883016.87pKJk9n0R@avalon> <51E4C073.4020407@wwwdotorg.org>
 <2989497.8E7gzkcamn@avalon>
Message-ID: <51E6D037.3020706@wwwdotorg.org>

On 07/17/2013 05:00 AM, Laurent Pinchart wrote:
> On Monday 15 July 2013 21:39:31 Stephen Warren wrote:
...
>> But then there's a problem where people assume that the common flags are
>> always available, and somewhere they aren't... Care is needed in the
>> choice of which common flags to define and/or how they're used.
> 
> Exactly. That's why I think listing the supported common flags in individual 
> bindings makes sense when some of the flags are not supported by all devices. 
> As the only PWM flags currently used are common to all PWM devices I can leave 
> this out now. I have no strong preference, I'll follow your opinion on this.

Yes, I guess separating the concept of defining common flags and which
devices use them is good. And then indeed individual devices need to
define which of the common flags they support. I'd still like to see the
*definition* of those common flags in some central place (i.e. pwm.txt
or a header that defines constants for it), and the other device
bindings simply reference that for the actual definitions.



From linux at arm.linux.org.uk  Wed Jul 17 13:13:44 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 18:13:44 +0100
Subject: [PATCH v2 24/42] ARM: at91: move at91sam9 boards to new at91
 clk implem
In-Reply-To: <1374075433-20170-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <1374075433-20170-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <20130717171343.GS24642@n2100.arm.linux.org.uk>

On Wed, Jul 17, 2013 at 05:37:13PM +0200, Boris BREZILLON wrote:
> Move at91 clk init from early_init to timer_init for all at91sam9 non dt
> boards.

Using black ball point pen, please complete the following sentence using
as many words as you desire.  Additional underscores are available on
request.

The reason for this change is ______________________________________.

Thanks. :)


From gregkh at linuxfoundation.org  Wed Jul 17 13:25:10 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Wed, 17 Jul 2013 10:25:10 -0700
Subject: [PATCH v9 1/8] drivers: phy: add generic PHY framework
In-Reply-To: <51E664CB.8050906@ti.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <1372247257-30186-2-git-send-email-kishon@ti.com>
 <20130717062944.GA24968@kroah.com> <51E664CB.8050906@ti.com>
Message-ID: <20130717172510.GB17093@kroah.com>

On Wed, Jul 17, 2013 at 03:02:59PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Wednesday 17 July 2013 11:59 AM, Greg KH wrote:
> > On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
> >> +menuconfig GENERIC_PHY
> >> +	tristate "PHY Subsystem"
> >> +	help
> >> +	  Generic PHY support.
> >> +
> >> +	  This framework is designed to provide a generic interface for PHY
> >> +	  devices present in the kernel. This layer will have the generic
> >> +	  API by which phy drivers can create PHY using the phy framework and
> >> +	  phy users can obtain reference to the PHY.
> > 
> > Shouldn't this be something that other drivers select?  How will anyone
> > know if they need this or not?
> 
> All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those
> PHY drivers can be selected like in [1].
> The PHY consumer driver should ideally use *depends on* in their Kconfig.
> 
> [1] ->
> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html

No, switch it around the other way.  How would I even _know_ that I need
to enable the generic PHY subsystem in the first place?  How can I
determine that I need this for my hardware?  You need to give hints to
someone who doesn't even know what a PHY is, otherwise they will always
disable it and move on.

> >> --- /dev/null
> >> +++ b/drivers/phy/phy-core.c
> >> @@ -0,0 +1,544 @@
> >> +/*
> >> + * phy-core.c  --  Generic Phy framework.
> >> + *
> >> + * Copyright (C) 2013 Texas Instruments
> >> + *
> >> + * Author: Kishon Vijay Abraham I <kishon at ti.com>
> >> + *
> >> + * This program is free software; you can redistribute  it and/or modify it
> >> + * under  the terms of  the GNU General  Public License as published by the
> >> + * Free Software Foundation;  either version 2 of the  License, or (at your
> >> + * option) any later version.
> > 
> > You really mean "any later version" (I have to ask)?
> 
> That was copied from somewhere :-s

So, is that what you really mean to have for this code?

> >> + * 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.
> >> + *
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> > 
> > Are these two paragraphs needed?  This isn't a "program", and they got a
> > copy of the GPL already with the kernel.
> 
> hmm.. I can remove that.
> > 
> >> +static struct class *phy_class;
> > 
> > Why do you need a class?
> 
> Wanted to group all the PHY drivers to be used by different subsystems
> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
> initial version [3] on using a bus_type instead of class but then it was
> decided to go with class itself.
> 
> [3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html

Ok, but what does the class usage get you?

> > When modifying/adding new sysfs stuff, you need a Documentation/ABI/
> > entry as well.
> 
> I'm not actually adding any new sysfs entry other than what a *class_create*
> must have created. Do I need to add one for that?

If you are not creating anything in sysfs at all, why use the driver
model?  (hint, I think you need to do something here to justify it...)

thanks,

greg k-h


From hartleys at visionengravers.com  Wed Jul 17 13:48:16 2013
From: hartleys at visionengravers.com (H Hartley Sweeten)
Date: Wed, 17 Jul 2013 10:48:16 -0700
Subject: [PATCH] ARM: debug: use generic option for ep93xx PL10x debug port
Message-ID: <201307171048.17430.hartleys@visionengravers.com>

The generic option DEBUG_LL_UART_PL01X is now used to select the UART
type for the kernel low-level debugging on the ep93xx platform. This
enables two config options to provide the physical and virtual base
address of the debug UART.

Use the generic options instead of providing platform specific options
to select the debug UART.

UART1 is selected with:  DEBUG_UART_PHYS = 0x808c0000
                         DEBUG_UART_VIRT = 0xfedc0000

UART2 is selected with:  DEBUG_UART_PHYS = 0x808d0000
                         DEBUG_UART_VIRT = 0xfedd0000

UART3 is selected with:  DEBUG_UART_PHYS = 0x808e0000
                         DEBUG_UART_VIRT = 0xfede0000

The selected UART must already be initialized by the bootloader. If it
isn't setup nothing will appear (which might be desired).

Signed-off-by: H Hartley Sweeten <hsweeten at visionengravers.com>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Cc: Ryan Mallon <rmallon at gmail.com>
---
This applies on top of Russell King's "Clean up the debugging support".

 arch/arm/mach-ep93xx/Kconfig                   | 14 --------------
 arch/arm/mach-ep93xx/include/mach/uncompress.h | 14 ++------------
 2 files changed, 2 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig
index fe3c1fa..93e54fd 100644
--- a/arch/arm/mach-ep93xx/Kconfig
+++ b/arch/arm/mach-ep93xx/Kconfig
@@ -194,20 +194,6 @@ config MACH_VISION_EP9307
 	  Say 'Y' here if you want your kernel to support the
 	  Vision Engraving Systems EP9307 SoM.
 
-choice
-	prompt "Select a UART for early kernel messages"
-
-config EP93XX_EARLY_UART1
-	bool "UART1"
-
-config EP93XX_EARLY_UART2
-	bool "UART2"
-
-config EP93XX_EARLY_UART3
-	bool "UART3"
-
-endchoice
-
 endmenu
 
 endif
diff --git a/arch/arm/mach-ep93xx/include/mach/uncompress.h b/arch/arm/mach-ep93xx/include/mach/uncompress.h
index b5cc77d..03c42e5 100644
--- a/arch/arm/mach-ep93xx/include/mach/uncompress.h
+++ b/arch/arm/mach-ep93xx/include/mach/uncompress.h
@@ -31,18 +31,8 @@ static void __raw_writel(unsigned int value, unsigned int ptr)
 	*((volatile unsigned int *)ptr) = value;
 }
 
-#if defined(CONFIG_EP93XX_EARLY_UART1)
-#define UART_BASE		EP93XX_UART1_PHYS_BASE
-#elif defined(CONFIG_EP93XX_EARLY_UART2)
-#define UART_BASE		EP93XX_UART2_PHYS_BASE
-#elif defined(CONFIG_EP93XX_EARLY_UART3)
-#define UART_BASE		EP93XX_UART3_PHYS_BASE
-#else
-#define UART_BASE		EP93XX_UART1_PHYS_BASE
-#endif
-
-#define PHYS_UART_DATA		(UART_BASE + 0x00)
-#define PHYS_UART_FLAG		(UART_BASE + 0x18)
+#define PHYS_UART_DATA		(CONFIG_DEBUG_UART_PHYS + 0x00)
+#define PHYS_UART_FLAG		(CONFIG_DEBUG_UART_PHYS + 0x18)
 #define UART_FLAG_TXFF		0x20
 
 static inline void putc(int c)
-- 
1.8.3.2



From dsd at laptop.org  Wed Jul 17 13:50:11 2013
From: dsd at laptop.org (Daniel Drake)
Date: Wed, 17 Jul 2013 11:50:11 -0600
Subject: DT binding review for Armada display subsystem
In-Reply-To: <20130715210900.GT14452@pengutronix.de>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <CAMLZHHRvWFrxxjr0sF0NRqvz+K1wB9Mb_OGG-8tx36A2rk-SNQ@mail.gmail.com>
 <20130715210900.GT14452@pengutronix.de>
Message-ID: <CAMLZHHSFW9o280yTURrBnvrEGWFi-a7Q2yQWsCh7X5kEWbZNyw@mail.gmail.com>

On Mon, Jul 15, 2013 at 3:09 PM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> You don't have to call drm_irq_install(). Both the exynos and i.MX
> driver do without it and at least the i.MX driver uses multiple irqs per
> drm_device.

Good point, thanks. That unblocks that item.

>> Secondly, devm. I understand from the "best practices" thread that we
>> want to have exactly one platform_device which corresponds to the
>> "super node", and all of the individual display controller components
>> will be represented by DT nodes but *without* their own
>> platform_device.
>
> A super node approach doesn't mean that there's only one platform
> device. You can still have a platform device for each component.

Yes. As noted, this was simply a preference that seemed to emerge in
the previous discussion. If in practice it causes too many headaches,
maybe we will change our minds. For now devm is the only issue I have
seen; I am avoiding devm where it is no longer possible under this
design.

The goal of getting this driver working properly on OLPC XO seems to
be a twisty path that presents a new issue at every turn. In the above
work I am trying to first implement the DT binding for Armada
510/cubox, as that is what the current code is aimed at.

I am now facing a problem with i2c/TDA998x which Russell already noted:

http://lists.freedesktop.org/archives/dri-devel/2013-June/039632.html
   What *can't* be done without a rewrite of the DRM slave encoder backend
   is to have the TDA998x I2C device provided by DT.  There are mumblings
   about redoing the slave encoder API, hopefully this will be fixed there.

This is because the existing DRM/encoder system works something like this:
1. i2c driver (e.g. tda998x_drv) registers as an i2c_driver via
drm_i2c_encoder_register()
2. The drm driver (i.e. armada) later has to know that it is expecting
a tda998x instance. It calls drm_i2c_encoder_init() to set this up.

drm_i2c_encoder init requires:
 1. The i2c_adapter in question. In a DT world, we could get this from
finding the parent node of the tda998x node (this is the i2c bus
master), and then using i2c_for_each_dev to find the first i2c adapter
instance that has the same of_node.
 2. i2c_board_info - basically the address of the device on the i2c
bus. This is basically the way of instantiating i2c devices from
platform data. Not the DT way :(

In a DT world the i2c driver would be instantiated from a node in the
DT, which already includes the info that would come in i2c_board_info.
Then later it would have to be linked to a DRM slave/encoder, perhaps
when the DRM device finds the of_node corresponding to it.

So I think the next step is fixing up DRM, as Russell hinted. Unless
someone sees another acceptable option that doesn't break our DT
design.

I am going away for 3-4 weeks now, so you won't be hearing for me for
a while. Just in case someone else wants to pick up the task in the
mean time, here is my work in progress. I'm still reading and
learning, so please don't do any detailed reviews yet :)

http://dev.laptop.org/~dsd/20130717/0001-dove-clk-dt-wip.patch

It includes the previous clock selection patch as this stuff is quite
closely bound with DT support.

Thanks
Daniel


From hartleys at visionengravers.com  Wed Jul 17 13:51:56 2013
From: hartleys at visionengravers.com (H Hartley Sweeten)
Date: Wed, 17 Jul 2013 12:51:56 -0500
Subject: [PATCH RFC v2 0/14] Clean up debugging support
In-Reply-To: <20130717170406.GR24642@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
 <20130717170406.GR24642@n2100.arm.linux.org.uk>
Message-ID: <ADE657CA350FB648AAC2C43247A983F0021DAC4AB5F0@AUSP01VMBX24.collaborationhost.net>

On Wednesday, July 17, 2013 10:04 AM, Russell King wrote:
> On Tue, Jul 16, 2013 at 05:32:43PM +0100, Russell King - ARM Linux wrote:
>> This is the second posting of this series, with a few additional patches
>> on top to go a little further.  Changes since the last posting:
>
> Okay, I think everyone is happy with this, and it's time to go into
> linux-next, so it'll be visible in my tree from tomorrow.
>
> Please keep the tested-by/acked-by etc coming.

Russell,

I just posted a patch for ep93xx that removes its platform specific
options to select the low-level debug UART. If it looks ok you can
add it to your patch series.

Regards,
Hartley


From broonie at kernel.org  Wed Jul 17 13:57:01 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Jul 2013 18:57:01 +0100
Subject: [PATCH] ASoC: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
In-Reply-To: <51E6CDEA.7060003@wwwdotorg.org>
References: <1374013667-21435-1-git-send-email-swarren@wwwdotorg.org>
 <20130717083003.GA22506@sirena.org.uk>
 <51E6CDEA.7060003@wwwdotorg.org>
Message-ID: <20130717175701.GY22506@sirena.org.uk>

On Wed, Jul 17, 2013 at 11:01:30AM -0600, Stephen Warren wrote:
> On 07/17/2013 02:30 AM, Mark Brown wrote:

> -       select SND_SOC_TEGRA20_I2S if ARCH_TEGRA_2x_SOC
> -       select SND_SOC_TEGRA30_I2S if ARCH_TEGRA_3x_SOC
> +       select SND_SOC_TEGRA20_I2S
> +       select SND_SOC_TEGRA30_I2S

> But then, it won't be possible to disable support for older SoCs,
> since simply enabling a machine driver that might support Tegra20
> would force ASoC support for Tegra20 to be enabled, even if the user
> only cares about Tegra30.

So how do they disable the core support for the older SoCs with the new
model?
-------------- 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/20130717/c1e3788a/attachment.sig>

From lars at metafoo.de  Wed Jul 17 14:04:37 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Wed, 17 Jul 2013 20:04:37 +0200
Subject: [PATCH v5 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <1374059564-6872-3-git-send-email-oleksandr.kozaruk@ti.com>
References: <1374059564-6872-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1374059564-6872-3-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <51E6DCB5.3070302@metafoo.de>

On 07/17/2013 01:12 PM, Oleksandr Kozaruk wrote:
> The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
> known also as Phoenix and PhoenixLite.
> 
> The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
> respectively. Some channels have current source and are used for
> measuring voltage drop on resistive load for detecting battery ID
> resistance, or measuring voltage drop on NTC resistors for external
> temperature measurements. Some channels measure voltage, (i.e. battery
> voltage), and have voltage dividers, thus, capable to scale voltage.
> Some channels are dedicated for measuring die temperature.
> 
> Some channels are calibrated in 2 points, having offsets from ideal
> values kept in trim registers. This is used to correct measurements.
> 
> The differences between GPADC in TWL6030 and TWL6032:
> - 10 bit vs 12 bit ADC;
> - 17 vs 19 channels;
> - channels have different purpose(i.e. battery voltage
>   channel 8 vs channel 18);
> - trim values are interpreted differently.
> 
> Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
> Girish S Ghongdemath.
> 
> Signed-off-by: Balaji T K <balajitk at ti.com>
> Signed-off-by: Graeme Gregory <gg at slimlogic.co.uk>
> Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>

Almost there (I hope). But please run scripts/checkpatch, make C=2 and make
coccicheck on your driver and fix all errors those tools give you before
submitting the driver upstream.

[...]
> +static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
> +		int channel, int *res)
> +{
> +	u8 reg = gpadc->pdata->channel_to_reg(channel);
> +	__le16 val;
> +	int raw_code;
> +	int ret;
> +
> +	ret = twl6030_gpadc_read(reg, (u8 *)&val);
> +	if (ret) {
> +		dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
> +		return ret;
> +	}
> +
> +	raw_code = le16_to_cpup(&val);

raw_code = le16_to_cpu(val)

> +	dev_dbg(gpadc->dev, "GPADC raw code: %d", raw_code);
> +
> +	if (twl6030_channel_calibrated(gpadc->pdata, channel))
> +		*res = twl6030_gpadc_make_correction(gpadc, channel, raw_code);
> +	else
> +		*res = raw_code;
> +
> +	return ret;
> +}
> +
[...]
> +static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
> +			     const struct iio_chan_spec *chan,
> +			     int *val, int *val2, long mask)
> +{
> +	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
> +	int ret = -EINVAL;
> +	long timeout;
> +
> +	mutex_lock(&gpadc->lock);
> +
> +	ret = gpadc->pdata->start_conversion(chan->channel);
> +	if (ret) {
> +		dev_err(gpadc->dev, "failed to start conversion\n");
> +		goto err;
> +	}
> +	/* wait for conversion to complete */
> +	timeout = wait_for_completion_interruptible_timeout(
> +				&gpadc->irq_complete, msecs_to_jiffies(5000));
> +	if (!timeout)
> +		return -ETIMEDOUT;
> +	else if (timeout < 0)
> +		return EINTR;

You still hold the mutex, try this instead:

	ret = wait_for_....
	if (ret == 0)
		ret = -ETIMEDOUT;
	if (ret < 0)
		goto err;


> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
> +		ret = ret ? -EIO : IIO_VAL_INT;
> +		break;
> +
> +	case IIO_CHAN_INFO_PROCESSED:
> +		ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
> +		ret = ret ? -EIO : IIO_VAL_INT;
> +		break;
> +
> +	default:
> +		break;
> +	}
> +err:
> +	mutex_unlock(&gpadc->lock);
> +
> +	return ret;
> +}
[...]
> +
> +static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
> +{
> +	int chn, d1 = 0, d2 = 0, temp;
> +	u8 trim_regs[17];
> +	int ret;
> +
> +	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
> +			TWL6030_GPADC_TRIM1, 16);
> +	if (ret < 0) {
> +		dev_err(gpadc->dev, "calibration failed\n");
> +		return ret;
> +	}
> +
> +	/*
> +	 * Loop to calculate the value needed for returning voltages from
> +	 * GPADC not values.
> +	 *
> +	 * gain is calculated to 3 decimal places fixed point.
> +	 */
> +	for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
> +
> +		switch (chn) {
> +		case 0:
> +		case 1:
> +		case 2:
> +		case 3:
> +		case 4:
> +		case 5:
> +		case 6:
> +		case 11:
> +		case 12:
> +		case 13:
> +		case 14:
> +			/* D1 */
> +			d1 = (trim_regs[3] & 0x1F) << 2;
> +			d1 |= (trim_regs[1] & 0x06) >> 1;
> +			if (trim_regs[1] & 0x01)
> +				d1 = -d1;
> +
> +			/* D2 */
> +			d2 = (trim_regs[4] & 0x3F) << 2;
> +			d2 |= (trim_regs[2] & 0x06) >> 1;
> +			if (trim_regs[2] & 0x01)
> +				d2 = -d2;
> +			break;
> +		case 8:
> +			/* D1 */
> +			temp = (trim_regs[3] & 0x1F) << 2;
> +			temp |= (trim_regs[1] & 0x06) >> 1;
> +			if (trim_regs[1] & 0x01)
> +				temp = -temp;
> +
> +			d1 = (trim_regs[8] & 0x18) << 1;
> +			d1 |= (trim_regs[7] & 0x1E) >> 1;
> +			if (trim_regs[7] & 0x01)
> +				d1 = -d1;
> +
> +			d1 += temp;
> +
> +			/* D2 */
> +			temp = (trim_regs[4] & 0x3F) << 2;
> +			temp |= (trim_regs[2] & 0x06) >> 1;
> +			if (trim_regs[2] & 0x01)
> +				temp = -temp;
> +
> +			d2 = (trim_regs[10] & 0x1F) << 2;
> +			d2 |= (trim_regs[8] & 0x06) >> 1;
> +			if (trim_regs[8] & 0x01)
> +				d2 = -d2;
> +
> +			d2 += temp;
> +			break;
> +		case 9:
> +			/* D1 */
> +			temp = (trim_regs[3] & 0x1F) << 2;
> +			temp |= (trim_regs[1] & 0x06) >> 1;
> +			if (trim_regs[1] & 0x01)
> +				temp = -temp;
> +
> +			d1 = (trim_regs[14] & 0x18) << 1;
> +			d1 |= (trim_regs[12] & 0x1E) >> 1;
> +			if (trim_regs[12] & 0x01)
> +				d1 = -d1;
> +
> +			d1 += temp;
> +
> +			/* D2 */
> +			temp = (trim_regs[4] & 0x3F) << 2;
> +			temp |= (trim_regs[2] & 0x06) >> 1;
> +			if (trim_regs[2] & 0x01)
> +				temp = -temp;
> +
> +			d2 = (trim_regs[16] & 0x1F) << 2;
> +			d2 |= (trim_regs[14] & 0x06) >> 1;
> +			if (trim_regs[14] & 0x01)
> +				d2 = -d2;
> +
> +			d2 += temp;
> +		case 10:
> +			/* D1 */
> +			d1 = (trim_regs[11] & 0x0F) << 3;
> +			d1 |= (trim_regs[9] & 0x0E) >> 1;
> +			if (trim_regs[9] & 0x01)
> +				d1 = -d1;
> +
> +			/* D2 */
> +			d2 = (trim_regs[15] & 0x0F) << 3;
> +			d2 |= (trim_regs[13] & 0x0E) >> 1;
> +			if (trim_regs[13] & 0x01)
> +				d2 = -d2;
> +			break;
> +		case 7:
> +		case 18:
> +			/* D1 */
> +			temp = (trim_regs[3] & 0x1F) << 2;
> +			temp |= (trim_regs[1] & 0x06) >> 1;
> +			if (trim_regs[1] & 0x01)
> +				temp = -temp;
> +
> +			d1 = (trim_regs[5] & 0x7E) >> 1;
> +			if (trim_regs[5] & 0x01)
> +				d1 = -d1;
> +.
> +			d1 += temp;
> +
> +			/* D2 */
> +			temp = (trim_regs[4] & 0x3F) << 2;
> +			temp |= (trim_regs[2] & 0x06) >> 1;
> +			if (trim_regs[2] & 0x01)
> +				temp = -temp;
> +
> +			d2 = (trim_regs[6] & 0xFE) >> 1;
> +			if (trim_regs[6] & 0x01)
> +				d2 = -d2;
> +
> +			d2 += temp;
> +			break;


There is quite a bit of copy paste in here. Putting the bit swizziling into
a helper function should also improbe legibility.

> +		default:
> +			/* No data for other channels */
> +			continue;
> +		}
> +
> +		twl6030_calibrate_channel(gpadc, chn, d1, d2);
> +	}
> +
> +	return 0;
> +}

> +[...]
> +static int twl6030_gpadc_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct twl6030_gpadc_data *gpadc;
> +	const struct twl6030_gpadc_platform_data *pdata;
> +	const struct of_device_id *match;
> +	struct iio_dev *indio_dev;
> +	int irq;
> +	int ret;
> +
> +	match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
> +	pdata = match ? match->data : dev->platform_data;

The twl6030_gpadc_platform_data struct is not available outside of this
file, so it is rather unlikely that dev->platfrom_data will contain such a
struct.

[...]
> +
> +static int twl6030_gpadc_remove(struct platform_device *pdev)
> +{
> +	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> +
> +	twl6030_gpadc_disable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
> +	free_irq(platform_get_irq(pdev, 0), indio_dev);

The last parameter needs to match that of the request_irq call

> +	iio_device_unregister(indio_dev);
> +	iio_device_free(indio_dev);
> +
> +	return 0;
> +}
[...]


From thierry.reding at gmail.com  Wed Jul 17 14:20:23 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Wed, 17 Jul 2013 11:20:23 -0700
Subject: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
In-Reply-To: <51E6D037.3020706@wwwdotorg.org>
References: <1373553468-6564-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <2883016.87pKJk9n0R@avalon> <51E4C073.4020407@wwwdotorg.org>
 <2989497.8E7gzkcamn@avalon> <51E6D037.3020706@wwwdotorg.org>
Message-ID: <20130717182021.GA24079@dhcp-172-17-186-34.nvidia.com>

On Wed, Jul 17, 2013 at 11:11:19AM -0600, Stephen Warren wrote:
> On 07/17/2013 05:00 AM, Laurent Pinchart wrote:
> > On Monday 15 July 2013 21:39:31 Stephen Warren wrote:
> ...
> >> But then there's a problem where people assume that the common flags are
> >> always available, and somewhere they aren't... Care is needed in the
> >> choice of which common flags to define and/or how they're used.
> > 
> > Exactly. That's why I think listing the supported common flags in individual 
> > bindings makes sense when some of the flags are not supported by all devices. 
> > As the only PWM flags currently used are common to all PWM devices I can leave 
> > this out now. I have no strong preference, I'll follow your opinion on this.
> 
> Yes, I guess separating the concept of defining common flags and which
> devices use them is good. And then indeed individual devices need to
> define which of the common flags they support. I'd still like to see the
> *definition* of those common flags in some central place (i.e. pwm.txt
> or a header that defines constants for it), and the other device
> bindings simply reference that for the actual definitions.

That sounds reasonable to me.

Thierry
-------------- 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/20130717/18cb3b2b/attachment.sig>

From swarren at wwwdotorg.org  Wed Jul 17 14:23:03 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Jul 2013 12:23:03 -0600
Subject: [PATCH] ASoC: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
In-Reply-To: <20130717175701.GY22506@sirena.org.uk>
References: <1374013667-21435-1-git-send-email-swarren@wwwdotorg.org>
 <20130717083003.GA22506@sirena.org.uk> <51E6CDEA.7060003@wwwdotorg.org>
 <20130717175701.GY22506@sirena.org.uk>
Message-ID: <51E6E107.8020300@wwwdotorg.org>

On 07/17/2013 11:57 AM, Mark Brown wrote:
> On Wed, Jul 17, 2013 at 11:01:30AM -0600, Stephen Warren wrote:
>> On 07/17/2013 02:30 AM, Mark Brown wrote:
> 
>> -       select SND_SOC_TEGRA20_I2S if ARCH_TEGRA_2x_SOC -
>> select SND_SOC_TEGRA30_I2S if ARCH_TEGRA_3x_SOC +       select
>> SND_SOC_TEGRA20_I2S +       select SND_SOC_TEGRA30_I2S
> 
>> But then, it won't be possible to disable support for older
>> SoCs, since simply enabling a machine driver that might support
>> Tegra20 would force ASoC support for Tegra20 to be enabled, even
>> if the user only cares about Tegra30.
> 
> So how do they disable the core support for the older SoCs with the
> new model?

They don't; the core support is so small it's not worth having the
ifdefs in it; just a few K. As such, it seems simpler to just always
compile in the core support, and remove the need for all the ifdef
nests in mach-tegra/. The bulk of the differences are different
drivers for different chips.


From nicolas.pitre at linaro.org  Wed Jul 17 14:29:02 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Jul 2013 14:29:02 -0400 (EDT)
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <20130717170038.GP24642@n2100.arm.linux.org.uk>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374052705.3146.86.camel@hornet>
 <alpine.LFD.2.03.1307170825240.14924@syhkavp.arg>
 <1374067786.3146.123.camel@hornet>
 <alpine.LFD.2.03.1307171014510.14924@syhkavp.arg>
 <1374070811.3146.124.camel@hornet>
 <alpine.LFD.2.03.1307171148160.14924@syhkavp.arg>
 <20130717170038.GP24642@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1307171416490.14924@syhkavp.arg>

On Wed, 17 Jul 2013, Russell King - ARM Linux wrote:

> On Wed, Jul 17, 2013 at 11:57:55AM -0400, Nicolas Pitre wrote:
> > The sanest location at this point might simply be 
> > drivers/platform/vexpress_spc.c or drivers/platform/vexpress/spc.c 
> > depending on whether or not more such driver glue is expected in the 
> > vexpress future.  No point putting "arm" in the path, especially if this 
> > is later reused on arm64.
> 
> You wouldn't be making that argument if it were arch/arm64 and arch/arm32 -
> you'd probably be arguing that "arm" made perfect sense.

Well... in a sense: yes.  But in the end, having per arch directories 
under drivers/ is silly.  We already have per arch directories under 
arch/already.

> Don't get too hung up on names please, it's really not worth the time
> and effort being soo pedantic, and being soo pedantic leads to "pointless
> churn" when someone comes along and wants to pedantically change the
> names because it no longer matches the users.

At this point I don't really care about the name.  I just want the damn 
thing merged upstream.  But after several iterations to either fit one 
or another maintainers taste, each rework ends up in that maintainer 
saying: "Now that you've reworked the code, I still don't like it since 
this no longer fits in my subsystem tree."

In fact what we'd need at this point is 
drivers/code_that_no_subsystem_maintainers_wants/.  This is becoming 
overly ridiculous.


Nicolas


From moinejf at free.fr  Wed Jul 17 14:30:14 2013
From: moinejf at free.fr (Jean-Francois Moine)
Date: Wed, 17 Jul 2013 20:30:14 +0200
Subject: DT binding review for Armada display subsystem
In-Reply-To: <CAMLZHHSFW9o280yTURrBnvrEGWFi-a7Q2yQWsCh7X5kEWbZNyw@mail.gmail.com>
References: <20130712164428.AC3D2FAAE9@dev.laptop.org>
 <CAMLZHHRvWFrxxjr0sF0NRqvz+K1wB9Mb_OGG-8tx36A2rk-SNQ@mail.gmail.com>
 <20130715210900.GT14452@pengutronix.de>
 <CAMLZHHSFW9o280yTURrBnvrEGWFi-a7Q2yQWsCh7X5kEWbZNyw@mail.gmail.com>
Message-ID: <20130717203014.339cd37c@armhf>

On Wed, 17 Jul 2013 11:50:11 -0600
Daniel Drake <dsd at laptop.org> wrote:

> I am now facing a problem with i2c/TDA998x which Russell already noted:
> 
> http://lists.freedesktop.org/archives/dri-devel/2013-June/039632.html
>    What *can't* be done without a rewrite of the DRM slave encoder backend
>    is to have the TDA998x I2C device provided by DT.  There are mumblings
>    about redoing the slave encoder API, hopefully this will be fixed there.
> 
> This is because the existing DRM/encoder system works something like this:
> 1. i2c driver (e.g. tda998x_drv) registers as an i2c_driver via
> drm_i2c_encoder_register()
> 2. The drm driver (i.e. armada) later has to know that it is expecting
> a tda998x instance. It calls drm_i2c_encoder_init() to set this up.
> 
> drm_i2c_encoder init requires:
>  1. The i2c_adapter in question. In a DT world, we could get this from
> finding the parent node of the tda998x node (this is the i2c bus
> master), and then using i2c_for_each_dev to find the first i2c adapter
> instance that has the same of_node.
>  2. i2c_board_info - basically the address of the device on the i2c
> bus. This is basically the way of instantiating i2c devices from
> platform data. Not the DT way :(
> 
> In a DT world the i2c driver would be instantiated from a node in the
> DT, which already includes the info that would come in i2c_board_info.
> Then later it would have to be linked to a DRM slave/encoder, perhaps
> when the DRM device finds the of_node corresponding to it.
> 
> So I think the next step is fixing up DRM, as Russell hinted. Unless
> someone sees another acceptable option that doesn't break our DT
> design.

Hi Daniel,

I don't see the problem with the TDA998x.

Indeed, it needs some enhancement to handle the DT, but also, the
function drm_i2c_encoder_init() is not usable in the DT case (this
function loads the module, while the module must be loaded by the DT
for it gets all parameters - i2c address and irq).

Here is the simple solution I use:

- the tda998x is declared in the DT, so the module is loaded at system
  startup time.

- its probe function is void.

- when the connector of the drm driver scans the DT, it finds the
  phandle to the tda998x.

- if / after the tda998x is loaded, the connector calls the function
  encoder_init() of the tda998x (and also increment the reference
  counter of the tda998x module to avoid this last one to be unloaded).

- the function encoder_init() of the tda998x scans the DT and it has all
  elements to run.

This working is compatible with the ticlcd driver: calling
drm_i2c_encoder_init() just prevents the tda998x to use the irq (the
i2c address is hard coded, the display connect/disconnect event is
detected by polling and reading the EDID is synchronous).

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/


From jic23 at kernel.org  Wed Jul 17 15:04:02 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Wed, 17 Jul 2013 20:04:02 +0100
Subject: [PATCH 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <51E668B4.1010000@ti.com>
References: <1373974023-23521-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1373974023-23521-3-git-send-email-oleksandr.kozaruk@ti.com>
 <c8f86766-822b-4fe3-ae2a-e0b12412ef39@email.android.com>
 <51E668B4.1010000@ti.com>
Message-ID: <7725cc73-4cab-49f5-9c33-ef3b24a7ee57@email.android.com>



Oleksandr Kozaruk <oleksandr.kozaruk at ti.com> wrote:
>Hello Jonathan,
>
> >Two very quick comments based on quick glance as it may be a while 
>before I can do a full review.
>
> >We still have channels that are only usable for temperature being 
>output to user space as voltage channels? Is the conversion so very
>hard?
>
>Can you please clarify what should return temperature channel for 
>in_tempX_input (processed)? Is it voltage or Celsius degree?
Milli degrees centigrade.

>in_tempX_raw should return ADC code? Right?
Yes

See Documentation/ABI/testing/sysfs-bus-iio
>
>Regards,
>OK.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.


From catalin.marinas at arm.com  Wed Jul 17 15:20:04 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 17 Jul 2013 20:20:04 +0100
Subject: [PATCH] arm64: use common reboot infrastructure
In-Reply-To: <1373541180-7452-1-git-send-email-marc.zyngier@arm.com>
References: <1373541180-7452-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130717192004.GD16496@MacBook-Pro.local>

On Thu, Jul 11, 2013 at 12:13:00PM +0100, Marc Zyngier wrote:
> Commit 7b6d864b48d9 (reboot: arm: change reboot_mode to use enum
> reboot_mode) changed the way reboot is handled on arm, which has a
> direct impact on arm64 as we share the reset driver on the VE platform.
> 
> The obvious fix is to move arm64 to use the same infrastructure.
> 
> Cc: Robin Holt <holt at sgi.com>
> Cc: Pawel Moll <pawel.moll at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

I just did the same before I saw your patch. Anyway, I'll take yours as
you did it first ;)

> --- a/kernel/reboot.c
> +++ b/kernel/reboot.c
> @@ -25,7 +25,7 @@ int C_A_D = 1;
>  struct pid *cad_pid;
>  EXPORT_SYMBOL(cad_pid);
>  
> -#if defined(CONFIG_ARM) || defined(CONFIG_UNICORE32)
> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_UNICORE32)
>  #define DEFAULT_REBOOT_MODE		= REBOOT_HARD
>  #else
>  #define DEFAULT_REBOOT_MODE

Do we need this or we could use the default (I think REBOOT_COLD is 0)?

-- 
Catalin


From s.hauer at pengutronix.de  Wed Jul 17 15:26:27 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Jul 2013 21:26:27 +0200
Subject: [PATCH v2 3/3] mxs: added driver for OCOTP in i.MX23 and i.MX28
In-Reply-To: <1374078460-4126-4-git-send-email-cb@sgoc.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
 <1374078460-4126-1-git-send-email-cb@sgoc.de>
 <1374078460-4126-4-git-send-email-cb@sgoc.de>
Message-ID: <20130717192627.GA12533@pengutronix.de>

Hi Christoph,

Several comments inline.

On Wed, Jul 17, 2013 at 06:27:40PM +0200, Christoph G. Baumann wrote:
> From: "Christoph G. Baumann" <cb at sgoc.de>
> 
> Signed-off-by: "Christoph G. Baumann" <cb at sgoc.de>
> ---
>  drivers/misc/Kconfig   |   14 ++
>  drivers/misc/Makefile  |    1 +
>  drivers/misc/fsl_otp.c |  363 ++++++++++++++++++++++++++++++++++++++++++++++++
>  drivers/misc/fsl_otp.h |  126 +++++++++++++++++
>  4 files changed, 504 insertions(+)
>  create mode 100644 drivers/misc/fsl_otp.c
>  create mode 100644 drivers/misc/fsl_otp.h
> 
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 8dacd4c..0740312 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -528,6 +528,20 @@ config SRAM
>  	  the genalloc API. It is supposed to be used for small on-chip SRAM
>  	  areas found on many SoCs.
>  
> +config FSL_OTP
> +	tristate "Freescale On-Chip OTP Memory Support"
> +	depends on SOC_IMX23 || SOC_IMX28
> +	default n

default n is the default. You can drop this.

> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
> + */

Please drop the address. It's wrong already.

> +static DEFINE_MUTEX(otp_mutex);
> +static struct kobject *otp_kobj;
> +static struct attribute **attrs;
> +static struct kobj_attribute *kattr;
> +static struct attribute_group attr_group;
> +static unsigned long otp_hclk_saved;
> +static u32 otp_voltage_saved;
> +static resource_size_t otp_base_address;
> +struct regulator *regu;

Collect your driver data in a struct and pass it around in functions
calls. No need to limit this driver to a single instance.

> +/* forward declaration */

Who would have guessed that? Drop this, it contains no information.

> +static int otp_wait_busy(u32 flags);

You should reorder the functions so that forward declarations are not
necessary.

> +
> +/* open the bank for the imx23/imx28 */
> +static int otp_read_prepare(void)
> +{
> +	int r;
> +
> +	/* [1] set the HCLK */
> +	/* [2] check BUSY and ERROR bit */
> +	r = otp_wait_busy(0);
> +	if (r < 0)
> +		goto error;
> +
> +	/* [3] open bank */
> +	__raw_writel(BM_OCOTP_CTRL_RD_BANK_OPEN,
> +		REGS_OCOTP_BASE + HW_OCOTP_CTRL_SET);
> +	udelay(10);
> +
> +	/* [4] wait for BUSY */
> +	r = otp_wait_busy(0);
> +	return 0;
> +error:
> +	return r;
> +}
> +
> +static int otp_read_post(void)
> +{
> +	/* [5] close bank */
> +	__raw_writel(BM_OCOTP_CTRL_RD_BANK_OPEN,
> +		REGS_OCOTP_BASE + HW_OCOTP_CTRL_CLR);
> +	return 0;
> +}
> +
> +static int otp_write_prepare(void)
> +{
> +	struct clk *hclk;
> +	int err = 0;
> +
> +	/* [1] HCLK to 24MHz. */
> +	hclk = clk_get_sys("hbus", NULL);

This is a driver, so you should use regular clk_get, not clk_get_sys.
Besides, this has to be done during probe. clk_get takes a reference to
the clock which has to be released.

> +	if (IS_ERR(hclk)) {
> +		err = PTR_ERR(hclk);
> +		goto out;
> +	}
> +	/*
> +	   WARNING  ACHTUNG  UWAGA
> +
> +	   the code below changes HCLK clock rate to 24M. This is
> +	   required to write OTP bits (7.2.2 in STMP378x Target
> +	   Specification), and might affect LCD operation, for example.
> +	   Moreover, this hacky code changes VDDIO to 2.8V; and resto-
> +	   res it only on otp_close(). This may affect... anything.
> +
> +	   You are warned now.
> +	 */
> +	otp_hclk_saved = clk_get_rate(hclk);
> +	clk_set_rate(hclk, 24000000);

You should check the return value.

> +
> +	/* [2] The voltage is set to 2.8V */
> +	regu = regulator_get(NULL, otp_data.regulator_name);

Same as with clk_get. Do it during probe time.

> +	otp_voltage_saved = regulator_get_voltage(regu);
> +	regulator_set_voltage(regu, 2800000, 2800000);

Check the return value.

> +
> +	/* [3] wait for BUSY and ERROR */
> +	err = otp_wait_busy(BM_OCOTP_CTRL_RD_BANK_OPEN);
> +out:
> +	return err;
> +}
> +
> +static int otp_write_post(void)
> +{
> +	struct clk *hclk;
> +
> +	hclk = clk_get_sys("hbus", NULL);
> +	if (IS_ERR(hclk))
> +		return PTR_ERR(hclk);
> +
> +	/* restore the clock and voltage */
> +	clk_set_rate(hclk, otp_hclk_saved);
> +	regulator_set_voltage(regu, otp_voltage_saved, otp_voltage_saved);
> +	otp_wait_busy(0);
> +
> +	/* reset */
> +	__raw_writel(BM_OCOTP_CTRL_RELOAD_SHADOWS,
> +			REGS_OCOTP_BASE + HW_OCOTP_CTRL_SET);
> +	otp_wait_busy(BM_OCOTP_CTRL_RELOAD_SHADOWS);
> +	return 0;
> +}
> +
> +static int __init map_ocotp_addr(struct platform_device *pdev)
> +{
> +	return 0;
> +}

What's this? Drop this.

> +static void unmap_ocotp_addr(void)
> +{
> +}

ditto

> +
> +static inline unsigned int get_reg_index(struct kobj_attribute *tmp)
> +{
> +	return tmp - kattr;
> +}
> +
> +static int otp_wait_busy(u32 flags)
> +{
> +	int count;
> +	u32 c;
> +
> +	for (count = 10000; count >= 0; count--) {
> +		c = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CTRL);
> +		if (!(c & (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR | flags)))
> +			break;
> +		cpu_relax();
> +	}
> +
> +	if (count < 0)
> +		return -ETIMEDOUT;
> +	return 0;
> +}
> +
> +static ssize_t otp_show(struct kobject *kobj, struct kobj_attribute *attr,
> +		      char *buf)
> +{
> +	unsigned int index = get_reg_index(attr);
> +	u32 value = 0;
> +
> +	/* sanity check */
> +	if (index >= otp_data.fuse_num)
> +		return 0;
> +
> +	mutex_lock(&otp_mutex);
> +
> +	if (otp_read_prepare()) {
> +		mutex_unlock(&otp_mutex);
> +		return 0;
> +	}
> +	value = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CUST_N(index));
> +	otp_read_post();
> +
> +	mutex_unlock(&otp_mutex);
> +	return sprintf(buf, "0x%x\n", value);
> +}
> +
> +static int otp_write_bits(int addr, u32 data, u32 magic)
> +{
> +	u32 c; /* for control register */
> +
> +	/* init the control register */
> +	c = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CTRL);
> +	c &= ~BM_OCOTP_CTRL_ADDR;
> +	c |= BF(addr, OCOTP_CTRL_ADDR);
> +	c |= BF(magic, OCOTP_CTRL_WR_UNLOCK);
> +	__raw_writel(c, REGS_OCOTP_BASE + HW_OCOTP_CTRL);
> +
> +	/* init the data register */
> +	__raw_writel(data, REGS_OCOTP_BASE + HW_OCOTP_DATA);
> +	otp_wait_busy(0);
> +
> +	mdelay(2); /* Write Postamble */
> +	return 0;
> +}
> +
> +static ssize_t otp_store(struct kobject *kobj, struct kobj_attribute *attr,
> +		       const char *buf, size_t count)
> +{
> +	unsigned int index = get_reg_index(attr);
> +	int value;
> +
> +	/* sanity check */
> +	if (index >= otp_data.fuse_num)
> +		return 0;
> +
> +	sscanf(buf, "0x%x", &value);
> +
> +	mutex_lock(&otp_mutex);
> +	if (otp_write_prepare()) {
> +		mutex_unlock(&otp_mutex);
> +		return 0;
> +	}
> +	otp_write_bits(index, value, 0x3e77);
> +	otp_write_post();
> +	mutex_unlock(&otp_mutex);
> +
> +	return count;
> +}
> +
> +static void free_otp_attr(void)
> +{
> +	kfree(attrs);
> +	attrs = NULL;
> +
> +	kfree(kattr);
> +	kattr = NULL;
> +}
> +
> +static int alloc_otp_attr(void)
> +{
> +	int i;
> +
> +	/* The last one is NULL, which is used to detect the end */
> +	attrs = kzalloc((otp_data.fuse_num + 1) * sizeof(attrs[0]),
> +			GFP_KERNEL);
> +	kattr = kzalloc(otp_data.fuse_num * sizeof(struct kobj_attribute),
> +			GFP_KERNEL);
> +
> +	if (!attrs || !kattr)
> +		goto error_out;
> +
> +	for (i = 0; i < otp_data.fuse_num; i++) {
> +		kattr[i].attr.name = otp_data.fuse_name[i];
> +		kattr[i].attr.mode = 0600;
> +		kattr[i].show  = otp_show;
> +		kattr[i].store = otp_store;
> +		attrs[i] = &kattr[i].attr;
> +		sysfs_attr_init(attrs[i]);
> +	}
> +	memset(&attr_group, 0, sizeof(attr_group));
> +	attr_group.attrs = attrs;
> +	return 0;
> +
> +error_out:
> +	free_otp_attr();
> +	return -ENOMEM;
> +}
> +
> +static int fsl_otp_probe(struct platform_device *pdev)
> +{
> +	int retval;
> +	struct fsl_otp_data *pdata;
> +
> +	/* get device base address */
> +	otp_base_address = pdev->resource->start;
> +	dev_info(&pdev->dev, "i.MX23/28 OCOTP at %p\n", otp_base_address);
> +
> +	pdata = &otp_data;
> +	if (pdev->dev.platform_data == NULL)
> +		pdev->dev.platform_data = &otp_data;

You shouldn't manipulate the platform_data pointer in the driver.
platform_data contains data passed to the driver.

> +
> +	retval = alloc_otp_attr();
> +	if (retval)
> +		return retval;
> +
> +	retval = map_ocotp_addr(pdev);
> +	if (retval)
> +		goto error;
> +
> +	otp_kobj = kobject_create_and_add("fsl_otp", NULL);
> +	if (!otp_kobj) {
> +		retval = -ENOMEM;
> +		goto error;
> +	}
> +
> +	retval = sysfs_create_group(otp_kobj, &attr_group);
> +	if (retval)
> +		goto error;
> +
> +	mutex_init(&otp_mutex);
> +	return 0;
> +error:
> +	kobject_put(otp_kobj);
> +	otp_kobj = NULL;
> +	free_otp_attr();
> +	unmap_ocotp_addr();
> +	return retval;
> +}
> +
> +static int otp_remove(struct platform_device *pdev)
> +{
> +	kobject_put(otp_kobj);
> +	otp_kobj = NULL;
> +
> +	free_otp_attr();
> +	unmap_ocotp_addr();
> +	return 0;
> +}
> +
> +static const struct of_device_id mxs_otp_dt_ids[] = {
> +	{ .compatible = "fsl,ocotp", .data = NULL, },
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mxs_otp_dt_ids);
> +
> +static struct platform_driver ocotp_driver = {
> +	.probe		= fsl_otp_probe,
> +	.remove		= otp_remove,
> +	.driver		= {
> +		.name   = "ocotp",
> +		.owner	= THIS_MODULE,
> +		.of_match_table = mxs_otp_dt_ids,
> +	},
> +};
> +
> +static int __init fsl_otp_init(void)
> +{
> +	return platform_driver_register(&ocotp_driver);
> +}
> +
> +static void __exit fsl_otp_exit(void)
> +{
> +	platform_driver_unregister(&ocotp_driver);
> +}
> +module_init(fsl_otp_init);
> +module_exit(fsl_otp_exit);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Christoph G. Baumann <cgb at debian.org>");
> +MODULE_DESCRIPTION("driver for OCOTP in i.MX23 and i.MX28");
> diff --git a/drivers/misc/fsl_otp.h b/drivers/misc/fsl_otp.h
> new file mode 100644
> index 0000000..9449f94
> --- /dev/null
> +++ b/drivers/misc/fsl_otp.h
> @@ -0,0 +1,126 @@
> +/*
> + * Copyright (C) 2010 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * Ported to 3.7 by Christoph G. Baumann <cgb at debian.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This 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.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

Here's another address of the FSF. That's the reason for not including
it.

> + */
> +#ifndef __FREESCALE_OTP__
> +#define __FREESCALE_OTP__
> +
> +
> +/* IMX23 and IMX28 share most of the defination ========================= */
> +#if (defined(CONFIG_SOC_IMX23) || defined(CONFIG_SOC_IMX28))
> +
> +#if defined(CONFIG_SOC_IMX28) && defined(CONFIG_SOC_IMX23)
> +#undef CONFIG_SOC_IMX23
> +#endif

So if the kernel supports both i.MX23 and i.MX28 you choose to make the
driver work on i.MX28 only. You have to make this a runtime decision.
See some other driver how this can be made, for example
drivers/spi/spi-imx.c. Look for the usage of of_match_device().

> +
> +
> +#define OCOTP_PHYS_ADDR         otp_base_address
> +#define REGS_OCOTP_BASE		(MXS_IO_ADDRESS(OCOTP_PHYS_ADDR))

Drop this and use ioremap in the driver.

> +#define BF(value, field)	(((value) << BP_##field) & BM_##field)
> +
> +/* MXS IO mappings */
> +
> +/*
> + * It maps the whole address space to [0xf4000000, 0xf50fffff].
> + *
> + *	OCRAM	0x00000000+0x020000	->	0xf4000000+0x020000
> + *	IO	0x80000000+0x100000	->	0xf5000000+0x100000
> + */
> +#define MXS_IO_P2V(x)	(0xf4000000 +					\
> +			(((x) & 0x80000000) >> 7) +			\
> +			(((x) & 0x000fffff)))
> +
> +#define MXS_IO_ADDRESS(x)	IOMEM(MXS_IO_P2V(x))

This also shouldn't be in a driver.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From catalin.marinas at arm.com  Wed Jul 17 15:27:46 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 17 Jul 2013 20:27:46 +0100
Subject: preempted dup_mm misses TLB invalidate
In-Reply-To: <51E43D2B.9090709@nvidia.com>
References: <51E43D2B.9090709@nvidia.com>
Message-ID: <20130717192746.GE16496@MacBook-Pro.local>

On Mon, Jul 15, 2013 at 07:19:23PM +0100, Nickolas Fortino wrote:
> I?ve noticed an issue in simulation where the Linux kernel is executing 
> a user process when the page tables and TLBs have gotten out of sync. 
> The page tables have a page marked as user read only, but the TLB has 
> the page marked as user read/write.

This happens during fork() for the current process. I think mprotect()
as well. The caller is supposed not to have threads that write its
memory while another thread does a fork().

> I?ve traced the issue back to the handling of copy on write pages 
> generated from the ?do_fork?, ?copy_process?, ?dup_mm?, ?dup_mmap? call 
> stack. If run without interruption, ?dup_mmap? calls 
> ?flush_tlb_mm(oldmm)? on completion, avoiding any issues. In this case, 
> however, about 4 million instructions after ?dup_mm? is called, 
> ?copy_pte_range? yields to another thread via __cond_resched. About 20 
> million instructions later, a user process with the ASID of the source 
> mm is scheduled.

Why would it have the same ASID? We should not reuse an ASID unless
there was a TLB invalidation for that ASID. If it's a thread of the same
process, I think it's just a user programming bug.

> This process performs a store to a page modified from 
> read/write to read only in the copy on write logic of ?copy_one_pte?. 
> Because the TLB was not invalidated, the store hits on a TLB entry with 
> read/write permissions and succeeds without a fault.
> 
> What invariant in the Linux kernel is supposed to prevent this from 
> happening? Note I have not observed user visible corruption, but it 
> seems very unlikely a successful store to a page marked as read only in 
> the kernel is safe.

See above. The only workaround would be to stop all the threads of a
process while calling fork(). Threads and fork() are not nice to
each-other.

-- 
Catalin


From catalin.marinas at arm.com  Wed Jul 17 15:41:21 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 17 Jul 2013 20:41:21 +0100
Subject: BUG: commit "ARM: Remove __ARCH_WANT_INTERRUPTS_ON_CTXSW on
 pre-ARMv6 CPUs" breaks armv5 with CONFIG_PREEMPT
In-Reply-To: <20130717085139.GJ24642@n2100.arm.linux.org.uk>
References: <51C2D5EF.3040803@pengutronix.de> <20130620102856.GC18536@arm.com>
 <20130620111255.GD18536@arm.com> <51C2E917.9000708@pengutronix.de>
 <51C2EA04.4060701@pengutronix.de> <51C2EBCD.4070206@pengutronix.de>
 <51C42AE0.9070506@pengutronix.de> <20130621135219.GC4099@arm.com>
 <51E658AF.1090009@pengutronix.de>
 <20130717085139.GJ24642@n2100.arm.linux.org.uk>
Message-ID: <20130717194121.GF16496@MacBook-Pro.local>

On Wed, Jul 17, 2013 at 09:51:39AM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 10:41:19AM +0200, Marc Kleine-Budde wrote:
> > What happend to that patch? I cannot find it in v3.10.x nor in linus/master.
> 
> Catalin sent it to me, and I didn't apply it because it's still racy.
> 
> We have stateful context switches (due to cache clearing) and this does
> nothing to solve the problem there.  If we get preempted during the
> cache clearing, things will still go wrong.
> 
> See:
> 
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7771/1
> 
> I've no idea what's happening about this.  It looks to me like nothing
> happened after Catalin's last comment there.

Too many other things to do. It's on my list for this week or early next
week.

-- 
Catalin


From nerv at dawncrow.de  Wed Jul 17 15:49:06 2013
From: nerv at dawncrow.de (=?UTF-8?B?QW5kcsOpIEhlbnRzY2hlbA==?=)
Date: Wed, 17 Jul 2013 21:49:06 +0200
Subject: arm: Only load TLS values when needed
In-Reply-To: <51E67B98.9040101@arm.com>
References: <51E42E11.1010903@dawncrow.de> <51E5836B.1010904@arm.com>
 <51E59E8F.1060501@dawncrow.de> <51E67B98.9040101@arm.com>
Message-ID: <51E6F532.1030004@dawncrow.de>

Am 17.07.2013 13:10, schrieb Jonathan Austin:
> Hi Andr?,
> 
> On 16/07/13 20:27, Andr? Hentschel wrote:
>> Hi Jonathan, First, thank you for your review.
>>
>> Am 16.07.2013 19:31, schrieb Jonathan Austin:
>>> Hi Andr?,
>>>
>>> On 15/07/13 18:14, Andr? Hentschel wrote:
>>>> From: Andr? Hentschel <nerv at dawncrow.de>
>>>>
>>>> This patch intents to reduce loading instructions when the
>>>> resulting value is not used. It's a follow up on
>>>> a4780adeefd042482f624f5e0d577bf9cdcbb760
>>>>
>>>
>>> Have you done any benchmarking to see that this has any real
>>> impact? Or tested on a !Vv6k system? It looks possible that the
>>> only case where this will perform better is where we're using
>>> switch_tls_none or switch_tls_software (both rare cases, I think)
>>> and there's some change it will make things worse in other cases?
>>
>> I have to admit that i only tested it on v6k and did no benchmark.
>>
> Do you have access to anything v6-NOT-k-ish? If not I can try and test this on something appropriate. How does your test-case access tpidrurw? If it uses inline asm then it won't work on v6-not-k, as those instructions aren't defined...

I don't, so it'd be nice if you could do that. I could imagine you have a good choice of devices at ARM :)

In my crappy test application i do it similar to Wine:
https://github.com/AndreRH/tpidrurw-test/blob/master/main.c#L29

but Wine code won't work out of the box on v6:
http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/signal_arm.c#l851

>>> One of the reasons for Russell's suggestion of placing the ldrd
>>> (which became the two ldr instructions you've removed from
>>> __switch_to, in order to maintain building for older cores) where
>>> it is was in order to reduce the chance of pipeline stalls.
>>>
>>> As I've pointed out below, there is some risk that changing that
>>> has implications for the v6 only case below (and the v6k case is
>>> now more prone to stalls with !CONFIG_CPU_USE_DOMAINS, but newer
>>> cores should have more advanced scheduling to avoid such issues
>>> anyway...)
>>
>> I'm not sure how this could make things worse on v6k, could you
>> elaborate please? Besides of the ldr and str being too close to each
>> other
> 
> Yea, that's the only issue, and in the !CONFIG_CPU_USE_DOMAINS case things are slightly worse than they were before
> 
>> i thought this patch is a good idea, because it removes two ldr
>> which are always executed. (Continuing below...)
> 
> Indeed, as long as it doesn't cause pipeline stalls then that's a gain for some cases :)
> 
> [...]
>>> Now we've only got one instruction between the store and the load
>>> and risk stalling the pipeline...
>>>
>>> Dave M cautiously says "The ancient advice was that one instruction
>>> was enough" but this is very core dependent... I wonder if anyone
>>> has a good idea about whether this is an issue here...?
>>
>> We could use a ldrd at the top, that'd be nearly what we have right
>> now, don't we?
> 
> Yea, that'd be good - as far as I can see from an 1136 TRM, the ldrd *may* be two cycles (depending on alignment of the words) but the ldr and ldrne will always be two cycles. Ahhh, the joys of modifying the fast path ;)



From swarren at wwwdotorg.org  Wed Jul 17 15:52:45 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Jul 2013 13:52:45 -0600
Subject: preempted dup_mm misses TLB invalidate
In-Reply-To: <20130717192746.GE16496@MacBook-Pro.local>
References: <51E43D2B.9090709@nvidia.com>
 <20130717192746.GE16496@MacBook-Pro.local>
Message-ID: <51E6F60D.6060804@wwwdotorg.org>

On 07/17/2013 01:27 PM, Catalin Marinas wrote:
> On Mon, Jul 15, 2013 at 07:19:23PM +0100, Nickolas Fortino wrote:
>> I?ve noticed an issue in simulation where the Linux kernel is executing 
>> a user process when the page tables and TLBs have gotten out of sync. 
>> The page tables have a page marked as user read only, but the TLB has 
>> the page marked as user read/write.
> 
> This happens during fork() for the current process. I think mprotect()
> as well. The caller is supposed not to have threads that write its
> memory while another thread does a fork().

Hmmm. That sounds like a plausible explanation, but I'm not convinced
it's true.

I would guess that the only way to prevent threads of an application
from writing to its memory while a fork() happens in another thread is
to prevent those threads from running at all; almost any code is going
to do some writes e.g. to the stack at least. That would imply the
kernel must prevent the scheduling of the other threads, not the
user-space application.

I quickly searched and couldn't see anything that agreed with your
statement about this being a user-space bug. There are plenty of
articles pointing out potential problems if a threaded app forks, but I
didn't see anything that said it's no legal. I also note that pthreads
explicitly specifies what happens if a threaded app forks (just the
thread calling fork is duplicated into the child process), what
functions can be called after a fork ("async-safe" functions), and the
function pthread_at_fork() exists, all of which tend to imply that
forking-and-threading can be legally used together.


From linux at arm.linux.org.uk  Wed Jul 17 16:01:38 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 21:01:38 +0100
Subject: preempted dup_mm misses TLB invalidate
In-Reply-To: <51E6F60D.6060804@wwwdotorg.org>
References: <51E43D2B.9090709@nvidia.com>
 <20130717192746.GE16496@MacBook-Pro.local> <51E6F60D.6060804@wwwdotorg.org>
Message-ID: <20130717200137.GT24642@n2100.arm.linux.org.uk>

On Wed, Jul 17, 2013 at 01:52:45PM -0600, Stephen Warren wrote:
> Hmmm. That sounds like a plausible explanation, but I'm not convinced
> it's true.
> 
> I would guess that the only way to prevent threads of an application
> from writing to its memory while a fork() happens in another thread is
> to prevent those threads from running at all; almost any code is going
> to do some writes e.g. to the stack at least. That would imply the
> kernel must prevent the scheduling of the other threads, not the
> user-space application.
> 
> I quickly searched and couldn't see anything that agreed with your
> statement about this being a user-space bug. There are plenty of
> articles pointing out potential problems if a threaded app forks, but I
> didn't see anything that said it's no legal. I also note that pthreads
> explicitly specifies what happens if a threaded app forks (just the
> thread calling fork is duplicated into the child process), what
> functions can be called after a fork ("async-safe" functions), and the
> function pthread_at_fork() exists, all of which tend to imply that
> forking-and-threading can be legally used together.

Yes, everything which you've said above is true, but if you read the
discussions on pthread_atfork(), you'll see that the whole notion that
you can somehow synchronize state for a fork() is a complete dead loss -
and pthread_atfork() is a pile of trash.

Semaphores must be released in the same thread as the thread which
acquired them.  If you take a semaphore in the pre-fork handler, and
release it in the parent post-fork handler, you can't legally release
it in the child post-fork handler because the child didn't acquire it!

What that means is that you can't be holding any semaphores when a
thread forks.  Remember that a thread ends up with a complete copy of
the VM space, semaphores and all in whatever state they were in _all_
the threads the moment when the fork happened.

Really, the only legal thing for a threaded process to do with fork()
is to immediately follow it with exec*() without doing anything else
with any pthread state (or any function which touches any pthread
state).  That much must work correctly - and if it doesn't, then we
definitely have a bug.

However, fork()ing a threaded app and trying to use pthread in the
child is not something I (or anyone) should really care about; it's
not a legal thing to do with all the requirements of the pthread APIs.


From b.brezillon at overkiz.com  Wed Jul 17 16:06:11 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 22:06:11 +0200
Subject: [PATCH v2 36/42] ARM: at91/dt: move sam9260/sam9g20 to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374091571-21935-1-git-send-email-b.brezillon@overkiz.com>

Define the main clock frequency in every sam9260/sam9g20 boards.
Remove the old main clock definition.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/animeo_ip.dts             |   17 ++++++-----------
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi |   17 ++++++-----------
 arch/arm/boot/dts/ge863-pro3.dtsi           |   16 ++++++----------
 arch/arm/boot/dts/kizbox.dts                |    5 +++++
 arch/arm/boot/dts/tny_a9260_common.dtsi     |   17 ++++++-----------
 arch/arm/boot/dts/usb_a9260_common.dtsi     |   17 ++++++-----------
 6 files changed, 35 insertions(+), 54 deletions(-)

diff --git a/arch/arm/boot/dts/animeo_ip.dts b/arch/arm/boot/dts/animeo_ip.dts
index 3a1de9e..1843f15 100644
--- a/arch/arm/boot/dts/animeo_ip.dts
+++ b/arch/arm/boot/dts/animeo_ip.dts
@@ -31,17 +31,6 @@
 		reg = <0x20000000 0x4000000>;
 	};
 
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <18432000>;
-		};
-	};
-
 	ahb {
 		apb {
 			usart0: serial at fffb0000 {
@@ -82,6 +71,12 @@
 			watchdog at fffffd40 {
 				status = "okay";
 			};
+
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <18432000>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
index 1373546..b8c823d 100644
--- a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
@@ -17,17 +17,6 @@
 		reg = <0x20000000 0x4000000>;
 	};
 
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <18432000>;
-		};
-	};
-
 	ahb {
 		apb {
 			pinctrl at fffff400 {
@@ -108,6 +97,12 @@
 			watchdog at fffffd40 {
 				status = "okay";
 			};
+
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <18432000>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/ge863-pro3.dtsi b/arch/arm/boot/dts/ge863-pro3.dtsi
index 230099b..b0b6aae 100644
--- a/arch/arm/boot/dts/ge863-pro3.dtsi
+++ b/arch/arm/boot/dts/ge863-pro3.dtsi
@@ -10,22 +10,18 @@
 #include "at91sam9260.dtsi"
 
 / {
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <6000000>;
-		};
-	};
 
 	ahb {
 		apb {
 			dbgu: serial at fffff200 {
 				status = "okay";
 			};
+
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <6000000>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/kizbox.dts b/arch/arm/boot/dts/kizbox.dts
index 02df191..091da2e 100644
--- a/arch/arm/boot/dts/kizbox.dts
+++ b/arch/arm/boot/dts/kizbox.dts
@@ -53,6 +53,11 @@
 				status = "okay";
 			};
 
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <18432000>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/tny_a9260_common.dtsi b/arch/arm/boot/dts/tny_a9260_common.dtsi
index 0e6d3de..1cecb7a 100644
--- a/arch/arm/boot/dts/tny_a9260_common.dtsi
+++ b/arch/arm/boot/dts/tny_a9260_common.dtsi
@@ -15,22 +15,17 @@
 		reg = <0x20000000 0x4000000>;
 	};
 
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <12000000>;
-		};
-	};
-
 	ahb {
 		apb {
 			dbgu: serial at fffff200 {
 				status = "okay";
 			};
+
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <12000000>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/usb_a9260_common.dtsi b/arch/arm/boot/dts/usb_a9260_common.dtsi
index 2859776..3ed4db8 100644
--- a/arch/arm/boot/dts/usb_a9260_common.dtsi
+++ b/arch/arm/boot/dts/usb_a9260_common.dtsi
@@ -7,17 +7,6 @@
  */
 
 / {
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <12000000>;
-		};
-	};
-
 	ahb {
 		apb {
 			dbgu: serial at fffff200 {
@@ -33,6 +22,12 @@
 				atmel,vbus-gpio = <&pioC 5 GPIO_ACTIVE_HIGH>;
 				status = "okay";
 			};
+
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <12000000>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 16:08:25 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 22:08:25 +0200
Subject: [PATCH v2 37/42] ARM: at91/dt: move rm9200 boards to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374091705-21985-1-git-send-email-b.brezillon@overkiz.com>

Define the main clock frequency in every at91rm9200 boards.
Remove the old main clock definition.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/at91rm9200ek.dts |   17 ++++++-----------
 arch/arm/boot/dts/mpa1600.dts      |   16 +++++-----------
 2 files changed, 11 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
index d2d72c3..e2960b4 100644
--- a/arch/arm/boot/dts/at91rm9200ek.dts
+++ b/arch/arm/boot/dts/at91rm9200ek.dts
@@ -16,19 +16,14 @@
 		reg = <0x20000000 0x4000000>;
 	};
 
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <18432000>;
-		};
-	};
-
 	ahb {
 		apb {
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <18432000>;
+				};
+			};
+
 			dbgu: serial at fffff200 {
 				status = "okay";
 			};
diff --git a/arch/arm/boot/dts/mpa1600.dts b/arch/arm/boot/dts/mpa1600.dts
index ccf9ea2..317ee5a 100644
--- a/arch/arm/boot/dts/mpa1600.dts
+++ b/arch/arm/boot/dts/mpa1600.dts
@@ -16,17 +16,6 @@
 		reg = <0x20000000 0x4000000>;
 	};
 
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <18432000>;
-		};
-	};
-
 	ahb {
 		apb {
 			dbgu: serial at fffff200 {
@@ -45,6 +34,11 @@
 			ssc1: ssc at fffd4000 {
 				status = "okay";
 			};
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <18432000>;
+				};
+			};
 		};
 
 		usb0: ohci at 00300000 {
-- 
1.7.9.5



From gerlando.falauto at keymile.com  Wed Jul 17 16:09:07 2013
From: gerlando.falauto at keymile.com (Gerlando Falauto)
Date: Wed, 17 Jul 2013 22:09:07 +0200
Subject: SPARSE_IRQ on Kirkwood
Message-ID: <51E6F9E3.9030302@keymile.com>

Hi everyone,

newbie's question: are sparse IRQs [going to be] supported on Kirkwood?
I thought irq domains were pretty much the same thing...
So if I understand correctly, without sparse IRQs I still have to 
increase NR_IRQS within arch/arm/mach-kirkwood/include/mach/irqs.h in 
order to support additional PICs.

Thanks in advance!
Gerlando


From nfortino at nvidia.com  Wed Jul 17 16:09:52 2013
From: nfortino at nvidia.com (Nickolas Fortino)
Date: Wed, 17 Jul 2013 13:09:52 -0700
Subject: preempted dup_mm misses TLB invalidate
In-Reply-To: <51E6F60D.6060804@wwwdotorg.org>
References: <51E43D2B.9090709@nvidia.com>
 <20130717192746.GE16496@MacBook-Pro.local> <51E6F60D.6060804@wwwdotorg.org>
Message-ID: <51E6FA10.5070504@nvidia.com>

On 7/17/2013 12:52 PM, Stephen Warren wrote:
> On 07/17/2013 01:27 PM, Catalin Marinas wrote:
>> On Mon, Jul 15, 2013 at 07:19:23PM +0100, Nickolas Fortino wrote:
>>> The page tables have a page marked as user read only, but the TLB has
>>> the page marked as user read/write.
>>
>> This happens during fork() for the current process. I think mprotect()
>> as well. The caller is supposed not to have threads that write its
>> memory while another thread does a fork().

To be clear, the complaint is not that the page tables are ephemerally 
out of sync with the TLBs. I agree that is part of the expected 
operation of fork(), and if a TLB invalidate occurs prior to any memory 
access the code is valid.

The problem is eventually a user process performs a store which hits on 
a writeable TLB entry with the PTE marked as read only. Is it supposed 
to be possible for a user threading bug to end up in this state? I would 
have expected the kernel to be responsible for assuring no stores occur 
to a page it has marked as read only.

As for whether the application is threaded, it almost certainly is - 
it's cfbench equivalent to 
https://play.google.com/store/apps/details?id=eu.chainfire.cfbench&hl=en




From b.brezillon at overkiz.com  Wed Jul 17 16:09:51 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 22:09:51 +0200
Subject: [PATCH v2 38/42] ARM: at91/dt: move sam9263 boards to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374091791-22043-1-git-send-email-b.brezillon@overkiz.com>

Define the main clock frequency in every at91sam9263 boards.
Remove the old main clock definition.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/at91sam9263ek.dts |   17 ++++++-----------
 arch/arm/boot/dts/tny_a9263.dts     |   17 ++++++-----------
 arch/arm/boot/dts/usb_a9263.dts     |   17 ++++++-----------
 3 files changed, 18 insertions(+), 33 deletions(-)

diff --git a/arch/arm/boot/dts/at91sam9263ek.dts b/arch/arm/boot/dts/at91sam9263ek.dts
index 70f835b..b3aa143 100644
--- a/arch/arm/boot/dts/at91sam9263ek.dts
+++ b/arch/arm/boot/dts/at91sam9263ek.dts
@@ -20,17 +20,6 @@
 		reg = <0x20000000 0x4000000>;
 	};
 
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <16367660>;
-		};
-	};
-
 	ahb {
 		apb {
 			dbgu: serial at ffffee00 {
@@ -93,6 +82,12 @@
 			watchdog at fffffd40 {
 				status = "okay";
 			};
+
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <16367660>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/tny_a9263.dts b/arch/arm/boot/dts/tny_a9263.dts
index 0751a6a..067eefb 100644
--- a/arch/arm/boot/dts/tny_a9263.dts
+++ b/arch/arm/boot/dts/tny_a9263.dts
@@ -20,17 +20,6 @@
 		reg = <0x20000000 0x4000000>;
 	};
 
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <12000000>;
-		};
-	};
-
 	ahb {
 		apb {
 			dbgu: serial at ffffee00 {
@@ -41,6 +30,12 @@
 				atmel,vbus-gpio = <&pioB 11 GPIO_ACTIVE_HIGH>;
 				status = "okay";
 			};
+
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <12000000>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/usb_a9263.dts b/arch/arm/boot/dts/usb_a9263.dts
index 290e603..ae5b92d 100644
--- a/arch/arm/boot/dts/usb_a9263.dts
+++ b/arch/arm/boot/dts/usb_a9263.dts
@@ -20,17 +20,6 @@
 		reg = <0x20000000 0x4000000>;
 	};
 
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <12000000>;
-		};
-	};
-
 	ahb {
 		apb {
 			dbgu: serial at ffffee00 {
@@ -61,6 +50,12 @@
 				atmel,wakeup-counter = <10>;
 				atmel,wakeup-rtt-timer;
 			};
+
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <12000000>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
-- 
1.7.9.5



From swarren at wwwdotorg.org  Wed Jul 17 16:11:18 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Jul 2013 14:11:18 -0600
Subject: preempted dup_mm misses TLB invalidate
In-Reply-To: <20130717200137.GT24642@n2100.arm.linux.org.uk>
References: <51E43D2B.9090709@nvidia.com>
 <20130717192746.GE16496@MacBook-Pro.local> <51E6F60D.6060804@wwwdotorg.org>
 <20130717200137.GT24642@n2100.arm.linux.org.uk>
Message-ID: <51E6FA66.7060001@wwwdotorg.org>

On 07/17/2013 02:01 PM, Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 01:52:45PM -0600, Stephen Warren wrote:
>> Hmmm. That sounds like a plausible explanation, but I'm not convinced
>> it's true.
>>
>> I would guess that the only way to prevent threads of an application
>> from writing to its memory while a fork() happens in another thread is
>> to prevent those threads from running at all; almost any code is going
>> to do some writes e.g. to the stack at least. That would imply the
>> kernel must prevent the scheduling of the other threads, not the
>> user-space application.
>>
>> I quickly searched and couldn't see anything that agreed with your
>> statement about this being a user-space bug. There are plenty of
>> articles pointing out potential problems if a threaded app forks, but I
>> didn't see anything that said it's no legal. I also note that pthreads
>> explicitly specifies what happens if a threaded app forks (just the
>> thread calling fork is duplicated into the child process), what
>> functions can be called after a fork ("async-safe" functions), and the
>> function pthread_at_fork() exists, all of which tend to imply that
>> forking-and-threading can be legally used together.
> 
> Yes, everything which you've said above is true, but if you read the
> discussions on pthread_atfork(), you'll see that the whole notion that
> you can somehow synchronize state for a fork() is a complete dead loss -
> and pthread_atfork() is a pile of trash.
> 
> Semaphores must be released in the same thread as the thread which
> acquired them.  If you take a semaphore in the pre-fork handler, and
> release it in the parent post-fork handler, you can't legally release
> it in the child post-fork handler because the child didn't acquire it!
> 
> What that means is that you can't be holding any semaphores when a
> thread forks.  Remember that a thread ends up with a complete copy of
> the VM space, semaphores and all in whatever state they were in _all_
> the threads the moment when the fork happened.
> 
> Really, the only legal thing for a threaded process to do with fork()
> is to immediately follow it with exec*() without doing anything else
> with any pthread state (or any function which touches any pthread
> state).  That much must work correctly - and if it doesn't, then we
> definitely have a bug.

Yes, there are definitely issues mixing threads and forking.

But I think the issue that Nickolas reported can be reproduced by a
threaded application doing nothing but fork() followed by an exec() in
the child, assuming that another thread in the parent process touches
memory (e.g. stack) between the "fork()" and exec() in the child, which
seems pretty likely unless the kernel itself prevents it.


From b.brezillon at overkiz.com  Wed Jul 17 16:17:25 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 22:17:25 +0200
Subject: [PATCH v2 39/42] ARM: at91/dt: move sam9g45 boards to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374092245-22121-1-git-send-email-b.brezillon@overkiz.com>

Define the main clock frequency in every at91sam9g45 boards.
Remove the old main clock definition.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/at91sam9m10g45ek.dts |   17 ++++++-----------
 arch/arm/boot/dts/pm9g45.dts           |   16 +++++-----------
 2 files changed, 11 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index a4b00e5..f83bda2 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -21,17 +21,6 @@
 		reg = <0x70000000 0x4000000>;
 	};
 
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <12000000>;
-		};
-	};
-
 	ahb {
 		apb {
 			dbgu: serial at ffffee00 {
@@ -121,6 +110,12 @@
 				atmel,vbus-gpio = <&pioB 19 GPIO_ACTIVE_HIGH>;
 				status = "okay";
 			};
+
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <12000000>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/pm9g45.dts b/arch/arm/boot/dts/pm9g45.dts
index 33ffabe..3d8af99 100644
--- a/arch/arm/boot/dts/pm9g45.dts
+++ b/arch/arm/boot/dts/pm9g45.dts
@@ -20,17 +20,6 @@
 		reg = <0x70000000 0x8000000>;
 	};
 
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <12000000>;
-		};
-	};
-
 	ahb {
 		apb {
 			dbgu: serial at ffffee00 {
@@ -73,6 +62,11 @@
 				status = "okay";
 			};
 
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <12000000>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 16:19:54 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 22:19:54 +0200
Subject: [PATCH v2 40/42] ARM: at91/dt: move sam9n12 boards to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374092394-22173-1-git-send-email-b.brezillon@overkiz.com>

Define the main clock frequency in every at91sam9n12 boards.
Remove the old main clock definition.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/at91sam9n12ek.dts |   17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts b/arch/arm/boot/dts/at91sam9n12ek.dts
index d59b70c..35f484a 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -21,17 +21,6 @@
 		reg = <0x20000000 0x10000000>;
 	};
 
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <16000000>;
-		};
-	};
-
 	ahb {
 		apb {
 			dbgu: serial at fffff200 {
@@ -81,6 +70,12 @@
 			watchdog at fffffe40 {
 				status = "okay";
 			};
+
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <16000000>;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
-- 
1.7.9.5



From b.brezillon at overkiz.com  Wed Jul 17 16:21:07 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 22:21:07 +0200
Subject: [PATCH v2 41/42] ARM: at91/dt: move sam9x5 boards to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374092467-22217-1-git-send-email-b.brezillon@overkiz.com>

Define the main clock frequency in every at91sam9x5 boards.
Remove the old main clock definition.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/at91-ariag25.dts |   17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/at91-ariag25.dts b/arch/arm/boot/dts/at91-ariag25.dts
index cce45f5..f574682 100644
--- a/arch/arm/boot/dts/at91-ariag25.dts
+++ b/arch/arm/boot/dts/at91-ariag25.dts
@@ -33,17 +33,6 @@
 		reg = <0x20000000 0x8000000>;
 	};
 
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <12000000>;
-		};
-	};
-
 	ahb {
 		apb {
 			mmc0: mmc at f0008000 {
@@ -147,6 +136,12 @@
 			rtc at fffffeb0 {
 				status = "okay";
 			};
+
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <12000000>;
+				};
+			};
 		};
 
 		usb0: ohci at 00600000 {
-- 
1.7.9.5



From magnus.damm at gmail.com  Wed Jul 17 16:30:49 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 18 Jul 2013 05:30:49 +0900
Subject: [PATCH v2 00/04] ARM: shmobile: ARCH_MULTIPLATFORM for EMEV2 and KZM9D
Message-ID: <20130717203049.27542.78385.sendpatchset@w520>

ARM: shmobile: ARCH_MULTIPLATFORM for EMEV2 and KZM9D (v2)

[PATCH v2 01/04] ARM: shmobile: Only build clocks when COMMON_CLK=n
[PATCH 02/04] ARM: shmobile: Introduce ARCH_SHMOBILE_MULTI
[PATCH v2 03/04] ARM: shmobile: Add EMEV2 and KZM9D to ARCH_SHMOBILE_MULTI
[PATCH 04/04] ARM: shmobile: Allow ARCH_SHMOBILE_MULTI timer configuration

This patch set extends mach-shmobile to allow a subset of SoCs and
boards to be built for ARCH_MULTIPLATFORM. With this v2 series applied
the EMEV2 SoC and the KZM9D board can be built in two ways - either
as good old ARCH_SHMOBILE or new ARCH_SHMOBILE_MULTI. The latter
requires common clock framework for proper run time operation.

The goal is to over time move all DT reference implementations from
ARCH_SHMOBILE to ARCH_SHMOBILE_MULTI. Until CCF is available for a
certain SoC it is to me acceptable for a DT reference board to allow
build in both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI. The reason for
this is to allow incremental development and easy testing during
development of CCF for a certain SoC. The KZM9D board is now in this
state while it is waiting for common clocks to become ready.

Until CCF is supported for EMEV2 the KZM9D board can be tested with
ARCH_SMOBILE_MULTI without clocks using the following prototype:
[PATCH] ARM: shmobile: MULTIPLATFORM KZM9D with no clocks prototype hack

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Built on top of renesas-devel-20130717

 arch/arm/Makefile                              |    1 
 arch/arm/boot/dts/Makefile                     |    1 
 arch/arm/mach-shmobile/Kconfig                 |   52 +++++++++++++++++++++---
 arch/arm/mach-shmobile/Makefile                |   33 +++++++++++----
 arch/arm/mach-shmobile/board-kzm9d-reference.c |    3 -
 arch/arm/mach-shmobile/setup-emev2.c           |    3 -
 6 files changed, 77 insertions(+), 16 deletions(-)


From magnus.damm at gmail.com  Wed Jul 17 16:30:59 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 18 Jul 2013 05:30:59 +0900
Subject: [PATCH v2 01/04] ARM: shmobile: Only build clocks when COMMON_CLK=n
In-Reply-To: <20130717203049.27542.78385.sendpatchset@w520>
References: <20130717203049.27542.78385.sendpatchset@w520>
Message-ID: <20130717203059.27542.57468.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Move shared clock.c file and per-SoC clock-xxx.c files
to only build when CONFIG_COMMON_CLK != y.

The regular ARCH_SHMOBILE case with legacy SH clock framework
will build just as before with this patch applied, however
the case when COMMON_CLK=y will exclude all the clock files.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Changes since V1:
 - wrap clock objects in ifndef, thanks Arnd and Laurent!

 arch/arm/mach-shmobile/Makefile |   31 ++++++++++++++++++++++---------
 1 file changed, 22 insertions(+), 9 deletions(-)

--- 0001/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-07-18 05:05:41.000000000 +0900
@@ -3,17 +3,30 @@
 #
 
 # Common objects
-obj-y				:= timer.o console.o clock.o
+obj-y				:= timer.o console.o
 
 # CPU objects
-obj-$(CONFIG_ARCH_SH7372)	+= setup-sh7372.o clock-sh7372.o intc-sh7372.o
-obj-$(CONFIG_ARCH_SH73A0)	+= setup-sh73a0.o clock-sh73a0.o intc-sh73a0.o
-obj-$(CONFIG_ARCH_R8A73A4)	+= setup-r8a73a4.o clock-r8a73a4.o
-obj-$(CONFIG_ARCH_R8A7740)	+= setup-r8a7740.o clock-r8a7740.o intc-r8a7740.o
-obj-$(CONFIG_ARCH_R8A7778)	+= setup-r8a7778.o clock-r8a7778.o
-obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o clock-r8a7779.o intc-r8a7779.o
-obj-$(CONFIG_ARCH_R8A7790)	+= setup-r8a7790.o clock-r8a7790.o
-obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o clock-emev2.o
+obj-$(CONFIG_ARCH_SH7372)	+= setup-sh7372.o intc-sh7372.o
+obj-$(CONFIG_ARCH_SH73A0)	+= setup-sh73a0.o intc-sh73a0.o
+obj-$(CONFIG_ARCH_R8A73A4)	+= setup-r8a73a4.o
+obj-$(CONFIG_ARCH_R8A7740)	+= setup-r8a7740.o intc-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7778)	+= setup-r8a7778.o
+obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o intc-r8a7779.o
+obj-$(CONFIG_ARCH_R8A7790)	+= setup-r8a7790.o
+obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o
+
+# Clock objects
+ifndef CONFIG_COMMON_CLK
+obj-y				+= clock.o
+obj-$(CONFIG_ARCH_SH7372)	+= clock-sh7372.o
+obj-$(CONFIG_ARCH_SH73A0)	+= clock-sh73a0.o
+obj-$(CONFIG_ARCH_R8A73A4)	+= clock-r8a73a4.o
+obj-$(CONFIG_ARCH_R8A7740)	+= clock-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7778)	+= clock-r8a7778.o
+obj-$(CONFIG_ARCH_R8A7779)	+= clock-r8a7779.o
+obj-$(CONFIG_ARCH_R8A7790)	+= clock-r8a7790.o
+obj-$(CONFIG_ARCH_EMEV2)	+= clock-emev2.o
+endif
 
 # SMP objects
 smp-y				:= platsmp.o headsmp.o


From magnus.damm at gmail.com  Wed Jul 17 16:31:09 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 18 Jul 2013 05:31:09 +0900
Subject: [PATCH 02/04] ARM: shmobile: Introduce ARCH_SHMOBILE_MULTI
In-Reply-To: <20130717203049.27542.78385.sendpatchset@w520>
References: <20130717203049.27542.78385.sendpatchset@w520>
Message-ID: <20130717203109.27542.77708.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Add ARCH_SHMOBILE_MULTI to mach-shmobile that can be used
to enable ARCH_MULTIPLATFORM on selected SoCs and boards.

The headers stay under arch/arm/mach-shmobile/include/mach/
for now, they can and will be migrated independently over time.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/Makefile               |    1 +
 arch/arm/mach-shmobile/Kconfig  |   21 +++++++++++++++++++++
 arch/arm/mach-shmobile/Makefile |    2 ++
 3 files changed, 24 insertions(+)

--- 0001/arch/arm/Makefile
+++ work/arch/arm/Makefile	2013-07-08 19:17:00.000000000 +0900
@@ -181,6 +181,7 @@ machine-$(CONFIG_ARCH_EXYNOS)		+= exynos
 machine-$(CONFIG_ARCH_SA1100)		+= sa1100
 machine-$(CONFIG_ARCH_SHARK)		+= shark
 machine-$(CONFIG_ARCH_SHMOBILE) 	+= shmobile
+machine-$(CONFIG_ARCH_SHMOBILE_MULTI) 	+= shmobile
 machine-$(CONFIG_ARCH_TEGRA)		+= tegra
 machine-$(CONFIG_ARCH_U300)		+= u300
 machine-$(CONFIG_ARCH_U8500)		+= ux500
--- 0002/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-07-08 19:19:21.000000000 +0900
@@ -1,3 +1,24 @@
+config ARCH_SHMOBILE_MULTI
+	bool "SH-Mobile Series" if ARCH_MULTI_V7
+	depends on MMU
+	select CPU_V7
+	select GENERIC_CLOCKEVENTS
+	select HAVE_ARM_SCU if SMP
+	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_SMP
+	select ARM_GIC
+	select MIGHT_HAVE_CACHE_L2X0
+	select NO_IOPORT
+	select PINCTRL
+	select ARCH_REQUIRE_GPIOLIB
+	select CLKDEV_LOOKUP
+
+if ARCH_SHMOBILE_MULTI
+
+comment "SH-Mobile System Type"
+
+endif
+
 if ARCH_SHMOBILE
 
 comment "SH-Mobile System Type"
--- 0003/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-07-08 19:18:20.000000000 +0900
@@ -2,6 +2,8 @@
 # Makefile for the linux kernel.
 #
 
+ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/arch/arm/mach-shmobile/include
+
 # Common objects
 obj-y				:= timer.o console.o
 


From swarren at wwwdotorg.org  Wed Jul 17 16:31:07 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Jul 2013 14:31:07 -0600
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <51E6FF0B.5000708@wwwdotorg.org>

On 07/17/2013 04:15 AM, Joseph Lo wrote:
> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
>>>>> this state.
... [ discussion of issues with Joesph's patches applied]
>
> OK. I did more stress tests last night and today. I found it cause by
> the patch "ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag" and
> only impact the Tegra20 platform. The hot plug regression seems due to
> this patch. After dropping this patch on top of v3.11-rc1, the Tegra20
> can back to normal.
> 
> And the hop plug and suspend stress test can pass on Tegra30/114 too.
> 
> Can the other two patch series for Tegra114 to support CPU idle power
> down mode and system suspend still moving forward, not be blocked by
> this patch?
> 
> Looks the CPUIDLE_FLAG_TIMER_STOP flag still cause some other issue for
> hot plug on Tegra20, I will continue to check this. You can just drop
> this patch.

OK, if I drop that patch, then everything on Tegra20 and Tegra30 seems
fine again.

However, I've found some new and exciting issue on Tegra114!

With unmodified v3.11-rc1, I can do the following without issue:

* Unplug/replug CPUs, so that I had all combinations of CPU 1, 2, 3
plugged/unpplugged (with CPU 0 always plugged).

* Unplug/replug CPUs, so that I had all combinations of CPU 0, 1, 2, 3
plugged/unpplugged (with the obvious exception of never having all CPUs
unplugged).

However, if I try this with your Tegra114 cpuidle and suspend patches
applied, I see the following issues:

1) If I boot, unplug CPU 0, then replug CPU 0, the system immediately
hard-hangs.

2) If I run the hotplug test script, leaving CPU 0 always present, I
sometimes see:

> root at localhost:~# for i in `seq 1 50`; do echo ITERATION $i; ./cpuonline.py; done
> ITERATION 1
> echo 0 > /sys/devices/system/cpu/cpu2/online
> [  458.910054] CPU2: shutdown
> echo 0 > /sys/devices/system/cpu/cpu1/online
> [  461.004371] CPU1: shutdown
> echo 0 > /sys/devices/system/cpu/cpu3/online
> [  463.027341] CPU3: shutdown
> echo 1 > /sys/devices/system/cpu/cpu1/online
> [  465.061412] CPU1: Booted secondary processor
> echo 1 > /sys/devices/system/cpu/cpu2/online
> [  467.095313] CPU2: Booted secondary processor
> [  467.113243] ------------[ cut here ]------------
> [  467.117948] WARNING: CPU: 2 PID: 0 at kernel/time/tick-broadcast.c:667 tick_broadcast_oneshot_control+0x19c/0x1c4()
> [  467.128352] Modules linked in:
> [  467.131455] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.11.0-rc1-00022-g7487363-dirty #49
> [  467.139678] [<c0015620>] (unwind_backtrace+0x0/0xf8) from [<c001154c>] (show_stack+0x10/0x14)
> [  467.148228] [<c001154c>] (show_stack+0x10/0x14) from [<c05135a8>] (dump_stack+0x80/0xc4)
> [  467.156336] [<c05135a8>] (dump_stack+0x80/0xc4) from [<c0024590>] (warn_slowpath_common+0x64/0x88)
> [  467.165300] [<c0024590>] (warn_slowpath_common+0x64/0x88) from [<c00245d0>] (warn_slowpath_null+0x1c/0x24)
> [  467.174959] [<c00245d0>] (warn_slowpath_null+0x1c/0x24) from [<c00695e4>] (tick_broadcast_oneshot_control+0x19c/0x1c4)
> [  467.185659] [<c00695e4>] (tick_broadcast_oneshot_control+0x19c/0x1c4) from [<c0067cdc>] (clockevents_notify+0x1b0/0x1dc)
> [  467.196538] [<c0067cdc>] (clockevents_notify+0x1b0/0x1dc) from [<c034f348>] (cpuidle_idle_call+0x11c/0x168)
> [  467.206292] [<c034f348>] (cpuidle_idle_call+0x11c/0x168) from [<c000f134>] (arch_cpu_idle+0x8/0x38)
> [  467.215359] [<c000f134>] (arch_cpu_idle+0x8/0x38) from [<c0061038>] (cpu_startup_entry+0x60/0x134)
> [  467.224325] [<c0061038>] (cpu_startup_entry+0x60/0x134) from [<800083d8>] (0x800083d8)
> [  467.232227] ---[ end trace ea579be22a00e7fb ]---
> echo 0 > /sys/devices/system/cpu/cpu1/online
> [  469.126682] CPU1: shutdown

I have found no solution for (1) (although I didn't look hard!).

(2) can be solved with the following (at least 50 iterations of my test
script worked with this patch applied):

> diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
> index 658b205..896408d 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra114.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
> @@ -66,8 +66,7 @@ static struct cpuidle_driver tegra_idle_driver = {
>                         .exit_latency           = 500,
>                         .target_residency       = 1000,
>                         .power_usage            = 0,
> -                       .flags                  = CPUIDLE_FLAG_TIME_VALID |
> -                                                 CPUIDLE_FLAG_TIMER_STOP,
> +                       .flags                  = CPUIDLE_FLAG_TIME_VALID,
>                         .name                   = "powered-down",
>                         .desc                   = "CPU power gated",
>                 },

Here's my test script for reference:

#!/usr/bin/env python

import multiprocessing
import os
import sys
import time

cpus = multiprocessing.cpu_count()
if cpus == 4:
  socf = file('/sys/devices/soc0/soc_id')
  soc = socf.readline().strip()
  socf.close()
  if True: #soc == '48':
    gc = (11, 9, 1, 3, 7, 5, 13, 15)
  else:
    gc = (14, 10, 11, 9, 8, 1, 3, 2, 6, 7, 5, 4, 12, 13, 15)
elif cpus == 2:
  gc = (1, 3)
else:
  raise Exception("Invalid CPU count %d" % cpus)

oldidx = len(gc) - 1
oldmask = gc[oldidx]

for newidx in range(len(gc)):
  newmask = gc[newidx]
  for cpu in range(cpus):
    oldon = oldmask & (1 << cpu)
    newon = newmask & (1 << cpu)
    if oldon != newon:
      if newon:
        newonval = 1
      else:
        newonval = 0
      cmd = "echo %d > /sys/devices/system/cpu/cpu%d/online" \
% (newonval, cpu)
      print cmd
      os.system(cmd)
  time.sleep(2)
  oldidx = newidx
  oldmask = newmask



From magnus.damm at gmail.com  Wed Jul 17 16:31:18 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 18 Jul 2013 05:31:18 +0900
Subject: [PATCH v2 03/04] ARM: shmobile: Add EMEV2 and KZM9D to
 ARCH_SHMOBILE_MULTI
In-Reply-To: <20130717203049.27542.78385.sendpatchset@w520>
References: <20130717203049.27542.78385.sendpatchset@w520>
Message-ID: <20130717203118.27542.37940.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Enable build of EMEV2 and KZM9D DT Reference in
case of ARCH_MULTIPLATFORM and ARCH_SHMOBILE_MULTI.

IS_ENABLED() is leaves the clock-emev2.c file out
in case of COMMON_CLK=y.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Changes since V1:
 - use IS_ENABLED() instead of weak symbol, thanks Arnd!

 arch/arm/boot/dts/Makefile                     |    1 +
 arch/arm/mach-shmobile/Kconfig                 |   15 +++++++++++++++
 arch/arm/mach-shmobile/board-kzm9d-reference.c |    3 ++-
 arch/arm/mach-shmobile/setup-emev2.c           |    3 ++-
 4 files changed, 20 insertions(+), 2 deletions(-)

--- 0001/arch/arm/boot/dts/Makefile
+++ work/arch/arm/boot/dts/Makefile	2013-07-18 05:06:46.000000000 +0900
@@ -195,6 +195,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm
 	r8a73a4-ape6evm.dtb \
 	r8a73a4-ape6evm-reference.dtb \
 	sh7372-mackerel.dtb
+dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += emev2-kzm9d-reference.dtb
 dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_cyclone5.dtb \
 	socfpga_vt.dtb
 dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb \
--- 0003/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-07-18 05:06:46.000000000 +0900
@@ -17,6 +17,21 @@ if ARCH_SHMOBILE_MULTI
 
 comment "SH-Mobile System Type"
 
+config ARCH_EMEV2
+	bool "Emma Mobile EV2"
+
+comment "SH-Mobile Board Type"
+
+config MACH_KZM9D_REFERENCE
+	bool "KZM9D board - Reference Device Tree Implementation"
+	depends on ARCH_EMEV2
+	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	---help---
+	   Use reference implementation of KZM9D board support
+	   which makes a greater use of device tree at the expense
+	   of not supporting a number of devices.
+
+	   This is intended to aid developers
 endif
 
 if ARCH_SHMOBILE
--- 0001/arch/arm/mach-shmobile/board-kzm9d-reference.c
+++ work/arch/arm/mach-shmobile/board-kzm9d-reference.c	2013-07-18 05:12:08.000000000 +0900
@@ -26,7 +26,8 @@
 
 static void __init kzm9d_add_standard_devices(void)
 {
-	emev2_clock_init();
+	if (!IS_ENABLED(CONFIG_COMMON_CLK))
+		emev2_clock_init();
 
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
--- 0001/arch/arm/mach-shmobile/setup-emev2.c
+++ work/arch/arm/mach-shmobile/setup-emev2.c	2013-07-18 05:12:17.000000000 +0900
@@ -175,7 +175,8 @@ static struct resource pmu_resources[] =
 
 void __init emev2_add_standard_devices(void)
 {
-	emev2_clock_init();
+	if (!IS_ENABLED(CONFIG_COMMON_CLK))
+		emev2_clock_init();
 
 	emev2_register_uart(0);
 	emev2_register_uart(1);


From magnus.damm at gmail.com  Wed Jul 17 16:31:27 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 18 Jul 2013 05:31:27 +0900
Subject: [PATCH 04/04] ARM: shmobile: Allow ARCH_SHMOBILE_MULTI timer
 configuration
In-Reply-To: <20130717203049.27542.78385.sendpatchset@w520>
References: <20130717203049.27542.78385.sendpatchset@w520>
Message-ID: <20130717203127.27542.41663.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Move the timer configuration bits to allow use in
case of ARCH_SHMOBILE or ARCH_SHMOBILE_MULTI.

The timers all make use of the regular driver model
so they are safe to enable for ARCH_MULTIPLATFORM.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/Kconfig |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

--- 0005/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-07-09 12:07:23.000000000 +0900
@@ -30,6 +30,8 @@ config MACH_KZM9D_REFERENCE
 	   of not supporting a number of devices.
 
 	   This is intended to aid developers
+
+comment "SH-Mobile System Configuration"
 endif
 
 if ARCH_SHMOBILE
@@ -243,6 +245,15 @@ config CPU_HAS_INTEVT
         bool
 	default y
 
+config SH_CLK_CPG
+	bool
+
+source "drivers/sh/Kconfig"
+
+endif
+
+if ARCH_SHMOBILE || ARCH_SHMOBILE_MULTI
+
 menu "Timer and clock configuration"
 
 config SHMOBILE_TIMER_HZ
@@ -277,9 +288,4 @@ config EM_TIMER_STI
 
 endmenu
 
-config SH_CLK_CPG
-	bool
-
-source "drivers/sh/Kconfig"
-
 endif


From b.brezillon at overkiz.com  Wed Jul 17 16:32:35 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Wed, 17 Jul 2013 22:32:35 +0200
Subject: [PATCH v2 24/42] ARM: at91: move at91sam9 boards to new at91
 clk implem
In-Reply-To: <20130717171343.GS24642@n2100.arm.linux.org.uk>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <1374075433-20170-1-git-send-email-b.brezillon@overkiz.com>
 <20130717171343.GS24642@n2100.arm.linux.org.uk>
Message-ID: <51E6FF63.6050805@overkiz.com>

On 17/07/2013 19:13, Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 05:37:13PM +0200, Boris BREZILLON wrote:
>> Move at91 clk init from early_init to timer_init for all at91sam9 non dt
>> boards.
> Using black ball point pen, please complete the following sentence using
> as many words as you desire.  Additional underscores are available on
> request.
>
> The reason for this change is ______________________________________.
>
> Thanks. :)
Indeed, this commit message is a bit useless as it only describe what is 
done not why...

The reason for this is that dynamic allocator is not ready yet when 
early_init callback is called,
and new at91 clk implementation calls kzalloc functions.
It is moved in timer_init (before timer init) because at91sam9 init 
timer (pit timer) request the
mck clk which is registered by at91 clk init function.

I'll change this commit message in the next version.


From b.brezillon at overkiz.com  Wed Jul 17 16:32:51 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Wed, 17 Jul 2013 22:32:51 +0200
Subject: [PATCH v2 42/42] ARM: at91/dt: move sama5d3 boards to new at91 clk
 implem
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374093171-22330-1-git-send-email-b.brezillon@overkiz.com>

Define the main clock frequency in every sama5d3 boards.
Remove the old main clock definition.
Include the appropriate peripheral options according to peripherals
availability.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 arch/arm/boot/dts/sama5d31ek.dts  |    4 ++++
 arch/arm/boot/dts/sama5d33ek.dts  |    2 ++
 arch/arm/boot/dts/sama5d34ek.dts  |    4 ++++
 arch/arm/boot/dts/sama5d35ek.dts  |    6 ++++++
 arch/arm/boot/dts/sama5d3xcm.dtsi |   17 ++++++-----------
 5 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d31ek.dts b/arch/arm/boot/dts/sama5d31ek.dts
index 027bac7..4628533 100644
--- a/arch/arm/boot/dts/sama5d31ek.dts
+++ b/arch/arm/boot/dts/sama5d31ek.dts
@@ -9,6 +9,10 @@
 /dts-v1/;
 #include "sama5d3xmb.dtsi"
 #include "sama5d3xdm.dtsi"
+#include "sama5d3_lcd.dtsi"
+#include "sama5d3_emac.dtsi"
+#include "sama5d3_mci2.dtsi"
+#include "sama5d3_uart.dtsi"
 
 / {
 	model = "Atmel SAMA5D31-EK";
diff --git a/arch/arm/boot/dts/sama5d33ek.dts b/arch/arm/boot/dts/sama5d33ek.dts
index 99bd0c8..5aa32f5 100644
--- a/arch/arm/boot/dts/sama5d33ek.dts
+++ b/arch/arm/boot/dts/sama5d33ek.dts
@@ -9,6 +9,8 @@
 /dts-v1/;
 #include "sama5d3xmb.dtsi"
 #include "sama5d3xdm.dtsi"
+#include "sama5d3_lcd.dtsi"
+#include "sama5d3_gmac.dtsi"
 
 / {
 	model = "Atmel SAMA5D33-EK";
diff --git a/arch/arm/boot/dts/sama5d34ek.dts b/arch/arm/boot/dts/sama5d34ek.dts
index fb8ee11..272a611 100644
--- a/arch/arm/boot/dts/sama5d34ek.dts
+++ b/arch/arm/boot/dts/sama5d34ek.dts
@@ -9,6 +9,10 @@
 /dts-v1/;
 #include "sama5d3xmb.dtsi"
 #include "sama5d3xdm.dtsi"
+#include "sama5d3_lcd.dtsi"
+#include "sama5d3_gmac.dtsi"
+#include "sama5d3_can.dtsi"
+#include "sama5d3_mci2.dtsi"
 
 / {
 	model = "Atmel SAMA5D34-EK";
diff --git a/arch/arm/boot/dts/sama5d35ek.dts b/arch/arm/boot/dts/sama5d35ek.dts
index 509a53d..155bb9d 100644
--- a/arch/arm/boot/dts/sama5d35ek.dts
+++ b/arch/arm/boot/dts/sama5d35ek.dts
@@ -8,6 +8,12 @@
  */
 /dts-v1/;
 #include "sama5d3xmb.dtsi"
+#include "sama5d3_gmac.dtsi"
+#include "sama5d3_emac.dtsi"
+#include "sama5d3_can.dtsi"
+#include "sama5d3_mci2.dtsi"
+#include "sama5d3_uart.dtsi"
+#include "sama5d3_tcb1.dtsi"
 
 / {
 	model = "Atmel SAMA5D35-EK";
diff --git a/arch/arm/boot/dts/sama5d3xcm.dtsi b/arch/arm/boot/dts/sama5d3xcm.dtsi
index 1f80508..f58aa43 100644
--- a/arch/arm/boot/dts/sama5d3xcm.dtsi
+++ b/arch/arm/boot/dts/sama5d3xcm.dtsi
@@ -19,17 +19,6 @@
 		reg = <0x20000000 0x20000000>;
 	};
 
-	clocks {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		main_clock: clock at 0 {
-			compatible = "atmel,osc", "fixed-clock";
-			clock-frequency = <12000000>;
-		};
-	};
-
 	ahb {
 		apb {
 			spi0: spi at f0004000 {
@@ -39,6 +28,12 @@
 			macb0: ethernet at f0028000 {
 				phy-mode = "rgmii";
 			};
+
+			pmc: pmc at fffffc00 {
+				main: mainck {
+					clock-frequency = <12000000>;
+				};
+			};
 		};
 
 		nand0: nand at 60000000 {
-- 
1.7.9.5



From linux at arm.linux.org.uk  Wed Jul 17 16:34:09 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 21:34:09 +0100
Subject: preempted dup_mm misses TLB invalidate
In-Reply-To: <51E6FA10.5070504@nvidia.com>
References: <51E43D2B.9090709@nvidia.com>
 <20130717192746.GE16496@MacBook-Pro.local> <51E6F60D.6060804@wwwdotorg.org>
 <51E6FA10.5070504@nvidia.com>
Message-ID: <20130717203409.GU24642@n2100.arm.linux.org.uk>

On Wed, Jul 17, 2013 at 01:09:52PM -0700, Nickolas Fortino wrote:
> The problem is eventually a user process performs a store which hits on  
> a writeable TLB entry with the PTE marked as read only. Is it supposed  
> to be possible for a user threading bug to end up in this state?

I've thought about that, and I'm not sure what we can do about this.
Moreover, I really don't think it matters at all.

Let's consider a SMP system running a multithreaded application.  CPUs
0 and 1 are running two threads, CPU 1 is about to do a fork, but CPU 0
is doing a large time consuming memcpy().

CPU 1 does the fork while CPU 0 is still running this large memcpy.  It
walks the page tables, setting the PTEs to read-only.  Let's say for
argument sake that it immediately invalidates each PTE after modification.

There is still a window which CPU0 can see the TLB entry, but the PTE has
already been write protected.  The only way to close this window is to
stop all threads of the process doing a fork().

However, before we think "oh, that sounds like a solution", let's think
about this a bit more first.

Let's say that we are on a system which doesn't need any TLB maintanence.
In other words, all PTE updates are seen by all observers immediately.

Consider the above scenario again.  What is the state of the memory at
the point the fork() returns, as seen from both the multithreaded parent
point of view and the child point of view?  Can you predict where in
that memcpy() CPU 0 will have been (and therefore what data the child can
see from that memcpy)?

The answer is you can't, because you don't know if CPU 0 might have had
an interrupt to deal with which stole time away from the memcpy().  You
don't know the relative timing of CPU 0's loads/stores against the time
it took CPU 1 to mark the PTE read-only.

Even if you stopped all threads on entry to a fork, the same problem
exists - at the point that you stopped the other threads, how do you know
what data they've written to memory?

What I'm pointing out here is that in this situation, the data visible to
the child process is unpredictable.


So, does it matter if a thread hits a page which has been marked read-only
in the PTE but hasn't been invalidated yet?  The answer to that is no -
because the parent and the child will see the update, and it will be
absolutely no different from what would have happened if the store had
happened _just before_ the PTE was marked read-only.

I'm pretty convinced that if you need to rely on a multi-threaded
programs state at the point you fork(), you must have some way to quiesce
your other threads _in user space_ rather than hoping that the kernel has
some magic to patch over this.


From magnus.damm at gmail.com  Wed Jul 17 16:49:18 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 18 Jul 2013 05:49:18 +0900
Subject: [PATCH] ARM: shmobile: r8a7790 SMP prototype v5
Message-ID: <20130717204918.30125.40588.sendpatchset@w520>

From: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>

Add SMP prototype support for r8a7790 by enabling
one cluster of either 4 x Cortex-A7 or 4 x Cortex-A15.

This patch only adds support for booting, at this point
no CPU Hotplug is included. In v5 both the big and the
LITTLE clusters are working with either architected timers
(in physical mode only for CA7) or CMT and broadcast timer.

On r8a7790 the MD6 pin control boot processor, and on the
Lager board SW8.7 can be used to select big or LITTLE.

In big boot mode the CPU cores will be configured as:
 - CPU0, CPU1, CPU2, CPU3: enabled (CA15)
 - CPU4, CPU5, CPU6, CPU7: disabled (CA7)

In LITTLE boot mode the CPU cores will be configured as:
 - CPU0, CPU5, CPU6, CPU7: enabled (CA7)
 - CPU1, CPU2, CPU3, CPU4: disabled (CA15)

Base addresses for RST and APMU are still hard coded
but DT will be used for them in future versions.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Changes since v4:
 - Rolled in the following patches from Kuribayashi-san, thanks!
   ARM: shmobile: smp-r8a7790: remove the obsolete RESCNT register
   ARM: shmobile: smp-r8a7790: rename s/carescnt/rescnt/g
   ARM: shmobile: smp-r8a7790: rename s/cabar/bar/g as well
   ARM: shmobile: smp-r8a7790: power up a CPU core at .smp_boot_secondary stage

 Written against kernel.org renesas git tag renesas-devel-20130717

 arch/arm/boot/dts/r8a7790.dtsi                 |   49 ++++++++
 arch/arm/mach-shmobile/Makefile                |    1 
 arch/arm/mach-shmobile/board-lager-reference.c |    1 
 arch/arm/mach-shmobile/board-lager.c           |    1 
 arch/arm/mach-shmobile/include/mach/common.h   |    1 
 arch/arm/mach-shmobile/include/mach/r8a7790.h  |    1 
 arch/arm/mach-shmobile/setup-r8a7790.c         |    1 
 arch/arm/mach-shmobile/smp-r8a7790.c           |  143 ++++++++++++++++++++++++
 8 files changed, 198 insertions(+)

--- 0001/arch/arm/boot/dts/r8a7790.dtsi
+++ work/arch/arm/boot/dts/r8a7790.dtsi	2013-07-18 05:35:38.000000000 +0900
@@ -24,6 +24,55 @@
 			reg = <0>;
 			clock-frequency = <1300000000>;
 		};
+
+		cpu1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <1>;
+			clock-frequency = <1300000000>;
+		};
+
+		cpu2: cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <2>;
+			clock-frequency = <1300000000>;
+		};
+
+		cpu3: cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <3>;
+			clock-frequency = <1300000000>;
+		};
+
+		cpu4: cpu at 4 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x100>;
+			clock-frequency = <780000000>;
+		};
+
+		cpu5: cpu at 5 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x101>;
+			clock-frequency = <780000000>;
+		};
+
+		cpu6: cpu at 6 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x102>;
+			clock-frequency = <780000000>;
+		};
+
+		cpu7: cpu at 7 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x103>;
+			clock-frequency = <780000000>;
+		};
 	};
 
 	gic: interrupt-controller at f1001000 {
--- 0001/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-07-18 05:35:38.000000000 +0900
@@ -19,6 +19,7 @@ obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.
 smp-y				:= platsmp.o headsmp.o
 smp-$(CONFIG_ARCH_SH73A0)	+= smp-sh73a0.o headsmp-scu.o
 smp-$(CONFIG_ARCH_R8A7779)	+= smp-r8a7779.o headsmp-scu.o
+smp-$(CONFIG_ARCH_R8A7790)	+= smp-r8a7790.o
 smp-$(CONFIG_ARCH_EMEV2)	+= smp-emev2.o headsmp-scu.o
 
 # IRQ objects
--- 0001/arch/arm/mach-shmobile/board-lager-reference.c
+++ work/arch/arm/mach-shmobile/board-lager-reference.c	2013-07-18 05:35:38.000000000 +0900
@@ -38,6 +38,7 @@ static const char *lager_boards_compat_d
 };
 
 DT_MACHINE_START(LAGER_DT, "lager")
+	.smp		= smp_ops(r8a7790_smp_ops),
 	.init_early	= r8a7790_init_delay,
 	.init_machine	= lager_add_standard_devices,
 	.init_time	= r8a7790_timer_init,
--- 0001/arch/arm/mach-shmobile/board-lager.c
+++ work/arch/arm/mach-shmobile/board-lager.c	2013-07-18 05:35:38.000000000 +0900
@@ -133,6 +133,7 @@ static const char *lager_boards_compat_d
 };
 
 DT_MACHINE_START(LAGER_DT, "lager")
+	.smp		= smp_ops(r8a7790_smp_ops),
 	.init_early	= r8a7790_init_delay,
 	.init_time	= r8a7790_timer_init,
 	.init_machine	= lager_add_standard_devices,
--- 0001/arch/arm/mach-shmobile/include/mach/common.h
+++ work/arch/arm/mach-shmobile/include/mach/common.h	2013-07-18 05:35:38.000000000 +0900
@@ -11,6 +11,7 @@ extern void shmobile_boot_vector(void);
 extern unsigned long shmobile_boot_fn;
 extern unsigned long shmobile_boot_arg;
 extern void shmobile_boot_scu(void);
+extern void shmobile_invalidate_start(void);
 struct clk;
 extern int shmobile_clk_init(void);
 extern void shmobile_handle_irq_intc(struct pt_regs *);
--- 0001/arch/arm/mach-shmobile/include/mach/r8a7790.h
+++ work/arch/arm/mach-shmobile/include/mach/r8a7790.h	2013-07-18 05:35:38.000000000 +0900
@@ -7,6 +7,7 @@ void r8a7790_clock_init(void);
 void r8a7790_pinmux_init(void);
 void r8a7790_init_delay(void);
 void r8a7790_timer_init(void);
+extern struct smp_operations r8a7790_smp_ops;
 
 #define MD(nr) BIT(nr)
 u32 r8a7790_read_mode_pins(void);
--- 0001/arch/arm/mach-shmobile/setup-r8a7790.c
+++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-07-18 05:35:38.000000000 +0900
@@ -281,6 +281,7 @@ static const char *r8a7790_boards_compat
 };
 
 DT_MACHINE_START(R8A7790_DT, "Generic R8A7790 (Flattened Device Tree)")
+	.smp		= smp_ops(r8a7790_smp_ops),
 	.init_early	= r8a7790_init_delay,
 	.init_time	= r8a7790_timer_init,
 	.dt_compat	= r8a7790_boards_compat_dt,
--- /dev/null
+++ work/arch/arm/mach-shmobile/smp-r8a7790.c	2013-07-18 05:40:04.000000000 +0900
@@ -0,0 +1,143 @@
+/*
+ * SMP support for r8a7790
+ *
+ * Copyright (C) 2012-2013 Renesas Solutions Corp.
+ * Copyright (C) 2012 Takashi Yoshii <takashi.yoshii.ze at renesas.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/smp.h>
+#include <linux/io.h>
+#include <asm/smp_plat.h>
+#include <mach/common.h>
+
+#define RST	0xe6160000
+#define CA15BAR	0x0020
+#define CA7BAR	0x0030
+#define CA15RESCNT 0x0040
+#define CA7RESCNT 0x0044
+
+#define APMU	0xe6150000
+#define CA15WUPCR 0x2010
+#define CA7WUPCR 0x1010
+
+#define MERAM	0xe8080000
+
+enum { R8A7790_CLST_CA15, R8A7790_CLST_CA7, R8A7790_CLST_NR };
+
+static struct {
+	unsigned int bar;
+	unsigned int rescnt;
+	unsigned int rescnt_magic;
+} r8a7790_clst[R8A7790_CLST_NR] = {
+	[R8A7790_CLST_CA15] = {
+		.bar = CA15BAR,
+		.rescnt = CA15RESCNT,
+		.rescnt_magic = 0xa5a50000,
+	},
+	[R8A7790_CLST_CA7] = {
+		.bar = CA7BAR,
+		.rescnt = CA7RESCNT,
+		.rescnt_magic = 0x5a5a0000,
+	},
+};
+
+#define r8a7790_clst_id(cpu) (cpu_logical_map((cpu)) >> 8)
+#define r8a7790_cpu_id(cpu) (cpu_logical_map((cpu)) & 0xff)
+
+static void r8a7790_deassert_reset(unsigned int cpu)
+{
+	void __iomem *p, *rescnt;
+	u32 bar, mask, magic;
+	unsigned int clst_id = r8a7790_clst_id(cpu);
+
+	/* setup reset vectors */
+	p = ioremap_nocache(RST, 0x63);
+	bar = (MERAM >> 8) & 0xfffffc00;
+	writel_relaxed(bar, p + r8a7790_clst[clst_id].bar);
+	writel_relaxed(bar | 0x10, p + r8a7790_clst[clst_id].bar);
+
+	/* enable per-core clocks */
+	mask = BIT(3 - r8a7790_cpu_id(cpu));
+	magic = r8a7790_clst[clst_id].rescnt_magic;
+	rescnt = p + r8a7790_clst[clst_id].rescnt;
+	writel_relaxed((readl_relaxed(rescnt) & ~mask) | magic, rescnt);
+
+	iounmap(p);
+}
+
+static void r8a7790_assert_reset(unsigned int cpu)
+{
+	void __iomem *p, *rescnt;
+	u32 mask, magic;
+	unsigned int clst_id = r8a7790_clst_id(cpu);
+
+	p = ioremap_nocache(RST, 0x63);
+
+	/* disable per-core clocks */
+	mask = BIT(3 - r8a7790_cpu_id(cpu));
+	magic = r8a7790_clst[clst_id].rescnt_magic;
+	rescnt = p + r8a7790_clst[clst_id].rescnt;
+	writel_relaxed((readl_relaxed(rescnt) | mask) | magic, rescnt);
+
+	iounmap(p);
+}
+
+static void r8a7790_power_on(unsigned int cpu)
+{
+	void __iomem *p, *cawupcr;
+
+	/* wake up CPU core via APMU */
+	p = ioremap_nocache(APMU, 0x3000);
+	cawupcr = p + (r8a7790_clst_id(cpu) ? CA7WUPCR : CA15WUPCR);
+	writel_relaxed(BIT(r8a7790_cpu_id(cpu)), cawupcr);
+
+	/* wait for APMU to finish */
+	while (readl_relaxed(cawupcr) != 0)
+		;
+
+	iounmap(p);
+}
+
+static void __init r8a7790_smp_prepare_cpus(unsigned int max_cpus)
+{
+	void __iomem *p;
+	unsigned int k;
+
+	shmobile_boot_fn = virt_to_phys(shmobile_invalidate_start);
+
+	/* MERAM for jump stub, because BAR requires 256KB aligned address */
+	p = ioremap_nocache(MERAM, 16);
+	memcpy_toio(p, shmobile_boot_vector, 16);
+	iounmap(p);
+
+	/* keep secondary CPU cores in reset */
+	for (k = 1; k < 8; k++)
+		r8a7790_assert_reset(k);
+}
+
+static int __cpuinit r8a7790_boot_secondary(unsigned int cpu,
+					    struct task_struct *idle)
+{
+	/* only allow a single cluster for now */
+	if (r8a7790_clst_id(cpu) != r8a7790_clst_id(0))
+		return -ENOTSUPP;
+
+	r8a7790_power_on(cpu);
+	r8a7790_deassert_reset(cpu);
+	return 0;
+}
+
+struct smp_operations r8a7790_smp_ops __initdata = {
+	.smp_prepare_cpus	= r8a7790_smp_prepare_cpus,
+	.smp_boot_secondary	= r8a7790_boot_secondary,
+};


From swarren at wwwdotorg.org  Wed Jul 17 16:55:27 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Jul 2013 14:55:27 -0600
Subject: [PATCH 2/4] pinctrl: Allow pinctrl to have multiple active states
In-Reply-To: <20130716090534.5541.60381.stgit@localhost>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090534.5541.60381.stgit@localhost>
Message-ID: <51E704BF.20508@wwwdotorg.org>

On 07/16/2013 03:05 AM, Tony Lindgren wrote:
> It's quite common that we need to dynamically change some pins for a
> device for runtime PM, or toggle a pin between rx and tx. Changing all
> the pins for a device is not efficient way of doing it.
> 
> So let's allow setting up multiple active states for pinctrl. Currently
> we only need PINCTRL_STATIC and PINCTRL_DYNAMIC, where PINCTRL_STATIC
> covers the current default pins, and PINCTRL_DYNAMIC holds the dynamic
> pins that need to be toggled.

> diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h

> +enum pinctr_states {

s/pinctr/pinctrl/


From nfortino at nvidia.com  Wed Jul 17 17:03:34 2013
From: nfortino at nvidia.com (Nickolas Fortino)
Date: Wed, 17 Jul 2013 14:03:34 -0700
Subject: preempted dup_mm misses TLB invalidate
In-Reply-To: <20130717203409.GU24642@n2100.arm.linux.org.uk>
References: <51E43D2B.9090709@nvidia.com>
 <20130717192746.GE16496@MacBook-Pro.local> <51E6F60D.6060804@wwwdotorg.org>
 <51E6FA10.5070504@nvidia.com> <20130717203409.GU24642@n2100.arm.linux.org.uk>
Message-ID: <51E706A6.4040309@nvidia.com>

On 7/17/2013 1:34 PM, Russell King - ARM Linux wrote:
> Even if you stopped all threads on entry to a fork, the same problem
> exists - at the point that you stopped the other threads, how do you know
> what data they've written to memory?
>
> What I'm pointing out here is that in this situation, the data visible to
> the child process is unpredictable.

I agree the data visible to the child process is inherently 
unpredictable. If you stop all process threads on a fork, however, you 
do preserve the invariant that memory accesses are not seen out of 
order. In your memcopy case, it is indeterminate how much of the memcopy 
has completed, but it is known that later pages in the memcopy will only 
have been written if prior pages have been updated.

With the current kernel configuration, you can have holes. Any page 
which hits in the TLB has the memcopy data appear in the forked process. 
Any page which misses in the TLB will not appear in the forked process. 
The choice of which pages get memcopy data in the forked process will 
appear random based on TLB contents, a behavior you cannot have if you 
freeze threads on a fork.



From sameo at linux.intel.com  Wed Jul 17 17:07:00 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Wed, 17 Jul 2013 23:07:00 +0200
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <20130717210700.GA19864@zurbaran>

Hi Lorenzo,

On Tue, Jul 16, 2013 at 05:05:42PM +0100, Lorenzo Pieralisi wrote:
> Hello,
> 
> version v5 of VExpress SPC driver, please read on the changelog for major
> changes and explanations.
> 
> The probing scheme is unchanged, since after trying the early platform
> devices approach it appeared that the end result was no better than the
> current one. The only clean solution relies either on changing how
> secondaries are brought up in the kernel (later than now) or enable
> early platform device registration through DT. Please check this
> thread for the related discussion:
> 
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036542.html
> 
> The interface was adapted to regmap and again reverted to old driver for
> the following reasons:
> 
> - Power down registers locking is hairy and requires arch spinlocks in
>   the MCPM back end to work properly, normal spinlocks cannot be used
> - Regmap adds unnecessary code to manage SPC since it is just a bunch of
>   registers used to control power management flags, the overhead is just
>   not worth it (talking about power down registers, not the vexpress config
>   interface)
> - The locking scheme behind regmap requires all registers in the map
>   to be protected with the same lock, which is not exactly what we want
>   here
> - Given the reasons above, adding a regmap interface buys us nothing from
>   a driver readability and maintainability perspective (again just talking
>   about the power interface, a few registers) because for the SPC it would
>   simply not be used
> 
> /drivers/mfd is probably not the right place for this code as it stands (but
> probably will be when the entire driver, with DVFS and config interface, is
> complete).
Could you please elaborate on how will the SPC driver extend into an MFD
driver?

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/


From sameo at linux.intel.com  Wed Jul 17 17:10:21 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Wed, 17 Jul 2013 23:10:21 +0200
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <1374070811.3146.124.camel@hornet>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374052705.3146.86.camel@hornet>
 <alpine.LFD.2.03.1307170825240.14924@syhkavp.arg>
 <1374067786.3146.123.camel@hornet>
 <alpine.LFD.2.03.1307171014510.14924@syhkavp.arg>
 <1374070811.3146.124.camel@hornet>
Message-ID: <20130717211021.GB19864@zurbaran>

Hi Pawel,

On Wed, Jul 17, 2013 at 03:20:11PM +0100, Pawel Moll wrote:
> On Wed, 2013-07-17 at 15:16 +0100, Nicolas Pitre wrote:
> > On Wed, 17 Jul 2013, Pawel Moll wrote:
> > 
> > > On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote:
> > > > If this is really miscelaneous code that really doesn't fit 
> > > > anywhere else, it should rather go into drivers/misc/ as a last resort.
> > > 
> > > Interestingly enough drivers/misc was my first choice for all the
> > > vexpress stuff, but it wasn't received well...
> > > 
> > > Anyway, the SPC driver as it is now seem to be a "power management
> > > system driver". Maybe a relevant directory would be in place? Wouldn't
> > > PSCI belong there as well? (there are two psci.c files in arch/arm and
> > > arch/arm64, surprisingly similar ones ;-)
> > > 
> > > The bottom line is: today it is not an MFD driver.
> > 
> > But we know it will, right?  So better  save some churn by storing the 
> > initial code where it would end up anyway once complete.
> 
> Not in that form, no. The code living in mfd will just register
> mfd_cells while "functional" parts are going to live elsewhere. This is
> how I understand what Samuel asked me to do and that's what is happening
> to vexpress-sysreg now.
Very good, I'll happily apply such changes.
If I understand the IP correctly, the SPC driver will stay as a set of
runtime APIs for controlling the SPC features. If that's the case, then
misc sounds like a more appropriate place for this driver.
drivers/power/ really is for power supplies and charging drivers.

Cheers,
Samuel. 

-- 
Intel Open Source Technology Centre
http://oss.intel.com/


From swarren at wwwdotorg.org  Wed Jul 17 17:14:59 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Jul 2013 15:14:59 -0600
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130716090536.5541.36289.stgit@localhost>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
Message-ID: <51E70953.1000601@wwwdotorg.org>

On 07/16/2013 03:05 AM, Tony Lindgren wrote:
> To toggle dynamic states, let's add the optional active state in
> addition to the static default state. Then if the optional active
> state is defined, we can require that idle and sleep states cover
> the same pingroups as the active state.
> 
> Then let's add pinctrl_check_dynamic() and pinctrl_select_dynamic()
> to use instead of pinctrl_select() to avoid breaking existing users.
> 
> With pinctrl_check_dynamic() we can check that idle and sleep states
> match the active state for pingroups during init, and don't need to
> do it during runtime.
> 
> Then with the states pre-validated, pinctrl_select_dynamic() can
> just toggle between the dynamic states without extra checks.
> 
> Note that pinctr_select_state() still has valid use cases, such as
> changing states when the pins can be shared between two drivers
> and don't necessarily cover the same pingroups. For dynamic runtime
> toggling of pin states, we should eventually always use just
> pinctrl_select_dynamic().

> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c

> @@ -887,6 +887,8 @@ static void pinctrl_free(struct pinctrl *p, bool inlist)
>  		list_for_each_entry_safe(setting, n2, &state->settings, node) {
>  			pinctrl_free_setting(state == p->state[PINCTRL_STATIC],
>  					     setting);
> +			pinctrl_free_setting(state == p->state[PINCTRL_DYNAMIC],
> +					     setting);

This will cause pinmux_free_setting() or pinconf_free_setting() to be
called twice on the setting object. Right now they don't do anything,
but if they start to kfree() some dynamically-allocated data that's
stored within the setting, that'll cause problems. I would suggest a
loop body something more like:

bool disable_setting = state == XXX || state == YYY;
pinctrl_free_setting(disable_setting, setting);

> +int pinctrl_check_dynamic(struct device *dev, struct pinctrl_state *st1,
> +			  struct pinctrl_state *st2)
> +{
> +	struct pinctrl_setting *s1, *s2;
> +
> +	list_for_each_entry(s1, &st1->settings, node) {
...
> +		list_for_each_entry(s2, &st2->settings, node) {
...
> +			if (pctldev1 != pctldev2) {
> +				dev_dbg(dev, "pctldev must be the same for states\n");
> +				return -EINVAL;
> +			}

I don't think we should require that; it's perfectly legal at the moment
for some device's pinctrl configuration to include settings from
multiple different pin controllers.

> +			for (i = 0; i < num_pins1; i++) {
> +				int pin1 = pins1[i];
> +
> +				for (j = 0; j < num_pins2; j++) {
> +					int pin2 = pins2[j];
> +
> +					if (pin1 == pin2) {
> +						found++;
> +						break;
> +					}
> +				}
> +			}
> +
> +			if (found != num_pins1) {

I guess this make sure that every entry in the dynamic state is in the
state state, but not vice-versa; the static state can affect more stuff
than the dynamic state?

If so, shouldn't that check be if (found != num_pins2)?

> +int pinctrl_select_dynamic(struct pinctrl *p, struct pinctrl_state *state)

The body of this function is rather duplicated with pinctrl_select().

> @@ -1241,7 +1371,13 @@ static int pinctrl_pm_select_state(struct device *dev, struct pinctrl_state *sta
>  		return 0;
>  	if (IS_ERR(state))
>  		return 0; /* No such state */
> -	ret = pinctrl_select_state(pins->p, state);
> +
> +	/* Configured for proper dynamic muxing? */

I don't think "proper" is correct here; it's just fine not to have any
dynamic configuration.

> +	if (!IS_ERR(dev->pins->active_state))
> +		ret = pinctrl_select_dynamic(pins->p, state);
> +	else
> +		ret = pinctrl_select_state(pins->p, state);

Hmmm. I'm not quite sure this is right... Surely this function should
just do nothing if the dynamic states aren't defined? The system should
just, and only, be in the "default" state and never do anything else.

Looking back at patch 1, I see the are
pinctrl_pm_select_{default,sleep,idle}_state(). Shouldn't that list be
active/sleep/idle, since I assume default is that "static" state, and
the other three are the "dynamic" states?

> +static int pinctrl_pm_check_state(struct device *dev,
> +				  struct pinctrl_state *state)

Naming this pinctrl_pm_is_state_error() or pinctrl_pm_is_state_ok()
might give more clue what its return value is expected to be.


From sam at ravnborg.org  Wed Jul 17 17:16:49 2013
From: sam at ravnborg.org (Sam Ravnborg)
Date: Wed, 17 Jul 2013 23:16:49 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the
 new streaming format
In-Reply-To: <20130716180408.GA19863@merkur.ravnborg.org>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716004727.b60b2c96.akpm@linux-foundation.org>
 <20130716005611.e4ccab02.akpm@linux-foundation.org>
 <201307161008.07643.yann.morin.1998@free.fr>
 <20130716180408.GA19863@merkur.ravnborg.org>
Message-ID: <20130717211649.GA5619@merkur.ravnborg.org>

> 
> We could extend the symbol option part to retreive values from a binary.
> Something like this:
> 
> config FOOBAR
>         bool
>         option exec="true"
> 
> FOOBAR would assume the value "y" if the command true has exit code == 0, otherwise "n".
> And similar conversions for other types.
> 
> This only extendt Kconfig slightly - using an already present method to import
> external values.
> 
> The drawback I see with this approach is that we may execute a lot of small programs
> where the value is never used.

Following is a quick patch implmenting this idea.
You need to run gperf manually to enable this.

"gperf -C scripts/kconfig/zconf.gperf > scripts/kconfig/zconf.hash.c"

I did not figure out how to use the built-in rules to generate this file :-(

I have tested this lightly - as we should discuss if this is a viable way forward.
For now I used popen() - so return value of the executed program are ignored.

To test this I used:

config FOOBAR
	bool
	option exec="echo y"

config FOOBAR_SELECTOR
	bool
	default FOOBAR

Nothing fancy - but it shows the idea.

	Sam


diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index df198a5..a68258b 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -133,6 +133,7 @@ enum prop_type {
 	P_SELECT,   /* select BAR */
 	P_RANGE,    /* range 7..100 (for a symbol) */
 	P_ENV,      /* value from environment variable */
+	P_EXEC,     /* value from executable (using symbol option) */
 	P_SYMBOL,   /* where a symbol is defined */
 };
 
diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h
index 09f4edf..371f73b 100644
--- a/scripts/kconfig/lkc.h
+++ b/scripts/kconfig/lkc.h
@@ -61,6 +61,7 @@ enum conf_def_mode {
 #define T_OPT_MODULES		1
 #define T_OPT_DEFCONFIG_LIST	2
 #define T_OPT_ENV		3
+#define T_OPT_EXEC		4
 
 struct kconf_id {
 	int name;
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index 7e233a6..cfa7aaa 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -213,6 +213,9 @@ void menu_add_option(int token, char *arg)
 	case T_OPT_ENV:
 		prop_add_env(arg);
 		break;
+	case T_OPT_EXEC:
+		prop_add_exec(arg);
+		break;
 	}
 }
 
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index d550300..b7179a6 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -1331,6 +1331,8 @@ const char *prop_get_type_name(enum prop_type type)
 		return "prompt";
 	case P_ENV:
 		return "env";
+	case P_EXEC:
+		return "exec";
 	case P_COMMENT:
 		return "comment";
 	case P_MENU:
@@ -1379,3 +1381,56 @@ static void prop_add_env(const char *env)
 	else
 		menu_warn(current_entry, "environment variable %s undefined", env);
 }
+
+static void exec_command(const char *command, struct symbol *sym)
+{
+	char buffer[2048];
+	FILE *stream;
+
+	stream = popen(command, "r");
+
+	if (stream != NULL) {
+		if (fgets(buffer, sizeof(buffer), stream) != NULL) {
+			int i;
+
+			buffer[sizeof(buffer) - 1] = '\0';
+
+			/* Drop any trialing newlines */
+			i = strlen(buffer);
+			while (i > 0 && buffer[i - 1] == '\n') {
+				buffer[i - 1] = '\0';
+				i--;
+			}
+			/* Validate the output of the command */
+			if (strlen(buffer) == 0) {
+				menu_warn(current_entry,
+				          "command '%s' - invalid (empty?) return value: \"%s\"",
+				          command, buffer);
+				return;
+			}
+
+			menu_warn(current_entry, "default: %s", buffer);
+			sym_add_default(sym, buffer);
+		} else {
+			menu_warn(current_entry, "command '%s' - empty return value", command);
+		}
+		pclose(stream);
+	} else {
+		menu_warn(current_entry, "command '%s' failed to execute", command);
+	}
+}
+
+static void prop_add_exec(const char *command)
+{
+	struct property *prop;
+	struct symbol *sym;
+
+	sym = current_entry->sym;
+	sym->flags |= SYMBOL_AUTO;
+
+	prop = prop_alloc(P_EXEC, sym);
+	prop->expr = expr_alloc_symbol(sym_lookup(command, SYMBOL_CONST));
+
+	exec_command(command, sym);
+}
+
diff --git a/scripts/kconfig/zconf.gperf b/scripts/kconfig/zconf.gperf
index f14ab41..02c6a59 100644
--- a/scripts/kconfig/zconf.gperf
+++ b/scripts/kconfig/zconf.gperf
@@ -44,4 +44,5 @@ on,		T_ON,		TF_PARAM
 modules,	T_OPT_MODULES,	TF_OPTION
 defconfig_list,	T_OPT_DEFCONFIG_LIST,TF_OPTION
 env,		T_OPT_ENV,	TF_OPTION
+exec,		T_OPT_EXEC,	TF_OPTION
 %%


From swarren at wwwdotorg.org  Wed Jul 17 17:21:35 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Jul 2013 15:21:35 -0600
Subject: [PATCH 4/4] drivers: Add pinctrl handling for dynamic pin states
In-Reply-To: <20130716090539.5541.980.stgit@localhost>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090539.5541.980.stgit@localhost>
Message-ID: <51E70ADF.8090805@wwwdotorg.org>

On 07/16/2013 03:05 AM, Tony Lindgren wrote:
> We want to have static pin states handled separately from
> dynamic pin states, so let's add optional state_active.
> 
> Then if state_active is defined, let's check and make sure
> state_idle and state_sleep match state_active for the
> pin groups to avoid checking them during runtime as the
> active and idle pins may need to be toggled for many
> devices every time we enter and exit idle.

> +	 * Note that if active state is defined, sleep and idle states must
> +	 * cover the same pin groups as active state.
>  	 */
>  	dev->pins->sleep_state = pinctrl_lookup_state(dev->pins->p,
>  					PINCTRL_STATE_SLEEP);
> -	if (IS_ERR(dev->pins->sleep_state))
> +	if (IS_ERR(dev->pins->sleep_state)) {
>  		/* Not supplying this state is perfectly legal */
>  		dev_dbg(dev, "no sleep pinctrl state\n");
> +	} else if (!IS_ERR(dev->pins->active_state)) {
> +		ret = pinctrl_check_dynamic(dev, dev->pins->active_state,
> +					    dev->pins->sleep_state);

Oh, I see you're trying to check that the set of pins in the active,
sleep, and idle states are identical.

But I think that pinctrl_check_dynamic() only checks that one state is a
subset of the other, not that the two states are equal. Instead, I think
you want to comparison coded in pinctrl_check_dynamic() to be:

gen_group_list_of_pinctrl_state(s1, array1);
gen_group_list_of_pinctrl_state(s2, array2);
mismatch = memcmp(array1, array2, length);


From linux at arm.linux.org.uk  Wed Jul 17 17:21:48 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Jul 2013 22:21:48 +0100
Subject: preempted dup_mm misses TLB invalidate
In-Reply-To: <51E706A6.4040309@nvidia.com>
References: <51E43D2B.9090709@nvidia.com>
 <20130717192746.GE16496@MacBook-Pro.local> <51E6F60D.6060804@wwwdotorg.org>
 <51E6FA10.5070504@nvidia.com> <20130717203409.GU24642@n2100.arm.linux.org.uk>
 <51E706A6.4040309@nvidia.com>
Message-ID: <20130717212148.GV24642@n2100.arm.linux.org.uk>

On Wed, Jul 17, 2013 at 02:03:34PM -0700, Nickolas Fortino wrote:
> On 7/17/2013 1:34 PM, Russell King - ARM Linux wrote:
>> Even if you stopped all threads on entry to a fork, the same problem
>> exists - at the point that you stopped the other threads, how do you know
>> what data they've written to memory?
>>
>> What I'm pointing out here is that in this situation, the data visible to
>> the child process is unpredictable.
>
> I agree the data visible to the child process is inherently  
> unpredictable. If you stop all process threads on a fork, however, you  
> do preserve the invariant that memory accesses are not seen out of  
> order. In your memcopy case, it is indeterminate how much of the memcopy  
> has completed, but it is known that later pages in the memcopy will only  
> have been written if prior pages have been updated.
>
> With the current kernel configuration, you can have holes. Any page  
> which hits in the TLB has the memcopy data appear in the forked process.  
> Any page which misses in the TLB will not appear in the forked process.  
> The choice of which pages get memcopy data in the forked process will  
> appear random based on TLB contents, a behavior you cannot have if you  
> freeze threads on a fork.

So... how is this handled on x86 or any of the other architectures?  I'm
willing to bet that the behaviour you observe on ARM is inherently visible
on many of the other Linux architectures.

Short of modifying the generic kernel to halt all threads, this can not be
fixed.


From swarren at wwwdotorg.org  Wed Jul 17 17:23:41 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Jul 2013 15:23:41 -0600
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130716090536.5541.36289.stgit@localhost>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
Message-ID: <51E70B5D.6030802@wwwdotorg.org>

On 07/16/2013 03:05 AM, Tony Lindgren wrote:
> To toggle dynamic states, let's add the optional active state in
> addition to the static default state. Then if the optional active
> state is defined, we can require that idle and sleep states cover
> the same pingroups as the active state.
> 
> Then let's add pinctrl_check_dynamic() and pinctrl_select_dynamic()
> to use instead of pinctrl_select() to avoid breaking existing users.
> 
> With pinctrl_check_dynamic() we can check that idle and sleep states
> match the active state for pingroups during init, and don't need to
> do it during runtime.
> 
> Then with the states pre-validated, pinctrl_select_dynamic() can
> just toggle between the dynamic states without extra checks.
> 
> Note that pinctr_select_state() still has valid use cases, such as
> changing states when the pins can be shared between two drivers
> and don't necessarily cover the same pingroups. For dynamic runtime
> toggling of pin states, we should eventually always use just
> pinctrl_select_dynamic().

Something in this series should edit Documentation/pinctrl.txt to
explain the philosophy behind the static/dynamic state split. That
philosophy and/or semantics are more important to review than the code...

Related to that, I'm worried that using pinctrl_select_state() and
pinctrl_select_dynamic() appear to be mutually-exclusive options here.
Why shouldn't e.g. a pinctrl-based I2C mux also be able to do runtime
PM? Does the mux setting select which states are used for runtime PM, or
does runtime PM override the basic mux setting, or must the pincrl-I2C
mux manually implement custom runtime-PM/pinctrl interaction since
there's no generic answer to those questions? How many more custom
exceptions will there be?


From sameo at linux.intel.com  Wed Jul 17 17:23:43 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Wed, 17 Jul 2013 23:23:43 +0200
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <alpine.LFD.2.03.1307171416490.14924@syhkavp.arg>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374052705.3146.86.camel@hornet>
 <alpine.LFD.2.03.1307170825240.14924@syhkavp.arg>
 <1374067786.3146.123.camel@hornet>
 <alpine.LFD.2.03.1307171014510.14924@syhkavp.arg>
 <1374070811.3146.124.camel@hornet>
 <alpine.LFD.2.03.1307171148160.14924@syhkavp.arg>
 <20130717170038.GP24642@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1307171416490.14924@syhkavp.arg>
Message-ID: <20130717212343.GC19864@zurbaran>

Hi Nicolas,

On Wed, Jul 17, 2013 at 02:29:02PM -0400, Nicolas Pitre wrote:
> On Wed, 17 Jul 2013, Russell King - ARM Linux wrote:
> 
> > On Wed, Jul 17, 2013 at 11:57:55AM -0400, Nicolas Pitre wrote:
> > > The sanest location at this point might simply be 
> > > drivers/platform/vexpress_spc.c or drivers/platform/vexpress/spc.c 
> > > depending on whether or not more such driver glue is expected in the 
> > > vexpress future.  No point putting "arm" in the path, especially if this 
> > > is later reused on arm64.
> > 
> > You wouldn't be making that argument if it were arch/arm64 and arch/arm32 -
> > you'd probably be arguing that "arm" made perfect sense.
> 
> Well... in a sense: yes.  But in the end, having per arch directories 
> under drivers/ is silly.  We already have per arch directories under 
> arch/already.
> 
> > Don't get too hung up on names please, it's really not worth the time
> > and effort being soo pedantic, and being soo pedantic leads to "pointless
> > churn" when someone comes along and wants to pedantically change the
> > names because it no longer matches the users.
> 
> At this point I don't really care about the name.  I just want the damn 
> thing merged upstream.  But after several iterations to either fit one 
> or another maintainers taste, each rework ends up in that maintainer 
> saying: "Now that you've reworked the code, I still don't like it since 
> this no longer fits in my subsystem tree."
FWIW, we asked Pawel to rework the sysreg and config parts of the
vexpress driver, make it an actual MFD driver, and spread the remaining
bits of the code into their respective subsystems. I don't think
this is an eccentric requirement.


> In fact what we'd need at this point is 
> drivers/code_that_no_subsystem_maintainers_wants/.  
Which is what some people think drivers/mfd/ is...
I don't mind merging Lorenzo's SPC driver as it is if he can explain to
me how it will eventually evolve into an actual MFD driver. If that's
not the case, I don't see how I could justify merging it through the
MFD tree.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/


From akpm at linux-foundation.org  Wed Jul 17 17:37:09 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Wed, 17 Jul 2013 14:37:09 -0700
Subject: [PATCH 0/3] Few ignored framebuffer fixes/additions
In-Reply-To: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20130717143709.f8879fb7f0a5d55859e96838@linux-foundation.org>

On Mon, 15 Jul 2013 17:26:59 +0200 Maxime Ripard <maxime.ripard at free-electrons.com> wrote:

> Sorry to bother you again with the framebuffer stuff but the new
> maintainer doesn't appear to be responsive either.

Jean-Christophe is doing things - on 11 July he sent out a call for
late patches to linux-fbdev at vger.kernel.org.

So hopefully the resend of this patch series will be handled
appropriately?



From pavel at denx.de  Wed Jul 17 17:38:36 2013
From: pavel at denx.de (Pavel Machek)
Date: Wed, 17 Jul 2013 23:38:36 +0200
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <51E6CCE4.20705@wwwdotorg.org>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <20130716041056.GA30067@S2101-09.ap.freescale.net>
 <51E56AA7.7020103@wwwdotorg.org>
 <20130717030246.GA4541@S2101-09.ap.freescale.net>
 <51E6CCE4.20705@wwwdotorg.org>
Message-ID: <20130717213836.GA13324@amd.pavel.ucw.cz>

On Wed 2013-07-17 10:57:08, Stephen Warren wrote:
> On 07/16/2013 09:02 PM, Shawn Guo wrote:
> > On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote:
> >> Registering the driver earlier won't cause any bugs. However, it's not
> >> the correct approach.
> >>
> >> Deferred probe /is/ the approach for assuring correct dependencies
> >> between drivers. It works and should be used. There are not enough
> >> initcall levels to play games using initcalls and solve all the issues,
> >> and the ordering requirements vary board-to-board. Deferred probe at
> >> runtime handles this without having to manually place all the drivers
> >> into specific initcall levels, and dynamically adjusts to board
> >> differences, since it all happens automatically at run-time.
> > 
> > I do not quite follow the argument here.  I agree with you that
> > deferred probe is the approach to solve dependencies.  But it does not
> > necessarily mean that initcall can not be used to help it save some
> > nasty or nested deferring.  Deferred probe and initcalls are not two
> > mutually exclusive mechanisms but two which can help each other.
> 
> My understanding is that deferred probe was implemented specifically to
> avoid having to, or allowing, the use of initcall levels to determine
> probe order.
> 
> However, if someone closely associated with the implementation of
> deferred probe (e.g. Grant, or a device core maintainer) is willing to
> step up and say I'm wrong, I'll drop my objection.

AFAIR, defered probing is known to be a "hack" by its authors. We
should still try to get initcall levels right...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From cb at sgoc.de  Wed Jul 17 17:43:12 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Wed, 17 Jul 2013 23:43:12 +0200 (CEST)
Subject: [PATCH v2 3/3] mxs: added driver for OCOTP in i.MX23 and i.MX28
In-Reply-To: <20130717192627.GA12533@pengutronix.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
 <1374078460-4126-1-git-send-email-cb@sgoc.de>
 <1374078460-4126-4-git-send-email-cb@sgoc.de>
 <20130717192627.GA12533@pengutronix.de>
Message-ID: <1068003072.1131668.1374097392210.open-xchange@email.1und1.de>

Hello Sascha,

thanks for your input. I must admit that I didn't do a thorough review of the
FSL code...


> Sascha Hauer <s.hauer at pengutronix.de> hat am 17. Juli 2013 um 21:26
> geschrieben:
> [...]
> > +static DEFINE_MUTEX(otp_mutex);
> > +static struct kobject *otp_kobj;
> > +static struct attribute **attrs;
> > +static struct kobj_attribute *kattr;
> > +static struct attribute_group attr_group;
> > +static unsigned long otp_hclk_saved;
> > +static u32 otp_voltage_saved;
> > +static resource_size_t otp_base_address;
> > +struct regulator *regu;
>
> Collect your driver data in a struct and pass it around in functions
> calls. No need to limit this driver to a single instance.

The OTP device is unique in the CPU and several instances i.e. potential
concurrent access is considered harmful. So I kept this construction
from FSL.


> > +static int otp_write_prepare(void)
> > +{
> > +? ? ?struct clk *hclk;
> > +? ? ?int err = 0;
> > +
> > +? ? ?/* [1] HCLK to 24MHz. */
> > +? ? ?hclk = clk_get_sys("hbus", NULL);
>
> This is a driver, so you should use regular clk_get, not clk_get_sys.
> Besides, this has to be done during probe. clk_get takes a reference to
> the clock which has to be released.

As far as I remember testing clk_get didn't work in this place.
In the API doc I only found the warning:
"clk_get_sys should not be called from within interrupt context.".


Regards,
Christoph


From bp at alien8.de  Wed Jul 17 17:44:42 2013
From: bp at alien8.de (Borislav Petkov)
Date: Wed, 17 Jul 2013 23:44:42 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130717211649.GA5619@merkur.ravnborg.org>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716004727.b60b2c96.akpm@linux-foundation.org>
 <20130716005611.e4ccab02.akpm@linux-foundation.org>
 <201307161008.07643.yann.morin.1998@free.fr>
 <20130716180408.GA19863@merkur.ravnborg.org>
 <20130717211649.GA5619@merkur.ravnborg.org>
Message-ID: <20130717214441.GB4454@pd.tnic>

On Wed, Jul 17, 2013 at 11:16:49PM +0200, Sam Ravnborg wrote:
> +
> +static void exec_command(const char *command, struct symbol *sym)
> +{
> +	char buffer[2048];
> +	FILE *stream;

Just some indentation level saving:

> +
> +	stream = popen(command, "r");
> +
> +	if (stream != NULL) {

	if (!stream) {
		menu_warn(current_entry, "command '%s' failed to execute", command);
		return;
	}

and the rest starts one level less to the right:

	if (fgets(buffer, sizeof(buffer), stream) != NULL) {
		int i;

		buffer[sizeof(buffer) - 1] = '\0';

and so on...

> +
> +			/* Drop any trialing newlines */
> +			i = strlen(buffer);
> +			while (i > 0 && buffer[i - 1] == '\n') {
> +				buffer[i - 1] = '\0';
> +				i--;
> +			}
> +			/* Validate the output of the command */
> +			if (strlen(buffer) == 0) {
> +				menu_warn(current_entry,
> +				          "command '%s' - invalid (empty?) return value: \"%s\"",
> +				          command, buffer);
> +				return;
> +			}
> +
> +			menu_warn(current_entry, "default: %s", buffer);
> +			sym_add_default(sym, buffer);
> +		} else {
> +			menu_warn(current_entry, "command '%s' - empty return value", command);
> +		}
> +		pclose(stream);
> +	} else {
> +		menu_warn(current_entry, "command '%s' failed to execute", command);
> +	}
> +}

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--


From daniel.lezcano at linaro.org  Wed Jul 17 17:45:47 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 17 Jul 2013 23:45:47 +0200
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <51E6FF0B.5000708@wwwdotorg.org>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
 <51E6FF0B.5000708@wwwdotorg.org>
Message-ID: <51E7108B.5030504@linaro.org>

On 07/17/2013 10:31 PM, Stephen Warren wrote:
> On 07/17/2013 04:15 AM, Joseph Lo wrote:
>> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
>>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
>>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
>>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
>>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
>>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
>>>>>> this state.
> ... [ discussion of issues with Joesph's patches applied]
>>
>> OK. I did more stress tests last night and today. I found it cause by
>> the patch "ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag" and
>> only impact the Tegra20 platform. The hot plug regression seems due to
>> this patch. After dropping this patch on top of v3.11-rc1, the Tegra20
>> can back to normal.
>>
>> And the hop plug and suspend stress test can pass on Tegra30/114 too.
>>
>> Can the other two patch series for Tegra114 to support CPU idle power
>> down mode and system suspend still moving forward, not be blocked by
>> this patch?
>>
>> Looks the CPUIDLE_FLAG_TIMER_STOP flag still cause some other issue for
>> hot plug on Tegra20, I will continue to check this. You can just drop
>> this patch.
> 
> OK, if I drop that patch, then everything on Tegra20 and Tegra30 seems
> fine again.
> 
> However, I've found some new and exciting issue on Tegra114!
> 
> With unmodified v3.11-rc1, I can do the following without issue:
> 
> * Unplug/replug CPUs, so that I had all combinations of CPU 1, 2, 3
> plugged/unpplugged (with CPU 0 always plugged).
> 
> * Unplug/replug CPUs, so that I had all combinations of CPU 0, 1, 2, 3
> plugged/unpplugged (with the obvious exception of never having all CPUs
> unplugged).
> 
> However, if I try this with your Tegra114 cpuidle and suspend patches
> applied, I see the following issues:
> 
> 1) If I boot, unplug CPU 0, then replug CPU 0, the system immediately
> hard-hangs.
> 
> 2) If I run the hotplug test script, leaving CPU 0 always present, I
> sometimes see:
> 
>> root at localhost:~# for i in `seq 1 50`; do echo ITERATION $i; ./cpuonline.py; done
>> ITERATION 1
>> echo 0 > /sys/devices/system/cpu/cpu2/online
>> [  458.910054] CPU2: shutdown
>> echo 0 > /sys/devices/system/cpu/cpu1/online
>> [  461.004371] CPU1: shutdown
>> echo 0 > /sys/devices/system/cpu/cpu3/online
>> [  463.027341] CPU3: shutdown
>> echo 1 > /sys/devices/system/cpu/cpu1/online
>> [  465.061412] CPU1: Booted secondary processor
>> echo 1 > /sys/devices/system/cpu/cpu2/online
>> [  467.095313] CPU2: Booted secondary processor
>> [  467.113243] ------------[ cut here ]------------
>> [  467.117948] WARNING: CPU: 2 PID: 0 at kernel/time/tick-broadcast.c:667 tick_broadcast_oneshot_control+0x19c/0x1c4()
>> [  467.128352] Modules linked in:
>> [  467.131455] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.11.0-rc1-00022-g7487363-dirty #49
>> [  467.139678] [<c0015620>] (unwind_backtrace+0x0/0xf8) from [<c001154c>] (show_stack+0x10/0x14)
>> [  467.148228] [<c001154c>] (show_stack+0x10/0x14) from [<c05135a8>] (dump_stack+0x80/0xc4)
>> [  467.156336] [<c05135a8>] (dump_stack+0x80/0xc4) from [<c0024590>] (warn_slowpath_common+0x64/0x88)
>> [  467.165300] [<c0024590>] (warn_slowpath_common+0x64/0x88) from [<c00245d0>] (warn_slowpath_null+0x1c/0x24)
>> [  467.174959] [<c00245d0>] (warn_slowpath_null+0x1c/0x24) from [<c00695e4>] (tick_broadcast_oneshot_control+0x19c/0x1c4)
>> [  467.185659] [<c00695e4>] (tick_broadcast_oneshot_control+0x19c/0x1c4) from [<c0067cdc>] (clockevents_notify+0x1b0/0x1dc)
>> [  467.196538] [<c0067cdc>] (clockevents_notify+0x1b0/0x1dc) from [<c034f348>] (cpuidle_idle_call+0x11c/0x168)
>> [  467.206292] [<c034f348>] (cpuidle_idle_call+0x11c/0x168) from [<c000f134>] (arch_cpu_idle+0x8/0x38)
>> [  467.215359] [<c000f134>] (arch_cpu_idle+0x8/0x38) from [<c0061038>] (cpu_startup_entry+0x60/0x134)
>> [  467.224325] [<c0061038>] (cpu_startup_entry+0x60/0x134) from [<800083d8>] (0x800083d8)
>> [  467.232227] ---[ end trace ea579be22a00e7fb ]---
>> echo 0 > /sys/devices/system/cpu/cpu1/online
>> [  469.126682] CPU1: shutdown
> 
> I have found no solution for (1) (although I didn't look hard!).
> 
> (2) can be solved with the following (at least 50 iterations of my test
> script worked with this patch applied):

Actually this warning is resulting from a bug in the tick broadcast code
and has been solved with commit:

https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers/urgent&id=ea8deb8dfa6b0e8d1b3d1051585706739b46656c

This patch has been merged in timers/urgent branch but still need to
merged with timers/core.

The patch below does not fix the warning but prevents the tick warning
to occur. Applying the patch above will fix your problem.


>> diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
>> index 658b205..896408d 100644
>> --- a/arch/arm/mach-tegra/cpuidle-tegra114.c
>> +++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
>> @@ -66,8 +66,7 @@ static struct cpuidle_driver tegra_idle_driver = {
>>                         .exit_latency           = 500,
>>                         .target_residency       = 1000,
>>                         .power_usage            = 0,
>> -                       .flags                  = CPUIDLE_FLAG_TIME_VALID |
>> -                                                 CPUIDLE_FLAG_TIMER_STOP,
>> +                       .flags                  = CPUIDLE_FLAG_TIME_VALID,
>>                         .name                   = "powered-down",
>>                         .desc                   = "CPU power gated",
>>                 },
> 
> Here's my test script for reference:
> 
> #!/usr/bin/env python
> 
> import multiprocessing
> import os
> import sys
> import time
> 
> cpus = multiprocessing.cpu_count()
> if cpus == 4:
>   socf = file('/sys/devices/soc0/soc_id')
>   soc = socf.readline().strip()
>   socf.close()
>   if True: #soc == '48':
>     gc = (11, 9, 1, 3, 7, 5, 13, 15)
>   else:
>     gc = (14, 10, 11, 9, 8, 1, 3, 2, 6, 7, 5, 4, 12, 13, 15)
> elif cpus == 2:
>   gc = (1, 3)
> else:
>   raise Exception("Invalid CPU count %d" % cpus)
> 
> oldidx = len(gc) - 1
> oldmask = gc[oldidx]
> 
> for newidx in range(len(gc)):
>   newmask = gc[newidx]
>   for cpu in range(cpus):
>     oldon = oldmask & (1 << cpu)
>     newon = newmask & (1 << cpu)
>     if oldon != newon:
>       if newon:
>         newonval = 1
>       else:
>         newonval = 0
>       cmd = "echo %d > /sys/devices/system/cpu/cpu%d/online" \
> % (newonval, cpu)
>       print cmd
>       os.system(cmd)
>   time.sleep(2)
>   oldidx = newidx
>   oldmask = newmask
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From sboyd at codeaurora.org  Wed Jul 17 17:52:02 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 17 Jul 2013 14:52:02 -0700
Subject: [GIT PULL] Remove ARM local timer API
In-Reply-To: <20130708153528.GB830@codeaurora.org>
References: <20130625200211.GA11625@codeaurora.org>
 <20130628000853.GB11547@quad.lixom.net> <20130708153528.GB830@codeaurora.org>
Message-ID: <51E71202.5060207@codeaurora.org>

On 07/08/13 08:35, Stephen Boyd wrote:
> On 06/27, Olof Johansson wrote:
>> On Tue, Jun 25, 2013 at 01:02:12PM -0700, Stephen Boyd wrote:
>>> Olof/Arnd,
>>>
>>> These patches remove the ARM local timer API. The ARM architected
>>> timers have already moved away from this API so this series
>>> migrates the rest of the users allowing us to remove the API
>>> entirely. Thomas has been kind enough to take the first two
>>> patches into timers/core in the tip tree (thanks Thomas!) so I've
>>> merged that into v3.10-rc1 and then applied the rest of the
>>> patches on top. Let me know if this is acceptable.
>> We need guarantees from Thomas that the branch is stable and will never be
>> rebased before it hit Linus tree, or we'll be in a world of pain for
>> dependencies like these.
>>
>> Thomas, is this branch stable or do you anticipate a rebase?
>>
> This branch has merged into Linus' tree. Can this go through the
> arm-soc tree now?
>

The merge window is over now. Can this be merged for 3.12?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 17 17:53:13 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 17 Jul 2013 14:53:13 -0700
Subject: [PATCH] irqchip: gic: Don't complain in gic_get_cpumask() if
 UP system
In-Reply-To: <20130712121023.GB27430@codeaurora.org>
References: <1373067573-29946-1-git-send-email-sboyd@codeaurora.org>
 <20130712111322.GC3213@e102654-lin.cambridge.arm.com>
 <20130712121023.GB27430@codeaurora.org>
Message-ID: <51E71249.4050200@codeaurora.org>

On 07/12/13 05:10, Stephen Boyd wrote:
> On 07/12, Javi Merino wrote:
>> I agree, we should drop the check.  It's annoying in uniprocessors and
>> unlikely to be found in the real world unless your gic entry in the dt
>> is wrong.
>>
> Ok. How about this?

Any comments?

>
> ----8<-----
> Subject: [PATCH v2] irqchip: gic: Don't complain in gic_get_cpumask()
>
> In a uniprocessor implementation the interrupt processor targets
> registers are read-as-zero/write-ignored (RAZ/WI). Unfortunately
> gic_get_cpumask() will print a critical message saying
>
>  GIC CPU mask not found - kernel will fail to boot.
>
> if these registers all read as zero, but there won't actually be
> a problem on uniprocessor systems and the kernel will boot just
> fine. Remove this check because if you're on a multiprocessor
> system it's unlikely to be printed unless your DT is wrong or
> your hardware is broken.
>
> Cc: Nicolas Pitre <nico at linaro.org>
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> Cc: Javi Merino <javi.merino at arm.com>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  drivers/irqchip/irq-gic.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 19ceaa60..4fbcea9 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -368,9 +368,6 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic)
>  			break;
>  	}
>  
> -	if (!mask)
> -		pr_crit("GIC CPU mask not found - kernel will fail to boot.\n");
> -
>  	return mask;
>  }
>  


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From swarren at wwwdotorg.org  Wed Jul 17 18:01:41 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Jul 2013 16:01:41 -0600
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <51E7108B.5030504@linaro.org>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
 <51E6FF0B.5000708@wwwdotorg.org> <51E7108B.5030504@linaro.org>
Message-ID: <51E71445.4070306@wwwdotorg.org>

On 07/17/2013 03:45 PM, Daniel Lezcano wrote:
> On 07/17/2013 10:31 PM, Stephen Warren wrote:
>> On 07/17/2013 04:15 AM, Joseph Lo wrote:
>>> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
>>>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
>>>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
>>>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
>>>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
>>>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
>>>>>>> this state.
>> ... [ discussion of issues with Joesph's patches applied]
>>>
>>> OK. I did more stress tests last night and today. I found it cause by
>>> the patch "ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag" and
>>> only impact the Tegra20 platform. The hot plug regression seems due to
>>> this patch. After dropping this patch on top of v3.11-rc1, the Tegra20
>>> can back to normal.
>>>
>>> And the hop plug and suspend stress test can pass on Tegra30/114 too.
>>>
>>> Can the other two patch series for Tegra114 to support CPU idle power
>>> down mode and system suspend still moving forward, not be blocked by
>>> this patch?
>>>
>>> Looks the CPUIDLE_FLAG_TIMER_STOP flag still cause some other issue for
>>> hot plug on Tegra20, I will continue to check this. You can just drop
>>> this patch.
>>
>> OK, if I drop that patch, then everything on Tegra20 and Tegra30 seems
>> fine again.
>>
>> However, I've found some new and exciting issue on Tegra114!
>>
>> With unmodified v3.11-rc1, I can do the following without issue:
>>
>> * Unplug/replug CPUs, so that I had all combinations of CPU 1, 2, 3
>> plugged/unpplugged (with CPU 0 always plugged).
>>
>> * Unplug/replug CPUs, so that I had all combinations of CPU 0, 1, 2, 3
>> plugged/unpplugged (with the obvious exception of never having all CPUs
>> unplugged).
>>
>> However, if I try this with your Tegra114 cpuidle and suspend patches
>> applied, I see the following issues:
>>
>> 1) If I boot, unplug CPU 0, then replug CPU 0, the system immediately
>> hard-hangs.
>>
>> 2) If I run the hotplug test script, leaving CPU 0 always present, I
>> sometimes see:
>>
>>> root at localhost:~# for i in `seq 1 50`; do echo ITERATION $i; ./cpuonline.py; done
>>> ITERATION 1
>>> echo 0 > /sys/devices/system/cpu/cpu2/online
>>> [  458.910054] CPU2: shutdown
>>> echo 0 > /sys/devices/system/cpu/cpu1/online
>>> [  461.004371] CPU1: shutdown
>>> echo 0 > /sys/devices/system/cpu/cpu3/online
>>> [  463.027341] CPU3: shutdown
>>> echo 1 > /sys/devices/system/cpu/cpu1/online
>>> [  465.061412] CPU1: Booted secondary processor
>>> echo 1 > /sys/devices/system/cpu/cpu2/online
>>> [  467.095313] CPU2: Booted secondary processor
>>> [  467.113243] ------------[ cut here ]------------
>>> [  467.117948] WARNING: CPU: 2 PID: 0 at kernel/time/tick-broadcast.c:667 tick_broadcast_oneshot_control+0x19c/0x1c4()
>>> [  467.128352] Modules linked in:
>>> [  467.131455] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.11.0-rc1-00022-g7487363-dirty #49
>>> [  467.139678] [<c0015620>] (unwind_backtrace+0x0/0xf8) from [<c001154c>] (show_stack+0x10/0x14)
>>> [  467.148228] [<c001154c>] (show_stack+0x10/0x14) from [<c05135a8>] (dump_stack+0x80/0xc4)
>>> [  467.156336] [<c05135a8>] (dump_stack+0x80/0xc4) from [<c0024590>] (warn_slowpath_common+0x64/0x88)
>>> [  467.165300] [<c0024590>] (warn_slowpath_common+0x64/0x88) from [<c00245d0>] (warn_slowpath_null+0x1c/0x24)
>>> [  467.174959] [<c00245d0>] (warn_slowpath_null+0x1c/0x24) from [<c00695e4>] (tick_broadcast_oneshot_control+0x19c/0x1c4)
>>> [  467.185659] [<c00695e4>] (tick_broadcast_oneshot_control+0x19c/0x1c4) from [<c0067cdc>] (clockevents_notify+0x1b0/0x1dc)
>>> [  467.196538] [<c0067cdc>] (clockevents_notify+0x1b0/0x1dc) from [<c034f348>] (cpuidle_idle_call+0x11c/0x168)
>>> [  467.206292] [<c034f348>] (cpuidle_idle_call+0x11c/0x168) from [<c000f134>] (arch_cpu_idle+0x8/0x38)
>>> [  467.215359] [<c000f134>] (arch_cpu_idle+0x8/0x38) from [<c0061038>] (cpu_startup_entry+0x60/0x134)
>>> [  467.224325] [<c0061038>] (cpu_startup_entry+0x60/0x134) from [<800083d8>] (0x800083d8)
>>> [  467.232227] ---[ end trace ea579be22a00e7fb ]---
>>> echo 0 > /sys/devices/system/cpu/cpu1/online
>>> [  469.126682] CPU1: shutdown
>>
>> I have found no solution for (1) (although I didn't look hard!).
>>
>> (2) can be solved with the following (at least 50 iterations of my test
>> script worked with this patch applied):
> 
> Actually this warning is resulting from a bug in the tick broadcast code
> and has been solved with commit:
> 
> https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers/urgent&id=ea8deb8dfa6b0e8d1b3d1051585706739b46656c
> 
> This patch has been merged in timers/urgent branch but still need to
> merged with timers/core.
> 
> The patch below does not fix the warning but prevents the tick warning
> to occur. Applying the patch above will fix your problem.

Yes, I was imprecise when I said solve; I simply meant that making that
change prevented me from seeing that issue any more.

That patch is already in v3.11-rc1, and I was using that as a base when
I applied Joseph's patches. So, it doesn't solve this issue.


From nicolas.pitre at linaro.org  Wed Jul 17 18:22:46 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Jul 2013 18:22:46 -0400 (EDT)
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <20130717212343.GC19864@zurbaran>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374052705.3146.86.camel@hornet>
 <alpine.LFD.2.03.1307170825240.14924@syhkavp.arg>
 <1374067786.3146.123.camel@hornet>
 <alpine.LFD.2.03.1307171014510.14924@syhkavp.arg>
 <1374070811.3146.124.camel@hornet>
 <alpine.LFD.2.03.1307171148160.14924@syhkavp.arg>
 <20130717170038.GP24642@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1307171416490.14924@syhkavp.arg>
 <20130717212343.GC19864@zurbaran>
Message-ID: <alpine.LFD.2.03.1307171758591.14924@syhkavp.arg>

On Wed, 17 Jul 2013, Samuel Ortiz wrote:

> On Wed, Jul 17, 2013 at 02:29:02PM -0400, Nicolas Pitre wrote:
> > At this point I don't really care about the name.  I just want the damn 
> > thing merged upstream.  But after several iterations to either fit one 
> > or another maintainers taste, each rework ends up in that maintainer 
> > saying: "Now that you've reworked the code, I still don't like it since 
> > this no longer fits in my subsystem tree."
> FWIW, we asked Pawel to rework the sysreg and config parts of the
> vexpress driver, make it an actual MFD driver, and spread the remaining
> bits of the code into their respective subsystems. I don't think
> this is an eccentric requirement.

I agree.  However the code that Lorenzo just posted can't be deprived 
of any more sysreg/config parts.  They are simply nonexistent.

Even the larger code you reviewed before is completely useless without 
_additional_ drivers to go on top which are indeed waiting after this 
code to be merged before they are submitted to their respective 
subsystems.

And those additional drivers are way more interesting than this dumb 
register access arbitrator.  Because this is fundamentally the only 
thing it does.

> > In fact what we'd need at this point is 
> > drivers/code_that_no_subsystem_maintainers_wants/.  
> Which is what some people think drivers/mfd/ is...

Does mfd still stand for "Multi Function Device"?

> I don't mind merging Lorenzo's SPC driver as it is if he can explain to
> me how it will eventually evolve into an actual MFD driver. If that's
> not the case, I don't see how I could justify merging it through the
> MFD tree.

Maybe the misunderstanding is about what actually is a MFD driver.
Given your persisting reluctance, I may only conclude that this is 
indeed not a MFD driver after all.

So I'll follow existing precedents in the kernel and move Lorenzo's code 
to drivers/platform/vexpress/.


Nicolas


From swarren at wwwdotorg.org  Wed Jul 17 18:24:38 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Jul 2013 16:24:38 -0600
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <20130717213836.GA13324@amd.pavel.ucw.cz>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <20130716041056.GA30067@S2101-09.ap.freescale.net>
 <51E56AA7.7020103@wwwdotorg.org>
 <20130717030246.GA4541@S2101-09.ap.freescale.net>
 <51E6CCE4.20705@wwwdotorg.org> <20130717213836.GA13324@amd.pavel.ucw.cz>
Message-ID: <51E719A6.6070105@wwwdotorg.org>

On 07/17/2013 03:38 PM, Pavel Machek wrote:
> On Wed 2013-07-17 10:57:08, Stephen Warren wrote:
>> On 07/16/2013 09:02 PM, Shawn Guo wrote:
>>> On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote:
>>>> Registering the driver earlier won't cause any bugs. However, it's not
>>>> the correct approach.
>>>>
>>>> Deferred probe /is/ the approach for assuring correct dependencies
>>>> between drivers. It works and should be used. There are not enough
>>>> initcall levels to play games using initcalls and solve all the issues,
>>>> and the ordering requirements vary board-to-board. Deferred probe at
>>>> runtime handles this without having to manually place all the drivers
>>>> into specific initcall levels, and dynamically adjusts to board
>>>> differences, since it all happens automatically at run-time.
>>>
>>> I do not quite follow the argument here.  I agree with you that
>>> deferred probe is the approach to solve dependencies.  But it does not
>>> necessarily mean that initcall can not be used to help it save some
>>> nasty or nested deferring.  Deferred probe and initcalls are not two
>>> mutually exclusive mechanisms but two which can help each other.
>>
>> My understanding is that deferred probe was implemented specifically to
>> avoid having to, or allowing, the use of initcall levels to determine
>> probe order.
>>
>> However, if someone closely associated with the implementation of
>> deferred probe (e.g. Grant, or a device core maintainer) is willing to
>> step up and say I'm wrong, I'll drop my objection.
> 
> AFAIR, defered probing is known to be a "hack" by its authors. We
> should still try to get initcall levels right...

I don't /think/ it was the concept of deferred probe that was considered
hacky, but perhaps just the first proof-of-concept implementation, and
any hackiness was presumably solved before the feature was merged.


From yann.morin.1998 at free.fr  Wed Jul 17 18:30:33 2013
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Thu, 18 Jul 2013 00:30:33 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130717211649.GA5619@merkur.ravnborg.org>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716004727.b60b2c96.akpm@linux-foundation.org>
 <20130716005611.e4ccab02.akpm@linux-foundation.org>
 <201307161008.07643.yann.morin.1998@free.fr>
 <20130716180408.GA19863@merkur.ravnborg.org>
 <20130717211649.GA5619@merkur.ravnborg.org>
Message-ID: <20130717223033.GF3385@free.fr>

Sam, All,

Well, while I was fighting on this on my side... ;-)

On 2013-07-17 23:16 +0200, Sam Ravnborg spake thusly:
> > We could extend the symbol option part to retreive values from a binary.
> > Something like this:
> > 
> > config FOOBAR
> >         bool
> >         option exec="true"
> > 
> > FOOBAR would assume the value "y" if the command true has exit code == 0, otherwise "n".
> > And similar conversions for other types.
> > 
> > This only extendt Kconfig slightly - using an already present method to import
> > external values.
> > 
> > The drawback I see with this approach is that we may execute a lot of small programs
> > where the value is never used.
> 
> Following is a quick patch implmenting this idea.
> You need to run gperf manually to enable this.
> 
> "gperf -C scripts/kconfig/zconf.gperf > scripts/kconfig/zconf.hash.c"
> 
> I did not figure out how to use the built-in rules to generate this file :-(

make REGENERATE_PARSERS=y menuconfig

> I have tested this lightly - as we should discuss if this is a viable way forward.

Instead of extending the Kconfig language, I was thinking (as initially
suggested by Andrew) of generating a Kconfig file before all config
targets, and source that Kconfig file from $(TOPDIR)/Kconfig.

I'm not a fan od extending the Kconfig language in this way. It feels
weird to me. Especially when we have a way to solve this specific issue
with a script that generates the needed Kconfig symbols before any
config target is called.

At the very least we'd have to decide if this is available only for
booleans/tristates, or for any type? Your implementation seems to make
it valid for strings/ints, too.

> For now I used popen() - so return value of the executed program are ignored.

Yet, pclose returns the exit status of the command.

If option exec was to be valid only for booleans, we could use the exit
value rather than the output, which would seem more logical. It would be
however a bit moretriclky for tristates, though...

Maybe using output is the best, after all...

So, how do you expect we use that to check for an external tool?
Something like this?
    config HAVE_LZ4
        bool
        option exec="which lz4c >/dev/null 2>&1 && echo y"

    config KERNEL_LZ4
        bool "compress the kernel with lz4"
        depends on HAVE_LZ4

Ot did I miss something?

> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
> index d550300..b7179a6 100644
> --- a/scripts/kconfig/symbol.c
> +++ b/scripts/kconfig/symbol.c
[--SNIP--]
> @@ -1379,3 +1381,56 @@ static void prop_add_env(const char *env)
>  	else
>  		menu_warn(current_entry, "environment variable %s undefined", env);
>  }
> +
> +static void exec_command(const char *command, struct symbol *sym)
> +{
> +	char buffer[2048];
> +	FILE *stream;
> +
> +	stream = popen(command, "r");
> +
> +	if (stream != NULL) {
> +		if (fgets(buffer, sizeof(buffer), stream) != NULL) {
> +			int i;
> +
> +			buffer[sizeof(buffer) - 1] = '\0';
> +
> +			/* Drop any trialing newlines */
> +			i = strlen(buffer);
> +			while (i > 0 && buffer[i - 1] == '\n') {
> +				buffer[i - 1] = '\0';
> +				i--;
> +			}
> +			/* Validate the output of the command */
> +			if (strlen(buffer) == 0) {
> +				menu_warn(current_entry,
> +				          "command '%s' - invalid (empty?) return value: \"%s\"",
> +				          command, buffer);
> +				return;

Missing pclose() before return.

[--SNIP--]

I'll give it a spin here. Thank you!

BTW, I still need your help on solving that one:
    randconfig does randomise choice entries, unless KCONFIG_ALLCONFIG
    is specified.
    http://marc.info/?l=linux-kernel&m=137209757414433&w=2

My two previous attempts failed due to introducing regressions, so they
were both reverted... :-(
Any suggestion? ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'


From broonie at kernel.org  Wed Jul 17 18:33:09 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Jul 2013 23:33:09 +0100
Subject: [PATCH] ASoC: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
In-Reply-To: <51E6E107.8020300@wwwdotorg.org>
References: <1374013667-21435-1-git-send-email-swarren@wwwdotorg.org>
 <20130717083003.GA22506@sirena.org.uk>
 <51E6CDEA.7060003@wwwdotorg.org>
 <20130717175701.GY22506@sirena.org.uk>
 <51E6E107.8020300@wwwdotorg.org>
Message-ID: <20130717223309.GZ22506@sirena.org.uk>

On Wed, Jul 17, 2013 at 12:23:03PM -0600, Stephen Warren wrote:
> On 07/17/2013 11:57 AM, Mark Brown wrote:

> > So how do they disable the core support for the older SoCs with the
> > new model?

> They don't; the core support is so small it's not worth having the
> ifdefs in it; just a few K. As such, it seems simpler to just always
> compile in the core support, and remove the need for all the ifdef
> nests in mach-tegra/. The bulk of the differences are different
> drivers for different chips.

So my take on that is that it seems like it's simpler to just have the
core selection since that's just one option for the user to choose and
save all the space for whatever device they're not interested in rather
than having to go through individual drivers disabling the boring SoCs.
It seems more straightfoward from a UI point of view but perhaps I'm not
thinking about it from the right angle?
-------------- 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/20130717/ff0e814b/attachment.sig>

From nicolas.pitre at linaro.org  Wed Jul 17 18:34:11 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Jul 2013 18:34:11 -0400 (EDT)
Subject: [PATCH] irqchip: gic: Don't complain in gic_get_cpumask() if UP
 system
In-Reply-To: <51E71249.4050200@codeaurora.org>
References: <1373067573-29946-1-git-send-email-sboyd@codeaurora.org>
 <20130712111322.GC3213@e102654-lin.cambridge.arm.com>
 <20130712121023.GB27430@codeaurora.org> <51E71249.4050200@codeaurora.org>
Message-ID: <alpine.LFD.2.03.1307171830170.14924@syhkavp.arg>

On Wed, 17 Jul 2013, Stephen Boyd wrote:

> On 07/12/13 05:10, Stephen Boyd wrote:
> > On 07/12, Javi Merino wrote:
> >> I agree, we should drop the check.  It's annoying in uniprocessors and
> >> unlikely to be found in the real world unless your gic entry in the dt
> >> is wrong.

And that's a likely outcome in the real world.

> >>
> > Ok. How about this?
> 
> Any comments?

What about this instead:

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 19ceaa60e0..86d21bc6cb 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -368,7 +368,7 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic)
 			break;
 	}
 
-	if (!mask)
+	if (is_smp() && !mask)
 		pr_crit("GIC CPU mask not found - kernel will fail to boot.\n");
 
 	return mask;


Nicolas


From sboyd at codeaurora.org  Wed Jul 17 18:36:40 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 17 Jul 2013 15:36:40 -0700
Subject: [PATCH] irqchip: gic: Don't complain in gic_get_cpumask() if
 UP system
In-Reply-To: <alpine.LFD.2.03.1307171830170.14924@syhkavp.arg>
References: <1373067573-29946-1-git-send-email-sboyd@codeaurora.org>
 <20130712111322.GC3213@e102654-lin.cambridge.arm.com>
 <20130712121023.GB27430@codeaurora.org> <51E71249.4050200@codeaurora.org>
 <alpine.LFD.2.03.1307171830170.14924@syhkavp.arg>
Message-ID: <51E71C78.6080604@codeaurora.org>

On 07/17/13 15:34, Nicolas Pitre wrote:
> On Wed, 17 Jul 2013, Stephen Boyd wrote:
>
>> On 07/12/13 05:10, Stephen Boyd wrote:
>>> On 07/12, Javi Merino wrote:
>>>> I agree, we should drop the check.  It's annoying in uniprocessors and
>>>> unlikely to be found in the real world unless your gic entry in the dt
>>>> is wrong.
> And that's a likely outcome in the real world.
>
>>> Ok. How about this?
>> Any comments?
> What about this instead:

Unfortunately arm64 doesn't have SMP_ON_UP. It sounds like you preferred
the first patch using num_possible_cpus()

>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 19ceaa60e0..86d21bc6cb 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -368,7 +368,7 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic)
>  			break;
>  	}
>  
> -	if (!mask)
> +	if (is_smp() && !mask)
>  		pr_crit("GIC CPU mask not found - kernel will fail to boot.\n");
>  
>  	return mask;
>
>
> Nicolas


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From sameo at linux.intel.com  Wed Jul 17 18:47:29 2013
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Thu, 18 Jul 2013 00:47:29 +0200
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <alpine.LFD.2.03.1307171758591.14924@syhkavp.arg>
References: <1374052705.3146.86.camel@hornet>
 <alpine.LFD.2.03.1307170825240.14924@syhkavp.arg>
 <1374067786.3146.123.camel@hornet>
 <alpine.LFD.2.03.1307171014510.14924@syhkavp.arg>
 <1374070811.3146.124.camel@hornet>
 <alpine.LFD.2.03.1307171148160.14924@syhkavp.arg>
 <20130717170038.GP24642@n2100.arm.linux.org.uk>
 <alpine.LFD.2.03.1307171416490.14924@syhkavp.arg>
 <20130717212343.GC19864@zurbaran>
 <alpine.LFD.2.03.1307171758591.14924@syhkavp.arg>
Message-ID: <20130717224729.GA20652@zurbaran>

On Wed, Jul 17, 2013 at 06:22:46PM -0400, Nicolas Pitre wrote:
> On Wed, 17 Jul 2013, Samuel Ortiz wrote:
> 
> > On Wed, Jul 17, 2013 at 02:29:02PM -0400, Nicolas Pitre wrote:
> > > At this point I don't really care about the name.  I just want the damn 
> > > thing merged upstream.  But after several iterations to either fit one 
> > > or another maintainers taste, each rework ends up in that maintainer 
> > > saying: "Now that you've reworked the code, I still don't like it since 
> > > this no longer fits in my subsystem tree."
> > FWIW, we asked Pawel to rework the sysreg and config parts of the
> > vexpress driver, make it an actual MFD driver, and spread the remaining
> > bits of the code into their respective subsystems. I don't think
> > this is an eccentric requirement.
> 
> I agree.  However the code that Lorenzo just posted can't be deprived 
> of any more sysreg/config parts.  
Yes, and I appreciate Lorenzo's effort here.


> Even the larger code you reviewed before is completely useless without 
> _additional_ drivers to go on top which are indeed waiting after this 
> code to be merged before they are submitted to their respective 
> subsystems.
Right. And merging this code in the right place is exactly what we're
doing here.

 
> And those additional drivers are way more interesting than this dumb 
> register access arbitrator.  
Yes, they're a lot smarter hence the requirement to have them live into
their respective subsystems where the right maintainer can provide
relevant reviews on them.

> > I don't mind merging Lorenzo's SPC driver as it is if he can explain to
> > me how it will eventually evolve into an actual MFD driver. If that's
> > not the case, I don't see how I could justify merging it through the
> > MFD tree.
> 
> Maybe the misunderstanding is about what actually is a MFD driver.
That's possible. I agree it should be documented properly.

> So I'll follow existing precedents in the kernel and move Lorenzo's code 
> to drivers/platform/vexpress/.
Thanks for that.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/


From swarren at wwwdotorg.org  Wed Jul 17 18:52:42 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 17 Jul 2013 16:52:42 -0600
Subject: [PATCH] ASoC: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
In-Reply-To: <20130717223309.GZ22506@sirena.org.uk>
References: <1374013667-21435-1-git-send-email-swarren@wwwdotorg.org>
 <20130717083003.GA22506@sirena.org.uk> <51E6CDEA.7060003@wwwdotorg.org>
 <20130717175701.GY22506@sirena.org.uk> <51E6E107.8020300@wwwdotorg.org>
 <20130717223309.GZ22506@sirena.org.uk>
Message-ID: <51E7203A.2020007@wwwdotorg.org>

On 07/17/2013 04:33 PM, Mark Brown wrote:
> On Wed, Jul 17, 2013 at 12:23:03PM -0600, Stephen Warren wrote:
>> On 07/17/2013 11:57 AM, Mark Brown wrote:
> 
>>> So how do they disable the core support for the older SoCs with
>>> the new model?
> 
>> They don't; the core support is so small it's not worth having
>> the ifdefs in it; just a few K. As such, it seems simpler to just
>> always compile in the core support, and remove the need for all
>> the ifdef nests in mach-tegra/. The bulk of the differences are
>> different drivers for different chips.
> 
> So my take on that is that it seems like it's simpler to just have
> the core selection since that's just one option for the user to
> choose and save all the space for whatever device they're not
> interested in rather than having to go through individual drivers
> disabling the boring SoCs. It seems more straightfoward from a UI
> point of view but perhaps I'm not thinking about it from the right
> angle?

Ah, so you mean keep the options in mach-tegra/Kconfig so that there's
a single place to configure per-SoC support, but just ignore those
options in code (like the Tegra CPU reset vector) where it's not worth
it. That sounds reasonable.

The one remaining issue is that we have plenty of HW module whose
driver works across multiple HW generations. For example,
tegra20_i2s.c supports only Tegra20, yet tegra30_i2s.c supports both
Tegra30 and Tegra114, and likely will support other generations too.
The key to enable tegra30_i2s.c should really be ARCH_TEGRA_3x_SOC ||
ARCH_TEGRA_114_SOC, which gets a bit unwieldy once you have, say, 4
different SoCs in that list and a similar list starts to apply to a
lot of different HW-modules/drivers. Even creating an
ARCH_TEGRA_30_OR_LATER_SOC will get problematic, since defining "or
later" will likely become progressively more complex over time, as we
start putting our more SoCs. What are your thoughts on the best way to
solve that?


From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 17 18:54:21 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Thu, 18 Jul 2013 00:54:21 +0200
Subject: [PATCH v2 1/4] pwm: Add PWM polarity flag macro for DT
In-Reply-To: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374101664-21112-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Define a PWM_POLARITY_INVERTED macro in include/dt-bindings/pwm/pwm.h to
be used by device tree sources.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 Documentation/devicetree/bindings/pwm/pwm.txt |  7 ++++---
 include/dt-bindings/pwm/pwm.h                 | 14 ++++++++++++++
 2 files changed, 18 insertions(+), 3 deletions(-)
 create mode 100644 include/dt-bindings/pwm/pwm.h

diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt b/Documentation/devicetree/bindings/pwm/pwm.txt
index 06e6724..8556263 100644
--- a/Documentation/devicetree/bindings/pwm/pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm.txt
@@ -43,13 +43,14 @@ because the name "backlight" would be used as fallback anyway.
 pwm-specifier typically encodes the chip-relative PWM number and the PWM
 period in nanoseconds.
 
-Optionally, the pwm-specifier can encode a number of flags in a third cell:
-- bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity)
+Optionally, the pwm-specifier can encode a number of flags (defined in
+<dt-bindings/pwm/pwm.h>) in a third cell:
+- PWM_POLARITY_INVERTED: invert the PWM signal polarity
 
 Example with optional PWM specifier for inverse polarity
 
 	bl: backlight {
-		pwms = <&pwm 0 5000000 1>;
+		pwms = <&pwm 0 5000000 PWM_POLARITY_INVERTED>;
 		pwm-names = "backlight";
 	};
 
diff --git a/include/dt-bindings/pwm/pwm.h b/include/dt-bindings/pwm/pwm.h
new file mode 100644
index 0000000..96f49e8
--- /dev/null
+++ b/include/dt-bindings/pwm/pwm.h
@@ -0,0 +1,14 @@
+/*
+ * This header provides constants for most PWM bindings.
+ *
+ * Most PWM bindings can include a flags cell as part of the PWM specifier.
+ * In most cases, the format of the flags cell uses the standard values
+ * defined in this header.
+ */
+
+#ifndef _DT_BINDINGS_PWM_PWM_H
+#define _DT_BINDINGS_PWM_PWM_H
+
+#define PWM_POLARITY_INVERTED			(1 << 0)
+
+#endif
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 17 18:54:20 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Thu, 18 Jul 2013 00:54:20 +0200
Subject: [PATCH v2 0/4] Add PWM polarity flag macro for DT
Message-ID: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Hello,

Here's a small patch set that replaces PWM polarity numerical constants with
macros in DT.

The series is the result of splitting the original patch into four patches
that

- add the flag macro (both in a header file and in the PWM DT binding core
  documentation)
- use the macro in the PWM core code
- update existing DT bindings to refer to the PWM DT bindings core
  documentation
- update existing DT sources to use the new macro

I believe I've taken all comments received so far into account. Most notable
changes include

- splitting the original patch
- removing the PWM_POLARITY_NORMAL flag, which wasn't a flag but was defined
  as 0
- renaming the PWM_POLARITY_INVERSED DT flag to PWM_POLARITY_INVERTED
- not relying on DT flags and PWM C flags having identical names and values

Laurent Pinchart (4):
  pwm: Add PWM polarity flag macro for DT
  pwm: Use the DT macro directly when parsing PWM DT flags
  pwm: Update DT bindings to reference pwm.txt for cells documentation
  ARM: dts: Use the PWM polarity flags

 Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt    |  8 +++-----
 Documentation/devicetree/bindings/pwm/imx-pwm.txt          |  4 ++--
 Documentation/devicetree/bindings/pwm/mxs-pwm.txt          |  4 ++--
 .../devicetree/bindings/pwm/nvidia,tegra20-pwm.txt         |  5 ++---
 Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt  |  4 ++--
 Documentation/devicetree/bindings/pwm/pwm-samsung.txt      | 10 +++-------
 Documentation/devicetree/bindings/pwm/pwm-tiecap.txt       |  8 +++-----
 Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt     |  8 +++-----
 Documentation/devicetree/bindings/pwm/pwm.txt              |  7 ++++---
 Documentation/devicetree/bindings/pwm/spear-pwm.txt        |  5 ++---
 Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt       |  4 ++--
 Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt    |  4 ++--
 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt       |  8 +++-----
 arch/arm/boot/dts/am335x-evmsk.dts                         |  3 ++-
 arch/arm/boot/dts/wm8850-w70v2.dts                         |  3 ++-
 drivers/pwm/core.c                                         |  7 +++----
 include/dt-bindings/pwm/pwm.h                              | 14 ++++++++++++++
 17 files changed, 54 insertions(+), 52 deletions(-)
 create mode 100644 include/dt-bindings/pwm/pwm.h

-- 
Regards,

Laurent Pinchart



From nicolas.pitre at linaro.org  Wed Jul 17 18:53:51 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Jul 2013 18:53:51 -0400 (EDT)
Subject: [PATCH] irqchip: gic: Don't complain in gic_get_cpumask() if UP
 system
In-Reply-To: <51E71C78.6080604@codeaurora.org>
References: <1373067573-29946-1-git-send-email-sboyd@codeaurora.org>
 <20130712111322.GC3213@e102654-lin.cambridge.arm.com>
 <20130712121023.GB27430@codeaurora.org> <51E71249.4050200@codeaurora.org>
 <alpine.LFD.2.03.1307171830170.14924@syhkavp.arg>
 <51E71C78.6080604@codeaurora.org>
Message-ID: <alpine.LFD.2.03.1307171849180.14924@syhkavp.arg>

On Wed, 17 Jul 2013, Stephen Boyd wrote:

> On 07/17/13 15:34, Nicolas Pitre wrote:
> > On Wed, 17 Jul 2013, Stephen Boyd wrote:
> >
> >> On 07/12/13 05:10, Stephen Boyd wrote:
> >>> On 07/12, Javi Merino wrote:
> >>>> I agree, we should drop the check.  It's annoying in uniprocessors and
> >>>> unlikely to be found in the real world unless your gic entry in the dt
> >>>> is wrong.
> > And that's a likely outcome in the real world.
> >
> >>> Ok. How about this?
> >> Any comments?
> > What about this instead:
> 
> Unfortunately arm64 doesn't have SMP_ON_UP. 

And why does that matter?

> It sounds like you preferred the first patch using num_possible_cpus()

Probably, yes.  I didn't follow the early conversation though.


Nicolas


From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 17 18:54:22 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Thu, 18 Jul 2013 00:54:22 +0200
Subject: [PATCH v2 2/4] pwm: Use the DT macro directly when parsing PWM DT
 flags
In-Reply-To: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374101664-21112-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Don't redefine a PWM_SPEC_POLARITY macro with a value identical to
PWM_POLARITY_INVERTED, use the PWM DT macro directly.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pwm/core.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index dfbfbc5..2ca9504 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -30,10 +30,9 @@
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
 
-#define MAX_PWMS 1024
+#include <dt-bindings/pwm/pwm.h>
 
-/* flags in the third cell of the DT PWM specifier */
-#define PWM_SPEC_POLARITY	(1 << 0)
+#define MAX_PWMS 1024
 
 static DEFINE_MUTEX(pwm_lookup_lock);
 static LIST_HEAD(pwm_lookup_list);
@@ -149,7 +148,7 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args)
 
 	pwm_set_period(pwm, args->args[1]);
 
-	if (args->args[2] & PWM_SPEC_POLARITY)
+	if (args->args[2] & PWM_POLARITY_INVERTED)
 		pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
 	else
 		pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 17 18:54:23 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Thu, 18 Jul 2013 00:54:23 +0200
Subject: [PATCH v2 3/4] pwm: Update DT bindings to reference pwm.txt for cells
 documentation
In-Reply-To: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374101664-21112-4-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The PWM client cells format is documented in the generic pwm.txt
documentation and duplicated in all PWM driver bindings. Remove
duplicate information and reference pwm.txt instead.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt      |  8 +++-----
 Documentation/devicetree/bindings/pwm/imx-pwm.txt            |  4 ++--
 Documentation/devicetree/bindings/pwm/mxs-pwm.txt            |  4 ++--
 Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt |  5 ++---
 Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt    |  4 ++--
 Documentation/devicetree/bindings/pwm/pwm-samsung.txt        | 10 +++-------
 Documentation/devicetree/bindings/pwm/pwm-tiecap.txt         |  8 +++-----
 Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt       |  8 +++-----
 Documentation/devicetree/bindings/pwm/spear-pwm.txt          |  5 ++---
 Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt         |  4 ++--
 Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt      |  4 ++--
 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt         |  8 +++-----
 12 files changed, 29 insertions(+), 43 deletions(-)

diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
index de0eaed..8031148 100644
--- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
@@ -2,11 +2,9 @@ Atmel TCB PWM controller
 
 Required properties:
 - compatible: should be "atmel,tcb-pwm"
-- #pwm-cells: Should be 3.  The first cell specifies the per-chip index
-  of the PWM to use, the second cell is the period in nanoseconds and
-  bit 0 in the third cell is used to encode the polarity of PWM output.
-  Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity &
-  set to 0 for normal polarity.
+- #pwm-cells: should be 3. See pwm.txt in this directory for a description of
+  the cells format. The only third cell flag supported by this binding is
+  PWM_POLARITY_INVERTED.
 - tc-block: The Timer Counter block to use as a PWM chip.
 
 Example:
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
index 8522bfb..b50d7a6d 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
@@ -3,8 +3,8 @@ Freescale i.MX PWM controller
 Required properties:
 - compatible: should be "fsl,<soc>-pwm"
 - reg: physical base address and length of the controller's registers
-- #pwm-cells: should be 2.  The first cell specifies the per-chip index
-  of the PWM to use and the second cell is the period in nanoseconds.
+- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
+  the cells format.
 - interrupts: The interrupt for the pwm controller
 
 Example:
diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt
index 9e3f8f1..96cdde5 100644
--- a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt
@@ -3,8 +3,8 @@ Freescale MXS PWM controller
 Required properties:
 - compatible: should be "fsl,imx23-pwm"
 - reg: physical base address and length of the controller's registers
-- #pwm-cells: should be 2.  The first cell specifies the per-chip index
-  of the PWM to use and the second cell is the period in nanoseconds.
+- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
+  the cells format.
 - fsl,pwm-number: the number of PWM devices
 
 Example:
diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
index 01438ec..c3fc57a 100644
--- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
@@ -5,9 +5,8 @@ Required properties:
   - "nvidia,tegra20-pwm"
   - "nvidia,tegra30-pwm"
 - reg: physical base address and length of the controller's registers
-- #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The
-  first cell specifies the per-chip index of the PWM to use and the second
-  cell is the period in nanoseconds.
+- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
+  the cells format.
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt b/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt
index 1e3dfe7..f84ec9d 100644
--- a/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt
@@ -3,8 +3,8 @@ NXP PCA9685 16-channel 12-bit PWM LED controller
 
 Required properties:
   - compatible: "nxp,pca9685-pwm"
-  - #pwm-cells: should be 2. The first cell specifies the per-chip index
-    of the PWM to use and the second cell is the period in nanoseconds.
+  - #pwm-cells: Should be 2. See pwm.txt in this directory for a description of
+    the cells format.
     The index 16 is the ALLCALL channel, that sets all PWM channels at the same
     time.
 
diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
index ac67c68..4caa1a7 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
@@ -19,13 +19,9 @@ Required properties:
 - reg: base address and size of register area
 - interrupts: list of timer interrupts (one interrupt per timer, starting at
   timer 0)
-- #pwm-cells: number of cells used for PWM specifier - must be 3
-   the specifier format is as follows:
-     - phandle to PWM controller node
-     - index of PWM channel (from 0 to 4)
-     - PWM signal period in nanoseconds
-     - bitmask of optional PWM flags:
-        0x1 - invert PWM signal
+- #pwm-cells: should be 3. See pwm.txt in this directory for a description of
+  the cells format. The only third cell flag supported by this binding is
+  PWM_POLARITY_INVERTED.
 
 Optional properties:
 - samsung,pwm-outputs: list of PWM channels used as PWM outputs on particular
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
index 681afad..fb81179 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
@@ -4,11 +4,9 @@ Required properties:
 - compatible: Must be "ti,<soc>-ecap".
   for am33xx - compatible = "ti,am33xx-ecap";
   for da850  - compatible = "ti,da850-ecap", "ti,am33xx-ecap";
-- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
-  First cell specifies the per-chip index of the PWM to use, the second
-  cell is the period in nanoseconds and bit 0 in the third cell is used to
-  encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
-  to 1 for inverse polarity & set to 0 for normal polarity.
+- #pwm-cells: should be 3. See pwm.txt in this directory for a description of
+  the cells format. The PWM channel index ranges from 0 to 4. The only third
+  cell flag supported by this binding is PWM_POLARITY_INVERTED.
 - reg: physical base address and size of the registers map.
 
 Optional properties:
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
index 337c6fc..9c100b2 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
@@ -4,11 +4,9 @@ Required properties:
 - compatible: Must be "ti,<soc>-ehrpwm".
   for am33xx - compatible = "ti,am33xx-ehrpwm";
   for da850  - compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
-- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
-  First cell specifies the per-chip index of the PWM to use, the second
-  cell is the period in nanoseconds and bit 0 in the third cell is used to
-  encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
-  to 1 for inverse polarity & set to 0 for normal polarity.
+- #pwm-cells: should be 3. See pwm.txt in this directory for a description of
+  the cells format. The only third cell flag supported by this binding is
+  PWM_POLARITY_INVERTED.
 - reg: physical base address and size of the registers map.
 
 Optional properties:
diff --git a/Documentation/devicetree/bindings/pwm/spear-pwm.txt b/Documentation/devicetree/bindings/pwm/spear-pwm.txt
index 3ac779d..b486de2 100644
--- a/Documentation/devicetree/bindings/pwm/spear-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/spear-pwm.txt
@@ -5,9 +5,8 @@ Required properties:
   - "st,spear320-pwm"
   - "st,spear1340-pwm"
 - reg: physical base address and length of the controller's registers
-- #pwm-cells: number of cells used to specify PWM which is fixed to 2 on
-  SPEAr. The first cell specifies the per-chip index of the PWM to use and
-  the second cell is the period in nanoseconds.
+- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
+  the cells format.
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt b/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
index 2943ee5..4e32bee 100644
--- a/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
@@ -6,8 +6,8 @@ On TWL6030 series: PWM0 and PWM1
 
 Required properties:
 - compatible: "ti,twl4030-pwm" or "ti,twl6030-pwm"
-- #pwm-cells: should be 2.  The first cell specifies the per-chip index
-  of the PWM to use and the second cell is the period in nanoseconds.
+- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
+  the cells format.
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt b/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
index cb64f3a..9f4b460 100644
--- a/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
+++ b/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
@@ -6,8 +6,8 @@ On TWL6030 series: LED PWM (mainly used as charging indicator LED)
 
 Required properties:
 - compatible: "ti,twl4030-pwmled" or "ti,twl6030-pwmled"
-- #pwm-cells: should be 2.  The first cell specifies the per-chip index
-  of the PWM to use and the second cell is the period in nanoseconds.
+- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
+  the cells format.
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
index d21d82d..a76390e 100644
--- a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
@@ -3,11 +3,9 @@ VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
 Required properties:
 - compatible: should be "via,vt8500-pwm"
 - reg: physical base address and length of the controller's registers
-- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
-  First cell specifies the per-chip index of the PWM to use, the second
-  cell is the period in nanoseconds and bit 0 in the third cell is used to
-  encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
-  to 1 for inverse polarity & set to 0 for normal polarity.
+- #pwm-cells: should be 3. See pwm.txt in this directory for a description of
+  the cells format. The only third cell flag supported by this binding is
+  PWM_POLARITY_INVERTED.
 - clocks: phandle to the PWM source clock
 
 Example:
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 17 18:54:24 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Thu, 18 Jul 2013 00:54:24 +0200
Subject: [PATCH v2 4/4] ARM: dts: Use the PWM polarity flags
In-Reply-To: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374101664-21112-5-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Replace the numerical polarity flags with the PWM_POLARITY_INVERTED
symbolic constant.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 arch/arm/boot/dts/am335x-evmsk.dts | 3 ++-
 arch/arm/boot/dts/wm8850-w70v2.dts | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 0c8ad17..62124c7 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -14,6 +14,7 @@
 /dts-v1/;
 
 #include "am33xx.dtsi"
+#include <dt-bindings/pwm/pwm.h>
 
 / {
 	model = "TI AM335x EVM-SK";
@@ -298,7 +299,7 @@
 
 	backlight {
 		compatible = "pwm-backlight";
-		pwms = <&ecap2 0 50000 1>;
+		pwms = <&ecap2 0 50000 PWM_POLARITY_INVERTED>;
 		brightness-levels = <0 58 61 66 75 90 125 170 255>;
 		default-brightness-level = <8>;
 	};
diff --git a/arch/arm/boot/dts/wm8850-w70v2.dts b/arch/arm/boot/dts/wm8850-w70v2.dts
index 90e913f..7a563d2 100644
--- a/arch/arm/boot/dts/wm8850-w70v2.dts
+++ b/arch/arm/boot/dts/wm8850-w70v2.dts
@@ -11,13 +11,14 @@
 
 /dts-v1/;
 /include/ "wm8850.dtsi"
+#include <dt-bindings/pwm/pwm.h>
 
 / {
 	model = "Wondermedia WM8850-W70v2 Tablet";
 
 	backlight {
 		compatible = "pwm-backlight";
-		pwms = <&pwm 0 50000 1>;	/* duty inverted */
+		pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
 
 		brightness-levels = <0 40 60 80 100 130 190 255>;
 		default-brightness-level = <5>;
-- 
1.8.1.5



From sboyd at codeaurora.org  Wed Jul 17 19:06:21 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 17 Jul 2013 16:06:21 -0700
Subject: [PATCH] irqchip: gic: Don't complain in gic_get_cpumask() if
 UP system
In-Reply-To: <alpine.LFD.2.03.1307171849180.14924@syhkavp.arg>
References: <1373067573-29946-1-git-send-email-sboyd@codeaurora.org>
 <20130712111322.GC3213@e102654-lin.cambridge.arm.com>
 <20130712121023.GB27430@codeaurora.org> <51E71249.4050200@codeaurora.org>
 <alpine.LFD.2.03.1307171830170.14924@syhkavp.arg>
 <51E71C78.6080604@codeaurora.org>
 <alpine.LFD.2.03.1307171849180.14924@syhkavp.arg>
Message-ID: <51E7236D.3010700@codeaurora.org>

On 07/17/13 15:53, Nicolas Pitre wrote:
> On Wed, 17 Jul 2013, Stephen Boyd wrote:
>
>> On 07/17/13 15:34, Nicolas Pitre wrote:
>>> On Wed, 17 Jul 2013, Stephen Boyd wrote:
>>>
>>>> On 07/12/13 05:10, Stephen Boyd wrote:
>>>>> On 07/12, Javi Merino wrote:
>>>>>> I agree, we should drop the check.  It's annoying in uniprocessors and
>>>>>> unlikely to be found in the real world unless your gic entry in the dt
>>>>>> is wrong.
>>> And that's a likely outcome in the real world.
>>>
>>>>> Ok. How about this?
>>>> Any comments?
>>> What about this instead:
>> Unfortunately arm64 doesn't have SMP_ON_UP. 
> And why does that matter?

Because the gic driver is compiled on both arm and arm64? I suppose we
could define is_smp() to 1 on arm64 but its probably better to rely on
generic kernel things instead of arch specific functions.

>
>> It sounds like you preferred the first patch using num_possible_cpus()
> Probably, yes.  I didn't follow the early conversation though.

This was the first patch:

---8<----

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 19ceaa6..589c760 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -368,7 +368,7 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic)
 			break;
 	}
 
-	if (!mask)
+	if (!mask && num_possible_cpus() > 1)
 		pr_crit("GIC CPU mask not found - kernel will fail to boot.\n");
 
 	return mask;


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From dinguyen at altera.com  Wed Jul 17 19:10:20 2013
From: dinguyen at altera.com (dinguyen at altera.com)
Date: Wed, 17 Jul 2013 18:10:20 -0500
Subject: [PATCH 1/4] arm: socfpga: Enable ARM_TWD for socfpga
In-Reply-To: <1374102623-4154-1-git-send-email-dinguyen@altera.com>
References: <1374102623-4154-1-git-send-email-dinguyen@altera.com>
Message-ID: <1374102623-4154-2-git-send-email-dinguyen@altera.com>

From: Dinh Nguyen <dinguyen at altera.com>

Update Kconfig to enable TWD.

Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
CC: Arnd Bergmann <arnd at arndb.de>
CC: Olof Johansson <olof at lixom.net>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Pavel Machek <pavel at denx.de>
Cc: Jack Mitchell <jack.mitchell at dbbroadcast.co.uk>
---
 arch/arm/mach-socfpga/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index dd86db4..efad818 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -11,6 +11,7 @@ config ARCH_SOCFPGA
 	select GENERIC_CLOCKEVENTS
 	select GPIO_PL061 if GPIOLIB
 	select HAVE_ARM_SCU
+	select HAVE_ARM_TWD if LOCAL_TIMERS
 	select HAVE_SMP
 	select MFD_SYSCON
 	select SPARSE_IRQ
-- 
1.7.9.5




From dinguyen at altera.com  Wed Jul 17 19:10:19 2013
From: dinguyen at altera.com (dinguyen at altera.com)
Date: Wed, 17 Jul 2013 18:10:19 -0500
Subject: [PATCH 0/4] Enable ethernet support for SOCFPGA
Message-ID: <1374102623-4154-1-git-send-email-dinguyen@altera.com>

From: Dinh Nguyen <dinguyen at altera.com>

Hello,

These 4 patches are meant to enable ethernet and SD/MMC for the SOCFPGA
platform.

patch (1/4): Adds select ARM_TWD for the platform
patch (2/4): Add platform specific initialization for the ethernet controller.
patch (3/4): Commit 25c83b5c2 added "snps,phy-addr" for getting the PHY addr.
        Set the ethernet clocks to be emac_0_clk and emac_1_clk so it be gated.
patch (4/4): Update defconfig to support SD/MMC, ethernet, EXT3 and NFS.

Thanks,

Dinh Nguyen (4):
  arm: socfpga: Enable ARM_TWD for socfpga
  arm: socfpga: Add platform initialization for ethernet
  ARM: socfpga: dts: Fix entries for the ethernet entries.
  arm: socfpga: Add support for SD/MMC and ethernet to defconfig

 arch/arm/boot/dts/socfpga.dtsi         |    4 +-
 arch/arm/boot/dts/socfpga_cyclone5.dts |    2 +-
 arch/arm/configs/socfpga_defconfig     |    8 +++
 arch/arm/mach-socfpga/Kconfig          |    1 +
 arch/arm/mach-socfpga/core.h           |    8 +++
 arch/arm/mach-socfpga/socfpga.c        |   85 +++++++++++++++++++++++++++++++-
 6 files changed, 104 insertions(+), 4 deletions(-)

CC: Arnd Bergmann <arnd at arndb.de>
CC: Olof Johansson <olof at lixom.net>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Pavel Machek <pavel at denx.de>
Cc: Jack Mitchell <jack.mitchell at dbbroadcast.co.uk>

-- 
1.7.9.5




From dinguyen at altera.com  Wed Jul 17 19:10:23 2013
From: dinguyen at altera.com (dinguyen at altera.com)
Date: Wed, 17 Jul 2013 18:10:23 -0500
Subject: [PATCH 4/4] arm: socfpga: Add support for SD/MMC and ethernet to
 defconfig
In-Reply-To: <1374102623-4154-1-git-send-email-dinguyen@altera.com>
References: <1374102623-4154-1-git-send-email-dinguyen@altera.com>
Message-ID: <1374102623-4154-5-git-send-email-dinguyen@altera.com>

From: Dinh Nguyen <dinguyen at altera.com>

Update the socfpga_defconfig to include dw_mmc driver and Micrel PHY.
Also enable EXT3 and NFS FS support.

Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
CC: Arnd Bergmann <arnd at arndb.de>
CC: Olof Johansson <olof at lixom.net>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Pavel Machek <pavel at denx.de>
Cc: Jack Mitchell <jack.mitchell at dbbroadcast.co.uk>
---
 arch/arm/configs/socfpga_defconfig |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig
index 4e1ce21..dcca3a1 100644
--- a/arch/arm/configs/socfpga_defconfig
+++ b/arch/arm/configs/socfpga_defconfig
@@ -52,6 +52,7 @@ CONFIG_BLK_DEV_SD=y
 # CONFIG_SCSI_LOWLEVEL is not set
 CONFIG_NETDEVICES=y
 CONFIG_STMMAC_ETH=y
+CONFIG_MICREL_PHY=y
 # CONFIG_STMMAC_PHY_ID_ZERO_WORKAROUND is not set
 CONFIG_INPUT_EVDEV=y
 # CONFIG_SERIO_SERPORT is not set
@@ -66,6 +67,9 @@ CONFIG_SERIAL_8250_DW=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT2_FS_POSIX_ACL=y
+CONFIG_EXT3_FS=y
+CONFIG_NFS_FS=y
+CONFIG_ROOT_NFS=y
 # CONFIG_DNOTIFY is not set
 # CONFIG_INOTIFY_USER is not set
 CONFIG_VFAT_FS=y
@@ -82,3 +86,7 @@ CONFIG_DEBUG_INFO=y
 CONFIG_ENABLE_DEFAULT_TRACERS=y
 CONFIG_DEBUG_USER=y
 CONFIG_XZ_DEC=y
+CONFIG_MMC=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_PLTFM=y
+CONFIG_MMC_DW_SOCFPGA=y
-- 
1.7.9.5




From dinguyen at altera.com  Wed Jul 17 19:10:21 2013
From: dinguyen at altera.com (dinguyen at altera.com)
Date: Wed, 17 Jul 2013 18:10:21 -0500
Subject: [PATCH 2/4] arm: socfpga: Add platform initialization for ethernet
In-Reply-To: <1374102623-4154-1-git-send-email-dinguyen@altera.com>
References: <1374102623-4154-1-git-send-email-dinguyen@altera.com>
Message-ID: <1374102623-4154-3-git-send-email-dinguyen@altera.com>

From: Dinh Nguyen <dinguyen at altera.com>

Use the PHYLIB to set the correct clock and skew values to the Micrel PHY. Add
platform specific intilization to put the STMMAC ethernet controller into the
correct PHY mode.

Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
CC: Arnd Bergmann <arnd at arndb.de>
CC: Olof Johansson <olof at lixom.net>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Pavel Machek <pavel at denx.de>
Cc: Jack Mitchell <jack.mitchell at dbbroadcast.co.uk>
---
 arch/arm/mach-socfpga/core.h    |    8 ++++
 arch/arm/mach-socfpga/socfpga.c |   85 ++++++++++++++++++++++++++++++++++++++-
 2 files changed, 92 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-socfpga/core.h b/arch/arm/mach-socfpga/core.h
index 572b8f7..505b8fe5 100644
--- a/arch/arm/mach-socfpga/core.h
+++ b/arch/arm/mach-socfpga/core.h
@@ -28,6 +28,14 @@
 #define RSTMGR_CTRL_SWCOLDRSTREQ	0x1	/* Cold Reset */
 #define RSTMGR_CTRL_SWWARMRSTREQ	0x2	/* Warm Reset */
 
+#define SYSMGR_EMACGRP_CTRL_OFFSET 0x60
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII 0x0
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII 0x1
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RMII 0x2
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_WIDTH 2
+
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_MASK 0x00000003
+
 extern void socfpga_secondary_startup(void);
 extern void __iomem *socfpga_scu_base_addr;
 
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index bfce964..abbde76 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -16,10 +16,14 @@
  */
 #include <linux/clk-provider.h>
 #include <linux/irqchip.h>
+#include <linux/micrel_phy.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <linux/of_net.h>
 #include <linux/of_platform.h>
 #include <linux/reboot.h>
+#include <linux/stmmac.h>
+#include <linux/phy.h>
 
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/mach/arch.h>
@@ -33,6 +37,22 @@ void __iomem *rst_manager_base_addr;
 void __iomem *clk_mgr_base_addr;
 unsigned long cpu1start_addr;
 
+static int stmmac_plat_init(struct platform_device *pdev);
+
+static struct plat_stmmacenet_data stmmacenet0_data = {
+	.init = &stmmac_plat_init,
+};
+
+static struct plat_stmmacenet_data stmmacenet1_data = {
+	.init = &stmmac_plat_init,
+};
+
+static const struct of_dev_auxdata socfpga_auxdata_lookup[] __initconst = {
+	OF_DEV_AUXDATA("snps,dwmac-3.70a", 0xff700000, NULL, &stmmacenet0_data),
+	OF_DEV_AUXDATA("snps,dwmac-3.70a", 0xff702000, NULL, &stmmacenet1_data),
+	{/* sentinel */}
+};
+
 static struct map_desc scu_io_desc __initdata = {
 	.virtual	= SOCFPGA_SCU_VIRT_BASE,
 	.pfn		= 0, /* run-time */
@@ -58,6 +78,65 @@ static void __init socfpga_scu_map_io(void)
 	iotable_init(&scu_io_desc, 1);
 }
 
+static int ksz9021rlrn_phy_fixup(struct phy_device *phydev)
+{
+	if (IS_BUILTIN(CONFIG_PHYLIB)) {
+		/* min rx data delay */
+		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
+			MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW | 0x8000);
+		phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
+
+		/* max rx/tx clock delay, min rx/tx control delay */
+		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
+			MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW | 0x8000);
+		phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0xa0d0);
+		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL, 0x104);
+	}
+
+	return 0;
+}
+
+static int stmmac_plat_init(struct platform_device *pdev)
+{
+	u32 ctrl, val, shift;
+	int phymode;
+
+	if (of_machine_is_compatible("altr,socfpga-vt"))
+		return 0;
+
+	phymode = of_get_phy_mode(pdev->dev.of_node);
+
+	switch (phymode) {
+	case PHY_INTERFACE_MODE_RGMII:
+		val = SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII;
+		break;
+	case PHY_INTERFACE_MODE_MII:
+	case PHY_INTERFACE_MODE_GMII:
+		val = SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII;
+		break;
+	default:
+		pr_err("%s bad phy mode %d", __func__, phymode);
+		return -EINVAL;
+	}
+
+	if (&stmmacenet1_data == pdev->dev.platform_data)
+		shift = SYSMGR_EMACGRP_CTRL_PHYSEL_WIDTH;
+	else if (&stmmacenet0_data == pdev->dev.platform_data)
+		shift = 0;
+	else {
+		pr_err("%s unexpected platform data pointer\n", __func__);
+		return -EINVAL;
+	}
+
+	ctrl = readl(sys_manager_base_addr + SYSMGR_EMACGRP_CTRL_OFFSET);
+	ctrl &= ~(SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << shift);
+	ctrl |= (val << shift);
+
+	writel(ctrl, (sys_manager_base_addr + SYSMGR_EMACGRP_CTRL_OFFSET));
+
+	return 0;
+}
+
 static void __init socfpga_map_io(void)
 {
 	socfpga_scu_map_io();
@@ -106,9 +185,13 @@ static void socfpga_cyclone5_restart(enum reboot_mode mode, const char *cmd)
 static void __init socfpga_cyclone5_init(void)
 {
 	l2x0_of_init(0, ~0UL);
-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+	of_platform_populate(NULL, of_default_bus_match_table,
+		socfpga_auxdata_lookup, NULL);
 	of_clk_init(NULL);
 	socfpga_init_clocks();
+	if (IS_BUILTIN(CONFIG_PHYLIB))
+		phy_register_fixup_for_uid(PHY_ID_KSZ9021RLRN,
+			MICREL_PHY_ID_MASK, ksz9021rlrn_phy_fixup);
 }
 
 static const char *altera_dt_match[] = {
-- 
1.7.9.5




From dinguyen at altera.com  Wed Jul 17 19:10:22 2013
From: dinguyen at altera.com (dinguyen at altera.com)
Date: Wed, 17 Jul 2013 18:10:22 -0500
Subject: [PATCH 3/4] ARM: socfpga: dts: Fix entries for the ethernet entries.
In-Reply-To: <1374102623-4154-1-git-send-email-dinguyen@altera.com>
References: <1374102623-4154-1-git-send-email-dinguyen@altera.com>
Message-ID: <1374102623-4154-4-git-send-email-dinguyen@altera.com>

From: Dinh Nguyen <dinguyen at altera.com>

Use the gate-clock emac_0_clk and emac_1_clk. Fix phy-addr binding to the
correct snps,phy-addr binding.

Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
CC: Arnd Bergmann <arnd at arndb.de>
CC: Olof Johansson <olof at lixom.net>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Pavel Machek <pavel at denx.de>
Cc: Jack Mitchell <jack.mitchell at dbbroadcast.co.uk>
---
 arch/arm/boot/dts/socfpga.dtsi         |    4 ++--
 arch/arm/boot/dts/socfpga_cyclone5.dts |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index dbf7f22..93ee655 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -444,7 +444,7 @@
 			interrupts = <0 115 4>;
 			interrupt-names = "macirq";
 			mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
-			clocks = <&emac0_clk>;
+			clocks = <&emac_0_clk>;
 			clock-names = "stmmaceth";
 			status = "disabled";
 		};
@@ -455,7 +455,7 @@
 			interrupts = <0 120 4>;
 			interrupt-names = "macirq";
 			mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
-			clocks = <&emac1_clk>;
+			clocks = <&emac_1_clk>;
 			clock-names = "stmmaceth";
 			status = "disabled";
 		};
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dts b/arch/arm/boot/dts/socfpga_cyclone5.dts
index 1853cb1..102c4d8 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dts
@@ -50,7 +50,7 @@
 
 		ethernet at ff702000 {
 			phy-mode = "rgmii";
-			phy-addr = <0xffffffff>; /* probe for phy addr */
+			snps,phy-addr = <0xffffffff>; /* probe for phy addr */
 			status = "okay";
 		};
 
-- 
1.7.9.5




From horms at verge.net.au  Wed Jul 17 19:01:13 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:01:13 +0900
Subject: [PATCH v4 1/3] ARM: shmobile: r8a7790: add Ether support
In-Reply-To: <20130717091103.GD15981@e106331-lin.cambridge.arm.com>
References: <1372663234-13486-1-git-send-email-horms+renesas@verge.net.au>
 <1372663234-13486-2-git-send-email-horms+renesas@verge.net.au>
 <20130717091103.GD15981@e106331-lin.cambridge.arm.com>
Message-ID: <20130717230113.GA8154@verge.net.au>

On Wed, Jul 17, 2013 at 10:11:03AM +0100, Mark Rutland wrote:

[snip]

> Why are we hardcoding the address and interrupt of a device rather than
> describing it in the devicetree? This is the most trivial case to
> describe.

The approach that shmobile is taking is to either initialise a device
entirely using C (non-DT) or entirely using DT. And moreover to either
initialise a board using C or DT (though in the latter case some devices
still end up being initialised in C to provide a minimally working system).

At this time for more recent boards we typically provide both a C and DT
versions to initialise a board. The C version typically is able to
initialise a fuller set of hardware while the DT version catches up.

In this case the device is being initialised in C. And this code is
intended ti be used when a board and thus its SoC is initialised using C.

Once the SH ethernet driver and all its pre-requisite drivers and
infrastructure can be initialised using DT then that will be used when
initialising the board using DT.


From hpa at zytor.com  Wed Jul 17 19:22:58 2013
From: hpa at zytor.com (H. Peter Anvin)
Date: Wed, 17 Jul 2013 16:22:58 -0700
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130717223033.GF3385@free.fr>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716004727.b60b2c96.akpm@linux-foundation.org>
 <20130716005611.e4ccab02.akpm@linux-foundation.org>
 <201307161008.07643.yann.morin.1998@free.fr>
 <20130716180408.GA19863@merkur.ravnborg.org>
 <20130717211649.GA5619@merkur.ravnborg.org> <20130717223033.GF3385@free.fr>
Message-ID: <51E72752.9020206@zytor.com>

On 07/17/2013 03:30 PM, Yann E. MORIN wrote:
> 
> At the very least we'd have to decide if this is available only for
> booleans/tristates, or for any type? Your implementation seems to make
> it valid for strings/ints, too.
> 

I feel the test should *export* a boolean.

It is worth noting that one of the things that keep getting brought up
as something that need this is gcc/binutils support for a specific feature.

	-hpa




From horms+renesas at verge.net.au  Wed Jul 17 19:31:56 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:31:56 +0900
Subject: [PATCH 17/22] ARM: shmobile: Remove redundant r8a7790 callback
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <fdbc45dbbe5a69a2c665630ab577726e01eadf23.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Replace the SoC-specific callback init_machine() with
a NULL to use the default code. This cleans up the code
and reduces the number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7790.c |    5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index d405dbd..b7e78b9 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -176,10 +176,6 @@ void __init r8a7790_timer_init(void)
 }
 
 #ifdef CONFIG_USE_OF
-void __init r8a7790_add_standard_devices_dt(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-}
 
 static const char *r8a7790_boards_compat_dt[] __initdata = {
 	"renesas,r8a7790",
@@ -187,7 +183,6 @@ static const char *r8a7790_boards_compat_dt[] __initdata = {
 };
 
 DT_MACHINE_START(R8A7790_DT, "Generic R8A7790 (Flattened Device Tree)")
-	.init_machine	= r8a7790_add_standard_devices_dt,
 	.init_time	= r8a7790_timer_init,
 	.dt_compat	= r8a7790_boards_compat_dt,
 MACHINE_END
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:32:07 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:32:07 +0900
Subject: [PATCH 06/22] ARM: shmobile: ape6evm: Remove init_irq declaration in
 machine description
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <c7f6085f6ea7b7cf155f470431cf1b12cd999450.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Remove redundant irqchip_init() callback. The default case
of NULL will result in invoking irqchip_init() anyway.

Signed-off-by: Magnus Damm <damm at opensource.se>
[ horms+renesas at verge.net.au: Trimmed patch to remove portion
  that updates the r8a73a4 SoC and altered the subject to
  use the same format as the patch that updates the r8a73a4. ]
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-ape6evm.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
index 5eb0caa..1fbc39a 100644
--- a/arch/arm/mach-shmobile/board-ape6evm.c
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -20,7 +20,6 @@
 
 #include <linux/gpio.h>
 #include <linux/interrupt.h>
-#include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/platform_device.h>
@@ -102,7 +101,6 @@ static const char *ape6evm_boards_compat_dt[] __initdata = {
 };
 
 DT_MACHINE_START(APE6EVM_DT, "ape6evm")
-	.init_irq	= irqchip_init,
 	.init_time	= shmobile_timer_init,
 	.init_machine	= ape6evm_add_standard_devices,
 	.dt_compat	= ape6evm_boards_compat_dt,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:32:08 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:32:08 +0900
Subject: [PATCH 07/22] ARM: shmobile: r8a7790: Remove init_irq declaration in
 machine description
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <125332daf2e4119614c561bc8cbf1f49cd243023.1374103272.git.horms+renesas@verge.net.au>

From: Maxime Ripard <maxime.ripard at free-electrons.com>

Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
specified") removed the need to explictly setup the init_irq field in
the machine description when using only irqchip_init. Remove that
declaration for shmobile as well.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7790.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index 28f9475..d405dbd 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -19,7 +19,6 @@
  */
 
 #include <linux/irq.h>
-#include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/of_platform.h>
 #include <linux/serial_sci.h>
@@ -188,7 +187,6 @@ static const char *r8a7790_boards_compat_dt[] __initdata = {
 };
 
 DT_MACHINE_START(R8A7790_DT, "Generic R8A7790 (Flattened Device Tree)")
-	.init_irq	= irqchip_init,
 	.init_machine	= r8a7790_add_standard_devices_dt,
 	.init_time	= r8a7790_timer_init,
 	.dt_compat	= r8a7790_boards_compat_dt,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:31:57 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:31:57 +0900
Subject: [PATCH 18/22] ARM: shmobile: Remove unused EMEV2/KZM9D early console
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <4146fa8861419ac0d2c3607168339621586f6c03.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Remove EMEV2 early console code from KZM9D and instead
rely on console setup during regular platform device
probe time. This makes the DT code and the KZM9D board
support behave the same.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-kzm9d.c        |    2 +-
 arch/arm/mach-shmobile/include/mach/emev2.h |    2 +-
 arch/arm/mach-shmobile/setup-emev2.c        |   24 +++---------------------
 3 files changed, 5 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-kzm9d.c b/arch/arm/mach-shmobile/board-kzm9d.c
index 4368000..15900f1 100644
--- a/arch/arm/mach-shmobile/board-kzm9d.c
+++ b/arch/arm/mach-shmobile/board-kzm9d.c
@@ -85,7 +85,7 @@ static const char *kzm9d_boards_compat_dt[] __initdata = {
 DT_MACHINE_START(KZM9D_DT, "kzm9d")
 	.smp		= smp_ops(emev2_smp_ops),
 	.map_io		= emev2_map_io,
-	.init_early	= emev2_add_early_devices,
+	.init_early	= emev2_init_delay,
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= emev2_init_irq,
 	.init_machine	= kzm9d_add_standard_devices,
diff --git a/arch/arm/mach-shmobile/include/mach/emev2.h b/arch/arm/mach-shmobile/include/mach/emev2.h
index ac37517..3e0c044 100644
--- a/arch/arm/mach-shmobile/include/mach/emev2.h
+++ b/arch/arm/mach-shmobile/include/mach/emev2.h
@@ -3,7 +3,7 @@
 
 extern void emev2_map_io(void);
 extern void emev2_init_irq(void);
-extern void emev2_add_early_devices(void);
+extern void emev2_init_delay(void);
 extern void emev2_add_standard_devices(void);
 extern void emev2_clock_init(void);
 extern void emev2_set_boot_vector(unsigned long value);
diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
index b0564ce..f6edd19 100644
--- a/arch/arm/mach-shmobile/setup-emev2.c
+++ b/arch/arm/mach-shmobile/setup-emev2.c
@@ -375,14 +375,11 @@ static struct platform_device pmu_device = {
 	.resource	= pmu_resources,
 };
 
-static struct platform_device *emev2_early_devices[] __initdata = {
+static struct platform_device *emev2_devices[] __initdata = {
 	&uart0_device,
 	&uart1_device,
 	&uart2_device,
 	&uart3_device,
-};
-
-static struct platform_device *emev2_late_devices[] __initdata = {
 	&sti_device,
 	&gio0_device,
 	&gio1_device,
@@ -396,29 +393,14 @@ void __init emev2_add_standard_devices(void)
 {
 	emev2_clock_init();
 
-	platform_add_devices(emev2_early_devices,
-			     ARRAY_SIZE(emev2_early_devices));
-
-	platform_add_devices(emev2_late_devices,
-			     ARRAY_SIZE(emev2_late_devices));
+	platform_add_devices(emev2_devices, ARRAY_SIZE(emev2_devices));
 }
 
-static void __init emev2_init_delay(void)
+void __init emev2_init_delay(void)
 {
 	shmobile_setup_delay(533, 1, 3); /* Cortex-A9 @ 533MHz */
 }
 
-void __init emev2_add_early_devices(void)
-{
-	emev2_init_delay();
-
-	early_platform_add_devices(emev2_early_devices,
-				   ARRAY_SIZE(emev2_early_devices));
-
-	/* setup early console here as well */
-	shmobile_setup_console();
-}
-
 void __init emev2_init_irq(void)
 {
 	void __iomem *gic_dist_base;
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:31:58 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:31:58 +0900
Subject: [PATCH 19/22] ARM: shmobile: Make EMEV2 platform devices more compact
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <210e179da2e39c965872b941a36e55ab78328e49.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Convert the EMEV2 SoC device setup code from using very
verbose resources and static platform devices to the
same style as more recent boards. This reduces the size
of the code.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-emev2.c |  321 +++++++---------------------------
 1 file changed, 61 insertions(+), 260 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
index f6edd19..e4b4693 100644
--- a/arch/arm/mach-shmobile/setup-emev2.c
+++ b/arch/arm/mach-shmobile/setup-emev2.c
@@ -62,102 +62,40 @@ void __init emev2_map_io(void)
 
 /* UART */
 static struct resource uart0_resources[] = {
-	[0]	= {
-		.start	= 0xe1020000,
-		.end	= 0xe1020037,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1]	= {
-		.start	= 40,
-		.flags	= IORESOURCE_IRQ,
-	}
-};
-
-static struct platform_device uart0_device = {
-	.name		= "serial8250-em",
-	.id		= 0,
-	.num_resources	= ARRAY_SIZE(uart0_resources),
-	.resource	= uart0_resources,
+	DEFINE_RES_MEM(0xe1020000, 0x38),
+	DEFINE_RES_IRQ(40),
 };
 
 static struct resource uart1_resources[] = {
-	[0]	= {
-		.start	= 0xe1030000,
-		.end	= 0xe1030037,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1]	= {
-		.start	= 41,
-		.flags	= IORESOURCE_IRQ,
-	}
-};
-
-static struct platform_device uart1_device = {
-	.name		= "serial8250-em",
-	.id		= 1,
-	.num_resources	= ARRAY_SIZE(uart1_resources),
-	.resource	= uart1_resources,
+	DEFINE_RES_MEM(0xe1030000, 0x38),
+	DEFINE_RES_IRQ(41),
 };
 
 static struct resource uart2_resources[] = {
-	[0]	= {
-		.start	= 0xe1040000,
-		.end	= 0xe1040037,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1]	= {
-		.start	= 42,
-		.flags	= IORESOURCE_IRQ,
-	}
-};
-
-static struct platform_device uart2_device = {
-	.name		= "serial8250-em",
-	.id		= 2,
-	.num_resources	= ARRAY_SIZE(uart2_resources),
-	.resource	= uart2_resources,
+	DEFINE_RES_MEM(0xe1040000, 0x38),
+	DEFINE_RES_IRQ(42),
 };
 
 static struct resource uart3_resources[] = {
-	[0]	= {
-		.start	= 0xe1050000,
-		.end	= 0xe1050037,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1]	= {
-		.start	= 43,
-		.flags	= IORESOURCE_IRQ,
-	}
+	DEFINE_RES_MEM(0xe1050000, 0x38),
+	DEFINE_RES_IRQ(43),
 };
 
-static struct platform_device uart3_device = {
-	.name		= "serial8250-em",
-	.id		= 3,
-	.num_resources	= ARRAY_SIZE(uart3_resources),
-	.resource	= uart3_resources,
-};
+#define emev2_register_uart(idx)					\
+	platform_device_register_simple("serial8250-em", idx,		\
+					uart##idx##_resources,		\
+					ARRAY_SIZE(uart##idx##_resources))
 
 /* STI */
 static struct resource sti_resources[] = {
-	[0] = {
-		.name	= "STI",
-		.start	= 0xe0180000,
-		.end	= 0xe0180053,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= 157,
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device sti_device = {
-	.name		= "em_sti",
-	.id		= 0,
-	.resource	= sti_resources,
-	.num_resources	= ARRAY_SIZE(sti_resources),
+	DEFINE_RES_MEM(0xe0180000, 0x54),
+	DEFINE_RES_IRQ(157),
 };
 
+#define emev2_register_sti()					\
+	platform_device_register_simple("em_sti", 0,		\
+					sti_resources,		\
+					ARRAY_SIZE(sti_resources))
 
 /* GIO */
 static struct gpio_em_config gio0_config = {
@@ -167,36 +105,10 @@ static struct gpio_em_config gio0_config = {
 };
 
 static struct resource gio0_resources[] = {
-	[0] = {
-		.name	= "GIO_000",
-		.start	= 0xe0050000,
-		.end	= 0xe005002b,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.name	= "GIO_000",
-		.start	= 0xe0050040,
-		.end	= 0xe005005f,
-		.flags	= IORESOURCE_MEM,
-	},
-	[2] = {
-		.start	= 99,
-		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
-		.start	= 100,
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device gio0_device = {
-	.name		= "em_gio",
-	.id		= 0,
-	.resource	= gio0_resources,
-	.num_resources	= ARRAY_SIZE(gio0_resources),
-	.dev		= {
-		.platform_data	= &gio0_config,
-	},
+	DEFINE_RES_MEM(0xe0050000, 0x2c),
+	DEFINE_RES_MEM(0xe0050040, 0x20),
+	DEFINE_RES_IRQ(99),
+	DEFINE_RES_IRQ(100),
 };
 
 static struct gpio_em_config gio1_config = {
@@ -206,36 +118,10 @@ static struct gpio_em_config gio1_config = {
 };
 
 static struct resource gio1_resources[] = {
-	[0] = {
-		.name	= "GIO_032",
-		.start	= 0xe0050080,
-		.end	= 0xe00500ab,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.name	= "GIO_032",
-		.start	= 0xe00500c0,
-		.end	= 0xe00500df,
-		.flags	= IORESOURCE_MEM,
-	},
-	[2] = {
-		.start	= 101,
-		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
-		.start	= 102,
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device gio1_device = {
-	.name		= "em_gio",
-	.id		= 1,
-	.resource	= gio1_resources,
-	.num_resources	= ARRAY_SIZE(gio1_resources),
-	.dev		= {
-		.platform_data	= &gio1_config,
-	},
+	DEFINE_RES_MEM(0xe0050080, 0x2c),
+	DEFINE_RES_MEM(0xe00500c0, 0x20),
+	DEFINE_RES_IRQ(101),
+	DEFINE_RES_IRQ(102),
 };
 
 static struct gpio_em_config gio2_config = {
@@ -245,36 +131,10 @@ static struct gpio_em_config gio2_config = {
 };
 
 static struct resource gio2_resources[] = {
-	[0] = {
-		.name	= "GIO_064",
-		.start	= 0xe0050100,
-		.end	= 0xe005012b,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.name	= "GIO_064",
-		.start	= 0xe0050140,
-		.end	= 0xe005015f,
-		.flags	= IORESOURCE_MEM,
-	},
-	[2] = {
-		.start	= 103,
-		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
-		.start	= 104,
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device gio2_device = {
-	.name		= "em_gio",
-	.id		= 2,
-	.resource	= gio2_resources,
-	.num_resources	= ARRAY_SIZE(gio2_resources),
-	.dev		= {
-		.platform_data	= &gio2_config,
-	},
+	DEFINE_RES_MEM(0xe0050100, 0x2c),
+	DEFINE_RES_MEM(0xe0050140, 0x20),
+	DEFINE_RES_IRQ(103),
+	DEFINE_RES_IRQ(104),
 };
 
 static struct gpio_em_config gio3_config = {
@@ -284,36 +144,10 @@ static struct gpio_em_config gio3_config = {
 };
 
 static struct resource gio3_resources[] = {
-	[0] = {
-		.name	= "GIO_096",
-		.start	= 0xe0050180,
-		.end	= 0xe00501ab,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.name	= "GIO_096",
-		.start	= 0xe00501c0,
-		.end	= 0xe00501df,
-		.flags	= IORESOURCE_MEM,
-	},
-	[2] = {
-		.start	= 105,
-		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
-		.start	= 106,
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device gio3_device = {
-	.name		= "em_gio",
-	.id		= 3,
-	.resource	= gio3_resources,
-	.num_resources	= ARRAY_SIZE(gio3_resources),
-	.dev		= {
-		.platform_data	= &gio3_config,
-	},
+	DEFINE_RES_MEM(0xe0050180, 0x2c),
+	DEFINE_RES_MEM(0xe00501c0, 0x20),
+	DEFINE_RES_IRQ(105),
+	DEFINE_RES_IRQ(106),
 };
 
 static struct gpio_em_config gio4_config = {
@@ -323,77 +157,44 @@ static struct gpio_em_config gio4_config = {
 };
 
 static struct resource gio4_resources[] = {
-	[0] = {
-		.name	= "GIO_128",
-		.start	= 0xe0050200,
-		.end	= 0xe005022b,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.name	= "GIO_128",
-		.start	= 0xe0050240,
-		.end	= 0xe005025f,
-		.flags	= IORESOURCE_MEM,
-	},
-	[2] = {
-		.start	= 107,
-		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
-		.start	= 108,
-		.flags	= IORESOURCE_IRQ,
-	},
+	DEFINE_RES_MEM(0xe0050200, 0x2c),
+	DEFINE_RES_MEM(0xe0050240, 0x20),
+	DEFINE_RES_IRQ(107),
+	DEFINE_RES_IRQ(108),
 };
 
-static struct platform_device gio4_device = {
-	.name		= "em_gio",
-	.id		= 4,
-	.resource	= gio4_resources,
-	.num_resources	= ARRAY_SIZE(gio4_resources),
-	.dev		= {
-		.platform_data	= &gio4_config,
-	},
-};
+#define emev2_register_gio(idx)						\
+	platform_device_register_resndata(&platform_bus, "em_gio",	\
+					  idx, gio##idx##_resources,	\
+					  ARRAY_SIZE(gio##idx##_resources), \
+					  &gio##idx##_config,		\
+					  sizeof(struct gpio_em_config))
 
 static struct resource pmu_resources[] = {
-	[0] = {
-		.start	= 152,
-		.end	= 152,
-		.flags	= IORESOURCE_IRQ,
-	},
-	[1] = {
-		.start	= 153,
-		.end	= 153,
-		.flags	= IORESOURCE_IRQ,
-	},
+	DEFINE_RES_IRQ(152),
+	DEFINE_RES_IRQ(153),
 };
 
-static struct platform_device pmu_device = {
-	.name		= "arm-pmu",
-	.id		= -1,
-	.num_resources	= ARRAY_SIZE(pmu_resources),
-	.resource	= pmu_resources,
-};
-
-static struct platform_device *emev2_devices[] __initdata = {
-	&uart0_device,
-	&uart1_device,
-	&uart2_device,
-	&uart3_device,
-	&sti_device,
-	&gio0_device,
-	&gio1_device,
-	&gio2_device,
-	&gio3_device,
-	&gio4_device,
-	&pmu_device,
-};
+#define emev2_register_pmu()					\
+	platform_device_register_simple("arm-pmu", -1,		\
+					pmu_resources,		\
+					ARRAY_SIZE(pmu_resources))
 
 void __init emev2_add_standard_devices(void)
 {
 	emev2_clock_init();
 
-	platform_add_devices(emev2_devices, ARRAY_SIZE(emev2_devices));
+	emev2_register_uart(0);
+	emev2_register_uart(1);
+	emev2_register_uart(2);
+	emev2_register_uart(3);
+	emev2_register_sti();
+	emev2_register_gio(0);
+	emev2_register_gio(1);
+	emev2_register_gio(2);
+	emev2_register_gio(3);
+	emev2_register_gio(4);
+	emev2_register_pmu();
 }
 
 void __init emev2_init_delay(void)
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:32:10 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:32:10 +0900
Subject: [PATCH 09/22] ARM: shmobile: sh73a0: Remove init_irq declaration in
 machine description
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <7d6b8883547feacc705c476cdb7f272e309d9fb0.1374103272.git.horms+renesas@verge.net.au>

From: Maxime Ripard <maxime.ripard at free-electrons.com>

Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
specified") removed the need to explictly setup the init_irq field in
the machine description when using only irqchip_init. Remove that
declaration for shmobile as well.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-sh73a0.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
index 79a6040..bd9370f 100644
--- a/arch/arm/mach-shmobile/setup-sh73a0.c
+++ b/arch/arm/mach-shmobile/setup-sh73a0.c
@@ -22,7 +22,6 @@
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
-#include <linux/irqchip.h>
 #include <linux/platform_device.h>
 #include <linux/of_platform.h>
 #include <linux/delay.h>
@@ -975,7 +974,6 @@ DT_MACHINE_START(SH73A0_DT, "Generic SH73A0 (Flattened Device Tree)")
 	.map_io		= sh73a0_map_io,
 	.init_early	= sh73a0_init_delay,
 	.nr_irqs	= NR_IRQS_LEGACY,
-	.init_irq	= irqchip_init,
 	.init_machine	= sh73a0_add_standard_devices_dt,
 	.dt_compat	= sh73a0_boards_compat_dt,
 MACHINE_END
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:31:50 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:31:50 +0900
Subject: [PATCH 11/22] ARM: shmobile: Remove unused EMEV2 auxdata and callback
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <a597d8df88143f7a409b260b1e89735eb0bdca05.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Replace the SoC-specific callback init_machine() with
a NULL to use the default code. This cleans up the code
and reduces the number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-emev2.c |   10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
index 6e8b6ac..b0564ce 100644
--- a/arch/arm/mach-shmobile/setup-emev2.c
+++ b/arch/arm/mach-shmobile/setup-emev2.c
@@ -434,15 +434,6 @@ void __init emev2_init_irq(void)
 }
 
 #ifdef CONFIG_USE_OF
-static const struct of_dev_auxdata emev2_auxdata_lookup[] __initconst = {
-	{ }
-};
-
-static void __init emev2_add_standard_devices_dt(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table,
-			     emev2_auxdata_lookup, NULL);
-}
 
 static const char *emev2_boards_compat_dt[] __initdata = {
 	"renesas,emev2",
@@ -453,7 +444,6 @@ DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
 	.smp		= smp_ops(emev2_smp_ops),
 	.init_early	= emev2_init_delay,
 	.nr_irqs	= NR_IRQS_LEGACY,
-	.init_machine	= emev2_add_standard_devices_dt,
 	.dt_compat	= emev2_boards_compat_dt,
 MACHINE_END
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:31:51 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:31:51 +0900
Subject: [PATCH 12/22] ARM: shmobile: Remove unused r8a7740 auxdata table
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <88378837780166d67a11142cd6f76596c0a2d8c3.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Pass NULL to of_platform_populate instead of passing
an empty list. This cleans up the code and reduces the
number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7740.c |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 00c5a70..ac29c2e 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -986,16 +986,22 @@ void __init r8a7740_add_early_devices(void)
 
 #ifdef CONFIG_USE_OF
 
-static const struct of_dev_auxdata r8a7740_auxdata_lookup[] __initconst = {
-	{ }
-};
+void __init r8a7740_add_early_devices_dt(void)
+{
+	shmobile_setup_delay(800, 1, 3); /* Cortex-A9 @ 800MHz */
+
+	early_platform_add_devices(r8a7740_early_devices,
+				   ARRAY_SIZE(r8a7740_early_devices));
+
+	/* setup early console here as well */
+	shmobile_setup_console();
+}
 
 void __init r8a7740_add_standard_devices_dt(void)
 {
 	platform_add_devices(r8a7740_devices_dt,
 			    ARRAY_SIZE(r8a7740_devices_dt));
-	of_platform_populate(NULL, of_default_bus_match_table,
-			     r8a7740_auxdata_lookup, NULL);
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
 void __init r8a7740_init_delay(void)
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:32:09 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:32:09 +0900
Subject: [PATCH 08/22] ARM: shmobile: lager: Remove init_irq declaration in
 machine description
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <5f85052c606e38c98de28170a2df72f78931aa30.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Remove redundant irqchip_init() callback. The default case
of NULL will result in invoking irqchip_init() anyway.

Signed-off-by: Magnus Damm <damm at opensource.se>
[ horms+renesas at verge.net.au: Trimmed patch to remove portion
  that updates the r8a7790 SoC and altered the subject to
  use the same format as the patch that updates the r8a7790. ]
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-lager.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index d73e21d..1e99b17 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -22,7 +22,6 @@
 #include <linux/gpio_keys.h>
 #include <linux/input.h>
 #include <linux/interrupt.h>
-#include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/leds.h>
 #include <linux/pinctrl/machine.h>
@@ -103,7 +102,6 @@ static const char *lager_boards_compat_dt[] __initdata = {
 };
 
 DT_MACHINE_START(LAGER_DT, "lager")
-	.init_irq	= irqchip_init,
 	.init_time	= r8a7790_timer_init,
 	.init_machine	= lager_add_standard_devices,
 	.dt_compat	= lager_boards_compat_dt,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:31:55 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:31:55 +0900
Subject: [PATCH 16/22] ARM: shmobile: Remove unused sh73a0 auxdata table
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <ea31597fe72245985e9d2521ea7e87acf2f14252.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Pass NULL to of_platform_populate instead of passing
an empty list. This cleans up the code and reduces the
number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-sh73a0.c |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
index bd9370f..516c239 100644
--- a/arch/arm/mach-shmobile/setup-sh73a0.c
+++ b/arch/arm/mach-shmobile/setup-sh73a0.c
@@ -944,10 +944,6 @@ void __init sh73a0_add_early_devices(void)
 
 #ifdef CONFIG_USE_OF
 
-static const struct of_dev_auxdata sh73a0_auxdata_lookup[] __initconst = {
-	{},
-};
-
 void __init sh73a0_add_standard_devices_dt(void)
 {
 	struct platform_device_info devinfo = { .name = "cpufreq-cpu0", .id = -1, };
@@ -957,8 +953,7 @@ void __init sh73a0_add_standard_devices_dt(void)
 
 	platform_add_devices(sh73a0_devices_dt,
 			     ARRAY_SIZE(sh73a0_devices_dt));
-	of_platform_populate(NULL, of_default_bus_match_table,
-			     sh73a0_auxdata_lookup, NULL);
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 
 	/* Instantiate cpufreq-cpu0 */
 	platform_device_register_full(&devinfo);
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:31:54 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:31:54 +0900
Subject: [PATCH 15/22] ARM: shmobile: Remove unused sh7372 auxdata table
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <975e5af958916f8b76a8926cd4d50c04936d7079.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Pass NULL to of_platform_populate instead of passing
an empty list. This cleans up the code and reduces the
number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-sh7372.c |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-sh7372.c b/arch/arm/mach-shmobile/setup-sh7372.c
index 5502d62..13e6fdb 100644
--- a/arch/arm/mach-shmobile/setup-sh7372.c
+++ b/arch/arm/mach-shmobile/setup-sh7372.c
@@ -1147,10 +1147,6 @@ void __init sh7372_add_early_devices_dt(void)
 	shmobile_setup_console();
 }
 
-static const struct of_dev_auxdata sh7372_auxdata_lookup[] __initconst = {
-	{ }
-};
-
 void __init sh7372_add_standard_devices_dt(void)
 {
 	/* clocks are setup late during boot in the case of DT */
@@ -1159,8 +1155,7 @@ void __init sh7372_add_standard_devices_dt(void)
 	platform_add_devices(sh7372_early_devices,
 			    ARRAY_SIZE(sh7372_early_devices));
 
-	of_platform_populate(NULL, of_default_bus_match_table,
-			     sh7372_auxdata_lookup, NULL);
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
 static const char *sh7372_boards_compat_dt[] __initdata = {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:31:49 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:31:49 +0900
Subject: [PATCH 10/22] ARM: shmobile: kzm9g: Remove init_irq declaration in
 machine description
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <fc492ba58aa6642f34eba716daf6ec4d2715e492.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Remove redundant irqchip_init() callback. The default case
of NULL will result in invoking irqchip_init() anyway.

Signed-off-by: Magnus Damm <damm at opensource.se>
[ horms+renesas at verge.net.au: Trimmed patch to remove portion
  that updates the sh73a0 SoC and altered the subject to
  use the same format as the patch that updates the sh73a0. ]
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-kzm9g-reference.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index 44055fe..41092bb 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -24,7 +24,6 @@
 #include <linux/gpio.h>
 #include <linux/io.h>
 #include <linux/irq.h>
-#include <linux/irqchip.h>
 #include <linux/input.h>
 #include <linux/of_platform.h>
 #include <linux/pinctrl/machine.h>
@@ -99,7 +98,6 @@ DT_MACHINE_START(KZM9G_DT, "kzm9g-reference")
 	.map_io		= sh73a0_map_io,
 	.init_early	= sh73a0_init_delay,
 	.nr_irqs	= NR_IRQS_LEGACY,
-	.init_irq	= irqchip_init,
 	.init_machine	= kzm_init,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= kzm9g_boards_compat_dt,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:31:52 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:31:52 +0900
Subject: [PATCH 13/22] ARM: shmobile: Remove unused r8a7778 auxdata and
 callback
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <40216263d3d0b9b46688a28a96daf66fe75caa28.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Replace the SoC-specific callback init_machine() with
a NULL to use the default code. This cleans up the code
and reduces the number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7778.c |   11 -----------
 1 file changed, 11 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c
index b70bfee..2a101eb 100644
--- a/arch/arm/mach-shmobile/setup-r8a7778.c
+++ b/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -457,16 +457,6 @@ void __init r8a7778_init_irq_dt(void)
 	r8a7778_init_irq_common();
 }
 
-static const struct of_dev_auxdata r8a7778_auxdata_lookup[] __initconst = {
-	{},
-};
-
-void __init r8a7778_add_standard_devices_dt(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table,
-			     r8a7778_auxdata_lookup, NULL);
-}
-
 static const char *r8a7778_compat_dt[] __initdata = {
 	"renesas,r8a7778",
 	NULL,
@@ -475,7 +465,6 @@ static const char *r8a7778_compat_dt[] __initdata = {
 DT_MACHINE_START(R8A7778_DT, "Generic R8A7778 (Flattened Device Tree)")
 	.init_early	= r8a7778_init_delay,
 	.init_irq	= r8a7778_init_irq_dt,
-	.init_machine	= r8a7778_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a7778_compat_dt,
 	.init_late      = r8a7778_init_late,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:31:53 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:31:53 +0900
Subject: [PATCH 14/22] ARM: shmobile: Remove unused r8a7779 auxdata table
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <41b0156ca5a1460f8f6dde7e57baf1b80d6a7030.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Pass NULL to of_platform_populate instead of passing
an empty list. This cleans up the code and reduces the
number of lines.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7779.c |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c
index 3986877..66d3826 100644
--- a/arch/arm/mach-shmobile/setup-r8a7779.c
+++ b/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -665,10 +665,6 @@ void __init r8a7779_init_delay(void)
 	shmobile_setup_delay(1000, 2, 4); /* Cortex-A9 @ 1000MHz */
 }
 
-static const struct of_dev_auxdata r8a7779_auxdata_lookup[] __initconst = {
-	{},
-};
-
 void __init r8a7779_add_standard_devices_dt(void)
 {
 	/* clocks are setup late during boot in the case of DT */
@@ -676,8 +672,7 @@ void __init r8a7779_add_standard_devices_dt(void)
 
 	platform_add_devices(r8a7779_devices_dt,
 			     ARRAY_SIZE(r8a7779_devices_dt));
-	of_platform_populate(NULL, of_default_bus_match_table,
-			     r8a7779_auxdata_lookup, NULL);
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
 static const char *r8a7779_compat_dt[] __initdata = {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:32:02 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:32:02 +0900
Subject: [PATCH 01/22] ARM: shmobile: armadillo800eva: remove left-overs
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <bcfed2a8a61a0f6ee7769f5093a8279a9e50c526.1374103272.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

A comment and a #define in board-armadillo800eva.c have been left over
after recent changes and are no longer relevant or needed, remove them.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-armadillo800eva.c |    9 ---------
 1 file changed, 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index e115f67..66cfd56 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -679,15 +679,6 @@ static struct platform_device vcc_sdhi1 = {
 };
 
 /* SDHI0 */
-/*
- * FIXME
- *
- * It use polling mode here, since
- * CD (= Card Detect) pin is not connected to SDHI0_CD.
- * We can use IRQ31 as card detect irq,
- * but it needs chattering removal operation
- */
-#define IRQ31	irq_pin(31)
 static struct sh_mobile_sdhi_info sdhi0_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI0_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI0_RX,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:32:05 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:32:05 +0900
Subject: [PATCH 04/22] ARM: shmobile: emev2: Remove init_irq declaration in
 machine description
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <34dd9fc04a028edad7658006764c4d18ac3dca73.1374103272.git.horms+renesas@verge.net.au>

From: Maxime Ripard <maxime.ripard at free-electrons.com>

Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
specified") removed the need to explictly setup the init_irq field in
the machine description when using only irqchip_init. Remove that
declaration for shmobile as well.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-emev2.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
index 1ccddd2..6e8b6ac 100644
--- a/arch/arm/mach-shmobile/setup-emev2.c
+++ b/arch/arm/mach-shmobile/setup-emev2.c
@@ -20,7 +20,6 @@
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
-#include <linux/irqchip.h>
 #include <linux/platform_device.h>
 #include <linux/platform_data/gpio-em.h>
 #include <linux/of_platform.h>
@@ -454,7 +453,6 @@ DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
 	.smp		= smp_ops(emev2_smp_ops),
 	.init_early	= emev2_init_delay,
 	.nr_irqs	= NR_IRQS_LEGACY,
-	.init_irq	= irqchip_init,
 	.init_machine	= emev2_add_standard_devices_dt,
 	.dt_compat	= emev2_boards_compat_dt,
 MACHINE_END
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:32:04 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:32:04 +0900
Subject: [PATCH 03/22] ARM: shmobile: sh73a0 pinmux platform device cleanup
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <474f67587345bf7b32bbd9d2b5621e85500103c5.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Use DEFINE_RES_MEM() and platform_device_register_simple()
to save a couple of lines of code.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
[ remove const from resource pfc_resources to avoid section miss-match
  reported by 4.4.5 ]
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-sh73a0.c |   25 ++++++-------------------
 1 file changed, 6 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-sh73a0.c b/arch/arm/mach-shmobile/setup-sh73a0.c
index 96e7ca1..79a6040 100644
--- a/arch/arm/mach-shmobile/setup-sh73a0.c
+++ b/arch/arm/mach-shmobile/setup-sh73a0.c
@@ -61,29 +61,16 @@ void __init sh73a0_map_io(void)
 	iotable_init(sh73a0_io_desc, ARRAY_SIZE(sh73a0_io_desc));
 }
 
-static struct resource sh73a0_pfc_resources[] = {
-	[0] = {
-		.start	= 0xe6050000,
-		.end	= 0xe6057fff,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= 0xe605801c,
-		.end	= 0xe6058027,
-		.flags	= IORESOURCE_MEM,
-	}
-};
-
-static struct platform_device sh73a0_pfc_device = {
-	.name		= "pfc-sh73a0",
-	.id		= -1,
-	.resource	= sh73a0_pfc_resources,
-	.num_resources	= ARRAY_SIZE(sh73a0_pfc_resources),
+/* PFC */
+static struct resource pfc_resources[] __initdata = {
+	DEFINE_RES_MEM(0xe6050000, 0x8000),
+	DEFINE_RES_MEM(0xe605801c, 0x000c),
 };
 
 void __init sh73a0_pinmux_init(void)
 {
-	platform_device_register(&sh73a0_pfc_device);
+	platform_device_register_simple("pfc-sh73a0", -1, pfc_resources,
+					ARRAY_SIZE(pfc_resources));
 }
 
 static struct plat_sci_port scif0_platform_data = {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:30:15 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:30:15 +0900
Subject: [GIT 00/22] Renesas ARM based SoC cleanups for v3.12
Message-ID: <cover.1374103272.git.horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

please consider the following cleanups for v3.12.

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-cleanup-for-v3.12

for you to fetch changes up to ebd9616f439a8a46b9dca9a272b342f34c5f3614:

  ARM: shmobile: Remove unused mach/dma.h (2013-07-17 10:02:30 +0900)

----------------------------------------------------------------
renesas-cleanup-for-v3.12 Renesas ARM based SoC cleanups for v3.12

* remove mach/dma.h, it is not used
* r8a7778 SoC: Removed unused r8a7778_init_irq
* emev2 SoC: Use less verbose resource declarations
* emev2 SoC: Correct typo in comment
* r8a7790 SoC: Remove redundant init_machine callback
* emev2, r8a7740, r8a7778, r8a7779, sh7372 and sh73a0 SoCs: Remove auxdata
* emev2, r8a73a4, ape6evm, r8a7790 and sh73a0 SoCs, and
  lager and kzm9g boards: remove init_irq declaration in machine description
* sh73a0 SoC: pinmux platform device cleanup
* r8a7778 SoC: add __initdata on resource and device data
* armadillo800eva board: Remove unused commend and define

----------------------------------------------------------------
Guennadi Liakhovetski (1):
      ARM: shmobile: armadillo800eva: remove left-overs

Kuninori Morimoto (2):
      ARM: shmobile: r8a7778: add __initdata on resource and device data
      ARM: shmobile: r8a7778: remove r8a7778_init_irq()

Magnus Damm (15):
      ARM: shmobile: sh73a0 pinmux platform device cleanup
      ARM: shmobile: ape6evm: Remove init_irq declaration in machine description
      ARM: shmobile: lager: Remove init_irq declaration in machine description
      ARM: shmobile: kzm9g: Remove init_irq declaration in machine description
      ARM: shmobile: Remove unused EMEV2 auxdata and callback
      ARM: shmobile: Remove unused r8a7740 auxdata table
      ARM: shmobile: Remove unused r8a7778 auxdata and callback
      ARM: shmobile: Remove unused r8a7779 auxdata table
      ARM: shmobile: Remove unused sh7372 auxdata table
      ARM: shmobile: Remove unused sh73a0 auxdata table
      ARM: shmobile: Remove redundant r8a7790 callback
      ARM: shmobile: Remove unused EMEV2/KZM9D early console
      ARM: shmobile: Make EMEV2 platform devices more compact
      ARM: shmobile: Fix EMEV2 clock comment typo
      ARM: shmobile: Remove unused mach/dma.h

Maxime Ripard (4):
      ARM: shmobile: emev2: Remove init_irq declaration in machine description
      ARM: shmobile: r8a73a4: Remove init_irq declaration in machine description
      ARM: shmobile: r8a7790: Remove init_irq declaration in machine description
      ARM: shmobile: sh73a0: Remove init_irq declaration in machine description

 arch/arm/mach-shmobile/board-ape6evm.c         |    2 -
 arch/arm/mach-shmobile/board-armadillo800eva.c |    9 -
 arch/arm/mach-shmobile/board-kzm9d.c           |    2 +-
 arch/arm/mach-shmobile/board-kzm9g-reference.c |    2 -
 arch/arm/mach-shmobile/board-lager.c           |    2 -
 arch/arm/mach-shmobile/clock-emev2.c           |    2 +-
 arch/arm/mach-shmobile/include/mach/dma.h      |    1 -
 arch/arm/mach-shmobile/include/mach/emev2.h    |    2 +-
 arch/arm/mach-shmobile/include/mach/r8a7778.h  |    1 -
 arch/arm/mach-shmobile/setup-emev2.c           |  353 +++++-------------------
 arch/arm/mach-shmobile/setup-r8a73a4.c         |    2 -
 arch/arm/mach-shmobile/setup-r8a7740.c         |   16 +-
 arch/arm/mach-shmobile/setup-r8a7778.c         |   72 ++---
 arch/arm/mach-shmobile/setup-r8a7779.c         |    7 +-
 arch/arm/mach-shmobile/setup-r8a7790.c         |    7 -
 arch/arm/mach-shmobile/setup-sh7372.c          |    7 +-
 arch/arm/mach-shmobile/setup-sh73a0.c          |   34 +--
 17 files changed, 106 insertions(+), 415 deletions(-)
 delete mode 100644 arch/arm/mach-shmobile/include/mach/dma.h


From horms+renesas at verge.net.au  Wed Jul 17 19:32:06 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:32:06 +0900
Subject: [PATCH 05/22] ARM: shmobile: r8a73a4: Remove init_irq declaration in
 machine description
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <0bdbe04db005e025d3522ad3ae9797a4954528e9.1374103272.git.horms+renesas@verge.net.au>

From: Maxime Ripard <maxime.ripard at free-electrons.com>

Commit ebafed7a ("ARM: irq: Call irqchip_init if no init_irq function is
specified") removed the need to explictly setup the init_irq field in
the machine description when using only irqchip_init. Remove that
declaration for shmobile as well.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a73a4.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c b/arch/arm/mach-shmobile/setup-r8a73a4.c
index 7f45c2e..a8c4e41 100644
--- a/arch/arm/mach-shmobile/setup-r8a73a4.c
+++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
@@ -18,7 +18,6 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  */
 #include <linux/irq.h>
-#include <linux/irqchip.h>
 #include <linux/kernel.h>
 #include <linux/of_platform.h>
 #include <linux/platform_data/irq-renesas-irqc.h>
@@ -194,7 +193,6 @@ static const char *r8a73a4_boards_compat_dt[] __initdata = {
 };
 
 DT_MACHINE_START(R8A73A4_DT, "Generic R8A73A4 (Flattened Device Tree)")
-	.init_irq	= irqchip_init,
 	.init_machine	= r8a73a4_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a73a4_boards_compat_dt,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:32:03 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:32:03 +0900
Subject: [PATCH 02/22] ARM: shmobile: r8a7778: add __initdata on resource and
 device data
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <c9031fbb35bd44d99c5cfe7d3c97ec238d63643a.1374103272.git.horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

These data will be kmemdup()'ed on
platform_device_add_resources() and platform_device_add_data()

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7778.c |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c
index 80c2039..b70bfee 100644
--- a/arch/arm/mach-shmobile/setup-r8a7778.c
+++ b/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -53,7 +53,7 @@
 	.irqs		= SCIx_IRQ_MUXED(irq),			\
 }
 
-static struct plat_sci_port scif_platform_data[] = {
+static struct plat_sci_port scif_platform_data[] __initdata = {
 	SCIF_INFO(0xffe40000, gic_iid(0x66)),
 	SCIF_INFO(0xffe41000, gic_iid(0x67)),
 	SCIF_INFO(0xffe42000, gic_iid(0x68)),
@@ -63,24 +63,24 @@ static struct plat_sci_port scif_platform_data[] = {
 };
 
 /* TMU */
-static struct resource sh_tmu0_resources[] = {
+static struct resource sh_tmu0_resources[] __initdata = {
 	DEFINE_RES_MEM(0xffd80008, 12),
 	DEFINE_RES_IRQ(gic_iid(0x40)),
 };
 
-static struct sh_timer_config sh_tmu0_platform_data = {
+static struct sh_timer_config sh_tmu0_platform_data __initdata = {
 	.name			= "TMU00",
 	.channel_offset		= 0x4,
 	.timer_bit		= 0,
 	.clockevent_rating	= 200,
 };
 
-static struct resource sh_tmu1_resources[] = {
+static struct resource sh_tmu1_resources[] __initdata = {
 	DEFINE_RES_MEM(0xffd80014, 12),
 	DEFINE_RES_IRQ(gic_iid(0x41)),
 };
 
-static struct sh_timer_config sh_tmu1_platform_data = {
+static struct sh_timer_config sh_tmu1_platform_data __initdata = {
 	.name			= "TMU01",
 	.channel_offset		= 0x10,
 	.timer_bit		= 1,
@@ -189,7 +189,7 @@ USB_PLATFORM_INFO(ehci);
 USB_PLATFORM_INFO(ohci);
 
 /* Ether */
-static struct resource ether_resources[] = {
+static struct resource ether_resources[] __initdata = {
 	DEFINE_RES_MEM(0xfde00000, 0x400),
 	DEFINE_RES_IRQ(gic_iid(0x89)),
 };
@@ -203,17 +203,17 @@ void __init r8a7778_add_ether_device(struct sh_eth_plat_data *pdata)
 }
 
 /* PFC/GPIO */
-static struct resource pfc_resources[] = {
+static struct resource pfc_resources[] __initdata = {
 	DEFINE_RES_MEM(0xfffc0000, 0x118),
 };
 
 #define R8A7778_GPIO(idx)						\
-static struct resource r8a7778_gpio##idx##_resources[] = {		\
+static struct resource r8a7778_gpio##idx##_resources[] __initdata = {	\
 	DEFINE_RES_MEM(0xffc40000 + 0x1000 * (idx), 0x30),		\
 	DEFINE_RES_IRQ(gic_iid(0x87)),					\
 };									\
 									\
-static struct gpio_rcar_config r8a7778_gpio##idx##_platform_data = {	\
+static struct gpio_rcar_config r8a7778_gpio##idx##_platform_data __initdata = { \
 	.gpio_base	= 32 * (idx),					\
 	.irq_base	= GPIO_IRQ_BASE(idx),				\
 	.number_of_pins	= 32,						\
@@ -249,7 +249,7 @@ void __init r8a7778_pinmux_init(void)
 };
 
 /* SDHI */
-static struct resource sdhi_resources[] = {
+static struct resource sdhi_resources[] __initdata = {
 	/* SDHI0 */
 	DEFINE_RES_MEM(0xFFE4C000, 0x100),
 	DEFINE_RES_IRQ(gic_iid(0x77)),
@@ -365,12 +365,12 @@ void __init r8a7778_init_late(void)
 	platform_device_register_full(&ohci_info);
 }
 
-static struct renesas_intc_irqpin_config irqpin_platform_data = {
+static struct renesas_intc_irqpin_config irqpin_platform_data __initdata = {
 	.irq_base = irq_pin(0), /* IRQ0 -> IRQ3 */
 	.sense_bitfield_width = 2,
 };
 
-static struct resource irqpin_resources[] = {
+static struct resource irqpin_resources[] __initdata = {
 	DEFINE_RES_MEM(0xfe78001c, 4), /* ICR1 */
 	DEFINE_RES_MEM(0xfe780010, 4), /* INTPRI */
 	DEFINE_RES_MEM(0xfe780024, 4), /* INTREQ */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:31:59 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:31:59 +0900
Subject: [PATCH 20/22] ARM: shmobile: Fix EMEV2 clock comment typo
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <09cb2e366737ac70f1d7c6c0a3747a75c8f90f1e.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Update the STI timer frequency comment to 32.768 kHz to
fix 37 kHz typo.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-emev2.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/clock-emev2.c b/arch/arm/mach-shmobile/clock-emev2.c
index 4710f18..56dd0cf 100644
--- a/arch/arm/mach-shmobile/clock-emev2.c
+++ b/arch/arm/mach-shmobile/clock-emev2.c
@@ -221,7 +221,7 @@ void __init emev2_clock_init(void)
 	smu_base = ioremap(EMEV2_SMU_BASE, PAGE_SIZE);
 	BUG_ON(!smu_base);
 
-	/* setup STI timer to run on 37.768 kHz and deassert reset */
+	/* setup STI timer to run on 32.768 kHz and deassert reset */
 	emev2_smu_write(0, STI_CLKSEL);
 	emev2_smu_write(1, STI_RSTCTRL);
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:32:00 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:32:00 +0900
Subject: [PATCH 21/22] ARM: shmobile: r8a7778: remove r8a7778_init_irq()
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <54aa4c48bc0d364565e7d1c722b07314efdc2a10.1374103272.git.horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

This patch removes r8a7778_init_irq(), since no-one is using it.
And now, there is no reason to have r8a7778_init_irq_common().
r8a7778_init_irq_dt() includes it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a7778.h |    1 -
 arch/arm/mach-shmobile/setup-r8a7778.c        |   37 ++++++-------------------
 2 files changed, 9 insertions(+), 29 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a7778.h b/arch/arm/mach-shmobile/include/mach/r8a7778.h
index 851d027..9b561bf 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -33,7 +33,6 @@ extern void r8a7778_add_mmc_device(struct sh_mmcif_plat_data *info);
 
 extern void r8a7778_init_late(void);
 extern void r8a7778_init_delay(void);
-extern void r8a7778_init_irq(void);
 extern void r8a7778_init_irq_dt(void);
 extern void r8a7778_clock_init(void);
 extern void r8a7778_init_irq_extpin(int irlm);
diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c
index 2a101eb..a3a2e37 100644
--- a/arch/arm/mach-shmobile/setup-r8a7778.c
+++ b/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -408,17 +408,25 @@ void __init r8a7778_init_irq_extpin(int irlm)
 			&irqpin_platform_data, sizeof(irqpin_platform_data));
 }
 
+void __init r8a7778_init_delay(void)
+{
+	shmobile_setup_delay(800, 1, 3); /* Cortex-A9 @ 800MHz */
+}
+
+#ifdef CONFIG_USE_OF
 #define INT2SMSKCR0	0x82288 /* 0xfe782288 */
 #define INT2SMSKCR1	0x8228c /* 0xfe78228c */
 
 #define INT2NTSR0	0x00018 /* 0xfe700018 */
 #define INT2NTSR1	0x0002c /* 0xfe70002c */
-static void __init r8a7778_init_irq_common(void)
+void __init r8a7778_init_irq_dt(void)
 {
 	void __iomem *base = ioremap_nocache(0xfe700000, 0x00100000);
 
 	BUG_ON(!base);
 
+	irqchip_init();
+
 	/* route all interrupts to ARM */
 	__raw_writel(0x73ffffff, base + INT2NTSR0);
 	__raw_writel(0xffffffff, base + INT2NTSR1);
@@ -430,33 +438,6 @@ static void __init r8a7778_init_irq_common(void)
 	iounmap(base);
 }
 
-void __init r8a7778_init_irq(void)
-{
-	void __iomem *gic_dist_base;
-	void __iomem *gic_cpu_base;
-
-	gic_dist_base = ioremap_nocache(0xfe438000, PAGE_SIZE);
-	gic_cpu_base  = ioremap_nocache(0xfe430000, PAGE_SIZE);
-	BUG_ON(!gic_dist_base || !gic_cpu_base);
-
-	/* use GIC to handle interrupts */
-	gic_init(0, 29, gic_dist_base, gic_cpu_base);
-
-	r8a7778_init_irq_common();
-}
-
-void __init r8a7778_init_delay(void)
-{
-	shmobile_setup_delay(800, 1, 3); /* Cortex-A9 @ 800MHz */
-}
-
-#ifdef CONFIG_USE_OF
-void __init r8a7778_init_irq_dt(void)
-{
-	irqchip_init();
-	r8a7778_init_irq_common();
-}
-
 static const char *r8a7778_compat_dt[] __initdata = {
 	"renesas,r8a7778",
 	NULL,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:32:01 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:32:01 +0900
Subject: [PATCH 22/22] ARM: shmobile: Remove unused mach/dma.h
In-Reply-To: <cover.1374103272.git.horms+renesas@verge.net.au>
References: <cover.1374103272.git.horms+renesas@verge.net.au>
Message-ID: <ebd9616f439a8a46b9dca9a272b342f34c5f3614.1374103272.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Remove mach-shmobile mach/dma.h since it only
seems to be used on non-mach-shmobile platforms.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/dma.h |    1 -
 1 file changed, 1 deletion(-)
 delete mode 100644 arch/arm/mach-shmobile/include/mach/dma.h

diff --git a/arch/arm/mach-shmobile/include/mach/dma.h b/arch/arm/mach-shmobile/include/mach/dma.h
deleted file mode 100644
index 40a8c17..0000000
--- a/arch/arm/mach-shmobile/include/mach/dma.h
+++ /dev/null
@@ -1 +0,0 @@
-/* empty */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Wed Jul 17 19:50:58 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 18 Jul 2013 08:50:58 +0900
Subject: [PATCH fix for v3.11 (repost)] dmaengine: shdma: fix a build failure
 on platforms with no DMA support
Message-ID: <20130717235058.GA10683@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

On platforms with no support for the shdma dmaengine driver build is
currently failing with

drivers/built-in.o: In function `sh_mobile_sdhi_probe':
drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference to`shdma_chan_filter'

Fix the breakage by defining shdma_chan_filter to NULL in such
configurations.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
[horms+renesas at verge.net.au: Apply change to shdma-base.h instead of sh_dma.h]
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 include/linux/shdma-base.h | 4 ++++
 1 file changed, 4 insertions(+)

Hi Vinod,

please consider this fix from Guennadi for v3.11 which I have rebased on top of
next-20130709. It fixes a build problem on a number of shmobile defconfigs
including bockw.

Alternatively, I would be happy to take this through the renesas tree.

I posted this patch last week but I'm wondering if you missed it somehow.
This patch resolves a regression in v3.11-rc1.

diff --git a/include/linux/shdma-base.h b/include/linux/shdma-base.h
index 382cf71..5b1c984 100644
--- a/include/linux/shdma-base.h
+++ b/include/linux/shdma-base.h
@@ -124,6 +124,10 @@ void shdma_chan_remove(struct shdma_chan *schan);
 int shdma_init(struct device *dev, struct shdma_dev *sdev,
 		    int chan_num);
 void shdma_cleanup(struct shdma_dev *sdev);
+#if IS_ENABLED(CONFIG_SH_DMAE_BASE)
 bool shdma_chan_filter(struct dma_chan *chan, void *arg);
+#else
+#define shdma_chan_filter NULL
+#endif
 
 #endif
-- 
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



From laurent.pinchart at ideasonboard.com  Wed Jul 17 19:58:17 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 18 Jul 2013 01:58:17 +0200
Subject: [PATCH] Documentation: dt: bindings: TI WiLink modules
In-Reply-To: <1372682370.21065.68.camel@cumari.coelho.fi>
References: <1372149330-24335-1-git-send-email-coelho@ti.com>
 <1372425670.21065.61.camel@cumari.coelho.fi>
 <1372682370.21065.68.camel@cumari.coelho.fi>
Message-ID: <1698879.DLaB5pbe5M@avalon>

Hi Luciano,

On Monday 01 July 2013 15:39:30 Luciano Coelho wrote:
> On Fri, 2013-06-28 at 16:21 +0300, Luciano Coelho wrote:
> > On Fri, 2013-06-28 at 15:18 +0300, Felipe Balbi wrote:
> > > On Fri, Jun 28, 2013 at 03:13:52PM +0300, Luciano Coelho wrote:
> > > > On Fri, 2013-06-28 at 14:41 +0300, Felipe Balbi wrote:
> > > > > On Fri, Jun 28, 2013 at 02:22:11PM +0300, Luciano Coelho wrote:
> > > > > > On Fri, 2013-06-28 at 13:31 +0300, Luciano Coelho wrote:
> > > > > > > (fixed Mike's address)
> > > > > > > 
> > > > > > > On Fri, 2013-06-28 at 11:21 +0100, Mark Rutland wrote:
> > > > > > > > On Fri, Jun 28, 2013 at 10:53:35AM +0100, Luciano Coelho 
wrote:
> > > > > > > > > On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
> > > > > > > > > > On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho 
wrote:
> > > > > > > > > > > +Optional properties:
> > > > > > > > > > > +--------------------
> > > > > > > > > > > +
> > > > > > > > > > > +- refclock: the internal WLAN reference clock frequency
> > > > > > > > > > > (required for
> > > > > > > > > > > +  WiLink6 and WiLink7; not used for WiLink8).  Must be
> > > > > > > > > > > one of the
> > > > > > > > > > > +  following:
> > > > > > > > > > > +	0 = 19.2 MHz
> > > > > > > > > > > +	1 = 26.0 MHz
> > > > > > > > > > > +	2 = 38.4 MHz
> > > > > > > > > > > +	3 = 52.0 MHz
> > > > > > > > > > > +	4 = 38.4 MHz, XTAL
> > > > > > > > > > > +	5 = 26.0 MHz, XTAL
> > > > > > > > > > > +
> > > > > > > > > > > +- tcxoclock: the internal WLAN TCXO clock frequency
> > > > > > > > > > > (required for
> > > > > > > > > > > +  WiLink7 not used for WiLink6 and WiLink8).  Must be
> > > > > > > > > > > one of the
> > > > > > > > > > > +  following:
> > > > > > > > > > > +	0 = 19.200 MHz
> > > > > > > > > > > +	1 = 26.000 MHz
> > > > > > > > > > > +	2 = 38.400 MHz
> > > > > > > > > > > +	3 = 52.000 MHz
> > > > > > > > > > > +	4 = 16.368 MHz
> > > > > > > > > > > +	5 = 32.736 MHz
> > > > > > > > > > > +	6 = 16.800 MHz
> > > > > > > > > > > +	7 = 33.600 MHz
> > > > > > > > > > 
> > > > > > > > > > This looks suspiciously like what we have the common clock
> > > > > > > > > > bindings for:
> > > > > > > > > > 
> > > > > > > > > > refclk {
> > > > > > > > > > 
> > > > > > > > > > 	compatible = "fixed-clock";
> > > > > > > > > > 	#clock-cells = <0>;
> > > > > > > > > > 	clock-frequency = <19200000>;
> > > > > > > > > > 
> > > > > > > > > > }
> > > > > > > > > > 
> > > > > > > > > > wilink {
> > > > > > > > > > 
> > > > > > > > > > 	compatible = "ti,wilink7";
> > > > > > > > > > 	interrupt-parent = <&some_interrupt_controller>;
> > > > > > > > > > 	interrupts = <0 1 1>;
> > > > > > > > > > 	clocks = <&refclk>, <&refclk>;
> > > > > > > > > > 	clock-names = "refclk", "txoclk";
> > > > > > > > > > 
> > > > > > > > > > };
> > > > > > > > > > 
> > > > > > > > > > Could you not use them?
> > > > > > > > > 
> > > > > > > > > Hmmm... this actually does look good.  But these are
> > > > > > > > > internal clocks in the modules, they cannot be accessed from
> > > > > > > > > outside.  Does it make sense to register them with the clock
> > > > > > > > > framework?
> > > > > > > > 
> > > > > > > > Given we already have a common way of describing clocks, I
> > > > > > > > think it makes sense to use it -- people already understand
> > > > > > > > the common bindings, and it's less code to add add to the
> > > > > > > > kernel. I don't think the fact these clocks are internal
> > > > > > > > should prevent us from describing them as we would an external
> > > > > > > > clock.
> > > > > > > 
> > > > > > > Yes, I agree with you.  Thanks for the suggestion! I think it
> > > > > > > will look much better.  And now that I dug a bit more into the
> > > > > > > code, I can see that there are only structs being populated, so
> > > > > > > there shouldn't be any other side-effects.
> > > > > > 
> > > > > > Hmmm, one thing that escaped me.  Besides the frequency, I also
> > > > > > need a boolean that tells if the clock is XTAL or not.  I can't
> > > > > > figure out how to pass this if I use the generic clock framework. 
> > > > > > Any suggestions?
> > > > > 
> > > > > Could you use clock-output-names for that ?
> > > > > 
> > > > > XTAL clock:
> > > > > 
> > > > > refclk {
> > > > > 
> > > > > 	compatible = "fixed-clock";
> > > > > 	#clock cells = <0>;
> > > > > 	clock-frequency = <19200000>;
> > > > > 	clock-output-names = "xtal";
> > > > > 
> > > > > };
> > > > > 
> > > > > non-XTAL clock:
> > > > > 
> > > > > refclk {
> > > > > 
> > > > > 	compatible = "fixed-clock";
> > > > > 	#clock cells = <0>;
> > > > > 	clock-frequency = <19200000>;
> > > > > 	clock-output-names = "osc"; /* any better name ? */
> > > > > 
> > > > > };
> > > > 
> > > > This starts looking a bit hacky.  Using the output name as a flag is
> > > > not very pretty.
> > > > 
> > > > I think it would be better to have a separate flag for it in the wlan
> > > > node.  Like an optional "refclock-xtal" boolean or something.  The
> > > > downside of this is that we would be adding information about the
> > > > clock details in the wilink node. :(
> > > > 
> > > > OTOH, we could add a flag to the generic clock binding? A new optional
> > > > boolean that tells whether the clock is XTAL or not:
> > > > 
> > > > refclk {
> > > > 
> > > > 	compatible = "fixed-clock";
> > > > 	#clock cells = <0>;
> > > > 	clock-frequency = <19200000>;
> > > > 	clock-xtal;
> > > > 
> > > > };
> > > > 
> > > > Do you think that would make sense?
> > > 
> > > sure, that looks alright to me. Surely there are other devices out there
> > > who want to know if the clock comes from a crystal or not ?!?
> > 
> > Mike, what do you think about this idea? If it sounds okay to you, I can
> > cook up a patch adding this flag.
> 
> Hmmm... I started implementing this whole thing, but using these clocks
> as "fixed-clock"s is not so straightforward.  The problem is that I
> would need to register my driver as a clock provider and add the OF
> match for "fixed-clock".
> 
> If I do that, all the other "fixed-clock" nodes would be passed to my
> driver too, which is wrong.  Or, the platform should register the
> "fixed-clock" match, but this would be wrong too, since it would find
> *my* fixed-clocks.
> 
> The only thing I can come up with is to make a small clock driver (maybe
> even inside the WiLink module itself) that registers a new type of
> clock, "ti,wilink-clock" or something.  But this would really be
> overkill, wouldn't it?
> 
> Any other ideas?

One possibility would be to just call clk_get_rate() on the clock from the 
WiLink driver, which would return the fixed frequency specified in DT, and 
configure the WiLink hardware accordingly. This might be a bit hackish though.

-- 
Regards,

Laurent Pinchart



From shinya.kuribayashi.px at renesas.com  Wed Jul 17 20:32:26 2013
From: shinya.kuribayashi.px at renesas.com (Shinya Kuribayashi)
Date: Thu, 18 Jul 2013 09:32:26 +0900
Subject: [PATCH] ARM: shmobile: r8a7790 SMP prototype v5
In-Reply-To: <20130717204918.30125.40588.sendpatchset@w520>
References: <20130717204918.30125.40588.sendpatchset@w520>
Message-ID: <51E7379A.1080408@renesas.com>

On 7/18/2013 5:49 AM, Magnus Damm wrote:
>  Changes since v4:
>  - Rolled in the following patches from Kuribayashi-san, thanks!
>    ARM: shmobile: smp-r8a7790: remove the obsolete RESCNT register
>    ARM: shmobile: smp-r8a7790: rename s/carescnt/rescnt/g
>    ARM: shmobile: smp-r8a7790: rename s/cabar/bar/g as well
>    ARM: shmobile: smp-r8a7790: power up a CPU core at .smp_boot_secondary stage
> 
>  Written against kernel.org renesas git tag renesas-devel-20130717

Thanks for the update, looks good to me.
--
Shinya Kuribayashi
Renesas Electronics


From gioh.kim at lge.com  Wed Jul 17 21:30:31 2013
From: gioh.kim at lge.com (Gioh Kim)
Date: Thu, 18 Jul 2013 10:30:31 +0900
Subject: [PATCH] [RFC] EHCI: add to memory barrier to updating hw_next
In-Reply-To: <CACVXFVOu-2q74JmHLEo3mCVSAzfc7n8GmqPDMPhEDp0wL37w_w@mail.gmail.com>
References: <000001ce82aa$feac9ee0$fc05dca0$@lge.com>
 <CACVXFVOu-2q74JmHLEo3mCVSAzfc7n8GmqPDMPhEDp0wL37w_w@mail.gmail.com>
Message-ID: <000101ce8356$65011940$2f034bc0$@lge.com>

Thanks for your reply.

> -----Original Message-----
> From: Ming Lei [mailto:tom.leiming at gmail.com]
> Sent: Wednesday, July 17, 2013 5:52 PM
> To: ???
> Cc: Alan Stern; linux-usb at vger.kernel.org; linux-kernel at vger.kernel.org;
> Mark Salter; namhyung.kim at lge.com; Minchan Kim; Chanho Min; Jong-Sung Kim;
> linux-arm-kernel
> Subject: Re: [PATCH] [RFC] EHCI: add to memory barrier to updating hw_next
> 
> Cc: ARM list
> 
> On Wed, Jul 17, 2013 at 1:03 PM, ??? <gioh.kim at lge.com> wrote:
> > Hi,
> >
> > I have a missing urb completion problem on ARMv7 based platform.
> >
> > I thought the above problem was caused by coherent memory between the
> > EHCI device and CPU so I tryied to allocates device type memory for
> > EHCI via dma_declare_coherent_memory at machine initialization step so
> > that EHCI always allocates from those device type memory.
> > It seems to solve the issue because I didn't see any problem.
> >
> > But I am not sure it is acceptable solution. So I applied the patch
> > https://lkml.org/lkml/2011/8/31/344.
> > But it could not solve the problem so that I added another wmb() as my
> > patch, and now my platform works fine.
> 
> I remember the previous problem reported on Pandaboard firstly was fixed
> by Will's commit 11ed0ba1(ARM: 7161/1: errata: no automatic store buffer
> drain), so could you try to enable PL310_ERRATA_769419 and see if your
> problem can be fixed?


I also know the errata but it didn't work for my platform.


> 
> >
> > I am not sure what's the exact problem and what wmb I added could
> > solve but I just think the problem is related to store buffer flush of
> hw_next.
> 
> Yes, per the above commit, but it might be one hardware problem.
> 
> > Anyway, important thing is that it fixed my problem so I expect you
> > expert guys could find what I am missing and a right solution.
> > IMHO, the patch might miss updating hw_next pointer.
> > Am I correct?
> >
> > I understand the wmb() is just memory barrier, not write-buffer flush.
> > But it is true that wmb() can flush write buffer in ARM.
> > Anyhow I think that memory type, "normal memory, non-cacheable", may
> > have a problem for some devices that needs device type memory.
> 
> Currently on ARMv7 DMA coherent buffer has to be bufferable, in theory we
> might need one API to flush CPU write buffer, as described in
> Documentation/DMA-API-HOWTO.txt:
> 
>              Also, on some platforms your driver may need to flush CPU write
>              buffers in much the same way as it needs to flush write buffers
>              found in PCI bridges (such as by reading a register's value
>              after writing it).
> 
> But actually on hardware without the problem(such as A15), I don't see any
> effect without flushing store buffer explicitly.


The problem of my platform is occurring when it has very heavy traffic such as
HD video streaming service or very many small images display.
I guess that HC could have a use-after-free problem like following situation.

1. A qtd which is not at the queue head should be removed in qh_completions().
2. The last->hw_next become be pointing at the next qtd but the hw_next value is delayed in write-buffer.
3. The qtd is removed in the list.
4. The qtd is freed into DMA pool and re-allocated for another urb.
5. HC try to process last->hw_next and it is pointing re-allocated qtd.

What do you think about it? Is it possible?


> 
> >
> > I cannot get conclusion from the discussion at
> > https://lkml.org/lkml/2011/8/31/344.
> > Which can I do for my platform, wmb() or dma_coherent_write_sync()?
> 
> If your hardware is covered by PL310_ERRATA_769419, maybe it is better to
> enable the errata.
> 
> >
> > Signed-off-by: Gioh Kim <gioh.kim at lge.com>
> > ---
> >  drivers/usb/host/ehci-q.c |    1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
> > index d34b399..779d9e8 100644
> > --- a/drivers/usb/host/ehci-q.c
> > +++ b/drivers/usb/host/ehci-q.c
> > @@ -501,6 +501,7 @@ qh_completions (struct ehci_hcd *ehci, struct
> ehci_qh *qh)
> >                         last = list_entry (qtd->qtd_list.prev,
> >                                         struct ehci_qtd, qtd_list);
> >                         last->hw_next = qtd->hw_next;
> > +                       wmb();
> >                 }
> >
> >                 /* remove qtd; it's recycled after possible urb
> > completion */
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb"
> > in the body of a message to majordomo at vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> Thanks,
> --
> Ming Lei



From laurent.pinchart at ideasonboard.com  Wed Jul 17 21:35:16 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 18 Jul 2013 03:35:16 +0200
Subject: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property
In-Reply-To: <1373913629-32179-5-git-send-email-swarren@wwwdotorg.org>
References: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
 <1373913629-32179-5-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1425430.efevqzjIZK@avalon>

Hi Stephen,

On Monday 15 July 2013 12:40:29 Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> This property is no longer required by the GPIO binding. Remove it.
> 
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
> ---
> This should presumably be applied along with the previous changes

The mach-shmobile tree includes patches for v3.12 that will add the #gpio-
ranges-cells to several .dtsi files. I can get that fixed locally (most 
probably through a rebase), could you please ping me when this series will be 
accepted for upstream merge ?

> v2: Squash spear and mxc changes into a single patch; there's no
> need to keep vf610.dtsi separate now that this series will go into
> v3.12 or later, and that file is part of v3.11-rc1.
> ---
>  arch/arm/boot/dts/spear1310.dtsi | 1 -
>  arch/arm/boot/dts/spear1340.dtsi | 1 -
>  arch/arm/boot/dts/spear310.dtsi  | 1 -
>  arch/arm/boot/dts/spear320.dtsi  | 2 --
>  arch/arm/boot/dts/vf610.dtsi     | 1 -
>  5 files changed, 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/spear1310.dtsi
> b/arch/arm/boot/dts/spear1310.dtsi index 122ae94..90e99b5 100644
> --- a/arch/arm/boot/dts/spear1310.dtsi
> +++ b/arch/arm/boot/dts/spear1310.dtsi
> @@ -89,7 +89,6 @@
>  		pinmux: pinmux at e0700000 {
>  			compatible = "st,spear1310-pinmux";
>  			reg = <0xe0700000 0x1000>;
> -			#gpio-range-cells = <3>;
>  		};
> 
>  		apb {
> diff --git a/arch/arm/boot/dts/spear1340.dtsi
> b/arch/arm/boot/dts/spear1340.dtsi index 54d128d..5003013 100644
> --- a/arch/arm/boot/dts/spear1340.dtsi
> +++ b/arch/arm/boot/dts/spear1340.dtsi
> @@ -63,7 +63,6 @@
>  		pinmux: pinmux at e0700000 {
>  			compatible = "st,spear1340-pinmux";
>  			reg = <0xe0700000 0x1000>;
> -			#gpio-range-cells = <3>;
>  		};
> 
>  		pwm: pwm at e0180000 {
> diff --git a/arch/arm/boot/dts/spear310.dtsi
> b/arch/arm/boot/dts/spear310.dtsi index 9537208..1e1318e 100644
> --- a/arch/arm/boot/dts/spear310.dtsi
> +++ b/arch/arm/boot/dts/spear310.dtsi
> @@ -25,7 +25,6 @@
>  		pinmux: pinmux at b4000000 {
>  			compatible = "st,spear310-pinmux";
>  			reg = <0xb4000000 0x1000>;
> -			#gpio-range-cells = <3>;
>  		};
> 
>  		fsmc: flash at 44000000 {
> diff --git a/arch/arm/boot/dts/spear320.dtsi
> b/arch/arm/boot/dts/spear320.dtsi index ffea342..f630d0c 100644
> --- a/arch/arm/boot/dts/spear320.dtsi
> +++ b/arch/arm/boot/dts/spear320.dtsi
> @@ -1,4 +1,3 @@
> -/*
>   * DTS file for SPEAr320 SoC
>   *
>   * Copyright 2012 Viresh Kumar <viresh.linux at gmail.com>
> @@ -24,7 +23,6 @@
>  		pinmux: pinmux at b3000000 {
>  			compatible = "st,spear320-pinmux";
>  			reg = <0xb3000000 0x1000>;
> -			#gpio-range-cells = <3>;
>  		};
> 
>  		clcd at 90000000 {
> diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
> index e1eb7da..8577780 100644
> --- a/arch/arm/boot/dts/vf610.dtsi
> +++ b/arch/arm/boot/dts/vf610.dtsi
> @@ -162,7 +162,6 @@
>  			iomuxc: iomuxc at 40048000 {
>  				compatible = "fsl,vf610-iomuxc";
>  				reg = <0x40048000 0x1000>;
> -				#gpio-range-cells = <3>;
> 
>  				/* functions and groups pins */
-- 
Regards,

Laurent Pinchart



From nfortino at nvidia.com  Wed Jul 17 21:48:37 2013
From: nfortino at nvidia.com (Nickolas Fortino)
Date: Wed, 17 Jul 2013 18:48:37 -0700
Subject: preempted dup_mm misses TLB invalidate
In-Reply-To: <20130717212148.GV24642@n2100.arm.linux.org.uk>
References: <51E43D2B.9090709@nvidia.com>
 <20130717192746.GE16496@MacBook-Pro.local> <51E6F60D.6060804@wwwdotorg.org>
 <51E6FA10.5070504@nvidia.com> <20130717203409.GU24642@n2100.arm.linux.org.uk>
 <51E706A6.4040309@nvidia.com> <20130717212148.GV24642@n2100.arm.linux.org.uk>
Message-ID: <51E74975.9040105@nvidia.com>

On 7/17/2013 2:21 PM, Russell King - ARM Linux wrote:
> I'm
> willing to bet that the behaviour you observe on ARM is inherently visible
> on many of the other Linux architectures.

Based on the discussion from this thread, I agree there is nothing 
architecture specific here. This behavior also appears legal, so long as 
any page with write permissions in the TLB is considered dirty in the 
linux PTE structure.

I had missed the specification for fork() is silent on what happens to 
MAP_PRIVATE memory modifications which occur during the execution of 
fork(); it merely specifies what happens to writes which occur prior to 
fork being called and after fork returns.


From sboyd at codeaurora.org  Wed Jul 17 22:39:18 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 17 Jul 2013 19:39:18 -0700
Subject: [PATCH 0/3] Cleanup sched_clock.h users
Message-ID: <1374115161-675-1-git-send-email-sboyd@codeaurora.org>

This patchset cleans up the last few stragglers using the sched_clock.h
header file in asm and removes the asm header.

A new one appeared in drivers/clocksource so I'm not sure who
wants to take that one.

Stephen Boyd (3):
  clocksource: orion: Use linux/sched_clock.h
  ARM: clps711x: Use linux/sched_clock.h
  ARM: Remove temporary sched_clock.h header

 arch/arm/include/asm/sched_clock.h | 4 ----
 arch/arm/mach-clps711x/common.c    | 2 +-
 drivers/clocksource/time-orion.c   | 2 +-
 3 files changed, 2 insertions(+), 6 deletions(-)
 delete mode 100644 arch/arm/include/asm/sched_clock.h

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 17 22:39:19 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 17 Jul 2013 19:39:19 -0700
Subject: [PATCH 1/3] clocksource: orion: Use linux/sched_clock.h
In-Reply-To: <1374115161-675-1-git-send-email-sboyd@codeaurora.org>
References: <1374115161-675-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374115161-675-2-git-send-email-sboyd@codeaurora.org>

The sched_clock.h include is under include/linux now.

Cc: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/time-orion.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/time-orion.c b/drivers/clocksource/time-orion.c
index ecbeb68..9c7f018 100644
--- a/drivers/clocksource/time-orion.c
+++ b/drivers/clocksource/time-orion.c
@@ -19,7 +19,7 @@
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 #include <linux/spinlock.h>
-#include <asm/sched_clock.h>
+#include <linux/sched_clock.h>
 
 #define TIMER_CTRL		0x00
 #define  TIMER0_EN		BIT(0)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 17 22:39:20 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 17 Jul 2013 19:39:20 -0700
Subject: [PATCH 2/3] ARM: clps711x: Use linux/sched_clock.h
In-Reply-To: <1374115161-675-1-git-send-email-sboyd@codeaurora.org>
References: <1374115161-675-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374115161-675-3-git-send-email-sboyd@codeaurora.org>

The sched_clock.h include is under include/linux now.

Cc: Alexander Shiyan <shc_work at mail.ru>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-clps711x/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-clps711x/common.c b/arch/arm/mach-clps711x/common.c
index 4ca2f3c..134641d 100644
--- a/arch/arm/mach-clps711x/common.c
+++ b/arch/arm/mach-clps711x/common.c
@@ -29,12 +29,12 @@
 #include <linux/clockchips.h>
 #include <linux/clocksource.h>
 #include <linux/clk-provider.h>
+#include <linux/sched_clock.h>
 
 #include <asm/exception.h>
 #include <asm/mach/irq.h>
 #include <asm/mach/map.h>
 #include <asm/mach/time.h>
-#include <asm/sched_clock.h>
 #include <asm/system_misc.h>
 
 #include <mach/hardware.h>
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 17 22:39:21 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 17 Jul 2013 19:39:21 -0700
Subject: [PATCH 3/3] ARM: Remove temporary sched_clock.h header
In-Reply-To: <1374115161-675-1-git-send-email-sboyd@codeaurora.org>
References: <1374115161-675-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374115161-675-4-git-send-email-sboyd@codeaurora.org>

This header file is no longer needed now that the ARM sched_clock
framework is generic and all users have moved to linux/sched_clock.h
instead of asm/sched_clock.h. Remove it.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/include/asm/sched_clock.h | 4 ----
 1 file changed, 4 deletions(-)
 delete mode 100644 arch/arm/include/asm/sched_clock.h

diff --git a/arch/arm/include/asm/sched_clock.h b/arch/arm/include/asm/sched_clock.h
deleted file mode 100644
index 2389b71..0000000
--- a/arch/arm/include/asm/sched_clock.h
+++ /dev/null
@@ -1,4 +0,0 @@
-/* You shouldn't include this file. Use linux/sched_clock.h instead.
- * Temporary file until all asm/sched_clock.h users are gone
- */
-#include <linux/sched_clock.h>
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From nicolas.pitre at linaro.org  Wed Jul 17 23:28:32 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Jul 2013 23:28:32 -0400
Subject: [PATCH 0/4] MCPM backends updates
Message-ID: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>

Patch 1:
Fixes to the existing Vexpress DCSCB backend.

Patch 2:
Lorenzo's minimal SPC driver required by the TC2 MCPM backend.
As discussed on the list, this is not considered to be a MFD driver.
This hardly qualify as a bus driver either.  Conceptually, this is
a very platform specific register multiplex driver allowing subsystem
drivers to hook into.  I therefore moved it to drivers/platform/vexpress/.

Patch 3:
This is the MCPM backend enabling SMP secondary boot and CPU hotplug
on the VExpress TC2 big.LITTLE platform.

Patch 4:
Add MCPM suspend method to the TC2 backend allowing basic CPU idle/suspend.
The cpuidle driver that hooks into this will be submitted separately.

The TC2 MCPM patches have been reviewed here:
http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=242408

The latest SPC driver discussion is here:
http://news.gmane.org/group/gmane.linux.kernel/thread=1525836


Nicolas






From nicolas.pitre at linaro.org  Wed Jul 17 23:28:34 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Jul 2013 23:28:34 -0400
Subject: [PATCH 2/4] drivers/platform: vexpress: add Serial Power Controller
 (SPC) support
In-Reply-To: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374118116-16836-3-git-send-email-nicolas.pitre@linaro.org>

From: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

The TC2 versatile express core tile integrates a logic block that provides
the interface between the dual cluster test-chip and the M3 microcontroller
that carries out power management. The logic block, called Serial Power
Controller (SPC), contains several memory mapped registers to control among
other things low-power states, wake-up irqs and per-CPU jump addresses
registers.

This patch provides a driver that enables run-time control of features
implemented by the SPC power management control logic with an API to
be used by different subsystem drivers on top.

The SPC control logic is required to be programmed very early in the boot
process to reset secondary CPUs on the TC2 testchip, set-up jump addresses
and wake-up IRQs for power management. Hence, waiting for core changes to
be made in the device core code to enable early registration of platform
devices, the driver puts in place an early init scheme that allows kernel
drivers to initialize the SPC driver directly from the components requiring
it, if their initialization routine is called before this driver init
function during the boot process.

Device tree bindings documentation for the SPC component is also provided.

Cc: Olof Johansson <olof at lixom.net>
Cc: Amit Kucheria <amit.kucheria at linaro.org>
Cc: Jon Medhurst <tixy at linaro.org>
Signed-off-by: Achin Gupta <achin.gupta at arm.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha at arm.com>
Acked-by: Pawel Moll <pawel.moll at arm.com>
[ np: moved from drivers/mfd/ to drivers/platform/vexpress/ ]
Signed-off-by: Nicolas Pitre <nico at linaro.org>
---
 .../devicetree/bindings/arm/vexpress-spc.txt       |  36 +++
 drivers/platform/Kconfig                           |   4 +-
 drivers/platform/Makefile                          |   1 +
 drivers/platform/vexpress/Kconfig                  |   9 +
 drivers/platform/vexpress/Makefile                 |   1 +
 drivers/platform/vexpress/spc.c                    | 253 +++++++++++++++++++++
 include/linux/vexpress.h                           |  17 ++
 7 files changed, 320 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/vexpress-spc.txt
 create mode 100644 drivers/platform/vexpress/Kconfig
 create mode 100644 drivers/platform/vexpress/Makefile
 create mode 100644 drivers/platform/vexpress/spc.c

diff --git a/Documentation/devicetree/bindings/arm/vexpress-spc.txt b/Documentation/devicetree/bindings/arm/vexpress-spc.txt
new file mode 100644
index 0000000000..1614725918
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vexpress-spc.txt
@@ -0,0 +1,36 @@
+* ARM Versatile Express Serial Power Controller device tree bindings
+
+Latest ARM development boards implement a power management interface (serial
+power controller - SPC) that is capable of managing power states transitions,
+wake-up IRQs and resume addresses for ARM multiprocessor testchips.
+The serial controller can be programmed through a memory mapped interface
+that enables communication between firmware running on the microcontroller
+managing power states and the application processors.
+
+The SPC DT bindings are defined as follows:
+
+- spc node
+
+	- compatible:
+		Usage: required
+		Value type: <stringlist>
+		Definition: must be
+			    "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc"
+	- reg:
+		Usage: required
+		Value type: <prop-encode-array>
+		Definition: A standard property that specifies the base address
+			    and the size of the SPC address space
+	- interrupts:
+		Usage: required
+		Value type: <prop-encoded-array>
+		Definition:  SPC interrupt configuration. A standard property
+			     that follows ePAPR interrupts specifications
+
+Example:
+
+spc: spc at 7fff0000 {
+	compatible = "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc";
+	reg = <0x7fff0000 0x1000>;
+	interrupts = <0 95 4>;
+};
diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig
index 69616aeaa9..449010e828 100644
--- a/drivers/platform/Kconfig
+++ b/drivers/platform/Kconfig
@@ -4,4 +4,6 @@ endif
 if GOLDFISH
 source "drivers/platform/goldfish/Kconfig"
 endif
-
+if ARCH_VEXPRESS
+source "drivers/platform/vexpress/Kconfig"
+endif
diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile
index 8a44a4cd6d..c1173d6e15 100644
--- a/drivers/platform/Makefile
+++ b/drivers/platform/Makefile
@@ -5,3 +5,4 @@
 obj-$(CONFIG_X86)		+= x86/
 obj-$(CONFIG_OLPC)		+= olpc/
 obj-$(CONFIG_GOLDFISH)		+= goldfish/
+obj-$(CONFIG_ARCH_VEXPRESS)	+= vexpress/
diff --git a/drivers/platform/vexpress/Kconfig b/drivers/platform/vexpress/Kconfig
new file mode 100644
index 0000000000..d09a7c45bd
--- /dev/null
+++ b/drivers/platform/vexpress/Kconfig
@@ -0,0 +1,9 @@
+config VEXPRESS_SPC
+	bool "Versatile Express SPC driver support"
+	help
+	  The Serial Power Controller (SPC) for ARM Ltd. test chips, is
+	  an IP that provides a memory mapped interface to power controller
+	  HW. The driver provides an API abstraction meant to be used by
+	  subsystem drivers allowing to program registers controlling
+	  low-level power management features like power down flags,
+	  global and per-cpu wake-up IRQs.
diff --git a/drivers/platform/vexpress/Makefile b/drivers/platform/vexpress/Makefile
new file mode 100644
index 0000000000..d31eca24f4
--- /dev/null
+++ b/drivers/platform/vexpress/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VEXPRESS_SPC)	+= spc.o
diff --git a/drivers/platform/vexpress/spc.c b/drivers/platform/vexpress/spc.c
new file mode 100644
index 0000000000..aa8c2a4862
--- /dev/null
+++ b/drivers/platform/vexpress/spc.c
@@ -0,0 +1,253 @@
+/*
+ * Versatile Express Serial Power Controller (SPC) support
+ *
+ * Copyright (C) 2013 ARM Ltd.
+ *
+ * Authors: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
+ *          Achin Gupta           <achin.gupta at arm.com>
+ *          Lorenzo Pieralisi     <lorenzo.pieralisi at arm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <linux/vexpress.h>
+
+#include <asm/cacheflush.h>
+
+#define SPCLOG "vexpress-spc: "
+
+/* SCC conf registers */
+#define A15_CONF		0x400
+#define SYS_INFO		0x700
+
+/* SPC registers base */
+#define SPC_BASE		0xB00
+
+/* SPC wake-up IRQs status and mask */
+#define WAKE_INT_MASK		(SPC_BASE + 0x24)
+#define WAKE_INT_RAW		(SPC_BASE + 0x28)
+#define WAKE_INT_STAT		(SPC_BASE + 0x2c)
+/* SPC power down registers */
+#define A15_PWRDN_EN		(SPC_BASE + 0x30)
+#define A7_PWRDN_EN		(SPC_BASE + 0x34)
+/* SPC per-CPU mailboxes */
+#define A15_BX_ADDR0		(SPC_BASE + 0x68)
+#define A7_BX_ADDR0		(SPC_BASE + 0x78)
+
+/* wake-up interrupt masks */
+#define GBL_WAKEUP_INT_MSK	(0x3 << 10)
+
+/* TC2 static dual-cluster configuration */
+#define MAX_CLUSTERS		2
+
+struct ve_spc_drvdata {
+	void __iomem *baseaddr;
+	/*
+	 * A15s cluster identifier
+	 * It corresponds to A15 processors MPIDR[15:8] bitfield
+	 */
+	u32 a15_clusid;
+};
+
+static struct ve_spc_drvdata *info;
+
+static inline bool cluster_is_a15(u32 cluster)
+{
+	return cluster == info->a15_clusid;
+}
+
+/**
+ * ve_spc_global_wakeup_irq()
+ *
+ * Function to set/clear global wakeup IRQs. Not protected by locking since
+ * it might be used in code paths where normal cacheable locks are not
+ * working. Locking must be provided by the caller to ensure atomicity.
+ *
+ * @set: if true, global wake-up IRQs are set, if false they are cleared
+ */
+void ve_spc_global_wakeup_irq(bool set)
+{
+	u32 reg;
+
+	reg = readl_relaxed(info->baseaddr + WAKE_INT_MASK);
+
+	if (set)
+		reg |= GBL_WAKEUP_INT_MSK;
+	else
+		reg &= ~GBL_WAKEUP_INT_MSK;
+
+	writel_relaxed(reg, info->baseaddr + WAKE_INT_MASK);
+}
+
+/**
+ * ve_spc_cpu_wakeup_irq()
+ *
+ * Function to set/clear per-CPU wake-up IRQs. Not protected by locking since
+ * it might be used in code paths where normal cacheable locks are not
+ * working. Locking must be provided by the caller to ensure atomicity.
+ *
+ * @cluster: mpidr[15:8] bitfield describing cluster affinity level
+ * @cpu: mpidr[7:0] bitfield describing cpu affinity level
+ * @set: if true, wake-up IRQs are set, if false they are cleared
+ */
+void ve_spc_cpu_wakeup_irq(u32 cluster, u32 cpu, bool set)
+{
+	u32 mask, reg;
+
+	if (cluster >= MAX_CLUSTERS)
+		return;
+
+	mask = 1 << cpu;
+
+	if (!cluster_is_a15(cluster))
+		mask <<= 4;
+
+	reg = readl_relaxed(info->baseaddr + WAKE_INT_MASK);
+
+	if (set)
+		reg |= mask;
+	else
+		reg &= ~mask;
+
+	writel_relaxed(reg, info->baseaddr + WAKE_INT_MASK);
+}
+
+/**
+ * ve_spc_set_resume_addr() - set the jump address used for warm boot
+ *
+ * @cluster: mpidr[15:8] bitfield describing cluster affinity level
+ * @cpu: mpidr[7:0] bitfield describing cpu affinity level
+ * @addr: physical resume address
+ */
+void ve_spc_set_resume_addr(u32 cluster, u32 cpu, u32 addr)
+{
+	void __iomem *baseaddr;
+
+	if (cluster >= MAX_CLUSTERS)
+		return;
+
+	if (cluster_is_a15(cluster))
+		baseaddr = info->baseaddr + A15_BX_ADDR0 + (cpu << 2);
+	else
+		baseaddr = info->baseaddr + A7_BX_ADDR0 + (cpu << 2);
+
+	writel_relaxed(addr, baseaddr);
+}
+
+/**
+ * ve_spc_get_nr_cpus() - get number of cpus in a cluster
+ *
+ * @cluster: mpidr[15:8] bitfield describing cluster affinity level
+ *
+ * Return: > 0 number of cpus in the cluster
+ *         or 0 if cluster number invalid
+ */
+u32 ve_spc_get_nr_cpus(u32 cluster)
+{
+	u32 val;
+
+	if (cluster >= MAX_CLUSTERS)
+		return 0;
+
+	val = readl_relaxed(info->baseaddr + SYS_INFO);
+	val = cluster_is_a15(cluster) ? (val >> 16) : (val >> 20);
+	return val & 0xf;
+}
+
+/**
+ * ve_spc_powerdown()
+ *
+ * Function to enable/disable cluster powerdown. Not protected by locking
+ * since it might be used in code paths where normal cacheable locks are not
+ * working. Locking must be provided by the caller to ensure atomicity.
+ *
+ * @cluster: mpidr[15:8] bitfield describing cluster affinity level
+ * @enable: if true enables powerdown, if false disables it
+ */
+void ve_spc_powerdown(u32 cluster, bool enable)
+{
+	u32 pwdrn_reg;
+
+	if (cluster >= MAX_CLUSTERS)
+		return;
+
+	pwdrn_reg = cluster_is_a15(cluster) ? A15_PWRDN_EN : A7_PWRDN_EN;
+	writel_relaxed(enable, info->baseaddr + pwdrn_reg);
+}
+
+static const struct of_device_id ve_spc_ids[] __initconst = {
+	{ .compatible = "arm,vexpress-spc,v2p-ca15_a7" },
+	{ .compatible = "arm,vexpress-spc" },
+	{},
+};
+
+static int __init ve_spc_probe(void)
+{
+	int ret;
+	struct device_node *node = of_find_matching_node(NULL, ve_spc_ids);
+
+	if (!node)
+		return -ENODEV;
+
+	info = kzalloc(sizeof(*info), GFP_KERNEL);
+	if (!info) {
+		pr_err(SPCLOG "unable to allocate mem\n");
+		return -ENOMEM;
+	}
+
+	info->baseaddr = of_iomap(node, 0);
+	if (!info->baseaddr) {
+		pr_err(SPCLOG "unable to ioremap memory\n");
+		ret = -ENXIO;
+		goto mem_free;
+	}
+
+	info->a15_clusid = readl_relaxed(info->baseaddr + A15_CONF) & 0xf;
+
+	/*
+	 * Multi-cluster systems may need this data when non-coherent, during
+	 * cluster power-up/power-down. Make sure driver info reaches main
+	 * memory.
+	 */
+	sync_cache_w(info);
+	sync_cache_w(&info);
+	pr_info("vexpress-spc loaded at %p\n", info->baseaddr);
+	return 0;
+
+mem_free:
+	kfree(info);
+	return ret;
+}
+
+/**
+ * ve_spc_init()
+ *
+ * Function exported to manage pre early_initcall initialization.
+ * SPC code is needed very early in the boot process to bring CPUs out of
+ * reset and initialize power management back-end so an init interface is
+ * provided to platform code to allow early initialization. The init
+ * interface can be removed as soon as the DT layer and platform bus allow
+ * platform device creation and probing before SMP boot.
+ */
+int __init ve_spc_init(void)
+{
+	static int ve_spc_init_status __initdata = -EAGAIN;
+
+	if (ve_spc_init_status == -EAGAIN)
+		ve_spc_init_status = ve_spc_probe();
+
+	return ve_spc_init_status;
+}
+early_initcall(ve_spc_init);
diff --git a/include/linux/vexpress.h b/include/linux/vexpress.h
index 617c01b8f7..3e35556b22 100644
--- a/include/linux/vexpress.h
+++ b/include/linux/vexpress.h
@@ -124,4 +124,21 @@ void vexpress_osc_of_setup(struct device_node *node);
 void vexpress_clk_init(void __iomem *sp810_base);
 void vexpress_clk_of_init(void);
 
+/* SPC */
+
+#ifdef CONFIG_VEXPRESS_SPC
+int __init ve_spc_init(void);
+void ve_spc_global_wakeup_irq(bool set);
+void ve_spc_cpu_wakeup_irq(u32 cluster, u32 cpu, bool set);
+void ve_spc_set_resume_addr(u32 cluster, u32 cpu, u32 addr);
+u32 ve_spc_get_nr_cpus(u32 cluster);
+void ve_spc_powerdown(u32 cluster, bool enable);
+#else
+static inline int ve_spc_init(void) { return -ENODEV; }
+static inline void ve_spc_global_wakeup_irq(bool set) { }
+static inline void ve_spc_cpu_wakeup_irq(u32 cluster, u32 cpu, bool set) { }
+static inline void ve_spc_set_resume_addr(u32 cluster, u32 cpu, u32 addr) { }
+static inline u32 ve_spc_get_nr_cpus(u32 cluster) { return 0; }
+static inline void ve_spc_powerdown(u32 cluster, bool enable) { }
+#endif
 #endif
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Wed Jul 17 23:28:35 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Jul 2013 23:28:35 -0400
Subject: [PATCH 3/4] ARM: vexpress/TC2: basic PM support
In-Reply-To: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374118116-16836-4-git-send-email-nicolas.pitre@linaro.org>

This is the MCPM backend for the Virtual Express A15x2 A7x3 CoreTile
aka TC2.  This provides cluster management for SMP secondary boot and
CPU hotplug.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Pawel Moll <pawel.moll at arm.com>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/mach-vexpress/Kconfig  |   9 ++
 arch/arm/mach-vexpress/Makefile |   1 +
 arch/arm/mach-vexpress/tc2_pm.c | 287 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 297 insertions(+)
 create mode 100644 arch/arm/mach-vexpress/tc2_pm.c

diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index b8bbabec63..4b082f8912 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -66,4 +66,13 @@ config ARCH_VEXPRESS_DCSCB
 	  This is needed to provide CPU and cluster power management
 	  on RTSM implementing big.LITTLE.
 
+config ARCH_VEXPRESS_TC2_PM
+	bool "Versatile Express TC2 power management"
+	depends on MCPM
+	select VEXPRESS_SPC
+	select ARM_CCI
+	help
+	  Support for CPU and cluster power management on Versatile Express
+	  with a TC2 (A15x2 A7x3) big.LITTLE core tile.
+
 endmenu
diff --git a/arch/arm/mach-vexpress/Makefile b/arch/arm/mach-vexpress/Makefile
index 48ba89a814..0853da6395 100644
--- a/arch/arm/mach-vexpress/Makefile
+++ b/arch/arm/mach-vexpress/Makefile
@@ -7,5 +7,6 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
 obj-y					:= v2m.o
 obj-$(CONFIG_ARCH_VEXPRESS_CA9X4)	+= ct-ca9x4.o
 obj-$(CONFIG_ARCH_VEXPRESS_DCSCB)	+= dcscb.o	dcscb_setup.o
+obj-$(CONFIG_ARCH_VEXPRESS_TC2_PM)	+= tc2_pm.o
 obj-$(CONFIG_SMP)			+= platsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= hotplug.o
diff --git a/arch/arm/mach-vexpress/tc2_pm.c b/arch/arm/mach-vexpress/tc2_pm.c
new file mode 100644
index 0000000000..26dbe782fb
--- /dev/null
+++ b/arch/arm/mach-vexpress/tc2_pm.c
@@ -0,0 +1,287 @@
+/*
+ * arch/arm/mach-vexpress/tc2_pm.c - TC2 power management support
+ *
+ * Created by:	Nicolas Pitre, October 2012
+ * Copyright:	(C) 2012-2013  Linaro Limited
+ *
+ * Some portions of this file were originally written by Achin Gupta
+ * Copyright:   (C) 2012  ARM Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/spinlock.h>
+#include <linux/errno.h>
+
+#include <asm/mcpm.h>
+#include <asm/proc-fns.h>
+#include <asm/cacheflush.h>
+#include <asm/cputype.h>
+#include <asm/cp15.h>
+
+#include <linux/vexpress.h>
+#include <linux/arm-cci.h>
+
+/*
+ * We can't use regular spinlocks. In the switcher case, it is possible
+ * for an outbound CPU to call power_down() after its inbound counterpart
+ * is already live using the same logical CPU number which trips lockdep
+ * debugging.
+ */
+static arch_spinlock_t tc2_pm_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+
+#define TC2_CLUSTERS			2
+#define TC2_MAX_CPUS_PER_CLUSTER	3
+
+/* Keep per-cpu usage count to cope with unordered up/down requests */
+static int tc2_pm_use_count[TC2_MAX_CPUS_PER_CLUSTER][TC2_CLUSTERS];
+
+#define tc2_cluster_unused(cluster) \
+	(!tc2_pm_use_count[0][cluster] && \
+	 !tc2_pm_use_count[1][cluster] && \
+	 !tc2_pm_use_count[2][cluster])
+
+static int tc2_pm_power_up(unsigned int cpu, unsigned int cluster)
+{
+	pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
+	if (cluster >= TC2_CLUSTERS || cpu >= ve_spc_get_nr_cpus(cluster))
+		return -EINVAL;
+
+	/*
+	 * Since this is called with IRQs enabled, and no arch_spin_lock_irq
+	 * variant exists, we need to disable IRQs manually here.
+	 */
+	local_irq_disable();
+	arch_spin_lock(&tc2_pm_lock);
+
+	if (tc2_cluster_unused(cluster))
+		ve_spc_powerdown(cluster, false);
+
+	tc2_pm_use_count[cpu][cluster]++;
+	if (tc2_pm_use_count[cpu][cluster] == 1) {
+		ve_spc_set_resume_addr(cluster, cpu,
+				       virt_to_phys(mcpm_entry_point));
+		ve_spc_cpu_wakeup_irq(cluster, cpu, true);
+	} else if (tc2_pm_use_count[cpu][cluster] != 2) {
+		/*
+		 * The only possible values are:
+		 * 0 = CPU down
+		 * 1 = CPU (still) up
+		 * 2 = CPU requested to be up before it had a chance
+		 *     to actually make itself down.
+		 * Any other value is a bug.
+		 */
+		BUG();
+	}
+
+	arch_spin_unlock(&tc2_pm_lock);
+	local_irq_enable();
+
+	return 0;
+}
+
+static void tc2_pm_power_down(void)
+{
+	unsigned int mpidr, cpu, cluster;
+	bool last_man = false, skip_wfi = false;
+
+	mpidr = read_cpuid_mpidr();
+	cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+	cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+	pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
+	BUG_ON(cluster >= TC2_CLUSTERS || cpu >= TC2_MAX_CPUS_PER_CLUSTER);
+
+	__mcpm_cpu_going_down(cpu, cluster);
+
+	arch_spin_lock(&tc2_pm_lock);
+	BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
+	tc2_pm_use_count[cpu][cluster]--;
+	if (tc2_pm_use_count[cpu][cluster] == 0) {
+		ve_spc_cpu_wakeup_irq(cluster, cpu, true);
+		if (tc2_cluster_unused(cluster)) {
+			ve_spc_powerdown(cluster, true);
+			ve_spc_global_wakeup_irq(true);
+			last_man = true;
+		}
+	} else if (tc2_pm_use_count[cpu][cluster] == 1) {
+		/*
+		 * A power_up request went ahead of us.
+		 * Even if we do not want to shut this CPU down,
+		 * the caller expects a certain state as if the WFI
+		 * was aborted.  So let's continue with cache cleaning.
+		 */
+		skip_wfi = true;
+	} else
+		BUG();
+
+	if (last_man && __mcpm_outbound_enter_critical(cpu, cluster)) {
+		arch_spin_unlock(&tc2_pm_lock);
+
+		if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A15) {
+			/*
+			 * On the Cortex-A15 we need to disable
+			 * L2 prefetching before flushing the cache.
+			 */
+			asm volatile(
+			"mcr	p15, 1, %0, c15, c0, 3 \n\t"
+			"isb	\n\t"
+			"dsb	"
+			: : "r" (0x400) );
+		}
+
+		/*
+		 * We need to disable and flush the whole (L1 and L2) cache.
+		 * Let's do it in the safest possible way i.e. with
+		 * no memory access within the following sequence
+		 * including the stack.
+		 */
+		asm volatile(
+		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
+		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
+		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
+		"isb	\n\t"
+		"bl	v7_flush_dcache_all \n\t"
+		"clrex	\n\t"
+		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
+		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
+		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
+		"isb	\n\t"
+		"dsb	"
+		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
+		      "r9","r10","r11","lr","memory");
+
+		cci_disable_port_by_cpu(mpidr);
+
+		__mcpm_outbound_leave_critical(cluster, CLUSTER_DOWN);
+	} else {
+		/*
+		 * If last man then undo any setup done previously.
+		 */
+		if (last_man) {
+			ve_spc_powerdown(cluster, false);
+			ve_spc_global_wakeup_irq(false);
+		}
+
+		arch_spin_unlock(&tc2_pm_lock);
+
+		/*
+		 * We need to disable and flush only the L1 cache.
+		 * Let's do it in the safest possible way as above.
+		 */
+		asm volatile(
+		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
+		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
+		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
+		"isb	\n\t"
+		"bl	v7_flush_dcache_louis \n\t"
+		"clrex	\n\t"
+		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
+		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
+		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
+		"isb	\n\t"
+		"dsb	"
+		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
+		      "r9","r10","r11","lr","memory");
+	}
+
+	__mcpm_cpu_down(cpu, cluster);
+
+	/* Now we are prepared for power-down, do it: */
+	if (!skip_wfi)
+		wfi();
+
+	/* Not dead at this point?  Let our caller cope. */
+}
+
+static void tc2_pm_powered_up(void)
+{
+	unsigned int mpidr, cpu, cluster;
+	unsigned long flags;
+
+	mpidr = read_cpuid_mpidr();
+	cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+	cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+	pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
+	BUG_ON(cluster >= TC2_CLUSTERS || cpu >= TC2_MAX_CPUS_PER_CLUSTER);
+
+	local_irq_save(flags);
+	arch_spin_lock(&tc2_pm_lock);
+
+	if (tc2_cluster_unused(cluster)) {
+		ve_spc_powerdown(cluster, false);
+		ve_spc_global_wakeup_irq(false);
+	}
+
+	if (!tc2_pm_use_count[cpu][cluster])
+		tc2_pm_use_count[cpu][cluster] = 1;
+
+	ve_spc_cpu_wakeup_irq(cluster, cpu, false);
+	ve_spc_set_resume_addr(cluster, cpu, 0);
+
+	arch_spin_unlock(&tc2_pm_lock);
+	local_irq_restore(flags);
+}
+
+static const struct mcpm_platform_ops tc2_pm_power_ops = {
+	.power_up	= tc2_pm_power_up,
+	.power_down	= tc2_pm_power_down,
+	.powered_up	= tc2_pm_powered_up,
+};
+
+static bool __init tc2_pm_usage_count_init(void)
+{
+	unsigned int mpidr, cpu, cluster;
+
+	mpidr = read_cpuid_mpidr();
+	cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+	cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+	pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
+	if (cluster >= TC2_CLUSTERS || cpu >= ve_spc_get_nr_cpus(cluster)) {
+		pr_err("%s: boot CPU is out of bound!\n", __func__);
+		return false;
+	}
+	tc2_pm_use_count[cpu][cluster] = 1;
+	return true;
+}
+
+/*
+ * Enable cluster-level coherency, in preparation for turning on the MMU.
+ */
+static void __naked tc2_pm_power_up_setup(unsigned int affinity_level)
+{
+	asm volatile (" \n"
+"	cmp	r0, #1 \n"
+"	bxne	lr \n"
+"	b	cci_enable_port_for_self ");
+}
+
+static int __init tc2_pm_init(void)
+{
+	int ret;
+
+	ret = ve_spc_init();
+	if (ret)
+		return ret;
+
+	if (!cci_probed())
+		return -ENODEV;
+
+	if (!tc2_pm_usage_count_init())
+		return -EINVAL;
+
+	ret = mcpm_platform_register(&tc2_pm_power_ops);
+	if (!ret) {
+		mcpm_sync_init(tc2_pm_power_up_setup);
+		pr_info("TC2 power management initialized\n");
+	}
+	return ret;
+}
+
+early_initcall(tc2_pm_init);
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Wed Jul 17 23:28:36 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Jul 2013 23:28:36 -0400
Subject: [PATCH 4/4] ARM: vexpress/TC2: implement PM suspend method
In-Reply-To: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374118116-16836-5-git-send-email-nicolas.pitre@linaro.org>

From: Nicolas Pitre <nico at linaro.org>

Similar to power_down(), except that for a suspend, the firmware
mailbox address has to be set prior entering low power mode.

The residency argument is not used yet, so the last man always shuts
down the cluster for now.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Pawel Moll <pawel.moll at arm.com>
---
 arch/arm/mach-vexpress/tc2_pm.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-vexpress/tc2_pm.c b/arch/arm/mach-vexpress/tc2_pm.c
index 26dbe782fb..dfb55d45b6 100644
--- a/arch/arm/mach-vexpress/tc2_pm.c
+++ b/arch/arm/mach-vexpress/tc2_pm.c
@@ -84,7 +84,7 @@ static int tc2_pm_power_up(unsigned int cpu, unsigned int cluster)
 	return 0;
 }
 
-static void tc2_pm_power_down(void)
+static void tc2_pm_down(u64 residency)
 {
 	unsigned int mpidr, cpu, cluster;
 	bool last_man = false, skip_wfi = false;
@@ -198,6 +198,22 @@ static void tc2_pm_power_down(void)
 	/* Not dead at this point?  Let our caller cope. */
 }
 
+static void tc2_pm_power_down(void)
+{
+	tc2_pm_down(0);
+}
+
+static void tc2_pm_suspend(u64 residency)
+{
+	unsigned int mpidr, cpu, cluster;
+
+	mpidr = read_cpuid_mpidr();
+	cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+	cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+	ve_spc_set_resume_addr(cluster, cpu, virt_to_phys(mcpm_entry_point));
+	tc2_pm_down(residency);
+}
+
 static void tc2_pm_powered_up(void)
 {
 	unsigned int mpidr, cpu, cluster;
@@ -231,6 +247,7 @@ static void tc2_pm_powered_up(void)
 static const struct mcpm_platform_ops tc2_pm_power_ops = {
 	.power_up	= tc2_pm_power_up,
 	.power_down	= tc2_pm_power_down,
+	.suspend	= tc2_pm_suspend,
 	.powered_up	= tc2_pm_powered_up,
 };
 
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Wed Jul 17 23:28:33 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Jul 2013 23:28:33 -0400
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374118116-16836-2-git-send-email-nicolas.pitre@linaro.org>

Unlike real A15/A7's, the RTSM simulation doesn't appear to hit the
cache when the CTRL.C bit is cleared.  Let's ensure there is no memory
access within the disable and flush cache sequence, including to the
stack.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/mach-vexpress/dcscb.c | 58 +++++++++++++++++++++++++++---------------
 1 file changed, 37 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-vexpress/dcscb.c b/arch/arm/mach-vexpress/dcscb.c
index 16d57a8a9d..9f01c04d58 100644
--- a/arch/arm/mach-vexpress/dcscb.c
+++ b/arch/arm/mach-vexpress/dcscb.c
@@ -136,14 +136,29 @@ static void dcscb_power_down(void)
 		/*
 		 * Flush all cache levels for this cluster.
 		 *
-		 * A15/A7 can hit in the cache with SCTLR.C=0, so we don't need
-		 * a preliminary flush here for those CPUs.  At least, that's
-		 * the theory -- without the extra flush, Linux explodes on
-		 * RTSM (to be investigated).
+		 * To do so we do:
+		 * - Clear the CTLR.C bit to prevent further cache allocations
+		 * - Flush the whole cache
+		 * - Disable local coherency by clearing the ACTLR "SMP" bit
+		 *
+		 * Let's do it in the safest possible way i.e. with
+		 * no memory access within the following sequence
+		 * including the stack.
 		 */
-		flush_cache_all();
-		set_cr(get_cr() & ~CR_C);
-		flush_cache_all();
+		asm volatile(
+		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
+		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
+		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
+		"isb	\n\t"
+		"bl	v7_flush_dcache_all \n\t"
+		"clrex	\n\t"
+		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
+		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
+		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
+		"isb	\n\t"
+		"dsb	"
+		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
+		      "r9","r10","r11","lr","memory");
 
 		/*
 		 * This is a harmless no-op.  On platforms with a real
@@ -152,9 +167,6 @@ static void dcscb_power_down(void)
 		 */
 		outer_flush_all();
 
-		/* Disable local coherency by clearing the ACTLR "SMP" bit: */
-		set_auxcr(get_auxcr() & ~(1 << 6));
-
 		/*
 		 * Disable cluster-level coherency by masking
 		 * incoming snoops and DVM messages:
@@ -167,18 +179,22 @@ static void dcscb_power_down(void)
 
 		/*
 		 * Flush the local CPU cache.
-		 *
-		 * A15/A7 can hit in the cache with SCTLR.C=0, so we don't need
-		 * a preliminary flush here for those CPUs.  At least, that's
-		 * the theory -- without the extra flush, Linux explodes on
-		 * RTSM (to be investigated).
+		 * Let's do it in the safest possible way as above.
 		 */
-		flush_cache_louis();
-		set_cr(get_cr() & ~CR_C);
-		flush_cache_louis();
-
-		/* Disable local coherency by clearing the ACTLR "SMP" bit: */
-		set_auxcr(get_auxcr() & ~(1 << 6));
+		asm volatile(
+		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
+		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
+		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
+		"isb	\n\t"
+		"bl	v7_flush_dcache_louis \n\t"
+		"clrex	\n\t"
+		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
+		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
+		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
+		"isb	\n\t"
+		"dsb	"
+		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
+		      "r9","r10","r11","lr","memory");
 	}
 
 	__mcpm_cpu_down(cpu, cluster);
-- 
1.8.1.2



From john.stultz at linaro.org  Wed Jul 17 23:41:07 2013
From: john.stultz at linaro.org (John Stultz)
Date: Wed, 17 Jul 2013 20:41:07 -0700
Subject: [PATCH 0/3] Cleanup sched_clock.h users
In-Reply-To: <1374115161-675-1-git-send-email-sboyd@codeaurora.org>
References: <1374115161-675-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <51E763D3.4000308@linaro.org>

On 07/17/2013 07:39 PM, Stephen Boyd wrote:
> This patchset cleans up the last few stragglers using the sched_clock.h
> header file in asm and removes the asm header.
>
> A new one appeared in drivers/clocksource so I'm not sure who
> wants to take that one.

Thanks for doing this!

I'll queue the drivers/clocksource one on its own in a separate branch, 
that way I'll merge it into my own 3.12 queue, and Arnd/Olof can also 
merge just that change it in before they drop the asm/sched_clock.h header.

I just pushed it out here:

git://git.linaro.org/people/jstultz/linux.git fortglx/3.12/sched-clock-cleanups


thanks
-john


From festevam at gmail.com  Wed Jul 17 23:42:39 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 18 Jul 2013 00:42:39 -0300
Subject: [PATCH 1/2] ARM: dts: mx6: Add support for mx6q nitrogen board
Message-ID: <1374118960-19060-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

mx6q sabrelite and nitrogen boards are hardware compatible.

Boundary Devices have a line of nitrogen boards based on quad/dual-lite and solo
variants.

Let's consolidate the common peripheral nodes into imx6qdl-nitrogen.dtsi and
add support for the mx6 quad nitrogen board.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/Makefile              |   1 +
 arch/arm/boot/dts/imx6q-nitrogen.dts    |  27 ++++++
 arch/arm/boot/dts/imx6q-sabrelite.dts   | 152 +-----------------------------
 arch/arm/boot/dts/imx6qdl-nitrogen.dtsi | 160 ++++++++++++++++++++++++++++++++
 4 files changed, 189 insertions(+), 151 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6q-nitrogen.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-nitrogen.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ce1b3a3..eeb2275 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -128,6 +128,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx6dl-sabresd.dtb \
 	imx6dl-wandboard.dtb \
 	imx6q-arm2.dtb \
+	imx6q-nitrogen.dtb \
 	imx6q-phytec-pbab01.dtb \
 	imx6q-sabreauto.dtb \
 	imx6q-sabrelite.dtb \
diff --git a/arch/arm/boot/dts/imx6q-nitrogen.dts b/arch/arm/boot/dts/imx6q-nitrogen.dts
new file mode 100644
index 0000000..0ac5c59
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-nitrogen.dts
@@ -0,0 +1,27 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Fabio Estevam <fabio.estevam at freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-nitrogen.dtsi"
+
+/ {
+	model = "Boundary Devices i.MX6 Quad Nitrogen Board";
+	compatible = "boundary,imx6q-nitrogen", "fsl,imx6q";
+
+	memory {
+		reg = <0x10000000 0x40000000>;
+	};
+};
+
+&sata {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts b/arch/arm/boot/dts/imx6q-sabrelite.dts
index e0f4cd0..d7ed6f8 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -12,6 +12,7 @@
 
 /dts-v1/;
 #include "imx6q.dtsi"
+#include "imx6qdl-nitrogen.dtsi"
 
 / {
 	model = "Freescale i.MX6 Quad SABRE Lite Board";
@@ -20,155 +21,4 @@
 	memory {
 		reg = <0x10000000 0x40000000>;
 	};
-
-	regulators {
-		compatible = "simple-bus";
-
-		reg_2p5v: 2p5v {
-			compatible = "regulator-fixed";
-			regulator-name = "2P5V";
-			regulator-min-microvolt = <2500000>;
-			regulator-max-microvolt = <2500000>;
-			regulator-always-on;
-		};
-
-		reg_3p3v: 3p3v {
-			compatible = "regulator-fixed";
-			regulator-name = "3P3V";
-			regulator-min-microvolt = <3300000>;
-			regulator-max-microvolt = <3300000>;
-			regulator-always-on;
-		};
-
-		reg_usb_otg_vbus: usb_otg_vbus {
-			compatible = "regulator-fixed";
-			regulator-name = "usb_otg_vbus";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			gpio = <&gpio3 22 0>;
-			enable-active-high;
-		};
-	};
-
-	sound {
-		compatible = "fsl,imx6q-sabrelite-sgtl5000",
-			     "fsl,imx-audio-sgtl5000";
-		model = "imx6q-sabrelite-sgtl5000";
-		ssi-controller = <&ssi1>;
-		audio-codec = <&codec>;
-		audio-routing =
-			"MIC_IN", "Mic Jack",
-			"Mic Jack", "Mic Bias",
-			"Headphone Jack", "HP_OUT";
-		mux-int-port = <1>;
-		mux-ext-port = <4>;
-	};
-};
-
-&sata {
-	status = "okay";
-};
-
-&ecspi1 {
-	fsl,spi-num-chipselects = <1>;
-	cs-gpios = <&gpio3 19 0>;
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_ecspi1_1>;
-	status = "okay";
-
-	flash: m25p80 at 0 {
-		compatible = "sst,sst25vf016b";
-		spi-max-frequency = <20000000>;
-		reg = <0>;
-	};
-};
-
-&ssi1 {
-	fsl,mode = "i2s-slave";
-	status = "okay";
-};
-
-&iomuxc {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_hog>;
-
-	hog {
-		pinctrl_hog: hoggrp {
-			fsl,pins = <
-				MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x80000000
-				MX6QDL_PAD_NANDF_D7__GPIO2_IO07 0x80000000
-				MX6QDL_PAD_EIM_D19__GPIO3_IO19  0x80000000
-				MX6QDL_PAD_EIM_D22__GPIO3_IO22  0x80000000
-				MX6QDL_PAD_EIM_D23__GPIO3_IO23  0x80000000
-				MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x80000000
-				MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x1f0b0
-				MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x80000000
-			>;
-		};
-	};
-};
-
-&usbotg {
-	vbus-supply = <&reg_usb_otg_vbus>;
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_usbotg_1>;
-	disable-over-current;
-	status = "okay";
-};
-
-&usbh1 {
-	status = "okay";
-};
-
-&fec {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet_1>;
-	phy-mode = "rgmii";
-	phy-reset-gpios = <&gpio3 23 0>;
-	status = "okay";
-};
-
-&usdhc3 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_usdhc3_2>;
-	cd-gpios = <&gpio7 0 0>;
-	wp-gpios = <&gpio7 1 0>;
-	vmmc-supply = <&reg_3p3v>;
-	status = "okay";
-};
-
-&usdhc4 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_usdhc4_2>;
-	cd-gpios = <&gpio2 6 0>;
-	wp-gpios = <&gpio2 7 0>;
-	vmmc-supply = <&reg_3p3v>;
-	status = "okay";
-};
-
-&audmux {
-	status = "okay";
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_audmux_1>;
-};
-
-&uart2 {
-	status = "okay";
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_uart2_1>;
-};
-
-&i2c1 {
-	status = "okay";
-	clock-frequency = <100000>;
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_i2c1_1>;
-
-	codec: sgtl5000 at 0a {
-		compatible = "fsl,sgtl5000";
-		reg = <0x0a>;
-		clocks = <&clks 169>;
-		VDDA-supply = <&reg_2p5v>;
-		VDDIO-supply = <&reg_3p3v>;
-	};
 };
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen.dtsi
new file mode 100644
index 0000000..bdffa55
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen.dtsi
@@ -0,0 +1,160 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/ {
+	regulators {
+		compatible = "simple-bus";
+
+		reg_2p5v: 2p5v {
+			compatible = "regulator-fixed";
+			regulator-name = "2P5V";
+			regulator-min-microvolt = <2500000>;
+			regulator-max-microvolt = <2500000>;
+			regulator-always-on;
+		};
+
+		reg_3p3v: 3p3v {
+			compatible = "regulator-fixed";
+			regulator-name = "3P3V";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
+
+		reg_usb_otg_vbus: usb_otg_vbus {
+			compatible = "regulator-fixed";
+			regulator-name = "usb_otg_vbus";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			gpio = <&gpio3 22 0>;
+			enable-active-high;
+		};
+	};
+
+	sound {
+		compatible = "fsl,imx6q-sabrelite-sgtl5000",
+			     "fsl,imx-audio-sgtl5000";
+		model = "imx6q-sabrelite-sgtl5000";
+		ssi-controller = <&ssi1>;
+		audio-codec = <&codec>;
+		audio-routing =
+			"MIC_IN", "Mic Jack",
+			"Mic Jack", "Mic Bias",
+			"Headphone Jack", "HP_OUT";
+		mux-int-port = <1>;
+		mux-ext-port = <4>;
+	};
+};
+
+&ecspi1 {
+	fsl,spi-num-chipselects = <1>;
+	cs-gpios = <&gpio3 19 0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi1_1>;
+	status = "okay";
+
+	flash: m25p80 at 0 {
+		compatible = "sst,sst25vf016b";
+		spi-max-frequency = <20000000>;
+		reg = <0>;
+	};
+};
+
+&ssi1 {
+	fsl,mode = "i2s-slave";
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	hog {
+		pinctrl_hog: hoggrp {
+			fsl,pins = <
+				MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x80000000
+				MX6QDL_PAD_NANDF_D7__GPIO2_IO07 0x80000000
+				MX6QDL_PAD_EIM_D19__GPIO3_IO19  0x80000000
+				MX6QDL_PAD_EIM_D22__GPIO3_IO22  0x80000000
+				MX6QDL_PAD_EIM_D23__GPIO3_IO23  0x80000000
+				MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x80000000
+				MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x1f0b0
+				MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x80000000
+			>;
+		};
+	};
+};
+
+&usbotg {
+	vbus-supply = <&reg_usb_otg_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbotg_1>;
+	disable-over-current;
+	status = "okay";
+};
+
+&usbh1 {
+	status = "okay";
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet_1>;
+	phy-mode = "rgmii";
+	phy-reset-gpios = <&gpio3 23 0>;
+	status = "okay";
+};
+
+&usdhc3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc3_2>;
+	cd-gpios = <&gpio7 0 0>;
+	wp-gpios = <&gpio7 1 0>;
+	vmmc-supply = <&reg_3p3v>;
+	status = "okay";
+};
+
+&usdhc4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc4_2>;
+	cd-gpios = <&gpio2 6 0>;
+	wp-gpios = <&gpio2 7 0>;
+	vmmc-supply = <&reg_3p3v>;
+	status = "okay";
+};
+
+&audmux {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_audmux_1>;
+};
+
+&uart2 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2_1>;
+};
+
+&i2c1 {
+	status = "okay";
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1_1>;
+
+	codec: sgtl5000 at 0a {
+		compatible = "fsl,sgtl5000";
+		reg = <0x0a>;
+		clocks = <&clks 169>;
+		VDDA-supply = <&reg_2p5v>;
+		VDDIO-supply = <&reg_3p3v>;
+	};
+};
-- 
1.8.1.2



From festevam at gmail.com  Wed Jul 17 23:42:40 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 18 Jul 2013 00:42:40 -0300
Subject: [PATCH 2/2] ARM: dts: mx6: Add support for imx6dl nitrogen board
In-Reply-To: <1374118960-19060-1-git-send-email-festevam@gmail.com>
References: <1374118960-19060-1-git-send-email-festevam@gmail.com>
Message-ID: <1374118960-19060-2-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/Makefile            |  1 +
 arch/arm/boot/dts/imx6dl-nitrogen.dts | 23 +++++++++++++++++++++++
 2 files changed, 24 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-nitrogen.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index eeb2275..3f1a75d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -124,6 +124,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx53-mba53.dtb \
 	imx53-qsb.dtb \
 	imx53-smd.dtb \
+	imx6dl-nitrogen.dtb \
 	imx6dl-sabreauto.dtb \
 	imx6dl-sabresd.dtb \
 	imx6dl-wandboard.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-nitrogen.dts b/arch/arm/boot/dts/imx6dl-nitrogen.dts
new file mode 100644
index 0000000..4f29207
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-nitrogen.dts
@@ -0,0 +1,23 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Fabio Estevam <fabio.estevam at freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-nitrogen.dtsi"
+
+/ {
+	model = "Boundary Devices i.MX6 Dual Lite Nitrogen Board";
+	compatible = "boundary,imx6dl-nitrogen", "fsl,imx6dl";
+
+	memory {
+		reg = <0x10000000 0x40000000>;
+	};
+};
-- 
1.8.1.2



From kishon at ti.com  Thu Jul 18 02:03:17 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 11:33:17 +0530
Subject: [PATCH v9 1/8] drivers: phy: add generic PHY framework
In-Reply-To: <20130717172510.GB17093@kroah.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <1372247257-30186-2-git-send-email-kishon@ti.com>
 <20130717062944.GA24968@kroah.com> <51E664CB.8050906@ti.com>
 <20130717172510.GB17093@kroah.com>
Message-ID: <51E78525.9000802@ti.com>

Hi,

On Wednesday 17 July 2013 10:55 PM, Greg KH wrote:
> On Wed, Jul 17, 2013 at 03:02:59PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 17 July 2013 11:59 AM, Greg KH wrote:
>>> On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
>>>> +menuconfig GENERIC_PHY
>>>> +	tristate "PHY Subsystem"
>>>> +	help
>>>> +	  Generic PHY support.
>>>> +
>>>> +	  This framework is designed to provide a generic interface for PHY
>>>> +	  devices present in the kernel. This layer will have the generic
>>>> +	  API by which phy drivers can create PHY using the phy framework and
>>>> +	  phy users can obtain reference to the PHY.
>>>
>>> Shouldn't this be something that other drivers select?  How will anyone
>>> know if they need this or not?
>>
>> All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those
>> PHY drivers can be selected like in [1].
>> The PHY consumer driver should ideally use *depends on* in their Kconfig.
>>
>> [1] ->
>> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> 
> No, switch it around the other way.  How would I even _know_ that I need
> to enable the generic PHY subsystem in the first place?  How can I
> determine that I need this for my hardware?  You need to give hints to
> someone who doesn't even know what a PHY is, otherwise they will always
> disable it and move on.
> 
>>>> --- /dev/null
>>>> +++ b/drivers/phy/phy-core.c
>>>> @@ -0,0 +1,544 @@
>>>> +/*
>>>> + * phy-core.c  --  Generic Phy framework.
>>>> + *
>>>> + * Copyright (C) 2013 Texas Instruments
>>>> + *
>>>> + * Author: Kishon Vijay Abraham I <kishon at ti.com>
>>>> + *
>>>> + * This program is free software; you can redistribute  it and/or modify it
>>>> + * under  the terms of  the GNU General  Public License as published by the
>>>> + * Free Software Foundation;  either version 2 of the  License, or (at your
>>>> + * option) any later version.
>>>
>>> You really mean "any later version" (I have to ask)?
>>
>> That was copied from somewhere :-s
> 
> So, is that what you really mean to have for this code?

indeed.
> 
>>>> + * 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.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>>
>>> Are these two paragraphs needed?  This isn't a "program", and they got a
>>> copy of the GPL already with the kernel.
>>
>> hmm.. I can remove that.
>>>
>>>> +static struct class *phy_class;
>>>
>>> Why do you need a class?
>>
>> Wanted to group all the PHY drivers to be used by different subsystems
>> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
>> initial version [3] on using a bus_type instead of class but then it was
>> decided to go with class itself.
>>
>> [3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
> 
> Ok, but what does the class usage get you?

hmm.. actually I use class only to iterate through the list of devices in *phy*
class which could very well be implemented using list. Just that I wont have a
/sys/class/phy/ entry to find the list of phys added in the system. I dont
think I want to add any other stuff to expose to the user space at this point
of time.
> 
>>> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
>>> entry as well.
>>
>> I'm not actually adding any new sysfs entry other than what a *class_create*
>> must have created. Do I need to add one for that?
> 
> If you are not creating anything in sysfs at all, why use the driver
> model?  (hint, I think you need to do something here to justify it...)

Well.. it helps me to use pm_runtime to enable clocks utilizing the
parent-child relationship.

Thanks
Kishon


From gregkh at linuxfoundation.org  Thu Jul 18 02:24:47 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Wed, 17 Jul 2013 23:24:47 -0700
Subject: [PATCH v9 1/8] drivers: phy: add generic PHY framework
In-Reply-To: <51E78525.9000802@ti.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <1372247257-30186-2-git-send-email-kishon@ti.com>
 <20130717062944.GA24968@kroah.com> <51E664CB.8050906@ti.com>
 <20130717172510.GB17093@kroah.com> <51E78525.9000802@ti.com>
Message-ID: <20130718062447.GA19997@kroah.com>

On Thu, Jul 18, 2013 at 11:33:17AM +0530, Kishon Vijay Abraham I wrote:
> >> Wanted to group all the PHY drivers to be used by different subsystems
> >> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
> >> initial version [3] on using a bus_type instead of class but then it was
> >> decided to go with class itself.
> >>
> >> [3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
> > 
> > Ok, but what does the class usage get you?
> 
> hmm.. actually I use class only to iterate through the list of devices in *phy*
> class which could very well be implemented using list. Just that I wont have a
> /sys/class/phy/ entry to find the list of phys added in the system. I dont
> think I want to add any other stuff to expose to the user space at this point
> of time.
> > 
> >>> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
> >>> entry as well.
> >>
> >> I'm not actually adding any new sysfs entry other than what a *class_create*
> >> must have created. Do I need to add one for that?
> > 
> > If you are not creating anything in sysfs at all, why use the driver
> > model?  (hint, I think you need to do something here to justify it...)
> 
> Well.. it helps me to use pm_runtime to enable clocks utilizing the
> parent-child relationship.

Ok, that's a good reason for this, nevermind then.  Care to send the
latest patches you have in emails so I can review them?

thanks,

greg k-h


From kishon at ti.com  Thu Jul 18 02:27:20 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 11:57:20 +0530
Subject: [PATCH v9 1/8] drivers: phy: add generic PHY framework
In-Reply-To: <20130718062447.GA19997@kroah.com>
References: <1372247257-30186-1-git-send-email-kishon@ti.com>
 <1372247257-30186-2-git-send-email-kishon@ti.com>
 <20130717062944.GA24968@kroah.com> <51E664CB.8050906@ti.com>
 <20130717172510.GB17093@kroah.com> <51E78525.9000802@ti.com>
 <20130718062447.GA19997@kroah.com>
Message-ID: <51E78AC8.3020203@ti.com>

On Thursday 18 July 2013 11:54 AM, Greg KH wrote:
> On Thu, Jul 18, 2013 at 11:33:17AM +0530, Kishon Vijay Abraham I wrote:
>>>> Wanted to group all the PHY drivers to be used by different subsystems
>>>> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
>>>> initial version [3] on using a bus_type instead of class but then it was
>>>> decided to go with class itself.
>>>>
>>>> [3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
>>>
>>> Ok, but what does the class usage get you?
>>
>> hmm.. actually I use class only to iterate through the list of devices in *phy*
>> class which could very well be implemented using list. Just that I wont have a
>> /sys/class/phy/ entry to find the list of phys added in the system. I dont
>> think I want to add any other stuff to expose to the user space at this point
>> of time.
>>>
>>>>> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
>>>>> entry as well.
>>>>
>>>> I'm not actually adding any new sysfs entry other than what a *class_create*
>>>> must have created. Do I need to add one for that?
>>>
>>> If you are not creating anything in sysfs at all, why use the driver
>>> model?  (hint, I think you need to do something here to justify it...)
>>
>> Well.. it helps me to use pm_runtime to enable clocks utilizing the
>> parent-child relationship.
> 
> Ok, that's a good reason for this, nevermind then.  Care to send the
> latest patches you have in emails so I can review them?

Sure.

Thanks
Kishon


From s.hauer at pengutronix.de  Thu Jul 18 02:36:55 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 18 Jul 2013 08:36:55 +0200
Subject: [PATCH v2 3/3] mxs: added driver for OCOTP in i.MX23 and i.MX28
In-Reply-To: <1068003072.1131668.1374097392210.open-xchange@email.1und1.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
 <1374078460-4126-1-git-send-email-cb@sgoc.de>
 <1374078460-4126-4-git-send-email-cb@sgoc.de>
 <20130717192627.GA12533@pengutronix.de>
 <1068003072.1131668.1374097392210.open-xchange@email.1und1.de>
Message-ID: <20130718063655.GH10380@pengutronix.de>

On Wed, Jul 17, 2013 at 11:43:12PM +0200, Christoph G. Baumann wrote:
> Hello Sascha,
> 
> thanks for your input. I must admit that I didn't do a thorough review of the
> FSL code...
> 
> 
> > Sascha Hauer <s.hauer at pengutronix.de> hat am 17. Juli 2013 um 21:26
> > geschrieben:
> > [...]
> > > +static DEFINE_MUTEX(otp_mutex);
> > > +static struct kobject *otp_kobj;
> > > +static struct attribute **attrs;
> > > +static struct kobj_attribute *kattr;
> > > +static struct attribute_group attr_group;
> > > +static unsigned long otp_hclk_saved;
> > > +static u32 otp_voltage_saved;
> > > +static resource_size_t otp_base_address;
> > > +struct regulator *regu;
> >
> > Collect your driver data in a struct and pass it around in functions
> > calls. No need to limit this driver to a single instance.
> 
> The OTP device is unique in the CPU and several instances i.e. potential
> concurrent access is considered harmful. So I kept this construction
> from FSL.

Yes, this is single instance only in current SoCs. This is no reason
though to make the driver single instance capabable only. It's not
much work to change and it raises less eyebrows if it's properly
written.
In the end I never thought that there ever would be two instances of
the i.MX graphics subsystem (IPU). Now the i.MX6 has two of them...

> 
> 
> > > +static int otp_write_prepare(void)
> > > +{
> > > +? ? ?struct clk *hclk;
> > > +? ? ?int err = 0;
> > > +
> > > +? ? ?/* [1] HCLK to 24MHz. */
> > > +? ? ?hclk = clk_get_sys("hbus", NULL);
> >
> > This is a driver, so you should use regular clk_get, not clk_get_sys.
> > Besides, this has to be done during probe. clk_get takes a reference to
> > the clock which has to be released.
> 
> As far as I remember testing clk_get didn't work in this place.

That is because the clk_register_clkdev() in your other patch is wrong.

Look at the 'clocks' and 'clock-names' properties in the devicetree.
Also look at Documentation/devicetree/bindings/clock/imx28-clock.txt.

In short you have to add a clock to your devicetree node and then use
clk_get(). The struct device * passed to clk_get will make the bridge
between the device and the devicenode and the id argument will be the
same name as in the devicetree.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From voice.shen at atmel.com  Thu Jul 18 02:38:20 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu, 18 Jul 2013 14:38:20 +0800
Subject: [PATCH] ASoC: wm8904: fix the typo error for LINER Mux
Message-ID: <1374129500-5270-1-git-send-email-voice.shen@atmel.com>

fix the typo error, from "LINEL Mux" to "LINER Mux"

Signed-off-by: Bo Shen <voice.shen at atmel.com>
---
 sound/soc/codecs/wm8904.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm8904.c b/sound/soc/codecs/wm8904.c
index 3ff195c..bdd575a 100644
--- a/sound/soc/codecs/wm8904.c
+++ b/sound/soc/codecs/wm8904.c
@@ -1017,7 +1017,7 @@ static const struct soc_enum liner_enum =
 	SOC_ENUM_SINGLE(WM8904_ANALOGUE_OUT12_ZC, 0, 2, out_mux_text);
 
 static const struct snd_kcontrol_new liner_mux =
-	SOC_DAPM_ENUM("LINEL Mux", liner_enum);
+	SOC_DAPM_ENUM("LINER Mux", liner_enum);
 
 static const char *sidetone_text[] = {
 	"None", "Left", "Right"
-- 
1.7.9.5



From rogerq at ti.com  Thu Jul 18 02:44:36 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 18 Jul 2013 09:44:36 +0300
Subject: [PATCH 0/3] ARM: OMAP2+: omap_device: add dynamic pinctrl handling
In-Reply-To: <51E68E6C.60100@ti.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
 <51E686C1.8020801@ti.com> <51E68E6C.60100@ti.com>
Message-ID: <51E78ED4.2020107@ti.com>

On 07/17/2013 03:30 PM, Grygorii Strashko wrote:
> On 07/17/2013 02:57 PM, Roger Quadros wrote:
>> Hi Grygorii,
>>
>> On 07/17/2013 02:41 PM, Grygorii Strashko wrote:
>>> Hi Tony, Kevin
>>>
>>> This patch series introduces dynamic pinctrl handling in OMAP device framework
>>> in the same way as it was before switching to DT.
>>> This allow OMAP devices driver's developers to simply add dynamic pinctrl
>>> handling for "default", "active", "idle", "sleep" PIN states in their drivers
>>> by modifying DT definitions only - no modifications in drivers code are not needed.
>>>
>>
>> Overall I like the idea but can we make a provision for device drivers to override
>> this default pin state handling?
>>
>> The OMAP EHCI driver is one such special case where the wakeup mechanism is tied to pinctrl states
>> as it uses IO daisy chaining to implement wakeup.
>> So depending on whether wakeup needs to be enabled or not I must be able to chose whether
>> I put the pin in just "sleep" state or "sleep with wakeup" state.
> 
> I think, in this case you can't use default behavior and need to define
> custom pins states like "sleep_wakeup"/"sleep_no_wakeup" and do not
> define pins state with name "sleep', so Device core and OMAP device
> framework will not touch your pins.

Yes, I think this should be fine. Thanks.

cheers,
-roger


From kishon at ti.com  Thu Jul 18 02:46:09 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:09 +0530
Subject: [PATCH 00/15] PHY framework
Message-ID: <1374129984-765-1-git-send-email-kishon@ti.com>

Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle.

This framework will be of use only to devices that uses external PHY (PHY
functionality is not embedded within the controller).

The intention of creating this framework is to bring the phy drivers spread
all over the Linux kernel to drivers/phy to increase code re-use and to
increase code maintainability.

Comments to make PHY as bus wasn't done because PHY devices can be part of
other bus and making a same device attached to multiple bus leads to bad
design.

If the PHY driver has to send notification on connect/disconnect, the PHY
driver should make use of the extcon framework. Using this susbsystem
to use extcon framwork will have to be analysed.

Exynos MIPI CSIS/DSIM PHY and Displayport PHY have started using this
framework. Have included those patches also in this series.

twl4030-usb and omap-usb2 have also been adapted to this framework.

These patches are also available @
git://gitorious.org/linuxphy/linuxphy.git tags/phy-for-v3.12

Jingoo Han (3):
  phy: Add driver for Exynos DP PHY
  video: exynos_dp: remove non-DT support for Exynos Display Port
  video: exynos_dp: Use the generic PHY driver

Kishon Vijay Abraham I (8):
  drivers: phy: add generic PHY framework
  usb: phy: omap-usb2: use the new generic PHY framework
  usb: phy: twl4030: use the new generic PHY framework
  ARM: OMAP: USB: Add phy binding information
  ARM: dts: omap: update usb_otg_hs data
  usb: musb: omap2430: use the new generic PHY framework
  usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
  usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

Sylwester Nawrocki (4):
  phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
  video: exynos_mipi_dsim: Use the generic PHY driver
  exynos4-is: Use the generic MIPI CSIS PHY driver
  ARM: Samsung: Remove the MIPI PHY setup code

 .../devicetree/bindings/phy/phy-bindings.txt       |   66 +++
 .../devicetree/bindings/phy/samsung-phy.txt        |   22 +
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 +
 .../devicetree/bindings/video/exynos_dp.txt        |   18 +-
 Documentation/phy.txt                              |  129 +++++
 MAINTAINERS                                        |    7 +
 arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 +
 arch/arm/boot/dts/omap3-evm.dts                    |    2 +
 arch/arm/boot/dts/omap3-overo.dtsi                 |    2 +
 arch/arm/boot/dts/omap4.dtsi                       |    3 +
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 arch/arm/mach-exynos/include/mach/regs-pmu.h       |    5 -
 arch/arm/mach-omap2/usb-musb.c                     |    3 +
 arch/arm/mach-s5pv210/include/mach/regs-clock.h    |    4 -
 arch/arm/plat-samsung/Kconfig                      |    5 -
 arch/arm/plat-samsung/Makefile                     |    1 -
 arch/arm/plat-samsung/setup-mipiphy.c              |   60 ---
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/media/platform/exynos4-is/mipi-csis.c      |   16 +-
 drivers/phy/Kconfig                                |   28 +
 drivers/phy/Makefile                               |    7 +
 drivers/phy/phy-core.c                             |  544 ++++++++++++++++++++
 drivers/phy/phy-exynos-dp-video.c                  |  111 ++++
 drivers/phy/phy-exynos-mipi-video.c                |  169 ++++++
 drivers/usb/musb/Kconfig                           |    1 +
 drivers/usb/musb/musb_core.c                       |    1 +
 drivers/usb/musb/musb_core.h                       |    3 +
 drivers/usb/musb/omap2430.c                        |   26 +-
 drivers/usb/phy/Kconfig                            |    1 +
 drivers/usb/phy/phy-omap-usb2.c                    |   60 ++-
 drivers/usb/phy/phy-twl4030-usb.c                  |   63 ++-
 drivers/video/exynos/Kconfig                       |    2 +-
 drivers/video/exynos/exynos_dp_core.c              |  132 ++---
 drivers/video/exynos/exynos_dp_core.h              |  110 ++++
 drivers/video/exynos/exynos_dp_reg.c               |    2 -
 drivers/video/exynos/exynos_mipi_dsi.c             |   19 +-
 include/linux/phy/phy.h                            |  344 +++++++++++++
 include/linux/platform_data/mipi-csis.h            |   11 +-
 include/linux/usb/musb.h                           |    3 +
 include/video/exynos_dp.h                          |  131 -----
 include/video/exynos_mipi_dsim.h                   |    6 +-
 43 files changed, 1746 insertions(+), 389 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/devicetree/bindings/phy/samsung-phy.txt
 create mode 100644 Documentation/phy.txt
 delete mode 100644 arch/arm/plat-samsung/setup-mipiphy.c
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 drivers/phy/phy-exynos-dp-video.c
 create mode 100644 drivers/phy/phy-exynos-mipi-video.c
 create mode 100644 include/linux/phy/phy.h
 delete mode 100644 include/video/exynos_dp.h

-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:10 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:10 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-2-git-send-email-kishon@ti.com>

The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.

PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Tested-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 .../devicetree/bindings/phy/phy-bindings.txt       |   66 +++
 Documentation/phy.txt                              |  129 +++++
 MAINTAINERS                                        |    7 +
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   13 +
 drivers/phy/Makefile                               |    5 +
 drivers/phy/phy-core.c                             |  544 ++++++++++++++++++++
 include/linux/phy/phy.h                            |  344 +++++++++++++
 9 files changed, 1112 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 0000000..8ae844f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,66 @@
+This document explains only the device tree data binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
+
+PHY device node
+===============
+
+Required Properties:
+#phy-cells:	Number of cells in a PHY specifier;  The meaning of all those
+		cells is defined by the binding for the phy node. The PHY
+		provider can use the values in cells to find the appropriate
+		PHY.
+
+For example:
+
+phys: phy {
+    compatible = "xxx";
+    reg = <...>;
+    .
+    .
+    #phy-cells = <1>;
+    .
+    .
+};
+
+That node describes an IP block (PHY provider) that implements 2 different PHYs.
+In order to differentiate between these 2 PHYs, an additonal specifier should be
+given while trying to get a reference to it.
+
+PHY user node
+=============
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+phy-names : the names of the PHY corresponding to the PHYs present in the
+	    *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss at xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&usb2_phy>, <&usb3_phy>;
+    phy-names = "usb2phy", "usb3phy";
+    .
+    .
+};
+
+This node represents a controller that uses two PHYs, one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss at xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&phys 1>;
+    phy-names = "usbphy";
+    .
+    .
+};
+
+This node represents a controller that uses one of the PHYs of the PHY provider
+device defined previously. Note that the phy handle has an additional specifier
+"1" to differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 0000000..05f8fda
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,129 @@
+			    PHY SUBSYSTEM
+		  Kishon Vijay Abraham I <kishon at ti.com>
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controllers have PHY functionality embedded into it and others use an external
+PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+The intention of creating this framework is to bring the PHY drivers spread
+all over the Linux kernel to drivers/phy to increase code re-use and for
+better code maintainability.
+
+This framework will be of use only to devices that use external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Registering/Unregistering the PHY provider
+
+PHY provider refers to an entity that implements one or more PHY instances.
+For the simple case where the PHY provider implements only a single instance of
+the PHY, the framework provides its own implementation of of_xlate in
+of_phy_simple_xlate. If the PHY provider implements multiple instances, it
+should provide its own implementation of of_xlate. of_xlate is used only for
+dt boot case.
+
+struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+
+__of_phy_provider_register and __devm_of_phy_provider_register can be used to
+register the phy_provider and it takes device, owner and of_xlate as
+arguments. For the dt boot case, all PHY providers should use one of the above
+2 APIs to register the PHY provider.
+
+void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider);
+void of_phy_provider_unregister(struct phy_provider *phy_provider);
+
+devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to
+unregister the PHY.
+
+3. Creating the PHY
+
+The PHY driver should create the PHY in order for other peripheral controllers
+to make use of it. The PHY framework provides 2 APIs to create the PHY.
+
+struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
+	const char *label);
+extern struct phy *devm_phy_create(struct device *dev, u8 id,
+        const struct phy_ops *ops, const char *label);
+
+The PHY drivers can use one of the above 2 APIs to create the PHY by passing
+the device pointer, id, phy ops, label and a driver data.
+phy_ops is a set of function pointers for performing PHY operations such as
+init, exit, power_on and power_off. *label* is mandatory for non-dt boot case
+and it should be unique as well.
+
+Inorder to dereference the private data (in phy_ops), the phy provider driver
+can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
+phy_ops to get back the private data.
+
+4. Getting a reference to the PHY
+
+Before the controller can make use of the PHY, it has to get a reference to
+it. This framework provides the following APIs to get a reference to the PHY.
+
+struct phy *phy_get(struct device *dev, const char *string);
+struct phy *devm_phy_get(struct device *dev, const char *string);
+
+phy_get and devm_phy_get can be used to get the PHY. In the case of dt boot,
+the string arguments should contain the phy name as given in the dt data and
+in the case of non-dt boot, it should contain the label of the PHY.
+The only difference between the two APIs is that devm_phy_get associates the
+device with the PHY using devres on successful PHY get. On driver detach,
+release function is invoked on the the devres data and devres data is freed.
+
+5. Releasing a reference to the PHY
+
+When the controller no longer needs the PHY, it has to release the reference
+to the PHY it has obtained using the APIs mentioned in the above section. The
+PHY framework provides 2 APIs to release a reference to the PHY.
+
+void phy_put(struct phy *phy);
+void devm_phy_put(struct device *dev, struct phy *phy);
+
+Both these APIs are used to release a reference to the PHY and devm_phy_put
+destroys the devres associated with this PHY.
+
+6. Destroying the PHY
+
+When the driver that created the PHY is unloaded, it should destroy the PHY it
+created using one of the following 2 APIs.
+
+void phy_destroy(struct phy *phy);
+void devm_phy_destroy(struct device *dev, struct phy *phy);
+
+Both these APIs destroy the PHY and devm_phy_destroy destroys the devres
+associated with this PHY.
+
+7. PM Runtime
+
+This subsystem is pm runtime enabled. So while creating the PHY,
+pm_runtime_enable of the phy device created by this subsystem is called and
+while destroying the PHY, pm_runtime_disable is called. Note that the phy
+device created by this subsystem will be a child of the device that calls
+phy_create (PHY provider device).
+
+So pm_runtime_get_sync of the phy_device created by this subsystem will invoke
+pm_runtime_get_sync of PHY provider device because of parent-child relationship.
+It should also be noted that phy_power_on and phy_power_off performs
+phy_pm_runtime_get_sync and phy_pm_runtime_put respectively.
+There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync,
+phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
+phy_pm_runtime_forbid for performing PM operations.
+
+8. DeviceTree Binding
+
+The documentation for PHY dt binding can be found @
+Documentation/devicetree/bindings/phy/phy-bindings.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index bf61e04..dd03889 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3594,6 +3594,13 @@ S:	Maintained
 F:	include/asm-generic
 F:	include/uapi/asm-generic
 
+GENERIC PHY FRAMEWORK
+M:	Kishon Vijay Abraham I <kishon at ti.com>
+L:	linux-kernel at vger.kernel.org
+S:	Supported
+F:	drivers/phy/
+F:	include/linux/phy/
+
 GENERIC UIO DRIVER FOR PCI DEVICES
 M:	"Michael S. Tsirkin" <mst at redhat.com>
 L:	kvm at vger.kernel.org
diff --git a/drivers/Kconfig b/drivers/Kconfig
index aa43b91..8f45144 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -166,4 +166,6 @@ source "drivers/reset/Kconfig"
 
 source "drivers/fmc/Kconfig"
 
+source "drivers/phy/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index ab93de8..687da89 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -8,6 +8,8 @@
 obj-y				+= irqchip/
 obj-y				+= bus/
 
+obj-$(CONFIG_GENERIC_PHY)	+= phy/
+
 # GPIO must come after pinctrl as gpios may need to mux pins etc
 obj-y				+= pinctrl/
 obj-y				+= gpio/
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
new file mode 100644
index 0000000..5f85909
--- /dev/null
+++ b/drivers/phy/Kconfig
@@ -0,0 +1,13 @@
+#
+# PHY
+#
+
+menuconfig GENERIC_PHY
+	tristate "PHY Subsystem"
+	help
+	  Generic PHY support.
+
+	  This framework is designed to provide a generic interface for PHY
+	  devices present in the kernel. This layer will have the generic
+	  API by which phy drivers can create PHY using the phy framework and
+	  phy users can obtain reference to the PHY.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
new file mode 100644
index 0000000..9e9560f
--- /dev/null
+++ b/drivers/phy/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 0000000..6c75dc3
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,544 @@
+/*
+ * phy-core.c  --  Generic Phy framework.
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I <kishon at ti.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/kernel.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/pm_runtime.h>
+
+static struct class *phy_class;
+static DEFINE_MUTEX(phy_provider_mutex);
+static LIST_HEAD(phy_provider_list);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_put(phy);
+}
+
+static void devm_phy_provider_release(struct device *dev, void *res)
+{
+	struct phy_provider *phy_provider = *(struct phy_provider **)res;
+
+	of_phy_provider_unregister(phy_provider);
+}
+
+static void devm_phy_consume(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_destroy(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+	return res == match_data;
+}
+
+static struct phy *phy_lookup(const char *phy_name)
+{
+	struct phy *phy;
+	struct device *dev;
+	struct class_dev_iter iter;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = to_phy(dev);
+		if (strcmp(phy->label, phy_name))
+			continue;
+
+		class_dev_iter_exit(&iter);
+		return phy;
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-ENODEV);
+}
+
+static struct phy_provider *of_phy_provider_lookup(struct device_node *node)
+{
+	struct phy_provider *phy_provider;
+
+	list_for_each_entry(phy_provider, &phy_provider_list, list) {
+		if (phy_provider->dev->of_node == node)
+			return phy_provider;
+	}
+
+	return ERR_PTR(-EPROBE_DEFER);
+}
+
+/**
+ * of_phy_get() - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Returns the phy associated with the given phandle value,
+ * after getting a refcount to it or -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded. This function uses of_xlate call back function provided
+ * while registering the phy_provider to find the phy instance.
+ */
+static struct phy *of_phy_get(struct device *dev, int index)
+{
+	int ret;
+	struct phy_provider *phy_provider;
+	struct phy *phy = NULL;
+	struct of_phandle_args args;
+
+	ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
+		index, &args);
+	if (ret) {
+		dev_dbg(dev, "failed to get phy in %s node\n",
+			dev->of_node->full_name);
+		return ERR_PTR(-ENODEV);
+	}
+
+	mutex_lock(&phy_provider_mutex);
+	phy_provider = of_phy_provider_lookup(args.np);
+	if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
+		phy = ERR_PTR(-EPROBE_DEFER);
+		goto err0;
+	}
+
+	phy = phy_provider->of_xlate(phy_provider->dev, &args);
+	module_put(phy_provider->owner);
+
+err0:
+	mutex_unlock(&phy_provider_mutex);
+	of_node_put(args.np);
+
+	return phy;
+}
+
+/**
+ * phy_put() - release the PHY
+ * @phy: the phy returned by phy_get()
+ *
+ * Releases a refcount the caller received from phy_get().
+ */
+void phy_put(struct phy *phy)
+{
+	if (IS_ERR(phy))
+		return;
+
+	module_put(phy->ops->owner);
+	put_device(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_put);
+
+/**
+ * devm_phy_put() - release the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_put
+ * to release the phy.
+ */
+void devm_phy_put(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_release, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_put);
+
+/**
+ * of_phy_simple_xlate() - returns the phy instance from phy provider
+ * @dev: the PHY provider device
+ * @args: of_phandle_args (not used here)
+ *
+ * Intended to be used by phy provider for the common case where #phy-cells is
+ * 0. For other cases where #phy-cells is greater than '0', the phy provider
+ * should provide a custom of_xlate function that reads the *args* and returns
+ * the appropriate phy.
+ */
+struct phy *of_phy_simple_xlate(struct device *dev, struct of_phandle_args
+	*args)
+{
+	struct phy *phy;
+	struct class_dev_iter iter;
+	struct device_node *node = dev->of_node;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = to_phy(dev);
+		if (node != phy->dev.of_node)
+			continue;
+
+		class_dev_iter_exit(&iter);
+		return phy;
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
+
+/**
+ * phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data or phy device name
+ * for non-dt case
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy.  The caller is responsible for
+ * calling phy_put() to release that count.
+ */
+struct phy *phy_get(struct device *dev, const char *string)
+{
+	int index = 0;
+	struct phy *phy = NULL;
+
+	if (string == NULL) {
+		dev_WARN(dev, "missing string\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (dev->of_node) {
+		index = of_property_match_string(dev->of_node, "phy-names",
+			string);
+		phy = of_phy_get(dev, index);
+		if (IS_ERR(phy)) {
+			dev_WARN(dev, "unable to find phy\n");
+			return phy;
+		}
+	} else {
+		phy = phy_lookup(string);
+		if (IS_ERR(phy)) {
+			dev_WARN(dev, "unable to find phy\n");
+			return phy;
+		}
+	}
+
+	if (!try_module_get(phy->ops->owner))
+		return ERR_PTR(-EPROBE_DEFER);
+
+	get_device(&phy->dev);
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(phy_get);
+
+/**
+ * devm_phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data or phy device name
+ * for non-dt case
+ *
+ * Gets the phy using phy_get(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_get(struct device *dev, const char *string)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_get(dev, string);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_get);
+
+/**
+ * phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
+	const char *label)
+{
+	int ret;
+	struct phy *phy;
+
+	if (!dev) {
+		dev_WARN(dev, "no device provided for PHY\n");
+		ret = -EINVAL;
+		goto err0;
+	}
+
+	phy = kzalloc(sizeof(*phy), GFP_KERNEL);
+	if (!phy) {
+		ret = -ENOMEM;
+		goto err0;
+	}
+
+	device_initialize(&phy->dev);
+	mutex_init(&phy->mutex);
+
+	phy->dev.class = phy_class;
+	phy->dev.parent = dev;
+	phy->dev.of_node = dev->of_node;
+	phy->id = id;
+	phy->ops = ops;
+	phy->label = kstrdup(label, GFP_KERNEL);
+
+	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
+	if (ret)
+		goto err1;
+
+	ret = device_add(&phy->dev);
+	if (ret)
+		goto err1;
+
+	if (pm_runtime_enabled(dev)) {
+		pm_runtime_enable(&phy->dev);
+		pm_runtime_no_callbacks(&phy->dev);
+	}
+
+	return phy;
+
+err1:
+	put_device(&phy->dev);
+	kfree(phy->label);
+	kfree(phy);
+
+err0:
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(phy_create);
+
+/**
+ * devm_phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ *
+ * Creates a new PHY device adding it to the PHY class.
+ * While at that, it also associates the device with the phy using devres.
+ * On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_consume, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_create(dev, id, ops, label);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_create);
+
+/**
+ * phy_destroy() - destroy the phy
+ * @phy: the phy to be destroyed
+ *
+ * Called to destroy the phy.
+ */
+void phy_destroy(struct phy *phy)
+{
+	pm_runtime_disable(&phy->dev);
+	device_unregister(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_destroy);
+
+/**
+ * devm_phy_destroy() - destroy the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_destroy
+ * to destroy the phy.
+ */
+void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_consume, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_destroy);
+
+/**
+ * __of_phy_provider_register() - create/register phy provider with the framework
+ * @dev: struct device of the phy provider
+ * @owner: the module owner containing of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy provider
+ *
+ * Creates struct phy_provider from dev and of_xlate function pointer.
+ * This is used in the case of dt boot for finding the phy instance from
+ * phy provider.
+ */
+struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	struct phy_provider *phy_provider;
+
+	phy_provider = kzalloc(sizeof(*phy_provider), GFP_KERNEL);
+	if (!phy_provider)
+		return ERR_PTR(-ENOMEM);
+
+	phy_provider->dev = dev;
+	phy_provider->owner = owner;
+	phy_provider->of_xlate = of_xlate;
+
+	mutex_lock(&phy_provider_mutex);
+	list_add_tail(&phy_provider->list, &phy_provider_list);
+	mutex_unlock(&phy_provider_mutex);
+
+	return phy_provider;
+}
+EXPORT_SYMBOL_GPL(__of_phy_provider_register);
+
+/**
+ * __devm_of_phy_provider_register() - create/register phy provider with the
+ * framework
+ * @dev: struct device of the phy provider
+ * @owner: the module owner containing of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy provider
+ *
+ * Creates struct phy_provider from dev and of_xlate function pointer.
+ * This is used in the case of dt boot for finding the phy instance from
+ * phy provider. While at that, it also associates the device with the
+ * phy provider using devres. On driver detach, release function is invoked
+ * on the devres data, then, devres data is freed.
+ */
+struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	struct phy_provider **ptr, *phy_provider;
+
+	ptr = devres_alloc(devm_phy_provider_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy_provider = __of_phy_provider_register(dev, owner, of_xlate);
+	if (!IS_ERR(phy_provider)) {
+		*ptr = phy_provider;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy_provider;
+}
+EXPORT_SYMBOL_GPL(__devm_of_phy_provider_register);
+
+/**
+ * of_phy_provider_unregister() - unregister phy provider from the framework
+ * @phy_provider: phy provider returned by of_phy_provider_register()
+ *
+ * Removes the phy_provider created using of_phy_provider_register().
+ */
+void of_phy_provider_unregister(struct phy_provider *phy_provider)
+{
+	if (IS_ERR(phy_provider))
+		return;
+
+	mutex_lock(&phy_provider_mutex);
+	list_del(&phy_provider->list);
+	kfree(phy_provider);
+	mutex_unlock(&phy_provider_mutex);
+}
+EXPORT_SYMBOL_GPL(of_phy_provider_unregister);
+
+/**
+ * devm_of_phy_provider_unregister() - remove phy provider from the framework
+ * @dev: struct device of the phy provider
+ *
+ * destroys the devres associated with this phy provider and invokes
+ * of_phy_provider_unregister to unregister the phy provider.
+ */
+void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider) {
+	int r;
+
+	r = devres_destroy(dev, devm_phy_provider_release, devm_phy_match,
+		phy_provider);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY provider device resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_provider_unregister);
+
+/**
+ * phy_release() - release the phy
+ * @dev: the dev member within phy
+ *
+ * When the last reference to the device is removed, it is called
+ * from the embedded kobject as release method.
+ */
+static void phy_release(struct device *dev)
+{
+	struct phy *phy;
+
+	phy = to_phy(dev);
+	dev_vdbg(dev, "releasing '%s'\n", dev_name(dev));
+	kfree(phy->label);
+	kfree(phy);
+}
+
+static int __init phy_core_init(void)
+{
+	phy_class = class_create(THIS_MODULE, "phy");
+	if (IS_ERR(phy_class)) {
+		pr_err("failed to create phy class --> %ld\n",
+			PTR_ERR(phy_class));
+		return PTR_ERR(phy_class);
+	}
+
+	phy_class->dev_release = phy_release;
+
+	return 0;
+}
+module_init(phy_core_init);
+
+static void __exit phy_core_exit(void)
+{
+	class_destroy(phy_class);
+}
+module_exit(phy_core_exit);
+
+MODULE_DESCRIPTION("Generic PHY Framework");
+MODULE_AUTHOR("Kishon Vijay Abraham I <kishon at ti.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
new file mode 100644
index 0000000..9351a16
--- /dev/null
+++ b/include/linux/phy/phy.h
@@ -0,0 +1,344 @@
+/*
+ * phy.h -- generic phy header file
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I <kishon at ti.com>
+ *
+ * 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 __DRIVERS_PHY_H
+#define __DRIVERS_PHY_H
+
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/device.h>
+#include <linux/pm_runtime.h>
+
+struct phy;
+
+/**
+ * struct phy_ops - set of function pointers for performing phy operations
+ * @init: operation to be performed for initializing phy
+ * @exit: operation to be performed while exiting
+ * @power_on: powering on the phy
+ * @power_off: powering off the phy
+ * @owner: the module owner containing the ops
+ */
+struct phy_ops {
+	int	(*init)(struct phy *phy);
+	int	(*exit)(struct phy *phy);
+	int	(*power_on)(struct phy *phy);
+	int	(*power_off)(struct phy *phy);
+	struct module *owner;
+};
+
+/**
+ * struct phy - represents the phy device
+ * @dev: phy device
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ * @mutex: mutex to protect phy_ops
+ * @init_count: used to protect when the PHY is used by multiple consumers
+ * @power_count: used to protect when the PHY is used by multiple consumers
+ */
+struct phy {
+	struct device		dev;
+	int			id;
+	const struct phy_ops	*ops;
+	const char		*label;
+	struct mutex		mutex;
+	int			init_count;
+	int			power_count;
+};
+
+/**
+ * struct phy_provider - represents the phy provider
+ * @dev: phy provider device
+ * @owner: the module owner having of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy pointer
+ * @list: to maintain a linked list of PHY providers
+ */
+struct phy_provider {
+	struct device		*dev;
+	struct module		*owner;
+	struct list_head	list;
+	struct phy * (*of_xlate)(struct device *dev,
+		struct of_phandle_args *args);
+};
+
+#define	to_phy(dev)	(container_of((dev), struct phy, dev))
+
+#define	of_phy_provider_register(dev, xlate)	\
+	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+#define	devm_of_phy_provider_register(dev, xlate)	\
+	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+static inline void phy_set_drvdata(struct phy *phy, void *data)
+{
+	dev_set_drvdata(&phy->dev, data);
+}
+
+static inline void *phy_get_drvdata(struct phy *phy)
+{
+	return dev_get_drvdata(&phy->dev);
+}
+
+#if IS_ENABLED(CONFIG_GENERIC_PHY)
+extern struct phy *phy_get(struct device *dev, const char *string);
+extern struct phy *devm_phy_get(struct device *dev, const char *string);
+extern void phy_put(struct phy *phy);
+extern void devm_phy_put(struct device *dev, struct phy *phy);
+extern struct phy *of_phy_simple_xlate(struct device *dev,
+	struct of_phandle_args *args);
+extern struct phy *phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label);
+extern struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label);
+extern void phy_destroy(struct phy *phy);
+extern void devm_phy_destroy(struct device *dev, struct phy *phy);
+extern struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+extern struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+extern void of_phy_provider_unregister(struct phy_provider *phy_provider);
+extern void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider);
+#else
+static inline struct phy *phy_get(struct device *dev, const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_get(struct device *dev, const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_put(struct phy *phy)
+{
+}
+
+static inline void devm_phy_put(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy *of_phy_simple_xlate(struct device *dev,
+	struct of_phandle_args *args)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_destroy(struct phy *phy)
+{
+}
+
+static inline void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy_provider *__of_phy_provider_register(
+	struct device *dev, struct module *owner, struct phy * (*of_xlate)(
+	struct device *dev, struct of_phandle_args *args))
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy_provider *__devm_of_phy_provider_register(struct device
+	*dev, struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void of_phy_provider_unregister(struct phy_provider *phy_provider)
+{
+}
+
+static inline void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider)
+{
+}
+#endif
+
+static inline int phy_pm_runtime_get(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_get(&phy->dev);
+}
+
+static inline int phy_pm_runtime_get_sync(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_get_sync(&phy->dev);
+}
+
+static inline int phy_pm_runtime_put(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_put(&phy->dev);
+}
+
+static inline int phy_pm_runtime_put_sync(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_put_sync(&phy->dev);
+}
+
+static inline void phy_pm_runtime_allow(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return;
+
+	pm_runtime_allow(&phy->dev);
+}
+
+static inline void phy_pm_runtime_forbid(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return;
+
+	pm_runtime_forbid(&phy->dev);
+}
+
+static inline int phy_init(struct phy *phy)
+{
+	int ret;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (phy->init_count++ == 0 && phy->ops->init) {
+		ret = phy->ops->init(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy init failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+	return ret;
+}
+
+static inline int phy_exit(struct phy *phy)
+{
+	int ret;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (--phy->init_count == 0 && phy->ops->exit) {
+		ret = phy->ops->exit(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy exit failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+	return ret;
+}
+
+static inline int phy_power_on(struct phy *phy)
+{
+	int ret = -ENOTSUPP;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (phy->power_count++ == 0 && phy->ops->power_on) {
+		ret = phy->ops->power_on(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy poweron failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+
+	return ret;
+}
+
+static inline int phy_power_off(struct phy *phy)
+{
+	int ret = -ENOTSUPP;
+
+	mutex_lock(&phy->mutex);
+	if (--phy->power_count == 0 && phy->ops->power_off) {
+		ret =  phy->ops->power_off(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy poweroff failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+
+	return ret;
+}
+
+#endif /* __DRIVERS_PHY_H */
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:11 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:11 +0530
Subject: [PATCH 02/15] usb: phy: omap-usb2: use the new generic PHY framework
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-3-git-send-email-kishon@ti.com>

Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 drivers/usb/phy/Kconfig         |    1 +
 drivers/usb/phy/phy-omap-usb2.c |   45 +++++++++++++++++++++++++++++++++++----
 2 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 3622fff..cc55993 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -75,6 +75,7 @@ config OMAP_CONTROL_USB
 config OMAP_USB2
 	tristate "OMAP USB2 PHY Driver"
 	depends on ARCH_OMAP2PLUS
+	depends on GENERIC_PHY
 	select OMAP_CONTROL_USB
 	help
 	  Enable this to support the transceiver that is part of SOC. This
diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 844ab68..751b30f 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/delay.h>
 #include <linux/usb/omap_control_usb.h>
+#include <linux/phy/phy.h>
 
 /**
  * omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,10 +120,36 @@ static int omap_usb2_suspend(struct usb_phy *x, int suspend)
 	return 0;
 }
 
+static int omap_usb_power_off(struct phy *x)
+{
+	struct omap_usb *phy = phy_get_drvdata(x);
+
+	omap_control_usb_phy_power(phy->control_dev, 0);
+
+	return 0;
+}
+
+static int omap_usb_power_on(struct phy *x)
+{
+	struct omap_usb *phy = phy_get_drvdata(x);
+
+	omap_control_usb_phy_power(phy->control_dev, 1);
+
+	return 0;
+}
+
+static struct phy_ops ops = {
+	.power_on	= omap_usb_power_on,
+	.power_off	= omap_usb_power_off,
+	.owner		= THIS_MODULE,
+};
+
 static int omap_usb2_probe(struct platform_device *pdev)
 {
 	struct omap_usb			*phy;
+	struct phy			*generic_phy;
 	struct usb_otg			*otg;
+	struct phy_provider		*phy_provider;
 
 	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
 	if (!phy) {
@@ -144,6 +171,11 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
+	phy_provider = devm_of_phy_provider_register(phy->dev,
+			of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
 	phy->control_dev = omap_get_control_dev();
 	if (IS_ERR(phy->control_dev)) {
 		dev_dbg(&pdev->dev, "Failed to get control device\n");
@@ -159,6 +191,15 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	otg->start_srp		= omap_usb_start_srp;
 	otg->phy		= &phy->phy;
 
+	platform_set_drvdata(pdev, phy);
+	pm_runtime_enable(phy->dev);
+
+	generic_phy = devm_phy_create(phy->dev, 0, &ops, "omap-usb2");
+	if (IS_ERR(generic_phy))
+		return PTR_ERR(generic_phy);
+
+	phy_set_drvdata(generic_phy, phy);
+
 	phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");
 	if (IS_ERR(phy->wkupclk)) {
 		dev_err(&pdev->dev, "unable to get usb_phy_cm_clk32k\n");
@@ -174,10 +215,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
 	usb_add_phy_dev(&phy->phy);
 
-	platform_set_drvdata(pdev, phy);
-
-	pm_runtime_enable(phy->dev);
-
 	return 0;
 }
 
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:12 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:12 +0530
Subject: [PATCH 03/15] usb: phy: twl4030: use the new generic PHY framework
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-4-git-send-email-kishon@ti.com>

Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed.

However using the old usb phy library cannot be completely removed
because otg is intertwined with phy and moving to the new
framework completely will break otg. Once we have a separate otg state machine,
we can get rid of the usb phy library.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 drivers/usb/phy/phy-twl4030-usb.c |   50 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..9051756 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -33,6 +33,7 @@
 #include <linux/io.h>
 #include <linux/delay.h>
 #include <linux/usb/otg.h>
+#include <linux/phy/phy.h>
 #include <linux/usb/musb-omap.h>
 #include <linux/usb/ulpi.h>
 #include <linux/i2c/twl.h>
@@ -431,6 +432,14 @@ static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
 	dev_dbg(twl->dev, "%s\n", __func__);
 }
 
+static int twl4030_phy_power_off(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	twl4030_phy_suspend(twl, 0);
+	return 0;
+}
+
 static void __twl4030_phy_resume(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
@@ -459,6 +468,14 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 	}
 }
 
+static int twl4030_phy_power_on(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	twl4030_phy_resume(twl);
+	return 0;
+}
+
 static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
 {
 	/* Enable writing to power configuration registers */
@@ -602,13 +619,22 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 	status = twl4030_usb_linkstat(twl);
 	twl->linkstat = status;
 
-	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
+	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
 		omap_musb_mailbox(twl->linkstat);
+		twl4030_phy_resume(twl);
+	}
 
 	sysfs_notify(&twl->dev->kobj, NULL, "vbus");
 	return 0;
 }
 
+static int twl4030_phy_init(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	return twl4030_usb_phy_init(&twl->phy);
+}
+
 static int twl4030_set_suspend(struct usb_phy *x, int suspend)
 {
 	struct twl4030_usb *twl = phy_to_twl(x);
@@ -646,13 +672,22 @@ static int twl4030_set_host(struct usb_otg *otg, struct usb_bus *host)
 	return 0;
 }
 
+static const struct phy_ops ops = {
+	.init		= twl4030_phy_init,
+	.power_on	= twl4030_phy_power_on,
+	.power_off	= twl4030_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
 static int twl4030_usb_probe(struct platform_device *pdev)
 {
 	struct twl4030_usb_data *pdata = pdev->dev.platform_data;
 	struct twl4030_usb	*twl;
+	struct phy		*phy;
 	int			status, err;
 	struct usb_otg		*otg;
 	struct device_node	*np = pdev->dev.of_node;
+	struct phy_provider	*phy_provider;
 
 	twl = devm_kzalloc(&pdev->dev, sizeof *twl, GFP_KERNEL);
 	if (!twl)
@@ -689,6 +724,19 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	otg->set_host		= twl4030_set_host;
 	otg->set_peripheral	= twl4030_set_peripheral;
 
+	phy_provider = devm_of_phy_provider_register(twl->dev,
+		of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	phy = devm_phy_create(twl->dev, 0, &ops, "twl4030");
+	if (IS_ERR(phy)) {
+		dev_dbg(&pdev->dev, "Failed to create PHY\n");
+		return PTR_ERR(phy);
+	}
+
+	phy_set_drvdata(phy, twl);
+
 	/* init spinlock for workqueue */
 	spin_lock_init(&twl->lock);
 
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:13 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:13 +0530
Subject: [PATCH 04/15] ARM: OMAP: USB: Add phy binding information
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-5-git-send-email-kishon@ti.com>

In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy device name) should be added in the platform
data of the controller.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/mach-omap2/usb-musb.c |    3 +++
 include/linux/usb/musb.h       |    3 +++
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 8c4de27..6aa7cbf 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,6 +85,9 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
 	musb_plat.mode = board_data->mode;
 	musb_plat.extvbus = board_data->extvbus;
 
+	if (cpu_is_omap34xx())
+		musb_plat.phy_label = "twl4030";
+
 	if (soc_is_am35xx()) {
 		oh_name = "am35x_otg_hs";
 		name = "musb-am35x";
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..596f8c8 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
 	/* for clk_get() */
 	const char	*clock;
 
+	/* phy label */
+	const char	*phy_label;
+
 	/* (HOST or OTG) switch VBUS on/off */
 	int		(*set_vbus)(struct device *dev, int is_on);
 
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:14 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:14 +0530
Subject: [PATCH 05/15] ARM: dts: omap: update usb_otg_hs data
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-6-git-send-email-kishon@ti.com>

Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +++++
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 ++++++
 arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 ++
 arch/arm/boot/dts/omap3-evm.dts                    |    2 ++
 arch/arm/boot/dts/omap3-overo.dtsi                 |    2 ++
 arch/arm/boot/dts/omap4.dtsi                       |    3 +++
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 7 files changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 57e71f6..825790d 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
  - power : Should be "50". This signifies the controller can supply up to
    100mA when operating in host mode.
  - usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phy* phandle.
 
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs at 4a0ab000 {
 	num-eps = <16>;
 	ram-bits = <12>;
 	ctrl-module = <&omap_control_usb>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 };
 
 Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
 Required properties:
  - compatible: Should be "ti,omap-usb2"
  - reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy at 4a0ad080 {
 	compatible = "ti,omap-usb2";
 	reg = <0x4a0ad080 0x58>;
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
 
 OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the registers
    filled in "reg".
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy at 4a084400 {
 	      <0x4a084c00 0x40>;
 	reg-names = "phy_rx", "phy_tx", "pll_ctrl";
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..533b2da 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -144,6 +144,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 7d4329d..4134dd0 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -70,6 +70,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
index 8f1abec..a461d2f 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -76,6 +76,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..1e8e2fe 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -520,6 +520,7 @@
 				compatible = "ti,omap-usb2";
 				reg = <0x4a0ad080 0x58>;
 				ctrl-module = <&omap_control_usb>;
+				#phy-cells = <0>;
 			};
 		};
 
@@ -658,6 +659,8 @@
 			interrupt-names = "mc", "dma";
 			ti,hwmods = "usb_otg_hs";
 			usb-phy = <&usb2_phy>;
+			phys = <&usb2_phy>;
+			phy-names = "usb2-phy";
 			multipoint = <1>;
 			num-eps = <16>;
 			ram-bits = <12>;
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index b3034da..ce4cd6f 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -80,6 +80,7 @@
 		usb1v8-supply = <&vusb1v8>;
 		usb3v1-supply = <&vusb3v1>;
 		usb_mode = <1>;
+		#phy-cells = <0>;
 	};
 
 	twl_pwm: pwm {
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:15 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:15 +0530
Subject: [PATCH 06/15] usb: musb: omap2430: use the new generic PHY framework
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-7-git-send-email-kishon@ti.com>

Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on and
power_off to align with the new PHY framework.

musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 drivers/usb/musb/Kconfig     |    1 +
 drivers/usb/musb/musb_core.c |    1 +
 drivers/usb/musb/musb_core.h |    3 +++
 drivers/usb/musb/omap2430.c  |   26 ++++++++++++++++++++------
 4 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 797e3fd..01381ac 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -76,6 +76,7 @@ config USB_MUSB_TUSB6010
 config USB_MUSB_OMAP2PLUS
 	tristate "OMAP2430 and onwards"
 	depends on ARCH_OMAP2PLUS
+	depends on GENERIC_PHY
 
 config USB_MUSB_AM35X
 	tristate "AM35x"
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 29a24ce..cca12c0 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1814,6 +1814,7 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
 	musb->min_power = plat->min_power;
 	musb->ops = plat->platform_ops;
 	musb->port_mode = plat->mode;
+	musb->phy_label = plat->phy_label;
 
 	/* The musb_platform_init() call:
 	 *   - adjusts musb->mregs
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7d341c3..8f017ab 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
 #include <linux/usb.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/musb.h>
+#include <linux/phy/phy.h>
 
 struct musb;
 struct musb_hw_ep;
@@ -346,6 +347,7 @@ struct musb {
 	u16			int_tx;
 
 	struct usb_phy		*xceiv;
+	struct phy		*phy;
 
 	int nIrq;
 	unsigned		irq_wake:1;
@@ -424,6 +426,7 @@ struct musb {
 	unsigned                double_buffer_not_ok:1;
 
 	struct musb_hdrc_config	*config;
+	const char		*phy_label;
 
 #ifdef MUSB_CONFIG_PROC_FS
 	struct proc_dir_entry *proc_entry;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 6708a3b..87dac0f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -348,11 +348,21 @@ static int omap2430_musb_init(struct musb *musb)
 	 * up through ULPI.  TWL4030-family PMICs include one,
 	 * which needs a driver, drivers aren't always needed.
 	 */
-	if (dev->parent->of_node)
+	if (dev->parent->of_node) {
+		musb->phy = devm_phy_get(dev->parent, "usb2-phy");
+
+		/* We can't totally remove musb->xceiv as of now because
+		 * musb core uses xceiv.state and xceiv.otg. Once we have
+		 * a separate state machine to handle otg, these can be moved
+		 * out of xceiv and then we can start using the generic PHY
+		 * framework
+		 */
 		musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
 		    "usb-phy", 0);
-	else
+	} else {
 		musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+		musb->phy = devm_phy_get(dev, musb->phy_label);
+	}
 
 	if (IS_ERR(musb->xceiv)) {
 		status = PTR_ERR(musb->xceiv);
@@ -364,6 +374,10 @@ static int omap2430_musb_init(struct musb *musb)
 		return -EPROBE_DEFER;
 	}
 
+	if (IS_ERR(musb->phy)) {
+		pr_err("HS USB OTG: no PHY configured\n");
+		return PTR_ERR(musb->phy);
+	}
 	musb->isr = omap2430_musb_interrupt;
 
 	status = pm_runtime_get_sync(dev);
@@ -397,7 +411,7 @@ static int omap2430_musb_init(struct musb *musb)
 	if (glue->status != OMAP_MUSB_UNKNOWN)
 		omap_musb_set_mailbox(glue);
 
-	usb_phy_init(musb->xceiv);
+	phy_init(musb->phy);
 
 	pm_runtime_put_noidle(musb->controller);
 	return 0;
@@ -460,6 +474,7 @@ static int omap2430_musb_exit(struct musb *musb)
 	del_timer_sync(&musb_idle_timer);
 
 	omap2430_low_level_exit(musb);
+	phy_exit(musb->phy);
 
 	return 0;
 }
@@ -633,7 +648,7 @@ static int omap2430_runtime_suspend(struct device *dev)
 				OTG_INTERFSEL);
 
 		omap2430_low_level_exit(musb);
-		usb_phy_set_suspend(musb->xceiv, 1);
+		phy_power_off(musb->phy);
 	}
 
 	return 0;
@@ -648,8 +663,7 @@ static int omap2430_runtime_resume(struct device *dev)
 		omap2430_low_level_init(musb);
 		musb_writel(musb->mregs, OTG_INTERFSEL,
 				musb->context.otg_interfsel);
-
-		usb_phy_set_suspend(musb->xceiv, 0);
+		phy_power_on(musb->phy);
 	}
 
 	return 0;
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:16 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:16 +0530
Subject: [PATCH 07/15] usb: phy: omap-usb2: remove *set_suspend* callback from
 omap-usb2
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-8-git-send-email-kishon@ti.com>

Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 drivers/usb/phy/phy-omap-usb2.c |   25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 751b30f..3f2b125 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -97,29 +97,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
 	return 0;
 }
 
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
-	u32 ret;
-	struct omap_usb *phy = phy_to_omapusb(x);
-
-	if (suspend && !phy->is_suspended) {
-		omap_control_usb_phy_power(phy->control_dev, 0);
-		pm_runtime_put_sync(phy->dev);
-		phy->is_suspended = 1;
-	} else if (!suspend && phy->is_suspended) {
-		ret = pm_runtime_get_sync(phy->dev);
-		if (ret < 0) {
-			dev_err(phy->dev, "get_sync failed with err %d\n",
-									ret);
-			return ret;
-		}
-		omap_control_usb_phy_power(phy->control_dev, 1);
-		phy->is_suspended = 0;
-	}
-
-	return 0;
-}
-
 static int omap_usb_power_off(struct phy *x)
 {
 	struct omap_usb *phy = phy_get_drvdata(x);
@@ -167,7 +144,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
 	phy->phy.dev		= phy->dev;
 	phy->phy.label		= "omap-usb2";
-	phy->phy.set_suspend	= omap_usb2_suspend;
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
@@ -182,7 +158,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	phy->is_suspended	= 1;
 	omap_control_usb_phy_power(phy->control_dev, 0);
 
 	otg->set_host		= omap_usb_set_host;
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:17 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:17 +0530
Subject: [PATCH 08/15] usb: phy: twl4030-usb: remove *set_suspend* and
 *phy_init* ops
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-9-git-send-email-kishon@ti.com>

Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 drivers/usb/phy/phy-twl4030-usb.c |   57 +++++++++----------------------------
 1 file changed, 13 insertions(+), 44 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 9051756..44f8b1b 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -422,25 +422,20 @@ static void twl4030_phy_power(struct twl4030_usb *twl, int on)
 	}
 }
 
-static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
+static int twl4030_phy_power_off(struct phy *phy)
 {
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
 	if (twl->asleep)
-		return;
+		return 0;
 
 	twl4030_phy_power(twl, 0);
 	twl->asleep = 1;
 	dev_dbg(twl->dev, "%s\n", __func__);
-}
-
-static int twl4030_phy_power_off(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	twl4030_phy_suspend(twl, 0);
 	return 0;
 }
 
-static void __twl4030_phy_resume(struct twl4030_usb *twl)
+static void __twl4030_phy_power_on(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
 	twl4030_i2c_access(twl, 1);
@@ -449,11 +444,13 @@ static void __twl4030_phy_resume(struct twl4030_usb *twl)
 		twl4030_i2c_access(twl, 0);
 }
 
-static void twl4030_phy_resume(struct twl4030_usb *twl)
+static int twl4030_phy_power_on(struct phy *phy)
 {
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
 	if (!twl->asleep)
-		return;
-	__twl4030_phy_resume(twl);
+		return 0;
+	__twl4030_phy_power_on(twl);
 	twl->asleep = 0;
 	dev_dbg(twl->dev, "%s\n", __func__);
 
@@ -466,13 +463,6 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 		cancel_delayed_work(&twl->id_workaround_work);
 		schedule_delayed_work(&twl->id_workaround_work, HZ);
 	}
-}
-
-static int twl4030_phy_power_on(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	twl4030_phy_resume(twl);
 	return 0;
 }
 
@@ -604,9 +594,9 @@ static void twl4030_id_workaround_work(struct work_struct *work)
 	}
 }
 
-static int twl4030_usb_phy_init(struct usb_phy *phy)
+static int twl4030_phy_init(struct phy *phy)
 {
-	struct twl4030_usb *twl = phy_to_twl(phy);
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
 	enum omap_musb_vbus_id_status status;
 
 	/*
@@ -621,32 +611,13 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 
 	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
 		omap_musb_mailbox(twl->linkstat);
-		twl4030_phy_resume(twl);
+		twl4030_phy_power_on(phy);
 	}
 
 	sysfs_notify(&twl->dev->kobj, NULL, "vbus");
 	return 0;
 }
 
-static int twl4030_phy_init(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	return twl4030_usb_phy_init(&twl->phy);
-}
-
-static int twl4030_set_suspend(struct usb_phy *x, int suspend)
-{
-	struct twl4030_usb *twl = phy_to_twl(x);
-
-	if (suspend)
-		twl4030_phy_suspend(twl, 1);
-	else
-		twl4030_phy_resume(twl);
-
-	return 0;
-}
-
 static int twl4030_set_peripheral(struct usb_otg *otg,
 					struct usb_gadget *gadget)
 {
@@ -717,8 +688,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	twl->phy.label		= "twl4030";
 	twl->phy.otg		= otg;
 	twl->phy.type		= USB_PHY_TYPE_USB2;
-	twl->phy.set_suspend	= twl4030_set_suspend;
-	twl->phy.init		= twl4030_usb_phy_init;
 
 	otg->phy		= &twl->phy;
 	otg->set_host		= twl4030_set_host;
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:18 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:18 +0530
Subject: [PATCH 09/15] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-10-git-send-email-kishon@ti.com>

From: Sylwester Nawrocki <s.nawrocki at samsung.com>

Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2
receiver and MIPI DSI transmitter DPHYs.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 .../devicetree/bindings/phy/samsung-phy.txt        |   14 ++
 drivers/phy/Kconfig                                |    9 ++
 drivers/phy/Makefile                               |    3 +-
 drivers/phy/phy-exynos-mipi-video.c                |  169 ++++++++++++++++++++
 4 files changed, 194 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/phy/samsung-phy.txt
 create mode 100644 drivers/phy/phy-exynos-mipi-video.c

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
new file mode 100644
index 0000000..5ff208c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -0,0 +1,14 @@
+Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY
+-------------------------------------------------
+
+Required properties:
+- compatible : should be "samsung,s5pv210-mipi-video-phy";
+- reg : offset and length of the MIPI DPHY register set;
+- #phy-cells : from the generic phy bindings, must be 1;
+
+For "samsung,s5pv210-mipi-video-phy" compatible PHYs the second cell in
+the PHY specifier identifies the PHY and its meaning is as follows:
+  0 - MIPI CSIS 0,
+  1 - MIPI DSIM 0,
+  2 - MIPI CSIS 1,
+  3 - MIPI DSIM 1.
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5f85909..6f446d0 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -11,3 +11,12 @@ menuconfig GENERIC_PHY
 	  devices present in the kernel. This layer will have the generic
 	  API by which phy drivers can create PHY using the phy framework and
 	  phy users can obtain reference to the PHY.
+
+if GENERIC_PHY
+
+config PHY_EXYNOS_MIPI_VIDEO
+	tristate "S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver"
+	help
+	  Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
+	  S5P and EXYNOS SoCs.
+endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..71d8841 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -2,4 +2,5 @@
 # Makefile for the phy drivers.
 #
 
-obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
+obj-$(CONFIG_GENERIC_PHY)		+= phy-core.o
+obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)	+= phy-exynos-mipi-video.o
diff --git a/drivers/phy/phy-exynos-mipi-video.c b/drivers/phy/phy-exynos-mipi-video.c
new file mode 100644
index 0000000..7e7fcd7
--- /dev/null
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -0,0 +1,169 @@
+/*
+ * Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Sylwester Nawrocki <s.nawrocki at samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+
+/* MIPI_PHYn_CONTROL register offset: n = 0..1 */
+#define EXYNOS_MIPI_PHY_CONTROL(n)	((n) * 4)
+#define EXYNOS_MIPI_PHY_ENABLE		(1 << 0)
+#define EXYNOS_MIPI_PHY_SRESETN		(1 << 1)
+#define EXYNOS_MIPI_PHY_MRESETN		(1 << 2)
+#define EXYNOS_MIPI_PHY_RESET_MASK	(3 << 1)
+
+enum exynos_mipi_phy_id {
+	EXYNOS_MIPI_PHY_ID_CSIS0,
+	EXYNOS_MIPI_PHY_ID_DSIM0,
+	EXYNOS_MIPI_PHY_ID_CSIS1,
+	EXYNOS_MIPI_PHY_ID_DSIM1,
+	EXYNOS_MIPI_PHYS_NUM
+};
+
+#define IS_EXYNOS_MIPI_DSIM_PHY_ID(id) \
+	((id) == EXYNOS_MIPI_PHY_ID_DSIM0 || (id) == EXYNOS_MIPI_PHY_ID_DSIM0)
+
+struct exynos_mipi_video_phy {
+	spinlock_t slock;
+	struct phy *phys[EXYNOS_MIPI_PHYS_NUM];
+	void __iomem *regs;
+};
+
+static int __set_phy_state(struct exynos_mipi_video_phy *state,
+			enum exynos_mipi_phy_id id, unsigned int on)
+{
+	void __iomem *addr;
+	u32 reg, reset;
+
+	addr = state->regs + EXYNOS_MIPI_PHY_CONTROL(id / 2);
+
+	if (IS_EXYNOS_MIPI_DSIM_PHY_ID(id))
+		reset = EXYNOS_MIPI_PHY_MRESETN;
+	else
+		reset = EXYNOS_MIPI_PHY_SRESETN;
+
+	spin_lock(&state->slock);
+	reg = readl(addr);
+	if (on)
+		reg |= reset;
+	else
+		reg &= ~reset;
+	writel(reg, addr);
+
+	/* Clear ENABLE bit only if MRESETN, SRESETN bits are not set. */
+	if (on)
+		reg |= EXYNOS_MIPI_PHY_ENABLE;
+	else if (!(reg & EXYNOS_MIPI_PHY_RESET_MASK))
+		reg &= ~EXYNOS_MIPI_PHY_ENABLE;
+
+	writel(reg, addr);
+	spin_unlock(&state->slock);
+	return 0;
+}
+
+static int exynos_mipi_video_phy_power_on(struct phy *phy)
+{
+	struct exynos_mipi_video_phy *state = phy_get_drvdata(phy);
+	return __set_phy_state(state, phy->id, 1);
+}
+
+static int exynos_mipi_video_phy_power_off(struct phy *phy)
+{
+	struct exynos_mipi_video_phy *state = phy_get_drvdata(phy);
+	return __set_phy_state(state, phy->id, 0);
+}
+
+static struct phy *exynos_mipi_video_phy_xlate(struct device *dev,
+					struct of_phandle_args *args)
+{
+	struct exynos_mipi_video_phy *state = dev_get_drvdata(dev);
+
+	if (WARN_ON(args->args[0] > EXYNOS_MIPI_PHYS_NUM))
+		return ERR_PTR(-ENODEV);
+
+	return state->phys[args->args[0]];
+}
+
+static struct phy_ops exynos_mipi_video_phy_ops = {
+	.power_on	= exynos_mipi_video_phy_power_on,
+	.power_off	= exynos_mipi_video_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
+static int exynos_mipi_video_phy_probe(struct platform_device *pdev)
+{
+	struct exynos_mipi_video_phy *state;
+	struct device *dev = &pdev->dev;
+	struct resource *res;
+	struct phy_provider *phy_provider;
+	int i;
+
+	state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
+	if (!state)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+	state->regs = devm_ioremap_resource(dev, res);
+	if (IS_ERR(state->regs))
+		return PTR_ERR(state->regs);
+
+	dev_set_drvdata(dev, state);
+	spin_lock_init(&state->slock);
+
+	phy_provider = devm_of_phy_provider_register(dev,
+					exynos_mipi_video_phy_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	for (i = 0; i < EXYNOS_MIPI_PHYS_NUM; i++) {
+		char label[8];
+
+		snprintf(label, sizeof(label), "%s.%d",
+				IS_EXYNOS_MIPI_DSIM_PHY_ID(i) ?
+				"dsim" : "csis", i / 2);
+
+		state->phys[i] = devm_phy_create(dev, i,
+				&exynos_mipi_video_phy_ops, label);
+		if (IS_ERR(state->phys[i])) {
+			dev_err(dev, "failed to create PHY %s\n", label);
+			return PTR_ERR(state->phys[i]);
+		}
+		phy_set_drvdata(state->phys[i], state);
+	}
+
+	return 0;
+}
+
+static const struct of_device_id exynos_mipi_video_phy_of_match[] = {
+	{ .compatible = "samsung,s5pv210-mipi-video-phy" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, exynos_mipi_video_phy_of_match);
+
+static struct platform_driver exynos_mipi_video_phy_driver = {
+	.probe	= exynos_mipi_video_phy_probe,
+	.driver = {
+		.of_match_table	= exynos_mipi_video_phy_of_match,
+		.name  = "exynos-mipi-video-phy",
+		.owner = THIS_MODULE,
+	}
+};
+module_platform_driver(exynos_mipi_video_phy_driver);
+
+MODULE_DESCRIPTION("Samsung S5P/EXYNOS SoC MIPI CSI-2/DSI PHY driver");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Sylwester Nawrocki <s.nawrocki at samsung.com>");
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:19 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:19 +0530
Subject: [PATCH 10/15] video: exynos_mipi_dsim: Use the generic PHY driver
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-11-git-send-email-kishon@ti.com>

From: Sylwester Nawrocki <s.nawrocki at samsung.com>

Use the generic PHY API instead of the platform callback to control
the MIPI DSIM DPHY. The 'phy_label' field is added to the platform
data structure to allow PHY lookup on non-dt platforms.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Acked-by: Donghwa Lee <dh09.lee at samsung.com>
Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/video/exynos/exynos_mipi_dsi.c |   19 ++++++++++---------
 include/video/exynos_mipi_dsim.h       |    6 ++++--
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index 32e5406..248e444 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -30,6 +30,7 @@
 #include <linux/interrupt.h>
 #include <linux/kthread.h>
 #include <linux/notifier.h>
+#include <linux/phy/phy.h>
 #include <linux/regulator/consumer.h>
 #include <linux/pm_runtime.h>
 #include <linux/err.h>
@@ -156,8 +157,7 @@ static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int power)
 		exynos_mipi_regulator_enable(dsim);
 
 		/* enable MIPI-DSI PHY. */
-		if (dsim->pd->phy_enable)
-			dsim->pd->phy_enable(pdev, true);
+		phy_power_on(dsim->phy);
 
 		clk_enable(dsim->clock);
 
@@ -373,6 +373,10 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	dsim->phy = devm_phy_get(&pdev->dev, dsim_pd->phy_label);
+	if (IS_ERR(dsim->phy))
+		return PTR_ERR(dsim->phy);
+
 	dsim->clock = devm_clk_get(&pdev->dev, "dsim0");
 	if (IS_ERR(dsim->clock)) {
 		dev_err(&pdev->dev, "failed to get dsim clock source\n");
@@ -439,8 +443,7 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
 	exynos_mipi_regulator_enable(dsim);
 
 	/* enable MIPI-DSI PHY. */
-	if (dsim->pd->phy_enable)
-		dsim->pd->phy_enable(pdev, true);
+	phy_power_on(dsim->phy);
 
 	exynos_mipi_update_cfg(dsim);
 
@@ -504,9 +507,8 @@ static int exynos_mipi_dsi_suspend(struct device *dev)
 	if (client_drv && client_drv->suspend)
 		client_drv->suspend(client_dev);
 
-	/* enable MIPI-DSI PHY. */
-	if (dsim->pd->phy_enable)
-		dsim->pd->phy_enable(pdev, false);
+	/* disable MIPI-DSI PHY. */
+	phy_power_off(dsim->phy);
 
 	clk_disable(dsim->clock);
 
@@ -536,8 +538,7 @@ static int exynos_mipi_dsi_resume(struct device *dev)
 	exynos_mipi_regulator_enable(dsim);
 
 	/* enable MIPI-DSI PHY. */
-	if (dsim->pd->phy_enable)
-		dsim->pd->phy_enable(pdev, true);
+	phy_power_on(dsim->phy);
 
 	clk_enable(dsim->clock);
 
diff --git a/include/video/exynos_mipi_dsim.h b/include/video/exynos_mipi_dsim.h
index 89dc88a..0e7e43b 100644
--- a/include/video/exynos_mipi_dsim.h
+++ b/include/video/exynos_mipi_dsim.h
@@ -216,6 +216,7 @@ struct mipi_dsim_config {
  *	automatically.
  * @e_clk_src: select byte clock source.
  * @pd: pointer to MIPI-DSI driver platform data.
+ * @phy: pointer to the generic PHY
  */
 struct mipi_dsim_device {
 	struct device			*dev;
@@ -236,6 +237,7 @@ struct mipi_dsim_device {
 	bool				suspended;
 
 	struct mipi_dsim_platform_data	*pd;
+	struct phy			*phy;
 };
 
 /*
@@ -248,7 +250,7 @@ struct mipi_dsim_device {
  * @enabled: indicate whether mipi controller got enabled or not.
  * @lcd_panel_info: pointer for lcd panel specific structure.
  *	this structure specifies width, height, timing and polarity and so on.
- * @phy_enable: pointer to a callback controlling D-PHY enable/reset
+ * @phy_label: the generic PHY label
  */
 struct mipi_dsim_platform_data {
 	char				lcd_panel_name[PANEL_NAME_SIZE];
@@ -257,7 +259,7 @@ struct mipi_dsim_platform_data {
 	unsigned int			enabled;
 	void				*lcd_panel_info;
 
-	int (*phy_enable)(struct platform_device *pdev, bool on);
+	const char			*phy_label;
 };
 
 /*
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:20 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:20 +0530
Subject: [PATCH 11/15] exynos4-is: Use the generic MIPI CSIS PHY driver
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-12-git-send-email-kishon@ti.com>

From: Sylwester Nawrocki <s.nawrocki at samsung.com>

Use the generic PHY API instead of the platform callback to control
the MIPI CSIS DPHY. The 'phy_label' field is added to the platform
data structure to allow PHY lookup on non-dt platforms

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Acked-by: Mauro Carvalho Chehab <mchehab at redhat.com>
Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/media/platform/exynos4-is/mipi-csis.c |   16 +++++++++++++---
 include/linux/platform_data/mipi-csis.h       |   11 ++---------
 2 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
index 0914230..94028ce 100644
--- a/drivers/media/platform/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/exynos4-is/mipi-csis.c
@@ -20,6 +20,7 @@
 #include <linux/memory.h>
 #include <linux/module.h>
 #include <linux/of.h>
+#include <linux/phy/phy.h>
 #include <linux/platform_data/mipi-csis.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
@@ -180,6 +181,7 @@ struct csis_drvdata {
  * @sd: v4l2_subdev associated with CSIS device instance
  * @index: the hardware instance index
  * @pdev: CSIS platform device
+ * @phy: pointer to the CSIS generic PHY
  * @regs: mmaped I/O registers memory
  * @supplies: CSIS regulator supplies
  * @clock: CSIS clocks
@@ -203,6 +205,8 @@ struct csis_state {
 	struct v4l2_subdev sd;
 	u8 index;
 	struct platform_device *pdev;
+	struct phy *phy;
+	const char *phy_label;
 	void __iomem *regs;
 	struct regulator_bulk_data supplies[CSIS_NUM_SUPPLIES];
 	struct clk *clock[NUM_CSIS_CLOCKS];
@@ -742,6 +746,7 @@ static int s5pcsis_get_platform_data(struct platform_device *pdev,
 	state->index = max(0, pdev->id);
 	state->max_num_lanes = state->index ? CSIS1_MAX_LANES :
 					      CSIS0_MAX_LANES;
+	state->phy_label = pdata->phy_label;
 	return 0;
 }
 
@@ -779,8 +784,9 @@ static int s5pcsis_parse_dt(struct platform_device *pdev,
 					"samsung,csis-wclk");
 
 	state->num_lanes = endpoint.bus.mipi_csi2.num_data_lanes;
-
 	of_node_put(node);
+
+	state->phy_label = "csis";
 	return 0;
 }
 #else
@@ -829,6 +835,10 @@ static int s5pcsis_probe(struct platform_device *pdev)
 		return -EINVAL;
 	}
 
+	state->phy = devm_phy_get(dev, state->phy_label);
+	if (IS_ERR(state->phy))
+		return PTR_ERR(state->phy);
+
 	mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	state->regs = devm_ioremap_resource(dev, mem_res);
 	if (IS_ERR(state->regs))
@@ -922,7 +932,7 @@ static int s5pcsis_pm_suspend(struct device *dev, bool runtime)
 	mutex_lock(&state->lock);
 	if (state->flags & ST_POWERED) {
 		s5pcsis_stop_stream(state);
-		ret = s5p_csis_phy_enable(state->index, false);
+		ret = phy_power_off(state->phy);
 		if (ret)
 			goto unlock;
 		ret = regulator_bulk_disable(CSIS_NUM_SUPPLIES,
@@ -958,7 +968,7 @@ static int s5pcsis_pm_resume(struct device *dev, bool runtime)
 					    state->supplies);
 		if (ret)
 			goto unlock;
-		ret = s5p_csis_phy_enable(state->index, true);
+		ret = phy_power_on(state->phy);
 		if (!ret) {
 			state->flags |= ST_POWERED;
 		} else {
diff --git a/include/linux/platform_data/mipi-csis.h b/include/linux/platform_data/mipi-csis.h
index bf34e17..9214317 100644
--- a/include/linux/platform_data/mipi-csis.h
+++ b/include/linux/platform_data/mipi-csis.h
@@ -17,21 +17,14 @@
  * @wclk_source: CSI wrapper clock selection: 0 - bus clock, 1 - ext. SCLK_CAM
  * @lanes:       number of data lanes used
  * @hs_settle:   HS-RX settle time
+ * @phy_label:	 the generic PHY label
  */
 struct s5p_platform_mipi_csis {
 	unsigned long clk_rate;
 	u8 wclk_source;
 	u8 lanes;
 	u8 hs_settle;
+	const char *phy_label;
 };
 
-/**
- * s5p_csis_phy_enable - global MIPI-CSI receiver D-PHY control
- * @id:     MIPI-CSIS harware instance index (0...1)
- * @on:     true to enable D-PHY and deassert its reset
- *          false to disable D-PHY
- * @return: 0 on success, or negative error code on failure
- */
-int s5p_csis_phy_enable(int id, bool on);
-
 #endif /* __PLAT_SAMSUNG_MIPI_CSIS_H_ */
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:21 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:21 +0530
Subject: [PATCH 12/15] ARM: Samsung: Remove the MIPI PHY setup code
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-13-git-send-email-kishon@ti.com>

From: Sylwester Nawrocki <s.nawrocki at samsung.com>

Generic PHY drivers are used to handle the MIPI CSIS and MIPI DSIM
DPHYs so we can remove now unused code at arch/arm/plat-samsung.
In case there is any board file for S5PV210 platforms using MIPI
CSIS/DSIM (not any upstream currently) it should use the generic
PHY API to bind the PHYs to respective PHY consumer drivers and
a platform device for the PHY provider should be defined.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Acked-by: Kukjin Kim <kgene.kim at samsung.com>
Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 arch/arm/mach-exynos/include/mach/regs-pmu.h    |    5 --
 arch/arm/mach-s5pv210/include/mach/regs-clock.h |    4 --
 arch/arm/plat-samsung/Kconfig                   |    5 --
 arch/arm/plat-samsung/Makefile                  |    1 -
 arch/arm/plat-samsung/setup-mipiphy.c           |   60 -----------------------
 5 files changed, 75 deletions(-)
 delete mode 100644 arch/arm/plat-samsung/setup-mipiphy.c

diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h b/arch/arm/mach-exynos/include/mach/regs-pmu.h
index 57344b7..2cdb63e 100644
--- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
+++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
@@ -44,11 +44,6 @@
 #define S5P_DAC_PHY_CONTROL			S5P_PMUREG(0x070C)
 #define S5P_DAC_PHY_ENABLE			(1 << 0)
 
-#define S5P_MIPI_DPHY_CONTROL(n)		S5P_PMUREG(0x0710 + (n) * 4)
-#define S5P_MIPI_DPHY_ENABLE			(1 << 0)
-#define S5P_MIPI_DPHY_SRESETN			(1 << 1)
-#define S5P_MIPI_DPHY_MRESETN			(1 << 2)
-
 #define S5P_INFORM0				S5P_PMUREG(0x0800)
 #define S5P_INFORM1				S5P_PMUREG(0x0804)
 #define S5P_INFORM2				S5P_PMUREG(0x0808)
diff --git a/arch/arm/mach-s5pv210/include/mach/regs-clock.h b/arch/arm/mach-s5pv210/include/mach/regs-clock.h
index 032de66..e345584 100644
--- a/arch/arm/mach-s5pv210/include/mach/regs-clock.h
+++ b/arch/arm/mach-s5pv210/include/mach/regs-clock.h
@@ -147,10 +147,6 @@
 #define S5P_HDMI_PHY_CONTROL	S5P_CLKREG(0xE804)
 #define S5P_USB_PHY_CONTROL	S5P_CLKREG(0xE80C)
 #define S5P_DAC_PHY_CONTROL	S5P_CLKREG(0xE810)
-#define S5P_MIPI_DPHY_CONTROL(x) S5P_CLKREG(0xE814)
-#define S5P_MIPI_DPHY_ENABLE	(1 << 0)
-#define S5P_MIPI_DPHY_SRESETN	(1 << 1)
-#define S5P_MIPI_DPHY_MRESETN	(1 << 2)
 
 #define S5P_INFORM0		S5P_CLKREG(0xF000)
 #define S5P_INFORM1		S5P_CLKREG(0xF004)
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 3dc5cbe..db2d814 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -402,11 +402,6 @@ config S3C24XX_PWM
 	  Support for exporting the PWM timer blocks via the pwm device
 	  system
 
-config S5P_SETUP_MIPIPHY
-	bool
-	help
-	  Compile in common setup code for MIPI-CSIS and MIPI-DSIM devices
-
 config S3C_SETUP_CAMIF
 	bool
 	help
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index 98d07d8..98f1e31 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -41,7 +41,6 @@ obj-$(CONFIG_S5P_DEV_UART)	+= s5p-dev-uart.o
 obj-$(CONFIG_SAMSUNG_DEV_BACKLIGHT)	+= dev-backlight.o
 
 obj-$(CONFIG_S3C_SETUP_CAMIF)	+= setup-camif.o
-obj-$(CONFIG_S5P_SETUP_MIPIPHY)	+= setup-mipiphy.o
 
 # DMA support
 
diff --git a/arch/arm/plat-samsung/setup-mipiphy.c b/arch/arm/plat-samsung/setup-mipiphy.c
deleted file mode 100644
index 66df315..0000000
--- a/arch/arm/plat-samsung/setup-mipiphy.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- *
- * S5P - Helper functions for MIPI-CSIS and MIPI-DSIM D-PHY control
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/export.h>
-#include <linux/kernel.h>
-#include <linux/platform_device.h>
-#include <linux/io.h>
-#include <linux/spinlock.h>
-#include <mach/regs-clock.h>
-
-static int __s5p_mipi_phy_control(int id, bool on, u32 reset)
-{
-	static DEFINE_SPINLOCK(lock);
-	void __iomem *addr;
-	unsigned long flags;
-	u32 cfg;
-
-	id = max(0, id);
-	if (id > 1)
-		return -EINVAL;
-
-	addr = S5P_MIPI_DPHY_CONTROL(id);
-
-	spin_lock_irqsave(&lock, flags);
-
-	cfg = __raw_readl(addr);
-	cfg = on ? (cfg | reset) : (cfg & ~reset);
-	__raw_writel(cfg, addr);
-
-	if (on) {
-		cfg |= S5P_MIPI_DPHY_ENABLE;
-	} else if (!(cfg & (S5P_MIPI_DPHY_SRESETN |
-			    S5P_MIPI_DPHY_MRESETN) & ~reset)) {
-		cfg &= ~S5P_MIPI_DPHY_ENABLE;
-	}
-
-	__raw_writel(cfg, addr);
-	spin_unlock_irqrestore(&lock, flags);
-
-	return 0;
-}
-
-int s5p_csis_phy_enable(int id, bool on)
-{
-	return __s5p_mipi_phy_control(id, on, S5P_MIPI_DPHY_SRESETN);
-}
-EXPORT_SYMBOL(s5p_csis_phy_enable);
-
-int s5p_dsim_phy_enable(struct platform_device *pdev, bool on)
-{
-	return __s5p_mipi_phy_control(pdev->id, on, S5P_MIPI_DPHY_MRESETN);
-}
-EXPORT_SYMBOL(s5p_dsim_phy_enable);
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:22 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:22 +0530
Subject: [PATCH 13/15] phy: Add driver for Exynos DP PHY
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-14-git-send-email-kishon@ti.com>

From: Jingoo Han <jg1.han at samsung.com>

Add a PHY provider driver for the Samsung Exynos SoC Display Port PHY.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 .../devicetree/bindings/phy/samsung-phy.txt        |    8 ++
 drivers/phy/Kconfig                                |    6 ++
 drivers/phy/Makefile                               |    1 +
 drivers/phy/phy-exynos-dp-video.c                  |  111 ++++++++++++++++++++
 4 files changed, 126 insertions(+)
 create mode 100644 drivers/phy/phy-exynos-dp-video.c

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 5ff208c..c0fccaa 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -12,3 +12,11 @@ the PHY specifier identifies the PHY and its meaning is as follows:
   1 - MIPI DSIM 0,
   2 - MIPI CSIS 1,
   3 - MIPI DSIM 1.
+
+Samsung EXYNOS SoC series Display Port PHY
+-------------------------------------------------
+
+Required properties:
+- compatible : should be "samsung,exynos5250-dp-video-phy";
+- reg : offset and length of the Display Port PHY register set;
+- #phy-cells : from the generic PHY bindings, must be 0;
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 6f446d0..ed0b1b8 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -19,4 +19,10 @@ config PHY_EXYNOS_MIPI_VIDEO
 	help
 	  Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
 	  S5P and EXYNOS SoCs.
+
+config PHY_EXYNOS_DP_VIDEO
+	tristate "EXYNOS SoC series Display Port PHY driver"
+	depends on OF
+	help
+	  Support for Display Port PHY found on Samsung EXYNOS SoCs.
 endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 71d8841..0fd1340 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_GENERIC_PHY)		+= phy-core.o
 obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)	+= phy-exynos-mipi-video.o
+obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)	+= phy-exynos-dp-video.o
diff --git a/drivers/phy/phy-exynos-dp-video.c b/drivers/phy/phy-exynos-dp-video.c
new file mode 100644
index 0000000..3c8e247
--- /dev/null
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -0,0 +1,111 @@
+/*
+ * Samsung EXYNOS SoC series Display Port PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Jingoo Han <jg1.han at samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+
+/* DPTX_PHY_CONTROL register */
+#define EXYNOS_DPTX_PHY_ENABLE		(1 << 0)
+
+struct exynos_dp_video_phy {
+	void __iomem *regs;
+};
+
+static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int on)
+{
+	u32 reg;
+
+	reg = readl(state->regs);
+	if (on)
+		reg |= EXYNOS_DPTX_PHY_ENABLE;
+	else
+		reg &= ~EXYNOS_DPTX_PHY_ENABLE;
+	writel(reg, state->regs);
+
+	return 0;
+}
+
+static int exynos_dp_video_phy_power_on(struct phy *phy)
+{
+	struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+	return __set_phy_state(state, 1);
+}
+
+static int exynos_dp_video_phy_power_off(struct phy *phy)
+{
+	struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+	return __set_phy_state(state, 0);
+}
+
+static struct phy_ops exynos_dp_video_phy_ops = {
+	.power_on	= exynos_dp_video_phy_power_on,
+	.power_off	= exynos_dp_video_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
+static int exynos_dp_video_phy_probe(struct platform_device *pdev)
+{
+	struct exynos_dp_video_phy *state;
+	struct device *dev = &pdev->dev;
+	struct resource *res;
+	struct phy_provider *phy_provider;
+	struct phy *phy;
+
+	state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
+	if (!state)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+	state->regs = devm_ioremap_resource(dev, res);
+	if (IS_ERR(state->regs))
+		return PTR_ERR(state->regs);
+
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	phy = devm_phy_create(dev, 0, &exynos_dp_video_phy_ops, NULL);
+	if (IS_ERR(phy)) {
+		dev_err(dev, "failed to create Display Port PHY\n");
+		return PTR_ERR(phy);
+	}
+	phy_set_drvdata(phy, state);
+
+	return 0;
+}
+
+static const struct of_device_id exynos_dp_video_phy_of_match[] = {
+	{ .compatible = "samsung,exynos5250-dp-video-phy" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, exynos_dp_video_phy_of_match);
+
+static struct platform_driver exynos_dp_video_phy_driver = {
+	.probe	= exynos_dp_video_phy_probe,
+	.driver = {
+		.name	= "exynos-dp-video-phy",
+		.owner	= THIS_MODULE,
+		.of_match_table	= exynos_dp_video_phy_of_match,
+	}
+};
+module_platform_driver(exynos_dp_video_phy_driver);
+
+MODULE_AUTHOR("Jingoo Han <jg1.han at samsung.com>");
+MODULE_DESCRIPTION("Samsung EXYNOS SoC DP PHY driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:23 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:23 +0530
Subject: [PATCH 14/15] video: exynos_dp: remove non-DT support for Exynos
 Display Port
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-15-git-send-email-kishon@ti.com>

From: Jingoo Han <jg1.han at samsung.com>

Exynos Display Port can be used only for Exynos SoCs. In addition,
non-DT for EXYNOS SoCs is not supported from v3.11; thus, there is
no need to support non-DT for Exynos Display Port.

The 'include/video/exynos_dp.h' file has been used for non-DT
support and the content of file include/video/exynos_dp.h is moved
to drivers/video/exynos/exynos_dp_core.h. Thus, the 'exynos_dp.h'
file is removed. Also, 'struct exynos_dp_platdata' is removed,
because it is not used any more.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/video/exynos/Kconfig          |    2 +-
 drivers/video/exynos/exynos_dp_core.c |  116 +++++++----------------------
 drivers/video/exynos/exynos_dp_core.h |  109 +++++++++++++++++++++++++++
 drivers/video/exynos/exynos_dp_reg.c  |    2 -
 include/video/exynos_dp.h             |  131 ---------------------------------
 5 files changed, 135 insertions(+), 225 deletions(-)
 delete mode 100644 include/video/exynos_dp.h

diff --git a/drivers/video/exynos/Kconfig b/drivers/video/exynos/Kconfig
index 1b035b2..fab9019 100644
--- a/drivers/video/exynos/Kconfig
+++ b/drivers/video/exynos/Kconfig
@@ -29,7 +29,7 @@ config EXYNOS_LCD_S6E8AX0
 
 config EXYNOS_DP
 	bool "EXYNOS DP driver support"
-	depends on ARCH_EXYNOS
+	depends on OF && ARCH_EXYNOS
 	default n
 	help
 	  This enables support for DP device.
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index 12bbede..05fed7d 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -20,8 +20,6 @@
 #include <linux/delay.h>
 #include <linux/of.h>
 
-#include <video/exynos_dp.h>
-
 #include "exynos_dp_core.h"
 
 static int exynos_dp_init_dp(struct exynos_dp_device *dp)
@@ -894,26 +892,17 @@ static void exynos_dp_hotplug(struct work_struct *work)
 		dev_err(dp->dev, "unable to config video\n");
 }
 
-#ifdef CONFIG_OF
-static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
+static struct video_info *exynos_dp_dt_parse_pdata(struct device *dev)
 {
 	struct device_node *dp_node = dev->of_node;
-	struct exynos_dp_platdata *pd;
 	struct video_info *dp_video_config;
 
-	pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
-	if (!pd) {
-		dev_err(dev, "memory allocation for pdata failed\n");
-		return ERR_PTR(-ENOMEM);
-	}
 	dp_video_config = devm_kzalloc(dev,
 				sizeof(*dp_video_config), GFP_KERNEL);
-
 	if (!dp_video_config) {
 		dev_err(dev, "memory allocation for video config failed\n");
 		return ERR_PTR(-ENOMEM);
 	}
-	pd->video_info = dp_video_config;
 
 	dp_video_config->h_sync_polarity =
 		of_property_read_bool(dp_node, "hsync-active-high");
@@ -960,7 +949,7 @@ static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
 		return ERR_PTR(-EINVAL);
 	}
 
-	return pd;
+	return dp_video_config;
 }
 
 static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
@@ -1003,48 +992,30 @@ err:
 
 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 {
-	u32 reg;
+	if (dp->phy_addr) {
+		u32 reg;
 
-	reg = __raw_readl(dp->phy_addr);
-	reg |= dp->enable_mask;
-	__raw_writel(reg, dp->phy_addr);
+		reg = __raw_readl(dp->phy_addr);
+		reg |= dp->enable_mask;
+		__raw_writel(reg, dp->phy_addr);
+	}
 }
 
 static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
 {
-	u32 reg;
-
-	reg = __raw_readl(dp->phy_addr);
-	reg &= ~(dp->enable_mask);
-	__raw_writel(reg, dp->phy_addr);
-}
-#else
-static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
-{
-	return NULL;
-}
-
-static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
-{
-	return -EINVAL;
-}
-
-static void exynos_dp_phy_init(struct exynos_dp_device *dp)
-{
-	return;
-}
+	if (dp->phy_addr) {
+		u32 reg;
 
-static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
-{
-	return;
+		reg = __raw_readl(dp->phy_addr);
+		reg &= ~(dp->enable_mask);
+		__raw_writel(reg, dp->phy_addr);
+	}
 }
-#endif /* CONFIG_OF */
 
 static int exynos_dp_probe(struct platform_device *pdev)
 {
 	struct resource *res;
 	struct exynos_dp_device *dp;
-	struct exynos_dp_platdata *pdata;
 
 	int ret = 0;
 
@@ -1057,21 +1028,13 @@ static int exynos_dp_probe(struct platform_device *pdev)
 
 	dp->dev = &pdev->dev;
 
-	if (pdev->dev.of_node) {
-		pdata = exynos_dp_dt_parse_pdata(&pdev->dev);
-		if (IS_ERR(pdata))
-			return PTR_ERR(pdata);
+	dp->video_info = exynos_dp_dt_parse_pdata(&pdev->dev);
+	if (IS_ERR(dp->video_info))
+		return PTR_ERR(dp->video_info);
 
-		ret = exynos_dp_dt_parse_phydata(dp);
-		if (ret)
-			return ret;
-	} else {
-		pdata = pdev->dev.platform_data;
-		if (!pdata) {
-			dev_err(&pdev->dev, "no platform data\n");
-			return -EINVAL;
-		}
-	}
+	ret = exynos_dp_dt_parse_phydata(dp);
+	if (ret)
+		return ret;
 
 	dp->clock = devm_clk_get(&pdev->dev, "dp");
 	if (IS_ERR(dp->clock)) {
@@ -1095,15 +1058,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
 
 	INIT_WORK(&dp->hotplug_work, exynos_dp_hotplug);
 
-	dp->video_info = pdata->video_info;
-
-	if (pdev->dev.of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_init(dp);
-	} else {
-		if (pdata->phy_init)
-			pdata->phy_init();
-	}
+	exynos_dp_phy_init(dp);
 
 	exynos_dp_init_dp(dp);
 
@@ -1121,18 +1076,11 @@ static int exynos_dp_probe(struct platform_device *pdev)
 
 static int exynos_dp_remove(struct platform_device *pdev)
 {
-	struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
 	struct exynos_dp_device *dp = platform_get_drvdata(pdev);
 
 	flush_work(&dp->hotplug_work);
 
-	if (pdev->dev.of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_exit(dp);
-	} else {
-		if (pdata->phy_exit)
-			pdata->phy_exit();
-	}
+	exynos_dp_phy_exit(dp);
 
 	clk_disable_unprepare(dp->clock);
 
@@ -1143,20 +1091,13 @@ static int exynos_dp_remove(struct platform_device *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int exynos_dp_suspend(struct device *dev)
 {
-	struct exynos_dp_platdata *pdata = dev->platform_data;
 	struct exynos_dp_device *dp = dev_get_drvdata(dev);
 
 	disable_irq(dp->irq);
 
 	flush_work(&dp->hotplug_work);
 
-	if (dev->of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_exit(dp);
-	} else {
-		if (pdata->phy_exit)
-			pdata->phy_exit();
-	}
+	exynos_dp_phy_exit(dp);
 
 	clk_disable_unprepare(dp->clock);
 
@@ -1165,16 +1106,9 @@ static int exynos_dp_suspend(struct device *dev)
 
 static int exynos_dp_resume(struct device *dev)
 {
-	struct exynos_dp_platdata *pdata = dev->platform_data;
 	struct exynos_dp_device *dp = dev_get_drvdata(dev);
 
-	if (dev->of_node) {
-		if (dp->phy_addr)
-			exynos_dp_phy_init(dp);
-	} else {
-		if (pdata->phy_init)
-			pdata->phy_init();
-	}
+	exynos_dp_phy_init(dp);
 
 	clk_prepare_enable(dp->clock);
 
@@ -1203,7 +1137,7 @@ static struct platform_driver exynos_dp_driver = {
 		.name	= "exynos-dp",
 		.owner	= THIS_MODULE,
 		.pm	= &exynos_dp_pm_ops,
-		.of_match_table = of_match_ptr(exynos_dp_match),
+		.of_match_table = exynos_dp_match,
 	},
 };
 
diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
index 6c567bbf..56cfec8 100644
--- a/drivers/video/exynos/exynos_dp_core.h
+++ b/drivers/video/exynos/exynos_dp_core.h
@@ -13,6 +13,99 @@
 #ifndef _EXYNOS_DP_CORE_H
 #define _EXYNOS_DP_CORE_H
 
+#define DP_TIMEOUT_LOOP_COUNT 100
+#define MAX_CR_LOOP 5
+#define MAX_EQ_LOOP 5
+
+enum link_rate_type {
+	LINK_RATE_1_62GBPS = 0x06,
+	LINK_RATE_2_70GBPS = 0x0a
+};
+
+enum link_lane_count_type {
+	LANE_COUNT1 = 1,
+	LANE_COUNT2 = 2,
+	LANE_COUNT4 = 4
+};
+
+enum link_training_state {
+	START,
+	CLOCK_RECOVERY,
+	EQUALIZER_TRAINING,
+	FINISHED,
+	FAILED
+};
+
+enum voltage_swing_level {
+	VOLTAGE_LEVEL_0,
+	VOLTAGE_LEVEL_1,
+	VOLTAGE_LEVEL_2,
+	VOLTAGE_LEVEL_3,
+};
+
+enum pre_emphasis_level {
+	PRE_EMPHASIS_LEVEL_0,
+	PRE_EMPHASIS_LEVEL_1,
+	PRE_EMPHASIS_LEVEL_2,
+	PRE_EMPHASIS_LEVEL_3,
+};
+
+enum pattern_set {
+	PRBS7,
+	D10_2,
+	TRAINING_PTN1,
+	TRAINING_PTN2,
+	DP_NONE
+};
+
+enum color_space {
+	COLOR_RGB,
+	COLOR_YCBCR422,
+	COLOR_YCBCR444
+};
+
+enum color_depth {
+	COLOR_6,
+	COLOR_8,
+	COLOR_10,
+	COLOR_12
+};
+
+enum color_coefficient {
+	COLOR_YCBCR601,
+	COLOR_YCBCR709
+};
+
+enum dynamic_range {
+	VESA,
+	CEA
+};
+
+enum pll_status {
+	PLL_UNLOCKED,
+	PLL_LOCKED
+};
+
+enum clock_recovery_m_value_type {
+	CALCULATED_M,
+	REGISTER_M
+};
+
+enum video_timing_recognition_type {
+	VIDEO_TIMING_FROM_CAPTURE,
+	VIDEO_TIMING_FROM_REGISTER
+};
+
+enum analog_power_block {
+	AUX_BLOCK,
+	CH0_BLOCK,
+	CH1_BLOCK,
+	CH2_BLOCK,
+	CH3_BLOCK,
+	ANALOG_TOTAL,
+	POWER_ALL
+};
+
 enum dp_irq_type {
 	DP_IRQ_TYPE_HP_CABLE_IN,
 	DP_IRQ_TYPE_HP_CABLE_OUT,
@@ -20,6 +113,22 @@ enum dp_irq_type {
 	DP_IRQ_TYPE_UNKNOWN,
 };
 
+struct video_info {
+	char *name;
+
+	bool h_sync_polarity;
+	bool v_sync_polarity;
+	bool interlaced;
+
+	enum color_space color_space;
+	enum dynamic_range dynamic_range;
+	enum color_coefficient ycbcr_coeff;
+	enum color_depth color_depth;
+
+	enum link_rate_type link_rate;
+	enum link_lane_count_type lane_count;
+};
+
 struct link_train {
 	int eq_loop;
 	int cr_loop[4];
diff --git a/drivers/video/exynos/exynos_dp_reg.c b/drivers/video/exynos/exynos_dp_reg.c
index 29d9d03..b70da50 100644
--- a/drivers/video/exynos/exynos_dp_reg.c
+++ b/drivers/video/exynos/exynos_dp_reg.c
@@ -14,8 +14,6 @@
 #include <linux/io.h>
 #include <linux/delay.h>
 
-#include <video/exynos_dp.h>
-
 #include "exynos_dp_core.h"
 #include "exynos_dp_reg.h"
 
diff --git a/include/video/exynos_dp.h b/include/video/exynos_dp.h
deleted file mode 100644
index bd8cabd..0000000
--- a/include/video/exynos_dp.h
+++ /dev/null
@@ -1,131 +0,0 @@
-/*
- * Samsung SoC DP device support
- *
- * Copyright (C) 2012 Samsung Electronics Co., Ltd.
- * Author: Jingoo Han <jg1.han at samsung.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef _EXYNOS_DP_H
-#define _EXYNOS_DP_H
-
-#define DP_TIMEOUT_LOOP_COUNT 100
-#define MAX_CR_LOOP 5
-#define MAX_EQ_LOOP 5
-
-enum link_rate_type {
-	LINK_RATE_1_62GBPS = 0x06,
-	LINK_RATE_2_70GBPS = 0x0a
-};
-
-enum link_lane_count_type {
-	LANE_COUNT1 = 1,
-	LANE_COUNT2 = 2,
-	LANE_COUNT4 = 4
-};
-
-enum link_training_state {
-	START,
-	CLOCK_RECOVERY,
-	EQUALIZER_TRAINING,
-	FINISHED,
-	FAILED
-};
-
-enum voltage_swing_level {
-	VOLTAGE_LEVEL_0,
-	VOLTAGE_LEVEL_1,
-	VOLTAGE_LEVEL_2,
-	VOLTAGE_LEVEL_3,
-};
-
-enum pre_emphasis_level {
-	PRE_EMPHASIS_LEVEL_0,
-	PRE_EMPHASIS_LEVEL_1,
-	PRE_EMPHASIS_LEVEL_2,
-	PRE_EMPHASIS_LEVEL_3,
-};
-
-enum pattern_set {
-	PRBS7,
-	D10_2,
-	TRAINING_PTN1,
-	TRAINING_PTN2,
-	DP_NONE
-};
-
-enum color_space {
-	COLOR_RGB,
-	COLOR_YCBCR422,
-	COLOR_YCBCR444
-};
-
-enum color_depth {
-	COLOR_6,
-	COLOR_8,
-	COLOR_10,
-	COLOR_12
-};
-
-enum color_coefficient {
-	COLOR_YCBCR601,
-	COLOR_YCBCR709
-};
-
-enum dynamic_range {
-	VESA,
-	CEA
-};
-
-enum pll_status {
-	PLL_UNLOCKED,
-	PLL_LOCKED
-};
-
-enum clock_recovery_m_value_type {
-	CALCULATED_M,
-	REGISTER_M
-};
-
-enum video_timing_recognition_type {
-	VIDEO_TIMING_FROM_CAPTURE,
-	VIDEO_TIMING_FROM_REGISTER
-};
-
-enum analog_power_block {
-	AUX_BLOCK,
-	CH0_BLOCK,
-	CH1_BLOCK,
-	CH2_BLOCK,
-	CH3_BLOCK,
-	ANALOG_TOTAL,
-	POWER_ALL
-};
-
-struct video_info {
-	char *name;
-
-	bool h_sync_polarity;
-	bool v_sync_polarity;
-	bool interlaced;
-
-	enum color_space color_space;
-	enum dynamic_range dynamic_range;
-	enum color_coefficient ycbcr_coeff;
-	enum color_depth color_depth;
-
-	enum link_rate_type link_rate;
-	enum link_lane_count_type lane_count;
-};
-
-struct exynos_dp_platdata {
-	struct video_info *video_info;
-
-	void (*phy_init)(void);
-	void (*phy_exit)(void);
-};
-
-#endif /* _EXYNOS_DP_H */
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 18 02:46:24 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 12:16:24 +0530
Subject: [PATCH 15/15] video: exynos_dp: Use the generic PHY driver
In-Reply-To: <1374129984-765-1-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
Message-ID: <1374129984-765-16-git-send-email-kishon@ti.com>

From: Jingoo Han <jg1.han at samsung.com>

Use the generic PHY API to control the DP PHY.

Signed-off-by: Jingoo Han <jg1.han at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 .../devicetree/bindings/video/exynos_dp.txt          |   18 +++++++++---------
 drivers/video/exynos/exynos_dp_core.c                |   16 ++++++++++++----
 drivers/video/exynos/exynos_dp_core.h                |    1 +
 3 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 84f10c1..2f56376 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -6,10 +6,10 @@ We use two nodes:
 	-dptx-phy node(defined inside dp-controller node)
 
 For the DP-PHY initialization, we use the dptx-phy node.
-Required properties for dptx-phy:
-	-reg:
+Required properties for dptx-phy: deprecated, use phys and phy-names
+	-reg: deprecated
 		Base address of DP PHY register.
-	-samsung,enable-mask:
+	-samsung,enable-mask: deprecated
 		The bit-mask used to enable/disable DP PHY.
 
 For the Panel initialization, we read data from dp-controller node.
@@ -25,6 +25,10 @@ Required properties for dp-controller:
 		from common clock binding: handle to dp clock.
 	-clock-names:
 		from common clock binding: Shall be "dp".
+	-phys:
+		from general PHY binding: the phandle for the PHY device.
+	-phy-names:
+		from general PHY binding: Should be "dp".
 	-interrupt-parent:
 		phandle to Interrupt combiner node.
 	-samsung,color-space:
@@ -67,12 +71,8 @@ SOC specific portion:
 		interrupt-parent = <&combiner>;
 		clocks = <&clock 342>;
 		clock-names = "dp";
-
-		dptx-phy {
-			reg = <0x10040720>;
-			samsung,enable-mask = <1>;
-		};
-
+		phys = <&dp_phy>;
+		phy-names = "dp";
 	};
 
 Board Specific portion:
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index 05fed7d..5e1a715 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -19,6 +19,7 @@
 #include <linux/interrupt.h>
 #include <linux/delay.h>
 #include <linux/of.h>
+#include <linux/phy/phy.h>
 
 #include "exynos_dp_core.h"
 
@@ -960,8 +961,11 @@ static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
 
 	dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
 	if (!dp_phy_node) {
-		dev_err(dp->dev, "could not find dptx-phy node\n");
-		return -ENODEV;
+		dp->phy = devm_phy_get(dp->dev, "dp");
+		if (IS_ERR(dp->phy))
+			return PTR_ERR(dp->phy);
+		else
+			return 0;
 	}
 
 	if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
@@ -992,7 +996,9 @@ err:
 
 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 {
-	if (dp->phy_addr) {
+	if (dp->phy) {
+		phy_power_on(dp->phy);
+	} else if (dp->phy_addr) {
 		u32 reg;
 
 		reg = __raw_readl(dp->phy_addr);
@@ -1003,7 +1009,9 @@ static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 
 static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
 {
-	if (dp->phy_addr) {
+	if (dp->phy) {
+		phy_power_off(dp->phy);
+	} else if (dp->phy_addr) {
 		u32 reg;
 
 		reg = __raw_readl(dp->phy_addr);
diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
index 56cfec8..607e36d 100644
--- a/drivers/video/exynos/exynos_dp_core.h
+++ b/drivers/video/exynos/exynos_dp_core.h
@@ -151,6 +151,7 @@ struct exynos_dp_device {
 	struct video_info	*video_info;
 	struct link_train	link_train;
 	struct work_struct	hotplug_work;
+	struct phy		*phy;
 };
 
 /* exynos_dp_reg.c */
-- 
1.7.10.4



From tony at atomide.com  Thu Jul 18 03:02:20 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 00:02:20 -0700
Subject: [PATCH 04/15] ARM: OMAP: USB: Add phy binding information
In-Reply-To: <1374129984-765-5-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-5-git-send-email-kishon@ti.com>
Message-ID: <20130718070219.GM7656@atomide.com>

* Kishon Vijay Abraham I <kishon at ti.com> [130717 23:53]:
> In order for controllers to get PHY in case of non dt boot, the phy
> binding information (phy device name) should be added in the platform
> data of the controller.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Acked-by: Felipe Balbi <balbi at ti.com>
> ---
>  arch/arm/mach-omap2/usb-musb.c |    3 +++
>  include/linux/usb/musb.h       |    3 +++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> index 8c4de27..6aa7cbf 100644
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -85,6 +85,9 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
>  	musb_plat.mode = board_data->mode;
>  	musb_plat.extvbus = board_data->extvbus;
>  
> +	if (cpu_is_omap34xx())
> +		musb_plat.phy_label = "twl4030";
> +
>  	if (soc_is_am35xx()) {
>  		oh_name = "am35x_otg_hs";
>  		name = "musb-am35x";

I don't think there's a USB PHY on non-twl4030 chips, so this should
be OK:

Acked-by: Tony Lindgren <tony at atomide.com>


> diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
> index 053c268..596f8c8 100644
> --- a/include/linux/usb/musb.h
> +++ b/include/linux/usb/musb.h
> @@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
>  	/* for clk_get() */
>  	const char	*clock;
>  
> +	/* phy label */
> +	const char	*phy_label;
> +
>  	/* (HOST or OTG) switch VBUS on/off */
>  	int		(*set_vbus)(struct device *dev, int is_on);
>  
> -- 
> 1.7.10.4
> 


From gsi at denx.de  Thu Jul 18 03:04:02 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 09:04:02 +0200
Subject: [PATCH v1 05/24] clk: wrap I/O access for improved portability
In-Reply-To: <20130715193829.GS14452@pengutronix.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1373914074-20889-6-git-send-email-gsi@denx.de>
 <20130715193829.GS14452@pengutronix.de>
Message-ID: <20130718070402.GO7080@book.gsilab.sittig.org>

On Mon, Jul 15, 2013 at 21:38 +0200, Sascha Hauer wrote:
> 
> On Mon, Jul 15, 2013 at 08:47:34PM +0200, Gerhard Sittig wrote:
> > diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> > index 6d55eb2..2c07061 100644
> > --- a/drivers/clk/clk-divider.c
> > +++ b/drivers/clk/clk-divider.c
> > @@ -104,7 +104,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
> >  	struct clk_divider *divider = to_clk_divider(hw);
> >  	unsigned int div, val;
> >  
> > -	val = readl(divider->reg) >> divider->shift;
> > +	val = clk_readl(divider->reg) >> divider->shift;
> >  	val &= div_mask(divider);
> 
> Would it be an option to use regmap for the generic dividers/muxes
> instead? This should be suitable for ppc and also for people who want to
> use the generic clocks on i2c devices.

Some other thought crossed my mind regarding access to clock
control registers that reside behind some communication channel
like I2C:

The common clock API assumes (it's part of the contract) that
there are potentially expensive operations like get, put, prepare
and unprepare, as well as swift and non-blocking operations like
enable and disable.

Would the regmap abstraction hide the potentially blocking nature
of a register access (I understand that you can implement "local"
as well as "remote" register sets by this mechanism)?  Or could
you still meet the assumptions or requirements of the common
clock API?

It might as well be the responsibility of the clock driver's
implementor to arrange for the availability of non-blocking
enable/disable operations, just as it is today.  Such that
expensive register access need not be forbidden in general.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


From tony at atomide.com  Thu Jul 18 03:05:09 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 00:05:09 -0700
Subject: [PATCH 05/15] ARM: dts: omap: update usb_otg_hs data
In-Reply-To: <1374129984-765-6-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-6-git-send-email-kishon@ti.com>
Message-ID: <20130718070508.GN7656@atomide.com>

* Kishon Vijay Abraham I <kishon at ti.com> [130717 23:53]:
> Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
> binding in order for the driver to use the new generic PHY framework.
> Also updated the Documentation to include the binding information.
> The PHY binding information can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> Acked-by: Felipe Balbi <balbi at ti.com>
> Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>

In general the .dts changes should be separate to avoid pointless
merge conflicts. But sounds like things will stop working for
USB unless we do it like this so:

Acked-by: Tony Lindgren <tony at atomide.com>


> ---
>  Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +++++
>  Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 ++++++
>  arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 ++
>  arch/arm/boot/dts/omap3-evm.dts                    |    2 ++
>  arch/arm/boot/dts/omap3-overo.dtsi                 |    2 ++
>  arch/arm/boot/dts/omap4.dtsi                       |    3 +++
>  arch/arm/boot/dts/twl4030.dtsi                     |    1 +
>  7 files changed, 21 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
> index 57e71f6..825790d 100644
> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
> @@ -19,6 +19,9 @@ OMAP MUSB GLUE
>   - power : Should be "50". This signifies the controller can supply up to
>     100mA when operating in host mode.
>   - usb-phy : the phandle for the PHY device
> + - phys : the phandle for the PHY device (used by generic PHY framework)
> + - phy-names : the names of the PHY corresponding to the PHYs present in the
> +   *phy* phandle.
>  
>  Optional properties:
>   - ctrl-module : phandle of the control module this glue uses to write to
> @@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs at 4a0ab000 {
>  	num-eps = <16>;
>  	ram-bits = <12>;
>  	ctrl-module = <&omap_control_usb>;
> +	phys = <&usb2_phy>;
> +	phy-names = "usb2-phy";
>  };
>  
>  Board specific device node entry
> diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
> index 61496f5..c0245c8 100644
> --- a/Documentation/devicetree/bindings/usb/usb-phy.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
> @@ -5,6 +5,8 @@ OMAP USB2 PHY
>  Required properties:
>   - compatible: Should be "ti,omap-usb2"
>   - reg : Address and length of the register set for the device.
> + - #phy-cells: determine the number of cells that should be given in the
> +   phandle while referencing this phy.
>  
>  Optional properties:
>   - ctrl-module : phandle of the control module used by PHY driver to power on
> @@ -16,6 +18,7 @@ usb2phy at 4a0ad080 {
>  	compatible = "ti,omap-usb2";
>  	reg = <0x4a0ad080 0x58>;
>  	ctrl-module = <&omap_control_usb>;
> +	#phy-cells = <0>;
>  };
>  
>  OMAP USB3 PHY
> @@ -25,6 +28,8 @@ Required properties:
>   - reg : Address and length of the register set for the device.
>   - reg-names: The names of the register addresses corresponding to the registers
>     filled in "reg".
> + - #phy-cells: determine the number of cells that should be given in the
> +   phandle while referencing this phy.
>  
>  Optional properties:
>   - ctrl-module : phandle of the control module used by PHY driver to power on
> @@ -39,4 +44,5 @@ usb3phy at 4a084400 {
>  	      <0x4a084c00 0x40>;
>  	reg-names = "phy_rx", "phy_tx", "pll_ctrl";
>  	ctrl-module = <&omap_control_usb>;
> +	#phy-cells = <0>;
>  };
> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
> index afdb164..533b2da 100644
> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> @@ -144,6 +144,8 @@
>  &usb_otg_hs {
>  	interface-type = <0>;
>  	usb-phy = <&usb2_phy>;
> +	phys = <&usb2_phy>;
> +	phy-names = "usb2-phy";
>  	mode = <3>;
>  	power = <50>;
>  };
> diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
> index 7d4329d..4134dd0 100644
> --- a/arch/arm/boot/dts/omap3-evm.dts
> +++ b/arch/arm/boot/dts/omap3-evm.dts
> @@ -70,6 +70,8 @@
>  &usb_otg_hs {
>  	interface-type = <0>;
>  	usb-phy = <&usb2_phy>;
> +	phys = <&usb2_phy>;
> +	phy-names = "usb2-phy";
>  	mode = <3>;
>  	power = <50>;
>  };
> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
> index 8f1abec..a461d2f 100644
> --- a/arch/arm/boot/dts/omap3-overo.dtsi
> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
> @@ -76,6 +76,8 @@
>  &usb_otg_hs {
>  	interface-type = <0>;
>  	usb-phy = <&usb2_phy>;
> +	phys = <&usb2_phy>;
> +	phy-names = "usb2-phy";
>  	mode = <3>;
>  	power = <50>;
>  };
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 22d9f2b..1e8e2fe 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -520,6 +520,7 @@
>  				compatible = "ti,omap-usb2";
>  				reg = <0x4a0ad080 0x58>;
>  				ctrl-module = <&omap_control_usb>;
> +				#phy-cells = <0>;
>  			};
>  		};
>  
> @@ -658,6 +659,8 @@
>  			interrupt-names = "mc", "dma";
>  			ti,hwmods = "usb_otg_hs";
>  			usb-phy = <&usb2_phy>;
> +			phys = <&usb2_phy>;
> +			phy-names = "usb2-phy";
>  			multipoint = <1>;
>  			num-eps = <16>;
>  			ram-bits = <12>;
> diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
> index b3034da..ce4cd6f 100644
> --- a/arch/arm/boot/dts/twl4030.dtsi
> +++ b/arch/arm/boot/dts/twl4030.dtsi
> @@ -80,6 +80,7 @@
>  		usb1v8-supply = <&vusb1v8>;
>  		usb3v1-supply = <&vusb3v1>;
>  		usb_mode = <1>;
> +		#phy-cells = <0>;
>  	};
>  
>  	twl_pwm: pwm {
> -- 
> 1.7.10.4
> 


From computersforpeace at gmail.com  Thu Jul 18 03:14:15 2013
From: computersforpeace at gmail.com (Brian Norris)
Date: Thu, 18 Jul 2013 00:14:15 -0700
Subject: [PATCH 6/6] mtd: ofpart: add compatible check for child nodes
In-Reply-To: <1372845034-5579-7-git-send-email-josh.wu@atmel.com>
References: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>
 <1372845034-5579-7-git-send-email-josh.wu@atmel.com>
Message-ID: <CAN8TOE_YfnQ5hK=xO28tH2h39Fb3KcVBFGM=XAFLHnRb0DFO3A@mail.gmail.com>

Adding device tree list, keeping patch context

On Wed, Jul 3, 2013 at 2:50 AM, Josh Wu <josh.wu at atmel.com> wrote:
> In case that the nand device will support some features like Nand Flash
> Controller, we want to make the sub feature as a sub node of nand device.
>
> Use such organization it is easy to enable/disable feature, also it is back
> compatible and more readable.
>
> If the sub-node has a compatible property then it is a driver not partition.
>
> Signed-off-by: Josh Wu <josh.wu at atmel.com>

I just came back to this patch series. I think this patch might be
deserving of a review by the device-tree mailing list. (It also
doesn't deserve to die in MTD purgatory.)

BTW, it looks good to me, so:

Acked-by: Brian Norris <computersforpeace at gmail.com>

Thanks,
Brian

> ---
> v3 --> v4:
>   - remove the 'len' parameter, just use NULL.
>   - refine the commit message.
>   - also add a NOTE in devicetree/bindings/mtd/partition.txt.
>
>  .../devicetree/bindings/mtd/partition.txt          |    1 +
>  drivers/mtd/ofpart.c                               |   13 ++++++++++++-
>  2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt
> index 9315ac9..8e5557d 100644
> --- a/Documentation/devicetree/bindings/mtd/partition.txt
> +++ b/Documentation/devicetree/bindings/mtd/partition.txt
> @@ -4,6 +4,7 @@ Partitions can be represented by sub-nodes of an mtd device. This can be used
>  on platforms which have strong conventions about which portions of a flash are
>  used for what purposes, but which don't use an on-flash partition table such
>  as RedBoot.
> +NOTE: if the sub-node has a compatible string, then it is not a partition.
>
>  #address-cells & #size-cells must both be present in the mtd device. There are
>  two valid values for both:
> diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
> index 553d6d6..30fcea1 100644
> --- a/drivers/mtd/ofpart.c
> +++ b/drivers/mtd/ofpart.c
> @@ -20,6 +20,10 @@
>  #include <linux/slab.h>
>  #include <linux/mtd/partitions.h>
>
> +static bool node_has_compatible(struct device_node *pp)
> +{
> +       return of_get_property(pp, "compatible", NULL);
> +}
>  static int parse_ofpart_partitions(struct mtd_info *master,
>                                    struct mtd_partition **pparts,
>                                    struct mtd_part_parser_data *data)
> @@ -40,8 +44,12 @@ static int parse_ofpart_partitions(struct mtd_info *master,
>         /* First count the subnodes */
>         pp = NULL;
>         nr_parts = 0;
> -       while ((pp = of_get_next_child(node, pp)))
> +       while ((pp = of_get_next_child(node, pp))) {
> +               if (node_has_compatible(pp))
> +                       continue;
> +
>                 nr_parts++;
> +       }
>
>         if (nr_parts == 0)
>                 return 0;
> @@ -57,6 +65,9 @@ static int parse_ofpart_partitions(struct mtd_info *master,
>                 int len;
>                 int a_cells, s_cells;
>
> +               if (node_has_compatible(pp))
> +                       continue;
> +
>                 reg = of_get_property(pp, "reg", &len);
>                 if (!reg) {
>                         nr_parts--;
> --
> 1.7.9.5
>


From gregkh at linuxfoundation.org  Thu Jul 18 03:20:04 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Thu, 18 Jul 2013 00:20:04 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <1374129984-765-2-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-2-git-send-email-kishon@ti.com>
Message-ID: <20130718072004.GA16720@kroah.com>

On Thu, Jul 18, 2013 at 12:16:10PM +0530, Kishon Vijay Abraham I wrote:
> +struct phy_provider *__of_phy_provider_register(struct device *dev,
> +	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
> +	struct of_phandle_args *args));
> +struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
> +	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
> +	struct of_phandle_args *args))
> +
> +__of_phy_provider_register and __devm_of_phy_provider_register can be used to
> +register the phy_provider and it takes device, owner and of_xlate as
> +arguments. For the dt boot case, all PHY providers should use one of the above
> +2 APIs to register the PHY provider.

Why do you have __ for the prefix of a public function?  Is that really
the way that OF handles this type of thing?

> --- /dev/null
> +++ b/drivers/phy/Kconfig
> @@ -0,0 +1,13 @@
> +#
> +# PHY
> +#
> +
> +menuconfig GENERIC_PHY
> +	tristate "PHY Subsystem"
> +	help
> +	  Generic PHY support.
> +
> +	  This framework is designed to provide a generic interface for PHY
> +	  devices present in the kernel. This layer will have the generic
> +	  API by which phy drivers can create PHY using the phy framework and
> +	  phy users can obtain reference to the PHY.

Again, please reverse this.  The drivers that use it should select it,
not depend on it, which will then enable this option.  I will never know
if I need to enable it, and based on your follow-on patches, if I don't,
drivers that were working just fine, now disappeared from my build,
which isn't nice, and a pain to notice and fix up.

> +/**
> + * phy_create() - create a new phy
> + * @dev: device that is creating the new phy
> + * @id: id of the phy
> + * @ops: function pointers for performing phy operations
> + * @label: label given to the phy
> + *
> + * Called to create a phy using phy framework.
> + */
> +struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
> +	const char *label)
> +{
> +	int ret;
> +	struct phy *phy;
> +
> +	if (!dev) {
> +		dev_WARN(dev, "no device provided for PHY\n");
> +		ret = -EINVAL;
> +		goto err0;
> +	}
> +
> +	phy = kzalloc(sizeof(*phy), GFP_KERNEL);
> +	if (!phy) {
> +		ret = -ENOMEM;
> +		goto err0;
> +	}
> +
> +	device_initialize(&phy->dev);
> +	mutex_init(&phy->mutex);
> +
> +	phy->dev.class = phy_class;
> +	phy->dev.parent = dev;
> +	phy->dev.of_node = dev->of_node;
> +	phy->id = id;
> +	phy->ops = ops;
> +	phy->label = kstrdup(label, GFP_KERNEL);
> +
> +	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);

Your naming is odd, no "phy" anywhere in it?  You rely on the sender to
never send a duplicate name.id pair?  Why not create your own ids based
on the number of phys in the system, like almost all other classes and
subsystems do?

> +static inline int phy_pm_runtime_get(struct phy *phy)
> +{
> +	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
> +		return -EINVAL;

Why would phy ever not be valid and a error pointer?  And why dump the
stack if that happens, that seems really extreme.

> +
> +	if (!pm_runtime_enabled(&phy->dev))
> +		return -ENOTSUPP;
> +
> +	return pm_runtime_get(&phy->dev);
> +}

This, and the other inline functions in this .h file seem huge, why are
they inline and not in the .c file?  There's no speed issues, and it
should save space overall in the .c file.  Please move them.


> +static inline int phy_init(struct phy *phy)
> +{
> +	int ret;
> +
> +	ret = phy_pm_runtime_get_sync(phy);
> +	if (ret < 0 && ret != -ENOTSUPP)
> +		return ret;
> +
> +	mutex_lock(&phy->mutex);
> +	if (phy->init_count++ == 0 && phy->ops->init) {
> +		ret = phy->ops->init(phy);
> +		if (ret < 0) {
> +			dev_err(&phy->dev, "phy init failed --> %d\n", ret);
> +			goto out;
> +		}
> +	}
> +
> +out:
> +	mutex_unlock(&phy->mutex);
> +	phy_pm_runtime_put(phy);
> +	return ret;
> +}
> +
> +static inline int phy_exit(struct phy *phy)
> +{
> +	int ret;
> +
> +	ret = phy_pm_runtime_get_sync(phy);
> +	if (ret < 0 && ret != -ENOTSUPP)
> +		return ret;
> +
> +	mutex_lock(&phy->mutex);
> +	if (--phy->init_count == 0 && phy->ops->exit) {
> +		ret = phy->ops->exit(phy);
> +		if (ret < 0) {
> +			dev_err(&phy->dev, "phy exit failed --> %d\n", ret);
> +			goto out;
> +		}
> +	}
> +
> +out:
> +	mutex_unlock(&phy->mutex);
> +	phy_pm_runtime_put(phy);
> +	return ret;
> +}
> +
> +static inline int phy_power_on(struct phy *phy)
> +{
> +	int ret = -ENOTSUPP;
> +
> +	ret = phy_pm_runtime_get_sync(phy);
> +	if (ret < 0 && ret != -ENOTSUPP)
> +		return ret;
> +
> +	mutex_lock(&phy->mutex);
> +	if (phy->power_count++ == 0 && phy->ops->power_on) {
> +		ret = phy->ops->power_on(phy);
> +		if (ret < 0) {
> +			dev_err(&phy->dev, "phy poweron failed --> %d\n", ret);
> +			goto out;
> +		}
> +	}
> +
> +out:
> +	mutex_unlock(&phy->mutex);
> +
> +	return ret;
> +}
> +
> +static inline int phy_power_off(struct phy *phy)
> +{
> +	int ret = -ENOTSUPP;
> +
> +	mutex_lock(&phy->mutex);
> +	if (--phy->power_count == 0 && phy->ops->power_off) {
> +		ret =  phy->ops->power_off(phy);
> +		if (ret < 0) {
> +			dev_err(&phy->dev, "phy poweroff failed --> %d\n", ret);
> +			goto out;
> +		}
> +	}
> +
> +out:
> +	mutex_unlock(&phy->mutex);
> +	phy_pm_runtime_put(phy);
> +
> +	return ret;
> +}

Look at those 3 functions, they are all "real" and not an inline
function at all, please move them.

thanks,

greg k-h


From s.trumtrar at pengutronix.de  Thu Jul 18 03:21:06 2013
From: s.trumtrar at pengutronix.de (Steffen Trumtrar)
Date: Thu, 18 Jul 2013 09:21:06 +0200
Subject: [PATCH 3/3] arm: zynq: slcr: Use read-modify-write for
 register writes
In-Reply-To: <1374081015-31431-4-git-send-email-soren.brinkmann@xilinx.com>
References: <1374081015-31431-1-git-send-email-soren.brinkmann@xilinx.com>
 <1374081015-31431-4-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <20130718072106.GB15514@pengutronix.de>

On Wed, Jul 17, 2013 at 10:10:15AM -0700, S?ren Brinkmann wrote:
> zynq_slcr_cpu_start/stop() ignored the current register state when
> writing to a register. Fixing this by implementing proper
> read-modify-write.
> 
> Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
> ---
>  arch/arm/mach-zynq/slcr.c | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/mach-zynq/slcr.c b/arch/arm/mach-zynq/slcr.c
> index 44a4ab6..1836d5a 100644
> --- a/arch/arm/mach-zynq/slcr.c
> +++ b/arch/arm/mach-zynq/slcr.c
> @@ -61,11 +61,11 @@ void zynq_slcr_system_reset(void)
>   */
>  void zynq_slcr_cpu_start(int cpu)
>  {
> -	/* enable CPUn */
> -	writel(SLCR_A9_CPU_CLKSTOP << cpu,
> -	       zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
> -	/* enable CLK for CPUn */
> -	writel(0x0 << cpu, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
> +	u32 reg = readl(zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
> +	reg &= ~(SLCR_A9_CPU_RST << cpu);
> +	writel(reg, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
> +	reg &= ~(SLCR_A9_CPU_CLKSTOP << cpu);
> +	writel(reg, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
>  }
>  
>  /**
> @@ -74,9 +74,9 @@ void zynq_slcr_cpu_start(int cpu)
>   */
>  void zynq_slcr_cpu_stop(int cpu)
>  {
> -	/* stop CLK and reset CPUn */
> -	writel((SLCR_A9_CPU_CLKSTOP | SLCR_A9_CPU_RST) << cpu,
> -	       zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
> +	u32 reg = readl(zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
> +	reg |= (SLCR_A9_CPU_CLKSTOP | SLCR_A9_CPU_RST) << cpu;
> +	writel(reg, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
>  }
>  

Hi!

Why do you also remove the comments? In my opinion they can stay.

Regards,
Steffen

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From gregkh at linuxfoundation.org  Thu Jul 18 03:21:49 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Thu, 18 Jul 2013 00:21:49 -0700
Subject: [PATCH 02/15] usb: phy: omap-usb2: use the new generic PHY
 framework
In-Reply-To: <1374129984-765-3-git-send-email-kishon@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-3-git-send-email-kishon@ti.com>
Message-ID: <20130718072149.GB16720@kroah.com>

On Thu, Jul 18, 2013 at 12:16:11PM +0530, Kishon Vijay Abraham I wrote:
> Used the generic PHY framework API to create the PHY. Now the power off and
> power on are done in omap_usb_power_off and omap_usb_power_on respectively.
> 
> However using the old USB PHY library cannot be completely removed
> because OTG is intertwined with PHY and moving to the new framework
> will break OTG. Once we have a separate OTG state machine, we
> can get rid of the USB PHY library.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Acked-by: Felipe Balbi <balbi at ti.com>
> ---
>  drivers/usb/phy/Kconfig         |    1 +
>  drivers/usb/phy/phy-omap-usb2.c |   45 +++++++++++++++++++++++++++++++++++----
>  2 files changed, 42 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index 3622fff..cc55993 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -75,6 +75,7 @@ config OMAP_CONTROL_USB
>  config OMAP_USB2
>  	tristate "OMAP USB2 PHY Driver"
>  	depends on ARCH_OMAP2PLUS
> +	depends on GENERIC_PHY
>  	select OMAP_CONTROL_USB
>  	help
>  	  Enable this to support the transceiver that is part of SOC. This
> diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
> index 844ab68..751b30f 100644
> --- a/drivers/usb/phy/phy-omap-usb2.c
> +++ b/drivers/usb/phy/phy-omap-usb2.c
> @@ -28,6 +28,7 @@
>  #include <linux/pm_runtime.h>
>  #include <linux/delay.h>
>  #include <linux/usb/omap_control_usb.h>
> +#include <linux/phy/phy.h>
>  
>  /**
>   * omap_usb2_set_comparator - links the comparator present in the sytem with
> @@ -119,10 +120,36 @@ static int omap_usb2_suspend(struct usb_phy *x, int suspend)
>  	return 0;
>  }
>  
> +static int omap_usb_power_off(struct phy *x)
> +{
> +	struct omap_usb *phy = phy_get_drvdata(x);
> +
> +	omap_control_usb_phy_power(phy->control_dev, 0);
> +
> +	return 0;
> +}
> +
> +static int omap_usb_power_on(struct phy *x)
> +{
> +	struct omap_usb *phy = phy_get_drvdata(x);
> +
> +	omap_control_usb_phy_power(phy->control_dev, 1);
> +
> +	return 0;
> +}
> +
> +static struct phy_ops ops = {
> +	.power_on	= omap_usb_power_on,
> +	.power_off	= omap_usb_power_off,
> +	.owner		= THIS_MODULE,
> +};
> +
>  static int omap_usb2_probe(struct platform_device *pdev)
>  {
>  	struct omap_usb			*phy;
> +	struct phy			*generic_phy;
>  	struct usb_otg			*otg;
> +	struct phy_provider		*phy_provider;
>  
>  	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
>  	if (!phy) {
> @@ -144,6 +171,11 @@ static int omap_usb2_probe(struct platform_device *pdev)
>  	phy->phy.otg		= otg;
>  	phy->phy.type		= USB_PHY_TYPE_USB2;
>  
> +	phy_provider = devm_of_phy_provider_register(phy->dev,
> +			of_phy_simple_xlate);
> +	if (IS_ERR(phy_provider))
> +		return PTR_ERR(phy_provider);
> +
>  	phy->control_dev = omap_get_control_dev();
>  	if (IS_ERR(phy->control_dev)) {
>  		dev_dbg(&pdev->dev, "Failed to get control device\n");
> @@ -159,6 +191,15 @@ static int omap_usb2_probe(struct platform_device *pdev)
>  	otg->start_srp		= omap_usb_start_srp;
>  	otg->phy		= &phy->phy;
>  
> +	platform_set_drvdata(pdev, phy);
> +	pm_runtime_enable(phy->dev);
> +
> +	generic_phy = devm_phy_create(phy->dev, 0, &ops, "omap-usb2");
> +	if (IS_ERR(generic_phy))
> +		return PTR_ERR(generic_phy);

So, if I have two of these controllers in my system, I can't create the
second phy because the name for it will be identical to the first?
That's why the phy core should handle the id, and not rely on the
drivers to set it, as they have no idea how many they have in the
system.

thanks,

greg k-h


From geert at linux-m68k.org  Thu Jul 18 03:22:58 2013
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Thu, 18 Jul 2013 09:22:58 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130717223033.GF3385@free.fr>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716004727.b60b2c96.akpm@linux-foundation.org>
 <20130716005611.e4ccab02.akpm@linux-foundation.org>
 <201307161008.07643.yann.morin.1998@free.fr>
 <20130716180408.GA19863@merkur.ravnborg.org>
 <20130717211649.GA5619@merkur.ravnborg.org>
 <20130717223033.GF3385@free.fr>
Message-ID: <CAMuHMdXzcRxEBqavTx-kEq6CNAx5fYug0w8kjDw=vNfS2iX4Fw@mail.gmail.com>

On Thu, Jul 18, 2013 at 12:30 AM, Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
> On 2013-07-17 23:16 +0200, Sam Ravnborg spake thusly:
>> > We could extend the symbol option part to retreive values from a binary.
>> > Something like this:
>> >
>> > config FOOBAR
>> >         bool
>> >         option exec="true"
>> >
>> > FOOBAR would assume the value "y" if the command true has exit code == 0, otherwise "n".
>> > And similar conversions for other types.
>> >
>> > This only extendt Kconfig slightly - using an already present method to import
>> > external values.
>> >
>> > The drawback I see with this approach is that we may execute a lot of small programs
>> > where the value is never used.
>>
>> Following is a quick patch implmenting this idea.
>> You need to run gperf manually to enable this.
>>
>> "gperf -C scripts/kconfig/zconf.gperf > scripts/kconfig/zconf.hash.c"
>>
>> I did not figure out how to use the built-in rules to generate this file :-(
>
> make REGENERATE_PARSERS=y menuconfig
>
>> I have tested this lightly - as we should discuss if this is a viable way forward.
>
> Instead of extending the Kconfig language, I was thinking (as initially
> suggested by Andrew) of generating a Kconfig file before all config
> targets, and source that Kconfig file from $(TOPDIR)/Kconfig.

I also prefer the generated Kconfig file.
It keeps all these checks in a single place, instead of spreading it over all
Kconfig files. This allows to keep better control over the list of checks, and
notice when it gets out-of-hand.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From tony at atomide.com  Thu Jul 18 03:25:16 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 00:25:16 -0700
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <51E70953.1000601@wwwdotorg.org>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
 <51E70953.1000601@wwwdotorg.org>
Message-ID: <20130718072034.GO7656@atomide.com>

* Stephen Warren <swarren at wwwdotorg.org> [130717 14:21]:
> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
> > To toggle dynamic states, let's add the optional active state in
> > addition to the static default state. Then if the optional active
> > state is defined, we can require that idle and sleep states cover
> > the same pingroups as the active state.
> > 
> > Then let's add pinctrl_check_dynamic() and pinctrl_select_dynamic()
> > to use instead of pinctrl_select() to avoid breaking existing users.
> > 
> > With pinctrl_check_dynamic() we can check that idle and sleep states
> > match the active state for pingroups during init, and don't need to
> > do it during runtime.
> > 
> > Then with the states pre-validated, pinctrl_select_dynamic() can
> > just toggle between the dynamic states without extra checks.
> > 
> > Note that pinctr_select_state() still has valid use cases, such as
> > changing states when the pins can be shared between two drivers
> > and don't necessarily cover the same pingroups. For dynamic runtime
> > toggling of pin states, we should eventually always use just
> > pinctrl_select_dynamic().
> 
> > diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> 
> > @@ -887,6 +887,8 @@ static void pinctrl_free(struct pinctrl *p, bool inlist)
> >  		list_for_each_entry_safe(setting, n2, &state->settings, node) {
> >  			pinctrl_free_setting(state == p->state[PINCTRL_STATIC],
> >  					     setting);
> > +			pinctrl_free_setting(state == p->state[PINCTRL_DYNAMIC],
> > +					     setting);
> 
> This will cause pinmux_free_setting() or pinconf_free_setting() to be
> called twice on the setting object. Right now they don't do anything,
> but if they start to kfree() some dynamically-allocated data that's
> stored within the setting, that'll cause problems. I would suggest a
> loop body something more like:
> 
> bool disable_setting = state == XXX || state == YYY;
> pinctrl_free_setting(disable_setting, setting);

OK good point, I'll check it.
 
> > +int pinctrl_check_dynamic(struct device *dev, struct pinctrl_state *st1,
> > +			  struct pinctrl_state *st2)
> > +{
> > +	struct pinctrl_setting *s1, *s2;
> > +
> > +	list_for_each_entry(s1, &st1->settings, node) {
> ...
> > +		list_for_each_entry(s2, &st2->settings, node) {
> ...
> > +			if (pctldev1 != pctldev2) {
> > +				dev_dbg(dev, "pctldev must be the same for states\n");
> > +				return -EINVAL;
> > +			}
> 
> I don't think we should require that; it's perfectly legal at the moment
> for some device's pinctrl configuration to include settings from
> multiple different pin controllers.

Yes that's fine for pinctrl_select(), but let's not do that for
runtime muxing.

Here we want to do a one-time check during init to make  sure that
if active_state is defined, then the idle_state and sleep_state
must match active_state for pins.

This way we can avoid checking things over and over again during
runtime like pinctrl_select() is currently doing.
 
> > +			for (i = 0; i < num_pins1; i++) {
> > +				int pin1 = pins1[i];
> > +
> > +				for (j = 0; j < num_pins2; j++) {
> > +					int pin2 = pins2[j];
> > +
> > +					if (pin1 == pin2) {
> > +						found++;
> > +						break;
> > +					}
> > +				}
> > +			}
> > +
> > +			if (found != num_pins1) {
> 
> I guess this make sure that every entry in the dynamic state is in the
> state state, but not vice-versa; the static state can affect more stuff
> than the dynamic state?
> 
> If so, shouldn't that check be if (found != num_pins2)?

The check is that idle_state and sleep_state pins must match the
active_state pins. This is intentionally different from the current
pinctrl_select() logic.
 
> > +int pinctrl_select_dynamic(struct pinctrl *p, struct pinctrl_state *state)
> 
> The body of this function is rather duplicated with pinctrl_select().

Well we may be able to make pinctrl_select() use this too, I'll take
a look. Initially I'd rather not start messing with pinctrl_select()
to avoid breaking existing users.
 
> > @@ -1241,7 +1371,13 @@ static int pinctrl_pm_select_state(struct device *dev, struct pinctrl_state *sta
> >  		return 0;
> >  	if (IS_ERR(state))
> >  		return 0; /* No such state */
> > -	ret = pinctrl_select_state(pins->p, state);
> > +
> > +	/* Configured for proper dynamic muxing? */
> 
> I don't think "proper" is correct here; it's just fine not to have any
> dynamic configuration.

Right, that's the most common case. I'll drop the "proper".
 
> > +	if (!IS_ERR(dev->pins->active_state))
> > +		ret = pinctrl_select_dynamic(pins->p, state);
> > +	else
> > +		ret = pinctrl_select_state(pins->p, state);
> 
> Hmmm. I'm not quite sure this is right... Surely this function should
> just do nothing if the dynamic states aren't defined? The system should
> just, and only, be in the "default" state and never do anything else.

This keeps the existing behaviour. We should be able to drop the
call to pinctrl_select_state() here after the existing use in
drivers has been fixed.
 
> Looking back at patch 1, I see the are
> pinctrl_pm_select_{default,sleep,idle}_state(). Shouldn't that list be
> active/sleep/idle, since I assume default is that "static" state, and
> the other three are the "dynamic" states?

Yes after this patch set that's the case, then we have default
plus optional active. Then if active is defined, sleep and idle
pins must match active. 
 
> > +static int pinctrl_pm_check_state(struct device *dev,
> > +				  struct pinctrl_state *state)
> 
> Naming this pinctrl_pm_is_state_error() or pinctrl_pm_is_state_ok()
> might give more clue what its return value is expected to be.

OK yeah I did not like that naming either, pinctrl_pm_is_state_error()
sounds good to me.

Regards,

Tony


From shawn.guo at linaro.org  Thu Jul 18 03:31:07 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 18 Jul 2013 15:31:07 +0800
Subject: [PATCH 1/4] ARM: imx6q: add spdif gate clock
In-Reply-To: <1374132670-791-1-git-send-email-shawn.guo@linaro.org>
References: <1374132670-791-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1374132670-791-2-git-send-email-shawn.guo@linaro.org>

It adds the missing spdif gate clock into imx6q clock driver.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 .../devicetree/bindings/clock/imx6q-clock.txt      |    1 +
 arch/arm/mach-imx/clk-imx6q.c                      |    4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index a0e104f..794d089 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -209,6 +209,7 @@ clocks and IDs.
 	pll5_post_div		194
 	pll5_video_div		195
 	eim_slow      		196
+	spdif      		197
 
 Examples:
 
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index db9f8f5..d739df1 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -239,7 +239,8 @@ enum mx6q_clks {
 	pll4_audio, pll5_video, pll8_mlb, pll7_usb_host, pll6_enet, ssi1_ipg,
 	ssi2_ipg, ssi3_ipg, rom, usbphy1, usbphy2, ldb_di0_div_3_5, ldb_di1_div_3_5,
 	sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref, usbphy1_gate,
-	usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow, clk_max
+	usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
+	spdif, clk_max
 };
 
 static struct clk *clk[clk_max];
@@ -521,6 +522,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[sata]         = imx_clk_gate2("sata",          "ipg",               base + 0x7c, 4);
 	clk[sdma]         = imx_clk_gate2("sdma",          "ahb",               base + 0x7c, 6);
 	clk[spba]         = imx_clk_gate2("spba",          "ipg",               base + 0x7c, 12);
+	clk[spdif]        = imx_clk_gate2("spdif",         "spdif_podf",    	base + 0x7c, 14);
 	clk[ssi1_ipg]     = imx_clk_gate2("ssi1_ipg",      "ipg",               base + 0x7c, 18);
 	clk[ssi2_ipg]     = imx_clk_gate2("ssi2_ipg",      "ipg",               base + 0x7c, 20);
 	clk[ssi3_ipg]     = imx_clk_gate2("ssi3_ipg",      "ipg",               base + 0x7c, 22);
-- 
1.7.9.5




From shawn.guo at linaro.org  Thu Jul 18 03:31:08 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 18 Jul 2013 15:31:08 +0800
Subject: [PATCH 2/4] ARM: imx6q: add cko2 clocks
In-Reply-To: <1374132670-791-1-git-send-email-shawn.guo@linaro.org>
References: <1374132670-791-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1374132670-791-3-git-send-email-shawn.guo@linaro.org>

It adds the missing cko2 clocks, including multiplexer, divider and
gate.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 .../devicetree/bindings/clock/imx6q-clock.txt      |    3 +++
 arch/arm/mach-imx/clk-imx6q.c                      |   15 ++++++++++++++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 794d089..c6d7e16 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -210,6 +210,9 @@ clocks and IDs.
 	pll5_video_div		195
 	eim_slow      		196
 	spdif      		197
+	cko2_sel      		198
+	cko2_podf      		199
+	cko2      		200
 
 Examples:
 
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index d739df1..924ed84 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -206,6 +206,16 @@ static const char *vpu_axi_sels[]	= { "axi", "pll2_pfd2_396m", "pll2_pfd0_352m",
 static const char *cko1_sels[]	= { "pll3_usb_otg", "pll2_bus", "pll1_sys", "pll5_video_div",
 				    "dummy", "axi", "enfc", "ipu1_di0", "ipu1_di1", "ipu2_di0",
 				    "ipu2_di1", "ahb", "ipg", "ipg_per", "ckil", "pll4_post_div", };
+static const char *cko2_sels[] = {
+	"mmdc_ch0_axi", "mmdc_ch1_axi", "usdhc4", "usdhc1",
+	"gpu2d_axi", "dummy", "ecspi_root", "gpu3d_axi",
+	"usdhc3", "dummy", "arm", "ipu1",
+	"ipu2", "vdo_axi", "osc", "gpu2d_core",
+	"gpu3d_core", "usdhc2", "ssi1", "ssi2",
+	"ssi3", "gpu3d_shader", "vpu_axi", "can_root",
+	"ldb_di0", "ldb_di1", "esai", "eim_slow",
+	"uart_serial", "spdif", "asrc", "hsi_tx",
+};
 
 enum mx6q_clks {
 	dummy, ckil, ckih, osc, pll2_pfd0_352m, pll2_pfd1_594m, pll2_pfd2_396m,
@@ -240,7 +250,7 @@ enum mx6q_clks {
 	ssi2_ipg, ssi3_ipg, rom, usbphy1, usbphy2, ldb_di0_div_3_5, ldb_di1_div_3_5,
 	sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref, usbphy1_gate,
 	usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
-	spdif, clk_max
+	spdif, cko2_sel, cko2_podf, cko2, clk_max
 };
 
 static struct clk *clk[clk_max];
@@ -398,6 +408,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[vdo_axi_sel]      = imx_clk_mux("vdo_axi_sel",      base + 0x18, 11, 1, vdo_axi_sels,      ARRAY_SIZE(vdo_axi_sels));
 	clk[vpu_axi_sel]      = imx_clk_mux("vpu_axi_sel",      base + 0x18, 14, 2, vpu_axi_sels,      ARRAY_SIZE(vpu_axi_sels));
 	clk[cko1_sel]         = imx_clk_mux("cko1_sel",         base + 0x60, 0,  4, cko1_sels,         ARRAY_SIZE(cko1_sels));
+	clk[cko2_sel]         = imx_clk_mux("cko2_sel",         base + 0x60, 16, 5, cko2_sels,         ARRAY_SIZE(cko2_sels));
 
 	/*                              name         reg      shift width busy: reg, shift parent_names  num_parents */
 	clk[periph]  = imx_clk_busy_mux("periph",  base + 0x14, 25,  1,   base + 0x48, 5,  periph_sels,  ARRAY_SIZE(periph_sels));
@@ -447,6 +458,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[emi_slow_podf]    = imx_clk_fixup_divider("emi_slow_podf", "emi_slow_sel",   base + 0x1c, 23, 3, imx_cscmr1_fixup);
 	clk[vpu_axi_podf]     = imx_clk_divider("vpu_axi_podf",     "vpu_axi_sel",       base + 0x24, 25, 3);
 	clk[cko1_podf]        = imx_clk_divider("cko1_podf",        "cko1_sel",          base + 0x60, 4,  3);
+	clk[cko2_podf]        = imx_clk_divider("cko2_podf",        "cko2_sel",          base + 0x60, 21, 3);
 
 	/*                                            name                 parent_name    reg        shift width busy: reg, shift */
 	clk[axi]               = imx_clk_busy_divider("axi",               "axi_sel",     base + 0x14, 16,  3,   base + 0x48, 0);
@@ -537,6 +549,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[vdo_axi]      = imx_clk_gate2("vdo_axi",       "vdo_axi_sel",       base + 0x80, 12);
 	clk[vpu_axi]      = imx_clk_gate2("vpu_axi",       "vpu_axi_podf",      base + 0x80, 14);
 	clk[cko1]         = imx_clk_gate("cko1",           "cko1_podf",         base + 0x60, 7);
+	clk[cko2]         = imx_clk_gate("cko2",           "cko2_podf",         base + 0x60, 24);
 
 	for (i = 0; i < ARRAY_SIZE(clk); i++)
 		if (IS_ERR(clk[i]))
-- 
1.7.9.5




From shawn.guo at linaro.org  Thu Jul 18 03:31:10 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 18 Jul 2013 15:31:10 +0800
Subject: [PATCH 4/4] ARM: imx6q: remove board specific CLKO setup
In-Reply-To: <1374132670-791-1-git-send-email-shawn.guo@linaro.org>
References: <1374132670-791-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1374132670-791-5-git-send-email-shawn.guo@linaro.org>

The CLKO is widely used by imx6q board designs to clock audio codec.
Since most codecs accept 24 MHz frequency, let's initially set up CLKO
with OSC24M (cko <-- cko2 <-- osc).  Then those board specific CLKO
setup for audio codec can be removed.

The board dts files also need an update on cko reference in codec node.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx6q-sabrelite.dts    |    2 +-
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi   |    2 +-
 arch/arm/boot/dts/imx6qdl-wandboard.dtsi |    2 +-
 arch/arm/mach-imx/clk-imx6q.c            |   11 +++++
 arch/arm/mach-imx/mach-imx6q.c           |   69 ------------------------------
 5 files changed, 14 insertions(+), 72 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts b/arch/arm/boot/dts/imx6q-sabrelite.dts
index e0f4cd0..3530280 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -167,7 +167,7 @@
 	codec: sgtl5000 at 0a {
 		compatible = "fsl,sgtl5000";
 		reg = <0x0a>;
-		clocks = <&clks 169>;
+		clocks = <&clks 201>;
 		VDDA-supply = <&reg_2p5v>;
 		VDDIO-supply = <&reg_3p3v>;
 	};
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 166b9ae..75b36b2 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -109,7 +109,7 @@
 	codec: wm8962 at 1a {
 		compatible = "wlf,wm8962";
 		reg = <0x1a>;
-		clocks = <&clks 169>;
+		clocks = <&clks 201>;
 		DCVDD-supply = <&reg_audio>;
 		DBVDD-supply = <&reg_audio>;
 		AVDD-supply = <&reg_audio>;
diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
index 7a46f64..77188cb 100644
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -60,7 +60,7 @@
 	codec: sgtl5000 at 0a {
 		compatible = "fsl,sgtl5000";
 		reg = <0x0a>;
-		clocks = <&clks 169>;
+		clocks = <&clks 201>;
 		VDDA-supply = <&reg_2p5v>;
 		VDDIO-supply = <&reg_3p3v>;
 	};
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index ed19b33..97f2702 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -288,6 +288,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	struct device_node *np;
 	void __iomem *base;
 	int i, irq;
+	int ret;
 
 	clk[dummy] = imx_clk_fixed("dummy", 0);
 	clk[ckil] = imx_obtain_fixed_clock("ckil", 0);
@@ -591,6 +592,16 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 		clk_prepare_enable(clk[usbphy2_gate]);
 	}
 
+	/*
+	 * Let's initially set up CLKO with OSC24M, since this configuration
+	 * is widely used by imx6q board designs to clock audio codec.
+	 */
+	ret = clk_set_parent(clk[cko2_sel], clk[osc]);
+	if (!ret)
+		ret = clk_set_parent(clk[cko], clk[cko2]);
+	if (ret)
+		pr_warn("failed to set up CLKO: %d\n", ret);
+
 	/* Set initial power mode */
 	imx6q_set_lpm(WAIT_CLOCKED);
 
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 9f06cc8..2460d49 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -159,30 +159,6 @@ static int ar8031_phy_fixup(struct phy_device *dev)
 	return 0;
 }
 
-static void __init imx6q_sabrelite_cko1_setup(void)
-{
-	struct clk *cko1_sel, *ahb, *cko1;
-	unsigned long rate;
-
-	cko1_sel = clk_get_sys(NULL, "cko1_sel");
-	ahb = clk_get_sys(NULL, "ahb");
-	cko1 = clk_get_sys(NULL, "cko1");
-	if (IS_ERR(cko1_sel) || IS_ERR(ahb) || IS_ERR(cko1)) {
-		pr_err("cko1 setup failed!\n");
-		goto put_clk;
-	}
-	clk_set_parent(cko1_sel, ahb);
-	rate = clk_round_rate(cko1, 16000000);
-	clk_set_rate(cko1, rate);
-put_clk:
-	if (!IS_ERR(cko1_sel))
-		clk_put(cko1_sel);
-	if (!IS_ERR(ahb))
-		clk_put(ahb);
-	if (!IS_ERR(cko1))
-		clk_put(cko1);
-}
-
 #define PHY_ID_AR8031	0x004dd074
 
 static void __init imx6q_enet_phy_init(void)
@@ -197,45 +173,6 @@ static void __init imx6q_enet_phy_init(void)
 	}
 }
 
-static void __init imx6q_sabresd_cko1_setup(void)
-{
-	struct clk *cko1_sel, *pll4, *pll4_post, *cko1;
-	unsigned long rate;
-
-	cko1_sel = clk_get_sys(NULL, "cko1_sel");
-	pll4 = clk_get_sys(NULL, "pll4_audio");
-	pll4_post = clk_get_sys(NULL, "pll4_post_div");
-	cko1 = clk_get_sys(NULL, "cko1");
-	if (IS_ERR(cko1_sel) || IS_ERR(pll4)
-			|| IS_ERR(pll4_post) || IS_ERR(cko1)) {
-		pr_err("cko1 setup failed!\n");
-		goto put_clk;
-	}
-	/*
-	 * Setting pll4 at 768MHz (24MHz * 32)
-	 * So its child clock can get 24MHz easily
-	 */
-	clk_set_rate(pll4, 768000000);
-
-	clk_set_parent(cko1_sel, pll4_post);
-	rate = clk_round_rate(cko1, 24000000);
-	clk_set_rate(cko1, rate);
-put_clk:
-	if (!IS_ERR(cko1_sel))
-		clk_put(cko1_sel);
-	if (!IS_ERR(pll4_post))
-		clk_put(pll4_post);
-	if (!IS_ERR(pll4))
-		clk_put(pll4);
-	if (!IS_ERR(cko1))
-		clk_put(cko1);
-}
-
-static void __init imx6q_sabresd_init(void)
-{
-	imx6q_sabresd_cko1_setup();
-}
-
 static void __init imx6q_1588_init(void)
 {
 	struct regmap *gpr;
@@ -256,12 +193,6 @@ static void __init imx6q_usb_init(void)
 
 static void __init imx6q_init_machine(void)
 {
-	if (of_machine_is_compatible("fsl,imx6q-sabrelite"))
-		imx6q_sabrelite_cko1_setup();
-	else if (of_machine_is_compatible("fsl,imx6q-sabresd") ||
-			of_machine_is_compatible("fsl,imx6dl-sabresd"))
-		imx6q_sabresd_init();
-
 	imx6q_enet_phy_init();
 
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-- 
1.7.9.5




From shawn.guo at linaro.org  Thu Jul 18 03:31:06 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 18 Jul 2013 15:31:06 +0800
Subject: [PATCH 0/4] ARM: imx6q: clean up board specific CLKO setup
Message-ID: <1374132670-791-1-git-send-email-shawn.guo@linaro.org>

The CLKO is widely used by imx6q board designs to clock audio codec.
Currently, imx6q-sabrelite and imx6qdl-sabresd set up CLKO in board
specific hooks, while imx6qdl-wandboard handles that in U-Boot.
Since most audio codecs accept 24 MHz frequency, the series adds missing
CLKO pieces into clock driver, and initially sets up CLKO with OSC24M
(cko <-- cko2 <-- osc).  Then those board specific CLKO setup for audio
codec can be removed, while it improves the power efficiency at the same
time by saving the use of PLL.

Shawn

Shawn Guo (4):
  ARM: imx6q: add spdif gate clock
  ARM: imx6q: add cko2 clocks
  ARM: imx6q: add the missing cko output selection
  ARM: imx6q: remove board specific CLKO setup

 .../devicetree/bindings/clock/imx6q-clock.txt      |    5 ++
 arch/arm/boot/dts/imx6q-sabrelite.dts              |    2 +-
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi             |    2 +-
 arch/arm/boot/dts/imx6qdl-wandboard.dtsi           |    2 +-
 arch/arm/mach-imx/clk-imx6q.c                      |   30 ++++++++-
 arch/arm/mach-imx/mach-imx6q.c                     |   69 --------------------
 6 files changed, 37 insertions(+), 73 deletions(-)

-- 
1.7.9.5




From shawn.guo at linaro.org  Thu Jul 18 03:31:09 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 18 Jul 2013 15:31:09 +0800
Subject: [PATCH 3/4] ARM: imx6q: add the missing cko output selection
In-Reply-To: <1374132670-791-1-git-send-email-shawn.guo@linaro.org>
References: <1374132670-791-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <1374132670-791-4-git-send-email-shawn.guo@linaro.org>

The clock output on imx6q CCM_CLKO1 pad is not always cko1 clock, and
there is a multiplexer to select between cko1 and cko2.  Add this
missing selection as the clock cko.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 .../devicetree/bindings/clock/imx6q-clock.txt      |    1 +
 arch/arm/mach-imx/clk-imx6q.c                      |    4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index c6d7e16..3066f181 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -213,6 +213,7 @@ clocks and IDs.
 	cko2_sel      		198
 	cko2_podf      		199
 	cko2      		200
+	cko      		201
 
 Examples:
 
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 924ed84..ed19b33 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -216,6 +216,7 @@ static const char *cko2_sels[] = {
 	"ldb_di0", "ldb_di1", "esai", "eim_slow",
 	"uart_serial", "spdif", "asrc", "hsi_tx",
 };
+static const char *cko_sels[] = { "cko1", "cko2", };
 
 enum mx6q_clks {
 	dummy, ckil, ckih, osc, pll2_pfd0_352m, pll2_pfd1_594m, pll2_pfd2_396m,
@@ -250,7 +251,7 @@ enum mx6q_clks {
 	ssi2_ipg, ssi3_ipg, rom, usbphy1, usbphy2, ldb_di0_div_3_5, ldb_di1_div_3_5,
 	sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref, usbphy1_gate,
 	usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
-	spdif, cko2_sel, cko2_podf, cko2, clk_max
+	spdif, cko2_sel, cko2_podf, cko2, cko, clk_max
 };
 
 static struct clk *clk[clk_max];
@@ -409,6 +410,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[vpu_axi_sel]      = imx_clk_mux("vpu_axi_sel",      base + 0x18, 14, 2, vpu_axi_sels,      ARRAY_SIZE(vpu_axi_sels));
 	clk[cko1_sel]         = imx_clk_mux("cko1_sel",         base + 0x60, 0,  4, cko1_sels,         ARRAY_SIZE(cko1_sels));
 	clk[cko2_sel]         = imx_clk_mux("cko2_sel",         base + 0x60, 16, 5, cko2_sels,         ARRAY_SIZE(cko2_sels));
+	clk[cko]              = imx_clk_mux("cko",              base + 0x60, 8, 1,  cko_sels,          ARRAY_SIZE(cko_sels));
 
 	/*                              name         reg      shift width busy: reg, shift parent_names  num_parents */
 	clk[periph]  = imx_clk_busy_mux("periph",  base + 0x14, 25,  1,   base + 0x48, 5,  periph_sels,  ARRAY_SIZE(periph_sels));
-- 
1.7.9.5




From voice.shen at atmel.com  Thu Jul 18 03:28:03 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Thu, 18 Jul 2013 15:28:03 +0800
Subject: [PATCH] ASoC: atmel: add wm8904 based audio machine driver
Message-ID: <1374132483-25375-1-git-send-email-voice.shen@atmel.com>

add wm8904 based audio machine driver

the following ek board based on it
  - at91sam9n12ek
  - sama5d3xek (d31, d33, d34, d35)

Signed-off-by: Bo Shen <voice.shen at atmel.com>
---
This patch is only for Atmel SoC with wm8904 codec machine driver only,
temp no change for dts file, as there are many changes to dts file in
mailing list for atmel SoC now, so hold on for dts change, after that
will send the dts file patches
---
 .../devicetree/bindings/sound/atmel-wm8904.txt     |   30 +++
 sound/soc/atmel/Kconfig                            |   10 +
 sound/soc/atmel/Makefile                           |    2 +
 sound/soc/atmel/atmel_wm8904.c                     |  263 ++++++++++++++++++++
 4 files changed, 305 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-wm8904.txt
 create mode 100644 sound/soc/atmel/atmel_wm8904.c

diff --git a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
new file mode 100644
index 0000000..5990271
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
@@ -0,0 +1,30 @@
+Atmel ASoC driver with wm8904 audio codec complex
+
+Required properties:
+  - compatible: "atmel,asoc-wm8904"
+  - atmel,model: The user-visible name of this sound complex.
+  - atmel,audio-routing: A list of the connections between audio components.
+  - atmel,ssc-controller: The phandle of the SSC controller
+  - atmel,audio-codec: The phandle of the WM8904 audio codec
+Optional properties:
+  - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
+
+Example:
+sound {
+	compatible = "atmel,asoc-wm8904";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pck0_as_mck>;
+
+	atmel,model = "wm8904 @ AT91SAM9N12EK";
+
+	atmel,audio-routing =
+		"Headphone Jack", "HPOUTL",
+		"Headphone Jack", "HPOUTR",
+		"IN2L", "Line In Jack",
+		"IN2R", "Line In Jack",
+		"Mic", "MICBIAS",
+		"IN1L", "Mic";
+
+	atmel,ssc-controller = <&ssc0>;
+	atmel,audio-codec = <&wm8904>;
+};
diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 1c0b185..986323b 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -33,6 +33,16 @@ config SND_AT91_SOC_SAM9G20_WM8731
 	  Say Y if you want to add support for SoC audio on WM8731-based
 	  AT91sam9g20 evaluation board.
 
+config SND_ATMEL_SOC_WM8904
+	tristate "Atmel ASoC driver for boards using WM8904 codec"
+	depends on ARCH_AT91 && ATMEL_SSC && SND_ATMEL_SOC
+	select SND_ATMEL_SOC_SSC
+	select SND_ATMEL_SOC_DMA
+	select SND_SOC_WM8904
+	help
+	  Say Y if you want to add support for Atmel ASoC driver for boards using
+	  WM8904 codec.
+
 config SND_AT91_SOC_AFEB9260
 	tristate "SoC Audio support for AFEB9260 board"
 	depends on ARCH_AT91 && ATMEL_SSC && ARCH_AT91 && MACH_AFEB9260 && SND_ATMEL_SOC
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index 41967cc..922d4da 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -11,6 +11,8 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
 
 # AT91 Machine Support
 snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
+snd-atmel-soc-wm8904-objs := atmel_wm8904.o
 
 obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
+obj-$(CONFIG_SND_ATMEL_SOC_WM8904) += snd-atmel-soc-wm8904.o
 obj-$(CONFIG_SND_AT91_SOC_AFEB9260) += snd-soc-afeb9260.o
diff --git a/sound/soc/atmel/atmel_wm8904.c b/sound/soc/atmel/atmel_wm8904.c
new file mode 100644
index 0000000..e309607
--- /dev/null
+++ b/sound/soc/atmel/atmel_wm8904.c
@@ -0,0 +1,263 @@
+/*
+ * atmel_wm8904 - Atmel ASoC driver for boards with WM8904 codec.
+ *
+ * Copyright (C) 2012 Atmel
+ *
+ * Author: Bo Shen <voice.shen at atmel.com>
+ *
+ * GPLv2 or later
+ */
+
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/consumer.h>
+
+#include <sound/soc.h>
+
+#include "../codecs/wm8904.h"
+#include "atmel_ssc_dai.h"
+
+#define MCLK_RATE 32768
+
+static struct clk *mclk;
+
+static const struct snd_soc_dapm_widget atmel_asoc_wm8904_dapm_widgets[] = {
+	SND_SOC_DAPM_HP("Headphone Jack", NULL),
+	SND_SOC_DAPM_MIC("Mic", NULL),
+	SND_SOC_DAPM_LINE("Line In Jack", NULL),
+};
+
+static int atmel_asoc_wm8904_init(struct snd_soc_pcm_runtime *rtd)
+{
+	struct snd_soc_dai *codec_dai = rtd->codec_dai;
+	int ret;
+
+	ret = snd_soc_dai_set_sysclk(codec_dai, WM8904_CLK_FLL,
+			12000000, SND_SOC_CLOCK_IN);
+	if (ret < 0) {
+		pr_err("%s -failed to set wm8904 SYSCLK\n", __func__);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int atmel_asoc_wm8904_params(struct snd_pcm_substream *substream,
+		struct snd_pcm_hw_params *params)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct snd_soc_dai *codec_dai = rtd->codec_dai;
+	int ret;
+
+	ret = snd_soc_dai_set_pll(codec_dai, WM8904_FLL_MCLK, WM8904_FLL_MCLK,
+		32768, params_rate(params) * 256);
+	if (ret < 0) {
+		pr_err("%s - failed to set wm8904 codec PLL.", __func__);
+		return ret;
+	}
+
+	return 0;
+}
+
+static struct snd_soc_ops atmel_asoc_wm8904_ops = {
+	.hw_params = atmel_asoc_wm8904_params,
+};
+
+static int atmel_set_bias_level(struct snd_soc_card *card,
+		struct snd_soc_dapm_context *dapm,
+		enum snd_soc_bias_level level)
+{
+	static int mclk_on;
+	int ret = 0;
+
+	switch (level) {
+	case SND_SOC_BIAS_ON:
+	case SND_SOC_BIAS_PREPARE:
+		if (!mclk_on) {
+			ret = clk_prepare_enable(mclk);
+			if (ret == 0)
+				mclk_on = 1;
+		}
+		break;
+	case SND_SOC_BIAS_STANDBY:
+	case SND_SOC_BIAS_OFF:
+		if (mclk_on)
+			clk_disable_unprepare(mclk);
+		mclk_on = 0;
+		break;
+	}
+
+	return ret;
+};
+
+static struct snd_soc_dai_link atmel_asoc_wm8904_dailink = {
+	.name = "WM8904",
+	.stream_name = "WM8904 PCM",
+	.codec_dai_name = "wm8904-hifi",
+	.dai_fmt = SND_SOC_DAIFMT_I2S
+		| SND_SOC_DAIFMT_NB_NF
+		| SND_SOC_DAIFMT_CBM_CFM,
+	.init = atmel_asoc_wm8904_init,
+	.ops = &atmel_asoc_wm8904_ops,
+};
+
+static struct snd_soc_card atmel_asoc_wm8904_card = {
+	.name = "atmel_asoc_wm8904",
+	.owner = THIS_MODULE,
+	.set_bias_level = atmel_set_bias_level,
+	.dai_link = &atmel_asoc_wm8904_dailink,
+	.num_links = 1,
+	.dapm_widgets = atmel_asoc_wm8904_dapm_widgets,
+	.num_dapm_widgets = ARRAY_SIZE(atmel_asoc_wm8904_dapm_widgets),
+	.fully_routed = true,
+};
+
+static int atmel_asoc_wm8904_dt_init(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *codec_np, *cpu_np;
+	struct snd_soc_card *card = &atmel_asoc_wm8904_card;
+	struct snd_soc_dai_link *dailink = &atmel_asoc_wm8904_dailink;
+	int ret;
+
+	if (!np)
+		return -1;
+
+	ret = snd_soc_of_parse_card_name(card, "atmel,model");
+	if (ret) {
+		dev_err(&pdev->dev, "failed to parse card name\n");
+		return ret;
+	}
+
+	ret = snd_soc_of_parse_audio_routing(card, "atmel,audio-routing");
+	if (ret) {
+		dev_err(&pdev->dev, "failed to parse audio routing\n");
+		return ret;
+	}
+
+	cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
+	if (!cpu_np) {
+		dev_err(&pdev->dev, "failed to get dai and pcm info\n");
+		ret = -EINVAL;
+		return ret;
+	}
+	dailink->cpu_of_node = cpu_np;
+	dailink->platform_of_node = cpu_np;
+	of_node_put(cpu_np);
+
+	codec_np = of_parse_phandle(np, "atmel,audio-codec", 0);
+	if (!codec_np) {
+		dev_err(&pdev->dev, "failed to get codec info\n");
+		ret = -EINVAL;
+		return ret;
+	}
+	dailink->codec_of_node = codec_np;
+	of_node_put(codec_np);
+
+	return 0;
+}
+
+static int atmel_asoc_wm8904_probe(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = &atmel_asoc_wm8904_card;
+	struct snd_soc_dai_link *dailink = &atmel_asoc_wm8904_dailink;
+	struct clk *clk_src;
+	struct pinctrl *pinctrl;
+	int id, ret;
+
+	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+	if (IS_ERR(pinctrl)) {
+		dev_err(&pdev->dev, "failed to request pinctrl\n");
+		return PTR_ERR(pinctrl);
+	}
+
+	card->dev = &pdev->dev;
+	ret = atmel_asoc_wm8904_dt_init(pdev);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to init dt info\n");
+		goto err_set_audio;
+	}
+
+	id = of_alias_get_id((struct device_node *)dailink->cpu_of_node, "ssc");
+	ret = atmel_ssc_set_audio(id);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "failed to set SSC 0 for audio\n");
+		return ret;
+	}
+
+	mclk = clk_get(NULL, "pck0");
+	if (IS_ERR(mclk)) {
+		dev_err(&pdev->dev, "failed to get pck0\n");
+		ret = PTR_ERR(mclk);
+		goto err_set_audio;
+	}
+
+	clk_src = clk_get(NULL, "clk32k");
+	if (IS_ERR(clk_src)) {
+		dev_err(&pdev->dev, "failed to get clk32k\n");
+		ret = PTR_ERR(clk_src);
+		goto err_set_audio;
+	}
+
+	ret = clk_set_parent(mclk, clk_src);
+	clk_put(clk_src);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "failed to set MCLK parent\n");
+		goto err_set_audio;
+	}
+
+	dev_info(&pdev->dev, "setting pck0 to %dHz\n", MCLK_RATE);
+	clk_set_rate(mclk, MCLK_RATE);
+
+	ret = snd_soc_register_card(card);
+	if (ret) {
+		dev_err(&pdev->dev, "snd_soc_register_card failed\n");
+		goto err_set_audio;
+	}
+
+	return 0;
+
+err_set_audio:
+	atmel_ssc_put_audio(0);
+	return ret;
+}
+
+static int atmel_asoc_wm8904_remove(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = platform_get_drvdata(pdev);
+	struct snd_soc_dai_link *dailink = &atmel_asoc_wm8904_dailink;
+	int id;
+
+	id = of_alias_get_id((struct device_node *)dailink->cpu_of_node, "ssc");
+
+	snd_soc_unregister_card(card);
+	atmel_ssc_put_audio(id);
+
+	return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id atmel_asoc_wm8904_dt_ids[] = {
+	{ .compatible = "atmel,asoc-wm8904", },
+	{ }
+};
+#endif
+
+static struct platform_driver atmel_asoc_wm8904_driver = {
+	.driver = {
+		.name = "atmel-wm8904-audio",
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(atmel_asoc_wm8904_dt_ids),
+	},
+	.probe = atmel_asoc_wm8904_probe,
+	.remove = atmel_asoc_wm8904_remove,
+};
+
+module_platform_driver(atmel_asoc_wm8904_driver);
+
+/* Module information */
+MODULE_AUTHOR("Bo Shen <voice.shen at atmel.com>");
+MODULE_DESCRIPTION("ALSA SoC machine driver for Atmel EK with WM8904 codec");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5



From b.brezillon at overkiz.com  Thu Jul 18 03:32:33 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Thu, 18 Jul 2013 09:32:33 +0200
Subject: [PATCH v4 0/5] ARM: at91: prepare transition to common clk framework
Message-ID: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>

Hello,

This patch series prepares the transition to common clk framework by
replacing all the clk_enable and clk_disable calls by clk_prepare_unable and
clk_disable_unprepare to avoid common clock framework warnings.

Best Regards,
Boris

Changes since v3:
 - move usb clock config patches out of this series
 - move clk_prepare/unprepare calls out of critical sections (ssc and
   mci drivers)
 - remove already applied spi clk_prepare patch 

Changes since v2:
 - add configuraton of usb clock in ohci and udc drivers
 - add clk_prepare patch for usba udc driver
 - add clk_prepare patch for spi driver
 - remove already applied udc clk_prepare patch

Changes since v1:
 - remove unneeded clk_unprepare in mci driver
 - remove already applied patches (ehci, ohci, dma and serial)

Changes since common clk patch series:
 - add clk_prepare_enable return check
 - fix a deadlock in atmel-mci (missing spin_unlock)
 - remove already applied patches (atmel-ssc and pwm-atmel-tcb)

Boris BREZILLON (5):
  ARM: at91/tc/clocksource: replace clk_enable/disable with
    clk_prepare_enable/disable_unprepare.
  mmc: atmel-mci: prepare clk before calling enable
  at91/avr32/atmel_lcdfb: prepare clk before calling enable
  USB: gadget: atmel_usba: prepare clk before calling enable
  ASoC: atmel-ssc: remove clk_disable_unprepare call from critical
    section

 drivers/clocksource/tcb_clksrc.c    |   10 +++++-----
 drivers/misc/atmel-ssc.c            |   11 ++++++++---
 drivers/mmc/host/atmel-mci.c        |   34 +++++++++++++++++++++++++++-------
 drivers/usb/gadget/atmel_usba_udc.c |   28 +++++++++++++++++++++-------
 drivers/video/atmel_lcdfb.c         |    8 ++++----
 5 files changed, 65 insertions(+), 26 deletions(-)

-- 
1.7.9.5



From akpm at linux-foundation.org  Thu Jul 18 03:34:08 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Thu, 18 Jul 2013 00:34:08 -0700
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <CAMuHMdXzcRxEBqavTx-kEq6CNAx5fYug0w8kjDw=vNfS2iX4Fw@mail.gmail.com>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716004727.b60b2c96.akpm@linux-foundation.org>
 <20130716005611.e4ccab02.akpm@linux-foundation.org>
 <201307161008.07643.yann.morin.1998@free.fr>
 <20130716180408.GA19863@merkur.ravnborg.org>
 <20130717211649.GA5619@merkur.ravnborg.org>
 <20130717223033.GF3385@free.fr>
 <CAMuHMdXzcRxEBqavTx-kEq6CNAx5fYug0w8kjDw=vNfS2iX4Fw@mail.gmail.com>
Message-ID: <20130718003408.bb9d5b51.akpm@linux-foundation.org>

On Thu, 18 Jul 2013 09:22:58 +0200 Geert Uytterhoeven <geert at linux-m68k.org> wrote:

> On Thu, Jul 18, 2013 at 12:30 AM, Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
> > On 2013-07-17 23:16 +0200, Sam Ravnborg spake thusly:
> >> > We could extend the symbol option part to retreive values from a binary.
> >> > Something like this:
> >> >
> >> > config FOOBAR
> >> >         bool
> >> >         option exec="true"
> >> >
> >> > FOOBAR would assume the value "y" if the command true has exit code == 0, otherwise "n".
> >> > And similar conversions for other types.
> >> >
> >> > This only extendt Kconfig slightly - using an already present method to import
> >> > external values.
> >> >
> >> > The drawback I see with this approach is that we may execute a lot of small programs
> >> > where the value is never used.
> >>
> >> Following is a quick patch implmenting this idea.
> >> You need to run gperf manually to enable this.
> >>
> >> "gperf -C scripts/kconfig/zconf.gperf > scripts/kconfig/zconf.hash.c"
> >>
> >> I did not figure out how to use the built-in rules to generate this file :-(
> >
> > make REGENERATE_PARSERS=y menuconfig
> >
> >> I have tested this lightly - as we should discuss if this is a viable way forward.
> >
> > Instead of extending the Kconfig language, I was thinking (as initially
> > suggested by Andrew) of generating a Kconfig file before all config
> > targets, and source that Kconfig file from $(TOPDIR)/Kconfig.
> 
> I also prefer the generated Kconfig file.
> It keeps all these checks in a single place, instead of spreading it over all
> Kconfig files. This allows to keep better control over the list of checks, and
> notice when it gets out-of-hand.

I prefer the "option exec" approach, actually.  That way the shell-outs
are colocated with the code which uses them and they will only be executed
if you've actually selected that subsystem for building (I think?).



From b.brezillon at overkiz.com  Thu Jul 18 03:34:42 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Thu, 18 Jul 2013 09:34:42 +0200
Subject: [PATCH v4 1/5] ARM: at91/tc/clocksource: replace clk_enable/disable
 with clk_prepare_enable/disable_unprepare.
In-Reply-To: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
References: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374132882-15276-1-git-send-email-b.brezillon@overkiz.com>

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/clocksource/tcb_clksrc.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index 8a61872..229c019 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -100,7 +100,7 @@ static void tc_mode(enum clock_event_mode m, struct clock_event_device *d)
 			|| tcd->clkevt.mode == CLOCK_EVT_MODE_ONESHOT) {
 		__raw_writel(0xff, regs + ATMEL_TC_REG(2, IDR));
 		__raw_writel(ATMEL_TC_CLKDIS, regs + ATMEL_TC_REG(2, CCR));
-		clk_disable(tcd->clk);
+		clk_disable_unprepare(tcd->clk);
 	}
 
 	switch (m) {
@@ -109,7 +109,7 @@ static void tc_mode(enum clock_event_mode m, struct clock_event_device *d)
 	 * of oneshot, we get lower overhead and improved accuracy.
 	 */
 	case CLOCK_EVT_MODE_PERIODIC:
-		clk_enable(tcd->clk);
+		clk_prepare_enable(tcd->clk);
 
 		/* slow clock, count up to RC, then irq and restart */
 		__raw_writel(timer_clock
@@ -126,7 +126,7 @@ static void tc_mode(enum clock_event_mode m, struct clock_event_device *d)
 		break;
 
 	case CLOCK_EVT_MODE_ONESHOT:
-		clk_enable(tcd->clk);
+		clk_prepare_enable(tcd->clk);
 
 		/* slow clock, count up to RC, then irq and stop */
 		__raw_writel(timer_clock | ATMEL_TC_CPCSTOP
@@ -275,7 +275,7 @@ static int __init tcb_clksrc_init(void)
 	pdev = tc->pdev;
 
 	t0_clk = tc->clk[0];
-	clk_enable(t0_clk);
+	clk_prepare_enable(t0_clk);
 
 	/* How fast will we be counting?  Pick something over 5 MHz.  */
 	rate = (u32) clk_get_rate(t0_clk);
@@ -313,7 +313,7 @@ static int __init tcb_clksrc_init(void)
 		/* tclib will give us three clocks no matter what the
 		 * underlying platform supports.
 		 */
-		clk_enable(tc->clk[1]);
+		clk_prepare_enable(tc->clk[1]);
 		/* setup both channel 0 & 1 */
 		tcb_setup_dual_chan(tc, best_divisor_idx);
 	}
-- 
1.7.9.5



From tony at atomide.com  Thu Jul 18 03:36:39 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 00:36:39 -0700
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <51E70B5D.6030802@wwwdotorg.org>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
 <51E70B5D.6030802@wwwdotorg.org>
Message-ID: <20130718073638.GP7656@atomide.com>

* Stephen Warren <swarren at wwwdotorg.org> [130717 14:30]:
> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
> > To toggle dynamic states, let's add the optional active state in
> > addition to the static default state. Then if the optional active
> > state is defined, we can require that idle and sleep states cover
> > the same pingroups as the active state.
> > 
> > Then let's add pinctrl_check_dynamic() and pinctrl_select_dynamic()
> > to use instead of pinctrl_select() to avoid breaking existing users.
> > 
> > With pinctrl_check_dynamic() we can check that idle and sleep states
> > match the active state for pingroups during init, and don't need to
> > do it during runtime.
> > 
> > Then with the states pre-validated, pinctrl_select_dynamic() can
> > just toggle between the dynamic states without extra checks.
> > 
> > Note that pinctr_select_state() still has valid use cases, such as
> > changing states when the pins can be shared between two drivers
> > and don't necessarily cover the same pingroups. For dynamic runtime
> > toggling of pin states, we should eventually always use just
> > pinctrl_select_dynamic().
> 
> Something in this series should edit Documentation/pinctrl.txt to
> explain the philosophy behind the static/dynamic state split. That
> philosophy and/or semantics are more important to review than the code...

Sure, I'll write up something on that.
 
> Related to that, I'm worried that using pinctrl_select_state() and
> pinctrl_select_dynamic() appear to be mutually-exclusive options here.

Not currently, but eventually I think that's a good idea. We should
use pinctrl_select_state() only during init time eventually because
of the diffing of states it does.

> Why shouldn't e.g. a pinctrl-based I2C mux also be able to do runtime
> PM? Does the mux setting select which states are used for runtime PM, or
> does runtime PM override the basic mux setting, or must the pincrl-I2C
> mux manually implement custom runtime-PM/pinctrl interaction since
> there's no generic answer to those questions? How many more custom
> exceptions will there be?

The idea is that runtime PM will never touch the basic mux settings
at all. The "default" state should be considered a static state
that is claimed during driver probe, and released when the driver
is unloaded. This is typically let's say 90% of the pins for any
device.

For runtime PM, we can just toggle the PM related pinctrl states as
they have been verified to match the active state during init.

So I don't see why pinctrl-I2C would have to do anything specific.
All that is required is that the pins are grouped for the consumer
driver, and we can provide some automated checks on the states for
runtime PM.

Regards,

Tony


From b.brezillon at overkiz.com  Thu Jul 18 03:38:52 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Thu, 18 Jul 2013 09:38:52 +0200
Subject: [PATCH v4 2/5] mmc: atmel-mci: prepare clk before calling enable
In-Reply-To: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
References: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374133132-17556-1-git-send-email-b.brezillon@overkiz.com>

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
Acked-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/mmc/host/atmel-mci.c |   34 +++++++++++++++++++++++++++-------
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index bdb84da..69e438e 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -378,6 +378,8 @@ static int atmci_regs_show(struct seq_file *s, void *v)
 {
 	struct atmel_mci	*host = s->private;
 	u32			*buf;
+	int			ret = 0;
+
 
 	buf = kmalloc(ATMCI_REGS_SIZE, GFP_KERNEL);
 	if (!buf)
@@ -388,12 +390,16 @@ static int atmci_regs_show(struct seq_file *s, void *v)
 	 * not disabling interrupts, so IMR and SR may not be
 	 * consistent.
 	 */
+	ret = clk_prepare_enable(host->mck);
+	if (ret)
+		goto out;
+
 	spin_lock_bh(&host->lock);
-	clk_enable(host->mck);
 	memcpy_fromio(buf, host->regs, ATMCI_REGS_SIZE);
-	clk_disable(host->mck);
 	spin_unlock_bh(&host->lock);
 
+	clk_disable_unprepare(host->mck);
+
 	seq_printf(s, "MR:\t0x%08x%s%s ",
 			buf[ATMCI_MR / 4],
 			buf[ATMCI_MR / 4] & ATMCI_MR_RDPROOF ? " RDPROOF" : "",
@@ -442,9 +448,10 @@ static int atmci_regs_show(struct seq_file *s, void *v)
 				val & ATMCI_CFG_LSYNC ? " LSYNC" : "");
 	}
 
+out:
 	kfree(buf);
 
-	return 0;
+	return ret;
 }
 
 static int atmci_regs_open(struct inode *inode, struct file *file)
@@ -1262,6 +1269,7 @@ static void atmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 	struct atmel_mci_slot	*slot = mmc_priv(mmc);
 	struct atmel_mci	*host = slot->host;
 	unsigned int		i;
+	bool			unprepare_clk;
 
 	slot->sdc_reg &= ~ATMCI_SDCBUS_MASK;
 	switch (ios->bus_width) {
@@ -1277,9 +1285,13 @@ static void atmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 		unsigned int clock_min = ~0U;
 		u32 clkdiv;
 
+		clk_prepare(host->mck);
+		unprepare_clk = true;
+
 		spin_lock_bh(&host->lock);
 		if (!host->mode_reg) {
 			clk_enable(host->mck);
+			unprepare_clk = false;
 			atmci_writel(host, ATMCI_CR, ATMCI_CR_SWRST);
 			atmci_writel(host, ATMCI_CR, ATMCI_CR_MCIEN);
 			if (host->caps.has_cfg_reg)
@@ -1347,6 +1359,8 @@ static void atmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 	} else {
 		bool any_slot_active = false;
 
+		unprepare_clk = false;
+
 		spin_lock_bh(&host->lock);
 		slot->clock = 0;
 		for (i = 0; i < ATMCI_MAX_NR_SLOTS; i++) {
@@ -1360,12 +1374,16 @@ static void atmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 			if (host->mode_reg) {
 				atmci_readl(host, ATMCI_MR);
 				clk_disable(host->mck);
+				unprepare_clk = true;
 			}
 			host->mode_reg = 0;
 		}
 		spin_unlock_bh(&host->lock);
 	}
 
+	if (unprepare_clk)
+		clk_unprepare(host->mck);
+
 	switch (ios->power_mode) {
 	case MMC_POWER_UP:
 		set_bit(ATMCI_CARD_NEED_INIT, &slot->flags);
@@ -2376,10 +2394,12 @@ static int __init atmci_probe(struct platform_device *pdev)
 	if (!host->regs)
 		goto err_ioremap;
 
-	clk_enable(host->mck);
+	ret = clk_prepare_enable(host->mck);
+	if (ret)
+		goto err_request_irq;
 	atmci_writel(host, ATMCI_CR, ATMCI_CR_SWRST);
 	host->bus_hz = clk_get_rate(host->mck);
-	clk_disable(host->mck);
+	clk_disable_unprepare(host->mck);
 
 	host->mapbase = regs->start;
 
@@ -2482,11 +2502,11 @@ static int __exit atmci_remove(struct platform_device *pdev)
 			atmci_cleanup_slot(host->slot[i], i);
 	}
 
-	clk_enable(host->mck);
+	clk_prepare_enable(host->mck);
 	atmci_writel(host, ATMCI_IDR, ~0UL);
 	atmci_writel(host, ATMCI_CR, ATMCI_CR_MCIDIS);
 	atmci_readl(host, ATMCI_SR);
-	clk_disable(host->mck);
+	clk_disable_unprepare(host->mck);
 
 	if (host->dma.chan)
 		dma_release_channel(host->dma.chan);
-- 
1.7.9.5



From b.brezillon at overkiz.com  Thu Jul 18 03:40:25 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Thu, 18 Jul 2013 09:40:25 +0200
Subject: [PATCH v4 3/5] at91/avr32/atmel_lcdfb: prepare clk before calling
 enable
In-Reply-To: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
References: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374133225-19141-1-git-send-email-b.brezillon@overkiz.com>

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 drivers/video/atmel_lcdfb.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index ece49d5..bf9c5d0 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -954,14 +954,14 @@ static int __init atmel_lcdfb_init_fbinfo(struct atmel_lcdfb_info *sinfo)
 
 static void atmel_lcdfb_start_clock(struct atmel_lcdfb_info *sinfo)
 {
-	clk_enable(sinfo->bus_clk);
-	clk_enable(sinfo->lcdc_clk);
+	clk_prepare_enable(sinfo->bus_clk);
+	clk_prepare_enable(sinfo->lcdc_clk);
 }
 
 static void atmel_lcdfb_stop_clock(struct atmel_lcdfb_info *sinfo)
 {
-	clk_disable(sinfo->bus_clk);
-	clk_disable(sinfo->lcdc_clk);
+	clk_disable_unprepare(sinfo->bus_clk);
+	clk_disable_unprepare(sinfo->lcdc_clk);
 }
 
 #ifdef CONFIG_OF
-- 
1.7.9.5



From b.brezillon at overkiz.com  Thu Jul 18 03:43:08 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Thu, 18 Jul 2013 09:43:08 +0200
Subject: [PATCH v4 4/5] USB: gadget: atmel_usba: prepare clk before calling
 enable
In-Reply-To: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
References: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374133388-22669-1-git-send-email-b.brezillon@overkiz.com>

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/usb/gadget/atmel_usba_udc.c |   28 +++++++++++++++++++++-------
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/gadget/atmel_usba_udc.c b/drivers/usb/gadget/atmel_usba_udc.c
index 1d97222..f018017 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -1772,6 +1772,7 @@ out:
 static int atmel_usba_start(struct usb_gadget *gadget,
 		struct usb_gadget_driver *driver)
 {
+	int ret = 0;
 	struct usba_udc *udc = container_of(gadget, struct usba_udc, gadget);
 	unsigned long flags;
 
@@ -1781,8 +1782,14 @@ static int atmel_usba_start(struct usb_gadget *gadget,
 	udc->driver = driver;
 	spin_unlock_irqrestore(&udc->lock, flags);
 
-	clk_enable(udc->pclk);
-	clk_enable(udc->hclk);
+	ret = clk_prepare_enable(udc->pclk);
+	if (ret)
+		goto out;
+	ret = clk_prepare_enable(udc->hclk);
+	if (ret) {
+		clk_disable_unprepare(udc->pclk);
+		goto out;
+	}
 
 	DBG(DBG_GADGET, "registered driver `%s'\n", driver->driver.name);
 
@@ -1797,9 +1804,11 @@ static int atmel_usba_start(struct usb_gadget *gadget,
 		usba_writel(udc, CTRL, USBA_ENABLE_MASK);
 		usba_writel(udc, INT_ENB, USBA_END_OF_RESET);
 	}
+
+out:
 	spin_unlock_irqrestore(&udc->lock, flags);
 
-	return 0;
+	return ret;
 }
 
 static int atmel_usba_stop(struct usb_gadget *gadget,
@@ -1822,8 +1831,8 @@ static int atmel_usba_stop(struct usb_gadget *gadget,
 
 	udc->driver = NULL;
 
-	clk_disable(udc->hclk);
-	clk_disable(udc->pclk);
+	clk_disable_unprepare(udc->hclk);
+	clk_disable_unprepare(udc->pclk);
 
 	DBG(DBG_GADGET, "unregistered driver `%s'\n", driver->driver.name);
 
@@ -2022,10 +2031,14 @@ static int __init usba_udc_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, udc);
 
 	/* Make sure we start from a clean slate */
-	clk_enable(pclk);
+	ret = clk_prepare_enable(pclk);
+	if (ret) {
+		dev_err(&pdev->dev, "Unable to enable pclk, aborting.\n");
+		goto err_clk_enable;
+	}
 	toggle_bias(0);
 	usba_writel(udc, CTRL, USBA_DISABLE_MASK);
-	clk_disable(pclk);
+	clk_disable_unprepare(pclk);
 
 	if (pdev->dev.of_node)
 		udc->usba_ep = atmel_udc_of_init(pdev, udc);
@@ -2081,6 +2094,7 @@ err_add_udc:
 	free_irq(irq, udc);
 err_request_irq:
 err_alloc_ep:
+err_clk_enable:
 	iounmap(udc->fifo);
 err_map_fifo:
 	iounmap(udc->regs);
-- 
1.7.9.5



From s.hauer at pengutronix.de  Thu Jul 18 03:46:11 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 18 Jul 2013 09:46:11 +0200
Subject: [PATCH 4/4] ARM: dts: i.MX53: split esdhc3 pins into base and 8bit
 groups
In-Reply-To: <1374133571-7660-1-git-send-email-s.hauer@pengutronix.de>
References: <1374133571-7660-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1374133571-7660-5-git-send-email-s.hauer@pengutronix.de>

This splits the esdhc3 groups into a base group and an 8bit extension
which results in smaller devicetrees and more obvious pinctrl group
names.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 arch/arm/boot/dts/imx53-evk.dts     |  2 +-
 arch/arm/boot/dts/imx53-qsb.dts     |  2 +-
 arch/arm/boot/dts/imx53-smd.dts     |  2 +-
 arch/arm/boot/dts/imx53-tqma53.dtsi |  2 +-
 arch/arm/boot/dts/imx53.dtsi        | 11 ++++++++---
 5 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/imx53-evk.dts b/arch/arm/boot/dts/imx53-evk.dts
index 2d093b5..ed5a41a 100644
--- a/arch/arm/boot/dts/imx53-evk.dts
+++ b/arch/arm/boot/dts/imx53-evk.dts
@@ -69,7 +69,7 @@
 
 &esdhc3 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_esdhc3_1>;
+	pinctrl-0 = <&pinctrl_esdhc3_base_1 &pinctrl_esdhc3_8bit_1>;
 	cd-gpios = <&gpio3 11 0>;
 	wp-gpios = <&gpio3 12 0>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
index 508390f..dbdd807 100644
--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@ -124,7 +124,7 @@
 
 &esdhc3 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_esdhc3_1>;
+	pinctrl-0 = <&pinctrl_esdhc3_base_1 &pinctrl_esdhc3_8bit_1>;
 	cd-gpios = <&gpio3 11 0>;
 	wp-gpios = <&gpio3 12 0>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/imx53-smd.dts b/arch/arm/boot/dts/imx53-smd.dts
index 74d34872..668c518 100644
--- a/arch/arm/boot/dts/imx53-smd.dts
+++ b/arch/arm/boot/dts/imx53-smd.dts
@@ -95,7 +95,7 @@
 
 &esdhc3 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_esdhc3_1>;
+	pinctrl-0 = <&pinctrl_esdhc3_base_1 &pinctrl_esdhc3_8bit_1>;
 	non-removable;
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/imx53-tqma53.dtsi b/arch/arm/boot/dts/imx53-tqma53.dtsi
index 82b0bd8..4c95c93 100644
--- a/arch/arm/boot/dts/imx53-tqma53.dtsi
+++ b/arch/arm/boot/dts/imx53-tqma53.dtsi
@@ -60,7 +60,7 @@
 
 &esdhc3 { /* EMMC */
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_esdhc3_1>;
+	pinctrl-0 = <&pinctrl_esdhc3_base_1 &pinctrl_esdhc3_8bit_1>;
 	vmmc-supply = <&reg_3p3v>;
 	non-removable;
 	bus-width = <8>;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index bfbeaef..a3e1eee 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -490,18 +490,23 @@
 				};
 
 				esdhc3 {
-					pinctrl_esdhc3_1: esdhc3grp-1 {
+					pinctrl_esdhc3_base_1: esdhc3-basegrp-1 {
 						fsl,pins = <
 							MX53_PAD_PATA_DATA8__ESDHC3_DAT0  0x1d5
 							MX53_PAD_PATA_DATA9__ESDHC3_DAT1  0x1d5
 							MX53_PAD_PATA_DATA10__ESDHC3_DAT2 0x1d5
 							MX53_PAD_PATA_DATA11__ESDHC3_DAT3 0x1d5
+							MX53_PAD_PATA_RESET_B__ESDHC3_CMD 0x1d5
+							MX53_PAD_PATA_IORDY__ESDHC3_CLK   0x1d5
+						>;
+					};
+
+					pinctrl_esdhc3_8bit_1: esdhc3-8bitgrp-1 {
+						fsl,pins = <
 							MX53_PAD_PATA_DATA0__ESDHC3_DAT4  0x1d5
 							MX53_PAD_PATA_DATA1__ESDHC3_DAT5  0x1d5
 							MX53_PAD_PATA_DATA2__ESDHC3_DAT6  0x1d5
 							MX53_PAD_PATA_DATA3__ESDHC3_DAT7  0x1d5
-							MX53_PAD_PATA_RESET_B__ESDHC3_CMD 0x1d5
-							MX53_PAD_PATA_IORDY__ESDHC3_CLK   0x1d5
 						>;
 					};
 				};
-- 
1.8.3.2



From s.hauer at pengutronix.de  Thu Jul 18 03:46:07 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 18 Jul 2013 09:46:07 +0200
Subject: [RFC] Split i.MX pinctrl groups
Message-ID: <1374133571-7660-1-git-send-email-s.hauer@pengutronix.de>

We currently introduce completely new pinctrl groups for each slight
variant of the pinctrl setup of a device. For several devices the
groups can be split into smaller groups to increase the flexibility
and to reduce the devicetree sizes (both source and dtb).

For example SDHC controller groups can be split into a base group
and an 8bit extension. The FEC groups can be split into base group
and several MDIO groups. The UARTs can be split into a base group
and RTS/CTS extensions.

Doing this makes the group names more obvious. Instead of having
just index _1, _2 and so on we now have base_1, 8bit_1.

This is not meant for inclusion right now, just some preliminary
patches to demonstrate the idea to see if this is acceptable/desired.

Sascha

----------------------------------------------------------------
Sascha Hauer (4):
      ARM: dts: i.MX6: split enet pins into smaller groups
      ARM: dts: i.MX53: split esdhc1 pins into base and 8bit groups
      ARM: dts: i.MX53: split esdhc2 pins into base and 8bit groups
      ARM: dts: i.MX53: split esdhc3 pins into base and 8bit groups

 arch/arm/boot/dts/imx53-ard.dts            |  2 +-
 arch/arm/boot/dts/imx53-evk.dts            |  4 +--
 arch/arm/boot/dts/imx53-m53evk.dts         |  2 +-
 arch/arm/boot/dts/imx53-qsb.dts            |  4 +--
 arch/arm/boot/dts/imx53-smd.dts            |  6 ++--
 arch/arm/boot/dts/imx53-tqma53.dtsi        |  4 +--
 arch/arm/boot/dts/imx53.dtsi               | 23 ++++++++--------
 arch/arm/boot/dts/imx6dl-wandboard.dts     |  2 +-
 arch/arm/boot/dts/imx6dl.dtsi              | 31 ++++++++++-----------
 arch/arm/boot/dts/imx6q-arm2.dts           |  2 +-
 arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi |  2 +-
 arch/arm/boot/dts/imx6q-sabrelite.dts      |  2 +-
 arch/arm/boot/dts/imx6q-sbc6x.dts          |  2 +-
 arch/arm/boot/dts/imx6q.dtsi               | 44 +++++++-----------------------
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi   |  2 +-
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi     |  2 +-
 16 files changed, 53 insertions(+), 81 deletions(-)


From s.hauer at pengutronix.de  Thu Jul 18 03:46:10 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 18 Jul 2013 09:46:10 +0200
Subject: [PATCH 3/4] ARM: dts: i.MX53: split esdhc2 pins into base and 8bit
 groups
In-Reply-To: <1374133571-7660-1-git-send-email-s.hauer@pengutronix.de>
References: <1374133571-7660-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1374133571-7660-4-git-send-email-s.hauer@pengutronix.de>

This splits the esdhc2 groups into a base group and an 8bit extension
which results in smaller devicetrees and more obvious pinctrl group
names.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 arch/arm/boot/dts/imx53-smd.dts     | 2 +-
 arch/arm/boot/dts/imx53-tqma53.dtsi | 2 +-
 arch/arm/boot/dts/imx53.dtsi        | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx53-smd.dts b/arch/arm/boot/dts/imx53-smd.dts
index a8fb844..74d34872 100644
--- a/arch/arm/boot/dts/imx53-smd.dts
+++ b/arch/arm/boot/dts/imx53-smd.dts
@@ -48,7 +48,7 @@
 
 &esdhc2 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_esdhc2_1>;
+	pinctrl-0 = <&pinctrl_esdhc2_base_1>;
 	non-removable;
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/imx53-tqma53.dtsi b/arch/arm/boot/dts/imx53-tqma53.dtsi
index abd72af..82b0bd8 100644
--- a/arch/arm/boot/dts/imx53-tqma53.dtsi
+++ b/arch/arm/boot/dts/imx53-tqma53.dtsi
@@ -35,7 +35,7 @@
 
 &esdhc2 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_esdhc2_1>,
+	pinctrl-0 = <&pinctrl_esdhc2_base_1>,
 		    <&pinctrl_tqma53_esdhc2_2>;
 	vmmc-supply = <&reg_3p3v>;
 	wp-gpios = <&gpio1 2 0>;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 6e317766..bfbeaef 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -477,7 +477,7 @@
 				};
 
 				esdhc2 {
-					pinctrl_esdhc2_1: esdhc2grp-1 {
+					pinctrl_esdhc2_base_1: esdhc2-basegrp-1 {
 						fsl,pins = <
 							MX53_PAD_SD2_CMD__ESDHC2_CMD	0x1d5
 							MX53_PAD_SD2_CLK__ESDHC2_CLK	0x1d5
-- 
1.8.3.2



From s.hauer at pengutronix.de  Thu Jul 18 03:46:09 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 18 Jul 2013 09:46:09 +0200
Subject: [PATCH 2/4] ARM: dts: i.MX53: split esdhc1 pins into base and 8bit
 groups
In-Reply-To: <1374133571-7660-1-git-send-email-s.hauer@pengutronix.de>
References: <1374133571-7660-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1374133571-7660-3-git-send-email-s.hauer@pengutronix.de>

This splits the esdhc1 groups into a base group and an 8bit extension
which results in smaller devicetrees and more obvious pinctrl group
names.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 arch/arm/boot/dts/imx53-ard.dts    |  2 +-
 arch/arm/boot/dts/imx53-evk.dts    |  2 +-
 arch/arm/boot/dts/imx53-m53evk.dts |  2 +-
 arch/arm/boot/dts/imx53-qsb.dts    |  2 +-
 arch/arm/boot/dts/imx53-smd.dts    |  2 +-
 arch/arm/boot/dts/imx53.dtsi       | 10 ++--------
 6 files changed, 7 insertions(+), 13 deletions(-)

diff --git a/arch/arm/boot/dts/imx53-ard.dts b/arch/arm/boot/dts/imx53-ard.dts
index 174f869..2d47fd6 100644
--- a/arch/arm/boot/dts/imx53-ard.dts
+++ b/arch/arm/boot/dts/imx53-ard.dts
@@ -99,7 +99,7 @@
 
 &esdhc1 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_esdhc1_2>;
+	pinctrl-0 = <&pinctrl_esdhc1_base_1 &pinctrl_esdhc1_8bit_1>;
 	cd-gpios = <&gpio1 1 0>;
 	wp-gpios = <&gpio1 9 0>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/imx53-evk.dts b/arch/arm/boot/dts/imx53-evk.dts
index 801fda7..2d093b5 100644
--- a/arch/arm/boot/dts/imx53-evk.dts
+++ b/arch/arm/boot/dts/imx53-evk.dts
@@ -34,7 +34,7 @@
 
 &esdhc1 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_esdhc1_1>;
+	pinctrl-0 = <&pinctrl_esdhc1_base_1>;
 	cd-gpios = <&gpio3 13 0>;
 	wp-gpios = <&gpio3 14 0>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/imx53-m53evk.dts b/arch/arm/boot/dts/imx53-m53evk.dts
index 7d304d0..91c08f7 100644
--- a/arch/arm/boot/dts/imx53-m53evk.dts
+++ b/arch/arm/boot/dts/imx53-m53evk.dts
@@ -120,7 +120,7 @@
 
 &esdhc1 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_esdhc1_1>;
+	pinctrl-0 = <&pinctrl_esdhc1_base_1>;
 	cd-gpios = <&gpio1 1 0>;
 	wp-gpios = <&gpio1 9 0>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
index 512a1f6..508390f 100644
--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@ -112,7 +112,7 @@
 
 &esdhc1 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_esdhc1_1>;
+	pinctrl-0 = <&pinctrl_esdhc1_base_1>;
 	cd-gpios = <&gpio3 13 0>;
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/imx53-smd.dts b/arch/arm/boot/dts/imx53-smd.dts
index a9b6e10..a8fb844 100644
--- a/arch/arm/boot/dts/imx53-smd.dts
+++ b/arch/arm/boot/dts/imx53-smd.dts
@@ -40,7 +40,7 @@
 
 &esdhc1 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_esdhc1_1>;
+	pinctrl-0 = <&pinctrl_esdhc1_base_1>;
 	cd-gpios = <&gpio3 13 0>;
 	wp-gpios = <&gpio4 11 0>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 3895fbb..6e317766 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -455,7 +455,7 @@
 				};
 
 				esdhc1 {
-					pinctrl_esdhc1_1: esdhc1grp-1 {
+					pinctrl_esdhc1_base_1: esdhc1-basegrp-1 {
 						fsl,pins = <
 							MX53_PAD_SD1_DATA0__ESDHC1_DAT0 0x1d5
 							MX53_PAD_SD1_DATA1__ESDHC1_DAT1 0x1d5
@@ -466,18 +466,12 @@
 						>;
 					};
 
-					pinctrl_esdhc1_2: esdhc1grp-2 {
+					pinctrl_esdhc1_8bit_1: esdhc1-8bitgrp-1 {
 						fsl,pins = <
-							MX53_PAD_SD1_DATA0__ESDHC1_DAT0   0x1d5
-							MX53_PAD_SD1_DATA1__ESDHC1_DAT1   0x1d5
-							MX53_PAD_SD1_DATA2__ESDHC1_DAT2   0x1d5
-							MX53_PAD_SD1_DATA3__ESDHC1_DAT3   0x1d5
 							MX53_PAD_PATA_DATA8__ESDHC1_DAT4  0x1d5
 							MX53_PAD_PATA_DATA9__ESDHC1_DAT5  0x1d5
 							MX53_PAD_PATA_DATA10__ESDHC1_DAT6 0x1d5
 							MX53_PAD_PATA_DATA11__ESDHC1_DAT7 0x1d5
-							MX53_PAD_SD1_CMD__ESDHC1_CMD	  0x1d5
-							MX53_PAD_SD1_CLK__ESDHC1_CLK	  0x1d5
 						>;
 					};
 				};
-- 
1.8.3.2



From s.hauer at pengutronix.de  Thu Jul 18 03:46:08 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 18 Jul 2013 09:46:08 +0200
Subject: [PATCH 1/4] ARM: dts: i.MX6: split enet pins into smaller groups
In-Reply-To: <1374133571-7660-1-git-send-email-s.hauer@pengutronix.de>
References: <1374133571-7660-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1374133571-7660-2-git-send-email-s.hauer@pengutronix.de>

We used to have complete pinctrl groups for each device. This turns
out to be quite inflexible since we have to introduce a new pinctrl
group for each slight difference. This splits the enet pinctrl groups
into:

- a base group
- two mdio groups
- one enet ref clk group

This results in smaller devicetrees (both binary and source code) and
increased flexibility.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 arch/arm/boot/dts/imx6dl-wandboard.dts     |  2 +-
 arch/arm/boot/dts/imx6dl.dtsi              | 31 ++++++++++-----------
 arch/arm/boot/dts/imx6q-arm2.dts           |  2 +-
 arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi |  2 +-
 arch/arm/boot/dts/imx6q-sabrelite.dts      |  2 +-
 arch/arm/boot/dts/imx6q-sbc6x.dts          |  2 +-
 arch/arm/boot/dts/imx6q.dtsi               | 44 +++++++-----------------------
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi   |  2 +-
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi     |  2 +-
 9 files changed, 31 insertions(+), 58 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts b/arch/arm/boot/dts/imx6dl-wandboard.dts
index bfc59c3..e3d3e11 100644
--- a/arch/arm/boot/dts/imx6dl-wandboard.dts
+++ b/arch/arm/boot/dts/imx6dl-wandboard.dts
@@ -22,7 +22,7 @@
 
 &fec {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet_1>;
+	pinctrl-0 = <&pinctrl_enet_1 &pinctrl_enet_mdio_1 &pinctrl_enet_ref_1>;
 	phy-mode = "rgmii";
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 2b3ecd6..8a740f1 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -61,8 +61,6 @@
 				enet {
 					pinctrl_enet_1: enetgrp-1 {
 						fsl,pins = <
-							MX6DL_PAD_ENET_MDIO__ENET_MDIO       0x1b0b0
-							MX6DL_PAD_ENET_MDC__ENET_MDC         0x1b0b0
 							MX6DL_PAD_RGMII_TXC__RGMII_TXC       0x1b0b0
 							MX6DL_PAD_RGMII_TD0__RGMII_TD0       0x1b0b0
 							MX6DL_PAD_RGMII_TD1__RGMII_TD1       0x1b0b0
@@ -76,27 +74,26 @@
 							MX6DL_PAD_RGMII_RD2__RGMII_RD2       0x1b0b0
 							MX6DL_PAD_RGMII_RD3__RGMII_RD3       0x1b0b0
 							MX6DL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
-							MX6DL_PAD_GPIO_16__ENET_REF_CLK      0x4001b0a8
 						>;
 					};
 
-					pinctrl_enet_2: enetgrp-2 {
+					pinctrl_enet_mdio_1: enet-mdiogrp-1 {
+						fsl,pins = <
+							MX6DL_PAD_ENET_MDIO__ENET_MDIO       0x1b0b0
+							MX6DL_PAD_ENET_MDC__ENET_MDC         0x1b0b0
+						>;
+					};
+
+					pinctrl_enet_mdio_2: enet-mdiogrp-2 {
 						fsl,pins = <
 							MX6DL_PAD_KEY_COL1__ENET_MDIO        0x1b0b0
 							MX6DL_PAD_KEY_COL2__ENET_MDC         0x1b0b0
-							MX6DL_PAD_RGMII_TXC__RGMII_TXC       0x1b0b0
-							MX6DL_PAD_RGMII_TD0__RGMII_TD0       0x1b0b0
-							MX6DL_PAD_RGMII_TD1__RGMII_TD1       0x1b0b0
-							MX6DL_PAD_RGMII_TD2__RGMII_TD2       0x1b0b0
-							MX6DL_PAD_RGMII_TD3__RGMII_TD3       0x1b0b0
-							MX6DL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
-							MX6DL_PAD_ENET_REF_CLK__ENET_TX_CLK  0x1b0b0
-							MX6DL_PAD_RGMII_RXC__RGMII_RXC       0x1b0b0
-							MX6DL_PAD_RGMII_RD0__RGMII_RD0       0x1b0b0
-							MX6DL_PAD_RGMII_RD1__RGMII_RD1       0x1b0b0
-							MX6DL_PAD_RGMII_RD2__RGMII_RD2       0x1b0b0
-							MX6DL_PAD_RGMII_RD3__RGMII_RD3       0x1b0b0
-							MX6DL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
+						>;
+					};
+
+					pinctrl_enet_ref_1: enet-refgrp-1 {
+						fsl,pins = <
+							MX6DL_PAD_GPIO_16__ENET_REF_CLK      0x4001b0a8
 						>;
 					};
 				};
diff --git a/arch/arm/boot/dts/imx6q-arm2.dts b/arch/arm/boot/dts/imx6q-arm2.dts
index 4e54fde..3425bc1 100644
--- a/arch/arm/boot/dts/imx6q-arm2.dts
+++ b/arch/arm/boot/dts/imx6q-arm2.dts
@@ -74,7 +74,7 @@
 
 &fec {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet_2>;
+	pinctrl-0 = <&pinctrl_enet_1 &pinctrl_enet_mdio_2>;
 	phy-mode = "rgmii";
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
index f5e1981..c2ed29c 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
@@ -44,7 +44,7 @@
 
 &fec {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet_3>;
+	pinctrl-0 = <&pinctrl_enet_1 &pinctrl_enet_mdio_1>;
 	phy-mode = "rgmii";
 	phy-reset-gpios = <&gpio3 23 0>;
 	status = "disabled";
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts b/arch/arm/boot/dts/imx6q-sabrelite.dts
index 6a00066..48661a4 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -118,7 +118,7 @@
 
 &fec {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet_1>;
+	pinctrl-0 = <&pinctrl_enet_1 &pinctrl_enet_mdio_1 &pinctrl_enet_ref_1>;
 	phy-mode = "rgmii";
 	phy-reset-gpios = <&gpio3 23 0>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/imx6q-sbc6x.dts b/arch/arm/boot/dts/imx6q-sbc6x.dts
index ee6addf..8d0e4ad 100644
--- a/arch/arm/boot/dts/imx6q-sbc6x.dts
+++ b/arch/arm/boot/dts/imx6q-sbc6x.dts
@@ -19,7 +19,7 @@
 
 &fec {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet_1>;
+	pinctrl-0 = <&pinctrl_enet_1 &pinctrl_enet_mdio_1 &pinctrl_enet_ref_1>;
 	phy-mode = "rgmii";
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index ba09dc3..09797ca 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -123,8 +123,6 @@
 				enet {
 					pinctrl_enet_1: enetgrp-1 {
 						fsl,pins = <
-							MX6Q_PAD_ENET_MDIO__ENET_MDIO       0x1b0b0
-							MX6Q_PAD_ENET_MDC__ENET_MDC         0x1b0b0
 							MX6Q_PAD_RGMII_TXC__RGMII_TXC       0x1b0b0
 							MX6Q_PAD_RGMII_TD0__RGMII_TD0       0x1b0b0
 							MX6Q_PAD_RGMII_TD1__RGMII_TD1       0x1b0b0
@@ -138,48 +136,26 @@
 							MX6Q_PAD_RGMII_RD2__RGMII_RD2       0x1b0b0
 							MX6Q_PAD_RGMII_RD3__RGMII_RD3       0x1b0b0
 							MX6Q_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
-							MX6Q_PAD_GPIO_16__ENET_REF_CLK      0x4001b0a8
 						>;
 					};
 
-					pinctrl_enet_2: enetgrp-2 {
+					pinctrl_enet_mdio_1: enet-mdiogrp-1 {
+						fsl,pins = <
+							MX6Q_PAD_ENET_MDIO__ENET_MDIO       0x1b0b0
+							MX6Q_PAD_ENET_MDC__ENET_MDC         0x1b0b0
+						>;
+					};
+
+					pinctrl_enet_mdio_2: enet-mdiogrp-2 {
 						fsl,pins = <
 							MX6Q_PAD_KEY_COL1__ENET_MDIO        0x1b0b0
 							MX6Q_PAD_KEY_COL2__ENET_MDC         0x1b0b0
-							MX6Q_PAD_RGMII_TXC__RGMII_TXC       0x1b0b0
-							MX6Q_PAD_RGMII_TD0__RGMII_TD0       0x1b0b0
-							MX6Q_PAD_RGMII_TD1__RGMII_TD1       0x1b0b0
-							MX6Q_PAD_RGMII_TD2__RGMII_TD2       0x1b0b0
-							MX6Q_PAD_RGMII_TD3__RGMII_TD3       0x1b0b0
-							MX6Q_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
-							MX6Q_PAD_ENET_REF_CLK__ENET_TX_CLK  0x1b0b0
-							MX6Q_PAD_RGMII_RXC__RGMII_RXC       0x1b0b0
-							MX6Q_PAD_RGMII_RD0__RGMII_RD0       0x1b0b0
-							MX6Q_PAD_RGMII_RD1__RGMII_RD1       0x1b0b0
-							MX6Q_PAD_RGMII_RD2__RGMII_RD2       0x1b0b0
-							MX6Q_PAD_RGMII_RD3__RGMII_RD3       0x1b0b0
-							MX6Q_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
 						>;
 					};
 
-					pinctrl_enet_3: enetgrp-3 {
+					pinctrl_enet_ref_1: enet-refgrp-1 {
 						fsl,pins = <
-							MX6Q_PAD_ENET_MDIO__ENET_MDIO       0x1b0b0
-							MX6Q_PAD_ENET_MDC__ENET_MDC         0x1b0b0
-							MX6Q_PAD_RGMII_TXC__RGMII_TXC       0x1b0b0
-							MX6Q_PAD_RGMII_TD0__RGMII_TD0       0x1b0b0
-							MX6Q_PAD_RGMII_TD1__RGMII_TD1       0x1b0b0
-							MX6Q_PAD_RGMII_TD2__RGMII_TD2       0x1b0b0
-							MX6Q_PAD_RGMII_TD3__RGMII_TD3       0x1b0b0
-							MX6Q_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
-							MX6Q_PAD_ENET_REF_CLK__ENET_TX_CLK  0x1b0b0
-							MX6Q_PAD_RGMII_RXC__RGMII_RXC       0x1b0b0
-							MX6Q_PAD_RGMII_RD0__RGMII_RD0       0x1b0b0
-							MX6Q_PAD_RGMII_RD1__RGMII_RD1       0x1b0b0
-							MX6Q_PAD_RGMII_RD2__RGMII_RD2       0x1b0b0
-							MX6Q_PAD_RGMII_RD3__RGMII_RD3       0x1b0b0
-							MX6Q_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
-							MX6Q_PAD_ENET_TX_EN__ENET_TX_EN     0x1b0b0
+							MX6Q_PAD_GPIO_16__ENET_REF_CLK      0x4001b0a8
 						>;
 					};
 				};
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index e994011..32a0f55 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -34,7 +34,7 @@
 
 &fec {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet_2>;
+	pinctrl-0 = <&pinctrl_enet_1 &pinctrl_enet_mdio_2>;
 	phy-mode = "rgmii";
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 6e5dfdb..906d267 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -79,7 +79,7 @@
 
 &fec {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet_1>;
+	pinctrl-0 = <&pinctrl_enet_1 &pinctrl_enet_mdio_1 &pinctrl_enet_ref_1>;
 	phy-mode = "rgmii";
 	status = "okay";
 };
-- 
1.8.3.2



From yann.morin.1998 at free.fr  Thu Jul 18 03:47:02 2013
From: yann.morin.1998 at free.fr (Yann E. MORIN)
Date: Thu, 18 Jul 2013 09:47:02 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <20130718003408.bb9d5b51.akpm@linux-foundation.org>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <CAMuHMdXzcRxEBqavTx-kEq6CNAx5fYug0w8kjDw=vNfS2iX4Fw@mail.gmail.com>
 <20130718003408.bb9d5b51.akpm@linux-foundation.org>
Message-ID: <201307180947.02456.yann.morin.1998@free.fr>

Andrew, All,

On Thursday 18 July 2013 09:34:08 Andrew Morton wrote:
> On Thu, 18 Jul 2013 09:22:58 +0200 Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > On Thu, Jul 18, 2013 at 12:30 AM, Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
> > > On 2013-07-17 23:16 +0200, Sam Ravnborg spake thusly:
> > >> > We could extend the symbol option part to retreive values from a binary.
> > >> > Something like this:
> > >> >
> > >> > config FOOBAR
> > >> >         bool
> > >> >         option exec="true"
> > >> >
> > >> > FOOBAR would assume the value "y" if the command true has exit code == 0, otherwise "n".
> > >> > And similar conversions for other types.
> > >> >
> > >> > This only extendt Kconfig slightly - using an already present method to import
> > >> > external values.
> > >> Following is a quick patch implmenting this idea.
> > >> You need to run gperf manually to enable this.
> > >>
> > >> "gperf -C scripts/kconfig/zconf.gperf > scripts/kconfig/zconf.hash.c"
> > >>
> > >> I did not figure out how to use the built-in rules to generate this file :-(
> > >
> > > make REGENERATE_PARSERS=y menuconfig
> > >
> > >> I have tested this lightly - as we should discuss if this is a viable way forward.
> > >
> > > Instead of extending the Kconfig language, I was thinking (as initially
> > > suggested by Andrew) of generating a Kconfig file before all config
> > > targets, and source that Kconfig file from $(TOPDIR)/Kconfig.
> > 
> > I also prefer the generated Kconfig file.
> > It keeps all these checks in a single place, instead of spreading it over all
> > Kconfig files. This allows to keep better control over the list of checks, and
> > notice when it gets out-of-hand.
> 
> I prefer the "option exec" approach, actually.  That way the shell-outs
> are colocated with the code which uses

Indeed, but in this case, all the checks will be spread-out in the Kconfig
files, and not easily locatable. Having all in a single script will also
more easily raise eyebrows when that script appears in a diffstat. Noticing
the 'exec' option risks being a bit less easy.

But, that's not my call to decide. ;-)

> them and they will only be executed
> if you've actually selected that subsystem for building (I think?).

If I understand the code correctly (which is still to be proven), the
exec option is run at parse-time, once.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'


From b.brezillon at overkiz.com  Thu Jul 18 03:48:40 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Thu, 18 Jul 2013 09:48:40 +0200
Subject: [PATCH v4 5/5] ASoC: atmel-ssc: remove clk_disable_unprepare call
 from critical section
In-Reply-To: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
References: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374133720-27362-1-git-send-email-b.brezillon@overkiz.com>

clk_prepare/unprepare (and indirectly clk_prepare_enable/disable_unprepare)
may sleep and thus cannot be called in critical section.

This patch fix a bug introduced by commit
6f0d94790efe9f4481bbd7c174ef0e9b5e5db7c4 where clk_disable_unprepare was
called with user_lock hold.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/misc/atmel-ssc.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index f7b90661..e068a76 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -66,14 +66,19 @@ EXPORT_SYMBOL(ssc_request);
 
 void ssc_free(struct ssc_device *ssc)
 {
+	bool disable_clk = true;
+
 	spin_lock(&user_lock);
-	if (ssc->user) {
+	if (ssc->user)
 		ssc->user--;
-		clk_disable_unprepare(ssc->clk);
-	} else {
+	else {
+		disable_clk = false;
 		dev_dbg(&ssc->pdev->dev, "device already free\n");
 	}
 	spin_unlock(&user_lock);
+
+	if (disable_clk)
+		clk_disable_unprepare(ssc->clk);
 }
 EXPORT_SYMBOL(ssc_free);
 
-- 
1.7.9.5



From plagnioj at jcrosoft.com  Thu Jul 18 03:49:52 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 18 Jul 2013 09:49:52 +0200
Subject: [PATCH V2 1/8] serial: at91: correct definition from DMA to PDC
In-Reply-To: <1373942627-7121-2-git-send-email-elen.song@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
 <1373942627-7121-2-git-send-email-elen.song@atmel.com>
Message-ID: <20130718074952.GB16015@ns203013.ovh.net>

On 10:43 Tue 16 Jul     , Elen Song wrote:
> The DMA is available since at91sam9x5 socs, before that, we use PDC.
> 
> Signed-off-by: Elen Song <elen.song at atmel.com>
> ---
>  drivers/tty/serial/atmel_serial.c |   71 +++++++++++++++++++------------------
>  1 file changed, 36 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 3467462..6c71ccf 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -140,11 +140,11 @@ struct atmel_uart_port {
>  	u32			backup_imr;	/* IMR saved during suspend */
>  	int			break_active;	/* break being received */
>  
> -	short			use_dma_rx;	/* enable PDC receiver */
> +	short			use_pdc_rx;	/* enable PDC receiver */
	as this is a boolean you should update the type too
>  	short			pdc_rx_idx;	/* current PDC RX buffer */
>  	struct atmel_dma_buffer	pdc_rx[2];	/* PDC receier */
>  
> -	short			use_dma_tx;	/* enable PDC transmitter */
> +	short			use_pdc_tx;	/* enable PDC transmitter */
ditto
>  	struct atmel_dma_buffer	pdc_tx;		/* PDC transmitter */
>  
>  	struct tasklet_struct	tasklet;
> @@ -181,26 +181,26 @@ to_atmel_uart_port(struct uart_port *uart)
>  }
>  
>  #ifdef CONFIG_SERIAL_ATMEL_PDC
> -static bool atmel_use_dma_rx(struct uart_port *port)
> +static bool atmel_use_pdc_rx(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  
> -	return atmel_port->use_dma_rx;
> +	return atmel_port->use_pdc_rx;
>  }
>  
> -static bool atmel_use_dma_tx(struct uart_port *port)
> +static bool atmel_use_pdc_tx(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  
> -	return atmel_port->use_dma_tx;
> +	return atmel_port->use_pdc_tx;
>  }
>  #else
> -static bool atmel_use_dma_rx(struct uart_port *port)
> +static bool atmel_use_pdc_rx(struct uart_port *port)
>  {
>  	return false;
>  }
>  
> -static bool atmel_use_dma_tx(struct uart_port *port)
> +static bool atmel_use_pdc_tx(struct uart_port *port)
>  {
>  	return false;
>  }
> @@ -233,7 +233,7 @@ void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
>  		mode |= ATMEL_US_USMODE_RS485;
>  	} else {
>  		dev_dbg(port->dev, "Setting UART to RS232\n");
> -		if (atmel_use_dma_tx(port))
> +		if (atmel_use_pdc_tx(port))
>  			atmel_port->tx_done_mask = ATMEL_US_ENDTX |
>  				ATMEL_US_TXBUFE;
>  		else
> @@ -345,7 +345,7 @@ static void atmel_stop_tx(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  
> -	if (atmel_use_dma_tx(port)) {
> +	if (atmel_use_pdc_tx(port)) {
>  		/* disable PDC transmit */
>  		UART_PUT_PTCR(port, ATMEL_PDC_TXTDIS);
>  	}
> @@ -364,7 +364,7 @@ static void atmel_start_tx(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  
> -	if (atmel_use_dma_tx(port)) {
> +	if (atmel_use_pdc_tx(port)) {
>  		if (UART_GET_PTSR(port) & ATMEL_PDC_TXTEN)
>  			/* The transmitter is already running.  Yes, we
>  			   really need this.*/
> @@ -390,7 +390,7 @@ static void atmel_start_rx(struct uart_port *port)
>  
>  	UART_PUT_CR(port, ATMEL_US_RXEN);
>  
> -	if (atmel_use_dma_rx(port)) {
> +	if (atmel_use_pdc_rx(port)) {
>  		/* enable PDC controller */
>  		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
>  			port->read_status_mask);
> @@ -407,7 +407,7 @@ static void atmel_stop_rx(struct uart_port *port)
>  {
>  	UART_PUT_CR(port, ATMEL_US_RXDIS);
>  
> -	if (atmel_use_dma_rx(port)) {
> +	if (atmel_use_pdc_rx(port)) {
>  		/* disable PDC receive */
>  		UART_PUT_PTCR(port, ATMEL_PDC_RXTDIS);
>  		UART_PUT_IDR(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
> @@ -572,7 +572,7 @@ atmel_handle_receive(struct uart_port *port, unsigned int pending)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  
> -	if (atmel_use_dma_rx(port)) {
> +	if (atmel_use_pdc_rx(port)) {
>  		/*
>  		 * PDC receive. Just schedule the tasklet and let it
>  		 * figure out the details.
> @@ -661,7 +661,7 @@ static irqreturn_t atmel_interrupt(int irq, void *dev_id)
>  /*
>   * Called from tasklet with ENDTX and TXBUFE interrupts disabled.
>   */
> -static void atmel_tx_dma(struct uart_port *port)
> +static void atmel_tx_pdc(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  	struct circ_buf *xmit = &port->state->xmit;
> @@ -778,7 +778,7 @@ static void atmel_rx_from_ring(struct uart_port *port)
>  	spin_lock(&port->lock);
>  }
>  
> -static void atmel_rx_from_dma(struct uart_port *port)
> +static void atmel_rx_from_pdc(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  	struct tty_port *tport = &port->state->port;
> @@ -868,8 +868,8 @@ static void atmel_tasklet_func(unsigned long data)
>  	/* The interrupt handler does not take the lock */
>  	spin_lock(&port->lock);
>  
> -	if (atmel_use_dma_tx(port))
> -		atmel_tx_dma(port);
> +	if (atmel_use_pdc_tx(port))
> +		atmel_tx_pdc(port);
>  	else
>  		atmel_tx_chars(port);
>  
> @@ -893,8 +893,8 @@ static void atmel_tasklet_func(unsigned long data)
>  		atmel_port->irq_status_prev = status;
>  	}
>  
> -	if (atmel_use_dma_rx(port))
> -		atmel_rx_from_dma(port);
> +	if (atmel_use_pdc_rx(port))
> +		atmel_rx_from_pdc(port);
>  	else
>  		atmel_rx_from_ring(port);
>  
> @@ -930,7 +930,7 @@ static int atmel_startup(struct uart_port *port)
>  	/*
>  	 * Initialize DMA (if necessary)
>  	 */
> -	if (atmel_use_dma_rx(port)) {
> +	if (atmel_use_pdc_rx(port)) {
>  		int i;
>  
>  		for (i = 0; i < 2; i++) {
> @@ -964,7 +964,7 @@ static int atmel_startup(struct uart_port *port)
>  		UART_PUT_RNPR(port, atmel_port->pdc_rx[1].dma_addr);
>  		UART_PUT_RNCR(port, PDC_BUFFER_SIZE);
>  	}
> -	if (atmel_use_dma_tx(port)) {
> +	if (atmel_use_pdc_tx(port)) {
>  		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
>  		struct circ_buf *xmit = &port->state->xmit;
>  
> @@ -1000,7 +1000,7 @@ static int atmel_startup(struct uart_port *port)
>  	/* enable xmit & rcvr */
>  	UART_PUT_CR(port, ATMEL_US_TXEN | ATMEL_US_RXEN);
>  
> -	if (atmel_use_dma_rx(port)) {
> +	if (atmel_use_pdc_rx(port)) {
>  		/* set UART timeout */
>  		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
>  		UART_PUT_CR(port, ATMEL_US_STTTO);
> @@ -1031,7 +1031,7 @@ static void atmel_shutdown(struct uart_port *port)
>  	/*
>  	 * Shut-down the DMA.
>  	 */
> -	if (atmel_use_dma_rx(port)) {
> +	if (atmel_use_pdc_rx(port)) {
>  		int i;
>  
>  		for (i = 0; i < 2; i++) {
> @@ -1044,7 +1044,7 @@ static void atmel_shutdown(struct uart_port *port)
>  			kfree(pdc->buf);
>  		}
>  	}
> -	if (atmel_use_dma_tx(port)) {
> +	if (atmel_use_pdc_tx(port)) {
>  		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
>  
>  		dma_unmap_single(port->dev,
> @@ -1080,7 +1080,7 @@ static void atmel_flush_buffer(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  
> -	if (atmel_use_dma_tx(port)) {
> +	if (atmel_use_pdc_tx(port)) {
>  		UART_PUT_TCR(port, 0);
>  		atmel_port->pdc_tx.ofs = 0;
>  	}
> @@ -1193,7 +1193,7 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
>  	if (termios->c_iflag & (BRKINT | PARMRK))
>  		port->read_status_mask |= ATMEL_US_RXBRK;
>  
> -	if (atmel_use_dma_rx(port))
> +	if (atmel_use_pdc_rx(port))
>  		/* need to enable error interrupts */
>  		UART_PUT_IER(port, port->read_status_mask);
>  
> @@ -1430,13 +1430,14 @@ static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
>  
>  	/* DMA/PDC usage specification */
>  	if (of_get_property(np, "atmel,use-dma-rx", NULL))
> -		atmel_port->use_dma_rx	= 1;
> +		atmel_port->use_pdc_rx	= 1;
>  	else
> -		atmel_port->use_dma_rx	= 0;
> +		atmel_port->use_pdc_rx	= 0;
> +
>  	if (of_get_property(np, "atmel,use-dma-tx", NULL))
> -		atmel_port->use_dma_tx	= 1;
> +		atmel_port->use_pdc_tx	= 1;
>  	else
> -		atmel_port->use_dma_tx	= 0;
> +		atmel_port->use_pdc_tx	= 0;
>  
>  	/* rs485 properties */
>  	if (of_property_read_u32_array(np, "rs485-rts-delay",
> @@ -1467,8 +1468,8 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
>  	if (pdev->dev.of_node) {
>  		atmel_of_init_port(atmel_port, pdev->dev.of_node);
>  	} else {
> -		atmel_port->use_dma_rx	= pdata->use_dma_rx;
> -		atmel_port->use_dma_tx	= pdata->use_dma_tx;
> +		atmel_port->use_pdc_rx	= pdata->use_dma_rx;
> +		atmel_port->use_pdc_tx	= pdata->use_dma_tx;
>  		atmel_port->rs485	= pdata->rs485;
>  	}
>  
> @@ -1505,7 +1506,7 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
>  	/* Use TXEMPTY for interrupt when rs485 else TXRDY or ENDTX|TXBUFE */
>  	if (atmel_port->rs485.flags & SER_RS485_ENABLED)
>  		atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
> -	else if (atmel_use_dma_tx(port)) {
> +	else if (atmel_use_pdc_tx(port)) {
>  		port->fifosize = PDC_BUFFER_SIZE;
>  		atmel_port->tx_done_mask = ATMEL_US_ENDTX | ATMEL_US_TXBUFE;
>  	} else {
> @@ -1794,7 +1795,7 @@ static int atmel_serial_probe(struct platform_device *pdev)
>  		goto err;
>  	}
>  
> -	if (!atmel_use_dma_rx(&port->uart)) {
> +	if (!atmel_use_pdc_rx(&port->uart)) {
>  		ret = -ENOMEM;
>  		data = kmalloc(sizeof(struct atmel_uart_char)
>  				* ATMEL_SERIAL_RINGSIZE, GFP_KERNEL);
> -- 
> 1.7.9.5
> 


From tony at atomide.com  Thu Jul 18 03:50:06 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 00:50:06 -0700
Subject: [PATCH 4/4] drivers: Add pinctrl handling for dynamic pin states
In-Reply-To: <51E70ADF.8090805@wwwdotorg.org>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090539.5541.980.stgit@localhost>
 <51E70ADF.8090805@wwwdotorg.org>
Message-ID: <20130718074508.GQ7656@atomide.com>

* Stephen Warren <swarren at wwwdotorg.org> [130717 14:28]:
> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
> > We want to have static pin states handled separately from
> > dynamic pin states, so let's add optional state_active.
> > 
> > Then if state_active is defined, let's check and make sure
> > state_idle and state_sleep match state_active for the
> > pin groups to avoid checking them during runtime as the
> > active and idle pins may need to be toggled for many
> > devices every time we enter and exit idle.
> 
> > +	 * Note that if active state is defined, sleep and idle states must
> > +	 * cover the same pin groups as active state.
> >  	 */
> >  	dev->pins->sleep_state = pinctrl_lookup_state(dev->pins->p,
> >  					PINCTRL_STATE_SLEEP);
> > -	if (IS_ERR(dev->pins->sleep_state))
> > +	if (IS_ERR(dev->pins->sleep_state)) {
> >  		/* Not supplying this state is perfectly legal */
> >  		dev_dbg(dev, "no sleep pinctrl state\n");
> > +	} else if (!IS_ERR(dev->pins->active_state)) {
> > +		ret = pinctrl_check_dynamic(dev, dev->pins->active_state,
> > +					    dev->pins->sleep_state);
> 
> Oh, I see you're trying to check that the set of pins in the active,
> sleep, and idle states are identical.

Right, that's to avoid any further checking during runtime for runtime PM.
 
> But I think that pinctrl_check_dynamic() only checks that one state is a
> subset of the other, not that the two states are equal. Instead, I think
> you want to comparison coded in pinctrl_check_dynamic() to be:

In pinctrl_check_dynamic() we check that the pins match between the
states, and the number of found pins matches the first set. I'll
take a look if we check the total pins between the two sets.
 
> gen_group_list_of_pinctrl_state(s1, array1);
> gen_group_list_of_pinctrl_state(s2, array2);
> mismatch = memcmp(array1, array2, length);

Well we could allocate and sort the pins, but the number of pins
for runtime PM is typically very small for each pin consumer device.
Typically you just need to toggle RX pin to GPIO mode for idle. And
this check is only done during consumer driver probe time. So
optimizing it for larger sets could be done at any point later on
as needed.

Regards,

Tony


From akpm at linux-foundation.org  Thu Jul 18 03:52:03 2013
From: akpm at linux-foundation.org (Andrew Morton)
Date: Thu, 18 Jul 2013 00:52:03 -0700
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <201307180947.02456.yann.morin.1998@free.fr>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <CAMuHMdXzcRxEBqavTx-kEq6CNAx5fYug0w8kjDw=vNfS2iX4Fw@mail.gmail.com>
 <20130718003408.bb9d5b51.akpm@linux-foundation.org>
 <201307180947.02456.yann.morin.1998@free.fr>
Message-ID: <20130718005203.9e9dc1d1.akpm@linux-foundation.org>

On Thu, 18 Jul 2013 09:47:02 +0200 "Yann E. MORIN" <yann.morin.1998 at free.fr> wrote:

> > 
> > I prefer the "option exec" approach, actually.  That way the shell-outs
> > are colocated with the code which uses
> 
> Indeed, but in this case, all the checks will be spread-out in the Kconfig
> files, and not easily locatable. Having all in a single script will also
> more easily raise eyebrows when that script appears in a diffstat. Noticing
> the 'exec' option risks being a bit less easy.

Eh, there are a million ways to screw up the kernel.

> But, that's not my call to decide. ;-)
> 
> > them and they will only be executed
> > if you've actually selected that subsystem for building (I think?).
> 
> If I understand the code correctly (which is still to be proven), the
> exec option is run at parse-time, once.

Yes, but not every Kconfig file in the tree gets parsed every time. 
For example, if arch/arm/Kconfig uses "option exec=some-slow-thing",
x86 users won't execute some-slow-thing.  This is good.



From viresh.kumar at linaro.org  Thu Jul 18 03:53:42 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 18 Jul 2013 13:23:42 +0530
Subject: [RFC PATCH v2 11/15] cpufreq: kirkwood-cpufreq: remove device
 tree parsing for cpu nodes
In-Reply-To: <20130717144355.GE1026@lunn.ch>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374069984-20567-12-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <20130717144355.GE1026@lunn.ch>
Message-ID: <CAKohpomoxFBQjDh12OkFB-NnuKzf0u-ZiotF7qa8Cs8Sa8nvNQ@mail.gmail.com>

On 17 July 2013 20:13, Andrew Lunn <andrew at lunn.ch> wrote:
> Are we not going a bit backwards here? You are replacing two lines
> with 10 lines.
>
> How about putting these 10 lines into some helper,
> of_get_cpu_device()?  It would be useful for spear, kirkwood and
> imx6q, and maybe others.

+1


From viresh.kumar at linaro.org  Thu Jul 18 03:54:18 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 18 Jul 2013 13:24:18 +0530
Subject: [RFC PATCH v2 00/15] DT/core: update cpu device of_node
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <CAKohpok_CA5x6Sk7cRQ2y7yMy_A-Sk+CfE3obg3Ybbq7wUsTiw@mail.gmail.com>

On 17 July 2013 19:36,  <Sudeep.KarkadaNagesha at arm.com> wrote:
> 3. Added Acks from Viresh and Shawn

Add it for the new cpufreq drivers included in this patchset too..


From b.brezillon at overkiz.com  Thu Jul 18 03:58:11 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Thu, 18 Jul 2013 09:58:11 +0200
Subject: [PATCH v4 1/5] ARM: at91/tc/clocksource: replace clk_enable/disable
 with clk_prepare_enable/disable_unprepare.
In-Reply-To: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
References: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <1374134291-27704-1-git-send-email-b.brezillon@overkiz.com>

Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/clocksource/tcb_clksrc.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index 8a61872..229c019 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -100,7 +100,7 @@ static void tc_mode(enum clock_event_mode m, struct clock_event_device *d)
 			|| tcd->clkevt.mode == CLOCK_EVT_MODE_ONESHOT) {
 		__raw_writel(0xff, regs + ATMEL_TC_REG(2, IDR));
 		__raw_writel(ATMEL_TC_CLKDIS, regs + ATMEL_TC_REG(2, CCR));
-		clk_disable(tcd->clk);
+		clk_disable_unprepare(tcd->clk);
 	}
 
 	switch (m) {
@@ -109,7 +109,7 @@ static void tc_mode(enum clock_event_mode m, struct clock_event_device *d)
 	 * of oneshot, we get lower overhead and improved accuracy.
 	 */
 	case CLOCK_EVT_MODE_PERIODIC:
-		clk_enable(tcd->clk);
+		clk_prepare_enable(tcd->clk);
 
 		/* slow clock, count up to RC, then irq and restart */
 		__raw_writel(timer_clock
@@ -126,7 +126,7 @@ static void tc_mode(enum clock_event_mode m, struct clock_event_device *d)
 		break;
 
 	case CLOCK_EVT_MODE_ONESHOT:
-		clk_enable(tcd->clk);
+		clk_prepare_enable(tcd->clk);
 
 		/* slow clock, count up to RC, then irq and stop */
 		__raw_writel(timer_clock | ATMEL_TC_CPCSTOP
@@ -275,7 +275,7 @@ static int __init tcb_clksrc_init(void)
 	pdev = tc->pdev;
 
 	t0_clk = tc->clk[0];
-	clk_enable(t0_clk);
+	clk_prepare_enable(t0_clk);
 
 	/* How fast will we be counting?  Pick something over 5 MHz.  */
 	rate = (u32) clk_get_rate(t0_clk);
@@ -313,7 +313,7 @@ static int __init tcb_clksrc_init(void)
 		/* tclib will give us three clocks no matter what the
 		 * underlying platform supports.
 		 */
-		clk_enable(tc->clk[1]);
+		clk_prepare_enable(tc->clk[1]);
 		/* setup both channel 0 & 1 */
 		tcb_setup_dual_chan(tc, best_divisor_idx);
 	}
-- 
1.7.9.5



From plagnioj at jcrosoft.com  Thu Jul 18 03:48:39 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 18 Jul 2013 09:48:39 +0200
Subject: [PATCH V2 0/8] serial: at91: make usart and uart support dma
 transfer
In-Reply-To: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
Message-ID: <20130718074839.GA16015@ns203013.ovh.net>

On 10:43 Tue 16 Jul     , Elen Song wrote:
> After at91sam9g45 socs, the usart only support dma transfer.
> This patch serial focus on:
> 1) distinguish pdc and dma transfer
> 2) support usart dma rx and tx transfer
> 3) distinguish usart and uart
> 4) support uart dma rx and tx transfer
> 
> For those only support PDC transfer socs, we use "atmel,use-dma-rx/tx" to establish a PDC transfer.
> For those only support DMA transfer socs, we not only use "atmel,use-dma-rx/tx", but also describe dma binding to establish a DMA transfer. 
> We switch the name from "use-dma" to "use-pdc" in serial driver to state more clearly.
> We also distinguish usart and uart by read ip name, the dbgu is regard as a uart.
> Because uart lack timeout function, we use software timer to trigger rx.
> 
> Compare to v1, this patch serials improve:
> 1) use function pointer instead of if/else
> 2) "atmel,use-dma-rx/tx" represent a PDC transfer,
>    but when add the dma bindings, it is a dma transfer
> 3) do not use strncmp in get ip name
> 4) remove modification in documentation part

please next time update this too when sending a new verison as I was nearly
NACKing it as I thought it was the same version

Please be carefull next time

Best Regards,
J.
> 
> Elen Song (7):
>   serial: at91: correct definition from DMA to PDC
>   serial: at91: add tx dma support
>   serial: at91: add rx dma support
>   serial: at91: make DBGU support dma and pdc transfers
>   serial: at91: distinguish usart and uart
>   serial: at91: modify UART to use software timer to trigger rx
>   serial: at91: add dma support in usart binding descriptions
> 
>  Documentation/devicetree/bindings/serial/rs485.txt |    4 +-
>  .../devicetree/bindings/tty/serial/atmel-usart.txt |   29 +-
>  arch/arm/boot/dts/at91rm9200.dtsi                  |   16 +-
>  arch/arm/boot/dts/at91sam9260.dtsi                 |   24 +-
>  arch/arm/boot/dts/at91sam9263.dtsi                 |   12 +-
>  arch/arm/boot/dts/at91sam9g45.dtsi                 |   16 +-
>  arch/arm/mach-at91/at91rm9200_devices.c            |   20 +-
>  arch/arm/mach-at91/at91sam9260_devices.c           |   28 +-
>  arch/arm/mach-at91/at91sam9261_devices.c           |   16 +-
>  arch/arm/mach-at91/at91sam9263_devices.c           |   16 +-
>  arch/arm/mach-at91/at91sam9g45_devices.c           |   20 +-
>  arch/arm/mach-at91/at91sam9rl_devices.c            |   20 +-
>  drivers/tty/serial/atmel_serial.c                  |  582 ++++++++++++++++++--
>  include/linux/atmel_serial.h                       |    2 +
>  include/linux/platform_data/atmel.h                |    2 +
>  15 files changed, 665 insertions(+), 142 deletions(-)
> 
> -- 
> 1.7.9.5
> 


From geert at linux-m68k.org  Thu Jul 18 04:02:27 2013
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Thu, 18 Jul 2013 10:02:27 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the new
 streaming format
In-Reply-To: <51E72752.9020206@zytor.com>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716004727.b60b2c96.akpm@linux-foundation.org>
 <20130716005611.e4ccab02.akpm@linux-foundation.org>
 <201307161008.07643.yann.morin.1998@free.fr>
 <20130716180408.GA19863@merkur.ravnborg.org>
 <20130717211649.GA5619@merkur.ravnborg.org>
 <20130717223033.GF3385@free.fr> <51E72752.9020206@zytor.com>
Message-ID: <CAMuHMdVo3rnTtXUZOZavdjJ4uHv4KYPA5g1Py6GTdZD3dPwFzQ@mail.gmail.com>

On Thu, Jul 18, 2013 at 1:22 AM, H. Peter Anvin <hpa at zytor.com> wrote:
> It is worth noting that one of the things that keep getting brought up
> as something that need this is gcc/binutils support for a specific feature.

Yeah, then those tests would be run only once, at kconfig time. I guess we
still run some of them many times, due to the use of recursive make?

Note that these will end up in your .config --- which is not necesarily a bad
thing --- but it does mean that if e.g. you sent me your .config,
several options
may change when I try to use it.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From s.hauer at pengutronix.de  Thu Jul 18 04:06:57 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 18 Jul 2013 10:06:57 +0200
Subject: [PATCH v1 05/24] clk: wrap I/O access for improved portability
In-Reply-To: <20130718070402.GO7080@book.gsilab.sittig.org>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1373914074-20889-6-git-send-email-gsi@denx.de>
 <20130715193829.GS14452@pengutronix.de>
 <20130718070402.GO7080@book.gsilab.sittig.org>
Message-ID: <20130718080657.GI10380@pengutronix.de>

On Thu, Jul 18, 2013 at 09:04:02AM +0200, Gerhard Sittig wrote:
> On Mon, Jul 15, 2013 at 21:38 +0200, Sascha Hauer wrote:
> > 
> > On Mon, Jul 15, 2013 at 08:47:34PM +0200, Gerhard Sittig wrote:
> > > diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> > > index 6d55eb2..2c07061 100644
> > > --- a/drivers/clk/clk-divider.c
> > > +++ b/drivers/clk/clk-divider.c
> > > @@ -104,7 +104,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
> > >  	struct clk_divider *divider = to_clk_divider(hw);
> > >  	unsigned int div, val;
> > >  
> > > -	val = readl(divider->reg) >> divider->shift;
> > > +	val = clk_readl(divider->reg) >> divider->shift;
> > >  	val &= div_mask(divider);
> > 
> > Would it be an option to use regmap for the generic dividers/muxes
> > instead? This should be suitable for ppc and also for people who want to
> > use the generic clocks on i2c devices.
> 
> Some other thought crossed my mind regarding access to clock
> control registers that reside behind some communication channel
> like I2C:
> 
> The common clock API assumes (it's part of the contract) that
> there are potentially expensive operations like get, put, prepare
> and unprepare, as well as swift and non-blocking operations like
> enable and disable.
> 
> Would the regmap abstraction hide the potentially blocking nature
> of a register access (I understand that you can implement "local"
> as well as "remote" register sets by this mechanism)?  Or could
> you still meet the assumptions or requirements of the common
> clock API?
> 
> It might as well be the responsibility of the clock driver's
> implementor to arrange for the availability of non-blocking
> enable/disable operations, just as it is today.  Such that
> expensive register access need not be forbidden in general.

regmap for mmio uses a spinlock for read/modify/write operations, just
like you have to use a spinlock in the common clk dividers/gates. This
part wouldn't change with regmap.

For i2c connected clocks where a spinlock doesn't work due to the
nonatomic nature of i2c devices we would have to move the enable/disble
stuff to prepare/unprepare in the common gate code. This can be left
for someone who works on i2c clocks though.

I think regmap has the potential to solve a number of issues like the
hardcoded readl/writel in the common clock blocks, issues with i2c
clocks and your endianess issue. The biggest question probably is how
to get there without putting too much of a burden on you. It's probably
not an option to convert all users to regmap, so it seems additional
functions like clk_register_gate_regmap are better to handle.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From tony at atomide.com  Thu Jul 18 04:09:53 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 01:09:53 -0700
Subject: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for
 uart3/4
In-Reply-To: <51E6C939.40208@ti.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
 <1374061312-25469-4-git-send-email-grygorii.strashko@ti.com>
 <20130717153248.GI7656@atomide.com> <51E6C939.40208@ti.com>
Message-ID: <20130718080953.GR7656@atomide.com>

* Grygorii Strashko <grygorii.strashko at ti.com> [130717 09:48]:
> Hi,
> 
> On 07/17/2013 06:32 PM, Tony Lindgren wrote:
> >* Grygorii Strashko <grygorii.strashko at ti.com> [130717 04:49]:
> >>Add dynamic "active"/"idle" pin states for uart3/4 which will be applied
> >>when uart3/4 state is switched from active to idle and back by Runtime
> >>PM or during system suspend.
> >
> >This is good for testing code, but should not be merged because
> >omap4 has the iopad wake-ups available for uarts. So those can
> >be always enabled.
> 
> In this case, 2 IRQ will be received per each UART RX event - one from
> PRCM and from UART - and that's not good from PM perspective (It will
> affect on CPUIdle and CPUFreq at least).

Oh I see, that's because I accidentally left the debug code enabled
to make it easier to test the wake-up events without having to
have working off-idle. The wake flags can be kept on always for
sure.

The patch below should sort out the issue of getting wake-up interrupts
during runtime as long as you don't have DEBUG defined.

Regards,

Tony

--- a/drivers/pinctrl/pinctrl-single-omap.c
+++ b/drivers/pinctrl/pinctrl-single-omap.c
@@ -140,9 +140,17 @@ static irqreturn_t pcs_omap_handle_irq(int irq, void *data)
 		if ((val & OMAP_WAKEUP_EVENT_MASK) == OMAP_WAKEUP_EVENT_MASK)
 			generic_handle_irq(wakeirq);
 	}
-
+#ifdef DEBUG
+	/*
+	 * This enables wake-up interrupts during runtime also
+	 * causing duplicate interrupts. But it also makes debugging
+	 * the wake-up events easy as deeper idle states often are
+	 * not working for new devices while the drivers are being
+	 * developed.
+	 */
 	if (pcso->reconfigure_io_chain)
 		pcso->reconfigure_io_chain();
+#endif
 
 	return IRQ_HANDLED;
 }


From tony at atomide.com  Thu Jul 18 04:14:06 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 01:14:06 -0700
Subject: [PATCH 2/3] ARM: OMAP2+: omap_device: add pinctrl handling
In-Reply-To: <51E6CCB6.2000907@ti.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
 <1374061312-25469-3-git-send-email-grygorii.strashko@ti.com>
 <20130717153838.GJ7656@atomide.com> <51E6CCB6.2000907@ti.com>
Message-ID: <20130718081405.GS7656@atomide.com>

* Grygorii Strashko <grygorii.strashko at ti.com> [130717 10:11]:
> On 07/17/2013 06:38 PM, Tony Lindgren wrote:
> >* Grygorii Strashko <grygorii.strashko at ti.com> [130717 04:49]:
> >>Before switching to DT pinctrl states of OMAP IPs have been handled by hwmod
> >>framework. After switching to DT-boot the pinctrl handling was dropped from
> >>hwmod framework and, as it was recommended, OMAP IP's drivers have to be updated
> >>to handle pinctrl states by itself using pinctrl_pm_select_xx() helpers
> >>(see http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html)
> >>
> >>But this is not right for OMAP2+ SoC where real IPs state is controlled
> >>by omap_device core which enables/disables modules & clocks actually.
> >
> >I'm not convinced we should try to handle this in a generic way
> >as only some devices need dynamic remuxing of some pins.
> >
> >>For example, if OMAP I2C driver will handle pinctrl state during system wide
> >>suspend the following issue may occure:
> >>- suspend_noirq - I2C device can be still active because of PM auto-suspend
> >>   |-_od_suspend_noirq
> >>      |- omap_i2c_suspend_noirq
> >>         |- PINs state set to SLEEP
> >>   |- pm_generic_runtime_suspend
> >>      |- omap_i2c_runtime_suspend()
> >>         |- PINs state set to IDLE  <--- *oops* PINs state is IDLE and not SLEEP
> >>   |- omap_device_idle()
> >>      |- omap_hwmod_idle()
> >>         |- _idle()
> >>            |- disbale module (sysc&clocks)
> >
> >And in this example you are assuming that you need separate idle and
> >sleep states, which is not true at least for most cases I've seen.
> 
> I don't need both states (at least right now) :), but
> - if any OMAP2+ driver will have two states defined: "idle" and "sleep"
> - and if it will try to manage them from drivers callbacks only using
>   pure calls to pinctrl_pm_select_xx() helpers
> 
> the "idle" state will be selected during suspend and *not* "sleep".

But the drivers have separate calls for runtime PM and suspend/resume?

> >It is possible that am33xx needs separate idle and sleep states, but
> >most likely only for some pins. For omap[345] we can get away with
> >just the default state for most cases.
> >
> 
> 
> In case, if only "default" state is defined for device - nothing will
>  be done by OMAP device framework for it (I mean any call to
> pinctrl_pm_select_xx() will do nothing - it just checks that there is
> no state and returns 0).

If we want to automate something, it should be done at Linux generic
level rather than at omap "bus" level. That sort of relates to drivers
needing to know when they've lost context too, which should be
implemented in Linux generic way.

Regards,

Tony


From plagnioj at jcrosoft.com  Thu Jul 18 04:15:20 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 18 Jul 2013 10:15:20 +0200
Subject: [PATCH V2 5/8] serial: at91: support run time switch transfer mode
In-Reply-To: <1373942627-7121-6-git-send-email-elen.song@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
 <1373942627-7121-6-git-send-email-elen.song@atmel.com>
Message-ID: <20130718081520.GC16015@ns203013.ovh.net>

On 10:43 Tue 16 Jul     , Elen Song wrote:
> We will switch to pio mode when request of dma or pdc fail.
> But soon or later, when the request is success, the transfer mode can switch to them at
> next open serial port action.
> So in startup stage, we should get original transfer mode.

You need to update the Documentation of the binding to said the driver support
dmas bindings for the new IP

and please use true/false for boolean

and check the white space
> 
> Signed-off-by: Elen Song <elen.song at atmel.com>
> ---
>  drivers/tty/serial/atmel_serial.c |  139 +++++++++++++++++++++----------------
>  1 file changed, 80 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 298b58c..ad787fd1 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -1371,6 +1371,80 @@ static void atmel_tasklet_func(unsigned long data)
>  	spin_unlock(&port->lock);
>  }
>  
> +static int atmel_init_property(struct atmel_uart_port *atmel_port,
> +				struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct atmel_uart_data *pdata = pdev->dev.platform_data;
> +
> +	if (np) {
> +		/* DMA/PDC usage specification */
> +		if (of_get_property(np, "atmel,use-dma-rx", NULL)) {
> +			if (of_get_property(np, "dmas", NULL)) {
> +				atmel_port->use_dma_rx  = 1;
> +				atmel_port->use_pdc_rx  = 0;
> +			} else {
> +				atmel_port->use_dma_rx  = 0;
> +				atmel_port->use_pdc_rx  = 1;
> +			}
> +		} else {
> +			atmel_port->use_dma_rx  = 0;
> +			atmel_port->use_pdc_rx  = 0;
> +		}
> +
> +		if (of_get_property(np, "atmel,use-dma-tx", NULL)) {
> +			if (of_get_property(np, "dmas", NULL)) {
> +				atmel_port->use_dma_tx  = 1;
> +				atmel_port->use_pdc_tx  = 0;
> +			} else {
> +				atmel_port->use_dma_tx  = 0;
> +				atmel_port->use_pdc_tx  = 1;
> +			}
> +		} else {
> +			atmel_port->use_dma_tx  = 0;
> +			atmel_port->use_pdc_tx  = 0;
> +		}
> +
> +	} else {
> +		atmel_port->use_pdc_rx  = pdata->use_dma_rx;
> +		atmel_port->use_pdc_tx  = pdata->use_dma_tx;
> +		atmel_port->use_dma_rx  = 0;
> +		atmel_port->use_dma_tx  = 0;
> +	}
> +
> +	return 0;
> +}
> +
> +static void atmel_init_rs485(struct atmel_uart_port *atmel_port,
> +				struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct atmel_uart_data *pdata = pdev->dev.platform_data;
> +
> +	if (np) {
> +		u32 rs485_delay[2];
> +		/* rs485 properties */
> +		if (of_property_read_u32_array(np, "rs485-rts-delay",
> +					rs485_delay, 2) == 0) {
> +			struct serial_rs485 *rs485conf = &atmel_port->rs485;
> +
> +			rs485conf->delay_rts_before_send = rs485_delay[0];
> +			rs485conf->delay_rts_after_send = rs485_delay[1];
> +			rs485conf->flags = 0;
> +
> +		if (of_get_property(np, "rs485-rx-during-tx", NULL))
> +			rs485conf->flags |= SER_RS485_RX_DURING_TX;
> +
> +		if (of_get_property(np, "linux,rs485-enabled-at-boot-time",
> +								NULL))
> +			rs485conf->flags |= SER_RS485_ENABLED;
> +		}
> +	} else {
> +		atmel_port->rs485       = pdata->rs485;
> +	}
> +
> +}
> +
>  static void atmel_set_ops(struct uart_port *port)
>  {
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> @@ -1409,6 +1483,7 @@ static void atmel_set_ops(struct uart_port *port)
>   */
>  static int atmel_startup(struct uart_port *port)
>  {
> +	struct platform_device *pdev = to_platform_device(port->dev);
>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>  	struct tty_struct *tty = port->state->port.tty;
>  	int retval;
> @@ -1433,6 +1508,8 @@ static int atmel_startup(struct uart_port *port)
>  	/*
>  	 * Initialize DMA (if necessary)
>  	 */
> +	atmel_init_property(atmel_port, pdev);
> +
>  	if (atmel_port->prepare_rx) {
>  		retval = atmel_port->prepare_rx(port);
>  		if (retval < 0)
> @@ -1878,55 +1955,6 @@ static struct uart_ops atmel_pops = {
>  #endif
>  };
>  
> -static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
> -					 struct device_node *np)
> -{
> -	u32 rs485_delay[2];
> -
> -	/* DMA/PDC usage specification */
> -	if (of_get_property(np, "atmel,use-dma-rx", NULL)) {
> -		if (of_get_property(np, "dmas", NULL)) {
> -			atmel_port->use_dma_rx	= 1;
> -			atmel_port->use_pdc_rx	= 0;
> -		} else {
> -			atmel_port->use_dma_rx	= 0;
> -			atmel_port->use_pdc_rx	= 1;
> -		}
> -	} else {
> -		atmel_port->use_dma_rx	= 0;
> -		atmel_port->use_pdc_rx	= 0;
> -	}
> -
> -	if (of_get_property(np, "atmel,use-dma-tx", NULL)) {
> -		if (of_get_property(np, "dmas", NULL)) {
> -			atmel_port->use_dma_tx	= 1;
> -			atmel_port->use_pdc_tx	= 0;
> -		} else {
> -			atmel_port->use_dma_tx	= 0;
> -			atmel_port->use_pdc_tx	= 1;
> -		}
> -	} else {
> -		atmel_port->use_dma_tx	= 0;
> -		atmel_port->use_pdc_tx	= 0;
> -	}
> -
> -	/* rs485 properties */
> -	if (of_property_read_u32_array(np, "rs485-rts-delay",
> -					    rs485_delay, 2) == 0) {
> -		struct serial_rs485 *rs485conf = &atmel_port->rs485;
> -
> -		rs485conf->delay_rts_before_send = rs485_delay[0];
> -		rs485conf->delay_rts_after_send = rs485_delay[1];
> -		rs485conf->flags = 0;
> -
> -		if (of_get_property(np, "rs485-rx-during-tx", NULL))
> -			rs485conf->flags |= SER_RS485_RX_DURING_TX;
> -
> -		if (of_get_property(np, "linux,rs485-enabled-at-boot-time", NULL))
> -			rs485conf->flags |= SER_RS485_ENABLED;
> -	}
> -}
> -
>  /*
>   * Configure the port from the platform device resource info.
>   */
> @@ -1936,17 +1964,10 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
>  	struct uart_port *port = &atmel_port->uart;
>  	struct atmel_uart_data *pdata = pdev->dev.platform_data;
>  
> -	if (pdev->dev.of_node) {
> -		atmel_of_init_port(atmel_port, pdev->dev.of_node);
> -	} else {
> -		atmel_port->use_pdc_rx	= pdata->use_dma_rx;
> -		atmel_port->use_pdc_tx	= pdata->use_dma_tx;
> -		atmel_port->use_dma_rx	= 0;
> -		atmel_port->use_dma_tx	= 0;
> -		atmel_port->rs485	= pdata->rs485;
> -	}
> +	if (!atmel_init_property(atmel_port, pdev))
> +		atmel_set_ops(port);
>  
> -	atmel_set_ops(port);
> +	atmel_init_rs485(atmel_port, pdev);
>  
>  	port->iotype		= UPIO_MEM;
>  	port->flags		= UPF_BOOT_AUTOCONF;
> -- 
> 1.7.9.5
> 


From plagnioj at jcrosoft.com  Thu Jul 18 04:18:49 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 18 Jul 2013 10:18:49 +0200
Subject: [PATCH V2 6/8] serial: at91: make DBGU support dma and pdc
 transfers
In-Reply-To: <1373942627-7121-7-git-send-email-elen.song@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
 <1373942627-7121-7-git-send-email-elen.song@atmel.com>
Message-ID: <20130718081849.GD16015@ns203013.ovh.net>

On 10:43 Tue 16 Jul     , Elen Song wrote:
> Because the DBGU lack of receive timeout register, so we use a timer to trigger
> data receive.

please re-order the patch put patch 7 before 6
so we can distinguish the uart type not by line = 0 which is wrong as if you
can have no dbgu registered and line == 0 can be a normal usart

Best Regards,
J.
> 
> Signed-off-by: Elen Song <elen.song at atmel.com>
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
> ---
>  drivers/tty/serial/atmel_serial.c |   48 ++++++++++++++++++++++++++++++++-----
>  1 file changed, 42 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index ad787fd1..afecdfa 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -41,6 +41,7 @@
>  #include <linux/uaccess.h>
>  #include <linux/pinctrl/consumer.h>
>  #include <linux/platform_data/atmel.h>
> +#include <linux/timer.h>
>  
>  #include <asm/io.h>
>  #include <asm/ioctls.h>
> @@ -167,6 +168,7 @@ struct atmel_uart_port {
>  
>  	struct serial_rs485	rs485;		/* rs485 settings */
>  	unsigned int		tx_done_mask;
> +	struct timer_list       uart_timer;     /* dbgu timer */
>  	int (*prepare_rx)(struct uart_port *port);
>  	int (*prepare_tx)(struct uart_port *port);
>  	void (*schedule_rx)(struct uart_port *port);
> @@ -821,6 +823,9 @@ static void atmel_release_rx_dma(struct uart_port *port)
>  	atmel_port->desc_rx = NULL;
>  	atmel_port->chan_rx = NULL;
>  	atmel_port->cookie_rx = -EINVAL;
> +
> +	if (port->line == 0)
> +		del_timer_sync(&atmel_port->uart_timer);
>  }
>  
>  static void atmel_rx_from_dma(struct uart_port *port)
> @@ -950,6 +955,15 @@ chan_err:
>  	return -EINVAL;
>  }
>  
> +static void atmel_uart_timer_callback(unsigned long data)
> +{
> +	struct uart_port *port = (void *)data;
> +	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> +
> +	tasklet_schedule(&atmel_port->tasklet);
> +	mod_timer(&atmel_port->uart_timer, jiffies + uart_poll_timeout(port));
> +}
> +
>  /*
>   * receive interrupt handler.
>   */
> @@ -1213,6 +1227,9 @@ static void atmel_release_rx_pdc(struct uart_port *port)
>  				 DMA_FROM_DEVICE);
>  		kfree(pdc->buf);
>  	}
> +
> +	if (port->line == 0)
> +		del_timer_sync(&atmel_port->uart_timer);
>  }
>  
>  static void atmel_rx_from_pdc(struct uart_port *port)
> @@ -1546,17 +1563,36 @@ static int atmel_startup(struct uart_port *port)
>  
>  	if (atmel_use_pdc_rx(port)) {
>  		/* set UART timeout */
> -		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
> -		UART_PUT_CR(port, ATMEL_US_STTTO);
> +		if (port->line == 0) {
> +			setup_timer(&atmel_port->uart_timer,
> +					atmel_uart_timer_callback,
> +					(unsigned long)port);
> +			mod_timer(&atmel_port->uart_timer,
> +					jiffies + uart_poll_timeout(port));
> +		/* set USART timeout */
> +		} else {
> +			UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
> +			UART_PUT_CR(port, ATMEL_US_STTTO);
>  
> -		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
> +			UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
> +		}
>  		/* enable PDC controller */
>  		UART_PUT_PTCR(port, ATMEL_PDC_RXTEN);
>  	} else if (atmel_use_dma_rx(port)) {
> -		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
> -		UART_PUT_CR(port, ATMEL_US_STTTO);
> +		/* set UART timeout */
> +		if (port->line == 0) {
> +			setup_timer(&atmel_port->uart_timer,
> +					atmel_uart_timer_callback,
> +					(unsigned long)port);
> +			mod_timer(&atmel_port->uart_timer,
> +					jiffies + uart_poll_timeout(port));
> +		/* set USART timeout */
> +		} else {
> +			UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
> +			UART_PUT_CR(port, ATMEL_US_STTTO);
>  
> -		UART_PUT_IER(port, ATMEL_US_TIMEOUT);
> +			UART_PUT_IER(port, ATMEL_US_TIMEOUT);
> +		}
>  	} else {
>  		/* enable receive only */
>  		UART_PUT_IER(port, ATMEL_US_RXRDY);
> -- 
> 1.7.9.5
> 


From plagnioj at jcrosoft.com  Thu Jul 18 04:19:47 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 18 Jul 2013 10:19:47 +0200
Subject: [PATCH V2 0/8] serial: at91: make usart and uart support dma
 transfer
In-Reply-To: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
Message-ID: <20130718081947.GE16015@ns203013.ovh.net>

Hi,

	except the comment this looks good

Best Regards,
J.
On 10:43 Tue 16 Jul     , Elen Song wrote:
> After at91sam9g45 socs, the usart only support dma transfer.
> This patch serial focus on:
> 1) distinguish pdc and dma transfer
> 2) support usart dma rx and tx transfer
> 3) distinguish usart and uart
> 4) support uart dma rx and tx transfer
> 
> For those only support PDC transfer socs, we use "atmel,use-dma-rx/tx" to establish a PDC transfer.
> For those only support DMA transfer socs, we not only use "atmel,use-dma-rx/tx", but also describe dma binding to establish a DMA transfer. 
> We switch the name from "use-dma" to "use-pdc" in serial driver to state more clearly.
> We also distinguish usart and uart by read ip name, the dbgu is regard as a uart.
> Because uart lack timeout function, we use software timer to trigger rx.
> 
> Compare to v1, this patch serials improve:
> 1) use function pointer instead of if/else
> 2) "atmel,use-dma-rx/tx" represent a PDC transfer,
>    but when add the dma bindings, it is a dma transfer
> 3) do not use strncmp in get ip name
> 4) remove modification in documentation part
> 
> Elen Song (7):
>   serial: at91: correct definition from DMA to PDC
>   serial: at91: add tx dma support
>   serial: at91: add rx dma support
>   serial: at91: make DBGU support dma and pdc transfers
>   serial: at91: distinguish usart and uart
>   serial: at91: modify UART to use software timer to trigger rx
>   serial: at91: add dma support in usart binding descriptions
> 
>  Documentation/devicetree/bindings/serial/rs485.txt |    4 +-
>  .../devicetree/bindings/tty/serial/atmel-usart.txt |   29 +-
>  arch/arm/boot/dts/at91rm9200.dtsi                  |   16 +-
>  arch/arm/boot/dts/at91sam9260.dtsi                 |   24 +-
>  arch/arm/boot/dts/at91sam9263.dtsi                 |   12 +-
>  arch/arm/boot/dts/at91sam9g45.dtsi                 |   16 +-
>  arch/arm/mach-at91/at91rm9200_devices.c            |   20 +-
>  arch/arm/mach-at91/at91sam9260_devices.c           |   28 +-
>  arch/arm/mach-at91/at91sam9261_devices.c           |   16 +-
>  arch/arm/mach-at91/at91sam9263_devices.c           |   16 +-
>  arch/arm/mach-at91/at91sam9g45_devices.c           |   20 +-
>  arch/arm/mach-at91/at91sam9rl_devices.c            |   20 +-
>  drivers/tty/serial/atmel_serial.c                  |  582 ++++++++++++++++++--
>  include/linux/atmel_serial.h                       |    2 +
>  include/linux/platform_data/atmel.h                |    2 +
>  15 files changed, 665 insertions(+), 142 deletions(-)
> 
> -- 
> 1.7.9.5
> 


From Sudeep.KarkadaNagesha at arm.com  Thu Jul 18 04:24:31 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Thu, 18 Jul 2013 09:24:31 +0100
Subject: [RFC PATCH v2 11/15] cpufreq: kirkwood-cpufreq: remove device
 tree parsing for cpu nodes
In-Reply-To: <20130717144355.GE1026@lunn.ch>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374069984-20567-12-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <20130717144355.GE1026@lunn.ch>
Message-ID: <51E7A63F.7020207@arm.com>

On 17/07/13 15:43, Andrew Lunn wrote:
> On Wed, Jul 17, 2013 at 03:06:20PM +0100, Sudeep.KarkadaNagesha at arm.com wrote:
>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>>
>> Now that the cpu device registration initialises the of_node(if available)
>> appropriately for all the cpus, parsing here is redundant.
>>
>> This patch removes all DT parsing and uses cpu->of_node instead.
>>
>> Cc: Andrew Lunn <andrew at lunn.ch>
>> Cc: Jason Cooper <jason at lakedaemon.net>
>> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
>> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>> ---
>>  drivers/cpufreq/kirkwood-cpufreq.c | 14 ++++++++++++--
>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
>> index c233ea6..18aa3eb 100644
>> --- a/drivers/cpufreq/kirkwood-cpufreq.c
>> +++ b/drivers/cpufreq/kirkwood-cpufreq.c
>> @@ -13,6 +13,7 @@
>>  #include <linux/module.h>
>>  #include <linux/clk.h>
>>  #include <linux/clk-provider.h>
>> +#include <linux/cpu.h>
>>  #include <linux/cpufreq.h>
>>  #include <linux/of.h>
>>  #include <linux/platform_device.h>
>> @@ -165,6 +166,7 @@ static struct cpufreq_driver kirkwood_cpufreq_driver = {
>>  static int kirkwood_cpufreq_probe(struct platform_device *pdev)
>>  {
>>  	struct device_node *np;
>> +	struct device *cpu_dev;
>>  	struct resource *res;
>>  	int err;
>>  
>> @@ -175,9 +177,17 @@ static int kirkwood_cpufreq_probe(struct platform_device *pdev)
>>  	if (IS_ERR(priv.base))
>>  		return PTR_ERR(priv.base);
>>  
>> -	np = of_find_node_by_path("/cpus/cpu at 0");
>> -	if (!np)
>> +	cpu_dev = get_cpu_device(0);
>> +	if (!cpu_dev) {
>> +		dev_err(&pdev->dev, "failed to get cpu device\n");
>>  		return -ENODEV;
>> +	}
>> +
>> +	np = of_node_get(cpu_dev->of_node);
>> +	if (!np) {
>> +		dev_err(&pdev->dev, "failed to get cpu device node\n");
>> +		return -ENODEV;
>> +	}
> 
> Hi Sudeep
> 
> Are we not going a bit backwards here? You are replacing two lines
> with 10 lines.
> 
> How about putting these 10 lines into some helper,
> of_get_cpu_device()?  It would be useful for spear, kirkwood and
> imx6q, and maybe others.
> 
Yes I realised that after making changes to this and pmac32 drivers. I
have already made those changes in v3. I am waiting for more response
before posting them.

Regards,
Sudeep





From b.brezillon at overkiz.com  Thu Jul 18 04:27:28 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Thu, 18 Jul 2013 10:27:28 +0200
Subject: [PATCH v4 0/5] ARM: at91: prepare transition to common clk framework
Message-ID: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>

Hello,

This patch series prepares the transition to common clk framework by
replacing all the clk_enable and clk_disable calls by clk_prepare_unable and
clk_disable_unprepare to avoid common clock framework warnings.

Best Regards,
Boris

Changes since v3:
 - move usb clock config patches out of this series
 - move clk_prepare/unprepare calls out of critical sections (ssc and
   mci drivers)
 - remove already applied spi clk_prepare patch 

Changes since v2:
 - add configuraton of usb clock in ohci and udc drivers
 - add clk_prepare patch for usba udc driver
 - add clk_prepare patch for spi driver
 - remove already applied udc clk_prepare patch

Changes since v1:
 - remove unneeded clk_unprepare in mci driver
 - remove already applied patches (ehci, ohci, dma and serial)

Changes since common clk patch series:
 - add clk_prepare_enable return check
 - fix a deadlock in atmel-mci (missing spin_unlock)
 - remove already applied patches (atmel-ssc and pwm-atmel-tcb)

Boris BREZILLON (5):
  ARM: at91/tc/clocksource: replace clk_enable/disable with
    clk_prepare_enable/disable_unprepare.
  mmc: atmel-mci: prepare clk before calling enable
  at91/avr32/atmel_lcdfb: prepare clk before calling enable
  USB: gadget: atmel_usba: prepare clk before calling enable
  ASoC: atmel-ssc: remove clk_disable_unprepare call from critical
    section

 drivers/clocksource/tcb_clksrc.c    |   10 +++++-----
 drivers/misc/atmel-ssc.c            |   11 ++++++++---
 drivers/mmc/host/atmel-mci.c        |   34 +++++++++++++++++++++++++++-------
 drivers/usb/gadget/atmel_usba_udc.c |   28 +++++++++++++++++++++-------
 drivers/video/atmel_lcdfb.c         |    8 ++++----
 5 files changed, 65 insertions(+), 26 deletions(-)

-- 
1.7.9.5



From plagnioj at jcrosoft.com  Thu Jul 18 04:28:58 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 18 Jul 2013 10:28:58 +0200
Subject: [PATCH 6/6] mtd: ofpart: add compatible check for child nodes
In-Reply-To: <CAN8TOE_YfnQ5hK=xO28tH2h39Fb3KcVBFGM=XAFLHnRb0DFO3A@mail.gmail.com>
References: <1372845034-5579-1-git-send-email-josh.wu@atmel.com>
 <1372845034-5579-7-git-send-email-josh.wu@atmel.com>
 <CAN8TOE_YfnQ5hK=xO28tH2h39Fb3KcVBFGM=XAFLHnRb0DFO3A@mail.gmail.com>
Message-ID: <20130718082858.GF16015@ns203013.ovh.net>

On 00:14 Thu 18 Jul     , Brian Norris wrote:
> Adding device tree list, keeping patch context
> 
> On Wed, Jul 3, 2013 at 2:50 AM, Josh Wu <josh.wu at atmel.com> wrote:
> > In case that the nand device will support some features like Nand Flash
> > Controller, we want to make the sub feature as a sub node of nand device.
> >
> > Use such organization it is easy to enable/disable feature, also it is back
> > compatible and more readable.
> >
> > If the sub-node has a compatible property then it is a driver not partition.
> >
> > Signed-off-by: Josh Wu <josh.wu at atmel.com>
> 
> I just came back to this patch series. I think this patch might be
> deserving of a review by the device-tree mailing list. (It also
> doesn't deserve to die in MTD purgatory.)
> 
> BTW, it looks good to me, so:
> 
> Acked-by: Brian Norris <computersforpeace at gmail.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

Rob can take a look on it

Best Regards,
J.
> 
> Thanks,
> Brian
> 
> > ---
> > v3 --> v4:
> >   - remove the 'len' parameter, just use NULL.
> >   - refine the commit message.
> >   - also add a NOTE in devicetree/bindings/mtd/partition.txt.
> >
> >  .../devicetree/bindings/mtd/partition.txt          |    1 +
> >  drivers/mtd/ofpart.c                               |   13 ++++++++++++-
> >  2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt
> > index 9315ac9..8e5557d 100644
> > --- a/Documentation/devicetree/bindings/mtd/partition.txt
> > +++ b/Documentation/devicetree/bindings/mtd/partition.txt
> > @@ -4,6 +4,7 @@ Partitions can be represented by sub-nodes of an mtd device. This can be used
> >  on platforms which have strong conventions about which portions of a flash are
> >  used for what purposes, but which don't use an on-flash partition table such
> >  as RedBoot.
> > +NOTE: if the sub-node has a compatible string, then it is not a partition.
> >
> >  #address-cells & #size-cells must both be present in the mtd device. There are
> >  two valid values for both:
> > diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
> > index 553d6d6..30fcea1 100644
> > --- a/drivers/mtd/ofpart.c
> > +++ b/drivers/mtd/ofpart.c
> > @@ -20,6 +20,10 @@
> >  #include <linux/slab.h>
> >  #include <linux/mtd/partitions.h>
> >
> > +static bool node_has_compatible(struct device_node *pp)
> > +{
> > +       return of_get_property(pp, "compatible", NULL);
> > +}
> >  static int parse_ofpart_partitions(struct mtd_info *master,
> >                                    struct mtd_partition **pparts,
> >                                    struct mtd_part_parser_data *data)
> > @@ -40,8 +44,12 @@ static int parse_ofpart_partitions(struct mtd_info *master,
> >         /* First count the subnodes */
> >         pp = NULL;
> >         nr_parts = 0;
> > -       while ((pp = of_get_next_child(node, pp)))
> > +       while ((pp = of_get_next_child(node, pp))) {
> > +               if (node_has_compatible(pp))
> > +                       continue;
> > +
> >                 nr_parts++;
> > +       }
> >
> >         if (nr_parts == 0)
> >                 return 0;
> > @@ -57,6 +65,9 @@ static int parse_ofpart_partitions(struct mtd_info *master,
> >                 int len;
> >                 int a_cells, s_cells;
> >
> > +               if (node_has_compatible(pp))
> > +                       continue;
> > +
> >                 reg = of_get_property(pp, "reg", &len);
> >                 if (!reg) {
> >                         nr_parts--;
> > --
> > 1.7.9.5
> >


From s.hauer at pengutronix.de  Thu Jul 18 04:36:03 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 18 Jul 2013 10:36:03 +0200
Subject: [PATCH 4/4] ARM: imx6q: remove board specific CLKO setup
In-Reply-To: <1374132670-791-5-git-send-email-shawn.guo@linaro.org>
References: <1374132670-791-1-git-send-email-shawn.guo@linaro.org>
 <1374132670-791-5-git-send-email-shawn.guo@linaro.org>
Message-ID: <20130718083603.GK10380@pengutronix.de>

On Thu, Jul 18, 2013 at 03:31:10PM +0800, Shawn Guo wrote:
> The CLKO is widely used by imx6q board designs to clock audio codec.
> Since most codecs accept 24 MHz frequency, let's initially set up CLKO
> with OSC24M (cko <-- cko2 <-- osc).  Then those board specific CLKO
> setup for audio codec can be removed.
> 
> The board dts files also need an update on cko reference in codec node.
> 
> +	/*
> +	 * Let's initially set up CLKO with OSC24M, since this configuration
> +	 * is widely used by imx6q board designs to clock audio codec.
> +	 */
> +	ret = clk_set_parent(clk[cko2_sel], clk[osc]);
> +	if (!ret)
> +		ret = clk_set_parent(clk[cko], clk[cko2]);
> +	if (ret)
> +		pr_warn("failed to set up CLKO: %d\n", ret);


I don't really like that the clock setup code fiddles with clocks it has
no knowledge about just because it happens to be correct for several
boards.

I currently have no example where this bites me, so I think I can live
with it for now. I just wonder what I should do when this clock is used
for something vital to the system (clocking an FPGA for example?).

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From oleksandr.kozaruk at ti.com  Thu Jul 18 04:36:42 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Thu, 18 Jul 2013 11:36:42 +0300
Subject: [PATCH v5 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <51E6DCB5.3070302@metafoo.de>
References: <1374059564-6872-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1374059564-6872-3-git-send-email-oleksandr.kozaruk@ti.com>
 <51E6DCB5.3070302@metafoo.de>
Message-ID: <CAPb7_muAzO-jRqgcm89fcKT-hTLq38Aj2p0WAWjGjN9DoQUwPg@mail.gmail.com>

Hello Lars,

On Wed, Jul 17, 2013 at 9:04 PM, Lars-Peter Clausen <lars at metafoo.de> wrote:
>> +static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
>> +{
>> +     int chn, d1 = 0, d2 = 0, temp;
>> +     u8 trim_regs[17];
>> +     int ret;
>> +
>> +     ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
>> +                     TWL6030_GPADC_TRIM1, 16);
>> +     if (ret < 0) {
>> +             dev_err(gpadc->dev, "calibration failed\n");
>> +             return ret;
>> +     }
>> +
>> +     /*
>> +      * Loop to calculate the value needed for returning voltages from
>> +      * GPADC not values.
>> +      *
>> +      * gain is calculated to 3 decimal places fixed point.
>> +      */
>> +     for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
>> +
>> +             switch (chn) {
>> +             case 0:
>> +             case 1:
>> +             case 2:
>> +             case 3:
>> +             case 4:
>> +             case 5:
>> +             case 6:
>> +             case 11:
>> +             case 12:
>> +             case 13:
>> +             case 14:
>> +                     /* D1 */
>> +                     d1 = (trim_regs[3] & 0x1F) << 2;
>> +                     d1 |= (trim_regs[1] & 0x06) >> 1;
>> +                     if (trim_regs[1] & 0x01)
>> +                             d1 = -d1;
>> +
>> +                     /* D2 */
>> +                     d2 = (trim_regs[4] & 0x3F) << 2;
>> +                     d2 |= (trim_regs[2] & 0x06) >> 1;
>> +                     if (trim_regs[2] & 0x01)
>> +                             d2 = -d2;
>> +                     break;
>> +             case 8:
>> +                     /* D1 */
>> +                     temp = (trim_regs[3] & 0x1F) << 2;
>> +                     temp |= (trim_regs[1] & 0x06) >> 1;
>> +                     if (trim_regs[1] & 0x01)
>> +                             temp = -temp;
>> +
>> +                     d1 = (trim_regs[8] & 0x18) << 1;
>> +                     d1 |= (trim_regs[7] & 0x1E) >> 1;
>> +                     if (trim_regs[7] & 0x01)
>> +                             d1 = -d1;
>> +
>> +                     d1 += temp;
>> +
>> +                     /* D2 */
>> +                     temp = (trim_regs[4] & 0x3F) << 2;
>> +                     temp |= (trim_regs[2] & 0x06) >> 1;
>> +                     if (trim_regs[2] & 0x01)
>> +                             temp = -temp;
>> +
>> +                     d2 = (trim_regs[10] & 0x1F) << 2;
>> +                     d2 |= (trim_regs[8] & 0x06) >> 1;
>> +                     if (trim_regs[8] & 0x01)
>> +                             d2 = -d2;
>> +
>> +                     d2 += temp;
>> +                     break;
>> +             case 9:
>> +                     /* D1 */
>> +                     temp = (trim_regs[3] & 0x1F) << 2;
>> +                     temp |= (trim_regs[1] & 0x06) >> 1;
>> +                     if (trim_regs[1] & 0x01)
>> +                             temp = -temp;
>> +
>> +                     d1 = (trim_regs[14] & 0x18) << 1;
>> +                     d1 |= (trim_regs[12] & 0x1E) >> 1;
>> +                     if (trim_regs[12] & 0x01)
>> +                             d1 = -d1;
>> +
>> +                     d1 += temp;
>> +
>> +                     /* D2 */
>> +                     temp = (trim_regs[4] & 0x3F) << 2;
>> +                     temp |= (trim_regs[2] & 0x06) >> 1;
>> +                     if (trim_regs[2] & 0x01)
>> +                             temp = -temp;
>> +
>> +                     d2 = (trim_regs[16] & 0x1F) << 2;
>> +                     d2 |= (trim_regs[14] & 0x06) >> 1;
>> +                     if (trim_regs[14] & 0x01)
>> +                             d2 = -d2;
>> +
>> +                     d2 += temp;
>> +             case 10:
>> +                     /* D1 */
>> +                     d1 = (trim_regs[11] & 0x0F) << 3;
>> +                     d1 |= (trim_regs[9] & 0x0E) >> 1;
>> +                     if (trim_regs[9] & 0x01)
>> +                             d1 = -d1;
>> +
>> +                     /* D2 */
>> +                     d2 = (trim_regs[15] & 0x0F) << 3;
>> +                     d2 |= (trim_regs[13] & 0x0E) >> 1;
>> +                     if (trim_regs[13] & 0x01)
>> +                             d2 = -d2;
>> +                     break;
>> +             case 7:
>> +             case 18:
>> +                     /* D1 */
>> +                     temp = (trim_regs[3] & 0x1F) << 2;
>> +                     temp |= (trim_regs[1] & 0x06) >> 1;
>> +                     if (trim_regs[1] & 0x01)
>> +                             temp = -temp;
>> +
>> +                     d1 = (trim_regs[5] & 0x7E) >> 1;
>> +                     if (trim_regs[5] & 0x01)
>> +                             d1 = -d1;
>> +.
>> +                     d1 += temp;
>> +
>> +                     /* D2 */
>> +                     temp = (trim_regs[4] & 0x3F) << 2;
>> +                     temp |= (trim_regs[2] & 0x06) >> 1;
>> +                     if (trim_regs[2] & 0x01)
>> +                             temp = -temp;
>> +
>> +                     d2 = (trim_regs[6] & 0xFE) >> 1;
>> +                     if (trim_regs[6] & 0x01)
>> +                             d2 = -d2;
>> +
>> +                     d2 += temp;
>> +                     break;
>
>
> There is quite a bit of copy paste in here. Putting the bit swizziling into
> a helper function should also improbe legibility.

Trimming bits are scattered randomly between registers and in
different bit positions.
I don't see any commonalities, that could be generalized. as Graeme
said about it "it's a bane of my life".

Regards,
OK.


From jonas.jensen at gmail.com  Thu Jul 18 04:50:26 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Thu, 18 Jul 2013 10:50:26 +0200
Subject: [PATCH] Documentation: Add device tree binding file for MOXA ART SoCs
 interrupt controller
Message-ID: <1374137426-6763-1-git-send-email-jonas.jensen@gmail.com>

Add binding document for MOXA ART SoCs interrupt controller.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    The MOXA ART irqchip driver was added without accompanying devicetree document.
    ( in next-20130716   drivers/irqchip/irq-moxart.c )
    
    Applies to next-20130716

 .../interrupt-controller/moxa,moxart-ic.txt        | 28 ++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/moxa,moxart-ic.txt

diff --git a/Documentation/devicetree/bindings/interrupt-controller/moxa,moxart-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/moxa,moxart-ic.txt
new file mode 100644
index 0000000..58f1fe1
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/moxa,moxart-ic.txt
@@ -0,0 +1,28 @@
+* MOXA ART Interrupt Controller
+
+MOXA ART Interrupt Controller (moxart-ic) is used on MOXA ART SoCs
+and supports 32 non-configurable number of interrupts
+
+Main node required properties:
+
+- compatible : "moxa,moxart-ic"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The type shall be a <u32> and the value shall be 2.
+
+  The first cell contains the interrupt number in the range [0-31].
+  The second cell contains the interrupt type
+
+- reg: physical base address and size of the intc registers map.
+- interrupt-mask: Specifies if the interrupt is edge or level-triggered
+  each bit represent an interrupt 0-31 where 1 signify edge
+
+Example:
+
+	intc: interrupt-controller at 98800000 {
+		compatible = "moxa,moxart-ic";
+		reg = <0x98800000 0x38>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-mask = <0x00080000>;
+	};
-- 
1.8.2.1



From b.brezillon at overkiz.com  Thu Jul 18 04:51:25 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Thu, 18 Jul 2013 10:51:25 +0200
Subject: [PATCH v2 00/42] ARM: at91: move to common clk framework
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <51E7AC8D.4090503@overkiz.com>

On 17/07/2013 15:34, Boris BREZILLON wrote:
> Hello,
>
> This patch series is a proposal to move at91 clock implementation
> to common clk framework.
>
> Most of the clock provided by the PMC (Power Management Controller) are
> implemented :
> - main clock (main oscillator)
> - pll clocks
> - master clock
> - programmable clocks
> - utmi clock
> - peripheral clocks
> - system clocks
>
> This implementation is compatible with device tree: the goal is
> to define the whole clock tree in the device tree (all currently
> available dt SoCs and boards are patched to support dt clocks).
> Please feel free to comment the dt bindinds.
>
> I removed the register_clocks function in SoC supporting dt boards only:
> - at91sam9x5 SoCs
> - at91sam9n12 SoC
> - sama5d3 SoCs
>
> This patch series is based on linux-next and has been tested on sama5d31ek
> board using device tree. It compiles for other SoCs and both with and without
> dt support, but it has not been tested.
This was tested on kizbox board too.
>
> BTW could other people test it on other boards (I only have a kizbox and
> a sama5d31ek dev kit).
>
> Best Regards,
> Boris
>
> Changes since v1:
>   - fix bugs in pll, programmable and system clock implementations
>     (wrong bit position).
>   - add usb clock configuration support (ohci and udc drivers +
>     clk_lookup for non dt boards)
>   - rework of the system clock interfaces (no need to define a parent clock,
>     system clock is a gate with no rate info)
>   - change system, peripheral and programmable clk dt bindings (1 master node
>     and multiple child nodes each defining a system/peripheral or prog clock)
>   - fix bugs in sama5 dt definition
>
> Boris BREZILLON (42):
>    ARM: at91: move at91_pmc.h to include/linux/clk/at91.h
>    ARM: at91: add PMC main clock
>    ARM: at91: add PMC pll clocks
>    ARM: at91: add PMC master clock
>    ARM: at91: add PMC system clocks
>    ARM: at91: add PMC peripheral clocks
>    ARM: at91: add PMC programmable clocks
>    ARM: at91: add PMC utmi clock
>    ARM: at91: add PMC usb clock
>    ARM: at91: add PMC smd clock
>    ARM: at91: add PMC clk device tree binding doc.
>    ARM: at91: move to common clk framework
>    ARM: at91: move at91rm9200 SoC to new at91 clk implem
>    ARM: at91: move at91sam9260 SoC to new at91 clk implem
>    ARM: at91: move at91sam9261 SoC to new at91 clk implem
>    ARM: at91: move at91sam9263 SoC to new at91 clk implem
>    ARM: at91: move at91sam9g45 SoC to new at91 clk implem
>    ARM: at91: move at91sam9n12 SoC to new at91 clk implem
>    ARM: at91: move at91sam9rl SoC to new at91 clk implem
>    ARM: at91: move at91sam9x5 SoCs to new at91 clk implem
>    ARM: at91: move at91sam9 SoCs to new at91 clk implem
>    ARM: at91: move sama5d3 SoCs to new at91 clk implem
>    ARM: at91: move at91rm9200 boards to new at91 clk implem
>    ARM: at91: move at91sam9 boards to new at91 clk implem
>    ARM: at91: move pit timer to common clk framework
>    USB: ohci-at91: add usb_clk for transition to common clk framework
>    usb: gadget: at91_udc: add usb_clk for transition to common clk
>      framework
>    ARM: at91/dt: move at91rm9200 SoC to new at91 clk implem
>    ARM: at91/dt: move at91sam9260 SoC to new at91 clk implem
>    ARM: at91/dt: move at91sam9263 SoC to new at91 clk implem
>    ARM: at91/dt: move at91sam9g45 SoC to new at91 clk implem
>    ARM: at91/dt: move at91sam9n12 SoC to new at91 clk implem
>    ARM: at91/dt: move at91sam9x5 SoCs to new at91 clk implem
>    ARM: at91/dt: move at91sam9g20 SoC to new at91 clk implem
>    ARM: at91/dt: move sama5d3 SoCs to new at91 clk implem
>    ARM: at91/dt: move sam9260/sam9g20 to new at91 clk implem
>    ARM: at91/dt: move rm9200 boards to new at91 clk implem
>    ARM: at91/dt: move sam9263 boards to new at91 clk implem
>    ARM: at91/dt: move sam9g45 boards to new at91 clk implem
>    ARM: at91/dt: move sam9n12 boards to new at91 clk implem
>    ARM: at91/dt: move sam9x5 boards to new at91 clk implem
>    ARM: at91/dt: move sama5d3 boards to new at91 clk implem
>
>   .../devicetree/bindings/clock/at91-clock.txt       |  262 ++++++
>   arch/arm/boot/dts/animeo_ip.dts                    |   17 +-
>   arch/arm/boot/dts/at91-ariag25.dts                 |   17 +-
>   arch/arm/boot/dts/at91rm9200.dtsi                  |  231 +++++
>   arch/arm/boot/dts/at91rm9200ek.dts                 |   17 +-
>   arch/arm/boot/dts/at91sam9260.dtsi                 |  236 +++++
>   arch/arm/boot/dts/at91sam9263.dtsi                 |  237 +++++
>   arch/arm/boot/dts/at91sam9263ek.dts                |   17 +-
>   arch/arm/boot/dts/at91sam9g15.dtsi                 |    1 +
>   arch/arm/boot/dts/at91sam9g20.dtsi                 |   37 +
>   arch/arm/boot/dts/at91sam9g20ek_common.dtsi        |   17 +-
>   arch/arm/boot/dts/at91sam9g25.dtsi                 |    3 +
>   arch/arm/boot/dts/at91sam9g35.dtsi                 |    2 +
>   arch/arm/boot/dts/at91sam9g45.dtsi                 |  257 +++++
>   arch/arm/boot/dts/at91sam9m10g45ek.dts             |   17 +-
>   arch/arm/boot/dts/at91sam9n12.dtsi                 |  251 +++++
>   arch/arm/boot/dts/at91sam9n12ek.dts                |   17 +-
>   arch/arm/boot/dts/at91sam9x25.dtsi                 |   25 +-
>   arch/arm/boot/dts/at91sam9x35.dtsi                 |    3 +
>   arch/arm/boot/dts/at91sam9x5.dtsi                  |  319 +++++--
>   arch/arm/boot/dts/at91sam9x5_can.dtsi              |   26 +
>   arch/arm/boot/dts/at91sam9x5_isi.dtsi              |   22 +
>   arch/arm/boot/dts/at91sam9x5_lcdc.dtsi             |   28 +
>   arch/arm/boot/dts/at91sam9x5_macb0.dtsi            |   66 ++
>   arch/arm/boot/dts/at91sam9x5_macb1.dtsi            |   54 ++
>   arch/arm/boot/dts/at91sam9x5_usart3.dtsi           |   58 ++
>   arch/arm/boot/dts/ge863-pro3.dtsi                  |   16 +-
>   arch/arm/boot/dts/kizbox.dts                       |    5 +
>   arch/arm/boot/dts/mpa1600.dts                      |   16 +-
>   arch/arm/boot/dts/pm9g45.dts                       |   16 +-
>   arch/arm/boot/dts/sama5d3.dtsi                     |  510 ++++++----
>   arch/arm/boot/dts/sama5d31ek.dts                   |    4 +
>   arch/arm/boot/dts/sama5d33ek.dts                   |    2 +
>   arch/arm/boot/dts/sama5d34ek.dts                   |    4 +
>   arch/arm/boot/dts/sama5d35ek.dts                   |    6 +
>   arch/arm/boot/dts/sama5d3_can.dtsi                 |   71 ++
>   arch/arm/boot/dts/sama5d3_emac.dtsi                |   54 ++
>   arch/arm/boot/dts/sama5d3_gmac.dtsi                |   87 ++
>   arch/arm/boot/dts/sama5d3_lcd.dtsi                 |   69 ++
>   arch/arm/boot/dts/sama5d3_mci2.dtsi                |   57 ++
>   arch/arm/boot/dts/sama5d3_tcb1.dtsi                |   38 +
>   arch/arm/boot/dts/sama5d3_uart.dtsi                |   46 +
>   arch/arm/boot/dts/sama5d3xcm.dtsi                  |   17 +-
>   arch/arm/boot/dts/tny_a9260_common.dtsi            |   17 +-
>   arch/arm/boot/dts/tny_a9263.dts                    |   17 +-
>   arch/arm/boot/dts/usb_a9260_common.dtsi            |   17 +-
>   arch/arm/boot/dts/usb_a9263.dts                    |   17 +-
>   arch/arm/mach-at91/Kconfig                         |   26 +
>   arch/arm/mach-at91/Makefile                        |    2 +-
>   arch/arm/mach-at91/at91rm9200.c                    |  568 +++++++-----
>   arch/arm/mach-at91/at91sam9260.c                   |  689 +++++++++-----
>   arch/arm/mach-at91/at91sam9261.c                   |  572 ++++++++----
>   arch/arm/mach-at91/at91sam9263.c                   |  595 +++++++-----
>   arch/arm/mach-at91/at91sam926x_time.c              |   21 +-
>   arch/arm/mach-at91/at91sam9g45.c                   |  704 ++++++++------
>   arch/arm/mach-at91/at91sam9g45_devices.c           |    1 -
>   arch/arm/mach-at91/at91sam9n12.c                   |  196 +---
>   arch/arm/mach-at91/at91sam9rl.c                    |  502 ++++++----
>   arch/arm/mach-at91/at91sam9x5.c                    |  293 +-----
>   arch/arm/mach-at91/board-1arm.c                    |   12 +-
>   arch/arm/mach-at91/board-afeb-9260v1.c             |   11 +-
>   arch/arm/mach-at91/board-cam60.c                   |   13 +-
>   arch/arm/mach-at91/board-carmeva.c                 |   13 +-
>   arch/arm/mach-at91/board-cpu9krea.c                |   12 +-
>   arch/arm/mach-at91/board-cpuat91.c                 |   12 +-
>   arch/arm/mach-at91/board-csb337.c                  |   11 +-
>   arch/arm/mach-at91/board-csb637.c                  |   11 +-
>   arch/arm/mach-at91/board-dt-rm9200.c               |    9 +-
>   arch/arm/mach-at91/board-dt-sam9.c                 |    9 +-
>   arch/arm/mach-at91/board-dt-sama5.c                |    9 +-
>   arch/arm/mach-at91/board-eb9200.c                  |   11 +-
>   arch/arm/mach-at91/board-ecbat91.c                 |   12 +-
>   arch/arm/mach-at91/board-eco920.c                  |   13 +-
>   arch/arm/mach-at91/board-flexibity.c               |   12 +-
>   arch/arm/mach-at91/board-foxg20.c                  |   12 +-
>   arch/arm/mach-at91/board-gsia18s.c                 |    8 +-
>   arch/arm/mach-at91/board-kafa.c                    |   12 +-
>   arch/arm/mach-at91/board-kb9202.c                  |   12 +-
>   arch/arm/mach-at91/board-pcontrol-g20.c            |    9 +-
>   arch/arm/mach-at91/board-picotux200.c              |   11 +-
>   arch/arm/mach-at91/board-qil-a9260.c               |   11 +-
>   arch/arm/mach-at91/board-rm9200ek.c                |   11 +-
>   arch/arm/mach-at91/board-rsi-ews.c                 |   12 +-
>   arch/arm/mach-at91/board-sam9-l9260.c              |   11 +-
>   arch/arm/mach-at91/board-sam9260ek.c               |   11 +-
>   arch/arm/mach-at91/board-sam9261ek.c               |   15 +-
>   arch/arm/mach-at91/board-sam9263ek.c               |   11 +-
>   arch/arm/mach-at91/board-sam9g20ek.c               |   15 +-
>   arch/arm/mach-at91/board-sam9m10g45ek.c            |   11 +-
>   arch/arm/mach-at91/board-sam9rlek.c                |   11 +-
>   arch/arm/mach-at91/board-snapper9260.c             |   12 +-
>   arch/arm/mach-at91/board-stamp9g20.c               |   15 +-
>   arch/arm/mach-at91/board-yl-9200.c                 |   12 +-
>   arch/arm/mach-at91/clock.c                         |  977 --------------------
>   arch/arm/mach-at91/clock.h                         |   49 -
>   arch/arm/mach-at91/generic.h                       |   10 +-
>   arch/arm/mach-at91/pm.c                            |    2 +-
>   arch/arm/mach-at91/pm_slowclock.S                  |    2 +-
>   arch/arm/mach-at91/pmc.c                           |   58 ++
>   arch/arm/mach-at91/sama5d3.c                       |  344 +------
>   arch/arm/mach-at91/setup.c                         |   38 +-
>   arch/arm/mach-at91/stamp9g20.h                     |    2 +-
>   drivers/clk/Makefile                               |    1 +
>   drivers/clk/at91/Makefile                          |   11 +
>   drivers/clk/at91/clk-main.c                        |  106 +++
>   drivers/clk/at91/clk-master.c                      |  317 +++++++
>   drivers/clk/at91/clk-peripheral.c                  |  371 ++++++++
>   drivers/clk/at91/clk-pll.c                         |  438 +++++++++
>   drivers/clk/at91/clk-plldiv.c                      |  125 +++
>   drivers/clk/at91/clk-programmable.c                |  368 ++++++++
>   drivers/clk/at91/clk-smd.c                         |  157 ++++
>   drivers/clk/at91/clk-system.c                      |  184 ++++
>   drivers/clk/at91/clk-usb.c                         |  303 ++++++
>   drivers/clk/at91/clk-utmi.c                        |  114 +++
>   drivers/usb/gadget/at91_udc.c                      |   31 +-
>   drivers/usb/gadget/at91_udc.h                      |    2 +-
>   drivers/usb/gadget/atmel_usba_udc.c                |    2 +-
>   drivers/usb/host/ohci-at91.c                       |   16 +-
>   .../mach/at91_pmc.h => include/linux/clk/at91.h    |  116 ++-
>   119 files changed, 8193 insertions(+), 3835 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/clock/at91-clock.txt
>   create mode 100644 arch/arm/boot/dts/at91sam9x5_can.dtsi
>   create mode 100644 arch/arm/boot/dts/at91sam9x5_isi.dtsi
>   create mode 100644 arch/arm/boot/dts/at91sam9x5_lcdc.dtsi
>   create mode 100644 arch/arm/boot/dts/at91sam9x5_macb0.dtsi
>   create mode 100644 arch/arm/boot/dts/at91sam9x5_macb1.dtsi
>   create mode 100644 arch/arm/boot/dts/at91sam9x5_usart3.dtsi
>   create mode 100644 arch/arm/boot/dts/sama5d3_can.dtsi
>   create mode 100644 arch/arm/boot/dts/sama5d3_emac.dtsi
>   create mode 100644 arch/arm/boot/dts/sama5d3_gmac.dtsi
>   create mode 100644 arch/arm/boot/dts/sama5d3_lcd.dtsi
>   create mode 100644 arch/arm/boot/dts/sama5d3_mci2.dtsi
>   create mode 100644 arch/arm/boot/dts/sama5d3_tcb1.dtsi
>   create mode 100644 arch/arm/boot/dts/sama5d3_uart.dtsi
>   delete mode 100644 arch/arm/mach-at91/clock.c
>   delete mode 100644 arch/arm/mach-at91/clock.h
>   create mode 100644 arch/arm/mach-at91/pmc.c
>   create mode 100644 drivers/clk/at91/Makefile
>   create mode 100644 drivers/clk/at91/clk-main.c
>   create mode 100644 drivers/clk/at91/clk-master.c
>   create mode 100644 drivers/clk/at91/clk-peripheral.c
>   create mode 100644 drivers/clk/at91/clk-pll.c
>   create mode 100644 drivers/clk/at91/clk-plldiv.c
>   create mode 100644 drivers/clk/at91/clk-programmable.c
>   create mode 100644 drivers/clk/at91/clk-smd.c
>   create mode 100644 drivers/clk/at91/clk-system.c
>   create mode 100644 drivers/clk/at91/clk-usb.c
>   create mode 100644 drivers/clk/at91/clk-utmi.c
>   rename arch/arm/mach-at91/include/mach/at91_pmc.h => include/linux/clk/at91.h (78%)
>



From rogerq at ti.com  Thu Jul 18 04:53:04 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 18 Jul 2013 11:53:04 +0300
Subject: [PATCH 0/6] USB: phy: phy-nop: Use RESET controller for managing the
 reset line
Message-ID: <1374137590-17865-1-git-send-email-rogerq@ti.com>

Hi,

Till now we were modelling the RESET line as a voltage regulator and
using the regulator framework to manage it.

[1] introduces a GPIO based reset controller driver. We use that
to manage the PHY reset line, at least for DT boots. For legacy boots,
will still need to use the regulator framework for reset lines.

Felipe,

The first patch is for you. The Kconfig change might conflict if
you apply this on top of my PHY Kconfig cleanup series.

Benoit,

Patches 2 to 6 are for you.

NOTE: All patches depend on [1] which is yet to be merged in.

cheers,
-roger

[1] - http://thread.gmane.org/gmane.linux.drivers.devicetree/41348

Roger Quadros (6):
  usb: phy-nop: Use RESET Controller for managing the reset line
  ARM: dts: omap3-beagle: Use reset-gpio driver for hsusb2_reset
  ARM: dts: omap4-panda: Use reset-gpio driver for hsusb1_reset
  ARM: dts: omap5-uevm: Use reset-gpio driver for hsusb2_reset
  ARM: dts: omap3-beagle-xm: Add USB Host support
  ARM: dts: omap3-beagle: Make USB host pin naming consistent

 .../devicetree/bindings/usb/usb-nop-xceiv.txt      |   10 ++-
 arch/arm/boot/dts/omap3-beagle-xm.dts              |   75 +++++++++++++++++---
 arch/arm/boot/dts/omap3-beagle.dts                 |   41 +++++------
 arch/arm/boot/dts/omap4-panda-common.dtsi          |   22 ++----
 arch/arm/boot/dts/omap5-uevm.dts                   |   17 ++---
 drivers/usb/phy/Kconfig                            |    1 +
 drivers/usb/phy/phy-nop.c                          |   48 ++++++++++---
 7 files changed, 146 insertions(+), 68 deletions(-)

-- 
1.7.4.1



From rogerq at ti.com  Thu Jul 18 04:53:05 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 18 Jul 2013 11:53:05 +0300
Subject: [PATCH 1/6] usb: phy-nop: Use RESET Controller for managing the reset
 line
In-Reply-To: <1374137590-17865-1-git-send-email-rogerq@ti.com>
References: <1374137590-17865-1-git-send-email-rogerq@ti.com>
Message-ID: <1374137590-17865-2-git-send-email-rogerq@ti.com>

Till now we were modelling the RESET line as a voltage regulator and
using the regulator framework to manage it.

[1] introduces a GPIO based reset controller driver. We use that
to manage the PHY reset line, at least for DT boots. For legacy boots,
will still need to use the regulator framework for reset lines.

[1] - http://thread.gmane.org/gmane.linux.drivers.devicetree/41348

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 .../devicetree/bindings/usb/usb-nop-xceiv.txt      |   10 +++--
 drivers/usb/phy/Kconfig                            |    1 +
 drivers/usb/phy/phy-nop.c                          |   48 +++++++++++++++-----
 3 files changed, 44 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
index d7e2726..5c3e978 100644
--- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -15,7 +15,9 @@ Optional properties:
 
 - vcc-supply: phandle to the regulator that provides RESET to the PHY.
 
-- reset-supply: phandle to the regulator that provides power to the PHY.
+- resets: phandle to the reset controller.
+
+- reset-names: must be "reset"
 
 Example:
 
@@ -25,10 +27,10 @@ Example:
 		clocks = <&osc 0>;
 		clock-names = "main_clk";
 		vcc-supply = <&hsusb1_vcc_regulator>;
-		reset-supply = <&hsusb1_reset_regulator>;
+		resets = <&hsusb1_reset>;
+		reset-names = "reset"
 	};
 
 hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
 and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
-hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
-controls RESET.
+hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset controls RESET.
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 3622fff..213b5ad 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -58,6 +58,7 @@ config MV_U3D_PHY
 
 config NOP_USB_XCEIV
 	tristate "NOP USB Transceiver Driver"
+	depends on RESET_CONTROLLER
 	help
 	  This driver is to be used by all the usb transceiver which are either
 	  built-in with usb ip or which are autonomous and doesn't require any
diff --git a/drivers/usb/phy/phy-nop.c b/drivers/usb/phy/phy-nop.c
index 55445e5d..a2cbda5 100644
--- a/drivers/usb/phy/phy-nop.c
+++ b/drivers/usb/phy/phy-nop.c
@@ -35,13 +35,15 @@
 #include <linux/clk.h>
 #include <linux/regulator/consumer.h>
 #include <linux/of.h>
+#include <linux/reset.h>
 
 struct nop_usb_xceiv {
 	struct usb_phy phy;
 	struct device *dev;
 	struct clk *clk;
 	struct regulator *vcc;
-	struct regulator *reset;
+	struct regulator *reset_reg; /* only used for non-DT boot */
+	struct reset_control *reset;
 };
 
 static struct platform_device *pd;
@@ -82,9 +84,14 @@ static int nop_init(struct usb_phy *phy)
 	if (!IS_ERR(nop->clk))
 		clk_enable(nop->clk);
 
+	/* De-assert RESET */
+	if (!IS_ERR(nop->reset_reg)) {
+		if (regulator_enable(nop->reset_reg))
+			dev_err(phy->dev, "Failed to de-assert reset\n");
+	}
+
 	if (!IS_ERR(nop->reset)) {
-		/* De-assert RESET */
-		if (regulator_enable(nop->reset))
+		if (reset_control_deassert(nop->reset))
 			dev_err(phy->dev, "Failed to de-assert reset\n");
 	}
 
@@ -95,9 +102,14 @@ static void nop_shutdown(struct usb_phy *phy)
 {
 	struct nop_usb_xceiv *nop = dev_get_drvdata(phy->dev);
 
+	/* Assert RESET */
+	if (!IS_ERR(nop->reset_reg)) {
+		if (regulator_disable(nop->reset_reg))
+			dev_err(phy->dev, "Failed to assert reset\n");
+	}
+
 	if (!IS_ERR(nop->reset)) {
-		/* Assert RESET */
-		if (regulator_disable(nop->reset))
+		if (reset_control_assert(nop->reset))
 			dev_err(phy->dev, "Failed to assert reset\n");
 	}
 
@@ -166,7 +178,7 @@ static int nop_usb_xceiv_probe(struct platform_device *pdev)
 			clk_rate = 0;
 
 		needs_vcc = of_property_read_bool(node, "vcc-supply");
-		needs_reset = of_property_read_bool(node, "reset-supply");
+		needs_reset = of_property_read_bool(node, "resets");
 
 	} else if (pdata) {
 		type = pdata->type;
@@ -205,12 +217,26 @@ static int nop_usb_xceiv_probe(struct platform_device *pdev)
 			return -EPROBE_DEFER;
 	}
 
-	nop->reset = devm_regulator_get(&pdev->dev, "reset");
-	if (IS_ERR(nop->reset)) {
-		dev_dbg(&pdev->dev, "Error getting reset regulator: %ld\n",
+	nop->reset_reg = ERR_PTR(-EINVAL);
+	nop->reset = ERR_PTR(-EINVAL);
+
+	if (dev->of_node) {
+		nop->reset = devm_reset_control_get(dev, "reset");
+		if (IS_ERR(nop->reset)) {
+			dev_dbg(dev, "Couldn't get reset controller: %ld\n",
 					PTR_ERR(nop->reset));
-		if (needs_reset)
-			return -EPROBE_DEFER;
+			if (needs_reset && PTR_ERR(nop->reset) == -ENODEV)
+				return -EPROBE_DEFER;
+		}
+
+	} else {
+		nop->reset_reg = devm_regulator_get(&pdev->dev, "reset");
+		if (IS_ERR(nop->reset_reg)) {
+			dev_dbg(&pdev->dev, "Error getting reset regulator: %ld\n",
+					PTR_ERR(nop->reset_reg));
+			if (needs_reset)
+				return -EPROBE_DEFER;
+		}
 	}
 
 	nop->dev		= &pdev->dev;
-- 
1.7.4.1



From rogerq at ti.com  Thu Jul 18 04:53:06 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 18 Jul 2013 11:53:06 +0300
Subject: [PATCH 2/6] ARM: dts: omap3-beagle: Use reset-gpio driver for
 hsusb2_reset
In-Reply-To: <1374137590-17865-1-git-send-email-rogerq@ti.com>
References: <1374137590-17865-1-git-send-email-rogerq@ti.com>
Message-ID: <1374137590-17865-3-git-send-email-rogerq@ti.com>

We no longer need to model a RESET line as a regulator since
we have the reset-gpio driver available.

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/boot/dts/omap3-beagle.dts |   17 ++++++++---------
 1 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..01fbad6 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -45,14 +45,12 @@
 	};
 
 	/* HS USB Port 2 RESET */
-	hsusb2_reset: hsusb2_reset_reg {
-		compatible = "regulator-fixed";
-		regulator-name = "hsusb2_reset";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-		gpio = <&gpio5 19 0>;	/* gpio_147 */
-		startup-delay-us = <70000>;
-		enable-active-high;
+	hsusb2_reset: hsusb2_reset {
+		compatible = "gpio-reset";
+		reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>; /* gpio_147 */
+		reset-delay-us = <70000>;
+		initially-in-reset;
+		#reset-cells = <0>;
 	};
 
 	/* HS USB Port 2 Power */
@@ -68,7 +66,8 @@
 	/* HS USB Host PHY on PORT 2 */
 	hsusb2_phy: hsusb2_phy {
 		compatible = "usb-nop-xceiv";
-		reset-supply = <&hsusb2_reset>;
+		resets = <&hsusb2_reset>;
+		reset-names = "reset";
 		vcc-supply = <&hsusb2_power>;
 	};
 
-- 
1.7.4.1



From rogerq at ti.com  Thu Jul 18 04:53:08 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 18 Jul 2013 11:53:08 +0300
Subject: [PATCH 4/6] ARM: dts: omap5-uevm: Use reset-gpio driver for
 hsusb2_reset
In-Reply-To: <1374137590-17865-1-git-send-email-rogerq@ti.com>
References: <1374137590-17865-1-git-send-email-rogerq@ti.com>
Message-ID: <1374137590-17865-5-git-send-email-rogerq@ti.com>

We no longer need to model a RESET line as a regulator since
we have the reset-gpio driver available.

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/boot/dts/omap5-uevm.dts |   17 ++++++++---------
 1 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..08650f9 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -28,20 +28,19 @@
 	};
 
 	/* HS USB Port 2 RESET */
-	hsusb2_reset: hsusb2_reset_reg {
-		compatible = "regulator-fixed";
-		regulator-name = "hsusb2_reset";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-		gpio = <&gpio3 16 GPIO_ACTIVE_HIGH>; /* gpio3_80 HUB_NRESET */
-		startup-delay-us = <70000>;
-		enable-active-high;
+	hsusb2_reset: hsusb2_reset {
+		compatible = "gpio-reset";
+		reset-gpios = <&gpio2 30 GPIO_ACTIVE_LOW>; /* gpio3_80 HUB_NRESET */
+		reset-delay-us = <70000>;
+		initially-in-reset;
+		#reset-cells = <0>;
 	};
 
 	/* HS USB Host PHY on PORT 2 */
 	hsusb2_phy: hsusb2_phy {
 		compatible = "usb-nop-xceiv";
-		reset-supply = <&hsusb2_reset>;
+		resets = <&hsusb2_reset>;
+		reset_names = "reset";
 	/**
 	  * FIXME
 	  * Put the right clock phandle here when available
-- 
1.7.4.1



From rogerq at ti.com  Thu Jul 18 04:53:07 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 18 Jul 2013 11:53:07 +0300
Subject: [PATCH 3/6] ARM: dts: omap4-panda: Use reset-gpio driver for
 hsusb1_reset
In-Reply-To: <1374137590-17865-1-git-send-email-rogerq@ti.com>
References: <1374137590-17865-1-git-send-email-rogerq@ti.com>
Message-ID: <1374137590-17865-4-git-send-email-rogerq@ti.com>

We no longer need to model a RESET line as a regulator since
we have the reset-gpio driver available.

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/boot/dts/omap4-panda-common.dtsi |   22 ++++++++--------------
 1 files changed, 8 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..e9b0a91 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -60,20 +60,13 @@
 			"AFMR", "Line In";
 	};
 
-	/*
-	 * Temp hack: Need to be replaced with the proper gpio-controlled
-	 * reset driver as soon it will be merged.
-	 * http://thread.gmane.org/gmane.linux.drivers.devicetree/36830
-	 */
 	/* HS USB Port 1 RESET */
-	hsusb1_reset: hsusb1_reset_reg {
-		compatible = "regulator-fixed";
-		regulator-name = "hsusb1_reset";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-		gpio = <&gpio2 30 0>;	/* gpio_62 */
-		startup-delay-us = <70000>;
-		enable-active-high;
+	hsusb1_reset: hsusb1_reset {
+		compatible = "gpio-reset";
+		reset-gpios = <&gpio2 30 GPIO_ACTIVE_LOW>; /* gpio_62 */
+		reset-delay-us = <70000>;
+		initially-in-reset;
+		#reset-cells = <0>;
 	};
 
 	/* HS USB Port 1 Power */
@@ -97,7 +90,8 @@
 	/* HS USB Host PHY on PORT 1 */
 	hsusb1_phy: hsusb1_phy {
 		compatible = "usb-nop-xceiv";
-		reset-supply = <&hsusb1_reset>;
+		resets = <&hsusb1_reset>;
+		reset-names = "reset";
 		vcc-supply = <&hsusb1_power>;
 	/**
 	 * FIXME:
-- 
1.7.4.1



From rogerq at ti.com  Thu Jul 18 04:53:09 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 18 Jul 2013 11:53:09 +0300
Subject: [PATCH 5/6] ARM: dts: omap3-beagle-xm: Add USB Host support
In-Reply-To: <1374137590-17865-1-git-send-email-rogerq@ti.com>
References: <1374137590-17865-1-git-send-email-rogerq@ti.com>
Message-ID: <1374137590-17865-6-git-send-email-rogerq@ti.com>

Provide RESET controller and Power regulator for the USB PHY,
the USB Host port mode and the PHY device. Provide
pin multiplexer information for USB host pins.

We also relocate omap3_pmx_core pin definations so that they
are close to omap3_pmx_wkup pin definations.

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/boot/dts/omap3-beagle-xm.dts |   75 +++++++++++++++++++++++++++++----
 1 files changed, 66 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..2273c24 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -69,6 +69,33 @@
 		};
 
 	};
+
+	/* HS USB Port 2 RESET */
+	hsusb2_reset: hsusb2_reset {
+		compatible = "gpio-reset";
+		reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>; /* gpio_147 */
+		reset-delay-us = <70000>;
+		initially-in-reset;
+		#reset-cells = <0>;
+	};
+
+	/* HS USB Port 2 Power */
+	hsusb2_power: hsusb2_power_reg {
+		compatible = "regulator-fixed";
+		regulator-name = "hsusb2_vbus";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&twl_gpio 18 0>;	/* GPIO LEDA */
+		startup-delay-us = <70000>;
+	};
+
+	/* HS USB Host PHY on PORT 2 */
+	hsusb2_phy: hsusb2_phy {
+		compatible = "usb-nop-xceiv";
+		resets = <&hsusb2_reset>;
+		reset-names = "reset";
+		vcc-supply = <&hsusb2_power>;
+	};
 };
 
 &omap3_pmx_wkup {
@@ -79,6 +106,37 @@
 	};
 };
 
+&omap3_pmx_core {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+			&hsusbb2_pins
+	>;
+
+	uart3_pins: pinmux_uart3_pins {
+		pinctrl-single,pins = <
+			0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */
+			0x170 (PIN_OUTPUT | MUX_MODE0) /* uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
+		>;
+	};
+
+	hsusbb2_pins: pinmux_hsusbb2_pins {
+		pinctrl-single,pins = <
+			0x5c0 (PIN_OUTPUT | MUX_MODE3)		/* etk_d10.hsusb2_clk */
+			0x5c2 (PIN_OUTPUT | MUX_MODE3)		/* etk_d11.hsusb2_stp */
+			0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* etk_d12.hsusb2_dir */
+			0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* etk_d13.hsusb2_nxt */
+			0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* etk_d14.hsusb2_data0 */
+			0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* etk_d15.hsusb2_data1 */
+			0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi1_cs3.hsusb2_data2 */
+			0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_clk.hsusb2_data7 */
+			0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_simo.hsusb2_data4 */
+			0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_somi.hsusb2_data5 */
+			0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_cs0.hsusb2_data6 */
+			0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_cs1.hsusb2_data3 */
+		>;
+	};
+};
+
 &i2c1 {
 	clock-frequency = <2600000>;
 
@@ -148,15 +206,6 @@
 	power = <50>;
 };
 
-&omap3_pmx_core {
-	uart3_pins: pinmux_uart3_pins {
-		pinctrl-single,pins = <
-			0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */
-			0x170 (PIN_OUTPUT | MUX_MODE0) /* uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
-		>;
-	};
-};
-
 &uart3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart3_pins>;
@@ -166,3 +215,11 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&gpio1_pins>;
 };
+
+&usbhshost {
+	port2-mode = "ehci-phy";
+};
+
+&usbhsehci {
+	phys = <0 &hsusb2_phy>;
+};
-- 
1.7.4.1



From rogerq at ti.com  Thu Jul 18 04:53:10 2013
From: rogerq at ti.com (Roger Quadros)
Date: Thu, 18 Jul 2013 11:53:10 +0300
Subject: [PATCH 6/6] ARM: dts: omap3-beagle: Make USB host pin naming
 consistent
In-Reply-To: <1374137590-17865-1-git-send-email-rogerq@ti.com>
References: <1374137590-17865-1-git-send-email-rogerq@ti.com>
Message-ID: <1374137590-17865-7-git-send-email-rogerq@ti.com>

Use a common naming scheme "mode0name.modename flags" for the
USB host pins to be consistent.

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/boot/dts/omap3-beagle.dts |   24 ++++++++++++------------
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index 01fbad6..27aed65 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -100,18 +100,18 @@
 
 	hsusbb2_pins: pinmux_hsusbb2_pins {
 		pinctrl-single,pins = <
-			0x5c0 (PIN_OUTPUT | MUX_MODE3)		/* usbb2_ulpitll_clk.usbb1_ulpiphy_clk */
-			0x5c2 (PIN_OUTPUT | MUX_MODE3)		/* usbb2_ulpitll_clk.usbb1_ulpiphy_stp */
-			0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* usbb2_ulpitll_clk.usbb1_ulpiphy_dir */
-			0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* usbb2_ulpitll_clk.usbb1_ulpiphy_nxt */
-			0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* usbb2_ulpitll_clk.usbb1_ulpiphy_dat0 */
-			0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* usbb2_ulpitll_clk.usbb1_ulpiphy_dat1 */
-			0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* usbb2_ulpitll_clk.usbb1_ulpiphy_dat2 */
-			0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* usbb2_ulpitll_clk.usbb1_ulpiphy_dat3 */
-			0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* usbb2_ulpitll_clk.usbb1_ulpiphy_dat4 */
-			0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* usbb2_ulpitll_clk.usbb1_ulpiphy_dat5 */
-			0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* usbb2_ulpitll_clk.usbb1_ulpiphy_dat6 */
-			0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* usbb2_ulpitll_clk.usbb1_ulpiphy_dat7 */
+			0x5c0 (PIN_OUTPUT | MUX_MODE3)		/* etk_d10.hsusb2_clk */
+			0x5c2 (PIN_OUTPUT | MUX_MODE3)		/* etk_d11.hsusb2_stp */
+			0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* etk_d12.hsusb2_dir */
+			0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* etk_d13.hsusb2_nxt */
+			0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* etk_d14.hsusb2_data0 */
+			0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* etk_d15.hsusb2_data1 */
+			0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi1_cs3.hsusb2_data2 */
+			0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_clk.hsusb2_data7 */
+			0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_simo.hsusb2_data4 */
+			0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_somi.hsusb2_data5 */
+			0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_cs0.hsusb2_data6 */
+			0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3)	/* mcspi2_cs1.hsusb2_data3 */
 		>;
 	};
 
-- 
1.7.4.1



From grygorii.strashko at ti.com  Thu Jul 18 04:54:16 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Thu, 18 Jul 2013 11:54:16 +0300
Subject: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for
 uart3/4
In-Reply-To: <20130718080953.GR7656@atomide.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
 <1374061312-25469-4-git-send-email-grygorii.strashko@ti.com>
 <20130717153248.GI7656@atomide.com> <51E6C939.40208@ti.com>
 <20130718080953.GR7656@atomide.com>
Message-ID: <51E7AD38.6010108@ti.com>

On 07/18/2013 11:09 AM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko at ti.com> [130717 09:48]:
>> Hi,
>>
>> On 07/17/2013 06:32 PM, Tony Lindgren wrote:
>>> * Grygorii Strashko <grygorii.strashko at ti.com> [130717 04:49]:
>>>> Add dynamic "active"/"idle" pin states for uart3/4 which will be applied
>>>> when uart3/4 state is switched from active to idle and back by Runtime
>>>> PM or during system suspend.
>>>
>>> This is good for testing code, but should not be merged because
>>> omap4 has the iopad wake-ups available for uarts. So those can
>>> be always enabled.
>>
>> In this case, 2 IRQ will be received per each UART RX event - one from
>> PRCM and from UART - and that's not good from PM perspective (It will
>> affect on CPUIdle and CPUFreq at least).
>
> Oh I see, that's because I accidentally left the debug code enabled
> to make it easier to test the wake-up events without having to
> have working off-idle. The wake flags can be kept on always for
> sure.
>
> The patch below should sort out the issue of getting wake-up interrupts
> during runtime as long as you don't have DEBUG defined.
>
> Regards,
>
> Tony
>
> --- a/drivers/pinctrl/pinctrl-single-omap.c
> +++ b/drivers/pinctrl/pinctrl-single-omap.c
> @@ -140,9 +140,17 @@ static irqreturn_t pcs_omap_handle_irq(int irq, void *data)
>   		if ((val & OMAP_WAKEUP_EVENT_MASK) == OMAP_WAKEUP_EVENT_MASK)
>   			generic_handle_irq(wakeirq);
>   	}
> -
> +#ifdef DEBUG

Don't think it's debug code - IO chain need to be rearmed after each
PRCM IO IRQ - otherwise IO wakeup events may be lost (at least on
OMAP4, OMAP5 requires more complex handling(( ).


> +	/*
> +	 * This enables wake-up interrupts during runtime also
> +	 * causing duplicate interrupts. But it also makes debugging
> +	 * the wake-up events easy as deeper idle states often are
> +	 * not working for new devices while the drivers are being
> +	 * developed.
> +	 */
>   	if (pcso->reconfigure_io_chain)
>   		pcso->reconfigure_io_chain();
> +#endif
>
>   	return IRQ_HANDLED;
>   }
>

I didn't pick up your padconf patches yet -seems i need to be in sync :)

Below the diff I used to verify IO wake up (It follows old IO daisy
chain hanlding models in hwmod before DT):


--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -574,7 +574,7 @@ odbs_exit:

         return ERR_PTR(ret);
  }
-
+#include "prm44xx.h"
  #ifdef CONFIG_PM_RUNTIME
  static int _od_runtime_suspend(struct device *dev)
  {
@@ -586,6 +586,7 @@ static int _od_runtime_suspend(struct device *dev)
         if (!ret) {
                 omap_device_idle(pdev);
                 pinctrl_pm_select_idle_state(dev);
+               omap44xx_prm_reconfigure_io_chain();
         }

         return ret;
@@ -596,6 +597,7 @@ static int _od_runtime_resume(struct device *dev)
         struct platform_device *pdev = to_platform_device(dev);

         pinctrl_pm_select_active_state(dev);
+       omap44xx_prm_reconfigure_io_chain();

         omap_device_enable(pdev);

diff --git a/arch/arm/mach-omap2/prm_common.c 
b/arch/arm/mach-omap2/prm_common.c
index 228b850..5db073a 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -79,7 +79,7 @@ static void omap_prcm_events_filter_priority(unsigned 
long *events,
                 events[i] ^= priority_events[i];
         }
  }
-
+#include "prm44xx.h"
  /*
   * PRCM Interrupt Handler
   *
@@ -144,6 +144,7 @@ static void omap_prcm_irq_handler(unsigned int irq, 
struct irq_desc *desc)
         chip->irq_unmask(&desc->irq_data);

         prcm_irq_setup->ocp_barrier(); /* avoid spurious IRQs */
+       omap44xx_prm_reconfigure_io_chain();
  }




From mpfj-list at newflow.co.uk  Thu Jul 18 04:55:08 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Thu, 18 Jul 2013 09:55:08 +0100
Subject: ARM: AM335x: Kernel oops when using EDMA and MMC
In-Reply-To: <51E6C88B.8090608@ti.com>
References: <51E6BE84.6080905@newflow.co.uk> <51E6C88B.8090608@ti.com>
Message-ID: <51E7AD6C.2000408@newflow.co.uk>

On 17/07/13 17:38, Joel Fernandes wrote:
> On 07/17/2013 10:55 AM, Mark Jackson wrote:
>> I'm trying to get the MMC port working on our custom AM3352 CPU board.
>>
>> I have added MMC entries to out dts file (similar to [1]), and I've
>> enabled CONFIG_TI_EDMA.
>>
>> Our board boots fine without an SD card inserted ...
>>
>> [    0.000000] Booting Linux on physical CPU 0x0
>> [    0.000000] Linux version 3.11.0-rc1-00025-g95b9b72 (mpfj at mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #309 Wed Jul 17 16:37:28 BST 2013
>> ...
>> [    2.789028] VFS: Mounted root (ubifs filesystem) on device 0:12.
>> [    2.797268] devtmpfs: mounted
>> [    2.801032] Freeing unused kernel memory: 200K (c0551000 - c0583000)
>> ...
>> Welcome to Buildroot
>> nanobone login:
>>
>> But when I boot with a card already inserted, I get the following oops ...
>>
>> ...
>> [    1.827343] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
>> [    1.835868] pgd = c0004000
>> [    1.838774] [0000000c] *pgd=00000000
>> [    1.842556] Internal error: Oops: 5 [#1] ARM
>> [    1.847063] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.11.0-rc1-00025-g95b9b72 #309
>> [    1.855511] Workqueue: kmmcd mmc_rescan
>> [    1.859556] task: cf06a080 ti: cf072000 task.ti: cf072000
>> [    1.865257] PC is at omap_hsmmc_start_command+0x74/0xf4
>> [    1.870761] LR is at omap_hsmmc_request+0xec/0x4dc
>> [    1.875806] pc : [<c0305b70>]    lr : [<c0306c64>]    psr: 60000113
>> [    1.875806] sp : cf073ca0  ip : 00000000  fp : 00000008
>> [    1.887885] r10: cf073de8  r9 : 00000001  r8 : cf11d918
>> [    1.893382] r7 : 00000003  r6 : cf33cc80  r5 : 00000001  r4 : 00000033
>> [    1.900250] r3 : 00020000  r2 : cf073db8  r1 : cf073d84  r0 : cf33cc80
>> [    1.907122] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
>> [    1.914813] Control: 10c5387d  Table: 80004019  DAC: 00000015
>> [    1.920859] Process kworker/u2:0 (pid: 6, stack limit = 0xcf072238)
>> [    1.927454] Stack: (0xcf073ca0 to 0xcf074000)
>> [    1.932048] 3ca0: cf33c800 cf073d40 00000003 00000000 c0076a8c cf073d40 48060220 48060220
>> [    1.940659] 3cc0: 00000004 00000004 00000002 00000002 cf073ec8 c0421a9c c051835c cf073d40
>> [    1.949271] 3ce0: cf33c800 00000001 00000008 00000008 00000002 cf073db8 cf073ec8 c02f0f28
>> [    1.957882] 3d00: 00000200 00000064 00000000 cf073db8 cf073ec8 cf073d40 cf073d50 00000000
>> [    1.966493] 3d20: cf33c800 c02f18a4 cf369800 cf369a80 00000000 cf360880 00000008 c02f9964
>> [    1.975104] 3d40: 00000000 cf073d84 cf073db8 00000000 00000001 00000001 dead4ead ffffffff
>> [    1.983717] 3d60: ffffffff c0af722c c06aa3e4 00000000 c04ddadc cf073d74 cf073d74 c02f0dc4
>> [    1.992327] 3d80: 00000000 00000033 00000000 00000000 00000000 00000000 00000000 000000b5
>> [    2.000938] 3da0: 00000000 00000000 00000000 00000000 cf073db8 cf073d40 05f5e100 00000000
>> [    2.009548] 3dc0: 00000008 00000001 00000000 00000200 00000000 00000000 cf073d40 00000001
>> [    2.018159] 3de0: cf073de8 00000000 c0cf1c02 00000880 00000008 8f360880 00000000 cf369800
>> [    2.026771] 3e00: cf33c800 00000000 cf369800 cf073e4c cf072000 c02f8740 00000000 00000015
>> [    2.035382] 3e20: 00000003 cf33c800 00000000 00000000 cf369800 cf073e4c cf072000 c02f8b20
>> [    2.043994] 3e40: 00000002 c02f25cc 00000002 02544d53 41303447 1026c914 2600bbbd c0ff8000
>> [    2.052605] 3e60: c0455884 cf33c800 00000000 c0455884 c0455890 00000000 cf072000 c02f92bc
>> [    2.061217] 3e80: c0455890 00ff8000 00000002 cf33cb14 cf33c800 c02f3a28 cf041ac0 cf33cb14
>> [    2.069829] 3ea0: cf050c00 cf051c00 00000000 c00507ec 00000002 00000000 c0050778 c0050f10
>> [    2.078441] 3ec0: 00000000 00000000 c0af7268 c06aa1c4 00000000 c0518cd0 cf06a080 cf041ac0
>> [    2.087054] 3ee0: cf050c00 cf072000 cf050c30 cf041ad8 00000089 c05d7b5c cf050c00 c0050e4c
>> [    2.095665] 3f00: 00000000 cf072000 60000113 cf04dda8 00000000 cf041ac0 c0050d08 00000000
>> [    2.104276] 3f20: 00000000 00000000 00000000 c0056c94 c0429a18 00000000 00000001 cf041ac0
>> [    2.112888] 3f40: 00000000 00000001 dead4ead ffffffff ffffffff c05ec0a0 00000000 00000000
>> [    2.121499] 3f60: c04ddadc cf073f64 cf073f64 00000000 00000001 dead4ead ffffffff ffffffff
>> [    2.130112] 3f80: c05ec0a0 00000000 00000000 c04ddadc cf073f90 cf073f90 cf073fac cf04dda8
>> [    2.138724] 3fa0: c0056bf0 00000000 00000000 c0013588 00000000 00000000 00000000 00000000
>> [    2.147334] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> [    2.155946] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 57e0c5db 5ffb7d3c
>> [    2.164565] [<c0305b70>] (omap_hsmmc_start_command+0x74/0xf4) from [<00000003>] (0x3)
>> [    2.172814] Code: 13a03801 0a00001b e590c008 e5914000 (e59cc00c)
>> [    2.179314] ---[ end trace 6ec9899a56aef6aa ]---
>>
>> I have also noticed that when the kernel boots okay (without a card inserted), if
>> I then insert a card, nothing happens (even with CONFIG_MMC_DEBUG=y) ... including
>> no kernel oops.
>>
>> Can anyone shed light on what's wrong ?
> 
> I see this issue too on -rc1. The mmc host pointer is mangled but this could be
> due to something totally unrelated.
> 
> Can you first please try rebasing on 3.10 instead of 3.11-rc1?

Well, I've rebased the code to v3.10 and I get no oops, but (with some debug info added)
I can see that omap_hsmmc_start_command() is never called.

I'm not sure the EDMA stuff is being compiled in ... was this added post v3.10 ?

Cheers
Mark J.


From kishon at ti.com  Thu Jul 18 04:59:52 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 14:29:52 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130718072004.GA16720@kroah.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-2-git-send-email-kishon@ti.com>
 <20130718072004.GA16720@kroah.com>
Message-ID: <51E7AE88.3050007@ti.com>

Hi,

On Thursday 18 July 2013 12:50 PM, Greg KH wrote:
> On Thu, Jul 18, 2013 at 12:16:10PM +0530, Kishon Vijay Abraham I wrote:
>> +struct phy_provider *__of_phy_provider_register(struct device *dev,
>> +	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
>> +	struct of_phandle_args *args));
>> +struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
>> +	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
>> +	struct of_phandle_args *args))
>> +
>> +__of_phy_provider_register and __devm_of_phy_provider_register can be used to
>> +register the phy_provider and it takes device, owner and of_xlate as
>> +arguments. For the dt boot case, all PHY providers should use one of the above
>> +2 APIs to register the PHY provider.
> 
> Why do you have __ for the prefix of a public function?  Is that really
> the way that OF handles this type of thing?

I have a macro of_phy_provider_register/devm_of_phy_provider_register that
calls these functions and should be used by the PHY drivers. Probably I should
make a mention of it in the Documentation.
> 
>> --- /dev/null
>> +++ b/drivers/phy/Kconfig
>> @@ -0,0 +1,13 @@
>> +#
>> +# PHY
>> +#
>> +
>> +menuconfig GENERIC_PHY
>> +	tristate "PHY Subsystem"
>> +	help
>> +	  Generic PHY support.
>> +
>> +	  This framework is designed to provide a generic interface for PHY
>> +	  devices present in the kernel. This layer will have the generic
>> +	  API by which phy drivers can create PHY using the phy framework and
>> +	  phy users can obtain reference to the PHY.
> 
> Again, please reverse this.  The drivers that use it should select it,
> not depend on it, which will then enable this option.  I will never know
> if I need to enable it, and based on your follow-on patches, if I don't,
> drivers that were working just fine, now disappeared from my build,
> which isn't nice, and a pain to notice and fix up.

ok.
> 
>> +/**
>> + * phy_create() - create a new phy
>> + * @dev: device that is creating the new phy
>> + * @id: id of the phy
>> + * @ops: function pointers for performing phy operations
>> + * @label: label given to the phy
>> + *
>> + * Called to create a phy using phy framework.
>> + */
>> +struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
>> +	const char *label)
>> +{
>> +	int ret;
>> +	struct phy *phy;
>> +
>> +	if (!dev) {
>> +		dev_WARN(dev, "no device provided for PHY\n");
>> +		ret = -EINVAL;
>> +		goto err0;
>> +	}
>> +
>> +	phy = kzalloc(sizeof(*phy), GFP_KERNEL);
>> +	if (!phy) {
>> +		ret = -ENOMEM;
>> +		goto err0;
>> +	}
>> +
>> +	device_initialize(&phy->dev);
>> +	mutex_init(&phy->mutex);
>> +
>> +	phy->dev.class = phy_class;
>> +	phy->dev.parent = dev;
>> +	phy->dev.of_node = dev->of_node;
>> +	phy->id = id;
>> +	phy->ops = ops;
>> +	phy->label = kstrdup(label, GFP_KERNEL);
>> +
>> +	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
> 
> Your naming is odd, no "phy" anywhere in it?  You rely on the sender to
> never send a duplicate name.id pair?  Why not create your own ids based
> on the number of phys in the system, like almost all other classes and
> subsystems do?

hmm.. some PHY drivers use the id they provide to perform some of their
internal operation as in [1] (This is used only if a single PHY provider
implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO
to give the PHY drivers an option to use auto id.

[1] ->
http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> 
>> +static inline int phy_pm_runtime_get(struct phy *phy)
>> +{
>> +	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> +		return -EINVAL;
> 
> Why would phy ever not be valid and a error pointer?  And why dump the
> stack if that happens, that seems really extreme.

hmm.. there might be cases where the same controller in one soc needs PHY
control and in some other soc does not need PHY control. In such cases, we
might get error pointer here.
I'll change WARN to dev_err.
> 
>> +
>> +	if (!pm_runtime_enabled(&phy->dev))
>> +		return -ENOTSUPP;
>> +
>> +	return pm_runtime_get(&phy->dev);
>> +}
> 
> This, and the other inline functions in this .h file seem huge, why are
> they inline and not in the .c file?  There's no speed issues, and it
> should save space overall in the .c file.  Please move them.

ok
> 
> 
>> +static inline int phy_init(struct phy *phy)
>> +{
>> +	int ret;
>> +
>> +	ret = phy_pm_runtime_get_sync(phy);
>> +	if (ret < 0 && ret != -ENOTSUPP)
>> +		return ret;
>> +
>> +	mutex_lock(&phy->mutex);
>> +	if (phy->init_count++ == 0 && phy->ops->init) {
>> +		ret = phy->ops->init(phy);
>> +		if (ret < 0) {
>> +			dev_err(&phy->dev, "phy init failed --> %d\n", ret);
>> +			goto out;
>> +		}
>> +	}
>> +
>> +out:
>> +	mutex_unlock(&phy->mutex);
>> +	phy_pm_runtime_put(phy);
>> +	return ret;
>> +}
>> +
>> +static inline int phy_exit(struct phy *phy)
>> +{
>> +	int ret;
>> +
>> +	ret = phy_pm_runtime_get_sync(phy);
>> +	if (ret < 0 && ret != -ENOTSUPP)
>> +		return ret;
>> +
>> +	mutex_lock(&phy->mutex);
>> +	if (--phy->init_count == 0 && phy->ops->exit) {
>> +		ret = phy->ops->exit(phy);
>> +		if (ret < 0) {
>> +			dev_err(&phy->dev, "phy exit failed --> %d\n", ret);
>> +			goto out;
>> +		}
>> +	}
>> +
>> +out:
>> +	mutex_unlock(&phy->mutex);
>> +	phy_pm_runtime_put(phy);
>> +	return ret;
>> +}
>> +
>> +static inline int phy_power_on(struct phy *phy)
>> +{
>> +	int ret = -ENOTSUPP;
>> +
>> +	ret = phy_pm_runtime_get_sync(phy);
>> +	if (ret < 0 && ret != -ENOTSUPP)
>> +		return ret;
>> +
>> +	mutex_lock(&phy->mutex);
>> +	if (phy->power_count++ == 0 && phy->ops->power_on) {
>> +		ret = phy->ops->power_on(phy);
>> +		if (ret < 0) {
>> +			dev_err(&phy->dev, "phy poweron failed --> %d\n", ret);
>> +			goto out;
>> +		}
>> +	}
>> +
>> +out:
>> +	mutex_unlock(&phy->mutex);
>> +
>> +	return ret;
>> +}
>> +
>> +static inline int phy_power_off(struct phy *phy)
>> +{
>> +	int ret = -ENOTSUPP;
>> +
>> +	mutex_lock(&phy->mutex);
>> +	if (--phy->power_count == 0 && phy->ops->power_off) {
>> +		ret =  phy->ops->power_off(phy);
>> +		if (ret < 0) {
>> +			dev_err(&phy->dev, "phy poweroff failed --> %d\n", ret);
>> +			goto out;
>> +		}
>> +	}
>> +
>> +out:
>> +	mutex_unlock(&phy->mutex);
>> +	phy_pm_runtime_put(phy);
>> +
>> +	return ret;
>> +}
> 
> Look at those 3 functions, they are all "real" and not an inline
> function at all, please move them.

Alright.

Thanks
Kishon


From kishon at ti.com  Thu Jul 18 05:00:58 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 14:30:58 +0530
Subject: [PATCH 02/15] usb: phy: omap-usb2: use the new generic PHY
 framework
In-Reply-To: <20130718072149.GB16720@kroah.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-3-git-send-email-kishon@ti.com>
 <20130718072149.GB16720@kroah.com>
Message-ID: <51E7AECA.1000204@ti.com>

On Thursday 18 July 2013 12:51 PM, Greg KH wrote:
> On Thu, Jul 18, 2013 at 12:16:11PM +0530, Kishon Vijay Abraham I wrote:
>> Used the generic PHY framework API to create the PHY. Now the power off and
>> power on are done in omap_usb_power_off and omap_usb_power_on respectively.
>>
>> However using the old USB PHY library cannot be completely removed
>> because OTG is intertwined with PHY and moving to the new framework
>> will break OTG. Once we have a separate OTG state machine, we
>> can get rid of the USB PHY library.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
>> Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
>> Acked-by: Felipe Balbi <balbi at ti.com>
>> ---
>>  drivers/usb/phy/Kconfig         |    1 +
>>  drivers/usb/phy/phy-omap-usb2.c |   45 +++++++++++++++++++++++++++++++++++----
>>  2 files changed, 42 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
>> index 3622fff..cc55993 100644
>> --- a/drivers/usb/phy/Kconfig
>> +++ b/drivers/usb/phy/Kconfig
>> @@ -75,6 +75,7 @@ config OMAP_CONTROL_USB
>>  config OMAP_USB2
>>  	tristate "OMAP USB2 PHY Driver"
>>  	depends on ARCH_OMAP2PLUS
>> +	depends on GENERIC_PHY
>>  	select OMAP_CONTROL_USB
>>  	help
>>  	  Enable this to support the transceiver that is part of SOC. This
>> diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
>> index 844ab68..751b30f 100644
>> --- a/drivers/usb/phy/phy-omap-usb2.c
>> +++ b/drivers/usb/phy/phy-omap-usb2.c
>> @@ -28,6 +28,7 @@
>>  #include <linux/pm_runtime.h>
>>  #include <linux/delay.h>
>>  #include <linux/usb/omap_control_usb.h>
>> +#include <linux/phy/phy.h>
>>  
>>  /**
>>   * omap_usb2_set_comparator - links the comparator present in the sytem with
>> @@ -119,10 +120,36 @@ static int omap_usb2_suspend(struct usb_phy *x, int suspend)
>>  	return 0;
>>  }
>>  
>> +static int omap_usb_power_off(struct phy *x)
>> +{
>> +	struct omap_usb *phy = phy_get_drvdata(x);
>> +
>> +	omap_control_usb_phy_power(phy->control_dev, 0);
>> +
>> +	return 0;
>> +}
>> +
>> +static int omap_usb_power_on(struct phy *x)
>> +{
>> +	struct omap_usb *phy = phy_get_drvdata(x);
>> +
>> +	omap_control_usb_phy_power(phy->control_dev, 1);
>> +
>> +	return 0;
>> +}
>> +
>> +static struct phy_ops ops = {
>> +	.power_on	= omap_usb_power_on,
>> +	.power_off	= omap_usb_power_off,
>> +	.owner		= THIS_MODULE,
>> +};
>> +
>>  static int omap_usb2_probe(struct platform_device *pdev)
>>  {
>>  	struct omap_usb			*phy;
>> +	struct phy			*generic_phy;
>>  	struct usb_otg			*otg;
>> +	struct phy_provider		*phy_provider;
>>  
>>  	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
>>  	if (!phy) {
>> @@ -144,6 +171,11 @@ static int omap_usb2_probe(struct platform_device *pdev)
>>  	phy->phy.otg		= otg;
>>  	phy->phy.type		= USB_PHY_TYPE_USB2;
>>  
>> +	phy_provider = devm_of_phy_provider_register(phy->dev,
>> +			of_phy_simple_xlate);
>> +	if (IS_ERR(phy_provider))
>> +		return PTR_ERR(phy_provider);
>> +
>>  	phy->control_dev = omap_get_control_dev();
>>  	if (IS_ERR(phy->control_dev)) {
>>  		dev_dbg(&pdev->dev, "Failed to get control device\n");
>> @@ -159,6 +191,15 @@ static int omap_usb2_probe(struct platform_device *pdev)
>>  	otg->start_srp		= omap_usb_start_srp;
>>  	otg->phy		= &phy->phy;
>>  
>> +	platform_set_drvdata(pdev, phy);
>> +	pm_runtime_enable(phy->dev);
>> +
>> +	generic_phy = devm_phy_create(phy->dev, 0, &ops, "omap-usb2");
>> +	if (IS_ERR(generic_phy))
>> +		return PTR_ERR(generic_phy);
> 
> So, if I have two of these controllers in my system, I can't create the
> second phy because the name for it will be identical to the first?
> That's why the phy core should handle the id, and not rely on the
> drivers to set it, as they have no idea how many they have in the
> system.

hmm.. for such cases I'll have something like PLATFORM_DEVID_AUTO.

Thanks
Kishon


From tony at atomide.com  Thu Jul 18 05:04:08 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 02:04:08 -0700
Subject: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for
 uart3/4
In-Reply-To: <51E7AD38.6010108@ti.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
 <1374061312-25469-4-git-send-email-grygorii.strashko@ti.com>
 <20130717153248.GI7656@atomide.com> <51E6C939.40208@ti.com>
 <20130718080953.GR7656@atomide.com> <51E7AD38.6010108@ti.com>
Message-ID: <20130718090408.GU7656@atomide.com>

* Grygorii Strashko <grygorii.strashko at ti.com> [130718 02:01]:
> On 07/18/2013 11:09 AM, Tony Lindgren wrote:
> 
> Don't think it's debug code - IO chain need to be rearmed after each
> PRCM IO IRQ - otherwise IO wakeup events may be lost (at least on
> OMAP4, OMAP5 requires more complex handling(( ).

Nope, only after the mux register changes. I've verified it on
am3730 with off-idle for both serial and wl12xx.
 
> I didn't pick up your padconf patches yet -seems i need to be in sync :)

Well you need those for proper wake-up event support..

> Below the diff I used to verify IO wake up (It follows old IO daisy
> chain hanlding models in hwmod before DT):

..then these changes not needed with the pinctrl-single changes.

Regards,

Tony


From sr at denx.de  Thu Jul 18 05:14:39 2013
From: sr at denx.de (Stefan Roese)
Date: Thu, 18 Jul 2013 11:14:39 +0200
Subject: [PATCH] ARM: omap2: fix musb usage for n8x0
In-Reply-To: <1374000777-5626-1-git-send-email-zonque@gmail.com>
References: <1374000777-5626-1-git-send-email-zonque@gmail.com>
Message-ID: <51E7B1FF.6000301@denx.de>

On 07/16/2013 08:52 PM, Daniel Mack wrote:
> Commit b7e2e75a8c ("usb: gadget: drop unused USB_GADGET_MUSB_HDRC")
> dropped a config symbol that was unused by the musb core, but it turns
> out that board support code had references to it.
> 
> As the core now has a fall-back to host-only mode if support for
> dual-role is not compiled in, so we can just pass MUSB_OTG as
> mode from board files.
> 
> Signed-off-by: Daniel Mack <zonque at gmail.com>
> Reported-and-tested-by: Aaro Koskinen <aaro.koskinen at iki.fi>

I'm testing musb as OTG on beagleboard (old one, not Beagle-xm). And
using the latest kernel.org version with this patch applied I see the
following messages while booting (repeatedly):

[    4.998168] usb usb1: bus auto-suspend, wakeup 1
[    5.003112] musb_bus_suspend 2457: trying to suspend as b_idle while active
[    5.010498] usb usb1: bus suspend fail, err -16
[    5.015289] hub 1-0:1.0: hub_resume
[    5.019073] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
[    5.024963] hub 1-0:1.0: hub_suspend
[    5.028778] usb usb1: bus auto-suspend, wakeup 1
...

This is without a cable connected to the OTG port.

Any ideas what might be missing here?

BTW: I enabled USB support for beagle in the dts this way:

+&usb_otg_hs {
+	interface-type = <0>;
+	usb-phy = <&usb2_phy>;
+	mode = <3>;
+	power = <50>;
+};

Thanks,
Stefan


From ml at communistcode.co.uk  Thu Jul 18 05:16:47 2013
From: ml at communistcode.co.uk (Jack Mitchell)
Date: Thu, 18 Jul 2013 10:16:47 +0100
Subject: [PATCH 0/4] Enable ethernet support for SOCFPGA
In-Reply-To: <1374102623-4154-1-git-send-email-dinguyen@altera.com>
References: <1374102623-4154-1-git-send-email-dinguyen@altera.com>
Message-ID: <51E7B27F.2000304@communistcode.co.uk>

On 18/07/13 00:10, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen at altera.com>
>
> Hello,
>
> These 4 patches are meant to enable ethernet and SD/MMC for the SOCFPGA
> platform.
>
> patch (1/4): Adds select ARM_TWD for the platform
> patch (2/4): Add platform specific initialization for the ethernet controller.
> patch (3/4): Commit 25c83b5c2 added "snps,phy-addr" for getting the PHY addr.
>          Set the ethernet clocks to be emac_0_clk and emac_1_clk so it be gated.
> patch (4/4): Update defconfig to support SD/MMC, ethernet, EXT3 and NFS.
>
> Thanks,
>
> Dinh Nguyen (4):
>    arm: socfpga: Enable ARM_TWD for socfpga
>    arm: socfpga: Add platform initialization for ethernet
>    ARM: socfpga: dts: Fix entries for the ethernet entries.
>    arm: socfpga: Add support for SD/MMC and ethernet to defconfig
>
>   arch/arm/boot/dts/socfpga.dtsi         |    4 +-
>   arch/arm/boot/dts/socfpga_cyclone5.dts |    2 +-
>   arch/arm/configs/socfpga_defconfig     |    8 +++
>   arch/arm/mach-socfpga/Kconfig          |    1 +
>   arch/arm/mach-socfpga/core.h           |    8 +++
>   arch/arm/mach-socfpga/socfpga.c        |   85 +++++++++++++++++++++++++++++++-
>   6 files changed, 104 insertions(+), 4 deletions(-)
>
> CC: Arnd Bergmann <arnd at arndb.de>
> CC: Olof Johansson <olof at lixom.net>
> Cc: Rob Herring <rob.herring at calxeda.com>
> Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Cc: Pavel Machek <pavel at denx.de>
> Cc: Jack Mitchell <jack.mitchell at dbbroadcast.co.uk>
>

Hi Dinh,

What tree is this based against, or what patches are a pre-requisite to 
this series? I applied the patches to linux-arm/master but the compile 
failed.

arch/arm/mach-socfpga/socfpga.c: In function 'ksz9021rlrn_phy_fixup':
arch/arm/mach-socfpga/socfpga.c:85:21: error: 
'MICREL_KSZ9021_EXTREG_CTRL' undeclared (first use in this function)
    phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
                      ^
arch/arm/mach-socfpga/socfpga.c:85:21: note: each undeclared identifier 
is reported only once for each function it appears in
arch/arm/mach-socfpga/socfpga.c:86:4: error: 
'MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW' undeclared (first use in this 
function)
     MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW | 0x8000);
     ^
arch/arm/mach-socfpga/socfpga.c:87:21: error: 
'MICREL_KSZ9021_EXTREG_DATA_WRITE' undeclared (first use in this function)
    phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
                      ^
arch/arm/mach-socfpga/socfpga.c:91:4: error: 
'MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW' undeclared (first use in this 
function)
     MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW | 0x8000);
     ^
arch/arm/mach-socfpga/socfpga.c: In function 'socfpga_cyclone5_init':
arch/arm/mach-socfpga/socfpga.c:193:30: error: 'PHY_ID_KSZ9021RLRN' 
undeclared (first use in this function)
    phy_register_fixup_for_uid(PHY_ID_KSZ9021RLRN,
                               ^
Cheers,
Jack.

-- 

   Jack Mitchell (jack at embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--



From kishon at ti.com  Thu Jul 18 05:18:50 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 18 Jul 2013 14:48:50 +0530
Subject: [PATCH] ARM: omap2: fix musb usage for n8x0
In-Reply-To: <51E7B1FF.6000301@denx.de>
References: <1374000777-5626-1-git-send-email-zonque@gmail.com>
 <51E7B1FF.6000301@denx.de>
Message-ID: <51E7B2FA.7020206@ti.com>

Hi,

On Thursday 18 July 2013 02:44 PM, Stefan Roese wrote:
> On 07/16/2013 08:52 PM, Daniel Mack wrote:
>> Commit b7e2e75a8c ("usb: gadget: drop unused USB_GADGET_MUSB_HDRC")
>> dropped a config symbol that was unused by the musb core, but it turns
>> out that board support code had references to it.
>>
>> As the core now has a fall-back to host-only mode if support for
>> dual-role is not compiled in, so we can just pass MUSB_OTG as
>> mode from board files.
>>
>> Signed-off-by: Daniel Mack <zonque at gmail.com>
>> Reported-and-tested-by: Aaro Koskinen <aaro.koskinen at iki.fi>
> 
> I'm testing musb as OTG on beagleboard (old one, not Beagle-xm). And
> using the latest kernel.org version with this patch applied I see the
> following messages while booting (repeatedly):
> 
> [    4.998168] usb usb1: bus auto-suspend, wakeup 1
> [    5.003112] musb_bus_suspend 2457: trying to suspend as b_idle while active
> [    5.010498] usb usb1: bus suspend fail, err -16
> [    5.015289] hub 1-0:1.0: hub_resume
> [    5.019073] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
> [    5.024963] hub 1-0:1.0: hub_suspend
> [    5.028778] usb usb1: bus auto-suspend, wakeup 1
> ...
> 
> This is without a cable connected to the OTG port.
> 
> Any ideas what might be missing here?

Even I observed these prints when I have dual mode enabled. When kept as gadget
only mode I dint see these prints.
However if you connect a cable, you should still see that enumeration should
succeed.
Not sure why those prints come though :-s

Thanks
Kishon


From linux at arm.linux.org.uk  Thu Jul 18 05:17:35 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Jul 2013 10:17:35 +0100
Subject: [PATCH v1 05/24] clk: wrap I/O access for improved portability
In-Reply-To: <20130718070402.GO7080@book.gsilab.sittig.org>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1373914074-20889-6-git-send-email-gsi@denx.de>
 <20130715193829.GS14452@pengutronix.de>
 <20130718070402.GO7080@book.gsilab.sittig.org>
Message-ID: <20130718091735.GW24642@n2100.arm.linux.org.uk>

On Thu, Jul 18, 2013 at 09:04:02AM +0200, Gerhard Sittig wrote:
> The common clock API assumes (it's part of the contract) that
> there are potentially expensive operations like get, put, prepare
> and unprepare, as well as swift and non-blocking operations like
> enable and disable.

Let's get something straight here, because what you've said above is
wrong.

1. clk_get() and clk_put() are NOT part of the common clock API.
   They're separate - they're part of the clk API, and the infrastructure
   behind that is clkdev, which is a separately owned thing (by me.)

2. The "contract" of the clk API is defined by the clk API, not by some
   random implementation like the common clock API.  The clk API is
   maintained by myself, and is described in include/linux/clk.h

3. clk_prepare() and clk_unprepare() are functions MUST only be called
   from contexts where sleeping is permitted.  These functions MAY sleep
   for whatever reason they require to, and as long as they require to.
   (This is the whole reason these two functions were created in the
   first place.)

4. clk_enable() and clk_disable() MAY be called from any context, but
   MUST never sleep.  If you need to talk over a non-atomic bus for these,
   then these functions should be no-ops, and the code which does that
   must be executed from the clk_prepare()/clk_unprepare() operations.

That is the "clk API" contract.  The CCF has no bearing on this; if it
disagrees, then the CCF is buggy and is non-conformant.


From elen.song at atmel.com  Thu Jul 18 05:21:00 2013
From: elen.song at atmel.com (elen.song)
Date: Thu, 18 Jul 2013 17:21:00 +0800
Subject: [PATCH V2 5/8] serial: at91: support run time switch transfer mode
In-Reply-To: <20130718081520.GC16015@ns203013.ovh.net>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
 <1373942627-7121-6-git-send-email-elen.song@atmel.com>
 <20130718081520.GC16015@ns203013.ovh.net>
Message-ID: <51E7B37C.5090105@atmel.com>

Hi JC:
On 7/18/2013 4:15 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:43 Tue 16 Jul     , Elen Song wrote:
>> We will switch to pio mode when request of dma or pdc fail.
>> But soon or later, when the request is success, the transfer mode can switch to them at
>> next open serial port action.
>> So in startup stage, we should get original transfer mode.
> You need to update the Documentation of the binding to said the driver support
> dmas bindings for the new IP

one question, it seems the document should write like:

use DMA:
     usart0: serial at f001c000{
         compatible = "atmel,at91sam9260-usart";
         dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(3)>,
                      <&dma0 2 
(AT91_DMA_CFG_PER_ID(3)|AT91_DMA_CFG_FIFOCFG_ASAP)>;
         dma-names = "tx","rx";
};

Should I replace macros with typical values?

Best regards
> and please use true/false for boolean
>
> and check the white space
>> Signed-off-by: Elen Song <elen.song at atmel.com>
>> ---
>>   drivers/tty/serial/atmel_serial.c |  139 +++++++++++++++++++++----------------
>>   1 file changed, 80 insertions(+), 59 deletions(-)
>>
>> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>> index 298b58c..ad787fd1 100644
>> --- a/drivers/tty/serial/atmel_serial.c
>> +++ b/drivers/tty/serial/atmel_serial.c
>> @@ -1371,6 +1371,80 @@ static void atmel_tasklet_func(unsigned long data)
>>   	spin_unlock(&port->lock);
>>   }
>>   
>> +static int atmel_init_property(struct atmel_uart_port *atmel_port,
>> +				struct platform_device *pdev)
>> +{
>> +	struct device_node *np = pdev->dev.of_node;
>> +	struct atmel_uart_data *pdata = pdev->dev.platform_data;
>> +
>> +	if (np) {
>> +		/* DMA/PDC usage specification */
>> +		if (of_get_property(np, "atmel,use-dma-rx", NULL)) {
>> +			if (of_get_property(np, "dmas", NULL)) {
>> +				atmel_port->use_dma_rx  = 1;
>> +				atmel_port->use_pdc_rx  = 0;
>> +			} else {
>> +				atmel_port->use_dma_rx  = 0;
>> +				atmel_port->use_pdc_rx  = 1;
>> +			}
>> +		} else {
>> +			atmel_port->use_dma_rx  = 0;
>> +			atmel_port->use_pdc_rx  = 0;
>> +		}
>> +
>> +		if (of_get_property(np, "atmel,use-dma-tx", NULL)) {
>> +			if (of_get_property(np, "dmas", NULL)) {
>> +				atmel_port->use_dma_tx  = 1;
>> +				atmel_port->use_pdc_tx  = 0;
>> +			} else {
>> +				atmel_port->use_dma_tx  = 0;
>> +				atmel_port->use_pdc_tx  = 1;
>> +			}
>> +		} else {
>> +			atmel_port->use_dma_tx  = 0;
>> +			atmel_port->use_pdc_tx  = 0;
>> +		}
>> +
>> +	} else {
>> +		atmel_port->use_pdc_rx  = pdata->use_dma_rx;
>> +		atmel_port->use_pdc_tx  = pdata->use_dma_tx;
>> +		atmel_port->use_dma_rx  = 0;
>> +		atmel_port->use_dma_tx  = 0;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static void atmel_init_rs485(struct atmel_uart_port *atmel_port,
>> +				struct platform_device *pdev)
>> +{
>> +	struct device_node *np = pdev->dev.of_node;
>> +	struct atmel_uart_data *pdata = pdev->dev.platform_data;
>> +
>> +	if (np) {
>> +		u32 rs485_delay[2];
>> +		/* rs485 properties */
>> +		if (of_property_read_u32_array(np, "rs485-rts-delay",
>> +					rs485_delay, 2) == 0) {
>> +			struct serial_rs485 *rs485conf = &atmel_port->rs485;
>> +
>> +			rs485conf->delay_rts_before_send = rs485_delay[0];
>> +			rs485conf->delay_rts_after_send = rs485_delay[1];
>> +			rs485conf->flags = 0;
>> +
>> +		if (of_get_property(np, "rs485-rx-during-tx", NULL))
>> +			rs485conf->flags |= SER_RS485_RX_DURING_TX;
>> +
>> +		if (of_get_property(np, "linux,rs485-enabled-at-boot-time",
>> +								NULL))
>> +			rs485conf->flags |= SER_RS485_ENABLED;
>> +		}
>> +	} else {
>> +		atmel_port->rs485       = pdata->rs485;
>> +	}
>> +
>> +}
>> +
>>   static void atmel_set_ops(struct uart_port *port)
>>   {
>>   	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>> @@ -1409,6 +1483,7 @@ static void atmel_set_ops(struct uart_port *port)
>>    */
>>   static int atmel_startup(struct uart_port *port)
>>   {
>> +	struct platform_device *pdev = to_platform_device(port->dev);
>>   	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>>   	struct tty_struct *tty = port->state->port.tty;
>>   	int retval;
>> @@ -1433,6 +1508,8 @@ static int atmel_startup(struct uart_port *port)
>>   	/*
>>   	 * Initialize DMA (if necessary)
>>   	 */
>> +	atmel_init_property(atmel_port, pdev);
>> +
>>   	if (atmel_port->prepare_rx) {
>>   		retval = atmel_port->prepare_rx(port);
>>   		if (retval < 0)
>> @@ -1878,55 +1955,6 @@ static struct uart_ops atmel_pops = {
>>   #endif
>>   };
>>   
>> -static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
>> -					 struct device_node *np)
>> -{
>> -	u32 rs485_delay[2];
>> -
>> -	/* DMA/PDC usage specification */
>> -	if (of_get_property(np, "atmel,use-dma-rx", NULL)) {
>> -		if (of_get_property(np, "dmas", NULL)) {
>> -			atmel_port->use_dma_rx	= 1;
>> -			atmel_port->use_pdc_rx	= 0;
>> -		} else {
>> -			atmel_port->use_dma_rx	= 0;
>> -			atmel_port->use_pdc_rx	= 1;
>> -		}
>> -	} else {
>> -		atmel_port->use_dma_rx	= 0;
>> -		atmel_port->use_pdc_rx	= 0;
>> -	}
>> -
>> -	if (of_get_property(np, "atmel,use-dma-tx", NULL)) {
>> -		if (of_get_property(np, "dmas", NULL)) {
>> -			atmel_port->use_dma_tx	= 1;
>> -			atmel_port->use_pdc_tx	= 0;
>> -		} else {
>> -			atmel_port->use_dma_tx	= 0;
>> -			atmel_port->use_pdc_tx	= 1;
>> -		}
>> -	} else {
>> -		atmel_port->use_dma_tx	= 0;
>> -		atmel_port->use_pdc_tx	= 0;
>> -	}
>> -
>> -	/* rs485 properties */
>> -	if (of_property_read_u32_array(np, "rs485-rts-delay",
>> -					    rs485_delay, 2) == 0) {
>> -		struct serial_rs485 *rs485conf = &atmel_port->rs485;
>> -
>> -		rs485conf->delay_rts_before_send = rs485_delay[0];
>> -		rs485conf->delay_rts_after_send = rs485_delay[1];
>> -		rs485conf->flags = 0;
>> -
>> -		if (of_get_property(np, "rs485-rx-during-tx", NULL))
>> -			rs485conf->flags |= SER_RS485_RX_DURING_TX;
>> -
>> -		if (of_get_property(np, "linux,rs485-enabled-at-boot-time", NULL))
>> -			rs485conf->flags |= SER_RS485_ENABLED;
>> -	}
>> -}
>> -
>>   /*
>>    * Configure the port from the platform device resource info.
>>    */
>> @@ -1936,17 +1964,10 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
>>   	struct uart_port *port = &atmel_port->uart;
>>   	struct atmel_uart_data *pdata = pdev->dev.platform_data;
>>   
>> -	if (pdev->dev.of_node) {
>> -		atmel_of_init_port(atmel_port, pdev->dev.of_node);
>> -	} else {
>> -		atmel_port->use_pdc_rx	= pdata->use_dma_rx;
>> -		atmel_port->use_pdc_tx	= pdata->use_dma_tx;
>> -		atmel_port->use_dma_rx	= 0;
>> -		atmel_port->use_dma_tx	= 0;
>> -		atmel_port->rs485	= pdata->rs485;
>> -	}
>> +	if (!atmel_init_property(atmel_port, pdev))
>> +		atmel_set_ops(port);
>>   
>> -	atmel_set_ops(port);
>> +	atmel_init_rs485(atmel_port, pdev);
>>   
>>   	port->iotype		= UPIO_MEM;
>>   	port->flags		= UPF_BOOT_AUTOCONF;
>> -- 
>> 1.7.9.5
>>



From mmarek at suse.cz  Thu Jul 18 05:22:24 2013
From: mmarek at suse.cz (Michal Marek)
Date: Thu, 18 Jul 2013 11:22:24 +0200
Subject: [PATCH] arm, kbuild: make "make install" not depend on vmlinux
In-Reply-To: <CA+55aFzhmV7iq+Pv37trMCmdNzk53ORAoj0a6rV14fzKta3Dhw@mail.gmail.com>
References: <20130710133742.GA29368@emu.suse.cz>
 <CA+55aFxtvT3Yvbxe5JGBThZS13payymFJ7jCLyEiE2iNDvsZtQ@mail.gmail.com>
 <20130711135445.GA21500@sepie.suse.cz>
 <CA+55aFyVjugxM7cUDWi0ASWttYthCxa6e7X3CADknBcSFxWgew@mail.gmail.com>
 <20130712105721.GF8731@rric.localhost> <20130717160506.GI8731@rric.localhost>
 <CA+55aFx4G5gME3ByqE0Wr-_t2x_6WkP3Ta4k1z4jfW+PrcK0og@mail.gmail.com>
 <20130717165743.GK8731@rric.localhost>
 <CA+55aFzhmV7iq+Pv37trMCmdNzk53ORAoj0a6rV14fzKta3Dhw@mail.gmail.com>
Message-ID: <51E7B3D0.4060609@suse.cz>

On 17.7.2013 19:03, Linus Torvalds wrote:
> On Wed, Jul 17, 2013 at 9:57 AM, Robert Richter <rric at kernel.org> wrote:
>>
>> If kernel.release doen't exist KERNEL_RELEASE is empty, thus all args
>> for install.sh shift one arg left.
> 
> You know what? I read the patch, but I didn't read your changelog well
> enough. You already explained that in the commit log, and I just
> missed it like some blind monkey. My bad.
> 
>> Will splitt the patches and resend.
> 
> No need to split, I was wrong, it wasn't some unrelated cleanup, and
> you were right the first time.
> 
> So Michal (or ARM people - whoever wants to take the patch), just take
> my ack. No objections.

I can add it to the kbuild tree if needed. Otherwise you can add
Acked-by: Michal Marek <mmarek at suse.cz>.

Michal



From p.zabel at pengutronix.de  Thu Jul 18 05:26:26 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 18 Jul 2013 11:26:26 +0200
Subject: [PATCH v10] reset: Add driver for gpio-controlled reset pins
Message-ID: <1374139586-6344-1-git-send-email-p.zabel@pengutronix.de>

This driver implements a reset controller device that toggle a gpio
connected to a reset pin of a peripheral IC. The delay between assertion
and de-assertion of the reset signal can be configured via device tree.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
Reviewed-by: Stephen Warren <swarren at nvidia.com>
---
Changes since v9:
 - Use gpio_set_value_cansleep unconditionally. reset_controller_assert/deassert
   should not be called from atomic context.
---
 .../devicetree/bindings/reset/gpio-reset.txt       |  35 ++++
 drivers/reset/Kconfig                              |  11 ++
 drivers/reset/Makefile                             |   1 +
 drivers/reset/gpio-reset.c                         | 184 +++++++++++++++++++++
 4 files changed, 231 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/gpio-reset.txt
 create mode 100644 drivers/reset/gpio-reset.c

diff --git a/Documentation/devicetree/bindings/reset/gpio-reset.txt b/Documentation/devicetree/bindings/reset/gpio-reset.txt
new file mode 100644
index 0000000..bca5348
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/gpio-reset.txt
@@ -0,0 +1,35 @@
+GPIO reset controller
+=====================
+
+A GPIO reset controller controls a single GPIO that is connected to the reset
+pin of a peripheral IC. Please also refer to reset.txt in this directory for
+common reset controller binding usage.
+
+Required properties:
+- compatible: Should be "gpio-reset"
+- reset-gpios: A gpio used as reset line. The gpio specifier for this property
+               depends on the gpio controller that provides the gpio.
+- #reset-cells: 0, see below
+
+Optional properties:
+- reset-delay-us: delay in microseconds. The gpio reset line will be asserted for
+                  this duration to reset.
+- initially-in-reset: boolean. If not set, the initial state should be a
+                      deasserted reset line. If this property exists, the
+                      reset line should be kept in reset.
+
+example:
+
+sii902x_reset: gpio-reset {
+	compatible = "gpio-reset";
+	reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+	reset-delay-us = <10000>;
+	initially-in-reset;
+	#reset-cells = <0>;
+};
+
+/* Device with nRESET pin connected to GPIO5_0 */
+sii902x at 39 {
+	/* ... */
+	resets = <&sii902x_reset>; /* active-low GPIO5_0, 10 ms delay */
+};
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index c9d04f7..1a862df 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -11,3 +11,14 @@ menuconfig RESET_CONTROLLER
 	  via GPIOs or SoC-internal reset controller modules.
 
 	  If unsure, say no.
+
+if RESET_CONTROLLER
+
+config RESET_GPIO
+	tristate "GPIO reset controller support"
+	depends on GPIOLIB && OF
+	help
+	  This driver provides support for reset lines that are controlled
+	  directly by GPIOs.
+
+endif
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 1e2d83f..b854f20 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_RESET_CONTROLLER) += core.o
+obj-$(CONFIG_RESET_GPIO) += gpio-reset.o
diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
new file mode 100644
index 0000000..3049b22
--- /dev/null
+++ b/drivers/reset/gpio-reset.c
@@ -0,0 +1,184 @@
+/*
+ * GPIO Reset Controller driver
+ *
+ * Copyright 2013 Philipp Zabel, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+
+struct gpio_reset_data {
+	struct reset_controller_dev rcdev;
+	unsigned int gpio;
+	bool active_low;
+	s32 delay_us;
+};
+
+static void gpio_reset_set(struct reset_controller_dev *rcdev, int asserted)
+{
+	struct gpio_reset_data *drvdata = container_of(rcdev,
+			struct gpio_reset_data, rcdev);
+	int value = asserted;
+
+	if (drvdata->active_low)
+		value = !value;
+
+	gpio_set_value_cansleep(drvdata->gpio, value);
+}
+
+static int gpio_reset(struct reset_controller_dev *rcdev, unsigned long id)
+{
+	struct gpio_reset_data *drvdata = container_of(rcdev,
+			struct gpio_reset_data, rcdev);
+
+	if (drvdata->delay_us < 0)
+		return -ENOSYS;
+
+	gpio_reset_set(rcdev, 1);
+	udelay(drvdata->delay_us);
+	gpio_reset_set(rcdev, 0);
+
+	return 0;
+}
+
+static int gpio_reset_assert(struct reset_controller_dev *rcdev,
+		unsigned long id)
+{
+	gpio_reset_set(rcdev, 1);
+
+	return 0;
+}
+
+static int gpio_reset_deassert(struct reset_controller_dev *rcdev,
+		unsigned long id)
+{
+	gpio_reset_set(rcdev, 0);
+
+	return 0;
+}
+
+static struct reset_control_ops gpio_reset_ops = {
+	.reset = gpio_reset,
+	.assert = gpio_reset_assert,
+	.deassert = gpio_reset_deassert,
+};
+
+static int of_gpio_reset_xlate(struct reset_controller_dev *rcdev,
+			       const struct of_phandle_args *reset_spec)
+{
+	if (WARN_ON(reset_spec->args_count != 0))
+		return -EINVAL;
+
+	return 0;
+}
+
+static int gpio_reset_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct gpio_reset_data *drvdata;
+	enum of_gpio_flags flags;
+	unsigned long gpio_flags;
+	bool initially_in_reset;
+	int ret;
+
+	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (drvdata == NULL)
+		return -ENOMEM;
+
+	if (of_gpio_named_count(np, "reset-gpios") != 1) {
+		dev_err(&pdev->dev,
+			"reset-gpios property missing, or not a single gpio\n");
+		return -EINVAL;
+	}
+
+	drvdata->gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
+	if (drvdata->gpio == -EPROBE_DEFER) {
+		return drvdata->gpio;
+	} else if (!gpio_is_valid(drvdata->gpio)) {
+		dev_err(&pdev->dev, "invalid reset gpio: %d\n", drvdata->gpio);
+		return drvdata->gpio;
+	}
+
+	drvdata->active_low = flags & OF_GPIO_ACTIVE_LOW;
+
+	ret = of_property_read_u32(np, "reset-delay-us", &drvdata->delay_us);
+	if (ret < 0)
+		drvdata->delay_us = -1;
+	else if (drvdata->delay_us < 0)
+		dev_warn(&pdev->dev, "reset delay too high\n");
+
+	initially_in_reset = of_property_read_bool(np, "initially-in-reset");
+	if (drvdata->active_low ^ initially_in_reset)
+		gpio_flags = GPIOF_OUT_INIT_HIGH;
+	else
+		gpio_flags = GPIOF_OUT_INIT_LOW;
+
+	ret = devm_gpio_request_one(&pdev->dev, drvdata->gpio, gpio_flags, NULL);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to request gpio %d: %d\n",
+			drvdata->gpio, ret);
+		return ret;
+	}
+
+	platform_set_drvdata(pdev, drvdata);
+
+	drvdata->rcdev.of_node = np;
+	drvdata->rcdev.owner = THIS_MODULE;
+	drvdata->rcdev.nr_resets = 1;
+	drvdata->rcdev.ops = &gpio_reset_ops;
+	drvdata->rcdev.of_xlate = of_gpio_reset_xlate;
+	reset_controller_register(&drvdata->rcdev);
+
+	return 0;
+}
+
+static int gpio_reset_remove(struct platform_device *pdev)
+{
+	struct gpio_reset_data *drvdata = platform_get_drvdata(pdev);
+
+	reset_controller_unregister(&drvdata->rcdev);
+
+	return 0;
+}
+
+static struct of_device_id gpio_reset_dt_ids[] = {
+	{ .compatible = "gpio-reset" },
+	{ }
+};
+
+static struct platform_driver gpio_reset_driver = {
+	.probe = gpio_reset_probe,
+	.remove = gpio_reset_remove,
+	.driver = {
+		.name = "gpio-reset",
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(gpio_reset_dt_ids),
+	},
+};
+
+static int __init gpio_reset_init(void)
+{
+	return platform_driver_register(&gpio_reset_driver);
+}
+arch_initcall(gpio_reset_init);
+
+static void __exit gpio_reset_exit(void)
+{
+	platform_driver_unregister(&gpio_reset_driver);
+}
+module_exit(gpio_reset_exit);
+
+MODULE_AUTHOR("Philipp Zabel <p.zabel at pengutronix.de>");
+MODULE_DESCRIPTION("gpio reset controller");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:gpio-reset");
+MODULE_DEVICE_TABLE(of, gpio_reset_dt_ids);
-- 
1.8.3.2



From lorenzo.pieralisi at arm.com  Thu Jul 18 05:28:09 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 18 Jul 2013 10:28:09 +0100
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
In-Reply-To: <20130717210700.GA19864@zurbaran>
References: <1373990743-23106-1-git-send-email-lorenzo.pieralisi@arm.com>
 <20130717210700.GA19864@zurbaran>
Message-ID: <20130718092809.GA29977@e102568-lin.cambridge.arm.com>

Hi Samuel,

On Wed, Jul 17, 2013 at 10:07:00PM +0100, Samuel Ortiz wrote:
> Hi Lorenzo,
> 
> On Tue, Jul 16, 2013 at 05:05:42PM +0100, Lorenzo Pieralisi wrote:
> > Hello,
> > 
> > version v5 of VExpress SPC driver, please read on the changelog for major
> > changes and explanations.
> > 
> > The probing scheme is unchanged, since after trying the early platform
> > devices approach it appeared that the end result was no better than the
> > current one. The only clean solution relies either on changing how
> > secondaries are brought up in the kernel (later than now) or enable
> > early platform device registration through DT. Please check this
> > thread for the related discussion:
> > 
> > https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036542.html
> > 
> > The interface was adapted to regmap and again reverted to old driver for
> > the following reasons:
> > 
> > - Power down registers locking is hairy and requires arch spinlocks in
> >   the MCPM back end to work properly, normal spinlocks cannot be used
> > - Regmap adds unnecessary code to manage SPC since it is just a bunch of
> >   registers used to control power management flags, the overhead is just
> >   not worth it (talking about power down registers, not the vexpress config
> >   interface)
> > - The locking scheme behind regmap requires all registers in the map
> >   to be protected with the same lock, which is not exactly what we want
> >   here
> > - Given the reasons above, adding a regmap interface buys us nothing from
> >   a driver readability and maintainability perspective (again just talking
> >   about the power interface, a few registers) because for the SPC it would
> >   simply not be used
> > 
> > /drivers/mfd is probably not the right place for this code as it stands (but
> > probably will be when the entire driver, with DVFS and config interface, is
> > complete).
> Could you please elaborate on how will the SPC driver extend into an MFD
> driver?

Reading through the thread I noticed Nico explained details properly, I
was about to mention a possible solution to the directory issue but I am
pretty sure that what he did will turn out for the best.

Usually, or better, historically, these pieces of code that program
PMICs lived in arch/arm/mach-* directories and that's something we could
have done as well (create a static mapping and write some functions to
peek and poke a few registers), but we thought that it was not the proper
way to go.

On top of that, the SPC is part of a component whose register space maps
disparate functions (config interface for voltage, clocks, energy probes,
frequency scaling and power states management) and basically that's the
reason we struggled to partition it properly (with further complexity
implied by the way requests - config and frequency scaling - have to be
serialized).

I hope the end result is reasonable, and overall I think it was a debate
that was worth having.

Thank you,
Lorenzo



From sr at denx.de  Thu Jul 18 05:40:42 2013
From: sr at denx.de (Stefan Roese)
Date: Thu, 18 Jul 2013 11:40:42 +0200
Subject: [PATCH] ARM: omap2: fix musb usage for n8x0
In-Reply-To: <51E7B2FA.7020206@ti.com>
References: <1374000777-5626-1-git-send-email-zonque@gmail.com>
 <51E7B1FF.6000301@denx.de> <51E7B2FA.7020206@ti.com>
Message-ID: <51E7B81A.70103@denx.de>

On 07/18/2013 11:18 AM, Kishon Vijay Abraham I wrote:
>> I'm testing musb as OTG on beagleboard (old one, not Beagle-xm). And
>> using the latest kernel.org version with this patch applied I see the
>> following messages while booting (repeatedly):
>>
>> [    4.998168] usb usb1: bus auto-suspend, wakeup 1
>> [    5.003112] musb_bus_suspend 2457: trying to suspend as b_idle while active
>> [    5.010498] usb usb1: bus suspend fail, err -16
>> [    5.015289] hub 1-0:1.0: hub_resume
>> [    5.019073] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
>> [    5.024963] hub 1-0:1.0: hub_suspend
>> [    5.028778] usb usb1: bus auto-suspend, wakeup 1
>> ...
>>
>> This is without a cable connected to the OTG port.
>>
>> Any ideas what might be missing here?
> 
> Even I observed these prints when I have dual mode enabled. When kept as gadget
> only mode I dint see these prints.

Yes. With gadget-only I don't see those messages. Thanks for the hint.

> However if you connect a cable, you should still see that enumeration should
> succeed.
> Not sure why those prints come though :-s

No. When configured as dual-role these endless messages are still there
with a cable connected to the PC USB host port (musb gadget mode).

Thanks,
Stefan



From jonas.jensen at gmail.com  Thu Jul 18 05:46:46 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Thu, 18 Jul 2013 11:46:46 +0200
Subject: [PATCH] net: Add MOXA ART SoCs ethernet driver
Message-ID: <1374140806-12485-1-git-send-email-jonas.jensen@gmail.com>

The MOXA UC-711X hardware(s) has an ethernet controller that seem to be
developed internally. The IC used is "RTL8201CP".

Since there is no public documentation, this driver is mostly the one
published by MOXA that has been heavily cleaned up / ported from linux 2.6.9.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Applies to next-20130716

 .../devicetree/bindings/net/moxa,moxart-mac.txt    |  25 +
 drivers/net/ethernet/Kconfig                       |   1 +
 drivers/net/ethernet/Makefile                      |   1 +
 drivers/net/ethernet/moxa/Kconfig                  |  30 ++
 drivers/net/ethernet/moxa/Makefile                 |   6 +
 drivers/net/ethernet/moxa/moxart_ether.c           | 544 +++++++++++++++++++++
 drivers/net/ethernet/moxa/moxart_ether.h           | 525 ++++++++++++++++++++
 7 files changed, 1132 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
 create mode 100644 drivers/net/ethernet/moxa/Kconfig
 create mode 100644 drivers/net/ethernet/moxa/Makefile
 create mode 100644 drivers/net/ethernet/moxa/moxart_ether.c
 create mode 100644 drivers/net/ethernet/moxa/moxart_ether.h

diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
new file mode 100644
index 0000000..12e12a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
@@ -0,0 +1,25 @@
+MOXA ART Ethernet Controller
+
+Required properties:
+
+- compatible : Should be "moxa,moxart-mac"
+- reg : Should contain registers location and length
+  index 0 : main register
+  index 1 : mac address (stored on flash)
+- interrupts : Should contain the mac interrupt number
+
+Example:
+
+	mac0: mac at 90900000 {
+		compatible = "moxa,moxart-mac";
+		reg =	<0x90900000 0x100>,
+			<0x80000050 0x6>;
+		interrupts = <25 0>;
+	};
+
+	mac1: mac at 92000000 {
+		compatible = "moxa,moxart-mac";
+		reg =	<0x92000000 0x100>,
+			<0x80000056 0x6>;
+		interrupts = <27 0>;
+	};
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 2037080..506b024 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -90,6 +90,7 @@ source "drivers/net/ethernet/marvell/Kconfig"
 source "drivers/net/ethernet/mellanox/Kconfig"
 source "drivers/net/ethernet/micrel/Kconfig"
 source "drivers/net/ethernet/microchip/Kconfig"
+source "drivers/net/ethernet/moxa/Kconfig"
 source "drivers/net/ethernet/myricom/Kconfig"
 
 config FEALNX
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 390bd0b..c0b8789 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_NET_VENDOR_MARVELL) += marvell/
 obj-$(CONFIG_NET_VENDOR_MELLANOX) += mellanox/
 obj-$(CONFIG_NET_VENDOR_MICREL) += micrel/
 obj-$(CONFIG_NET_VENDOR_MICROCHIP) += microchip/
+obj-$(CONFIG_NET_VENDOR_MOXART) += moxa/
 obj-$(CONFIG_NET_VENDOR_MYRI) += myricom/
 obj-$(CONFIG_FEALNX) += fealnx.o
 obj-$(CONFIG_NET_VENDOR_NATSEMI) += natsemi/
diff --git a/drivers/net/ethernet/moxa/Kconfig b/drivers/net/ethernet/moxa/Kconfig
new file mode 100644
index 0000000..1731e05
--- /dev/null
+++ b/drivers/net/ethernet/moxa/Kconfig
@@ -0,0 +1,30 @@
+#
+# MOXART device configuration
+#
+
+config NET_VENDOR_MOXART
+	bool "MOXA ART devices"
+	default y
+	depends on (ARM && ARCH_MOXART)
+	---help---
+	  If you have a network (Ethernet) card belonging to this class, say Y
+	  and read the Ethernet-HOWTO, available from
+	  <http://www.tldp.org/docs.html#howto>.
+
+	  Note that the answer to this question doesn't directly affect the
+	  kernel: saying N will just cause the configurator to skip all
+	  the questions about MOXA ART devices. If you say Y, you will be asked
+	  for your specific card in the following questions.
+
+if NET_VENDOR_MOXART
+
+config ARM_MOXART_ETHER
+	tristate "MOXART Ethernet support"
+	depends on ARM && ARCH_MOXART
+	select NET_CORE
+	---help---
+	  If you wish to compile a kernel for a hardware with MOXA ART SoC and
+	  want to use the internal ethernet then you should answer Y to this.
+
+
+endif # NET_VENDOR_MOXART
diff --git a/drivers/net/ethernet/moxa/Makefile b/drivers/net/ethernet/moxa/Makefile
new file mode 100644
index 0000000..d757a78
--- /dev/null
+++ b/drivers/net/ethernet/moxa/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for the MOXART network device drivers.
+#
+
+obj-$(CONFIG_ARM_MOXART_ETHER) += moxart_ether.o
+
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
new file mode 100644
index 0000000..172f718
--- /dev/null
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -0,0 +1,544 @@
+/* MOXA ART Ethernet (RTL8201CP) driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/skbuff.h>
+#include <linux/dma-mapping.h>
+#include <linux/ethtool.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/crc32.h>
+#include <linux/crc32c.h>
+
+#include "moxart_ether.h"
+
+static inline unsigned long moxart_emac_read(struct net_device *ndev,
+					     unsigned int reg)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	return readl(priv->base + reg);
+}
+
+static inline void moxart_emac_write(struct net_device *ndev,
+				     unsigned int reg, unsigned long value)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	writel(value, priv->base + reg);
+}
+
+static void moxart_update_mac_address(struct net_device *ndev)
+{
+	moxart_emac_write(ndev, MAC_MADR_REG_OFFSET,
+			  ((ndev->dev_addr[0] << 8) | (ndev->dev_addr[1])));
+	moxart_emac_write(ndev, MAC_MADR_REG_OFFSET + 4,
+			  ((ndev->dev_addr[2] << 24) |
+			   (ndev->dev_addr[3] << 16) |
+			   (ndev->dev_addr[4] << 8) |
+			   (ndev->dev_addr[5])));
+}
+
+static int moxart_set_mac_address(struct net_device *ndev, void *addr)
+{
+	struct sockaddr *address = addr;
+
+	if (!is_valid_ether_addr(address->sa_data))
+		return -EADDRNOTAVAIL;
+
+	memcpy(ndev->dev_addr, address->sa_data, ndev->addr_len);
+	moxart_update_mac_address(ndev);
+
+	return 0;
+}
+
+static void moxart_mac_free_memory(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	if (priv->virt_tx_desc_baseaddr)
+		dma_free_coherent(NULL, sizeof(struct tx_desc_t)*TX_DESC_NUM,
+				  priv->virt_tx_desc_baseaddr,
+				  priv->phy_tx_desc_baseaddr);
+	if (priv->virt_rx_desc_baseaddr)
+		dma_free_coherent(NULL, sizeof(struct rx_desc_t)*RX_DESC_NUM,
+				  priv->virt_rx_desc_baseaddr,
+				  priv->phy_rx_desc_baseaddr);
+	if (priv->virt_tx_buf_baseaddr)
+		dma_free_coherent(NULL, TX_BUF_SIZE*TX_DESC_NUM,
+				  priv->virt_tx_buf_baseaddr,
+				  priv->phy_tx_buf_baseaddr);
+	if (priv->virt_rx_buf_baseaddr)
+		dma_free_coherent(NULL, RX_BUF_SIZE*RX_DESC_NUM,
+				  priv->virt_rx_buf_baseaddr,
+				  priv->phy_rx_buf_baseaddr);
+}
+
+static void moxart_mac_reset(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	writel(SW_RST, priv->base + MACCR_REG_OFFSET);
+	while (readl(priv->base + MACCR_REG_OFFSET) & SW_RST)
+		mdelay(10);
+
+	writel(0, priv->base + IMR_REG_OFFSET);
+
+	priv->maccr = RX_BROADPKT | FULLDUP | CRC_APD | RX_FTL;
+}
+
+static void moxart_mac_enable(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	writel(0x00001010, priv->base + ITC_REG_OFFSET);
+	writel(0x00000001, priv->base + APTC_REG_OFFSET);
+	writel(0x00000390, priv->base + DBLAC_REG_OFFSET);
+
+	writel(RPKT_FINISH_M, priv->base + IMR_REG_OFFSET);
+	priv->maccr |= (RCV_EN | XMT_EN | RDMA_EN | XDMA_EN);
+	writel(priv->maccr, priv->base + MACCR_REG_OFFSET);
+}
+
+static void moxart_mac_setup_desc_ring(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	struct tx_desc_t *txdesc;
+	struct rx_desc_t *rxdesc;
+	unsigned char *virtbuf;
+	unsigned int phybuf;
+	int i;
+
+	virtbuf = priv->virt_tx_buf_baseaddr;
+	phybuf = priv->phy_tx_buf_baseaddr;
+	for (i = 0; i < TX_DESC_NUM; i++,
+		virtbuf += TX_BUF_SIZE, phybuf += TX_BUF_SIZE) {
+		txdesc = &priv->virt_tx_desc_baseaddr[i];
+		memset(txdesc, 0, sizeof(struct tx_desc_t));
+		txdesc->txdes2.phy_tx_buf_baseaddr = phybuf;
+		txdesc->txdes2.virt_tx_buf_baseaddr = virtbuf;
+	}
+	priv->virt_tx_desc_baseaddr[TX_DESC_NUM - 1].txdes1.ubit.edotr = 1;
+	priv->tx_desc_now = 0;
+
+	virtbuf = priv->virt_rx_buf_baseaddr;
+	phybuf = priv->phy_rx_buf_baseaddr;
+	for (i = 0; i < RX_DESC_NUM; i++,
+		virtbuf += RX_BUF_SIZE, phybuf += RX_BUF_SIZE) {
+		rxdesc = &priv->virt_rx_desc_baseaddr[i];
+		memset(rxdesc, 0, sizeof(struct rx_desc_t));
+		rxdesc->rxdes0.ubit.rx_dma_own = 1;
+		rxdesc->rxdes1.ubit.rx_buf_size = RX_BUF_SIZE;
+		rxdesc->rxdes2.phy_rx_buf_baseaddr = phybuf;
+		rxdesc->rxdes2.virt_rx_buf_baseaddr = virtbuf;
+	}
+	priv->virt_rx_desc_baseaddr[RX_DESC_NUM - 1].rxdes1.ubit.edorr = 1;
+	priv->rx_desc_now = 0;
+
+	/* reset the MAC controler TX/RX desciptor base address */
+	writel(priv->phy_tx_desc_baseaddr, priv->base + TXR_BADR_REG_OFFSET);
+	writel(priv->phy_rx_desc_baseaddr, priv->base + RXR_BADR_REG_OFFSET);
+}
+
+static int moxart_mac_open(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	if (!is_valid_ether_addr(ndev->dev_addr))
+		return -EADDRNOTAVAIL;
+
+	spin_lock_irq(&priv->txlock);
+	moxart_mac_reset(ndev);
+	moxart_update_mac_address(ndev);
+	moxart_mac_setup_desc_ring(ndev);
+	moxart_mac_enable(ndev);
+	spin_unlock_irq(&priv->txlock);
+	netif_start_queue(ndev);
+
+	netdev_dbg(ndev, "%s: IMR=0x%x, MACCR=0x%x\n",
+		   __func__, readl(priv->base + IMR_REG_OFFSET),
+		   readl(priv->base + MACCR_REG_OFFSET));
+
+	return 0;
+}
+
+static int moxart_mac_stop(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	netif_stop_queue(ndev);
+	spin_lock_irq(&priv->txlock);
+
+	/* disable all interrupts */
+	writel(0, priv->base + IMR_REG_OFFSET);
+
+	/* disable all functions */
+	writel(0, priv->base + MACCR_REG_OFFSET);
+
+	spin_unlock_irq(&priv->txlock);
+
+	return 0;
+}
+
+static void moxart_mac_recv(struct work_struct *ptr)
+{
+	struct net_device *ndev = (struct net_device *) ptr;
+	struct moxart_mac_priv_t *priv = netdev_priv((struct net_device *)ptr);
+	struct rx_desc_t *rxdesc;
+	struct sk_buff *skb;
+	unsigned int ui, len;
+	int rxnow = priv->rx_desc_now;
+	int loops = RX_DESC_NUM;
+
+repeat_recv:
+	rxdesc = &priv->virt_rx_desc_baseaddr[rxnow];
+	ui = rxdesc->rxdes0.ui;
+
+	if (ui & RXDMA_OWN)
+		return;
+
+	if (ui & (RX_ERR | CRC_ERR | FTL | RUNT | RX_ODD_NB)) {
+		netdev_err(ndev, "%s: packet error\n", __func__);
+		priv->stats.rx_dropped++;
+		priv->stats.rx_errors++;
+		goto recv_finish;
+	}
+
+	len = ui & RFL_MASK;
+
+	if (len > RX_BUF_SIZE)
+		len = RX_BUF_SIZE;
+
+	skb = dev_alloc_skb(len + 2);
+	if (skb == NULL) {
+		netdev_err(ndev, "%s: dev_alloc_skb failed\n", __func__);
+		priv->stats.rx_dropped++;
+		goto recv_finish;
+	}
+
+	skb_reserve(skb, 2);
+	skb->dev = ndev;
+	memcpy(skb_put(skb, len), rxdesc->rxdes2.virt_rx_buf_baseaddr, len);
+	netif_rx(skb);
+	skb->protocol = eth_type_trans(skb, ndev);
+	ndev->last_rx = jiffies;
+	priv->stats.rx_packets++;
+	priv->stats.rx_bytes += len;
+	if (ui & MULTICAST_RXDES0)
+		priv->stats.multicast++;
+
+recv_finish:
+	rxdesc->rxdes0.ui = RXDMA_OWN;
+	rxnow++;
+	rxnow &= RX_DESC_NUM_MASK;
+	priv->rx_desc_now = rxnow;
+	if (loops-- > 0)
+		goto repeat_recv;
+}
+
+static irqreturn_t moxart_mac_interrupt(int irq, void *dev_id)
+{
+	struct net_device *ndev = (struct net_device *) dev_id;
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	unsigned int ists = readl(priv->base + ISR_REG_OFFSET);
+
+	if (ists & RPKT_FINISH)
+		moxart_mac_recv((void *) ndev);
+
+	return IRQ_HANDLED;
+}
+
+static int moxart_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	struct tx_desc_t *txdesc;
+	int len;
+	int txnow = priv->tx_desc_now;
+
+	spin_lock_irq(&priv->txlock);
+	txdesc = &priv->virt_tx_desc_baseaddr[txnow];
+	if (txdesc->txdes0.ubit.tx_dma_own) {
+		netdev_err(ndev, "%s: no TX space for packet\n", __func__);
+		priv->stats.tx_dropped++;
+		goto xmit_final;
+	}
+
+	len = skb->len > TX_BUF_SIZE ? TX_BUF_SIZE : skb->len;
+	memcpy(txdesc->txdes2.virt_tx_buf_baseaddr, skb->data, len);
+
+	if (skb->len < ETH_ZLEN) {
+		memset(&txdesc->txdes2.virt_tx_buf_baseaddr[skb->len],
+		       0, ETH_ZLEN - skb->len);
+		len = ETH_ZLEN;
+	}
+
+	txdesc->txdes1.ubit.lts = 1;
+	txdesc->txdes1.ubit.fts = 1;
+	txdesc->txdes1.ubit.tx2_fic = 0;
+	txdesc->txdes1.ubit.tx_ic = 0;
+	txdesc->txdes1.ubit.tx_buf_size = len;
+	txdesc->txdes0.ui = TXDMA_OWN;
+
+	/* start to send packet */
+	writel(0xffffffff, priv->base + TXPD_REG_OFFSET);
+
+	txnow++;
+	txnow &= TX_DESC_NUM_MASK;
+	priv->tx_desc_now = txnow;
+	ndev->trans_start = jiffies;
+	priv->stats.tx_packets++;
+	priv->stats.tx_bytes += len;
+
+xmit_final:
+	spin_unlock_irq(&priv->txlock);
+	dev_kfree_skb_any(skb);
+
+	return NETDEV_TX_OK;
+}
+
+static struct net_device_stats *moxart_mac_get_stats(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	int desc = priv->rx_desc_now;
+
+	desc++;
+	desc &= RX_DESC_NUM_MASK;
+
+	return &priv->stats;
+}
+
+static void moxart_mac_setmulticast(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	struct netdev_hw_addr *ha;
+	int crc_val;
+
+	netdev_for_each_mc_addr(ha, ndev) {
+		crc_val = crc32_le(~0, ha->addr, ETH_ALEN);
+		crc_val = (crc_val >> 26) & 0x3f;
+		if (crc_val >= 32) {
+			writel(readl(priv->base + MATH1_REG_OFFSET) |
+			       (1UL << (crc_val - 32)),
+			       priv->base + MATH1_REG_OFFSET);
+		} else {
+			writel(readl(priv->base + MATH0_REG_OFFSET) |
+			       (1UL << crc_val),
+			       priv->base + MATH0_REG_OFFSET);
+		}
+	}
+}
+
+static void moxart_mac_set_rx_mode(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	spin_lock_irq(&priv->txlock);
+
+	(ndev->flags & IFF_PROMISC) ? (priv->maccr |= RCV_ALL) :
+				      (priv->maccr &= ~RCV_ALL);
+
+	(ndev->flags & IFF_ALLMULTI) ? (priv->maccr |= RX_MULTIPKT) :
+				       (priv->maccr &= ~RX_MULTIPKT);
+
+	if ((ndev->flags & IFF_MULTICAST) && netdev_mc_count(ndev)) {
+		priv->maccr |= HT_MULTI_EN;
+		moxart_mac_setmulticast(ndev);
+	} else {
+		priv->maccr &= ~HT_MULTI_EN;
+	}
+
+	writel(priv->maccr, priv->base + MACCR_REG_OFFSET);
+
+	spin_unlock_irq(&priv->txlock);
+}
+
+static struct net_device_ops moxart_netdev_ops = {
+	.ndo_open		= moxart_mac_open,
+	.ndo_stop		= moxart_mac_stop,
+	.ndo_start_xmit		= moxart_mac_start_xmit,
+	.ndo_get_stats		= moxart_mac_get_stats,
+	.ndo_set_rx_mode	= moxart_mac_set_rx_mode,
+	.ndo_set_mac_address	= moxart_set_mac_address,
+	.ndo_validate_addr	= eth_validate_addr,
+	.ndo_change_mtu		= eth_change_mtu,
+};
+
+static void moxart_get_mac_address(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	int i;
+
+	for (i = 0; i <= 5; i++)
+		ndev->dev_addr[i] = readb(priv->flash_base + i);
+}
+
+static int moxart_mac_probe(struct platform_device *pdev)
+{
+	struct device *p_dev = &pdev->dev;
+	struct device_node *node = p_dev->of_node;
+	struct net_device *ndev;
+	struct moxart_mac_priv_t *priv;
+	struct resource *res;
+	unsigned int irq;
+	void *tmp;
+
+	ndev = alloc_etherdev(sizeof(struct moxart_mac_priv_t));
+	if (!ndev)
+		return -ENOMEM;
+
+	irq = irq_of_parse_and_map(node, 0);
+
+	priv = netdev_priv(ndev);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	ndev->base_addr = res->start;
+	priv->base = devm_ioremap_resource(p_dev, res);
+	if (IS_ERR(priv->base)) {
+		dev_err(p_dev, "%s: devm_ioremap_resource res_mac failed\n",
+			__func__);
+		goto init_fail;
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+
+	/* the flash driver (physmap_of) requests the same region
+	 * so use ioremap instead of devm_ioremap_resource
+	 */
+	priv->flash_base = ioremap(res->start, resource_size(res));
+	if (IS_ERR(priv->flash_base)) {
+		dev_err(p_dev, "%s: devm_ioremap_resource res_flash failed\n",
+			__func__);
+		goto init_fail;
+	}
+
+	spin_lock_init(&priv->txlock);
+
+	tmp = dma_alloc_coherent(NULL, sizeof(struct tx_desc_t) * TX_DESC_NUM,
+				 (dma_addr_t *) &priv->phy_tx_desc_baseaddr,
+				 GFP_DMA | GFP_KERNEL);
+	priv->virt_tx_desc_baseaddr = (struct tx_desc_t *) tmp;
+	if (priv->virt_tx_desc_baseaddr == NULL ||
+	    (priv->phy_tx_desc_baseaddr & 0x0f)) {
+		netdev_err(ndev, "TX descriptor alloc failed\n");
+		goto init_fail;
+	}
+
+	tmp = dma_alloc_coherent(NULL, sizeof(struct rx_desc_t) * RX_DESC_NUM,
+				 (dma_addr_t *)&priv->phy_rx_desc_baseaddr,
+				 GFP_DMA | GFP_KERNEL);
+	priv->virt_rx_desc_baseaddr = (struct rx_desc_t *) tmp;
+	if (priv->virt_rx_desc_baseaddr == NULL ||
+	    (priv->phy_rx_desc_baseaddr & 0x0f)) {
+		netdev_err(ndev, "RX descriptor alloc failed\n");
+		goto init_fail;
+	}
+
+	tmp = dma_alloc_coherent(NULL, TX_BUF_SIZE * TX_DESC_NUM,
+				 (dma_addr_t *)&priv->phy_tx_buf_baseaddr,
+				 GFP_DMA | GFP_KERNEL);
+	priv->virt_tx_buf_baseaddr = (unsigned char *) tmp;
+	if (priv->virt_tx_buf_baseaddr == NULL ||
+	    (priv->phy_tx_buf_baseaddr & 0x03)) {
+		netdev_err(ndev, "TX buffer alloc failed\n");
+		goto init_fail;
+	}
+
+	tmp = dma_alloc_coherent(NULL, RX_BUF_SIZE * RX_DESC_NUM,
+				 (dma_addr_t *)&priv->phy_rx_buf_baseaddr,
+				 GFP_DMA | GFP_KERNEL);
+	priv->virt_rx_buf_baseaddr = (unsigned char *) tmp;
+	if (priv->virt_rx_buf_baseaddr == NULL ||
+	    (priv->phy_rx_buf_baseaddr & 0x03)) {
+		netdev_err(ndev, "RX buffer alloc failed\n");
+		goto init_fail;
+	}
+
+	platform_set_drvdata(pdev, ndev);
+
+	ether_setup(ndev);
+	ndev->netdev_ops = &moxart_netdev_ops;
+	ndev->priv_flags |= IFF_UNICAST_FLT;
+
+	SET_NETDEV_DEV(ndev, &pdev->dev);
+
+	moxart_get_mac_address(ndev);
+	moxart_update_mac_address(ndev);
+
+	if (register_netdev(ndev)) {
+		free_netdev(ndev);
+		goto init_fail;
+	}
+
+	ndev->irq = irq;
+
+	if (devm_request_irq(p_dev, irq, moxart_mac_interrupt, 0,
+			     pdev->name, ndev)) {
+		netdev_err(ndev, "%s: devm_request_irq failed\n", __func__);
+		free_netdev(ndev);
+		return -EBUSY;
+	}
+
+	netdev_dbg(ndev, "%s: IRQ=%d address=%02x:%02x:%02x:%02x:%02x:%02x\n",
+		   __func__, ndev->irq,
+		   ndev->dev_addr[0], ndev->dev_addr[1], ndev->dev_addr[2],
+		   ndev->dev_addr[3], ndev->dev_addr[4], ndev->dev_addr[5]);
+
+	return 0;
+
+init_fail:
+	netdev_err(ndev, "%s: init failed\n", __func__);
+	moxart_mac_free_memory(ndev);
+
+	return -ENOMEM;
+}
+
+static int moxart_remove(struct platform_device *pdev)
+{
+	struct net_device *ndev = platform_get_drvdata(pdev);
+
+	unregister_netdev(ndev);
+	free_irq(ndev->irq, ndev);
+	moxart_mac_free_memory(ndev);
+	platform_set_drvdata(pdev, NULL);
+	free_netdev(ndev);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_mac_match[] = {
+	{ .compatible = "moxa,moxart-mac" },
+	{ }
+};
+
+struct __initdata platform_driver moxart_mac_driver = {
+	.probe	= moxart_mac_probe,
+	.remove	= moxart_remove,
+	.driver	= {
+		.name		= "moxart-ethernet",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_mac_match,
+	},
+};
+module_platform_driver(moxart_mac_driver);
+
+MODULE_DESCRIPTION("MOXART RTL8201CP Ethernet driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
+
diff --git a/drivers/net/ethernet/moxa/moxart_ether.h b/drivers/net/ethernet/moxa/moxart_ether.h
new file mode 100644
index 0000000..9c477f6
--- /dev/null
+++ b/drivers/net/ethernet/moxa/moxart_ether.h
@@ -0,0 +1,525 @@
+/* MOXA ART Ethernet (RTL8201CP) driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _MOXART_ETHERNET_H
+#define _MOXART_ETHERNET_H
+
+#define TX_DESC_NUM		64
+#define TX_DESC_NUM_MASK	(TX_DESC_NUM-1)
+#define RX_DESC_NUM		64
+#define RX_DESC_NUM_MASK	(RX_DESC_NUM-1)
+#define TX_BUF_SIZE		1600
+#define RX_BUF_SIZE		1600
+
+struct tx_desc_t {
+	union {
+#define TXDMA_OWN		BIT(31)
+#define TXPKT_EXSCOL		BIT(1)
+#define TXPKT_LATECOL		BIT(0)
+		unsigned int ui;
+
+		struct {
+			/* is aborted due to late collision */
+			unsigned int tx_pkt_late_col:1;
+
+			/* is aborted after 16 collisions */
+			unsigned int rx_pkt_exs_col:1;
+
+			unsigned int reserved1:29;
+
+			/* is owned by the MAC controller */
+			unsigned int tx_dma_own:1;
+		} ubit;
+	} txdes0;
+
+	union {
+#define EDOTR			BIT(31)
+#define TXIC			BIT(30)
+#define TX2FIC			BIT(29)
+#define FTS			BIT(28)
+#define LTS			BIT(27)
+#define TXBUF_SIZE_MASK		0x7ff
+#define TXBUF_SIZE_MAX		(TXBUF_SIZE_MASK+1)
+		unsigned int ui;
+
+		struct {
+			/* transmit buffer size in byte */
+			unsigned int tx_buf_size:11;
+
+			unsigned int reserved2:16;
+
+			/* is the last descriptor of a Tx packet */
+			unsigned int lts:1;
+
+			/* is the first descriptor of a Tx packet */
+			unsigned int fts:1;
+
+			/* transmit to FIFO interrupt on completion */
+			unsigned int tx2_fic:1;
+
+			/* transmit interrupt on completion */
+			unsigned int tx_ic:1;
+
+			/* end descriptor of transmit ring */
+			unsigned int edotr:1;
+		} ubit;
+	} txdes1;
+
+	struct {
+		/* transmit buffer physical base address */
+		unsigned int phy_tx_buf_baseaddr;
+
+		/* transmit buffer virtual base address */
+		unsigned char *virt_tx_buf_baseaddr;
+	} txdes2;
+};
+
+struct rx_desc_t {
+	union {
+#define RXDMA_OWN		BIT(31)
+#define FRS			BIT(29)
+#define LRS			BIT(28)
+#define RX_ODD_NB		BIT(22)
+#define RUNT			BIT(21)
+#define FTL			BIT(20)
+#define CRC_ERR			BIT(19)
+#define RX_ERR			BIT(18)
+#define BROADCAST_RXDES0	BIT(17)
+#define MULTICAST_RXDES0	BIT(16)
+#define RFL_MASK		0x7ff
+#define RFL_MAX			(RFL_MASK+1)
+		unsigned int ui;
+
+		struct {
+			/* receive frame length */
+			unsigned int recv_frame_len:11;
+			unsigned int reserved1:5;
+
+			/* multicast frame */
+			unsigned int multicast:1;
+
+			/* broadcast frame */
+			unsigned int broadcast:1;
+			unsigned int rx_err:1;		/* receive error */
+			unsigned int crc_err:1;		/* CRC error */
+			unsigned int ftl:1;		/* frame too long */
+
+			/* runt packet, less than 64 bytes */
+			unsigned int runt:1;
+
+			/* receive odd nibbles */
+			unsigned int rx_odd_nb:1;
+			unsigned int reserved2:5;
+
+			/* last receive segment descriptor */
+			unsigned int lrs:1;
+
+			/* first receive segment descriptor */
+			unsigned int frs:1;
+
+			unsigned int reserved3:1;
+			unsigned int rx_dma_own:1;	/* RXDMA onwership */
+		} ubit;
+	} rxdes0;
+
+	union {
+#define EDORR			BIT(31)
+#define RXBUF_SIZE_MASK		0x7ff
+#define RXBUF_SIZE_MAX		(RXBUF_SIZE_MASK+1)
+		unsigned int ui;
+
+		struct {
+			/* receive buffer size */
+			unsigned int rx_buf_size:11;
+
+			unsigned int reserved4:20;
+
+			/* end descriptor of receive ring */
+			unsigned int edorr:1;
+		} ubit;
+	} rxdes1;
+
+	struct {
+		/* receive buffer physical base address */
+		unsigned int phy_rx_buf_baseaddr;
+
+		/* receive buffer virtual base address */
+		unsigned char *virt_rx_buf_baseaddr;
+	} rxdes2;
+};
+
+struct mac_control_reg_t {
+
+/* RXDMA has received packets into RX buffer successfully */
+#define RPKT_FINISH		BIT(0)
+/* receive buffer unavailable */
+#define NORXBUF			BIT(1)
+/* TXDMA has moved data into the TX FIFO */
+#define XPKT_FINISH		BIT(2)
+/* transmit buffer unavailable */
+#define NOTXBUF			BIT(3)
+/* packets transmitted to ethernet successfully */
+#define XPKT_OK_INT_STS		BIT(4)
+/* packets transmitted to ethernet lost due to late
+ * collision or excessive collision
+ */
+#define XPKT_LOST_INT_STS	BIT(5)
+/* packets received into RX FIFO successfully */
+#define RPKT_SAV		BIT(6)
+/* received packet lost due to RX FIFO full */
+#define RPKT_LOST_INT_STS	BIT(7)
+#define AHB_ERR			BIT(8)		/* AHB error */
+#define PHYSTS_CHG		BIT(9)		/* PHY link status change */
+	unsigned int isr;			/* interrupt status, 0x0 */
+
+#define RPKT_FINISH_M		BIT(0)		/* interrupt mask of ISR[0] */
+#define NORXBUF_M		BIT(1)		/* interrupt mask of ISR[1] */
+#define XPKT_FINISH_M		BIT(2)		/* interrupt mask of ISR[2] */
+#define NOTXBUF_M		BIT(3)		/* interrupt mask of ISR[3] */
+#define XPKT_OK_M		BIT(4)		/* interrupt mask of ISR[4] */
+#define XPKT_LOST_M		BIT(5)		/* interrupt mask of ISR[5] */
+#define RPKT_SAV_M		BIT(6)		/* interrupt mask of ISR[6] */
+#define RPKT_LOST_M		BIT(7)		/* interrupt mask of ISR[7] */
+#define AHB_ERR_M		BIT(8)		/* interrupt mask of ISR[8] */
+#define PHYSTS_CHG_M		BIT(9)		/* interrupt mask of ISR[9] */
+	unsigned int imr;			/* interrupt mask, 0x4 */
+
+/* the most significant 2 bytes of MAC address */
+#define MAC_MADR_MASK		0xffff
+	/* MAC most significant address, 0x8 */
+	unsigned int mac_madr;
+
+	/* MAC least significant address, 0xc */
+	unsigned int mac_ldar;
+
+	/* multicast address hash table 0, 0x10 */
+	unsigned int matht0;
+
+	/* multicast address hash table 1, 0x14 */
+	unsigned int matht1;
+
+	/* transmit poll demand, 0x18 */
+	unsigned int txpd;
+
+	/* receive poll demand, 0x1c */
+	unsigned int rxpd;
+
+	/* transmit ring base address, 0x20 */
+	unsigned int txr_badr;
+
+	/* receive ring base address, 0x24 */
+	unsigned int rxr_badr;
+
+/* defines the period of TX cycle time */
+#define TXINT_TIME_SEL		BIT(15)
+#define TXINT_THR_MASK		0x7000
+#define TXINT_CNT_MASK		0xf00
+/* defines the period of RX cycle time */
+#define RXINT_TIME_SEL		BIT(7)
+#define RXINT_THR_MASK		0x70
+#define RXINT_CNT_MASK		0xF
+	/* interrupt timer control, 0x28 */
+	unsigned int itc;
+
+/* defines the period of TX poll time */
+#define TXPOLL_TIME_SEL		BIT(12)
+#define TXPOLL_CNT_MASK		0xf00
+#define TXPOLL_CNT_SHIFT_BIT	8
+/* defines the period of RX poll time */
+#define RXPOLL_TIME_SEL		BIT(4)
+#define RXPOLL_CNT_MASK		0xF
+#define RXPOLL_CNT_SHIFT_BIT	0
+	/* automatic polling timer control, 0x2c */
+	unsigned int aptc;
+
+/* enable RX FIFO threshold arbitration */
+#define RX_THR_EN		BIT(9)
+#define RXFIFO_HTHR_MASK	0x1c0
+#define RXFIFO_LTHR_MASK	0x38
+/* use INCR16 burst command in AHB bus */
+#define INCR16_EN		BIT(2)
+/* use INCR8 burst command in AHB bus */
+#define INCR8_EN		BIT(1)
+/* use INCR4 burst command in AHB bus */
+#define INCR4_EN		BIT(0)
+	/* DMA burst length and arbitration control, 0x30 */
+	unsigned int dblac;
+
+	unsigned int reserved1[21];		/* 0x34 - 0x84 */
+
+#define RX_BROADPKT		BIT(17)		/* receive boradcast packet */
+/* receive all multicast packet */
+#define RX_MULTIPKT		BIT(16)
+#define FULLDUP			BIT(15)		/* full duplex */
+/* append CRC to transmitted packet */
+#define CRC_APD			BIT(14)
+/* do not check incoming packet's destination address */
+#define RCV_ALL			BIT(12)
+/* store incoming packet even if its length is great than 1518 bytes */
+#define RX_FTL			BIT(11)
+/* store incoming packet even if its length is less than 64 bytes */
+#define RX_RUNT			BIT(10)
+/* enable storing incoming packet if the packet passes hash table
+ * address filtering and is a multicast packet
+ */
+#define HT_MULTI_EN		BIT(9)
+#define RCV_EN			BIT(8)		/* receiver enable */
+/* enable packet reception when transmitting packet in half duplex mode */
+#define ENRX_IN_HALFTX		BIT(6)
+#define XMT_EN			BIT(5)		/* transmitter enable */
+/* disable CRC check when receiving packets */
+#define CRC_DIS			BIT(4)
+#define LOOP_EN			BIT(3)		/* internal loop-back */
+/* software reset, last 64 AHB bus clocks */
+#define SW_RST			BIT(2)
+#define RDMA_EN			BIT(1)		/* enable receive DMA chan */
+#define XDMA_EN			BIT(0)		/* enable transmit DMA chan */
+	unsigned int maccr;			/* MAC control, 0x88 */
+
+#define COL_EXCEED		BIT(11)		/* collisions exceeds 16 */
+/* transmitter detects late collision */
+#define LATE_COL		BIT(10)
+/* packet transmitted to ethernet lost due to late collision
+ * or excessive collision
+ */
+#define XPKT_LOST		BIT(9)
+/* packets transmitted to ethernet successfully */
+#define XPKT_OK			BIT(8)
+/* receiver detects a runt packet */
+#define RUNT_MAC_STS		BIT(7)
+/* receiver detects a frame that is too long */
+#define FTL_MAC_STS		BIT(6)
+#define CRC_ERR_MAC_STS		BIT(5)
+/* received packets list due to RX FIFO full */
+#define RPKT_LOST		BIT(4)
+/* packets received into RX FIFO successfully */
+#define RPKT_SAVE		BIT(3)
+/* incoming packet dropped due to collision */
+#define COL			BIT(2)
+#define MCPU_BROADCAST		BIT(1)
+#define MCPU_MULTICAST		BIT(0)
+	unsigned int macsr;			/* MAC status, 0x8c */
+
+/* initialize a write sequence to PHY by setting this bit to 1
+ * this bit would be auto cleared after the write operation is finished.
+ */
+#define MIIWR			BIT(27)
+#define MIIRD			BIT(26)
+#define REGAD_MASK		0x3e00000
+#define PHYAD_MASK		0x1f0000
+#define MIIRDATA_MASK		0xffff
+	unsigned int phycr;			/* PHY control, 0x90 */
+
+#define MIIWDATA_MASK		0xffff
+	unsigned int phywdata;			/* PHY write data, 0x94 */
+
+#define PAUSE_TIME_MASK		0xffff0000
+#define FC_HIGH_MASK		0xf000
+#define FC_LOW_MASK		0xf00
+#define RX_PAUSE		BIT(4)		/* receive pause frame */
+/* packet transmission is paused due to receive */
+#define TXPAUSED		BIT(3)
+	/* pause frame */
+/* enable flow control threshold mode. */
+#define FCTHR_EN		BIT(2)
+#define TX_PAUSE		BIT(1)		/* transmit pause frame */
+#define FC_EN			BIT(0)		/* flow control mode enable */
+	unsigned int fcr;			/* flow control, 0x98 */
+
+#define BK_LOW_MASK		0xf00
+#define BKJAM_LEN_MASK		0xf0
+#define BK_MODE			BIT(1)		/* back pressure address mode */
+#define BK_EN			BIT(0)		/* back pressure mode enable */
+	unsigned int bpr;			/* back pressure, 0x9c */
+
+	unsigned int reserved2[9];		/* 0xa0 - 0xc0 */
+
+#define TEST_SEED_MASK      0x3fff
+	unsigned int ts;			/* test seed, 0xc4 */
+
+#define TXD_REQ			BIT(31)		/* TXDMA request */
+#define RXD_REQ			BIT(30)		/* RXDMA request */
+#define DARB_TXGNT		BIT(29)		/* TXDMA grant */
+#define DARB_RXGNT		BIT(28)		/* RXDMA grant */
+#define TXFIFO_EMPTY		BIT(27)		/* TX FIFO is empty */
+#define RXFIFO_EMPTY		BIT(26)		/* RX FIFO is empty */
+#define TXDMA2_SM_MASK		0x7000
+#define TXDMA1_SM_MASK		0xf00
+#define RXDMA2_SM_MASK		0x70
+#define RXDMA1_SM_MASK		0xF
+	unsigned int dmafifos;			/* DMA/FIFO state, 0xc8 */
+
+#define SINGLE_PKT		BIT(26)		/* single packet mode */
+/* automatic polling timer test mode */
+#define PTIMER_TEST		BIT(25)
+#define ITIMER_TEST		BIT(24)		/* interrupt timer test mode */
+#define TEST_SEED_SEL		BIT(22)		/* test seed select */
+#define SEED_SEL		BIT(21)		/* seed select */
+#define TEST_MODE		BIT(20)		/* transmission test mode */
+#define TEST_TIME_MASK		0xffc00
+#define TEST_EXCEL_MASK		0x3e0
+	unsigned int tm;			/* test mode, 0xcc */
+
+	unsigned int reserved3;			/* 0xd0 */
+
+#define TX_MCOL_MASK		0xffff0000
+#define TX_MCOL_SHIFT_BIT	16
+#define TX_SCOL_MASK		0xffff
+#define TX_SCOL_SHIFT_BIT	0
+	/* TX_MCOL and TX_SCOL counter, 0xd4 */
+	unsigned int txmcol_xscol;
+
+#define RPF_MASK		0xffff0000
+#define RPF_SHIFT_BIT		16
+#define AEP_MASK		0xffff
+#define AEP_SHIFT_BIT		0
+	unsigned int rpf_aep;			/* RPF and AEP counter, 0xd8 */
+
+#define XM_MASK			0xffff0000
+#define XM_SHIFT_BIT		16
+#define PG_MASK			0xffff
+#define PG_SHIFT_BIT		0
+	unsigned int xm_pg;			/* XM and PG counter, 0xdc */
+
+#define RUNT_CNT_MASK		0xffff0000
+#define RUNT_CNT_SHIFT_BIT	16
+#define TLCC_MASK		0xffff
+#define TLCC_SHIFT_BIT		0
+	/* RUNT_CNT and TLCC counter, 0xe0 */
+	unsigned int runtcnt_tlcc;
+
+#define CRCER_CNT_MASK		0xffff0000
+#define CRCER_CNT_SHIFT_BIT	16
+#define FTL_CNT_MASK		0xffff
+#define FTL_CNT_SHIFT_BIT	0
+	/* CRCER_CNT and FTL_CNT counter, 0xe4 */
+	unsigned int crcercnt_ftlcnt;
+
+#define RLC_MASK		0xffff0000
+#define RLC_SHIFT_BIT		16
+#define RCC_MASK		0xffff
+#define RCC_SHIFT_BIT		0
+	unsigned int rlc_rcc;		/* RLC and RCC counter, 0xe8 */
+
+	unsigned int broc;		/* BROC counter, 0xec */
+	unsigned int mulca;		/* MULCA counter, 0xf0 */
+	unsigned int rp;		/* RP counter, 0xf4 */
+	unsigned int xp;		/* XP counter, 0xf8 */
+};
+
+#define ISR_REG_OFFSET			0x0
+#define IMR_REG_OFFSET			0x4
+#define MAC_MADR_REG_OFFSET		0x8
+#define MAC_LADR_REG_OFFSET		0xC
+#define MATH0_REG_OFFSET		0x10
+#define MATH1_REG_OFFSET		0x14
+#define TXPD_REG_OFFSET			0x18
+#define RXPD_REG_OFFSET			0x1C
+#define TXR_BADR_REG_OFFSET		0x20
+#define RXR_BADR_REG_OFFSET		0x24
+#define ITC_REG_OFFSET			0x28
+#define APTC_REG_OFFSET			0x2C
+#define DBLAC_REG_OFFSET		0x30
+#define MACCR_REG_OFFSET		0x88
+#define MACSR_REG_OFFSET		0x8C
+#define PHYCR_REG_OFFSET		0x90
+#define PHYWDATA_REG_OFFSET		0x94
+#define FCR_REG_OFFSET			0x98
+#define BPR_REG_OFFSET			0x9C
+#define TS_REG_OFFSET			0xC4
+#define DMAFIFOS_REG_OFFSET		0xC8
+#define TM_REG_OFFSET			0xCC
+#define TX_MCOL_TX_SCOL_REG_OFFSET	0xD4
+#define RPF_AEP_REG_OFFSET		0xD8
+#define XM_PG_REG_OFFSET		0xDC
+#define RUNT_CNT_TLCC_REG_OFFSET	0xE0
+#define CRCER_CNT_FTL_CNT_REG_OFFSET	0xE4
+#define RLC_RCC_REG_OFFSET		0xE8
+#define BROC_REG_OFFSET			0xEC
+#define MULCA_REG_OFFSET		0xF0
+#define RP_REG_OFFSET			0xF4
+#define XP_REG_OFFSET			0xF8
+#define PHY_CNTL_REG			0x0
+#define PHY_STATUS_REG			0x1
+#define PHY_ID_REG1			0x2
+#define PHY_ID_REG2			0x3
+#define PHY_ANA_REG			0x4
+#define PHY_ANLPAR_REG			0x5
+#define PHY_ANE_REG			0x6
+#define PHY_ECNTL_REG1			0x10
+#define PHY_QPDS_REG			0x11
+#define PHY_10BOP_REG			0x12
+#define PHY_ECNTL_REG2			0x13
+#define FTMAC100_REG_PHY_WRITE		0x8000000
+#define FTMAC100_REG_PHY_READ		0x4000000
+
+/* PHY Status register */
+#define AN_COMPLETE			0x20
+
+#define LINK_STATUS			0x4
+
+struct moxart_mac_priv_t {
+	void __iomem *base;
+	void __iomem *flash_base;
+
+	/* Tx descriptor physical base address */
+	unsigned int phy_tx_desc_baseaddr;
+
+	/* Tx descriptor virtual base address */
+	struct tx_desc_t *virt_tx_desc_baseaddr;
+
+	/* Rx descriptor physical base address */
+	unsigned int phy_rx_desc_baseaddr;
+
+	/* Rx descriptor virtual base address */
+	struct rx_desc_t *virt_rx_desc_baseaddr;
+
+	/* Tx buffer physical base address */
+	unsigned int phy_tx_buf_baseaddr;
+
+	/* Tx buffer virtual base address */
+	unsigned char *virt_tx_buf_baseaddr;
+
+	/* Rx buffer physical base address */
+	unsigned int phy_rx_buf_baseaddr;
+
+	/* Rx buffer virtual base address */
+	unsigned char *virt_rx_buf_baseaddr;
+
+	/* Tx descriptor now first used index */
+	int tx_desc_now;
+
+	/* Rx descriptor now first used index */
+	int rx_desc_now;
+
+	/* OS about the ethernet statistics */
+	struct net_device_stats stats;
+
+	spinlock_t txlock;
+	spinlock_t rxlock;
+
+	/* store the maccr control register value */
+	unsigned int maccr;
+
+	struct work_struct rqueue;
+};
+
+#if TX_BUF_SIZE >= TXBUF_SIZE_MAX
+#error MOXA ART Ethernet device driver Tx buffer size too large !
+#endif
+#if RX_BUF_SIZE >= RXBUF_SIZE_MAX
+#error MOXA ART Ethernet device driver Rx buffer size too large !
+#endif
+
+#endif
-- 
1.8.2.1



From lars at metafoo.de  Thu Jul 18 05:48:10 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Thu, 18 Jul 2013 11:48:10 +0200
Subject: [PATCH v5 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <CAPb7_muAzO-jRqgcm89fcKT-hTLq38Aj2p0WAWjGjN9DoQUwPg@mail.gmail.com>
References: <1374059564-6872-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1374059564-6872-3-git-send-email-oleksandr.kozaruk@ti.com>
 <51E6DCB5.3070302@metafoo.de>
 <CAPb7_muAzO-jRqgcm89fcKT-hTLq38Aj2p0WAWjGjN9DoQUwPg@mail.gmail.com>
Message-ID: <51E7B9DA.9040803@metafoo.de>

On 07/18/2013 10:36 AM, Oleksandr Kozaruk wrote:
> Hello Lars,
> 
> On Wed, Jul 17, 2013 at 9:04 PM, Lars-Peter Clausen <lars at metafoo.de> wrote:
>>> +static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
>>> +{
>>> +     int chn, d1 = 0, d2 = 0, temp;
>>> +     u8 trim_regs[17];
>>> +     int ret;
>>> +
>>> +     ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
>>> +                     TWL6030_GPADC_TRIM1, 16);
>>> +     if (ret < 0) {
>>> +             dev_err(gpadc->dev, "calibration failed\n");
>>> +             return ret;
>>> +     }
>>> +
>>> +     /*
>>> +      * Loop to calculate the value needed for returning voltages from
>>> +      * GPADC not values.
>>> +      *
>>> +      * gain is calculated to 3 decimal places fixed point.
>>> +      */
>>> +     for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
>>> +
>>> +             switch (chn) {
>>> +             case 0:
>>> +             case 1:
>>> +             case 2:
>>> +             case 3:
>>> +             case 4:
>>> +             case 5:
>>> +             case 6:
>>> +             case 11:
>>> +             case 12:
>>> +             case 13:
>>> +             case 14:
>>> +                     /* D1 */
>>> +                     d1 = (trim_regs[3] & 0x1F) << 2;
>>> +                     d1 |= (trim_regs[1] & 0x06) >> 1;
>>> +                     if (trim_regs[1] & 0x01)
>>> +                             d1 = -d1;
>>> +
>>> +                     /* D2 */
>>> +                     d2 = (trim_regs[4] & 0x3F) << 2;
>>> +                     d2 |= (trim_regs[2] & 0x06) >> 1;
>>> +                     if (trim_regs[2] & 0x01)
>>> +                             d2 = -d2;
>>> +                     break;
>>> +             case 8:
>>> +                     /* D1 */
>>> +                     temp = (trim_regs[3] & 0x1F) << 2;
>>> +                     temp |= (trim_regs[1] & 0x06) >> 1;
>>> +                     if (trim_regs[1] & 0x01)
>>> +                             temp = -temp;
>>> +
>>> +                     d1 = (trim_regs[8] & 0x18) << 1;
>>> +                     d1 |= (trim_regs[7] & 0x1E) >> 1;
>>> +                     if (trim_regs[7] & 0x01)
>>> +                             d1 = -d1;
>>> +
>>> +                     d1 += temp;
>>> +
>>> +                     /* D2 */
>>> +                     temp = (trim_regs[4] & 0x3F) << 2;
>>> +                     temp |= (trim_regs[2] & 0x06) >> 1;
>>> +                     if (trim_regs[2] & 0x01)
>>> +                             temp = -temp;
>>> +
>>> +                     d2 = (trim_regs[10] & 0x1F) << 2;
>>> +                     d2 |= (trim_regs[8] & 0x06) >> 1;
>>> +                     if (trim_regs[8] & 0x01)
>>> +                             d2 = -d2;
>>> +
>>> +                     d2 += temp;
>>> +                     break;
>>> +             case 9:
>>> +                     /* D1 */
>>> +                     temp = (trim_regs[3] & 0x1F) << 2;
>>> +                     temp |= (trim_regs[1] & 0x06) >> 1;
>>> +                     if (trim_regs[1] & 0x01)
>>> +                             temp = -temp;
>>> +
>>> +                     d1 = (trim_regs[14] & 0x18) << 1;
>>> +                     d1 |= (trim_regs[12] & 0x1E) >> 1;
>>> +                     if (trim_regs[12] & 0x01)
>>> +                             d1 = -d1;
>>> +
>>> +                     d1 += temp;
>>> +
>>> +                     /* D2 */
>>> +                     temp = (trim_regs[4] & 0x3F) << 2;
>>> +                     temp |= (trim_regs[2] & 0x06) >> 1;
>>> +                     if (trim_regs[2] & 0x01)
>>> +                             temp = -temp;
>>> +
>>> +                     d2 = (trim_regs[16] & 0x1F) << 2;
>>> +                     d2 |= (trim_regs[14] & 0x06) >> 1;
>>> +                     if (trim_regs[14] & 0x01)
>>> +                             d2 = -d2;
>>> +
>>> +                     d2 += temp;
>>> +             case 10:
>>> +                     /* D1 */
>>> +                     d1 = (trim_regs[11] & 0x0F) << 3;
>>> +                     d1 |= (trim_regs[9] & 0x0E) >> 1;
>>> +                     if (trim_regs[9] & 0x01)
>>> +                             d1 = -d1;
>>> +
>>> +                     /* D2 */
>>> +                     d2 = (trim_regs[15] & 0x0F) << 3;
>>> +                     d2 |= (trim_regs[13] & 0x0E) >> 1;
>>> +                     if (trim_regs[13] & 0x01)
>>> +                             d2 = -d2;
>>> +                     break;
>>> +             case 7:
>>> +             case 18:
>>> +                     /* D1 */
>>> +                     temp = (trim_regs[3] & 0x1F) << 2;
>>> +                     temp |= (trim_regs[1] & 0x06) >> 1;
>>> +                     if (trim_regs[1] & 0x01)
>>> +                             temp = -temp;
>>> +
>>> +                     d1 = (trim_regs[5] & 0x7E) >> 1;
>>> +                     if (trim_regs[5] & 0x01)
>>> +                             d1 = -d1;
>>> +.
>>> +                     d1 += temp;
>>> +
>>> +                     /* D2 */
>>> +                     temp = (trim_regs[4] & 0x3F) << 2;
>>> +                     temp |= (trim_regs[2] & 0x06) >> 1;
>>> +                     if (trim_regs[2] & 0x01)
>>> +                             temp = -temp;
>>> +
>>> +                     d2 = (trim_regs[6] & 0xFE) >> 1;
>>> +                     if (trim_regs[6] & 0x01)
>>> +                             d2 = -d2;
>>> +
>>> +                     d2 += temp;
>>> +                     break;
>>
>>
>> There is quite a bit of copy paste in here. Putting the bit swizziling into
>> a helper function should also improbe legibility.
> 
> Trimming bits are scattered randomly between registers and in
> different bit positions.
> I don't see any commonalities, that could be generalized. as Graeme
> said about it "it's a bane of my life".

The pattern is pretty regular though, how about:


int twl6032_get_trim_value(u8 *trim_regs, unsigned int reg0,
	unsigned int reg1, unsigned int mask0, unsigned int mask1,
	unsigned int shift0)
{
	int val;

	val = (trim_regs[reg0] & mask0) << shift0;
	val |= (trim_regs[reg1] & mask1) >> 1;
	if (trim_regs[reg1] & 0x01)
		val = -val;

	return val;
}

and then

	d1 = twl6032_get_trim_value(trim_regs, 3, 1, 0x1f, 0x06, 2);
	d2 = twl6032_get_trim_value(trim_regs, 4, 2, 0x3f, 0x06, 2);

and so on.


From mark.rutland at arm.com  Thu Jul 18 05:50:35 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 18 Jul 2013 10:50:35 +0100
Subject: [PATCH v3] clk: add MOXA ART SoCs clock driver
In-Reply-To: <1374067396-30155-1-git-send-email-jonas.jensen@gmail.com>
References: <1372943292-6960-1-git-send-email-jonas.jensen@gmail.com>
 <1374067396-30155-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <20130718095035.GA29153@e106331-lin.cambridge.arm.com>

On Wed, Jul 17, 2013 at 02:23:16PM +0100, Jonas Jensen wrote:
> This patch adds MOXA ART SoCs clock driver support.
> 
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
> ---
> 
> Notes:
>     Changes since v2:
>     
>     1. add devicetree bindings document
>     
>     Applies to next-20130716
> 
>  .../bindings/clock/moxa,moxart-core-clock.txt      | 19 +++++
>  drivers/clk/Makefile                               |  1 +
>  drivers/clk/clk-moxart.c                           | 82 ++++++++++++++++++++++
>  3 files changed, 102 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
>  create mode 100644 drivers/clk/clk-moxart.c
> 
> diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
> new file mode 100644
> index 0000000..cf69361
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
> @@ -0,0 +1,19 @@
> +Device Tree Clock bindings for arch-moxart
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +MOXA ART SoCs allow to determine core clock frequencies by reading
> +a register.
> +
> +Required properties:
> +- compatible : Should be "moxa,moxart-core-clock"
> +- reg : Should contain registers location and length
> +
> +For example:
> +
> +	clk: core-clock at 98100000 {
> +		compatible = "moxa,moxart-core-clock";
> +		reg = <0x98100000 0x34>;
> +	};
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 4038c2b..933622f 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_COMMON_CLK)	+= clk-composite.o
>  
>  # SoCs specific
>  obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
> +obj-$(CONFIG_ARCH_MOXART)	+= clk-moxart.o
>  obj-$(CONFIG_ARCH_NOMADIK)	+= clk-nomadik.o
>  obj-$(CONFIG_ARCH_HIGHBANK)	+= clk-highbank.o
>  obj-$(CONFIG_ARCH_NSPIRE)	+= clk-nspire.o
> diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
> new file mode 100644
> index 0000000..79c27f4
> --- /dev/null
> +++ b/drivers/clk/clk-moxart.c
> @@ -0,0 +1,82 @@
> +/*
> + * MOXA ART SoCs clock driver.
> + *
> + * Copyright (C) 2013 Jonas Jensen
> + *
> + * Jonas Jensen <jonas.jensen at gmail.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/slab.h>
> +#include <linux/delay.h>
> +#include <linux/module.h>
> +#include <linux/io.h>
> +#include <linux/of_address.h>
> +#include <linux/clkdev.h>
> +
> +static const struct of_device_id moxart_apb_clock_match[] = {
> +	{ .compatible = "moxa,moxart-apb-clock" },
> +	{ }
> +};
> +
> +void __init moxart_of_clk_init(struct device_node *node)
> +{
> +	static void __iomem *base;
> +	struct device_node *clk_node;
> +	struct clk *clk;
> +	unsigned long rate;
> +	unsigned int mul, val, div;
> +
> +	base = of_iomap(node, 0);
> +	if (IS_ERR(base))
> +		panic("%s: of_iomap failed\n", node->full_name);
> +
> +	clk_node = of_find_matching_node(NULL, moxart_apb_clock_match);
> +	if (!clk_node)
> +		panic("%s: can't find clock DT node\n", node->full_name);
> +
> +	mul = (readl(base + 0x30) >> 3) & 0x1ff;
> +	val = (readl(base + 0x0c) >> 4) & 0x7;
> +
> +	switch (val) {
> +	case 1:
> +		div = 3;
> +		break;
> +	case 2:
> +		div = 4;
> +		break;
> +	case 3:
> +		div = 6;
> +		break;
> +	case 4:
> +		div = 8;
> +		break;
> +	default:
> +		div = 2;
> +		break;
> +	}
> +
> +	/*
> +	 * the rate calculation below is only tested and proven
> +	 * to be true for UC-7112-LX
> +	 *
> +	 * UC-7112-LX: mul=80 val=0
> +	 *
> +	 * to support other moxart SoC hardware, this may need
> +	 * a change, though it's possible it works there too
> +	 */
> +	rate = (mul * 1200000 / div);
> +
> +	clk = clk_register_fixed_rate(NULL, "clkapb", NULL, CLK_IS_ROOT, rate);
> +	clk_register_clkdev(clk, NULL, "clkapb");
> +	of_clk_add_provider(clk_node, of_clk_src_simple_get, clk);

This confuses me. moxart_of_clk_init gets called because there was a
"moxa,moxart-core-clock", node in the dt, but the driver only seems to
use the information to figure out the configuration of another clock
("moxa,moxart-apb-clock"), and never registers a clock specifically for
the core-clock.

I couldn't find "moxa,moxart-apb-clock" described in mainline. COuld you
describe the relationship between core-clock and apb-clock?

Thanks,
Mark.

> +
> +	iounmap(base);
> +}
> +CLK_OF_DECLARE(moxart_core_clock, "moxa,moxart-core-clock", moxart_of_clk_init);
> -- 
> 1.8.2.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From broonie at kernel.org  Thu Jul 18 05:53:37 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Jul 2013 10:53:37 +0100
Subject: [PATCH v4 5/5] ASoC: atmel-ssc: remove clk_disable_unprepare
 call from critical section
In-Reply-To: <1374133720-27362-1-git-send-email-b.brezillon@overkiz.com>
References: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
 <1374133720-27362-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <20130718095337.GD22506@sirena.org.uk>

On Thu, Jul 18, 2013 at 09:48:40AM +0200, Boris BREZILLON wrote:
> clk_prepare/unprepare (and indirectly clk_prepare_enable/disable_unprepare)
> may sleep and thus cannot be called in critical section.

I'm missing patches 1-4?
-------------- 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/20130718/b35734e3/attachment.sig>

From broonie at kernel.org  Thu Jul 18 05:58:15 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Jul 2013 10:58:15 +0100
Subject: [PATCH] ASoC: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
In-Reply-To: <51E7203A.2020007@wwwdotorg.org>
References: <1374013667-21435-1-git-send-email-swarren@wwwdotorg.org>
 <20130717083003.GA22506@sirena.org.uk>
 <51E6CDEA.7060003@wwwdotorg.org>
 <20130717175701.GY22506@sirena.org.uk>
 <51E6E107.8020300@wwwdotorg.org>
 <20130717223309.GZ22506@sirena.org.uk>
 <51E7203A.2020007@wwwdotorg.org>
Message-ID: <20130718095815.GE22506@sirena.org.uk>

On Wed, Jul 17, 2013 at 04:52:42PM -0600, Stephen Warren wrote:

> The key to enable tegra30_i2s.c should really be ARCH_TEGRA_3x_SOC ||
> ARCH_TEGRA_114_SOC, which gets a bit unwieldy once you have, say, 4
> different SoCs in that list and a similar list starts to apply to a
> lot of different HW-modules/drivers. Even creating an
> ARCH_TEGRA_30_OR_LATER_SOC will get problematic, since defining "or
> later" will likely become progressively more complex over time, as we
> start putting our more SoCs. What are your thoughts on the best way to
> solve that?

Can't you just say Tegra 20 or later is Tegra 20 plus Tegra 30 or later
and so on?
-------------- 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/20130718/0307c9f5/attachment.sig>

From tom.leiming at gmail.com  Thu Jul 18 06:07:19 2013
From: tom.leiming at gmail.com (Ming Lei)
Date: Thu, 18 Jul 2013 18:07:19 +0800
Subject: [PATCH] [RFC] EHCI: add to memory barrier to updating hw_next
In-Reply-To: <000101ce8356$65011940$2f034bc0$@lge.com>
References: <000001ce82aa$feac9ee0$fc05dca0$@lge.com>
 <CACVXFVOu-2q74JmHLEo3mCVSAzfc7n8GmqPDMPhEDp0wL37w_w@mail.gmail.com>
 <000101ce8356$65011940$2f034bc0$@lge.com>
Message-ID: <CACVXFVNV-hGZpcy2ANQaca1K5yXJ88EOq1PTkJUEHEkFk9Btvw@mail.gmail.com>

On Thu, Jul 18, 2013 at 9:30 AM, Gioh Kim <gioh.kim at lge.com> wrote:
> Thanks for your reply.
>
>> -----Original Message-----
>> From: Ming Lei [mailto:tom.leiming at gmail.com]
>> Sent: Wednesday, July 17, 2013 5:52 PM
>> To: ???
>> Cc: Alan Stern; linux-usb at vger.kernel.org; linux-kernel at vger.kernel.org;
>> Mark Salter; namhyung.kim at lge.com; Minchan Kim; Chanho Min; Jong-Sung Kim;
>> linux-arm-kernel
>> Subject: Re: [PATCH] [RFC] EHCI: add to memory barrier to updating hw_next
>>
>> Cc: ARM list
>>
>> On Wed, Jul 17, 2013 at 1:03 PM, ??? <gioh.kim at lge.com> wrote:
>> > Hi,
>> >
>> > I have a missing urb completion problem on ARMv7 based platform.
>> >
>> > I thought the above problem was caused by coherent memory between the
>> > EHCI device and CPU so I tryied to allocates device type memory for
>> > EHCI via dma_declare_coherent_memory at machine initialization step so
>> > that EHCI always allocates from those device type memory.
>> > It seems to solve the issue because I didn't see any problem.
>> >
>> > But I am not sure it is acceptable solution. So I applied the patch
>> > https://lkml.org/lkml/2011/8/31/344.
>> > But it could not solve the problem so that I added another wmb() as my
>> > patch, and now my platform works fine.
>>
>> I remember the previous problem reported on Pandaboard firstly was fixed
>> by Will's commit 11ed0ba1(ARM: 7161/1: errata: no automatic store buffer
>> drain), so could you try to enable PL310_ERRATA_769419 and see if your
>> problem can be fixed?
>
>
> I also know the errata but it didn't work for my platform.
>
>
>>
>> >
>> > I am not sure what's the exact problem and what wmb I added could
>> > solve but I just think the problem is related to store buffer flush of
>> hw_next.
>>
>> Yes, per the above commit, but it might be one hardware problem.
>>
>> > Anyway, important thing is that it fixed my problem so I expect you
>> > expert guys could find what I am missing and a right solution.
>> > IMHO, the patch might miss updating hw_next pointer.
>> > Am I correct?
>> >
>> > I understand the wmb() is just memory barrier, not write-buffer flush.
>> > But it is true that wmb() can flush write buffer in ARM.
>> > Anyhow I think that memory type, "normal memory, non-cacheable", may
>> > have a problem for some devices that needs device type memory.
>>
>> Currently on ARMv7 DMA coherent buffer has to be bufferable, in theory we
>> might need one API to flush CPU write buffer, as described in
>> Documentation/DMA-API-HOWTO.txt:
>>
>>              Also, on some platforms your driver may need to flush CPU write
>>              buffers in much the same way as it needs to flush write buffers
>>              found in PCI bridges (such as by reading a register's value
>>              after writing it).
>>
>> But actually on hardware without the problem(such as A15), I don't see any
>> effect without flushing store buffer explicitly.
>
>
> The problem of my platform is occurring when it has very heavy traffic such as
> HD video streaming service or very many small images display.

Could you describe your test case in a bit detail?  Which USB
applications/drivers
may trigger your URB completion miss problem? Under what kind of video
streaming service(USB video or only kind of heavy load)?

> I guess that HC could have a use-after-free problem like following situation.
>
> 1. A qtd which is not at the queue head should be removed in qh_completions().
> 2. The last->hw_next become be pointing at the next qtd but the hw_next value is delayed in write-buffer.
> 3. The qtd is removed in the list.
> 4. The qtd is freed into DMA pool and re-allocated for another urb.
> 5. HC try to process last->hw_next and it is pointing re-allocated qtd.
>
> What do you think about it? Is it possible?

I understand it might not be possible because:  when 'stopped' is set, that
said the HC might not advance the queue. But I don't understand why
'last->hw_next' is patched here under 'stopped' situation.

Even the 'stopped' case may be seldom triggered, do you know under
which condition the stopped is triggered in your problem?(stall, short read
or others)


Thanks,
-- 
Ming Lei


From broonie at kernel.org  Thu Jul 18 06:08:00 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Jul 2013 11:08:00 +0100
Subject: [PATCH v1 05/24] clk: wrap I/O access for improved portability
In-Reply-To: <20130718080657.GI10380@pengutronix.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1373914074-20889-6-git-send-email-gsi@denx.de>
 <20130715193829.GS14452@pengutronix.de>
 <20130718070402.GO7080@book.gsilab.sittig.org>
 <20130718080657.GI10380@pengutronix.de>
Message-ID: <20130718100800.GF22506@sirena.org.uk>

On Thu, Jul 18, 2013 at 10:06:57AM +0200, Sascha Hauer wrote:

> I think regmap has the potential to solve a number of issues like the
> hardcoded readl/writel in the common clock blocks, issues with i2c
> clocks and your endianess issue. The biggest question probably is how
> to get there without putting too much of a burden on you. It's probably
> not an option to convert all users to regmap, so it seems additional
> functions like clk_register_gate_regmap are better to handle.

That's basically what regulator does.  There's versions of the ops that
all the drivers can use.
-------------- 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/20130718/43ffb513/attachment.sig>

From Sudeep.KarkadaNagesha at arm.com  Thu Jul 18 06:14:18 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Thu, 18 Jul 2013 11:14:18 +0100
Subject: [RFC PATCH v2 11/15] cpufreq: kirkwood-cpufreq: remove device
 tree parsing for cpu nodes
In-Reply-To: <51E7A63F.7020207@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374069984-20567-12-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <20130717144355.GE1026@lunn.ch> <51E7A63F.7020207@arm.com>
Message-ID: <51E7BFFA.8010101@arm.com>

On 18/07/13 09:24, Sudeep KarkadaNagesha wrote:
> On 17/07/13 15:43, Andrew Lunn wrote:
>> On Wed, Jul 17, 2013 at 03:06:20PM +0100, Sudeep.KarkadaNagesha at arm.com wrote:
>>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>>>
[...]
>>> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
>>> index c233ea6..18aa3eb 100644
>>> --- a/drivers/cpufreq/kirkwood-cpufreq.c
>>> +++ b/drivers/cpufreq/kirkwood-cpufreq.c
>>> @@ -13,6 +13,7 @@
>>>  #include <linux/module.h>
>>>  #include <linux/clk.h>
>>>  #include <linux/clk-provider.h>
>>> +#include <linux/cpu.h>
>>>  #include <linux/cpufreq.h>
>>>  #include <linux/of.h>
>>>  #include <linux/platform_device.h>
>>> @@ -165,6 +166,7 @@ static struct cpufreq_driver kirkwood_cpufreq_driver = {
>>>  static int kirkwood_cpufreq_probe(struct platform_device *pdev)
>>>  {
>>>  	struct device_node *np;
>>> +	struct device *cpu_dev;
>>>  	struct resource *res;
>>>  	int err;
>>>  
>>> @@ -175,9 +177,17 @@ static int kirkwood_cpufreq_probe(struct platform_device *pdev)
>>>  	if (IS_ERR(priv.base))
>>>  		return PTR_ERR(priv.base);
>>>  
>>> -	np = of_find_node_by_path("/cpus/cpu at 0");
>>> -	if (!np)
>>> +	cpu_dev = get_cpu_device(0);
>>> +	if (!cpu_dev) {
>>> +		dev_err(&pdev->dev, "failed to get cpu device\n");
>>>  		return -ENODEV;
>>> +	}
>>> +
>>> +	np = of_node_get(cpu_dev->of_node);
>>> +	if (!np) {
>>> +		dev_err(&pdev->dev, "failed to get cpu device node\n");
>>> +		return -ENODEV;
>>> +	}
>>
>> Hi Sudeep
>>
>> Are we not going a bit backwards here? You are replacing two lines
>> with 10 lines.
>>
>> How about putting these 10 lines into some helper,
>> of_get_cpu_device()?  It would be useful for spear, kirkwood and
>> imx6q, and maybe others.
>>
> Yes I realised that after making changes to this and pmac32 drivers. I
> have already made those changes in v3. I am waiting for more response
> before posting them.
> 
I thought of placing this helper in include/linux/of_device.h but I see:
#include <linux/of_platform.h> /* temporary until merge */

Does this mean of_platform.h and of_device.h will be merged ?
If so, which will be the final merged one ? I would like to avoid
changing all the header file inclusions later in users of this new helper.

Regards,
Sudeep




From sachin.kamat at linaro.org  Thu Jul 18 06:01:16 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Thu, 18 Jul 2013 15:31:16 +0530
Subject: [PATCH v2 0/6] clk: exynos: Some fixes and cleanup
Message-ID: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>

Resending some of patches (1, 3 and 5) as per discussion in thread [1].
Other patches in the series are new.

[1] http://comments.gmane.org/gmane.linux.kernel.samsung-soc/19933

Changes since v1:
* Removed an unnecessary change in Patch 1 as pointed out by Kukjin Kim.
* Added Kukjin's ack to patches 3~6.

Sachin Kamat (6):
  clk: exynos4: Staticize local symbols
  clk: exynos4: Remove unused function
  clk: exynos5250: Staticize local symbols
  clk: exynos5420: Staticize local symbols
  clk: exynos5440: Staticize local symbols
  clk: exynos-audss: Staticize exynos_audss_clk_init

 drivers/clk/samsung/clk-exynos-audss.c |    2 +-
 drivers/clk/samsung/clk-exynos4.c      |   42 ++++++++++++--------------------
 drivers/clk/samsung/clk-exynos5250.c   |   14 +++++------
 drivers/clk/samsung/clk-exynos5420.c   |   14 +++++------
 drivers/clk/samsung/clk-exynos5440.c   |   14 +++++------
 5 files changed, 37 insertions(+), 49 deletions(-)

-- 
1.7.9.5



From sachin.kamat at linaro.org  Thu Jul 18 06:01:17 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Thu, 18 Jul 2013 15:31:17 +0530
Subject: [PATCH 1/6] clk: exynos4: Staticize local symbols
In-Reply-To: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
References: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1374141682-29432-2-git-send-email-sachin.kamat@linaro.org>

Symbols referenced only in this file are made static.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
---
 drivers/clk/samsung/clk-exynos4.c |   28 +++++++++++++++-------------
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index 1bdb882..5af496c 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -338,24 +338,24 @@ PNAME(mout_user_aclk200_p4x12) = {"fin_pll", "div_aclk200", };
 PNAME(mout_user_aclk266_gps_p4x12) = {"fin_pll", "div_aclk266_gps", };
 
 /* fixed rate clocks generated outside the soc */
-struct samsung_fixed_rate_clock exynos4_fixed_rate_ext_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos4_fixed_rate_ext_clks[] __initdata = {
 	FRATE(xxti, "xxti", NULL, CLK_IS_ROOT, 0),
 	FRATE(xusbxti, "xusbxti", NULL, CLK_IS_ROOT, 0),
 };
 
 /* fixed rate clocks generated inside the soc */
-struct samsung_fixed_rate_clock exynos4_fixed_rate_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos4_fixed_rate_clks[] __initdata = {
 	FRATE(none, "sclk_hdmi24m", NULL, CLK_IS_ROOT, 24000000),
 	FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 27000000),
 	FRATE(none, "sclk_usbphy0", NULL, CLK_IS_ROOT, 48000000),
 };
 
-struct samsung_fixed_rate_clock exynos4210_fixed_rate_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos4210_fixed_rate_clks[] __initdata = {
 	FRATE(none, "sclk_usbphy1", NULL, CLK_IS_ROOT, 48000000),
 };
 
 /* list of mux clocks supported in all exynos4 soc's */
-struct samsung_mux_clock exynos4_mux_clks[] __initdata = {
+static struct samsung_mux_clock exynos4_mux_clks[] __initdata = {
 	MUX_FA(mout_apll, "mout_apll", mout_apll_p, SRC_CPU, 0, 1,
 			CLK_SET_RATE_PARENT, 0, "mout_apll"),
 	MUX(none, "mout_hdmi", mout_hdmi_p, SRC_TV, 0, 1),
@@ -372,7 +372,7 @@ struct samsung_mux_clock exynos4_mux_clks[] __initdata = {
 };
 
 /* list of mux clocks supported in exynos4210 soc */
-struct samsung_mux_clock exynos4210_mux_clks[] __initdata = {
+static struct samsung_mux_clock exynos4210_mux_clks[] __initdata = {
 	MUX(none, "mout_aclk200", sclk_ampll_p4210, SRC_TOP0, 12, 1),
 	MUX(none, "mout_aclk100", sclk_ampll_p4210, SRC_TOP0, 16, 1),
 	MUX(none, "mout_aclk160", sclk_ampll_p4210, SRC_TOP0, 20, 1),
@@ -423,7 +423,7 @@ struct samsung_mux_clock exynos4210_mux_clks[] __initdata = {
 };
 
 /* list of mux clocks supported in exynos4x12 soc */
-struct samsung_mux_clock exynos4x12_mux_clks[] __initdata = {
+static struct samsung_mux_clock exynos4x12_mux_clks[] __initdata = {
 	MUX_A(mout_mpll_user_c, "mout_mpll_user_c", mout_mpll_user_p4x12,
 			SRC_CPU, 24, 1, "mout_mpll"),
 	MUX(none, "mout_aclk266_gps", aclk_p4412, SRC_TOP1, 4, 1),
@@ -491,7 +491,7 @@ struct samsung_mux_clock exynos4x12_mux_clks[] __initdata = {
 };
 
 /* list of divider clocks supported in all exynos4 soc's */
-struct samsung_div_clock exynos4_div_clks[] __initdata = {
+static struct samsung_div_clock exynos4_div_clks[] __initdata = {
 	DIV(none, "div_core", "mout_core", DIV_CPU0, 0, 3),
 	DIV(none, "div_core2", "div_core", DIV_CPU0, 28, 3),
 	DIV(none, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
@@ -554,7 +554,7 @@ struct samsung_div_clock exynos4_div_clks[] __initdata = {
 };
 
 /* list of divider clocks supported in exynos4210 soc */
-struct samsung_div_clock exynos4210_div_clks[] __initdata = {
+static struct samsung_div_clock exynos4210_div_clks[] __initdata = {
 	DIV(aclk200, "aclk200", "mout_aclk200", DIV_TOP, 0, 3),
 	DIV(sclk_fimg2d, "sclk_fimg2d", "mout_g2d", DIV_IMAGE, 0, 4),
 	DIV(none, "div_fimd1", "mout_fimd1", E4210_DIV_LCD1, 0, 4),
@@ -565,7 +565,7 @@ struct samsung_div_clock exynos4210_div_clks[] __initdata = {
 };
 
 /* list of divider clocks supported in exynos4x12 soc */
-struct samsung_div_clock exynos4x12_div_clks[] __initdata = {
+static struct samsung_div_clock exynos4x12_div_clks[] __initdata = {
 	DIV(none, "div_mdnie0", "mout_mdnie0", DIV_LCD0, 4, 4),
 	DIV(none, "div_mdnie_pwm0", "mout_mdnie_pwm0", DIV_LCD0, 8, 4),
 	DIV(none, "div_mdnie_pwm_pre0", "div_mdnie_pwm0", DIV_LCD0, 12, 4),
@@ -590,7 +590,7 @@ struct samsung_div_clock exynos4x12_div_clks[] __initdata = {
 };
 
 /* list of gate clocks supported in all exynos4 soc's */
-struct samsung_gate_clock exynos4_gate_clks[] __initdata = {
+static struct samsung_gate_clock exynos4_gate_clks[] __initdata = {
 	/*
 	 * After all Exynos4 based platforms are migrated to use device tree,
 	 * the device name and clock alias names specified below for some
@@ -782,7 +782,7 @@ struct samsung_gate_clock exynos4_gate_clks[] __initdata = {
 };
 
 /* list of gate clocks supported in exynos4210 soc */
-struct samsung_gate_clock exynos4210_gate_clks[] __initdata = {
+static struct samsung_gate_clock exynos4210_gate_clks[] __initdata = {
 	GATE(tvenc, "tvenc", "aclk160", GATE_IP_TV, 2, 0, 0),
 	GATE(g2d, "g2d", "aclk200", E4210_GATE_IP_IMAGE, 0, 0, 0),
 	GATE(rotator, "rotator", "aclk200", E4210_GATE_IP_IMAGE, 1, 0, 0),
@@ -817,7 +817,7 @@ struct samsung_gate_clock exynos4210_gate_clks[] __initdata = {
 };
 
 /* list of gate clocks supported in exynos4x12 soc */
-struct samsung_gate_clock exynos4x12_gate_clks[] __initdata = {
+static struct samsung_gate_clock exynos4x12_gate_clks[] __initdata = {
 	GATE(audss, "audss", "sclk_epll", E4X12_GATE_IP_MAUDIO, 0, 0, 0),
 	GATE(mdnie0, "mdnie0", "aclk160", GATE_IP_LCD0, 2, 0, 0),
 	GATE(rotator, "rotator", "aclk200", E4X12_GATE_IP_IMAGE, 1, 0, 0),
@@ -990,7 +990,9 @@ static __initdata struct of_device_id ext_clk_match[] = {
 };
 
 /* register exynos4 clocks */
-void __init exynos4_clk_init(struct device_node *np, enum exynos4_soc exynos4_soc, void __iomem *reg_base, unsigned long xom)
+static void __init exynos4_clk_init(struct device_node *np,
+				    enum exynos4_soc exynos4_soc,
+				    void __iomem *reg_base, unsigned long xom)
 {
 	struct clk *apll, *mpll, *epll, *vpll;
 
-- 
1.7.9.5



From sachin.kamat at linaro.org  Thu Jul 18 06:01:18 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Thu, 18 Jul 2013 15:31:18 +0530
Subject: [PATCH 2/6] clk: exynos4: Remove unused function
In-Reply-To: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
References: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1374141682-29432-3-git-send-email-sachin.kamat@linaro.org>

Subsequent to the cleanup in commit 3c70348c7c ("ARM: EXYNOS:
Remove legacy timer initialization code"), this function has no more
users. Hence remove it.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
---
 drivers/clk/samsung/clk-exynos4.c |   14 --------------
 1 file changed, 14 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index 5af496c..75635eb 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -969,20 +969,6 @@ static void __init exynos4_clk_register_finpll(unsigned long xom)
 
 }
 
-/*
- * This function allows non-dt platforms to specify the clock speed of the
- * xxti and xusbxti clocks. These clocks are then registered with the specified
- * clock speed.
- */
-void __init exynos4_clk_register_fixed_ext(unsigned long xxti_f,
-						unsigned long xusbxti_f)
-{
-	exynos4_fixed_rate_ext_clks[0].fixed_rate = xxti_f;
-	exynos4_fixed_rate_ext_clks[1].fixed_rate = xusbxti_f;
-	samsung_clk_register_fixed_rate(exynos4_fixed_rate_ext_clks,
-			ARRAY_SIZE(exynos4_fixed_rate_ext_clks));
-}
-
 static __initdata struct of_device_id ext_clk_match[] = {
 	{ .compatible = "samsung,clock-xxti", .data = (void *)0, },
 	{ .compatible = "samsung,clock-xusbxti", .data = (void *)1, },
-- 
1.7.9.5



From sachin.kamat at linaro.org  Thu Jul 18 06:01:19 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Thu, 18 Jul 2013 15:31:19 +0530
Subject: [PATCH 3/6] clk: exynos5250: Staticize local symbols
In-Reply-To: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
References: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1374141682-29432-4-git-send-email-sachin.kamat@linaro.org>

Symbols referenced only in this file are made static.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
Acked-by: Kukjin Kim <kgene.kim at samsung.com>
---
 drivers/clk/samsung/clk-exynos5250.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index 3da0bdf..e6a4be1 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -193,24 +193,24 @@ PNAME(mout_spdif_p)	= { "sclk_audio0", "sclk_audio1", "sclk_audio2",
 				"spdif_extclk" };
 
 /* fixed rate clocks generated outside the soc */
-struct samsung_fixed_rate_clock exynos5250_fixed_rate_ext_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos5250_fixed_rate_ext_clks[] __initdata = {
 	FRATE(fin_pll, "fin_pll", NULL, CLK_IS_ROOT, 0),
 };
 
 /* fixed rate clocks generated inside the soc */
-struct samsung_fixed_rate_clock exynos5250_fixed_rate_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos5250_fixed_rate_clks[] __initdata = {
 	FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 24000000),
 	FRATE(none, "sclk_hdmi27m", NULL, CLK_IS_ROOT, 27000000),
 	FRATE(none, "sclk_dptxphy", NULL, CLK_IS_ROOT, 24000000),
 	FRATE(none, "sclk_uhostphy", NULL, CLK_IS_ROOT, 48000000),
 };
 
-struct samsung_fixed_factor_clock exynos5250_fixed_factor_clks[] __initdata = {
+static struct samsung_fixed_factor_clock exynos5250_fixed_factor_clks[] __initdata = {
 	FFACTOR(none, "fout_mplldiv2", "fout_mpll", 1, 2, 0),
 	FFACTOR(none, "fout_bplldiv2", "fout_bpll", 1, 2, 0),
 };
 
-struct samsung_mux_clock exynos5250_mux_clks[] __initdata = {
+static struct samsung_mux_clock exynos5250_mux_clks[] __initdata = {
 	MUX_A(none, "mout_apll", mout_apll_p, SRC_CPU, 0, 1, "mout_apll"),
 	MUX_A(none, "mout_cpu", mout_cpu_p, SRC_CPU, 16, 1, "mout_cpu"),
 	MUX(none, "mout_mpll_fout", mout_mpll_fout_p, PLL_DIV2_SEL, 4, 1),
@@ -256,7 +256,7 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata = {
 	MUX(none, "mout_spi2", mout_group1_p, SRC_PERIC1, 24, 4),
 };
 
-struct samsung_div_clock exynos5250_div_clks[] __initdata = {
+static struct samsung_div_clock exynos5250_div_clks[] __initdata = {
 	DIV(none, "div_arm", "mout_cpu", DIV_CPU0, 0, 3),
 	DIV(none, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3),
 	DIV(none, "aclk66_pre", "sclk_mpll_user", DIV_TOP1, 24, 3),
@@ -316,7 +316,7 @@ struct samsung_div_clock exynos5250_div_clks[] __initdata = {
 			DIV_PERIC2, 8, 8, CLK_SET_RATE_PARENT, 0),
 };
 
-struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
+static struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
 	GATE(gscl0, "gscl0", "none", GATE_IP_GSCL, 0, 0, 0),
 	GATE(gscl1, "gscl1", "none", GATE_IP_GSCL, 1, 0, 0),
 	GATE(gscl2, "gscl2", "aclk266", GATE_IP_GSCL, 2, 0, 0),
@@ -474,7 +474,7 @@ static __initdata struct of_device_id ext_clk_match[] = {
 };
 
 /* register exynox5250 clocks */
-void __init exynos5250_clk_init(struct device_node *np)
+static void __init exynos5250_clk_init(struct device_node *np)
 {
 	void __iomem *reg_base;
 	struct clk *apll, *mpll, *epll, *vpll, *bpll, *gpll, *cpll;
-- 
1.7.9.5



From sachin.kamat at linaro.org  Thu Jul 18 06:01:20 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Thu, 18 Jul 2013 15:31:20 +0530
Subject: [PATCH 4/6] clk: exynos5420: Staticize local symbols
In-Reply-To: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
References: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1374141682-29432-5-git-send-email-sachin.kamat@linaro.org>

Symbols referenced only in this file are made static.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
Acked-by: Kukjin Kim <kgene.kim at samsung.com>
---
 drivers/clk/samsung/clk-exynos5420.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index 68a96cb..125728a 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -262,12 +262,12 @@ PNAME(maudio0_p)	= { "fin_pll", "maudio_clk", "sclk_dpll", "sclk_mpll",
 			  "sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };
 
 /* fixed rate clocks generated outside the soc */
-struct samsung_fixed_rate_clock exynos5420_fixed_rate_ext_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos5420_fixed_rate_ext_clks[] __initdata = {
 	FRATE(fin_pll, "fin_pll", NULL, CLK_IS_ROOT, 0),
 };
 
 /* fixed rate clocks generated inside the soc */
-struct samsung_fixed_rate_clock exynos5420_fixed_rate_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos5420_fixed_rate_clks[] __initdata = {
 	FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 24000000),
 	FRATE(none, "sclk_pwi", NULL, CLK_IS_ROOT, 24000000),
 	FRATE(none, "sclk_usbh20", NULL, CLK_IS_ROOT, 48000000),
@@ -275,11 +275,11 @@ struct samsung_fixed_rate_clock exynos5420_fixed_rate_clks[] __initdata = {
 	FRATE(none, "sclk_usbh20_scan_clk", NULL, CLK_IS_ROOT, 480000000),
 };
 
-struct samsung_fixed_factor_clock exynos5420_fixed_factor_clks[] __initdata = {
+static struct samsung_fixed_factor_clock exynos5420_fixed_factor_clks[] __initdata = {
 	FFACTOR(none, "sclk_hsic_12m", "fin_pll", 1, 2, 0),
 };
 
-struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
+static struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
 	MUX(none, "mout_mspll_kfc", mspll_cpu_p, SRC_TOP7, 8, 2),
 	MUX(none, "mout_mspll_cpu", mspll_cpu_p, SRC_TOP7, 12, 2),
 	MUX(none, "mout_apll", apll_p, SRC_CPU, 0, 1),
@@ -399,7 +399,7 @@ struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
 	MUX(none, "mout_spi2", group2_p, SRC_PERIC1, 28, 3),
 };
 
-struct samsung_div_clock exynos5420_div_clks[] __initdata = {
+static struct samsung_div_clock exynos5420_div_clks[] __initdata = {
 	DIV(none, "div_arm", "mout_cpu", DIV_CPU0, 0, 3),
 	DIV(none, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3),
 	DIV(none, "armclk2", "div_arm", DIV_CPU0, 28, 3),
@@ -479,7 +479,7 @@ struct samsung_div_clock exynos5420_div_clks[] __initdata = {
 	DIV(none, "dout_pre_spi2", "dout_spi2", DIV_PERIC4, 24, 8),
 };
 
-struct samsung_gate_clock exynos5420_gate_clks[] __initdata = {
+static struct samsung_gate_clock exynos5420_gate_clks[] __initdata = {
 	/* TODO: Re-verify the CG bits for all the gate clocks */
 	GATE_A(mct, "pclk_st", "aclk66_psgen", GATE_BUS_PERIS1, 2, 0, 0, "mct"),
 
@@ -704,7 +704,7 @@ static __initdata struct of_device_id ext_clk_match[] = {
 };
 
 /* register exynos5420 clocks */
-void __init exynos5420_clk_init(struct device_node *np)
+static void __init exynos5420_clk_init(struct device_node *np)
 {
 	void __iomem *reg_base;
 	struct clk *apll, *bpll, *cpll, *dpll, *epll, *ipll, *kpll, *mpll;
-- 
1.7.9.5



From sachin.kamat at linaro.org  Thu Jul 18 06:01:21 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Thu, 18 Jul 2013 15:31:21 +0530
Subject: [PATCH 5/6] clk: exynos5440: Staticize local symbols
In-Reply-To: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
References: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1374141682-29432-6-git-send-email-sachin.kamat@linaro.org>

Symbols referenced only in this file are made static.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
Acked-by: Kukjin Kim <kgene.kim at samsung.com>
---
 drivers/clk/samsung/clk-exynos5440.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5440.c b/drivers/clk/samsung/clk-exynos5440.c
index 7d54341..6d043a2 100644
--- a/drivers/clk/samsung/clk-exynos5440.c
+++ b/drivers/clk/samsung/clk-exynos5440.c
@@ -41,12 +41,12 @@ PNAME(mout_armclk_p)	= { "cplla", "cpllb" };
 PNAME(mout_spi_p)	= { "div125", "div200" };
 
 /* fixed rate clocks generated outside the soc */
-struct samsung_fixed_rate_clock exynos5440_fixed_rate_ext_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos5440_fixed_rate_ext_clks[] __initdata = {
 	FRATE(none, "xtal", NULL, CLK_IS_ROOT, 0),
 };
 
 /* fixed rate clocks */
-struct samsung_fixed_rate_clock exynos5440_fixed_rate_clks[] __initdata = {
+static struct samsung_fixed_rate_clock exynos5440_fixed_rate_clks[] __initdata = {
 	FRATE(none, "ppll", NULL, CLK_IS_ROOT, 1000000000),
 	FRATE(none, "usb_phy0", NULL, CLK_IS_ROOT, 60000000),
 	FRATE(none, "usb_phy1", NULL, CLK_IS_ROOT, 60000000),
@@ -55,26 +55,26 @@ struct samsung_fixed_rate_clock exynos5440_fixed_rate_clks[] __initdata = {
 };
 
 /* fixed factor clocks */
-struct samsung_fixed_factor_clock exynos5440_fixed_factor_clks[] __initdata = {
+static struct samsung_fixed_factor_clock exynos5440_fixed_factor_clks[] __initdata = {
 	FFACTOR(none, "div250", "ppll", 1, 4, 0),
 	FFACTOR(none, "div200", "ppll", 1, 5, 0),
 	FFACTOR(none, "div125", "div250", 1, 2, 0),
 };
 
 /* mux clocks */
-struct samsung_mux_clock exynos5440_mux_clks[] __initdata = {
+static struct samsung_mux_clock exynos5440_mux_clks[] __initdata = {
 	MUX(none, "mout_spi", mout_spi_p, MISC_DOUT1, 5, 1),
 	MUX_A(arm_clk, "arm_clk", mout_armclk_p,
 			CPU_CLK_STATUS, 0, 1, "armclk"),
 };
 
 /* divider clocks */
-struct samsung_div_clock exynos5440_div_clks[] __initdata = {
+static struct samsung_div_clock exynos5440_div_clks[] __initdata = {
 	DIV(spi_baud, "div_spi", "mout_spi", MISC_DOUT1, 3, 2),
 };
 
 /* gate clocks */
-struct samsung_gate_clock exynos5440_gate_clks[] __initdata = {
+static struct samsung_gate_clock exynos5440_gate_clks[] __initdata = {
 	GATE(pb0_250, "pb0_250", "div250", CLKEN_OV_VAL, 3, 0, 0),
 	GATE(pr0_250, "pr0_250", "div250", CLKEN_OV_VAL, 4, 0, 0),
 	GATE(pr1_250, "pr1_250", "div250", CLKEN_OV_VAL, 5, 0, 0),
@@ -103,7 +103,7 @@ static __initdata struct of_device_id ext_clk_match[] = {
 };
 
 /* register exynos5440 clocks */
-void __init exynos5440_clk_init(struct device_node *np)
+static void __init exynos5440_clk_init(struct device_node *np)
 {
 	void __iomem *reg_base;
 
-- 
1.7.9.5



From sachin.kamat at linaro.org  Thu Jul 18 06:01:22 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Thu, 18 Jul 2013 15:31:22 +0530
Subject: [PATCH 6/6] clk: exynos-audss: Staticize exynos_audss_clk_init
In-Reply-To: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
References: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1374141682-29432-7-git-send-email-sachin.kamat@linaro.org>

exynos_audss_clk_init() is used only in this file. Make it
static.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
Acked-by: Kukjin Kim <kgene.kim at samsung.com>
---
 drivers/clk/samsung/clk-exynos-audss.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
index 9b1bbd5..51b48da 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -62,7 +62,7 @@ static struct syscore_ops exynos_audss_clk_syscore_ops = {
 #endif /* CONFIG_PM_SLEEP */
 
 /* register exynos_audss clocks */
-void __init exynos_audss_clk_init(struct device_node *np)
+static void __init exynos_audss_clk_init(struct device_node *np)
 {
 	reg_base = of_iomap(np, 0);
 	if (!reg_base) {
-- 
1.7.9.5



From b.brezillon at overkiz.com  Thu Jul 18 06:21:38 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Thu, 18 Jul 2013 12:21:38 +0200
Subject: [PATCH v4 5/5] ASoC: atmel-ssc: remove clk_disable_unprepare
 call from critical section
In-Reply-To: <20130718095337.GD22506@sirena.org.uk>
References: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
 <1374133720-27362-1-git-send-email-b.brezillon@overkiz.com>
 <20130718095337.GD22506@sirena.org.uk>
Message-ID: <51E7C1B2.8000206@overkiz.com>

On 18/07/2013 11:53, Mark Brown wrote:
> On Thu, Jul 18, 2013 at 09:48:40AM +0200, Boris BREZILLON wrote:
>> clk_prepare/unprepare (and indirectly clk_prepare_enable/disable_unprepare)
>> may sleep and thus cannot be called in critical section.
> I'm missing patches 1-4?
I can send you the whole series if you want (already sent to LKML and 
LAKML).

But I'd like to understand who I should send patches from this series to.

Here's my approach:
1) send all patches of the series to at91 maintainers (as they are 
directly concerned).
2) send all patches of the series LKML and LAKML
3) send each patch of the series to the persons and mailing lists 
concerned by this patch :
     contributors and maintainers (retrieved by get_maintainer.pl script)

Could you tell me if I'm doing something wrong?

Thanks

Best Regards,

Boris


From jonas.jensen at gmail.com  Thu Jul 18 06:36:40 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Thu, 18 Jul 2013 12:36:40 +0200
Subject: [PATCH v3] clk: add MOXA ART SoCs clock driver
In-Reply-To: <20130718095035.GA29153@e106331-lin.cambridge.arm.com>
References: <1372943292-6960-1-git-send-email-jonas.jensen@gmail.com>
 <1374067396-30155-1-git-send-email-jonas.jensen@gmail.com>
 <20130718095035.GA29153@e106331-lin.cambridge.arm.com>
Message-ID: <CACmBeS2SnpiUtiQD6j9qyaXZ5-chHSHVeo4c5=UhitVonvkKtw@mail.gmail.com>

Hi Mark, thanks for taking a look at this.

On 18 July 2013 11:50, Mark Rutland <mark.rutland at arm.com> wrote:
> This confuses me. moxart_of_clk_init gets called because there was a
> "moxa,moxart-core-clock", node in the dt, but the driver only seems to
> use the information to figure out the configuration of another clock
> ("moxa,moxart-apb-clock"), and never registers a clock specifically for
> the core-clock.
>
> I couldn't find "moxa,moxart-apb-clock" described in mainline. COuld you
> describe the relationship between core-clock and apb-clock?

It's true core-clock exist only so the register can be mapped.

apb-clock is part of a patch set that will add new device tree files for the
MOXA ART SoC, but it's not in mainline:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181757.html

apb-clock could be a fixed rate 48MHz DT only clock, but because we can't
be sure it's 48MHz on all platforms, reading it from a register with core-clock
is more portable.


Best regards,
Jonas


From plagnioj at jcrosoft.com  Thu Jul 18 06:45:23 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 18 Jul 2013 18:45:23 +0800
Subject: [PATCH V2 5/8] serial: at91: support run time switch transfer mode
In-Reply-To: <51E7A756.6010004@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
 <1373942627-7121-6-git-send-email-elen.song@atmel.com>
 <20130718081520.GC16015@ns203013.ovh.net> <51E7A756.6010004@atmel.com>
Message-ID: <288A72E2-2BFD-4D6D-930E-6CE06A8487FC@jcrosoft.com>


On Jul 18, 2013, at 4:29 PM, elen.song <elen.song at atmel.com> wrote:

> Hi JC:
> On 7/18/2013 4:15 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 10:43 Tue 16 Jul     , Elen Song wrote:
>> 
>>> We will switch to pio mode when request of dma or pdc fail.
>>> But soon or later, when the request is success, the transfer mode can switch to them at
>>> next open serial port action.
>>> So in startup stage, we should get original transfer mode.
>>> 
>> You need to update the Documentation of the binding to said the driver support
>> dmas bindings for the new IP
>> 
> one question, it seems the document should write like:
>  
> +- use DMA:
> +       usart0: serial at f001c000 {
> +               compatible = "atmel,at91sam9260-usart";
> +               reg = <0xf001c000 0x100>;
> +               interrupts = <12 IRQ_TYPE_LEVEL_HIGH 5>;
> +               dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(3)>,
> +                      <&dma0 2 (AT91_DMA_CFG_PER_ID(4) | AT91_DMA_CFG_FIFOCFG_ASAP)>;
> +               dma-names = "tx", "rx";
> +       };
> 
> Should I instead macros with typical values?
> 

Value as MACRO is a linux artefact

Best Regards,
J.


> Best regards
>>  
>> and please use true/false for boolean
>> 
>> and check the white space
>> 
>>> Signed-off-by: Elen Song <elen.song at atmel.com>
>>> 
>>> ---
>>>  drivers/tty/serial/atmel_serial.c |  139 +++++++++++++++++++++----------------
>>>  1 file changed, 80 insertions(+), 59 deletions(-)
>>> 
>>> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>>> index 298b58c..ad787fd1 100644
>>> --- a/drivers/tty/serial/atmel_serial.c
>>> +++ b/drivers/tty/serial/atmel_serial.c
>>> @@ -1371,6 +1371,80 @@ static void atmel_tasklet_func(unsigned long data)
>>>  	spin_unlock(&port->lock);
>>>  }
>>>  
>>> +static int atmel_init_property(struct atmel_uart_port *atmel_port,
>>> +				struct platform_device *pdev)
>>> +{
>>> +	struct device_node *np = pdev->dev.of_node;
>>> +	struct atmel_uart_data *pdata = pdev->dev.platform_data;
>>> +
>>> +	if (np) {
>>> +		/* DMA/PDC usage specification */
>>> +		if (of_get_property(np, "atmel,use-dma-rx", NULL)) {
>>> +			if (of_get_property(np, "dmas", NULL)) {
>>> +				atmel_port->use_dma_rx  = 1;
>>> +				atmel_port->use_pdc_rx  = 0;
>>> +			} else {
>>> +				atmel_port->use_dma_rx  = 0;
>>> +				atmel_port->use_pdc_rx  = 1;
>>> +			}
>>> +		} else {
>>> +			atmel_port->use_dma_rx  = 0;
>>> +			atmel_port->use_pdc_rx  = 0;
>>> +		}
>>> +
>>> +		if (of_get_property(np, "atmel,use-dma-tx", NULL)) {
>>> +			if (of_get_property(np, "dmas", NULL)) {
>>> +				atmel_port->use_dma_tx  = 1;
>>> +				atmel_port->use_pdc_tx  = 0;
>>> +			} else {
>>> +				atmel_port->use_dma_tx  = 0;
>>> +				atmel_port->use_pdc_tx  = 1;
>>> +			}
>>> +		} else {
>>> +			atmel_port->use_dma_tx  = 0;
>>> +			atmel_port->use_pdc_tx  = 0;
>>> +		}
>>> +
>>> +	} else {
>>> +		atmel_port->use_pdc_rx  = pdata->use_dma_rx;
>>> +		atmel_port->use_pdc_tx  = pdata->use_dma_tx;
>>> +		atmel_port->use_dma_rx  = 0;
>>> +		atmel_port->use_dma_tx  = 0;
>>> +	}
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static void atmel_init_rs485(struct atmel_uart_port *atmel_port,
>>> +				struct platform_device *pdev)
>>> +{
>>> +	struct device_node *np = pdev->dev.of_node;
>>> +	struct atmel_uart_data *pdata = pdev->dev.platform_data;
>>> +
>>> +	if (np) {
>>> +		u32 rs485_delay[2];
>>> +		/* rs485 properties */
>>> +		if (of_property_read_u32_array(np, "rs485-rts-delay",
>>> +					rs485_delay, 2) == 0) {
>>> +			struct serial_rs485 *rs485conf = &atmel_port->rs485;
>>> +
>>> +			rs485conf->delay_rts_before_send = rs485_delay[0];
>>> +			rs485conf->delay_rts_after_send = rs485_delay[1];
>>> +			rs485conf->flags = 0;
>>> +
>>> +		if (of_get_property(np, "rs485-rx-during-tx", NULL))
>>> +			rs485conf->flags |= SER_RS485_RX_DURING_TX;
>>> +
>>> +		if (of_get_property(np, "linux,rs485-enabled-at-boot-time",
>>> +								NULL))
>>> +			rs485conf->flags |= SER_RS485_ENABLED;
>>> +		}
>>> +	} else {
>>> +		atmel_port->rs485       = pdata->rs485;
>>> +	}
>>> +
>>> +}
>>> +
>>>  static void atmel_set_ops(struct uart_port *port)
>>>  {
>>>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>>> @@ -1409,6 +1483,7 @@ static void atmel_set_ops(struct uart_port *port)
>>>   */
>>>  static int atmel_startup(struct uart_port *port)
>>>  {
>>> +	struct platform_device *pdev = to_platform_device(port->dev);
>>>  	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
>>>  	struct tty_struct *tty = port->state->port.tty;
>>>  	int retval;
>>> @@ -1433,6 +1508,8 @@ static int atmel_startup(struct uart_port *port)
>>>  	/*
>>>  	 * Initialize DMA (if necessary)
>>>  	 */
>>> +	atmel_init_property(atmel_port, pdev);
>>> +
>>>  	if (atmel_port->prepare_rx) {
>>>  		retval = atmel_port->prepare_rx(port);
>>>  		if (retval < 0)
>>> @@ -1878,55 +1955,6 @@ static struct uart_ops atmel_pops = {
>>>  #endif
>>>  };
>>>  
>>> -static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
>>> -					 struct device_node *np)
>>> -{
>>> -	u32 rs485_delay[2];
>>> -
>>> -	/* DMA/PDC usage specification */
>>> -	if (of_get_property(np, "atmel,use-dma-rx", NULL)) {
>>> -		if (of_get_property(np, "dmas", NULL)) {
>>> -			atmel_port->use_dma_rx	= 1;
>>> -			atmel_port->use_pdc_rx	= 0;
>>> -		} else {
>>> -			atmel_port->use_dma_rx	= 0;
>>> -			atmel_port->use_pdc_rx	= 1;
>>> -		}
>>> -	} else {
>>> -		atmel_port->use_dma_rx	= 0;
>>> -		atmel_port->use_pdc_rx	= 0;
>>> -	}
>>> -
>>> -	if (of_get_property(np, "atmel,use-dma-tx", NULL)) {
>>> -		if (of_get_property(np, "dmas", NULL)) {
>>> -			atmel_port->use_dma_tx	= 1;
>>> -			atmel_port->use_pdc_tx	= 0;
>>> -		} else {
>>> -			atmel_port->use_dma_tx	= 0;
>>> -			atmel_port->use_pdc_tx	= 1;
>>> -		}
>>> -	} else {
>>> -		atmel_port->use_dma_tx	= 0;
>>> -		atmel_port->use_pdc_tx	= 0;
>>> -	}
>>> -
>>> -	/* rs485 properties */
>>> -	if (of_property_read_u32_array(np, "rs485-rts-delay",
>>> -					    rs485_delay, 2) == 0) {
>>> -		struct serial_rs485 *rs485conf = &atmel_port->rs485;
>>> -
>>> -		rs485conf->delay_rts_before_send = rs485_delay[0];
>>> -		rs485conf->delay_rts_after_send = rs485_delay[1];
>>> -		rs485conf->flags = 0;
>>> -
>>> -		if (of_get_property(np, "rs485-rx-during-tx", NULL))
>>> -			rs485conf->flags |= SER_RS485_RX_DURING_TX;
>>> -
>>> -		if (of_get_property(np, "linux,rs485-enabled-at-boot-time", NULL))
>>> -			rs485conf->flags |= SER_RS485_ENABLED;
>>> -	}
>>> -}
>>> -
>>>  /*
>>>   * Configure the port from the platform device resource info.
>>>   */
>>> @@ -1936,17 +1964,10 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
>>>  	struct uart_port *port = &atmel_port->uart;
>>>  	struct atmel_uart_data *pdata = pdev->dev.platform_data;
>>>  
>>> -	if (pdev->dev.of_node) {
>>> -		atmel_of_init_port(atmel_port, pdev->dev.of_node);
>>> -	} else {
>>> -		atmel_port->use_pdc_rx	= pdata->use_dma_rx;
>>> -		atmel_port->use_pdc_tx	= pdata->use_dma_tx;
>>> -		atmel_port->use_dma_rx	= 0;
>>> -		atmel_port->use_dma_tx	= 0;
>>> -		atmel_port->rs485	= pdata->rs485;
>>> -	}
>>> +	if (!atmel_init_property(atmel_port, pdev))
>>> +		atmel_set_ops(port);
>>>  
>>> -	atmel_set_ops(port);
>>> +	atmel_init_rs485(atmel_port, pdev);
>>>  
>>>  	port->iotype		= UPIO_MEM;
>>>  	port->flags		= UPF_BOOT_AUTOCONF;
>>> -- 
>>> 1.7.9.5
>>> 
>>> 
> 



From tony at atomide.com  Thu Jul 18 06:53:46 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 03:53:46 -0700
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130718072034.GO7656@atomide.com>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
 <51E70953.1000601@wwwdotorg.org>
 <20130718072034.GO7656@atomide.com>
Message-ID: <20130718105345.GV7656@atomide.com>

* Tony Lindgren <tony at atomide.com> [130718 00:31]:
> * Stephen Warren <swarren at wwwdotorg.org> [130717 14:21]:
> > On 07/16/2013 03:05 AM, Tony Lindgren wrote:
> > > +int pinctrl_check_dynamic(struct device *dev, struct pinctrl_state *st1,
> > > +			  struct pinctrl_state *st2)
> > > +{
> > > +	struct pinctrl_setting *s1, *s2;
> > > +
> > > +	list_for_each_entry(s1, &st1->settings, node) {
> > ...
> > > +		list_for_each_entry(s2, &st2->settings, node) {
> > ...
> > > +			if (pctldev1 != pctldev2) {
> > > +				dev_dbg(dev, "pctldev must be the same for states\n");
> > > +				return -EINVAL;
> > > +			}
> > 
> > I don't think we should require that; it's perfectly legal at the moment
> > for some device's pinctrl configuration to include settings from
> > multiple different pin controllers.
> 
> Yes that's fine for pinctrl_select(), but let's not do that for
> runtime muxing.

Hmm reading this again, you're right, there should not be anything
preventing mixing multiple controllers as long as the states match.
 
> > > +			for (i = 0; i < num_pins1; i++) {
> > > +				int pin1 = pins1[i];
> > > +
> > > +				for (j = 0; j < num_pins2; j++) {
> > > +					int pin2 = pins2[j];
> > > +
> > > +					if (pin1 == pin2) {
> > > +						found++;
> > > +						break;
> > > +					}
> > > +				}
> > > +			}
> > > +
> > > +			if (found != num_pins1) {
> > 
> > I guess this make sure that every entry in the dynamic state is in the
> > state state, but not vice-versa; the static state can affect more stuff
> > than the dynamic state?
> > 
> > If so, shouldn't that check be if (found != num_pins2)?
> 
> The check is that idle_state and sleep_state pins must match the
> active_state pins. This is intentionally different from the current
> pinctrl_select() logic.

And here things will get messed up if the order of settings is diffrent..
So yes, pinctrl_check_dynamic() needs more work.

Regards,

Tony


From broonie at kernel.org  Thu Jul 18 06:55:40 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Jul 2013 11:55:40 +0100
Subject: [PATCH] ASoC: wm8904: fix the typo error for LINER Mux
In-Reply-To: <1374129500-5270-1-git-send-email-voice.shen@atmel.com>
References: <1374129500-5270-1-git-send-email-voice.shen@atmel.com>
Message-ID: <20130718105540.GI22506@sirena.org.uk>

On Thu, Jul 18, 2013 at 02:38:20PM +0800, Bo Shen wrote:
> fix the typo error, from "LINEL Mux" to "LINER Mux"

Applied, thanks.
-------------- 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/20130718/46091b67/attachment.sig>

From broonie at kernel.org  Thu Jul 18 06:58:46 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Jul 2013 11:58:46 +0100
Subject: [PATCH v4 5/5] ASoC: atmel-ssc: remove clk_disable_unprepare
 call from critical section
In-Reply-To: <51E7C1B2.8000206@overkiz.com>
References: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
 <1374133720-27362-1-git-send-email-b.brezillon@overkiz.com>
 <20130718095337.GD22506@sirena.org.uk>
 <51E7C1B2.8000206@overkiz.com>
Message-ID: <20130718105846.GJ22506@sirena.org.uk>

On Thu, Jul 18, 2013 at 12:21:38PM +0200, boris brezillon wrote:

> I can send you the whole series if you want (already sent to LKML
> and LAKML).

> But I'd like to understand who I should send patches from this series to.

When you send me patch 5/5 with no other information on the rest of the
series I've no idea if there's any dependencies on the other code or
anything like that.  The key thing here is to make sure the people
getting the patch can understand the interdependencies somehow.

If you're sending a bunch of unrelated changes with no dependencies
you're better off sending them all separately rather than as a part of a
series.
-------------- 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/20130718/d69af9e4/attachment.sig>

From mark.rutland at arm.com  Thu Jul 18 07:02:01 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 18 Jul 2013 12:02:01 +0100
Subject: [PATCH v3] clk: add MOXA ART SoCs clock driver
In-Reply-To: <CACmBeS2SnpiUtiQD6j9qyaXZ5-chHSHVeo4c5=UhitVonvkKtw@mail.gmail.com>
References: <1372943292-6960-1-git-send-email-jonas.jensen@gmail.com>
 <1374067396-30155-1-git-send-email-jonas.jensen@gmail.com>
 <20130718095035.GA29153@e106331-lin.cambridge.arm.com>
 <CACmBeS2SnpiUtiQD6j9qyaXZ5-chHSHVeo4c5=UhitVonvkKtw@mail.gmail.com>
Message-ID: <20130718110201.GB29153@e106331-lin.cambridge.arm.com>

On Thu, Jul 18, 2013 at 11:36:40AM +0100, Jonas Jensen wrote:
> Hi Mark, thanks for taking a look at this.
> 
> On 18 July 2013 11:50, Mark Rutland <mark.rutland at arm.com> wrote:
> > This confuses me. moxart_of_clk_init gets called because there was a
> > "moxa,moxart-core-clock", node in the dt, but the driver only seems to
> > use the information to figure out the configuration of another clock
> > ("moxa,moxart-apb-clock"), and never registers a clock specifically for
> > the core-clock.
> >
> > I couldn't find "moxa,moxart-apb-clock" described in mainline. COuld you
> > describe the relationship between core-clock and apb-clock?
> 
> It's true core-clock exist only so the register can be mapped.

Ok. I'm just concerned that the linkage isn't explicit or obvious.

> 
> apb-clock is part of a patch set that will add new device tree files for the
> MOXA ART SoC, but it's not in mainline:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181757.html
> 
> apb-clock could be a fixed rate 48MHz DT only clock, but because we can't
> be sure it's 48MHz on all platforms, reading it from a register with core-clock
> is more portable.

This does leave apb-clock completely dependent on core-clock, and unless
I've missed something there's no linkage between the two described in
the dt.

How does core-clock physically relate to apb-clock? Does it feed or is
it fed by apb-clock?

Are we always guaranteed to have core-clock if we have apb-clock, and is
it part of the same block in hardware? If so we could describe the
amalgamation as a provider with two clock outputs, with core-clock's
registers for configuration at probe-time.

Thanks,
Mark.

> 
> 
> Best regards,
> Jonas
> 


From afzal at ti.com  Thu Jul 18 07:07:06 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Thu, 18 Jul 2013 16:37:06 +0530
Subject: [PATCH RFC 00/13] ARM: OMAP2+: AM43x PRCM support
In-Reply-To: <cover.1373519192.git.afzal@ti.com>
References: <cover.1373519192.git.afzal@ti.com>
Message-ID: <51E7CC5A.8020906@ti.com>

Hi Tony, Paul,

On 7/11/2013 12:03 PM, Afzal Mohammed wrote:

> AM43x PRCM support (excluding clock tree) is being added with this
> series. AM43x reuses most of the IP's from AM335x, as that is the
> case, it was felt that reusing AM335x code as much as possible for
> AM43x is better - it also helps to keep LOC less.

> Major reuse has been with hwmod database of AM335x, moving common
> elements to a new array and keeping separate arrays for elements that
> are specific only to either one of AM335x or AM43x. And in the cases
> where relevant IP is present in both that has difference in details
> like CLKCTRL register offsets, it is being updated at runtime based on
> the SoC detected.

> This series is being developed with additional clock tree changes that
> would be DT'fied.

> Additional DTS changes are also required for hwmod to get register
> target address space as most of AM335x hwmod address space details has
> been recently cleaned up and moved to DTS.

 > 		********
 >
 > This RFC is being posted to get an early feedback on approach taken
 > here mainly w.r.t reusing AM335x hwmod database for AM43x.
 >
 > 		********

Please let me know your comments on this series.

Most of the IP's in AM335x is reused on AM43x and hence out of the
existing 77 hwmod ocpif entries on AM335x, 73 are reused on AM43x by
moving to a common array (only 4 is left AM335x specific).

Even the address space of those peripherals that are common between
AM335x & AM43x is same. And AM43x has only a few newer IP's as
compared to AM335x.

Regards
Afzal


From josephl at nvidia.com  Thu Jul 18 07:08:45 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Thu, 18 Jul 2013 19:08:45 +0800
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <51E6FF0B.5000708@wwwdotorg.org>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
 <51E6FF0B.5000708@wwwdotorg.org>
Message-ID: <1374145726.5610.73.camel@jlo-ubuntu-64.nvidia.com>

On Thu, 2013-07-18 at 04:31 +0800, Stephen Warren wrote:
> On 07/17/2013 04:15 AM, Joseph Lo wrote:
> > On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
> >> On 07/16/2013 05:17 AM, Joseph Lo wrote:
> >>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
> >>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
> >>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
> >>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
> >>>>> this state.
> ... [ discussion of issues with Joesph's patches applied]
> >
> > OK. I did more stress tests last night and today. I found it cause by
> > the patch "ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag" and
> > only impact the Tegra20 platform. The hot plug regression seems due to
> > this patch. After dropping this patch on top of v3.11-rc1, the Tegra20
> > can back to normal.
> > 
> > And the hop plug and suspend stress test can pass on Tegra30/114 too.
> > 
> > Can the other two patch series for Tegra114 to support CPU idle power
> > down mode and system suspend still moving forward, not be blocked by
> > this patch?
> > 
> > Looks the CPUIDLE_FLAG_TIMER_STOP flag still cause some other issue for
> > hot plug on Tegra20, I will continue to check this. You can just drop
> > this patch.
> 
> OK, if I drop that patch, then everything on Tegra20 and Tegra30 seems
> fine again.
> 
> However, I've found some new and exciting issue on Tegra114!
> 
> With unmodified v3.11-rc1, I can do the following without issue:
> 
> * Unplug/replug CPUs, so that I had all combinations of CPU 1, 2, 3
> plugged/unpplugged (with CPU 0 always plugged).
> 
> * Unplug/replug CPUs, so that I had all combinations of CPU 0, 1, 2, 3
> plugged/unpplugged (with the obvious exception of never having all CPUs
> unplugged).
> 
> However, if I try this with your Tegra114 cpuidle and suspend patches
> applied, I see the following issues:
> 
> 1) If I boot, unplug CPU 0, then replug CPU 0, the system immediately
> hard-hangs.
> 
Sorry, I didn't apply the hotplug stress test on CPU0 too much. Because
all of our use cases and stress tests are focused on secondary CPUs
only.

After doing some tests, here is my summary. This issue happens after we
support CPU idle power-down mode and relates to PMC or flow controller I
believe.

i) on top of v3.11-rc1 (only support WFI in CPU idle)
When hot unplug CPU0, the PMC can power gate and put it into reset
state. This is what I expect and also true on all the other secondary
CPUs. The flow controller can maintain the CPU power state machine as
what we want.

ii) on top of v3.11-rc1 + CPU idle power down mode support
a) I saw most of the time the CPU0,1,2,3 were in power down and reset
status. That means the idle power down mode works fine.

b) Testing with the CPU hotplug stress test with the secondary CPUs (not
include CPU0), the result is good too.

c) Testing hot plug on CPU0 with CPUIDLE_FLAG_TIMER_STOP apply or not
apply (Note 1), the result shows not good to me. The CPU0 have already
gone into WFI and the flow controller is set as WAITFOREVENT mode. But
the PMC always can't power gate CPU0 and sometimes can put it into
reset, but sometimes can't. That's why you can see it hanging after
unplug CPU0 sometimes.

When hop plug-in CPU0, because the CPU0 not be power gated by PMC or the
flow controller event that we trigger PMC to do. I think it may need
more time to process it. It can be solved by just add a udelay(10) after
we set up flow controller event to wake up CPU0. Then it can put CPU0
back to normal state.

So the result shows to me the flow controller (or the state machine)
looks not support to power gate CPU0 when we support idle power down
mode. The power of CPU0 also can bind to the power of the CPU cluster.
That cause the state machine can't work correctly in this case, I guess.
I need to check with some people. BTW, I just saw we drop the hotplug
support for CPU0 in downstream rel-18 (although it's not related to this
issue).

Note 1.
diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c
b/arch/arm/mach-tegra/cpuidle-tegra114.c
index 658b205..5248a69 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -43,8 +43,12 @@ static int tegra114_idle_power_down(struct
cpuidle_device *dev,
        tegra_set_cpu_in_lp2();
        cpu_pm_enter();
 
+       clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+
        cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
 
+       clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+
        cpu_pm_exit();
        tegra_clear_cpu_in_lp2();
 
@@ -66,8 +70,8 @@ static struct cpuidle_driver tegra_idle_driver = {
                        .exit_latency           = 500,
                        .target_residency       = 1000,
                        .power_usage            = 0,
-                       .flags                  =
CPUIDLE_FLAG_TIME_VALID |
-
CPUIDLE_FLAG_TIMER_STOP,
+                       .flags                  =
CPUIDLE_FLAG_TIME_VALID,
+//
CPUIDLE_FLAG_TIMER_STOP,
                        .name                   = "powered-down",
                        .desc                   = "CPU power gated",
                },

> 2) If I run the hotplug test script, leaving CPU 0 always present, I
> sometimes see:
> 
> > root at localhost:~# for i in `seq 1 50`; do echo ITERATION $i; ./cpuonline.py; done
> > ITERATION 1
> > echo 0 > /sys/devices/system/cpu/cpu2/online
> > [  458.910054] CPU2: shutdown
> > echo 0 > /sys/devices/system/cpu/cpu1/online
> > [  461.004371] CPU1: shutdown
> > echo 0 > /sys/devices/system/cpu/cpu3/online
> > [  463.027341] CPU3: shutdown
> > echo 1 > /sys/devices/system/cpu/cpu1/online
> > [  465.061412] CPU1: Booted secondary processor
> > echo 1 > /sys/devices/system/cpu/cpu2/online
> > [  467.095313] CPU2: Booted secondary processor
> > [  467.113243] ------------[ cut here ]------------
> > [  467.117948] WARNING: CPU: 2 PID: 0 at kernel/time/tick-broadcast.c:667 tick_broadcast_oneshot_control+0x19c/0x1c4()
> > [  467.128352] Modules linked in:
> > [  467.131455] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.11.0-rc1-00022-g7487363-dirty #49
> > [  467.139678] [<c0015620>] (unwind_backtrace+0x0/0xf8) from [<c001154c>] (show_stack+0x10/0x14)
> > [  467.148228] [<c001154c>] (show_stack+0x10/0x14) from [<c05135a8>] (dump_stack+0x80/0xc4)
> > [  467.156336] [<c05135a8>] (dump_stack+0x80/0xc4) from [<c0024590>] (warn_slowpath_common+0x64/0x88)
> > [  467.165300] [<c0024590>] (warn_slowpath_common+0x64/0x88) from [<c00245d0>] (warn_slowpath_null+0x1c/0x24)
> > [  467.174959] [<c00245d0>] (warn_slowpath_null+0x1c/0x24) from [<c00695e4>] (tick_broadcast_oneshot_control+0x19c/0x1c4)
> > [  467.185659] [<c00695e4>] (tick_broadcast_oneshot_control+0x19c/0x1c4) from [<c0067cdc>] (clockevents_notify+0x1b0/0x1dc)
> > [  467.196538] [<c0067cdc>] (clockevents_notify+0x1b0/0x1dc) from [<c034f348>] (cpuidle_idle_call+0x11c/0x168)
> > [  467.206292] [<c034f348>] (cpuidle_idle_call+0x11c/0x168) from [<c000f134>] (arch_cpu_idle+0x8/0x38)
> > [  467.215359] [<c000f134>] (arch_cpu_idle+0x8/0x38) from [<c0061038>] (cpu_startup_entry+0x60/0x134)
> > [  467.224325] [<c0061038>] (cpu_startup_entry+0x60/0x134) from [<800083d8>] (0x800083d8)
> > [  467.232227] ---[ end trace ea579be22a00e7fb ]---
> > echo 0 > /sys/devices/system/cpu/cpu1/online
> > [  469.126682] CPU1: shutdown

Hmm. It's hard to reproduce. But finally, I also can repro with CPU
hotplug stress test. And some strange issues after apply
CPUIDLE_FLAG_TIMER_STOP on Tegra20, can we postpone to apply this?
I need more time to investigate how does this flag impact system.



From pavel at denx.de  Thu Jul 18 07:17:12 2013
From: pavel at denx.de (Pavel Machek)
Date: Thu, 18 Jul 2013 13:17:12 +0200
Subject: [PATCH] phy: micrel: Add definitions for common Micrel PHY
 registers
In-Reply-To: <1373929730-28130-1-git-send-email-dinguyen@altera.com>
References: <1373929730-28130-1-git-send-email-dinguyen@altera.com>
Message-ID: <20130718111712.GA1021@amd.pavel.ucw.cz>

On Mon 2013-07-15 18:08:50, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen at altera.com>
> 
> Add defines for common Micrel PHY setups so that other platforms
> can use them. Update imx61 and sama5 hardware to use the micrel_phy.h
> PHY defines.

Looks good to me.

> Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
> Cc: David S. Miller <davem at davemloft.net>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> CC: Andrew Victor <linux at maxim.org.za>
> CC: Nicolas Ferre <nicolas.ferre at atmel.com>
> CC: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>

Reviewed-by: Pavel Machek <pavel at denx.de>
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From broonie at kernel.org  Thu Jul 18 07:17:09 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Jul 2013 12:17:09 +0100
Subject: [PATCH] ASoC: atmel: add wm8904 based audio machine driver
In-Reply-To: <1374132483-25375-1-git-send-email-voice.shen@atmel.com>
References: <1374132483-25375-1-git-send-email-voice.shen@atmel.com>
Message-ID: <20130718111709.GL22506@sirena.org.uk>

On Thu, Jul 18, 2013 at 03:28:03PM +0800, Bo Shen wrote:
> add wm8904 based audio machine driver
> 
> the following ek board based on it
>   - at91sam9n12ek
>   - sama5d3xek (d31, d33, d34, d35)
> 
> Signed-off-by: Bo Shen <voice.shen at atmel.com>

Looks pretty good, a few fairly small issues below.

The binding document should be CCed to devicetree-discuss for review.

> +	atmel,audio-routing =
> +		"Headphone Jack", "HPOUTL",
> +		"Headphone Jack", "HPOUTR",
> +		"IN2L", "Line In Jack",
> +		"IN2R", "Line In Jack",
> +		"Mic", "MICBIAS",
> +		"IN1L", "Mic";

The widgets defined by the board should be documented in this binding.
Those from the CODEC should be documented in the CODEC binding.

> +#define MCLK_RATE 32768
> +
> +static struct clk *mclk;

This should be in driver data for the board.  Shouldn't the clock be
referenced using the clock bindings?

> +static int atmel_asoc_wm8904_init(struct snd_soc_pcm_runtime *rtd)
> +{
> +	struct snd_soc_dai *codec_dai = rtd->codec_dai;
> +	int ret;
> +
> +	ret = snd_soc_dai_set_sysclk(codec_dai, WM8904_CLK_FLL,
> +			12000000, SND_SOC_CLOCK_IN);
> +	if (ret < 0) {
> +		pr_err("%s -failed to set wm8904 SYSCLK\n", __func__);
> +		return ret;
> +	}

This is an odd thing to set the clock rate to and limits the sample
rates the board can play back.  It would be better to set the clock rate
based on the requested sample rate in hw_params - you're using the FLL
so may as well take advantage of the ability it offers to support all
sample rates.

> +static int atmel_asoc_wm8904_params(struct snd_pcm_substream *substream,
> +		struct snd_pcm_hw_params *params)
> +{
> +	struct snd_soc_pcm_runtime *rtd = substream->private_data;
> +	struct snd_soc_dai *codec_dai = rtd->codec_dai;
> +	int ret;
> +
> +	ret = snd_soc_dai_set_pll(codec_dai, WM8904_FLL_MCLK, WM8904_FLL_MCLK,
> +		32768, params_rate(params) * 256);

Ah, in fact you do actually do that - it'd be clearer to put the
set_sysclk() after this.

> +	switch (level) {
> +	case SND_SOC_BIAS_ON:
> +	case SND_SOC_BIAS_PREPARE:
> +		if (!mclk_on) {
> +			ret = clk_prepare_enable(mclk);
> +			if (ret == 0)
> +				mclk_on = 1;
> +		}
> +		break;
> +	case SND_SOC_BIAS_STANDBY:
> +	case SND_SOC_BIAS_OFF:
> +		if (mclk_on)
> +			clk_disable_unprepare(mclk);
> +		mclk_on = 0;
> +		break;
> +	}

It's better to write this using the previous state than to have the
mclk_on flag - you want to enable on the standby->prepare transition and
disable on the standby->off transition.

> +static int atmel_asoc_wm8904_dt_init(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct device_node *codec_np, *cpu_np;
> +	struct snd_soc_card *card = &atmel_asoc_wm8904_card;
> +	struct snd_soc_dai_link *dailink = &atmel_asoc_wm8904_dailink;
> +	int ret;
> +
> +	if (!np)
> +		return -1;

Return a real error code here.
-------------- 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/20130718/3d976bad/attachment.sig>

From grygorii.strashko at ti.com  Thu Jul 18 07:22:02 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Thu, 18 Jul 2013 14:22:02 +0300
Subject: [PATCH 2/3] ARM: OMAP2+: omap_device: add pinctrl handling
In-Reply-To: <20130718081405.GS7656@atomide.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
 <1374061312-25469-3-git-send-email-grygorii.strashko@ti.com>
 <20130717153838.GJ7656@atomide.com> <51E6CCB6.2000907@ti.com>
 <20130718081405.GS7656@atomide.com>
Message-ID: <51E7CFDA.6070600@ti.com>

On 07/18/2013 11:14 AM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko at ti.com> [130717 10:11]:
>> On 07/17/2013 06:38 PM, Tony Lindgren wrote:
>>> * Grygorii Strashko <grygorii.strashko at ti.com> [130717 04:49]:
>>>> Before switching to DT pinctrl states of OMAP IPs have been handled by hwmod
>>>> framework. After switching to DT-boot the pinctrl handling was dropped from
>>>> hwmod framework and, as it was recommended, OMAP IP's drivers have to be updated
>>>> to handle pinctrl states by itself using pinctrl_pm_select_xx() helpers
>>>> (see http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html)
>>>>
>>>> But this is not right for OMAP2+ SoC where real IPs state is controlled
>>>> by omap_device core which enables/disables modules & clocks actually.
>>>
>>> I'm not convinced we should try to handle this in a generic way
>>> as only some devices need dynamic remuxing of some pins.
>>>
>>>> For example, if OMAP I2C driver will handle pinctrl state during system wide
>>>> suspend the following issue may occure:
>>>> - suspend_noirq - I2C device can be still active because of PM auto-suspend
>>>>    |-_od_suspend_noirq
>>>>       |- omap_i2c_suspend_noirq
>>>>          |- PINs state set to SLEEP
>>>>    |- pm_generic_runtime_suspend
>>>>       |- omap_i2c_runtime_suspend()
>>>>          |- PINs state set to IDLE  <--- *oops* PINs state is IDLE and not SLEEP
>>>>    |- omap_device_idle()
>>>>       |- omap_hwmod_idle()
>>>>          |- _idle()
>>>>             |- disbale module (sysc&clocks)

Above call sequence explains what's going on when .suspend_noirq() is 
called - .suspend_noirq() handler ==> _od_suspend_noirq() and it's set 
for all OMAP2+ devices.


>>>
>>> And in this example you are assuming that you need separate idle and
>>> sleep states, which is not true at least for most cases I've seen.
>>
>> I don't need both states (at least right now) :), but
>> - if any OMAP2+ driver will have two states defined: "idle" and "sleep"
>> - and if it will try to manage them from drivers callbacks only using
>>    pure calls to pinctrl_pm_select_xx() helpers
>>
>> the "idle" state will be selected during suspend and *not* "sleep".
>
> But the drivers have separate calls for runtime PM and suspend/resume?

Yes, but for OMAP2+ everything is handled by OMAP device framework :)

>
>>> It is possible that am33xx needs separate idle and sleep states, but
>>> most likely only for some pins. For omap[345] we can get away with
>>> just the default state for most cases.
>>>
>>
>>
>> In case, if only "default" state is defined for device - nothing will
>>   be done by OMAP device framework for it (I mean any call to
>> pinctrl_pm_select_xx() will do nothing - it just checks that there is
>> no state and returns 0).
>
> If we want to automate something, it should be done at Linux generic
> level rather than at omap "bus" level. That sort of relates to drivers
> needing to know when they've lost context too, which should be
> implemented in Linux generic way.
>
> Regards,
>
> Tony
>



From broonie at kernel.org  Thu Jul 18 07:25:38 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Jul 2013 12:25:38 +0100
Subject: [PATCH v4 5/5] ASoC: atmel-ssc: remove clk_disable_unprepare
 call from critical section
In-Reply-To: <1374133720-27362-1-git-send-email-b.brezillon@overkiz.com>
References: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
 <1374133720-27362-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <20130718112538.GM22506@sirena.org.uk>

On Thu, Jul 18, 2013 at 09:48:40AM +0200, Boris BREZILLON wrote:
> clk_prepare/unprepare (and indirectly clk_prepare_enable/disable_unprepare)
> may sleep and thus cannot be called in critical section.

Applied, thanks.
-------------- 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/20130718/6a63d4cf/attachment-0001.sig>

From pavel at denx.de  Thu Jul 18 07:25:55 2013
From: pavel at denx.de (Pavel Machek)
Date: Thu, 18 Jul 2013 13:25:55 +0200
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <51E719A6.6070105@wwwdotorg.org>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <20130716041056.GA30067@S2101-09.ap.freescale.net>
 <51E56AA7.7020103@wwwdotorg.org>
 <20130717030246.GA4541@S2101-09.ap.freescale.net>
 <51E6CCE4.20705@wwwdotorg.org>
 <20130717213836.GA13324@amd.pavel.ucw.cz>
 <51E719A6.6070105@wwwdotorg.org>
Message-ID: <20130718112555.GB1021@amd.pavel.ucw.cz>

Hi!

> >>> I do not quite follow the argument here.  I agree with you that
> >>> deferred probe is the approach to solve dependencies.  But it does not
> >>> necessarily mean that initcall can not be used to help it save some
> >>> nasty or nested deferring.  Deferred probe and initcalls are not two
> >>> mutually exclusive mechanisms but two which can help each other.
> >>
> >> My understanding is that deferred probe was implemented specifically to
> >> avoid having to, or allowing, the use of initcall levels to determine
> >> probe order.
> >>
> >> However, if someone closely associated with the implementation of
> >> deferred probe (e.g. Grant, or a device core maintainer) is willing to
> >> step up and say I'm wrong, I'll drop my objection.
> > 
> > AFAIR, defered probing is known to be a "hack" by its authors. We
> > should still try to get initcall levels right...
> 
> I don't /think/ it was the concept of deferred probe that was considered
> hacky, but perhaps just the first proof-of-concept implementation, and
> any hackiness was presumably solved before the feature was merged.

Well...

http://lwn.net/Articles/485194/

From:		Grant Likely <grant.likely at secretlab.ca>
To:		      linux-kernel at vger.kernel.org
Subject:		[PATCH] drivercore: Add driver probe deferral
mechanism
Date:		Mon, 5 Mar 2012 08:47:41 -0700
Message-ID:
<1330962461-9061-1-git-send-email-grant.likely at secretlab.ca>
...

I know that not everybody is happy with this approach, but I've yet to
see a better alternative.  However, it is *really easy* to find all
the
users of deferred probe since any user must return -EPROBE_DEFER
explicitly.
If/when a better approach is found, all the users will be easy to find
and modify.

...

It sound to me like keeping ammount of -EPROBE_DEFER to minimum is
still preferred.

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From b.brezillon at overkiz.com  Thu Jul 18 07:33:49 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Thu, 18 Jul 2013 13:33:49 +0200
Subject: [PATCH v4 5/5] ASoC: atmel-ssc: remove clk_disable_unprepare
 call from critical section
In-Reply-To: <20130718105846.GJ22506@sirena.org.uk>
References: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
 <1374133720-27362-1-git-send-email-b.brezillon@overkiz.com>
 <20130718095337.GD22506@sirena.org.uk> <51E7C1B2.8000206@overkiz.com>
 <20130718105846.GJ22506@sirena.org.uk>
Message-ID: <51E7D29D.3000008@overkiz.com>

On 18/07/2013 12:58, Mark Brown wrote:
> On Thu, Jul 18, 2013 at 12:21:38PM +0200, boris brezillon wrote:
>
>> I can send you the whole series if you want (already sent to LKML
>> and LAKML).
>> But I'd like to understand who I should send patches from this series to.
> When you send me patch 5/5 with no other information on the rest of the
> series I've no idea if there's any dependencies on the other code or
> anything like that.  The key thing here is to make sure the people
> getting the patch can understand the interdependencies somehow.
>
> If you're sending a bunch of unrelated changes with no dependencies
> you're better off sending them all separately rather than as a part of a
> series.
Noted, I will send each patch separately next time (if they are unrelated).


From b.brezillon at overkiz.com  Thu Jul 18 07:34:11 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Thu, 18 Jul 2013 13:34:11 +0200
Subject: [PATCH v4 5/5] ASoC: atmel-ssc: remove clk_disable_unprepare
 call from critical section
In-Reply-To: <20130718112538.GM22506@sirena.org.uk>
References: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
 <1374133720-27362-1-git-send-email-b.brezillon@overkiz.com>
 <20130718112538.GM22506@sirena.org.uk>
Message-ID: <51E7D2B3.5070006@overkiz.com>

On 18/07/2013 13:25, Mark Brown wrote:
> On Thu, Jul 18, 2013 at 09:48:40AM +0200, Boris BREZILLON wrote:
>> clk_prepare/unprepare (and indirectly clk_prepare_enable/disable_unprepare)
>> may sleep and thus cannot be called in critical section.
> Applied, thanks.
Thanks


From ml at communistcode.co.uk  Thu Jul 18 07:35:51 2013
From: ml at communistcode.co.uk (Jack Mitchell)
Date: Thu, 18 Jul 2013 12:35:51 +0100
Subject: [PATCH 0/4] Enable ethernet support for SOCFPGA
In-Reply-To: <51E7B27F.2000304@communistcode.co.uk>
References: <1374102623-4154-1-git-send-email-dinguyen@altera.com>
 <51E7B27F.2000304@communistcode.co.uk>
Message-ID: <51E7D317.50101@communistcode.co.uk>

On 18/07/13 10:16, Jack Mitchell wrote:
> On 18/07/13 00:10, dinguyen at altera.com wrote:
>> From: Dinh Nguyen <dinguyen at altera.com>
>>
>> Hello,
>>
>> These 4 patches are meant to enable ethernet and SD/MMC for the SOCFPGA
>> platform.
>>
>> patch (1/4): Adds select ARM_TWD for the platform
>> patch (2/4): Add platform specific initialization for the ethernet
>> controller.
>> patch (3/4): Commit 25c83b5c2 added "snps,phy-addr" for getting the
>> PHY addr.
>>          Set the ethernet clocks to be emac_0_clk and emac_1_clk so it
>> be gated.
>> patch (4/4): Update defconfig to support SD/MMC, ethernet, EXT3 and NFS.
>>
>> Thanks,
>>
>> Dinh Nguyen (4):
>>    arm: socfpga: Enable ARM_TWD for socfpga
>>    arm: socfpga: Add platform initialization for ethernet
>>    ARM: socfpga: dts: Fix entries for the ethernet entries.
>>    arm: socfpga: Add support for SD/MMC and ethernet to defconfig
>>
>>   arch/arm/boot/dts/socfpga.dtsi         |    4 +-
>>   arch/arm/boot/dts/socfpga_cyclone5.dts |    2 +-
>>   arch/arm/configs/socfpga_defconfig     |    8 +++
>>   arch/arm/mach-socfpga/Kconfig          |    1 +
>>   arch/arm/mach-socfpga/core.h           |    8 +++
>>   arch/arm/mach-socfpga/socfpga.c        |   85
>> +++++++++++++++++++++++++++++++-
>>   6 files changed, 104 insertions(+), 4 deletions(-)
>>
>> CC: Arnd Bergmann <arnd at arndb.de>
>> CC: Olof Johansson <olof at lixom.net>
>> Cc: Rob Herring <rob.herring at calxeda.com>
>> Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>> Cc: Pavel Machek <pavel at denx.de>
>> Cc: Jack Mitchell <jack.mitchell at dbbroadcast.co.uk>
>>
> 
> Hi Dinh,
> 
> What tree is this based against, or what patches are a pre-requisite to
> this series? I applied the patches to linux-arm/master but the compile
> failed.
> 
> arch/arm/mach-socfpga/socfpga.c: In function 'ksz9021rlrn_phy_fixup':
> arch/arm/mach-socfpga/socfpga.c:85:21: error:
> 'MICREL_KSZ9021_EXTREG_CTRL' undeclared (first use in this function)
>    phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
>                      ^
> arch/arm/mach-socfpga/socfpga.c:85:21: note: each undeclared identifier
> is reported only once for each function it appears in
> arch/arm/mach-socfpga/socfpga.c:86:4: error:
> 'MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW' undeclared (first use in this
> function)
>     MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW | 0x8000);
>     ^
> arch/arm/mach-socfpga/socfpga.c:87:21: error:
> 'MICREL_KSZ9021_EXTREG_DATA_WRITE' undeclared (first use in this function)
>    phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
>                      ^
> arch/arm/mach-socfpga/socfpga.c:91:4: error:
> 'MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW' undeclared (first use in this
> function)
>     MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW | 0x8000);
>     ^
> arch/arm/mach-socfpga/socfpga.c: In function 'socfpga_cyclone5_init':
> arch/arm/mach-socfpga/socfpga.c:193:30: error: 'PHY_ID_KSZ9021RLRN'
> undeclared (first use in this function)
>    phy_register_fixup_for_uid(PHY_ID_KSZ9021RLRN,
>                               ^
> Cheers,
> Jack.
> 

Dinh,

So I found your patch "phy: micrel: Add definitions for common Micrel
PHY registers" and applied it, now the kernel compiles. I do however
still run into the "Waiting for root device" issue. This is still on my
Arrow SoCkit board, which may be a bit different to the Altera devkit;
so please don't let this be a blocker if it works find with your kit. It
is strange though that both boards can share the same 3.9-vendor
dts/kernel without any changes...

Synopsys Designware Multimedia Card Interface Driver
oprofile: no performance counters
oprofile: using timer interrupt.
TCP: cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
ThumbEE CPU extension supported.
Registering SWP/SWPB emulation handler
Waiting for root device /dev/mmcblk0p2...

Cheers,
Jack.




-- 

  Jack Mitchell (jack at embed.me.uk)
  Embedded Systems Engineer
  http://www.embed.me.uk

--


From thomas.petazzoni at free-electrons.com  Thu Jul 18 07:43:30 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 18 Jul 2013 13:43:30 +0200
Subject: Audio issue on Kirkwood t5325: no sound
Message-ID: <20130718134330.5aea00c5@skate>

Hello,

As part of some work around audio support on Marvell platforms, I've
taken the Kirkwood-based HP t5325 thin client device that Martin
Michlmayr kindly gave me and tried to use the audio part of it, with
kernel 3.11-rc1. (My plan is to write the Device Tree binding for this
audio driver, and then use it for Armada 370 based platforms).

My kernel configuration has the following options enabled:

CONFIG_SND_SOC=y
CONFIG_SND_KIRKWOOD_SOC=y
CONFIG_SND_KIRKWOOD_SOC_I2S=y
CONFIG_SND_KIRKWOOD_SOC_OPENRD=y
CONFIG_SND_KIRKWOOD_SOC_T5325=y
CONFIG_SND_SOC_I2C_AND_SPI=y
CONFIG_SND_SOC_ALC5623=y
CONFIG_SND_SOC_CS42L51=y

So both the Kirkwood audio driver is enabled, the t5325-specific
machine audio driver, and the ALC5623 codec. When booting, the system
says:

t5325-audio t5325-audio:  alc5621-hifi <-> kirkwood-i2s mapping ok
[...]
ALSA device list:
  #0: t5325

I can actually use aplay to play a sound, it plays fine, except that
nothing goes out on the headphone jack, as if it was muted:

# aplay sensation.wav 
Playing WAVE 'sensation.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
#

I've unmuted all volume controls, and pushed all of them to the max
value, as can be seen from the following amixer output:

# amixer 
Simple mixer control 'Headphone',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 31 [100%] [0.00dB] [on]
  Front Right: Playback 31 [100%] [0.00dB] [on]
Simple mixer control 'Speaker',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 31 [100%] [0.00dB] [on]
  Front Right: Playback 31 [100%] [0.00dB] [on]
Simple mixer control 'Speaker Mix AUXI2SPK',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'Speaker Mix DAC2SPK',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'Speaker Mix LI2SPK',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'Speaker Mix MIC12SPK',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'Speaker Mix MIC22SPK',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'SpeakerOut Mux',0
  Capabilities: enum
  Items: 'Vmid' 'HPOut Mix' 'Speaker Mix' 'Mono Mix'
  Item0: 'Vmid'
Simple mixer control 'SpeakerOut N Mux',0
  Capabilities: enum
  Items: 'RN/-R' 'RP/+R' 'LN/-R' 'Vmid'
  Item0: 'Vmid'
Simple mixer control 'PCM',0
  Capabilities: pvolume
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 31 [100%] [12.00dB]
  Front Right: Playback 31 [100%] [12.00dB]
Simple mixer control 'LineIn',0
  Capabilities: cvolume
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 31
  Front Left: Capture 31 [100%] [12.00dB]
  Front Right: Capture 31 [100%] [12.00dB]
Simple mixer control 'Mic 1 Boost',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 2
  Mono: 0 [0%] [0.00dB]
Simple mixer control 'Mic 2 Boost',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 2
  Mono: 0 [0%] [0.00dB]
Simple mixer control 'Mic1',0
  Capabilities: cvolume cvolume-joined
  Capture channels: Mono
  Limits: Capture 0 - 31
  Mono: Capture 23 [74%] [0.00dB]
Simple mixer control 'Mic2',0
  Capabilities: cvolume cvolume-joined
  Capture channels: Mono
  Limits: Capture 0 - 31
  Mono: Capture 23 [74%] [0.00dB]
Simple mixer control 'AuxI',0
  Capabilities: cvolume
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 31
  Front Left: Capture 23 [74%] [0.00dB]
  Front Right: Capture 23 [74%] [0.00dB]
Simple mixer control 'AuxOut Mux',0
  Capabilities: enum
  Items: 'Vmid' 'HPOut Mix' 'Speaker Mix' 'Mono Mix'
  Item0: 'Vmid'
Simple mixer control 'Auxout',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 31 [100%] [0.00dB] [on]
  Front Right: Playback 31 [100%] [0.00dB] [on]
Simple mixer control 'Mono Mix ADC2MONO_L',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'Mono Mix ADC2MONO_R',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'Mono Mix AUXI2MONO',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'Mono Mix DAC2MONO',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'Mono Mix LI2MONO',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'Mono Mix MIC12MONO',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'Mono Mix MIC22MONO',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'AB-D Amp Mux',0
  Capabilities: enum
  Items: 'AB Amp' 'D Amp'
  Item0: 'AB Amp'
Simple mixer control 'Digital Boost',0
  Capabilities: volume volume-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 3
  Mono: 3 [100%] [18.00dB]
Simple mixer control 'HP Mix AUXI2HP',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'HP Mix DAC2HP',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'HP Mix LI2HP',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'HP Mix MIC12HP',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'HP Mix MIC22HP',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'HPL Mix ADC2HP_L',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'HPR Mix ADC2HP_R',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'Left Capture Mix HPMixerL',0
  Capabilities: cswitch cswitch-joined
  Capture channels: Mono
  Mono: Capture [off]
Simple mixer control 'Left Capture Mix Left AuxI',0
  Capabilities: cswitch cswitch-joined
  Capture channels: Mono
  Mono: Capture [off]
Simple mixer control 'Left Capture Mix LineInL',0
  Capabilities: cswitch cswitch-joined
  Capture channels: Mono
  Mono: Capture [off]
Simple mixer control 'Left Capture Mix Mic1',0
  Capabilities: cswitch cswitch-joined
  Capture channels: Mono
  Mono: Capture [off]
Simple mixer control 'Left Capture Mix Mic2',0
  Capabilities: cswitch cswitch-joined
  Capture channels: Mono
  Mono: Capture [off]
Simple mixer control 'Left Capture Mix MonoMixer',0
  Capabilities: cswitch cswitch-joined
  Capture channels: Mono
  Mono: Capture [off]
Simple mixer control 'Left Capture Mix SPKMixer',0
  Capabilities: cswitch cswitch-joined
  Capture channels: Mono
  Mono: Capture [off]
Simple mixer control 'Left Headphone Mux',0
  Capabilities: enum
  Items: 'Vmid' 'HP Left Mix'
  Item0: 'Vmid'
Simple mixer control 'Rec',0
  Capabilities: cvolume
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 31
  Front Left: Capture 11 [35%] [0.00dB]
  Front Right: Capture 11 [35%] [0.00dB]
Simple mixer control 'Right Capture Mix HPMixerR',0
  Capabilities: cswitch cswitch-joined
  Capture channels: Mono
  Mono: Capture [off]
Simple mixer control 'Right Capture Mix LineInR',0
  Capabilities: cswitch cswitch-joined
  Capture channels: Mono
  Mono: Capture [off]
Simple mixer control 'Right Capture Mix Mic1',0
  Capabilities: cswitch cswitch-joined
  Capture channels: Mono
  Mono: Capture [off]
Simple mixer control 'Right Capture Mix Mic2',0
  Capabilities: cswitch cswitch-joined
  Capture channels: Mono
  Mono: Capture [off]
Simple mixer control 'Right Capture Mix MonoMixer',0
  Capabilities: cswitch cswitch-joined
  Capture channels: Mono
  Mono: Capture [off]
Simple mixer control 'Right Capture Mix Right AuxI',0
  Capabilities: cswitch cswitch-joined
  Capture channels: Mono
  Mono: Capture [off]
Simple mixer control 'Right Capture Mix SPKMixer',0
  Capabilities: cswitch cswitch-joined
  Capture channels: Mono
  Mono: Capture [off]
Simple mixer control 'Right Headphone Mux',0
  Capabilities: enum
  Items: 'Vmid' 'HP Right Mix'
  Item0: 'Vmid'

There are no kernel errors in the log, nothing that looks suspicious.
Is there anything I've missed?

I've posted the complete kernel configuration at:
 http://free-electrons.com/~thomas/pub/kirkwood-audio-kernel.config

And the complete kernel log at:
 http://free-electrons.com/~thomas/pub/kirkwood-audio-kernel.log

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From jonas.jensen at gmail.com  Thu Jul 18 07:55:26 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Thu, 18 Jul 2013 13:55:26 +0200
Subject: [PATCH v3] clk: add MOXA ART SoCs clock driver
In-Reply-To: <20130718110201.GB29153@e106331-lin.cambridge.arm.com>
References: <1372943292-6960-1-git-send-email-jonas.jensen@gmail.com>
 <1374067396-30155-1-git-send-email-jonas.jensen@gmail.com>
 <20130718095035.GA29153@e106331-lin.cambridge.arm.com>
 <CACmBeS2SnpiUtiQD6j9qyaXZ5-chHSHVeo4c5=UhitVonvkKtw@mail.gmail.com>
 <20130718110201.GB29153@e106331-lin.cambridge.arm.com>
Message-ID: <CACmBeS24smrJ4SLY7snv1_6SRcuXRkZ8t0PGMvBupUpKMMb43w@mail.gmail.com>

On 18 July 2013 13:02, Mark Rutland <mark.rutland at arm.com> wrote:
> Ok. I'm just concerned that the linkage isn't explicit or obvious.

> This does leave apb-clock completely dependent on core-clock, and unless
> I've missed something there's no linkage between the two described in
> the dt.

I can add a description in the core-clock binding and also for
apb-clock pointing
out that it's set from core-clock.

> How does core-clock physically relate to apb-clock? Does it feed or is
> it fed by apb-clock?

apb-clock is entirely a DT construct used by drivers to get the fixed
rate 48MHz.
It's not fed by core-clock more than what happens in probe.

For UC-7112-LX, drivers using apb-clock are: clocksource, MMC, watchdog

Because clocksource relies on apb-clock, a successful probe of
core-clock is critical.

Commonly, drivers look up the apb-clock node and call clk_get_rate.

> Are we always guaranteed to have core-clock if we have apb-clock, and is
> it part of the same block in hardware? If so we could describe the
> amalgamation as a provider with two clock outputs, with core-clock's
> registers for configuration at probe-time.

Yes, as described above, there can not be a apb-clock without core-clock.


I think drivers could find and use core-clock instead. Maybe the abstraction
of apb-clock is unnecessary?


Best regards,
Jonas


From shawn.guo at linaro.org  Thu Jul 18 07:55:45 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 18 Jul 2013 19:55:45 +0800
Subject: [PATCH 4/4] ARM: imx6q: remove board specific CLKO setup
In-Reply-To: <20130718083603.GK10380@pengutronix.de>
References: <1374132670-791-1-git-send-email-shawn.guo@linaro.org>
 <1374132670-791-5-git-send-email-shawn.guo@linaro.org>
 <20130718083603.GK10380@pengutronix.de>
Message-ID: <20130718115541.GA16328@S2101-09.ap.freescale.net>

On Thu, Jul 18, 2013 at 10:36:03AM +0200, Sascha Hauer wrote:
> On Thu, Jul 18, 2013 at 03:31:10PM +0800, Shawn Guo wrote:
> > The CLKO is widely used by imx6q board designs to clock audio codec.
> > Since most codecs accept 24 MHz frequency, let's initially set up CLKO
> > with OSC24M (cko <-- cko2 <-- osc).  Then those board specific CLKO
> > setup for audio codec can be removed.
> > 
> > The board dts files also need an update on cko reference in codec node.
> > 
> > +	/*
> > +	 * Let's initially set up CLKO with OSC24M, since this configuration
> > +	 * is widely used by imx6q board designs to clock audio codec.
> > +	 */
> > +	ret = clk_set_parent(clk[cko2_sel], clk[osc]);
> > +	if (!ret)
> > +		ret = clk_set_parent(clk[cko], clk[cko2]);
> > +	if (ret)
> > +		pr_warn("failed to set up CLKO: %d\n", ret);
> 
> 
> I don't really like that the clock setup code fiddles with clocks it has
> no knowledge about just because it happens to be correct for several
> boards.

I have to admit it's not the best way to handle it, and I can understand
your concern.  What I like about it is we can remove those board
specific hooks from mach-imx6q.c at least for now.

> 
> I currently have no example where this bites me, so I think I can live
> with it for now. I just wonder what I should do when this clock is used
> for something vital to the system (clocking an FPGA for example?).

Go back to set up CLKO in mach-imx6q.c with board specific hook for the
system?

I think I chose to change the default CLKO setup for audio use case, as
all the users we've seen so far is audio codec.  I can still have this
setup done in mach-imx6q.c with of_machine_is_compatible() check on all
those board.  But that also means we need to register lookups for those
CLKO clocks and call clk_get_sys() to get them.

Shawn



From p.zabel at pengutronix.de  Thu Jul 18 07:57:33 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 18 Jul 2013 13:57:33 +0200
Subject: [PATCH] reset: allow drivers to request probe deferral
Message-ID: <1374148653-14009-1-git-send-email-p.zabel@pengutronix.de>

If the requested reset controller is not yet available, have reset_control_get
and device_reset return -EPROBE_DEFER so the driver can decide to request
probe deferral.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/reset/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index d1b6089..b3d99a1 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -167,7 +167,7 @@ struct reset_control *reset_control_get(struct device *dev, const char *id)
 
 	if (!rcdev) {
 		mutex_unlock(&reset_controller_list_mutex);
-		return ERR_PTR(-ENODEV);
+		return ERR_PTR(-EPROBE_DEFER);
 	}
 
 	rstc_id = rcdev->of_xlate(rcdev, &args);
-- 
1.8.3.2



From shawn.guo at linaro.org  Thu Jul 18 07:59:18 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 18 Jul 2013 19:59:18 +0800
Subject: [RFC] Split i.MX pinctrl groups
In-Reply-To: <1374133571-7660-1-git-send-email-s.hauer@pengutronix.de>
References: <1374133571-7660-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <20130718115915.GB16328@S2101-09.ap.freescale.net>

On Thu, Jul 18, 2013 at 09:46:07AM +0200, Sascha Hauer wrote:
> We currently introduce completely new pinctrl groups for each slight
> variant of the pinctrl setup of a device. For several devices the
> groups can be split into smaller groups to increase the flexibility
> and to reduce the devicetree sizes (both source and dtb).
> 
> For example SDHC controller groups can be split into a base group
> and an 8bit extension. The FEC groups can be split into base group
> and several MDIO groups. The UARTs can be split into a base group
> and RTS/CTS extensions.
> 
> Doing this makes the group names more obvious. Instead of having
> just index _1, _2 and so on we now have base_1, 8bit_1.
> 
> This is not meant for inclusion right now, just some preliminary
> patches to demonstrate the idea to see if this is acceptable/desired.

Yes, it makes sense to me.

Shawn



From pavel at denx.de  Thu Jul 18 07:59:51 2013
From: pavel at denx.de (Pavel Machek)
Date: Thu, 18 Jul 2013 13:59:51 +0200
Subject: [PATCH 0/4] Enable ethernet support for SOCFPGA
In-Reply-To: <51E7B27F.2000304@communistcode.co.uk>
References: <1374102623-4154-1-git-send-email-dinguyen@altera.com>
 <51E7B27F.2000304@communistcode.co.uk>
Message-ID: <20130718115951.GA2706@amd.pavel.ucw.cz>

Hi!

> >These 4 patches are meant to enable ethernet and SD/MMC for the SOCFPGA
> >platform.
> >
> >patch (1/4): Adds select ARM_TWD for the platform
> >patch (2/4): Add platform specific initialization for the ethernet controller.
> >patch (3/4): Commit 25c83b5c2 added "snps,phy-addr" for getting the PHY addr.
> >         Set the ethernet clocks to be emac_0_clk and emac_1_clk so it be gated.
> >patch (4/4): Update defconfig to support SD/MMC, ethernet, EXT3 and NFS.

> What tree is this based against, or what patches are a pre-requisite
> to this series? I applied the patches to linux-arm/master but the
> compile failed.
> 
> arch/arm/mach-socfpga/socfpga.c: In function 'ksz9021rlrn_phy_fixup':
> arch/arm/mach-socfpga/socfpga.c:85:21: error:
> 'MICREL_KSZ9021_EXTREG_CTRL' undeclared (first use in this function)
>    phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
>                      ^

It seems it depends on:

Date: Mon, 15 Jul 2013 18:08:50 -0500
From: dinguyen at altera.com
To: dinh.linux at gmail.com, netdev at vger.kernel.org
Cc: Pavel Machek <pavel at denx.de>, Nicolas Ferre
<nicolas.ferre at atmel.com>,
        "David S. Miller" <davem at davemloft.net>,
        linux-arm-kernel at lists.infradead.org,
        Shawn Guo <shawn.guo at linaro.org>,
        Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>,
        Andrew Victor <linux at maxim.org.za>,
        Dinh Nguyen <dinguyen at altera.com>
Subject: [PATCH] phy: micrel: Add definitions for common Micrel PHY
registers
X-Mailer: git-send-email 1.7.9.5

From: Dinh Nguyen <dinguyen at altera.com>

Add defines for common Micrel PHY setups so that other platforms
can use them. Update imx61 and sama5 hardware to use the micrel_phy.h
PHY defines.

Also add support for the KSZ9021RLRN PHY.

Signed-off-by: Dinh Nguyen <dinguyen at altera.com>

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From zonque at gmail.com  Thu Jul 18 08:02:24 2013
From: zonque at gmail.com (Daniel Mack)
Date: Thu, 18 Jul 2013 14:02:24 +0200
Subject: [PATCH] ARM: omap2: fix musb usage for n8x0
In-Reply-To: <51E7B81A.70103@denx.de>
References: <1374000777-5626-1-git-send-email-zonque@gmail.com>
 <51E7B1FF.6000301@denx.de> <51E7B2FA.7020206@ti.com> <51E7B81A.70103@denx.de>
Message-ID: <51E7D950.60900@gmail.com>

On 18.07.2013 11:40, Stefan Roese wrote:
> On 07/18/2013 11:18 AM, Kishon Vijay Abraham I wrote:
>>> I'm testing musb as OTG on beagleboard (old one, not Beagle-xm). And
>>> using the latest kernel.org version with this patch applied I see the
>>> following messages while booting (repeatedly):
>>>
>>> [    4.998168] usb usb1: bus auto-suspend, wakeup 1
>>> [    5.003112] musb_bus_suspend 2457: trying to suspend as b_idle while active
>>> [    5.010498] usb usb1: bus suspend fail, err -16
>>> [    5.015289] hub 1-0:1.0: hub_resume
>>> [    5.019073] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
>>> [    5.024963] hub 1-0:1.0: hub_suspend
>>> [    5.028778] usb usb1: bus auto-suspend, wakeup 1
>>> ...
>>>
>>> This is without a cable connected to the OTG port.
>>>
>>> Any ideas what might be missing here?
>>
>> Even I observed these prints when I have dual mode enabled. When kept as gadget
>> only mode I dint see these prints.
> 
> Yes. With gadget-only I don't see those messages. Thanks for the hint.

So in which mode does your port operate then? Gadget or dual-role? And I
take it this does not happen with 3.10?

Unfortunately, I have no board here anymore with such a port in
dual-role mode ...


Daniel



From grygorii.strashko at ti.com  Thu Jul 18 08:01:17 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Thu, 18 Jul 2013 15:01:17 +0300
Subject: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for
 uart3/4
In-Reply-To: <20130718090408.GU7656@atomide.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
 <1374061312-25469-4-git-send-email-grygorii.strashko@ti.com>
 <20130717153248.GI7656@atomide.com> <51E6C939.40208@ti.com>
 <20130718080953.GR7656@atomide.com> <51E7AD38.6010108@ti.com>
 <20130718090408.GU7656@atomide.com>
Message-ID: <51E7D90D.6070101@ti.com>

Hi Tony,

On 07/18/2013 12:04 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko at ti.com> [130718 02:01]:
>> On 07/18/2013 11:09 AM, Tony Lindgren wrote:
>>
>> Don't think it's debug code - IO chain need to be rearmed after each
>> PRCM IO IRQ - otherwise IO wakeup events may be lost (at least on
>> OMAP4, OMAP5 requires more complex handling(( ).
>
> Nope, only after the mux register changes. I've verified it on
> am3730 with off-idle for both serial and wl12xx.

Unfortunately, there is a possibility to lose wake up events in case if
IO daisy chain will be rearmed (this will clean up all WAKEUPEVENT bits)
while there is some pending  WAKEUP event present. In this case, 
pcs_omap_handle_irq() will not call generic_handle_irq(wakeirq).

The below patch contains explanation of such kind of issue we've solved
in K3.4
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=5ff316db224a2c3c23bfe44261275d520b4f78bb

Currently, in Mainline the same is possible on OMAP4 (which is SMP) if
some Device will be switched to idle and rearm IO chain while there is
pending WAKEUP event form USB for example. So, IO rearming need to be 
delayed until PRCM irq will be served served and PRCM irq handler should 
finally rearm IO daisy chain.


>
>> I didn't pick up your padconf patches yet -seems i need to be in sync :)
>
> Well you need those for proper wake-up event support..
>
>> Below the diff I used to verify IO wake up (It follows old IO daisy
>> chain hanlding models in hwmod before DT):
>
> ..then these changes not needed with the pinctrl-single changes.
>
> Regards,
>
> Tony
>



From shawn.guo at linaro.org  Thu Jul 18 08:04:52 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 18 Jul 2013 20:04:52 +0800
Subject: [PATCH] reset: allow drivers to request probe deferral
In-Reply-To: <1374148653-14009-1-git-send-email-p.zabel@pengutronix.de>
References: <1374148653-14009-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20130718120448.GC16328@S2101-09.ap.freescale.net>

On Thu, Jul 18, 2013 at 01:57:33PM +0200, Philipp Zabel wrote:
> If the requested reset controller is not yet available, have reset_control_get
> and device_reset return -EPROBE_DEFER so the driver can decide to request
> probe deferral.
> 
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> ---
>  drivers/reset/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/core.c b/drivers/reset/core.c
> index d1b6089..b3d99a1 100644
> --- a/drivers/reset/core.c
> +++ b/drivers/reset/core.c
> @@ -167,7 +167,7 @@ struct reset_control *reset_control_get(struct device *dev, const char *id)
>  
>  	if (!rcdev) {
>  		mutex_unlock(&reset_controller_list_mutex);
> -		return ERR_PTR(-ENODEV);
> +		return ERR_PTR(-EPROBE_DEFER);

Yeah, with the change the client device driver does not need to
translate error code -ENODEV into -EPROBE_DEFER, but just return
whatever device_reset() returns in error case.  So,

Acked-by: Shawn Guo <shawn.guo at linaro.org>

>  	}
>  
>  	rstc_id = rcdev->of_xlate(rcdev, &args);
> -- 
> 1.8.3.2
> 



From shawn.guo at linaro.org  Thu Jul 18 08:06:04 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 18 Jul 2013 20:06:04 +0800
Subject: [PATCH v10] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <1374139586-6344-1-git-send-email-p.zabel@pengutronix.de>
References: <1374139586-6344-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20130718120600.GD16328@S2101-09.ap.freescale.net>

On Thu, Jul 18, 2013 at 11:26:26AM +0200, Philipp Zabel wrote:
> This driver implements a reset controller device that toggle a gpio
> connected to a reset pin of a peripheral IC. The delay between assertion
> and de-assertion of the reset signal can be configured via device tree.
> 
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> Reviewed-by: Stephen Warren <swarren at nvidia.com>

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



From nicolas.ferre at atmel.com  Thu Jul 18 08:36:23 2013
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 18 Jul 2013 14:36:23 +0200
Subject: [PATCH V2 5/8] serial: at91: support run time switch transfer mode
In-Reply-To: <51E7B37C.5090105@atmel.com>
References: <1373942627-7121-1-git-send-email-elen.song@atmel.com>
 <1373942627-7121-6-git-send-email-elen.song@atmel.com>
 <20130718081520.GC16015@ns203013.ovh.net> <51E7B37C.5090105@atmel.com>
Message-ID: <51E7E147.30104@atmel.com>

On 18/07/2013 11:21, elen.song :
> Hi JC:
> On 7/18/2013 4:15 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 10:43 Tue 16 Jul     , Elen Song wrote:
>>> We will switch to pio mode when request of dma or pdc fail.
>>> But soon or later, when the request is success, the transfer mode can switch to them at
>>> next open serial port action.
>>> So in startup stage, we should get original transfer mode.
>> You need to update the Documentation of the binding to said the driver support
>> dmas bindings for the new IP
>
> one question, it seems the document should write like:
>
> use DMA:
>       usart0: serial at f001c000{
>           compatible = "atmel,at91sam9260-usart";
>           dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(3)>,
>                        <&dma0 2
> (AT91_DMA_CFG_PER_ID(3)|AT91_DMA_CFG_FIFOCFG_ASAP)>;
>           dma-names = "tx","rx";
> };
>
> Should I replace macros with typical values?

Yes. That is the common rule for DT documentation.

Bye,
-- 
Nicolas Ferre


From sr at denx.de  Thu Jul 18 08:38:09 2013
From: sr at denx.de (Stefan Roese)
Date: Thu, 18 Jul 2013 14:38:09 +0200
Subject: [PATCH] ARM: omap2: fix musb usage for n8x0
In-Reply-To: <51E7D950.60900@gmail.com>
References: <1374000777-5626-1-git-send-email-zonque@gmail.com>
 <51E7B1FF.6000301@denx.de> <51E7B2FA.7020206@ti.com> <51E7B81A.70103@denx.de>
 <51E7D950.60900@gmail.com>
Message-ID: <51E7E1B1.4070407@denx.de>

On 07/18/2013 02:02 PM, Daniel Mack wrote:
> On 18.07.2013 11:40, Stefan Roese wrote:
>> On 07/18/2013 11:18 AM, Kishon Vijay Abraham I wrote:
>>>> I'm testing musb as OTG on beagleboard (old one, not Beagle-xm). And
>>>> using the latest kernel.org version with this patch applied I see the
>>>> following messages while booting (repeatedly):
>>>>
>>>> [    4.998168] usb usb1: bus auto-suspend, wakeup 1
>>>> [    5.003112] musb_bus_suspend 2457: trying to suspend as b_idle while active
>>>> [    5.010498] usb usb1: bus suspend fail, err -16
>>>> [    5.015289] hub 1-0:1.0: hub_resume
>>>> [    5.019073] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
>>>> [    5.024963] hub 1-0:1.0: hub_suspend
>>>> [    5.028778] usb usb1: bus auto-suspend, wakeup 1
>>>> ...
>>>>
>>>> This is without a cable connected to the OTG port.
>>>>
>>>> Any ideas what might be missing here?
>>>
>>> Even I observed these prints when I have dual mode enabled. When kept as gadget
>>> only mode I dint see these prints.
>>
>> Yes. With gadget-only I don't see those messages. Thanks for the hint.
> 
> So in which mode does your port operate then? Gadget or dual-role?

Its the original Beagleboard (revision C2), so I suppose its dual-role.
Or am I mistaken here?

> And I
> take it this does not happen with 3.10?

I just checked v3.10 as again. No, I'm not seeing these messages here.

Thanks,
Stefan



From daniel.lezcano at linaro.org  Thu Jul 18 08:41:31 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 18 Jul 2013 14:41:31 +0200
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <1374145726.5610.73.camel@jlo-ubuntu-64.nvidia.com>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
 <51E6FF0B.5000708@wwwdotorg.org>
 <1374145726.5610.73.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <51E7E27B.9090605@linaro.org>

On 07/18/2013 01:08 PM, Joseph Lo wrote:
> On Thu, 2013-07-18 at 04:31 +0800, Stephen Warren wrote:
>> On 07/17/2013 04:15 AM, Joseph Lo wrote:
>>> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
>>>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
>>>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
>>>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
>>>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
>>>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
>>>>>>> this state.
>> ... [ discussion of issues with Joesph's patches applied]
>>>
>>> OK. I did more stress tests last night and today. I found it cause by
>>> the patch "ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag" and
>>> only impact the Tegra20 platform. The hot plug regression seems due to
>>> this patch. After dropping this patch on top of v3.11-rc1, the Tegra20
>>> can back to normal.
>>>
>>> And the hop plug and suspend stress test can pass on Tegra30/114 too.
>>>
>>> Can the other two patch series for Tegra114 to support CPU idle power
>>> down mode and system suspend still moving forward, not be blocked by
>>> this patch?
>>>
>>> Looks the CPUIDLE_FLAG_TIMER_STOP flag still cause some other issue for
>>> hot plug on Tegra20, I will continue to check this. You can just drop
>>> this patch.
>>
>> OK, if I drop that patch, then everything on Tegra20 and Tegra30 seems
>> fine again.
>>
>> However, I've found some new and exciting issue on Tegra114!
>>
>> With unmodified v3.11-rc1, I can do the following without issue:
>>
>> * Unplug/replug CPUs, so that I had all combinations of CPU 1, 2, 3
>> plugged/unpplugged (with CPU 0 always plugged).
>>
>> * Unplug/replug CPUs, so that I had all combinations of CPU 0, 1, 2, 3
>> plugged/unpplugged (with the obvious exception of never having all CPUs
>> unplugged).
>>
>> However, if I try this with your Tegra114 cpuidle and suspend patches
>> applied, I see the following issues:
>>
>> 1) If I boot, unplug CPU 0, then replug CPU 0, the system immediately
>> hard-hangs.
>>
> Sorry, I didn't apply the hotplug stress test on CPU0 too much. Because
> all of our use cases and stress tests are focused on secondary CPUs
> only.
> 
> After doing some tests, here is my summary. This issue happens after we
> support CPU idle power-down mode and relates to PMC or flow controller I
> believe.
> 
> i) on top of v3.11-rc1 (only support WFI in CPU idle)
> When hot unplug CPU0, the PMC can power gate and put it into reset
> state. This is what I expect and also true on all the other secondary
> CPUs. The flow controller can maintain the CPU power state machine as
> what we want.
> 
> ii) on top of v3.11-rc1 + CPU idle power down mode support
> a) I saw most of the time the CPU0,1,2,3 were in power down and reset
> status. That means the idle power down mode works fine.
> 
> b) Testing with the CPU hotplug stress test with the secondary CPUs (not
> include CPU0), the result is good too.
> 
> c) Testing hot plug on CPU0 with CPUIDLE_FLAG_TIMER_STOP apply or not
> apply (Note 1), the result shows not good to me. The CPU0 have already
> gone into WFI and the flow controller is set as WAITFOREVENT mode. But
> the PMC always can't power gate CPU0 and sometimes can put it into
> reset, but sometimes can't. That's why you can see it hanging after
> unplug CPU0 sometimes.

Are sure coupled idle state support hotplug and especially the cpu0
hotplug ?

> When hop plug-in CPU0, because the CPU0 not be power gated by PMC or the
> flow controller event that we trigger PMC to do. I think it may need
> more time to process it. It can be solved by just add a udelay(10) after
> we set up flow controller event to wake up CPU0. Then it can put CPU0
> back to normal state.
> 
> So the result shows to me the flow controller (or the state machine)
> looks not support to power gate CPU0 when we support idle power down
> mode. The power of CPU0 also can bind to the power of the CPU cluster.
> That cause the state machine can't work correctly in this case, I guess.
> I need to check with some people. BTW, I just saw we drop the hotplug
> support for CPU0 in downstream rel-18 (although it's not related to this
> issue).
> 
> Note 1.
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c
> b/arch/arm/mach-tegra/cpuidle-tegra114.c
> index 658b205..5248a69 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra114.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
> @@ -43,8 +43,12 @@ static int tegra114_idle_power_down(struct
> cpuidle_device *dev,
>         tegra_set_cpu_in_lp2();
>         cpu_pm_enter();
>  
> +       clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> +
>         cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
>  
> +       clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +
>         cpu_pm_exit();
>         tegra_clear_cpu_in_lp2();
>  
> @@ -66,8 +70,8 @@ static struct cpuidle_driver tegra_idle_driver = {
>                         .exit_latency           = 500,
>                         .target_residency       = 1000,
>                         .power_usage            = 0,
> -                       .flags                  =
> CPUIDLE_FLAG_TIME_VALID |
> -
> CPUIDLE_FLAG_TIMER_STOP,
> +                       .flags                  =
> CPUIDLE_FLAG_TIME_VALID,
> +//
> CPUIDLE_FLAG_TIMER_STOP,
>                         .name                   = "powered-down",
>                         .desc                   = "CPU power gated",
>                 },
> 
>> 2) If I run the hotplug test script, leaving CPU 0 always present, I
>> sometimes see:
>>
>>> root at localhost:~# for i in `seq 1 50`; do echo ITERATION $i; ./cpuonline.py; done
>>> ITERATION 1
>>> echo 0 > /sys/devices/system/cpu/cpu2/online
>>> [  458.910054] CPU2: shutdown
>>> echo 0 > /sys/devices/system/cpu/cpu1/online
>>> [  461.004371] CPU1: shutdown
>>> echo 0 > /sys/devices/system/cpu/cpu3/online
>>> [  463.027341] CPU3: shutdown
>>> echo 1 > /sys/devices/system/cpu/cpu1/online
>>> [  465.061412] CPU1: Booted secondary processor
>>> echo 1 > /sys/devices/system/cpu/cpu2/online
>>> [  467.095313] CPU2: Booted secondary processor
>>> [  467.113243] ------------[ cut here ]------------
>>> [  467.117948] WARNING: CPU: 2 PID: 0 at kernel/time/tick-broadcast.c:667 tick_broadcast_oneshot_control+0x19c/0x1c4()
>>> [  467.128352] Modules linked in:
>>> [  467.131455] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.11.0-rc1-00022-g7487363-dirty #49
>>> [  467.139678] [<c0015620>] (unwind_backtrace+0x0/0xf8) from [<c001154c>] (show_stack+0x10/0x14)
>>> [  467.148228] [<c001154c>] (show_stack+0x10/0x14) from [<c05135a8>] (dump_stack+0x80/0xc4)
>>> [  467.156336] [<c05135a8>] (dump_stack+0x80/0xc4) from [<c0024590>] (warn_slowpath_common+0x64/0x88)
>>> [  467.165300] [<c0024590>] (warn_slowpath_common+0x64/0x88) from [<c00245d0>] (warn_slowpath_null+0x1c/0x24)
>>> [  467.174959] [<c00245d0>] (warn_slowpath_null+0x1c/0x24) from [<c00695e4>] (tick_broadcast_oneshot_control+0x19c/0x1c4)
>>> [  467.185659] [<c00695e4>] (tick_broadcast_oneshot_control+0x19c/0x1c4) from [<c0067cdc>] (clockevents_notify+0x1b0/0x1dc)
>>> [  467.196538] [<c0067cdc>] (clockevents_notify+0x1b0/0x1dc) from [<c034f348>] (cpuidle_idle_call+0x11c/0x168)
>>> [  467.206292] [<c034f348>] (cpuidle_idle_call+0x11c/0x168) from [<c000f134>] (arch_cpu_idle+0x8/0x38)
>>> [  467.215359] [<c000f134>] (arch_cpu_idle+0x8/0x38) from [<c0061038>] (cpu_startup_entry+0x60/0x134)
>>> [  467.224325] [<c0061038>] (cpu_startup_entry+0x60/0x134) from [<800083d8>] (0x800083d8)
>>> [  467.232227] ---[ end trace ea579be22a00e7fb ]---
>>> echo 0 > /sys/devices/system/cpu/cpu1/online
>>> [  469.126682] CPU1: shutdown
> 
> Hmm. It's hard to reproduce. But finally, I also can repro with CPU
> hotplug stress test. And some strange issues after apply
> CPUIDLE_FLAG_TIMER_STOP on Tegra20, can we postpone to apply this?
> I need more time to investigate how does this flag impact system.
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Thu Jul 18 08:54:27 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 18 Jul 2013 14:54:27 +0200
Subject: [PATCH 1/4] ARM: exynos: cpuidle: Fallback to WFI,
 when AFTR is selected
Message-ID: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>

When there are several cpus online, the AFTR state does not work.

The AFTR must be selected only when there is one cpu online.

The previous code was already handling this case.

Simplified the code, especially the init routine to have the same init
pattern than the other drivers.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-exynos/cpuidle.c |   13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index 17a18ff..cc4b097 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -147,16 +147,11 @@ static int exynos4_enter_lowpower(struct cpuidle_device *dev,
 				struct cpuidle_driver *drv,
 				int index)
 {
-	int new_index = index;
-
 	/* This mode only can be entered when other core's are offline */
 	if (num_online_cpus() > 1)
-		new_index = drv->safe_state_index;
+		return drv->states[0].enter(dev, drv, 0);
 
-	if (new_index == 0)
-		return arm_cpuidle_simple_enter(dev, drv, new_index);
-	else
-		return exynos4_enter_core0_aftr(dev, drv, new_index);
+	return exynos4_enter_core0_aftr(dev, drv, index);
 }
 
 static void __init exynos5_core_down_clk(void)
@@ -209,10 +204,6 @@ static int __init exynos4_init_cpuidle(void)
 		device = &per_cpu(exynos4_cpuidle_device, cpu_id);
 		device->cpu = cpu_id;
 
-		/* Support IDLE only */
-		if (cpu_id != 0)
-			device->state_count = 1;
-
 		ret = cpuidle_register_device(device);
 		if (ret) {
 			printk(KERN_ERR "CPUidle register device failed\n");
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Jul 18 08:54:28 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 18 Jul 2013 14:54:28 +0200
Subject: [PATCH 2/4] ARM: exynos: cpuidle: Use the common cpuidle register
 routine
In-Reply-To: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
References: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1374152070-21008-2-git-send-email-daniel.lezcano@linaro.org>

Now we have the same routine than the one handled by the cpuidle framework.

Let's use it.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-exynos/cpuidle.c |   24 +-----------------------
 1 file changed, 1 insertion(+), 23 deletions(-)

diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index cc4b097..d8fc1a2 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -41,8 +41,6 @@ static int exynos4_enter_lowpower(struct cpuidle_device *dev,
 				struct cpuidle_driver *drv,
 				int index);
 
-static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
-
 static struct cpuidle_driver exynos4_idle_driver = {
 	.name			= "exynos4_idle",
 	.owner			= THIS_MODULE,
@@ -188,29 +186,9 @@ static void __init exynos5_core_down_clk(void)
 
 static int __init exynos4_init_cpuidle(void)
 {
-	int cpu_id, ret;
-	struct cpuidle_device *device;
-
 	if (soc_is_exynos5250())
 		exynos5_core_down_clk();
 
-	ret = cpuidle_register_driver(&exynos4_idle_driver);
-	if (ret) {
-		printk(KERN_ERR "CPUidle failed to register driver\n");
-		return ret;
-	}
-
-	for_each_online_cpu(cpu_id) {
-		device = &per_cpu(exynos4_cpuidle_device, cpu_id);
-		device->cpu = cpu_id;
-
-		ret = cpuidle_register_device(device);
-		if (ret) {
-			printk(KERN_ERR "CPUidle register device failed\n");
-			return ret;
-		}
-	}
-
-	return 0;
+	return cpuidle_register(&exynos4_idle_driver, NULL);
 }
 device_initcall(exynos4_init_cpuidle);
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Jul 18 08:54:29 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 18 Jul 2013 14:54:29 +0200
Subject: [PATCH 3/4] ARM: exynos: cpuidle: Move exynos4_idle_driver
 declaration below in the code
In-Reply-To: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
References: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1374152070-21008-3-git-send-email-daniel.lezcano@linaro.org>

In order to prevent a pointless forward declaration, move the driver declation
after the idle function callback, right before the init function.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-exynos/cpuidle.c |   40 ++++++++++++++++++----------------------
 1 file changed, 18 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index d8fc1a2..8d06128 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -37,28 +37,6 @@
 
 #define S5P_CHECK_AFTR		0xFCBA0D10
 
-static int exynos4_enter_lowpower(struct cpuidle_device *dev,
-				struct cpuidle_driver *drv,
-				int index);
-
-static struct cpuidle_driver exynos4_idle_driver = {
-	.name			= "exynos4_idle",
-	.owner			= THIS_MODULE,
-	.states = {
-		[0] = ARM_CPUIDLE_WFI_STATE,
-		[1] = {
-			.enter			= exynos4_enter_lowpower,
-			.exit_latency		= 300,
-			.target_residency	= 100000,
-			.flags			= CPUIDLE_FLAG_TIME_VALID,
-			.name			= "C1",
-			.desc			= "ARM power down",
-		},
-	},
-	.state_count = 2,
-	.safe_state_index = 0,
-};
-
 /* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
 static void exynos4_set_wakeupmask(void)
 {
@@ -184,6 +162,24 @@ static void __init exynos5_core_down_clk(void)
 	__raw_writel(tmp, EXYNOS5_PWR_CTRL2);
 }
 
+static struct cpuidle_driver exynos4_idle_driver = {
+	.name			= "exynos4_idle",
+	.owner			= THIS_MODULE,
+	.states = {
+		[0] = ARM_CPUIDLE_WFI_STATE,
+		[1] = {
+			.enter			= exynos4_enter_lowpower,
+			.exit_latency		= 300,
+			.target_residency	= 100000,
+			.flags			= CPUIDLE_FLAG_TIME_VALID,
+			.name			= "C1",
+			.desc			= "ARM power down",
+		},
+	},
+	.state_count = 2,
+	.safe_state_index = 0,
+};
+
 static int __init exynos4_init_cpuidle(void)
 {
 	if (soc_is_exynos5250())
-- 
1.7.9.5



From daniel.lezcano at linaro.org  Thu Jul 18 08:54:30 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 18 Jul 2013 14:54:30 +0200
Subject: [PATCH 4/4] ARM: exynos: cpuidle: Remove useless headers
In-Reply-To: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
References: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1374152070-21008-4-git-send-email-daniel.lezcano@linaro.org>

The headers:

#include <linux/kernel.h>
#include <linux/export.h>
#include <linux/time.h>
#include <asm/unified.h>

are not needed. Removed them.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/mach-exynos/cpuidle.c |    4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index 8d06128..027f5e7 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -8,18 +8,14 @@
  * published by the Free Software Foundation.
 */
 
-#include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/cpuidle.h>
 #include <linux/cpu_pm.h>
 #include <linux/io.h>
-#include <linux/export.h>
-#include <linux/time.h>
 
 #include <asm/proc-fns.h>
 #include <asm/smp_scu.h>
 #include <asm/suspend.h>
-#include <asm/unified.h>
 #include <asm/cpuidle.h>
 #include <mach/regs-clock.h>
 #include <mach/regs-pmu.h>
-- 
1.7.9.5



From u.kleine-koenig at pengutronix.de  Thu Jul 18 08:58:06 2013
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Thu, 18 Jul 2013 14:58:06 +0200
Subject: [PATCH] gpio/mxc: add chained_irq_enter/exit() to mx2_gpio_irq_handler
Message-ID: <1374152286-12955-1-git-send-email-u.kleine-koenig@pengutronix.de>

Similar to commit

	0e44b6e (gpio/mxc: add chained_irq_enter/exit() to mx3_gpio_irq_handler())

. It doesn't seem to be critical to make the irqs work, but still it is
more correct.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
Hello,

note this is completely untested.

Uwe

 drivers/gpio/gpio-mxc.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 7176743..832881c 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -291,6 +291,9 @@ static void mx2_gpio_irq_handler(u32 irq, struct irq_desc *desc)
 {
 	u32 irq_msk, irq_stat;
 	struct mxc_gpio_port *port;
+	struct irq_chip *chip = irq_get_chip(irq);
+
+	chained_irq_enter(chip, desc);
 
 	/* walk through all interrupt status registers */
 	list_for_each_entry(port, &mxc_gpio_ports, node) {
@@ -302,6 +305,7 @@ static void mx2_gpio_irq_handler(u32 irq, struct irq_desc *desc)
 		if (irq_stat)
 			mxc_gpio_irq_handler(port, irq_stat);
 	}
+	chained_irq_exit(chip, desc);
 }
 
 /*
-- 
1.8.3.2



From dinguyen at altera.com  Thu Jul 18 09:12:53 2013
From: dinguyen at altera.com (Dinh Nguyen)
Date: Thu, 18 Jul 2013 08:12:53 -0500
Subject: [PATCH 0/4] Enable ethernet support for SOCFPGA
In-Reply-To: <20130718115951.GA2706@amd.pavel.ucw.cz>
References: <1374102623-4154-1-git-send-email-dinguyen@altera.com>
 <51E7B27F.2000304@communistcode.co.uk>
 <20130718115951.GA2706@amd.pavel.ucw.cz>
Message-ID: <1374153173.9004.4.camel@linux-builds1>

Hi Jack,

On Thu, 2013-07-18 at 13:59 +0200, ZY - pavel wrote:
> Hi!
> 
> > >These 4 patches are meant to enable ethernet and SD/MMC for the SOCFPGA
> > >platform.
> > >
> > >patch (1/4): Adds select ARM_TWD for the platform
> > >patch (2/4): Add platform specific initialization for the ethernet controller.
> > >patch (3/4): Commit 25c83b5c2 added "snps,phy-addr" for getting the PHY addr.
> > >         Set the ethernet clocks to be emac_0_clk and emac_1_clk so it be gated.
> > >patch (4/4): Update defconfig to support SD/MMC, ethernet, EXT3 and NFS.
> 
> > What tree is this based against, or what patches are a pre-requisite
> > to this series? I applied the patches to linux-arm/master but the
> > compile failed.
> > 
> > arch/arm/mach-socfpga/socfpga.c: In function 'ksz9021rlrn_phy_fixup':
> > arch/arm/mach-socfpga/socfpga.c:85:21: error:
> > 'MICREL_KSZ9021_EXTREG_CTRL' undeclared (first use in this function)
> >    phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> >                      ^
> 
> It seems it depends on:
> 
> Date: Mon, 15 Jul 2013 18:08:50 -0500
> From: dinguyen at altera.com
> To: dinh.linux at gmail.com, netdev at vger.kernel.org
> Cc: Pavel Machek <pavel at denx.de>, Nicolas Ferre
> <nicolas.ferre at atmel.com>,
>         "David S. Miller" <davem at davemloft.net>,
>         linux-arm-kernel at lists.infradead.org,
>         Shawn Guo <shawn.guo at linaro.org>,
>         Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>,
>         Andrew Victor <linux at maxim.org.za>,
>         Dinh Nguyen <dinguyen at altera.com>
> Subject: [PATCH] phy: micrel: Add definitions for common Micrel PHY
> registers
> X-Mailer: git-send-email 1.7.9.5
> 
> From: Dinh Nguyen <dinguyen at altera.com>
> 
> Add defines for common Micrel PHY setups so that other platforms
> can use them. Update imx61 and sama5 hardware to use the micrel_phy.h
> PHY defines.
> 
> Also add support for the KSZ9021RLRN PHY.
> 
> Signed-off-by: Dinh Nguyen <dinguyen at altera.com>

Yes, the above patch is necessary. I was hoping that patch can go into
either Shawn's or Nicolas' tree. I have received ACKs from both. There
is also the SD/MMC bindings patch that has not been applied to the
arm-soc tree yet. I have started collecting the patches at github in the
meantime:

git at github.com:dinh-linux/linux-socfpga.git for-next

Dinh
> 
> 									Pavel





From ml at communistcode.co.uk  Thu Jul 18 09:38:51 2013
From: ml at communistcode.co.uk (Jack Mitchell)
Date: Thu, 18 Jul 2013 14:38:51 +0100
Subject: [PATCH 0/4] Enable ethernet support for SOCFPGA
In-Reply-To: <1374153173.9004.4.camel@linux-builds1>
References: <1374102623-4154-1-git-send-email-dinguyen@altera.com>
 <51E7B27F.2000304@communistcode.co.uk>
 <20130718115951.GA2706@amd.pavel.ucw.cz>
 <1374153173.9004.4.camel@linux-builds1>
Message-ID: <51E7EFEB.6080605@communistcode.co.uk>

On 18/07/13 14:12, Dinh Nguyen wrote:
> Hi Jack,
> 
> On Thu, 2013-07-18 at 13:59 +0200, ZY - pavel wrote:
>> Hi!
>>
>>>> These 4 patches are meant to enable ethernet and SD/MMC for the SOCFPGA
>>>> platform.
>>>>
>>>> patch (1/4): Adds select ARM_TWD for the platform
>>>> patch (2/4): Add platform specific initialization for the ethernet controller.
>>>> patch (3/4): Commit 25c83b5c2 added "snps,phy-addr" for getting the PHY addr.
>>>>         Set the ethernet clocks to be emac_0_clk and emac_1_clk so it be gated.
>>>> patch (4/4): Update defconfig to support SD/MMC, ethernet, EXT3 and NFS.
>>
>>> What tree is this based against, or what patches are a pre-requisite
>>> to this series? I applied the patches to linux-arm/master but the
>>> compile failed.
>>>
>>> arch/arm/mach-socfpga/socfpga.c: In function 'ksz9021rlrn_phy_fixup':
>>> arch/arm/mach-socfpga/socfpga.c:85:21: error:
>>> 'MICREL_KSZ9021_EXTREG_CTRL' undeclared (first use in this function)
>>>    phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
>>>                      ^
>>
>> It seems it depends on:
>>
>> Date: Mon, 15 Jul 2013 18:08:50 -0500
>> From: dinguyen at altera.com
>> To: dinh.linux at gmail.com, netdev at vger.kernel.org
>> Cc: Pavel Machek <pavel at denx.de>, Nicolas Ferre
>> <nicolas.ferre at atmel.com>,
>>         "David S. Miller" <davem at davemloft.net>,
>>         linux-arm-kernel at lists.infradead.org,
>>         Shawn Guo <shawn.guo at linaro.org>,
>>         Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>,
>>         Andrew Victor <linux at maxim.org.za>,
>>         Dinh Nguyen <dinguyen at altera.com>
>> Subject: [PATCH] phy: micrel: Add definitions for common Micrel PHY
>> registers
>> X-Mailer: git-send-email 1.7.9.5
>>
>> From: Dinh Nguyen <dinguyen at altera.com>
>>
>> Add defines for common Micrel PHY setups so that other platforms
>> can use them. Update imx61 and sama5 hardware to use the micrel_phy.h
>> PHY defines.
>>
>> Also add support for the KSZ9021RLRN PHY.
>>
>> Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
> 
> Yes, the above patch is necessary. I was hoping that patch can go into
> either Shawn's or Nicolas' tree. I have received ACKs from both. There
> is also the SD/MMC bindings patch that has not been applied to the
> arm-soc tree yet. I have started collecting the patches at github in the
> meantime:
> 
> git at github.com:dinh-linux/linux-socfpga.git for-next
> 
> Dinh

Dinh,

Perfect, that boots from the mmc! For what it's worth, for the whole
series + pre-requisite patches on an Arrow SoCkit devkit:

Tested-by: Jack Mitchell <jack.mitchell at dbbroadcast.co.uk>

-- 

  Jack Mitchell (jack at embed.me.uk)
  Embedded Systems Engineer
  http://www.embed.me.uk

--


From tony at atomide.com  Thu Jul 18 09:48:07 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 06:48:07 -0700
Subject: [PATCH 4/4] drivers: Add pinctrl handling for dynamic pin states
In-Reply-To: <20130718074508.GQ7656@atomide.com>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090539.5541.980.stgit@localhost>
 <51E70ADF.8090805@wwwdotorg.org>
 <20130718074508.GQ7656@atomide.com>
Message-ID: <20130718134806.GW7656@atomide.com>

* Tony Lindgren <tony at atomide.com> [130718 00:57]:
> * Stephen Warren <swarren at wwwdotorg.org> [130717 14:28]:
> > 
> > Oh, I see you're trying to check that the set of pins in the active,
> > sleep, and idle states are identical.
> 
> Right, that's to avoid any further checking during runtime for runtime PM.
>  
> > But I think that pinctrl_check_dynamic() only checks that one state is a
> > subset of the other, not that the two states are equal. Instead, I think
> > you want to comparison coded in pinctrl_check_dynamic() to be:
> 
> In pinctrl_check_dynamic() we check that the pins match between the
> states, and the number of found pins matches the first set. I'll
> take a look if we check the total pins between the two sets.

That that is a bit painful right now to check properly as we don't
have any sorting, and we could use that elsewhere too for checks
probably..
  
> > gen_group_list_of_pinctrl_state(s1, array1);
> > gen_group_list_of_pinctrl_state(s2, array2);
> > mismatch = memcmp(array1, array2, length);
> 
> Well we could allocate and sort the pins, but the number of pins
> for runtime PM is typically very small for each pin consumer device.
> Typically you just need to toggle RX pin to GPIO mode for idle. And
> this check is only done during consumer driver probe time. So
> optimizing it for larger sets could be done at any point later on
> as needed.

..so for now, let's just check the total number of pins for the sets
like Felipe suggested. I think we're better off improving the pinctrl
data first to make various checks easier.

What you're suggesting with the mepcmp() can be done easily if we add
something like device_get_pins() and have the pins sorted for the
various states for a device at the device probe time.

Regards,

Tony


From ezequiel.garcia at free-electrons.com  Thu Jul 18 09:55:06 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Thu, 18 Jul 2013 10:55:06 -0300
Subject: [PATCH] ARM: Kirkwood: Fix the internal register ranges
 translation
In-Reply-To: <51E63B3A.2010807@keymile.com>
References: <1371569479-31498-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <51E5145A.90404@keymile.com> <20130716125531.GD2317@localhost>
 <51E63B3A.2010807@keymile.com>
Message-ID: <20130718135505.GA3264@localhost>

Hi Gerlando,

On Wed, Jul 17, 2013 at 08:35:38AM +0200, Gerlando Falauto wrote:
> On 07/16/2013 02:56 PM, Ezequiel Garcia wrote:
> [...]
> > Also, speaking of "device bus" this nand node should be behind a devicebus node.
> >
> > 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000   /* internal-regs */
> > 			  MBUS_ID(0x01, 0x2f) 0 0 0xf4000000 0x400>;
> >
> > 		devbus {
> > 			status = "okay";
> > 			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x400>;
> >
> > 			/* nand */
> > 			nand {
> > 				compatible = "marvell,orion-nand";
> > 				reg = <0 0x400>;
> > 			};
> > 		};
> >
> > (notice this will allow you to relocate the base address of the NAND windows
> > easily if it conflicts with your PCIe needs).
> 
> I am MAYBE slowly starting to understand this whole mbus rework.
> Just one remark though: don't you think it would make sense to add 
> something like:
> 
> #define MBUS_ID_INTERNAL_REGS	MBUS_ID(0xf0, 0x01)
> #define MBUS_ID_NAND		MBUS_ID(0x01, 0x2f)
> 

Yeah, maybe it would make sense. This has been discussed in the past
and others were against, so that's the reason it's not included in
the series I submitted.

But feel free to send a patch proposing it once the MBus is merged!

Thanks,
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From mark.rutland at arm.com  Thu Jul 18 09:56:50 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 18 Jul 2013 14:56:50 +0100
Subject: [PATCH v3] clk: add MOXA ART SoCs clock driver
In-Reply-To: <CACmBeS24smrJ4SLY7snv1_6SRcuXRkZ8t0PGMvBupUpKMMb43w@mail.gmail.com>
References: <1372943292-6960-1-git-send-email-jonas.jensen@gmail.com>
 <1374067396-30155-1-git-send-email-jonas.jensen@gmail.com>
 <20130718095035.GA29153@e106331-lin.cambridge.arm.com>
 <CACmBeS2SnpiUtiQD6j9qyaXZ5-chHSHVeo4c5=UhitVonvkKtw@mail.gmail.com>
 <20130718110201.GB29153@e106331-lin.cambridge.arm.com>
 <CACmBeS24smrJ4SLY7snv1_6SRcuXRkZ8t0PGMvBupUpKMMb43w@mail.gmail.com>
Message-ID: <20130718135650.GD29153@e106331-lin.cambridge.arm.com>

On Thu, Jul 18, 2013 at 12:55:26PM +0100, Jonas Jensen wrote:
> On 18 July 2013 13:02, Mark Rutland <mark.rutland at arm.com> wrote:
> > Ok. I'm just concerned that the linkage isn't explicit or obvious.
> 
> > This does leave apb-clock completely dependent on core-clock, and unless
> > I've missed something there's no linkage between the two described in
> > the dt.
> 
> I can add a description in the core-clock binding and also for
> apb-clock pointing
> out that it's set from core-clock.
> 
> > How does core-clock physically relate to apb-clock? Does it feed or is
> > it fed by apb-clock?
> 
> apb-clock is entirely a DT construct used by drivers to get the fixed
> rate 48MHz.
> It's not fed by core-clock more than what happens in probe.
> 
> For UC-7112-LX, drivers using apb-clock are: clocksource, MMC, watchdog
> 
> Because clocksource relies on apb-clock, a successful probe of
> core-clock is critical.
> 
> Commonly, drivers look up the apb-clock node and call clk_get_rate.

When you say look up the apb-clock node, I assume they find it via their
clocks property with of_clk_get or similar, rather than scanning the
tree for a "moxart,moxa-apb-clock" node specifically?

> 
> > Are we always guaranteed to have core-clock if we have apb-clock, and is
> > it part of the same block in hardware? If so we could describe the
> > amalgamation as a provider with two clock outputs, with core-clock's
> > registers for configuration at probe-time.
> 
> Yes, as described above, there can not be a apb-clock without core-clock.
> 
> 
> I think drivers could find and use core-clock instead. Maybe the abstraction
> of apb-clock is unnecessary?

Given the above, I think it would make more sense to have core-clock
registered, and have it passed to the devices currently passed
apb-clock.

Thanks,
Mark.

> 
> 
> Best regards,
> Jonas
> 


From ezequiel.garcia at free-electrons.com  Thu Jul 18 10:05:51 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Thu, 18 Jul 2013 11:05:51 -0300
Subject: [PATCH] ARM: Kirkwood: Fix the internal register ranges
 translation
In-Reply-To: <51E59639.3000207@keymile.com>
References: <1371569479-31498-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <51E5145A.90404@keymile.com> <20130716125531.GD2317@localhost>
 <51E59639.3000207@keymile.com>
Message-ID: <20130718140550.GA3364@localhost>

Gerlando,

On Tue, Jul 16, 2013 at 08:51:37PM +0200, Gerlando Falauto wrote:
[...]
> >
> > Also, speaking of "device bus" this nand node should be behind a devicebus node.
> >
> > 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000   /* internal-regs */
> > 			  MBUS_ID(0x01, 0x2f) 0 0 0xf4000000 0x400>;
> >
> > 		devbus {
> > 			status = "okay";
> > 			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x400>;
> >
> > 			/* nand */
> > 			nand {
> > 				compatible = "marvell,orion-nand";
> > 				reg = <0 0x400>;
> > 			};
> > 		};
> 
> I believe that makes a lot more sense this way... I guess this feature 
> (device bus) requires your latest set of patches, right? (either v7 as 
> you posted yesterday or your tree at 
> git://github.com/MISL-EBU-System-SW/mainline-public.git/marvell-mvebu-mbus-v7)
> 

No, not really. The device-bus driver is already merged, so we only need
to use it, and maybe extend it a bit to support kirkwood (in case it's
needed). You can see in:

  arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts

for an example.

I would prefer that to be done *after* the MBus is accepted...
but that's just a personal preference.

> > (notice this will allow you to relocate the base address of the NAND windows
> > easily if it conflicts with your PCIe needs).
> 
> I sort of had the impression I could do already do that somehow, though 
> I am not quite sure anymore...
> 

Well, you can do it by patching and re-building the kernel as the
MBus windows are created from C-files.

With the MBus DT binding, all you need is to change the DT.

> >> avoid a later incosistency between the "unit-address" and the first
> >> "reg" address:
> >>
> >>>    		#address-cells = <1>;
> >>>    		#size-cells = <1>;
> >>> @@ -171,7 +172,7 @@
> >>   >   		nand at 3000000 {
> >> 		     ^^^^^^^
> >
> > Oh, this should be fixed. I just missed it, and nobody noticed either.
> >
> 
> So, in the end, you think it's OK to have a set of nodes with "relative" 
> addresses (gpio at 10140, serial at 12000 etc...) and some with "absolute" 
> addresses (nand at 0xf4000000, where the ranges property does a 0-offset 
> translation)?
> Even though I understand this is just some transitional state, and it 
> will all be fixed like your example above, once we get the rest of the 
> rework merged (mbus/devbus).

Mmm.. I see your point. In the end, it's just as you say, the current state
is only transitional. There's no way to have a proper DT without the MBus DT
binding.

The reason for this mess is that the current layout mixes the actual
address space. Feel free to take a look at the latest MBus series and
try to add MBus DT binding for Kirkwood.

If you do, don't hesitate in asking as many questions as you need and/or
posting RFCs for us to look at.

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From nsekhar at ti.com  Thu Jul 18 10:08:26 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Thu, 18 Jul 2013 19:38:26 +0530
Subject: [PATCH RFC v2 13/14] ARM: debug: move davinci debug to generic
 8250 code
In-Reply-To: <20130717170233.GQ24642@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
 <E1Uz8OD-00048N-Be@rmk-PC.arm.linux.org.uk> <51E6887F.3090808@ti.com>
 <20130717170233.GQ24642@n2100.arm.linux.org.uk>
Message-ID: <51E7F6DA.7000505@ti.com>

On Wednesday 17 July 2013 10:32 PM, Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 05:35:19PM +0530, Sekhar Nori wrote:
>> On 7/16/2013 10:16 PM, Russell King wrote:
>>> Davinci's debugging is just a copy of the old 8250_32 code with a
>>> different base address.  Incorporate this into the generic 8250
>>> debug code.
>>>
>>> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
>>
>> Tested on DA850 EVM
>>
>> Acked-by: Sekhar Nori <nsekhar at ti.com>
> 
> You may wish to consider whether a Tested-by tag would be a more accurate
> attributation if you actually tested the patch.

Okay, I chose Acked-by: because I also reviewed the patch to make sure
there are not typos in the addresses etc for the devices I did not test.

Thanks,
Sekhar


From stern at rowland.harvard.edu  Thu Jul 18 10:08:53 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Thu, 18 Jul 2013 10:08:53 -0400 (EDT)
Subject: [PATCH] [RFC] EHCI: add to memory barrier to updating hw_next
In-Reply-To: <CACVXFVNV-hGZpcy2ANQaca1K5yXJ88EOq1PTkJUEHEkFk9Btvw@mail.gmail.com>
Message-ID: <Pine.LNX.4.44L0.1307181004190.1245-100000@iolanthe.rowland.org>

On Thu, 18 Jul 2013, Ming Lei wrote:

> > I guess that HC could have a use-after-free problem like following situation.
> >
> > 1. A qtd which is not at the queue head should be removed in qh_completions().
> > 2. The last->hw_next become be pointing at the next qtd but the hw_next value is delayed in write-buffer.
> > 3. The qtd is removed in the list.
> > 4. The qtd is freed into DMA pool and re-allocated for another urb.
> > 5. HC try to process last->hw_next and it is pointing re-allocated qtd.
> >
> > What do you think about it? Is it possible?
> 
> I understand it might not be possible because:  when 'stopped' is set, that
> said the HC might not advance the queue. But I don't understand why
> 'last->hw_next' is patched here under 'stopped' situation.

It should not be possible.  When "stopped" is set, the QH gets unlinked 
and relinked before it can start up again.  Relinking involves some 
memory barriers, so the qTD will not be accessed again by the HC.

last->hw_next gets patched because the qTD might belong to some URB in 
the middle of the queue that is being unlinked.  The URBs before it and 
after it will still be active, so the queue link has to be updated.

> Even the 'stopped' case may be seldom triggered, do you know under
> which condition the stopped is triggered in your problem?(stall, short read
> or others)

I was going to ask the same question.  This particular piece of code
gets executed _only_ when an URB is unlinked.  Not during any other
kind of error.

Alan Stern



From Dave.Martin at arm.com  Thu Jul 18 10:19:12 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Thu, 18 Jul 2013 15:19:12 +0100
Subject: Can't get FIQ interrupt to work on i.mx233
In-Reply-To: <51E69F42.2060106@gmail.com>
References: <CAF-Ht3z3GQLwEWoB+UgOGepHfMFUD7pTRHfYWR9Ynk3rM4dD=Q@mail.gmail.com>
 <20130716081132.GB24642@n2100.arm.linux.org.uk>
 <51E5322B.8080602@gmail.com>
 <20130716161643.GB3428@localhost.localdomain>
 <51E69F42.2060106@gmail.com>
Message-ID: <20130718141905.GA2655@localhost.localdomain>

On Wed, Jul 17, 2013 at 10:42:26PM +0900, Juha Lumme wrote:
> Hi Dave,
> 
> Thanks for the idea, that's indeed a dead simple way to find out.
> Being sure that I will get stuck in FIQ handler, I started
> experimenting different things, and it seems that if instead of
> calling mxs_icoll_set_irq_fiq(31) (which only sets FIQ bit), I
> directly set bits 4 (FIQ) and 2 (ENABLE) in HW_ICOLL_INTERRUPT31
> register, my interrupt starts working as expected. Maybe I can also
> leave enable_fiq out this way.
> 
> So it currently seems like mxs_icoll_set_irq_fiq (which I patched
> in) and enable_fiq (already there) are not working as expected
> currently in freescale's mainline 3.10.
> I will try to find out the reason, and create patches for this - but
> if you have any pointers on what might help me on a right path, I
> would appreciate it.

It sounds like you're on the right track -- I can't comment on the
details though, since I'm not familiar with this board.

Cheers
---Dave


From linux at arm.linux.org.uk  Thu Jul 18 10:20:09 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Jul 2013 15:20:09 +0100
Subject: Audio issue on Kirkwood t5325: no sound
In-Reply-To: <20130718134330.5aea00c5@skate>
References: <20130718134330.5aea00c5@skate>
Message-ID: <20130718142009.GX24642@n2100.arm.linux.org.uk>

On Thu, Jul 18, 2013 at 01:43:30PM +0200, Thomas Petazzoni wrote:
> As part of some work around audio support on Marvell platforms, I've
> taken the Kirkwood-based HP t5325 thin client device that Martin
> Michlmayr kindly gave me and tried to use the audio part of it, with
> kernel 3.11-rc1. (My plan is to write the Device Tree binding for this
> audio driver, and then use it for Armada 370 based platforms).

A couple of basic things to check:

1. /proc/asound/card0/pcm0p/sub0/status

Does this indicate that the hw_ptr and appl_ptr are updating ?

2. /proc/interrupts

Are you getting interrupts for kirkwood-i2s ?

That will confirm whether the I2S unit is reading data from the ring
buffer.  I suspect these will be a positive yes, given that aplay
appears to work normally except being muted.

Another thing to check is the DAPM status, which you can find buried
in /sys/kernel/debug/asoc - check all the DAPM status you can find
below there, and check whether you think it's reasonable.


From jonas.jensen at gmail.com  Thu Jul 18 10:25:27 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Thu, 18 Jul 2013 16:25:27 +0200
Subject: [PATCH v3] clk: add MOXA ART SoCs clock driver
In-Reply-To: <20130718135650.GD29153@e106331-lin.cambridge.arm.com>
References: <1372943292-6960-1-git-send-email-jonas.jensen@gmail.com>
 <1374067396-30155-1-git-send-email-jonas.jensen@gmail.com>
 <20130718095035.GA29153@e106331-lin.cambridge.arm.com>
 <CACmBeS2SnpiUtiQD6j9qyaXZ5-chHSHVeo4c5=UhitVonvkKtw@mail.gmail.com>
 <20130718110201.GB29153@e106331-lin.cambridge.arm.com>
 <CACmBeS24smrJ4SLY7snv1_6SRcuXRkZ8t0PGMvBupUpKMMb43w@mail.gmail.com>
 <20130718135650.GD29153@e106331-lin.cambridge.arm.com>
Message-ID: <CACmBeS2rBTtyfzUgB41zXkDC5-DRcvArgeyjbqHQHXO5+QLvmA@mail.gmail.com>

On 18 July 2013 15:56, Mark Rutland <mark.rutland at arm.com> wrote:
> When you say look up the apb-clock node, I assume they find it via their
> clocks property with of_clk_get or similar, rather than scanning the
> tree for a "moxart,moxa-apb-clock" node specifically?

Yes, all use of_clk_get(node, 0), which is fortunate because e.g.
clocksource is already merged with linaro's clockevent drivers tree.

That should mean I can get away with only changing the DT files :)

> Given the above, I think it would make more sense to have core-clock
> registered, and have it passed to the devices currently passed
> apb-clock.

OK, I'll return with an updated version.


Best regards,
Jonas


From Dave.Martin at arm.com  Thu Jul 18 11:04:08 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Thu, 18 Jul 2013 16:04:08 +0100
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <1374118116-16836-2-git-send-email-nicolas.pitre@linaro.org>
References: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
 <1374118116-16836-2-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130718150408.GB2655@localhost.localdomain>

On Wed, Jul 17, 2013 at 11:28:33PM -0400, Nicolas Pitre wrote:
> Unlike real A15/A7's, the RTSM simulation doesn't appear to hit the
> cache when the CTRL.C bit is cleared.  Let's ensure there is no memory
> access within the disable and flush cache sequence, including to the
> stack.
> 
> Signed-off-by: Nicolas Pitre <nico at linaro.org>
> ---
>  arch/arm/mach-vexpress/dcscb.c | 58 +++++++++++++++++++++++++++---------------
>  1 file changed, 37 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/arm/mach-vexpress/dcscb.c b/arch/arm/mach-vexpress/dcscb.c
> index 16d57a8a9d..9f01c04d58 100644
> --- a/arch/arm/mach-vexpress/dcscb.c
> +++ b/arch/arm/mach-vexpress/dcscb.c
> @@ -136,14 +136,29 @@ static void dcscb_power_down(void)
>  		/*
>  		 * Flush all cache levels for this cluster.
>  		 *
> -		 * A15/A7 can hit in the cache with SCTLR.C=0, so we don't need
> -		 * a preliminary flush here for those CPUs.  At least, that's
> -		 * the theory -- without the extra flush, Linux explodes on
> -		 * RTSM (to be investigated).
> +		 * To do so we do:
> +		 * - Clear the CTLR.C bit to prevent further cache allocations

SCTLR

> +		 * - Flush the whole cache
> +		 * - Disable local coherency by clearing the ACTLR "SMP" bit
> +		 *
> +		 * Let's do it in the safest possible way i.e. with
> +		 * no memory access within the following sequence
> +		 * including the stack.
>  		 */
> -		flush_cache_all();
> -		set_cr(get_cr() & ~CR_C);
> -		flush_cache_all();
> +		asm volatile(
> +		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
> +		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
> +		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
> +		"isb	\n\t"
> +		"bl	v7_flush_dcache_all \n\t"
> +		"clrex	\n\t"
> +		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
> +		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
> +		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
> +		"isb	\n\t"
> +		"dsb	"
> +		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
> +		      "r9","r10","r11","lr","memory");

Along with the TC2 support, we now have 4 copies of this code sequence.

This is basically the A15/A7 native "exit coherency and flash and
disable some levels of dcache" operation, whose only parameter is which
cache levels to flush.

That's a big mouthful -- we can probably come up with a better name --
but we've pretty much concluded that there is no way to break this
operation apart into bitesize pieces.  Nonetheless, any native
powerdown sequence for these processors will need to do this, or
something closely related.

Is it worth consolidating, or is that premature?

> +		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
> +		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
> +		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
> +		"isb	\n\t"
> +		"bl	v7_flush_dcache_all \n\t"
> +		"clrex	\n\t"
> +		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
> +		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
> +		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
> +		"isb	\n\t"
> +		"dsb	"
> +		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
> +		      "r9","r10","r11","lr","memory");


>  
>  		/*
>  		 * This is a harmless no-op.  On platforms with a real
> @@ -152,9 +167,6 @@ static void dcscb_power_down(void)
>  		 */
>  		outer_flush_all();

Do you have any opinion on whether we should leave that for educational
purposes?

None of the relevant platforms has a non-architected outer cache, so
there could be an argument for removing it.  But that might mislead
people who use this code as a reference.

Cheers
---Dave

>  
> -		/* Disable local coherency by clearing the ACTLR "SMP" bit: */
> -		set_auxcr(get_auxcr() & ~(1 << 6));
> -
>  		/*
>  		 * Disable cluster-level coherency by masking
>  		 * incoming snoops and DVM messages:
> @@ -167,18 +179,22 @@ static void dcscb_power_down(void)
>  
>  		/*
>  		 * Flush the local CPU cache.
> -		 *
> -		 * A15/A7 can hit in the cache with SCTLR.C=0, so we don't need
> -		 * a preliminary flush here for those CPUs.  At least, that's
> -		 * the theory -- without the extra flush, Linux explodes on
> -		 * RTSM (to be investigated).
> +		 * Let's do it in the safest possible way as above.
>  		 */
> -		flush_cache_louis();
> -		set_cr(get_cr() & ~CR_C);
> -		flush_cache_louis();
> -
> -		/* Disable local coherency by clearing the ACTLR "SMP" bit: */
> -		set_auxcr(get_auxcr() & ~(1 << 6));
> +		asm volatile(
> +		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
> +		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
> +		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
> +		"isb	\n\t"
> +		"bl	v7_flush_dcache_louis \n\t"
> +		"clrex	\n\t"
> +		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
> +		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
> +		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
> +		"isb	\n\t"
> +		"dsb	"
> +		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
> +		      "r9","r10","r11","lr","memory");
>  	}
>  
>  	__mcpm_cpu_down(cpu, cluster);
> -- 
> 1.8.1.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From cb at sgoc.de  Thu Jul 18 11:14:37 2013
From: cb at sgoc.de (Christoph G. Baumann)
Date: Thu, 18 Jul 2013 17:14:37 +0200 (CEST)
Subject: [PATCH v2 3/3] mxs: added driver for OCOTP in i.MX23 and i.MX28
In-Reply-To: <20130718063655.GH10380@pengutronix.de>
References: <1372855154-8422-1-git-send-email-cb@sgoc.de>
 <1374078460-4126-1-git-send-email-cb@sgoc.de>
 <1374078460-4126-4-git-send-email-cb@sgoc.de>
 <20130717192627.GA12533@pengutronix.de>
 <1068003072.1131668.1374097392210.open-xchange@email.1und1.de>
 <20130718063655.GH10380@pengutronix.de>
Message-ID: <1421016029.122488.1374160477415.open-xchange@email.1und1.de>

Hello Sascha,

unfortunately I don't have the time at the moment to further fix the FSL code.
Maybe someone else feels inclined?


Regards
Christoph


From tony at atomide.com  Thu Jul 18 11:15:01 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 08:15:01 -0700
Subject: [PATCHv2 0/4] improved support for runtime muxing for pinctrl
Message-ID: <20130718151213.30990.45828.stgit@localhost>

Hi all,

Here's this series again with hopefully all the comments addressed.

As discussed earlier, the pinctrl support for changing some of the
consumer device pins during runtime needs some improvment.
                                                                                                                
Regards,

Tony

---

Tony Lindgren (4):
      pinctrl: Remove duplicate code in pinctrl_pm_select_state functions
      pinctrl: Allow pinctrl to have multiple active states
      pinctrl: Add support for additional dynamic states
      drivers: Add pinctrl handling for dynamic pin states


 Documentation/pinctrl.txt             |   77 ++++++++-
 drivers/base/pinctrl.c                |   39 ++++
 drivers/pinctrl/core.c                |  291 +++++++++++++++++++++++++++------
 drivers/pinctrl/core.h                |   10 +
 include/linux/pinctrl/consumer.h      |   46 +++++
 include/linux/pinctrl/devinfo.h       |    4 
 include/linux/pinctrl/pinctrl-state.h |   15 +-
 7 files changed, 420 insertions(+), 62 deletions(-)

-- 
Signature


From tony at atomide.com  Thu Jul 18 11:15:04 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 08:15:04 -0700
Subject: [PATCH 1/4] pinctrl: Remove duplicate code in
 pinctrl_pm_select_state functions
In-Reply-To: <20130718151213.30990.45828.stgit@localhost>
References: <20130718151213.30990.45828.stgit@localhost>
Message-ID: <20130718151504.30990.96819.stgit@localhost>

There's no need to duplicate essentially the same functions. Let's
introduce static int pinctrl_pm_select_state() and make the other
related functions call that.

This allows us to add support later on for multiple active states,
and more optimized dynamic remuxing.

Note that we still need to export the various pinctrl_pm_select
functions as we want to keep struct pinctrl_state private to the
pinctrl code, and cannot replace those with inline functions.

Cc: Felipe Balbi <balbi at ti.com>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 drivers/pinctrl/core.c |   55 ++++++++++++++++++++++++------------------------
 1 file changed, 27 insertions(+), 28 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 5b272bf..a97b717 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1227,23 +1227,36 @@ EXPORT_SYMBOL_GPL(pinctrl_force_default);
 #ifdef CONFIG_PM
 
 /**
- * pinctrl_pm_select_default_state() - select default pinctrl state for PM
+ * pinctrl_pm_select_state() - select pinctrl state for PM
  * @dev: device to select default state for
+ * @state: state to set
  */
-int pinctrl_pm_select_default_state(struct device *dev)
+static int pinctrl_pm_select_state(struct device *dev,
+				   struct pinctrl_state *state)
 {
 	struct dev_pin_info *pins = dev->pins;
 	int ret;
 
-	if (!pins)
-		return 0;
-	if (IS_ERR(pins->default_state))
-		return 0; /* No default state */
-	ret = pinctrl_select_state(pins->p, pins->default_state);
+	if (IS_ERR(state))
+		return 0; /* No such state */
+	ret = pinctrl_select_state(pins->p, state);
 	if (ret)
-		dev_err(dev, "failed to activate default pinctrl state\n");
+		dev_err(dev, "failed to activate pinctrl state %s\n",
+			state->name);
 	return ret;
 }
+
+/**
+ * pinctrl_pm_select_default_state() - select default pinctrl state for PM
+ * @dev: device to select default state for
+ */
+int pinctrl_pm_select_default_state(struct device *dev)
+{
+	if (!dev->pins)
+		return 0;
+
+	return pinctrl_pm_select_state(dev, dev->pins->default_state);
+}
 EXPORT_SYMBOL_GPL(pinctrl_pm_select_default_state);
 
 /**
@@ -1252,17 +1265,10 @@ EXPORT_SYMBOL_GPL(pinctrl_pm_select_default_state);
  */
 int pinctrl_pm_select_sleep_state(struct device *dev)
 {
-	struct dev_pin_info *pins = dev->pins;
-	int ret;
-
-	if (!pins)
+	if (!dev->pins)
 		return 0;
-	if (IS_ERR(pins->sleep_state))
-		return 0; /* No sleep state */
-	ret = pinctrl_select_state(pins->p, pins->sleep_state);
-	if (ret)
-		dev_err(dev, "failed to activate pinctrl sleep state\n");
-	return ret;
+
+	return pinctrl_pm_select_state(dev, dev->pins->sleep_state);
 }
 EXPORT_SYMBOL_GPL(pinctrl_pm_select_sleep_state);
 
@@ -1272,17 +1278,10 @@ EXPORT_SYMBOL_GPL(pinctrl_pm_select_sleep_state);
  */
 int pinctrl_pm_select_idle_state(struct device *dev)
 {
-	struct dev_pin_info *pins = dev->pins;
-	int ret;
-
-	if (!pins)
+	if (!dev->pins)
 		return 0;
-	if (IS_ERR(pins->idle_state))
-		return 0; /* No idle state */
-	ret = pinctrl_select_state(pins->p, pins->idle_state);
-	if (ret)
-		dev_err(dev, "failed to activate pinctrl idle state\n");
-	return ret;
+
+	return pinctrl_pm_select_state(dev, dev->pins->idle_state);
 }
 EXPORT_SYMBOL_GPL(pinctrl_pm_select_idle_state);
 #endif



From tony at atomide.com  Thu Jul 18 11:15:07 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 08:15:07 -0700
Subject: [PATCH 2/4] pinctrl: Allow pinctrl to have multiple active states
In-Reply-To: <20130718151213.30990.45828.stgit@localhost>
References: <20130718151213.30990.45828.stgit@localhost>
Message-ID: <20130718151507.30990.67174.stgit@localhost>

It's quite common that we need to dynamically change some pins for a
device for runtime PM, or toggle a pin between rx and tx. Changing all
the pins for a device is not efficient way of doing it.

So let's allow setting up multiple active states for pinctrl. Currently
we only need PINCTRL_STATIC and PINCTRL_DYNAMIC, where PINCTRL_STATIC
covers the current default pins, and PINCTRL_DYNAMIC holds the dynamic
pins that need to be toggled.

Cc: Felipe Balbi <balbi at ti.com>
Cc: Grygorii Strashko <grygorii.strashko at ti.com>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 drivers/pinctrl/core.c |   18 ++++++++++--------
 drivers/pinctrl/core.h |   10 ++++++++--
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index a97b717..c9b709b 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -885,7 +885,8 @@ static void pinctrl_free(struct pinctrl *p, bool inlist)
 	mutex_lock(&pinctrl_list_mutex);
 	list_for_each_entry_safe(state, n1, &p->states, node) {
 		list_for_each_entry_safe(setting, n2, &state->settings, node) {
-			pinctrl_free_setting(state == p->state, setting);
+			pinctrl_free_setting(state == p->state[PINCTRL_STATIC],
+					     setting);
 			list_del(&setting->node);
 			kfree(setting);
 		}
@@ -955,13 +956,13 @@ EXPORT_SYMBOL_GPL(pinctrl_lookup_state);
 int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
 {
 	struct pinctrl_setting *setting, *setting2;
-	struct pinctrl_state *old_state = p->state;
+	struct pinctrl_state *old_state = p->state[PINCTRL_STATIC];
 	int ret;
 
-	if (p->state == state)
+	if (old_state == state)
 		return 0;
 
-	if (p->state) {
+	if (old_state) {
 		/*
 		 * The set of groups with a mux configuration in the old state
 		 * may not be identical to the set of groups with a mux setting
@@ -971,7 +972,7 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
 		 * but not in the new state, this code puts that group into a
 		 * safe/disabled state.
 		 */
-		list_for_each_entry(setting, &p->state->settings, node) {
+		list_for_each_entry(setting, &old_state->settings, node) {
 			bool found = false;
 			if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
 				continue;
@@ -989,7 +990,7 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
 		}
 	}
 
-	p->state = NULL;
+	p->state[PINCTRL_STATIC] = NULL;
 
 	/* Apply all the settings for the new state */
 	list_for_each_entry(setting, &state->settings, node) {
@@ -1011,7 +1012,7 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
 		}
 	}
 
-	p->state = state;
+	p->state[PINCTRL_STATIC] = state;
 
 	return 0;
 
@@ -1492,7 +1493,8 @@ static int pinctrl_show(struct seq_file *s, void *what)
 	list_for_each_entry(p, &pinctrl_list, node) {
 		seq_printf(s, "device: %s current state: %s\n",
 			   dev_name(p->dev),
-			   p->state ? p->state->name : "none");
+			   p->state[PINCTRL_STATIC] ?
+			   p->state[PINCTRL_STATIC]->name : "none");
 
 		list_for_each_entry(state, &p->states, node) {
 			seq_printf(s, "  state: %s\n", state->name);
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
index 75476b3..ac5a269 100644
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -53,12 +53,18 @@ struct pinctrl_dev {
 #endif
 };
 
+enum pinctrl_states {
+	PINCTRL_STATIC,
+	PINCTRL_DYNAMIC,
+	PINCTRL_NR_STATES,
+};
+
 /**
  * struct pinctrl - per-device pin control state holder
  * @node: global list node
  * @dev: the device using this pin control handle
  * @states: a list of states for this device
- * @state: the current state
+ * @state: the current state(s)
  * @dt_maps: the mapping table chunks dynamically parsed from device tree for
  *	this device, if any
  * @users: reference count
@@ -67,7 +73,7 @@ struct pinctrl {
 	struct list_head node;
 	struct device *dev;
 	struct list_head states;
-	struct pinctrl_state *state;
+	struct pinctrl_state *state[PINCTRL_NR_STATES];
 	struct list_head dt_maps;
 	struct kref users;
 };



From tony at atomide.com  Thu Jul 18 11:15:14 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 08:15:14 -0700
Subject: [PATCH 4/4] drivers: Add pinctrl handling for dynamic pin states
In-Reply-To: <20130718151213.30990.45828.stgit@localhost>
References: <20130718151213.30990.45828.stgit@localhost>
Message-ID: <20130718151514.30990.99907.stgit@localhost>

We want to have static pin states handled separately from
dynamic pin states, so let's add optional state_active.

Then if state_active is defined, let's check and make sure
state_idle and state_sleep match state_active for the
pin groups to avoid checking them during runtime as the
active and idle pins may need to be toggled for many
devices every time we enter and exit idle.

See also Documentation/pinctrl.txt regarding runtime
muxing of pins.

Cc: Felipe Balbi <balbi at ti.com>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Grygorii Strashko <grygorii.strashko at ti.com>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 drivers/base/pinctrl.c |   39 +++++++++++++++++++++++++++++++++++++--
 1 file changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
index 5fb74b4..49644ed 100644
--- a/drivers/base/pinctrl.c
+++ b/drivers/base/pinctrl.c
@@ -34,6 +34,7 @@ int pinctrl_bind_pins(struct device *dev)
 		goto cleanup_alloc;
 	}
 
+	/* Default static pins that don't need to change */
 	dev->pins->default_state = pinctrl_lookup_state(dev->pins->p,
 					PINCTRL_STATE_DEFAULT);
 	if (IS_ERR(dev->pins->default_state)) {
@@ -48,23 +49,57 @@ int pinctrl_bind_pins(struct device *dev)
 		goto cleanup_get;
 	}
 
+	/* Optional runtime dynamic pins in addition to the static pins */
+	dev->pins->active_state = pinctrl_lookup_state(dev->pins->p,
+					PINCTRL_STATE_ACTIVE);
+	if (IS_ERR(dev->pins->active_state)) {
+		/* Not supplying this state is perfectly legal */
+		dev_dbg(dev, "no active pinctrl state\n");
+	} else {
+		ret = pinctrl_select_dynamic(dev->pins->p,
+				dev->pins->active_state);
+		if (ret) {
+			dev_dbg(dev, "failed to select active pinctrl state\n");
+			goto cleanup_get;
+		}
+	}
+
 #ifdef CONFIG_PM
 	/*
 	 * If power management is enabled, we also look for the optional
 	 * sleep and idle pin states, with semantics as defined in
 	 * <linux/pinctrl/pinctrl-state.h>
+	 *
+	 * Note that if active state is defined, sleep and idle states must
+	 * cover the same pin groups as active state.
 	 */
 	dev->pins->sleep_state = pinctrl_lookup_state(dev->pins->p,
 					PINCTRL_STATE_SLEEP);
-	if (IS_ERR(dev->pins->sleep_state))
+	if (IS_ERR(dev->pins->sleep_state)) {
 		/* Not supplying this state is perfectly legal */
 		dev_dbg(dev, "no sleep pinctrl state\n");
+	} else if (!IS_ERR(dev->pins->active_state)) {
+		ret = pinctrl_check_dynamic(dev, dev->pins->active_state,
+					    dev->pins->sleep_state);
+		if (ret) {
+			dev_err(dev, "sleep state groups do not match active state\n");
+			dev->pins->sleep_state = ERR_PTR(-EINVAL);
+		}
+	}
 
 	dev->pins->idle_state = pinctrl_lookup_state(dev->pins->p,
 					PINCTRL_STATE_IDLE);
-	if (IS_ERR(dev->pins->idle_state))
+	if (IS_ERR(dev->pins->idle_state)) {
 		/* Not supplying this state is perfectly legal */
 		dev_dbg(dev, "no idle pinctrl state\n");
+	} else if (!IS_ERR(dev->pins->active_state)) {
+		ret = pinctrl_check_dynamic(dev, dev->pins->active_state,
+					    dev->pins->idle_state);
+		if (ret) {
+			dev_err(dev, "idle state groups do not match active state\n");
+			dev->pins->idle_state = ERR_PTR(-EINVAL);
+		}
+	}
 #endif
 
 	return 0;



From tony at atomide.com  Thu Jul 18 11:15:11 2013
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 18 Jul 2013 08:15:11 -0700
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130718151213.30990.45828.stgit@localhost>
References: <20130718151213.30990.45828.stgit@localhost>
Message-ID: <20130718151511.30990.8738.stgit@localhost>

To toggle dynamic states, let's add the optional active state in
addition to the static default state. Then if the optional active
state is defined, we can require that idle and sleep states cover
the same pingroups as the active state.

Then let's add pinctrl_check_dynamic() and pinctrl_select_dynamic()
to use instead of pinctrl_select() to avoid breaking existing users.

With pinctrl_check_dynamic() we can check that idle and sleep states
match the active state for pingroups during init, and don't need to
do it during runtime.

Then with the states pre-validated, pinctrl_select_dynamic() can
just toggle between the dynamic states without extra checks.

Note that pinctr_select_state() still has valid use cases, such as
changing states when the pins can be shared between two drivers
and don't necessarily cover the same pingroups. For dynamic runtime
toggling of pin states, we should eventually always use just
pinctrl_select_dynamic().

Cc: Felipe Balbi <balbi at ti.com>
Cc: Grygorii Strashko <grygorii.strashko at ti.com>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 Documentation/pinctrl.txt             |   77 ++++++++++-
 drivers/pinctrl/core.c                |  226 ++++++++++++++++++++++++++++++---
 include/linux/pinctrl/consumer.h      |   46 +++++++
 include/linux/pinctrl/devinfo.h       |    4 +
 include/linux/pinctrl/pinctrl-state.h |   15 ++
 5 files changed, 342 insertions(+), 26 deletions(-)

diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index 052e13a..0477ec5 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -1283,12 +1283,77 @@ This gives the exact same result as the above construction.
 Runtime pinmuxing
 =================
 
-It is possible to mux a certain function in and out at runtime, say to move
-an SPI port from one set of pins to another set of pins. Say for example for
-spi0 in the example above, we expose two different groups of pins for the same
-function, but with different named in the mapping as described under
-"Advanced mapping" above. So that for an SPI device, we have two states named
-"pos-A" and "pos-B".
+Typically runtime pinmuxing is done for runtime PM to mux a device RX pin
+to GPIO for wake-up events. And In some cases a shared RX/TX pin may need to
+be toggled. Sometimes pins can be also shared between two device drivers.
+
+In most cases runtime pinmuxing only is needed for some pins on a device, and
+most pins can be static. To avoid continuously having to check for all the
+pins of a device, pinctrl framework supports grouping device pin states to
+static and dynamic states.
+
+Most devices only need to use the static default state. If a devices has a
+need for runtime pinmuxing, the device must define the static default state,
+and then the optional dynamic states using the following rules:
+
+1. The default dynamic states are in addition to the static default state.
+
+2. The default dynamic states are active, sleep and idle, or active and idle.
+
+3. At least active and idle, or active and sleep states must be defined.
+
+4. Out of the dynamic pin states, only one of the active, sleep or idle states
+   can be active at a time.
+
+5. The dynamic pin states must all toggle the same pins to avoid unnecessary
+   checks during runtime.
+
+6. The pinctrl consumer driver must use pinctrl_select_dynamic() instead of
+   pinctrl_select_state() to toggle between the dynamic states.
+
+For example, to mux a serial driver RX pin to GPIO for runtime PM wake-up
+events, something like the following can be done. Most of the work is done
+by the pinctrl framework as long as the default, active and idle states are
+properly defined.
+
+#include <linux/pinctrl/consumer.h>
+
+serial_foo_probe()
+{
+	...
+	if (!pinctrl_pm_is_idle_state_error())
+		/* Set driver specific flags for runtime PM */
+	...
+}
+
+static int serial_foo_runtime_suspend(struct device *dev)
+{
+	...
+	res = pinctrl_pm_select_idle_state(dev);
+	if (ret < 0)
+		return ret;
+	...
+}
+
+static int serial_foo_runtime_resume(struct device *dev)
+{
+	...
+	res = pinctrl_pm_select_active_state(dev);
+	if (ret < 0)
+		return ret;
+	...
+}
+
+Currently only runtime muxing for runtime PM has been optimized as that can
+happen at high rate every time when idling and unidling devices. For less
+latency critical runtime remuxing it is possible to use pinctrl_select_state()
+as described below.
+
+For example, it is possible to move an SPI port from one set of pins to another
+set of pins. Say for example for spi0 in the example above, we expose two
+different groups of pins for the same function, but with different named in
+the mapping as described under "Advanced mapping" above. So that for an SPI
+device, we have two states named "pos-A" and "pos-B".
 
 This snippet first muxes the function in the pins defined by group A, enables
 it, disables and releases it, and muxes it in on the pins defined by group B:
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index c9b709b..af399cc 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -885,8 +885,13 @@ static void pinctrl_free(struct pinctrl *p, bool inlist)
 	mutex_lock(&pinctrl_list_mutex);
 	list_for_each_entry_safe(state, n1, &p->states, node) {
 		list_for_each_entry_safe(setting, n2, &state->settings, node) {
-			pinctrl_free_setting(state == p->state[PINCTRL_STATIC],
-					     setting);
+			bool disable_setting = false;
+
+			if ((state == p->state[PINCTRL_STATIC]) ||
+			    (state == p->state[PINCTRL_DYNAMIC]))
+				disable_setting = true;
+
+			pinctrl_free_setting(disable_setting, setting);
 			list_del(&setting->node);
 			kfree(setting);
 		}
@@ -949,6 +954,25 @@ struct pinctrl_state *pinctrl_lookup_state(struct pinctrl *p,
 EXPORT_SYMBOL_GPL(pinctrl_lookup_state);
 
 /**
+ * pinctrl_apply_setting() - apply a setting
+ * @setting: pinctrl setting to apply
+ */
+static int pinctrl_apply_setting(struct pinctrl_setting *setting)
+{
+	switch (setting->type) {
+	case PIN_MAP_TYPE_MUX_GROUP:
+		return pinmux_enable_setting(setting);
+	case PIN_MAP_TYPE_CONFIGS_PIN:
+	case PIN_MAP_TYPE_CONFIGS_GROUP:
+		return pinconf_apply_setting(setting);
+	default:
+		break;
+	}
+
+	return -EINVAL;
+}
+
+/**
  * pinctrl_select_state() - select/activate/program a pinctrl state to HW
  * @p: the pinctrl handle for the device that requests configuration
  * @state: the state handle to select/activate/program
@@ -994,19 +1018,7 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
 
 	/* Apply all the settings for the new state */
 	list_for_each_entry(setting, &state->settings, node) {
-		switch (setting->type) {
-		case PIN_MAP_TYPE_MUX_GROUP:
-			ret = pinmux_enable_setting(setting);
-			break;
-		case PIN_MAP_TYPE_CONFIGS_PIN:
-		case PIN_MAP_TYPE_CONFIGS_GROUP:
-			ret = pinconf_apply_setting(setting);
-			break;
-		default:
-			ret = -EINVAL;
-			break;
-		}
-
+		ret = pinctrl_apply_setting(setting);
 		if (ret < 0) {
 			goto unapply_new_state;
 		}
@@ -1041,6 +1053,122 @@ unapply_new_state:
 }
 EXPORT_SYMBOL_GPL(pinctrl_select_state);
 
+/**
+ * pinctrl_setting_get_group_pins() - get group pins for a pinctrl setting
+ * @s: pinctrl setting pointer
+ * @pins: pins
+ * @num_pins: number of pins
+ */
+static int pinctrl_setting_get_group_pins(struct pinctrl_setting *s,
+				const unsigned **pins, unsigned *num_pins)
+{
+	struct pinctrl_dev *pctldev;
+	const struct pinctrl_ops *pctlops;
+
+	if (s->type != PIN_MAP_TYPE_MUX_GROUP)
+		return -EINVAL;
+
+	pctldev = s->pctldev;
+	pctlops = pctldev->desc->pctlops;
+
+	return pctlops->get_group_pins(pctldev, s->data.mux.group,
+					pins, num_pins);
+}
+
+/**
+ * pinctrl_state_get_pin_count() - get a pin count for a state
+ * @st: pinctrl state pointer
+ */
+static int pinctrl_state_get_pin_count(struct pinctrl_state *st)
+{
+	struct pinctrl_setting *s;
+	int found = 0;
+
+	list_for_each_entry(s, &st->settings, node) {
+		const unsigned *pins;
+		unsigned num_pins;
+		int res;
+
+		res = pinctrl_setting_get_group_pins(s, &pins, &num_pins);
+		if (res)
+			continue;
+
+		found += num_pins;
+	}
+
+	return found;
+}
+
+/**
+ * pinctrl_check_dynamic() - compare two states for the pins
+ * @dev: pinctrl consumer device pointer
+ * @st1: state handle
+ * @st2: state handle
+ *
+ * This function checks that the group pins match between the two
+ * states to avoid runtime checking. Note that currently the checking
+ * is very minimal, but can be enhanced as needed. Even this minimal
+ * check should be enough to avoid trying to use the default pins state
+ * with pinctrl_select_dynamic().
+ *
+ * Call this during pinctrl consumer driver probe time to check
+ * dynamic pin states used by the device for runtime PM etc.
+
+ * REVISIT: We can improve this further by adding device_get_pins()
+ * and adding a sorted state arrays for pins at device probe time.
+ * The comparing two states can be done just by comparing the two
+ * arrays.
+ */
+int pinctrl_check_dynamic(struct device *dev, struct pinctrl_state *st1,
+			  struct pinctrl_state *st2)
+{
+	int num_pins1, num_pins2;
+
+	num_pins1 = pinctrl_state_get_pin_count(st1);
+	num_pins2 = pinctrl_state_get_pin_count(st2);
+
+	if (num_pins1 != num_pins2) {
+		dev_err(dev, "device pins do not match for PM states\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pinctrl_check_dynamic);
+
+/**
+ * pinctrl_select_dynamic() - fast path for toggling pre-validated sets of pins
+ * @p: the pinctrl handle for the device that requests configuration
+ * @state: the state handle to select/activate/program
+ *
+ * Note that as we've already checked that the PINCTRL_DYNAMIC pins always
+ * cover the same sets for active/idle, or rx/tx, there's no need to call
+ * pinux_disable_settings() on these pins. Calling it could also cause
+ * issues for the connected peripheral as it potentially could change the
+ * values of data lines for example.
+ */
+int pinctrl_select_dynamic(struct pinctrl *p, struct pinctrl_state *state)
+{
+	struct pinctrl_setting *setting;
+	int ret;
+
+	if (p->state[PINCTRL_DYNAMIC] == state)
+		return 0;
+
+	list_for_each_entry(setting, &state->settings, node) {
+		ret = pinctrl_apply_setting(setting);
+		if (ret < 0) {
+			dev_err(p->dev, "Error applying dynamic settings\n");
+			return ret;
+		}
+	}
+
+	p->state[PINCTRL_DYNAMIC] = state;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pinctrl_select_dynamic);
+
 static void devm_pinctrl_release(struct device *dev, void *res)
 {
 	pinctrl_put(*(struct pinctrl **)res);
@@ -1240,7 +1368,13 @@ static int pinctrl_pm_select_state(struct device *dev,
 
 	if (IS_ERR(state))
 		return 0; /* No such state */
-	ret = pinctrl_select_state(pins->p, state);
+
+	/* Configured for dynamic muxing? */
+	if (!IS_ERR(dev->pins->active_state))
+		ret = pinctrl_select_dynamic(pins->p, state);
+	else
+		ret = pinctrl_select_state(pins->p, state);
+
 	if (ret)
 		dev_err(dev, "failed to activate pinctrl state %s\n",
 			state->name);
@@ -1261,6 +1395,19 @@ int pinctrl_pm_select_default_state(struct device *dev)
 EXPORT_SYMBOL_GPL(pinctrl_pm_select_default_state);
 
 /**
+ * pinctrl_pm_select_active_state() - select active pinctrl state for PM
+ * @dev: device to select default state for
+ */
+int pinctrl_pm_select_active_state(struct device *dev)
+{
+	if (!dev->pins)
+		return 0;
+
+	return pinctrl_pm_select_state(dev, dev->pins->active_state);
+}
+EXPORT_SYMBOL_GPL(pinctrl_pm_select_active_state);
+
+/**
  * pinctrl_pm_select_sleep_state() - select sleep pinctrl state for PM
  * @dev: device to select sleep state for
  */
@@ -1285,6 +1432,47 @@ int pinctrl_pm_select_idle_state(struct device *dev)
 	return pinctrl_pm_select_state(dev, dev->pins->idle_state);
 }
 EXPORT_SYMBOL_GPL(pinctrl_pm_select_idle_state);
+
+static int pinctrl_pm_is_state_error(struct device *dev,
+				  struct pinctrl_state *state)
+{
+	if (!dev)
+		return -EINVAL;
+
+	return IS_ERR(state);
+}
+
+/**
+ * pinctrl_pm_is_sleep_state_error() - check if sleep state is configured
+ * @dev: consumer device
+ *
+ * Call this from consumer driver to check if the sleep state
+ * has been properly configured on the device.
+ */
+int pinctrl_pm_is_sleep_state_error(struct device *dev)
+{
+	if (!dev->pins)
+		return 0;
+
+	return pinctrl_pm_is_state_error(dev, dev->pins->sleep_state);
+}
+EXPORT_SYMBOL_GPL(pinctrl_pm_is_sleep_state_error);
+
+/**
+ * pinctrl_pm_is_idle_state_error() - check if idle state is configured
+ * @dev: consumer device
+ *
+ * Call this from consumer driver to check if the idle state
+ * has been properly configured on the device.
+ */
+int pinctrl_pm_is_idle_state_error(struct device *dev)
+{
+	if (!dev->pins)
+		return 0;
+
+	return pinctrl_pm_is_state_error(dev, dev->pins->idle_state);
+}
+EXPORT_SYMBOL_GPL(pinctrl_pm_is_idle_state_error);
 #endif
 
 #ifdef CONFIG_DEBUG_FS
@@ -1491,10 +1679,12 @@ static int pinctrl_show(struct seq_file *s, void *what)
 	mutex_lock(&pinctrl_list_mutex);
 
 	list_for_each_entry(p, &pinctrl_list, node) {
-		seq_printf(s, "device: %s current state: %s\n",
+		seq_printf(s, "device: %s current states: %s %s\n",
 			   dev_name(p->dev),
 			   p->state[PINCTRL_STATIC] ?
-			   p->state[PINCTRL_STATIC]->name : "none");
+			   p->state[PINCTRL_STATIC]->name : "none",
+			   p->state[PINCTRL_DYNAMIC] ?
+			   p->state[PINCTRL_DYNAMIC]->name : "none");
 
 		list_for_each_entry(state, &p->states, node) {
 			seq_printf(s, "  state: %s\n", state->name);
diff --git a/include/linux/pinctrl/consumer.h b/include/linux/pinctrl/consumer.h
index 18eccef..333885b 100644
--- a/include/linux/pinctrl/consumer.h
+++ b/include/linux/pinctrl/consumer.h
@@ -36,19 +36,29 @@ extern struct pinctrl_state * __must_check pinctrl_lookup_state(
 							struct pinctrl *p,
 							const char *name);
 extern int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *s);
+extern int pinctrl_check_dynamic(struct device *dev, struct pinctrl_state *s1,
+				 struct pinctrl_state *s2);
+extern int pinctrl_select_dynamic(struct pinctrl *p, struct pinctrl_state *s);
 
 extern struct pinctrl * __must_check devm_pinctrl_get(struct device *dev);
 extern void devm_pinctrl_put(struct pinctrl *p);
 
 #ifdef CONFIG_PM
 extern int pinctrl_pm_select_default_state(struct device *dev);
+extern int pinctrl_pm_select_active_state(struct device *dev);
 extern int pinctrl_pm_select_sleep_state(struct device *dev);
 extern int pinctrl_pm_select_idle_state(struct device *dev);
+extern int pinctrl_pm_is_sleep_state_error(struct device *dev);
+extern int pinctrl_pm_is_idle_state_error(struct device *dev);
 #else
 static inline int pinctrl_pm_select_default_state(struct device *dev)
 {
 	return 0;
 }
+static inline int pinctrl_pm_select_active_state(struct device *dev)
+{
+	return 0;
+}
 static inline int pinctrl_pm_select_sleep_state(struct device *dev)
 {
 	return 0;
@@ -57,6 +67,14 @@ static inline int pinctrl_pm_select_idle_state(struct device *dev)
 {
 	return 0;
 }
+static inline int pinctrl_pm_is_sleep_state_error(struct device *dev)
+{
+	return -ENODEV;
+}
+static inline int pinctrl_pm_is_idle_state_error(struct device *dev)
+{
+	return -ENODEV;
+}
 #endif
 
 #else /* !CONFIG_PINCTRL */
@@ -102,6 +120,19 @@ static inline int pinctrl_select_state(struct pinctrl *p,
 	return 0;
 }
 
+static inline int pinctrl_check_dynamic(struct device *dev,
+					struct pinctrl_state *s1,
+					struct pinctrl_state *s2)
+{
+	return 0;
+}
+
+static inline int pinctrl_select_dynamic(struct pinctrl *p,
+				       struct pinctrl_state *s)
+{
+	return 0;
+}
+
 static inline struct pinctrl * __must_check devm_pinctrl_get(struct device *dev)
 {
 	return NULL;
@@ -116,6 +147,11 @@ static inline int pinctrl_pm_select_default_state(struct device *dev)
 	return 0;
 }
 
+static inline int pinctrl_pm_select_active_state(struct device *dev)
+{
+	return 0;
+}
+
 static inline int pinctrl_pm_select_sleep_state(struct device *dev)
 {
 	return 0;
@@ -126,6 +162,16 @@ static inline int pinctrl_pm_select_idle_state(struct device *dev)
 	return 0;
 }
 
+static inline int pinctrl_pm_is_sleep_state_error(struct device *dev)
+{
+	return -ENODEV;
+}
+
+static inline int pinctrl_pm_is_idle_state_error(struct device *dev)
+{
+	return -ENODEV;
+}
+
 #endif /* CONFIG_PINCTRL */
 
 static inline struct pinctrl * __must_check pinctrl_get_select(
diff --git a/include/linux/pinctrl/devinfo.h b/include/linux/pinctrl/devinfo.h
index 281cb91..2857a7b 100644
--- a/include/linux/pinctrl/devinfo.h
+++ b/include/linux/pinctrl/devinfo.h
@@ -24,10 +24,14 @@
  * struct dev_pin_info - pin state container for devices
  * @p: pinctrl handle for the containing device
  * @default_state: the default state for the handle, if found
+ * @active_state: the default state for the handle, if found
+ * @sleep_state: the default state for the handle, if found
+ * @idle_state: the default state for the handle, if found
  */
 struct dev_pin_info {
 	struct pinctrl *p;
 	struct pinctrl_state *default_state;
+	struct pinctrl_state *active_state;
 #ifdef CONFIG_PM
 	struct pinctrl_state *sleep_state;
 	struct pinctrl_state *idle_state;
diff --git a/include/linux/pinctrl/pinctrl-state.h b/include/linux/pinctrl/pinctrl-state.h
index b5919f8..c136e82 100644
--- a/include/linux/pinctrl/pinctrl-state.h
+++ b/include/linux/pinctrl/pinctrl-state.h
@@ -9,16 +9,27 @@
  *	hogs to configure muxing and pins at boot, and also as a state
  *	to go into when returning from sleep and idle in
  *	.pm_runtime_resume() or ordinary .resume() for example.
+ * @PINCTRL_STATE_ACTIVE: optional state of dynamic pins in addition to
+ *	PINCTRL_STATE_DEFAULT that are needed during runtime.
  * @PINCTRL_STATE_IDLE: the state the pinctrl handle shall be put into
  *	when the pins are idle. This is a state where the system is relaxed
  *	but not fully sleeping - some power may be on but clocks gated for
  *	example. Could typically be set from a pm_runtime_suspend() or
- *	pm_runtime_idle() operation.
+ *	pm_runtime_idle() operation. If PINCTRL_STATE_ACTIVE pins are
+ *	defined, PINCTRL_STATE_IDLE pin groups must cover the same pin
+ *	groups as PINCTRL_STATE_ACTIVE and selecting PINCTRL_STATE_IDLE
+ *	must be done using pinctrl_select_state_dynamic() instead of
+ *	pinctrl_select_state().
  * @PINCTRL_STATE_SLEEP: the state the pinctrl handle shall be put into
  *	when the pins are sleeping. This is a state where the system is in
  *	its lowest sleep state. Could typically be set from an
- *	ordinary .suspend() function.
+ *	ordinary .suspend() function. If PINCTRL_STATE_ACTIVE pins are
+ *	defined, PINCTRL_STATE_SLEEP pin groups must cover the same pin
+ *	groups as PINCTRL_STATE_ACTIVE and selecting PINCTRL_STATE_SLEEP
+ *	must be done using pinctrl_select_state_dynamic() instead of
+ *	pinctrl_select_state().
  */
 #define PINCTRL_STATE_DEFAULT "default"
+#define PINCTRL_STATE_ACTIVE "active"
 #define PINCTRL_STATE_IDLE "idle"
 #define PINCTRL_STATE_SLEEP "sleep"



From marc.zyngier at arm.com  Thu Jul 18 11:26:18 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Jul 2013 16:26:18 +0100
Subject: [PATCH 0/3] arm/arm64: a trio of boot mode detection fixes
In-Reply-To: <1373379366-15689-1-git-send-email-mark.rutland@arm.com>
References: <1373379366-15689-1-git-send-email-mark.rutland@arm.com>
Message-ID: <51E8091A.5040302@arm.com>

On 09/07/13 15:16, Mark Rutland wrote:
> The following patches fix a couple of issues in the boot mode detection
> code where in the case of mismatched boot modes we can corrupt a small
> portion of memory or fail to detect the fact we've booted CPUs with
> mismatched modes due to the boot mode being logged incoherently.

Sorry for the delay in replying to this. The whole series looks good to
me, so: Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.

> Thanks,
> Mark.
> 
> Mark Rutland (3):
>   arm: hyp: fix macro parameterisation
>   arm: virt: ensure visibility of __boot_cpu_mode
>   arm64: virt: ensure visibility of __boot_cpu_mode
> 
>  arch/arm/include/asm/virt.h   | 12 ++++++++++++
>  arch/arm/kernel/hyp-stub.S    |  4 ++--
>  arch/arm/kernel/setup.c       |  2 ++
>  arch/arm64/include/asm/virt.h | 13 +++++++++++++
>  4 files changed, 29 insertions(+), 2 deletions(-)
> 


-- 
Jazz is not dead. It just smells funny...



From thomas.petazzoni at free-electrons.com  Thu Jul 18 11:37:27 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 18 Jul 2013 17:37:27 +0200
Subject: Audio issue on Kirkwood t5325: no sound
In-Reply-To: <20130718142009.GX24642@n2100.arm.linux.org.uk>
References: <20130718134330.5aea00c5@skate>
 <20130718142009.GX24642@n2100.arm.linux.org.uk>
Message-ID: <20130718173727.2cfa38d3@skate>

Russell,

Thanks for your feedback!

On Thu, 18 Jul 2013 15:20:09 +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 18, 2013 at 01:43:30PM +0200, Thomas Petazzoni wrote:
> > As part of some work around audio support on Marvell platforms, I've
> > taken the Kirkwood-based HP t5325 thin client device that Martin
> > Michlmayr kindly gave me and tried to use the audio part of it, with
> > kernel 3.11-rc1. (My plan is to write the Device Tree binding for
> > this audio driver, and then use it for Armada 370 based platforms).
> 
> A couple of basic things to check:
> 
> 1. /proc/asound/card0/pcm0p/sub0/status
> 
> Does this indicate that the hw_ptr and appl_ptr are updating ?

Yes, it does:

# cat status 
state: RUNNING
owner_pid   : 720
trigger_time: 170.971641590
tstamp      : 172.468710470
delay       : 32224
avail       : 544
avail_max   : 28672
-----
hw_ptr      : 66080
appl_ptr    : 98304
# cat status 
state: RUNNING
owner_pid   : 720
trigger_time: 170.971641590
tstamp      : 173.042343190
delay       : 31520
avail       : 1248
avail_max   : 4096
-----
hw_ptr      : 91360
appl_ptr    : 122880

> 2. /proc/interrupts
> 
> Are you getting interrupts for kirkwood-i2s ?

Yes, I am:

# cat /proc/interrupts 
           CPU0       
 ...
 24:        109  orion_irq  kirkwood-i2s
 ...
# cat /proc/interrupts 
           CPU0       
 ...
 24:        116  orion_irq  kirkwood-i2s
 ...

> That will confirm whether the I2S unit is reading data from the ring
> buffer.  I suspect these will be a positive yes, given that aplay
> appears to work normally except being muted.

Your suspicion was indeed correct. Seems like the audio samples are
really being played.

> Another thing to check is the DAPM status, which you can find buried
> in /sys/kernel/debug/asoc - check all the DAPM status you can find
> below there, and check whether you think it's reasonable.

# for i in /sys/kernel/debug/asoc/t5325/dapm/* ; do echo $i ; cat "$i" ; done
/sys/kernel/debug/asoc/t5325/dapm/Headphone Jack
Headphone Jack: Off  in 2 out 1
 in  "static" "HPR"
 in  "static" "HPL"
/sys/kernel/debug/asoc/t5325/dapm/Mic Jack
Mic Jack: Off  in 1 out 0
 out "static" "MIC2"
 out "static" "MIC1"
/sys/kernel/debug/asoc/t5325/dapm/Speaker
Speaker: Off  in 2 out 1
 in  "static" "SPKOUTN"
 in  "static" "SPKOUT"
/sys/kernel/debug/asoc/t5325/dapm/bias_level
Off

I don't see anything that looks unreasonable in there, but I've never
played with DAPM and related things, so it is very possible that my
reasonable-guesser might be wrong on this.

Thoughts?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From linux at arm.linux.org.uk  Thu Jul 18 11:42:06 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Jul 2013 16:42:06 +0100
Subject: Audio issue on Kirkwood t5325: no sound
In-Reply-To: <20130718173727.2cfa38d3@skate>
References: <20130718134330.5aea00c5@skate>
 <20130718142009.GX24642@n2100.arm.linux.org.uk>
 <20130718173727.2cfa38d3@skate>
Message-ID: <20130718154206.GY24642@n2100.arm.linux.org.uk>

On Thu, Jul 18, 2013 at 05:37:27PM +0200, Thomas Petazzoni wrote:
> # for i in /sys/kernel/debug/asoc/t5325/dapm/* ; do echo $i ; cat "$i" ; done
> /sys/kernel/debug/asoc/t5325/dapm/Headphone Jack
> Headphone Jack: Off  in 2 out 1
>  in  "static" "HPR"
>  in  "static" "HPL"
> /sys/kernel/debug/asoc/t5325/dapm/Mic Jack
> Mic Jack: Off  in 1 out 0
>  out "static" "MIC2"
>  out "static" "MIC1"
> /sys/kernel/debug/asoc/t5325/dapm/Speaker
> Speaker: Off  in 2 out 1
>  in  "static" "SPKOUTN"
>  in  "static" "SPKOUT"
> /sys/kernel/debug/asoc/t5325/dapm/bias_level
> Off
> 
> I don't see anything that looks unreasonable in there, but I've never
> played with DAPM and related things, so it is very possible that my
> reasonable-guesser might be wrong on this.

The last one.  I've seen that with the UDA134x driver too, where the bias
level stays in a low power state, resulting in no audio output.  I fixed
it by adding DAPM to the UDA134x and my SA11x0 driver.  Mark mentioned
something about virtual DAPM support must not be working correctly.

This needs an understanding of the DAPM code, which I'm told is just a
graph walk.  However, trying to work out where stuff starts and how to
follow the code through the stages of state changes in soc-dapm.c has
proved to be quite an onerous task.  I think there's only one or maybe
two people on this planet who understands that chunk of code.

At this point, you need Mark or Liam to sort this out.


From soren.brinkmann at xilinx.com  Thu Jul 18 11:45:03 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Thu, 18 Jul 2013 08:45:03 -0700
Subject: [PATCH 3/3] arm: zynq: slcr: Use read-modify-write for register
 writes
In-Reply-To: <20130718072106.GB15514@pengutronix.de>
References: <1374081015-31431-1-git-send-email-soren.brinkmann@xilinx.com>
 <1374081015-31431-4-git-send-email-soren.brinkmann@xilinx.com>
 <20130718072106.GB15514@pengutronix.de>
Message-ID: <a57f684c-8983-48d2-8e99-8c9712383091@TX2EHSMHS024.ehs.local>

On Thu, Jul 18, 2013 at 09:21:06AM +0200, Steffen Trumtrar wrote:
> On Wed, Jul 17, 2013 at 10:10:15AM -0700, S?ren Brinkmann wrote:
> > zynq_slcr_cpu_start/stop() ignored the current register state when
> > writing to a register. Fixing this by implementing proper
> > read-modify-write.
> > 
> > Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
> > ---
> >  arch/arm/mach-zynq/slcr.c | 16 ++++++++--------
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/arm/mach-zynq/slcr.c b/arch/arm/mach-zynq/slcr.c
> > index 44a4ab6..1836d5a 100644
> > --- a/arch/arm/mach-zynq/slcr.c
> > +++ b/arch/arm/mach-zynq/slcr.c
> > @@ -61,11 +61,11 @@ void zynq_slcr_system_reset(void)
> >   */
> >  void zynq_slcr_cpu_start(int cpu)
> >  {
> > -	/* enable CPUn */
> > -	writel(SLCR_A9_CPU_CLKSTOP << cpu,
> > -	       zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
> > -	/* enable CLK for CPUn */
> > -	writel(0x0 << cpu, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
> > +	u32 reg = readl(zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
> > +	reg &= ~(SLCR_A9_CPU_RST << cpu);
> > +	writel(reg, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
> > +	reg &= ~(SLCR_A9_CPU_CLKSTOP << cpu);
> > +	writel(reg, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
> >  }
> >  
> >  /**
> > @@ -74,9 +74,9 @@ void zynq_slcr_cpu_start(int cpu)
> >   */
> >  void zynq_slcr_cpu_stop(int cpu)
> >  {
> > -	/* stop CLK and reset CPUn */
> > -	writel((SLCR_A9_CPU_CLKSTOP | SLCR_A9_CPU_RST) << cpu,
> > -	       zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
> > +	u32 reg = readl(zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
> > +	reg |= (SLCR_A9_CPU_CLKSTOP | SLCR_A9_CPU_RST) << cpu;
> > +	writel(reg, zynq_slcr_base + SLCR_A9_CPU_RST_CTRL_OFFSET);
> >  }
> >  
> 
> Hi!
> 
> Why do you also remove the comments? In my opinion they can stay.
I found the #defines descriptive enough

	S?ren




From gregkh at linuxfoundation.org  Thu Jul 18 11:49:54 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Thu, 18 Jul 2013 08:49:54 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51E7AE88.3050007@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-2-git-send-email-kishon@ti.com>
 <20130718072004.GA16720@kroah.com> <51E7AE88.3050007@ti.com>
Message-ID: <20130718154954.GA31961@kroah.com>

On Thu, Jul 18, 2013 at 02:29:52PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Thursday 18 July 2013 12:50 PM, Greg KH wrote:
> > On Thu, Jul 18, 2013 at 12:16:10PM +0530, Kishon Vijay Abraham I wrote:
> >> +struct phy_provider *__of_phy_provider_register(struct device *dev,
> >> +	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
> >> +	struct of_phandle_args *args));
> >> +struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
> >> +	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
> >> +	struct of_phandle_args *args))
> >> +
> >> +__of_phy_provider_register and __devm_of_phy_provider_register can be used to
> >> +register the phy_provider and it takes device, owner and of_xlate as
> >> +arguments. For the dt boot case, all PHY providers should use one of the above
> >> +2 APIs to register the PHY provider.
> > 
> > Why do you have __ for the prefix of a public function?  Is that really
> > the way that OF handles this type of thing?
> 
> I have a macro of_phy_provider_register/devm_of_phy_provider_register that
> calls these functions and should be used by the PHY drivers. Probably I should
> make a mention of it in the Documentation.

Yes, mention those as you never want to be calling __* functions
directly, right?

> >> +	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
> > 
> > Your naming is odd, no "phy" anywhere in it?  You rely on the sender to
> > never send a duplicate name.id pair?  Why not create your own ids based
> > on the number of phys in the system, like almost all other classes and
> > subsystems do?
> 
> hmm.. some PHY drivers use the id they provide to perform some of their
> internal operation as in [1] (This is used only if a single PHY provider
> implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO
> to give the PHY drivers an option to use auto id.
> 
> [1] ->
> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html

No, who cares about the id?  No one outside of the phy core ever should,
because you pass back the only pointer that they really do care about,
if they need to do anything with the device.  Use that, and then you can
rip out all of the "search for a phy by a string" logic, as that's not
needed either.  Just stick to the pointer, it's easier, and safer that
way.

> >> +static inline int phy_pm_runtime_get(struct phy *phy)
> >> +{
> >> +	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
> >> +		return -EINVAL;
> > 
> > Why would phy ever not be valid and a error pointer?  And why dump the
> > stack if that happens, that seems really extreme.
> 
> hmm.. there might be cases where the same controller in one soc needs PHY
> control and in some other soc does not need PHY control. In such cases, we
> might get error pointer here.
> I'll change WARN to dev_err.

I still don't understand.  You have control over the code that calls
these functions, just ensure that they pass in a valid pointer, it's
that simple.  Or am I missing something?

thanks,

greg k-h


From stern at rowland.harvard.edu  Thu Jul 18 11:50:00 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Thu, 18 Jul 2013 11:50:00 -0400 (EDT)
Subject: [PATCH V3 2/6] USB: OHCI: make ohci-omap a separate driver
In-Reply-To: <1372141408-9894-3-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <Pine.LNX.4.44L0.1307181144480.1245-100000@iolanthe.rowland.org>

On Tue, 25 Jun 2013, Manjunath Goudar wrote:

> Separate the  TI OHCI OMAP1/2 host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.11.
   
I'm sorry it took so long to review this; I have been very busy. 
    
This patch is almost right.  There are just a couple of problems 
involving the clock_power calls.

> @@ -354,12 +358,6 @@ static int usb_hcd_omap_probe (const struct hc_driver *driver,
>  		goto err2;
>  	}
>  
> -	ohci = hcd_to_ohci(hcd);
> -	ohci_hcd_init(ohci);
> -
> -	host_initialized = 0;
> -	host_enabled = 1;
> -
>  	irq = platform_get_irq(pdev, 0);
>  	if (irq < 0) {
>  		retval = -ENXIO;
> @@ -369,11 +367,7 @@ static int usb_hcd_omap_probe (const struct hc_driver *driver,
>  	if (retval)
>  		goto err3;
>  
> -	host_initialized = 1;
> -
> -	if (!host_enabled)
> -		omap_ohci_clock_power(0);
> -
> +	omap_ohci_clock_power(0);

Since host_enabled was always 1 at this point, omap_ohci_clock_power()
would never be called.  You should remove it.

> @@ -402,6 +396,8 @@ err0:
>  static inline void
>  usb_hcd_omap_remove (struct usb_hcd *hcd, struct platform_device *pdev)
>  {
> +	dev_dbg(hcd->self.controller, "stopping USB Controller\n");
> +	omap_ohci_clock_power(0);
>  	usb_remove_hcd(hcd);
>  	if (!IS_ERR_OR_NULL(hcd->phy)) {
>  		(void) otg_set_host(hcd->phy->otg, 0);

omap_ohci_clock_power() should be called after usb_remove_hcd(), not
before.  This reason is simple: Until usb_remove_hcd() is called, the
controller is still running and therefore needs to have a valid clock
signal.

Alan Stern



From will.deacon at arm.com  Thu Jul 18 11:51:15 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 18 Jul 2013 16:51:15 +0100
Subject: [PATCH] ARM: bugfix: Features of /proc/cpuinfo is wrong
In-Reply-To: <1374043709-24770-1-git-send-email-koba@kmckk.co.jp>
References: <1374043709-24770-1-git-send-email-koba@kmckk.co.jp>
Message-ID: <20130718155115.GC9733@mudshark.cambridge.arm.com>

On Wed, Jul 17, 2013 at 07:48:29AM +0100, Tetsuyuki Kobayashi wrote:
> Array hwcap_str[19] should be "vfpd32" and hwcap_str[20] should be "lpae".
> But actually "vfpd32" was missing and "lpae" was at wrong place.
> 
> Signed-off-by: Tetsuyuki Kobayashi <koba at kmckk.co.jp>

[...]

> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 63af9a7..96286cb 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -971,6 +971,7 @@ static const char *hwcap_str[] = {
>  	"vfpv4",
>  	"idiva",
>  	"idivt",
> +	"vfpd32",
>  	"lpae",
>  	NULL
>  };
> -- 

Acked-by: Will Deacon <will.deacon at arm.com>

Please can you put this into the patch system? It needs to get in for 3.11.

Cheers,

Will


From mark.rutland at arm.com  Thu Jul 18 12:06:05 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 18 Jul 2013 17:06:05 +0100
Subject: [PATCH V3] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene
 host
In-Reply-To: <1374048718-9455-1-git-send-email-anup.patel@linaro.org>
References: <1374048718-9455-1-git-send-email-anup.patel@linaro.org>
Message-ID: <20130718160605.GB18520@e106331-lin.cambridge.arm.com>

On Wed, Jul 17, 2013 at 09:11:58AM +0100, Anup Patel wrote:
> This patch allows us to have X-Gene guest VCPU when using KVM arm64
> on APM X-Gene host.
> 
> We add KVM_ARM_TARGET_XGENE_POTENZA for X-Gene Potenza compatible
> guest VCPU and we return KVM_ARM_TARGET_XGENE_POTENZA in kvm_target_cpu()
> when running on X-Gene host with Potenza core.
> 
> V3:
>  - Reduce multiple "return -EINVAL" in kvm_target_cpu()
> 
> V2:
>  - Renamed KVM_ARM_TARGET_XGENE_V8 to KVM_ARM_TARGET_XGENE_POTENZA
> 
> V1:
>  - Initial patch with target named as KVM_ARM_TARGET_XGENE_V8
> 
> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> ---
>  arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
>  arch/arm64/kvm/guest.c               |   36 ++++++++++++++++++++++------------
>  arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
>  3 files changed, 29 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 5031f42..d9f026b 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -55,8 +55,9 @@ struct kvm_regs {
>  #define KVM_ARM_TARGET_AEM_V8		0
>  #define KVM_ARM_TARGET_FOUNDATION_V8	1
>  #define KVM_ARM_TARGET_CORTEX_A57	2
> +#define KVM_ARM_TARGET_XGENE_POTENZA	3
>  
> -#define KVM_ARM_NUM_TARGETS		3
> +#define KVM_ARM_NUM_TARGETS		4
>  
>  /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
>  #define KVM_ARM_DEVICE_TYPE_SHIFT	0
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 2c3ff67..143d179 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -207,20 +207,32 @@ int __attribute_const__ kvm_target_cpu(void)
>  	unsigned long implementor = read_cpuid_implementor();
>  	unsigned long part_number = read_cpuid_part_number();
>  
> -	if (implementor != ARM_CPU_IMP_ARM)
> -		return -EINVAL;
> -
> -	switch (part_number) {
> -	case ARM_CPU_PART_AEM_V8:
> -		return KVM_ARM_TARGET_AEM_V8;
> -	case ARM_CPU_PART_FOUNDATION:
> -		return KVM_ARM_TARGET_FOUNDATION_V8;
> -	case ARM_CPU_PART_CORTEX_A57:
> -		/* Currently handled by the generic backend */
> -		return KVM_ARM_TARGET_CORTEX_A57;
> +	switch (implementor) {
> +	case ARM_CPU_IMP_ARM:
> +		switch (part_number) {
> +		case ARM_CPU_PART_AEM_V8:
> +			return KVM_ARM_TARGET_AEM_V8;
> +		case ARM_CPU_PART_FOUNDATION:
> +			return KVM_ARM_TARGET_FOUNDATION_V8;
> +		case ARM_CPU_PART_CORTEX_A57:
> +			return KVM_ARM_TARGET_CORTEX_A57;
> +		default:
> +	 		break;

This can go, the break outside the switch will handle it.

> +		}
> +		break;
> +	case ARM_CPU_IMP_APM:
> +		switch (part_number) {
> +		case APM_CPU_PART_POTENZA:
> +			return KVM_ARM_TARGET_XGENE_POTENZA;
> +		default:
> +	 		break;

This one too.

> +		}
> +		break;
>  	default:
> -		return -EINVAL;
> + 		break;

Given we'll fall out of the switch for an unknown implementor, we don't
need the final break.

Thanks,
Mark.

>  	}
> +
> +	return -EINVAL;
>  }
>  
>  int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
> diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
> index 4268ab9..8fe6f76 100644
> --- a/arch/arm64/kvm/sys_regs_generic_v8.c
> +++ b/arch/arm64/kvm/sys_regs_generic_v8.c
> @@ -90,6 +90,9 @@ static int __init sys_reg_genericv8_init(void)
>  					  &genericv8_target_table);
>  	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_CORTEX_A57,
>  					  &genericv8_target_table);
> +	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_XGENE_POTENZA,
> +					  &genericv8_target_table);
> +
>  	return 0;
>  }
>  late_initcall(sys_reg_genericv8_init);
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From julien.grall at linaro.org  Thu Jul 18 12:15:21 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Thu, 18 Jul 2013 17:15:21 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabled
In-Reply-To: <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
Message-ID: <CAPnVf8yH7PBOSSC57qJv+pWmsinRUxGr81QUPH9GoOkKw2oo3Q@mail.gmail.com>

On 17 July 2013 14:25, Stefano Stabellini
<stefano.stabellini at eu.citrix.com> wrote:
> On Mon, 15 Jul 2013, Julien Grall wrote:
>> Even if uncompress debug is disabled, some board will continue to print
>> information during uncompress step.
>
> Are you talking about DEBUG_UNCOMPRESS?
> Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> some board will continue to print information during the uncompress step"?

Yes. On the arndale, uncompress log are directly output on UART-2.
This is annoying
because  Xen doesn't expose the UART to dom0.

> Isn't this a bug in the platform specific code that should be fixed anyway?
>
>> By using debug/uncompress.h include, all debug output will be disabled.
>
> I am not sure if this is the right solution to the problem.
> I think it might be better to add the appropriate ifdefs into the
> platform specific code.

--
Julien Grall


From linux at arm.linux.org.uk  Thu Jul 18 12:23:44 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Jul 2013 17:23:44 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabled
In-Reply-To: <CAPnVf8yH7PBOSSC57qJv+pWmsinRUxGr81QUPH9GoOkKw2oo3Q@mail.gmail.com>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
 <CAPnVf8yH7PBOSSC57qJv+pWmsinRUxGr81QUPH9GoOkKw2oo3Q@mail.gmail.com>
Message-ID: <20130718162344.GZ24642@n2100.arm.linux.org.uk>

On Thu, Jul 18, 2013 at 05:15:21PM +0100, Julien Grall wrote:
> On 17 July 2013 14:25, Stefano Stabellini
> <stefano.stabellini at eu.citrix.com> wrote:
> > On Mon, 15 Jul 2013, Julien Grall wrote:
> >> Even if uncompress debug is disabled, some board will continue to print
> >> information during uncompress step.
> >
> > Are you talking about DEBUG_UNCOMPRESS?
> > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > some board will continue to print information during the uncompress step"?
> 
> Yes. On the arndale, uncompress log are directly output on UART-2.
> This is annoying because  Xen doesn't expose the UART to dom0.

The DEBUG_UNCOMPRESS option is not about whether the decompressor produces
output or not.  It is about the implementation of that output.

* With non-multiplatform kernels, the output is sent to whatever functions
  are found in arch/arm/*/include/mach/uncompress.h.

* With multiplatform kernels with DEBUG_UNCOMPRESS set, the output is sent
  using the kernel's LL debug functions.  (hence it's name - it's saying
  that it uses the debug macros.)

* With multiplatform kernels without DEBUG_UNCOMPRESS set, there is no
  way to know where to send the *normal* decompressor output, so we have
  decided that in this case and this case only, it shall be silent.

The final thing to remember is... the normal output from the decompressor
is *NOT* debug output.  It's informational or error output.

Everything here is working as intended.


From a.motakis at virtualopensystems.com  Thu Jul 18 12:24:34 2013
From: a.motakis at virtualopensystems.com (Antonios Motakis)
Date: Thu, 18 Jul 2013 18:24:34 +0200
Subject: [PATCH v7 00/12] iommu/exynos: Fixes and Enhancements of System
 MMU driver with DT
In-Reply-To: <002801ce797b$3d2fbc80$b78f3580$@samsung.com>
References: <002801ce797b$3d2fbc80$b78f3580$@samsung.com>
Message-ID: <CAG8rG2y8ZN4ahv7DqJ11=FhJpVVxcbAbTaViyi-D4GH=p3xg=A@mail.gmail.com>

Hello Cho,

I have been trying out the Exynos System MMU driver including your
fixes, however I notice that if you try to get the iommu_group of a
device (i.e. iommu_group_get(&pdev->dev)) this will not work. Since
each device is behind its own System MMU I would expect a distinct
iommu_group for that device, instead I get NULL (I tried this with the
MFC).

Indeed, it looks like this is not currently implemented in the driver.
Is this something that is on the roadmap?

Best regards,
Antonios Motakis

On Fri, Jul 5, 2013 at 2:29 PM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> The current exynos-iommu(System MMU) driver does not work autonomously
> since it is lack of support for power management of peripheral blocks.
> For example, MFC device driver must ensure that its System MMU is disabled
> before MFC block is power-down not to invalidate IOTLB in the System MMU
> when I/O memory mapping is changed. Because A System MMU is resides in the
> same H/W block, access to control registers of System MMU while the H/W
> block is turned off must be prohibited.
>
> This set of changes solves the above problem with setting each System MMUs
> as the parent of the device which owns the System MMU to recieve the
> information when the device is turned off or turned on.
>
> Another big change to the driver is the support for devicetree.
> The bindings for System MMU is described in
> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
>
> In addition, this patchset also includes several bug fixes and enhancements
> of the current driver.
>
> Change log:
> v7:
> - Rebased on the stable 3.10
> - Registered PM domains and gate clocks with DT
> - Changed connection method between a System MMU and its master H/W
>    'mmu-master' property in the node of System MMU
>    --> 'iommu' property in the node of master H/W
> - Marking device descriptor of master H/W of a System MMU with bus notifier.
> - Power management (PM_RUNTIME, PM_SLEEP) of System MMUs with gpd_dev_ops
>    of Generic IO Powerdomain. gpd_dev_ops are set to the master H/Ws
>    before they are probed in the bus notifier.
> - Removed additional debugging features like debugfs entries and
>    version names.
> - Removed support for advanced features of System MMU 3.2 and 3.3
>    the current IOMMU API cannot handle the feature
>   (A kind of L2 TLB that fetches several consequence page table entries.
>    It must be initialized by the driver of master H/W whenever it works.)
>
> v6:
> - Rebased on the branch, next/iommu-exynos of
>   git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>
> v5:
> - new bugfix: patch 01
> - Reordered patches
>   * patch 01 ~ 05: Bugfix and enhancements of the existing driver
>   * patch 06 ~ 10: Device Tree support and callbacks for power management
>   * patch 11     : System MMU 3.2 and 3.3 support
>   * patch 12 ~ 14: Debugging features
> - Additional code compaction
>
> v4:
> - Remove Change-Id from v3 patches
> - Change the order of the third and the first patch
>   Thanks to Kukjin Kim.
> - Fix memory leak when allocating and assigning exynos_iommu_owner to client
>   device if the client device has multiple System MMUs.
>   Thanks to Rahul Sharma.
>
> v3:
> - Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
> - Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
>   Thanks to Prathyush.
>
> v2:
> - Split the patch to iommu/exynos into 9 patches
> - Support for System MMU 3.3
> - Some code compaction
>
> Patch summary:
> [PATCH v7 1/9] iommu/exynos: do not include removed header
> [PATCH v7 2/9] iommu/exynos: add missing cache flush for removed page table entries
> [PATCH v7 3/9] iommu/exynos: fix page table maintenance
> [PATCH v7 4/9] iommu/exynos: allocate lv2 page table from own slab
> [PATCH v7 5/9] iommu/exynos: change rwlock to spinlock
> [PATCH v7 6/9] clk: exynos5250: add gate clock descriptions of System MMU
> [PATCH v7 7/9] ARM: dts: Add description of System MMU of Exynos SoCs
> [PATCH v7 8/9] iommu/exynos: support for device tree
> [PATCH v7 9/9] iommu/exynos: add bus notifier for registering System MMU
>
> Diffstats:
> .../devicetree/bindings/clock/exynos5250-clock.txt |   28 +-
> .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 ++
> arch/arm/boot/dts/exynos4.dtsi                     |  122 +++
> arch/arm/boot/dts/exynos4210.dtsi                  |   25 +
> arch/arm/boot/dts/exynos4x12.dtsi                  |   76 ++
> arch/arm/boot/dts/exynos5250.dtsi                  |  291 ++++++
> drivers/clk/samsung/clk-exynos5250.c               |   57 +-
> drivers/iommu/Kconfig                              |    5 +-
> drivers/iommu/exynos-iommu.c                       | 1011 +++++++++++++-------
> 9 files changed, 1382 insertions(+), 336 deletions(-)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


From mark.rutland at arm.com  Thu Jul 18 12:25:01 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 18 Jul 2013 17:25:01 +0100
Subject: [PATCH 0/3] arm/arm64: a trio of boot mode detection fixes
In-Reply-To: <51E8091A.5040302@arm.com>
References: <1373379366-15689-1-git-send-email-mark.rutland@arm.com>
 <51E8091A.5040302@arm.com>
Message-ID: <20130718162501.GA20870@e106331-lin.cambridge.arm.com>

On Thu, Jul 18, 2013 at 04:26:18PM +0100, Marc Zyngier wrote:
> On 09/07/13 15:16, Mark Rutland wrote:
> > The following patches fix a couple of issues in the boot mode detection
> > code where in the case of mismatched boot modes we can corrupt a small
> > portion of memory or fail to detect the fact we've booted CPUs with
> > mismatched modes due to the boot mode being logged incoherently.
> 
> Sorry for the delay in replying to this. The whole series looks good to
> me, so: Acked-by: Marc Zyngier <marc.zyngier at arm.com>

Cheers.

Russell,
I've dropped the first two patches into the patch system as 7786/1 and
7787/1.

Catalin,
Are you happy to pick up the third patch?

Thanks,
Mark.

> 
> 	M.
> 
> > Thanks,
> > Mark.
> > 
> > Mark Rutland (3):
> >   arm: hyp: fix macro parameterisation
> >   arm: virt: ensure visibility of __boot_cpu_mode
> >   arm64: virt: ensure visibility of __boot_cpu_mode
> > 
> >  arch/arm/include/asm/virt.h   | 12 ++++++++++++
> >  arch/arm/kernel/hyp-stub.S    |  4 ++--
> >  arch/arm/kernel/setup.c       |  2 ++
> >  arch/arm64/include/asm/virt.h | 13 +++++++++++++
> >  4 files changed, 29 insertions(+), 2 deletions(-)
> > 
> 
> 
> -- 
> Jazz is not dead. It just smells funny...


From balajitk at ti.com  Thu Jul 18 12:40:30 2013
From: balajitk at ti.com (Balaji T K)
Date: Thu, 18 Jul 2013 22:10:30 +0530
Subject: ARM: AM335x: Kernel oops when using EDMA and MMC
In-Reply-To: <51E6C88B.8090608@ti.com>
References: <51E6BE84.6080905@newflow.co.uk> <51E6C88B.8090608@ti.com>
Message-ID: <51E81A7E.9030805@ti.com>

On Wednesday 17 July 2013 10:08 PM, Joel Fernandes wrote:
> On 07/17/2013 10:55 AM, Mark Jackson wrote:
>> I'm trying to get the MMC port working on our custom AM3352 CPU board.
>>
>> I have added MMC entries to out dts file (similar to [1]), and I've
>> enabled CONFIG_TI_EDMA.
>>
>> Our board boots fine without an SD card inserted ...
>>
>> [    0.000000] Booting Linux on physical CPU 0x0
>> [    0.000000] Linux version 3.11.0-rc1-00025-g95b9b72 (mpfj at mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #309 Wed Jul 17 16:37:28 BST 2013
>> ...
>> [    2.789028] VFS: Mounted root (ubifs filesystem) on device 0:12.
>> [    2.797268] devtmpfs: mounted
>> [    2.801032] Freeing unused kernel memory: 200K (c0551000 - c0583000)
>> ...
>> Welcome to Buildroot
>> nanobone login:
>>
>> But when I boot with a card already inserted, I get the following oops ...
>>
>> ...
>> [    1.827343] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
>> [    1.835868] pgd = c0004000
>> [    1.838774] [0000000c] *pgd=00000000
>> [    1.842556] Internal error: Oops: 5 [#1] ARM
>> [    1.847063] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.11.0-rc1-00025-g95b9b72 #309
>> [    1.855511] Workqueue: kmmcd mmc_rescan
>> [    1.859556] task: cf06a080 ti: cf072000 task.ti: cf072000
>> [    1.865257] PC is at omap_hsmmc_start_command+0x74/0xf4
>> [    1.870761] LR is at omap_hsmmc_request+0xec/0x4dc
>> [    1.875806] pc : [<c0305b70>]    lr : [<c0306c64>]    psr: 60000113
>> [    1.875806] sp : cf073ca0  ip : 00000000  fp : 00000008
>> [    1.887885] r10: cf073de8  r9 : 00000001  r8 : cf11d918
>> [    1.893382] r7 : 00000003  r6 : cf33cc80  r5 : 00000001  r4 : 00000033
>> [    1.900250] r3 : 00020000  r2 : cf073db8  r1 : cf073d84  r0 : cf33cc80
>> [    1.907122] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
>> [    1.914813] Control: 10c5387d  Table: 80004019  DAC: 00000015
>> [    1.920859] Process kworker/u2:0 (pid: 6, stack limit = 0xcf072238)
>> [    1.927454] Stack: (0xcf073ca0 to 0xcf074000)
>> [    1.932048] 3ca0: cf33c800 cf073d40 00000003 00000000 c0076a8c cf073d40 48060220 48060220
>> [    1.940659] 3cc0: 00000004 00000004 00000002 00000002 cf073ec8 c0421a9c c051835c cf073d40
>> [    1.949271] 3ce0: cf33c800 00000001 00000008 00000008 00000002 cf073db8 cf073ec8 c02f0f28
>> [    1.957882] 3d00: 00000200 00000064 00000000 cf073db8 cf073ec8 cf073d40 cf073d50 00000000
>> [    1.966493] 3d20: cf33c800 c02f18a4 cf369800 cf369a80 00000000 cf360880 00000008 c02f9964
>> [    1.975104] 3d40: 00000000 cf073d84 cf073db8 00000000 00000001 00000001 dead4ead ffffffff
>> [    1.983717] 3d60: ffffffff c0af722c c06aa3e4 00000000 c04ddadc cf073d74 cf073d74 c02f0dc4
>> [    1.992327] 3d80: 00000000 00000033 00000000 00000000 00000000 00000000 00000000 000000b5
>> [    2.000938] 3da0: 00000000 00000000 00000000 00000000 cf073db8 cf073d40 05f5e100 00000000
>> [    2.009548] 3dc0: 00000008 00000001 00000000 00000200 00000000 00000000 cf073d40 00000001
>> [    2.018159] 3de0: cf073de8 00000000 c0cf1c02 00000880 00000008 8f360880 00000000 cf369800
>> [    2.026771] 3e00: cf33c800 00000000 cf369800 cf073e4c cf072000 c02f8740 00000000 00000015
>> [    2.035382] 3e20: 00000003 cf33c800 00000000 00000000 cf369800 cf073e4c cf072000 c02f8b20
>> [    2.043994] 3e40: 00000002 c02f25cc 00000002 02544d53 41303447 1026c914 2600bbbd c0ff8000
>> [    2.052605] 3e60: c0455884 cf33c800 00000000 c0455884 c0455890 00000000 cf072000 c02f92bc
>> [    2.061217] 3e80: c0455890 00ff8000 00000002 cf33cb14 cf33c800 c02f3a28 cf041ac0 cf33cb14
>> [    2.069829] 3ea0: cf050c00 cf051c00 00000000 c00507ec 00000002 00000000 c0050778 c0050f10
>> [    2.078441] 3ec0: 00000000 00000000 c0af7268 c06aa1c4 00000000 c0518cd0 cf06a080 cf041ac0
>> [    2.087054] 3ee0: cf050c00 cf072000 cf050c30 cf041ad8 00000089 c05d7b5c cf050c00 c0050e4c
>> [    2.095665] 3f00: 00000000 cf072000 60000113 cf04dda8 00000000 cf041ac0 c0050d08 00000000
>> [    2.104276] 3f20: 00000000 00000000 00000000 c0056c94 c0429a18 00000000 00000001 cf041ac0
>> [    2.112888] 3f40: 00000000 00000001 dead4ead ffffffff ffffffff c05ec0a0 00000000 00000000
>> [    2.121499] 3f60: c04ddadc cf073f64 cf073f64 00000000 00000001 dead4ead ffffffff ffffffff
>> [    2.130112] 3f80: c05ec0a0 00000000 00000000 c04ddadc cf073f90 cf073f90 cf073fac cf04dda8
>> [    2.138724] 3fa0: c0056bf0 00000000 00000000 c0013588 00000000 00000000 00000000 00000000
>> [    2.147334] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> [    2.155946] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 57e0c5db 5ffb7d3c
>> [    2.164565] [<c0305b70>] (omap_hsmmc_start_command+0x74/0xf4) from [<00000003>] (0x3)
>> [    2.172814] Code: 13a03801 0a00001b e590c008 e5914000 (e59cc00c)
>> [    2.179314] ---[ end trace 6ec9899a56aef6aa ]---
>>
>> I have also noticed that when the kernel boots okay (without a card inserted), if
>> I then insert a card, nothing happens (even with CONFIG_MMC_DEBUG=y) ... including
>> no kernel oops.
>>
>> Can anyone shed light on what's wrong ?
>
> I see this issue too on -rc1. The mmc host pointer is mangled but this could be
> due to something totally unrelated.
>
Hi Joel,

With DMA channel info retrieved from dt binding on 3.11rc1,
unused_chan_list is broken after hwmod cleanup removing mmc sdma
resource info, hence pdev resource wont have DMA resource populated.

arch/arm/common/edma.c
static int prepare_unused_channel_list(struct device *dev, void *data)
{
	struct platform_device *pdev = to_platform_device(dev);
	int i, ctlr;

	for (i = 0; i < pdev->num_resources; i++) {
		if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
				(int)pdev->resource[i].start >= 0) {
			ctlr = EDMA_CTLR(pdev->resource[i].start);
			clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
					edma_cc[ctlr]->edma_unused);
		}
	}

	return 0;
}

int edma_alloc_channel(int channel,
	if (!unused_chan_list_done) {
		/*
		 * Scan all the platform devices to find out the EDMA channels
		 * used and clear them in the unused list, making the rest
		 * available for ARM usage.
		 */
		ret = bus_for_each_dev(&platform_bus_type, NULL, NULL,
				prepare_unused_channel_list);
		if (ret < 0)
			return ret;

		unused_chan_list_done = true;
	}

===========

with the below hack patch, edma is working fine with mmc on your 3.11rc1+ branch

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index a432e6c..5a19164 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1262,8 +1262,8 @@ int edma_start(unsigned channel)
  		if (test_bit(channel, edma_cc[ctlr]->edma_unused)) {
  			pr_debug("EDMA: ESR%d %08x\n", j,
  				edma_shadow0_read_array(ctlr, SH_ESR, j));
-			edma_shadow0_write_array(ctlr, SH_ESR, j, mask);
-			return 0;
+//			edma_shadow0_write_array(ctlr, SH_ESR, j, mask);
+//			return 0;
  		}

  		/* EDMA channel with event association */
-- 

> Can you first please try rebasing on 3.10 instead of 3.11-rc1?
>
> Thanks,
>
> -Joel
>


From julien.grall at linaro.org  Thu Jul 18 12:43:37 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Thu, 18 Jul 2013 17:43:37 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabled
In-Reply-To: <20130717151148.GM24642@n2100.arm.linux.org.uk>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
 <20130717151148.GM24642@n2100.arm.linux.org.uk>
Message-ID: <51E81B39.2030805@linaro.org>

On 07/17/2013 04:11 PM, Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 02:25:38PM +0100, Stefano Stabellini wrote:
>> On Mon, 15 Jul 2013, Julien Grall wrote:
>>> Even if uncompress debug is disabled, some board will continue to print
>>> information during uncompress step.
>>
>> Are you talking about DEBUG_UNCOMPRESS?
>> Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
>> some board will continue to print information during the uncompress step"?
>>
>> Isn't this a bug in the platform specific code that should be fixed anyway?
> 
> Hang on, let's be clear what's going on here.
> 
> 1. The normal output from the decompressor is *not* debugging.  By that
>    I mean the "Uncompressing kernel... done" message.  That is part of
>    user output.
> 
> 2. In non-multiplatform environments, the decompressor will normally use
>    the putc/flush functions found in arch/arm/mach-*/include/mach/uncompress.h
>    to implement its output, irrespective of the DEBUG_UNCOMPRESS setting.
>    (An interesting point is that DEBUG_UNCOMPRESS really should depend on
>    MULTIPLATFORM so that this point is explicit - the option requires
>    MULTIPLATFORM to be set.)
> 
> 3. DEBUG_UNCOMPRESS allows the functions which we've implemented for LL
>    debug to be re-used for decompressor output.

When Xen will boot, it will use one UART, given by the user, to be able
to log its information. Xen will not map the UART region and the IRQ to
dom0. Of course it will not be present in the device tree either. So if
Linux tries to access to this memory region, it will crash.

When Linux will boot as dom0, it will either use an hvc console or
another UART.

In case of multi-platform environments, there is no issue because when
CONFIG_DEBUG_UNCOMPRESS is disabled.

Now, in non-multiplatform environment, the decompressor will use a
pre-defined UART. This UART may be already used by Xen and Linux will
abort at the first access.

I think, the decompressor should be able to detect if the UART exists
(I'm not sure it's possible) or disabled at compile time uncompress log.

Do you have any better ideas?

Cheers,

-- 
Julien



From r.sricharan at ti.com  Thu Jul 18 12:43:47 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Thu, 18 Jul 2013 22:13:47 +0530
Subject: [PATCH 0/3] Add crossbar driver
Message-ID: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>

Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers are preceded by an
IRQ/DMA CROSSBAR that provides flexibility in muxing the device
requests to the controller inputs.

This series adds a crossbar driver and the DT bindings for the
same. Also the DT nodes for DRA7xx SOC which has a IRQ/DMA
crossbar has been added here.

This series is on top of the basic DRA support from Rajendra [1][2]

[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/100763
[2] http://comments.gmane.org/gmane.linux.ports.arm.omap/100773

Sricharan R (3):
  misc: Add crossbar driver
  ARM: dts: DRA: Add crossbar device binding
  ARM: DRA: Enable crossbar driver for dra soc

 .../devicetree/bindings/arm/omap/crossbar.txt      |   24 ++
 arch/arm/boot/dts/dra7.dtsi                        |   19 ++
 arch/arm/mach-omap2/Kconfig                        |    1 +
 drivers/misc/Kconfig                               |    8 +
 drivers/misc/Makefile                              |    1 +
 drivers/misc/crossbar.c                            |  258 ++++++++++++++++++++
 include/linux/crossbar.h                           |   71 ++++++
 7 files changed, 382 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
 create mode 100644 drivers/misc/crossbar.c
 create mode 100644 include/linux/crossbar.h

-- 
1.7.9.5



From r.sricharan at ti.com  Thu Jul 18 12:43:48 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Thu, 18 Jul 2013 22:13:48 +0530
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
Message-ID: <1374165830-6367-2-git-send-email-r.sricharan@ti.com>

Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers are preceded by an
IRQ/DMA CROSSBAR that provides flexibility in muxing the device
requests to the controller inputs.

The Peripheral irq/dma requests are connected to one crossbar's input
and the output of the crossbar is connected to controller's input
line. On POR, there are some mappings which are done by default.
Those peripherals which do not have a mapping on POR, should be configured
to route its requests using the crossbar.

The drivers identifies every controller's crossbar as individual devices.
The mappings can be specified from the DT crossbar nodes and those gets mapped
during the crossbar device's probe. The mappings can also be specified by adding
the crossbar lines to the peripheral device nodes and map it with
crossbar_map/unmap apis.

Signed-off-by: Sricharan R <r.sricharan at ti.com>
---
 .../devicetree/bindings/arm/omap/crossbar.txt      |   24 ++
 drivers/misc/Kconfig                               |    8 +
 drivers/misc/Makefile                              |    1 +
 drivers/misc/crossbar.c                            |  258 ++++++++++++++++++++
 include/linux/crossbar.h                           |   71 ++++++
 5 files changed, 362 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
 create mode 100644 drivers/misc/crossbar.c
 create mode 100644 include/linux/crossbar.h

diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 0000000..02a8a28
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,24 @@
+* TI - IRQ/DMA Crossbar
+
+This version is an implementation of the Crossbar IRQ/DMA IP
+
+Required properties:
+- compatible : Should be "ti,dra-crossbar"
+- crossbar-name: Name of the controller to which crossbar output is routed
+- reg:	Contains crossbar register address range
+- reg-width: Represents the width of the individual registers
+- crossbar-lines:  Default mappings.Should contain the crossbar-name
+		   device name, int/dma request number, crossbar number,
+		   register offset in the same order.
+
+Examples:
+		crossbar_mpu: mpuirq at 4a002a48 {
+			compatible = "crossbar";
+			crossbar-name = "mpu-irq";
+			reg = <0x4a002a48 0x0130>;
+			reg-width = <16>;
+			crossbar-lines = "mpu-irq", "rtc-ss-alarm", <0x9f 0xd9 0x12c>,
+					 "mpu-irq", "mcasp3-arevt", <0x9e 0x96 0x12a>,
+					 "mpu-irq", "mcasp3-axevt", <0x9d 0x97 0x128>;
+		};
+
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index c002d86..de89bff 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -527,6 +527,14 @@ config SRAM
 	  the genalloc API. It is supposed to be used for small on-chip SRAM
 	  areas found on many SoCs.
 
+config CROSSBAR
+	bool "on-chip crossbar driver"
+	select REGMAP_MMIO
+	help
+	  This driver is for IRQ/DMA crossbar devices which is responsible for
+	  muxing the irq/dma requests from external peripherals to the corresponding
+	  controller's inputs.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index c235d5b..37ce1b8 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_INTEL_MEI)		+= mei/
 obj-$(CONFIG_VMWARE_VMCI)	+= vmw_vmci/
 obj-$(CONFIG_LATTICE_ECP3_CONFIG)	+= lattice-ecp3-config.o
 obj-$(CONFIG_SRAM)		+= sram.o
+obj-$(CONFIG_CROSSBAR)		+= crossbar.o
diff --git a/drivers/misc/crossbar.c b/drivers/misc/crossbar.c
new file mode 100644
index 0000000..c0a7e83
--- /dev/null
+++ b/drivers/misc/crossbar.c
@@ -0,0 +1,258 @@
+/*
+ * IRQ/DMA CROSSBAR DRIVER
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *	Sricharan R <r.sricharan at ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ */
+#include <linux/crossbar.h>
+#include <linux/regmap.h>
+
+static LIST_HEAD(cb_devlist);
+
+static struct regmap_config cb_regmap_config = {
+	.reg_bits = 32,
+};
+
+static unsigned cb_entry_read(struct cb_line *tmp, const void *cbs)
+{
+	unsigned index = 0;
+
+	tmp->cb_name = cbs;
+	index = strlen(tmp->cb_name) + 1;
+
+	tmp->dev_name = cbs + index;
+	index += strlen(tmp->dev_name) + 1;
+
+	tmp->int_no = be32_to_cpup(cbs + index);
+	index += sizeof(tmp->int_no);
+
+	tmp->cb_no = be32_to_cpup(cbs + index);
+	index += sizeof(tmp->cb_no);
+
+	tmp->offset = be32_to_cpup(cbs + index);
+	index += sizeof(tmp->offset);
+
+	return index;
+}
+
+int crossbar_unmap(struct device_node *cbdev_node, unsigned index)
+{
+	const void *cbs;
+	unsigned size = 0, i = 0;
+	struct cb_line tmp;
+	struct cb_device *cbdev;
+	struct cb_entry *cbentry, *p;
+
+	cbs = of_get_property(cbdev_node, "crossbar-lines", &size);
+	if (!cbs)
+		return -ENOENT;
+
+	size = 0;
+
+	while (i++ < index)
+		size += cb_entry_read(&tmp, cbs + size);
+
+	cb_entry_read(&tmp, cbs + size);
+
+	list_for_each_entry(cbdev, &cb_devlist, node) {
+		if (strcmp(cbdev->name, tmp.cb_name))
+			continue;
+
+		mutex_lock(&cbdev->cb_lock);
+		list_for_each_entry_safe(cbentry, p, &cbdev->cb_entries,
+					 cb_list) {
+			if ((cbentry->line.cb_no == tmp.cb_no) &&
+			    (cbentry->line.int_no == tmp.int_no)) {
+				list_del(&cbentry->cb_list);
+				mutex_unlock(&cbdev->cb_lock);
+				dev_warn(cbdev->dev,
+					 "unmapped int_no %x mapped to cb %x\n",
+					 tmp.int_no, tmp.cb_no);
+				return 0;
+			}
+		}
+		mutex_unlock(&cbdev->cb_lock);
+		break;
+	}
+
+	dev_warn(cbdev->dev, "%s cb entry %d not found\n",
+		 __func__, tmp.cb_no);
+	return -ENOENT;
+}
+EXPORT_SYMBOL(crossbar_unmap);
+
+const int cb_map(struct cb_line cbl)
+{
+	struct cb_device *cbdev;
+	struct cb_entry *cbentry, *tmp;
+	unsigned val;
+
+	/* Get corresponding device pointer */
+	list_for_each_entry(cbdev, &cb_devlist, node) {
+		if (strcmp(cbdev->name, cbl.cb_name))
+			continue;
+
+		mutex_lock(&cbdev->cb_lock);
+
+		/* Check for invalid and duplicate mapping */
+		list_for_each_entry_safe(cbentry, tmp, &cbdev->cb_entries,
+					 cb_list) {
+			if ((cbentry->line.cb_no == cbl.cb_no) &&
+			    (cbentry->line.int_no != cbl.int_no)) {
+				dev_warn(cbdev->dev,
+					 "%s irq already mapped to irq no %d",
+					 cbentry->line.dev_name,
+					 cbentry->line.int_no);
+				mutex_unlock(&cbdev->cb_lock);
+				return -EINVAL;
+			}
+			if ((cbentry->line.cb_no == cbl.cb_no) &&
+			    (cbentry->line.int_no == cbl.int_no)) {
+				mutex_unlock(&cbdev->cb_lock);
+				return 0;
+			}
+			if ((cbentry->line.int_no == cbl.int_no) &&
+			    (cbentry->line.cb_no != cbl.cb_no)) {
+				dev_warn(cbdev->dev,
+					 "%s irq replaced by %s irq\n",
+					 cbentry->line.dev_name,
+					 cbl.dev_name);
+				list_del(&(cbentry->cb_list));
+				break;
+			}
+		}
+
+		cbentry = devm_kzalloc(cbdev->dev, sizeof(struct cb_entry),
+								GFP_KERNEL);
+		cbentry->line = cbl;
+		list_add_tail(&(cbentry->cb_list), &cbdev->cb_entries);
+
+		regmap_read(cbdev->cb_regmap, cbl.offset, &val);
+
+		/* Print the replaced entry and map the new one */
+		dev_warn(cbdev->dev,
+			 "replacing irq %d mapped to cb input %d with cb input %d\n",
+			 cbl.int_no, val, cbl.cb_no);
+
+		regmap_write(cbdev->cb_regmap, cbl.offset, cbl.cb_no);
+		mutex_unlock(&cbdev->cb_lock);
+		return 0;
+	}
+
+	dev_warn(cbdev->dev, "crossbar device %s not found", cbl.cb_name);
+	return -ENODEV;
+}
+
+int crossbar_map(struct device_node *cbdev_node)
+{
+	const void *cbs;
+	unsigned size = 0, index = 0;
+	int err;
+
+	cbs = of_get_property(cbdev_node, "crossbar-lines", &size);
+	if (!cbs)
+		return -ENOENT;
+
+	while (index < size) {
+		struct cb_line tmp;
+
+		index += cb_entry_read(&tmp, cbs + index);
+
+		err = cb_map(tmp);
+		if (IS_ERR_VALUE(err))
+			return err;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL(crossbar_map);
+
+static int crossbar_probe(struct platform_device *pdev)
+{
+	struct cb_device *cbdev;
+	unsigned width;
+	struct device_node *cbdev_node = pdev->dev.of_node;
+	int err;
+	struct resource *res;
+
+	cbdev = devm_kzalloc(&pdev->dev, sizeof(struct cb_device), GFP_KERNEL);
+	if (!cbdev)
+		return -ENOMEM;
+
+	/* Get the device resources */
+	of_property_read_string(cbdev_node, "crossbar-name", &(cbdev->name));
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (res == NULL)
+		return -ENOENT;
+
+	cbdev->base = devm_ioremap_resource(&pdev->dev, res);
+	if (!cbdev->base)
+		return -ENOMEM;
+
+	cbdev->dev = &pdev->dev;
+
+	of_property_read_u32(cbdev_node, "reg-width", &width);
+
+	cb_regmap_config.val_bits = width;
+	cb_regmap_config.reg_stride = width >> 3;
+
+	cbdev->cb_regmap = devm_regmap_init_mmio(cbdev->dev, cbdev->base,
+						 &cb_regmap_config);
+
+	if (IS_ERR(cbdev->cb_regmap)) {
+		dev_err(&pdev->dev, "regmap init failed\n");
+		err = PTR_ERR(cbdev->cb_regmap);
+		return err;
+	}
+
+	platform_set_drvdata(pdev, cbdev);
+	list_add_tail(&cbdev->node, &cb_devlist);
+
+	/* INIT LIST HEAD */
+	INIT_LIST_HEAD(&cbdev->cb_entries);
+
+	mutex_init(&cbdev->cb_lock);
+
+	/* map the cross bar entries passed as default from DT */
+	err = crossbar_map(cbdev_node);
+
+	return err;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id crossbar_match[] = {
+	{.compatible = "crossbar", },
+	{},
+};
+#endif
+
+static struct platform_driver crossbar_driver = {
+	.probe		= crossbar_probe,
+	.driver		= {
+		.name		= "crossbar",
+		.owner		= THIS_MODULE,
+		.of_match_table = crossbar_match,
+	},
+};
+
+static int __init crossbar_init(void)
+{
+	return platform_driver_register(&crossbar_driver);
+}
+postcore_initcall(crossbar_init);
diff --git a/include/linux/crossbar.h b/include/linux/crossbar.h
new file mode 100644
index 0000000..27ca735
--- /dev/null
+++ b/include/linux/crossbar.h
@@ -0,0 +1,71 @@
+/*
+ * IRQ/DMA CROSSBAR DRIVER
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *	Sricharan <r.sricharan at ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ */
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
+#include <linux/list.h>
+#include <linux/err.h>
+#include <linux/gfp.h>
+#include <linux/platform_device.h>
+
+/*
+ * @base: base address of the crossbar device
+ * @dev:  device ptr
+ * @name: name of the crossbar device
+ * @node: list node for the crossbar devices linked list
+ * @cb_entries: list of entries that belong to the crossbar
+ * @cb_lock: mutex
+ * @regmap pointer
+ */
+struct cb_device {
+	void __iomem *base;
+	struct device *dev;
+	const char *name;
+	struct list_head node;
+	struct list_head cb_entries;
+	struct mutex cb_lock;
+	struct regmap *cb_regmap;
+};
+
+/*
+ * @cb_name: name of crossbar target to which this line is mapped
+ * @dev_name: mapped device input request name
+ * @cb_no: crossbar device input number
+ * @int_no: request number to which this input should be routed
+ * @offset: register offset address
+ */
+struct cb_line {
+	const char *cb_name;
+	const char *dev_name;
+	unsigned cb_no;
+	unsigned int_no;
+	unsigned offset;
+};
+
+struct cb_entry {
+	struct cb_line line;
+	struct list_head cb_list;
+};
+
+int crossbar_map(struct device_node *cbdev_node);
+int crossbar_unmap(struct device_node *cbdev_node, unsigned index);
-- 
1.7.9.5



From r.sricharan at ti.com  Thu Jul 18 12:43:49 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Thu, 18 Jul 2013 22:13:49 +0530
Subject: [PATCH 2/3] ARM: dts: DRA: Add crossbar device binding
In-Reply-To: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
Message-ID: <1374165830-6367-3-git-send-email-r.sricharan@ti.com>

This adds the irq/dma crossbar device nodes.

There is a IRQ and DMA crossbar device in the soc, which
maps the irq/dma requests from the peripherals to the
mpu/dsp/ipu/eve interrupt and sdma/edma controller's inputs.
The Peripheral irq/dma requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. On POR, there are some mappings which
are done by default. Those peripherals which do not have a
mapping on POR, should be configured to route its requests
using the crossbar control registers.

The irq/dma mapping for some peripherals are
added with the crossbar nodes here.

Signed-off-by: Sricharan R <r.sricharan at ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index a5d9350..e6208b4 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -85,6 +85,25 @@
 		ranges;
 		ti,hwmods = "l3_main_1", "l3_main_2";
 
+		crossbar_mpu: mpuirq at 4a002a48 {
+			compatible = "crossbar";
+			crossbar-name = "mpu-irq";
+			reg = <0x4a002a48 0x0130>;
+			reg-width = <16>;
+			crossbar-lines = "mpu-irq", "rtc-ss-alarm", <0x9f 0xd9 0x12c>,
+					 "mpu-irq", "mcasp3-arevt", <0x9e 0x96 0x12a>,
+					 "mpu-irq", "mcasp3-axevt", <0x9d 0x97 0x128>;
+		};
+
+		crossbar_dma: dmareq at 4a002b78 {
+			compatible = "crossbar";
+			crossbar-name = "dma-req";
+			reg = <0x4a002b78 0x0100>;
+			reg-width = <16>;
+			crossbar-lines = "dma-req", "mcasp3-rx", <0x7e 0x84 0xfc>,
+					 "dma-req", "mcasp3-tx", <0x7d 0x85 0xfa>;
+		};
+
 		counter32k: counter at 4ae04000 {
 			compatible = "ti,omap-counter32k";
 			reg = <0x4ae04000 0x40>;
-- 
1.7.9.5



From r.sricharan at ti.com  Thu Jul 18 12:43:50 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Thu, 18 Jul 2013 22:13:50 +0530
Subject: [PATCH 3/3] ARM: DRA7xx: Enable crossbar driver for the soc
In-Reply-To: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
Message-ID: <1374165830-6367-4-git-send-email-r.sricharan@ti.com>

Enable the crossbar driver to handle the irq/dma
crossbar devices in the soc.

Signed-off-by: Sricharan R <r.sricharan at ti.com>
---
 arch/arm/mach-omap2/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 80aaadc..3def350 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -120,6 +120,7 @@ config SOC_DRA7XX
 	select ARM_GIC
 	select HAVE_SMP
 	select COMMON_CLK
+	select CROSSBAR
 
 comment "OMAP Core Type"
 	depends on ARCH_OMAP2
-- 
1.7.9.5



From zonque at gmail.com  Thu Jul 18 12:47:10 2013
From: zonque at gmail.com (Daniel Mack)
Date: Thu, 18 Jul 2013 18:47:10 +0200
Subject: ARM: AM335x: Kernel oops when using EDMA and MMC
In-Reply-To: <51E81A7E.9030805@ti.com>
References: <51E6BE84.6080905@newflow.co.uk> <51E6C88B.8090608@ti.com>
 <51E81A7E.9030805@ti.com>
Message-ID: <51E81C0E.6070709@gmail.com>

Hi Balaji,

On 18.07.2013 18:40, Balaji T K wrote:
> With DMA channel info retrieved from dt binding on 3.11rc1,
> unused_chan_list is broken after hwmod cleanup removing mmc sdma
> resource info, hence pdev resource wont have DMA resource populated.
> 
> arch/arm/common/edma.c
> static int prepare_unused_channel_list(struct device *dev, void *data)
> {
> 	struct platform_device *pdev = to_platform_device(dev);
> 	int i, ctlr;
> 
> 	for (i = 0; i < pdev->num_resources; i++) {
> 		if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
> 				(int)pdev->resource[i].start >= 0) {
> 			ctlr = EDMA_CTLR(pdev->resource[i].start);
> 			clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
> 					edma_cc[ctlr]->edma_unused);
> 		}
> 	}
> 
> 	return 0;
> }
> 
> int edma_alloc_channel(int channel,
> 	if (!unused_chan_list_done) {
> 		/*
> 		 * Scan all the platform devices to find out the EDMA channels
> 		 * used and clear them in the unused list, making the rest
> 		 * available for ARM usage.
> 		 */
> 		ret = bus_for_each_dev(&platform_bus_type, NULL, NULL,
> 				prepare_unused_channel_list);
> 		if (ret < 0)
> 			return ret;
> 
> 		unused_chan_list_done = true;
> 	}
> 
> ===========
> 
> with the below hack patch, edma is working fine with mmc on your 3.11rc1+ branch
> 
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index a432e6c..5a19164 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -1262,8 +1262,8 @@ int edma_start(unsigned channel)
>   		if (test_bit(channel, edma_cc[ctlr]->edma_unused)) {
>   			pr_debug("EDMA: ESR%d %08x\n", j,
>   				edma_shadow0_read_array(ctlr, SH_ESR, j));
> -			edma_shadow0_write_array(ctlr, SH_ESR, j, mask);
> -			return 0;
> +//			edma_shadow0_write_array(ctlr, SH_ESR, j, mask);
> +//			return 0;
>   		}
> 
>   		/* EDMA channel with event association */
> 

Yes, this in fact works for me as well. Thanks for the quick reply! What
would be the proper fix for this?


Best,
Daniel




From joelf at ti.com  Thu Jul 18 12:46:39 2013
From: joelf at ti.com (Joel Fernandes)
Date: Thu, 18 Jul 2013 11:46:39 -0500
Subject: [PATCH 1/3] dmaengine: add dma_get_slave_sg_limits()
In-Reply-To: <1374166001-31340-1-git-send-email-joelf@ti.com>
References: <1374166001-31340-1-git-send-email-joelf@ti.com>
Message-ID: <1374166001-31340-2-git-send-email-joelf@ti.com>

From: Matt Porter <mporter at ti.com>

Add a dmaengine API to retrieve slave SG transfer limits.

The API is optionally implemented by dmaengine drivers and when
unimplemented will return a NULL pointer. A client driver using
this API provides the required dma channel, address width, and
burst size of the transfer. dma_get_slave_sg_limits() returns an
SG limits structure with the maximum number and size of SG segments
that the given channel can handle.

[Joel Fernandes <joelf at ti.com>: Changes to allocate limits
structure in client and fill up in DMAEngine implementation.]
Signed-off-by: Matt Porter <mporter at ti.com>
Signed-off-by: Joel Fernandes <joelf at ti.com>
Cc: Mark Jackson <mpfj-list at newflow.co.uk>
---
 include/linux/dmaengine.h |   45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 96d3e4a..2985878 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -371,6 +371,18 @@ struct dma_slave_config {
 	unsigned int slave_id;
 };
 
+/* struct dma_slave_sg_limits - expose SG transfer limits of a channel
+ *
+ * @max_seg_nr: maximum number of SG segments supported on a SG/SLAVE
+ *	    channel (0 for no maximum or not a SG/SLAVE channel)
+ * @max_seg_len: maximum length of SG segments supported on a SG/SLAVE
+ *	     channel (0 for no maximum or not a SG/SLAVE channel)
+ */
+struct dma_slave_sg_limits {
+	u32 max_seg_nr;
+	u32 max_seg_len;
+};
+
 static inline const char *dma_chan_name(struct dma_chan *chan)
 {
 	return dev_name(&chan->dev->device);
@@ -534,6 +546,7 @@ struct dma_tx_state {
  *	struct with auxiliary transfer status information, otherwise the call
  *	will just return a simple status code
  * @device_issue_pending: push pending transactions to hardware
+ * @device_slave_sg_limits: return the slave SG capabilities
  */
 struct dma_device {
 
@@ -602,6 +615,10 @@ struct dma_device {
 					    dma_cookie_t cookie,
 					    struct dma_tx_state *txstate);
 	void (*device_issue_pending)(struct dma_chan *chan);
+	int (*device_slave_sg_limits)(struct dma_chan *chan,
+		enum dma_slave_buswidth addr_width,
+		u32 maxburst,
+		struct dma_slave_sg_limits *sg_limits);
 };
 
 static inline int dmaengine_device_control(struct dma_chan *chan,
@@ -963,6 +980,34 @@ dma_set_tx_state(struct dma_tx_state *st, dma_cookie_t last, dma_cookie_t used,
 	}
 }
 
+/**
+ * dma_get_slave_sg_limits - get DMAC SG transfer capabilities
+ * @chan: target DMA channel
+ * @addr_width: address width of the DMA transfer
+ * @maxburst: maximum DMA transfer burst size
+ * @sg_limits: point to sg_limits struct to populate with limit info
+ *
+ * Get SG transfer capabilities for a specified channel. If the dmaengine
+ * driver does not implement SG transfer capabilities then NULL is
+ * returned.
+ */
+static inline int
+dma_get_slave_sg_limits(struct dma_chan *chan,
+		       enum dma_slave_buswidth addr_width,
+		       u32 maxburst,
+		       struct dma_slave_sg_limits *sg_limits)
+
+{
+
+	if (chan->device->device_slave_sg_limits && sg_limits)
+		return chan->device->device_slave_sg_limits(chan,
+							  addr_width,
+							  maxburst,
+							  sg_limits);
+
+	return -EINVAL;
+}
+
 enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
 #ifdef CONFIG_DMA_ENGINE
 enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
-- 
1.7.9.5



From joelf at ti.com  Thu Jul 18 12:46:40 2013
From: joelf at ti.com (Joel Fernandes)
Date: Thu, 18 Jul 2013 11:46:40 -0500
Subject: [PATCH 2/3] mmc: omap_hsmmc: set max_segs based on dma engine limits
In-Reply-To: <1374166001-31340-1-git-send-email-joelf@ti.com>
References: <1374166001-31340-1-git-send-email-joelf@ti.com>
Message-ID: <1374166001-31340-3-git-send-email-joelf@ti.com>

From: Matt Porter <mporter at ti.com>

The EDMA DMAC has a hardware limitation that prevents supporting
scatter gather lists with any number of segments. The DMA Engine
API reports the maximum number of segments a channel can support
via the optional dma_get_slave_sg_limits() API. If the max_nr_segs
limit is present, the value is used to configure mmc->max_segs
appropriately.

[Joel Fernandes <joelf at ti.com>: Allocate sg_limits structure in
client driver, and have the dmaengine implementation fill it up]
Signed-off-by: Matt Porter <mporter at ti.com>
Acked-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Joel Fernandes <joelf at ti.com>
Cc: Mark Jackson <mpfj-list at newflow.co.uk>
---
 drivers/mmc/host/omap_hsmmc.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index eccedc7..b723095 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1776,6 +1776,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
 	const struct of_device_id *match;
 	dma_cap_mask_t mask;
 	unsigned tx_req, rx_req;
+	struct dma_slave_sg_limits dma_sg_limits;
 	struct pinctrl *pinctrl;
 
 	match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev);
@@ -1952,6 +1953,14 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
 		goto err_irq;
 	}
 
+	/* Some DMA Engines only handle a limited number of SG segments */
+	ret = dma_get_slave_sg_limits(host->rx_chan,
+				DMA_SLAVE_BUSWIDTH_4_BYTES,
+				mmc->max_blk_size / 4,
+				&dma_sg_limits);
+	if (!ret && dma_sg_limits.max_seg_nr)
+		mmc->max_segs = dma_sg_limits.max_seg_nr;
+
 	/* Request IRQ for MMC operations */
 	ret = request_irq(host->irq, omap_hsmmc_irq, 0,
 			mmc_hostname(mmc), host);
-- 
1.7.9.5



From joelf at ti.com  Thu Jul 18 12:46:38 2013
From: joelf at ti.com (Joel Fernandes)
Date: Thu, 18 Jul 2013 11:46:38 -0500
Subject: [PATCH 0/3] Pending dmaengine patches
Message-ID: <1374166001-31340-1-git-send-email-joelf@ti.com>

I've reworked Matt's dmaegine sg_limits series addressing review comments at [1].

Currently MMC on AM33xx requires EDMA which was posted and accepted, following
it is a series that are fixes that have to go in for it to work correctly.
Without this series, DMA fails on MMC resulting in I/O errors.

A subsequent MMC DT patch for AM33xx is also on hold [2] for the same reason.

Tested on AM335x (Beaglebone Rev A5A).

[1] http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2013-March/026658.html
[2] http://lkml.indiana.edu/hypermail/linux/kernel/1306.3/03766.html

Matt Porter (3):
  dmaengine: add dma_get_slave_sg_limits()
  mmc: omap_hsmmc: set max_segs based on dma engine limits
  dma: edma: add device_slave_sg_limits() support

 drivers/dma/edma.c            |   14 +++++++++++++
 drivers/mmc/host/omap_hsmmc.c |    9 +++++++++
 include/linux/dmaengine.h     |   45 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 68 insertions(+)

-- 
1.7.9.5



From joelf at ti.com  Thu Jul 18 12:46:41 2013
From: joelf at ti.com (Joel Fernandes)
Date: Thu, 18 Jul 2013 11:46:41 -0500
Subject: [PATCH 3/3] dma: edma: add device_slave_sg_limits() support
In-Reply-To: <1374166001-31340-1-git-send-email-joelf@ti.com>
References: <1374166001-31340-1-git-send-email-joelf@ti.com>
Message-ID: <1374166001-31340-4-git-send-email-joelf@ti.com>

From: Matt Porter <mporter at ti.com>

Implement device_slave_sg_limits().

EDMA has a finite set of PaRAM slots available for linking a
multi-segment SG transfer. In order to prevent any one channel
from consuming all PaRAM slots to fulfill a large SG transfer,
the driver reports a static per-channel max number of SG segments
it will handle.

The maximum size of an SG segment is limited by the addr_width
and maxburst of a given transfer request. These values are
provided by the client driver and used to calculate and return
the maximum segment length.

[Joel Fernandes <joelf at ti.com>: Changes for filling sg_limits
by DMAEngine implementation and allocating in client, channel
parameter is unused in this implementation as all channels
have the same capability]
Signed-off-by: Matt Porter <mporter at ti.com>
Signed-off-by: Joel Fernandes <joelf at ti.com>
Cc: Mark Jackson <mpfj-list at newflow.co.uk>
---
 drivers/dma/edma.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 5f3e532..964de26 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -462,6 +462,19 @@ static void edma_issue_pending(struct dma_chan *chan)
 	spin_unlock_irqrestore(&echan->vchan.lock, flags);
 }
 
+static inline int edma_get_slave_sg_limits(struct dma_chan *chan,
+		       enum dma_slave_buswidth addr_width,
+		       u32 maxburst,
+		       struct dma_slave_sg_limits *sg_limits)
+{
+	if (!sg_limits)
+		return -EINVAL;
+	sg_limits->max_seg_nr = MAX_NR_SG;
+	sg_limits->max_seg_len =
+		(SZ_64K - 1) * addr_width * maxburst;
+	return 0;
+}
+
 static size_t edma_desc_size(struct edma_desc *edesc)
 {
 	int i;
@@ -537,6 +550,7 @@ static void edma_dma_init(struct edma_cc *ecc, struct dma_device *dma,
 	dma->device_alloc_chan_resources = edma_alloc_chan_resources;
 	dma->device_free_chan_resources = edma_free_chan_resources;
 	dma->device_issue_pending = edma_issue_pending;
+	dma->device_slave_sg_limits = edma_get_slave_sg_limits;
 	dma->device_tx_status = edma_tx_status;
 	dma->device_control = edma_control;
 	dma->dev = dev;
-- 
1.7.9.5



From linux at arm.linux.org.uk  Thu Jul 18 12:50:07 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Jul 2013 17:50:07 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabled
In-Reply-To: <51E81B39.2030805@linaro.org>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
 <20130717151148.GM24642@n2100.arm.linux.org.uk> <51E81B39.2030805@linaro.org>
Message-ID: <20130718165007.GA24642@n2100.arm.linux.org.uk>

On Thu, Jul 18, 2013 at 05:43:37PM +0100, Julien Grall wrote:
> When Xen will boot, it will use one UART, given by the user, to be able
> to log its information. Xen will not map the UART region and the IRQ to
> dom0. Of course it will not be present in the device tree either. So if
> Linux tries to access to this memory region, it will crash.
> 
> When Linux will boot as dom0, it will either use an hvc console or
> another UART.
> 
> In case of multi-platform environments, there is no issue because when
> CONFIG_DEBUG_UNCOMPRESS is disabled.
> 
> Now, in non-multiplatform environment, the decompressor will use a
> pre-defined UART. This UART may be already used by Xen and Linux will
> abort at the first access.
> 
> I think, the decompressor should be able to detect if the UART exists
> (I'm not sure it's possible) or disabled at compile time uncompress log.
> 
> Do you have any better ideas?

Let me get this straight.

1. You want to run an _existing_ platforms kernel under Xen, where the
   platform assumes that it has various devices at various locations,
   and will make direct accesses to those devices.

2. You don't want to provide some of those devices, and you arrange for
   those unprovided devices to fault.

Excuse me if I think that's really silly.

Lastly, aren't all ARMv7 kernels (therefore Xen supporting kernels)
supposed to be part of the multiplatform kernel stuff now?


From joe at perches.com  Thu Jul 18 12:55:18 2013
From: joe at perches.com (Joe Perches)
Date: Thu, 18 Jul 2013 09:55:18 -0700
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
Message-ID: <1374166518.1949.122.camel@joe-AO722>

On Thu, 2013-07-18 at 22:13 +0530, Sricharan R wrote:
> Some socs have a large number of interrupts/dma requests to service
> the needs of its many peripherals and subsystems. All of the
> requests lines from the subsystems are not needed at the same
> time, so they have to be muxed to the controllers appropriately.
> In such places a interrupt/dma controllers are preceded by an
> IRQ/DMA CROSSBAR that provides flexibility in muxing the device
> requests to the controller inputs.
[]
> diff --git a/drivers/misc/crossbar.c b/drivers/misc/crossbar.c
[]
> +int crossbar_unmap(struct device_node *cbdev_node, unsigned index)
[]
> +	list_for_each_entry(cbdev, &cb_devlist, node) {
> +		if (strcmp(cbdev->name, tmp.cb_name))
> +			continue;
[]
> +				dev_warn(cbdev->dev,
> +					 "unmapped int_no %x mapped to cb %x\n",
> +					 tmp.int_no, tmp.cb_no);
> +				return 0;
[]
> +	dev_warn(cbdev->dev, "%s cb entry %d not found\n",
> +		 __func__, tmp.cb_no);
> +	return -ENOENT;

Why does this function always emit a dev_warn
before return?  Maybe the first should be dev_info?




From swarren at wwwdotorg.org  Thu Jul 18 12:55:56 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 10:55:56 -0600
Subject: [PATCH v2 0/4] Add PWM polarity flag macro for DT
In-Reply-To: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <51E81E1C.20708@wwwdotorg.org>

On 07/17/2013 04:54 PM, Laurent Pinchart wrote:
> Hello,
> 
> Here's a small patch set that replaces PWM polarity numerical constants with
> macros in DT.

The series,
Reviewed-by: Stephen Warren <swarren at nvidia.com>

I'm (very very) slightly hesitant about patch 3/4, since it's moving
towards all PWMs having to use the same specifier format, whereas
specifiers are at least potentially binding-specific, not
device-type-specific. However, consistency is good; there's no need to
do something different just for the heck of it. Equally, there's nothing
actually stopping a new binding from defining its own format rather than
simply deferring to pwm.txt if it absolutely has to, so I think this
will turn out fine.


From vinod.koul at intel.com  Thu Jul 18 12:16:58 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Thu, 18 Jul 2013 21:46:58 +0530
Subject: [PATCH 1/3] dmaengine: add dma_get_slave_sg_limits()
In-Reply-To: <1374166001-31340-2-git-send-email-joelf@ti.com>
References: <1374166001-31340-1-git-send-email-joelf@ti.com>
 <1374166001-31340-2-git-send-email-joelf@ti.com>
Message-ID: <20130718161658.GW16653@intel.com>

On Thu, Jul 18, 2013 at 11:46:39AM -0500, Joel Fernandes wrote:
> From: Matt Porter <mporter at ti.com>
> 
> Add a dmaengine API to retrieve slave SG transfer limits.
> 
> The API is optionally implemented by dmaengine drivers and when
> unimplemented will return a NULL pointer. A client driver using
> this API provides the required dma channel, address width, and
> burst size of the transfer. dma_get_slave_sg_limits() returns an
> SG limits structure with the maximum number and size of SG segments
> that the given channel can handle.
Hi Joel,

I have already resurrected this and generalized the API to get the slave
capablities. 
https://lkml.org/lkml/2013/7/15/147

Please start using this API

~Vinod


From swarren at wwwdotorg.org  Thu Jul 18 12:58:46 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 10:58:46 -0600
Subject: [PATCH] ASoC: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
In-Reply-To: <20130718095815.GE22506@sirena.org.uk>
References: <1374013667-21435-1-git-send-email-swarren@wwwdotorg.org>
 <20130717083003.GA22506@sirena.org.uk> <51E6CDEA.7060003@wwwdotorg.org>
 <20130717175701.GY22506@sirena.org.uk> <51E6E107.8020300@wwwdotorg.org>
 <20130717223309.GZ22506@sirena.org.uk> <51E7203A.2020007@wwwdotorg.org>
 <20130718095815.GE22506@sirena.org.uk>
Message-ID: <51E81EC6.2040802@wwwdotorg.org>

On 07/18/2013 03:58 AM, Mark Brown wrote:
> On Wed, Jul 17, 2013 at 04:52:42PM -0600, Stephen Warren wrote:
> 
>> The key to enable tegra30_i2s.c should really be
>> ARCH_TEGRA_3x_SOC || ARCH_TEGRA_114_SOC, which gets a bit
>> unwieldy once you have, say, 4 different SoCs in that list and a
>> similar list starts to apply to a lot of different
>> HW-modules/drivers. Even creating an ARCH_TEGRA_30_OR_LATER_SOC
>> will get problematic, since defining "or later" will likely
>> become progressively more complex over time, as we start putting
>> our more SoCs. What are your thoughts on the best way to solve
>> that?
> 
> Can't you just say Tegra 20 or later is Tegra 20 plus Tegra 30 or
> later and so on?

For the chips that are supported upstream right now, that would work.
However, I'm not sure that life will be quite so linear in the future.
In other words, what is "or later" for, say, the SDHCI controller may
not be the same as what is "or later" for, say, the I2C controller.
(feel free to substitute arbitrary HW modules into that statement).


From swarren at wwwdotorg.org  Thu Jul 18 13:00:09 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 11:00:09 -0600
Subject: [PATCH] memory: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
In-Reply-To: <1374013147-4775-1-git-send-email-swarren@wwwdotorg.org>
References: <1374013147-4775-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <51E81F19.2070402@wwwdotorg.org>

On 07/16/2013 04:19 PM, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> I'm planning to remove CONFIG_ARCH_TEGRA_*_SOC, leaving just ARCH_TEGRA.
> This will reduce the number of configurations that need to be supported
> by core Tegra code, e.g. CPU idle, hotplug. As a precursor, we need to
> update Kconfig for all Tegra drivers not to reference ARCH_TEGRA_*_SOC.

I'd like to defer actually applying this patch. There is some discussion
(in the thread for the equivalent ASoC patches) re: the best way to
handle the ARCH_TEGRA_*_SOC Kconfig options which might affect this
patch. Any review comment is still appreciated.



From swarren at wwwdotorg.org  Thu Jul 18 13:00:19 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 11:00:19 -0600
Subject: [PATCH] iommu: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
In-Reply-To: <1374013222-4856-1-git-send-email-swarren@wwwdotorg.org>
References: <1374013222-4856-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <51E81F23.40807@wwwdotorg.org>

On 07/16/2013 04:20 PM, Stephen Warren wrote:
> I'm planning to remove CONFIG_ARCH_TEGRA_*_SOC, leaving just ARCH_TEGRA.
> This will reduce the number of configurations that need to be supported
> by core Tegra code, e.g. CPU idle, hotplug. As a precursor, we need to
> update Kconfig for all Tegra drivers not to reference ARCH_TEGRA_*_SOC.

I'd like to defer actually applying this patch. There is some discussion
(in the thread for the equivalent ASoC patches) re: the best way to
handle the ARCH_TEGRA_*_SOC Kconfig options which might affect this
patch. Any review comment is still appreciated.


From joelf at ti.com  Thu Jul 18 13:00:15 2013
From: joelf at ti.com (Joel Fernandes)
Date: Thu, 18 Jul 2013 12:00:15 -0500
Subject: ARM: AM335x: Kernel oops when using EDMA and MMC
In-Reply-To: <51E81A7E.9030805@ti.com>
References: <51E6BE84.6080905@newflow.co.uk> <51E6C88B.8090608@ti.com>
 <51E81A7E.9030805@ti.com>
Message-ID: <51E81F1F.50407@ti.com>

Hi Balaji,

On 07/18/2013 11:40 AM, Balaji T K wrote:
> On Wednesday 17 July 2013 10:08 PM, Joel Fernandes wrote:
>> On 07/17/2013 10:55 AM, Mark Jackson wrote:
>>> I'm trying to get the MMC port working on our custom AM3352 CPU board.
>>>
>>> I have added MMC entries to out dts file (similar to [1]), and I've
>>> enabled CONFIG_TI_EDMA.
>>>
>>> Our board boots fine without an SD card inserted ...
>>>
>>> [    0.000000] Booting Linux on physical CPU 0x0
>>> [    0.000000] Linux version 3.11.0-rc1-00025-g95b9b72
>>> (mpfj at mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) )
>>> #309 Wed Jul 17 16:37:28 BST 2013
>>> ...
>>> [    2.789028] VFS: Mounted root (ubifs filesystem) on device 0:12.
>>> [    2.797268] devtmpfs: mounted
>>> [    2.801032] Freeing unused kernel memory: 200K (c0551000 - c0583000)
>>> ...
>>> Welcome to Buildroot
>>> nanobone login:
>>>
>>> But when I boot with a card already inserted, I get the following
>>> oops ...
>>>
>>> ...
>>> [    1.827343] Unable to handle kernel NULL pointer dereference at
>>> virtual address 0000000c
>>> [    1.835868] pgd = c0004000
>>> [    1.838774] [0000000c] *pgd=00000000
>>> [    1.842556] Internal error: Oops: 5 [#1] ARM
>>> [    1.847063] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted
>>> 3.11.0-rc1-00025-g95b9b72 #309
>>> [    1.855511] Workqueue: kmmcd mmc_rescan
>>> [    1.859556] task: cf06a080 ti: cf072000 task.ti: cf072000
>>> [    1.865257] PC is at omap_hsmmc_start_command+0x74/0xf4
>>> [    1.870761] LR is at omap_hsmmc_request+0xec/0x4dc
>>> [    1.875806] pc : [<c0305b70>]    lr : [<c0306c64>]    psr: 60000113
>>> [    1.875806] sp : cf073ca0  ip : 00000000  fp : 00000008
>>> [    1.887885] r10: cf073de8  r9 : 00000001  r8 : cf11d918
>>> [    1.893382] r7 : 00000003  r6 : cf33cc80  r5 : 00000001  r4 :
>>> 00000033
>>> [    1.900250] r3 : 00020000  r2 : cf073db8  r1 : cf073d84  r0 :
>>> cf33cc80
>>> [    1.907122] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM 
>>> Segment kernel
>>> [    1.914813] Control: 10c5387d  Table: 80004019  DAC: 00000015
>>> [    1.920859] Process kworker/u2:0 (pid: 6, stack limit = 0xcf072238)
>>> [    1.927454] Stack: (0xcf073ca0 to 0xcf074000)
>>> [    1.932048] 3ca0: cf33c800 cf073d40 00000003 00000000 c0076a8c
>>> cf073d40 48060220 48060220
>>> [    1.940659] 3cc0: 00000004 00000004 00000002 00000002 cf073ec8
>>> c0421a9c c051835c cf073d40
>>> [    1.949271] 3ce0: cf33c800 00000001 00000008 00000008 00000002
>>> cf073db8 cf073ec8 c02f0f28
>>> [    1.957882] 3d00: 00000200 00000064 00000000 cf073db8 cf073ec8
>>> cf073d40 cf073d50 00000000
>>> [    1.966493] 3d20: cf33c800 c02f18a4 cf369800 cf369a80 00000000
>>> cf360880 00000008 c02f9964
>>> [    1.975104] 3d40: 00000000 cf073d84 cf073db8 00000000 00000001
>>> 00000001 dead4ead ffffffff
>>> [    1.983717] 3d60: ffffffff c0af722c c06aa3e4 00000000 c04ddadc
>>> cf073d74 cf073d74 c02f0dc4
>>> [    1.992327] 3d80: 00000000 00000033 00000000 00000000 00000000
>>> 00000000 00000000 000000b5
>>> [    2.000938] 3da0: 00000000 00000000 00000000 00000000 cf073db8
>>> cf073d40 05f5e100 00000000
>>> [    2.009548] 3dc0: 00000008 00000001 00000000 00000200 00000000
>>> 00000000 cf073d40 00000001
>>> [    2.018159] 3de0: cf073de8 00000000 c0cf1c02 00000880 00000008
>>> 8f360880 00000000 cf369800
>>> [    2.026771] 3e00: cf33c800 00000000 cf369800 cf073e4c cf072000
>>> c02f8740 00000000 00000015
>>> [    2.035382] 3e20: 00000003 cf33c800 00000000 00000000 cf369800
>>> cf073e4c cf072000 c02f8b20
>>> [    2.043994] 3e40: 00000002 c02f25cc 00000002 02544d53 41303447
>>> 1026c914 2600bbbd c0ff8000
>>> [    2.052605] 3e60: c0455884 cf33c800 00000000 c0455884 c0455890
>>> 00000000 cf072000 c02f92bc
>>> [    2.061217] 3e80: c0455890 00ff8000 00000002 cf33cb14 cf33c800
>>> c02f3a28 cf041ac0 cf33cb14
>>> [    2.069829] 3ea0: cf050c00 cf051c00 00000000 c00507ec 00000002
>>> 00000000 c0050778 c0050f10
>>> [    2.078441] 3ec0: 00000000 00000000 c0af7268 c06aa1c4 00000000
>>> c0518cd0 cf06a080 cf041ac0
>>> [    2.087054] 3ee0: cf050c00 cf072000 cf050c30 cf041ad8 00000089
>>> c05d7b5c cf050c00 c0050e4c
>>> [    2.095665] 3f00: 00000000 cf072000 60000113 cf04dda8 00000000
>>> cf041ac0 c0050d08 00000000
>>> [    2.104276] 3f20: 00000000 00000000 00000000 c0056c94 c0429a18
>>> 00000000 00000001 cf041ac0
>>> [    2.112888] 3f40: 00000000 00000001 dead4ead ffffffff ffffffff
>>> c05ec0a0 00000000 00000000
>>> [    2.121499] 3f60: c04ddadc cf073f64 cf073f64 00000000 00000001
>>> dead4ead ffffffff ffffffff
>>> [    2.130112] 3f80: c05ec0a0 00000000 00000000 c04ddadc cf073f90
>>> cf073f90 cf073fac cf04dda8
>>> [    2.138724] 3fa0: c0056bf0 00000000 00000000 c0013588 00000000
>>> 00000000 00000000 00000000
>>> [    2.147334] 3fc0: 00000000 00000000 00000000 00000000 00000000
>>> 00000000 00000000 00000000
>>> [    2.155946] 3fe0: 00000000 00000000 00000000 00000000 00000013
>>> 00000000 57e0c5db 5ffb7d3c
>>> [    2.164565] [<c0305b70>] (omap_hsmmc_start_command+0x74/0xf4) from
>>> [<00000003>] (0x3)
>>> [    2.172814] Code: 13a03801 0a00001b e590c008 e5914000 (e59cc00c)
>>> [    2.179314] ---[ end trace 6ec9899a56aef6aa ]---
>>>
>>> I have also noticed that when the kernel boots okay (without a card
>>> inserted), if
>>> I then insert a card, nothing happens (even with CONFIG_MMC_DEBUG=y)
>>> ... including
>>> no kernel oops.
>>>
>>> Can anyone shed light on what's wrong ?
>>
>> I see this issue too on -rc1. The mmc host pointer is mangled but this
>> could be
>> due to something totally unrelated.
>>
> Hi Joel,
> 
> With DMA channel info retrieved from dt binding on 3.11rc1,
> unused_chan_list is broken after hwmod cleanup removing mmc sdma
> resource info, hence pdev resource wont have DMA resource populated.

Thanks for letting me know. I will try to populate the unused channel
list differently and will post a patch.

Regards,

-Joel


From swarren at wwwdotorg.org  Thu Jul 18 13:00:29 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 11:00:29 -0600
Subject: [PATCH] clk: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
In-Reply-To: <1374014039-22469-1-git-send-email-swarren@wwwdotorg.org>
References: <1374014039-22469-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <51E81F2D.6060405@wwwdotorg.org>

On 07/16/2013 04:33 PM, Stephen Warren wrote:
> I'm planning to remove CONFIG_ARCH_TEGRA_*_SOC, leaving just ARCH_TEGRA.
> This will reduce the number of configurations that need to be supported
> by core Tegra code, e.g. CPU idle, hotplug. As a precursor, we need to
> update Kconfig for all Tegra drivers not to reference ARCH_TEGRA_*_SOC.
> 
> The Tegra clock driver contains a fairly large amount of SoC-specific
> code and data. Introduce explicit config options so that the user can
> trim the set of supported SoCs if they wish. Default these to on, since
> most people will probably want to enable support for all SoCs. This also
> avoids the need to change any defconfig files.

I'd like to defer actually applying this patch. There is some discussion
(in the thread for the equivalent ASoC patches) re: the best way to
handle the ARCH_TEGRA_*_SOC Kconfig options which might affect this
patch. Any review comment is still appreciated.




From swarren at wwwdotorg.org  Thu Jul 18 13:00:38 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 11:00:38 -0600
Subject: [PATCH] pinctrl: tegra: expose config options for individual SoCs
In-Reply-To: <1374014077-22536-1-git-send-email-swarren@wwwdotorg.org>
References: <1374014077-22536-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <51E81F36.3030802@wwwdotorg.org>

On 07/16/2013 04:34 PM, Stephen Warren wrote:
> I'm planning to remove CONFIG_ARCH_TEGRA_*_SOC, leaving just ARCH_TEGRA.
> This will reduce the number of configurations that need to be supported
> by core Tegra code, e.g. CPU idle, hotplug. As a precursor, we need to
> update Kconfig for all Tegra drivers not to reference ARCH_TEGRA_*_SOC.
> 
> The Tegra pinctrl driver contains a fairly large amount of SoC-specific
> code and data. Introduce explicit config options so that the user can
> trim the set of supported SoCs if they wish. Default these to on, since
> most people will probably want to enable support for all SoCs. This also
> avoids the need to change any defconfig files.

I'd like to defer actually applying this patch. There is some discussion
(in the thread for the equivalent ASoC patches) re: the best way to
handle the ARCH_TEGRA_*_SOC Kconfig options which might affect this
patch. Any review comment is still appreciated.



From gsi at denx.de  Thu Jul 18 13:00:31 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:31 +0200
Subject: [PATCH v2 00/24] add COMMON_CLK support for PowerPC MPC512x
In-Reply-To: <1373914074-20889-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-1-git-send-email-gsi@denx.de>

this series introduces support for the common clock framework (CCF,
COMMON_CLK Kconfig option) in the PowerPC based MPC512x platform

although the series does touch several subsystems -- serial, spi, net
(can, fs_enet), mtd (nfc), usb, i2c, media (viu), and dts -- all of the
patches are strictly clock related

it appears most appropriate to take this series through either the clk
or the powerpc trees after it has passed review and other subsystem
maintainers ACKed the clock setup related driver modifications

the series passes 'checkpatch.pl --strict' except for one warning which
cannot get resolved, since that either breaks compilation (the data type
is preset by the clk-provider.h API) or requires a cast which shadows
real mismatches:

  WARNING: static const char * array should probably be static const char * const
  #413: FILE: arch/powerpc/platforms/512x/clock-commonclk.c:335:
  +static const char *parent_names_mux0[] = {

  total: 0 errors, 1 warnings, 0 checks, 836 lines checked

each step in the series was build and run tested (with a display that is
attached to the DIU as well as SPI, with an SPI attached NOR flash, with
multiple UART ports such that one is not the boot console, with EEPROMs
attached to I2C, with an SD card, booting from network)


changes in v2:
- cleanup of the UART and SPI clock handling before the introduction of
  common clock support for the platform, as incomplete clock handling
  becomes fatal or more dangerous later (which in turn changes the
  context of the "device tree lookup only" followup patch later)
- reordered the sequence of patches to keep the serial communication
  related parts together (UART, SPI, and PSC FIFO changes after common
  clock support was introduced)
- updated commit messages for the clock API use cleanup in the serial
  communication drivers, updated comments and reworded commit messages
  in the core clock driver to expand on the pre-enable workaround and
  clkdev registration
- keep a reference to the PSC FIFO clock during use instead of looking
  up the clock again in the uninit() routine
- remove the clkdev.h header file inclusion directive with the removal
  of the clkdev registration call


Gerhard Sittig (24):
  spi: mpc512x: cleanup clock API use
  serial: mpc512x: cleanup clock API use
  mtd: mpc5121_nfc: prepare clocks before enabling them
  powerpc: mpc512x: array decl for MCLK registers in CCM
  clk: wrap I/O access for improved portability
  dts: mpc512x: prepare for preprocessor support
  dts: mpc512x: introduce dt-bindings/clock/ header
  dts: mpc512x: add clock related device tree specs
  clk: mpc512x: introduce COMMON_CLK for MPC512x
  dts: mpc512x: add clock specs for client lookups
  spi: mpc512x: remove now obsolete clock lookup name
  serial: mpc512x: remove now obsolete clock lookup name
  clk: mpc512x: remove now obsolete clkdev registration
  serial: mpc512x: setup the PSC FIFO clock as well
  net: can: mscan: add a comment on reg to idx mapping
  net: can: mscan: make mpc512x code use common clock
  powerpc/mpc512x: improve DIU related clock setup
  i2c: mpc: OF clock lookup for MPC512x
  USB: fsl-mph-dr-of: OF clock lookup, prepare and enable
  fs_enet: OF clock lookup (non-fatal), prepare and enable
  [media] fsl-viu: OF clock lookup, prepare before enable
  powerpc/fsl-pci: OF clock lookup, prepare before enable
  clk: mpc512x: switch to COMMON_CLK, remove PPC_CLOCK
  net: can: mscan: remove MPC512x non-COMMON_CLK code path

 arch/powerpc/boot/dts/ac14xx.dts                   |    9 +-
 arch/powerpc/boot/dts/include/dt-bindings          |    1 +
 arch/powerpc/boot/dts/mpc5121.dtsi                 |   94 ++-
 arch/powerpc/boot/dts/mpc5121ads.dts               |    2 +-
 arch/powerpc/boot/dts/pdm360ng.dts                 |    2 +-
 arch/powerpc/include/asm/mpc5121.h                 |   18 +-
 arch/powerpc/platforms/512x/Kconfig                |    2 +-
 arch/powerpc/platforms/512x/Makefile               |    3 +-
 arch/powerpc/platforms/512x/clock-commonclk.c      |  761 ++++++++++++++++++++
 arch/powerpc/platforms/512x/clock.c                |  753 -------------------
 arch/powerpc/platforms/512x/mpc512x_shared.c       |  165 +++--
 arch/powerpc/sysdev/fsl_pci.c                      |   15 +
 drivers/clk/clk-divider.c                          |    6 +-
 drivers/clk/clk-gate.c                             |    6 +-
 drivers/clk/clk-mux.c                              |    6 +-
 drivers/i2c/busses/i2c-mpc.c                       |    9 +
 drivers/media/platform/fsl-viu.c                   |   12 +-
 drivers/mtd/nand/mpc5121_nfc.c                     |    4 +-
 drivers/net/can/mscan/mpc5xxx_can.c                |  234 +++---
 .../net/ethernet/freescale/fs_enet/fs_enet-main.c  |   27 +-
 drivers/spi/spi-mpc512x-psc.c                      |   45 +-
 drivers/tty/serial/mpc52xx_uart.c                  |  137 +++-
 drivers/usb/host/fsl-mph-dr-of.c                   |   24 +-
 include/dt-bindings/clock/mpc512x-clock.h          |   59 ++
 include/linux/clk-provider.h                       |   33 +
 include/linux/fs_enet_pd.h                         |    3 +
 26 files changed, 1392 insertions(+), 1038 deletions(-)
 create mode 120000 arch/powerpc/boot/dts/include/dt-bindings
 create mode 100644 arch/powerpc/platforms/512x/clock-commonclk.c
 delete mode 100644 arch/powerpc/platforms/512x/clock.c
 create mode 100644 include/dt-bindings/clock/mpc512x-clock.h


# uname -srm
Linux 3.11.0-rc1-00024-g96ff9fe ppc
# cat /sys/kernel/debug/clk/clk_summary
   clock                        enable_cnt  prepare_cnt  rate
---------------------------------------------------------------------
 ac97                           0           0            24567000
 spdif_rx_in                    0           0            0
 spdif_tx_in                    0           0            0
 psc_mclk_in                    0           0            25000000
 dummy                          1           1            0
 osc                            1           1            25000000
    ref                         1           1            25000000
       sys                      10          10           320000000
          spdif-mux0            0           0            320000000
             spdif-en0          0           0            320000000
                spdif_mclk_div  0           0            80000000
                   spdif_mclk_out 0           0            80000000
                      spdif_mclk 0           0            80000000
          mscan3-mux0           1           1            320000000
             mscan3-en0         1           1            320000000
                mscan3_mclk_div 1           1            80000000
                   mscan3_mclk_out 1           1            80000000
                      mscan3_mclk 1           1            80000000
          mscan2-mux0           1           1            320000000
             mscan2-en0         1           1            320000000
                mscan2_mclk_div 1           1            80000000
                   mscan2_mclk_out 1           1            80000000
                      mscan2_mclk 1           1            80000000
          mscan1-mux0           1           1            320000000
             mscan1-en0         1           1            320000000
                mscan1_mclk_div 1           1            16000000
                   mscan1_mclk_out 1           1            16000000
                      mscan1_mclk 2           2            16000000
          mscan0-mux0           1           1            320000000
             mscan0-en0         1           1            320000000
                mscan0_mclk_div 1           1            16000000
                   mscan0_mclk_out 1           1            16000000
                      mscan0_mclk 2           2            16000000
          psc11-mux0            0           0            320000000
             psc11-en0          0           0            320000000
                psc11_mclk_div  0           0            80000000
                   psc11_mclk_out 0           0            80000000
                      psc11_mclk 0           0            80000000
          psc10-mux0            0           0            320000000
             psc10-en0          0           0            320000000
                psc10_mclk_div  0           0            80000000
                   psc10_mclk_out 0           0            80000000
                      psc10_mclk 0           0            80000000
          psc9-mux0             0           0            320000000
             psc9-en0           0           0            320000000
                psc9_mclk_div   0           0            80000000
                   psc9_mclk_out 0           0            80000000
                      psc9_mclk 0           0            80000000
          psc8-mux0             0           0            320000000
             psc8-en0           0           0            320000000
                psc8_mclk_div   0           0            80000000
                   psc8_mclk_out 0           0            80000000
                      psc8_mclk 0           0            80000000
          psc7-mux0             1           1            320000000
             psc7-en0           1           1            320000000
                psc7_mclk_div   1           1            80000000
                   psc7_mclk_out 1           1            80000000
                      psc7_mclk 1           1            80000000
          psc6-mux0             0           0            320000000
             psc6-en0           0           0            320000000
                psc6_mclk_div   0           0            80000000
                   psc6_mclk_out 0           0            80000000
                      psc6_mclk 0           0            80000000
          psc5-mux0             1           1            320000000
             psc5-en0           1           1            320000000
                psc5_mclk_div   1           1            80000000
                   psc5_mclk_out 1           1            80000000
                      psc5_mclk 1           1            80000000
          psc4-mux0             1           1            320000000
             psc4-en0           1           1            320000000
                psc4_mclk_div   1           1            80000000
                   psc4_mclk_out 1           1            80000000
                      psc4_mclk 1           1            80000000
          psc3-mux0             1           1            320000000
             psc3-en0           1           1            320000000
                psc3_mclk_div   1           1            80000000
                   psc3_mclk_out 1           1            80000000
                      psc3_mclk 2           2            80000000
          psc2-mux0             0           0            320000000
             psc2-en0           0           0            320000000
                psc2_mclk_div   0           0            80000000
                   psc2_mclk_out 0           0            80000000
                      psc2_mclk 0           0            80000000
          psc1-mux0             0           0            320000000
             psc1-en0           0           0            320000000
                psc1_mclk_div   0           0            80000000
                   psc1_mclk_out 0           0            80000000
                      psc1_mclk 0           0            80000000
          psc0-mux0             0           0            320000000
             psc0-en0           0           0            320000000
                psc0_mclk_div   0           0            80000000
                   psc0_mclk_out 0           0            80000000
                      psc0_mclk 0           0            80000000
          ddr-ug                1           1            160000000
             ddr                1           1            160000000
          csb                   4           4            160000000
             viu                0           0            160000000
             iim                0           0            160000000
             usb2               0           0            160000000
             usb1               0           0            160000000
             axe                0           0            160000000
             pci-ug             0           0            26666666
                pci             0           0            26666666
             mbx-bus-ug         0           0            80000000
                mbx-bus         0           0            80000000
                mbx-ug          0           0            80000000
                   mbx          0           0            80000000
                   mbx-3d-ug    0           0            80000000
                      mbx-3d    0           0            80000000
             e300               1           1            400000000
             diu-x4             1           1            640000000
                diu-ug          1           1            2509803
                   diu          2           2            2509803
             sdhc-x4            1           1            640000000
                sdhc-ug         1           1            53333333
                   sdhc-2       0           0            53333333
                   sdhc         1           1            53333333
             ips                7           7            80000000
                i2c             3           3            80000000
                mem             1           1            80000000
                fec             1           1            80000000
                sata            0           0            80000000
                psc-fifo        1           1            80000000
                pata            0           0            80000000
                lpc-ug          1           1            40000000
                   lpc          1           1            40000000
                nfc-ug          0           0            40000000
                   nfc          0           0            40000000

-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 13:00:33 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:33 +0200
Subject: [PATCH v2 02/24] serial: mpc512x: cleanup clock API use
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-3-git-send-email-gsi@denx.de>

cleanup the clock API use of the UART driver which is shared among the
MPC512x and the MPC5200 platforms
- get, prepare, and enable the MCLK during port allocation; disable,
  unprepare and put the MCLK upon port release; hold a reference to the
  clock over the period of use; check for and propagate enable errors
- fix a buffer overflow for clock names with two digit PSC index numbers
- stick with the PPC_CLOCK 'psc%d_mclk' name for clock lookup, only
  switch to a fixed string later after device tree based clock lookup
  will have become available

the omission in the clock handling previously went unnoticed, but will
become fatal in the common clock scenario

to achieve support for MPC512x which is neutral to MPC5200, the
modification was done as follows
- introduce "clock alloc" and "clock release" routines in addition to
  the previous "clock enable/disable" routine in the psc_ops struct
- make the clock allocation a part of the port request (resource
  allocation), and make clock release a part of the port release, such
  that essential resources get allocated early
- just enable/disable the clock from within the .clock() callback
  without any allocation or preparation as the former implementation
  did, since this routine is called from within the startup and shutdown
  callbacks
- all of the above remains a NOP for the MPC5200 platform (no callbacks
  are provided on that platform)
- implementation note: the clock gets enabled upon allocation already
  just in case the clock is not only required for bitrate generation but
  for register access as well

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/tty/serial/mpc52xx_uart.c |  100 ++++++++++++++++++++++++++++++-------
 1 file changed, 83 insertions(+), 17 deletions(-)

diff --git a/drivers/tty/serial/mpc52xx_uart.c b/drivers/tty/serial/mpc52xx_uart.c
index e1280a2..98a1f43 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -107,6 +107,8 @@ struct psc_ops {
 	unsigned int	(*set_baudrate)(struct uart_port *port,
 					struct ktermios *new,
 					struct ktermios *old);
+	int		(*clock_alloc)(struct uart_port *port);
+	void		(*clock_relse)(struct uart_port *port);
 	int		(*clock)(struct uart_port *port, int enable);
 	int		(*fifoc_init)(void);
 	void		(*fifoc_uninit)(void);
@@ -616,31 +618,75 @@ static irqreturn_t mpc512x_psc_handle_irq(struct uart_port *port)
 	return IRQ_NONE;
 }
 
-static int mpc512x_psc_clock(struct uart_port *port, int enable)
+static struct clk *psc_mclk_clk[MPC52xx_PSC_MAXNUM];
+
+/* called from within the .request_port() callback (allocation) */
+static int mpc512x_psc_alloc_clock(struct uart_port *port)
 {
-	struct clk *psc_clk;
 	int psc_num;
-	char clk_name[10];
+	char clk_name[16];
+	struct clk *clk;
+	int err;
+
+	psc_num = (port->mapbase & 0xf00) >> 8;
+	snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
+	clk = clk_get(port->dev, clk_name);
+	if (IS_ERR(clk)) {
+		dev_err(port->dev, "Failed to get MCLK!\n");
+		return PTR_ERR(clk);
+	}
+	err = clk_prepare_enable(clk);
+	if (err) {
+		dev_err(port->dev, "Failed to enable MCLK!\n");
+		clk_put(clk);
+		return err;
+	}
+	psc_mclk_clk[psc_num] = clk;
+	return 0;
+}
+
+/* called from within the .release_port() callback (release) */
+static void mpc512x_psc_relse_clock(struct uart_port *port)
+{
+	int psc_num;
+	struct clk *clk;
+
+	psc_num = (port->mapbase & 0xf00) >> 8;
+	clk = psc_mclk_clk[psc_num];
+	if (clk) {
+		clk_disable_unprepare(clk);
+		clk_put(clk);
+		psc_mclk_clk[psc_num] = NULL;
+	}
+}
+
+/* implementation of the .clock() callback (enable/disable) */
+static int mpc512x_psc_endis_clock(struct uart_port *port, int enable)
+{
+	int psc_num;
+	struct clk *psc_clk;
+	int ret;
 
 	if (uart_console(port))
 		return 0;
 
 	psc_num = (port->mapbase & 0xf00) >> 8;
-	snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
-	psc_clk = clk_get(port->dev, clk_name);
-	if (IS_ERR(psc_clk)) {
+	psc_clk = psc_mclk_clk[psc_num];
+	if (!psc_clk) {
 		dev_err(port->dev, "Failed to get PSC clock entry!\n");
 		return -ENODEV;
 	}
 
-	dev_dbg(port->dev, "%s %sable\n", clk_name, enable ? "en" : "dis");
-
-	if (enable)
-		clk_enable(psc_clk);
-	else
+	dev_dbg(port->dev, "mclk %sable\n", enable ? "en" : "dis");
+	if (enable) {
+		ret = clk_enable(psc_clk);
+		if (ret)
+			dev_err(port->dev, "Failed to enable MCLK!\n");
+		return ret;
+	} else {
 		clk_disable(psc_clk);
-
-	return 0;
+		return 0;
+	}
 }
 
 static void mpc512x_psc_get_irq(struct uart_port *port, struct device_node *np)
@@ -873,7 +919,9 @@ static struct psc_ops mpc5125_psc_ops = {
 	.cw_disable_ints = mpc5125_psc_cw_disable_ints,
 	.cw_restore_ints = mpc5125_psc_cw_restore_ints,
 	.set_baudrate = mpc5125_psc_set_baudrate,
-	.clock = mpc512x_psc_clock,
+	.clock_alloc = mpc512x_psc_alloc_clock,
+	.clock_relse = mpc512x_psc_relse_clock,
+	.clock = mpc512x_psc_endis_clock,
 	.fifoc_init = mpc512x_psc_fifoc_init,
 	.fifoc_uninit = mpc512x_psc_fifoc_uninit,
 	.get_irq = mpc512x_psc_get_irq,
@@ -906,7 +954,9 @@ static struct psc_ops mpc512x_psc_ops = {
 	.cw_disable_ints = mpc512x_psc_cw_disable_ints,
 	.cw_restore_ints = mpc512x_psc_cw_restore_ints,
 	.set_baudrate = mpc512x_psc_set_baudrate,
-	.clock = mpc512x_psc_clock,
+	.clock_alloc = mpc512x_psc_alloc_clock,
+	.clock_relse = mpc512x_psc_relse_clock,
+	.clock = mpc512x_psc_endis_clock,
 	.fifoc_init = mpc512x_psc_fifoc_init,
 	.fifoc_uninit = mpc512x_psc_fifoc_uninit,
 	.get_irq = mpc512x_psc_get_irq,
@@ -1166,6 +1216,9 @@ mpc52xx_uart_type(struct uart_port *port)
 static void
 mpc52xx_uart_release_port(struct uart_port *port)
 {
+	if (psc_ops->clock_relse)
+		psc_ops->clock_relse(port);
+
 	/* remapped by us ? */
 	if (port->flags & UPF_IOREMAP) {
 		iounmap(port->membase);
@@ -1190,11 +1243,24 @@ mpc52xx_uart_request_port(struct uart_port *port)
 	err = request_mem_region(port->mapbase, sizeof(struct mpc52xx_psc),
 			"mpc52xx_psc_uart") != NULL ? 0 : -EBUSY;
 
-	if (err && (port->flags & UPF_IOREMAP)) {
+	if (err)
+		goto out_membase;
+
+	if (psc_ops->clock_alloc) {
+		err = psc_ops->clock_alloc(port);
+		if (err)
+			goto out_mapregion;
+	}
+
+	return 0;
+
+out_mapregion:
+	release_mem_region(port->mapbase, sizeof(struct mpc52xx_psc));
+out_membase:
+	if (port->flags & UPF_IOREMAP) {
 		iounmap(port->membase);
 		port->membase = NULL;
 	}
-
 	return err;
 }
 
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 13:00:37 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:37 +0200
Subject: [PATCH v2 06/24] dts: mpc512x: prepare for preprocessor support
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-7-git-send-email-gsi@denx.de>

prepare C preprocessor support when processing MPC512x DTS files
- switch from DTS syntax to CPP syntax for include specs
- create a symlink such that DTS processing can reference includes

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/boot/dts/ac14xx.dts          |    2 +-
 arch/powerpc/boot/dts/include/dt-bindings |    1 +
 arch/powerpc/boot/dts/mpc5121ads.dts      |    2 +-
 arch/powerpc/boot/dts/pdm360ng.dts        |    2 +-
 4 files changed, 4 insertions(+), 3 deletions(-)
 create mode 120000 arch/powerpc/boot/dts/include/dt-bindings

diff --git a/arch/powerpc/boot/dts/ac14xx.dts b/arch/powerpc/boot/dts/ac14xx.dts
index a27a460..a543c40 100644
--- a/arch/powerpc/boot/dts/ac14xx.dts
+++ b/arch/powerpc/boot/dts/ac14xx.dts
@@ -10,7 +10,7 @@
  */
 
 
-/include/ "mpc5121.dtsi"
+#include <mpc5121.dtsi>
 
 / {
 	model = "ac14xx";
diff --git a/arch/powerpc/boot/dts/include/dt-bindings b/arch/powerpc/boot/dts/include/dt-bindings
new file mode 120000
index 0000000..08c00e4
--- /dev/null
+++ b/arch/powerpc/boot/dts/include/dt-bindings
@@ -0,0 +1 @@
+../../../../../include/dt-bindings
\ No newline at end of file
diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts b/arch/powerpc/boot/dts/mpc5121ads.dts
index 7d3cb79..c228a0a 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -9,7 +9,7 @@
  * option) any later version.
  */
 
-/include/ "mpc5121.dtsi"
+#include <mpc5121.dtsi>
 
 / {
 	model = "mpc5121ads";
diff --git a/arch/powerpc/boot/dts/pdm360ng.dts b/arch/powerpc/boot/dts/pdm360ng.dts
index 7433740..871c16d 100644
--- a/arch/powerpc/boot/dts/pdm360ng.dts
+++ b/arch/powerpc/boot/dts/pdm360ng.dts
@@ -13,7 +13,7 @@
  * option) any later version.
  */
 
-/include/ "mpc5121.dtsi"
+#include <mpc5121.dtsi>
 
 / {
 	model = "pdm360ng";
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 13:00:34 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:34 +0200
Subject: [PATCH v2 03/24] mtd: mpc5121_nfc: prepare clocks before enabling them
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-4-git-send-email-gsi@denx.de>

must prepare clocks before enabling them, unprepare after disable

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/mtd/nand/mpc5121_nfc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/mpc5121_nfc.c b/drivers/mtd/nand/mpc5121_nfc.c
index 3c9cdcb..eb7771d 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -618,7 +618,7 @@ static void mpc5121_nfc_free(struct device *dev, struct mtd_info *mtd)
 	struct mpc5121_nfc_prv *prv = chip->priv;
 
 	if (prv->clk) {
-		clk_disable(prv->clk);
+		clk_disable_unprepare(prv->clk);
 		clk_put(prv->clk);
 	}
 
@@ -737,7 +737,7 @@ static int mpc5121_nfc_probe(struct platform_device *op)
 		goto error;
 	}
 
-	clk_enable(prv->clk);
+	clk_prepare_enable(prv->clk);
 
 	/* Reset NAND Flash controller */
 	nfc_set(mtd, NFC_CONFIG1, NFC_RESET);
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 13:00:32 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:32 +0200
Subject: [PATCH v2 01/24] spi: mpc512x: cleanup clock API use
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-2-git-send-email-gsi@denx.de>

cleanup the MPC512x SoC's SPI master's use of the clock API
- get, prepare, and enable the MCLK during probe; disable, unprepare and
  put the MCLK upon remove; hold a reference to the clock over the
  period of use
- fetch MCLK rate (reference) once during probe and slightly reword BCLK
  (bitrate) determination to reduce redundancy as well as to not exceed
  the maximum text line length
- stick with the PPC_CLOCK 'psc%d_mclk' name for clock lookup, only
  switch to a fixed string later after device tree based clock lookup
  will have become available

the omission in the clock handling previously went unnoticed, but will
become fatal in the common clock scenario

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/spi/spi-mpc512x-psc.c |   49 ++++++++++++++++++++++++++---------------
 1 file changed, 31 insertions(+), 18 deletions(-)

diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
index 29fce6a..7a32373 100644
--- a/drivers/spi/spi-mpc512x-psc.c
+++ b/drivers/spi/spi-mpc512x-psc.c
@@ -38,7 +38,8 @@ struct mpc512x_psc_spi {
 	struct mpc512x_psc_fifo __iomem *fifo;
 	unsigned int irq;
 	u8 bits_per_word;
-	u32 mclk;
+	struct clk *clk_mclk;
+	u32 mclk_rate;
 
 	struct completion txisrdone;
 };
@@ -72,6 +73,7 @@ static void mpc512x_psc_spi_activate_cs(struct spi_device *spi)
 	struct mpc52xx_psc __iomem *psc = mps->psc;
 	u32 sicr;
 	u32 ccr;
+	int speed;
 	u16 bclkdiv;
 
 	sicr = in_be32(&psc->sicr);
@@ -95,10 +97,10 @@ static void mpc512x_psc_spi_activate_cs(struct spi_device *spi)
 
 	ccr = in_be32(&psc->ccr);
 	ccr &= 0xFF000000;
-	if (cs->speed_hz)
-		bclkdiv = (mps->mclk / cs->speed_hz) - 1;
-	else
-		bclkdiv = (mps->mclk / 1000000) - 1;	/* default 1MHz */
+	speed = cs->speed_hz;
+	if (!speed)
+		speed = 1000000;	/* default 1MHz */
+	bclkdiv = (mps->mclk_rate / speed) - 1;
 
 	ccr |= (((bclkdiv & 0xff) << 16) | (((bclkdiv >> 8) & 0xff) << 8));
 	out_be32(&psc->ccr, ccr);
@@ -386,19 +388,11 @@ static int mpc512x_psc_spi_port_config(struct spi_master *master,
 {
 	struct mpc52xx_psc __iomem *psc = mps->psc;
 	struct mpc512x_psc_fifo __iomem *fifo = mps->fifo;
-	struct clk *spiclk;
-	int ret = 0;
-	char name[32];
 	u32 sicr;
 	u32 ccr;
+	int speed;
 	u16 bclkdiv;
 
-	sprintf(name, "psc%d_mclk", master->bus_num);
-	spiclk = clk_get(&master->dev, name);
-	clk_enable(spiclk);
-	mps->mclk = clk_get_rate(spiclk);
-	clk_put(spiclk);
-
 	/* Reset the PSC into a known state */
 	out_8(&psc->command, MPC52xx_PSC_RST_RX);
 	out_8(&psc->command, MPC52xx_PSC_RST_TX);
@@ -425,7 +419,8 @@ static int mpc512x_psc_spi_port_config(struct spi_master *master,
 
 	ccr = in_be32(&psc->ccr);
 	ccr &= 0xFF000000;
-	bclkdiv = (mps->mclk / 1000000) - 1;	/* default 1MHz */
+	speed = 1000000;	/* default 1MHz */
+	bclkdiv = (mps->mclk_rate / speed) - 1;
 	ccr |= (((bclkdiv & 0xff) << 16) | (((bclkdiv >> 8) & 0xff) << 8));
 	out_be32(&psc->ccr, ccr);
 
@@ -445,7 +440,7 @@ static int mpc512x_psc_spi_port_config(struct spi_master *master,
 
 	mps->bits_per_word = 8;
 
-	return ret;
+	return 0;
 }
 
 static irqreturn_t mpc512x_psc_spi_isr(int irq, void *dev_id)
@@ -479,6 +474,8 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
 	struct spi_master *master;
 	int ret;
 	void *tempp;
+	int psc_num;
+	char clk_name[16];
 
 	master = spi_alloc_master(dev, sizeof *mps);
 	if (master == NULL)
@@ -521,16 +518,30 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
 		goto free_master;
 	init_completion(&mps->txisrdone);
 
+	psc_num = master->bus_num;
+	snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
+	mps->clk_mclk = clk_get(dev, clk_name);
+	if (IS_ERR(mps->clk_mclk))
+		goto free_irq;
+	ret = clk_prepare_enable(mps->clk_mclk);
+	if (ret)
+		goto free_putclk;
+	mps->mclk_rate = clk_get_rate(mps->clk_mclk);
+
 	ret = mpc512x_psc_spi_port_config(master, mps);
 	if (ret < 0)
-		goto free_irq;
+		goto free_disclk;
 
 	ret = spi_register_master(master);
 	if (ret < 0)
-		goto free_irq;
+		goto free_disclk;
 
 	return ret;
 
+free_disclk:
+	clk_disable_unprepare(mps->clk_mclk);
+free_putclk:
+	clk_put(mps->clk_mclk);
 free_irq:
 	free_irq(mps->irq, mps);
 free_master:
@@ -547,6 +558,8 @@ static int mpc512x_psc_spi_do_remove(struct device *dev)
 	struct mpc512x_psc_spi *mps = spi_master_get_devdata(master);
 
 	spi_unregister_master(master);
+	clk_disable_unprepare(mps->clk_mclk);
+	clk_put(mps->clk_mclk);
 	free_irq(mps->irq, mps);
 	if (mps->psc)
 		iounmap(mps->psc);
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 13:00:35 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:35 +0200
Subject: [PATCH v2 04/24] powerpc: mpc512x: array decl for MCLK registers in
 CCM
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-5-git-send-email-gsi@denx.de>

reword the clock control module's registers declaration such that the
MCLK related registers form an array and get indexed by PSC number

this change is in preparation to COMMON_CLK support for the MPC512x
platform, the changed declaration remains neutral to existing code since
the PSC and MSCAN CCR fields declared here aren't referenced anywhere

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/include/asm/mpc5121.h |   18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/include/asm/mpc5121.h b/arch/powerpc/include/asm/mpc5121.h
index 8ae133e..887d3d6 100644
--- a/arch/powerpc/include/asm/mpc5121.h
+++ b/arch/powerpc/include/asm/mpc5121.h
@@ -32,25 +32,11 @@ struct mpc512x_ccm {
 	u32	scfr2;	/* System Clock Frequency Register 2 */
 	u32	scfr2s;	/* System Clock Frequency Shadow Register 2 */
 	u32	bcr;	/* Bread Crumb Register */
-	u32	p0ccr;	/* PSC0 Clock Control Register */
-	u32	p1ccr;	/* PSC1 CCR */
-	u32	p2ccr;	/* PSC2 CCR */
-	u32	p3ccr;	/* PSC3 CCR */
-	u32	p4ccr;	/* PSC4 CCR */
-	u32	p5ccr;	/* PSC5 CCR */
-	u32	p6ccr;	/* PSC6 CCR */
-	u32	p7ccr;	/* PSC7 CCR */
-	u32	p8ccr;	/* PSC8 CCR */
-	u32	p9ccr;	/* PSC9 CCR */
-	u32	p10ccr;	/* PSC10 CCR */
-	u32	p11ccr;	/* PSC11 CCR */
+	u32	psc_ccr[12];	/* PSC Clock Control Registers */
 	u32	spccr;	/* SPDIF Clock Control Register */
 	u32	cccr;	/* CFM Clock Control Register */
 	u32	dccr;	/* DIU Clock Control Register */
-	u32	m1ccr;	/* MSCAN1 CCR */
-	u32	m2ccr;	/* MSCAN2 CCR */
-	u32	m3ccr;	/* MSCAN3 CCR */
-	u32	m4ccr;	/* MSCAN4 CCR */
+	u32	mscan_ccr[4];	/* MSCAN Clock Control Registers */
 	u8	res[0x98]; /* Reserved */
 };
 
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 13:00:41 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:41 +0200
Subject: [PATCH v2 10/24] dts: mpc512x: add clock specs for client lookups
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-11-git-send-email-gsi@denx.de>

this addresses the client side of device tree based clock lookups:
add clock specifiers to the mbx, nfc, mscan, sdhc, i2c, axe, diu,
viu, mdio, fec, usb, pata, psc, psc fifo, and pci nodes in the
shared mpc5121.dtsi include

these specs map 'clock-names' encoded in drivers to their respective
'struct clk' items in the platform's clock driver; some drivers
still need to learn how to lookup OF clocks, other drivers will
transparently probe successfully on MPC512x as well (sdhc)

few 'clock-names' (nfc, viu) use strings that are encoded in their
respective drivers to keep up compatibility, an alternative approach
would be to register clkdev items in the platform's clock driver for
the migration period

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/boot/dts/mpc5121.dtsi |   79 ++++++++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi b/arch/powerpc/boot/dts/mpc5121.dtsi
index 8f4cba0..983da9c 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -51,6 +51,10 @@
 		compatible = "fsl,mpc5121-mbx";
 		reg = <0x20000000 0x4000>;
 		interrupts = <66 0x8>;
+		clocks = <&clks MPC512x_CLK_MBX_BUS>,
+			 <&clks MPC512x_CLK_MBX_3D>,
+			 <&clks MPC512x_CLK_MBX>;
+		clock-names = "mbx-bus", "mbx-3d", "mbx";
 	};
 
 	sram at 30000000 {
@@ -64,6 +68,8 @@
 		interrupts = <6 8>;
 		#address-cells = <1>;
 		#size-cells = <1>;
+		clocks = <&clks MPC512x_CLK_NFC>;
+		clock-names = "nfc_clk";	/* backwards compat */
 	};
 
 	localbus at 80000020 {
@@ -153,12 +159,22 @@
 			compatible = "fsl,mpc5121-mscan";
 			reg = <0x1300 0x80>;
 			interrupts = <12 0x8>;
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SYS>,
+				 <&clks MPC512x_CLK_REF>,
+				 <&clks MPC512x_CLK_MSCAN0_MCLK>;
+			clock-names = "ips", "sys", "ref", "mclk";
 		};
 
 		can at 1380 {
 			compatible = "fsl,mpc5121-mscan";
 			reg = <0x1380 0x80>;
 			interrupts = <13 0x8>;
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SYS>,
+				 <&clks MPC512x_CLK_REF>,
+				 <&clks MPC512x_CLK_MSCAN1_MCLK>;
+			clock-names = "ips", "sys", "ref", "mclk";
 		};
 
 		sdhc at 1500 {
@@ -167,6 +183,9 @@
 			interrupts = <8 0x8>;
 			dmas = <&dma0 30>;
 			dma-names = "rx-tx";
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SDHC>;
+			clock-names = "ipg", "per";
 		};
 
 		i2c at 1700 {
@@ -175,6 +194,8 @@
 			compatible = "fsl,mpc5121-i2c", "fsl-i2c";
 			reg = <0x1700 0x20>;
 			interrupts = <9 0x8>;
+			clocks = <&clks MPC512x_CLK_I2C>;
+			clock-names = "per";
 		};
 
 		i2c at 1720 {
@@ -183,6 +204,8 @@
 			compatible = "fsl,mpc5121-i2c", "fsl-i2c";
 			reg = <0x1720 0x20>;
 			interrupts = <10 0x8>;
+			clocks = <&clks MPC512x_CLK_I2C>;
+			clock-names = "per";
 		};
 
 		i2c at 1740 {
@@ -191,6 +214,8 @@
 			compatible = "fsl,mpc5121-i2c", "fsl-i2c";
 			reg = <0x1740 0x20>;
 			interrupts = <11 0x8>;
+			clocks = <&clks MPC512x_CLK_I2C>;
+			clock-names = "per";
 		};
 
 		i2ccontrol at 1760 {
@@ -202,30 +227,46 @@
 			compatible = "fsl,mpc5121-axe";
 			reg = <0x2000 0x100>;
 			interrupts = <42 0x8>;
+			clocks = <&clks MPC512x_CLK_AXE>;
+			clock-names = "per";
 		};
 
 		display at 2100 {
 			compatible = "fsl,mpc5121-diu";
 			reg = <0x2100 0x100>;
 			interrupts = <64 0x8>;
+			clocks = <&clks MPC512x_CLK_DIU>;
+			clock-names = "per";
 		};
 
 		can at 2300 {
 			compatible = "fsl,mpc5121-mscan";
 			reg = <0x2300 0x80>;
 			interrupts = <90 0x8>;
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SYS>,
+				 <&clks MPC512x_CLK_REF>,
+				 <&clks MPC512x_CLK_MSCAN2_MCLK>;
+			clock-names = "ips", "sys", "ref", "mclk";
 		};
 
 		can at 2380 {
 			compatible = "fsl,mpc5121-mscan";
 			reg = <0x2380 0x80>;
 			interrupts = <91 0x8>;
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SYS>,
+				 <&clks MPC512x_CLK_REF>,
+				 <&clks MPC512x_CLK_MSCAN3_MCLK>;
+			clock-names = "ips", "sys", "ref", "mclk";
 		};
 
 		viu at 2400 {
 			compatible = "fsl,mpc5121-viu";
 			reg = <0x2400 0x400>;
 			interrupts = <67 0x8>;
+			clocks = <&clks MPC512x_CLK_VIU>;
+			clock-names = "viu_clk";	/* backwards compat */
 		};
 
 		mdio at 2800 {
@@ -233,6 +274,8 @@
 			reg = <0x2800 0x800>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+			clocks = <&clks MPC512x_CLK_FEC>;
+			clock-names = "per";
 		};
 
 		eth0: ethernet at 2800 {
@@ -241,6 +284,8 @@
 			reg = <0x2800 0x800>;
 			local-mac-address = [ 00 00 00 00 00 00 ];
 			interrupts = <4 0x8>;
+			clocks = <&clks MPC512x_CLK_FEC>;
+			clock-names = "per";
 		};
 
 		/* USB1 using external ULPI PHY */
@@ -252,6 +297,8 @@
 			interrupts = <43 0x8>;
 			dr_mode = "otg";
 			phy_type = "ulpi";
+			clocks = <&clks MPC512x_CLK_USB1>;
+			clock-names = "per";
 		};
 
 		/* USB0 using internal UTMI PHY */
@@ -263,6 +310,8 @@
 			interrupts = <44 0x8>;
 			dr_mode = "otg";
 			phy_type = "utmi_wide";
+			clocks = <&clks MPC512x_CLK_USB2>;
+			clock-names = "per";
 		};
 
 		/* IO control */
@@ -281,6 +330,8 @@
 			compatible = "fsl,mpc5121-pata";
 			reg = <0x10200 0x100>;
 			interrupts = <5 0x8>;
+			clocks = <&clks MPC512x_CLK_PATA>;
+			clock-names = "per";
 		};
 
 		/* 512x PSCs are not 52xx PSC compatible */
@@ -292,6 +343,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC0_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC1 */
@@ -301,6 +354,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC1_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC2 */
@@ -310,6 +365,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC2_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC3 */
@@ -319,6 +376,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC3_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC4 */
@@ -328,6 +387,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC4_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC5 */
@@ -337,6 +398,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC5_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC6 */
@@ -346,6 +409,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC6_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC7 */
@@ -355,6 +420,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC7_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC8 */
@@ -364,6 +431,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC8_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC9 */
@@ -373,6 +442,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC9_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC10 */
@@ -382,6 +453,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC10_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC11 */
@@ -391,12 +464,16 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC11_MCLK>;
+			clock-names = "mclk";
 		};
 
 		pscfifo at 11f00 {
 			compatible = "fsl,mpc5121-psc-fifo";
 			reg = <0x11f00 0x100>;
 			interrupts = <40 0x8>;
+			clocks = <&clks MPC512x_CLK_PSC_FIFO>;
+			clock-names = "per";
 		};
 
 		dma0: dma at 14000 {
@@ -414,6 +491,8 @@
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
+		clocks = <&clks MPC512x_CLK_PCI>;
+		clock-names = "per";
 
 		reg = <0x80008500 0x100	/* internal registers */
 		       0x80008300 0x8>;	/* config space access registers */
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 13:00:36 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:36 +0200
Subject: [PATCH v2 05/24] clk: wrap I/O access for improved portability
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-6-git-send-email-gsi@denx.de>

the common clock drivers were motivated/initiated by ARM development
and apparently assume little endian peripherals

wrap register/peripherals access in the common code (div, gate, mux)
in preparation of adding COMMON_CLK support for other platforms

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/clk/clk-divider.c    |    6 +++---
 drivers/clk/clk-gate.c       |    6 +++---
 drivers/clk/clk-mux.c        |    6 +++---
 include/linux/clk-provider.h |   17 +++++++++++++++++
 4 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 6d55eb2..2c07061 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -104,7 +104,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
 	struct clk_divider *divider = to_clk_divider(hw);
 	unsigned int div, val;
 
-	val = readl(divider->reg) >> divider->shift;
+	val = clk_readl(divider->reg) >> divider->shift;
 	val &= div_mask(divider);
 
 	div = _get_div(divider, val);
@@ -230,11 +230,11 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
 	if (divider->flags & CLK_DIVIDER_HIWORD_MASK) {
 		val = div_mask(divider) << (divider->shift + 16);
 	} else {
-		val = readl(divider->reg);
+		val = clk_readl(divider->reg);
 		val &= ~(div_mask(divider) << divider->shift);
 	}
 	val |= value << divider->shift;
-	writel(val, divider->reg);
+	clk_writel(val, divider->reg);
 
 	if (divider->lock)
 		spin_unlock_irqrestore(divider->lock, flags);
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 790306e..b7fbd96 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -58,7 +58,7 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable)
 		if (set)
 			reg |= BIT(gate->bit_idx);
 	} else {
-		reg = readl(gate->reg);
+		reg = clk_readl(gate->reg);
 
 		if (set)
 			reg |= BIT(gate->bit_idx);
@@ -66,7 +66,7 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable)
 			reg &= ~BIT(gate->bit_idx);
 	}
 
-	writel(reg, gate->reg);
+	clk_writel(reg, gate->reg);
 
 	if (gate->lock)
 		spin_unlock_irqrestore(gate->lock, flags);
@@ -89,7 +89,7 @@ static int clk_gate_is_enabled(struct clk_hw *hw)
 	u32 reg;
 	struct clk_gate *gate = to_clk_gate(hw);
 
-	reg = readl(gate->reg);
+	reg = clk_readl(gate->reg);
 
 	/* if a set bit disables this clk, flip it before masking */
 	if (gate->flags & CLK_GATE_SET_TO_DISABLE)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 614444c..02ef506 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -42,7 +42,7 @@ static u8 clk_mux_get_parent(struct clk_hw *hw)
 	 * OTOH, pmd_trace_clk_mux_ck uses a separate bit for each clock, so
 	 * val = 0x4 really means "bit 2, index starts at bit 0"
 	 */
-	val = readl(mux->reg) >> mux->shift;
+	val = clk_readl(mux->reg) >> mux->shift;
 	val &= mux->mask;
 
 	if (mux->table) {
@@ -89,11 +89,11 @@ static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
 	if (mux->flags & CLK_MUX_HIWORD_MASK) {
 		val = mux->mask << (mux->shift + 16);
 	} else {
-		val = readl(mux->reg);
+		val = clk_readl(mux->reg);
 		val &= ~(mux->mask << mux->shift);
 	}
 	val |= index << mux->shift;
-	writel(val, mux->reg);
+	clk_writel(val, mux->reg);
 
 	if (mux->lock)
 		spin_unlock_irqrestore(mux->lock, flags);
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1ec14a7..c4f7799 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -12,6 +12,7 @@
 #define __LINUX_CLK_PROVIDER_H
 
 #include <linux/clk.h>
+#include <linux/io.h>
 
 #ifdef CONFIG_COMMON_CLK
 
@@ -490,5 +491,21 @@ static inline const char *of_clk_get_parent_name(struct device_node *np,
 #define of_clk_init(matches) \
 	{ while (0); }
 #endif /* CONFIG_OF */
+
+/*
+ * wrap access to peripherals in accessor routines
+ * for improved portability across platforms
+ */
+
+static inline u32 clk_readl(u32 __iomem *reg)
+{
+	return readl(reg);
+}
+
+static inline void clk_writel(u32 val, u32 __iomem *reg)
+{
+	writel(val, reg);
+}
+
 #endif /* CONFIG_COMMON_CLK */
 #endif /* CLK_PROVIDER_H */
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 13:00:44 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:44 +0200
Subject: [PATCH v2 13/24] clk: mpc512x: remove now obsolete clkdev registration
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-14-git-send-email-gsi@denx.de>

after the peripheral drivers for UART and SPI mode (both using the PSC
controller) got converted to device tree based clock lookups, the
platform clock driver need no longer provide the "psc%d_mclk" name which
depends on the PSC index number -- remove the clk_register_clkdev() call

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |   12 ------------
 1 file changed, 12 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index 6627957..b822469 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -12,7 +12,6 @@
  */
 
 #include <linux/clk-provider.h>
-#include <linux/clkdev.h>
 #include <linux/device.h>
 #include <linux/errno.h>
 #include <linux/io.h>
@@ -529,17 +528,6 @@ static void mpc512x_clk_setup_mclk(struct mclk_setup_data *entry)
 				entry->name_mclk,
 				entry->name_mux1, 1, 1);
 	}
-
-	/*
-	 * without this "clock device" registration, "simple" lookups in
-	 * the SPI master initialization and serial port setup will fail
-	 *
-	 * those drivers need to get adjusted to lookup their required
-	 * clocks from device tree specs, and device tree nodes need to
-	 * provide the clock specs, before this clkdev registration
-	 * becomes obsolete
-	 */
-	clk_register_clkdev(clks[clks_idx_pub], entry->name_mclk, NULL);
 }
 
 static void mpc512x_clk_setup_mclks(struct mclk_setup_data *table, size_t count)
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 13:00:43 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:43 +0200
Subject: [PATCH v2 12/24] serial: mpc512x: remove now obsolete clock lookup
 name
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-13-git-send-email-gsi@denx.de>

after device tree based clock lookup became available, the peripheral
driver need no longer construct clock names which include the PSC index,
remove the "psc%d_mclk" template and unconditionally use "mclk"

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/tty/serial/mpc52xx_uart.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/mpc52xx_uart.c b/drivers/tty/serial/mpc52xx_uart.c
index 98a1f43..8643dcf 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -623,14 +623,11 @@ static struct clk *psc_mclk_clk[MPC52xx_PSC_MAXNUM];
 /* called from within the .request_port() callback (allocation) */
 static int mpc512x_psc_alloc_clock(struct uart_port *port)
 {
-	int psc_num;
-	char clk_name[16];
 	struct clk *clk;
 	int err;
+	int psc_num;
 
-	psc_num = (port->mapbase & 0xf00) >> 8;
-	snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
-	clk = clk_get(port->dev, clk_name);
+	clk = clk_get(port->dev, "mclk");
 	if (IS_ERR(clk)) {
 		dev_err(port->dev, "Failed to get MCLK!\n");
 		return PTR_ERR(clk);
@@ -641,6 +638,7 @@ static int mpc512x_psc_alloc_clock(struct uart_port *port)
 		clk_put(clk);
 		return err;
 	}
+	psc_num = (port->mapbase & 0xf00) >> 8;
 	psc_mclk_clk[psc_num] = clk;
 	return 0;
 }
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 13:00:45 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:45 +0200
Subject: [PATCH v2 14/24] serial: mpc512x: setup the PSC FIFO clock as well
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-15-git-send-email-gsi@denx.de>

prepare and enable the FIFO clock upon PSC FIFO initialization,
disable and unprepare the FIFO clock upon PSC FIFO uninitialization,
remove the pre-enable workaround from the platform's clock driver

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |    2 --
 drivers/tty/serial/mpc52xx_uart.c             |   39 +++++++++++++++++++++----
 2 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index b822469..99d197d 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -689,8 +689,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	clk_prepare_enable(clks[MPC512x_CLK_MEM]);	/* SRAM */
 	clk_prepare_enable(clks[MPC512x_CLK_IPS]);	/* SoC periph */
 	clk_prepare_enable(clks[MPC512x_CLK_LPC]);	/* boot media */
-	/* some are required yet no dependencies were declared */
-	clk_prepare_enable(clks[MPC512x_CLK_PSC_FIFO]);
 	/* some are not yet acquired by their respective drivers */
 	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
 	clk_prepare_enable(clks[MPC512x_CLK_FEC]);	/* network, NFS */
diff --git a/drivers/tty/serial/mpc52xx_uart.c b/drivers/tty/serial/mpc52xx_uart.c
index 8643dcf..3fdadf9 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -421,6 +421,7 @@ struct psc_fifoc {
 
 static struct psc_fifoc __iomem *psc_fifoc;
 static unsigned int psc_fifoc_irq;
+static struct clk *psc_fifoc_clk;
 
 static void mpc512x_psc_fifo_init(struct uart_port *port)
 {
@@ -574,30 +575,56 @@ static int __init mpc512x_psc_fifoc_init(void)
 				     "fsl,mpc5121-psc-fifo");
 	if (!np) {
 		pr_err("%s: Can't find FIFOC node\n", __func__);
-		return -ENODEV;
+		goto out_err;
+	}
+
+	psc_fifoc_clk = of_clk_get_by_name(np, "per");
+	if (IS_ERR(psc_fifoc_clk)) {
+		pr_err("%s: Can't lookup FIFO clock\n", __func__);
+		goto out_ofnode_put;
+	}
+	if (clk_prepare_enable(psc_fifoc_clk)) {
+		pr_err("%s: Can't enable FIFO clock\n", __func__);
+		goto out_clk_put;
 	}
 
 	psc_fifoc = of_iomap(np, 0);
 	if (!psc_fifoc) {
 		pr_err("%s: Can't map FIFOC\n", __func__);
-		of_node_put(np);
-		return -ENODEV;
+		goto out_clk_disable;
 	}
 
 	psc_fifoc_irq = irq_of_parse_and_map(np, 0);
-	of_node_put(np);
 	if (psc_fifoc_irq == 0) {
 		pr_err("%s: Can't get FIFOC irq\n", __func__);
-		iounmap(psc_fifoc);
-		return -ENODEV;
+		goto out_unmap;
 	}
 
+	of_node_put(np);
 	return 0;
+
+out_unmap:
+	iounmap(psc_fifoc);
+out_clk_disable:
+	clk_disable_unprepare(psc_fifoc_clk);
+out_clk_put:
+	clk_put(psc_fifoc_clk);
+out_ofnode_put:
+	of_node_put(np);
+out_err:
+	return -ENODEV;
 }
 
 static void __exit mpc512x_psc_fifoc_uninit(void)
 {
 	iounmap(psc_fifoc);
+
+	/* disable the clock, errors are not fatal */
+	if (psc_fifoc_clk && !IS_ERR(psc_fifoc_clk)) {
+		clk_disable_unprepare(psc_fifoc_clk);
+		clk_put(psc_fifoc_clk);
+		psc_fifoc_clk = NULL;
+	}
 }
 
 /* 512x specific interrupt handler. The caller holds the port lock */
-- 
1.7.10.4



From joelf at ti.com  Thu Jul 18 13:02:12 2013
From: joelf at ti.com (Joel Fernandes)
Date: Thu, 18 Jul 2013 12:02:12 -0500
Subject: ARM: AM335x: Kernel oops when using EDMA and MMC
In-Reply-To: <51E81C0E.6070709@gmail.com>
References: <51E6BE84.6080905@newflow.co.uk> <51E6C88B.8090608@ti.com>
 <51E81A7E.9030805@ti.com> <51E81C0E.6070709@gmail.com>
Message-ID: <51E81F94.7090804@ti.com>

On 07/18/2013 11:47 AM, Daniel Mack wrote:
> Hi Balaji,
> 
> On 18.07.2013 18:40, Balaji T K wrote:
>> With DMA channel info retrieved from dt binding on 3.11rc1,
>> unused_chan_list is broken after hwmod cleanup removing mmc sdma
>> resource info, hence pdev resource wont have DMA resource populated.
>>
>> arch/arm/common/edma.c
>> static int prepare_unused_channel_list(struct device *dev, void *data)
>> {
>> 	struct platform_device *pdev = to_platform_device(dev);
>> 	int i, ctlr;
>>
>> 	for (i = 0; i < pdev->num_resources; i++) {
>> 		if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
>> 				(int)pdev->resource[i].start >= 0) {
>> 			ctlr = EDMA_CTLR(pdev->resource[i].start);
>> 			clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
>> 					edma_cc[ctlr]->edma_unused);
>> 		}
>> 	}
>>
>> 	return 0;
>> }
>>
>> int edma_alloc_channel(int channel,
>> 	if (!unused_chan_list_done) {
>> 		/*
>> 		 * Scan all the platform devices to find out the EDMA channels
>> 		 * used and clear them in the unused list, making the rest
>> 		 * available for ARM usage.
>> 		 */
>> 		ret = bus_for_each_dev(&platform_bus_type, NULL, NULL,
>> 				prepare_unused_channel_list);
>> 		if (ret < 0)
>> 			return ret;
>>
>> 		unused_chan_list_done = true;
>> 	}
>>
>> ===========
>>
>> with the below hack patch, edma is working fine with mmc on your 3.11rc1+ branch
>>
>> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
>> index a432e6c..5a19164 100644
>> --- a/arch/arm/common/edma.c
>> +++ b/arch/arm/common/edma.c
>> @@ -1262,8 +1262,8 @@ int edma_start(unsigned channel)
>>   		if (test_bit(channel, edma_cc[ctlr]->edma_unused)) {
>>   			pr_debug("EDMA: ESR%d %08x\n", j,
>>   				edma_shadow0_read_array(ctlr, SH_ESR, j));
>> -			edma_shadow0_write_array(ctlr, SH_ESR, j, mask);
>> -			return 0;
>> +//			edma_shadow0_write_array(ctlr, SH_ESR, j, mask);
>> +//			return 0;
>>   		}
>>
>>   		/* EDMA channel with event association */
>>
> 
> Yes, this in fact works for me as well. Thanks for the quick reply! What
> would be the proper fix for this?

Correct fix would be in the common EDMA driver to populate the unused
channel list correctly as found by Balaji.

Thanks,

-Joel


From gsi at denx.de  Thu Jul 18 13:00:38 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:38 +0200
Subject: [PATCH v2 07/24] dts: mpc512x: introduce dt-bindings/clock/ header
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-8-git-send-email-gsi@denx.de>

introduce a dt-bindings/ header file for MPC512x clocks,
providing symbolic identifiers for those SoC clocks which
clients will reference from their device tree nodes

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 include/dt-bindings/clock/mpc512x-clock.h |   59 +++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)
 create mode 100644 include/dt-bindings/clock/mpc512x-clock.h

diff --git a/include/dt-bindings/clock/mpc512x-clock.h b/include/dt-bindings/clock/mpc512x-clock.h
new file mode 100644
index 0000000..46c560e
--- /dev/null
+++ b/include/dt-bindings/clock/mpc512x-clock.h
@@ -0,0 +1,59 @@
+/*
+ * This header provides constants for MPC512x clock specs in DT bindings.
+ *
+ * Unfortunately the clock number declaration cannot be an enum but
+ * needs to be a list of #define directives since when referenced from
+ * within DTS files they need to get resolved "at compile time".
+ */
+
+#ifndef _DT_BINDINGS_CLOCK_MPC512x_CLOCK_H
+#define _DT_BINDINGS_CLOCK_MPC512x_CLOCK_H
+
+#define MPC512x_CLK_DUMMY		0
+#define MPC512x_CLK_REF			1
+#define MPC512x_CLK_SYS			2
+#define MPC512x_CLK_DIU			3
+#define MPC512x_CLK_VIU			4
+#define MPC512x_CLK_CSB			5
+#define MPC512x_CLK_E300		6
+#define MPC512x_CLK_IPS			7
+#define MPC512x_CLK_FEC			8
+#define MPC512x_CLK_SATA		9
+#define MPC512x_CLK_PATA		10
+#define MPC512x_CLK_NFC			11
+#define MPC512x_CLK_LPC			12
+#define MPC512x_CLK_MBX_BUS		13
+#define MPC512x_CLK_MBX			14
+#define MPC512x_CLK_MBX_3D		15
+#define MPC512x_CLK_AXE			16
+#define MPC512x_CLK_USB1		17
+#define MPC512x_CLK_USB2		18
+#define MPC512x_CLK_I2C			19
+#define MPC512x_CLK_MSCAN0_MCLK		20
+#define MPC512x_CLK_MSCAN1_MCLK		21
+#define MPC512x_CLK_MSCAN2_MCLK		22
+#define MPC512x_CLK_MSCAN3_MCLK		23
+#define MPC512x_CLK_SDHC		24
+#define MPC512x_CLK_PCI			25
+#define MPC512x_CLK_PSC_MCLK_IN		26
+#define MPC512x_CLK_SPDIF_TX		27
+#define MPC512x_CLK_SPDIF_RX		28
+#define MPC512x_CLK_SPDIF_MCLK		29
+#define MPC512x_CLK_AC97		30
+#define MPC512x_CLK_PSC0_MCLK		31
+#define MPC512x_CLK_PSC1_MCLK		32
+#define MPC512x_CLK_PSC2_MCLK		33
+#define MPC512x_CLK_PSC3_MCLK		34
+#define MPC512x_CLK_PSC4_MCLK		35
+#define MPC512x_CLK_PSC5_MCLK		36
+#define MPC512x_CLK_PSC6_MCLK		37
+#define MPC512x_CLK_PSC7_MCLK		38
+#define MPC512x_CLK_PSC8_MCLK		39
+#define MPC512x_CLK_PSC9_MCLK		40
+#define MPC512x_CLK_PSC10_MCLK		41
+#define MPC512x_CLK_PSC11_MCLK		42
+#define MPC512x_CLK_PSC_FIFO		43
+
+#define MPC512x_CLK_LAST_PUBLIC		43
+
+#endif
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 13:00:39 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:39 +0200
Subject: [PATCH v2 08/24] dts: mpc512x: add clock related device tree specs
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-9-git-send-email-gsi@denx.de>

this addresses the clock driver aka provider's side of clocks
- prepare for future '<&clks ID>' phandle references for device tree
  based clock lookup in client drivers
- introduce a 'clocks' subtree with an 'osc' node for the crystal
  or oscillator SoC input (fixed frequency)
- provide default values with 33MHz oscillator frequency in the
  common include (the 66MHz IPS bus already was there), add
  override values for the ifm AC14xx board which deviates from
  the reference design (25MHz xtal, 80MHz IPS bus)

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/boot/dts/ac14xx.dts   |    7 +++++++
 arch/powerpc/boot/dts/mpc5121.dtsi |   15 ++++++++++++++-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/ac14xx.dts b/arch/powerpc/boot/dts/ac14xx.dts
index a543c40..a1b8837 100644
--- a/arch/powerpc/boot/dts/ac14xx.dts
+++ b/arch/powerpc/boot/dts/ac14xx.dts
@@ -139,7 +139,14 @@
 		};
 	};
 
+	clocks {
+		osc {
+			clock-frequency = <25000000>;
+		};
+	};
+
 	soc at 80000000 {
+		bus-frequency = <80000000>;	/* 80 MHz ips bus */
 
 		clock at f00 {
 			compatible = "fsl,mpc5121rev2-clock", "fsl,mpc5121-clock";
diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi b/arch/powerpc/boot/dts/mpc5121.dtsi
index bd14c00..8f4cba0 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -9,6 +9,8 @@
  * option) any later version.
  */
 
+#include <dt-bindings/clock/mpc512x-clock.h>
+
 /dts-v1/;
 
 / {
@@ -73,6 +75,16 @@
 		ranges = <0x0 0x0 0xfc000000 0x04000000>;
 	};
 
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		osc {
+			compatible = "fsl,mpc512x-osc", "fixed-clock";
+			clock-frequency = <33000000>;
+		};
+	};
+
 	soc at 80000000 {
 		compatible = "fsl,mpc5121-immr";
 		#address-cells = <1>;
@@ -118,9 +130,10 @@
 		};
 
 		/* Clock control */
-		clock at f00 {
+		clks: clock at f00 {
 			compatible = "fsl,mpc5121-clock";
 			reg = <0xf00 0x100>;
+			#clock-cells = <1>;
 		};
 
 		/* Power Management Controller */
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 13:00:42 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:42 +0200
Subject: [PATCH v2 11/24] spi: mpc512x: remove now obsolete clock lookup name
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-12-git-send-email-gsi@denx.de>

after device tree based clock lookup became available, the peripheral
driver need no longer construct clock names which include the PSC index,
remove the "psc%d_mclk" template and unconditionally use "mclk"

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/spi/spi-mpc512x-psc.c |    6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
index 7a32373..b04f094 100644
--- a/drivers/spi/spi-mpc512x-psc.c
+++ b/drivers/spi/spi-mpc512x-psc.c
@@ -474,8 +474,6 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
 	struct spi_master *master;
 	int ret;
 	void *tempp;
-	int psc_num;
-	char clk_name[16];
 
 	master = spi_alloc_master(dev, sizeof *mps);
 	if (master == NULL)
@@ -518,9 +516,7 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
 		goto free_master;
 	init_completion(&mps->txisrdone);
 
-	psc_num = master->bus_num;
-	snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
-	mps->clk_mclk = clk_get(dev, clk_name);
+	mps->clk_mclk = clk_get(dev, "mclk");
 	if (IS_ERR(mps->clk_mclk))
 		goto free_irq;
 	ret = clk_prepare_enable(mps->clk_mclk);
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 13:00:40 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 19:00:40 +0200
Subject: [PATCH v2 09/24] clk: mpc512x: introduce COMMON_CLK for MPC512x
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374166855-7280-10-git-send-email-gsi@denx.de>

this change introduces a clock infrastructure implementation for the
MPC512x PowerPC platform which follows the COMMON_CLK approach and uses
common clock drivers shared with other platforms

this driver implements the publicly announced set of clocks (which can
get referenced by means of symbolic identifiers from the dt-bindings
header file), as well as generates additional 'struct clk' items where
the SoC hardware cannot easily get mapped to the common primitives of
the clock API, or requires "intermediate" clock nodes to represent
clocks that have both gates and dividers

the previous PPC_CLOCK implementation is kept in place and resides in
parallel to the common clock implementation for test and comparison
during migration, a compile time option picks one of the two
alternatives (Kconfig switch, common clock used by default)

since not all drivers for peripherals were adjusted yet to properly
allocate and release their clock items, this platform clock driver
implementation pre-enables some of the clock items to not break
peripheral drivers during migration -- these clock pre-enable
workarounds will get removed as peripheral drivers get adjusted

to provide clock names which the serial communication drivers are using
and where the PSC index number is encoded into, clkdev registration is
done to not break these peripheral drivers -- this workaround will get
removed as these drivers get adjusted after device tree based clock
lookup has become available

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/Kconfig           |   14 +-
 arch/powerpc/platforms/512x/Makefile          |    4 +-
 arch/powerpc/platforms/512x/clock-commonclk.c |  778 +++++++++++++++++++++++++
 include/linux/clk-provider.h                  |   16 +
 4 files changed, 810 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/platforms/512x/clock-commonclk.c

diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig
index fc9c1cb..c5fcdd0 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -1,9 +1,21 @@
+config MPC512x_COMMON_CLK
+	bool "MPC512x platform uses COMMON_CLK"
+	default y
+	depends on PPC_MPC512x
+	help
+	  This option is only here to support tests and comparison
+	  during development and migration.  This option will get
+	  removed after the COMMON_CLK support for MPC512x has become
+	  fully operational and all drivers were adjusted to explicitly
+	  acquire their required clocks.
+
 config PPC_MPC512x
 	bool "512x-based boards"
 	depends on 6xx
 	select FSL_SOC
 	select IPIC
-	select PPC_CLOCK
+	select PPC_CLOCK if !MPC512x_COMMON_CLK
+	select COMMON_CLK if MPC512x_COMMON_CLK
 	select PPC_PCI_CHOICE
 	select FSL_PCI if PCI
 	select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/powerpc/platforms/512x/Makefile b/arch/powerpc/platforms/512x/Makefile
index 72fb934..1e05f9d 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -1,7 +1,9 @@
 #
 # Makefile for the Freescale PowerPC 512x linux kernel.
 #
-obj-y				+= clock.o mpc512x_shared.o
+obj-$(CONFIG_PPC_CLOCK)		+= clock.o
+obj-$(CONFIG_COMMON_CLK)	+= clock-commonclk.o
+obj-y				+= mpc512x_shared.o
 obj-$(CONFIG_MPC5121_ADS)	+= mpc5121_ads.o mpc5121_ads_cpld.o
 obj-$(CONFIG_MPC512x_GENERIC)	+= mpc512x_generic.o
 obj-$(CONFIG_PDM360NG)		+= pdm360ng.o
diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
new file mode 100644
index 0000000..6627957
--- /dev/null
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -0,0 +1,778 @@
+/*
+ * Copyright (C) 2013 DENX Software Engineering
+ *
+ * Gerhard Sittig, <gsi at denx.de>
+ *
+ * common clock driver support for the MPC512x platform
+ *
+ * This is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+#include <linux/of.h>
+
+#include <asm/mpc5121.h>
+#include <dt-bindings/clock/mpc512x-clock.h>
+
+#include "mpc512x.h"		/* our public mpc5121_clk_init() API */
+
+/* helpers to keep the MCLK intermediates "somewhere" in our table */
+enum {
+	MCLK_IDX_MUX0,
+	MCLK_IDX_EN0,
+	MCLK_IDX_DIV0,
+	MCLK_IDX_MUX1,
+	MCLK_MAX_IDX,
+};
+
+#define NR_PSCS			12
+#define NR_MSCANS		4
+#define NR_SPDIFS		1
+#define NR_MCLKS		(NR_PSCS + NR_MSCANS + NR_SPDIFS)
+
+/* extend the public set of clocks by adding internal slots for management */
+enum {
+	/* arrange for adjacent numbers after the public set */
+	MPC512x_CLK_START_PRIVATE = MPC512x_CLK_LAST_PUBLIC,
+	/* clocks which aren't announced to the public */
+	MPC512x_CLK_DDR,
+	MPC512x_CLK_MEM,
+	MPC512x_CLK_IIM,
+	MPC512x_CLK_SDHC_2,
+	/* intermediates in div+gate combos or fractional dividers */
+	MPC512x_CLK_DDR_UG,
+	MPC512x_CLK_SDHC_x4,
+	MPC512x_CLK_SDHC_UG,
+	MPC512x_CLK_DIU_x4,
+	MPC512x_CLK_DIU_UG,
+	MPC512x_CLK_MBX_BUS_UG,
+	MPC512x_CLK_MBX_UG,
+	MPC512x_CLK_MBX_3D_UG,
+	MPC512x_CLK_PCI_UG,
+	MPC512x_CLK_NFC_UG,
+	MPC512x_CLK_LPC_UG,
+	MPC512x_CLK_SPDIF_TX_IN,
+	/* intermediates for the mux+gate+div+mux MCLK generation */
+	MPC512x_CLK_MCLKS_FIRST,
+	MPC512x_CLK_MCLKS_LAST = MPC512x_CLK_MCLKS_FIRST
+				+ NR_MCLKS * MCLK_MAX_IDX,
+	/* internal, symbolic spec for the number of slots */
+	MPC512x_CLK_LAST_PRIVATE,
+};
+
+/* data required for the OF clock provider registration */
+static struct clk *clks[MPC512x_CLK_LAST_PRIVATE];
+static struct clk_onecell_data clk_data;
+
+/* CCM register access */
+static struct mpc512x_ccm __iomem *clkregs;
+static DEFINE_SPINLOCK(clklock);
+
+/* convenience wrappers around the common clk API */
+static inline struct clk *mpc512x_clk_fixed(const char *name, int rate)
+{
+	return clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
+}
+
+static inline struct clk *mpc512x_clk_factor(
+	const char *name, const char *parent_name,
+	int mul, int div)
+{
+	int clkflags;
+
+	clkflags = CLK_SET_RATE_PARENT;
+	return clk_register_fixed_factor(NULL, name, parent_name, clkflags,
+					 mul, div);
+}
+
+static inline struct clk *mpc512x_clk_divider(
+	const char *name, const char *parent_name, u8 clkflags,
+	u32 __iomem *reg, u8 pos, u8 len, int divflags)
+{
+	return clk_register_divider(NULL, name, parent_name, clkflags,
+				    reg, pos, len, divflags, &clklock);
+}
+
+static inline struct clk *mpc512x_clk_divtable(
+	const char *name, const char *parent_name,
+	u32 __iomem *reg, u8 pos, u8 len,
+	const struct clk_div_table *divtab)
+{
+	u8 divflags;
+
+	divflags = 0;
+	return clk_register_divider_table(NULL, name, parent_name, 0,
+					  reg, pos, len, divflags,
+					  divtab, &clklock);
+}
+
+static inline struct clk *mpc512x_clk_gated(
+	const char *name, const char *parent_name,
+	u32 __iomem *reg, u8 pos)
+{
+	int clkflags;
+
+	clkflags = CLK_SET_RATE_PARENT;
+	return clk_register_gate(NULL, name, parent_name, clkflags,
+				 reg, pos, 0, &clklock);
+}
+
+static inline struct clk *mpc512x_clk_muxed(const char *name,
+	const char **parent_names, int parent_count,
+	u32 __iomem *reg, u8 pos, u8 len)
+{
+	int clkflags;
+	u8 muxflags;
+
+	clkflags = CLK_SET_RATE_PARENT;
+	muxflags = 0;
+	return clk_register_mux(NULL, name,
+				parent_names, parent_count, clkflags,
+				reg, pos, len, muxflags, &clklock);
+}
+
+/* helper to isolate a bit field from a register */
+static inline int get_bit_field(uint32_t __iomem *reg, uint8_t pos, uint8_t len)
+{
+	uint32_t val;
+
+	val = in_be32(reg);
+	val >>= pos;
+	val &= (1 << len) - 1;
+	return val;
+}
+
+/* get the SPMF and translate it into the "sys pll" multiplier */
+static int get_spmf_mult(void)
+{
+	static int spmf_to_mult[] = {
+		68, 1, 12, 16, 20, 24, 28, 32,
+		36, 40, 44, 48, 52, 56, 60, 64,
+	};
+	int spmf;
+
+	spmf = get_bit_field(&clkregs->spmr, 24, 4);
+	return spmf_to_mult[spmf];
+}
+
+/*
+ * get the SYS_DIV value and translate it into a divide factor
+ *
+ * values returned from here are a multiple of the real factor since the
+ * divide ratio is fractional
+ */
+static int get_sys_div_x2(void)
+{
+	static int sysdiv_code_to_x2[] = {
+		4, 5, 6, 7, 8, 9, 10, 14,
+		12, 16, 18, 22, 20, 24, 26, 30,
+		28, 32, 34, 38, 36, 40, 42, 46,
+		44, 48, 50, 54, 52, 56, 58, 62,
+		60, 64, 66,
+	};
+	int divcode;
+
+	divcode = get_bit_field(&clkregs->scfr2, 26, 6);
+	return sysdiv_code_to_x2[divcode];
+}
+
+/*
+ * get the CPMF value and translate it into a multiplier factor
+ *
+ * values returned from here are a multiple of the real factor since the
+ * multiplier ratio is fractional
+ */
+static int get_cpmf_mult_x2(void)
+{
+	static int cpmf_to_mult[] = {
+		72, 2, 2, 3, 4, 5, 6, 7,
+	};
+	int cpmf;
+
+	cpmf = get_bit_field(&clkregs->spmr, 16, 4);
+	return cpmf_to_mult[cpmf];
+}
+
+/*
+ * some of the clock dividers do scale in a linear way, yet not all of
+ * their bit combinations are legal; use a divider table to get a
+ * resulting set of applicable divider values
+ */
+
+/* applies to the IPS_DIV, and PCI_DIV values */
+static struct clk_div_table divtab_2346[] = {
+	{ .val = 2, .div = 2, },
+	{ .val = 3, .div = 3, },
+	{ .val = 4, .div = 4, },
+	{ .val = 6, .div = 6, },
+	{ .div = 0, },
+};
+
+/* applies to the MBX_DIV, LPC_DIV, and NFC_DIV values */
+static struct clk_div_table divtab_1234[] = {
+	{ .val = 1, .div = 1, },
+	{ .val = 2, .div = 2, },
+	{ .val = 3, .div = 3, },
+	{ .val = 4, .div = 4, },
+	{ .div = 0, },
+};
+
+static int get_freq_from_dt(char *propname)
+{
+	struct device_node *np;
+	const unsigned int *prop;
+	int val;
+
+	val = 0;
+	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-immr");
+	if (np) {
+		prop = of_get_property(np, propname, NULL);
+		if (prop)
+			val = *prop;
+	    of_node_put(np);
+	}
+	return val;
+}
+
+static void mpc512x_clk_preset_data(void)
+{
+	size_t i;
+
+	for (i = 0; i < ARRAY_SIZE(clks); i++)
+		clks[i] = ERR_PTR(-ENODEV);
+}
+
+/*
+ * - receives the "bus frequency" from the caller (that's the IPS clock
+ *   rate, the historical source of clock information)
+ * - fetches the system PLL multiplier and divider values as well as the
+ *   IPS divider value from hardware
+ * - determines the REF clock rate either from the XTAL/OSC spec (if
+ *   there is a device tree node describing the oscillator) or from the
+ *   IPS bus clock (supported for backwards compatibility, such that
+ *   setups without XTAL/OSC specs keep working)
+ * - creates the "ref" clock item in the clock tree, such that
+ *   subsequent code can create the remainder of the hierarchy (REF ->
+ *   SYS -> CSB -> IPS) from the REF clock rate and the returned mul/div
+ *   values
+ */
+static void mpc512x_clk_setup_ref_clock(int bus_freq,
+	int *sys_mul, int *sys_div, int *ips_div)
+{
+	struct clk *osc_clk;
+	int calc_freq;
+
+	/* fetch mul/div factors from the hardware */
+	*sys_mul = get_spmf_mult();
+	*sys_mul *= 2;		/* compensate for the fractional divider */
+	*sys_div = get_sys_div_x2();
+	*ips_div = get_bit_field(&clkregs->scfr1, 23, 3);
+
+	/* lookup the oscillator node */
+	osc_clk = clk_get(NULL, "osc");
+	if (osc_clk) {
+		/* descend REF directly from OSC, verify the IPS rate */
+		clks[MPC512x_CLK_REF] = mpc512x_clk_factor("ref", "osc", 1, 1);
+		calc_freq = clk_get_rate(clks[MPC512x_CLK_REF]);
+		calc_freq *= *sys_mul;
+		calc_freq /= *sys_div;
+		calc_freq /= 2;
+		calc_freq /= *ips_div;
+		if (bus_freq && calc_freq != bus_freq)
+			pr_warn("calc rate %d != OF spec %d\n",
+				calc_freq, bus_freq);
+	} else {
+		/* calculate OSC rate and create REF from the freq value */
+		calc_freq = bus_freq;	/* start with IPS */
+		calc_freq *= *ips_div;	/* IPS -> CSB */
+		calc_freq *= 2;		/* CSB -> SYS */
+		calc_freq *= *sys_div;	/* SYS -> PLL out */
+		calc_freq /= *sys_mul;	/* PLL out -> REF == OSC */
+		clks[MPC512x_CLK_REF] = mpc512x_clk_fixed("ref", calc_freq);
+	}
+}
+
+/*
+ * helper code for the MCLK subtree setup
+ *
+ * the overview in section 5.2.4 of the MPC5121e Reference Manual rev4
+ * suggests that all instances of the "PSC clock generation" are equal,
+ * and that one might re-use the PSC setup for MSCAN clock generation
+ * (section 5.2.5) as well, at least the logic if not the data for
+ * description
+ *
+ * the details (starting at page 5-20) show differences in the specific
+ * inputs of the first mux stage ("can clk in", "spdif tx"), and the
+ * factual non-availability of the second mux stage (it's present yet
+ * only one input is valid)
+ *
+ * the MSCAN clock related registers (starting at page 5-35) all
+ * reference "spdif clk" at the first mux stage and don't mention any
+ * "can clk" at all, which somehow is unexpected
+ *
+ * TODO re-check the document, and clarify whether the RM is correct in
+ * the overview or in the details, and whether the difference is a
+ * clipboard induced error or results from chip revisions
+ *
+ * it turns out that the RM rev4 as of 2012-06 talks about "can" for the
+ * PSCs while RM rev3 as of 2008-10 talks about "spdif", so I guess that
+ * first a doc update is required which better reflects reality in the
+ * SoC before the implementation should follow while no questions remain
+ */
+
+/*
+ * note that this declaration raises a checkpatch warning, but
+ * it's the very data type which <linux/clk-provider.h> expects,
+ * making this declaration pass checkpatch will break compilation
+ */
+static const char *parent_names_mux0[] = {
+	"sys", "ref", "psc-mclk-in", "spdif-tx",
+};
+
+enum mclk_type {
+	MCLK_TYPE_PSC,
+	MCLK_TYPE_MSCAN,
+	MCLK_TYPE_SPDIF,
+};
+
+struct mclk_setup_data {
+	enum mclk_type type;
+	int comp_idx;
+	bool has_mclk1;
+	int bit_sccr1, bit_sccr2;
+	const char *name_mux0;
+	const char *name_en0;
+	const char *name_div0;
+	const char *parent_names_mux1[2];
+	const char *name_mux1;
+	const char *name_mclk;
+};
+
+#define MCLK_SETUP_DATA_PSC(id) { \
+	MCLK_TYPE_PSC, id, \
+	0, 27 - id, -1, \
+	"psc" #id "-mux0", \
+	"psc" #id "-en0", \
+	"psc" #id "_mclk_div", \
+	{ "psc" #id "_mclk_div", "dummy", }, \
+	"psc" #id "_mclk_out", \
+	"psc" #id "_mclk", \
+}
+
+#define MCLK_SETUP_DATA_MSCAN(id) { \
+	MCLK_TYPE_MSCAN, id, \
+	0, -1, 25, \
+	"mscan" #id "-mux0", \
+	"mscan" #id "-en0", \
+	"mscan" #id "_mclk_div", \
+	{ "mscan" #id "_mclk_div", "dummy", }, \
+	"mscan" #id "_mclk_out", \
+	"mscan" #id "_mclk", \
+}
+
+#define MCLK_SETUP_DATA_SPDIF { \
+	MCLK_TYPE_SPDIF, 0, \
+	1, -1, 23, \
+	"spdif-mux0", \
+	"spdif-en0", \
+	"spdif_mclk_div", \
+	{ "spdif_mclk_div", "spdif-rx", }, \
+	"spdif_mclk_out", \
+	"spdif_mclk", \
+}
+
+static struct mclk_setup_data mclk_psc_data[] = {
+	MCLK_SETUP_DATA_PSC(0),
+	MCLK_SETUP_DATA_PSC(1),
+	MCLK_SETUP_DATA_PSC(2),
+	MCLK_SETUP_DATA_PSC(3),
+	MCLK_SETUP_DATA_PSC(4),
+	MCLK_SETUP_DATA_PSC(5),
+	MCLK_SETUP_DATA_PSC(6),
+	MCLK_SETUP_DATA_PSC(7),
+	MCLK_SETUP_DATA_PSC(8),
+	MCLK_SETUP_DATA_PSC(9),
+	MCLK_SETUP_DATA_PSC(10),
+	MCLK_SETUP_DATA_PSC(11),
+};
+
+static struct mclk_setup_data mclk_mscan_data[] = {
+	MCLK_SETUP_DATA_MSCAN(0),
+	MCLK_SETUP_DATA_MSCAN(1),
+	MCLK_SETUP_DATA_MSCAN(2),
+	MCLK_SETUP_DATA_MSCAN(3),
+};
+
+static struct mclk_setup_data mclk_spdif_data[] = {
+	MCLK_SETUP_DATA_SPDIF,
+};
+
+/* setup the MCLK clock subtree of an individual PSC/MSCAN/SPDIF */
+static void mpc512x_clk_setup_mclk(struct mclk_setup_data *entry)
+{
+	size_t clks_idx_pub, clks_idx_int;
+	u32 __iomem *mccr_reg;	/* MCLK control register (mux, en, div) */
+	u32 __iomem *sccr_reg;	/* system clock control register (enable) */
+	int sccr_bit;
+	int div;
+
+	/* derive a few parameters from the component type and index */
+	switch (entry->type) {
+	case MCLK_TYPE_PSC:
+		clks_idx_pub = MPC512x_CLK_PSC0_MCLK + entry->comp_idx;
+		clks_idx_int = MPC512x_CLK_MCLKS_FIRST
+			     + (entry->comp_idx) * MCLK_MAX_IDX;
+		mccr_reg = &clkregs->psc_ccr[entry->comp_idx];
+		break;
+	case MCLK_TYPE_MSCAN:
+		clks_idx_pub = MPC512x_CLK_MSCAN0_MCLK + entry->comp_idx;
+		clks_idx_int = MPC512x_CLK_MCLKS_FIRST
+			     + (NR_PSCS + entry->comp_idx) * MCLK_MAX_IDX;
+		mccr_reg = &clkregs->mscan_ccr[entry->comp_idx];
+		break;
+	case MCLK_TYPE_SPDIF:
+		clks_idx_pub = MPC512x_CLK_SPDIF_MCLK;
+		clks_idx_int = MPC512x_CLK_MCLKS_FIRST
+			     + (NR_PSCS + NR_MSCANS) * MCLK_MAX_IDX;
+		mccr_reg = &clkregs->spccr;
+		break;
+	default:
+		return;
+	}
+	if (entry->bit_sccr1 >= 0) {
+		sccr_reg = &clkregs->sccr1;
+		sccr_bit = entry->bit_sccr1;
+	} else if (entry->bit_sccr2 >= 0) {
+		sccr_reg = &clkregs->sccr2;
+		sccr_bit = entry->bit_sccr2;
+	} else {
+		sccr_reg = NULL;
+	}
+
+	/*
+	 * this was grabbed from the PPC_CLOCK implementation, which
+	 * enforced a specific MCLK divider while the clock was gated
+	 * during setup (that's a documented hardware requirement)
+	 *
+	 * the PPC_CLOCK implementation might even have violated the
+	 * "MCLK <= IPS" constraint, the fixed divider value of 1
+	 * results in a divider of 2 and thus MCLK = SYS/2 which equals
+	 * CSB which is greater than IPS; the serial port setup may have
+	 * adjusted the divider which the clock setup might have left in
+	 * an undesirable state
+	 *
+	 * initial setup is:
+	 * - MCLK 0 from SYS
+	 * - MCLK DIV such to not exceed the IPS clock
+	 * - MCLK 0 enabled
+	 * - MCLK 1 from MCLK DIV
+	 */
+	div = clk_get_rate(clks[MPC512x_CLK_SYS]);
+	div /= clk_get_rate(clks[MPC512x_CLK_IPS]);
+	out_be32(mccr_reg, (0 << 16));
+	out_be32(mccr_reg, (0 << 16) | ((div - 1) << 17));
+	out_be32(mccr_reg, (1 << 16) | ((div - 1) << 17));
+
+	/*
+	 * create the 'struct clk' items of the MCLK's clock subtree
+	 *
+	 * note that by design we always create all nodes and won't take
+	 * shortcuts here, because
+	 * - the "internal" MCLK_DIV and MCLK_OUT signal in turn are
+	 *   selectable inputs to the CFM while those who "actually use"
+	 *   the PSC/MSCAN/SPDIF (serial drivers et al) need the MCLK
+	 *   for their bitrate
+	 * - in the absence of "aliases" for clocks we need to create
+	 *   individial 'struct clk' items for whatever might get
+	 *   referenced or looked up, even if several of those items are
+	 *   identical from the logical POV (their rate value)
+	 * - for easier future maintenance and for better reflection of
+	 *   the SoC's documentation, it appears appropriate to generate
+	 *   clock items even for those muxers which actually are NOPs
+	 *   (those with two inputs of which one is reserved)
+	 */
+	clks[clks_idx_int + MCLK_IDX_MUX0] = mpc512x_clk_muxed(
+			entry->name_mux0,
+			&parent_names_mux0[0], ARRAY_SIZE(parent_names_mux0),
+			mccr_reg, 14, 2);
+	clks[clks_idx_int + MCLK_IDX_EN0] = mpc512x_clk_gated(
+			entry->name_en0, entry->name_mux0,
+			mccr_reg, 16);
+	clks[clks_idx_int + MCLK_IDX_DIV0] = mpc512x_clk_divider(
+			entry->name_div0,
+			entry->name_en0, CLK_SET_RATE_GATE,
+			mccr_reg, 17, 15, 0);
+	if (entry->has_mclk1) {
+		clks[clks_idx_int + MCLK_IDX_MUX1] = mpc512x_clk_muxed(
+				entry->name_mux1,
+				&entry->parent_names_mux1[0],
+				ARRAY_SIZE(entry->parent_names_mux1),
+				mccr_reg, 7, 1);
+	} else {
+		clks[clks_idx_int + MCLK_IDX_MUX1] = mpc512x_clk_factor(
+				entry->name_mux1, entry->parent_names_mux1[0],
+				1, 1);
+	}
+	if (sccr_reg) {
+		clks[clks_idx_pub] = mpc512x_clk_gated(
+				entry->name_mclk,
+				entry->name_mux1, sccr_reg, sccr_bit);
+	} else {
+		clks[clks_idx_pub] = mpc512x_clk_factor(
+				entry->name_mclk,
+				entry->name_mux1, 1, 1);
+	}
+
+	/*
+	 * without this "clock device" registration, "simple" lookups in
+	 * the SPI master initialization and serial port setup will fail
+	 *
+	 * those drivers need to get adjusted to lookup their required
+	 * clocks from device tree specs, and device tree nodes need to
+	 * provide the clock specs, before this clkdev registration
+	 * becomes obsolete
+	 */
+	clk_register_clkdev(clks[clks_idx_pub], entry->name_mclk, NULL);
+}
+
+static void mpc512x_clk_setup_mclks(struct mclk_setup_data *table, size_t count)
+{
+	while (count-- > 0)
+		mpc512x_clk_setup_mclk(table++);
+}
+
+static void mpc512x_clk_setup_clock_tree(int busfreq)
+{
+	int sys_mul, sys_div, ips_div;
+	int mul, div;
+	int freq;
+
+	/*
+	 * TODO
+	 * - consider whether to handle clocks which have both gates and
+	 *   dividers via intermediates or by means of composites
+	 * - fractional dividers appear to not map well to composites
+	 *   since they can be seen as a fixed multiplier and an
+	 *   adjustable divider, while composites can only combine at
+	 *   most one of a mux, div, and gate each into one 'struct clk'
+	 *   item
+	 * - PSC/MSCAN/SPDIF clock generation OTOH already is very
+	 *   specific and cannot get mapped to componsites (at least not
+	 *   a single one, maybe two of them, but see the comment about
+	 *   "intermediates are referenced from elsewhere, too")
+	 * - trim the list of auto-enabled clocks after drivers acquire
+	 *   them correctly as needed
+	 */
+
+	/* regardless of whether XTAL/OSC exists, have REF created */
+	mpc512x_clk_setup_ref_clock(busfreq, &sys_mul, &sys_div, &ips_div);
+
+	/* now setup the REF -> SYS -> CSB -> IPS hierarchy */
+	clks[MPC512x_CLK_SYS] = mpc512x_clk_factor("sys", "ref",
+						   sys_mul, sys_div);
+	clks[MPC512x_CLK_CSB] = mpc512x_clk_factor("csb", "sys", 1, 2);
+	clks[MPC512x_CLK_IPS] = mpc512x_clk_divtable("ips", "csb",
+						     &clkregs->scfr1, 23, 3,
+						     divtab_2346);
+
+	/* now setup anything below SYS and CSB and IPS */
+	clks[MPC512x_CLK_DDR_UG] = mpc512x_clk_factor("ddr-ug", "sys", 1, 2);
+	clks[MPC512x_CLK_SDHC_x4] = mpc512x_clk_factor("sdhc-x4", "csb", 4, 1);
+	clks[MPC512x_CLK_SDHC_UG] = mpc512x_clk_divider("sdhc-ug", "sdhc-x4", 0,
+							&clkregs->scfr2, 0, 8,
+							CLK_DIVIDER_ONE_BASED);
+	clks[MPC512x_CLK_DIU_x4] = mpc512x_clk_factor("diu-x4", "csb", 4, 1);
+	clks[MPC512x_CLK_DIU_UG] = mpc512x_clk_divider("diu-ug", "diu-x4", 0,
+						       &clkregs->scfr1, 0, 8,
+						       CLK_DIVIDER_ONE_BASED);
+
+	/*
+	 * the "power architecture PLL" was setup from data which was
+	 * sampled from the reset config word, at this point in time the
+	 * configuration can be considered fixed and read only (i.e. no
+	 * longer adjustable, or no longer in need of adjustment), which
+	 * is why we don't register a PLL here but assume fixed factors
+	 */
+	mul = get_cpmf_mult_x2();
+	div = 2;	/* compensate for the fractional factor */
+	clks[MPC512x_CLK_E300] = mpc512x_clk_factor("e300", "csb", mul, div);
+
+	clks[MPC512x_CLK_MBX_BUS_UG] = mpc512x_clk_factor("mbx-bus-ug", "csb",
+							  1, 2);
+	clks[MPC512x_CLK_MBX_UG] = mpc512x_clk_divtable("mbx-ug", "mbx-bus-ug",
+							&clkregs->scfr1, 14, 3,
+							divtab_1234);
+	clks[MPC512x_CLK_MBX_3D_UG] = mpc512x_clk_factor("mbx-3d-ug", "mbx-ug",
+							 1, 1);
+	clks[MPC512x_CLK_PCI_UG] = mpc512x_clk_divtable("pci-ug", "csb",
+							&clkregs->scfr1, 20, 3,
+							divtab_2346);
+	clks[MPC512x_CLK_NFC_UG] = mpc512x_clk_divtable("nfc-ug", "ips",
+							&clkregs->scfr1, 8, 3,
+							divtab_1234);
+	clks[MPC512x_CLK_LPC_UG] = mpc512x_clk_divtable("lpc-ug", "ips",
+							&clkregs->scfr1, 11, 3,
+							divtab_1234);
+
+	clks[MPC512x_CLK_LPC] = mpc512x_clk_gated("lpc", "lpc-ug",
+						  &clkregs->sccr1, 30);
+	clks[MPC512x_CLK_NFC] = mpc512x_clk_gated("nfc", "nfc-ug",
+						  &clkregs->sccr1, 29);
+	clks[MPC512x_CLK_PATA] = mpc512x_clk_gated("pata", "ips",
+						   &clkregs->sccr1, 28);
+	mpc512x_clk_setup_mclks(mclk_psc_data, ARRAY_SIZE(mclk_psc_data));
+	clks[MPC512x_CLK_PSC_FIFO] = mpc512x_clk_gated("psc-fifo", "ips",
+						       &clkregs->sccr1, 15);
+	clks[MPC512x_CLK_SATA] = mpc512x_clk_gated("sata", "ips",
+						   &clkregs->sccr1, 14);
+	clks[MPC512x_CLK_FEC] = mpc512x_clk_gated("fec", "ips",
+						  &clkregs->sccr1, 13);
+	clks[MPC512x_CLK_PCI] = mpc512x_clk_gated("pci", "pci-ug",
+						  &clkregs->sccr1, 11);
+	clks[MPC512x_CLK_DDR] = mpc512x_clk_gated("ddr", "ddr-ug",
+						  &clkregs->sccr1, 10);
+
+	clks[MPC512x_CLK_DIU] = mpc512x_clk_gated("diu", "diu-ug",
+						  &clkregs->sccr2, 31);
+	clks[MPC512x_CLK_AXE] = mpc512x_clk_gated("axe", "csb",
+						  &clkregs->sccr2, 30);
+	clks[MPC512x_CLK_MEM] = mpc512x_clk_gated("mem", "ips",
+						  &clkregs->sccr2, 29);
+	clks[MPC512x_CLK_USB1] = mpc512x_clk_gated("usb1", "csb",
+						   &clkregs->sccr2, 28);
+	clks[MPC512x_CLK_USB2] = mpc512x_clk_gated("usb2", "csb",
+						   &clkregs->sccr2, 27);
+	clks[MPC512x_CLK_I2C] = mpc512x_clk_gated("i2c", "ips",
+						  &clkregs->sccr2, 26);
+	mpc512x_clk_setup_mclks(mclk_mscan_data, ARRAY_SIZE(mclk_mscan_data));
+	clks[MPC512x_CLK_SDHC] = mpc512x_clk_gated("sdhc", "sdhc-ug",
+						   &clkregs->sccr2, 24);
+	mpc512x_clk_setup_mclks(mclk_spdif_data, ARRAY_SIZE(mclk_spdif_data));
+	clks[MPC512x_CLK_MBX_BUS] = mpc512x_clk_gated("mbx-bus", "mbx-bus-ug",
+						      &clkregs->sccr2, 22);
+	clks[MPC512x_CLK_MBX] = mpc512x_clk_gated("mbx", "mbx-ug",
+						  &clkregs->sccr2, 21);
+	clks[MPC512x_CLK_MBX_3D] = mpc512x_clk_gated("mbx-3d", "mbx-3d-ug",
+						     &clkregs->sccr2, 20);
+	clks[MPC512x_CLK_IIM] = mpc512x_clk_gated("iim", "csb",
+						  &clkregs->sccr2, 19);
+	clks[MPC512x_CLK_VIU] = mpc512x_clk_gated("viu", "csb",
+						  &clkregs->sccr2, 18);
+	clks[MPC512x_CLK_SDHC_2] = mpc512x_clk_gated("sdhc-2", "sdhc-ug",
+						     &clkregs->sccr2, 17);
+
+	/*
+	 * externally provided clocks (when implemented in hardware,
+	 * device tree may specify values which otherwise were unknown)
+	 */
+	freq = get_freq_from_dt("psc_mclk_in");
+	if (!freq)
+		freq = 25000000;
+	clks[MPC512x_CLK_PSC_MCLK_IN] = mpc512x_clk_fixed("psc_mclk_in", freq);
+	freq = get_freq_from_dt("spdif_tx_in");
+	clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed("spdif_tx_in", freq);
+	freq = get_freq_from_dt("spdif_rx_in");
+	clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed("spdif_rx_in", freq);
+
+	/* fixed frequency for AC97, always 24.567MHz */
+	clks[MPC512x_CLK_AC97] = mpc512x_clk_fixed("ac97", 24567000);
+
+	pr_debug("clock tree setup complete\n");
+	freq = clk_get_rate(clks[MPC512x_CLK_E300]);
+	pr_debug("derived PPC freq [%d]\n", freq);
+	freq = clk_get_rate(clks[MPC512x_CLK_IPS]);
+	pr_debug("derived IPS freq [%d]\n", freq);
+	freq = clk_get_rate(clks[MPC512x_CLK_LPC]);
+	pr_debug("derived LPC freq [%d]\n", freq);
+
+	/* enable some of the clocks here unconditionally because ... */
+	pr_debug("automatically enabling some clocks\n");
+	/* some are essential yet never get claimed by any driver */
+	clk_prepare_enable(clks[MPC512x_CLK_DUMMY]);
+	clk_prepare_enable(clks[MPC512x_CLK_E300]);	/* PowerPC CPU */
+	clk_prepare_enable(clks[MPC512x_CLK_DDR]);	/* DRAM */
+	clk_prepare_enable(clks[MPC512x_CLK_MEM]);	/* SRAM */
+	clk_prepare_enable(clks[MPC512x_CLK_IPS]);	/* SoC periph */
+	clk_prepare_enable(clks[MPC512x_CLK_LPC]);	/* boot media */
+	/* some are required yet no dependencies were declared */
+	clk_prepare_enable(clks[MPC512x_CLK_PSC_FIFO]);
+	/* some are not yet acquired by their respective drivers */
+	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
+	clk_prepare_enable(clks[MPC512x_CLK_FEC]);	/* network, NFS */
+	clk_prepare_enable(clks[MPC512x_CLK_DIU]);	/* display */
+	clk_prepare_enable(clks[MPC512x_CLK_I2C]);
+	/*
+	 * some have their individual clock subtree with separate clock
+	 * items and their individual enable counters, yet share a
+	 * common gate (refer to the same register location) while the
+	 * common clock driver code is not aware of the fact and the
+	 * platform's code doesn't provide specific support either
+	 *
+	 * what might happen is that e.g. enabling two MSCAN clock items
+	 * and disabling one of them will disable the common gate and
+	 * thus break the other MSCAN clock as well
+	 */
+	clk_prepare_enable(clks[MPC512x_CLK_MSCAN0_MCLK]);
+	clk_prepare_enable(clks[MPC512x_CLK_MSCAN1_MCLK]);
+	clk_prepare_enable(clks[MPC512x_CLK_MSCAN2_MCLK]);
+	clk_prepare_enable(clks[MPC512x_CLK_MSCAN3_MCLK]);
+}
+
+/*
+ * registers the set of public clocks (those listed in the dt-bindings/
+ * header file) for OF lookups, keeps the intermediates private to us
+ */
+static void mpc5121_clk_register_of_provider(struct device_node *np)
+{
+	clk_data.clks = clks;
+	clk_data.clk_num = MPC512x_CLK_LAST_PUBLIC + 1;	/* _not_ ARRAY_SIZE() */
+	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
+}
+
+int __init mpc5121_clk_init(void)
+{
+	struct device_node *clk_np;
+	int busfreq;
+
+	/* map the clock control registers */
+	clk_np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-clock");
+	if (!clk_np)
+		return -ENODEV;
+	clkregs = of_iomap(clk_np, 0);
+	WARN_ON(!clkregs);
+
+	/* invalidate all not yet registered clock slots */
+	mpc512x_clk_preset_data();
+
+	/*
+	 * have the device tree scanned for "fixed-clock" nodes (which
+	 * includes the oscillator node if the board's DT provides one)
+	 */
+	of_clk_init(NULL);
+
+	/*
+	 * add a dummy clock for those situations where a clock spec is
+	 * required yet no real clock is involved
+	 */
+	clks[MPC512x_CLK_DUMMY] = mpc512x_clk_fixed("dummy", 0);
+
+	/*
+	 * have all the real nodes in the clock tree populated from REF
+	 * down to all leaves, either starting from the OSC node or from
+	 * a REF root that was created from the IPS bus clock input
+	 */
+	busfreq = get_freq_from_dt("bus-frequency");
+	mpc512x_clk_setup_clock_tree(busfreq);
+
+	/* register as an OF clock provider */
+	mpc5121_clk_register_of_provider(clk_np);
+
+	return 0;
+}
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index c4f7799..7f8fc64 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -497,6 +497,20 @@ static inline const char *of_clk_get_parent_name(struct device_node *np,
  * for improved portability across platforms
  */
 
+#if IS_ENABLED(CONFIG_PPC)
+
+static inline u32 clk_readl(u32 __iomem *reg)
+{
+	return ioread32be(reg);
+}
+
+static inline void clk_writel(u32 val, u32 __iomem *reg)
+{
+	iowrite32be(val, reg);
+}
+
+#else	/* platform dependent I/O accessors */
+
 static inline u32 clk_readl(u32 __iomem *reg)
 {
 	return readl(reg);
@@ -507,5 +521,7 @@ static inline void clk_writel(u32 val, u32 __iomem *reg)
 	writel(val, reg);
 }
 
+#endif	/* platform dependent I/O accessors */
+
 #endif /* CONFIG_COMMON_CLK */
 #endif /* CLK_PROVIDER_H */
-- 
1.7.10.4



From swarren at wwwdotorg.org  Thu Jul 18 13:06:51 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 11:06:51 -0600
Subject: [PATCH] reset: allow drivers to request probe deferral
In-Reply-To: <1374148653-14009-1-git-send-email-p.zabel@pengutronix.de>
References: <1374148653-14009-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <51E820AB.1040008@wwwdotorg.org>

On 07/18/2013 05:57 AM, Philipp Zabel wrote:
> If the requested reset controller is not yet available, have reset_control_get
> and device_reset return -EPROBE_DEFER so the driver can decide to request
> probe deferral.

Reviewed-by: Stephen Warren <swarren at nvidia.com>


From linux at arm.linux.org.uk  Thu Jul 18 13:08:25 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Jul 2013 18:08:25 +0100
Subject: [PATCH 1/3] dmaengine: add dma_get_slave_sg_limits()
In-Reply-To: <1374166001-31340-2-git-send-email-joelf@ti.com>
References: <1374166001-31340-1-git-send-email-joelf@ti.com>
 <1374166001-31340-2-git-send-email-joelf@ti.com>
Message-ID: <20130718170825.GZ21614@n2100.arm.linux.org.uk>

On Thu, Jul 18, 2013 at 11:46:39AM -0500, Joel Fernandes wrote:
> The API is optionally implemented by dmaengine drivers and when
> unimplemented will return a NULL pointer. A client driver using
> this API provides the required dma channel, address width, and
> burst size of the transfer. dma_get_slave_sg_limits() returns an
> SG limits structure with the maximum number and size of SG segments
> that the given channel can handle.

Please look at what's already in struct device:

struct device {
...
        struct device_dma_parameters *dma_parms;
...
};

This provides:

struct device_dma_parameters {
        /*
         * a low level driver may set these to teach IOMMU code about
         * sg limitations.
         */
        unsigned int max_segment_size;
        unsigned long segment_boundary_mask;
};

Now, these are helpfully accessed via:

dma_get_max_seg_size(dev)
dma_set_max_seg_size(dev)
dma_get_seg_boundary(dev)
dma_set_seg_boundary(dev, mask)

Drivers already use these to work out how to construct the scatterlist
before passing it to the DMA API, which means that they should also be
used when creating a scatterlist for the DMA engine (think about it -
you have to use the DMA API to map the buffers for the DMA engine too.)

So, we already have two properties defined on a per-device basis: the
maximum size of a scatterlist segment, and the boundary over which any
segment must not cross.

The former ties up with your max_seg_len() property, though arguably it
may depend on the DMA engine access size.  The problem with implementing
this new API though is that the subsystems (such as SCSI) which already
use dma_get_max_seg_size() will be at odds with what is possible via the
DMA engine.

I strongly suggest using the infrastructure at device level and not
implementing some private DMA engine API to convey this information.

As for the maximum number of scatterlist entries, really that's a bug in
the DMA engine implementations if they can't accept arbitary lengths.
I've created DMA engine drivers for implementations where you have to
program each segment individually, ones which can have the current and
next segments, as well as those which can walk a list.  Provided you get
informed of a transfer being completed, there really is no reason for a
DMA engine driver to limit the number of scatterlist entries that it
will accept.


From julien.grall at linaro.org  Thu Jul 18 13:18:48 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Thu, 18 Jul 2013 18:18:48 +0100
Subject: [PATCH] xen/arm: enable PV control for ARM
In-Reply-To: <alpine.DEB.2.02.1307171435000.8258@kaball.uk.xensource.com>
References: <1373898219-15713-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307171435000.8258@kaball.uk.xensource.com>
Message-ID: <CAPnVf8z1YQsRsznag-Z+mnMTu9JxgWptYcDfoswzE-x0aJCDwg@mail.gmail.com>

On 17 July 2013 14:40, Stefano Stabellini
<stefano.stabellini at eu.citrix.com> wrote:
> On Mon, 15 Jul 2013, Julien Grall wrote:
>> Enable power management from the toolstack for ARM guest.
>>
>> Signed-off-by: Julien Grall <julien.grall at linaro.org>
>
> Considering that now we support both ARM and ARM64, could you please
> add an ifneq ($(CONFIG_ARM64),y) too around cpu_hotplug.o, since you are
> at it?

Yes. I will resend the patch.

-- 
Julien Grall


From julien.grall at linaro.org  Thu Jul 18 13:20:52 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Thu, 18 Jul 2013 18:20:52 +0100
Subject: [Xen-devel] [PATCH] xen/arm: disable cpuidle when linux is
 running as dom0
In-Reply-To: <alpine.DEB.2.02.1307171426300.8258@kaball.uk.xensource.com>
References: <1373898101-15633-1-git-send-email-julien.grall@linaro.org>
 <20130715152532.GC5774@phenom.dumpdata.com>
 <alpine.DEB.2.02.1307171426300.8258@kaball.uk.xensource.com>
Message-ID: <CAPnVf8xuQJpXv+D8QNqhdz=Pm8rvbWA-U0T-ZdC3Mye-KeLdGA@mail.gmail.com>

On 17 July 2013 14:28, Stefano Stabellini
<stefano.stabellini at eu.citrix.com> wrote:
> On Mon, 15 Jul 2013, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jul 15, 2013 at 03:21:41PM +0100, Julien Grall wrote:
>> > When linux is running as dom0, Xen doesn't show the physical cpu but a
>> > virtual CPU.
>> > On some ARM SOC (for instance the exynos 5250), linux registers callbacks
>> > for cpuidle. When these callbacks are called, they will modify
>> > directly the physical cpu not the virtual one.
>> It can impact the whole board
>> > instead of dom0.
>
> Certainly this is something that should be fixed at the hypervisor level
> too. However I agree that Linux should try to avoid doing that when
> running on Xen.
>
>
>
>> Should you also call disable_cpufreq() ?
>
> Sounds like a good idea.
> Julien, could you add that to this patch?

I have checked with both the Arndale and Versatile Express without any issue.
I will resend this patch with disable_cpufreq().

-- 
Julien Grall


From will.deacon at arm.com  Thu Jul 18 13:21:59 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 18 Jul 2013 18:21:59 +0100
Subject: [PATCH] ARM: locks: remove opencoded #16 for ticket shift
In-Reply-To: <alpine.LFD.2.03.1307170952580.14924@syhkavp.arg>
References: <1373894879-30559-1-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307170952580.14924@syhkavp.arg>
Message-ID: <20130718172159.GC9837@mudshark.cambridge.arm.com>

On Wed, Jul 17, 2013 at 02:56:59PM +0100, Nicolas Pitre wrote:
> On Mon, 15 Jul 2013, Will Deacon wrote:
> 
> > The ticket width of our spinlocks is defined by TICKET_SHIFT, so remove
> > the opencoded #16 from the trylock implementation.
> > 
> > Signed-off-by: Will Deacon <will.deacon at arm.com>
> 
> This is pointless.

I disagree (see below).

> >  		"	ldrex	%0, [%3]\n"
> >  		"	mov	%2, #0\n"
> > -		"	subs	%1, %0, %0, ror #16\n"
> 
> Any value other than 16 would break that code.  You'd rather ensure it 
> never gets defined to anything else.

There are two aspects to the ticket lock:

  1. The size of each ticket
  2. The location of the next ticket within the 32-bit lock word

TICKET_SHIFT actually defines (2) and could be 0 or 16, hence why I was
making this small cosmetic change. I admit that the naming isn't very good
and I should change the commit message to reflect what's actually going on.

Cheers,

Will


From stefano.stabellini at eu.citrix.com  Thu Jul 18 13:24:11 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 18 Jul 2013 18:24:11 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabledo
In-Reply-To: <20130718165007.GA24642@n2100.arm.linux.org.uk>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
 <20130717151148.GM24642@n2100.arm.linux.org.uk> <51E81B39.2030805@linaro.org>
 <20130718165007.GA24642@n2100.arm.linux.org.uk>
Message-ID: <alpine.DEB.2.02.1307181755371.8258@kaball.uk.xensource.com>

On Thu, 18 Jul 2013, Russell King - ARM Linux wrote:
> On Thu, Jul 18, 2013 at 05:43:37PM +0100, Julien Grall wrote:
> > When Xen will boot, it will use one UART, given by the user, to be able
> > to log its information. Xen will not map the UART region and the IRQ to
> > dom0. Of course it will not be present in the device tree either. So if
> > Linux tries to access to this memory region, it will crash.
> > 
> > When Linux will boot as dom0, it will either use an hvc console or
> > another UART.
> > 
> > In case of multi-platform environments, there is no issue because when
> > CONFIG_DEBUG_UNCOMPRESS is disabled.
> > 
> > Now, in non-multiplatform environment, the decompressor will use a
> > pre-defined UART. This UART may be already used by Xen and Linux will
> > abort at the first access.
> > 
> > I think, the decompressor should be able to detect if the UART exists
> > (I'm not sure it's possible) or disabled at compile time uncompress log.
> > 
> > Do you have any better ideas?
> 
> Let me get this straight.
> 
> 1. You want to run an _existing_ platforms kernel under Xen, where the
>    platform assumes that it has various devices at various locations,
>    and will make direct accesses to those devices.
> 
> 2. You don't want to provide some of those devices, and you arrange for
>    those unprovided devices to fault.
> 
> Excuse me if I think that's really silly.

Unfortunately not all the platforms are available on multiplatform
kernels.
Also by the same argument, we wouldn't need device tree on
non-multiplatform kernels because we could hardcode almost anything.


> Lastly, aren't all ARMv7 kernels (therefore Xen supporting kernels)
> supposed to be part of the multiplatform kernel stuff now?

Most of them, yes. However some of them, like exynos5250, are not yet.


From nicolas.pitre at linaro.org  Thu Jul 18 13:24:48 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Jul 2013 13:24:48 -0400 (EDT)
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <20130718150408.GB2655@localhost.localdomain>
References: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
 <1374118116-16836-2-git-send-email-nicolas.pitre@linaro.org>
 <20130718150408.GB2655@localhost.localdomain>
Message-ID: <alpine.LFD.2.03.1307181231510.14924@syhkavp.arg>

[ added Russell for his opinion on the patch below ]

On Thu, 18 Jul 2013, Dave Martin wrote:

> On Wed, Jul 17, 2013 at 11:28:33PM -0400, Nicolas Pitre wrote:
> > Unlike real A15/A7's, the RTSM simulation doesn't appear to hit the
> > cache when the CTRL.C bit is cleared.  Let's ensure there is no memory
> > access within the disable and flush cache sequence, including to the
> > stack.
> > 
> > Signed-off-by: Nicolas Pitre <nico at linaro.org>
> > ---
> >  arch/arm/mach-vexpress/dcscb.c | 58 +++++++++++++++++++++++++++---------------
> >  1 file changed, 37 insertions(+), 21 deletions(-)
> > 
> > diff --git a/arch/arm/mach-vexpress/dcscb.c b/arch/arm/mach-vexpress/dcscb.c
> > index 16d57a8a9d..9f01c04d58 100644
> > --- a/arch/arm/mach-vexpress/dcscb.c
> > +++ b/arch/arm/mach-vexpress/dcscb.c
> > @@ -136,14 +136,29 @@ static void dcscb_power_down(void)
> >  		/*
> >  		 * Flush all cache levels for this cluster.
> >  		 *
> > -		 * A15/A7 can hit in the cache with SCTLR.C=0, so we don't need
> > -		 * a preliminary flush here for those CPUs.  At least, that's
> > -		 * the theory -- without the extra flush, Linux explodes on
> > -		 * RTSM (to be investigated).
> > +		 * To do so we do:
> > +		 * - Clear the CTLR.C bit to prevent further cache allocations
> 
> SCTLR

Fixed.

> > +		 * - Flush the whole cache
> > +		 * - Disable local coherency by clearing the ACTLR "SMP" bit
> > +		 *
> > +		 * Let's do it in the safest possible way i.e. with
> > +		 * no memory access within the following sequence
> > +		 * including the stack.
> >  		 */
> > -		flush_cache_all();
> > -		set_cr(get_cr() & ~CR_C);
> > -		flush_cache_all();
> > +		asm volatile(
> > +		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
> > +		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
> > +		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
> > +		"isb	\n\t"
> > +		"bl	v7_flush_dcache_all \n\t"
> > +		"clrex	\n\t"
> > +		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
> > +		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
> > +		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
> > +		"isb	\n\t"
> > +		"dsb	"
> > +		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
> > +		      "r9","r10","r11","lr","memory");
> 
> Along with the TC2 support, we now have 4 copies of this code sequence.
> 
> This is basically the A15/A7 native "exit coherency and flash and
> disable some levels of dcache" operation, whose only parameter is which
> cache levels to flush.
> 
> That's a big mouthful -- we can probably come up with a better name --
> but we've pretty much concluded that there is no way to break this
> operation apart into bitesize pieces.  Nonetheless, any native
> powerdown sequence for these processors will need to do this, or
> something closely related.
> 
> Is it worth consolidating, or is that premature?

It is probably worth consolidating.

What about this:

commit 390cf8b9b83eeeebdfef51912f5003a6a9b84115
Author: Nicolas Pitre <nicolas.pitre at linaro.org>
Date:   Thu Jul 18 13:12:48 2013 -0400

    ARM: cacheflush: consolidate single-CPU ARMv7 cache disabling code
    
    This code is becoming duplicated in many places.  So let's consolidate
    it into a handy macro that is known to be right and available for reuse.
    
    Signed-off-by: Nicolas Pitre <nico at linaro.org>

diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
index 17d0ae8672..8a76933e80 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -436,4 +436,33 @@ static inline void __sync_cache_range_r(volatile void *p, size_t size)
 #define sync_cache_w(ptr) __sync_cache_range_w(ptr, sizeof *(ptr))
 #define sync_cache_r(ptr) __sync_cache_range_r(ptr, sizeof *(ptr))
 
+/*
+ * Disabling cache access for one CPU in an ARMv7 SMP system is tricky.
+ * To do so we must:
+ *
+ * - Clear the SCTLR.C bit to prevent further cache allocations
+ * - Flush the desired level of cache
+ * - Clear the ACTLR "SMP" bit to disable local coherency
+ *
+ * ... and so without any intervening memory access in between those steps,
+ * not even to the stack.
+ *
+ * The clobber list is dictated by the call to v7_flush_dcache_*.
+ */
+#define v7_disable_flush_cache(level) \
+	asm volatile( \
+	"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t" \
+	"bic	r0, r0, #"__stringify(CR_C)" \n\t" \
+	"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t" \
+	"isb	\n\t" \
+	"bl	v7_flush_dcache_"__stringify(level)" \n\t" \
+	"clrex	\n\t" \
+	"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t" \
+	"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t" \
+	"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t" \
+	"isb	\n\t" \
+	"dsb	" \
+	: : : "r0","r1","r2","r3","r4","r5","r6","r7", \
+	      "r9","r10","r11","lr","memory" )
+
 #endif
diff --git a/arch/arm/mach-vexpress/dcscb.c b/arch/arm/mach-vexpress/dcscb.c
index 85fffa702f..145d8237d5 100644
--- a/arch/arm/mach-vexpress/dcscb.c
+++ b/arch/arm/mach-vexpress/dcscb.c
@@ -133,32 +133,8 @@ static void dcscb_power_down(void)
 	if (last_man && __mcpm_outbound_enter_critical(cpu, cluster)) {
 		arch_spin_unlock(&dcscb_lock);
 
-		/*
-		 * Flush all cache levels for this cluster.
-		 *
-		 * To do so we do:
-		 * - Clear the SCTLR.C bit to prevent further cache allocations
-		 * - Flush the whole cache
-		 * - Clear the ACTLR "SMP" bit to disable local coherency
-		 *
-		 * Let's do it in the safest possible way i.e. with
-		 * no memory access within the following sequence
-		 * including to the stack.
-		 */
-		asm volatile(
-		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
-		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
-		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
-		"isb	\n\t"
-		"bl	v7_flush_dcache_all \n\t"
-		"clrex	\n\t"
-		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
-		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
-		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
-		"isb	\n\t"
-		"dsb	"
-		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
-		      "r9","r10","r11","lr","memory");
+		/* Flush all cache levels for this cluster. */
+		v7_disable_flush_cache(all);
 
 		/*
 		 * This is a harmless no-op.  On platforms with a real
@@ -177,24 +153,8 @@ static void dcscb_power_down(void)
 	} else {
 		arch_spin_unlock(&dcscb_lock);
 
-		/*
-		 * Flush the local CPU cache.
-		 * Let's do it in the safest possible way as above.
-		 */
-		asm volatile(
-		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
-		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
-		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
-		"isb	\n\t"
-		"bl	v7_flush_dcache_louis \n\t"
-		"clrex	\n\t"
-		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
-		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
-		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
-		"isb	\n\t"
-		"dsb	"
-		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
-		      "r9","r10","r11","lr","memory");
+		/* Flush the local CPU cache. */
+		v7_disable_flush_cache(louis);
 	}
 
 	__mcpm_cpu_down(cpu, cluster);
diff --git a/arch/arm/mach-vexpress/tc2_pm.c b/arch/arm/mach-vexpress/tc2_pm.c
index dfb55d45b6..fd8bc2d931 100644
--- a/arch/arm/mach-vexpress/tc2_pm.c
+++ b/arch/arm/mach-vexpress/tc2_pm.c
@@ -134,26 +134,7 @@ static void tc2_pm_down(u64 residency)
 			: : "r" (0x400) );
 		}
 
-		/*
-		 * We need to disable and flush the whole (L1 and L2) cache.
-		 * Let's do it in the safest possible way i.e. with
-		 * no memory access within the following sequence
-		 * including the stack.
-		 */
-		asm volatile(
-		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
-		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
-		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
-		"isb	\n\t"
-		"bl	v7_flush_dcache_all \n\t"
-		"clrex	\n\t"
-		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
-		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
-		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
-		"isb	\n\t"
-		"dsb	"
-		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
-		      "r9","r10","r11","lr","memory");
+		v7_disable_flush_cache(all);
 
 		cci_disable_port_by_cpu(mpidr);
 
@@ -169,24 +150,7 @@ static void tc2_pm_down(u64 residency)
 
 		arch_spin_unlock(&tc2_pm_lock);
 
-		/*
-		 * We need to disable and flush only the L1 cache.
-		 * Let's do it in the safest possible way as above.
-		 */
-		asm volatile(
-		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
-		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
-		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
-		"isb	\n\t"
-		"bl	v7_flush_dcache_louis \n\t"
-		"clrex	\n\t"
-		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
-		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
-		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
-		"isb	\n\t"
-		"dsb	"
-		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
-		      "r9","r10","r11","lr","memory");
+		v7_disable_flush_cache(louis);
 	}
 
 	__mcpm_cpu_down(cpu, cluster);


From nicolas.pitre at linaro.org  Thu Jul 18 13:47:22 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Jul 2013 13:47:22 -0400 (EDT)
Subject: [PATCH v1 05/24] clk: wrap I/O access for improved portability
In-Reply-To: <20130718091735.GW24642@n2100.arm.linux.org.uk>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1373914074-20889-6-git-send-email-gsi@denx.de>
 <20130715193829.GS14452@pengutronix.de>
 <20130718070402.GO7080@book.gsilab.sittig.org>
 <20130718091735.GW24642@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1307181330520.14924@syhkavp.arg>

On Thu, 18 Jul 2013, Russell King - ARM Linux wrote:

> 1. clk_get() and clk_put() are NOT part of the common clock API.
>    They're separate - they're part of the clk API, and the infrastructure
>    behind that is clkdev, which is a separately owned thing (by me.)
> 
> 2. The "contract" of the clk API is defined by the clk API, not by some
>    random implementation like the common clock API.  The clk API is
>    maintained by myself, and is described in include/linux/clk.h
> 
> 3. clk_prepare() and clk_unprepare() are functions MUST only be called
>    from contexts where sleeping is permitted.  These functions MAY sleep
>    for whatever reason they require to, and as long as they require to.
>    (This is the whole reason these two functions were created in the
>    first place.)
> 
> 4. clk_enable() and clk_disable() MAY be called from any context, but
>    MUST never sleep.  If you need to talk over a non-atomic bus for these,
>    then these functions should be no-ops, and the code which does that
>    must be executed from the clk_prepare()/clk_unprepare() operations.

Could the above be included in some form in Documentation/clk.txt (this 
is likely one of the first location people look for information) and 
elsewhere if appropriate please?

A *lot* of people are confused by the prepare-enable-disable-unprepare 
sequence and when I try to find some rational for the prepare/enable 
split I can only direct them to mail archive posts since this is nowhere 
to be found in the kernel.

The comments in include/linux/clk.h, while correct, are very terse and 
don't provide any insight to the reason why there is a split in the API.

The content of Documentation/clk.txt does refer to prepare and enable 
(and their counterparts) but again doesn't provide any clue about the 
reason for their existence.

Since there've been several good posts with usage example now buried 
into list archives, I think this would go a long way helping people get 
it right if those were part of the kernel documentation as well.


Nicolas


From nicolas.pitre at linaro.org  Thu Jul 18 13:53:06 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Jul 2013 13:53:06 -0400 (EDT)
Subject: [PATCH] ARM: locks: remove opencoded #16 for ticket shift
In-Reply-To: <20130718172159.GC9837@mudshark.cambridge.arm.com>
References: <1373894879-30559-1-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307170952580.14924@syhkavp.arg>
 <20130718172159.GC9837@mudshark.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1307181350440.14924@syhkavp.arg>

On Thu, 18 Jul 2013, Will Deacon wrote:

> On Wed, Jul 17, 2013 at 02:56:59PM +0100, Nicolas Pitre wrote:
> > On Mon, 15 Jul 2013, Will Deacon wrote:
> > 
> > > The ticket width of our spinlocks is defined by TICKET_SHIFT, so remove
> > > the opencoded #16 from the trylock implementation.
> > > 
> > > Signed-off-by: Will Deacon <will.deacon at arm.com>
> > 
> > This is pointless.
> 
> I disagree (see below).
> 
> > >  		"	ldrex	%0, [%3]\n"
> > >  		"	mov	%2, #0\n"
> > > -		"	subs	%1, %0, %0, ror #16\n"
> > 
> > Any value other than 16 would break that code.  You'd rather ensure it 
> > never gets defined to anything else.
> 
> There are two aspects to the ticket lock:
> 
>   1. The size of each ticket
>   2. The location of the next ticket within the 32-bit lock word
> 
> TICKET_SHIFT actually defines (2) and could be 0 or 16, hence why I was
> making this small cosmetic change.

Doesn't matter where the location of the next ticket is.  Whether it is 
0 or 16, for the above code to work, it *must* always perform a ror #16.  
Hence tying the ror constant with TICKET_SHIFT is wrong.


Nicolas


From Dave.Martin at arm.com  Thu Jul 18 14:03:23 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Thu, 18 Jul 2013 19:03:23 +0100
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <alpine.LFD.2.03.1307181231510.14924@syhkavp.arg>
References: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
 <1374118116-16836-2-git-send-email-nicolas.pitre@linaro.org>
 <20130718150408.GB2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181231510.14924@syhkavp.arg>
Message-ID: <20130718180323.GC2655@localhost.localdomain>

On Thu, Jul 18, 2013 at 01:24:48PM -0400, Nicolas Pitre wrote:
> [ added Russell for his opinion on the patch below ]

[...]

> commit 390cf8b9b83eeeebdfef51912f5003a6a9b84115
> Author: Nicolas Pitre <nicolas.pitre at linaro.org>
> Date:   Thu Jul 18 13:12:48 2013 -0400
> 
>     ARM: cacheflush: consolidate single-CPU ARMv7 cache disabling code
>     
>     This code is becoming duplicated in many places.  So let's consolidate
>     it into a handy macro that is known to be right and available for reuse.
>     
>     Signed-off-by: Nicolas Pitre <nico at linaro.org>
> 
> diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
> index 17d0ae8672..8a76933e80 100644
> --- a/arch/arm/include/asm/cacheflush.h
> +++ b/arch/arm/include/asm/cacheflush.h
> @@ -436,4 +436,33 @@ static inline void __sync_cache_range_r(volatile void *p, size_t size)
>  #define sync_cache_w(ptr) __sync_cache_range_w(ptr, sizeof *(ptr))
>  #define sync_cache_r(ptr) __sync_cache_range_r(ptr, sizeof *(ptr))
>  
> +/*
> + * Disabling cache access for one CPU in an ARMv7 SMP system is tricky.
> + * To do so we must:
> + *
> + * - Clear the SCTLR.C bit to prevent further cache allocations
> + * - Flush the desired level of cache
> + * - Clear the ACTLR "SMP" bit to disable local coherency
> + *
> + * ... and so without any intervening memory access in between those steps,
> + * not even to the stack.
> + *
> + * The clobber list is dictated by the call to v7_flush_dcache_*.
> + */
> +#define v7_disable_flush_cache(level) \
> +	asm volatile( \
> +	"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t" \
> +	"bic	r0, r0, #"__stringify(CR_C)" \n\t" \
> +	"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t" \
> +	"isb	\n\t" \
> +	"bl	v7_flush_dcache_"__stringify(level)" \n\t" \
> +	"clrex	\n\t" \
> +	"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t" \
> +	"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t" \
> +	"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t" \
> +	"isb	\n\t" \
> +	"dsb	" \
> +	: : : "r0","r1","r2","r3","r4","r5","r6","r7", \
> +	      "r9","r10","r11","lr","memory" )
> +
>  #endif

That's roughly what I had in mind, though it might belong somewhere more
obscure than cacheflush.h(?)

"disable_flush_cache" sounds a too general-purpose for my liking.

"v7" isn't really right because we touch the ACTLR.  This only works
on certain CPUs and when Linux is running Secure.  Maybe saying "a15"
instead of "a7" is reasonable, since a7 is supposed to be an a15
workalike in most places.

I had other names in mind, like "coherency_exit" or "cache_exit".
Those are not very intelligible, but that might at least make people
pause and think before blindly using it.

Really, it's for the very specific purpose of doing native low-level
powerdown of an individual CPU in a multiprocessor system, when the
platform as a whole is not being shut down, on A15 or A7 (+ possibly
other future v7 CPUs)... it's not suitable for any other situation.
Even kexec probably shouldn't be disabling the SMP bit.

Cheers
---Dave



From swarren at wwwdotorg.org  Thu Jul 18 14:11:07 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 12:11:07 -0600
Subject: Issue with gpio and pinmux
In-Reply-To: <51E667BC.3070804@parrot.com>
References: <51E667BC.3070804@parrot.com>
Message-ID: <51E82FBB.1080905@wwwdotorg.org>

On 07/17/2013 03:45 AM, Damien Riegel wrote:
> Hi,
> 
> 
> In our ARM-based SoC, we can multiplex up to 4 functions on each pin,
> but we have an issue when using a pin as a gpio: it can still be muxed
> as another function.

It's a good idea to Cc the maintainers of the subsystem you're asking
questions about. See the MAINTAINERS file in the kernel source tree for
clues who that is. I've CC'd LinusW here.

When you say "it can still be muxed as another function", I assume you
mean that SW is allowing someone to do that; it's not that your HW
allows this somehow?

> In the gpio driver, we delegate calls to "request" to
> "pinctrl_request_gpio":
> 
> 	static int p7gpio_request(struct gpio_chip *chip, unsigned int offset)
> 	{
> 		return pinctrl_request_gpio(chip->base + offset);
> 	}
> 
> 	static const struct gpio_chip p7gpio_chip_defaults = {
> 		.request            = p7gpio_request,
> 		[...]
> 	};
> 
> pinctrl_request_gpio will result in a call to pin_request, which behaves
> differently if we request a gpio or another function, so at kernel
> level they are not exclusive, but at hardware level they must be.

Yes, that's how pinctrl is implemented right now.

The issue is that some HW muxes groups of pins at a time, so simply
because that group of pins is "claimed" by a mux function, implies
nothing about which specific pins in that group are actually used; some
may actually still be free for usage as a GPIO.

Now obviously that doesn't make a huge amount of sense if your HW muxes
each pin individually, so there are no groups.

The solution here may be one of:

a) Modify pinctrl /not/ to allow both a GPIO and a mux function to claim
a pin *if* the group that contains the pin only contains a single pin.
This is a bit of a hacky special case though; there are other situations
where "dual claiming" shouldn't be allowed, and this doesn't solve those.

b) Ignore the issue; if the system configuration is correct, the issue
won't cause problems in practice, since nothing will be configured to
"dual claim" any pin.

c) Enhance pinctrl with extra information, so it knows which pins in a
group are usable as GPIO even when the group is claimed by a mux
function. The list of pins could theoretically vary per mux function, so
you'd need a table with lookup key (pin group, mux function) and output
data (list of pins that can be "dual claimed"). This would be a complete
solution. If a list wasn't provided, the pinctrl core could assume that
mean no dual claim was allowed.


From balbi at ti.com  Thu Jul 18 14:25:04 2013
From: balbi at ti.com (Felipe Balbi)
Date: Thu, 18 Jul 2013 21:25:04 +0300
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
Message-ID: <20130718182504.GA7497@arwen.pp.htv.fi>

Hi,

On Thu, Jul 18, 2013 at 10:13:48PM +0530, Sricharan R wrote:
> Some socs have a large number of interrupts/dma requests to service
> the needs of its many peripherals and subsystems. All of the
> requests lines from the subsystems are not needed at the same
> time, so they have to be muxed to the controllers appropriately.
> In such places a interrupt/dma controllers are preceded by an
> IRQ/DMA CROSSBAR that provides flexibility in muxing the device
> requests to the controller inputs.
> 
> The Peripheral irq/dma requests are connected to one crossbar's input
> and the output of the crossbar is connected to controller's input
> line. On POR, there are some mappings which are done by default.
> Those peripherals which do not have a mapping on POR, should be configured
> to route its requests using the crossbar.
> 
> The drivers identifies every controller's crossbar as individual devices.
> The mappings can be specified from the DT crossbar nodes and those gets mapped
> during the crossbar device's probe. The mappings can also be specified by adding
> the crossbar lines to the peripheral device nodes and map it with
> crossbar_map/unmap apis.
> 
> Signed-off-by: Sricharan R <r.sricharan at ti.com>

why isn't this done under pinctrl ? If all it does is mux DMA and IRQ
request lines, it should be written as a pinctrl driver no ?

-- 
balbi
-------------- 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/20130718/fc2553ee/attachment.sig>

From shc_work at mail.ru  Thu Jul 18 14:34:52 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Thu, 18 Jul 2013 22:34:52 +0400
Subject: [PATCH 01/10] ARM: clps711x: Remove the special name for the syscon
 driver
In-Reply-To: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374172501-26796-2-git-send-email-shc_work@mail.ru>

This is a partial revert of the patch:
"6597619f9c ARM: clps711x: Add support for SYSCON driver".
No reason to make SYSCON driver name unique to that processor.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/mach-clps711x/devices.c | 2 +-
 drivers/mfd/syscon.c             | 3 ---
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/mach-clps711x/devices.c b/arch/arm/mach-clps711x/devices.c
index 856b81c..fb77d14 100644
--- a/arch/arm/mach-clps711x/devices.c
+++ b/arch/arm/mach-clps711x/devices.c
@@ -57,7 +57,7 @@ static void __init clps711x_add_syscon(void)
 	unsigned i;
 
 	for (i = 0; i < ARRAY_SIZE(clps711x_syscon_res); i++)
-		platform_device_register_simple("clps711x-syscon", i + 1,
+		platform_device_register_simple("syscon", i + 1,
 						&clps711x_syscon_res[i], 1);
 }
 
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index 1a31512..962a6e1 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -159,9 +159,6 @@ static int syscon_probe(struct platform_device *pdev)
 
 static const struct platform_device_id syscon_ids[] = {
 	{ "syscon", },
-#ifdef CONFIG_ARCH_CLPS711X
-	{ "clps711x-syscon", },
-#endif
 	{ }
 };
 
-- 
1.8.1.5



From shc_work at mail.ru  Thu Jul 18 14:34:53 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Thu, 18 Jul 2013 22:34:53 +0400
Subject: [PATCH 02/10] ARM: clps711x: Drop fortunet board support
In-Reply-To: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374172501-26796-3-git-send-email-shc_work@mail.ru>

This patch removes support for the fortunet board.
This board is not maintained by long time and it seems
no one is not using it.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/mach-clps711x/Kconfig          |  3 --
 arch/arm/mach-clps711x/Makefile         |  1 -
 arch/arm/mach-clps711x/board-fortunet.c | 85 ---------------------------------
 3 files changed, 89 deletions(-)
 delete mode 100644 arch/arm/mach-clps711x/board-fortunet.c

diff --git a/arch/arm/mach-clps711x/Kconfig b/arch/arm/mach-clps711x/Kconfig
index 01ad4d4..bea6295 100644
--- a/arch/arm/mach-clps711x/Kconfig
+++ b/arch/arm/mach-clps711x/Kconfig
@@ -33,9 +33,6 @@ config ARCH_P720T
 	  Say Y here if you intend to run this kernel on the ARM Prospector
 	  720T.
 
-config ARCH_FORTUNET
-	bool "FORTUNET"
-
 config EP72XX_ROM_BOOT
 	bool "EP721x/EP731x ROM boot"
 	help
diff --git a/arch/arm/mach-clps711x/Makefile b/arch/arm/mach-clps711x/Makefile
index f30ed2b..f04151e 100644
--- a/arch/arm/mach-clps711x/Makefile
+++ b/arch/arm/mach-clps711x/Makefile
@@ -10,5 +10,4 @@ obj-$(CONFIG_ARCH_AUTCPU12)	+= board-autcpu12.o
 obj-$(CONFIG_ARCH_CDB89712)	+= board-cdb89712.o
 obj-$(CONFIG_ARCH_CLEP7312)	+= board-clep7312.o
 obj-$(CONFIG_ARCH_EDB7211)	+= board-edb7211.o
-obj-$(CONFIG_ARCH_FORTUNET)	+= board-fortunet.o
 obj-$(CONFIG_ARCH_P720T)	+= board-p720t.o
diff --git a/arch/arm/mach-clps711x/board-fortunet.c b/arch/arm/mach-clps711x/board-fortunet.c
deleted file mode 100644
index b1561e3..0000000
--- a/arch/arm/mach-clps711x/board-fortunet.c
+++ /dev/null
@@ -1,85 +0,0 @@
-/*
- *  linux/arch/arm/mach-clps711x/fortunet.c
- *
- *  Derived from linux/arch/arm/mach-integrator/arch.c
- *
- *  Copyright (C) 2000 Deep Blue Solutions Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-#include <linux/types.h>
-#include <linux/init.h>
-#include <linux/initrd.h>
-
-#include <mach/hardware.h>
-#include <asm/setup.h>
-#include <asm/mach-types.h>
-
-#include <asm/mach/arch.h>
-
-#include <asm/memory.h>
-
-#include "common.h"
-
-struct meminfo memmap = {
-	.nr_banks	= 1,
-	.bank		= {
-		{
-			.start	= 0xC0000000,
-			.size	= 0x01000000,
-		},
-	},
-};
-
-typedef struct tag_IMAGE_PARAMS
-{
-	int	ramdisk_ok;
-	int	ramdisk_address;
-	int	ramdisk_size;
-	int	ram_size;
-	int	extra_param_type;
-	int	extra_param_ptr;
-	int	command_line;
-} IMAGE_PARAMS;
-
-#define IMAGE_PARAMS_PHYS	0xC01F0000
-
-static void __init
-fortunet_fixup(struct tag *tags, char **cmdline, struct meminfo *mi)
-{
-	IMAGE_PARAMS *ip = phys_to_virt(IMAGE_PARAMS_PHYS);
-	*cmdline = phys_to_virt(ip->command_line);
-#ifdef CONFIG_BLK_DEV_INITRD
-	if(ip->ramdisk_ok)
-	{
-		initrd_start = __phys_to_virt(ip->ramdisk_address);
-		initrd_end = initrd_start + ip->ramdisk_size;
-	}
-#endif
-	memmap.bank[0].size = ip->ram_size;
-	*mi = memmap;
-}
-
-MACHINE_START(FORTUNET, "ARM-FortuNet")
-	/* Maintainer: FortuNet Inc. */
-	.nr_irqs	= CLPS711X_NR_IRQS,
-	.fixup		= fortunet_fixup,
-	.map_io		= clps711x_map_io,
-	.init_early	= clps711x_init_early,
-	.init_irq	= clps711x_init_irq,
-	.init_time	= clps711x_timer_init,
-	.handle_irq	= clps711x_handle_irq,
-	.restart	= clps711x_restart,
-MACHINE_END
-- 
1.8.1.5



From shc_work at mail.ru  Thu Jul 18 14:34:54 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Thu, 18 Jul 2013 22:34:54 +0400
Subject: [PATCH 03/10] ARM: clps711x: autcpu12: Remove incorrect config
 checking
In-Reply-To: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374172501-26796-4-git-send-email-shc_work@mail.ru>

This patch removes incorrect config symbols checking since these
symbols not contain "CONFIG_" prefix. Anyway, checking is unneeded
here and this patch remove it completely.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/mach-clps711x/board-autcpu12.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/arm/mach-clps711x/board-autcpu12.c b/arch/arm/mach-clps711x/board-autcpu12.c
index 5867aeb..f8d71a8 100644
--- a/arch/arm/mach-clps711x/board-autcpu12.c
+++ b/arch/arm/mach-clps711x/board-autcpu12.c
@@ -259,11 +259,7 @@ static void __init autcpu12_init(void)
 static void __init autcpu12_init_late(void)
 {
 	gpio_request_array(autcpu12_gpios, ARRAY_SIZE(autcpu12_gpios));
-
-	if (IS_ENABLED(MTD_NAND_GPIO) && IS_ENABLED(GPIO_GENERIC_PLATFORM)) {
-		/* We are need both drivers to handle NAND */
-		platform_device_register(&autcpu12_nand_pdev);
-	}
+	platform_device_register(&autcpu12_nand_pdev);
 }
 
 MACHINE_START(AUTCPU12, "autronix autcpu12")
-- 
1.8.1.5



From shc_work at mail.ru  Thu Jul 18 14:34:55 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Thu, 18 Jul 2013 22:34:55 +0400
Subject: [PATCH 04/10] ARM: clps711x: edb7211: Remove extra iotable_init() call
In-Reply-To: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374172501-26796-5-git-send-email-shc_work@mail.ru>

The keyboard driver for the CLPS711X platform is missing, so there
is no need to call iotable_init() for this memory region.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/mach-clps711x/board-edb7211.c | 17 +----------------
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/arch/arm/mach-clps711x/board-edb7211.c b/arch/arm/mach-clps711x/board-edb7211.c
index 9dfb990..fe6184e 100644
--- a/arch/arm/mach-clps711x/board-edb7211.c
+++ b/arch/arm/mach-clps711x/board-edb7211.c
@@ -126,21 +126,6 @@ static struct gpio edb7211_gpios[] __initconst = {
 	{ EDB7211_LCDBL,	GPIOF_OUT_INIT_LOW,	"LCD BACKLIGHT" },
 };
 
-static struct map_desc edb7211_io_desc[] __initdata = {
-	{	/* Memory-mapped extra keyboard row */
-		.virtual	= IO_ADDRESS(EDB7211_EXTKBD_BASE),
-		.pfn		= __phys_to_pfn(EDB7211_EXTKBD_BASE),
-		.length		= SZ_1M,
-		.type		= MT_DEVICE,
-	},
-};
-
-void __init edb7211_map_io(void)
-{
-	clps711x_map_io();
-	iotable_init(edb7211_io_desc, ARRAY_SIZE(edb7211_io_desc));
-}
-
 /* Reserve screen memory region at the start of main system memory. */
 static void __init edb7211_reserve(void)
 {
@@ -195,7 +180,7 @@ MACHINE_START(EDB7211, "CL-EDB7211 (EP7211 eval board)")
 	.nr_irqs	= CLPS711X_NR_IRQS,
 	.fixup		= fixup_edb7211,
 	.reserve	= edb7211_reserve,
-	.map_io		= edb7211_map_io,
+	.map_io		= clps711x_map_io,
 	.init_early	= clps711x_init_early,
 	.init_irq	= clps711x_init_irq,
 	.init_time	= clps711x_timer_init,
-- 
1.8.1.5



From shc_work at mail.ru  Thu Jul 18 14:34:56 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Thu, 18 Jul 2013 22:34:56 +0400
Subject: [PATCH 05/10] ARM: clps711x: Add CLPS711X clk driver
In-Reply-To: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374172501-26796-6-git-send-email-shc_work@mail.ru>

This adds the clock driver for Cirrus Logic CLPS711X series SoCs
using common clock infrastructure.
Designed primarily for migration CLPS711X subarch for multiplatform & DT,
for this as the "OF" and "not-OF" calls implemented.
Additionally, patch removes unnecessary symbol CLKDEV_LOOKUP for CLPS711X
from main ARM Kconfig since this symbol is selected automatically by COMMON_CLK.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 .../devicetree/bindings/clock/clps711x-clock.txt   |  47 +++++++
 arch/arm/Kconfig                                   |   1 -
 drivers/clk/Makefile                               |   1 +
 drivers/clk/clk-clps711x.c                         | 150 +++++++++++++++++++++
 4 files changed, 198 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/clock/clps711x-clock.txt
 create mode 100644 drivers/clk/clk-clps711x.c

diff --git a/Documentation/devicetree/bindings/clock/clps711x-clock.txt b/Documentation/devicetree/bindings/clock/clps711x-clock.txt
new file mode 100644
index 0000000..0fb9fff
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clps711x-clock.txt
@@ -0,0 +1,47 @@
+Device Tree Clock bindings for the Cirrus Logic CLPS711X CPUs
+
+=== Clock subsystem ===
+Required properties:
+- compatible: Should be "cirrus,clps711x-clk"
+- reg: Address of the internal register set
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell. The following table is a full list of
+CLPS711X clocks and IDs.
+
+	Clock		ID
+	------------------
+	dummy		0
+	cpu		1
+	pll		2
+	bus		3
+	timer_hf	4
+	timer_lf	5
+	tc1		6
+	tc2		7
+	spi		8
+	uart		9
+
+=== Clocksource subsystem ===
+Required properties:
+- compatible: Should be "cirrus,clps711x-clocksource"
+- reg: Address of the internal register set
+- clocks: phandle to the source clocks TC1 and TC2
+- interrupts: The interrupt of the TC2 timer
+
+Example:
+
+clks: clks at 80000000 {
+	compatible = "cirrus,clps711x-clk";
+	reg = <0x80000000 0>;
+	#clock-cells = <1>;
+};
+
+timer {
+	compatible = "cirrus,clps711x-clocksource";
+	reg = <0x80000000 0>;
+	clocks = <&clks 6>, <&clks 7>;
+	clock-names = "tc1", "tc2";
+	interrupts = <9>;
+};
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..dfb1e7f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -370,7 +370,6 @@ config ARCH_CLPS711X
 	bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
 	select ARCH_REQUIRE_GPIOLIB
 	select AUTO_ZRELADDR
-	select CLKDEV_LOOKUP
 	select CLKSRC_MMIO
 	select COMMON_CLK
 	select CPU_ARM720T
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4038c2b..a7e9b73 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_COMMON_CLK)	+= clk-composite.o
 
 # SoCs specific
 obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
+obj-$(CONFIG_ARCH_CLPS711X)	+= clk-clps711x.o
 obj-$(CONFIG_ARCH_NOMADIK)	+= clk-nomadik.o
 obj-$(CONFIG_ARCH_HIGHBANK)	+= clk-highbank.o
 obj-$(CONFIG_ARCH_NSPIRE)	+= clk-nspire.o
diff --git a/drivers/clk/clk-clps711x.c b/drivers/clk/clk-clps711x.c
new file mode 100644
index 0000000..662908c
--- /dev/null
+++ b/drivers/clk/clk-clps711x.c
@@ -0,0 +1,150 @@
+/*
+ *  CLPS711X clk driver
+ *
+ *  Copyright (C) 2013 Alexander Shiyan <shc_work at mail.ru>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#define pr_fmt(fmt)	"clk-clps711x: " fmt
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+
+#include <linux/mfd/syscon/clps711x.h>
+
+#define CLPS711X_SYSCON1	(0x0100)
+#define CLPS711X_SYSCON2	(0x1100)
+#define CLPS711X_PLLR		(0xa5a8)
+
+#define CLPS711X_EXT_FREQ	(13000000)
+#define CLPS711X_OSC_FREQ	(3686400)
+
+enum clps711x_clks {
+	dummy, cpu, pll, bus, timer_hf, timer_lf, tc1, tc2, spi, uart, clk_max
+};
+
+static struct {
+	struct clk_onecell_data	clk_data;
+	struct clk		*clks[clk_max];
+} *clps711x_clk;
+
+static void __init _clps711x_clk_init(phys_addr_t phys_base)
+{
+	const char *tc_parents[] = { "timer_lf", "timer_hf" };
+	u32 tmp, f_cpu, f_pll, f_bus, f_timh, f_spi;
+	void __iomem *pllr, *syscon1, *syscon2;
+
+	BUG_ON(!request_mem_region(phys_base + CLPS711X_PLLR, SZ_4, NULL));
+	BUG_ON(!request_mem_region(phys_base + CLPS711X_SYSCON1, SZ_128, NULL));
+	BUG_ON(!request_mem_region(phys_base + CLPS711X_SYSCON2, SZ_128, NULL));
+
+	clps711x_clk = kzalloc(sizeof(*clps711x_clk), GFP_KERNEL);
+	BUG_ON(!clps711x_clk);
+
+	pllr = ioremap(phys_base + CLPS711X_PLLR, SZ_4);
+	BUG_ON(!pllr);
+
+	syscon1 = ioremap(phys_base + CLPS711X_SYSCON1, SZ_128);
+	BUG_ON(!syscon1);
+
+	syscon2 = ioremap(phys_base + CLPS711X_SYSCON2, SZ_128);
+	BUG_ON(!syscon2);
+
+	tmp = readl(pllr) >> 24;
+	if (tmp)
+		f_pll = DIV_ROUND_UP(CLPS711X_OSC_FREQ * tmp, 2);
+	else
+		f_pll = 73728000; /* Old CPUs default value */
+
+	tmp = readl(syscon2 + SYSFLG_OFFSET);
+	if (tmp & SYSFLG2_CKMODE) {
+		f_cpu = CLPS711X_EXT_FREQ;
+		f_bus = CLPS711X_EXT_FREQ;
+		f_spi = 135400;
+		f_pll = 0;
+	} else {
+		f_cpu = f_pll;
+		if (f_cpu >= 36864000)
+			f_bus = DIV_ROUND_UP(f_cpu, 2);
+		else
+			f_bus = 36864000 / 2;
+		f_spi = DIV_ROUND_CLOSEST(f_cpu, 576);
+	}
+
+	if (tmp & SYSFLG2_CKMODE) {
+		if (readl(syscon2 + SYSCON_OFFSET) & SYSCON2_OSTB)
+			f_timh = DIV_ROUND_CLOSEST(CLPS711X_EXT_FREQ, 26);
+		else
+			f_timh = DIV_ROUND_CLOSEST(CLPS711X_EXT_FREQ, 24);
+	} else
+		f_timh = DIV_ROUND_CLOSEST(f_cpu, 144);
+
+	clps711x_clk->clks[dummy] =
+		clk_register_fixed_rate(NULL, "dummy", NULL, CLK_IS_ROOT, 0);
+	clps711x_clk->clks[cpu] =
+		clk_register_fixed_rate(NULL, "cpu", NULL, CLK_IS_ROOT, f_cpu);
+	clps711x_clk->clks[pll] =
+		clk_register_fixed_rate(NULL, "pll", NULL, CLK_IS_ROOT, f_pll);
+	clps711x_clk->clks[bus] =
+		clk_register_fixed_rate(NULL, "bus", NULL, CLK_IS_ROOT, f_bus);
+	clps711x_clk->clks[timer_hf] =
+		clk_register_fixed_rate(NULL, "timer_hf", NULL, CLK_IS_ROOT,
+					f_timh);
+	clps711x_clk->clks[timer_lf] =
+		clk_register_fixed_factor(NULL, "timer_lf", "timer_hf",
+					  0, 1, 256);
+	clps711x_clk->clks[tc1] =
+		clk_register_mux(NULL, "tc1", tc_parents, 2,
+				 CLK_GET_RATE_NOCACHE, syscon1, 5, 1, 0, NULL);
+	clps711x_clk->clks[tc2] =
+		clk_register_mux(NULL, "tc2", tc_parents, 2,
+				 CLK_GET_RATE_NOCACHE, syscon1, 7, 1, 0, NULL);
+	clps711x_clk->clks[spi] =
+		clk_register_fixed_rate(NULL, "spi", NULL, CLK_IS_ROOT, f_spi);
+	clps711x_clk->clks[uart] =
+		clk_register_fixed_factor(NULL, "uart", "bus", 0, 1, 10);
+
+	clk_set_parent(clps711x_clk->clks[tc1], clps711x_clk->clks[timer_lf]);
+	clk_set_parent(clps711x_clk->clks[tc2], clps711x_clk->clks[timer_hf]);
+
+	/* Temporary export clocks for non-DT capable drivers */
+	clk_register_clkdev(clps711x_clk->clks[pll], "pll", NULL);
+	clk_register_clkdev(clps711x_clk->clks[spi], "spi", NULL);
+	clk_register_clkdev(clps711x_clk->clks[uart], "uart", NULL);
+
+	pr_debug("CPU: %u Hz, Timer: %u Hz\n", f_cpu, f_timh);
+}
+
+void __init clps711x_clk_init(phys_addr_t phys_base)
+{
+	_clps711x_clk_init(phys_base);
+
+	clk_register_clkdev(clps711x_clk->clks[tc1], "tc1", NULL);
+	clk_register_clkdev(clps711x_clk->clks[tc2], "tc2", NULL);
+}
+
+#ifdef CONFIG_OF
+static void __init clps711x_clk_init_dt(struct device_node *np)
+{
+	struct resource res;
+
+	BUG_ON(!of_address_to_resource(np, 0, &res));
+
+	_clps711x_clk_init(res.start);
+
+	clps711x_clk->clk_data.clks = clps711x_clk->clks;
+	clps711x_clk->clk_data.clk_num = clk_max;
+	of_clk_add_provider(np, of_clk_src_onecell_get,
+			    &clps711x_clk->clk_data);
+}
+CLK_OF_DECLARE(clps711x, "cirrus,clps711x-clk", clps711x_clk_init_dt);
+#endif
-- 
1.8.1.5



From shc_work at mail.ru  Thu Jul 18 14:34:58 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Thu, 18 Jul 2013 22:34:58 +0400
Subject: [PATCH 07/10] ARM: clps711x: Add CLPS711X irqchip driver
In-Reply-To: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374172501-26796-8-git-send-email-shc_work@mail.ru>

This adds the irqchip driver for Cirrus Logic CLPS711X series SoCs.
Designed primarily for migration CLPS711X subarch for multiplatform & DT,
for this as the "OF" and "not-OF" calls implemented.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 .../interrupt-controller/cirrus,clps711x-intc.txt  |  42 ++++
 arch/arm/Kconfig                                   |   2 -
 drivers/irqchip/Kconfig                            |   6 +
 drivers/irqchip/Makefile                           |   1 +
 drivers/irqchip/irq-clps711x.c                     | 277 +++++++++++++++++++++
 5 files changed, 326 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt
 create mode 100644 drivers/irqchip/irq-clps711x.c

diff --git a/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt
new file mode 100644
index 0000000..26f8983
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt
@@ -0,0 +1,42 @@
+Cirrus Logic CLPS711X Interrupt Controller
+
+Required properties:
+
+- compatible: Should be "cirrus,clps711x-intc"
+- reg: Specifies base physical address of the registers set
+- interrupt-controller: Identifies the node as an interrupt controller
+- #interrupt-cells: Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 1.
+
+The interrupt sources are as follows:
+ID	Name	Description
+---------------------------
+1:	BLINT	Battery low (FIQ)
+3:	MCINT	Media changed (FIQ)
+4:	CSINT	CODEC sound
+5:	EINT1	External 1
+6:	EINT2	External 2
+7:	EINT3	External 3
+8:	TC1OI	TC1 under flow
+9:	TC2OI	TC2 under flow
+10:	RTCMI	RTC compare match
+11:	TINT	64Hz tick
+12:	UTXINT1	UART1 transmit FIFO half empty
+13:	URXINT1	UART1 receive FIFO half full
+14:	UMSINT	UART1 modem status changed
+15:	SSEOTI	SSI1 end of transfer
+16:	KBDINT	Keyboard
+17:	SS2RX	SSI2 receive FIFO half or greater full
+18:	SS2TX	SSI2 transmit FIFO less than half empty
+28:	UTXINT2	UART2 transmit FIFO half empty
+29:	URXINT2	UART2 receive FIFO half full
+32:	DAIINT	DAI interface (FIQ)
+
+Example:
+
+intc: interrupt-controller {
+	compatible = "cirrus,clps711x-intc";
+	reg = <0x80000000 0>;
+	interrupt-controller;
+	#interrupt-cells = <1>;
+};
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5c60cb7..6f0d238 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -373,8 +373,6 @@ config ARCH_CLPS711X
 	select COMMON_CLK
 	select CPU_ARM720T
 	select MFD_SYSCON
-	select MULTI_IRQ_HANDLER
-	select SPARSE_IRQ
 	help
 	  Support for Cirrus Logic 711x/721x/731x based boards.
 
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 1fea003..c94d00a 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -30,6 +30,12 @@ config ARM_VIC_NR
 	  The maximum number of VICs available in the system, for
 	  power management.
 
+config CLPS711X_IRQCHIP
+	def_bool y if ARCH_CLPS711X
+	select IRQ_DOMAIN
+	select MULTI_IRQ_HANDLER
+	select SPARSE_IRQ
+
 config ORION_IRQCHIP
 	bool
 	select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index e65c41a..a80ff5b 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_ARCH_S3C24XX)		+= irq-s3c24xx.o
 obj-$(CONFIG_METAG)			+= irq-metag-ext.o
 obj-$(CONFIG_METAG_PERFCOUNTER_IRQS)	+= irq-metag.o
 obj-$(CONFIG_ARCH_MOXART)		+= irq-moxart.o
+obj-$(CONFIG_CLPS711X_IRQCHIP)		+= irq-clps711x.o
 obj-$(CONFIG_ORION_IRQCHIP)		+= irq-orion.o
 obj-$(CONFIG_ARCH_SUNXI)		+= irq-sun4i.o
 obj-$(CONFIG_ARCH_SPEAR3XX)		+= spear-shirq.o
diff --git a/drivers/irqchip/irq-clps711x.c b/drivers/irqchip/irq-clps711x.c
new file mode 100644
index 0000000..819baa9
--- /dev/null
+++ b/drivers/irqchip/irq-clps711x.c
@@ -0,0 +1,277 @@
+/*
+ *  CLPS711X IRQ driver
+ *
+ *  Copyright (C) 2013 Alexander Shiyan <shc_work at mail.ru>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/slab.h>
+
+#include <asm/exception.h>
+#include <asm/mach/irq.h>
+
+#include "irqchip.h"
+
+#define CLPS711X_INTSR1	(0x0240)
+#define CLPS711X_INTMR1	(0x0280)
+#define CLPS711X_BLEOI	(0x0600)
+#define CLPS711X_MCEOI	(0x0640)
+#define CLPS711X_TEOI	(0x0680)
+#define CLPS711X_TC1EOI	(0x06c0)
+#define CLPS711X_TC2EOI	(0x0700)
+#define CLPS711X_RTCEOI	(0x0740)
+#define CLPS711X_UMSEOI	(0x0780)
+#define CLPS711X_COEOI	(0x07c0)
+#define CLPS711X_INTSR2	(0x1240)
+#define CLPS711X_INTMR2	(0x1280)
+#define CLPS711X_SRXEOF	(0x1600)
+#define CLPS711X_KBDEOI	(0x1700)
+#define CLPS711X_INTSR3	(0x2240)
+#define CLPS711X_INTMR3	(0x2280)
+
+static const struct {
+#define CLPS711X_FLAG_EN	(1 << 0)
+#define CLPS711X_FLAG_FIQ	(1 << 1)
+	unsigned int	flags;
+	phys_addr_t	phys_eoi;
+} clps711x_irqs[] __initconst = {
+	[1]	= { CLPS711X_FLAG_FIQ, CLPS711X_BLEOI, },
+	[3]	= { CLPS711X_FLAG_FIQ, CLPS711X_MCEOI, },
+	[4]	= { CLPS711X_FLAG_EN, CLPS711X_COEOI, },
+	[5]	= { CLPS711X_FLAG_EN, },
+	[6]	= { CLPS711X_FLAG_EN, },
+	[7]	= { CLPS711X_FLAG_EN, },
+	[8]	= { CLPS711X_FLAG_EN, CLPS711X_TC1EOI, },
+	[9]	= { CLPS711X_FLAG_EN, CLPS711X_TC2EOI, },
+	[10]	= { CLPS711X_FLAG_EN, CLPS711X_RTCEOI, },
+	[11]	= { CLPS711X_FLAG_EN, CLPS711X_TEOI, },
+	[12]	= { CLPS711X_FLAG_EN, },
+	[13]	= { CLPS711X_FLAG_EN, },
+	[14]	= { CLPS711X_FLAG_EN, CLPS711X_UMSEOI, },
+	[15]	= { CLPS711X_FLAG_EN, CLPS711X_SRXEOF, },
+	[16]	= { CLPS711X_FLAG_EN, CLPS711X_KBDEOI, },
+	[17]	= { CLPS711X_FLAG_EN, },
+	[18]	= { CLPS711X_FLAG_EN, },
+	[28]	= { CLPS711X_FLAG_EN, },
+	[29]	= { CLPS711X_FLAG_EN, },
+	[32]	= { CLPS711X_FLAG_FIQ, },
+};
+
+static struct {
+	struct irq_domain	*domain;
+	phys_addr_t		phys_base;
+	void __iomem		*intmr[3];
+	void __iomem		*intsr[3];
+	void __iomem		*eoi[ARRAY_SIZE(clps711x_irqs)];
+} *clps711x_intc;
+
+
+static inline u32 fls16(u32 x)
+{
+	u32 r = 15;
+
+	if (!(x & 0xff00)) {
+		x <<= 8;
+		r -= 8;
+	}
+	if (!(x & 0xf000)) {
+		x <<= 4;
+		r -= 4;
+	}
+	if (!(x & 0xc000)) {
+		x <<= 2;
+		r -= 2;
+	}
+	if (!(x & 0x8000))
+		r--;
+
+	return r;
+}
+
+static asmlinkage void __exception_irq_entry
+clps711x_handle_irq(struct pt_regs *regs)
+{
+	do {
+		u32 irqnr, irqstat;
+
+		irqstat = readw(clps711x_intc->intmr[0]) &
+			  readw(clps711x_intc->intsr[0]);
+		if (irqstat) {
+			irqnr =	irq_find_mapping(clps711x_intc->domain,
+						 fls16(irqstat));
+			handle_IRQ(irqnr, regs);
+		}
+
+		irqstat = readw(clps711x_intc->intmr[1]) &
+			  readw(clps711x_intc->intsr[1]);
+		if (irqstat) {
+			irqnr =	irq_find_mapping(clps711x_intc->domain,
+						 fls16(irqstat) + 16);
+			handle_IRQ(irqnr, regs);
+			continue;
+		}
+
+		break;
+	} while (1);
+}
+
+static void clps711x_intc_eoi(struct irq_data *d)
+{
+	irq_hw_number_t hwirq = irqd_to_hwirq(d);
+
+	writel(0, clps711x_intc->eoi[hwirq]);
+}
+
+static void clps711x_intc_mask(struct irq_data *d)
+{
+	irq_hw_number_t hwirq = irqd_to_hwirq(d);
+	void __iomem *intmr = clps711x_intc->intmr[hwirq / 16];
+	u32 tmp;
+
+	tmp = readl(intmr);
+	tmp &= ~(1 << (hwirq % 16));
+	writel(tmp, intmr);
+}
+
+static void clps711x_intc_unmask(struct irq_data *d)
+{
+	irq_hw_number_t hwirq = irqd_to_hwirq(d);
+	void __iomem *intmr = clps711x_intc->intmr[hwirq / 16];
+	u32 tmp;
+
+	tmp = readl(intmr);
+	tmp |= 1 << (hwirq % 16);
+	writel(tmp, intmr);
+}
+
+static struct irq_chip clps711x_intc_chip = {
+	.name		= "clps711x-intc",
+	.irq_eoi	= clps711x_intc_eoi,
+	.irq_mask	= clps711x_intc_mask,
+	.irq_unmask	= clps711x_intc_unmask,
+};
+
+static void __iomem __init *clps711x_ioremap_one(phys_addr_t reg)
+{
+	void __iomem *ret;
+
+	if (!request_mem_region(clps711x_intc->phys_base + reg, SZ_4, NULL))
+		return ERR_PTR(-EBUSY);
+
+	ret = ioremap(clps711x_intc->phys_base + reg, SZ_4);
+	if (!ret)
+		return ERR_PTR(-ENOMEM);
+
+	return ret;
+}
+
+static int __init clps711x_intc_irq_map(struct irq_domain *h, unsigned int virq,
+					irq_hw_number_t hw)
+{
+	irq_flow_handler_t handler = handle_level_irq;
+	unsigned int flags = IRQF_VALID | IRQF_PROBE;
+
+	if (!clps711x_irqs[hw].flags)
+		return 0;
+
+	if (clps711x_irqs[hw].flags & CLPS711X_FLAG_FIQ) {
+		handler = handle_bad_irq;
+		flags |= IRQF_NOAUTOEN;
+	} else if (clps711x_irqs[hw].phys_eoi) {
+		handler = handle_fasteoi_irq;
+
+		clps711x_intc->eoi[hw] =
+			clps711x_ioremap_one(clps711x_irqs[hw].phys_eoi);
+		if (IS_ERR_OR_NULL(clps711x_intc->eoi[hw]))
+			return PTR_ERR(clps711x_intc->eoi[hw]);
+
+		/* Clear down pending interrupt */
+		writel(0, clps711x_intc->eoi[hw]);
+	}
+
+	irq_set_chip_and_handler(virq, &clps711x_intc_chip, handler);
+	set_irq_flags(virq, flags);
+
+	return 0;
+}
+
+static struct irq_domain_ops clps711x_intc_ops = {
+	.map	= clps711x_intc_irq_map,
+	.xlate	= irq_domain_xlate_onecell,
+};
+
+static void __init _clps711x_intc_init(phys_addr_t phys_base,
+				       struct device_node *np)
+{
+	clps711x_intc = kzalloc(sizeof(*clps711x_intc), GFP_KERNEL);
+	BUG_ON(!clps711x_intc);
+
+	clps711x_intc->phys_base = phys_base;
+
+	clps711x_intc->intsr[0] = clps711x_ioremap_one(CLPS711X_INTSR1);
+	BUG_ON(IS_ERR_OR_NULL(clps711x_intc->intsr[0]));
+
+	clps711x_intc->intmr[0] = clps711x_ioremap_one(CLPS711X_INTMR1);
+	BUG_ON(IS_ERR_OR_NULL(clps711x_intc->intmr[0]));
+
+	clps711x_intc->intsr[1] = clps711x_ioremap_one(CLPS711X_INTSR2);
+	BUG_ON(IS_ERR_OR_NULL(clps711x_intc->intsr[1]));
+
+	clps711x_intc->intmr[1] = clps711x_ioremap_one(CLPS711X_INTMR2);
+	BUG_ON(IS_ERR_OR_NULL(clps711x_intc->intmr[1]));
+
+	clps711x_intc->intsr[2] = clps711x_ioremap_one(CLPS711X_INTSR3);
+	BUG_ON(IS_ERR_OR_NULL(clps711x_intc->intsr[2]));
+
+	clps711x_intc->intmr[2] = clps711x_ioremap_one(CLPS711X_INTMR3);
+	BUG_ON(IS_ERR_OR_NULL(clps711x_intc->intmr[2]));
+
+	/* Disable interrupts */
+	writel(0, clps711x_intc->intmr[0]);
+	writel(0, clps711x_intc->intmr[1]);
+	writel(0, clps711x_intc->intmr[2]);
+
+	BUG_ON(IS_ERR_VALUE(irq_alloc_descs(-1, 0, ARRAY_SIZE(clps711x_irqs),
+					    numa_node_id())));
+
+	clps711x_intc->domain =
+		irq_domain_add_legacy(np, ARRAY_SIZE(clps711x_irqs),
+				      0, 0, &clps711x_intc_ops, NULL);
+	BUG_ON(!clps711x_intc->domain);
+
+	irq_set_default_host(clps711x_intc->domain);
+	set_handle_irq(clps711x_handle_irq);
+
+#ifdef CONFIG_FIQ
+	init_FIQ(0);
+#endif
+}
+
+void __init clps711x_intc_init(phys_addr_t phys_base)
+{
+	_clps711x_intc_init(phys_base, NULL);
+}
+
+#ifdef CONFIG_IRQCHIP
+static int __init clps711x_intc_init_dt(struct device_node *np,
+					struct device_node *parent)
+{
+	struct resource res;
+
+	BUG_ON(of_address_to_resource(np, 0, &res));
+
+	_clps711x_intc_init(res.start, np);
+
+	return 0;
+}
+IRQCHIP_DECLARE(clps711x, "cirrus,clps711x-intc", clps711x_intc_init_dt);
+#endif
-- 
1.8.1.5



From shc_work at mail.ru  Thu Jul 18 14:35:00 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Thu, 18 Jul 2013 22:35:00 +0400
Subject: [PATCH 09/10] ARM: clps711x: Migrate CLPS711X subarch to the new
 basic drivers
In-Reply-To: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374172501-26796-10-git-send-email-shc_work@mail.ru>

This patch remove old code and migrate Cirrus Logic CLPS711X subarch
to the new basic drivers: clk, clocksource, irqchip and cpuidle.
This change brings this subarch for use in multiplatform build.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/mach-clps711x/board-autcpu12.c |   3 -
 arch/arm/mach-clps711x/board-cdb89712.c |   3 -
 arch/arm/mach-clps711x/board-clep7312.c |   3 -
 arch/arm/mach-clps711x/board-edb7211.c  |   3 -
 arch/arm/mach-clps711x/board-p720t.c    |   3 -
 arch/arm/mach-clps711x/common.c         | 345 +-------------------------------
 arch/arm/mach-clps711x/common.h         |   3 -
 arch/arm/mach-clps711x/devices.c        |  10 +
 8 files changed, 16 insertions(+), 357 deletions(-)

diff --git a/arch/arm/mach-clps711x/board-autcpu12.c b/arch/arm/mach-clps711x/board-autcpu12.c
index f8d71a8..b1c77ad 100644
--- a/arch/arm/mach-clps711x/board-autcpu12.c
+++ b/arch/arm/mach-clps711x/board-autcpu12.c
@@ -265,14 +265,11 @@ static void __init autcpu12_init_late(void)
 MACHINE_START(AUTCPU12, "autronix autcpu12")
 	/* Maintainer: Thomas Gleixner */
 	.atag_offset	= 0x20000,
-	.nr_irqs	= CLPS711X_NR_IRQS,
 	.map_io		= clps711x_map_io,
-	.init_early	= clps711x_init_early,
 	.init_irq	= clps711x_init_irq,
 	.init_time	= clps711x_timer_init,
 	.init_machine	= autcpu12_init,
 	.init_late	= autcpu12_init_late,
-	.handle_irq	= clps711x_handle_irq,
 	.restart	= clps711x_restart,
 MACHINE_END
 
diff --git a/arch/arm/mach-clps711x/board-cdb89712.c b/arch/arm/mach-clps711x/board-cdb89712.c
index a9e38c6..1ec378c 100644
--- a/arch/arm/mach-clps711x/board-cdb89712.c
+++ b/arch/arm/mach-clps711x/board-cdb89712.c
@@ -139,12 +139,9 @@ static void __init cdb89712_init(void)
 MACHINE_START(CDB89712, "Cirrus-CDB89712")
 	/* Maintainer: Ray Lehtiniemi */
 	.atag_offset	= 0x100,
-	.nr_irqs	= CLPS711X_NR_IRQS,
 	.map_io		= clps711x_map_io,
-	.init_early	= clps711x_init_early,
 	.init_irq	= clps711x_init_irq,
 	.init_time	= clps711x_timer_init,
 	.init_machine	= cdb89712_init,
-	.handle_irq	= clps711x_handle_irq,
 	.restart	= clps711x_restart,
 MACHINE_END
diff --git a/arch/arm/mach-clps711x/board-clep7312.c b/arch/arm/mach-clps711x/board-clep7312.c
index b476424..1f3b403 100644
--- a/arch/arm/mach-clps711x/board-clep7312.c
+++ b/arch/arm/mach-clps711x/board-clep7312.c
@@ -36,12 +36,9 @@ fixup_clep7312(struct tag *tags, char **cmdline, struct meminfo *mi)
 MACHINE_START(CLEP7212, "Cirrus Logic 7212/7312")
 	/* Maintainer: Nobody */
 	.atag_offset	= 0x0100,
-	.nr_irqs	= CLPS711X_NR_IRQS,
 	.fixup		= fixup_clep7312,
 	.map_io		= clps711x_map_io,
-	.init_early	= clps711x_init_early,
 	.init_irq	= clps711x_init_irq,
 	.init_time	= clps711x_timer_init,
-	.handle_irq	= clps711x_handle_irq,
 	.restart	= clps711x_restart,
 MACHINE_END
diff --git a/arch/arm/mach-clps711x/board-edb7211.c b/arch/arm/mach-clps711x/board-edb7211.c
index fe6184e..fa4580f 100644
--- a/arch/arm/mach-clps711x/board-edb7211.c
+++ b/arch/arm/mach-clps711x/board-edb7211.c
@@ -177,15 +177,12 @@ static void __init edb7211_init_late(void)
 MACHINE_START(EDB7211, "CL-EDB7211 (EP7211 eval board)")
 	/* Maintainer: Jon McClintock */
 	.atag_offset	= VIDEORAM_SIZE + 0x100,
-	.nr_irqs	= CLPS711X_NR_IRQS,
 	.fixup		= fixup_edb7211,
 	.reserve	= edb7211_reserve,
 	.map_io		= clps711x_map_io,
-	.init_early	= clps711x_init_early,
 	.init_irq	= clps711x_init_irq,
 	.init_time	= clps711x_timer_init,
 	.init_machine	= edb7211_init,
 	.init_late	= edb7211_init_late,
-	.handle_irq	= clps711x_handle_irq,
 	.restart	= clps711x_restart,
 MACHINE_END
diff --git a/arch/arm/mach-clps711x/board-p720t.c b/arch/arm/mach-clps711x/board-p720t.c
index dd81b06..4a2ec28 100644
--- a/arch/arm/mach-clps711x/board-p720t.c
+++ b/arch/arm/mach-clps711x/board-p720t.c
@@ -363,14 +363,11 @@ static void __init p720t_init_late(void)
 MACHINE_START(P720T, "ARM-Prospector720T")
 	/* Maintainer: ARM Ltd/Deep Blue Solutions Ltd */
 	.atag_offset	= 0x100,
-	.nr_irqs	= CLPS711X_NR_IRQS,
 	.fixup		= fixup_p720t,
 	.map_io		= clps711x_map_io,
-	.init_early	= clps711x_init_early,
 	.init_irq	= clps711x_init_irq,
 	.init_time	= clps711x_timer_init,
 	.init_machine	= p720t_init,
 	.init_late	= p720t_init_late,
-	.handle_irq	= clps711x_handle_irq,
 	.restart	= clps711x_restart,
 MACHINE_END
diff --git a/arch/arm/mach-clps711x/common.c b/arch/arm/mach-clps711x/common.c
index 4ca2f3c..d226609 100644
--- a/arch/arm/mach-clps711x/common.c
+++ b/arch/arm/mach-clps711x/common.c
@@ -22,26 +22,14 @@
 #include <linux/io.h>
 #include <linux/init.h>
 #include <linux/sizes.h>
-#include <linux/interrupt.h>
-#include <linux/irq.h>
-#include <linux/clk.h>
-#include <linux/clkdev.h>
-#include <linux/clockchips.h>
 #include <linux/clocksource.h>
 #include <linux/clk-provider.h>
 
-#include <asm/exception.h>
-#include <asm/mach/irq.h>
 #include <asm/mach/map.h>
-#include <asm/mach/time.h>
-#include <asm/sched_clock.h>
 #include <asm/system_misc.h>
 
 #include <mach/hardware.h>
 
-static struct clk *clk_pll, *clk_bus, *clk_uart, *clk_timerl, *clk_timerh,
-		  *clk_tint, *clk_spi;
-
 /*
  * This maps the generic CLPS711x registers
  */
@@ -59,344 +47,23 @@ void __init clps711x_map_io(void)
 	iotable_init(clps711x_io_desc, ARRAY_SIZE(clps711x_io_desc));
 }
 
-static void int1_mask(struct irq_data *d)
-{
-	u32 intmr1;
-
-	intmr1 = clps_readl(INTMR1);
-	intmr1 &= ~(1 << d->irq);
-	clps_writel(intmr1, INTMR1);
-}
-
-static void int1_eoi(struct irq_data *d)
-{
-	switch (d->irq) {
-	case IRQ_CSINT:  clps_writel(0, COEOI);  break;
-	case IRQ_TC1OI:  clps_writel(0, TC1EOI); break;
-	case IRQ_TC2OI:  clps_writel(0, TC2EOI); break;
-	case IRQ_RTCMI:  clps_writel(0, RTCEOI); break;
-	case IRQ_TINT:   clps_writel(0, TEOI);   break;
-	case IRQ_UMSINT: clps_writel(0, UMSEOI); break;
-	}
-}
-
-static void int1_unmask(struct irq_data *d)
-{
-	u32 intmr1;
-
-	intmr1 = clps_readl(INTMR1);
-	intmr1 |= 1 << d->irq;
-	clps_writel(intmr1, INTMR1);
-}
-
-static struct irq_chip int1_chip = {
-	.name		= "Interrupt Vector 1",
-	.irq_eoi	= int1_eoi,
-	.irq_mask	= int1_mask,
-	.irq_unmask	= int1_unmask,
-};
-
-static void int2_mask(struct irq_data *d)
-{
-	u32 intmr2;
-
-	intmr2 = clps_readl(INTMR2);
-	intmr2 &= ~(1 << (d->irq - 16));
-	clps_writel(intmr2, INTMR2);
-}
-
-static void int2_eoi(struct irq_data *d)
-{
-	switch (d->irq) {
-	case IRQ_KBDINT: clps_writel(0, KBDEOI); break;
-	}
-}
-
-static void int2_unmask(struct irq_data *d)
-{
-	u32 intmr2;
-
-	intmr2 = clps_readl(INTMR2);
-	intmr2 |= 1 << (d->irq - 16);
-	clps_writel(intmr2, INTMR2);
-}
-
-static struct irq_chip int2_chip = {
-	.name		= "Interrupt Vector 2",
-	.irq_eoi	= int2_eoi,
-	.irq_mask	= int2_mask,
-	.irq_unmask	= int2_unmask,
-};
-
-static void int3_mask(struct irq_data *d)
-{
-	u32 intmr3;
-
-	intmr3 = clps_readl(INTMR3);
-	intmr3 &= ~(1 << (d->irq - 32));
-	clps_writel(intmr3, INTMR3);
-}
-
-static void int3_unmask(struct irq_data *d)
-{
-	u32 intmr3;
-
-	intmr3 = clps_readl(INTMR3);
-	intmr3 |= 1 << (d->irq - 32);
-	clps_writel(intmr3, INTMR3);
-}
-
-static struct irq_chip int3_chip = {
-	.name		= "Interrupt Vector 3",
-	.irq_mask	= int3_mask,
-	.irq_unmask	= int3_unmask,
-};
-
-static struct {
-	int			nr;
-	struct irq_chip		*chip;
-	irq_flow_handler_t	handle;
-} clps711x_irqdescs[] __initdata = {
-	{ IRQ_CSINT,	&int1_chip,	handle_fasteoi_irq,	},
-	{ IRQ_EINT1,	&int1_chip,	handle_level_irq,	},
-	{ IRQ_EINT2,	&int1_chip,	handle_level_irq,	},
-	{ IRQ_EINT3,	&int1_chip,	handle_level_irq,	},
-	{ IRQ_TC1OI,	&int1_chip,	handle_fasteoi_irq,	},
-	{ IRQ_TC2OI,	&int1_chip,	handle_fasteoi_irq,	},
-	{ IRQ_RTCMI,	&int1_chip,	handle_fasteoi_irq,	},
-	{ IRQ_TINT,	&int1_chip,	handle_fasteoi_irq,	},
-	{ IRQ_UTXINT1,	&int1_chip,	handle_level_irq,	},
-	{ IRQ_URXINT1,	&int1_chip,	handle_level_irq,	},
-	{ IRQ_UMSINT,	&int1_chip,	handle_fasteoi_irq,	},
-	{ IRQ_SSEOTI,	&int1_chip,	handle_level_irq,	},
-	{ IRQ_KBDINT,	&int2_chip,	handle_fasteoi_irq,	},
-	{ IRQ_SS2RX,	&int2_chip,	handle_level_irq,	},
-	{ IRQ_SS2TX,	&int2_chip,	handle_level_irq,	},
-	{ IRQ_UTXINT2,	&int2_chip,	handle_level_irq,	},
-	{ IRQ_URXINT2,	&int2_chip,	handle_level_irq,	},
-};
-
 void __init clps711x_init_irq(void)
 {
-	unsigned int i;
-
-	/* Disable interrupts */
-	clps_writel(0, INTMR1);
-	clps_writel(0, INTMR2);
-	clps_writel(0, INTMR3);
-
-	/* Clear down any pending interrupts */
-	clps_writel(0, BLEOI);
-	clps_writel(0, MCEOI);
-	clps_writel(0, COEOI);
-	clps_writel(0, TC1EOI);
-	clps_writel(0, TC2EOI);
-	clps_writel(0, RTCEOI);
-	clps_writel(0, TEOI);
-	clps_writel(0, UMSEOI);
-	clps_writel(0, KBDEOI);
-	clps_writel(0, SRXEOF);
-	clps_writel(0xffffffff, DAISR);
-
-	for (i = 0; i < ARRAY_SIZE(clps711x_irqdescs); i++) {
-		irq_set_chip_and_handler(clps711x_irqdescs[i].nr,
-					 clps711x_irqdescs[i].chip,
-					 clps711x_irqdescs[i].handle);
-		set_irq_flags(clps711x_irqdescs[i].nr,
-			      IRQF_VALID | IRQF_PROBE);
-	}
-
-	if (IS_ENABLED(CONFIG_FIQ)) {
-		init_FIQ(0);
-		irq_set_chip_and_handler(IRQ_DAIINT, &int3_chip,
-					 handle_bad_irq);
-		set_irq_flags(IRQ_DAIINT,
-			      IRQF_VALID | IRQF_PROBE | IRQF_NOAUTOEN);
-	}
-}
-
-static inline u32 fls16(u32 x)
-{
-	u32 r = 15;
+	extern void clps711x_intc_init(phys_addr_t);
 
-	if (!(x & 0xff00)) {
-		x <<= 8;
-		r -= 8;
-	}
-	if (!(x & 0xf000)) {
-		x <<= 4;
-		r -= 4;
-	}
-	if (!(x & 0xc000)) {
-		x <<= 2;
-		r -= 2;
-	}
-	if (!(x & 0x8000))
-		r--;
-
-	return r;
-}
-
-asmlinkage void __exception_irq_entry clps711x_handle_irq(struct pt_regs *regs)
-{
-	do {
-		u32 irqstat;
-		void __iomem *base = CLPS711X_VIRT_BASE;
-
-		irqstat = readw_relaxed(base + INTSR1) &
-			  readw_relaxed(base + INTMR1);
-		if (irqstat)
-			handle_IRQ(fls16(irqstat), regs);
-
-		irqstat = readw_relaxed(base + INTSR2) &
-			  readw_relaxed(base + INTMR2);
-		if (irqstat) {
-			handle_IRQ(fls16(irqstat) + 16, regs);
-			continue;
-		}
-
-		break;
-	} while (1);
-}
-
-static u32 notrace clps711x_sched_clock_read(void)
-{
-	return ~readw_relaxed(CLPS711X_VIRT_BASE + TC1D);
-}
-
-static void clps711x_clockevent_set_mode(enum clock_event_mode mode,
-					 struct clock_event_device *evt)
-{
-	disable_irq(IRQ_TC2OI);
-
-	switch (mode) {
-	case CLOCK_EVT_MODE_PERIODIC:
-		enable_irq(IRQ_TC2OI);
-		break;
-	case CLOCK_EVT_MODE_ONESHOT:
-		/* Not supported */
-	case CLOCK_EVT_MODE_SHUTDOWN:
-	case CLOCK_EVT_MODE_UNUSED:
-	case CLOCK_EVT_MODE_RESUME:
-		/* Left event sources disabled, no more interrupts appear */
-		break;
-	}
-}
-
-static struct clock_event_device clockevent_clps711x = {
-	.name		= "clps711x-clockevent",
-	.rating		= 300,
-	.features	= CLOCK_EVT_FEAT_PERIODIC,
-	.set_mode	= clps711x_clockevent_set_mode,
-};
-
-static irqreturn_t clps711x_timer_interrupt(int irq, void *dev_id)
-{
-	clockevent_clps711x.event_handler(&clockevent_clps711x);
-
-	return IRQ_HANDLED;
-}
-
-static struct irqaction clps711x_timer_irq = {
-	.name		= "clps711x-timer",
-	.flags		= IRQF_TIMER | IRQF_IRQPOLL,
-	.handler	= clps711x_timer_interrupt,
-};
-
-static void add_fixed_clk(struct clk *clk, const char *name, int rate)
-{
-	clk = clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
-	clk_register_clkdev(clk, name, NULL);
+	clps711x_intc_init(CLPS711X_PHYS_BASE);
 }
 
 void __init clps711x_timer_init(void)
 {
-	int osc, ext, pll, cpu, bus, timl, timh, uart, spi;
-	u32 tmp;
-
-	osc = 3686400;
-	ext = 13000000;
-
-	tmp = clps_readl(PLLR) >> 24;
-	if (tmp)
-		pll = (osc * tmp) / 2;
-	else
-		pll = 73728000; /* Default value */
-
-	tmp = clps_readl(SYSFLG2);
-	if (tmp & SYSFLG2_CKMODE) {
-		cpu = ext;
-		bus = cpu;
-		spi = 135400;
-		pll = 0;
-	} else {
-		cpu = pll;
-		if (cpu >= 36864000)
-			bus = cpu / 2;
-		else
-			bus = 36864000 / 2;
-		spi = cpu / 576;
-	}
-
-	uart = bus / 10;
-
-	if (tmp & SYSFLG2_CKMODE) {
-		tmp = clps_readl(SYSCON2);
-		if (tmp & SYSCON2_OSTB)
-			timh = ext / 26;
-		else
-			timh = 541440;
-	} else
-		timh = DIV_ROUND_CLOSEST(cpu, 144);
-
-	timl = DIV_ROUND_CLOSEST(timh, 256);
-
-	/* All clocks are fixed */
-	add_fixed_clk(clk_pll, "pll", pll);
-	add_fixed_clk(clk_bus, "bus", bus);
-	add_fixed_clk(clk_uart, "uart", uart);
-	add_fixed_clk(clk_timerl, "timer_lf", timl);
-	add_fixed_clk(clk_timerh, "timer_hf", timh);
-	add_fixed_clk(clk_tint, "tint", 64);
-	add_fixed_clk(clk_spi, "spi", spi);
-
-	pr_info("CPU frequency set at %i Hz.\n", cpu);
+	extern void clps711x_clk_init(phys_addr_t);
+	extern void clps711x_clksrc_init(phys_addr_t, int);
 
-	/* Start Timer1 in free running mode (Low frequency) */
-	tmp = clps_readl(SYSCON1) & ~(SYSCON1_TC1S | SYSCON1_TC1M);
-	clps_writel(tmp, SYSCON1);
-
-	setup_sched_clock(clps711x_sched_clock_read, 16, timl);
-
-	clocksource_mmio_init(CLPS711X_VIRT_BASE + TC1D,
-			      "clps711x_clocksource", timl, 300, 16,
-			      clocksource_mmio_readw_down);
-
-	/* Set Timer2 prescaler */
-	clps_writew(DIV_ROUND_CLOSEST(timh, HZ), TC2D);
-
-	/* Start Timer2 in prescale mode (High frequency)*/
-	tmp = clps_readl(SYSCON1) | SYSCON1_TC2M | SYSCON1_TC2S;
-	clps_writel(tmp, SYSCON1);
-
-	clockevents_config_and_register(&clockevent_clps711x, timh, 0, 0);
-
-	setup_irq(IRQ_TC2OI, &clps711x_timer_irq);
+	clps711x_clk_init(CLPS711X_PHYS_BASE);
+	clps711x_clksrc_init(CLPS711X_PHYS_BASE, IRQ_TC2OI);
 }
 
 void clps711x_restart(enum reboot_mode mode, const char *cmd)
 {
 	soft_restart(0);
 }
-
-static void clps711x_idle(void)
-{
-	clps_writel(1, HALT);
-	asm("mov r0, r0");
-	asm("mov r0, r0");
-}
-
-void __init clps711x_init_early(void)
-{
-	arm_pm_idle = clps711x_idle;
-}
diff --git a/arch/arm/mach-clps711x/common.h b/arch/arm/mach-clps711x/common.h
index 9a6767b..77f3130 100644
--- a/arch/arm/mach-clps711x/common.h
+++ b/arch/arm/mach-clps711x/common.h
@@ -6,13 +6,10 @@
 
 #include <linux/reboot.h>
 
-#define CLPS711X_NR_IRQS	(33)
 #define CLPS711X_NR_GPIO	(4 * 8 + 3)
 #define CLPS711X_GPIO(prt, bit)	((prt) * 8 + (bit))
 
 extern void clps711x_map_io(void);
 extern void clps711x_init_irq(void);
 extern void clps711x_timer_init(void);
-extern void clps711x_handle_irq(struct pt_regs *regs);
 extern void clps711x_restart(enum reboot_mode mode, const char *cmd);
-extern void clps711x_init_early(void);
diff --git a/arch/arm/mach-clps711x/devices.c b/arch/arm/mach-clps711x/devices.c
index fb77d14..aa24dc4 100644
--- a/arch/arm/mach-clps711x/devices.c
+++ b/arch/arm/mach-clps711x/devices.c
@@ -14,6 +14,15 @@
 
 #include <mach/hardware.h>
 
+static const struct resource clps711x_cpuidle_res __initconst =
+	DEFINE_RES_MEM(CLPS711X_PHYS_BASE + HALT, SZ_4);
+
+static void __init clps711x_add_cpuidle(void)
+{
+	platform_device_register_simple("clps711x-cpuidle", PLATFORM_DEVID_NONE,
+					&clps711x_cpuidle_res, 1);
+}
+
 static const phys_addr_t clps711x_gpios[][2] __initconst = {
 	{ PADR, PADDR },
 	{ PBDR, PBDDR },
@@ -63,6 +72,7 @@ static void __init clps711x_add_syscon(void)
 
 void __init clps711x_devices_init(void)
 {
+	clps711x_add_cpuidle();
 	clps711x_add_gpio();
 	clps711x_add_syscon();
 }
-- 
1.8.1.5



From shc_work at mail.ru  Thu Jul 18 14:35:01 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Thu, 18 Jul 2013 22:35:01 +0400
Subject: [PATCH 10/10] ARM: clps711x: Add initial DT support
In-Reply-To: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374172501-26796-11-git-send-email-shc_work@mail.ru>

This patch adds initial support for Cirrus Logic CLPS711X based platforms
using the device tree for discovery.
The basic devices is not yet DT-capable, so the CLPS711X DT option is marked
as experimental.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/mach-clps711x/Kconfig    |  7 +++++
 arch/arm/mach-clps711x/Makefile   |  1 +
 arch/arm/mach-clps711x/board-dt.c | 56 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 64 insertions(+)
 create mode 100644 arch/arm/mach-clps711x/board-dt.c

diff --git a/arch/arm/mach-clps711x/Kconfig b/arch/arm/mach-clps711x/Kconfig
index bea6295..8ef38c6 100644
--- a/arch/arm/mach-clps711x/Kconfig
+++ b/arch/arm/mach-clps711x/Kconfig
@@ -33,6 +33,13 @@ config ARCH_P720T
 	  Say Y here if you intend to run this kernel on the ARM Prospector
 	  720T.
 
+config CLPS711X_DT
+	bool "Support CLPS711X platforms from device tree (Very Experimental!)"
+	depends on USE_OF
+	help
+	  Include support for Cirrus Logic CLPS711X based platforms
+	  using the device tree for discovery.
+
 config EP72XX_ROM_BOOT
 	bool "EP721x/EP731x ROM boot"
 	help
diff --git a/arch/arm/mach-clps711x/Makefile b/arch/arm/mach-clps711x/Makefile
index f04151e..77d3a76 100644
--- a/arch/arm/mach-clps711x/Makefile
+++ b/arch/arm/mach-clps711x/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_ARCH_CDB89712)	+= board-cdb89712.o
 obj-$(CONFIG_ARCH_CLEP7312)	+= board-clep7312.o
 obj-$(CONFIG_ARCH_EDB7211)	+= board-edb7211.o
 obj-$(CONFIG_ARCH_P720T)	+= board-p720t.o
+obj-$(CONFIG_CLPS711X_DT)	+= board-dt.o
diff --git a/arch/arm/mach-clps711x/board-dt.c b/arch/arm/mach-clps711x/board-dt.c
new file mode 100644
index 0000000..5b6f3f1
--- /dev/null
+++ b/arch/arm/mach-clps711x/board-dt.c
@@ -0,0 +1,56 @@
+/*
+ *  CLPS711X Generic DT board
+ *
+ *  Author: Alexander Shiyan <shc_work at mail.ru>, 2013
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/clocksource.h>
+#include <linux/clk-provider.h>
+#include <linux/init.h>
+#include <linux/of_platform.h>
+
+#include <asm/mach/arch.h>
+
+#include <mach/hardware.h>
+
+#include "common.h"
+
+void __init clps711x_timer_init_dt(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+static struct of_dev_auxdata clps711x_auxdata_lookup[] __initdata = {
+	OF_DEV_AUXDATA("cirrus,clps711x-syscon", CLPS711X_PHYS_BASE + SYSCON1,
+		       "syscon.1", NULL),
+	OF_DEV_AUXDATA("cirrus,clps711x-syscon", CLPS711X_PHYS_BASE + SYSCON2,
+		       "syscon.2", NULL),
+	OF_DEV_AUXDATA("cirrus,clps711x-syscon", CLPS711X_PHYS_BASE + SYSCON3,
+		       "syscon.3", NULL),
+	{ }
+};
+
+static void __init clps711x_init_dt(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table,
+			     clps711x_auxdata_lookup, NULL);
+}
+
+static const char *clps711x_dt_compat[] __initdata = {
+	"cirrus,clps711x",
+	NULL
+};
+
+DT_MACHINE_START(CLPS711X_DT, "Cirrus Logic CLPS711X (Device Tree Support)")
+	.dt_compat	= clps711x_dt_compat,
+	.map_io		= clps711x_map_io,
+	.init_time	= clps711x_timer_init,
+	.init_machine	= clps711x_init_dt,
+	.restart	= clps711x_restart,
+MACHINE_END
-- 
1.8.1.5



From robherring2 at gmail.com  Thu Jul 18 14:30:55 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 18 Jul 2013 13:30:55 -0500
Subject: [RFC PATCH v2 11/15] cpufreq: kirkwood-cpufreq: remove device
 tree parsing for cpu nodes
In-Reply-To: <51E7BFFA.8010101@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374069984-20567-12-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <20130717144355.GE1026@lunn.ch> <51E7A63F.7020207@arm.com>
 <51E7BFFA.8010101@arm.com>
Message-ID: <51E8345F.30608@gmail.com>

On 07/18/2013 05:14 AM, Sudeep KarkadaNagesha wrote:
> On 18/07/13 09:24, Sudeep KarkadaNagesha wrote:
>> On 17/07/13 15:43, Andrew Lunn wrote:
>>> On Wed, Jul 17, 2013 at 03:06:20PM +0100, Sudeep.KarkadaNagesha at arm.com wrote:
>>>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>>>>
> [...]

>>> Are we not going a bit backwards here? You are replacing two lines
>>> with 10 lines.
>>>
>>> How about putting these 10 lines into some helper,
>>> of_get_cpu_device()?  It would be useful for spear, kirkwood and
>>> imx6q, and maybe others.
>>>
>> Yes I realised that after making changes to this and pmac32 drivers. I
>> have already made those changes in v3. I am waiting for more response
>> before posting them.
>>
> I thought of placing this helper in include/linux/of_device.h but I see:
> #include <linux/of_platform.h> /* temporary until merge */
> 
> Does this mean of_platform.h and of_device.h will be merged ?

No, I think that was probably to avoid adding includes of of_platform.h
for 100's of files. Maybe things are cleaned up enough to remove this line.

> If so, which will be the final merged one ? I would like to avoid
> changing all the header file inclusions later in users of this new helper.

of_device.h is the right place.

Rob

> 
> Regards,
> Sudeep
> 
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 



From shc_work at mail.ru  Thu Jul 18 14:34:59 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Thu, 18 Jul 2013 22:34:59 +0400
Subject: [PATCH 08/10] ARM: clps711x: Add CLPS711X cpuidle driver
In-Reply-To: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374172501-26796-9-git-send-email-shc_work@mail.ru>

This adds the cpuidle driver for Cirrus Logic CLPS711X series SoCs.
Designed primarily for migration CLPS711X subarch for multiplatform & DT.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 drivers/cpuidle/Kconfig            |  6 +++
 drivers/cpuidle/Makefile           |  1 +
 drivers/cpuidle/cpuidle-clps711x.c | 80 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 87 insertions(+)
 create mode 100644 drivers/cpuidle/cpuidle-clps711x.c

diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index 0e2cd5c..c68a0cf 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
@@ -36,6 +36,12 @@ config CPU_IDLE_CALXEDA
 	help
 	  Select this to enable cpuidle on Calxeda processors.
 
+config CPU_IDLE_CLPS711X
+	bool "CPU Idle Driver for CLPS711X processors"
+	depends on ARCH_CLPS711X
+	help
+	  Select this to enable cpuidle on Cirrus Logic CLPS711X processors.
+
 config CPU_IDLE_ZYNQ
 	bool "CPU Idle Driver for Xilinx Zynq processors"
 	depends on ARCH_ZYNQ
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 8767a7b..d07d2cb 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -6,5 +6,6 @@ obj-y += cpuidle.o driver.o governor.o sysfs.o governors/
 obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
 
 obj-$(CONFIG_CPU_IDLE_CALXEDA) += cpuidle-calxeda.o
+obj-$(CONFIG_CPU_IDLE_CLPS711X)	+= cpuidle-clps711x.o
 obj-$(CONFIG_ARCH_KIRKWOOD) += cpuidle-kirkwood.o
 obj-$(CONFIG_CPU_IDLE_ZYNQ) += cpuidle-zynq.o
diff --git a/drivers/cpuidle/cpuidle-clps711x.c b/drivers/cpuidle/cpuidle-clps711x.c
new file mode 100644
index 0000000..9f0129f
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-clps711x.c
@@ -0,0 +1,80 @@
+/*
+ *  CLPS711X CPU idle driver
+ *
+ *  Copyright (C) 2013 Alexander Shiyan <shc_work at mail.ru>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/cpuidle.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+static void __iomem *clps711x_halt;
+
+static int clps711x_cpuidle_halt(struct cpuidle_device *dev,
+				 struct cpuidle_driver *drv, int index)
+{
+	writel(1, clps711x_halt);
+	asm volatile ("mov r0, r0");
+	asm volatile ("mov r0, r0");
+
+	return index;
+}
+
+static struct cpuidle_driver clps711x_idle_driver = {
+	.name			= "clps711x_idle",
+	.owner			= THIS_MODULE,
+	.state_count		= 1,
+	.states[0]	= {
+		.name		= "HALT",
+		.desc		= "CLPS711X WFI",
+		.enter		= clps711x_cpuidle_halt,
+		.exit_latency	= 1,
+	},
+};
+
+static int __init clps711x_cpuidle_probe(struct platform_device *pdev)
+{
+	struct resource *res;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	clps711x_halt = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(clps711x_halt))
+		return PTR_ERR(clps711x_halt);
+
+	return cpuidle_register(&clps711x_idle_driver, NULL);
+}
+
+static int clps711x_cpuidle_remove(struct platform_device *pdev)
+{
+	cpuidle_unregister(&clps711x_idle_driver);
+
+	return 0;
+}
+
+static const struct of_device_id clps711x_cpuidle_dt_ids[] = {
+	{ .compatible = "cirrus,clps711x-cpuidle", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, clps711x_cpuidle_dt_ids);
+
+static struct platform_driver clps711x_cpuidle_driver = {
+	.driver	= {
+		.name		= "clps711x-cpuidle",
+		.owner		= THIS_MODULE,
+		.of_match_table	= clps711x_cpuidle_dt_ids,
+	},
+	.remove	= clps711x_cpuidle_remove,
+};
+module_platform_driver_probe(clps711x_cpuidle_driver, clps711x_cpuidle_probe);
+
+MODULE_AUTHOR("Alexander Shiyan <shc_work at mail.ru>");
+MODULE_DESCRIPTION("CLPS711X CPU idle driver");
+MODULE_LICENSE("GPL");
-- 
1.8.1.5



From shc_work at mail.ru  Thu Jul 18 14:34:57 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Thu, 18 Jul 2013 22:34:57 +0400
Subject: [PATCH 06/10] ARM: clps711x: Add CLPS711X clocksource driver
In-Reply-To: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374172501-26796-7-git-send-email-shc_work@mail.ru>

This adds the clocksource driver for Cirrus Logic CLPS711X series SoCs.
Designed primarily for migration CLPS711X subarch for multiplatform & DT,
for this as the "OF" and "not-OF" calls implemented.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/Kconfig                      |   2 -
 drivers/clocksource/Kconfig           |   6 ++
 drivers/clocksource/Makefile          |   1 +
 drivers/clocksource/clps711x-clksrc.c | 151 ++++++++++++++++++++++++++++++++++
 4 files changed, 158 insertions(+), 2 deletions(-)
 create mode 100644 drivers/clocksource/clps711x-clksrc.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dfb1e7f..5c60cb7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -370,10 +370,8 @@ config ARCH_CLPS711X
 	bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
 	select ARCH_REQUIRE_GPIOLIB
 	select AUTO_ZRELADDR
-	select CLKSRC_MMIO
 	select COMMON_CLK
 	select CPU_ARM720T
-	select GENERIC_CLOCKEVENTS
 	select MFD_SYSCON
 	select MULTI_IRQ_HANDLER
 	select SPARSE_IRQ
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index b7b9b04..bd6dc82 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -41,6 +41,12 @@ config VT8500_TIMER
 config CADENCE_TTC_TIMER
 	bool
 
+config CLKSRC_CLPS711X
+	def_bool y if ARCH_CLPS711X
+	select CLKSRC_MMIO
+	select CLKSRC_OF if OF
+	select GENERIC_CLOCKEVENTS
+
 config CLKSRC_NOMADIK_MTU
 	bool
 	depends on (ARCH_NOMADIK || ARCH_U8500)
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 8b00c5c..da6c102 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_CLKBLD_I8253)	+= i8253.o
 obj-$(CONFIG_CLKSRC_MMIO)	+= mmio.o
 obj-$(CONFIG_DW_APB_TIMER)	+= dw_apb_timer.o
 obj-$(CONFIG_DW_APB_TIMER_OF)	+= dw_apb_timer_of.o
+obj-$(CONFIG_CLKSRC_CLPS711X)	+= clps711x-clksrc.o
 obj-$(CONFIG_CLKSRC_NOMADIK_MTU)	+= nomadik-mtu.o
 obj-$(CONFIG_CLKSRC_DBX500_PRCMU)	+= clksrc-dbx500-prcmu.o
 obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
diff --git a/drivers/clocksource/clps711x-clksrc.c b/drivers/clocksource/clps711x-clksrc.c
new file mode 100644
index 0000000..1749b0b
--- /dev/null
+++ b/drivers/clocksource/clps711x-clksrc.c
@@ -0,0 +1,151 @@
+/*
+ *  CLPS711X clocksource driver
+ *
+ *  Copyright (C) 2013 Alexander Shiyan <shc_work at mail.ru>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/clocksource.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/sched_clock.h>
+#include <linux/slab.h>
+
+#include <linux/mfd/syscon/clps711x.h>
+
+#define CLPS711X_SYSCON1	(0x0100)
+#define CLPS711X_TC1D		(0x0300)
+#define CLPS711X_TC2D		(0x0340)
+
+static struct {
+	void __iomem	*tc1d;
+	int		irq;
+} *clps711x_clksrc;
+
+static u32 notrace clps711x_sched_clock_read(void)
+{
+	return ~readw(clps711x_clksrc->tc1d);
+}
+
+static void clps711x_clockevent_set_mode(enum clock_event_mode mode,
+					 struct clock_event_device *evt)
+{
+	disable_irq(clps711x_clksrc->irq);
+
+	switch (mode) {
+	case CLOCK_EVT_MODE_PERIODIC:
+		enable_irq(clps711x_clksrc->irq);
+		break;
+	case CLOCK_EVT_MODE_ONESHOT:
+		/* Not supported */
+	case CLOCK_EVT_MODE_SHUTDOWN:
+	case CLOCK_EVT_MODE_UNUSED:
+	case CLOCK_EVT_MODE_RESUME:
+		/* Left event sources disabled, no more interrupts appear */
+		break;
+	}
+}
+
+static struct clock_event_device clps711x_clockevent = {
+	.name		= "clps711x-clockevent",
+	.rating		= 300,
+	.features	= CLOCK_EVT_FEAT_PERIODIC,
+	.set_mode	= clps711x_clockevent_set_mode,
+};
+
+static irqreturn_t clps711x_timer_interrupt(int irq, void *dev_id)
+{
+	clps711x_clockevent.event_handler(&clps711x_clockevent);
+
+	return IRQ_HANDLED;
+}
+
+static struct irqaction clps711x_timer_irq = {
+	.name		= "clps711x-timer",
+	.flags		= IRQF_TIMER | IRQF_IRQPOLL,
+	.handler	= clps711x_timer_interrupt,
+};
+
+static void __init _clps711x_clksrc_init(phys_addr_t phys_base, int irq,
+					 struct clk *tc1, struct clk *tc2)
+{
+	unsigned long tc1_rate, tc2_rate;
+	void __iomem *tc2d, *syscon1;
+	u32 tmp;
+
+	BUG_ON(IS_ERR(tc1) || IS_ERR(tc2));
+
+	BUG_ON(!request_mem_region(phys_base + CLPS711X_TC1D, SZ_2, NULL));
+	BUG_ON(!request_mem_region(phys_base + CLPS711X_TC2D, SZ_2, NULL));
+
+	clps711x_clksrc = kzalloc(sizeof(*clps711x_clksrc), GFP_KERNEL);
+	BUG_ON(!clps711x_clksrc);
+
+	clps711x_clksrc->tc1d = ioremap(phys_base + CLPS711X_TC1D, SZ_2);
+	BUG_ON(!clps711x_clksrc->tc1d);
+
+	tc2d = ioremap(phys_base + CLPS711X_TC2D, SZ_2);
+	BUG_ON(!tc2d);
+
+	syscon1 = ioremap(phys_base + CLPS711X_SYSCON1, SZ_4);
+	BUG_ON(!syscon1);
+
+	clps711x_clksrc->irq = irq;
+
+	tmp = readl(syscon1);
+	/* TC1 in free running mode */
+	tmp &= ~SYSCON1_TC1M;
+	/* TC2 in prescale mode */
+	tmp |= SYSCON1_TC2M;
+	writel(tmp, syscon1);
+
+	tc1_rate = clk_get_rate(tc1);
+	tc2_rate = clk_get_rate(tc2);
+
+	clocksource_mmio_init(clps711x_clksrc->tc1d, "clps711x-clocksource",
+			      tc1_rate, 300, 16, clocksource_mmio_readw_down);
+
+	setup_sched_clock(clps711x_sched_clock_read, 16, tc1_rate);
+
+	/* Set Timer prescaler */
+	writew(DIV_ROUND_CLOSEST(tc2_rate, HZ), tc2d);
+
+	clockevents_config_and_register(&clps711x_clockevent, tc2_rate, 0, 0);
+
+	BUG_ON(setup_irq(clps711x_clksrc->irq, &clps711x_timer_irq));
+}
+
+void __init clps711x_clksrc_init(phys_addr_t phys_base, int irq)
+{
+	struct clk *tc1 = clk_get(NULL, "tc1");
+	struct clk *tc2 = clk_get(NULL, "tc2");
+
+	_clps711x_clksrc_init(phys_base, irq, tc1, tc2);
+}
+
+#ifdef CONFIG_CLKSRC_OF
+static void __init clps711x_clksrc_init_dt(struct device_node *np)
+{
+	struct clk *tc1 = of_clk_get_by_name(np, "tc1");
+	struct clk *tc2 = of_clk_get_by_name(np, "tc2");
+	struct resource res_io, res_irq;
+
+	BUG_ON(!of_address_to_resource(np, 0, &res_io));
+
+	BUG_ON(!of_irq_to_resource(np, 0, &res_irq));
+
+	_clps711x_clksrc_init(res_io.start, res_irq.start, tc1, tc2);
+}
+CLOCKSOURCE_OF_DECLARE(clps711x, "cirrus,clps711x-clocksource",
+		       clps711x_clksrc_init_dt);
+#endif
-- 
1.8.1.5



From olof at lixom.net  Thu Jul 18 14:45:29 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 18 Jul 2013 11:45:29 -0700
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <20130718112555.GB1021@amd.pavel.ucw.cz>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <20130716041056.GA30067@S2101-09.ap.freescale.net>
 <51E56AA7.7020103@wwwdotorg.org>
 <20130717030246.GA4541@S2101-09.ap.freescale.net>
 <51E6CCE4.20705@wwwdotorg.org>
 <20130717213836.GA13324@amd.pavel.ucw.cz>
 <51E719A6.6070105@wwwdotorg.org>
 <20130718112555.GB1021@amd.pavel.ucw.cz>
Message-ID: <CAOesGMgi0j_mPyeBLVHb_QW+DwtAPoFY697eQO3-yp9tnP1vmA@mail.gmail.com>

Hi,

On Thu, Jul 18, 2013 at 4:25 AM, Pavel Machek <pavel at denx.de> wrote:

> It sound to me like keeping ammount of -EPROBE_DEFER to minimum is
> still preferred.

Hand-crafting initcall level ordering of various drivers and subsystem
is probably an even greater evil though. We've done it in the past,
but now that we have deferred probe we have the option of not having
to do it every time, such as this.

You're spending an awful lot of energy arguing over this, but nobody
has actually shown data of how much deferral is happening -- and that
it's a real problem. Until someone does so there's no reason to change
it from the default module init level at all, I'd say.


-Olof


From shc_work at mail.ru  Thu Jul 18 14:34:51 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Thu, 18 Jul 2013 22:34:51 +0400
Subject: [PATCH 00/10] ARM: clps711x: Initial DT support / Fixes
Message-ID: <1374172501-26796-1-git-send-email-shc_work@mail.ru>

Here is next patchset for the Cirrus Logic CLPS711X target CPUs.
The first four patches is a small fixes. The rest is a attempt
to add DT support for this subarch.
As long as DT support is incomplete (no peripherals), I did not
add DTS yet. This is the next step.

Alexander Shiyan (10):
  ARM: clps711x: Remove the special name for the syscon driver
  ARM: clps711x: Drop fortunet board support
  ARM: clps711x: autcpu12: Remove incorrect config checking
  ARM: clps711x: edb7211: Remove extra iotable_init() call
  ARM: clps711x: Add CLPS711X clk driver
  ARM: clps711x: Add CLPS711X clocksource driver
  ARM: clps711x: Add CLPS711X irqchip driver
  ARM: clps711x: Add CLPS711X cpuidle driver
  ARM: clps711x: Migrate CLPS711X subarch to the new basic drivers
  ARM: clps711x: Add initial DT support

 .../devicetree/bindings/clock/clps711x-clock.txt   |  47 +++
 .../interrupt-controller/cirrus,clps711x-intc.txt  |  42 +++
 arch/arm/Kconfig                                   |   5 -
 arch/arm/mach-clps711x/Kconfig                     |   8 +-
 arch/arm/mach-clps711x/Makefile                    |   2 +-
 arch/arm/mach-clps711x/board-autcpu12.c            |   9 +-
 arch/arm/mach-clps711x/board-cdb89712.c            |   3 -
 arch/arm/mach-clps711x/board-clep7312.c            |   3 -
 arch/arm/mach-clps711x/board-dt.c                  |  56 ++++
 arch/arm/mach-clps711x/board-edb7211.c             |  20 +-
 arch/arm/mach-clps711x/board-fortunet.c            |  85 -----
 arch/arm/mach-clps711x/board-p720t.c               |   3 -
 arch/arm/mach-clps711x/common.c                    | 345 +--------------------
 arch/arm/mach-clps711x/common.h                    |   3 -
 arch/arm/mach-clps711x/devices.c                   |  12 +-
 drivers/clk/Makefile                               |   1 +
 drivers/clk/clk-clps711x.c                         | 150 +++++++++
 drivers/clocksource/Kconfig                        |   6 +
 drivers/clocksource/Makefile                       |   1 +
 drivers/clocksource/clps711x-clksrc.c              | 151 +++++++++
 drivers/cpuidle/Kconfig                            |   6 +
 drivers/cpuidle/Makefile                           |   1 +
 drivers/cpuidle/cpuidle-clps711x.c                 |  80 +++++
 drivers/irqchip/Kconfig                            |   6 +
 drivers/irqchip/Makefile                           |   1 +
 drivers/irqchip/irq-clps711x.c                     | 277 +++++++++++++++++
 drivers/mfd/syscon.c                               |   3 -
 27 files changed, 851 insertions(+), 475 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/clps711x-clock.txt
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt
 create mode 100644 arch/arm/mach-clps711x/board-dt.c
 delete mode 100644 arch/arm/mach-clps711x/board-fortunet.c
 create mode 100644 drivers/clk/clk-clps711x.c
 create mode 100644 drivers/clocksource/clps711x-clksrc.c
 create mode 100644 drivers/cpuidle/cpuidle-clps711x.c
 create mode 100644 drivers/irqchip/irq-clps711x.c

-- 
1.8.1.5



From nm at ti.com  Thu Jul 18 14:56:15 2013
From: nm at ti.com (Nishanth Menon)
Date: Thu, 18 Jul 2013 13:56:15 -0500
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
Message-ID: <51E83A4F.5080904@ti.com>

On 07/18/2013 11:43 AM, Sricharan R wrote:
> Some socs have a large number of interrupts/dma requests to service
> the needs of its many peripherals and subsystems. All of the
> requests lines from the subsystems are not needed at the same
> time, so they have to be muxed to the controllers appropriately.
> In such places a interrupt/dma controllers are preceded by an
> IRQ/DMA CROSSBAR that provides flexibility in muxing the device
> requests to the controller inputs.
>
> The Peripheral irq/dma requests are connected to one crossbar's input
> and the output of the crossbar is connected to controller's input
> line. On POR, there are some mappings which are done by default.
> Those peripherals which do not have a mapping on POR, should be configured
> to route its requests using the crossbar.
>
> The drivers identifies every controller's crossbar as individual devices.
> The mappings can be specified from the DT crossbar nodes and those gets mapped
> during the crossbar device's probe. The mappings can also be specified by adding
> the crossbar lines to the peripheral device nodes and map it with
> crossbar_map/unmap apis.
>
> Signed-off-by: Sricharan R <r.sricharan at ti.com>
> ---
>   .../devicetree/bindings/arm/omap/crossbar.txt      |   24 ++
>   drivers/misc/Kconfig                               |    8 +
>   drivers/misc/Makefile                              |    1 +
>   drivers/misc/crossbar.c                            |  258 ++++++++++++++++++++
>   include/linux/crossbar.h                           |   71 ++++++
>   5 files changed, 362 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
>   create mode 100644 drivers/misc/crossbar.c
>   create mode 100644 include/linux/crossbar.h
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> new file mode 100644
> index 0000000..02a8a28
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> @@ -0,0 +1,24 @@
> +* TI - IRQ/DMA Crossbar
> +
> +This version is an implementation of the Crossbar IRQ/DMA IP
> +
> +Required properties:
> +- compatible : Should be "ti,dra-crossbar"
> +- crossbar-name: Name of the controller to which crossbar output is routed
> +- reg:	Contains crossbar register address range
> +- reg-width: Represents the width of the individual registers
> +- crossbar-lines:  Default mappings.Should contain the crossbar-name
> +		   device name, int/dma request number, crossbar number,
> +		   register offset in the same order.
> +
> +Examples:
> +		crossbar_mpu: mpuirq at 4a002a48 {
> +			compatible = "crossbar";
> +			crossbar-name = "mpu-irq";
> +			reg = <0x4a002a48 0x0130>;
> +			reg-width = <16>;
> +			crossbar-lines = "mpu-irq", "rtc-ss-alarm", <0x9f 0xd9 0x12c>,
> +					 "mpu-irq", "mcasp3-arevt", <0x9e 0x96 0x12a>,
> +					 "mpu-irq", "mcasp3-axevt", <0x9d 0x97 0x128>;
> +		};

I carry forward my TI internal objection to this approach:

NAK.

DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt 
is as follows:
hardware IP block -interrupt line-> IRQ Cross bar -> GIC IRQ line --> 
MPU IRQ.


What we have done today for DRA is to provide IRQ numbers as direct maps 
from hardware IP block to GIC based on default IRQ cross bar mapping.

Lets see what happens as a result of this:

https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
uart1: serial at 4806a000 {
<snip>
+			interrupts = <0 72 0x4>;
Assumes that GIC interrupt by default mapping used.

Now, think of a product that wants to use UART10 instead of UART1, SoC 
design allows you do that by doing a remapping of GIC interrupt to 
UART10 - which is awesome.

Option 1: u-boot/bootloader
mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,

Option 2: in kernel do a raw_writel version of option 1.
This patch does option 1 in kernel in a "fancy way" - why the heck would 
I want to do that when u-boot allows me to do the same thing in uEnv.txt

Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
a) Allows us to define every single IP available on DRA7 SoC.
b) GIC allocation happens dynamically
c) allow products use IPs as needed.

Sorry, Conceptually option 3 is the right approach in my view.
instead of doing
uart1: serial at 4806a000 {
<snip>
+			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;

we should be able to do the following:
uart1: serial at 4806a000 {
<snip>
+			interrupts = <TI_IRQ_CROSSBAR 192 IRQ_TYPE_LEVEL_HIGH>;

and not worry about the GIC interrupt number used


-- 
Regards,
Nishanth Menon


From joelf at ti.com  Thu Jul 18 14:57:33 2013
From: joelf at ti.com (Joel Fernandes)
Date: Thu, 18 Jul 2013 13:57:33 -0500
Subject: [PATCH 1/3] dmaengine: add dma_get_slave_sg_limits()
In-Reply-To: <20130718170825.GZ21614@n2100.arm.linux.org.uk>
References: <1374166001-31340-1-git-send-email-joelf@ti.com>
 <1374166001-31340-2-git-send-email-joelf@ti.com>
 <20130718170825.GZ21614@n2100.arm.linux.org.uk>
Message-ID: <51E83A9D.5020008@ti.com>

On 07/18/2013 12:08 PM, Russell King - ARM Linux wrote:
> On Thu, Jul 18, 2013 at 11:46:39AM -0500, Joel Fernandes wrote:
>> The API is optionally implemented by dmaengine drivers and when
>> unimplemented will return a NULL pointer. A client driver using
>> this API provides the required dma channel, address width, and
>> burst size of the transfer. dma_get_slave_sg_limits() returns an
>> SG limits structure with the maximum number and size of SG segments
>> that the given channel can handle.
> 
> Please look at what's already in struct device:
> 
> struct device {
> ...
>         struct device_dma_parameters *dma_parms;
> ...
> };
> 
> This provides:
> 
> struct device_dma_parameters {
>         /*
>          * a low level driver may set these to teach IOMMU code about
>          * sg limitations.
>          */
>         unsigned int max_segment_size;
>         unsigned long segment_boundary_mask;
> };
> 
> Now, these are helpfully accessed via:
> 
> dma_get_max_seg_size(dev)
> dma_set_max_seg_size(dev)
> dma_get_seg_boundary(dev)
> dma_set_seg_boundary(dev, mask)
> Drivers already use these to work out how to construct the scatterlist
> before passing it to the DMA API, which means that they should also be
> used when creating a scatterlist for the DMA engine (think about it -
> you have to use the DMA API to map the buffers for the DMA engine too.)
> 
> So, we already have two properties defined on a per-device basis: the
> maximum size of a scatterlist segment, and the boundary over which any
> segment must not cross.
> 
> The former ties up with your max_seg_len() property, though arguably it
> may depend on the DMA engine access size.  The problem with implementing
> this new API though is that the subsystems (such as SCSI) which already
> use dma_get_max_seg_size() will be at odds with what is possible via the
> DMA engine.

Not very clear for this particular case, are you saying the DMAEngine
driver implementation should set the max_seg_size of its own struct dev,
and then the drivers retrieve it from the channel they are allocated?

> I strongly suggest using the infrastructure at device level and not
> implementing some private DMA engine API to convey this information.

Certainly see the value. OK with either approach. Can Vinod add to the
discussion here, and we can decide a way forward? Is it ok to use the
new CAPS API added for now so that we can keep AM33xx MMC alive?
seg_size atleast is a real regression, the number of slots limit however
is related more to MMC grabbing a lot of slots. Atleast for -rc cycle
the seg_size and MMC fixes should go in.

> As for the maximum number of scatterlist entries, really that's a bug in
> the DMA engine implementations if they can't accept arbitary lengths.
> I've created DMA engine drivers for implementations where you have to
> program each segment individually, ones which can have the current and
> next segments, as well as those which can walk a list.  Provided you get
> informed of a transfer being completed, there really is no reason for a
> DMA engine driver to limit the number of scatterlist entries that it
> will accept.

Sure, that makes sense. Can you point to such a typical example
implementation to get some ideas?

Thanks,

-Joel


From nicolas.pitre at linaro.org  Thu Jul 18 14:59:06 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Jul 2013 14:59:06 -0400 (EDT)
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <20130718180323.GC2655@localhost.localdomain>
References: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
 <1374118116-16836-2-git-send-email-nicolas.pitre@linaro.org>
 <20130718150408.GB2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181231510.14924@syhkavp.arg>
 <20130718180323.GC2655@localhost.localdomain>
Message-ID: <alpine.LFD.2.03.1307181452480.14924@syhkavp.arg>

On Thu, 18 Jul 2013, Dave Martin wrote:

> On Thu, Jul 18, 2013 at 01:24:48PM -0400, Nicolas Pitre wrote:
> > [ added Russell for his opinion on the patch below ]
> 
> [...]
> 
> > commit 390cf8b9b83eeeebdfef51912f5003a6a9b84115
> > Author: Nicolas Pitre <nicolas.pitre at linaro.org>
> > Date:   Thu Jul 18 13:12:48 2013 -0400
> > 
> >     ARM: cacheflush: consolidate single-CPU ARMv7 cache disabling code
> >     
> >     This code is becoming duplicated in many places.  So let's consolidate
> >     it into a handy macro that is known to be right and available for reuse.
> >     
> >     Signed-off-by: Nicolas Pitre <nico at linaro.org>
> > 
> > diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
> > index 17d0ae8672..8a76933e80 100644
> > --- a/arch/arm/include/asm/cacheflush.h
> > +++ b/arch/arm/include/asm/cacheflush.h
> > @@ -436,4 +436,33 @@ static inline void __sync_cache_range_r(volatile void *p, size_t size)
> >  #define sync_cache_w(ptr) __sync_cache_range_w(ptr, sizeof *(ptr))
> >  #define sync_cache_r(ptr) __sync_cache_range_r(ptr, sizeof *(ptr))
> >  
> > +/*
> > + * Disabling cache access for one CPU in an ARMv7 SMP system is tricky.
> > + * To do so we must:
> > + *
> > + * - Clear the SCTLR.C bit to prevent further cache allocations
> > + * - Flush the desired level of cache
> > + * - Clear the ACTLR "SMP" bit to disable local coherency
> > + *
> > + * ... and so without any intervening memory access in between those steps,
> > + * not even to the stack.
> > + *
> > + * The clobber list is dictated by the call to v7_flush_dcache_*.
> > + */
> > +#define v7_disable_flush_cache(level) \
> > +	asm volatile( \
> > +	"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t" \
> > +	"bic	r0, r0, #"__stringify(CR_C)" \n\t" \
> > +	"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t" \
> > +	"isb	\n\t" \
> > +	"bl	v7_flush_dcache_"__stringify(level)" \n\t" \
> > +	"clrex	\n\t" \
> > +	"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t" \
> > +	"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t" \
> > +	"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t" \
> > +	"isb	\n\t" \
> > +	"dsb	" \
> > +	: : : "r0","r1","r2","r3","r4","r5","r6","r7", \
> > +	      "r9","r10","r11","lr","memory" )
> > +
> >  #endif
> 
> That's roughly what I had in mind, though it might belong somewhere more
> obscure than cacheflush.h(?)

Any suggestions for that?  Maybe asm/mcpm.h but that might be used in 
other circumstances as well.

> "disable_flush_cache" sounds a too general-purpose for my liking.
> 
> "v7" isn't really right because we touch the ACTLR.  This only works
> on certain CPUs and when Linux is running Secure.  Maybe saying "a15"
> instead of "a7" is reasonable, since a7 is supposed to be an a15
> workalike in most places.

Isn't this how this should be done on an A9 too?  Lorenzo asked me to do 
it this way, by fear of seeing people copy the previous implementation, 
so the same sequence works on A9 as well as A15.

> I had other names in mind, like "coherency_exit" or "cache_exit".
> Those are not very intelligible, but that might at least make people
> pause and think before blindly using it.

Good point.  It should still embody the architecture name for which it 
is valid though.


Nicolas


From nm at ti.com  Thu Jul 18 15:04:38 2013
From: nm at ti.com (Nishanth Menon)
Date: Thu, 18 Jul 2013 14:04:38 -0500
Subject: [PATCH 2/3] ARM: dts: DRA: Add crossbar device binding
In-Reply-To: <1374165830-6367-3-git-send-email-r.sricharan@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-3-git-send-email-r.sricharan@ti.com>
Message-ID: <51E83C46.3040000@ti.com>

On 07/18/2013 11:43 AM, Sricharan R wrote:
> This adds the irq/dma crossbar device nodes.
>
> There is a IRQ and DMA crossbar device in the soc, which
> maps the irq/dma requests from the peripherals to the
> mpu/dsp/ipu/eve interrupt and sdma/edma controller's inputs.
> The Peripheral irq/dma requests are connected to only one crossbar
> input and the output of the crossbar is connected to only one
> controller's input line. On POR, there are some mappings which
> are done by default. Those peripherals which do not have a
> mapping on POR, should be configured to route its requests
> using the crossbar control registers.
>

What is POR? Plan on Record? I supppose, we just love our TLA?

> The irq/dma mapping for some peripherals are
> added with the crossbar nodes here.
>
> Signed-off-by: Sricharan R <r.sricharan at ti.com>
> ---
>   arch/arm/boot/dts/dra7.dtsi |   19 +++++++++++++++++++
>   1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index a5d9350..e6208b4 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -85,6 +85,25 @@
>   		ranges;
>   		ti,hwmods = "l3_main_1", "l3_main_2";
>
> +		crossbar_mpu: mpuirq at 4a002a48 {
> +			compatible = "crossbar";
> +			crossbar-name = "mpu-irq";
> +			reg = <0x4a002a48 0x0130>;
> +			reg-width = <16>;
> +			crossbar-lines = "mpu-irq", "rtc-ss-alarm", <0x9f 0xd9 0x12c>,
> +					 "mpu-irq", "mcasp3-arevt", <0x9e 0x96 0x12a>,
> +					 "mpu-irq", "mcasp3-axevt", <0x9d 0x97 0x128>;

a) I'd like to use UART10. oh, let me guess: we dont map all cross bar 
options here.. just "certain ones"
b) I like to use random 6 uarts out of the available 10 uarts on the fly.
c) I'd like to use IRQCROSS bar such that i use all the hardware block 
instances that dont have default GIC IRQ mapping.


> +		};
> +
> +		crossbar_dma: dmareq at 4a002b78 {
> +			compatible = "crossbar";
> +			crossbar-name = "dma-req";
> +			reg = <0x4a002b78 0x0100>;
> +			reg-width = <16>;
> +			crossbar-lines = "dma-req", "mcasp3-rx", <0x7e 0x84 0xfc>,
> +					 "dma-req", "mcasp3-tx", <0x7d 0x85 0xfa>;
> +		};
> +
>   		counter32k: counter at 4ae04000 {
>   			compatible = "ti,omap-counter32k";
>   			reg = <0x4ae04000 0x40>;
>


-- 
Regards,
Nishanth Menon


From swarren at wwwdotorg.org  Thu Jul 18 15:21:02 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 13:21:02 -0600
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130718072034.GO7656@atomide.com>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost> <51E70953.1000601@wwwdotorg.org>
 <20130718072034.GO7656@atomide.com>
Message-ID: <51E8401E.8040705@wwwdotorg.org>

On 07/18/2013 01:25 AM, Tony Lindgren wrote:
> * Stephen Warren <swarren at wwwdotorg.org> [130717 14:21]:
>> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
>>> To toggle dynamic states, let's add the optional active state in
>>> addition to the static default state. Then if the optional active
>>> state is defined, we can require that idle and sleep states cover
>>> the same pingroups as the active state.
>>>
>>> Then let's add pinctrl_check_dynamic() and pinctrl_select_dynamic()
>>> to use instead of pinctrl_select() to avoid breaking existing users.
>>>
>>> With pinctrl_check_dynamic() we can check that idle and sleep states
>>> match the active state for pingroups during init, and don't need to
>>> do it during runtime.
>>>
>>> Then with the states pre-validated, pinctrl_select_dynamic() can
>>> just toggle between the dynamic states without extra checks.
>>>
>>> Note that pinctr_select_state() still has valid use cases, such as
>>> changing states when the pins can be shared between two drivers
>>> and don't necessarily cover the same pingroups. For dynamic runtime
>>> toggling of pin states, we should eventually always use just
>>> pinctrl_select_dynamic().

>>> @@ -1241,7 +1371,13 @@ static int pinctrl_pm_select_state(struct device *dev, struct pinctrl_state *sta
>>>  		return 0;
>>>  	if (IS_ERR(state))
>>>  		return 0; /* No such state */
>>> -	ret = pinctrl_select_state(pins->p, state);
>>> +
>>> +	/* Configured for proper dynamic muxing? */
>>> +	if (!IS_ERR(dev->pins->active_state))
>>> +		ret = pinctrl_select_dynamic(pins->p, state);
>>> +	else
>>> +		ret = pinctrl_select_state(pins->p, state);
>>
>> Hmmm. I'm not quite sure this is right... Surely this function should
>> just do nothing if the dynamic states aren't defined? The system should
>> just, and only, be in the "default" state and never do anything else.
> 
> This keeps the existing behaviour. We should be able to drop the
> call to pinctrl_select_state() here after the existing use in
> drivers has been fixed.

How many DT-based systems already have multiple of default/idle/sleep
states defined in DT? Right now, since the kernel code uses
pinctrl_select_state() to switch between those, the state definitions
need to define /all/ pins used by those states, not just the dynamic
ones. However, with this series in place, the default state should only
include the static pins, and the active/idle/sleep states should only
include the dynamic pins. That's a change to the DT bindings, since it
changes how the DT must be written, and causes older DTs to be
incompatible with newer kernels and vice-versa.

So, do we just ignore this DT ABI change again, or insist on doing it in
some compatible way? DT ABI-ness is a PITA:-(


From swarren at wwwdotorg.org  Thu Jul 18 15:26:56 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 13:26:56 -0600
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130718073638.GP7656@atomide.com>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost> <51E70B5D.6030802@wwwdotorg.org>
 <20130718073638.GP7656@atomide.com>
Message-ID: <51E84180.6080902@wwwdotorg.org>

On 07/18/2013 01:36 AM, Tony Lindgren wrote:
> * Stephen Warren <swarren at wwwdotorg.org> [130717 14:30]:
>> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
...
>> Why shouldn't e.g. a pinctrl-based I2C mux also be able to do runtime
>> PM? Does the mux setting select which states are used for runtime PM, or
>> does runtime PM override the basic mux setting, or must the pincrl-I2C
>> mux manually implement custom runtime-PM/pinctrl interaction since
>> there's no generic answer to those questions? How many more custom
>> exceptions will there be?
> 
> The idea is that runtime PM will never touch the basic mux settings
> at all. The "default" state should be considered a static state
> that is claimed during driver probe, and released when the driver
> is unloaded. This is typically let's say 90% of the pins for any
> device.
> 
> For runtime PM, we can just toggle the PM related pinctrl states as
> they have been verified to match the active state during init.
> 
> So I don't see why pinctrl-I2C would have to do anything specific.
> All that is required is that the pins are grouped for the consumer
> driver, and we can provide some automated checks on the states for
> runtime PM.

So, consider a pinctrl-based I2C mux. It has 2 states to cover two I2C
buses:

a) bus 1: I2C controller is muxed out onto one set of pins.

b) bus 2: I2C controller is muxed out onto another set of pins.

Now, the system could go idle in either of those 2 states, and then
later need to return to one of those states. I just don't see how that
would work, since the runtime PM code in this series switches to *an*
active state when the device becomes non-idle. If the definition of the
idle state switches the mux function for both sets of pins to some
idle/quiescent value, then you'd need to do different reprogramming when
going back to "the" active state; I guess the system would need to
remember which state was active before switching to idle, then switch
back to that same state rather than hard-coding the active state name as
"active"...


From andi at etezian.org  Thu Jul 18 15:35:30 2013
From: andi at etezian.org (Andi Shyti)
Date: Thu, 18 Jul 2013 21:35:30 +0200
Subject: [PATCH] u8500_defconfig: allow creation and mounting of devtmpfs
Message-ID: <1374176130-21209-1-git-send-email-andi@etezian.org>

This patch enables CONFIG_DETTMPFS and CONFIG_DEVTMPFS_MOUNT
flags for u8500 based devices.

In this way it's possible to create a tmpfs/ramfs already in the
early stages of the boot, allowing programs like udev/mdev to
populate the /dev directory.

Signed-off-by: Andi Shyti <andi at etezian.org>
---
 arch/arm/configs/u8500_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
index a0025dc..0675d6a 100644
--- a/arch/arm/configs/u8500_defconfig
+++ b/arch/arm/configs/u8500_defconfig
@@ -109,6 +109,8 @@ CONFIG_EXT2_FS_SECURITY=y
 CONFIG_EXT3_FS=y
 CONFIG_EXT4_FS=y
 CONFIG_VFAT_FS=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_TMPFS=y
 CONFIG_TMPFS_POSIX_ACL=y
 # CONFIG_MISC_FILESYSTEMS is not set
-- 
1.8.3.2



From swarren at wwwdotorg.org  Thu Jul 18 16:01:36 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 14:01:36 -0600
Subject: [PATCH v2 11/22] iommu/tegra: smmu: Add Tegra 114 support
In-Reply-To: <1373021097-32420-12-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-12-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E849A0.6040508@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> Tegra 114 SMMU uses the almost same logic as one in Tegra 30 except
> that they have different HaredWare Accelerators(HWA). Those difference
> is provided from DT.

> diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt

>  Required properties:
> -- compatible : "nvidia,tegra30-smmu"
> +- compatible : "nvidia,tegra114-smmu", "nvidia,tegra30-smmu"

So that we don't have to list every single chip in that list, we've
often written that as:

compatible : "nvidia,tegra<chip>-smmu".

> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c

>  static struct of_device_id tegra_smmu_of_match[] = {
> +	{ .compatible = "nvidia,tegra114-smmu", },
>  	{ .compatible = "nvidia,tegra30-smmu", },

So, there are no HW differences, and hence no driver changes required?
In that case, there's no point making the driver explicitly support
nvidia,tegra114-smmu, since the DT will always be:

compatible = "nvidia,tegra114-smmu", "nvidia,tegra30-smmu";

... and hence always match on the existing nvidia,tegra30-smmu entry in
that table.


From davidb at codeaurora.org  Thu Jul 18 16:07:12 2013
From: davidb at codeaurora.org (David Brown)
Date: Thu, 18 Jul 2013 13:07:12 -0700
Subject: [PATCH 0/3] MSM gpio fixes
Message-ID: <1374178035-19943-1-git-send-email-davidb@codeaurora.org>

Rohit sent these three fixes out on June 18.  I still need a
devicetree ack for the first patch, and would like these to get pulled
in for v3.11

Rohit Vaswani (3):
  ARM: msm: dts: Fix the gpio register address for msm8960
  drivers: gpio: msm: Fix the error condition for reading ngpio
  ARM: msm: Consolidate gpiomux for older architectures

 arch/arm/boot/dts/msm8960-cdp.dts |  4 ++--
 arch/arm/mach-msm/Kconfig         |  3 +--
 arch/arm/mach-msm/gpiomux-v1.c    | 33 ---------------------------------
 arch/arm/mach-msm/gpiomux.h       | 10 ----------
 drivers/gpio/gpio-msm-v2.c        |  2 +-
 5 files changed, 4 insertions(+), 48 deletions(-)
 delete mode 100644 arch/arm/mach-msm/gpiomux-v1.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From davidb at codeaurora.org  Thu Jul 18 16:07:13 2013
From: davidb at codeaurora.org (David Brown)
Date: Thu, 18 Jul 2013 13:07:13 -0700
Subject: [PATCH 1/3] ARM: msm: dts: Fix the gpio register address for msm8960
In-Reply-To: <1374178035-19943-1-git-send-email-davidb@codeaurora.org>
References: <1374178035-19943-1-git-send-email-davidb@codeaurora.org>
Message-ID: <1374178035-19943-2-git-send-email-davidb@codeaurora.org>

From: Rohit Vaswani <rvaswani at codeaurora.org>

Fix the the gpio reg address for the device tree entry.

Signed-off-by: Rohit Vaswani <rvaswani at codeaurora.org>
Signed-off-by: David Brown <davidb at codeaurora.org>
---
 arch/arm/boot/dts/msm8960-cdp.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/msm8960-cdp.dts b/arch/arm/boot/dts/msm8960-cdp.dts
index db2060c..9c1167b0 100644
--- a/arch/arm/boot/dts/msm8960-cdp.dts
+++ b/arch/arm/boot/dts/msm8960-cdp.dts
@@ -26,7 +26,7 @@
 		cpu-offset = <0x80000>;
 	};
 
-	msmgpio: gpio at fd510000 {
+	msmgpio: gpio at 800000 {
 		compatible = "qcom,msm-gpio";
 		gpio-controller;
 		#gpio-cells = <2>;
@@ -34,7 +34,7 @@
 		interrupts = <0 32 0x4>;
 		interrupt-controller;
 		#interrupt-cells = <2>;
-		reg = <0xfd510000 0x4000>;
+		reg = <0x800000 0x4000>;
 	};
 
 	serial at 16440000 {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From davidb at codeaurora.org  Thu Jul 18 16:07:15 2013
From: davidb at codeaurora.org (David Brown)
Date: Thu, 18 Jul 2013 13:07:15 -0700
Subject: [PATCH 3/3] ARM: msm: Consolidate gpiomux for older architectures
In-Reply-To: <1374178035-19943-1-git-send-email-davidb@codeaurora.org>
References: <1374178035-19943-1-git-send-email-davidb@codeaurora.org>
Message-ID: <1374178035-19943-4-git-send-email-davidb@codeaurora.org>

From: Rohit Vaswani <rvaswani at codeaurora.org>

Msm gpiomux can be used only for 7x30 and 8x50.
Prevent compilation and fix build issues on 7X00, 8X60 and 8960.

Signed-off-by: Rohit Vaswani <rvaswani at codeaurora.org>
Signed-off-by: David Brown <davidb at codeaurora.org>
---
 arch/arm/mach-msm/Kconfig      |  3 +--
 arch/arm/mach-msm/gpiomux-v1.c | 33 ---------------------------------
 arch/arm/mach-msm/gpiomux.h    | 10 ----------
 3 files changed, 1 insertion(+), 45 deletions(-)
 delete mode 100644 arch/arm/mach-msm/gpiomux-v1.c

diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 614e41e..905efc8 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -121,8 +121,7 @@ config MSM_SMD
 	bool
 
 config MSM_GPIOMUX
-	depends on !(ARCH_MSM8X60 || ARCH_MSM8960)
-	bool "MSM V1 TLMM GPIOMUX architecture"
+	bool
 	help
 	  Support for MSM V1 TLMM GPIOMUX architecture.
 
diff --git a/arch/arm/mach-msm/gpiomux-v1.c b/arch/arm/mach-msm/gpiomux-v1.c
deleted file mode 100644
index 27de2ab..0000000
--- a/arch/arm/mach-msm/gpiomux-v1.c
+++ /dev/null
@@ -1,33 +0,0 @@
-/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
- */
-#include <linux/kernel.h>
-#include "gpiomux.h"
-#include "proc_comm.h"
-
-void __msm_gpiomux_write(unsigned gpio, gpiomux_config_t val)
-{
-	unsigned tlmm_config  = (val & ~GPIOMUX_CTL_MASK) |
-				((gpio & 0x3ff) << 4);
-	unsigned tlmm_disable = 0;
-	int rc;
-
-	rc = msm_proc_comm(PCOM_RPC_GPIO_TLMM_CONFIG_EX,
-			   &tlmm_config, &tlmm_disable);
-	if (rc)
-		pr_err("%s: unexpected proc_comm failure %d: %08x %08x\n",
-		       __func__, rc, tlmm_config, tlmm_disable);
-}
diff --git a/arch/arm/mach-msm/gpiomux.h b/arch/arm/mach-msm/gpiomux.h
index 8e82f41..4410d77 100644
--- a/arch/arm/mach-msm/gpiomux.h
+++ b/arch/arm/mach-msm/gpiomux.h
@@ -73,16 +73,6 @@ extern struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS];
 int msm_gpiomux_write(unsigned gpio,
 		      gpiomux_config_t active,
 		      gpiomux_config_t suspended);
-
-/* Architecture-internal function for use by the framework only.
- * This function can assume the following:
- * - the gpio value has passed a bounds-check
- * - the gpiomux spinlock has been obtained
- *
- * This function is not for public consumption.  External users
- * should use msm_gpiomux_write.
- */
-void __msm_gpiomux_write(unsigned gpio, gpiomux_config_t val);
 #else
 static inline int msm_gpiomux_write(unsigned gpio,
 				    gpiomux_config_t active,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From davidb at codeaurora.org  Thu Jul 18 16:07:14 2013
From: davidb at codeaurora.org (David Brown)
Date: Thu, 18 Jul 2013 13:07:14 -0700
Subject: [PATCH 2/3] drivers: gpio: msm: Fix the error condition for reading
 ngpio
In-Reply-To: <1374178035-19943-1-git-send-email-davidb@codeaurora.org>
References: <1374178035-19943-1-git-send-email-davidb@codeaurora.org>
Message-ID: <1374178035-19943-3-git-send-email-davidb@codeaurora.org>

From: Rohit Vaswani <rvaswani at codeaurora.org>

of_property_read_u32 return 0 on success. The check was using a ! to
return error. Fix the if condition.

Signed-off-by: Rohit Vaswani <rvaswani at codeaurora.org>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Reviewed-by: Pankaj Jangra  <jangra.pankaj9 at gmail.com>
Cc: "Bird, Tim" <Tim.Bird at sonymobile.com>
Signed-off-by: David Brown <davidb at codeaurora.org>
---
 drivers/gpio/gpio-msm-v2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-msm-v2.c b/drivers/gpio/gpio-msm-v2.c
index f4491a4..c2fa770 100644
--- a/drivers/gpio/gpio-msm-v2.c
+++ b/drivers/gpio/gpio-msm-v2.c
@@ -378,7 +378,7 @@ static int msm_gpio_probe(struct platform_device *pdev)
 	int ret, ngpio;
 	struct resource *res;
 
-	if (!of_property_read_u32(pdev->dev.of_node, "ngpio", &ngpio)) {
+	if (of_property_read_u32(pdev->dev.of_node, "ngpio", &ngpio)) {
 		dev_err(&pdev->dev, "%s: ngpio property missing\n", __func__);
 		return -EINVAL;
 	}
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From swarren at wwwdotorg.org  Thu Jul 18 16:10:29 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 14:10:29 -0600
Subject: [PATCH v2 13/22] iommu/tegra: smmu: Create default IOVA maps
In-Reply-To: <1373021097-32420-14-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-14-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E84BB5.9010303@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> Create default IOVA maps at boot-up which can be attached to devices.

> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c

>  static int tegra_smmu_probe(struct platform_device *pdev)
>  {
>  	struct smmu_device *smmu;

> @@ -1160,13 +1182,15 @@ static int tegra_smmu_probe(struct platform_device *pdev)
>  	if (of_property_read_u32(dev->of_node, "nvidia,#asids", &asids))
>  		return -ENODEV;
>  
> -	bytes = sizeof(*smmu) + asids * sizeof(*smmu->as);
> +	bytes = sizeof(*smmu) + asids * (sizeof(*smmu->as) +
> +					 sizeof(struct dma_iommu_mapping *));
>  	smmu = devm_kzalloc(dev, bytes, GFP_KERNEL);
>  	if (!smmu) {
>  		dev_err(dev, "failed to allocate smmu_device\n");
>  		return -ENOMEM;
>  	}
>  
> +	smmu->map = (struct dma_iommu_mapping **)(smmu->as + asids);

Shouldn't "+ asids" be "+ asids * sizeof(*smmu->as)" to match the
calculation of "bytes" above?


From swarren at wwwdotorg.org  Thu Jul 18 16:17:21 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 14:17:21 -0600
Subject: [PATCH v2 14/22] iommu/tegra: smmu: Register platform_device
 to IOMMU dynamically
In-Reply-To: <1373021097-32420-15-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-15-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E84D51.2030404@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> Register platform_devices to IOMMU dynamically via
> ops->{add,remove}_device().

> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c

> +/*
> + * ASID[0] for the system default
> + * ASID[1] for PPCS, which has SDMMC

I have no idea what PPCS is. The patch description for 21/22 implies
much more than SDMMC is "in PPCS"...

> + * ASID[2][3].. open for drivers, first come, first served.
> + */
> +enum {
> +	SYSTEM_DEFAULT,
> +	SYSTEM_PROTECTED,
> +};

Why hard-code this mapping? Can't devices be assigned to ASIDs based on
a DT property? I assume there's nothing in the SMMU HW that requires
specific ASIDs to be used?

I don't see anything in this series which implements the "open for
drivers" part of the description for ASID 2/3/...

Perhaps not so relevant here since this patch only uses SYSTEM_DEFAULT
as the ASID number, but don't you need to validate that smmu->num_as is
large enough to support all values in the enum definition above?

Since this patch doesn't actually use anything other than
SYSTEM_DEFAULT, I wonder if this patch shouldn't be squashed into patch
21/22, where multiple ASIDs are actually used?


From swarren at wwwdotorg.org  Thu Jul 18 16:18:34 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 14:18:34 -0600
Subject: [PATCH v2 15/22] iommu/tegra: smmu: Calculate ASID register offset
 by ID
In-Reply-To: <1373021097-32420-16-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-16-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E84D9A.2080507@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> Calculate ASID register offset by ID so that we can get rid of SoC
> specific MACROs. This is needed for the unified SMMU driver over Tegra
> SoCs.

> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c

> -#define HWGRP_ASID_REG(x) (smmu_hwgrp_asid_reg[x])
> +#define HWGRP_ASID_REG(x) ((x) * sizeof(u32) + SMMU_AFI_ASID)

I think this removes the last use of smmu_hwgrp_asid_reg[]. Don't you
want to delete that in this patch?


From gsi at denx.de  Thu Jul 18 16:20:49 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 22:20:49 +0200
Subject: [PATCH v2 15/24] net: can: mscan: add a comment on reg to idx mapping
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374178858-8683-1-git-send-email-gsi@denx.de>

add a comment about the magic of deriving an MSCAN component index
from the peripheral's physical address / register offset

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/net/can/mscan/mpc5xxx_can.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index 5b0ee8e..bc422ba 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -148,7 +148,10 @@ static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 		goto exit_put;
 	}
 
-	/* Determine the MSCAN device index from the physical address */
+	/* Determine the MSCAN device index from the peripheral's
+	 * physical address. Register address offsets against the
+	 * IMMR base are:  0x1300, 0x1380, 0x2300, 0x2380
+	 */
 	pval = of_get_property(ofdev->dev.of_node, "reg", &plen);
 	BUG_ON(!pval || plen < sizeof(*pval));
 	clockidx = (*pval & 0x80) ? 1 : 0;
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 16:20:52 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 22:20:52 +0200
Subject: [PATCH v2 18/24] i2c: mpc: OF clock lookup for MPC512x
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374178858-8683-4-git-send-email-gsi@denx.de>

make the MPC I2C driver prepare and enable the peripheral clock
('per' for register access) in the MPC512x setup routine,
make this clock setup non-fatal to allow for a migration period,
remove the pre-enabling hack in the platform's clock driver

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |    1 -
 drivers/i2c/busses/i2c-mpc.c                  |    9 +++++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index b8963b7..49c52bc 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -692,7 +692,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	/* some are not yet acquired by their respective drivers */
 	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
 	clk_prepare_enable(clks[MPC512x_CLK_FEC]);	/* network, NFS */
-	clk_prepare_enable(clks[MPC512x_CLK_I2C]);
 	/*
 	 * some have their individual clock subtree with separate clock
 	 * items and their individual enable counters, yet share a
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 7607dc0..13d6822 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -21,6 +21,7 @@
 #include <linux/of_i2c.h>
 #include <linux/slab.h>
 
+#include <linux/clk.h>
 #include <linux/io.h>
 #include <linux/fsl_devices.h>
 #include <linux/i2c.h>
@@ -264,11 +265,19 @@ static void mpc_i2c_setup_512x(struct device_node *node,
 					 struct mpc_i2c *i2c,
 					 u32 clock, u32 prescaler)
 {
+	struct clk *clk;
 	struct device_node *node_ctrl;
 	void __iomem *ctrl;
 	const u32 *pval;
 	u32 idx;
 
+	/* enable clock for the I2C peripheral (non fatal) */
+	clk = of_clk_get_by_name(node, "per");
+	if (!IS_ERR(clk)) {
+		clk_prepare_enable(clk);
+		clk_put(clk);
+	}
+
 	/* Enable I2C interrupts for mpc5121 */
 	node_ctrl = of_find_compatible_node(NULL, NULL,
 					    "fsl,mpc5121-i2c-ctrl");
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 16:20:54 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 22:20:54 +0200
Subject: [PATCH v2 20/24] fs_enet: OF clock lookup (non-fatal),
 prepare and enable
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374178858-8683-6-git-send-email-gsi@denx.de>

device tree based clock lookup, must prepare clocks before enabling
them, unprepare after disable, error check in the clock setup, remove
the pre-enable workaround in the MPC512x platform's clock driver

this change implements non-fatal clock lookup since not all platforms
provide device tree specs for clocks, but failure to enable a specified
clock is considered fatal

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c      |    1 -
 .../net/ethernet/freescale/fs_enet/fs_enet-main.c  |   27 +++++++++++++++++++-
 include/linux/fs_enet_pd.h                         |    3 +++
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index 49c52bc..e9451a7 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -691,7 +691,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	clk_prepare_enable(clks[MPC512x_CLK_LPC]);	/* boot media */
 	/* some are not yet acquired by their respective drivers */
 	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
-	clk_prepare_enable(clks[MPC512x_CLK_FEC]);	/* network, NFS */
 	/*
 	 * some have their individual clock subtree with separate clock
 	 * items and their individual enable counters, yet share a
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 8de53a1..df92e12 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -1020,6 +1020,21 @@ static int fs_enet_probe(struct platform_device *ofdev)
 		fpi->cp_command = *data;
 	}
 
+	/* make clock lookup non-fatal (the driver is shared among platforms),
+	 * but require enable to succeed when a clock was specified/found
+	 */
+	fpi->clk_per = clk_get(&ofdev->dev, "per");
+	if (IS_ERR(fpi->clk_per))
+		fpi->clk_per = NULL;
+	if (fpi->clk_per) {
+		int err;
+		err = clk_prepare_enable(fpi->clk_per);
+		if (err) {
+			ret = err;
+			goto out_clk_put;
+		}
+	}
+
 	fpi->rx_ring = 32;
 	fpi->tx_ring = 32;
 	fpi->rx_copybreak = 240;
@@ -1028,7 +1043,7 @@ static int fs_enet_probe(struct platform_device *ofdev)
 	fpi->phy_node = of_parse_phandle(ofdev->dev.of_node, "phy-handle", 0);
 	if ((!fpi->phy_node) && (!of_get_property(ofdev->dev.of_node, "fixed-link",
 						  NULL)))
-		goto out_free_fpi;
+		goto out_clk_dis;
 
 	if (of_device_is_compatible(ofdev->dev.of_node, "fsl,mpc5125-fec")) {
 		phy_connection_type = of_get_property(ofdev->dev.of_node,
@@ -1108,6 +1123,12 @@ out_free_dev:
 	free_netdev(ndev);
 out_put:
 	of_node_put(fpi->phy_node);
+out_clk_dis:
+	if (fpi->clk_per)
+		clk_disable_unprepare(fpi->clk_per);
+out_clk_put:
+	if (fpi->clk_per)
+		clk_put(fpi->clk_per);
 out_free_fpi:
 	kfree(fpi);
 	return ret;
@@ -1124,6 +1145,10 @@ static int fs_enet_remove(struct platform_device *ofdev)
 	fep->ops->cleanup_data(ndev);
 	dev_set_drvdata(fep->dev, NULL);
 	of_node_put(fep->fpi->phy_node);
+	if (fep->fpi->clk_per) {
+		clk_disable_unprepare(fep->fpi->clk_per);
+		clk_put(fep->fpi->clk_per);
+	}
 	free_netdev(ndev);
 	return 0;
 }
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 51b7934..a978d0d 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -16,6 +16,7 @@
 #ifndef FS_ENET_PD_H
 #define FS_ENET_PD_H
 
+#include <linux/clk.h>
 #include <linux/string.h>
 #include <linux/of_mdio.h>
 #include <asm/types.h>
@@ -142,6 +143,8 @@ struct fs_platform_info {
 
 	int use_rmii;		/* use RMII mode 	       */
 	int has_phy;            /* if the network is phy container as well...*/
+
+	struct clk *clk_per;	/* 'per' clock for register access */
 };
 struct fs_mii_fec_platform_info {
 	u32 irq[32];
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 16:20:50 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 22:20:50 +0200
Subject: [PATCH v2 16/24] net: can: mscan: make mpc512x code use common clock
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374178858-8683-2-git-send-email-gsi@denx.de>

extend the mscan(4) driver with alternative support for the COMMON_CLK
approach which is an option in the MPC512x platform, keep the existing
clock support implementation in place since the driver is shared with
other MPC5xxx SoCs which don't have common clock support

one byproduct of this change is that the CAN driver no longer needs to
access the SoC's clock control registers, which shall be the domain of
the platform's clock driver

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/net/can/mscan/mpc5xxx_can.c |  139 +++++++++++++++++++++++++++++++++++
 1 file changed, 139 insertions(+)

diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index bc422ba..dd26ab6 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -108,6 +108,143 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
 #endif /* CONFIG_PPC_MPC52xx */
 
 #ifdef CONFIG_PPC_MPC512x
+
+#if IS_ENABLED(CONFIG_COMMON_CLK)
+
+static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
+				 const char *clock_source, int *mscan_clksrc)
+{
+	struct device_node *np;
+	u32 clockdiv;
+	enum {
+		CLK_FROM_AUTO,
+		CLK_FROM_IPS,
+		CLK_FROM_SYS,
+		CLK_FROM_REF,
+	} clk_from;
+	struct clk *clk_in, *clk_can;
+	unsigned long freq_calc;
+
+	/* the caller passed in the clock source spec that was read from
+	 * the device tree, get the optional clock divider as well
+	 */
+	np = ofdev->dev.of_node;
+	clockdiv = 1;
+	of_property_read_u32(np, "fsl,mscan-clock-divider", &clockdiv);
+	dev_dbg(&ofdev->dev, "device tree specs: clk src[%s] div[%d]\n",
+		clock_source ? clock_source : "<NULL>", clockdiv);
+
+	/* when clock-source is 'ip', the CANCTL1[CLKSRC] bit needs to
+	 * get set, and the 'ips' clock is the input to the MSCAN
+	 * component
+	 *
+	 * for clock-source values of 'ref' or 'sys' the CANCTL1[CLKSRC]
+	 * bit needs to get cleared, an optional clock-divider may have
+	 * been specified (the default value is 1), the appropriate
+	 * MSCAN related MCLK is the input to the MSCAN component
+	 *
+	 * in the absence of a clock-source spec, first an optimal clock
+	 * gets determined based on the 'sys' clock, if that fails the
+	 * 'ref' clock is used
+	 */
+	clk_from = CLK_FROM_AUTO;
+	if (clock_source) {
+		/* interpret the device tree's spec for the clock source */
+		if (!strcmp(clock_source, "ip"))
+			clk_from = CLK_FROM_IPS;
+		else if (!strcmp(clock_source, "sys"))
+			clk_from = CLK_FROM_SYS;
+		else if (!strcmp(clock_source, "ref"))
+			clk_from = CLK_FROM_REF;
+		else
+			goto err_invalid;
+		dev_dbg(&ofdev->dev, "got a clk source spec[%d]\n", clk_from);
+	}
+	if (clk_from == CLK_FROM_AUTO) {
+		/* no spec so far, try the 'sys' clock; round to the
+		 * next MHz and see if we can get a multiple of 16MHz
+		 */
+		dev_dbg(&ofdev->dev, "no clk source spec, trying SYS\n");
+		clk_in = clk_get(&ofdev->dev, "sys");
+		if (IS_ERR(clk_in))
+			goto err_notavail;
+		freq_calc = clk_get_rate(clk_in);
+		freq_calc +=  499999;
+		freq_calc /= 1000000;
+		freq_calc *= 1000000;
+		if ((freq_calc % 16000000) == 0) {
+			clk_from = CLK_FROM_SYS;
+			clockdiv = freq_calc / 16000000;
+			dev_dbg(&ofdev->dev,
+				"clk fit, sys[%lu] div[%d] freq[%lu]\n",
+				freq_calc, clockdiv, freq_calc / clockdiv);
+		}
+	}
+	if (clk_from == CLK_FROM_AUTO) {
+		/* no spec so far, use the 'ref' clock */
+		dev_dbg(&ofdev->dev, "no clk source spec, trying REF\n");
+		clk_in = clk_get(&ofdev->dev, "ref");
+		if (IS_ERR(clk_in))
+			goto err_notavail;
+		clk_from = CLK_FROM_REF;
+		freq_calc = clk_get_rate(clk_in);
+		dev_dbg(&ofdev->dev,
+			"clk fit, ref[%lu] (no div) freq[%lu]\n",
+			freq_calc, freq_calc);
+	}
+
+	/* select IPS or MCLK as the MSCAN input (returned to the caller),
+	 * setup the MCLK mux source and rate if applicable, apply the
+	 * optionally specified or derived above divider, and determine
+	 * the actual resulting clock rate to return to the caller
+	 */
+	switch (clk_from) {
+	case CLK_FROM_IPS:
+		clk_can = clk_get(&ofdev->dev, "ips");
+		if (IS_ERR(clk_can))
+			goto err_notavail;
+		clk_prepare_enable(clk_can);
+		freq_calc = clk_get_rate(clk_can);
+		*mscan_clksrc = MSCAN_CLKSRC_IPS;
+		dev_dbg(&ofdev->dev, "clk from IPS, clksrc[%d] freq[%lu]\n",
+			*mscan_clksrc, freq_calc);
+		break;
+	case CLK_FROM_SYS:
+	case CLK_FROM_REF:
+		clk_can = clk_get(&ofdev->dev, "mclk");
+		if (IS_ERR(clk_can))
+			goto err_notavail;
+		clk_prepare_enable(clk_can);
+		if (clk_from == CLK_FROM_SYS)
+			clk_in = clk_get(&ofdev->dev, "sys");
+		if (clk_from == CLK_FROM_REF)
+			clk_in = clk_get(&ofdev->dev, "ref");
+		if (IS_ERR(clk_in))
+			goto err_notavail;
+		clk_set_parent(clk_can, clk_in);
+		freq_calc = clk_get_rate(clk_in);
+		freq_calc /= clockdiv;
+		clk_set_rate(clk_can, freq_calc);
+		freq_calc = clk_get_rate(clk_can);
+		*mscan_clksrc = MSCAN_CLKSRC_BUS;
+		dev_dbg(&ofdev->dev, "clk from MCLK, clksrc[%d] freq[%lu]\n",
+			*mscan_clksrc, freq_calc);
+		break;
+	default:
+		goto err_invalid;
+	}
+
+	return freq_calc;
+
+err_invalid:
+	dev_err(&ofdev->dev, "invalid clock source specification\n");
+	return 0;
+
+err_notavail:
+	dev_err(&ofdev->dev, "cannot acquire or setup clock source\n");
+	return 0;
+}
+#else	/* COMMON_CLK */
 struct mpc512x_clockctl {
 	u32 spmr;		/* System PLL Mode Reg */
 	u32 sccr[2];		/* System Clk Ctrl Reg 1 & 2 */
@@ -238,6 +375,8 @@ exit_put:
 	of_node_put(np_clock);
 	return freq;
 }
+#endif	/* COMMON_CLK */
+
 #else /* !CONFIG_PPC_MPC512x */
 static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 				 const char *clock_name, int *mscan_clksrc)
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 16:20:51 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 22:20:51 +0200
Subject: [PATCH v2 17/24] powerpc/mpc512x: improve DIU related clock setup
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374178858-8683-3-git-send-email-gsi@denx.de>

adapt the DIU clock initialization to the COMMON_CLK approach: device
tree based clock lookup, prepare and unprepare for clocks, work with
frequencies not dividers, call the appropriate clk_*() routines and
don't access CCM registers, remove the pre-enable workaround in the
platform's clock driver

the "best clock" determination now completely relies on the platform's
clock driver to pick a frequency close to what the caller requests, and
merely checks whether the desired frequency was met (is acceptable since
it meets the tolerance of the monitor) -- this approach shall succeed
upon first try in the usual case, will test a few less desirable yet
acceptable frequencies in edge cases, and will fallback to "best effort"
if none of the previously tried frequencies pass the test

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |    1 -
 arch/powerpc/platforms/512x/mpc512x_shared.c  |  165 +++++++++++++------------
 2 files changed, 88 insertions(+), 78 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index 99d197d..b8963b7 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -692,7 +692,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	/* some are not yet acquired by their respective drivers */
 	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
 	clk_prepare_enable(clks[MPC512x_CLK_FEC]);	/* network, NFS */
-	clk_prepare_enable(clks[MPC512x_CLK_DIU]);	/* display */
 	clk_prepare_enable(clks[MPC512x_CLK_I2C]);
 	/*
 	 * some have their individual clock subtree with separate clock
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
index a82a41b..3381eea 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -12,6 +12,7 @@
  * (at your option) any later version.
  */
 
+#include <linux/clk.h>
 #include <linux/kernel.h>
 #include <linux/io.h>
 #include <linux/irq.h>
@@ -70,98 +71,108 @@ struct fsl_diu_shared_fb {
 	bool		in_use;
 };
 
-#define DIU_DIV_MASK	0x000000ff
+/* receives a pixel clock spec in pico seconds, adjusts the DIU clock rate */
 void mpc512x_set_pixel_clock(unsigned int pixclock)
 {
-	unsigned long bestval, bestfreq, speed, busfreq;
-	unsigned long minpixclock, maxpixclock, pixval;
-	struct mpc512x_ccm __iomem *ccm;
 	struct device_node *np;
-	u32 temp;
-	long err;
-	int i;
+	struct clk *clk_diu;
+	unsigned long epsilon, minpixclock, maxpixclock;
+	unsigned long offset, want, got, delta;
 
-	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-clock");
+	/* lookup and enable the DIU clock */
+	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-diu");
 	if (!np) {
-		pr_err("Can't find clock control module.\n");
+		pr_err("Could not find DIU device tree node.\n");
 		return;
 	}
-
-	ccm = of_iomap(np, 0);
+	clk_diu = of_clk_get_by_name(np, "per");
 	of_node_put(np);
-	if (!ccm) {
-		pr_err("Can't map clock control module reg.\n");
+	if (IS_ERR(clk_diu)) {
+		pr_err("Could not lookup DIU clock.\n");
 		return;
 	}
-
-	np = of_find_node_by_type(NULL, "cpu");
-	if (np) {
-		const unsigned int *prop =
-			of_get_property(np, "bus-frequency", NULL);
-
-		of_node_put(np);
-		if (prop) {
-			busfreq = *prop;
-		} else {
-			pr_err("Can't get bus-frequency property\n");
-			return;
-		}
-	} else {
-		pr_err("Can't find 'cpu' node.\n");
+	if (clk_prepare_enable(clk_diu)) {
+		pr_err("Could not enable DIU clock.\n");
 		return;
 	}
 
-	/* Pixel Clock configuration */
-	pr_debug("DIU: Bus Frequency = %lu\n", busfreq);
-	speed = busfreq * 4; /* DIU_DIV ratio is 4 * CSB_CLK / DIU_CLK */
-
-	/* Calculate the pixel clock with the smallest error */
-	/* calculate the following in steps to avoid overflow */
-	pr_debug("DIU pixclock in ps - %d\n", pixclock);
-	temp = (1000000000 / pixclock) * 1000;
-	pixclock = temp;
-	pr_debug("DIU pixclock freq - %u\n", pixclock);
-
-	temp = temp / 20; /* pixclock * 0.05 */
-	pr_debug("deviation = %d\n", temp);
-	minpixclock = pixclock - temp;
-	maxpixclock = pixclock + temp;
-	pr_debug("DIU minpixclock - %lu\n", minpixclock);
-	pr_debug("DIU maxpixclock - %lu\n", maxpixclock);
-	pixval = speed/pixclock;
-	pr_debug("DIU pixval = %lu\n", pixval);
-
-	err = LONG_MAX;
-	bestval = pixval;
-	pr_debug("DIU bestval = %lu\n", bestval);
-
-	bestfreq = 0;
-	for (i = -1; i <= 1; i++) {
-		temp = speed / (pixval+i);
-		pr_debug("DIU test pixval i=%d, pixval=%lu, temp freq. = %u\n",
-			i, pixval, temp);
-		if ((temp < minpixclock) || (temp > maxpixclock))
-			pr_debug("DIU exceeds monitor range (%lu to %lu)\n",
-				minpixclock, maxpixclock);
-		else if (abs(temp - pixclock) < err) {
-			pr_debug("Entered the else if block %d\n", i);
-			err = abs(temp - pixclock);
-			bestval = pixval + i;
-			bestfreq = temp;
-		}
+	/*
+	 * convert the picoseconds spec into the desired clock rate,
+	 * determine the acceptable clock range for the monitor (+/- 5%),
+	 * do the calculation in steps to avoid integer overflow
+	 */
+	pr_debug("DIU pixclock in ps - %u\n", pixclock);
+	pixclock = (1000000000 / pixclock) * 1000;
+	pr_debug("DIU pixclock freq  - %u\n", pixclock);
+	epsilon = pixclock / 20; /* pixclock * 0.05 */
+	pr_debug("DIU deviation      - %lu\n", epsilon);
+	minpixclock = pixclock - epsilon;
+	maxpixclock = pixclock + epsilon;
+	pr_debug("DIU minpixclock    - %lu\n", minpixclock);
+	pr_debug("DIU maxpixclock    - %lu\n", maxpixclock);
+
+	/*
+	 * check whether the DIU supports the desired pixel clock
+	 *
+	 * - simply request the desired clock and see what the
+	 *   platform's clock driver will make of it, assuming that it
+	 *   will setup the best approximation of the requested value
+	 * - try other candidate frequencies in the order of decreasing
+	 *   preference (i.e. with increasing distance from the desired
+	 *   pixel clock, and checking the lower frequency before the
+	 *   higher frequency to not overload the hardware) until the
+	 *   first match is found -- any potential subsequent match
+	 *   would only be as good as the former match or typically
+	 *   would be less preferrable
+	 *
+	 * the offset increment of pixelclock divided by 64 is an
+	 * arbitrary choice -- it's simple to calculate, in the typical
+	 * case we expect the first check to succeed already, in the
+	 * worst case seven frequencies get tested (the exact center and
+	 * three more values each to the left and to the right) before
+	 * the 5% tolerance window is exceeded, resulting in fast enough
+	 * execution yet high enough probability of finding a suitable
+	 * value, while the error rate will be in the order of single
+	 * percents
+	 */
+	for (offset = 0; offset <= epsilon; offset += pixclock / 64) {
+		want = pixclock - offset;
+		pr_debug("DIU checking clock - %lu\n", want);
+		clk_set_rate(clk_diu, want);
+		got = clk_get_rate(clk_diu);
+		delta = abs(pixclock - got);
+		if (delta < epsilon)
+			break;
+		if (!offset)
+			continue;
+		want = pixclock + offset;
+		pr_debug("DIU checking clock - %lu\n", want);
+		clk_set_rate(clk_diu, want);
+		got = clk_get_rate(clk_diu);
+		delta = abs(pixclock - got);
+		if (delta < epsilon)
+			break;
 	}
+	if (offset <= epsilon) {
+		pr_debug("DIU clock accepted - %lu\n", want);
+		pr_debug("DIU pixclock want %u, got %lu, delta %lu, eps %lu\n",
+			 pixclock, got, delta, epsilon);
+		return;
+	}
+	pr_warn("DIU pixclock auto search unsuccessful\n");
 
-	pr_debug("DIU chose = %lx\n", bestval);
-	pr_debug("DIU error = %ld\n NomPixClk ", err);
-	pr_debug("DIU: Best Freq = %lx\n", bestfreq);
-	/* Modify DIU_DIV in CCM SCFR1 */
-	temp = in_be32(&ccm->scfr1);
-	pr_debug("DIU: Current value of SCFR1: 0x%08x\n", temp);
-	temp &= ~DIU_DIV_MASK;
-	temp |= (bestval & DIU_DIV_MASK);
-	out_be32(&ccm->scfr1, temp);
-	pr_debug("DIU: Modified value of SCFR1: 0x%08x\n", temp);
-	iounmap(ccm);
+	/*
+	 * what is the most appropriate action to take when the search
+	 * for an available pixel clock which is acceptable to the
+	 * monitor has failed?  disable the DIU (clock) or just provide
+	 * a "best effort"?  we go with the latter
+	 */
+	pr_warn("DIU pixclock best effort fallback (backend's choice)\n");
+	clk_set_rate(clk_diu, pixclock);
+	got = clk_get_rate(clk_diu);
+	delta = abs(pixclock - got);
+	pr_debug("DIU pixclock want %u, got %lu, delta %lu, eps %lu\n",
+		 pixclock, got, delta, epsilon);
 }
 
 enum fsl_diu_monitor_port
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 16:20:55 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 22:20:55 +0200
Subject: [PATCH v2 21/24] [media] fsl-viu: OF clock lookup,
 prepare before enable
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374178858-8683-7-git-send-email-gsi@denx.de>

device tree based clock lookup, must prepare clocks before enabling
them, unprepare after disable, error check in the clock setup

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/media/platform/fsl-viu.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index 221ec42..b95aa43 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -1582,8 +1582,11 @@ static int viu_of_probe(struct platform_device *op)
 		dev_err(&op->dev, "failed to find the clock module!\n");
 		ret = -ENODEV;
 		goto err_clk;
-	} else {
-		clk_enable(viu_dev->clk);
+	}
+	ret = clk_prepare_enable(viu_dev->clk);
+	if (ret) {
+		dev_err(&op->dev, "failed to enable the clock!\n");
+		goto err_clk_put;
 	}
 
 	/* reset VIU module */
@@ -1602,7 +1605,8 @@ static int viu_of_probe(struct platform_device *op)
 	return ret;
 
 err_irq:
-	clk_disable(viu_dev->clk);
+	clk_disable_unprepare(viu_dev->clk);
+err_clk_put:
 	clk_put(viu_dev->clk);
 err_clk:
 	video_unregister_device(viu_dev->vdev);
@@ -1626,7 +1630,7 @@ static int viu_of_remove(struct platform_device *op)
 	free_irq(dev->irq, (void *)dev);
 	irq_dispose_mapping(dev->irq);
 
-	clk_disable(dev->clk);
+	clk_disable_unprepare(dev->clk);
 	clk_put(dev->clk);
 
 	video_unregister_device(dev->vdev);
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 16:20:53 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 22:20:53 +0200
Subject: [PATCH v2 19/24] USB: fsl-mph-dr-of: OF clock lookup,
 prepare and enable
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374178858-8683-5-git-send-email-gsi@denx.de>

device tree based clock lookup in the MPC512x initialization (lookup
'per' for register access), add error check in the clock setup, must
prepare clocks before they can get enabled, unprepare after disable

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/usb/host/fsl-mph-dr-of.c |   24 +++++++++---------------
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 11e0b79..eb564f3 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -260,25 +260,19 @@ int fsl_usb2_mpc5121_init(struct platform_device *pdev)
 {
 	struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
 	struct clk *clk;
-	char clk_name[10];
-	int base, clk_num;
-
-	base = pdev->resource->start & 0xf000;
-	if (base == 0x3000)
-		clk_num = 1;
-	else if (base == 0x4000)
-		clk_num = 2;
-	else
-		return -ENODEV;
+	int err;
 
-	snprintf(clk_name, sizeof(clk_name), "usb%d_clk", clk_num);
-	clk = clk_get(&pdev->dev, clk_name);
+	clk = clk_get(&pdev->dev, "per");
 	if (IS_ERR(clk)) {
 		dev_err(&pdev->dev, "failed to get clk\n");
 		return PTR_ERR(clk);
 	}
-
-	clk_enable(clk);
+	err = clk_prepare_enable(clk);
+	if (err) {
+		dev_err(&pdev->dev, "failed to enable clk\n");
+		clk_put(clk);
+		return err;
+	}
 	pdata->clk = clk;
 
 	if (pdata->phy_mode == FSL_USB2_PHY_UTMI_WIDE) {
@@ -303,7 +297,7 @@ static void fsl_usb2_mpc5121_exit(struct platform_device *pdev)
 	pdata->regs = NULL;
 
 	if (pdata->clk) {
-		clk_disable(pdata->clk);
+		clk_disable_unprepare(pdata->clk);
 		clk_put(pdata->clk);
 	}
 }
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 16:20:56 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 22:20:56 +0200
Subject: [PATCH v2 22/24] powerpc/fsl-pci: OF clock lookup,
 prepare before enable
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374178858-8683-8-git-send-email-gsi@denx.de>

device tree based clock lookup, must prepare clocks before enabling
them, error check in the clock setup

this change implements non-fatal clock lookup for compatibility with
platforms that don't provide OF clock specs, but failure to enable a
specified clock is considered fatal

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/sysdev/fsl_pci.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 46ac1dd..cb2ed92 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -17,6 +17,8 @@
  * Free Software Foundation;  either version 2 of the  License, or (at your
  * option) any later version.
  */
+
+#include <linux/clk.h>
 #include <linux/kernel.h>
 #include <linux/pci.h>
 #include <linux/delay.h>
@@ -741,6 +743,7 @@ err0:
 
 int __init mpc83xx_add_bridge(struct device_node *dev)
 {
+	struct clk *clk;
 	int ret;
 	int len;
 	struct pci_controller *hose;
@@ -758,6 +761,18 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
 	}
 	pr_debug("Adding PCI host bridge %s\n", dev->full_name);
 
+	/* non-fatal OF clock lookup, but fatal when a clock
+	 * was specified yet could not get enabled */
+	clk = of_clk_get_by_name(dev, "per");
+	if (!IS_ERR(clk)) {
+		ret = clk_prepare_enable(clk);
+		clk_put(clk);
+		if (ret) {
+			pr_err("Could not enable peripheral clock\n");
+			return ret;
+		}
+	}
+
 	/* Fetch host bridge registers address */
 	if (of_address_to_resource(dev, 0, &rsrc_reg)) {
 		printk(KERN_WARNING "Can't get pci register base!\n");
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 16:20:57 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 22:20:57 +0200
Subject: [PATCH v2 23/24] clk: mpc512x: switch to COMMON_CLK, remove PPC_CLOCK
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374178858-8683-9-git-send-email-gsi@denx.de>

completely switch to, i.e. unconditionally use COMMON_CLK for the
MPC512x platform, and retire the PPC_CLOCK implementation for that
platform after the transition has completed

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/Kconfig  |   14 +-
 arch/powerpc/platforms/512x/Makefile |    3 +-
 arch/powerpc/platforms/512x/clock.c  |  753 ----------------------------------
 3 files changed, 2 insertions(+), 768 deletions(-)
 delete mode 100644 arch/powerpc/platforms/512x/clock.c

diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig
index c5fcdd0..5aa3f4b 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -1,21 +1,9 @@
-config MPC512x_COMMON_CLK
-	bool "MPC512x platform uses COMMON_CLK"
-	default y
-	depends on PPC_MPC512x
-	help
-	  This option is only here to support tests and comparison
-	  during development and migration.  This option will get
-	  removed after the COMMON_CLK support for MPC512x has become
-	  fully operational and all drivers were adjusted to explicitly
-	  acquire their required clocks.
-
 config PPC_MPC512x
 	bool "512x-based boards"
 	depends on 6xx
+	select COMMON_CLK
 	select FSL_SOC
 	select IPIC
-	select PPC_CLOCK if !MPC512x_COMMON_CLK
-	select COMMON_CLK if MPC512x_COMMON_CLK
 	select PPC_PCI_CHOICE
 	select FSL_PCI if PCI
 	select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/powerpc/platforms/512x/Makefile b/arch/powerpc/platforms/512x/Makefile
index 1e05f9d..bb20116 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -1,8 +1,7 @@
 #
 # Makefile for the Freescale PowerPC 512x linux kernel.
 #
-obj-$(CONFIG_PPC_CLOCK)		+= clock.o
-obj-$(CONFIG_COMMON_CLK)	+= clock-commonclk.o
+obj-y				+= clock-commonclk.o
 obj-y				+= mpc512x_shared.o
 obj-$(CONFIG_MPC5121_ADS)	+= mpc5121_ads.o mpc5121_ads_cpld.o
 obj-$(CONFIG_MPC512x_GENERIC)	+= mpc512x_generic.o
diff --git a/arch/powerpc/platforms/512x/clock.c b/arch/powerpc/platforms/512x/clock.c
deleted file mode 100644
index e504166..0000000
--- a/arch/powerpc/platforms/512x/clock.c
+++ /dev/null
@@ -1,753 +0,0 @@
-/*
- * Copyright (C) 2007,2008 Freescale Semiconductor, Inc. All rights reserved.
- *
- * Author: John Rigby <jrigby at freescale.com>
- *
- * Implements the clk api defined in include/linux/clk.h
- *
- *    Original based on linux/arch/arm/mach-integrator/clock.c
- *
- *    Copyright (C) 2004 ARM Limited.
- *    Written by Deep Blue Solutions Limited.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <linux/kernel.h>
-#include <linux/list.h>
-#include <linux/errno.h>
-#include <linux/err.h>
-#include <linux/module.h>
-#include <linux/string.h>
-#include <linux/clk.h>
-#include <linux/mutex.h>
-#include <linux/io.h>
-
-#include <linux/of_platform.h>
-#include <asm/mpc5xxx.h>
-#include <asm/mpc5121.h>
-#include <asm/clk_interface.h>
-
-#include "mpc512x.h"
-
-#undef CLK_DEBUG
-
-static int clocks_initialized;
-
-#define CLK_HAS_RATE	0x1	/* has rate in MHz */
-#define CLK_HAS_CTRL	0x2	/* has control reg and bit */
-
-struct clk {
-	struct list_head node;
-	char name[32];
-	int flags;
-	struct device *dev;
-	unsigned long rate;
-	struct module *owner;
-	void (*calc) (struct clk *);
-	struct clk *parent;
-	int reg, bit;		/* CLK_HAS_CTRL */
-	int div_shift;		/* only used by generic_div_clk_calc */
-};
-
-static LIST_HEAD(clocks);
-static DEFINE_MUTEX(clocks_mutex);
-
-static struct clk *mpc5121_clk_get(struct device *dev, const char *id)
-{
-	struct clk *p, *clk = ERR_PTR(-ENOENT);
-	int dev_match;
-	int id_match;
-
-	if (dev == NULL || id == NULL)
-		return clk;
-
-	mutex_lock(&clocks_mutex);
-	list_for_each_entry(p, &clocks, node) {
-		dev_match = id_match = 0;
-
-		if (dev == p->dev)
-			dev_match++;
-		if (strcmp(id, p->name) == 0)
-			id_match++;
-		if ((dev_match || id_match) && try_module_get(p->owner)) {
-			clk = p;
-			break;
-		}
-	}
-	mutex_unlock(&clocks_mutex);
-
-	return clk;
-}
-
-#ifdef CLK_DEBUG
-static void dump_clocks(void)
-{
-	struct clk *p;
-
-	mutex_lock(&clocks_mutex);
-	printk(KERN_INFO "CLOCKS:\n");
-	list_for_each_entry(p, &clocks, node) {
-		pr_info("  %s=%ld", p->name, p->rate);
-		if (p->parent)
-			pr_cont(" %s=%ld", p->parent->name,
-			       p->parent->rate);
-		if (p->flags & CLK_HAS_CTRL)
-			pr_cont(" reg/bit=%d/%d", p->reg, p->bit);
-		pr_cont("\n");
-	}
-	mutex_unlock(&clocks_mutex);
-}
-#define	DEBUG_CLK_DUMP() dump_clocks()
-#else
-#define	DEBUG_CLK_DUMP()
-#endif
-
-
-static void mpc5121_clk_put(struct clk *clk)
-{
-	module_put(clk->owner);
-}
-
-#define NRPSC 12
-
-struct mpc512x_clockctl {
-	u32 spmr;		/* System PLL Mode Reg */
-	u32 sccr[2];		/* System Clk Ctrl Reg 1 & 2 */
-	u32 scfr1;		/* System Clk Freq Reg 1 */
-	u32 scfr2;		/* System Clk Freq Reg 2 */
-	u32 reserved;
-	u32 bcr;		/* Bread Crumb Reg */
-	u32 pccr[NRPSC];	/* PSC Clk Ctrl Reg 0-11 */
-	u32 spccr;		/* SPDIF Clk Ctrl Reg */
-	u32 cccr;		/* CFM Clk Ctrl Reg */
-	u32 dccr;		/* DIU Clk Cnfg Reg */
-};
-
-static struct mpc512x_clockctl __iomem *clockctl;
-
-static int mpc5121_clk_enable(struct clk *clk)
-{
-	unsigned int mask;
-
-	if (clk->flags & CLK_HAS_CTRL) {
-		mask = in_be32(&clockctl->sccr[clk->reg]);
-		mask |= 1 << clk->bit;
-		out_be32(&clockctl->sccr[clk->reg], mask);
-	}
-	return 0;
-}
-
-static void mpc5121_clk_disable(struct clk *clk)
-{
-	unsigned int mask;
-
-	if (clk->flags & CLK_HAS_CTRL) {
-		mask = in_be32(&clockctl->sccr[clk->reg]);
-		mask &= ~(1 << clk->bit);
-		out_be32(&clockctl->sccr[clk->reg], mask);
-	}
-}
-
-static unsigned long mpc5121_clk_get_rate(struct clk *clk)
-{
-	if (clk->flags & CLK_HAS_RATE)
-		return clk->rate;
-	else
-		return 0;
-}
-
-static long mpc5121_clk_round_rate(struct clk *clk, unsigned long rate)
-{
-	return rate;
-}
-
-static int mpc5121_clk_set_rate(struct clk *clk, unsigned long rate)
-{
-	return 0;
-}
-
-static int clk_register(struct clk *clk)
-{
-	mutex_lock(&clocks_mutex);
-	list_add(&clk->node, &clocks);
-	mutex_unlock(&clocks_mutex);
-	return 0;
-}
-
-static unsigned long spmf_mult(void)
-{
-	/*
-	 * Convert spmf to multiplier
-	 */
-	static int spmf_to_mult[] = {
-		68, 1, 12, 16,
-		20, 24, 28, 32,
-		36, 40, 44, 48,
-		52, 56, 60, 64
-	};
-	int spmf = (in_be32(&clockctl->spmr) >> 24) & 0xf;
-	return spmf_to_mult[spmf];
-}
-
-static unsigned long sysdiv_div_x_2(void)
-{
-	/*
-	 * Convert sysdiv to divisor x 2
-	 * Some divisors have fractional parts so
-	 * multiply by 2 then divide by this value
-	 */
-	static int sysdiv_to_div_x_2[] = {
-		4, 5, 6, 7,
-		8, 9, 10, 14,
-		12, 16, 18, 22,
-		20, 24, 26, 30,
-		28, 32, 34, 38,
-		36, 40, 42, 46,
-		44, 48, 50, 54,
-		52, 56, 58, 62,
-		60, 64, 66,
-	};
-	int sysdiv = (in_be32(&clockctl->scfr2) >> 26) & 0x3f;
-	return sysdiv_to_div_x_2[sysdiv];
-}
-
-static unsigned long ref_to_sys(unsigned long rate)
-{
-	rate *= spmf_mult();
-	rate *= 2;
-	rate /= sysdiv_div_x_2();
-
-	return rate;
-}
-
-static unsigned long sys_to_ref(unsigned long rate)
-{
-	rate *= sysdiv_div_x_2();
-	rate /= 2;
-	rate /= spmf_mult();
-
-	return rate;
-}
-
-static long ips_to_ref(unsigned long rate)
-{
-	int ips_div = (in_be32(&clockctl->scfr1) >> 23) & 0x7;
-
-	rate *= ips_div;	/* csb_clk = ips_clk * ips_div */
-	rate *= 2;		/* sys_clk = csb_clk * 2 */
-	return sys_to_ref(rate);
-}
-
-static unsigned long devtree_getfreq(char *clockname)
-{
-	struct device_node *np;
-	const unsigned int *prop;
-	unsigned int val = 0;
-
-	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-immr");
-	if (np) {
-		prop = of_get_property(np, clockname, NULL);
-		if (prop)
-			val = *prop;
-	    of_node_put(np);
-	}
-	return val;
-}
-
-static void ref_clk_calc(struct clk *clk)
-{
-	unsigned long rate;
-
-	rate = devtree_getfreq("bus-frequency");
-	if (rate == 0) {
-		printk(KERN_ERR "No bus-frequency in dev tree\n");
-		clk->rate = 0;
-		return;
-	}
-	clk->rate = ips_to_ref(rate);
-}
-
-static struct clk ref_clk = {
-	.name = "ref_clk",
-	.calc = ref_clk_calc,
-};
-
-
-static void sys_clk_calc(struct clk *clk)
-{
-	clk->rate = ref_to_sys(ref_clk.rate);
-}
-
-static struct clk sys_clk = {
-	.name = "sys_clk",
-	.calc = sys_clk_calc,
-};
-
-static void diu_clk_calc(struct clk *clk)
-{
-	int diudiv_x_2 = in_be32(&clockctl->scfr1) & 0xff;
-	unsigned long rate;
-
-	rate = sys_clk.rate;
-
-	rate *= 2;
-	rate /= diudiv_x_2;
-
-	clk->rate = rate;
-}
-
-static void viu_clk_calc(struct clk *clk)
-{
-	unsigned long rate;
-
-	rate = sys_clk.rate;
-	rate /= 2;
-	clk->rate = rate;
-}
-
-static void half_clk_calc(struct clk *clk)
-{
-	clk->rate = clk->parent->rate / 2;
-}
-
-static void generic_div_clk_calc(struct clk *clk)
-{
-	int div = (in_be32(&clockctl->scfr1) >> clk->div_shift) & 0x7;
-
-	clk->rate = clk->parent->rate / div;
-}
-
-static void unity_clk_calc(struct clk *clk)
-{
-	clk->rate = clk->parent->rate;
-}
-
-static struct clk csb_clk = {
-	.name = "csb_clk",
-	.calc = half_clk_calc,
-	.parent = &sys_clk,
-};
-
-static void e300_clk_calc(struct clk *clk)
-{
-	int spmf = (in_be32(&clockctl->spmr) >> 16) & 0xf;
-	int ratex2 = clk->parent->rate * spmf;
-
-	clk->rate = ratex2 / 2;
-}
-
-static struct clk e300_clk = {
-	.name = "e300_clk",
-	.calc = e300_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk ips_clk = {
-	.name = "ips_clk",
-	.calc = generic_div_clk_calc,
-	.parent = &csb_clk,
-	.div_shift = 23,
-};
-
-/*
- * Clocks controlled by SCCR1 (.reg = 0)
- */
-static struct clk lpc_clk = {
-	.name = "lpc_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 30,
-	.calc = generic_div_clk_calc,
-	.parent = &ips_clk,
-	.div_shift = 11,
-};
-
-static struct clk nfc_clk = {
-	.name = "nfc_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 29,
-	.calc = generic_div_clk_calc,
-	.parent = &ips_clk,
-	.div_shift = 8,
-};
-
-static struct clk pata_clk = {
-	.name = "pata_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 28,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-/*
- * PSC clocks (bits 27 - 16)
- * are setup elsewhere
- */
-
-static struct clk sata_clk = {
-	.name = "sata_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 14,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk fec_clk = {
-	.name = "fec_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 13,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk pci_clk = {
-	.name = "pci_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 11,
-	.calc = generic_div_clk_calc,
-	.parent = &csb_clk,
-	.div_shift = 20,
-};
-
-/*
- * Clocks controlled by SCCR2 (.reg = 1)
- */
-static struct clk diu_clk = {
-	.name = "diu_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 31,
-	.calc = diu_clk_calc,
-};
-
-static struct clk viu_clk = {
-	.name = "viu_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 18,
-	.calc = viu_clk_calc,
-};
-
-static struct clk axe_clk = {
-	.name = "axe_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 30,
-	.calc = unity_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk usb1_clk = {
-	.name = "usb1_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 28,
-	.calc = unity_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk usb2_clk = {
-	.name = "usb2_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 27,
-	.calc = unity_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk i2c_clk = {
-	.name = "i2c_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 26,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk mscan_clk = {
-	.name = "mscan_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 25,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk sdhc_clk = {
-	.name = "sdhc_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 24,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk mbx_bus_clk = {
-	.name = "mbx_bus_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 22,
-	.calc = half_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk mbx_clk = {
-	.name = "mbx_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 21,
-	.calc = unity_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk mbx_3d_clk = {
-	.name = "mbx_3d_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 20,
-	.calc = generic_div_clk_calc,
-	.parent = &mbx_bus_clk,
-	.div_shift = 14,
-};
-
-static void psc_mclk_in_calc(struct clk *clk)
-{
-	clk->rate = devtree_getfreq("psc_mclk_in");
-	if (!clk->rate)
-		clk->rate = 25000000;
-}
-
-static struct clk psc_mclk_in = {
-	.name = "psc_mclk_in",
-	.calc = psc_mclk_in_calc,
-};
-
-static struct clk spdif_txclk = {
-	.name = "spdif_txclk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 23,
-};
-
-static struct clk spdif_rxclk = {
-	.name = "spdif_rxclk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 23,
-};
-
-static void ac97_clk_calc(struct clk *clk)
-{
-	/* ac97 bit clock is always 24.567 MHz */
-	clk->rate = 24567000;
-}
-
-static struct clk ac97_clk = {
-	.name = "ac97_clk_in",
-	.calc = ac97_clk_calc,
-};
-
-static struct clk *rate_clks[] = {
-	&ref_clk,
-	&sys_clk,
-	&diu_clk,
-	&viu_clk,
-	&csb_clk,
-	&e300_clk,
-	&ips_clk,
-	&fec_clk,
-	&sata_clk,
-	&pata_clk,
-	&nfc_clk,
-	&lpc_clk,
-	&mbx_bus_clk,
-	&mbx_clk,
-	&mbx_3d_clk,
-	&axe_clk,
-	&usb1_clk,
-	&usb2_clk,
-	&i2c_clk,
-	&mscan_clk,
-	&sdhc_clk,
-	&pci_clk,
-	&psc_mclk_in,
-	&spdif_txclk,
-	&spdif_rxclk,
-	&ac97_clk,
-	NULL
-};
-
-static void rate_clk_init(struct clk *clk)
-{
-	if (clk->calc) {
-		clk->calc(clk);
-		clk->flags |= CLK_HAS_RATE;
-		clk_register(clk);
-	} else {
-		printk(KERN_WARNING
-		       "Could not initialize clk %s without a calc routine\n",
-		       clk->name);
-	}
-}
-
-static void rate_clks_init(void)
-{
-	struct clk **cpp, *clk;
-
-	cpp = rate_clks;
-	while ((clk = *cpp++))
-		rate_clk_init(clk);
-}
-
-/*
- * There are two clk enable registers with 32 enable bits each
- * psc clocks and device clocks are all stored in dev_clks
- */
-static struct clk dev_clks[2][32];
-
-/*
- * Given a psc number return the dev_clk
- * associated with it
- */
-static struct clk *psc_dev_clk(int pscnum)
-{
-	int reg, bit;
-	struct clk *clk;
-
-	reg = 0;
-	bit = 27 - pscnum;
-
-	clk = &dev_clks[reg][bit];
-	clk->reg = 0;
-	clk->bit = bit;
-	return clk;
-}
-
-/*
- * PSC clock rate calculation
- */
-static void psc_calc_rate(struct clk *clk, int pscnum, struct device_node *np)
-{
-	unsigned long mclk_src = sys_clk.rate;
-	unsigned long mclk_div;
-
-	/*
-	 * Can only change value of mclk divider
-	 * when the divider is disabled.
-	 *
-	 * Zero is not a valid divider so minimum
-	 * divider is 1
-	 *
-	 * disable/set divider/enable
-	 */
-	out_be32(&clockctl->pccr[pscnum], 0);
-	out_be32(&clockctl->pccr[pscnum], 0x00020000);
-	out_be32(&clockctl->pccr[pscnum], 0x00030000);
-
-	if (in_be32(&clockctl->pccr[pscnum]) & 0x80) {
-		clk->rate = spdif_rxclk.rate;
-		return;
-	}
-
-	switch ((in_be32(&clockctl->pccr[pscnum]) >> 14) & 0x3) {
-	case 0:
-		mclk_src = sys_clk.rate;
-		break;
-	case 1:
-		mclk_src = ref_clk.rate;
-		break;
-	case 2:
-		mclk_src = psc_mclk_in.rate;
-		break;
-	case 3:
-		mclk_src = spdif_txclk.rate;
-		break;
-	}
-
-	mclk_div = ((in_be32(&clockctl->pccr[pscnum]) >> 17) & 0x7fff) + 1;
-	clk->rate = mclk_src / mclk_div;
-}
-
-/*
- * Find all psc nodes in device tree and assign a clock
- * with name "psc%d_mclk" and dev pointing at the device
- * returned from of_find_device_by_node
- */
-static void psc_clks_init(void)
-{
-	struct device_node *np;
-	struct platform_device *ofdev;
-	u32 reg;
-	const char *psc_compat;
-
-	psc_compat = mpc512x_select_psc_compat();
-	if (!psc_compat)
-		return;
-
-	for_each_compatible_node(np, NULL, psc_compat) {
-		if (!of_property_read_u32(np, "reg", &reg)) {
-			int pscnum = (reg & 0xf00) >> 8;
-			struct clk *clk = psc_dev_clk(pscnum);
-
-			clk->flags = CLK_HAS_RATE | CLK_HAS_CTRL;
-			ofdev = of_find_device_by_node(np);
-			clk->dev = &ofdev->dev;
-			/*
-			 * AC97 is special rate clock does
-			 * not go through normal path
-			 */
-			if (of_device_is_compatible(np, "fsl,mpc5121-psc-ac97"))
-				clk->rate = ac97_clk.rate;
-			else
-				psc_calc_rate(clk, pscnum, np);
-			sprintf(clk->name, "psc%d_mclk", pscnum);
-			clk_register(clk);
-			clk_enable(clk);
-		}
-	}
-}
-
-static struct clk_interface mpc5121_clk_functions = {
-	.clk_get		= mpc5121_clk_get,
-	.clk_enable		= mpc5121_clk_enable,
-	.clk_disable		= mpc5121_clk_disable,
-	.clk_get_rate		= mpc5121_clk_get_rate,
-	.clk_put		= mpc5121_clk_put,
-	.clk_round_rate		= mpc5121_clk_round_rate,
-	.clk_set_rate		= mpc5121_clk_set_rate,
-	.clk_set_parent		= NULL,
-	.clk_get_parent		= NULL,
-};
-
-int __init mpc5121_clk_init(void)
-{
-	struct device_node *np;
-
-	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-clock");
-	if (np) {
-		clockctl = of_iomap(np, 0);
-		of_node_put(np);
-	}
-
-	if (!clockctl) {
-		printk(KERN_ERR "Could not map clock control registers\n");
-		return 0;
-	}
-
-	rate_clks_init();
-	psc_clks_init();
-
-	/* leave clockctl mapped forever */
-	/*iounmap(clockctl); */
-	DEBUG_CLK_DUMP();
-	clocks_initialized++;
-	clk_functions = mpc5121_clk_functions;
-	return 0;
-}
-- 
1.7.10.4



From gsi at denx.de  Thu Jul 18 16:20:58 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Thu, 18 Jul 2013 22:20:58 +0200
Subject: [PATCH v2 24/24] net: can: mscan: remove MPC512x non-COMMON_CLK code
 path
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374178858-8683-10-git-send-email-gsi@denx.de>

transition to the COMMON_CLK framework has completed for the MPC512x
platform, remove the now obsolete code path of the mpc5xxx mscan
driver which accessed clock control module registers directly

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/net/can/mscan/mpc5xxx_can.c |  136 -----------------------------------
 1 file changed, 136 deletions(-)

diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index dd26ab6..cf5e4cfc 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -108,9 +108,6 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
 #endif /* CONFIG_PPC_MPC52xx */
 
 #ifdef CONFIG_PPC_MPC512x
-
-#if IS_ENABLED(CONFIG_COMMON_CLK)
-
 static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 				 const char *clock_source, int *mscan_clksrc)
 {
@@ -244,139 +241,6 @@ err_notavail:
 	dev_err(&ofdev->dev, "cannot acquire or setup clock source\n");
 	return 0;
 }
-#else	/* COMMON_CLK */
-struct mpc512x_clockctl {
-	u32 spmr;		/* System PLL Mode Reg */
-	u32 sccr[2];		/* System Clk Ctrl Reg 1 & 2 */
-	u32 scfr1;		/* System Clk Freq Reg 1 */
-	u32 scfr2;		/* System Clk Freq Reg 2 */
-	u32 reserved;
-	u32 bcr;		/* Bread Crumb Reg */
-	u32 pccr[12];		/* PSC Clk Ctrl Reg 0-11 */
-	u32 spccr;		/* SPDIF Clk Ctrl Reg */
-	u32 cccr;		/* CFM Clk Ctrl Reg */
-	u32 dccr;		/* DIU Clk Cnfg Reg */
-	u32 mccr[4];		/* MSCAN Clk Ctrl Reg 1-3 */
-};
-
-static struct of_device_id mpc512x_clock_ids[] = {
-	{ .compatible = "fsl,mpc5121-clock", },
-	{}
-};
-
-static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
-				 const char *clock_name, int *mscan_clksrc)
-{
-	struct mpc512x_clockctl __iomem *clockctl;
-	struct device_node *np_clock;
-	struct clk *sys_clk, *ref_clk;
-	int plen, clockidx, clocksrc = -1;
-	u32 sys_freq, val, clockdiv = 1, freq = 0;
-	const u32 *pval;
-
-	np_clock = of_find_matching_node(NULL, mpc512x_clock_ids);
-	if (!np_clock) {
-		dev_err(&ofdev->dev, "couldn't find clock node\n");
-		return 0;
-	}
-	clockctl = of_iomap(np_clock, 0);
-	if (!clockctl) {
-		dev_err(&ofdev->dev, "couldn't map clock registers\n");
-		goto exit_put;
-	}
-
-	/* Determine the MSCAN device index from the peripheral's
-	 * physical address. Register address offsets against the
-	 * IMMR base are:  0x1300, 0x1380, 0x2300, 0x2380
-	 */
-	pval = of_get_property(ofdev->dev.of_node, "reg", &plen);
-	BUG_ON(!pval || plen < sizeof(*pval));
-	clockidx = (*pval & 0x80) ? 1 : 0;
-	if (*pval & 0x2000)
-		clockidx += 2;
-
-	/*
-	 * Clock source and divider selection: 3 different clock sources
-	 * can be selected: "ip", "ref" or "sys". For the latter two, a
-	 * clock divider can be defined as well. If the clock source is
-	 * not specified by the device tree, we first try to find an
-	 * optimal CAN source clock based on the system clock. If that
-	 * is not posslible, the reference clock will be used.
-	 */
-	if (clock_name && !strcmp(clock_name, "ip")) {
-		*mscan_clksrc = MSCAN_CLKSRC_IPS;
-		freq = mpc5xxx_get_bus_frequency(ofdev->dev.of_node);
-	} else {
-		*mscan_clksrc = MSCAN_CLKSRC_BUS;
-
-		pval = of_get_property(ofdev->dev.of_node,
-				       "fsl,mscan-clock-divider", &plen);
-		if (pval && plen == sizeof(*pval))
-			clockdiv = *pval;
-		if (!clockdiv)
-			clockdiv = 1;
-
-		if (!clock_name || !strcmp(clock_name, "sys")) {
-			sys_clk = clk_get(&ofdev->dev, "sys_clk");
-			if (IS_ERR(sys_clk)) {
-				dev_err(&ofdev->dev, "couldn't get sys_clk\n");
-				goto exit_unmap;
-			}
-			/* Get and round up/down sys clock rate */
-			sys_freq = 1000000 *
-				((clk_get_rate(sys_clk) + 499999) / 1000000);
-
-			if (!clock_name) {
-				/* A multiple of 16 MHz would be optimal */
-				if ((sys_freq % 16000000) == 0) {
-					clocksrc = 0;
-					clockdiv = sys_freq / 16000000;
-					freq = sys_freq / clockdiv;
-				}
-			} else {
-				clocksrc = 0;
-				freq = sys_freq / clockdiv;
-			}
-		}
-
-		if (clocksrc < 0) {
-			ref_clk = clk_get(&ofdev->dev, "ref_clk");
-			if (IS_ERR(ref_clk)) {
-				dev_err(&ofdev->dev, "couldn't get ref_clk\n");
-				goto exit_unmap;
-			}
-			clocksrc = 1;
-			freq = clk_get_rate(ref_clk) / clockdiv;
-		}
-	}
-
-	/* Disable clock */
-	out_be32(&clockctl->mccr[clockidx], 0x0);
-	if (clocksrc >= 0) {
-		/* Set source and divider */
-		val = (clocksrc << 14) | ((clockdiv - 1) << 17);
-		out_be32(&clockctl->mccr[clockidx], val);
-		/* Enable clock */
-		out_be32(&clockctl->mccr[clockidx], val | 0x10000);
-	}
-
-	/* Enable MSCAN clock domain */
-	val = in_be32(&clockctl->sccr[1]);
-	if (!(val & (1 << 25)))
-		out_be32(&clockctl->sccr[1], val | (1 << 25));
-
-	dev_dbg(&ofdev->dev, "using '%s' with frequency divider %d\n",
-		*mscan_clksrc == MSCAN_CLKSRC_IPS ? "ips_clk" :
-		clocksrc == 1 ? "ref_clk" : "sys_clk", clockdiv);
-
-exit_unmap:
-	iounmap(clockctl);
-exit_put:
-	of_node_put(np_clock);
-	return freq;
-}
-#endif	/* COMMON_CLK */
-
 #else /* !CONFIG_PPC_MPC512x */
 static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 				 const char *clock_name, int *mscan_clksrc)
-- 
1.7.10.4



From swarren at wwwdotorg.org  Thu Jul 18 16:28:42 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 14:28:42 -0600
Subject: [PATCH v2 16/22] iommu/tegra: smmu: Get "nvidia,swgroup" from DT
In-Reply-To: <1373021097-32420-17-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-17-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E84FFA.8020509@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> This provides the info about which H/W Accelerators are supported on
> Tegra SoC. This info is passed from DT. This is necessary to have the
> unified SMMU driver among Tegra SoCs. Instead of using platform data,
> DT passes "nvidia,swgroup" now. DT is mandatory in Tegra.

> diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt

> +- nvidia,swgroups: A bitmap of supported HardWare Accelerators(HWA).
> +  Each bit represents one swgroup. The assignments may be found in header
> +  file <dt-bindings/memory/tegra-swgroup.h>.

There needs to be a default for this field if one is not specified so
that existing DTs continue to work without modification.

How many cells big is this property?

Is this really a bitmap of HWAs? Surely it's a bitmap of SMMU client IDs?

>  Example:
> -	smmu {
> +	iommu {

The node name shouldn't be interpreted by anything, so there should be
no need to change it at all. Certainly, it should not be changed by this
patch, since this patch is all about SMMU client IDs.

> +		nvidia,swgroups = TEGRA30_SWGROUP_ALL;

As I mentioned before, macros shouldn't include syntax/structure, just
data values.

> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c

> @@ -265,7 +265,7 @@ struct smmu_client {
>  	struct device		*dev;
>  	struct list_head	list;
>  	struct smmu_as		*as;
> -	u32			hwgrp;
> +	u64			hwgrp;

Why is that "hwgrp" not "swgrp"? Don't they represent the same thing?

> @@ -307,6 +307,8 @@ struct smmu_device {
>  	struct device	*dev;
>  	struct page *avp_vector_page;	/* dummy page shared by all AS's */
>  
> +	u64 swgroup;			/* swgroup ID bitmap */

If that's a bitmap, then it represents multiple things, so "swgroups"?

> @@ -382,10 +384,10 @@ static inline void smmu_write(struct smmu_device *smmu, u32 val, size_t offs)
>   */
>  #define FLUSH_SMMU_REGS(smmu)	smmu_read(smmu, SMMU_CONFIG)
>  
> -#define smmu_client_hwgrp(c) (u32)((c)->dev->platform_data)
> +#define smmu_client_hwgrp(c)	(c->as->smmu->swgroup)

hwgrp-vs-swgrp inconsistency again.

Is this series git bisectable? I worry that by the time patch 14 is
applied, the SMMU starts affecting client devices, whereas none of those
client devices have swgroup values defined as their client data, and
hence without this patch also applied, things might blow up in
interesting ways.

I wonder why the code was ever using dev->platform_data in this way; the
platform data for a device should have its structure/semantics defined
by the driver for that device, not by an SMMU that happens to affect
that device. Ick!

>  static int __smmu_client_set_hwgrp(struct smmu_client *c,
> -				   unsigned long map, int on)
> +				   u64 map, int on)
>  {
>  	int i;
>  	struct smmu_as *as = c->as;
> @@ -398,12 +400,11 @@ static int __smmu_client_set_hwgrp(struct smmu_client *c,
>  	if (!on)
>  		map = smmu_client_hwgrp(c);
>  
> -	for_each_set_bit(i, &map, HWGRP_COUNT) {
> +	for_each_set_bit(i, (unsigned long *)&map,
> +			 sizeof(map) * BITS_PER_BYTE) {

Why change the type if it just forces you to add this cast?

>  		offs = HWGRP_ASID_REG(i);
>  		val = smmu_read(smmu, offs);
>  		if (on) {
> -			if (WARN_ON(val & mask))
> -				goto err_hw_busy;

Why?


From swarren at wwwdotorg.org  Thu Jul 18 16:30:55 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 14:30:55 -0600
Subject: [PATCH v2 18/22] iommu/tegra: smmu: Use dt-bindings MACRO
In-Reply-To: <1373021097-32420-19-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-19-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E8507F.3050601@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> Use dt-bindings MACRO instead of SoC dependent MACROs.

> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c

> -	if (map & HWG_AVPC) {
> +	if (map & TEGRA_SWGROUP_BIT(AVPC)) {

Patch 17 removes the definition of HWG_AVPC. So, git bisect is broken.



From swarren at wwwdotorg.org  Thu Jul 18 16:33:02 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 14:33:02 -0600
Subject: [PATCH v2 19/22] iommu/tegra: smmu: Workaround PCIe IOMMU'able
In-Reply-To: <1373021097-32420-20-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-20-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E850FE.4000506@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> Make PCIe work as it is. IOMMU support can be implemented later. We
> need the same kind of registration framework for PCIe as platform_bus
> does currently.

> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c

>  	for_each_set_bit(i, (unsigned long *)&map,
>  			 sizeof(map) * BITS_PER_BYTE) {
> +		if (i == TEGRA_SWGROUP_AFI) /* FIXME: IOMMU'able PCIe */
> +			continue;

Isn't it just a fluke that TEGRA_SWGROUP_AFI is defined identically for
the SoCs that we support upstream?

If this change is required, don't we need it before the SMMU starts
enabling itself for clients, so that git bisect is maintained?

By deferring the question of registering the IOMMU for PCIe, ar we going
to require non-backwards-compatible changes to DT for the PCIe
controller at some later point in time?



From linux at arm.linux.org.uk  Thu Jul 18 16:33:24 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Jul 2013 21:33:24 +0100
Subject: [PATCH v2 18/24] i2c: mpc: OF clock lookup for MPC512x
In-Reply-To: <1374178858-8683-4-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374178858-8683-4-git-send-email-gsi@denx.de>
Message-ID: <20130718203324.GB24642@n2100.arm.linux.org.uk>

On Thu, Jul 18, 2013 at 10:20:52PM +0200, Gerhard Sittig wrote:
> +	/* enable clock for the I2C peripheral (non fatal) */
> +	clk = of_clk_get_by_name(node, "per");
> +	if (!IS_ERR(clk)) {
> +		clk_prepare_enable(clk);
> +		clk_put(clk);
> +	}
> +

This kind of hacked up approach to the clk API is exactly the thing I
really don't like seeing.  I don't know what it is... is the clk API
somehow difficult to use or what's the problem with doing stuff correctly?

1. Get the clock in your probe function.
2. Prepare it at the appropriate time.
3. Enable it appropriately.  (or if you want to combine 2 and 3, use
   clk_prepare_enable().)
4. Ensure that enables/disables and prepares/unprepares are appropriately
   balanced.
5. 'put' the clock in your remove function.

Certainly do not get-enable-put a clock.  You're supposed to hold on to
the clock all the time that you're actually using it.

Final point - if you want to make it non-fatal, don't play games like:

	clk = clk_get(whatever);
	if (IS_ERR(clk))
		clk = NULL;

	...
	if (clk)
		clk_prepare(clk);

Do this instead:

	clk = clk_get(whatever);
	...

	if (!IS_ERR(clk))
		clk_prepare(clk);
etc.

(And on this subject, I'm considering whether to make a change to the
clk API where clk_prepare() and clk_enable() return zero when passed
an error pointer - this means drivers with optional clocks don't have
to burden themselves with these kinds of checks.)


From stern at rowland.harvard.edu  Thu Jul 18 16:38:57 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Thu, 18 Jul 2013 16:38:57 -0400 (EDT)
Subject: [PATCH V3 6/6] USB: OHCI: make ohci-s3c2410 a separate driver
In-Reply-To: <1372141408-9894-7-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <Pine.LNX.4.44L0.1307181634380.1245-100000@iolanthe.rowland.org>

On Tue, 25 Jun 2013, Manjunath Goudar wrote:

> Separate the Samsung OHCI S3CXXXX host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.11.

This patch looks very good.  I have only two very small nits:

> diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
> index e125770..b0f6644 100644
> --- a/drivers/usb/host/ohci-s3c2410.c
> +++ b/drivers/usb/host/ohci-s3c2410.c
> @@ -19,17 +19,34 @@
>   * This file is licenced under the GPL.
>  */
>  
> -#include <linux/platform_device.h>
>  #include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
>  #include <linux/platform_data/usb-ohci-s3c2410.h>
> +#include <linux/usb.h>
> +#include <linux/usb/hcd.h>
> +
> +#include "ohci.h"
> +
>  
>  #define valid_port(idx) ((idx) == 1 || (idx) == 2)
>  
>  /* clock device associated with the hcd */
>  
> +
> +#define DRIVER_DESC "OHCI S3CXXXX driver"
> +
> +static const char hcd_name[] = "ohci-s3cxxxx";
> +
>  static struct clk *clk;
>  static struct clk *usb_clk;
>  
> +static int (*orig_ohci_hub_control)(struct usb_hcd  *hcd, u16 typeReq,
> +			u16 wValue, u16 wIndex, char *buf, u16 wLength);
> +static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
> +
>  /* forward definitions */

Do you understand what "forward definitions" means?  It refers to 
declarations of functions whose actual code is given later.  In other 
words, your declarations of orig_ohci_hub_control and 
orig_ohci_hub_status_data belong just after this comment, not just 
before it.

> @@ -93,7 +110,7 @@ ohci_s3c2410_hub_status_data(struct usb_hcd *hcd, char *buf)
>  	int orig;
>  	int portno;
>  
> -	orig  = ohci_hub_status_data(hcd, buf);
> +	orig  = orig_ohci_hub_status_data(hcd, buf);

Since you're changing the line anyway, you should get rid of the extra
space before the '='.

After you make those two changes, you can add my Acked-by.

Alan Stern



From swarren at wwwdotorg.org  Thu Jul 18 16:40:55 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 14:40:55 -0600
Subject: [PATCH v2 20/22] iommu/tegra: smmu: Get "nvidia,memory-client"
 from DT
In-Reply-To: <1373021097-32420-21-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-21-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E852D7.4070302@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> This provides the info about which swgroups a device belongs to. This
> info is passed from DT. This is necessary for the unified SMMU driver
> among Tegra SoCs since each has different H/W accelerators.

> diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt

> @@ -11,6 +11,7 @@ Required properties:
>  - nvidia,swgroups: A bitmap of supported HardWare Accelerators(HWA).
>    Each bit represents one swgroup. The assignments may be found in header
>    file <dt-bindings/memory/tegra-swgroup.h>.
> +- nvidia,memory-client: Indicates which swgroups a device belongs to.

The list of properties you're adding to is for the SMMU node itself. If
specific properties need to exist in SMMU client nodes, you need to
create a separate section/list in the document for that. For example,
see the clear distinction between sections (1) and (2) in
Documentation/devicetree/bindings/gpio/gpio.txt.

What is the format/size of data in this property?

>From the example below:

> +			nvidia,memory-client = <TEGRA_SWGROUP_NV
> +						TEGRA_SWGROUP_NV2>;

... it seems like multiple entries are allowed. Should the property be
named "nvidia,memory-clients" instead (a plural)? "memory-clients" seems
like new terminology that exists just for this property. Is "swgroups"
the correct term here?

> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c

> +static u64 smmu_of_get_memory_client(struct device *dev)

> +	for (i = 0; i < bytes / sizeof(u32); i++, prop++)
> +		swgroup |= 1ULL << be32_to_cpup(prop);

Oh, so it's a list of bit numbers instead of a list of masks. Definitely
good to specify in the binding doc!


From swarren at wwwdotorg.org  Thu Jul 18 16:43:06 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 14:43:06 -0600
Subject: [PATCH v2 21/22] iommu/tegra: smmu: Support Multiple ASID
In-Reply-To: <1373021097-32420-22-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-22-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E8535A.30605@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> Support Multiple Address Space(AS). Tegra SMMU can have multiple
> ASes. We reserve 2 of them for static assignment, AS[0] for system
> default, AS[1] for AHB clusters as protected domain from others, where
> there are many traditional pheripheral devices like USB, SD/MMC. They
> should be isolated from some smart devices like host1x for system
> robustness. Even if smart devices behaves wrongly, the traditional
> devices(SD/MMC, USB) wouldn't be affected, and the system could
> continue most likely.

> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c

>  static int smmu_iommu_add_device(struct device *dev)
>  {
>  	int err;
> -	struct dma_iommu_mapping *map = smmu_handle->map[SYSTEM_DEFAULT];
> +	u64 swgroup;
> +	struct dma_iommu_mapping *map = NULL;
> +
> +	swgroup = smmu_of_get_memory_client(dev);
> +	switch (swgroup) {
> +	case TEGRA_SWGROUP_BIT(PPCS):
> +		map = smmu_handle->map[SYSTEM_PROTECTED];
> +		break;
> +	default:
> +		map = smmu_handle->map[SYSTEM_DEFAULT];

I already mentioned this, but just for completeness: What is
smmu->num_as <= SYSTEM_DEFAULT?


From swarren at wwwdotorg.org  Thu Jul 18 16:45:11 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 18 Jul 2013 14:45:11 -0600
Subject: [PATCH v2 22/22] ARM: dma-mapping: Drop GFP_COMP for DMA memory
 allocations
In-Reply-To: <1373021097-32420-23-git-send-email-hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-23-git-send-email-hdoyu@nvidia.com>
Message-ID: <51E853D7.4070200@wwwdotorg.org>

On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> arm_iommu_alloc_attrs wants to split pages after allocation in order
> to reduce the memory footprint. This does not work well with GFP_COMP
> pages, so drop this flag before allocation.
> 
> (ref: ea2e7057c0234cfb8b09467d8f137760d371fc72)

Include the commit description too, so people have a clue what that
commit is.

Presumably this fix can go through the core ARM tree independently from
this series? Or, will this series cause problems if applied without this
patch being applied first?

BTW, I don't see anything in this series that adds the mandatory
properties to DT for all this to work. I assume if I just apply this
series, everything will blow up? If so, it's usual to say "[PATCH RFC"
rather than "[PATCH" in the email subject.


From sam at ravnborg.org  Thu Jul 18 16:47:55 2013
From: sam at ravnborg.org (Sam Ravnborg)
Date: Thu, 18 Jul 2013 22:47:55 +0200
Subject: [PATCH -next 2/2] kbuild: fix for updated LZ4 tool with the
 new streaming format
In-Reply-To: <20130717223033.GF3385@free.fr>
References: <1367829775-4434-1-git-send-email-kyungsik.lee@lge.com>
 <20130716004727.b60b2c96.akpm@linux-foundation.org>
 <20130716005611.e4ccab02.akpm@linux-foundation.org>
 <201307161008.07643.yann.morin.1998@free.fr>
 <20130716180408.GA19863@merkur.ravnborg.org>
 <20130717211649.GA5619@merkur.ravnborg.org> <20130717223033.GF3385@free.fr>
Message-ID: <20130718204755.GA7900@merkur.ravnborg.org>

On Thu, Jul 18, 2013 at 12:30:33AM +0200, Yann E. MORIN wrote:
> Sam, All,
> 
> Well, while I was fighting on this on my side... ;-)
> 
> On 2013-07-17 23:16 +0200, Sam Ravnborg spake thusly:
> > > We could extend the symbol option part to retreive values from a binary.
> > > Something like this:
> > > 
> > > config FOOBAR
> > >         bool
> > >         option exec="true"
> > > 
> > > FOOBAR would assume the value "y" if the command true has exit code == 0, otherwise "n".
> > > And similar conversions for other types.
> > > 
> > > This only extendt Kconfig slightly - using an already present method to import
> > > external values.
> > > 
> > > The drawback I see with this approach is that we may execute a lot of small programs
> > > where the value is never used.
> > 
> > Following is a quick patch implmenting this idea.
> > You need to run gperf manually to enable this.
> > 
> > "gperf -C scripts/kconfig/zconf.gperf > scripts/kconfig/zconf.hash.c"
> > 
> > I did not figure out how to use the built-in rules to generate this file :-(
> 
> make REGENERATE_PARSERS=y menuconfig
Thanks!

> 
> > I have tested this lightly - as we should discuss if this is a viable way forward.
> 
> Instead of extending the Kconfig language, I was thinking (as initially
> suggested by Andrew) of generating a Kconfig file before all config
> targets, and source that Kconfig file from $(TOPDIR)/Kconfig.
> 
> I'm not a fan od extending the Kconfig language in this way. It feels
> weird to me. Especially when we have a way to solve this specific issue
> with a script that generates the needed Kconfig symbols before any
> config target is called.

The problem we want to solve is that we want some external state to influence
the Kconfig symbols.
In this case if we support lz4.
In other cases if we support a specific gcc feature or whatever.

The relevant external state may not be relevant in all cases.
We may have something that is arm specific - and we do not want to waste
time on this when we are building for sparc.

We can consider two general cases.
- Where the external state is static and independent on any other config symbols.
  lz4 is such a case.
- Where the external state depends on a config symbol.
  As we specify CROSS_COMPILE as a config symbol this may influence if gcc
  support a specific feature or not.

Both approaches suggested (generate Kconfig and exec option) supports that
we only execute relevant stuff. When we generate Kconfig we can call arch specific
scripts and for exec option we include the arch specific stuff in the arch specific
Kconfig files.

None of the approaches presented so far can handle the fact that a config symbol
may influence the external state.
But I think the exec option can be updated to support this which is why
that is my preference.

This extends the Kconfig language - but at least it is a very minor extension.

	Sam


From broonie at kernel.org  Thu Jul 18 16:49:56 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Jul 2013 21:49:56 +0100
Subject: [PATCH v2 01/24] spi: mpc512x: cleanup clock API use
In-Reply-To: <1374166855-7280-2-git-send-email-gsi@denx.de>
References: <1373914074-20889-1-git-send-email-gsi@denx.de>
 <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374166855-7280-2-git-send-email-gsi@denx.de>
Message-ID: <20130718204956.GU22506@sirena.org.uk>

On Thu, Jul 18, 2013 at 07:00:32PM +0200, Gerhard Sittig wrote:

> +	psc_num = master->bus_num;
> +	snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
> +	mps->clk_mclk = clk_get(dev, clk_name);
> +	if (IS_ERR(mps->clk_mclk))
> +		goto free_irq;

Should be using devm_clk_get().
-------------- 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/20130718/5428dd8f/attachment.sig>

From stern at rowland.harvard.edu  Thu Jul 18 16:51:17 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Thu, 18 Jul 2013 16:51:17 -0400 (EDT)
Subject: [PATCH V3 5/6] USB: OHCI: make ohci-at91 a separate driver
In-Reply-To: <1372141408-9894-6-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <Pine.LNX.4.44L0.1307181647240.1245-100000@iolanthe.rowland.org>

On Tue, 25 Jun 2013, Manjunath Goudar wrote:

> Separate the  TI OHCI Atmel host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.11.

This looks okay except for some very minor issues.

> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 46c2f42..e4dc9ab 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR
>            Enables support for the on-chip OHCI controller on
>            ST SPEAr chips.
>  
> +config USB_OHCI_HCD_AT91
> +        tristate  "Support for Atmel on-chip OHCI USB controller"
> +        depends on USB_OHCI_HCD && ARCH_AT91
> +        default y
> +        ---help---
> +          Enables support for the on-chip OHCI controller on
> +          Atmel chips.

Get rid of the extra space after "tristate".

> @@ -686,7 +630,11 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev, pm_message_t mesg)
>  	 * REVISIT: some boards will be able to turn VBUS off...
>  	 */
>  	if (at91_suspend_entering_slow_clock()) {
> -		ohci_usb_reset (ohci);
> +		ohci->hc_control = ohci_readl (ohci, &ohci->regs->control);
> +		ohci->hc_control &= OHCI_CTRL_RWC;
> +		ohci_writel (ohci, ohci->hc_control, &ohci->regs->control);
> +		ohci->rh_state = OHCI_RH_HALTED;

Even though you're just copying the code, don't also copy its mistakes.
Get rid of the extra spaces before the '(' characters.

> +static void __exit ohci_at91_cleanup(void)
> +{
> +	platform_driver_unregister(&ohci_hcd_at91_driver);
> +}
> +module_exit(ohci_at91_cleanup);
> +
> +MODULE_DESCRIPTION(DRIVER_DESC);
> +MODULE_LICENSE("GPL");

Please move the existing MODULE_ALIAS line down here with these lines.

Alan Stern



From sboyd at codeaurora.org  Thu Jul 18 17:04:44 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 14:04:44 -0700
Subject: [PATCH v3 0/5] clk: dt: bindings for mux, divider & gate clocks
In-Reply-To: <1371795256-16703-1-git-send-email-mturquette@linaro.org>
References: <1371795256-16703-1-git-send-email-mturquette@linaro.org>
Message-ID: <51E8586C.7040808@codeaurora.org>

On 06/20/13 23:14, Mike Turquette wrote:
> This series introduces binding definitions for common register-mapped
> clock multiplexer, divider and gate IP blocks along with the
> corresponding setup functions for matching DT data.  The bindings are
> similar to the struct definitions but please don't hold that against the
> binding: the struct definitions closely model the hardware register
> layout.

I know there was some discussion about clock bindings and how they
should and should not be done at Linaro Connect Europe last week. Can
someone in that discussion reply to the mailing list with what came out
of that? I only have second hand knowledge about the discussion so it
would be good for me and others to know what was discussed. I'm
especially curious because the arm soc update etherpad[1] says "DT
describes what HW is (location, type, attributes), not how HW works
(register descriptions, bitmasks, etc)." but these proposed generic
clock bindings are describing registers and bitmasks.

[1] http://pad.linaro.org/p/LCE13_ARM_SOC_Tree_Consolidation_Update

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From broonie at kernel.org  Thu Jul 18 17:06:37 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Jul 2013 22:06:37 +0100
Subject: Audio issue on Kirkwood t5325: no sound
In-Reply-To: <20130718173727.2cfa38d3@skate>
References: <20130718134330.5aea00c5@skate>
 <20130718142009.GX24642@n2100.arm.linux.org.uk>
 <20130718173727.2cfa38d3@skate>
Message-ID: <20130718210637.GW22506@sirena.org.uk>

On Thu, Jul 18, 2013 at 05:37:27PM +0200, Thomas Petazzoni wrote:

> # for i in /sys/kernel/debug/asoc/t5325/dapm/* ; do echo $i ; cat "$i" ; done
> /sys/kernel/debug/asoc/t5325/dapm/Headphone Jack
> Headphone Jack: Off  in 2 out 1
>  in  "static" "HPR"
>  in  "static" "HPL"
> /sys/kernel/debug/asoc/t5325/dapm/Mic Jack
> Mic Jack: Off  in 1 out 0
>  out "static" "MIC2"
>  out "static" "MIC1"
> /sys/kernel/debug/asoc/t5325/dapm/Speaker
> Speaker: Off  in 2 out 1
>  in  "static" "SPKOUTN"
>  in  "static" "SPKOUT"
> /sys/kernel/debug/asoc/t5325/dapm/bias_level
> Off

> I don't see anything that looks unreasonable in there, but I've never
> played with DAPM and related things, so it is very possible that my
> reasonable-guesser might be wrong on this.

All those "Off" things mean that things are powered off which tends not
to involve them making any noise...  Russell mentioned that he thought
this was a lack of DAPM stuff however looking here it seems there are
some DAPM widgets on your board?
-------------- 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/20130718/56ddfdb1/attachment.sig>

From broonie at kernel.org  Thu Jul 18 17:15:21 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Jul 2013 22:15:21 +0100
Subject: Audio issue on Kirkwood t5325: no sound
In-Reply-To: <20130718210637.GW22506@sirena.org.uk>
References: <20130718134330.5aea00c5@skate>
 <20130718142009.GX24642@n2100.arm.linux.org.uk>
 <20130718173727.2cfa38d3@skate>
 <20130718210637.GW22506@sirena.org.uk>
Message-ID: <20130718211521.GX22506@sirena.org.uk>

On Thu, Jul 18, 2013 at 10:06:37PM +0100, Mark Brown wrote:

> All those "Off" things mean that things are powered off which tends not
> to involve them making any noise...  Russell mentioned that he thought
> this was a lack of DAPM stuff however looking here it seems there are
> some DAPM widgets on your board?

And now I think about it further the fix here is essentially that we
require DAPM on any device that wants power management these days - DAIs
are now widget based so it's going to be much more sensible to just go
through and add the relevant output pins to relevant legacy drivers.

This means that for uda134x (which I think is what you're using here, I
have no context but that's what Russell mentioned?) someone needs to add
widgets corresponding to the names for the inputs and outputs (just make
up a name if there's just one of each and no datasheet) then link them
with some DAPM routes:

	{ "OUTPUT", NULL, "Playback" },
	{ "Capture", NULL, "INPUT" },

where INPUT and OUTPUT are the names of an input or output pin on the
device defined as DAPM widgets:

	SND_SOC_DAPM_INPUT("INPUT"),
	SND_SOC_DAPM_OUTPUT("OUTPUT"),

which I think is what Russell did.
-------------- 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/20130718/a6f5a8aa/attachment-0001.sig>

From linux at arm.linux.org.uk  Thu Jul 18 17:23:50 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Jul 2013 22:23:50 +0100
Subject: Audio issue on Kirkwood t5325: no sound
In-Reply-To: <20130718211521.GX22506@sirena.org.uk>
References: <20130718134330.5aea00c5@skate>
 <20130718142009.GX24642@n2100.arm.linux.org.uk>
 <20130718173727.2cfa38d3@skate> <20130718210637.GW22506@sirena.org.uk>
 <20130718211521.GX22506@sirena.org.uk>
Message-ID: <20130718212350.GC24642@n2100.arm.linux.org.uk>

On Thu, Jul 18, 2013 at 10:15:21PM +0100, Mark Brown wrote:
> On Thu, Jul 18, 2013 at 10:06:37PM +0100, Mark Brown wrote:
> 
> > All those "Off" things mean that things are powered off which tends not
> > to involve them making any noise...  Russell mentioned that he thought
> > this was a lack of DAPM stuff however looking here it seems there are
> > some DAPM widgets on your board?
> 
> And now I think about it further the fix here is essentially that we
> require DAPM on any device that wants power management these days - DAIs
> are now widget based so it's going to be much more sensible to just go
> through and add the relevant output pins to relevant legacy drivers.
> 
> This means that for uda134x (which I think is what you're using here, I

No, this report is against ALC5623, which does appear to have widgets.
I was remarking that this looks like the same kind of issue I had with
UDA134x.

Note that the report indicates that the bias setting remains off while
playing, and ALC5623 does this:

        case SND_SOC_BIAS_OFF:
                /* everything off, dac mute, inactive */
                snd_soc_write(codec, ALC5623_PWR_MANAG_ADD2, 0);
                snd_soc_write(codec, ALC5623_PWR_MANAG_ADD3, 0);
                snd_soc_write(codec, ALC5623_PWR_MANAG_ADD1, 0);

So if everything on the codec is powered down, it's not surprising that
there is no audio output.


From broonie at kernel.org  Thu Jul 18 17:52:32 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Jul 2013 22:52:32 +0100
Subject: Audio issue on Kirkwood t5325: no sound
In-Reply-To: <20130718212350.GC24642@n2100.arm.linux.org.uk>
References: <20130718134330.5aea00c5@skate>
 <20130718142009.GX24642@n2100.arm.linux.org.uk>
 <20130718173727.2cfa38d3@skate>
 <20130718210637.GW22506@sirena.org.uk>
 <20130718211521.GX22506@sirena.org.uk>
 <20130718212350.GC24642@n2100.arm.linux.org.uk>
Message-ID: <20130718215231.GY22506@sirena.org.uk>

On Thu, Jul 18, 2013 at 10:23:50PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 18, 2013 at 10:15:21PM +0100, Mark Brown wrote:

> > This means that for uda134x (which I think is what you're using here, I

> No, this report is against ALC5623, which does appear to have widgets.
> I was remarking that this looks like the same kind of issue I had with
> UDA134x.

Ah, OK.  In that case the issue is likely to be that no connection has
been made between the audio interface and the outputs desired - probably
some routing control needs to be enabled by userspace.  If there's no
visible path between a source of audio (like playback from the CPU) and
a sink (such as an output) then the framework will think there's nothing
to do.

> So if everything on the codec is powered down, it's not surprising that
> there is no audio output.

Indeed, and if the routing isn't set up to connect an audio path the
core will not bother powering it on at all.  The issue with the UDA134x
is that we need to give the framework the information that the playback
interfaces are connected to an output (or restore the code to do this in
the core but at this point since it's all data driven now in the drivers
it's easier and more robust to just plumb them in and avoid having to
deal with special cases which keep tripping us up).
-------------- 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/20130718/72605e9e/attachment.sig>

From sergei.shtylyov at cogentembedded.com  Thu Jul 18 17:56:36 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 19 Jul 2013 01:56:36 +0400
Subject: [PATCH 1/3] ARM: shmobile: use common platform header for HPB-DMAC
In-Reply-To: <51D171E4.3080108@cogentembedded.com>
References: <201306300243.57180.sergei.shtylyov@cogentembedded.com>
 <201306300245.58486.sergei.shtylyov@cogentembedded.com>
 <87ehbij4wc.wl%kuninori.morimoto.gx@renesas.com>
 <51D171E4.3080108@cogentembedded.com>
Message-ID: <51E86494.5050906@cogentembedded.com>

Hello.

On 07/01/2013 04:11 PM, Sergei Shtylyov wrote:

>>> From: Max Filippov <max.filippov at cogentembedded.com>

>>> Use previously empty <mach/dma.h> to declare HPB-DMA slave IDs.

>>> Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
>>> [Sergei: changed the guard macro name, fixed comment, extended copyright.]
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

>>> ---
>>>   arch/arm/mach-shmobile/include/mach/dma.h |   25 ++++++++++++++++++++++++-
>>>   1 file changed, 24 insertions(+), 1 deletion(-)

>>> Index: renesas/arch/arm/mach-shmobile/include/mach/dma.h
>>> ===================================================================
>>> --- renesas.orig/arch/arm/mach-shmobile/include/mach/dma.h
>>> +++ renesas/arch/arm/mach-shmobile/include/mach/dma.h
>>> @@ -1 +1,24 @@
>>> -/* empty */
>>> +/*
>>> + * Copyright (C) 2011-2013 Renesas Electronics Corporation
>>> + * Copyright (C) 2013 Cogent Embedded, Inc.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2
>>> + * as published by the Free Software Foundation.
>>> + */
>>> +
>>> +#ifndef __MACH_DMA_H
>>> +#define __MACH_DMA_H
>>> +
>>> +/* HPB-DMA slave IDs */
>>> +enum {
>>> +    HPBDMA_SLAVE_DUMMY,
>>> +    HPBDMA_SLAVE_SDHI0_TX,
>>> +    HPBDMA_SLAVE_SDHI0_RX,
>>> +    HPBDMA_SLAVE_SSI0_TX_ST,
>>> +    HPBDMA_SLAVE_SSI0_TX_MN,
>>> +    HPBDMA_SLAVE_SSI1_RX_ST,
>>> +    HPBDMA_SLAVE_SSI1_RX_MN,
>>> +};

>> it should be in r8a7778.h

>     It will be shared with R8A7779.

    Apparently not anymore as this file is gone now.

WBR, Sergei



From sergei.shtylyov at cogentembedded.com  Thu Jul 18 18:02:34 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 19 Jul 2013 02:02:34 +0400
Subject: [PATCH 1/3] ARM: shmobile: use common platform header for HPB-DMAC
In-Reply-To: <CANqRtoTCaJfbECSpX7nMZoV8SPeQqs-xrJQ0-+-smA+bx3QG=w@mail.gmail.com>
References: <201306300243.57180.sergei.shtylyov@cogentembedded.com>
 <201306300245.58486.sergei.shtylyov@cogentembedded.com>
 <CANqRtoTCaJfbECSpX7nMZoV8SPeQqs-xrJQ0-+-smA+bx3QG=w@mail.gmail.com>
Message-ID: <51E865FA.9000706@cogentembedded.com>

Hello.

On 07/02/2013 08:59 AM, Magnus Damm wrote:

>> From: Max Filippov <max.filippov at cogentembedded.com>

>> Use previously empty <mach/dma.h> to declare HPB-DMA slave IDs.

>> Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
>> [Sergei: changed the guard macro name, fixed comment, extended copyright.]
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

>> ---
>>   arch/arm/mach-shmobile/include/mach/dma.h |   25 ++++++++++++++++++++++++-
>>   1 file changed, 24 insertions(+), 1 deletion(-)

> Thanks for your patch. Can you please explain the reason why you put
> this shared information under mach/?

    I'm afraid that's more a question to the original author, Phil Edworthy.
He put this stuff into <mach/hpb-dmae.h>.

>  From my point of view we should really have as few special things as
> possible under mach/. Starting to share DMA stuff here looks special.
> I would like mach-shmobile to be as standard as possible (basically
> only ARM code in the future), and in the case we have I/O devices or
> other IOMMUs or DMA controllers then we should use include/linux or
> that recently added platform data directory if needed. We need to make
> sure that our headers stay compatible with multiplatform support.

> I realize you may want to share this header between multiple SoCs, but
> I really want to avoid creating local common code under arch/arm/ that
> has nothing to do with ARM. Also, this is IMO a total non-issue,
> instead of merging code and making back porting more difficult for any
> particular SoC, then how about spending effort on the ling term
> instead, like DMA DT?

> So my recommendation is to keep this information together with each
> SoC. And also work on DT. In between have a coffee or work on DT, but
> please do not spend time on merging short term per-SoC information and
> making back porting more difficult.

    OK. DT would be a next step I guess.

> Thanks,

> / magnus

WBR, Sergei



From sergei.shtylyov at cogentembedded.com  Thu Jul 18 18:04:20 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 19 Jul 2013 02:04:20 +0400
Subject: [PATCH 2/3] ARM: shmobile: r8a7778: add HPB-DMAC support
In-Reply-To: <87d2r2j4uy.wl%kuninori.morimoto.gx@renesas.com>
References: <201306300243.57180.sergei.shtylyov@cogentembedded.com>
 <201306300248.57898.sergei.shtylyov@cogentembedded.com>
 <87d2r2j4uy.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <51E86664.1060509@cogentembedded.com>

Hello.

On 07/01/2013 08:12 AM, Kuninori Morimoto wrote:

>> From: Max Filippov <max.filippov at cogentembedded.com>

>> Add HPB-DMAC platform device on R8A7778 SoC along with its slave and channel
>> configurations.

>> Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

>> ---
> (snip)
>> +static const struct hpb_dmae_slave_config hpb_dmae_slaves[] = {
>> +	{
>> +		.id	= HPBDMA_SLAVE_SDHI0_TX,
>> +		.addr	= 0xffe4c000 + 0x30,
>> +		.dcr	= DCR_SPDS_16BIT | DCR_DMDL | DCR_DPDS_16BIT,
>> +		.rstr	= ASYNCRSTR_ASRST21 | ASYNCRSTR_ASRST22 |
>> +			  ASYNCRSTR_ASRST23,
>> +		.mdr	= ASYNCMDR_ASMD21_SINGLE,
>> +		.mdm	= ASYNCMDR_ASMD21_MASK,
>> +		.port	= 0x0D0C,
>> +		.flags	= HPB_DMAE_SET_ASYNC_RESET | HPB_DMAE_SET_ASYNC_MODE,
>> +		.dma_ch	= 21,
>> +	}, {
>> +		.id	= HPBDMA_SLAVE_SDHI0_RX,
>> +		.addr	= 0xffe4c000 + 0x30,
>> +		.dcr	= DCR_SMDL | DCR_SPDS_16BIT | DCR_DPDS_16BIT,
>> +		.rstr	= ASYNCRSTR_ASRST21 | ASYNCRSTR_ASRST22 |
>> +			  ASYNCRSTR_ASRST23,
>> +		.mdr	= ASYNCMDR_ASMD22_SINGLE,
>> +		.mdm	= ASYNCMDR_ASMD22_MASK,
>> +		.port	= 0x0D0C,
>> +		.flags	= HPB_DMAE_SET_ASYNC_RESET | HPB_DMAE_SET_ASYNC_MODE,
>> +		.dma_ch	= 22,
>> +	}, {
>> +		.id	= HPBDMA_SLAVE_SSI0_TX_ST,
>> +		.addr	= 0xffd90000 + 0x1008,
>> +		.dcr	= DCR_CT | DCR_DIP | DCR_SPDS_32BIT | DCR_DMDL |
>> +			  DCR_DPDS_32BIT,
>> +		.port	= 0x0000,
>> +		.dma_ch	= 28,
>> +	}, {
>> +		.id	= HPBDMA_SLAVE_SSI0_TX_MN,
>> +		.addr	= 0xffd90000 + 0x1008,
>> +		.dcr	= DCR_CT | DCR_DIP | DCR_SPDS_16BIT | DCR_DMDL |
>> +			  DCR_DPDS_16BIT,
>> +		.port	= 0x0000,
>> +		.dma_ch	= 28,
>> +	}, {
>> +		.id	= HPBDMA_SLAVE_SSI1_RX_ST,
>> +		.addr	= 0xffd90000 + 0x104c,
>> +		.dcr	= DCR_CT | DCR_DIP | DCR_SMDL | DCR_SPDS_32BIT |
>> +			  DCR_DPDAM | DCR_DPDS_32BIT,
>> +		.port	= 0x0101,
>> +		.dma_ch	= 29,
>> +	}, {
>> +		.id	= HPBDMA_SLAVE_SSI1_RX_MN,
>> +		.addr	= 0xffd90000 + 0x104c,
>> +		.dcr	= DCR_CT | DCR_DIP | DCR_SMDL | DCR_SPDS_16BIT |
>> +			  DCR_DPDAM | DCR_DPDS_16BIT,
>> +		.port	= 0x0101,
>> +		.dma_ch	= 29,
>> +	},
>> +};

> How did you test SSI ?
> remove these

    OK. The SSI stuff came from the original patch.

> Best regards
> ---
> Kuninori Morimoto

WBR, Sergei



From grant.likely at secretlab.ca  Thu Jul 18 18:50:09 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Thu, 18 Jul 2013 15:50:09 -0700
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <51E6CCE4.20705@wwwdotorg.org>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <20130716041056.GA30067@S2101-09.ap.freescale.net>
 <51E56AA7.7020103@wwwdotorg.org>
 <20130717030246.GA4541@S2101-09.ap.freescale.net>
 <51E6CCE4.20705@wwwdotorg.org>
Message-ID: <CACxGe6usaesdKTb8eVtB3SxdOUzJVbE+4X4J5mfKDmD6oiyQsQ@mail.gmail.com>

On Wed, Jul 17, 2013 at 9:57 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/16/2013 09:02 PM, Shawn Guo wrote:
>> On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote:
>>> Registering the driver earlier won't cause any bugs. However, it's not
>>> the correct approach.
>>>
>>> Deferred probe /is/ the approach for assuring correct dependencies
>>> between drivers. It works and should be used. There are not enough
>>> initcall levels to play games using initcalls and solve all the issues,
>>> and the ordering requirements vary board-to-board. Deferred probe at
>>> runtime handles this without having to manually place all the drivers
>>> into specific initcall levels, and dynamically adjusts to board
>>> differences, since it all happens automatically at run-time.
>>
>> I do not quite follow the argument here.  I agree with you that
>> deferred probe is the approach to solve dependencies.  But it does not
>> necessarily mean that initcall can not be used to help it save some
>> nasty or nested deferring.  Deferred probe and initcalls are not two
>> mutually exclusive mechanisms but two which can help each other.
>
> My understanding is that deferred probe was implemented specifically to
> avoid having to, or allowing, the use of initcall levels to determine
> probe order.

Correct. Futzing around with initcalls may optimize particular use
cases, but it isn't complete. I've been pushing for all drivers to use
module_initcall() unless there is a very strong reason to do
otherwise. Premature optimization (without measuring time consumed) is
not a strong justification.

g.


From grant.likely at secretlab.ca  Thu Jul 18 18:55:55 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Thu, 18 Jul 2013 15:55:55 -0700
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <20130718112555.GB1021@amd.pavel.ucw.cz>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <20130716041056.GA30067@S2101-09.ap.freescale.net>
 <51E56AA7.7020103@wwwdotorg.org>
 <20130717030246.GA4541@S2101-09.ap.freescale.net>
 <51E6CCE4.20705@wwwdotorg.org>
 <20130717213836.GA13324@amd.pavel.ucw.cz> <51E719A6.6070105@wwwdotorg.org>
 <20130718112555.GB1021@amd.pavel.ucw.cz>
Message-ID: <CACxGe6usDHi5sQFXTGB7wqEyzZud3J1cqaX19x9kqREz+WhQLA@mail.gmail.com>

On Thu, Jul 18, 2013 at 4:25 AM, Pavel Machek <pavel at denx.de> wrote:
> Hi!
>
>> >>> I do not quite follow the argument here.  I agree with you that
>> >>> deferred probe is the approach to solve dependencies.  But it does not
>> >>> necessarily mean that initcall can not be used to help it save some
>> >>> nasty or nested deferring.  Deferred probe and initcalls are not two
>> >>> mutually exclusive mechanisms but two which can help each other.
>> >>
>> >> My understanding is that deferred probe was implemented specifically to
>> >> avoid having to, or allowing, the use of initcall levels to determine
>> >> probe order.
>> >>
>> >> However, if someone closely associated with the implementation of
>> >> deferred probe (e.g. Grant, or a device core maintainer) is willing to
>> >> step up and say I'm wrong, I'll drop my objection.
>> >
>> > AFAIR, defered probing is known to be a "hack" by its authors. We
>> > should still try to get initcall levels right...
>>
>> I don't /think/ it was the concept of deferred probe that was considered
>> hacky, but perhaps just the first proof-of-concept implementation, and
>> any hackiness was presumably solved before the feature was merged.
>
> Well...
>
> http://lwn.net/Articles/485194/
>
> From:           Grant Likely <grant.likely at secretlab.ca>
> To:                   linux-kernel at vger.kernel.org
> Subject:                [PATCH] drivercore: Add driver probe deferral
> mechanism
> Date:           Mon, 5 Mar 2012 08:47:41 -0700
> Message-ID:
> <1330962461-9061-1-git-send-email-grant.likely at secretlab.ca>
> ...
>
> I know that not everybody is happy with this approach, but I've yet to
> see a better alternative.  However, it is *really easy* to find all
> the
> users of deferred probe since any user must return -EPROBE_DEFER
> explicitly.
> If/when a better approach is found, all the users will be easy to find
> and modify.
>
> ...
>
> It sound to me like keeping ammount of -EPROBE_DEFER to minimum is
> still preferred.

That wasn't the point I was trying to make in the above thread. My
point was that -EPROBE_DEFER is the best option that we currently have
to get rid of the initcall ordering madness. I'm all ears if someone
comes up with a simple and inexpensive alternative that can take into
account dependencies between devices.

g.


From linux at roeck-us.net  Thu Jul 18 19:05:29 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 18 Jul 2013 16:05:29 -0700
Subject: [PATCH v3] watchdog: Add MOXA ART watchdog driver
In-Reply-To: <1374053091-5907-1-git-send-email-jonas.jensen@gmail.com>
References: <1373981055-18515-1-git-send-email-jonas.jensen@gmail.com>
 <1374053091-5907-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <20130718230529.GA8465@roeck-us.net>

On Wed, Jul 17, 2013 at 11:24:51AM +0200, Jonas Jensen wrote:
> Add watchdog driver for MOXA ART SoCs.
> 
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
> ---
> 
> Notes:
>     Changes since v2:
>     
>     1. add devicetree bindings document
>     
>     Applies to next-20130716
> 
>  .../bindings/watchdog/moxa,moxart-watchdog.txt     |  15 ++
>  drivers/watchdog/Kconfig                           |  10 ++
>  drivers/watchdog/Makefile                          |   1 +
>  drivers/watchdog/moxart_wdt.c                      | 171 +++++++++++++++++++++
>  4 files changed, 197 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
>  create mode 100644 drivers/watchdog/moxart_wdt.c
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
> new file mode 100644
> index 0000000..fb99e50
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
> @@ -0,0 +1,15 @@
> +MOXA ART Watchdog timer
> +
> +Required properties:
> +
> +- compatible : Should be "moxa,moxart-watchdog"
> +- reg : Should contain registers location and length
> +- clocks : Should contain phandle for APB clock "clkapb"
> +
> +Example:
> +
> +	watchdog: watchdog at 98500000 {
> +		compatible = "moxa,moxart-watchdog";
> +		reg = <0x98500000 0x10>;
> +		clocks = <&clkapb>;
> +	};
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 362085d..6883aab 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -382,6 +382,16 @@ config RETU_WATCHDOG
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called retu_wdt.
>  
> +config MOXART_WDT
> +	tristate "MOXART watchdog"
> +	depends on ARCH_MOXART
> +	help
> +	  Say Y here to include Watchdog timer support for the watchdog
> +	  existing on the MOXA ART SoC series platforms.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called moxart_wdt.
> +
>  # AVR32 Architecture
>  
>  config AT32AP700X_WDT
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 2f26a0b..7cab53a 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -54,6 +54,7 @@ obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
>  obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
>  obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
>  obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
> +obj-$(CONFIG_MOXART_WDT) += moxart_wdt.o
>  
>  # AVR32 Architecture
>  obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
> new file mode 100644
> index 0000000..966855d
> --- /dev/null
> +++ b/drivers/watchdog/moxart_wdt.c
> @@ -0,0 +1,171 @@
> +/*
> + * MOXA ART SoCs watchdog driver.
> + *
> + * Copyright (C) 2013 Jonas Jensen
> + *
> + * Jonas Jensen <jonas.jensen at gmail.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>

Do you need the above two includes ? 

> +#include <linux/platform_device.h>
> +#include <linux/types.h>
> +#include <linux/watchdog.h>
> +
> +#include <asm/system_misc.h>
> +
> +#define REG_COUNT			0x4
> +#define REG_MODE			0x8
> +#define REG_ENABLE			0xC
> +
> +struct moxart_wdt_dev {
> +	struct watchdog_device wdt_dev;
> +	void __iomem *wdt_base;
> +};
> +
> +static struct moxart_wdt_dev *moxart_wdt;

I don't think this variable is really needed as static variable;
you should be able to use platform_get_drvdata() to get it whereever needed.
In fact, you sometimes use the static variable and sometimes a local variable
with the same name. I find this confusing.

> +static bool nowayout = WATCHDOG_NOWAYOUT;

Only used in probe function and should be declared there.

> +static int heartbeat;
> +static unsigned int clock_frequency;

Curious - why did you declare this variable as static variable, but wdt_base is
part of moxart_wdt_dev.

> +static unsigned int max_timeout;

This variable is only used in the probe function and should thus be declared
there.

> +static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
> +	void __iomem *wdt_base = moxart_wdt->wdt_base;
> +
> +	writel(0, wdt_base + REG_ENABLE);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_start(struct watchdog_device *wdt_dev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
> +	void __iomem *wdt_base = moxart_wdt->wdt_base;
> +
> +	writel(clock_frequency * moxart_wdt->wdt_dev.timeout,
> +	       wdt_base + REG_COUNT);
> +	writel(0x5ab9, wdt_base + REG_MODE);
> +	writel(0x03, wdt_base + REG_ENABLE);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_set_timeout(struct watchdog_device *wdt_dev,
> +				  unsigned int timeout)
> +{
> +	dev_dbg(wdt_dev->dev, "%s: timeout=%u\n", __func__, timeout);
> +
> +	moxart_wdt->wdt_dev.timeout = timeout;
> +
> +	return 0;
> +}
> +
> +static const struct watchdog_info moxart_wdt_info = {
> +	.identity       = "moxart-wdt",
> +	.options        = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
> +			  WDIOF_MAGICCLOSE,
> +};
> +
> +static const struct watchdog_ops moxart_wdt_ops = {
> +	.owner          = THIS_MODULE,
> +	.start          = moxart_wdt_start,
> +	.stop           = moxart_wdt_stop,
> +	.set_timeout    = moxart_wdt_set_timeout,
> +};
> +
> +static int moxart_wdt_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct device_node *node = dev->of_node;
> +	struct resource *res;
> +	struct clk *clk;
> +	int err;
> +
> +	moxart_wdt = devm_kzalloc(&pdev->dev, sizeof(*moxart_wdt), GFP_KERNEL);
> +	if (!moxart_wdt)
> +		return -EINVAL;
> +
> +	platform_set_drvdata(pdev, moxart_wdt);
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	moxart_wdt->wdt_base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(moxart_wdt->wdt_base))
> +		return PTR_ERR(moxart_wdt->wdt_base);
> +
> +	clk = of_clk_get(node, 0);
> +	if (IS_ERR(clk)) {
> +		pr_err("%s: of_clk_get failed\n", __func__);
> +		return PTR_ERR(clk);
> +	}
> +
> +	clock_frequency = clk_get_rate(clk);

Other callers of this function check the return value. Maybe the error can not
happen here, but I am a bit concerned that the function may return 0, in which
case you would have a problem with division by zero below. Is it guaranteed
that this can never happen ?

> +
> +	max_timeout = UINT_MAX / clock_frequency;
> +
> +	moxart_wdt->wdt_dev.info = &moxart_wdt_info;
> +	moxart_wdt->wdt_dev.ops = &moxart_wdt_ops;
> +	moxart_wdt->wdt_dev.timeout = max_timeout;
> +	moxart_wdt->wdt_dev.min_timeout = 1;
> +	moxart_wdt->wdt_dev.max_timeout = max_timeout;
> +	moxart_wdt->wdt_dev.parent = &pdev->dev;
> +
> +	watchdog_init_timeout(&moxart_wdt->wdt_dev, heartbeat, &pdev->dev);
> +	watchdog_set_nowayout(&moxart_wdt->wdt_dev, nowayout);
> +
> +	watchdog_set_drvdata(&moxart_wdt->wdt_dev, moxart_wdt);
> +
> +	err = watchdog_register_device(&moxart_wdt->wdt_dev);
> +	if (unlikely(err))
> +		return err;
> +
> +	dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
> +		moxart_wdt->wdt_dev.timeout, nowayout);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_remove(struct platform_device *pdev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
> +
> +	moxart_wdt_stop(&moxart_wdt->wdt_dev);
> +	watchdog_unregister_device(&moxart_wdt->wdt_dev);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id moxart_watchdog_match[] = {
> +	{ .compatible = "moxa,moxart-watchdog" },
> +	{ },
> +};
> +
> +static struct platform_driver moxart_wdt_driver = {
> +	.probe      = moxart_wdt_probe,
> +	.remove     = moxart_wdt_remove,
> +	.driver     = {
> +		.name		= "moxart-watchdog",
> +		.owner		= THIS_MODULE,
> +		.of_match_table	= moxart_watchdog_match,
> +	},
> +};
> +module_platform_driver(moxart_wdt_driver);
> +
> +module_param(heartbeat, int, 0);
> +MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");
> +
> +MODULE_DESCRIPTION("MOXART watchdog driver");
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
> -- 
> 1.8.2.1
> 
> 


From linux at roeck-us.net  Thu Jul 18 19:11:07 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 18 Jul 2013 16:11:07 -0700
Subject: [PATCH v6] ARM: sunxi: New watchdog driver for Allwinner A10/A13
In-Reply-To: <1374009903-10203-1-git-send-email-carlo.caione@gmail.com>
References: <1374009903-10203-1-git-send-email-carlo.caione@gmail.com>
Message-ID: <20130718231107.GB8465@roeck-us.net>

On Tue, Jul 16, 2013 at 11:25:03PM +0200, Carlo Caione wrote:
> This patch adds the driver for the watchdog found in the Allwinner A10 and
> A13 SoCs. It has DT-support and uses the new watchdog framework.
> 
> Signed-off-by: Carlo Caione <carlo.caione at gmail.com>
> Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  drivers/watchdog/Kconfig     |  10 ++
>  drivers/watchdog/Makefile    |   1 +
>  drivers/watchdog/sunxi_wdt.c | 241 +++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 252 insertions(+)
>  create mode 100644 drivers/watchdog/sunxi_wdt.c
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 362085d..d1d53f3 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -290,6 +290,16 @@ config ORION_WATCHDOG
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called orion_wdt.
>  
> +config SUNXI_WATCHDOG
> +	tristate "Allwinner SoCs watchdog support"
> +	depends on ARCH_SUNXI
> +	select WATCHDOG_CORE
> +	help
> +	  Say Y here to include support for the watchdog timer
> +	  in Allwinner SoCs.
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called sunxi_wdt.
> +
>  config COH901327_WATCHDOG
>  	bool "ST-Ericsson COH 901 327 watchdog"
>  	depends on ARCH_U300
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 2f26a0b..6c5bb27 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -46,6 +46,7 @@ obj-$(CONFIG_PNX4008_WATCHDOG) += pnx4008_wdt.o
>  obj-$(CONFIG_IOP_WATCHDOG) += iop_wdt.o
>  obj-$(CONFIG_DAVINCI_WATCHDOG) += davinci_wdt.o
>  obj-$(CONFIG_ORION_WATCHDOG) += orion_wdt.o
> +obj-$(CONFIG_SUNXI_WATCHDOG) += sunxi_wdt.o
>  obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
>  obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
>  obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
> diff --git a/drivers/watchdog/sunxi_wdt.c b/drivers/watchdog/sunxi_wdt.c
> new file mode 100644
> index 0000000..11bfaf2
> --- /dev/null
> +++ b/drivers/watchdog/sunxi_wdt.c
> @@ -0,0 +1,241 @@
> +/*
> + *      sunxi Watchdog Driver
> + *
> + *      Copyright (c) 2013 Carlo Caione
> + *                    2012 Henrik Nordstrom
> + *
> + *      This program is free software; you can redistribute it and/or
> + *      modify it under the terms of the GNU General Public License
> + *      as published by the Free Software Foundation; either version
> + *      2 of the License, or (at your option) any later version.
> + *
> + *      Based on xen_wdt.c
> + *      (c) Copyright 2010 Novell, Inc.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>

Is this include file really needed ?

> +#include <linux/platform_device.h>
> +#include <linux/types.h>
> +#include <linux/watchdog.h>
> +
> +#define WDT_MAX_TIMEOUT         16
> +#define WDT_MIN_TIMEOUT         1
> +#define WDT_MODE_TIMEOUT(n)     ((n) << 3)
> +#define WDT_TIMEOUT_MASK        WDT_MODE_TIMEOUT(0x0F)
> +
> +#define WDT_CTRL                0x00
> +#define WDT_CTRL_RELOAD         ((1 << 0) | (0x0a57 << 1))
> +
> +#define WDT_MODE                0x04
> +#define WDT_MODE_EN             (1 << 0)
> +#define WDT_MODE_RST_EN         (1 << 1)
> +
> +#define DRV_NAME		"sunxi-wdt"
> +#define DRV_VERSION		"1.0"
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +static unsigned int timeout = WDT_MAX_TIMEOUT;
> +
> +struct sunxi_wdt_dev {
> +	struct watchdog_device wdt_dev;
> +	void __iomem *wdt_base;
> +};
> +
> +/*
> + * wdt_timeout_map maps the watchdog timer interval value in seconds to
> + * the value of the register WDT_MODE bit 3:6
> + *
> + * [timeout seconds] = register value
> + *
> + */
> +
> +static const int wdt_timeout_map[] = {
> +	[1] = 0b0001,  /* 1s  */
> +	[2] = 0b0010,  /* 2s  */
> +	[3] = 0b0011,  /* 3s  */
> +	[4] = 0b0100,  /* 4s  */
> +	[5] = 0b0101,  /* 5s  */
> +	[6] = 0b0110,  /* 6s  */
> +	[8] = 0b0111,  /* 8s  */
> +	[10] = 0b1000, /* 10s */
> +	[12] = 0b1001, /* 12s */
> +	[14] = 0b1010, /* 14s */
> +	[16] = 0b1011, /* 16s */
> +};
> +
> +static int sunxi_wdt_ping(struct watchdog_device *wdt_dev)
> +{
> +	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
> +	void __iomem *wdt_base = sunxi_wdt->wdt_base;
> +
> +	iowrite32(WDT_CTRL_RELOAD, wdt_base + WDT_CTRL);
> +
> +	return 0;
> +}
> +
> +static int sunxi_wdt_set_timeout(struct watchdog_device *wdt_dev,
> +		unsigned int timeout)
> +{
> +	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
> +	void __iomem *wdt_base = sunxi_wdt->wdt_base;
> +	u32 reg;
> +
> +	if (timeout > WDT_MAX_TIMEOUT)
> +		return -EINVAL;
> +
This check is already done by the infrastructure and thus not needed here.

Guenter


From sboyd at codeaurora.org  Thu Jul 18 19:21:13 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:13 -0700
Subject: [PATCH v4 00/17] 64-bit friendly generic sched_clock()
Message-ID: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>

This patchset adds support for 64 bit counters in the generic
sched_clock code and converts drivers over to use it. Based
on v3.11-rc1.

Changes since v3:
 * Move to use seqcount to fix issues with 64-bit cyc counters
 * Move to hrtimer to fix underflow/overflow errors in wraparound
   calculation
 * Use of 1 hour in clocks_calc_mult_shift
 * Converted over drivers in drivers/clocksource

Stephen Boyd (17):
  clocksource: Extract max nsec calculation into separate function
  sched_clock: Use seqcount instead of rolling our own
  sched_clock: Use an hrtimer instead of timer
  sched_clock: Add support for >32 bit sched_clock
  arch_timer: Move to generic sched_clock framework
  sched_clock: Remove sched_clock_func() hook
  clocksource: bcm2835: Switch to sched_clock_register()
  ocksource: dbx500-prcmu: Switch to sched_clock_register()
  clocksource: dw_apb_timer_of: Switch to sched_clock_register()
  clocksource: mxs_timer: Switch to sched_clock_register()
  clocksource: nomadik: Switch to sched_clock_register()
  clocksource: samsung_pwm_timer: Switch to sched_clock_register()
  clocksource: tegra: Switch to sched_clock_register()
  clocksource: time-armada-370-xp: Switch to sched_clock_register()
  clocksource: sirf: Switch to sched_clock_register() and use 64 bits
  clocksource: vf_pit_timer: Switch to sched_clock_register()
  sched_clock: Deprecate setup_sched_clock()

 arch/arm/kernel/arch_timer.c              |  14 ----
 arch/arm64/Kconfig                        |   1 +
 arch/arm64/kernel/time.c                  |  10 ---
 drivers/clocksource/arm_arch_timer.c      |   4 ++
 drivers/clocksource/bcm2835_timer.c       |   4 +-
 drivers/clocksource/clksrc-dbx500-prcmu.c |   5 +-
 drivers/clocksource/dw_apb_timer_of.c     |   4 +-
 drivers/clocksource/mxs_timer.c           |   4 +-
 drivers/clocksource/nomadik-mtu.c         |   4 +-
 drivers/clocksource/samsung_pwm_timer.c   |   4 +-
 drivers/clocksource/tegra20_timer.c       |   4 +-
 drivers/clocksource/time-armada-370-xp.c  |   4 +-
 drivers/clocksource/timer-prima2.c        |   6 +-
 drivers/clocksource/vf_pit_timer.c        |   4 +-
 include/linux/clocksource.h               |   2 +
 include/linux/sched_clock.h               |   7 +-
 kernel/time/clocksource.c                 |  45 ++++++++-----
 kernel/time/sched_clock.c                 | 105 +++++++++++++++---------------
 18 files changed, 116 insertions(+), 115 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:15 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:15 -0700
Subject: [PATCH v4 02/17] sched_clock: Use seqcount instead of rolling our own
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-3-git-send-email-sboyd@codeaurora.org>

We're going to increase the cyc value to 64 bits in the near
future. Doing that is going to break the custom seqcount
implementation in the sched_clock code because 64 bit numbers
aren't guaranteed to be atomic. Replace the cyc_copy with a
seqcount to avoid this problem.

Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 kernel/time/sched_clock.c | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index a326f27..396f7b9 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -14,11 +14,12 @@
 #include <linux/syscore_ops.h>
 #include <linux/timer.h>
 #include <linux/sched_clock.h>
+#include <linux/seqlock.h>
 
 struct clock_data {
 	u64 epoch_ns;
 	u32 epoch_cyc;
-	u32 epoch_cyc_copy;
+	seqcount_t seq;
 	unsigned long rate;
 	u32 mult;
 	u32 shift;
@@ -54,23 +55,16 @@ static unsigned long long notrace sched_clock_32(void)
 	u64 epoch_ns;
 	u32 epoch_cyc;
 	u32 cyc;
+	unsigned long seq;
 
 	if (cd.suspended)
 		return cd.epoch_ns;
 
-	/*
-	 * Load the epoch_cyc and epoch_ns atomically.  We do this by
-	 * ensuring that we always write epoch_cyc, epoch_ns and
-	 * epoch_cyc_copy in strict order, and read them in strict order.
-	 * If epoch_cyc and epoch_cyc_copy are not equal, then we're in
-	 * the middle of an update, and we should repeat the load.
-	 */
 	do {
+		seq = read_seqcount_begin(&cd.seq);
 		epoch_cyc = cd.epoch_cyc;
-		smp_rmb();
 		epoch_ns = cd.epoch_ns;
-		smp_rmb();
-	} while (epoch_cyc != cd.epoch_cyc_copy);
+	} while (read_seqcount_retry(&cd.seq, seq));
 
 	cyc = read_sched_clock();
 	cyc = (cyc - epoch_cyc) & sched_clock_mask;
@@ -90,16 +84,12 @@ static void notrace update_sched_clock(void)
 	ns = cd.epoch_ns +
 		cyc_to_ns((cyc - cd.epoch_cyc) & sched_clock_mask,
 			  cd.mult, cd.shift);
-	/*
-	 * Write epoch_cyc and epoch_ns in a way that the update is
-	 * detectable in cyc_to_fixed_sched_clock().
-	 */
+
 	raw_local_irq_save(flags);
-	cd.epoch_cyc_copy = cyc;
-	smp_wmb();
+	write_seqcount_begin(&cd.seq);
 	cd.epoch_ns = ns;
-	smp_wmb();
 	cd.epoch_cyc = cyc;
+	write_seqcount_end(&cd.seq);
 	raw_local_irq_restore(flags);
 }
 
@@ -195,7 +185,6 @@ static int sched_clock_suspend(void)
 static void sched_clock_resume(void)
 {
 	cd.epoch_cyc = read_sched_clock();
-	cd.epoch_cyc_copy = cd.epoch_cyc;
 	cd.suspended = false;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:16 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:16 -0700
Subject: [PATCH v4 03/17] sched_clock: Use an hrtimer instead of timer
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-4-git-send-email-sboyd@codeaurora.org>

In the next patch we're going to increase the number of bits that
the generic sched_clock can handle to be greater than 32. With
more than 32 bits the wraparound time can be larger than what can
fit into the units that msecs_to_jiffies takes (unsigned int).
Luckily, the wraparound is initially calculated in nanoseconds
which we can easily use with hrtimers, so switch to using an
hrtimer.

Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 kernel/time/sched_clock.c | 29 ++++++++++++++++-------------
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 396f7b9..a269890b 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -8,15 +8,17 @@
 #include <linux/clocksource.h>
 #include <linux/init.h>
 #include <linux/jiffies.h>
+#include <linux/ktime.h>
 #include <linux/kernel.h>
 #include <linux/moduleparam.h>
 #include <linux/sched.h>
 #include <linux/syscore_ops.h>
-#include <linux/timer.h>
+#include <linux/hrtimer.h>
 #include <linux/sched_clock.h>
 #include <linux/seqlock.h>
 
 struct clock_data {
+	ktime_t wrap_kt;
 	u64 epoch_ns;
 	u32 epoch_cyc;
 	seqcount_t seq;
@@ -26,8 +28,7 @@ struct clock_data {
 	bool suspended;
 };
 
-static void sched_clock_poll(unsigned long wrap_ticks);
-static DEFINE_TIMER(sched_clock_timer, sched_clock_poll, 0, 0);
+static struct hrtimer sched_clock_timer;
 static int irqtime = -1;
 
 core_param(irqtime, irqtime, int, 0400);
@@ -93,15 +94,16 @@ static void notrace update_sched_clock(void)
 	raw_local_irq_restore(flags);
 }
 
-static void sched_clock_poll(unsigned long wrap_ticks)
+static enum hrtimer_restart sched_clock_poll(struct hrtimer *hrt)
 {
-	mod_timer(&sched_clock_timer, round_jiffies(jiffies + wrap_ticks));
 	update_sched_clock();
+	hrtimer_forward_now(hrt, cd.wrap_kt);
+	return HRTIMER_RESTART;
 }
 
 void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
 {
-	unsigned long r, w;
+	unsigned long r;
 	u64 res, wrap;
 	char r_unit;
 
@@ -129,19 +131,19 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
 
 	/* calculate how many ns until we wrap */
 	wrap = cyc_to_ns((1ULL << bits) - 1, cd.mult, cd.shift);
-	do_div(wrap, NSEC_PER_MSEC);
-	w = wrap;
+	cd.wrap_kt = ns_to_ktime(wrap - (wrap >> 3));
 
 	/* calculate the ns resolution of this counter */
 	res = cyc_to_ns(1ULL, cd.mult, cd.shift);
-	pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lums\n",
-		bits, r, r_unit, res, w);
+	pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns\n",
+		bits, r, r_unit, res, wrap);
 
 	/*
 	 * Start the timer to keep sched_clock() properly updated and
 	 * sets the initial epoch.
 	 */
-	sched_clock_timer.data = msecs_to_jiffies(w - (w / 10));
+	hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+	sched_clock_timer.function = sched_clock_poll;
 	update_sched_clock();
 
 	/*
@@ -172,12 +174,13 @@ void __init sched_clock_postinit(void)
 	if (read_sched_clock == jiffy_sched_clock_read)
 		setup_sched_clock(jiffy_sched_clock_read, 32, HZ);
 
-	sched_clock_poll(sched_clock_timer.data);
+	update_sched_clock();
+	hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
 }
 
 static int sched_clock_suspend(void)
 {
-	sched_clock_poll(sched_clock_timer.data);
+	sched_clock_poll(&sched_clock_timer);
 	cd.suspended = true;
 	return 0;
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:17 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:17 -0700
Subject: [PATCH v4 04/17] sched_clock: Add support for >32 bit sched_clock
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-5-git-send-email-sboyd@codeaurora.org>

The ARM architected system counter has at least 56 usable bits.
Add support for counters with more than 32 bits to the generic
sched_clock implementation so we can increase the time between
wakeups due to dealing with wrap-around on these devices while
benefiting from the irqtime accounting and suspend/resume
handling that the generic sched_clock code already has. On my
system using 56 bits over 32 bits changes the wraparound time
from a few minutes to an hour. For faster running counters (GHz
range) this is even more important because we may not be able to
execute the timer in time to deal with the wraparound if only 32
bits are used.

We choose a maxsec value of 3600 seconds because we assume no
system will go idle for more than an hour. In the future we may
need to increase this value.

Note: All users should switch over to the 64-bit read function so
we can remove setup_sched_clock() in favor of sched_clock_register().

Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 include/linux/sched_clock.h |  2 ++
 kernel/time/sched_clock.c   | 46 +++++++++++++++++++++++++++++++--------------
 2 files changed, 34 insertions(+), 14 deletions(-)

diff --git a/include/linux/sched_clock.h b/include/linux/sched_clock.h
index fa7922c..eca7abe 100644
--- a/include/linux/sched_clock.h
+++ b/include/linux/sched_clock.h
@@ -15,6 +15,8 @@ static inline void sched_clock_postinit(void) { }
 #endif
 
 extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
+extern void sched_clock_register(u64 (*read)(void), int bits,
+				 unsigned long rate);
 
 extern unsigned long long (*sched_clock_func)(void);
 
diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index a269890b..3aa83ba 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -16,11 +16,12 @@
 #include <linux/hrtimer.h>
 #include <linux/sched_clock.h>
 #include <linux/seqlock.h>
+#include <linux/bitops.h>
 
 struct clock_data {
 	ktime_t wrap_kt;
 	u64 epoch_ns;
-	u32 epoch_cyc;
+	u64 epoch_cyc;
 	seqcount_t seq;
 	unsigned long rate;
 	u32 mult;
@@ -37,14 +38,25 @@ static struct clock_data cd = {
 	.mult	= NSEC_PER_SEC / HZ,
 };
 
-static u32 __read_mostly sched_clock_mask = 0xffffffff;
+static u64 __read_mostly sched_clock_mask;
 
-static u32 notrace jiffy_sched_clock_read(void)
+static u64 notrace jiffy_sched_clock_read(void)
 {
-	return (u32)(jiffies - INITIAL_JIFFIES);
+	/*
+	 * We don't need to use get_jiffies_64 on 32-bit arches here
+	 * because we register with BITS_PER_LONG
+	 */
+	return (u64)(jiffies - INITIAL_JIFFIES);
+}
+
+static u32 __read_mostly (*read_sched_clock_32)(void);
+
+static u64 notrace read_sched_clock_32_wrapper(void)
+{
+	return read_sched_clock_32();
 }
 
-static u32 __read_mostly (*read_sched_clock)(void) = jiffy_sched_clock_read;
+static u64 __read_mostly (*read_sched_clock)(void) = jiffy_sched_clock_read;
 
 static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 shift)
 {
@@ -54,8 +66,8 @@ static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 shift)
 static unsigned long long notrace sched_clock_32(void)
 {
 	u64 epoch_ns;
-	u32 epoch_cyc;
-	u32 cyc;
+	u64 epoch_cyc;
+	u64 cyc;
 	unsigned long seq;
 
 	if (cd.suspended)
@@ -78,7 +90,7 @@ static unsigned long long notrace sched_clock_32(void)
 static void notrace update_sched_clock(void)
 {
 	unsigned long flags;
-	u32 cyc;
+	u64 cyc;
 	u64 ns;
 
 	cyc = read_sched_clock();
@@ -101,7 +113,8 @@ static enum hrtimer_restart sched_clock_poll(struct hrtimer *hrt)
 	return HRTIMER_RESTART;
 }
 
-void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
+void __init sched_clock_register(u64 (*read)(void), int bits,
+				 unsigned long rate)
 {
 	unsigned long r;
 	u64 res, wrap;
@@ -110,14 +123,13 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
 	if (cd.rate > rate)
 		return;
 
-	BUG_ON(bits > 32);
 	WARN_ON(!irqs_disabled());
 	read_sched_clock = read;
-	sched_clock_mask = (1 << bits) - 1;
+	sched_clock_mask = CLOCKSOURCE_MASK(bits);
 	cd.rate = rate;
 
 	/* calculate the mult/shift to convert counter ticks to ns. */
-	clocks_calc_mult_shift(&cd.mult, &cd.shift, rate, NSEC_PER_SEC, 0);
+	clocks_calc_mult_shift(&cd.mult, &cd.shift, rate, NSEC_PER_SEC, 3600);
 
 	r = rate;
 	if (r >= 4000000) {
@@ -130,7 +142,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
 		r_unit = ' ';
 
 	/* calculate how many ns until we wrap */
-	wrap = cyc_to_ns((1ULL << bits) - 1, cd.mult, cd.shift);
+	wrap = clocks_calc_max_nsecs(cd.mult, cd.shift, 0, sched_clock_mask);
 	cd.wrap_kt = ns_to_ktime(wrap - (wrap >> 3));
 
 	/* calculate the ns resolution of this counter */
@@ -158,6 +170,12 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
 	pr_debug("Registered %pF as sched_clock source\n", read);
 }
 
+void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
+{
+	read_sched_clock_32 = read;
+	sched_clock_register(read_sched_clock_32_wrapper, bits, rate);
+}
+
 unsigned long long __read_mostly (*sched_clock_func)(void) = sched_clock_32;
 
 unsigned long long notrace sched_clock(void)
@@ -172,7 +190,7 @@ void __init sched_clock_postinit(void)
 	 * make it the final one one.
 	 */
 	if (read_sched_clock == jiffy_sched_clock_read)
-		setup_sched_clock(jiffy_sched_clock_read, 32, HZ);
+		sched_clock_register(jiffy_sched_clock_read, BITS_PER_LONG, HZ);
 
 	update_sched_clock();
 	hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:14 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:14 -0700
Subject: [PATCH v4 01/17] clocksource: Extract max nsec calculation into
 separate function
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-2-git-send-email-sboyd@codeaurora.org>

We need to calculate the same number in the clocksource code and
the sched_clock code, so extract this code into its own function.
We also drop the min_t and just use min() because the two types
are the same.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 include/linux/clocksource.h |  2 ++
 kernel/time/clocksource.c   | 45 ++++++++++++++++++++++++++++++---------------
 2 files changed, 32 insertions(+), 15 deletions(-)

diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index dbbf8aa..67301a4 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -292,6 +292,8 @@ extern void clocksource_resume(void);
 extern struct clocksource * __init __weak clocksource_default_clock(void);
 extern void clocksource_mark_unstable(struct clocksource *cs);
 
+extern u64
+clocks_calc_max_nsecs(u32 mult, u32 shift, u32 maxadj, u64 mask);
 extern void
 clocks_calc_mult_shift(u32 *mult, u32 *shift, u32 from, u32 to, u32 minsec);
 
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 50a8736..637a14a 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -537,40 +537,55 @@ static u32 clocksource_max_adjustment(struct clocksource *cs)
 }
 
 /**
- * clocksource_max_deferment - Returns max time the clocksource can be deferred
- * @cs:         Pointer to clocksource
- *
+ * clocks_calc_max_nsecs - Returns maximum nanoseconds that can be converted
+ * @mult:	cycle to nanosecond multiplier
+ * @shift:	cycle to nanosecond divisor (power of two)
+ * @maxadj:	maximum adjustment value to mult (~11%)
+ * @mask:	bitmask for two's complement subtraction of non 64 bit counters
  */
-static u64 clocksource_max_deferment(struct clocksource *cs)
+u64 clocks_calc_max_nsecs(u32 mult, u32 shift, u32 maxadj, u64 mask)
 {
 	u64 max_nsecs, max_cycles;
 
 	/*
 	 * Calculate the maximum number of cycles that we can pass to the
 	 * cyc2ns function without overflowing a 64-bit signed result. The
-	 * maximum number of cycles is equal to ULLONG_MAX/(cs->mult+cs->maxadj)
+	 * maximum number of cycles is equal to ULLONG_MAX/(mult+maxadj)
 	 * which is equivalent to the below.
-	 * max_cycles < (2^63)/(cs->mult + cs->maxadj)
-	 * max_cycles < 2^(log2((2^63)/(cs->mult + cs->maxadj)))
-	 * max_cycles < 2^(log2(2^63) - log2(cs->mult + cs->maxadj))
-	 * max_cycles < 2^(63 - log2(cs->mult + cs->maxadj))
-	 * max_cycles < 1 << (63 - log2(cs->mult + cs->maxadj))
+	 * max_cycles < (2^63)/(mult + maxadj)
+	 * max_cycles < 2^(log2((2^63)/(mult + maxadj)))
+	 * max_cycles < 2^(log2(2^63) - log2(mult + maxadj))
+	 * max_cycles < 2^(63 - log2(mult + maxadj))
+	 * max_cycles < 1 << (63 - log2(mult + maxadj))
 	 * Please note that we add 1 to the result of the log2 to account for
 	 * any rounding errors, ensure the above inequality is satisfied and
 	 * no overflow will occur.
 	 */
-	max_cycles = 1ULL << (63 - (ilog2(cs->mult + cs->maxadj) + 1));
+	max_cycles = 1ULL << (63 - (ilog2(mult + maxadj) + 1));
 
 	/*
 	 * The actual maximum number of cycles we can defer the clocksource is
-	 * determined by the minimum of max_cycles and cs->mask.
+	 * determined by the minimum of max_cycles and mask.
 	 * Note: Here we subtract the maxadj to make sure we don't sleep for
 	 * too long if there's a large negative adjustment.
 	 */
-	max_cycles = min_t(u64, max_cycles, (u64) cs->mask);
-	max_nsecs = clocksource_cyc2ns(max_cycles, cs->mult - cs->maxadj,
-					cs->shift);
+	max_cycles = min(max_cycles, mask);
+	max_nsecs = clocksource_cyc2ns(max_cycles, mult - maxadj, shift);
+
+	return max_nsecs;
+}
+
+/**
+ * clocksource_max_deferment - Returns max time the clocksource can be deferred
+ * @cs:         Pointer to clocksource
+ *
+ */
+static u64 clocksource_max_deferment(struct clocksource *cs)
+{
+	u64 max_nsecs;
 
+	max_nsecs = clocks_calc_max_nsecs(cs->mult, cs->shift, cs->maxadj,
+					  cs->mask);
 	/*
 	 * To ensure that the clocksource does not wrap whilst we are idle,
 	 * limit the time the clocksource can be deferred by 12.5%. Please
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:25 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:25 -0700
Subject: [PATCH v4 12/17] clocksource: samsung_pwm_timer: Switch to
 sched_clock_register()
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-13-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Tomasz Figa <t.figa at samsung.com>
Cc: Kyungmin Park <kyungmin.park at samsung.com>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/samsung_pwm_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index 584b547..09e8bc7 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -310,7 +310,7 @@ static void __iomem *samsung_timer_reg(void)
  * this wraps around for now, since it is just a relative time
  * stamp. (Inspired by U300 implementation.)
  */
-static u32 notrace samsung_read_sched_clock(void)
+static u64 notrace samsung_read_sched_clock(void)
 {
 	void __iomem *reg = samsung_timer_reg();
 
@@ -337,7 +337,7 @@ static void __init samsung_clocksource_init(void)
 	samsung_time_setup(pwm.source_id, pwm.tcnt_max);
 	samsung_time_start(pwm.source_id, true);
 
-	setup_sched_clock(samsung_read_sched_clock,
+	sched_clock_register(samsung_read_sched_clock,
 						pwm.variant.bits, clock_rate);
 
 	ret = clocksource_mmio_init(reg, "samsung_clocksource_timer",
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:22 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:22 -0700
Subject: [PATCH v4 09/17] clocksource: dw_apb_timer_of: Switch to
 sched_clock_register()
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-10-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/dw_apb_timer_of.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
index 4cbae4f..003b230 100644
--- a/drivers/clocksource/dw_apb_timer_of.c
+++ b/drivers/clocksource/dw_apb_timer_of.c
@@ -106,7 +106,7 @@ static void add_clocksource(struct device_node *source_timer)
 	sched_rate = rate;
 }
 
-static u32 read_sched_clock(void)
+static u64 read_sched_clock(void)
 {
 	return __raw_readl(sched_io_base);
 }
@@ -128,7 +128,7 @@ static void init_sched_clock(void)
 		of_node_put(sched_timer);
 	}
 
-	setup_sched_clock(read_sched_clock, 32, sched_rate);
+	sched_clock_register(read_sched_clock, 32, sched_rate);
 }
 
 static int num_called;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:24 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:24 -0700
Subject: [PATCH v4 11/17] clocksource: nomadik: Switch to
 sched_clock_register()
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-12-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/nomadik-mtu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/nomadik-mtu.c b/drivers/clocksource/nomadik-mtu.c
index 7d2c2c5..2242cd3 100644
--- a/drivers/clocksource/nomadik-mtu.c
+++ b/drivers/clocksource/nomadik-mtu.c
@@ -76,7 +76,7 @@ static struct delay_timer mtu_delay_timer;
  * local implementation which uses the clocksource to get some
  * better resolution when scheduling the kernel.
  */
-static u32 notrace nomadik_read_sched_clock(void)
+static u64 notrace nomadik_read_sched_clock(void)
 {
 	if (unlikely(!mtu_base))
 		return 0;
@@ -230,7 +230,7 @@ static void __init __nmdk_timer_init(void __iomem *base, int irq,
 		       "mtu_0");
 
 #ifdef CONFIG_CLKSRC_NOMADIK_MTU_SCHED_CLOCK
-	setup_sched_clock(nomadik_read_sched_clock, 32, rate);
+	sched_clock_register(nomadik_read_sched_clock, 32, rate);
 #endif
 
 	/* Timer 1 is used for events, register irq and clockevents */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:21 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:21 -0700
Subject: [PATCH v4 08/17] ocksource: dbx500-prcmu: Switch to
 sched_clock_register()
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-9-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Srinidhi Kasagar <srinidhi.kasagar at stericsson.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/clksrc-dbx500-prcmu.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/clocksource/clksrc-dbx500-prcmu.c b/drivers/clocksource/clksrc-dbx500-prcmu.c
index a9fd4ad..b375106 100644
--- a/drivers/clocksource/clksrc-dbx500-prcmu.c
+++ b/drivers/clocksource/clksrc-dbx500-prcmu.c
@@ -53,7 +53,7 @@ static struct clocksource clocksource_dbx500_prcmu = {
 
 #ifdef CONFIG_CLKSRC_DBX500_PRCMU_SCHED_CLOCK
 
-static u32 notrace dbx500_prcmu_sched_clock_read(void)
+static u64 notrace dbx500_prcmu_sched_clock_read(void)
 {
 	if (unlikely(!clksrc_dbx500_timer_base))
 		return 0;
@@ -81,8 +81,7 @@ void __init clksrc_dbx500_prcmu_init(void __iomem *base)
 		       clksrc_dbx500_timer_base + PRCMU_TIMER_REF);
 	}
 #ifdef CONFIG_CLKSRC_DBX500_PRCMU_SCHED_CLOCK
-	setup_sched_clock(dbx500_prcmu_sched_clock_read,
-			 32, RATE_32K);
+	sched_clock_register(dbx500_prcmu_sched_clock_read, 32, RATE_32K);
 #endif
 	clocksource_register_hz(&clocksource_dbx500_prcmu, RATE_32K);
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:23 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:23 -0700
Subject: [PATCH v4 10/17] clocksource: mxs_timer: Switch to
 sched_clock_register()
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-11-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Shawn Guo <shawn.guo at linaro.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/mxs_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/mxs_timer.c b/drivers/clocksource/mxs_timer.c
index 0f5e65f..445b68a 100644
--- a/drivers/clocksource/mxs_timer.c
+++ b/drivers/clocksource/mxs_timer.c
@@ -222,7 +222,7 @@ static struct clocksource clocksource_mxs = {
 	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
-static u32 notrace mxs_read_sched_clock_v2(void)
+static u64 notrace mxs_read_sched_clock_v2(void)
 {
 	return ~readl_relaxed(mxs_timrot_base + HW_TIMROT_RUNNING_COUNTn(1));
 }
@@ -236,7 +236,7 @@ static int __init mxs_clocksource_init(struct clk *timer_clk)
 	else {
 		clocksource_mmio_init(mxs_timrot_base + HW_TIMROT_RUNNING_COUNTn(1),
 			"mxs_timer", c, 200, 32, clocksource_mmio_readl_down);
-		setup_sched_clock(mxs_read_sched_clock_v2, 32, c);
+		sched_clock_register(mxs_read_sched_clock_v2, 32, c);
 	}
 
 	return 0;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:27 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:27 -0700
Subject: [PATCH v4 14/17] clocksource: time-armada-370-xp: Switch to
 sched_clock_register()
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-15-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/time-armada-370-xp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
index efdca32..2bec8dc 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -71,7 +71,7 @@ static u32 ticks_per_jiffy;
 
 static struct clock_event_device __percpu **percpu_armada_370_xp_evt;
 
-static u32 notrace armada_370_xp_read_sched_clock(void)
+static u64 notrace armada_370_xp_read_sched_clock(void)
 {
 	return ~readl(timer_base + TIMER0_VAL_OFF);
 }
@@ -258,7 +258,7 @@ void __init armada_370_xp_timer_init(void)
 	/*
 	 * Set scale and timer for sched_clock.
 	 */
-	setup_sched_clock(armada_370_xp_read_sched_clock, 32, timer_clk);
+	sched_clock_register(armada_370_xp_read_sched_clock, 32, timer_clk);
 
 	/*
 	 * Setup free-running clocksource timer (interrupts
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:26 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:26 -0700
Subject: [PATCH v4 13/17] clocksource: tegra: Switch to sched_clock_register()
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-14-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Stephen Warren <swarren at wwwdotorg.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/tegra20_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/tegra20_timer.c b/drivers/clocksource/tegra20_timer.c
index 9396170..5cff616 100644
--- a/drivers/clocksource/tegra20_timer.c
+++ b/drivers/clocksource/tegra20_timer.c
@@ -98,7 +98,7 @@ static struct clock_event_device tegra_clockevent = {
 	.set_mode	= tegra_timer_set_mode,
 };
 
-static u32 notrace tegra_read_sched_clock(void)
+static u64 notrace tegra_read_sched_clock(void)
 {
 	return timer_readl(TIMERUS_CNTR_1US);
 }
@@ -200,7 +200,7 @@ static void __init tegra20_init_timer(struct device_node *np)
 		WARN(1, "Unknown clock rate");
 	}
 
-	setup_sched_clock(tegra_read_sched_clock, 32, 1000000);
+	sched_clock_register(tegra_read_sched_clock, 32, 1000000);
 
 	if (clocksource_mmio_init(timer_reg_base + TIMERUS_CNTR_1US,
 		"timer_us", 1000000, 300, 32, clocksource_mmio_readl_up)) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:20 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:20 -0700
Subject: [PATCH v4 07/17] clocksource: bcm2835: Switch to
 sched_clock_register()
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-8-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Stephen Warren <swarren at wwwdotorg.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/bcm2835_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/bcm2835_timer.c b/drivers/clocksource/bcm2835_timer.c
index 07ea7ce..26ed331 100644
--- a/drivers/clocksource/bcm2835_timer.c
+++ b/drivers/clocksource/bcm2835_timer.c
@@ -49,7 +49,7 @@ struct bcm2835_timer {
 
 static void __iomem *system_clock __read_mostly;
 
-static u32 notrace bcm2835_sched_read(void)
+static u64 notrace bcm2835_sched_read(void)
 {
 	return readl_relaxed(system_clock);
 }
@@ -110,7 +110,7 @@ static void __init bcm2835_timer_init(struct device_node *node)
 		panic("Can't read clock-frequency");
 
 	system_clock = base + REG_COUNTER_LO;
-	setup_sched_clock(bcm2835_sched_read, 32, freq);
+	sched_clock_register(bcm2835_sched_read, 32, freq);
 
 	clocksource_mmio_init(base + REG_COUNTER_LO, node->name,
 		freq, 300, 32, clocksource_mmio_readl_up);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:19 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:19 -0700
Subject: [PATCH v4 06/17] sched_clock: Remove sched_clock_func() hook
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-7-git-send-email-sboyd@codeaurora.org>

Nobody is using sched_clock_func() anymore now that sched_clock
supports up to 64 bits. Remove the hook so that new code only
uses sched_clock_register().

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 include/linux/sched_clock.h | 2 --
 kernel/time/sched_clock.c   | 9 +--------
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/include/linux/sched_clock.h b/include/linux/sched_clock.h
index eca7abe..cddf0c2 100644
--- a/include/linux/sched_clock.h
+++ b/include/linux/sched_clock.h
@@ -18,6 +18,4 @@ extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
 extern void sched_clock_register(u64 (*read)(void), int bits,
 				 unsigned long rate);
 
-extern unsigned long long (*sched_clock_func)(void);
-
 #endif
diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 3aa83ba..659c59a 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -63,7 +63,7 @@ static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 shift)
 	return (cyc * mult) >> shift;
 }
 
-static unsigned long long notrace sched_clock_32(void)
+unsigned long long notrace sched_clock(void)
 {
 	u64 epoch_ns;
 	u64 epoch_cyc;
@@ -176,13 +176,6 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
 	sched_clock_register(read_sched_clock_32_wrapper, bits, rate);
 }
 
-unsigned long long __read_mostly (*sched_clock_func)(void) = sched_clock_32;
-
-unsigned long long notrace sched_clock(void)
-{
-	return sched_clock_func();
-}
-
 void __init sched_clock_postinit(void)
 {
 	/*
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:18 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:18 -0700
Subject: [PATCH v4 05/17] arch_timer: Move to generic sched_clock framework
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-6-git-send-email-sboyd@codeaurora.org>

Register with the generic sched_clock framework now that it
supports 64 bits. This fixes two problems with the current
sched_clock support for machines using the architected timers.
First off, we don't subtract the start value from subsequent
sched_clock calls so we can potentially start off with
sched_clock returning gigantic numbers. Second, there is no
support for suspend/resume handling so problems such as discussed
in 6a4dae5 (ARM: 7565/1: sched: stop sched_clock() during
suspend, 2012-10-23) can happen without this patch. Finally, it
allows us to move the sched_clock setup into drivers clocksource
out of the arch ports.

Cc: Christopher Covington <cov at codeaurora.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/kernel/arch_timer.c         | 14 --------------
 arch/arm64/Kconfig                   |  1 +
 arch/arm64/kernel/time.c             | 10 ----------
 drivers/clocksource/arm_arch_timer.c |  4 ++++
 4 files changed, 5 insertions(+), 24 deletions(-)

diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index 221f07b..1791f12 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -11,7 +11,6 @@
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/errno.h>
-#include <linux/sched_clock.h>
 
 #include <asm/delay.h>
 
@@ -22,13 +21,6 @@ static unsigned long arch_timer_read_counter_long(void)
 	return arch_timer_read_counter();
 }
 
-static u32 sched_clock_mult __read_mostly;
-
-static unsigned long long notrace arch_timer_sched_clock(void)
-{
-	return arch_timer_read_counter() * sched_clock_mult;
-}
-
 static struct delay_timer arch_delay_timer;
 
 static void __init arch_timer_delay_timer_register(void)
@@ -48,11 +40,5 @@ int __init arch_timer_arch_init(void)
 
 	arch_timer_delay_timer_register();
 
-	/* Cache the sched_clock multiplier to save a divide in the hot path. */
-	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
-	sched_clock_func = arch_timer_sched_clock;
-	pr_info("sched_clock: ARM arch timer >56 bits at %ukHz, resolution %uns\n",
-		arch_timer_rate / 1000, sched_clock_mult);
-
 	return 0;
 }
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9737e97..e32b471 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -14,6 +14,7 @@ config ARM64
 	select GENERIC_IOMAP
 	select GENERIC_IRQ_PROBE
 	select GENERIC_IRQ_SHOW
+	select GENERIC_SCHED_CLOCK
 	select GENERIC_SMP_IDLE_THREAD
 	select GENERIC_TIME_VSYSCALL
 	select HARDIRQS_SW_RESEND
diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index 03dc371..29c39d5 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -61,13 +61,6 @@ unsigned long profile_pc(struct pt_regs *regs)
 EXPORT_SYMBOL(profile_pc);
 #endif
 
-static u64 sched_clock_mult __read_mostly;
-
-unsigned long long notrace sched_clock(void)
-{
-	return arch_timer_read_counter() * sched_clock_mult;
-}
-
 void __init time_init(void)
 {
 	u32 arch_timer_rate;
@@ -78,9 +71,6 @@ void __init time_init(void)
 	if (!arch_timer_rate)
 		panic("Unable to initialise architected timer.\n");
 
-	/* Cache the sched_clock multiplier to save a divide in the hot path. */
-	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
-
 	/* Calibrate the delay loop directly */
 	lpj_fine = arch_timer_rate / HZ;
 }
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 053d846..2facf14 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -17,6 +17,7 @@
 #include <linux/interrupt.h>
 #include <linux/of_irq.h>
 #include <linux/io.h>
+#include <linux/sched_clock.h>
 
 #include <asm/arch_timer.h>
 #include <asm/virt.h>
@@ -281,6 +282,9 @@ static int __init arch_timer_register(void)
 	timecounter_init(&timecounter, &cyclecounter,
 			 arch_counter_get_cntvct());
 
+	/* 56 bits minimum, so we assume worst case rollover */
+	sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate);
+
 	if (arch_timer_use_virtual) {
 		ppi = arch_timer_ppi[VIRT_PPI];
 		err = request_percpu_irq(ppi, arch_timer_handler_virt,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:30 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:30 -0700
Subject: [PATCH v4 17/17] sched_clock: Deprecate setup_sched_clock()
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-18-git-send-email-sboyd@codeaurora.org>

Users of the generic sched_clock framework should use
sched_clock_register() instead of setup_sched_clock(). Mark the
function as deprecated.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 include/linux/sched_clock.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/sched_clock.h b/include/linux/sched_clock.h
index cddf0c2..d3da3e2 100644
--- a/include/linux/sched_clock.h
+++ b/include/linux/sched_clock.h
@@ -14,7 +14,8 @@ extern void sched_clock_postinit(void);
 static inline void sched_clock_postinit(void) { }
 #endif
 
-extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
+/* Use sched_clock_register() instead */
+extern void __deprecated setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
 extern void sched_clock_register(u64 (*read)(void), int bits,
 				 unsigned long rate);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:28 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:28 -0700
Subject: [PATCH v4 15/17] clocksource: sirf: Switch to sched_clock_register()
 and use 64 bits
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-16-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface and use all 64 bits of this timer.

Cc: Barry Song <Baohua.Song at csr.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/timer-prima2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clocksource/timer-prima2.c b/drivers/clocksource/timer-prima2.c
index ef3cfb2..8a492d3 100644
--- a/drivers/clocksource/timer-prima2.c
+++ b/drivers/clocksource/timer-prima2.c
@@ -165,9 +165,9 @@ static struct irqaction sirfsoc_timer_irq = {
 };
 
 /* Overwrite weak default sched_clock with more precise one */
-static u32 notrace sirfsoc_read_sched_clock(void)
+static u64 notrace sirfsoc_read_sched_clock(void)
 {
-	return (u32)(sirfsoc_timer_read(NULL) & 0xffffffff);
+	return sirfsoc_timer_read(NULL);
 }
 
 static void __init sirfsoc_clockevent_init(void)
@@ -206,7 +206,7 @@ static void __init sirfsoc_prima2_timer_init(struct device_node *np)
 
 	BUG_ON(clocksource_register_hz(&sirfsoc_clocksource, CLOCK_TICK_RATE));
 
-	setup_sched_clock(sirfsoc_read_sched_clock, 32, CLOCK_TICK_RATE);
+	sched_clock_register(sirfsoc_read_sched_clock, 64, CLOCK_TICK_RATE);
 
 	BUG_ON(setup_irq(sirfsoc_timer_irq.irq, &sirfsoc_timer_irq));
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:21:29 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:21:29 -0700
Subject: [PATCH v4 16/17] clocksource: vf_pit_timer: Switch to
 sched_clock_register()
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374189690-10810-17-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Jingchang Lu <b35083 at freescale.com>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/vf_pit_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/vf_pit_timer.c b/drivers/clocksource/vf_pit_timer.c
index 587e020..02821b0 100644
--- a/drivers/clocksource/vf_pit_timer.c
+++ b/drivers/clocksource/vf_pit_timer.c
@@ -52,7 +52,7 @@ static inline void pit_irq_acknowledge(void)
 	__raw_writel(PITTFLG_TIF, clkevt_base + PITTFLG);
 }
 
-static unsigned int pit_read_sched_clock(void)
+static u64 pit_read_sched_clock(void)
 {
 	return __raw_readl(clksrc_base + PITCVAL);
 }
@@ -64,7 +64,7 @@ static int __init pit_clocksource_init(unsigned long rate)
 	__raw_writel(~0UL, clksrc_base + PITLDVAL);
 	__raw_writel(PITTCTRL_TEN, clksrc_base + PITTCTRL);
 
-	setup_sched_clock(pit_read_sched_clock, 32, rate);
+	sched_clock_register(pit_read_sched_clock, 32, rate);
 	return clocksource_mmio_init(clksrc_base + PITCVAL, "vf-pit", rate,
 			300, 32, clocksource_mmio_readl_down);
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From santosh.shilimkar at ti.com  Thu Jul 18 19:39:04 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 18 Jul 2013 19:39:04 -0400
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <51E83A4F.5080904@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <51E83A4F.5080904@ti.com>
Message-ID: <51E87C98.5030001@ti.com>

On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
> On 07/18/2013 11:43 AM, Sricharan R wrote:
>> Some socs have a large number of interrupts/dma requests to service
>> the needs of its many peripherals and subsystems. All of the
>> requests lines from the subsystems are not needed at the same
>> time, so they have to be muxed to the controllers appropriately.
>> In such places a interrupt/dma controllers are preceded by an
>> IRQ/DMA CROSSBAR that provides flexibility in muxing the device
>> requests to the controller inputs.
>>
>> The Peripheral irq/dma requests are connected to one crossbar's input
>> and the output of the crossbar is connected to controller's input
>> line. On POR, there are some mappings which are done by default.
>> Those peripherals which do not have a mapping on POR, should be configured
>> to route its requests using the crossbar.
>>
>> The drivers identifies every controller's crossbar as individual devices.
>> The mappings can be specified from the DT crossbar nodes and those gets mapped
>> during the crossbar device's probe. The mappings can also be specified by adding
>> the crossbar lines to the peripheral device nodes and map it with
>> crossbar_map/unmap apis.
>>
>> Signed-off-by: Sricharan R <r.sricharan at ti.com>
>> ---
>>   .../devicetree/bindings/arm/omap/crossbar.txt      |   24 ++
>>   drivers/misc/Kconfig                               |    8 +
>>   drivers/misc/Makefile                              |    1 +
>>   drivers/misc/crossbar.c                            |  258 ++++++++++++++++++++
>>   include/linux/crossbar.h                           |   71 ++++++
>>   5 files changed, 362 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>   create mode 100644 drivers/misc/crossbar.c
>>   create mode 100644 include/linux/crossbar.h
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> new file mode 100644
>> index 0000000..02a8a28
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> @@ -0,0 +1,24 @@
>> +* TI - IRQ/DMA Crossbar
>> +
>> +This version is an implementation of the Crossbar IRQ/DMA IP
>> +
>> +Required properties:
>> +- compatible : Should be "ti,dra-crossbar"
>> +- crossbar-name: Name of the controller to which crossbar output is routed
>> +- reg:    Contains crossbar register address range
>> +- reg-width: Represents the width of the individual registers
>> +- crossbar-lines:  Default mappings.Should contain the crossbar-name
>> +           device name, int/dma request number, crossbar number,
>> +           register offset in the same order.
>> +
>> +Examples:
>> +        crossbar_mpu: mpuirq at 4a002a48 {
>> +            compatible = "crossbar";
>> +            crossbar-name = "mpu-irq";
>> +            reg = <0x4a002a48 0x0130>;
>> +            reg-width = <16>;
>> +            crossbar-lines = "mpu-irq", "rtc-ss-alarm", <0x9f 0xd9 0x12c>,
>> +                     "mpu-irq", "mcasp3-arevt", <0x9e 0x96 0x12a>,
>> +                     "mpu-irq", "mcasp3-axevt", <0x9d 0x97 0x128>;
>> +        };
> 
> I carry forward my TI internal objection to this approach:
> 
> NAK.
> 
> DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt is as follows:
> hardware IP block -interrupt line-> IRQ Cross bar -> GIC IRQ line --> MPU IRQ.
> 
> 
> What we have done today for DRA is to provide IRQ numbers as direct maps from hardware IP block to GIC based on default IRQ cross bar mapping.
> 
> Lets see what happens as a result of this:
> 
> https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
> uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
> uart1: serial at 4806a000 {
> <snip>
> +            interrupts = <0 72 0x4>;
> Assumes that GIC interrupt by default mapping used.
> 
> Now, think of a product that wants to use UART10 instead of UART1, SoC design allows you do that by doing a remapping of GIC interrupt to UART10 - which is awesome.
> 
> Option 1: u-boot/bootloader
> mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
> 
> Option 2: in kernel do a raw_writel version of option 1.
> This patch does option 1 in kernel in a "fancy way" - why the heck would I want to do that when u-boot allows me to do the same thing in uEnv.txt
> 
> Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
> a) Allows us to define every single IP available on DRA7 SoC.
> b) GIC allocation happens dynamically
> c) allow products use IPs as needed.
> 
> Sorry, Conceptually option 3 is the right approach in my view.
> instead of doing
> uart1: serial at 4806a000 {
> <snip>
> +            interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
> 
> we should be able to do the following:
> uart1: serial at 4806a000 {
> <snip>
> +            interrupts = <TI_IRQ_CROSSBAR 192 IRQ_TYPE_LEVEL_HIGH>;
> 
> and not worry about the GIC interrupt number used
> 
> 
Since the cross-bar is not limited t0 IRQ lines and applicable for
DMA request lines as well, making it IRQ chip doesn't make sense. Its
not typical pin control functionality either but at least that framework
is much closer to consider as an option.

Actually its more of setting up the IRQ and DMA pins maps once
at boot for a given SOC based on chosen configuration by the
board. So I am leaning towards pinctrl as well. Just haven't
thought enough about whether thats the best approach.

CC'ing Linus W and Tony L whether we can use pinctrl framework
for such an IP and if yes how ;-).

Regards,
Santosh



From sboyd at codeaurora.org  Thu Jul 18 19:59:30 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:59:30 -0700
Subject: [PATCH v4 3/5] clocksource: arch_timer: Pass clock event to set_mode
 callback
In-Reply-To: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
References: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374191972-18015-4-git-send-email-sboyd@codeaurora.org>

There isn't any reason why we don't pass the event here and we'll
need it in the near future for memory mapped arch timers anyway.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/arm_arch_timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index aa07038..7624ba5 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -140,7 +140,7 @@ static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
 
 	clk->cpumask = cpumask_of(smp_processor_id());
 
-	clk->set_mode(CLOCK_EVT_MODE_SHUTDOWN, NULL);
+	clk->set_mode(CLOCK_EVT_MODE_SHUTDOWN, clk);
 
 	clockevents_config_and_register(clk, arch_timer_rate,
 					0xf, 0x7fffffff);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:59:27 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:59:27 -0700
Subject: [PATCH v4 0/5] Memory mapped architected timers
Message-ID: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>

This patchset adds support for memory mapped architected timers. We
don't have any other global broadcast timer in our system, so we use the
mmio timer during low power modes. The first patch changes the register
accessor to an enum per Thomas' request. The second patch is the binding.
The next two patches lay some groundwork so that the last patch is simpler.
The final patch adds support for mmio timers.

Patches are based on v3.11-rc1.

Updates since v3:
 * Rebased onto v3.11-rc1
 * New patch to use compiler warnings instead of BUILD_BUG_ON()

Updates since v2:
 * Rebased onto v3.10-rc1

Updates since v1:
 * Assigned counter reading function and commented why for arm64
 * Updated DT binding to replace frame-id with frame-number and use status
   property


Stephen Boyd (5):
  clocksource: arch_timer: Make register accessors less error-prone
  Documentation: Add memory mapped ARM architected timer binding
  clocksource: arch_timer: Pass clock event to set_mode callback
  clocksource: arch_timer: Push the read/write wrappers deeper
  clocksource: arch_timer: Add support for memory mapped timers

 .../devicetree/bindings/arm/arch_timer.txt         |  59 ++-
 arch/arm/include/asm/arch_timer.h                  |  14 +-
 arch/arm64/include/asm/arch_timer.h                |  23 +-
 drivers/clocksource/arm_arch_timer.c               | 446 +++++++++++++++++----
 include/clocksource/arm_arch_timer.h               |  10 +-
 5 files changed, 455 insertions(+), 97 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:59:29 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:59:29 -0700
Subject: [PATCH v4 2/5] Documentation: Add memory mapped ARM architected timer
 binding
In-Reply-To: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
References: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374191972-18015-3-git-send-email-sboyd@codeaurora.org>

Add a binding for the arm architected timer hardware's memory
mapped interface. The mmio timer hardware is made up of one base
frame and a collection of up to 8 timer frames, where each of the
8 timer frames can have either one or two views. A frame
typically maps to a privilege level (user/kernel, hypervisor,
secure). The first view has full access to the registers within a
frame, while the second view can be restricted to particular
registers within a frame. Each frame must support a physical
timer. It's optional for a frame to support a virtual timer.

Cc: devicetree-discuss at lists.ozlabs.org
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Rob Herring <robherring2 at gmail.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 .../devicetree/bindings/arm/arch_timer.txt         | 59 ++++++++++++++++++++--
 1 file changed, 56 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
index 20746e5..06fc760 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -1,10 +1,14 @@
 * ARM architected timer
 
-ARM cores may have a per-core architected timer, which provides per-cpu timers.
+ARM cores may have a per-core architected timer, which provides per-cpu timers,
+or a memory mapped architected timer, which provides up to 8 frames with a
+physical and optional virtual timer per frame.
 
-The timer is attached to a GIC to deliver its per-processor interrupts.
+The per-core architected timer is attached to a GIC to deliver its
+per-processor interrupts via PPIs. The memory mapped timer is attached to a GIC
+to deliver its interrupts via SPIs.
 
-** Timer node properties:
+** CP15 Timer node properties:
 
 - compatible : Should at least contain one of
 	"arm,armv7-timer"
@@ -26,3 +30,52 @@ Example:
 			     <1 10 0xf08>;
 		clock-frequency = <100000000>;
 	};
+
+** Memory mapped timer node properties:
+
+- compatible : Should at least contain "arm,armv7-timer-mem".
+
+- clock-frequency : The frequency of the main counter, in Hz. Optional.
+
+- reg : The control frame base address.
+
+Note that #address-cells, #size-cells, and ranges shall be present to ensure
+the CPU can address a frame's registers.
+
+A timer node has up to 8 frame sub-nodes, each with the following properties:
+
+- frame-number: 0 to 7.
+
+- interrupts : Interrupt list for physical and virtual timers in that order.
+  The virtual timer interrupt is optional.
+
+- reg : The first and second view base addresses in that order. The second view
+  base address is optional.
+
+- status : "disabled" indicates the frame is not available for use. Optional.
+
+Example:
+
+	timer at f0000000 {
+		compatible = "arm,armv7-timer-mem";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		reg = <0xf0000000 0x1000>;
+		clock-frequency = <50000000>;
+
+		frame at f0001000 {
+			frame-number = <0>
+			interrupts = <0 13 0x8>,
+				     <0 14 0x8>;
+			reg = <0xf0001000 0x1000>,
+			      <0xf0002000 0x1000>;
+		};
+
+		frame at f0003000 {
+			frame-number = <1>
+			interrupts = <0 15 0x8>;
+			reg = <0xf0003000 0x1000>;
+			status = "disabled";
+		};
+	};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:59:31 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:59:31 -0700
Subject: [PATCH v4 4/5] clocksource: arch_timer: Push the read/write wrappers
 deeper
In-Reply-To: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
References: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374191972-18015-5-git-send-email-sboyd@codeaurora.org>

We're going to introduce support to read and write the memory
mapped timer registers in the next patch, so push the cp15
read/write functions one level deeper. This simplifies the next
patch and makes it clearer what's going on.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/include/asm/arch_timer.h    |  4 ++--
 arch/arm64/include/asm/arch_timer.h  |  4 ++--
 drivers/clocksource/arm_arch_timer.c | 46 ++++++++++++++++++++++++------------
 3 files changed, 35 insertions(+), 19 deletions(-)

diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h
index aeb93f3..5560946 100644
--- a/arch/arm/include/asm/arch_timer.h
+++ b/arch/arm/include/asm/arch_timer.h
@@ -18,7 +18,7 @@ int arch_timer_arch_init(void);
  * the code. At least it does so with a recent GCC (4.6.3).
  */
 static __always_inline
-void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val)
+void arch_timer_reg_write_cp15(int access, enum arch_timer_reg reg, u32 val)
 {
 	if (access == ARCH_TIMER_PHYS_ACCESS) {
 		switch (reg) {
@@ -44,7 +44,7 @@ void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val)
 }
 
 static __always_inline
-u32 arch_timer_reg_read(int access, enum arch_timer_reg reg)
+u32 arch_timer_reg_read_cp15(int access, enum arch_timer_reg reg)
 {
 	u32 val = 0;
 
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index dbca771..7181e77 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -32,7 +32,7 @@
  * the code.
  */
 static __always_inline
-void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val)
+void arch_timer_reg_write_cp15(int access, enum arch_timer_reg reg, u32 val)
 {
 	if (access == ARCH_TIMER_PHYS_ACCESS) {
 		switch (reg) {
@@ -58,7 +58,7 @@ void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val)
 }
 
 static __always_inline
-u32 arch_timer_reg_read(int access, enum arch_timer_reg reg)
+u32 arch_timer_reg_read_cp15(int access, enum arch_timer_reg reg)
 {
 	u32 val;
 
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 7624ba5..a9ca284 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -43,14 +43,28 @@ static bool arch_timer_use_virtual = true;
  * Architected system timer support.
  */
 
+static __always_inline
+void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val,
+		struct clock_event_device *clk)
+{
+	arch_timer_reg_write_cp15(access, reg, val);
+}
+
+static __always_inline
+u32 arch_timer_reg_read(int access, enum arch_timer_reg reg,
+		struct clock_event_device *clk)
+{
+	return arch_timer_reg_read_cp15(access, reg);
+}
+
 static __always_inline irqreturn_t timer_handler(const int access,
 					struct clock_event_device *evt)
 {
 	unsigned long ctrl;
-	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL);
+	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, evt);
 	if (ctrl & ARCH_TIMER_CTRL_IT_STAT) {
 		ctrl |= ARCH_TIMER_CTRL_IT_MASK;
-		arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl);
+		arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, evt);
 		evt->event_handler(evt);
 		return IRQ_HANDLED;
 	}
@@ -72,15 +86,16 @@ static irqreturn_t arch_timer_handler_phys(int irq, void *dev_id)
 	return timer_handler(ARCH_TIMER_PHYS_ACCESS, evt);
 }
 
-static __always_inline void timer_set_mode(const int access, int mode)
+static __always_inline void timer_set_mode(const int access, int mode,
+				  struct clock_event_device *clk)
 {
 	unsigned long ctrl;
 	switch (mode) {
 	case CLOCK_EVT_MODE_UNUSED:
 	case CLOCK_EVT_MODE_SHUTDOWN:
-		ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL);
+		ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, clk);
 		ctrl &= ~ARCH_TIMER_CTRL_ENABLE;
-		arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl);
+		arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
 		break;
 	default:
 		break;
@@ -90,36 +105,37 @@ static __always_inline void timer_set_mode(const int access, int mode)
 static void arch_timer_set_mode_virt(enum clock_event_mode mode,
 				     struct clock_event_device *clk)
 {
-	timer_set_mode(ARCH_TIMER_VIRT_ACCESS, mode);
+	timer_set_mode(ARCH_TIMER_VIRT_ACCESS, mode, clk);
 }
 
 static void arch_timer_set_mode_phys(enum clock_event_mode mode,
 				     struct clock_event_device *clk)
 {
-	timer_set_mode(ARCH_TIMER_PHYS_ACCESS, mode);
+	timer_set_mode(ARCH_TIMER_PHYS_ACCESS, mode, clk);
 }
 
-static __always_inline void set_next_event(const int access, unsigned long evt)
+static __always_inline void set_next_event(const int access, unsigned long evt,
+				  struct clock_event_device *clk)
 {
 	unsigned long ctrl;
-	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL);
+	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL, clk);
 	ctrl |= ARCH_TIMER_CTRL_ENABLE;
 	ctrl &= ~ARCH_TIMER_CTRL_IT_MASK;
-	arch_timer_reg_write(access, ARCH_TIMER_REG_TVAL, evt);
-	arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl);
+	arch_timer_reg_write(access, ARCH_TIMER_REG_TVAL, evt, clk);
+	arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
 }
 
 static int arch_timer_set_next_event_virt(unsigned long evt,
-					  struct clock_event_device *unused)
+					  struct clock_event_device *clk)
 {
-	set_next_event(ARCH_TIMER_VIRT_ACCESS, evt);
+	set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk);
 	return 0;
 }
 
 static int arch_timer_set_next_event_phys(unsigned long evt,
-					  struct clock_event_device *unused)
+					  struct clock_event_device *clk)
 {
-	set_next_event(ARCH_TIMER_PHYS_ACCESS, evt);
+	set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk);
 	return 0;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:59:28 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:59:28 -0700
Subject: [PATCH v4 1/5] clocksource: arch_timer: Make register accessors less
 error-prone
In-Reply-To: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
References: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374191972-18015-2-git-send-email-sboyd@codeaurora.org>

Using an enum for the register we wish to access allows newer
compilers to determine if we've forgotten a case in our switch
statement. This allows us to remove the BUILD_BUG() instances in
the arm64 port, avoiding problems where optimizations may not
happen.

To try and force better code generation we're currently marking
the accessor functions as inline, but newer compilers can ignore
the inline keyword unless it's marked __always_inline. Luckily on
arm and arm64 inline is __always_inline, but let's make
everything __always_inline to be explicit.

Suggested-by: Thomas Gleixner <tglx at linutronix.de>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/include/asm/arch_timer.h    | 14 ++++++--------
 arch/arm64/include/asm/arch_timer.h  | 23 +++++++++--------------
 drivers/clocksource/arm_arch_timer.c |  6 +++---
 include/clocksource/arm_arch_timer.h |  6 ++++--
 4 files changed, 22 insertions(+), 27 deletions(-)

diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h
index accefe0..aeb93f3 100644
--- a/arch/arm/include/asm/arch_timer.h
+++ b/arch/arm/include/asm/arch_timer.h
@@ -17,7 +17,8 @@ int arch_timer_arch_init(void);
  * nicely work out which register we want, and chuck away the rest of
  * the code. At least it does so with a recent GCC (4.6.3).
  */
-static inline void arch_timer_reg_write(const int access, const int reg, u32 val)
+static __always_inline
+void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val)
 {
 	if (access == ARCH_TIMER_PHYS_ACCESS) {
 		switch (reg) {
@@ -28,9 +29,7 @@ static inline void arch_timer_reg_write(const int access, const int reg, u32 val
 			asm volatile("mcr p15, 0, %0, c14, c2, 0" : : "r" (val));
 			break;
 		}
-	}
-
-	if (access == ARCH_TIMER_VIRT_ACCESS) {
+	} else if (access == ARCH_TIMER_VIRT_ACCESS) {
 		switch (reg) {
 		case ARCH_TIMER_REG_CTRL:
 			asm volatile("mcr p15, 0, %0, c14, c3, 1" : : "r" (val));
@@ -44,7 +43,8 @@ static inline void arch_timer_reg_write(const int access, const int reg, u32 val
 	isb();
 }
 
-static inline u32 arch_timer_reg_read(const int access, const int reg)
+static __always_inline
+u32 arch_timer_reg_read(int access, enum arch_timer_reg reg)
 {
 	u32 val = 0;
 
@@ -57,9 +57,7 @@ static inline u32 arch_timer_reg_read(const int access, const int reg)
 			asm volatile("mrc p15, 0, %0, c14, c2, 0" : "=r" (val));
 			break;
 		}
-	}
-
-	if (access == ARCH_TIMER_VIRT_ACCESS) {
+	} else if (access == ARCH_TIMER_VIRT_ACCESS) {
 		switch (reg) {
 		case ARCH_TIMER_REG_CTRL:
 			asm volatile("mrc p15, 0, %0, c14, c3, 1" : "=r" (val));
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index d56ed11..dbca771 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -26,7 +26,13 @@
 
 #include <clocksource/arm_arch_timer.h>
 
-static inline void arch_timer_reg_write(int access, int reg, u32 val)
+/*
+ * These register accessors are marked inline so the compiler can
+ * nicely work out which register we want, and chuck away the rest of
+ * the code.
+ */
+static __always_inline
+void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val)
 {
 	if (access == ARCH_TIMER_PHYS_ACCESS) {
 		switch (reg) {
@@ -36,8 +42,6 @@ static inline void arch_timer_reg_write(int access, int reg, u32 val)
 		case ARCH_TIMER_REG_TVAL:
 			asm volatile("msr cntp_tval_el0, %0" : : "r" (val));
 			break;
-		default:
-			BUILD_BUG();
 		}
 	} else if (access == ARCH_TIMER_VIRT_ACCESS) {
 		switch (reg) {
@@ -47,17 +51,14 @@ static inline void arch_timer_reg_write(int access, int reg, u32 val)
 		case ARCH_TIMER_REG_TVAL:
 			asm volatile("msr cntv_tval_el0, %0" : : "r" (val));
 			break;
-		default:
-			BUILD_BUG();
 		}
-	} else {
-		BUILD_BUG();
 	}
 
 	isb();
 }
 
-static inline u32 arch_timer_reg_read(int access, int reg)
+static __always_inline
+u32 arch_timer_reg_read(int access, enum arch_timer_reg reg)
 {
 	u32 val;
 
@@ -69,8 +70,6 @@ static inline u32 arch_timer_reg_read(int access, int reg)
 		case ARCH_TIMER_REG_TVAL:
 			asm volatile("mrs %0, cntp_tval_el0" : "=r" (val));
 			break;
-		default:
-			BUILD_BUG();
 		}
 	} else if (access == ARCH_TIMER_VIRT_ACCESS) {
 		switch (reg) {
@@ -80,11 +79,7 @@ static inline u32 arch_timer_reg_read(int access, int reg)
 		case ARCH_TIMER_REG_TVAL:
 			asm volatile("mrs %0, cntv_tval_el0" : "=r" (val));
 			break;
-		default:
-			BUILD_BUG();
 		}
-	} else {
-		BUILD_BUG();
 	}
 
 	return val;
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 053d846..aa07038 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -43,7 +43,7 @@ static bool arch_timer_use_virtual = true;
  * Architected system timer support.
  */
 
-static inline irqreturn_t timer_handler(const int access,
+static __always_inline irqreturn_t timer_handler(const int access,
 					struct clock_event_device *evt)
 {
 	unsigned long ctrl;
@@ -72,7 +72,7 @@ static irqreturn_t arch_timer_handler_phys(int irq, void *dev_id)
 	return timer_handler(ARCH_TIMER_PHYS_ACCESS, evt);
 }
 
-static inline void timer_set_mode(const int access, int mode)
+static __always_inline void timer_set_mode(const int access, int mode)
 {
 	unsigned long ctrl;
 	switch (mode) {
@@ -99,7 +99,7 @@ static void arch_timer_set_mode_phys(enum clock_event_mode mode,
 	timer_set_mode(ARCH_TIMER_PHYS_ACCESS, mode);
 }
 
-static inline void set_next_event(const int access, unsigned long evt)
+static __always_inline void set_next_event(const int access, unsigned long evt)
 {
 	unsigned long ctrl;
 	ctrl = arch_timer_reg_read(access, ARCH_TIMER_REG_CTRL);
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index c463ce9..f3da817 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -23,8 +23,10 @@
 #define ARCH_TIMER_CTRL_IT_MASK		(1 << 1)
 #define ARCH_TIMER_CTRL_IT_STAT		(1 << 2)
 
-#define ARCH_TIMER_REG_CTRL		0
-#define ARCH_TIMER_REG_TVAL		1
+enum arch_timer_reg {
+	ARCH_TIMER_REG_CTRL,
+	ARCH_TIMER_REG_TVAL,
+};
 
 #define ARCH_TIMER_PHYS_ACCESS		0
 #define ARCH_TIMER_VIRT_ACCESS		1
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Thu Jul 18 19:59:32 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 16:59:32 -0700
Subject: [PATCH v4 5/5] clocksource: arch_timer: Add support for memory mapped
 timers
In-Reply-To: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
References: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374191972-18015-6-git-send-email-sboyd@codeaurora.org>

Add support for the memory mapped timers by filling in the
read/write functions and adding some parsing code. Note that we
only register one clocksource, preferring the cp15 based
clocksource over the mmio one.

To keep things simple we register one global clockevent. This
covers the case of UP and SMP systems with only mmio hardware and
systems where the memory mapped timers are used as the broadcast
timer in low power modes.

The DT binding allows for per-CPU memory mapped timers in case we
want to support that in the future, but the code isn't added
here. We also don't do much for hypervisor support, although it
should be possible to support it by searching for at least two
frames where one frame has the virtual capability and then
updating KVM timers to support it.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <Marc.Zyngier at arm.com>
Cc: Rob Herring <robherring2 at gmail.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clocksource/arm_arch_timer.c | 402 ++++++++++++++++++++++++++++++-----
 include/clocksource/arm_arch_timer.h |   4 +-
 2 files changed, 350 insertions(+), 56 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index a9ca284..b3df46d 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -16,13 +16,39 @@
 #include <linux/clockchips.h>
 #include <linux/interrupt.h>
 #include <linux/of_irq.h>
+#include <linux/of_address.h>
 #include <linux/io.h>
+#include <linux/slab.h>
 
 #include <asm/arch_timer.h>
 #include <asm/virt.h>
 
 #include <clocksource/arm_arch_timer.h>
 
+#define CNTTIDR		0x08
+#define CNTTIDR_VIRT(n)	(BIT(1) << ((n) * 4))
+
+#define CNTVCT_LO	0x08
+#define CNTVCT_HI	0x0c
+#define CNTFRQ		0x10
+#define CNTP_TVAL	0x28
+#define CNTP_CTL	0x2c
+#define CNTV_TVAL	0x38
+#define CNTV_CTL	0x3c
+
+#define ARCH_CP15_TIMER	BIT(0)
+#define ARCH_MEM_TIMER	BIT(1)
+static unsigned arch_timers_present __initdata;
+
+static void __iomem *arch_counter_base;
+
+struct arch_timer {
+	void __iomem *base;
+	struct clock_event_device evt;
+};
+
+#define to_arch_timer(e) container_of(e, struct arch_timer, evt)
+
 static u32 arch_timer_rate;
 
 enum ppi_nr {
@@ -38,6 +64,7 @@ static int arch_timer_ppi[MAX_TIMER_PPI];
 static struct clock_event_device __percpu *arch_timer_evt;
 
 static bool arch_timer_use_virtual = true;
+static bool arch_timer_mem_use_virtual;
 
 /*
  * Architected system timer support.
@@ -47,14 +74,62 @@ static __always_inline
 void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val,
 		struct clock_event_device *clk)
 {
-	arch_timer_reg_write_cp15(access, reg, val);
+	if (access == ARCH_TIMER_MEM_PHYS_ACCESS) {
+		struct arch_timer *timer = to_arch_timer(clk);
+		switch (reg) {
+		case ARCH_TIMER_REG_CTRL:
+			writel_relaxed(val, timer->base + CNTP_CTL);
+			break;
+		case ARCH_TIMER_REG_TVAL:
+			writel_relaxed(val, timer->base + CNTP_TVAL);
+			break;
+		}
+	} else if (access == ARCH_TIMER_MEM_VIRT_ACCESS) {
+		struct arch_timer *timer = to_arch_timer(clk);
+		switch (reg) {
+		case ARCH_TIMER_REG_CTRL:
+			writel_relaxed(val, timer->base + CNTV_CTL);
+			break;
+		case ARCH_TIMER_REG_TVAL:
+			writel_relaxed(val, timer->base + CNTV_TVAL);
+			break;
+		}
+	} else {
+		arch_timer_reg_write_cp15(access, reg, val);
+	}
 }
 
 static __always_inline
 u32 arch_timer_reg_read(int access, enum arch_timer_reg reg,
 		struct clock_event_device *clk)
 {
-	return arch_timer_reg_read_cp15(access, reg);
+	u32 val;
+
+	if (access == ARCH_TIMER_MEM_PHYS_ACCESS) {
+		struct arch_timer *timer = to_arch_timer(clk);
+		switch (reg) {
+		case ARCH_TIMER_REG_CTRL:
+			val = readl_relaxed(timer->base + CNTP_CTL);
+			break;
+		case ARCH_TIMER_REG_TVAL:
+			val = readl_relaxed(timer->base + CNTP_TVAL);
+			break;
+		}
+	} else if (access == ARCH_TIMER_MEM_VIRT_ACCESS) {
+		struct arch_timer *timer = to_arch_timer(clk);
+		switch (reg) {
+		case ARCH_TIMER_REG_CTRL:
+			val = readl_relaxed(timer->base + CNTV_CTL);
+			break;
+		case ARCH_TIMER_REG_TVAL:
+			val = readl_relaxed(timer->base + CNTV_TVAL);
+			break;
+		}
+	} else {
+		val = arch_timer_reg_read_cp15(access, reg);
+	}
+
+	return val;
 }
 
 static __always_inline irqreturn_t timer_handler(const int access,
@@ -86,6 +161,20 @@ static irqreturn_t arch_timer_handler_phys(int irq, void *dev_id)
 	return timer_handler(ARCH_TIMER_PHYS_ACCESS, evt);
 }
 
+static irqreturn_t arch_timer_handler_phys_mem(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+
+	return timer_handler(ARCH_TIMER_MEM_PHYS_ACCESS, evt);
+}
+
+static irqreturn_t arch_timer_handler_virt_mem(int irq, void *dev_id)
+{
+	struct clock_event_device *evt = dev_id;
+
+	return timer_handler(ARCH_TIMER_MEM_VIRT_ACCESS, evt);
+}
+
 static __always_inline void timer_set_mode(const int access, int mode,
 				  struct clock_event_device *clk)
 {
@@ -114,6 +203,18 @@ static void arch_timer_set_mode_phys(enum clock_event_mode mode,
 	timer_set_mode(ARCH_TIMER_PHYS_ACCESS, mode, clk);
 }
 
+static void arch_timer_set_mode_virt_mem(enum clock_event_mode mode,
+					 struct clock_event_device *clk)
+{
+	timer_set_mode(ARCH_TIMER_MEM_VIRT_ACCESS, mode, clk);
+}
+
+static void arch_timer_set_mode_phys_mem(enum clock_event_mode mode,
+					 struct clock_event_device *clk)
+{
+	timer_set_mode(ARCH_TIMER_MEM_PHYS_ACCESS, mode, clk);
+}
+
 static __always_inline void set_next_event(const int access, unsigned long evt,
 				  struct clock_event_device *clk)
 {
@@ -139,27 +240,62 @@ static int arch_timer_set_next_event_phys(unsigned long evt,
 	return 0;
 }
 
-static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
+static int arch_timer_set_next_event_virt_mem(unsigned long evt,
+					      struct clock_event_device *clk)
 {
-	clk->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP;
-	clk->name = "arch_sys_timer";
-	clk->rating = 450;
-	if (arch_timer_use_virtual) {
-		clk->irq = arch_timer_ppi[VIRT_PPI];
-		clk->set_mode = arch_timer_set_mode_virt;
-		clk->set_next_event = arch_timer_set_next_event_virt;
+	set_next_event(ARCH_TIMER_MEM_VIRT_ACCESS, evt, clk);
+	return 0;
+}
+
+static int arch_timer_set_next_event_phys_mem(unsigned long evt,
+					      struct clock_event_device *clk)
+{
+	set_next_event(ARCH_TIMER_MEM_PHYS_ACCESS, evt, clk);
+	return 0;
+}
+
+static void __cpuinit __arch_timer_setup(unsigned type,
+				       struct clock_event_device *clk)
+{
+	clk->features = CLOCK_EVT_FEAT_ONESHOT;
+
+	if (type == ARCH_CP15_TIMER) {
+		clk->features |= CLOCK_EVT_FEAT_C3STOP;
+		clk->name = "arch_sys_timer";
+		clk->rating = 450;
+		clk->cpumask = cpumask_of(smp_processor_id());
+		if (arch_timer_use_virtual) {
+			clk->irq = arch_timer_ppi[VIRT_PPI];
+			clk->set_mode = arch_timer_set_mode_virt;
+			clk->set_next_event = arch_timer_set_next_event_virt;
+		} else {
+			clk->irq = arch_timer_ppi[PHYS_SECURE_PPI];
+			clk->set_mode = arch_timer_set_mode_phys;
+			clk->set_next_event = arch_timer_set_next_event_phys;
+		}
 	} else {
-		clk->irq = arch_timer_ppi[PHYS_SECURE_PPI];
-		clk->set_mode = arch_timer_set_mode_phys;
-		clk->set_next_event = arch_timer_set_next_event_phys;
+		clk->name = "arch_mem_timer";
+		clk->rating = 400;
+		clk->cpumask = cpu_all_mask;
+		if (arch_timer_mem_use_virtual) {
+			clk->set_mode = arch_timer_set_mode_virt_mem;
+			clk->set_next_event =
+				arch_timer_set_next_event_virt_mem;
+		} else {
+			clk->set_mode = arch_timer_set_mode_phys_mem;
+			clk->set_next_event =
+				arch_timer_set_next_event_phys_mem;
+		}
 	}
 
-	clk->cpumask = cpumask_of(smp_processor_id());
-
 	clk->set_mode(CLOCK_EVT_MODE_SHUTDOWN, clk);
 
-	clockevents_config_and_register(clk, arch_timer_rate,
-					0xf, 0x7fffffff);
+	clockevents_config_and_register(clk, arch_timer_rate, 0xf, 0x7fffffff);
+}
+
+static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
+{
+	__arch_timer_setup(ARCH_CP15_TIMER, clk);
 
 	if (arch_timer_use_virtual)
 		enable_percpu_irq(arch_timer_ppi[VIRT_PPI], 0);
@@ -174,27 +310,41 @@ static int __cpuinit arch_timer_setup(struct clock_event_device *clk)
 	return 0;
 }
 
-static int arch_timer_available(void)
+static void
+arch_timer_detect_rate(void __iomem *cntbase, struct device_node *np)
 {
-	u32 freq;
-
-	if (arch_timer_rate == 0) {
-		freq = arch_timer_get_cntfrq();
-
-		/* Check the timer frequency. */
-		if (freq == 0) {
-			pr_warn("Architected timer frequency not available\n");
-			return -EINVAL;
-		}
+	/* Who has more than one independent system counter? */
+	if (arch_timer_rate)
+		return;
 
-		arch_timer_rate = freq;
+	/* Try to determine the frequency from the device tree or CNTFRQ */
+	if (of_property_read_u32(np, "clock-frequency", &arch_timer_rate)) {
+		if (cntbase)
+			arch_timer_rate = readl_relaxed(cntbase + CNTFRQ);
+		else
+			arch_timer_rate = arch_timer_get_cntfrq();
 	}
 
-	pr_info_once("Architected local timer running at %lu.%02luMHz (%s).\n",
+	/* Check the timer frequency. */
+	if (arch_timer_rate == 0)
+		pr_warn("Architected timer frequency not available\n");
+}
+
+static void arch_timer_banner(unsigned type)
+{
+	pr_info("Architected %s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",
+		     type & ARCH_CP15_TIMER ? "cp15" : "",
+		     type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ?  " and " : "",
+		     type & ARCH_MEM_TIMER ? "mmio" : "",
 		     (unsigned long)arch_timer_rate / 1000000,
 		     (unsigned long)(arch_timer_rate / 10000) % 100,
-		     arch_timer_use_virtual ? "virt" : "phys");
-	return 0;
+		     type & ARCH_CP15_TIMER ?
+			arch_timer_use_virtual ? "virt" : "phys" :
+			"",
+		     type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ?  "/" : "",
+		     type & ARCH_MEM_TIMER ?
+			arch_timer_mem_use_virtual ? "virt" : "phys" :
+			"");
 }
 
 u32 arch_timer_get_rate(void)
@@ -202,19 +352,35 @@ u32 arch_timer_get_rate(void)
 	return arch_timer_rate;
 }
 
-u64 arch_timer_read_counter(void)
+static u64 arch_counter_get_cntvct_mem(void)
 {
-	return arch_counter_get_cntvct();
+	u32 vct_lo, vct_hi, tmp_hi;
+
+	do {
+		vct_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
+		vct_lo = readl_relaxed(arch_counter_base + CNTVCT_LO);
+		tmp_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
+	} while (vct_hi != tmp_hi);
+
+	return ((u64) vct_hi << 32) | vct_lo;
 }
 
+/*
+ * Default to cp15 based access because arm64 uses this function for
+ * sched_clock() before DT is probed and the cp15 method is guaranteed
+ * to exist on arm64. arm doesn't use this before DT is probed so even
+ * if we don't have the cp15 accessors we won't have a problem.
+ */
+u64 (*arch_timer_read_counter)(void) = arch_counter_get_cntvct;
+
 static cycle_t arch_counter_read(struct clocksource *cs)
 {
-	return arch_counter_get_cntvct();
+	return arch_timer_read_counter();
 }
 
 static cycle_t arch_counter_read_cc(const struct cyclecounter *cc)
 {
-	return arch_counter_get_cntvct();
+	return arch_timer_read_counter();
 }
 
 static struct clocksource clocksource_counter = {
@@ -237,6 +403,23 @@ struct timecounter *arch_timer_get_timecounter(void)
 	return &timecounter;
 }
 
+static void __init arch_counter_register(unsigned type)
+{
+	u64 start_count;
+
+	/* Register the CP15 based counter if we have one */
+	if (type & ARCH_CP15_TIMER)
+		arch_timer_read_counter = arch_counter_get_cntvct;
+	else
+		arch_timer_read_counter = arch_counter_get_cntvct_mem;
+
+	start_count = arch_timer_read_counter();
+	clocksource_register_hz(&clocksource_counter, arch_timer_rate);
+	cyclecounter.mult = clocksource_counter.mult;
+	cyclecounter.shift = clocksource_counter.shift;
+	timecounter_init(&timecounter, &cyclecounter, start_count);
+}
+
 static void __cpuinit arch_timer_stop(struct clock_event_device *clk)
 {
 	pr_debug("arch_timer_teardown disable IRQ%d cpu #%d\n",
@@ -281,22 +464,12 @@ static int __init arch_timer_register(void)
 	int err;
 	int ppi;
 
-	err = arch_timer_available();
-	if (err)
-		goto out;
-
 	arch_timer_evt = alloc_percpu(struct clock_event_device);
 	if (!arch_timer_evt) {
 		err = -ENOMEM;
 		goto out;
 	}
 
-	clocksource_register_hz(&clocksource_counter, arch_timer_rate);
-	cyclecounter.mult = clocksource_counter.mult;
-	cyclecounter.shift = clocksource_counter.shift;
-	timecounter_init(&timecounter, &cyclecounter,
-			 arch_counter_get_cntvct());
-
 	if (arch_timer_use_virtual) {
 		ppi = arch_timer_ppi[VIRT_PPI];
 		err = request_percpu_irq(ppi, arch_timer_handler_virt,
@@ -347,24 +520,77 @@ out:
 	return err;
 }
 
+static int __init arch_timer_mem_register(void __iomem *base, unsigned int irq)
+{
+	int ret;
+	irq_handler_t func;
+	struct arch_timer *t;
+
+	t = kzalloc(sizeof(*t), GFP_KERNEL);
+	if (!t)
+		return -ENOMEM;
+
+	t->base = base;
+	t->evt.irq = irq;
+	__arch_timer_setup(ARCH_MEM_TIMER, &t->evt);
+
+	if (arch_timer_mem_use_virtual)
+		func = arch_timer_handler_virt_mem;
+	else
+		func = arch_timer_handler_phys_mem;
+
+	ret = request_irq(irq, func, IRQF_TIMER, "arch_mem_timer", &t->evt);
+	if (ret) {
+		pr_err("arch_timer: Failed to request mem timer irq\n");
+		kfree(t);
+	}
+
+	return ret;
+}
+
+static const struct of_device_id arch_timer_of_match[] __initconst = {
+	{ .compatible   = "arm,armv7-timer",    },
+	{ .compatible   = "arm,armv8-timer",    },
+	{},
+};
+
+static const struct of_device_id arch_timer_mem_of_match[] __initconst = {
+	{ .compatible   = "arm,armv7-timer-mem", },
+	{},
+};
+
+static void __init arch_timer_common_init(void)
+{
+	unsigned mask = ARCH_CP15_TIMER | ARCH_MEM_TIMER;
+
+	/* Wait until both nodes are probed if we have two timers */
+	if ((arch_timers_present & mask) != mask) {
+		if (of_find_matching_node(NULL, arch_timer_mem_of_match) &&
+				!(arch_timers_present & ARCH_MEM_TIMER))
+			return;
+		if (of_find_matching_node(NULL, arch_timer_of_match) &&
+				!(arch_timers_present & ARCH_CP15_TIMER))
+			return;
+	}
+
+	arch_timer_banner(arch_timers_present);
+	arch_counter_register(arch_timers_present);
+	arch_timer_arch_init();
+}
+
 static void __init arch_timer_init(struct device_node *np)
 {
-	u32 freq;
 	int i;
 
-	if (arch_timer_get_rate()) {
+	if (arch_timers_present & ARCH_CP15_TIMER) {
 		pr_warn("arch_timer: multiple nodes in dt, skipping\n");
 		return;
 	}
 
-	/* Try to determine the frequency from the device tree or CNTFRQ */
-	if (!of_property_read_u32(np, "clock-frequency", &freq))
-		arch_timer_rate = freq;
-
+	arch_timers_present |= ARCH_CP15_TIMER;
 	for (i = PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++)
 		arch_timer_ppi[i] = irq_of_parse_and_map(np, i);
-
-	of_node_put(np);
+	arch_timer_detect_rate(NULL, np);
 
 	/*
 	 * If HYP mode is available, we know that the physical timer
@@ -385,7 +611,73 @@ static void __init arch_timer_init(struct device_node *np)
 	}
 
 	arch_timer_register();
-	arch_timer_arch_init();
+	arch_timer_common_init();
 }
 CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_init);
 CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_init);
+
+static void __init arch_timer_mem_init(struct device_node *np)
+{
+	struct device_node *frame, *best_frame = NULL;
+	void __iomem *cntctlbase, *base;
+	unsigned int irq;
+	u32 cnttidr;
+
+	arch_timers_present |= ARCH_MEM_TIMER;
+	cntctlbase = of_iomap(np, 0);
+	if (!cntctlbase) {
+		pr_err("arch_timer: Can't find CNTCTLBase\n");
+		return;
+	}
+
+	cnttidr = readl_relaxed(cntctlbase + CNTTIDR);
+	iounmap(cntctlbase);
+
+	/*
+	 * Try to find a virtual capable frame. Otherwise fall back to a
+	 * physical capable frame.
+	 */
+	for_each_available_child_of_node(np, frame) {
+		int n;
+
+		if (of_property_read_u32(frame, "frame-number", &n)) {
+			pr_err("arch_timer: Missing frame-number\n");
+			of_node_put(best_frame);
+			of_node_put(frame);
+			return;
+		}
+
+		if (cnttidr & CNTTIDR_VIRT(n)) {
+			of_node_put(best_frame);
+			best_frame = frame;
+			arch_timer_mem_use_virtual = true;
+			break;
+		}
+		of_node_put(best_frame);
+		best_frame = of_node_get(frame);
+	}
+
+	base = arch_counter_base = of_iomap(best_frame, 0);
+	if (!base) {
+		pr_err("arch_timer: Can't map frame's registers\n");
+		of_node_put(best_frame);
+		return;
+	}
+
+	if (arch_timer_mem_use_virtual)
+		irq = irq_of_parse_and_map(best_frame, 1);
+	else
+		irq = irq_of_parse_and_map(best_frame, 0);
+	of_node_put(best_frame);
+	if (!irq) {
+		pr_err("arch_timer: Frame missing %s irq",
+				arch_timer_mem_use_virtual ? "virt" : "phys");
+		return;
+	}
+
+	arch_timer_detect_rate(base, np);
+	arch_timer_mem_register(base, irq);
+	arch_timer_common_init();
+}
+CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
+		       arch_timer_mem_init);
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index f3da817..93b7f96 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -30,11 +30,13 @@ enum arch_timer_reg {
 
 #define ARCH_TIMER_PHYS_ACCESS		0
 #define ARCH_TIMER_VIRT_ACCESS		1
+#define ARCH_TIMER_MEM_PHYS_ACCESS	2
+#define ARCH_TIMER_MEM_VIRT_ACCESS	3
 
 #ifdef CONFIG_ARM_ARCH_TIMER
 
 extern u32 arch_timer_get_rate(void);
-extern u64 arch_timer_read_counter(void);
+extern u64 (*arch_timer_read_counter)(void);
 extern struct timecounter *arch_timer_get_timecounter(void);
 
 #else
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From hsweeten at visionengravers.com  Thu Jul 18 20:03:01 2013
From: hsweeten at visionengravers.com (H Hartley Sweeten)
Date: Thu, 18 Jul 2013 17:03:01 -0700
Subject: [PATCH] arm: ep93xx: use soc bus
Message-ID: <201307181703.01961.hsweeten@visionengravers.com>

Use the soc bus to report the silicon revision and Maverick Key. Both
are not currently exposed to the user. In addition, fill in the SoC
family and machine for completeness.

Signed-off-by: H Hartley Sweeten <hsweeten at visionengravers.com>
Cc: Ryan Mallon <rmallon at gmail.com>
Cc: Alexander Shiyan <shc_work at mail.ru>
---
v4: refresh to next-20130718
v3: use the full name for the family as suggested by Alexander Shiyan
v2: address some comments from Ryan Mallon

 arch/arm/mach-ep93xx/Kconfig                 |   1 +
 arch/arm/mach-ep93xx/core.c                  | 108 ++++++++++++++++++++++++++-
 arch/arm/mach-ep93xx/include/mach/platform.h |   3 +-
 3 files changed, 110 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig
index fe3c1fa..91eee1d 100644
--- a/arch/arm/mach-ep93xx/Kconfig
+++ b/arch/arm/mach-ep93xx/Kconfig
@@ -5,6 +5,7 @@ menu "Cirrus EP93xx Implementation Options"
 config EP93XX_SOC_COMMON
 	bool
 	default y
+	select SOC_BUS
 	select LEDS_GPIO_REGISTER
 
 config CRUNCH
diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index df8612f..cefc26e 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -21,6 +21,7 @@
 #include <linux/platform_device.h>
 #include <linux/interrupt.h>
 #include <linux/dma-mapping.h>
+#include <linux/sys_soc.h>
 #include <linux/timex.h>
 #include <linux/irq.h>
 #include <linux/io.h>
@@ -43,6 +44,7 @@
 #include <linux/platform_data/spi-ep93xx.h>
 #include <mach/gpio-ep93xx.h>
 
+#include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <asm/mach/time.h>
 
@@ -896,8 +898,108 @@ void ep93xx_ide_release_gpio(struct platform_device *pdev)
 }
 EXPORT_SYMBOL(ep93xx_ide_release_gpio);
 
-void __init ep93xx_init_devices(void)
+/*************************************************************************
+ * EP93xx Security peripheral
+ *************************************************************************/
+
+/*
+ * The Maverick Key is 256 bits of micro fuses blown at the factory during
+ * manufacturing to uniquely identify a part.
+ *
+ * See: http://arm.cirrus.com/forum/viewtopic.php?t=486&highlight=maverick+key
+ */
+#define EP93XX_SECURITY_REG(x)		(EP93XX_SECURITY_BASE + (x))
+#define EP93XX_SECURITY_SECFLG		EP93XX_SECURITY_REG(0x2400)
+#define EP93XX_SECURITY_FUSEFLG		EP93XX_SECURITY_REG(0x2410)
+#define EP93XX_SECURITY_UNIQID		EP93XX_SECURITY_REG(0x2440)
+#define EP93XX_SECURITY_UNIQCHK		EP93XX_SECURITY_REG(0x2450)
+#define EP93XX_SECURITY_UNIQVAL		EP93XX_SECURITY_REG(0x2460)
+#define EP93XX_SECURITY_SECID1		EP93XX_SECURITY_REG(0x2500)
+#define EP93XX_SECURITY_SECID2		EP93XX_SECURITY_REG(0x2504)
+#define EP93XX_SECURITY_SECCHK1		EP93XX_SECURITY_REG(0x2520)
+#define EP93XX_SECURITY_SECCHK2		EP93XX_SECURITY_REG(0x2524)
+#define EP93XX_SECURITY_UNIQID2		EP93XX_SECURITY_REG(0x2700)
+#define EP93XX_SECURITY_UNIQID3		EP93XX_SECURITY_REG(0x2704)
+#define EP93XX_SECURITY_UNIQID4		EP93XX_SECURITY_REG(0x2708)
+#define EP93XX_SECURITY_UNIQID5		EP93XX_SECURITY_REG(0x270c)
+
+static char ep93xx_soc_id[33];
+
+static const char __init *ep93xx_get_soc_id(void)
 {
+	unsigned int id, id2, id3, id4, id5;
+
+	if (__raw_readl(EP93XX_SECURITY_UNIQVAL) != 1)
+		return "bad Hamming code";
+
+	id = __raw_readl(EP93XX_SECURITY_UNIQID);
+	id2 = __raw_readl(EP93XX_SECURITY_UNIQID2);
+	id3 = __raw_readl(EP93XX_SECURITY_UNIQID3);
+	id4 = __raw_readl(EP93XX_SECURITY_UNIQID4);
+	id5 = __raw_readl(EP93XX_SECURITY_UNIQID5);
+
+	if (id != id2)
+		return "invalid";
+
+	snprintf(ep93xx_soc_id, sizeof(ep93xx_soc_id),
+		 "%08x%08x%08x%08x", id2, id3, id4, id5);
+
+	return ep93xx_soc_id;
+}
+
+static const char __init *ep93xx_get_soc_rev(void)
+{
+	int rev = ep93xx_chip_revision();
+
+	switch (rev) {
+	case EP93XX_CHIP_REV_D0:
+		return "D0";
+	case EP93XX_CHIP_REV_D1:
+		return "D1";
+	case EP93XX_CHIP_REV_E0:
+		return "E0";
+	case EP93XX_CHIP_REV_E1:
+		return "E1";
+	case EP93XX_CHIP_REV_E2:
+		return "E2";
+	default:
+		return "unknown";
+	}
+}
+
+static const char __init *ep93xx_get_machine_name(void)
+{
+	return kasprintf(GFP_KERNEL,"%s", machine_desc->name);
+}
+
+static struct device __init *ep93xx_init_soc(void)
+{
+	struct soc_device_attribute *soc_dev_attr;
+	struct soc_device *soc_dev;
+
+	soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+	if (!soc_dev_attr)
+		return NULL;
+
+	soc_dev_attr->machine = ep93xx_get_machine_name();
+	soc_dev_attr->family = "Cirrus Logic EP93xx";
+	soc_dev_attr->revision = ep93xx_get_soc_rev();
+	soc_dev_attr->soc_id = ep93xx_get_soc_id();
+
+	soc_dev = soc_device_register(soc_dev_attr);
+	if (IS_ERR(soc_dev)) {
+		kfree(soc_dev_attr->machine);
+		kfree(soc_dev_attr);
+		return NULL;
+	}
+
+	return soc_device_to_device(soc_dev);
+}
+
+struct device __init *ep93xx_init_devices(void)
+{
+	struct device *parent;
+
 	/* Disallow access to MaverickCrunch initially */
 	ep93xx_devcfg_clear_bits(EP93XX_SYSCON_DEVCFG_CPENA);
 
@@ -908,6 +1010,8 @@ void __init ep93xx_init_devices(void)
 			       EP93XX_SYSCON_DEVCFG_GONIDE |
 			       EP93XX_SYSCON_DEVCFG_HONIDE);
 
+	parent = ep93xx_init_soc();
+
 	/* Get the GPIO working early, other devices need it */
 	platform_device_register(&ep93xx_gpio_device);
 
@@ -920,6 +1024,8 @@ void __init ep93xx_init_devices(void)
 	platform_device_register(&ep93xx_wdt_device);
 
 	gpio_led_register_device(-1, &ep93xx_led_data);
+
+	return parent;
 }
 
 void ep93xx_restart(enum reboot_mode mode, const char *cmd)
diff --git a/arch/arm/mach-ep93xx/include/mach/platform.h b/arch/arm/mach-ep93xx/include/mach/platform.h
index e256e0b..4c0bbd9 100644
--- a/arch/arm/mach-ep93xx/include/mach/platform.h
+++ b/arch/arm/mach-ep93xx/include/mach/platform.h
@@ -6,6 +6,7 @@
 
 #include <linux/reboot.h>
 
+struct device;
 struct i2c_gpio_platform_data;
 struct i2c_board_info;
 struct spi_board_info;
@@ -54,7 +55,7 @@ void ep93xx_register_ide(void);
 int ep93xx_ide_acquire_gpio(struct platform_device *pdev);
 void ep93xx_ide_release_gpio(struct platform_device *pdev);
 
-void ep93xx_init_devices(void);
+struct device *ep93xx_init_devices(void);
 extern void ep93xx_timer_init(void);
 
 void ep93xx_restart(enum reboot_mode, const char *);
-- 
1.8.3.2



From john.stultz at linaro.org  Thu Jul 18 19:59:44 2013
From: john.stultz at linaro.org (John Stultz)
Date: Thu, 18 Jul 2013 16:59:44 -0700
Subject: [PATCH v4 00/17] 64-bit friendly generic sched_clock()
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <51E88170.3080505@linaro.org>

On 07/18/2013 04:21 PM, Stephen Boyd wrote:
> This patchset adds support for 64 bit counters in the generic
> sched_clock code and converts drivers over to use it. Based
> on v3.11-rc1.
>
> Changes since v3:
>   * Move to use seqcount to fix issues with 64-bit cyc counters
>   * Move to hrtimer to fix underflow/overflow errors in wraparound
>     calculation
>   * Use of 1 hour in clocks_calc_mult_shift
>   * Converted over drivers in drivers/clocksource

I've not been able to take a deep review yet, but this looks pretty much 
like what we discussed last week, so I'm happy with it so far. Has this 
gotten much testing (on both 32 and 64bit systems?)

One detail: Most of this is likely to go in via tip/timers/core, but the 
5/17 "arch_timer: Move to generic sched_clock" will need some 
synchronization with Catalin to make sure its ok to go in via tip. Not 
sure what other arm64 changes are pending that would depend or collide 
with that change.

thanks
-john



From kuninori.morimoto.gx at renesas.com  Thu Jul 18 20:16:05 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Thu, 18 Jul 2013 17:16:05 -0700 (PDT)
Subject: [PATCH 1/3] ARM: shmobile: use common platform header for HPB-DMAC
In-Reply-To: <51E865FA.9000706@cogentembedded.com>
References: <201306300243.57180.sergei.shtylyov@cogentembedded.com>
 <201306300245.58486.sergei.shtylyov@cogentembedded.com>
 <CANqRtoTCaJfbECSpX7nMZoV8SPeQqs-xrJQ0-+-smA+bx3QG=w@mail.gmail.com>
 <51E865FA.9000706@cogentembedded.com>
Message-ID: <87txjrbe11.wl%kuninori.morimoto.gx@renesas.com>


Hi

> >> From: Max Filippov <max.filippov at cogentembedded.com>
> 
> >> Use previously empty <mach/dma.h> to declare HPB-DMA slave IDs.
> 
> >> Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
> >> [Sergei: changed the guard macro name, fixed comment, extended copyright.]
> >> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> >> ---
> >>   arch/arm/mach-shmobile/include/mach/dma.h |   25 ++++++++++++++++++++++++-
> >>   1 file changed, 24 insertions(+), 1 deletion(-)
> 
> > Thanks for your patch. Can you please explain the reason why you put
> > this shared information under mach/?
> 
>     I'm afraid that's more a question to the original author, Phil Edworthy.
> He put this stuff into <mach/hpb-dmae.h>.

Then, why you could send this patch instead of original author,
even though you can't answer any question about it ?

Best regards
---
Kuninori Morimoto


From sboyd at codeaurora.org  Thu Jul 18 20:18:28 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 17:18:28 -0700
Subject: [PATCH v4 08/17] ocksource: dbx500-prcmu: Switch to
 sched_clock_register()
In-Reply-To: <1374189690-10810-9-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-9-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130719001828.GE27430@codeaurora.org>

On 07/18, Stephen Boyd wrote:
> The 32 bit sched_clock interface now supports 64 bits. Upgrade to
> the 64 bit function to allow us to remove the 32 bit registration
> interface.
> 
> Cc: Srinidhi Kasagar <srinidhi.kasagar at stericsson.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---

Hmph, the subject got messed up. If I don't resend please correct
to clocksource.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From nm at ti.com  Thu Jul 18 20:13:18 2013
From: nm at ti.com (Nishanth Menon)
Date: Thu, 18 Jul 2013 19:13:18 -0500
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <51E87C98.5030001@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <51E83A4F.5080904@ti.com> <51E87C98.5030001@ti.com>
Message-ID: <CAGo_u6rO0SjHzXhMBPeSmWykqqpf9phLEPBEaeFtS9bkHoq8qg@mail.gmail.com>

On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar
<santosh.shilimkar at ti.com> wrote:
> On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
>> On 07/18/2013 11:43 AM, Sricharan R wrote:
>>> Some socs have a large number of interrupts/dma requests to service
>>> the needs of its many peripherals and subsystems. All of the
>>> requests lines from the subsystems are not needed at the same
>>> time, so they have to be muxed to the controllers appropriately.
>>> In such places a interrupt/dma controllers are preceded by an
>>> IRQ/DMA CROSSBAR that provides flexibility in muxing the device
>>> requests to the controller inputs.
>>>
>>> The Peripheral irq/dma requests are connected to one crossbar's input
>>> and the output of the crossbar is connected to controller's input
>>> line. On POR, there are some mappings which are done by default.
>>> Those peripherals which do not have a mapping on POR, should be configured
>>> to route its requests using the crossbar.
>>>
>>> The drivers identifies every controller's crossbar as individual devices.
>>> The mappings can be specified from the DT crossbar nodes and those gets mapped
>>> during the crossbar device's probe. The mappings can also be specified by adding
>>> the crossbar lines to the peripheral device nodes and map it with
>>> crossbar_map/unmap apis.
>>>
>>> Signed-off-by: Sricharan R <r.sricharan at ti.com>
>>> ---
>>>   .../devicetree/bindings/arm/omap/crossbar.txt      |   24 ++
>>>   drivers/misc/Kconfig                               |    8 +
>>>   drivers/misc/Makefile                              |    1 +
>>>   drivers/misc/crossbar.c                            |  258 ++++++++++++++++++++
>>>   include/linux/crossbar.h                           |   71 ++++++
>>>   5 files changed, 362 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>>   create mode 100644 drivers/misc/crossbar.c
>>>   create mode 100644 include/linux/crossbar.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> new file mode 100644
>>> index 0000000..02a8a28
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> @@ -0,0 +1,24 @@
>>> +* TI - IRQ/DMA Crossbar
>>> +
>>> +This version is an implementation of the Crossbar IRQ/DMA IP
>>> +
>>> +Required properties:
>>> +- compatible : Should be "ti,dra-crossbar"
>>> +- crossbar-name: Name of the controller to which crossbar output is routed
>>> +- reg:    Contains crossbar register address range
>>> +- reg-width: Represents the width of the individual registers
>>> +- crossbar-lines:  Default mappings.Should contain the crossbar-name
>>> +           device name, int/dma request number, crossbar number,
>>> +           register offset in the same order.
>>> +
>>> +Examples:
>>> +        crossbar_mpu: mpuirq at 4a002a48 {
>>> +            compatible = "crossbar";
>>> +            crossbar-name = "mpu-irq";
>>> +            reg = <0x4a002a48 0x0130>;
>>> +            reg-width = <16>;
>>> +            crossbar-lines = "mpu-irq", "rtc-ss-alarm", <0x9f 0xd9 0x12c>,
>>> +                     "mpu-irq", "mcasp3-arevt", <0x9e 0x96 0x12a>,
>>> +                     "mpu-irq", "mcasp3-axevt", <0x9d 0x97 0x128>;
>>> +        };
>>
>> I carry forward my TI internal objection to this approach:
>>
>> NAK.
>>
>> DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt is as follows:
>> hardware IP block -interrupt line-> IRQ Cross bar -> GIC IRQ line --> MPU IRQ.
>>
>>
>> What we have done today for DRA is to provide IRQ numbers as direct maps from hardware IP block to GIC based on default IRQ cross bar mapping.
>>
>> Lets see what happens as a result of this:
>>
>> https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
>> uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
>> uart1: serial at 4806a000 {
>> <snip>
>> +            interrupts = <0 72 0x4>;
>> Assumes that GIC interrupt by default mapping used.
>>
>> Now, think of a product that wants to use UART10 instead of UART1, SoC design allows you do that by doing a remapping of GIC interrupt to UART10 - which is awesome.
>>
>> Option 1: u-boot/bootloader
>> mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
>>
>> Option 2: in kernel do a raw_writel version of option 1.
>> This patch does option 1 in kernel in a "fancy way" - why the heck would I want to do that when u-boot allows me to do the same thing in uEnv.txt
>>
>> Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
>> a) Allows us to define every single IP available on DRA7 SoC.
>> b) GIC allocation happens dynamically
>> c) allow products use IPs as needed.
>>
>> Sorry, Conceptually option 3 is the right approach in my view.
>> instead of doing
>> uart1: serial at 4806a000 {
>> <snip>
>> +            interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
>>
>> we should be able to do the following:
>> uart1: serial at 4806a000 {
>> <snip>
>> +            interrupts = <TI_IRQ_CROSSBAR 192 IRQ_TYPE_LEVEL_HIGH>;
>>
>> and not worry about the GIC interrupt number used
>>
>>
> Since the cross-bar is not limited t0 IRQ lines and applicable for
> DMA request lines as well, making it IRQ chip doesn't make sense. Its
> not typical pin control functionality either but at least that framework
> is much closer to consider as an option.

The core concept is that this is a trivial mapping problem and if can
extrapolate pinctrl to be mapping for SoC internal signals, oh great!

pinctrl solved a problem where we are not absolutely sure how to
reallocate SoC *external* pins to board interface. pinctrl works in
more complex world, each SoC pinout has A options, but not all B SoC
signals can or will routed there - in fact, inside one single SoC
family, there never was a pattern even as it all depended on how the
board manufacturer wanted to do it - and yep, it was easy - a signal
just had limited number of options it could go to review and pinctrl
options to do that was simple as well!

The problem here IMHO is different. it is a simple X->Y mapping, where
X > Y, but any of X can be mapped to any of Y - so, now with a static
map, you need be sure that you do not map double even by mistake - so
what ever number of GIC mappings need to be evaluated always every
time we do a static map change to ensure no conflicts w.r.t board
usage etc. Doable? sure! Right way to solve a simple X->Y mapping
problem? I personally don't think so.

<rant>

Now, if we want to force every single DRA7 product board designers and
s/w board support guy to consider how the DRA internal signals are
mapped using dts - yes, we are proposing to solve the problem of a
trivial resource allocation problem with a framework meant to handle
much more complex muxing problem and ensured that all DRA7 product
guys will wonder "what the heck were these guys thinking"?

</rant>

Regards,
Nishanth Menon


From sboyd at codeaurora.org  Thu Jul 18 20:23:15 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Jul 2013 17:23:15 -0700
Subject: [PATCH v4 00/17] 64-bit friendly generic sched_clock()
In-Reply-To: <51E88170.3080505@linaro.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <51E88170.3080505@linaro.org>
Message-ID: <20130719002315.GF27430@codeaurora.org>

On 07/18, John Stultz wrote:
> On 07/18/2013 04:21 PM, Stephen Boyd wrote:
> >This patchset adds support for 64 bit counters in the generic
> >sched_clock code and converts drivers over to use it. Based
> >on v3.11-rc1.
> >
> >Changes since v3:
> >  * Move to use seqcount to fix issues with 64-bit cyc counters
> >  * Move to hrtimer to fix underflow/overflow errors in wraparound
> >    calculation
> >  * Use of 1 hour in clocks_calc_mult_shift
> >  * Converted over drivers in drivers/clocksource
> 
> I've not been able to take a deep review yet, but this looks pretty
> much like what we discussed last week, so I'm happy with it so far.
> Has this gotten much testing (on both 32 and 64bit systems?)

I've tested it on a couple 32 bit systems. I'll ask around for
some 64 bit system testing.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From hsweeten at visionengravers.com  Thu Jul 18 20:49:16 2013
From: hsweeten at visionengravers.com (H Hartley Sweeten)
Date: Thu, 18 Jul 2013 17:49:16 -0700
Subject: [PATCH] arm: ep93xx: remove memory configuration options
Message-ID: <201307181749.17093.hsweeten@visionengravers.com>

The ARM_PATCH_PHYS_VIRT option makes the ep93xx memory configuration
options obsolete.

With this option enabled the physical address is detected according
to the position of the kernel in system memory at boot. If its disabled,
the user can enter the physical address manually in the config.

Signed-off-by: H Hartley Sweeten <hsweeten at visionengravers.com>
Cc: Ryan Mallon <rmallon at gmail.com>
---
I have tested this on ep93xx systems with the SDRAM at 0xc0000000.
If anyone has a system with a different SDRAM address please respond
with a Tested-by.

 arch/arm/Kconfig                           |  1 -
 arch/arm/mach-ep93xx/Kconfig               | 54 ------------------------------
 arch/arm/mach-ep93xx/include/mach/memory.h | 22 ------------
 3 files changed, 77 deletions(-)
 delete mode 100644 arch/arm/mach-ep93xx/include/mach/memory.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..29c039c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -413,7 +413,6 @@ config ARCH_EP93XX
 	select ARM_VIC
 	select CLKDEV_LOOKUP
 	select CPU_ARM920T
-	select NEED_MACH_MEMORY_H
 	help
 	  This enables support for the Cirrus EP93xx series of CPUs.
 
diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig
index 91eee1d..a1107f4 100644
--- a/arch/arm/mach-ep93xx/Kconfig
+++ b/arch/arm/mach-ep93xx/Kconfig
@@ -15,45 +15,8 @@ config CRUNCH
 
 comment "EP93xx Platforms"
 
-choice
-	prompt "EP93xx first SDRAM bank selection"
-	default EP93XX_SDCE3_SYNC_PHYS_OFFSET
-
-config EP93XX_SDCE3_SYNC_PHYS_OFFSET
-	bool "0x00000000 - SDCE3/SyncBoot"
-	help
-	  Select this option if you want support for EP93xx boards with the
-	  first SDRAM bank at 0x00000000.
-
-config EP93XX_SDCE0_PHYS_OFFSET
-	bool "0xc0000000 - SDCEO"
-	help
-	  Select this option if you want support for EP93xx boards with the
-	  first SDRAM bank at 0xc0000000.
-
-config EP93XX_SDCE1_PHYS_OFFSET
-	bool "0xd0000000 - SDCE1"
-	help
-	  Select this option if you want support for EP93xx boards with the
-	  first SDRAM bank at 0xd0000000.
-
-config EP93XX_SDCE2_PHYS_OFFSET
-	bool "0xe0000000 - SDCE2"
-	help
-	  Select this option if you want support for EP93xx boards with the
-	  first SDRAM bank at 0xe0000000.
-
-config EP93XX_SDCE3_ASYNC_PHYS_OFFSET
-	bool "0xf0000000 - SDCE3/AsyncBoot"
-	help
-	  Select this option if you want support for EP93xx boards with the
-	  first SDRAM bank at 0xf0000000.
-
-endchoice
-
 config MACH_ADSSPHERE
 	bool "Support ADS Sphere"
-	depends on EP93XX_SDCE3_SYNC_PHYS_OFFSET
 	help
 	  Say 'Y' here if you want your kernel to support the ADS
 	  Sphere board.
@@ -63,7 +26,6 @@ config MACH_EDB93XX
 
 config MACH_EDB9301
 	bool "Support Cirrus Logic EDB9301"
-	depends on EP93XX_SDCE3_SYNC_PHYS_OFFSET
 	select MACH_EDB93XX
 	help
 	  Say 'Y' here if you want your kernel to support the Cirrus
@@ -71,7 +33,6 @@ config MACH_EDB9301
 
 config MACH_EDB9302
 	bool "Support Cirrus Logic EDB9302"
-	depends on EP93XX_SDCE3_SYNC_PHYS_OFFSET
 	select MACH_EDB93XX
 	help
 	  Say 'Y' here if you want your kernel to support the Cirrus
@@ -79,7 +40,6 @@ config MACH_EDB9302
 
 config MACH_EDB9302A
 	bool "Support Cirrus Logic EDB9302A"
-	depends on EP93XX_SDCE0_PHYS_OFFSET
 	select MACH_EDB93XX
 	help
 	  Say 'Y' here if you want your kernel to support the Cirrus
@@ -87,7 +47,6 @@ config MACH_EDB9302A
 
 config MACH_EDB9307
 	bool "Support Cirrus Logic EDB9307"
-	depends on EP93XX_SDCE3_SYNC_PHYS_OFFSET
 	select MACH_EDB93XX
 	help
 	  Say 'Y' here if you want your kernel to support the Cirrus
@@ -95,7 +54,6 @@ config MACH_EDB9307
 
 config MACH_EDB9307A
 	bool "Support Cirrus Logic EDB9307A"
-	depends on EP93XX_SDCE0_PHYS_OFFSET
 	select MACH_EDB93XX
 	help
 	  Say 'Y' here if you want your kernel to support the Cirrus
@@ -103,7 +61,6 @@ config MACH_EDB9307A
 
 config MACH_EDB9312
 	bool "Support Cirrus Logic EDB9312"
-	depends on EP93XX_SDCE3_SYNC_PHYS_OFFSET
 	select MACH_EDB93XX
 	help
 	  Say 'Y' here if you want your kernel to support the Cirrus
@@ -111,7 +68,6 @@ config MACH_EDB9312
 
 config MACH_EDB9315
 	bool "Support Cirrus Logic EDB9315"
-	depends on EP93XX_SDCE3_SYNC_PHYS_OFFSET
 	select MACH_EDB93XX
 	help
 	  Say 'Y' here if you want your kernel to support the Cirrus
@@ -119,14 +75,12 @@ config MACH_EDB9315
 
 config MACH_EDB9315A
 	bool "Support Cirrus Logic EDB9315A"
-	depends on EP93XX_SDCE0_PHYS_OFFSET
 	select MACH_EDB93XX
 	help
 	  Say 'Y' here if you want your kernel to support the Cirrus
 	  Logic EDB9315A Evaluation Board.
 
 config MACH_GESBC9312
-	depends on EP93XX_SDCE3_SYNC_PHYS_OFFSET
 	bool "Support Glomation GESBC-9312-sx"
 	help
 	  Say 'Y' here if you want your kernel to support the Glomation
@@ -137,7 +91,6 @@ config MACH_MICRO9
 
 config MACH_MICRO9H
 	bool "Support Contec Micro9-High"
-	depends on EP93XX_SDCE3_SYNC_PHYS_OFFSET
 	select MACH_MICRO9
 	help
 	  Say 'Y' here if you want your kernel to support the
@@ -145,7 +98,6 @@ config MACH_MICRO9H
 
 config MACH_MICRO9M
 	bool "Support Contec Micro9-Mid"
-	depends on EP93XX_SDCE3_ASYNC_PHYS_OFFSET
 	select MACH_MICRO9
 	help
 	  Say 'Y' here if you want your kernel to support the
@@ -153,7 +105,6 @@ config MACH_MICRO9M
 
 config MACH_MICRO9L
 	bool "Support Contec Micro9-Lite"
-	depends on EP93XX_SDCE3_SYNC_PHYS_OFFSET
 	select MACH_MICRO9
 	help
 	  Say 'Y' here if you want your kernel to support the
@@ -161,7 +112,6 @@ config MACH_MICRO9L
 
 config MACH_MICRO9S
 	bool "Support Contec Micro9-Slim"
-	depends on EP93XX_SDCE3_ASYNC_PHYS_OFFSET
 	select MACH_MICRO9
 	help
 	  Say 'Y' here if you want your kernel to support the
@@ -169,28 +119,24 @@ config MACH_MICRO9S
 
 config MACH_SIM_ONE
         bool "Support Simplemachines Sim.One board"
-        depends on EP93XX_SDCE0_PHYS_OFFSET
         help
           Say 'Y' here if you want your kernel to support the
           Simplemachines Sim.One board.
 
 config MACH_SNAPPER_CL15
 	bool "Support Bluewater Systems Snapper CL15 Module"
-	depends on EP93XX_SDCE0_PHYS_OFFSET
 	help
 	  Say 'Y' here if you want your kernel to support the Bluewater
 	  Systems Snapper CL15 Module.
 
 config MACH_TS72XX
 	bool "Support Technologic Systems TS-72xx SBC"
-	depends on EP93XX_SDCE3_SYNC_PHYS_OFFSET
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Technologic Systems TS-72xx board.
 
 config MACH_VISION_EP9307
 	bool "Support Vision Engraving Systems EP9307 SoM"
-	depends on EP93XX_SDCE0_PHYS_OFFSET
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Vision Engraving Systems EP9307 SoM.
diff --git a/arch/arm/mach-ep93xx/include/mach/memory.h b/arch/arm/mach-ep93xx/include/mach/memory.h
deleted file mode 100644
index c9400cf..0000000
--- a/arch/arm/mach-ep93xx/include/mach/memory.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/*
- * arch/arm/mach-ep93xx/include/mach/memory.h
- */
-
-#ifndef __ASM_ARCH_MEMORY_H
-#define __ASM_ARCH_MEMORY_H
-
-#if defined(CONFIG_EP93XX_SDCE3_SYNC_PHYS_OFFSET)
-#define PLAT_PHYS_OFFSET		UL(0x00000000)
-#elif defined(CONFIG_EP93XX_SDCE0_PHYS_OFFSET)
-#define PLAT_PHYS_OFFSET		UL(0xc0000000)
-#elif defined(CONFIG_EP93XX_SDCE1_PHYS_OFFSET)
-#define PLAT_PHYS_OFFSET		UL(0xd0000000)
-#elif defined(CONFIG_EP93XX_SDCE2_PHYS_OFFSET)
-#define PLAT_PHYS_OFFSET		UL(0xe0000000)
-#elif defined(CONFIG_EP93XX_SDCE3_ASYNC_PHYS_OFFSET)
-#define PLAT_PHYS_OFFSET		UL(0xf0000000)
-#else
-#error "Kconfig bug: No EP93xx PHYS_OFFSET set"
-#endif
-
-#endif
-- 
1.8.3.2



From cavokz at gmail.com  Thu Jul 18 21:36:47 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Fri, 19 Jul 2013 03:36:47 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <51E56839.8010205@hauke-m.de>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716172023.64337690@skate> <51E56839.8010205@hauke-m.de>
Message-ID: <20130719013646.GA16615@glitch>

On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote:
> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote:
> > 
> >> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig
> >> new file mode 100644
> >> index 0000000..1e16e87
> >> --- /dev/null
> >> +++ b/arch/arm/mach-bcm53xx/Kconfig
> >> @@ -0,0 +1,10 @@
> >> +config ARCH_BCM53XX
> >> +	bool "Broadcom BCM47XX / BCM53XX ARM SoC"
> > 
> > So the directory is named mach-bcm53xx, but you also handle BCM47xx
> > SoCs. This doesn't sound really easy to follow.

At the time of the BCM281XX merge we considered that such directories would
mostly contain board files only, being these new entries DT based. Hence
the choice of mach-bcm to collect all of them.

I think you should then put this stuff there.

> Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I
> do not know why there are two different names, probably marketing.
>
> Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a
> MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to
> not conflict with the MIPS part now. I know this could still cause
> problems and people will get confused, but I do not know a better name.

I'll throw also BCM476x (bcm4760 and bcm4761) on the table. These are ARM11,
single-core SoCs.

Can we agree on a nice naming so that we actually clarify this silliness?

Regards,
Domenico


From anup at brainfault.org  Thu Jul 18 21:49:59 2013
From: anup at brainfault.org (Anup Patel)
Date: Fri, 19 Jul 2013 07:19:59 +0530
Subject: [PATCH V3] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene
 host
In-Reply-To: <20130718160605.GB18520@e106331-lin.cambridge.arm.com>
References: <1374048718-9455-1-git-send-email-anup.patel@linaro.org>
 <20130718160605.GB18520@e106331-lin.cambridge.arm.com>
Message-ID: <CAAhSdy25vrO4ep_atQaS6p3LN1xzYfSBry-gjjbQT7qws0Ddsw@mail.gmail.com>

On Thu, Jul 18, 2013 at 9:36 PM, Mark Rutland <mark.rutland at arm.com> wrote:
> On Wed, Jul 17, 2013 at 09:11:58AM +0100, Anup Patel wrote:
>> This patch allows us to have X-Gene guest VCPU when using KVM arm64
>> on APM X-Gene host.
>>
>> We add KVM_ARM_TARGET_XGENE_POTENZA for X-Gene Potenza compatible
>> guest VCPU and we return KVM_ARM_TARGET_XGENE_POTENZA in kvm_target_cpu()
>> when running on X-Gene host with Potenza core.
>>
>> V3:
>>  - Reduce multiple "return -EINVAL" in kvm_target_cpu()
>>
>> V2:
>>  - Renamed KVM_ARM_TARGET_XGENE_V8 to KVM_ARM_TARGET_XGENE_POTENZA
>>
>> V1:
>>  - Initial patch with target named as KVM_ARM_TARGET_XGENE_V8
>>
>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>> ---
>>  arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
>>  arch/arm64/kvm/guest.c               |   36 ++++++++++++++++++++++------------
>>  arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
>>  3 files changed, 29 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 5031f42..d9f026b 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -55,8 +55,9 @@ struct kvm_regs {
>>  #define KVM_ARM_TARGET_AEM_V8                0
>>  #define KVM_ARM_TARGET_FOUNDATION_V8 1
>>  #define KVM_ARM_TARGET_CORTEX_A57    2
>> +#define KVM_ARM_TARGET_XGENE_POTENZA 3
>>
>> -#define KVM_ARM_NUM_TARGETS          3
>> +#define KVM_ARM_NUM_TARGETS          4
>>
>>  /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
>>  #define KVM_ARM_DEVICE_TYPE_SHIFT    0
>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>> index 2c3ff67..143d179 100644
>> --- a/arch/arm64/kvm/guest.c
>> +++ b/arch/arm64/kvm/guest.c
>> @@ -207,20 +207,32 @@ int __attribute_const__ kvm_target_cpu(void)
>>       unsigned long implementor = read_cpuid_implementor();
>>       unsigned long part_number = read_cpuid_part_number();
>>
>> -     if (implementor != ARM_CPU_IMP_ARM)
>> -             return -EINVAL;
>> -
>> -     switch (part_number) {
>> -     case ARM_CPU_PART_AEM_V8:
>> -             return KVM_ARM_TARGET_AEM_V8;
>> -     case ARM_CPU_PART_FOUNDATION:
>> -             return KVM_ARM_TARGET_FOUNDATION_V8;
>> -     case ARM_CPU_PART_CORTEX_A57:
>> -             /* Currently handled by the generic backend */
>> -             return KVM_ARM_TARGET_CORTEX_A57;
>> +     switch (implementor) {
>> +     case ARM_CPU_IMP_ARM:
>> +             switch (part_number) {
>> +             case ARM_CPU_PART_AEM_V8:
>> +                     return KVM_ARM_TARGET_AEM_V8;
>> +             case ARM_CPU_PART_FOUNDATION:
>> +                     return KVM_ARM_TARGET_FOUNDATION_V8;
>> +             case ARM_CPU_PART_CORTEX_A57:
>> +                     return KVM_ARM_TARGET_CORTEX_A57;
>> +             default:
>> +                     break;
>
> This can go, the break outside the switch will handle it.

Ok, I will update this accordingly.

>
>> +             }
>> +             break;
>> +     case ARM_CPU_IMP_APM:
>> +             switch (part_number) {
>> +             case APM_CPU_PART_POTENZA:
>> +                     return KVM_ARM_TARGET_XGENE_POTENZA;
>> +             default:
>> +                     break;
>
> This one too.

Ok.

>
>> +             }
>> +             break;
>>       default:
>> -             return -EINVAL;
>> +             break;
>
> Given we'll fall out of the switch for an unknown implementor, we don't
> need the final break.
>
> Thanks,
> Mark.
>
>>       }
>> +
>> +     return -EINVAL;
>>  }
>>
>>  int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
>> diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
>> index 4268ab9..8fe6f76 100644
>> --- a/arch/arm64/kvm/sys_regs_generic_v8.c
>> +++ b/arch/arm64/kvm/sys_regs_generic_v8.c
>> @@ -90,6 +90,9 @@ static int __init sys_reg_genericv8_init(void)
>>                                         &genericv8_target_table);
>>       kvm_register_target_sys_reg_table(KVM_ARM_TARGET_CORTEX_A57,
>>                                         &genericv8_target_table);
>> +     kvm_register_target_sys_reg_table(KVM_ARM_TARGET_XGENE_POTENZA,
>> +                                       &genericv8_target_table);
>> +
>>       return 0;
>>  }
>>  late_initcall(sys_reg_genericv8_init);
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Regards,
Anup


From ldewangan at nvidia.com  Thu Jul 18 22:13:11 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Fri, 19 Jul 2013 07:43:11 +0530
Subject: [PATCH V3 RFT] ARM: tegra: enable palmas device for dalmore
Message-ID: <1374199992-27947-1-git-send-email-ldewangan@nvidia.com>

Make the entry of Dalmore Power Management Unit device TPS65913
in dalmore DTS file. The Palma driver support this device.

Enable following submodule of the TPS65913:
- GPIO driver
- RTC driver.
- Power regulator driver.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
Changes from V1:
- renames nodes from palams_* to simple as gpio, rtc, pmic etc.
- Added line gap properly.
- Remove comment for palams-gpio reference as the entry itself explain.
- Remove unit address for tps65913.

Changes from V2:
- Made LDO9 as always ON for sd card functionality.

Hi Stephen,
I observed that if sd card is not initailised in bootloader then it will not get
enumerated in the kernel also. In my case, I am using fastboot and hence it is not
observed that sd card is getting initialised.
But today I use the uboot and on this, sd card is getting enumerated. And observer that
LDO9 is getting disabled in late init call due to full constraint and it can create
issue for sd card. With this modified patch I make the LDO9 as always ON.

I am not able to validate this througly as the kernel crash in the method of uboot. Need
more debugging.

 arch/arm/boot/dts/tegra114-dalmore.dts |  186 +++++++++++++++++++++++++++++++-
 1 files changed, 185 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index a42bfa4..d5728ff 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -791,7 +791,7 @@
 					regulator-boot-on;
 				};
 
-				dcdc3 {
+				tps65090_dcdc3_reg: dcdc3 {
 					regulator-name = "vdd-ao";
 					regulator-always-on;
 					regulator-boot-on;
@@ -836,6 +836,180 @@
 				};
 			};
 		};
+
+		palmas: tps65913 {
+			compatible = "ti,palmas";
+			reg = <0x58>;
+			interrupts = <0 86 0x4>;
+
+			#interrupt-cells = <2>;
+			interrupt-controller;
+
+			palmas_gpio: gpio {
+				compatible = "ti,palmas-gpio";
+				gpio-controller;
+				#gpio-cells = <2>;
+			};
+
+			rtc {
+				compatible = "ti,palmas-rtc";
+				interrupt-parent = <&palmas>;
+				interrupts = <8 0>;
+			};
+
+			pmic {
+			    compatible = "ti,tps65913-pmic", "ti,palmas-pmic";
+			    smps1-in-supply = <&tps65090_dcdc3_reg>;
+			    smps3-in-supply = <&tps65090_dcdc3_reg>;
+			    smps4-in-supply = <&tps65090_dcdc2_reg>;
+			    smps7-in-supply = <&tps65090_dcdc2_reg>;
+			    smps8-in-supply = <&tps65090_dcdc2_reg>;
+			    smps9-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo1-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo2-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo3-in-supply = <&palmas_smps3_reg>;
+			    ldo4-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo5-in-supply = <&vdd_ac_bat_reg>;
+			    ldo6-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo7-in-supply = <&tps65090_dcdc2_reg>;
+			    ldo8-in-supply = <&tps65090_dcdc3_reg>;
+			    ldo9-in-supply = <&palmas_smps9_reg>;
+			    ldoln-in-supply = <&tps65090_dcdc1_reg>;
+			    ldousb-in-supply = <&tps65090_dcdc1_reg>;
+
+			    regulators {
+				smps12 {
+					regulator-name = "vddio-ddr";
+					regulator-min-microvolt = <1350000>;
+					regulator-max-microvolt = <1350000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				palmas_smps3_reg: smps3 {
+					regulator-name = "vddio-1v8";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				smps45 {
+					regulator-name = "vdd-core";
+					regulator-min-microvolt = <900000>;
+					regulator-max-microvolt = <1400000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				smps457 {
+					regulator-name = "vdd-core";
+					regulator-min-microvolt = <900000>;
+					regulator-max-microvolt = <1400000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				smps8 {
+					regulator-name = "avdd-pll";
+					regulator-min-microvolt = <1050000>;
+					regulator-max-microvolt = <1050000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				palmas_smps9_reg: smps9 {
+					regulator-name = "sdhci-vdd-sd-slot";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+					regulator-always-on;
+				};
+
+				ldo1 {
+					regulator-name = "avdd-cam1";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo2 {
+					regulator-name = "avdd-cam2";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo3 {
+					regulator-name = "avdd-dsi-csi";
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				ldo4 {
+					regulator-name = "vpp-fuse";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+				};
+
+				ldo6 {
+					regulator-name = "vdd-sensor-2v85";
+					regulator-min-microvolt = <2850000>;
+					regulator-max-microvolt = <2850000>;
+				};
+
+				ldo7 {
+					regulator-name = "vdd-af-cam1";
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+				};
+
+				ldo8 {
+					regulator-name = "vdd-rtc";
+					regulator-min-microvolt = <900000>;
+					regulator-max-microvolt = <900000>;
+					regulator-always-on;
+					regulator-boot-on;
+					ti,enable-ldo8-tracking;
+				};
+
+				ldo9 {
+					regulator-name = "vddio-sdmmc-2";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <3300000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				ldoln {
+					regulator-name = "hvdd-usb";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldousb {
+					regulator-name = "avdd-usb";
+					regulator-min-microvolt = <3300000>;
+					regulator-max-microvolt = <3300000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				regen1 {
+					regulator-name = "rail-3v3";
+					regulator-max-microvolt = <3300000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+
+				regen2 {
+					regulator-name = "rail-5v0";
+					regulator-max-microvolt = <5000000>;
+					regulator-always-on;
+					regulator-boot-on;
+				};
+			    };
+			};
+		};
 	};
 
 	spi at 7000da00 {
@@ -980,6 +1154,16 @@
 			gpio = <&gpio TEGRA_GPIO(K, 1) GPIO_ACTIVE_HIGH>;
 			vin-supply = <&tps65090_dcdc1_reg>;
 		};
+
+		vdd_cam_1v8_reg: regulator at 6 {
+			compatible = "regulator-fixed";
+			reg = <6>;
+			regulator-name = "vdd_cam_1v8_reg";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			enable-active-high;
+			gpio = <&palmas_gpio 6 0>;
+		};
 	};
 
 	sound {
-- 
1.7.1.1



From cavokz at gmail.com  Thu Jul 18 22:06:11 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Fri, 19 Jul 2013 04:06:11 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <2043662.BcW19XTTMG@lenovo>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
Message-ID: <20130719020611.GA4941@glitch>

On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote:
> Hello,
> 
> Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :
> > > +	compatible = "brcm,bcm5301x";
> > 
> > Ok, this was nagging at me before I went on my very long vacation. I see
> > the "brcm" vendor prefix as a real consistency problem. I noticed on the
> > bcm281xx/kona family, we have been using "bcm" which is not logged in
> > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
> > already established use of "brcm" before any of the bcm281xx support
> > came in. Ideally, the vendor prefix should change to "bcm" since every
> > reference in the family names is BCM. However, if others want the least
> > amount of churn in making this consistent, we might have to go with
> > "brcm" across the board.
> 
> I would like to keep "brcm" here because that is what has been defined as a 
> vendor prefix, and is used beyond the scope of the ARM Linux kernel support 
> even within Broadcom. Maybe it was an oversight, or rather a mistake to let 

brcm is the stock ticker. As far as I can search, this is the convention
for the vendor prefixes.

I'm theb not that surprised that it's common within broadcom ;)

Regards,
Domenico


From cavokz at gmail.com  Thu Jul 18 22:23:14 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Fri, 19 Jul 2013 04:23:14 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
Message-ID: <20130719022314.GB4941@glitch>

Hi Hauke,

On Tue, Jul 16, 2013 at 03:52:07PM +0200, Hauke Mehrtens wrote:
> This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU.
> Currently just booting to a shell is working and nothing else, no
> Ethernet, wifi, flash, ...
> 
> This SoC uses a Dual core CPU, but this is currently not implemented.
> More information about this SoC can be found here:
> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers
> 
> Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
> ---

...

> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index e401a76..74e32f6 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -93,6 +93,10 @@ choice
>  		bool "Kernel low-level debugging on BCM2835 PL011 UART"
>  		depends on ARCH_BCM2835
>  
> +	config DEBUG_BCM53XX
> +		bool "Kernel low-level debugging on BCM53XX UART1"
> +		depends on ARCH_BCM53XX
> +
>  	config DEBUG_CLPS711X_UART1
>  		bool "Kernel low-level debugging messages via UART1"
>  		depends on ARCH_CLPS711X
> @@ -762,6 +766,7 @@ endchoice
>  config DEBUG_LL_INCLUDE
>  	string
>  	default "debug/bcm2835.S" if DEBUG_BCM2835
> +	default "debug/bcm53xx.S" if DEBUG_BCM53XX
>  	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
>  	default "debug/exynos.S" if DEBUG_EXYNOS_UART
>  	default "debug/highbank.S" if DEBUG_HIGHBANK_UART

...

> diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S
> new file mode 100644
> index 0000000..98c836b
> --- /dev/null
> +++ b/arch/arm/include/debug/bcm53xx.S
> @@ -0,0 +1,19 @@
> +/*
> + * Macros used for EARLY_PRINTK, in low-level UART debug console
> + *
> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> + *
> + * Licensed under the GNU/GPL. See COPYING for details.
> + */
> +
> +#define BCM53XX_UART1_PHYS	0x18000300
> +#define BCM53XX_UART1_VIRT	0xf1000300
> +#define BCM53XX_UART1_SH	0
> +
> +	.macro	addruart, rp, rv, tmp
> +	ldr	\rp, =BCM53XX_UART1_PHYS 	@ MMU off, Physical
> +	ldr	\rv, =BCM53XX_UART1_VIRT 	@ MMU on, Virtual
> +	.endm
> +
> +#define UART_SHIFT	BCM53XX_UART1_SH
> +#include <asm/hardware/debug-8250.S>

don't know if it's worth to add this debug uart support here. there is a
series from Russel to consolidate 8250 and pl01x debug uarts. maybe you
want to delay this.

> diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c
> new file mode 100644
> index 0000000..aa5bd397
> --- /dev/null
> +++ b/arch/arm/mach-bcm53xx/bcm53xx.c
> @@ -0,0 +1,68 @@
> +/*
> + * Broadcom BCM47XX / BCM53XX ARM platform code.
> + *
> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> + *
> + * Licensed under the GNU/GPL. See COPYING for details.
> + */
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/irqchip.h>
> +#include <linux/clocksource.h>
> +#include <linux/clk-provider.h>
> +
> +#include <asm/mach/arch.h>
> +#include <asm/mach/map.h>
> +#include <asm/signal.h>
> +
> +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
> +				 struct pt_regs *regs)
> +{
> +	/*
> +	 * These happen for no good reason
> +	 * possibly left over from CFE
> +	 */
> +	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
> +		addr, fsr);
> +
> +	/* Returning non-zero causes fault display and panic */
> +	return 0;
> +}
> +
> +static void bcm53xx_aborts_enable(void)
> +{
> +	/* Install our hook */
> +	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
> +			"imprecise external abort");
> +}
> +
> +static void __init bcm53xx_timer_init(void)
> +{
> +	of_clk_init(NULL);
> +	clocksource_of_init();
> +}
> +
> +void __init bcm53xx_map_io(void)
> +{
> +	debug_ll_io_init();
> +	bcm53xx_aborts_enable();
> +}
> +
> +static void __init bcm53xx_dt_init(void)
> +{
> +	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +}
> +
> +static const char const *bcm53xx_dt_compat[] = {
> +	"brcm,bcm5301x",
> +	"netgear,r6250v1",
> +	NULL,
> +};
> +
> +DT_MACHINE_START(BCM53XX, "BCM53XX")
> +	.init_machine = bcm53xx_dt_init,
> +	.map_io = bcm53xx_map_io,
> +	.init_irq = irqchip_init,
> +	.init_time = bcm53xx_timer_init,
> +	.dt_compat = bcm53xx_dt_compat,
> +MACHINE_END

the trend is to consolidate machine descriptors.

so .init_irq can go, irqchip_init is picked anyway if .init_irq is NULL.

also .init_time could be dropped, it can be specified using
CLOCKSOURCE_OF_DECLARE(), but I see bcm53xx_timer_init is already quite
minimal here and I'm struggling to see the big picture here. So mine is
actually a question for others... :)

Regards,
Domenico


From horms at verge.net.au  Thu Jul 18 22:28:22 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 11:28:22 +0900
Subject: [PATCH v2 00/04] ARM: shmobile: ARCH_MULTIPLATFORM for EMEV2 and
 KZM9D
In-Reply-To: <20130717203049.27542.78385.sendpatchset@w520>
References: <20130717203049.27542.78385.sendpatchset@w520>
Message-ID: <20130719022821.GF4403@verge.net.au>

On Thu, Jul 18, 2013 at 05:30:49AM +0900, Magnus Damm wrote:
> ARM: shmobile: ARCH_MULTIPLATFORM for EMEV2 and KZM9D (v2)
> 
> [PATCH v2 01/04] ARM: shmobile: Only build clocks when COMMON_CLK=n
> [PATCH 02/04] ARM: shmobile: Introduce ARCH_SHMOBILE_MULTI
> [PATCH v2 03/04] ARM: shmobile: Add EMEV2 and KZM9D to ARCH_SHMOBILE_MULTI
> [PATCH 04/04] ARM: shmobile: Allow ARCH_SHMOBILE_MULTI timer configuration
> 
> This patch set extends mach-shmobile to allow a subset of SoCs and
> boards to be built for ARCH_MULTIPLATFORM. With this v2 series applied
> the EMEV2 SoC and the KZM9D board can be built in two ways - either
> as good old ARCH_SHMOBILE or new ARCH_SHMOBILE_MULTI. The latter
> requires common clock framework for proper run time operation.
> 
> The goal is to over time move all DT reference implementations from
> ARCH_SHMOBILE to ARCH_SHMOBILE_MULTI. Until CCF is available for a
> certain SoC it is to me acceptable for a DT reference board to allow
> build in both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI. The reason for
> this is to allow incremental development and easy testing during
> development of CCF for a certain SoC. The KZM9D board is now in this
> state while it is waiting for common clocks to become ready.
> 
> Until CCF is supported for EMEV2 the KZM9D board can be tested with
> ARCH_SMOBILE_MULTI without clocks using the following prototype:
> [PATCH] ARM: shmobile: MULTIPLATFORM KZM9D with no clocks prototype hack
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  Built on top of renesas-devel-20130717

Hi Magnus,

could you let me know if/when these are ready for me to queue-up?

Thanks


From horms at verge.net.au  Thu Jul 18 22:29:04 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 11:29:04 +0900
Subject: [PATCH] ARM: shmobile: r8a7790 SMP prototype v5
In-Reply-To: <51E7379A.1080408@renesas.com>
References: <20130717204918.30125.40588.sendpatchset@w520>
 <51E7379A.1080408@renesas.com>
Message-ID: <20130719022904.GG4403@verge.net.au>

On Thu, Jul 18, 2013 at 09:32:26AM +0900, Shinya Kuribayashi wrote:
> On 7/18/2013 5:49 AM, Magnus Damm wrote:
> >  Changes since v4:
> >  - Rolled in the following patches from Kuribayashi-san, thanks!
> >    ARM: shmobile: smp-r8a7790: remove the obsolete RESCNT register
> >    ARM: shmobile: smp-r8a7790: rename s/carescnt/rescnt/g
> >    ARM: shmobile: smp-r8a7790: rename s/cabar/bar/g as well
> >    ARM: shmobile: smp-r8a7790: power up a CPU core at .smp_boot_secondary stage
> > 
> >  Written against kernel.org renesas git tag renesas-devel-20130717
> 
> Thanks for the update, looks good to me.

Thanks.

This seems like it is ready to queue-up.
Magnus, are there any outstanding reviews or issues?


From voice.shen at atmel.com  Thu Jul 18 22:39:43 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Fri, 19 Jul 2013 10:39:43 +0800
Subject: [PATCH] ASoC: atmel: add wm8904 based audio machine driver
In-Reply-To: <20130718111709.GL22506@sirena.org.uk>
References: <1374132483-25375-1-git-send-email-voice.shen@atmel.com>
 <20130718111709.GL22506@sirena.org.uk>
Message-ID: <51E8A6EF.4040608@atmel.com>

Hi Mark,

On 07/18/2013 07:17 PM, Mark Brown wrote:
> On Thu, Jul 18, 2013 at 03:28:03PM +0800, Bo Shen wrote:
>> add wm8904 based audio machine driver
>>
>> the following ek board based on it
>>    - at91sam9n12ek
>>    - sama5d3xek (d31, d33, d34, d35)
>>
>> Signed-off-by: Bo Shen <voice.shen at atmel.com>
>
> Looks pretty good, a few fairly small issues below.
>
> The binding document should be CCed to devicetree-discuss for review.

OK, I will cc the devicetree-discuss next version.

>> +	atmel,audio-routing =
>> +		"Headphone Jack", "HPOUTL",
>> +		"Headphone Jack", "HPOUTR",
>> +		"IN2L", "Line In Jack",
>> +		"IN2R", "Line In Jack",
>> +		"Mic", "MICBIAS",
>> +		"IN1L", "Mic";
>
> The widgets defined by the board should be documented in this binding.
> Those from the CODEC should be documented in the CODEC binding.

OK, I will separate this and put need information in this binding document.

>> +#define MCLK_RATE 32768
>> +
>> +static struct clk *mclk;
>
> This should be in driver data for the board.  Shouldn't the clock be
> referenced using the clock bindings?

I will try to implement this in next version.

>> +static int atmel_asoc_wm8904_init(struct snd_soc_pcm_runtime *rtd)
>> +{
>> +	struct snd_soc_dai *codec_dai = rtd->codec_dai;
>> +	int ret;
>> +
>> +	ret = snd_soc_dai_set_sysclk(codec_dai, WM8904_CLK_FLL,
>> +			12000000, SND_SOC_CLOCK_IN);
>> +	if (ret < 0) {
>> +		pr_err("%s -failed to set wm8904 SYSCLK\n", __func__);
>> +		return ret;
>> +	}
>
> This is an odd thing to set the clock rate to and limits the sample
> rates the board can play back.  It would be better to set the clock rate
> based on the requested sample rate in hw_params - you're using the FLL
> so may as well take advantage of the ability it offers to support all
> sample rates.
>> +static int atmel_asoc_wm8904_params(struct snd_pcm_substream *substream,
>> +		struct snd_pcm_hw_params *params)
>> +{
>> +	struct snd_soc_pcm_runtime *rtd = substream->private_data;
>> +	struct snd_soc_dai *codec_dai = rtd->codec_dai;
>> +	int ret;
>> +
>> +	ret = snd_soc_dai_set_pll(codec_dai, WM8904_FLL_MCLK, WM8904_FLL_MCLK,
>> +		32768, params_rate(params) * 256);
>
> Ah, in fact you do actually do that - it'd be clearer to put the
> set_sysclk() after this.

OK, I will put set_sysclk here.

>> +	switch (level) {
>> +	case SND_SOC_BIAS_ON:
>> +	case SND_SOC_BIAS_PREPARE:
>> +		if (!mclk_on) {
>> +			ret = clk_prepare_enable(mclk);
>> +			if (ret == 0)
>> +				mclk_on = 1;
>> +		}
>> +		break;
>> +	case SND_SOC_BIAS_STANDBY:
>> +	case SND_SOC_BIAS_OFF:
>> +		if (mclk_on)
>> +			clk_disable_unprepare(mclk);
>> +		mclk_on = 0;
>> +		break;
>> +	}
>
> It's better to write this using the previous state than to have the
> mclk_on flag - you want to enable on the standby->prepare transition and
> disable on the standby->off transition.

OK, I will implement it in next version.

>> +static int atmel_asoc_wm8904_dt_init(struct platform_device *pdev)
>> +{
>> +	struct device_node *np = pdev->dev.of_node;
>> +	struct device_node *codec_np, *cpu_np;
>> +	struct snd_soc_card *card = &atmel_asoc_wm8904_card;
>> +	struct snd_soc_dai_link *dailink = &atmel_asoc_wm8904_dailink;
>> +	int ret;
>> +
>> +	if (!np)
>> +		return -1;
>
> Return a real error code here.

Sure.

Thanks,

Best Reards,
Bo Shen




From shawn.guo at linaro.org  Thu Jul 18 23:23:30 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri, 19 Jul 2013 11:23:30 +0800
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <CAOesGMgi0j_mPyeBLVHb_QW+DwtAPoFY697eQO3-yp9tnP1vmA@mail.gmail.com>
References: <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <20130716041056.GA30067@S2101-09.ap.freescale.net>
 <51E56AA7.7020103@wwwdotorg.org>
 <20130717030246.GA4541@S2101-09.ap.freescale.net>
 <51E6CCE4.20705@wwwdotorg.org>
 <20130717213836.GA13324@amd.pavel.ucw.cz>
 <51E719A6.6070105@wwwdotorg.org>
 <20130718112555.GB1021@amd.pavel.ucw.cz>
 <CAOesGMgi0j_mPyeBLVHb_QW+DwtAPoFY697eQO3-yp9tnP1vmA@mail.gmail.com>
Message-ID: <20130719032328.GB20889@S2101-09.ap.freescale.net>

On Thu, Jul 18, 2013 at 11:45:29AM -0700, Olof Johansson wrote:
> Hi,
> 
> On Thu, Jul 18, 2013 at 4:25 AM, Pavel Machek <pavel at denx.de> wrote:
> 
> > It sound to me like keeping ammount of -EPROBE_DEFER to minimum is
> > still preferred.
> 
> Hand-crafting initcall level ordering of various drivers and subsystem
> is probably an even greater evil though. We've done it in the past,
> but now that we have deferred probe we have the option of not having
> to do it every time, such as this.
> 
> You're spending an awful lot of energy arguing over this, but nobody
> has actually shown data of how much deferral is happening -- and that
> it's a real problem. Until someone does so there's no reason to change
> it from the default module init level at all, I'd say.

On imx6qdl-sabreauto board, there are 3 MAX7310 units as IO expanders to
output 3 x 8 = 24 GPIOs.  18 of them are used for resets, enables and
pin steering for various peripherals on the board.

  BACKLITE_ON
  SAT_SHUTDN_B
  CPU_PER_RST_B
  MAIN_PER_RST_B
  IPOD_RST_B
  MLB_RST_B
  SSI_STEERING
  GPS_RST_B
  
  GPS_PWREN
  VIDEO_ADC_PWRDN_B
  ENET_CAN1_STEER
  EIMD30_BTUART3_STEER
  CAN_STBY
  CAN_EN
  USB_H1_PWR
  
  USB_OTG_PWR_ON
  SAT_RST_B
  NAND_BT_WIFI_STEER

Most of these GPIOs need to set up properly at client device driver's
probe stage - module_init() time.  So if we have all these service
providers resets/enables/steering API registered at module_init() too,
the probes of all these client device drivers stand a good chance to be
deferred.

Shawn



From B18965 at freescale.com  Thu Jul 18 23:49:02 2013
From: B18965 at freescale.com (Wang Huan-B18965)
Date: Fri, 19 Jul 2013 03:49:02 +0000
Subject: [PATCH v2 0/5] ARM: vf610: Add DCU framebuffer driver for
 Vybrid VF610 platform
In-Reply-To: <1373609276-14566-1-git-send-email-b18965@freescale.com>
References: <1373609276-14566-1-git-send-email-b18965@freescale.com>
Message-ID: <81BA6E5E0BC2344391CABCEE22D1B6D83AA3AE@039-SN1MPN1-004.039d.mgd.msft.net>

Hi, Jean-Christophe,

      Could you please help to review these patches? 

      Thanks a lot!


Best Regards,
Alison Wang

> -----Original Message-----
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> bounces at lists.infradead.org] On Behalf Of Alison Wang
> Sent: Friday, July 12, 2013 2:08 PM
> To: plagnioj at jcrosoft.com; tomi.valkeinen at ti.com; shawn.guo at linaro.org;
> Estevam Fabio-R49496; linux-fbdev at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Cc: Jin Zhengxiong-R64188
> Subject: [PATCH v2 0/5] ARM: vf610: Add DCU framebuffer driver for
> Vybrid VF610 platform
> 
> This series contain DCU framebuffer driver for Freescale Vybrid VF610
> platform.
> 
> The Display Controller Unit (DCU) module is a system master that
> fetches graphics stored in internal or external memory and displays
> them on a TFT LCD panel. A wide range of panel sizes is supported and
> the timing of the interface signals is highly configurable.
> Graphics are read directly from memory and then blended in real-time,
> which allows for dynamic content creation with minimal CPU intervention.
> 
> The features:
> 
> (1) Full RGB888 output to TFT LCD panel.
> (2) For the current LCD panel, WQVGA "480x272" is tested.
> (3) Blending of each pixel using up to 4 source layers dependent on
> size of panel.
> (4) Each graphic layer can be placed with one pixel resolution in
> either axis.
> (5) Each graphic layer support RGB565 and RGB888 direct colors without
> alpha channel and BGRA8888 direct colors with an alpha channel.
> (6) Each graphic layer support alpha blending with 8-bit resolution.
> 
> Changes in v2:
> - Add a document for DCU framebuffer driver under
> Documentation/devicetree/bindings/fb/.
> 
> ----------------------------------------------------------------
> Alison Wang (5):
>       ARM: dts: vf610: Add DCU and TCON nodes
>       ARM: dts: vf610-twr: Enable DCU and TCON devices
>       ARM: clk: vf610: Add DCU and TCON clock support
>       fb: Add DCU framebuffer driver for Vybrid VF610 platform
>       Documentation: DT: Add DCU framebuffer driver
> 
>  Documentation/devicetree/bindings/fb/fsl-dcu-fb.txt |   36 ++++
>  arch/arm/boot/dts/vf610-twr.dts                     |   10 +
>  arch/arm/boot/dts/vf610.dtsi                        |   19 +-
>  arch/arm/mach-imx/clk-vf610.c                       |    5 +
>  drivers/video/Kconfig                               |    9 +
>  drivers/video/Makefile                              |    1 +
>  drivers/video/fsl-dcu-fb.c                          | 1091
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +++++++++++++++++++++++++
>  include/dt-bindings/clock/vf610-clock.h             |    3 +-
>  8 files changed, 1172 insertions(+), 2 deletions(-)  create mode
> 100644 Documentation/devicetree/bindings/fb/fsl-dcu-fb.txt
>  create mode 100644 drivers/video/fsl-dcu-fb.c
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel




From tom.leiming at gmail.com  Thu Jul 18 23:50:04 2013
From: tom.leiming at gmail.com (Ming Lei)
Date: Fri, 19 Jul 2013 11:50:04 +0800
Subject: [PATCH] [RFC] EHCI: add to memory barrier to updating hw_next
In-Reply-To: <Pine.LNX.4.44L0.1307181004190.1245-100000@iolanthe.rowland.org>
References: <CACVXFVNV-hGZpcy2ANQaca1K5yXJ88EOq1PTkJUEHEkFk9Btvw@mail.gmail.com>
 <Pine.LNX.4.44L0.1307181004190.1245-100000@iolanthe.rowland.org>
Message-ID: <CACVXFVNXAJe363O2OFHJ927BT23hCzedbG1Yt41xbDxV_d_oOg@mail.gmail.com>

On Thu, Jul 18, 2013 at 10:08 PM, Alan Stern <stern at rowland.harvard.edu> wrote:
> On Thu, 18 Jul 2013, Ming Lei wrote:
>
>> > I guess that HC could have a use-after-free problem like following situation.
>> >
>> > 1. A qtd which is not at the queue head should be removed in qh_completions().
>> > 2. The last->hw_next become be pointing at the next qtd but the hw_next value is delayed in write-buffer.
>> > 3. The qtd is removed in the list.
>> > 4. The qtd is freed into DMA pool and re-allocated for another urb.
>> > 5. HC try to process last->hw_next and it is pointing re-allocated qtd.
>> >
>> > What do you think about it? Is it possible?
>>
>> I understand it might not be possible because:  when 'stopped' is set, that
>> said the HC might not advance the queue. But I don't understand why
>> 'last->hw_next' is patched here under 'stopped' situation.
>
> It should not be possible.  When "stopped" is set, the QH gets unlinked
> and relinked before it can start up again.  Relinking involves some
> memory barriers, so the qTD will not be accessed again by the HC.
>
> last->hw_next gets patched because the qTD might belong to some URB in
> the middle of the queue that is being unlinked.  The URBs before it and
> after it will still be active, so the queue link has to be updated.

'stopped' is set under below situations:

     - unlink over or shutdown
     - halt
     - short packet(URB_SHORT_NOT_OK)

Looks EHCI won't advance the queue(qh) any more on above situations, so I
think last->hw_next might not need patching.

>
>> Even the 'stopped' case may be seldom triggered, do you know under
>> which condition the stopped is triggered in your problem?(stall, short read
>> or others)
>
> I was going to ask the same question.  This particular piece of code
> gets executed _only_ when an URB is unlinked.  Not during any other
> kind of error.

The code may run under 'halt' or short packet(URB_SHORT_NOT_OK) too.
If Gioh's problem falls to these two situations, below patch might be helpful.

Because the qh will be unlinked when there is fault in the endpoint(halt, short
packet), maybe it is safer to complete these URBs after the qh becomes
unlinked,  like what the blew patch does:

diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index b637a65..6a65e0a 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -454,6 +454,10 @@ qh_completions (struct ehci_hcd *ehci, struct ehci_qh *qh)
 			}
 		}

+		/* complete URBs after unlinking */
+		if (stopped && state != QH_STATE_IDLE)
+			goto exit;
+
 		/* unless we already know the urb's status, collect qtd status
 		 * and update count of bytes transferred.  in common short read
 		 * cases with only one data qtd (including control transfers),
@@ -489,15 +493,6 @@ qh_completions (struct ehci_hcd *ehci, struct ehci_qh *qh)
 			}
 		}

-		/* if we're removing something not at the queue head,
-		 * patch the hardware queue pointer.
-		 */
-		if (stopped && qtd->qtd_list.prev != &qh->qtd_list) {
-			last = list_entry (qtd->qtd_list.prev,
-					struct ehci_qtd, qtd_list);
-			last->hw_next = qtd->hw_next;
-		}
-
 		/* remove qtd; it's recycled after possible urb completion */
 		list_del (&qtd->qtd_list);
 		last = qtd;
@@ -520,7 +515,7 @@ qh_completions (struct ehci_hcd *ehci, struct ehci_qh *qh)

 		/* Otherwise the caller must unlink the QH. */
 	}
-
+ exit:
 	/* restore original state; caller must unlink or relink */
 	qh->qh_state = state;



Thanks,
-- 
Ming Lei


From horms+renesas at verge.net.au  Fri Jul 19 00:34:48 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:34:48 +0900
Subject: [GIT 0/7] Renesas ARM and SH based SoC backlight drivers for v3.12
Message-ID: <cover.1374207161.git.horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

please consider the following backlight drivers for v3.12.

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-backlight-for-v3.12

for you to fetch changes up to 0fb19cdabfc3f8884bac53fd81b02bf61c7904af:

  ARM: mach-shmobile: ag5evm: Use bd6107 backlight driver (2013-07-17 10:06:18 +0900)

----------------------------------------------------------------
Renesas ARM and SH based SoC backlight drivers for v3.12

Backlight drivers used by SH and ARM SH-Mobile boards.

----------------------------------------------------------------
Laurent Pinchart (7):
      backlight: Add GPIO-based backlight driver
      backlight: Add Sanyo LV5207LP backlight driver
      backlight: Add ROHM BD6107 backlight driver
      ARM: mach-shmobile: mackerel: Use gpio-backlight
      sh: ecovec24: Use gpio-backlight
      sh: kfr2r09: Use lv5207lp backlight
      ARM: mach-shmobile: ag5evm: Use bd6107 backlight driver

 arch/arm/mach-shmobile/board-ag5evm.c        |   65 ++------
 arch/arm/mach-shmobile/board-mackerel.c      |   34 ++--
 arch/sh/boards/mach-ecovec24/setup.c         |   37 +++--
 arch/sh/boards/mach-kfr2r09/lcd_wqvga.c      |   48 ------
 arch/sh/boards/mach-kfr2r09/setup.c          |   19 ++-
 arch/sh/include/mach-kfr2r09/mach/kfr2r09.h  |    2 -
 drivers/video/backlight/Kconfig              |   19 +++
 drivers/video/backlight/Makefile             |    3 +
 drivers/video/backlight/bd6107.c             |  213 ++++++++++++++++++++++++++
 drivers/video/backlight/gpio_backlight.c     |  133 ++++++++++++++++
 drivers/video/backlight/lv5207lp.c           |  171 +++++++++++++++++++++
 include/linux/platform_data/bd6107.h         |   19 +++
 include/linux/platform_data/gpio_backlight.h |   21 +++
 include/linux/platform_data/lv5207lp.h       |   19 +++
 14 files changed, 665 insertions(+), 138 deletions(-)
 create mode 100644 drivers/video/backlight/bd6107.c
 create mode 100644 drivers/video/backlight/gpio_backlight.c
 create mode 100644 drivers/video/backlight/lv5207lp.c
 create mode 100644 include/linux/platform_data/bd6107.h
 create mode 100644 include/linux/platform_data/gpio_backlight.h
 create mode 100644 include/linux/platform_data/lv5207lp.h


From horms+renesas at verge.net.au  Fri Jul 19 00:35:29 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:35:29 +0900
Subject: [PATCH 4/7] ARM: mach-shmobile: mackerel: Use gpio-backlight
In-Reply-To: <cover.1374207161.git.horms+renesas@verge.net.au>
References: <cover.1374207161.git.horms+renesas@verge.net.au>
Message-ID: <14bd03e08831a52035e601ae85b05a4849214ec4.1374207161.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Replace the backlight callback with a gpio-backlight platform device.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-mackerel.c |   34 +++++++++++++++----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index 85f51a8..af06753 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -41,6 +41,7 @@
 #include <linux/mtd/physmap.h>
 #include <linux/mtd/sh_flctl.h>
 #include <linux/pinctrl/machine.h>
+#include <linux/platform_data/gpio_backlight.h>
 #include <linux/pm_clock.h>
 #include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
@@ -49,7 +50,6 @@
 #include <linux/tca6416_keypad.h>
 #include <linux/usb/renesas_usbhs.h>
 #include <linux/dma-mapping.h>
-
 #include <video/sh_mobile_hdmi.h>
 #include <video/sh_mobile_lcdc.h>
 #include <media/sh_mobile_ceu.h>
@@ -346,7 +346,7 @@ static struct platform_device meram_device = {
 	},
 };
 
-/* LCDC */
+/* LCDC and backlight */
 static struct fb_videomode mackerel_lcdc_modes[] = {
 	{
 		.name		= "WVGA Panel",
@@ -362,13 +362,6 @@ static struct fb_videomode mackerel_lcdc_modes[] = {
 	},
 };
 
-static int mackerel_set_brightness(int brightness)
-{
-	gpio_set_value(31, brightness);
-
-	return 0;
-}
-
 static const struct sh_mobile_meram_cfg lcd_meram_cfg = {
 	.icb[0] = {
 		.meram_size     = 0x40,
@@ -393,11 +386,6 @@ static struct sh_mobile_lcdc_info lcdc_info = {
 			.width		= 152,
 			.height		= 91,
 		},
-		.bl_info = {
-			.name = "sh_mobile_lcdc_bl",
-			.max_brightness = 1,
-			.set_brightness = mackerel_set_brightness,
-		},
 		.meram_cfg = &lcd_meram_cfg,
 	}
 };
@@ -425,6 +413,20 @@ static struct platform_device lcdc_device = {
 	},
 };
 
+static struct gpio_backlight_platform_data gpio_backlight_data = {
+	.fbdev = &lcdc_device.dev,
+	.gpio = 31,
+	.def_value = 1,
+	.name = "backlight",
+};
+
+static struct platform_device gpio_backlight_device = {
+	.name = "gpio-backlight",
+	.dev = {
+		.platform_data = &gpio_backlight_data,
+	},
+};
+
 /* HDMI */
 static struct sh_mobile_hdmi_info hdmi_info = {
 	.flags		= HDMI_SND_SRC_SPDIF,
@@ -1231,6 +1233,7 @@ static struct platform_device *mackerel_devices[] __initdata = {
 	&nor_flash_device,
 	&smc911x_device,
 	&lcdc_device,
+	&gpio_backlight_device,
 	&usbhs0_device,
 	&usbhs1_device,
 	&leds_device,
@@ -1441,9 +1444,6 @@ static void __init mackerel_init(void)
 				  ARRAY_SIZE(mackerel_pinctrl_map));
 	sh7372_pinmux_init();
 
-	/* backlight, off by default */
-	gpio_request_one(31, GPIOF_OUT_INIT_LOW, NULL);
-
 	gpio_request_one(151, GPIOF_OUT_INIT_HIGH, NULL); /* LCDDON */
 
 	/* USBHS0 */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:35:30 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:35:30 +0900
Subject: [PATCH 5/7] sh: ecovec24: Use gpio-backlight
In-Reply-To: <cover.1374207161.git.horms+renesas@verge.net.au>
References: <cover.1374207161.git.horms+renesas@verge.net.au>
Message-ID: <fe79f919f47eabf6eae08414dcc078b0d89dfd8e.1374207161.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Replace the backlight callback with a gpio-backlight platform device.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/sh/boards/mach-ecovec24/setup.c |   37 ++++++++++++++++++----------------
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-ecovec24/setup.c
index 61fade0..bcbb86b 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -30,6 +30,7 @@
 #include <linux/spi/mmc_spi.h>
 #include <linux/input.h>
 #include <linux/input/sh_keysc.h>
+#include <linux/platform_data/gpio_backlight.h>
 #include <linux/sh_eth.h>
 #include <linux/sh_intc.h>
 #include <linux/videodev2.h>
@@ -303,7 +304,7 @@ static struct platform_device usbhs_device = {
 	.resource	= usbhs_resources,
 };
 
-/* LCDC */
+/* LCDC and backlight */
 static const struct fb_videomode ecovec_lcd_modes[] = {
 	{
 		.name		= "Panel",
@@ -334,13 +335,6 @@ static const struct fb_videomode ecovec_dvi_modes[] = {
 	},
 };
 
-static int ecovec24_set_brightness(int brightness)
-{
-	gpio_set_value(GPIO_PTR1, brightness);
-
-	return 0;
-}
-
 static struct sh_mobile_lcdc_info lcdc_info = {
 	.ch[0] = {
 		.interface_type = RGB18,
@@ -350,11 +344,6 @@ static struct sh_mobile_lcdc_info lcdc_info = {
 			.width = 152,
 			.height = 91,
 		},
-		.bl_info = {
-			.name = "sh_mobile_lcdc_bl",
-			.max_brightness = 1,
-			.set_brightness = ecovec24_set_brightness,
-		},
 	}
 };
 
@@ -380,6 +369,20 @@ static struct platform_device lcdc_device = {
 	},
 };
 
+static struct gpio_backlight_platform_data gpio_backlight_data = {
+	.fbdev = &lcdc_device.dev,
+	.gpio = GPIO_PTR1,
+	.def_value = 1,
+	.name = "backlight",
+};
+
+static struct platform_device gpio_backlight_device = {
+	.name = "gpio-backlight",
+	.dev = {
+		.platform_data = &gpio_backlight_data,
+	},
+};
+
 /* CEU0 */
 static struct sh_mobile_ceu_info sh_mobile_ceu0_info = {
 	.flags = SH_CEU_FLAG_USE_8BIT_BUS,
@@ -1049,6 +1052,7 @@ static struct platform_device *ecovec_devices[] __initdata = {
 	&usb1_common_device,
 	&usbhs_device,
 	&lcdc_device,
+	&gpio_backlight_device,
 	&ceu0_device,
 	&ceu1_device,
 	&keysc_device,
@@ -1239,11 +1243,9 @@ static int __init arch_setup(void)
 
 	gpio_request(GPIO_PTE6, NULL);
 	gpio_request(GPIO_PTU1, NULL);
-	gpio_request(GPIO_PTR1, NULL);
 	gpio_request(GPIO_PTA2, NULL);
 	gpio_direction_input(GPIO_PTE6);
 	gpio_direction_output(GPIO_PTU1, 0);
-	gpio_direction_output(GPIO_PTR1, 0);
 	gpio_direction_output(GPIO_PTA2, 0);
 
 	/* I/O buffer drive ability is high */
@@ -1256,6 +1258,9 @@ static int __init arch_setup(void)
 		lcdc_info.ch[0].lcd_modes		= ecovec_dvi_modes;
 		lcdc_info.ch[0].num_modes		= ARRAY_SIZE(ecovec_dvi_modes);
 
+		/* No backlight */
+		gpio_backlight_data.fbdev = NULL;
+
 		gpio_set_value(GPIO_PTA2, 1);
 		gpio_set_value(GPIO_PTU1, 1);
 	} else {
@@ -1265,8 +1270,6 @@ static int __init arch_setup(void)
 		lcdc_info.ch[0].lcd_modes		= ecovec_lcd_modes;
 		lcdc_info.ch[0].num_modes		= ARRAY_SIZE(ecovec_lcd_modes);
 
-		gpio_set_value(GPIO_PTR1, 1);
-
 		/* FIXME
 		 *
 		 * LCDDON control is needed for Panel,
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:35:26 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:35:26 +0900
Subject: [PATCH 1/7] backlight: Add GPIO-based backlight driver
In-Reply-To: <cover.1374207161.git.horms+renesas@verge.net.au>
References: <cover.1374207161.git.horms+renesas@verge.net.au>
Message-ID: <8b770e3c9824c98eafe67950ad6e41e09ec9c98a.1374207161.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The GPIO backlight driver controls the backlight in on/off mode through
a single GPIO.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Jingoo Han <jg1.han at samsung.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/video/backlight/Kconfig              |    7 ++
 drivers/video/backlight/Makefile             |    1 +
 drivers/video/backlight/gpio_backlight.c     |  133 ++++++++++++++++++++++++++
 include/linux/platform_data/gpio_backlight.h |   21 ++++
 4 files changed, 162 insertions(+)
 create mode 100644 drivers/video/backlight/gpio_backlight.c
 create mode 100644 include/linux/platform_data/gpio_backlight.h

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index d5ab658..5ab6423 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -425,6 +425,13 @@ config BACKLIGHT_AS3711
 	  If you have an Austrian Microsystems AS3711 say Y to enable the
 	  backlight driver.
 
+config BACKLIGHT_GPIO
+	tristate "Generic GPIO based Backlight Driver"
+	depends on GPIOLIB
+	help
+	  If you have a LCD backlight adjustable by GPIO, say Y to enable
+	  this driver.
+
 endif # BACKLIGHT_CLASS_DEVICE
 
 endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 92711fe..65698a8 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_BACKLIGHT_DA903X)		+= da903x_bl.o
 obj-$(CONFIG_BACKLIGHT_DA9052)		+= da9052_bl.o
 obj-$(CONFIG_BACKLIGHT_EP93XX)		+= ep93xx_bl.o
 obj-$(CONFIG_BACKLIGHT_GENERIC)		+= generic_bl.o
+obj-$(CONFIG_BACKLIGHT_GPIO)		+= gpio_backlight.o
 obj-$(CONFIG_BACKLIGHT_HP680)		+= hp680_bl.o
 obj-$(CONFIG_BACKLIGHT_HP700)		+= jornada720_bl.o
 obj-$(CONFIG_BACKLIGHT_LM3533)		+= lm3533_bl.o
diff --git a/drivers/video/backlight/gpio_backlight.c b/drivers/video/backlight/gpio_backlight.c
new file mode 100644
index 0000000..5fa217f
--- /dev/null
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -0,0 +1,133 @@
+/*
+ * gpio_backlight.c - Simple GPIO-controlled backlight
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/backlight.h>
+#include <linux/err.h>
+#include <linux/fb.h>
+#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_data/gpio_backlight.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+struct gpio_backlight {
+	struct device *dev;
+	struct device *fbdev;
+
+	int gpio;
+	int active;
+};
+
+static int gpio_backlight_update_status(struct backlight_device *bl)
+{
+	struct gpio_backlight *gbl = bl_get_data(bl);
+	int brightness = bl->props.brightness;
+
+	if (bl->props.power != FB_BLANK_UNBLANK ||
+	    bl->props.fb_blank != FB_BLANK_UNBLANK ||
+	    bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
+		brightness = 0;
+
+	gpio_set_value(gbl->gpio, brightness ? gbl->active : !gbl->active);
+
+	return 0;
+}
+
+static int gpio_backlight_get_brightness(struct backlight_device *bl)
+{
+	return bl->props.brightness;
+}
+
+static int gpio_backlight_check_fb(struct backlight_device *bl,
+				   struct fb_info *info)
+{
+	struct gpio_backlight *gbl = bl_get_data(bl);
+
+	return gbl->fbdev == NULL || gbl->fbdev == info->dev;
+}
+
+static const struct backlight_ops gpio_backlight_ops = {
+	.options	= BL_CORE_SUSPENDRESUME,
+	.update_status	= gpio_backlight_update_status,
+	.get_brightness	= gpio_backlight_get_brightness,
+	.check_fb	= gpio_backlight_check_fb,
+};
+
+static int gpio_backlight_probe(struct platform_device *pdev)
+{
+	struct gpio_backlight_platform_data *pdata = pdev->dev.platform_data;
+	struct backlight_properties props;
+	struct backlight_device *bl;
+	struct gpio_backlight *gbl;
+	int ret;
+
+	if (!pdata) {
+		dev_err(&pdev->dev, "failed to find platform data\n");
+		return -ENODEV;
+	}
+
+	gbl = devm_kzalloc(&pdev->dev, sizeof(*gbl), GFP_KERNEL);
+	if (gbl == NULL)
+		return -ENOMEM;
+
+	gbl->dev = &pdev->dev;
+	gbl->fbdev = pdata->fbdev;
+	gbl->gpio = pdata->gpio;
+	gbl->active = pdata->active_low ? 0 : 1;
+
+	ret = devm_gpio_request_one(gbl->dev, gbl->gpio, GPIOF_DIR_OUT |
+				    (gbl->active ? GPIOF_INIT_LOW
+						 : GPIOF_INIT_HIGH),
+				    pdata->name);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "unable to request GPIO\n");
+		return ret;
+	}
+
+	memset(&props, 0, sizeof(props));
+	props.type = BACKLIGHT_RAW;
+	props.max_brightness = 1;
+	bl = backlight_device_register(dev_name(&pdev->dev), &pdev->dev, gbl,
+				       &gpio_backlight_ops, &props);
+	if (IS_ERR(bl)) {
+		dev_err(&pdev->dev, "failed to register backlight\n");
+		return PTR_ERR(bl);
+	}
+
+	bl->props.brightness = pdata->def_value;
+	backlight_update_status(bl);
+
+	platform_set_drvdata(pdev, bl);
+	return 0;
+}
+
+static int gpio_backlight_remove(struct platform_device *pdev)
+{
+	struct backlight_device *bl = platform_get_drvdata(pdev);
+
+	backlight_device_unregister(bl);
+	return 0;
+}
+
+static struct platform_driver gpio_backlight_driver = {
+	.driver		= {
+		.name		= "gpio-backlight",
+		.owner		= THIS_MODULE,
+	},
+	.probe		= gpio_backlight_probe,
+	.remove		= gpio_backlight_remove,
+};
+
+module_platform_driver(gpio_backlight_driver);
+
+MODULE_AUTHOR("Laurent Pinchart <laurent.pinchart at ideasonboard.com>");
+MODULE_DESCRIPTION("GPIO-based Backlight Driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:gpio-backlight");
diff --git a/include/linux/platform_data/gpio_backlight.h b/include/linux/platform_data/gpio_backlight.h
new file mode 100644
index 0000000..5ae0d9c
--- /dev/null
+++ b/include/linux/platform_data/gpio_backlight.h
@@ -0,0 +1,21 @@
+/*
+ * gpio_backlight.h - Simple GPIO-controlled backlight
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __GPIO_BACKLIGHT_H__
+#define __GPIO_BACKLIGHT_H__
+
+struct device;
+
+struct gpio_backlight_platform_data {
+	struct device *fbdev;
+	int gpio;
+	int def_value;
+	bool active_low;
+	const char *name;
+};
+
+#endif
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:35:27 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:35:27 +0900
Subject: [PATCH 2/7] backlight: Add Sanyo LV5207LP backlight driver
In-Reply-To: <cover.1374207161.git.horms+renesas@verge.net.au>
References: <cover.1374207161.git.horms+renesas@verge.net.au>
Message-ID: <82e5c40d88f928afffe7bd4027719d3184433908.1374207161.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The LV5207LP is a multi-purpose 7 LEDs driver for the mobile market.
Only the main LED is supported by this driver.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Jingoo Han <jg1.han at samsung.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/video/backlight/Kconfig        |    6 ++
 drivers/video/backlight/Makefile       |    1 +
 drivers/video/backlight/lv5207lp.c     |  171 ++++++++++++++++++++++++++++++++
 include/linux/platform_data/lv5207lp.h |   19 ++++
 4 files changed, 197 insertions(+)
 create mode 100644 drivers/video/backlight/lv5207lp.c
 create mode 100644 include/linux/platform_data/lv5207lp.h

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 5ab6423..b304e07 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -432,6 +432,12 @@ config BACKLIGHT_GPIO
 	  If you have a LCD backlight adjustable by GPIO, say Y to enable
 	  this driver.
 
+config BACKLIGHT_LV5207LP
+	tristate "Sanyo LV5207LP Backlight"
+	depends on I2C
+	help
+	  If you have a Sanyo LV5207LP say Y to enable the backlight driver.
+
 endif # BACKLIGHT_CLASS_DEVICE
 
 endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 65698a8..4e5e811 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_BACKLIGHT_LM3639)		+= lm3639_bl.o
 obj-$(CONFIG_BACKLIGHT_LOCOMO)		+= locomolcd.o
 obj-$(CONFIG_BACKLIGHT_LP855X)		+= lp855x_bl.o
 obj-$(CONFIG_BACKLIGHT_LP8788)		+= lp8788_bl.o
+obj-$(CONFIG_BACKLIGHT_LV5207LP)	+= lv5207lp.o
 obj-$(CONFIG_BACKLIGHT_MAX8925)		+= max8925_bl.o
 obj-$(CONFIG_BACKLIGHT_OMAP1)		+= omap1_bl.o
 obj-$(CONFIG_BACKLIGHT_OT200)		+= ot200_bl.o
diff --git a/drivers/video/backlight/lv5207lp.c b/drivers/video/backlight/lv5207lp.c
new file mode 100644
index 0000000..498fd73
--- /dev/null
+++ b/drivers/video/backlight/lv5207lp.c
@@ -0,0 +1,171 @@
+/*
+ * Sanyo LV5207LP LED Driver
+ *
+ * Copyright (C) 2013 Ideas on board SPRL
+ *
+ * Contact: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/backlight.h>
+#include <linux/err.h>
+#include <linux/fb.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/platform_data/lv5207lp.h>
+#include <linux/slab.h>
+
+#define LV5207LP_CTRL1			0x00
+#define LV5207LP_CPSW			(1 << 7)
+#define LV5207LP_SCTEN			(1 << 6)
+#define LV5207LP_C10			(1 << 5)
+#define LV5207LP_CKSW			(1 << 4)
+#define LV5207LP_RSW			(1 << 3)
+#define LV5207LP_GSW			(1 << 2)
+#define LV5207LP_BSW			(1 << 1)
+#define LV5207LP_CTRL2			0x01
+#define LV5207LP_MSW			(1 << 7)
+#define LV5207LP_MLED4			(1 << 6)
+#define LV5207LP_RED			0x02
+#define LV5207LP_GREEN			0x03
+#define LV5207LP_BLUE			0x04
+
+#define LV5207LP_MAX_BRIGHTNESS		32
+
+struct lv5207lp {
+	struct i2c_client *client;
+	struct backlight_device *backlight;
+	struct lv5207lp_platform_data *pdata;
+};
+
+static int lv5207lp_write(struct lv5207lp *lv, u8 reg, u8 data)
+{
+	return i2c_smbus_write_byte_data(lv->client, reg, data);
+}
+
+static int lv5207lp_backlight_update_status(struct backlight_device *backlight)
+{
+	struct lv5207lp *lv = bl_get_data(backlight);
+	int brightness = backlight->props.brightness;
+
+	if (backlight->props.power != FB_BLANK_UNBLANK ||
+	    backlight->props.fb_blank != FB_BLANK_UNBLANK ||
+	    backlight->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
+		brightness = 0;
+
+	if (brightness) {
+		lv5207lp_write(lv, LV5207LP_CTRL1,
+			       LV5207LP_CPSW | LV5207LP_C10 | LV5207LP_CKSW);
+		lv5207lp_write(lv, LV5207LP_CTRL2,
+			       LV5207LP_MSW | LV5207LP_MLED4 |
+			       (brightness - 1));
+	} else {
+		lv5207lp_write(lv, LV5207LP_CTRL1, 0);
+		lv5207lp_write(lv, LV5207LP_CTRL2, 0);
+	}
+
+	return 0;
+}
+
+static int lv5207lp_backlight_get_brightness(struct backlight_device *backlight)
+{
+	return backlight->props.brightness;
+}
+
+static int lv5207lp_backlight_check_fb(struct backlight_device *backlight,
+				       struct fb_info *info)
+{
+	struct lv5207lp *lv = bl_get_data(backlight);
+
+	return lv->pdata->fbdev == NULL || lv->pdata->fbdev == info->dev;
+}
+
+static const struct backlight_ops lv5207lp_backlight_ops = {
+	.options	= BL_CORE_SUSPENDRESUME,
+	.update_status	= lv5207lp_backlight_update_status,
+	.get_brightness	= lv5207lp_backlight_get_brightness,
+	.check_fb	= lv5207lp_backlight_check_fb,
+};
+
+static int lv5207lp_probe(struct i2c_client *client,
+			  const struct i2c_device_id *id)
+{
+	struct lv5207lp_platform_data *pdata = client->dev.platform_data;
+	struct backlight_device *backlight;
+	struct backlight_properties props;
+	struct lv5207lp *lv;
+
+	if (pdata == NULL) {
+		dev_err(&client->dev, "No platform data supplied\n");
+		return -EINVAL;
+	}
+
+	if (!i2c_check_functionality(client->adapter,
+				     I2C_FUNC_SMBUS_BYTE_DATA)) {
+		dev_warn(&client->dev,
+			 "I2C adapter doesn't support I2C_FUNC_SMBUS_BYTE\n");
+		return -EIO;
+	}
+
+	lv = devm_kzalloc(&client->dev, sizeof(*lv), GFP_KERNEL);
+	if (!lv)
+		return -ENOMEM;
+
+	lv->client = client;
+	lv->pdata = pdata;
+
+	memset(&props, 0, sizeof(props));
+	props.type = BACKLIGHT_RAW;
+	props.max_brightness = min_t(unsigned int, pdata->max_value,
+				     LV5207LP_MAX_BRIGHTNESS);
+	props.brightness = clamp_t(unsigned int, pdata->def_value, 0,
+				   props.max_brightness);
+
+	backlight = backlight_device_register(dev_name(&client->dev),
+					      &lv->client->dev, lv,
+					      &lv5207lp_backlight_ops, &props);
+	if (IS_ERR(backlight)) {
+		dev_err(&client->dev, "failed to register backlight\n");
+		return PTR_ERR(backlight);
+	}
+
+	backlight_update_status(backlight);
+	i2c_set_clientdata(client, backlight);
+
+	return 0;
+}
+
+static int lv5207lp_remove(struct i2c_client *client)
+{
+	struct backlight_device *backlight = i2c_get_clientdata(client);
+
+	backlight->props.brightness = 0;
+	backlight_update_status(backlight);
+	backlight_device_unregister(backlight);
+
+	return 0;
+}
+
+static const struct i2c_device_id lv5207lp_ids[] = {
+	{ "lv5207lp", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, lv5207lp_ids);
+
+static struct i2c_driver lv5207lp_driver = {
+	.driver = {
+		.name = "lv5207lp",
+	},
+	.probe = lv5207lp_probe,
+	.remove = lv5207lp_remove,
+	.id_table = lv5207lp_ids,
+};
+
+module_i2c_driver(lv5207lp_driver);
+
+MODULE_DESCRIPTION("Sanyo LV5207LP Backlight Driver");
+MODULE_AUTHOR("Laurent Pinchart <laurent.pinchart at ideasonboard.com>");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/platform_data/lv5207lp.h b/include/linux/platform_data/lv5207lp.h
new file mode 100644
index 0000000..7dc4d9a
--- /dev/null
+++ b/include/linux/platform_data/lv5207lp.h
@@ -0,0 +1,19 @@
+/*
+ * lv5207lp.h - Sanyo LV5207LP LEDs Driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LV5207LP_H__
+#define __LV5207LP_H__
+
+struct device;
+
+struct lv5207lp_platform_data {
+	struct device *fbdev;
+	unsigned int max_value;
+	unsigned int def_value;
+};
+
+#endif
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:35:28 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:35:28 +0900
Subject: [PATCH 3/7] backlight: Add ROHM BD6107 backlight driver
In-Reply-To: <cover.1374207161.git.horms+renesas@verge.net.au>
References: <cover.1374207161.git.horms+renesas@verge.net.au>
Message-ID: <67b43e590415866649e5ba8a6421bb84ecb74f72.1374207161.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The BD6107 is a multi-purpose 10 channels LED driver for the mobile
market. Only the main channel is supported by this driver.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Jingoo Han <jg1.han at samsung.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/video/backlight/Kconfig      |    6 +
 drivers/video/backlight/Makefile     |    1 +
 drivers/video/backlight/bd6107.c     |  213 ++++++++++++++++++++++++++++++++++
 include/linux/platform_data/bd6107.h |   19 +++
 4 files changed, 239 insertions(+)
 create mode 100644 drivers/video/backlight/bd6107.c
 create mode 100644 include/linux/platform_data/bd6107.h

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index b304e07..d4a7a35 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -438,6 +438,12 @@ config BACKLIGHT_LV5207LP
 	help
 	  If you have a Sanyo LV5207LP say Y to enable the backlight driver.
 
+config BACKLIGHT_BD6107
+	tristate "Rohm BD6107 Backlight"
+	depends on I2C
+	help
+	  If you have a Rohm BD6107 say Y to enable the backlight driver.
+
 endif # BACKLIGHT_CLASS_DEVICE
 
 endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 4e5e811..38e1bab 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_BACKLIGHT_ADP8870)		+= adp8870_bl.o
 obj-$(CONFIG_BACKLIGHT_APPLE)		+= apple_bl.o
 obj-$(CONFIG_BACKLIGHT_AS3711)		+= as3711_bl.o
 obj-$(CONFIG_BACKLIGHT_ATMEL_PWM)	+= atmel-pwm-bl.o
+obj-$(CONFIG_BACKLIGHT_BD6107)		+= bd6107.o
 obj-$(CONFIG_BACKLIGHT_CARILLO_RANCH)	+= cr_bllcd.o
 obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE)	+= backlight.o
 obj-$(CONFIG_BACKLIGHT_DA903X)		+= da903x_bl.o
diff --git a/drivers/video/backlight/bd6107.c b/drivers/video/backlight/bd6107.c
new file mode 100644
index 0000000..15e3294
--- /dev/null
+++ b/drivers/video/backlight/bd6107.c
@@ -0,0 +1,213 @@
+/*
+ * ROHM Semiconductor BD6107 LED Driver
+ *
+ * Copyright (C) 2013 Ideas on board SPRL
+ *
+ * Contact: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/backlight.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/fb.h>
+#include <linux/gpio.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/platform_data/bd6107.h>
+#include <linux/slab.h>
+
+#define BD6107_PSCNT1				0x00
+#define BD6107_PSCNT1_PSCNTREG2			(1 << 2)
+#define BD6107_PSCNT1_PSCNTREG1			(1 << 0)
+#define BD6107_REGVSET				0x02
+#define BD6107_REGVSET_REG1VSET_2_85V		(1 << 2)
+#define BD6107_REGVSET_REG1VSET_2_80V		(0 << 2)
+#define BD6107_LEDCNT1				0x03
+#define BD6107_LEDCNT1_LEDONOFF2		(1 << 1)
+#define BD6107_LEDCNT1_LEDONOFF1		(1 << 0)
+#define BD6107_PORTSEL				0x04
+#define BD6107_PORTSEL_LEDM(n)			(1 << (n))
+#define BD6107_RGB1CNT1				0x05
+#define BD6107_RGB1CNT2				0x06
+#define BD6107_RGB1CNT3				0x07
+#define BD6107_RGB1CNT4				0x08
+#define BD6107_RGB1CNT5				0x09
+#define BD6107_RGB1FLM				0x0a
+#define BD6107_RGB2CNT1				0x0b
+#define BD6107_RGB2CNT2				0x0c
+#define BD6107_RGB2CNT3				0x0d
+#define BD6107_RGB2CNT4				0x0e
+#define BD6107_RGB2CNT5				0x0f
+#define BD6107_RGB2FLM				0x10
+#define BD6107_PSCONT3				0x11
+#define BD6107_SMMONCNT				0x12
+#define BD6107_DCDCCNT				0x13
+#define BD6107_IOSEL				0x14
+#define BD6107_OUT1				0x15
+#define BD6107_OUT2				0x16
+#define BD6107_MASK1				0x17
+#define BD6107_MASK2				0x18
+#define BD6107_FACTOR1				0x19
+#define BD6107_FACTOR2				0x1a
+#define BD6107_CLRFACT1				0x1b
+#define BD6107_CLRFACT2				0x1c
+#define BD6107_STATE1				0x1d
+#define BD6107_LSIVER				0x1e
+#define BD6107_GRPSEL				0x1f
+#define BD6107_LEDCNT2				0x20
+#define BD6107_LEDCNT3				0x21
+#define BD6107_MCURRENT				0x22
+#define BD6107_MAINCNT1				0x23
+#define BD6107_MAINCNT2				0x24
+#define BD6107_SLOPECNT				0x25
+#define BD6107_MSLOPE				0x26
+#define BD6107_RGBSLOPE				0x27
+#define BD6107_TEST				0x29
+#define BD6107_SFTRST				0x2a
+#define BD6107_SFTRSTGD				0x2b
+
+struct bd6107 {
+	struct i2c_client *client;
+	struct backlight_device *backlight;
+	struct bd6107_platform_data *pdata;
+};
+
+static int bd6107_write(struct bd6107 *bd, u8 reg, u8 data)
+{
+	return i2c_smbus_write_byte_data(bd->client, reg, data);
+}
+
+static int bd6107_backlight_update_status(struct backlight_device *backlight)
+{
+	struct bd6107 *bd = bl_get_data(backlight);
+	int brightness = backlight->props.brightness;
+
+	if (backlight->props.power != FB_BLANK_UNBLANK ||
+	    backlight->props.fb_blank != FB_BLANK_UNBLANK ||
+	    backlight->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
+		brightness = 0;
+
+	if (brightness) {
+		bd6107_write(bd, BD6107_PORTSEL, BD6107_PORTSEL_LEDM(2) |
+			     BD6107_PORTSEL_LEDM(1) | BD6107_PORTSEL_LEDM(0));
+		bd6107_write(bd, BD6107_MAINCNT1, brightness);
+		bd6107_write(bd, BD6107_LEDCNT1, BD6107_LEDCNT1_LEDONOFF1);
+	} else {
+		gpio_set_value(bd->pdata->reset, 0);
+		msleep(24);
+		gpio_set_value(bd->pdata->reset, 1);
+	}
+
+	return 0;
+}
+
+static int bd6107_backlight_get_brightness(struct backlight_device *backlight)
+{
+	return backlight->props.brightness;
+}
+
+static int bd6107_backlight_check_fb(struct backlight_device *backlight,
+				       struct fb_info *info)
+{
+	struct bd6107 *bd = bl_get_data(backlight);
+
+	return bd->pdata->fbdev == NULL || bd->pdata->fbdev == info->dev;
+}
+
+static const struct backlight_ops bd6107_backlight_ops = {
+	.options	= BL_CORE_SUSPENDRESUME,
+	.update_status	= bd6107_backlight_update_status,
+	.get_brightness	= bd6107_backlight_get_brightness,
+	.check_fb	= bd6107_backlight_check_fb,
+};
+
+static int bd6107_probe(struct i2c_client *client,
+			  const struct i2c_device_id *id)
+{
+	struct bd6107_platform_data *pdata = client->dev.platform_data;
+	struct backlight_device *backlight;
+	struct backlight_properties props;
+	struct bd6107 *bd;
+	int ret;
+
+	if (pdata == NULL || !pdata->reset) {
+		dev_err(&client->dev, "No reset GPIO in platform data\n");
+		return -EINVAL;
+	}
+
+	if (!i2c_check_functionality(client->adapter,
+				     I2C_FUNC_SMBUS_BYTE_DATA)) {
+		dev_warn(&client->dev,
+			 "I2C adapter doesn't support I2C_FUNC_SMBUS_BYTE\n");
+		return -EIO;
+	}
+
+	bd = devm_kzalloc(&client->dev, sizeof(*bd), GFP_KERNEL);
+	if (!bd)
+		return -ENOMEM;
+
+	bd->client = client;
+	bd->pdata = pdata;
+
+	ret = devm_gpio_request_one(&client->dev, pdata->reset,
+				    GPIOF_DIR_OUT | GPIOF_INIT_LOW, "reset");
+	if (ret < 0) {
+		dev_err(&client->dev, "unable to request reset GPIO\n");
+		return ret;
+	}
+
+	memset(&props, 0, sizeof(props));
+	props.type = BACKLIGHT_RAW;
+	props.max_brightness = 128;
+	props.brightness = clamp_t(unsigned int, pdata->def_value, 0,
+				   props.max_brightness);
+
+	backlight = backlight_device_register(dev_name(&client->dev),
+					      &bd->client->dev, bd,
+					      &bd6107_backlight_ops, &props);
+	if (IS_ERR(backlight)) {
+		dev_err(&client->dev, "failed to register backlight\n");
+		return PTR_ERR(backlight);
+	}
+
+	backlight_update_status(backlight);
+	i2c_set_clientdata(client, backlight);
+
+	return 0;
+}
+
+static int bd6107_remove(struct i2c_client *client)
+{
+	struct backlight_device *backlight = i2c_get_clientdata(client);
+
+	backlight->props.brightness = 0;
+	backlight_update_status(backlight);
+	backlight_device_unregister(backlight);
+
+	return 0;
+}
+
+static const struct i2c_device_id bd6107_ids[] = {
+	{ "bd6107", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, bd6107_ids);
+
+static struct i2c_driver bd6107_driver = {
+	.driver = {
+		.name = "bd6107",
+	},
+	.probe = bd6107_probe,
+	.remove = bd6107_remove,
+	.id_table = bd6107_ids,
+};
+
+module_i2c_driver(bd6107_driver);
+
+MODULE_DESCRIPTION("Rohm BD6107 Backlight Driver");
+MODULE_AUTHOR("Laurent Pinchart <laurent.pinchart at ideasonboard.com>");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/platform_data/bd6107.h b/include/linux/platform_data/bd6107.h
new file mode 100644
index 0000000..671d650
--- /dev/null
+++ b/include/linux/platform_data/bd6107.h
@@ -0,0 +1,19 @@
+/*
+ * bd6107.h - Rohm BD6107 LEDs Driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __BD6107_H__
+#define __BD6107_H__
+
+struct device;
+
+struct bd6107_platform_data {
+	struct device *fbdev;
+	int reset;			/* Reset GPIO */
+	unsigned int def_value;
+};
+
+#endif
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:35:53 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:35:53 +0900
Subject: [GIT] Renesas ARM based clocksource updates for v3.12
Message-ID: <cover.1374207810.git.horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

please consider the following clocksource updates for v3.12.

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-clocksource-for-v3.12

for you to fetch changes up to 2792cc6f22031110f6959c02d42d7b6116105a71:

  clocksource: sh_cmt: 32-bit control register support (2013-07-16 10:42:23 +0900)

----------------------------------------------------------------
Renesas ARM based clocksource updates for v3.12

Add support for CMT hardware with 32-bit control and counter registers.

----------------------------------------------------------------
Magnus Damm (1):
      clocksource: sh_cmt: 32-bit control register support

 drivers/clocksource/sh_cmt.c |   50 ++++++++++++++++++++++++++++++------------
 1 file changed, 36 insertions(+), 14 deletions(-)


From horms+renesas at verge.net.au  Fri Jul 19 00:35:32 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:35:32 +0900
Subject: [PATCH 7/7] ARM: mach-shmobile: ag5evm: Use bd6107 backlight driver
In-Reply-To: <cover.1374207161.git.horms+renesas@verge.net.au>
References: <cover.1374207161.git.horms+renesas@verge.net.au>
Message-ID: <0fb19cdabfc3f8884bac53fd81b02bf61c7904af.1374207161.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Replace the backlight callback with a bd6107 backlight platform device.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-ag5evm.c |   65 ++++++++-------------------------
 1 file changed, 16 insertions(+), 49 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-ag5evm.c b/arch/arm/mach-shmobile/board-ag5evm.c
index c754071..f6d6449 100644
--- a/arch/arm/mach-shmobile/board-ag5evm.c
+++ b/arch/arm/mach-shmobile/board-ag5evm.c
@@ -41,6 +41,7 @@
 #include <linux/mmc/sh_mmcif.h>
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/mfd/tmio.h>
+#include <linux/platform_data/bd6107.h>
 #include <linux/sh_clk.h>
 #include <linux/irqchip/arm-gic.h>
 #include <video/sh_mobile_lcdc.h>
@@ -291,47 +292,7 @@ static struct platform_device mipidsi0_device = {
 	},
 };
 
-static unsigned char lcd_backlight_seq[3][2] = {
-	{ 0x04, 0x07 },
-	{ 0x23, 0x80 },
-	{ 0x03, 0x01 },
-};
-
-static int lcd_backlight_set_brightness(int brightness)
-{
-	struct i2c_adapter *adap;
-	struct i2c_msg msg;
-	unsigned int i;
-	int ret;
-
-	if (brightness == 0) {
-		/* Reset the chip */
-		gpio_set_value(235, 0);
-		mdelay(24);
-		gpio_set_value(235, 1);
-		return 0;
-	}
-
-	adap = i2c_get_adapter(1);
-	if (adap == NULL)
-		return -ENODEV;
-
-	for (i = 0; i < ARRAY_SIZE(lcd_backlight_seq); i++) {
-		msg.addr = 0x6d;
-		msg.buf = &lcd_backlight_seq[i][0];
-		msg.len = 2;
-		msg.flags = 0;
-
-		ret = i2c_transfer(adap, &msg, 1);
-		if (ret < 0)
-			break;
-	}
-
-	i2c_put_adapter(adap);
-	return ret < 0 ? ret : 0;
-}
-
-/* LCDC0 */
+/* LCDC0 and backlight */
 static const struct fb_videomode lcdc0_modes[] = {
 	{
 		.name		= "R63302(QHD)",
@@ -361,11 +322,6 @@ static struct sh_mobile_lcdc_info lcdc0_info = {
 			.width = 44,
 			.height = 79,
 		},
-		.bl_info = {
-			.name = "sh_mobile_lcdc_bl",
-			.max_brightness = 1,
-			.set_brightness = lcd_backlight_set_brightness,
-		},
 		.tx_dev = &mipidsi0_device,
 	}
 };
@@ -394,6 +350,17 @@ static struct platform_device lcdc0_device = {
 	},
 };
 
+static struct bd6107_platform_data backlight_data = {
+	.fbdev = &lcdc0_device.dev,
+	.reset = 235,
+	.def_value = 0,
+};
+
+static struct i2c_board_info backlight_board_info = {
+	I2C_BOARD_INFO("bd6107", 0x6d),
+	.platform_data = &backlight_data,
+};
+
 /* Fixed 2.8V regulators to be used by SDHI0 */
 static struct regulator_consumer_supply fixed2v8_power_consumers[] =
 {
@@ -648,15 +615,15 @@ static void __init ag5evm_init(void)
 	gpio_set_value(217, 1);
 	mdelay(100);
 
-	/* LCD backlight controller */
-	gpio_request_one(235, GPIOF_OUT_INIT_LOW, NULL); /* RESET */
-	lcd_backlight_set_brightness(0);
 
 #ifdef CONFIG_CACHE_L2X0
 	/* Shared attribute override enable, 64K*8way */
 	l2x0_init(IOMEM(0xf0100000), 0x00460000, 0xc2000fff);
 #endif
 	sh73a0_add_standard_devices();
+
+	i2c_register_board_info(1, &backlight_board_info, 1);
+
 	platform_add_devices(ag5evm_devices, ARRAY_SIZE(ag5evm_devices));
 }
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:35:31 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:35:31 +0900
Subject: [PATCH 6/7] sh: kfr2r09: Use lv5207lp backlight
In-Reply-To: <cover.1374207161.git.horms+renesas@verge.net.au>
References: <cover.1374207161.git.horms+renesas@verge.net.au>
Message-ID: <3f3bee2e31f6fbf8ac09b58b8e87374d24387cef.1374207161.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Replace the backlight callback with a lv5207lp backlight platform
device.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/sh/boards/mach-kfr2r09/lcd_wqvga.c     |   48 ---------------------------
 arch/sh/boards/mach-kfr2r09/setup.c         |   19 ++++++++---
 arch/sh/include/mach-kfr2r09/mach/kfr2r09.h |    2 --
 3 files changed, 14 insertions(+), 55 deletions(-)

diff --git a/arch/sh/boards/mach-kfr2r09/lcd_wqvga.c b/arch/sh/boards/mach-kfr2r09/lcd_wqvga.c
index c620503..355a78a 100644
--- a/arch/sh/boards/mach-kfr2r09/lcd_wqvga.c
+++ b/arch/sh/boards/mach-kfr2r09/lcd_wqvga.c
@@ -276,51 +276,3 @@ void kfr2r09_lcd_start(void *sohandle, struct sh_mobile_lcdc_sys_bus_ops *so)
 {
 	write_memory_start(sohandle, so);
 }
-
-#define CTRL_CKSW       0x10
-#define CTRL_C10        0x20
-#define CTRL_CPSW       0x80
-#define MAIN_MLED4      0x40
-#define MAIN_MSW        0x80
-
-int kfr2r09_lcd_set_brightness(int brightness)
-{
-	struct i2c_adapter *a;
-	struct i2c_msg msg;
-	unsigned char buf[2];
-	int ret;
-
-	a = i2c_get_adapter(0);
-	if (!a)
-		return -ENODEV;
-
-	buf[0] = 0x00;
-	if (brightness)
-		buf[1] = CTRL_CPSW | CTRL_C10 | CTRL_CKSW;
-	else
-		buf[1] = 0;
-
-	msg.addr = 0x75;
-	msg.buf = buf;
-	msg.len = 2;
-	msg.flags = 0;
-	ret = i2c_transfer(a, &msg, 1);
-	if (ret != 1)
-		return -ENODEV;
-
-	buf[0] = 0x01;
-	if (brightness)
-		buf[1] = MAIN_MSW | MAIN_MLED4 | 0x0c;
-	else
-		buf[1] = 0;
-
-	msg.addr = 0x75;
-	msg.buf = buf;
-	msg.len = 2;
-	msg.flags = 0;
-	ret = i2c_transfer(a, &msg, 1);
-	if (ret != 1)
-		return -ENODEV;
-
-	return 0;
-}
diff --git a/arch/sh/boards/mach-kfr2r09/setup.c b/arch/sh/boards/mach-kfr2r09/setup.c
index ab502f12..1df4398 100644
--- a/arch/sh/boards/mach-kfr2r09/setup.c
+++ b/arch/sh/boards/mach-kfr2r09/setup.c
@@ -21,6 +21,7 @@
 #include <linux/input.h>
 #include <linux/input/sh_keysc.h>
 #include <linux/i2c.h>
+#include <linux/platform_data/lv5207lp.h>
 #include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
 #include <linux/usb/r8a66597.h>
@@ -159,11 +160,6 @@ static struct sh_mobile_lcdc_info kfr2r09_sh_lcdc_info = {
 			.setup_sys = kfr2r09_lcd_setup,
 			.start_transfer = kfr2r09_lcd_start,
 		},
-		.bl_info = {
-			.name = "sh_mobile_lcdc_bl",
-			.max_brightness = 1,
-			.set_brightness = kfr2r09_lcd_set_brightness,
-		},
 		.sys_bus_cfg = {
 			.ldmt2r = 0x07010904,
 			.ldmt3r = 0x14012914,
@@ -195,6 +191,17 @@ static struct platform_device kfr2r09_sh_lcdc_device = {
 	},
 };
 
+static struct lv5207lp_platform_data kfr2r09_backlight_data = {
+	.fbdev = &kfr2r09_sh_lcdc_device.dev,
+	.def_value = 13,
+	.max_value = 13,
+};
+
+static struct i2c_board_info kfr2r09_backlight_board_info = {
+	I2C_BOARD_INFO("lv5207lp", 0x75),
+	.platform_data = &kfr2r09_backlight_data,
+};
+
 static struct r8a66597_platdata kfr2r09_usb0_gadget_data = {
 	.on_chip = 1,
 };
@@ -627,6 +634,8 @@ static int __init kfr2r09_devices_setup(void)
 	gpio_request(GPIO_FN_SDHI0CMD, NULL);
 	gpio_request(GPIO_FN_SDHI0CLK, NULL);
 
+	i2c_register_board_info(0, &kfr2r09_backlight_board_info, 1);
+
 	return platform_add_devices(kfr2r09_devices,
 				    ARRAY_SIZE(kfr2r09_devices));
 }
diff --git a/arch/sh/include/mach-kfr2r09/mach/kfr2r09.h b/arch/sh/include/mach-kfr2r09/mach/kfr2r09.h
index c20c9e5..79f154e 100644
--- a/arch/sh/include/mach-kfr2r09/mach/kfr2r09.h
+++ b/arch/sh/include/mach-kfr2r09/mach/kfr2r09.h
@@ -4,13 +4,11 @@
 #include <video/sh_mobile_lcdc.h>
 
 #if defined(CONFIG_FB_SH_MOBILE_LCDC) || defined(CONFIG_FB_SH_MOBILE_LCDC_MODULE)
-int kfr2r09_lcd_set_brightness(int brightness);
 int kfr2r09_lcd_setup(void *sys_ops_handle,
 		      struct sh_mobile_lcdc_sys_bus_ops *sys_ops);
 void kfr2r09_lcd_start(void *sys_ops_handle,
 		       struct sh_mobile_lcdc_sys_bus_ops *sys_ops);
 #else
-static int kfr2r09_lcd_set_brightness(int brightness) {}
 static int kfr2r09_lcd_setup(void *sys_ops_handle,
 				struct sh_mobile_lcdc_sys_bus_ops *sys_ops)
 {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:36:07 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:36:07 +0900
Subject: [PATCH] clocksource: sh_cmt: 32-bit control register support
In-Reply-To: <cover.1374207810.git.horms+renesas@verge.net.au>
References: <cover.1374207810.git.horms+renesas@verge.net.au>
Message-ID: <2792cc6f22031110f6959c02d42d7b6116105a71.1374207810.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add support for CMT hardware with 32-bit control and counter
registers, as found on r8a73a4 and r8a7790. To use the CMT
with 32-bit hardware a second I/O memory resource needs to
point out the CMSTR register and it needs to be 32 bit wide.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/clocksource/sh_cmt.c |   50 ++++++++++++++++++++++++++++++------------
 1 file changed, 36 insertions(+), 14 deletions(-)

diff --git a/drivers/clocksource/sh_cmt.c b/drivers/clocksource/sh_cmt.c
index 08d0c41..0965e98 100644
--- a/drivers/clocksource/sh_cmt.c
+++ b/drivers/clocksource/sh_cmt.c
@@ -37,6 +37,7 @@
 
 struct sh_cmt_priv {
 	void __iomem *mapbase;
+	void __iomem *mapbase_str;
 	struct clk *clk;
 	unsigned long width; /* 16 or 32 bit version of hardware block */
 	unsigned long overflow_bit;
@@ -79,6 +80,12 @@ struct sh_cmt_priv {
  * CMCSR 0xffca0060 16-bit
  * CMCNT 0xffca0064 32-bit
  * CMCOR 0xffca0068 32-bit
+ *
+ * "32-bit counter and 32-bit control" as found on r8a73a4 and r8a7790:
+ * CMSTR 0xffca0500 32-bit
+ * CMCSR 0xffca0510 32-bit
+ * CMCNT 0xffca0514 32-bit
+ * CMCOR 0xffca0518 32-bit
  */
 
 static unsigned long sh_cmt_read16(void __iomem *base, unsigned long offs)
@@ -109,9 +116,7 @@ static void sh_cmt_write32(void __iomem *base, unsigned long offs,
 
 static inline unsigned long sh_cmt_read_cmstr(struct sh_cmt_priv *p)
 {
-	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
-
-	return p->read_control(p->mapbase - cfg->channel_offset, 0);
+	return p->read_control(p->mapbase_str, 0);
 }
 
 static inline unsigned long sh_cmt_read_cmcsr(struct sh_cmt_priv *p)
@@ -127,9 +132,7 @@ static inline unsigned long sh_cmt_read_cmcnt(struct sh_cmt_priv *p)
 static inline void sh_cmt_write_cmstr(struct sh_cmt_priv *p,
 				      unsigned long value)
 {
-	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
-
-	p->write_control(p->mapbase - cfg->channel_offset, 0, value);
+	p->write_control(p->mapbase_str, 0, value);
 }
 
 static inline void sh_cmt_write_cmcsr(struct sh_cmt_priv *p,
@@ -676,7 +679,7 @@ static int sh_cmt_register(struct sh_cmt_priv *p, char *name,
 static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
 {
 	struct sh_timer_config *cfg = pdev->dev.platform_data;
-	struct resource *res;
+	struct resource *res, *res2;
 	int irq, ret;
 	ret = -ENXIO;
 
@@ -694,6 +697,9 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
 		goto err0;
 	}
 
+	/* optional resource for the shared timer start/stop register */
+	res2 = platform_get_resource(p->pdev, IORESOURCE_MEM, 1);
+
 	irq = platform_get_irq(p->pdev, 0);
 	if (irq < 0) {
 		dev_err(&p->pdev->dev, "failed to get irq\n");
@@ -707,6 +713,15 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
 		goto err0;
 	}
 
+	/* map second resource for CMSTR */
+	p->mapbase_str = ioremap_nocache(res2 ? res2->start :
+					 res->start - cfg->channel_offset,
+					 res2 ? resource_size(res2) : 2);
+	if (p->mapbase_str == NULL) {
+		dev_err(&p->pdev->dev, "failed to remap I/O second memory\n");
+		goto err1;
+	}
+
 	/* request irq using setup_irq() (too early for request_irq()) */
 	p->irqaction.name = dev_name(&p->pdev->dev);
 	p->irqaction.handler = sh_cmt_interrupt;
@@ -719,11 +734,17 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
 	if (IS_ERR(p->clk)) {
 		dev_err(&p->pdev->dev, "cannot get clock\n");
 		ret = PTR_ERR(p->clk);
-		goto err1;
+		goto err2;
 	}
 
-	p->read_control = sh_cmt_read16;
-	p->write_control = sh_cmt_write16;
+	if (res2 && (resource_size(res2) == 4)) {
+		/* assume both CMSTR and CMCSR to be 32-bit */
+		p->read_control = sh_cmt_read32;
+		p->write_control = sh_cmt_write32;
+	} else {
+		p->read_control = sh_cmt_read16;
+		p->write_control = sh_cmt_write16;
+	}
 
 	if (resource_size(res) == 6) {
 		p->width = 16;
@@ -752,22 +773,23 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
 			      cfg->clocksource_rating);
 	if (ret) {
 		dev_err(&p->pdev->dev, "registration failed\n");
-		goto err2;
+		goto err3;
 	}
 	p->cs_enabled = false;
 
 	ret = setup_irq(irq, &p->irqaction);
 	if (ret) {
 		dev_err(&p->pdev->dev, "failed to request irq %d\n", irq);
-		goto err2;
+		goto err3;
 	}
 
 	platform_set_drvdata(pdev, p);
 
 	return 0;
-err2:
+err3:
 	clk_put(p->clk);
-
+err2:
+	iounmap(p->mapbase_str);
 err1:
 	iounmap(p->mapbase);
 err0:
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:36:29 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:36:29 +0900
Subject: [GIT 00/19] Renesas ARM based SoC pinmux updates for v3.12
Message-ID: <cover.1374208262.git.horms+renesas@verge.net.au>

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-pinmux-for-v3.12

for you to fetch changes up to 838a7070ce8bfff11e19ed434edd9a4423b478bd:

  ARM: shmobile: kzm9g-reference: Add LED1-LED4 to the device tree (2013-07-16 12:55:04 +0900)

----------------------------------------------------------------
Renesas ARM based SoC pinmux updates for v3.12

SH Mobile pinctrl DT support

----------------------------------------------------------------
Laurent Pinchart (19):
      ARM: shmobile: r8a73a4: Add pin control device to device tree
      ARM: shmobile: r8a7740: Add pin control device to device tree
      ARM: shmobile: r8a7778: Add pin control device to device tree
      ARM: shmobile: r8a7778: Add GPIO controller devices to device tree
      ARM: shmobile: r8a7779: Add pin control device to device tree
      ARM: shmobile: r8a7779: Add GPIO controller devices to device tree
      ARM: shmobile: r8a7790: Add pin control device to device tree
      ARM: shmobile: r8a7790: Add GPIO controller devices to device tree
      ARM: shmobile: sh7372: Add pin control device to device tree
      ARM: shmobile: sh73a0: Add pin control device to device tree
      ARM: shmobile: armadillo-reference: Move pinctrl mappings to device tree
      ARM: shmobile: armadillo-reference: Add st1232 pin mappings
      ARM: shmobile: armadillo-reference: Move st1232 reset GPIO to DT
      ARM: shmobile: armadillo-reference: Add LED1-LED4 to the device tree
      ARM: shmobile: marzen-reference: Move pinctrl mappings to device tree
      ARM: shmobile: marzen-reference: Add LED2-LED4 to the device tree
      ARM: shmobile: kzm9g-reference: Move pinctrl mappings to device tree
      ARM: shmobile: kzm9g-reference: Move SDHI regulators to DT
      ARM: shmobile: kzm9g-reference: Add LED1-LED4 to the device tree

 arch/arm/boot/dts/r8a73a4.dtsi                     |   88 +++++++++++++++++++
 .../boot/dts/r8a7740-armadillo800eva-reference.dts |   34 ++++++++
 arch/arm/boot/dts/r8a7740.dtsi                     |    8 ++
 arch/arm/boot/dts/r8a7778.dtsi                     |   66 ++++++++++++++
 arch/arm/boot/dts/r8a7779-marzen-reference.dts     |   49 +++++++++++
 arch/arm/boot/dts/r8a7779.dtsi                     |   90 ++++++++++++++++++++
 arch/arm/boot/dts/r8a7790.dtsi                     |   78 +++++++++++++++++
 arch/arm/boot/dts/sh7372.dtsi                      |    8 ++
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts       |   90 +++++++++++++++++++-
 arch/arm/boot/dts/sh73a0.dtsi                      |    8 ++
 .../board-armadillo800eva-reference.c              |   18 +---
 arch/arm/mach-shmobile/board-kzm9g-reference.c     |   47 ----------
 arch/arm/mach-shmobile/board-marzen-reference.c    |   28 ------
 13 files changed, 518 insertions(+), 94 deletions(-)


From horms+renesas at verge.net.au  Fri Jul 19 00:36:57 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:36:57 +0900
Subject: [PATCH 03/19] ARM: shmobile: r8a7778: Add pin control device to
 device tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <2754bfad53d2a5eb2a824c0c8f65564cf0d7b57c.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add a pfc node to the r8a7778 device tree.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7778.dtsi |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index 4743735..c8dbf14 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -32,4 +32,9 @@
 		reg = <0xfe438000 0x1000>,
 		      <0xfe430000 0x100>;
 	};
+
+	pfc: pfc at fffc0000 {
+		compatible = "renesas,pfc-r8a7778";
+		reg = <0xfffc000 0x118>;
+	};
 };
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:36:59 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:36:59 +0900
Subject: [PATCH 05/19] ARM: shmobile: r8a7779: Add pin control device to
 device tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <c829db7cacd0a5dd857bf59f74db1c5e1d3f32f6.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add a pfc node to the r8a7779 device tree and remove manual pinmux
initialization from the corresponding board files.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779.dtsi                  |    5 +++++
 arch/arm/mach-shmobile/board-marzen-reference.c |   17 ++++++++---------
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 7f146c6..9dfc438 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -101,6 +101,11 @@
 		interrupts = <0 81 0x4>;
 	};
 
+	pfc: pfc at fffc0000 {
+		compatible = "renesas,pfc-r8a7779";
+		reg = <0xfffc0000 0x23c>;
+	};
+
 	thermal at ffc48000 {
 		compatible = "renesas,rcar-thermal";
 		reg = <0xffc48000 0x38>;
diff --git a/arch/arm/mach-shmobile/board-marzen-reference.c b/arch/arm/mach-shmobile/board-marzen-reference.c
index 480d882..94804f3 100644
--- a/arch/arm/mach-shmobile/board-marzen-reference.c
+++ b/arch/arm/mach-shmobile/board-marzen-reference.c
@@ -28,24 +28,24 @@
 
 static const struct pinctrl_map marzen_pinctrl_map[] = {
 	/* SCIF2 (CN18: DEBUG0) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.2", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.2", "fffc0000.pfc",
 				  "scif2_data_c", "scif2"),
 	/* SCIF4 (CN19: DEBUG1) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "fffc0000.pfc",
 				  "scif4_data", "scif4"),
 	/* SDHI0 */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
 				  "sdhi0_data4", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
 				  "sdhi0_ctrl", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
 				  "sdhi0_cd", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
 				  "sdhi0_wp", "sdhi0"),
 	/* SMSC */
-	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "fffc0000.pfc",
 				  "intc_irq1_b", "intc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "fffc0000.pfc",
 				  "lbsc_ex_cs0", "lbsc"),
 };
 
@@ -53,7 +53,6 @@ static void __init marzen_init(void)
 {
 	pinctrl_register_mappings(marzen_pinctrl_map,
 				  ARRAY_SIZE(marzen_pinctrl_map));
-	r8a7779_pinmux_init();
 
 	r8a7779_add_standard_devices_dt();
 }
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:36:56 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:36:56 +0900
Subject: [PATCH 02/19] ARM: shmobile: r8a7740: Add pin control device to
 device tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <bce4d99ee1c246a12a043c196faba6948f3bdf9d.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add a pfc node to the r8a7740 device tree and remove manual pinmux
initialization from the corresponding board files.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7740.dtsi                         |    8 ++++++++
 .../mach-shmobile/board-armadillo800eva-reference.c    |   16 ++++++++--------
 2 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 24e9306..e18a195 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -139,4 +139,12 @@
 			      0 72 0x4
 			      0 73 0x4>;
 	};
+
+	pfc: pfc at e6050000 {
+		compatible = "renesas,pfc-r8a7740";
+		reg = <0xe6050000 0x8000>,
+		      <0xe605800c 0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
 };
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
index 03b85fe..f25b6aa 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
@@ -121,7 +121,7 @@
 
 static const struct pinctrl_map eva_pinctrl_map[] = {
 	/* SCIFA1 */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.1", "pfc-r8a7740",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.1", "e6050000.pfc",
 				  "scifa1_data", "scifa1"),
 };
 
@@ -170,22 +170,22 @@ static void __init eva_init(void)
 	eva_clock_init();
 
 	pinctrl_register_mappings(eva_pinctrl_map, ARRAY_SIZE(eva_pinctrl_map));
-	r8a7740_pinmux_init();
 
 	r8a7740_meram_workaround();
 
-	/*
-	 * Touchscreen
-	 * TODO: Move reset GPIO over to .dts when we can reference it
-	 */
-	gpio_request_one(166, GPIOF_OUT_INIT_HIGH, NULL); /* TP_RST_B */
-
 #ifdef CONFIG_CACHE_L2X0
 	/* Early BRESP enable, Shared attribute override enable, 32K*8way */
 	l2x0_init(IOMEM(0xf0002000), 0x40440000, 0x82000fff);
 #endif
 
 	r8a7740_add_standard_devices_dt();
+
+	/*
+	 * Touchscreen
+	 * TODO: Move reset GPIO over to .dts when we can reference it
+	 */
+	gpio_request_one(166, GPIOF_OUT_INIT_HIGH, NULL); /* TP_RST_B */
+
 	r8a7740_pm_init();
 }
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:36:58 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:36:58 +0900
Subject: [PATCH 04/19] ARM: shmobile: r8a7778: Add GPIO controller devices to
 device tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <789ff14261cc1d951a6dfd68edd72e4b44407ddd.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add GPIO controller nodes to the r8a7778 core device tree.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7778.dtsi |   61 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 61 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index c8dbf14..45ac404 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -33,8 +33,69 @@
 		      <0xfe430000 0x100>;
 	};
 
+	gpio0: gpio at ffc40000 {
+		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
+		reg = <0xffc40000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 103 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 0 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio1: gpio at ffc41000 {
+		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
+		reg = <0xffc41000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 103 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 32 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio2: gpio at ffc42000 {
+		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
+		reg = <0xffc42000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 103 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 64 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio3: gpio at ffc43000 {
+		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
+		reg = <0xffc43000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 103 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 96 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio4: gpio at ffc44000 {
+		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
+		reg = <0xffc44000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 103 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 128 27>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
 	pfc: pfc at fffc0000 {
 		compatible = "renesas,pfc-r8a7778";
 		reg = <0xfffc000 0x118>;
+		#gpio-range-cells = <3>;
 	};
 };
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:36:55 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:36:55 +0900
Subject: [PATCH 01/19] ARM: shmobile: r8a73a4: Add pin control device to
 device tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <c173e780f82e5dea3da21f9eda47bc48aa3f57b1.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add a pfc node to the r8a73a4 device tree.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a73a4.dtsi |   88 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 4ff2019..f1a35d5 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -85,4 +85,92 @@
 		interrupt-parent = <&gic>;
 		interrupts = <0 69 4>;
 	};
+
+	i2c0: i2c at e6500000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6500000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 174 0x4>;
+	};
+
+	i2c1: i2c at e6510000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6510000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 175 0x4>;
+	};
+
+	i2c2: i2c at e6520000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6520000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 176 0x4>;
+	};
+
+	i2c3: i2c at e6530000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6530000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 177 0x4>;
+	};
+
+	i2c4: i2c at e6540000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6540000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 178 0x4>;
+	};
+
+	i2c5: i2c at e60b0000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe60b0000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 179 0x4>;
+	};
+
+	i2c6: i2c at e6550000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6550000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 184 0x4>;
+	};
+
+	i2c7: i2c at e6560000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6560000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 185 0x4>;
+	};
+
+	i2c8: i2c at e6570000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6570000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 173 0x4>;
+	};
+
+	pfc: pfc at e6050000 {
+		compatible = "renesas,pfc-r8a73a4";
+		reg = <0xe6050000 0x9000>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
 };
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:37:11 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:37:11 +0900
Subject: [PATCH 12/19] ARM: shmobile: armadillo-reference: Add st1232 pin
 mappings
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <448bd4531a795df3d7541a4dbe40d3fab5f1f68c.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add pin mappings for the st1232 device to the device tree and reference
them as the default state for the device.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index 4a7ae32..a6c6606 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -41,6 +41,8 @@
 		reg = <0x55>;
 		interrupt-parent = <&irqpin1>;
 		interrupts = <2 0>; /* IRQ10: hwirq 2 on irqpin1 */
+		pinctrl-0 = <&st1232_pins>;
+		pinctrl-names = "default";
 	};
 };
 
@@ -52,4 +54,9 @@
 		renesas,groups = "scifa1_data";
 		renesas,function = "scifa1";
 	};
+
+	st1232_pins: st1232 {
+		renesas,groups = "intc_irq10";
+		renesas,function = "intc";
+	};
 };
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:37:13 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:37:13 +0900
Subject: [PATCH 14/19] ARM: shmobile: armadillo-reference: Add LED1-LED4 to
 the device tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <35b235cac74f549e0e7b71c42234566b26ecb90f.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

LED1 to LED4 are GPIO LEDs. Add corresponding DT nodes.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index 8ec4cd1..366f729 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -34,6 +34,21 @@
 		regulator-boot-on;
 	};
 
+	leds {
+		compatible = "gpio-leds";
+		led1 {
+			gpios = <&pfc 102 GPIO_ACTIVE_HIGH>;
+		};
+		led2 {
+			gpios = <&pfc 111 GPIO_ACTIVE_HIGH>;
+		};
+		led3 {
+			gpios = <&pfc 110 GPIO_ACTIVE_HIGH>;
+		};
+		led4 {
+			gpios = <&pfc 177 GPIO_ACTIVE_HIGH>;
+		};
+	};
 };
 
 &i2c0 {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:37:01 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:37:01 +0900
Subject: [PATCH 07/19] ARM: shmobile: r8a7790: Add pin control device to
 device tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <2d6dcdb5352160d064cffefcd63368ad0d518860.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add a pfc node to the r8a7790 device tree.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 339d9b1..13caf12 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -54,4 +54,9 @@
 		interrupt-parent = <&gic>;
 		interrupts = <0 0 4>, <0 1 4>, <0 2 4>,	<0 3 4>;
 	};
+
+	pfc: pfc at e6060000 {
+		compatible = "renesas,pfc-r8a7790";
+		reg = <0 0xe6060000 0 0x250>;
+	};
 };
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:37:12 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:37:12 +0900
Subject: [PATCH 13/19] ARM: shmobile: armadillo-reference: Move st1232 reset
 GPIO to DT
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <9900595b3dac2948112ed7745dbb28d2a8bf99f9.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Reference the st1232 reset GPIO from the device tree and remove it from
board code.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts  |    2 ++
 arch/arm/mach-shmobile/board-armadillo800eva-reference.c |    7 -------
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index a6c6606..8ec4cd1 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -10,6 +10,7 @@
 
 /dts-v1/;
 /include/ "r8a7740.dtsi"
+#include <dt-bindings/gpio/gpio.h>
 
 / {
 	model = "armadillo 800 eva reference";
@@ -43,6 +44,7 @@
 		interrupts = <2 0>; /* IRQ10: hwirq 2 on irqpin1 */
 		pinctrl-0 = <&st1232_pins>;
 		pinctrl-names = "default";
+		gpios = <&pfc 166 GPIO_ACTIVE_LOW>;
 	};
 };
 
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
index 4ddd299..002d8d3 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
@@ -158,7 +158,6 @@ clock_error:
  */
 static void __init eva_init(void)
 {
-
 	r8a7740_clock_init(MD_CK0 | MD_CK2);
 	eva_clock_init();
 
@@ -171,12 +170,6 @@ static void __init eva_init(void)
 
 	r8a7740_add_standard_devices_dt();
 
-	/*
-	 * Touchscreen
-	 * TODO: Move reset GPIO over to .dts when we can reference it
-	 */
-	gpio_request_one(166, GPIOF_OUT_INIT_HIGH, NULL); /* TP_RST_B */
-
 	r8a7740_pm_init();
 }
 
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:37:02 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:37:02 +0900
Subject: [PATCH 08/19] ARM: shmobile: r8a7790: Add GPIO controller devices to
 device tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <ed189bb9e7b2fc65e4e6e17ab32f5838b2c30dae.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add GPIO controller nodes to the r8a7790 core device tree.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi |   73 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 13caf12..9465cfc 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -38,6 +38,78 @@
 		interrupts = <1 9 0xf04>;
 	};
 
+	gpio0: gpio at ffc40000 {
+		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+		reg = <0 0xffc40000 0 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 4 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 0 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio1: gpio at ffc41000 {
+		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+		reg = <0 0xffc41000 0 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 5 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 32 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio2: gpio at ffc42000 {
+		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+		reg = <0 0xffc42000 0 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 6 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 64 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio3: gpio at ffc43000 {
+		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+		reg = <0 0xffc43000 0 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 7 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 96 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio4: gpio at ffc44000 {
+		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+		reg = <0 0xffc44000 0 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 8 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 128 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio5: gpio at ffc45000 {
+		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+		reg = <0 0xffc45000 0 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 9 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 160 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
 	timer {
 		compatible = "arm,armv7-timer";
 		interrupts = <1 13 0xf08>,
@@ -58,5 +130,6 @@
 	pfc: pfc at e6060000 {
 		compatible = "renesas,pfc-r8a7790";
 		reg = <0 0xe6060000 0 0x250>;
+		#gpio-range-cells = <3>;
 	};
 };
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:37:10 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:37:10 +0900
Subject: [PATCH 11/19] ARM: shmobile: armadillo-reference: Move pinctrl
 mappings to device tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <ea79c07300f15d2f250b8ed65b6f90932296099e.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Replace the pinctrl mappings in board code by device tree mappings.
For devices that are still instantiated from board code reference the
mappings as the default pin controller state to apply them at boot time.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts  |   10 ++++++++++
 arch/arm/mach-shmobile/board-armadillo800eva-reference.c |    9 ---------
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index 09ea22c..4a7ae32 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -43,3 +43,13 @@
 		interrupts = <2 0>; /* IRQ10: hwirq 2 on irqpin1 */
 	};
 };
+
+&pfc {
+	pinctrl-0 = <&scifa1_pins>;
+	pinctrl-names = "default";
+
+	scifa1_pins: scifa1 {
+		renesas,groups = "scifa1_data";
+		renesas,function = "scifa1";
+	};
+};
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
index f25b6aa..4ddd299 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
@@ -24,7 +24,6 @@
 #include <linux/kernel.h>
 #include <linux/gpio.h>
 #include <linux/io.h>
-#include <linux/pinctrl/machine.h>
 #include <mach/common.h>
 #include <mach/r8a7740.h>
 #include <asm/mach/arch.h>
@@ -119,12 +118,6 @@
  *	usbhsf_power_ctrl()
  */
 
-static const struct pinctrl_map eva_pinctrl_map[] = {
-	/* SCIFA1 */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.1", "e6050000.pfc",
-				  "scifa1_data", "scifa1"),
-};
-
 static void __init eva_clock_init(void)
 {
 	struct clk *system	= clk_get(NULL, "system_clk");
@@ -169,8 +162,6 @@ static void __init eva_init(void)
 	r8a7740_clock_init(MD_CK0 | MD_CK2);
 	eva_clock_init();
 
-	pinctrl_register_mappings(eva_pinctrl_map, ARRAY_SIZE(eva_pinctrl_map));
-
 	r8a7740_meram_workaround();
 
 #ifdef CONFIG_CACHE_L2X0
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:37:15 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:37:15 +0900
Subject: [PATCH 16/19] ARM: shmobile: marzen-reference: Add LED2-LED4 to the
 device tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <1cf6e1795452f9c1f82b55b1a72585c42249836e.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

LED2 to LED4 are GPIO LEDs. Add corresponding DT nodes.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779-marzen-reference.dts |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7779-marzen-reference.dts b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
index 6d20247..b64705b 100644
--- a/arch/arm/boot/dts/r8a7779-marzen-reference.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 /include/ "r8a7779.dtsi"
+#include <dt-bindings/gpio/gpio.h>
 
 / {
 	model = "marzen";
@@ -47,6 +48,19 @@
 		vddvario-supply = <&fixedregulator3v3>;
 		vdd33a-supply = <&fixedregulator3v3>;
 	};
+
+	leds {
+		compatible = "gpio-leds";
+		led2 {
+			gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+		};
+		led3 {
+			gpios = <&gpio4 30 GPIO_ACTIVE_HIGH>;
+		};
+		led4 {
+			gpios = <&gpio4 31 GPIO_ACTIVE_HIGH>;
+		};
+	};
 };
 
 &pfc {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:37:00 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:37:00 +0900
Subject: [PATCH 06/19] ARM: shmobile: r8a7779: Add GPIO controller devices to
 device tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <d96a1d8bb88a38eef93207daba91338450b3295f.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add GPIO controller nodes to the r8a7779 core device tree.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779.dtsi |   85 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 85 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 9dfc438..e9fbe3d 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -48,6 +48,90 @@
                       <0xf0000100 0x100>;
         };
 
+	gpio0: gpio at ffc40000 {
+		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+		reg = <0xffc40000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 141 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 0 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio1: gpio at ffc41000 {
+		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+		reg = <0xffc41000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 142 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 32 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio2: gpio at ffc42000 {
+		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+		reg = <0xffc42000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 143 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 64 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio3: gpio at ffc43000 {
+		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+		reg = <0xffc43000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 144 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 96 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio4: gpio at ffc44000 {
+		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+		reg = <0xffc44000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 145 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 128 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio5: gpio at ffc45000 {
+		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+		reg = <0xffc45000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 146 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 160 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio6: gpio at ffc46000 {
+		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+		reg = <0xffc46000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 147 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 192 9>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
 	irqpin0: irqpin at fe780010 {
 		compatible = "renesas,intc-irqpin";
 		#interrupt-cells = <2>;
@@ -104,6 +188,7 @@
 	pfc: pfc at fffc0000 {
 		compatible = "renesas,pfc-r8a7779";
 		reg = <0xfffc0000 0x23c>;
+		#gpio-range-cells = <3>;
 	};
 
 	thermal at ffc48000 {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:37:03 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:37:03 +0900
Subject: [PATCH 09/19] ARM: shmobile: sh7372: Add pin control device to device
 tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <ed3dcde41b77aa23ef04ea12c46ed78a816c2a50.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add a pfc node to the sh7372 device tree.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh7372.dtsi |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sh7372.dtsi b/arch/arm/boot/dts/sh7372.dtsi
index 7bf020e..249f65be2 100644
--- a/arch/arm/boot/dts/sh7372.dtsi
+++ b/arch/arm/boot/dts/sh7372.dtsi
@@ -23,4 +23,12 @@
 			reg = <0x0>;
 		};
 	};
+
+	pfc: pfc at e6050000 {
+		compatible = "renesas,pfc-sh7372";
+		reg = <0xe6050000 0x8000>,
+		      <0xe605801c 0x1c>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
 };
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:37:17 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:37:17 +0900
Subject: [PATCH 18/19] ARM: shmobile: kzm9g-reference: Move SDHI regulators to
 DT
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <14036bb1a37f8928ea0d1813b9419472e0a517a7.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Create two GPIO-controlled fixed-voltage regulators in the
kzm9g-reference DT and remove manual configuration of the corresponding
GPIOs from board code.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts   |   23 +++++++++++++++++++++--
 arch/arm/mach-shmobile/board-kzm9g-reference.c |    6 ------
 2 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
index 11ae9ad..d2b2c9f 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -13,6 +13,7 @@
 
 /dts-v1/;
 /include/ "sh73a0.dtsi"
+#include <dt-bindings/gpio/gpio.h>
 
 / {
 	model = "KZM-A9-GT";
@@ -58,6 +59,24 @@
 		regulator-boot-on;
 	};
 
+	vmmc_sdhi0: regulator at 2 {
+	        compatible = "regulator-fixed";
+		regulator-name = "SDHI0 Vcc";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&pfc 15 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vmmc_sdhi2: regulator at 3 {
+	        compatible = "regulator-fixed";
+		regulator-name = "SDHI2 Vcc";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&pfc 14 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
 	lan9220 at 10000000 {
 		compatible = "smsc,lan9220", "smsc,lan9115";
 		reg = <0x10000000 0x100>;
@@ -200,7 +219,7 @@
 	pinctrl-0 = <&sdhi0_pins>;
 	pinctrl-names = "default";
 
-	vmmc-supply = <&reg_3p3v>;
+	vmmc-supply = <&vmmc_sdhi0>;
 	bus-width = <4>;
 	status = "okay";
 };
@@ -209,7 +228,7 @@
 	pinctrl-0 = <&sdhi2_pins>;
 	pinctrl-names = "default";
 
-	vmmc-supply = <&reg_3p3v>;
+	vmmc-supply = <&vmmc_sdhi2>;
 	bus-width = <4>;
 	broken-cd;
 	status = "okay";
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index fc2bb37..1847b4d 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -21,7 +21,6 @@
  */
 
 #include <linux/delay.h>
-#include <linux/gpio.h>
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/irqchip.h>
@@ -37,11 +36,6 @@ static void __init kzm_init(void)
 {
 	sh73a0_add_standard_devices_dt();
 
-	/* enable SD */
-	gpio_request_one(15, GPIOF_OUT_INIT_HIGH, NULL); /* power */
-
-	gpio_request_one(14, GPIOF_OUT_INIT_HIGH, NULL); /* power */
-
 #ifdef CONFIG_CACHE_L2X0
 	/* Early BRESP enable, Shared attribute override enable, 64K*8way */
 	l2x0_init(IOMEM(0xf0100000), 0x40460000, 0x82000fff);
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:37:09 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:37:09 +0900
Subject: [PATCH 10/19] ARM: shmobile: sh73a0: Add pin control device to device
 tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <3e987e22d0aca598b4455948510db013e96f325a.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add a pfc node to the sh73a0 device tree and remove manual pinmux
initialization from the corresponding board files.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh73a0.dtsi                  |    8 +++++++
 arch/arm/mach-shmobile/board-kzm9g-reference.c |   27 ++++++++++++------------
 2 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index b977502..86e79fe 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -222,4 +222,12 @@
 		cap-sd-highspeed;
 		status = "disabled";
 	};
+
+	pfc: pfc at e6050000 {
+		compatible = "renesas,pfc-sh73a0";
+		reg = <0xe6050000 0x8000>,
+		      <0xe605801c 0x1c>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
 };
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index 44055fe..6ff6ca2 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -40,35 +40,35 @@ static unsigned long pin_pullup_conf[] = {
 };
 
 static const struct pinctrl_map kzm_pinctrl_map[] = {
-	PIN_MAP_MUX_GROUP_DEFAULT("e6826000.i2c", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("e6826000.i2c", "e6050000.pfc",
 				  "i2c3_1", "i2c3"),
 	/* MMCIF */
-	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.mmcif", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
 				  "mmc0_data8_0", "mmc0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.mmcif", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
 				  "mmc0_ctrl_0", "mmc0"),
-	PIN_MAP_CONFIGS_PIN_DEFAULT("e6bd0000.mmcif", "pfc-sh73a0",
+	PIN_MAP_CONFIGS_PIN_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
 				    "PORT279", pin_pullup_conf),
-	PIN_MAP_CONFIGS_GROUP_DEFAULT("e6bd0000.mmcif", "pfc-sh73a0",
+	PIN_MAP_CONFIGS_GROUP_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
 				      "mmc0_data8_0", pin_pullup_conf),
 	/* SCIFA4 */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "e6050000.pfc",
 				  "scifa4_data", "scifa4"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "e6050000.pfc",
 				  "scifa4_ctrl", "scifa4"),
 	/* SDHI0 */
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
 				  "sdhi0_data4", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
 				  "sdhi0_ctrl", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
 				  "sdhi0_cd", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
 				  "sdhi0_wp", "sdhi0"),
 	/* SDHI2 */
-	PIN_MAP_MUX_GROUP_DEFAULT("ee140000.sdhi", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("ee140000.sdhi", "e6050000.pfc",
 				  "sdhi2_data4", "sdhi2"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee140000.sdhi", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("ee140000.sdhi", "e6050000.pfc",
 				  "sdhi2_ctrl", "sdhi2"),
 };
 
@@ -76,7 +76,6 @@ static void __init kzm_init(void)
 {
 	sh73a0_add_standard_devices_dt();
 	pinctrl_register_mappings(kzm_pinctrl_map, ARRAY_SIZE(kzm_pinctrl_map));
-	sh73a0_pinmux_init();
 
 	/* enable SD */
 	gpio_request_one(15, GPIOF_OUT_INIT_HIGH, NULL); /* power */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:37:16 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:37:16 +0900
Subject: [PATCH 17/19] ARM: shmobile: kzm9g-reference: Move pinctrl mappings
 to device tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <61eea6ffedd96e3a1d107cde6e5f6c1a444094ff.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Replace the pinctrl mappings in board code by device tree mappings.
For devices that are still instantiated from board code reference the
mappings as the default pin controller state to apply them at boot time.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts   |   51 ++++++++++++++++++++++++
 arch/arm/mach-shmobile/board-kzm9g-reference.c |   40 -------------------
 2 files changed, 51 insertions(+), 40 deletions(-)

diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
index b6f759e..11ae9ad 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -145,19 +145,70 @@
 	};
 };
 
+&i2c3 {
+	pinctrl-0 = <&i2c3_pins>;
+	pinctrl-names = "default";
+};
+
 &mmcif {
+	pinctrl-0 = <&mmcif_pins>;
+	pinctrl-names = "default";
+
 	bus-width = <8>;
 	vmmc-supply = <&reg_1p8v>;
 	status = "okay";
 };
 
+&pfc {
+	pinctrl-0 = <&scifa4_pins>;
+	pinctrl-names = "default";
+
+	i2c3_pins: i2c3 {
+		renesas,groups = "i2c3_1";
+		renesas,function = "i2c3";
+	};
+
+	mmcif_pins: mmcif {
+		mux {
+			renesas,groups = "mmc0_data8_0", "mmc0_ctrl_0";
+			renesas,function = "mmc0";
+		};
+		cfg {
+			renesas,groups = "mmc0_data8_0";
+			renesas,pins = "PORT279";
+			bias-pull-up;
+		};
+	};
+
+	scifa4_pins: scifa4 {
+		renesas,groups = "scifa4_data", "scifa4_ctrl";
+		renesas,function = "scifa4";
+	};
+
+	sdhi0_pins: sdhi0 {
+		renesas,groups = "sdhi0_data4", "sdhi0_ctrl", "sdhi0_cd", "sdhi0_wp";
+		renesas,function = "sdhi0";
+	};
+
+	sdhi2_pins: sdhi2 {
+		renesas,groups = "sdhi2_data4", "sdhi2_ctrl";
+		renesas,function = "sdhi2";
+	};
+};
+
 &sdhi0 {
+	pinctrl-0 = <&sdhi0_pins>;
+	pinctrl-names = "default";
+
 	vmmc-supply = <&reg_3p3v>;
 	bus-width = <4>;
 	status = "okay";
 };
 
 &sdhi2 {
+	pinctrl-0 = <&sdhi2_pins>;
+	pinctrl-names = "default";
+
 	vmmc-supply = <&reg_3p3v>;
 	bus-width = <4>;
 	broken-cd;
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index 6ff6ca2..fc2bb37 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -27,55 +27,15 @@
 #include <linux/irqchip.h>
 #include <linux/input.h>
 #include <linux/of_platform.h>
-#include <linux/pinctrl/machine.h>
-#include <linux/pinctrl/pinconf-generic.h>
 #include <mach/sh73a0.h>
 #include <mach/common.h>
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
-static unsigned long pin_pullup_conf[] = {
-	PIN_CONF_PACKED(PIN_CONFIG_BIAS_PULL_UP, 0),
-};
-
-static const struct pinctrl_map kzm_pinctrl_map[] = {
-	PIN_MAP_MUX_GROUP_DEFAULT("e6826000.i2c", "e6050000.pfc",
-				  "i2c3_1", "i2c3"),
-	/* MMCIF */
-	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
-				  "mmc0_data8_0", "mmc0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
-				  "mmc0_ctrl_0", "mmc0"),
-	PIN_MAP_CONFIGS_PIN_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
-				    "PORT279", pin_pullup_conf),
-	PIN_MAP_CONFIGS_GROUP_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
-				      "mmc0_data8_0", pin_pullup_conf),
-	/* SCIFA4 */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "e6050000.pfc",
-				  "scifa4_data", "scifa4"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "e6050000.pfc",
-				  "scifa4_ctrl", "scifa4"),
-	/* SDHI0 */
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
-				  "sdhi0_data4", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
-				  "sdhi0_ctrl", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
-				  "sdhi0_cd", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
-				  "sdhi0_wp", "sdhi0"),
-	/* SDHI2 */
-	PIN_MAP_MUX_GROUP_DEFAULT("ee140000.sdhi", "e6050000.pfc",
-				  "sdhi2_data4", "sdhi2"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee140000.sdhi", "e6050000.pfc",
-				  "sdhi2_ctrl", "sdhi2"),
-};
-
 static void __init kzm_init(void)
 {
 	sh73a0_add_standard_devices_dt();
-	pinctrl_register_mappings(kzm_pinctrl_map, ARRAY_SIZE(kzm_pinctrl_map));
 
 	/* enable SD */
 	gpio_request_one(15, GPIOF_OUT_INIT_HIGH, NULL); /* power */
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:37:18 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:37:18 +0900
Subject: [PATCH 19/19] ARM: shmobile: kzm9g-reference: Add LED1-LED4 to the
 device tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <838a7070ce8bfff11e19ed434edd9a4423b478bd.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

LED1 to LED4 are GPIO LEDs. Add corresponding DT nodes.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
index d2b2c9f..b99e890 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -89,6 +89,22 @@
 		vddvario-supply = <&reg_1p8v>;
 		vdd33a-supply = <&reg_3p3v>;
 	};
+
+	leds {
+		compatible = "gpio-leds";
+		led1 {
+			gpios = <&pfc 20 GPIO_ACTIVE_LOW>;
+		};
+		led2 {
+			gpios = <&pfc 21 GPIO_ACTIVE_LOW>;
+		};
+		led3 {
+			gpios = <&pfc 22 GPIO_ACTIVE_LOW>;
+		};
+		led4 {
+			gpios = <&pfc 23 GPIO_ACTIVE_LOW>;
+		};
+	};
 };
 
 &i2c0 {
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 19 00:37:14 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Jul 2013 13:37:14 +0900
Subject: [PATCH 15/19] ARM: shmobile: marzen-reference: Move pinctrl mappings
 to device tree
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <fb0978516f4a7c2d62e097d05c86f47d407fe4a2.1374208262.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Replace the pinctrl mappings in board code by device tree mappings.
For devices that are still instantiated from board code reference the
mappings as the default pin controller state to apply them at boot time.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779-marzen-reference.dts  |   35 +++++++++++++++++++++++
 arch/arm/mach-shmobile/board-marzen-reference.c |   27 -----------------
 2 files changed, 35 insertions(+), 27 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779-marzen-reference.dts b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
index 72be4c8..6d20247 100644
--- a/arch/arm/boot/dts/r8a7779-marzen-reference.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
@@ -37,6 +37,9 @@
 	lan0 at 18000000 {
 		compatible = "smsc,lan9220", "smsc,lan9115";
 		reg = <0x18000000 0x100>;
+		pinctrl-0 = <&lan0_pins>;
+		pinctrl-names = "default";
+
 		phy-mode = "mii";
 		interrupt-parent = <&gic>;
 		interrupts = <0 28 0x4>;
@@ -45,3 +48,35 @@
 		vdd33a-supply = <&fixedregulator3v3>;
 	};
 };
+
+&pfc {
+	pinctrl-0 = <&scif2_pins &scif4_pins &sdhi0_pins>;
+	pinctrl-names = "default";
+
+	lan0_pins: lan0 {
+		intc {
+			renesas,groups = "intc_irq1_b";
+			renesas,function = "intc";
+		};
+		lbsc {
+			renesas,groups = "lbsc_ex_cs0";
+			renesas,function = "lbsc";
+		};
+	};
+
+	scif2_pins: scif2 {
+		renesas,groups = "scif2_data_c";
+		renesas,function = "scif2";
+	};
+
+	scif4_pins: scif4 {
+		renesas,groups = "scif4_data";
+		renesas,function = "scif4";
+	};
+
+	sdhi0_pins: sdhi0 {
+		renesas,groups = "sdhi0_data4", "sdhi0_ctrl", "sdhi0_cd",
+				 "sdhi0_wp";
+		renesas,function = "sdhi0";
+	};
+};
diff --git a/arch/arm/mach-shmobile/board-marzen-reference.c b/arch/arm/mach-shmobile/board-marzen-reference.c
index 94804f3..3d1c439 100644
--- a/arch/arm/mach-shmobile/board-marzen-reference.c
+++ b/arch/arm/mach-shmobile/board-marzen-reference.c
@@ -19,41 +19,14 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  */
 
-#include <linux/pinctrl/machine.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <asm/irq.h>
 #include <asm/mach/arch.h>
 
-static const struct pinctrl_map marzen_pinctrl_map[] = {
-	/* SCIF2 (CN18: DEBUG0) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.2", "fffc0000.pfc",
-				  "scif2_data_c", "scif2"),
-	/* SCIF4 (CN19: DEBUG1) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "fffc0000.pfc",
-				  "scif4_data", "scif4"),
-	/* SDHI0 */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
-				  "sdhi0_data4", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
-				  "sdhi0_ctrl", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
-				  "sdhi0_cd", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
-				  "sdhi0_wp", "sdhi0"),
-	/* SMSC */
-	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "fffc0000.pfc",
-				  "intc_irq1_b", "intc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "fffc0000.pfc",
-				  "lbsc_ex_cs0", "lbsc"),
-};
-
 static void __init marzen_init(void)
 {
-	pinctrl_register_mappings(marzen_pinctrl_map,
-				  ARRAY_SIZE(marzen_pinctrl_map));
-
 	r8a7779_add_standard_devices_dt();
 }
 
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 19 01:37:10 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 19 Jul 2013 11:07:10 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130718154954.GA31961@kroah.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-2-git-send-email-kishon@ti.com>
 <20130718072004.GA16720@kroah.com> <51E7AE88.3050007@ti.com>
 <20130718154954.GA31961@kroah.com>
Message-ID: <51E8D086.809@ti.com>

Hi,

On Thursday 18 July 2013 09:19 PM, Greg KH wrote:
> On Thu, Jul 18, 2013 at 02:29:52PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Thursday 18 July 2013 12:50 PM, Greg KH wrote:
>>> On Thu, Jul 18, 2013 at 12:16:10PM +0530, Kishon Vijay Abraham I wrote:
>>>> +struct phy_provider *__of_phy_provider_register(struct device *dev,
>>>> +	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
>>>> +	struct of_phandle_args *args));
>>>> +struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
>>>> +	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
>>>> +	struct of_phandle_args *args))
>>>> +
>>>> +__of_phy_provider_register and __devm_of_phy_provider_register can be used to
>>>> +register the phy_provider and it takes device, owner and of_xlate as
>>>> +arguments. For the dt boot case, all PHY providers should use one of the above
>>>> +2 APIs to register the PHY provider.
>>>
>>> Why do you have __ for the prefix of a public function?  Is that really
>>> the way that OF handles this type of thing?
>>
>> I have a macro of_phy_provider_register/devm_of_phy_provider_register that
>> calls these functions and should be used by the PHY drivers. Probably I should
>> make a mention of it in the Documentation.
> 
> Yes, mention those as you never want to be calling __* functions
> directly, right?

correct.
> 
>>>> +	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
>>>
>>> Your naming is odd, no "phy" anywhere in it?  You rely on the sender to
>>> never send a duplicate name.id pair?  Why not create your own ids based
>>> on the number of phys in the system, like almost all other classes and
>>> subsystems do?
>>
>> hmm.. some PHY drivers use the id they provide to perform some of their
>> internal operation as in [1] (This is used only if a single PHY provider
>> implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO
>> to give the PHY drivers an option to use auto id.
>>
>> [1] ->
>> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> 
> No, who cares about the id?  No one outside of the phy core ever should,
> because you pass back the only pointer that they really do care about,
> if they need to do anything with the device.  Use that, and then you can

hmm.. ok.

> rip out all of the "search for a phy by a string" logic, as that's not

Actually this is needed for non-dt boot case. In the case of dt boot, we use a
phandle by which the controller can get a reference to the phy. But in the case
of non-dt boot, the controller can get a reference to the phy only by label.
> needed either.  Just stick to the pointer, it's easier, and safer that
> way.
> 
>>>> +static inline int phy_pm_runtime_get(struct phy *phy)
>>>> +{
>>>> +	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>>>> +		return -EINVAL;
>>>
>>> Why would phy ever not be valid and a error pointer?  And why dump the
>>> stack if that happens, that seems really extreme.
>>
>> hmm.. there might be cases where the same controller in one soc needs PHY
>> control and in some other soc does not need PHY control. In such cases, we
>> might get error pointer here.
>> I'll change WARN to dev_err.
> 
> I still don't understand.  You have control over the code that calls
> these functions, just ensure that they pass in a valid pointer, it's
> that simple.  Or am I missing something?

You are right. Valid pointer check can be done in controller code as well.

Thanks
Kishon


From gregkh at linuxfoundation.org  Fri Jul 19 01:43:11 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Thu, 18 Jul 2013 22:43:11 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51E8D086.809@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-2-git-send-email-kishon@ti.com>
 <20130718072004.GA16720@kroah.com> <51E7AE88.3050007@ti.com>
 <20130718154954.GA31961@kroah.com> <51E8D086.809@ti.com>
Message-ID: <20130719054311.GA14638@kroah.com>

On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote:
> >>>> +	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
> >>>
> >>> Your naming is odd, no "phy" anywhere in it?  You rely on the sender to
> >>> never send a duplicate name.id pair?  Why not create your own ids based
> >>> on the number of phys in the system, like almost all other classes and
> >>> subsystems do?
> >>
> >> hmm.. some PHY drivers use the id they provide to perform some of their
> >> internal operation as in [1] (This is used only if a single PHY provider
> >> implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO
> >> to give the PHY drivers an option to use auto id.
> >>
> >> [1] ->
> >> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> > 
> > No, who cares about the id?  No one outside of the phy core ever should,
> > because you pass back the only pointer that they really do care about,
> > if they need to do anything with the device.  Use that, and then you can
> 
> hmm.. ok.
> 
> > rip out all of the "search for a phy by a string" logic, as that's not
> 
> Actually this is needed for non-dt boot case. In the case of dt boot, we use a
> phandle by which the controller can get a reference to the phy. But in the case
> of non-dt boot, the controller can get a reference to the phy only by label.

I don't understand.  They registered the phy, and got back a pointer to
it.  Why can't they save it in their local structure to use it again
later if needed?  They should never have to "ask" for the device, as the
device id might be unknown if there are multiple devices in the system.

Or am I missing something?

thanks,

greg k-h


From kishon at ti.com  Fri Jul 19 01:55:44 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 19 Jul 2013 11:25:44 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130719054311.GA14638@kroah.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-2-git-send-email-kishon@ti.com>
 <20130718072004.GA16720@kroah.com> <51E7AE88.3050007@ti.com>
 <20130718154954.GA31961@kroah.com> <51E8D086.809@ti.com>
 <20130719054311.GA14638@kroah.com>
Message-ID: <51E8D4E0.8060200@ti.com>

Hi,

On Friday 19 July 2013 11:13 AM, Greg KH wrote:
> On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote:
>>>>>> +	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
>>>>>
>>>>> Your naming is odd, no "phy" anywhere in it?  You rely on the sender to
>>>>> never send a duplicate name.id pair?  Why not create your own ids based
>>>>> on the number of phys in the system, like almost all other classes and
>>>>> subsystems do?
>>>>
>>>> hmm.. some PHY drivers use the id they provide to perform some of their
>>>> internal operation as in [1] (This is used only if a single PHY provider
>>>> implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO
>>>> to give the PHY drivers an option to use auto id.
>>>>
>>>> [1] ->
>>>> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
>>>
>>> No, who cares about the id?  No one outside of the phy core ever should,
>>> because you pass back the only pointer that they really do care about,
>>> if they need to do anything with the device.  Use that, and then you can
>>
>> hmm.. ok.
>>
>>> rip out all of the "search for a phy by a string" logic, as that's not
>>
>> Actually this is needed for non-dt boot case. In the case of dt boot, we use a
>> phandle by which the controller can get a reference to the phy. But in the case
>> of non-dt boot, the controller can get a reference to the phy only by label.
> 
> I don't understand.  They registered the phy, and got back a pointer to
> it.  Why can't they save it in their local structure to use it again
> later if needed?  They should never have to "ask" for the device, as the

One is a *PHY provider* driver which is a driver for some PHY device. This will
use phy_create to create the phy.
The other is a *PHY consumer* driver which might be any controller driver (can
be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference to the
phy (by *phandle* in the case of dt boot and *label* in the case of non-dt boot).
> device id might be unknown if there are multiple devices in the system.

I agree with you on the device id part. That need not be known to the PHY driver.

Thanks
Kishon


From voice.shen at atmel.com  Fri Jul 19 02:06:20 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Fri, 19 Jul 2013 14:06:20 +0800
Subject: [alsa-devel] [PATCH] ASoC: atmel: add wm8904 based audio machine
 driver
In-Reply-To: <51E8A6EF.4040608@atmel.com>
References: <1374132483-25375-1-git-send-email-voice.shen@atmel.com>
 <20130718111709.GL22506@sirena.org.uk> <51E8A6EF.4040608@atmel.com>
Message-ID: <51E8D75C.7030707@atmel.com>

Hi Mark,

On 07/19/2013 10:39 AM, Bo Shen wrote:
>
>>> +#define MCLK_RATE 32768
>>> +
>>> +static struct clk *mclk;
>>
>> This should be in driver data for the board.  Shouldn't the clock be
>> referenced using the clock bindings?
>
> I will try to implement this in next version.

After check the clock implementation, we are on the way to common clock 
framework, so will do this after we fully transfer to common clock.

Best Regards,
Bo Shen


From gregkh at linuxfoundation.org  Fri Jul 19 02:29:41 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Thu, 18 Jul 2013 23:29:41 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51E8D4E0.8060200@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-2-git-send-email-kishon@ti.com>
 <20130718072004.GA16720@kroah.com> <51E7AE88.3050007@ti.com>
 <20130718154954.GA31961@kroah.com> <51E8D086.809@ti.com>
 <20130719054311.GA14638@kroah.com> <51E8D4E0.8060200@ti.com>
Message-ID: <20130719062941.GA23611@kroah.com>

On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Friday 19 July 2013 11:13 AM, Greg KH wrote:
> > On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote:
> >>>>>> +	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
> >>>>>
> >>>>> Your naming is odd, no "phy" anywhere in it?  You rely on the sender to
> >>>>> never send a duplicate name.id pair?  Why not create your own ids based
> >>>>> on the number of phys in the system, like almost all other classes and
> >>>>> subsystems do?
> >>>>
> >>>> hmm.. some PHY drivers use the id they provide to perform some of their
> >>>> internal operation as in [1] (This is used only if a single PHY provider
> >>>> implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO
> >>>> to give the PHY drivers an option to use auto id.
> >>>>
> >>>> [1] ->
> >>>> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> >>>
> >>> No, who cares about the id?  No one outside of the phy core ever should,
> >>> because you pass back the only pointer that they really do care about,
> >>> if they need to do anything with the device.  Use that, and then you can
> >>
> >> hmm.. ok.
> >>
> >>> rip out all of the "search for a phy by a string" logic, as that's not
> >>
> >> Actually this is needed for non-dt boot case. In the case of dt boot, we use a
> >> phandle by which the controller can get a reference to the phy. But in the case
> >> of non-dt boot, the controller can get a reference to the phy only by label.
> > 
> > I don't understand.  They registered the phy, and got back a pointer to
> > it.  Why can't they save it in their local structure to use it again
> > later if needed?  They should never have to "ask" for the device, as the
> 
> One is a *PHY provider* driver which is a driver for some PHY device. This will
> use phy_create to create the phy.
> The other is a *PHY consumer* driver which might be any controller driver (can
> be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference to the
> phy (by *phandle* in the case of dt boot and *label* in the case of non-dt boot).
> > device id might be unknown if there are multiple devices in the system.
> 
> I agree with you on the device id part. That need not be known to the PHY driver.

How does a consumer know which "label" to use in a non-dt system if
there are multiple PHYs in the system?

Do you have any drivers that are non-dt using this yet?

greg k-h


From sachin.kamat at linaro.org  Fri Jul 19 02:30:20 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Fri, 19 Jul 2013 12:00:20 +0530
Subject: [PATCH 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <CAK9yfHyEaysTJ9QpWWxxOacQEP4wv1NX3sXKkvKFhMbBgbCYYg@mail.gmail.com>
References: <1372054438-15693-1-git-send-email-sachin.kamat@linaro.org>
 <CAK9yfHyEaysTJ9QpWWxxOacQEP4wv1NX3sXKkvKFhMbBgbCYYg@mail.gmail.com>
Message-ID: <CAK9yfHy7BR8kEmc9++ohRRQ=pDVy0oXYqL6Dh1cSNU2v_D_u5w@mail.gmail.com>

Ping Kukjin.


On 15 July 2013 17:22, Sachin Kamat <sachin.kamat at linaro.org> wrote:
> On 24 June 2013 11:43, Sachin Kamat <sachin.kamat at linaro.org> wrote:
>> With the recent cleanup in Exynos platform code notably commits
>> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
>> more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
>> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
>> Exynos4412 which have more (285) than the default number of GPIOs (255).
>> Thus define this number in Kconfig file. Without this patch we get the
>> following errors during boot:
>>
>> gpiochip_add: gpios 251..258 (gpv0) failed to register
>> samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
>> error code: -22
>> samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
>> Cc: Tomasz Figa <t.figa at samsung.com>
>> ---
>> Based on Kukjin's for-next tree.
>> ---
>>  arch/arm/Kconfig |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index ddf2667..380a53b 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1578,6 +1578,7 @@ config ARCH_NR_GPIO
>>         default 512 if SOC_OMAP5
>>         default 392 if ARCH_U8500
>>         default 352 if ARCH_VT8500
>> +       default 288 if ARCH_EXYNOS
>>         default 288 if ARCH_SUNXI
>>         default 264 if MACH_H4700
>>         default 0
>> --
>> 1.7.9.5
>>
>
> Kukjin,
>
> Now that 3.11-rc1 is out, can you please queue this up for 3.11-rc2 as
> without this patch
> gpio support on 4412 boards is broken.
>
>
> --
> With warm regards,
> Sachin



-- 
With warm regards,
Sachin


From kishon at ti.com  Fri Jul 19 02:36:01 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 19 Jul 2013 12:06:01 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130719062941.GA23611@kroah.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-2-git-send-email-kishon@ti.com>
 <20130718072004.GA16720@kroah.com> <51E7AE88.3050007@ti.com>
 <20130718154954.GA31961@kroah.com> <51E8D086.809@ti.com>
 <20130719054311.GA14638@kroah.com> <51E8D4E0.8060200@ti.com>
 <20130719062941.GA23611@kroah.com>
Message-ID: <51E8DE51.1060404@ti.com>

Hi,

On Friday 19 July 2013 11:59 AM, Greg KH wrote:
> On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Friday 19 July 2013 11:13 AM, Greg KH wrote:
>>> On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote:
>>>>>>>> +	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
>>>>>>>
>>>>>>> Your naming is odd, no "phy" anywhere in it?  You rely on the sender to
>>>>>>> never send a duplicate name.id pair?  Why not create your own ids based
>>>>>>> on the number of phys in the system, like almost all other classes and
>>>>>>> subsystems do?
>>>>>>
>>>>>> hmm.. some PHY drivers use the id they provide to perform some of their
>>>>>> internal operation as in [1] (This is used only if a single PHY provider
>>>>>> implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO
>>>>>> to give the PHY drivers an option to use auto id.
>>>>>>
>>>>>> [1] ->
>>>>>> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
>>>>>
>>>>> No, who cares about the id?  No one outside of the phy core ever should,
>>>>> because you pass back the only pointer that they really do care about,
>>>>> if they need to do anything with the device.  Use that, and then you can
>>>>
>>>> hmm.. ok.
>>>>
>>>>> rip out all of the "search for a phy by a string" logic, as that's not
>>>>
>>>> Actually this is needed for non-dt boot case. In the case of dt boot, we use a
>>>> phandle by which the controller can get a reference to the phy. But in the case
>>>> of non-dt boot, the controller can get a reference to the phy only by label.
>>>
>>> I don't understand.  They registered the phy, and got back a pointer to
>>> it.  Why can't they save it in their local structure to use it again
>>> later if needed?  They should never have to "ask" for the device, as the
>>
>> One is a *PHY provider* driver which is a driver for some PHY device. This will
>> use phy_create to create the phy.
>> The other is a *PHY consumer* driver which might be any controller driver (can
>> be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference to the
>> phy (by *phandle* in the case of dt boot and *label* in the case of non-dt boot).
>>> device id might be unknown if there are multiple devices in the system.
>>
>> I agree with you on the device id part. That need not be known to the PHY driver.
> 
> How does a consumer know which "label" to use in a non-dt system if
> there are multiple PHYs in the system?

That should be passed using platform data.
> 
> Do you have any drivers that are non-dt using this yet?

yes. tw4030 (used in OMAP3) supports non-dt.
[PATCH 04/15] ARM: OMAP: USB: Add phy binding information
[PATCH 06/15] usb: musb: omap2430: use the new generic PHY framework
of this patch series shows how it's used.

Thanks
Kishon


From paul at pwsan.com  Fri Jul 19 02:52:16 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Fri, 19 Jul 2013 06:52:16 +0000 (UTC)
Subject: OMAP baseline test results for v3.10
Message-ID: <alpine.DEB.2.02.1307190320560.15248@utopia.booyaka.com>


Here are some basic OMAP test results for Linux v3.10.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v3.10/20130717134228/


Test summary
------------

Build: uImage:
    Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a,
                  omap1_defconfig, omap1_defconfig_1510innovator_only, 
                  omap1_defconfig_5912osk_only, omap2plus_defconfig, 
                  omap2plus_defconfig_2430sdp_only
                  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, 
                  omap2plus_defconfig_omap2_4_only, 
                  omap2plus_defconfig_omap3_4_only, 
                  rmk_omap3430_ldp_allnoconfig, 
                  rmk_omap3430_ldp_oldconfig, 
                  rmk_omap4430_sdp_allnoconfig, 
                  rmk_omap4430_sdp_oldconfig

Build: zImage:
    Pass ( 1/ 1): omap2plus_defconfig

Boot to userspace:
    FAIL ( 1/12): 37xxevm
    Pass (11/12): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
                  3730beaglexm, 4430es2panda, 4460pandaes, 5912osk,
                  am335xbone, am335xbonelt, cmt3517

PM: chip retention via suspend:
    FAIL ( 3/ 6): 2430sdp, 37xxevm, 4430es2panda
    Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 4460pandaes

PM: chip retention via dynamic idle:
    FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 2/ 6): 3530es3beagle, 3730beaglexm

PM: chip off except CORE via suspend:
    Pass ( 1/ 1): 3730beaglexm

PM: chip off except CORE via dynamic idle:
    Pass ( 1/ 1): 3730beaglexm

PM: chip off via suspend:
    FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 1/ 4): 3530es3beagle

PM: chip off via dynamic idle:
    FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
    Pass ( 1/ 4): 3530es3beagle



Failing tests: fixed by posted patches
--------------------------------------

* 37xx EVM: boot fails
  - as of v3.10-rc1
  - Fixed by http://marc.info/?l=linux-arm-kernel&m=137112093431021&w=2
  

Failing tests: needing investigation
------------------------------------

Boot tests:

* 3517EVM & CM-T3517: boot hangs with NFS root
  - Likely some Kconfig, board file, and PM issues with EMAC
  - Longstanding bug
  - Not currently part of the automated test suite

Boot warnings:

* 2420N800, 2430sdp: failed to get counter_32k resource
  - "omap2_sync32k_clocksource_init: failed to get counter_32k resource"
  - Cause unknown

* CM-T3517: L3 in-band error with IPSS during boot
  - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
  - Longstanding issue; does not occur on the 3517EVM

* 3730 Beagle XM, 3517EVM, CM-T3517: uart4_rx.uart4_rx mux failure
  - Cause unknown
  - May be related to the OMAP serial driver and/or DT mux data
  - http://marc.info/?l=linux-arm-kernel&m=137121357528854&w=2

PM tests:

* 2430sdp: power domains not entering retention
  - Cause unknown

* 3730 Beagle XM: does not serial wake from off-idle suspend when console
  UART doesn't clock-gate ("debug ignore_loglevel")
  - Cause unknown
  - Not yet part of the automated test suite
  - Re-tested at v3.7; still failing:
    http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt

* 4430es2panda: pwrdm state mismatch on CAM, DSS

* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
  - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
    per discussion with Tero Kristo
  - Likely dependent on the bootloader version
    - fails with 2012.07-00136-g755de79
  - http://marc.info/?l=linux-arm-kernel&m=136432340618226&w=2

* 4430es2panda: MPU, ABE didn't enter target state
  - New for v3.10-rc

* 4460pandaes: pwrdm state mismatch on DSS, ABE, IVAHD, TESLA

* 4460pandaes: chip not entering retention in dynamic idle
  - Presumably 4430es2panda also fails this
  - Suspend-to-RAM enters full chip retention

Other:

* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
  - Unknown cause; could be due to the lack of hierarchical enable/disable
    in hwmod code
  - Jon Hunter and Santosh Shilimkar report this does not appear with
    the same X-loader/bootloader on his 4430ES2.3 Panda, so could be
    ES-level dependent


Failing tests: reported by others 
---------------------------------

- RTC wakeup from suspend broken on 3730beaglexm
  - as of v3.10-rc1
  - discussion here: http://marc.info/?l=linux-omap&m=136915841625434&w=2



vmlinux object size
(delta in bytes from test_v3.10-rc7 
(9e895ace5d82df8929b16f58e9f515f6d54ab82d)):
   text     data      bss    total  kernel
   +103       +8        0     +111  am33xx_only
    +12        0        0      +12  n800_multi_omap2xxx
    +44        0        0      +44  n800_only_a
    +51      +32        0      +83  omap1_defconfig
    +51        0        0      +51  omap1_defconfig_1510innovator_only
    +51        0        0      +51  omap1_defconfig_5912osk_only
   +227      +80        0     +307  omap2plus_defconfig
   -129       +8        0     -121  omap2plus_defconfig_2430sdp_only
   +227      +16        0     +243  omap2plus_defconfig_cpupm
   +163      -16        0     +147  omap2plus_defconfig_no_pm
   -157      +80        0      -77  omap2plus_defconfig_omap2_4_only
   +227      +48        0     +275  omap2plus_defconfig_omap3_4_only
    +24        0      -24        0  rmk_omap3430_ldp_allnoconfig
    -45      +16        0      -29  rmk_omap3430_ldp_oldconfig
    +24        0      -24        0  rmk_omap4430_sdp_allnoconfig
   +611      +72        0     +683  rmk_omap4430_sdp_oldconfig


From josephl at nvidia.com  Fri Jul 19 03:14:24 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 19 Jul 2013 15:14:24 +0800
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <51E7E27B.9090605@linaro.org>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
 <51E6FF0B.5000708@wwwdotorg.org>
 <1374145726.5610.73.camel@jlo-ubuntu-64.nvidia.com>
 <51E7E27B.9090605@linaro.org>
Message-ID: <1374218064.24607.1.camel@jlo-ubuntu-64.nvidia.com>

On Thu, 2013-07-18 at 20:41 +0800, Daniel Lezcano wrote:
> On 07/18/2013 01:08 PM, Joseph Lo wrote:
> > On Thu, 2013-07-18 at 04:31 +0800, Stephen Warren wrote:
> >> On 07/17/2013 04:15 AM, Joseph Lo wrote:
> >>> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
> >>>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
> >>>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
> >>>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
> >>>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
> >>>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
> >>>>>>> this state.
> >> ... [ discussion of issues with Joesph's patches applied]
> >>>
> >>> OK. I did more stress tests last night and today. I found it cause by
> >>> the patch "ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag" and
> >>> only impact the Tegra20 platform. The hot plug regression seems due to
> >>> this patch. After dropping this patch on top of v3.11-rc1, the Tegra20
> >>> can back to normal.
> >>>
> >>> And the hop plug and suspend stress test can pass on Tegra30/114 too.
> >>>
> >>> Can the other two patch series for Tegra114 to support CPU idle power
> >>> down mode and system suspend still moving forward, not be blocked by
> >>> this patch?
> >>>
> >>> Looks the CPUIDLE_FLAG_TIMER_STOP flag still cause some other issue for
> >>> hot plug on Tegra20, I will continue to check this. You can just drop
> >>> this patch.
> >>
> >> OK, if I drop that patch, then everything on Tegra20 and Tegra30 seems
> >> fine again.
> >>
> >> However, I've found some new and exciting issue on Tegra114!
> >>
> >> With unmodified v3.11-rc1, I can do the following without issue:
> >>
> >> * Unplug/replug CPUs, so that I had all combinations of CPU 1, 2, 3
> >> plugged/unpplugged (with CPU 0 always plugged).
> >>
> >> * Unplug/replug CPUs, so that I had all combinations of CPU 0, 1, 2, 3
> >> plugged/unpplugged (with the obvious exception of never having all CPUs
> >> unplugged).
> >>
> >> However, if I try this with your Tegra114 cpuidle and suspend patches
> >> applied, I see the following issues:
> >>
> >> 1) If I boot, unplug CPU 0, then replug CPU 0, the system immediately
> >> hard-hangs.
> >>
> > Sorry, I didn't apply the hotplug stress test on CPU0 too much. Because
> > all of our use cases and stress tests are focused on secondary CPUs
> > only.
> >
> > After doing some tests, here is my summary. This issue happens after we
> > support CPU idle power-down mode and relates to PMC or flow controller I
> > believe.
> >
> > i) on top of v3.11-rc1 (only support WFI in CPU idle)
> > When hot unplug CPU0, the PMC can power gate and put it into reset
> > state. This is what I expect and also true on all the other secondary
> > CPUs. The flow controller can maintain the CPU power state machine as
> > what we want.
> >
> > ii) on top of v3.11-rc1 + CPU idle power down mode support
> > a) I saw most of the time the CPU0,1,2,3 were in power down and reset
> > status. That means the idle power down mode works fine.
> >
> > b) Testing with the CPU hotplug stress test with the secondary CPUs (not
> > include CPU0), the result is good too.
> >
> > c) Testing hot plug on CPU0 with CPUIDLE_FLAG_TIMER_STOP apply or not
> > apply (Note 1), the result shows not good to me. The CPU0 have already
> > gone into WFI and the flow controller is set as WAITFOREVENT mode. But
> > the PMC always can't power gate CPU0 and sometimes can put it into
> > reset, but sometimes can't. That's why you can see it hanging after
> > unplug CPU0 sometimes.
> 
> Are sure coupled idle state support hotplug and especially the cpu0
> hotplug ?

Tegra114 didn't use coupled idle framework.




From tony at atomide.com  Fri Jul 19 03:17:29 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Jul 2013 00:17:29 -0700
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <51E87C98.5030001@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <51E83A4F.5080904@ti.com> <51E87C98.5030001@ti.com>
Message-ID: <20130719071728.GX7656@atomide.com>

> On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
> 
> Since the cross-bar is not limited t0 IRQ lines and applicable for
> DMA request lines as well, making it IRQ chip doesn't make sense. Its
> not typical pin control functionality either but at least that framework
> is much closer to consider as an option.
> 
> Actually its more of setting up the IRQ and DMA pins maps once
> at boot for a given SOC based on chosen configuration by the
> board. So I am leaning towards pinctrl as well. Just haven't
> thought enough about whether thats the best approach.
> 
> CC'ing Linus W and Tony L whether we can use pinctrl framework
> for such an IP and if yes how ;-).

If it really muxes signals then using pinctrl seems logical.
Especially if the registers are in the SCM block.

It might be already possible to handle it already with
pinctrl-single,bits for the muxing part.

Regards,

Tony


From olof at lixom.net  Fri Jul 19 03:24:35 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 19 Jul 2013 09:24:35 +0200
Subject: [GIT PULL] Remove ARM local timer API
In-Reply-To: <51E71202.5060207@codeaurora.org>
References: <20130625200211.GA11625@codeaurora.org>
 <20130628000853.GB11547@quad.lixom.net> <20130708153528.GB830@codeaurora.org>
 <51E71202.5060207@codeaurora.org>
Message-ID: <40771222-cc0f-4826-b14f-8dcdb4abb673@email.android.com>



Stephen Boyd <sboyd at codeaurora.org> wrote:

>On 07/08/13 08:35, Stephen Boyd wrote:
>> On 06/27, Olof Johansson wrote:
>>> On Tue, Jun 25, 2013 at 01:02:12PM -0700, Stephen Boyd wrote:
>>>> Olof/Arnd,
>>>>
>>>> These patches remove the ARM local timer API. The ARM architected
>>>> timers have already moved away from this API so this series
>>>> migrates the rest of the users allowing us to remove the API
>>>> entirely. Thomas has been kind enough to take the first two
>>>> patches into timers/core in the tip tree (thanks Thomas!) so I've
>>>> merged that into v3.10-rc1 and then applied the rest of the
>>>> patches on top. Let me know if this is acceptable.
>>> We need guarantees from Thomas that the branch is stable and will
>never be
>>> rebased before it hit Linus tree, or we'll be in a world of pain for
>>> dependencies like these.
>>>
>>> Thomas, is this branch stable or do you anticipate a rebase?
>>>
>> This branch has merged into Linus' tree. Can this go through the
>> arm-soc tree now?
>>
>
>The merge window is over now. Can this be merged for 3.12?

Yes, I am still traveling and haven't done any merges for 3.12 yet. This is first in the queue, I should get to it over the weekend or early next week.


-Olof



From tony at atomide.com  Fri Jul 19 03:29:27 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Jul 2013 00:29:27 -0700
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <51E8401E.8040705@wwwdotorg.org>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
 <51E70953.1000601@wwwdotorg.org>
 <20130718072034.GO7656@atomide.com>
 <51E8401E.8040705@wwwdotorg.org>
Message-ID: <20130719072927.GY7656@atomide.com>

* Stephen Warren <swarren at wwwdotorg.org> [130718 12:27]:
> On 07/18/2013 01:25 AM, Tony Lindgren wrote:
> > * Stephen Warren <swarren at wwwdotorg.org> [130717 14:21]:
> >> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
> >>> To toggle dynamic states, let's add the optional active state in
> >>> addition to the static default state. Then if the optional active
> >>> state is defined, we can require that idle and sleep states cover
> >>> the same pingroups as the active state.
> >>>
> >>> Then let's add pinctrl_check_dynamic() and pinctrl_select_dynamic()
> >>> to use instead of pinctrl_select() to avoid breaking existing users.
> >>>
> >>> With pinctrl_check_dynamic() we can check that idle and sleep states
> >>> match the active state for pingroups during init, and don't need to
> >>> do it during runtime.
> >>>
> >>> Then with the states pre-validated, pinctrl_select_dynamic() can
> >>> just toggle between the dynamic states without extra checks.
> >>>
> >>> Note that pinctr_select_state() still has valid use cases, such as
> >>> changing states when the pins can be shared between two drivers
> >>> and don't necessarily cover the same pingroups. For dynamic runtime
> >>> toggling of pin states, we should eventually always use just
> >>> pinctrl_select_dynamic().
> 
> >>> @@ -1241,7 +1371,13 @@ static int pinctrl_pm_select_state(struct device *dev, struct pinctrl_state *sta
> >>>  		return 0;
> >>>  	if (IS_ERR(state))
> >>>  		return 0; /* No such state */
> >>> -	ret = pinctrl_select_state(pins->p, state);
> >>> +
> >>> +	/* Configured for proper dynamic muxing? */
> >>> +	if (!IS_ERR(dev->pins->active_state))
> >>> +		ret = pinctrl_select_dynamic(pins->p, state);
> >>> +	else
> >>> +		ret = pinctrl_select_state(pins->p, state);
> >>
> >> Hmmm. I'm not quite sure this is right... Surely this function should
> >> just do nothing if the dynamic states aren't defined? The system should
> >> just, and only, be in the "default" state and never do anything else.
> > 
> > This keeps the existing behaviour. We should be able to drop the
> > call to pinctrl_select_state() here after the existing use in
> > drivers has been fixed.
> 
> How many DT-based systems already have multiple of default/idle/sleep
> states defined in DT? Right now, since the kernel code uses
> pinctrl_select_state() to switch between those, the state definitions
> need to define /all/ pins used by those states, not just the dynamic
> ones. However, with this series in place, the default state should only
> include the static pins, and the active/idle/sleep states should only
> include the dynamic pins. That's a change to the DT bindings, since it
> changes how the DT must be written, and causes older DTs to be
> incompatible with newer kernels and vice-versa.

Well we can keep the current behaviour with pinctrl_select_state() around
as long as needed. For the legacy cases, there is no active state defined
and we fall back to pinctrl_select_state().
 
> So, do we just ignore this DT ABI change again, or insist on doing it in
> some compatible way? DT ABI-ness is a PITA:-(

I'd vote for keeping the existing behaviour with pinctrl_select_state()
when no active state is defined.

Regards,

Tony



From mkl at pengutronix.de  Fri Jul 19 03:34:47 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Fri, 19 Jul 2013 09:34:47 +0200
Subject: [PATCH v2 16/24] net: can: mscan: make mpc512x code use common
 clock
In-Reply-To: <1374178858-8683-2-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374178858-8683-2-git-send-email-gsi@denx.de>
Message-ID: <51E8EC17.9060703@pengutronix.de>

On 07/18/2013 10:20 PM, Gerhard Sittig wrote:
> extend the mscan(4) driver with alternative support for the COMMON_CLK
> approach which is an option in the MPC512x platform, keep the existing
> clock support implementation in place since the driver is shared with
> other MPC5xxx SoCs which don't have common clock support
> 
> one byproduct of this change is that the CAN driver no longer needs to
> access the SoC's clock control registers, which shall be the domain of
> the platform's clock driver
> 
> Signed-off-by: Gerhard Sittig <gsi at denx.de>
> ---
>  drivers/net/can/mscan/mpc5xxx_can.c |  139 +++++++++++++++++++++++++++++++++++
>  1 file changed, 139 insertions(+)
> 
> diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
> index bc422ba..dd26ab6 100644
> --- a/drivers/net/can/mscan/mpc5xxx_can.c
> +++ b/drivers/net/can/mscan/mpc5xxx_can.c
> @@ -108,6 +108,143 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
>  #endif /* CONFIG_PPC_MPC52xx */
>  
>  #ifdef CONFIG_PPC_MPC512x
> +
> +#if IS_ENABLED(CONFIG_COMMON_CLK)
> +
> +static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
> +				 const char *clock_source, int *mscan_clksrc)
> +{
> +	struct device_node *np;
> +	u32 clockdiv;
> +	enum {
> +		CLK_FROM_AUTO,
> +		CLK_FROM_IPS,
> +		CLK_FROM_SYS,
> +		CLK_FROM_REF,
> +	} clk_from;
> +	struct clk *clk_in, *clk_can;
> +	unsigned long freq_calc;
> +
> +	/* the caller passed in the clock source spec that was read from
> +	 * the device tree, get the optional clock divider as well
> +	 */
> +	np = ofdev->dev.of_node;
> +	clockdiv = 1;
> +	of_property_read_u32(np, "fsl,mscan-clock-divider", &clockdiv);
> +	dev_dbg(&ofdev->dev, "device tree specs: clk src[%s] div[%d]\n",
> +		clock_source ? clock_source : "<NULL>", clockdiv);
> +
> +	/* when clock-source is 'ip', the CANCTL1[CLKSRC] bit needs to
> +	 * get set, and the 'ips' clock is the input to the MSCAN
> +	 * component
> +	 *
> +	 * for clock-source values of 'ref' or 'sys' the CANCTL1[CLKSRC]
> +	 * bit needs to get cleared, an optional clock-divider may have
> +	 * been specified (the default value is 1), the appropriate
> +	 * MSCAN related MCLK is the input to the MSCAN component
> +	 *
> +	 * in the absence of a clock-source spec, first an optimal clock
> +	 * gets determined based on the 'sys' clock, if that fails the
> +	 * 'ref' clock is used
> +	 */
> +	clk_from = CLK_FROM_AUTO;
> +	if (clock_source) {
> +		/* interpret the device tree's spec for the clock source */
> +		if (!strcmp(clock_source, "ip"))
> +			clk_from = CLK_FROM_IPS;
> +		else if (!strcmp(clock_source, "sys"))
> +			clk_from = CLK_FROM_SYS;
> +		else if (!strcmp(clock_source, "ref"))
> +			clk_from = CLK_FROM_REF;
> +		else
> +			goto err_invalid;
> +		dev_dbg(&ofdev->dev, "got a clk source spec[%d]\n", clk_from);
> +	}
> +	if (clk_from == CLK_FROM_AUTO) {
> +		/* no spec so far, try the 'sys' clock; round to the
> +		 * next MHz and see if we can get a multiple of 16MHz
> +		 */
> +		dev_dbg(&ofdev->dev, "no clk source spec, trying SYS\n");
> +		clk_in = clk_get(&ofdev->dev, "sys");
> +		if (IS_ERR(clk_in))
> +			goto err_notavail;
> +		freq_calc = clk_get_rate(clk_in);
> +		freq_calc +=  499999;
> +		freq_calc /= 1000000;
> +		freq_calc *= 1000000;
> +		if ((freq_calc % 16000000) == 0) {
> +			clk_from = CLK_FROM_SYS;
> +			clockdiv = freq_calc / 16000000;
> +			dev_dbg(&ofdev->dev,
> +				"clk fit, sys[%lu] div[%d] freq[%lu]\n",
> +				freq_calc, clockdiv, freq_calc / clockdiv);
> +		}
> +	}
> +	if (clk_from == CLK_FROM_AUTO) {
> +		/* no spec so far, use the 'ref' clock */
> +		dev_dbg(&ofdev->dev, "no clk source spec, trying REF\n");
> +		clk_in = clk_get(&ofdev->dev, "ref");
> +		if (IS_ERR(clk_in))
> +			goto err_notavail;
> +		clk_from = CLK_FROM_REF;
> +		freq_calc = clk_get_rate(clk_in);
> +		dev_dbg(&ofdev->dev,
> +			"clk fit, ref[%lu] (no div) freq[%lu]\n",
> +			freq_calc, freq_calc);
> +	}
> +
> +	/* select IPS or MCLK as the MSCAN input (returned to the caller),
> +	 * setup the MCLK mux source and rate if applicable, apply the
> +	 * optionally specified or derived above divider, and determine
> +	 * the actual resulting clock rate to return to the caller
> +	 */
> +	switch (clk_from) {
> +	case CLK_FROM_IPS:
> +		clk_can = clk_get(&ofdev->dev, "ips");
> +		if (IS_ERR(clk_can))
> +			goto err_notavail;
> +		clk_prepare_enable(clk_can);

Where is the corresponding clk_disable_unprepare()?a

> +		freq_calc = clk_get_rate(clk_can);
> +		*mscan_clksrc = MSCAN_CLKSRC_IPS;
> +		dev_dbg(&ofdev->dev, "clk from IPS, clksrc[%d] freq[%lu]\n",
> +			*mscan_clksrc, freq_calc);
> +		break;
> +	case CLK_FROM_SYS:
> +	case CLK_FROM_REF:
> +		clk_can = clk_get(&ofdev->dev, "mclk");
> +		if (IS_ERR(clk_can))
> +			goto err_notavail;
> +		clk_prepare_enable(clk_can);

dito

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130719/2115e02f/attachment.sig>

From tony at atomide.com  Fri Jul 19 03:39:58 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Jul 2013 00:39:58 -0700
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <51E84180.6080902@wwwdotorg.org>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
 <51E70B5D.6030802@wwwdotorg.org>
 <20130718073638.GP7656@atomide.com>
 <51E84180.6080902@wwwdotorg.org>
Message-ID: <20130719073957.GZ7656@atomide.com>

* Stephen Warren <swarren at wwwdotorg.org> [130718 12:33]:
> On 07/18/2013 01:36 AM, Tony Lindgren wrote:
> > * Stephen Warren <swarren at wwwdotorg.org> [130717 14:30]:
> >> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
> ...
> >> Why shouldn't e.g. a pinctrl-based I2C mux also be able to do runtime
> >> PM? Does the mux setting select which states are used for runtime PM, or
> >> does runtime PM override the basic mux setting, or must the pincrl-I2C
> >> mux manually implement custom runtime-PM/pinctrl interaction since
> >> there's no generic answer to those questions? How many more custom
> >> exceptions will there be?
> > 
> > The idea is that runtime PM will never touch the basic mux settings
> > at all. The "default" state should be considered a static state
> > that is claimed during driver probe, and released when the driver
> > is unloaded. This is typically let's say 90% of the pins for any
> > device.
> > 
> > For runtime PM, we can just toggle the PM related pinctrl states as
> > they have been verified to match the active state during init.
> > 
> > So I don't see why pinctrl-I2C would have to do anything specific.
> > All that is required is that the pins are grouped for the consumer
> > driver, and we can provide some automated checks on the states for
> > runtime PM.
> 
> So, consider a pinctrl-based I2C mux. It has 2 states to cover two I2C
> buses:
> 
> a) bus 1: I2C controller is muxed out onto one set of pins.
> 
> b) bus 2: I2C controller is muxed out onto another set of pins.
> 
> Now, the system could go idle in either of those 2 states, and then
> later need to return to one of those states. I just don't see how that
> would work, since the runtime PM code in this series switches to *an*
> active state when the device becomes non-idle. If the definition of the
> idle state switches the mux function for both sets of pins to some
> idle/quiescent value, then you'd need to do different reprogramming when
> going back to "the" active state; I guess the system would need to
> remember which state was active before switching to idle, then switch
> back to that same state rather than hard-coding the active state name as
> "active"...

I think the only sane way to deal with this is to make the I2C controller
to show up as two separate I2C controller instances. Then use runtime
PM to save and restore the state for each instance, and locking between
the two driver instances.

For the pin muxing part, I'd do this:

			i2c1 instance	i2c2 instance	notes
default_state		0 pins		0 pins		(or dedicated pins only)
active_state		all pins	alls pins
idle_state		safe mode	safe mode

Then when i2c1 instance is done, it's runtime PM suspend muxes the pins
to safe mode, or some nop state. Then when i2c2 instance is woken, it's
runtime PM resume muxes pins to i2c2.

Regards,

Tony


From jonas.jensen at gmail.com  Fri Jul 19 04:07:58 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Fri, 19 Jul 2013 10:07:58 +0200
Subject: [PATCH v4] clk: add MOXA ART SoCs clock driver
In-Reply-To: <1374067396-30155-1-git-send-email-jonas.jensen@gmail.com>
References: <1374067396-30155-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1374221278-18204-1-git-send-email-jonas.jensen@gmail.com>

This patch adds MOXA ART SoCs clock driver support.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v3:
    
    1. remove apb-clock
    2. read clock-output-names of property
    3. update device tree bindings document
    
    Applies to next-20130716

 .../bindings/clock/moxa,moxart-core-clock.txt      | 23 +++++++
 drivers/clk/Makefile                               |  1 +
 drivers/clk/clk-moxart.c                           | 74 ++++++++++++++++++++++
 3 files changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
 create mode 100644 drivers/clk/clk-moxart.c

diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
new file mode 100644
index 0000000..528c8b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
@@ -0,0 +1,23 @@
+Device Tree Clock bindings for arch-moxart
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+MOXA ART SoCs allow to determine core clock frequencies by reading
+a register.
+
+Required properties:
+- compatible : Should be "moxa,moxart-core-clock"
+- #clock-cells : Should be 0
+- reg : Should contain registers location and length
+- clock-output-names : Should be "coreclk"
+
+For example:
+
+	coreclk: core-clock at 98100000 {
+		compatible = "moxa,moxart-core-clock";
+		#clock-cells = <0>;
+		reg = <0x98100000 0x34>;
+		clock-output-names = "coreclk";
+	};
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4038c2b..933622f 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_COMMON_CLK)	+= clk-composite.o
 
 # SoCs specific
 obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
+obj-$(CONFIG_ARCH_MOXART)	+= clk-moxart.o
 obj-$(CONFIG_ARCH_NOMADIK)	+= clk-nomadik.o
 obj-$(CONFIG_ARCH_HIGHBANK)	+= clk-highbank.o
 obj-$(CONFIG_ARCH_NSPIRE)	+= clk-nspire.o
diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
new file mode 100644
index 0000000..a7a1e7b
--- /dev/null
+++ b/drivers/clk/clk-moxart.c
@@ -0,0 +1,74 @@
+/*
+ * MOXA ART SoCs clock driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/platform_device.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/slab.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/clkdev.h>
+
+void __init moxart_of_clk_init(struct device_node *node)
+{
+	static void __iomem *base;
+	struct clk *clk;
+	unsigned long rate;
+	unsigned int mul, val, div;
+	const char *name;
+
+	base = of_iomap(node, 0);
+	if (IS_ERR(base))
+		panic("%s: of_iomap failed\n", node->full_name);
+
+	mul = (readl(base + 0x30) >> 3) & 0x1ff;
+	val = (readl(base + 0x0c) >> 4) & 0x7;
+
+	switch (val) {
+	case 1:
+		div = 3;
+		break;
+	case 2:
+		div = 4;
+		break;
+	case 3:
+		div = 6;
+		break;
+	case 4:
+		div = 8;
+		break;
+	default:
+		div = 2;
+		break;
+	}
+
+	/*
+	 * the rate calculation below is only tested and proven
+	 * to be true for UC-7112-LX
+	 *
+	 * UC-7112-LX: mul=80 val=0
+	 *
+	 * to support other moxart SoC hardware, this may need
+	 * a change, though it's possible it works there too
+	 */
+	rate = (mul * 1200000 / div);
+
+	of_property_read_string(node, "clock-output-names", &name);
+	clk = clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
+	clk_register_clkdev(clk, NULL, name);
+	of_clk_add_provider(node, of_clk_src_simple_get, clk);
+
+	iounmap(base);
+}
+CLK_OF_DECLARE(moxart_core_clock, "moxa,moxart-core-clock", moxart_of_clk_init);
-- 
1.8.2.1



From jonas.jensen at gmail.com  Fri Jul 19 04:17:17 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Fri, 19 Jul 2013 10:17:17 +0200
Subject: [PATCH v5] clk: add MOXA ART SoCs clock driver
In-Reply-To: <1374221278-18204-1-git-send-email-jonas.jensen@gmail.com>
References: <1374221278-18204-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1374221837-23773-1-git-send-email-jonas.jensen@gmail.com>

This patch adds MOXA ART SoCs clock driver support.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v4:
    
    1. remove unnecessary header includes
    
    Applies to next-20130716

 .../bindings/clock/moxa,moxart-core-clock.txt      | 23 ++++++++
 drivers/clk/Makefile                               |  1 +
 drivers/clk/clk-moxart.c                           | 69 ++++++++++++++++++++++
 3 files changed, 93 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
 create mode 100644 drivers/clk/clk-moxart.c

diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
new file mode 100644
index 0000000..528c8b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
@@ -0,0 +1,23 @@
+Device Tree Clock bindings for arch-moxart
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+MOXA ART SoCs allow to determine core clock frequencies by reading
+a register.
+
+Required properties:
+- compatible : Should be "moxa,moxart-core-clock"
+- #clock-cells : Should be 0
+- reg : Should contain registers location and length
+- clock-output-names : Should be "coreclk"
+
+For example:
+
+	coreclk: core-clock at 98100000 {
+		compatible = "moxa,moxart-core-clock";
+		#clock-cells = <0>;
+		reg = <0x98100000 0x34>;
+		clock-output-names = "coreclk";
+	};
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4038c2b..933622f 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_COMMON_CLK)	+= clk-composite.o
 
 # SoCs specific
 obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
+obj-$(CONFIG_ARCH_MOXART)	+= clk-moxart.o
 obj-$(CONFIG_ARCH_NOMADIK)	+= clk-nomadik.o
 obj-$(CONFIG_ARCH_HIGHBANK)	+= clk-highbank.o
 obj-$(CONFIG_ARCH_NSPIRE)	+= clk-nspire.o
diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
new file mode 100644
index 0000000..5559371
--- /dev/null
+++ b/drivers/clk/clk-moxart.c
@@ -0,0 +1,69 @@
+/*
+ * MOXA ART SoCs clock driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/clkdev.h>
+
+void __init moxart_of_clk_init(struct device_node *node)
+{
+	static void __iomem *base;
+	struct clk *clk;
+	unsigned long rate;
+	unsigned int mul, val, div;
+	const char *name;
+
+	base = of_iomap(node, 0);
+	if (IS_ERR(base))
+		panic("%s: of_iomap failed\n", node->full_name);
+
+	mul = (readl(base + 0x30) >> 3) & 0x1ff;
+	val = (readl(base + 0x0c) >> 4) & 0x7;
+
+	switch (val) {
+	case 1:
+		div = 3;
+		break;
+	case 2:
+		div = 4;
+		break;
+	case 3:
+		div = 6;
+		break;
+	case 4:
+		div = 8;
+		break;
+	default:
+		div = 2;
+		break;
+	}
+
+	/*
+	 * the rate calculation below is only tested and proven
+	 * to be true for UC-7112-LX
+	 *
+	 * UC-7112-LX: mul=80 val=0
+	 *
+	 * to support other moxart SoC hardware, this may need
+	 * a change, though it's possible it works there too
+	 */
+	rate = (mul * 1200000 / div);
+
+	of_property_read_string(node, "clock-output-names", &name);
+	clk = clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
+	clk_register_clkdev(clk, NULL, name);
+	of_clk_add_provider(node, of_clk_src_simple_get, clk);
+
+	iounmap(base);
+}
+CLK_OF_DECLARE(moxart_core_clock, "moxa,moxart-core-clock", moxart_of_clk_init);
-- 
1.8.2.1



From maxime.ripard at free-electrons.com  Fri Jul 19 04:27:49 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 19 Jul 2013 10:27:49 +0200
Subject: [PATCH 0/3] Few ignored framebuffer fixes/additions
In-Reply-To: <20130717143709.f8879fb7f0a5d55859e96838@linux-foundation.org>
References: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
 <20130717143709.f8879fb7f0a5d55859e96838@linux-foundation.org>
Message-ID: <20130719082749.GB5106@lukather>

Hi Andrew,

On Wed, Jul 17, 2013 at 02:37:09PM -0700, Andrew Morton wrote:
> On Mon, 15 Jul 2013 17:26:59 +0200 Maxime Ripard <maxime.ripard at free-electrons.com> wrote:
> 
> > Sorry to bother you again with the framebuffer stuff but the new
> > maintainer doesn't appear to be responsive either.
> 
> Jean-Christophe is doing things - on 11 July he sent out a call for
> late patches to linux-fbdev at vger.kernel.org.
> 
> So hopefully the resend of this patch series will be handled
> appropriately?

Hopefully. We'll see how it turns out then, and let you know.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130719/35f5ae92/attachment-0001.sig>

From Ian.Campbell at citrix.com  Fri Jul 19 04:32:16 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Fri, 19 Jul 2013 09:32:16 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabled
In-Reply-To: <CAPnVf8yH7PBOSSC57qJv+pWmsinRUxGr81QUPH9GoOkKw2oo3Q@mail.gmail.com>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
 <CAPnVf8yH7PBOSSC57qJv+pWmsinRUxGr81QUPH9GoOkKw2oo3Q@mail.gmail.com>
Message-ID: <1374222736.26728.128.camel@kazak.uk.xensource.com>

On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote:
> On 17 July 2013 14:25, Stefano Stabellini
> <stefano.stabellini at eu.citrix.com> wrote:
> > On Mon, 15 Jul 2013, Julien Grall wrote:
> >> Even if uncompress debug is disabled, some board will continue to print
> >> information during uncompress step.
> >
> > Are you talking about DEBUG_UNCOMPRESS?
> > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > some board will continue to print information during the uncompress step"?
> 
> Yes. On the arndale, uncompress log are directly output on UART-2.
> This is annoying because Xen doesn't expose the UART to dom0.

This is because Xen wants/tries to use the UART as its own console,
right?

There are at least two other options: Either Xen uses a different UART
to that configured statically into the kernel image (depends on how many
UARTs the platform exposes) or Xen uses no serial console at all.

Of course long term we just need to wait for the exynos stuff to get
integrated into the multiplatform kernel.

Having no Xen serial console is not as bad as it seems for actual
deployment, it is actually already the default on x86 (a serial console
needs to be explicitly configured). The Xen console would still be
available via the "xl dmesg" command and for debug environments people
can just hack around the issue for now (until MP kernels arrive for the
platform).

Perhaps a useful compromise would be for Xen to initially use the
console but to hand it over to dom0 once it starts (similar to how we
handle VGA where it is present), Xen could also steal it back on panic
(since dom0 isn't going to be using it after that...).

Alternatively, since these early UART routines tend to be pretty simple
polled affairs, we could also consider extending the existing vpl011
code to have platform configurable addresses for the output and status
registers and a configurable fixed value for the read of the status
register. I'm not keen to have this code turn into a full "emulator" but
so long as it stays within the remit given in vpl011.c:
        /*
         * This is not intended to be a full emulation of a PL011
         * device. Rather it is intended to provide a sufficient veneer of one
         * that early code (such as Linux's boot time decompressor) which
         * hardcodes output directly to such a device are able to make progress.
         *
         * This device is not intended to be enumerable or exposed to the OS
         * (e.g. via Device Tree).
         */
then I think I could live with it getting a bit more flexible about
where the registers live in order to be able to handle more UART
variants.

Ian.



From oleksandr.kozaruk at globallogic.com  Fri Jul 19 04:35:41 2013
From: oleksandr.kozaruk at globallogic.com (Oleksandr Kozaruk)
Date: Fri, 19 Jul 2013 11:35:41 +0300
Subject: [PATCH v5 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <51E7B9DA.9040803@metafoo.de>
References: <1374059564-6872-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1374059564-6872-3-git-send-email-oleksandr.kozaruk@ti.com>
 <51E6DCB5.3070302@metafoo.de>
 <CAPb7_muAzO-jRqgcm89fcKT-hTLq38Aj2p0WAWjGjN9DoQUwPg@mail.gmail.com>
 <51E7B9DA.9040803@metafoo.de>
Message-ID: <CAPb7_ms36YnT2VVkhngCEonwihtgHSMWO0uQQxsr58rUCgRPLA@mail.gmail.com>

Hello Lars,

On Thu, Jul 18, 2013 at 12:48 PM, Lars-Peter Clausen <lars at metafoo.de> wrote:
> On 07/18/2013 10:36 AM, Oleksandr Kozaruk wrote:
>> Hello Lars,
>>
>> On Wed, Jul 17, 2013 at 9:04 PM, Lars-Peter Clausen <lars at metafoo.de> wrote:
>>>> +static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
>>>> +{
>>>> +     int chn, d1 = 0, d2 = 0, temp;
>>>> +     u8 trim_regs[17];
>>>> +     int ret;
>>>> +
>>>> +     ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
>>>> +                     TWL6030_GPADC_TRIM1, 16);
>>>> +     if (ret < 0) {
>>>> +             dev_err(gpadc->dev, "calibration failed\n");
>>>> +             return ret;
>>>> +     }
>>>> +
>>>> +     /*
>>>> +      * Loop to calculate the value needed for returning voltages from
>>>> +      * GPADC not values.
>>>> +      *
>>>> +      * gain is calculated to 3 decimal places fixed point.
>>>> +      */
>>>> +     for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
>>>> +
>>>> +             switch (chn) {
>>>> +             case 0:
>>>> +             case 1:
>>>> +             case 2:
>>>> +             case 3:
>>>> +             case 4:
>>>> +             case 5:
>>>> +             case 6:
>>>> +             case 11:
>>>> +             case 12:
>>>> +             case 13:
>>>> +             case 14:
>>>> +                     /* D1 */
>>>> +                     d1 = (trim_regs[3] & 0x1F) << 2;
>>>> +                     d1 |= (trim_regs[1] & 0x06) >> 1;
>>>> +                     if (trim_regs[1] & 0x01)
>>>> +                             d1 = -d1;
>>>> +
>>>> +                     /* D2 */
>>>> +                     d2 = (trim_regs[4] & 0x3F) << 2;
>>>> +                     d2 |= (trim_regs[2] & 0x06) >> 1;
>>>> +                     if (trim_regs[2] & 0x01)
>>>> +                             d2 = -d2;
>>>> +                     break;
>>>> +             case 8:
>>>> +                     /* D1 */
>>>> +                     temp = (trim_regs[3] & 0x1F) << 2;
>>>> +                     temp |= (trim_regs[1] & 0x06) >> 1;
>>>> +                     if (trim_regs[1] & 0x01)
>>>> +                             temp = -temp;
>>>> +
>>>> +                     d1 = (trim_regs[8] & 0x18) << 1;
>>>> +                     d1 |= (trim_regs[7] & 0x1E) >> 1;
>>>> +                     if (trim_regs[7] & 0x01)
>>>> +                             d1 = -d1;
>>>> +
>>>> +                     d1 += temp;
>>>> +
>>>> +                     /* D2 */
>>>> +                     temp = (trim_regs[4] & 0x3F) << 2;
>>>> +                     temp |= (trim_regs[2] & 0x06) >> 1;
>>>> +                     if (trim_regs[2] & 0x01)
>>>> +                             temp = -temp;
>>>> +
>>>> +                     d2 = (trim_regs[10] & 0x1F) << 2;
>>>> +                     d2 |= (trim_regs[8] & 0x06) >> 1;
>>>> +                     if (trim_regs[8] & 0x01)
>>>> +                             d2 = -d2;
>>>> +
>>>> +                     d2 += temp;
>>>> +                     break;
>>>> +             case 9:
>>>> +                     /* D1 */
>>>> +                     temp = (trim_regs[3] & 0x1F) << 2;
>>>> +                     temp |= (trim_regs[1] & 0x06) >> 1;
>>>> +                     if (trim_regs[1] & 0x01)
>>>> +                             temp = -temp;
>>>> +
>>>> +                     d1 = (trim_regs[14] & 0x18) << 1;
>>>> +                     d1 |= (trim_regs[12] & 0x1E) >> 1;
>>>> +                     if (trim_regs[12] & 0x01)
>>>> +                             d1 = -d1;
>>>> +
>>>> +                     d1 += temp;
>>>> +
>>>> +                     /* D2 */
>>>> +                     temp = (trim_regs[4] & 0x3F) << 2;
>>>> +                     temp |= (trim_regs[2] & 0x06) >> 1;
>>>> +                     if (trim_regs[2] & 0x01)
>>>> +                             temp = -temp;
>>>> +
>>>> +                     d2 = (trim_regs[16] & 0x1F) << 2;
>>>> +                     d2 |= (trim_regs[14] & 0x06) >> 1;
>>>> +                     if (trim_regs[14] & 0x01)
>>>> +                             d2 = -d2;
>>>> +
>>>> +                     d2 += temp;
>>>> +             case 10:
>>>> +                     /* D1 */
>>>> +                     d1 = (trim_regs[11] & 0x0F) << 3;
>>>> +                     d1 |= (trim_regs[9] & 0x0E) >> 1;
>>>> +                     if (trim_regs[9] & 0x01)
>>>> +                             d1 = -d1;
>>>> +
>>>> +                     /* D2 */
>>>> +                     d2 = (trim_regs[15] & 0x0F) << 3;
>>>> +                     d2 |= (trim_regs[13] & 0x0E) >> 1;
>>>> +                     if (trim_regs[13] & 0x01)
>>>> +                             d2 = -d2;
>>>> +                     break;
>>>> +             case 7:
>>>> +             case 18:
>>>> +                     /* D1 */
>>>> +                     temp = (trim_regs[3] & 0x1F) << 2;
>>>> +                     temp |= (trim_regs[1] & 0x06) >> 1;
>>>> +                     if (trim_regs[1] & 0x01)
>>>> +                             temp = -temp;
>>>> +
>>>> +                     d1 = (trim_regs[5] & 0x7E) >> 1;
>>>> +                     if (trim_regs[5] & 0x01)
>>>> +                             d1 = -d1;
>>>> +.
>>>> +                     d1 += temp;
>>>> +
>>>> +                     /* D2 */
>>>> +                     temp = (trim_regs[4] & 0x3F) << 2;
>>>> +                     temp |= (trim_regs[2] & 0x06) >> 1;
>>>> +                     if (trim_regs[2] & 0x01)
>>>> +                             temp = -temp;
>>>> +
>>>> +                     d2 = (trim_regs[6] & 0xFE) >> 1;
>>>> +                     if (trim_regs[6] & 0x01)
>>>> +                             d2 = -d2;
>>>> +
>>>> +                     d2 += temp;
>>>> +                     break;
>>>
>>>
>>> There is quite a bit of copy paste in here. Putting the bit swizziling into
>>> a helper function should also improbe legibility.
>>
>> Trimming bits are scattered randomly between registers and in
>> different bit positions.
>> I don't see any commonalities, that could be generalized. as Graeme
>> said about it "it's a bane of my life".
>
> The pattern is pretty regular though, how about:
>
>
> int twl6032_get_trim_value(u8 *trim_regs, unsigned int reg0,
>         unsigned int reg1, unsigned int mask0, unsigned int mask1,
>         unsigned int shift0)
> {
>         int val;
>
>         val = (trim_regs[reg0] & mask0) << shift0;
>         val |= (trim_regs[reg1] & mask1) >> 1;
>         if (trim_regs[reg1] & 0x01)
>                 val = -val;
>
>         return val;
> }
>
> and then
>
>         d1 = twl6032_get_trim_value(trim_regs, 3, 1, 0x1f, 0x06, 2);
>         d2 = twl6032_get_trim_value(trim_regs, 4, 2, 0x3f, 0x06, 2);
>
> and so on.

Thank you. I think legibility is better now, I even found a bug - in
case 9 'break' was missing.
Though it is not without special case for channels 7, 18:
	for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {

		switch (chn) {
		case 0:
		case 1:
		case 2:
		case 3:
		case 4:
		case 5:
		case 6:
		case 11:
		case 12:
		case 13:
		case 14:
			d1 = twl6032_get_trim_value(trim_regs, 3, 1, 0x1f, 0x06, 2);
			d2 = twl6032_get_trim_value(trim_regs, 4, 2, 0x3f, 0x06, 2);
			break;
		case 8:
			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x1f, 0x06, 2);
			d1 = temp + twl6032_get_trim_value(trim_regs, 8, 7, 0x18, 0x1E, 1);

			temp = twl6032_get_trim_value(trim_regs, 4, 2, 0x3F, 0x06, 2);
			d2 = temp + twl6032_get_trim_value(trim_regs, 10, 8, 0x1F, 0x06, 2);
			break;
		case 9:
			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x1f, 0x06, 2);
			d1 = temp + twl6032_get_trim_value(trim_regs, 14, 12, 0x18, 0x1E, 1);

			temp = twl6032_get_trim_value(trim_regs, 4, 2, 0x3f, 0x06, 2);
			d2 = temp + twl6032_get_trim_value(trim_regs, 16, 14, 0x1F, 0x06, 1);
			break;
		case 10:
			d1 = twl6032_get_trim_value(trim_regs, 11, 9, 0x0f, 0x0E, 3);
			d2 = twl6032_get_trim_value(trim_regs, 15, 13, 0x0f, 0x0E, 3);
			break;
		case 7:
		case 18:
			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x1f, 0x06, 2);

			d1 = (trim_regs[5] & 0x7E) >> 1;
			if (trim_regs[5] & 0x01)
				d1 = -d1;
			d1 += temp;

			temp = twl6032_get_trim_value(trim_regs, 4, 2, 0x3f, 0x06, 2);

			d2 = (trim_regs[6] & 0xFE) >> 1;
			if (trim_regs[6] & 0x01)
				d2 = -d2;

			d2 += temp;
			break;
		default:
			/* No data for other channels */
			continue;
		}

-- 
Regards,
Oleksandr Kozaruk


From maxime.ripard at free-electrons.com  Fri Jul 19 04:35:55 2013
From: maxime.ripard at free-electrons.com ('Maxime Ripard')
Date: Fri, 19 Jul 2013 10:35:55 +0200
Subject: [PATCH 2/3] video: hx8357: Make IM pins optional
In-Reply-To: <1373945380.7549.26.camel@marge.simpson.net>
References: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
 <1373902022-20439-3-git-send-email-maxime.ripard@free-electrons.com>
 <003501ce81be$4a945ed0$dfbd1c70$@samsung.com>
 <1373945380.7549.26.camel@marge.simpson.net>
Message-ID: <20130719083555.GC5106@lukather>

Hi Jingoo, Mike,

On Tue, Jul 16, 2013 at 05:29:40AM +0200, Mike Galbraith wrote:
> On Tue, 2013-07-16 at 09:49 +0900, Jingoo Han wrote: 
> > On Tuesday, July 16, 2013 12:27 AM, Maxime Ripard wrote:
> 
> > > +
> > > +			ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
> > > +						    GPIOF_OUT_INIT_LOW, "im_pins");
> > 
> > This makes a checkpatch warning such as 'WARNING: line over 80 characters'.
> > How about the following?
> > 
> > 			ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
> > 						GPIOF_OUT_INIT_LOW, "im_pins");
> 
> IIRC, some maintainers gripe (davem?) when they see such alignment,
> preferring the original arg below arg alignment vs strict 80 column.

As far as I know, the coding guide styles are quite fuzzy about this:
  - The new line is not required to be aligned with the braces above
  - Yet, the emacs config given does indent like this.
  - 80 characters is said not to be a hard limit

I don't really know if there's a better solution here, except maybe:
ret = devm_gpio_request_one(&spi-dev, lcd->im_pins[i],
			    GPIOF_OUT_INIT_LOW,
			    "im_pins");

But it's not really a big deal, is it?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130719/bc2fea0e/attachment.sig>

From gsi at denx.de  Fri Jul 19 04:42:52 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Fri, 19 Jul 2013 10:42:52 +0200
Subject: [PATCH v2 18/24] i2c: mpc: OF clock lookup for MPC512x
In-Reply-To: <20130718203324.GB24642@n2100.arm.linux.org.uk>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374178858-8683-4-git-send-email-gsi@denx.de>
 <20130718203324.GB24642@n2100.arm.linux.org.uk>
Message-ID: <20130719084252.GP7080@book.gsilab.sittig.org>

On Thu, Jul 18, 2013 at 21:33 +0100, Russell King - ARM Linux wrote:
> 
> On Thu, Jul 18, 2013 at 10:20:52PM +0200, Gerhard Sittig wrote:
> > +	/* enable clock for the I2C peripheral (non fatal) */
> > +	clk = of_clk_get_by_name(node, "per");
> > +	if (!IS_ERR(clk)) {
> > +		clk_prepare_enable(clk);
> > +		clk_put(clk);
> > +	}
> > +
> 
> This kind of hacked up approach to the clk API is exactly the thing I
> really don't like seeing.  I don't know what it is... is the clk API
> somehow difficult to use or what's the problem with doing stuff correctly?
> 
> 1. Get the clock in your probe function.
> 2. Prepare it at the appropriate time.
> 3. Enable it appropriately.  (or if you want to combine 2 and 3, use
>    clk_prepare_enable().)
> 4. Ensure that enables/disables and prepares/unprepares are appropriately
>    balanced.
> 5. 'put' the clock in your remove function.
> 
> Certainly do not get-enable-put a clock.  You're supposed to hold on to
> the clock all the time that you're actually using it.

Russel, thank you for the feedback!  I agree that your outline of
steps to take is simple and should not be a problem to do.

I noticed that I kept looking at the wrong spot in the driver,
hooked up to some setup routine which lacks a counter part.  You
made me re-visit the drivers and find better locations to hook up
to (probe and remove).  Part of my sloppiness with immediate put
after enable was caused by put being a NOP at the moment, and the
assumption that clocks without references but in the enabled
state won't go away.  But I saw your recent message as well about
how clocks shall get reference counted and keep their provider's
module loaded.

I've queued an update to the I2C, ethernet, and PCI drivers,
which addresses your concerns.  I2C and ethernet clock handling
will become correctly balanced, while PCI won't since the
existing driver already lacks a remove() routine.  These changes
will be part of v3 of the series.

Mark, Greg, v2 of the series already addresses the above concerns
for the serial communication with the PSC hardware (UART and
SPI).  See how 01/24 and 02/24 became much more complex than in
v1, yet should result in appropriate clock handling in these
drivers.

In the very minute I wanted to send out v3, I received feedback
on the CAN driver manipulation from Marc.  Apparently it suffers
from the same problem (my blindness to locate the best spot for
resource release), but CAN shall be the last driver in the series
which is not acceptable yet.


> Final point - if you want to make it non-fatal, don't play games like:
> 
> 	clk = clk_get(whatever);
> 	if (IS_ERR(clk))
> 		clk = NULL;
> 
> 	...
> 	if (clk)
> 		clk_prepare(clk);
> 
> Do this instead:
> 
> 	clk = clk_get(whatever);
> 	...
> 
> 	if (!IS_ERR(clk))
> 		clk_prepare(clk);
> etc.

You saw this in the ethernet driver, right?  This "interesting"
style of "normalization to NULL" in the setup path was meant to
simplify the cleanup path, but that point has become obsolete by
now.  Your example doesn't reflect that 'clk' was a more complex
to access member in the driver's private data.

It seems that doing the setup in steps with a local variable, to
only store the reference when all steps were successful, cleans
up the release code paths.

Immediately putting the clock and not having stored the reference
when enable failed is one more instruction before jumping to the
bailout label, but eliminates the pain of tracking get and enable
separately, and needing two labels for disable and put (you
cannot disable a clock that wasn't enabled).

As mentioned, both the I2C driver you responded to as well as the
ethernet driver you reference here got adjusted.  v3 will get
sent when I could address the remaining CAN driver issue.


> (And on this subject, I'm considering whether to make a change to the
> clk API where clk_prepare() and clk_enable() return zero when passed
> an error pointer - this means drivers with optional clocks don't have
> to burden themselves with these kinds of checks.)


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


From kishon at ti.com  Fri Jul 19 04:45:02 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 19 Jul 2013 14:15:02 +0530
Subject: [PATCH v2 0/4] usb: musb: fix USB enumeration issue in OMAP3
 platform
In-Reply-To: <20130716124227.GC15036@arwen.pp.htv.fi>
References: <1373282057-20181-1-git-send-email-kishon@ti.com>
 <51E4DFA6.2010501@ti.com> <20130716124227.GC15036@arwen.pp.htv.fi>
Message-ID: <51E8FC8E.7090302@ti.com>

Felipe,

On Tuesday 16 July 2013 06:12 PM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 16, 2013 at 11:22:38AM +0530, Kishon Vijay Abraham I wrote:
>> Tony,
>>
>> On Monday 08 July 2013 04:44 PM, Kishon Vijay Abraham I wrote:
>>> This series fixes the USB enumeration issue caused because of the controller
>>> not able to get a reference to the PHY because of incorrect binding in the
>>> board file.
>>>
>>> In the case of non-dt boot, the platform specific initialization file
>>> (board file) will do usb_bind_phy that binds the usb controller with the
>>> PHY using device names. After the device names are created using 
>>> PLATFORM_DEVID_AUTO, our original method of binding by device names doesn't
>>> work reliably (since the device name changes). Hence the usb controller
>>> is made to use labels for getting the PHY.
>>>
>>> Here the PHY name is added in the plat data of USB controller device which
>>> should be used by the controller driver to get the PHY.
>>> Two new APIs usb_get_phy_by_name and devm_usb_get_phy_by_name are added to
>>> be used by the controller to get the PHY by name.
>>
>> You haven't picked this patch series?
> 
> yeah and now it's too much to send during the -rc series. Here's what we
> can do, we can to minimum fix for -rc series (patching the names again)

There are a lot of different boards available using OMAP3 and the device names
(PHY and MUSB) vary across each board (apparently). It will be difficult to
find the device names (for PHY and MUSB) for all the different boards available
(partly because of non-availability of all the boards) and test it.

Thanks
Kishon


From will.deacon at arm.com  Fri Jul 19 05:03:28 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 19 Jul 2013 10:03:28 +0100
Subject: [PATCH v4 02/17] sched_clock: Use seqcount instead of rolling
 our own
In-Reply-To: <1374189690-10810-3-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-3-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130719090328.GA18139@mudshark.cambridge.arm.com>

On Fri, Jul 19, 2013 at 12:21:15AM +0100, Stephen Boyd wrote:
> We're going to increase the cyc value to 64 bits in the near
> future. Doing that is going to break the custom seqcount
> implementation in the sched_clock code because 64 bit numbers
> aren't guaranteed to be atomic. Replace the cyc_copy with a
> seqcount to avoid this problem.
> 
> Cc: Russell King <linux at arm.linux.org.uk>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  kernel/time/sched_clock.c | 27 ++++++++-------------------
>  1 file changed, 8 insertions(+), 19 deletions(-)

Looks good to me. The current scheme would be very fiddly to extend to
64-bit values on 32-bit architectures without cheap atomic doubleword
accesses.

Acked-by: Will Deacon <will.deacon at arm.com>

Will


From will.deacon at arm.com  Fri Jul 19 05:05:03 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 19 Jul 2013 10:05:03 +0100
Subject: [PATCH] ARM: locks: remove opencoded #16 for ticket shift
In-Reply-To: <alpine.LFD.2.03.1307181350440.14924@syhkavp.arg>
References: <1373894879-30559-1-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307170952580.14924@syhkavp.arg>
 <20130718172159.GC9837@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1307181350440.14924@syhkavp.arg>
Message-ID: <20130719090503.GB18139@mudshark.cambridge.arm.com>

On Thu, Jul 18, 2013 at 06:53:06PM +0100, Nicolas Pitre wrote:
> On Thu, 18 Jul 2013, Will Deacon wrote:
> > There are two aspects to the ticket lock:
> > 
> >   1. The size of each ticket
> >   2. The location of the next ticket within the 32-bit lock word
> > 
> > TICKET_SHIFT actually defines (2) and could be 0 or 16, hence why I was
> > making this small cosmetic change.
> 
> Doesn't matter where the location of the next ticket is.  Whether it is 
> 0 or 16, for the above code to work, it *must* always perform a ror #16.  
> Hence tying the ror constant with TICKET_SHIFT is wrong.

You're right; we always need to refer to the higher ticket, rather than
`owner' or `next'. Patch dropped.

Cheers,

Will


From baruch at tkos.co.il  Fri Jul 19 05:23:19 2013
From: baruch at tkos.co.il (Baruch Siach)
Date: Fri, 19 Jul 2013 12:23:19 +0300
Subject: [PATCH v4 04/17] sched_clock: Add support for >32 bit sched_clock
In-Reply-To: <1374189690-10810-5-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-5-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130719092319.GA4681@tarshish>

Hi Stephen,

On Thu, Jul 18, 2013 at 04:21:17PM -0700, Stephen Boyd wrote:
> The ARM architected system counter has at least 56 usable bits.
> Add support for counters with more than 32 bits to the generic
> sched_clock implementation so we can increase the time between
> wakeups due to dealing with wrap-around on these devices while
> benefiting from the irqtime accounting and suspend/resume
> handling that the generic sched_clock code already has. On my
> system using 56 bits over 32 bits changes the wraparound time
> from a few minutes to an hour. For faster running counters (GHz
> range) this is even more important because we may not be able to
> execute the timer in time to deal with the wraparound if only 32
> bits are used.
> 
> We choose a maxsec value of 3600 seconds because we assume no
> system will go idle for more than an hour. In the future we may
> need to increase this value.
> 
> Note: All users should switch over to the 64-bit read function so
> we can remove setup_sched_clock() in favor of sched_clock_register().
> 
> Cc: Russell King <linux at arm.linux.org.uk>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---

[..]

> @@ -110,14 +123,13 @@ void __init setup_sched_clock(u32 (*read)(void), int
>   bits, unsigned long rate)
>  	if (cd.rate > rate)
>  		return;
>  
> -	BUG_ON(bits > 32);
>  	WARN_ON(!irqs_disabled());
>  	read_sched_clock = read;
> -	sched_clock_mask = (1 << bits) - 1;
> +	sched_clock_mask = CLOCKSOURCE_MASK(bits);

Note that this conflicts with my integer overflow fix 
(http://article.gmane.org/gmane.linux.ports.arm.kernel/252498) that I hope 
will get merged before 3.11 is out.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -


From josephl at nvidia.com  Fri Jul 19 05:25:22 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 19 Jul 2013 17:25:22 +0800
Subject: [PATCH V4 0/4] ARM: tegra114: cpuidle: add power down state
Message-ID: <1374225926-26832-1-git-send-email-josephl@nvidia.com>

This series introduce CPU core power down state for CPU idle. When CPU go
into this state, it saves it's context and needs a proper configuration
in flow controller to power gate the CPU when CPU runs into WFI
instruction. And the CPU also needs to set the IRQ as CPU power down idle
wake up event in flow controller.

To prevent race conditions and ensure proper interrupt routing on
Cortex-A15 CPUs when they are power-gated, add a CPU PM notifier
call-back to reprogram the GIC CPU interface on PM entry. The
GIC CPU interface will be reset back to its normal state by
the common GIC CPU PM exit callback when the CPU wakes up.

And the Tegra114 support CPU0 hotplug function in HW physically, but it
needs other software to make it work normally after we add CPU idle power
down mode support. But we don't support that yet, removing them for now.

V4:
* remove the CPU0 hot plug support due to miss of SW support
* postpone to use CPUIDLE_FLAG_TIMER_STOP flag, because it still has some
  issues
V3:
* use CPUIDLE_FLAG_TIMER_STOP flag
V2:
* clean up the CPUidle driver to make it more generic

Joseph Lo (4):
  Revert "ARM: tegra: add cpu_disable for hotplug"
  ARM: tegra114: Reprogram GIC CPU interface to bypass IRQ on CPU PM
    entry
  ARM: tegra114: add low level support for CPU idle powered-down mode
  ARM: tegra114: cpuidle: add powered-down state

 arch/arm/mach-tegra/common.h           |  1 -
 arch/arm/mach-tegra/cpuidle-tegra114.c | 51 +++++++++++++++++++++++++++++++++-
 arch/arm/mach-tegra/flowctrl.h         |  2 ++
 arch/arm/mach-tegra/hotplug.c          | 11 --------
 arch/arm/mach-tegra/irq.c              | 40 ++++++++++++++++++++++++++
 arch/arm/mach-tegra/platsmp.c          |  1 -
 arch/arm/mach-tegra/sleep-tegra30.S    |  2 ++
 7 files changed, 94 insertions(+), 14 deletions(-)

-- 
1.8.3.2



From josephl at nvidia.com  Fri Jul 19 05:25:23 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 19 Jul 2013 17:25:23 +0800
Subject: [PATCH V4 1/4] Revert "ARM: tegra: add cpu_disable for hotplug"
In-Reply-To: <1374225926-26832-1-git-send-email-josephl@nvidia.com>
References: <1374225926-26832-1-git-send-email-josephl@nvidia.com>
Message-ID: <1374225926-26832-2-git-send-email-josephl@nvidia.com>

This reverts commit 510bb595de26f90e5bb7c4a1e2a584e38398cf00.

The Tegra114 support CPU0 hotplug function in HW physically, but it needs
other software to make it work normally after we add CPU idle power down
mode support. So remove them for now.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V4:
* remove the CPU0 hot plug support due to miss of SW support
---
 arch/arm/mach-tegra/common.h  |  1 -
 arch/arm/mach-tegra/hotplug.c | 11 -----------
 arch/arm/mach-tegra/platsmp.c |  1 -
 3 files changed, 13 deletions(-)

diff --git a/arch/arm/mach-tegra/common.h b/arch/arm/mach-tegra/common.h
index 32f8eb3..5900cc4 100644
--- a/arch/arm/mach-tegra/common.h
+++ b/arch/arm/mach-tegra/common.h
@@ -2,4 +2,3 @@ extern struct smp_operations tegra_smp_ops;
 
 extern int tegra_cpu_kill(unsigned int cpu);
 extern void tegra_cpu_die(unsigned int cpu);
-extern int tegra_cpu_disable(unsigned int cpu);
diff --git a/arch/arm/mach-tegra/hotplug.c b/arch/arm/mach-tegra/hotplug.c
index a52c10e..d07f152 100644
--- a/arch/arm/mach-tegra/hotplug.c
+++ b/arch/arm/mach-tegra/hotplug.c
@@ -46,17 +46,6 @@ void __ref tegra_cpu_die(unsigned int cpu)
 	BUG();
 }
 
-int tegra_cpu_disable(unsigned int cpu)
-{
-	switch (tegra_chip_id) {
-	case TEGRA20:
-	case TEGRA30:
-		return cpu == 0 ? -EPERM : 0;
-	default:
-		return 0;
-	}
-}
-
 void __init tegra_hotplug_init(void)
 {
 	if (!IS_ENABLED(CONFIG_HOTPLUG_CPU))
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index 97b33a2..2d02036 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -196,6 +196,5 @@ struct smp_operations tegra_smp_ops __initdata = {
 #ifdef CONFIG_HOTPLUG_CPU
 	.cpu_kill		= tegra_cpu_kill,
 	.cpu_die		= tegra_cpu_die,
-	.cpu_disable		= tegra_cpu_disable,
 #endif
 };
-- 
1.8.3.2



From josephl at nvidia.com  Fri Jul 19 05:25:25 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 19 Jul 2013 17:25:25 +0800
Subject: [PATCH V4 3/4] ARM: tegra114: add low level support for CPU idle
 powered-down mode
In-Reply-To: <1374225926-26832-1-git-send-email-josephl@nvidia.com>
References: <1374225926-26832-1-git-send-email-josephl@nvidia.com>
Message-ID: <1374225926-26832-4-git-send-email-josephl@nvidia.com>

The flow controller would take care the power sequence when CPU idle in
powered-down mode. It powered gate the CPU when CPU runs into WFI
instruction. And wake up the CPU when event be triggered.

The sequence is below.
* setting wfi bitmap for the CPU as the halt event in the
  FLOW_CTRL_CPU_HALT_REG to monitor the CPU running into WFI,then power
  gate it
* setting IRQ and FIQ as wake up event to wake up CPU when event triggered

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V4:
* no change
V3:
* no change
V2:
* no change
---
 arch/arm/mach-tegra/flowctrl.h      | 2 ++
 arch/arm/mach-tegra/sleep-tegra30.S | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/arm/mach-tegra/flowctrl.h b/arch/arm/mach-tegra/flowctrl.h
index 7a29bae..e56a950 100644
--- a/arch/arm/mach-tegra/flowctrl.h
+++ b/arch/arm/mach-tegra/flowctrl.h
@@ -28,6 +28,8 @@
 #define FLOW_CTRL_SCLK_RESUME		(1 << 27)
 #define FLOW_CTRL_HALT_CPU_IRQ		(1 << 10)
 #define	FLOW_CTRL_HALT_CPU_FIQ		(1 << 8)
+#define FLOW_CTRL_HALT_GIC_IRQ		(1 << 9)
+#define FLOW_CTRL_HALT_GIC_FIQ		(1 << 8)
 #define FLOW_CTRL_CPU0_CSR		0x8
 #define	FLOW_CTRL_CSR_INTR_FLAG		(1 << 15)
 #define FLOW_CTRL_CSR_EVENT_FLAG	(1 << 14)
diff --git a/arch/arm/mach-tegra/sleep-tegra30.S b/arch/arm/mach-tegra/sleep-tegra30.S
index ada8821..5877f26 100644
--- a/arch/arm/mach-tegra/sleep-tegra30.S
+++ b/arch/arm/mach-tegra/sleep-tegra30.S
@@ -99,6 +99,8 @@ flow_ctrl_setting_for_lp2:
 	cmp	r10, #TEGRA30
 	moveq   r3, #FLOW_CTRL_WAIT_FOR_INTERRUPT	@ For LP2
 	movne	r3, #FLOW_CTRL_WAITEVENT
+	orrne	r3, r3, #FLOW_CTRL_HALT_GIC_IRQ
+	orrne	r3, r3, #FLOW_CTRL_HALT_GIC_FIQ
 flow_ctrl_done:
 	cmp	r10, #TEGRA30
 	str	r3, [r2]
-- 
1.8.3.2



From josephl at nvidia.com  Fri Jul 19 05:25:26 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 19 Jul 2013 17:25:26 +0800
Subject: [PATCH V4 4/4] ARM: tegra114: cpuidle: add powered-down state
In-Reply-To: <1374225926-26832-1-git-send-email-josephl@nvidia.com>
References: <1374225926-26832-1-git-send-email-josephl@nvidia.com>
Message-ID: <1374225926-26832-5-git-send-email-josephl@nvidia.com>

This supports CPU core power down on each CPU when CPU idle. When CPU go
into this state, it saves it's context and needs a proper configuration
in flow controller to power gate the CPU when CPU runs into WFI
instruction. And the CPU also needs to set the IRQ as CPU power down idle
wake up event in flow controller.

Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V4:
* postpone to use CPUIDLE_FLAG_TIMER_STOP flag, because it still has some
  issues
V3:
* use CPUIDLE_FLAG_TIMER_STOP flag
V2:
* remove some redundant code of memory barrier
* remove the function declaration by rearranging the coding sequence 
---
 arch/arm/mach-tegra/cpuidle-tegra114.c | 51 +++++++++++++++++++++++++++++++++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
index 1d1c602..e0b8730 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -17,15 +17,64 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/cpuidle.h>
+#include <linux/cpu_pm.h>
+#include <linux/clockchips.h>
 
 #include <asm/cpuidle.h>
+#include <asm/suspend.h>
+#include <asm/smp_plat.h>
+
+#include "pm.h"
+#include "sleep.h"
+
+#ifdef CONFIG_PM_SLEEP
+#define TEGRA114_MAX_STATES 2
+#else
+#define TEGRA114_MAX_STATES 1
+#endif
+
+#ifdef CONFIG_PM_SLEEP
+static int tegra114_idle_power_down(struct cpuidle_device *dev,
+				    struct cpuidle_driver *drv,
+				    int index)
+{
+	local_fiq_disable();
+
+	tegra_set_cpu_in_lp2();
+	cpu_pm_enter();
+
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+
+	cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
+
+	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+
+	cpu_pm_exit();
+	tegra_clear_cpu_in_lp2();
+
+	local_fiq_enable();
+
+	return index;
+}
+#endif
 
 static struct cpuidle_driver tegra_idle_driver = {
 	.name = "tegra_idle",
 	.owner = THIS_MODULE,
-	.state_count = 1,
+	.state_count = TEGRA114_MAX_STATES,
 	.states = {
 		[0] = ARM_CPUIDLE_WFI_STATE_PWR(600),
+#ifdef CONFIG_PM_SLEEP
+		[1] = {
+			.enter			= tegra114_idle_power_down,
+			.exit_latency		= 500,
+			.target_residency	= 1000,
+			.power_usage		= 0,
+			.flags			= CPUIDLE_FLAG_TIME_VALID,
+			.name			= "powered-down",
+			.desc			= "CPU power gated",
+		},
+#endif
 	},
 };
 
-- 
1.8.3.2



From josephl at nvidia.com  Fri Jul 19 05:25:24 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 19 Jul 2013 17:25:24 +0800
Subject: [PATCH V4 2/4] ARM: tegra114: Reprogram GIC CPU interface to bypass
 IRQ on CPU PM entry
In-Reply-To: <1374225926-26832-1-git-send-email-josephl@nvidia.com>
References: <1374225926-26832-1-git-send-email-josephl@nvidia.com>
Message-ID: <1374225926-26832-3-git-send-email-josephl@nvidia.com>

There is a difference between GICv1 and v2 when CPU in power management
mode (aka CPU power down on Tegra). For GICv1, IRQ/FIQ interrupt lines
going to CPU are same lines which are also used for wake-interrupt.
Therefore, we cannot disable the GIC CPU interface if we need to use same
interrupts for CPU wake purpose. This creates a race condition for CPU
power off entry. Also, in GICv1, disabling GICv1 CPU interface puts GICv1
into bypass mode such that incoming legacy IRQ/FIQ are sent to CPU, which
means disabling GIC CPU interface doesn't really disable IRQ/FIQ to CPU.

GICv2 provides a wake IRQ/FIQ (for wake-event purpose), which are not
disabled by GIC CPU interface. This is done by adding a bypass override
capability when the interrupts are disabled at the CPU interface. To
support this, there are four bits about IRQ/FIQ BypassDisable in CPU
interface Control Register. When the IRQ/FIQ not being driver by the
CPU interface, each interrupt output signal can be deasserted rather
than being driven by the legacy interrupt input.

So the wake-event can be used as wakeup signals to SoC (system power
controller).

To prevent race conditions and ensure proper interrupt routing on
Cortex-A15 CPUs when they are power-gated, add a CPU PM notifier
call-back to reprogram the GIC CPU interface on PM entry. The
GIC CPU interface will be reset back to its normal state by
the common GIC CPU PM exit callback when the CPU wakes up.

Based on the work by: Scott Williams <scwilliams at nvidia.com>

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
V4:
* no change
V3:
* no change
V2:
* no change
---
 arch/arm/mach-tegra/irq.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/mach-tegra/irq.c b/arch/arm/mach-tegra/irq.c
index 0de4eed..1a74d56 100644
--- a/arch/arm/mach-tegra/irq.c
+++ b/arch/arm/mach-tegra/irq.c
@@ -18,10 +18,12 @@
  */
 
 #include <linux/kernel.h>
+#include <linux/cpu_pm.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/io.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/irqchip/arm-gic.h>
 #include <linux/syscore_ops.h>
 
@@ -65,6 +67,7 @@ static u32 cpu_ier[TEGRA_MAX_NUM_ICTLRS];
 static u32 cpu_iep[TEGRA_MAX_NUM_ICTLRS];
 
 static u32 ictlr_wake_mask[TEGRA_MAX_NUM_ICTLRS];
+static void __iomem *tegra_gic_cpu_base;
 #endif
 
 bool tegra_pending_sgi(void)
@@ -213,8 +216,43 @@ int tegra_legacy_irq_syscore_init(void)
 
 	return 0;
 }
+
+static int tegra_gic_notifier(struct notifier_block *self,
+			      unsigned long cmd, void *v)
+{
+	switch (cmd) {
+	case CPU_PM_ENTER:
+		writel_relaxed(0x1E0, tegra_gic_cpu_base + GIC_CPU_CTRL);
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block tegra_gic_notifier_block = {
+	.notifier_call = tegra_gic_notifier,
+};
+
+static const struct of_device_id tegra114_dt_gic_match[] __initconst = {
+	{ .compatible = "arm,cortex-a15-gic" },
+	{ }
+};
+
+static void tegra114_gic_cpu_pm_registration(void)
+{
+	struct device_node *dn;
+
+	dn = of_find_matching_node(NULL, tegra114_dt_gic_match);
+	if (!dn)
+		return;
+
+	tegra_gic_cpu_base = of_iomap(dn, 1);
+
+	cpu_pm_register_notifier(&tegra_gic_notifier_block);
+}
 #else
 #define tegra_set_wake NULL
+static void tegra114_gic_cpu_pm_registration(void) { }
 #endif
 
 void __init tegra_init_irq(void)
@@ -252,4 +290,6 @@ void __init tegra_init_irq(void)
 	if (!of_have_populated_dt())
 		gic_init(0, 29, distbase,
 			IO_ADDRESS(TEGRA_ARM_PERIF_BASE + 0x100));
+
+	tegra114_gic_cpu_pm_registration();
 }
-- 
1.8.3.2



From oleksandr.kozaruk at ti.com  Fri Jul 19 05:27:18 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Fri, 19 Jul 2013 12:27:18 +0300
Subject: [PATCH v6 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <1374226039-16943-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1374226039-16943-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1374226039-16943-2-git-send-email-oleksandr.kozaruk@ti.com>

GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.

Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..d7d4c28 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
 		compatible = "ti,twl6030-pwmled";
 		#pwm-cells = <2>;
 	};
+
+	adc: gpadc {
+		compatible = "ti,twl6030-gpadc";
+		interrupts = <3>;
+		#io-channel-cells = <1>;
+	};
 };
-- 
1.8.1.2



From oleksandr.kozaruk at ti.com  Fri Jul 19 05:27:17 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Fri, 19 Jul 2013 12:27:17 +0300
Subject: [PATCH v6 0/2] TWL6030, TWL6032 GPADC driver
Message-ID: <1374226039-16943-1-git-send-email-oleksandr.kozaruk@ti.com>

Hello,

v6 - addressed comments about trim bits, checkpatch clean up
v5 - gpadc DT node renamed from "gpadc" to generic "adc", added
     temperature channels; raw code is corracted with calibration
     data.
v4 - addressed comments: fixed style violation, bug in freeing memory,
     added comments explaining calibration method, removed test network
     channels from exposing to userspace, error handling for 
     wait_for_complition
v3 - fixed compiler warning
v2 - the driver put in drivers/iio, and
converted using iio facilities as suggested by Graeme.

TWL603[02] GPADC is used to measure battery voltage,
battery temperature, battery presence ID, and could
be used to measure twl603[02] die temperature.
This is used on TI blaze, blaze tablet platforms.

The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19
channels respectively. Some channels have current
source and are used for measuring voltage drop
on resistive load for detecting battery ID resistance,
or measuring voltage drop on NTC resistors for external
temperature measurements, other channels measure voltage,
(i.e. battery voltage), and have inbuilt voltage dividers,
thus, capable to scale voltage. Some channels are dedicated
for measuring die temperature.

Some channels could be calibrated in 2 points, having
offsets from ideal values in trim registers.

The difference between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i. e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

The driver is derived from git://git.omapzoom.org/kernel/omap.git
The original driver's authors and contributors are Balaji T K,
Graeme Gregory, Ambresh K, Girish S Ghongdemath.

The changes to the original driver:
- device tree adaptation;
- drop ioctl support - never been used;
- unified measurement method for both devices;
- get rid of "if (device == X)" code style to data driven;
- drop polling end of conversion and use interrupt instead;
- iio framework is used

Tested with on blaze tablet 2 with OMAP4430(twl6030), and
OMAP4470(twl6032) SOMs.

The patches were tested against 3.10-rc7

Oleksandr Kozaruk (2):
  ARM: dts: twl: Add GPADC data to device tree
  iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

 arch/arm/boot/dts/twl6030.dtsi  |   6 +
 drivers/iio/adc/Kconfig         |  14 +
 drivers/iio/adc/Makefile        |   1 +
 drivers/iio/adc/twl6030-gpadc.c | 991 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 1012 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

-- 
1.8.1.2



From oleksandr.kozaruk at ti.com  Fri Jul 19 05:27:19 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Fri, 19 Jul 2013 12:27:19 +0300
Subject: [PATCH v6 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <1374226039-16943-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1374226039-16943-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1374226039-16943-3-git-send-email-oleksandr.kozaruk@ti.com>

The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
known also as Phoenix and PhoenixLite.

The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
respectively. Some channels have current source and are used for
measuring voltage drop on resistive load for detecting battery ID
resistance, or measuring voltage drop on NTC resistors for external
temperature measurements. Some channels measure voltage, (i.e. battery
voltage), and have voltage dividers, thus, capable to scale voltage.
Some channels are dedicated for measuring die temperature.

Some channels are calibrated in 2 points, having offsets from ideal
values kept in trim registers. This is used to correct measurements.

The differences between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i.e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
Girish S Ghongdemath.

Signed-off-by: Balaji T K <balajitk at ti.com>
Signed-off-by: Graeme Gregory <gg at slimlogic.co.uk>
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 drivers/iio/adc/Kconfig         |  14 +
 drivers/iio/adc/Makefile        |   1 +
 drivers/iio/adc/twl6030-gpadc.c | 991 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 1006 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index ab0767e6..3172461 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -150,6 +150,20 @@ config TI_AM335X_ADC
 	  Say yes here to build support for Texas Instruments ADC
 	  driver which is also a MFD client.
 
+config TWL6030_GPADC
+	tristate "TWL6030 GPADC (General Purpose A/D Converter) Support"
+	depends on TWL4030_CORE
+	default n
+	help
+	  Say yes here if you want support for the TWL6030/TWL6032 General
+	  Purpose A/D Converter. This will add support for battery type
+	  detection, battery voltage and temperature measurement, die
+	  temperature measurement, system supply voltage, audio accessory,
+	  USB ID detection.
+
+	  This driver can also be built as a module. If so, the module will be
+	  called twl6030-gpadc.
+
 config VIPERBOARD_ADC
 	tristate "Viperboard ADC support"
 	depends on MFD_VIPERBOARD && USB
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 0a825be..996ba09 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -16,4 +16,5 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
 obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
+obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
 obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
new file mode 100644
index 0000000..b42cfd6
--- /dev/null
+++ b/drivers/iio/adc/twl6030-gpadc.c
@@ -0,0 +1,991 @@
+/*
+ * TWL6030 GPADC module driver
+ *
+ * Copyright (C) 2009-2013 Texas Instruments Inc.
+ * Nishant Kamat <nskamat at ti.com>
+ * Balaji T K <balajitk at ti.com>
+ * Graeme Gregory <gg at slimlogic.co.uk>
+ * Girish S Ghongdemath <girishsg at ti.com>
+ * Ambresh K <ambresh at ti.com>
+ * Oleksandr Kozaruk <oleksandr.kozaruk at ti.com
+ *
+ * Based on twl4030-madc.c
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen <mikko.k.ylinen at nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of_platform.h>
+#include <linux/i2c/twl.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define DRIVER_NAME		"twl6030_gpadc"
+
+#define TWL6030_GPADC_MAX_CHANNELS 17
+#define TWL6032_GPADC_MAX_CHANNELS 19
+
+#define TWL6030_GPADC_CTRL_P1			0x05
+
+#define TWL6032_GPADC_GPSELECT_ISB		0x07
+#define TWL6032_GPADC_CTRL_P1			0x08
+
+#define TWL6032_GPADC_GPCH0_LSB			0x0d
+#define TWL6032_GPADC_GPCH0_MSB			0x0e
+
+#define TWL6030_GPADC_CTRL_P1_SP1		BIT(3)
+
+#define TWL6030_GPADC_GPCH0_LSB			(0x29)
+
+#define TWL6030_GPADC_RT_SW1_EOC_MASK		BIT(5)
+
+#define TWL6030_GPADC_TRIM1			0xCD
+
+#define TWL6030_REG_TOGGLE1			0x90
+#define TWL6030_GPADCS				BIT(1)
+#define TWL6030_GPADCR				BIT(0)
+
+/**
+ * struct twl6030_chnl_calib - channel calibration
+ * @gain:		slope coefficient for ideal curve
+ * @gain_error:		gain error
+ * @offset_error:	offset of the real curve
+ */
+struct twl6030_chnl_calib {
+	s32 gain;
+	s32 gain_error;
+	s32 offset_error;
+};
+
+/**
+ * struct twl6030_ideal_code - GPADC calibration parameters
+ * GPADC is calibrated in two points: close to the beginning and
+ * to the and of the measurable input range
+ *
+ * @code1:	ideal code for the input at the beginning
+ * @code2:	ideal code for at the end of the range
+ * @volt1:	voltage input at the beginning(low voltage)
+ * @volt2:	voltage input at the end(high voltage)
+ */
+struct twl6030_ideal_code {
+	u16 code1;
+	u16 code2;
+	u16 volt1;
+	u16 volt2;
+};
+
+struct twl6030_gpadc_data;
+
+/**
+ * struct twl6030_gpadc_platform_data - platform specific data
+ * @nchannels:		number of GPADC channels
+ * @iio_channels:	iio channels
+ * @twl6030_ideal:	pointer to calibration parameters
+ * @start_conversion:	pointer to ADC start conversion function
+ * @channel_to_reg	pointer to ADC function to convert channel to
+ *			register address for reading conversion result
+ * @calibrate:		pointer to calibration function
+ */
+struct twl6030_gpadc_platform_data {
+	const int nchannels;
+	const struct iio_chan_spec *iio_channels;
+	const struct twl6030_ideal_code *ideal;
+	int (*start_conversion)(int channel);
+	u8 (*channel_to_reg)(int channel);
+	int (*calibrate)(struct twl6030_gpadc_data *gpadc);
+};
+
+/**
+ * struct twl6030_gpadc_data - GPADC data
+ * @dev:		device pointer
+ * @lock:		mutual exclusion lock for the structure
+ * @irq_complete:	completion to signal end of conversion
+ * @twl6030_cal_tbl:	pointer to calibration data for each
+ *			channel with gain error and offset
+ * @pdata:		pointer to device specific data
+ */
+struct twl6030_gpadc_data {
+	struct device	*dev;
+	struct mutex	lock;
+	struct completion	irq_complete;
+	struct twl6030_chnl_calib	*twl6030_cal_tbl;
+	const struct twl6030_gpadc_platform_data *pdata;
+};
+
+/*
+ * channels 11, 12, 13, 15 and 16 have no calibration data
+ * calibration offset is same for channels 1, 3, 4, 5
+ *
+ * The data is taken from GPADC_TRIM registers description.
+ * GPADC_TRIM registers keep difference between the code measured
+ * at volt1 and volt2 input voltages and corresponding code1 and code2
+ */
+static const struct twl6030_ideal_code
+	twl6030_ideal[TWL6030_GPADC_MAX_CHANNELS] = {
+	[0] = { /* ch 0, external, battery type, resistor value */
+		.code1 = 116,
+		.code2 = 745,
+		.volt1 = 141,
+		.volt2 = 910,
+	},
+	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[2] = { /* ch 2, external, audio accessory/general purpose */
+		.code1 = 55,
+		.code2 = 818,
+		.volt1 = 101,
+		.volt2 = 1499,
+	},
+	[3] = { /* ch 3, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[4] = { /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[5] = { /* ch 5, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[6] = { /* ch 6, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[7] = { /* ch 7, internal, main battery */
+		.code1 = 614,
+		.code2 = 941,
+		.volt1 = 3001,
+		.volt2 = 4599,
+	},
+	[8] = { /* ch 8, internal, backup battery */
+		.code1 = 82,
+		.code2 = 688,
+		.volt1 = 501,
+		.volt2 = 4203,
+	},
+	[9] = { /* ch 9, internal, external charger input */
+		.code1 = 182,
+		.code2 = 818,
+		.volt1 = 2001,
+		.volt2 = 8996,
+	},
+	[10] = { /* ch 10, internal, VBUS */
+		.code1 = 149,
+		.code2 = 818,
+		.volt1 = 1001,
+		.volt2 = 5497,
+	},
+	[11] = {},	/* ch 11, internal, VBUS charging current */
+	[12] = {},	/* ch 12, internal, Die temperature */
+	[13] = {},	/* ch 13, internal, Die temperature */
+	[14] = { /* ch 14, internal, USB ID line */
+		.code1 = 48,
+		.code2 = 714,
+		.volt1 = 323,
+		.volt2 = 4800,
+	},
+	[15] = {},	/* ch 15, internal, test network */
+	[16] = {},	/* ch 16, internal, test network */
+};
+
+static const struct twl6030_ideal_code
+			twl6032_ideal[TWL6032_GPADC_MAX_CHANNELS] = {
+	[0] = { /* ch 0, external, battery type, resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[2] = { /* ch 2, external, audio accessory/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 660,
+		.volt2 = 1500,
+	},
+	[3] = { /* ch 3, external, temperature with external diode/general
+								purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[4] = { /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[5] = { /* ch 5, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[6] = { /* ch 6, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[7] = { /* ch7, internal, system supply */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+	[8] = { /* ch8, internal, backup battery */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+	[9] = { /* ch 9, internal, external charger input */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 3960,
+		.volt2 = 9000,
+	},
+	[10] = { /* ch10, internal, VBUS */
+		.code1 = 150,
+		.code2 = 751,
+		.volt1 = 1000,
+		.volt2 = 5000,
+	},
+	[11] = { /* ch 11, internal, VBUS DC-DC output current */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 660,
+		.volt2 = 1500,
+	},
+	[12] = { /* ch 12, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[13] = { /* ch 13, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[14] = { /* ch 14, internal, USB ID line */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2420,
+		.volt2 = 5500,
+	},
+	[15] = {},	/* ch 15, internal, test network */
+	[16] = {},	/* ch 16, internal, test network */
+	[17] = {},	/* ch 17, internal, battery charging current */
+	[18] = { /* ch 18, internal, battery voltage */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+};
+
+static inline int twl6030_gpadc_write(u8 reg, u8 val)
+{
+	return twl_i2c_write_u8(TWL6030_MODULE_GPADC, val, reg);
+}
+
+static inline int twl6030_gpadc_read(u8 reg, u8 *val)
+{
+
+	return twl_i2c_read(TWL6030_MODULE_GPADC, val, reg, 2);
+}
+
+static int twl6030_gpadc_enable_irq(u8 mask)
+{
+	int ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_LINE_B);
+	if (ret < 0)
+		return ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_STS_B);
+
+	return ret;
+}
+
+static void twl6030_gpadc_disable_irq(u8 mask)
+{
+	twl6030_interrupt_mask(mask, REG_INT_MSK_LINE_B);
+	twl6030_interrupt_mask(mask, REG_INT_MSK_STS_B);
+}
+
+static irqreturn_t twl6030_gpadc_irq_handler(int irq, void *indio_dev)
+{
+	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
+
+	complete(&gpadc->irq_complete);
+
+	return IRQ_HANDLED;
+}
+
+static int twl6030_start_conversion(int channel)
+{
+	return twl6030_gpadc_write(TWL6030_GPADC_CTRL_P1,
+					TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static int twl6032_start_conversion(int channel)
+{
+	int ret;
+
+	ret = twl6030_gpadc_write(TWL6032_GPADC_GPSELECT_ISB, channel);
+	if (ret)
+		return ret;
+
+	return twl6030_gpadc_write(TWL6032_GPADC_CTRL_P1,
+						TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static u8 twl6030_channel_to_reg(int channel)
+{
+	return TWL6030_GPADC_GPCH0_LSB + 2 * channel;
+}
+
+static u8 twl6032_channel_to_reg(int channel)
+{
+	/*
+	 * for any prior chosen channel, when the conversion is ready
+	 * the result is avalable in GPCH0_LSB, GPCH0_MSB.
+	 */
+
+	return TWL6032_GPADC_GPCH0_LSB;
+}
+
+static int twl6030_channel_calibrated(const struct twl6030_gpadc_platform_data
+		*pdata, int channel)
+{
+	/* not calibrated channels have 0 in all structure members */
+	return pdata->ideal[channel].code2;
+}
+
+static int twl6030_gpadc_make_correction(struct twl6030_gpadc_data *gpadc,
+		int channel, int raw_code)
+{
+	int corrected_code;
+
+	corrected_code = ((raw_code * 1000) -
+		gpadc->twl6030_cal_tbl[channel].offset_error) /
+		gpadc->twl6030_cal_tbl[channel].gain_error;
+
+	return corrected_code;
+}
+
+static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
+		int channel, int *res)
+{
+	u8 reg = gpadc->pdata->channel_to_reg(channel);
+	__le16 val;
+	int raw_code;
+	int ret;
+
+	ret = twl6030_gpadc_read(reg, (u8 *)&val);
+	if (ret) {
+		dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
+		return ret;
+	}
+
+	raw_code = le16_to_cpu(val);
+	dev_dbg(gpadc->dev, "GPADC raw code: %d", raw_code);
+
+	if (twl6030_channel_calibrated(gpadc->pdata, channel))
+		*res = twl6030_gpadc_make_correction(gpadc, channel, raw_code);
+	else
+		*res = raw_code;
+
+	return ret;
+}
+
+static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
+		int channel, int *val)
+{
+	int corrected_code;
+	int channel_value;
+	int ret;
+
+	ret = twl6030_gpadc_get_raw(gpadc, channel, &corrected_code);
+	if (ret)
+		return ret;
+
+	channel_value = corrected_code *
+			gpadc->twl6030_cal_tbl[channel].gain;
+
+	/* Shift back into mV range */
+	channel_value /= 1000;
+
+	dev_dbg(gpadc->dev, "GPADC corrected code: %d", corrected_code);
+	dev_dbg(gpadc->dev, "GPADC value: %d", channel_value);
+
+	*val = channel_value;
+
+	return ret;
+}
+
+static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
+			     const struct iio_chan_spec *chan,
+			     int *val, int *val2, long mask)
+{
+	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
+	int ret = -EINVAL;
+	long timeout;
+
+	mutex_lock(&gpadc->lock);
+
+	ret = gpadc->pdata->start_conversion(chan->channel);
+	if (ret) {
+		dev_err(gpadc->dev, "failed to start conversion\n");
+		goto err;
+	}
+	/* wait for conversion to complete */
+	timeout = wait_for_completion_interruptible_timeout(
+				&gpadc->irq_complete, msecs_to_jiffies(5000));
+	if (!timeout) {
+		ret = -ETIMEDOUT;
+		goto err;
+	} else if (timeout < 0) {
+		goto err;
+		ret = -EINTR;
+	}
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	case IIO_CHAN_INFO_PROCESSED:
+		ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	default:
+		break;
+	}
+err:
+	mutex_unlock(&gpadc->lock);
+
+	return ret;
+}
+
+/*
+ * The GPADC channels are calibrated using a two point calibration method.
+ * The channels measured with two known values: volt1 and volt2, and
+ * ideal corresponding output codes are known: code1, code2.
+ * The difference(d1, d2) between ideal and measured codes stored in trim
+ * registers.
+ * The goal is to find offset and gain of the real curve for each calibrated
+ * channel.
+ * gain: k = 1 + ((d2 - d1) / (x2 - x1))
+ * offset: b = d1 + (k - 1) * x1
+ */
+static void twl6030_calibrate_channel(struct twl6030_gpadc_data *gpadc,
+					int channel, int d1, int d2)
+{
+	int b, k, gain, x1, x2;
+	const struct twl6030_ideal_code *ideal = gpadc->pdata->ideal;
+
+	/* Gain */
+	gain = ((ideal[channel].volt2 - ideal[channel].volt1) * 1000) /
+		(ideal[channel].code2 - ideal[channel].code1);
+
+	x1 = ideal[channel].code1;
+	x2 = ideal[channel].code2;
+
+	/* k - real curve gain */
+	k = 1000 + (((d2 - d1) * 1000) / (x2 - x1));
+
+	/* b - offset of the real curve gain */
+	b = (d1 * 1000) - (k - 1000) * x1;
+
+	gpadc->twl6030_cal_tbl[channel].gain = gain;
+	gpadc->twl6030_cal_tbl[channel].gain_error = k;
+	gpadc->twl6030_cal_tbl[channel].offset_error = b;
+
+	dev_dbg(gpadc->dev, "GPADC d1   for Chn: %d = %d\n", channel, d1);
+	dev_dbg(gpadc->dev, "GPADC d2   for Chn: %d = %d\n", channel, d2);
+	dev_dbg(gpadc->dev, "GPADC x1   for Chn: %d = %d\n", channel, x1);
+	dev_dbg(gpadc->dev, "GPADC x2   for Chn: %d = %d\n", channel, x2);
+	dev_dbg(gpadc->dev, "GPADC Gain for Chn: %d = %d\n", channel, gain);
+	dev_dbg(gpadc->dev, "GPADC k    for Chn: %d = %d\n", channel, k);
+	dev_dbg(gpadc->dev, "GPADC b    for Chn: %d = %d\n", channel, b);
+}
+
+static inline int twl6030_gpadc_get_trim_offset(s8 d)
+{
+	/*
+	 * XXX NOTE!
+	 * bit 0 - sign, bit 7 - reserved, 6..1 - trim value
+	 * though, the documentation states that trim value
+	 * is absolute value, the correct conversion results are
+	 * obtained if the value is interpreted as 2's complement.
+	 */
+	__u32 temp = ((d & 0x7f) >> 1) | ((d & 1) << 6);
+
+	return sign_extend32(temp, 6);
+}
+
+static int twl6030_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int ret;
+	int chn;
+	u8 trim_regs[TWL6030_GPADC_MAX_CHANNELS];
+	s8 d1, d2;
+
+	/*
+	 * for calibration two measurements have been performed at
+	 * factory, for some channels, during the production test and
+	 * have been stored in registers. This two stored values are
+	 * used to correct the measurements. The values represent
+	 * offsets for the given input from the output on ideal curve.
+	 */
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs,
+			TWL6030_GPADC_TRIM1, 16);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	for (chn = 0; chn < TWL6030_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+			d1 = trim_regs[0];
+			d2 = trim_regs[1];
+			break;
+		case 1:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+			d1 = trim_regs[4];
+			d2 = trim_regs[5];
+			break;
+		case 2:
+			d1 = trim_regs[12];
+			d2 = trim_regs[13];
+			break;
+		case 7:
+			d1 = trim_regs[6];
+			d2 = trim_regs[7];
+			break;
+		case 8:
+			d1 = trim_regs[2];
+			d2 = trim_regs[3];
+			break;
+		case 9:
+			d1 = trim_regs[8];
+			d2 = trim_regs[9];
+			break;
+		case 10:
+			d1 = trim_regs[10];
+			d2 = trim_regs[11];
+			break;
+		case 14:
+			d1 = trim_regs[14];
+			d2 = trim_regs[15];
+			break;
+		default:
+			continue;
+		}
+
+		d1 = twl6030_gpadc_get_trim_offset(d1);
+		d2 = twl6030_gpadc_get_trim_offset(d2);
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+static int twl6032_get_trim_value(u8 *trim_regs, unsigned int reg0,
+		unsigned int reg1, unsigned int mask0, unsigned int mask1,
+		unsigned int shift0)
+{
+	int val;
+
+	val = (trim_regs[reg0] & mask0) << shift0;
+	val |= (trim_regs[reg1] & mask1) >> 1;
+	if (trim_regs[reg1] & 0x01)
+		val = -val;
+
+	return val;
+}
+
+static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int chn, d1 = 0, d2 = 0, temp;
+	u8 trim_regs[17];
+	int ret;
+
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
+			TWL6030_GPADC_TRIM1, 16);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	/*
+	 * Loop to calculate the value needed for returning voltages from
+	 * GPADC not values.
+	 *
+	 * gain is calculated to 3 decimal places fixed point.
+	 */
+	for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+		case 1:
+		case 2:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+		case 11:
+		case 12:
+		case 13:
+		case 14:
+			d1 = twl6032_get_trim_value(trim_regs, 3, 1, 0x1f,
+								0x06, 2);
+			d2 = twl6032_get_trim_value(trim_regs, 4, 2, 0x3f,
+								0x06, 2);
+			break;
+		case 8:
+			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x1f,
+								0x06, 2);
+			d1 = temp + twl6032_get_trim_value(trim_regs, 8, 7,
+								0x18, 0x1E, 1);
+
+			temp = twl6032_get_trim_value(trim_regs, 4, 2, 0x3F,
+								0x06, 2);
+			d2 = temp + twl6032_get_trim_value(trim_regs, 10, 8,
+								0x1F, 0x06, 2);
+			break;
+		case 9:
+			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x1f,
+								0x06, 2);
+			d1 = temp + twl6032_get_trim_value(trim_regs, 14, 12,
+								0x18, 0x1E, 1);
+
+			temp = twl6032_get_trim_value(trim_regs, 4, 2, 0x3f,
+								0x06, 2);
+			d2 = temp + twl6032_get_trim_value(trim_regs, 16, 14,
+								0x1F, 0x06, 1);
+			break;
+		case 10:
+			d1 = twl6032_get_trim_value(trim_regs, 11, 9, 0x0f,
+								0x0E, 3);
+			d2 = twl6032_get_trim_value(trim_regs, 15, 13, 0x0f,
+								0x0E, 3);
+			break;
+		case 7:
+		case 18:
+			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x1f,
+								0x06, 2);
+
+			d1 = (trim_regs[5] & 0x7E) >> 1;
+			if (trim_regs[5] & 0x01)
+				d1 = -d1;
+			d1 += temp;
+
+			temp = twl6032_get_trim_value(trim_regs, 4, 2, 0x3f,
+								0x06, 2);
+
+			d2 = (trim_regs[6] & 0xFE) >> 1;
+			if (trim_regs[6] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		default:
+			/* No data for other channels */
+			continue;
+		}
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+#define TWL6030_GPADC_CHAN(chn, _type, chan_info) {	\
+	.type = _type,					\
+	.channel = chn,					\
+	.info_mask_separate = BIT(chan_info),		\
+	.indexed = 1,					\
+}
+
+/* internal test network channel */
+#define TWL6030_GPADC_TEST_CHAN(chn, chan_info) {	\
+	.type = IIO_VOLTAGE,				\
+	.channel = chn,					\
+	.indexed = 1,					\
+}
+
+static const struct iio_chan_spec twl6030_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(2, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(5, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(12, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(13, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(14, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_TEST_CHAN(15, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_TEST_CHAN(16, IIO_CHAN_INFO_RAW),
+};
+
+static const struct iio_chan_spec twl6032_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(2, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(5, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(12, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(13, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(14, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_TEST_CHAN(15, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_TEST_CHAN(16, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(17, IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(18, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+};
+
+static const struct iio_info twl6030_gpadc_iio_info = {
+	.read_raw = &twl6030_gpadc_read_raw,
+	.driver_module = THIS_MODULE,
+};
+
+static const struct twl6030_gpadc_platform_data twl6030_pdata = {
+	.iio_channels = twl6030_gpadc_iio_channels,
+	.nchannels = TWL6030_GPADC_MAX_CHANNELS,
+	.ideal = twl6030_ideal,
+	.start_conversion = twl6030_start_conversion,
+	.channel_to_reg = twl6030_channel_to_reg,
+	.calibrate = twl6030_calibration,
+};
+
+static const struct twl6030_gpadc_platform_data twl6032_pdata = {
+	.iio_channels = twl6032_gpadc_iio_channels,
+	.nchannels = TWL6032_GPADC_MAX_CHANNELS,
+	.ideal = twl6032_ideal,
+	.start_conversion = twl6032_start_conversion,
+	.channel_to_reg = twl6032_channel_to_reg,
+	.calibrate = twl6032_calibration,
+};
+
+static const struct of_device_id of_twl6030_match_tbl[] = {
+	{
+		.compatible = "ti,twl6030-gpadc",
+		.data = &twl6030_pdata,
+	},
+	{
+		.compatible = "ti,twl6032-gpadc",
+		.data = &twl6032_pdata,
+	},
+	{ /* end */ }
+};
+
+static int twl6030_gpadc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct twl6030_gpadc_data *gpadc;
+	const struct twl6030_gpadc_platform_data *pdata;
+	const struct of_device_id *match;
+	struct iio_dev *indio_dev;
+	int irq;
+	int ret;
+
+	match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
+	if (!match)
+		return -EINVAL;
+
+	pdata = match->data;
+
+	indio_dev = iio_device_alloc(sizeof(*gpadc));
+	if (!indio_dev) {
+		dev_err(dev, "failed allocating iio device\n");
+		ret = -ENOMEM;
+	}
+
+	gpadc = iio_priv(indio_dev);
+
+	gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
+					sizeof(struct twl6030_chnl_calib) *
+					pdata->nchannels, GFP_KERNEL);
+	if (!gpadc->twl6030_cal_tbl)
+		goto err_free_device;
+
+	gpadc->dev = dev;
+	gpadc->pdata = pdata;
+
+	platform_set_drvdata(pdev, indio_dev);
+	mutex_init(&gpadc->lock);
+	init_completion(&gpadc->irq_complete);
+
+	ret = pdata->calibrate(gpadc);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to read calibration registers\n");
+		goto err_free_device;
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "failed to get irq\n");
+		goto err_free_device;
+	}
+
+	ret = request_threaded_irq(irq, NULL, twl6030_gpadc_irq_handler,
+				IRQF_ONESHOT, "twl6030_gpadc", indio_dev);
+	if (ret) {
+		dev_dbg(&pdev->dev, "could not request irq\n");
+		goto err_free_device;
+	}
+
+	ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
+		goto err_free_irq;
+	}
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+					TWL6030_REG_TOGGLE1);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC module\n");
+		goto err_free_irq;
+	}
+
+	indio_dev->name = DRIVER_NAME;
+	indio_dev->dev.parent = dev;
+	indio_dev->info = &twl6030_gpadc_iio_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->channels = pdata->iio_channels;
+	indio_dev->num_channels = pdata->nchannels;
+
+	ret = iio_device_register(indio_dev);
+	if (ret)
+		goto err_free_irq;
+
+	return ret;
+
+err_free_irq:
+	free_irq(irq, indio_dev);
+err_free_device:
+	iio_device_free(indio_dev);
+
+	return ret;
+}
+
+static int twl6030_gpadc_remove(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+
+	twl6030_gpadc_disable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	free_irq(platform_get_irq(pdev, 0), indio_dev);
+	iio_device_unregister(indio_dev);
+	iio_device_free(indio_dev);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int twl6030_gpadc_suspend(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCR,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error reseting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+
+static int twl6030_gpadc_resume(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error setting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+#endif
+
+static SIMPLE_DEV_PM_OPS(twl6030_gpadc_pm_ops, twl6030_gpadc_suspend,
+					twl6030_gpadc_resume);
+
+static struct platform_driver twl6030_gpadc_driver = {
+	.probe		= twl6030_gpadc_probe,
+	.remove		= twl6030_gpadc_remove,
+	.driver		= {
+		.name	= DRIVER_NAME,
+		.owner	= THIS_MODULE,
+		.pm	= &twl6030_gpadc_pm_ops,
+		.of_match_table = of_twl6030_match_tbl,
+	},
+};
+
+module_platform_driver(twl6030_gpadc_driver);
+
+MODULE_ALIAS("platform: " DRIVER_NAME);
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_DESCRIPTION("twl6030 ADC driver");
+MODULE_LICENSE("GPL");
-- 
1.8.1.2



From josephl at nvidia.com  Fri Jul 19 05:29:12 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 19 Jul 2013 17:29:12 +0800
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <51E7E27B.9090605@linaro.org>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
 <51E6FF0B.5000708@wwwdotorg.org>
 <1374145726.5610.73.camel@jlo-ubuntu-64.nvidia.com>
 <51E7E27B.9090605@linaro.org>
Message-ID: <1374226153.24607.3.camel@jlo-ubuntu-64.nvidia.com>

On Thu, 2013-07-18 at 20:41 +0800, Daniel Lezcano wrote:
> On 07/18/2013 01:08 PM, Joseph Lo wrote:
> > On Thu, 2013-07-18 at 04:31 +0800, Stephen Warren wrote:
> >> On 07/17/2013 04:15 AM, Joseph Lo wrote:
> >>> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
> >>>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
> >>>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
> >>>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
> >>>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
> >>>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
> >>>>>>> this state.
> >> ... [ discussion of issues with Joesph's patches applied]
> >>>
> >> 2) If I run the hotplug test script, leaving CPU 0 always present, I
> >> sometimes see:
> >>
> >>> root at localhost:~# for i in `seq 1 50`; do echo ITERATION $i; ./cpuonline.py; done
> >>> ITERATION 1
> >>> echo 0 > /sys/devices/system/cpu/cpu2/online
> >>> [  458.910054] CPU2: shutdown
> >>> echo 0 > /sys/devices/system/cpu/cpu1/online
> >>> [  461.004371] CPU1: shutdown
> >>> echo 0 > /sys/devices/system/cpu/cpu3/online
> >>> [  463.027341] CPU3: shutdown
> >>> echo 1 > /sys/devices/system/cpu/cpu1/online
> >>> [  465.061412] CPU1: Booted secondary processor
> >>> echo 1 > /sys/devices/system/cpu/cpu2/online
> >>> [  467.095313] CPU2: Booted secondary processor
> >>> [  467.113243] ------------[ cut here ]------------
> >>> [  467.117948] WARNING: CPU: 2 PID: 0 at kernel/time/tick-broadcast.c:667 tick_broadcast_oneshot_control+0x19c/0x1c4()
> >>> [  467.128352] Modules linked in:
> >>> [  467.131455] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.11.0-rc1-00022-g7487363-dirty #49
> >>> [  467.139678] [<c0015620>] (unwind_backtrace+0x0/0xf8) from [<c001154c>] (show_stack+0x10/0x14)
> >>> [  467.148228] [<c001154c>] (show_stack+0x10/0x14) from [<c05135a8>] (dump_stack+0x80/0xc4)
> >>> [  467.156336] [<c05135a8>] (dump_stack+0x80/0xc4) from [<c0024590>] (warn_slowpath_common+0x64/0x88)
> >>> [  467.165300] [<c0024590>] (warn_slowpath_common+0x64/0x88) from [<c00245d0>] (warn_slowpath_null+0x1c/0x24)
> >>> [  467.174959] [<c00245d0>] (warn_slowpath_null+0x1c/0x24) from [<c00695e4>] (tick_broadcast_oneshot_control+0x19c/0x1c4)
> >>> [  467.185659] [<c00695e4>] (tick_broadcast_oneshot_control+0x19c/0x1c4) from [<c0067cdc>] (clockevents_notify+0x1b0/0x1dc)
> >>> [  467.196538] [<c0067cdc>] (clockevents_notify+0x1b0/0x1dc) from [<c034f348>] (cpuidle_idle_call+0x11c/0x168)
> >>> [  467.206292] [<c034f348>] (cpuidle_idle_call+0x11c/0x168) from [<c000f134>] (arch_cpu_idle+0x8/0x38)
> >>> [  467.215359] [<c000f134>] (arch_cpu_idle+0x8/0x38) from [<c0061038>] (cpu_startup_entry+0x60/0x134)
> >>> [  467.224325] [<c0061038>] (cpu_startup_entry+0x60/0x134) from [<800083d8>] (0x800083d8)
> >>> [  467.232227] ---[ end trace ea579be22a00e7fb ]---
> >>> echo 0 > /sys/devices/system/cpu/cpu1/online
> >>> [  469.126682] CPU1: shutdown
> >
> > Hmm. It's hard to reproduce. But finally, I also can repro with CPU
> > hotplug stress test. And some strange issues after apply
> > CPUIDLE_FLAG_TIMER_STOP on Tegra20, can we postpone to apply this?
> > I need more time to investigate how does this flag impact system.
> >
> 
Daniel,

How do you think about this fix?

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index d75040d..0b8878b 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -81,8 +81,16 @@ int cpuidle_enter_state(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
 
        time_start = ktime_get();
 
+       if (drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP)
+               clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER,
+                                  &dev->cpu);
+
        entered_state = target_state->enter(dev, drv, index);
 
+       if (drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP)
+               clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT,
+                                  &dev->cpu);
+
        time_end = ktime_get();
 
        local_irq_enable();
@@ -144,20 +152,12 @@ int cpuidle_idle_call(void)
 
        trace_cpu_idle_rcuidle(next_state, dev->cpu);
 
-       if (drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP)
-               clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER,
-                                  &dev->cpu);
-
        if (cpuidle_state_is_coupled(dev, drv, next_state))
                entered_state = cpuidle_enter_state_coupled(dev, drv,
                                                            next_state);
        else
                entered_state = cpuidle_enter_state(dev, drv,
next_state);
 
-       if (drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP)
-               clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT,
-                                  &dev->cpu);
-
        trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
 
        /* give the governor an opportunity to reflect on the outcome */



From gsi at denx.de  Fri Jul 19 05:41:43 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Fri, 19 Jul 2013 11:41:43 +0200
Subject: [PATCH v2 16/24] net: can: mscan: make mpc512x code use common
 clock
In-Reply-To: <51E8EC17.9060703@pengutronix.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374178858-8683-2-git-send-email-gsi@denx.de>
 <51E8EC17.9060703@pengutronix.de>
Message-ID: <20130719094143.GQ7080@book.gsilab.sittig.org>

On Fri, Jul 19, 2013 at 09:34 +0200, Marc Kleine-Budde wrote:
> 
> On 07/18/2013 10:20 PM, Gerhard Sittig wrote:
> > extend the mscan(4) driver with alternative support for the COMMON_CLK
> > approach which is an option in the MPC512x platform, keep the existing
> > clock support implementation in place since the driver is shared with
> > other MPC5xxx SoCs which don't have common clock support
> > 
> > one byproduct of this change is that the CAN driver no longer needs to
> > access the SoC's clock control registers, which shall be the domain of
> > the platform's clock driver
> > 
> > Signed-off-by: Gerhard Sittig <gsi at denx.de>
> > ---
> >  drivers/net/can/mscan/mpc5xxx_can.c |  139 +++++++++++++++++++++++++++++++++++
> >  1 file changed, 139 insertions(+)
> > 
> > diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
> > index bc422ba..dd26ab6 100644
> > --- a/drivers/net/can/mscan/mpc5xxx_can.c
> > +++ b/drivers/net/can/mscan/mpc5xxx_can.c
> > @@ -108,6 +108,143 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
> >  #endif /* CONFIG_PPC_MPC52xx */
> >  
> >  #ifdef CONFIG_PPC_MPC512x
> > +
> > +#if IS_ENABLED(CONFIG_COMMON_CLK)
> > +
> > +static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
> > +				 const char *clock_source, int *mscan_clksrc)
> > +{
> > +	struct device_node *np;
> > +	u32 clockdiv;
> > +	enum {
> > +		CLK_FROM_AUTO,
> > +		CLK_FROM_IPS,
> > +		CLK_FROM_SYS,
> > +		CLK_FROM_REF,
> > +	} clk_from;
> > +	struct clk *clk_in, *clk_can;
> > +	unsigned long freq_calc;
> > +
> > +	/* the caller passed in the clock source spec that was read from
> > +	 * the device tree, get the optional clock divider as well
> > +	 */
> > +	np = ofdev->dev.of_node;
> > +	clockdiv = 1;
> > +	of_property_read_u32(np, "fsl,mscan-clock-divider", &clockdiv);
> > +	dev_dbg(&ofdev->dev, "device tree specs: clk src[%s] div[%d]\n",
> > +		clock_source ? clock_source : "<NULL>", clockdiv);
> > +
> > +	/* when clock-source is 'ip', the CANCTL1[CLKSRC] bit needs to
> > +	 * get set, and the 'ips' clock is the input to the MSCAN
> > +	 * component
> > +	 *
> > +	 * for clock-source values of 'ref' or 'sys' the CANCTL1[CLKSRC]
> > +	 * bit needs to get cleared, an optional clock-divider may have
> > +	 * been specified (the default value is 1), the appropriate
> > +	 * MSCAN related MCLK is the input to the MSCAN component
> > +	 *
> > +	 * in the absence of a clock-source spec, first an optimal clock
> > +	 * gets determined based on the 'sys' clock, if that fails the
> > +	 * 'ref' clock is used
> > +	 */
> > +	clk_from = CLK_FROM_AUTO;
> > +	if (clock_source) {
> > +		/* interpret the device tree's spec for the clock source */
> > +		if (!strcmp(clock_source, "ip"))
> > +			clk_from = CLK_FROM_IPS;
> > +		else if (!strcmp(clock_source, "sys"))
> > +			clk_from = CLK_FROM_SYS;
> > +		else if (!strcmp(clock_source, "ref"))
> > +			clk_from = CLK_FROM_REF;
> > +		else
> > +			goto err_invalid;
> > +		dev_dbg(&ofdev->dev, "got a clk source spec[%d]\n", clk_from);
> > +	}
> > +	if (clk_from == CLK_FROM_AUTO) {
> > +		/* no spec so far, try the 'sys' clock; round to the
> > +		 * next MHz and see if we can get a multiple of 16MHz
> > +		 */
> > +		dev_dbg(&ofdev->dev, "no clk source spec, trying SYS\n");
> > +		clk_in = clk_get(&ofdev->dev, "sys");
> > +		if (IS_ERR(clk_in))
> > +			goto err_notavail;
> > +		freq_calc = clk_get_rate(clk_in);
> > +		freq_calc +=  499999;
> > +		freq_calc /= 1000000;
> > +		freq_calc *= 1000000;
> > +		if ((freq_calc % 16000000) == 0) {
> > +			clk_from = CLK_FROM_SYS;
> > +			clockdiv = freq_calc / 16000000;
> > +			dev_dbg(&ofdev->dev,
> > +				"clk fit, sys[%lu] div[%d] freq[%lu]\n",
> > +				freq_calc, clockdiv, freq_calc / clockdiv);
> > +		}
> > +	}
> > +	if (clk_from == CLK_FROM_AUTO) {
> > +		/* no spec so far, use the 'ref' clock */
> > +		dev_dbg(&ofdev->dev, "no clk source spec, trying REF\n");
> > +		clk_in = clk_get(&ofdev->dev, "ref");
> > +		if (IS_ERR(clk_in))
> > +			goto err_notavail;
> > +		clk_from = CLK_FROM_REF;
> > +		freq_calc = clk_get_rate(clk_in);
> > +		dev_dbg(&ofdev->dev,
> > +			"clk fit, ref[%lu] (no div) freq[%lu]\n",
> > +			freq_calc, freq_calc);
> > +	}
> > +
> > +	/* select IPS or MCLK as the MSCAN input (returned to the caller),
> > +	 * setup the MCLK mux source and rate if applicable, apply the
> > +	 * optionally specified or derived above divider, and determine
> > +	 * the actual resulting clock rate to return to the caller
> > +	 */
> > +	switch (clk_from) {
> > +	case CLK_FROM_IPS:
> > +		clk_can = clk_get(&ofdev->dev, "ips");
> > +		if (IS_ERR(clk_can))
> > +			goto err_notavail;
> > +		clk_prepare_enable(clk_can);
> 
> Where is the corresponding clk_disable_unprepare()?a

It's missing, as I could not find the counterpart of the
.get_clock() callback where the get and prepare/enable was added
to.  And it appears that neither are enable errors checked for.
This patch clearly needs an update as well, but already should be
the last part of the series in a currently inacceptable state.

This .get_clock() routine is supposed to determine the clock
source, setup the desired rate and return the actual rate.  The
callback's API is rather limited in that it does communicate
clock rate values, but cannot access a location to store handles
to.

Are the introduction of a .put_clock() callback and passing the
'priv' handle to both get and put routines acceptable?  As this
would hook up clock handling to probe() and remove() just as
memory mapping gets approached.

Below is a patch on top of the CAN related patch in v2 of the
series.  If this approach is acceptable (maybe modulo how the
"unused" warnings get silenced), I'll fold it into the
introduction of common clock support in the mscan(4) driver.

diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index cf5e4cfc..16ca712 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -39,7 +39,9 @@
 struct mpc5xxx_can_data {
 	unsigned int type;
 	u32 (*get_clock)(struct platform_device *ofdev, const char *clock_name,
-			 int *mscan_clksrc);
+			 int *mscan_clksrc, struct mscan_priv *priv);
+	void (*put_clock)(struct platform_device *ofdev,
+			  struct mscan_priv *priv);
 };
 
 #ifdef CONFIG_PPC_MPC52xx
@@ -49,7 +51,8 @@ static struct of_device_id mpc52xx_cdm_ids[] = {
 };
 
 static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
-				 const char *clock_name, int *mscan_clksrc)
+				 const char *clock_name, int *mscan_clksrc,
+				 struct mscan_priv *priv)
 {
 	unsigned int pvr;
 	struct mpc52xx_cdm  __iomem *cdm;
@@ -101,15 +104,24 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
 }
 #else /* !CONFIG_PPC_MPC52xx */
 static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
-				 const char *clock_name, int *mscan_clksrc)
+				 const char *clock_name, int *mscan_clksrc,
+				 struct mscan_priv *priv)
 {
 	return 0;
 }
 #endif /* CONFIG_PPC_MPC52xx */
+static void mpc52xx_can_put_clock(struct platform_device *ofdev,
+				  struct mscan_priv *priv)
+{
+	/* EMPTY */
+	(void)ofdev;
+	(void)priv;
+}
 
 #ifdef CONFIG_PPC_MPC512x
 static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
-				 const char *clock_source, int *mscan_clksrc)
+				 const char *clock_source, int *mscan_clksrc,
+				 struct mscan_priv *priv)
 {
 	struct device_node *np;
 	u32 clockdiv;
@@ -200,7 +212,9 @@ static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 		clk_can = clk_get(&ofdev->dev, "ips");
 		if (IS_ERR(clk_can))
 			goto err_notavail;
-		clk_prepare_enable(clk_can);
+		if (clk_prepare_enable(clk_can))
+			goto err_notavail;
+		priv->clk_can = clk_can;
 		freq_calc = clk_get_rate(clk_can);
 		*mscan_clksrc = MSCAN_CLKSRC_IPS;
 		dev_dbg(&ofdev->dev, "clk from IPS, clksrc[%d] freq[%lu]\n",
@@ -211,7 +225,9 @@ static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 		clk_can = clk_get(&ofdev->dev, "mclk");
 		if (IS_ERR(clk_can))
 			goto err_notavail;
-		clk_prepare_enable(clk_can);
+		if (clk_prepare_enable(clk_can))
+			goto err_notavail;
+		priv->clk_can = clk_can;
 		if (clk_from == CLK_FROM_SYS)
 			clk_in = clk_get(&ofdev->dev, "sys");
 		if (clk_from == CLK_FROM_REF)
@@ -241,12 +257,31 @@ err_notavail:
 	dev_err(&ofdev->dev, "cannot acquire or setup clock source\n");
 	return 0;
 }
+
+static void mpc512x_can_put_clock(struct platform_device *ofdev,
+				  struct mscan_priv *priv)
+{
+	(void)ofdev;
+	if (priv->clk_can) {
+		clk_disable_unprepare(priv->clk_can);
+		clk_put(priv->clk_can);
+	}
+}
 #else /* !CONFIG_PPC_MPC512x */
 static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
-				 const char *clock_name, int *mscan_clksrc)
+				 const char *clock_name, int *mscan_clksrc,
+				 struct mscan_priv *priv)
 {
 	return 0;
 }
+
+static void mpc512x_can_put_clock(struct platform_device *ofdev,
+				  struct mscan_priv *priv)
+{
+	(void)ofdev;
+	(void)priv;
+	/* EMPTY */
+}
 #endif /* CONFIG_PPC_MPC512x */
 
 static const struct of_device_id mpc5xxx_can_table[];
@@ -293,7 +328,7 @@ static int mpc5xxx_can_probe(struct platform_device *ofdev)
 	BUG_ON(!data);
 	priv->type = data->type;
 	priv->can.clock.freq = data->get_clock(ofdev, clock_name,
-					       &mscan_clksrc);
+					       &mscan_clksrc, priv);
 	if (!priv->can.clock.freq) {
 		dev_err(&ofdev->dev, "couldn't get MSCAN clock properties\n");
 		goto exit_free_mscan;
@@ -327,10 +362,17 @@ exit_unmap_mem:
 
 static int mpc5xxx_can_remove(struct platform_device *ofdev)
 {
+	const struct of_device_id *match;
+	const struct mpc5xxx_can_data *data;
 	struct net_device *dev = platform_get_drvdata(ofdev);
 	struct mscan_priv *priv = netdev_priv(dev);
 
+	match = of_match_device(mpc5xxx_can_table, &ofdev->dev);
+	data = match ? match->data : NULL;
+
 	unregister_mscandev(dev);
+	if (data)
+		data->put_clock(ofdev, priv);
 	iounmap(priv->reg_base);
 	irq_dispose_mapping(dev->irq);
 	free_candev(dev);
@@ -383,11 +425,13 @@ static int mpc5xxx_can_resume(struct platform_device *ofdev)
 static const struct mpc5xxx_can_data mpc5200_can_data = {
 	.type = MSCAN_TYPE_MPC5200,
 	.get_clock = mpc52xx_can_get_clock,
+	.put_clock = mpc52xx_can_put_clock,
 };
 
 static const struct mpc5xxx_can_data mpc5121_can_data = {
 	.type = MSCAN_TYPE_MPC5121,
 	.get_clock = mpc512x_can_get_clock,
+	.put_clock = mpc512x_can_put_clock,
 };
 
 static const struct of_device_id mpc5xxx_can_table[] = {
diff --git a/drivers/net/can/mscan/mscan.h b/drivers/net/can/mscan/mscan.h
index af2ed8b..f32e190 100644
--- a/drivers/net/can/mscan/mscan.h
+++ b/drivers/net/can/mscan/mscan.h
@@ -21,6 +21,7 @@
 #ifndef __MSCAN_H__
 #define __MSCAN_H__
 
+#include <linux/clk.h>
 #include <linux/types.h>
 
 /* MSCAN control register 0 (CANCTL0) bits */
@@ -283,6 +284,7 @@ struct mscan_priv {
 	unsigned int type; 	/* MSCAN type variants */
 	unsigned long flags;
 	void __iomem *reg_base;	/* ioremap'ed address to registers */
+	struct clk *clk_can;	/* clock for registers or bitrates */
 	u8 shadow_statflg;
 	u8 shadow_canrier;
 	u8 cur_pri;

> > +		freq_calc = clk_get_rate(clk_can);
> > +		*mscan_clksrc = MSCAN_CLKSRC_IPS;
> > +		dev_dbg(&ofdev->dev, "clk from IPS, clksrc[%d] freq[%lu]\n",
> > +			*mscan_clksrc, freq_calc);
> > +		break;
> > +	case CLK_FROM_SYS:
> > +	case CLK_FROM_REF:
> > +		clk_can = clk_get(&ofdev->dev, "mclk");
> > +		if (IS_ERR(clk_can))
> > +			goto err_notavail;
> > +		clk_prepare_enable(clk_can);
> 
> dito

yes, both problems of not checking for errors and dropping the
reference, will address this as well


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


From maxime.ripard at free-electrons.com  Fri Jul 19 05:42:11 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 19 Jul 2013 11:42:11 +0200
Subject: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner's
 Security ID fuses
In-Reply-To: <20130717161758.GA9822@kroah.com>
References: <51C8B84C.3020200@schinagl.nl> <20130624214615.GA17604@kroah.com>
 <51CAA709.4060801@schinagl.nl> <20130626175144.GC2222@kroah.com>
 <51D674BF.9030207@schinagl.nl> <20130706193646.GB9778@kroah.com>
 <51E466A3.4010503@schinagl.nl> <20130716064107.GA10868@kroah.com>
 <20130717114650.GN3125@lukather> <20130717161758.GA9822@kroah.com>
Message-ID: <20130719094211.GD5106@lukather>

On Wed, Jul 17, 2013 at 09:17:58AM -0700, Greg KH wrote:
> On Wed, Jul 17, 2013 at 01:46:50PM +0200, Maxime Ripard wrote:
> > On Mon, Jul 15, 2013 at 11:41:07PM -0700, Greg KH wrote:
> > > On Mon, Jul 15, 2013 at 11:16:19PM +0200, Oliver Schinagl wrote:
> > > > So using these new patches for binary attributes, how can I pass data 
> > > > between my driver and the sysfs files using a platform_driver? Or are 
> > > > other 'hacks' needed and using the .groups attribute from 
> > > > platform_driver->device_driver->groups is really the wrong approach.
> > > > 
> > > > I did ask around and still haven't figured it out so far, so I do 
> > > > apologize if you feel I'm wasting your precious time.
> > > 
> > > How is the platform device not the same thing that was passed to your
> > > probe function?
> > 
> > One thing I don't get here is why it should be set in the
> > platform_driver structure. From my understanding of the device model,
> > and since what Oliver is trying to do is exposing a few bytes of memory
> > to sysfs, shouldn't the sysfs file be attached to the device instead?
> 
> It will be created by the driver core for any device attached to the
> driver automatically.
> 
> > I mean, here, the sysfs file will be created under something like
> > .../drivers/sunxi-sid/eeprom. What happens when you have several
> > instances of that driver loaded? I'd expect it to have several sysfs
> > files created, one for each instance. So to me, it should be in the
> > device structure, not the driver one.
> 
> You can't have multiple drivers with the same name loaded (or the same
> module loaded multiple times.)  You can have multiple devices for a
> single driver, which is what we do all the time.

Yes, I know that, and it's actually my point.
With the current oliver's code he pasted earlier in this thread:

# find /sys/ -name eeprom
/sys/bus/platform/drivers/sunxi-sid/eeprom

While I'd expect the eeprom file to be located in
/sys/bus/platform/devices/X.eeprom/eeprom like it used to be in the v4,
since it's an instance-specific content.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130719/02c9c251/attachment-0001.sig>

From voice.shen at atmel.com  Fri Jul 19 05:42:57 2013
From: voice.shen at atmel.com (Bo Shen)
Date: Fri, 19 Jul 2013 17:42:57 +0800
Subject: [PATCH] ASoC: atmel: add wm8904 based audio machine driver
Message-ID: <1374226977-10188-1-git-send-email-voice.shen@atmel.com>

Add wm8904 based audio machine driver for Atmel EK board

The following ek board based on it
  - at91sam9n12ek
  - sama5d3xek (d31, d33, d34, d35)

Signed-off-by: Bo Shen <voice.shen at atmel.com>
---
This patch is only for Atmel SoC with wm8904 codec machine driver
only, temp no change for dts file, as there are many changes to dts
file in mailing list for atmel SoC now, so hold on for dts change,
after that will send the dts file patches

Change in v2:
  - Update the binding doc, add widgets describe of codec and board
  - set sysclk after set pll
  - using bias level trasition to decide enable/disable clock
  - return real error code instead of return -1

Todo:
  - After the at91 clock move to common clock framework, then rework
    the clock in this driver
---
 .../devicetree/bindings/sound/atmel-wm8904.txt     |   55 +++++
 sound/soc/atmel/Kconfig                            |   10 +
 sound/soc/atmel/Makefile                           |    2 +
 sound/soc/atmel/atmel_wm8904.c                     |  254 ++++++++++++++++++++
 4 files changed, 321 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-wm8904.txt
 create mode 100644 sound/soc/atmel/atmel_wm8904.c

diff --git a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
new file mode 100644
index 0000000..8bbe50c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
@@ -0,0 +1,55 @@
+Atmel ASoC driver with wm8904 audio codec complex
+
+Required properties:
+  - compatible: "atmel,asoc-wm8904"
+  - atmel,model: The user-visible name of this sound complex.
+  - atmel,audio-routing: A list of the connections between audio components.
+    Each entry is a pair of strings, the first being the connection's sink,
+    the second being the connection's source. Valid names for sources and
+    sinks are the WM8904's pins, and the jacks on the board:
+
+    WM8904 pins:
+
+    * IN1L
+    * IN1R
+    * IN2L
+    * IN2R
+    * IN3L
+    * IN3R
+    * HPOUTL
+    * HPOUTR
+    * LINEOUTL
+    * LINEOUTR
+    * MICBIAS
+
+    Board connectors:
+
+    * Headphone Jack
+    * Line In Jack
+    * Mic
+
+  - atmel,ssc-controller: The phandle of the SSC controller
+  - atmel,audio-codec: The phandle of the WM8904 audio codec
+
+Optional properties:
+  - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
+
+Example:
+sound {
+	compatible = "atmel,asoc-wm8904";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pck0_as_mck>;
+
+	atmel,model = "wm8904 @ AT91SAM9N12EK";
+
+	atmel,audio-routing =
+		"Headphone Jack", "HPOUTL",
+		"Headphone Jack", "HPOUTR",
+		"IN2L", "Line In Jack",
+		"IN2R", "Line In Jack",
+		"Mic", "MICBIAS",
+		"IN1L", "Mic";
+
+	atmel,ssc-controller = <&ssc0>;
+	atmel,audio-codec = <&wm8904>;
+};
diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 1c0b185..986323b 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -33,6 +33,16 @@ config SND_AT91_SOC_SAM9G20_WM8731
 	  Say Y if you want to add support for SoC audio on WM8731-based
 	  AT91sam9g20 evaluation board.
 
+config SND_ATMEL_SOC_WM8904
+	tristate "Atmel ASoC driver for boards using WM8904 codec"
+	depends on ARCH_AT91 && ATMEL_SSC && SND_ATMEL_SOC
+	select SND_ATMEL_SOC_SSC
+	select SND_ATMEL_SOC_DMA
+	select SND_SOC_WM8904
+	help
+	  Say Y if you want to add support for Atmel ASoC driver for boards using
+	  WM8904 codec.
+
 config SND_AT91_SOC_AFEB9260
 	tristate "SoC Audio support for AFEB9260 board"
 	depends on ARCH_AT91 && ATMEL_SSC && ARCH_AT91 && MACH_AFEB9260 && SND_ATMEL_SOC
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index 41967cc..922d4da 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -11,6 +11,8 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
 
 # AT91 Machine Support
 snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
+snd-atmel-soc-wm8904-objs := atmel_wm8904.o
 
 obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
+obj-$(CONFIG_SND_ATMEL_SOC_WM8904) += snd-atmel-soc-wm8904.o
 obj-$(CONFIG_SND_AT91_SOC_AFEB9260) += snd-soc-afeb9260.o
diff --git a/sound/soc/atmel/atmel_wm8904.c b/sound/soc/atmel/atmel_wm8904.c
new file mode 100644
index 0000000..7222380
--- /dev/null
+++ b/sound/soc/atmel/atmel_wm8904.c
@@ -0,0 +1,254 @@
+/*
+ * atmel_wm8904 - Atmel ASoC driver for boards with WM8904 codec.
+ *
+ * Copyright (C) 2012 Atmel
+ *
+ * Author: Bo Shen <voice.shen at atmel.com>
+ *
+ * GPLv2 or later
+ */
+
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/consumer.h>
+
+#include <sound/soc.h>
+
+#include "../codecs/wm8904.h"
+#include "atmel_ssc_dai.h"
+
+#define MCLK_RATE 32768
+
+static struct clk *mclk;
+
+static const struct snd_soc_dapm_widget atmel_asoc_wm8904_dapm_widgets[] = {
+	SND_SOC_DAPM_HP("Headphone Jack", NULL),
+	SND_SOC_DAPM_MIC("Mic", NULL),
+	SND_SOC_DAPM_LINE("Line In Jack", NULL),
+};
+
+static int atmel_asoc_wm8904_hw_params(struct snd_pcm_substream *substream,
+		struct snd_pcm_hw_params *params)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct snd_soc_dai *codec_dai = rtd->codec_dai;
+	int ret;
+
+	ret = snd_soc_dai_set_pll(codec_dai, WM8904_FLL_MCLK, WM8904_FLL_MCLK,
+		32768, params_rate(params) * 256);
+	if (ret < 0) {
+		pr_err("%s - failed to set wm8904 codec PLL.", __func__);
+		return ret;
+	}
+
+	/*
+	 * As here wm8904 use FLL output as its system clock
+	 * so calling set_sysclk won't care freq parameter
+	 * then we pass 0
+	 */
+	ret = snd_soc_dai_set_sysclk(codec_dai, WM8904_CLK_FLL,
+			0, SND_SOC_CLOCK_IN);
+	if (ret < 0) {
+		pr_err("%s -failed to set wm8904 SYSCLK\n", __func__);
+		return ret;
+	}
+
+	return 0;
+}
+
+static struct snd_soc_ops atmel_asoc_wm8904_ops = {
+	.hw_params = atmel_asoc_wm8904_hw_params,
+};
+
+static int atmel_set_bias_level(struct snd_soc_card *card,
+		struct snd_soc_dapm_context *dapm,
+		enum snd_soc_bias_level level)
+{
+	if (dapm->bias_level == SND_SOC_BIAS_STANDBY) {
+		switch (level) {
+		case SND_SOC_BIAS_PREPARE:
+			clk_prepare_enable(mclk);
+			break;
+		case SND_SOC_BIAS_OFF:
+			clk_disable_unprepare(mclk);
+			break;
+		default:
+			break;
+		}
+	}
+
+	return 0;
+};
+
+static struct snd_soc_dai_link atmel_asoc_wm8904_dailink = {
+	.name = "WM8904",
+	.stream_name = "WM8904 PCM",
+	.codec_dai_name = "wm8904-hifi",
+	.dai_fmt = SND_SOC_DAIFMT_I2S
+		| SND_SOC_DAIFMT_NB_NF
+		| SND_SOC_DAIFMT_CBM_CFM,
+	.ops = &atmel_asoc_wm8904_ops,
+};
+
+static struct snd_soc_card atmel_asoc_wm8904_card = {
+	.name = "atmel_asoc_wm8904",
+	.owner = THIS_MODULE,
+	.set_bias_level = atmel_set_bias_level,
+	.dai_link = &atmel_asoc_wm8904_dailink,
+	.num_links = 1,
+	.dapm_widgets = atmel_asoc_wm8904_dapm_widgets,
+	.num_dapm_widgets = ARRAY_SIZE(atmel_asoc_wm8904_dapm_widgets),
+	.fully_routed = true,
+};
+
+static int atmel_asoc_wm8904_dt_init(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *codec_np, *cpu_np;
+	struct snd_soc_card *card = &atmel_asoc_wm8904_card;
+	struct snd_soc_dai_link *dailink = &atmel_asoc_wm8904_dailink;
+	int ret;
+
+	if (!np) {
+		dev_err(&pdev->dev, "only device tree supported\n");
+		return -EINVAL;
+	}
+
+	ret = snd_soc_of_parse_card_name(card, "atmel,model");
+	if (ret) {
+		dev_err(&pdev->dev, "failed to parse card name\n");
+		return ret;
+	}
+
+	ret = snd_soc_of_parse_audio_routing(card, "atmel,audio-routing");
+	if (ret) {
+		dev_err(&pdev->dev, "failed to parse audio routing\n");
+		return ret;
+	}
+
+	cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
+	if (!cpu_np) {
+		dev_err(&pdev->dev, "failed to get dai and pcm info\n");
+		ret = -EINVAL;
+		return ret;
+	}
+	dailink->cpu_of_node = cpu_np;
+	dailink->platform_of_node = cpu_np;
+	of_node_put(cpu_np);
+
+	codec_np = of_parse_phandle(np, "atmel,audio-codec", 0);
+	if (!codec_np) {
+		dev_err(&pdev->dev, "failed to get codec info\n");
+		ret = -EINVAL;
+		return ret;
+	}
+	dailink->codec_of_node = codec_np;
+	of_node_put(codec_np);
+
+	return 0;
+}
+
+static int atmel_asoc_wm8904_probe(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = &atmel_asoc_wm8904_card;
+	struct snd_soc_dai_link *dailink = &atmel_asoc_wm8904_dailink;
+	struct clk *clk_src;
+	struct pinctrl *pinctrl;
+	int id, ret;
+
+	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+	if (IS_ERR(pinctrl)) {
+		dev_err(&pdev->dev, "failed to request pinctrl\n");
+		return PTR_ERR(pinctrl);
+	}
+
+	card->dev = &pdev->dev;
+	ret = atmel_asoc_wm8904_dt_init(pdev);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to init dt info\n");
+		return ret;
+	}
+
+	id = of_alias_get_id((struct device_node *)dailink->cpu_of_node, "ssc");
+	ret = atmel_ssc_set_audio(id);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "failed to set SSC %d for audio\n", id);
+		return ret;
+	}
+
+	mclk = clk_get(NULL, "pck0");
+	if (IS_ERR(mclk)) {
+		dev_err(&pdev->dev, "failed to get pck0\n");
+		ret = PTR_ERR(mclk);
+		goto err_set_audio;
+	}
+
+	clk_src = clk_get(NULL, "clk32k");
+	if (IS_ERR(clk_src)) {
+		dev_err(&pdev->dev, "failed to get clk32k\n");
+		ret = PTR_ERR(clk_src);
+		goto err_set_audio;
+	}
+
+	ret = clk_set_parent(mclk, clk_src);
+	clk_put(clk_src);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "failed to set MCLK parent\n");
+		goto err_set_audio;
+	}
+
+	dev_info(&pdev->dev, "setting pck0 to %dHz\n", MCLK_RATE);
+	clk_set_rate(mclk, MCLK_RATE);
+
+	ret = snd_soc_register_card(card);
+	if (ret) {
+		dev_err(&pdev->dev, "snd_soc_register_card failed\n");
+		goto err_set_audio;
+	}
+
+	return 0;
+
+err_set_audio:
+	atmel_ssc_put_audio(id);
+	return ret;
+}
+
+static int atmel_asoc_wm8904_remove(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = platform_get_drvdata(pdev);
+	struct snd_soc_dai_link *dailink = &atmel_asoc_wm8904_dailink;
+	int id;
+
+	id = of_alias_get_id((struct device_node *)dailink->cpu_of_node, "ssc");
+
+	snd_soc_unregister_card(card);
+	atmel_ssc_put_audio(id);
+
+	return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id atmel_asoc_wm8904_dt_ids[] = {
+	{ .compatible = "atmel,asoc-wm8904", },
+	{ }
+};
+#endif
+
+static struct platform_driver atmel_asoc_wm8904_driver = {
+	.driver = {
+		.name = "atmel-wm8904-audio",
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(atmel_asoc_wm8904_dt_ids),
+	},
+	.probe = atmel_asoc_wm8904_probe,
+	.remove = atmel_asoc_wm8904_remove,
+};
+
+module_platform_driver(atmel_asoc_wm8904_driver);
+
+/* Module information */
+MODULE_AUTHOR("Bo Shen <voice.shen at atmel.com>");
+MODULE_DESCRIPTION("ALSA SoC machine driver for Atmel EK with WM8904 codec");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5



From stefano.stabellini at eu.citrix.com  Fri Jul 19 05:52:00 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 19 Jul 2013 10:52:00 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabled
In-Reply-To: <1374222736.26728.128.camel@kazak.uk.xensource.com>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
 <CAPnVf8yH7PBOSSC57qJv+pWmsinRUxGr81QUPH9GoOkKw2oo3Q@mail.gmail.com>
 <1374222736.26728.128.camel@kazak.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1307191049070.8258@kaball.uk.xensource.com>

On Fri, 19 Jul 2013, Ian Campbell wrote:
> On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote:
> > On 17 July 2013 14:25, Stefano Stabellini
> > <stefano.stabellini at eu.citrix.com> wrote:
> > > On Mon, 15 Jul 2013, Julien Grall wrote:
> > >> Even if uncompress debug is disabled, some board will continue to print
> > >> information during uncompress step.
> > >
> > > Are you talking about DEBUG_UNCOMPRESS?
> > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > > some board will continue to print information during the uncompress step"?
> > 
> > Yes. On the arndale, uncompress log are directly output on UART-2.
> > This is annoying because Xen doesn't expose the UART to dom0.
> 
> This is because Xen wants/tries to use the UART as its own console,
> right?
> 
> There are at least two other options: Either Xen uses a different UART
> to that configured statically into the kernel image (depends on how many
> UARTs the platform exposes) or Xen uses no serial console at all.
> 
> Of course long term we just need to wait for the exynos stuff to get
> integrated into the multiplatform kernel.
> 
> Having no Xen serial console is not as bad as it seems for actual
> deployment, it is actually already the default on x86 (a serial console
> needs to be explicitly configured). The Xen console would still be
> available via the "xl dmesg" command and for debug environments people
> can just hack around the issue for now (until MP kernels arrive for the
> platform).
> 
> Perhaps a useful compromise would be for Xen to initially use the
> console but to hand it over to dom0 once it starts (similar to how we
> handle VGA where it is present), Xen could also steal it back on panic
> (since dom0 isn't going to be using it after that...).

I like this last option, it looks like the best compromise.


> Alternatively, since these early UART routines tend to be pretty simple
> polled affairs, we could also consider extending the existing vpl011
> code to have platform configurable addresses for the output and status
> registers and a configurable fixed value for the read of the status
> register. I'm not keen to have this code turn into a full "emulator" but
> so long as it stays within the remit given in vpl011.c:
>         /*
>          * This is not intended to be a full emulation of a PL011
>          * device. Rather it is intended to provide a sufficient veneer of one
>          * that early code (such as Linux's boot time decompressor) which
>          * hardcodes output directly to such a device are able to make progress.
>          *
>          * This device is not intended to be enumerable or exposed to the OS
>          * (e.g. via Device Tree).
>          */
> then I think I could live with it getting a bit more flexible about
> where the registers live in order to be able to handle more UART
> variants.
 
We could end up emulating way too many devices and not all the platforms
expect a pl011 uart.


From plagnioj at jcrosoft.com  Fri Jul 19 05:56:28 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Fri, 19 Jul 2013 11:56:28 +0200
Subject: [PATCH] arm64: use common reboot infrastructure
In-Reply-To: <1373541180-7452-1-git-send-email-marc.zyngier@arm.com>
References: <1373541180-7452-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130719095628.GG16015@ns203013.ovh.net>

On 12:13 Thu 11 Jul     , Marc Zyngier wrote:
> Commit 7b6d864b48d9 (reboot: arm: change reboot_mode to use enum
> reboot_mode) changed the way reboot is handled on arm, which has a
> direct impact on arm64 as we share the reset driver on the VE platform.
> 
> The obvious fix is to move arm64 to use the same infrastructure.
> 
> Cc: Robin Holt <holt at sgi.com>
> Cc: Pawel Moll <pawel.moll at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/system_misc.h | 3 ++-
>  arch/arm64/kernel/process.c          | 2 +-
>  kernel/reboot.c                      | 2 +-
>  3 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
> index a6e1750..7a18fab 100644
> --- a/arch/arm64/include/asm/system_misc.h
> +++ b/arch/arm64/include/asm/system_misc.h
> @@ -23,6 +23,7 @@
>  #include <linux/compiler.h>
>  #include <linux/linkage.h>
>  #include <linux/irqflags.h>
> +#include <linux/reboot.h>
>  
>  struct pt_regs;
>  
> @@ -41,7 +42,7 @@ extern void show_pte(struct mm_struct *mm, unsigned long addr);
>  extern void __show_regs(struct pt_regs *);
>  
>  void soft_restart(unsigned long);
> -extern void (*arm_pm_restart)(char str, const char *cmd);
> +extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
>  
>  #define UDBG_UNDEFINED	(1 << 0)
>  #define UDBG_SYSCALL	(1 << 1)
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 46f02c3..1788bf6 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -132,7 +132,7 @@ void machine_restart(char *cmd)
>  
>  	/* Now call the architecture specific reboot code. */
>  	if (arm_pm_restart)
> -		arm_pm_restart('h', cmd);
> +		arm_pm_restart(reboot_mode, cmd);
>  
>  	/*
>  	 * Whoops - the architecture was unable to reboot.
> diff --git a/kernel/reboot.c b/kernel/reboot.c
> index 269ed93..9aaeb58 100644
> --- a/kernel/reboot.c
> +++ b/kernel/reboot.c
> @@ -25,7 +25,7 @@ int C_A_D = 1;
>  struct pid *cad_pid;
>  EXPORT_SYMBOL(cad_pid);
>  
> -#if defined(CONFIG_ARM) || defined(CONFIG_UNICORE32)
> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_UNICORE32)
how aboud have a specific Kconfig for this instead of a list of defined(xx)

Best Regards,
J.
>  #define DEFAULT_REBOOT_MODE		= REBOOT_HARD
>  #else
>  #define DEFAULT_REBOOT_MODE
> -- 
> 1.8.1.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From Ian.Campbell at citrix.com  Fri Jul 19 06:00:43 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Fri, 19 Jul 2013 11:00:43 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabled
In-Reply-To: <alpine.DEB.2.02.1307191049070.8258@kaball.uk.xensource.com>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
 <CAPnVf8yH7PBOSSC57qJv+pWmsinRUxGr81QUPH9GoOkKw2oo3Q@mail.gmail.com>
 <1374222736.26728.128.camel@kazak.uk.xensource.com>
 <alpine.DEB.2.02.1307191049070.8258@kaball.uk.xensource.com>
Message-ID: <1374228043.13645.44.camel@kazak.uk.xensource.com>

On Fri, 2013-07-19 at 10:52 +0100, Stefano Stabellini wrote:
> On Fri, 19 Jul 2013, Ian Campbell wrote:
> > On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote:
> > > On 17 July 2013 14:25, Stefano Stabellini
> > > <stefano.stabellini at eu.citrix.com> wrote:
> > > > On Mon, 15 Jul 2013, Julien Grall wrote:
> > > >> Even if uncompress debug is disabled, some board will continue to print
> > > >> information during uncompress step.
> > > >
> > > > Are you talking about DEBUG_UNCOMPRESS?
> > > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > > > some board will continue to print information during the uncompress step"?
> > > 
> > > Yes. On the arndale, uncompress log are directly output on UART-2.
> > > This is annoying because Xen doesn't expose the UART to dom0.
> > 
> > This is because Xen wants/tries to use the UART as its own console,
> > right?
> > 
> > There are at least two other options: Either Xen uses a different UART
> > to that configured statically into the kernel image (depends on how many
> > UARTs the platform exposes) or Xen uses no serial console at all.
> > 
> > Of course long term we just need to wait for the exynos stuff to get
> > integrated into the multiplatform kernel.
> > 
> > Having no Xen serial console is not as bad as it seems for actual
> > deployment, it is actually already the default on x86 (a serial console
> > needs to be explicitly configured). The Xen console would still be
> > available via the "xl dmesg" command and for debug environments people
> > can just hack around the issue for now (until MP kernels arrive for the
> > platform).
> > 
> > Perhaps a useful compromise would be for Xen to initially use the
> > console but to hand it over to dom0 once it starts (similar to how we
> > handle VGA where it is present), Xen could also steal it back on panic
> > (since dom0 isn't going to be using it after that...).
> 
> I like this last option, it looks like the best compromise.
> 
> 
> > Alternatively, since these early UART routines tend to be pretty simple
> > polled affairs, we could also consider extending the existing vpl011
> > code to have platform configurable addresses for the output and status
> > registers and a configurable fixed value for the read of the status
> > register. I'm not keen to have this code turn into a full "emulator" but
> > so long as it stays within the remit given in vpl011.c:
> >         /*
> >          * This is not intended to be a full emulation of a PL011
> >          * device. Rather it is intended to provide a sufficient veneer of one
> >          * that early code (such as Linux's boot time decompressor) which
> >          * hardcodes output directly to such a device are able to make progress.
> >          *
> >          * This device is not intended to be enumerable or exposed to the OS
> >          * (e.g. via Device Tree).
> >          */
> > then I think I could live with it getting a bit more flexible about
> > where the registers live in order to be able to handle more UART
> > variants.
>  
> We could end up emulating way too many devices and not all the platforms
> expect a pl011 uart.

My point was that all of these debug routines expect exactly two things:
  * An output register where they can write a character
  * A status register which when read indicates that a new byte can be 
    sent

The existing pl011.c could be extended to provide this level of
functionality for *any* UART, at least to the degree required by this
code, almost trivially, by simply making the two addresses and the
static status register value configurable.

The status register value is static for us because we have no FIFOs and
just accumulate into a buffer to be sent to the real console, so it is
always possible to send another byte.

ISTR some talk of doing something similar for the early-printk stuff via
DT, might have imagined that though...

Ian.



From stefano.stabellini at eu.citrix.com  Fri Jul 19 06:06:28 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 19 Jul 2013 11:06:28 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabled
In-Reply-To: <1374228043.13645.44.camel@kazak.uk.xensource.com>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
 <CAPnVf8yH7PBOSSC57qJv+pWmsinRUxGr81QUPH9GoOkKw2oo3Q@mail.gmail.com>
 <1374222736.26728.128.camel@kazak.uk.xensource.com>
 <alpine.DEB.2.02.1307191049070.8258@kaball.uk.xensource.com>
 <1374228043.13645.44.camel@kazak.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1307191103520.8258@kaball.uk.xensource.com>

On Fri, 19 Jul 2013, Ian Campbell wrote:
> On Fri, 2013-07-19 at 10:52 +0100, Stefano Stabellini wrote:
> > On Fri, 19 Jul 2013, Ian Campbell wrote:
> > > On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote:
> > > > On 17 July 2013 14:25, Stefano Stabellini
> > > > <stefano.stabellini at eu.citrix.com> wrote:
> > > > > On Mon, 15 Jul 2013, Julien Grall wrote:
> > > > >> Even if uncompress debug is disabled, some board will continue to print
> > > > >> information during uncompress step.
> > > > >
> > > > > Are you talking about DEBUG_UNCOMPRESS?
> > > > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > > > > some board will continue to print information during the uncompress step"?
> > > > 
> > > > Yes. On the arndale, uncompress log are directly output on UART-2.
> > > > This is annoying because Xen doesn't expose the UART to dom0.
> > > 
> > > This is because Xen wants/tries to use the UART as its own console,
> > > right?
> > > 
> > > There are at least two other options: Either Xen uses a different UART
> > > to that configured statically into the kernel image (depends on how many
> > > UARTs the platform exposes) or Xen uses no serial console at all.
> > > 
> > > Of course long term we just need to wait for the exynos stuff to get
> > > integrated into the multiplatform kernel.
> > > 
> > > Having no Xen serial console is not as bad as it seems for actual
> > > deployment, it is actually already the default on x86 (a serial console
> > > needs to be explicitly configured). The Xen console would still be
> > > available via the "xl dmesg" command and for debug environments people
> > > can just hack around the issue for now (until MP kernels arrive for the
> > > platform).
> > > 
> > > Perhaps a useful compromise would be for Xen to initially use the
> > > console but to hand it over to dom0 once it starts (similar to how we
> > > handle VGA where it is present), Xen could also steal it back on panic
> > > (since dom0 isn't going to be using it after that...).
> > 
> > I like this last option, it looks like the best compromise.
> > 
> > 
> > > Alternatively, since these early UART routines tend to be pretty simple
> > > polled affairs, we could also consider extending the existing vpl011
> > > code to have platform configurable addresses for the output and status
> > > registers and a configurable fixed value for the read of the status
> > > register. I'm not keen to have this code turn into a full "emulator" but
> > > so long as it stays within the remit given in vpl011.c:
> > >         /*
> > >          * This is not intended to be a full emulation of a PL011
> > >          * device. Rather it is intended to provide a sufficient veneer of one
> > >          * that early code (such as Linux's boot time decompressor) which
> > >          * hardcodes output directly to such a device are able to make progress.
> > >          *
> > >          * This device is not intended to be enumerable or exposed to the OS
> > >          * (e.g. via Device Tree).
> > >          */
> > > then I think I could live with it getting a bit more flexible about
> > > where the registers live in order to be able to handle more UART
> > > variants.
> >  
> > We could end up emulating way too many devices and not all the platforms
> > expect a pl011 uart.
> 
> My point was that all of these debug routines expect exactly two things:
>   * An output register where they can write a character
>   * A status register which when read indicates that a new byte can be 
>     sent
> 
> The existing pl011.c could be extended to provide this level of
> functionality for *any* UART, at least to the degree required by this
> code, almost trivially, by simply making the two addresses and the
> static status register value configurable.
> 
> The status register value is static for us because we have no FIFOs and
> just accumulate into a buffer to be sent to the real console, so it is
> always possible to send another byte.
> 
> ISTR some talk of doing something similar for the early-printk stuff via
> DT, might have imagined that though...
 
That's interesting but what about the meaning of the various bits of the
status register? It's not going to be always the same for the various
uarts, we would need to take into account at least that.


From Ian.Campbell at citrix.com  Fri Jul 19 06:12:11 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Fri, 19 Jul 2013 11:12:11 +0100
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabled
In-Reply-To: <alpine.DEB.2.02.1307191103520.8258@kaball.uk.xensource.com>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307171420350.8258@kaball.uk.xensource.com>
 <CAPnVf8yH7PBOSSC57qJv+pWmsinRUxGr81QUPH9GoOkKw2oo3Q@mail.gmail.com>
 <1374222736.26728.128.camel@kazak.uk.xensource.com>
 <alpine.DEB.2.02.1307191049070.8258@kaball.uk.xensource.com>
 <1374228043.13645.44.camel@kazak.uk.xensource.com>
 <alpine.DEB.2.02.1307191103520.8258@kaball.uk.xensource.com>
Message-ID: <1374228731.13645.45.camel@kazak.uk.xensource.com>

On Fri, 2013-07-19 at 11:06 +0100, Stefano Stabellini wrote:
> On Fri, 19 Jul 2013, Ian Campbell wrote:
> > On Fri, 2013-07-19 at 10:52 +0100, Stefano Stabellini wrote:
> > > On Fri, 19 Jul 2013, Ian Campbell wrote:
> > > > On Thu, 2013-07-18 at 17:15 +0100, Julien Grall wrote:
> > > > > On 17 July 2013 14:25, Stefano Stabellini
> > > > > <stefano.stabellini at eu.citrix.com> wrote:
> > > > > > On Mon, 15 Jul 2013, Julien Grall wrote:
> > > > > >> Even if uncompress debug is disabled, some board will continue to print
> > > > > >> information during uncompress step.
> > > > > >
> > > > > > Are you talking about DEBUG_UNCOMPRESS?
> > > > > > Should I read the sentence as "even if DEBUG_UNCOMPRESS is not selected,
> > > > > > some board will continue to print information during the uncompress step"?
> > > > > 
> > > > > Yes. On the arndale, uncompress log are directly output on UART-2.
> > > > > This is annoying because Xen doesn't expose the UART to dom0.
> > > > 
> > > > This is because Xen wants/tries to use the UART as its own console,
> > > > right?
> > > > 
> > > > There are at least two other options: Either Xen uses a different UART
> > > > to that configured statically into the kernel image (depends on how many
> > > > UARTs the platform exposes) or Xen uses no serial console at all.
> > > > 
> > > > Of course long term we just need to wait for the exynos stuff to get
> > > > integrated into the multiplatform kernel.
> > > > 
> > > > Having no Xen serial console is not as bad as it seems for actual
> > > > deployment, it is actually already the default on x86 (a serial console
> > > > needs to be explicitly configured). The Xen console would still be
> > > > available via the "xl dmesg" command and for debug environments people
> > > > can just hack around the issue for now (until MP kernels arrive for the
> > > > platform).
> > > > 
> > > > Perhaps a useful compromise would be for Xen to initially use the
> > > > console but to hand it over to dom0 once it starts (similar to how we
> > > > handle VGA where it is present), Xen could also steal it back on panic
> > > > (since dom0 isn't going to be using it after that...).
> > > 
> > > I like this last option, it looks like the best compromise.
> > > 
> > > 
> > > > Alternatively, since these early UART routines tend to be pretty simple
> > > > polled affairs, we could also consider extending the existing vpl011
> > > > code to have platform configurable addresses for the output and status
> > > > registers and a configurable fixed value for the read of the status
> > > > register. I'm not keen to have this code turn into a full "emulator" but
> > > > so long as it stays within the remit given in vpl011.c:
> > > >         /*
> > > >          * This is not intended to be a full emulation of a PL011
> > > >          * device. Rather it is intended to provide a sufficient veneer of one
> > > >          * that early code (such as Linux's boot time decompressor) which
> > > >          * hardcodes output directly to such a device are able to make progress.
> > > >          *
> > > >          * This device is not intended to be enumerable or exposed to the OS
> > > >          * (e.g. via Device Tree).
> > > >          */
> > > > then I think I could live with it getting a bit more flexible about
> > > > where the registers live in order to be able to handle more UART
> > > > variants.
> > >  
> > > We could end up emulating way too many devices and not all the platforms
> > > expect a pl011 uart.
> > 
> > My point was that all of these debug routines expect exactly two things:
> >   * An output register where they can write a character
> >   * A status register which when read indicates that a new byte can be 
> >     sent
> > 
> > The existing pl011.c could be extended to provide this level of
> > functionality for *any* UART, at least to the degree required by this
> > code, almost trivially, by simply making the two addresses and the
> > static status register value configurable.
> > 
> > The status register value is static for us because we have no FIFOs and
> > just accumulate into a buffer to be sent to the real console, so it is
> > always possible to send another byte.
> > 
> > ISTR some talk of doing something similar for the early-printk stuff via
> > DT, might have imagined that though...
>  
> That's interesting but what about the meaning of the various bits of the
> status register? It's not going to be always the same for the various
> uarts, we would need to take into account at least that.

Yes, hence making the static value read from the status register
configurable too.

Ian.




From jonas.jensen at gmail.com  Fri Jul 19 06:23:22 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Fri, 19 Jul 2013 12:23:22 +0200
Subject: [PATCH v4] watchdog: Add MOXA ART watchdog driver
In-Reply-To: <1374053091-5907-1-git-send-email-jonas.jensen@gmail.com>
References: <1374053091-5907-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1374229402-20432-1-git-send-email-jonas.jensen@gmail.com>

Add watchdog driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    v4 should fix remaining issues pointed out by Guenter.
    
    Changes since v3:
    
    1. remove unnecessary header includes:
       linux/of.h
       linux/of_address.h
       linux/err.h
       linux/init.h
       linux/kernel.h,
       linux/moduleparam.h
       linux/types.h
       asm/system_misc.h
    2. move clock_frequency to moxart_wdt_dev
    3. remove local pointer "void __iomem *wdt_base" use moxart_wdt->base instead
    4. get clock_frequency from watchdog_get_drvdata
    5. move max_timeout variable to moxart_wdt_probe
    6. check for division by zero moxart_wdt->clock_frequency
    7. if devm_kzalloc fails, return -ENOMEM instead of -EINVAL
    
    Applies to next-20130716

 .../bindings/watchdog/moxa,moxart-watchdog.txt     |  15 ++
 drivers/watchdog/Kconfig                           |  10 ++
 drivers/watchdog/Makefile                          |   1 +
 drivers/watchdog/moxart_wdt.c                      | 166 +++++++++++++++++++++
 4 files changed, 192 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
 create mode 100644 drivers/watchdog/moxart_wdt.c

diff --git a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
new file mode 100644
index 0000000..5507f2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
@@ -0,0 +1,15 @@
+MOXA ART Watchdog timer
+
+Required properties:
+
+- compatible : Should be "moxa,moxart-watchdog"
+- reg : Should contain registers location and length
+- clocks : Should contain phandle for the MOXA ART core clock "coreclk"
+
+Example:
+
+	watchdog: watchdog at 98500000 {
+		compatible = "moxa,moxart-watchdog";
+		reg = <0x98500000 0x10>;
+		clocks = <&coreclk>;
+	};
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 362085d..6883aab 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -382,6 +382,16 @@ config RETU_WATCHDOG
 	  To compile this driver as a module, choose M here: the
 	  module will be called retu_wdt.
 
+config MOXART_WDT
+	tristate "MOXART watchdog"
+	depends on ARCH_MOXART
+	help
+	  Say Y here to include Watchdog timer support for the watchdog
+	  existing on the MOXA ART SoC series platforms.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called moxart_wdt.
+
 # AVR32 Architecture
 
 config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 2f26a0b..7cab53a 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
 obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
 obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
 obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
+obj-$(CONFIG_MOXART_WDT) += moxart_wdt.o
 
 # AVR32 Architecture
 obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
new file mode 100644
index 0000000..9a59c3d
--- /dev/null
+++ b/drivers/watchdog/moxart_wdt.c
@@ -0,0 +1,166 @@
+/*
+ * MOXA ART SoCs watchdog driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/watchdog.h>
+
+#define REG_COUNT			0x4
+#define REG_MODE			0x8
+#define REG_ENABLE			0xC
+
+struct moxart_wdt_dev {
+	struct watchdog_device dev;
+	void __iomem *base;
+	unsigned int clock_frequency;
+};
+
+static int heartbeat;
+
+static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+
+	writel(0, moxart_wdt->base + REG_ENABLE);
+
+	return 0;
+}
+
+static int moxart_wdt_start(struct watchdog_device *wdt_dev)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+
+	writel(moxart_wdt->clock_frequency * moxart_wdt->dev.timeout,
+	       moxart_wdt->base + REG_COUNT);
+	writel(0x5ab9, moxart_wdt->base + REG_MODE);
+	writel(0x03, moxart_wdt->base + REG_ENABLE);
+
+	return 0;
+}
+
+static int moxart_wdt_set_timeout(struct watchdog_device *wdt_dev,
+				  unsigned int timeout)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+
+	dev_dbg(wdt_dev->dev, "%s: timeout=%u\n", __func__, timeout);
+
+	moxart_wdt->dev.timeout = timeout;
+
+	return 0;
+}
+
+static const struct watchdog_info moxart_wdt_info = {
+	.identity       = "moxart-wdt",
+	.options        = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
+static const struct watchdog_ops moxart_wdt_ops = {
+	.owner          = THIS_MODULE,
+	.start          = moxart_wdt_start,
+	.stop           = moxart_wdt_stop,
+	.set_timeout    = moxart_wdt_set_timeout,
+};
+
+static int moxart_wdt_probe(struct platform_device *pdev)
+{
+	struct moxart_wdt_dev *moxart_wdt;
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct resource *res;
+	struct clk *clk;
+	int err;
+	unsigned int max_timeout;
+	bool nowayout = WATCHDOG_NOWAYOUT;
+
+	moxart_wdt = devm_kzalloc(&pdev->dev, sizeof(*moxart_wdt), GFP_KERNEL);
+	if (!moxart_wdt)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, moxart_wdt);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	moxart_wdt->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_wdt->base))
+		return PTR_ERR(moxart_wdt->base);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk)) {
+		pr_err("%s: of_clk_get failed\n", __func__);
+		return PTR_ERR(clk);
+	}
+
+	moxart_wdt->clock_frequency = clk_get_rate(clk);
+	if (moxart_wdt->clock_frequency == 0) {
+		pr_err("%s: incorrect clock frequency\n", __func__);
+		return -EINVAL;
+	}
+
+	max_timeout = UINT_MAX / moxart_wdt->clock_frequency;
+
+	moxart_wdt->dev.info = &moxart_wdt_info;
+	moxart_wdt->dev.ops = &moxart_wdt_ops;
+	moxart_wdt->dev.timeout = max_timeout;
+	moxart_wdt->dev.min_timeout = 1;
+	moxart_wdt->dev.max_timeout = max_timeout;
+	moxart_wdt->dev.parent = &pdev->dev;
+
+	watchdog_init_timeout(&moxart_wdt->dev, heartbeat, &pdev->dev);
+	watchdog_set_nowayout(&moxart_wdt->dev, nowayout);
+
+	watchdog_set_drvdata(&moxart_wdt->dev, moxart_wdt);
+
+	err = watchdog_register_device(&moxart_wdt->dev);
+	if (unlikely(err))
+		return err;
+
+	dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
+		moxart_wdt->dev.timeout, nowayout);
+
+	return 0;
+}
+
+static int moxart_wdt_remove(struct platform_device *pdev)
+{
+	struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
+
+	moxart_wdt_stop(&moxart_wdt->dev);
+	watchdog_unregister_device(&moxart_wdt->dev);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_watchdog_match[] = {
+	{ .compatible = "moxa,moxart-watchdog" },
+	{ },
+};
+
+static struct platform_driver moxart_wdt_driver = {
+	.probe      = moxart_wdt_probe,
+	.remove     = moxart_wdt_remove,
+	.driver     = {
+		.name		= "moxart-watchdog",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_watchdog_match,
+	},
+};
+module_platform_driver(moxart_wdt_driver);
+
+module_param(heartbeat, int, 0);
+MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");
+
+MODULE_DESCRIPTION("MOXART watchdog driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From Dave.Martin at arm.com  Fri Jul 19 06:28:49 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Fri, 19 Jul 2013 11:28:49 +0100
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <alpine.LFD.2.03.1307181452480.14924@syhkavp.arg>
References: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
 <1374118116-16836-2-git-send-email-nicolas.pitre@linaro.org>
 <20130718150408.GB2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181231510.14924@syhkavp.arg>
 <20130718180323.GC2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181452480.14924@syhkavp.arg>
Message-ID: <20130719102844.GA3746@localhost.localdomain>

On Thu, Jul 18, 2013 at 02:59:06PM -0400, Nicolas Pitre wrote:
> On Thu, 18 Jul 2013, Dave Martin wrote:
> 
> > On Thu, Jul 18, 2013 at 01:24:48PM -0400, Nicolas Pitre wrote:
> > > [ added Russell for his opinion on the patch below ]
> > 
> > [...]
> > 
> > > commit 390cf8b9b83eeeebdfef51912f5003a6a9b84115
> > > Author: Nicolas Pitre <nicolas.pitre at linaro.org>
> > > Date:   Thu Jul 18 13:12:48 2013 -0400
> > > 
> > >     ARM: cacheflush: consolidate single-CPU ARMv7 cache disabling code
> > >     
> > >     This code is becoming duplicated in many places.  So let's consolidate
> > >     it into a handy macro that is known to be right and available for reuse.
> > >     
> > >     Signed-off-by: Nicolas Pitre <nico at linaro.org>
> > > 
> > > diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
> > > index 17d0ae8672..8a76933e80 100644
> > > --- a/arch/arm/include/asm/cacheflush.h
> > > +++ b/arch/arm/include/asm/cacheflush.h
> > > @@ -436,4 +436,33 @@ static inline void __sync_cache_range_r(volatile void *p, size_t size)
> > >  #define sync_cache_w(ptr) __sync_cache_range_w(ptr, sizeof *(ptr))
> > >  #define sync_cache_r(ptr) __sync_cache_range_r(ptr, sizeof *(ptr))
> > >  
> > > +/*
> > > + * Disabling cache access for one CPU in an ARMv7 SMP system is tricky.
> > > + * To do so we must:
> > > + *
> > > + * - Clear the SCTLR.C bit to prevent further cache allocations
> > > + * - Flush the desired level of cache
> > > + * - Clear the ACTLR "SMP" bit to disable local coherency
> > > + *
> > > + * ... and so without any intervening memory access in between those steps,
> > > + * not even to the stack.
> > > + *
> > > + * The clobber list is dictated by the call to v7_flush_dcache_*.
> > > + */
> > > +#define v7_disable_flush_cache(level) \
> > > +	asm volatile( \
> > > +	"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t" \
> > > +	"bic	r0, r0, #"__stringify(CR_C)" \n\t" \
> > > +	"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t" \
> > > +	"isb	\n\t" \
> > > +	"bl	v7_flush_dcache_"__stringify(level)" \n\t" \
> > > +	"clrex	\n\t" \
> > > +	"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t" \
> > > +	"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t" \
> > > +	"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t" \
> > > +	"isb	\n\t" \
> > > +	"dsb	" \
> > > +	: : : "r0","r1","r2","r3","r4","r5","r6","r7", \
> > > +	      "r9","r10","r11","lr","memory" )
> > > +
> > >  #endif
> > 
> > That's roughly what I had in mind, though it might belong somewhere more
> > obscure than cacheflush.h(?)
> 
> Any suggestions for that?  Maybe asm/mcpm.h but that might be used in 
> other circumstances as well.

I don't really have a better idea...  if nobody objects strongly to
putting it in cacheflush.h, I happy to go with that.
> 
> > "disable_flush_cache" sounds a too general-purpose for my liking.
> > 
> > "v7" isn't really right because we touch the ACTLR.  This only works
> > on certain CPUs and when Linux is running Secure.  Maybe saying "a15"
> > instead of "a7" is reasonable, since a7 is supposed to be an a15
> > workalike in most places.
> 
> Isn't this how this should be done on an A9 too?  Lorenzo asked me to do 

Quite possibly -- the point is, it's not guaranteed that all v7 CPUs will
work the same way, especially the custom implementations.   Third-party v7
implementations like Snapdragon etc. need not be in any way the same as
ARM's CPUs with regard to details like the SMP bit.

> it this way, by fear of seeing people copy the previous implementation, 
> so the same sequence works on A9 as well as A15.

Would it make sense to have things like

#define a15_something() asm(volatile ... )
#define a7_something() a15_something()
#define a9_something() a15_something()

(where the correct one to call for a b.L system would probably be the
one corresponding to the big cluster)

... or just call is something like

cortex_a_something()

with a big comment (or alias macros, as above) documenting which CPUs we
know it works for, and warning people to stop and think before using it
on some other CPU.

> > I had other names in mind, like "coherency_exit" or "cache_exit".
> > Those are not very intelligible, but that might at least make people
> > pause and think before blindly using it.
> 
> Good point.  It should still embody the architecture name for which it 
> is valid though.

Sure, I was assuming something would be pasted on the start of the name.

Cheers
---Dave


From grygorii.strashko at ti.com  Fri Jul 19 06:29:42 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Fri, 19 Jul 2013 13:29:42 +0300
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130719073957.GZ7656@atomide.com>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost> <51E70B5D.6030802@wwwdotorg.org>
 <20130718073638.GP7656@atomide.com> <51E84180.6080902@wwwdotorg.org>
 <20130719073957.GZ7656@atomide.com>
Message-ID: <51E91516.2040301@ti.com>

Hi Tony, Stephen

On 07/19/2013 10:39 AM, Tony Lindgren wrote:
> * Stephen Warren <swarren at wwwdotorg.org> [130718 12:33]:
>> On 07/18/2013 01:36 AM, Tony Lindgren wrote:
>>> * Stephen Warren <swarren at wwwdotorg.org> [130717 14:30]:
>>>> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
>> ...
>>>> Why shouldn't e.g. a pinctrl-based I2C mux also be able to do runtime
>>>> PM? Does the mux setting select which states are used for runtime PM, or
>>>> does runtime PM override the basic mux setting, or must the pincrl-I2C
>>>> mux manually implement custom runtime-PM/pinctrl interaction since
>>>> there's no generic answer to those questions? How many more custom
>>>> exceptions will there be?
>>>
>>> The idea is that runtime PM will never touch the basic mux settings
>>> at all. The "default" state should be considered a static state
>>> that is claimed during driver probe, and released when the driver
>>> is unloaded. This is typically let's say 90% of the pins for any
>>> device.
>>>
>>> For runtime PM, we can just toggle the PM related pinctrl states as
>>> they have been verified to match the active state during init.
>>>
>>> So I don't see why pinctrl-I2C would have to do anything specific.
>>> All that is required is that the pins are grouped for the consumer
>>> driver, and we can provide some automated checks on the states for
>>> runtime PM.
>>
>> So, consider a pinctrl-based I2C mux. It has 2 states to cover two I2C
>> buses:
>>
>> a) bus 1: I2C controller is muxed out onto one set of pins.
>>
>> b) bus 2: I2C controller is muxed out onto another set of pins.
>>
>> Now, the system could go idle in either of those 2 states, and then
>> later need to return to one of those states. I just don't see how that
>> would work, since the runtime PM code in this series switches to *an*
>> active state when the device becomes non-idle. If the definition of the
>> idle state switches the mux function for both sets of pins to some
>> idle/quiescent value, then you'd need to do different reprogramming when
>> going back to "the" active state; I guess the system would need to
>> remember which state was active before switching to idle, then switch
>> back to that same state rather than hard-coding the active state name as
>> "active"...
>
> I think the only sane way to deal with this is to make the I2C controller
> to show up as two separate I2C controller instances. Then use runtime
> PM to save and restore the state for each instance, and locking between
> the two driver instances.
>
> For the pin muxing part, I'd do this:
>
> 			i2c1 instance	i2c2 instance	notes
> default_state		0 pins		0 pins		(or dedicated pins only)
> active_state		all pins	alls pins
> idle_state		safe mode	safe mode
>
> Then when i2c1 instance is done, it's runtime PM suspend muxes the pins
> to safe mode, or some nop state. Then when i2c2 instance is woken, it's
> runtime PM resume muxes pins to i2c2.

First of all, I'd like to mention that these patches do *not* connect
pinctrl to PM runtime, so until driver will call pinctrl_select_state()
or pinctrl_pm_select_*() there will be no pins state changes.
(As result, i2c-mux is not good example, seems:))

And I think, some sort of summary need to be done to explain how system 
will behave after these patches in comparison to how it was before:

1) Device has pins states defined and driver uses pinctrl_select_state
(lets say legacy mode):
- "default" - no changes
- "default"+"idle"/"sleep" - no changes
- "default" + any other states - no chages
- "default"+"active" + "idle"/"sleep" - behavior will be *changed*
   pinctrl_bind_pins() will do:
   a) pinctrl_select_state("default")
   b) pinctrl_select_dynamic("active")
   but, driver uses pinctrl_select_state() to change pins state during
its work -- Is it ok?

2) Device has pins states defined and driver uses pinctrl_pm_select_*() 
API only:
- if no "active" defined - behavior will be the same as for legacy mode
- "default"+"active" + "idle"/"sleep" - will behave as explained in doc

3)  Device has pins states defined and driver uses
pinctrl_pm_select_*() API and pinctrl_select_state() simultaneously:
- if no "active" defined - behavior will be the same as for legacy mode
- "default"+"active" + "idle"/"sleep" + "stateX"
   How it will work if during suspend driver will do:??
   if (conditionY)
         pinctrl_select_state(stateX);
   pinctrl_pm_select_sleep_state("sleep")
Is it valid?

   How it will work if during runtime resuming driver will do:??
   if (conditionY)
         pinctrl_select_state(stateX);
   pinctrl_pm_select_active_state("active");
Is it valid?

Any way, if driver don't want support introduced default/common behavior 
- all it need is to not define "active" state.

Uh, hope it will be useful and I have correct understandings here :)

>
> Regards,
>
> Tony

Regards,
- grygorii



From broonie at kernel.org  Fri Jul 19 06:32:32 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 19 Jul 2013 11:32:32 +0100
Subject: [alsa-devel] [PATCH] ASoC: atmel: add wm8904 based audio machine
 driver
In-Reply-To: <51E8D75C.7030707@atmel.com>
References: <1374132483-25375-1-git-send-email-voice.shen@atmel.com>
 <20130718111709.GL22506@sirena.org.uk> <51E8A6EF.4040608@atmel.com>
 <51E8D75C.7030707@atmel.com>
Message-ID: <20130719103232.GH9858@sirena.org.uk>

On Fri, Jul 19, 2013 at 02:06:20PM +0800, Bo Shen wrote:
> On 07/19/2013 10:39 AM, Bo Shen wrote:

> >I will try to implement this in next version.

> After check the clock implementation, we are on the way to common
> clock framework, so will do this after we fully transfer to common
> clock.

OK, that makes sense - just leave things as they are for now.
-------------- 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/20130719/2b32b927/attachment.sig>

From gioh.kim at lge.com  Fri Jul 19 06:45:36 2013
From: gioh.kim at lge.com (Gioh Kim)
Date: Fri, 19 Jul 2013 19:45:36 +0900
Subject: [PATCH] [RFC] EHCI: add to memory barrier to updating hw_next
In-Reply-To: <Pine.LNX.4.44L0.1307181004190.1245-100000@iolanthe.rowland.org>
References: <CACVXFVNV-hGZpcy2ANQaca1K5yXJ88EOq1PTkJUEHEkFk9Btvw@mail.gmail.com>
 <Pine.LNX.4.44L0.1307181004190.1245-100000@iolanthe.rowland.org>
Message-ID: <003101ce846d$1a74ffa0$4f5efee0$@lge.com>

Thanks a lot for your replay.

> -----Original Message-----
> From: Alan Stern [mailto:stern at rowland.harvard.edu]
> Sent: Thursday, July 18, 2013 11:09 PM
> To: Ming Lei
> Cc: Gioh Kim; linux-usb at vger.kernel.org; linux-kernel at vger.kernel.org;
> Mark Salter; namhyung.kim at lge.com; Minchan Kim; Chanho Min; Jong-Sung Kim;
> linux-arm-kernel
> Subject: Re: [PATCH] [RFC] EHCI: add to memory barrier to updating hw_next
> 
> On Thu, 18 Jul 2013, Ming Lei wrote:
> 
> > > I guess that HC could have a use-after-free problem like following
> situation.
> > >
> > > 1. A qtd which is not at the queue head should be removed in
> qh_completions().
> > > 2. The last->hw_next become be pointing at the next qtd but the
> hw_next value is delayed in write-buffer.
> > > 3. The qtd is removed in the list.
> > > 4. The qtd is freed into DMA pool and re-allocated for another urb.
> > > 5. HC try to process last->hw_next and it is pointing re-allocated
qtd.
> > >
> > > What do you think about it? Is it possible?
> >
> > I understand it might not be possible because:  when 'stopped' is set,
> > that said the HC might not advance the queue. But I don't understand
> > why 'last->hw_next' is patched here under 'stopped' situation.
> 
> It should not be possible.  When "stopped" is set, the QH gets unlinked
> and relinked before it can start up again.  Relinking involves some memory
> barriers, so the qTD will not be accessed again by the HC.
> 
> last->hw_next gets patched because the qTD might belong to some URB in
> the middle of the queue that is being unlinked.  The URBs before it and
> after it will still be active, so the queue link has to be updated.
> 


You're right. I misunderstand those codes. Please forget about it.


> > Even the 'stopped' case may be seldom triggered, do you know under
> > which condition the stopped is triggered in your problem?(stall, short
> > read or others)
> 
> I was going to ask the same question.  This particular piece of code gets
> executed _only_ when an URB is unlinked.  Not during any other kind of
> error.


I've got the problem when I listened to the mp3 file of USB HDD.
I checked the urb data when the problem occurred, the last-status value of
urb was EINPROGRESS and 
urb->unlinked was ECONNRESET. 
I think the 'stopped' case was occurred by the reset of USB port.
The block device driver did reset USB port because there is no return from
USB device.
If I made block device driver could not reset USB port, the EHCI driver
codes were not executed.
Finally the halt of HC makes 'stopped' case.

I think halt of the HC might be caused that store-buffer delays command for
HC.
When I applied the patch from https://lkml.org/lkml/2011/8/31/344 and added
a mb() into hw_next updating
to remove delay of store-buffer, My platform works well.

Can the store-buffer delay halt HC? Is it possible?

IMHO, if the qTD list is broken the HC think there is no qTD to send.
So I added mb() at hw_next update code.





> 
> Alan Stern



From tony at atomide.com  Fri Jul 19 06:45:38 2013
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Jul 2013 03:45:38 -0700
Subject: [GIT PULL] omap fixes against v3.11-rc1
Message-ID: <20130719104538.GE7656@atomide.com>


The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/fixes-against-rc1

for you to fetch changes up to 7956c487e407bdbf7f8c8a570fd5d4d089973692:

  Merge branch 'omap-for-v3.11/dt-fixes' into omap-for-v3.11/fixes (2013-07-19 03:28:35 -0700)

----------------------------------------------------------------

Omap fixes mostly to deal with the dropping of platform
data for omap4, and to make v7_defconfig bootable on omap4
SDP with nfsroot.

----------------------------------------------------------------
Roger Quadros (1):
      ARM: OMAP2+: Provide alias to USB PHY clock

Tony Lindgren (3):
      ARM: multi_v7: Enabled omap4430 sdp nfsroot
      ARM: dts: Add missing vmmc2 regulator for twl
      Merge branch 'omap-for-v3.11/dt-fixes' into omap-for-v3.11/fixes

 arch/arm/boot/dts/twl4030.dtsi      |  6 ++++++
 arch/arm/configs/multi_v7_defconfig |  3 +++
 arch/arm/mach-omap2/board-generic.c | 23 ++++++++++++++++++++++-
 3 files changed, 31 insertions(+), 1 deletion(-)


From mkl at pengutronix.de  Fri Jul 19 06:46:05 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Fri, 19 Jul 2013 12:46:05 +0200
Subject: [PATCH v2 16/24] net: can: mscan: make mpc512x code use common
 clock
In-Reply-To: <20130719094143.GQ7080@book.gsilab.sittig.org>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374178858-8683-2-git-send-email-gsi@denx.de>
 <51E8EC17.9060703@pengutronix.de>
 <20130719094143.GQ7080@book.gsilab.sittig.org>
Message-ID: <51E918ED.80002@pengutronix.de>

On 07/19/2013 11:41 AM, Gerhard Sittig wrote:
> On Fri, Jul 19, 2013 at 09:34 +0200, Marc Kleine-Budde wrote:
>>
>> On 07/18/2013 10:20 PM, Gerhard Sittig wrote:
>>> extend the mscan(4) driver with alternative support for the COMMON_CLK
>>> approach which is an option in the MPC512x platform, keep the existing
>>> clock support implementation in place since the driver is shared with
>>> other MPC5xxx SoCs which don't have common clock support
>>>
>>> one byproduct of this change is that the CAN driver no longer needs to
>>> access the SoC's clock control registers, which shall be the domain of
>>> the platform's clock driver
>>>
>>> Signed-off-by: Gerhard Sittig <gsi at denx.de>
>>> ---
>>>  drivers/net/can/mscan/mpc5xxx_can.c |  139 +++++++++++++++++++++++++++++++++++
>>>  1 file changed, 139 insertions(+)
>>>
>>> diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
>>> index bc422ba..dd26ab6 100644
>>> --- a/drivers/net/can/mscan/mpc5xxx_can.c
>>> +++ b/drivers/net/can/mscan/mpc5xxx_can.c
>>> @@ -108,6 +108,143 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
>>>  #endif /* CONFIG_PPC_MPC52xx */
>>>  
>>>  #ifdef CONFIG_PPC_MPC512x
>>> +
>>> +#if IS_ENABLED(CONFIG_COMMON_CLK)
>>> +
>>> +static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
>>> +				 const char *clock_source, int *mscan_clksrc)
>>> +{
>>> +	struct device_node *np;
>>> +	u32 clockdiv;
>>> +	enum {
>>> +		CLK_FROM_AUTO,
>>> +		CLK_FROM_IPS,
>>> +		CLK_FROM_SYS,
>>> +		CLK_FROM_REF,
>>> +	} clk_from;
>>> +	struct clk *clk_in, *clk_can;
>>> +	unsigned long freq_calc;
>>> +
>>> +	/* the caller passed in the clock source spec that was read from
>>> +	 * the device tree, get the optional clock divider as well
>>> +	 */
>>> +	np = ofdev->dev.of_node;
>>> +	clockdiv = 1;
>>> +	of_property_read_u32(np, "fsl,mscan-clock-divider", &clockdiv);
>>> +	dev_dbg(&ofdev->dev, "device tree specs: clk src[%s] div[%d]\n",
>>> +		clock_source ? clock_source : "<NULL>", clockdiv);
>>> +
>>> +	/* when clock-source is 'ip', the CANCTL1[CLKSRC] bit needs to
>>> +	 * get set, and the 'ips' clock is the input to the MSCAN
>>> +	 * component
>>> +	 *
>>> +	 * for clock-source values of 'ref' or 'sys' the CANCTL1[CLKSRC]
>>> +	 * bit needs to get cleared, an optional clock-divider may have
>>> +	 * been specified (the default value is 1), the appropriate
>>> +	 * MSCAN related MCLK is the input to the MSCAN component
>>> +	 *
>>> +	 * in the absence of a clock-source spec, first an optimal clock
>>> +	 * gets determined based on the 'sys' clock, if that fails the
>>> +	 * 'ref' clock is used
>>> +	 */
>>> +	clk_from = CLK_FROM_AUTO;
>>> +	if (clock_source) {
>>> +		/* interpret the device tree's spec for the clock source */
>>> +		if (!strcmp(clock_source, "ip"))
>>> +			clk_from = CLK_FROM_IPS;
>>> +		else if (!strcmp(clock_source, "sys"))
>>> +			clk_from = CLK_FROM_SYS;
>>> +		else if (!strcmp(clock_source, "ref"))
>>> +			clk_from = CLK_FROM_REF;
>>> +		else
>>> +			goto err_invalid;
>>> +		dev_dbg(&ofdev->dev, "got a clk source spec[%d]\n", clk_from);
>>> +	}
>>> +	if (clk_from == CLK_FROM_AUTO) {
>>> +		/* no spec so far, try the 'sys' clock; round to the
>>> +		 * next MHz and see if we can get a multiple of 16MHz
>>> +		 */
>>> +		dev_dbg(&ofdev->dev, "no clk source spec, trying SYS\n");
>>> +		clk_in = clk_get(&ofdev->dev, "sys");
>>> +		if (IS_ERR(clk_in))
>>> +			goto err_notavail;
>>> +		freq_calc = clk_get_rate(clk_in);
>>> +		freq_calc +=  499999;
>>> +		freq_calc /= 1000000;
>>> +		freq_calc *= 1000000;
>>> +		if ((freq_calc % 16000000) == 0) {
>>> +			clk_from = CLK_FROM_SYS;
>>> +			clockdiv = freq_calc / 16000000;
>>> +			dev_dbg(&ofdev->dev,
>>> +				"clk fit, sys[%lu] div[%d] freq[%lu]\n",
>>> +				freq_calc, clockdiv, freq_calc / clockdiv);
>>> +		}
>>> +	}
>>> +	if (clk_from == CLK_FROM_AUTO) {
>>> +		/* no spec so far, use the 'ref' clock */
>>> +		dev_dbg(&ofdev->dev, "no clk source spec, trying REF\n");
>>> +		clk_in = clk_get(&ofdev->dev, "ref");
>>> +		if (IS_ERR(clk_in))
>>> +			goto err_notavail;
>>> +		clk_from = CLK_FROM_REF;
>>> +		freq_calc = clk_get_rate(clk_in);
>>> +		dev_dbg(&ofdev->dev,
>>> +			"clk fit, ref[%lu] (no div) freq[%lu]\n",
>>> +			freq_calc, freq_calc);
>>> +	}
>>> +
>>> +	/* select IPS or MCLK as the MSCAN input (returned to the caller),
>>> +	 * setup the MCLK mux source and rate if applicable, apply the
>>> +	 * optionally specified or derived above divider, and determine
>>> +	 * the actual resulting clock rate to return to the caller
>>> +	 */
>>> +	switch (clk_from) {
>>> +	case CLK_FROM_IPS:
>>> +		clk_can = clk_get(&ofdev->dev, "ips");
>>> +		if (IS_ERR(clk_can))
>>> +			goto err_notavail;
>>> +		clk_prepare_enable(clk_can);
>>
>> Where is the corresponding clk_disable_unprepare()?a
> 
> It's missing, as I could not find the counterpart of the
> .get_clock() callback where the get and prepare/enable was added
> to.  And it appears that neither are enable errors checked for.
> This patch clearly needs an update as well, but already should be
> the last part of the series in a currently inacceptable state.
> 
> This .get_clock() routine is supposed to determine the clock
> source, setup the desired rate and return the actual rate.  The
> callback's API is rather limited in that it does communicate
> clock rate values, but cannot access a location to store handles
> to.

I think the API is sufficient, the ofdev links via drv data to the
netdev
(http://lxr.free-electrons.com/source/drivers/net/can/mscan/mpc5xxx_can.c#L305)
and you get from the netdev to the mscan_priv
(http://lxr.free-electrons.com/source/drivers/net/can/mscan/mpc5xxx_can.c#L281).

BTW: You should prepare_enable the clock in the ndo_open() callback,
i.e. mscan_open() and disable_unprepare in mscan_close(). Doing this you
maximize the power saving effect by not powering the mscan IP core if
the CAN device is not up.

> Are the introduction of a .put_clock() callback and passing the
> 'priv' handle to both get and put routines acceptable?  As this
> would hook up clock handling to probe() and remove() just as
> memory mapping gets approached.

I think an additional priv parameter is not needed. get_ and put_clock()
in probe() and remove() is good, but put the
prepare_enable()/disable_unprepare() in open()/close().

> Below is a patch on top of the CAN related patch in v2 of the
> series.  If this approach is acceptable (maybe modulo how the
> "unused" warnings get silenced), I'll fold it into the
> introduction of common clock support in the mscan(4) driver.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130719/a63fef52/attachment-0001.sig>

From r.sricharan at ti.com  Fri Jul 19 06:48:11 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Fri, 19 Jul 2013 16:18:11 +0530
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <CAGo_u6rO0SjHzXhMBPeSmWykqqpf9phLEPBEaeFtS9bkHoq8qg@mail.gmail.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <51E83A4F.5080904@ti.com> <51E87C98.5030001@ti.com>
 <CAGo_u6rO0SjHzXhMBPeSmWykqqpf9phLEPBEaeFtS9bkHoq8qg@mail.gmail.com>
Message-ID: <51E9196B.3070900@ti.com>

Hi,

On Friday 19 July 2013 05:43 AM, Nishanth Menon wrote:
> On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar
> <santosh.shilimkar at ti.com> wrote:
>> On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
>>> On 07/18/2013 11:43 AM, Sricharan R wrote:
>>>> Some socs have a large number of interrupts/dma requests to service
>>>> the needs of its many peripherals and subsystems. All of the
>>>> requests lines from the subsystems are not needed at the same
>>>> time, so they have to be muxed to the controllers appropriately.
>>>> In such places a interrupt/dma controllers are preceded by an
>>>> IRQ/DMA CROSSBAR that provides flexibility in muxing the device
>>>> requests to the controller inputs.
>>>>
>>>> The Peripheral irq/dma requests are connected to one crossbar's input
>>>> and the output of the crossbar is connected to controller's input
>>>> line. On POR, there are some mappings which are done by default.
>>>> Those peripherals which do not have a mapping on POR, should be configured
>>>> to route its requests using the crossbar.
>>>>
>>>> The drivers identifies every controller's crossbar as individual devices.
>>>> The mappings can be specified from the DT crossbar nodes and those gets mapped
>>>> during the crossbar device's probe. The mappings can also be specified by adding
>>>> the crossbar lines to the peripheral device nodes and map it with
>>>> crossbar_map/unmap apis.
>>>>
>>>> Signed-off-by: Sricharan R <r.sricharan at ti.com>
>>>> ---
>>>>   .../devicetree/bindings/arm/omap/crossbar.txt      |   24 ++
>>>>   drivers/misc/Kconfig                               |    8 +
>>>>   drivers/misc/Makefile                              |    1 +
>>>>   drivers/misc/crossbar.c                            |  258 ++++++++++++++++++++
>>>>   include/linux/crossbar.h                           |   71 ++++++
>>>>   5 files changed, 362 insertions(+)
>>>>   create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>>>   create mode 100644 drivers/misc/crossbar.c
>>>>   create mode 100644 include/linux/crossbar.h
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>>> new file mode 100644
>>>> index 0000000..02a8a28
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>>> @@ -0,0 +1,24 @@
>>>> +* TI - IRQ/DMA Crossbar
>>>> +
>>>> +This version is an implementation of the Crossbar IRQ/DMA IP
>>>> +
>>>> +Required properties:
>>>> +- compatible : Should be "ti,dra-crossbar"
>>>> +- crossbar-name: Name of the controller to which crossbar output is routed
>>>> +- reg:    Contains crossbar register address range
>>>> +- reg-width: Represents the width of the individual registers
>>>> +- crossbar-lines:  Default mappings.Should contain the crossbar-name
>>>> +           device name, int/dma request number, crossbar number,
>>>> +           register offset in the same order.
>>>> +
>>>> +Examples:
>>>> +        crossbar_mpu: mpuirq at 4a002a48 {
>>>> +            compatible = "crossbar";
>>>> +            crossbar-name = "mpu-irq";
>>>> +            reg = <0x4a002a48 0x0130>;
>>>> +            reg-width = <16>;
>>>> +            crossbar-lines = "mpu-irq", "rtc-ss-alarm", <0x9f 0xd9 0x12c>,
>>>> +                     "mpu-irq", "mcasp3-arevt", <0x9e 0x96 0x12a>,
>>>> +                     "mpu-irq", "mcasp3-axevt", <0x9d 0x97 0x128>;
>>>> +        };
>>> I carry forward my TI internal objection to this approach:
>>>
>>> NAK.
>>>
>>> DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt is as follows:
>>> hardware IP block -interrupt line-> IRQ Cross bar -> GIC IRQ line --> MPU IRQ.
>>>
>>>
>>> What we have done today for DRA is to provide IRQ numbers as direct maps from hardware IP block to GIC based on default IRQ cross bar mapping.
>>>
>>> Lets see what happens as a result of this:
>>>
>>> https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
>>> uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
>>> uart1: serial at 4806a000 {
>>> <snip>
>>> +            interrupts = <0 72 0x4>;
>>> Assumes that GIC interrupt by default mapping used.
>>>
>>> Now, think of a product that wants to use UART10 instead of UART1, SoC design allows you do that by doing a remapping of GIC interrupt to UART10 - which is awesome.
>>>
>>> Option 1: u-boot/bootloader
>>> mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
>>>
>>> Option 2: in kernel do a raw_writel version of option 1.
>>> This patch does option 1 in kernel in a "fancy way" - why the heck would I want to do that when u-boot allows me to do the same thing in uEnv.txt
>>>
>>> Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
>>> a) Allows us to define every single IP available on DRA7 SoC.
>>> b) GIC allocation happens dynamically
>>> c) allow products use IPs as needed.
>>>
>>> Sorry, Conceptually option 3 is the right approach in my view.
>>> instead of doing
>>> uart1: serial at 4806a000 {
>>> <snip>
>>> +            interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
>>>
>>> we should be able to do the following:
>>> uart1: serial at 4806a000 {
>>> <snip>
>>> +            interrupts = <TI_IRQ_CROSSBAR 192 IRQ_TYPE_LEVEL_HIGH>;
>>>
>>> and not worry about the GIC interrupt number used
>>>
>>>
>> Since the cross-bar is not limited t0 IRQ lines and applicable for
>> DMA request lines as well, making it IRQ chip doesn't make sense. Its
>> not typical pin control functionality either but at least that framework
>> is much closer to consider as an option.
> The core concept is that this is a trivial mapping problem and if can
> extrapolate pinctrl to be mapping for SoC internal signals, oh great!
>
> pinctrl solved a problem where we are not absolutely sure how to
> reallocate SoC *external* pins to board interface. pinctrl works in
> more complex world, each SoC pinout has A options, but not all B SoC
> signals can or will routed there - in fact, inside one single SoC
> family, there never was a pattern even as it all depended on how the
> board manufacturer wanted to do it - and yep, it was easy - a signal
> just had limited number of options it could go to review and pinctrl
> options to do that was simple as well!
>
> The problem here IMHO is different. it is a simple X->Y mapping, where
> X > Y, but any of X can be mapped to any of Y - so, now with a static
> map, you need be sure that you do not map double even by mistake - so
> what ever number of GIC mappings need to be evaluated always every
> time we do a static map change to ensure no conflicts w.r.t board
> usage etc. Doable? sure! Right way to solve a simple X->Y mapping
> problem? I personally don't think so.
>
> <rant>
>
> Now, if we want to force every single DRA7 product board designers and
> s/w board support guy to consider how the DRA internal signals are
> mapped using dts - yes, we are proposing to solve the problem of a
> trivial resource allocation problem with a framework meant to handle
> much more complex muxing problem and ensured that all DRA7 product
> guys will wonder "what the heck were these guys thinking"?
>
> </rant>
  The problems to be solved with Dynamic mappings are
  1) How to populate the drivers resources with the dynamically allocated
       data? This also means that all the drivers should
     be adapted to use crossbar before it does a request_irq.

 2) How to get a dynamic line when there is no "free" line.
      That is how to decide runtime which one to replace.
      We can do this in dts because we know what peripheral is not used
      in a board.

Regards,
 Sricharan


From r.sricharan at ti.com  Fri Jul 19 06:48:31 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Fri, 19 Jul 2013 16:18:31 +0530
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <20130719071728.GX7656@atomide.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <51E83A4F.5080904@ti.com> <51E87C98.5030001@ti.com>
 <20130719071728.GX7656@atomide.com>
Message-ID: <51E9197F.7010608@ti.com>

On Friday 19 July 2013 12:47 PM, Tony Lindgren wrote:
>> On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
>>
>> Since the cross-bar is not limited t0 IRQ lines and applicable for
>> DMA request lines as well, making it IRQ chip doesn't make sense. Its
>> not typical pin control functionality either but at least that framework
>> is much closer to consider as an option.
>>
>> Actually its more of setting up the IRQ and DMA pins maps once
>> at boot for a given SOC based on chosen configuration by the
>> board. So I am leaning towards pinctrl as well. Just haven't
>> thought enough about whether thats the best approach.
>>
>> CC'ing Linus W and Tony L whether we can use pinctrl framework
>> for such an IP and if yes how ;-).
> If it really muxes signals then using pinctrl seems logical.
> Especially if the registers are in the SCM block.
>
> It might be already possible to handle it already with
> pinctrl-single,bits for the muxing part.
 I also thought of using the pinctrl itself.
 But then i wanted  to have the error handling as well,
 hence did this.

Regards,
 Sricharan


From daniel.lezcano at linaro.org  Fri Jul 19 06:52:34 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 19 Jul 2013 12:52:34 +0200
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <1374218064.24607.1.camel@jlo-ubuntu-64.nvidia.com>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
 <51E6FF0B.5000708@wwwdotorg.org>
 <1374145726.5610.73.camel@jlo-ubuntu-64.nvidia.com>
 <51E7E27B.9090605@linaro.org>
 <1374218064.24607.1.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <51E91A72.6070708@linaro.org>

On 07/19/2013 09:14 AM, Joseph Lo wrote:
> On Thu, 2013-07-18 at 20:41 +0800, Daniel Lezcano wrote:
>> On 07/18/2013 01:08 PM, Joseph Lo wrote:
>>> On Thu, 2013-07-18 at 04:31 +0800, Stephen Warren wrote:
>>>> On 07/17/2013 04:15 AM, Joseph Lo wrote:
>>>>> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
>>>>>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
>>>>>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
>>>>>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
>>>>>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
>>>>>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
>>>>>>>>> this state.
>>>> ... [ discussion of issues with Joesph's patches applied]
>>>>>
>>>>> OK. I did more stress tests last night and today. I found it cause by
>>>>> the patch "ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag" and
>>>>> only impact the Tegra20 platform. The hot plug regression seems due to
>>>>> this patch. After dropping this patch on top of v3.11-rc1, the Tegra20
>>>>> can back to normal.
>>>>>
>>>>> And the hop plug and suspend stress test can pass on Tegra30/114 too.
>>>>>
>>>>> Can the other two patch series for Tegra114 to support CPU idle power
>>>>> down mode and system suspend still moving forward, not be blocked by
>>>>> this patch?
>>>>>
>>>>> Looks the CPUIDLE_FLAG_TIMER_STOP flag still cause some other issue for
>>>>> hot plug on Tegra20, I will continue to check this. You can just drop
>>>>> this patch.
>>>>
>>>> OK, if I drop that patch, then everything on Tegra20 and Tegra30 seems
>>>> fine again.
>>>>
>>>> However, I've found some new and exciting issue on Tegra114!
>>>>
>>>> With unmodified v3.11-rc1, I can do the following without issue:
>>>>
>>>> * Unplug/replug CPUs, so that I had all combinations of CPU 1, 2, 3
>>>> plugged/unpplugged (with CPU 0 always plugged).
>>>>
>>>> * Unplug/replug CPUs, so that I had all combinations of CPU 0, 1, 2, 3
>>>> plugged/unpplugged (with the obvious exception of never having all CPUs
>>>> unplugged).
>>>>
>>>> However, if I try this with your Tegra114 cpuidle and suspend patches
>>>> applied, I see the following issues:
>>>>
>>>> 1) If I boot, unplug CPU 0, then replug CPU 0, the system immediately
>>>> hard-hangs.
>>>>
>>> Sorry, I didn't apply the hotplug stress test on CPU0 too much. Because
>>> all of our use cases and stress tests are focused on secondary CPUs
>>> only.
>>>
>>> After doing some tests, here is my summary. This issue happens after we
>>> support CPU idle power-down mode and relates to PMC or flow controller I
>>> believe.
>>>
>>> i) on top of v3.11-rc1 (only support WFI in CPU idle)
>>> When hot unplug CPU0, the PMC can power gate and put it into reset
>>> state. This is what I expect and also true on all the other secondary
>>> CPUs. The flow controller can maintain the CPU power state machine as
>>> what we want.
>>>
>>> ii) on top of v3.11-rc1 + CPU idle power down mode support
>>> a) I saw most of the time the CPU0,1,2,3 were in power down and reset
>>> status. That means the idle power down mode works fine.
>>>
>>> b) Testing with the CPU hotplug stress test with the secondary CPUs (not
>>> include CPU0), the result is good too.
>>>
>>> c) Testing hot plug on CPU0 with CPUIDLE_FLAG_TIMER_STOP apply or not
>>> apply (Note 1), the result shows not good to me. The CPU0 have already
>>> gone into WFI and the flow controller is set as WAITFOREVENT mode. But
>>> the PMC always can't power gate CPU0 and sometimes can put it into
>>> reset, but sometimes can't. That's why you can see it hanging after
>>> unplug CPU0 sometimes.
>>
>> Are sure coupled idle state support hotplug and especially the cpu0
>> hotplug ?
> 
> Tegra114 didn't use coupled idle framework.

Ok, so the problem occurs with the CPUIDLE_FLAG_TIMER_STOP flag only on
tegra114, right ?

Sorry, I am a bit lost :)


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From ben.dooks at codethink.co.uk  Fri Jul 19 06:58:45 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Fri, 19 Jul 2013 11:58:45 +0100
Subject: alignment handler instruction endian-ness
Message-ID: <51E91BE5.8070809@codethink.co.uk>

I ran in to an issue with the alignment handler when running BE8 where
it loads instructions and fails to swap.

Is there a better way of swapping instructions for ARM when loading
from arbitrary places? Have I missed any other places this could happen?

The following patch is my first attempt at solving the problem for the
alignment handler:

> Author: Ben Dooks <ben.dooks at codethink.co.uk>
> Date:   Thu Jul 18 21:10:56 2013 +0100
>
>     arm: alignment: deal with be8 mode when decoding instructions
>
>     If we are in BE8 mode, we must deal with the instruction stream being
>     in LE order when data is being loaded in BE order. Ensure the data is
>     swapped before processing to avoid thre following:
>
>     Alignment trap: not handling instruction 030091e8 at [<80333e8c>]
>     Unhandled fault: alignment exception (0x001) at 0xbfa09567
>
>     Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
 >
> diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
> index db26e2e..e8793a7 100644
> --- a/arch/arm/mm/alignment.c
> +++ b/arch/arm/mm/alignment.c
> @@ -87,6 +87,12 @@ core_param(alignment, ai_usermode, int, 0600);
>  #define UM_FIXUP       (1 << 1)
>  #define UM_SIGNAL      (1 << 2)
>
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +#define need_swap()    true
> +#else
> +#define need_swap()    false
> +#endif
> +
>  /* Return true if and only if the ARMv6 unaligned access model is in use. */
>  static bool cpu_is_v6_unaligned(void)
>  {
> @@ -762,12 +768,16 @@ do_alignment(unsigned long addr, unsigned int fsr, struct
>         if (thumb_mode(regs)) {
>                 u16 *ptr = (u16 *)(instrptr & ~1);
>                 fault = probe_kernel_address(ptr, tinstr);
> +               if (need_swap())
> +                       tinstr = cpu_to_le16(tinstr);
>                 if (!fault) {
>                         if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
>                             IS_T32(tinstr)) {
>                                 /* Thumb-2 32-bit */
>                                 u16 tinst2 = 0;
>                                 fault = probe_kernel_address(ptr + 1, tinst2);
> +                               if (need_swap())
> +                                       tinst2 = cpu_to_le16(tinst2);
>                                 instr = (tinstr << 16) | tinst2;
>                                 thumb2_32b = 1;
>                         } else {
> @@ -775,8 +785,11 @@ do_alignment(unsigned long addr, unsigned int fsr, struct p
>                                 instr = thumb2arm(tinstr);
>                         }
>                 }
> -       } else
> +       } else {
>                 fault = probe_kernel_address(instrptr, instr);
> +               if (need_swap())
> +                       instr = cpu_to_le32(instr);
> +       }
>
>         if (fault) {
>                 type = TYPE_FAULT;


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From lorenzo.pieralisi at arm.com  Fri Jul 19 06:59:07 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 19 Jul 2013 11:59:07 +0100
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <20130719102844.GA3746@localhost.localdomain>
References: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
 <1374118116-16836-2-git-send-email-nicolas.pitre@linaro.org>
 <20130718150408.GB2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181231510.14924@syhkavp.arg>
 <20130718180323.GC2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181452480.14924@syhkavp.arg>
 <20130719102844.GA3746@localhost.localdomain>
Message-ID: <20130719105907.GB27389@e102568-lin.cambridge.arm.com>

On Fri, Jul 19, 2013 at 11:28:49AM +0100, Dave Martin wrote:
> On Thu, Jul 18, 2013 at 02:59:06PM -0400, Nicolas Pitre wrote:
> > On Thu, 18 Jul 2013, Dave Martin wrote:
> > 
> > > On Thu, Jul 18, 2013 at 01:24:48PM -0400, Nicolas Pitre wrote:
> > > > [ added Russell for his opinion on the patch below ]
> > > 
> > > [...]
> > > 
> > > > commit 390cf8b9b83eeeebdfef51912f5003a6a9b84115
> > > > Author: Nicolas Pitre <nicolas.pitre at linaro.org>
> > > > Date:   Thu Jul 18 13:12:48 2013 -0400
> > > > 
> > > >     ARM: cacheflush: consolidate single-CPU ARMv7 cache disabling code
> > > >     
> > > >     This code is becoming duplicated in many places.  So let's consolidate
> > > >     it into a handy macro that is known to be right and available for reuse.
> > > >     
> > > >     Signed-off-by: Nicolas Pitre <nico at linaro.org>
> > > > 
> > > > diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
> > > > index 17d0ae8672..8a76933e80 100644
> > > > --- a/arch/arm/include/asm/cacheflush.h
> > > > +++ b/arch/arm/include/asm/cacheflush.h
> > > > @@ -436,4 +436,33 @@ static inline void __sync_cache_range_r(volatile void *p, size_t size)
> > > >  #define sync_cache_w(ptr) __sync_cache_range_w(ptr, sizeof *(ptr))
> > > >  #define sync_cache_r(ptr) __sync_cache_range_r(ptr, sizeof *(ptr))
> > > >  
> > > > +/*
> > > > + * Disabling cache access for one CPU in an ARMv7 SMP system is tricky.
> > > > + * To do so we must:
> > > > + *
> > > > + * - Clear the SCTLR.C bit to prevent further cache allocations
> > > > + * - Flush the desired level of cache
> > > > + * - Clear the ACTLR "SMP" bit to disable local coherency
> > > > + *
> > > > + * ... and so without any intervening memory access in between those steps,
> > > > + * not even to the stack.
> > > > + *
> > > > + * The clobber list is dictated by the call to v7_flush_dcache_*.
> > > > + */
> > > > +#define v7_disable_flush_cache(level) \
> > > > +	asm volatile( \
> > > > +	"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t" \
> > > > +	"bic	r0, r0, #"__stringify(CR_C)" \n\t" \
> > > > +	"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t" \
> > > > +	"isb	\n\t" \
> > > > +	"bl	v7_flush_dcache_"__stringify(level)" \n\t" \
> > > > +	"clrex	\n\t" \
> > > > +	"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t" \
> > > > +	"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t" \
> > > > +	"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t" \
> > > > +	"isb	\n\t" \
> > > > +	"dsb	" \
> > > > +	: : : "r0","r1","r2","r3","r4","r5","r6","r7", \
> > > > +	      "r9","r10","r11","lr","memory" )
> > > > +
> > > >  #endif
> > > 
> > > That's roughly what I had in mind, though it might belong somewhere more
> > > obscure than cacheflush.h(?)
> > 
> > Any suggestions for that?  Maybe asm/mcpm.h but that might be used in 
> > other circumstances as well.
> 
> I don't really have a better idea...  if nobody objects strongly to
> putting it in cacheflush.h, I happy to go with that.
> > 
> > > "disable_flush_cache" sounds a too general-purpose for my liking.
> > > 
> > > "v7" isn't really right because we touch the ACTLR.  This only works
> > > on certain CPUs and when Linux is running Secure.  Maybe saying "a15"
> > > instead of "a7" is reasonable, since a7 is supposed to be an a15
> > > workalike in most places.
> > 
> > Isn't this how this should be done on an A9 too?  Lorenzo asked me to do 
> 
> Quite possibly -- the point is, it's not guaranteed that all v7 CPUs will
> work the same way, especially the custom implementations.   Third-party v7
> implementations like Snapdragon etc. need not be in any way the same as
> ARM's CPUs with regard to details like the SMP bit.

Well, if they change the SMP bit behaviour from what the TRM describes they
certainly know what they are doing, I am not sure we should cater for that,
they will just use their own function if their behaviour differs from
"standard".

At least all v7 implementations I've run into in the kernel (mainline
and platform trees) could have used the sequence above (well, security
notwithstanding).

Also, we should point out that after clearing the C bit ldr/str exclusive
must not be used anymore (even though this is implementation defined since it
depends on a global monitor in DRAM). The macro is also a barrier in
terms of coherency when we call it we should know what to expect,
basically a CPU with caches that are not coherent anymore.

> > it this way, by fear of seeing people copy the previous implementation, 
> > so the same sequence works on A9 as well as A15.
> 
> Would it make sense to have things like
> 
> #define a15_something() asm(volatile ... )
> #define a7_something() a15_something()
> #define a9_something() a15_something()
> 
> (where the correct one to call for a b.L system would probably be the
> one corresponding to the big cluster)
> 
> ... or just call is something like
> 
> cortex_a_something()
> 
> with a big comment (or alias macros, as above) documenting which CPUs we
> know it works for, and warning people to stop and think before using it
> on some other CPU.

It might be, even though a well written comment would do IMHO.

> > > I had other names in mind, like "coherency_exit" or "cache_exit".
> > > Those are not very intelligible, but that might at least make people
> > > pause and think before blindly using it.
> > 
> > Good point.  It should still embody the architecture name for which it 
> > is valid though.
> 
> Sure, I was assuming something would be pasted on the start of the name.

v7 :-) with a comment describing the assumptions (in particular related
as Dave mentioned to the SMP bit behaviour) ?

Lorenzo



From 21cnbao at gmail.com  Fri Jul 19 07:07:16 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Fri, 19 Jul 2013 19:07:16 +0800
Subject: [PATCH 0/6] ASoC: add CSR SiRFSoC sound drivers
Message-ID: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>

This patchset adds CSR SiRFSoC sound drivers including:
1. the platform DMA driver which will be shard by all DAI
2. the I2S CPU DAI driver
3. the USP-based PCM CPU DAI driver
4. CPU DAI and Codec driver for internal chip codec
5. the mach driver for EVB board using internal codec

Barry Song (1):
  arm: prima2: defconfig: enable sound components

Rongjun Ying (5):
  ASoC: sirf: add sirf platform driver which provides DMA
  ASoC: sirf: add I2S CPU DAI driver
  ASoC: usp-pcm: add CPU DAI driver for PCM simulated from USP
  ASoC: sirf-soc-inner: add drivers for both CPU and Codec DAIs
  ASoC: sirf-inner: add mach driver for SiRFSoC internal codec

 arch/arm/configs/prima2_defconfig |  10 +-
 sound/soc/Kconfig                 |   1 +
 sound/soc/Makefile                |   1 +
 sound/soc/sirf/Kconfig            |  18 ++
 sound/soc/sirf/Makefile           |  11 +
 sound/soc/sirf/sirf-audio.h       | 266 ++++++++++++++++
 sound/soc/sirf/sirf-i2s.c         | 411 ++++++++++++++++++++++++
 sound/soc/sirf/sirf-inner.c       | 267 ++++++++++++++++
 sound/soc/sirf/sirf-pcm.c         | 221 +++++++++++++
 sound/soc/sirf/sirf-pcm.h         |  17 +
 sound/soc/sirf/sirf-soc-inner.c   | 653 ++++++++++++++++++++++++++++++++++++++
 sound/soc/sirf/sirf-usp.c         | 481 ++++++++++++++++++++++++++++
 sound/soc/sirf/sirf-usp.h         | 276 ++++++++++++++++
 13 files changed, 2630 insertions(+), 3 deletions(-)
 create mode 100644 sound/soc/sirf/Kconfig
 create mode 100644 sound/soc/sirf/Makefile
 create mode 100644 sound/soc/sirf/sirf-audio.h
 create mode 100644 sound/soc/sirf/sirf-i2s.c
 create mode 100644 sound/soc/sirf/sirf-inner.c
 create mode 100644 sound/soc/sirf/sirf-pcm.c
 create mode 100644 sound/soc/sirf/sirf-pcm.h
 create mode 100644 sound/soc/sirf/sirf-soc-inner.c
 create mode 100644 sound/soc/sirf/sirf-usp.c
 create mode 100644 sound/soc/sirf/sirf-usp.h

-- 
1.8.2.3



From 21cnbao at gmail.com  Fri Jul 19 07:07:17 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Fri, 19 Jul 2013 19:07:17 +0800
Subject: [PATCH 1/6] ASoC: sirf: add sirf platform driver which provides DMA
In-Reply-To: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <1374232042-26088-2-git-send-email-Baohua.Song@csr.com>

From: Rongjun Ying <Rongjun.Ying at csr.com>

this driver uses dmaengine APIs and provides DMA to the CPU DAIs
of I2S, USP and SiRF-soc-inner.
SiRFSoC has 3 audio DAIs: I2S, USP(Universal Serial Ports) and DAI
connected to soc-inner-codec, all of them will use the same DMA
driver here.

Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 sound/soc/Kconfig         |   1 +
 sound/soc/Makefile        |   1 +
 sound/soc/sirf/Kconfig    |   4 +
 sound/soc/sirf/Makefile   |   3 +
 sound/soc/sirf/sirf-pcm.c | 221 ++++++++++++++++++++++++++++++++++++++++++++++
 sound/soc/sirf/sirf-pcm.h |  17 ++++
 6 files changed, 247 insertions(+)
 create mode 100644 sound/soc/sirf/Kconfig
 create mode 100644 sound/soc/sirf/Makefile
 create mode 100644 sound/soc/sirf/sirf-pcm.c
 create mode 100644 sound/soc/sirf/sirf-pcm.h

diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 45eeaa9..2581e55 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -51,6 +51,7 @@ source "sound/soc/pxa/Kconfig"
 source "sound/soc/samsung/Kconfig"
 source "sound/soc/s6000/Kconfig"
 source "sound/soc/sh/Kconfig"
+source "sound/soc/sirf/Kconfig"
 source "sound/soc/spear/Kconfig"
 source "sound/soc/tegra/Kconfig"
 source "sound/soc/txx9/Kconfig"
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index bc02614..e15df84 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_SND_SOC)	+= pxa/
 obj-$(CONFIG_SND_SOC)	+= samsung/
 obj-$(CONFIG_SND_SOC)	+= s6000/
 obj-$(CONFIG_SND_SOC)	+= sh/
+obj-$(CONFIG_SND_SOC)	+= sirf/
 obj-$(CONFIG_SND_SOC)	+= spear/
 obj-$(CONFIG_SND_SOC)	+= tegra/
 obj-$(CONFIG_SND_SOC)	+= txx9/
diff --git a/sound/soc/sirf/Kconfig b/sound/soc/sirf/Kconfig
new file mode 100644
index 0000000..3678aed
--- /dev/null
+++ b/sound/soc/sirf/Kconfig
@@ -0,0 +1,4 @@
+config SND_SIRF_SOC
+	tristate "Platform DMA driver for the SiRF SoC chips"
+	depends on ARCH_SIRF && SND_SOC
+	select SND_SOC_DMAENGINE_PCM
diff --git a/sound/soc/sirf/Makefile b/sound/soc/sirf/Makefile
new file mode 100644
index 0000000..f268b83
--- /dev/null
+++ b/sound/soc/sirf/Makefile
@@ -0,0 +1,3 @@
+snd-soc-sirf-objs := sirf-pcm.o
+
+obj-$(CONFIG_SND_SIRF_SOC) += snd-soc-sirf.o
diff --git a/sound/soc/sirf/sirf-pcm.c b/sound/soc/sirf/sirf-pcm.c
new file mode 100644
index 0000000..d4cb897
--- /dev/null
+++ b/sound/soc/sirf/sirf-pcm.c
@@ -0,0 +1,221 @@
+/*
+ * ALSA PCM interface for the SiRF SoC
+ *
+ * Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group company.
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include <linux/module.h>
+#include <linux/dma-mapping.h>
+#include <linux/sirfsoc_dma.h>
+
+#include <sound/dmaengine_pcm.h>
+#include <sound/core.h>
+#include <sound/pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/control.h>
+#include <sound/initval.h>
+#include <sound/soc.h>
+
+#include "sirf-pcm.h"
+
+static struct snd_pcm_hardware sirf_pcm_hardware = {
+	.info                   = (SNDRV_PCM_INFO_MMAP
+			| SNDRV_PCM_INFO_MMAP_VALID
+			| SNDRV_PCM_INFO_INTERLEAVED
+			| SNDRV_PCM_INFO_BLOCK_TRANSFER
+			| SNDRV_PCM_INFO_RESUME
+			| SNDRV_PCM_INFO_PAUSE),
+	.formats                = (SNDRV_PCM_FMTBIT_S16_LE),
+	.rates                  = (SNDRV_PCM_RATE_48000),
+	.rate_min               = 512,
+	.rate_max               = 115200,
+	.channels_min           = 1,
+	.channels_max           = 2,
+	.buffer_bytes_max       = 64 * 1024,
+	.period_bytes_min       = 128,
+	.period_bytes_max       = 32 * 1024,
+	.periods_min            = 2,
+	.periods_max            = 2,
+};
+
+static int sirf_pcm_open(struct snd_pcm_substream *substream)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct sirf_pcm_dma_data *dma_data;
+	substream->runtime->hw = sirf_pcm_hardware;
+	snd_soc_set_runtime_hwparams(substream, &sirf_pcm_hardware);
+
+	dma_data = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
+
+	return snd_dmaengine_pcm_open_request_chan(substream,
+			(dma_filter_fn)sirfsoc_dma_filter_id,
+			(void *)(dma_data->dma_req));
+}
+
+static int sirf_pcm_hw_params(struct snd_pcm_substream *substream,
+		struct snd_pcm_hw_params *params)
+{
+	struct snd_pcm_runtime *runtime = substream->runtime;
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct sirf_pcm_dma_data *dma_data;
+	struct dma_slave_config config;
+	struct dma_chan *chan;
+	int err = 0;
+
+	dma_data = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
+
+	snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer);
+	runtime->dma_bytes = params_buffer_bytes(params);
+
+	chan = snd_dmaengine_pcm_get_chan(substream);
+	if (!chan)
+		return -EINVAL;
+
+	/* fills in addr_width and direction */
+	err = snd_hwparams_to_dma_slave_config(substream, params, &config);
+	if (err)
+		return err;
+
+	config.dst_addr_width = DMA_SLAVE_BUSWIDTH_8_BYTES;
+	config.src_addr_width = DMA_SLAVE_BUSWIDTH_8_BYTES;
+
+	config.src_addr = runtime->dma_addr;
+	config.dst_addr = runtime->dma_addr;
+	config.src_maxburst = DMA_SLAVE_BUSWIDTH_8_BYTES;
+	config.dst_maxburst = DMA_SLAVE_BUSWIDTH_8_BYTES;
+
+	return dmaengine_slave_config(chan, &config);
+}
+
+static int sirf_pcm_hw_free(struct snd_pcm_substream *substream)
+{
+	snd_pcm_set_runtime_buffer(substream, NULL);
+	return 0;
+}
+
+static int sirf_pcm_mmap(struct snd_pcm_substream *substream,
+		struct vm_area_struct *vma)
+{
+	struct snd_pcm_runtime *runtime = substream->runtime;
+	return dma_mmap_coherent(substream->pcm->card->dev, vma,
+			runtime->dma_area,
+			runtime->dma_addr,
+			runtime->dma_bytes);
+}
+
+static struct snd_pcm_ops sirf_pcm_ops = {
+	.open		= sirf_pcm_open,
+	.close		= snd_dmaengine_pcm_close_release_chan,
+	.ioctl		= snd_pcm_lib_ioctl,
+	.hw_params	= sirf_pcm_hw_params,
+	.hw_free	= sirf_pcm_hw_free,
+	.trigger	= snd_dmaengine_pcm_trigger,
+	.pointer	= snd_dmaengine_pcm_pointer,
+	.mmap		= sirf_pcm_mmap,
+};
+
+static void sirf_pcm_free_dma_buffers(struct snd_pcm *pcm)
+{
+	struct snd_pcm_substream *substream;
+	struct snd_dma_buffer *buf;
+	int stream;
+
+	for (stream = 0; stream < 2; stream++) {
+		substream = pcm->streams[stream].substream;
+		if (!substream)
+			continue;
+
+		buf = &substream->dma_buffer;
+		if (!buf->area)
+			continue;
+
+		dma_free_coherent(pcm->card->dev, buf->bytes,
+				buf->area, buf->addr);
+		buf->area = NULL;
+	}
+}
+
+static int sirf_pcm_preallocate_dma_buffer(struct snd_pcm *pcm, int stream)
+{
+	struct snd_pcm_substream *substream = pcm->streams[stream].substream;
+	struct snd_dma_buffer *buf = &substream->dma_buffer;
+	size_t size = sirf_pcm_hardware.buffer_bytes_max;
+
+	buf->dev.type = SNDRV_DMA_TYPE_DEV;
+	buf->dev.dev = pcm->card->dev;
+	buf->area = dma_alloc_coherent(pcm->card->dev, size,
+			&buf->addr, GFP_KERNEL);
+	if (!buf->area)
+		return -ENOMEM;
+
+	buf->bytes = size;
+
+	return 0;
+}
+
+static int sirf_pcm_new(struct snd_soc_pcm_runtime *rtd)
+{
+	struct snd_pcm *pcm = rtd->pcm;
+	int ret;
+
+	if (pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream) {
+		ret = sirf_pcm_preallocate_dma_buffer(pcm,
+				SNDRV_PCM_STREAM_PLAYBACK);
+		if (ret)
+			goto out;
+	}
+
+	if (pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream) {
+		ret = sirf_pcm_preallocate_dma_buffer(pcm,
+				SNDRV_PCM_STREAM_CAPTURE);
+		if (ret)
+			goto out;
+	}
+
+	return 0;
+
+out:
+	sirf_pcm_free_dma_buffers(pcm);
+	return ret;
+}
+
+static struct snd_soc_platform_driver sirf_soc_platform = {
+	.ops		= &sirf_pcm_ops,
+	.pcm_new	= sirf_pcm_new,
+	.pcm_free	= sirf_pcm_free_dma_buffers,
+};
+
+static int sirf_pcm_probe(struct platform_device *pdev)
+{
+	return snd_soc_register_platform(&pdev->dev,
+			&sirf_soc_platform);
+}
+
+static int sirf_pcm_remove(struct platform_device *pdev)
+{
+	snd_soc_unregister_platform(&pdev->dev);
+	return 0;
+}
+
+static const struct of_device_id sirf_pcm_of_match[] = {
+	{ .compatible = "sirf,pcm-audio", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, sirf_pcm_of_match);
+
+static struct platform_driver sirf_pcm_driver = {
+	.driver = {
+		.name = "sirf-pcm-audio",
+		.owner = THIS_MODULE,
+		.of_match_table = sirf_pcm_of_match,
+	},
+	.probe = sirf_pcm_probe,
+	.remove = sirf_pcm_remove,
+};
+module_platform_driver(sirf_pcm_driver);
+
+MODULE_DESCRIPTION("SiRF PCM audio interface driver");
+MODULE_AUTHOR("RongJun Ying <Rongjun.Ying at csr.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/sound/soc/sirf/sirf-pcm.h b/sound/soc/sirf/sirf-pcm.h
new file mode 100644
index 0000000..c178016
--- /dev/null
+++ b/sound/soc/sirf/sirf-pcm.h
@@ -0,0 +1,17 @@
+/*
+ * SiRF pcm dma data struct
+ *
+ * Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group company.
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#ifndef __SIRF_PCM_H__
+#define __SIRF_PCM_H__
+
+struct sirf_pcm_dma_data {
+	char	*name;		/* Stream name */
+	int	dma_req;	/* DMA request line */
+};
+
+#endif
-- 
1.8.2.3



From 21cnbao at gmail.com  Fri Jul 19 07:07:18 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Fri, 19 Jul 2013 19:07:18 +0800
Subject: [PATCH 2/6] ASoC: sirf: add I2S CPU DAI driver
In-Reply-To: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <1374232042-26088-3-git-send-email-Baohua.Song@csr.com>

From: Rongjun Ying <Rongjun.Ying at csr.com>

This patch adds I2S DAI driver for SiRFprima2 and SiRFatlas6. The hardware supports:
I2S bus specification compliant (Released by Philips Semiconductors in June, 1996)
Supports I2S master and I2S slave mode
Provides MCLK to I2S CODEC in I2S master mode
Supports 16-bit resolution playback
Supports 16-bit resolution record
Supports 2 channel record
Supports 2 channel and 6 channel mode playback
Frame length, left channel length and right channel length are all programmable
Supports two DMA channels for TXFIFO and RXFIFO
Supports floating mode (x_ac97_dout can be configured as input)

headfile sound/soc/sirf/sirf-audio.h will be shard by all I2S and soc-inner
DAIs.

Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 sound/soc/sirf/Kconfig      |   3 +
 sound/soc/sirf/Makefile     |   2 +
 sound/soc/sirf/sirf-audio.h | 266 ++++++++++++++++++++++++++++
 sound/soc/sirf/sirf-i2s.c   | 411 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 682 insertions(+)
 create mode 100644 sound/soc/sirf/sirf-audio.h
 create mode 100644 sound/soc/sirf/sirf-i2s.c

diff --git a/sound/soc/sirf/Kconfig b/sound/soc/sirf/Kconfig
index 3678aed..d98acd4 100644
--- a/sound/soc/sirf/Kconfig
+++ b/sound/soc/sirf/Kconfig
@@ -2,3 +2,6 @@ config SND_SIRF_SOC
 	tristate "Platform DMA driver for the SiRF SoC chips"
 	depends on ARCH_SIRF && SND_SOC
 	select SND_SOC_DMAENGINE_PCM
+
+config SND_SOC_SIRF_I2S
+	tristate
diff --git a/sound/soc/sirf/Makefile b/sound/soc/sirf/Makefile
index f268b83..9f754fe 100644
--- a/sound/soc/sirf/Makefile
+++ b/sound/soc/sirf/Makefile
@@ -1,3 +1,5 @@
 snd-soc-sirf-objs := sirf-pcm.o
+snd-soc-sirf-i2s-objs := sirf-i2s.o
 
 obj-$(CONFIG_SND_SIRF_SOC) += snd-soc-sirf.o
+obj-$(CONFIG_SND_SOC_SIRF_I2S) += snd-soc-sirf-i2s.o
diff --git a/sound/soc/sirf/sirf-audio.h b/sound/soc/sirf/sirf-audio.h
new file mode 100644
index 0000000..514c815
--- /dev/null
+++ b/sound/soc/sirf/sirf-audio.h
@@ -0,0 +1,266 @@
+/*
+ * SiRF inner codec controllers define
+ *
+ * Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group company.
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#ifndef _SIRF_INNER_AUDIO_CTRL_H
+#define _SIRF_INNER_AUDIO_CTRL_H
+
+#define AUDIO_CTRL_TX_FIFO_LEVEL_CHECK_MASK     0x3F
+#define AUDIO_CTRL_TX_FIFO_SC_OFFSET    0
+#define AUDIO_CTRL_TX_FIFO_LC_OFFSET    10
+#define AUDIO_CTRL_TX_FIFO_HC_OFFSET    20
+
+#define TX_FIFO_SC(x)           (((x) & AUDIO_CTRL_TX_FIFO_LEVEL_CHECK_MASK) \
+				<< AUDIO_CTRL_TX_FIFO_SC_OFFSET)
+#define TX_FIFO_LC(x)           (((x) & AUDIO_CTRL_TX_FIFO_LEVEL_CHECK_MASK) \
+				<< AUDIO_CTRL_TX_FIFO_LC_OFFSET)
+#define TX_FIFO_HC(x)           (((x) & AUDIO_CTRL_TX_FIFO_LEVEL_CHECK_MASK) \
+				<< AUDIO_CTRL_TX_FIFO_HC_OFFSET)
+
+#define AUDIO_CTRL_RX_FIFO_LEVEL_CHECK_MASK     0x0F
+#define AUDIO_CTRL_RX_FIFO_SC_OFFSET    0
+#define AUDIO_CTRL_RX_FIFO_LC_OFFSET    10
+#define AUDIO_CTRL_RX_FIFO_HC_OFFSET    20
+
+#define RX_FIFO_SC(x)           (((x) & AUDIO_CTRL_RX_FIFO_LEVEL_CHECK_MASK) \
+				<< AUDIO_CTRL_RX_FIFO_SC_OFFSET)
+#define RX_FIFO_LC(x)           (((x) & AUDIO_CTRL_RX_FIFO_LEVEL_CHECK_MASK) \
+				<< AUDIO_CTRL_RX_FIFO_LC_OFFSET)
+#define RX_FIFO_HC(x)           (((x) & AUDIO_CTRL_RX_FIFO_LEVEL_CHECK_MASK) \
+				<< AUDIO_CTRL_RX_FIFO_HC_OFFSET)
+
+#define AUDIO_CTRL_MODE_SEL			(0x0000)
+#define AUDIO_CTRL_AC97_CTRL			(0x0004)
+#define AUDIO_CTRL_AC97_CMD			(0x0008)
+#define AUDIO_CTRL_AC97_OP_STATUS		(0x000C)
+#define AUDIO_CTRL_AC97_RD_CODEC_REG		(0x0010)
+#define AUDIO_CTRL_TXSLOT_EN			(0x0014)
+#define AUDIO_CTRL_RXSLOT_EN			(0x0018)
+#define AUDIO_CTRL_AC97_AUX_SLOT_EN		(0x001c)
+#define AUDIO_CTRL_I2S_CTRL			(0x0020)
+#define AUDIO_CTRL_I2S_TX_RX_EN			(0x0024)
+
+#define AUDIO_CTRL_EXT_TXFIFO1_OP		(0x0040)
+#define AUDIO_CTRL_EXT_TXFIFO1_LEV_CHK		(0x0044)
+#define AUDIO_CTRL_EXT_TXFIFO1_STS		(0x0048)
+#define AUDIO_CTRL_EXT_TXFIFO1_INT		(0x004C)
+#define AUDIO_CTRL_EXT_TXFIFO1_INT_MSK		(0x0050)
+
+#define AUDIO_CTRL_EXT_TXFIFO2_OP		(0x0054)
+#define AUDIO_CTRL_EXT_TXFIFO2_LEV_CHK		(0x0058)
+#define AUDIO_CTRL_EXT_TXFIFO2_STS		(0x005C)
+#define AUDIO_CTRL_EXT_TXFIFO2_INT		(0x0060)
+#define AUDIO_CTRL_EXT_TXFIFO2_INT_MSK		(0x0064)
+
+#define AUDIO_CTRL_EXT_TXFIFO3_OP		(0x0068)
+#define AUDIO_CTRL_EXT_TXFIFO3_LEV_CHK		(0x006C)
+#define AUDIO_CTRL_EXT_TXFIFO3_STS		(0x0070)
+#define AUDIO_CTRL_EXT_TXFIFO3_INT		(0x0074)
+#define AUDIO_CTRL_EXT_TXFIFO3_INT_MSK		(0x0078)
+
+#define AUDIO_CTRL_EXT_TXFIFO4_OP		(0x007C)
+#define AUDIO_CTRL_EXT_TXFIFO4_LEV_CHK		(0x0080)
+#define AUDIO_CTRL_EXT_TXFIFO4_STS		(0x0084)
+#define AUDIO_CTRL_EXT_TXFIFO4_INT		(0x0088)
+#define AUDIO_CTRL_EXT_TXFIFO4_INT_MSK		(0x008C)
+
+#define AUDIO_CTRL_EXT_TXFIFO5_OP		(0x0090)
+#define AUDIO_CTRL_EXT_TXFIFO5_LEV_CHK		(0x0094)
+#define AUDIO_CTRL_EXT_TXFIFO5_STS		(0x0098)
+#define AUDIO_CTRL_EXT_TXFIFO5_INT		(0x009C)
+#define AUDIO_CTRL_EXT_TXFIFO5_INT_MSK		(0x00A0)
+
+#define AUDIO_CTRL_EXT_TXFIFO6_OP		(0x00A4)
+#define AUDIO_CTRL_EXT_TXFIFO6_LEV_CHK		(0x00A8)
+#define AUDIO_CTRL_EXT_TXFIFO6_STS		(0x00AC)
+#define AUDIO_CTRL_EXT_TXFIFO6_INT		(0x00B0)
+#define AUDIO_CTRL_EXT_TXFIFO6_INT_MSK		(0x00B4)
+
+#define AUDIO_CTRL_RXFIFO_OP			(0x00B8)
+#define AUDIO_CTRL_RXFIFO_LEV_CHK		(0x00BC)
+#define AUDIO_CTRL_RXFIFO_STS			(0x00C0)
+#define AUDIO_CTRL_RXFIFO_INT			(0x00C4)
+#define AUDIO_CTRL_RXFIFO_INT_MSK		(0x00C8)
+
+#define AUDIO_CTRL_AUXFIFO_OP			(0x00CC)
+#define AUDIO_CTRL_AUXFIFO_LEV_CHK		(0x00D0)
+#define AUDIO_CTRL_AUXFIFO_STS			(0x00D4)
+#define AUDIO_CTRL_AUXFIFO_INT			(0x00D8)
+#define AUDIO_CTRL_AUXFIFO_INT_MSK		(0x00DC)
+
+#define AUDIO_IC_CODEC_PWR			(0x00E0)
+#define AUDIO_IC_CODEC_CTRL0			(0x00E4)
+#define AUDIO_IC_CODEC_CTRL1			(0x00E8)
+#define AUDIO_IC_CODEC_CTRL2			(0x00EC)
+#define AUDIO_IC_CODEC_CTRL3			(0x00F0)
+
+#define AUDIO_CTRL_IC_CODEC_TX_CTRL		(0x00F4)
+#define AUDIO_CTRL_IC_CODEC_RX_CTRL		(0x00F8)
+
+#define AUDIO_CTRL_IC_TXFIFO_OP			(0x00FC)
+#define AUDIO_CTRL_IC_TXFIFO_LEV_CHK		(0x0100)
+#define AUDIO_CTRL_IC_TXFIFO_STS		(0x0104)
+#define AUDIO_CTRL_IC_TXFIFO_INT		(0x0108)
+#define AUDIO_CTRL_IC_TXFIFO_INT_MSK		(0x010C)
+
+#define AUDIO_CTRL_IC_RXFIFO_OP			(0x0110)
+#define AUDIO_CTRL_IC_RXFIFO_LEV_CHK		(0x0114)
+#define AUDIO_CTRL_IC_RXFIFO_STS		(0x0118)
+#define AUDIO_CTRL_IC_RXFIFO_INT		(0x011C)
+#define AUDIO_CTRL_IC_RXFIFO_INT_MSK		(0x0120)
+
+#define I2S_MODE				(1<<0)
+#define AC97_TX_SLOT3_WIDTH_MASK		(3<<1)
+#define AC97_TX_SLOT4_WIDTH_MASK		(3<<3)
+#define AC97_TX_SLOT6_WIDTH_MASK		(3<<5)
+#define AC97_TX_SLOT7_WIDTH_MASK		(3<<7)
+#define AC97_TX_SLOT8_WIDTH_MASK		(3<<9)
+#define AC97_TX_SLOT9_WIDTH_MASK		(3<<11)
+#define AC97_FIFO_SYNC_MASK			(3<<13)
+#define AC97_FIFO_SYNC_ALL			(1<<13)
+
+#define SYNC_START				(1<<0)
+#define AC97_START				(1<<1)
+#define WARM_WAKEUP				(1<<2)
+
+#define AC97_CMD_TYPE_MASK			(1<<7)
+#define AC97_CMD_ADDR_MASK			(0x7F)
+#define AC97_CMD_TYPE_WRITE			(0<<7)
+#define AC97_CMD_TYPE_READ			(1<<7)
+
+#define CMD_ISSUE_BIT				(1<<0)
+#define	RD_CMD_FINISH_BIT			(1<<1)
+#define	CODEC_READY_BIT				(1<<2)
+
+#define	AC97_RDBACK_ADDR_BITS			(0x7F)
+#define	AC97_RDBACK_DATA_BITS			(0xFF<<16)
+
+#define AC97_TX_SLOT3_EN			(1<<0)
+#define AC97_TX_SLOT4_EN			(1<<1)
+#define AC97_TX_SLOT6_EN			(1<<2)
+#define AC97_TX_SLOT7_EN			(1<<3)
+#define AC97_TX_SLOT8_EN			(1<<4)
+#define AC97_TX_SLOT9_EN			(1<<5)
+
+#define AC97_RX_SLOT3_EN			(1<<0)
+#define AC97_RX_SLOT4_EN			(1<<1)
+#define AC97_RX_SLOT5_EN			(1<<2)
+#define AC97_RX_SLOT6_EN			(1<<3)
+#define AC97_RX_SLOT7_EN			(1<<4)
+#define AC97_RX_SLOT8_EN			(1<<5)
+#define AC97_RX_SLOT9_EN			(1<<6)
+#define AC97_RX_SLOT10_EN			(1<<7)
+#define AC97_RX_SLOT11_EN			(1<<8)
+#define AC97_RX_SLOT12_EN			(1<<9)
+
+#define AC97_AUX_SLOT3_EN			(1<<0)
+#define AC97_AUX_SLOT4_EN			(1<<1)
+#define AC97_AUX_SLOT5_EN			(1<<2)
+#define AC97_AUX_SLOT6_EN			(1<<3)
+#define AC97_AUX_SLOT7_EN			(1<<4)
+#define AC97_AUX_SLOT8_EN			(1<<5)
+#define AC97_AUX_SLOT9_EN			(1<<6)
+#define AC97_AUX_SLOT10_EN			(1<<7)
+#define AC97_AUX_SLOT11_EN			(1<<8)
+#define AC97_AUX_SLOT12_EN			(1<<9)
+
+#define I2S_LOOP_BACK				(1<<3)
+#define	I2S_MCLK_DIV_SHIFT			15
+#define I2S_MCLK_DIV_MASK			(0x1FF<<I2S_MCLK_DIV_SHIFT)
+#define I2S_BITCLK_DIV_SHIFT			24
+#define I2S_BITCLK_DIV_MASK			(0xFF<<I2S_BITCLK_DIV_SHIFT)
+
+#define I2S_MCLK_EN				(1<<2)
+#define I2S_REF_CLK_SEL_EXT			(1<<3)
+#define I2S_DOUT_OE				(1<<4)
+#define i2s_R2X_LP_TO_TX0			(1<<30)
+#define i2s_R2X_LP_TO_TX1			(2<<30)
+#define i2s_R2X_LP_TO_TX2			(3<<30)
+
+#define AUDIO_FIFO_START		(1 << 0)
+#define AUDIO_FIFO_RESET		(1 << 1)
+
+#define AUDIO_FIFO_FULL			(1 << 0)
+#define AUDIO_FIFO_EMPTY		(1 << 1)
+#define AUDIO_FIFO_OFLOW		(1 << 2)
+#define AUDIO_FIFO_UFLOW		(1 << 3)
+
+#define I2S_RX_ENABLE			(1 << 0)
+#define I2S_TX_ENABLE			(1 << 1)
+
+/* Codec I2S Control Register defines */
+#define I2S_SLAVE_MODE			(1 << 0)
+#define I2S_SIX_CHANNELS		(1 << 1)
+#define I2S_L_CHAN_LEN_MASK		(0x1f << 4)
+#define I2S_FRAME_LEN_MASK		(0x3f << 9)
+
+#define AC97_WRITE_FRAME_VALID    0X10
+#define AC97_WRITE_SLOT1_VALID    0X08
+#define AC97_WRITE_SLOT2_VALID    0X04
+#define AC97_WRITE_SLOT3_VALID    0X02
+#define AC97_WRITE_SLOT4_VALID    0X01
+
+#define IC_TX_ENABLE		(0x03)
+#define IC_RX_ENABLE		(0x03)
+
+#define MICBIASEN		(1 << 3)
+
+#define IC_RDACEN		(1 << 0)
+#define IC_LDACEN		(1 << 1)
+#define IC_HSREN		(1 << 2)
+#define IC_HSLEN		(1 << 3)
+#define IC_SPEN			(1 << 4)
+#define IC_CPEN			(1 << 5)
+
+#define IC_HPRSELR		(1 << 6)
+#define IC_HPLSELR		(1 << 7)
+#define IC_HPRSELL		(1 << 8)
+#define IC_HPLSELL		(1 << 9)
+#define IC_SPSELR		(1 << 10)
+#define IC_SPSELL		(1 << 11)
+
+#define IC_MONOR		(1 << 12)
+#define IC_MONOL		(1 << 13)
+
+#define IC_RXOSRSEL		(1 << 28)
+#define IC_CPFREQ		(1 << 29)
+#define IC_HSINVEN		(1 << 30)
+
+#define IC_MICINREN		(1 << 0)
+#define IC_MICINLEN		(1 << 1)
+#define IC_MICIN1SEL		(1 << 2)
+#define IC_MICIN2SEL		(1 << 3)
+#define IC_MICDIFSEL		(1 << 4)
+#define	IC_LINEIN1SEL		(1 << 5)
+#define	IC_LINEIN2SEL		(1 << 6)
+#define	IC_RADCEN		(1 << 7)
+#define	IC_LADCEN		(1 << 8)
+#define	IC_ALM			(1 << 9)
+
+#define IC_DIGMICEN             (1 << 22)
+#define IC_DIGMICFREQ           (1 << 23)
+#define IC_ADC14B_12            (1 << 24)
+#define IC_FIRDAC_HSL_EN        (1 << 25)
+#define IC_FIRDAC_HSR_EN        (1 << 26)
+#define IC_FIRDAC_LOUT_EN       (1 << 27)
+#define IC_POR                  (1 << 28)
+#define IC_CODEC_CLK_EN         (1 << 29)
+#define IC_HP_3DB_BOOST         (1 << 30)
+
+#define IC_ADC_LEFT_GAIN_SHIFT	16
+#define IC_ADC_RIGHT_GAIN_SHIFT 10
+#define IC_ADC_GAIN_MASK	0x3F
+#define IC_MIC_MAX_GAIN		0x39
+
+#define IC_RXPGAR_MASK		0x3F
+#define IC_RXPGAR_SHIFT		14
+#define IC_RXPGAL_MASK		0x3F
+#define IC_RXPGAL_SHIFT		21
+#define IC_RXPGAR		0x7B
+#define IC_RXPGAL		0x7B
+
+#endif /*__SIRF_INNER_AUDIO_CTRL_H*/
diff --git a/sound/soc/sirf/sirf-i2s.c b/sound/soc/sirf/sirf-i2s.c
new file mode 100644
index 0000000..d0f81f9
--- /dev/null
+++ b/sound/soc/sirf/sirf-i2s.c
@@ -0,0 +1,411 @@
+/*
+ * SiRF I2S driver
+ *
+ * Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group company.
+ *
+ * Licensed under GPLv2 or later.
+ */
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/clk.h>
+#include <linux/pwm.h>
+#include <linux/delay.h>
+#include <linux/reset.h>
+
+#include <sound/soc.h>
+#include <sound/pcm_params.h>
+
+#include "sirf-pcm.h"
+#include "sirf-audio.h"
+
+struct sirf_i2s {
+	void __iomem		*base;
+	struct clk		*clk;
+	struct pwm_device	*mclk_pwm;
+	u32			i2s_ctrl;
+	spinlock_t		lock;
+	int			master_mode;
+};
+
+static struct sirf_pcm_dma_data sirf_i2s_dai_dma_data[2] = {
+	{
+		.name = "Audio Playback",
+	}, {
+		.name = "Audio Capture",
+	}
+};
+
+static int sirf_i2s_startup(struct snd_pcm_substream *substream,
+		struct snd_soc_dai *dai)
+{
+
+	struct sirf_i2s *si2s = snd_soc_dai_get_drvdata(dai);
+
+	if (si2s->master_mode)
+		pwm_enable(si2s->mclk_pwm);
+	clk_prepare_enable(si2s->clk);
+
+	device_reset(dai->dev);
+	snd_soc_dai_set_dma_data(dai, substream,
+		&sirf_i2s_dai_dma_data[substream->stream]);
+	return 0;
+}
+
+static void sirf_i2s_shutdown(struct snd_pcm_substream *substream,
+		struct snd_soc_dai *dai)
+{
+	struct sirf_i2s *si2s = snd_soc_dai_get_drvdata(dai);
+	if (si2s->master_mode)
+		pwm_disable(si2s->mclk_pwm);
+	clk_disable_unprepare(si2s->clk);
+}
+
+static int sirf_i2s_trigger(struct snd_pcm_substream *substream,
+		int cmd, struct snd_soc_dai *dai)
+{
+	struct sirf_i2s *si2s = snd_soc_dai_get_drvdata(dai);
+	int playback = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK);
+
+	switch (cmd) {
+	case SNDRV_PCM_TRIGGER_START:
+	case SNDRV_PCM_TRIGGER_RESUME:
+	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+		spin_lock(&si2s->lock);
+
+		if (playback) {
+			/* First start the FIFO, then enable the tx/rx */
+			writel(AUDIO_FIFO_RESET,
+				si2s->base + AUDIO_CTRL_EXT_TXFIFO1_OP);
+			mdelay(1);
+			writel(AUDIO_FIFO_START,
+				si2s->base + AUDIO_CTRL_EXT_TXFIFO1_OP);
+			mdelay(1);
+
+			writel(readl(si2s->base+AUDIO_CTRL_I2S_TX_RX_EN)
+				| I2S_TX_ENABLE | I2S_DOUT_OE |
+				(si2s->master_mode == 1 ? I2S_MCLK_EN : 0),
+				si2s->base + AUDIO_CTRL_I2S_TX_RX_EN);
+
+		} else {
+			/* First start the FIFO, then enable the tx/rx */
+			writel(AUDIO_FIFO_RESET,
+				si2s->base + AUDIO_CTRL_RXFIFO_OP);
+			mdelay(1);
+			writel(AUDIO_FIFO_START,
+				si2s->base + AUDIO_CTRL_RXFIFO_OP);
+			mdelay(1);
+
+			writel(readl(si2s->base+AUDIO_CTRL_I2S_TX_RX_EN)
+				| I2S_RX_ENABLE |
+				(si2s->master_mode == 1 ? I2S_MCLK_EN : 0),
+				si2s->base + AUDIO_CTRL_I2S_TX_RX_EN);
+		}
+
+		spin_unlock(&si2s->lock);
+		break;
+	case SNDRV_PCM_TRIGGER_STOP:
+	case SNDRV_PCM_TRIGGER_SUSPEND:
+	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+		spin_lock(&si2s->lock);
+
+		if (playback) {
+			writel(readl(si2s->base + AUDIO_CTRL_I2S_TX_RX_EN)
+				& ~(I2S_TX_ENABLE | I2S_MCLK_EN),
+				si2s->base + AUDIO_CTRL_I2S_TX_RX_EN);
+			/* First disable the tx/rx, then stop the FIFO */
+			writel(0, si2s->base + AUDIO_CTRL_EXT_TXFIFO1_OP);
+		} else {
+			writel(readl(si2s->base + AUDIO_CTRL_I2S_TX_RX_EN)
+				& ~(I2S_RX_ENABLE | I2S_MCLK_EN),
+				si2s->base+AUDIO_CTRL_I2S_TX_RX_EN);
+
+			/* First disable the tx/rx, then stop the FIFO */
+			writel(0, si2s->base + AUDIO_CTRL_RXFIFO_OP);
+		}
+
+		spin_unlock(&si2s->lock);
+		break;
+	default:
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static int sirf_i2s_prepare(struct snd_pcm_substream *substream,
+			struct snd_soc_dai *dai)
+{
+	struct snd_pcm_runtime *runtime = substream->runtime;
+	struct sirf_i2s *si2s = snd_soc_dai_get_drvdata(dai);
+	u32 ctrl = readl(si2s->base + AUDIO_CTRL_I2S_CTRL);
+
+	if (runtime->channels == 2)
+		ctrl &= ~I2S_SIX_CHANNELS;
+	else
+		ctrl |= I2S_SIX_CHANNELS;
+
+	writel(ctrl, si2s->base+AUDIO_CTRL_I2S_CTRL);
+
+	return 0;
+}
+
+static int sirf_i2s_hw_params(struct snd_pcm_substream *substream,
+		struct snd_pcm_hw_params *params, struct snd_soc_dai *dai)
+{
+	struct sirf_i2s *si2s = snd_soc_dai_get_drvdata(dai);
+	u32 i2s_ctrl = readl(si2s->base + AUDIO_CTRL_I2S_CTRL);
+	u32 left_len, frame_len;
+
+	switch (params_format(params)) {
+	case SNDRV_PCM_FORMAT_S8:
+		left_len = 8;
+		break;
+	case SNDRV_PCM_FORMAT_S16_LE:
+		left_len = 16;
+		break;
+	case SNDRV_PCM_FORMAT_S24_LE:
+		left_len = 24;
+		break;
+	case SNDRV_PCM_FORMAT_S32_LE:
+		left_len = 32;
+		break;
+	default:
+		dev_err(dai->dev, "Format unsupported\n");
+		return -EINVAL;
+	}
+
+	frame_len = left_len * 2;
+	i2s_ctrl &= ~(I2S_L_CHAN_LEN_MASK | I2S_FRAME_LEN_MASK);
+	/* Fill the actual len - 1 */
+	i2s_ctrl |= ((frame_len - 1) << 9) | ((left_len - 1) << 4)
+		| (0 << 15) | (3 << 24);
+	writel(i2s_ctrl, si2s->base + AUDIO_CTRL_I2S_CTRL);
+	return 0;
+}
+
+static int sirf_i2s_set_dai_fmt(struct snd_soc_dai *dai,
+		unsigned int fmt)
+{
+	struct sirf_i2s *si2s = snd_soc_dai_get_drvdata(dai);
+	u32 ctrl;
+
+	switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+	case SND_SOC_DAIFMT_CBM_CFM:
+		ctrl = readl(si2s->base + AUDIO_CTRL_I2S_CTRL);
+		ctrl |= I2S_SLAVE_MODE;
+		writel(ctrl, si2s->base + AUDIO_CTRL_I2S_CTRL);
+		si2s->master_mode = 0;
+		break;
+	case SND_SOC_DAIFMT_CBS_CFS:
+		si2s->master_mode = 1;
+		return -EINVAL;
+	default:
+		return -EINVAL;
+	}
+
+	/* interface format */
+	switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+	case SND_SOC_DAIFMT_I2S:
+		writel(readl(si2s->base + AUDIO_CTRL_MODE_SEL)
+			| I2S_MODE,
+			si2s->base + AUDIO_CTRL_MODE_SEL);
+		break;
+	default:
+		dev_err(dai->dev, "Only I2S format supported\n");
+		return -EINVAL;
+	}
+
+	/* clock inversion */
+	switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
+	case SND_SOC_DAIFMT_NB_NF:
+		break;
+	default:
+		dev_err(dai->dev, " Only normal bit clock, normal frame clock supported\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+struct snd_soc_dai_ops sirfsoc_i2s_dai_ops = {
+	.startup	= sirf_i2s_startup,
+	.shutdown	= sirf_i2s_shutdown,
+	.trigger	= sirf_i2s_trigger,
+	.prepare	= sirf_i2s_prepare,
+	.hw_params	= sirf_i2s_hw_params,
+	.set_fmt	= sirf_i2s_set_dai_fmt,
+};
+
+static struct snd_soc_dai_driver sirf_i2s_dai = {
+	.name		= "sirf-i2s",
+	.id			= 0,
+	.playback = {
+		.stream_name = "SiRF I2S Playback",
+		.channels_min = 2,
+		.channels_max = 6,
+		.rates = SNDRV_PCM_RATE_8000_96000,
+		.formats = SNDRV_PCM_FMTBIT_S8 |
+			SNDRV_PCM_FMTBIT_S16_LE |
+			SNDRV_PCM_FMTBIT_S24_LE |
+			SNDRV_PCM_FMTBIT_S32_LE,
+	},
+	.capture = {
+		.stream_name = "SiRF I2S Capture",
+		.channels_min = 2,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_8000_96000,
+		.formats = SNDRV_PCM_FMTBIT_S8 |
+			SNDRV_PCM_FMTBIT_S16_LE |
+			SNDRV_PCM_FMTBIT_S24_LE |
+			SNDRV_PCM_FMTBIT_S32_LE,
+	},
+	.ops = &sirfsoc_i2s_dai_ops,
+};
+
+#ifdef CONFIG_PM
+static int sirf_i2s_suspend(struct platform_device *pdev,
+		pm_message_t state)
+{
+	struct sirf_i2s *si2s = platform_get_drvdata(pdev);
+
+	si2s->i2s_ctrl = readl(si2s->base+AUDIO_CTRL_I2S_CTRL);
+
+	clk_disable_unprepare(si2s->clk);
+
+	if (si2s->master_mode)
+		pwm_disable(si2s->mclk_pwm);
+	return 0;
+}
+
+static int sirf_i2s_resume(struct platform_device *pdev)
+{
+	struct sirf_i2s *si2s = platform_get_drvdata(pdev);
+	if (si2s->master_mode)
+		pwm_enable(si2s->mclk_pwm);
+	clk_prepare_enable(si2s->clk);
+
+	device_reset(&pdev->dev);
+	writel(readl(si2s->base+AUDIO_CTRL_MODE_SEL)
+			| I2S_MODE,
+			si2s->base+AUDIO_CTRL_MODE_SEL);
+	writel(si2s->i2s_ctrl, si2s->base+AUDIO_CTRL_I2S_CTRL);
+	writel(0, si2s->base + AUDIO_CTRL_EXT_TXFIFO1_INT_MSK);
+	writel(0, si2s->base + AUDIO_CTRL_RXFIFO_INT_MSK);
+
+	return 0;
+}
+#else
+#define sirf_usp_pcm_suspend NULL
+#define sirf_usp_pcm_resume NULL
+#endif
+
+static const struct snd_soc_component_driver sirf_i2s_component = {
+	.name       = "sirf-i2s",
+};
+
+static int sirf_i2s_probe(struct platform_device *pdev)
+{
+	struct sirf_i2s *si2s;
+	u32 rx_dma_ch, tx_dma_ch;
+	int ret;
+	struct resource mem_res;
+
+	si2s = devm_kzalloc(&pdev->dev, sizeof(struct sirf_i2s),
+			GFP_KERNEL);
+	if (!si2s)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, si2s);
+
+	spin_lock_init(&si2s->lock);
+
+	ret = of_property_read_u32(pdev->dev.of_node,
+			"sirf,i2s-dma-rx-channel", &rx_dma_ch);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Unable to USP0 rx dma channel\n");
+		return ret;
+	}
+	ret = of_property_read_u32(pdev->dev.of_node,
+			"sirf,i2s-dma-tx-channel", &tx_dma_ch);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Unable to USP0 tx dma channel\n");
+		return ret;
+	}
+	sirf_i2s_dai_dma_data[0].dma_req = tx_dma_ch;
+	sirf_i2s_dai_dma_data[1].dma_req = rx_dma_ch;
+
+	ret = of_address_to_resource(pdev->dev.of_node, 0, &mem_res);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Unable to get i2s memory resource.\n");
+		return ret;
+	}
+	si2s->base = devm_ioremap(&pdev->dev, mem_res.start,
+		resource_size(&mem_res));
+	if (!si2s->base)
+		return -ENOMEM;
+
+	si2s->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(si2s->clk)) {
+		dev_err(&pdev->dev, "Get clock failed.\n");
+		ret = PTR_ERR(si2s->clk);
+		goto err;
+	}
+
+	/* i2s bus uses an internal PWM to generate MCLK */
+	si2s->mclk_pwm = devm_pwm_get(&pdev->dev, NULL);
+	if (IS_ERR(si2s->mclk_pwm)) {
+		dev_err(&pdev->dev, "unable to request PWM\n");
+		ret = PTR_ERR(si2s->mclk_pwm);
+		goto err_clk_put;
+	}
+
+	ret = snd_soc_register_component(&pdev->dev, &sirf_i2s_component,
+			&sirf_i2s_dai, 1);
+	if (ret) {
+		dev_err(&pdev->dev, "Register Audio SoC dai failed.\n");
+		goto err_clk_put;
+	}
+
+	return 0;
+
+err_clk_put:
+	clk_disable_unprepare(si2s->clk);
+err:
+	return ret;
+}
+
+static int sirf_i2s_remove(struct platform_device *pdev)
+{
+	struct sirf_i2s *si2s = platform_get_drvdata(pdev);
+
+	pwm_disable(si2s->mclk_pwm);
+	snd_soc_unregister_component(&pdev->dev);
+	clk_disable_unprepare(si2s->clk);
+
+	return 0;
+}
+
+static const struct of_device_id sirf_i2s_of_match[] = {
+	{ .compatible = "sirf,prima2-i2s", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, sirf_i2s_of_match);
+
+static struct platform_driver sirf_i2s_driver = {
+	.driver = {
+		.name = "sirf-i2s",
+		.owner = THIS_MODULE,
+		.of_match_table = sirf_i2s_of_match,
+	},
+	.probe = sirf_i2s_probe,
+	.remove = sirf_i2s_remove,
+	.suspend = sirf_i2s_suspend,
+	.resume = sirf_i2s_resume,
+};
+
+module_platform_driver(sirf_i2s_driver);
+
+MODULE_DESCRIPTION("SiRF SoC I2S driver");
+MODULE_AUTHOR("RongJun Ying <Rongjun.Ying at csr.com>");
+MODULE_LICENSE("GPL v2");
-- 
1.8.2.3



From 21cnbao at gmail.com  Fri Jul 19 07:07:19 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Fri, 19 Jul 2013 19:07:19 +0800
Subject: [PATCH 3/6] ASoC: usp-pcm: add CPU DAI driver for PCM simulated from
 USP
In-Reply-To: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <1374232042-26088-4-git-send-email-Baohua.Song@csr.com>

From: Rongjun Ying <Rongjun.Ying at csr.com>

Universal Serial Ports (USP) can be used as PCM. this patch
adds support for this functionality.

The USP provides 128-byte data FIFO which supports DMA and I/O
modes. Here we use the common DMA driver.

Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 sound/soc/sirf/Kconfig    |   3 +
 sound/soc/sirf/Makefile   |   2 +
 sound/soc/sirf/sirf-usp.c | 481 ++++++++++++++++++++++++++++++++++++++++++++++
 sound/soc/sirf/sirf-usp.h | 276 ++++++++++++++++++++++++++
 4 files changed, 762 insertions(+)
 create mode 100644 sound/soc/sirf/sirf-usp.c
 create mode 100644 sound/soc/sirf/sirf-usp.h

diff --git a/sound/soc/sirf/Kconfig b/sound/soc/sirf/Kconfig
index d98acd4..3606614 100644
--- a/sound/soc/sirf/Kconfig
+++ b/sound/soc/sirf/Kconfig
@@ -5,3 +5,6 @@ config SND_SIRF_SOC
 
 config SND_SOC_SIRF_I2S
 	tristate
+
+config SND_SOC_SIRF_USP
+	tristate
diff --git a/sound/soc/sirf/Makefile b/sound/soc/sirf/Makefile
index 9f754fe..630c9be 100644
--- a/sound/soc/sirf/Makefile
+++ b/sound/soc/sirf/Makefile
@@ -1,5 +1,7 @@
 snd-soc-sirf-objs := sirf-pcm.o
 snd-soc-sirf-i2s-objs := sirf-i2s.o
+snd-soc-sirf-usp-objs := sirf-usp.o
 
 obj-$(CONFIG_SND_SIRF_SOC) += snd-soc-sirf.o
 obj-$(CONFIG_SND_SOC_SIRF_I2S) += snd-soc-sirf-i2s.o
+obj-$(CONFIG_SND_SOC_SIRF_USP) += snd-soc-sirf-usp.o
diff --git a/sound/soc/sirf/sirf-usp.c b/sound/soc/sirf/sirf-usp.c
new file mode 100644
index 0000000..107aa4b
--- /dev/null
+++ b/sound/soc/sirf/sirf-usp.c
@@ -0,0 +1,481 @@
+/*
+ * SiRF USP audio transfer interface like I2S
+ *
+ * Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group company.
+ *
+ * Licensed under GPLv2 or later.
+ */
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <sound/soc.h>
+
+#include "sirf-usp.h"
+#include "sirf-pcm.h"
+
+#define FIFO_RESET  0
+#define FIFO_START	1
+#define FIFO_STOP	2
+
+#define AUDIO_WORD_SIZE 16
+
+struct sirf_usp {
+	void __iomem *base;
+	struct clk *clk;
+	u32 mode1_reg;
+	u32 mode2_reg;
+};
+
+static struct sirf_pcm_dma_data sirf_usp_pcm_dai_dma_data[2] = {
+	{
+		.name = "Audio Playback",
+	}, {
+		.name = "Audio Capture",
+	}
+};
+static void sirf_usp_tx_fifo_op(struct sirf_usp *susp, int cmd)
+{
+	switch (cmd) {
+	case FIFO_RESET:
+		writel(USP_TX_FIFO_RESET, susp->base + USP_TX_FIFO_OP);
+		writel(0, susp->base + USP_TX_FIFO_OP);
+		break;
+	case FIFO_START:
+		writel(USP_TX_FIFO_START, susp->base + USP_TX_FIFO_OP);
+		break;
+	case FIFO_STOP:
+		writel(0, susp->base + USP_TX_FIFO_OP);
+		break;
+	}
+}
+
+static void sirf_usp_rx_fifo_op(struct sirf_usp *susp, int cmd)
+{
+	switch (cmd) {
+	case FIFO_RESET:
+		writel(USP_RX_FIFO_RESET, susp->base + USP_RX_FIFO_OP);
+		writel(0, susp->base + USP_RX_FIFO_OP);
+		break;
+	case FIFO_START:
+		writel(USP_RX_FIFO_START, susp->base + USP_RX_FIFO_OP);
+		break;
+	case FIFO_STOP:
+		writel(0, susp->base + USP_RX_FIFO_OP);
+		break;
+	}
+}
+
+static inline void sirf_usp_tx_enable(struct sirf_usp *susp)
+{
+	writel(readl(susp->base + USP_TX_RX_ENABLE) | USP_TX_ENA,
+			susp->base + USP_TX_RX_ENABLE);
+}
+
+static inline void sirf_usp_tx_disable(struct sirf_usp *susp)
+{
+	writel(readl(susp->base + USP_TX_RX_ENABLE) & ~USP_TX_ENA,
+			susp->base + USP_TX_RX_ENABLE);
+}
+
+static inline void sirf_usp_rx_enable(struct sirf_usp *susp)
+{
+	writel(readl(susp->base + USP_TX_RX_ENABLE) | USP_RX_ENA,
+			susp->base + USP_TX_RX_ENABLE);
+}
+
+static inline void sirf_usp_rx_disable(struct sirf_usp *susp)
+{
+	writel(readl(susp->base + USP_TX_RX_ENABLE) & ~USP_RX_ENA,
+			susp->base + USP_TX_RX_ENABLE);
+}
+
+static int sirf_usp_pcm_dai_startup(struct snd_pcm_substream *substream,
+		struct snd_soc_dai *dai)
+{
+	struct sirf_usp *susp = snd_soc_dai_get_drvdata(dai);
+	int playback = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK);
+	if (playback)
+		sirf_usp_tx_fifo_op(susp, FIFO_RESET);
+	else
+		sirf_usp_rx_fifo_op(susp, FIFO_RESET);
+
+	snd_soc_dai_set_dma_data(dai, substream,
+			&sirf_usp_pcm_dai_dma_data[substream->stream]);
+	return 0;
+}
+
+static int sirf_usp_pcm_set_dai_fmt(struct snd_soc_dai *dai,
+		unsigned int fmt)
+{
+	struct sirf_usp *susp = snd_soc_dai_get_drvdata(dai);
+	u32 val = readl(susp->base + USP_MODE2);
+
+	/* set master/slave audio interface */
+	switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+	case SND_SOC_DAIFMT_CBS_CFS:
+		dev_info(dai->dev, "USP master mode is not supported.\n");
+		return -EINVAL;
+	case SND_SOC_DAIFMT_CBM_CFM:
+		writel(readl(susp->base + USP_MODE1)
+			| USP_CLOCK_MODE_SLAVE, susp->base + USP_MODE1);
+		val |= (USP_TFS_CLK_SLAVE_MODE);
+		val |= (USP_RFS_CLK_SLAVE_MODE);
+		break;
+	default:
+		return -EINVAL;
+	}
+	writel(val, susp->base + USP_MODE2);
+
+	return 0;
+}
+
+static int sirf_usp_pcm_trigger(struct snd_pcm_substream *substream, int cmd,
+				struct snd_soc_dai *dai)
+{
+	int playback = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
+	struct sirf_usp *susp = snd_soc_dai_get_drvdata(dai);
+
+	switch (cmd) {
+	case SNDRV_PCM_TRIGGER_START:
+		if (playback) {
+			sirf_usp_tx_fifo_op(susp, FIFO_RESET);
+			sirf_usp_tx_fifo_op(susp, FIFO_START);
+			sirf_usp_tx_enable(susp);
+		} else {
+			sirf_usp_rx_fifo_op(susp, FIFO_RESET);
+			sirf_usp_rx_fifo_op(susp, FIFO_START);
+			sirf_usp_rx_enable(susp);
+		}
+		break;
+	case SNDRV_PCM_TRIGGER_STOP:
+		if (playback) {
+			sirf_usp_tx_disable(susp);
+			sirf_usp_tx_fifo_op(susp, FIFO_STOP);
+		} else {
+			sirf_usp_rx_disable(susp);
+			sirf_usp_rx_fifo_op(susp, FIFO_STOP);
+		}
+		break;
+	case SNDRV_PCM_TRIGGER_RESUME:
+		if (playback) {
+			sirf_usp_tx_fifo_op(susp, FIFO_RESET);
+			sirf_usp_tx_fifo_op(susp, FIFO_START);
+			sirf_usp_tx_enable(susp);
+		} else {
+			sirf_usp_rx_fifo_op(susp, FIFO_RESET);
+			sirf_usp_rx_fifo_op(susp, FIFO_START);
+			sirf_usp_rx_enable(susp);
+		}
+		break;
+	case SNDRV_PCM_TRIGGER_SUSPEND:
+		if (playback) {
+			sirf_usp_tx_disable(susp);
+			sirf_usp_tx_fifo_op(susp, FIFO_STOP);
+		} else {
+			sirf_usp_rx_disable(susp);
+			sirf_usp_rx_fifo_op(susp, FIFO_STOP);
+		}
+		break;
+	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+		if (playback) {
+			sirf_usp_tx_disable(susp);
+			sirf_usp_tx_fifo_op(susp, FIFO_STOP);
+		} else {
+			sirf_usp_rx_disable(susp);
+			sirf_usp_rx_fifo_op(susp, FIFO_STOP);
+		}
+		break;
+	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+		if (playback) {
+			sirf_usp_tx_fifo_op(susp, FIFO_START);
+			sirf_usp_tx_enable(susp);
+		} else {
+			sirf_usp_rx_fifo_op(susp, FIFO_START);
+			sirf_usp_rx_enable(susp);
+		}
+		break;
+	}
+
+	return 0;
+}
+
+static int sirf_usp_pcm_divider(struct snd_soc_dai *dai, int div_id, int rate)
+{
+	struct sirf_usp *susp = snd_soc_dai_get_drvdata(dai);
+
+	u32 clk_rate = clk_get_rate(susp->clk);
+	u32 clk_div = (clk_rate/(2*rate)) - 1;
+	u32 clk_div_hi = (clk_div & 0xC00)>>10;
+	u32 clk_div_lo = (clk_div & 0x3FF);
+
+	writel((clk_div_lo<<21) | readl(susp->base + USP_MODE2),
+		susp->base + USP_MODE2);
+	writel((clk_div_hi<<30) | readl(susp->base + USP_TX_FRAME_CTRL),
+		susp->base + USP_TX_FRAME_CTRL);
+
+	return 0;
+}
+
+static const struct snd_soc_dai_ops sirf_usp_pcm_dai_ops = {
+	.startup        = sirf_usp_pcm_dai_startup,
+	.trigger  = sirf_usp_pcm_trigger,
+	.set_fmt = sirf_usp_pcm_set_dai_fmt,
+	.set_clkdiv = sirf_usp_pcm_divider,
+};
+
+static struct snd_soc_dai_driver sirf_usp_pcm_dai = {
+	.name		= "sirf-usp-pcm",
+	.id			= 0,
+	.playback = {
+		.stream_name = "SiRF USP PCM Playback",
+		.channels_min = 1,
+		.channels_max = 1,
+		.rates = SNDRV_PCM_RATE_48000
+			| SNDRV_PCM_RATE_44100
+			| SNDRV_PCM_RATE_32000
+			| SNDRV_PCM_RATE_22050
+			| SNDRV_PCM_RATE_16000
+			| SNDRV_PCM_RATE_11025
+			| SNDRV_PCM_RATE_8000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.capture = {
+		.stream_name = "SiRF USP PCM Capture",
+		.channels_min = 1,
+		.channels_max = 1,
+		.rates = SNDRV_PCM_RATE_48000
+			| SNDRV_PCM_RATE_44100
+			| SNDRV_PCM_RATE_32000
+			| SNDRV_PCM_RATE_22050
+			| SNDRV_PCM_RATE_16000
+			| SNDRV_PCM_RATE_11025
+			| SNDRV_PCM_RATE_8000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.ops = &sirf_usp_pcm_dai_ops,
+};
+
+static void sirf_usp_controller_init(struct sirf_usp *susp)
+{
+	u32 val;
+
+	/* Configure RISC mode */
+	writel(readl(susp->base + USP_RISC_DSP_MODE) & ~USP_RISC_DSP_SEL,
+		susp->base + USP_RISC_DSP_MODE);
+
+	/* Disable all interrupts status */
+	writel(readl(susp->base + USP_INT_STATUS), susp->base + USP_INT_STATUS);
+
+	/* Configure DMA IO Length register */
+	writel(0, susp->base + USP_TX_DMA_IO_LEN);
+	writel(0, susp->base + USP_RX_DMA_IO_LEN);
+
+	/* Configure RX Frame Control */
+	val = (AUDIO_WORD_SIZE*2 - 1)<<USP_RXC_DATA_LEN_OFFSET;
+	val |= (AUDIO_WORD_SIZE*2 - 1)<<USP_RXC_FRAME_LEN_OFFSET;
+	val |= (AUDIO_WORD_SIZE*2 - 1)<<USP_RXC_SHIFTER_LEN_OFFSET;
+	val |= USP_SINGLE_SYNC_MODE;
+	writel(val, susp->base + USP_RX_FRAME_CTRL);
+
+	/* Configure TX Frame Control */
+	val = (AUDIO_WORD_SIZE*2 - 1)<<USP_TXC_DATA_LEN_OFFSET;
+	val |= 0<<USP_TXC_SYNC_LEN_OFFSET;
+	val |= (AUDIO_WORD_SIZE*2 - 1)<<USP_TXC_FRAME_LEN_OFFSET;
+	val |= (AUDIO_WORD_SIZE*2 - 1)<<USP_TXC_SHIFTER_LEN_OFFSET;
+	val |= USP_TXC_SLAVE_CLK_SAMPLE;
+	writel(val, susp->base + USP_TX_FRAME_CTRL);
+
+	/* Configure Mode2 register */
+	val = (1<<USP_RXD_DELAY_LEN_OFFSET) | (0<<USP_TXD_DELAY_LEN_OFFSET);
+	val &= ~USP_ENA_CTRL_MODE;
+	val &= ~USP_FRAME_CTRL_MODE;
+	val &= ~USP_TFS_SOURCE_MODE;
+	writel(val, susp->base + USP_MODE2);
+
+	/* Configure Mode1 register */
+	val = 0;
+	val |= USP_SYNC_MODE;
+	val |= USP_ENDIAN_CTRL_LSBF;
+	val |= USP_EN;
+	val |= USP_RXD_ACT_EDGE_FALLING;
+	val &= ~USP_TXD_ACT_EDGE_FALLING;
+	val |= USP_RFS_ACT_LEVEL_LOGIC1;
+	val |= USP_TFS_ACT_LEVEL_LOGIC1;
+	val |= USP_SCLK_IDLE_MODE_TOGGLE;
+	val |= USP_SCLK_IDLE_LEVEL_LOGIC1;
+	val &= ~USP_SCLK_PIN_MODE_IO;
+	val &= ~USP_RFS_PIN_MODE_IO;
+	val &= ~USP_TFS_PIN_MODE_IO;
+	val &= ~USP_RXD_PIN_MODE_IO;
+	val &= ~USP_TXD_PIN_MODE_IO;
+	val |= USP_TX_UFLOW_REPEAT_ZERO;
+	writel(val, susp->base + USP_MODE1);
+
+	/* Configure RX DMA IO Control register */
+	writel(0x0, susp->base + USP_RX_DMA_IO_CTRL);
+
+	/* Congiure RX FIFO Control register */
+	writel((USP_RX_FIFO_THRESHOLD << USP_RX_FIFO_THD_OFFSET) |
+		(USP_TX_RX_FIFO_WIDTH_DWORD << USP_RX_FIFO_WIDTH_OFFSET),
+		susp->base + USP_RX_FIFO_CTRL);
+
+	/* Congiure RX FIFO Level Check register */
+	writel(RX_FIFO_SC(0x04)|RX_FIFO_LC(0x0E)|RX_FIFO_HC(0x1B),
+		susp->base + USP_RX_FIFO_LEVEL_CHK);
+
+	/* Configure TX DMA IO Control register*/
+	writel(0x0, susp->base + USP_TX_DMA_IO_CTRL);
+
+	/* Configure TX FIFO Control register */
+	writel((USP_TX_FIFO_THRESHOLD << USP_TX_FIFO_THD_OFFSET) |
+		(USP_TX_RX_FIFO_WIDTH_DWORD << USP_TX_FIFO_WIDTH_OFFSET),
+		susp->base + USP_TX_FIFO_CTRL);
+
+	/* Congiure TX FIFO Level Check register */
+	writel(TX_FIFO_SC(0x1B)|TX_FIFO_LC(0x0E)|TX_FIFO_HC(0x04),
+		susp->base + USP_TX_FIFO_LEVEL_CHK);
+
+	/* Configure RX FIFO */
+	writel(USP_RX_FIFO_RESET, susp->base + USP_RX_FIFO_OP);
+	writel(0, susp->base + USP_RX_FIFO_OP);
+
+	/* Configure TX FIFO */
+	writel(USP_TX_FIFO_RESET, susp->base + USP_TX_FIFO_OP);
+	writel(0, susp->base + USP_TX_FIFO_OP);
+}
+
+static void sirf_usp_controller_uninit(struct sirf_usp *susp)
+{
+	/* Disable RX/TX */
+	writel(0, susp->base+USP_INT_ENABLE);
+	writel(0, susp->base + USP_TX_RX_ENABLE);
+}
+
+#ifdef CONFIG_PM
+static int sirf_usp_pcm_suspend(struct platform_device *pdev,
+	pm_message_t state)
+{
+	struct sirf_usp *susp = platform_get_drvdata(pdev);
+
+	susp->mode1_reg = readl(susp->base + USP_MODE1);
+	susp->mode2_reg = readl(susp->base + USP_MODE2);
+	sirf_usp_controller_uninit(susp);
+	clk_disable_unprepare(susp->clk);
+
+	return 0;
+}
+
+static int sirf_usp_pcm_resume(struct platform_device *pdev)
+{
+	struct sirf_usp *susp = platform_get_drvdata(pdev);
+
+	clk_prepare_enable(susp->clk);
+	sirf_usp_controller_init(susp);
+
+	writel(susp->mode1_reg, susp->base + USP_MODE1);
+	writel(susp->mode2_reg, susp->base + USP_MODE2);
+
+	return 0;
+}
+#else
+#define sirf_usp_pcm_suspend NULL
+#define sirf_usp_pcm_resume NULL
+#endif
+
+static const struct snd_soc_component_driver sirf_usp_component = {
+	.name		= "sirf-usp",
+};
+
+static int sirf_usp_pcm_probe(struct platform_device *pdev)
+{
+	struct sirf_usp *susp;
+	u32 rx_dma_ch, tx_dma_ch;
+	int ret;
+	struct resource *mem_res;
+
+	susp = devm_kzalloc(&pdev->dev, sizeof(struct sirf_usp),
+			GFP_KERNEL);
+	if (!susp)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, susp);
+
+	ret = of_property_read_u32(pdev->dev.of_node,
+			"sirf,usp-dma-rx-channel", &rx_dma_ch);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Unable to USP0 rx dma channel\n");
+		return ret;
+	}
+	ret = of_property_read_u32(pdev->dev.of_node,
+			"sirf,usp-dma-tx-channel", &tx_dma_ch);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Unable to USP0 tx dma channel\n");
+		return ret;
+	}
+	sirf_usp_pcm_dai_dma_data[0].dma_req = tx_dma_ch;
+	sirf_usp_pcm_dai_dma_data[1].dma_req = rx_dma_ch;
+
+	mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	susp->base = devm_ioremap_resource(&pdev->dev, mem_res);
+	if (susp->base == NULL)
+		return -ENOMEM;
+
+	susp->clk = clk_get(&pdev->dev, NULL);
+	if (IS_ERR(susp->clk)) {
+		dev_err(&pdev->dev, "Get clock failed.\n");
+		return PTR_ERR(susp->clk);
+	}
+	clk_prepare_enable(susp->clk);
+
+	sirf_usp_controller_init(susp);
+
+	ret = snd_soc_register_component(&pdev->dev, &sirf_usp_component,
+		&sirf_usp_pcm_dai, 1);
+	if (ret) {
+		dev_err(&pdev->dev, "Register Audio SoC dai failed.\n");
+		goto err_clk_put;
+	}
+
+	return 0;
+
+err_clk_put:
+	clk_disable_unprepare(susp->clk);
+	clk_put(susp->clk);
+	return ret;
+}
+
+static int sirf_usp_pcm_remove(struct platform_device *pdev)
+{
+	struct sirf_usp *susp = platform_get_drvdata(pdev);
+	snd_soc_unregister_component(&pdev->dev);
+	sirf_usp_controller_uninit(susp);
+	clk_disable_unprepare(susp->clk);
+	clk_put(susp->clk);
+
+	return 0;
+}
+
+static const struct of_device_id sirf_usp_pcm_of_match[] = {
+	{ .compatible = "sirf,prima2-usp-pcm", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, sirf_usp_pcm_of_match);
+
+static struct platform_driver sirf_usp_pcm_driver = {
+	.driver = {
+		.name = "sirf-usp-pcm",
+		.owner = THIS_MODULE,
+		.of_match_table = sirf_usp_pcm_of_match,
+	},
+	.probe = sirf_usp_pcm_probe,
+	.remove = sirf_usp_pcm_remove,
+	.suspend = sirf_usp_pcm_suspend,
+	.resume = sirf_usp_pcm_resume,
+};
+
+module_platform_driver(sirf_usp_pcm_driver);
+
+MODULE_DESCRIPTION("SiRF SoC USP PCM bus driver");
+MODULE_AUTHOR("RongJun Ying <Rongjun.Ying at csr.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/sound/soc/sirf/sirf-usp.h b/sound/soc/sirf/sirf-usp.h
new file mode 100644
index 0000000..cb9085f
--- /dev/null
+++ b/sound/soc/sirf/sirf-usp.h
@@ -0,0 +1,276 @@
+/*
+ * arch/arm/mach-prima2/include/mach/sirfsoc_usp.h
+ *
+ * Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group company.
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#ifndef __SIRFSOC_USP__
+#define __SIRFSOC_USP__
+
+/* USP Registers */
+#define USP_MODE1		0x00
+#define USP_MODE2 		0x04
+#define USP_TX_FRAME_CTRL  	0x08
+#define USP_RX_FRAME_CTRL	0x0C
+#define USP_TX_RX_ENABLE	0x10
+#define USP_INT_ENABLE		0x14
+#define USP_INT_STATUS		0x18
+#define USP_PIN_IO_DATA		0x1C
+#define USP_RISC_DSP_MODE	0x20
+#define USP_AYSNC_PARAM_REG	0x24
+#define USP_IRDA_X_MODE_DIV	0x28
+#define USP_SM_CFG		0x2C
+#define USP_TX_DMA_IO_CTRL	0x100
+#define USP_TX_DMA_IO_LEN	0x104
+#define USP_TX_FIFO_CTRL	0x108
+#define USP_TX_FIFO_LEVEL_CHK	0x10C
+#define USP_TX_FIFO_OP		0x110
+#define USP_TX_FIFO_STATUS	0x114
+#define USP_TX_FIFO_DATA	0x118
+#define USP_RX_DMA_IO_CTRL	0x120
+#define USP_RX_DMA_IO_LEN	0x124
+#define USP_RX_FIFO_CTRL	0x128
+#define USP_RX_FIFO_LEVEL_CHK	0x12C
+#define USP_RX_FIFO_OP		0x130
+#define USP_RX_FIFO_STATUS	0x134
+#define USP_RX_FIFO_DATA	0x138
+
+/* USP MODE register-1 */
+#define USP_SYNC_MODE 			0x00000001
+#define USP_CLOCK_MODE_SLAVE 		0x00000002
+#define USP_LOOP_BACK_EN		0x00000004
+#define USP_HPSIR_EN			0x00000008
+#define USP_ENDIAN_CTRL_LSBF		0x00000010
+#define USP_EN				0x00000020
+#define USP_RXD_ACT_EDGE_FALLING	0x00000040
+#define USP_TXD_ACT_EDGE_FALLING	0x00000080
+#define USP_RFS_ACT_LEVEL_LOGIC1	0x00000100
+#define USP_TFS_ACT_LEVEL_LOGIC1	0x00000200
+#define USP_SCLK_IDLE_MODE_TOGGLE	0x00000400
+#define USP_SCLK_IDLE_LEVEL_LOGIC1	0x00000800
+#define USP_SCLK_PIN_MODE_IO	0x00001000
+#define USP_RFS_PIN_MODE_IO	0x00002000
+#define USP_TFS_PIN_MODE_IO	0x00004000
+#define USP_RXD_PIN_MODE_IO	0x00008000
+#define USP_TXD_PIN_MODE_IO	0x00010000
+#define USP_SCLK_IO_MODE_INPUT	0x00020000
+#define USP_RFS_IO_MODE_INPUT	0x00040000
+#define USP_TFS_IO_MODE_INPUT	0x00080000
+#define USP_RXD_IO_MODE_INPUT	0x00100000
+#define USP_TXD_IO_MODE_INPUT	0x00200000
+#define USP_IRDA_WIDTH_DIV_MASK	0x3FC00000
+#define USP_IRDA_WIDTH_DIV_OFFSET	0
+#define USP_IRDA_IDLE_LEVEL_HIGH	0x40000000
+#define USP_TX_UFLOW_REPEAT_ZERO	0x80000000
+#define USP_TX_ENDIAN_MODE		0x00000020
+#define USP_RX_ENDIAN_MODE		0x00000020
+
+/* USP Mode Register-2 */
+#define USP_RXD_DELAY_LEN_MASK		0x000000FF
+#define USP_RXD_DELAY_LEN_OFFSET	0
+
+#define USP_TXD_DELAY_LEN_MASK		0x0000FF00
+#define USP_TXD_DELAY_LEN_OFFSET	8
+
+#define USP_ENA_CTRL_MODE		0x00010000
+#define USP_FRAME_CTRL_MODE		0x00020000
+#define USP_TFS_SOURCE_MODE             0x00040000
+#define USP_TFS_MS_MODE                 0x00080000
+#define USP_CLK_DIVISOR_MASK		0x7FE00000
+#define USP_CLK_DIVISOR_OFFSET 		21
+
+#define USP_TFS_CLK_SLAVE_MODE		(1<<20)
+#define USP_RFS_CLK_SLAVE_MODE		(1<<19)
+
+#define USP_IRDA_DATA_WIDTH		0x80000000
+
+/* USP Transmit Frame Control Register */
+
+#define USP_TXC_DATA_LEN_MASK		0x000000FF
+#define USP_TXC_DATA_LEN_OFFSET		0
+
+#define USP_TXC_SYNC_LEN_MASK		0x0000FF00
+#define USP_TXC_SYNC_LEN_OFFSET		8
+
+#define USP_TXC_FRAME_LEN_MASK		0x00FF0000
+#define USP_TXC_FRAME_LEN_OFFSET 	16
+
+#define USP_TXC_SHIFTER_LEN_MASK	0x1F000000
+#define USP_TXC_SHIFTER_LEN_OFFSET	24
+
+#define USP_TXC_SLAVE_CLK_SAMPLE 	0x20000000
+
+#define USP_TXC_CLK_DIVISOR_MASK  	0xC0000000
+#define USP_TXC_CLK_DIVISOR_OFFSET 	30
+
+/* USP Receive Frame Control Register */
+
+#define USP_RXC_DATA_LEN_MASK 		0x000000FF
+#define USP_RXC_DATA_LEN_OFFSET		0
+
+#define USP_RXC_FRAME_LEN_MASK		0x0000FF00
+#define USP_RXC_FRAME_LEN_OFFSET  	8
+
+#define USP_RXC_SHIFTER_LEN_MASK 	0x001F0000
+#define USP_RXC_SHIFTER_LEN_OFFSET 	16
+
+#define USP_I2S_SYNC_CHG		0x00200000
+
+#define USP_RXC_CLK_DIVISOR_MASK  	0x0F000000
+#define USP_RXC_CLK_DIVISOR_OFFSET 	24
+#define USP_SINGLE_SYNC_MODE		0x00400000
+
+/* Tx - RX Enable Register */
+
+#define USP_RX_ENA		0x00000001
+#define USP_TX_ENA		0x00000002
+
+/* USP Interrupt Enable and status Register */
+#define USP_RX_DONE_INT			0x00000001
+#define USP_TX_DONE_INT			0x00000002
+#define USP_RX_OFLOW_INT		0x00000004
+#define USP_TX_UFLOW_INT		0x00000008
+#define USP_RX_IO_DMA_INT		0x00000010
+#define USP_TX_IO_DMA_INT		0x00000020
+#define USP_RXFIFO_FULL_INT		0x00000040
+#define USP_TXFIFO_EMPTY_INT		0x00000080
+#define USP_RXFIFO_THD_INT		0x00000100
+#define USP_TXFIFO_THD_INT		0x00000200
+#define USP_UART_FRM_ERR_INT		0x00000400
+#define USP_RX_TIMEOUT_INT 		0x00000800
+#define USP_TX_ALLOUT_INT  		0x00001000
+#define USP_RXD_BREAK_INT		0x00008000
+
+/* All possible TX interruots */
+#define USP_TX_INTERRUPT		(USP_TX_DONE_INT|USP_TX_UFLOW_INT|USP_TX_IO_DMA_INT|\
+					USP_TXFIFO_EMPTY_INT|USP_TXFIFO_THD_INT)
+/* All possible RX interruots */
+#define USP_RX_INTERRUPT		(USP_RX_DONE_INT|USP_RX_OFLOW_INT|USP_RX_IO_DMA_INT|\
+					USP_RXFIFO_FULL_INT|USP_RXFIFO_THD_INT|USP_RXFIFO_THD_INT|USP_RX_TIMEOUT_INT)
+
+#define USP_INT_ALL        0x1FFF
+
+/* USP Pin I/O Data Register */
+
+#define USP_RFS_PIN_VALUE_MASK	0x00000001
+#define USP_TFS_PIN_VALUE_MASK	0x00000002
+#define USP_RXD_PIN_VALUE_MASK	0x00000004
+#define USP_TXD_PIN_VALUE_MASK	0x00000008
+#define USP_SCLK_PIN_VALUE_MASK	0x00000010
+
+/* USP RISC/DSP Mode Register */
+#define USP_RISC_DSP_SEL	0x00000001
+
+/* USP ASYNC PARAMETER Register*/
+
+#define USP_ASYNC_TIMEOUT_MASK 	0x0000FFFF
+#define USP_ASYNC_TIMEOUT_OFFSET	0
+#define USP_ASYNC_TIMEOUT(x)	(((x)&USP_ASYNC_TIMEOUT_MASK)<<USP_ASYNC_TIMEOUT_OFFSET)
+
+#define USP_ASYNC_DIV2_MASK		0x003F0000
+#define USP_ASYNC_DIV2_OFFSET		16
+
+/* USP TX DMA I/O MODE Register */
+#define USP_TX_MODE_IO			0x00000001
+
+/* USP TX DMA I/O Length Register */
+#define USP_TX_DATA_LEN_MASK		0xFFFFFFFF
+#define USP_TX_DATA_LEN_OFFSET		0
+
+/* USP TX FIFO Control Register */
+#define USP_TX_FIFO_WIDTH_MASK		0x00000003
+#define USP_TX_FIFO_WIDTH_OFFSET	0
+
+#define USP_TX_FIFO_THD_MASK		0x000001FC
+#define USP_TX_FIFO_THD_OFFSET		2
+
+/* USP TX FIFO Level Check Register */
+#define USP_TX_FIFO_LEVEL_CHECK_MASK	0x1F
+#define USP_TX_FIFO_SC_OFFSET	0
+#define USP_TX_FIFO_LC_OFFSET	10
+#define USP_TX_FIFO_HC_OFFSET	20
+
+#define TX_FIFO_SC(x)		(((x) & USP_TX_FIFO_LEVEL_CHECK_MASK) << USP_TX_FIFO_SC_OFFSET)
+#define TX_FIFO_LC(x)		(((x) & USP_TX_FIFO_LEVEL_CHECK_MASK) << USP_TX_FIFO_LC_OFFSET)
+#define TX_FIFO_HC(x)		(((x) & USP_TX_FIFO_LEVEL_CHECK_MASK) << USP_TX_FIFO_HC_OFFSET)
+
+/* USP TX FIFO Operation Register */
+#define USP_TX_FIFO_RESET		0x00000001
+#define USP_TX_FIFO_START		0x00000002
+
+/* USP TX FIFO Status Register */
+#define USP_TX_FIFO_LEVEL_MASK		0x0000007F
+#define USP_TX_FIFO_LEVEL_OFFSET	0
+
+#define USP_TX_FIFO_FULL 		0x00000080
+#define USP_TX_FIFO_EMPTY		0x00000100
+
+/* USP TX FIFO Data Register */
+#define USP_TX_FIFO_DATA_MASK		0xFFFFFFFF
+#define USP_TX_FIFO_DATA_OFFSET		0
+
+/* USP RX DMA I/O MODE Register */
+#define USP_RX_MODE_IO			0x00000001
+#define USP_RX_DMA_FLUSH		0x00000004
+
+/* USP RX DMA I/O Length Register */
+#define USP_RX_DATA_LEN_MASK		0xFFFFFFFF
+#define USP_RX_DATA_LEN_OFFSET		0
+
+/* USP RX FIFO Control Register */
+#define USP_RX_FIFO_WIDTH_MASK		0x00000003
+#define USP_RX_FIFO_WIDTH_OFFSET	0
+
+#define USP_RX_FIFO_THD_MASK		0x000001FC
+#define USP_RX_FIFO_THD_OFFSET		2
+
+/* USP RX FIFO Level Check Register */
+
+#define USP_RX_FIFO_LEVEL_CHECK_MASK	0x1F
+#define USP_RX_FIFO_SC_OFFSET	0
+#define USP_RX_FIFO_LC_OFFSET	10
+#define USP_RX_FIFO_HC_OFFSET	20
+
+#define RX_FIFO_SC(x)		(((x) & USP_RX_FIFO_LEVEL_CHECK_MASK) << USP_RX_FIFO_SC_OFFSET)
+#define RX_FIFO_LC(x)		(((x) & USP_RX_FIFO_LEVEL_CHECK_MASK) << USP_RX_FIFO_LC_OFFSET)
+#define RX_FIFO_HC(x)		(((x) & USP_RX_FIFO_LEVEL_CHECK_MASK) << USP_RX_FIFO_HC_OFFSET)
+
+/* USP RX FIFO Operation Register */
+#define USP_RX_FIFO_RESET		0x00000001
+#define USP_RX_FIFO_START		0x00000002
+
+/* USP RX FIFO Status Register */
+
+#define USP_RX_FIFO_LEVEL_MASK		0x0000007F
+#define USP_RX_FIFO_LEVEL_OFFSET	0
+
+#define USP_RX_FIFO_FULL		0x00000080
+#define USP_RX_FIFO_EMPTY		0x00000100
+
+/* USP RX FIFO Data Register */
+
+#define USP_RX_FIFO_DATA_MASK		0xFFFFFFFF
+#define USP_RX_FIFO_DATA_OFFSET		0
+
+/*
+ * When rx thd irq occur, sender just disable tx empty irq,
+ * Remaining data in tx fifo wil also be sent out.
+ */
+#define USP_FIFO_SIZE           	128
+#define USP_TX_FIFO_THRESHOLD		(USP_FIFO_SIZE/2)
+#define USP_RX_FIFO_THRESHOLD		(USP_FIFO_SIZE/2)
+
+/* FIFO_WIDTH for the USP_TX_FIFO_CTRL and USP_RX_FIFO_CTRL registers */
+#define USP_FIFO_WIDTH_BYTE  0x00
+#define USP_FIFO_WIDTH_WORD  0x01
+#define USP_FIFO_WIDTH_DWORD 0x02
+
+#define USP_ASYNC_DIV2          16
+
+#define USP_PLUGOUT_RETRY_CNT	2
+
+#define USP_TX_RX_FIFO_WIDTH_DWORD    2
+
+#endif
-- 
1.8.2.3



From 21cnbao at gmail.com  Fri Jul 19 07:07:20 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Fri, 19 Jul 2013 19:07:20 +0800
Subject: [PATCH 4/6] ASoC: sirf-soc-inner: add drivers for both CPU and Codec
 DAIs
In-Reply-To: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <1374232042-26088-5-git-send-email-Baohua.Song@csr.com>

From: Rongjun Ying <Rongjun.Ying at csr.com>

there is an internal codec embedded in the SiRF SoC. this is not
a typical user scenerios of ASoC. but we can still get benefit by
sharing platform DMA codes instead of implementing a pure ALSA
driver.
This driver adds DAI drivers for this internal codec.

The features of  Internal Codec Controller include:
Support two channel 16-bit resolution playback with fix 48KHz sample rate
Support two channel 16-bit resolution record with fix 48KHz sample rate
Use dedicated Internal Codec TXFIFO and Internal Codec RXFIFO
Supports two DMA channels for Internal Codec TXFIFO and Internal Codec RXFIFO

Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 sound/soc/sirf/Kconfig          |   3 +
 sound/soc/sirf/Makefile         |   2 +
 sound/soc/sirf/sirf-soc-inner.c | 653 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 658 insertions(+)
 create mode 100644 sound/soc/sirf/sirf-soc-inner.c

diff --git a/sound/soc/sirf/Kconfig b/sound/soc/sirf/Kconfig
index 3606614..60b8857 100644
--- a/sound/soc/sirf/Kconfig
+++ b/sound/soc/sirf/Kconfig
@@ -6,5 +6,8 @@ config SND_SIRF_SOC
 config SND_SOC_SIRF_I2S
 	tristate
 
+config SND_SIRF_SOC_INNER
+	tristate
+
 config SND_SOC_SIRF_USP
 	tristate
diff --git a/sound/soc/sirf/Makefile b/sound/soc/sirf/Makefile
index 630c9be..8517c67 100644
--- a/sound/soc/sirf/Makefile
+++ b/sound/soc/sirf/Makefile
@@ -1,7 +1,9 @@
 snd-soc-sirf-objs := sirf-pcm.o
+snd-soc-sirf-soc-inner-objs := sirf-soc-inner.o
 snd-soc-sirf-i2s-objs := sirf-i2s.o
 snd-soc-sirf-usp-objs := sirf-usp.o
 
 obj-$(CONFIG_SND_SIRF_SOC) += snd-soc-sirf.o
+obj-$(CONFIG_SND_SIRF_SOC_INNER) += snd-soc-sirf-soc-inner.o
 obj-$(CONFIG_SND_SOC_SIRF_I2S) += snd-soc-sirf-i2s.o
 obj-$(CONFIG_SND_SOC_SIRF_USP) += snd-soc-sirf-usp.o
diff --git a/sound/soc/sirf/sirf-soc-inner.c b/sound/soc/sirf/sirf-soc-inner.c
new file mode 100644
index 0000000..96bf59b
--- /dev/null
+++ b/sound/soc/sirf/sirf-soc-inner.c
@@ -0,0 +1,653 @@
+/*
+ * SiRF inner audio codec driver
+ *
+ * Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group company.
+ *
+ * Licensed under GPLv2 or later.*
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/rtc/sirfsoc_rtciobrg.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <sound/core.h>
+#include <sound/pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/initval.h>
+#include <sound/soc.h>
+
+#include "sirf-audio.h"
+#include "sirf-pcm.h"
+
+struct sirf_soc_inner_audio_reg_bits {
+	u32 dig_mic_en_bits;
+	u32 dig_mic_freq_bits;
+	u32 adc14b_12_bits;
+	u32 firdac_hsl_en_bits;
+	u32 firdac_hsr_en_bits;
+	u32 firdac_lout_en_bits;
+	u32 por_bits;
+	u32 codec_clk_en_bits;
+	u32 hp_3db_boost_bits;
+	u32 adc_left_gain_shift;
+	u32 adc_right_gain_shift;
+	u32 adc_gain_mask;
+	u32 mic_max_gain;
+};
+
+struct sirf_soc_inner_audio {
+	void __iomem            *base;
+	unsigned int            playing;
+	struct clk              *clk;
+	spinlock_t              lock;
+	u32			sys_pwrc_reg_base;
+	struct sirf_soc_inner_audio_reg_bits *reg_bits;
+};
+
+static struct sirf_soc_inner_audio_reg_bits sirf_soc_inner_audio_reg_bits_prima2 = {
+	20, 21, 22, 23, 24, 25, 26, 27, 28, 15, 10, 0x1f, 0x19,
+};
+
+static struct sirf_soc_inner_audio_reg_bits sirf_soc_inner_audio_reg_bits_atlas6 = {
+	22, 23, 24, 25, 26, 27, 28, 29, 30, 16, 10, 0x3f, 0x39,
+};
+
+static int sirf_inner_control(struct snd_kcontrol *kcontrol,
+		struct snd_ctl_elem_value *ucontrol,
+		int get, char *name)
+{
+	struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct snd_soc_card *card = codec->card;
+	int i;
+	for (i = 0; i < card->num_controls; i++) {
+		if (!strcmp(card->controls[i].name, name)) {
+			if (card->controls[i].get && get)
+				return card->controls[i].get(kcontrol, ucontrol);
+			else if (card->controls[i].put && !get)
+				return card->controls[i].put(kcontrol, ucontrol);
+		}
+	}
+	return 0;
+}
+
+static int sirf_inner_snd_speaker_get(struct snd_kcontrol *kcontrol,
+		struct snd_ctl_elem_value *ucontrol)
+{
+	sirf_inner_control(kcontrol, ucontrol, 1, "Speaker Out");
+	return 0;
+}
+
+static int sirf_inner_snd_speaker_set(struct snd_kcontrol *kcontrol,
+		struct snd_ctl_elem_value *ucontrol)
+{
+	struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct sirf_soc_inner_audio *sinner_audio = dev_get_drvdata(codec->dev);
+
+	spin_lock(&sinner_audio->lock);
+	sirf_inner_control(kcontrol, ucontrol, 0, "Speaker Out");
+
+	if (ucontrol->value.integer.value[0]) {
+		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0)
+				| IC_RDACEN | IC_SPSELR,
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+
+		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1) |
+				(1 << sinner_audio->reg_bits->firdac_lout_en_bits),
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+
+		writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) |
+					IC_SPEN), sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+	} else {
+		writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0)
+					& ~(IC_SPEN | IC_SPSELR)),
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1)
+				& ~(1 << sinner_audio->reg_bits->firdac_lout_en_bits),
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+	}
+
+	spin_unlock(&sinner_audio->lock);
+
+	return 0;
+}
+
+static int sirf_inner_snd_headphone_get(struct snd_kcontrol *kcontrol,
+		struct snd_ctl_elem_value *ucontrol)
+{
+	sirf_inner_control(kcontrol, ucontrol, 1, "Headphone Out");
+	return 0;
+}
+
+static int sirf_inner_snd_headphone_set(struct snd_kcontrol *kcontrol,
+		struct snd_ctl_elem_value *ucontrol)
+{
+	struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct sirf_soc_inner_audio *sinner_audio = dev_get_drvdata(codec->dev);
+
+	spin_lock(&sinner_audio->lock);
+	sirf_inner_control(kcontrol, ucontrol, 0, "Headphone Out");
+	if (ucontrol->value.integer.value[0])
+		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0)
+				| IC_HSLEN | IC_HSREN | IC_HPRSELR
+				| IC_HPLSELL,
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+	else
+		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0)
+				& ~(IC_HSLEN | IC_HSREN | IC_HPRSELR
+					| IC_HPLSELL),
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+	spin_unlock(&sinner_audio->lock);
+	return 0;
+}
+
+static struct snd_kcontrol_new snd_sirf_inner_volume_controls_atlas6[] = {
+	SOC_DOUBLE("Speaker Volume", AUDIO_IC_CODEC_CTRL0, 21, 14,
+			0x7F, 0),
+	SOC_DOUBLE("Capture Volume", AUDIO_IC_CODEC_CTRL1, 16, 10,
+			0x3F, 0),
+	SOC_DOUBLE("Capture Switch", AUDIO_IC_CODEC_CTRL1, 0, 1,
+			1, 0),
+	SOC_SINGLE_BOOL_EXT("Speaker Switch", 0, sirf_inner_snd_speaker_get,
+			sirf_inner_snd_speaker_set),
+	SOC_SINGLE_BOOL_EXT("Headphone Switch", 0, sirf_inner_snd_headphone_get,
+			sirf_inner_snd_headphone_set),
+};
+
+static struct snd_kcontrol_new snd_sirf_inner_volume_controls_prima2[] = {
+	SOC_DOUBLE("Speaker Volume", AUDIO_IC_CODEC_CTRL0, 21, 14,
+			0x7F, 0),
+	SOC_DOUBLE("Capture Volume", AUDIO_IC_CODEC_CTRL1, 15, 10,
+			0x1F, 0),
+	SOC_DOUBLE("Capture Switch", AUDIO_IC_CODEC_CTRL1, 0, 1,
+			1, 0),
+	SOC_SINGLE_BOOL_EXT("Speaker Switch", 0, sirf_inner_snd_speaker_get,
+			sirf_inner_snd_speaker_set),
+	SOC_SINGLE_BOOL_EXT("Headphone Switch", 0, sirf_inner_snd_headphone_get,
+			sirf_inner_snd_headphone_set),
+};
+
+static int sirf_inner_codec_startup(struct snd_pcm_substream *substream,
+		struct snd_soc_dai *dai)
+{
+	struct sirf_soc_inner_audio *sinner_audio = snd_soc_dai_get_drvdata(dai);
+	u32 adc_gain_mask = sinner_audio->reg_bits->adc_gain_mask;
+	u32 adc_left_gain_shift = sinner_audio->reg_bits->adc_left_gain_shift;
+	u32 adc_right_gain_shift = sinner_audio->reg_bits->adc_right_gain_shift;
+	u32 mic_max_gain = sinner_audio->reg_bits->mic_max_gain;
+
+	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+		writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1)
+					| (1 << sinner_audio->reg_bits->codec_clk_en_bits) |
+					(1 << sinner_audio->reg_bits->por_bits)),
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+
+		writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) | IC_HSINVEN)
+				& ~IC_MONOR,
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+
+		msleep(50);
+
+		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) | IC_RDACEN |
+				IC_LDACEN | IC_HPRSELR | IC_HPLSELL,
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+
+		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1) |
+					(1 << sinner_audio->reg_bits->firdac_hsl_en_bits) |
+					(1 << sinner_audio->reg_bits->firdac_hsr_en_bits),
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+
+		usleep_range(300, 1000);
+
+		writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0)
+					| IC_HSREN | IC_HSLEN),
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+
+		/* avoid break noise when sound loud, set RX gain -1dB */
+		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) &
+				~((IC_RXPGAR_MASK << IC_RXPGAR_SHIFT) |
+					(IC_RXPGAL_MASK << IC_RXPGAL_SHIFT)),
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+
+		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) |
+				((IC_RXPGAR << IC_RXPGAR_SHIFT) |
+				 (IC_RXPGAL << IC_RXPGAL_SHIFT)),
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+	} else if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) {
+#define PWRC_PDN_CTRL_OFFSET    0
+#define AUDIO_POWER_EN_BIT      14
+		sirfsoc_rtc_iobrg_writel(sirfsoc_rtc_iobrg_readl(
+			(sinner_audio->sys_pwrc_reg_base +
+			PWRC_PDN_CTRL_OFFSET))
+			| (1 << AUDIO_POWER_EN_BIT),
+			sinner_audio->sys_pwrc_reg_base +
+			PWRC_PDN_CTRL_OFFSET);
+
+		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1) |
+			(1 << sinner_audio->reg_bits->codec_clk_en_bits) |
+			(1 << sinner_audio->reg_bits->por_bits),
+			sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+		msleep(50);
+
+		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_PWR) |
+			MICBIASEN, sinner_audio->base + AUDIO_IC_CODEC_PWR);
+		usleep_range(300, 1000);
+
+		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1)
+			| IC_MICINREN | IC_MICINLEN,
+			sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+		usleep_range(100, 200);
+		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1) | IC_RADCEN |
+			IC_LADCEN, sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+		usleep_range(100, 200);
+		writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1) | IC_MICIN1SEL
+			| IC_MICDIFSEL) & (~IC_MICIN2SEL),
+			sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+
+		writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1) &
+			~(adc_gain_mask << adc_left_gain_shift) &
+			~(adc_gain_mask << adc_right_gain_shift)) |
+			(mic_max_gain << adc_left_gain_shift) |
+			(mic_max_gain << adc_right_gain_shift),
+			sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+	}
+	return 0;
+}
+
+static void sirf_inner_codec_shutdown(struct snd_pcm_substream *substream,
+		struct snd_soc_dai *dai)
+{
+}
+
+static int sirf_inner_codec_hw_params(struct snd_pcm_substream *substream,
+		struct snd_pcm_hw_params *params,
+		struct snd_soc_dai *dai)
+{
+	return 0;
+}
+
+static int sirf_inner_codec_trigger(struct snd_pcm_substream *substream,
+		int cmd,
+		struct snd_soc_dai *dai)
+{
+	struct sirf_soc_inner_audio *sinner_audio = snd_soc_dai_get_drvdata(dai);
+	int playback = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
+
+	switch (cmd) {
+	case SNDRV_PCM_TRIGGER_STOP:
+	case SNDRV_PCM_TRIGGER_SUSPEND:
+	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+		spin_lock(&sinner_audio->lock);
+		if (playback) {
+			writel(readl(sinner_audio->base + AUDIO_CTRL_IC_CODEC_TX_CTRL)
+				& ~IC_TX_ENABLE,
+				sinner_audio->base + AUDIO_CTRL_IC_CODEC_TX_CTRL);
+			sinner_audio->playing = false;
+			writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0)
+				& ~(IC_SPEN | IC_SPSELR | IC_HSLEN)),
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+			writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1)
+				& ~(1 << sinner_audio->reg_bits->firdac_lout_en_bits),
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+			writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0)
+				& ~(IC_HSLEN | IC_HSREN | IC_HPRSELR | IC_HPLSELL),
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+		} else {
+			writel(readl(sinner_audio->base + AUDIO_CTRL_IC_CODEC_RX_CTRL)
+				& ~IC_RX_ENABLE,
+				sinner_audio->base + AUDIO_CTRL_IC_CODEC_RX_CTRL);
+		}
+		spin_unlock(&sinner_audio->lock);
+		break;
+	case SNDRV_PCM_TRIGGER_START:
+	case SNDRV_PCM_TRIGGER_RESUME:
+	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+		spin_lock(&sinner_audio->lock);
+		if (playback) {
+			writel(0, sinner_audio->base + AUDIO_CTRL_IC_TXFIFO_INT_MSK);
+			writel(AUDIO_FIFO_START,
+				sinner_audio->base + AUDIO_CTRL_IC_TXFIFO_OP);
+			writel(IC_TX_ENABLE,
+				sinner_audio->base + AUDIO_CTRL_IC_CODEC_TX_CTRL);
+			sinner_audio->playing = true;
+			writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0)
+				| IC_RDACEN | IC_SPSELR,
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+
+			writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1)
+				| (1 << sinner_audio->reg_bits->firdac_lout_en_bits),
+				sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+
+			writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0)
+				| IC_SPEN, sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+			writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0)
+				| IC_HSLEN | IC_HSREN
+				| IC_HPRSELR | IC_HPLSELL,
+				sinner_audio->base
+				+ AUDIO_IC_CODEC_CTRL0);
+		} else {
+			/* unmask rx fifo interrupt */
+			writel(0, sinner_audio->base
+				+ AUDIO_CTRL_IC_RXFIFO_INT_MSK);
+
+				/* First start the FIFO, then enable the tx/rx */
+			writel(AUDIO_FIFO_START, sinner_audio->base
+				+ AUDIO_CTRL_IC_RXFIFO_OP);
+			/* mono capture from dacr*/
+			if (substream->runtime->channels == 1)
+				writel(0x01, sinner_audio->base
+					+ AUDIO_CTRL_IC_CODEC_RX_CTRL);
+			else
+				writel(IC_RX_ENABLE, sinner_audio->base
+					+ AUDIO_CTRL_IC_CODEC_RX_CTRL);
+		}
+		spin_unlock(&sinner_audio->lock);
+		break;
+	default:
+		return -EINVAL;
+	}
+	return 0;
+}
+
+struct snd_soc_dai_ops sirf_inner_codec_dai_ops = {
+	.startup = sirf_inner_codec_startup,
+	.hw_params = sirf_inner_codec_hw_params,
+	.shutdown = sirf_inner_codec_shutdown,
+	.trigger = sirf_inner_codec_trigger,
+};
+
+struct snd_soc_dai_driver sirf_inner_codec_dai = {
+	.name = "sirf-soc-inner",
+	.playback = {
+		.stream_name = "Audio Playback",
+		.channels_min = 2,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_48000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.capture = {
+		.stream_name = "Audio Capture",
+		.channels_min = 1,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_48000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.ops = &sirf_inner_codec_dai_ops,
+};
+EXPORT_SYMBOL_GPL(sirf_inner_codec_dai);
+
+static int sirf_inner_codec_probe(struct snd_soc_codec *codec)
+{
+	if (of_device_is_compatible(codec->dev->of_node, "sirf,prima2-audio"))
+		return snd_soc_add_codec_controls(codec,
+			snd_sirf_inner_volume_controls_prima2,
+			ARRAY_SIZE(snd_sirf_inner_volume_controls_prima2));
+	if (of_device_is_compatible(codec->dev->of_node, "sirf,atlas6-audio"))
+		return snd_soc_add_codec_controls(codec,
+			snd_sirf_inner_volume_controls_atlas6,
+			ARRAY_SIZE(snd_sirf_inner_volume_controls_atlas6));
+
+	return -EINVAL;
+}
+
+static int sirf_inner_codec_remove(struct snd_soc_codec *codec)
+{
+	return 0;
+}
+
+static unsigned int sirf_inner_codec_reg_read(struct snd_soc_codec *codec,
+		unsigned int reg)
+{
+	struct sirf_soc_inner_audio *sinner_audio = dev_get_drvdata(codec->dev);
+	return readl(sinner_audio->base + reg);
+}
+
+static int sirf_inner_codec_reg_write(struct snd_soc_codec *codec,
+	unsigned int reg, unsigned int val)
+{
+	struct sirf_soc_inner_audio *sinner_audio = dev_get_drvdata(codec->dev);
+	writel(val, sinner_audio->base + reg);
+	return 0;
+}
+
+
+static struct snd_soc_codec_driver soc_codec_device_sirf_inner_codec = {
+	.probe = sirf_inner_codec_probe,
+	.remove = sirf_inner_codec_remove,
+	.read = sirf_inner_codec_reg_read,
+	.write = sirf_inner_codec_reg_write,
+};
+
+static struct sirf_pcm_dma_data sirf_soc_inner_dai_dma_data[2] = {
+	{
+		.name = "Audio Playback",
+	}, {
+		.name = "Audio Capture",
+	},
+};
+
+static int sirf_soc_inner_dai_startup(struct snd_pcm_substream *substream,
+		struct snd_soc_dai *dai)
+{
+	snd_soc_dai_set_dma_data(dai, substream,
+			&sirf_soc_inner_dai_dma_data[substream->stream]);
+	return 0;
+}
+
+static int sirf_soc_inner_dai_hw_params(struct snd_pcm_substream *substream,
+		struct snd_pcm_hw_params *params,
+		struct snd_soc_dai *dai)
+{
+	int playback = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
+	struct sirf_soc_inner_audio *sinner_audio =
+			snd_soc_dai_get_drvdata(dai);
+	if (playback) {
+		writel(AUDIO_FIFO_RESET,
+				sinner_audio->base + AUDIO_CTRL_IC_TXFIFO_OP);
+
+		writel(0x00,
+				sinner_audio->base + AUDIO_CTRL_IC_TXFIFO_OP);
+	} else {
+		writel(AUDIO_FIFO_RESET,
+				sinner_audio->base + AUDIO_CTRL_IC_RXFIFO_OP);
+
+		writel(0x00,
+				sinner_audio->base + AUDIO_CTRL_IC_RXFIFO_OP);
+	}
+	return 0;
+}
+
+static const struct snd_soc_dai_ops sirf_soc_inner_dai_ops = {
+	.startup        = sirf_soc_inner_dai_startup,
+	.hw_params      = sirf_soc_inner_dai_hw_params,
+};
+
+static struct snd_soc_dai_driver sirf_soc_inner_dai = {
+	.name		= "sirf-soc-inner",
+	.id			= 0,
+	.playback = {
+		.stream_name = "inner Playback",
+		.channels_min = 2,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_48000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.capture = {
+		.stream_name = "inner Capture",
+		.channels_min = 1,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_48000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.ops = &sirf_soc_inner_dai_ops,
+};
+
+static const struct snd_soc_component_driver sirf_soc_inner_component = {
+	.name		= "sirf-soc-inner",
+};
+
+static const struct of_device_id sirf_soc_inner_of_match[] = {
+	{ .compatible = "sirf,prima2-audio", .data = &sirf_soc_inner_audio_reg_bits_prima2 },
+	{ .compatible = "sirf,atlas6-audio", .data = &sirf_soc_inner_audio_reg_bits_atlas6 },
+	{}
+};
+MODULE_DEVICE_TABLE(of, sirf_soc_inner_of_match);
+
+static int sirf_soc_inner_probe(struct platform_device *pdev)
+{
+	int ret;
+	u32 rx_dma_ch, tx_dma_ch;
+	struct sirf_soc_inner_audio *sinner_audio;
+	struct resource *mem_res;
+	struct device_node *dn = NULL;
+	const struct of_device_id *match;
+
+	match = of_match_node(sirf_soc_inner_of_match, pdev->dev.of_node);
+
+	sinner_audio = devm_kzalloc(&pdev->dev,
+		sizeof(struct sirf_soc_inner_audio), GFP_KERNEL);
+	if (!sinner_audio)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, sinner_audio);
+
+	ret = of_property_read_u32(pdev->dev.of_node,
+			"sirf,inner-audio-dma-rx-channel", &rx_dma_ch);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Unable to audio capture dma channel\n");
+		return ret;
+	}
+	ret = of_property_read_u32(pdev->dev.of_node,
+			"sirf,inner-audio-dma-tx-channel", &tx_dma_ch);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Unable to audio playback dma channel\n");
+		return ret;
+	}
+	sirf_soc_inner_dai_dma_data[0].dma_req = tx_dma_ch;
+	sirf_soc_inner_dai_dma_data[1].dma_req = rx_dma_ch;
+
+	dn = of_find_compatible_node(dn, NULL, "sirf,prima2-pwrc");
+	if (!dn) {
+		dev_err(&pdev->dev, "Failed to get sirf,prima2-pwrc  node!\n");
+		return -ENODEV;
+	}
+
+	ret = of_property_read_u32(dn, "reg", &sinner_audio->sys_pwrc_reg_base);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed tp get pwrc register base address\n");
+		return -EINVAL;
+	}
+
+	mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	sinner_audio->base = devm_ioremap_resource(&pdev->dev, mem_res);
+	if (sinner_audio->base == NULL)
+		return -ENOMEM;
+
+	sinner_audio->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(sinner_audio->clk)) {
+		dev_err(&pdev->dev, "Get clock failed.\n");
+		return PTR_ERR(sinner_audio->clk);
+	}
+	clk_prepare_enable(sinner_audio->clk);
+
+	ret = snd_soc_register_component(&pdev->dev, &sirf_soc_inner_component,
+		&sirf_soc_inner_dai, 1);
+	if (ret) {
+		dev_err(&pdev->dev, "Register Audio SoC dai failed.\n");
+		goto err_clk_put;
+	}
+
+	ret = snd_soc_register_codec(&(pdev->dev),
+			&soc_codec_device_sirf_inner_codec,
+			&sirf_inner_codec_dai, 1);
+	if (ret) {
+		dev_err(&pdev->dev, "Register Audio Codec dai failed.\n");
+		goto err_com_unreg;
+	}
+
+	sinner_audio->reg_bits = (struct sirf_soc_inner_audio_reg_bits *)match->data;
+
+	spin_lock_init(&sinner_audio->lock);
+	writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1)
+				| (1 << sinner_audio->reg_bits->codec_clk_en_bits)),
+			sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+	writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1)
+			| (1 << sinner_audio->reg_bits->adc14b_12_bits)),
+			sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+	writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) | IC_CPFREQ,
+			sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+	writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) | IC_CPEN,
+			sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+	return 0;
+
+err_com_unreg:
+	snd_soc_unregister_component(&pdev->dev);
+err_clk_put:
+	clk_disable_unprepare(sinner_audio->clk);
+	return ret;
+}
+
+static int sirf_soc_inner_remove(struct platform_device *pdev)
+{
+	struct sirf_soc_inner_audio *sinner_audio = platform_get_drvdata(pdev);
+
+	clk_disable_unprepare(sinner_audio->clk);
+	snd_soc_unregister_codec(&(pdev->dev));
+	snd_soc_unregister_component(&pdev->dev);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM
+static int sirf_soc_inner_suspend(struct platform_device *pdev,
+		pm_message_t msg)
+{
+	struct sirf_soc_inner_audio *sinner_audio = platform_get_drvdata(pdev);
+
+	clk_disable_unprepare(sinner_audio->clk);
+	return 0;
+}
+
+static int sirf_soc_inner_resume(struct platform_device *pdev)
+{
+	struct sirf_soc_inner_audio *sinner_audio = platform_get_drvdata(pdev);
+
+	clk_prepare_enable(sinner_audio->clk);
+
+	writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1)
+		| (1 << sinner_audio->reg_bits->codec_clk_en_bits)),
+		sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+	writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1)
+		| (1 << sinner_audio->reg_bits->adc14b_12_bits)),
+		sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
+	writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) | IC_CPFREQ,
+		sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+	writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) | IC_CPEN,
+		sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
+	return 0;
+}
+#else
+#define sirf_soc_inner_suspend NULL
+#define sirf_soc_inner_resume NULL
+#endif
+
+static struct platform_driver sirf_soc_inner_driver = {
+	.driver = {
+		.name = "sirf-soc-inner",
+		.owner = THIS_MODULE,
+		.of_match_table = sirf_soc_inner_of_match,
+	},
+	.probe = sirf_soc_inner_probe,
+	.remove = sirf_soc_inner_remove,
+	.suspend = sirf_soc_inner_suspend,
+	.resume = sirf_soc_inner_resume,
+};
+
+module_platform_driver(sirf_soc_inner_driver);
+
+MODULE_DESCRIPTION("SiRF SoC inner bus and codec driver");
+MODULE_AUTHOR("RongJun Ying <Rongjun.Ying at csr.com>");
+MODULE_LICENSE("GPL v2");
-- 
1.8.2.3



From 21cnbao at gmail.com  Fri Jul 19 07:07:21 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Fri, 19 Jul 2013 19:07:21 +0800
Subject: [PATCH 5/6] ASoC: sirf-inner: add mach driver for SiRFSoC internal
 codec
In-Reply-To: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <1374232042-26088-6-git-send-email-Baohua.Song@csr.com>

From: Rongjun Ying <Rongjun.Ying at csr.com>

This connects DMA, CPU DAI and Codec DAI together and works
as a mach driver.

Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 sound/soc/sirf/Kconfig      |   7 +-
 sound/soc/sirf/Makefile     |   2 +
 sound/soc/sirf/sirf-inner.c | 267 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 275 insertions(+), 1 deletion(-)
 create mode 100644 sound/soc/sirf/sirf-inner.c

diff --git a/sound/soc/sirf/Kconfig b/sound/soc/sirf/Kconfig
index 60b8857..ce3c025 100644
--- a/sound/soc/sirf/Kconfig
+++ b/sound/soc/sirf/Kconfig
@@ -2,7 +2,7 @@ config SND_SIRF_SOC
 	tristate "Platform DMA driver for the SiRF SoC chips"
 	depends on ARCH_SIRF && SND_SOC
 	select SND_SOC_DMAENGINE_PCM
-
+	
 config SND_SOC_SIRF_I2S
 	tristate
 
@@ -11,3 +11,8 @@ config SND_SIRF_SOC_INNER
 
 config SND_SOC_SIRF_USP
 	tristate
+
+config SND_SIRF_INNER
+	tristate "SoC Audio support for SiRF inner codec of SiRF EVB"
+	depends on SND_SIRF_SOC
+	select SND_SIRF_SOC_INNER
diff --git a/sound/soc/sirf/Makefile b/sound/soc/sirf/Makefile
index 8517c67..80abdf6 100644
--- a/sound/soc/sirf/Makefile
+++ b/sound/soc/sirf/Makefile
@@ -1,9 +1,11 @@
 snd-soc-sirf-objs := sirf-pcm.o
+snd-soc-sirf-inner-objs := sirf-inner.o
 snd-soc-sirf-soc-inner-objs := sirf-soc-inner.o
 snd-soc-sirf-i2s-objs := sirf-i2s.o
 snd-soc-sirf-usp-objs := sirf-usp.o
 
 obj-$(CONFIG_SND_SIRF_SOC) += snd-soc-sirf.o
+obj-$(CONFIG_SND_SIRF_INNER) += snd-soc-sirf-inner.o
 obj-$(CONFIG_SND_SIRF_SOC_INNER) += snd-soc-sirf-soc-inner.o
 obj-$(CONFIG_SND_SOC_SIRF_I2S) += snd-soc-sirf-i2s.o
 obj-$(CONFIG_SND_SOC_SIRF_USP) += snd-soc-sirf-usp.o
diff --git a/sound/soc/sirf/sirf-inner.c b/sound/soc/sirf/sirf-inner.c
new file mode 100644
index 0000000..a8f2765
--- /dev/null
+++ b/sound/soc/sirf/sirf-inner.c
@@ -0,0 +1,267 @@
+/*
+ * SiRF inner audio device driver
+ *
+ * Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group company.
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+
+#include <sound/core.h>
+#include <sound/pcm.h>
+#include <sound/soc.h>
+#include <sound/jack.h>
+
+struct sirf_inner_card {
+	unsigned int            gpio_hp_pa;
+	unsigned int            gpio_spk_pa;
+	/*
+	 * Android platform uses switch gpio instead of jack.
+	 */
+#ifndef CONFIG_ANDROID
+	unsigned int            gpio_hp_detect;
+	struct snd_soc_jack     hp_jack;
+#endif
+};
+
+#ifndef CONFIG_ANDROID
+static int sirf_inner_jack_status_check(void);
+
+static struct snd_soc_jack_gpio hp_jack_gpios[] = {
+	{
+		.name = "hpdet-gpio",
+		.report = SND_JACK_HEADPHONE,
+		.debounce_time = 200,
+		.jack_status_check = sirf_inner_jack_status_check,
+	},
+};
+
+static int sirf_inner_jack_status_check(void)
+{
+	int spk_out = 0;
+	struct snd_soc_codec *codec = hp_jack_gpios[0].jack->codec;
+	struct snd_soc_card *card = codec->card;
+	struct sirf_inner_card *sinner_card = snd_soc_card_get_drvdata(card);
+	int hp_report = 0;
+
+	if (gpio_is_valid(sinner_card->gpio_hp_detect))
+		spk_out = gpio_get_value(sinner_card->gpio_hp_detect);
+
+	if (gpio_is_valid(sinner_card->gpio_hp_pa))
+		gpio_direction_output(sinner_card->gpio_hp_pa, !spk_out);
+
+	if (gpio_is_valid(sinner_card->gpio_spk_pa))
+		gpio_direction_output(sinner_card->gpio_spk_pa, spk_out);
+
+	if (!spk_out)
+		hp_report |= SND_JACK_HEADPHONE;
+
+	return hp_report;
+}
+
+static int sirf_inner_init(struct snd_soc_pcm_runtime *rtd)
+{
+	struct snd_soc_codec *codec = rtd->codec;
+	struct snd_soc_card *card = codec->card;
+	struct sirf_inner_card *sinner_card = snd_soc_card_get_drvdata(card);
+	int ret;
+	hp_jack_gpios[0].gpio = sinner_card->gpio_hp_detect;
+	ret = snd_soc_jack_new(codec, "Headphone Jack", SND_JACK_HEADPHONE,
+			&sinner_card->hp_jack);
+	if (ret)
+		return ret;
+	return snd_soc_jack_add_gpios(&sinner_card->hp_jack,
+			ARRAY_SIZE(hp_jack_gpios),
+			hp_jack_gpios);
+}
+#endif
+
+/* Digital audio interface glue - connects codec <--> CPU */
+static struct snd_soc_dai_link sirf_inner_dai_links[] = {
+	{
+		.name = "SiRF inner",
+		.stream_name = "SiRF inner",
+		.codec_dai_name = "sirf-soc-inner",
+#ifndef CONFIG_ANDROID
+		.init = sirf_inner_init,
+#endif
+	},
+};
+
+static int sirf_inner_headphone_out_get(struct snd_kcontrol *kcontrol,
+		struct snd_ctl_elem_value *ucontrol)
+{
+	int hp_out = 0;
+	struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct snd_soc_card *card = codec->card;
+	struct sirf_inner_card *sinner_card = snd_soc_card_get_drvdata(card);
+
+	if (gpio_is_valid(sinner_card->gpio_hp_pa))
+		hp_out = gpio_get_value(sinner_card->gpio_hp_pa);
+
+	*ucontrol->value.integer.value = hp_out;
+	return 0;
+}
+
+static int sirf_inner_headphone_out_put(struct snd_kcontrol *kcontrol,
+		struct snd_ctl_elem_value *ucontrol)
+{
+	int is_hp_out = ucontrol->value.integer.value[0];
+	struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct snd_soc_card *card = codec->card;
+	struct sirf_inner_card *sinner_card = snd_soc_card_get_drvdata(card);
+
+	if (gpio_is_valid(sinner_card->gpio_hp_pa))
+		gpio_direction_output(sinner_card->gpio_hp_pa, is_hp_out);
+
+	return 0;
+}
+
+static int sirf_inner_speaker_out_get(struct snd_kcontrol *kcontrol,
+		struct snd_ctl_elem_value *ucontrol)
+{
+	int spk_out = 0;
+	struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct snd_soc_card *card = codec->card;
+	struct sirf_inner_card *sinner_card = snd_soc_card_get_drvdata(card);
+
+	if (gpio_is_valid(sinner_card->gpio_spk_pa))
+		spk_out = gpio_get_value(sinner_card->gpio_spk_pa);
+
+	*ucontrol->value.integer.value = spk_out;
+	return 0;
+}
+
+static int sirf_inner_speaker_out_put(struct snd_kcontrol *kcontrol,
+		struct snd_ctl_elem_value *ucontrol)
+{
+	int is_spk_out = ucontrol->value.integer.value[0];
+	struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct snd_soc_card *card = codec->card;
+	struct sirf_inner_card *sinner_card = snd_soc_card_get_drvdata(card);
+
+	if (gpio_is_valid(sinner_card->gpio_spk_pa))
+		gpio_direction_output(sinner_card->gpio_spk_pa, is_spk_out);
+	return 0;
+}
+
+static int sirf_inner_speaker_out_info(struct snd_kcontrol *kcontrol,
+		struct snd_ctl_elem_info *uinfo)
+{
+	return 0;
+}
+
+static int sirf_inner_headphone_out_info(struct snd_kcontrol *kcontrol,
+		struct snd_ctl_elem_info *uinfo)
+{
+	return 0;
+}
+
+static struct snd_kcontrol_new snd_sirf_inner_out_route_controls[] = {
+	{
+		.iface          =       SNDRV_CTL_ELEM_IFACE_MIXER,
+		.name           =       "Speaker Out",
+		.index          =       0,
+		.access         =       SNDRV_CTL_ELEM_ACCESS_READWRITE,
+		.info           =	sirf_inner_speaker_out_info,
+		.get            =       sirf_inner_speaker_out_get,
+		.put            =       sirf_inner_speaker_out_put,
+	}, {
+		.iface          =       SNDRV_CTL_ELEM_IFACE_MIXER,
+		.name           =       "Headphone Out",
+		.index          =       0,
+		.access         =       SNDRV_CTL_ELEM_ACCESS_READWRITE,
+		.info           =	sirf_inner_headphone_out_info,
+		.get            =       sirf_inner_headphone_out_get,
+		.put            =       sirf_inner_headphone_out_put,
+	},
+};
+
+/* Audio machine driver */
+static struct snd_soc_card snd_soc_sirf_inner_card = {
+	.name = "SiRF inner",
+	.owner = THIS_MODULE,
+	.dai_link = sirf_inner_dai_links,
+	.num_links = ARRAY_SIZE(sirf_inner_dai_links),
+	.controls = snd_sirf_inner_out_route_controls,
+	.num_controls = ARRAY_SIZE(snd_sirf_inner_out_route_controls),
+};
+
+static int sirf_inner_probe(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = &snd_soc_sirf_inner_card;
+	struct sirf_inner_card *sinner_card;
+	sinner_card = devm_kzalloc(&pdev->dev, sizeof(struct sirf_inner_card),
+			GFP_KERNEL);
+	if (sinner_card == NULL)
+		return -ENOMEM;
+
+	sirf_inner_dai_links[0].platform_of_node =
+		of_find_compatible_node(NULL, NULL, "sirf,pcm-audio");
+	sirf_inner_dai_links[0].cpu_of_node =
+		of_parse_phandle(pdev->dev.of_node, "sirf,inner-platform", 0);
+	sirf_inner_dai_links[0].codec_of_node =
+		of_parse_phandle(pdev->dev.of_node, "sirf,inner-codec", 0);
+	sinner_card->gpio_spk_pa = of_get_named_gpio(pdev->dev.of_node,
+			"spk-pa-gpios", 0);
+	sinner_card->gpio_hp_pa =  of_get_named_gpio(pdev->dev.of_node,
+			"hp-pa-gpios", 0);
+#ifndef CONFIG_ANDROID
+	sinner_card->gpio_hp_detect = of_get_named_gpio(pdev->dev.of_node,
+			"hp-switch-gpios", 0);
+#endif
+	if (gpio_is_valid(sinner_card->gpio_spk_pa))
+		gpio_request(sinner_card->gpio_spk_pa, "SPA_PA_SD");
+	if (gpio_is_valid(sinner_card->gpio_hp_pa))
+		gpio_request(sinner_card->gpio_hp_pa, "HP_PA_SD");
+
+	card->dev = &pdev->dev;
+	snd_soc_card_set_drvdata(card, sinner_card);
+	platform_set_drvdata(pdev, card);
+	if (gpio_is_valid(sinner_card->gpio_hp_pa))
+		gpio_direction_output(sinner_card->gpio_hp_pa, 0);
+	if (gpio_is_valid(sinner_card->gpio_spk_pa))
+		gpio_direction_output(sinner_card->gpio_spk_pa, 0);
+
+	return snd_soc_register_card(card);
+}
+
+static int sirf_inner_remove(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = platform_get_drvdata(pdev);
+	struct sirf_inner_card *sinner_card = snd_soc_card_get_drvdata(card);
+
+	if (gpio_is_valid(sinner_card->gpio_hp_pa))
+		gpio_free(sinner_card->gpio_hp_pa);
+	if (gpio_is_valid(sinner_card->gpio_spk_pa))
+		gpio_free(sinner_card->gpio_spk_pa);
+
+	snd_soc_unregister_card(card);
+	return 0;
+}
+
+static const struct of_device_id sirf_inner_of_match[] = {
+	{.compatible = "sirf,sirf-inner-audio", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, sirf_inner_of_match);
+
+static struct platform_driver sirf_inner_driver = {
+	.driver = {
+		.name = "sirf-inner-audio",
+		.owner = THIS_MODULE,
+		.of_match_table = sirf_inner_of_match,
+	},
+	.probe = sirf_inner_probe,
+	.remove = sirf_inner_remove,
+};
+module_platform_driver(sirf_inner_driver);
+
+MODULE_AUTHOR("RongJun Ying <RongJun.Ying at csr.com>");
+MODULE_DESCRIPTION("ALSA SoC SIRF inner AUDIO driver");
+MODULE_LICENSE("GPL v2");
-- 
1.8.2.3



From hanjun.guo at linaro.org  Fri Jul 19 07:09:57 2013
From: hanjun.guo at linaro.org (Hanjun Guo)
Date: Fri, 19 Jul 2013 19:09:57 +0800
Subject: [RFC PATCH 0/5] arm64: initial CPU_HOTPLUG support
In-Reply-To: <20130711163458.GA8303@kartoffel>
References: <1373494279-24712-1-git-send-email-mark.rutland@arm.com>
 <51DECAFB.4010800@linaro.org> <20130711163458.GA8303@kartoffel>
Message-ID: <CAGHbJ3ADJ3tKR2DiL8XNh8wZqY1k0OFeOSAHa61ALvUyicmg9g@mail.gmail.com>

On 2013-7-12 0:34, Mark Rutland wrote:
> On Thu, Jul 11, 2013 at 04:10:51PM +0100, Hanjun Guo wrote:
>> Hi Mark,
>
> Hi Hanjun,
>
>>
>> I tested this patch set on the armv8 foundation model, it's panic.
>>
>> I seems that we need to do something more, I'll also checkout
>> what's going on here.
>>
>> Thanks
>> Hanjun
>>
>> dump formation:
>> root at genericarmv8:/sys/devices/system/cpu/cpu3# echo 0 > online
>> CPU3: Booted secondary processor
>> CPU3: shutdown
>> BUG: failure at kernel/time/clockevents.c:284/clockevents_register_device()!
>> Kernel panic - not syncing: BUG!
>> CPU: 3 PID: 0 Comm: swapper/3 Not tainted 3.10.0+ #2
>> Call trace:
>> [<ffffffc0000873e0>] dump_backtrace+0x0/0x12c
>> [<ffffffc000087520>] show_stack+0x14/0x1c
>> [<ffffffc0003f2e7c>] dump_stack+0x20/0x28
>> [<ffffffc0003efd24>] panic+0xe8/0x214
>> [<ffffffc0000d049c>] clockevents_set_mode+0x0/0x6c
>> [<ffffffc0000d074c>] clockevents_config_and_register+0x24/0x30
>> [<ffffffc0003ef840>] arch_timer_setup+0xd8/0x140
>> [<ffffffc0003ef8f0>] arch_timer_cpu_notify+0x48/0xc8
>> [<ffffffc0000b83e4>] notifier_call_chain+0x48/0x88
>> [<ffffffc0000b8500>] __raw_notifier_call_chain+0xc/0x14
>> [<ffffffc0000973f0>] __cpu_notify+0x30/0x58
>> [<ffffffc00009742c>] cpu_notify+0x14/0x1c
>> [<ffffffc0003ed46c>] notify_cpu_starting+0x14/0x1c
>> [<ffffffc0003ece74>] secondary_start_kernel+0xc0/0xf4
>
> That looks suspicious. It looks like the CPU didn't actually die and jumped
> immediately to secondary_start_kernel. At a guess, did you update your dts with
> a psci node and cpu enable-methods?
>
> I can see the code's broken if you try hotplug with spin-table, because
> cpu_disable and cpu_die are both NULL, and the sanity checking doesn't attempt
> to deal with this case, so the cpu will end up getting into cpu_die, won't call
> anything, and jump straight back into the kernel. I'll fix up the
> op_cpu_disable checks to cover this.
>
> The other possibility is that you're using PSCI but your function id for
> cpu_off is wrong, and thus the psci cpu_off call fails. Did you update your dts
> for PSCI? Below is a patch to do so.

Hi Mark,

Sorry for the late reply.

I updated the boot wrapper and applied the dts patch you provided, and then
I test the cpu online/offline, it works fine on the armv8 foundation model.
It also works fine combined with my ACPI CPU hot-plug driver, I can eject
(hot remove) a CPU now :)

Thanks
Hanjun


From 21cnbao at gmail.com  Fri Jul 19 07:07:22 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Fri, 19 Jul 2013 19:07:22 +0800
Subject: [PATCH 6/6] arm: prima2: defconfig: enable sound components
In-Reply-To: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <1374232042-26088-7-git-send-email-Baohua.Song@csr.com>

Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 arch/arm/configs/prima2_defconfig | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/configs/prima2_defconfig b/arch/arm/configs/prima2_defconfig
index 002a1ce..07a87c8 100644
--- a/arch/arm/configs/prima2_defconfig
+++ b/arch/arm/configs/prima2_defconfig
@@ -1,4 +1,3 @@
-CONFIG_EXPERIMENTAL=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_RELAY=y
@@ -39,6 +38,11 @@ CONFIG_SPI=y
 CONFIG_SPI_SIRF=y
 CONFIG_SPI_SPIDEV=y
 # CONFIG_HWMON is not set
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_SOC=y
+CONFIG_SND_SIRF_SOC=y
+CONFIG_SND_SIRF_INNER=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_MASS_STORAGE=m
 CONFIG_MMC=y
@@ -59,12 +63,12 @@ CONFIG_ROMFS_FS=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ASCII=y
 CONFIG_NLS_ISO8859_1=y
-CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_INFO=y
 CONFIG_DEBUG_SECTION_MISMATCH=y
+CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_KERNEL=y
 # CONFIG_DEBUG_PREEMPT is not set
 CONFIG_DEBUG_RT_MUTEXES=y
 CONFIG_DEBUG_SPINLOCK=y
 CONFIG_DEBUG_MUTEXES=y
-CONFIG_DEBUG_INFO=y
 CONFIG_CRC_CCITT=y
-- 
1.8.2.3



From linux at arm.linux.org.uk  Fri Jul 19 07:09:47 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Jul 2013 12:09:47 +0100
Subject: alignment handler instruction endian-ness
In-Reply-To: <51E91BE5.8070809@codethink.co.uk>
References: <51E91BE5.8070809@codethink.co.uk>
Message-ID: <20130719110947.GD24642@n2100.arm.linux.org.uk>

On Fri, Jul 19, 2013 at 11:58:45AM +0100, Ben Dooks wrote:
> I ran in to an issue with the alignment handler when running BE8 where
> it loads instructions and fails to swap.
>
> Is there a better way of swapping instructions for ARM when loading
> from arbitrary places? Have I missed any other places this could happen?

Maybe we need a macro which deals with this automatically?

	arm_instr_to_cpu(x)
	thumb_instr_to_cpu(x)

These should probably make use of the swab*() macros when an endian swap
is needed.

> The following patch is my first attempt at solving the problem for the
> alignment handler:

I'd suggest checking this with sparse too - you have some type errors here.


From jonas.jensen at gmail.com  Fri Jul 19 07:12:59 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Fri, 19 Jul 2013 13:12:59 +0200
Subject: [PATCH] ARM: clocksource: moxart: documentation: update device tree
 bindings document
In-Reply-To: <1374048297-4321-1-git-send-email-jonas.jensen@gmail.com>
References: <1374048297-4321-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1374232379-20900-1-git-send-email-jonas.jensen@gmail.com>

Update device tree bindings document with the correct clock name.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Hi Daniel,
    
    I apologize in advance if this causes trouble..
    
    One of the device tree bindings files you merged
    git://git.linaro.org/people/dlezcano/clockevents.git timers/clockevents-next
    now needs an update.
    
    This patch can be applied directly to timers/clockevents-next.
    
    Best regards,
    Jonas

 Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt b/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt
index 77c4cfa..ad0bf7f 100644
--- a/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt
+++ b/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt
@@ -5,7 +5,7 @@ Required properties:
 - compatible : Should be "moxa,moxart-timer"
 - reg : Should contain registers location and length
 - interrupts : Should contain the timer interrupt number
-- clocks : Should contain phandle for APB clock "clkapb"
+- clocks : Should contain phandle for the MOXA ART core clock "coreclk"
 
 Example:
 
@@ -13,5 +13,5 @@ Example:
 		compatible = "moxa,moxart-timer";
 		reg = <0x98400000 0x42>;
 		interrupts = <19 1>;
-		clocks = <&clkapb>;
+		clocks = <&coreclk>;
 	};
-- 
1.8.2.1



From sergei.shtylyov at cogentembedded.com  Fri Jul 19 07:17:39 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 19 Jul 2013 15:17:39 +0400
Subject: [PATCH 1/3] ARM: shmobile: use common platform header for HPB-DMAC
In-Reply-To: <87txjrbe11.wl%kuninori.morimoto.gx@renesas.com>
References: <201306300243.57180.sergei.shtylyov@cogentembedded.com>
 <201306300245.58486.sergei.shtylyov@cogentembedded.com>
 <CANqRtoTCaJfbECSpX7nMZoV8SPeQqs-xrJQ0-+-smA+bx3QG=w@mail.gmail.com>
 <51E865FA.9000706@cogentembedded.com>
 <87txjrbe11.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <51E92053.5080103@cogentembedded.com>

Hello.

On 19-07-2013 4:16, Kuninori Morimoto wrote:

>>>> From: Max Filippov <max.filippov at cogentembedded.com>

>>>> Use previously empty <mach/dma.h> to declare HPB-DMA slave IDs.

>>>> Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
>>>> [Sergei: changed the guard macro name, fixed comment, extended copyright.]
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

>>>> ---
>>>>    arch/arm/mach-shmobile/include/mach/dma.h |   25 ++++++++++++++++++++++++-
>>>>    1 file changed, 24 insertions(+), 1 deletion(-)

>>> Thanks for your patch. Can you please explain the reason why you put
>>> this shared information under mach/?

>>      I'm afraid that's more a question to the original author, Phil Edworthy.
>> He put this stuff into <mach/hpb-dmae.h>.

> Then, why you could send this patch instead of original author,

    Ask Phil why didn't he upstream his stuff. We, unlike him, do have 
obligation to upstream it.

> even though you can't answer any question about it ?

    I'm not the author of the patch, let me remind you, Max Filippov is.
He was on vacations.

> Best regards
> ---
> Kuninori Morimoto

WBR, Sergei



From ben.dooks at codethink.co.uk  Fri Jul 19 07:26:24 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Fri, 19 Jul 2013 12:26:24 +0100
Subject: alignment handler instruction endian-ness
In-Reply-To: <20130719110947.GD24642@n2100.arm.linux.org.uk>
References: <51E91BE5.8070809@codethink.co.uk>
 <20130719110947.GD24642@n2100.arm.linux.org.uk>
Message-ID: <51E92260.1060101@codethink.co.uk>

On 19/07/13 12:09, Russell King - ARM Linux wrote:
> On Fri, Jul 19, 2013 at 11:58:45AM +0100, Ben Dooks wrote:
>> I ran in to an issue with the alignment handler when running BE8 where
>> it loads instructions and fails to swap.
>>
>> Is there a better way of swapping instructions for ARM when loading
>> from arbitrary places? Have I missed any other places this could happen?
>
> Maybe we need a macro which deals with this automatically?
>
> 	arm_instr_to_cpu(x)
> 	thumb_instr_to_cpu(x)
>
> These should probably make use of the swab*() macros when an endian swap
> is needed.
>
>> The following patch is my first attempt at solving the problem for the
>> alignment handler:
>
> I'd suggest checking this with sparse too - you have some type errors here.

Very probably, I needed this in a hurry and was after some input on how
it could be improved.

The only issue I was thinking of for having those functions would be if
the userspace was running BE32 and the kernel was LE. I don't think this
is very likely, so it can probably be discounted.

I could not find where the kernel's relocation code does this to see if
it also needed changing.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From laurent.pinchart at ideasonboard.com  Fri Jul 19 07:29:13 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 19 Jul 2013 13:29:13 +0200
Subject: [PATCH v2 0/4] Add PWM polarity flag macro for DT
In-Reply-To: <51E81E1C.20708@wwwdotorg.org>
References: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <51E81E1C.20708@wwwdotorg.org>
Message-ID: <10033310.z2U2FSCElN@avalon>

Hi Stephen,

On Thursday 18 July 2013 10:55:56 Stephen Warren wrote:
> On 07/17/2013 04:54 PM, Laurent Pinchart wrote:
> > Hello,
> > 
> > Here's a small patch set that replaces PWM polarity numerical constants
> > with macros in DT.
> 
> The series,
> Reviewed-by: Stephen Warren <swarren at nvidia.com>
> 
> I'm (very very) slightly hesitant about patch 3/4, since it's moving towards
> all PWMs having to use the same specifier format, whereas specifiers are at
> least potentially binding-specific, not device-type-specific. However,
> consistency is good; there's no need to do something different just for the
> heck of it. Equally, there's nothing actually stopping a new binding from
> defining its own format rather than simply deferring to pwm.txt if it
> absolutely has to, so I think this will turn out fine.

Exactly, that's why I don't think it's an issue. pwm.txt defines a common 
format, individual bindings are free to use it or not.

Thierry, if you're fine with the patches, could you take them in your tree 
with Stephen's Reviewed-by, or should I report them and send you a pull 
request ?

-- 
Regards,

Laurent Pinchart



From sergei.shtylyov at cogentembedded.com  Fri Jul 19 07:32:38 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 19 Jul 2013 15:32:38 +0400
Subject: [PATCH 1/3] ARM: shmobile: use common platform header for HPB-DMAC
In-Reply-To: <51E92053.5080103@cogentembedded.com>
References: <201306300243.57180.sergei.shtylyov@cogentembedded.com>
 <201306300245.58486.sergei.shtylyov@cogentembedded.com>
 <CANqRtoTCaJfbECSpX7nMZoV8SPeQqs-xrJQ0-+-smA+bx3QG=w@mail.gmail.com>
 <51E865FA.9000706@cogentembedded.com>
 <87txjrbe11.wl%kuninori.morimoto.gx@renesas.com>
 <51E92053.5080103@cogentembedded.com>
Message-ID: <51E923D6.5050502@cogentembedded.com>

Hello.

On 19-07-2013 15:17, Sergei Shtylyov wrote:

>>>>> From: Max Filippov <max.filippov at cogentembedded.com>

>>>>> Use previously empty <mach/dma.h> to declare HPB-DMA slave IDs.

>>>>> Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
>>>>> [Sergei: changed the guard macro name, fixed comment, extended copyright.]
>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

>>>>> ---
>>>>>    arch/arm/mach-shmobile/include/mach/dma.h |   25
>>>>> ++++++++++++++++++++++++-
>>>>>    1 file changed, 24 insertions(+), 1 deletion(-)

>>>> Thanks for your patch. Can you please explain the reason why you put
>>>> this shared information under mach/?

    IIUC, because the only 2 file using it were under arch/arm/mach-shmobile/.

>>>      I'm afraid that's more a question to the original author, Phil Edworthy.
>>> He put this stuff into <mach/hpb-dmae.h>.

>> Then, why you could send this patch instead of original author,

>     Ask Phil why didn't he upstream his stuff. We, unlike him, do have
> obligation to upstream it.

>> even though you can't answer any question about it ?

>     I'm not the author of the patch, let me remind you, Max Filippov is.
> He was on vacations.

    Phil's patches were only for R8A7778, IIRC (yet, the platfrom DMA code was 
placed in a separate file, not r8a7778.c). Max decided to use the 
<mach/hpb-dmae.h> header for sharing the DMA channel IDs between R8A777[89], I 
agreed but suggested to use the empty <mach/dma.h> instead.

>> Best regards
>> ---
>> Kuninori Morimoto

WBR, Sergei



From julien.grall at linaro.org  Fri Jul 19 07:27:00 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Fri, 19 Jul 2013 12:27:00 +0100
Subject: [PATCH v2] xen/arm: disable cpuidle and cpufreq when linux is running
 as dom0
Message-ID: <1374233220-13770-1-git-send-email-julien.grall@linaro.org>

When linux is running as dom0, Xen doesn't show the physical cpu but a
virtual CPU.
On some ARM SOC (for instance the exynos 5250), linux registers callbacks
for cpuidle and cpufreq. When these callbacks are called, they will modify
directly the physical cpu not the virtual one. It can impact the whole board
instead of only dom0.

Signed-off-by: Julien Grall <julien.grall at linaro.org>

---
    Changes in v2:
        - Disable cpufreq
---
 arch/arm/xen/enlighten.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 49839d8..af82792 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -24,6 +24,8 @@
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/of_address.h>
+#include <linux/cpuidle.h>
+#include <linux/cpufreq.h>
 
 #include <linux/mm.h>
 
@@ -292,6 +294,12 @@ static int __init xen_pm_init(void)
 {
 	pm_power_off = xen_power_off;
 	arm_pm_restart = xen_restart;
+	/*
+	 * Making sure board specific code will not set up ops for
+	 * cpu idle and cpu freq.
+	 */
+	disable_cpuidle();
+	disable_cpufreq();
 
 	return 0;
 }
-- 
1.7.10.4



From vijay.kilari at gmail.com  Fri Jul 19 07:38:55 2013
From: vijay.kilari at gmail.com (Vijay Kilari)
Date: Fri, 19 Jul 2013 17:08:55 +0530
Subject: alignment handler instruction endian-ness (Ben Dooks)
Message-ID: <CALicx6tS2B_itZHdFh2YrQ2VZOoacx-MuO5vkNfqypH9v5rEiQ@mail.gmail.com>

On Fri, Jul 19, 2013 at 5:06 PM, Vijay Kilari <vijay.kilari at gmail.com> wrote:
>> Message: 4
>> Date: Fri, 19 Jul 2013 11:58:45 +0100
>> From: Ben Dooks <ben.dooks at codethink.co.uk>
>> To: "linux-arm-kernel at lists.infradead.org"
>>         <linux-arm-kernel at lists.infradead.org>
>> Subject: alignment handler instruction endian-ness
>> Message-ID: <51E91BE5.8070809 at codethink.co.uk>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> I ran in to an issue with the alignment handler when running BE8 where
>> it loads instructions and fails to swap.
>>
>> Is there a better way of swapping instructions for ARM when loading
>> from arbitrary places? Have I missed any other places this could happen?
>>
>> The following patch is my first attempt at solving the problem for the
>> alignment handler:
>>
>>> Author: Ben Dooks <ben.dooks at codethink.co.uk>
>>> Date:   Thu Jul 18 21:10:56 2013 +0100
>>>
>>>     arm: alignment: deal with be8 mode when decoding instructions
>>>
>>>     If we are in BE8 mode, we must deal with the instruction stream being
>>>     in LE order when data is being loaded in BE order. Ensure the data is
>>>     swapped before processing to avoid thre following:
>>>
>>>     Alignment trap: not handling instruction 030091e8 at [<80333e8c>]
>>>     Unhandled fault: alignment exception (0x001) at 0xbfa09567
>>>
>>>     Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
>>  >
>>> diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
>>> index db26e2e..e8793a7 100644
>>> --- a/arch/arm/mm/alignment.c
>>> +++ b/arch/arm/mm/alignment.c
>>> @@ -87,6 +87,12 @@ core_param(alignment, ai_usermode, int, 0600);
>>>  #define UM_FIXUP       (1 << 1)
>>>  #define UM_SIGNAL      (1 << 2)
>>>
>>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>>> +#define need_swap()    true
>>> +#else
>>> +#define need_swap()    false
>>> +#endif
>>> +
>>>  /* Return true if and only if the ARMv6 unaligned access model is in use. */
>>>  static bool cpu_is_v6_unaligned(void)
>>>  {
>>> @@ -762,12 +768,16 @@ do_alignment(unsigned long addr, unsigned int fsr, struct
>>>         if (thumb_mode(regs)) {
>>>                 u16 *ptr = (u16 *)(instrptr & ~1);
>>>                 fault = probe_kernel_address(ptr, tinstr);
>>> +               if (need_swap())
>>> +                       tinstr = cpu_to_le16(tinstr);
>>>                 if (!fault) {
>>>                         if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
>>>                             IS_T32(tinstr)) {
>>>                                 /* Thumb-2 32-bit */
>>>                                 u16 tinst2 = 0;
>>>                                 fault = probe_kernel_address(ptr + 1, tinst2);
>>> +                               if (need_swap())
>>> +                                       tinst2 = cpu_to_le16(tinst2);
>>>                                 instr = (tinstr << 16) | tinst2;
>>>                                 thumb2_32b = 1;
>>>                         } else {
>>> @@ -775,8 +785,11 @@ do_alignment(unsigned long addr, unsigned int fsr, struct p
>>>                                 instr = thumb2arm(tinstr);
>>>                         }
>>>                 }
>>> -       } else
>>> +       } else {
>>>                 fault = probe_kernel_address(instrptr, instr);
>>> +               if (need_swap())
>>> +                       instr = cpu_to_le32(instr);
>>> +       }
>>>
>>>         if (fault) {
>>>                 type = TYPE_FAULT;
>>
>>
>
 I think some changes are required in arch/arm/kernel/traps.c
 for handling undefined instruction as well
>
>> --
>> Ben Dooks                               http://www.codethink.co.uk/
>> Senior Engineer                         Codethink - Providing Genius
>>
>>


From pullip.cho at samsung.com  Fri Jul 19 08:01:51 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 19 Jul 2013 21:01:51 +0900
Subject: [PATCH v7 00/12] iommu/exynos: Fixes and Enhancements of System
 MMU driver with DT
In-Reply-To: <CAG8rG2y8ZN4ahv7DqJ11=FhJpVVxcbAbTaViyi-D4GH=p3xg=A@mail.gmail.com>
References: <002801ce797b$3d2fbc80$b78f3580$@samsung.com>
 <CAG8rG2y8ZN4ahv7DqJ11=FhJpVVxcbAbTaViyi-D4GH=p3xg=A@mail.gmail.com>
Message-ID: <004301ce8477$c1172fe0$43458fa0$@samsung.com>

> -----Original Message-----
> From: Antonios Motakis [mailto:a.motakis at virtualopensystems.com]
> Sent: Friday, July 19, 2013 1:25 AM
> 
> Hello Cho,
> 
> I have been trying out the Exynos System MMU driver including your
> fixes, however I notice that if you try to get the iommu_group of a
> device (i.e. iommu_group_get(&pdev->dev)) this will not work. Since
> each device is behind its own System MMU I would expect a distinct
> iommu_group for that device, instead I get NULL (I tried this with the
> MFC).
> 
> Indeed, it looks like this is not currently implemented in the driver.
> Is this something that is on the roadmap?
> 

I have not implemented anything about iommu_group
since a System MMU is dedicated to a single master device.
I also did not find any reason to implement something about iommu_group.
I would like to know why you need to call iommu_group_get().
Do you need some information in user-space?

Thank you.

Cho KyongHo.

> Best regards,
> Antonios Motakis
> 
> On Fri, Jul 5, 2013 at 2:29 PM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> > The current exynos-iommu(System MMU) driver does not work autonomously
> > since it is lack of support for power management of peripheral blocks.
> > For example, MFC device driver must ensure that its System MMU is disabled
> > before MFC block is power-down not to invalidate IOTLB in the System MMU
> > when I/O memory mapping is changed. Because A System MMU is resides in the
> > same H/W block, access to control registers of System MMU while the H/W
> > block is turned off must be prohibited.
> >
> > This set of changes solves the above problem with setting each System MMUs
> > as the parent of the device which owns the System MMU to recieve the
> > information when the device is turned off or turned on.
> >
> > Another big change to the driver is the support for devicetree.
> > The bindings for System MMU is described in
> > Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
> >
> > In addition, this patchset also includes several bug fixes and enhancements
> > of the current driver.
> >
> > Change log:
> > v7:
> > - Rebased on the stable 3.10
> > - Registered PM domains and gate clocks with DT
> > - Changed connection method between a System MMU and its master H/W
> >    'mmu-master' property in the node of System MMU
> >    --> 'iommu' property in the node of master H/W
> > - Marking device descriptor of master H/W of a System MMU with bus notifier.
> > - Power management (PM_RUNTIME, PM_SLEEP) of System MMUs with gpd_dev_ops
> >    of Generic IO Powerdomain. gpd_dev_ops are set to the master H/Ws
> >    before they are probed in the bus notifier.
> > - Removed additional debugging features like debugfs entries and
> >    version names.
> > - Removed support for advanced features of System MMU 3.2 and 3.3
> >    the current IOMMU API cannot handle the feature
> >   (A kind of L2 TLB that fetches several consequence page table entries.
> >    It must be initialized by the driver of master H/W whenever it works.)
> >
> > v6:
> > - Rebased on the branch, next/iommu-exynos of
> >   git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> >
> > v5:
> > - new bugfix: patch 01
> > - Reordered patches
> >   * patch 01 ~ 05: Bugfix and enhancements of the existing driver
> >   * patch 06 ~ 10: Device Tree support and callbacks for power management
> >   * patch 11     : System MMU 3.2 and 3.3 support
> >   * patch 12 ~ 14: Debugging features
> > - Additional code compaction
> >
> > v4:
> > - Remove Change-Id from v3 patches
> > - Change the order of the third and the first patch
> >   Thanks to Kukjin Kim.
> > - Fix memory leak when allocating and assigning exynos_iommu_owner to client
> >   device if the client device has multiple System MMUs.
> >   Thanks to Rahul Sharma.
> >
> > v3:
> > - Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
> > - Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
> >   Thanks to Prathyush.
> >
> > v2:
> > - Split the patch to iommu/exynos into 9 patches
> > - Support for System MMU 3.3
> > - Some code compaction
> >
> > Patch summary:
> > [PATCH v7 1/9] iommu/exynos: do not include removed header
> > [PATCH v7 2/9] iommu/exynos: add missing cache flush for removed page table entries
> > [PATCH v7 3/9] iommu/exynos: fix page table maintenance
> > [PATCH v7 4/9] iommu/exynos: allocate lv2 page table from own slab
> > [PATCH v7 5/9] iommu/exynos: change rwlock to spinlock
> > [PATCH v7 6/9] clk: exynos5250: add gate clock descriptions of System MMU
> > [PATCH v7 7/9] ARM: dts: Add description of System MMU of Exynos SoCs
> > [PATCH v7 8/9] iommu/exynos: support for device tree
> > [PATCH v7 9/9] iommu/exynos: add bus notifier for registering System MMU
> >
> > Diffstats:
> > .../devicetree/bindings/clock/exynos5250-clock.txt |   28 +-
> > .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 ++
> > arch/arm/boot/dts/exynos4.dtsi                     |  122 +++
> > arch/arm/boot/dts/exynos4210.dtsi                  |   25 +
> > arch/arm/boot/dts/exynos4x12.dtsi                  |   76 ++
> > arch/arm/boot/dts/exynos5250.dtsi                  |  291 ++++++
> > drivers/clk/samsung/clk-exynos5250.c               |   57 +-
> > drivers/iommu/Kconfig                              |    5 +-
> > drivers/iommu/exynos-iommu.c                       | 1011 +++++++++++++-------
> > 9 files changed, 1382 insertions(+), 336 deletions(-)
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/



From ben.dooks at codethink.co.uk  Fri Jul 19 08:15:33 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Fri, 19 Jul 2013 13:15:33 +0100
Subject: alignment handler instruction endian-ness
In-Reply-To: <20130719110947.GD24642@n2100.arm.linux.org.uk>
References: <51E91BE5.8070809@codethink.co.uk>
 <20130719110947.GD24642@n2100.arm.linux.org.uk>
Message-ID: <51E92DE5.6090404@codethink.co.uk>

On 19/07/13 12:09, Russell King - ARM Linux wrote:
> On Fri, Jul 19, 2013 at 11:58:45AM +0100, Ben Dooks wrote:
>> I ran in to an issue with the alignment handler when running BE8 where
>> it loads instructions and fails to swap.
>>
>> Is there a better way of swapping instructions for ARM when loading
>> from arbitrary places? Have I missed any other places this could happen?
>
> Maybe we need a macro which deals with this automatically?
>
> 	arm_instr_to_cpu(x)
> 	thumb_instr_to_cpu(x)
>
> These should probably make use of the swab*() macros when an endian swap
> is needed.
>
>> The following patch is my first attempt at solving the problem for the
>> alignment handler:
>
> I'd suggest checking this with sparse too - you have some type errors here.

How about:

diff --git a/arch/arm/include/uapi/asm/byteorder.h 
b/arch/arm/include/uapi/asm/b
index 7737974..9e63a00 100644
--- a/arch/arm/include/uapi/asm/byteorder.h
+++ b/arch/arm/include/uapi/asm/byteorder.h
@@ -21,5 +21,13 @@
  #include <linux/byteorder/little_endian.h>
  #endif


+#ifdef CONFIG_CPU_ENDIAN_BE8
+#define cpu_to_arm_instr(__instr)      swab32(__instr)
+#define cpu_to_thum_instr(__instr)     swab16(__instr)
+#else
+#define cpu_to_arm_instr(__instr)      (__instr)
+#define cpu_to_thum_instr(__instr)     (__instr)
+#endif

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From daniel.lezcano at linaro.org  Fri Jul 19 08:16:48 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 19 Jul 2013 14:16:48 +0200
Subject: [PATCH] ARM: clocksource: moxart: documentation: update device
 tree bindings document
In-Reply-To: <1374232379-20900-1-git-send-email-jonas.jensen@gmail.com>
References: <1374048297-4321-1-git-send-email-jonas.jensen@gmail.com>
 <1374232379-20900-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <51E92E30.5090907@linaro.org>

On 07/19/2013 01:12 PM, Jonas Jensen wrote:
> Update device tree bindings document with the correct clock name.

Ok, pushed.


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From sergei.shtylyov at cogentembedded.com  Fri Jul 19 08:32:42 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 19 Jul 2013 16:32:42 +0400
Subject: [PATCH 01/19] ARM: shmobile: r8a73a4: Add pin control device
 to device tree
In-Reply-To: <c173e780f82e5dea3da21f9eda47bc48aa3f57b1.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
 <c173e780f82e5dea3da21f9eda47bc48aa3f57b1.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <51E931EA.6010805@cogentembedded.com>

Hello.

On 19-07-2013 8:36, Simon Horman wrote:

> From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

> Add a pfc node to the r8a73a4 device tree.

    This patch looks strange...

> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> ---
>   arch/arm/boot/dts/r8a73a4.dtsi |   88 ++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 88 insertions(+)

> diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
> index 4ff2019..f1a35d5 100644
> --- a/arch/arm/boot/dts/r8a73a4.dtsi
> +++ b/arch/arm/boot/dts/r8a73a4.dtsi
> @@ -85,4 +85,92 @@
>   		interrupt-parent = <&gic>;
>   		interrupts = <0 69 4>;
>   	};
> +
> +	i2c0: i2c at e6500000 {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		compatible = "renesas,rmobile-iic";
> +		reg = <0 0xe6500000 0 0x428>;
> +		interrupt-parent = <&gic>;
> +		interrupts = <0 174 0x4>;
> +	};
[...]
> +	i2c8: i2c at e6570000 {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		compatible = "renesas,rmobile-iic";
> +		reg = <0 0xe6570000 0 0x428>;
> +		interrupt-parent = <&gic>;
> +		interrupts = <0 173 0x4>;
> +	};
> +

    Hm, this also adds a bunch of I2C controllers which is not mentioned in 
the changelog at all.

WBR, Sergei



From linux at arm.linux.org.uk  Fri Jul 19 08:32:50 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Jul 2013 13:32:50 +0100
Subject: alignment handler instruction endian-ness
In-Reply-To: <51E92DE5.6090404@codethink.co.uk>
References: <51E91BE5.8070809@codethink.co.uk>
 <20130719110947.GD24642@n2100.arm.linux.org.uk>
 <51E92DE5.6090404@codethink.co.uk>
Message-ID: <20130719123249.GE24642@n2100.arm.linux.org.uk>

On Fri, Jul 19, 2013 at 01:15:33PM +0100, Ben Dooks wrote:
> On 19/07/13 12:09, Russell King - ARM Linux wrote:
>> On Fri, Jul 19, 2013 at 11:58:45AM +0100, Ben Dooks wrote:
>>> I ran in to an issue with the alignment handler when running BE8 where
>>> it loads instructions and fails to swap.
>>>
>>> Is there a better way of swapping instructions for ARM when loading
>>> from arbitrary places? Have I missed any other places this could happen?
>>
>> Maybe we need a macro which deals with this automatically?
>>
>> 	arm_instr_to_cpu(x)
>> 	thumb_instr_to_cpu(x)
>>
>> These should probably make use of the swab*() macros when an endian swap
>> is needed.
>>
>>> The following patch is my first attempt at solving the problem for the
>>> alignment handler:
>>
>> I'd suggest checking this with sparse too - you have some type errors here.
>
> How about:
>
> diff --git a/arch/arm/include/uapi/asm/byteorder.h  
> b/arch/arm/include/uapi/asm/b
> index 7737974..9e63a00 100644
> --- a/arch/arm/include/uapi/asm/byteorder.h
> +++ b/arch/arm/include/uapi/asm/byteorder.h
> @@ -21,5 +21,13 @@
>  #include <linux/byteorder/little_endian.h>
>  #endif
>
>
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +#define cpu_to_arm_instr(__instr)      swab32(__instr)
> +#define cpu_to_thum_instr(__instr)     swab16(__instr)
> +#else
> +#define cpu_to_arm_instr(__instr)      (__instr)
> +#define cpu_to_thum_instr(__instr)     (__instr)
> +#endif

ARGH.

First point: does userspace have any knowledge how the kernel is
configured?  Do they include the kernel configuration header file?  No.
Therefore the use of CONFIG_* in UAPI header files is wrong.

Second point: does userspace need these macros and should the kernel
provide them to userspace?  No on both counts.  Therefore, this must
not be placed in UAPI.

UAPI was created explicitly to separate the kernel private definitions
from the parts of the kernel interface which the user API depends on.

If you value your soul, NEVER EVER EVER place stuff which is not part
of the user API in a header file in a UAPI subdirectory.  And never
modify a header file in a UAPI subdirectory without first having a
good long think about how that modification may impact _userspace_.

Third point: the name is totally and utterly wrong.  I think you've
misunderstood the naming conventions of the cpu_to_xxx() and xxx_to_cpu()
macros.  "cpu" is the CPUs native data endianness - the endianness that
you can do standard arithmetic on and you get the right answer.  "xxx"
is the "foreign" endianness.  In this case, it's the instructions which
are not the CPUs native data endianness, so they are the foreign state -
they are the "xxx".

So, I've no idea why you decided to reverse the name of the macro I gave
you...  I am astounded at this.


From laurent.pinchart at ideasonboard.com  Fri Jul 19 08:42:14 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 19 Jul 2013 14:42:14 +0200
Subject: [PATCH 01/19] ARM: shmobile: r8a73a4: Add pin control device to
 device tree
In-Reply-To: <51E931EA.6010805@cogentembedded.com>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
 <c173e780f82e5dea3da21f9eda47bc48aa3f57b1.1374208262.git.horms+renesas@verge.net.au>
 <51E931EA.6010805@cogentembedded.com>
Message-ID: <5391577.hBy909tQ3H@avalon>

On Friday 19 July 2013 16:32:42 Sergei Shtylyov wrote:
> Hello.
> 
> On 19-07-2013 8:36, Simon Horman wrote:
> > From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> > 
> > Add a pfc node to the r8a73a4 device tree.
> 
>     This patch looks strange...
> 
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas at ideasonboard.com>
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> > ---
> > 
> >   arch/arm/boot/dts/r8a73a4.dtsi |   88
> >   ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88
> >   insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/r8a73a4.dtsi
> > b/arch/arm/boot/dts/r8a73a4.dtsi index 4ff2019..f1a35d5 100644
> > --- a/arch/arm/boot/dts/r8a73a4.dtsi
> > +++ b/arch/arm/boot/dts/r8a73a4.dtsi
> > @@ -85,4 +85,92 @@
> > 
> >   		interrupt-parent = <&gic>;
> >   		interrupts = <0 69 4>;
> >   	
> >   	};
> > 
> > +
> > +	i2c0: i2c at e6500000 {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +		compatible = "renesas,rmobile-iic";
> > +		reg = <0 0xe6500000 0 0x428>;
> > +		interrupt-parent = <&gic>;
> > +		interrupts = <0 174 0x4>;
> > +	};
> 
> [...]
> 
> > +	i2c8: i2c at e6570000 {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +		compatible = "renesas,rmobile-iic";
> > +		reg = <0 0xe6570000 0 0x428>;
> > +		interrupt-parent = <&gic>;
> > +		interrupts = <0 173 0x4>;
> > +	};
> > +
> 
> Hm, this also adds a bunch of I2C controllers which is not mentioned in the
> changelog at all.

Rebase error ? They were not included in my original patch.

-- 
Regards,

Laurent Pinchart



From jonas.jensen at gmail.com  Fri Jul 19 08:50:52 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Fri, 19 Jul 2013 14:50:52 +0200
Subject: [PATCH] ARM: clocksource: moxart: documentation: update device
 tree bindings document
In-Reply-To: <51E92E30.5090907@linaro.org>
References: <1374048297-4321-1-git-send-email-jonas.jensen@gmail.com>
 <1374232379-20900-1-git-send-email-jonas.jensen@gmail.com>
 <51E92E30.5090907@linaro.org>
Message-ID: <CACmBeS1zTcMCU=p-rfgrLzDrDGsjOuBvN6qzjP+HkUVhvGnsdQ@mail.gmail.com>

On 19 July 2013 14:16, Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
> Ok, pushed.

Thanks :)


From rogerq at ti.com  Fri Jul 19 09:04:15 2013
From: rogerq at ti.com (Roger Quadros)
Date: Fri, 19 Jul 2013 16:04:15 +0300
Subject: [PATCH] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
In-Reply-To: <51E5727B.2010500@denx.de>
References: <1366024808-4691-1-git-send-email-rogerq@ti.com>
 <51DC09E7.1070302@denx.de> <51DC164B.5010608@ti.com>
 <51DC1B47.7070504@denx.de> <51DE87D3.5030600@ti.com>
 <51DEA7F1.1050902@denx.de> <51DEC2CE.70400@ti.com> <51DED076.3040000@denx.de>
 <51DEF0DE.4050607@denx.de> <51DFC92F.1050701@ti.com>
 <51DFDFD4.3040900@denx.de> <51E3AFF4.7060607@ti.com>
 <51E3B1B1.3060202@denx.de> <51E55AAE.3000209@ti.com>
 <51E5727B.2010500@denx.de>
Message-ID: <51E9394F.8040004@ti.com>

On 07/16/2013 07:19 PM, Stefan Roese wrote:
> Hi Roger,
> 
> On 07/16/2013 04:37 PM, Roger Quadros wrote:
>> On 07/15/2013 11:24 AM, Stefan Roese wrote:
>>> On 07/15/2013 10:16 AM, Roger Quadros wrote:
>>>>>> I can only test on beagle-xm (which is also rev. C2) with integrated SMSC ethernet chip
>>>>>> as I don't have an external USB-ethernet adapter.
>>>>>
>>>>> Too bad. This difference in boards makes the tests a bit less
>>>>> meaningful. Is there really no USB-ethernet adapter somewhere in your
>>>>> department (perhaps a non-SMSC95xx might serve as well?)? I might
>>>>> send/order you one if necessary. ;)
>>>>
>>>> Thanks for the offer :). I'll just get one for myself by today/tomorrow.
>>>> The one available here uses this driver "drivers/net/usb/asix.c"
>>>
>>> Great.
>>>
>>
>> OK. Finally managed to reproduce the problem.
> 
> Ahh, great. Thanks for the effort.
> 
>> Don't know the root cause yet. Will need to investigate.
> 
> Thanks. Just let me know if I can be of any assistance (testing etc).
> 

For the record, not resetting the OMAP USB Host Module (UHH) from u-boot seems to solve
the issue.

Patch for u-boot below.

From: Roger Quadros <rogerq at ti.com>
Date: Fri, 19 Jul 2013 15:26:14 +0300
Subject: [PATCH] usb: ehci-omap: Don't softreset USB High-speed Host (UHH) Module

Fixes NFS root problems with Beagle (3530 ES1.0) when used with
external USB-ethernet adapter and "USB start" command used within
u-boot.

Soft resetting the UHH module causes instability issues on
all OMAPs so we just avoid it.

See OMAP36xx Errata
  i571: USB host EHCI may stall when entering smart-standby mode
  i660: USBHOST Configured In Smart-Idle Can Lead To a Deadlock

On OMAP4/5, soft-resetting the UHH module can put it into
Smart-Idle mode and lead to a deadlock.

On OMAP3 this doesn't seem to be the case but still instabilities
are observed on beagle (3530 ES1.0) if soft-reset is used.
 e.g. NFS root failures with Linux kernel.

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 drivers/usb/host/ehci-omap.c |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 086c697..628e86c 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -42,6 +42,22 @@ static struct omap_ehci *const ehci = (struct omap_ehci *)OMAP_EHCI_BASE;
 
 static int omap_uhh_reset(void)
 {
+/*
+ * Soft resetting the UHH module causes instability issues on
+ * all OMAPs so we just avoid it.
+ *
+ * See OMAP36xx Errata
+ *  i571: USB host EHCI may stall when entering smart-standby mode
+ *  i660: USBHOST Configured In Smart-Idle Can Lead To a Deadlock
+ *
+ * On OMAP4/5, soft-resetting the UHH module will put it into
+ * Smart-Idle mode and lead to a deadlock.
+ *
+ * On OMAP3 this doesn't seem to be the case but still instabilities
+ * are observed on beagle (3530 ES1.0) if soft-reset is used.
+ * e.g. NFS root failures with Linux kernel.
+ */
+#if 0
 	unsigned long init = get_timer(0);
 
 	/* perform UHH soft reset, and wait until reset is complete */
@@ -53,6 +69,7 @@ static int omap_uhh_reset(void)
 			debug("OMAP UHH error: timeout resetting ehci\n");
 			return -EL3RST;
 		}
+#endif
 
 	return 0;
 }
-- 
1.7.4.1





From nsekhar at ti.com  Fri Jul 19 09:06:05 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 19 Jul 2013 18:36:05 +0530
Subject: [PATCH v3 1/5] ARM: davinci: uart: move to devid based clk_get
In-Reply-To: <1371633342-1210-2-git-send-email-prakash.pm@ti.com>
References: <1371633342-1210-1-git-send-email-prakash.pm@ti.com>
 <1371633342-1210-2-git-send-email-prakash.pm@ti.com>
Message-ID: <51E939BD.8050600@ti.com>

On Wednesday 19 June 2013 02:45 PM, Manjunathappa, Prakash wrote:
> For modules having single clock, clk_get should be done with dev_id.
> But current davinci implementation handles multiple instances
> of the UART devices with single platform_device_register. Hence clk_get
> is based on con_id rather than dev_id, this is not correct. Do
> platform_device_register for each instance and clk_get on dev_id.
> 
> Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>

[...]

> diff --git a/arch/arm/mach-davinci/serial.c b/arch/arm/mach-davinci/serial.c
> index f262581..57e6150 100644
> --- a/arch/arm/mach-davinci/serial.c
> +++ b/arch/arm/mach-davinci/serial.c
> @@ -76,7 +76,7 @@ int __init davinci_serial_setup_clk(unsigned instance, unsigned int *rate)
>  	char name[16];
>  	struct clk *clk;
>  	struct davinci_soc_info *soc_info = &davinci_soc_info;
> -	struct device *dev = &soc_info->serial_dev->dev;
> +	struct device *dev = &soc_info->serial_dev[instance].dev;
>  
>  	sprintf(name, "uart%d", instance);
>  	clk = clk_get(dev, name);

Since the subject of your patch is to use avoid using the con_id for 
clk_get() match, you should stop passing 'name' here. So instead do

	clk = clk_get(dev, NULL);

I did this change locally (along with removal of now useless sprintf 
call and name variable) and committed for inclusion in v3.12. Final 
patch attached for reference.

Thanks,
Sekhar

---8<---
    ARM: davinci: uart: move to devid based clk_get
    
    For modules having single clock, clk_get should be done with dev_id.
    But current davinci implementation handles multiple instances
    of the UART devices with single platform_device_register. Hence clk_get
    is based on con_id rather than dev_id, this is not correct. Do
    platform_device_register for each instance and clk_get on dev_id.
    
    Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
    [nsekhar at ti.com: actually stop using con_id in clk_get()]
    Signed-off-by: Sekhar Nori <nsekhar at ti.com>

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index abbaf02..a3ffd52 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -395,9 +395,9 @@ static struct clk_lookup da830_clks[] = {
 	CLK(NULL,		"tptc0",	&tptc0_clk),
 	CLK(NULL,		"tptc1",	&tptc1_clk),
 	CLK("da830-mmc.0",	NULL,		&mmcsd_clk),
-	CLK(NULL,		"uart0",	&uart0_clk),
-	CLK(NULL,		"uart1",	&uart1_clk),
-	CLK(NULL,		"uart2",	&uart2_clk),
+	CLK("serial8250.0",	NULL,		&uart0_clk),
+	CLK("serial8250.1",	NULL,		&uart1_clk),
+	CLK("serial8250.2",	NULL,		&uart2_clk),
 	CLK("spi_davinci.0",	NULL,		&spi0_clk),
 	CLK("spi_davinci.1",	NULL,		&spi1_clk),
 	CLK(NULL,		"ecap0",	&ecap0_clk),
@@ -1199,7 +1199,7 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
 	.gpio_base		= DA8XX_GPIO_BASE,
 	.gpio_num		= 128,
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
-	.serial_dev		= &da8xx_serial_device,
+	.serial_dev		= da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
 };
 
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index a0d4f60..d4274ab 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -451,9 +451,9 @@ static struct clk_lookup da850_clks[] = {
 	CLK(NULL,		"tpcc1",	&tpcc1_clk),
 	CLK(NULL,		"tptc2",	&tptc2_clk),
 	CLK("pruss_uio",	"pruss",	&pruss_clk),
-	CLK(NULL,		"uart0",	&uart0_clk),
-	CLK(NULL,		"uart1",	&uart1_clk),
-	CLK(NULL,		"uart2",	&uart2_clk),
+	CLK("serial8250.0",	NULL,		&uart0_clk),
+	CLK("serial8250.1",	NULL,		&uart1_clk),
+	CLK("serial8250.2",	NULL,		&uart2_clk),
 	CLK(NULL,		"aintc",	&aintc_clk),
 	CLK(NULL,		"gpio",		&gpio_clk),
 	CLK("i2c_davinci.2",	NULL,		&i2c1_clk),
@@ -1301,7 +1301,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
 	.gpio_base		= DA8XX_GPIO_BASE,
 	.gpio_num		= 144,
 	.gpio_irq		= IRQ_DA8XX_GPIO0,
-	.serial_dev		= &da8xx_serial_device,
+	.serial_dev		= da8xx_serial_device,
 	.emac_pdata		= &da8xx_emac_pdata,
 	.sram_dma		= DA8XX_SHARED_RAM_BASE,
 	.sram_len		= SZ_128K,
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 71a46a3..280f67d 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -68,7 +68,7 @@
 void __iomem *da8xx_syscfg0_base;
 void __iomem *da8xx_syscfg1_base;
 
-static struct plat_serial8250_port da8xx_serial_pdata[] = {
+static struct plat_serial8250_port da8xx_serial0_pdata[] = {
 	{
 		.mapbase	= DA8XX_UART0_BASE,
 		.irq		= IRQ_DA8XX_UARTINT0,
@@ -78,6 +78,11 @@ static struct plat_serial8250_port da8xx_serial_pdata[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags	= 0,
+	}
+};
+static struct plat_serial8250_port da8xx_serial1_pdata[] = {
+	{
 		.mapbase	= DA8XX_UART1_BASE,
 		.irq		= IRQ_DA8XX_UARTINT1,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -86,6 +91,11 @@ static struct plat_serial8250_port da8xx_serial_pdata[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags	= 0,
+	}
+};
+static struct plat_serial8250_port da8xx_serial2_pdata[] = {
+	{
 		.mapbase	= DA8XX_UART2_BASE,
 		.irq		= IRQ_DA8XX_UARTINT2,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -95,15 +105,33 @@ static struct plat_serial8250_port da8xx_serial_pdata[] = {
 	},
 	{
 		.flags	= 0,
-	},
+	}
 };
 
-struct platform_device da8xx_serial_device = {
-	.name	= "serial8250",
-	.id	= PLAT8250_DEV_PLATFORM,
-	.dev	= {
-		.platform_data	= da8xx_serial_pdata,
+struct platform_device da8xx_serial_device[] = {
+	{
+		.name	= "serial8250",
+		.id	= PLAT8250_DEV_PLATFORM,
+		.dev	= {
+			.platform_data	= da8xx_serial0_pdata,
+		}
+	},
+	{
+		.name	= "serial8250",
+		.id	= PLAT8250_DEV_PLATFORM1,
+		.dev	= {
+			.platform_data	= da8xx_serial1_pdata,
+		}
 	},
+	{
+		.name	= "serial8250",
+		.id	= PLAT8250_DEV_PLATFORM2,
+		.dev	= {
+			.platform_data	= da8xx_serial2_pdata,
+		}
+	},
+	{
+	}
 };
 
 static s8 da8xx_queue_tc_mapping[][2] = {
diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c b/arch/arm/mach-davinci/devices-tnetv107x.c
index 128cb9a..fc4a0fe 100644
--- a/arch/arm/mach-davinci/devices-tnetv107x.c
+++ b/arch/arm/mach-davinci/devices-tnetv107x.c
@@ -126,7 +126,7 @@ static struct platform_device edma_device = {
 	.dev.platform_data = tnetv107x_edma_info,
 };
 
-static struct plat_serial8250_port serial_data[] = {
+static struct plat_serial8250_port serial0_platform_data[] = {
 	{
 		.mapbase	= TNETV107X_UART0_BASE,
 		.irq		= IRQ_TNETV107X_UART0,
@@ -137,6 +137,11 @@ static struct plat_serial8250_port serial_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags	= 0,
+	}
+};
+static struct plat_serial8250_port serial1_platform_data[] = {
+	{
 		.mapbase	= TNETV107X_UART1_BASE,
 		.irq		= IRQ_TNETV107X_UART1,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -146,6 +151,11 @@ static struct plat_serial8250_port serial_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags	= 0,
+	}
+};
+static struct plat_serial8250_port serial2_platform_data[] = {
+	{
 		.mapbase	= TNETV107X_UART2_BASE,
 		.irq		= IRQ_TNETV107X_UART2,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -156,13 +166,28 @@ static struct plat_serial8250_port serial_data[] = {
 	},
 	{
 		.flags	= 0,
-	},
+	}
 };
 
-struct platform_device tnetv107x_serial_device = {
-	.name			= "serial8250",
-	.id			= PLAT8250_DEV_PLATFORM,
-	.dev.platform_data	= serial_data,
+
+struct platform_device tnetv107x_serial_device[] = {
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM,
+		.dev.platform_data	= serial0_platform_data,
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM1,
+		.dev.platform_data	= serial1_platform_data,
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM2,
+		.dev.platform_data	= serial2_platform_data,
+	},
+	{
+	}
 };
 
 static struct resource mmc0_resources[] = {
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 42ef53f..29fdbae 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -357,9 +357,9 @@ static struct clk_lookup dm355_clks[] = {
 	CLK(NULL, "clkout3", &clkout3_clk),
 	CLK(NULL, "arm", &arm_clk),
 	CLK(NULL, "mjcp", &mjcp_clk),
-	CLK(NULL, "uart0", &uart0_clk),
-	CLK(NULL, "uart1", &uart1_clk),
-	CLK(NULL, "uart2", &uart2_clk),
+	CLK("serial8250.0", NULL, &uart0_clk),
+	CLK("serial8250.1", NULL, &uart1_clk),
+	CLK("serial8250.2", NULL, &uart2_clk),
 	CLK("i2c_davinci.1", NULL, &i2c_clk),
 	CLK("davinci-mcbsp.0", NULL, &asp0_clk),
 	CLK("davinci-mcbsp.1", NULL, &asp1_clk),
@@ -922,7 +922,7 @@ static struct davinci_timer_info dm355_timer_info = {
 	.clocksource_id	= T0_TOP,
 };
 
-static struct plat_serial8250_port dm355_serial_platform_data[] = {
+static struct plat_serial8250_port dm355_serial0_platform_data[] = {
 	{
 		.mapbase	= DAVINCI_UART0_BASE,
 		.irq		= IRQ_UARTINT0,
@@ -932,6 +932,11 @@ static struct plat_serial8250_port dm355_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags	= 0,
+	}
+};
+static struct plat_serial8250_port dm355_serial1_platform_data[] = {
+	{
 		.mapbase	= DAVINCI_UART1_BASE,
 		.irq		= IRQ_UARTINT1,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -940,6 +945,11 @@ static struct plat_serial8250_port dm355_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags	= 0,
+	}
+};
+static struct plat_serial8250_port dm355_serial2_platform_data[] = {
+	{
 		.mapbase	= DM355_UART2_BASE,
 		.irq		= IRQ_DM355_UARTINT2,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -948,16 +958,34 @@ static struct plat_serial8250_port dm355_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
-		.flags		= 0
-	},
+		.flags	= 0,
+	}
 };
 
-static struct platform_device dm355_serial_device = {
-	.name			= "serial8250",
-	.id			= PLAT8250_DEV_PLATFORM,
-	.dev			= {
-		.platform_data	= dm355_serial_platform_data,
+static struct platform_device dm355_serial_device[] = {
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM,
+		.dev			= {
+			.platform_data	= dm355_serial0_platform_data,
+		}
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM1,
+		.dev			= {
+			.platform_data	= dm355_serial1_platform_data,
+		}
 	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM2,
+		.dev			= {
+			.platform_data	= dm355_serial2_platform_data,
+		}
+	},
+	{
+	}
 };
 
 static struct davinci_soc_info davinci_soc_info_dm355 = {
@@ -981,7 +1009,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
 	.gpio_base		= DAVINCI_GPIO_BASE,
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM355_GPIOBNK0,
-	.serial_dev		= &dm355_serial_device,
+	.serial_dev		= dm355_serial_device,
 	.sram_dma		= 0x00010000,
 	.sram_len		= SZ_32K,
 };
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index fa7af5e..b601189 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -455,8 +455,8 @@ static struct clk_lookup dm365_clks[] = {
 	CLK("vpss", "master", &vpss_master_clk),
 	CLK("vpss", "slave", &vpss_slave_clk),
 	CLK(NULL, "arm", &arm_clk),
-	CLK(NULL, "uart0", &uart0_clk),
-	CLK(NULL, "uart1", &uart1_clk),
+	CLK("serial8250.0", NULL, &uart0_clk),
+	CLK("serial8250.1", NULL, &uart1_clk),
 	CLK("i2c_davinci.1", NULL, &i2c_clk),
 	CLK("da830-mmc.0", NULL, &mmcsd0_clk),
 	CLK("da830-mmc.1", NULL, &mmcsd1_clk),
@@ -1041,7 +1041,7 @@ static struct davinci_timer_info dm365_timer_info = {
 
 #define DM365_UART1_BASE	(IO_PHYS + 0x106000)
 
-static struct plat_serial8250_port dm365_serial_platform_data[] = {
+static struct plat_serial8250_port dm365_serial0_platform_data[] = {
 	{
 		.mapbase	= DAVINCI_UART0_BASE,
 		.irq		= IRQ_UARTINT0,
@@ -1051,6 +1051,11 @@ static struct plat_serial8250_port dm365_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags	= 0,
+	}
+};
+static struct plat_serial8250_port dm365_serial1_platform_data[] = {
+	{
 		.mapbase	= DM365_UART1_BASE,
 		.irq		= IRQ_UARTINT1,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -1059,16 +1064,27 @@ static struct plat_serial8250_port dm365_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
-		.flags		= 0
-	},
+		.flags	= 0,
+	}
 };
 
-static struct platform_device dm365_serial_device = {
-	.name			= "serial8250",
-	.id			= PLAT8250_DEV_PLATFORM,
-	.dev			= {
-		.platform_data	= dm365_serial_platform_data,
+static struct platform_device dm365_serial_device[] = {
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM,
+		.dev			= {
+			.platform_data	= dm365_serial0_platform_data,
+		}
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM1,
+		.dev			= {
+			.platform_data	= dm365_serial1_platform_data,
+		}
 	},
+	{
+	}
 };
 
 static struct davinci_soc_info davinci_soc_info_dm365 = {
@@ -1093,7 +1109,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
 	.gpio_num		= 104,
 	.gpio_irq		= IRQ_DM365_GPIO0,
 	.gpio_unbanked		= 8,	/* really 16 ... skip muxed GPIOs */
-	.serial_dev		= &dm365_serial_device,
+	.serial_dev		= dm365_serial_device,
 	.emac_pdata		= &dm365_emac_pdata,
 	.sram_dma		= 0x00010000,
 	.sram_len		= SZ_32K,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index a49d182..490eb8c 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -303,9 +303,9 @@ static struct clk_lookup dm644x_clks[] = {
 	CLK("vpss", "master", &vpss_master_clk),
 	CLK("vpss", "slave", &vpss_slave_clk),
 	CLK(NULL, "arm", &arm_clk),
-	CLK(NULL, "uart0", &uart0_clk),
-	CLK(NULL, "uart1", &uart1_clk),
-	CLK(NULL, "uart2", &uart2_clk),
+	CLK("serial8250.0", NULL, &uart0_clk),
+	CLK("serial8250.1", NULL, &uart1_clk),
+	CLK("serial8250.2", NULL, &uart2_clk),
 	CLK("davinci_emac.1", NULL, &emac_clk),
 	CLK("i2c_davinci.1", NULL, &i2c_clk),
 	CLK("palm_bk3710", NULL, &ide_clk),
@@ -813,7 +813,7 @@ static struct davinci_timer_info dm644x_timer_info = {
 	.clocksource_id	= T0_TOP,
 };
 
-static struct plat_serial8250_port dm644x_serial_platform_data[] = {
+static struct plat_serial8250_port dm644x_serial0_platform_data[] = {
 	{
 		.mapbase	= DAVINCI_UART0_BASE,
 		.irq		= IRQ_UARTINT0,
@@ -823,6 +823,11 @@ static struct plat_serial8250_port dm644x_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags	= 0,
+	}
+};
+static struct plat_serial8250_port dm644x_serial1_platform_data[] = {
+	{
 		.mapbase	= DAVINCI_UART1_BASE,
 		.irq		= IRQ_UARTINT1,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -831,6 +836,11 @@ static struct plat_serial8250_port dm644x_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags	= 0,
+	}
+};
+static struct plat_serial8250_port dm644x_serial2_platform_data[] = {
+	{
 		.mapbase	= DAVINCI_UART2_BASE,
 		.irq		= IRQ_UARTINT2,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -839,16 +849,34 @@ static struct plat_serial8250_port dm644x_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
-		.flags		= 0
-	},
+		.flags	= 0,
+	}
 };
 
-static struct platform_device dm644x_serial_device = {
-	.name			= "serial8250",
-	.id			= PLAT8250_DEV_PLATFORM,
-	.dev			= {
-		.platform_data	= dm644x_serial_platform_data,
+static struct platform_device dm644x_serial_device[] = {
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM,
+		.dev			= {
+			.platform_data	= dm644x_serial0_platform_data,
+		}
 	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM1,
+		.dev			= {
+			.platform_data	= dm644x_serial1_platform_data,
+		}
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM2,
+		.dev			= {
+			.platform_data	= dm644x_serial2_platform_data,
+		}
+	},
+	{
+	}
 };
 
 static struct davinci_soc_info davinci_soc_info_dm644x = {
@@ -872,7 +900,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
 	.gpio_base		= DAVINCI_GPIO_BASE,
 	.gpio_num		= 71,
 	.gpio_irq		= IRQ_GPIOBNK0,
-	.serial_dev		= &dm644x_serial_device,
+	.serial_dev		= dm644x_serial_device,
 	.emac_pdata		= &dm644x_emac_pdata,
 	.sram_dma		= 0x00008000,
 	.sram_len		= SZ_16K,
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index d1259e8..23609b1 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -342,9 +342,9 @@ static struct clk_lookup dm646x_clks[] = {
 	CLK(NULL, "edma_tc1", &edma_tc1_clk),
 	CLK(NULL, "edma_tc2", &edma_tc2_clk),
 	CLK(NULL, "edma_tc3", &edma_tc3_clk),
-	CLK(NULL, "uart0", &uart0_clk),
-	CLK(NULL, "uart1", &uart1_clk),
-	CLK(NULL, "uart2", &uart2_clk),
+	CLK("serial8250.0", NULL, &uart0_clk),
+	CLK("serial8250.1", NULL, &uart1_clk),
+	CLK("serial8250.2", NULL, &uart2_clk),
 	CLK("i2c_davinci.1", NULL, &i2c_clk),
 	CLK(NULL, "gpio", &gpio_clk),
 	CLK("davinci-mcasp.0", NULL, &mcasp0_clk),
@@ -790,7 +790,7 @@ static struct davinci_timer_info dm646x_timer_info = {
 	.clocksource_id	= T0_TOP,
 };
 
-static struct plat_serial8250_port dm646x_serial_platform_data[] = {
+static struct plat_serial8250_port dm646x_serial0_platform_data[] = {
 	{
 		.mapbase	= DAVINCI_UART0_BASE,
 		.irq		= IRQ_UARTINT0,
@@ -800,6 +800,11 @@ static struct plat_serial8250_port dm646x_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags	= 0,
+	}
+};
+static struct plat_serial8250_port dm646x_serial1_platform_data[] = {
+	{
 		.mapbase	= DAVINCI_UART1_BASE,
 		.irq		= IRQ_UARTINT1,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -808,6 +813,11 @@ static struct plat_serial8250_port dm646x_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
+		.flags	= 0,
+	}
+};
+static struct plat_serial8250_port dm646x_serial2_platform_data[] = {
+	{
 		.mapbase	= DAVINCI_UART2_BASE,
 		.irq		= IRQ_DM646X_UARTINT2,
 		.flags		= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -816,16 +826,34 @@ static struct plat_serial8250_port dm646x_serial_platform_data[] = {
 		.regshift	= 2,
 	},
 	{
-		.flags		= 0
-	},
+		.flags	= 0,
+	}
 };
 
-static struct platform_device dm646x_serial_device = {
-	.name			= "serial8250",
-	.id			= PLAT8250_DEV_PLATFORM,
-	.dev			= {
-		.platform_data	= dm646x_serial_platform_data,
+static struct platform_device dm646x_serial_device[] = {
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM,
+		.dev			= {
+			.platform_data	= dm646x_serial0_platform_data,
+		}
+	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM1,
+		.dev			= {
+			.platform_data	= dm646x_serial1_platform_data,
+		}
 	},
+	{
+		.name			= "serial8250",
+		.id			= PLAT8250_DEV_PLATFORM2,
+		.dev			= {
+			.platform_data	= dm646x_serial2_platform_data,
+		}
+	},
+	{
+	}
 };
 
 static struct davinci_soc_info davinci_soc_info_dm646x = {
@@ -849,7 +877,7 @@ static struct davinci_soc_info davinci_soc_info_dm646x = {
 	.gpio_base		= DAVINCI_GPIO_BASE,
 	.gpio_num		= 43, /* Only 33 usable */
 	.gpio_irq		= IRQ_DM646X_GPIOBNK0,
-	.serial_dev		= &dm646x_serial_device,
+	.serial_dev		= dm646x_serial_device,
 	.emac_pdata		= &dm646x_emac_pdata,
 	.sram_dma		= 0x10010000,
 	.sram_len		= SZ_32K,
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index 7b41a5e..aae5307 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -111,7 +111,7 @@ void da8xx_restart(enum reboot_mode mode, const char *cmd);
 void da8xx_rproc_reserve_cma(void);
 int da8xx_register_rproc(void);
 
-extern struct platform_device da8xx_serial_device;
+extern struct platform_device da8xx_serial_device[];
 extern struct emac_platform_data da8xx_emac_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lcd035q3dg01_pdata;
 extern struct da8xx_lcdc_platform_data sharp_lk043t1dg01_pdata;
diff --git a/arch/arm/mach-davinci/include/mach/tnetv107x.h b/arch/arm/mach-davinci/include/mach/tnetv107x.h
index 16314c6..beb7c0e 100644
--- a/arch/arm/mach-davinci/include/mach/tnetv107x.h
+++ b/arch/arm/mach-davinci/include/mach/tnetv107x.h
@@ -50,7 +50,7 @@ struct tnetv107x_device_info {
 };
 
 extern struct platform_device tnetv107x_wdt_device;
-extern struct platform_device tnetv107x_serial_device;
+extern struct platform_device tnetv107x_serial_device[];
 
 extern void tnetv107x_init(void);
 extern void tnetv107x_devices_init(struct tnetv107x_device_info *);
diff --git a/arch/arm/mach-davinci/serial.c b/arch/arm/mach-davinci/serial.c
index f262581..2bc74c2 100644
--- a/arch/arm/mach-davinci/serial.c
+++ b/arch/arm/mach-davinci/serial.c
@@ -73,13 +73,11 @@ static void __init davinci_serial_reset(struct plat_serial8250_port *p)
 /* Enable UART clock and obtain its rate */
 int __init davinci_serial_setup_clk(unsigned instance, unsigned int *rate)
 {
-	char name[16];
 	struct clk *clk;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
-	struct device *dev = &soc_info->serial_dev->dev;
+	struct device *dev = &soc_info->serial_dev[instance].dev;
 
-	sprintf(name, "uart%d", instance);
-	clk = clk_get(dev, name);
+	clk = clk_get(dev, NULL);
 	if (IS_ERR(clk)) {
 		pr_err("%s:%d: failed to get UART%d clock\n",
 					__func__, __LINE__, instance);
@@ -96,19 +94,25 @@ int __init davinci_serial_setup_clk(unsigned instance, unsigned int *rate)
 
 int __init davinci_serial_init(struct davinci_uart_config *info)
 {
-	int i, ret;
+	int i, ret = 0;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
-	struct device *dev = &soc_info->serial_dev->dev;
-	struct plat_serial8250_port *p = dev->platform_data;
+	struct device *dev;
+	struct plat_serial8250_port *p;
 
 	/*
 	 * Make sure the serial ports are muxed on at this point.
 	 * You have to mux them off in device drivers later on if not needed.
 	 */
-	for (i = 0; p->flags; i++, p++) {
+	for (i = 0; soc_info->serial_dev[i].dev.platform_data != NULL; i++) {
+		dev = &soc_info->serial_dev[i].dev;
+		p = dev->platform_data;
 		if (!(info->enabled_uarts & (1 << i)))
 			continue;
 
+		ret = platform_device_register(&soc_info->serial_dev[i]);
+		if (ret)
+			continue;
+
 		ret = davinci_serial_setup_clk(i, &p->uartclk);
 		if (ret)
 			continue;
@@ -125,6 +129,5 @@ int __init davinci_serial_init(struct davinci_uart_config *info)
 		if (p->membase && p->type != PORT_AR7)
 			davinci_serial_reset(p);
 	}
-
-	return platform_device_register(soc_info->serial_dev);
+	return ret;
 }
diff --git a/arch/arm/mach-davinci/tnetv107x.c b/arch/arm/mach-davinci/tnetv107x.c
index 4545667..f4d7fbb 100644
--- a/arch/arm/mach-davinci/tnetv107x.c
+++ b/arch/arm/mach-davinci/tnetv107x.c
@@ -264,7 +264,7 @@ static struct clk_lookup clks[] = {
 	CLK(NULL,		"clk_chipcfg",		&clk_chipcfg),
 	CLK("tnetv107x-ts.0",	NULL,			&clk_tsc),
 	CLK(NULL,		"clk_rom",		&clk_rom),
-	CLK(NULL,		"uart2",		&clk_uart2),
+	CLK("serial8250.2",     NULL,			&clk_uart2),
 	CLK(NULL,		"clk_pktsec",		&clk_pktsec),
 	CLK("tnetv107x-rng.0",	NULL,			&clk_rng),
 	CLK("tnetv107x-pka.0",	NULL,			&clk_pka),
@@ -274,8 +274,8 @@ static struct clk_lookup clks[] = {
 	CLK(NULL,		"clk_gpio",		&clk_gpio),
 	CLK(NULL,		"clk_mdio",		&clk_mdio),
 	CLK("dm6441-mmc.0",	NULL,			&clk_sdio0),
-	CLK(NULL,		"uart0",		&clk_uart0),
-	CLK(NULL,		"uart1",		&clk_uart1),
+	CLK("serial8250.0",	NULL,			&clk_uart0),
+	CLK("serial8250.1",	NULL,			&clk_uart1),
 	CLK(NULL,		"timer0",		&clk_timer0),
 	CLK(NULL,		"timer1",		&clk_timer1),
 	CLK("tnetv107x_wdt.0",	NULL,			&clk_wdt_arm),
@@ -757,7 +757,7 @@ static struct davinci_soc_info tnetv107x_soc_info = {
 	.gpio_type		= GPIO_TYPE_TNETV107X,
 	.gpio_num		= TNETV107X_N_GPIO,
 	.timer_info		= &timer_info,
-	.serial_dev		= &tnetv107x_serial_device,
+	.serial_dev		= tnetv107x_serial_device,
 };
 
 void __init tnetv107x_init(void)



From julien.grall at linaro.org  Fri Jul 19 09:09:59 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Fri, 19 Jul 2013 14:09:59 +0100
Subject: [PATCH v2] xen/arm: enable PV control for ARM
Message-ID: <1374239399-2498-1-git-send-email-julien.grall@linaro.org>

Enable power management from the toolstack for ARM guest.

Signed-off-by: Julien Grall <julien.grall at linaro.org>

---
    Changes in v2:
        - Don't compile xen/cpu_hotplug.o with ARM64
---
 drivers/xen/Makefile |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 2bf461a..b550a94 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,9 +1,8 @@
-ifneq ($(CONFIG_ARM),y)
-obj-y	+= manage.o
+ifneq ($(filter y, ($CONFIG_ARM) $(CONFIG_ARM64)),)
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
 obj-$(CONFIG_X86)			+= fallback.o
-obj-y	+= grant-table.o features.o events.o balloon.o time.o
+obj-y	+= grant-table.o features.o events.o balloon.o time.o manage.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Fri Jul 19 09:19:12 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Fri, 19 Jul 2013 14:19:12 +0100
Subject: alignment handler instruction endian-ness
In-Reply-To: <20130719123249.GE24642@n2100.arm.linux.org.uk>
References: <51E91BE5.8070809@codethink.co.uk>
 <20130719110947.GD24642@n2100.arm.linux.org.uk>
 <51E92DE5.6090404@codethink.co.uk>
 <20130719123249.GE24642@n2100.arm.linux.org.uk>
Message-ID: <51E93CD0.3040302@codethink.co.uk>

On 19/07/13 13:32, Russell King - ARM Linux wrote:
> On Fri, Jul 19, 2013 at 01:15:33PM +0100, Ben Dooks wrote:
>> On 19/07/13 12:09, Russell King - ARM Linux wrote:
>>> On Fri, Jul 19, 2013 at 11:58:45AM +0100, Ben Dooks wrote:
>>>> I ran in to an issue with the alignment handler when running BE8 where
>>>> it loads instructions and fails to swap.
>>>>
>>>> Is there a better way of swapping instructions for ARM when loading
>>>> from arbitrary places? Have I missed any other places this could happen?
>>>
>>> Maybe we need a macro which deals with this automatically?
>>>
>>> 	arm_instr_to_cpu(x)
>>> 	thumb_instr_to_cpu(x)
>>>
>>> These should probably make use of the swab*() macros when an endian swap
>>> is needed.
>>>
>>>> The following patch is my first attempt at solving the problem for the
>>>> alignment handler:
>>>
>>> I'd suggest checking this with sparse too - you have some type errors here.
>>
>> How about:
>>
>> diff --git a/arch/arm/include/uapi/asm/byteorder.h
>> b/arch/arm/include/uapi/asm/b
>> index 7737974..9e63a00 100644
>> --- a/arch/arm/include/uapi/asm/byteorder.h
>> +++ b/arch/arm/include/uapi/asm/byteorder.h
>> @@ -21,5 +21,13 @@
>>   #include<linux/byteorder/little_endian.h>
>>   #endif
>>
>>
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +#define cpu_to_arm_instr(__instr)      swab32(__instr)
>> +#define cpu_to_thum_instr(__instr)     swab16(__instr)
>> +#else
>> +#define cpu_to_arm_instr(__instr)      (__instr)
>> +#define cpu_to_thum_instr(__instr)     (__instr)
>> +#endif
>
> ARGH.
>
> First point: does userspace have any knowledge how the kernel is
> configured?  Do they include the kernel configuration header file?  No.
> Therefore the use of CONFIG_* in UAPI header files is wrong.
>
> Second point: does userspace need these macros and should the kernel
> provide them to userspace?  No on both counts.  Therefore, this must
> not be placed in UAPI.
>
> UAPI was created explicitly to separate the kernel private definitions
> from the parts of the kernel interface which the user API depends on.
>
> If you value your soul, NEVER EVER EVER place stuff which is not part
> of the user API in a header file in a UAPI subdirectory.  And never
> modify a header file in a UAPI subdirectory without first having a
> good long think about how that modification may impact _userspace_.

Sorry, searched for byteorder.h and just did not notice.

Where is the best place for these to go?

> Third point: the name is totally and utterly wrong.  I think you've
> misunderstood the naming conventions of the cpu_to_xxx() and xxx_to_cpu()
> macros.  "cpu" is the CPUs native data endianness - the endianness that
> you can do standard arithmetic on and you get the right answer.  "xxx"
> is the "foreign" endianness.  In this case, it's the instructions which
> are not the CPUs native data endianness, so they are the foreign state -
> they are the "xxx".
>
> So, I've no idea why you decided to reverse the name of the macro I gave
> you...  I am astounded at this.

I meant to put both versions in as I thought they'd be needed/.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From festevam at gmail.com  Fri Jul 19 09:40:23 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 19 Jul 2013 10:40:23 -0300
Subject: [PATCH] ARM: dts: imx6qdl-sabresd: Allow buttons to wake-up the system
Message-ID: <1374241223-27975-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

This is useful for testing suspend/resume sequence.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 166b9ae..ac24ed1 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -41,12 +41,14 @@
 		volume-up {
 			label = "Volume Up";
 			gpios = <&gpio1 4 0>;
+			gpio-key,wakeup;
 			linux,code = <115>; /* KEY_VOLUMEUP */
 		};
 
 		volume-down {
 			label = "Volume Down";
 			gpios = <&gpio1 5 0>;
+			gpio-key,wakeup;
 			linux,code = <114>; /* KEY_VOLUMEDOWN */
 		};
 	};
-- 
1.8.1.2



From konrad.wilk at oracle.com  Fri Jul 19 09:50:50 2013
From: konrad.wilk at oracle.com (Konrad Rzeszutek Wilk)
Date: Fri, 19 Jul 2013 09:50:50 -0400
Subject: [PATCH v2] xen/arm: disable cpuidle and cpufreq when linux is
 running as dom0
In-Reply-To: <1374233220-13770-1-git-send-email-julien.grall@linaro.org>
References: <1374233220-13770-1-git-send-email-julien.grall@linaro.org>
Message-ID: <20130719135050.GA12144@localhost.localdomain>

On Fri, Jul 19, 2013 at 12:27:00PM +0100, Julien Grall wrote:
> When linux is running as dom0, Xen doesn't show the physical cpu but a
> virtual CPU.
> On some ARM SOC (for instance the exynos 5250), linux registers callbacks
> for cpuidle and cpufreq. When these callbacks are called, they will modify
> directly the physical cpu not the virtual one. It can impact the whole board
> instead of only dom0.
> 
> Signed-off-by: Julien Grall <julien.grall at linaro.org>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
> 
> ---
>     Changes in v2:
>         - Disable cpufreq
> ---
>  arch/arm/xen/enlighten.c |    8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 49839d8..af82792 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -24,6 +24,8 @@
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_address.h>
> +#include <linux/cpuidle.h>
> +#include <linux/cpufreq.h>
>  
>  #include <linux/mm.h>
>  
> @@ -292,6 +294,12 @@ static int __init xen_pm_init(void)
>  {
>  	pm_power_off = xen_power_off;
>  	arm_pm_restart = xen_restart;
> +	/*
> +	 * Making sure board specific code will not set up ops for
> +	 * cpu idle and cpu freq.
> +	 */
> +	disable_cpuidle();
> +	disable_cpufreq();
>  
>  	return 0;
>  }
> -- 
> 1.7.10.4
> 


From marc.zyngier at arm.com  Fri Jul 19 09:53:51 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Jul 2013 14:53:51 +0100
Subject: [PATCH 0/4] KVM/arm64 fixes for 3.11
Message-ID: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>

This series contains a small number of patches for KVM/arm64. The
first two are the arm64 equivalent of AArch32 fixes that have already
been merged, and the next two are more related to performance
optimisation and code cleanup.

The patches are also available at:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/fixes-3.11-rc1

Marc Zyngier (4):
  arm64: KVM: perform save/restore of PAR_EL1
  arm64: KVM: add missing dsb before invalidating Stage-2 TLBs
  arm64: KVM: let other tasks run when hitting WFE
  arm64: KVM: remove __kvm_hyp_code_{start,end} from hyp.S

 arch/arm64/include/asm/kvm_arm.h |  6 ++++--
 arch/arm64/include/asm/kvm_asm.h | 23 ++++++++++++++---------
 arch/arm64/include/asm/virt.h    |  4 ++++
 arch/arm64/kvm/handle_exit.c     | 18 +++++++++++++-----
 arch/arm64/kvm/hyp.S             | 18 ++++++++++++------
 arch/arm64/kvm/sys_regs.c        |  3 +++
 6 files changed, 50 insertions(+), 22 deletions(-)

-- 
1.8.2.3




From marc.zyngier at arm.com  Fri Jul 19 09:53:55 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Jul 2013 14:53:55 +0100
Subject: [PATCH 4/4] arm64: KVM: remove __kvm_hyp_code_{start,end} from hyp.S
In-Reply-To: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1374242035-13199-5-git-send-email-marc.zyngier@arm.com>

We already have __hyp_text_{start,end} to express the boundaries
of the HYP text section, and __kvm_hyp_code_{start,end} are getting
in the way of a more modular world switch code.

Just turn __kvm_hyp_code_{start,end} into #defines mapping the
linker-emited symbols.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_asm.h | 6 ++++--
 arch/arm64/include/asm/virt.h    | 4 ++++
 arch/arm64/kvm/hyp.S             | 6 ------
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index b25763b..dddb345 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -18,6 +18,8 @@
 #ifndef __ARM_KVM_ASM_H__
 #define __ARM_KVM_ASM_H__
 
+#include <asm/virt.h>
+
 /*
  * 0 is reserved as an invalid value.
  * Order *must* be kept in sync with the hyp switch code.
@@ -95,8 +97,8 @@ extern char __kvm_hyp_init_end[];
 
 extern char __kvm_hyp_vector[];
 
-extern char __kvm_hyp_code_start[];
-extern char __kvm_hyp_code_end[];
+#define	__kvm_hyp_code_start	__hyp_text_start
+#define	__kvm_hyp_code_end	__hyp_text_end
 
 extern void __kvm_flush_vm_context(void);
 extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 4398272..59d67f3 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -49,6 +49,10 @@ static inline bool is_hyp_mode_mismatched(void)
 	return __boot_cpu_mode[0] != __boot_cpu_mode[1];
 }
 
+/* The section containing the hypervisor text */
+extern char __hyp_text_start[];
+extern char __hyp_text_end[];
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* ! __ASM__VIRT_H */
diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index e1ccfcc..19ccf48 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -36,9 +36,6 @@
 	.pushsection	.hyp.text, "ax"
 	.align	PAGE_SHIFT
 
-__kvm_hyp_code_start:
-	.globl __kvm_hyp_code_start
-
 .macro save_common_regs
 	// x2: base address for cpu context
 	// x3: tmp register
@@ -837,7 +834,4 @@ ENTRY(__kvm_hyp_vector)
 	ventry	el1_error_invalid		// Error 32-bit EL1
 ENDPROC(__kvm_hyp_vector)
 
-__kvm_hyp_code_end:
-	.globl	__kvm_hyp_code_end
-
 	.popsection
-- 
1.8.2.3




From marc.zyngier at arm.com  Fri Jul 19 09:53:53 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Jul 2013 14:53:53 +0100
Subject: [PATCH 2/4] arm64: KVM: add missing dsb before invalidating Stage-2
 TLBs
In-Reply-To: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1374242035-13199-3-git-send-email-marc.zyngier@arm.com>

When performing a Stage-2 TLB invalidation, it is necessary to
make sure the write to the page tables is observable by all CPUs.

For this purpose, add a dsb instruction to __kvm_tlb_flush_vmid_ipa
before doing the TLB invalidation itself.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index 218802f..e1ccfcc 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -604,6 +604,8 @@ END(__kvm_vcpu_run)
 
 // void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
 ENTRY(__kvm_tlb_flush_vmid_ipa)
+	dsb	ishst	// Make sure previous writes are observable
+
 	kern_hyp_va	x0
 	ldr	x2, [x0, #KVM_VTTBR]
 	msr	vttbr_el2, x2
-- 
1.8.2.3




From marc.zyngier at arm.com  Fri Jul 19 09:53:52 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Jul 2013 14:53:52 +0100
Subject: [PATCH 1/4] arm64: KVM: perform save/restore of PAR_EL1
In-Reply-To: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1374242035-13199-2-git-send-email-marc.zyngier@arm.com>

Not saving PAR_EL1 is an unfortunate oversight. If the guest
performs an AT* operation and gets scheduled out before reading
the result of the translation from PAREL1, it could become
corrupted by another guest or the host.

Saving this register is made slightly more complicated as KVM also
uses it on the permission fault handling path, leading to an ugly
"stash and restore" sequence. Fortunately, this is already a slow
path so we don't really care. Also, Linux doesn't do any AT*
operation, so Linux guests are not impacted by this bug.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_asm.h | 17 ++++++++++-------
 arch/arm64/kvm/hyp.S             | 10 ++++++++++
 arch/arm64/kvm/sys_regs.c        |  3 +++
 3 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index c92de41..b25763b 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -42,14 +42,15 @@
 #define	TPIDR_EL1	18	/* Thread ID, Privileged */
 #define	AMAIR_EL1	19	/* Aux Memory Attribute Indirection Register */
 #define	CNTKCTL_EL1	20	/* Timer Control Register (EL1) */
+#define	PAR_EL1		21	/* Physical Address Register */
 /* 32bit specific registers. Keep them at the end of the range */
-#define	DACR32_EL2	21	/* Domain Access Control Register */
-#define	IFSR32_EL2	22	/* Instruction Fault Status Register */
-#define	FPEXC32_EL2	23	/* Floating-Point Exception Control Register */
-#define	DBGVCR32_EL2	24	/* Debug Vector Catch Register */
-#define	TEECR32_EL1	25	/* ThumbEE Configuration Register */
-#define	TEEHBR32_EL1	26	/* ThumbEE Handler Base Register */
-#define	NR_SYS_REGS	27
+#define	DACR32_EL2	22	/* Domain Access Control Register */
+#define	IFSR32_EL2	23	/* Instruction Fault Status Register */
+#define	FPEXC32_EL2	24	/* Floating-Point Exception Control Register */
+#define	DBGVCR32_EL2	25	/* Debug Vector Catch Register */
+#define	TEECR32_EL1	26	/* ThumbEE Configuration Register */
+#define	TEEHBR32_EL1	27	/* ThumbEE Handler Base Register */
+#define	NR_SYS_REGS	28
 
 /* 32bit mapping */
 #define c0_MPIDR	(MPIDR_EL1 * 2)	/* MultiProcessor ID Register */
@@ -69,6 +70,8 @@
 #define c5_AIFSR	(AFSR1_EL1 * 2)	/* Auxiliary Instr Fault Status R */
 #define c6_DFAR		(FAR_EL1 * 2)	/* Data Fault Address Register */
 #define c6_IFAR		(c6_DFAR + 1)	/* Instruction Fault Address Register */
+#define c7_PAR		(PAR_EL1 * 2)	/* Physical Address Register */
+#define c7_PAR_high	(c7_PAR + 1)	/* PAR top 32 bits */
 #define c10_PRRR	(MAIR_EL1 * 2)	/* Primary Region Remap Register */
 #define c10_NMRR	(c10_PRRR + 1)	/* Normal Memory Remap Register */
 #define c12_VBAR	(VBAR_EL1 * 2)	/* Vector Base Address Register */
diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index ff985e3..218802f 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -214,6 +214,7 @@ __kvm_hyp_code_start:
 	mrs	x21,	tpidr_el1
 	mrs	x22, 	amair_el1
 	mrs	x23, 	cntkctl_el1
+	mrs	x24,	par_el1
 
 	stp	x4, x5, [x3]
 	stp	x6, x7, [x3, #16]
@@ -225,6 +226,7 @@ __kvm_hyp_code_start:
 	stp	x18, x19, [x3, #112]
 	stp	x20, x21, [x3, #128]
 	stp	x22, x23, [x3, #144]
+	str	x24, [x3, #160]
 .endm
 
 .macro restore_sysregs
@@ -243,6 +245,7 @@ __kvm_hyp_code_start:
 	ldp	x18, x19, [x3, #112]
 	ldp	x20, x21, [x3, #128]
 	ldp	x22, x23, [x3, #144]
+	ldr	x24, [x3, #160]
 
 	msr	vmpidr_el2,	x4
 	msr	csselr_el1,	x5
@@ -264,6 +267,7 @@ __kvm_hyp_code_start:
 	msr	tpidr_el1,	x21
 	msr	amair_el1,	x22
 	msr	cntkctl_el1,	x23
+	msr	par_el1,	x24
 .endm
 
 .macro skip_32bit_state tmp, target
@@ -753,6 +757,10 @@ el1_trap:
 	 */
 	tbnz	x1, #7, 1f	// S1PTW is set
 
+	/* Preserve PAR_EL1 */
+	mrs	x3, par_el1
+	push	x3, xzr
+
 	/*
 	 * Permission fault, HPFAR_EL2 is invalid.
 	 * Resolve the IPA the hard way using the guest VA.
@@ -766,6 +774,8 @@ el1_trap:
 
 	/* Read result */
 	mrs	x3, par_el1
+	pop	x0, xzr			// Restore PAR_EL1 from the stack
+	msr	par_el1, x0
 	tbnz	x3, #0, 3f		// Bail out if we failed the translation
 	ubfx	x3, x3, #12, #36	// Extract IPA
 	lsl	x3, x3, #4		// and present it like HPFAR
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 9492360..02e9d09 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -211,6 +211,9 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	/* FAR_EL1 */
 	{ Op0(0b11), Op1(0b000), CRn(0b0110), CRm(0b0000), Op2(0b000),
 	  NULL, reset_unknown, FAR_EL1 },
+	/* PAR_EL1 */
+	{ Op0(0b11), Op1(0b000), CRn(0b0111), CRm(0b0100), Op2(0b000),
+	  NULL, reset_unknown, PAR_EL1 },
 
 	/* PMINTENSET_EL1 */
 	{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b001),
-- 
1.8.2.3




From marc.zyngier at arm.com  Fri Jul 19 09:53:54 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Jul 2013 14:53:54 +0100
Subject: [PATCH 3/4] arm64: KVM: let other tasks run when hitting WFE
In-Reply-To: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>

So far, when a guest executes WFE (like when waiting for a spinlock
to become unlocked), we don't do a thing and let it run uninterrupted.

Another option is to trap a blocking WFE and offer the opportunity
to the scheduler to switch to another task, potentially giving the
vcpu holding the spinlock a chance to run sooner.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_arm.h |  6 ++++--
 arch/arm64/kvm/handle_exit.c     | 18 +++++++++++++-----
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index a5f28e2..ac1ea05 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -63,6 +63,7 @@
  * TAC:		Trap ACTLR
  * TSC:		Trap SMC
  * TSW:		Trap cache operations by set/way
+ * TWE:		Trap WFE
  * TWI:		Trap WFI
  * TIDCP:	Trap L2CTLR/L2ECTLR
  * BSU_IS:	Upgrade barriers to the inner shareable domain
@@ -72,8 +73,9 @@
  * FMO:		Override CPSR.F and enable signaling with VF
  * SWIO:	Turn set/way invalidates into set/way clean+invalidate
  */
-#define HCR_GUEST_FLAGS (HCR_TSC | HCR_TSW | HCR_TWI | HCR_VM | HCR_BSU_IS | \
-			 HCR_FB | HCR_TAC | HCR_AMO | HCR_IMO | HCR_FMO | \
+#define HCR_GUEST_FLAGS (HCR_TSC | HCR_TSW | HCR_TWE | HCR_TWI | HCR_VM | \
+			 HCR_BSU_IS | HCR_FB | HCR_TAC | \
+			 HCR_AMO | HCR_IMO | HCR_FMO | \
 			 HCR_SWIO | HCR_TIDCP | HCR_RW)
 #define HCR_VIRT_EXCP_MASK (HCR_VA | HCR_VI | HCR_VF)
 
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 9beaca03..b0098c2 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -47,21 +47,29 @@ static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run)
 }
 
 /**
- * kvm_handle_wfi - handle a wait-for-interrupts instruction executed by a guest
+ * kvm_handle_wfx - handle a wait-for-interrupts or wait-for-event
+ *		    instruction executed by a guest
+ *
  * @vcpu:	the vcpu pointer
  *
- * Simply call kvm_vcpu_block(), which will halt execution of
+ * WFE: Yield the CPU and come back to this vcpu when the scheduler
+ * decides to.
+ * WFI: Simply call kvm_vcpu_block(), which will halt execution of
  * world-switches and schedule other host processes until there is an
  * incoming IRQ or FIQ to the VM.
  */
-static int kvm_handle_wfi(struct kvm_vcpu *vcpu, struct kvm_run *run)
+static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
 {
-	kvm_vcpu_block(vcpu);
+	if (kvm_vcpu_get_hsr(vcpu) & 1)
+		cond_resched();
+	else
+		kvm_vcpu_block(vcpu);
+
 	return 1;
 }
 
 static exit_handle_fn arm_exit_handlers[] = {
-	[ESR_EL2_EC_WFI]	= kvm_handle_wfi,
+	[ESR_EL2_EC_WFI]	= kvm_handle_wfx,
 	[ESR_EL2_EC_CP15_32]	= kvm_handle_cp15_32,
 	[ESR_EL2_EC_CP15_64]	= kvm_handle_cp15_64,
 	[ESR_EL2_EC_CP14_MR]	= kvm_handle_cp14_access,
-- 
1.8.2.3




From lee.jones at linaro.org  Fri Jul 19 09:58:32 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:32 +0100
Subject: [PATCH 01/22] ARM: ux500: Remove '0x's from HREF v60+ DTS file
Message-ID: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/hrefv60plus.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/hrefv60plus.dts b/arch/arm/boot/dts/hrefv60plus.dts
index 3d580d6..46fd8af 100644
--- a/arch/arm/boot/dts/hrefv60plus.dts
+++ b/arch/arm/boot/dts/hrefv60plus.dts
@@ -26,7 +26,7 @@
 
 	soc {
 		i2c at 80110000 {
-			bu21013_tp at 0x5c {
+			bu21013_tp at 5c {
 				reset-gpio = <&gpio4 15 0x4>;
 			};
 		};
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:33 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:33 +0100
Subject: [PATCH 02/22] ARM: ux500: Remove '0x's from nomadik stn8815 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-2-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
index a3acfa7..c2ee51e 100644
--- a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
+++ b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
@@ -742,14 +742,14 @@
 		#size-cells = <1>;
 		ranges;
 
-		vica: intc at 0x10140000 {
+		vica: intc at 10140000 {
 			compatible = "arm,versatile-vic";
 			interrupt-controller;
 			#interrupt-cells = <1>;
 			reg = <0x10140000 0x20>;
 		};
 
-		vicb: intc at 0x10140020 {
+		vicb: intc at 10140020 {
 			compatible = "arm,versatile-vic";
 			interrupt-controller;
 			#interrupt-cells = <1>;
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:34 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:34 +0100
Subject: [PATCH 03/22] ARM: ux500: Remove '0x's from U300 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-3-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/ste-u300.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index 8a1032c..a9da480 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -307,7 +307,7 @@
 		clocks = <&i2c0_clk>;
 		#address-cells = <1>;
 		#size-cells = <0>;
-		ab3100: ab3100 at 0x48 {
+		ab3100: ab3100 at 48 {
 			compatible = "stericsson,ab3100";
 			reg = <0x48>;
 			interrupt-parent = <&vica>;
@@ -385,10 +385,10 @@
 		clocks = <&i2c1_clk>;
 		#address-cells = <1>;
 		#size-cells = <0>;
-		fwcam0: fwcam at 0x10 {
+		fwcam0: fwcam at 10 {
 			reg = <0x10>;
 		};
-		fwcam1: fwcam at 0x5d {
+		fwcam1: fwcam at 5d {
 			reg = <0x5d>;
 		};
 	};
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:36 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:36 +0100
Subject: [PATCH 05/22] ARM: ux500: Remove '0x's from BCM11351 BRT DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-5-git-send-email-lee.jones@linaro.org>

Cc: Christian Daudt <csd at broadcom.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/bcm11351-brt.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/bcm11351-brt.dts b/arch/arm/boot/dts/bcm11351-brt.dts
index 67ec524..fdace5d 100644
--- a/arch/arm/boot/dts/bcm11351-brt.dts
+++ b/arch/arm/boot/dts/bcm11351-brt.dts
@@ -27,18 +27,18 @@
 		status = "okay";
 	};
 
-	sdio0: sdio at 0x3f180000 {
+	sdio0: sdio at 3f180000 {
 		max-frequency = <48000000>;
 		status = "okay";
 	};
 
-	sdio1: sdio at 0x3f190000 {
+	sdio1: sdio at 3f190000 {
 		non-removable;
 		max-frequency = <48000000>;
 		status = "okay";
 	};
 
-	sdio3: sdio at 0x3f1b0000 {
+	sdio3: sdio at 3f1b0000 {
 		max-frequency = <48000000>;
 		status = "okay";
 	};
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:37 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:37 +0100
Subject: [PATCH 06/22] ARM: ux500: Remove '0x's from BCM11351 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-6-git-send-email-lee.jones@linaro.org>

Cc: Christian Daudt <csd at broadcom.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/bcm11351.dtsi | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index c0cdf66..db5873a 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -34,7 +34,7 @@
 		      <0x3ff00100 0x100>;
 	};
 
-	smc at 0x3404c000 {
+	smc at 3404c000 {
 		compatible = "bcm,bcm11351-smc", "bcm,kona-smc";
 		reg = <0x3404c000 0x400>; /* 1 KiB in SRAM */
 	};
@@ -63,28 +63,28 @@
 		clock-frequency = <32768>;
 	};
 
-	sdio0: sdio at 0x3f180000 {
+	sdio0: sdio at 3f180000 {
 		compatible = "bcm,kona-sdhci";
 		reg = <0x3f180000 0x10000>;
 		interrupts = <0x0 77 0x4>;
 		status = "disabled";
 	};
 
-	sdio1: sdio at 0x3f190000 {
+	sdio1: sdio at 3f190000 {
 		compatible = "bcm,kona-sdhci";
 		reg = <0x3f190000 0x10000>;
 		interrupts = <0x0 76 0x4>;
 		status = "disabled";
 	};
 
-	sdio2: sdio at 0x3f1a0000 {
+	sdio2: sdio at 3f1a0000 {
 		compatible = "bcm,kona-sdhci";
 		reg = <0x3f1a0000 0x10000>;
 		interrupts = <0x0 74 0x4>;
 		status = "disabled";
 	};
 
-	sdio3: sdio at 0x3f1b0000 {
+	sdio3: sdio at 3f1b0000 {
 		compatible = "bcm,kona-sdhci";
 		reg = <0x3f1b0000 0x10000>;
 		interrupts = <0x0 73 0x4>;
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:38 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:38 +0100
Subject: [PATCH 07/22] ARM: ux500: Remove '0x's from Exynos4110 DTSI file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-7-git-send-email-lee.jones@linaro.org>

Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/exynos4210.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index b7f358a..53e2527 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -72,7 +72,7 @@
 		};
 	};
 
-	clock: clock-controller at 0x10030000 {
+	clock: clock-controller at 10030000 {
 		compatible = "samsung,exynos4210-clock";
 		reg = <0x10030000 0x20000>;
 		#clock-cells = <1>;
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:39 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:39 +0100
Subject: [PATCH 08/22] ARM: ux500: Remove '0x's from Exynos4x12 DTSI file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-8-git-send-email-lee.jones@linaro.org>

Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index 01da194..3aa2f06 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -28,7 +28,7 @@
 		pinctrl3 = &pinctrl_3;
 	};
 
-	clock: clock-controller at 0x10030000 {
+	clock: clock-controller at 10030000 {
 		compatible = "samsung,exynos4412-clock";
 		reg = <0x10030000 0x20000>;
 		#clock-cells = <1>;
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:42 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:42 +0100
Subject: [PATCH 11/22] ARM: ux500: Remove '0x's from Exynos5440 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-11-git-send-email-lee.jones@linaro.org>

Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/exynos5440.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index ff7f5d8..0cedba4 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -20,7 +20,7 @@
 		spi0 = &spi_0;
 	};
 
-	clock: clock-controller at 0x160000 {
+	clock: clock-controller at 160000 {
 		compatible = "samsung,exynos5440-clock";
 		reg = <0x160000 0x1000>;
 		#clock-cells = <1>;
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:40 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:40 +0100
Subject: [PATCH 09/22] ARM: ux500: Remove '0x's from Exynos5250 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-9-git-send-email-lee.jones@linaro.org>

Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/exynos5250.dtsi | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index ef57277..24c0888 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -68,17 +68,17 @@
 		};
 	};
 
-	pd_gsc: gsc-power-domain at 0x10044000 {
+	pd_gsc: gsc-power-domain at 10044000 {
 		compatible = "samsung,exynos4210-pd";
 		reg = <0x10044000 0x20>;
 	};
 
-	pd_mfc: mfc-power-domain at 0x10044040 {
+	pd_mfc: mfc-power-domain at 10044040 {
 		compatible = "samsung,exynos4210-pd";
 		reg = <0x10044040 0x20>;
 	};
 
-	clock: clock-controller at 0x10010000 {
+	clock: clock-controller at 10010000 {
 		compatible = "samsung,exynos5250-clock";
 		reg = <0x10010000 0x30000>;
 		#clock-cells = <1>;
@@ -562,7 +562,7 @@
 		};
 	};
 
-	gsc_0:  gsc at 0x13e00000 {
+	gsc_0:  gsc at 13e00000 {
 		compatible = "samsung,exynos5-gsc";
 		reg = <0x13e00000 0x1000>;
 		interrupts = <0 85 0>;
@@ -571,7 +571,7 @@
 		clock-names = "gscl";
 	};
 
-	gsc_1:  gsc at 0x13e10000 {
+	gsc_1:  gsc at 13e10000 {
 		compatible = "samsung,exynos5-gsc";
 		reg = <0x13e10000 0x1000>;
 		interrupts = <0 86 0>;
@@ -580,7 +580,7 @@
 		clock-names = "gscl";
 	};
 
-	gsc_2:  gsc at 0x13e20000 {
+	gsc_2:  gsc at 13e20000 {
 		compatible = "samsung,exynos5-gsc";
 		reg = <0x13e20000 0x1000>;
 		interrupts = <0 87 0>;
@@ -589,7 +589,7 @@
 		clock-names = "gscl";
 	};
 
-	gsc_3:  gsc at 0x13e30000 {
+	gsc_3:  gsc at 13e30000 {
 		compatible = "samsung,exynos5-gsc";
 		reg = <0x13e30000 0x1000>;
 		interrupts = <0 88 0>;
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:41 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:41 +0100
Subject: [PATCH 10/22] ARM: ux500: Remove '0x's from Exynos5420 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-10-git-send-email-lee.jones@linaro.org>

Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/exynos5420.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 8c54c4b..9e90d1e 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -59,7 +59,7 @@
 		};
 	};
 
-	clock: clock-controller at 0x10010000 {
+	clock: clock-controller at 10010000 {
 		compatible = "samsung,exynos5420-clock";
 		reg = <0x10010000 0x30000>;
 		#clock-cells = <1>;
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:43 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:43 +0100
Subject: [PATCH 12/22] ARM: ux500: Remove '0x's from OMAP2420 H4 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-12-git-send-email-lee.jones@linaro.org>

Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/omap2420-h4.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/omap2420-h4.dts b/arch/arm/boot/dts/omap2420-h4.dts
index 224c08f..34cdecb 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -50,15 +50,15 @@
 			label = "bootloader";
 			reg = <0 0x20000>;
 		};
-		partition at 0x20000 {
+		partition at 20000 {
 			label = "params";
 			reg = <0x20000 0x20000>;
 		};
-		partition at 0x40000 {
+		partition at 40000 {
 			label = "kernel";
 			reg = <0x40000 0x200000>;
 		};
-		partition at 0x240000 {
+		partition at 240000 {
 			label = "file-system";
 			reg = <0x240000 0x3dc0000>;
 		};
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:44 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:44 +0100
Subject: [PATCH 13/22] ARM: ux500: Remove '0x's from OMAP3 IGEP0020 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-13-git-send-email-lee.jones@linaro.org>

Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/omap3-igep0020.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
index e8c4828..f7a8122 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -99,19 +99,19 @@
 			label = "SPL";
 			reg = <0 0x100000>;
 		};
-		partition at 0x80000 {
+		partition at 80000 {
 			label = "U-Boot";
 			reg = <0x100000 0x180000>;
 		};
-		partition at 0x1c0000 {
+		partition at 1c0000 {
 			label = "Environment";
 			reg = <0x280000 0x100000>;
 		};
-		partition at 0x280000 {
+		partition at 280000 {
 			label = "Kernel";
 			reg = <0x380000 0x300000>;
 		};
-		partition at 0x780000 {
+		partition at 780000 {
 			label = "Filesystem";
 			reg = <0x680000 0x1f980000>;
 		};
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:46 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:46 +0100
Subject: [PATCH 15/22] ARM: ux500: Remove '0x's from OMAP3 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-15-git-send-email-lee.jones@linaro.org>

Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/omap3.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..16420ae 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -111,7 +111,7 @@
 			pinctrl-single,function-mask = <0x7f1f>;
 		};
 
-		omap3_pmx_wkup: pinmux at 0x48002a00 {
+		omap3_pmx_wkup: pinmux at 48002a00 {
 			compatible = "ti,omap3-padconf", "pinctrl-single";
 			reg = <0x48002a00 0x5c>;
 			#address-cells = <1>;
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:45 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:45 +0100
Subject: [PATCH 14/22] ARM: ux500: Remove '0x's from OMAP3 IGEP0030 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-14-git-send-email-lee.jones@linaro.org>

Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/omap3-igep0030.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts
index 644d0538..f628200 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -74,19 +74,19 @@
 			label = "SPL";
 			reg = <0 0x100000>;
 		};
-		partition at 0x80000 {
+		partition at 80000 {
 			label = "U-Boot";
 			reg = <0x100000 0x180000>;
 		};
-		partition at 0x1c0000 {
+		partition at 1c0000 {
 			label = "Environment";
 			reg = <0x280000 0x100000>;
 		};
-		partition at 0x280000 {
+		partition at 280000 {
 			label = "Kernel";
 			reg = <0x380000 0x300000>;
 		};
-		partition at 0x780000 {
+		partition at 780000 {
 			label = "Filesystem";
 			reg = <0x680000 0x1f980000>;
 		};
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:48 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:48 +0100
Subject: [PATCH 17/22] ARM: ux500: Remove '0x's from OMAP4 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-17-git-send-email-lee.jones@linaro.org>

Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/omap4.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..45708e1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -56,7 +56,7 @@
 		cache-level = <2>;
 	};
 
-	local-timer at 0x48240600 {
+	local-timer at 48240600 {
 		compatible = "arm,cortex-a9-twd-timer";
 		reg = <0x48240600 0x20>;
 		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_RAW(3) | IRQ_TYPE_LEVEL_HIGH)>;
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:47 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:47 +0100
Subject: [PATCH 16/22] ARM: ux500: Remove '0x's from OMAP3430 SDP DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-16-git-send-email-lee.jones@linaro.org>

Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/omap3430-sdp.dts | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
index e2249bc..281914e 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -84,15 +84,15 @@
 			label = "bootloader-nor";
 			reg = <0 0x40000>;
 		};
-		partition at 0x40000 {
+		partition at 40000 {
 			label = "params-nor";
 			reg = <0x40000 0x40000>;
 		};
-		partition at 0x80000 {
+		partition at 80000 {
 			label = "kernel-nor";
 			reg = <0x80000 0x200000>;
 		};
-		partition at 0x280000 {
+		partition at 280000 {
 			label = "filesystem-nor";
 			reg = <0x240000 0x7d80000>;
 		};
@@ -125,19 +125,19 @@
 			label = "xloader-nand";
 			reg = <0 0x80000>;
 		};
-		partition at 0x80000 {
+		partition at 80000 {
 			label = "bootloader-nand";
 			reg = <0x80000 0x140000>;
 		};
-		partition at 0x1c0000 {
+		partition at 1c0000 {
 			label = "params-nand";
 			reg = <0x1c0000 0xc0000>;
 		};
-		partition at 0x280000 {
+		partition at 280000 {
 			label = "kernel-nand";
 			reg = <0x280000 0x500000>;
 		};
-		partition at 0x780000 {
+		partition at 780000 {
 			label = "filesystem-nand";
 			reg = <0x780000 0x7880000>;
 		};
@@ -170,19 +170,19 @@
 			label = "xloader-onenand";
 			reg = <0 0x80000>;
 		};
-		partition at 0x80000 {
+		partition at 80000 {
 			label = "bootloader-onenand";
 			reg = <0x80000 0x40000>;
 		};
-		partition at 0xc0000 {
+		partition at c0000 {
 			label = "params-onenand";
 			reg = <0xc0000 0x20000>;
 		};
-		partition at 0xe0000 {
+		partition at e0000 {
 			label = "kernel-onenand";
 			reg = <0xe0000 0x200000>;
 		};
-		partition at 0x2e0000 {
+		partition at 2e0000 {
 			label = "filesystem-onenand";
 			reg = <0x2e0000 0xfd20000>;
 		};
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:49 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:49 +0100
Subject: [PATCH 18/22] ARM: ux500: Remove '0x's from OMAP5 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-18-git-send-email-lee.jones@linaro.org>

Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/omap5.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..be58604 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -604,7 +604,7 @@
 			ti,hwmods = "wd_timer2";
 		};
 
-		emif1: emif at 0x4c000000 {
+		emif1: emif at 4c000000 {
 			compatible	= "ti,emif-4d5";
 			ti,hwmods	= "emif1";
 			phy-type	= <2>; /* DDR PHY type: Intelli PHY */
@@ -615,7 +615,7 @@
 			hw-caps-temp-alert;
 		};
 
-		emif2: emif at 0x4d000000 {
+		emif2: emif at 4d000000 {
 			compatible	= "ti,emif-4d5";
 			ti,hwmods	= "emif2";
 			phy-type	= <2>; /* DDR PHY type: Intelli PHY */
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:50 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:50 +0100
Subject: [PATCH 19/22] ARM: ux500: Remove '0x's from R8A7779 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-19-git-send-email-lee.jones@linaro.org>

Cc: Simon Horman <horms+renesas at verge.net.au>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/r8a7779.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 7f146c6..86bd487 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -65,7 +65,7 @@
 		sense-bitfield-width = <2>;
 	};
 
-	i2c0: i2c at 0xffc70000 {
+	i2c0: i2c at ffc70000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "renesas,rmobile-iic";
@@ -74,7 +74,7 @@
 		interrupts = <0 79 0x4>;
 	};
 
-	i2c1: i2c at 0xffc71000 {
+	i2c1: i2c at ffc71000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "renesas,rmobile-iic";
@@ -83,7 +83,7 @@
 		interrupts = <0 82 0x4>;
 	};
 
-	i2c2: i2c at 0xffc72000 {
+	i2c2: i2c at ffc72000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "renesas,rmobile-iic";
@@ -92,7 +92,7 @@
 		interrupts = <0 80 0x4>;
 	};
 
-	i2c3: i2c at 0xffc73000 {
+	i2c3: i2c at ffc73000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "renesas,rmobile-iic";
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:51 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:51 +0100
Subject: [PATCH 20/22] ARM: ux500: Remove '0x's from Spear 300 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-20-git-send-email-lee.jones@linaro.org>

Cc: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/spear300.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/spear300.dtsi b/arch/arm/boot/dts/spear300.dtsi
index f79b3df..8970a4a 100644
--- a/arch/arm/boot/dts/spear300.dtsi
+++ b/arch/arm/boot/dts/spear300.dtsi
@@ -52,7 +52,7 @@
 			status = "disabled";
 		};
 
-		shirq: interrupt-controller at 0x50000000 {
+		shirq: interrupt-controller at 50000000 {
 			compatible = "st,spear300-shirq";
 			reg = <0x50000000 0x1000>;
 			interrupts = <28>;
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:52 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:52 +0100
Subject: [PATCH 21/22] ARM: ux500: Remove '0x's from Spear 310 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-21-git-send-email-lee.jones@linaro.org>

Cc: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/spear310.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/spear310.dtsi b/arch/arm/boot/dts/spear310.dtsi
index 9537208..dc263e4 100644
--- a/arch/arm/boot/dts/spear310.dtsi
+++ b/arch/arm/boot/dts/spear310.dtsi
@@ -40,7 +40,7 @@
 			status = "disabled";
 		};
 
-		shirq: interrupt-controller at 0xb4000000 {
+		shirq: interrupt-controller at b4000000 {
 			compatible = "st,spear310-shirq";
 			reg = <0xb4000000 0x1000>;
 			interrupts = <28 29 30 1>;
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 09:58:53 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:53 +0100
Subject: [PATCH 22/22] ARM: ux500: Remove '0x's from Spear 320 DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-22-git-send-email-lee.jones@linaro.org>

Cc: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/spear320.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/spear320.dtsi b/arch/arm/boot/dts/spear320.dtsi
index ffea342..a82d76e5 100644
--- a/arch/arm/boot/dts/spear320.dtsi
+++ b/arch/arm/boot/dts/spear320.dtsi
@@ -55,7 +55,7 @@
 			status = "disabled";
 		};
 
-		shirq: interrupt-controller at 0xb3000000 {
+		shirq: interrupt-controller at b3000000 {
 			compatible = "st,spear320-shirq";
 			reg = <0xb3000000 0x1000>;
 			interrupts = <30 28 29 1>;
-- 
1.8.1.2



From tixy at linaro.org  Fri Jul 19 10:01:02 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Fri, 19 Jul 2013 15:01:02 +0100
Subject: alignment handler instruction endian-ness
In-Reply-To: <20130719110947.GD24642@n2100.arm.linux.org.uk>
References: <51E91BE5.8070809@codethink.co.uk>
 <20130719110947.GD24642@n2100.arm.linux.org.uk>
Message-ID: <1374242462.3406.59.camel@linaro1.home>

On Fri, 2013-07-19 at 12:09 +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 19, 2013 at 11:58:45AM +0100, Ben Dooks wrote:
> > I ran in to an issue with the alignment handler when running BE8 where
> > it loads instructions and fails to swap.
> >
> > Is there a better way of swapping instructions for ARM when loading
> > from arbitrary places? Have I missed any other places this could happen?
> 
> Maybe we need a macro which deals with this automatically?

Like the stuff in arch/arm/include/asm/opcodes.h ?

> 	arm_instr_to_cpu(x)
> 	thumb_instr_to_cpu(x)
> 
> These should probably make use of the swab*() macros when an endian swap
> is needed.
> 
> > The following patch is my first attempt at solving the problem for the
> > alignment handler:
> 
> I'd suggest checking this with sparse too - you have some type errors here.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel




From linux at arm.linux.org.uk  Fri Jul 19 10:05:13 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Jul 2013 15:05:13 +0100
Subject: alignment handler instruction endian-ness
In-Reply-To: <1374242462.3406.59.camel@linaro1.home>
References: <51E91BE5.8070809@codethink.co.uk>
 <20130719110947.GD24642@n2100.arm.linux.org.uk>
 <1374242462.3406.59.camel@linaro1.home>
Message-ID: <20130719140513.GF24642@n2100.arm.linux.org.uk>

On Fri, Jul 19, 2013 at 03:01:02PM +0100, Jon Medhurst (Tixy) wrote:
> On Fri, 2013-07-19 at 12:09 +0100, Russell King - ARM Linux wrote:
> > On Fri, Jul 19, 2013 at 11:58:45AM +0100, Ben Dooks wrote:
> > > I ran in to an issue with the alignment handler when running BE8 where
> > > it loads instructions and fails to swap.
> > >
> > > Is there a better way of swapping instructions for ARM when loading
> > > from arbitrary places? Have I missed any other places this could happen?
> > 
> > Maybe we need a macro which deals with this automatically?
> 
> Like the stuff in arch/arm/include/asm/opcodes.h ?

Not like asm/opcodes.h does at the moment, because there's really no
reason whatsoever that it isn't using the standard swab stuff, which
will automatically use the rev/rev16 instructions where available.

There's really no reason to open code that stuff.


From lee.jones at linaro.org  Fri Jul 19 09:58:35 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 14:58:35 +0100
Subject: [PATCH 04/22] ARM: ux500: Remove '0x's from Animeo IP DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374242333-6852-4-git-send-email-lee.jones@linaro.org>

Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/animeo_ip.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/animeo_ip.dts b/arch/arm/boot/dts/animeo_ip.dts
index 3a1de9e..4cb0342 100644
--- a/arch/arm/boot/dts/animeo_ip.dts
+++ b/arch/arm/boot/dts/animeo_ip.dts
@@ -105,7 +105,7 @@
 				reg = <0x48000 0x8000>;
 			};
 
-			user_block at 0x50000 {
+			user_block at 50000 {
 				label = "user_block";
 				reg = <0x50000 0xb0000>;
 			};
-- 
1.8.1.2



From festevam at gmail.com  Fri Jul 19 10:11:44 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 19 Jul 2013 11:11:44 -0300
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <CAOMZO5CbB6JBb6F7yWavWxVDaDQAGGZUB96x4an1XaiHuyt8fg@mail.gmail.com>

Hi Alexander,

On Thu, Jul 11, 2013 at 3:27 AM, Peter Chen <peter.chen at freescale.com> wrote:
> This patchset adds tested otg id switch function and
> vbus connect and disconnect detection for chipidea driver.
> And fix kinds of bugs found at chipidea drivers after enabling
> id and vbus detection.
>
> This patch is fully tested at imx6 sabresd platform.
> My chipidea repo: https://github.com/hzpeterchen/linux-usb.git
>
> Changes for v12:
> - Rebased greg's usb-next tree (3.10.0-rc7+)
> - Split more small patches for single function and fix.

Any comments about this series?


From lee.jones at linaro.org  Fri Jul 19 10:13:36 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 15:13:36 +0100
Subject: [PATCH 00/13] ARM: ux500: Misc Device Tree patches
Message-ID: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>

In this patchset we:

1. Remove nodes which aren't pertinent to Snowball from its DTS file
2. Provide ST-Ericsson's DTS[I] files with a ste-* prefix
3. Remove the old u9540.dts file 



From lee.jones at linaro.org  Fri Jul 19 10:13:37 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 15:13:37 +0100
Subject: [PATCH 01/13] ARM: ux500: Remove Toshiba TC35892 I/O Expander's DT
 entry from Snowball's DTS
In-Reply-To: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
References: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374243229-8585-2-git-send-email-lee.jones@linaro.org>

It doesn't exist on this development board.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/snowball.dts | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 49824be..16c2b23 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -166,12 +166,6 @@
 		};
 
 		i2c at 80004000 {
-			tc3589x at 42 {
-				//compatible = "tc3589x";
-				reg = <0x42>;
-				gpios = <&gpio6 25 0x4>;
-				interrupt-parent = <&gpio6>;
-			};
 			tps61052 at 33 {
 				//compatible = "tps61052";
 				reg = <0x33>;
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 10:13:38 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 15:13:38 +0100
Subject: [PATCH 02/13] ARM: ux500: Remove Snowball DTS entry for National
 Semiconductor LP5521 LED chip
In-Reply-To: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
References: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374243229-8585-3-git-send-email-lee.jones@linaro.org>

It doesn't exist on the Snowball development board.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/snowball.dts | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 16c2b23..a5d6317 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -173,14 +173,6 @@
 		};
 
 		i2c at 80128000 {
-			lp5521 at 33 {
-				// compatible = "lp5521";
-				reg = <0x33>;
-			};
-			lp5521 at 34 {
-				// compatible = "lp5521";
-				reg = <0x34>;
-			};
 			bh1780 at 29 {
 				// compatible = "rohm,bh1780gli";
 				reg = <0x33>;
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 10:13:39 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 15:13:39 +0100
Subject: [PATCH 03/13] ARM: ux500: Remove Snowball DTS entry for TPS61052 chip
In-Reply-To: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
References: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374243229-8585-4-git-send-email-lee.jones@linaro.org>

TPS61052 is a; boost converter, LED driver, LED flash driver and
simple GPIO pin chip. It has no use here however, as it is not
found on the Snowball development board.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/snowball.dts | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index a5d6317..d01ec70 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -165,13 +165,6 @@
 			status = "okay";
 		};
 
-		i2c at 80004000 {
-			tps61052 at 33 {
-				//compatible = "tps61052";
-				reg = <0x33>;
-			};
-		};
-
 		i2c at 80128000 {
 			bh1780 at 29 {
 				// compatible = "rohm,bh1780gli";
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 10:13:40 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 15:13:40 +0100
Subject: [PATCH 04/13] ARM: ux500: Remove Snowball DTS entry for ROHM
 BH1780GLI ambient light sensor
In-Reply-To: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
References: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374243229-8585-5-git-send-email-lee.jones@linaro.org>

It doesn't exist on the Snowball development board.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/snowball.dts | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index d01ec70..dc5c641 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -165,13 +165,6 @@
 			status = "okay";
 		};
 
-		i2c at 80128000 {
-			bh1780 at 29 {
-				// compatible = "rohm,bh1780gli";
-				reg = <0x33>;
-			};
-		};
-
 		cpufreq-cooling {
 			status = "okay";
 		};
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 10:13:41 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 15:13:41 +0100
Subject: [PATCH 05/13] ARM: ux500: Apply a ste-* prefix onto snowball.dts
In-Reply-To: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
References: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374243229-8585-6-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/{snowball.dts => ste-snowball.dts} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename arch/arm/boot/dts/{snowball.dts => ste-snowball.dts} (100%)

diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/ste-snowball.dts
similarity index 100%
rename from arch/arm/boot/dts/snowball.dts
rename to arch/arm/boot/dts/ste-snowball.dts
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 10:13:42 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 15:13:42 +0100
Subject: [PATCH 06/13] ARM: ux500: Apply a ste-* prefix onto ccu8540.dts
In-Reply-To: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
References: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374243229-8585-7-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/{ccu8540.dts => ste-ccu8540.dts} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename arch/arm/boot/dts/{ccu8540.dts => ste-ccu8540.dts} (100%)

diff --git a/arch/arm/boot/dts/ccu8540.dts b/arch/arm/boot/dts/ste-ccu8540.dts
similarity index 100%
rename from arch/arm/boot/dts/ccu8540.dts
rename to arch/arm/boot/dts/ste-ccu8540.dts
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 10:13:45 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 15:13:45 +0100
Subject: [PATCH 09/13] ARM: ux500: Apply a ste-* prefix onto hrefprev60.dts
 Signed-off-by: Lee Jones <lee.jones@linaro.org>
In-Reply-To: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
References: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374243229-8585-10-git-send-email-lee.jones@linaro.org>

---
 arch/arm/boot/dts/{hrefprev60.dts => ste-hrefprev60.dts} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename arch/arm/boot/dts/{hrefprev60.dts => ste-hrefprev60.dts} (100%)

diff --git a/arch/arm/boot/dts/hrefprev60.dts b/arch/arm/boot/dts/ste-hrefprev60.dts
similarity index 100%
rename from arch/arm/boot/dts/hrefprev60.dts
rename to arch/arm/boot/dts/ste-hrefprev60.dts
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 10:13:43 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 15:13:43 +0100
Subject: [PATCH 07/13] ARM: ux500: Apply a ste-* prefix onto ccu9540.dts
In-Reply-To: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
References: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374243229-8585-8-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/{ccu9540.dts => ste-ccu9540.dts} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename arch/arm/boot/dts/{ccu9540.dts => ste-ccu9540.dts} (100%)

diff --git a/arch/arm/boot/dts/ccu9540.dts b/arch/arm/boot/dts/ste-ccu9540.dts
similarity index 100%
rename from arch/arm/boot/dts/ccu9540.dts
rename to arch/arm/boot/dts/ste-ccu9540.dts
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 10:13:46 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 15:13:46 +0100
Subject: [PATCH 10/13] ARM: ux500: Apply a ste-* prefix onto hrefv60plus.dts
In-Reply-To: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
References: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374243229-8585-11-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/{hrefv60plus.dts => ste-hrefv60plus.dts} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename arch/arm/boot/dts/{hrefv60plus.dts => ste-hrefv60plus.dts} (100%)

diff --git a/arch/arm/boot/dts/hrefv60plus.dts b/arch/arm/boot/dts/ste-hrefv60plus.dts
similarity index 100%
rename from arch/arm/boot/dts/hrefv60plus.dts
rename to arch/arm/boot/dts/ste-hrefv60plus.dts
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 10:13:44 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 15:13:44 +0100
Subject: [PATCH 08/13] ARM: ux500: Apply a ste-* prefix onto href.dtsi
In-Reply-To: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
References: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374243229-8585-9-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/{href.dtsi => ste-href.dtsi} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename arch/arm/boot/dts/{href.dtsi => ste-href.dtsi} (100%)

diff --git a/arch/arm/boot/dts/href.dtsi b/arch/arm/boot/dts/ste-href.dtsi
similarity index 100%
rename from arch/arm/boot/dts/href.dtsi
rename to arch/arm/boot/dts/ste-href.dtsi
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 10:13:47 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 15:13:47 +0100
Subject: [PATCH 11/13] ARM: ux500: Apply a ste-* prefix onto stuib.dtsi
In-Reply-To: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
References: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374243229-8585-12-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/{stuib.dtsi => ste-stuib.dtsi} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename arch/arm/boot/dts/{stuib.dtsi => ste-stuib.dtsi} (100%)

diff --git a/arch/arm/boot/dts/stuib.dtsi b/arch/arm/boot/dts/ste-stuib.dtsi
similarity index 100%
rename from arch/arm/boot/dts/stuib.dtsi
rename to arch/arm/boot/dts/ste-stuib.dtsi
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 10:13:48 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 15:13:48 +0100
Subject: [PATCH 12/13] ARM: ux500: Apply a ste-* prefix onto dbx5x0.dtsi
In-Reply-To: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
References: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374243229-8585-13-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/{dbx5x0.dtsi => ste-dbx5x0.dtsi} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename arch/arm/boot/dts/{dbx5x0.dtsi => ste-dbx5x0.dtsi} (100%)

diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/ste-dbx5x0.dtsi
similarity index 100%
rename from arch/arm/boot/dts/dbx5x0.dtsi
rename to arch/arm/boot/dts/ste-dbx5x0.dtsi
-- 
1.8.1.2



From lee.jones at linaro.org  Fri Jul 19 10:13:49 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 19 Jul 2013 15:13:49 +0100
Subject: [PATCH 13/13] ARM: ux500: Remove u9540.dts as it's been replaced
In-Reply-To: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
References: <1374243229-8585-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374243229-8585-14-git-send-email-lee.jones@linaro.org>

This must have been a merge error. There was a patch which renamed the
u9540.dts to ccu9540.dts, however the u9540.dts was reincarnate with
the same patches which created it in the first place. Let's kill it
once and for all.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/u9540.dts | 72 ---------------------------------------------
 1 file changed, 72 deletions(-)
 delete mode 100644 arch/arm/boot/dts/u9540.dts

diff --git a/arch/arm/boot/dts/u9540.dts b/arch/arm/boot/dts/u9540.dts
deleted file mode 100644
index 95892ec..0000000
--- a/arch/arm/boot/dts/u9540.dts
+++ /dev/null
@@ -1,72 +0,0 @@
-/*
- * Copyright 2012 ST-Ericsson AB
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
-
-/dts-v1/;
-/include/ "dbx5x0.dtsi"
-
-/ {
-	model = "ST-Ericsson U9540 platform with Device Tree";
-	compatible = "st-ericsson,u9540";
-
-	memory {
-		reg = <0x00000000 0x20000000>;
-	};
-
-	soc-u9500 {
-		uart at 80120000 {
-			status = "okay";
-		};
-
-		uart at 80121000 {
-			status = "okay";
-		};
-
-		uart at 80007000 {
-			status = "okay";
-		};
-
-		// External Micro SD slot
-		sdi0_per1 at 80126000 {
-			arm,primecell-periphid = <0x10480180>;
-			max-frequency = <100000000>;
-			bus-width = <4>;
-			mmc-cap-sd-highspeed;
-			mmc-cap-mmc-highspeed;
-			vmmc-supply = <&ab8500_ldo_aux3_reg>;
-
-			cd-gpios  = <&gpio7 6 0x4>; // 230
-			cd-inverted;
-
-			status = "okay";
-		};
-
-
-		// WLAN SDIO channel
-		sdi1_per2 at 80118000 {
-			arm,primecell-periphid = <0x10480180>;
-			max-frequency = <50000000>;
-			bus-width = <4>;
-
-			status = "okay";
-		};
-
-		// On-board eMMC
-		sdi4_per2 at 80114000 {
-			arm,primecell-periphid = <0x10480180>;
-		        max-frequency = <100000000>;
-			bus-width = <8>;
-			mmc-cap-mmc-highspeed;
-			vmmc-supply = <&ab8500_ldo_aux2_reg>;
-
-			status = "okay";
-		};
-	};
-};
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Fri Jul 19 10:20:19 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 19 Jul 2013 10:20:19 -0400 (EDT)
Subject: [PATCH v4 02/17] sched_clock: Use seqcount instead of rolling
 our own
In-Reply-To: <20130719090328.GA18139@mudshark.cambridge.arm.com>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-3-git-send-email-sboyd@codeaurora.org>
 <20130719090328.GA18139@mudshark.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1307191016010.14924@syhkavp.arg>

On Fri, 19 Jul 2013, Will Deacon wrote:

> Looks good to me. The current scheme would be very fiddly to extend to
> 64-bit values on 32-bit architectures without cheap atomic doubleword
> accesses.

You should have a look at include/linux/cnt32_to_63.h.
This could be applied to pure software counters if the low part is 
atomically increased.


Nicolas


From will.deacon at arm.com  Fri Jul 19 10:25:25 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 19 Jul 2013 15:25:25 +0100
Subject: [PATCH 3/4] arm64: KVM: let other tasks run when hitting WFE
In-Reply-To: <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130719142524.GF18139@mudshark.cambridge.arm.com>

On Fri, Jul 19, 2013 at 02:53:54PM +0100, Marc Zyngier wrote:
> So far, when a guest executes WFE (like when waiting for a spinlock
> to become unlocked), we don't do a thing and let it run uninterrupted.
> 
> Another option is to trap a blocking WFE and offer the opportunity
> to the scheduler to switch to another task, potentially giving the
> vcpu holding the spinlock a chance to run sooner.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

[...]

> +static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  {
> -	kvm_vcpu_block(vcpu);
> +	if (kvm_vcpu_get_hsr(vcpu) & 1)
> +		cond_resched();

The hardcoded `1' doesn't make it obvious that we're treating wfi and wfe
differently. Could you use a #define for that bit in hsr.iss please?

Will


From linux at arm.linux.org.uk  Fri Jul 19 10:27:18 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Jul 2013 15:27:18 +0100
Subject: [PATCH v4 02/17] sched_clock: Use seqcount instead of rolling
 our own
In-Reply-To: <alpine.LFD.2.03.1307191016010.14924@syhkavp.arg>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-3-git-send-email-sboyd@codeaurora.org>
 <20130719090328.GA18139@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1307191016010.14924@syhkavp.arg>
Message-ID: <20130719142718.GG24642@n2100.arm.linux.org.uk>

On Fri, Jul 19, 2013 at 10:20:19AM -0400, Nicolas Pitre wrote:
> On Fri, 19 Jul 2013, Will Deacon wrote:
> 
> > Looks good to me. The current scheme would be very fiddly to extend to
> > 64-bit values on 32-bit architectures without cheap atomic doubleword
> > accesses.
> 
> You should have a look at include/linux/cnt32_to_63.h.
> This could be applied to pure software counters if the low part is 
> atomically increased.

But this can't be used for sched_clock().  That's exactly why I originally
had to rewrite that thing in the first place.


From marc.zyngier at arm.com  Fri Jul 19 10:29:45 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Jul 2013 15:29:45 +0100
Subject: [PATCH 3/4] arm64: KVM: let other tasks run when hitting WFE
In-Reply-To: <20130719142524.GF18139@mudshark.cambridge.arm.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
 <20130719142524.GF18139@mudshark.cambridge.arm.com>
Message-ID: <51E94D59.9010607@arm.com>

On 19/07/13 15:25, Will Deacon wrote:
> On Fri, Jul 19, 2013 at 02:53:54PM +0100, Marc Zyngier wrote:
>> So far, when a guest executes WFE (like when waiting for a spinlock
>> to become unlocked), we don't do a thing and let it run uninterrupted.
>>
>> Another option is to trap a blocking WFE and offer the opportunity
>> to the scheduler to switch to another task, potentially giving the
>> vcpu holding the spinlock a chance to run sooner.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> 
> [...]
> 
>> +static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>  {
>> -	kvm_vcpu_block(vcpu);
>> +	if (kvm_vcpu_get_hsr(vcpu) & 1)
>> +		cond_resched();
> 
> The hardcoded `1' doesn't make it obvious that we're treating wfi and wfe
> differently. Could you use a #define for that bit in hsr.iss please?

Good point. I'll rework that part.

	M.
-- 
Jazz is not dead. It just smells funny...



From will.deacon at arm.com  Fri Jul 19 10:32:30 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 19 Jul 2013 15:32:30 +0100
Subject: [PATCH 2/4] arm64: KVM: add missing dsb before invalidating
 Stage-2 TLBs
In-Reply-To: <1374242035-13199-3-git-send-email-marc.zyngier@arm.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-3-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130719143229.GG18139@mudshark.cambridge.arm.com>

On Fri, Jul 19, 2013 at 02:53:53PM +0100, Marc Zyngier wrote:
> When performing a Stage-2 TLB invalidation, it is necessary to
> make sure the write to the page tables is observable by all CPUs.
> 
> For this purpose, add a dsb instruction to __kvm_tlb_flush_vmid_ipa
> before doing the TLB invalidation itself.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/hyp.S | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
> index 218802f..e1ccfcc 100644
> --- a/arch/arm64/kvm/hyp.S
> +++ b/arch/arm64/kvm/hyp.S
> @@ -604,6 +604,8 @@ END(__kvm_vcpu_run)
>  
>  // void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
>  ENTRY(__kvm_tlb_flush_vmid_ipa)
> +	dsb	ishst	// Make sure previous writes are observable
> +
>  	kern_hyp_va	x0
>  	ldr	x2, [x0, #KVM_VTTBR]
>  	msr	vttbr_el2, x2
> -- 
> 1.8.2.3

I don't think the comment adds anything to this code. Also, why don't you
need similar barriers for the cases where you clobber the entire TLB (e.g.
__kvm_flush_vm_context)?

Will


From daniel.lezcano at linaro.org  Fri Jul 19 10:38:54 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 19 Jul 2013 16:38:54 +0200
Subject: [PATCH 06/10] ARM: clps711x: Add CLPS711X clocksource driver
In-Reply-To: <1374172501-26796-7-git-send-email-shc_work@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
 <1374172501-26796-7-git-send-email-shc_work@mail.ru>
Message-ID: <51E94F7E.4030404@linaro.org>

Hi Alex,

(Added Thomas and John in Cc in case they want to review the patch).

On 07/18/2013 08:34 PM, Alexander Shiyan wrote:
> This adds the clocksource driver for Cirrus Logic CLPS711X series SoCs.
> Designed primarily for migration CLPS711X subarch for multiplatform & DT,
> for this as the "OF" and "not-OF" calls implemented.

When a new driver is submitted, I ask for a more detailed changelog
about the driver itself: how it works, any specificities, etc ...

That will help people to understand the code better at least for the review.

> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  arch/arm/Kconfig                      |   2 -
>  drivers/clocksource/Kconfig           |   6 ++
>  drivers/clocksource/Makefile          |   1 +
>  drivers/clocksource/clps711x-clksrc.c | 151 ++++++++++++++++++++++++++++++++++
>  4 files changed, 158 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/clocksource/clps711x-clksrc.c
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index dfb1e7f..5c60cb7 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -370,10 +370,8 @@ config ARCH_CLPS711X
>  	bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
>  	select ARCH_REQUIRE_GPIOLIB
>  	select AUTO_ZRELADDR
> -	select CLKSRC_MMIO
>  	select COMMON_CLK
>  	select CPU_ARM720T
> -	select GENERIC_CLOCKEVENTS
>  	select MFD_SYSCON
>  	select MULTI_IRQ_HANDLER
>  	select SPARSE_IRQ
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index b7b9b04..bd6dc82 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -41,6 +41,12 @@ config VT8500_TIMER
>  config CADENCE_TTC_TIMER
>  	bool
>  
> +config CLKSRC_CLPS711X
> +	def_bool y if ARCH_CLPS711X
> +	select CLKSRC_MMIO
> +	select CLKSRC_OF if OF
> +	select GENERIC_CLOCKEVENTS
> +
>  config CLKSRC_NOMADIK_MTU
>  	bool
>  	depends on (ARCH_NOMADIK || ARCH_U8500)
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index 8b00c5c..da6c102 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_CLKBLD_I8253)	+= i8253.o
>  obj-$(CONFIG_CLKSRC_MMIO)	+= mmio.o
>  obj-$(CONFIG_DW_APB_TIMER)	+= dw_apb_timer.o
>  obj-$(CONFIG_DW_APB_TIMER_OF)	+= dw_apb_timer_of.o
> +obj-$(CONFIG_CLKSRC_CLPS711X)	+= clps711x-clksrc.o
>  obj-$(CONFIG_CLKSRC_NOMADIK_MTU)	+= nomadik-mtu.o
>  obj-$(CONFIG_CLKSRC_DBX500_PRCMU)	+= clksrc-dbx500-prcmu.o
>  obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
> diff --git a/drivers/clocksource/clps711x-clksrc.c b/drivers/clocksource/clps711x-clksrc.c
> new file mode 100644
> index 0000000..1749b0b
> --- /dev/null
> +++ b/drivers/clocksource/clps711x-clksrc.c
> @@ -0,0 +1,151 @@
> +/*
> + *  CLPS711X clocksource driver
> + *
> + *  Copyright (C) 2013 Alexander Shiyan <shc_work at mail.ru>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clockchips.h>
> +#include <linux/clocksource.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/io.h>
> +#include <linux/ioport.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/sched_clock.h>
> +#include <linux/slab.h>
> +
> +#include <linux/mfd/syscon/clps711x.h>
> +
> +#define CLPS711X_SYSCON1	(0x0100)
> +#define CLPS711X_TC1D		(0x0300)
> +#define CLPS711X_TC2D		(0x0340)

Alignment.

> +
> +static struct {
> +	void __iomem	*tc1d;
> +	int		irq;
> +} *clps711x_clksrc;

You don't need to define this structure, the struct clock_event_device
already contains a field with irq.

> +static u32 notrace clps711x_sched_clock_read(void)
> +{
> +	return ~readw(clps711x_clksrc->tc1d);
> +}
> +
> +static void clps711x_clockevent_set_mode(enum clock_event_mode mode,
> +					 struct clock_event_device *evt)
> +{
> +	disable_irq(clps711x_clksrc->irq);

Do you really need to disable the interrupt to re-enable it right after ?

> +> +	switch (mode) {
> +	case CLOCK_EVT_MODE_PERIODIC:
> +		enable_irq(clps711x_clksrc->irq);
> +		break;
> +	case CLOCK_EVT_MODE_ONESHOT:
> +		/* Not supported */
> +	case CLOCK_EVT_MODE_SHUTDOWN:
> +	case CLOCK_EVT_MODE_UNUSED:
> +	case CLOCK_EVT_MODE_RESUME:
> +		/* Left event sources disabled, no more interrupts appear */
> +		break;
> +	}
> +}

I am not expert in interrupts, but it is possible this interrupt could
be shared ?

There isn't a register to enable/disable the timer ?

> +
> +static struct clock_event_device clps711x_clockevent = {
> +	.name		= "clps711x-clockevent",
> +	.rating		= 300,
> +	.features	= CLOCK_EVT_FEAT_PERIODIC,
> +	.set_mode	= clps711x_clockevent_set_mode,
> +};
> +
> +static irqreturn_t clps711x_timer_interrupt(int irq, void *dev_id)
> +{
> +	clps711x_clockevent.event_handler(&clps711x_clockevent);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static struct irqaction clps711x_timer_irq = {
> +	.name		= "clps711x-timer",
> +	.flags		= IRQF_TIMER | IRQF_IRQPOLL,

Why do you need IRQF_IRQPOOL ?

> +	.handler	= clps711x_timer_interrupt,
> +};
> +
> +static void __init _clps711x_clksrc_init(phys_addr_t phys_base, int irq,
> +					 struct clk *tc1, struct clk *tc2)
> +{
> +	unsigned long tc1_rate, tc2_rate;
> +	void __iomem *tc2d, *syscon1;
> +	u32 tmp;
> +
> +	BUG_ON(IS_ERR(tc1) || IS_ERR(tc2));
> +
> +	BUG_ON(!request_mem_region(phys_base + CLPS711X_TC1D, SZ_2, NULL));
> +	BUG_ON(!request_mem_region(phys_base + CLPS711X_TC2D, SZ_2, NULL));
> +
> +	clps711x_clksrc = kzalloc(sizeof(*clps711x_clksrc), GFP_KERNEL);
> +	BUG_ON(!clps711x_clksrc);
> +
> +	clps711x_clksrc->tc1d = ioremap(phys_base + CLPS711X_TC1D, SZ_2);
> +	BUG_ON(!clps711x_clksrc->tc1d);
> +
> +	tc2d = ioremap(phys_base + CLPS711X_TC2D, SZ_2);
> +	BUG_ON(!tc2d);
> +
> +	syscon1 = ioremap(phys_base + CLPS711X_SYSCON1, SZ_4);
> +	BUG_ON(!syscon1);
> +
> +	clps711x_clksrc->irq = irq;

	clps711x_clockevent.irq = irq;

	clps711x_clockevent.cpumask = ?

> +	tmp = readl(syscon1);
> +	/* TC1 in free running mode */
> +	tmp &= ~SYSCON1_TC1M;
> +	/* TC2 in prescale mode */
> +	tmp |= SYSCON1_TC2M;
> +	writel(tmp, syscon1);

Could you encapsulate these calls inside a static inline function with a
more detailed comment please ?

> +
> +	tc1_rate = clk_get_rate(tc1);
> +	tc2_rate = clk_get_rate(tc2);
> +
> +	clocksource_mmio_init(clps711x_clksrc->tc1d, "clps711x-clocksource",
> +			      tc1_rate, 300, 16, clocksource_mmio_readw_down);
> +
> +	setup_sched_clock(clps711x_sched_clock_read, 16, tc1_rate);
> +
> +	/* Set Timer prescaler */
> +	writew(DIV_ROUND_CLOSEST(tc2_rate, HZ), tc2d);
> +
> +	clockevents_config_and_register(&clps711x_clockevent, tc2_rate, 0, 0);
> +
> +	BUG_ON(setup_irq(clps711x_clksrc->irq, &clps711x_timer_irq));
> +}
> +
> +void __init clps711x_clksrc_init(phys_addr_t phys_base, int irq)

Is this function called somewhere ? I don't see the function definition ?

> +{
> +	struct clk *tc1 = clk_get(NULL, "tc1");
> +	struct clk *tc2 = clk_get(NULL, "tc2");
> +
> +	_clps711x_clksrc_init(phys_base, irq, tc1, tc2);
> +}
> +
> +#ifdef CONFIG_CLKSRC_OF
> +static void __init clps711x_clksrc_init_dt(struct device_node *np)
> +{
> +	struct clk *tc1 = of_clk_get_by_name(np, "tc1");
> +	struct clk *tc2 = of_clk_get_by_name(np, "tc2");
> +	struct resource res_io, res_irq;
> +
> +	BUG_ON(!of_address_to_resource(np, 0, &res_io));
> +
> +	BUG_ON(!of_irq_to_resource(np, 0, &res_irq));
> +
> +	_clps711x_clksrc_init(res_io.start, res_irq.start, tc1, tc2);
> +}
> +CLOCKSOURCE_OF_DECLARE(clps711x, "cirrus,clps711x-clocksource",
> +		       clps711x_clksrc_init_dt);
> +#endif
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From sergei.shtylyov at cogentembedded.com  Fri Jul 19 10:39:19 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 19 Jul 2013 18:39:19 +0400
Subject: [PATCH v6 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <1374226039-16943-2-git-send-email-oleksandr.kozaruk@ti.com>
References: <1374226039-16943-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1374226039-16943-2-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <51E94F97.40002@cogentembedded.com>

Hello.

On 19-07-2013 13:27, Oleksandr Kozaruk wrote:

> GPADC is the general purpose ADC present on twl6030.
> The dt data is interrupt used to trigger end of ADC
> conversion.

> Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
> ---
>   arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
>   1 file changed, 6 insertions(+)

> diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
> index 2e3bd31..d7d4c28 100644
> --- a/arch/arm/boot/dts/twl6030.dtsi
> +++ b/arch/arm/boot/dts/twl6030.dtsi
> @@ -103,4 +103,10 @@
>   		compatible = "ti,twl6030-pwmled";
>   		#pwm-cells = <2>;
>   	};
> +
> +	adc: gpadc {

    Read my lips: the node should be called just "adc", not "gpadc".

WBR, Sergei



From nsekhar at ti.com  Fri Jul 19 10:50:11 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 19 Jul 2013 20:20:11 +0530
Subject: [PATCH v3 2/5] ARM: davinci: da850: override device name of UART
 in DT kernel
In-Reply-To: <1371633342-1210-3-git-send-email-prakash.pm@ti.com>
References: <1371633342-1210-1-git-send-email-prakash.pm@ti.com>
 <1371633342-1210-3-git-send-email-prakash.pm@ti.com>
Message-ID: <51E95223.30704@ti.com>

On Wednesday 19 June 2013 02:45 PM, Manjunathappa, Prakash wrote:
> Populate OF_DEV_AUXDATA with desired device name so as to prevent
> clk_get failures.

This can be folded into 1/5 itself.

Thanks,
Sekhar



From ben.dooks at codethink.co.uk  Fri Jul 19 10:50:12 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Fri, 19 Jul 2013 15:50:12 +0100
Subject: alignment handler instruction endian-ness
In-Reply-To: <20130719140513.GF24642@n2100.arm.linux.org.uk>
References: <51E91BE5.8070809@codethink.co.uk>
 <20130719110947.GD24642@n2100.arm.linux.org.uk>
 <1374242462.3406.59.camel@linaro1.home>
 <20130719140513.GF24642@n2100.arm.linux.org.uk>
Message-ID: <51E95224.9010306@codethink.co.uk>

On 19/07/13 15:05, Russell King - ARM Linux wrote:
> On Fri, Jul 19, 2013 at 03:01:02PM +0100, Jon Medhurst (Tixy) wrote:
>> On Fri, 2013-07-19 at 12:09 +0100, Russell King - ARM Linux wrote:
>>> On Fri, Jul 19, 2013 at 11:58:45AM +0100, Ben Dooks wrote:
>>>> I ran in to an issue with the alignment handler when running BE8 where
>>>> it loads instructions and fails to swap.
>>>>
>>>> Is there a better way of swapping instructions for ARM when loading
>>>> from arbitrary places? Have I missed any other places this could happen?
>>>
>>> Maybe we need a macro which deals with this automatically?
>>
>> Like the stuff in arch/arm/include/asm/opcodes.h ?
>
> Not like asm/opcodes.h does at the moment, because there's really no
> reason whatsoever that it isn't using the standard swab stuff, which
> will automatically use the rev/rev16 instructions where available.
>
> There's really no reason to open code that stuff.

It seems it is only open coded for the __ASSEMBLY__ version,
it does use swabXX() for the !__ASSEMBLY__ case.

Should we use __mem_to_opcode_arm() in the aligned and abort
handlers?

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From marc.zyngier at arm.com  Fri Jul 19 10:53:28 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Jul 2013 15:53:28 +0100
Subject: [PATCH 2/4] arm64: KVM: add missing dsb before invalidating
 Stage-2 TLBs
In-Reply-To: <20130719143229.GG18139@mudshark.cambridge.arm.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-3-git-send-email-marc.zyngier@arm.com>
 <20130719143229.GG18139@mudshark.cambridge.arm.com>
Message-ID: <51E952E8.6020503@arm.com>

On 19/07/13 15:32, Will Deacon wrote:
> On Fri, Jul 19, 2013 at 02:53:53PM +0100, Marc Zyngier wrote:
>> When performing a Stage-2 TLB invalidation, it is necessary to
>> make sure the write to the page tables is observable by all CPUs.
>>
>> For this purpose, add a dsb instruction to __kvm_tlb_flush_vmid_ipa
>> before doing the TLB invalidation itself.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kvm/hyp.S | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
>> index 218802f..e1ccfcc 100644
>> --- a/arch/arm64/kvm/hyp.S
>> +++ b/arch/arm64/kvm/hyp.S
>> @@ -604,6 +604,8 @@ END(__kvm_vcpu_run)
>>  
>>  // void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
>>  ENTRY(__kvm_tlb_flush_vmid_ipa)
>> +	dsb	ishst	// Make sure previous writes are observable
>> +
>>  	kern_hyp_va	x0
>>  	ldr	x2, [x0, #KVM_VTTBR]
>>  	msr	vttbr_el2, x2
>> -- 
>> 1.8.2.3
> 
> I don't think the comment adds anything to this code. Also, why don't you
> need similar barriers for the cases where you clobber the entire TLB (e.g.
> __kvm_flush_vm_context)?

I think they are required as well. I'll respin the patch.

	M.
-- 
Jazz is not dead. It just smells funny...



From linux at arm.linux.org.uk  Fri Jul 19 10:56:35 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Jul 2013 15:56:35 +0100
Subject: alignment handler instruction endian-ness
In-Reply-To: <51E95224.9010306@codethink.co.uk>
References: <51E91BE5.8070809@codethink.co.uk>
 <20130719110947.GD24642@n2100.arm.linux.org.uk>
 <1374242462.3406.59.camel@linaro1.home>
 <20130719140513.GF24642@n2100.arm.linux.org.uk>
 <51E95224.9010306@codethink.co.uk>
Message-ID: <20130719145634.GH24642@n2100.arm.linux.org.uk>

On Fri, Jul 19, 2013 at 03:50:12PM +0100, Ben Dooks wrote:
> Should we use __mem_to_opcode_arm() in the aligned and abort
> handlers?

I think so.


From lars at metafoo.de  Fri Jul 19 11:08:12 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Fri, 19 Jul 2013 17:08:12 +0200
Subject: [alsa-devel] [PATCH 1/6] ASoC: sirf: add sirf platform driver
 which provides DMA
In-Reply-To: <1374232042-26088-2-git-send-email-Baohua.Song@csr.com>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
 <1374232042-26088-2-git-send-email-Baohua.Song@csr.com>
Message-ID: <51E9565C.8020308@metafoo.de>

On 07/19/2013 01:07 PM, Barry Song wrote:
> From: Rongjun Ying <Rongjun.Ying at csr.com>
> 
> this driver uses dmaengine APIs and provides DMA to the CPU DAIs
> of I2S, USP and SiRF-soc-inner.
> SiRFSoC has 3 audio DAIs: I2S, USP(Universal Serial Ports) and DAI
> connected to soc-inner-codec, all of them will use the same DMA
> driver here.
> 

I think the bulk of the code here can be replaced by using the generic
dmaengine PCM driver. Have a look at e.g. mxs to see how that is done.

[...]
> +
> +static int sirf_pcm_open(struct snd_pcm_substream *substream)
> +{
> +	struct snd_soc_pcm_runtime *rtd = substream->private_data;
> +	struct sirf_pcm_dma_data *dma_data;
> +	substream->runtime->hw = sirf_pcm_hardware;
> +	snd_soc_set_runtime_hwparams(substream, &sirf_pcm_hardware);
> +
> +	dma_data = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
> +
> +	return snd_dmaengine_pcm_open_request_chan(substream,
> +			(dma_filter_fn)sirfsoc_dma_filter_id,
> +			(void *)(dma_data->dma_req));

Since you are using devicetree on this platform use the devicetree to get a
handle to the DMA channel.

> +}
> +
> +static int sirf_pcm_hw_params(struct snd_pcm_substream *substream,
> +		struct snd_pcm_hw_params *params)
> +{
> +	struct snd_pcm_runtime *runtime = substream->runtime;
> +	struct snd_soc_pcm_runtime *rtd = substream->private_data;
> +	struct sirf_pcm_dma_data *dma_data;
> +	struct dma_slave_config config;
> +	struct dma_chan *chan;
> +	int err = 0;
> +
> +	dma_data = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
> +
> +	snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer);
> +	runtime->dma_bytes = params_buffer_bytes(params);
> +
> +	chan = snd_dmaengine_pcm_get_chan(substream);
> +	if (!chan)
> +		return -EINVAL;
> +
> +	/* fills in addr_width and direction */
> +	err = snd_hwparams_to_dma_slave_config(substream, params, &config);
> +	if (err)
> +		return err;
> +
> +	config.dst_addr_width = DMA_SLAVE_BUSWIDTH_8_BYTES;
> +	config.src_addr_width = DMA_SLAVE_BUSWIDTH_8_BYTES;
> +
> +	config.src_addr = runtime->dma_addr;
> +	config.dst_addr = runtime->dma_addr;
> +	config.src_maxburst = DMA_SLAVE_BUSWIDTH_8_BYTES;
> +	config.dst_maxburst = DMA_SLAVE_BUSWIDTH_8_BYTES;
> +
> +	return dmaengine_slave_config(chan, &config);


Nothing special in here, just use the generic
snd_dmaengine_pcm_prepare_slave_config().

> +}
> +
[...]

static const struct of_device_id sirf_pcm_of_match[] = {
> +	{ .compatible = "sirf,pcm-audio", },
> +	{}
> +};

Since this is not a separate piece of hardware, but just the glue logic
between the DMA controller and the audio DAI it should not have it's own
devicetree node. Usually the the PCM device is registered by the DAI driver.
Again take at other platforms using the generic dmaengine PCM driver for
examples.

> +MODULE_DEVICE_TABLE(of, sirf_pcm_of_match);
> +
> +static struct platform_driver sirf_pcm_driver = {
> +	.driver = {
> +		.name = "sirf-pcm-audio",
> +		.owner = THIS_MODULE,
> +		.of_match_table = sirf_pcm_of_match,
> +	},
> +	.probe = sirf_pcm_probe,
> +	.remove = sirf_pcm_remove,
> +};
> +module_platform_driver(sirf_pcm_driver);
[...]



From swarren at wwwdotorg.org  Fri Jul 19 11:18:36 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 19 Jul 2013 09:18:36 -0600
Subject: [PATCH] ARM: kexec: validate CPU hotplug support
In-Reply-To: <1373582931-11956-1-git-send-email-swarren@wwwdotorg.org>
References: <1373582931-11956-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <51E958CC.5070906@wwwdotorg.org>

On 07/11/2013 04:48 PM, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> Architectures should fully validate whether kexec is possible as part of
> machine_kexec_prepare(), so that user-space's kexec_load() operation can
> report any problems. Performing validation in machine_kexec() itself is
> too late, since it is not allowed to return.
> 
> Prior to this patch, ARM's machine_kexec() was testing after-the-fact
> whether machine_kexec_prepare() was able to disable all but one CPU.
> Instead, modify machine_kexec_prepare() to validate all conditions
> necessary for machine_kexec_prepare()'s to succeed. BUG if the validation
> succeeded, yet disabling the CPUs didn't actually work.

Russell, does this look good to put into the ARM patch tracker?


From stern at rowland.harvard.edu  Fri Jul 19 11:26:56 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Fri, 19 Jul 2013 11:26:56 -0400 (EDT)
Subject: [PATCH] [RFC] EHCI: add to memory barrier to updating hw_next
In-Reply-To: <003101ce846d$1a74ffa0$4f5efee0$@lge.com>
Message-ID: <Pine.LNX.4.44L0.1307191119550.1055-100000@iolanthe.rowland.org>

On Fri, 19 Jul 2013, Gioh Kim wrote:

> > I was going to ask the same question.  This particular piece of code gets
> > executed _only_ when an URB is unlinked.  Not during any other kind of
> > error.
> 
> 
> I've got the problem when I listened to the mp3 file of USB HDD.
> I checked the urb data when the problem occurred, the last-status value of
> urb was EINPROGRESS and 
> urb->unlinked was ECONNRESET. 

Ah, so the URB _was_ unlinked.

> I think the 'stopped' case was occurred by the reset of USB port.
> The block device driver did reset USB port because there is no return from
> USB device.

Okay.

> If I made block device driver could not reset USB port, the EHCI driver
> codes were not executed.
> Finally the halt of HC makes 'stopped' case.

Why was the HC halted?  That should happen only when there is an 
extremely severe error.

> I think halt of the HC might be caused that store-buffer delays command for
> HC.
> When I applied the patch from https://lkml.org/lkml/2011/8/31/344 and added
> a mb() into hw_next updating
> to remove delay of store-buffer, My platform works well.
> 
> Can the store-buffer delay halt HC? Is it possible?

I don't see how.  It could slow things down but it should not cause any 
errors.

> IMHO, if the qTD list is broken the HC think there is no qTD to send.
> So I added mb() at hw_next update code.

At the time when the hw_next update gets executed, what is the value of 
"state"?  It should be QH_STATE_IDLE.

Alan Stern



From swarren at wwwdotorg.org  Fri Jul 19 11:33:09 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 19 Jul 2013 09:33:09 -0600
Subject: [PATCH V3 RFT] ARM: tegra: enable palmas device for dalmore
In-Reply-To: <1374199992-27947-1-git-send-email-ldewangan@nvidia.com>
References: <1374199992-27947-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <51E95C35.7060502@wwwdotorg.org>

On 07/18/2013 08:13 PM, Laxman Dewangan wrote:
> Make the entry of Dalmore Power Management Unit device TPS65913
> in dalmore DTS file. The Palma driver support this device.
> 
> Enable following submodule of the TPS65913:
> - GPIO driver
> - RTC driver.
> - Power regulator driver.

OK, this version works fine. Applied to Tegra's for-3.12/dt branch.

> Changes from V2:
> - Made LDO9 as always ON for sd card functionality.

We really need to start hooking up the regulators to the SDHCI
controller nodes sometime soon... I let it slide here because it's at
least consistent with the regulators we already have in place on other
boards.


From grygorii.strashko at ti.com  Fri Jul 19 11:40:27 2013
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Fri, 19 Jul 2013 18:40:27 +0300
Subject: [PATCH v6 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <51E94F97.40002@cogentembedded.com>
References: <1374226039-16943-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1374226039-16943-2-git-send-email-oleksandr.kozaruk@ti.com>
 <51E94F97.40002@cogentembedded.com>
Message-ID: <51E95DEB.7010702@ti.com>

On 07/19/2013 05:39 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 19-07-2013 13:27, Oleksandr Kozaruk wrote:
>
>> GPADC is the general purpose ADC present on twl6030.
>> The dt data is interrupt used to trigger end of ADC
>> conversion.
>
>> Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
>> ---
>>   arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
>>   1 file changed, 6 insertions(+)
>
>> diff --git a/arch/arm/boot/dts/twl6030.dtsi
>> b/arch/arm/boot/dts/twl6030.dtsi
>> index 2e3bd31..d7d4c28 100644
>> --- a/arch/arm/boot/dts/twl6030.dtsi
>> +++ b/arch/arm/boot/dts/twl6030.dtsi
>> @@ -103,4 +103,10 @@
>>           compatible = "ti,twl6030-pwmled";
>>           #pwm-cells = <2>;
>>       };
>> +
>> +    adc: gpadc {
>
>     Read my lips: the node should be called just "adc", not "gpadc".
       ^^^^^^^^^^^^ Are you sure?

Why? The name was selected according to the documentation on device 
"General purpose analog-to-digital converter (GPADC)".

PS. Following your logic - "GPIO" need to renamed to "IO" everywhere ;P

>
> WBR, Sergei
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Regards,
- grygorii


From swarren at wwwdotorg.org  Fri Jul 19 11:45:20 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 19 Jul 2013 09:45:20 -0600
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <20130719032328.GB20889@S2101-09.ap.freescale.net>
References: <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <20130716041056.GA30067@S2101-09.ap.freescale.net>
 <51E56AA7.7020103@wwwdotorg.org>
 <20130717030246.GA4541@S2101-09.ap.freescale.net>
 <51E6CCE4.20705@wwwdotorg.org> <20130717213836.GA13324@amd.pavel.ucw.cz>
 <51E719A6.6070105@wwwdotorg.org> <20130718112555.GB1021@amd.pavel.ucw.cz>
 <CAOesGMgi0j_mPyeBLVHb_QW+DwtAPoFY697eQO3-yp9tnP1vmA@mail.gmail.com>
 <20130719032328.GB20889@S2101-09.ap.freescale.net>
Message-ID: <51E95F10.5070006@wwwdotorg.org>

On 07/18/2013 09:23 PM, Shawn Guo wrote:
> On Thu, Jul 18, 2013 at 11:45:29AM -0700, Olof Johansson wrote:
...
>> You're spending an awful lot of energy arguing over this, but nobody
>> has actually shown data of how much deferral is happening -- and that
>> it's a real problem. Until someone does so there's no reason to change
>> it from the default module init level at all, I'd say.
> 
> On imx6qdl-sabreauto board, there are 3 MAX7310 units as IO expanders to
> output 3 x 8 = 24 GPIOs.  18 of them are used for resets, enables and
> pin steering for various peripherals on the board.
> 
>   BACKLITE_ON
>   SAT_SHUTDN_B
>   CPU_PER_RST_B
>   MAIN_PER_RST_B
>   IPOD_RST_B
>   MLB_RST_B
>   SSI_STEERING
>   GPS_RST_B
>   
>   GPS_PWREN
>   VIDEO_ADC_PWRDN_B
>   ENET_CAN1_STEER
>   EIMD30_BTUART3_STEER
>   CAN_STBY
>   CAN_EN
>   USB_H1_PWR
>   
>   USB_OTG_PWR_ON
>   SAT_RST_B
>   NAND_BT_WIFI_STEER
> 
> Most of these GPIOs need to set up properly at client device driver's
> probe stage - module_init() time.  So if we have all these service
> providers resets/enables/steering API registered at module_init() too,
> the probes of all these client device drivers stand a good chance to be
> deferred.

That sounds like it /could/ well be an issue. Do you have all that
actually hooked up through device tree so you can demonstrate the amount
of deferred probing that /actually/ happens though?

In order to push the probe order in the right direction, I would
personally prefer to see some kind of explicit hinting or outright
representation of probe order in the DT.

If we fiddle with initcall levels to do this, (a) it won't always work;
what may be optimal for one board/SoC may not be optimal for another,
and with multi-platform kernels, we have to take a broader view, (b) the
only beneficiary is Linux; if we add information to DT for this, every
OS could benefit in the same way.

My view is that when one HW object depends on another (e.g. it's reset
by some other module, sends an interrupt to another module, is affected
by a pin controller module, etc.), that really is a HW issue, and hence
is appropriate to represent in device tree.

In fact, we already do represent the dependencies in device tree; e.g. a
foo-gpios/foo-reset/... property already indicates this. The issue is
that there's no standard naming/structure across all types of DT binding
(GPIO, reset, ...), and hence the only way to parse these dependencies
is to do exactly what deferred probe is doing; try probing each driver,
which then encompasses all device-specific and subsystem-specific naming
and DT structure in its actions, and if it fails, then defer probe.

If we had some explicit information re: dependencies in the DT, in an
entirely standard format, perhaps the device core or similar could parse
this and not even attempt probe until the relevant devices had completed
probe. If the information turned out to be bogus (e.g. loops, missing
drivers), we could always fall back to pure deferred probe later in the
boot sequence.

Or perhaps we should revisit whether DT node order should be defined as
having a guaranteed influence on probe order. We could enforce that the
source order has no influence, but then run a post-processing tool that
finds all the dependencies from the phandles in the DT, and then
re-sorts the DTB to get the probing order right? That would probably
require every single driver to be module_initcall, or to ignore driver
registration order and only probe devices in the order they appear in DT.


From swarren at wwwdotorg.org  Fri Jul 19 11:54:29 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 19 Jul 2013 09:54:29 -0600
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51E8DE51.1060404@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-2-git-send-email-kishon@ti.com>
 <20130718072004.GA16720@kroah.com> <51E7AE88.3050007@ti.com>
 <20130718154954.GA31961@kroah.com> <51E8D086.809@ti.com>
 <20130719054311.GA14638@kroah.com> <51E8D4E0.8060200@ti.com>
 <20130719062941.GA23611@kroah.com> <51E8DE51.1060404@ti.com>
Message-ID: <51E96135.9090108@wwwdotorg.org>

On 07/19/2013 12:36 AM, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Friday 19 July 2013 11:59 AM, Greg KH wrote:
>> On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On Friday 19 July 2013 11:13 AM, Greg KH wrote:
>>>> On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote:
>>>>>>>>> +	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
>>>>>>>>
>>>>>>>> Your naming is odd, no "phy" anywhere in it?  You rely on the sender to
>>>>>>>> never send a duplicate name.id pair?  Why not create your own ids based
>>>>>>>> on the number of phys in the system, like almost all other classes and
>>>>>>>> subsystems do?
>>>>>>>
>>>>>>> hmm.. some PHY drivers use the id they provide to perform some of their
>>>>>>> internal operation as in [1] (This is used only if a single PHY provider
>>>>>>> implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO
>>>>>>> to give the PHY drivers an option to use auto id.
>>>>>>>
>>>>>>> [1] ->
>>>>>>> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
>>>>>>
>>>>>> No, who cares about the id?  No one outside of the phy core ever should,
>>>>>> because you pass back the only pointer that they really do care about,
>>>>>> if they need to do anything with the device.  Use that, and then you can
>>>>>
>>>>> hmm.. ok.
>>>>>
>>>>>> rip out all of the "search for a phy by a string" logic, as that's not
>>>>>
>>>>> Actually this is needed for non-dt boot case. In the case of dt boot, we use a
>>>>> phandle by which the controller can get a reference to the phy. But in the case
>>>>> of non-dt boot, the controller can get a reference to the phy only by label.
>>>>
>>>> I don't understand.  They registered the phy, and got back a pointer to
>>>> it.  Why can't they save it in their local structure to use it again
>>>> later if needed?  They should never have to "ask" for the device, as the
>>>
>>> One is a *PHY provider* driver which is a driver for some PHY device. This will
>>> use phy_create to create the phy.
>>> The other is a *PHY consumer* driver which might be any controller driver (can
>>> be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference to the
>>> phy (by *phandle* in the case of dt boot and *label* in the case of non-dt boot).
>>>> device id might be unknown if there are multiple devices in the system.
>>>
>>> I agree with you on the device id part. That need not be known to the PHY driver.
>>
>> How does a consumer know which "label" to use in a non-dt system if
>> there are multiple PHYs in the system?
> 
> That should be passed using platform data.

I don't think that's right. That's just like passing clock names in
platform data, which I believe is frowned upon.

Instead, why not take the approach that e.g. regulators have taken? Each
driver defines the names of the objects that it requires. There is a
table (registered by a board file) that has lookup key (device name,
regulator name), and the output is the regulator device (or global
regulator name).

This is almost the same way that DT works, except that in DT, the table
is represented as properties in the DT. The DT binding defines the names
of those properties, or the strings that must be in the foo-names
properties, just like a driver in non-DT Linux is going to define the
names it expects to be provided with.

That way, you don't need platform data to define the names.


From b.zolnierkie at samsung.com  Fri Jul 19 12:03:01 2013
From: b.zolnierkie at samsung.com (Bartlomiej Zolnierkiewicz)
Date: Fri, 19 Jul 2013 18:03:01 +0200
Subject: [PATCH 2/4] ARM: exynos: cpuidle: Use the common cpuidle register
 routine
In-Reply-To: <1374152070-21008-2-git-send-email-daniel.lezcano@linaro.org>
References: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
 <1374152070-21008-2-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <4097491.3y6BBYmzze@amdc1032>


Hi,

On Thursday, July 18, 2013 02:54:28 PM Daniel Lezcano wrote:
> Now we have the same routine than the one handled by the cpuidle framework.

Small nitpick:

To be exact the routine is not the same, on error cpuidle_register() does
complete unregister operation of the cpuidle driver, exynos4_init_cpuidle()
just stops the registration procedure. 

The change itself is okay but the patch description could be better.

Anyway all patches (#1-4) look fine to me. Thanks for this work.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
 
> Let's use it.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  arch/arm/mach-exynos/cpuidle.c |   24 +-----------------------
>  1 file changed, 1 insertion(+), 23 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
> index cc4b097..d8fc1a2 100644
> --- a/arch/arm/mach-exynos/cpuidle.c
> +++ b/arch/arm/mach-exynos/cpuidle.c
> @@ -41,8 +41,6 @@ static int exynos4_enter_lowpower(struct cpuidle_device *dev,
>  				struct cpuidle_driver *drv,
>  				int index);
>  
> -static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
> -
>  static struct cpuidle_driver exynos4_idle_driver = {
>  	.name			= "exynos4_idle",
>  	.owner			= THIS_MODULE,
> @@ -188,29 +186,9 @@ static void __init exynos5_core_down_clk(void)
>  
>  static int __init exynos4_init_cpuidle(void)
>  {
> -	int cpu_id, ret;
> -	struct cpuidle_device *device;
> -
>  	if (soc_is_exynos5250())
>  		exynos5_core_down_clk();
>  
> -	ret = cpuidle_register_driver(&exynos4_idle_driver);
> -	if (ret) {
> -		printk(KERN_ERR "CPUidle failed to register driver\n");
> -		return ret;
> -	}
> -
> -	for_each_online_cpu(cpu_id) {
> -		device = &per_cpu(exynos4_cpuidle_device, cpu_id);
> -		device->cpu = cpu_id;
> -
> -		ret = cpuidle_register_device(device);
> -		if (ret) {
> -			printk(KERN_ERR "CPUidle register device failed\n");
> -			return ret;
> -		}
> -	}
> -
> -	return 0;
> +	return cpuidle_register(&exynos4_idle_driver, NULL);
>  }
>  device_initcall(exynos4_init_cpuidle);



From catalin.marinas at arm.com  Fri Jul 19 12:03:50 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Jul 2013 17:03:50 +0100
Subject: [GIT PULL] arm64 fixes for 3.11-rc2
Message-ID: <20130719160336.GA22565@arm.com>

Hi Linus,

Please pull the arm64 fixes below. Thanks.

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git tags/arm64-stable

for you to fetch changes up to ff701306cd49aaff80fb852323b387812bc76491:

  arm64: use common reboot infrastructure (2013-07-19 15:57:08 +0100)

----------------------------------------------------------------
- Post -rc1 update to the common reboot infrastructure.
- Fixes (user cache maintenance fault handling, !COMPAT compilation, CPU
  online and interrupt hanlding).

----------------------------------------------------------------
Catalin Marinas (1):
      arm64: Only enable local interrupts after the CPU is marked online

Chen Gang (1):
      arm64: add '#ifdef CONFIG_COMPAT' for aarch32_break_handler()

Marc Zyngier (1):
      arm64: use common reboot infrastructure

Will Deacon (1):
      arm64: mm: don't treat user cache maintenance faults as writes

 arch/arm64/include/asm/debug-monitors.h |  7 -----
 arch/arm64/include/asm/system_misc.h    |  3 ++-
 arch/arm64/kernel/process.c             |  2 +-
 arch/arm64/kernel/smp.c                 | 15 ++++++-----
 arch/arm64/mm/fault.c                   | 46 ++++++++++++++-------------------
 5 files changed, 31 insertions(+), 42 deletions(-)

-- 
Catalin


From broonie at kernel.org  Fri Jul 19 12:12:52 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 19 Jul 2013 17:12:52 +0100
Subject: [PATCH 1/6] ASoC: sirf: add sirf platform driver which provides
 DMA
In-Reply-To: <1374232042-26088-2-git-send-email-Baohua.Song@csr.com>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
 <1374232042-26088-2-git-send-email-Baohua.Song@csr.com>
Message-ID: <20130719161252.GK9858@sirena.org.uk>

On Fri, Jul 19, 2013 at 07:07:17PM +0800, Barry Song wrote:

> index 0000000..3678aed
> --- /dev/null
> +++ b/sound/soc/sirf/Kconfig
> @@ -0,0 +1,4 @@
> +config SND_SIRF_SOC
> +	tristate "Platform DMA driver for the SiRF SoC chips"
> +	depends on ARCH_SIRF && SND_SOC
> +	select SND_SOC_DMAENGINE_PCM

Does this have any actual platform build dependencies or can this be
ARCH_SIRF || COMPILE_TEST?
-------------- 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/20130719/9274cadb/attachment.sig>

From fweisbec at gmail.com  Fri Jul 19 12:17:10 2013
From: fweisbec at gmail.com (Frederic Weisbecker)
Date: Fri, 19 Jul 2013 18:17:10 +0200
Subject: [PATCH 3/3] ARM: Kconfig: allow virt CPU accounting
In-Reply-To: <1372876601-23881-4-git-send-email-khilman@linaro.org>
References: <1372876601-23881-1-git-send-email-khilman@linaro.org>
 <1372876601-23881-4-git-send-email-khilman@linaro.org>
Message-ID: <20130719161708.GB21752@somewhere>

On Wed, Jul 03, 2013 at 11:36:41AM -0700, Kevin Hilman wrote:
> With the 64-bit requirement removed from virt CPU accounting,
> allow ARM platforms to enable it.
> 
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> Signed-off-by: Kevin Hilman <khilman at linaro.org>
> ---
>  arch/arm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 136f263..7850612 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -61,6 +61,7 @@ config ARM
>  	select OLD_SIGSUSPEND3
>  	select OLD_SIGACTION
>  	select HAVE_CONTEXT_TRACKING
> +	select HAVE_VIRT_CPU_ACCOUNTING

I think you got confused here. HAVE_VIRT_CPU_ACCOUNTING is the arch capability
for VIRT_CPU_ACCOUNTING_NATIVE, not for VIRT_CPU_ACCOUNTING_GEN that only requires
support for context tracking.

That's my bad, all those names start to be confusing now.
The VIRT based Kconfig naming is a bit weird, that doesn't really reflect what the feature
is doing. "Virtual cputime accounting" just doesn't give any clue, except perhaps suggesting
the stuff deals with virtualization while it actually has nothing to do with.
I don't even know what virtual refers to here.

Same goes for vtime based APIs. In fact I just based my work on the legacy that was
there and expanded further the non-sense ;-)

I'll need to do a big renaming one day.

But to begin with I should rename s/HAVE_VIRT_CPU_ACCOUNTING/HAVE_VIRT_CPU_ACCOUNTING_NATIVE.



>  	help
>  	  The ARM series is a line of low-power-consumption RISC chip designs
>  	  licensed by ARM Ltd and targeted at embedded applications and
> -- 
> 1.8.3
> 


From plagnioj at jcrosoft.com  Fri Jul 19 12:25:36 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Fri, 19 Jul 2013 18:25:36 +0200
Subject: [PATCH RESEND 1/2] ARM: mmp: Add compatible entries for OLPC XO
 laptops
In-Reply-To: <20130716180605.A63C7FAAF3@dev.laptop.org>
References: <20130716180605.A63C7FAAF3@dev.laptop.org>
Message-ID: <20130719162536.GH16015@ns203013.ovh.net>

On 14:06 Tue 16 Jul     , Daniel Drake wrote:
> Add compatible entries to enable booting of OLPC XO-1.75 (MMP2) and
> OLPC XO-4 (MMP3).
> 
> Signed-off-by: Chris Ball <cjb at laptop.org>
> Signed-off-by: Daniel Drake <dsd at laptop.org>
> ---
>  Documentation/devicetree/bindings/arm/mrvl/intc.txt | 4 ++--
>  Documentation/devicetree/bindings/arm/mrvl/mrvl.txt | 8 ++++++++
>  arch/arm/mach-mmp/irq.c                             | 1 +
>  arch/arm/mach-mmp/mmp2-dt.c                         | 2 ++
>  4 files changed, 13 insertions(+), 2 deletions(-)
> 
> Resending after 1 month with no response.
> 
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> index 8b53273..3554fb9 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> @@ -1,8 +1,8 @@
>  * Marvell MMP Interrupt controller
>  
>  Required properties:
> -- compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or
> -  "mrvl,mmp2-mux-intc"
> +- compatible : One of: mrvl,mmp-intc mrvl,mmp2-intc mrvl,mmp3-intc
> +  mrvl,mmp2-mux-intc
>  - reg : Address and length of the register set of the interrupt controller.
>    If the interrupt controller is intc, address and length means the range
>    of the whold interrupt controller. If the interrupt controller is mux-intc,
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> index 117d741..236e884 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> @@ -12,3 +12,11 @@ Required root node properties:
>  MMP2 Brownstone Board
>  Required root node properties:
>  	- compatible = "mrvl,mmp2-brownstone";
> +
> +OLPC XO-1.75 (CL2) based on MMP2
> +Required root node properties:
> +	- compatible = "olpc,xo-1.75";
> +
> +OLPC XO-4 (CL4) based on MMP3
> +Required root node properties:
> +	- compatible = "olpc,xo-cl4";
documentation not consistnt with code

Best Regards,
J.
> diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c
> index 3c71246..d60b85a 100644
> --- a/arch/arm/mach-mmp/irq.c
> +++ b/arch/arm/mach-mmp/irq.c
> @@ -329,6 +329,7 @@ void __init mmp2_init_icu(void)
>  static const struct of_device_id intc_ids[] __initconst = {
>  	{ .compatible = "mrvl,mmp-intc", .data = &mmp_conf },
>  	{ .compatible = "mrvl,mmp2-intc", .data = &mmp2_conf },
> +	{ .compatible = "mrvl,mmp3-intc", .data = &mmp2_conf },
>  	{}
>  };
>  
> diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
> index 4ac2567..e67bd9f 100644
> --- a/arch/arm/mach-mmp/mmp2-dt.c
> +++ b/arch/arm/mach-mmp/mmp2-dt.c
> @@ -44,6 +44,8 @@ static void __init mmp2_dt_init(void)
>  
>  static const char *mmp2_dt_board_compat[] __initdata = {
>  	"mrvl,mmp2-brownstone",
> +	"olpc,xo-1.75",
> +	"olpc,xo-cl4",
>  	NULL,
>  };
>  
> -- 
> 1.8.1.4
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss


From fweisbec at gmail.com  Fri Jul 19 12:29:04 2013
From: fweisbec at gmail.com (Frederic Weisbecker)
Date: Fri, 19 Jul 2013 18:29:04 +0200
Subject: [PATCH 1/3] nohz: Kconfig: remove redundant 64-bit dependency
In-Reply-To: <1372876601-23881-2-git-send-email-khilman@linaro.org>
References: <1372876601-23881-1-git-send-email-khilman@linaro.org>
 <1372876601-23881-2-git-send-email-khilman@linaro.org>
Message-ID: <20130719162903.GC21752@somewhere>

On Wed, Jul 03, 2013 at 11:36:39AM -0700, Kevin Hilman wrote:
> The current 64-bit dependency is on VIRT_CPU_ACCOUNTING_GEN, which already
> has its own dependency on 64-bit.  Remove it from NO_HZ_FULL.

It's not exactly redundant. It's a necessary dependency inheritance.
When we select NO_HZ_FULL, TICK_CPU_ACCOUNTING and VIRT_CPU_ACCOUNTING_NATIVE
disappear such that only VIRT_CPU_ACCOUNTING_GEN can be selected. But if we
don't have CONFIG_64bits, then VIRT_CPU_ACCOUNTING_GEN is not possible either.
So we end up with nothing for the accounting (or whatever random reaction
from Kconfig against that situation) and that's a bug. So we need to inherit the
64 bits dependency on NO_HZ_FULL to prevent that.

We can remove this dependency from NO_HZ_FULL, but only once we remove it
from VIRT_CPU_ACCOUNTING_GEN, not the other way around otherwise this
breaks bisection.

> 
> Cc: Frederic Weisbecker <fweisbec at gmail.com>
> Signed-off-by: Kevin Hilman <khilman at linaro.org>
> ---
>  kernel/time/Kconfig | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> index 70f27e8..b78760f 100644
> --- a/kernel/time/Kconfig
> +++ b/kernel/time/Kconfig
> @@ -99,8 +99,6 @@ config NO_HZ_FULL
>  	depends on SMP
>  	# RCU_USER_QS dependency
>  	depends on HAVE_CONTEXT_TRACKING
> -	# VIRT_CPU_ACCOUNTING_GEN dependency
> -	depends on 64BIT
>  	select NO_HZ_COMMON
>  	select RCU_USER_QS
>  	select RCU_NOCB_CPU
> -- 
> 1.8.3
> 


From sboyd at codeaurora.org  Fri Jul 19 12:29:39 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 19 Jul 2013 09:29:39 -0700
Subject: [PATCH v4 04/17] sched_clock: Add support for >32 bit sched_clock
In-Reply-To: <20130719092319.GA4681@tarshish>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-5-git-send-email-sboyd@codeaurora.org>
 <20130719092319.GA4681@tarshish>
Message-ID: <20130719162939.GG27430@codeaurora.org>

On 07/19, Baruch Siach wrote:
> On Thu, Jul 18, 2013 at 04:21:17PM -0700, Stephen Boyd wrote:
> > @@ -110,14 +123,13 @@ void __init setup_sched_clock(u32 (*read)(void), int
> >   bits, unsigned long rate)
> >  	if (cd.rate > rate)
> >  		return;
> >  
> > -	BUG_ON(bits > 32);
> >  	WARN_ON(!irqs_disabled());
> >  	read_sched_clock = read;
> > -	sched_clock_mask = (1 << bits) - 1;
> > +	sched_clock_mask = CLOCKSOURCE_MASK(bits);
> 
> Note that this conflicts with my integer overflow fix 
> (http://article.gmane.org/gmane.linux.ports.arm.kernel/252498) that I hope 
> will get merged before 3.11 is out.
> 

Thanks for the heads up. The conflict looks minor and I'll rebase
if necessary.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From catalin.marinas at arm.com  Fri Jul 19 12:45:29 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Jul 2013 17:45:29 +0100
Subject: [PATCH v2] arm: Fix deferred mm switch on VIVT processors
Message-ID: <1374252329-5345-1-git-send-email-catalin.marinas@arm.com>

As of commit b9d4d42ad9 (ARM: Remove __ARCH_WANT_INTERRUPTS_ON_CTXSW on
pre-ARMv6 CPUs), the mm switching on VIVT processors is done in the
finish_arch_post_lock_switch() function to avoid whole cache flushing
with interrupts disabled. The need for deferred mm switch is stored as a
thread flag (TIF_SWITCH_MM). However, with preemption enabled, we can
have another thread switch before finish_arch_post_lock_switch(). If the
new thread has the same mm as the previous 'next' thread, the scheduler
will not call switch_mm() and the TIF_SWITCH_MM flag won't be set for
the new thread.

This patch moves the switch pending flag to the mm_context_t structure
since this is specific to the mm rather than thread.

Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
Reported-by: Marc Kleine-Budde <mkl at pengutronix.de>
Cc: Marc Kleine-Budde <mkl at pengutronix.de>
Cc: <stable at vger.kernel.org> # 3.5+
---

That's version 2 following Russell's comments. It now disables the
preemption around cpu_switch_mm(). The preempt enabling is done with
no_resched as we are already at the end of a thread switch.

Marc, I dropped your Tested-by since this is a modified patch. Please
let me know if it works for you.

Thanks.

 arch/arm/include/asm/mmu.h         |  2 ++
 arch/arm/include/asm/mmu_context.h | 20 ++++++++++++++++----
 arch/arm/include/asm/thread_info.h |  1 -
 3 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/mmu.h b/arch/arm/include/asm/mmu.h
index e3d5554..d1b4998 100644
--- a/arch/arm/include/asm/mmu.h
+++ b/arch/arm/include/asm/mmu.h
@@ -6,6 +6,8 @@
 typedef struct {
 #ifdef CONFIG_CPU_HAS_ASID
 	atomic64_t	id;
+#else
+	int		switch_pending;
 #endif
 	unsigned int	vmalloc_seq;
 } mm_context_t;
diff --git a/arch/arm/include/asm/mmu_context.h b/arch/arm/include/asm/mmu_context.h
index b5792b7..9b32f76 100644
--- a/arch/arm/include/asm/mmu_context.h
+++ b/arch/arm/include/asm/mmu_context.h
@@ -56,7 +56,7 @@ static inline void check_and_switch_context(struct mm_struct *mm,
 		 * on non-ASID CPUs, the old mm will remain valid until the
 		 * finish_arch_post_lock_switch() call.
 		 */
-		set_ti_thread_flag(task_thread_info(tsk), TIF_SWITCH_MM);
+		mm->context.switch_pending = 1;
 	else
 		cpu_switch_mm(mm->pgd, mm);
 }
@@ -65,9 +65,21 @@ static inline void check_and_switch_context(struct mm_struct *mm,
 	finish_arch_post_lock_switch
 static inline void finish_arch_post_lock_switch(void)
 {
-	if (test_and_clear_thread_flag(TIF_SWITCH_MM)) {
-		struct mm_struct *mm = current->mm;
-		cpu_switch_mm(mm->pgd, mm);
+	struct mm_struct *mm = current->mm;
+
+	if (mm && mm->context.switch_pending) {
+		/*
+		 * Preemption must be disabled during cpu_switch_mm() as we
+		 * have some stateful cache flush implementations. Check
+		 * switch_pending again in case we were preempted and the
+		 * switch to this mm was already done.
+		 */
+		preempt_disable();
+		if (mm->context.switch_pending) {
+			mm->context.switch_pending = 0;
+			cpu_switch_mm(mm->pgd, mm);
+		}
+		preempt_enable_no_resched();
 	}
 }
 
diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
index 214d415..2b8114f 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -156,7 +156,6 @@ extern int vfp_restore_user_hwstate(struct user_vfp __user *,
 #define TIF_USING_IWMMXT	17
 #define TIF_MEMDIE		18	/* is terminating due to OOM killer */
 #define TIF_RESTORE_SIGMASK	20
-#define TIF_SWITCH_MM		22	/* deferred switch_mm */
 
 #define _TIF_SIGPENDING		(1 << TIF_SIGPENDING)
 #define _TIF_NEED_RESCHED	(1 << TIF_NEED_RESCHED)


From fweisbec at gmail.com  Fri Jul 19 12:51:52 2013
From: fweisbec at gmail.com (Frederic Weisbecker)
Date: Fri, 19 Jul 2013 18:51:52 +0200
Subject: [PATCH 2/3] init/Kconfig: VIRT_CPU_ACCOUNTING_GEN: drop 64-bit
 requirement
In-Reply-To: <1372876601-23881-3-git-send-email-khilman@linaro.org>
References: <1372876601-23881-1-git-send-email-khilman@linaro.org>
 <1372876601-23881-3-git-send-email-khilman@linaro.org>
Message-ID: <20130719165150.GD21752@somewhere>

On Wed, Jul 03, 2013 at 11:36:40AM -0700, Kevin Hilman wrote:
> The 64-bit requirement can be removed after the conversion of the nsec
> granularity cputime to work on !64_BIT, which was done in commit
> 8c23b80e (cputime_nsecs: use math64.h for nsec resolution conversion
> helpers)
> 
> Cc: Frederic Weisbecker <fweisbec at gmail.com>
> Signed-off-by: Kevin Hilman <khilman at linaro.org>

So I finally sat down and checked all the use of cputime_t (I probably
missed some) to make sure that readers are safe against concurrent write
in 32 bits archs.

And everything looks ok expect perhaps fs/[compat]binfmt_elf*.c that doesn't
lock the signal struct before getting tsk->signal->cutime and stuff. But perhaps
it's safe for some reason, I'll look more carefully. And I also need to
check further itimers code.

But I think I pushed back the ARM support long enough now so it's time to
get this patch in. The above issues are mostly details that can be dealt
with separately.

Just one thing before we apply this. I haven't checked the arch/* potential
unsafe uses of cputime. So it would be nice to bring a new
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN. This won't require any specific arch
support, it would just be there to inform the arch developer, through the help
text, about the issue with cputime being u64 and resulting possible race.
So the guy can have a look at cputime_t uses in his arch before finally enabling
that config.

Also, of course check that arm is fine wrt. that and finally enable it :)

Thanks!


> ---
>  init/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 2d9b831..e151022 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -325,7 +325,7 @@ config VIRT_CPU_ACCOUNTING_NATIVE
>  
>  config VIRT_CPU_ACCOUNTING_GEN
>  	bool "Full dynticks CPU time accounting"
> -	depends on HAVE_CONTEXT_TRACKING && 64BIT
> +	depends on HAVE_CONTEXT_TRACKING
>  	select VIRT_CPU_ACCOUNTING
>  	select CONTEXT_TRACKING
>  	help
> -- 
> 1.8.3
> 


From swarren at wwwdotorg.org  Fri Jul 19 12:52:33 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 19 Jul 2013 10:52:33 -0600
Subject: [PATCH V4 0/4] ARM: tegra114: cpuidle: add power down state
In-Reply-To: <1374225926-26832-1-git-send-email-josephl@nvidia.com>
References: <1374225926-26832-1-git-send-email-josephl@nvidia.com>
Message-ID: <51E96ED1.9020300@wwwdotorg.org>

On 07/19/2013 03:25 AM, Joseph Lo wrote:
> This series introduce CPU core power down state for CPU idle. When CPU go
> into this state, it saves it's context and needs a proper configuration
> in flow controller to power gate the CPU when CPU runs into WFI
> instruction. And the CPU also needs to set the IRQ as CPU power down idle
> wake up event in flow controller.
> 
> To prevent race conditions and ensure proper interrupt routing on
> Cortex-A15 CPUs when they are power-gated, add a CPU PM notifier
> call-back to reprogram the GIC CPU interface on PM entry. The
> GIC CPU interface will be reset back to its normal state by
> the common GIC CPU PM exit callback when the CPU wakes up.
> 
> And the Tegra114 support CPU0 hotplug function in HW physically, but it
> needs other software to make it work normally after we add CPU idle power
> down mode support. But we don't support that yet, removing them for now.

OK, this version works fine, so I have applied it to Tegra's
for-3.12/soc. I hope we can resolve the issues with
CPUIDLE_FLAG_TIMER_STOP and CPU0 hot plug soon though.


From broonie at kernel.org  Fri Jul 19 12:52:46 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 19 Jul 2013 17:52:46 +0100
Subject: [PATCH 2/6] ASoC: sirf: add I2S CPU DAI driver
In-Reply-To: <1374232042-26088-3-git-send-email-Baohua.Song@csr.com>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
 <1374232042-26088-3-git-send-email-Baohua.Song@csr.com>
Message-ID: <20130719165246.GL9858@sirena.org.uk>

On Fri, Jul 19, 2013 at 07:07:18PM +0800, Barry Song wrote:

Pretty good overall - there's a few things below but should all be
fairly small.

> +static int sirf_i2s_startup(struct snd_pcm_substream *substream,
> +		struct snd_soc_dai *dai)
> +{
> +
> +	struct sirf_i2s *si2s = snd_soc_dai_get_drvdata(dai);
> +
> +	if (si2s->master_mode)
> +		pwm_enable(si2s->mclk_pwm);
> +	clk_prepare_enable(si2s->clk);
> +
> +	device_reset(dai->dev);
> +	snd_soc_dai_set_dma_data(dai, substream,
> +		&sirf_i2s_dai_dma_data[substream->stream]);
> +	return 0;
> +}

device_reset() sounds like it's not going to work for simultaneous
playback and capture.

> +static int sirf_i2s_trigger(struct snd_pcm_substream *substream,
> +		int cmd, struct snd_soc_dai *dai)
> +{
> +	struct sirf_i2s *si2s = snd_soc_dai_get_drvdata(dai);
> +	int playback = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK);
> +
> +	switch (cmd) {
> +	case SNDRV_PCM_TRIGGER_START:
> +	case SNDRV_PCM_TRIGGER_RESUME:
> +	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> +		spin_lock(&si2s->lock);
> +
> +		if (playback) {
> +			/* First start the FIFO, then enable the tx/rx */
> +			writel(AUDIO_FIFO_RESET,
> +				si2s->base + AUDIO_CTRL_EXT_TXFIFO1_OP);
> +			mdelay(1);
> +			writel(AUDIO_FIFO_START,
> +				si2s->base + AUDIO_CTRL_EXT_TXFIFO1_OP);
> +			mdelay(1);

Do we really need these 1ms delays?  They're very long for the
context...

> +static int sirf_i2s_prepare(struct snd_pcm_substream *substream,
> +			struct snd_soc_dai *dai)
> +{
> +	struct snd_pcm_runtime *runtime = substream->runtime;
> +	struct sirf_i2s *si2s = snd_soc_dai_get_drvdata(dai);
> +	u32 ctrl = readl(si2s->base + AUDIO_CTRL_I2S_CTRL);
> +
> +	if (runtime->channels == 2)
> +		ctrl &= ~I2S_SIX_CHANNELS;
> +	else
> +		ctrl |= I2S_SIX_CHANNELS;

A switch statement for the number of channels would make me happier
here.

> +	switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
> +	case SND_SOC_DAIFMT_CBM_CFM:
> +		ctrl = readl(si2s->base + AUDIO_CTRL_I2S_CTRL);
> +		ctrl |= I2S_SLAVE_MODE;
> +		writel(ctrl, si2s->base + AUDIO_CTRL_I2S_CTRL);
> +		si2s->master_mode = 0;
> +		break;

Do we need locking on all these register updates?

> +	case SND_SOC_DAIFMT_CBS_CFS:
> +		si2s->master_mode = 1;
> +		return -EINVAL;

Should this be undoing the work done for _CBM_CFM?

> +#ifdef CONFIG_PM
> +static int sirf_i2s_suspend(struct platform_device *pdev,
> +		pm_message_t state)
> +{
> +	struct sirf_i2s *si2s = platform_get_drvdata(pdev);
> +
> +	si2s->i2s_ctrl = readl(si2s->base+AUDIO_CTRL_I2S_CTRL);
> +
> +	clk_disable_unprepare(si2s->clk);
> +
> +	if (si2s->master_mode)
> +		pwm_disable(si2s->mclk_pwm);
> +	return 0;
> +}

Should these be runtime PM calls as well?  Seems like the bus could be
unclocked whenever audio is not playing.  If you need the clock to write
conifguraiton perhaps regmap-mmio could help?

> +	spin_lock_init(&si2s->lock);

What is this lock actually protecting?
-------------- 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/20130719/727ea2f8/attachment.sig>

From swarren at wwwdotorg.org  Fri Jul 19 12:54:31 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 19 Jul 2013 10:54:31 -0600
Subject: [PATCH V2 00/11] ARM: tegra114: add support for system suspend
In-Reply-To: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
References: <1372845047-25147-1-git-send-email-josephl@nvidia.com>
Message-ID: <51E96F47.5080206@wwwdotorg.org>

On 07/03/2013 03:50 AM, Joseph Lo wrote:
> This series introduce system suspend function for Tegra114 and depend on
> the series of "ARM: tegra114: cpuidle: add power down state".
> 
> Verified on Seaboard, Cardhu and Dalmore and with THUMB2_KERNEL as well.

Patches 1-9 applied to Tegra's for-3.12/soc branch. Patch 10 dropped
since Laxman's patch was more complete. Patch 11 applied to Tegra's
for-3.12/dt branch.


From soren.brinkmann at xilinx.com  Fri Jul 19 13:16:44 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Fri, 19 Jul 2013 10:16:44 -0700
Subject: [PATCH 1/2] clk/zynq/pll: Fix documentation for PLL register function
Message-ID: <1374254205-9912-1-git-send-email-soren.brinkmann@xilinx.com>

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
---
 drivers/clk/zynq/pll.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/zynq/pll.c b/drivers/clk/zynq/pll.c
index 47e307c..67f1b5e 100644
--- a/drivers/clk/zynq/pll.c
+++ b/drivers/clk/zynq/pll.c
@@ -182,7 +182,12 @@ static const struct clk_ops zynq_pll_ops = {
 
 /**
  * clk_register_zynq_pll() - Register PLL with the clock framework
- * @np	Pointer to the DT device node
+ * @name	PLL name
+ * @parent	Parent clock name
+ * @pll_ctrl	Pointer to PLL control register
+ * @pll_status	Pointer to PLL status register
+ * @lock_index	Bit index to this PLL's lock status bit in @pll_status
+ * @lock	Register lock
  */
 struct clk *clk_register_zynq_pll(const char *name, const char *parent,
 		void __iomem *pll_ctrl, void __iomem *pll_status, u8 lock_index,
-- 
1.8.3.3



From soren.brinkmann at xilinx.com  Fri Jul 19 13:16:45 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Fri, 19 Jul 2013 10:16:45 -0700
Subject: [PATCH 2/2] clk/zynq/pll: Use #defines for fbdiv min/max values
In-Reply-To: <1374254205-9912-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1374254205-9912-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <1374254205-9912-2-git-send-email-soren.brinkmann@xilinx.com>

Use more descriptive #defines for the minimum and maximum PLL
feedback divider.

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
---
 drivers/clk/zynq/pll.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/zynq/pll.c b/drivers/clk/zynq/pll.c
index 67f1b5e..26a8d8b 100644
--- a/drivers/clk/zynq/pll.c
+++ b/drivers/clk/zynq/pll.c
@@ -50,6 +50,9 @@ struct zynq_pll {
 #define PLLCTRL_RESET_MASK	1
 #define PLLCTRL_RESET_SHIFT	0
 
+#define PLL_FBDIV_MIN	13
+#define PLL_FBDIV_MAX	66
+
 /**
  * zynq_pll_round_rate() - Round a clock frequency
  * @hw:		Handle between common and hardware-specific interfaces
@@ -63,10 +66,10 @@ static long zynq_pll_round_rate(struct clk_hw *hw, unsigned long rate,
 	u32 fbdiv;
 
 	fbdiv = DIV_ROUND_CLOSEST(rate, *prate);
-	if (fbdiv < 13)
-		fbdiv = 13;
-	else if (fbdiv > 66)
-		fbdiv = 66;
+	if (fbdiv < PLL_FBDIV_MIN)
+		fbdiv = PLL_FBDIV_MIN;
+	else if (fbdiv > PLL_FBDIV_MAX)
+		fbdiv = PLL_FBDIV_MAX;
 
 	return *prate * fbdiv;
 }
-- 
1.8.3.3



From broonie at kernel.org  Fri Jul 19 14:06:40 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 19 Jul 2013 19:06:40 +0100
Subject: [PATCH] ASoC: atmel: add wm8904 based audio machine driver
In-Reply-To: <1374226977-10188-1-git-send-email-voice.shen@atmel.com>
References: <1374226977-10188-1-git-send-email-voice.shen@atmel.com>
Message-ID: <20130719180640.GS9858@sirena.org.uk>

On Fri, Jul 19, 2013 at 05:42:57PM +0800, Bo Shen wrote:
> Add wm8904 based audio machine driver for Atmel EK board

Applied, thanks though...

> +	mclk = clk_get(NULL, "pck0");
> +	if (IS_ERR(mclk)) {
> +		dev_err(&pdev->dev, "failed to get pck0\n");
> +		ret = PTR_ERR(mclk);
> +		goto err_set_audio;
> +	}
> +
> +	clk_src = clk_get(NULL, "clk32k");
> +	if (IS_ERR(clk_src)) {
> +		dev_err(&pdev->dev, "failed to get clk32k\n");
> +		ret = PTR_ERR(clk_src);
> +		goto err_set_audio;
> +	}

These should really be devm_clk_get()s and use a device.  This can be
revisited after the common clock framework conversion though.
-------------- 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/20130719/11eb3e56/attachment.sig>

From systemprogrammierung.brunner at gmail.com  Fri Jul 19 14:07:00 2013
From: systemprogrammierung.brunner at gmail.com (Markus Brunner)
Date: Fri, 19 Jul 2013 20:07:00 +0200
Subject: [PATCH] remove vlan tags in CPSW dual emac mode
In-Reply-To: <51E42B43.8060307@ti.com>
References: <4699400.vD3TdgH1nR@localhost> <5176C4FE.4080305@ti.com>
 <51E00B2F.6050406@newflow.co.uk> <51E04C89.8030202@ti.com>
 <51E0582D.4090306@newflow.co.uk> <51E3EEE7.9030508@ti.com>
 <51E41A34.4030000@newflow.co.uk> <51E42B43.8060307@ti.com>
Message-ID: <CAOFKi=amD5Ho0LpOm+G-2pQezUjJMgSgH0XxHXQ_md57c3FwVA@mail.gmail.com>

On Mon, Jul 15, 2013 at 7:02 PM, Mugunthan V N <mugunthanvnm at ti.com> wrote:
> On 7/15/2013 9:20 PM, Mark Jackson wrote:
>> On 15/07/13 13:45, Mugunthan V N wrote:
>>> On 7/13/2013 12:55 AM, Mark Jackson wrote:
>>>> On 12/07/13 19:35, Mugunthan V N wrote:
>>>>> On 7/12/2013 7:27 PM, Mark Jackson wrote:
>>>> [snip]
>>>>
>>>>>> Just to update this (old) thread ...
>>>>>>
>>>>>> I can still confirm that *without* the above patch, I am *unable* to use both network
>>>>>> ports on our AM335x board.

I can confirm that. Windows won't strip away the vlan header like linux does.

[snip]
>>>> Markus, are you still using this patch ?

yes.

>>>>
>>> Today I have tested the Dual EMAC on my am335x-evmsk and its working fine with
>>> net/master branch.
>>> I had 3 patches additional to net/master in which two for basic boot of EVMsk
>>> and one for enabling Dual EMAC. I had pushed the branch in the below repo
>>> repo:
>>> git://git.ti.com/~mugunthanvnm/ti-linux-kernel/mugunth-connectivity-linux-feature-tree.git
>>> branch: dual-emac

I tested it and it has the same problem as with 3.9 - 3.11-rc1.

>> Okay ... I can't test that at the moment as I can only boot from MMC as there's
>> currently no support for MMC booting in the mainline kernel.
>>
>> So ... the code works for you, but not for me.
>>
>> I guess the other difference is that I'm not using the same PHY (we use a 10/100
>> SMSC 8710A, not the GbE Atheros part).
>>
>> Could that make any difference ?
>>
>> Markus, are you still seeing the same issue ?  What PHY are you using ?

I', using a Micrel ksz8895mq, which is actually a switch, however one
phy is connected directly, so bootstrapping can work and even if I
don't enable the switch I have the same issue on that port. I doubt
the phy will change anything.

Regards,
Markus


From broonie at kernel.org  Fri Jul 19 14:13:13 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 19 Jul 2013 19:13:13 +0100
Subject: [PATCH 3/6] ASoC: usp-pcm: add CPU DAI driver for PCM simulated
 from USP
In-Reply-To: <1374232042-26088-4-git-send-email-Baohua.Song@csr.com>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
 <1374232042-26088-4-git-send-email-Baohua.Song@csr.com>
Message-ID: <20130719181313.GT9858@sirena.org.uk>

On Fri, Jul 19, 2013 at 07:07:19PM +0800, Barry Song wrote:

> +static int sirf_usp_pcm_divider(struct snd_soc_dai *dai, int div_id, int rate)
> +{
> +	struct sirf_usp *susp = snd_soc_dai_get_drvdata(dai);
> +
> +	u32 clk_rate = clk_get_rate(susp->clk);
> +	u32 clk_div = (clk_rate/(2*rate)) - 1;
> +	u32 clk_div_hi = (clk_div & 0xC00)>>10;
> +	u32 clk_div_lo = (clk_div & 0x3FF);
> +
> +	writel((clk_div_lo<<21) | readl(susp->base + USP_MODE2),
> +		susp->base + USP_MODE2);
> +	writel((clk_div_hi<<30) | readl(susp->base + USP_TX_FRAME_CTRL),
> +		susp->base + USP_TX_FRAME_CTRL);
> +
> +	return 0;
> +}

I'd be happier if this did some validation on the supplied rate (for
example, checking that it's less than the master rate) and had arguments
specifying which clock was being affected (in case there's more in
future revisions).

Also what exactly is the rate being set - can the driver just figure
this out automatically from the sample rate?

> +#ifdef CONFIG_PM
> +static int sirf_usp_pcm_suspend(struct platform_device *pdev,
> +	pm_message_t state)
> +{
> +	struct sirf_usp *susp = platform_get_drvdata(pdev);
> +
> +	susp->mode1_reg = readl(susp->base + USP_MODE1);
> +	susp->mode2_reg = readl(susp->base + USP_MODE2);
> +	sirf_usp_controller_uninit(susp);
> +	clk_disable_unprepare(susp->clk);
> +
> +	return 0;
> +}

Can this be done as runtime PM as well?  Seems like it'd save power.

> +	susp->clk = clk_get(&pdev->dev, NULL);
> +	if (IS_ERR(susp->clk)) {
> +		dev_err(&pdev->dev, "Get clock failed.\n");
> +		return PTR_ERR(susp->clk);
> +	}

devm_clk_get().
-------------- 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/20130719/e8735988/attachment.sig>

From sre at debian.org  Fri Jul 19 14:14:16 2013
From: sre at debian.org (Sebastian Reichel)
Date: Fri, 19 Jul 2013 20:14:16 +0200
Subject: N900 device tree conversion: how to do first step
In-Reply-To: <20130609015944.GA23559@amd.pavel.ucw.cz>
References: <20130609015944.GA23559@amd.pavel.ucw.cz>
Message-ID: <20130719181416.GA1204@earth.universe>

Hi,

On Sun, Jun 09, 2013 at 03:59:44AM +0200, Pavel Machek wrote:
> I'd like to convert Nokia N900 to device tree.
> 
> Unfortunately, serial port is not easily available (very special cable
> would be needed, does someone know where to get one?)

One way to get one is building it yourself. I finished mine yesterday:

http://elektranox.org/n900/adapter/index.html

-- Sebastian
-------------- 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/20130719/70ad0e59/attachment.sig>

From sergei.shtylyov at cogentembedded.com  Fri Jul 19 14:18:56 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 19 Jul 2013 22:18:56 +0400
Subject: [PATCH v6 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <51E95DEB.7010702@ti.com>
References: <1374226039-16943-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1374226039-16943-2-git-send-email-oleksandr.kozaruk@ti.com>
 <51E94F97.40002@cogentembedded.com> <51E95DEB.7010702@ti.com>
Message-ID: <51E98310.7020103@cogentembedded.com>

Hello.

On 07/19/2013 07:40 PM, Grygorii Strashko wrote:

>>> GPADC is the general purpose ADC present on twl6030.
>>> The dt data is interrupt used to trigger end of ADC
>>> conversion.

>>> Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
>>> ---
>>>   arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
>>>   1 file changed, 6 insertions(+)

>>> diff --git a/arch/arm/boot/dts/twl6030.dtsi
>>> b/arch/arm/boot/dts/twl6030.dtsi
>>> index 2e3bd31..d7d4c28 100644
>>> --- a/arch/arm/boot/dts/twl6030.dtsi
>>> +++ b/arch/arm/boot/dts/twl6030.dtsi
>>> @@ -103,4 +103,10 @@
>>>           compatible = "ti,twl6030-pwmled";
>>>           #pwm-cells = <2>;
>>>       };
>>> +
>>> +    adc: gpadc {

>>     Read my lips: the node should be called just "adc", not "gpadc".
>        ^^^^^^^^^^^^ Are you sure?

    I didn't know how to express my disappointment from Oleksandr's inability 
to understand what I wanted to convey to him from 2 attempts... first, he 
changed the label instead of the node name, then he only dropped "twl6030_" 
prefix from the name. I should probably have been even more specific before.

> Why? The name was selected according to the documentation on device "General
> purpose analog-to-digital converter (GPADC)".

    Sigh, we simply don't care whether this ADC is general-purpose or not.
The main thing it is ADC.

> PS. Following your logic - "GPIO" need to renamed to "IO" everywhere ;P

    GPIO is well known and established abbreviation, contrasted to GPADC.
Moreover, ePAPR spec lists "gpio" as a generic node name.

WBR, Sergei



From broonie at kernel.org  Fri Jul 19 14:35:03 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 19 Jul 2013 19:35:03 +0100
Subject: [PATCH 4/6] ASoC: sirf-soc-inner: add drivers for both CPU and
 Codec DAIs
In-Reply-To: <1374232042-26088-5-git-send-email-Baohua.Song@csr.com>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
 <1374232042-26088-5-git-send-email-Baohua.Song@csr.com>
Message-ID: <20130719183503.GU9858@sirena.org.uk>

On Fri, Jul 19, 2013 at 07:07:20PM +0800, Barry Song wrote:

> there is an internal codec embedded in the SiRF SoC. this is not
> a typical user scenerios of ASoC. but we can still get benefit by
> sharing platform DMA codes instead of implementing a pure ALSA
> driver.
> This driver adds DAI drivers for this internal codec.

To be honest this shouldn't be too exciting from an ASoC point of view -
just a normal CODEC driver with some stub DAIs.  It looks like it might
benefit from regmap-mmio and DAPM.

> +static int sirf_inner_control(struct snd_kcontrol *kcontrol,
> +		struct snd_ctl_elem_value *ucontrol,
> +		int get, char *name)
> +{
> +	struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
> +	struct snd_soc_card *card = codec->card;
> +	int i;
> +	for (i = 0; i < card->num_controls; i++) {
> +		if (!strcmp(card->controls[i].name, name)) {
> +			if (card->controls[i].get && get)
> +				return card->controls[i].get(kcontrol, ucontrol);
> +			else if (card->controls[i].put && !get)
> +				return card->controls[i].put(kcontrol, ucontrol);
> +		}
> +	}
> +	return 0;
> +}

What is all this about?  I don't quite understand what the goal is and
there's no comments.

> +static int sirf_inner_snd_speaker_set(struct snd_kcontrol *kcontrol,
> +		struct snd_ctl_elem_value *ucontrol)
> +{
> +	struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
> +	struct sirf_soc_inner_audio *sinner_audio = dev_get_drvdata(codec->dev);
> +
> +	spin_lock(&sinner_audio->lock);
> +	sirf_inner_control(kcontrol, ucontrol, 0, "Speaker Out");
> +
> +	if (ucontrol->value.integer.value[0]) {
> +		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0)
> +				| IC_RDACEN | IC_SPSELR,
> +				sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
> +
> +		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1) |
> +				(1 << sinner_audio->reg_bits->firdac_lout_en_bits),
> +				sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
> +
> +		writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) |
> +					IC_SPEN), sinner_audio->base + AUDIO_IC_CODEC_CTRL0);

Is this possibly some supplies plus a power bit?

> +static int sirf_inner_codec_startup(struct snd_pcm_substream *substream,
> +		struct snd_soc_dai *dai)
> +{
> +	struct sirf_soc_inner_audio *sinner_audio = snd_soc_dai_get_drvdata(dai);
> +	u32 adc_gain_mask = sinner_audio->reg_bits->adc_gain_mask;
> +	u32 adc_left_gain_shift = sinner_audio->reg_bits->adc_left_gain_shift;
> +	u32 adc_right_gain_shift = sinner_audio->reg_bits->adc_right_gain_shift;
> +	u32 mic_max_gain = sinner_audio->reg_bits->mic_max_gain;

Would regmap_field help here?

> +		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1) |
> +			(1 << sinner_audio->reg_bits->codec_clk_en_bits) |
> +			(1 << sinner_audio->reg_bits->por_bits),
> +			sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
> +		msleep(50);
> +
> +		writel(readl(sinner_audio->base + AUDIO_IC_CODEC_PWR) |
> +			MICBIASEN, sinner_audio->base + AUDIO_IC_CODEC_PWR);
> +		usleep_range(300, 1000);

This all looks a lot like a normal CODEC power up sequence that's been
open coded but could use DAPM?

> +static void sirf_inner_codec_shutdown(struct snd_pcm_substream *substream,
> +		struct snd_soc_dai *dai)
> +{
> +}
> +
> +static int sirf_inner_codec_hw_params(struct snd_pcm_substream *substream,
> +		struct snd_pcm_hw_params *params,
> +		struct snd_soc_dai *dai)
> +{
> +	return 0;
> +}

Remove empty functions.

> +static int sirf_soc_inner_resume(struct platform_device *pdev)
> +{
> +	struct sirf_soc_inner_audio *sinner_audio = platform_get_drvdata(pdev);
> +
> +	clk_prepare_enable(sinner_audio->clk);
> +
> +	writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1)
> +		| (1 << sinner_audio->reg_bits->codec_clk_en_bits)),
> +		sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
> +	writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1)
> +		| (1 << sinner_audio->reg_bits->adc14b_12_bits)),
> +		sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
> +	writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) | IC_CPFREQ,
> +		sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
> +	writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) | IC_CPEN,
> +		sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
> +	return 0;
> +}
> +#else
> +#define sirf_soc_inner_suspend NULL
> +#define sirf_soc_inner_resume NULL
> +#endif

Standard runtime PM question and this definitely does look like
regmap-mmio will help - you've essentially open coded some of it.
-------------- 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/20130719/2b23f3dd/attachment.sig>

From broonie at kernel.org  Fri Jul 19 14:51:01 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 19 Jul 2013 19:51:01 +0100
Subject: [PATCH 5/6] ASoC: sirf-inner: add mach driver for SiRFSoC
 internal codec
In-Reply-To: <1374232042-26088-6-git-send-email-Baohua.Song@csr.com>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
 <1374232042-26088-6-git-send-email-Baohua.Song@csr.com>
Message-ID: <20130719185101.GV9858@sirena.org.uk>

On Fri, Jul 19, 2013 at 07:07:21PM +0800, Barry Song wrote:

> +#ifndef CONFIG_ANDROID
> +	unsigned int            gpio_hp_detect;
> +	struct snd_soc_jack     hp_jack;
> +#endif

Not for mainline.  I'd suggest setting it up for extcon anyway
especially if it's just a simple accessory, that should work for both
Android and mainline.

> +static int sirf_inner_speaker_out_put(struct snd_kcontrol *kcontrol,
> +		struct snd_ctl_elem_value *ucontrol)
> +{
> +	int is_spk_out = ucontrol->value.integer.value[0];
> +	struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
> +	struct snd_soc_card *card = codec->card;
> +	struct sirf_inner_card *sinner_card = snd_soc_card_get_drvdata(card);
> +
> +	if (gpio_is_valid(sinner_card->gpio_spk_pa))
> +		gpio_direction_output(sinner_card->gpio_spk_pa, is_spk_out);
> +	return 0;
> +}

Oh, right.  If this is doing what I think this is doing you want to use
DAPM within the CODEC then this can just become a pin switch or you can
hook in directly if you continue to use soc-jack - it has DAPM
integration.
-------------- 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/20130719/df529a7f/attachment.sig>

From swarren at wwwdotorg.org  Fri Jul 19 14:52:28 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 19 Jul 2013 12:52:28 -0600
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130719072927.GY7656@atomide.com>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost> <51E70953.1000601@wwwdotorg.org>
 <20130718072034.GO7656@atomide.com> <51E8401E.8040705@wwwdotorg.org>
 <20130719072927.GY7656@atomide.com>
Message-ID: <51E98AEC.5000802@wwwdotorg.org>

On 07/19/2013 01:29 AM, Tony Lindgren wrote:
> * Stephen Warren <swarren at wwwdotorg.org> [130718 12:27]:
>> On 07/18/2013 01:25 AM, Tony Lindgren wrote:
>>> * Stephen Warren <swarren at wwwdotorg.org> [130717 14:21]:
>>>> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
>>>>> To toggle dynamic states, let's add the optional active state in
>>>>> addition to the static default state. Then if the optional active
>>>>> state is defined, we can require that idle and sleep states cover
>>>>> the same pingroups as the active state.
>>>>>
>>>>> Then let's add pinctrl_check_dynamic() and pinctrl_select_dynamic()
>>>>> to use instead of pinctrl_select() to avoid breaking existing users.
>>>>>
>>>>> With pinctrl_check_dynamic() we can check that idle and sleep states
>>>>> match the active state for pingroups during init, and don't need to
>>>>> do it during runtime.
>>>>>
>>>>> Then with the states pre-validated, pinctrl_select_dynamic() can
>>>>> just toggle between the dynamic states without extra checks.
>>>>>
>>>>> Note that pinctr_select_state() still has valid use cases, such as
>>>>> changing states when the pins can be shared between two drivers
>>>>> and don't necessarily cover the same pingroups. For dynamic runtime
>>>>> toggling of pin states, we should eventually always use just
>>>>> pinctrl_select_dynamic().
>>
>>>>> @@ -1241,7 +1371,13 @@ static int pinctrl_pm_select_state(struct device *dev, struct pinctrl_state *sta
>>>>>  		return 0;
>>>>>  	if (IS_ERR(state))
>>>>>  		return 0; /* No such state */
>>>>> -	ret = pinctrl_select_state(pins->p, state);
>>>>> +
>>>>> +	/* Configured for proper dynamic muxing? */
>>>>> +	if (!IS_ERR(dev->pins->active_state))
>>>>> +		ret = pinctrl_select_dynamic(pins->p, state);
>>>>> +	else
>>>>> +		ret = pinctrl_select_state(pins->p, state);
>>>>
>>>> Hmmm. I'm not quite sure this is right... Surely this function should
>>>> just do nothing if the dynamic states aren't defined? The system should
>>>> just, and only, be in the "default" state and never do anything else.
>>>
>>> This keeps the existing behaviour. We should be able to drop the
>>> call to pinctrl_select_state() here after the existing use in
>>> drivers has been fixed.
>>
>> How many DT-based systems already have multiple of default/idle/sleep
>> states defined in DT? Right now, since the kernel code uses
>> pinctrl_select_state() to switch between those, the state definitions
>> need to define /all/ pins used by those states, not just the dynamic
>> ones. However, with this series in place, the default state should only
>> include the static pins, and the active/idle/sleep states should only
>> include the dynamic pins. That's a change to the DT bindings, since it
>> changes how the DT must be written, and causes older DTs to be
>> incompatible with newer kernels and vice-versa.
> 
> Well we can keep the current behaviour with pinctrl_select_state() around
> as long as needed. For the legacy cases, there is no active state defined
> and we fall back to pinctrl_select_state().
>  
>> So, do we just ignore this DT ABI change again, or insist on doing it in
>> some compatible way? DT ABI-ness is a PITA:-(
> 
> I'd vote for keeping the existing behaviour with pinctrl_select_state()
> when no active state is defined.

Yes, I think that will work, since the active state cannot exist before
this new scheme is in place.

But, this needs to be very clearly spell out in the DT binding
documentation: If you have states default/idle/sleep, they're complete
alternatives, whereas if you have states default/active/idle/sleep, the
latter 3 are alternatives that build on top of the first. I foresee mass
confusion, but perhaps I'm being pessimistic.


From swarren at wwwdotorg.org  Fri Jul 19 14:58:57 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 19 Jul 2013 12:58:57 -0600
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130719073957.GZ7656@atomide.com>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost> <51E70B5D.6030802@wwwdotorg.org>
 <20130718073638.GP7656@atomide.com> <51E84180.6080902@wwwdotorg.org>
 <20130719073957.GZ7656@atomide.com>
Message-ID: <51E98C71.5010709@wwwdotorg.org>

On 07/19/2013 01:39 AM, Tony Lindgren wrote:
> * Stephen Warren <swarren at wwwdotorg.org> [130718 12:33]:
>> On 07/18/2013 01:36 AM, Tony Lindgren wrote:
>>> * Stephen Warren <swarren at wwwdotorg.org> [130717 14:30]:
>>>> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
>> ...
>>>> Why shouldn't e.g. a pinctrl-based I2C mux also be able to do runtime
>>>> PM? Does the mux setting select which states are used for runtime PM, or
>>>> does runtime PM override the basic mux setting, or must the pincrl-I2C
>>>> mux manually implement custom runtime-PM/pinctrl interaction since
>>>> there's no generic answer to those questions? How many more custom
>>>> exceptions will there be?
>>>
>>> The idea is that runtime PM will never touch the basic mux settings
>>> at all. The "default" state should be considered a static state
>>> that is claimed during driver probe, and released when the driver
>>> is unloaded. This is typically let's say 90% of the pins for any
>>> device.
>>>
>>> For runtime PM, we can just toggle the PM related pinctrl states as
>>> they have been verified to match the active state during init.
>>>
>>> So I don't see why pinctrl-I2C would have to do anything specific.
>>> All that is required is that the pins are grouped for the consumer
>>> driver, and we can provide some automated checks on the states for
>>> runtime PM.
>>
>> So, consider a pinctrl-based I2C mux. It has 2 states to cover two I2C
>> buses:
>>
>> a) bus 1: I2C controller is muxed out onto one set of pins.
>>
>> b) bus 2: I2C controller is muxed out onto another set of pins.
>>
>> Now, the system could go idle in either of those 2 states, and then
>> later need to return to one of those states. I just don't see how that
>> would work, since the runtime PM code in this series switches to *an*
>> active state when the device becomes non-idle. If the definition of the
>> idle state switches the mux function for both sets of pins to some
>> idle/quiescent value, then you'd need to do different reprogramming when
>> going back to "the" active state; I guess the system would need to
>> remember which state was active before switching to idle, then switch
>> back to that same state rather than hard-coding the active state name as
>> "active"...
> 
> I think the only sane way to deal with this is to make the I2C controller
> to show up as two separate I2C controller instances. Then use runtime
> PM to save and restore the state for each instance, and locking between
> the two driver instances.
> 
> For the pin muxing part, I'd do this:
> 
> 			i2c1 instance	i2c2 instance	notes
> default_state		0 pins		0 pins		(or dedicated pins only)
> active_state		all pins	alls pins
> idle_state		safe mode	safe mode
> 
> Then when i2c1 instance is done, it's runtime PM suspend muxes the pins
> to safe mode, or some nop state. Then when i2c2 instance is woken, it's
> runtime PM resume muxes pins to i2c2.

I see two issues with that approach:

1) Runtime PM doesn't always put a device into an idle state as soon as
its work is done. Sometimes (always?) there is a delay between when the
device is last used and when the HW is actually made idle so that if the
device is re-activated quickly, the kernel hasn't wasted time making it
idle then active again. You'd have to force that delay to complete when
switching between the two virtual controller devices.

2) This requires two separate device objects for the two I2C instances.
I guess you could have the driver for the one I2C mux node end up
instantiating two child devices for this purpose, and hence make that
happen without needing to change the DT ABI. However, that sure feels
complex...

I wonder if it wouldn't be better to have active/idle/sleep as
"modifiers" to the state name rather than alternatives, so you end up
with states named:

default
nobus:active
nobus:idle
nobus:sleep
bus0:active
bus0:idle
bus0:sleep
bus1:active
bus1:idle
bus1:sleep

Of course, if you continue on with that approach (i.e. you add more
sub-fields each separated by a colon), you end up with a huge
combinatorial mess of state names.


From swarren at wwwdotorg.org  Fri Jul 19 15:03:37 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 19 Jul 2013 13:03:37 -0600
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <51E91516.2040301@ti.com>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost> <51E70B5D.6030802@wwwdotorg.org>
 <20130718073638.GP7656@atomide.com> <51E84180.6080902@wwwdotorg.org>
 <20130719073957.GZ7656@atomide.com> <51E91516.2040301@ti.com>
Message-ID: <51E98D89.9050407@wwwdotorg.org>

On 07/19/2013 04:29 AM, Grygorii Strashko wrote:
> Hi Tony, Stephen
> 
> On 07/19/2013 10:39 AM, Tony Lindgren wrote:
>> * Stephen Warren <swarren at wwwdotorg.org> [130718 12:33]:
>>> On 07/18/2013 01:36 AM, Tony Lindgren wrote:
>>>> * Stephen Warren <swarren at wwwdotorg.org> [130717 14:30]:
>>>>> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
>>> ...
>>>>> Why shouldn't e.g. a pinctrl-based I2C mux also be able to do runtime
>>>>> PM? Does the mux setting select which states are used for runtime
>>>>> PM, or
>>>>> does runtime PM override the basic mux setting, or must the pincrl-I2C
>>>>> mux manually implement custom runtime-PM/pinctrl interaction since
>>>>> there's no generic answer to those questions? How many more custom
>>>>> exceptions will there be?
>>>>
>>>> The idea is that runtime PM will never touch the basic mux settings
>>>> at all. The "default" state should be considered a static state
>>>> that is claimed during driver probe, and released when the driver
>>>> is unloaded. This is typically let's say 90% of the pins for any
>>>> device.
>>>>
>>>> For runtime PM, we can just toggle the PM related pinctrl states as
>>>> they have been verified to match the active state during init.
>>>>
>>>> So I don't see why pinctrl-I2C would have to do anything specific.
>>>> All that is required is that the pins are grouped for the consumer
>>>> driver, and we can provide some automated checks on the states for
>>>> runtime PM.
>>>
>>> So, consider a pinctrl-based I2C mux. It has 2 states to cover two I2C
>>> buses:
>>>
>>> a) bus 1: I2C controller is muxed out onto one set of pins.
>>>
>>> b) bus 2: I2C controller is muxed out onto another set of pins.
>>>
>>> Now, the system could go idle in either of those 2 states, and then
>>> later need to return to one of those states. I just don't see how that
>>> would work, since the runtime PM code in this series switches to *an*
>>> active state when the device becomes non-idle. If the definition of the
>>> idle state switches the mux function for both sets of pins to some
>>> idle/quiescent value, then you'd need to do different reprogramming when
>>> going back to "the" active state; I guess the system would need to
>>> remember which state was active before switching to idle, then switch
>>> back to that same state rather than hard-coding the active state name as
>>> "active"...
>>
>> I think the only sane way to deal with this is to make the I2C controller
>> to show up as two separate I2C controller instances. Then use runtime
>> PM to save and restore the state for each instance, and locking between
>> the two driver instances.
>>
>> For the pin muxing part, I'd do this:
>>
>>             i2c1 instance    i2c2 instance    notes
>> default_state        0 pins        0 pins        (or dedicated pins only)
>> active_state        all pins    alls pins
>> idle_state        safe mode    safe mode
>>
>> Then when i2c1 instance is done, it's runtime PM suspend muxes the pins
>> to safe mode, or some nop state. Then when i2c2 instance is woken, it's
>> runtime PM resume muxes pins to i2c2.
> 
> First of all, I'd like to mention that these patches do *not* connect
> pinctrl to PM runtime, so until driver will call pinctrl_select_state()
> or pinctrl_pm_select_*() there will be no pins state changes.

Isn't the whole point of the pinctrl_pm_select*() APIs to eventually be
called automatically by the runtime PM core, so that we don't need to
write code to do this in every single driver, just like we moved the
call to pinctrl_select_state(default) into the device core so that we
didn't have to make every device do that manually?

> (As result, i2c-mux is not good example, seems:))

As such, I think all situations are good examples, because a generic
feature has to work in all cases.

The description you gave of the behavioural changes this patch creates
seems accurate at a quick glance.


From joe at perches.com  Fri Jul 19 15:12:11 2013
From: joe at perches.com (Joe Perches)
Date: Fri, 19 Jul 2013 12:12:11 -0700
Subject: [PATCH 2/2] clk/zynq/pll: Use #defines for fbdiv min/max values
In-Reply-To: <1632076624.115.1374260902674.JavaMail.mail@webmail02>
References: <1374254205-9912-1-git-send-email-soren.brinkmann@xilinx.com>
 <1632076624.115.1374260902674.JavaMail.mail@webmail02>
Message-ID: <1374261131.2059.5.camel@joe-AO722>

On Fri, 2013-07-19 at 10:16 -0700, Soren Brinkmann wrote:
> Use more descriptive #defines for the minimum and maximum PLL
> feedback divider.

trivial

> diff --git a/drivers/clk/zynq/pll.c b/drivers/clk/zynq/pll.c
[]
> @@ -63,10 +66,10 @@ static long zynq_pll_round_rate(struct clk_hw *hw, unsigned long rate,
>  	u32 fbdiv;
>  
>  	fbdiv = DIV_ROUND_CLOSEST(rate, *prate);
> -	if (fbdiv < 13)
> -		fbdiv = 13;
> -	else if (fbdiv > 66)
> -		fbdiv = 66;
> +	if (fbdiv < PLL_FBDIV_MIN)
> +		fbdiv = PLL_FBDIV_MIN;
> +	else if (fbdiv > PLL_FBDIV_MAX)
> +		fbdiv = PLL_FBDIV_MAX;

clamp




From swarren at wwwdotorg.org  Fri Jul 19 15:34:19 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 19 Jul 2013 13:34:19 -0600
Subject: [PATCH v4 13/17] clocksource: tegra: Switch to
 sched_clock_register()
In-Reply-To: <1374189690-10810-14-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-14-git-send-email-sboyd@codeaurora.org>
Message-ID: <51E994BB.5070306@wwwdotorg.org>

On 07/18/2013 05:21 PM, Stephen Boyd wrote:
> The 32 bit sched_clock interface now supports 64 bits. Upgrade to
> the 64 bit function to allow us to remove the 32 bit registration
> interface.

Acked-by: Stephen Warren <swarren at nvidia.com>
Tested-by: Stephen Warren <swarren at nvidia.com>


From swarren at wwwdotorg.org  Fri Jul 19 15:34:53 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 19 Jul 2013 13:34:53 -0600
Subject: [PATCH v4 07/17] clocksource: bcm2835: Switch to
 sched_clock_register()
In-Reply-To: <1374189690-10810-8-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-8-git-send-email-sboyd@codeaurora.org>
Message-ID: <51E994DD.6010305@wwwdotorg.org>

On 07/18/2013 05:21 PM, Stephen Boyd wrote:
> The 32 bit sched_clock interface now supports 64 bits. Upgrade to
> the 64 bit function to allow us to remove the 32 bit registration
> interface.

Acked-by: Stephen Warren <swarren at wwwdotorg.org>



From linux at arm.linux.org.uk  Fri Jul 19 17:49:07 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Jul 2013 22:49:07 +0100
Subject: [PATCH 10/22] ARM: ux500: Remove '0x's from Exynos5420 DTS file
In-Reply-To: <1374242333-6852-10-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
 <1374242333-6852-10-git-send-email-lee.jones@linaro.org>
Message-ID: <20130719214907.GI24642@n2100.arm.linux.org.uk>

On Fri, Jul 19, 2013 at 02:58:41PM +0100, Lee Jones wrote:
> Cc: Kukjin Kim <kgene.kim at samsung.com>
> Cc: linux-samsung-soc at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  arch/arm/boot/dts/exynos5420.dtsi | 2 +-

One question.  What have all these files got to do with ux500 ?


From csd at broadcom.com  Fri Jul 19 19:33:37 2013
From: csd at broadcom.com (Christian Daudt)
Date: Fri, 19 Jul 2013 16:33:37 -0700
Subject: [PATCH 0/2] ARM: bcm281xx: Board specific reboot code
In-Reply-To: <CAPdLdq=0k56kX01easzTb11AUo=Ew+DCrmMpq8=2ruEJEuMF3Q@mail.gmail.com>
References: <1372453018-5830-1-git-send-email-markus.mayer@linaro.org>
 <CAPdLdq=0k56kX01easzTb11AUo=Ew+DCrmMpq8=2ruEJEuMF3Q@mail.gmail.com>
Message-ID: <51E9CCD1.60903@broadcom.com>

On 13-06-28 02:00 PM, Markus Mayer wrote:
> Adding Christian who got dropped from the Cc list.
>
> -Markus
>
> On 28 June 2013 13:56, Markus Mayer <markus.mayer at linaro.org> wrote:
>> This patch series adds reboot code and related device tree bindings needed
>> for the bcm281xx family.
>>
>> Markus Mayer (2):
>>    ARM: bcm281xx: Board specific reboot code
>>    ARM: bcm281xx: DT changes for reboot code
>>
>>   .../devicetree/bindings/arm/bcm/bcm,kona-wdt.txt   |   15 ++++++
>>   arch/arm/boot/dts/bcm11351.dtsi                    |    7 ++-
>>   arch/arm/mach-bcm/Makefile                         |    4 +-
>>   arch/arm/mach-bcm/board_bcm.c                      |   20 ++++++--
>>   arch/arm/mach-bcm/kona.c                           |   54 ++++++++++++++++++++
>>   arch/arm/mach-bcm/kona.h                           |   15 ++++++
>>   6 files changed, 109 insertions(+), 6 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/arm/bcm/bcm,kona-wdt.txt
>>   create mode 100644 arch/arm/mach-bcm/kona.c
>>   create mode 100644 arch/arm/mach-bcm/kona.h
>>
>> --
>> 1.7.9.5
>>
>>
Pulled into bcm tree branch for-3.12/dt

  thanks,
    csd





From gregkh at linuxfoundation.org  Fri Jul 19 19:49:44 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Fri, 19 Jul 2013 16:49:44 -0700
Subject: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner's
 Security ID fuses
In-Reply-To: <20130719094211.GD5106@lukather>
References: <20130624214615.GA17604@kroah.com> <51CAA709.4060801@schinagl.nl>
 <20130626175144.GC2222@kroah.com> <51D674BF.9030207@schinagl.nl>
 <20130706193646.GB9778@kroah.com> <51E466A3.4010503@schinagl.nl>
 <20130716064107.GA10868@kroah.com> <20130717114650.GN3125@lukather>
 <20130717161758.GA9822@kroah.com> <20130719094211.GD5106@lukather>
Message-ID: <20130719234944.GA11498@kroah.com>

On Fri, Jul 19, 2013 at 11:42:11AM +0200, Maxime Ripard wrote:
> On Wed, Jul 17, 2013 at 09:17:58AM -0700, Greg KH wrote:
> > On Wed, Jul 17, 2013 at 01:46:50PM +0200, Maxime Ripard wrote:
> > > On Mon, Jul 15, 2013 at 11:41:07PM -0700, Greg KH wrote:
> > > > On Mon, Jul 15, 2013 at 11:16:19PM +0200, Oliver Schinagl wrote:
> > > > > So using these new patches for binary attributes, how can I pass data 
> > > > > between my driver and the sysfs files using a platform_driver? Or are 
> > > > > other 'hacks' needed and using the .groups attribute from 
> > > > > platform_driver->device_driver->groups is really the wrong approach.
> > > > > 
> > > > > I did ask around and still haven't figured it out so far, so I do 
> > > > > apologize if you feel I'm wasting your precious time.
> > > > 
> > > > How is the platform device not the same thing that was passed to your
> > > > probe function?
> > > 
> > > One thing I don't get here is why it should be set in the
> > > platform_driver structure. From my understanding of the device model,
> > > and since what Oliver is trying to do is exposing a few bytes of memory
> > > to sysfs, shouldn't the sysfs file be attached to the device instead?
> > 
> > It will be created by the driver core for any device attached to the
> > driver automatically.
> > 
> > > I mean, here, the sysfs file will be created under something like
> > > .../drivers/sunxi-sid/eeprom. What happens when you have several
> > > instances of that driver loaded? I'd expect it to have several sysfs
> > > files created, one for each instance. So to me, it should be in the
> > > device structure, not the driver one.
> > 
> > You can't have multiple drivers with the same name loaded (or the same
> > module loaded multiple times.)  You can have multiple devices for a
> > single driver, which is what we do all the time.
> 
> Yes, I know that, and it's actually my point.
> With the current oliver's code he pasted earlier in this thread:
> 
> # find /sys/ -name eeprom
> /sys/bus/platform/drivers/sunxi-sid/eeprom
> 
> While I'd expect the eeprom file to be located in
> /sys/bus/platform/devices/X.eeprom/eeprom like it used to be in the v4,
> since it's an instance-specific content.

Oh crap.  You are totally right.  That's why we added the new device
create call, to allow this to work properly.

Right now you are getting the kobject of the driver, not the device, in
the callback, which is not what you want (sure, if you only have once
instance, you can work around it, but don't it's the driver core's fault
for not giving you the correct api...)

Let me go look at how I can make this work "easier", give me a few days.

greg k-h


From gregkh at linuxfoundation.org  Fri Jul 19 19:50:55 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Fri, 19 Jul 2013 16:50:55 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51E8DE51.1060404@ti.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-2-git-send-email-kishon@ti.com>
 <20130718072004.GA16720@kroah.com> <51E7AE88.3050007@ti.com>
 <20130718154954.GA31961@kroah.com> <51E8D086.809@ti.com>
 <20130719054311.GA14638@kroah.com> <51E8D4E0.8060200@ti.com>
 <20130719062941.GA23611@kroah.com> <51E8DE51.1060404@ti.com>
Message-ID: <20130719235055.GB11498@kroah.com>

On Fri, Jul 19, 2013 at 12:06:01PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Friday 19 July 2013 11:59 AM, Greg KH wrote:
> > On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote:
> >> Hi,
> >>
> >> On Friday 19 July 2013 11:13 AM, Greg KH wrote:
> >>> On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote:
> >>>>>>>> +	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
> >>>>>>>
> >>>>>>> Your naming is odd, no "phy" anywhere in it?  You rely on the sender to
> >>>>>>> never send a duplicate name.id pair?  Why not create your own ids based
> >>>>>>> on the number of phys in the system, like almost all other classes and
> >>>>>>> subsystems do?
> >>>>>>
> >>>>>> hmm.. some PHY drivers use the id they provide to perform some of their
> >>>>>> internal operation as in [1] (This is used only if a single PHY provider
> >>>>>> implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO
> >>>>>> to give the PHY drivers an option to use auto id.
> >>>>>>
> >>>>>> [1] ->
> >>>>>> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> >>>>>
> >>>>> No, who cares about the id?  No one outside of the phy core ever should,
> >>>>> because you pass back the only pointer that they really do care about,
> >>>>> if they need to do anything with the device.  Use that, and then you can
> >>>>
> >>>> hmm.. ok.
> >>>>
> >>>>> rip out all of the "search for a phy by a string" logic, as that's not
> >>>>
> >>>> Actually this is needed for non-dt boot case. In the case of dt boot, we use a
> >>>> phandle by which the controller can get a reference to the phy. But in the case
> >>>> of non-dt boot, the controller can get a reference to the phy only by label.
> >>>
> >>> I don't understand.  They registered the phy, and got back a pointer to
> >>> it.  Why can't they save it in their local structure to use it again
> >>> later if needed?  They should never have to "ask" for the device, as the
> >>
> >> One is a *PHY provider* driver which is a driver for some PHY device. This will
> >> use phy_create to create the phy.
> >> The other is a *PHY consumer* driver which might be any controller driver (can
> >> be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference to the
> >> phy (by *phandle* in the case of dt boot and *label* in the case of non-dt boot).
> >>> device id might be unknown if there are multiple devices in the system.
> >>
> >> I agree with you on the device id part. That need not be known to the PHY driver.
> > 
> > How does a consumer know which "label" to use in a non-dt system if
> > there are multiple PHYs in the system?
> 
> That should be passed using platform data.

Ick, don't pass strings around, pass pointers.  If you have platform
data you can get to, then put the pointer there, don't use a "name".

thanks,

greg k-h


From tomasz.figa at gmail.com  Fri Jul 19 20:04:13 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:13 +0200
Subject: [PATCH v4 01/20] clocksource: samsung_pwm_timer: Do not request PWM
 mem region
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-2-git-send-email-tomasz.figa@gmail.com>

PWM registers are shared between clocksource and PWM drivers and so can
not be claimed for exclusive use.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/clocksource/samsung_pwm_timer.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index 584b547..3fa5b07 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -404,7 +404,6 @@ void __init samsung_pwm_clocksource_init(void __iomem *base,
 static void __init samsung_pwm_alloc(struct device_node *np,
 				     const struct samsung_pwm_variant *variant)
 {
-	struct resource res;
 	struct property *prop;
 	const __be32 *cur;
 	u32 val;
@@ -423,17 +422,9 @@ static void __init samsung_pwm_alloc(struct device_node *np,
 		pwm.variant.output_mask |= 1 << val;
 	}
 
-	of_address_to_resource(np, 0, &res);
-	if (!request_mem_region(res.start,
-				resource_size(&res), "samsung-pwm")) {
-		pr_err("%s: failed to request IO mem region\n", __func__);
-		return;
-	}
-
-	pwm.base = ioremap(res.start, resource_size(&res));
+	pwm.base = of_iomap(np, 0);
 	if (!pwm.base) {
 		pr_err("%s: failed to map PWM registers\n", __func__);
-		release_mem_region(res.start, resource_size(&res));
 		return;
 	}
 
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:12 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:12 +0200
Subject: [PATCH v4 00/20] Samsung PWM support cleanup
Message-ID: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>

Since we now have a proper Samsung PWM clocksource driver in place,
we can proceed with further cleanup of PWM timers support on Samsung SoCs.

This series attempts to achieve this goal by:
 1) fixing up few things in samsung_pwm_timer clocksource driver,
 2) moving remaining Samsung platforms to the new clocksource driver,
 3) removing old clocksource driver,
 4) adding new multiplatform- and DT-aware PWM driver,
 5) moving all Samsung platforms to use the new PWM driver,
 6) removing old PWM driver,
 7) removing all PWM-related code that is not used anymore.

Cleaning up the PWM driver is a bit tricky, because the design of current
driver makes it completely unsuitable for DT and multiplatform and would
require a heavy rework to make it usable, breaking any existing Samsung PWM
users by the way. To avoid any breakage this series first renames the old
driver, then adds new one using original name, migrates all platforms to
use it and then finally removes the old driver.

See particular patches for more detailed descriptions.

[On S3C6410-based Tiny6410 (Mini6410-compatible) with pwm-beeper, SMDK6410
with PWM backlight and Exynos4210-based Origen board (with PWM0 attached
to a scope)]
Tested-by: Tomasz Figa <tomasz.figa at gmail.com>

[On S3C2440-based Mini2440 board]
Tested-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>

[On a s3c2416 based machine]
Tested-by: Heiko Stuebner <heiko at sntech.de> 

[Also not sure on what boards, but still]
Tested-by: Mark Brown <broonie at linaro.org>

Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Thierry Reding <thierry.reding at gmail.com>
Acked-by: Heiko Stuebner <heiko at sntech.de> 

Changes since v3:
 - added two extra clocksource driver fixes to the series (patches 1, 2),
 - added comment explaining why only a simple synchronization is needed
   between clocksource and PWM drivers,
 - some stylistic fixes,
 - rebased to 3.11-rc1.
Changes since v2:
 - replaced __raw_{readl,writel} with {readl,writel},
 - corrected some commit messages,
 - used git format-patch -M to detect rename.
Changes since v1:
 - made sure that suspend/resume is handled correctly in both
   clocksource and PWM drivers,
 - fixed incorrect definition of AUTORELOAD bit for channel 4,
 - fixed order of registering PWM device and calling samsung_bl_set(),
   which assumes that PWM device has been already registered,
 - corrected commit messages of several patches,
 - addressed all the valid comments from reviewers, including cleanup
   of most code originally copied from previous PWM driver,
 - rebased on top of current Kgene's for-next,
 - tested on Exynos4210, verifying correct PWM output with a scope.

Tomasz Figa (20):
  clocksource: samsung_pwm_timer: Do not request PWM mem region
  clocksource: samsung_pwm_timer: Correct definition of AUTORELOAD bit
  clocksource: samsung_pwm_timer: Cache clocksource register address
  clocksource: samsung_pwm_timer: Do not use clocksource_mmio
  clocksource: samsung_pwm_timer: Handle suspend/resume correctly
  ARM: SAMSUNG: Unify base address definitions of timer block
  ARM: SAMSUNG: Add new PWM platform device
  ARM: SAMSUNG: Set PWM platform data
  ARM: SAMSUNG: Move all platforms to new clocksource driver
  ARM: SAMSUNG: Remove old samsung-time driver
  ARM: SAMSUNG: Remove unused PWM timer IRQ chip code
  pwm: samsung: Rename to pwm-samsung-legacy
  pwm: Add new pwm-samsung driver
  ARM: SAMSUNG: Rework private data handling in dev-backlight
  ARM: SAMSUNG: Modify board files to use new PWM platform device
  pwm: Remove superseded pwm-samsung-legacy driver
  ARM: SAMSUNG: Remove old PWM timer platform devices
  ARM: SAMSUNG: Remove pwm-clock infrastructure
  ARM: SAMSUNG: Remove remaining uses of plat/regs-timer.h header
  ARM: SAMSUNG: Remove plat/regs-timer.h header

 arch/arm/Kconfig                                   |  11 +-
 arch/arm/mach-s3c24xx/Kconfig                      |   6 -
 arch/arm/mach-s3c24xx/clock-s3c2410.c              |   1 -
 arch/arm/mach-s3c24xx/clock-s3c2412.c              |   1 -
 arch/arm/mach-s3c24xx/clock-s3c2416.c              |   2 -
 arch/arm/mach-s3c24xx/clock-s3c2443.c              |   2 -
 arch/arm/mach-s3c24xx/common.c                     |  27 +
 arch/arm/mach-s3c24xx/include/mach/map.h           |   2 +
 arch/arm/mach-s3c24xx/mach-h1940.c                 |   4 +-
 arch/arm/mach-s3c24xx/mach-rx1950.c                |   5 +-
 arch/arm/mach-s3c64xx/Kconfig                      |   2 -
 arch/arm/mach-s3c64xx/clock.c                      |   2 -
 arch/arm/mach-s3c64xx/common.c                     |  32 +-
 arch/arm/mach-s3c64xx/include/mach/irqs.h          |   8 -
 arch/arm/mach-s3c64xx/include/mach/map.h           |   1 +
 arch/arm/mach-s3c64xx/irq-pm.c                     |   2 -
 arch/arm/mach-s3c64xx/mach-crag6410.c              |   4 +-
 arch/arm/mach-s3c64xx/mach-hmt.c                   |   4 +-
 arch/arm/mach-s3c64xx/mach-smartq.c                |   4 +-
 arch/arm/mach-s3c64xx/mach-smdk6410.c              |   5 +-
 arch/arm/mach-s5p64x0/Kconfig                      |   2 -
 arch/arm/mach-s5p64x0/clock-s5p6440.c              |   2 -
 arch/arm/mach-s5p64x0/clock-s5p6450.c              |   2 -
 arch/arm/mach-s5p64x0/common.c                     |  27 +
 arch/arm/mach-s5p64x0/include/mach/irqs.h          |   2 -
 arch/arm/mach-s5p64x0/include/mach/map.h           |   1 +
 arch/arm/mach-s5p64x0/mach-smdk6440.c              |   5 +-
 arch/arm/mach-s5p64x0/mach-smdk6450.c              |   5 +-
 arch/arm/mach-s5p64x0/pm.c                         |   3 -
 arch/arm/mach-s5pc100/Kconfig                      |   1 -
 arch/arm/mach-s5pc100/clock.c                      |   2 -
 arch/arm/mach-s5pc100/common.c                     |  28 +
 arch/arm/mach-s5pc100/include/mach/irqs.h          |   2 -
 arch/arm/mach-s5pc100/include/mach/map.h           |   1 +
 arch/arm/mach-s5pc100/mach-smdkc100.c              |   5 +-
 arch/arm/mach-s5pv210/Kconfig                      |   1 -
 arch/arm/mach-s5pv210/clock.c                      |   1 -
 arch/arm/mach-s5pv210/common.c                     |  28 +
 arch/arm/mach-s5pv210/include/mach/irqs.h          |   2 -
 arch/arm/mach-s5pv210/include/mach/map.h           |   1 +
 arch/arm/mach-s5pv210/mach-smdkv210.c              |   5 +-
 arch/arm/mach-s5pv210/pm.c                         |  10 -
 arch/arm/plat-samsung/Kconfig                      |  14 -
 arch/arm/plat-samsung/Makefile                     |   3 -
 arch/arm/plat-samsung/dev-backlight.c              |  61 +-
 arch/arm/plat-samsung/devs.c                       |  42 +-
 arch/arm/plat-samsung/include/plat/clock.h         |   4 -
 arch/arm/plat-samsung/include/plat/devs.h          |   1 +
 arch/arm/plat-samsung/include/plat/irq-vic-timer.h |  13 -
 arch/arm/plat-samsung/include/plat/irqs.h          |   9 -
 arch/arm/plat-samsung/include/plat/pwm-clock.h     |  81 ---
 arch/arm/plat-samsung/include/plat/pwm-core.h      |  24 +
 arch/arm/plat-samsung/include/plat/regs-timer.h    | 124 ----
 arch/arm/plat-samsung/include/plat/samsung-time.h  |  23 -
 arch/arm/plat-samsung/irq-vic-timer.c              |  98 ---
 arch/arm/plat-samsung/pwm-clock.c                  | 474 --------------
 arch/arm/plat-samsung/s5p-irq.c                    |   4 -
 arch/arm/plat-samsung/samsung-time.c               | 394 ------------
 drivers/clocksource/Kconfig                        |   1 -
 drivers/clocksource/samsung_pwm_timer.c            |  98 +--
 drivers/pwm/pwm-samsung.c                          | 701 ++++++++++++++-------
 61 files changed, 768 insertions(+), 1662 deletions(-)
 delete mode 100644 arch/arm/plat-samsung/include/plat/irq-vic-timer.h
 delete mode 100644 arch/arm/plat-samsung/include/plat/pwm-clock.h
 create mode 100644 arch/arm/plat-samsung/include/plat/pwm-core.h
 delete mode 100644 arch/arm/plat-samsung/include/plat/regs-timer.h
 delete mode 100644 arch/arm/plat-samsung/irq-vic-timer.c
 delete mode 100644 arch/arm/plat-samsung/pwm-clock.c
 delete mode 100644 arch/arm/plat-samsung/samsung-time.c

-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:14 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:14 +0200
Subject: [PATCH v4 02/20] clocksource: samsung_pwm_timer: Correct definition
 of AUTORELOAD bit
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-3-git-send-email-tomasz.figa@gmail.com>

PWM channel 4 has its autoreload bit located at different position. This
patch fixes the driver to account for that.

This fixes a problem with the clocksource hanging after it overflows because
it is not reloaded any more.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
Tested-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/clocksource/samsung_pwm_timer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index 3fa5b07..e238fb0 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -47,7 +47,8 @@
 #define TCON_START(chan)		(1 << (4 * (chan) + 0))
 #define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
 #define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
-#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
+#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) \
+						+ (((chan) < 5) ? 3 : 2)))
 
 DEFINE_SPINLOCK(samsung_pwm_lock);
 EXPORT_SYMBOL(samsung_pwm_lock);
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:17 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:17 +0200
Subject: [PATCH v4 04/20] clocksource: samsung_pwm_timer: Do not use
 clocksource_mmio
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-6-git-send-email-tomasz.figa@gmail.com>

In case of Samsung PWM timer, clocksource MMIO can not be used, because
custom suspend/resume callbacks are required.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/clocksource/Kconfig             |  1 -
 drivers/clocksource/samsung_pwm_timer.c | 19 +++++++++++++++----
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index b7b9b04..41c6946 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -99,7 +99,6 @@ config CLKSRC_EXYNOS_MCT
 
 config CLKSRC_SAMSUNG_PWM
 	bool
-	select CLKSRC_MMIO
 	help
 	  This is a new clocksource driver for the PWM timer found in
 	  Samsung S3C, S5P and Exynos SoCs, replacing an earlier driver
diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index 823279b..753ffec 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -288,6 +288,18 @@ static void __init samsung_clockevent_init(void)
 	}
 }
 
+static cycle_t samsung_clocksource_read(struct clocksource *c)
+{
+	return ~readl_relaxed(pwm.source_reg);
+}
+
+static struct clocksource samsung_clocksource = {
+	.name		= "samsung_clocksource_timer",
+	.rating		= 250,
+	.read		= samsung_clocksource_read,
+	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
+};
+
 /*
  * Override the global weak sched_clock symbol with this
  * local implementation which uses the clocksource to get some
@@ -297,7 +309,7 @@ static void __init samsung_clockevent_init(void)
  */
 static u32 notrace samsung_read_sched_clock(void)
 {
-	return ~__raw_readl(pwm.source_reg);
+	return samsung_clocksource_read(NULL);
 }
 
 static void __init samsung_clocksource_init(void)
@@ -324,9 +336,8 @@ static void __init samsung_clocksource_init(void)
 	setup_sched_clock(samsung_read_sched_clock,
 						pwm.variant.bits, clock_rate);
 
-	ret = clocksource_mmio_init(pwm.source_reg, "samsung_clocksource_timer",
-					clock_rate, 250, pwm.variant.bits,
-					clocksource_mmio_readl_down);
+	samsung_clocksource.mask = CLOCKSOURCE_MASK(pwm.variant.bits);
+	ret = clocksource_register_hz(&samsung_clocksource, clock_rate);
 	if (ret)
 		panic("samsung_clocksource_timer: can't register clocksource\n");
 }
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:15 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:15 +0200
Subject: [PATCH v4 02/20] clocksource: samsung_pwm_timer: Correct definition
 of AUTORELOAD bit
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-4-git-send-email-tomasz.figa@gmail.com>

PWM channel 4 has its autoreload bit located at different position. This
patch fixes the driver to account for that.

This fixes a problem with the clocksource hanging after it overflows because
it is not reloaded any more.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/clocksource/samsung_pwm_timer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index 3fa5b07..e238fb0 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -47,7 +47,8 @@
 #define TCON_START(chan)		(1 << (4 * (chan) + 0))
 #define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
 #define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
-#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
+#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) \
+						+ (((chan) < 5) ? 3 : 2)))
 
 DEFINE_SPINLOCK(samsung_pwm_lock);
 EXPORT_SYMBOL(samsung_pwm_lock);
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:16 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:16 +0200
Subject: [PATCH v4 03/20] clocksource: samsung_pwm_timer: Cache clocksource
 register address
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-5-git-send-email-tomasz.figa@gmail.com>

Instead of calculating register every time the timer should be read,
we can just do it one time at initialization and store the address in
driver data.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/clocksource/samsung_pwm_timer.c | 33 ++++++++-------------------------
 1 file changed, 8 insertions(+), 25 deletions(-)

diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index e238fb0..823279b 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -55,6 +55,7 @@ EXPORT_SYMBOL(samsung_pwm_lock);
 
 struct samsung_pwm_clocksource {
 	void __iomem *base;
+	void __iomem *source_reg;
 	unsigned int irq[SAMSUNG_PWM_NUM];
 	struct samsung_pwm_variant variant;
 
@@ -287,23 +288,6 @@ static void __init samsung_clockevent_init(void)
 	}
 }
 
-static void __iomem *samsung_timer_reg(void)
-{
-	switch (pwm.source_id) {
-	case 0:
-	case 1:
-	case 2:
-	case 3:
-		return pwm.base + pwm.source_id * 0x0c + 0x14;
-
-	case 4:
-		return pwm.base + 0x40;
-
-	default:
-		BUG();
-	}
-}
-
 /*
  * Override the global weak sched_clock symbol with this
  * local implementation which uses the clocksource to get some
@@ -313,17 +297,11 @@ static void __iomem *samsung_timer_reg(void)
  */
 static u32 notrace samsung_read_sched_clock(void)
 {
-	void __iomem *reg = samsung_timer_reg();
-
-	if (!reg)
-		return 0;
-
-	return ~__raw_readl(reg);
+	return ~__raw_readl(pwm.source_reg);
 }
 
 static void __init samsung_clocksource_init(void)
 {
-	void __iomem *reg = samsung_timer_reg();
 	unsigned long pclk;
 	unsigned long clock_rate;
 	int ret;
@@ -338,10 +316,15 @@ static void __init samsung_clocksource_init(void)
 	samsung_time_setup(pwm.source_id, pwm.tcnt_max);
 	samsung_time_start(pwm.source_id, true);
 
+	if (pwm.source_id == 4)
+		pwm.source_reg = pwm.base + 0x40;
+	else
+		pwm.source_reg = pwm.base + pwm.source_id * 0x0c + 0x14;
+
 	setup_sched_clock(samsung_read_sched_clock,
 						pwm.variant.bits, clock_rate);
 
-	ret = clocksource_mmio_init(reg, "samsung_clocksource_timer",
+	ret = clocksource_mmio_init(pwm.source_reg, "samsung_clocksource_timer",
 					clock_rate, 250, pwm.variant.bits,
 					clocksource_mmio_readl_down);
 	if (ret)
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:18 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:18 +0200
Subject: [PATCH v4 05/20] clocksource: samsung_pwm_timer: Handle
 suspend/resume correctly
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-7-git-send-email-tomasz.figa@gmail.com>

Current suspend/resume handling of the driver was broken, because:
 - periodic timer was being enabled in CLOCK_EVT_MODE_RESUME mode, which
   does not seem to be correct behavior looking at other platforms,
 - PWM divisors need to be restored, but they were not,
 - clockevent interrupt mask needs to be restored, but it was not,
 - clocksource was being restored in clockevent resume callback.

This patch fixes issues mentioned above, making suspend/resume handling
in the driver correct.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/clocksource/samsung_pwm_timer.c | 42 ++++++++++++++++++++++-----------
 1 file changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index 753ffec..282e0e2 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -197,17 +197,6 @@ static int samsung_set_next_event(unsigned long cycles,
 	return 0;
 }
 
-static void samsung_timer_resume(void)
-{
-	/* event timer restart */
-	samsung_time_setup(pwm.event_id, pwm.clock_count_per_tick - 1);
-	samsung_time_start(pwm.event_id, true);
-
-	/* source timer restart */
-	samsung_time_setup(pwm.source_id, pwm.tcnt_max);
-	samsung_time_start(pwm.source_id, true);
-}
-
 static void samsung_set_mode(enum clock_event_mode mode,
 				struct clock_event_device *evt)
 {
@@ -224,20 +213,29 @@ static void samsung_set_mode(enum clock_event_mode mode,
 
 	case CLOCK_EVT_MODE_UNUSED:
 	case CLOCK_EVT_MODE_SHUTDOWN:
-		break;
-
 	case CLOCK_EVT_MODE_RESUME:
-		samsung_timer_resume();
 		break;
 	}
 }
 
+static void samsung_clockevent_resume(struct clock_event_device *cev)
+{
+	samsung_timer_set_prescale(pwm.event_id, pwm.tscaler_div);
+	samsung_timer_set_divisor(pwm.event_id, pwm.tdiv);
+
+	if (pwm.variant.has_tint_cstat) {
+		u32 mask = (1 << pwm.event_id);
+		writel(mask | (mask << 5), pwm.base + REG_TINT_CSTAT);
+	}
+}
+
 static struct clock_event_device time_event_device = {
 	.name		= "samsung_event_timer",
 	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
 	.rating		= 200,
 	.set_next_event	= samsung_set_next_event,
 	.set_mode	= samsung_set_mode,
+	.resume		= samsung_clockevent_resume,
 };
 
 static irqreturn_t samsung_clock_event_isr(int irq, void *dev_id)
@@ -288,6 +286,20 @@ static void __init samsung_clockevent_init(void)
 	}
 }
 
+static void samsung_clocksource_suspend(struct clocksource *cs)
+{
+	samsung_time_stop(pwm.source_id);
+}
+
+static void samsung_clocksource_resume(struct clocksource *cs)
+{
+	samsung_timer_set_prescale(pwm.source_id, pwm.tscaler_div);
+	samsung_timer_set_divisor(pwm.source_id, pwm.tdiv);
+
+	samsung_time_setup(pwm.source_id, pwm.tcnt_max);
+	samsung_time_start(pwm.source_id, true);
+}
+
 static cycle_t samsung_clocksource_read(struct clocksource *c)
 {
 	return ~readl_relaxed(pwm.source_reg);
@@ -297,6 +309,8 @@ static struct clocksource samsung_clocksource = {
 	.name		= "samsung_clocksource_timer",
 	.rating		= 250,
 	.read		= samsung_clocksource_read,
+	.suspend	= samsung_clocksource_suspend,
+	.resume		= samsung_clocksource_resume,
 	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:21 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:21 +0200
Subject: [PATCH v4 08/20] ARM: SAMSUNG: Set PWM platform data
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-10-git-send-email-tomasz.figa@gmail.com>

From: Tomasz Figa <t.figa at samsung.com>

This patch adds PWM platform data needed for legacy (non-DT) platforms
to handle SoC-specific bits of the PWM/timer block.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/mach-s3c24xx/common.c | 11 +++++++++++
 arch/arm/mach-s3c64xx/common.c | 11 +++++++++++
 arch/arm/mach-s5p64x0/common.c | 10 ++++++++++
 arch/arm/mach-s5pc100/common.c | 11 +++++++++++
 arch/arm/mach-s5pv210/common.c | 11 +++++++++++
 5 files changed, 54 insertions(+)

diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index c157103..e5e7d7d 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -27,6 +27,7 @@
 #include <linux/interrupt.h>
 #include <linux/ioport.h>
 #include <linux/serial_core.h>
+#include <clocksource/samsung_pwm.h>
 #include <linux/platform_device.h>
 #include <linux/delay.h>
 #include <linux/io.h>
@@ -49,6 +50,7 @@
 #include <plat/clock.h>
 #include <plat/cpu-freq.h>
 #include <plat/pll.h>
+#include <plat/pwm-core.h>
 
 #include "common.h"
 
@@ -216,6 +218,13 @@ static void s3c24xx_default_idle(void)
 		     S3C2410_CLKCON);
 }
 
+static struct samsung_pwm_variant s3c24xx_pwm_variant = {
+	.bits		= 16,
+	.div_base	= 1,
+	.has_tint_cstat	= false,
+	.tclk_mask	= (1 << 4),
+};
+
 void __init s3c24xx_init_io(struct map_desc *mach_desc, int size)
 {
 	arm_pm_idle = s3c24xx_default_idle;
@@ -232,6 +241,8 @@ void __init s3c24xx_init_io(struct map_desc *mach_desc, int size)
 	s3c24xx_init_cpu();
 
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+
+	samsung_pwm_set_platdata(&s3c24xx_pwm_variant);
 }
 
 /* Serial port registrations */
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 3f62e46..ca05e61 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -27,6 +27,7 @@
 #include <linux/irq.h>
 #include <linux/gpio.h>
 #include <linux/irqchip/arm-vic.h>
+#include <clocksource/samsung_pwm.h>
 
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
@@ -43,6 +44,7 @@
 #include <plat/gpio-cfg.h>
 #include <plat/irq-uart.h>
 #include <plat/irq-vic-timer.h>
+#include <plat/pwm-core.h>
 #include <plat/regs-irqtype.h>
 #include <plat/regs-serial.h>
 #include <plat/watchdog-reset.h>
@@ -149,6 +151,13 @@ static struct device s3c64xx_dev = {
 	.bus	= &s3c64xx_subsys,
 };
 
+static struct samsung_pwm_variant s3c64xx_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 7) | (1 << 6) | (1 << 5),
+};
+
 /* read cpu identification code */
 
 void __init s3c64xx_init_io(struct map_desc *mach_desc, int size)
@@ -161,6 +170,8 @@ void __init s3c64xx_init_io(struct map_desc *mach_desc, int size)
 	s3c64xx_init_cpu();
 
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+
+	samsung_pwm_set_platdata(&s3c64xx_pwm_variant);
 }
 
 static __init int s3c64xx_dev_init(void)
diff --git a/arch/arm/mach-s5p64x0/common.c b/arch/arm/mach-s5p64x0/common.c
index dfdfdc3..49687f2 100644
--- a/arch/arm/mach-s5p64x0/common.c
+++ b/arch/arm/mach-s5p64x0/common.c
@@ -19,6 +19,7 @@
 #include <linux/io.h>
 #include <linux/device.h>
 #include <linux/serial_core.h>
+#include <clocksource/samsung_pwm.h>
 #include <linux/platform_device.h>
 #include <linux/sched.h>
 #include <linux/dma-mapping.h>
@@ -47,6 +48,7 @@
 #include <plat/fb-core.h>
 #include <plat/spi-core.h>
 #include <plat/gpio-cfg.h>
+#include <plat/pwm-core.h>
 #include <plat/regs-irqtype.h>
 #include <plat/regs-serial.h>
 #include <plat/watchdog-reset.h>
@@ -157,6 +159,13 @@ static void s5p64x0_idle(void)
 	cpu_do_idle();
 }
 
+static struct samsung_pwm_variant s5p64x0_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= 0,
+};
+
 /*
  * s5p64x0_map_io
  *
@@ -176,6 +185,7 @@ void __init s5p64x0_init_io(struct map_desc *mach_desc, int size)
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
 	samsung_wdt_reset_init(S3C_VA_WATCHDOG);
 
+	samsung_pwm_set_platdata(&s5p64x0_pwm_variant);
 }
 
 void __init s5p6440_map_io(void)
diff --git a/arch/arm/mach-s5pc100/common.c b/arch/arm/mach-s5pc100/common.c
index 4bdfecf..e0600af 100644
--- a/arch/arm/mach-s5pc100/common.c
+++ b/arch/arm/mach-s5pc100/common.c
@@ -22,6 +22,7 @@
 #include <linux/io.h>
 #include <linux/device.h>
 #include <linux/serial_core.h>
+#include <clocksource/samsung_pwm.h>
 #include <linux/platform_device.h>
 #include <linux/sched.h>
 #include <linux/reboot.h>
@@ -46,6 +47,7 @@
 #include <plat/fb-core.h>
 #include <plat/iic-core.h>
 #include <plat/onenand-core.h>
+#include <plat/pwm-core.h>
 #include <plat/spi-core.h>
 #include <plat/regs-serial.h>
 #include <plat/watchdog-reset.h>
@@ -132,6 +134,13 @@ static struct map_desc s5pc100_iodesc[] __initdata = {
 	}
 };
 
+static struct samsung_pwm_variant s5pc100_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 5),
+};
+
 /*
  * s5pc100_map_io
  *
@@ -149,6 +158,8 @@ void __init s5pc100_init_io(struct map_desc *mach_desc, int size)
 	s5p_init_cpu(S5P_VA_CHIPID);
 
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+
+	samsung_pwm_set_platdata(&s5pc100_pwm_variant);
 }
 
 void __init s5pc100_map_io(void)
diff --git a/arch/arm/mach-s5pv210/common.c b/arch/arm/mach-s5pv210/common.c
index 023f1a7..306b29a 100644
--- a/arch/arm/mach-s5pv210/common.c
+++ b/arch/arm/mach-s5pv210/common.c
@@ -19,6 +19,7 @@
 #include <linux/clk.h>
 #include <linux/io.h>
 #include <linux/device.h>
+#include <clocksource/samsung_pwm.h>
 #include <linux/platform_device.h>
 #include <linux/sched.h>
 #include <linux/dma-mapping.h>
@@ -42,6 +43,7 @@
 #include <plat/fimc-core.h>
 #include <plat/iic-core.h>
 #include <plat/keypad-core.h>
+#include <plat/pwm-core.h>
 #include <plat/tv-core.h>
 #include <plat/spi-core.h>
 #include <plat/regs-serial.h>
@@ -148,6 +150,13 @@ void s5pv210_restart(enum reboot_mode mode, const char *cmd)
 	__raw_writel(0x1, S5P_SWRESET);
 }
 
+static struct samsung_pwm_variant s5pv210_pwm_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= (1 << 5),
+};
+
 /*
  * s5pv210_map_io
  *
@@ -165,6 +174,8 @@ void __init s5pv210_init_io(struct map_desc *mach_desc, int size)
 	s5p_init_cpu(S5P_VA_CHIPID);
 
 	s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
+
+	samsung_pwm_set_platdata(&s5pv210_pwm_variant);
 }
 
 void __init s5pv210_map_io(void)
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:19 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:19 +0200
Subject: [PATCH v4 06/20] ARM: SAMSUNG: Unify base address definitions of
 timer block
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-8-git-send-email-tomasz.figa@gmail.com>

From: Tomasz Figa <t.figa at samsung.com>

This patch makes all defintions of timer block base address use the same
prefix to allow using the common name to define platform device
resource.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/mach-s3c24xx/include/mach/map.h | 2 ++
 arch/arm/mach-s3c64xx/include/mach/map.h | 1 +
 arch/arm/mach-s5p64x0/include/mach/map.h | 1 +
 arch/arm/mach-s5pc100/include/mach/map.h | 1 +
 arch/arm/mach-s5pv210/include/mach/map.h | 1 +
 5 files changed, 6 insertions(+)

diff --git a/arch/arm/mach-s3c24xx/include/mach/map.h b/arch/arm/mach-s3c24xx/include/mach/map.h
index 8ba381f..444793f 100644
--- a/arch/arm/mach-s3c24xx/include/mach/map.h
+++ b/arch/arm/mach-s3c24xx/include/mach/map.h
@@ -167,4 +167,6 @@
 #define S3C_PA_SPI0		S3C2443_PA_SPI0
 #define S3C_PA_SPI1		S3C2443_PA_SPI1
 
+#define SAMSUNG_PA_TIMER	S3C2410_PA_TIMER
+
 #endif /* __ASM_ARCH_MAP_H */
diff --git a/arch/arm/mach-s3c64xx/include/mach/map.h b/arch/arm/mach-s3c64xx/include/mach/map.h
index 8e2097b..f55ccb1 100644
--- a/arch/arm/mach-s3c64xx/include/mach/map.h
+++ b/arch/arm/mach-s3c64xx/include/mach/map.h
@@ -121,5 +121,6 @@
 #define SAMSUNG_PA_ADC		S3C64XX_PA_ADC
 #define SAMSUNG_PA_CFCON	S3C64XX_PA_CFCON
 #define SAMSUNG_PA_KEYPAD	S3C64XX_PA_KEYPAD
+#define SAMSUNG_PA_TIMER	S3C64XX_PA_TIMER
 
 #endif /* __ASM_ARCH_6400_MAP_H */
diff --git a/arch/arm/mach-s5p64x0/include/mach/map.h b/arch/arm/mach-s5p64x0/include/mach/map.h
index 0c0175d..50a6e96 100644
--- a/arch/arm/mach-s5p64x0/include/mach/map.h
+++ b/arch/arm/mach-s5p64x0/include/mach/map.h
@@ -76,6 +76,7 @@
 #define S5P_PA_TIMER		S5P64X0_PA_TIMER
 
 #define SAMSUNG_PA_ADC		S5P64X0_PA_ADC
+#define SAMSUNG_PA_TIMER	S5P64X0_PA_TIMER
 
 /* UART */
 
diff --git a/arch/arm/mach-s5pc100/include/mach/map.h b/arch/arm/mach-s5pc100/include/mach/map.h
index 54bc4f8..2550b61 100644
--- a/arch/arm/mach-s5pc100/include/mach/map.h
+++ b/arch/arm/mach-s5pc100/include/mach/map.h
@@ -116,6 +116,7 @@
 #define SAMSUNG_PA_ADC			S5PC100_PA_TSADC
 #define SAMSUNG_PA_CFCON		S5PC100_PA_CFCON
 #define SAMSUNG_PA_KEYPAD		S5PC100_PA_KEYPAD
+#define SAMSUNG_PA_TIMER		S5PC100_PA_TIMER
 
 #define S5PC100_VA_OTHERS		(S3C_VA_SYS + 0x10000)
 
diff --git a/arch/arm/mach-s5pv210/include/mach/map.h b/arch/arm/mach-s5pv210/include/mach/map.h
index b7c8a19..763929a 100644
--- a/arch/arm/mach-s5pv210/include/mach/map.h
+++ b/arch/arm/mach-s5pv210/include/mach/map.h
@@ -139,6 +139,7 @@
 #define SAMSUNG_PA_ADC			S5PV210_PA_ADC
 #define SAMSUNG_PA_CFCON		S5PV210_PA_CFCON
 #define SAMSUNG_PA_KEYPAD		S5PV210_PA_KEYPAD
+#define SAMSUNG_PA_TIMER		S5PV210_PA_TIMER
 
 /* UART */
 
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:20 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:20 +0200
Subject: [PATCH v4 07/20] ARM: SAMSUNG: Add new PWM platform device
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-9-git-send-email-tomasz.figa@gmail.com>

This patch adds new samsung_device_pwm platform device that represents
the whole PWM/timer block and includes memory and IRQ resources.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/plat-samsung/devs.c                  | 17 +++++++++++++++++
 arch/arm/plat-samsung/include/plat/devs.h     |  1 +
 arch/arm/plat-samsung/include/plat/pwm-core.h | 24 ++++++++++++++++++++++++
 3 files changed, 42 insertions(+)
 create mode 100644 arch/arm/plat-samsung/include/plat/pwm-core.h

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 0f9c3f4..bba6d78 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -58,6 +58,7 @@
 #include <plat/keypad.h>
 #include <linux/platform_data/mmc-s3cmci.h>
 #include <linux/platform_data/mtd-nand-s3c2410.h>
+#include <plat/pwm-core.h>
 #include <plat/sdhci.h>
 #include <linux/platform_data/touchscreen-s3c2410.h>
 #include <linux/platform_data/usb-s3c2410_udc.h>
@@ -1127,6 +1128,22 @@ struct platform_device s3c_device_timer[] = {
 	[3] = { DEFINE_S3C_TIMER(3, IRQ_TIMER3) },
 	[4] = { DEFINE_S3C_TIMER(4, IRQ_TIMER4) },
 };
+
+static struct resource samsung_pwm_resource[] = {
+	DEFINE_RES_MEM(SAMSUNG_PA_TIMER, SZ_4K),
+};
+
+struct platform_device samsung_device_pwm = {
+	.name		= "samsung-pwm",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(samsung_pwm_resource),
+	.resource	= samsung_pwm_resource,
+};
+
+void __init samsung_pwm_set_platdata(struct samsung_pwm_variant *pd)
+{
+	samsung_device_pwm.dev.platform_data = pd;
+}
 #endif /* CONFIG_SAMSUNG_DEV_PWM */
 
 /* RTC */
diff --git a/arch/arm/plat-samsung/include/plat/devs.h b/arch/arm/plat-samsung/include/plat/devs.h
index 87d501f..0dc4ac4 100644
--- a/arch/arm/plat-samsung/include/plat/devs.h
+++ b/arch/arm/plat-samsung/include/plat/devs.h
@@ -134,6 +134,7 @@ extern struct platform_device exynos4_device_spdif;
 
 extern struct platform_device samsung_asoc_idma;
 extern struct platform_device samsung_device_keypad;
+extern struct platform_device samsung_device_pwm;
 
 /* s3c2440 specific devices */
 
diff --git a/arch/arm/plat-samsung/include/plat/pwm-core.h b/arch/arm/plat-samsung/include/plat/pwm-core.h
new file mode 100644
index 0000000..df50f5c
--- /dev/null
+++ b/arch/arm/plat-samsung/include/plat/pwm-core.h
@@ -0,0 +1,24 @@
+/*
+ * linux/arch/arm/plat-samsung/onenand-core.h
+ *
+ *  Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
+ *
+ * Samsung PWM Controller core functions
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#ifndef __ASM_ARCH_PWM_CORE_H
+#define __ASM_ARCH_PWM_CORE_H __FILE__
+
+#include <clocksource/samsung_pwm.h>
+
+#ifdef CONFIG_SAMSUNG_DEV_PWM
+extern void samsung_pwm_set_platdata(struct samsung_pwm_variant *pd);
+#else
+static inline void samsung_pwm_set_platdata(struct samsung_pwm_variant *pd) { }
+#endif
+
+#endif /* __ASM_ARCH_PWM_CORE_H */
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:22 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:22 +0200
Subject: [PATCH v4 09/20] ARM: SAMSUNG: Move all platforms to new clocksource
 driver
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-11-git-send-email-tomasz.figa@gmail.com>

This patch moves all Samsung platforms using PWM clocksource from legacy
samsung-time to new samsung-pwm-timer driver.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/Kconfig                | 10 +++++-----
 arch/arm/mach-s3c24xx/Kconfig   |  6 ------
 arch/arm/mach-s3c24xx/common.c  | 16 ++++++++++++++++
 arch/arm/mach-s3c64xx/Kconfig   |  2 --
 arch/arm/mach-s3c64xx/common.c  | 21 +++++++++++++++++----
 arch/arm/mach-s5p64x0/Kconfig   |  2 --
 arch/arm/mach-s5p64x0/common.c  | 17 +++++++++++++++++
 arch/arm/mach-s5pc100/Kconfig   |  1 -
 arch/arm/mach-s5pc100/common.c  | 17 +++++++++++++++++
 arch/arm/mach-s5pv210/Kconfig   |  1 -
 arch/arm/mach-s5pv210/common.c  | 17 +++++++++++++++++
 arch/arm/plat-samsung/s5p-irq.c |  3 ---
 12 files changed, 89 insertions(+), 24 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..486ab0a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -700,7 +700,7 @@ config ARCH_S3C24XX
 	select ARCH_HAS_CPUFREQ
 	select ARCH_REQUIRE_GPIOLIB
 	select CLKDEV_LOOKUP
-	select CLKSRC_MMIO
+	select CLKSRC_SAMSUNG_PWM
 	select GENERIC_CLOCKEVENTS
 	select GPIO_SAMSUNG
 	select HAVE_CLK
@@ -723,7 +723,7 @@ config ARCH_S3C64XX
 	select ARCH_REQUIRE_GPIOLIB
 	select ARM_VIC
 	select CLKDEV_LOOKUP
-	select CLKSRC_MMIO
+	select CLKSRC_SAMSUNG_PWM
 	select CPU_V6
 	select GENERIC_CLOCKEVENTS
 	select GPIO_SAMSUNG
@@ -748,7 +748,7 @@ config ARCH_S3C64XX
 config ARCH_S5P64X0
 	bool "Samsung S5P6440 S5P6450"
 	select CLKDEV_LOOKUP
-	select CLKSRC_MMIO
+	select CLKSRC_SAMSUNG_PWM
 	select CPU_V6
 	select GENERIC_CLOCKEVENTS
 	select GPIO_SAMSUNG
@@ -767,7 +767,7 @@ config ARCH_S5PC100
 	bool "Samsung S5PC100"
 	select ARCH_REQUIRE_GPIOLIB
 	select CLKDEV_LOOKUP
-	select CLKSRC_MMIO
+	select CLKSRC_SAMSUNG_PWM
 	select CPU_V7
 	select GENERIC_CLOCKEVENTS
 	select GPIO_SAMSUNG
@@ -787,7 +787,7 @@ config ARCH_S5PV210
 	select ARCH_HAS_HOLES_MEMORYMODEL
 	select ARCH_SPARSEMEM_ENABLE
 	select CLKDEV_LOOKUP
-	select CLKSRC_MMIO
+	select CLKSRC_SAMSUNG_PWM
 	select CPU_V7
 	select GENERIC_CLOCKEVENTS
 	select GPIO_SAMSUNG
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 6d9252e..b8ec0ec 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -30,7 +30,6 @@ config CPU_S3C2410
 	select S3C2410_CLOCK
 	select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ
 	select S3C2410_PM if PM
-	select SAMSUNG_HRT
 	select SAMSUNG_WDT_RESET
 	help
 	  Support for S3C2410 and S3C2410A family from the S3C24XX line
@@ -42,7 +41,6 @@ config CPU_S3C2412
 	select CPU_LLSERIAL_S3C2440
 	select S3C2412_DMA if S3C24XX_DMA
 	select S3C2412_PM if PM
-	select SAMSUNG_HRT
 	help
 	  Support for the S3C2412 and S3C2413 SoCs from the S3C24XX line
 
@@ -54,7 +52,6 @@ config CPU_S3C2416
 	select S3C2443_COMMON
 	select S3C2443_DMA if S3C24XX_DMA
 	select SAMSUNG_CLKSRC
-	select SAMSUNG_HRT
 	help
 	  Support for the S3C2416 SoC from the S3C24XX line
 
@@ -65,7 +62,6 @@ config CPU_S3C2440
 	select S3C2410_CLOCK
 	select S3C2410_PM if PM
 	select S3C2440_DMA if S3C24XX_DMA
-	select SAMSUNG_HRT
 	help
 	  Support for S3C2440 Samsung Mobile CPU based systems.
 
@@ -75,7 +71,6 @@ config CPU_S3C2442
 	select CPU_LLSERIAL_S3C2440
 	select S3C2410_CLOCK
 	select S3C2410_PM if PM
-	select SAMSUNG_HRT
 	help
 	  Support for S3C2442 Samsung Mobile CPU based systems.
 
@@ -91,7 +86,6 @@ config CPU_S3C2443
 	select S3C2443_COMMON
 	select S3C2443_DMA if S3C24XX_DMA
 	select SAMSUNG_CLKSRC
-	select SAMSUNG_HRT
 	help
 	  Support for the S3C2443 SoC from the S3C24XX line
 
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index e5e7d7d..457261c 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -245,6 +245,22 @@ void __init s3c24xx_init_io(struct map_desc *mach_desc, int size)
 	samsung_pwm_set_platdata(&s3c24xx_pwm_variant);
 }
 
+void __init samsung_set_timer_source(unsigned int event, unsigned int source)
+{
+	s3c24xx_pwm_variant.output_mask = BIT(SAMSUNG_PWM_NUM) - 1;
+	s3c24xx_pwm_variant.output_mask &= ~(BIT(event) | BIT(source));
+}
+
+void __init samsung_timer_init(void)
+{
+	unsigned int timer_irqs[SAMSUNG_PWM_NUM] = {
+		IRQ_TIMER0, IRQ_TIMER1, IRQ_TIMER2, IRQ_TIMER3, IRQ_TIMER4,
+	};
+
+	samsung_pwm_clocksource_init(S3C_VA_TIMER,
+					timer_irqs, &s3c24xx_pwm_variant);
+}
+
 /* Serial port registrations */
 
 #define S3C2410_PA_UART0      (S3C24XX_PA_UART)
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 2057853..041da51 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -17,13 +17,11 @@ config PLAT_S3C64XX
 # Configuration options for the S3C6410 CPU
 
 config CPU_S3C6400
-	select SAMSUNG_HRT
 	bool
 	help
 	  Enable S3C6400 CPU support
 
 config CPU_S3C6410
-	select SAMSUNG_HRT
 	bool
 	help
 	  Enable S3C6410 CPU support
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index ca05e61..73d79cf 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -43,7 +43,6 @@
 #include <plat/pm.h>
 #include <plat/gpio-cfg.h>
 #include <plat/irq-uart.h>
-#include <plat/irq-vic-timer.h>
 #include <plat/pwm-core.h>
 #include <plat/regs-irqtype.h>
 #include <plat/regs-serial.h>
@@ -158,6 +157,23 @@ static struct samsung_pwm_variant s3c64xx_pwm_variant = {
 	.tclk_mask	= (1 << 7) | (1 << 6) | (1 << 5),
 };
 
+void __init samsung_set_timer_source(unsigned int event, unsigned int source)
+{
+	s3c64xx_pwm_variant.output_mask = BIT(SAMSUNG_PWM_NUM) - 1;
+	s3c64xx_pwm_variant.output_mask &= ~(BIT(event) | BIT(source));
+}
+
+void __init samsung_timer_init(void)
+{
+	unsigned int timer_irqs[SAMSUNG_PWM_NUM] = {
+		IRQ_TIMER0_VIC, IRQ_TIMER1_VIC, IRQ_TIMER2_VIC,
+		IRQ_TIMER3_VIC, IRQ_TIMER4_VIC,
+	};
+
+	samsung_pwm_clocksource_init(S3C_VA_TIMER,
+					timer_irqs, &s3c64xx_pwm_variant);
+}
+
 /* read cpu identification code */
 
 void __init s3c64xx_init_io(struct map_desc *mach_desc, int size)
@@ -206,9 +222,6 @@ void __init s3c64xx_init_irq(u32 vic0_valid, u32 vic1_valid)
 	/* initialise the pair of VICs */
 	vic_init(VA_VIC0, IRQ_VIC0_BASE, vic0_valid, IRQ_VIC0_RESUME);
 	vic_init(VA_VIC1, IRQ_VIC1_BASE, vic1_valid, IRQ_VIC1_RESUME);
-
-	/* add the timer sub-irqs */
-	s3c_init_vic_timer_irq(5, IRQ_TIMER0);
 }
 
 #define eint_offset(irq)	((irq) - IRQ_EINT(0))
diff --git a/arch/arm/mach-s5p64x0/Kconfig b/arch/arm/mach-s5p64x0/Kconfig
index 5a707bd..bb2111b 100644
--- a/arch/arm/mach-s5p64x0/Kconfig
+++ b/arch/arm/mach-s5p64x0/Kconfig
@@ -11,14 +11,12 @@ config CPU_S5P6440
 	bool
 	select S5P_SLEEP if PM
 	select SAMSUNG_DMADEV
-	select SAMSUNG_HRT
 	select SAMSUNG_WAKEMASK if PM
 	help
 	  Enable S5P6440 CPU support
 
 config CPU_S5P6450
 	bool
-	select SAMSUNG_HRT
 	select S5P_SLEEP if PM
 	select SAMSUNG_DMADEV
 	select SAMSUNG_WAKEMASK if PM
diff --git a/arch/arm/mach-s5p64x0/common.c b/arch/arm/mach-s5p64x0/common.c
index 49687f2..42e14f2 100644
--- a/arch/arm/mach-s5p64x0/common.c
+++ b/arch/arm/mach-s5p64x0/common.c
@@ -166,6 +166,23 @@ static struct samsung_pwm_variant s5p64x0_pwm_variant = {
 	.tclk_mask	= 0,
 };
 
+void __init samsung_set_timer_source(unsigned int event, unsigned int source)
+{
+	s5p64x0_pwm_variant.output_mask = BIT(SAMSUNG_PWM_NUM) - 1;
+	s5p64x0_pwm_variant.output_mask &= ~(BIT(event) | BIT(source));
+}
+
+void __init samsung_timer_init(void)
+{
+	unsigned int timer_irqs[SAMSUNG_PWM_NUM] = {
+		IRQ_TIMER0_VIC, IRQ_TIMER1_VIC, IRQ_TIMER2_VIC,
+		IRQ_TIMER3_VIC, IRQ_TIMER4_VIC,
+	};
+
+	samsung_pwm_clocksource_init(S3C_VA_TIMER,
+					timer_irqs, &s5p64x0_pwm_variant);
+}
+
 /*
  * s5p64x0_map_io
  *
diff --git a/arch/arm/mach-s5pc100/Kconfig b/arch/arm/mach-s5pc100/Kconfig
index 2f456a4..15170be 100644
--- a/arch/arm/mach-s5pc100/Kconfig
+++ b/arch/arm/mach-s5pc100/Kconfig
@@ -11,7 +11,6 @@ config CPU_S5PC100
 	bool
 	select S5P_EXT_INT
 	select SAMSUNG_DMADEV
-	select SAMSUNG_HRT
 	help
 	  Enable S5PC100 CPU support
 
diff --git a/arch/arm/mach-s5pc100/common.c b/arch/arm/mach-s5pc100/common.c
index e0600af..c5a8eea 100644
--- a/arch/arm/mach-s5pc100/common.c
+++ b/arch/arm/mach-s5pc100/common.c
@@ -141,6 +141,23 @@ static struct samsung_pwm_variant s5pc100_pwm_variant = {
 	.tclk_mask	= (1 << 5),
 };
 
+void __init samsung_set_timer_source(unsigned int event, unsigned int source)
+{
+	s5pc100_pwm_variant.output_mask = BIT(SAMSUNG_PWM_NUM) - 1;
+	s5pc100_pwm_variant.output_mask &= ~(BIT(event) | BIT(source));
+}
+
+void __init samsung_timer_init(void)
+{
+	unsigned int timer_irqs[SAMSUNG_PWM_NUM] = {
+		IRQ_TIMER0_VIC, IRQ_TIMER1_VIC, IRQ_TIMER2_VIC,
+		IRQ_TIMER3_VIC, IRQ_TIMER4_VIC,
+	};
+
+	samsung_pwm_clocksource_init(S3C_VA_TIMER,
+					timer_irqs, &s5pc100_pwm_variant);
+}
+
 /*
  * s5pc100_map_io
  *
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 0963283..caaedaf 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -15,7 +15,6 @@ config CPU_S5PV210
 	select S5P_PM if PM
 	select S5P_SLEEP if PM
 	select SAMSUNG_DMADEV
-	select SAMSUNG_HRT
 	help
 	  Enable S5PV210 CPU support
 
diff --git a/arch/arm/mach-s5pv210/common.c b/arch/arm/mach-s5pv210/common.c
index 306b29a..26027a2 100644
--- a/arch/arm/mach-s5pv210/common.c
+++ b/arch/arm/mach-s5pv210/common.c
@@ -157,6 +157,23 @@ static struct samsung_pwm_variant s5pv210_pwm_variant = {
 	.tclk_mask	= (1 << 5),
 };
 
+void __init samsung_set_timer_source(unsigned int event, unsigned int source)
+{
+	s5pv210_pwm_variant.output_mask = BIT(SAMSUNG_PWM_NUM) - 1;
+	s5pv210_pwm_variant.output_mask &= ~(BIT(event) | BIT(source));
+}
+
+void __init samsung_timer_init(void)
+{
+	unsigned int timer_irqs[SAMSUNG_PWM_NUM] = {
+		IRQ_TIMER0_VIC, IRQ_TIMER1_VIC, IRQ_TIMER2_VIC,
+		IRQ_TIMER3_VIC, IRQ_TIMER4_VIC,
+	};
+
+	samsung_pwm_clocksource_init(S3C_VA_TIMER,
+					timer_irqs, &s5pv210_pwm_variant);
+}
+
 /*
  * s5pv210_map_io
  *
diff --git a/arch/arm/plat-samsung/s5p-irq.c b/arch/arm/plat-samsung/s5p-irq.c
index ff1a760..6729cb2 100644
--- a/arch/arm/plat-samsung/s5p-irq.c
+++ b/arch/arm/plat-samsung/s5p-irq.c
@@ -19,7 +19,6 @@
 #include <mach/map.h>
 #include <plat/regs-timer.h>
 #include <plat/cpu.h>
-#include <plat/irq-vic-timer.h>
 
 void __init s5p_init_irq(u32 *vic, u32 num_vic)
 {
@@ -30,6 +29,4 @@ void __init s5p_init_irq(u32 *vic, u32 num_vic)
 	for (irq = 0; irq < num_vic; irq++)
 		vic_init(VA_VIC(irq), VIC_BASE(irq), vic[irq], 0);
 #endif
-
-	s3c_init_vic_timer_irq(5, IRQ_TIMER0);
 }
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:23 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:23 +0200
Subject: [PATCH v4 10/20] ARM: SAMSUNG: Remove old samsung-time driver
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-12-git-send-email-tomasz.figa@gmail.com>

This patch removes the old samsung-time driver, since all its users have
been migrated to the new samsung_pwm_timer clocksource driver.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/plat-samsung/Kconfig                     |   8 -
 arch/arm/plat-samsung/Makefile                    |   1 -
 arch/arm/plat-samsung/include/plat/samsung-time.h |  23 --
 arch/arm/plat-samsung/samsung-time.c              | 394 ----------------------
 4 files changed, 426 deletions(-)
 delete mode 100644 arch/arm/plat-samsung/samsung-time.c

diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 3dc5cbe..3e880b7 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -72,14 +72,6 @@ config SAMSUNG_ATAGS
 
 if SAMSUNG_ATAGS
 
-# timer options
-
-config SAMSUNG_HRT
-	bool
-	select SAMSUNG_DEV_PWM
-	help
-	  Use the High Resolution timer support
-
 # clock options
 
 config SAMSUNG_CLOCK
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index 98d07d8..cf41bf9 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -12,7 +12,6 @@ obj-				:=
 # Objects we always build independent of SoC choice
 
 obj-y				+= init.o cpu.o
-obj-$(CONFIG_SAMSUNG_HRT) 	+= samsung-time.o
 
 obj-$(CONFIG_SAMSUNG_CLOCK)	+= clock.o
 obj-$(CONFIG_SAMSUNG_CLOCK)	+= pwm-clock.o
diff --git a/arch/arm/plat-samsung/include/plat/samsung-time.h b/arch/arm/plat-samsung/include/plat/samsung-time.h
index 4cc99bb..209464a 100644
--- a/arch/arm/plat-samsung/include/plat/samsung-time.h
+++ b/arch/arm/plat-samsung/include/plat/samsung-time.h
@@ -22,29 +22,6 @@ enum samsung_timer_mode {
 	SAMSUNG_PWM4,
 };
 
-struct samsung_timer_source {
-	unsigned int event_id;
-	unsigned int source_id;
-};
-
-/* Be able to sleep for atleast 4 seconds (usually more) */
-#define SAMSUNG_TIMER_MIN_RANGE	4
-
-#if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S5PC100)
-#define TCNT_MAX		0xffff
-#define TSCALER_DIV		25
-#define TDIV			50
-#define TSIZE			16
-#else
-#define TCNT_MAX		0xffffffff
-#define TSCALER_DIV		2
-#define TDIV			2
-#define TSIZE			32
-#endif
-
-#define NON_PERIODIC		0
-#define PERIODIC		1
-
 extern void __init samsung_set_timer_source(enum samsung_timer_mode event,
 					enum samsung_timer_mode source);
 
diff --git a/arch/arm/plat-samsung/samsung-time.c b/arch/arm/plat-samsung/samsung-time.c
deleted file mode 100644
index 2957075..0000000
--- a/arch/arm/plat-samsung/samsung-time.c
+++ /dev/null
@@ -1,394 +0,0 @@
-/*
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- *		http://www.samsung.com/
- *
- * samsung - Common hr-timer support (s3c and s5p)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include <linux/interrupt.h>
-#include <linux/irq.h>
-#include <linux/err.h>
-#include <linux/clk.h>
-#include <linux/clockchips.h>
-#include <linux/platform_device.h>
-#include <linux/sched_clock.h>
-
-#include <asm/smp_twd.h>
-#include <asm/mach/time.h>
-#include <asm/mach/arch.h>
-#include <asm/mach/map.h>
-
-#include <mach/map.h>
-#include <plat/devs.h>
-#include <plat/regs-timer.h>
-#include <plat/samsung-time.h>
-
-static struct clk *tin_event;
-static struct clk *tin_source;
-static struct clk *tdiv_event;
-static struct clk *tdiv_source;
-static struct clk *timerclk;
-static struct samsung_timer_source timer_source;
-static unsigned long clock_count_per_tick;
-static void samsung_timer_resume(void);
-
-static void samsung_time_stop(enum samsung_timer_mode mode)
-{
-	unsigned long tcon;
-
-	tcon = __raw_readl(S3C2410_TCON);
-
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon &= ~S3C2410_TCON_T0START;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon &= ~S3C2410_TCON_T1START;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon &= ~S3C2410_TCON_T2START;
-		break;
-
-	case SAMSUNG_PWM3:
-		tcon &= ~S3C2410_TCON_T3START;
-		break;
-
-	case SAMSUNG_PWM4:
-		tcon &= ~S3C2410_TCON_T4START;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-	__raw_writel(tcon, S3C2410_TCON);
-}
-
-static void samsung_time_setup(enum samsung_timer_mode mode, unsigned long tcnt)
-{
-	unsigned long tcon;
-
-	tcon = __raw_readl(S3C2410_TCON);
-
-	tcnt--;
-
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon &= ~(0x0f << 0);
-		tcon |= S3C2410_TCON_T0MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon &= ~(0x0f << 8);
-		tcon |= S3C2410_TCON_T1MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon &= ~(0x0f << 12);
-		tcon |= S3C2410_TCON_T2MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM3:
-		tcon &= ~(0x0f << 16);
-		tcon |= S3C2410_TCON_T3MANUALUPD;
-		break;
-
-	case SAMSUNG_PWM4:
-		tcon &= ~(0x07 << 20);
-		tcon |= S3C2410_TCON_T4MANUALUPD;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-
-	__raw_writel(tcnt, S3C2410_TCNTB(mode));
-	__raw_writel(tcnt, S3C2410_TCMPB(mode));
-	__raw_writel(tcon, S3C2410_TCON);
-}
-
-static void samsung_time_start(enum samsung_timer_mode mode, bool periodic)
-{
-	unsigned long tcon;
-
-	tcon  = __raw_readl(S3C2410_TCON);
-
-	switch (mode) {
-	case SAMSUNG_PWM0:
-		tcon |= S3C2410_TCON_T0START;
-		tcon &= ~S3C2410_TCON_T0MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T0RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T0RELOAD;
-		break;
-
-	case SAMSUNG_PWM1:
-		tcon |= S3C2410_TCON_T1START;
-		tcon &= ~S3C2410_TCON_T1MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T1RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T1RELOAD;
-		break;
-
-	case SAMSUNG_PWM2:
-		tcon |= S3C2410_TCON_T2START;
-		tcon &= ~S3C2410_TCON_T2MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T2RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T2RELOAD;
-		break;
-
-	case SAMSUNG_PWM3:
-		tcon |= S3C2410_TCON_T3START;
-		tcon &= ~S3C2410_TCON_T3MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T3RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T3RELOAD;
-		break;
-
-	case SAMSUNG_PWM4:
-		tcon |= S3C2410_TCON_T4START;
-		tcon &= ~S3C2410_TCON_T4MANUALUPD;
-
-		if (periodic)
-			tcon |= S3C2410_TCON_T4RELOAD;
-		else
-			tcon &= ~S3C2410_TCON_T4RELOAD;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", mode);
-		break;
-	}
-	__raw_writel(tcon, S3C2410_TCON);
-}
-
-static int samsung_set_next_event(unsigned long cycles,
-				struct clock_event_device *evt)
-{
-	samsung_time_setup(timer_source.event_id, cycles);
-	samsung_time_start(timer_source.event_id, NON_PERIODIC);
-
-	return 0;
-}
-
-static void samsung_set_mode(enum clock_event_mode mode,
-				struct clock_event_device *evt)
-{
-	samsung_time_stop(timer_source.event_id);
-
-	switch (mode) {
-	case CLOCK_EVT_MODE_PERIODIC:
-		samsung_time_setup(timer_source.event_id, clock_count_per_tick);
-		samsung_time_start(timer_source.event_id, PERIODIC);
-		break;
-
-	case CLOCK_EVT_MODE_ONESHOT:
-		break;
-
-	case CLOCK_EVT_MODE_UNUSED:
-	case CLOCK_EVT_MODE_SHUTDOWN:
-		break;
-
-	case CLOCK_EVT_MODE_RESUME:
-		samsung_timer_resume();
-		break;
-	}
-}
-
-static void samsung_timer_resume(void)
-{
-	/* event timer restart */
-	samsung_time_setup(timer_source.event_id, clock_count_per_tick);
-	samsung_time_start(timer_source.event_id, PERIODIC);
-
-	/* source timer restart */
-	samsung_time_setup(timer_source.source_id, TCNT_MAX);
-	samsung_time_start(timer_source.source_id, PERIODIC);
-}
-
-void __init samsung_set_timer_source(enum samsung_timer_mode event,
-				 enum samsung_timer_mode source)
-{
-	s3c_device_timer[event].dev.bus = &platform_bus_type;
-	s3c_device_timer[source].dev.bus = &platform_bus_type;
-
-	timer_source.event_id = event;
-	timer_source.source_id = source;
-}
-
-static struct clock_event_device time_event_device = {
-	.name		= "samsung_event_timer",
-	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
-	.rating		= 200,
-	.set_next_event	= samsung_set_next_event,
-	.set_mode	= samsung_set_mode,
-};
-
-static irqreturn_t samsung_clock_event_isr(int irq, void *dev_id)
-{
-	struct clock_event_device *evt = dev_id;
-
-	evt->event_handler(evt);
-
-	return IRQ_HANDLED;
-}
-
-static struct irqaction samsung_clock_event_irq = {
-	.name		= "samsung_time_irq",
-	.flags		= IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
-	.handler	= samsung_clock_event_isr,
-	.dev_id		= &time_event_device,
-};
-
-static void __init samsung_clockevent_init(void)
-{
-	unsigned long pclk;
-	unsigned long clock_rate;
-	unsigned int irq_number;
-	struct clk *tscaler;
-
-	pclk = clk_get_rate(timerclk);
-
-	tscaler = clk_get_parent(tdiv_event);
-
-	clk_set_rate(tscaler, pclk / TSCALER_DIV);
-	clk_set_rate(tdiv_event, pclk / TDIV);
-	clk_set_parent(tin_event, tdiv_event);
-
-	clock_rate = clk_get_rate(tin_event);
-	clock_count_per_tick = clock_rate / HZ;
-
-	time_event_device.cpumask = cpumask_of(0);
-	clockevents_config_and_register(&time_event_device, clock_rate, 1, -1);
-
-	irq_number = timer_source.event_id + IRQ_TIMER0;
-	setup_irq(irq_number, &samsung_clock_event_irq);
-}
-
-static void __iomem *samsung_timer_reg(void)
-{
-	unsigned long offset = 0;
-
-	switch (timer_source.source_id) {
-	case SAMSUNG_PWM0:
-	case SAMSUNG_PWM1:
-	case SAMSUNG_PWM2:
-	case SAMSUNG_PWM3:
-		offset = (timer_source.source_id * 0x0c) + 0x14;
-		break;
-
-	case SAMSUNG_PWM4:
-		offset = 0x40;
-		break;
-
-	default:
-		printk(KERN_ERR "Invalid Timer %d\n", timer_source.source_id);
-		return NULL;
-	}
-
-	return S3C_TIMERREG(offset);
-}
-
-/*
- * Override the global weak sched_clock symbol with this
- * local implementation which uses the clocksource to get some
- * better resolution when scheduling the kernel. We accept that
- * this wraps around for now, since it is just a relative time
- * stamp. (Inspired by U300 implementation.)
- */
-static u32 notrace samsung_read_sched_clock(void)
-{
-	void __iomem *reg = samsung_timer_reg();
-
-	if (!reg)
-		return 0;
-
-	return ~__raw_readl(reg);
-}
-
-static void __init samsung_clocksource_init(void)
-{
-	unsigned long pclk;
-	unsigned long clock_rate;
-
-	pclk = clk_get_rate(timerclk);
-
-	clk_set_rate(tdiv_source, pclk / TDIV);
-	clk_set_parent(tin_source, tdiv_source);
-
-	clock_rate = clk_get_rate(tin_source);
-
-	samsung_time_setup(timer_source.source_id, TCNT_MAX);
-	samsung_time_start(timer_source.source_id, PERIODIC);
-
-	setup_sched_clock(samsung_read_sched_clock, TSIZE, clock_rate);
-
-	if (clocksource_mmio_init(samsung_timer_reg(), "samsung_clocksource_timer",
-			clock_rate, 250, TSIZE, clocksource_mmio_readl_down))
-		panic("samsung_clocksource_timer: can't register clocksource\n");
-}
-
-static void __init samsung_timer_resources(void)
-{
-
-	unsigned long event_id = timer_source.event_id;
-	unsigned long source_id = timer_source.source_id;
-	char devname[15];
-
-	timerclk = clk_get(NULL, "timers");
-	if (IS_ERR(timerclk))
-		panic("failed to get timers clock for timer");
-
-	clk_enable(timerclk);
-
-	sprintf(devname, "s3c24xx-pwm.%lu", event_id);
-	s3c_device_timer[event_id].id = event_id;
-	s3c_device_timer[event_id].dev.init_name = devname;
-
-	tin_event = clk_get(&s3c_device_timer[event_id].dev, "pwm-tin");
-	if (IS_ERR(tin_event))
-		panic("failed to get pwm-tin clock for event timer");
-
-	tdiv_event = clk_get(&s3c_device_timer[event_id].dev, "pwm-tdiv");
-	if (IS_ERR(tdiv_event))
-		panic("failed to get pwm-tdiv clock for event timer");
-
-	clk_enable(tin_event);
-
-	sprintf(devname, "s3c24xx-pwm.%lu", source_id);
-	s3c_device_timer[source_id].id = source_id;
-	s3c_device_timer[source_id].dev.init_name = devname;
-
-	tin_source = clk_get(&s3c_device_timer[source_id].dev, "pwm-tin");
-	if (IS_ERR(tin_source))
-		panic("failed to get pwm-tin clock for source timer");
-
-	tdiv_source = clk_get(&s3c_device_timer[source_id].dev, "pwm-tdiv");
-	if (IS_ERR(tdiv_source))
-		panic("failed to get pwm-tdiv clock for source timer");
-
-	clk_enable(tin_source);
-}
-
-void __init samsung_timer_init(void)
-{
-	samsung_timer_resources();
-	samsung_clockevent_init();
-	samsung_clocksource_init();
-}
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:27 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:27 +0200
Subject: [PATCH v4 14/20] ARM: SAMSUNG: Rework private data handling in
 dev-backlight
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-16-git-send-email-tomasz.figa@gmail.com>

This patch modifies dev-backlight helpers to get private data using
container_of instead of abusing platform_data field of PWM device.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/plat-samsung/dev-backlight.c | 51 ++++++++++++++++++++---------------
 1 file changed, 29 insertions(+), 22 deletions(-)

diff --git a/arch/arm/plat-samsung/dev-backlight.c b/arch/arm/plat-samsung/dev-backlight.c
index 5f197dc..e467a01 100644
--- a/arch/arm/plat-samsung/dev-backlight.c
+++ b/arch/arm/plat-samsung/dev-backlight.c
@@ -20,13 +20,18 @@
 #include <plat/gpio-cfg.h>
 #include <plat/backlight.h>
 
+struct samsung_bl_drvdata {
+	struct platform_pwm_backlight_data plat_data;
+	struct samsung_bl_gpio_info *gpio_info;
+};
+
 static int samsung_bl_init(struct device *dev)
 {
 	int ret = 0;
-	struct platform_device *timer_dev =
-			container_of(dev->parent, struct platform_device, dev);
-	struct samsung_bl_gpio_info *bl_gpio_info =
-			timer_dev->dev.platform_data;
+	struct platform_pwm_backlight_data *pdata = dev->platform_data;
+	struct samsung_bl_drvdata *drvdata = container_of(pdata,
+					struct samsung_bl_drvdata, plat_data);
+	struct samsung_bl_gpio_info *bl_gpio_info = drvdata->gpio_info;
 
 	ret = gpio_request(bl_gpio_info->no, "Backlight");
 	if (ret) {
@@ -42,10 +47,10 @@ static int samsung_bl_init(struct device *dev)
 
 static void samsung_bl_exit(struct device *dev)
 {
-	struct platform_device *timer_dev =
-			container_of(dev->parent, struct platform_device, dev);
-	struct samsung_bl_gpio_info *bl_gpio_info =
-			timer_dev->dev.platform_data;
+	struct platform_pwm_backlight_data *pdata = dev->platform_data;
+	struct samsung_bl_drvdata *drvdata = container_of(pdata,
+					struct samsung_bl_drvdata, plat_data);
+	struct samsung_bl_gpio_info *bl_gpio_info = drvdata->gpio_info;
 
 	s3c_gpio_cfgpin(bl_gpio_info->no, S3C_GPIO_OUTPUT);
 	gpio_free(bl_gpio_info->no);
@@ -60,12 +65,14 @@ static void samsung_bl_exit(struct device *dev)
  * for their specific boards
  */
 
-static struct platform_pwm_backlight_data samsung_dfl_bl_data __initdata = {
-	.max_brightness = 255,
-	.dft_brightness = 255,
-	.pwm_period_ns  = 78770,
-	.init           = samsung_bl_init,
-	.exit           = samsung_bl_exit,
+static struct samsung_bl_drvdata samsung_dfl_bl_data __initdata = {
+	.plat_data = {
+		.max_brightness = 255,
+		.dft_brightness = 255,
+		.pwm_period_ns  = 78770,
+		.init           = samsung_bl_init,
+		.exit           = samsung_bl_exit,
+	},
 };
 
 static struct platform_device samsung_dfl_bl_device __initdata = {
@@ -82,6 +89,7 @@ void __init samsung_bl_set(struct samsung_bl_gpio_info *gpio_info,
 {
 	int ret = 0;
 	struct platform_device *samsung_bl_device;
+	struct samsung_bl_drvdata *samsung_bl_drvdata;
 	struct platform_pwm_backlight_data *samsung_bl_data;
 
 	samsung_bl_device = kmemdup(&samsung_dfl_bl_device,
@@ -91,17 +99,19 @@ void __init samsung_bl_set(struct samsung_bl_gpio_info *gpio_info,
 		return;
 	}
 
-	samsung_bl_data = s3c_set_platdata(&samsung_dfl_bl_data,
-		sizeof(struct platform_pwm_backlight_data), samsung_bl_device);
-	if (!samsung_bl_data) {
+	samsung_bl_drvdata = kmemdup(&samsung_dfl_bl_data,
+				sizeof(samsung_dfl_bl_data), GFP_KERNEL);
+	if (!samsung_bl_drvdata) {
 		printk(KERN_ERR "%s: no memory for platform dev\n", __func__);
 		goto err_data;
 	}
+	samsung_bl_device->dev.platform_data = &samsung_bl_drvdata->plat_data;
+	samsung_bl_drvdata->gpio_info = gpio_info;
+	samsung_bl_data = &samsung_bl_drvdata->plat_data;
 
 	/* Copy board specific data provided by user */
 	samsung_bl_data->pwm_id = bl_data->pwm_id;
-	samsung_bl_device->dev.parent =
-			&s3c_device_timer[samsung_bl_data->pwm_id].dev;
+	samsung_bl_device->dev.parent = &samsung_device_pwm.dev;
 
 	if (bl_data->max_brightness)
 		samsung_bl_data->max_brightness = bl_data->max_brightness;
@@ -122,9 +132,6 @@ void __init samsung_bl_set(struct samsung_bl_gpio_info *gpio_info,
 	if (bl_data->check_fb)
 		samsung_bl_data->check_fb = bl_data->check_fb;
 
-	/* Keep the GPIO info for future use */
-	s3c_device_timer[samsung_bl_data->pwm_id].dev.platform_data = gpio_info;
-
 	/* Register the specific PWM timer dev for Backlight control */
 	ret = platform_device_register(
 			&s3c_device_timer[samsung_bl_data->pwm_id]);
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:28 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:28 +0200
Subject: [PATCH v4 15/20] ARM: SAMSUNG: Modify board files to use new PWM
 platform device
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-17-git-send-email-tomasz.figa@gmail.com>

This patch modifies any board files using the legacy PWM device to use
the new device instead.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/mach-s3c24xx/mach-h1940.c    |  4 ++--
 arch/arm/mach-s3c24xx/mach-rx1950.c   |  5 ++---
 arch/arm/mach-s3c64xx/mach-crag6410.c |  4 ++--
 arch/arm/mach-s3c64xx/mach-hmt.c      |  4 ++--
 arch/arm/mach-s3c64xx/mach-smartq.c   |  4 ++--
 arch/arm/mach-s3c64xx/mach-smdk6410.c |  5 +++--
 arch/arm/mach-s5p64x0/mach-smdk6440.c |  5 +++--
 arch/arm/mach-s5p64x0/mach-smdk6450.c |  5 +++--
 arch/arm/mach-s5pc100/mach-smdkc100.c |  5 +++--
 arch/arm/mach-s5pv210/mach-smdkv210.c |  5 +++--
 arch/arm/plat-samsung/dev-backlight.c | 10 ----------
 11 files changed, 25 insertions(+), 31 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/mach-h1940.c b/arch/arm/mach-s3c24xx/mach-h1940.c
index af4334d..74dd479 100644
--- a/arch/arm/mach-s3c24xx/mach-h1940.c
+++ b/arch/arm/mach-s3c24xx/mach-h1940.c
@@ -512,7 +512,7 @@ static struct platform_pwm_backlight_data backlight_data = {
 static struct platform_device h1940_backlight = {
 	.name = "pwm-backlight",
 	.dev  = {
-		.parent = &s3c_device_timer[0].dev,
+		.parent = &samsung_device_pwm.dev,
 		.platform_data = &backlight_data,
 	},
 	.id   = -1,
@@ -632,7 +632,7 @@ static struct platform_device *h1940_devices[] __initdata = {
 	&h1940_device_bluetooth,
 	&s3c_device_sdi,
 	&s3c_device_rtc,
-	&s3c_device_timer[0],
+	&samsung_device_pwm,
 	&h1940_backlight,
 	&h1940_lcd_powerdev,
 	&s3c_device_adc,
diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c b/arch/arm/mach-s3c24xx/mach-rx1950.c
index 44ca018..206b1f7 100644
--- a/arch/arm/mach-s3c24xx/mach-rx1950.c
+++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
@@ -530,7 +530,7 @@ static struct platform_pwm_backlight_data rx1950_backlight_data = {
 static struct platform_device rx1950_backlight = {
 	.name = "pwm-backlight",
 	.dev = {
-		.parent = &s3c_device_timer[0].dev,
+		.parent = &samsung_device_pwm.dev,
 		.platform_data = &rx1950_backlight_data,
 	},
 };
@@ -717,8 +717,7 @@ static struct platform_device *rx1950_devices[] __initdata = {
 	&s3c_device_sdi,
 	&s3c_device_adc,
 	&s3c_device_ts,
-	&s3c_device_timer[0],
-	&s3c_device_timer[1],
+	&samsung_device_pwm,
 	&rx1950_backlight,
 	&rx1950_device_gpiokeys,
 	&power_supply,
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 8ad88ac..28889cc 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -120,7 +120,7 @@ static struct platform_device crag6410_backlight_device = {
 	.name		= "pwm-backlight",
 	.id		= -1,
 	.dev		= {
-		.parent	= &s3c_device_timer[0].dev,
+		.parent	= &samsung_device_pwm.dev,
 		.platform_data = &crag6410_backlight_data,
 	},
 };
@@ -375,7 +375,7 @@ static struct platform_device *crag6410_devices[] __initdata = {
 	&s3c_device_fb,
 	&s3c_device_ohci,
 	&s3c_device_usb_hsotg,
-	&s3c_device_timer[0],
+	&samsung_device_pwm,
 	&s3c64xx_device_iis0,
 	&s3c64xx_device_iis1,
 	&samsung_device_keypad,
diff --git a/arch/arm/mach-s3c64xx/mach-hmt.c b/arch/arm/mach-s3c64xx/mach-hmt.c
index 5b7f357..f39569e 100644
--- a/arch/arm/mach-s3c64xx/mach-hmt.c
+++ b/arch/arm/mach-s3c64xx/mach-hmt.c
@@ -123,7 +123,7 @@ static struct platform_pwm_backlight_data hmt_backlight_data = {
 static struct platform_device hmt_backlight_device = {
 	.name		= "pwm-backlight",
 	.dev		= {
-		.parent	= &s3c_device_timer[1].dev,
+		.parent	= &samsung_device_pwm.dev,
 		.platform_data = &hmt_backlight_data,
 	},
 };
@@ -239,7 +239,7 @@ static struct platform_device *hmt_devices[] __initdata = {
 	&s3c_device_nand,
 	&s3c_device_fb,
 	&s3c_device_ohci,
-	&s3c_device_timer[1],
+	&samsung_device_pwm,
 	&hmt_backlight_device,
 	&hmt_leds_device,
 };
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c b/arch/arm/mach-s3c64xx/mach-smartq.c
index 58ac990..86d980b 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -157,7 +157,7 @@ static struct platform_pwm_backlight_data smartq_backlight_data = {
 static struct platform_device smartq_backlight_device = {
 	.name		= "pwm-backlight",
 	.dev		= {
-		.parent	= &s3c_device_timer[1].dev,
+		.parent	= &samsung_device_pwm.dev,
 		.platform_data = &smartq_backlight_data,
 	},
 };
@@ -246,7 +246,7 @@ static struct platform_device *smartq_devices[] __initdata = {
 	&s3c_device_i2c0,
 	&s3c_device_ohci,
 	&s3c_device_rtc,
-	&s3c_device_timer[1],
+	&samsung_device_pwm,
 	&s3c_device_ts,
 	&s3c_device_usb_hsotg,
 	&s3c64xx_device_iis0,
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index bd3295a..d90b450 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -274,6 +274,7 @@ static struct platform_device *smdk6410_devices[] __initdata = {
 	&s3c_device_i2c1,
 	&s3c_device_fb,
 	&s3c_device_ohci,
+	&samsung_device_pwm,
 	&s3c_device_usb_hsotg,
 	&s3c64xx_device_iisv4,
 	&samsung_device_keypad,
@@ -691,9 +692,9 @@ static void __init smdk6410_machine_init(void)
 
 	s3c_ide_set_platdata(&smdk6410_ide_pdata);
 
-	samsung_bl_set(&smdk6410_bl_gpio_info, &smdk6410_bl_data);
-
 	platform_add_devices(smdk6410_devices, ARRAY_SIZE(smdk6410_devices));
+
+	samsung_bl_set(&smdk6410_bl_gpio_info, &smdk6410_bl_data);
 }
 
 MACHINE_START(SMDK6410, "SMDK6410")
diff --git a/arch/arm/mach-s5p64x0/mach-smdk6440.c b/arch/arm/mach-s5p64x0/mach-smdk6440.c
index 73f71a6..0b00304 100644
--- a/arch/arm/mach-s5p64x0/mach-smdk6440.c
+++ b/arch/arm/mach-s5p64x0/mach-smdk6440.c
@@ -162,6 +162,7 @@ static struct platform_device *smdk6440_devices[] __initdata = {
 	&s3c_device_rtc,
 	&s3c_device_i2c0,
 	&s3c_device_i2c1,
+	&samsung_device_pwm,
 	&s3c_device_ts,
 	&s3c_device_wdt,
 	&s5p6440_device_iis,
@@ -254,8 +255,6 @@ static void __init smdk6440_machine_init(void)
 	i2c_register_board_info(1, smdk6440_i2c_devs1,
 			ARRAY_SIZE(smdk6440_i2c_devs1));
 
-	samsung_bl_set(&smdk6440_bl_gpio_info, &smdk6440_bl_data);
-
 	s5p6440_set_lcd_interface();
 	s3c_fb_set_platdata(&smdk6440_lcd_pdata);
 
@@ -264,6 +263,8 @@ static void __init smdk6440_machine_init(void)
 	s3c_sdhci2_set_platdata(&smdk6440_hsmmc2_pdata);
 
 	platform_add_devices(smdk6440_devices, ARRAY_SIZE(smdk6440_devices));
+
+	samsung_bl_set(&smdk6440_bl_gpio_info, &smdk6440_bl_data);
 }
 
 MACHINE_START(SMDK6440, "SMDK6440")
diff --git a/arch/arm/mach-s5p64x0/mach-smdk6450.c b/arch/arm/mach-s5p64x0/mach-smdk6450.c
index 18303e1..5949296 100644
--- a/arch/arm/mach-s5p64x0/mach-smdk6450.c
+++ b/arch/arm/mach-s5p64x0/mach-smdk6450.c
@@ -180,6 +180,7 @@ static struct platform_device *smdk6450_devices[] __initdata = {
 	&s3c_device_rtc,
 	&s3c_device_i2c0,
 	&s3c_device_i2c1,
+	&samsung_device_pwm,
 	&s3c_device_ts,
 	&s3c_device_wdt,
 	&s5p6450_device_iis0,
@@ -273,8 +274,6 @@ static void __init smdk6450_machine_init(void)
 	i2c_register_board_info(1, smdk6450_i2c_devs1,
 			ARRAY_SIZE(smdk6450_i2c_devs1));
 
-	samsung_bl_set(&smdk6450_bl_gpio_info, &smdk6450_bl_data);
-
 	s5p6450_set_lcd_interface();
 	s3c_fb_set_platdata(&smdk6450_lcd_pdata);
 
@@ -283,6 +282,8 @@ static void __init smdk6450_machine_init(void)
 	s3c_sdhci2_set_platdata(&smdk6450_hsmmc2_pdata);
 
 	platform_add_devices(smdk6450_devices, ARRAY_SIZE(smdk6450_devices));
+
+	samsung_bl_set(&smdk6450_bl_gpio_info, &smdk6450_bl_data);
 }
 
 MACHINE_START(SMDK6450, "SMDK6450")
diff --git a/arch/arm/mach-s5pc100/mach-smdkc100.c b/arch/arm/mach-s5pc100/mach-smdkc100.c
index 8c880f7..7c57a22 100644
--- a/arch/arm/mach-s5pc100/mach-smdkc100.c
+++ b/arch/arm/mach-s5pc100/mach-smdkc100.c
@@ -194,6 +194,7 @@ static struct platform_device *smdkc100_devices[] __initdata = {
 	&s3c_device_hsmmc0,
 	&s3c_device_hsmmc1,
 	&s3c_device_hsmmc2,
+	&samsung_device_pwm,
 	&s3c_device_ts,
 	&s3c_device_wdt,
 	&smdkc100_lcd_powerdev,
@@ -246,9 +247,9 @@ static void __init smdkc100_machine_init(void)
 	gpio_request(S5PC100_GPH0(6), "GPH0");
 	smdkc100_lcd_power_set(&smdkc100_lcd_power_data, 0);
 
-	samsung_bl_set(&smdkc100_bl_gpio_info, &smdkc100_bl_data);
-
 	platform_add_devices(smdkc100_devices, ARRAY_SIZE(smdkc100_devices));
+
+	samsung_bl_set(&smdkc100_bl_gpio_info, &smdkc100_bl_data);
 }
 
 MACHINE_START(SMDKC100, "SMDKC100")
diff --git a/arch/arm/mach-s5pv210/mach-smdkv210.c b/arch/arm/mach-s5pv210/mach-smdkv210.c
index d50b6f1..6d72bb99 100644
--- a/arch/arm/mach-s5pv210/mach-smdkv210.c
+++ b/arch/arm/mach-s5pv210/mach-smdkv210.c
@@ -218,6 +218,7 @@ static struct platform_device *smdkv210_devices[] __initdata = {
 	&s3c_device_i2c0,
 	&s3c_device_i2c1,
 	&s3c_device_i2c2,
+	&samsung_device_pwm,
 	&s3c_device_rtc,
 	&s3c_device_ts,
 	&s3c_device_usb_hsotg,
@@ -316,11 +317,11 @@ static void __init smdkv210_machine_init(void)
 
 	s3c_fb_set_platdata(&smdkv210_lcd0_pdata);
 
-	samsung_bl_set(&smdkv210_bl_gpio_info, &smdkv210_bl_data);
-
 	s3c_hsotg_set_platdata(&smdkv210_hsotg_pdata);
 
 	platform_add_devices(smdkv210_devices, ARRAY_SIZE(smdkv210_devices));
+
+	samsung_bl_set(&smdkv210_bl_gpio_info, &smdkv210_bl_data);
 }
 
 MACHINE_START(SMDKV210, "SMDKV210")
diff --git a/arch/arm/plat-samsung/dev-backlight.c b/arch/arm/plat-samsung/dev-backlight.c
index e467a01..d51f956 100644
--- a/arch/arm/plat-samsung/dev-backlight.c
+++ b/arch/arm/plat-samsung/dev-backlight.c
@@ -132,14 +132,6 @@ void __init samsung_bl_set(struct samsung_bl_gpio_info *gpio_info,
 	if (bl_data->check_fb)
 		samsung_bl_data->check_fb = bl_data->check_fb;
 
-	/* Register the specific PWM timer dev for Backlight control */
-	ret = platform_device_register(
-			&s3c_device_timer[samsung_bl_data->pwm_id]);
-	if (ret) {
-		printk(KERN_ERR "failed to register pwm timer for backlight: %d\n", ret);
-		goto err_plat_reg1;
-	}
-
 	/* Register the Backlight dev */
 	ret = platform_device_register(samsung_bl_device);
 	if (ret) {
@@ -150,8 +142,6 @@ void __init samsung_bl_set(struct samsung_bl_gpio_info *gpio_info,
 	return;
 
 err_plat_reg2:
-	platform_device_unregister(&s3c_device_timer[samsung_bl_data->pwm_id]);
-err_plat_reg1:
 	kfree(samsung_bl_data);
 err_data:
 	kfree(samsung_bl_device);
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:30 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:30 +0200
Subject: [PATCH v4 17/20] ARM: SAMSUNG: Remove old PWM timer platform devices
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-19-git-send-email-tomasz.figa@gmail.com>

This patch removes old Samsung PWM timer platform devices that are not
used any more.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/plat-samsung/devs.c | 18 ------------------
 1 file changed, 18 deletions(-)

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 290f63a..8ce0ac0 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -1098,24 +1098,6 @@ arch_initcall(s5p_pmu_init);
 /* PWM Timer */
 
 #ifdef CONFIG_SAMSUNG_DEV_PWM
-
-#define DEFINE_S3C_TIMER(_tmr_no)			\
-	.name		= "s3c24xx-pwm",		\
-	.id		= _tmr_no,			\
-
-/*
- * since we already have an static mapping for the timer,
- * we do not bother setting any IO resource for the base.
- */
-
-struct platform_device s3c_device_timer[] = {
-	[0] = { DEFINE_S3C_TIMER(0) },
-	[1] = { DEFINE_S3C_TIMER(1) },
-	[2] = { DEFINE_S3C_TIMER(2) },
-	[3] = { DEFINE_S3C_TIMER(3) },
-	[4] = { DEFINE_S3C_TIMER(4) },
-};
-
 static struct resource samsung_pwm_resource[] = {
 	DEFINE_RES_MEM(SAMSUNG_PA_TIMER, SZ_4K),
 };
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:26 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:26 +0200
Subject: [PATCH v4 13/20] pwm: Add new pwm-samsung driver
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-15-git-send-email-tomasz.figa@gmail.com>

This patch introduces new Samsung PWM driver, which uses Samsung
PWM/timer master driver to control shared parts of the hardware.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/pwm/Makefile      |   1 +
 drivers/pwm/pwm-samsung.c | 606 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 607 insertions(+)
 create mode 100644 drivers/pwm/pwm-samsung.c

diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index aa94807..86a5771 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_PWM_PUV3)		+= pwm-puv3.o
 obj-$(CONFIG_PWM_PXA)		+= pwm-pxa.o
 obj-$(CONFIG_PWM_RENESAS_TPU)	+= pwm-renesas-tpu.o
 obj-$(CONFIG_PWM_SAMSUNG)	+= pwm-samsung-legacy.o
+obj-$(CONFIG_PWM_SAMSUNG)	+= pwm-samsung.o
 obj-$(CONFIG_PWM_SPEAR)		+= pwm-spear.o
 obj-$(CONFIG_PWM_TEGRA)		+= pwm-tegra.o
 obj-$(CONFIG_PWM_TIECAP)	+= pwm-tiecap.o
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
new file mode 100644
index 0000000..b9e5240
--- /dev/null
+++ b/drivers/pwm/pwm-samsung.c
@@ -0,0 +1,606 @@
+/*
+ * Copyright (c) 2007 Ben Dooks
+ * Copyright (c) 2008 Simtec Electronics
+ *     Ben Dooks <ben at simtec.co.uk>, <ben-linux at fluff.org>
+ * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
+ *
+ * PWM driver for Samsung SoCs
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/export.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/time.h>
+
+/* For struct samsung_timer_variant and samsung_pwm_lock. */
+#include <clocksource/samsung_pwm.h>
+
+#define REG_TCFG0			0x00
+#define REG_TCFG1			0x04
+#define REG_TCON			0x08
+
+#define REG_TCNTB(tmr)			(0x0c + ((tmr) * 0xc))
+#define REG_TCMPB(tmr)			(0x10 + ((tmr) * 0xc))
+
+#define TCFG0_PRESCALER_MASK		0xff
+#define TCFG0_PRESCALER1_SHIFT		8
+
+#define TCFG1_MUX_MASK			0xf
+#define TCFG1_SHIFT(x)			((x) * 4)
+
+#define TCON_START(chan)		(1 << (4 * (chan) + 0))
+#define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
+#define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
+#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) \
+						+ (((chan) < 5) ? 3 : 2)))
+
+/**
+ * struct samsung_pwm_channel - private data of PWM channel
+ * @period_ns:	current period in nanoseconds programmed to the hardware
+ * @duty_ns:	current duty time in nanoseconds programmed to the hardware
+ * @tin_ns:	time of one timer tick in nanoseconds with current timer rate
+ */
+struct samsung_pwm_channel {
+	u32 period_ns;
+	u32 duty_ns;
+	u32 tin_ns;
+};
+
+/**
+ * struct samsung_pwm_chip - private data of PWM chip
+ * @chip:		generic PWM chip
+ * @variant:		local copy of hardware variant data
+ * @inverter_mask:	inverter status for all channels - one bit per channel
+ * @base:		base address of mapped PWM registers
+ * @base_clk:		base clock used to drive the timers
+ * @tclk0:		external clock 0 (can be ERR_PTR if not present)
+ * @tclk1:		external clock 1 (can be ERR_PTR if not present)
+ */
+struct samsung_pwm_chip {
+	struct pwm_chip chip;
+	struct samsung_pwm_variant variant;
+	u8 inverter_mask;
+
+	void __iomem *base;
+	struct clk *base_clk;
+	struct clk *tclk0;
+	struct clk *tclk1;
+};
+
+#ifndef CONFIG_CLKSRC_SAMSUNG_PWM
+/*
+ * PWM block is shared between pwm-samsung and samsung_pwm_timer drivers
+ * and some registers need access synchronization. If both drivers are
+ * compiled in, the spinlock is defined in the clocksource driver,
+ * otherwise following definition is used.
+ *
+ * Currently we do not need any more complex synchronization method
+ * because all the supported SoCs contain only one instance of the PWM
+ * IP. Should this change, both drivers will need to be modified to
+ * properly synchronize accesses to particular instances.
+ */
+static DEFINE_SPINLOCK(samsung_pwm_lock);
+#endif
+
+static inline
+struct samsung_pwm_chip *to_samsung_pwm_chip(struct pwm_chip *chip)
+{
+	return container_of(chip, struct samsung_pwm_chip, chip);
+}
+
+static inline unsigned int to_tcon_channel(unsigned int channel)
+{
+	/* TCON register has a gap of 4 bits (1 channel) */
+	return (channel == 0) ? 0 : (channel + 1);
+}
+
+static void pwm_samsung_set_divisor(struct samsung_pwm_chip *pwm,
+				    unsigned int channel, u8 divisor)
+{
+	u8 shift = TCFG1_SHIFT(channel);
+	unsigned long flags;
+	u32 reg;
+	u8 bits;
+
+	bits = (fls(divisor) - 1) - pwm->variant.div_base;
+
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
+
+	reg = readl(pwm->base + REG_TCFG1);
+	reg &= ~(TCFG1_MUX_MASK << shift);
+	reg |= bits << shift;
+	writel(reg, pwm->base + REG_TCFG1);
+
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
+}
+
+static int pwm_samsung_is_tdiv(struct samsung_pwm_chip *chip, unsigned int chan)
+{
+	struct samsung_pwm_variant *variant = &chip->variant;
+	u32 reg;
+
+	reg = readl(chip->base + REG_TCFG1);
+	reg >>= TCFG1_SHIFT(chan);
+	reg &= TCFG1_MUX_MASK;
+
+	return (BIT(reg) & variant->tclk_mask) == 0;
+}
+
+static unsigned long pwm_samsung_get_tin_rate(struct samsung_pwm_chip *chip,
+					      unsigned int chan)
+{
+	unsigned long rate;
+	u32 reg;
+
+	rate = clk_get_rate(chip->base_clk);
+
+	reg = readl(chip->base + REG_TCFG0);
+	if (chan >= 2)
+		reg >>= TCFG0_PRESCALER1_SHIFT;
+	reg &= TCFG0_PRESCALER_MASK;
+
+	return rate / (reg + 1);
+}
+
+static unsigned long pwm_samsung_calc_tin(struct samsung_pwm_chip *chip,
+					  unsigned int chan, unsigned long freq)
+{
+	struct samsung_pwm_variant *variant = &chip->variant;
+	unsigned long rate;
+	struct clk *clk;
+	u8 div;
+
+	if (!pwm_samsung_is_tdiv(chip, chan)) {
+		clk = (chan < 2) ? chip->tclk0 : chip->tclk1;
+		if (!IS_ERR(clk)) {
+			rate = clk_get_rate(clk);
+			if (rate)
+				return rate;
+		}
+
+		dev_warn(chip->chip.dev,
+			"tclk of PWM %d is inoperational, using tdiv\n", chan);
+	}
+
+	rate = pwm_samsung_get_tin_rate(chip, chan);
+	dev_dbg(chip->chip.dev, "tin parent at %lu\n", rate);
+
+	/*
+	 * Compare minimum PWM frequency that can be achieved with possible
+	 * divider settings and choose the lowest divisor that can generate
+	 * frequencies lower than requested.
+	 */
+	for (div = variant->div_base; div < 4; ++div)
+		if ((rate >> (variant->bits + div)) < freq)
+			break;
+
+	pwm_samsung_set_divisor(chip, chan, BIT(div));
+
+	return rate >> div;
+}
+
+static int pwm_samsung_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	struct samsung_pwm_channel *our_chan;
+
+	if (!(our_chip->variant.output_mask & BIT(pwm->hwpwm))) {
+		dev_warn(chip->dev,
+			"tried to request PWM channel %d without output\n",
+			pwm->hwpwm);
+		return -EINVAL;
+	}
+
+	our_chan = devm_kzalloc(chip->dev, sizeof(*our_chan), GFP_KERNEL);
+	if (!our_chan)
+		return -ENOMEM;
+
+	pwm_set_chip_data(pwm, our_chan);
+
+	return 0;
+}
+
+static void pwm_samsung_free(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	pwm_set_chip_data(pwm, NULL);
+	devm_kfree(chip->dev, pwm_get_chip_data(pwm));
+}
+
+static int pwm_samsung_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	unsigned int tcon_chan = to_tcon_channel(pwm->hwpwm);
+	unsigned long flags;
+	u32 tcon;
+
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
+
+	tcon = readl(our_chip->base + REG_TCON);
+
+	tcon &= ~TCON_START(tcon_chan);
+	tcon |= TCON_MANUALUPDATE(tcon_chan);
+	writel(tcon, our_chip->base + REG_TCON);
+
+	tcon &= ~TCON_MANUALUPDATE(tcon_chan);
+	tcon |= TCON_START(tcon_chan) | TCON_AUTORELOAD(tcon_chan);
+	writel(tcon, our_chip->base + REG_TCON);
+
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
+
+	return 0;
+}
+
+static void pwm_samsung_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	unsigned int tcon_chan = to_tcon_channel(pwm->hwpwm);
+	unsigned long flags;
+	u32 tcon;
+
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
+
+	tcon = readl(our_chip->base + REG_TCON);
+	tcon &= ~TCON_AUTORELOAD(tcon_chan);
+	writel(tcon, our_chip->base + REG_TCON);
+
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
+}
+
+static int pwm_samsung_config(struct pwm_chip *chip, struct pwm_device *pwm,
+			      int duty_ns, int period_ns)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	struct samsung_pwm_channel *chan = pwm_get_chip_data(pwm);
+	u32 tin_ns = chan->tin_ns, tcnt, tcmp;
+
+	/*
+	 * We currently avoid using 64bit arithmetic by using the
+	 * fact that anything faster than 1Hz is easily representable
+	 * by 32bits.
+	 */
+	if (period_ns > NSEC_PER_SEC)
+		return -ERANGE;
+
+	if (period_ns == chan->period_ns && duty_ns == chan->duty_ns)
+		return 0;
+
+	tcnt = readl(our_chip->base + REG_TCNTB(pwm->hwpwm));
+
+	/* We need tick count for calculation, not last tick. */
+	++tcnt;
+
+	/* Check to see if we are changing the clock rate of the PWM. */
+	if (chan->period_ns != period_ns) {
+		unsigned long tin_rate;
+		u32 period;
+
+		period = NSEC_PER_SEC / period_ns;
+
+		dev_dbg(our_chip->chip.dev, "duty_ns=%d, period_ns=%d (%u)\n",
+						duty_ns, period_ns, period);
+
+		tin_rate = pwm_samsung_calc_tin(our_chip, pwm->hwpwm, period);
+
+		dev_dbg(our_chip->chip.dev, "tin_rate=%lu\n", tin_rate);
+
+		tin_ns = NSEC_PER_SEC / tin_rate;
+		tcnt = period_ns / tin_ns;
+	}
+
+	/* Period is too short. */
+	if (tcnt <= 1)
+		return -ERANGE;
+
+	/* Note that counters count down. */
+	tcmp = duty_ns / tin_ns;
+
+	/* 0% duty is not available */
+	if (!tcmp)
+		++tcmp;
+
+	tcmp = tcnt - tcmp;
+
+	/* Decrement to get tick numbers, instead of tick counts. */
+	--tcnt;
+	/* -1UL will give 100% duty. */
+	--tcmp;
+
+	dev_dbg(our_chip->chip.dev,
+				"tin_ns=%u, tcmp=%u/%u\n", tin_ns, tcmp, tcnt);
+
+	/* Update PWM registers. */
+	writel(tcnt, our_chip->base + REG_TCNTB(pwm->hwpwm));
+	writel(tcmp, our_chip->base + REG_TCMPB(pwm->hwpwm));
+
+	if (test_bit(PWMF_ENABLED, &pwm->flags))
+		pwm_samsung_enable(chip, pwm);
+
+	chan->period_ns = period_ns;
+	chan->tin_ns = tin_ns;
+	chan->duty_ns = duty_ns;
+
+	return 0;
+}
+
+static void pwm_samsung_set_invert(struct samsung_pwm_chip *chip,
+				   unsigned int channel, bool invert)
+{
+	unsigned int tcon_chan = to_tcon_channel(channel);
+	unsigned long flags;
+	u32 tcon;
+
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
+
+	tcon = readl(chip->base + REG_TCON);
+
+	if (invert) {
+		chip->inverter_mask |= BIT(channel);
+		tcon |= TCON_INVERT(tcon_chan);
+	} else {
+		chip->inverter_mask &= ~BIT(channel);
+		tcon &= ~TCON_INVERT(tcon_chan);
+	}
+
+	writel(tcon, chip->base + REG_TCON);
+
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
+}
+
+static int pwm_samsung_set_polarity(struct pwm_chip *chip,
+				    struct pwm_device *pwm,
+				    enum pwm_polarity polarity)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	bool invert = (polarity == PWM_POLARITY_NORMAL);
+
+	/* Inverted means normal in the hardware. */
+	pwm_samsung_set_invert(our_chip, pwm->hwpwm, invert);
+
+	return 0;
+}
+
+static const struct pwm_ops pwm_samsung_ops = {
+	.request	= pwm_samsung_request,
+	.free		= pwm_samsung_free,
+	.enable		= pwm_samsung_enable,
+	.disable	= pwm_samsung_disable,
+	.config		= pwm_samsung_config,
+	.set_polarity	= pwm_samsung_set_polarity,
+	.owner		= THIS_MODULE,
+};
+
+#ifdef CONFIG_OF
+static const struct samsung_pwm_variant s3c24xx_variant = {
+	.bits		= 16,
+	.div_base	= 1,
+	.has_tint_cstat	= false,
+	.tclk_mask	= BIT(4),
+};
+
+static const struct samsung_pwm_variant s3c64xx_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= BIT(7) | BIT(6) | BIT(5),
+};
+
+static const struct samsung_pwm_variant s5p64x0_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+};
+
+static const struct samsung_pwm_variant s5p_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= BIT(5),
+};
+
+static const struct of_device_id samsung_pwm_matches[] = {
+	{ .compatible = "samsung,s3c2410-pwm", .data = &s3c24xx_variant },
+	{ .compatible = "samsung,s3c6400-pwm", .data = &s3c64xx_variant },
+	{ .compatible = "samsung,s5p6440-pwm", .data = &s5p64x0_variant },
+	{ .compatible = "samsung,s5pc100-pwm", .data = &s5p_variant },
+	{ .compatible = "samsung,exynos4210-pwm", .data = &s5p64x0_variant },
+	{},
+};
+
+static int pwm_samsung_parse_dt(struct samsung_pwm_chip *chip)
+{
+	struct device_node *np = chip->chip.dev->of_node;
+	const struct of_device_id *match;
+	struct property *prop;
+	const __be32 *cur;
+	u32 val;
+
+	match = of_match_node(samsung_pwm_matches, np);
+	if (!match)
+		return -ENODEV;
+
+	memcpy(&chip->variant, match->data, sizeof(chip->variant));
+
+	of_property_for_each_u32(np, "samsung,pwm-outputs", prop, cur, val) {
+		if (val >= SAMSUNG_PWM_NUM) {
+			pr_warn("%s: invalid channel index in samsung,pwm-outputs property\n",
+								__func__);
+			continue;
+		}
+		chip->variant.output_mask |= BIT(val);
+	}
+
+	return 0;
+}
+#else
+static int pwm_samsung_parse_dt(struct samsung_pwm_chip *chip)
+{
+	return -ENODEV;
+}
+#endif
+
+static int pwm_samsung_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct samsung_pwm_chip *chip;
+	struct resource *res;
+	unsigned int chan;
+	int ret;
+
+	chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
+	if (chip == NULL)
+		return -ENOMEM;
+
+	chip->chip.dev = &pdev->dev;
+	chip->chip.ops = &pwm_samsung_ops;
+	chip->chip.base = -1;
+	chip->chip.npwm = SAMSUNG_PWM_NUM;
+	chip->inverter_mask = BIT(SAMSUNG_PWM_NUM) - 1;
+
+	if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node) {
+		ret = pwm_samsung_parse_dt(chip);
+		if (ret)
+			return ret;
+
+		chip->chip.of_xlate = of_pwm_xlate_with_flags;
+		chip->chip.of_pwm_n_cells = 3;
+	} else {
+		if (!pdev->dev.platform_data) {
+			dev_err(&pdev->dev, "no platform data specified\n");
+			return -EINVAL;
+		}
+
+		memcpy(&chip->variant, pdev->dev.platform_data,
+							sizeof(chip->variant));
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	chip->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(chip->base))
+		return PTR_ERR(chip->base);
+
+	chip->base_clk = devm_clk_get(&pdev->dev, "timers");
+	if (IS_ERR(chip->base_clk)) {
+		dev_err(dev, "failed to get timer base clk\n");
+		return PTR_ERR(chip->base_clk);
+	}
+
+	ret = clk_prepare_enable(chip->base_clk);
+	if (ret < 0) {
+		dev_err(dev, "failed to enable base clock\n");
+		return ret;
+	}
+
+	for (chan = 0; chan < SAMSUNG_PWM_NUM; ++chan)
+		if (chip->variant.output_mask & BIT(chan))
+			pwm_samsung_set_invert(chip, chan, true);
+
+	/* Following clocks are optional. */
+	chip->tclk0 = devm_clk_get(&pdev->dev, "pwm-tclk0");
+	chip->tclk1 = devm_clk_get(&pdev->dev, "pwm-tclk1");
+
+	platform_set_drvdata(pdev, chip);
+
+	ret = pwmchip_add(&chip->chip);
+	if (ret < 0) {
+		dev_err(dev, "failed to register PWM chip\n");
+		clk_disable_unprepare(chip->base_clk);
+		return ret;
+	}
+
+	dev_dbg(dev, "base_clk at %lu, tclk0 at %lu, tclk1 at %lu\n",
+		clk_get_rate(chip->base_clk),
+		!IS_ERR(chip->tclk0) ? clk_get_rate(chip->tclk0) : 0,
+		!IS_ERR(chip->tclk1) ? clk_get_rate(chip->tclk1) : 0);
+
+	return 0;
+}
+
+static int pwm_samsung_remove(struct platform_device *pdev)
+{
+	struct samsung_pwm_chip *chip = platform_get_drvdata(pdev);
+	int ret;
+
+	ret = pwmchip_remove(&chip->chip);
+	if (ret < 0)
+		return ret;
+
+	clk_disable_unprepare(chip->base_clk);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int pwm_samsung_suspend(struct device *dev)
+{
+	struct samsung_pwm_chip *chip = dev_get_drvdata(dev);
+	unsigned int i;
+
+	/*
+	 * No one preserves these values during suspend so reset them.
+	 * Otherwise driver leaves PWM unconfigured if same values are
+	 * passed to pwm_config() next time.
+	 */
+	for (i = 0; i < SAMSUNG_PWM_NUM; ++i) {
+		struct pwm_device *pwm = &chip->chip.pwms[i];
+		struct samsung_pwm_channel *chan = pwm_get_chip_data(pwm);
+
+		if (!chan)
+			continue;
+
+		chan->period_ns = 0;
+		chan->duty_ns = 0;
+	}
+
+	return 0;
+}
+
+static int pwm_samsung_resume(struct device *dev)
+{
+	struct samsung_pwm_chip *chip = dev_get_drvdata(dev);
+	unsigned int chan;
+
+	/*
+	 * Inverter setting must be preserved across suspend/resume
+	 * as nobody really seems to configure it more than once.
+	 */
+	for (chan = 0; chan < SAMSUNG_PWM_NUM; ++chan) {
+		if (chip->variant.output_mask & BIT(chan))
+			pwm_samsung_set_invert(chip, chan,
+					chip->inverter_mask & BIT(chan));
+	}
+
+	return 0;
+}
+#endif
+
+static const struct dev_pm_ops pwm_samsung_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pwm_samsung_suspend, pwm_samsung_resume)
+};
+
+static struct platform_driver pwm_samsung_driver = {
+	.driver		= {
+		.name	= "samsung-pwm",
+		.owner	= THIS_MODULE,
+		.pm	= &pwm_samsung_pm_ops,
+		.of_match_table = of_match_ptr(samsung_pwm_matches),
+	},
+	.probe		= pwm_samsung_probe,
+	.remove		= pwm_samsung_remove,
+};
+module_platform_driver(pwm_samsung_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Tomasz Figa <tomasz.figa at gmail.com>");
+MODULE_ALIAS("platform:samsung-pwm");
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:32 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:32 +0200
Subject: [PATCH v4 19/20] ARM: SAMSUNG: Remove remaining uses of
 plat/regs-timer.h header
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-21-git-send-email-tomasz.figa@gmail.com>

This patch removes remaining inclusions of plat/regs-timer.h as
a preparation to remove the header.

As a part of this, things like save and restore of PWM registers are
removed from SoC-specific code, because it is handled in appropriate
drivers now.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/mach-s3c64xx/irq-pm.c  |  2 --
 arch/arm/mach-s5p64x0/pm.c      |  3 ---
 arch/arm/mach-s5pv210/pm.c      | 10 ----------
 arch/arm/plat-samsung/s5p-irq.c |  1 -
 4 files changed, 16 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/irq-pm.c b/arch/arm/mach-s3c64xx/irq-pm.c
index 0c7e1d9..c3da1b6 100644
--- a/arch/arm/mach-s3c64xx/irq-pm.c
+++ b/arch/arm/mach-s3c64xx/irq-pm.c
@@ -22,7 +22,6 @@
 #include <mach/map.h>
 
 #include <plat/regs-serial.h>
-#include <plat/regs-timer.h>
 #include <mach/regs-gpio.h>
 #include <plat/cpu.h>
 #include <plat/pm.h>
@@ -43,7 +42,6 @@ static struct sleep_save irq_save[] = {
 	SAVE_ITEM(S3C64XX_EINT0FLTCON2),
 	SAVE_ITEM(S3C64XX_EINT0FLTCON3),
 	SAVE_ITEM(S3C64XX_EINT0MASK),
-	SAVE_ITEM(S3C64XX_TINT_CSTAT),
 };
 
 static struct irq_grp_save {
diff --git a/arch/arm/mach-s5p64x0/pm.c b/arch/arm/mach-s5p64x0/pm.c
index 97c2a08a..861e15c 100644
--- a/arch/arm/mach-s5p64x0/pm.c
+++ b/arch/arm/mach-s5p64x0/pm.c
@@ -18,7 +18,6 @@
 
 #include <plat/cpu.h>
 #include <plat/pm.h>
-#include <plat/regs-timer.h>
 #include <plat/wakeup-mask.h>
 
 #include <mach/regs-clock.h>
@@ -48,8 +47,6 @@ static struct sleep_save s5p64x0_misc_save[] = {
 	SAVE_ITEM(S5P64X0_MEM0CONSLP1),
 	SAVE_ITEM(S5P64X0_MEM0DRVCON),
 	SAVE_ITEM(S5P64X0_MEM1DRVCON),
-
-	SAVE_ITEM(S3C64XX_TINT_CSTAT),
 };
 
 /* DPLL is present only in S5P6450 */
diff --git a/arch/arm/mach-s5pv210/pm.c b/arch/arm/mach-s5pv210/pm.c
index 2b68a67..3cf3f9c 100644
--- a/arch/arm/mach-s5pv210/pm.c
+++ b/arch/arm/mach-s5pv210/pm.c
@@ -21,7 +21,6 @@
 
 #include <plat/cpu.h>
 #include <plat/pm.h>
-#include <plat/regs-timer.h>
 
 #include <mach/regs-irq.h>
 #include <mach/regs-clock.h>
@@ -77,15 +76,6 @@ static struct sleep_save s5pv210_core_save[] = {
 	/* Clock ETC */
 	SAVE_ITEM(S5P_CLK_OUT),
 	SAVE_ITEM(S5P_MDNIE_SEL),
-
-	/* PWM Register */
-	SAVE_ITEM(S3C2410_TCFG0),
-	SAVE_ITEM(S3C2410_TCFG1),
-	SAVE_ITEM(S3C64XX_TINT_CSTAT),
-	SAVE_ITEM(S3C2410_TCON),
-	SAVE_ITEM(S3C2410_TCNTB(0)),
-	SAVE_ITEM(S3C2410_TCMPB(0)),
-	SAVE_ITEM(S3C2410_TCNTO(0)),
 };
 
 static int s5pv210_cpu_suspend(unsigned long arg)
diff --git a/arch/arm/plat-samsung/s5p-irq.c b/arch/arm/plat-samsung/s5p-irq.c
index 6729cb2..ddfaca9 100644
--- a/arch/arm/plat-samsung/s5p-irq.c
+++ b/arch/arm/plat-samsung/s5p-irq.c
@@ -17,7 +17,6 @@
 
 #include <mach/irqs.h>
 #include <mach/map.h>
-#include <plat/regs-timer.h>
 #include <plat/cpu.h>
 
 void __init s5p_init_irq(u32 *vic, u32 num_vic)
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:29 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:29 +0200
Subject: [PATCH v4 16/20] pwm: Remove superseded pwm-samsung-legacy driver
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-18-git-send-email-tomasz.figa@gmail.com>

This patch removes the now unused pwm-samsung-legacy driver, which was
replaced by new pwm-samsung driver.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/pwm/Makefile             |   1 -
 drivers/pwm/pwm-samsung-legacy.c | 353 ---------------------------------------
 2 files changed, 354 deletions(-)
 delete mode 100644 drivers/pwm/pwm-samsung-legacy.c

diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 86a5771..77a8c18 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -11,7 +11,6 @@ obj-$(CONFIG_PWM_PCA9685)	+= pwm-pca9685.o
 obj-$(CONFIG_PWM_PUV3)		+= pwm-puv3.o
 obj-$(CONFIG_PWM_PXA)		+= pwm-pxa.o
 obj-$(CONFIG_PWM_RENESAS_TPU)	+= pwm-renesas-tpu.o
-obj-$(CONFIG_PWM_SAMSUNG)	+= pwm-samsung-legacy.o
 obj-$(CONFIG_PWM_SAMSUNG)	+= pwm-samsung.o
 obj-$(CONFIG_PWM_SPEAR)		+= pwm-spear.o
 obj-$(CONFIG_PWM_TEGRA)		+= pwm-tegra.o
diff --git a/drivers/pwm/pwm-samsung-legacy.c b/drivers/pwm/pwm-samsung-legacy.c
deleted file mode 100644
index a0ece50..0000000
--- a/drivers/pwm/pwm-samsung-legacy.c
+++ /dev/null
@@ -1,353 +0,0 @@
-/* drivers/pwm/pwm-samsung.c
- *
- * Copyright (c) 2007 Ben Dooks
- * Copyright (c) 2008 Simtec Electronics
- *	Ben Dooks <ben at simtec.co.uk>, <ben-linux at fluff.org>
- *
- * S3C series PWM device core
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License.
-*/
-
-#define pr_fmt(fmt) "pwm-samsung: " fmt
-
-#include <linux/export.h>
-#include <linux/kernel.h>
-#include <linux/platform_device.h>
-#include <linux/slab.h>
-#include <linux/err.h>
-#include <linux/clk.h>
-#include <linux/io.h>
-#include <linux/pwm.h>
-
-#include <mach/map.h>
-
-#include <plat/regs-timer.h>
-
-struct s3c_chip {
-	struct platform_device	*pdev;
-
-	struct clk		*clk_div;
-	struct clk		*clk;
-	const char		*label;
-
-	unsigned int		 period_ns;
-	unsigned int		 duty_ns;
-
-	unsigned char		 tcon_base;
-	unsigned char		 pwm_id;
-	struct pwm_chip		 chip;
-};
-
-#define to_s3c_chip(chip)	container_of(chip, struct s3c_chip, chip)
-
-#define pwm_dbg(_pwm, msg...) dev_dbg(&(_pwm)->pdev->dev, msg)
-
-static struct clk *clk_scaler[2];
-
-static inline int pwm_is_tdiv(struct s3c_chip *chip)
-{
-	return clk_get_parent(chip->clk) == chip->clk_div;
-}
-
-#define pwm_tcon_start(pwm) (1 << (pwm->tcon_base + 0))
-#define pwm_tcon_invert(pwm) (1 << (pwm->tcon_base + 2))
-#define pwm_tcon_autoreload(pwm) (1 << (pwm->tcon_base + 3))
-#define pwm_tcon_manulupdate(pwm) (1 << (pwm->tcon_base + 1))
-
-static int s3c_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
-	struct s3c_chip *s3c = to_s3c_chip(chip);
-	unsigned long flags;
-	unsigned long tcon;
-
-	local_irq_save(flags);
-
-	tcon = __raw_readl(S3C2410_TCON);
-	tcon |= pwm_tcon_start(s3c);
-	__raw_writel(tcon, S3C2410_TCON);
-
-	local_irq_restore(flags);
-
-	return 0;
-}
-
-static void s3c_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
-	struct s3c_chip *s3c = to_s3c_chip(chip);
-	unsigned long flags;
-	unsigned long tcon;
-
-	local_irq_save(flags);
-
-	tcon = __raw_readl(S3C2410_TCON);
-	tcon &= ~pwm_tcon_start(s3c);
-	__raw_writel(tcon, S3C2410_TCON);
-
-	local_irq_restore(flags);
-}
-
-static unsigned long pwm_calc_tin(struct s3c_chip *s3c, unsigned long freq)
-{
-	unsigned long tin_parent_rate;
-	unsigned int div;
-
-	tin_parent_rate = clk_get_rate(clk_get_parent(s3c->clk_div));
-	pwm_dbg(s3c, "tin parent at %lu\n", tin_parent_rate);
-
-	for (div = 2; div <= 16; div *= 2) {
-		if ((tin_parent_rate / (div << 16)) < freq)
-			return tin_parent_rate / div;
-	}
-
-	return tin_parent_rate / 16;
-}
-
-#define NS_IN_HZ (1000000000UL)
-
-static int s3c_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
-		int duty_ns, int period_ns)
-{
-	struct s3c_chip *s3c = to_s3c_chip(chip);
-	unsigned long tin_rate;
-	unsigned long tin_ns;
-	unsigned long period;
-	unsigned long flags;
-	unsigned long tcon;
-	unsigned long tcnt;
-	long tcmp;
-
-	/* We currently avoid using 64bit arithmetic by using the
-	 * fact that anything faster than 1Hz is easily representable
-	 * by 32bits. */
-
-	if (period_ns > NS_IN_HZ || duty_ns > NS_IN_HZ)
-		return -ERANGE;
-
-	if (period_ns == s3c->period_ns &&
-	    duty_ns == s3c->duty_ns)
-		return 0;
-
-	/* The TCMP and TCNT can be read without a lock, they're not
-	 * shared between the timers. */
-
-	tcmp = __raw_readl(S3C2410_TCMPB(s3c->pwm_id));
-	tcnt = __raw_readl(S3C2410_TCNTB(s3c->pwm_id));
-
-	period = NS_IN_HZ / period_ns;
-
-	pwm_dbg(s3c, "duty_ns=%d, period_ns=%d (%lu)\n",
-		duty_ns, period_ns, period);
-
-	/* Check to see if we are changing the clock rate of the PWM */
-
-	if (s3c->period_ns != period_ns) {
-		if (pwm_is_tdiv(s3c)) {
-			tin_rate = pwm_calc_tin(s3c, period);
-			clk_set_rate(s3c->clk_div, tin_rate);
-		} else
-			tin_rate = clk_get_rate(s3c->clk);
-
-		s3c->period_ns = period_ns;
-
-		pwm_dbg(s3c, "tin_rate=%lu\n", tin_rate);
-
-		tin_ns = NS_IN_HZ / tin_rate;
-		tcnt = period_ns / tin_ns;
-	} else
-		tin_ns = NS_IN_HZ / clk_get_rate(s3c->clk);
-
-	/* Note, counters count down */
-
-	tcmp = duty_ns / tin_ns;
-	tcmp = tcnt - tcmp;
-	/* the pwm hw only checks the compare register after a decrement,
-	   so the pin never toggles if tcmp = tcnt */
-	if (tcmp == tcnt)
-		tcmp--;
-
-	pwm_dbg(s3c, "tin_ns=%lu, tcmp=%ld/%lu\n", tin_ns, tcmp, tcnt);
-
-	if (tcmp < 0)
-		tcmp = 0;
-
-	/* Update the PWM register block. */
-
-	local_irq_save(flags);
-
-	__raw_writel(tcmp, S3C2410_TCMPB(s3c->pwm_id));
-	__raw_writel(tcnt, S3C2410_TCNTB(s3c->pwm_id));
-
-	tcon = __raw_readl(S3C2410_TCON);
-	tcon |= pwm_tcon_manulupdate(s3c);
-	tcon |= pwm_tcon_autoreload(s3c);
-	__raw_writel(tcon, S3C2410_TCON);
-
-	tcon &= ~pwm_tcon_manulupdate(s3c);
-	__raw_writel(tcon, S3C2410_TCON);
-
-	local_irq_restore(flags);
-
-	return 0;
-}
-
-static struct pwm_ops s3c_pwm_ops = {
-	.enable = s3c_pwm_enable,
-	.disable = s3c_pwm_disable,
-	.config = s3c_pwm_config,
-	.owner = THIS_MODULE,
-};
-
-static int s3c_pwm_probe(struct platform_device *pdev)
-{
-	struct device *dev = &pdev->dev;
-	struct s3c_chip *s3c;
-	unsigned long flags;
-	unsigned long tcon;
-	unsigned int id = pdev->id;
-	int ret;
-
-	if (id == 4) {
-		dev_err(dev, "TIMER4 is currently not supported\n");
-		return -ENXIO;
-	}
-
-	s3c = devm_kzalloc(&pdev->dev, sizeof(*s3c), GFP_KERNEL);
-	if (s3c == NULL) {
-		dev_err(dev, "failed to allocate pwm_device\n");
-		return -ENOMEM;
-	}
-
-	/* calculate base of control bits in TCON */
-	s3c->tcon_base = id == 0 ? 0 : (id * 4) + 4;
-	s3c->pwm_id = id;
-	s3c->chip.dev = &pdev->dev;
-	s3c->chip.ops = &s3c_pwm_ops;
-	s3c->chip.base = -1;
-	s3c->chip.npwm = 1;
-
-	s3c->clk = devm_clk_get(dev, "pwm-tin");
-	if (IS_ERR(s3c->clk)) {
-		dev_err(dev, "failed to get pwm tin clk\n");
-		return PTR_ERR(s3c->clk);
-	}
-
-	s3c->clk_div = devm_clk_get(dev, "pwm-tdiv");
-	if (IS_ERR(s3c->clk_div)) {
-		dev_err(dev, "failed to get pwm tdiv clk\n");
-		return PTR_ERR(s3c->clk_div);
-	}
-
-	clk_enable(s3c->clk);
-	clk_enable(s3c->clk_div);
-
-	local_irq_save(flags);
-
-	tcon = __raw_readl(S3C2410_TCON);
-	tcon |= pwm_tcon_invert(s3c);
-	__raw_writel(tcon, S3C2410_TCON);
-
-	local_irq_restore(flags);
-
-	ret = pwmchip_add(&s3c->chip);
-	if (ret < 0) {
-		dev_err(dev, "failed to register pwm\n");
-		goto err_clk_tdiv;
-	}
-
-	pwm_dbg(s3c, "config bits %02x\n",
-		(__raw_readl(S3C2410_TCON) >> s3c->tcon_base) & 0x0f);
-
-	dev_info(dev, "tin at %lu, tdiv at %lu, tin=%sclk, base %d\n",
-		 clk_get_rate(s3c->clk),
-		 clk_get_rate(s3c->clk_div),
-		 pwm_is_tdiv(s3c) ? "div" : "ext", s3c->tcon_base);
-
-	platform_set_drvdata(pdev, s3c);
-	return 0;
-
- err_clk_tdiv:
-	clk_disable(s3c->clk_div);
-	clk_disable(s3c->clk);
-	return ret;
-}
-
-static int s3c_pwm_remove(struct platform_device *pdev)
-{
-	struct s3c_chip *s3c = platform_get_drvdata(pdev);
-	int err;
-
-	err = pwmchip_remove(&s3c->chip);
-	if (err < 0)
-		return err;
-
-	clk_disable(s3c->clk_div);
-	clk_disable(s3c->clk);
-
-	return 0;
-}
-
-#ifdef CONFIG_PM_SLEEP
-static int s3c_pwm_suspend(struct device *dev)
-{
-	struct s3c_chip *s3c = dev_get_drvdata(dev);
-
-	/* No one preserve these values during suspend so reset them
-	 * Otherwise driver leaves PWM unconfigured if same values
-	 * passed to pwm_config
-	 */
-	s3c->period_ns = 0;
-	s3c->duty_ns = 0;
-
-	return 0;
-}
-
-static int s3c_pwm_resume(struct device *dev)
-{
-	struct s3c_chip *s3c = dev_get_drvdata(dev);
-	unsigned long tcon;
-
-	/* Restore invertion */
-	tcon = __raw_readl(S3C2410_TCON);
-	tcon |= pwm_tcon_invert(s3c);
-	__raw_writel(tcon, S3C2410_TCON);
-
-	return 0;
-}
-#endif
-
-static SIMPLE_DEV_PM_OPS(s3c_pwm_pm_ops, s3c_pwm_suspend,
-			s3c_pwm_resume);
-
-static struct platform_driver s3c_pwm_driver = {
-	.driver		= {
-		.name	= "s3c24xx-pwm",
-		.owner	= THIS_MODULE,
-		.pm	= &s3c_pwm_pm_ops,
-	},
-	.probe		= s3c_pwm_probe,
-	.remove		= s3c_pwm_remove,
-};
-
-static int __init pwm_init(void)
-{
-	int ret;
-
-	clk_scaler[0] = clk_get(NULL, "pwm-scaler0");
-	clk_scaler[1] = clk_get(NULL, "pwm-scaler1");
-
-	if (IS_ERR(clk_scaler[0]) || IS_ERR(clk_scaler[1])) {
-		pr_err("failed to get scaler clocks\n");
-		return -EINVAL;
-	}
-
-	ret = platform_driver_register(&s3c_pwm_driver);
-	if (ret)
-		pr_err("failed to add pwm driver\n");
-
-	return ret;
-}
-
-arch_initcall(pwm_init);
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:33 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:33 +0200
Subject: [PATCH v4 20/20] ARM: SAMSUNG: Remove plat/regs-timer.h header
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-22-git-send-email-tomasz.figa@gmail.com>

Since all uses of the header has been removed by previous patches it can
be removed safely.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/plat-samsung/include/plat/regs-timer.h | 124 ------------------------
 1 file changed, 124 deletions(-)
 delete mode 100644 arch/arm/plat-samsung/include/plat/regs-timer.h

diff --git a/arch/arm/plat-samsung/include/plat/regs-timer.h b/arch/arm/plat-samsung/include/plat/regs-timer.h
deleted file mode 100644
index d097d92..0000000
--- a/arch/arm/plat-samsung/include/plat/regs-timer.h
+++ /dev/null
@@ -1,124 +0,0 @@
-/* arch/arm/mach-s3c2410/include/mach/regs-timer.h
- *
- * Copyright (c) 2003 Simtec Electronics <linux at simtec.co.uk>
- *		      http://www.simtec.co.uk/products/SWLINUX/
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * S3C2410 Timer configuration
-*/
-
-#ifndef __ASM_ARCH_REGS_TIMER_H
-#define __ASM_ARCH_REGS_TIMER_H
-
-#define S3C_TIMERREG(x) (S3C_VA_TIMER + (x))
-#define S3C_TIMERREG2(tmr,reg) S3C_TIMERREG((reg)+0x0c+((tmr)*0x0c))
-
-#define S3C2410_TCFG0	      S3C_TIMERREG(0x00)
-#define S3C2410_TCFG1	      S3C_TIMERREG(0x04)
-#define S3C2410_TCON	      S3C_TIMERREG(0x08)
-
-#define S3C64XX_TINT_CSTAT    S3C_TIMERREG(0x44)
-
-#define S3C2410_TCFG_PRESCALER0_MASK (255<<0)
-#define S3C2410_TCFG_PRESCALER1_MASK (255<<8)
-#define S3C2410_TCFG_PRESCALER1_SHIFT (8)
-#define S3C2410_TCFG_DEADZONE_MASK   (255<<16)
-#define S3C2410_TCFG_DEADZONE_SHIFT  (16)
-
-#define S3C2410_TCFG1_MUX4_DIV2	  (0<<16)
-#define S3C2410_TCFG1_MUX4_DIV4	  (1<<16)
-#define S3C2410_TCFG1_MUX4_DIV8	  (2<<16)
-#define S3C2410_TCFG1_MUX4_DIV16  (3<<16)
-#define S3C2410_TCFG1_MUX4_TCLK1  (4<<16)
-#define S3C2410_TCFG1_MUX4_MASK	  (15<<16)
-#define S3C2410_TCFG1_MUX4_SHIFT  (16)
-
-#define S3C2410_TCFG1_MUX3_DIV2	  (0<<12)
-#define S3C2410_TCFG1_MUX3_DIV4	  (1<<12)
-#define S3C2410_TCFG1_MUX3_DIV8	  (2<<12)
-#define S3C2410_TCFG1_MUX3_DIV16  (3<<12)
-#define S3C2410_TCFG1_MUX3_TCLK1  (4<<12)
-#define S3C2410_TCFG1_MUX3_MASK	  (15<<12)
-
-
-#define S3C2410_TCFG1_MUX2_DIV2	  (0<<8)
-#define S3C2410_TCFG1_MUX2_DIV4	  (1<<8)
-#define S3C2410_TCFG1_MUX2_DIV8	  (2<<8)
-#define S3C2410_TCFG1_MUX2_DIV16  (3<<8)
-#define S3C2410_TCFG1_MUX2_TCLK1  (4<<8)
-#define S3C2410_TCFG1_MUX2_MASK	  (15<<8)
-
-
-#define S3C2410_TCFG1_MUX1_DIV2	  (0<<4)
-#define S3C2410_TCFG1_MUX1_DIV4	  (1<<4)
-#define S3C2410_TCFG1_MUX1_DIV8	  (2<<4)
-#define S3C2410_TCFG1_MUX1_DIV16  (3<<4)
-#define S3C2410_TCFG1_MUX1_TCLK0  (4<<4)
-#define S3C2410_TCFG1_MUX1_MASK	  (15<<4)
-
-#define S3C2410_TCFG1_MUX0_DIV2	  (0<<0)
-#define S3C2410_TCFG1_MUX0_DIV4	  (1<<0)
-#define S3C2410_TCFG1_MUX0_DIV8	  (2<<0)
-#define S3C2410_TCFG1_MUX0_DIV16  (3<<0)
-#define S3C2410_TCFG1_MUX0_TCLK0  (4<<0)
-#define S3C2410_TCFG1_MUX0_MASK	  (15<<0)
-
-#define S3C2410_TCFG1_MUX_DIV2	  (0<<0)
-#define S3C2410_TCFG1_MUX_DIV4	  (1<<0)
-#define S3C2410_TCFG1_MUX_DIV8	  (2<<0)
-#define S3C2410_TCFG1_MUX_DIV16   (3<<0)
-#define S3C2410_TCFG1_MUX_TCLK    (4<<0)
-#define S3C2410_TCFG1_MUX_MASK	  (15<<0)
-
-#define S3C64XX_TCFG1_MUX_DIV1	  (0<<0)
-#define S3C64XX_TCFG1_MUX_DIV2	  (1<<0)
-#define S3C64XX_TCFG1_MUX_DIV4	  (2<<0)
-#define S3C64XX_TCFG1_MUX_DIV8    (3<<0)
-#define S3C64XX_TCFG1_MUX_DIV16   (4<<0)
-#define S3C64XX_TCFG1_MUX_TCLK    (5<<0)  /* 3 sets of TCLK */
-#define S3C64XX_TCFG1_MUX_MASK	  (15<<0)
-
-#define S3C2410_TCFG1_SHIFT(x)	  ((x) * 4)
-
-/* for each timer, we have an count buffer, an compare buffer and
- * an observation buffer
-*/
-
-/* WARNING - timer 4 has no buffer reg, and it's observation is at +4 */
-
-#define S3C2410_TCNTB(tmr)    S3C_TIMERREG2(tmr, 0x00)
-#define S3C2410_TCMPB(tmr)    S3C_TIMERREG2(tmr, 0x04)
-#define S3C2410_TCNTO(tmr)    S3C_TIMERREG2(tmr, (((tmr) == 4) ? 0x04 : 0x08))
-
-#define S3C2410_TCON_T4RELOAD	  (1<<22)
-#define S3C2410_TCON_T4MANUALUPD  (1<<21)
-#define S3C2410_TCON_T4START	  (1<<20)
-
-#define S3C2410_TCON_T3RELOAD	  (1<<19)
-#define S3C2410_TCON_T3INVERT	  (1<<18)
-#define S3C2410_TCON_T3MANUALUPD  (1<<17)
-#define S3C2410_TCON_T3START	  (1<<16)
-
-#define S3C2410_TCON_T2RELOAD	  (1<<15)
-#define S3C2410_TCON_T2INVERT	  (1<<14)
-#define S3C2410_TCON_T2MANUALUPD  (1<<13)
-#define S3C2410_TCON_T2START	  (1<<12)
-
-#define S3C2410_TCON_T1RELOAD	  (1<<11)
-#define S3C2410_TCON_T1INVERT	  (1<<10)
-#define S3C2410_TCON_T1MANUALUPD  (1<<9)
-#define S3C2410_TCON_T1START	  (1<<8)
-
-#define S3C2410_TCON_T0DEADZONE	  (1<<4)
-#define S3C2410_TCON_T0RELOAD	  (1<<3)
-#define S3C2410_TCON_T0INVERT	  (1<<2)
-#define S3C2410_TCON_T0MANUALUPD  (1<<1)
-#define S3C2410_TCON_T0START	  (1<<0)
-
-#endif /*  __ASM_ARCH_REGS_TIMER_H */
-
-
-
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:31 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:31 +0200
Subject: [PATCH v4 18/20] ARM: SAMSUNG: Remove pwm-clock infrastructure
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-20-git-send-email-tomasz.figa@gmail.com>

Since all the used PWM prescalers and dividers configuration has been
moved to appropriate drivers, the pwm-clock infrastructure is now
unused and so this patch removes it.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/mach-s3c24xx/clock-s3c2410.c          |   1 -
 arch/arm/mach-s3c24xx/clock-s3c2412.c          |   1 -
 arch/arm/mach-s3c24xx/clock-s3c2416.c          |   2 -
 arch/arm/mach-s3c24xx/clock-s3c2443.c          |   2 -
 arch/arm/mach-s3c64xx/clock.c                  |   2 -
 arch/arm/mach-s5p64x0/clock-s5p6440.c          |   2 -
 arch/arm/mach-s5p64x0/clock-s5p6450.c          |   2 -
 arch/arm/mach-s5pc100/clock.c                  |   2 -
 arch/arm/mach-s5pv210/clock.c                  |   1 -
 arch/arm/plat-samsung/Makefile                 |   1 -
 arch/arm/plat-samsung/include/plat/clock.h     |   4 -
 arch/arm/plat-samsung/include/plat/pwm-clock.h |  81 -----
 arch/arm/plat-samsung/pwm-clock.c              | 474 -------------------------
 13 files changed, 575 deletions(-)
 delete mode 100644 arch/arm/plat-samsung/include/plat/pwm-clock.h
 delete mode 100644 arch/arm/plat-samsung/pwm-clock.c

diff --git a/arch/arm/mach-s3c24xx/clock-s3c2410.c b/arch/arm/mach-s3c24xx/clock-s3c2410.c
index 34fffdf..afa0267 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2410.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2410.c
@@ -246,6 +246,5 @@ int __init s3c2410_baseclk_add(void)
 	       (clkslow & S3C2410_CLKSLOW_MPLL_OFF) ? "off" : "on",
 	       (clkslow & S3C2410_CLKSLOW_UCLK_OFF) ? "off" : "on");
 
-	s3c_pwmclk_init();
 	return 0;
 }
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2412.c b/arch/arm/mach-s3c24xx/clock-s3c2412.c
index 2cc017d..d8f253f 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2412.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2412.c
@@ -757,6 +757,5 @@ int __init s3c2412_baseclk_add(void)
 	}
 
 	clkdev_add_table(s3c2412_clk_lookup, ARRAY_SIZE(s3c2412_clk_lookup));
-	s3c_pwmclk_init();
 	return 0;
 }
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2416.c b/arch/arm/mach-s3c24xx/clock-s3c2416.c
index 036056ce..d421a72 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2416.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2416.c
@@ -168,6 +168,4 @@ void __init s3c2416_init_clocks(int xtal)
 	s3c24xx_register_clock(&hsmmc0_clk);
 	clkdev_add_table(s3c2416_clk_lookup, ARRAY_SIZE(s3c2416_clk_lookup));
 
-	s3c_pwmclk_init();
-
 }
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2443.c b/arch/arm/mach-s3c24xx/clock-s3c2443.c
index 0a53051..76cd31f 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2443.c
@@ -209,6 +209,4 @@ void __init s3c2443_init_clocks(int xtal)
 	s3c_register_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
 	s3c_disable_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
 	clkdev_add_table(s3c2443_clk_lookup, ARRAY_SIZE(s3c2443_clk_lookup));
-
-	s3c_pwmclk_init();
 }
diff --git a/arch/arm/mach-s3c64xx/clock.c b/arch/arm/mach-s3c64xx/clock.c
index 8499415..c1bcc4a 100644
--- a/arch/arm/mach-s3c64xx/clock.c
+++ b/arch/arm/mach-s3c64xx/clock.c
@@ -1004,6 +1004,4 @@ void __init s3c64xx_register_clocks(unsigned long xtal,
 	for (cnt = 0; cnt < ARRAY_SIZE(clksrc_cdev); cnt++)
 		s3c_register_clksrc(clksrc_cdev[cnt], 1);
 	clkdev_add_table(s3c64xx_clk_lookup, ARRAY_SIZE(s3c64xx_clk_lookup));
-
-	s3c_pwmclk_init();
 }
diff --git a/arch/arm/mach-s5p64x0/clock-s5p6440.c b/arch/arm/mach-s5p64x0/clock-s5p6440.c
index 35378152..ae34a1d 100644
--- a/arch/arm/mach-s5p64x0/clock-s5p6440.c
+++ b/arch/arm/mach-s5p64x0/clock-s5p6440.c
@@ -629,6 +629,4 @@ void __init s5p6440_register_clocks(void)
 	clkdev_add_table(s5p6440_clk_lookup, ARRAY_SIZE(s5p6440_clk_lookup));
 
 	s3c24xx_register_clock(&dummy_apb_pclk);
-
-	s3c_pwmclk_init();
 }
diff --git a/arch/arm/mach-s5p64x0/clock-s5p6450.c b/arch/arm/mach-s5p64x0/clock-s5p6450.c
index af384dd..0b3ca2e 100644
--- a/arch/arm/mach-s5p64x0/clock-s5p6450.c
+++ b/arch/arm/mach-s5p64x0/clock-s5p6450.c
@@ -698,6 +698,4 @@ void __init s5p6450_register_clocks(void)
 	clkdev_add_table(s5p6450_clk_lookup, ARRAY_SIZE(s5p6450_clk_lookup));
 
 	s3c24xx_register_clock(&dummy_apb_pclk);
-
-	s3c_pwmclk_init();
 }
diff --git a/arch/arm/mach-s5pc100/clock.c b/arch/arm/mach-s5pc100/clock.c
index a206dc3..d0dc10e 100644
--- a/arch/arm/mach-s5pc100/clock.c
+++ b/arch/arm/mach-s5pc100/clock.c
@@ -1358,6 +1358,4 @@ void __init s5pc100_register_clocks(void)
 		s3c_disable_clocks(clk_cdev[ptr], 1);
 
 	s3c24xx_register_clock(&dummy_apb_pclk);
-
-	s3c_pwmclk_init();
 }
diff --git a/arch/arm/mach-s5pv210/clock.c b/arch/arm/mach-s5pv210/clock.c
index f051f53..ca46372 100644
--- a/arch/arm/mach-s5pv210/clock.c
+++ b/arch/arm/mach-s5pv210/clock.c
@@ -1362,5 +1362,4 @@ void __init s5pv210_register_clocks(void)
 	for (ptr = 0; ptr < ARRAY_SIZE(clk_cdev); ptr++)
 		s3c_disable_clocks(clk_cdev[ptr], 1);
 
-	s3c_pwmclk_init();
 }
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index aafbe56..5d7f839 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -14,7 +14,6 @@ obj-				:=
 obj-y				+= init.o cpu.o
 
 obj-$(CONFIG_SAMSUNG_CLOCK)	+= clock.o
-obj-$(CONFIG_SAMSUNG_CLOCK)	+= pwm-clock.o
 
 obj-$(CONFIG_SAMSUNG_CLKSRC)	+= clock-clksrc.o
 obj-$(CONFIG_S5P_CLOCK)		+= s5p-clock.o
diff --git a/arch/arm/plat-samsung/include/plat/clock.h b/arch/arm/plat-samsung/include/plat/clock.h
index a62753d..254c3dd 100644
--- a/arch/arm/plat-samsung/include/plat/clock.h
+++ b/arch/arm/plat-samsung/include/plat/clock.h
@@ -140,10 +140,6 @@ extern int s3c2443_clkcon_enable_s(struct clk *clk, int enable);
 
 extern int s3c64xx_sclk_ctrl(struct clk *clk, int enable);
 
-/* Init for pwm clock code */
-
-extern void s3c_pwmclk_init(void);
-
 /* Global watchdog clock used by arch_wtd_reset() callback */
 
 extern struct clk *s3c2410_wdtclk;
diff --git a/arch/arm/plat-samsung/include/plat/pwm-clock.h b/arch/arm/plat-samsung/include/plat/pwm-clock.h
deleted file mode 100644
index bf6a60e..0000000
--- a/arch/arm/plat-samsung/include/plat/pwm-clock.h
+++ /dev/null
@@ -1,81 +0,0 @@
-/* linux/arch/arm/plat-samsung/include/plat/pwm-clock.h
- *
- * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
- *		http://www.samsung.com
- *
- * Copyright 2008 Openmoko, Inc.
- * Copyright 2008 Simtec Electronics
- *      Ben Dooks <ben at simtec.co.uk>
- *      http://armlinux.simtec.co.uk/
- *
- * SAMSUNG - pwm clock and timer support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#ifndef __ASM_PLAT_PWM_CLOCK_H
-#define __ASM_PLAT_PWM_CLOCK_H __FILE__
-
-/**
- * pwm_cfg_src_is_tclk() - return whether the given mux config is a tclk
- * @tcfg: The timer TCFG1 register bits shifted down to 0.
- *
- * Return true if the given configuration from TCFG1 is a TCLK instead
- * any of the TDIV clocks.
- */
-static inline int pwm_cfg_src_is_tclk(unsigned long tcfg)
-{
-	if (soc_is_s3c24xx())
-		return tcfg == S3C2410_TCFG1_MUX_TCLK;
-	else if (soc_is_s3c64xx() || soc_is_s5pc100())
-		return tcfg >= S3C64XX_TCFG1_MUX_TCLK;
-	else if (soc_is_s5p6440() || soc_is_s5p6450())
-		return 0;
-	else
-		return tcfg == S3C64XX_TCFG1_MUX_TCLK;
-}
-
-/**
- * tcfg_to_divisor() - convert tcfg1 setting to a divisor
- * @tcfg1: The tcfg1 setting, shifted down.
- *
- * Get the divisor value for the given tcfg1 setting. We assume the
- * caller has already checked to see if this is not a TCLK source.
- */
-static inline unsigned long tcfg_to_divisor(unsigned long tcfg1)
-{
-	if (soc_is_s3c24xx())
-		return 1 << (tcfg1 + 1);
-	else
-		return 1 << tcfg1;
-}
-
-/**
- * pwm_tdiv_has_div1() - does the tdiv setting have a /1
- *
- * Return true if we have a /1 in the tdiv setting.
- */
-static inline unsigned int pwm_tdiv_has_div1(void)
-{
-	if (soc_is_s3c24xx())
-		return 0;
-	else
-		return 1;
-}
-
-/**
- * pwm_tdiv_div_bits() - calculate TCFG1 divisor value.
- * @div: The divisor to calculate the bit information for.
- *
- * Turn a divisor into the necessary bit field for TCFG1.
- */
-static inline unsigned long pwm_tdiv_div_bits(unsigned int div)
-{
-	if (soc_is_s3c24xx())
-		return ilog2(div) - 1;
-	else
-		return ilog2(div);
-}
-#endif /* __ASM_PLAT_PWM_CLOCK_H */
diff --git a/arch/arm/plat-samsung/pwm-clock.c b/arch/arm/plat-samsung/pwm-clock.c
deleted file mode 100644
index a35ff3b..0000000
--- a/arch/arm/plat-samsung/pwm-clock.c
+++ /dev/null
@@ -1,474 +0,0 @@
-/* linux/arch/arm/plat-s3c24xx/pwm-clock.c
- *
- * Copyright (c) 2007 Simtec Electronics
- * Copyright (c) 2007, 2008 Ben Dooks
- *	Ben Dooks <ben-linux at fluff.org>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License.
-*/
-
-#include <linux/init.h>
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/list.h>
-#include <linux/errno.h>
-#include <linux/log2.h>
-#include <linux/clk.h>
-#include <linux/err.h>
-#include <linux/io.h>
-
-#include <mach/hardware.h>
-#include <mach/map.h>
-#include <asm/irq.h>
-
-#include <plat/clock.h>
-#include <plat/cpu.h>
-
-#include <plat/regs-timer.h>
-#include <plat/pwm-clock.h>
-
-/* Each of the timers 0 through 5 go through the following
- * clock tree, with the inputs depending on the timers.
- *
- * pclk ---- [ prescaler 0 ] -+---> timer 0
- *			      +---> timer 1
- *
- * pclk ---- [ prescaler 1 ] -+---> timer 2
- *			      +---> timer 3
- *			      \---> timer 4
- *
- * Which are fed into the timers as so:
- *
- * prescaled 0 ---- [ div 2,4,8,16 ] ---\
- *				       [mux] -> timer 0
- * tclk 0 ------------------------------/
- *
- * prescaled 0 ---- [ div 2,4,8,16 ] ---\
- *				       [mux] -> timer 1
- * tclk 0 ------------------------------/
- *
- *
- * prescaled 1 ---- [ div 2,4,8,16 ] ---\
- *				       [mux] -> timer 2
- * tclk 1 ------------------------------/
- *
- * prescaled 1 ---- [ div 2,4,8,16 ] ---\
- *				       [mux] -> timer 3
- * tclk 1 ------------------------------/
- *
- * prescaled 1 ---- [ div 2,4,8, 16 ] --\
- *				       [mux] -> timer 4
- * tclk 1 ------------------------------/
- *
- * Since the mux and the divider are tied together in the
- * same register space, it is impossible to set the parent
- * and the rate at the same time. To avoid this, we add an
- * intermediate 'prescaled-and-divided' clock to select
- * as the parent for the timer input clock called tdiv.
- *
- * prescaled clk --> pwm-tdiv ---\
- *                             [ mux ] --> timer X
- * tclk -------------------------/
-*/
-
-static struct clk clk_timer_scaler[];
-
-static unsigned long clk_pwm_scaler_get_rate(struct clk *clk)
-{
-	unsigned long tcfg0 = __raw_readl(S3C2410_TCFG0);
-
-	if (clk == &clk_timer_scaler[1]) {
-		tcfg0 &= S3C2410_TCFG_PRESCALER1_MASK;
-		tcfg0 >>= S3C2410_TCFG_PRESCALER1_SHIFT;
-	} else {
-		tcfg0 &= S3C2410_TCFG_PRESCALER0_MASK;
-	}
-
-	return clk_get_rate(clk->parent) / (tcfg0 + 1);
-}
-
-static unsigned long clk_pwm_scaler_round_rate(struct clk *clk,
-					       unsigned long rate)
-{
-	unsigned long parent_rate = clk_get_rate(clk->parent);
-	unsigned long divisor = parent_rate / rate;
-
-	if (divisor > 256)
-		divisor = 256;
-	else if (divisor < 2)
-		divisor = 2;
-
-	return parent_rate / divisor;
-}
-
-static int clk_pwm_scaler_set_rate(struct clk *clk, unsigned long rate)
-{
-	unsigned long round = clk_pwm_scaler_round_rate(clk, rate);
-	unsigned long tcfg0;
-	unsigned long divisor;
-	unsigned long flags;
-
-	divisor = clk_get_rate(clk->parent) / round;
-	divisor--;
-
-	local_irq_save(flags);
-	tcfg0 = __raw_readl(S3C2410_TCFG0);
-
-	if (clk == &clk_timer_scaler[1]) {
-		tcfg0 &= ~S3C2410_TCFG_PRESCALER1_MASK;
-		tcfg0 |= divisor << S3C2410_TCFG_PRESCALER1_SHIFT;
-	} else {
-		tcfg0 &= ~S3C2410_TCFG_PRESCALER0_MASK;
-		tcfg0 |= divisor;
-	}
-
-	__raw_writel(tcfg0, S3C2410_TCFG0);
-	local_irq_restore(flags);
-
-	return 0;
-}
-
-static struct clk_ops clk_pwm_scaler_ops = {
-	.get_rate	= clk_pwm_scaler_get_rate,
-	.set_rate	= clk_pwm_scaler_set_rate,
-	.round_rate	= clk_pwm_scaler_round_rate,
-};
-
-static struct clk clk_timer_scaler[] = {
-	[0]	= {
-		.name		= "pwm-scaler0",
-		.id		= -1,
-		.ops		= &clk_pwm_scaler_ops,
-	},
-	[1]	= {
-		.name		= "pwm-scaler1",
-		.id		= -1,
-		.ops		= &clk_pwm_scaler_ops,
-	},
-};
-
-static struct clk clk_timer_tclk[] = {
-	[0]	= {
-		.name		= "pwm-tclk0",
-		.id		= -1,
-	},
-	[1]	= {
-		.name		= "pwm-tclk1",
-		.id		= -1,
-	},
-};
-
-struct pwm_tdiv_clk {
-	struct clk	clk;
-	unsigned int	divisor;
-};
-
-static inline struct pwm_tdiv_clk *to_tdiv(struct clk *clk)
-{
-	return container_of(clk, struct pwm_tdiv_clk, clk);
-}
-
-static unsigned long clk_pwm_tdiv_get_rate(struct clk *clk)
-{
-	unsigned long tcfg1 = __raw_readl(S3C2410_TCFG1);
-	unsigned int divisor;
-
-	tcfg1 >>= S3C2410_TCFG1_SHIFT(clk->id);
-	tcfg1 &= S3C2410_TCFG1_MUX_MASK;
-
-	if (pwm_cfg_src_is_tclk(tcfg1))
-		divisor = to_tdiv(clk)->divisor;
-	else
-		divisor = tcfg_to_divisor(tcfg1);
-
-	return clk_get_rate(clk->parent) / divisor;
-}
-
-static unsigned long clk_pwm_tdiv_round_rate(struct clk *clk,
-					     unsigned long rate)
-{
-	unsigned long parent_rate;
-	unsigned long divisor;
-
-	parent_rate = clk_get_rate(clk->parent);
-	divisor = parent_rate / rate;
-
-	if (divisor <= 1 && pwm_tdiv_has_div1())
-		divisor = 1;
-	else if (divisor <= 2)
-		divisor = 2;
-	else if (divisor <= 4)
-		divisor = 4;
-	else if (divisor <= 8)
-		divisor = 8;
-	else
-		divisor = 16;
-
-	return parent_rate / divisor;
-}
-
-static unsigned long clk_pwm_tdiv_bits(struct pwm_tdiv_clk *divclk)
-{
-	return pwm_tdiv_div_bits(divclk->divisor);
-}
-
-static void clk_pwm_tdiv_update(struct pwm_tdiv_clk *divclk)
-{
-	unsigned long tcfg1 = __raw_readl(S3C2410_TCFG1);
-	unsigned long bits = clk_pwm_tdiv_bits(divclk);
-	unsigned long flags;
-	unsigned long shift =  S3C2410_TCFG1_SHIFT(divclk->clk.id);
-
-	local_irq_save(flags);
-
-	tcfg1 = __raw_readl(S3C2410_TCFG1);
-	tcfg1 &= ~(S3C2410_TCFG1_MUX_MASK << shift);
-	tcfg1 |= bits << shift;
-	__raw_writel(tcfg1, S3C2410_TCFG1);
-
-	local_irq_restore(flags);
-}
-
-static int clk_pwm_tdiv_set_rate(struct clk *clk, unsigned long rate)
-{
-	struct pwm_tdiv_clk *divclk = to_tdiv(clk);
-	unsigned long tcfg1 = __raw_readl(S3C2410_TCFG1);
-	unsigned long parent_rate = clk_get_rate(clk->parent);
-	unsigned long divisor;
-
-	tcfg1 >>= S3C2410_TCFG1_SHIFT(clk->id);
-	tcfg1 &= S3C2410_TCFG1_MUX_MASK;
-
-	rate = clk_round_rate(clk, rate);
-	divisor = parent_rate / rate;
-
-	if (divisor > 16)
-		return -EINVAL;
-
-	divclk->divisor = divisor;
-
-	/* Update the current MUX settings if we are currently
-	 * selected as the clock source for this clock. */
-
-	if (!pwm_cfg_src_is_tclk(tcfg1))
-		clk_pwm_tdiv_update(divclk);
-
-	return 0;
-}
-
-static struct clk_ops clk_tdiv_ops = {
-	.get_rate	= clk_pwm_tdiv_get_rate,
-	.set_rate	= clk_pwm_tdiv_set_rate,
-	.round_rate	= clk_pwm_tdiv_round_rate,
-};
-
-static struct pwm_tdiv_clk clk_timer_tdiv[] = {
-	[0]	= {
-		.clk	= {
-			.name	= "pwm-tdiv",
-			.devname	= "s3c24xx-pwm.0",
-			.ops	= &clk_tdiv_ops,
-			.parent	= &clk_timer_scaler[0],
-		},
-	},
-	[1]	= {
-		.clk	= {
-			.name	= "pwm-tdiv",
-			.devname	= "s3c24xx-pwm.1",
-			.ops	= &clk_tdiv_ops,
-			.parent	= &clk_timer_scaler[0],
-		}
-	},
-	[2]	= {
-		.clk	= {
-			.name	= "pwm-tdiv",
-			.devname	= "s3c24xx-pwm.2",
-			.ops	= &clk_tdiv_ops,
-			.parent	= &clk_timer_scaler[1],
-		},
-	},
-	[3]	= {
-		.clk	= {
-			.name	= "pwm-tdiv",
-			.devname	= "s3c24xx-pwm.3",
-			.ops	= &clk_tdiv_ops,
-			.parent	= &clk_timer_scaler[1],
-		},
-	},
-	[4]	= {
-		.clk	= {
-			.name	= "pwm-tdiv",
-			.devname	= "s3c24xx-pwm.4",
-			.ops	= &clk_tdiv_ops,
-			.parent	= &clk_timer_scaler[1],
-		},
-	},
-};
-
-static int __init clk_pwm_tdiv_register(unsigned int id)
-{
-	struct pwm_tdiv_clk *divclk = &clk_timer_tdiv[id];
-	unsigned long tcfg1 = __raw_readl(S3C2410_TCFG1);
-
-	tcfg1 >>= S3C2410_TCFG1_SHIFT(id);
-	tcfg1 &= S3C2410_TCFG1_MUX_MASK;
-
-	divclk->clk.id = id;
-	divclk->divisor = tcfg_to_divisor(tcfg1);
-
-	return s3c24xx_register_clock(&divclk->clk);
-}
-
-static inline struct clk *s3c24xx_pwmclk_tclk(unsigned int id)
-{
-	return (id >= 2) ? &clk_timer_tclk[1] : &clk_timer_tclk[0];
-}
-
-static inline struct clk *s3c24xx_pwmclk_tdiv(unsigned int id)
-{
-	return &clk_timer_tdiv[id].clk;
-}
-
-static int clk_pwm_tin_set_parent(struct clk *clk, struct clk *parent)
-{
-	unsigned int id = clk->id;
-	unsigned long tcfg1;
-	unsigned long flags;
-	unsigned long bits;
-	unsigned long shift = S3C2410_TCFG1_SHIFT(id);
-
-	unsigned long mux_tclk;
-
-	if (soc_is_s3c24xx())
-		mux_tclk = S3C2410_TCFG1_MUX_TCLK;
-	else if (soc_is_s5p6440() || soc_is_s5p6450())
-		mux_tclk = 0;
-	else
-		mux_tclk = S3C64XX_TCFG1_MUX_TCLK;
-
-	if (parent == s3c24xx_pwmclk_tclk(id))
-		bits = mux_tclk << shift;
-	else if (parent == s3c24xx_pwmclk_tdiv(id))
-		bits = clk_pwm_tdiv_bits(to_tdiv(parent)) << shift;
-	else
-		return -EINVAL;
-
-	clk->parent = parent;
-
-	local_irq_save(flags);
-
-	tcfg1 = __raw_readl(S3C2410_TCFG1);
-	tcfg1 &= ~(S3C2410_TCFG1_MUX_MASK << shift);
-	__raw_writel(tcfg1 | bits, S3C2410_TCFG1);
-
-	local_irq_restore(flags);
-
-	return 0;
-}
-
-static struct clk_ops clk_tin_ops = {
-	.set_parent	= clk_pwm_tin_set_parent,
-};
-
-static struct clk clk_tin[] = {
-	[0]	= {
-		.name	= "pwm-tin",
-		.devname	= "s3c24xx-pwm.0",
-		.id	= 0,
-		.ops	= &clk_tin_ops,
-	},
-	[1]	= {
-		.name	= "pwm-tin",
-		.devname	= "s3c24xx-pwm.1",
-		.id	= 1,
-		.ops	= &clk_tin_ops,
-	},
-	[2]	= {
-		.name	= "pwm-tin",
-		.devname	= "s3c24xx-pwm.2",
-		.id	= 2,
-		.ops	= &clk_tin_ops,
-	},
-	[3]	= {
-		.name	= "pwm-tin",
-		.devname	= "s3c24xx-pwm.3",
-		.id	= 3,
-		.ops	= &clk_tin_ops,
-	},
-	[4]	= {
-		.name	= "pwm-tin",
-		.devname	= "s3c24xx-pwm.4",
-		.id	= 4,
-		.ops	= &clk_tin_ops,
-	},
-};
-
-static __init int clk_pwm_tin_register(struct clk *pwm)
-{
-	unsigned long tcfg1 = __raw_readl(S3C2410_TCFG1);
-	unsigned int id = pwm->id;
-
-	struct clk *parent;
-	int ret;
-
-	ret = s3c24xx_register_clock(pwm);
-	if (ret < 0)
-		return ret;
-
-	tcfg1 >>= S3C2410_TCFG1_SHIFT(id);
-	tcfg1 &= S3C2410_TCFG1_MUX_MASK;
-
-	if (pwm_cfg_src_is_tclk(tcfg1))
-		parent = s3c24xx_pwmclk_tclk(id);
-	else
-		parent = s3c24xx_pwmclk_tdiv(id);
-
-	return clk_set_parent(pwm, parent);
-}
-
-/**
- * s3c_pwmclk_init() - initialise pwm clocks
- *
- * Initialise and register the clocks which provide the inputs for the
- * pwm timer blocks.
- *
- * Note, this call is required by the time core, so must be called after
- * the base clocks are added and before any of the initcalls are run.
- */
-__init void s3c_pwmclk_init(void)
-{
-	struct clk *clk_timers;
-	unsigned int clk;
-	int ret;
-
-	clk_timers = clk_get(NULL, "timers");
-	if (IS_ERR(clk_timers)) {
-		printk(KERN_ERR "%s: no parent clock\n", __func__);
-		return;
-	}
-
-	for (clk = 0; clk < ARRAY_SIZE(clk_timer_scaler); clk++)
-		clk_timer_scaler[clk].parent = clk_timers;
-
-	s3c_register_clocks(clk_timer_scaler, ARRAY_SIZE(clk_timer_scaler));
-	s3c_register_clocks(clk_timer_tclk, ARRAY_SIZE(clk_timer_tclk));
-
-	for (clk = 0; clk < ARRAY_SIZE(clk_timer_tdiv); clk++) {
-		ret = clk_pwm_tdiv_register(clk);
-
-		if (ret < 0) {
-			printk(KERN_ERR "error adding pwm%d tdiv clock\n", clk);
-			return;
-		}
-	}
-
-	for (clk = 0; clk < ARRAY_SIZE(clk_tin); clk++) {
-		ret = clk_pwm_tin_register(&clk_tin[clk]);
-		if (ret < 0) {
-			printk(KERN_ERR "error adding pwm%d tin clock\n", clk);
-			return;
-		}
-	}
-}
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:24 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:24 +0200
Subject: [PATCH v4 11/20] ARM: SAMSUNG: Remove unused PWM timer IRQ chip code
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-13-git-send-email-tomasz.figa@gmail.com>

From: Tomasz Figa <t.figa at samsung.com>

As the need for an IRQ chip handling PWM timer interrupt chaining is
gone now, this patch removes all the code made unnecessary.

Signed-off-by: Tomasz Figa <t.figa at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/Kconfig                                   |  1 -
 arch/arm/mach-s3c64xx/include/mach/irqs.h          |  8 --
 arch/arm/mach-s5p64x0/include/mach/irqs.h          |  2 -
 arch/arm/mach-s5pc100/include/mach/irqs.h          |  2 -
 arch/arm/mach-s5pv210/include/mach/irqs.h          |  2 -
 arch/arm/plat-samsung/Kconfig                      |  6 --
 arch/arm/plat-samsung/Makefile                     |  1 -
 arch/arm/plat-samsung/devs.c                       | 25 ++----
 arch/arm/plat-samsung/include/plat/irq-vic-timer.h | 13 ---
 arch/arm/plat-samsung/include/plat/irqs.h          |  9 --
 arch/arm/plat-samsung/irq-vic-timer.c              | 98 ----------------------
 11 files changed, 6 insertions(+), 161 deletions(-)
 delete mode 100644 arch/arm/plat-samsung/include/plat/irq-vic-timer.h
 delete mode 100644 arch/arm/plat-samsung/irq-vic-timer.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 486ab0a..fa7ffca 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -739,7 +739,6 @@ config ARCH_S3C64XX
 	select SAMSUNG_ATAGS
 	select SAMSUNG_CLKSRC
 	select SAMSUNG_GPIOLIB_4BIT
-	select SAMSUNG_IRQ_VIC_TIMER
 	select SAMSUNG_WDT_RESET
 	select USB_ARCH_HAS_OHCI
 	help
diff --git a/arch/arm/mach-s3c64xx/include/mach/irqs.h b/arch/arm/mach-s3c64xx/include/mach/irqs.h
index 96d60e0..67bbd1d 100644
--- a/arch/arm/mach-s3c64xx/include/mach/irqs.h
+++ b/arch/arm/mach-s3c64xx/include/mach/irqs.h
@@ -107,14 +107,6 @@
 #define IRQ_TC			IRQ_PENDN
 #define IRQ_ADC			S3C64XX_IRQ_VIC1(31)
 
-#define S3C64XX_TIMER_IRQ(x)	S3C_IRQ(64 + (x))
-
-#define IRQ_TIMER0		S3C64XX_TIMER_IRQ(0)
-#define IRQ_TIMER1		S3C64XX_TIMER_IRQ(1)
-#define IRQ_TIMER2		S3C64XX_TIMER_IRQ(2)
-#define IRQ_TIMER3		S3C64XX_TIMER_IRQ(3)
-#define IRQ_TIMER4		S3C64XX_TIMER_IRQ(4)
-
 /* compatibility for device defines */
 
 #define IRQ_IIC1		IRQ_S3C6410_IIC1
diff --git a/arch/arm/mach-s5p64x0/include/mach/irqs.h b/arch/arm/mach-s5p64x0/include/mach/irqs.h
index 5b845e8..53982db 100644
--- a/arch/arm/mach-s5p64x0/include/mach/irqs.h
+++ b/arch/arm/mach-s5p64x0/include/mach/irqs.h
@@ -141,8 +141,6 @@
 
 #define IRQ_EINT_GROUP(grp, x)	(IRQ_EINT_GROUP##grp##_BASE + (x))
 
-#define IRQ_TIMER_BASE		(11)
-
 /* Set the default NR_IRQS */
 
 #define NR_IRQS			(IRQ_EINT_GROUP8_BASE + IRQ_EINT_GROUP8_NR + 1)
diff --git a/arch/arm/mach-s5pc100/include/mach/irqs.h b/arch/arm/mach-s5pc100/include/mach/irqs.h
index 2870f12..d2eb475 100644
--- a/arch/arm/mach-s5pc100/include/mach/irqs.h
+++ b/arch/arm/mach-s5pc100/include/mach/irqs.h
@@ -97,8 +97,6 @@
 #define IRQ_SDMFIQ		S5P_IRQ_VIC2(31)
 #define IRQ_VIC_END		S5P_IRQ_VIC2(31)
 
-#define IRQ_TIMER_BASE		(11)
-
 #define S5P_EINT_BASE1		(S5P_IRQ_VIC0(0))
 #define S5P_EINT_BASE2		(IRQ_VIC_END + 1)
 
diff --git a/arch/arm/mach-s5pv210/include/mach/irqs.h b/arch/arm/mach-s5pv210/include/mach/irqs.h
index e777e01..5e0de3a 100644
--- a/arch/arm/mach-s5pv210/include/mach/irqs.h
+++ b/arch/arm/mach-s5pv210/include/mach/irqs.h
@@ -118,8 +118,6 @@
 #define IRQ_MDNIE3		S5P_IRQ_VIC3(8)
 #define IRQ_VIC_END		S5P_IRQ_VIC3(31)
 
-#define IRQ_TIMER_BASE		(11)
-
 #define S5P_EINT_BASE1		(S5P_IRQ_VIC0(0))
 #define S5P_EINT_BASE2		(IRQ_VIC_END + 1)
 
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 3e880b7..b21d9d5 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -25,7 +25,6 @@ config PLAT_S5P
 	select S5P_GPIO_DRVSTR
 	select SAMSUNG_CLKSRC if !COMMON_CLK
 	select SAMSUNG_GPIOLIB_4BIT
-	select SAMSUNG_IRQ_VIC_TIMER
 	help
 	  Base platform code for Samsung's S5P series SoC.
 
@@ -91,11 +90,6 @@ config S5P_CLOCK
 
 # options for IRQ support
 
-config SAMSUNG_IRQ_VIC_TIMER
-       bool
-       help
-         Internal configuration to build the VIC timer interrupt code.
-
 config S5P_IRQ
 	def_bool (ARCH_S5P64X0 || ARCH_S5PC100 || ARCH_S5PV210)
 	help
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index cf41bf9..aafbe56 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -19,7 +19,6 @@ obj-$(CONFIG_SAMSUNG_CLOCK)	+= pwm-clock.o
 obj-$(CONFIG_SAMSUNG_CLKSRC)	+= clock-clksrc.o
 obj-$(CONFIG_S5P_CLOCK)		+= s5p-clock.o
 
-obj-$(CONFIG_SAMSUNG_IRQ_VIC_TIMER) += irq-vic-timer.o
 obj-$(CONFIG_S5P_IRQ)		+= s5p-irq.o
 obj-$(CONFIG_S5P_EXT_INT)	+= s5p-irq-eint.o
 obj-$(CONFIG_S5P_GPIO_INT)	+= s5p-irq-gpioint.o
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index bba6d78..290f63a 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -1099,22 +1099,9 @@ arch_initcall(s5p_pmu_init);
 
 #ifdef CONFIG_SAMSUNG_DEV_PWM
 
-#define TIMER_RESOURCE_SIZE (1)
-
-#define TIMER_RESOURCE(_tmr, _irq)			\
-	(struct resource [TIMER_RESOURCE_SIZE]) {	\
-		[0] = {					\
-			.start	= _irq,			\
-			.end	= _irq,			\
-			.flags	= IORESOURCE_IRQ	\
-		}					\
-	}
-
-#define DEFINE_S3C_TIMER(_tmr_no, _irq)			\
+#define DEFINE_S3C_TIMER(_tmr_no)			\
 	.name		= "s3c24xx-pwm",		\
 	.id		= _tmr_no,			\
-	.num_resources	= TIMER_RESOURCE_SIZE,		\
-	.resource	= TIMER_RESOURCE(_tmr_no, _irq),	\
 
 /*
  * since we already have an static mapping for the timer,
@@ -1122,11 +1109,11 @@ arch_initcall(s5p_pmu_init);
  */
 
 struct platform_device s3c_device_timer[] = {
-	[0] = { DEFINE_S3C_TIMER(0, IRQ_TIMER0) },
-	[1] = { DEFINE_S3C_TIMER(1, IRQ_TIMER1) },
-	[2] = { DEFINE_S3C_TIMER(2, IRQ_TIMER2) },
-	[3] = { DEFINE_S3C_TIMER(3, IRQ_TIMER3) },
-	[4] = { DEFINE_S3C_TIMER(4, IRQ_TIMER4) },
+	[0] = { DEFINE_S3C_TIMER(0) },
+	[1] = { DEFINE_S3C_TIMER(1) },
+	[2] = { DEFINE_S3C_TIMER(2) },
+	[3] = { DEFINE_S3C_TIMER(3) },
+	[4] = { DEFINE_S3C_TIMER(4) },
 };
 
 static struct resource samsung_pwm_resource[] = {
diff --git a/arch/arm/plat-samsung/include/plat/irq-vic-timer.h b/arch/arm/plat-samsung/include/plat/irq-vic-timer.h
deleted file mode 100644
index 5b9c42f..0000000
--- a/arch/arm/plat-samsung/include/plat/irq-vic-timer.h
+++ /dev/null
@@ -1,13 +0,0 @@
-/* arch/arm/plat-samsung/include/plat/irq-vic-timer.h
- *
- * Copyright (c) 2010 Simtec Electronics
- *	Ben Dooks <ben at simtec.co.uk>
- *
- * Header file for Samsung SoC IRQ VIC timer
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-extern void s3c_init_vic_timer_irq(unsigned int num, unsigned int timer_irq);
diff --git a/arch/arm/plat-samsung/include/plat/irqs.h b/arch/arm/plat-samsung/include/plat/irqs.h
index df46b77..039001c 100644
--- a/arch/arm/plat-samsung/include/plat/irqs.h
+++ b/arch/arm/plat-samsung/include/plat/irqs.h
@@ -44,15 +44,6 @@
 #define S5P_IRQ_VIC2(x)		(S5P_VIC2_BASE + (x))
 #define S5P_IRQ_VIC3(x)		(S5P_VIC3_BASE + (x))
 
-#define S5P_TIMER_IRQ(x)	(IRQ_TIMER_BASE + (x))
-
-#define IRQ_TIMER0		S5P_TIMER_IRQ(0)
-#define IRQ_TIMER1		S5P_TIMER_IRQ(1)
-#define IRQ_TIMER2		S5P_TIMER_IRQ(2)
-#define IRQ_TIMER3		S5P_TIMER_IRQ(3)
-#define IRQ_TIMER4		S5P_TIMER_IRQ(4)
-#define IRQ_TIMER_COUNT		(5)
-
 #define IRQ_EINT(x)		((x) < 16 ? ((x) + S5P_EINT_BASE1) \
 					: ((x) - 16 + S5P_EINT_BASE2))
 
diff --git a/arch/arm/plat-samsung/irq-vic-timer.c b/arch/arm/plat-samsung/irq-vic-timer.c
deleted file mode 100644
index 0fceb42..0000000
--- a/arch/arm/plat-samsung/irq-vic-timer.c
+++ /dev/null
@@ -1,98 +0,0 @@
-/* arch/arm/plat-samsung/irq-vic-timer.c
- *	originally part of arch/arm/plat-s3c64xx/irq.c
- *
- * Copyright 2008 Openmoko, Inc.
- * Copyright 2008 Simtec Electronics
- *      Ben Dooks <ben at simtec.co.uk>
- *      http://armlinux.simtec.co.uk/
- *
- * S3C64XX - Interrupt handling
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/kernel.h>
-#include <linux/interrupt.h>
-#include <linux/irq.h>
-#include <linux/irqchip/chained_irq.h>
-#include <linux/io.h>
-
-#include <mach/map.h>
-#include <mach/irqs.h>
-#include <plat/cpu.h>
-#include <plat/irq-vic-timer.h>
-#include <plat/regs-timer.h>
-
-static void s3c_irq_demux_vic_timer(unsigned int irq, struct irq_desc *desc)
-{
-	struct irq_chip *chip = irq_get_chip(irq);
-	chained_irq_enter(chip, desc);
-	generic_handle_irq((int)desc->irq_data.handler_data);
-	chained_irq_exit(chip, desc);
-}
-
-/* We assume the IRQ_TIMER0..IRQ_TIMER4 range is continuous. */
-static void s3c_irq_timer_ack(struct irq_data *d)
-{
-	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-	u32 mask = (1 << 5) << (d->irq - gc->irq_base);
-
-	irq_reg_writel(mask | gc->mask_cache, gc->reg_base);
-}
-
-/**
- * s3c_init_vic_timer_irq() - initialise timer irq chanined off VIC.\
- * @num: Number of timers to initialize
- * @timer_irq: Base IRQ number to be used for the timers.
- *
- * Register the necessary IRQ chaining and support for the timer IRQs
- * chained of the VIC.
- */
-void __init s3c_init_vic_timer_irq(unsigned int num, unsigned int timer_irq)
-{
-	unsigned int pirq[5] = { IRQ_TIMER0_VIC, IRQ_TIMER1_VIC, IRQ_TIMER2_VIC,
-				 IRQ_TIMER3_VIC, IRQ_TIMER4_VIC };
-	struct irq_chip_generic *s3c_tgc;
-	struct irq_chip_type *ct;
-	unsigned int i;
-
-#ifdef CONFIG_ARCH_EXYNOS
-	if (soc_is_exynos5250()) {
-		pirq[0] = EXYNOS5_IRQ_TIMER0_VIC;
-		pirq[1] = EXYNOS5_IRQ_TIMER1_VIC;
-		pirq[2] = EXYNOS5_IRQ_TIMER2_VIC;
-		pirq[3] = EXYNOS5_IRQ_TIMER3_VIC;
-		pirq[4] = EXYNOS5_IRQ_TIMER4_VIC;
-	} else {
-		pirq[0] = EXYNOS4_IRQ_TIMER0_VIC;
-		pirq[1] = EXYNOS4_IRQ_TIMER1_VIC;
-		pirq[2] = EXYNOS4_IRQ_TIMER2_VIC;
-		pirq[3] = EXYNOS4_IRQ_TIMER3_VIC;
-		pirq[4] = EXYNOS4_IRQ_TIMER4_VIC;
-	}
-#endif
-	s3c_tgc = irq_alloc_generic_chip("s3c-timer", 1, timer_irq,
-					 S3C64XX_TINT_CSTAT, handle_level_irq);
-
-	if (!s3c_tgc) {
-		pr_err("%s: irq_alloc_generic_chip for IRQ %d failed\n",
-		       __func__, timer_irq);
-		return;
-	}
-
-	ct = s3c_tgc->chip_types;
-	ct->chip.irq_mask = irq_gc_mask_clr_bit;
-	ct->chip.irq_unmask = irq_gc_mask_set_bit;
-	ct->chip.irq_ack = s3c_irq_timer_ack;
-	irq_setup_generic_chip(s3c_tgc, IRQ_MSK(num), IRQ_GC_INIT_MASK_CACHE,
-			       IRQ_NOREQUEST | IRQ_NOPROBE, 0);
-	/* Clear the upper bits of the mask_cache*/
-	s3c_tgc->mask_cache &= 0x1f;
-
-	for (i = 0; i < num; i++, timer_irq++) {
-		irq_set_chained_handler(pirq[i], s3c_irq_demux_vic_timer);
-		irq_set_handler_data(pirq[i], (void *)timer_irq);
-	}
-}
-- 
1.8.3.2



From tomasz.figa at gmail.com  Fri Jul 19 20:04:25 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 20 Jul 2013 02:04:25 +0200
Subject: [PATCH v4 12/20] pwm: samsung: Rename to pwm-samsung-legacy
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374278673-25615-14-git-send-email-tomasz.figa@gmail.com>

This patch renames the old pwm-samsung driver to pwm-samsung-legacy to
create place for the new, rewritten, DT-aware pwm-samsung driver using
Samsung PWM/timer master driver.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/pwm/Makefile                                | 2 +-
 drivers/pwm/{pwm-samsung.c => pwm-samsung-legacy.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/pwm/{pwm-samsung.c => pwm-samsung-legacy.c} (100%)

diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 77a8c18..aa94807 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_PWM_PCA9685)	+= pwm-pca9685.o
 obj-$(CONFIG_PWM_PUV3)		+= pwm-puv3.o
 obj-$(CONFIG_PWM_PXA)		+= pwm-pxa.o
 obj-$(CONFIG_PWM_RENESAS_TPU)	+= pwm-renesas-tpu.o
-obj-$(CONFIG_PWM_SAMSUNG)	+= pwm-samsung.o
+obj-$(CONFIG_PWM_SAMSUNG)	+= pwm-samsung-legacy.o
 obj-$(CONFIG_PWM_SPEAR)		+= pwm-spear.o
 obj-$(CONFIG_PWM_TEGRA)		+= pwm-tegra.o
 obj-$(CONFIG_PWM_TIECAP)	+= pwm-tiecap.o
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung-legacy.c
similarity index 100%
rename from drivers/pwm/pwm-samsung.c
rename to drivers/pwm/pwm-samsung-legacy.c
-- 
1.8.3.2



From kishon at ti.com  Fri Jul 19 23:15:29 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Sat, 20 Jul 2013 08:45:29 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51E96135.9090108@wwwdotorg.org>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-2-git-send-email-kishon@ti.com>
 <20130718072004.GA16720@kroah.com> <51E7AE88.3050007@ti.com>
 <20130718154954.GA31961@kroah.com> <51E8D086.809@ti.com>
 <20130719054311.GA14638@kroah.com> <51E8D4E0.8060200@ti.com>
 <20130719062941.GA23611@kroah.com> <51E8DE51.1060404@ti.com>
 <51E96135.9090108@wwwdotorg.org>
Message-ID: <51EA00D1.7080402@ti.com>

Hi,

On Friday 19 July 2013 09:24 PM, Stephen Warren wrote:
> On 07/19/2013 12:36 AM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Friday 19 July 2013 11:59 AM, Greg KH wrote:
>>> On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote:
>>>> Hi,
>>>>
>>>> On Friday 19 July 2013 11:13 AM, Greg KH wrote:
>>>>> On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote:
>>>>>>>>>> +	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
>>>>>>>>>
>>>>>>>>> Your naming is odd, no "phy" anywhere in it?  You rely on the sender to
>>>>>>>>> never send a duplicate name.id pair?  Why not create your own ids based
>>>>>>>>> on the number of phys in the system, like almost all other classes and
>>>>>>>>> subsystems do?
>>>>>>>>
>>>>>>>> hmm.. some PHY drivers use the id they provide to perform some of their
>>>>>>>> internal operation as in [1] (This is used only if a single PHY provider
>>>>>>>> implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO
>>>>>>>> to give the PHY drivers an option to use auto id.
>>>>>>>>
>>>>>>>> [1] ->
>>>>>>>> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
>>>>>>>
>>>>>>> No, who cares about the id?  No one outside of the phy core ever should,
>>>>>>> because you pass back the only pointer that they really do care about,
>>>>>>> if they need to do anything with the device.  Use that, and then you can
>>>>>>
>>>>>> hmm.. ok.
>>>>>>
>>>>>>> rip out all of the "search for a phy by a string" logic, as that's not
>>>>>>
>>>>>> Actually this is needed for non-dt boot case. In the case of dt boot, we use a
>>>>>> phandle by which the controller can get a reference to the phy. But in the case
>>>>>> of non-dt boot, the controller can get a reference to the phy only by label.
>>>>>
>>>>> I don't understand.  They registered the phy, and got back a pointer to
>>>>> it.  Why can't they save it in their local structure to use it again
>>>>> later if needed?  They should never have to "ask" for the device, as the
>>>>
>>>> One is a *PHY provider* driver which is a driver for some PHY device. This will
>>>> use phy_create to create the phy.
>>>> The other is a *PHY consumer* driver which might be any controller driver (can
>>>> be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference to the
>>>> phy (by *phandle* in the case of dt boot and *label* in the case of non-dt boot).
>>>>> device id might be unknown if there are multiple devices in the system.
>>>>
>>>> I agree with you on the device id part. That need not be known to the PHY driver.
>>>
>>> How does a consumer know which "label" to use in a non-dt system if
>>> there are multiple PHYs in the system?
>>
>> That should be passed using platform data.
>
> I don't think that's right. That's just like passing clock names in
> platform data, which I believe is frowned upon.
>
> Instead, why not take the approach that e.g. regulators have taken? Each
> driver defines the names of the objects that it requires. There is a
> table (registered by a board file) that has lookup key (device name,

We were using a similar approach with USB PHY layer but things started 
breaking after the device names are created using PLATFORM_DEVID_AUTO. 
Now theres no way to reliably know the device names in advance.
Btw I had such device name binding in my v3 of this patch series [1] and 
had some discussion with Grant during that time [2].

[1] -> 
http://archive.arm.linux.org.uk/lurker/message/20130320.091200.721a6fb5.hu.html
[2] -> https://lkml.org/lkml/2013/4/22/26

Thanks
Kishon


From kishon at ti.com  Fri Jul 19 23:19:32 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Sat, 20 Jul 2013 08:49:32 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130719235055.GB11498@kroah.com>
References: <1374129984-765-1-git-send-email-kishon@ti.com>
 <1374129984-765-2-git-send-email-kishon@ti.com>
 <20130718072004.GA16720@kroah.com> <51E7AE88.3050007@ti.com>
 <20130718154954.GA31961@kroah.com> <51E8D086.809@ti.com>
 <20130719054311.GA14638@kroah.com> <51E8D4E0.8060200@ti.com>
 <20130719062941.GA23611@kroah.com> <51E8DE51.1060404@ti.com>
 <20130719235055.GB11498@kroah.com>
Message-ID: <51EA01C4.2010006@ti.com>

Hi,

On Saturday 20 July 2013 05:20 AM, Greg KH wrote:
> On Fri, Jul 19, 2013 at 12:06:01PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Friday 19 July 2013 11:59 AM, Greg KH wrote:
>>> On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote:
>>>> Hi,
>>>>
>>>> On Friday 19 July 2013 11:13 AM, Greg KH wrote:
>>>>> On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote:
>>>>>>>>>> +	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
>>>>>>>>>
>>>>>>>>> Your naming is odd, no "phy" anywhere in it?  You rely on the sender to
>>>>>>>>> never send a duplicate name.id pair?  Why not create your own ids based
>>>>>>>>> on the number of phys in the system, like almost all other classes and
>>>>>>>>> subsystems do?
>>>>>>>>
>>>>>>>> hmm.. some PHY drivers use the id they provide to perform some of their
>>>>>>>> internal operation as in [1] (This is used only if a single PHY provider
>>>>>>>> implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO
>>>>>>>> to give the PHY drivers an option to use auto id.
>>>>>>>>
>>>>>>>> [1] ->
>>>>>>>> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
>>>>>>>
>>>>>>> No, who cares about the id?  No one outside of the phy core ever should,
>>>>>>> because you pass back the only pointer that they really do care about,
>>>>>>> if they need to do anything with the device.  Use that, and then you can
>>>>>>
>>>>>> hmm.. ok.
>>>>>>
>>>>>>> rip out all of the "search for a phy by a string" logic, as that's not
>>>>>>
>>>>>> Actually this is needed for non-dt boot case. In the case of dt boot, we use a
>>>>>> phandle by which the controller can get a reference to the phy. But in the case
>>>>>> of non-dt boot, the controller can get a reference to the phy only by label.
>>>>>
>>>>> I don't understand.  They registered the phy, and got back a pointer to
>>>>> it.  Why can't they save it in their local structure to use it again
>>>>> later if needed?  They should never have to "ask" for the device, as the
>>>>
>>>> One is a *PHY provider* driver which is a driver for some PHY device. This will
>>>> use phy_create to create the phy.
>>>> The other is a *PHY consumer* driver which might be any controller driver (can
>>>> be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference to the
>>>> phy (by *phandle* in the case of dt boot and *label* in the case of non-dt boot).
>>>>> device id might be unknown if there are multiple devices in the system.
>>>>
>>>> I agree with you on the device id part. That need not be known to the PHY driver.
>>>
>>> How does a consumer know which "label" to use in a non-dt system if
>>> there are multiple PHYs in the system?
>>
>> That should be passed using platform data.
>
> Ick, don't pass strings around, pass pointers.  If you have platform
> data you can get to, then put the pointer there, don't use a "name".

I don't think I understood you here :-s We wont have phy pointer when we 
create the device for the controller no?(it'll be done in board file). 
Probably I'm missing something.

Thanks
Kishon


From jld at mozilla.com  Fri Jul 19 23:43:21 2013
From: jld at mozilla.com (Jed Davis)
Date: Fri, 19 Jul 2013 20:43:21 -0700
Subject: [PATCH] ARM: perf: Implement perf_arch_fetch_caller_regs
In-Reply-To: <20130715135342.GF10000@mudshark.cambridge.arm.com>
References: <1373685434-1581-1-git-send-email-jld@mozilla.com>
 <20130715135342.GF10000@mudshark.cambridge.arm.com>
Message-ID: <20130720034321.GB9433@mozilla.com>

On Mon, Jul 15, 2013 at 02:53:42PM +0100, Will Deacon wrote:
> On Sat, Jul 13, 2013 at 04:17:14AM +0100, Jed Davis wrote:
[...]
> > +#ifdef CONFIG_THUMB2_KERNEL
> > +#define perf_arch_fetch_caller_regs(regs, ip)				\
> > +	do {								\
> > +		__u32 _cpsr, _pc;					\
> > +		__asm__ __volatile__("str r7, [%[_regs], #(7 * 4)]\n\t" \
> > +				     "str r13, [%[_regs], #(13 * 4)]\n\t" \
> > +				     "str r14, [%[_regs], #(14 * 4)]\n\t" \
> 
> Is this safe? How can we be sure that the registers haven't been clobbered
> by the callee before this macro is expanded? For example, you can end up
> with the following code:

They might be clobbered, but if they are, then...

> 00000058 <perf_ftrace_function_call>:
>   58:   e92d 43f0       stmdb   sp!, {r4, r5, r6, r7, r8, r9, lr}
>   5c:   b09b            sub     sp, #108        ; 0x6c
>   5e:   ac08            add     r4, sp, #32
>   60:   4681            mov     r9, r0
>   62:   4688            mov     r8, r1
>   64:   4620            mov     r0, r4
>   66:   2148            movs    r1, #72 ; 0x48
>   68:   f7ff fffe       bl      0 <__memzero>
>   6c:   61e7            str     r7, [r4, #28]
>   6e:   f8c4 d034       str.w   sp, [r4, #52]   ; 0x34
>   72:   f8c4 e038       str.w   lr, [r4, #56]   ; 0x38
> 
> but the call to __memzero will have corrupted the lr.

...the function's unwinding entry will restore them from the stack, and
can't assume anything about their values before then.  It's the same
problem as if the code was interrupted by a profiler timer at that point
and we tried unwinding from the trap state.

Hopefully.  It's hard to be as rigorous as I'd like about this, because
the Exception Handling ABI was meant for exception handling, so as
specified it only needs to work at points where C++ exceptions can be
thrown, as I understand it.  Fortunately GCC isn't limited to that, but
there are more issues, because -fasynchronous-unwind-tables doesn't
actually make things work from *any* instruction as documented (which is
not entirely bad, because working correctly would significantly increase
the size of .extab/.exidx).

All that said, the unwinding program for a function should work at any
point after the prologue and before the epilogue.

> > +				     "mov %[_pc],  r15\n\t"		\
> > +				     "mrs %[_cpsr], cpsr\n\t"		\
> > +				     : [_cpsr] "=r" (_cpsr),		\
> > +				       [_pc] "=r" (_pc)			\
> > +				     : [_regs] "r" (&(regs)->uregs)	\
> 
> It would be cleaner to pass a separate argument for each register, using the
> ARM_rN macros rather than calculating the offset by hand.

I'll do that.  If there were more arguments there might be a problem
at -O0, because the naive translation can run out of registers in
some cases, but that shouldn't be a problem here.  (Nor if someone
later extends this to all the core registers, because {r0-r13} can and
presumably should use a store-multiple.)

Thanks for the quick review, and sorry for the delay in responding.

--Jed



From shc_work at mail.ru  Fri Jul 19 23:44:41 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 20 Jul 2013 07:44:41 +0400
Subject: [PATCH 06/10] ARM: clps711x: Add CLPS711X clocksource driver
In-Reply-To: <51E94F7E.4030404@linaro.org>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
 <1374172501-26796-7-git-send-email-shc_work@mail.ru>
 <51E94F7E.4030404@linaro.org>
Message-ID: <20130720074441.9882b71183e5eadd535da6c1@mail.ru>

On Fri, 19 Jul 2013 16:38:54 +0200
Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
> (Added Thomas and John in Cc in case they want to review the patch).
> 
> On 07/18/2013 08:34 PM, Alexander Shiyan wrote:
> > This adds the clocksource driver for Cirrus Logic CLPS711X series SoCs.
> > Designed primarily for migration CLPS711X subarch for multiplatform & DT,
> > for this as the "OF" and "not-OF" calls implemented.
> 
> When a new driver is submitted, I ask for a more detailed changelog
> about the driver itself: how it works, any specificities, etc ...
> 
> That will help people to understand the code better at least for the review.

Basically, this series is a port of the CLPS711X subsystems in places specially
designed for this purpose. Additionally added to the standard description of the
subsystem for use with DT.
As for specs, I'm a little confused by this question. In this case, I'm doing
is not anything new for this CPU. The CPU has two timers and I use both to
provide the correct time sources.

> > Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> > ---
> >  arch/arm/Kconfig                      |   2 -
> >  drivers/clocksource/Kconfig           |   6 ++
> >  drivers/clocksource/Makefile          |   1 +
> >  drivers/clocksource/clps711x-clksrc.c | 151 ++++++++++++++++++++++++++++++++++
> >  4 files changed, 158 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/clocksource/clps711x-clksrc.c
[...]
> > +#define CLPS711X_SYSCON1	(0x0100)
> > +#define CLPS711X_TC1D		(0x0300)
> > +#define CLPS711X_TC2D		(0x0340)
> 
> Alignment.

Alignment? Do not see any problems.
Wrong alignment in this case is the result of quote.

> > +static struct {
> > +	void __iomem	*tc1d;
> > +	int		irq;
> > +} *clps711x_clksrc;
> 
> You don't need to define this structure, the struct clock_event_device
> already contains a field with irq.

Thank you, I will know.

[...]
> > +static void clps711x_clockevent_set_mode(enum clock_event_mode mode,
> > +					 struct clock_event_device *evt)
> > +{
> > +	disable_irq(clps711x_clksrc->irq);
> 
> Do you really need to disable the interrupt to re-enable it right after ?

That was the original implementation. Perhaps the best solution is to disable
interrupt by CLOCK_EVT_MODE_SHUTDOWN and enable it back by CLOCK_EVT_MODE_RESUME.

> > +> +	switch (mode) {
> > +	case CLOCK_EVT_MODE_PERIODIC:
> > +		enable_irq(clps711x_clksrc->irq);
> > +		break;
> > +	case CLOCK_EVT_MODE_ONESHOT:
> > +		/* Not supported */
> > +	case CLOCK_EVT_MODE_SHUTDOWN:
> > +	case CLOCK_EVT_MODE_UNUSED:
> > +	case CLOCK_EVT_MODE_RESUME:
> > +		/* Left event sources disabled, no more interrupts appear */
> > +		break;
> > +	}
> > +}
> 
> I am not expert in interrupts, but it is possible this interrupt could
> be shared ?

Timer interrupt? No.

> There isn't a register to enable/disable the timer ?

Unfortunately, no. The timer is running always, except STDBY CPU state,
so we can control it only by enable/disable interrupt.

[...]
> > +static struct irqaction clps711x_timer_irq = {
> > +	.name		= "clps711x-timer",
> > +	.flags		= IRQF_TIMER | IRQF_IRQPOLL,
> 
> Why do you need IRQF_IRQPOOL ?

linux/interrupt.h:
 * IRQF_IRQPOLL - Interrupt is used for polling (only the interrupt that is
 *                registered first in an shared interrupt is considered for
 *                performance reasons)

I do not see need this flag, but in fact, this flag is traditionally used
in almost all subsystems of this type.

[...]
> > +	tmp = readl(syscon1);
> > +	/* TC1 in free running mode */
> > +	tmp &= ~SYSCON1_TC1M;
> > +	/* TC2 in prescale mode */
> > +	tmp |= SYSCON1_TC2M;
> > +	writel(tmp, syscon1);
> 
> Could you encapsulate these calls inside a static inline function with a
> more detailed comment please ?

Why static inline?
There is a comment line for each bit, You think this is not enough?

[...]
> > +void __init clps711x_clksrc_init(phys_addr_t phys_base, int irq)
> 
> Is this function called somewhere ? I don't see the function definition ?

It is defined in the patch [9/10] for non-DT case.

[...]

Thanks.

-- 
Alexander Shiyan <shc_work at mail.ru>


From jld at mozilla.com  Sat Jul 20 00:46:55 2013
From: jld at mozilla.com (Jed Davis)
Date: Fri, 19 Jul 2013 21:46:55 -0700
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y
In-Reply-To: <20130715135420.GG10000@mudshark.cambridge.arm.com>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
 <20130715135420.GG10000@mudshark.cambridge.arm.com>
Message-ID: <20130720044655.GC9433@mozilla.com>

On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
[...]
> > Effects of this are probably limited to failure of EHABI unwinding when
> > starting from a function that uses r7 to restore its stack pointer, but
> > the possibility for further breakage (which would be invisible on
> > non-Thumb kernels) is worrying.
[...]
> I'm struggling to understand exactly the problem that this patch is trying
> to address. If it's just a code consistency issue, I don't think it's worth
> it (I actually find it less confusing the way we currently have things) but
> if there is a real bug, perhaps you could provide a testcase?

There is a real bug here, but my commit message wasn't very clear.  This
was breaking PERF_COUNT_SW_CONTEXT_SWITCHES with CONFIG_THUMB2_KERNEL=y
(with my other recently posted patch applied), because kernel/sched.c is
built with -fno-omit-frame-pointer (which is wrong, but that's a problem
for another patch) and so __schedule's EHABI entry uses 0x97 (mov sp, r7),
and somewhere along the line the unwinder gets the r11 value instead.
This would also apply to any function with a variable-length array, but
__schedule happens to have the perf hook I was trying to use.

I should add that this bug doesn't affect me directly at the moment,
because we're not currently using CONFIG_THUMB2_KERNEL on Firefox OS,
because our kernels are assorted older versions with hardware vendors'
changes and there are some issues with it.  But I felt it was worth
tracking this down before trying to send changes upstream.

The "right" thing to do here might be to just include all the registers,
or at least {r4-pc}, in struct stackframe.  The parts that aren't {fp,
sp, lr, pc} could be ifdef'ed if we're concerned enough about the
overhead in kernels using APCS frame pointer unwinding.

I agree that a test case would be good -- I'm more than a little worried
of regressions without one -- but I could use some advice on how best to
do that.

--Jed



From shc_work at mail.ru  Sat Jul 20 01:46:33 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 20 Jul 2013 09:46:33 +0400
Subject: [PATCH RESEND] media: coda: Fix DT-driver data pointer for i.MX27
In-Reply-To: <1371799814.4320.3.camel@pizza.hi.pengutronix.de>
References: <1371746796-16123-1-git-send-email-shc_work@mail.ru>
 <1371799814.4320.3.camel@pizza.hi.pengutronix.de>
Message-ID: <20130720094633.d18f5915dab9587598d8782a@mail.ru>

On Fri, 21 Jun 2013 09:30:14 +0200
Philipp Zabel <p.zabel at pengutronix.de> wrote:

> Am Donnerstag, den 20.06.2013, 20:46 +0400 schrieb Alexander Shiyan:
> > Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> > ---
> >  drivers/media/platform/coda.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
> > index 48b8d7a..1c77781 100644
> > --- a/drivers/media/platform/coda.c
> > +++ b/drivers/media/platform/coda.c
> > @@ -1924,7 +1924,7 @@ MODULE_DEVICE_TABLE(platform, coda_platform_ids);
> >  
> >  #ifdef CONFIG_OF
> >  static const struct of_device_id coda_dt_ids[] = {
> > -	{ .compatible = "fsl,imx27-vpu", .data = &coda_platform_ids[CODA_IMX27] },
> > +	{ .compatible = "fsl,imx27-vpu", .data = &coda_devdata[CODA_IMX27] },
> >  	{ .compatible = "fsl,imx53-vpu", .data = &coda_devdata[CODA_IMX53] },
> >  	{ /* sentinel */ }
> >  };
> 
> Acked-by: Philipp Zabel <p.zabel at pengutronix.de>

Ping.

-- 
Alexander Shiyan <shc_work at mail.ru>


From oleksandr.kozaruk at ti.com  Sat Jul 20 02:14:34 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Sat, 20 Jul 2013 01:14:34 -0500
Subject: [PATCH v6 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <51E98310.7020103@cogentembedded.com>
References: <1374226039-16943-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1374226039-16943-2-git-send-email-oleksandr.kozaruk@ti.com>
 <51E94F97.40002@cogentembedded.com> <51E95DEB.7010702@ti.com>
 <51E98310.7020103@cogentembedded.com>
Message-ID: <CAPb7_msk+dq9OK=UVU8A58k7iiPJwTYaViJjQ=qQHOCBN9u-7g@mail.gmail.com>

Hi Sergei,

On Fri, Jul 19, 2013 at 1:18 PM, Sergei Shtylyov
<sergei.shtylyov at cogentembedded.com> wrote:
> Hello.
>
>
> On 07/19/2013 07:40 PM, Grygorii Strashko wrote:
>
>>>> GPADC is the general purpose ADC present on twl6030.
>>>> The dt data is interrupt used to trigger end of ADC
>>>> conversion.
>
>
>>>> Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
>>>> ---
>>>>   arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
>>>>   1 file changed, 6 insertions(+)
>
>
>>>> diff --git a/arch/arm/boot/dts/twl6030.dtsi
>>>> b/arch/arm/boot/dts/twl6030.dtsi
>>>> index 2e3bd31..d7d4c28 100644
>>>> --- a/arch/arm/boot/dts/twl6030.dtsi
>>>> +++ b/arch/arm/boot/dts/twl6030.dtsi
>>>> @@ -103,4 +103,10 @@
>>>>           compatible = "ti,twl6030-pwmled";
>>>>           #pwm-cells = <2>;
>>>>       };
>>>> +
>>>> +    adc: gpadc {
>
>
>>>     Read my lips: the node should be called just "adc", not "gpadc".
>>
>>        ^^^^^^^^^^^^ Are you sure?
>
>
>    I didn't know how to express my disappointment from Oleksandr's inability
> to understand what I wanted to convey to him from 2 attempts... first,
How would you comment the following code, v3.10-rc7:

arch/arm/boot/dts/dbx5x0.dtsi, line 375
375                                  ab8500-gpadc {
376                                          compatible =
"stericsson,ab8500-gpadc";
377                                          interrupts = <32
IRQ_TYPE_LEVEL_HIGH
arch/arm/boot/dts/dbx5x0.dtsi:                          ab8500-gpadc {
arch/arm/boot/dts/dbx5x0.dtsi:
compatible = "stericsson,ab8500-gpadc";
arch/arm/boot/dts/dbx5x0.dtsi:
vddadc-supply = <&ab8500_ldo_tvout_reg>;


arch/arm/boot/dts/sama5d3.dtsi:                 tsadcc: tsadcc at f8018000 {
arch/arm/boot/dts/sama5d3.dtsi:                         compatible =
"atmel,at91sam9x5-tsadcc";
arch/arm/boot/dts/sama5d3.dtsi:
atmel,tsadcc_clock = <300000>;

arch/arm/boot/dts/am33xx.dtsi:          tscadc: tscadc at 44e0d000 {
arch/arm/boot/dts/am33xx.dtsi:                  compatible = "ti,am3359-tscadc";
arch/arm/boot/dts/am33xx.dtsi:                  ti,hwmods = "adc_tsc";
arch/arm/boot/dts/am33xx.dtsi:                  am335x_adc: adc {
arch/arm/boot/dts/am33xx.dtsi:                          compatible =
"ti,am3359-adc";

Regards,
Sasha.

> changed the label instead of the node name, then he only dropped "twl6030_"
> prefix from the name. I should probably have been even more specific before.
>
>
>> Why? The name was selected according to the documentation on device
>> "General
>> purpose analog-to-digital converter (GPADC)".
>
>
>    Sigh, we simply don't care whether this ADC is general-purpose or not.
> The main thing it is ADC.
>
>
>> PS. Following your logic - "GPIO" need to renamed to "IO" everywhere ;P
>
>
>    GPIO is well known and established abbreviation, contrasted to GPADC.
> Moreover, ePAPR spec lists "gpio" as a generic node name.
>
>
> WBR, Sergei
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From prabhakar.csengg at gmail.com  Sat Jul 20 02:21:05 2013
From: prabhakar.csengg at gmail.com (Lad, Prabhakar)
Date: Sat, 20 Jul 2013 11:51:05 +0530
Subject: [PATCH v3 1/2] media: i2c: adv7343: make the platform data members as
 array
In-Reply-To: <1374301266-26726-1-git-send-email-prabhakar.csengg@gmail.com>
References: <1374301266-26726-1-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <1374301266-26726-2-git-send-email-prabhakar.csengg@gmail.com>

From: "Lad, Prabhakar" <prabhakar.csengg at gmail.com>

This patch makes the platform data members as array wherever
possible, so as this makes easier while collecting the data
in DT case and read the entire array at once.

This patch also makes appropriate changes to board-da850-evm.c

Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
Cc: Sekhar Nori <nsekhar at ti.com>
Cc: linux-arm-kernel at lists.infradead.org
---
 arch/arm/mach-davinci/board-da850-evm.c |    6 ++----
 drivers/media/i2c/adv7343.c             |   28 ++++++++++++++--------------
 include/media/adv7343.h                 |   20 ++++----------------
 3 files changed, 20 insertions(+), 34 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index e6f5b5d..ab6bdbe 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -733,12 +733,10 @@ static struct tvp514x_platform_data tvp5146_pdata = {
 
 static struct adv7343_platform_data adv7343_pdata = {
 	.mode_config = {
-		.dac_3 = 1,
-		.dac_2 = 1,
-		.dac_1 = 1,
+		.dac = { 1, 1, 1 },
 	},
 	.sd_config = {
-		.sd_dac_out1 = 1,
+		.sd_dac_out = { 1 },
 	},
 };
 
diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
index 8080c2c..f0238fb 100644
--- a/drivers/media/i2c/adv7343.c
+++ b/drivers/media/i2c/adv7343.c
@@ -227,12 +227,12 @@ static int adv7343_setoutput(struct v4l2_subdev *sd, u32 output_type)
 	else
 		val = state->pdata->mode_config.sleep_mode << 0 |
 		      state->pdata->mode_config.pll_control << 1 |
-		      state->pdata->mode_config.dac_3 << 2 |
-		      state->pdata->mode_config.dac_2 << 3 |
-		      state->pdata->mode_config.dac_1 << 4 |
-		      state->pdata->mode_config.dac_6 << 5 |
-		      state->pdata->mode_config.dac_5 << 6 |
-		      state->pdata->mode_config.dac_4 << 7;
+		      state->pdata->mode_config.dac[2] << 2 |
+		      state->pdata->mode_config.dac[1] << 3 |
+		      state->pdata->mode_config.dac[0] << 4 |
+		      state->pdata->mode_config.dac[5] << 5 |
+		      state->pdata->mode_config.dac[4] << 6 |
+		      state->pdata->mode_config.dac[3] << 7;
 
 	err = adv7343_write(sd, ADV7343_POWER_MODE_REG, val);
 	if (err < 0)
@@ -251,15 +251,15 @@ static int adv7343_setoutput(struct v4l2_subdev *sd, u32 output_type)
 	/* configure SD DAC Output 2 and SD DAC Output 1 bit to zero */
 	val = state->reg82 & (SD_DAC_1_DI & SD_DAC_2_DI);
 
-	if (state->pdata && state->pdata->sd_config.sd_dac_out1)
-		val = val | (state->pdata->sd_config.sd_dac_out1 << 1);
-	else if (state->pdata && !state->pdata->sd_config.sd_dac_out1)
-		val = val & ~(state->pdata->sd_config.sd_dac_out1 << 1);
+	if (state->pdata && state->pdata->sd_config.sd_dac_out[0])
+		val = val | (state->pdata->sd_config.sd_dac_out[0] << 1);
+	else if (state->pdata && !state->pdata->sd_config.sd_dac_out[0])
+		val = val & ~(state->pdata->sd_config.sd_dac_out[0] << 1);
 
-	if (state->pdata && state->pdata->sd_config.sd_dac_out2)
-		val = val | (state->pdata->sd_config.sd_dac_out2 << 2);
-	else if (state->pdata && !state->pdata->sd_config.sd_dac_out2)
-		val = val & ~(state->pdata->sd_config.sd_dac_out2 << 2);
+	if (state->pdata && state->pdata->sd_config.sd_dac_out[1])
+		val = val | (state->pdata->sd_config.sd_dac_out[1] << 2);
+	else if (state->pdata && !state->pdata->sd_config.sd_dac_out[1])
+		val = val & ~(state->pdata->sd_config.sd_dac_out[1] << 2);
 
 	err = adv7343_write(sd, ADV7343_SD_MODE_REG2, val);
 	if (err < 0)
diff --git a/include/media/adv7343.h b/include/media/adv7343.h
index 944757b..e4142b1 100644
--- a/include/media/adv7343.h
+++ b/include/media/adv7343.h
@@ -28,12 +28,7 @@
  * @pll_control: PLL and oversampling control. This control allows internal
  *		 PLL 1 circuit to be powered down and the oversampling to be
  *		 switched off.
- * @dac_1: power on/off DAC 1.
- * @dac_2: power on/off DAC 2.
- * @dac_3: power on/off DAC 3.
- * @dac_4: power on/off DAC 4.
- * @dac_5: power on/off DAC 5.
- * @dac_6: power on/off DAC 6.
+ * @dac: array to configure power on/off DAC's 1..6
  *
  * Power mode register (Register 0x0), for more info refer REGISTER MAP ACCESS
  * section of datasheet[1], table 17 page no 30.
@@ -43,23 +38,16 @@
 struct adv7343_power_mode {
 	bool sleep_mode;
 	bool pll_control;
-	bool dac_1;
-	bool dac_2;
-	bool dac_3;
-	bool dac_4;
-	bool dac_5;
-	bool dac_6;
+	u32 dac[6];
 };
 
 /**
  * struct adv7343_sd_config - SD Only Output Configuration.
- * @sd_dac_out1: Configure SD DAC Output 1.
- * @sd_dac_out2: Configure SD DAC Output 2.
+ * @sd_dac_out: array configuring SD DAC Outputs 1 and 2
  */
 struct adv7343_sd_config {
 	/* SD only Output Configuration */
-	bool sd_dac_out1;
-	bool sd_dac_out2;
+	u32 sd_dac_out[2];
 };
 
 /**
-- 
1.7.9.5



From viresh.kumar at linaro.org  Sat Jul 20 03:02:15 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Sat, 20 Jul 2013 12:32:15 +0530
Subject: [PATCH 20/22] ARM: ux500: Remove '0x's from Spear 300 DTS file
In-Reply-To: <1374242333-6852-20-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
 <1374242333-6852-20-git-send-email-lee.jones@linaro.org>
Message-ID: <CAOh2x==EBzy6MMy0Jv1=VSAD7Kdw7=Jag8g4oz-kfRH0XafGaw@mail.gmail.com>

On Fri, Jul 19, 2013 at 7:28 PM, Lee Jones <lee.jones at linaro.org> wrote:
> Cc: Viresh Kumar <viresh.kumar at linaro.org>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  arch/arm/boot/dts/spear300.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/spear300.dtsi b/arch/arm/boot/dts/spear300.dtsi
> index f79b3df..8970a4a 100644
> --- a/arch/arm/boot/dts/spear300.dtsi
> +++ b/arch/arm/boot/dts/spear300.dtsi
> @@ -52,7 +52,7 @@
>                         status = "disabled";
>                 };
>
> -               shirq: interrupt-controller at 0x50000000 {
> +               shirq: interrupt-controller at 50000000 {
>                         compatible = "st,spear300-shirq";
>                         reg = <0x50000000 0x1000>;
>                         interrupts = <28>;

Should Ux500 come in subject line? And please write Spear as
SPEAr.

Otherwise all three patches look fine.

Ackedy-by: Viresh Kumar <viresh.kumar at linaro.org>


From joro at 8bytes.org  Sat Jul 20 03:15:27 2013
From: joro at 8bytes.org (Joerg Roedel)
Date: Sat, 20 Jul 2013 09:15:27 +0200
Subject: [PATCH] iommu: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
In-Reply-To: <51E81F23.40807@wwwdotorg.org>
References: <1374013222-4856-1-git-send-email-swarren@wwwdotorg.org>
 <51E81F23.40807@wwwdotorg.org>
Message-ID: <20130720071527.GI28811@8bytes.org>

On Thu, Jul 18, 2013 at 11:00:19AM -0600, Stephen Warren wrote:
> I'd like to defer actually applying this patch. There is some discussion
> (in the thread for the equivalent ASoC patches) re: the best way to
> handle the ARCH_TEGRA_*_SOC Kconfig options which might affect this
> patch. Any review comment is still appreciated.

Okay, not much to review here. Just let me know if it is still required.


	Joerg




From shc_work at mail.ru  Sat Jul 20 03:17:58 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 20 Jul 2013 11:17:58 +0400
Subject: [PATCH 5/6] ARM: dts: i.MX27: Remove clock name from CPU node
In-Reply-To: <1374304679-27338-1-git-send-email-shc_work@mail.ru>
References: <1374304679-27338-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374304679-27338-5-git-send-email-shc_work@mail.ru>

Clock name is not needed for "cpufreq-cpu0".

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index c06df85..76cd89f 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -63,7 +63,6 @@
 			>;
 			clock-latency = <62500>;
 			clocks = <&clks 18>;
-			clock-names = "cpu";
 			voltage-tolerance = <5>;
 		};
 	};
-- 
1.8.1.5



From shc_work at mail.ru  Sat Jul 20 03:17:54 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 20 Jul 2013 11:17:54 +0400
Subject: [PATCH 1/6] ARM: dts: i.MX27: Using "wdog_ipg_gate" clock source for
 watchdog
Message-ID: <1374304679-27338-1-git-send-email-shc_work@mail.ru>

Patch replaces "dummy" clock source for watchdog with "wdog_ipg_gate".

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index 56b8c97..e9d60ab 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -96,7 +96,7 @@
 				compatible = "fsl,imx27-wdt", "fsl,imx21-wdt";
 				reg = <0x10002000 0x1000>;
 				interrupts = <27>;
-				clocks = <&clks 0>;
+				clocks = <&clks 74>;
 			};
 
 			gpt1: timer at 10003000 {
-- 
1.8.1.5



From shc_work at mail.ru  Sat Jul 20 03:17:57 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 20 Jul 2013 11:17:57 +0400
Subject: [PATCH 4/6] ARM: dts: i.MX27: Increase "clock-latency" value
In-Reply-To: <1374304679-27338-1-git-send-email-shc_work@mail.ru>
References: <1374304679-27338-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374304679-27338-4-git-send-email-shc_work@mail.ru>

i.MX27 CPU can be clocked with a 32 kHz quartz, and not just 32768 Hz,
so increase "clock-latency" value, which will ensure that we use two
clock cycles on frequency change.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index a8e0c7e..c06df85 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -61,7 +61,7 @@
 				266000 1300000
 				399000 1450000
 			>;
-			clock-latency = <61036>; /* two CLK32 periods */
+			clock-latency = <62500>;
 			clocks = <&clks 18>;
 			clock-names = "cpu";
 			voltage-tolerance = <5>;
-- 
1.8.1.5



From shc_work at mail.ru  Sat Jul 20 03:17:55 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 20 Jul 2013 11:17:55 +0400
Subject: [PATCH 2/6] ARM: dts: i.MX27: Remove optional "ptp" clock source for
 FEC
In-Reply-To: <1374304679-27338-1-git-send-email-shc_work@mail.ru>
References: <1374304679-27338-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374304679-27338-2-git-send-email-shc_work@mail.ru>

Patch removes optional "ptp" clock source for FEC. This clock is
missing in i.MX27.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index e9d60ab..7cf954b 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -428,8 +428,8 @@
 				compatible = "fsl,imx27-fec";
 				reg = <0x1002b000 0x4000>;
 				interrupts = <50>;
-				clocks = <&clks 48>, <&clks 67>, <&clks 0>;
-				clock-names = "ipg", "ahb", "ptp";
+				clocks = <&clks 48>, <&clks 67>;
+				clock-names = "ipg", "ahb";
 				status = "disabled";
 			};
 		};
-- 
1.8.1.5



From shc_work at mail.ru  Sat Jul 20 03:17:56 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 20 Jul 2013 11:17:56 +0400
Subject: [PATCH 3/6] ARM: dts: i.MX27: Add label to CPU node
In-Reply-To: <1374304679-27338-1-git-send-email-shc_work@mail.ru>
References: <1374304679-27338-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374304679-27338-3-git-send-email-shc_work@mail.ru>

Add a label to i.MX27 CPU node. This change allows the reuse this node
in the upper levels of the DTS.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index 7cf954b..a8e0c7e 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -53,7 +53,7 @@
 		#size-cells = <0>;
 		#address-cells = <1>;
 
-		cpu {
+		cpu: cpu at 0 {
 			device_type = "cpu";
 			compatible = "arm,arm926ej-s";
 			operating-points = <
-- 
1.8.1.5



From shc_work at mail.ru  Sat Jul 20 03:17:59 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 20 Jul 2013 11:17:59 +0400
Subject: [PATCH 6/6] ARM: dts: imx27-phytec-phycore-som: Fix regulator settings
In-Reply-To: <1374304679-27338-1-git-send-email-shc_work@mail.ru>
References: <1374304679-27338-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374304679-27338-6-git-send-email-shc_work@mail.ru>

Outputs regulator SW1A and SW1A, SW2A and SW2B are connected together,
so it determined as "joined" operation for MC13783. Separate work of
these outputs in this case would be wrong, so we define only one of
the outputs.
Additionally, define the full range of voltages for the CPU (1.2v - 1.52v).

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx27-phytec-phycore-som.dts | 22 +++++-----------------
 1 file changed, 5 insertions(+), 17 deletions(-)

diff --git a/arch/arm/boot/dts/imx27-phytec-phycore-som.dts b/arch/arm/boot/dts/imx27-phytec-phycore-som.dts
index 22d0d27..aa70ad7 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore-som.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycore-som.dts
@@ -38,28 +38,16 @@
 		fsl,mc13xxx-uses-rtc;
 
 		regulators {
-			sw1a_reg: sw1a {
+			/* SW1A and SW1B joined operation */
+			sw1_reg: sw1a {
 				regulator-min-microvolt = <1200000>;
-				regulator-max-microvolt = <1200000>;
+				regulator-max-microvolt = <1520000>;
 				regulator-always-on;
 				regulator-boot-on;
 			};
 
-			sw1b_reg: sw1b {
-				regulator-min-microvolt = <1200000>;
-				regulator-max-microvolt = <1200000>;
-				regulator-always-on;
-				regulator-boot-on;
-			};
-
-			sw2a_reg: sw2a {
-				regulator-min-microvolt = <1800000>;
-				regulator-max-microvolt = <1800000>;
-				regulator-always-on;
-				regulator-boot-on;
-			};
-
-			sw2b_reg: sw2b {
+			/* SW2A and SW2B joined operation */
+			sw2_reg: sw2a {
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;
 				regulator-always-on;
-- 
1.8.1.5



From vaibhav.bedia at ti.com  Sat Jul 20 03:27:25 2013
From: vaibhav.bedia at ti.com (Bedia, Vaibhav)
Date: Sat, 20 Jul 2013 07:27:25 +0000
Subject: [PATCH] irqchip: gic: Don't complain in gic_get_cpumask() if UP
 system
In-Reply-To: <1373067573-29946-1-git-send-email-sboyd@codeaurora.org>
References: <1373067573-29946-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <B5906170F1614E41A8A28DE3B8D121433EEB180B@DBDE04.ent.ti.com>

Hi,

On Sat, Jul 06, 2013 at 05:09:33, Stephen Boyd wrote:
> In a uniprocessor implementation the interrupt processor targets
> registers are read-as-zero/write-ignored (RAZ/WI). Unfortunately
> gic_get_cpumask() will print a critical message saying
> 
>  GIC CPU mask not found - kernel will fail to boot.
> 
> if these registers all read as zero, but there won't actually be
> a problem on uniprocessor systems and the kernel will boot just
> fine. Skip this check if we're running a UP kernel or if we
> detect that the hardware only supports a single processor.
> 
> Cc: Nicolas Pitre <nico at linaro.org>
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
> 
> Maybe we should just drop the check entirely? It looks like it may
> just be debug code that won't ever trigger in practice, even on the
> 11MPCore that caused this code to be introduced.
> 

Apologies if I missed v2 of this patch if there was one. I could not
locate it in my inbox or the list archives.

We have a yet to be released single-core A9 MPCore system (AM437x) which
needs to co-exist in omap2plus_defconfig wherein NR_CPUS is set to 2. 
This currently leads to the "GIC CPU mask not found..." being printed
twice during bootup. If the check is really some debug code, can it be
completely dropped?

Regards,
Vaibhav B.



From coelho at ti.com  Sat Jul 20 03:48:08 2013
From: coelho at ti.com (Luciano Coelho)
Date: Sat, 20 Jul 2013 10:48:08 +0300
Subject: [PATCH] Documentation: dt: bindings: TI WiLink modules
In-Reply-To: <1698879.DLaB5pbe5M@avalon>
References: <1372149330-24335-1-git-send-email-coelho@ti.com>
 <1372425670.21065.61.camel@cumari.coelho.fi>
 <1372682370.21065.68.camel@cumari.coelho.fi> <1698879.DLaB5pbe5M@avalon>
Message-ID: <1374306488.8385.56.camel@cumari.coelho.fi>

On Thu, 2013-07-18 at 01:58 +0200, Laurent Pinchart wrote:
> Hi Luciano,

Hi Laurent,

> On Monday 01 July 2013 15:39:30 Luciano Coelho wrote:
> > The only thing I can come up with is to make a small clock driver (maybe
> > even inside the WiLink module itself) that registers a new type of
> > clock, "ti,wilink-clock" or something.  But this would really be
> > overkill, wouldn't it?
> > 
> > Any other ideas?
> 
> One possibility would be to just call clk_get_rate() on the clock from the 
> WiLink driver, which would return the fixed frequency specified in DT, and 
> configure the WiLink hardware accordingly. This might be a bit hackish though.

The problem is not get the rate itself, the problem is knowing whether
the clock is XTAL or not.  The WiLink chip uses the clock in a slightly
different way if it is XTAL, due to some stabilization time constraints.

--
Luca.



From shc_work at mail.ru  Sat Jul 20 04:29:35 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 20 Jul 2013 12:29:35 +0400
Subject: [RFC v2] ARM: i.MX pllv1: Implement set_rate
Message-ID: <1374308975-20596-1-git-send-email-shc_work@mail.ru>

This patch implements frequency change for i.MX pllv1.
Selection of the values of the registers is not optimal, since is
made by simple enumeration of all possible values.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/mach-imx/clk-imx27.c |   2 +-
 arch/arm/mach-imx/clk-pllv1.c | 118 +++++++++++++++++++++++++++++++++++-------
 arch/arm/mach-imx/mx27.h      |   7 ++-
 3 files changed, 106 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index c3cfa41..2b363d9 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -125,7 +125,7 @@ int __init mx27_clocks_init(unsigned long fref)
 	clk[vpu_sel] = imx_clk_mux("vpu_sel", CCM_CSCR, 21, 1, vpu_sel_clks, ARRAY_SIZE(vpu_sel_clks));
 	clk[vpu_div] = imx_clk_divider("vpu_div", "vpu_sel", CCM_PCDR0, 10, 6);
 	clk[usb_div] = imx_clk_divider("usb_div", "spll_gate", CCM_CSCR, 28, 3);
-	clk[cpu_sel] = imx_clk_mux("cpu_sel", CCM_CSCR, 15, 1, cpu_sel_clks, ARRAY_SIZE(cpu_sel_clks));
+	clk[cpu_sel] = imx_clk_mux_flags("cpu_sel", CCM_CSCR, 15, 1, cpu_sel_clks, ARRAY_SIZE(cpu_sel_clks), CLK_SET_RATE_PARENT);
 	clk[clko_sel] = imx_clk_mux("clko_sel", CCM_CCSR, 0, 5, clko_sel_clks, ARRAY_SIZE(clko_sel_clks));
 	if (mx27_revision() >= IMX_CHIP_REVISION_2_0)
 		clk[cpu_div] = imx_clk_divider("cpu_div", "cpu_sel", CCM_CSCR, 12, 2);
diff --git a/arch/arm/mach-imx/clk-pllv1.c b/arch/arm/mach-imx/clk-pllv1.c
index c1eaee3..722fea2 100644
--- a/arch/arm/mach-imx/clk-pllv1.c
+++ b/arch/arm/mach-imx/clk-pllv1.c
@@ -9,6 +9,8 @@
 #include "common.h"
 #include "hardware.h"
 
+#include "mx27.h"
+
 /**
  * pll v1
  *
@@ -25,17 +27,13 @@ struct clk_pllv1 {
 
 #define to_clk_pllv1(clk) (container_of(clk, struct clk_pllv1, clk))
 
-static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
-		unsigned long parent_rate)
+static unsigned long _clk_pllv1_recalc_rate(unsigned int mfi, unsigned int mfn,
+					    unsigned int mfd, unsigned int pd,
+					    unsigned long parent_rate)
 {
-	struct clk_pllv1 *pll = to_clk_pllv1(hw);
-	long long ll;
-	int mfn_abs;
-	unsigned int mfi, mfn, mfd, pd;
-	u32 reg;
 	unsigned long rate;
-
-	reg = readl(pll->base);
+	int mfn_abs = mfn;
+	long long ll;
 
 	/*
 	 * Get the resulting clock rate from a PLL register value and the input
@@ -47,15 +45,6 @@ static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
 	 *                        pd + 1
 	 */
 
-	mfi = (reg >> 10) & 0xf;
-	mfn = reg & 0x3ff;
-	mfd = (reg >> 16) & 0x3ff;
-	pd =  (reg >> 26) & 0xf;
-
-	mfi = mfi <= 5 ? 5 : mfi;
-
-	mfn_abs = mfn;
-
 	/*
 	 * On all i.MXs except i.MX1 and i.MX21 mfn is a 10bit
 	 * 2's complements number
@@ -78,8 +67,99 @@ static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
 	return ll;
 }
 
+static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
+		unsigned long parent_rate)
+{
+	struct clk_pllv1 *pll = to_clk_pllv1(hw);
+	unsigned int mfi, mfn, mfd, pd;
+	u32 reg = readl(pll->base);
+
+	/* Avoid i.MX27 TO2 SPCTL0 bug */
+	if (cpu_is_mx27() && (mx27_revision() == IMX_CHIP_REVISION_2_0))
+		writel(reg, pll->base);
+
+	mfi = (reg >> 10) & 0xf;
+	mfn = reg & 0x3ff;
+	mfd = (reg >> 16) & 0x3ff;
+	pd =  (reg >> 26) & 0xf;
+
+	mfi = mfi <= 5 ? 5 : mfi;
+
+	return _clk_pllv1_recalc_rate(mfi, mfn, mfd, pd, parent_rate);
+}
+
+static void _clk_pllv1_set_rate(unsigned long rate, unsigned long parent_rate,
+				unsigned int *reg)
+{
+	unsigned int pd, mfi, mfn, mfd, mfn_offs = 0;
+	long tmp, res, best = 0;
+
+	pd = (parent_rate * 2 * 5) / rate;
+	if (pd > 15)
+		pd = 15;
+	mfi = rate / (parent_rate * 2 * (pd + 1));
+	if (mfi < 5)
+		mfi = 5;
+	if (mfi < 15) {
+		tmp = parent_rate * 2;
+		tmp /= pd + 1;
+		tmp *= mfi;
+		if (tmp / parent_rate) {
+			mfi++;
+			/* Use negative values */
+			mfn_offs = 0x200;
+		}
+	} else if (mfi > 15)
+		mfi = 15;
+
+	for (mfd = 1; mfd < 0x400; mfd++)
+		for (mfn = 0; (mfn < mfd) && (mfn <= 0x1fe); mfn++) {
+			res = _clk_pllv1_recalc_rate(mfi, mfn_offs + mfn, mfd,
+						     pd, parent_rate);
+			if (!best || (abs(rate - res) < abs(rate - best))) {
+				*reg = mfn_offs + mfn;
+				*reg |= mfi << 10;
+				*reg |= mfd << 16;
+				*reg |= pd << 26;
+				if (res == rate)
+					return;
+				best = res;
+			}
+		}
+}
+
+static int clk_pllv1_set_rate(struct clk_hw *hw, unsigned long rate,
+			      unsigned long parent_rate)
+{
+	struct clk_pllv1 *pll = to_clk_pllv1(hw);
+	u32 reg;
+
+	_clk_pllv1_set_rate(rate, parent_rate, &reg);
+	writel(reg, pll->base);
+
+	return 0;
+}
+
+static long clk_pllv1_round_rate(struct clk_hw *hw, unsigned long rate,
+				 unsigned long *prate)
+{
+	unsigned int pd, mfi, mfn, mfd;
+	u32 reg;
+
+	_clk_pllv1_set_rate(rate, *prate, &reg);
+
+	mfi = (reg >> 10) & 0xf;
+	mfn = reg & 0x3ff;
+	mfd = (reg >> 16) & 0x3ff;
+	pd =  (reg >> 26) & 0xf;
+
+	return _clk_pllv1_recalc_rate(mfi, mfn, mfd, pd, *prate);
+}
+
 static struct clk_ops clk_pllv1_ops = {
-	.recalc_rate = clk_pllv1_recalc_rate,
+	.recalc_rate	= clk_pllv1_recalc_rate,
+	.round_rate	= clk_pllv1_round_rate,
+	.set_rate	= clk_pllv1_set_rate,
 };
 
 struct clk *imx_clk_pllv1(const char *name, const char *parent,
diff --git a/arch/arm/mach-imx/mx27.h b/arch/arm/mach-imx/mx27.h
index 8a65f19..c64632b 100644
--- a/arch/arm/mach-imx/mx27.h
+++ b/arch/arm/mach-imx/mx27.h
@@ -231,8 +231,13 @@
 #define MX27_DMA_REQ_SDHC3	36
 #define MX27_DMA_REQ_NFC	37
 
-#ifndef __ASSEMBLY__
+#ifdef CONFIG_SOC_IMX27
 extern int mx27_revision(void);
+#else
+static int mx27_revision(void)
+{
+	return -1;
+}
 #endif
 
 #endif /* ifndef __MACH_MX27_H__ */
-- 
1.8.1.5



From jic23 at kernel.org  Sat Jul 20 05:35:14 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sat, 20 Jul 2013 10:35:14 +0100
Subject: [PATCH 2/5] iio: at91: Use different prescal, startup mask in
 MR for different IP
In-Reply-To: <51E66D5E.1060608@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-3-git-send-email-josh.wu@atmel.com>
 <51E64EBB.30700@atmel.com> <51E66D5E.1060608@atmel.com>
Message-ID: <51EA59D2.4050907@kernel.org>

On 07/17/2013 11:09 AM, Josh Wu wrote:
> Hi, Nicolas
> 
> Thanks for your review.
> 
> On 7/17/2013 3:58 PM, Nicolas Ferre wrote:
>> On 14/07/2013 10:04, Josh Wu :
>>> For at91 boards, there are different IPs for adc. Different IPs has different
>>> STARTUP & PRESCAL mask in ADC_MR.
>>>
>>> This patch can change the masks according to the different IP version.
>>>
>>> Signed-off-by: Josh Wu <josh.wu at atmel.com>
>>> ---
>>>   arch/arm/mach-at91/include/mach/at91_adc.h |    9 ++++--
>>>   drivers/iio/adc/at91_adc.c                 |   48 ++++++++++++++++++++++++++--
>>>   2 files changed, 53 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-at91/include/mach/at91_adc.h b/arch/arm/mach-at91/include/mach/at91_adc.h
>>> index 8e7ed5c..ab273ee 100644
>>> --- a/arch/arm/mach-at91/include/mach/at91_adc.h
>>> +++ b/arch/arm/mach-at91/include/mach/at91_adc.h
>>> @@ -28,9 +28,12 @@
>>>   #define            AT91_ADC_TRGSEL_EXTERNAL    (6 << 1)
>>>   #define        AT91_ADC_LOWRES        (1 << 4)    /* Low Resolution */
>>>   #define        AT91_ADC_SLEEP        (1 << 5)    /* Sleep Mode */
>>> -#define        AT91_ADC_PRESCAL    (0x3f << 8)    /* Prescalar Rate Selection */
>>> +#define        AT91_ADC_PRESCAL    (0xff << 8)    /* Prescalar Rate Selection */
>>> +#define        AT91_ADC_PRESCAL_9260    (0x3f << 8)
>>>   #define            AT91_ADC_PRESCAL_(x)    ((x) << 8)
>>> -#define        AT91_ADC_STARTUP    (0x1f << 16)    /* Startup Up Time */
>>> +#define        AT91_ADC_STARTUP    (0xf << 16)    /* Startup Up Time */
>>
>> Which product has this kind of startup mask: 0xf? Compared with 9260 and 9g45 values, it seems strange to me: maybe a
>> little comment should be added.
> 
> From the datasheet, In at91sam9x5 and sama5d3x, the startup time mask is become 0xf. In meanwhile, the startup time
> calculation method is also changed.
> 
> Before at91sam9x5, Startup Time = (STARTUP+1) * 8/ADCCLK
> 
> Since at91sam9x5,  Startup Time = <find the following lookup table>
>         0 SUT0 0 periods of ADCClock
>         1 SUT8 8 periods of ADCClock
>         2 SUT16 16 periods of ADCClock
>         3 SUT24 24 periods of ADCClock
>         4 SUT64 64 periods of ADCClock
>         5 SUT80 80 periods of ADCClock
>         ...    ...
>         14 SUT896 896 periods of ADCClock
>         15 SUT960 960 periods of ADCClock
> 
> so only 4bits, it still can define < 960's ADC clock.
> 
> In my 3/5 patch, it implement this calculation method.
> 
>>
>>
>>> +#define        AT91_ADC_STARTUP_9260 (0x1f << 16)
>>> +#define        AT91_ADC_STARTUP_9G45    (0x7f << 16)
>>>   #define            AT91_ADC_STARTUP_(x)    ((x) << 16)
>>>   #define        AT91_ADC_SHTIM        (0xf  << 24)    /* Sample & Hold Time */
>>>   #define            AT91_ADC_SHTIM_(x)    ((x) << 24)
>>> @@ -58,4 +61,6 @@
>>>   #define AT91_ADC_CHR(n)        (0x30 + ((n) * 4))    /* Channel Data Register N */
>>>   #define        AT91_ADC_DATA        (0x3ff)
>>>
>>> +#define AT91_ADC_VERSION    0xFC
>>> +
>>>   #endif
>>> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
>>> index 18bd54f..14e99ba 100644
>>> --- a/drivers/iio/adc/at91_adc.c
>>> +++ b/drivers/iio/adc/at91_adc.c
>>> @@ -39,6 +39,12 @@
>>>   #define at91_adc_writel(st, reg, val) \
>>>       (writel_relaxed(val, st->reg_base + reg))
>>>
>>> +struct at91_adc_caps {
>>> +    bool    has_tsmr;    /* only at91sam9x5, sama5d3 have TSMR reg */
>>> +    u32    mr_prescal_mask;
>>> +    u32    mr_startup_mask;
>>> +};
>>> +
>>
>> If we move to DT and compatible string for these values, maybe a separate structure won't be needed....
> 
> yes, if we move the mask as DT property.
> But another way is define above structure in driver. Driver will load the correct mask by checking the compatible
> string. In this way, we don't exposure all IP details out to DT.
> I prefer the second way in the moment.
> 
> By answer this question, I just had a second thought of the ADC compatible implementation:
> For touch ADC, there should have 3 catalogs:
>   9260/9g20: not support touch.
>   9g45: support touch, but no average, no TSMR. Need a software filter
>   9x5, sama5: support touch, with average, TSMR. Sample data function changed a lot from 9g45.
> 
>>
>>
>>>   struct at91_adc_state {
>>>       struct clk        *adc_clk;
>>>       u16            *buffer;
>>> @@ -62,6 +68,7 @@ struct at91_adc_state {
>>>       u32            res;        /* resolution used for convertions */
>>>       bool            low_res;    /* the resolution corresponds to the lowest one */
>>>       wait_queue_head_t    wq_data_avail;
>>> +    struct at91_adc_caps    caps;
>>>   };
>>>
>>>   static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
>>> @@ -580,6 +587,41 @@ static const struct iio_info at91_adc_info = {
>>>       .read_raw = &at91_adc_read_raw,
>>>   };
>>>
>>> +/*
>>> + * Since atmel adc support different ip for touchscreen mode. Through the
>>> + * IP check, we will know the touchscreen capbilities.
>>> + */
>>> +static void atmel_adc_get_cap(struct at91_adc_state *st)
>>> +{
>>> +    unsigned int version;
>>> +    struct iio_dev *idev = iio_priv_to_dev(st);
>>> +
>>> +    version = at91_adc_readl(st, AT91_ADC_VERSION);
>>> +    dev_dbg(&idev->dev, "version: 0x%x\n", version);
>>> +
>>> +    st->caps.mr_prescal_mask = AT91_ADC_PRESCAL_9260;
>>> +    st->caps.mr_startup_mask = AT91_ADC_STARTUP_9260;
>>> +
>>> +    /* keep only major version number */
>>> +    switch (version & 0xf00) {
>>> +    case 0x500:    /* SAMA5D3 */
>>> +    case 0x400:    /* AT91SAM9X5/9N12 */
>>> +        st->caps.has_tsmr = 1;
>>> +        st->caps.mr_startup_mask = AT91_ADC_STARTUP;
>>
>> Here is where AT91_ADC_STARTUP may need another name: what about AT91_ADC_STARTUP_9x5 to match the "compatibility" of
>> this value?
> 
> ok.
> 
>>
>>
>>> +    case 0x200:    /* AT91SAM9M10/9G45 */
>>> +        st->caps.mr_prescal_mask = AT91_ADC_PRESCAL;
>>> +
>>> +        if ((version & 0xf00) == 0x200)
>>
>> Sorry but I do not understand this test in a switch/case entry where it should always be true...
> 
> Since the switch case is fall through, that means the higher IP (at91sam9x5, sama5) will also running this check, but
> this line only for 9G45 chip.
> 
> a little bit hard to read  :)

Indeed. Write the case statements out long hand without the full throughs.
It'll take a couple more lines but be much easer to read.
> 
>>
>>
>>> +            st->caps.mr_startup_mask = AT91_ADC_STARTUP_9G45;
>>> +    case 0x100:    /* AT91SAM9260/9G20 */
>>> +        break;
>>> +    default:
>>> +        dev_warn(&idev->dev,
>>> +                "Unmanaged adc version, use minimal capabilities\n");
>>> +        break;
>>> +    };
>>> +}
>>> +
>>>   static int at91_adc_probe(struct platform_device *pdev)
>>>   {
>>>       unsigned int prsc, mstrclk, ticks, adc_clk, adc_clk_khz, shtim;
>>> @@ -645,6 +687,8 @@ static int at91_adc_probe(struct platform_device *pdev)
>>>           goto error_free_device;
>>>       }
>>>
>>> +    atmel_adc_get_cap(st);
>>> +
>>>       st->clk = devm_clk_get(&pdev->dev, "adc_clk");
>>>       if (IS_ERR(st->clk)) {
>>>           dev_err(&pdev->dev, "Failed to get the clock.\n");
>>> @@ -704,8 +748,8 @@ static int at91_adc_probe(struct platform_device *pdev)
>>>       shtim = round_up((st->sample_hold_time * adc_clk_khz /
>>>                 1000) - 1, 1);
>>>
>>> -    reg = AT91_ADC_PRESCAL_(prsc) & AT91_ADC_PRESCAL;
>>> -    reg |= AT91_ADC_STARTUP_(ticks) & AT91_ADC_STARTUP;
>>> +    reg = AT91_ADC_PRESCAL_(prsc) & st->caps.mr_prescal_mask;
>>> +    reg |= AT91_ADC_STARTUP_(ticks) & st->caps.mr_startup_mask;
>>>       if (st->low_res)
>>>           reg |= AT91_ADC_LOWRES;
>>>       if (st->sleep_mode)
>>>
>>
>>
> 
> Thanks again.
> Best Regards,
> Josh Wu
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From jic23 at kernel.org  Sat Jul 20 05:39:17 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sat, 20 Jul 2013 10:39:17 +0100
Subject: [PATCH 3/5] iio: at91: ADC start-up time calculation changed
 since at91sam9x5
In-Reply-To: <1373789069-11604-4-git-send-email-josh.wu@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-4-git-send-email-josh.wu@atmel.com>
Message-ID: <51EA5AC5.30400@kernel.org>

On 07/14/2013 09:04 AM, Josh Wu wrote:
> Since in at91sam9x5, sama5d3x chip. the start up time calucation is changed.
> And these two chips also have TSMR, so we check whether ADC has TSMR, then
> choose different start up time calculation formula.
If this doesn't have anything directly to do with the TSMR and this is just
coincidence, then do this separately with it's own flag as it will be
easier to maintain in the long run.

Jonathan
> 
> Signed-off-by: Josh Wu <josh.wu at atmel.com>
> ---
>  drivers/iio/adc/at91_adc.c |   40 +++++++++++++++++++++++++++++++++-------
>  1 file changed, 33 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index 14e99ba..e93a075 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -733,13 +733,39 @@ static int at91_adc_probe(struct platform_device *pdev)
>  		goto error_disable_adc_clk;
>  	}
>  
> -	/*
> -	 * Number of ticks needed to cover the startup time of the ADC as
> -	 * defined in the electrical characteristics of the board, divided by 8.
> -	 * The formula thus is : Startup Time = (ticks + 1) * 8 / ADC Clock
> -	 */
> -	ticks = round_up((st->startup_time * adc_clk_khz /
> -			  1000) - 1, 8) / 8;
> +	if (!st->caps.has_tsmr) {
> +		/*
> +		 * Number of ticks needed to cover the startup time of the ADC
> +		 * as defined in the electrical characteristics of the board,
> +		 * divided by 8. The formula thus is :
> +		 *   Startup Time = (ticks + 1) * 8 / ADC Clock
> +		 */
> +		ticks = round_up((st->startup_time * adc_clk_khz /
> +				  1000) - 1, 8) / 8;
> +	} else {
> +		/*
> +		 * For sama5d3x and at91sam9x5, the formula changes to:
> +		 * Startup Time = <lookup_table_value> / ADC Clock
> +		 */
> +		const int startup_lookup[] = {
> +			0  , 8  , 16 , 24 ,
> +			64 , 80 , 96 , 112,
> +			512, 576, 640, 704,
> +			768, 832, 896, 960
> +			};
> +
> +		int i, size = ARRAY_SIZE(startup_lookup);
> +		ticks = st->startup_time * adc_clk_khz / 1000;
> +		for (i = 0; i < size; i++)
> +			if (ticks < startup_lookup[i])
> +				break;
> +
> +		ticks = i;
> +		if (ticks == size)
> +			/* Reach the end of lookup table */
> +			ticks = size - 1;
> +	}
> +
>  	/*
>  	 * a minimal Sample and Hold Time is necessary for the ADC to guarantee
>  	 * the best converted final value between two channels selection
> 


From jic23 at kernel.org  Sat Jul 20 05:57:57 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sat, 20 Jul 2013 10:57:57 +0100
Subject: [PATCH 5/5] iio: at91: introduce touch screen support in iio
 adc driver
In-Reply-To: <1373789069-11604-6-git-send-email-josh.wu@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-6-git-send-email-josh.wu@atmel.com>
Message-ID: <51EA5F25.6060504@kernel.org>

On 07/14/2013 09:04 AM, Josh Wu wrote:
> AT91 ADC hardware integrate touch screen support. So this patch add touch
> screen support for at91 adc iio driver.
> To enable touch screen support in adc, you need to add the dt parameters:
>   which type of touch are used? (4 or 5 wires), sample period time,
>   pen detect debounce time, average samples and pen detect resistor.
>
> In the meantime, since touch screen will use a interal period trigger of adc,
> so it is conflict to other hardware triggers. Driver will disable the hardware
> trigger support if touch screen is enabled.
>
> This driver has been tested in AT91SAM9X5-EK and SAMA5D3x-EK.

Firstly, this is adding input subsystem stuff inside an iio driver.  Generally we
are very anti this sort of combination, but I agree that right now the support for
doing it any other way is not really present.

The next bit of text is actually largely irrelevant here as I actually read the driver after
I wrote it and discovered the hardware handles all the nastiness of touch screen processing here.
I'll leave it here for reference of anyone working on parts where it is relevant ;)

     When I had more time to work on IIO I was working on an iio to input
     bridge driver (similar to iio-hwmon, but using the buffered interface hooks instead).
     It was fundamentally working, but I never quite got around to cleaning it up for submission.
     I'd appreciate any comments on what is missing or does not work for this case.

     http://marc.info/?l=linux-iio&m=135167944813803&w=2

     Ulitimately what I would love to see is a generic touch screen consumer driver for IIO
     adc's but appreciate that is a big and complex job given all the different varieties of
     touch screen and trying to abstract the control of the various channels.

So back to this part.  My immediate thought is that this really ought to have an mfd
underneath separate IIO and input drivers.

Dmitry, what do you think?

>
> Signed-off-by: Josh Wu <josh.wu at atmel.com>
> Cc: Dmitry Torokhov <dmitry.torokhov at gmail.com>
> ---
>  .../devicetree/bindings/arm/atmel-adc.txt          |   13 +
>  arch/arm/mach-at91/include/mach/at91_adc.h         |   34 ++
>  drivers/iio/adc/at91_adc.c                         |  389 ++++++++++++++++++--
>  3 files changed, 412 insertions(+), 24 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> index 0db2945..925d656 100644
> --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> @@ -29,6 +29,19 @@ Optional properties:
>    - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
>    - atmel,adc-clock-rate: ADC clock rate. If not specified, use the default
>  			  adc_op_clk.
> +  - atmel,adc-touchscreen-wires: Number of touch screen wires. Only support
> +				 4 and 5 wires touch screen.
> +    NOTE: when adc touch screen enabled, the adc hardware trigger will be
> +          disabled. Since touch screen will occupied the trigger register.
> +  - atmel,adc-ts-pendet-debounce: Debounce time in microsecond for touch pen
> +				  detect.
> +  - atmel,adc-ts-sample-period-time: Sample Period Time in microsecond for
> +				     touch screen
> +  - atmel,adc-ts-filter-average: Numbers of sampling data will be averaged.
> +    0 means no average. 1 means average two samples. 2 means average four
> +    samples. 3 means average eight samples.
> +  - atmel,adc-ts-pendet-sensitivity: Pen Detection input pull-up resistor.
> +    It can be 0, 1, 2, 3.
>
>  Optional trigger Nodes:
>    - Required properties:
> diff --git a/arch/arm/mach-at91/include/mach/at91_adc.h b/arch/arm/mach-at91/include/mach/at91_adc.h
> index ab273ee..6d6cc14 100644
> --- a/arch/arm/mach-at91/include/mach/at91_adc.h
> +++ b/arch/arm/mach-at91/include/mach/at91_adc.h
> @@ -57,10 +57,44 @@
>  #define AT91_ADC_IER		0x24		/* Interrupt Enable Register */
>  #define AT91_ADC_IDR		0x28		/* Interrupt Disable Register */
>  #define AT91_ADC_IMR		0x2C		/* Interrupt Mask Register */
> +#define		AT91_ADC_IER_PEN	(1 << 29)
> +#define		AT91_ADC_IER_NOPEN	(1 << 30)
> +#define		AT91_ADC_IER_XRDY	(1 << 20)
> +#define		AT91_ADC_IER_YRDY	(1 << 21)
> +#define		AT91_ADC_IER_PRDY	(1 << 22)
> +#define		AT91_ADC_ISR_PENS	(1 << 31)
>
>  #define AT91_ADC_CHR(n)		(0x30 + ((n) * 4))	/* Channel Data Register N */
>  #define		AT91_ADC_DATA		(0x3ff)
>
> +#define AT91_ADC_ACR		0x94	/* Analog Control Register */
> +#define		AT91_ADC_ACR_PENDETSENS	(0x3 << 0)	/* pull-up resistor */
> +
> +#define AT91_ADC_TSMR		0xB0
> +#define		AT91_ADC_TSMR_TSMODE	(3 << 0)	/* Touch Screen Mode */
> +#define			AT91_ADC_TSMR_TSMODE_NONE		(0 << 0)
> +#define			AT91_ADC_TSMR_TSMODE_4WIRE_NO_PRESS	(1 << 0)
> +#define			AT91_ADC_TSMR_TSMODE_4WIRE_PRESS	(2 << 0)
> +#define			AT91_ADC_TSMR_TSMODE_5WIRE		(3 << 0)
> +#define		AT91_ADC_TSMR_TSAV	(3 << 4)	/* Averages samples */
> +#define			AT91_ADC_TSMR_TSAV_(x)		((x) << 4)
> +#define		AT91_ADC_TSMR_SCTIM	(0x0f << 16)	/* Switch closure time */
> +#define		AT91_ADC_TSMR_PENDBC	(0x0f << 28)	/* Pen Debounce time */
> +#define			AT91_ADC_TSMR_PENDBC_(x)	((x) << 28)
> +#define		AT91_ADC_TSMR_NOTSDMA	(1 << 22)	/* No Touchscreen DMA */
> +#define		AT91_ADC_TSMR_PENDET_DIS	(0 << 24)	/* Pen contact detection disable */
> +#define		AT91_ADC_TSMR_PENDET_ENA	(1 << 24)	/* Pen contact detection enable */
> +
> +#define AT91_ADC_TSXPOSR	0xB4
> +#define AT91_ADC_TSYPOSR	0xB8
> +#define AT91_ADC_TSPRESSR	0xBC
> +
>  #define AT91_ADC_VERSION	0xFC
>
> +/* Trigger Register bit field */
> +#define		AT91_ADC_TRGR_TRGPER	(0xffff << 16)
> +#define			AT91_ADC_TRGR_TRGPER_(x)	((x) << 16)
> +#define		AT91_ADC_TRGR_TRGMOD	(0x7 << 0)
> +#define			AT91_ADC_TRGR_MOD_PERIOD_TRIG	(5 << 0)
> +
>  #endif
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index 8f1386f..ffc0e42 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -11,6 +11,7 @@
>  #include <linux/clk.h>
>  #include <linux/err.h>
>  #include <linux/io.h>
> +#include <linux/input.h>
>  #include <linux/interrupt.h>
>  #include <linux/jiffies.h>
>  #include <linux/kernel.h>
> @@ -39,12 +40,24 @@
>  #define at91_adc_writel(st, reg, val) \
>  	(writel_relaxed(val, st->reg_base + reg))
>
> +#define DRIVER_NAME		"at91_adc"
> +#define MAX_POS_BITS		12
> +
> +#define ZTHRESHOLD		9000
> +
>  struct at91_adc_caps {
> +	bool	has_12bits_xy;	/* true means use 12 bits. Otherwise 10 bits */
>  	bool	has_tsmr;	/* only at91sam9x5, sama5d3 have TSMR reg */
>  	u32	mr_prescal_mask;
>  	u32	mr_startup_mask;
>  };
>
> +enum atmel_adc_ts_type {
> +	ATMEL_ADC_TOUCHSCREEN_NONE = 0,
> +	ATMEL_ADC_TOUCHSCREEN_4WIRE,
> +	ATMEL_ADC_TOUCHSCREEN_5WIRE,
> +};
> +
>  struct at91_adc_state {
>  	struct clk		*adc_clk;
>  	u32			adc_clk_rate;
> @@ -70,6 +83,29 @@ struct at91_adc_state {
>  	bool			low_res;	/* the resolution corresponds to the lowest one */
>  	wait_queue_head_t	wq_data_avail;
>  	struct at91_adc_caps	caps;
> +
> +	/*
> +	 * Following ADC channels are shared by touchscreen:
> +	 *
> +	 * CH0 -- Touch screen XP/UL
> +	 * CH1 -- Touch screen XM/UR
> +	 * CH2 -- Touch screen YP/LL
> +	 * CH3 -- Touch screen YM/Sense
> +	 * CH4 -- Touch screen LR(5-wire only)
> +	 *
> +	 * The bitfields below represents the reserved channel in the
> +	 * touchscreen mode.
> +	 */
> +#define CHAN_MASK_TOUCHSCREEN_4WIRE	(0xf << 0)
> +#define CHAN_MASK_TOUCHSCREEN_5WIRE	(0x1f << 0)
> +	enum atmel_adc_ts_type	touchscreen_type;
> +	struct input_dev		*ts_input;
> +
> +	u8			ts_filter_average;
> +	u16			ts_pen_detect_debounce;
> +	u8			ts_pen_detect_sensitivity;
> +	u16			ts_sample_period_time;
> +	u16			ts_sample_period_val;
>  };
>
>  static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
> @@ -104,14 +140,10 @@ static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
>  	return IRQ_HANDLED;
>  }
>
> -static irqreturn_t at91_adc_eoc_trigger(int irq, void *private)
> +/* Handler for classic adc channel eoc trigger */
> +void handle_adc_eoc_trigger(int irq, struct iio_dev *idev)
>  {
> -	struct iio_dev *idev = private;
>  	struct at91_adc_state *st = iio_priv(idev);
> -	u32 status = at91_adc_readl(st, st->registers->status_register);
> -
> -	if (!(status & st->registers->drdy_mask))
> -		return IRQ_HANDLED;
>
>  	if (iio_buffer_enabled(idev)) {
>  		disable_irq_nosync(irq);
> @@ -121,6 +153,115 @@ static irqreturn_t at91_adc_eoc_trigger(int irq, void *private)
>  		st->done = true;
>  		wake_up_interruptible(&st->wq_data_avail);
>  	}
> +}
> +
> +static int at91_ts_sample(struct at91_adc_state *st)
> +{
> +	unsigned int xscale, yscale, reg, z1, z2;
> +	unsigned int x, y, pres, xpos, ypos;
> +	unsigned int rxp = 1;
> +	unsigned int factor = 1000;
> +	struct iio_dev *idev = iio_priv_to_dev(st);
> +
> +	unsigned int xyz_mask_bits = st->caps.has_12bits_xy ? 12 : 10;
> +	unsigned int xyz_mask = (1 << xyz_mask_bits) - 1;
> +
> +	/* calculate position */
> +	/* x position = (x / xscale) * max, max = 2^MAX_POS_BITS - 1 */
> +	reg = at91_adc_readl(st, AT91_ADC_TSXPOSR);
> +	xpos = reg & xyz_mask;
> +	x = (xpos << MAX_POS_BITS) - xpos;
> +	xscale = (reg >> 16) & xyz_mask;
> +	if (xscale != 0)
> +		x /= xscale;
> +	else
> +		dev_err(&idev->dev, "xscale == 0!!!\n");
> +
> +	/* y position = (y / yscale) * max, max = 2^MAX_POS_BITS - 1 */
> +	reg = at91_adc_readl(st, AT91_ADC_TSYPOSR);
> +	ypos = reg & xyz_mask;
> +	y = (ypos << MAX_POS_BITS) - ypos;
> +	yscale = (reg >> 16) & xyz_mask;
> +	if (yscale != 0)
> +		y /= yscale;
> +	else
> +		dev_err(&idev->dev, "yscale == 0!!!\n");
> +
> +	/* calculate the pressure */
> +	reg = at91_adc_readl(st, AT91_ADC_TSPRESSR);
> +	z1 = reg & xyz_mask;
> +	z2 = (reg >> 16) & xyz_mask;
> +
> +	if (z1 != 0)
> +		pres = rxp * (x * factor / 1024) * (z2 * factor / z1 - factor)
> +			/ factor;
> +	else
> +		pres = ZTHRESHOLD;	/* no pen contacted */
> +
> +	dev_dbg(&idev->dev, "xpos = %d, xscale = %d, ypos = %d, yscale = %d, z1 = %d, z2 = %d, press = %d\n",
> +				xpos, xscale, ypos, yscale, z1, z2, pres);
> +
> +	if (pres < ZTHRESHOLD) {
> +		dev_dbg(&idev->dev, "x = %d, y = %d, pressure = %d\n",
> +					x, y, pres / factor);
> +		input_report_abs(st->ts_input, ABS_X, x);
> +		input_report_abs(st->ts_input, ABS_Y, y);
> +		input_report_abs(st->ts_input, ABS_PRESSURE, pres);
> +		input_report_key(st->ts_input, BTN_TOUCH, 1);
> +		input_sync(st->ts_input);
> +	} else {
> +		dev_dbg(&idev->dev,
> +				"pressure too low: not reporting\n");
> +	}
> +
> +	return 0;
> +}
> +
> +
> +static irqreturn_t at91_adc_interrupt(int irq, void *private)
> +{
> +	struct iio_dev *idev = private;
> +	struct at91_adc_state *st = iio_priv(idev);
> +	u32 status = at91_adc_readl(st, st->registers->status_register);
> +	const uint32_t ts_data_irq_mask =
> +		AT91_ADC_IER_XRDY |
> +		AT91_ADC_IER_YRDY |
> +		AT91_ADC_IER_PRDY;
> +
> +	if (status & st->registers->drdy_mask)
> +		handle_adc_eoc_trigger(irq, idev);
> +
> +	if (status & AT91_ADC_IER_PEN) {
> +		at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_PEN);
> +		at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_NOPEN |
> +			ts_data_irq_mask);
> +		/* Set up period trigger for sampling */
> +		at91_adc_writel(st, st->registers->trigger_register,
> +			AT91_ADC_TRGR_MOD_PERIOD_TRIG |
> +			AT91_ADC_TRGR_TRGPER_(st->ts_sample_period_val));
> +	} else if (status & AT91_ADC_IER_NOPEN) {
> +		at91_adc_writel(st, st->registers->trigger_register, 0);
> +		at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_NOPEN |
> +			ts_data_irq_mask);
> +		at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_PEN);
> +
> +		input_report_key(st->ts_input, BTN_TOUCH, 0);
> +		input_sync(st->ts_input);
> +	} else if ((status & ts_data_irq_mask) == ts_data_irq_mask) {
> +		/* Now all touchscreen data is ready */
> +
> +		if (status & AT91_ADC_ISR_PENS) {
> +			/* validate data by pen contact */
> +			at91_ts_sample(st);
> +		} else {
> +			/* triggered by event that is no pen contact, just read
> +			 * them to clean the interrupt and discard all.
> +			 */
> +			at91_adc_readl(st, AT91_ADC_TSXPOSR);
> +			at91_adc_readl(st, AT91_ADC_TSYPOSR);
> +			at91_adc_readl(st, AT91_ADC_TSPRESSR);
> +		}
> +	}
>
>  	return IRQ_HANDLED;
>  }
> @@ -130,6 +271,16 @@ static int at91_adc_channel_init(struct iio_dev *idev)
>  	struct at91_adc_state *st = iio_priv(idev);
>  	struct iio_chan_spec *chan_array, *timestamp;
>  	int bit, idx = 0;
> +	unsigned long rsvd_mask = 0;
> +
> +	/* If touchscreen is enable, then reserve the adc channels */
> +	if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_4WIRE)
> +		rsvd_mask = CHAN_MASK_TOUCHSCREEN_4WIRE;
> +	else if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_5WIRE)
> +		rsvd_mask = CHAN_MASK_TOUCHSCREEN_5WIRE;
> +
> +	/* set up the channel mask to reserve touchscreen channels */
> +	st->channels_mask &= ~rsvd_mask;
>
>  	idev->num_channels = bitmap_weight(&st->channels_mask,
>  					   st->num_channels) + 1;
> @@ -561,6 +712,57 @@ static int at91_adc_probe_dt(struct at91_adc_state *st,
>  		i++;
>  	}
>
> +	/* Check if touchscreen is enabled in DT. */
> +	ret = of_property_read_u32(node, "atmel,adc-touchscreen-wires", &prop);
> +	if (ret)
> +		dev_info(&idev->dev, "Touchscreen not enabled.\n");
> +	else if (prop == 4)
> +		st->touchscreen_type = ATMEL_ADC_TOUCHSCREEN_4WIRE;
> +	else if (prop == 5)
> +		st->touchscreen_type = ATMEL_ADC_TOUCHSCREEN_5WIRE;
> +	else
> +		dev_warn(&idev->dev, "Unsupported number of touchscreen wires (%d)\n",
> +				prop);
> +
> +	if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_NONE)
> +		return 0;
> +
> +	/* Touch screen is enabled, so check touch screen dt parameters */
> +	if (of_property_read_u32(node, "atmel,adc-ts-filter-average", &prop)) {
> +		dev_err(&idev->dev, "Missing atmel,adc-ts-filtering-average property in the DT.\n");
> +		ret = -EINVAL;
> +		goto error_ret;
> +	}
> +	st->ts_filter_average = prop;
> +	if (st->ts_filter_average > 3) {
> +		dev_err(&idev->dev, "Invalid atmel,adc-ts-filtering-average property in the DT.\n");
> +		ret = -EINVAL;
> +		goto error_ret;
> +	}
> +
> +	prop = 0;
> +	of_property_read_u32(node, "atmel,adc-ts-pendet-debounce", &prop);
> +	st->ts_pen_detect_debounce = prop;
> +
> +	/* default sample period is 2ms. The real touch sample period should be
> +	 * this period * TSFREQ.
> +	 */
> +	prop = 2000;
> +	of_property_read_u32(node, "atmel,adc-ts-sample-period-time", &prop);
> +	st->ts_sample_period_time = prop;
> +
> +	if (of_property_read_u32(node, "atmel,adc-ts-pendet-sensitivity", &prop)) {
> +		dev_err(&idev->dev, "Missing atmel,adc-ts-pendet-sensitivity property in the DT.\n");
> +		ret = -EINVAL;
> +		goto error_ret;
> +	}
> +	st->ts_pen_detect_sensitivity = prop;
> +	if (st->ts_pen_detect_sensitivity > 3) {
> +		dev_err(&idev->dev, "Invalid atmel,adc-ts-pendet-sensitivity property in the DT.\n");
> +		ret = -EINVAL;
> +		goto error_ret;
> +	}
> +
>  	return 0;
>
>  error_ret:
> @@ -592,6 +794,114 @@ static const struct iio_info at91_adc_info = {
>  	.read_raw = &at91_adc_read_raw,
>  };
>
> +/* Touchscreen related functions */
> +static int atmel_ts_open(struct input_dev *dev)
> +{
> +	struct at91_adc_state *st = input_get_drvdata(dev);
> +
> +	at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_PEN);
> +	return 0;
> +}
> +
> +static void atmel_ts_close(struct input_dev *dev)
> +{
> +	struct at91_adc_state *st = input_get_drvdata(dev);
> +
> +	at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_PEN);
> +}
> +
> +static int at91_ts_hw_init(struct at91_adc_state *st, u32 adc_clk_khz)
> +{
> +	u32 reg = 0, pendbc;
> +	int i = 0;
> +
> +	if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_4WIRE)
> +		reg = AT91_ADC_TSMR_TSMODE_4WIRE_PRESS;
> +	else
> +		reg = AT91_ADC_TSMR_TSMODE_5WIRE;
> +
> +	/* a Pen Detect Debounce Time is necessary for the ADC Touch to avoid
> +	 * pen detect noise.
> +	 * The formula is : Pen Detect Debounce Time = (2 ^ pendbc) / ADCClock
> +	 */
> +	pendbc = round_up(st->ts_pen_detect_debounce * adc_clk_khz / 1000, 1);
> +
> +	while (pendbc >> ++i)
> +		;	/* Empty! Find the shift offset */
> +	if (abs(pendbc - (1 << i)) < abs(pendbc - (1 << (i - 1))))
> +		pendbc = i;
> +	else
> +		pendbc = i - 1;
> +
> +	if (st->caps.has_tsmr) {
> +		reg |= AT91_ADC_TSMR_TSAV_(st->ts_filter_average)
> +				& AT91_ADC_TSMR_TSAV;
> +		reg |= AT91_ADC_TSMR_PENDBC_(pendbc) & AT91_ADC_TSMR_PENDBC;
> +		reg |= AT91_ADC_TSMR_NOTSDMA;
> +		reg |= AT91_ADC_TSMR_PENDET_ENA;
> +		reg |= 0x03 << 8;	/* TSFREQ, need bigger than TSAV */
> +
> +		at91_adc_writel(st, AT91_ADC_TSMR, reg);
> +	} else {
> +		/* TODO: for 9g45 which has no TSMR */
> +	}
> +
> +	/* Change adc internal resistor value for better pen detection,
> +	 * default value is 100 kOhm.
> +	 * 0 = 200 kOhm, 1 = 150 kOhm, 2 = 100 kOhm, 3 = 50 kOhm
> +	 * option only available on ES2 and higher
> +	 */
> +	at91_adc_writel(st, AT91_ADC_ACR, st->ts_pen_detect_sensitivity
> +			& AT91_ADC_ACR_PENDETSENS);
> +
> +	/* Sample Peroid Time = (TRGPER + 1) / ADCClock */
> +	st->ts_sample_period_val = round_up((st->ts_sample_period_time *
> +			adc_clk_khz / 1000) - 1, 1);
> +
> +	return 0;
> +}
> +
> +static int at91_ts_register(struct at91_adc_state *st)
> +{
> +	struct input_dev *input;
> +	struct iio_dev *idev = iio_priv_to_dev(st);
> +	int ret;
> +
> +	input = input_allocate_device();
> +	if (!input) {
> +		dev_err(&idev->dev, "Failed to allocate TS device!\n");
> +		return -ENOMEM;
> +	}
> +
> +	input->name = DRIVER_NAME;
> +	input->id.bustype = BUS_HOST;
> +	input->dev.parent = idev->dev.parent;
> +	input->open = atmel_ts_open;
> +	input->close = atmel_ts_close;
> +
> +	__set_bit(EV_ABS, input->evbit);
> +	__set_bit(EV_KEY, input->evbit);
> +	__set_bit(BTN_TOUCH, input->keybit);
> +	input_set_abs_params(input, ABS_X, 0, (1 << MAX_POS_BITS) - 1, 0, 0);
> +	input_set_abs_params(input, ABS_Y, 0, (1 << MAX_POS_BITS) - 1, 0, 0);
> +	input_set_abs_params(input, ABS_PRESSURE, 0, 0xffffff, 0, 0);
> +
> +	st->ts_input = input;
> +	input_set_drvdata(input, st);
> +
> +	ret = input_register_device(input);
> +	if (ret)
> +		input_free_device(st->ts_input);
> +
> +	return ret;
> +}
> +
> +static void at91_ts_unregister(struct at91_adc_state *st)
> +{
> +	input_unregister_device(st->ts_input);
> +	input_free_device(st->ts_input);
> +}
> +
>  /*
>   * Since atmel adc support different ip for touchscreen mode. Through the
>   * IP check, we will know the touchscreen capbilities.
> @@ -610,6 +920,7 @@ static void atmel_adc_get_cap(struct at91_adc_state *st)
>  	/* keep only major version number */
>  	switch (version & 0xf00) {
>  	case 0x500:	/* SAMA5D3 */
> +		st->caps.has_12bits_xy = 1;
>  	case 0x400:	/* AT91SAM9X5/9N12 */
>  		st->caps.has_tsmr = 1;
>  		st->caps.mr_startup_mask = AT91_ADC_STARTUP;
> @@ -683,7 +994,7 @@ static int at91_adc_probe(struct platform_device *pdev)
>  	at91_adc_writel(st, AT91_ADC_CR, AT91_ADC_SWRST);
>  	at91_adc_writel(st, AT91_ADC_IDR, 0xFFFFFFFF);
>  	ret = request_irq(st->irq,
> -			  at91_adc_eoc_trigger,
> +			  at91_adc_interrupt,
>  			  0,
>  			  pdev->dev.driver->name,
>  			  idev);
> @@ -731,6 +1042,10 @@ static int at91_adc_probe(struct platform_device *pdev)
>  	adc_clk = st->adc_clk_rate ?
>  		st->adc_clk_rate : clk_get_rate(st->adc_clk);
>  	adc_clk_khz = adc_clk / 1000;
> +
> +	dev_dbg(&pdev->dev, "Master clock is set as: %d Hz, adc_clk should set as: %d Hz\n",
> +		mstrclk, adc_clk);
> +
>  	prsc = (mstrclk / (2 * adc_clk)) - 1;
>
>  	if (!st->startup_time) {
> @@ -799,30 +1114,52 @@ static int at91_adc_probe(struct platform_device *pdev)
>  	init_waitqueue_head(&st->wq_data_avail);
>  	mutex_init(&st->lock);
>
> -	ret = at91_adc_buffer_init(idev);
> -	if (ret < 0) {
> -		dev_err(&pdev->dev, "Couldn't initialize the buffer.\n");
> -		goto error_disable_adc_clk;
> -	}
> +	/*
> +	 * Since touch screen will set trigger register as period trigger. So
> +	 * when touch screen is enabled, then we have to disable hardware
> +	 * trigger for classic adc.
> +	 */
> +	if (!st->touchscreen_type) {
> +		ret = at91_adc_buffer_init(idev);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev, "Couldn't initialize the buffer.\n");
> +			goto error_disable_adc_clk;
> +		}
>
> -	ret = at91_adc_trigger_init(idev);
> -	if (ret < 0) {
> -		dev_err(&pdev->dev, "Couldn't setup the triggers.\n");
> -		goto error_unregister_buffer;
> +		ret = at91_adc_trigger_init(idev);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev, "Couldn't setup the triggers.\n");
> +			at91_adc_buffer_remove(idev);
> +			goto error_disable_adc_clk;
> +		}
> +	} else {
> +		if (!st->caps.has_tsmr) {
> +			dev_err(&pdev->dev, "We don't support non-TSMR adc\n");
> +			goto error_disable_adc_clk;
> +		}
> +
> +		ret = at91_ts_register(st);
> +		if (ret)
> +			goto error_disable_adc_clk;
> +
> +		at91_ts_hw_init(st, adc_clk_khz);
>  	}
>
>  	ret = iio_device_register(idev);
>  	if (ret < 0) {
>  		dev_err(&pdev->dev, "Couldn't register the device.\n");
> -		goto error_remove_triggers;
> +		goto error_iio_device_register;
>  	}
>
>  	return 0;
>
> -error_remove_triggers:
> -	at91_adc_trigger_remove(idev);
> -error_unregister_buffer:
> -	at91_adc_buffer_remove(idev);
> +error_iio_device_register:
> +	if (!st->touchscreen_type) {
> +		at91_adc_trigger_remove(idev);
> +		at91_adc_buffer_remove(idev);
> +	} else {
> +		at91_ts_unregister(st);
> +	}
>  error_disable_adc_clk:
>  	clk_disable_unprepare(st->adc_clk);
>  error_disable_clk:
> @@ -841,8 +1178,12 @@ static int at91_adc_remove(struct platform_device *pdev)
>  	struct at91_adc_state *st = iio_priv(idev);
>
>  	iio_device_unregister(idev);
> -	at91_adc_trigger_remove(idev);
> -	at91_adc_buffer_remove(idev);
> +	if (!st->touchscreen_type) {
> +		at91_adc_trigger_remove(idev);
> +		at91_adc_buffer_remove(idev);
> +	} else {
> +		at91_ts_unregister(st);
> +	}
>  	clk_disable_unprepare(st->adc_clk);
>  	clk_disable_unprepare(st->clk);
>  	free_irq(st->irq, idev);
> @@ -861,7 +1202,7 @@ static struct platform_driver at91_adc_driver = {
>  	.probe = at91_adc_probe,
>  	.remove = at91_adc_remove,
>  	.driver = {
> -		   .name = "at91_adc",
> +		   .name = DRIVER_NAME,
>  		   .of_match_table = of_match_ptr(at91_adc_dt_ids),
>  	},
>  };
>


From jogo at openwrt.org  Sat Jul 20 06:15:39 2013
From: jogo at openwrt.org (Jonas Gorski)
Date: Sat, 20 Jul 2013 12:15:39 +0200
Subject: [PATCH 2/2] net: ixp4xx_eth: use parent device for dma allocations
In-Reply-To: <1374315339-31469-1-git-send-email-jogo@openwrt.org>
References: <1374315339-31469-1-git-send-email-jogo@openwrt.org>
Message-ID: <1374315339-31469-3-git-send-email-jogo@openwrt.org>

Now that the platfomr device provides a dma_cohorent_mask, use it for
dma operations.

This fixes ethernet on ixp4xx which was broken since 3.7.

Signed-off-by: Jonas Gorski <jogo at openwrt.org>
---
 drivers/net/ethernet/xscale/ixp4xx_eth.c | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c b/drivers/net/ethernet/xscale/ixp4xx_eth.c
index 3d689fc..18aa660 100644
--- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
+++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
@@ -641,10 +641,10 @@ static inline void queue_put_desc(unsigned int queue, u32 phys,
 static inline void dma_unmap_tx(struct port *port, struct desc *desc)
 {
 #ifdef __ARMEB__
-	dma_unmap_single(&port->netdev->dev, desc->data,
+	dma_unmap_single(port->netdev->dev.parent, desc->data,
 			 desc->buf_len, DMA_TO_DEVICE);
 #else
-	dma_unmap_single(&port->netdev->dev, desc->data & ~3,
+	dma_unmap_single(port->netdev->dev.parent, desc->data & ~3,
 			 ALIGN((desc->data & 3) + desc->buf_len, 4),
 			 DMA_TO_DEVICE);
 #endif
@@ -711,9 +711,9 @@ static int eth_poll(struct napi_struct *napi, int budget)
 
 #ifdef __ARMEB__
 		if ((skb = netdev_alloc_skb(dev, RX_BUFF_SIZE))) {
-			phys = dma_map_single(&dev->dev, skb->data,
+			phys = dma_map_single(dev->dev.parent, skb->data,
 					      RX_BUFF_SIZE, DMA_FROM_DEVICE);
-			if (dma_mapping_error(&dev->dev, phys)) {
+			if (dma_mapping_error(dev->dev.parent, phys)) {
 				dev_kfree_skb(skb);
 				skb = NULL;
 			}
@@ -736,10 +736,11 @@ static int eth_poll(struct napi_struct *napi, int budget)
 #ifdef __ARMEB__
 		temp = skb;
 		skb = port->rx_buff_tab[n];
-		dma_unmap_single(&dev->dev, desc->data - NET_IP_ALIGN,
+		dma_unmap_single(dev->dev.parent, desc->data - NET_IP_ALIGN,
 				 RX_BUFF_SIZE, DMA_FROM_DEVICE);
 #else
-		dma_sync_single_for_cpu(&dev->dev, desc->data - NET_IP_ALIGN,
+		dma_sync_single_for_cpu(dev->dev.parent,
+					desc->data - NET_IP_ALIGN,
 					RX_BUFF_SIZE, DMA_FROM_DEVICE);
 		memcpy_swab32((u32 *)skb->data, (u32 *)port->rx_buff_tab[n],
 			      ALIGN(NET_IP_ALIGN + desc->pkt_len, 4) / 4);
@@ -858,7 +859,7 @@ static int eth_xmit(struct sk_buff *skb, struct net_device *dev)
 	memcpy_swab32(mem, (u32 *)((int)skb->data & ~3), bytes / 4);
 #endif
 
-	phys = dma_map_single(&dev->dev, mem, bytes, DMA_TO_DEVICE);
+	phys = dma_map_single(dev->dev.parent, mem, bytes, DMA_TO_DEVICE);
 	if (dma_mapping_error(&dev->dev, phys)) {
 		dev_kfree_skb(skb);
 #ifndef __ARMEB__
@@ -1104,7 +1105,7 @@ static int init_queues(struct port *port)
 	int i;
 
 	if (!ports_open) {
-		dma_pool = dma_pool_create(DRV_NAME, &port->netdev->dev,
+		dma_pool = dma_pool_create(DRV_NAME, port->netdev->dev.parent,
 					   POOL_ALLOC_SIZE, 32, 0);
 		if (!dma_pool)
 			return -ENOMEM;
@@ -1132,9 +1133,9 @@ static int init_queues(struct port *port)
 		data = buff;
 #endif
 		desc->buf_len = MAX_MRU;
-		desc->data = dma_map_single(&port->netdev->dev, data,
+		desc->data = dma_map_single(port->netdev->dev.parent, data,
 					    RX_BUFF_SIZE, DMA_FROM_DEVICE);
-		if (dma_mapping_error(&port->netdev->dev, desc->data)) {
+		if (dma_mapping_error(port->netdev->dev.parent, desc->data)) {
 			free_buffer(buff);
 			return -EIO;
 		}
@@ -1154,7 +1155,7 @@ static void destroy_queues(struct port *port)
 			struct desc *desc = rx_desc_ptr(port, i);
 			buffer_t *buff = port->rx_buff_tab[i];
 			if (buff) {
-				dma_unmap_single(&port->netdev->dev,
+				dma_unmap_single(port->netdev->dev.parent,
 						 desc->data - NET_IP_ALIGN,
 						 RX_BUFF_SIZE, DMA_FROM_DEVICE);
 				free_buffer(buff);
-- 
1.8.3.2



From jogo at openwrt.org  Sat Jul 20 06:15:38 2013
From: jogo at openwrt.org (Jonas Gorski)
Date: Sat, 20 Jul 2013 12:15:38 +0200
Subject: [PATCH 1/2] arm: ixp4xx: set cohorent_dma_mask for ethernet platform
 devices
In-Reply-To: <1374315339-31469-1-git-send-email-jogo@openwrt.org>
References: <1374315339-31469-1-git-send-email-jogo@openwrt.org>
Message-ID: <1374315339-31469-2-git-send-email-jogo@openwrt.org>

ARM requires the cohorent_dma_mask set, so set it for the platform
devices so that the ethernet driver has access to it.

Signed-off-by: Jonas Gorski <jogo at openwrt.org>
---
 arch/arm/mach-ixp4xx/fsg-setup.c     | 2 ++
 arch/arm/mach-ixp4xx/goramo_mlr.c    | 2 ++
 arch/arm/mach-ixp4xx/ixdp425-setup.c | 3 +++
 arch/arm/mach-ixp4xx/nas100d-setup.c | 1 +
 arch/arm/mach-ixp4xx/nslu2-setup.c   | 1 +
 arch/arm/mach-ixp4xx/omixp-setup.c   | 3 +++
 arch/arm/mach-ixp4xx/vulcan-setup.c  | 2 ++
 7 files changed, 14 insertions(+)

diff --git a/arch/arm/mach-ixp4xx/fsg-setup.c b/arch/arm/mach-ixp4xx/fsg-setup.c
index 429966b7..c120e78 100644
--- a/arch/arm/mach-ixp4xx/fsg-setup.c
+++ b/arch/arm/mach-ixp4xx/fsg-setup.c
@@ -142,12 +142,14 @@ static struct platform_device fsg_eth[] = {
 		.id			= IXP4XX_ETH_NPEB,
 		.dev = {
 			.platform_data	= fsg_plat_eth,
+			.coherent_dma_mask = DMA_BIT_MASK(32),
 		},
 	}, {
 		.name			= "ixp4xx_eth",
 		.id			= IXP4XX_ETH_NPEC,
 		.dev = {
 			.platform_data	= fsg_plat_eth + 1,
+			.coherent_dma_mask = DMA_BIT_MASK(32),
 		},
 	}
 };
diff --git a/arch/arm/mach-ixp4xx/goramo_mlr.c b/arch/arm/mach-ixp4xx/goramo_mlr.c
index e54ff49..0d1b101 100644
--- a/arch/arm/mach-ixp4xx/goramo_mlr.c
+++ b/arch/arm/mach-ixp4xx/goramo_mlr.c
@@ -294,10 +294,12 @@ static struct platform_device device_eth_tab[] = {
 		.name			= "ixp4xx_eth",
 		.id			= IXP4XX_ETH_NPEB,
 		.dev.platform_data	= eth_plat,
+		.dev.coherent_dma_mask	= DMA_BIT_MASK(32),
 	}, {
 		.name			= "ixp4xx_eth",
 		.id			= IXP4XX_ETH_NPEC,
 		.dev.platform_data	= eth_plat + 1,
+		.dev.coherent_dma_mask	= DMA_BIT_MASK(32),
 	}
 };
 
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c b/arch/arm/mach-ixp4xx/ixdp425-setup.c
index 22d688b..f608629 100644
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -20,6 +20,7 @@
 #include <linux/mtd/nand.h>
 #include <linux/mtd/partitions.h>
 #include <linux/delay.h>
+#include <linux/dma-mapping.h>
 #include <asm/types.h>
 #include <asm/setup.h>
 #include <asm/memory.h>
@@ -195,10 +196,12 @@ static struct platform_device ixdp425_eth[] = {
 		.name			= "ixp4xx_eth",
 		.id			= IXP4XX_ETH_NPEB,
 		.dev.platform_data	= ixdp425_plat_eth,
+		.dev.coherent_dma_mask	= DMA_BIT_MASK(32),
 	}, {
 		.name			= "ixp4xx_eth",
 		.id			= IXP4XX_ETH_NPEC,
 		.dev.platform_data	= ixdp425_plat_eth + 1,
+		.dev.coherent_dma_mask	= DMA_BIT_MASK(32),
 	}
 };
 
diff --git a/arch/arm/mach-ixp4xx/nas100d-setup.c b/arch/arm/mach-ixp4xx/nas100d-setup.c
index ed667ce..59654f3 100644
--- a/arch/arm/mach-ixp4xx/nas100d-setup.c
+++ b/arch/arm/mach-ixp4xx/nas100d-setup.c
@@ -170,6 +170,7 @@ static struct platform_device nas100d_eth[] = {
 		.name			= "ixp4xx_eth",
 		.id			= IXP4XX_ETH_NPEB,
 		.dev.platform_data	= nas100d_plat_eth,
+		.dev.coherent_dma_mask	= DMA_BIT_MASK(32),
 	}
 };
 
diff --git a/arch/arm/mach-ixp4xx/nslu2-setup.c b/arch/arm/mach-ixp4xx/nslu2-setup.c
index 7e55236..ff078d2 100644
--- a/arch/arm/mach-ixp4xx/nslu2-setup.c
+++ b/arch/arm/mach-ixp4xx/nslu2-setup.c
@@ -182,6 +182,7 @@ static struct platform_device nslu2_eth[] = {
 		.name			= "ixp4xx_eth",
 		.id			= IXP4XX_ETH_NPEB,
 		.dev.platform_data	= nslu2_plat_eth,
+		.dev.coherent_dma_mask	= DMA_BIT_MASK(32),
 	}
 };
 
diff --git a/arch/arm/mach-ixp4xx/omixp-setup.c b/arch/arm/mach-ixp4xx/omixp-setup.c
index 75ef03d..b79cd51 100644
--- a/arch/arm/mach-ixp4xx/omixp-setup.c
+++ b/arch/arm/mach-ixp4xx/omixp-setup.c
@@ -17,6 +17,7 @@
 #include <linux/serial_8250.h>
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/partitions.h>
+#include <linux/dma-mapping.h>
 #ifdef CONFIG_LEDS_CLASS
 #include <linux/leds.h>
 #endif
@@ -190,10 +191,12 @@ static struct platform_device ixdp425_eth[] = {
 		.name			= "ixp4xx_eth",
 		.id			= IXP4XX_ETH_NPEB,
 		.dev.platform_data	= ixdp425_plat_eth,
+		.dev.coherent_dma_mask	= DMA_BIT_MASK(32),
 	}, {
 		.name			= "ixp4xx_eth",
 		.id			= IXP4XX_ETH_NPEC,
 		.dev.platform_data	= ixdp425_plat_eth + 1,
+		.dev.coherent_dma_mask	= DMA_BIT_MASK(32),
 	},
 };
 
diff --git a/arch/arm/mach-ixp4xx/vulcan-setup.c b/arch/arm/mach-ixp4xx/vulcan-setup.c
index d599e35..162d71f 100644
--- a/arch/arm/mach-ixp4xx/vulcan-setup.c
+++ b/arch/arm/mach-ixp4xx/vulcan-setup.c
@@ -139,6 +139,7 @@ static struct platform_device vulcan_eth[] = {
 		.id			= IXP4XX_ETH_NPEB,
 		.dev = {
 			.platform_data	= &vulcan_plat_eth[0],
+			.coherent_dma_mask = DMA_BIT_MASK(32),
 		},
 	},
 	[1] = {
@@ -146,6 +147,7 @@ static struct platform_device vulcan_eth[] = {
 		.id			= IXP4XX_ETH_NPEC,
 		.dev = {
 			.platform_data	= &vulcan_plat_eth[1],
+			.coherent_dma_mask = DMA_BIT_MASK(32),
 		},
 	},
 };
-- 
1.8.3.2



From jogo at openwrt.org  Sat Jul 20 06:15:37 2013
From: jogo at openwrt.org (Jonas Gorski)
Date: Sat, 20 Jul 2013 12:15:37 +0200
Subject: [PATCH 0/2] net: fix ixp4xx_eth
Message-ID: <1374315339-31469-1-git-send-email-jogo@openwrt.org>

This patchset aims at fixing ethernet for ixp4xx, which is broken since
3.7. It is basedon discussion to the patch from Krzysztof Halasa [1],
following Russel King's suggestion.

This patchset is currently in use at OpenWrt and successfully tested
on Linksys NSLU2.

These patches are independent of each other, so they could go each in
a different tree or both in the same, and the order does not matter.

[1] https://patchwork.kernel.org/patch/2325151/

Jonas Gorski (2):
  arm: ixp4xx: set cohorent_dma_mask for ethernet platform devices
  net: ixp4xx_eth: use parent device for dma allocations

 arch/arm/mach-ixp4xx/fsg-setup.c         |  2 ++
 arch/arm/mach-ixp4xx/goramo_mlr.c        |  2 ++
 arch/arm/mach-ixp4xx/ixdp425-setup.c     |  3 +++
 arch/arm/mach-ixp4xx/nas100d-setup.c     |  1 +
 arch/arm/mach-ixp4xx/nslu2-setup.c       |  1 +
 arch/arm/mach-ixp4xx/omixp-setup.c       |  3 +++
 arch/arm/mach-ixp4xx/vulcan-setup.c      |  2 ++
 drivers/net/ethernet/xscale/ixp4xx_eth.c | 23 ++++++++++++-----------
 8 files changed, 26 insertions(+), 11 deletions(-)

-- 
1.8.3.2



From jic23 at kernel.org  Sat Jul 20 06:43:42 2013
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sat, 20 Jul 2013 11:43:42 +0100
Subject: [PATCH v6 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <1374226039-16943-3-git-send-email-oleksandr.kozaruk@ti.com>
References: <1374226039-16943-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1374226039-16943-3-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <51EA69DE.4080908@kernel.org>

On 07/19/2013 10:27 AM, Oleksandr Kozaruk wrote:
> The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
> known also as Phoenix and PhoenixLite.
>
> The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
> respectively. Some channels have current source and are used for
> measuring voltage drop on resistive load for detecting battery ID
> resistance, or measuring voltage drop on NTC resistors for external
> temperature measurements. Some channels measure voltage, (i.e. battery
> voltage), and have voltage dividers, thus, capable to scale voltage.
> Some channels are dedicated for measuring die temperature.
>
> Some channels are calibrated in 2 points, having offsets from ideal
> values kept in trim registers. This is used to correct measurements.
>
> The differences between GPADC in TWL6030 and TWL6032:
> - 10 bit vs 12 bit ADC;
> - 17 vs 19 channels;
> - channels have different purpose(i.e. battery voltage
>   channel 8 vs channel 18);
> - trim values are interpreted differently.
>
> Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
> Girish S Ghongdemath.
>
> Signed-off-by: Balaji T K <balajitk at ti.com>
> Signed-off-by: Graeme Gregory <gg at slimlogic.co.uk>
> Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
A few little bits and bobs inline.

My only major query is about the lack of info for the temperature
channels.  How do you convert these to useful real world units?

Jonathan

> ---
>  drivers/iio/adc/Kconfig         |  14 +
>  drivers/iio/adc/Makefile        |   1 +
>  drivers/iio/adc/twl6030-gpadc.c | 991 ++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 1006 insertions(+)
>  create mode 100644 drivers/iio/adc/twl6030-gpadc.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index ab0767e6..3172461 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -150,6 +150,20 @@ config TI_AM335X_ADC
>  	  Say yes here to build support for Texas Instruments ADC
>  	  driver which is also a MFD client.
>
> +config TWL6030_GPADC
> +	tristate "TWL6030 GPADC (General Purpose A/D Converter) Support"
> +	depends on TWL4030_CORE
> +	default n
> +	help
> +	  Say yes here if you want support for the TWL6030/TWL6032 General
> +	  Purpose A/D Converter. This will add support for battery type
> +	  detection, battery voltage and temperature measurement, die
> +	  temperature measurement, system supply voltage, audio accessory,
> +	  USB ID detection.
> +
> +	  This driver can also be built as a module. If so, the module will be
> +	  called twl6030-gpadc.
> +
>  config VIPERBOARD_ADC
>  	tristate "Viperboard ADC support"
>  	depends on MFD_VIPERBOARD && USB
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 0a825be..996ba09 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -16,4 +16,5 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
>  obj-$(CONFIG_MAX1363) += max1363.o
>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
> +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
>  obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
> diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
> new file mode 100644
> index 0000000..b42cfd6
> --- /dev/null
> +++ b/drivers/iio/adc/twl6030-gpadc.c
> @@ -0,0 +1,991 @@
> +/*
> + * TWL6030 GPADC module driver
> + *
> + * Copyright (C) 2009-2013 Texas Instruments Inc.
> + * Nishant Kamat <nskamat at ti.com>
> + * Balaji T K <balajitk at ti.com>
> + * Graeme Gregory <gg at slimlogic.co.uk>
> + * Girish S Ghongdemath <girishsg at ti.com>
> + * Ambresh K <ambresh at ti.com>
> + * Oleksandr Kozaruk <oleksandr.kozaruk at ti.com
> + *
> + * Based on twl4030-madc.c
> + * Copyright (C) 2008 Nokia Corporation
> + * Mikko Ylinen <mikko.k.ylinen at nokia.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA
> + *
> + */
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of_platform.h>
> +#include <linux/i2c/twl.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +
> +#define DRIVER_NAME		"twl6030_gpadc"
> +
> +#define TWL6030_GPADC_MAX_CHANNELS 17
> +#define TWL6032_GPADC_MAX_CHANNELS 19
> +
> +#define TWL6030_GPADC_CTRL_P1			0x05
> +
> +#define TWL6032_GPADC_GPSELECT_ISB		0x07
> +#define TWL6032_GPADC_CTRL_P1			0x08
> +
> +#define TWL6032_GPADC_GPCH0_LSB			0x0d
> +#define TWL6032_GPADC_GPCH0_MSB			0x0e
> +
> +#define TWL6030_GPADC_CTRL_P1_SP1		BIT(3)
> +
> +#define TWL6030_GPADC_GPCH0_LSB			(0x29)
> +
> +#define TWL6030_GPADC_RT_SW1_EOC_MASK		BIT(5)
> +
> +#define TWL6030_GPADC_TRIM1			0xCD
> +
> +#define TWL6030_REG_TOGGLE1			0x90
> +#define TWL6030_GPADCS				BIT(1)
> +#define TWL6030_GPADCR				BIT(0)
> +
> +/**
> + * struct twl6030_chnl_calib - channel calibration
> + * @gain:		slope coefficient for ideal curve
> + * @gain_error:		gain error
> + * @offset_error:	offset of the real curve
> + */
> +struct twl6030_chnl_calib {
> +	s32 gain;
> +	s32 gain_error;
> +	s32 offset_error;
> +};
> +
> +/**
> + * struct twl6030_ideal_code - GPADC calibration parameters
> + * GPADC is calibrated in two points: close to the beginning and
> + * to the and of the measurable input range
> + *
> + * @code1:	ideal code for the input at the beginning
> + * @code2:	ideal code for at the end of the range
> + * @volt1:	voltage input at the beginning(low voltage)
> + * @volt2:	voltage input at the end(high voltage)
> + */
> +struct twl6030_ideal_code {
> +	u16 code1;
> +	u16 code2;
> +	u16 volt1;
> +	u16 volt2;
> +};
> +
> +struct twl6030_gpadc_data;
> +
> +/**
> + * struct twl6030_gpadc_platform_data - platform specific data
> + * @nchannels:		number of GPADC channels
> + * @iio_channels:	iio channels
> + * @twl6030_ideal:	pointer to calibration parameters
> + * @start_conversion:	pointer to ADC start conversion function
> + * @channel_to_reg	pointer to ADC function to convert channel to
> + *			register address for reading conversion result
> + * @calibrate:		pointer to calibration function
> + */
> +struct twl6030_gpadc_platform_data {
> +	const int nchannels;
> +	const struct iio_chan_spec *iio_channels;
> +	const struct twl6030_ideal_code *ideal;
> +	int (*start_conversion)(int channel);
> +	u8 (*channel_to_reg)(int channel);
> +	int (*calibrate)(struct twl6030_gpadc_data *gpadc);
> +};
> +
> +/**
> + * struct twl6030_gpadc_data - GPADC data
> + * @dev:		device pointer
> + * @lock:		mutual exclusion lock for the structure
> + * @irq_complete:	completion to signal end of conversion
> + * @twl6030_cal_tbl:	pointer to calibration data for each
> + *			channel with gain error and offset
> + * @pdata:		pointer to device specific data
> + */
> +struct twl6030_gpadc_data {
> +	struct device	*dev;
> +	struct mutex	lock;
> +	struct completion	irq_complete;
> +	struct twl6030_chnl_calib	*twl6030_cal_tbl;
> +	const struct twl6030_gpadc_platform_data *pdata;
> +};
> +
> +/*
> + * channels 11, 12, 13, 15 and 16 have no calibration data
> + * calibration offset is same for channels 1, 3, 4, 5
> + *
> + * The data is taken from GPADC_TRIM registers description.
> + * GPADC_TRIM registers keep difference between the code measured
> + * at volt1 and volt2 input voltages and corresponding code1 and code2
> + */
> +static const struct twl6030_ideal_code
> +	twl6030_ideal[TWL6030_GPADC_MAX_CHANNELS] = {
> +	[0] = { /* ch 0, external, battery type, resistor value */
> +		.code1 = 116,
> +		.code2 = 745,
> +		.volt1 = 141,
> +		.volt2 = 910,
> +	},
> +	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
> +		.code1 = 82,
> +		.code2 = 900,
> +		.volt1 = 100,
> +		.volt2 = 1100,
> +	},
> +	[2] = { /* ch 2, external, audio accessory/general purpose */
> +		.code1 = 55,
> +		.code2 = 818,
> +		.volt1 = 101,
> +		.volt2 = 1499,
> +	},
> +	[3] = { /* ch 3, external, general purpose */
> +		.code1 = 82,
> +		.code2 = 900,
> +		.volt1 = 100,
> +		.volt2 = 1100,
> +	},
> +	[4] = { /* ch 4, external, temperature measurement/general purpose */
> +		.code1 = 82,
> +		.code2 = 900,
> +		.volt1 = 100,
> +		.volt2 = 1100,
> +	},
> +	[5] = { /* ch 5, external, general purpose */
> +		.code1 = 82,
> +		.code2 = 900,
> +		.volt1 = 100,
> +		.volt2 = 1100,
> +	},
> +	[6] = { /* ch 6, external, general purpose */
> +		.code1 = 82,
> +		.code2 = 900,
> +		.volt1 = 100,
> +		.volt2 = 1100,
> +	},
> +	[7] = { /* ch 7, internal, main battery */
> +		.code1 = 614,
> +		.code2 = 941,
> +		.volt1 = 3001,
> +		.volt2 = 4599,
> +	},
> +	[8] = { /* ch 8, internal, backup battery */
> +		.code1 = 82,
> +		.code2 = 688,
> +		.volt1 = 501,
> +		.volt2 = 4203,
> +	},
> +	[9] = { /* ch 9, internal, external charger input */
> +		.code1 = 182,
> +		.code2 = 818,
> +		.volt1 = 2001,
> +		.volt2 = 8996,
> +	},
> +	[10] = { /* ch 10, internal, VBUS */
> +		.code1 = 149,
> +		.code2 = 818,
> +		.volt1 = 1001,
> +		.volt2 = 5497,
> +	},
> +	[11] = {},	/* ch 11, internal, VBUS charging current */
> +	[12] = {},	/* ch 12, internal, Die temperature */
> +	[13] = {},	/* ch 13, internal, Die temperature */
> +	[14] = { /* ch 14, internal, USB ID line */
> +		.code1 = 48,
> +		.code2 = 714,
> +		.volt1 = 323,
> +		.volt2 = 4800,
> +	},
> +	[15] = {},	/* ch 15, internal, test network */
> +	[16] = {},	/* ch 16, internal, test network */
> +};
> +
> +static const struct twl6030_ideal_code
> +			twl6032_ideal[TWL6032_GPADC_MAX_CHANNELS] = {
> +	[0] = { /* ch 0, external, battery type, resistor value */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 440,
> +		.volt2 = 1000,
> +	},
> +	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 440,
> +		.volt2 = 1000,
> +	},
> +	[2] = { /* ch 2, external, audio accessory/general purpose */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 660,
> +		.volt2 = 1500,
> +	},
> +	[3] = { /* ch 3, external, temperature with external diode/general
> +								purpose */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 440,
> +		.volt2 = 1000,
> +	},
> +	[4] = { /* ch 4, external, temperature measurement/general purpose */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 440,
> +		.volt2 = 1000,
> +	},
> +	[5] = { /* ch 5, external, general purpose */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 440,
> +		.volt2 = 1000,
> +	},
> +	[6] = { /* ch 6, external, general purpose */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 440,
> +		.volt2 = 1000,
> +	},
> +	[7] = { /* ch7, internal, system supply */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 2200,
> +		.volt2 = 5000,
> +	},
> +	[8] = { /* ch8, internal, backup battery */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 2200,
> +		.volt2 = 5000,
> +	},
> +	[9] = { /* ch 9, internal, external charger input */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 3960,
> +		.volt2 = 9000,
> +	},
> +	[10] = { /* ch10, internal, VBUS */
> +		.code1 = 150,
> +		.code2 = 751,
> +		.volt1 = 1000,
> +		.volt2 = 5000,
> +	},
> +	[11] = { /* ch 11, internal, VBUS DC-DC output current */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 660,
> +		.volt2 = 1500,
> +	},
> +	[12] = { /* ch 12, internal, Die temperature */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 440,
> +		.volt2 = 1000,
> +	},
> +	[13] = { /* ch 13, internal, Die temperature */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 440,
> +		.volt2 = 1000,
> +	},
> +	[14] = { /* ch 14, internal, USB ID line */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 2420,
> +		.volt2 = 5500,
> +	},
> +	[15] = {},	/* ch 15, internal, test network */
> +	[16] = {},	/* ch 16, internal, test network */
> +	[17] = {},	/* ch 17, internal, battery charging current */
> +	[18] = { /* ch 18, internal, battery voltage */
> +		.code1 = 1441,
> +		.code2 = 3276,
> +		.volt1 = 2200,
> +		.volt2 = 5000,
> +	},
> +};
> +
> +static inline int twl6030_gpadc_write(u8 reg, u8 val)
> +{
> +	return twl_i2c_write_u8(TWL6030_MODULE_GPADC, val, reg);
> +}
> +
> +static inline int twl6030_gpadc_read(u8 reg, u8 *val)
> +{
> +
> +	return twl_i2c_read(TWL6030_MODULE_GPADC, val, reg, 2);
> +}
> +
> +static int twl6030_gpadc_enable_irq(u8 mask)
> +{
> +	int ret;
> +
> +	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_LINE_B);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_STS_B);
> +
> +	return ret;
> +}
> +
> +static void twl6030_gpadc_disable_irq(u8 mask)
> +{
> +	twl6030_interrupt_mask(mask, REG_INT_MSK_LINE_B);
> +	twl6030_interrupt_mask(mask, REG_INT_MSK_STS_B);
> +}
> +
> +static irqreturn_t twl6030_gpadc_irq_handler(int irq, void *indio_dev)
> +{
> +	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
> +
> +	complete(&gpadc->irq_complete);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int twl6030_start_conversion(int channel)
> +{
> +	return twl6030_gpadc_write(TWL6030_GPADC_CTRL_P1,
> +					TWL6030_GPADC_CTRL_P1_SP1);
> +}
> +
> +static int twl6032_start_conversion(int channel)
> +{
> +	int ret;
> +
> +	ret = twl6030_gpadc_write(TWL6032_GPADC_GPSELECT_ISB, channel);
> +	if (ret)
> +		return ret;
> +
> +	return twl6030_gpadc_write(TWL6032_GPADC_CTRL_P1,
> +						TWL6030_GPADC_CTRL_P1_SP1);
> +}
> +
> +static u8 twl6030_channel_to_reg(int channel)
> +{
> +	return TWL6030_GPADC_GPCH0_LSB + 2 * channel;
> +}
> +
> +static u8 twl6032_channel_to_reg(int channel)
> +{
> +	/*
> +	 * for any prior chosen channel, when the conversion is ready
> +	 * the result is avalable in GPCH0_LSB, GPCH0_MSB.
> +	 */
> +
> +	return TWL6032_GPADC_GPCH0_LSB;
> +}
> +
> +static int twl6030_channel_calibrated(const struct twl6030_gpadc_platform_data
> +		*pdata, int channel)
> +{
> +	/* not calibrated channels have 0 in all structure members */
> +	return pdata->ideal[channel].code2;
> +}
> +
> +static int twl6030_gpadc_make_correction(struct twl6030_gpadc_data *gpadc,
> +		int channel, int raw_code)
> +{
> +	int corrected_code;
> +
> +	corrected_code = ((raw_code * 1000) -
> +		gpadc->twl6030_cal_tbl[channel].offset_error) /
> +		gpadc->twl6030_cal_tbl[channel].gain_error;
> +
> +	return corrected_code;
> +}
> +
> +static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
> +		int channel, int *res)
> +{
> +	u8 reg = gpadc->pdata->channel_to_reg(channel);
> +	__le16 val;
> +	int raw_code;
> +	int ret;
> +
> +	ret = twl6030_gpadc_read(reg, (u8 *)&val);
> +	if (ret) {
> +		dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
> +		return ret;
> +	}
> +
> +	raw_code = le16_to_cpu(val);
> +	dev_dbg(gpadc->dev, "GPADC raw code: %d", raw_code);
> +
> +	if (twl6030_channel_calibrated(gpadc->pdata, channel))
> +		*res = twl6030_gpadc_make_correction(gpadc, channel, raw_code);
> +	else
> +		*res = raw_code;
> +
> +	return ret;
> +}
> +
> +static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
> +		int channel, int *val)
> +{
> +	int corrected_code;
> +	int channel_value;
> +	int ret;
> +
> +	ret = twl6030_gpadc_get_raw(gpadc, channel, &corrected_code);
> +	if (ret)
> +		return ret;
> +
> +	channel_value = corrected_code *
> +			gpadc->twl6030_cal_tbl[channel].gain;
> +
> +	/* Shift back into mV range */
> +	channel_value /= 1000;
> +
> +	dev_dbg(gpadc->dev, "GPADC corrected code: %d", corrected_code);
> +	dev_dbg(gpadc->dev, "GPADC value: %d", channel_value);
> +
> +	*val = channel_value;
> +
> +	return ret;
> +}
> +
> +static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
> +			     const struct iio_chan_spec *chan,
> +			     int *val, int *val2, long mask)
> +{
> +	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
> +	int ret = -EINVAL;
I'm suprised you didn't get a warning about the assigment above
being pointless as you overwrite ret just below.

> +	long timeout;
> +
> +	mutex_lock(&gpadc->lock);
> +
> +	ret = gpadc->pdata->start_conversion(chan->channel);
> +	if (ret) {
> +		dev_err(gpadc->dev, "failed to start conversion\n");
> +		goto err;
> +	}
> +	/* wait for conversion to complete */
> +	timeout = wait_for_completion_interruptible_timeout(
> +				&gpadc->irq_complete, msecs_to_jiffies(5000));
timeout == 0 would be a little clearer.
> +	if (!timeout) {
> +		ret = -ETIMEDOUT;
> +		goto err;
> +	} else if (timeout < 0) {
> +		goto err;
> +		ret = -EINTR;
> +	}
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
> +		ret = ret ? -EIO : IIO_VAL_INT;
> +		break;
> +
> +	case IIO_CHAN_INFO_PROCESSED:
> +		ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
> +		ret = ret ? -EIO : IIO_VAL_INT;
> +		break;
> +
> +	default:
> +		break;
> +	}
> +err:
> +	mutex_unlock(&gpadc->lock);
> +
> +	return ret;
> +}
> +
> +/*
> + * The GPADC channels are calibrated using a two point calibration method.
> + * The channels measured with two known values: volt1 and volt2, and
> + * ideal corresponding output codes are known: code1, code2.
> + * The difference(d1, d2) between ideal and measured codes stored in trim
> + * registers.
> + * The goal is to find offset and gain of the real curve for each calibrated
> + * channel.
> + * gain: k = 1 + ((d2 - d1) / (x2 - x1))
> + * offset: b = d1 + (k - 1) * x1
> + */
> +static void twl6030_calibrate_channel(struct twl6030_gpadc_data *gpadc,
> +					int channel, int d1, int d2)
> +{
> +	int b, k, gain, x1, x2;
> +	const struct twl6030_ideal_code *ideal = gpadc->pdata->ideal;
> +
> +	/* Gain */
> +	gain = ((ideal[channel].volt2 - ideal[channel].volt1) * 1000) /
> +		(ideal[channel].code2 - ideal[channel].code1);
> +
> +	x1 = ideal[channel].code1;
> +	x2 = ideal[channel].code2;
> +
> +	/* k - real curve gain */
> +	k = 1000 + (((d2 - d1) * 1000) / (x2 - x1));
> +
> +	/* b - offset of the real curve gain */
> +	b = (d1 * 1000) - (k - 1000) * x1;
> +
> +	gpadc->twl6030_cal_tbl[channel].gain = gain;
> +	gpadc->twl6030_cal_tbl[channel].gain_error = k;
> +	gpadc->twl6030_cal_tbl[channel].offset_error = b;
> +
> +	dev_dbg(gpadc->dev, "GPADC d1   for Chn: %d = %d\n", channel, d1);
> +	dev_dbg(gpadc->dev, "GPADC d2   for Chn: %d = %d\n", channel, d2);
> +	dev_dbg(gpadc->dev, "GPADC x1   for Chn: %d = %d\n", channel, x1);
> +	dev_dbg(gpadc->dev, "GPADC x2   for Chn: %d = %d\n", channel, x2);
> +	dev_dbg(gpadc->dev, "GPADC Gain for Chn: %d = %d\n", channel, gain);
> +	dev_dbg(gpadc->dev, "GPADC k    for Chn: %d = %d\n", channel, k);
> +	dev_dbg(gpadc->dev, "GPADC b    for Chn: %d = %d\n", channel, b);
> +}
> +
> +static inline int twl6030_gpadc_get_trim_offset(s8 d)
> +{
> +	/*
> +	 * XXX NOTE!
> +	 * bit 0 - sign, bit 7 - reserved, 6..1 - trim value
> +	 * though, the documentation states that trim value
> +	 * is absolute value, the correct conversion results are
> +	 * obtained if the value is interpreted as 2's complement.
> +	 */
> +	__u32 temp = ((d & 0x7f) >> 1) | ((d & 1) << 6);
> +
> +	return sign_extend32(temp, 6);
> +}
> +
> +static int twl6030_calibration(struct twl6030_gpadc_data *gpadc)
> +{
> +	int ret;
> +	int chn;
> +	u8 trim_regs[TWL6030_GPADC_MAX_CHANNELS];
> +	s8 d1, d2;
> +
> +	/*
> +	 * for calibration two measurements have been performed at
> +	 * factory, for some channels, during the production test and
> +	 * have been stored in registers. This two stored values are
> +	 * used to correct the measurements. The values represent
> +	 * offsets for the given input from the output on ideal curve.
> +	 */
> +	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs,
> +			TWL6030_GPADC_TRIM1, 16);
> +	if (ret < 0) {
> +		dev_err(gpadc->dev, "calibration failed\n");
> +		return ret;
> +	}
> +
> +	for (chn = 0; chn < TWL6030_GPADC_MAX_CHANNELS; chn++) {
> +
> +		switch (chn) {
> +		case 0:
> +			d1 = trim_regs[0];
> +			d2 = trim_regs[1];
> +			break;
> +		case 1:
> +		case 3:
> +		case 4:
> +		case 5:
> +		case 6:
> +			d1 = trim_regs[4];
> +			d2 = trim_regs[5];
> +			break;
> +		case 2:
> +			d1 = trim_regs[12];
> +			d2 = trim_regs[13];
> +			break;
> +		case 7:
> +			d1 = trim_regs[6];
> +			d2 = trim_regs[7];
> +			break;
> +		case 8:
> +			d1 = trim_regs[2];
> +			d2 = trim_regs[3];
> +			break;
> +		case 9:
> +			d1 = trim_regs[8];
> +			d2 = trim_regs[9];
> +			break;
> +		case 10:
> +			d1 = trim_regs[10];
> +			d2 = trim_regs[11];
> +			break;
> +		case 14:
> +			d1 = trim_regs[14];
> +			d2 = trim_regs[15];
> +			break;
> +		default:
> +			continue;
> +		}
> +
> +		d1 = twl6030_gpadc_get_trim_offset(d1);
> +		d2 = twl6030_gpadc_get_trim_offset(d2);
> +
> +		twl6030_calibrate_channel(gpadc, chn, d1, d2);
> +	}
> +
> +	return 0;
> +}
> +
> +static int twl6032_get_trim_value(u8 *trim_regs, unsigned int reg0,
> +		unsigned int reg1, unsigned int mask0, unsigned int mask1,
> +		unsigned int shift0)
> +{
> +	int val;
> +
> +	val = (trim_regs[reg0] & mask0) << shift0;
> +	val |= (trim_regs[reg1] & mask1) >> 1;
> +	if (trim_regs[reg1] & 0x01)
> +		val = -val;
> +
> +	return val;
> +}
> +
> +static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
> +{
> +	int chn, d1 = 0, d2 = 0, temp;
> +	u8 trim_regs[17];
Use the nice define you put in above instead of a mystical 17 ;)
> +	int ret;
> +
> +	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
> +			TWL6030_GPADC_TRIM1, 16);
> +	if (ret < 0) {
> +		dev_err(gpadc->dev, "calibration failed\n");
> +		return ret;
> +	}
> +
> +	/*
> +	 * Loop to calculate the value needed for returning voltages from
> +	 * GPADC not values.
> +	 *
> +	 * gain is calculated to 3 decimal places fixed point.
> +	 */
> +	for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
> +
> +		switch (chn) {
> +		case 0:
> +		case 1:
> +		case 2:
> +		case 3:
> +		case 4:
> +		case 5:
> +		case 6:
> +		case 11:
> +		case 12:
> +		case 13:
> +		case 14:
Much tidier.
> +			d1 = twl6032_get_trim_value(trim_regs, 3, 1, 0x1f,
> +								0x06, 2);
> +			d2 = twl6032_get_trim_value(trim_regs, 4, 2, 0x3f,
> +								0x06, 2);
> +			break;
> +		case 8:
> +			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x1f,
> +								0x06, 2);
> +			d1 = temp + twl6032_get_trim_value(trim_regs, 8, 7,
> +								0x18, 0x1E, 1);
> +
> +			temp = twl6032_get_trim_value(trim_regs, 4, 2, 0x3F,
> +								0x06, 2);
> +			d2 = temp + twl6032_get_trim_value(trim_regs, 10, 8,
> +								0x1F, 0x06, 2);
> +			break;
> +		case 9:
> +			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x1f,
> +								0x06, 2);
> +			d1 = temp + twl6032_get_trim_value(trim_regs, 14, 12,
> +								0x18, 0x1E, 1);
> +
> +			temp = twl6032_get_trim_value(trim_regs, 4, 2, 0x3f,
> +								0x06, 2);
> +			d2 = temp + twl6032_get_trim_value(trim_regs, 16, 14,
> +								0x1F, 0x06, 1);
> +			break;
> +		case 10:
> +			d1 = twl6032_get_trim_value(trim_regs, 11, 9, 0x0f,
> +								0x0E, 3);
> +			d2 = twl6032_get_trim_value(trim_regs, 15, 13, 0x0f,
> +								0x0E, 3);
> +			break;
> +		case 7:
> +		case 18:
> +			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x1f,
> +								0x06, 2);
> +
> +			d1 = (trim_regs[5] & 0x7E) >> 1;
> +			if (trim_regs[5] & 0x01)
> +				d1 = -d1;
> +			d1 += temp;
> +
> +			temp = twl6032_get_trim_value(trim_regs, 4, 2, 0x3f,
> +								0x06, 2);
> +
> +			d2 = (trim_regs[6] & 0xFE) >> 1;
> +			if (trim_regs[6] & 0x01)
> +				d2 = -d2;
> +
> +			d2 += temp;
> +			break;
> +		default:
> +			/* No data for other channels */
> +			continue;
> +		}
> +
> +		twl6030_calibrate_channel(gpadc, chn, d1, d2);
> +	}
> +
> +	return 0;
> +}
> +
> +#define TWL6030_GPADC_CHAN(chn, _type, chan_info) {	\
> +	.type = _type,					\
> +	.channel = chn,					\
> +	.info_mask_separate = BIT(chan_info),		\
> +	.indexed = 1,					\
> +}
> +


Why list these at all?  I see they are no longer visible from
userspace, but they are still taking up memory etc without I
think ever being used?
> +/* internal test network channel */
> +#define TWL6030_GPADC_TEST_CHAN(chn, chan_info) {	\
> +	.type = IIO_VOLTAGE,				\
> +	.channel = chn,					\
> +	.indexed = 1,					\
> +}
> +
> +static const struct iio_chan_spec twl6030_gpadc_iio_channels[] = {
> +	TWL6030_GPADC_CHAN(0, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(1, IIO_TEMP, IIO_CHAN_INFO_RAW),
So we have no other information about the temp channels other than
raw adc counts?  If so, how are these useful?  I guess you might
be intending to use iio-hwmon to get these into hwmon the use
lm-sensors config files to convert to something useful.
Otherwise, you probably want to get the board specific info on
the calibration of these in here to make the data available to userspace
in a useful format...

> +	TWL6030_GPADC_CHAN(2, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(3, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(4, IIO_TEMP, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(5, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(6, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(7, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(8, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(9, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(10, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(11, IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(12, IIO_TEMP, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(13, IIO_TEMP, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(14, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_TEST_CHAN(15, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_TEST_CHAN(16, IIO_CHAN_INFO_RAW),
> +};
> +
> +static const struct iio_chan_spec twl6032_gpadc_iio_channels[] = {
> +	TWL6030_GPADC_CHAN(0, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(1, IIO_TEMP, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(2, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(3, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(4, IIO_TEMP, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(5, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(6, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(7, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(8, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(9, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(10, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(11, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_CHAN(12, IIO_TEMP, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(13, IIO_TEMP, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(14, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +	TWL6030_GPADC_TEST_CHAN(15, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_TEST_CHAN(16, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(17, IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
> +	TWL6030_GPADC_CHAN(18, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
> +};
> +
> +static const struct iio_info twl6030_gpadc_iio_info = {
> +	.read_raw = &twl6030_gpadc_read_raw,
> +	.driver_module = THIS_MODULE,
> +};
> +
> +static const struct twl6030_gpadc_platform_data twl6030_pdata = {
> +	.iio_channels = twl6030_gpadc_iio_channels,
> +	.nchannels = TWL6030_GPADC_MAX_CHANNELS,
> +	.ideal = twl6030_ideal,
> +	.start_conversion = twl6030_start_conversion,
> +	.channel_to_reg = twl6030_channel_to_reg,
> +	.calibrate = twl6030_calibration,
> +};
> +
> +static const struct twl6030_gpadc_platform_data twl6032_pdata = {
> +	.iio_channels = twl6032_gpadc_iio_channels,
> +	.nchannels = TWL6032_GPADC_MAX_CHANNELS,
> +	.ideal = twl6032_ideal,
> +	.start_conversion = twl6032_start_conversion,
> +	.channel_to_reg = twl6032_channel_to_reg,
> +	.calibrate = twl6032_calibration,
> +};
> +
> +static const struct of_device_id of_twl6030_match_tbl[] = {
> +	{
> +		.compatible = "ti,twl6030-gpadc",
> +		.data = &twl6030_pdata,
> +	},
> +	{
> +		.compatible = "ti,twl6032-gpadc",
> +		.data = &twl6032_pdata,
> +	},
> +	{ /* end */ }
> +};
> +
> +static int twl6030_gpadc_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct twl6030_gpadc_data *gpadc;
> +	const struct twl6030_gpadc_platform_data *pdata;
> +	const struct of_device_id *match;
> +	struct iio_dev *indio_dev;
> +	int irq;
> +	int ret;
> +
> +	match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
> +	if (!match)
> +		return -EINVAL;
> +
> +	pdata = match->data;
> +
> +	indio_dev = iio_device_alloc(sizeof(*gpadc));
> +	if (!indio_dev) {
> +		dev_err(dev, "failed allocating iio device\n");
> +		ret = -ENOMEM;
> +	}
> +
> +	gpadc = iio_priv(indio_dev);
> +
> +	gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
> +					sizeof(struct twl6030_chnl_calib) *
> +					pdata->nchannels, GFP_KERNEL);
Nitpick, but the following is easier to verify as correct aas it doesn't
require the reviewer to look up the type of twl6030_cal_tbl ;)

gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
				      sizeof(*(gpadc->twl6030_cal_tbl) *
				      pdata->nchannels, GFP_KERNEL);

Random aside, why is there no devm_kcalloc?

> +	if (!gpadc->twl6030_cal_tbl)
> +		goto err_free_device;
> +
> +	gpadc->dev = dev;
> +	gpadc->pdata = pdata;
> +
> +	platform_set_drvdata(pdev, indio_dev);
> +	mutex_init(&gpadc->lock);
> +	init_completion(&gpadc->irq_complete);
> +
> +	ret = pdata->calibrate(gpadc);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to read calibration registers\n");
> +		goto err_free_device;
> +	}
> +
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq < 0) {
> +		dev_err(&pdev->dev, "failed to get irq\n");
> +		goto err_free_device;
> +	}
> +
> +	ret = request_threaded_irq(irq, NULL, twl6030_gpadc_irq_handler,
> +				IRQF_ONESHOT, "twl6030_gpadc", indio_dev);
> +	if (ret) {
> +		dev_dbg(&pdev->dev, "could not request irq\n");
> +		goto err_free_device;
> +	}
> +
> +	ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
> +		goto err_free_irq;
> +	}
> +
> +	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
> +					TWL6030_REG_TOGGLE1);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to enable GPADC module\n");
> +		goto err_free_irq;
> +	}
> +
> +	indio_dev->name = DRIVER_NAME;
> +	indio_dev->dev.parent = dev;
> +	indio_dev->info = &twl6030_gpadc_iio_info;
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->channels = pdata->iio_channels;
> +	indio_dev->num_channels = pdata->nchannels;
> +
> +	ret = iio_device_register(indio_dev);
> +	if (ret)
> +		goto err_free_irq;
> +
> +	return ret;
> +
> +err_free_irq:
> +	free_irq(irq, indio_dev);
> +err_free_device:
> +	iio_device_free(indio_dev);
> +
> +	return ret;
> +}
> +
> +static int twl6030_gpadc_remove(struct platform_device *pdev)
> +{
> +	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> +
> +	twl6030_gpadc_disable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
> +	free_irq(platform_get_irq(pdev, 0), indio_dev);
> +	iio_device_unregister(indio_dev);
> +	iio_device_free(indio_dev);
> +
> +	return 0;
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int twl6030_gpadc_suspend(struct device *pdev)
> +{
> +	int ret;
> +
> +	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCR,
> +				TWL6030_REG_TOGGLE1);
> +	if (ret)
> +		dev_err(pdev, "error reseting GPADC (%d)!\n", ret);
> +
> +	return 0;
> +};
> +
> +static int twl6030_gpadc_resume(struct device *pdev)
> +{
> +	int ret;
> +
> +	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
> +				TWL6030_REG_TOGGLE1);
> +	if (ret)
> +		dev_err(pdev, "error setting GPADC (%d)!\n", ret);
> +
> +	return 0;
> +};
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(twl6030_gpadc_pm_ops, twl6030_gpadc_suspend,
> +					twl6030_gpadc_resume);
> +
> +static struct platform_driver twl6030_gpadc_driver = {
> +	.probe		= twl6030_gpadc_probe,
> +	.remove		= twl6030_gpadc_remove,
> +	.driver		= {
> +		.name	= DRIVER_NAME,
> +		.owner	= THIS_MODULE,
> +		.pm	= &twl6030_gpadc_pm_ops,
> +		.of_match_table = of_twl6030_match_tbl,
> +	},
> +};
> +
> +module_platform_driver(twl6030_gpadc_driver);
> +
> +MODULE_ALIAS("platform: " DRIVER_NAME);
> +MODULE_AUTHOR("Texas Instruments Inc.");

I would normally expect an actual person for
the module author.  Is this TI policy or simply a case of no clear single
author?  Note I believe there is no problem with having multiple
MODULE_AUTHOR lines so that everyone who made a major contribution is
included.

> +MODULE_DESCRIPTION("twl6030 ADC driver");
> +MODULE_LICENSE("GPL");
>


From jonas.jensen at gmail.com  Sat Jul 20 06:55:36 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Sat, 20 Jul 2013 12:55:36 +0200
Subject: [PATCH] net: Add MOXA ART SoCs ethernet driver
In-Reply-To: <1374140806-12485-1-git-send-email-jonas.jensen@gmail.com>
References: <1374140806-12485-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <CACmBeS0ztqKWJ1uLKhb2EZdexspTq5t0uHZfPotHiAPHfkftoA@mail.gmail.com>

I think this driver may have a bug.

After some time running ping successfully, the message "no TX space
for packet" is printed resulting in 100% packet loss.

The message is printed from .ndo_start_xmit and I think it may be
because of how priv->tx_desc_now is now set up in
moxart_mac_setup_desc_ring.

I will take a look at this and try to fix the issue.

Best regards,
Jonas


From arnd at arndb.de  Fri Jul 19 09:03:25 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Jul 2013 15:03:25 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with
 ARM CPU
In-Reply-To: <20130716151435.GB3871@linaro.org>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org>
Message-ID: <201307191503.25382.arnd@arndb.de>

On Tuesday 16 July 2013, Matt Porter wrote:

> > diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
> > new file mode 100644
> > index 0000000..638350d
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> > @@ -0,0 +1,72 @@
> > +/*
> > + * Broadcom BCM47XX / BCM53XX ARM platform code.
> > + *
> > + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> > + *
> > + * Licensed under the GNU/GPL. See COPYING for details.
> > + */
> > +
> > +/include/ "skeleton.dtsi"
> > +
> > +/ {
> > +	compatible = "brcm,bcm5301x";
> 
> Ok, this was nagging at me before I went on my very long vacation. I see
> the "brcm" vendor prefix as a real consistency problem. I noticed on the
> bcm281xx/kona family, we have been using "bcm" which is not logged in
> vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
> already established use of "brcm" before any of the bcm281xx support
> came in. Ideally, the vendor prefix should change to "bcm" since every
> reference in the family names is BCM. However, if others want the least
> amount of churn in making this consistent, we might have to go with
> "brcm" across the board.
> 
> Arnd, any thoughts here?

No strong feelings on the bcm vs brcm side, but please make it consistent.

> Last thing, compatible strings are not to have wildcards in them. See
> http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
> and note the Warning at the bottom. Also see how bcm2835.txt and
> bcm11351.txt use a specific model.

+1

	Arnd


From s.hauer at pengutronix.de  Sat Jul 20 07:16:39 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Sat, 20 Jul 2013 13:16:39 +0200
Subject: [RFC v2] ARM: i.MX pllv1: Implement set_rate
In-Reply-To: <1374308975-20596-1-git-send-email-shc_work@mail.ru>
References: <1374308975-20596-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130720111639.GA29785@pengutronix.de>

On Sat, Jul 20, 2013 at 12:29:35PM +0400, Alexander Shiyan wrote:
> This patch implements frequency change for i.MX pllv1.
> Selection of the values of the registers is not optimal, since is
> made by simple enumeration of all possible values.

You do not mention why you want to adjust the rate. Normally we've been
happy with the static values from the bootloader.

> -static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
> -		unsigned long parent_rate)
> +static unsigned long _clk_pllv1_recalc_rate(unsigned int mfi, unsigned int mfn,
> +					    unsigned int mfd, unsigned int pd,
> +					    unsigned long parent_rate)
>  {
> -	struct clk_pllv1 *pll = to_clk_pllv1(hw);
> -	long long ll;
> -	int mfn_abs;
> -	unsigned int mfi, mfn, mfd, pd;
> -	u32 reg;
>  	unsigned long rate;
> -
> -	reg = readl(pll->base);
> +	int mfn_abs = mfn;
> +	long long ll;
>  
>  	/*
>  	 * Get the resulting clock rate from a PLL register value and the input
> @@ -47,15 +45,6 @@ static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
>  	 *                        pd + 1
>  	 */
>  
> -	mfi = (reg >> 10) & 0xf;
> -	mfn = reg & 0x3ff;
> -	mfd = (reg >> 16) & 0x3ff;
> -	pd =  (reg >> 26) & 0xf;
> -
> -	mfi = mfi <= 5 ? 5 : mfi;
> -
> -	mfn_abs = mfn;
> -
>  	/*
>  	 * On all i.MXs except i.MX1 and i.MX21 mfn is a 10bit
>  	 * 2's complements number
> @@ -78,8 +67,99 @@ static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
>  	return ll;
>  }
>  
> +static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
> +		unsigned long parent_rate)
> +{
> +	struct clk_pllv1 *pll = to_clk_pllv1(hw);
> +	unsigned int mfi, mfn, mfd, pd;
> +	u32 reg = readl(pll->base);
> +
> +	/* Avoid i.MX27 TO2 SPCTL0 bug */
> +	if (cpu_is_mx27() && (mx27_revision() == IMX_CHIP_REVISION_2_0))
> +		writel(reg, pll->base);

I remember this was fixed and got lost. If you want to have fixed it
again this should be a separate paatch along with a description of the
bug in the commit log.

> +
> +	mfi = (reg >> 10) & 0xf;
> +	mfn = reg & 0x3ff;
> +	mfd = (reg >> 16) & 0x3ff;
> +	pd =  (reg >> 26) & 0xf;
> +
> +	mfi = mfi <= 5 ? 5 : mfi;
> +
> +	return _clk_pllv1_recalc_rate(mfi, mfn, mfd, pd, parent_rate);
> +}
> +
> +static void _clk_pllv1_set_rate(unsigned long rate, unsigned long parent_rate,
> +				unsigned int *reg)
> +{
> +	unsigned int pd, mfi, mfn, mfd, mfn_offs = 0;
> +	long tmp, res, best = 0;
> +
> +	pd = (parent_rate * 2 * 5) / rate;
> +	if (pd > 15)
> +		pd = 15;
> +	mfi = rate / (parent_rate * 2 * (pd + 1));
> +	if (mfi < 5)
> +		mfi = 5;
> +	if (mfi < 15) {
> +		tmp = parent_rate * 2;
> +		tmp /= pd + 1;
> +		tmp *= mfi;
> +		if (tmp / parent_rate) {
> +			mfi++;
> +			/* Use negative values */
> +			mfn_offs = 0x200;
> +		}
> +	} else if (mfi > 15)
> +		mfi = 15;

Use braces on both branches here.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From shc_work at mail.ru  Sat Jul 20 07:31:04 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 20 Jul 2013 15:31:04 +0400
Subject: [RFC v2] ARM: i.MX pllv1: Implement set_rate
In-Reply-To: <20130720111639.GA29785@pengutronix.de>
References: <1374308975-20596-1-git-send-email-shc_work@mail.ru>
 <20130720111639.GA29785@pengutronix.de>
Message-ID: <20130720153104.96b6723a20bde172a8ea1ba1@mail.ru>

On Sat, 20 Jul 2013 13:16:39 +0200
Sascha Hauer <s.hauer at pengutronix.de> wrote:

> On Sat, Jul 20, 2013 at 12:29:35PM +0400, Alexander Shiyan wrote:
> > This patch implements frequency change for i.MX pllv1.
> > Selection of the values of the registers is not optimal, since is
> > made by simple enumeration of all possible values.
> 
> You do not mention why you want to adjust the rate. Normally we've been
> happy with the static values from the bootloader.

For CPUfreq.
Only one barrier to make it workable.

[...]
> > +	/* Avoid i.MX27 TO2 SPCTL0 bug */
> > +	if (cpu_is_mx27() && (mx27_revision() == IMX_CHIP_REVISION_2_0))
> > +		writel(reg, pll->base);
> 
> I remember this was fixed and got lost. If you want to have fixed it
> again this should be a separate paatch along with a description of the
> bug in the commit log.

This part of the patch can be completely removed ;)
I'm more interested in a more efficient algorithm for finding the best
values for the PLL.

[...]

-- 
Alexander Shiyan <shc_work at mail.ru>


From linus.walleij at linaro.org  Sat Jul 20 07:34:18 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Jul 2013 13:34:18 +0200
Subject: [GIT PULL] Nomadik defconfig updates
Message-ID: <CACRpkdZxSkLrKY1rZwdbo2ZJpVqExu7GRyhWN5T8V+aR_jx2Dw@mail.gmail.com>

Hi ARM SoC folks,

now we are past -rc1 and I'd like to have these defconfig changes for
the Nomadik pulled in. It is similar in scope to the ux500 defconfig
updates I sent the other week, and all have been circulated on the
mailing list.

Please pull them in!

Yours,
Linus Walleij


The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
tags/nomadik-defconfig-for-arm-soc

for you to fetch changes up to fec57e15527ab2e3d22cfbf04f2b98f823f294ff:

  ARM: nomadik: configure for NO_HZ and HRTIMERS (2013-07-20 11:59:45 +0200)

----------------------------------------------------------------
This updates the Nomadik defconfig post-v3.11-rc1:
- Update the baseline so we need not rely on make
  oldconfig so much
- MMC defconfig updates
- Activate NO_HZ_IDLE and HRTIMERS

----------------------------------------------------------------
Linus Walleij (2):
      ARM: nomadik: update defconfig base
      ARM: nomadik: configure for NO_HZ and HRTIMERS

Ulf Hansson (1):
      ARM: nomadik: Update MMC defconfigs

 arch/arm/configs/nhk8815_defconfig | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)


From lee.jones at linaro.org  Sat Jul 20 07:42:20 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Sat, 20 Jul 2013 12:42:20 +0100
Subject: [PATCH 10/22] ARM: ux500: Remove '0x's from Exynos5420 DTS file
In-Reply-To: <20130719214907.GI24642@n2100.arm.linux.org.uk>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
 <1374242333-6852-10-git-send-email-lee.jones@linaro.org>
 <20130719214907.GI24642@n2100.arm.linux.org.uk>
Message-ID: <20130720114220.GB4681@laptop>

On Fri, 19 Jul 2013, Russell King - ARM Linux wrote:

> On Fri, Jul 19, 2013 at 02:58:41PM +0100, Lee Jones wrote:
> > Cc: Kukjin Kim <kgene.kim at samsung.com>
> > Cc: linux-samsung-soc at vger.kernel.org
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > ---
> >  arch/arm/boot/dts/exynos5420.dtsi | 2 +-
> 
> One question.  What have all these files got to do with ux500 ?

They don't, sorry about that. Force of habit.

I'll resubmit on Monday.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Sat Jul 20 07:43:37 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Sat, 20 Jul 2013 12:43:37 +0100
Subject: [PATCH 20/22] ARM: ux500: Remove '0x's from Spear 300 DTS file
In-Reply-To: <CAOh2x==EBzy6MMy0Jv1=VSAD7Kdw7=Jag8g4oz-kfRH0XafGaw@mail.gmail.com>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
 <1374242333-6852-20-git-send-email-lee.jones@linaro.org>
 <CAOh2x==EBzy6MMy0Jv1=VSAD7Kdw7=Jag8g4oz-kfRH0XafGaw@mail.gmail.com>
Message-ID: <20130720114337.GC4681@laptop>

On Sat, 20 Jul 2013, Viresh Kumar wrote:

> On Fri, Jul 19, 2013 at 7:28 PM, Lee Jones <lee.jones at linaro.org> wrote:
> > Cc: Viresh Kumar <viresh.kumar at linaro.org>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > ---
> >  arch/arm/boot/dts/spear300.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/spear300.dtsi b/arch/arm/boot/dts/spear300.dtsi
> > index f79b3df..8970a4a 100644
> > --- a/arch/arm/boot/dts/spear300.dtsi
> > +++ b/arch/arm/boot/dts/spear300.dtsi
> > @@ -52,7 +52,7 @@
> >                         status = "disabled";
> >                 };
> >
> > -               shirq: interrupt-controller at 0x50000000 {
> > +               shirq: interrupt-controller at 50000000 {
> >                         compatible = "st,spear300-shirq";
> >                         reg = <0x50000000 0x1000>;
> >                         interrupts = <28>;
> 
> Should Ux500 come in subject line? And please write Spear as
> SPEAr.

Yes, you're right, I will correct them.

I did this for all twenty odd patches, whoops!

> Otherwise all three patches look fine.
> 
> Ackedy-by: Viresh Kumar <viresh.kumar at linaro.org>

Thanks.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From s.hauer at pengutronix.de  Sat Jul 20 07:58:29 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Sat, 20 Jul 2013 13:58:29 +0200
Subject: [RFC v2] ARM: i.MX pllv1: Implement set_rate
In-Reply-To: <20130720153104.96b6723a20bde172a8ea1ba1@mail.ru>
References: <1374308975-20596-1-git-send-email-shc_work@mail.ru>
 <20130720111639.GA29785@pengutronix.de>
 <20130720153104.96b6723a20bde172a8ea1ba1@mail.ru>
Message-ID: <20130720115829.GD29785@pengutronix.de>

On Sat, Jul 20, 2013 at 03:31:04PM +0400, Alexander Shiyan wrote:
> On Sat, 20 Jul 2013 13:16:39 +0200
> Sascha Hauer <s.hauer at pengutronix.de> wrote:
> 
> > On Sat, Jul 20, 2013 at 12:29:35PM +0400, Alexander Shiyan wrote:
> > > This patch implements frequency change for i.MX pllv1.
> > > Selection of the values of the registers is not optimal, since is
> > > made by simple enumeration of all possible values.
> > 
> > You do not mention why you want to adjust the rate. Normally we've been
> > happy with the static values from the bootloader.
> 
> For CPUfreq.
> Only one barrier to make it workable.

Isn't it better to adjust the dividers only? I haven't made good
experience with adjusting the PLLs.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From grant.likely at linaro.org  Sat Jul 20 01:44:39 2013
From: grant.likely at linaro.org (Grant Likely)
Date: Sat, 20 Jul 2013 06:44:39 +0100
Subject: [PATCH] of: match the compatible in the order set by the dts file
In-Reply-To: <51DBC58D.90002@freescale.com>
References: <1373013818-11365-1-git-send-email-b32955@freescale.com>
 <20130709070541.GQ516@pengutronix.de> <51DBBFDA.70302@freescale.com>
 <20130709075124.GR516@pengutronix.de> <51DBC58D.90002@freescale.com>
Message-ID: <20130720054439.308B33E13F0@localhost>

On Tue, 9 Jul 2013 16:10:53 +0800, Huang Shijie <b32955 at freescale.com> wrote:
> ??? 2013???07???09??? 15:51, Sascha Hauer ??????:
> > On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
> >> ??? 2013???07???09??? 15:05, Sascha Hauer ??????:
> >>> Why don't you set the matching order in the driver the way you want it
> >>> to be, i.e.:
> >>>
> >>> 	{ .compatible = "fsl,imx6q-uart", ... },
> >>> 	{ .compatible = "fsl,imx21-uart", ... },
> >>> 	{ .compatible = "fsl,imx1-uart", ... },
> >>>
> >> yes. i can set it like this.
> >>
> >> but this method looks like a ugly workaround.
> > If a driver has different ways of supporting a single device, then
> > putting the preferred or most feature rich on top doesn't look very ugly
> > to me.
> this method makes it much _coupled_ between the driver and the dts file.
> 
> IMHO, it's an unnecessary _burden_ to the driver programmer:
>     he should puts the most feature compatible on the top.
> 
> it's much graceful if we let the driver programmer be transparent about 
> this.

Absolutely true. Applied, thanks.

g.



From grant.likely at linaro.org  Sat Jul 20 01:39:45 2013
From: grant.likely at linaro.org (Grant Likely)
Date: Sat, 20 Jul 2013 06:39:45 +0100
Subject: [PATCH v2] of: Specify initrd location using 64-bit
In-Reply-To: <51D1F5E2.6070609@gmail.com>
References: <1372702835-5333-1-git-send-email-santosh.shilimkar@ti.com>
 <51D1F5E2.6070609@gmail.com>
Message-ID: <20130720053945.C7AC63E0C52@localhost>

On Mon, 01 Jul 2013 16:34:26 -0500, Rob Herring <robherring2 at gmail.com> wrote:
> On 07/01/2013 01:20 PM, Santosh Shilimkar wrote:
> > On some PAE architectures, the entire range of physical memory could reside
> > outside the 32-bit limit.  These systems need the ability to specify the
> > initrd location using 64-bit numbers.
> > 
> > This patch globally modifies the early_init_dt_setup_initrd_arch() function to
> > use 64-bit numbers instead of the current unsigned long.
> > 
> > There has been quite a bit of debate about whether to use u64 or phys_addr_t.
> > It was concluded to stick to u64 to be consistent with rest of the device
> > tree code. As summarized by Geert, "The address to load the initrd is decided
> > by the bootloader/user and set at that point later in time. The dtb should not
> > be tied to the kernel you are booting"
> 
> That was quoting me. Otherwise:
> 
> Acked-by: Rob Herring <rob.herring at calxeda.com>
> 
> Unless Grant feels compelled to pick this up for 3.11, I think it has to
> wait for 3.12.

Nope, 3.12 is fine. Applied.

g.



From grant.likely at secretlab.ca  Sat Jul 20 01:25:37 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sat, 20 Jul 2013 06:25:37 +0100
Subject: [PATCH] DT: add vendor prefixes for hisilicon
In-Reply-To: <1371445499-27265-1-git-send-email-zhangfei.gao@linaro.org>
References: <1371445499-27265-1-git-send-email-zhangfei.gao@linaro.org>
Message-ID: <20130720052537.5BB403E16CD@localhost>

On Mon, 17 Jun 2013 13:04:59 +0800, Zhangfei Gao <zhangfei.gao at linaro.org> wrote:
> Signed-off-by: Zhangfei Gao <zhangfei.gao at linaro.org>

Applied.

g.

> ---
>  .../devicetree/bindings/vendor-prefixes.txt        |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 6931c43..e18f3ad 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -25,6 +25,7 @@ est	ESTeem Wireless Modems
>  fsl	Freescale Semiconductor
>  GEFanuc	GE Fanuc Intelligent Platforms Embedded Systems, Inc.
>  gef	GE Fanuc Intelligent Platforms Embedded Systems, Inc.
> +hisilicon	Hisilicon Limited.
>  hp	Hewlett Packard
>  ibm	International Business Machines (IBM)
>  idt	Integrated Device Technologies, Inc.
> -- 
> 1.7.9.5
> 



From shc_work at mail.ru  Sat Jul 20 08:18:01 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 20 Jul 2013 16:18:01 +0400
Subject: [RFC v2] ARM: i.MX pllv1: Implement set_rate
In-Reply-To: <20130720115829.GD29785@pengutronix.de>
References: <1374308975-20596-1-git-send-email-shc_work@mail.ru>
 <20130720111639.GA29785@pengutronix.de>
 <20130720153104.96b6723a20bde172a8ea1ba1@mail.ru>
 <20130720115829.GD29785@pengutronix.de>
Message-ID: <20130720161801.380bb0d9db75155f5401730b@mail.ru>

On Sat, 20 Jul 2013 13:58:29 +0200
Sascha Hauer <s.hauer at pengutronix.de> wrote:

> > > On Sat, Jul 20, 2013 at 12:29:35PM +0400, Alexander Shiyan wrote:
> > > > This patch implements frequency change for i.MX pllv1.
> > > > Selection of the values of the registers is not optimal, since is
> > > > made by simple enumeration of all possible values.
> > > 
> > > You do not mention why you want to adjust the rate. Normally we've been
> > > happy with the static values from the bootloader.
> > 
> > For CPUfreq.
> > Only one barrier to make it workable.
> 
> Isn't it better to adjust the dividers only? I haven't made good
> experience with adjusting the PLLs.

The frequency value after booting can be quite arbitrary.

Since we define possible frequencies for the CPU (266 and 399 MHz),
I can offer as variant to use a fixed constant values for PLL.

-- 
Alexander Shiyan <shc_work at mail.ru>


From b.brezillon at overkiz.com  Sat Jul 20 10:51:33 2013
From: b.brezillon at overkiz.com (Boris BREZILLON)
Date: Sat, 20 Jul 2013 16:51:33 +0200
Subject: [PATCH] pinctrl: at91: choose appropriate handler for level interrupts
Message-ID: <1374331893-16009-1-git-send-email-b.brezillon@overkiz.com>

The current implementation handle both edge and level interrupts with the
'handle_simple_irq' handler.

Level interrupts are active as long as the pin stays at the configured
level (low or high). In this case we have to use 'handle_level_irq' which
mask the interrupt until the handle has treated it.

Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
---
 drivers/pinctrl/pinctrl-at91.c |   16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 5d7529e..76e108d 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -1241,18 +1241,22 @@ static int alt_gpio_irq_type(struct irq_data *d, unsigned type)
 
 	switch (type) {
 	case IRQ_TYPE_EDGE_RISING:
+		irq_set_handler(d->irq, handle_simple_irq);
 		writel_relaxed(mask, pio + PIO_ESR);
 		writel_relaxed(mask, pio + PIO_REHLSR);
 		break;
 	case IRQ_TYPE_EDGE_FALLING:
+		irq_set_handler(d->irq, handle_simple_irq);
 		writel_relaxed(mask, pio + PIO_ESR);
 		writel_relaxed(mask, pio + PIO_FELLSR);
 		break;
 	case IRQ_TYPE_LEVEL_LOW:
+		irq_set_handler(d->irq, handle_level_irq);
 		writel_relaxed(mask, pio + PIO_LSR);
 		writel_relaxed(mask, pio + PIO_FELLSR);
 		break;
 	case IRQ_TYPE_LEVEL_HIGH:
+		irq_set_handler(d->irq, handle_level_irq);
 		writel_relaxed(mask, pio + PIO_LSR);
 		writel_relaxed(mask, pio + PIO_REHLSR);
 		break;
@@ -1261,6 +1265,7 @@ static int alt_gpio_irq_type(struct irq_data *d, unsigned type)
 		 * disable additional interrupt modes:
 		 * fall back to default behavior
 		 */
+		irq_set_handler(d->irq, handle_simple_irq);
 		writel_relaxed(mask, pio + PIO_AIMDR);
 		return 0;
 	case IRQ_TYPE_NONE:
@@ -1402,6 +1407,8 @@ static int at91_gpio_irq_map(struct irq_domain *h, unsigned int virq,
 							irq_hw_number_t hw)
 {
 	struct at91_gpio_chip	*at91_gpio = h->host_data;
+	void __iomem		*pio = at91_gpio->regbase;
+	u32			mask = 1 << hw;
 
 	irq_set_lockdep_class(virq, &gpio_lock_class);
 
@@ -1409,8 +1416,13 @@ static int at91_gpio_irq_map(struct irq_domain *h, unsigned int virq,
 	 * Can use the "simple" and not "edge" handler since it's
 	 * shorter, and the AIC handles interrupts sanely.
 	 */
-	irq_set_chip_and_handler(virq, &gpio_irqchip,
-				 handle_simple_irq);
+	irq_set_chip(virq, &gpio_irqchip);
+	if ((at91_gpio->ops == &at91sam9x5_ops) &&
+	    (readl_relaxed(pio + PIO_AIMMR) & mask) &&
+	    (readl_relaxed(pio + PIO_ELSR) & mask))
+		irq_set_handler(virq, handle_level_irq);
+	else
+		irq_set_handler(virq, handle_simple_irq);
 	set_irq_flags(virq, IRQF_VALID);
 	irq_set_chip_data(virq, at91_gpio);
 
-- 
1.7.9.5



From ezequiel.garcia at free-electrons.com  Sat Jul 20 11:44:05 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Sat, 20 Jul 2013 12:44:05 -0300
Subject: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130720154404.GD24504@localhost>

Hi Grant, Arnd, Jason:

On Mon, Jul 15, 2013 at 11:57:29AM -0300, Ezequiel Garcia wrote:
> Here's the new MBus DT binding, implementing the changes proposed
> by Thomas when we discussed the previous patchset:
> 
>   http://www.spinics.net/lists/arm-kernel/msg257170.html
> 
> As far as I know, this round fixes *all* the concerns raised in the past
> and therefore I'd like to get Acked-by's from all the parties involved
> on the respective patches, and particularly for the DT binding.
> 
> If there's anything left to review, we'll be glad to fix it quickly,
> so don't hesitate in providing your feedback!
> 

Can you comment on this DT binding? Notice this is the outcome of a
lengthy discussion and has been already agreed by Arnd and Jason Gunthorpe.

If it looks OK, I'd like to have formal Acked-by's so Jason Cooper can merge it.

On the other side, given we've decided to mark some bindings as 'unstable'
or 'staging' maybe Jason can merge it so it can be in linux-next.
This way developers can actually start using this, and complaining if
there's anything to complain.

If we leave it as a patchset floating in mailing-lists it's hardly going
to get tested.

Does this approach make sense?

Thanks a lot!
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From arnd at arndb.de  Sat Jul 20 12:40:52 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 20 Jul 2013 18:40:52 +0200
Subject: [PATCH v4] watchdog: Add MOXA ART watchdog driver
In-Reply-To: <1374229402-20432-1-git-send-email-jonas.jensen@gmail.com>
References: <1374053091-5907-1-git-send-email-jonas.jensen@gmail.com>
 <1374229402-20432-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <201307201840.52455.arnd@arndb.de>

On Friday 19 July 2013, Jonas Jensen wrote:
> diff --git a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
> new file mode 100644
> index 0000000..5507f2b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
> @@ -0,0 +1,15 @@
> +MOXA ART Watchdog timer
> +
> +Required properties:
> +
> +- compatible : Should be "moxa,moxart-watchdog"
> +- reg : Should contain registers location and length
> +- clocks : Should contain phandle for the MOXA ART core clock "coreclk"
> +
> +Example:
> +
> +       watchdog: watchdog at 98500000 {
> +               compatible = "moxa,moxart-watchdog";
> +               reg = <0x98500000 0x10>;
> +               clocks = <&coreclk>;
> +       };

I think the property descriptions need to be clarified here:

* I think "should" makes no sense for the "compatible" property since it is
  required here, you probably mean "must", see http://www.ietf.org/rfc/rfc2119.txt. 

* for the clock, make sure that the description is from the point of view of
  the device you are describing, not from the perspective of the clock controller.
  The device should not make any assumptions about who provides a clock, only
  what it is used for, and it sounds like "coreclk" is an SoC-wide identifier,
  not the name of the clock input of the watchdog device. This is not as important
  as you don't define a "clock-names" property here, butsomething to keep in
  mind anyway.

	Arnd


From andrew at lunn.ch  Sat Jul 20 12:43:32 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Sat, 20 Jul 2013 18:43:32 +0200
Subject: [PATCH RFC v2 0/14] Clean up debugging support
In-Reply-To: <20130717170406.GR24642@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
 <20130717170406.GR24642@n2100.arm.linux.org.uk>
Message-ID: <20130720164332.GA26625@lunn.ch>

On Wed, Jul 17, 2013 at 06:04:06PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 16, 2013 at 05:32:43PM +0100, Russell King - ARM Linux wrote:
> > This is the second posting of this series, with a few additional patches
> > on top to go a little further.  Changes since the last posting:
> 
> Okay, I think everyone is happy with this, and it's time to go into
> linux-next, so it'll be visible in my tree from tomorrow.
> 
> Please keep the tested-by/acked-by etc coming.

Hi Russell

Maybe i'm blind, but i don't seem to be able to see this in linux
next, or your git tree.

Has it been pushed out yet?

Thanks
	Andrew


From arnd at arndb.de  Sat Jul 20 12:50:07 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 20 Jul 2013 18:50:07 +0200
Subject: [PATCH] arm: choose debug/uncompress.h include when uncompress
 debug is disabledo
In-Reply-To: <alpine.DEB.2.02.1307181755371.8258@kaball.uk.xensource.com>
References: <1373897706-15331-1-git-send-email-julien.grall@linaro.org>
 <20130718165007.GA24642@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307181755371.8258@kaball.uk.xensource.com>
Message-ID: <201307201850.07406.arnd@arndb.de>

On Thursday 18 July 2013, Stefano Stabellini wrote:
> > Lastly, aren't all ARMv7 kernels (therefore Xen supporting kernels)
> > supposed to be part of the multiplatform kernel stuff now?
> 
> Most of them, yes. However some of them, like exynos5250, are not yet.

It's just a matter of time. I had a patch for 3.10 to enable multiplatform
on exynos, but it missed both the 3.10 and 3.11 merge windows by a small
margin (for different reasons). We definitely want all ARMv7 platforms
to be multiplatform in the not too distant future.

	Arnd


From andrew at lunn.ch  Sat Jul 20 12:58:55 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Sat, 20 Jul 2013 18:58:55 +0200
Subject: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
In-Reply-To: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130720165855.GB26625@lunn.ch>

On Mon, Jul 15, 2013 at 11:57:29AM -0300, Ezequiel Garcia wrote:
> Here's the new MBus DT binding, implementing the changes proposed
> by Thomas when we discussed the previous patchset:
> 
>   http://www.spinics.net/lists/arm-kernel/msg257170.html
> 
> As far as I know, this round fixes *all* the concerns raised in the past
> and therefore I'd like to get Acked-by's from all the parties involved
> on the respective patches, and particularly for the DT binding.
> 
> If there's anything left to review, we'll be glad to fix it quickly,
> so don't hesitate in providing your feedback!
> 
> I'm sure many of you are dying to test this new MBus thing, so to make
> it easier for those courageous enough, I've pushed a public branch:
> 
>   https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v7

Hi Ezequiel

I just tried this in my Kirkwood QNAP.

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.11.0-rc1-00022-g44e8c39 (lunn at londo.lunn.ch) (gcc version 4.3.43
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Marvell Kirkwood (Flattened Device Tree), model: QNAP TS219 family
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
Kernel command line: root=/dev/sda2 console=ttyS0,115200 earlyprintk
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 513268K/524288K available (4247K kernel code, 241K rwdata, 1148K rodata)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
    lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .text : 0xc0008000 - 0xc054d050   (5397 kB)
      .init : 0xc054e000 - 0xc0576520   ( 162 kB)
      .data : 0xc0578000 - 0xc05b4420   ( 242 kB)
       .bss : 0xc05b4420 - 0xc064e104   ( 616 kB)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:114
sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms
Console: colour dummy device 80x30
Calibrating delay loop... 1587.60 BogoMIPS (lpj=7938048)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc040e888 - 0xc040e8c4
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
Kirkwood: MV88F6282-Rev-A0, TCLK=200000000.
Feroceon L2: Enabling L2
Feroceon L2: Cache support initialised.
bio: create slab <bio-0> at 0
mvebu-pcie pcie-controller.1: PCIe0.0: cannot get tgt/attr for mem window
mvebu-pcie pcie-controller.1: PCIe1.0: cannot get tgt/attr for mem window
Unable to handle kernel paging request at virtual address 00001804
pgd = c0004000
[00001804] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.11.0-rc1-00022-g44e8c39 #35
task: df848000 ti: df84a000 task.ti: df84a000
PC is at mvebu_pcie_setup+0x84/0x2b4
LR is at mvebu_pcie_setup+0x74/0x2b4
pc : [<c05622e4>]    lr : [<c05622d4>]    psr: 20000053
sp : df84bd70  ip : 00000000  fp : 00000000
r10: 00000000  r9 : c06435f4  r8 : df84be0c
r7 : 00000000  r6 : df8359d0  r5 : df9e8410  r4 : df9e7180
r3 : 00001804  r2 : 00000000  r1 : ffffffe0  r0 : c06435f4
Flags: nzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
Control: 0005397f  Table: 00004000  DAC: 00000017
Process swapper (pid: 1, stack limit = 0xdf84a1b8)
Stack: (0xdf84bd70 to 0xdf84c000)
bd60:                                     df801e00 00000000 df8f8a10 df9e7180
bd80: df9e71a0 df8f8a00 00000000 df84be0c 00000000 00000000 df84bdb0 c000d438
bda0: 00000018 c0206e58 c04db1d8 00000000 df84bdb0 df84bdb0 df9e8410 df9e8410
bdc0: df8359d0 df8f8a00 df8f8a10 00000000 00000000 c0c89170 df9e8410 c0561f98
bde0: df9e842c df911fa0 0000a1ff 00007846 000011ab 00000604 df84be0c 00000000
be00: 00000000 00000000 00000000 c059615c 00000001 df84be34 c0562260 c01d3468
be20: 00000000 00000000 00000000 c0562230 c01d2b88 df8359d0 00000000 df8f8a10
be40: df8f8a10 00000000 c059611c c0646070 c054e380 00000000 c05b4434 c020bdd8
be60: 00000000 c020ac28 df8f8a10 df8f8a44 c059611c c020adb8 c0561d0c c020ae44
be80: 00000000 df84be90 c059611c c02093f8 df80de8c df8f9e10 df9e72d4 df804b00
bea0: df9e72a0 c059611c c059dc50 c0209c3c c04d7b78 c01cf608 c0596108 c0596108
bec0: c059611c 00000005 0000009c c020b208 00000000 c0596108 c056f73c 00000005
bee0: 0000009c c020c0e8 c05760f8 c056f73c 00000005 c0008684 c0411b70 c0638b64
bf00: 0000003f 00000000 00000000 00000000 60000053 00000000 00000000 00000000
bf20: 00000000 0000009c c052e7cc c003482c 00000004 00000004 c052de0c c0c899ef
bf40: c0589738 c05760a0 c056f73c c05760f8 c056f73c 00000005 0000009c c05b4420
bf60: c056f70c c054e2ac 00000004 00000004 c054e380 ffffffff ffffffff 00000000
bf80: c04059f4 00000000 00000000 00000000 00000000 00000000 00000000 c0405a00
bfa0: 00000000 00000000 c04059f4 c0009330 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
[<c05622e4>] (mvebu_pcie_setup+0x84/0x2b4) from [<c000d438>] (pci_common_init_d)
[<c000d438>] (pci_common_init_dev+0xb8/0x2fc) from [<c0561f98>] (mvebu_pcie_pro)
[<c0561f98>] (mvebu_pcie_probe+0x278/0x510) from [<c020bdd8>] (platform_drv_pro)
[<c020bdd8>] (platform_drv_probe+0x1c/0x24) from [<c020ac28>] (driver_probe_dev)
[<c020ac28>] (driver_probe_device+0x90/0x220) from [<c020ae44>] (__driver_attac)
[<c020ae44>] (__driver_attach+0x8c/0x90) from [<c02093f8>] (bus_for_each_dev+0x)
[<c02093f8>] (bus_for_each_dev+0x74/0x98) from [<c0209c3c>] (bus_add_driver+0xe)
[<c0209c3c>] (bus_add_driver+0xe8/0x238) from [<c020b208>] (driver_register+0x5)
[<c020b208>] (driver_register+0x5c/0x14c) from [<c020c0e8>] (platform_driver_pr)
[<c020c0e8>] (platform_driver_probe+0x1c/0xac) from [<c0008684>] (do_one_initca)
[<c0008684>] (do_one_initcall+0x2c/0x160) from [<c054e2ac>] (kernel_init_freeab)
[<c054e2ac>] (kernel_init_freeable+0xf4/0x1c8) from [<c0405a00>] (kernel_init+0)
[<c0405a00>] (kernel_init+0xc/0x164) from [<c0009330>] (ret_from_fork+0x14/0x24)
Code: e5953004 e1a09000 e2833b06 e2833004 (e583a000) 
---[ end trace 939c05c25cac6ec3 ]---


     Andrew


From andrew at lunn.ch  Sat Jul 20 13:38:47 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Sat, 20 Jul 2013 19:38:47 +0200
Subject: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
In-Reply-To: <20130720165855.GB26625@lunn.ch>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130720165855.GB26625@lunn.ch>
Message-ID: <20130720173847.GC26625@lunn.ch>

On Sat, Jul 20, 2013 at 06:58:55PM +0200, Andrew Lunn wrote:
> On Mon, Jul 15, 2013 at 11:57:29AM -0300, Ezequiel Garcia wrote:
> > Here's the new MBus DT binding, implementing the changes proposed
> > by Thomas when we discussed the previous patchset:
> > 
> >   http://www.spinics.net/lists/arm-kernel/msg257170.html
> > 
> > As far as I know, this round fixes *all* the concerns raised in the past
> > and therefore I'd like to get Acked-by's from all the parties involved
> > on the respective patches, and particularly for the DT binding.
> > 
> > If there's anything left to review, we'll be glad to fix it quickly,
> > so don't hesitate in providing your feedback!
> > 
> > I'm sure many of you are dying to test this new MBus thing, so to make
> > it easier for those courageous enough, I've pushed a public branch:
> > 
> >   https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v7
> 
> Hi Ezequiel
> 
> I just tried this in my Kirkwood QNAP.
> 
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 3.11.0-rc1-00022-g44e8c39 (lunn at londo.lunn.ch) (gcc version 4.3.43
> CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
> CPU: VIVT data cache, VIVT instruction cache
> Machine: Marvell Kirkwood (Flattened Device Tree), model: QNAP TS219 family
> bootconsole [earlycon0] enabled
> Memory policy: ECC disabled, Data cache writeback
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
> Kernel command line: root=/dev/sda2 console=ttyS0,115200 earlyprintk
> PID hash table entries: 2048 (order: 1, 8192 bytes)
> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Memory: 513268K/524288K available (4247K kernel code, 241K rwdata, 1148K rodata)
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>     vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
>     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
>     modules : 0xbf000000 - 0xc0000000   (  16 MB)
>       .text : 0xc0008000 - 0xc054d050   (5397 kB)
>       .init : 0xc054e000 - 0xc0576520   ( 162 kB)
>       .data : 0xc0578000 - 0xc05b4420   ( 242 kB)
>        .bss : 0xc05b4420 - 0xc064e104   ( 616 kB)
> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> Preemptible hierarchical RCU implementation.
> NR_IRQS:114
> sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms
> Console: colour dummy device 80x30
> Calibrating delay loop... 1587.60 BogoMIPS (lpj=7938048)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> Setting up static identity map for 0xc040e888 - 0xc040e8c4
> pinctrl core: initialized pinctrl subsystem
> regulator-dummy: no parameters
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> Kirkwood: MV88F6282-Rev-A0, TCLK=200000000.
> Feroceon L2: Enabling L2
> Feroceon L2: Cache support initialised.
> bio: create slab <bio-0> at 0
> mvebu-pcie pcie-controller.1: PCIe0.0: cannot get tgt/attr for mem window
> mvebu-pcie pcie-controller.1: PCIe1.0: cannot get tgt/attr for mem window

Hi Ezequiel

I just put some debug into mvebu_get_tgt_attr():

slot 0, PCI_SLOT(devfn) 1
type 512, rtype 512
slot 0, PCI_SLOT(devfn) 1
type 512, rtype 512
slot 0, PCI_SLOT(devfn) 1
type 512, rtype 512
slot 0, PCI_SLOT(devfn) 1
type 512, rtype 256
mvebu-pcie pcie-controller.1: PCIe0.0: cannot get tgt/attr for mem window -2
slot 0, PCI_SLOT(devfn) 2
type 512, rtype 512
slot 0, PCI_SLOT(devfn) 2
type 512, rtype 512
slot 0, PCI_SLOT(devfn) 2
type 512, rtype 512
slot 0, PCI_SLOT(devfn) 2
type 512, rtype 256

Any ideas?

    Thanks
	Andrew


From shc_work at mail.ru  Sat Jul 20 14:22:04 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 20 Jul 2013 22:22:04 +0400
Subject: [PATCH RESEND] ARM: plat-samsung: Fix switching FIFO in
 arch_enable_uart_fifo function
In-Reply-To: <1372792593-7457-1-git-send-email-shc_work@mail.ru>
References: <1372792593-7457-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130720222204.95d2626fbe133ab7fd3c3287@mail.ru>

On Tue,  2 Jul 2013 23:16:33 +0400
Alexander Shiyan <shc_work at mail.ru> wrote:

> When CONFIG_S3C_BOOT_UART_FORCE_FIFO symbol is set, we should
> enable FIFO but actually switch command is missing in the code.
> This patch adds this switching.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  arch/arm/plat-samsung/include/plat/uncompress.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/plat-samsung/include/plat/uncompress.h b/arch/arm/plat-samsung/include/plat/uncompress.h
> index 4afc32f..f48dc0a 100644
> --- a/arch/arm/plat-samsung/include/plat/uncompress.h
> +++ b/arch/arm/plat-samsung/include/plat/uncompress.h
> @@ -145,6 +145,8 @@ static inline void arch_enable_uart_fifo(void)
>  			if (!(fifocon & S3C2410_UFCON_RESETBOTH))
>  				break;
>  		}
> +
> +		uart_wr(S3C2410_UFCON, S3C2410_UFCON_FIFOMODE);
>  	}
>  }
>  #else
> -- 
> 1.8.1.5

Ping.

-- 
Alexander Shiyan <shc_work at mail.ru>


From ezequiel.garcia at free-electrons.com  Sat Jul 20 14:36:30 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Sat, 20 Jul 2013 15:36:30 -0300
Subject: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
In-Reply-To: <20130720173847.GC26625@lunn.ch>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130720165855.GB26625@lunn.ch> <20130720173847.GC26625@lunn.ch>
Message-ID: <20130720183629.GA21460@localhost>

Andrew,

On Sat, Jul 20, 2013 at 07:38:47PM +0200, Andrew Lunn wrote:
> On Sat, Jul 20, 2013 at 06:58:55PM +0200, Andrew Lunn wrote:
> > On Mon, Jul 15, 2013 at 11:57:29AM -0300, Ezequiel Garcia wrote:
> > > Here's the new MBus DT binding, implementing the changes proposed
> > > by Thomas when we discussed the previous patchset:
> > > 
> > >   http://www.spinics.net/lists/arm-kernel/msg257170.html
> > > 
> > > As far as I know, this round fixes *all* the concerns raised in the past
> > > and therefore I'd like to get Acked-by's from all the parties involved
> > > on the respective patches, and particularly for the DT binding.
> > > 
> > > If there's anything left to review, we'll be glad to fix it quickly,
> > > so don't hesitate in providing your feedback!
> > > 
> > > I'm sure many of you are dying to test this new MBus thing, so to make
> > > it easier for those courageous enough, I've pushed a public branch:
> > > 
> > >   https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v7
> > 
> > Hi Ezequiel
> > 
> > I just tried this in my Kirkwood QNAP.
> > 
> > Uncompressing Linux... done, booting the kernel.
> > Booting Linux on physical CPU 0x0
> > Linux version 3.11.0-rc1-00022-g44e8c39 (lunn at londo.lunn.ch) (gcc version 4.3.43
> > CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
> > CPU: VIVT data cache, VIVT instruction cache
> > Machine: Marvell Kirkwood (Flattened Device Tree), model: QNAP TS219 family
> > bootconsole [earlycon0] enabled
> > Memory policy: ECC disabled, Data cache writeback
> > Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
> > Kernel command line: root=/dev/sda2 console=ttyS0,115200 earlyprintk
> > PID hash table entries: 2048 (order: 1, 8192 bytes)
> > Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> > Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> > Memory: 513268K/524288K available (4247K kernel code, 241K rwdata, 1148K rodata)
> > Virtual kernel memory layout:
> >     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> >     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> >     vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
> >     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
> >     modules : 0xbf000000 - 0xc0000000   (  16 MB)
> >       .text : 0xc0008000 - 0xc054d050   (5397 kB)
> >       .init : 0xc054e000 - 0xc0576520   ( 162 kB)
> >       .data : 0xc0578000 - 0xc05b4420   ( 242 kB)
> >        .bss : 0xc05b4420 - 0xc064e104   ( 616 kB)
> > SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> > Preemptible hierarchical RCU implementation.
> > NR_IRQS:114
> > sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms
> > Console: colour dummy device 80x30
> > Calibrating delay loop... 1587.60 BogoMIPS (lpj=7938048)
> > pid_max: default: 32768 minimum: 301
> > Mount-cache hash table entries: 512
> > CPU: Testing write buffer coherency: ok
> > Setting up static identity map for 0xc040e888 - 0xc040e8c4
> > pinctrl core: initialized pinctrl subsystem
> > regulator-dummy: no parameters
> > NET: Registered protocol family 16
> > DMA: preallocated 256 KiB pool for atomic coherent allocations
> > Kirkwood: MV88F6282-Rev-A0, TCLK=200000000.
> > Feroceon L2: Enabling L2
> > Feroceon L2: Cache support initialised.
> > bio: create slab <bio-0> at 0
> > mvebu-pcie pcie-controller.1: PCIe0.0: cannot get tgt/attr for mem window
> > mvebu-pcie pcie-controller.1: PCIe1.0: cannot get tgt/attr for mem window
> 
> Hi Ezequiel
> 
> I just put some debug into mvebu_get_tgt_attr():
> 
> slot 0, PCI_SLOT(devfn) 1
> type 512, rtype 512
> slot 0, PCI_SLOT(devfn) 1
> type 512, rtype 512
> slot 0, PCI_SLOT(devfn) 1
> type 512, rtype 512
> slot 0, PCI_SLOT(devfn) 1
> type 512, rtype 256
> mvebu-pcie pcie-controller.1: PCIe0.0: cannot get tgt/attr for mem window -2
> slot 0, PCI_SLOT(devfn) 2
> type 512, rtype 512
> slot 0, PCI_SLOT(devfn) 2
> type 512, rtype 512
> slot 0, PCI_SLOT(devfn) 2
> type 512, rtype 512
> slot 0, PCI_SLOT(devfn) 2
> type 512, rtype 256
> 
> Any ideas?
> 

Thanks a lot for testing this! I'll take a look and let you know...

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From ezequiel.garcia at free-electrons.com  Sat Jul 20 14:54:44 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Sat, 20 Jul 2013 15:54:44 -0300
Subject: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
In-Reply-To: <20130720173847.GC26625@lunn.ch>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130720165855.GB26625@lunn.ch> <20130720173847.GC26625@lunn.ch>
Message-ID: <20130720185443.GB21460@localhost>

Andrew,

On Sat, Jul 20, 2013 at 07:38:47PM +0200, Andrew Lunn wrote:
> On Sat, Jul 20, 2013 at 06:58:55PM +0200, Andrew Lunn wrote:
> > On Mon, Jul 15, 2013 at 11:57:29AM -0300, Ezequiel Garcia wrote:
> > > Here's the new MBus DT binding, implementing the changes proposed
> > > by Thomas when we discussed the previous patchset:
> > > 
> > >   http://www.spinics.net/lists/arm-kernel/msg257170.html
> > > 
> > > As far as I know, this round fixes *all* the concerns raised in the past
> > > and therefore I'd like to get Acked-by's from all the parties involved
> > > on the respective patches, and particularly for the DT binding.
> > > 
> > > If there's anything left to review, we'll be glad to fix it quickly,
> > > so don't hesitate in providing your feedback!
> > > 
> > > I'm sure many of you are dying to test this new MBus thing, so to make
> > > it easier for those courageous enough, I've pushed a public branch:
> > > 
> > >   https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v7
> > 
> > I just tried this in my Kirkwood QNAP.
> > 
> > Uncompressing Linux... done, booting the kernel.
> > Booting Linux on physical CPU 0x0
> > Linux version 3.11.0-rc1-00022-g44e8c39 (lunn at londo.lunn.ch) (gcc version 4.3.43
> > CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
> > CPU: VIVT data cache, VIVT instruction cache
> > Machine: Marvell Kirkwood (Flattened Device Tree), model: QNAP TS219 family
> > bootconsole [earlycon0] enabled
> > Memory policy: ECC disabled, Data cache writeback
> > Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
> > Kernel command line: root=/dev/sda2 console=ttyS0,115200 earlyprintk
> > PID hash table entries: 2048 (order: 1, 8192 bytes)
> > Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> > Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> > Memory: 513268K/524288K available (4247K kernel code, 241K rwdata, 1148K rodata)
> > Virtual kernel memory layout:
> >     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> >     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> >     vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
> >     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
> >     modules : 0xbf000000 - 0xc0000000   (  16 MB)
> >       .text : 0xc0008000 - 0xc054d050   (5397 kB)
> >       .init : 0xc054e000 - 0xc0576520   ( 162 kB)
> >       .data : 0xc0578000 - 0xc05b4420   ( 242 kB)
> >        .bss : 0xc05b4420 - 0xc064e104   ( 616 kB)
> > SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> > Preemptible hierarchical RCU implementation.
> > NR_IRQS:114
> > sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms
> > Console: colour dummy device 80x30
> > Calibrating delay loop... 1587.60 BogoMIPS (lpj=7938048)
> > pid_max: default: 32768 minimum: 301
> > Mount-cache hash table entries: 512
> > CPU: Testing write buffer coherency: ok
> > Setting up static identity map for 0xc040e888 - 0xc040e8c4
> > pinctrl core: initialized pinctrl subsystem
> > regulator-dummy: no parameters
> > NET: Registered protocol family 16
> > DMA: preallocated 256 KiB pool for atomic coherent allocations
> > Kirkwood: MV88F6282-Rev-A0, TCLK=200000000.
> > Feroceon L2: Enabling L2
> > Feroceon L2: Cache support initialised.
> > bio: create slab <bio-0> at 0
[...]
> > mvebu-pcie pcie-controller.1: PCIe0.0: cannot get tgt/attr for mem window
> > mvebu-pcie pcie-controller.1: PCIe1.0: cannot get tgt/attr for mem window
[...]
> 
> Any ideas?
> 

The patchset works only for Armada 370 and Armada XP SoC, not for Kirkwood.
For some reason I was completely sure there wasn't any DT-enabled Kirkwood
boards with PCIe support.

I apologize for not noticing this before!

My plan was to get this patchset acked/merged and then add MBus DT to Kirkwood.
The reason for this is that it's a simple change, but probably *very* intrusive
on the DTS files.
Of course, this plan was based on the assumption that the wasn't breaking
anything.

However, now I guess there's no other solution than adding Kirkwood to the
patchset. So unless anyone has any better idea, I'll be sending a v8.

Thanks again for the test!
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From andrew at lunn.ch  Sat Jul 20 15:45:59 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Sat, 20 Jul 2013 21:45:59 +0200
Subject: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
In-Reply-To: <20130720185443.GB21460@localhost>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130720165855.GB26625@lunn.ch> <20130720173847.GC26625@lunn.ch>
 <20130720185443.GB21460@localhost>
Message-ID: <20130720194559.GA27517@lunn.ch>

> The patchset works only for Armada 370 and Armada XP SoC, not for Kirkwood.
> For some reason I was completely sure there wasn't any DT-enabled Kirkwood
> boards with PCIe support.

I had a quick look at Dove and Orion5x. It looks like there are none
with PCIe support. So only Kirkwood is broken.

	Andrew


From linus.walleij at linaro.org  Sat Jul 20 16:51:09 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Jul 2013 22:51:09 +0200
Subject: [PATCH v4 00/17] 64-bit friendly generic sched_clock()
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <CACRpkdauSuk9xDSzUFN=OO0yVWZXSMTUuYTVDZb2_zYb=YMW_A@mail.gmail.com>

On Fri, Jul 19, 2013 at 1:21 AM, Stephen Boyd <sboyd at codeaurora.org> wrote:

> This patchset adds support for 64 bit counters in the generic
> sched_clock code and converts drivers over to use it. Based
> on v3.11-rc1.
>
> Changes since v3:

>   ocksource: dbx500-prcmu: Switch to sched_clock_register()

Fix subject.

>   clocksource: nomadik: Switch to sched_clock_register()

Apart from that Acked-by: Linus Walleij <linus.walleij at linaro.org>
for these two drivers.

BTW: why are you not patching arch/arm/mach-u300/timer.c?
Please make sure to grep for all setup_sched_clock() if you're
going to do this.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Sat Jul 20 16:45:29 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Jul 2013 22:45:29 +0200
Subject: [PATCH v9] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <1374048297-4321-1-git-send-email-jonas.jensen@gmail.com>
References: <1373985880-23469-1-git-send-email-jonas.jensen@gmail.com>
 <1374048297-4321-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <CACRpkdYktthfRsn9=9GjphXUbOEAswdCZCM48KFK2WRgBdj-Qw@mail.gmail.com>

On Wed, Jul 17, 2013 at 10:04 AM, Jonas Jensen <jonas.jensen at gmail.com> wrote:

> +#include <linux/clk.h>
> +#include <linux/clockchips.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/irqreturn.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/io.h>
> +#include <linux/clocksource.h>

#include <linux/bitops.h>

> +#define TIMEREG_CR_1_ENABLE    BIT(0)

Because BIT() comes from there. And we shall not rely on
implicit #inclusion.

Apart from that:
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From linus.walleij at linaro.org  Sat Jul 20 16:54:42 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Jul 2013 22:54:42 +0200
Subject: [PATCH 0/3] MSM gpio fixes
In-Reply-To: <1374178035-19943-1-git-send-email-davidb@codeaurora.org>
References: <1374178035-19943-1-git-send-email-davidb@codeaurora.org>
Message-ID: <CACRpkdbOO8fFEx+PxsdJ9F1dqD6V4_RPZThvTufo9+XhhyuHOg@mail.gmail.com>

On Thu, Jul 18, 2013 at 10:07 PM, David Brown <davidb at codeaurora.org> wrote:

> Rohit sent these three fixes out on June 18.  I still need a
> devicetree ack for the first patch, and would like these to get pulled
> in for v3.11
>
> Rohit Vaswani (3):
>   ARM: msm: dts: Fix the gpio register address for msm8960
>   drivers: gpio: msm: Fix the error condition for reading ngpio

OK for these two...

>   ARM: msm: Consolidate gpiomux for older architectures

This does not look like a fix? Surely this can wait for v3.12?

Yours,
Linus Walleij


From daniel.lezcano at linaro.org  Sat Jul 20 17:34:29 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sat, 20 Jul 2013 23:34:29 +0200
Subject: [PATCH v9] ARM: clocksource: add support for MOXA ART SoCs
In-Reply-To: <CACRpkdYktthfRsn9=9GjphXUbOEAswdCZCM48KFK2WRgBdj-Qw@mail.gmail.com>
References: <1373985880-23469-1-git-send-email-jonas.jensen@gmail.com>
 <1374048297-4321-1-git-send-email-jonas.jensen@gmail.com>
 <CACRpkdYktthfRsn9=9GjphXUbOEAswdCZCM48KFK2WRgBdj-Qw@mail.gmail.com>
Message-ID: <51EB0265.2030508@linaro.org>

On 07/20/2013 10:45 PM, Linus Walleij wrote:
> On Wed, Jul 17, 2013 at 10:04 AM, Jonas Jensen <jonas.jensen at gmail.com> wrote:
> 
>> +#include <linux/clk.h>
>> +#include <linux/clockchips.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/irq.h>
>> +#include <linux/irqreturn.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_irq.h>
>> +#include <linux/io.h>
>> +#include <linux/clocksource.h>
> 
> #include <linux/bitops.h>
> 
>> +#define TIMEREG_CR_1_ENABLE    BIT(0)
> 
> Because BIT() comes from there. And we shall not rely on
> implicit #inclusion.

Hi Jonas,

as the patchset is already merged could you fix it with a separate patch ?

Thanks
  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Sat Jul 20 17:42:11 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sat, 20 Jul 2013 23:42:11 +0200
Subject: [PATCH 08/10] ARM: clps711x: Add CLPS711X cpuidle driver
In-Reply-To: <1374172501-26796-9-git-send-email-shc_work@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
 <1374172501-26796-9-git-send-email-shc_work@mail.ru>
Message-ID: <51EB0433.3050308@linaro.org>

On 07/18/2013 08:34 PM, Alexander Shiyan wrote:
> This adds the cpuidle driver for Cirrus Logic CLPS711X series SoCs.
> Designed primarily for migration CLPS711X subarch for multiplatform & DT.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  drivers/cpuidle/Kconfig            |  6 +++
>  drivers/cpuidle/Makefile           |  1 +
>  drivers/cpuidle/cpuidle-clps711x.c | 80 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 87 insertions(+)
>  create mode 100644 drivers/cpuidle/cpuidle-clps711x.c
> 
> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
> index 0e2cd5c..c68a0cf 100644
> --- a/drivers/cpuidle/Kconfig
> +++ b/drivers/cpuidle/Kconfig
> @@ -36,6 +36,12 @@ config CPU_IDLE_CALXEDA
>  	help
>  	  Select this to enable cpuidle on Calxeda processors.
>  
> +config CPU_IDLE_CLPS711X
> +	bool "CPU Idle Driver for CLPS711X processors"
> +	depends on ARCH_CLPS711X
> +	help
> +	  Select this to enable cpuidle on Cirrus Logic CLPS711X processors.
> +
>  config CPU_IDLE_ZYNQ
>  	bool "CPU Idle Driver for Xilinx Zynq processors"
>  	depends on ARCH_ZYNQ
> diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
> index 8767a7b..d07d2cb 100644
> --- a/drivers/cpuidle/Makefile
> +++ b/drivers/cpuidle/Makefile
> @@ -6,5 +6,6 @@ obj-y += cpuidle.o driver.o governor.o sysfs.o governors/
>  obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
>  
>  obj-$(CONFIG_CPU_IDLE_CALXEDA) += cpuidle-calxeda.o
> +obj-$(CONFIG_CPU_IDLE_CLPS711X)	+= cpuidle-clps711x.o
>  obj-$(CONFIG_ARCH_KIRKWOOD) += cpuidle-kirkwood.o
>  obj-$(CONFIG_CPU_IDLE_ZYNQ) += cpuidle-zynq.o
> diff --git a/drivers/cpuidle/cpuidle-clps711x.c b/drivers/cpuidle/cpuidle-clps711x.c
> new file mode 100644
> index 0000000..9f0129f
> --- /dev/null
> +++ b/drivers/cpuidle/cpuidle-clps711x.c
> @@ -0,0 +1,80 @@
> +/*
> + *  CLPS711X CPU idle driver
> + *
> + *  Copyright (C) 2013 Alexander Shiyan <shc_work at mail.ru>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/cpuidle.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +
> +static void __iomem *clps711x_halt;
> +
> +static int clps711x_cpuidle_halt(struct cpuidle_device *dev,
> +				 struct cpuidle_driver *drv, int index)
> +{
> +	writel(1, clps711x_halt);

In what the 'clps711x_halt' differs from the usual WFI (cpu_do_idle) ?

> +	asm volatile ("mov r0, r0");
> +	asm volatile ("mov r0, r0");

Why are needed these two volatile ?

> +	return index;
> +}
> +
> +static struct cpuidle_driver clps711x_idle_driver = {
> +	.name			= "clps711x_idle",
> +	.owner			= THIS_MODULE,
> +	.state_count		= 1,
> +	.states[0]	= {
> +		.name		= "HALT",
> +		.desc		= "CLPS711X WFI",
> +		.enter		= clps711x_cpuidle_halt,
> +		.exit_latency	= 1,
> +	},
> +};
> +
> +static int __init clps711x_cpuidle_probe(struct platform_device *pdev)
> +{
> +	struct resource *res;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	clps711x_halt = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(clps711x_halt))
> +		return PTR_ERR(clps711x_halt);
> +
> +	return cpuidle_register(&clps711x_idle_driver, NULL);
> +}
> +
> +static int clps711x_cpuidle_remove(struct platform_device *pdev)
> +{
> +	cpuidle_unregister(&clps711x_idle_driver);
> +
> +	return 0;
> +}

The driver is not compiled as module, will this function be called ?

> +
> +static const struct of_device_id clps711x_cpuidle_dt_ids[] = {
> +	{ .compatible = "cirrus,clps711x-cpuidle", },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, clps711x_cpuidle_dt_ids);
> +
> +static struct platform_driver clps711x_cpuidle_driver = {
> +	.driver	= {
> +		.name		= "clps711x-cpuidle",
> +		.owner		= THIS_MODULE,
> +		.of_match_table	= clps711x_cpuidle_dt_ids,
> +	},
> +	.remove	= clps711x_cpuidle_remove,
> +};
> +module_platform_driver_probe(clps711x_cpuidle_driver, clps711x_cpuidle_probe);

+1

> +
> +MODULE_AUTHOR("Alexander Shiyan <shc_work at mail.ru>");
> +MODULE_DESCRIPTION("CLPS711X CPU idle driver");
> +MODULE_LICENSE("GPL");




-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Sat Jul 20 17:48:30 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sat, 20 Jul 2013 23:48:30 +0200
Subject: [PATCH 06/10] ARM: clps711x: Add CLPS711X clocksource driver
In-Reply-To: <20130720074441.9882b71183e5eadd535da6c1@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
 <1374172501-26796-7-git-send-email-shc_work@mail.ru>
 <51E94F7E.4030404@linaro.org>
 <20130720074441.9882b71183e5eadd535da6c1@mail.ru>
Message-ID: <51EB05AE.2050105@linaro.org>

On 07/20/2013 05:44 AM, Alexander Shiyan wrote:
> On Fri, 19 Jul 2013 16:38:54 +0200
> Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
>> (Added Thomas and John in Cc in case they want to review the patch).
>>
>> On 07/18/2013 08:34 PM, Alexander Shiyan wrote:
>>> This adds the clocksource driver for Cirrus Logic CLPS711X series SoCs.
>>> Designed primarily for migration CLPS711X subarch for multiplatform & DT,
>>> for this as the "OF" and "not-OF" calls implemented.
>>
>> When a new driver is submitted, I ask for a more detailed changelog
>> about the driver itself: how it works, any specificities, etc ...
>>
>> That will help people to understand the code better at least for the review.
> 
> Basically, this series is a port of the CLPS711X subsystems in places specially
> designed for this purpose. Additionally added to the standard description of the
> subsystem for use with DT.
> As for specs, I'm a little confused by this question. In this case, I'm doing
> is not anything new for this CPU. The CPU has two timers and I use both to
> provide the correct time sources.

I understand there is nothing extra in the code but I was talking about
some specificity of the driver if there are (eg. timer must be disabled
with disable/enable irq).

>>> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
>>> ---
>>>  arch/arm/Kconfig                      |   2 -
>>>  drivers/clocksource/Kconfig           |   6 ++
>>>  drivers/clocksource/Makefile          |   1 +
>>>  drivers/clocksource/clps711x-clksrc.c | 151 ++++++++++++++++++++++++++++++++++
>>>  4 files changed, 158 insertions(+), 2 deletions(-)
>>>  create mode 100644 drivers/clocksource/clps711x-clksrc.c
> [...]
>>> +#define CLPS711X_SYSCON1	(0x0100)
>>> +#define CLPS711X_TC1D		(0x0300)
>>> +#define CLPS711X_TC2D		(0x0340)
>>
>> Alignment.
> 
> Alignment? Do not see any problems.
> Wrong alignment in this case is the result of quote.

Ok.

>>> +static struct {
>>> +	void __iomem	*tc1d;
>>> +	int		irq;
>>> +} *clps711x_clksrc;
>>
>> You don't need to define this structure, the struct clock_event_device
>> already contains a field with irq.
> 
> Thank you, I will know.
> 
> [...]
>>> +static void clps711x_clockevent_set_mode(enum clock_event_mode mode,
>>> +					 struct clock_event_device *evt)
>>> +{
>>> +	disable_irq(clps711x_clksrc->irq);
>>
>> Do you really need to disable the interrupt to re-enable it right after ?
> 
> That was the original implementation. Perhaps the best solution is to disable
> interrupt by CLOCK_EVT_MODE_SHUTDOWN and enable it back by CLOCK_EVT_MODE_RESUME.
> 
>>> +> +	switch (mode) {
>>> +	case CLOCK_EVT_MODE_PERIODIC:
>>> +		enable_irq(clps711x_clksrc->irq);
>>> +		break;
>>> +	case CLOCK_EVT_MODE_ONESHOT:
>>> +		/* Not supported */
>>> +	case CLOCK_EVT_MODE_SHUTDOWN:
>>> +	case CLOCK_EVT_MODE_UNUSED:
>>> +	case CLOCK_EVT_MODE_RESUME:
>>> +		/* Left event sources disabled, no more interrupts appear */
>>> +		break;
>>> +	}
>>> +}
>>
>> I am not expert in interrupts, but it is possible this interrupt could
>> be shared ?
> 
> Timer interrupt? No.
> 
>> There isn't a register to enable/disable the timer ?
> 
> Unfortunately, no. The timer is running always, except STDBY CPU state,
> so we can control it only by enable/disable interrupt.

Ok.

> [...]
>>> +static struct irqaction clps711x_timer_irq = {
>>> +	.name		= "clps711x-timer",
>>> +	.flags		= IRQF_TIMER | IRQF_IRQPOLL,
>>
>> Why do you need IRQF_IRQPOOL ?
> 
> linux/interrupt.h:
>  * IRQF_IRQPOLL - Interrupt is used for polling (only the interrupt that is
>  *                registered first in an shared interrupt is considered for
>  *                performance reasons)
> 
> I do not see need this flag, but in fact, this flag is traditionally used
> in almost all subsystems of this type.

So IIUC, IRQPOLL is to switch to polling mode when a lot of interrupts
occur, right ?

> [...]
>>> +	tmp = readl(syscon1);
>>> +	/* TC1 in free running mode */
>>> +	tmp &= ~SYSCON1_TC1M;
>>> +	/* TC2 in prescale mode */
>>> +	tmp |= SYSCON1_TC2M;
>>> +	writel(tmp, syscon1);
>>
>> Could you encapsulate these calls inside a static inline function with a
>> more detailed comment please ?
> 
> Why static inline?
> There is a comment line for each bit, You think this is not enough?

I prefer to encapsulate readl/writel calls inside a small function with
an explicit name, comments are still welcome.

> [...]
>>> +void __init clps711x_clksrc_init(phys_addr_t phys_base, int irq)
>>
>> Is this function called somewhere ? I don't see the function definition ?
> 
> It is defined in the patch [9/10] for non-DT case.

Ok, thanks.


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From christoffer.dall at linaro.org  Sat Jul 20 17:51:47 2013
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Sat, 20 Jul 2013 22:51:47 +0100
Subject: [PATCH 1/4] arm64: KVM: perform save/restore of PAR_EL1
In-Reply-To: <1374242035-13199-2-git-send-email-marc.zyngier@arm.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-2-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130720215147.GB35165@lvm>

On Fri, Jul 19, 2013 at 02:53:52PM +0100, Marc Zyngier wrote:
> Not saving PAR_EL1 is an unfortunate oversight. If the guest
> performs an AT* operation and gets scheduled out before reading
> the result of the translation from PAREL1, it could become
> corrupted by another guest or the host.
> 
> Saving this register is made slightly more complicated as KVM also
> uses it on the permission fault handling path, leading to an ugly
> "stash and restore" sequence. Fortunately, this is already a slow
> path so we don't really care. Also, Linux doesn't do any AT*
> operation, so Linux guests are not impacted by this bug.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/kvm_asm.h | 17 ++++++++++-------
>  arch/arm64/kvm/hyp.S             | 10 ++++++++++
>  arch/arm64/kvm/sys_regs.c        |  3 +++
>  3 files changed, 23 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index c92de41..b25763b 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -42,14 +42,15 @@
>  #define	TPIDR_EL1	18	/* Thread ID, Privileged */
>  #define	AMAIR_EL1	19	/* Aux Memory Attribute Indirection Register */
>  #define	CNTKCTL_EL1	20	/* Timer Control Register (EL1) */
> +#define	PAR_EL1		21	/* Physical Address Register */
>  /* 32bit specific registers. Keep them at the end of the range */
> -#define	DACR32_EL2	21	/* Domain Access Control Register */
> -#define	IFSR32_EL2	22	/* Instruction Fault Status Register */
> -#define	FPEXC32_EL2	23	/* Floating-Point Exception Control Register */
> -#define	DBGVCR32_EL2	24	/* Debug Vector Catch Register */
> -#define	TEECR32_EL1	25	/* ThumbEE Configuration Register */
> -#define	TEEHBR32_EL1	26	/* ThumbEE Handler Base Register */
> -#define	NR_SYS_REGS	27
> +#define	DACR32_EL2	22	/* Domain Access Control Register */
> +#define	IFSR32_EL2	23	/* Instruction Fault Status Register */
> +#define	FPEXC32_EL2	24	/* Floating-Point Exception Control Register */
> +#define	DBGVCR32_EL2	25	/* Debug Vector Catch Register */
> +#define	TEECR32_EL1	26	/* ThumbEE Configuration Register */
> +#define	TEEHBR32_EL1	27	/* ThumbEE Handler Base Register */
> +#define	NR_SYS_REGS	28
>  
>  /* 32bit mapping */
>  #define c0_MPIDR	(MPIDR_EL1 * 2)	/* MultiProcessor ID Register */
> @@ -69,6 +70,8 @@
>  #define c5_AIFSR	(AFSR1_EL1 * 2)	/* Auxiliary Instr Fault Status R */
>  #define c6_DFAR		(FAR_EL1 * 2)	/* Data Fault Address Register */
>  #define c6_IFAR		(c6_DFAR + 1)	/* Instruction Fault Address Register */
> +#define c7_PAR		(PAR_EL1 * 2)	/* Physical Address Register */
> +#define c7_PAR_high	(c7_PAR + 1)	/* PAR top 32 bits */
>  #define c10_PRRR	(MAIR_EL1 * 2)	/* Primary Region Remap Register */
>  #define c10_NMRR	(c10_PRRR + 1)	/* Normal Memory Remap Register */
>  #define c12_VBAR	(VBAR_EL1 * 2)	/* Vector Base Address Register */
> diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
> index ff985e3..218802f 100644
> --- a/arch/arm64/kvm/hyp.S
> +++ b/arch/arm64/kvm/hyp.S
> @@ -214,6 +214,7 @@ __kvm_hyp_code_start:
>  	mrs	x21,	tpidr_el1
>  	mrs	x22, 	amair_el1
>  	mrs	x23, 	cntkctl_el1
> +	mrs	x24,	par_el1
>  
>  	stp	x4, x5, [x3]
>  	stp	x6, x7, [x3, #16]
> @@ -225,6 +226,7 @@ __kvm_hyp_code_start:
>  	stp	x18, x19, [x3, #112]
>  	stp	x20, x21, [x3, #128]
>  	stp	x22, x23, [x3, #144]
> +	str	x24, [x3, #160]
>  .endm
>  
>  .macro restore_sysregs
> @@ -243,6 +245,7 @@ __kvm_hyp_code_start:
>  	ldp	x18, x19, [x3, #112]
>  	ldp	x20, x21, [x3, #128]
>  	ldp	x22, x23, [x3, #144]
> +	ldr	x24, [x3, #160]
>  
>  	msr	vmpidr_el2,	x4
>  	msr	csselr_el1,	x5
> @@ -264,6 +267,7 @@ __kvm_hyp_code_start:
>  	msr	tpidr_el1,	x21
>  	msr	amair_el1,	x22
>  	msr	cntkctl_el1,	x23
> +	msr	par_el1,	x24
>  .endm
>  
>  .macro skip_32bit_state tmp, target
> @@ -753,6 +757,10 @@ el1_trap:
>  	 */
>  	tbnz	x1, #7, 1f	// S1PTW is set
>  
> +	/* Preserve PAR_EL1 */
> +	mrs	x3, par_el1
> +	push	x3, xzr
> +
>  	/*
>  	 * Permission fault, HPFAR_EL2 is invalid.
>  	 * Resolve the IPA the hard way using the guest VA.
> @@ -766,6 +774,8 @@ el1_trap:
>  
>  	/* Read result */
>  	mrs	x3, par_el1
> +	pop	x0, xzr			// Restore PAR_EL1 from the stack
> +	msr	par_el1, x0
>  	tbnz	x3, #0, 3f		// Bail out if we failed the translation
>  	ubfx	x3, x3, #12, #36	// Extract IPA
>  	lsl	x3, x3, #4		// and present it like HPFAR
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 9492360..02e9d09 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -211,6 +211,9 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>  	/* FAR_EL1 */
>  	{ Op0(0b11), Op1(0b000), CRn(0b0110), CRm(0b0000), Op2(0b000),
>  	  NULL, reset_unknown, FAR_EL1 },
> +	/* PAR_EL1 */
> +	{ Op0(0b11), Op1(0b000), CRn(0b0111), CRm(0b0100), Op2(0b000),
> +	  NULL, reset_unknown, PAR_EL1 },
>  
>  	/* PMINTENSET_EL1 */
>  	{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b001),
> -- 
> 1.8.2.3
> 
> 

Looks good to me,
-Christoffer


From gregkh at linuxfoundation.org  Sat Jul 20 18:00:06 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Sat, 20 Jul 2013 15:00:06 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51EA01C4.2010006@ti.com>
References: <20130718072004.GA16720@kroah.com> <51E7AE88.3050007@ti.com>
 <20130718154954.GA31961@kroah.com> <51E8D086.809@ti.com>
 <20130719054311.GA14638@kroah.com> <51E8D4E0.8060200@ti.com>
 <20130719062941.GA23611@kroah.com> <51E8DE51.1060404@ti.com>
 <20130719235055.GB11498@kroah.com> <51EA01C4.2010006@ti.com>
Message-ID: <20130720220006.GA7977@kroah.com>

On Sat, Jul 20, 2013 at 08:49:32AM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Saturday 20 July 2013 05:20 AM, Greg KH wrote:
> >On Fri, Jul 19, 2013 at 12:06:01PM +0530, Kishon Vijay Abraham I wrote:
> >>Hi,
> >>
> >>On Friday 19 July 2013 11:59 AM, Greg KH wrote:
> >>>On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote:
> >>>>Hi,
> >>>>
> >>>>On Friday 19 July 2013 11:13 AM, Greg KH wrote:
> >>>>>On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote:
> >>>>>>>>>>+	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
> >>>>>>>>>
> >>>>>>>>>Your naming is odd, no "phy" anywhere in it?  You rely on the sender to
> >>>>>>>>>never send a duplicate name.id pair?  Why not create your own ids based
> >>>>>>>>>on the number of phys in the system, like almost all other classes and
> >>>>>>>>>subsystems do?
> >>>>>>>>
> >>>>>>>>hmm.. some PHY drivers use the id they provide to perform some of their
> >>>>>>>>internal operation as in [1] (This is used only if a single PHY provider
> >>>>>>>>implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO
> >>>>>>>>to give the PHY drivers an option to use auto id.
> >>>>>>>>
> >>>>>>>>[1] ->
> >>>>>>>>http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> >>>>>>>
> >>>>>>>No, who cares about the id?  No one outside of the phy core ever should,
> >>>>>>>because you pass back the only pointer that they really do care about,
> >>>>>>>if they need to do anything with the device.  Use that, and then you can
> >>>>>>
> >>>>>>hmm.. ok.
> >>>>>>
> >>>>>>>rip out all of the "search for a phy by a string" logic, as that's not
> >>>>>>
> >>>>>>Actually this is needed for non-dt boot case. In the case of dt boot, we use a
> >>>>>>phandle by which the controller can get a reference to the phy. But in the case
> >>>>>>of non-dt boot, the controller can get a reference to the phy only by label.
> >>>>>
> >>>>>I don't understand.  They registered the phy, and got back a pointer to
> >>>>>it.  Why can't they save it in their local structure to use it again
> >>>>>later if needed?  They should never have to "ask" for the device, as the
> >>>>
> >>>>One is a *PHY provider* driver which is a driver for some PHY device. This will
> >>>>use phy_create to create the phy.
> >>>>The other is a *PHY consumer* driver which might be any controller driver (can
> >>>>be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference to the
> >>>>phy (by *phandle* in the case of dt boot and *label* in the case of non-dt boot).
> >>>>>device id might be unknown if there are multiple devices in the system.
> >>>>
> >>>>I agree with you on the device id part. That need not be known to the PHY driver.
> >>>
> >>>How does a consumer know which "label" to use in a non-dt system if
> >>>there are multiple PHYs in the system?
> >>
> >>That should be passed using platform data.
> >
> >Ick, don't pass strings around, pass pointers.  If you have platform
> >data you can get to, then put the pointer there, don't use a "name".
> 
> I don't think I understood you here :-s We wont have phy pointer
> when we create the device for the controller no?(it'll be done in
> board file). Probably I'm missing something.

Why will you not have that pointer?  You can't rely on the "name" as the
device id will not match up, so you should be able to rely on the
pointer being in the structure that the board sets up, right?

Don't use names, especially as ids can, and will, change, that is going
to cause big problems.  Use pointers, this is C, we are supposed to be
doing that :)

thanks,

greg k-h


From christoffer.dall at linaro.org  Sat Jul 20 18:04:05 2013
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Sat, 20 Jul 2013 23:04:05 +0100
Subject: [PATCH 3/4] arm64: KVM: let other tasks run when hitting WFE
In-Reply-To: <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130720220405.GC35165@lvm>

On Fri, Jul 19, 2013 at 02:53:54PM +0100, Marc Zyngier wrote:
> So far, when a guest executes WFE (like when waiting for a spinlock
> to become unlocked), we don't do a thing and let it run uninterrupted.
> 
> Another option is to trap a blocking WFE and offer the opportunity
> to the scheduler to switch to another task, potentially giving the
> vcpu holding the spinlock a chance to run sooner.
> 

I'm curious if we have any data supporting this to be a good idea?

My intuition here is that waiting for a spinlock really shouldn't be
something a guest is doing for a long time - we always try to avoid too
much contention on spinlocks, no?  The theory that it would unlock the
spinlock sooner is really only supported if the CPU resources are
grossly oversubscribed - are we optimizing for this case?

So, how many cycles do we anticipate a world-switch back and forward
between a VM and the host to be compared to the average number of spin
cycles for a spinlock?

Finally, for the case where a waiting vcpu is only going to spin for a
couple of cycles, aren't we adding significant overhead?  I would expect
this to be the most common case.


> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/kvm_arm.h |  6 ++++--
>  arch/arm64/kvm/handle_exit.c     | 18 +++++++++++++-----
>  2 files changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index a5f28e2..ac1ea05 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -63,6 +63,7 @@
>   * TAC:		Trap ACTLR
>   * TSC:		Trap SMC
>   * TSW:		Trap cache operations by set/way
> + * TWE:		Trap WFE
>   * TWI:		Trap WFI
>   * TIDCP:	Trap L2CTLR/L2ECTLR
>   * BSU_IS:	Upgrade barriers to the inner shareable domain
> @@ -72,8 +73,9 @@
>   * FMO:		Override CPSR.F and enable signaling with VF
>   * SWIO:	Turn set/way invalidates into set/way clean+invalidate
>   */
> -#define HCR_GUEST_FLAGS (HCR_TSC | HCR_TSW | HCR_TWI | HCR_VM | HCR_BSU_IS | \
> -			 HCR_FB | HCR_TAC | HCR_AMO | HCR_IMO | HCR_FMO | \
> +#define HCR_GUEST_FLAGS (HCR_TSC | HCR_TSW | HCR_TWE | HCR_TWI | HCR_VM | \
> +			 HCR_BSU_IS | HCR_FB | HCR_TAC | \
> +			 HCR_AMO | HCR_IMO | HCR_FMO | \
>  			 HCR_SWIO | HCR_TIDCP | HCR_RW)
>  #define HCR_VIRT_EXCP_MASK (HCR_VA | HCR_VI | HCR_VF)
>  
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 9beaca03..b0098c2 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -47,21 +47,29 @@ static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  }
>  
>  /**
> - * kvm_handle_wfi - handle a wait-for-interrupts instruction executed by a guest
> + * kvm_handle_wfx - handle a wait-for-interrupts or wait-for-event
> + *		    instruction executed by a guest
> + *
>   * @vcpu:	the vcpu pointer
>   *
> - * Simply call kvm_vcpu_block(), which will halt execution of
> + * WFE: Yield the CPU and come back to this vcpu when the scheduler
> + * decides to.
> + * WFI: Simply call kvm_vcpu_block(), which will halt execution of
>   * world-switches and schedule other host processes until there is an
>   * incoming IRQ or FIQ to the VM.
>   */
> -static int kvm_handle_wfi(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  {
> -	kvm_vcpu_block(vcpu);
> +	if (kvm_vcpu_get_hsr(vcpu) & 1)
> +		cond_resched();
> +	else
> +		kvm_vcpu_block(vcpu);
> +
>  	return 1;
>  }
>  
>  static exit_handle_fn arm_exit_handlers[] = {
> -	[ESR_EL2_EC_WFI]	= kvm_handle_wfi,
> +	[ESR_EL2_EC_WFI]	= kvm_handle_wfx,
>  	[ESR_EL2_EC_CP15_32]	= kvm_handle_cp15_32,
>  	[ESR_EL2_EC_CP15_64]	= kvm_handle_cp15_64,
>  	[ESR_EL2_EC_CP14_MR]	= kvm_handle_cp14_access,
> -- 
> 1.8.2.3
> 
> 

-- 
Christoffer


From linus.walleij at linaro.org  Sat Jul 20 18:44:21 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 21 Jul 2013 00:44:21 +0200
Subject: Issue with gpio and pinmux
In-Reply-To: <51E82FBB.1080905@wwwdotorg.org>
References: <51E667BC.3070804@parrot.com>
	<51E82FBB.1080905@wwwdotorg.org>
Message-ID: <CACRpkdb1n07KoQZSme1EMJfV-9pHr-kd_1eJ6HsBV5gz7Dh3Ww@mail.gmail.com>

On Thu, Jul 18, 2013 at 8:11 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:

> The issue is that some HW muxes groups of pins at a time, so simply
> because that group of pins is "claimed" by a mux function, implies
> nothing about which specific pins in that group are actually used; some
> may actually still be free for usage as a GPIO.

This we need to get into the documentation.

> The solution here may be one of:
>
> a) Modify pinctrl /not/ to allow both a GPIO and a mux function to claim
> a pin *if* the group that contains the pin only contains a single pin.
> This is a bit of a hacky special case though; there are other situations
> where "dual claiming" shouldn't be allowed, and this doesn't solve those.
>
> b) Ignore the issue; if the system configuration is correct, the issue
> won't cause problems in practice, since nothing will be configured to
> "dual claim" any pin.
>
> c) Enhance pinctrl with extra information, so it knows which pins in a
> group are usable as GPIO even when the group is claimed by a mux
> function. The list of pins could theoretically vary per mux function, so
> you'd need a table with lookup key (pin group, mux function) and output
> data (list of pins that can be "dual claimed"). This would be a complete
> solution. If a list wasn't provided, the pinctrl core could assume that
> mean no dual claim was allowed.

I guess (b) is what we have.

But it really feels incomplete does it not? IIRC the system was strict
not to allow simultaneous use of pins for GPIO and other functions
at all until the above corner case made it necessary to relax this
restriction.

A simple way to get (a) would be to just add a flag like ".strict"
to struct pinmux_ops but it feels cheap.

What do we need for (c)? I think we can refactor this as the Tegra
and U300 should be the two platforms with such tricky groups so
the impact should be fairly small right now. I'm just worried it would
be a complex and memory-consuming thing :-/

Yours,
Linus Walleij


From andrea.adami at gmail.com  Sat Jul 20 19:07:36 2013
From: andrea.adami at gmail.com (Andrea Adami)
Date: Sun, 21 Jul 2013 01:07:36 +0200
Subject: [PATCH] sa1100: collie: fall back to jedec_probe flash detection
Message-ID: <1374361656-3034-1-git-send-email-andrea.adami@gmail.com>

Zaurus 5500 contains 2 LH28F640BFHE-PTTL90 (64M 4Mx16) and
the LH28F640BFHE-PTTL90.pdf datasheet available on the net shows
the exact erasesize and the OTP support.
At the moment only jedec_probe can discover the chip and
the NOR is mounted read only probably because of wrong vpp.

Signed-off-by: Andrea Adami <andrea.adami at gmail.com>
---
 arch/arm/mach-sa1100/collie.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-sa1100/collie.c b/arch/arm/mach-sa1100/collie.c
index 612a456..7fb96eb 100644
--- a/arch/arm/mach-sa1100/collie.c
+++ b/arch/arm/mach-sa1100/collie.c
@@ -289,7 +289,7 @@ static void collie_flash_exit(void)
 }
 
 static struct flash_platform_data collie_flash_data = {
-	.map_name	= "cfi_probe",
+	.map_name	= "jedec_probe",
 	.init		= collie_flash_init,
 	.set_vpp	= collie_set_vpp,
 	.exit		= collie_flash_exit,
-- 
1.8.1.5



From andrea.adami at gmail.com  Sat Jul 20 19:07:50 2013
From: andrea.adami at gmail.com (Andrea Adami)
Date: Sun, 21 Jul 2013 01:07:50 +0200
Subject: [PATCH] pxa: sharpsl_param: fix invalid memory access in
 sharpsl_save_param()
Message-ID: <1374361670-3214-1-git-send-email-andrea.adami@gmail.com>

From: Marko Katic <dromede at gmail.com>

Unbreak kernel boot (tested with kexecboot)

Patch was sent twice upstrream:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137284.html
Devices that call sharpsl_save_param() will hang on boot due to
a memcpy call that uses a physical address that is no longer * accessible. Fix
his by converting the physical address into a virtual one.

Signed-off-by: Marko Katic <dromede at gmail.com>
[andrea.adami at gmail.com: checkpatch.pl dislikes void * param_start]
Signed-off-by: Andrea Adami <andrea.adami at gmail.com>
---
 arch/arm/common/sharpsl_param.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/common/sharpsl_param.c b/arch/arm/common/sharpsl_param.c
index d56c932..b70b13a 100644
--- a/arch/arm/common/sharpsl_param.c
+++ b/arch/arm/common/sharpsl_param.c
@@ -14,6 +14,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/string.h>
+#include <asm/memory.h>
 #include <asm/mach/sharpsl_param.h>
 
 /*
@@ -41,7 +42,8 @@ EXPORT_SYMBOL(sharpsl_param);
 
 void sharpsl_save_param(void)
 {
-	memcpy(&sharpsl_param, (void *)PARAM_BASE, sizeof(struct sharpsl_param_info));
+	void *param_start = phys_to_virt(PARAM_BASE);
+	memcpy(&sharpsl_param, param_start, sizeof(struct sharpsl_param_info));
 
 	if (sharpsl_param.comadj_keyword != COMADJ_MAGIC)
 		sharpsl_param.comadj=-1;
-- 
1.8.1.5



From domenico.andreoli at linux.com  Sat Jul 20 20:23:24 2013
From: domenico.andreoli at linux.com (Domenico Andreoli)
Date: Sun, 21 Jul 2013 02:23:24 +0200
Subject: [PATCH 4/5] ARM: bcm4760: Add stub clock driver
References: <20130721002320.730568671@gmail.com>
Message-ID: <20130721002714.459727324@gmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: arm-bcm476x-add-stub-clock-driver.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130721/df7477dd/attachment.ksh>

From domenico.andreoli at linux.com  Sat Jul 20 20:23:23 2013
From: domenico.andreoli at linux.com (Domenico Andreoli)
Date: Sun, 21 Jul 2013 02:23:23 +0200
Subject: [PATCH 3/5] ARM: bcm4760: Add ripple counter
References: <20130721002320.730568671@gmail.com>
Message-ID: <20130721002714.188757389@gmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: arm-bcm476x-add-ripple-counter.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130721/b6173d51/attachment.ksh>

From domenico.andreoli at linux.com  Sat Jul 20 20:23:20 2013
From: domenico.andreoli at linux.com (Domenico Andreoli)
Date: Sun, 21 Jul 2013 02:23:20 +0200
Subject: [PATCH 0/5] ARM: Broadcom BCM4760 support
Message-ID: <20130721002320.730568671@gmail.com>

Hi all,

  I've refreshed this patchset to add the Broadcom BCM4760 SoC. It's
the bare minimum required to boot to the console.

Given the amount of Broadcom SoCs merged or being reviewed (and their
crazy and inconsistent names), I've decided to drop the BCM476X naming
I used before and stick with BCM4760.

Previous spin collected acked-by from Olof and Arnd but some time passed
and I cannot assume they have nothing new to comment.

Please give another glance to this smaller and smaller minimum patchset.

Best regards,
Domenico


From domenico.andreoli at linux.com  Sat Jul 20 20:23:25 2013
From: domenico.andreoli at linux.com (Domenico Andreoli)
Date: Sun, 21 Jul 2013 02:23:25 +0200
Subject: [PATCH 5/5] ARM: bcm4760: Add restart hook
References: <20130721002320.730568671@gmail.com>
Message-ID: <20130721002714.732402573@gmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: arm-bcm476x-add-restart-hook.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130721/c8074cc3/attachment.ksh>

From domenico.andreoli at linux.com  Sat Jul 20 20:23:22 2013
From: domenico.andreoli at linux.com (Domenico Andreoli)
Date: Sun, 21 Jul 2013 02:23:22 +0200
Subject: [PATCH 2/5] ARM: bcm4760: Add system timer
References: <20130721002320.730568671@gmail.com>
Message-ID: <20130721002713.813400062@gmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: arm-bcm476x-add-system-timer.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130721/af8ec12f/attachment.ksh>

From domenico.andreoli at linux.com  Sat Jul 20 20:23:21 2013
From: domenico.andreoli at linux.com (Domenico Andreoli)
Date: Sun, 21 Jul 2013 02:23:21 +0200
Subject: [PATCH 1/5] ARM: bcm4760: Add platform infrastructure
References: <20130721002320.730568671@gmail.com>
Message-ID: <20130721002713.512199844@gmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: arm-bcm476x-add-infrastructure.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130721/1ddfe7cb/attachment.ksh>

From ebiederm at xmission.com  Sat Jul 20 21:40:14 2013
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Sat, 20 Jul 2013 18:40:14 -0700
Subject: [PATCH] ARM: kexec: validate CPU hotplug support
In-Reply-To: <1373582931-11956-1-git-send-email-swarren@wwwdotorg.org>
 (Stephen Warren's message of "Thu, 11 Jul 2013 16:48:51 -0600")
References: <1373582931-11956-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <87ehas7ksh.fsf@xmission.com>

Stephen Warren <swarren at wwwdotorg.org> writes:

> From: Stephen Warren <swarren at nvidia.com>
>
> Architectures should fully validate whether kexec is possible as part of
> machine_kexec_prepare(), so that user-space's kexec_load() operation can
> report any problems. Performing validation in machine_kexec() itself is
> too late, since it is not allowed to return.
>
> Prior to this patch, ARM's machine_kexec() was testing after-the-fact
> whether machine_kexec_prepare() was able to disable all but one CPU.
> Instead, modify machine_kexec_prepare() to validate all conditions
> necessary for machine_kexec_prepare()'s to succeed. BUG if the validation
> succeeded, yet disabling the CPUs didn't actually work.
>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>

At a quick skim this looks good to me.

Acked-by: "Eric W. Biederman" <ebiederm at xmission.com>

> ---
> Russell, does it make sense for this to be cc: stable as a follow-up to
> 19ab428 "ARM: 7759/1: decouple CPU offlining from reboot/shutdown"?
>
>  arch/arm/include/asm/smp_plat.h |  3 +++
>  arch/arm/kernel/machine_kexec.c | 20 ++++++++++++++++----
>  arch/arm/kernel/smp.c           |  8 ++++++++
>  3 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
> index 6462a72..a252c0b 100644
> --- a/arch/arm/include/asm/smp_plat.h
> +++ b/arch/arm/include/asm/smp_plat.h
> @@ -88,4 +88,7 @@ static inline u32 mpidr_hash_size(void)
>  {
>  	return 1 << mpidr_hash.bits;
>  }
> +
> +extern int platform_can_cpu_hotplug(void);
> +
>  #endif
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index 4fb074c..d7c82df 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -15,6 +15,7 @@
>  #include <asm/mmu_context.h>
>  #include <asm/cacheflush.h>
>  #include <asm/mach-types.h>
> +#include <asm/smp_plat.h>
>  #include <asm/system_misc.h>
>  
>  extern const unsigned char relocate_new_kernel[];
> @@ -39,6 +40,14 @@ int machine_kexec_prepare(struct kimage *image)
>  	int i, err;
>  
>  	/*
> +	 * Validate that if the current HW supports SMP, then the SW supports
> +	 * and implements CPU hotplug for the current HW. If not, we won't be
> +	 * able to kexec reliably, so fail the prepare operation.
> +	 */
> +	if (num_possible_cpus() > 1 && !platform_can_cpu_hotplug())
> +		return -EINVAL;
> +
> +	/*
>  	 * No segment at default ATAGs address. try to locate
>  	 * a dtb using magic.
>  	 */
> @@ -134,10 +143,13 @@ void machine_kexec(struct kimage *image)
>  	unsigned long reboot_code_buffer_phys;
>  	void *reboot_code_buffer;
>  
> -	if (num_online_cpus() > 1) {
> -		pr_err("kexec: error: multiple CPUs still online\n");
> -		return;
> -	}
> +	/*
> +	 * This can only happen if machine_shutdown() failed to disable some
> +	 * CPU, and that can only happen if the checks in
> +	 * machine_kexec_prepare() were not correct. If this fails, we can't
> +	 * reliably kexec anyway, so BUG_ON is appropriate.
> +	 */
> +	BUG_ON(num_online_cpus() > 1);
>  
>  	page_list = image->head & PAGE_MASK;
>  
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index c2b4f8f..5b9e501 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -145,6 +145,14 @@ int boot_secondary(unsigned int cpu, struct task_struct *idle)
>  	return -ENOSYS;
>  }
>  
> +int platform_can_cpu_hotplug(void)
> +{
> +	if (!IS_ENABLED(CONFIG_HOTPLUG_CPU) || !smp_ops.cpu_kill)
> +		return 0;
> +
> +	return 1;
> +}
> +
>  #ifdef CONFIG_HOTPLUG_CPU
>  static void percpu_timer_stop(void);


From stern at rowland.harvard.edu  Sat Jul 20 22:32:26 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Sat, 20 Jul 2013 22:32:26 -0400 (EDT)
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130720220006.GA7977@kroah.com>
Message-ID: <Pine.LNX.4.44L0.1307202223430.8250-100000@netrider.rowland.org>

On Sat, 20 Jul 2013, Greg KH wrote:

> > >>That should be passed using platform data.
> > >
> > >Ick, don't pass strings around, pass pointers.  If you have platform
> > >data you can get to, then put the pointer there, don't use a "name".
> > 
> > I don't think I understood you here :-s We wont have phy pointer
> > when we create the device for the controller no?(it'll be done in
> > board file). Probably I'm missing something.
> 
> Why will you not have that pointer?  You can't rely on the "name" as the
> device id will not match up, so you should be able to rely on the
> pointer being in the structure that the board sets up, right?
> 
> Don't use names, especially as ids can, and will, change, that is going
> to cause big problems.  Use pointers, this is C, we are supposed to be
> doing that :)

Kishon, I think what Greg means is this:  The name you are using must
be stored somewhere in a data structure constructed by the board file,
right?  Or at least, associated with some data structure somehow.  
Otherwise the platform code wouldn't know which PHY hardware
corresponded to a particular name.

Greg's suggestion is that you store the address of that data structure 
in the platform data instead of storing the name string.  Have the 
consumer pass the data structure's address when it calls phy_create, 
instead of passing the name.  Then you don't have to worry about two 
PHYs accidentally ending up with the same name or any other similar 
problems.

Alan Stern



From rizhao at nvidia.com  Sat Jul 20 22:34:09 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Sun, 21 Jul 2013 10:34:09 +0800
Subject: [PATCH] ASoC: tegra: correct playback_dma_data setup
Message-ID: <1374374049-30732-1-git-send-email-rizhao@nvidia.com>

The errors were caused by copy/paste mistake in below commit
since v3.10:
3489d50 ASoC: tegra: Use common DAI DMA data struct

It also corrects slave_id initialization in tegra20_ac97 driver.

Signed-off-by: Richard Zhao <rizhao at nvidia.com>
Cc: Lars-Peter Clausen <lars at metafoo.de>
Cc: <stable at vger.kernel.org> # 3.10
---
 sound/soc/tegra/tegra20_ac97.c  | 6 +++---
 sound/soc/tegra/tegra20_spdif.c | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/sound/soc/tegra/tegra20_ac97.c b/sound/soc/tegra/tegra20_ac97.c
index e58233f..6c48662 100644
--- a/sound/soc/tegra/tegra20_ac97.c
+++ b/sound/soc/tegra/tegra20_ac97.c
@@ -389,9 +389,9 @@ static int tegra20_ac97_platform_probe(struct platform_device *pdev)
 	ac97->capture_dma_data.slave_id = of_dma[1];
 
 	ac97->playback_dma_data.addr = mem->start + TEGRA20_AC97_FIFO_TX1;
-	ac97->capture_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-	ac97->capture_dma_data.maxburst = 4;
-	ac97->capture_dma_data.slave_id = of_dma[0];
+	ac97->playback_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+	ac97->playback_dma_data.maxburst = 4;
+	ac97->playback_dma_data.slave_id = of_dma[1];
 
 	ret = tegra_asoc_utils_init(&ac97->util_data, &pdev->dev);
 	if (ret)
diff --git a/sound/soc/tegra/tegra20_spdif.c b/sound/soc/tegra/tegra20_spdif.c
index 5eaa12c..551b3c9 100644
--- a/sound/soc/tegra/tegra20_spdif.c
+++ b/sound/soc/tegra/tegra20_spdif.c
@@ -323,8 +323,8 @@ static int tegra20_spdif_platform_probe(struct platform_device *pdev)
 	}
 
 	spdif->playback_dma_data.addr = mem->start + TEGRA20_SPDIF_DATA_OUT;
-	spdif->capture_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-	spdif->capture_dma_data.maxburst = 4;
+	spdif->playback_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+	spdif->playback_dma_data.maxburst = 4;
 	spdif->playback_dma_data.slave_id = dmareq->start;
 
 	pm_runtime_enable(&pdev->dev);
-- 
1.8.1.5



From gregkh at linuxfoundation.org  Sat Jul 20 22:59:10 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Sat, 20 Jul 2013 19:59:10 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <Pine.LNX.4.44L0.1307202223430.8250-100000@netrider.rowland.org>
References: <20130720220006.GA7977@kroah.com>
 <Pine.LNX.4.44L0.1307202223430.8250-100000@netrider.rowland.org>
Message-ID: <20130721025910.GA23043@kroah.com>

On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
> On Sat, 20 Jul 2013, Greg KH wrote:
> 
> > > >>That should be passed using platform data.
> > > >
> > > >Ick, don't pass strings around, pass pointers.  If you have platform
> > > >data you can get to, then put the pointer there, don't use a "name".
> > > 
> > > I don't think I understood you here :-s We wont have phy pointer
> > > when we create the device for the controller no?(it'll be done in
> > > board file). Probably I'm missing something.
> > 
> > Why will you not have that pointer?  You can't rely on the "name" as the
> > device id will not match up, so you should be able to rely on the
> > pointer being in the structure that the board sets up, right?
> > 
> > Don't use names, especially as ids can, and will, change, that is going
> > to cause big problems.  Use pointers, this is C, we are supposed to be
> > doing that :)
> 
> Kishon, I think what Greg means is this:  The name you are using must
> be stored somewhere in a data structure constructed by the board file,
> right?  Or at least, associated with some data structure somehow.  
> Otherwise the platform code wouldn't know which PHY hardware
> corresponded to a particular name.
> 
> Greg's suggestion is that you store the address of that data structure 
> in the platform data instead of storing the name string.  Have the 
> consumer pass the data structure's address when it calls phy_create, 
> instead of passing the name.  Then you don't have to worry about two 
> PHYs accidentally ending up with the same name or any other similar 
> problems.

Close, but the issue is that whatever returns from phy_create() should
then be used, no need to call any "find" functions, as you can just use
the pointer that phy_create() returns.  Much like all other class api
functions in the kernel work.

thanks,

greg k-h


From swarren at wwwdotorg.org  Sat Jul 20 23:44:10 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Sat, 20 Jul 2013 21:44:10 -0600
Subject: Issue with gpio and pinmux
In-Reply-To: <CACRpkdb1n07KoQZSme1EMJfV-9pHr-kd_1eJ6HsBV5gz7Dh3Ww@mail.gmail.com>
References: <51E667BC.3070804@parrot.com> <51E82FBB.1080905@wwwdotorg.org>
 <CACRpkdb1n07KoQZSme1EMJfV-9pHr-kd_1eJ6HsBV5gz7Dh3Ww@mail.gmail.com>
Message-ID: <51EB590A.4010600@wwwdotorg.org>

On 07/20/2013 04:44 PM, Linus Walleij wrote:
> On Thu, Jul 18, 2013 at 8:11 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> 
>> The issue is that some HW muxes groups of pins at a time, so simply
>> because that group of pins is "claimed" by a mux function, implies
>> nothing about which specific pins in that group are actually used; some
>> may actually still be free for usage as a GPIO.
> 
> This we need to get into the documentation.
> 
>> The solution here may be one of:
>>
>> a) Modify pinctrl /not/ to allow both a GPIO and a mux function to claim
>> a pin *if* the group that contains the pin only contains a single pin.
>> This is a bit of a hacky special case though; there are other situations
>> where "dual claiming" shouldn't be allowed, and this doesn't solve those.
>>
>> b) Ignore the issue; if the system configuration is correct, the issue
>> won't cause problems in practice, since nothing will be configured to
>> "dual claim" any pin.
>>
>> c) Enhance pinctrl with extra information, so it knows which pins in a
>> group are usable as GPIO even when the group is claimed by a mux
>> function. The list of pins could theoretically vary per mux function, so
>> you'd need a table with lookup key (pin group, mux function) and output
>> data (list of pins that can be "dual claimed"). This would be a complete
>> solution. If a list wasn't provided, the pinctrl core could assume that
>> mean no dual claim was allowed.
> 
> I guess (b) is what we have.
> 
> But it really feels incomplete does it not? IIRC the system was strict
> not to allow simultaneous use of pins for GPIO and other functions
> at all until the above corner case made it necessary to relax this
> restriction.
> 
> A simple way to get (a) would be to just add a flag like ".strict"
> to struct pinmux_ops but it feels cheap.
> 
> What do we need for (c)? I think we can refactor this as the Tegra
> and U300 should be the two platforms with such tricky groups so
> the impact should be fairly small right now. I'm just worried it would
> be a complex and memory-consuming thing :-/

Actually, a better way to do (c) might be to just add an extra "op" to
struct pinmux_ops; something like validate_gpio_mux(), passing in
information such as whether a mux function is in effect on that pin,
whether the pin is already claimed as a GPIO, and whether the function
is being called to check a GPIO-claim or mux-claim operation . If the op
is missing, no "dual claim" is allowed. If the op is present, the code
in the op validates whether the particular GPIO is allowed to be claimed
while the particular mux function is active.

That way, I think any driver that doesn't want to allow dual-claim
doesn't have to do anything, but the few drivers that do can code up
whatever algorithm they want; for Tegra, I'd just allow everything for
simplicity, but we could always enhance that later if we want.


From swarren at wwwdotorg.org  Sat Jul 20 23:55:26 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Sat, 20 Jul 2013 21:55:26 -0600
Subject: [PATCH] ASoC: tegra: correct playback_dma_data setup
In-Reply-To: <1374374049-30732-1-git-send-email-rizhao@nvidia.com>
References: <1374374049-30732-1-git-send-email-rizhao@nvidia.com>
Message-ID: <51EB5BAE.2070306@wwwdotorg.org>

On 07/20/2013 08:34 PM, Richard Zhao wrote:
> The errors were caused by copy/paste mistake in below commit
> since v3.10:
> 3489d50 ASoC: tegra: Use common DAI DMA data struct
> 
> It also corrects slave_id initialization in tegra20_ac97 driver.

Acked-by: Stephen Warren <swarren at nvidia.com>

Hmm, that's what I get for only testing I2S and not SPDIF or AC'97 (not
that I can test the latter).


From shc_work at mail.ru  Sun Jul 21 00:11:38 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sun, 21 Jul 2013 08:11:38 +0400
Subject: [PATCH 08/10] ARM: clps711x: Add CLPS711X cpuidle driver
In-Reply-To: <51EB0433.3050308@linaro.org>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
 <1374172501-26796-9-git-send-email-shc_work@mail.ru>
 <51EB0433.3050308@linaro.org>
Message-ID: <20130721081138.75cf5437bc30f42284f12e47@mail.ru>

On Sat, 20 Jul 2013 23:42:11 +0200
Daniel Lezcano <daniel.lezcano at linaro.org> wrote:

> On 07/18/2013 08:34 PM, Alexander Shiyan wrote:
> > This adds the cpuidle driver for Cirrus Logic CLPS711X series SoCs.
> > Designed primarily for migration CLPS711X subarch for multiplatform & DT.
> > 
> > Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> > ---
> >  drivers/cpuidle/Kconfig            |  6 +++
> >  drivers/cpuidle/Makefile           |  1 +
> >  drivers/cpuidle/cpuidle-clps711x.c | 80 ++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 87 insertions(+)
> >  create mode 100644 drivers/cpuidle/cpuidle-clps711x.c
[...]
> > +static int clps711x_cpuidle_halt(struct cpuidle_device *dev,
> > +				 struct cpuidle_driver *drv, int index)
> > +{
> > +	writel(1, clps711x_halt);
> 
> In what the 'clps711x_halt' differs from the usual WFI (cpu_do_idle) ?

AFAIK, ARM720T does not implement the WFI instruction.
"HALT" register in CLPS711X do the same:
"A write to this location will put the system into the Idle State by
halting the clock to the processor until an interrupt is generated."

> > +	asm volatile ("mov r0, r0");
> > +	asm volatile ("mov r0, r0");
> 
> Why are needed these two volatile ?

Two NOP instructions necessary following the enable or disable of the MMU.
Documentation not say anything about using this for "HALT", maybe it's the
remnants of the old code. I will remove it.

[...]
> > +static int clps711x_cpuidle_remove(struct platform_device *pdev)
> > +{
> > +	cpuidle_unregister(&clps711x_idle_driver);
> > +
> > +	return 0;
> > +}
> 
> The driver is not compiled as module, will this function be called ?

You're right. I will remove it.

> > +static const struct of_device_id clps711x_cpuidle_dt_ids[] = {
> > +	{ .compatible = "cirrus,clps711x-cpuidle", },
> > +	{ }
> > +};
> > +MODULE_DEVICE_TABLE(of, clps711x_cpuidle_dt_ids);
> > +
> > +static struct platform_driver clps711x_cpuidle_driver = {
> > +	.driver	= {
> > +		.name		= "clps711x-cpuidle",
> > +		.owner		= THIS_MODULE,
> > +		.of_match_table	= clps711x_cpuidle_dt_ids,
> > +	},
> > +	.remove	= clps711x_cpuidle_remove,
> > +};
> > +module_platform_driver_probe(clps711x_cpuidle_driver, clps711x_cpuidle_probe);
> 
> +1

??? What here?

[...]

-- 
Alexander Shiyan <shc_work at mail.ru>


From shc_work at mail.ru  Sun Jul 21 00:30:11 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sun, 21 Jul 2013 08:30:11 +0400
Subject: [PATCH 06/10] ARM: clps711x: Add CLPS711X clocksource driver
In-Reply-To: <51EB05AE.2050105@linaro.org>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
 <1374172501-26796-7-git-send-email-shc_work@mail.ru>
 <51E94F7E.4030404@linaro.org>
 <20130720074441.9882b71183e5eadd535da6c1@mail.ru>
 <51EB05AE.2050105@linaro.org>
Message-ID: <20130721083011.7988b08426c022d03269c223@mail.ru>

On Sat, 20 Jul 2013 23:48:30 +0200
Daniel Lezcano <daniel.lezcano at linaro.org> wrote:

> On 07/20/2013 05:44 AM, Alexander Shiyan wrote:
> > On Fri, 19 Jul 2013 16:38:54 +0200
> > Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
> >> (Added Thomas and John in Cc in case they want to review the patch).
> >>
> >> On 07/18/2013 08:34 PM, Alexander Shiyan wrote:
> >>> This adds the clocksource driver for Cirrus Logic CLPS711X series SoCs.
> >>> Designed primarily for migration CLPS711X subarch for multiplatform & DT,
> >>> for this as the "OF" and "not-OF" calls implemented.
[...]
> >>> +static struct irqaction clps711x_timer_irq = {
> >>> +	.name		= "clps711x-timer",
> >>> +	.flags		= IRQF_TIMER | IRQF_IRQPOLL,
> >>
> >> Why do you need IRQF_IRQPOOL ?
> > 
> > linux/interrupt.h:
> >  * IRQF_IRQPOLL - Interrupt is used for polling (only the interrupt that is
> >  *                registered first in an shared interrupt is considered for
> >  *                performance reasons)
> > 
> > I do not see need this flag, but in fact, this flag is traditionally used
> > in almost all subsystems of this type.
> 
> So IIUC, IRQPOLL is to switch to polling mode when a lot of interrupts
> occur, right ?

I'm also not an expert on these flags, but realized appointment just like you.

> >>> +	tmp = readl(syscon1);
> >>> +	/* TC1 in free running mode */
> >>> +	tmp &= ~SYSCON1_TC1M;
> >>> +	/* TC2 in prescale mode */
> >>> +	tmp |= SYSCON1_TC2M;
> >>> +	writel(tmp, syscon1);
> >>
> >> Could you encapsulate these calls inside a static inline function with a
> >> more detailed comment please ?
> > 
> > Why static inline?
> > There is a comment line for each bit, You think this is not enough?
> 
> I prefer to encapsulate readl/writel calls inside a small function with
> an explicit name, comments are still welcome.

Ok.

[...]

-- 
Alexander Shiyan <shc_work at mail.ru>


From thierry.reding at gmail.com  Sun Jul 21 02:35:34 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Sun, 21 Jul 2013 08:35:34 +0200
Subject: [PATCH] of: match the compatible in the order set by the dts file
In-Reply-To: <20130720054439.308B33E13F0@localhost>
References: <1373013818-11365-1-git-send-email-b32955@freescale.com>
 <20130709070541.GQ516@pengutronix.de>
 <51DBBFDA.70302@freescale.com>
 <20130709075124.GR516@pengutronix.de>
 <51DBC58D.90002@freescale.com>
 <20130720054439.308B33E13F0@localhost>
Message-ID: <20130721063531.GA16516@mithrandir>

On Sat, Jul 20, 2013 at 06:44:39AM +0100, Grant Likely wrote:
> On Tue, 9 Jul 2013 16:10:53 +0800, Huang Shijie <b32955 at freescale.com> wrote:
> > ? 2013?07?09? 15:51, Sascha Hauer ??:
> > > On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
> > >> ? 2013?07?09? 15:05, Sascha Hauer ??:
> > >>> Why don't you set the matching order in the driver the way you want it
> > >>> to be, i.e.:
> > >>>
> > >>> 	{ .compatible = "fsl,imx6q-uart", ... },
> > >>> 	{ .compatible = "fsl,imx21-uart", ... },
> > >>> 	{ .compatible = "fsl,imx1-uart", ... },
> > >>>
> > >> yes. i can set it like this.
> > >>
> > >> but this method looks like a ugly workaround.
> > > If a driver has different ways of supporting a single device, then
> > > putting the preferred or most feature rich on top doesn't look very ugly
> > > to me.
> > this method makes it much _coupled_ between the driver and the dts file.
> > 
> > IMHO, it's an unnecessary _burden_ to the driver programmer:
> >     he should puts the most feature compatible on the top.
> > 
> > it's much graceful if we let the driver programmer be transparent about 
> > this.
> 
> Absolutely true. Applied, thanks.

I don't think this will work. The patch looks very similar to one that I
posted about a year ago (commit 107a84e "of: match by compatible
property first"). The problem it was trying to address was exactly the
same. However the patch caused regressions on SPARC and had to be
reverted in commit bc51b0c "Revert "of: match by compatible property
first"".

The revert commit quotes Rob having a fix for this, and I remember that
I pinged him about it occasionally, but I suspect that those must have
fallen through the cracks.

Grant, before applying this patch we should make sure that it doesn't
cause a regression again, so perhaps asking Meelis Roos (mentioned in
the revert commit) to test would be good. I have a strong feeling that
this patch will break in the same way than mine did a year ago, because
it looks too similar and doesn't handle the compatible & name
combination that Rob mentioned.

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/20130721/282471db/attachment.sig>

From joelf at ti.com  Sun Jul 21 02:57:33 2013
From: joelf at ti.com (Joel Fernandes)
Date: Sun, 21 Jul 2013 01:57:33 -0500
Subject: [RFC 0/5] EDMA: Support to DMA scatter-lists with any no. of entries
Message-ID: <1374389853-32458-1-git-send-email-joelf@ti.com>

Re: on-going discussion at [1], I've added support to EDMA driver to be
able to accept scatter gather lists of arbitrary length, but still make
use of only a certain MAX number of slots. Thus free-ing up the rest of
the slots to other slave users.  With this there is no need for slave
drivers to query the EDMA driver how much is the MAX. It can send SG lists
of any number of entries to DMA.

Tested with various number of MAX slots , even just "1". In the case where
it is 1, only 1-slot is used to transmit an entire set of scatter list.
If only 1 slot is used for a channel, there is a performance impact, but
it works. A DMA resources vs Performance tradeoff.

[1] http://marc.info/?l=linux-omap&m=137416733628831&w=2

Joel Fernandes (5):
  dma: edma: Setup parameters to DMA MAX_SG_NR at a time
  dma: edma: Write out and handle MAX_SG_NR at a given time
  ARM: edma: Add function to manually trigger an EDMA channel
  dma: edma: Find missed events and issue them
  DMA: EDMA: Leave linked to Null slot instead of DUMMY slot

 arch/arm/common/edma.c             |   21 +++++++
 drivers/dma/edma.c                 |  113 ++++++++++++++++++++++++++----------
 include/linux/platform_data/edma.h |    2 +
 3 files changed, 104 insertions(+), 32 deletions(-)

-- 
1.7.9.5



From joelf at ti.com  Sun Jul 21 02:57:56 2013
From: joelf at ti.com (Joel Fernandes)
Date: Sun, 21 Jul 2013 01:57:56 -0500
Subject: [RFC 1/5] dma: edma: Setup parameters to DMA MAX_SG_NR at a time
Message-ID: <1374389876-32500-1-git-send-email-joelf@ti.com>

Changes are made here for configuring existing parameters to support
DMA'ing them out in batches as needed.

Also allocate as many as slots as needed by the SG list, but not more
than MAX_SG_NR. Then these slots will be reused accordingly.
For ex, if MAX_SG_NR=10, and number of SG entries is 40, still only
10 slots will be allocated to DMA the entire SG list of size 40.

Also enable TC interrupts for slots that are a last in a current
iteration, or that fall on a MAX_SG_NR boundary.

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
 drivers/dma/edma.c |   21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 083ecff..9b9954e 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -223,9 +223,11 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
 	enum dma_slave_buswidth dev_width;
 	u32 burst;
 	struct scatterlist *sg;
-	int i;
+
 	int acnt, bcnt, ccnt, src, dst, cidx;
 	int src_bidx, dst_bidx, src_cidx, dst_cidx;
+	int i, ret;
+	int num_slots_needed;
 
 	if (unlikely(!echan || !sgl || !sg_len))
 		return NULL;
@@ -257,8 +259,11 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
 
 	edesc->pset_nr = sg_len;
 
-	for_each_sg(sgl, sg, sg_len, i) {
-		/* Allocate a PaRAM slot, if needed */
+	/* Allocate a PaRAM slot, if needed */
+
+	num_slots_needed = sg_len > MAX_NR_SG ? MAX_NR_SG : sg_len;
+
+	for (i = 0; i < num_slots_needed; i++) {
 		if (echan->slot[i] < 0) {
 			echan->slot[i] =
 				edma_alloc_slot(EDMA_CTLR(echan->ch_num),
@@ -268,6 +273,10 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
 				return NULL;
 			}
 		}
+	}
+
+	/* Configure PaRAM sets for each SG */
+	for_each_sg(sgl, sg, sg_len, i) {
 
 		acnt = dev_width;
 
@@ -325,6 +334,12 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
 		/* Configure A or AB synchronized transfers */
 		if (edesc->absync)
 			edesc->pset[i].opt |= SYNCDIM;
+
+		/* If this is the last in a current SG set of transactions,
+		   enable interrupts so that next set is processed */
+		if (!((i+1) % MAX_NR_SG))
+			edesc->pset[i].opt |= TCINTEN;
+
 		/* If this is the last set, enable completion interrupt flag */
 		if (i == sg_len - 1)
 			edesc->pset[i].opt |= TCINTEN;
-- 
1.7.9.5



From joelf at ti.com  Sun Jul 21 02:58:08 2013
From: joelf at ti.com (Joel Fernandes)
Date: Sun, 21 Jul 2013 01:58:08 -0500
Subject: [RFC 2/5] dma: edma: Write out and handle MAX_SG_NR at a given time
Message-ID: <1374389888-32538-1-git-send-email-joelf@ti.com>

Process SG-elements in batches of MAX_SG_NR if they are greater
than MAX_SG_NR. Due to this, at any given time only those many
slots will be used in the given channel no matter how long the
scatter list is. We keep track of how much has been written
inorder to process the next batch of elements in the scatter-list
and detect completion.

For such intermediate transfer completions (one batch of MAX_SG_NR),
make use of pause and resume functions instead of start and stop
when such intermediate transfer is in progress or completed as we
donot want to clear any pending events.

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
 drivers/dma/edma.c |   79 +++++++++++++++++++++++++++++++++++-----------------
 1 file changed, 54 insertions(+), 25 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 9b9954e..0e7ed79 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -56,6 +56,7 @@ struct edma_desc {
 	struct list_head		node;
 	int				absync;
 	int				pset_nr;
+	int				total_processed;
 	struct edmacc_param		pset[0];
 };
 
@@ -105,22 +106,36 @@ static void edma_desc_free(struct virt_dma_desc *vdesc)
 /* Dispatch a queued descriptor to the controller (caller holds lock) */
 static void edma_execute(struct edma_chan *echan)
 {
-	struct virt_dma_desc *vdesc = vchan_next_desc(&echan->vchan);
+	struct virt_dma_desc *vdesc;
 	struct edma_desc *edesc;
-	int i;
+	struct device *dev = echan->vchan.chan.device->dev;
 
-	if (!vdesc) {
-		echan->edesc = NULL;
-		return;
+	int i, j, total_left, total_process;
+
+	/* If either we processed all psets or we're still not started */
+	if (!echan->edesc ||
+	    echan->edesc->pset_nr == echan->edesc->total_processed) {
+		/* Get next vdesc */
+		vdesc = vchan_next_desc(&echan->vchan);
+		if (!vdesc) {
+			echan->edesc = NULL;
+			return;
+		}
+		list_del(&vdesc->node);
+		echan->edesc = to_edma_desc(&vdesc->tx);
 	}
 
-	list_del(&vdesc->node);
+	edesc = echan->edesc;
+
+	/* Find out how many left */
+	total_left = edesc->pset_nr - edesc->total_processed;
+	total_process = total_left > MAX_NR_SG ? MAX_NR_SG : total_left;
 
-	echan->edesc = edesc = to_edma_desc(&vdesc->tx);
 
 	/* Write descriptor PaRAM set(s) */
-	for (i = 0; i < edesc->pset_nr; i++) {
-		edma_write_slot(echan->slot[i], &edesc->pset[i]);
+	for (i = 0; i < total_process; i++) {
+		j = i + edesc->total_processed;
+		edma_write_slot(echan->slot[i], &edesc->pset[j]);
 		dev_dbg(echan->vchan.chan.device->dev,
 			"\n pset[%d]:\n"
 			"  chnum\t%d\n"
@@ -133,24 +148,31 @@ static void edma_execute(struct edma_chan *echan)
 			"  bidx\t%08x\n"
 			"  cidx\t%08x\n"
 			"  lkrld\t%08x\n",
-			i, echan->ch_num, echan->slot[i],
-			edesc->pset[i].opt,
-			edesc->pset[i].src,
-			edesc->pset[i].dst,
-			edesc->pset[i].a_b_cnt,
-			edesc->pset[i].ccnt,
-			edesc->pset[i].src_dst_bidx,
-			edesc->pset[i].src_dst_cidx,
-			edesc->pset[i].link_bcntrld);
+			j, echan->ch_num, echan->slot[i],
+			edesc->pset[j].opt,
+			edesc->pset[j].src,
+			edesc->pset[j].dst,
+			edesc->pset[j].a_b_cnt,
+			edesc->pset[j].ccnt,
+			edesc->pset[j].src_dst_bidx,
+			edesc->pset[j].src_dst_cidx,
+			edesc->pset[j].link_bcntrld);
 		/* Link to the previous slot if not the last set */
-		if (i != (edesc->pset_nr - 1))
+		if (i != (total_process - 1))
 			edma_link(echan->slot[i], echan->slot[i+1]);
 		/* Final pset links to the dummy pset */
 		else
 			edma_link(echan->slot[i], echan->ecc->dummy_slot);
 	}
 
-	edma_start(echan->ch_num);
+	edesc->total_processed += total_process;
+
+	edma_resume(echan->ch_num);
+
+	if (edesc->total_processed <= MAX_NR_SG) {
+		dev_dbg(dev, "first transfer starting %d\n", echan->ch_num);
+		edma_start(echan->ch_num);
+	}
 }
 
 static int edma_terminate_all(struct edma_chan *echan)
@@ -366,19 +388,26 @@ static void edma_callback(unsigned ch_num, u16 ch_status, void *data)
 	struct edma_desc *edesc;
 	unsigned long flags;
 
-	/* Stop the channel */
-	edma_stop(echan->ch_num);
+	/* Pause the channel */
+	edma_pause(echan->ch_num);
 
 	switch (ch_status) {
 	case DMA_COMPLETE:
-		dev_dbg(dev, "transfer complete on channel %d\n", ch_num);
-
 		spin_lock_irqsave(&echan->vchan.lock, flags);
 
 		edesc = echan->edesc;
 		if (edesc) {
+			if (edesc->total_processed == edesc->pset_nr) {
+				dev_dbg(dev, "transfer complete." \
+					" stopping channel %d\n", ch_num);
+				edma_stop(echan->ch_num);
+				vchan_cookie_complete(&edesc->vdesc);
+			} else {
+				dev_dbg(dev, "Intermediate transfer complete" \
+					" on channel %d\n", ch_num);
+			}
+
 			edma_execute(echan);
-			vchan_cookie_complete(&edesc->vdesc);
 		}
 
 		spin_unlock_irqrestore(&echan->vchan.lock, flags);
-- 
1.7.9.5



From joelf at ti.com  Sun Jul 21 02:58:16 2013
From: joelf at ti.com (Joel Fernandes)
Date: Sun, 21 Jul 2013 01:58:16 -0500
Subject: [RFC 3/5] ARM: edma: Add function to manually trigger an EDMA channel
Message-ID: <1374389896-32584-1-git-send-email-joelf@ti.com>

Manual trigger for events missed as a result of splitting a
scatter gather list and DMA'ing it in batches. Add a helper
function to trigger a channel incase any such events are missed.

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
 arch/arm/common/edma.c             |   21 +++++++++++++++++++++
 include/linux/platform_data/edma.h |    2 ++
 2 files changed, 23 insertions(+)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 3567ba1..205f5da 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1236,6 +1236,27 @@ void edma_resume(unsigned channel)
 }
 EXPORT_SYMBOL(edma_resume);
 
+int edma_manual_trigger(unsigned channel)
+{
+	unsigned ctlr;
+	int j;
+	unsigned int mask;
+
+	ctlr = EDMA_CTLR(channel);
+	channel = EDMA_CHAN_SLOT(channel);
+	mask = BIT(channel & 0x1f);
+
+	j = channel >> 5;
+
+	/* EDMA channels without event association */
+	edma_shadow0_write_array(ctlr, SH_ESR, j, mask);
+
+	pr_debug("EDMA: ESR%d %08x\n", j,
+		edma_shadow0_read_array(ctlr, SH_ESR, j));
+	return 0;
+}
+EXPORT_SYMBOL(edma_manual_trigger);
+
 /**
  * edma_start - start dma on a channel
  * @channel: channel being activated
diff --git a/include/linux/platform_data/edma.h b/include/linux/platform_data/edma.h
index 57300fd..0e11eca 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -180,4 +180,6 @@ struct edma_soc_info {
 	const s16	(*xbar_chans)[2];
 };
 
+int edma_manual_trigger(unsigned);
+
 #endif
-- 
1.7.9.5



From joelf at ti.com  Sun Jul 21 02:58:35 2013
From: joelf at ti.com (Joel Fernandes)
Date: Sun, 21 Jul 2013 01:58:35 -0500
Subject: [RFC 4/5] dma: edma: Find missed events and issue them
Message-ID: <1374389915-32630-1-git-send-email-joelf@ti.com>

In an effort to move to using Scatter gather lists of any size with
EDMA as discussed at [1] instead of placing limitations on the driver,
we work through the limitations of the EDMAC hardware to find missed
events and issue them.

The sequence of events that require this are:

For the scenario where MAX slots for an EDMA channel is 3:

SG1 -> SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> Null

The above SG list will have to be DMA'd in 2 sets:

(1) SG1 -> SG2 -> SG3 -> Null
(2) SG4 -> SG5 -> SG6 -> Null

After (1) is succesfully transferred, the events from the MMC controller
donot stop coming and are missed by the time we have setup the transfer
for (2). So here, we catch the events missed as an error condition and
issue them manually.

[1] http://marc.info/?l=linux-omap&m=137416733628831&w=2

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
 drivers/dma/edma.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 0e7ed79..b0b5bcd 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -414,7 +414,15 @@ static void edma_callback(unsigned ch_num, u16 ch_status, void *data)
 
 		break;
 	case DMA_CC_ERROR:
-		dev_dbg(dev, "transfer error on channel %d\n", ch_num);
+		if (echan->edesc) {
+			dev_dbg(dev, "Missed event on %d, retrying\n",
+				ch_num);
+			edma_clean_channel(echan->ch_num);
+			edma_stop(echan->ch_num);
+			edma_start(echan->ch_num);
+			edma_manual_trigger(echan->ch_num);
+		}
+		dev_dbg(dev, "handled error on channel %d\n", ch_num);
 		break;
 	default:
 		break;
-- 
1.7.9.5



From joelf at ti.com  Sun Jul 21 02:58:45 2013
From: joelf at ti.com (Joel Fernandes)
Date: Sun, 21 Jul 2013 01:58:45 -0500
Subject: [RFC 5/5] DMA: EDMA: Leave linked to Null slot instead of DUMMY slot
Message-ID: <1374389925-32667-1-git-send-email-joelf@ti.com>

Dummy slot has been used as a way for missed-events not to be
reported as missing. This has been particularly troublesome for cases
where we might want to temporarily pause all incoming events.

For EDMA DMAC, there is no way to do any such pausing of events as
the occurence of the "next" event is not software controlled.
Using "edma_pause" in IRQ handlers doesn't help as by then the event
in concern from the slave is already missed.

Linking a dummy slot, is seen to absorb these events which we didn't
want to miss. So we don't link to dummy, but instead leave it linked
to NULL set, allow an error condition and detect the channel that
missed it.

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
 drivers/dma/edma.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index b0b5bcd..e9f1f27 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -160,9 +160,6 @@ static void edma_execute(struct edma_chan *echan)
 		/* Link to the previous slot if not the last set */
 		if (i != (total_process - 1))
 			edma_link(echan->slot[i], echan->slot[i+1]);
-		/* Final pset links to the dummy pset */
-		else
-			edma_link(echan->slot[i], echan->ecc->dummy_slot);
 	}
 
 	edesc->total_processed += total_process;
-- 
1.7.9.5



From linux at roeck-us.net  Sun Jul 21 03:33:36 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Sun, 21 Jul 2013 00:33:36 -0700
Subject: [PATCH v4] watchdog: Add MOXA ART watchdog driver
In-Reply-To: <1374229402-20432-1-git-send-email-jonas.jensen@gmail.com>
References: <1374053091-5907-1-git-send-email-jonas.jensen@gmail.com>
 <1374229402-20432-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <20130721073336.GA26485@roeck-us.net>

On Fri, Jul 19, 2013 at 12:23:22PM +0200, Jonas Jensen wrote:
> Add watchdog driver for MOXA ART SoCs.
> 
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
> ---
> 
> Notes:
>     v4 should fix remaining issues pointed out by Guenter.
>     
>     Changes since v3:
>     
>     1. remove unnecessary header includes:
>        linux/of.h
>        linux/of_address.h
>        linux/err.h
>        linux/init.h
>        linux/kernel.h,
>        linux/moduleparam.h
>        linux/types.h
>        asm/system_misc.h

Seems you removed too many, but I'll need to have a closer look.
General guideline: If a definition from an include file is used, it must be
included. You can not depend on an include file being included from another
include file.

Thanks,
Guenter

>     2. move clock_frequency to moxart_wdt_dev
>     3. remove local pointer "void __iomem *wdt_base" use moxart_wdt->base instead
>     4. get clock_frequency from watchdog_get_drvdata
>     5. move max_timeout variable to moxart_wdt_probe
>     6. check for division by zero moxart_wdt->clock_frequency
>     7. if devm_kzalloc fails, return -ENOMEM instead of -EINVAL
>     
>     Applies to next-20130716
> 
>  .../bindings/watchdog/moxa,moxart-watchdog.txt     |  15 ++
>  drivers/watchdog/Kconfig                           |  10 ++
>  drivers/watchdog/Makefile                          |   1 +
>  drivers/watchdog/moxart_wdt.c                      | 166 +++++++++++++++++++++
>  4 files changed, 192 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
>  create mode 100644 drivers/watchdog/moxart_wdt.c
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
> new file mode 100644
> index 0000000..5507f2b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
> @@ -0,0 +1,15 @@
> +MOXA ART Watchdog timer
> +
> +Required properties:
> +
> +- compatible : Should be "moxa,moxart-watchdog"
> +- reg : Should contain registers location and length
> +- clocks : Should contain phandle for the MOXA ART core clock "coreclk"
> +
> +Example:
> +
> +	watchdog: watchdog at 98500000 {
> +		compatible = "moxa,moxart-watchdog";
> +		reg = <0x98500000 0x10>;
> +		clocks = <&coreclk>;
> +	};
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 362085d..6883aab 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -382,6 +382,16 @@ config RETU_WATCHDOG
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called retu_wdt.
>  
> +config MOXART_WDT
> +	tristate "MOXART watchdog"
> +	depends on ARCH_MOXART
> +	help
> +	  Say Y here to include Watchdog timer support for the watchdog
> +	  existing on the MOXA ART SoC series platforms.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called moxart_wdt.
> +
>  # AVR32 Architecture
>  
>  config AT32AP700X_WDT
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 2f26a0b..7cab53a 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -54,6 +54,7 @@ obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
>  obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
>  obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
>  obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
> +obj-$(CONFIG_MOXART_WDT) += moxart_wdt.o
>  
>  # AVR32 Architecture
>  obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
> new file mode 100644
> index 0000000..9a59c3d
> --- /dev/null
> +++ b/drivers/watchdog/moxart_wdt.c
> @@ -0,0 +1,166 @@
> +/*
> + * MOXA ART SoCs watchdog driver.
> + *
> + * Copyright (C) 2013 Jonas Jensen
> + *
> + * Jonas Jensen <jonas.jensen at gmail.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/watchdog.h>
> +
> +#define REG_COUNT			0x4
> +#define REG_MODE			0x8
> +#define REG_ENABLE			0xC
> +
> +struct moxart_wdt_dev {
> +	struct watchdog_device dev;
> +	void __iomem *base;
> +	unsigned int clock_frequency;
> +};
> +
> +static int heartbeat;
> +
> +static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
> +
> +	writel(0, moxart_wdt->base + REG_ENABLE);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_start(struct watchdog_device *wdt_dev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
> +
> +	writel(moxart_wdt->clock_frequency * moxart_wdt->dev.timeout,
> +	       moxart_wdt->base + REG_COUNT);
> +	writel(0x5ab9, moxart_wdt->base + REG_MODE);
> +	writel(0x03, moxart_wdt->base + REG_ENABLE);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_set_timeout(struct watchdog_device *wdt_dev,
> +				  unsigned int timeout)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
> +
> +	dev_dbg(wdt_dev->dev, "%s: timeout=%u\n", __func__, timeout);
> +
> +	moxart_wdt->dev.timeout = timeout;
> +
> +	return 0;
> +}
> +
> +static const struct watchdog_info moxart_wdt_info = {
> +	.identity       = "moxart-wdt",
> +	.options        = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
> +			  WDIOF_MAGICCLOSE,
> +};
> +
> +static const struct watchdog_ops moxart_wdt_ops = {
> +	.owner          = THIS_MODULE,
> +	.start          = moxart_wdt_start,
> +	.stop           = moxart_wdt_stop,
> +	.set_timeout    = moxart_wdt_set_timeout,
> +};
> +
> +static int moxart_wdt_probe(struct platform_device *pdev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt;
> +	struct device *dev = &pdev->dev;
> +	struct device_node *node = dev->of_node;
> +	struct resource *res;
> +	struct clk *clk;
> +	int err;
> +	unsigned int max_timeout;
> +	bool nowayout = WATCHDOG_NOWAYOUT;
> +
> +	moxart_wdt = devm_kzalloc(&pdev->dev, sizeof(*moxart_wdt), GFP_KERNEL);
> +	if (!moxart_wdt)
> +		return -ENOMEM;
> +
> +	platform_set_drvdata(pdev, moxart_wdt);
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	moxart_wdt->base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(moxart_wdt->base))
> +		return PTR_ERR(moxart_wdt->base);
> +
> +	clk = of_clk_get(node, 0);
> +	if (IS_ERR(clk)) {
> +		pr_err("%s: of_clk_get failed\n", __func__);
> +		return PTR_ERR(clk);
> +	}
> +
> +	moxart_wdt->clock_frequency = clk_get_rate(clk);
> +	if (moxart_wdt->clock_frequency == 0) {
> +		pr_err("%s: incorrect clock frequency\n", __func__);
> +		return -EINVAL;
> +	}
> +
> +	max_timeout = UINT_MAX / moxart_wdt->clock_frequency;
> +
> +	moxart_wdt->dev.info = &moxart_wdt_info;
> +	moxart_wdt->dev.ops = &moxart_wdt_ops;
> +	moxart_wdt->dev.timeout = max_timeout;
> +	moxart_wdt->dev.min_timeout = 1;
> +	moxart_wdt->dev.max_timeout = max_timeout;
> +	moxart_wdt->dev.parent = &pdev->dev;
> +
> +	watchdog_init_timeout(&moxart_wdt->dev, heartbeat, &pdev->dev);
> +	watchdog_set_nowayout(&moxart_wdt->dev, nowayout);
> +
> +	watchdog_set_drvdata(&moxart_wdt->dev, moxart_wdt);
> +
> +	err = watchdog_register_device(&moxart_wdt->dev);
> +	if (unlikely(err))
> +		return err;
> +
> +	dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
> +		moxart_wdt->dev.timeout, nowayout);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_remove(struct platform_device *pdev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
> +
> +	moxart_wdt_stop(&moxart_wdt->dev);
> +	watchdog_unregister_device(&moxart_wdt->dev);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id moxart_watchdog_match[] = {
> +	{ .compatible = "moxa,moxart-watchdog" },
> +	{ },
> +};
> +
> +static struct platform_driver moxart_wdt_driver = {
> +	.probe      = moxart_wdt_probe,
> +	.remove     = moxart_wdt_remove,
> +	.driver     = {
> +		.name		= "moxart-watchdog",
> +		.owner		= THIS_MODULE,
> +		.of_match_table	= moxart_watchdog_match,
> +	},
> +};
> +module_platform_driver(moxart_wdt_driver);
> +
> +module_param(heartbeat, int, 0);
> +MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");
> +
> +MODULE_DESCRIPTION("MOXART watchdog driver");
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
> -- 
> 1.8.2.1
> 
> 


From paul at pwsan.com  Sun Jul 21 03:54:08 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Sun, 21 Jul 2013 07:54:08 +0000 (UTC)
Subject: Changes in OMAP baseline testing for v3.11-rc1 onwards
Message-ID: <alpine.DEB.2.02.1307210740570.22867@utopia.booyaka.com>


Hi,

Unfortunately I'm no longer able to manually track regressions and posted 
solutions (if any).  This process consumes more time and energy than I'm 
able to invest now.  So, starting with v3.11-rc1, the summary reports will 
only report the outcome of automated validation scripts. 

Any comments and testbed bug reports continue to be welcome,


- Paul


From arnd at arndb.de  Sun Jul 21 04:09:31 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sun, 21 Jul 2013 10:09:31 +0200
Subject: [PATCH 1/5] ARM: bcm4760: Add platform infrastructure
In-Reply-To: <20130721002713.512199844@gmail.com>
References: <20130721002320.730568671@gmail.com>
 <20130721002713.512199844@gmail.com>
Message-ID: <201307211009.31789.arnd@arndb.de>

On Sunday 21 July 2013, Domenico Andreoli wrote:
> From: Domenico Andreoli <domenico.andreoli at linux.com>
> 
> Platform infrastructure for the Broadcom BCM4760 based ARM11 SoCs.
> 
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Domenico Andreoli <domenico.andreoli at linux.com>

Looks very nice overall, thanks for following up on this!

> +#define BCM4760_PERIPH_PHYS   0x00080000
> +#define BCM4760_PERIPH_VIRT   IOMEM(0xd0080000)
> +#define BCM4760_PERIPH_SIZE   SZ_512K
> +
> +static struct map_desc io_map __initdata = {
> +	.virtual = (unsigned long) BCM4760_PERIPH_VIRT,
> +	.pfn = __phys_to_pfn(BCM4760_PERIPH_PHYS),
> +	.length = BCM4760_PERIPH_SIZE,
> +	.type = MT_DEVICE,
> +};
> +
> +static void __init bcm4760_map_io(void)
> +{
> +	iotable_init(&io_map, 1);
> +}

I would hope expect a comment here explaining what those registers are and why
they are mapped early.

> +
> +#define BCM4760_CPUID0 IOMEM(0xd00b0ff0)
> +#define BCM4760_CPUID1 IOMEM(0xd00b0ff4)

Better make these

#define BCM4760_CPUID0 (BCM4760_PERIPH_VIRT + 0x30ff0)
#define BCM4760_CPUID1 (BCM4760_PERIPH_VIRT + 0x30ff4)

for clarity.

> +static void __init bcm4760_system_rev(void)
> +{
> +	u32 id0, id1;
> +
> +	id0 = readl_relaxed(BCM4760_CPUID0);
> +	id1 = readl_relaxed(BCM4760_CPUID1);
> +
> +	if (id0 >> 16 != 0xbcbc)
> +		system_rev = 0xbc4760a0;
> +	else
> +		system_rev = id0 << 8 | (id1 & 0xff);
> +}

Or even better, change this function to do:

	struct device_node *node = of_find_compatible_node(NULL, NULL, "brcm,whatever");
	void __iomem *regs = of_iomap(node, 0);
	u32 id0, id1;

	id0 = readl_relaxed(regs + BCM4760_CPUID0);
	id1 = readl_relaxed(regs + BCM4760_CPUID1);

	...

	iounmap(regs);
	of_node_put(node);


bonus points if you use soc_device_register();

What is the system_rev variable actually used for?

> +		uart0 at c0000 {
> +			compatible = "brcm,bcm4760-pl011", "arm,pl011", "arm,primecell";
> +			reg = <0xc0000 0x1000>;
> +			interrupt-parent = <&vic0>;
> +			interrupts = <14>;
> +		};
> +
> +		uart1 at c1000 {
> +			compatible = "brcm,bcm4760-pl011", "arm,pl011", "arm,primecell";
> +			reg = <0xc1000 0x1000>;
> +			interrupt-parent = <&vic0>;
> +			interrupts = <15>;
> +		};
> +
> +		uart2 at b2000 {
> +			compatible = "brcm,bcm4760-pl011", "arm,pl011", "arm,primecell";
> +			reg = <0xb2000 0x1000>;
> +			interrupt-parent = <&vic0>;
> +			interrupts = <16>;
> +		};
> +	};

Please change the names here to say "serial" rather than "uartX". The name should not
have an index in it (that's what the @address part is for) and there are conventions
for common devices.

If some of the serial ports are not connected on all boars, best mark them as
status="disabled"; here and only enable them in the board specific file.

> +config ARCH_BCM4760
> +	bool "Broadcom BCM4760 based SoCs (ARM11)" if ARCH_MULTI_V6
> +	select ARCH_WANT_OPTIONAL_GPIOLIB
> +	select ARM_AMBA
> +	select ARM_VIC
> +	select CLKDEV_LOOKUP
> +	select CLKSRC_OF
> +	select COMMON_CLK
> +	select CPU_V6
> +	select GENERIC_CLOCKEVENTS
> +	select GENERIC_IRQ_CHIP
> +	select MULTI_IRQ_HANDLER
> +	select NO_IOPORT
> +	select PINCTRL
> +	select PINMUX
> +	select SPARSE_IRQ
> +	select USE_OF

A lot of these are implied by ARCH_MULTIPLATFORM or ARCH_MULTI_V6 and can be removed
here. I don't think you should select 'PINCTRL and PINMUX' here, as long as the code
builds without them.

	Arnd


From arnd at arndb.de  Sun Jul 21 04:14:20 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sun, 21 Jul 2013 10:14:20 +0200
Subject: [PATCH 2/5] ARM: bcm4760: Add system timer
In-Reply-To: <20130721002713.813400062@gmail.com>
References: <20130721002320.730568671@gmail.com>
 <20130721002713.813400062@gmail.com>
Message-ID: <201307211014.21161.arnd@arndb.de>

+Daniel Lezcano

On Sunday 21 July 2013, Domenico Andreoli wrote:

> Index: b/Documentation/devicetree/bindings/timer/brcm,bcm4760-system-timer.txt
> ===================================================================
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/brcm,bcm4760-system-timer.txt
> @@ -0,0 +1,23 @@
> +Broadcom BCM4760 System Timer device tree bindings
> +--------------------------------------------------
> +
> +The BCM4760 Timer peripheral provides either two or four 32-bit timer
> +channels. Three timer blocks are available at 0xba000, 0xbb000 and
> +0xd1000. The first two provide four channels, the last (in the AON -
> +Always ON power domain) provides only two.
> +
> +Required properties:
> +
> +- compatible : should be "brcm,bcm4760-system-timer"
> +- reg : Specifies base physical address and size of the registers.
> +- interrupts : A list of 2 or 4 interrupt sinks; one per timer channel.
> +- clock-frequency : The frequency of the clock that drives the counter, in Hz.

I think the current consensus is that if you have a clock driver (as added in
patch 4), you should use a 'clocks' reference and clk_get_rate() to find the
frequency rather than an explicit clock-frequency property.

I have no comments on the driver, the rest is quoted so Daniel can find it
more easily.

	Arnd

> +Example:
> +
> +timer at ba000 {
> +	compatible = "brcm,bcm4760-system-timer";
> +	reg = <0xba000 0x1000>;
> +	interrupts = <4>, <11>;
> +	clock-frequency = <24000000>;
> +};
> Index: b/arch/arm/boot/dts/bcm4760.dtsi
> ===================================================================
> --- a/arch/arm/boot/dts/bcm4760.dtsi
> +++ b/arch/arm/boot/dts/bcm4760.dtsi
> @@ -10,6 +10,14 @@
>  		#size-cells = <1>;
>  		ranges;
>  
> +		timer at ba000 {
> +			compatible = "brcm,bcm4760-system-timer";
> +			reg = <0xba000 0x1000>;
> +			interrupt-parent = <&vic0>;
> +			interrupts = <4>, <11>;
> +			clock-frequency = <24000000>;
> +		};
> +
>  		vic0: interrupt-controller at 80000 {
>  			compatible = "brcm,bcm4760-pl192", "arm,pl192-vic", "arm,primecell";
>  			reg = <0x80000 0x1000>;
> Index: b/drivers/clocksource/Makefile
> ===================================================================
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_CLKSRC_DBX500_PRCMU)	+= clk
>  obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
>  obj-$(CONFIG_ORION_TIMER)	+= time-orion.o
>  obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
> +obj-$(CONFIG_ARCH_BCM4760)	+= bcm4760_timer.o
>  obj-$(CONFIG_ARCH_MARCO)	+= timer-marco.o
>  obj-$(CONFIG_ARCH_MXS)		+= mxs_timer.o
>  obj-$(CONFIG_ARCH_PRIMA2)	+= timer-prima2.o
> Index: b/drivers/clocksource/bcm4760_timer.c
> ===================================================================
> --- /dev/null
> +++ b/drivers/clocksource/bcm4760_timer.c
> @@ -0,0 +1,170 @@
> +/*
> + * Broadcom BCM4760 based ARM11 SoCs system timer
> + *
> + * Copyright (C) 2012 Domenico Andreoli <domenico.andreoli at linux.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This 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.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/interrupt.h>
> +#include <linux/clockchips.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +
> +#define TIMER_LOAD_OFFSET          0x00          /* load */
> +#define TIMER_VALUE_OFFSET         0x04          /* value */
> +#define TIMER_CONTROL_OFFSET       0x08          /* control */
> +#define TIMER_INTCLR_OFFSET        0x0c          /* interrupt clear */
> +#define TIMER_RIS_OFFSET           0x10          /* raw interrupt */
> +#define TIMER_MIS_OFFSET           0x14          /* masked interrupt status */
> +#define TIMER_BGLOAD_OFFSET        0x18          /* background load */
> +
> +#define TIMER_CTRL_ONESHOTMODE     BIT(0)        /* One shot mode */
> +#define TIMER_CTRL_32BIT           BIT(1)        /* 32-bit counter mode */
> +#define TIMER_CTRL_IE              BIT(5)        /* Interrupt enable */
> +#define TIMER_CTRL_PERIODIC        BIT(6)        /* Periodic mode */
> +#define TIMER_CTRL_EN              BIT(7)        /* Timer enable */
> +#define TIMER_CTRL_CLK2            BIT(9)        /* Clock 2 selected */
> +#define TIMER_CTRL_PREBY16         (1 << 2)      /* prescale divide by 16 */
> +#define TIMER_CTRL_PREBY256        (2 << 2)      /* prescale divide by 256 */
> +
> +struct bcm4760_timer {
> +	void __iomem *base;
> +	struct clock_event_device evt;
> +	struct irqaction act;
> +};
> +
> +static inline void __iomem *to_load(struct bcm4760_timer *timer)
> +{
> +	return timer->base + TIMER_LOAD_OFFSET;
> +}
> +
> +static inline void __iomem *to_control(struct bcm4760_timer *timer)
> +{
> +	return timer->base + TIMER_CONTROL_OFFSET;
> +}
> +
> +static inline void __iomem *to_intclr(struct bcm4760_timer *timer)
> +{
> +	return timer->base + TIMER_INTCLR_OFFSET;
> +}
> +
> +static inline void __iomem *to_ris(struct bcm4760_timer *timer)
> +{
> +	return timer->base + TIMER_RIS_OFFSET;
> +}
> +
> +static inline void __iomem *to_mis(struct bcm4760_timer *timer)
> +{
> +	return timer->base + TIMER_MIS_OFFSET;
> +}
> +
> +static void bcm4760_timer_set_mode(enum clock_event_mode mode,
> +	struct clock_event_device *evt_dev)
> +{
> +	struct bcm4760_timer *timer;
> +	u32 val;
> +
> +	timer = container_of(evt_dev, struct bcm4760_timer, evt);
> +	val = TIMER_CTRL_CLK2 | TIMER_CTRL_32BIT |
> +	      TIMER_CTRL_IE | TIMER_CTRL_EN;
> +
> +	switch (mode) {
> +	case CLOCK_EVT_MODE_ONESHOT:
> +		writel(val | TIMER_CTRL_ONESHOTMODE, to_control(timer));
> +		break;
> +	case CLOCK_EVT_MODE_RESUME:
> +	case CLOCK_EVT_MODE_SHUTDOWN:
> +		break;
> +	default:
> +		WARN(1, "%s: unhandled event mode %d\n", __func__, mode);
> +		break;
> +	}
> +}
> +
> +static int bcm4760_timer_set_next_event(unsigned long event,
> +	struct clock_event_device *evt_dev)
> +{
> +	struct bcm4760_timer *timer;
> +
> +	timer = container_of(evt_dev, struct bcm4760_timer, evt);
> +	writel(event, to_load(timer));
> +	return 0;
> +}
> +
> +static irqreturn_t bcm4760_timer_interrupt(int irq, void *dev_id)
> +{
> +	struct bcm4760_timer *timer = dev_id;
> +	void (*event_handler)(struct clock_event_device *);
> +
> +	/* check the (masked) interrupt status */
> +	if (!readl_relaxed(to_mis(timer)))
> +		return IRQ_NONE;
> +
> +	/* clear the timer interrupt */
> +	writel_relaxed(1, to_intclr(timer));
> +
> +	event_handler = ACCESS_ONCE(timer->evt.event_handler);
> +	if (event_handler)
> +		event_handler(&timer->evt);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static void __init bcm4760_init_time(struct device_node *node)
> +{
> +	void __iomem *base;
> +	u32 freq;
> +	int irq;
> +	struct bcm4760_timer *timer;
> +
> +	base = of_iomap(node, 0);
> +	if (!base)
> +		panic("Can't remap timer registers");
> +
> +	if (of_property_read_u32(node, "clock-frequency", &freq))
> +		panic("Can't read timer frequency");
> +
> +	/* TODO allow other frequences by using pre-scaling parameters */
> +	if (freq != 24000000)
> +		panic("Invalid timer frequency");
> +
> +	timer = kzalloc(sizeof(*timer), GFP_KERNEL);
> +	if (!timer)
> +		panic("Can't allocate timer struct\n");
> +
> +	irq = irq_of_parse_and_map(node, 0);
> +	if (irq <= 0)
> +		panic("Can't parse timer IRQ");
> +
> +	timer->base = base;
> +	timer->evt.name = node->name;
> +	timer->evt.rating = 300;
> +	timer->evt.features = CLOCK_EVT_FEAT_ONESHOT;
> +	timer->evt.set_mode = bcm4760_timer_set_mode;
> +	timer->evt.set_next_event = bcm4760_timer_set_next_event;
> +	timer->evt.cpumask = cpumask_of(0);
> +	timer->act.name = node->name;
> +	timer->act.flags = IRQF_TIMER | IRQF_SHARED;
> +	timer->act.dev_id = timer;
> +	timer->act.handler = bcm4760_timer_interrupt;
> +
> +	if (setup_irq(irq, &timer->act))
> +		panic("Can't set up timer IRQ\n");
> +
> +	clockevents_config_and_register(&timer->evt, freq, 0xf, 0xffffffff);
> +}
> +
> +CLOCKSOURCE_OF_DECLARE(bcm4760, "brcm,bcm4760-system-timer", bcm4760_init_time);
> 
> 



From arnd at arndb.de  Sun Jul 21 04:16:48 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sun, 21 Jul 2013 10:16:48 +0200
Subject: [PATCH 4/5] ARM: bcm4760: Add stub clock driver
In-Reply-To: <20130721002714.459727324@gmail.com>
References: <20130721002320.730568671@gmail.com>
 <20130721002714.459727324@gmail.com>
Message-ID: <201307211016.49274.arnd@arndb.de>

On Sunday 21 July 2013, Domenico Andreoli wrote:
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk/bcm4760.h>
> +
> +void __init bcm4760_init_clocks(void)
> +{
> +       struct clk *clk;
> +
> +       clk = clk_register_fixed_rate(NULL, "pclk", NULL, CLK_IS_ROOT, 78000000);
> +       if (IS_ERR(clk))
> +               pr_err("pclk not registered\n");
> +
> +       if (clk_register_clkdev(clk, NULL, "c0000.uart0"))
> +               pr_err("uart0 clk alias not registered\n");
> +       if (clk_register_clkdev(clk, NULL, "c1000.uart1"))
> +               pr_err("uart1 clk alias not registered\n");
> +       if (clk_register_clkdev(clk, NULL, "b2000.uart2"))
> +               pr_err("uart2 clk alias not registered\n");
> +}


Since these are all fixed-rate clocks, I think what you should do here is to
put them into the device tree as compatible="fixed-clock" and remove the code
here.

	Arnd


From arnd at arndb.de  Sun Jul 21 04:20:25 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sun, 21 Jul 2013 10:20:25 +0200
Subject: [PATCH 5/5] ARM: bcm4760: Add restart hook
In-Reply-To: <20130721002714.732402573@gmail.com>
References: <20130721002320.730568671@gmail.com>
 <20130721002714.732402573@gmail.com>
Message-ID: <201307211020.25966.arnd@arndb.de>

On Sunday 21 July 2013, Domenico Andreoli wrote:
> From: Domenico Andreoli <domenico.andreoli at linux.com>
> 
> Restart hook implementation for the Broadcom BCM4760 based ARM11 SoCs.
> 
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Domenico Andreoli <domenico.andreoli at linux.com>
> ---
>  Documentation/devicetree/bindings/watchdog/brcm,bcm4760-pm-wdt.txt |   14 ++
>  arch/arm/boot/dts/bcm4760.dtsi                                     |    5 +
>  arch/arm/mach-bcm/bcm4760.c                                        |   78 ++++++++++
>  3 files changed, 97 insertions(+)

The implementation looks ok to me, but I would prefer this to be part of a
watchdog device driver that overrides the pm_power_off hook.

It can probably be done at a later stage when you submit a watchdog driver.

	Arnd

> Index: b/Documentation/devicetree/bindings/watchdog/brcm,bcm4760-pm-wdt.txt
> ===================================================================
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm4760-pm-wdt.txt
> @@ -0,0 +1,14 @@
> +Broadcom BCM4760 watchdog timer device tree bindings
> +----------------------------------------------------
> +
> +Required properties:
> +
> +- compatible : should be "brcm,bcm4760-pm-wdt"
> +- reg : Specifies base physical address and size of the registers.
> +
> +Example:
> +
> +watchdog {
> +	compatible = "brcm,bcm4760-pm-wdt";
> +	reg = <0xbd000 0x1000>;
> +};
> Index: b/arch/arm/boot/dts/bcm4760.dtsi
> ===================================================================
> --- a/arch/arm/boot/dts/bcm4760.dtsi
> +++ b/arch/arm/boot/dts/bcm4760.dtsi
> @@ -23,6 +23,11 @@
>  			reg = <0xbc000 0x1000>;
>  		};
>  
> +		watchdog {
> +			compatible = "brcm,bcm4760-pm-wdt";
> +			reg = <0xbd000 0x1000>;
> +		};
> +
>  		vic0: interrupt-controller at 80000 {
>  			compatible = "brcm,bcm4760-pl192", "arm,pl192-vic", "arm,primecell";
>  			reg = <0x80000 0x1000>;
> Index: b/arch/arm/mach-bcm/bcm4760.c
> ===================================================================
> --- a/arch/arm/mach-bcm/bcm4760.c
> +++ b/arch/arm/mach-bcm/bcm4760.c
> @@ -16,7 +16,9 @@
>  
>  #include <linux/init.h>
>  #include <linux/irqchip.h>
> +#include <linux/delay.h>
>  #include <linux/of_irq.h>
> +#include <linux/of_address.h>
>  #include <linux/of_platform.h>
>  #include <linux/clk/bcm4760.h>
>  
> @@ -28,6 +30,17 @@
>  #define BCM4760_PERIPH_VIRT   IOMEM(0xd0080000)
>  #define BCM4760_PERIPH_SIZE   SZ_512K
>  
> +#define BCM4760_WDT_LOAD      0x000
> +#define BCM4760_WDT_CTRL      0x008
> +#define BCM4760_WDT_INTCLR    0x00c
> +#define BCM4760_WDT_LOCK      0xc00
> +
> +#define BCM4760_WDT_PASSWORD  0x1acce551
> +#define BCM4760_WDT_INTEN     BIT(0)
> +#define BCM4760_WDT_RESEN     BIT(1)
> +
> +static void __iomem *wdt_regs;
> +
>  static struct map_desc io_map __initdata = {
>  	.virtual = (unsigned long) BCM4760_PERIPH_VIRT,
>  	.pfn = __phys_to_pfn(BCM4760_PERIPH_PHYS),
> @@ -56,11 +69,75 @@ static void __init bcm4760_system_rev(vo
>  		system_rev = id0 << 8 | (id1 & 0xff);
>  }
>  
> +static const struct of_device_id bcm4760_pm_wdt_match[] __initconst = {
> +	{ .compatible = "brcm,bcm4760-pm-wdt" },
> +	{}
> +};
> +
> +/*
> + * The machine restart method can be called from an atomic context so we won't
> + * be able to ioremap the regs then.
> + */
> +static void __init bcm4760_setup_restart(void)
> +{
> +	struct device_node *node;
> +
> +	node = of_find_matching_node(NULL, bcm4760_pm_wdt_match);
> +	if (!node) {
> +		pr_info("No bcm4760 watchdog node\n");
> +		return;
> +	}
> +
> +	wdt_regs = of_iomap(node, 0);
> +	if (!wdt_regs) {
> +		pr_err("Can't remap watchdog registers\n");
> +		return;
> +	}
> +
> +	/* unlock watchdog registers */
> +	writel(BCM4760_WDT_PASSWORD, wdt_regs + BCM4760_WDT_LOCK);
> +	/* disable watchdog */
> +	writel(0, wdt_regs + BCM4760_WDT_CTRL);
> +	/* lock watchdog registers */
> +	writel(1, wdt_regs + BCM4760_WDT_LOCK);
> +}
> +
> +static void bcm4760_restart(enum reboot_mode mode, const char *cmd)
> +{
> +	if (!wdt_regs) {
> +		pr_err("No restart hook installed. ");
> +		return;
> +	}
> +
> +	/* unlock watchdog registers */
> +	writel(BCM4760_WDT_PASSWORD, wdt_regs + BCM4760_WDT_LOCK);
> +
> +	/* disable watchdog */
> +	writel(0, wdt_regs + BCM4760_WDT_CTRL);
> +	udelay(20);
> +
> +	/* clear the irq status */
> +	writel(1, wdt_regs + BCM4760_WDT_INTCLR);
> +	udelay(20);
> +
> +	/* expire after 5 cycles (~156us) */
> +	writel(5, wdt_regs + BCM4760_WDT_LOAD);
> +	/* enable watchdog */
> +	writel(BCM4760_WDT_INTEN | BCM4760_WDT_RESEN,
> +		wdt_regs + BCM4760_WDT_CTRL);
> +
> +	/* lock watchdog registers */
> +	writel(1, wdt_regs + BCM4760_WDT_LOCK);
> +	/* wait the bite */
> +	udelay(400);
> +}
> +
>  static void __init bcm4760_init(void)
>  {
>  	int err;
>  
>  	bcm4760_system_rev();
> +	bcm4760_setup_restart();
>  	bcm4760_init_clocks();
>  
>  	err = of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> @@ -78,5 +155,6 @@ static const char * const bcm4760_compat
>  DT_MACHINE_START(BCM4760, "Broadcom BCM4760")
>  	.map_io = bcm4760_map_io,
>  	.init_machine = bcm4760_init,
> +	.restart = bcm4760_restart,
>  	.dt_compat = bcm4760_compat
>  MACHINE_END
> 
> 



From shc_work at mail.ru  Sun Jul 21 04:35:09 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sun, 21 Jul 2013 12:35:09 +0400
Subject: [PATCH 2/2] video: imxfb: Add feature to setup PWM Contrast Control
 Register
In-Reply-To: <1374395709-20898-1-git-send-email-shc_work@mail.ru>
References: <1374395709-20898-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374395709-20898-2-git-send-email-shc_work@mail.ru>

This patch adds feature to setup PWM Contrast Control Register.
This register is used to control the signal output at the contrast pin,
which controls contrast of the LCD panel.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 Documentation/devicetree/bindings/video/fsl,imx-fb.txt | 1 +
 drivers/video/imxfb.c                                  | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
index 46da08d..be10c65 100644
--- a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
+++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
@@ -18,6 +18,7 @@ Optional properties:
 - fsl,dmacr: DMA Control Register value. This is optional. By default, the
 	register is not modified as recommended by the datasheet.
 - fsl,lscr1: LCDC Sharp Configuration Register value.
+- fsl,pwmr: LCDC PWM Contrast Control Register value.
 
 Example:
 
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 8e104c4..d98299a 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -806,8 +806,8 @@ static int imxfb_init_fbinfo(struct platform_device *pdev,
 
 		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
 		of_property_read_u32(np, "fsl,lscr1", &fbi->lscr1);
-
 		of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
+		of_property_read_u32(np, "fsl,pwmr", &fbi->pwmr);
 
 		/* These two function pointers could be used by some specific
 		 * platforms. */
-- 
1.8.1.5



From shc_work at mail.ru  Sun Jul 21 04:35:08 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sun, 21 Jul 2013 12:35:08 +0400
Subject: [PATCH 1/2] video: imxfb: Fix retrieve values from DT
Message-ID: <1374395709-20898-1-git-send-email-shc_work@mail.ru>

Display settings should be retrieved from "display" node, not from
root fb node. This patch fix this bug.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 drivers/video/imxfb.c | 26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 38733ac..8e104c4 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -753,12 +753,12 @@ static int imxfb_resume(struct platform_device *dev)
 #define imxfb_resume	NULL
 #endif
 
-static int imxfb_init_fbinfo(struct platform_device *pdev)
+static int imxfb_init_fbinfo(struct platform_device *pdev,
+			     struct device_node *np)
 {
 	struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
 	struct fb_info *info = dev_get_drvdata(&pdev->dev);
 	struct imxfb_info *fbi = info->par;
-	struct device_node *np;
 
 	pr_debug("%s\n",__func__);
 
@@ -799,7 +799,6 @@ static int imxfb_init_fbinfo(struct platform_device *pdev)
 		fbi->lcd_power			= pdata->lcd_power;
 		fbi->backlight_power		= pdata->backlight_power;
 	} else {
-		np = pdev->dev.of_node;
 		info->var.grayscale = of_property_read_bool(np,
 						"cmap-greyscale");
 		fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
@@ -858,6 +857,7 @@ static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
 
 static int imxfb_probe(struct platform_device *pdev)
 {
+	struct device_node *display_np = NULL;
 	struct imxfb_info *fbi;
 	struct fb_info *info;
 	struct imx_fb_platform_data *pdata;
@@ -887,7 +887,17 @@ static int imxfb_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, info);
 
-	ret = imxfb_init_fbinfo(pdev);
+	if (pdev->dev.of_node) {
+		display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
+		if (!display_np) {
+			dev_err(&pdev->dev,
+				"No display defined in devicetree\n");
+			ret = -EINVAL;
+			goto failed_init;
+		}
+	}
+
+	ret = imxfb_init_fbinfo(pdev, display_np);
 	if (ret < 0)
 		goto failed_init;
 
@@ -898,16 +908,8 @@ static int imxfb_probe(struct platform_device *pdev)
 		fbi->mode = pdata->mode;
 		fbi->num_modes = pdata->num_modes;
 	} else {
-		struct device_node *display_np;
 		fb_mode = NULL;
 
-		display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
-		if (!display_np) {
-			dev_err(&pdev->dev, "No display defined in devicetree\n");
-			ret = -EINVAL;
-			goto failed_of_parse;
-		}
-
 		/*
 		 * imxfb does not support more modes, we choose only the native
 		 * mode.
-- 
1.8.1.5



From daniel.lezcano at linaro.org  Sun Jul 21 04:32:31 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sun, 21 Jul 2013 10:32:31 +0200
Subject: [PATCH 08/10] ARM: clps711x: Add CLPS711X cpuidle driver
In-Reply-To: <20130721081138.75cf5437bc30f42284f12e47@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
 <1374172501-26796-9-git-send-email-shc_work@mail.ru>
 <51EB0433.3050308@linaro.org>
 <20130721081138.75cf5437bc30f42284f12e47@mail.ru>
Message-ID: <51EB9C9F.5040405@linaro.org>

On 07/21/2013 06:11 AM, Alexander Shiyan wrote:
> On Sat, 20 Jul 2013 23:42:11 +0200
> Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
> 
>> On 07/18/2013 08:34 PM, Alexander Shiyan wrote:
>>> This adds the cpuidle driver for Cirrus Logic CLPS711X series SoCs.
>>> Designed primarily for migration CLPS711X subarch for multiplatform & DT.
>>>
>>> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
>>> ---
>>>  drivers/cpuidle/Kconfig            |  6 +++
>>>  drivers/cpuidle/Makefile           |  1 +
>>>  drivers/cpuidle/cpuidle-clps711x.c | 80 ++++++++++++++++++++++++++++++++++++++
>>>  3 files changed, 87 insertions(+)
>>>  create mode 100644 drivers/cpuidle/cpuidle-clps711x.c
> [...]
>>> +static int clps711x_cpuidle_halt(struct cpuidle_device *dev,
>>> +				 struct cpuidle_driver *drv, int index)
>>> +{
>>> +	writel(1, clps711x_halt);
>>
>> In what the 'clps711x_halt' differs from the usual WFI (cpu_do_idle) ?
> 
> AFAIK, ARM720T does not implement the WFI instruction.
> "HALT" register in CLPS711X do the same:
> "A write to this location will put the system into the Idle State by
> halting the clock to the processor until an interrupt is generated."

I am wondering if you are not using more states, may be you can consider
to add a clps711x idle function for the 'arm_pm_idle' callback instead
of creating a new driver.

>>> +	asm volatile ("mov r0, r0");
>>> +	asm volatile ("mov r0, r0");
>>
>> Why are needed these two volatile ?
> 
> Two NOP instructions necessary following the enable or disable of the MMU.
> Documentation not say anything about using this for "HALT", maybe it's the
> remnants of the old code. I will remove it.

Ok.

> [...]
>>> +static int clps711x_cpuidle_remove(struct platform_device *pdev)
>>> +{
>>> +	cpuidle_unregister(&clps711x_idle_driver);
>>> +
>>> +	return 0;
>>> +}
>>
>> The driver is not compiled as module, will this function be called ?
> 
> You're right. I will remove it.
> 
>>> +static const struct of_device_id clps711x_cpuidle_dt_ids[] = {
>>> +	{ .compatible = "cirrus,clps711x-cpuidle", },
>>> +	{ }
>>> +};
>>> +MODULE_DEVICE_TABLE(of, clps711x_cpuidle_dt_ids);
>>> +
>>> +static struct platform_driver clps711x_cpuidle_driver = {
>>> +	.driver	= {
>>> +		.name		= "clps711x-cpuidle",
>>> +		.owner		= THIS_MODULE,
>>> +		.of_match_table	= clps711x_cpuidle_dt_ids,
>>> +	},
>>> +	.remove	= clps711x_cpuidle_remove,
>>> +};
>>> +module_platform_driver_probe(clps711x_cpuidle_driver, clps711x_cpuidle_probe);
>>
>> +1
> 
> ??? What here?

I like the approach :)

Thanks
  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From paul at pwsan.com  Sun Jul 21 05:36:36 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Sun, 21 Jul 2013 09:36:36 +0000 (UTC)
Subject: OMAP baseline test results for v3.11-rc1
Message-ID: <alpine.DEB.2.02.1307210933330.15337@utopia.booyaka.com>



Here are some basic OMAP test results for Linux v3.11-rc1.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v3.11-rc1/20130721020309/


Test summary
------------

Build: uImage:
    Pass (14/14): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
		  omap1_defconfig_1510innovator_only,
		  omap1_defconfig_5912osk_only, omap2plus_defconfig,
		  omap2plus_defconfig_2430sdp_only,
		  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
		  omap2plus_defconfig_omap2_4_only,
		  omap2plus_defconfig_omap3_4_only,
		  rmk_omap3430_ldp_allnoconfig,
		  rmk_omap3430_ldp_oldconfig,
		  rmk_omap4430_sdp_allnoconfig

Build: uImage+dtb:
    Pass ( 3/ 3): am33xx_only/am335x-bone,
		  omap2plus_defconfig/omap4-panda,
		  omap2plus_defconfig/omap4-panda-es

Build: zImage:
    Pass ( 1/ 1): omap2plus_defconfig

Boot to userspace:
    FAIL ( 5/ 11): 2430sdp, 3530es3beagle, 3730beaglexm, 5912osk, am335xbonelt
    Pass ( 6/ 11): 3517evm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, cmt3517

PM: chip retention via suspend:
    FAIL ( 4/ 6): 2430sdp, 3530es3beagle, 3730beaglexm, 4430es2panda
    Pass ( 2/ 6): 37xxevm, 4460pandaes

PM: chip retention via dynamic idle:
    FAIL ( 5/ 6): 2430sdp, 3530es3beagle, 3730beaglexm, 4430es2panda, 4460pandaes
    Pass ( 1/ 6): 37xxevm

PM: chip off except CORE via suspend:
    FAIL ( 1/ 1): 3730beaglexm

PM: chip off except CORE via dynamic idle:
    FAIL ( 1/ 1): 3730beaglexm

PM: chip off via suspend:
    FAIL ( 3/ 4): 3530es3beagle, 4430es2panda, 4460pandaes
    Pass ( 1/ 4): 37xxevm

PM: chip off via dynamic idle:
    FAIL ( 3/ 4): 3530es3beagle, 4430es2panda, 4460pandaes
    Pass ( 1/ 4): 37xxevm


vmlinux object size
(delta in bytes from test_v3.10 (8bb495e3f02401ee6f76d1b1d77f3ac9f079e376)):
   text     data      bss    total  kernel
+105416    +2632    +2000  +110048  am33xx_only
 +42013    +1728     +960   +44701  n800_multi_omap2xxx
 +41993    +1592     +960   +44545  n800_only_a
 +45499     +832     +472   +46803  omap1_defconfig
 +50118    +2584     +472   +53174  omap1_defconfig_1510innovator_only
 +53938    +2648     +440   +57026  omap1_defconfig_5912osk_only
+159173    -2456    +1680  +158397  omap2plus_defconfig
+156519    +8608    +2752  +167879  omap2plus_defconfig_2430sdp_only
+144258    -4400    +1680  +141538  omap2plus_defconfig_cpupm
+155750    -2800    +1744  +154694  omap2plus_defconfig_no_pm
+155973   -27688    +1936  +130221  omap2plus_defconfig_omap2_4_only
+103989   -55072    +1616   +50533  omap2plus_defconfig_omap3_4_only
 -30840  -110588     -736  -142164  rmk_omap3430_ldp_allnoconfig
 +41080   -28816    +3988   +16252  rmk_omap3430_ldp_oldconfig
 -60468  -176540     +560  -236448  rmk_omap4430_sdp_allnoconfig


Boot-time memory difference
(delta in bytes from test_v3.10 (8bb495e3f02401ee6f76d1b1d77f3ac9f079e376))
  avail  rsrvd   high  freed  board          kconfig
   -44k    44k      .    -4k  2420n800       n800_only_a
 -98412k -32660k      .  -392k  2430sdp        omap2plus_defconfig
  -152k  -872k      .   -12k  3517evm        omap2plus_defconfig
  -152k  -872k      .   -12k  3530es3beagle  omap2plus_defconfig
  -152k  -872k      .   -12k  3730beaglexm   omap2plus_defconfig
  -216k  -808k      .   -12k  4430es2panda   omap2plus_defconfig
  -204k  -820k      .   -12k  4460pandaes    omap2plus_defconfig
   -48k    48k      .      .  5912osk        omap1_defconfig
  -116k   116k      .     4k  am335xbone     am33xx_only
  -152k  -872k      .   -12k  am335xbonelt   am33xx_only


OMAP4 platforms have been switched to DT boots, since board file-based 
booting was deprecated for OMAP4 after v3.10.


From shc_work at mail.ru  Sun Jul 21 06:04:52 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sun, 21 Jul 2013 14:04:52 +0400
Subject: [PATCH 08/10] ARM: clps711x: Add CLPS711X cpuidle driver
In-Reply-To: <51EB9C9F.5040405@linaro.org>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
 <1374172501-26796-9-git-send-email-shc_work@mail.ru>
 <51EB0433.3050308@linaro.org>
 <20130721081138.75cf5437bc30f42284f12e47@mail.ru>
 <51EB9C9F.5040405@linaro.org>
Message-ID: <20130721140452.826cb0b8f8f5ab01867aec90@mail.ru>

On Sun, 21 Jul 2013 10:32:31 +0200
Daniel Lezcano <daniel.lezcano at linaro.org> wrote:

> On 07/21/2013 06:11 AM, Alexander Shiyan wrote:
> > On Sat, 20 Jul 2013 23:42:11 +0200
> > Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
> > 
> >> On 07/18/2013 08:34 PM, Alexander Shiyan wrote:
> >>> This adds the cpuidle driver for Cirrus Logic CLPS711X series SoCs.
> >>> Designed primarily for migration CLPS711X subarch for multiplatform & DT.
> >>>
> >>> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> >>> ---
> >>>  drivers/cpuidle/Kconfig            |  6 +++
> >>>  drivers/cpuidle/Makefile           |  1 +
> >>>  drivers/cpuidle/cpuidle-clps711x.c | 80 ++++++++++++++++++++++++++++++++++++++
> >>>  3 files changed, 87 insertions(+)
> >>>  create mode 100644 drivers/cpuidle/cpuidle-clps711x.c
> > [...]
> >>> +static int clps711x_cpuidle_halt(struct cpuidle_device *dev,
> >>> +				 struct cpuidle_driver *drv, int index)
> >>> +{
> >>> +	writel(1, clps711x_halt);
> >>
> >> In what the 'clps711x_halt' differs from the usual WFI (cpu_do_idle) ?
> > 
> > AFAIK, ARM720T does not implement the WFI instruction.
> > "HALT" register in CLPS711X do the same:
> > "A write to this location will put the system into the Idle State by
> > halting the clock to the processor until an interrupt is generated."
> 
> I am wondering if you are not using more states, may be you can consider
> to add a clps711x idle function for the 'arm_pm_idle' callback instead
> of creating a new driver.

Currently, this is exactly what is done :)
But I really would like to further add a second mode (STDBY),
which allow to use all PM features.
At this time add this mode is too hard, because there are some barriers
for this, which will be resolved when all drivers for this platform will
contains DT-support.

[...]

-- 
Alexander Shiyan <shc_work at mail.ru>


From s.hauer at pengutronix.de  Sun Jul 21 06:22:48 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Sun, 21 Jul 2013 12:22:48 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130721025910.GA23043@kroah.com>
References: <20130720220006.GA7977@kroah.com>
 <Pine.LNX.4.44L0.1307202223430.8250-100000@netrider.rowland.org>
 <20130721025910.GA23043@kroah.com>
Message-ID: <20130721102248.GE29785@pengutronix.de>

On Sat, Jul 20, 2013 at 07:59:10PM -0700, Greg KH wrote:
> On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
> > On Sat, 20 Jul 2013, Greg KH wrote:
> > 
> > > > >>That should be passed using platform data.
> > > > >
> > > > >Ick, don't pass strings around, pass pointers.  If you have platform
> > > > >data you can get to, then put the pointer there, don't use a "name".
> > > > 
> > > > I don't think I understood you here :-s We wont have phy pointer
> > > > when we create the device for the controller no?(it'll be done in
> > > > board file). Probably I'm missing something.
> > > 
> > > Why will you not have that pointer?  You can't rely on the "name" as the
> > > device id will not match up, so you should be able to rely on the
> > > pointer being in the structure that the board sets up, right?
> > > 
> > > Don't use names, especially as ids can, and will, change, that is going
> > > to cause big problems.  Use pointers, this is C, we are supposed to be
> > > doing that :)
> > 
> > Kishon, I think what Greg means is this:  The name you are using must
> > be stored somewhere in a data structure constructed by the board file,
> > right?  Or at least, associated with some data structure somehow.  
> > Otherwise the platform code wouldn't know which PHY hardware
> > corresponded to a particular name.
> > 
> > Greg's suggestion is that you store the address of that data structure 
> > in the platform data instead of storing the name string.  Have the 
> > consumer pass the data structure's address when it calls phy_create, 
> > instead of passing the name.  Then you don't have to worry about two 
> > PHYs accidentally ending up with the same name or any other similar 
> > problems.
> 
> Close, but the issue is that whatever returns from phy_create() should
> then be used, no need to call any "find" functions, as you can just use
> the pointer that phy_create() returns.  Much like all other class api
> functions in the kernel work.

I think the problem here is to connect two from the bus structure
completely independent devices. Several frameworks (ASoC, soc-camera)
had this problem and this wasn't solved until the advent of devicetrees
and their phandles.
phy_create might be called from the probe function of some i2c device
(the phy device) and the resulting pointer is then needed in some other
platform devices (the user of the phy) probe function.
The best solution we have right now is implemented in the clk framework
which uses a string matching of the device names in clk_get() (at least
in the non-dt case).

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From cavokz at gmail.com  Sun Jul 21 06:29:25 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Sun, 21 Jul 2013 12:29:25 +0200
Subject: [PATCH 1/5] ARM: bcm4760: Add platform infrastructure
In-Reply-To: <201307211009.31789.arnd@arndb.de>
References: <20130721002320.730568671@gmail.com>
 <20130721002713.512199844@gmail.com> <201307211009.31789.arnd@arndb.de>
Message-ID: <d40f0756-7ba0-4416-9576-63470274be1b@email.android.com>

Arnd Bergmann <arnd at arndb.de> wrote:
>On Sunday 21 July 2013, Domenico Andreoli wrote:
>> From: Domenico Andreoli <domenico.andreoli at linux.com>
>> 
>> Platform infrastructure for the Broadcom BCM4760 based ARM11 SoCs.
>> 
>> Cc: linux-arm-kernel at lists.infradead.org
>> Signed-off-by: Domenico Andreoli <domenico.andreoli at linux.com>
>
>Looks very nice overall, thanks for following up on this!

Thank you for reviewing again.

>
>> +#define BCM4760_PERIPH_PHYS   0x00080000
>> +#define BCM4760_PERIPH_VIRT   IOMEM(0xd0080000)
>> +#define BCM4760_PERIPH_SIZE   SZ_512K
>> +
>> +static struct map_desc io_map __initdata = {
>> +	.virtual = (unsigned long) BCM4760_PERIPH_VIRT,
>> +	.pfn = __phys_to_pfn(BCM4760_PERIPH_PHYS),
>> +	.length = BCM4760_PERIPH_SIZE,
>> +	.type = MT_DEVICE,
>> +};
>> +
>> +static void __init bcm4760_map_io(void)
>> +{
>> +	iotable_init(&io_map, 1);
>> +}
>
>I would hope expect a comment here explaining what those registers are
>and why
>they are mapped early.

Without these the board doesn't boot so I must be doing something
wrong somewhere else. I'll investigate.

>
>> +
>> +#define BCM4760_CPUID0 IOMEM(0xd00b0ff0)
>> +#define BCM4760_CPUID1 IOMEM(0xd00b0ff4)
>
>Better make these
>
>#define BCM4760_CPUID0 (BCM4760_PERIPH_VIRT + 0x30ff0)
>#define BCM4760_CPUID1 (BCM4760_PERIPH_VIRT + 0x30ff4)
>
>for clarity.
>
>> +static void __init bcm4760_system_rev(void)
>> +{
>> +	u32 id0, id1;
>> +
>> +	id0 = readl_relaxed(BCM4760_CPUID0);
>> +	id1 = readl_relaxed(BCM4760_CPUID1);
>> +
>> +	if (id0 >> 16 != 0xbcbc)
>> +		system_rev = 0xbc4760a0;
>> +	else
>> +		system_rev = id0 << 8 | (id1 & 0xff);
>> +}
>
>Or even better, change this function to do:
>
>	struct device_node *node = of_find_compatible_node(NULL, NULL,
>"brcm,whatever");
>	void __iomem *regs = of_iomap(node, 0);
>	u32 id0, id1;
>
>	id0 = readl_relaxed(regs + BCM4760_CPUID0);
>	id1 = readl_relaxed(regs + BCM4760_CPUID1);
>
>	...
>
>	iounmap(regs);
>	of_node_put(node);
>
>
>bonus points if you use soc_device_register();
>
>What is the system_rev variable actually used for?

I use it to show something sensible in /proc/cpuinfo, to report
whether the soc is  a 4760 or 4761 and the silicon revision.

If the proper way to deal with this has so much boilerplate as
you say, I think I'll drop it altogether. I'd like to print the info
somewhere in the bootlog anyway.

btw this could well be one of the accesses requiring the io
mapping above.


>> +		uart0 at c0000 {
>> +			compatible = "brcm,bcm4760-pl011", "arm,pl011", "arm,primecell";
>> +			reg = <0xc0000 0x1000>;
>> +			interrupt-parent = <&vic0>;
>> +			interrupts = <14>;
>> +		};
>> +
>> +		uart1 at c1000 {
>> +			compatible = "brcm,bcm4760-pl011", "arm,pl011", "arm,primecell";
>> +			reg = <0xc1000 0x1000>;
>> +			interrupt-parent = <&vic0>;
>> +			interrupts = <15>;
>> +		};
>> +
>> +		uart2 at b2000 {
>> +			compatible = "brcm,bcm4760-pl011", "arm,pl011", "arm,primecell";
>> +			reg = <0xb2000 0x1000>;
>> +			interrupt-parent = <&vic0>;
>> +			interrupts = <16>;
>> +		};
>> +	};
>
>Please change the names here to say "serial" rather than "uartX". The
>name should not
>have an index in it (that's what the @address part is for) and there
>are conventions
>for common devices.

ok, will fix

>If some of the serial ports are not connected on all boars, best mark
>them as
>status="disabled"; here and only enable them in the board specific
>file.

uhm..  interesting

>> +config ARCH_BCM4760
>> +	bool "Broadcom BCM4760 based SoCs (ARM11)" if ARCH_MULTI_V6
>> +	select ARCH_WANT_OPTIONAL_GPIOLIB
>> +	select ARM_AMBA
>> +	select ARM_VIC
>> +	select CLKDEV_LOOKUP
>> +	select CLKSRC_OF
>> +	select COMMON_CLK
>> +	select CPU_V6
>> +	select GENERIC_CLOCKEVENTS
>> +	select GENERIC_IRQ_CHIP
>> +	select MULTI_IRQ_HANDLER
>> +	select NO_IOPORT
>> +	select PINCTRL
>> +	select PINMUX
>> +	select SPARSE_IRQ
>> +	select USE_OF
>
>A lot of these are implied by ARCH_MULTIPLATFORM or ARCH_MULTI_V6 and
>can be removed
>here. I don't think you should select 'PINCTRL and PINMUX' here, as
>long as the code
>builds without them.
>
>	Arnd
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel




From tomasz.figa at gmail.com  Sun Jul 21 06:31:05 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sun, 21 Jul 2013 12:31:05 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130721025910.GA23043@kroah.com>
References: <20130720220006.GA7977@kroah.com>
 <Pine.LNX.4.44L0.1307202223430.8250-100000@netrider.rowland.org>
 <20130721025910.GA23043@kroah.com>
Message-ID: <3839600.WiC1OLF35o@flatron>

Hi,

On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
> On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
> > On Sat, 20 Jul 2013, Greg KH wrote:
> > > > >>That should be passed using platform data.
> > > > >
> > > > >Ick, don't pass strings around, pass pointers.  If you have
> > > > >platform
> > > > >data you can get to, then put the pointer there, don't use a
> > > > >"name".
> > > > 
> > > > I don't think I understood you here :-s We wont have phy pointer
> > > > when we create the device for the controller no?(it'll be done in
> > > > board file). Probably I'm missing something.
> > > 
> > > Why will you not have that pointer?  You can't rely on the "name" as
> > > the device id will not match up, so you should be able to rely on
> > > the pointer being in the structure that the board sets up, right?
> > > 
> > > Don't use names, especially as ids can, and will, change, that is
> > > going
> > > to cause big problems.  Use pointers, this is C, we are supposed to
> > > be
> > > doing that :)
> > 
> > Kishon, I think what Greg means is this:  The name you are using must
> > be stored somewhere in a data structure constructed by the board file,
> > right?  Or at least, associated with some data structure somehow.
> > Otherwise the platform code wouldn't know which PHY hardware
> > corresponded to a particular name.
> > 
> > Greg's suggestion is that you store the address of that data structure
> > in the platform data instead of storing the name string.  Have the
> > consumer pass the data structure's address when it calls phy_create,
> > instead of passing the name.  Then you don't have to worry about two
> > PHYs accidentally ending up with the same name or any other similar
> > problems.
> 
> Close, but the issue is that whatever returns from phy_create() should
> then be used, no need to call any "find" functions, as you can just use
> the pointer that phy_create() returns.  Much like all other class api
> functions in the kernel work.

I think there is a confusion here about who registers the PHYs.

All platform code does is registering a platform/i2c/whatever device, 
which causes a driver (located in drivers/phy/) to be instantiated. Such 
drivers call phy_create(), usually in their probe() callbacks, so 
platform_code has no way (and should have no way, for the sake of 
layering) to get what phy_create() returns.

IMHO we need a lookup method for PHYs, just like for clocks, regulators, 
PWMs or even i2c busses because there are complex cases when passing just 
a name using platform data will not work. I would second what Stephen said 
[1] and define a structure doing things in a DT-like way.

Example;

[platform code]

static const struct phy_lookup my_phy_lookup[] = {
	PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
	/* etc... */
};

static void my_machine_init(void)
{
	/* ... */
	phy_register_lookup(my_phy_lookup, ARRAY_SIZE(my_phy_lookup));
	/* ... */
}

/* Notice nothing stuffed in platform data. */

[provider code - samsung-usbphy driver]

static int samsung_usbphy_probe(...)
{
	/* ... */
		for (i = 0; i < PHY_COUNT; ++i) {
			usbphy->phy[i].name = "phy";
			usbphy->phy[i].id = i;
			/* ... */
			ret = phy_create(&usbphy->phy);
			/* err handling */
		}
	/* ... */
}

[consumer code - s3c-hsotg driver]

static int s3c_hsotg_probe(...)
{
	/* ... */
	phy = phy_get(&pdev->dev, "otg");
	/* ... */
}

[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813

Best regards,
Tomasz



From kishon at ti.com  Sun Jul 21 07:07:33 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Sun, 21 Jul 2013 16:37:33 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <3839600.WiC1OLF35o@flatron>
References: <20130720220006.GA7977@kroah.com>
 <Pine.LNX.4.44L0.1307202223430.8250-100000@netrider.rowland.org>
 <20130721025910.GA23043@kroah.com> <3839600.WiC1OLF35o@flatron>
Message-ID: <51EBC0F5.70601@ti.com>

Hi,

On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
> Hi,
>
> On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
>> On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
>>> On Sat, 20 Jul 2013, Greg KH wrote:
>>>>>>> That should be passed using platform data.
>>>>>>
>>>>>> Ick, don't pass strings around, pass pointers.  If you have
>>>>>> platform
>>>>>> data you can get to, then put the pointer there, don't use a
>>>>>> "name".
>>>>>
>>>>> I don't think I understood you here :-s We wont have phy pointer
>>>>> when we create the device for the controller no?(it'll be done in
>>>>> board file). Probably I'm missing something.
>>>>
>>>> Why will you not have that pointer?  You can't rely on the "name" as
>>>> the device id will not match up, so you should be able to rely on
>>>> the pointer being in the structure that the board sets up, right?
>>>>
>>>> Don't use names, especially as ids can, and will, change, that is
>>>> going
>>>> to cause big problems.  Use pointers, this is C, we are supposed to
>>>> be
>>>> doing that :)
>>>
>>> Kishon, I think what Greg means is this:  The name you are using must
>>> be stored somewhere in a data structure constructed by the board file,
>>> right?  Or at least, associated with some data structure somehow.
>>> Otherwise the platform code wouldn't know which PHY hardware
>>> corresponded to a particular name.
>>>
>>> Greg's suggestion is that you store the address of that data structure
>>> in the platform data instead of storing the name string.  Have the
>>> consumer pass the data structure's address when it calls phy_create,
>>> instead of passing the name.  Then you don't have to worry about two
>>> PHYs accidentally ending up with the same name or any other similar
>>> problems.
>>
>> Close, but the issue is that whatever returns from phy_create() should
>> then be used, no need to call any "find" functions, as you can just use
>> the pointer that phy_create() returns.  Much like all other class api
>> functions in the kernel work.
>
> I think there is a confusion here about who registers the PHYs.
>
> All platform code does is registering a platform/i2c/whatever device,
> which causes a driver (located in drivers/phy/) to be instantiated. Such
> drivers call phy_create(), usually in their probe() callbacks, so
> platform_code has no way (and should have no way, for the sake of
> layering) to get what phy_create() returns.

right.
>
> IMHO we need a lookup method for PHYs, just like for clocks, regulators,
> PWMs or even i2c busses because there are complex cases when passing just
> a name using platform data will not work. I would second what Stephen said
> [1] and define a structure doing things in a DT-like way.
>
> Example;
>
> [platform code]
>
> static const struct phy_lookup my_phy_lookup[] = {
> 	PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),

The only problem here is that if *PLATFORM_DEVID_AUTO* is used while 
creating the device, the ids in the device name would change and 
PHY_LOOKUP wont be useful.

Thanks
Kishon


From tomasz.figa at gmail.com  Sun Jul 21 07:12:07 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sun, 21 Jul 2013 13:12:07 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51EBC0F5.70601@ti.com>
References: <20130720220006.GA7977@kroah.com> <3839600.WiC1OLF35o@flatron>
 <51EBC0F5.70601@ti.com>
Message-ID: <9748041.Qq1fWJBg6D@flatron>

On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
> > Hi,
> > 
> > On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
> >> On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
> >>> On Sat, 20 Jul 2013, Greg KH wrote:
> >>>>>>> That should be passed using platform data.
> >>>>>> 
> >>>>>> Ick, don't pass strings around, pass pointers.  If you have
> >>>>>> platform
> >>>>>> data you can get to, then put the pointer there, don't use a
> >>>>>> "name".
> >>>>> 
> >>>>> I don't think I understood you here :-s We wont have phy pointer
> >>>>> when we create the device for the controller no?(it'll be done in
> >>>>> board file). Probably I'm missing something.
> >>>> 
> >>>> Why will you not have that pointer?  You can't rely on the "name"
> >>>> as
> >>>> the device id will not match up, so you should be able to rely on
> >>>> the pointer being in the structure that the board sets up, right?
> >>>> 
> >>>> Don't use names, especially as ids can, and will, change, that is
> >>>> going
> >>>> to cause big problems.  Use pointers, this is C, we are supposed to
> >>>> be
> >>>> doing that :)
> >>> 
> >>> Kishon, I think what Greg means is this:  The name you are using
> >>> must
> >>> be stored somewhere in a data structure constructed by the board
> >>> file,
> >>> right?  Or at least, associated with some data structure somehow.
> >>> Otherwise the platform code wouldn't know which PHY hardware
> >>> corresponded to a particular name.
> >>> 
> >>> Greg's suggestion is that you store the address of that data
> >>> structure
> >>> in the platform data instead of storing the name string.  Have the
> >>> consumer pass the data structure's address when it calls phy_create,
> >>> instead of passing the name.  Then you don't have to worry about two
> >>> PHYs accidentally ending up with the same name or any other similar
> >>> problems.
> >> 
> >> Close, but the issue is that whatever returns from phy_create()
> >> should
> >> then be used, no need to call any "find" functions, as you can just
> >> use
> >> the pointer that phy_create() returns.  Much like all other class api
> >> functions in the kernel work.
> > 
> > I think there is a confusion here about who registers the PHYs.
> > 
> > All platform code does is registering a platform/i2c/whatever device,
> > which causes a driver (located in drivers/phy/) to be instantiated.
> > Such drivers call phy_create(), usually in their probe() callbacks,
> > so platform_code has no way (and should have no way, for the sake of
> > layering) to get what phy_create() returns.
> 
> right.
> 
> > IMHO we need a lookup method for PHYs, just like for clocks,
> > regulators, PWMs or even i2c busses because there are complex cases
> > when passing just a name using platform data will not work. I would
> > second what Stephen said [1] and define a structure doing things in a
> > DT-like way.
> > 
> > Example;
> > 
> > [platform code]
> > 
> > static const struct phy_lookup my_phy_lookup[] = {
> > 
> > 	PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
> 
> The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
> creating the device, the ids in the device name would change and
> PHY_LOOKUP wont be useful.

I don't think this is a problem. All the existing lookup methods already 
use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You 
can simply add a requirement that the ID must be assigned manually, 
without using PLATFORM_DEVID_AUTO to use PHY lookup.

Best regards,
Tomasz



From arnd at arndb.de  Sun Jul 21 08:00:21 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sun, 21 Jul 2013 14:00:21 +0200
Subject: [PATCH 1/5] ARM: bcm4760: Add platform infrastructure
In-Reply-To: <d40f0756-7ba0-4416-9576-63470274be1b@email.android.com>
References: <20130721002320.730568671@gmail.com>
 <201307211009.31789.arnd@arndb.de>
 <d40f0756-7ba0-4416-9576-63470274be1b@email.android.com>
Message-ID: <201307211400.21295.arnd@arndb.de>

On Sunday 21 July 2013, Domenico Andreoli wrote:
> >bonus points if you use soc_device_register();
> >
> >What is the system_rev variable actually used for?
> 
> I use it to show something sensible in /proc/cpuinfo, to report
> whether the soc is  a 4760 or 4761 and the silicon revision.
> 
> If the proper way to deal with this has so much boilerplate as
> you say, I think I'll drop it altogether. I'd like to print the info
> somewhere in the bootlog anyway.
> 
> btw this could well be one of the accesses requiring the io
> mapping above.

If it's just for informational purposes, soc_device_register() sounds like
the correct place to put that information, you can register a couple
of strings there that get put into sysfs at a known location for the
SoC, and keeps the cpuinfo for the actual CPU core.

	Arnd


From s.hauer at pengutronix.de  Sun Jul 21 08:37:59 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Sun, 21 Jul 2013 14:37:59 +0200
Subject: [RFC v2] ARM: i.MX pllv1: Implement set_rate
In-Reply-To: <20130720161801.380bb0d9db75155f5401730b@mail.ru>
References: <1374308975-20596-1-git-send-email-shc_work@mail.ru>
 <20130720111639.GA29785@pengutronix.de>
 <20130720153104.96b6723a20bde172a8ea1ba1@mail.ru>
 <20130720115829.GD29785@pengutronix.de>
 <20130720161801.380bb0d9db75155f5401730b@mail.ru>
Message-ID: <20130721123759.GJ29785@pengutronix.de>

On Sat, Jul 20, 2013 at 04:18:01PM +0400, Alexander Shiyan wrote:
> On Sat, 20 Jul 2013 13:58:29 +0200
> Sascha Hauer <s.hauer at pengutronix.de> wrote:
> 
> > > > On Sat, Jul 20, 2013 at 12:29:35PM +0400, Alexander Shiyan wrote:
> > > > > This patch implements frequency change for i.MX pllv1.
> > > > > Selection of the values of the registers is not optimal, since is
> > > > > made by simple enumeration of all possible values.
> > > > 
> > > > You do not mention why you want to adjust the rate. Normally we've been
> > > > happy with the static values from the bootloader.
> > > 
> > > For CPUfreq.
> > > Only one barrier to make it workable.
> > 
> > Isn't it better to adjust the dividers only? I haven't made good
> > experience with adjusting the PLLs.
> 
> The frequency value after booting can be quite arbitrary.
> 
> Since we define possible frequencies for the CPU (266 and 399 MHz),
> I can offer as variant to use a fixed constant values for PLL.

AFAIK the PLL should run at 800MHz. With dividers of 2, 3 and 6 we get
400, 266 and 133MHz. I don't think having more fine grained control
about the CPU frequency is necessary from a power saving point of view.
Let's keep the variants to a minimum to make the whole stuff more
robust.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From dev at lynxeye.de  Sun Jul 21 09:02:29 2013
From: dev at lynxeye.de (Lucas Stach)
Date: Sun, 21 Jul 2013 15:02:29 +0200
Subject: [PATCH] ASoC: tegra: correct playback_dma_data setup
In-Reply-To: <1374374049-30732-1-git-send-email-rizhao@nvidia.com>
References: <1374374049-30732-1-git-send-email-rizhao@nvidia.com>
Message-ID: <1374411749.1633.1.camel@tellur>

Am Sonntag, den 21.07.2013, 10:34 +0800 schrieb Richard Zhao:
> The errors were caused by copy/paste mistake in below commit
> since v3.10:
> 3489d50 ASoC: tegra: Use common DAI DMA data struct
> 
> It also corrects slave_id initialization in tegra20_ac97 driver.
> 
> Signed-off-by: Richard Zhao <rizhao at nvidia.com>
> Cc: Lars-Peter Clausen <lars at metafoo.de>
> Cc: <stable at vger.kernel.org> # 3.10

Acked-by: Lucas Stach <dev at lynxeye.de>

> ---
>  sound/soc/tegra/tegra20_ac97.c  | 6 +++---
>  sound/soc/tegra/tegra20_spdif.c | 4 ++--
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/sound/soc/tegra/tegra20_ac97.c b/sound/soc/tegra/tegra20_ac97.c
> index e58233f..6c48662 100644
> --- a/sound/soc/tegra/tegra20_ac97.c
> +++ b/sound/soc/tegra/tegra20_ac97.c
> @@ -389,9 +389,9 @@ static int tegra20_ac97_platform_probe(struct platform_device *pdev)
>  	ac97->capture_dma_data.slave_id = of_dma[1];
>  
>  	ac97->playback_dma_data.addr = mem->start + TEGRA20_AC97_FIFO_TX1;
> -	ac97->capture_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> -	ac97->capture_dma_data.maxburst = 4;
> -	ac97->capture_dma_data.slave_id = of_dma[0];
> +	ac97->playback_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> +	ac97->playback_dma_data.maxburst = 4;
> +	ac97->playback_dma_data.slave_id = of_dma[1];
>  
>  	ret = tegra_asoc_utils_init(&ac97->util_data, &pdev->dev);
>  	if (ret)
> diff --git a/sound/soc/tegra/tegra20_spdif.c b/sound/soc/tegra/tegra20_spdif.c
> index 5eaa12c..551b3c9 100644
> --- a/sound/soc/tegra/tegra20_spdif.c
> +++ b/sound/soc/tegra/tegra20_spdif.c
> @@ -323,8 +323,8 @@ static int tegra20_spdif_platform_probe(struct platform_device *pdev)
>  	}
>  
>  	spdif->playback_dma_data.addr = mem->start + TEGRA20_SPDIF_DATA_OUT;
> -	spdif->capture_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> -	spdif->capture_dma_data.maxburst = 4;
> +	spdif->playback_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> +	spdif->playback_dma_data.maxburst = 4;
>  	spdif->playback_dma_data.slave_id = dmareq->start;
>  
>  	pm_runtime_enable(&pdev->dev);




From stefano.stabellini at eu.citrix.com  Sun Jul 21 10:09:13 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Sun, 21 Jul 2013 15:09:13 +0100
Subject: [PATCH v2] xen/arm: disable cpuidle and cpufreq when linux is
 running as dom0
In-Reply-To: <1374233220-13770-1-git-send-email-julien.grall@linaro.org>
References: <1374233220-13770-1-git-send-email-julien.grall@linaro.org>
Message-ID: <alpine.DEB.2.02.1307211508520.4893@kaball.uk.xensource.com>

On Fri, 19 Jul 2013, Julien Grall wrote:
> When linux is running as dom0, Xen doesn't show the physical cpu but a
> virtual CPU.
> On some ARM SOC (for instance the exynos 5250), linux registers callbacks
> for cpuidle and cpufreq. When these callbacks are called, they will modify
> directly the physical cpu not the virtual one. It can impact the whole board
> instead of only dom0.
> 
> Signed-off-by: Julien Grall <julien.grall at linaro.org>
> 

Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>


>     Changes in v2:
>         - Disable cpufreq
> ---
>  arch/arm/xen/enlighten.c |    8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 49839d8..af82792 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -24,6 +24,8 @@
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_address.h>
> +#include <linux/cpuidle.h>
> +#include <linux/cpufreq.h>
>  
>  #include <linux/mm.h>
>  
> @@ -292,6 +294,12 @@ static int __init xen_pm_init(void)
>  {
>  	pm_power_off = xen_power_off;
>  	arm_pm_restart = xen_restart;
> +	/*
> +	 * Making sure board specific code will not set up ops for
> +	 * cpu idle and cpu freq.
> +	 */
> +	disable_cpuidle();
> +	disable_cpufreq();
>  
>  	return 0;
>  }
> -- 
> 1.7.10.4
> 


From khc at pm.waw.pl  Sun Jul 21 10:45:45 2013
From: khc at pm.waw.pl (Krzysztof Halasa)
Date: Sun, 21 Jul 2013 16:45:45 +0200
Subject: [PATCH 1/2] arm: ixp4xx: set cohorent_dma_mask for ethernet
 platform devices
In-Reply-To: <1374315339-31469-2-git-send-email-jogo@openwrt.org> (Jonas
 Gorski's message of "Sat, 20 Jul 2013 12:15:38 +0200")
References: <1374315339-31469-1-git-send-email-jogo@openwrt.org>
 <1374315339-31469-2-git-send-email-jogo@openwrt.org>
Message-ID: <m3ip04ezty.fsf@intrepid.localdomain>

Jonas Gorski <jogo at openwrt.org> writes:

> ARM requires the cohorent_dma_mask set, so set it for the platform
> devices so that the ethernet driver has access to it.

I recognize the need to fix this issue and I appreciate your efforts,
but... I think this patch tries to make the driver functional again at
all costs and this a very bad idea. The IXP4xx Ethernet MACs are not
normal platform devices, they are in fact built-in CPU resources. The
platform device structs are only used to set parameters. What the patch
does is unneeded and IMHO harmful code duplication. It makes completely
no sense to set DMA masks in code for individual platforms as it's not
something platforms can decide, or *even should know of*. It's simply
a CPU attribute, a value that is shared by all IXP4xx CPUs and thus all
platforms and systems using it.

This is against the "line of code" count rules (or "rules").

Also the dev->dev.parent is IMHO a bad idea. The queue numbers and MAC
addresses are in no way "parents" of Ethernet controllers, and even if
they somehow were, I find it rather hard to believe they can have DMA
masks.

I think the previous patch (which sets the masks in one place, in
Ethernet driver code) was better, though not perfect.

My fault is I haven't fixed it yet. Will try to invent something.
-- 
Krzysztof Halasa


From stefano.stabellini at eu.citrix.com  Sun Jul 21 10:54:24 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Sun, 21 Jul 2013 15:54:24 +0100
Subject: [PATCH v2] xen/arm: enable PV control for ARM
In-Reply-To: <1374239399-2498-1-git-send-email-julien.grall@linaro.org>
References: <1374239399-2498-1-git-send-email-julien.grall@linaro.org>
Message-ID: <alpine.DEB.2.02.1307211535210.4893@kaball.uk.xensource.com>

On Fri, 19 Jul 2013, Julien Grall wrote:
> Enable power management from the toolstack for ARM guest.
> 
> Signed-off-by: Julien Grall <julien.grall at linaro.org>
> 
> ---
>     Changes in v2:
>         - Don't compile xen/cpu_hotplug.o with ARM64
> ---
>  drivers/xen/Makefile |    5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 2bf461a..b550a94 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -1,9 +1,8 @@
> -ifneq ($(CONFIG_ARM),y)
> -obj-y	+= manage.o
> +ifneq ($(filter y, ($CONFIG_ARM) $(CONFIG_ARM64)),y

This is wrong: ifneq is checking for the opposite condition of what we want, and
beside you have the $ in the wrong place for CONFIG_ARM.

Please test you patches before sending them.


>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>  endif
>  obj-$(CONFIG_X86)			+= fallback.o
> -obj-y	+= grant-table.o features.o events.o balloon.o time.o
> +obj-y	+= grant-table.o features.o events.o balloon.o time.o manage.o
>  obj-y	+= xenbus/
>  
>  nostackp := $(call cc-option, -fno-stack-protector)
> -- 
> 1.7.10.4
> 


From stefano.stabellini at eu.citrix.com  Sun Jul 21 11:24:17 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Sun, 21 Jul 2013 16:24:17 +0100
Subject: [PATCH] xen/arm and xen/arm64: update xen_restart after ff701306cd49
Message-ID: <1374420257-19467-1-git-send-email-stefano.stabellini@eu.citrix.com>

Commit ff701306cd49 changes the prototype of arm_pm_restart.
Update xen_restart accordingly.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/xen/enlighten.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index f71c37e..c9770ba 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -172,7 +172,7 @@ static void __init xen_percpu_init(void *unused)
 	enable_percpu_irq(xen_events_irq, 0);
 }
 
-static void xen_restart(char str, const char *cmd)
+static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
 {
 	struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
 	int rc;
-- 
1.7.2.5



From thomas.petazzoni at free-electrons.com  Sun Jul 21 11:27:00 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sun, 21 Jul 2013 17:27:00 +0200
Subject: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
In-Reply-To: <20130720194559.GA27517@lunn.ch>
References: <1373900271-4722-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130720165855.GB26625@lunn.ch> <20130720173847.GC26625@lunn.ch>
 <20130720185443.GB21460@localhost> <20130720194559.GA27517@lunn.ch>
Message-ID: <20130721172700.6bd14e58@skate>

Dear Andrew Lunn,

On Sat, 20 Jul 2013 21:45:59 +0200, Andrew Lunn wrote:
> > The patchset works only for Armada 370 and Armada XP SoC, not for Kirkwood.
> > For some reason I was completely sure there wasn't any DT-enabled Kirkwood
> > boards with PCIe support.
> 
> I had a quick look at Dove and Orion5x. It looks like there are none
> with PCIe support. So only Kirkwood is broken.

There are some Dove and Orion5x with PCIe support, but none of them are
using the new PCIe driver yet.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From stefano.stabellini at eu.citrix.com  Sun Jul 21 11:38:43 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Sun, 21 Jul 2013 16:38:43 +0100
Subject: [PATCH v2] xen/arm: disable cpuidle and cpufreq when linux is
 running as dom0
In-Reply-To: <alpine.DEB.2.02.1307211508520.4893@kaball.uk.xensource.com>
References: <1374233220-13770-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307211508520.4893@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1307211638260.4893@kaball.uk.xensource.com>

On Sun, 21 Jul 2013, Stefano Stabellini wrote:
> On Fri, 19 Jul 2013, Julien Grall wrote:
> > When linux is running as dom0, Xen doesn't show the physical cpu but a
> > virtual CPU.
> > On some ARM SOC (for instance the exynos 5250), linux registers callbacks
> > for cpuidle and cpufreq. When these callbacks are called, they will modify
> > directly the physical cpu not the virtual one. It can impact the whole board
> > instead of only dom0.
> > 
> > Signed-off-by: Julien Grall <julien.grall at linaro.org>
> > 
> 
> Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>

I added the patch to my queue


From gregkh at linuxfoundation.org  Sun Jul 21 11:46:53 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Sun, 21 Jul 2013 08:46:53 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <9748041.Qq1fWJBg6D@flatron>
References: <20130720220006.GA7977@kroah.com> <3839600.WiC1OLF35o@flatron>
 <51EBC0F5.70601@ti.com> <9748041.Qq1fWJBg6D@flatron>
Message-ID: <20130721154653.GG16598@kroah.com>

On Sun, Jul 21, 2013 at 01:12:07PM +0200, Tomasz Figa wrote:
> On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
> > Hi,
> > 
> > On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
> > > Hi,
> > > 
> > > On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
> > >> On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
> > >>> On Sat, 20 Jul 2013, Greg KH wrote:
> > >>>>>>> That should be passed using platform data.
> > >>>>>> 
> > >>>>>> Ick, don't pass strings around, pass pointers.  If you have
> > >>>>>> platform
> > >>>>>> data you can get to, then put the pointer there, don't use a
> > >>>>>> "name".
> > >>>>> 
> > >>>>> I don't think I understood you here :-s We wont have phy pointer
> > >>>>> when we create the device for the controller no?(it'll be done in
> > >>>>> board file). Probably I'm missing something.
> > >>>> 
> > >>>> Why will you not have that pointer?  You can't rely on the "name"
> > >>>> as
> > >>>> the device id will not match up, so you should be able to rely on
> > >>>> the pointer being in the structure that the board sets up, right?
> > >>>> 
> > >>>> Don't use names, especially as ids can, and will, change, that is
> > >>>> going
> > >>>> to cause big problems.  Use pointers, this is C, we are supposed to
> > >>>> be
> > >>>> doing that :)
> > >>> 
> > >>> Kishon, I think what Greg means is this:  The name you are using
> > >>> must
> > >>> be stored somewhere in a data structure constructed by the board
> > >>> file,
> > >>> right?  Or at least, associated with some data structure somehow.
> > >>> Otherwise the platform code wouldn't know which PHY hardware
> > >>> corresponded to a particular name.
> > >>> 
> > >>> Greg's suggestion is that you store the address of that data
> > >>> structure
> > >>> in the platform data instead of storing the name string.  Have the
> > >>> consumer pass the data structure's address when it calls phy_create,
> > >>> instead of passing the name.  Then you don't have to worry about two
> > >>> PHYs accidentally ending up with the same name or any other similar
> > >>> problems.
> > >> 
> > >> Close, but the issue is that whatever returns from phy_create()
> > >> should
> > >> then be used, no need to call any "find" functions, as you can just
> > >> use
> > >> the pointer that phy_create() returns.  Much like all other class api
> > >> functions in the kernel work.
> > > 
> > > I think there is a confusion here about who registers the PHYs.
> > > 
> > > All platform code does is registering a platform/i2c/whatever device,
> > > which causes a driver (located in drivers/phy/) to be instantiated.
> > > Such drivers call phy_create(), usually in their probe() callbacks,
> > > so platform_code has no way (and should have no way, for the sake of
> > > layering) to get what phy_create() returns.

Why not put pointers in the platform data structure that can hold these
pointers?  I thought that is why we created those structures in the
first place.  If not, what are they there for?

> > > IMHO we need a lookup method for PHYs, just like for clocks,
> > > regulators, PWMs or even i2c busses because there are complex cases
> > > when passing just a name using platform data will not work. I would
> > > second what Stephen said [1] and define a structure doing things in a
> > > DT-like way.
> > > 
> > > Example;
> > > 
> > > [platform code]
> > > 
> > > static const struct phy_lookup my_phy_lookup[] = {
> > > 
> > > 	PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
> > 
> > The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
> > creating the device, the ids in the device name would change and
> > PHY_LOOKUP wont be useful.
> 
> I don't think this is a problem. All the existing lookup methods already 
> use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You 
> can simply add a requirement that the ID must be assigned manually, 
> without using PLATFORM_DEVID_AUTO to use PHY lookup.

And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways when
devices get added to systems, making these strings constantly have to be
kept up to date with different board configurations.

People, NEVER, hardcode something like an id.  The fact that this
happens today with the clock code, doesn't make it right, it makes the
clock code wrong.  Others have already said that this is wrong there as
well, as systems change and dynamic ids get used more and more.

Let's not repeat the same mistakes of the past just because we refuse to
learn from them...

So again, the "find a phy by a string" functions should be removed, the
device id should be automatically created by the phy core just to make
things unique in sysfs, and no driver code should _ever_ be reliant on
the number that is being created, and the pointer to the phy structure
should be used everywhere instead.

With those types of changes, I will consider merging this subsystem, but
without them, sorry, I will not.

thanks,

greg k-h


From gregkh at linuxfoundation.org  Sun Jul 21 11:48:08 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Sun, 21 Jul 2013 08:48:08 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130721102248.GE29785@pengutronix.de>
References: <20130720220006.GA7977@kroah.com>
 <Pine.LNX.4.44L0.1307202223430.8250-100000@netrider.rowland.org>
 <20130721025910.GA23043@kroah.com>
 <20130721102248.GE29785@pengutronix.de>
Message-ID: <20130721154808.GH16598@kroah.com>

On Sun, Jul 21, 2013 at 12:22:48PM +0200, Sascha Hauer wrote:
> On Sat, Jul 20, 2013 at 07:59:10PM -0700, Greg KH wrote:
> > On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
> > > On Sat, 20 Jul 2013, Greg KH wrote:
> > > 
> > > > > >>That should be passed using platform data.
> > > > > >
> > > > > >Ick, don't pass strings around, pass pointers.  If you have platform
> > > > > >data you can get to, then put the pointer there, don't use a "name".
> > > > > 
> > > > > I don't think I understood you here :-s We wont have phy pointer
> > > > > when we create the device for the controller no?(it'll be done in
> > > > > board file). Probably I'm missing something.
> > > > 
> > > > Why will you not have that pointer?  You can't rely on the "name" as the
> > > > device id will not match up, so you should be able to rely on the
> > > > pointer being in the structure that the board sets up, right?
> > > > 
> > > > Don't use names, especially as ids can, and will, change, that is going
> > > > to cause big problems.  Use pointers, this is C, we are supposed to be
> > > > doing that :)
> > > 
> > > Kishon, I think what Greg means is this:  The name you are using must
> > > be stored somewhere in a data structure constructed by the board file,
> > > right?  Or at least, associated with some data structure somehow.  
> > > Otherwise the platform code wouldn't know which PHY hardware
> > > corresponded to a particular name.
> > > 
> > > Greg's suggestion is that you store the address of that data structure 
> > > in the platform data instead of storing the name string.  Have the 
> > > consumer pass the data structure's address when it calls phy_create, 
> > > instead of passing the name.  Then you don't have to worry about two 
> > > PHYs accidentally ending up with the same name or any other similar 
> > > problems.
> > 
> > Close, but the issue is that whatever returns from phy_create() should
> > then be used, no need to call any "find" functions, as you can just use
> > the pointer that phy_create() returns.  Much like all other class api
> > functions in the kernel work.
> 
> I think the problem here is to connect two from the bus structure
> completely independent devices. Several frameworks (ASoC, soc-camera)
> had this problem and this wasn't solved until the advent of devicetrees
> and their phandles.
> phy_create might be called from the probe function of some i2c device
> (the phy device) and the resulting pointer is then needed in some other
> platform devices (the user of the phy) probe function.
> The best solution we have right now is implemented in the clk framework
> which uses a string matching of the device names in clk_get() (at least
> in the non-dt case).

I would argue that clocks are wrong here as well, as others have already
pointed out.

What's wrong with the platform_data structure, why can't that be used
for this?

Or, if not, we can always add pointers to the platform device structure,
or even the main 'struct device' as well, that's what it is there for.

thanks,

greg k-h


From linus.walleij at linaro.org  Sun Jul 21 12:15:03 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 21 Jul 2013 18:15:03 +0200
Subject: [PATCH 1/5] gpio: pxa: remove dead code
In-Reply-To: <1373555877-29887-2-git-send-email-zonque@gmail.com>
References: <1373555877-29887-1-git-send-email-zonque@gmail.com>
 <1373555877-29887-2-git-send-email-zonque@gmail.com>
Message-ID: <CACRpkdaB7JnWzoLKpQ1eLWAi7yFz9CanhbhwtiCnEtcNWzX3RQ@mail.gmail.com>

On Thu, Jul 11, 2013 at 5:17 PM, Daniel Mack <zonque at gmail.com> wrote:

> Commit f87311743 ("ARM: mmp: add more compatible names in gpio driver")
> changed the driver logic to determine the number of available GPIOs from
> the compatible string, and hence obsoleted the (undocumented) child
> nodes that were previously necessary. However, it left some remainder
> which can be safely removed now.
>
> Also, this patch makes pxa_gpio_probe_dt() return the correct value in
> case irq_alloc_descs() fails.
>
> Signed-off-by: Daniel Mack <zonque at gmail.com>
> Cc: Haojian Zhuang <haojian.zhuang at linaro.org>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Arnd Bergmann <arnd at arndb.de>

Tentatively applied, Haojian, does this look allright?

Yours,
Linus Walleij


From linus.walleij at linaro.org  Sun Jul 21 12:16:48 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 21 Jul 2013 18:16:48 +0200
Subject: [PATCH 2/5] gpio: pxa: fix Documentation of interrupt-names
 property
In-Reply-To: <1373555877-29887-3-git-send-email-zonque@gmail.com>
References: <1373555877-29887-1-git-send-email-zonque@gmail.com>
 <1373555877-29887-3-git-send-email-zonque@gmail.com>
Message-ID: <CACRpkdazAgZO4610Oppk12MCgErsKmEXcjnnkzsH4JMOBWB8Sg@mail.gmail.com>

On Thu, Jul 11, 2013 at 5:17 PM, Daniel Mack <zonque at gmail.com> wrote:

> The property name to pass names for interrupt resources is called
> "interrupt-names", not "interrupt-name". Fix it to avoid further
> confusion.
>
> Signed-off-by: Daniel Mack <zonque at gmail.com>
> Cc: Haojian Zhuang <haojian.zhuang at linaro.org>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Arnd Bergmann <arnd at arndb.de>

Obviously correct so applied.

Cc binding patches to devicetree at vger.kernel.org going
forward...

Yours,
Linus Walleij


From linus.walleij at linaro.org  Sun Jul 21 12:33:57 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 21 Jul 2013 18:33:57 +0200
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <20130718182504.GA7497@arwen.pp.htv.fi>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <20130718182504.GA7497@arwen.pp.htv.fi>
Message-ID: <CACRpkdYdLBzFnzB1xGOPoVt-j11UciPwYiy_c3i+xYY9UOngEw@mail.gmail.com>

On Thu, Jul 18, 2013 at 8:25 PM, Felipe Balbi <balbi at ti.com> wrote:

>> The Peripheral irq/dma requests are connected to one crossbar's input
>> and the output of the crossbar is connected to controller's input
>> line. On POR, there are some mappings which are done by default.
>> Those peripherals which do not have a mapping on POR, should be configured
>> to route its requests using the crossbar.
(...)
> why isn't this done under pinctrl ? If all it does is mux DMA and IRQ
> request lines, it should be written as a pinctrl driver no ?

Actually I was thinking about this at one time when designing pinctrl,
"what if we face the problem of arbitrary signal multiplexing?"

However pin control is named for what it does and also controls
things like the electrical properties of pins, biasing and so on which
is ill applicable here.

I would rather say that the pin multiplexing portions of pin control
could be rewritten to use a more generic component dealing with
arbitrary line multiplexing, i.e. something under /lib and maybe then
move over some generic concepts such as the function to group
mapping.

The same concept as found here is found in the muxes used by
drivers/dma/amba-pl08x.c back-ends on ARM reference hardware
which is also multiplexing DMA signals. In that case we have done
platform-specific hooks and implemented this in the per-machine
platform code.

Yours,
Linus Walleij


From bhutchings at solarflare.com  Sun Jul 21 12:40:23 2013
From: bhutchings at solarflare.com (Ben Hutchings)
Date: Sun, 21 Jul 2013 17:40:23 +0100
Subject: [PATCH 1/2] arm: ixp4xx: set cohorent_dma_mask for ethernet
 platform devices
In-Reply-To: <m3ip04ezty.fsf@intrepid.localdomain>
References: <1374315339-31469-1-git-send-email-jogo@openwrt.org>
 <1374315339-31469-2-git-send-email-jogo@openwrt.org>
 <m3ip04ezty.fsf@intrepid.localdomain>
Message-ID: <1374424823.2804.25.camel@deadeye.wl.decadent.org.uk>

On Sun, 2013-07-21 at 16:45 +0200, Krzysztof Halasa wrote:
> Jonas Gorski <jogo at openwrt.org> writes:
> 
> > ARM requires the cohorent_dma_mask set, so set it for the platform
> > devices so that the ethernet driver has access to it.
> 
> I recognize the need to fix this issue and I appreciate your efforts,
> but... I think this patch tries to make the driver functional again at
> all costs and this a very bad idea. The IXP4xx Ethernet MACs are not
> normal platform devices, they are in fact built-in CPU resources.

Sounds like a normal platform device to me...

> The
> platform device structs are only used to set parameters. What the patch
> does is unneeded and IMHO harmful code duplication. It makes completely
> no sense to set DMA masks in code for individual platforms as it's not
> something platforms can decide, or *even should know of*. It's simply
> a CPU attribute, a value that is shared by all IXP4xx CPUs and thus all
> platforms and systems using it.
> 
> This is against the "line of code" count rules (or "rules").
> 
> Also the dev->dev.parent is IMHO a bad idea. The queue numbers and MAC
> addresses are in no way "parents" of Ethernet controllers,

Well, those are the platform data.

> and even if
> they somehow were, I find it rather hard to believe they can have DMA
> masks.

I think the problem is that the platform device and the platform data
have not been properly separated.  The machine-specific setup functions
should be passing the eth_plat_info and MAC ID into a common ixp4xx
function which would then create the platform device with the correct
DMA mask etc.

Ben.

> I think the previous patch (which sets the masks in one place, in
> Ethernet driver code) was better, though not perfect.
> 
> My fault is I haven't fixed it yet. Will try to invent something.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.



From linus.walleij at linaro.org  Sun Jul 21 12:49:40 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 21 Jul 2013 18:49:40 +0200
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <51E83A4F.5080904@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <51E83A4F.5080904@ti.com>
Message-ID: <CACRpkdY3nQaWimTwB-Zt-8+Q_KZr8a0rpB1SUQq=AuoG4bAYnQ@mail.gmail.com>

On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon <nm at ti.com> wrote:

> I carry forward my TI internal objection to this approach:

It is actually a very good sign of FOSS-maturity that you as a company
take unresolved architectural issues to the community. Kudos!

> Lets see what happens as a result of this:
>
> https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
> uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
> uart1: serial at 4806a000 {
> <snip>
> +                       interrupts = <0 72 0x4>;
> Assumes that GIC interrupt by default mapping used.

So introducing this inbetween the GIC lines and its actual device IRQ
lines inevitably means that the GIC three-cell concept is completely
ill-devised to handle this.

For routing IRQs, I think the proper solution would be to use a
cascaded struct irqchip, which in turn contains an irqdomain
translation to remux the signal onto the GIC inputs.

I.e. the interrupt-controller given to that serial would be the
crossbar irqchip, and that in turn will hog and allocate apropriate
lines from the gic to it would probably itself list *all* the IRQs
of the GIC as "its" IRQs.

We already have plenty of cascading irqchips such as GPIO
controller providing IRQs, just that they only multiplex on a
single GIC line instead of the whole lot.

Mock example:

                intc: interrupt-controller at 0 {
                        compatible = "arm,cortex-a9-gic";
                        #interrupt-cells = <3>;
                        #address-cells = <1>;
                        interrupt-controller;
                        reg = ...;
                };

                crossbar: crossbar at 0 {
                        compatible = "...";
                        interrupt-controller;
                        #interrupt-cells = <1>;
                        interrupt-parent = <&intc>;
                        interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
                                          <0 1 IRQ_TYPE_LEVEL_HIGH>,
                                          <0 2 IRQ_TYPE_LEVEL_HIGH>,
                                          ....
                                          <0 n IRQ_TYPE_LEVEL_HIGH>;
                };

                uart0: serial at 0 {
                        compatible = "...";
                        interrupt-parent = <&crossbar>;
                        interrupts = <1234>;
                 };

Maybe the interrupts provided from crossbar cannot even be
specified by a number, maybe a line name need to be used
or so. I don't know the particulars.

Whether this as a whole is a good idea, I don't know,
but you would have to go about it something like this.

What happens if there is no line to mux in a certain IRQ?

Yours,
Linus Walleij


From sylvester.nawrocki at gmail.com  Sun Jul 21 13:14:54 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Sun, 21 Jul 2013 19:14:54 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130721154808.GH16598@kroah.com>
References: <20130720220006.GA7977@kroah.com>
 <Pine.LNX.4.44L0.1307202223430.8250-100000@netrider.rowland.org>
 <20130721025910.GA23043@kroah.com> <20130721102248.GE29785@pengutronix.de>
 <20130721154808.GH16598@kroah.com>
Message-ID: <51EC170E.3080201@gmail.com>

On 07/21/2013 05:48 PM, Greg KH wrote:
> On Sun, Jul 21, 2013 at 12:22:48PM +0200, Sascha Hauer wrote:
>> On Sat, Jul 20, 2013 at 07:59:10PM -0700, Greg KH wrote:
>>> On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
>>>> On Sat, 20 Jul 2013, Greg KH wrote:
>>>>
>>>>>>>> That should be passed using platform data.
>>>>>>>
>>>>>>> Ick, don't pass strings around, pass pointers.  If you have platform
>>>>>>> data you can get to, then put the pointer there, don't use a "name".
>>>>>>
>>>>>> I don't think I understood you here :-s We wont have phy pointer
>>>>>> when we create the device for the controller no?(it'll be done in
>>>>>> board file). Probably I'm missing something.
>>>>>
>>>>> Why will you not have that pointer?  You can't rely on the "name" as the
>>>>> device id will not match up, so you should be able to rely on the
>>>>> pointer being in the structure that the board sets up, right?
>>>>>
>>>>> Don't use names, especially as ids can, and will, change, that is going
>>>>> to cause big problems.  Use pointers, this is C, we are supposed to be
>>>>> doing that :)
>>>>
>>>> Kishon, I think what Greg means is this:  The name you are using must
>>>> be stored somewhere in a data structure constructed by the board file,
>>>> right?  Or at least, associated with some data structure somehow.
>>>> Otherwise the platform code wouldn't know which PHY hardware
>>>> corresponded to a particular name.
>>>>
>>>> Greg's suggestion is that you store the address of that data structure
>>>> in the platform data instead of storing the name string.  Have the
>>>> consumer pass the data structure's address when it calls phy_create,
>>>> instead of passing the name.  Then you don't have to worry about two
>>>> PHYs accidentally ending up with the same name or any other similar
>>>> problems.
>>>
>>> Close, but the issue is that whatever returns from phy_create() should
>>> then be used, no need to call any "find" functions, as you can just use
>>> the pointer that phy_create() returns.  Much like all other class api
>>> functions in the kernel work.
>>
>> I think the problem here is to connect two from the bus structure
>> completely independent devices. Several frameworks (ASoC, soc-camera)
>> had this problem and this wasn't solved until the advent of devicetrees
>> and their phandles.
>> phy_create might be called from the probe function of some i2c device
>> (the phy device) and the resulting pointer is then needed in some other
>> platform devices (the user of the phy) probe function.
>> The best solution we have right now is implemented in the clk framework
>> which uses a string matching of the device names in clk_get() (at least
>> in the non-dt case).
>
> I would argue that clocks are wrong here as well, as others have already
> pointed out.
>
> What's wrong with the platform_data structure, why can't that be used
> for this?

At the point the platform data of some driver is initialized, e.g. in
board setup code the PHY pointer is not known, since the PHY supplier
driver has not initialized yet.  Even though we wanted to pass pointer
to a PHY through some notifier call, it would have been not clear
which PHY user driver should match on such notifier.  A single PHY
supplier driver can create M PHY objects and this needs to be mapped
to N PHY user drivers.  This mapping needs to be defined somewhere by
the system integrator.  It works well with device tree, but except that
there seems to be no other reliable infrastructure in the kernel to
define links/dependencies between devices, since device identifiers are
not known in advance in all cases.

What Tomasz proposed seems currently most reasonable to me for non-dt.

> Or, if not, we can always add pointers to the platform device structure,
> or even the main 'struct device' as well, that's what it is there for.

Still we would need to solve a problem which platform device structure
gets which PHY pointer.

--
Regards,
Sylwester


From linus.walleij at linaro.org  Sun Jul 21 13:47:51 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 21 Jul 2013 19:47:51 +0200
Subject: [PATCH v2] pinctrl: elaborate a bit on arrangements in doc
In-Reply-To: <51CCB611.6010709@wwwdotorg.org>
References: <1372326887-6497-1-git-send-email-linus.walleij@stericsson.com>
 <51CCB611.6010709@wwwdotorg.org>
Message-ID: <CACRpkdbdpXd0+OeNmCfFFJX7S2OWJ_k-FZBxMu6UG3mzQZXoEg@mail.gmail.com>

On Fri, Jun 28, 2013 at 12:00 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:

> Otherwise, this patch seems good. Reading this version, it's much more
> obvious to me what the intent of the patch is, for some reason:-)

I left this off the pull request and I have now incorporated all your
comments to a final version.

Sorry for the delay!

Yours,
Linus Walleij


From linus.walleij at linaro.org  Sun Jul 21 13:49:40 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 21 Jul 2013 19:49:40 +0200
Subject: [PATCH v3] pinctrl: elaborate a bit on arrangements in doc
Message-ID: <1374428980-3997-1-git-send-email-linus.walleij@linaro.org>

This elaborates a bit on the pin control and pin muxing
logic vs GPIO arangements in the hardware.

Inspired by some drawings in a mail from Christian Ruppert.
Both arrangements are confirmed to exist in practice.

Cc: Rob Landley <rob at landley.net>
Reviewed-by: Christian Ruppert <christian.ruppert at abilis.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v2->v3:
- Updated with lots of good input and rewording from Stephen
  Warren.
ChangeLog v1->v2:
- Cut down to two arrangements that I *know* exist in reality.
- Reword, rehash, rinse, repeat...
---
 Documentation/pinctrl.txt | 91 +++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 85 insertions(+), 6 deletions(-)

diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index 052e13a..d2d7fc0 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -795,18 +795,97 @@ special GPIO-handler is registered.
 GPIO mode pitfalls
 ==================
 
-Sometime the developer may be confused by a datasheet talking about a pin
-being possible to set into "GPIO mode". It appears that what hardware
-engineers mean with "GPIO mode" is not necessarily the use case that is
-implied in the kernel interface <linux/gpio.h>: a pin that you grab from
-kernel code and then either listen for input or drive high/low to
-assert/deassert some external line.
+Due to the naming conventions used by hardware engineers, where "GPIO"
+is taken to mean different things than what the kernel does, the developer
+may be confused by a datasheet talking about a pin being possible to set
+into "GPIO mode". It appears that what hardware engineers mean with
+"GPIO mode" is not necessarily the use case that is implied in the kernel
+interface <linux/gpio.h>: a pin that you grab from kernel code and then
+either listen for input or drive high/low to assert/deassert some
+external line.
 
 Rather hardware engineers think that "GPIO mode" means that you can
 software-control a few electrical properties of the pin that you would
 not be able to control if the pin was in some other mode, such as muxed in
 for a device.
 
+The GPIO portions of a pin and its relation to a certain pin controller
+configuration and muxing logic can be constructed in several ways. Here
+are two examples:
+
+(A)
+                       pin config
+                       logic regs
+                       |               +- SPI
+     Physical pins --- pad --- pinmux -+- I2C
+                               |       +- mmc
+                               |       +- GPIO
+                               pin
+                               multiplex
+                               logic regs
+
+Here some electrical properties of the pin can be configured no matter
+whether the pin is used for GPIO or not. If you multiplex a GPIO onto a
+pin, you can also drive it high/low from "GPIO" registers.
+Alternatively, the pin can be controlled by a certain peripheral, while
+still applying desired pin config properties. GPIO functionality is thus
+orthogonal to any other device using the pin.
+
+In this arrangement the registers for the GPIO portions of the pin controller,
+or the registers for the GPIO hardware module are likely to reside in a
+separate memory range only intended for GPIO driving, and the register
+range dealing with pin config and pin multiplexing get placed into a
+different memory range and a separate section of the data sheet.
+
+(B)
+
+                       pin config
+                       logic regs
+                       |               +- SPI
+     Physical pins --- pad --- pinmux -+- I2C
+                       |       |       +- mmc
+                       |       |
+                       GPIO    pin
+                               multiplex
+                               logic regs
+
+In this arrangement, the GPIO functionality can always be enabled, such that
+e.g. a GPIO input can be used to "spy" on the SPI/I2C/MMC signal while it is
+pulsed out. It is likely possible to disrupt the traffic on the pin by doing
+wrong things on the GPIO block, as it is never really disconnected. It is
+possible that the GPIO, pin config and pin multiplex registers are placed into
+the same memory range and the same section of the data sheet, although that
+need not be the case.
+
+From a kernel point of view, however, these are different aspects of the
+hardware and shall be put into different subsystems:
+
+- Registers (or fields within registers) that control electrical
+  properties of the pin such as biasing and drive strength should be
+  exposed through the pinctrl subsystem, as "pin configuration" settings.
+
+- Registers (or fields within registers) that control muxing of signals
+  from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should
+  be exposed through the pinctrl subssytem, as mux functions.
+
+- Registers (or fields within registers) that control GPIO functionality
+  such as setting a GPIO's output value, reading a GPIO's input value, or
+  setting GPIO pin direction should be exposed through the GPIO subsystem,
+  and if they also support interrupt capabilities, through the irqchip
+  abstraction.
+
+Depending on the exact HW register design, some functions exposed by the
+GPIO subsystem may call into the pinctrl subsystem in order to
+co-ordinate register settings across HW modules. In particular, this may
+be needed for HW with separate GPIO and pin controller HW modules, where
+e.g. GPIO direction is determined by a register in the pin controller HW
+module rather than the GPIO HW module.
+
+Electrical properties of the pin such as biasing and drive strength
+may be placed at some pin-specific register in all cases or as part
+of the GPIO register in case (B) especially. This doesn't mean that such
+properties necessarily pertain to what the Linux kernel calls "GPIO".
+
 Example: a pin is usually muxed in to be used as a UART TX line. But during
 system sleep, we need to put this pin into "GPIO mode" and ground it.
 
-- 
1.8.1.4



From s.hauer at pengutronix.de  Sun Jul 21 14:50:23 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Sun, 21 Jul 2013 20:50:23 +0200
Subject: [PATCH 1/6] ARM: dts: i.MX27: Using "wdog_ipg_gate" clock
 source for watchdog
In-Reply-To: <1374304679-27338-1-git-send-email-shc_work@mail.ru>
References: <1374304679-27338-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130721185023.GM29785@pengutronix.de>

On Sat, Jul 20, 2013 at 11:17:54AM +0400, Alexander Shiyan wrote:
> Patch replaces "dummy" clock source for watchdog with "wdog_ipg_gate".
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>

The series looks good to me.

Acked-by: Sascha Hauer <s.hauer at pengutronix.de>

Sascha

> ---
>  arch/arm/boot/dts/imx27.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
> index 56b8c97..e9d60ab 100644
> --- a/arch/arm/boot/dts/imx27.dtsi
> +++ b/arch/arm/boot/dts/imx27.dtsi
> @@ -96,7 +96,7 @@
>  				compatible = "fsl,imx27-wdt", "fsl,imx21-wdt";
>  				reg = <0x10002000 0x1000>;
>  				interrupts = <27>;
> -				clocks = <&clks 0>;
> +				clocks = <&clks 74>;
>  			};
>  
>  			gpt1: timer at 10003000 {
> -- 
> 1.8.1.5
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From stern at rowland.harvard.edu  Sun Jul 21 15:22:21 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Sun, 21 Jul 2013 15:22:21 -0400 (EDT)
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51EC170E.3080201@gmail.com>
Message-ID: <Pine.LNX.4.44L0.1307211453450.19133-100000@netrider.rowland.org>

On Sun, 21 Jul 2013, Sylwester Nawrocki wrote:

> > What's wrong with the platform_data structure, why can't that be used
> > for this?
> 
> At the point the platform data of some driver is initialized, e.g. in
> board setup code the PHY pointer is not known, since the PHY supplier
> driver has not initialized yet.  Even though we wanted to pass pointer
> to a PHY through some notifier call, it would have been not clear
> which PHY user driver should match on such notifier.  A single PHY
> supplier driver can create M PHY objects and this needs to be mapped
> to N PHY user drivers.  This mapping needs to be defined somewhere by
> the system integrator.  It works well with device tree, but except that
> there seems to be no other reliable infrastructure in the kernel to
> define links/dependencies between devices, since device identifiers are
> not known in advance in all cases.
> 
> What Tomasz proposed seems currently most reasonable to me for non-dt.
> 
> > Or, if not, we can always add pointers to the platform device structure,
> > or even the main 'struct device' as well, that's what it is there for.
> 
> Still we would need to solve a problem which platform device structure
> gets which PHY pointer.

Can you explain the issues in more detail?  I don't fully understand 
the situation.

Here's what I think I know:

	The PHY and the controller it is attached to are both physical
	devices.

	The connection between them is hardwired by the system
	manufacturer and cannot be changed by software.

	PHYs are generally described by fixed system-specific board
	files or by Device Tree information.  Are they ever discovered
	dynamically?

	Is the same true for the controllers attached to the PHYs?
	If not -- if both a PHY and a controller are discovered 
	dynamically -- how does the kernel know whether they are 
	connected to each other?

	The kernel needs to know which controller is attached to which
	PHY.  Currently this information is represented by name or ID
	strings embedded in platform data.

	The PHY's driver (the supplier) uses the platform data to 
	construct a platform_device structure that represents the PHY.  
	Until this is done, the controller's driver (the client) cannot 
	use the PHY.

	Since there is no parent-child relation between the PHY and the 
	controller, there is no guarantee that the PHY's driver will be
	ready when the controller's driver wants to use it.  A deferred
	probe may be needed.

	The issue (or one of the issues) in this discussion is that 
	Greg does not like the idea of using names or IDs to associate
	PHYs with controllers, because they are too prone to
	duplications or other errors.  Pointers are more reliable.

	But pointers to what?  Since the only data known to be 
	available to both the PHY driver and controller driver is the
	platform data, the obvious answer is a pointer to platform data
	(either for the PHY or for the controller, or maybe both).

Probably some of the details above are wrong; please indicate where I
have gone astray.  Also, I'm not clear about the role played by various 
APIs.  For example, where does phy_create() fit into this picture?

Alan Stern



From sylvester.nawrocki at gmail.com  Sun Jul 21 15:42:45 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Sun, 21 Jul 2013 21:42:45 +0200
Subject: [PATCH] ARM: S3C24XX: Add missing clkdev entries for s3c2440 UART
Message-ID: <1374435765-6747-1-git-send-email-sylvester.nawrocki@gmail.com>

This patch restores serial port operation which has been broken since
commit 60e93575476f90a72146b51283f514da655410a7
serial: samsung: enable clock before clearing pending interrupts during init

That commit only uncovered the real issue which was missing clkdev
entries for the "uart" clocks on S3C2440. It went unnoticed so far
because return value of clk API calls were not being checked at all
in the samsung serial port driver.

This patch should be backported to at least 3.10 stable kernel, since
the serial port has not been working on s3c2440 since 3.10-rc5.

Cc: Chander Kashyap <chander.kashyap at linaro.org>
Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
[on S3C2440 SoC based Mini2440 board]
Tested-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
---

There seems to be something wrong with the process, as things are
getting broken late in the -rc cycle.  It seems author of the above
mentioned commit didn't test all 6 SoC series that the samsung
serial driver handles.  While I can understand they might not have
all required hardware it's a bit irritating that the patch that
in practice caused regression appeared only on linux-serial mailing
list. And it's not evident it was even tried to test it on all
potentially affected platforms. It not clear on what platforms
the patch has been tested.

My humble suggestion is, _please_ do send patches that affect multiple
Samsung SoCs to linux-samsung at vger.kernel.org.  So there is better
review and test exposure.  And we can reduce mess like this happening
in the future.

Thanks!
Sylwester
---
 arch/arm/mach-s3c24xx/clock-s3c2410.c      |  161 +++++++++++++++++-----------
 arch/arm/mach-s3c24xx/clock-s3c2440.c      |    3 +
 arch/arm/plat-samsung/include/plat/clock.h |    5 +
 3 files changed, 106 insertions(+), 63 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/clock-s3c2410.c b/arch/arm/mach-s3c24xx/clock-s3c2410.c
index afa0267..d39d3c7 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2410.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2410.c
@@ -119,66 +119,101 @@ static struct clk init_clocks_off[] = {
 	}
 };
 
-static struct clk init_clocks[] = {
-	{
-		.name		= "lcd",
-		.parent		= &clk_h,
-		.enable		= s3c2410_clkcon_enable,
-		.ctrlbit	= S3C2410_CLKCON_LCDC,
-	}, {
-		.name		= "gpio",
-		.parent		= &clk_p,
-		.enable		= s3c2410_clkcon_enable,
-		.ctrlbit	= S3C2410_CLKCON_GPIO,
-	}, {
-		.name		= "usb-host",
-		.parent		= &clk_h,
-		.enable		= s3c2410_clkcon_enable,
-		.ctrlbit	= S3C2410_CLKCON_USBH,
-	}, {
-		.name		= "usb-device",
-		.parent		= &clk_h,
-		.enable		= s3c2410_clkcon_enable,
-		.ctrlbit	= S3C2410_CLKCON_USBD,
-	}, {
-		.name		= "timers",
-		.parent		= &clk_p,
-		.enable		= s3c2410_clkcon_enable,
-		.ctrlbit	= S3C2410_CLKCON_PWMT,
-	}, {
-		.name		= "uart",
-		.devname	= "s3c2410-uart.0",
-		.parent		= &clk_p,
-		.enable		= s3c2410_clkcon_enable,
-		.ctrlbit	= S3C2410_CLKCON_UART0,
-	}, {
-		.name		= "uart",
-		.devname	= "s3c2410-uart.1",
-		.parent		= &clk_p,
-		.enable		= s3c2410_clkcon_enable,
-		.ctrlbit	= S3C2410_CLKCON_UART1,
-	}, {
-		.name		= "uart",
-		.devname	= "s3c2410-uart.2",
-		.parent		= &clk_p,
-		.enable		= s3c2410_clkcon_enable,
-		.ctrlbit	= S3C2410_CLKCON_UART2,
-	}, {
-		.name		= "rtc",
-		.parent		= &clk_p,
-		.enable		= s3c2410_clkcon_enable,
-		.ctrlbit	= S3C2410_CLKCON_RTC,
-	}, {
-		.name		= "watchdog",
-		.parent		= &clk_p,
-		.ctrlbit	= 0,
-	}, {
-		.name		= "usb-bus-host",
-		.parent		= &clk_usb_bus,
-	}, {
-		.name		= "usb-bus-gadget",
-		.parent		= &clk_usb_bus,
-	},
+static struct clk clk_lcd = {
+	.name		= "lcd",
+	.parent		= &clk_h,
+	.enable		= s3c2410_clkcon_enable,
+	.ctrlbit	= S3C2410_CLKCON_LCDC,
+};
+
+static struct clk clk_gpio = {
+	.name		= "gpio",
+	.parent		= &clk_p,
+	.enable		= s3c2410_clkcon_enable,
+	.ctrlbit	= S3C2410_CLKCON_GPIO,
+};
+
+static struct clk clk_usb_host = {
+	.name		= "usb-host",
+	.parent		= &clk_h,
+	.enable		= s3c2410_clkcon_enable,
+	.ctrlbit	= S3C2410_CLKCON_USBH,
+};
+
+static struct clk clk_usb_device = {
+	.name		= "usb-device",
+	.parent		= &clk_h,
+	.enable		= s3c2410_clkcon_enable,
+	.ctrlbit	= S3C2410_CLKCON_USBD,
+};
+
+static struct clk clk_timers = {
+	.name		= "timers",
+	.parent		= &clk_p,
+	.enable		= s3c2410_clkcon_enable,
+	.ctrlbit	= S3C2410_CLKCON_PWMT,
+};
+
+struct clk s3c24xx_clk_uart0 = {
+	.name		= "uart",
+	.devname	= "s3c2410-uart.0",
+	.parent		= &clk_p,
+	.enable		= s3c2410_clkcon_enable,
+	.ctrlbit	= S3C2410_CLKCON_UART0,
+};
+
+struct clk s3c24xx_clk_uart1 = {
+	.name		= "uart",
+	.devname	= "s3c2410-uart.1",
+	.parent		= &clk_p,
+	.enable		= s3c2410_clkcon_enable,
+	.ctrlbit	= S3C2410_CLKCON_UART1,
+};
+
+struct clk s3c24xx_clk_uart2 = {
+	.name		= "uart",
+	.devname	= "s3c2410-uart.2",
+	.parent		= &clk_p,
+	.enable		= s3c2410_clkcon_enable,
+	.ctrlbit	= S3C2410_CLKCON_UART2,
+};
+
+static struct clk clk_rtc = {
+	.name		= "rtc",
+	.parent		= &clk_p,
+	.enable		= s3c2410_clkcon_enable,
+	.ctrlbit	= S3C2410_CLKCON_RTC,
+};
+
+static struct clk clk_watchdog = {
+	.name		= "watchdog",
+	.parent		= &clk_p,
+	.ctrlbit	= 0,
+};
+
+static struct clk clk_usb_bus_host = {
+	.name		= "usb-bus-host",
+	.parent		= &clk_usb_bus,
+};
+
+static struct clk clk_usb_bus_gadget = {
+	.name		= "usb-bus-gadget",
+	.parent		= &clk_usb_bus,
+};
+
+static struct clk *init_clocks[] = {
+	&clk_lcd,
+	&clk_gpio,
+	&clk_usb_host,
+	&clk_usb_device,
+	&clk_timers,
+	&s3c24xx_clk_uart0,
+	&s3c24xx_clk_uart1,
+	&s3c24xx_clk_uart2,
+	&clk_rtc,
+	&clk_watchdog,
+	&clk_usb_bus_host,
+	&clk_usb_bus_gadget,
 };
 
 /* s3c2410_baseclk_add()
@@ -195,7 +230,6 @@ int __init s3c2410_baseclk_add(void)
 {
 	unsigned long clkslow = __raw_readl(S3C2410_CLKSLOW);
 	unsigned long clkcon  = __raw_readl(S3C2410_CLKCON);
-	struct clk *clkp;
 	struct clk *xtal;
 	int ret;
 	int ptr;
@@ -207,8 +241,9 @@ int __init s3c2410_baseclk_add(void)
 
 	/* register clocks from clock array */
 
-	clkp = init_clocks;
-	for (ptr = 0; ptr < ARRAY_SIZE(init_clocks); ptr++, clkp++) {
+	for (ptr = 0; ptr < ARRAY_SIZE(init_clocks); ptr++) {
+		struct clk *clkp = init_clocks[ptr];
+
 		/* ensure that we note the clock state */
 
 		clkp->usage = clkcon & clkp->ctrlbit ? 1 : 0;
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2440.c b/arch/arm/mach-s3c24xx/clock-s3c2440.c
index 1069b56..aaf006d 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2440.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2440.c
@@ -166,6 +166,9 @@ static struct clk_lookup s3c2440_clk_lookup[] = {
 	CLKDEV_INIT(NULL, "clk_uart_baud1", &s3c24xx_uclk),
 	CLKDEV_INIT(NULL, "clk_uart_baud2", &clk_p),
 	CLKDEV_INIT(NULL, "clk_uart_baud3", &s3c2440_clk_fclk_n),
+	CLKDEV_INIT("s3c2440-uart.0", "uart", &s3c24xx_clk_uart0),
+	CLKDEV_INIT("s3c2440-uart.1", "uart", &s3c24xx_clk_uart1),
+	CLKDEV_INIT("s3c2440-uart.2", "uart", &s3c24xx_clk_uart2),
 	CLKDEV_INIT("s3c2440-camif", "camera", &s3c2440_clk_cam_upll),
 };
 
diff --git a/arch/arm/plat-samsung/include/plat/clock.h b/arch/arm/plat-samsung/include/plat/clock.h
index 254c3dd..63239f4 100644
--- a/arch/arm/plat-samsung/include/plat/clock.h
+++ b/arch/arm/plat-samsung/include/plat/clock.h
@@ -83,6 +83,11 @@ extern struct clk clk_ext;
 extern struct clksrc_clk clk_epllref;
 extern struct clksrc_clk clk_esysclk;
 
+/* S3C24XX UART clocks */
+extern struct clk s3c24xx_clk_uart0;
+extern struct clk s3c24xx_clk_uart1;
+extern struct clk s3c24xx_clk_uart2;
+
 /* S3C64XX specific clocks */
 extern struct clk clk_h2;
 extern struct clk clk_27m;
-- 
1.7.4.1



From sylvester.nawrocki at gmail.com  Sun Jul 21 15:46:09 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Sun, 21 Jul 2013 21:46:09 +0200
Subject: [PATCH v4 07/20] ARM: SAMSUNG: Add new PWM platform device
In-Reply-To: <1374278673-25615-9-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-9-git-send-email-tomasz.figa@gmail.com>
Message-ID: <51EC3A81.7050001@gmail.com>

Hi Tomasz,

On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> This patch adds new samsung_device_pwm platform device that represents
> the whole PWM/timer block and includes memory and IRQ resources.
>
> Signed-off-by: Tomasz Figa<tomasz.figa at gmail.com>
> ---
>   arch/arm/plat-samsung/devs.c                  | 17 +++++++++++++++++
>   arch/arm/plat-samsung/include/plat/devs.h     |  1 +
>   arch/arm/plat-samsung/include/plat/pwm-core.h | 24 ++++++++++++++++++++++++
>   3 files changed, 42 insertions(+)
>   create mode 100644 arch/arm/plat-samsung/include/plat/pwm-core.h
>
> diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
> index 0f9c3f4..bba6d78 100644
> --- a/arch/arm/plat-samsung/devs.c
> +++ b/arch/arm/plat-samsung/devs.c
> @@ -58,6 +58,7 @@
>   #include<plat/keypad.h>
>   #include<linux/platform_data/mmc-s3cmci.h>
>   #include<linux/platform_data/mtd-nand-s3c2410.h>
> +#include<plat/pwm-core.h>
>   #include<plat/sdhci.h>
>   #include<linux/platform_data/touchscreen-s3c2410.h>
>   #include<linux/platform_data/usb-s3c2410_udc.h>
> @@ -1127,6 +1128,22 @@ struct platform_device s3c_device_timer[] = {
>   	[3] = { DEFINE_S3C_TIMER(3, IRQ_TIMER3) },
>   	[4] = { DEFINE_S3C_TIMER(4, IRQ_TIMER4) },
>   };
> +
> +static struct resource samsung_pwm_resource[] = {
> +	DEFINE_RES_MEM(SAMSUNG_PA_TIMER, SZ_4K),
> +};
> +
> +struct platform_device samsung_device_pwm = {
> +	.name		= "samsung-pwm",
> +	.id		= -1,
> +	.num_resources	= ARRAY_SIZE(samsung_pwm_resource),
> +	.resource	= samsung_pwm_resource,
> +};
> +
> +void __init samsung_pwm_set_platdata(struct samsung_pwm_variant *pd)
> +{
> +	samsung_device_pwm.dev.platform_data = pd;
> +}
>   #endif /* CONFIG_SAMSUNG_DEV_PWM */
>
>   /* RTC */
> diff --git a/arch/arm/plat-samsung/include/plat/devs.h b/arch/arm/plat-samsung/include/plat/devs.h
> index 87d501f..0dc4ac4 100644
> --- a/arch/arm/plat-samsung/include/plat/devs.h
> +++ b/arch/arm/plat-samsung/include/plat/devs.h
> @@ -134,6 +134,7 @@ extern struct platform_device exynos4_device_spdif;
>
>   extern struct platform_device samsung_asoc_idma;
>   extern struct platform_device samsung_device_keypad;
> +extern struct platform_device samsung_device_pwm;
>
>   /* s3c2440 specific devices */
>
> diff --git a/arch/arm/plat-samsung/include/plat/pwm-core.h b/arch/arm/plat-samsung/include/plat/pwm-core.h
> new file mode 100644
> index 0000000..df50f5c
> --- /dev/null
> +++ b/arch/arm/plat-samsung/include/plat/pwm-core.h
> @@ -0,0 +1,24 @@
> +/*
> + * linux/arch/arm/plat-samsung/onenand-core.h

Are such full file path names really useful, especially we are never
sure they are up to date ? I guess this line could be removed.

> + *  Copyright (c) 2013 Tomasz Figa<tomasz.figa at gmail.com>
> + *
> + * Samsung PWM Controller core functions
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#ifndef __ASM_ARCH_PWM_CORE_H
> +#define __ASM_ARCH_PWM_CORE_H __FILE__
> +
> +#include<clocksource/samsung_pwm.h>
> +
> +#ifdef CONFIG_SAMSUNG_DEV_PWM
> +extern void samsung_pwm_set_platdata(struct samsung_pwm_variant *pd);

nit: 'extern' is implicit for function declarations, it could be omitted 
here.

> +#else
> +static inline void samsung_pwm_set_platdata(struct samsung_pwm_variant *pd) { }
> +#endif
> +
> +#endif /* __ASM_ARCH_PWM_CORE_H */

Thanks,
Sylwester


From sylvester.nawrocki at gmail.com  Sun Jul 21 15:50:47 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Sun, 21 Jul 2013 21:50:47 +0200
Subject: [PATCH v4 13/20] pwm: Add new pwm-samsung driver
In-Reply-To: <1374278673-25615-15-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-15-git-send-email-tomasz.figa@gmail.com>
Message-ID: <51EC3B97.3040107@gmail.com>

On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> This patch introduces new Samsung PWM driver, which uses Samsung
> PWM/timer master driver to control shared parts of the hardware.
>
> Signed-off-by: Tomasz Figa<tomasz.figa at gmail.com>
> ---
>   drivers/pwm/Makefile      |   1 +
>   drivers/pwm/pwm-samsung.c | 606 ++++++++++++++++++++++++++++++++++++++++++++++
>   2 files changed, 607 insertions(+)
>   create mode 100644 drivers/pwm/pwm-samsung.c
[...]
> +static const struct samsung_pwm_variant s3c64xx_variant = {
> +	.bits		= 32,
> +	.div_base	= 0,

Initialization to 0 could be omitted, since it is implicit.

> +	.has_tint_cstat	= true,
> +	.tclk_mask	= BIT(7) | BIT(6) | BIT(5),
> +};
> +
> +static const struct samsung_pwm_variant s5p64x0_variant = {
> +	.bits		= 32,
> +	.div_base	= 0,

Ditto.

> +	.has_tint_cstat	= true,
> +};
> +
> +static const struct samsung_pwm_variant s5p_variant = {
> +	.bits		= 32,
> +	.div_base	= 0,

Ditto.

> +	.has_tint_cstat	= true,
> +	.tclk_mask	= BIT(5),
> +};
> +
[...]
> +static int pwm_samsung_remove(struct platform_device *pdev)
> +{
> +	struct samsung_pwm_chip *chip = platform_get_drvdata(pdev);
> +	int ret;
> +
> +	ret = pwmchip_remove(&chip->chip);
> +	if (ret<  0)
> +		return ret;

Since return value of the remove() callback is happily ignored by
the driver core I think there is no point in returning an error
here like this. Wouldn't it be more sensible to just call all the
cleanup functions unconditionally ? At least potentially wrong state
of the clock could be avoided.

> +
> +	clk_disable_unprepare(chip->base_clk);
> +
> +	return 0;
> +}

--
Regards,
Sylwester


From robherring2 at gmail.com  Sun Jul 21 15:53:37 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Sun, 21 Jul 2013 14:53:37 -0500
Subject: [PATCH] ARM: highbank: Only touch common coherency control register
 fields
Message-ID: <1374436417-29761-1-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Midway adds new register fields to the coherency control registers, so
writing absolute values will break on Midway. Change the register
accesses to only modify the necessary and common fields in order to
support both Midway and Highbank.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/mach-highbank/highbank.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
index dc5d6be..8881579 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -115,6 +115,7 @@ static int highbank_platform_notifier(struct notifier_block *nb,
 {
 	struct resource *res;
 	int reg = -1;
+	u32 val;
 	struct device *dev = __dev;
 
 	if (event != BUS_NOTIFY_ADD_DEVICE)
@@ -141,10 +142,10 @@ static int highbank_platform_notifier(struct notifier_block *nb,
 		return NOTIFY_DONE;
 
 	if (of_property_read_bool(dev->of_node, "dma-coherent")) {
-		writel(0xff31, sregs_base + reg);
+		val = readl(sregs_base + reg);
+		writel(val | 0xff01, sregs_base + reg);
 		set_dma_ops(dev, &arm_coherent_dma_ops);
-	} else
-		writel(0, sregs_base + reg);
+	}
 
 	return NOTIFY_OK;
 }
-- 
1.8.1.2



From sergei.shtylyov at cogentembedded.com  Sun Jul 21 16:39:29 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 22 Jul 2013 00:39:29 +0400
Subject: [PATCH] xen/arm and xen/arm64: update xen_restart after
 ff701306cd49
In-Reply-To: <1374420257-19467-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1374420257-19467-1-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <51EC4701.8020502@cogentembedded.com>

Hello.

On 21-07-2013 19:24, Stefano Stabellini wrote:

> Commit ff701306cd49 changes the prototype of arm_pm_restart.

    Please also specify the summary line of that commit in parens.

> Update xen_restart accordingly.

> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>

WBR, Sergei



From robherring2 at gmail.com  Sun Jul 21 16:45:13 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Sun, 21 Jul 2013 15:45:13 -0500
Subject: [PATCH] of: match the compatible in the order set by the dts file
In-Reply-To: <20130720054439.308B33E13F0@localhost>
References: <1373013818-11365-1-git-send-email-b32955@freescale.com>
 <20130709070541.GQ516@pengutronix.de> <51DBBFDA.70302@freescale.com>
 <20130709075124.GR516@pengutronix.de> <51DBC58D.90002@freescale.com>
 <20130720054439.308B33E13F0@localhost>
Message-ID: <51EC4859.5000007@gmail.com>

On Sat, Jul 20, 2013 at 12:44 AM, Grant Likely <grant.likely at linaro.org>
wrote:
> On Tue, 9 Jul 2013 16:10:53 +0800, Huang Shijie <b32955 at freescale.com> wrote:
>> ? 2013?07?09? 15:51, Sascha Hauer ??:
>> > On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
>> >> ? 2013?07?09? 15:05, Sascha Hauer ??:
>> >>> Why don't you set the matching order in the driver the way you want it
>> >>> to be, i.e.:
>> >>>
>> >>>   { .compatible = "fsl,imx6q-uart", ... },
>> >>>   { .compatible = "fsl,imx21-uart", ... },
>> >>>   { .compatible = "fsl,imx1-uart", ... },
>> >>>
>> >> yes. i can set it like this.
>> >>
>> >> but this method looks like a ugly workaround.
>> > If a driver has different ways of supporting a single device, then
>> > putting the preferred or most feature rich on top doesn't look very ugly
>> > to me.
>> this method makes it much _coupled_ between the driver and the dts file.
>>
>> IMHO, it's an unnecessary _burden_ to the driver programmer:
>>     he should puts the most feature compatible on the top.
>>
>> it's much graceful if we let the driver programmer be transparent about
>> this.
>
> Absolutely true. Applied, thanks.

We can debate whether the driver order matters or not, but either way
I'm not sure this patch does the right thing. It doesn't really look
correct to me, but I haven't dug into it.

We've already tried to fix matching and reverted the fix once before
(commit below). So this patch needs careful review and thought about
cases where the name and/or type is used to match.

commit bc51b0c22cebf5c311a6f1895fcca9f78efd0478
Author: Linus Torvalds <torvalds at linux-foundation.org>
Date:   Tue Jul 10 12:49:32 2012 -0700

    Revert "of: match by compatible property first"

    This reverts commit 107a84e61cdd3406c842a0e4be7efffd3a05dba6.

    Meelis Roos reports a regression since 3.5-rc5 that stops Sun Fire V100
    and Sun Netra X1 sparc64 machines from booting, hanging after enabling
    serial console.  He bisected it to commit 107a84e61cdd.

    Rob Herring explains:
     "The problem is match combinations of compatible plus name and/or type
      fail to match correctly.  I have a fix for this, but given how late it
      is for 3.5 I think it is best to revert this for now.  There could be
      other cases that rely on the current although wrong behavior.  I will
      post an updated version for 3.6."

    Bisected-and-reported-by: Meelis Roos <mroos at linux.ee>
    Requested-by: Rob Herring <rob.herring at calxeda.com>
    Cc: Thierry Reding <thierry.reding at avionic-design.de>
    Cc: Grant Likely <grant.likely at secretlab.ca>
    Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>


Rob


From julien.grall at linaro.org  Sun Jul 21 16:59:22 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Sun, 21 Jul 2013 21:59:22 +0100
Subject: [PATCH v2] xen/arm: enable PV control for ARM
In-Reply-To: <alpine.DEB.2.02.1307211535210.4893@kaball.uk.xensource.com>
References: <1374239399-2498-1-git-send-email-julien.grall@linaro.org>
 <alpine.DEB.2.02.1307211535210.4893@kaball.uk.xensource.com>
Message-ID: <CAPnVf8yG4VecBkk8py_cyOiFkFMqiLYydicKcM2PgYYm+gKd8w@mail.gmail.com>

On 21 July 2013 15:54, Stefano Stabellini
<stefano.stabellini at eu.citrix.com> wrote:
> On Fri, 19 Jul 2013, Julien Grall wrote:
>> Enable power management from the toolstack for ARM guest.
>>
>> Signed-off-by: Julien Grall <julien.grall at linaro.org>
>>
>> ---
>>     Changes in v2:
>>         - Don't compile xen/cpu_hotplug.o with ARM64
>> ---
>>  drivers/xen/Makefile |    5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
>> index 2bf461a..b550a94 100644
>> --- a/drivers/xen/Makefile
>> +++ b/drivers/xen/Makefile
>> @@ -1,9 +1,8 @@
>> -ifneq ($(CONFIG_ARM),y)
>> -obj-y        += manage.o
>> +ifneq ($(filter y, ($CONFIG_ARM) $(CONFIG_ARM64)),y
>
> This is wrong: ifneq is checking for the opposite condition of what we want, and
> beside you have the $ in the wrong place for CONFIG_ARM.
>
> Please test you patches before sending them.

My apologies, I tried without any issue on ARM (certainly, because of
the $ in wrong place).

I will send a new patch.

--
Julien Grall


From will.deacon at arm.com  Sun Jul 21 17:37:53 2013
From: will.deacon at arm.com (Will Deacon)
Date: Sun, 21 Jul 2013 22:37:53 +0100
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y
In-Reply-To: <20130720044655.GC9433@mozilla.com>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
 <20130715135420.GG10000@mudshark.cambridge.arm.com>
 <20130720044655.GC9433@mozilla.com>
Message-ID: <20130721213753.GA29879@mudshark.cambridge.arm.com>

Hello Jed,

Thanks for the reply.

On Sat, Jul 20, 2013 at 05:46:55AM +0100, Jed Davis wrote:
> On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> > On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> [...]
> > > Effects of this are probably limited to failure of EHABI unwinding when
> > > starting from a function that uses r7 to restore its stack pointer, but
> > > the possibility for further breakage (which would be invisible on
> > > non-Thumb kernels) is worrying.
> [...]
> > I'm struggling to understand exactly the problem that this patch is trying
> > to address. If it's just a code consistency issue, I don't think it's worth
> > it (I actually find it less confusing the way we currently have things) but
> > if there is a real bug, perhaps you could provide a testcase?
> 
> There is a real bug here, but my commit message wasn't very clear.  This
> was breaking PERF_COUNT_SW_CONTEXT_SWITCHES with CONFIG_THUMB2_KERNEL=y
> (with my other recently posted patch applied), because kernel/sched.c is
> built with -fno-omit-frame-pointer (which is wrong, but that's a problem
> for another patch) and so __schedule's EHABI entry uses 0x97 (mov sp, r7),
> and somewhere along the line the unwinder gets the r11 value instead.
> This would also apply to any function with a variable-length array, but
> __schedule happens to have the perf hook I was trying to use.

Ok, I think I'm with you now. I also think that a better solution would be
to try and limit the r7/fp confusion to one place, perhaps behind something
like:

void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);

then that function can act as the bridge between pt_regs (where we leave
everything as it is) and stackframe (where we assign either r7 or fp into
the fp member). Then we just fix up the call sites to pass the regs they're
interested in to our new function.

What do you think?

Will


From will.deacon at arm.com  Sun Jul 21 17:39:37 2013
From: will.deacon at arm.com (Will Deacon)
Date: Sun, 21 Jul 2013 22:39:37 +0100
Subject: [PATCH] ARM: perf: Implement perf_arch_fetch_caller_regs
In-Reply-To: <20130720034321.GB9433@mozilla.com>
References: <1373685434-1581-1-git-send-email-jld@mozilla.com>
 <20130715135342.GF10000@mudshark.cambridge.arm.com>
 <20130720034321.GB9433@mozilla.com>
Message-ID: <20130721213937.GB29879@mudshark.cambridge.arm.com>

On Sat, Jul 20, 2013 at 04:43:21AM +0100, Jed Davis wrote:
> On Mon, Jul 15, 2013 at 02:53:42PM +0100, Will Deacon wrote:
> > > +				     "mov %[_pc],  r15\n\t"		\
> > > +				     "mrs %[_cpsr], cpsr\n\t"		\
> > > +				     : [_cpsr] "=r" (_cpsr),		\
> > > +				       [_pc] "=r" (_pc)			\
> > > +				     : [_regs] "r" (&(regs)->uregs)	\
> > 
> > It would be cleaner to pass a separate argument for each register, using the
> > ARM_rN macros rather than calculating the offset by hand.
> 
> I'll do that.  If there were more arguments there might be a problem
> at -O0, because the naive translation can run out of registers in
> some cases, but that shouldn't be a problem here.  (Nor if someone
> later extends this to all the core registers, because {r0-r13} can and
> presumably should use a store-multiple.)

We already rely on compiler optimisation for things like tlbflush.h, so we
don't need to worry about building with -O0.

Please send a v2 when you get a chance!

Will


From tomasz.figa at gmail.com  Sun Jul 21 17:51:24 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sun, 21 Jul 2013 23:51:24 +0200
Subject: [PATCH v4 07/20] ARM: SAMSUNG: Add new PWM platform device
In-Reply-To: <51EC3A81.7050001@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-9-git-send-email-tomasz.figa@gmail.com>
 <51EC3A81.7050001@gmail.com>
Message-ID: <3579759.6nJBcZTDZ4@flatron>

Hi Sylwester,

On Sunday 21 of July 2013 21:46:09 Sylwester Nawrocki wrote:
> Hi Tomasz,
> 
> On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> > This patch adds new samsung_device_pwm platform device that represents
> > the whole PWM/timer block and includes memory and IRQ resources.
> > 
> > Signed-off-by: Tomasz Figa<tomasz.figa at gmail.com>
> > ---
> > 
> >   arch/arm/plat-samsung/devs.c                  | 17 +++++++++++++++++
> >   arch/arm/plat-samsung/include/plat/devs.h     |  1 +
> >   arch/arm/plat-samsung/include/plat/pwm-core.h | 24
> >   ++++++++++++++++++++++++ 3 files changed, 42 insertions(+)
> >   create mode 100644 arch/arm/plat-samsung/include/plat/pwm-core.h
> > 
> > diff --git a/arch/arm/plat-samsung/devs.c
> > b/arch/arm/plat-samsung/devs.c index 0f9c3f4..bba6d78 100644
> > --- a/arch/arm/plat-samsung/devs.c
> > +++ b/arch/arm/plat-samsung/devs.c
> > @@ -58,6 +58,7 @@
> > 
> >   #include<plat/keypad.h>
> >   #include<linux/platform_data/mmc-s3cmci.h>
> >   #include<linux/platform_data/mtd-nand-s3c2410.h>
> > 
> > +#include<plat/pwm-core.h>
> > 
> >   #include<plat/sdhci.h>
> >   #include<linux/platform_data/touchscreen-s3c2410.h>
> >   #include<linux/platform_data/usb-s3c2410_udc.h>
> > 
> > @@ -1127,6 +1128,22 @@ struct platform_device s3c_device_timer[] = {
> > 
> >   	[3] = { DEFINE_S3C_TIMER(3, IRQ_TIMER3) },
> >   	[4] = { DEFINE_S3C_TIMER(4, IRQ_TIMER4) },
> >   
> >   };
> > 
> > +
> > +static struct resource samsung_pwm_resource[] = {
> > +	DEFINE_RES_MEM(SAMSUNG_PA_TIMER, SZ_4K),
> > +};
> > +
> > +struct platform_device samsung_device_pwm = {
> > +	.name		= "samsung-pwm",
> > +	.id		= -1,
> > +	.num_resources	= ARRAY_SIZE(samsung_pwm_resource),
> > +	.resource	= samsung_pwm_resource,
> > +};
> > +
> > +void __init samsung_pwm_set_platdata(struct samsung_pwm_variant *pd)
> > +{
> > +	samsung_device_pwm.dev.platform_data = pd;
> > +}
> > 
> >   #endif /* CONFIG_SAMSUNG_DEV_PWM */
> >   
> >   /* RTC */
> > 
> > diff --git a/arch/arm/plat-samsung/include/plat/devs.h
> > b/arch/arm/plat-samsung/include/plat/devs.h index 87d501f..0dc4ac4
> > 100644
> > --- a/arch/arm/plat-samsung/include/plat/devs.h
> > +++ b/arch/arm/plat-samsung/include/plat/devs.h
> > @@ -134,6 +134,7 @@ extern struct platform_device
> > exynos4_device_spdif;
> > 
> >   extern struct platform_device samsung_asoc_idma;
> >   extern struct platform_device samsung_device_keypad;
> > 
> > +extern struct platform_device samsung_device_pwm;
> > 
> >   /* s3c2440 specific devices */
> > 
> > diff --git a/arch/arm/plat-samsung/include/plat/pwm-core.h
> > b/arch/arm/plat-samsung/include/plat/pwm-core.h new file mode 100644
> > index 0000000..df50f5c
> > --- /dev/null
> > +++ b/arch/arm/plat-samsung/include/plat/pwm-core.h
> > @@ -0,0 +1,24 @@
> > +/*
> > + * linux/arch/arm/plat-samsung/onenand-core.h
> 
> Are such full file path names really useful, especially we are never
> sure they are up to date ? I guess this line could be removed.

No, they are not. This is a copy-pasto I missed (notice onenand-core...).

> > + *  Copyright (c) 2013 Tomasz Figa<tomasz.figa at gmail.com>
> > + *
> > + * Samsung PWM Controller core functions
> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify + * it under the terms of the GNU General Public License
> > version 2 as + * published by the Free Software Foundation.
> > +*/
> > +
> > +#ifndef __ASM_ARCH_PWM_CORE_H
> > +#define __ASM_ARCH_PWM_CORE_H __FILE__
> > +
> > +#include<clocksource/samsung_pwm.h>
> > +
> > +#ifdef CONFIG_SAMSUNG_DEV_PWM
> > +extern void samsung_pwm_set_platdata(struct samsung_pwm_variant *pd);
> 
> nit: 'extern' is implicit for function declarations, it could be omitted
> here.

The extern kernel is used widely over the kernel (including headers in 
plat-samsung) and I prefer adding it for clarity.

Best regards,
Tomasz



From tomasz.figa at gmail.com  Sun Jul 21 17:58:04 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sun, 21 Jul 2013 23:58:04 +0200
Subject: [PATCH v4 13/20] pwm: Add new pwm-samsung driver
In-Reply-To: <51EC3B97.3040107@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-15-git-send-email-tomasz.figa@gmail.com>
 <51EC3B97.3040107@gmail.com>
Message-ID: <4551618.l5Bs8czD9o@flatron>

On Sunday 21 of July 2013 21:50:47 Sylwester Nawrocki wrote:
> On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> > This patch introduces new Samsung PWM driver, which uses Samsung
> > PWM/timer master driver to control shared parts of the hardware.
> > 
> > Signed-off-by: Tomasz Figa<tomasz.figa at gmail.com>
> > ---
> > 
> >   drivers/pwm/Makefile      |   1 +
> >   drivers/pwm/pwm-samsung.c | 606
> >   ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 607
> >   insertions(+)
> >   create mode 100644 drivers/pwm/pwm-samsung.c
> 
> [...]
> 
> > +static const struct samsung_pwm_variant s3c64xx_variant = {
> > +	.bits		= 32,
> > +	.div_base	= 0,
> 
> Initialization to 0 could be omitted, since it is implicit.

Well, I'd prefer keeping this as is, for clarity. It improves code 
readability, because you don't have to look at struct definition to see 
all the fields.

> > +	.has_tint_cstat	= true,
> > +	.tclk_mask	= BIT(7) | BIT(6) | BIT(5),
> > +};
> > +
> > +static const struct samsung_pwm_variant s5p64x0_variant = {
> > +	.bits		= 32,
> > +	.div_base	= 0,
> 
> Ditto.
> 
> > +	.has_tint_cstat	= true,
> > +};
> > +
> > +static const struct samsung_pwm_variant s5p_variant = {
> > +	.bits		= 32,
> > +	.div_base	= 0,
> 
> Ditto.
> 
> > +	.has_tint_cstat	= true,
> > +	.tclk_mask	= BIT(5),
> > +};
> > +
> 
> [...]
> 
> > +static int pwm_samsung_remove(struct platform_device *pdev)
> > +{
> > +	struct samsung_pwm_chip *chip = platform_get_drvdata(pdev);
> > +	int ret;
> > +
> > +	ret = pwmchip_remove(&chip->chip);
> > +	if (ret < 0)
> > +		return ret;
> 
> Since return value of the remove() callback is happily ignored by
> the driver core I think there is no point in returning an error
> here like this. Wouldn't it be more sensible to just call all the
> cleanup functions unconditionally ? At least potentially wrong state
> of the clock could be avoided.

IMHO handling the errors correctly here is more future-proof. Driver core 
might be modified to handle errors in future and this driver will not need 
to be modified.

Best regards,
Tomasz



From sylvester.nawrocki at gmail.com  Sun Jul 21 18:22:16 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Mon, 22 Jul 2013 00:22:16 +0200
Subject: [PATCH v4 00/20] Samsung PWM support cleanup
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <51EC5F18.8040007@gmail.com>

On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> Since we now have a proper Samsung PWM clocksource driver in place,
> we can proceed with further cleanup of PWM timers support on Samsung SoCs.
>
> This series attempts to achieve this goal by:
>   1) fixing up few things in samsung_pwm_timer clocksource driver,
>   2) moving remaining Samsung platforms to the new clocksource driver,
>   3) removing old clocksource driver,
>   4) adding new multiplatform- and DT-aware PWM driver,
>   5) moving all Samsung platforms to use the new PWM driver,
>   6) removing old PWM driver,
>   7) removing all PWM-related code that is not used anymore.
>
> Cleaning up the PWM driver is a bit tricky, because the design of current
> driver makes it completely unsuitable for DT and multiplatform and would
> require a heavy rework to make it usable, breaking any existing Samsung PWM
> users by the way. To avoid any breakage this series first renames the old
> driver, then adds new one using original name, migrates all platforms to
> use it and then finally removes the old driver.
>
> See particular patches for more detailed descriptions.
>
> [On S3C6410-based Tiny6410 (Mini6410-compatible) with pwm-beeper, SMDK6410
> with PWM backlight and Exynos4210-based Origen board (with PWM0 attached
> to a scope)]
> Tested-by: Tomasz Figa<tomasz.figa at gmail.com>
>
> [On S3C2440-based Mini2440 board]
> Tested-by: Sylwester Nawrocki<sylvester.nawrocki at gmail.com>

I have retested this series on top of v3.11-rc1 with pwm-backlight (and 
buzzer
as the output :)) on Mini2440. It seems to work well - generated frequencies
are correct. I'll check pulse widths with a scope tomorrow, as it's a 
bit late
now. FWIW you can add to this series my:

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>

> [On a s3c2416 based machine]
> Tested-by: Heiko Stuebner<heiko at sntech.de>
>
> [Also not sure on what boards, but still]
> Tested-by: Mark Brown<broonie at linaro.org>
>
> Acked-by: Arnd Bergmann<arnd at arndb.de>
> Acked-by: Thierry Reding<thierry.reding at gmail.com>
> Acked-by: Heiko Stuebner<heiko at sntech.de>

Thanks,
Sylwester


From tomasz.figa at gmail.com  Sun Jul 21 18:24:27 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 00:24:27 +0200
Subject: [PATCH v4 07/20] ARM: SAMSUNG: Add new PWM platform device
In-Reply-To: <3579759.6nJBcZTDZ4@flatron>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <51EC3A81.7050001@gmail.com> <3579759.6nJBcZTDZ4@flatron>
Message-ID: <3807808.Lo7Q7WGM8g@flatron>

On Sunday 21 of July 2013 23:51:24 Tomasz Figa wrote:
> Hi Sylwester,
> 
> On Sunday 21 of July 2013 21:46:09 Sylwester Nawrocki wrote:
> > Hi Tomasz,
> > 
> > On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> > > This patch adds new samsung_device_pwm platform device that
> > > represents
> > > the whole PWM/timer block and includes memory and IRQ resources.
> > > 
> > > Signed-off-by: Tomasz Figa<tomasz.figa at gmail.com>
> > > ---
> > > 
> > >   arch/arm/plat-samsung/devs.c                  | 17
> > >   +++++++++++++++++
> > >   arch/arm/plat-samsung/include/plat/devs.h     |  1 +
> > >   arch/arm/plat-samsung/include/plat/pwm-core.h | 24
> > >   ++++++++++++++++++++++++ 3 files changed, 42 insertions(+)
> > >   create mode 100644 arch/arm/plat-samsung/include/plat/pwm-core.h
> > > 
> > > diff --git a/arch/arm/plat-samsung/devs.c
> > > b/arch/arm/plat-samsung/devs.c index 0f9c3f4..bba6d78 100644
> > > --- a/arch/arm/plat-samsung/devs.c
> > > +++ b/arch/arm/plat-samsung/devs.c
> > > @@ -58,6 +58,7 @@
> > > 
> > >   #include<plat/keypad.h>
> > >   #include<linux/platform_data/mmc-s3cmci.h>
> > >   #include<linux/platform_data/mtd-nand-s3c2410.h>
> > > 
> > > +#include<plat/pwm-core.h>
> > > 
> > >   #include<plat/sdhci.h>
> > >   #include<linux/platform_data/touchscreen-s3c2410.h>
> > >   #include<linux/platform_data/usb-s3c2410_udc.h>
> > > 
> > > @@ -1127,6 +1128,22 @@ struct platform_device s3c_device_timer[] = {
> > > 
> > >   	[3] = { DEFINE_S3C_TIMER(3, IRQ_TIMER3) },
> > >   	[4] = { DEFINE_S3C_TIMER(4, IRQ_TIMER4) },
> > >   
> > >   };
> > > 
> > > +
> > > +static struct resource samsung_pwm_resource[] = {
> > > +	DEFINE_RES_MEM(SAMSUNG_PA_TIMER, SZ_4K),
> > > +};
> > > +
> > > +struct platform_device samsung_device_pwm = {
> > > +	.name		= "samsung-pwm",
> > > +	.id		= -1,
> > > +	.num_resources	= ARRAY_SIZE(samsung_pwm_resource),
> > > +	.resource	= samsung_pwm_resource,
> > > +};
> > > +
> > > +void __init samsung_pwm_set_platdata(struct samsung_pwm_variant
> > > *pd)
> > > +{
> > > +	samsung_device_pwm.dev.platform_data = pd;
> > > +}
> > > 
> > >   #endif /* CONFIG_SAMSUNG_DEV_PWM */
> > >   
> > >   /* RTC */
> > > 
> > > diff --git a/arch/arm/plat-samsung/include/plat/devs.h
> > > b/arch/arm/plat-samsung/include/plat/devs.h index 87d501f..0dc4ac4
> > > 100644
> > > --- a/arch/arm/plat-samsung/include/plat/devs.h
> > > +++ b/arch/arm/plat-samsung/include/plat/devs.h
> > > @@ -134,6 +134,7 @@ extern struct platform_device
> > > exynos4_device_spdif;
> > > 
> > >   extern struct platform_device samsung_asoc_idma;
> > >   extern struct platform_device samsung_device_keypad;
> > > 
> > > +extern struct platform_device samsung_device_pwm;
> > > 
> > >   /* s3c2440 specific devices */
> > > 
> > > diff --git a/arch/arm/plat-samsung/include/plat/pwm-core.h
> > > b/arch/arm/plat-samsung/include/plat/pwm-core.h new file mode 100644
> > > index 0000000..df50f5c
> > > --- /dev/null
> > > +++ b/arch/arm/plat-samsung/include/plat/pwm-core.h
> > > @@ -0,0 +1,24 @@
> > > +/*
> > > + * linux/arch/arm/plat-samsung/onenand-core.h
> > 
> > Are such full file path names really useful, especially we are never
> > sure they are up to date ? I guess this line could be removed.
> 
> No, they are not. This is a copy-pasto I missed (notice
> onenand-core...).
> > > + *  Copyright (c) 2013 Tomasz Figa<tomasz.figa at gmail.com>
> > > + *
> > > + * Samsung PWM Controller core functions
> > > + *
> > > + * This program is free software; you can redistribute it and/or
> > > modify + * it under the terms of the GNU General Public License
> > > version 2 as + * published by the Free Software Foundation.
> > > +*/
> > > +
> > > +#ifndef __ASM_ARCH_PWM_CORE_H
> > > +#define __ASM_ARCH_PWM_CORE_H __FILE__
> > > +
> > > +#include<clocksource/samsung_pwm.h>
> > > +
> > > +#ifdef CONFIG_SAMSUNG_DEV_PWM
> > > +extern void samsung_pwm_set_platdata(struct samsung_pwm_variant
> > > *pd);
> > 
> > nit: 'extern' is implicit for function declarations, it could be
> > omitted here.
> 
> The extern kernel is used widely over the kernel (including headers in
> plat-samsung) and I prefer adding it for clarity.

s/extern kernel/extern keyword/

I guess it's time to sleep.

Best regards,
Tomasz



From tomasz.figa at gmail.com  Sun Jul 21 18:25:21 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 00:25:21 +0200
Subject: [PATCH v4 00/20] Samsung PWM support cleanup
In-Reply-To: <51EC5F18.8040007@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <51EC5F18.8040007@gmail.com>
Message-ID: <9102768.ef8LAvpunv@flatron>

On Monday 22 of July 2013 00:22:16 Sylwester Nawrocki wrote:
> On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> > Since we now have a proper Samsung PWM clocksource driver in place,
> > we can proceed with further cleanup of PWM timers support on Samsung
> > SoCs.> 
> > This series attempts to achieve this goal by:
> >   1) fixing up few things in samsung_pwm_timer clocksource driver,
> >   2) moving remaining Samsung platforms to the new clocksource driver,
> >   3) removing old clocksource driver,
> >   4) adding new multiplatform- and DT-aware PWM driver,
> >   5) moving all Samsung platforms to use the new PWM driver,
> >   6) removing old PWM driver,
> >   7) removing all PWM-related code that is not used anymore.
> > 
> > Cleaning up the PWM driver is a bit tricky, because the design of
> > current driver makes it completely unsuitable for DT and
> > multiplatform and would require a heavy rework to make it usable,
> > breaking any existing Samsung PWM users by the way. To avoid any
> > breakage this series first renames the old driver, then adds new one
> > using original name, migrates all platforms to use it and then
> > finally removes the old driver.
> > 
> > See particular patches for more detailed descriptions.
> > 
> > [On S3C6410-based Tiny6410 (Mini6410-compatible) with pwm-beeper,
> > SMDK6410 with PWM backlight and Exynos4210-based Origen board (with
> > PWM0 attached to a scope)]
> > Tested-by: Tomasz Figa<tomasz.figa at gmail.com>
> > 
> > [On S3C2440-based Mini2440 board]
> > Tested-by: Sylwester Nawrocki<sylvester.nawrocki at gmail.com>
> 
> I have retested this series on top of v3.11-rc1 with pwm-backlight (and
> buzzer
> as the output :)) on Mini2440. It seems to work well - generated
> frequencies are correct. I'll check pulse widths with a scope tomorrow,
> as it's a bit late
> now. FWIW you can add to this series my:
> 
> Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>

Thanks. I hope we can finally get this series merged soon.

Best regards,
Tomasz



From linus.walleij at linaro.org  Sun Jul 21 18:50:13 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Jul 2013 00:50:13 +0200
Subject: [PATCH 1/5] pinctrl: sirf: fix the pin number and mux bit for usp0
In-Reply-To: <1372924529-5519-1-git-send-email-Baohua.Song@csr.com>
References: <1372924529-5519-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <CACRpkdZEdr-ViHf4ygnZh6u555F8bzvUQC70x1QwYVzkf1rzVQ@mail.gmail.com>

On Thu, Jul 4, 2013 at 9:55 AM, Barry Song <Baohua.Song at csr.com> wrote:

> From: Qipan Li <Qipan.Li at csr.com>
>
> we missed a pin and related mux bit for usp pin group, this
> patch fixes it.
>
> Signed-off-by: Qipan Li <Qipan.Li at csr.com>
> Signed-off-by: Barry Song <Baohua.Song at csr.com>

Applied.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Sun Jul 21 18:52:48 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Jul 2013 00:52:48 +0200
Subject: [PATCH 2/5] pinctrl: sirf: add usp0_uart_nostreamctrl pin group
 for usp-uart without flowctrl
In-Reply-To: <1372924529-5519-2-git-send-email-Baohua.Song@csr.com>
References: <1372924529-5519-1-git-send-email-Baohua.Song@csr.com>
 <1372924529-5519-2-git-send-email-Baohua.Song@csr.com>
Message-ID: <CACRpkda1Ypmc8WhWb2G6=0ZJrhh_9oKB4pOGSj=u7gwQ1v0SeQ@mail.gmail.com>

On Thu, Jul 4, 2013 at 9:55 AM, Barry Song <Baohua.Song at csr.com> wrote:

> From: Qipan Li <Qipan.Li at csr.com>
>
> this patch adds the lost pin group which supports to let USP0 to simulate
> a UART without hardware flow control.
>
> Signed-off-by: Qipan Li <Qipan.Li at csr.com>
> Signed-off-by: Barry Song <Baohua.Song at csr.com>

Applied.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Sun Jul 21 18:53:52 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Jul 2013 00:53:52 +0200
Subject: [PATCH 3/5] arm/dts: sirf: fix the pingroup name mismatch between
 drivers and dts
In-Reply-To: <1372924529-5519-3-git-send-email-Baohua.Song@csr.com>
References: <1372924529-5519-1-git-send-email-Baohua.Song@csr.com>
 <1372924529-5519-3-git-send-email-Baohua.Song@csr.com>
Message-ID: <CACRpkdYNFzP7vhO-fRXsnQR2dQh9su6M5z-Wcwq7BxEV5ep=OA@mail.gmail.com>

On Thu, Jul 4, 2013 at 9:55 AM, Barry Song <Baohua.Song at csr.com> wrote:

> in drivers/pinctrl/sirf, pingroup name is cko0 and cko1, but in dts, they
> are cko0 and cko1_rst. this patch fixes the error in dts.
>
> Signed-off-by: Barry Song <Baohua.Song at csr.com>

Applied.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Sun Jul 21 18:54:56 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Jul 2013 00:54:56 +0200
Subject: [PATCH 4/5] pinctrl: sirf: fix the checkpatch issue about
 indentation
In-Reply-To: <1372924529-5519-4-git-send-email-Baohua.Song@csr.com>
References: <1372924529-5519-1-git-send-email-Baohua.Song@csr.com>
 <1372924529-5519-4-git-send-email-Baohua.Song@csr.com>
Message-ID: <CACRpkdbwCn9Fg2R4bKU2pdZTPJ58jtM0f76A5RoTk=V6i0Wuqg@mail.gmail.com>

On Thu, Jul 4, 2013 at 9:55 AM, Barry Song <Baohua.Song at csr.com> wrote:

> From: Rongjun Ying <Rongjun.Ying at csr.com>
>
> Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
> Signed-off-by: Barry Song <Baohua.Song at csr.com>

Applied.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Sun Jul 21 18:57:21 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Jul 2013 00:57:21 +0200
Subject: [PATCH 5/5] pinctrl: sirf: add freeze and restore entries for
 hibernation support
In-Reply-To: <1372924793-5579-1-git-send-email-Baohua.Song@csr.com>
References: <1372924793-5579-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <CACRpkdY-nxceQWugtrDOkKA3atBsb2y9qfp5qEAtrK=93yaNkA@mail.gmail.com>

On Thu, Jul 4, 2013 at 9:59 AM, Barry Song <Baohua.Song at csr.com> wrote:

> this patch adds hibernation entries so that the sirf platform can
> support suspend-to-disk.
>
> Signed-off-by: Barry Song <Baohua.Song at csr.com>

Are you really using this?

Applied anyway...

Yours,
Linus Walleij


From grant.likely at linaro.org  Sun Jul 21 19:36:17 2013
From: grant.likely at linaro.org (Grant Likely)
Date: Mon, 22 Jul 2013 00:36:17 +0100
Subject: [PATCH] of: match the compatible in the order set by the dts file
In-Reply-To: <51EC4859.5000007@gmail.com>
References: <1373013818-11365-1-git-send-email-b32955@freescale.com>
 <20130709070541.GQ516@pengutronix.de> <51DBBFDA.70302@freescale.com>
 <20130709075124.GR516@pengutronix.de> <51DBC58D.90002@freescale.com>
 <20130720054439.308B33E13F0@localhost> <51EC4859.5000007@gmail.com>
Message-ID: <CACxGe6s2UjFkZBOUKVP5=4kW9a=vKT3kQA8YrtitPgC4PLj6jw@mail.gmail.com>

On Sun, Jul 21, 2013 at 9:45 PM, Rob Herring <robherring2 at gmail.com> wrote:
> We can debate whether the driver order matters or not, but either way
> I'm not sure this patch does the right thing. It doesn't really look
> correct to me, but I haven't dug into it.
>
> We've already tried to fix matching and reverted the fix once before
> (commit below). So this patch needs careful review and thought about
> cases where the name and/or type is used to match.

The rules have always been well established. This patch /shouldn't/
cause any regression that cannot be narrowed down to a fixable driver
bug.

A harder problem to solve however is dealing with the case when
multiple drivers will potentially bind against the same device. Making
that work requires getting all of the match tables into the kernel
early so that the kernel can select the correct driver of many. Can't
be that big a problem though since we've never actually tried to solve
it.  :-)

[...]
>     Rob Herring explains:
>      "The problem is match combinations of compatible plus name and/or type
>       fail to match correctly.  I have a fix for this, but given how late it
>       is for 3.5 I think it is best to revert this for now.  There could be
>       other cases that rely on the current although wrong behavior.  I will
>       post an updated version for 3.6."

I don't believe the fix ever got posted. Do you still have it? Or can
you describe what needs to be done?

g.


From cavokz at gmail.com  Sun Jul 21 19:42:56 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Mon, 22 Jul 2013 01:42:56 +0200
Subject: [PATCH 1/5] ARM: bcm4760: Add platform infrastructure
In-Reply-To: <20130721002713.512199844@gmail.com>
References: <20130721002320.730568671@gmail.com>
 <20130721002713.512199844@gmail.com>
Message-ID: <20130721234256.GA5537@glitch>

+ Christian Daudt  (Christian, you've not an entry in MAINTAINERS)

On Sun, Jul 21, 2013 at 02:23:21AM +0200, Domenico Andreoli wrote:
> From: Domenico Andreoli <domenico.andreoli at linux.com>
> 
> Platform infrastructure for the Broadcom BCM4760 based ARM11 SoCs.
> 
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Domenico Andreoli <domenico.andreoli at linux.com>
> ---
> Index: b/arch/arm/Makefile
> ===================================================================
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x0020
>  machine-$(CONFIG_ARCH_AT91)		+= at91
>  machine-$(CONFIG_ARCH_BCM)		+= bcm
>  machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
> +machine-$(CONFIG_ARCH_BCM4760)		+= bcm
>  machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
>  machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
>  machine-$(CONFIG_ARCH_DAVINCI)		+= davinci

I've noticed that enabling both CONFIG_ARCH_BCM and CONFIG_ARCH_BCM4760
makes the linker complain of duplicate symbols.

Shouldn't the mach-bcm subdir be included always and let then Makefile
therein sort what to build?

As I side note, I think this CONFIG_ARCH_BCM option is misnamed, shouldn't be
something like CONFIG_ARCH_BCM281XX? It looks about this ARMv7 family only.

Thanks,
Domenico


From broonie at kernel.org  Sun Jul 21 19:57:08 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 22 Jul 2013 00:57:08 +0100
Subject: [PATCH] ASoC: tegra: correct playback_dma_data setup
In-Reply-To: <1374374049-30732-1-git-send-email-rizhao@nvidia.com>
References: <1374374049-30732-1-git-send-email-rizhao@nvidia.com>
Message-ID: <20130721235708.GF9858@sirena.org.uk>

On Sun, Jul 21, 2013 at 10:34:09AM +0800, Richard Zhao wrote:
> The errors were caused by copy/paste mistake in below commit
> since v3.10:
> 3489d50 ASoC: tegra: Use common DAI DMA data struct

Applied, thanks.
-------------- 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/20130722/7b2696ea/attachment.sig>

From 21cnbao at gmail.com  Sun Jul 21 20:04:33 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Mon, 22 Jul 2013 08:04:33 +0800
Subject: [PATCH 5/5] pinctrl: sirf: add freeze and restore entries for
 hibernation support
In-Reply-To: <CACRpkdY-nxceQWugtrDOkKA3atBsb2y9qfp5qEAtrK=93yaNkA@mail.gmail.com>
References: <1372924793-5579-1-git-send-email-Baohua.Song@csr.com>
 <CACRpkdY-nxceQWugtrDOkKA3atBsb2y9qfp5qEAtrK=93yaNkA@mail.gmail.com>
Message-ID: <CAGsJ_4wxJ+LVtKwajybC6ytguzpEp-Men20hrhS92xB=XdQMQQ@mail.gmail.com>

2013/7/22 Linus Walleij <linus.walleij at linaro.org>:
> On Thu, Jul 4, 2013 at 9:59 AM, Barry Song <Baohua.Song at csr.com> wrote:
>
>> this patch adds hibernation entries so that the sirf platform can
>> support suspend-to-disk.
>>
>> Signed-off-by: Barry Song <Baohua.Song at csr.com>
>
> Are you really using this?

yes, we do for quick boot requirement.

>
> Applied anyway...
>
> Yours,
> Linus Walleij

-barry


From 21cnbao at gmail.com  Sun Jul 21 20:06:55 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Mon, 22 Jul 2013 08:06:55 +0800
Subject: [PATCH 1/6] ASoC: sirf: add sirf platform driver which provides
 DMA
In-Reply-To: <20130719161252.GK9858@sirena.org.uk>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
 <1374232042-26088-2-git-send-email-Baohua.Song@csr.com>
 <20130719161252.GK9858@sirena.org.uk>
Message-ID: <CAGsJ_4yJoYJdRjZiVOPYgOA+kxGyU9eKjWQFK1B_AnQ6-7BDjg@mail.gmail.com>

2013/7/20 Mark Brown <broonie at kernel.org>:
> On Fri, Jul 19, 2013 at 07:07:17PM +0800, Barry Song wrote:
>
>> index 0000000..3678aed
>> --- /dev/null
>> +++ b/sound/soc/sirf/Kconfig
>> @@ -0,0 +1,4 @@
>> +config SND_SIRF_SOC
>> +     tristate "Platform DMA driver for the SiRF SoC chips"
>> +     depends on ARCH_SIRF && SND_SOC
>> +     select SND_SOC_DMAENGINE_PCM
>
> Does this have any actual platform build dependencies or can this be
> ARCH_SIRF || COMPILE_TEST?

it depends on SIRF as it is specific to SiRFSoC, but i think it would
be good to have " || COMPILE_TEST"

-barry


From horms at verge.net.au  Sun Jul 21 20:43:30 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 09:43:30 +0900
Subject: [PATCH 01/19] ARM: shmobile: r8a73a4: Add pin control device to
 device tree
In-Reply-To: <5391577.hBy909tQ3H@avalon>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
 <c173e780f82e5dea3da21f9eda47bc48aa3f57b1.1374208262.git.horms+renesas@verge.net.au>
 <51E931EA.6010805@cogentembedded.com> <5391577.hBy909tQ3H@avalon>
Message-ID: <20130722004329.GE12445@verge.net.au>

On Fri, Jul 19, 2013 at 02:42:14PM +0200, Laurent Pinchart wrote:
> On Friday 19 July 2013 16:32:42 Sergei Shtylyov wrote:
> > Hello.
> > 
> > On 19-07-2013 8:36, Simon Horman wrote:
> > > From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> > > 
> > > Add a pfc node to the r8a73a4 device tree.
> > 
> >     This patch looks strange...
> > 
> > > Signed-off-by: Laurent Pinchart
> > > <laurent.pinchart+renesas at ideasonboard.com>
> > > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> > > ---
> > > 
> > >   arch/arm/boot/dts/r8a73a4.dtsi |   88
> > >   ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88
> > >   insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/r8a73a4.dtsi
> > > b/arch/arm/boot/dts/r8a73a4.dtsi index 4ff2019..f1a35d5 100644
> > > --- a/arch/arm/boot/dts/r8a73a4.dtsi
> > > +++ b/arch/arm/boot/dts/r8a73a4.dtsi
> > > @@ -85,4 +85,92 @@
> > > 
> > >   		interrupt-parent = <&gic>;
> > >   		interrupts = <0 69 4>;
> > >   	
> > >   	};
> > > 
> > > +
> > > +	i2c0: i2c at e6500000 {
> > > +		#address-cells = <1>;
> > > +		#size-cells = <0>;
> > > +		compatible = "renesas,rmobile-iic";
> > > +		reg = <0 0xe6500000 0 0x428>;
> > > +		interrupt-parent = <&gic>;
> > > +		interrupts = <0 174 0x4>;
> > > +	};
> > 
> > [...]
> > 
> > > +	i2c8: i2c at e6570000 {
> > > +		#address-cells = <1>;
> > > +		#size-cells = <0>;
> > > +		compatible = "renesas,rmobile-iic";
> > > +		reg = <0 0xe6570000 0 0x428>;
> > > +		interrupt-parent = <&gic>;
> > > +		interrupts = <0 173 0x4>;
> > > +	};
> > > +
> > 
> > Hm, this also adds a bunch of I2C controllers which is not mentioned in the
> > changelog at all.
> 
> Rebase error ? They were not included in my original patch.

Sorry, I will correct that and repost.


From horms at verge.net.au  Sun Jul 21 20:58:32 2013
From: horms at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 09:58:32 +0900
Subject: [GIT 00/19] Renesas ARM based SoC pinmux updates for v3.12
In-Reply-To: <cover.1374208262.git.horms+renesas@verge.net.au>
References: <cover.1374208262.git.horms+renesas@verge.net.au>
Message-ID: <20130722005832.GF12445@verge.net.au>

Hi,

please hold off on this. It appears that there is a problem with
one of the patches.

On Fri, Jul 19, 2013 at 01:36:29PM +0900, Simon Horman wrote:
> The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:
> 
>   Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-pinmux-for-v3.12
> 
> for you to fetch changes up to 838a7070ce8bfff11e19ed434edd9a4423b478bd:
> 
>   ARM: shmobile: kzm9g-reference: Add LED1-LED4 to the device tree (2013-07-16 12:55:04 +0900)
> 
> ----------------------------------------------------------------
> Renesas ARM based SoC pinmux updates for v3.12
> 
> SH Mobile pinctrl DT support
> 
> ----------------------------------------------------------------
> Laurent Pinchart (19):
>       ARM: shmobile: r8a73a4: Add pin control device to device tree
>       ARM: shmobile: r8a7740: Add pin control device to device tree
>       ARM: shmobile: r8a7778: Add pin control device to device tree
>       ARM: shmobile: r8a7778: Add GPIO controller devices to device tree
>       ARM: shmobile: r8a7779: Add pin control device to device tree
>       ARM: shmobile: r8a7779: Add GPIO controller devices to device tree
>       ARM: shmobile: r8a7790: Add pin control device to device tree
>       ARM: shmobile: r8a7790: Add GPIO controller devices to device tree
>       ARM: shmobile: sh7372: Add pin control device to device tree
>       ARM: shmobile: sh73a0: Add pin control device to device tree
>       ARM: shmobile: armadillo-reference: Move pinctrl mappings to device tree
>       ARM: shmobile: armadillo-reference: Add st1232 pin mappings
>       ARM: shmobile: armadillo-reference: Move st1232 reset GPIO to DT
>       ARM: shmobile: armadillo-reference: Add LED1-LED4 to the device tree
>       ARM: shmobile: marzen-reference: Move pinctrl mappings to device tree
>       ARM: shmobile: marzen-reference: Add LED2-LED4 to the device tree
>       ARM: shmobile: kzm9g-reference: Move pinctrl mappings to device tree
>       ARM: shmobile: kzm9g-reference: Move SDHI regulators to DT
>       ARM: shmobile: kzm9g-reference: Add LED1-LED4 to the device tree
> 
>  arch/arm/boot/dts/r8a73a4.dtsi                     |   88 +++++++++++++++++++
>  .../boot/dts/r8a7740-armadillo800eva-reference.dts |   34 ++++++++
>  arch/arm/boot/dts/r8a7740.dtsi                     |    8 ++
>  arch/arm/boot/dts/r8a7778.dtsi                     |   66 ++++++++++++++
>  arch/arm/boot/dts/r8a7779-marzen-reference.dts     |   49 +++++++++++
>  arch/arm/boot/dts/r8a7779.dtsi                     |   90 ++++++++++++++++++++
>  arch/arm/boot/dts/r8a7790.dtsi                     |   78 +++++++++++++++++
>  arch/arm/boot/dts/sh7372.dtsi                      |    8 ++
>  arch/arm/boot/dts/sh73a0-kzm9g-reference.dts       |   90 +++++++++++++++++++-
>  arch/arm/boot/dts/sh73a0.dtsi                      |    8 ++
>  .../board-armadillo800eva-reference.c              |   18 +---
>  arch/arm/mach-shmobile/board-kzm9g-reference.c     |   47 ----------
>  arch/arm/mach-shmobile/board-marzen-reference.c    |   28 ------
>  13 files changed, 518 insertions(+), 94 deletions(-)
> 


From marex at denx.de  Sun Jul 21 21:15:28 2013
From: marex at denx.de (Marek Vasut)
Date: Mon, 22 Jul 2013 03:15:28 +0200
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <20130716094320.GA29679@nchen-desktop>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <201307121518.31501.marex@denx.de> <20130716094320.GA29679@nchen-desktop>
Message-ID: <201307220315.28821.marex@denx.de>

Hi Peter,

> On Fri, Jul 12, 2013 at 03:18:31PM +0200, Marek Vasut wrote:
> > Hi Peter,
> > 
> > > On Fri, Jul 12, 2013 at 06:04:43AM +0200, Marek Vasut wrote:
> > > > Hi Peter,
> > > > 
> > > > > On Thu, Jul 11, 2013 at 07:57:19PM +0200, Marek Vasut wrote:
> > > > > > Hi Peter,
> > > > > > 
> > > > > > > This patchset adds tested otg id switch function and
> > > > > > > vbus connect and disconnect detection for chipidea driver.
> > > > > > > And fix kinds of bugs found at chipidea drivers after enabling
> > > > > > > id and vbus detection.
> > > > > > > 
> > > > > > > This patch is fully tested at imx6 sabresd platform.
> > > > > > > My chipidea repo: https://github.com/hzpeterchen/linux-usb.git
> > > > > > > 
> > > > > > > Changes for v12:
> > > > > > > - Rebased greg's usb-next tree (3.10.0-rc7+)
> > > > > > > - Split more small patches for single function and fix.
> > > > > > 
> > > > > > I tested the patchset. Here are the results:
> > > > > > 
> > > > > > - VBUS switching
> > > > > > 
> > > > > > I'm no longer getting any ID interrupts at all when I apply the
> > > > > > patch below. The board stays in HOST mode all the time. If I
> > > > > > configure it as peripheral, it works as peripheral. Note with
> > > > > > [1], I was able to switch from Peripheral->Host , not the other
> > > > > > way around.
> > > > > 
> > > > > Thanks for your testing. But first, can you have me check
> > > > > if your ID wakeup is enabled?
> > > > 
> > > > ID wakeup? How do I check?
> > > 
> > > See otgsc at controller register, the ID wakeup enable is bit 24.
> > 
> > Yes, ID interrupt (IDIE) is set.
> > 
> > I noticed this backtrace in the kernel bootlog, but this only happens if
> > the dr_mode="otg" , it comes from the host-mode irq handler :
> > 
> > [    2.757563] irq 238: nobody cared (try booting with the "irqpoll"
> > option) [    2.764398] CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-
> > next-20130711-00013-g011c4b3-dirty #703
> > [    2.773445] [<80013878>] (unwind_backtrace+0x0/0xe8) from [<80011644>]
> > (show_stack+0x10/0x14)
> > [    2.782027] [<80011644>] (show_stack+0x10/0x14) from [<800659f4>]
> > (__report_bad_irq.isra.6+0x20/0xe0)
> > [    2.791286] [<800659f4>] (__report_bad_irq.isra.6+0x20/0xe0) from
> > [<80065c98>] (note_interrupt+0x16c/0x230)
> > [    2.801063] [<80065c98>] (note_interrupt+0x16c/0x230) from
> > [<80064000>] (handle_irq_event_percpu+0x10c/0x1a4)
> > [    2.811010] [<80064000>] (handle_irq_event_percpu+0x10c/0x1a4) from
> > [<800640e8>] (handle_irq_event+0x50/0x78)
> > [    2.820958] [<800640e8>] (handle_irq_event+0x50/0x78) from
> > [<8006652c>] (handle_level_irq+0x88/0x10c)
> > [    2.830210] [<8006652c>] (handle_level_irq+0x88/0x10c) from
> > [<800638d0>] (generic_handle_irq+0x28/0x3c)
> > [    2.839637] [<800638d0>] (generic_handle_irq+0x28/0x3c) from
> > [<8000f84c>] (handle_IRQ+0x30/0x84)
> > [    2.848461] [<8000f84c>] (handle_IRQ+0x30/0x84) from [<80012160>]
> > (__irq_svc+0x40/0x6c)
> > [    2.856510] [<80012160>] (__irq_svc+0x40/0x6c) from [<80022a44>]
> > (__do_softirq+0x90/0x1d8)
> > [    2.864812] [<80022a44>] (__do_softirq+0x90/0x1d8) from [<80022edc>]
> > (irq_exit+0x98/0xd4)
> > [    2.873025] [<80022edc>] (irq_exit+0x98/0xd4) from [<8000f850>]
> > (handle_IRQ+0x34/0x84)
> > [    2.880980] [<8000f850>] (handle_IRQ+0x34/0x84) from [<80012160>]
> > (__irq_svc+0x40/0x6c)
> > [    2.889020] [<80012160>] (__irq_svc+0x40/0x6c) from [<8001d724>]
> > (vprintk_emit+0x1bc/0x524)
> > [    2.897411] [<8001d724>] (vprintk_emit+0x1bc/0x524) from [<804da5a4>]
> > (printk+0x30/0x40)
> > [    2.905551] [<804da5a4>] (printk+0x30/0x40) from [<80630138>]
> > (mousedev_init+0x4c/0x60)
> > [    2.913617] [<80630138>] (mousedev_init+0x4c/0x60) from [<806178fc>]
> > (do_one_initcall+0x94/0x14c)
> > [    2.922537] [<806178fc>] (do_one_initcall+0x94/0x14c) from
> > [<80617b20>] (kernel_init_freeable+0x16c/0x22c)
> > [    2.932230] [<80617b20>] (kernel_init_freeable+0x16c/0x22c) from
> > [<804d8cbc>] (kernel_init+0x8/0x150)
> > [    2.941486] [<804d8cbc>] (kernel_init+0x8/0x150) from [<8000ea70>]
> > (ret_from_fork+0x14/0x24)
> > [    2.949932] handlers:
> > [    2.952227] [<8033fc58>] ci_irq
> > [    2.955388] Disabling IRQ #238
> 
> Marek, I have a test at imx28evk (Freescale imx28evk) for this patchset,
> it works well for dual-role switch after adding below dts change.
> There is a kernel dump when works at udc mode(due to enable
> CONFIG_LOCKUP_DETECTOR), at the first connect, but it does not affect
> function, it should be a common chipidea problem, I will check later.

Sorry for the long delay. I finally got further with this, at least now I can 
switch Periph->Host again, but if I do so the other way around (unplug host 
adapter and plug computer cable) and dump the controller registers, I still see 
the controller in "host" (according to USBMODE register) mode. The controller 
stays in HOST mode even if I force it to gadget mode by writing "gadget" into 
debugfs "role" entry. I will keep poking.

In the meantime, I guess if it works on the EVK, it might be a hardware error so 
I better stop stalling you. I'll drop you an email if I find what this problem 
is.

Best regards,
Marek Vasut


From peter.chen at freescale.com  Sun Jul 21 21:21:28 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Mon, 22 Jul 2013 09:21:28 +0800
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <201307220315.28821.marex@denx.de>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <201307121518.31501.marex@denx.de>
 <20130716094320.GA29679@nchen-desktop>
 <201307220315.28821.marex@denx.de>
Message-ID: <20130722012127.GA25817@nchen-desktop>

On Mon, Jul 22, 2013 at 03:15:28AM +0200, Marek Vasut wrote:
> Hi Peter,
> 
> > On Fri, Jul 12, 2013 at 03:18:31PM +0200, Marek Vasut wrote:
> > > Hi Peter,
> > > 
> > > > On Fri, Jul 12, 2013 at 06:04:43AM +0200, Marek Vasut wrote:
> > > > > Hi Peter,
> > > > > 
> > > > > > On Thu, Jul 11, 2013 at 07:57:19PM +0200, Marek Vasut wrote:
> > > > > > > Hi Peter,
> > > > > > > 
> > > > > > > > This patchset adds tested otg id switch function and
> > > > > > > > vbus connect and disconnect detection for chipidea driver.
> > > > > > > > And fix kinds of bugs found at chipidea drivers after enabling
> > > > > > > > id and vbus detection.
> > > > > > > > 
> > > > > > > > This patch is fully tested at imx6 sabresd platform.
> > > > > > > > My chipidea repo: https://github.com/hzpeterchen/linux-usb.git
> > > > > > > > 
> > > > > > > > Changes for v12:
> > > > > > > > - Rebased greg's usb-next tree (3.10.0-rc7+)
> > > > > > > > - Split more small patches for single function and fix.
> > > > > > > 
> > > > > > > I tested the patchset. Here are the results:
> > > > > > > 
> > > > > > > - VBUS switching
> > > > > > > 
> > > > > > > I'm no longer getting any ID interrupts at all when I apply the
> > > > > > > patch below. The board stays in HOST mode all the time. If I
> > > > > > > configure it as peripheral, it works as peripheral. Note with
> > > > > > > [1], I was able to switch from Peripheral->Host , not the other
> > > > > > > way around.
> > > > > > 
> > > > > > Thanks for your testing. But first, can you have me check
> > > > > > if your ID wakeup is enabled?
> > > > > 
> > > > > ID wakeup? How do I check?
> > > > 
> > > > See otgsc at controller register, the ID wakeup enable is bit 24.
> > > 
> > > Yes, ID interrupt (IDIE) is set.
> > > 
> > > I noticed this backtrace in the kernel bootlog, but this only happens if
> > > the dr_mode="otg" , it comes from the host-mode irq handler :
> > > 
> > > [    2.757563] irq 238: nobody cared (try booting with the "irqpoll"
> > > option) [    2.764398] CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-
> > > next-20130711-00013-g011c4b3-dirty #703
> > > [    2.773445] [<80013878>] (unwind_backtrace+0x0/0xe8) from [<80011644>]
> > > (show_stack+0x10/0x14)
> > > [    2.782027] [<80011644>] (show_stack+0x10/0x14) from [<800659f4>]
> > > (__report_bad_irq.isra.6+0x20/0xe0)
> > > [    2.791286] [<800659f4>] (__report_bad_irq.isra.6+0x20/0xe0) from
> > > [<80065c98>] (note_interrupt+0x16c/0x230)
> > > [    2.801063] [<80065c98>] (note_interrupt+0x16c/0x230) from
> > > [<80064000>] (handle_irq_event_percpu+0x10c/0x1a4)
> > > [    2.811010] [<80064000>] (handle_irq_event_percpu+0x10c/0x1a4) from
> > > [<800640e8>] (handle_irq_event+0x50/0x78)
> > > [    2.820958] [<800640e8>] (handle_irq_event+0x50/0x78) from
> > > [<8006652c>] (handle_level_irq+0x88/0x10c)
> > > [    2.830210] [<8006652c>] (handle_level_irq+0x88/0x10c) from
> > > [<800638d0>] (generic_handle_irq+0x28/0x3c)
> > > [    2.839637] [<800638d0>] (generic_handle_irq+0x28/0x3c) from
> > > [<8000f84c>] (handle_IRQ+0x30/0x84)
> > > [    2.848461] [<8000f84c>] (handle_IRQ+0x30/0x84) from [<80012160>]
> > > (__irq_svc+0x40/0x6c)
> > > [    2.856510] [<80012160>] (__irq_svc+0x40/0x6c) from [<80022a44>]
> > > (__do_softirq+0x90/0x1d8)
> > > [    2.864812] [<80022a44>] (__do_softirq+0x90/0x1d8) from [<80022edc>]
> > > (irq_exit+0x98/0xd4)
> > > [    2.873025] [<80022edc>] (irq_exit+0x98/0xd4) from [<8000f850>]
> > > (handle_IRQ+0x34/0x84)
> > > [    2.880980] [<8000f850>] (handle_IRQ+0x34/0x84) from [<80012160>]
> > > (__irq_svc+0x40/0x6c)
> > > [    2.889020] [<80012160>] (__irq_svc+0x40/0x6c) from [<8001d724>]
> > > (vprintk_emit+0x1bc/0x524)
> > > [    2.897411] [<8001d724>] (vprintk_emit+0x1bc/0x524) from [<804da5a4>]
> > > (printk+0x30/0x40)
> > > [    2.905551] [<804da5a4>] (printk+0x30/0x40) from [<80630138>]
> > > (mousedev_init+0x4c/0x60)
> > > [    2.913617] [<80630138>] (mousedev_init+0x4c/0x60) from [<806178fc>]
> > > (do_one_initcall+0x94/0x14c)
> > > [    2.922537] [<806178fc>] (do_one_initcall+0x94/0x14c) from
> > > [<80617b20>] (kernel_init_freeable+0x16c/0x22c)
> > > [    2.932230] [<80617b20>] (kernel_init_freeable+0x16c/0x22c) from
> > > [<804d8cbc>] (kernel_init+0x8/0x150)
> > > [    2.941486] [<804d8cbc>] (kernel_init+0x8/0x150) from [<8000ea70>]
> > > (ret_from_fork+0x14/0x24)
> > > [    2.949932] handlers:
> > > [    2.952227] [<8033fc58>] ci_irq
> > > [    2.955388] Disabling IRQ #238
> > 
> > Marek, I have a test at imx28evk (Freescale imx28evk) for this patchset,
> > it works well for dual-role switch after adding below dts change.
> > There is a kernel dump when works at udc mode(due to enable
> > CONFIG_LOCKUP_DETECTOR), at the first connect, but it does not affect
> > function, it should be a common chipidea problem, I will check later.
> 
> Sorry for the long delay. I finally got further with this, at least now I can 
> switch Periph->Host again, but if I do so the other way around (unplug host 
> adapter and plug computer cable) and dump the controller registers, I still see 
> the controller in "host" (according to USBMODE register) mode. The controller 
> stays in HOST mode even if I force it to gadget mode by writing "gadget" into 
> debugfs "role" entry. I will keep poking.
> 
> In the meantime, I guess if it works on the EVK, it might be a hardware error so 
> I better stop stalling you. I'll drop you an email if I find what this problem 
> is.
> 

No, the problem is you did not config the USB OTG ID pin.
Do the same thing I have done at imx28evk, you probably will work
if the ID pin is the same at your board.

If it works, please give a tested-by :).

-- 

Best Regards,
Peter Chen



From marex at denx.de  Sun Jul 21 21:40:32 2013
From: marex at denx.de (Marek Vasut)
Date: Mon, 22 Jul 2013 03:40:32 +0200
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <20130722012127.GA25817@nchen-desktop>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <201307220315.28821.marex@denx.de> <20130722012127.GA25817@nchen-desktop>
Message-ID: <201307220340.32263.marex@denx.de>

Dear Peter Chen,

> On Mon, Jul 22, 2013 at 03:15:28AM +0200, Marek Vasut wrote:
> > Hi Peter,
> > 
> > > On Fri, Jul 12, 2013 at 03:18:31PM +0200, Marek Vasut wrote:
> > > > Hi Peter,
> > > > 
> > > > > On Fri, Jul 12, 2013 at 06:04:43AM +0200, Marek Vasut wrote:
> > > > > > Hi Peter,
> > > > > > 
> > > > > > > On Thu, Jul 11, 2013 at 07:57:19PM +0200, Marek Vasut wrote:
> > > > > > > > Hi Peter,
> > > > > > > > 
> > > > > > > > > This patchset adds tested otg id switch function and
> > > > > > > > > vbus connect and disconnect detection for chipidea driver.
> > > > > > > > > And fix kinds of bugs found at chipidea drivers after
> > > > > > > > > enabling id and vbus detection.
> > > > > > > > > 
> > > > > > > > > This patch is fully tested at imx6 sabresd platform.
> > > > > > > > > My chipidea repo:
> > > > > > > > > https://github.com/hzpeterchen/linux-usb.git
> > > > > > > > > 
> > > > > > > > > Changes for v12:
> > > > > > > > > - Rebased greg's usb-next tree (3.10.0-rc7+)
> > > > > > > > > - Split more small patches for single function and fix.
> > > > > > > > 
> > > > > > > > I tested the patchset. Here are the results:
> > > > > > > > 
> > > > > > > > - VBUS switching
> > > > > > > > 
> > > > > > > > I'm no longer getting any ID interrupts at all when I apply
> > > > > > > > the patch below. The board stays in HOST mode all the time.
> > > > > > > > If I configure it as peripheral, it works as peripheral.
> > > > > > > > Note with [1], I was able to switch from Peripheral->Host ,
> > > > > > > > not the other way around.
> > > > > > > 
> > > > > > > Thanks for your testing. But first, can you have me check
> > > > > > > if your ID wakeup is enabled?
> > > > > > 
> > > > > > ID wakeup? How do I check?
> > > > > 
> > > > > See otgsc at controller register, the ID wakeup enable is bit 24.
> > > > 
> > > > Yes, ID interrupt (IDIE) is set.
> > > > 
> > > > I noticed this backtrace in the kernel bootlog, but this only happens
> > > > if the dr_mode="otg" , it comes from the host-mode irq handler :
> > > > 
> > > > [    2.757563] irq 238: nobody cared (try booting with the "irqpoll"
> > > > option) [    2.764398] CPU: 0 PID: 1 Comm: swapper Not tainted
> > > > 3.10.0- next-20130711-00013-g011c4b3-dirty #703
> > > > [    2.773445] [<80013878>] (unwind_backtrace+0x0/0xe8) from
> > > > [<80011644>] (show_stack+0x10/0x14)
> > > > [    2.782027] [<80011644>] (show_stack+0x10/0x14) from [<800659f4>]
> > > > (__report_bad_irq.isra.6+0x20/0xe0)
> > > > [    2.791286] [<800659f4>] (__report_bad_irq.isra.6+0x20/0xe0) from
> > > > [<80065c98>] (note_interrupt+0x16c/0x230)
> > > > [    2.801063] [<80065c98>] (note_interrupt+0x16c/0x230) from
> > > > [<80064000>] (handle_irq_event_percpu+0x10c/0x1a4)
> > > > [    2.811010] [<80064000>] (handle_irq_event_percpu+0x10c/0x1a4)
> > > > from [<800640e8>] (handle_irq_event+0x50/0x78)
> > > > [    2.820958] [<800640e8>] (handle_irq_event+0x50/0x78) from
> > > > [<8006652c>] (handle_level_irq+0x88/0x10c)
> > > > [    2.830210] [<8006652c>] (handle_level_irq+0x88/0x10c) from
> > > > [<800638d0>] (generic_handle_irq+0x28/0x3c)
> > > > [    2.839637] [<800638d0>] (generic_handle_irq+0x28/0x3c) from
> > > > [<8000f84c>] (handle_IRQ+0x30/0x84)
> > > > [    2.848461] [<8000f84c>] (handle_IRQ+0x30/0x84) from [<80012160>]
> > > > (__irq_svc+0x40/0x6c)
> > > > [    2.856510] [<80012160>] (__irq_svc+0x40/0x6c) from [<80022a44>]
> > > > (__do_softirq+0x90/0x1d8)
> > > > [    2.864812] [<80022a44>] (__do_softirq+0x90/0x1d8) from
> > > > [<80022edc>] (irq_exit+0x98/0xd4)
> > > > [    2.873025] [<80022edc>] (irq_exit+0x98/0xd4) from [<8000f850>]
> > > > (handle_IRQ+0x34/0x84)
> > > > [    2.880980] [<8000f850>] (handle_IRQ+0x34/0x84) from [<80012160>]
> > > > (__irq_svc+0x40/0x6c)
> > > > [    2.889020] [<80012160>] (__irq_svc+0x40/0x6c) from [<8001d724>]
> > > > (vprintk_emit+0x1bc/0x524)
> > > > [    2.897411] [<8001d724>] (vprintk_emit+0x1bc/0x524) from
> > > > [<804da5a4>] (printk+0x30/0x40)
> > > > [    2.905551] [<804da5a4>] (printk+0x30/0x40) from [<80630138>]
> > > > (mousedev_init+0x4c/0x60)
> > > > [    2.913617] [<80630138>] (mousedev_init+0x4c/0x60) from
> > > > [<806178fc>] (do_one_initcall+0x94/0x14c)
> > > > [    2.922537] [<806178fc>] (do_one_initcall+0x94/0x14c) from
> > > > [<80617b20>] (kernel_init_freeable+0x16c/0x22c)
> > > > [    2.932230] [<80617b20>] (kernel_init_freeable+0x16c/0x22c) from
> > > > [<804d8cbc>] (kernel_init+0x8/0x150)
> > > > [    2.941486] [<804d8cbc>] (kernel_init+0x8/0x150) from [<8000ea70>]
> > > > (ret_from_fork+0x14/0x24)
> > > > [    2.949932] handlers:
> > > > [    2.952227] [<8033fc58>] ci_irq
> > > > [    2.955388] Disabling IRQ #238
> > > 
> > > Marek, I have a test at imx28evk (Freescale imx28evk) for this
> > > patchset, it works well for dual-role switch after adding below dts
> > > change. There is a kernel dump when works at udc mode(due to enable
> > > CONFIG_LOCKUP_DETECTOR), at the first connect, but it does not affect
> > > function, it should be a common chipidea problem, I will check later.
> > 
> > Sorry for the long delay. I finally got further with this, at least now I
> > can switch Periph->Host again, but if I do so the other way around
> > (unplug host adapter and plug computer cable) and dump the controller
> > registers, I still see the controller in "host" (according to USBMODE
> > register) mode. The controller stays in HOST mode even if I force it to
> > gadget mode by writing "gadget" into debugfs "role" entry. I will keep
> > poking.
> > 
> > In the meantime, I guess if it works on the EVK, it might be a hardware
> > error so I better stop stalling you. I'll drop you an email if I find
> > what this problem is.
> 
> No, the problem is you did not config the USB OTG ID pin.
> Do the same thing I have done at imx28evk, you probably will work
> if the ID pin is the same at your board.

That one I have configured, exactly the same way you did (except that mine is 
MX28_PAD_PWM2__USB0_ID).

If it was the OTG ID pin issue, would the manual switching not work ?

> If it works, please give a tested-by :).

Best regards,
Marek Vasut


From kgene.kim at samsung.com  Sun Jul 21 21:48:29 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Mon, 22 Jul 2013 10:48:29 +0900
Subject: [PATCH 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <1372054438-15693-1-git-send-email-sachin.kamat@linaro.org>
References: <1372054438-15693-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <0ab301ce867d$9078c170$b16a4450$%kim@samsung.com>

Sachin Kamat wrote:
> 
> With the recent cleanup in Exynos platform code notably commits
> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
> more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
> Exynos4412 which have more (285) than the default number of GPIOs (255).
> Thus define this number in Kconfig file. Without this patch we get the
> following errors during boot:
> 
> gpiochip_add: gpios 251..258 (gpv0) failed to register
> samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
> error code: -22
> samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
> 
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> Cc: Tomasz Figa <t.figa at samsung.com>
> ---
> Based on Kukjin's for-next tree.
> ---
>  arch/arm/Kconfig |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index ddf2667..380a53b 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1578,6 +1578,7 @@ config ARCH_NR_GPIO
>  	default 512 if SOC_OMAP5
>  	default 392 if ARCH_U8500
>  	default 352 if ARCH_VT8500
> +	default 288 if ARCH_EXYNOS
>  	default 288 if ARCH_SUNXI
>  	default 264 if MACH_H4700
>  	default 0
> --
> 1.7.9.5

Hmm, BTW, I'm wondering why it is 288 not 285 or other specific number...

Thanks,
- Kukjin



From kgene.kim at samsung.com  Sun Jul 21 21:51:54 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Mon, 22 Jul 2013 10:51:54 +0900
Subject: [PATCH 1/1] of/documentation: Fix a typo in exynos5250-clock.txt
In-Reply-To: <1373012281-26433-1-git-send-email-sachin.kamat@linaro.org>
References: <1373012281-26433-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <0ab501ce867e$0adadd40$209097c0$%kim@samsung.com>

Sachin Kamat wrote:
> 
> The clocks should be numbered sequentially as they are represented as
> enum values in the clock driver.
> 
> Typo introduced by commit 17d4caccef ("clk: exynos5250: register
> display block gate clocks to common clock framework")
> 
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> ---
>  .../devicetree/bindings/clock/exynos5250-clock.txt |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> index 781a627..1a05761 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> @@ -154,7 +154,7 @@ clock which they consume.
>    dsim0			341
>    dp			342
>    mixer			343
> -  hdmi			345
> +  hdmi			344
> 
>  Example 1: An example of a clock controller node is listed below.
> 
> --
> 1.7.9.5

Looks OK to me.

Mike, do you want me to take into the samsung tree?

Thanks,
Kukjin



From peter.chen at freescale.com  Sun Jul 21 21:53:06 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Mon, 22 Jul 2013 09:53:06 +0800
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <201307220340.32263.marex@denx.de>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <201307220315.28821.marex@denx.de>
 <20130722012127.GA25817@nchen-desktop>
 <201307220340.32263.marex@denx.de>
Message-ID: <20130722015305.GB25817@nchen-desktop>

On Mon, Jul 22, 2013 at 03:40:32AM +0200, Marek Vasut wrote:
> Dear Peter Chen,
> 
> > On Mon, Jul 22, 2013 at 03:15:28AM +0200, Marek Vasut wrote:
> > > Hi Peter,
> > > 
> > > > On Fri, Jul 12, 2013 at 03:18:31PM +0200, Marek Vasut wrote:
> > > > > Hi Peter,
> > > > > 
> > > > > > On Fri, Jul 12, 2013 at 06:04:43AM +0200, Marek Vasut wrote:
> > > > > > > Hi Peter,
> > > > > > > 
> > > > > > > > On Thu, Jul 11, 2013 at 07:57:19PM +0200, Marek Vasut wrote:
> > > > > > > > > Hi Peter,
> > > > > > > > > 
> > > > > > > > > > This patchset adds tested otg id switch function and
> > > > > > > > > > vbus connect and disconnect detection for chipidea driver.
> > > > > > > > > > And fix kinds of bugs found at chipidea drivers after
> > > > > > > > > > enabling id and vbus detection.
> > > > > > > > > > 
> > > > > > > > > > This patch is fully tested at imx6 sabresd platform.
> > > > > > > > > > My chipidea repo:
> > > > > > > > > > https://github.com/hzpeterchen/linux-usb.git
> > > > > > > > > > 
> > > > > > > > > > Changes for v12:
> > > > > > > > > > - Rebased greg's usb-next tree (3.10.0-rc7+)
> > > > > > > > > > - Split more small patches for single function and fix.
> > > > > > > > > 
> > > > > > > > > I tested the patchset. Here are the results:
> > > > > > > > > 
> > > > > > > > > - VBUS switching
> > > > > > > > > 
> > > > > > > > > I'm no longer getting any ID interrupts at all when I apply
> > > > > > > > > the patch below. The board stays in HOST mode all the time.
> > > > > > > > > If I configure it as peripheral, it works as peripheral.
> > > > > > > > > Note with [1], I was able to switch from Peripheral->Host ,
> > > > > > > > > not the other way around.
> > > > > > > > 
> > > > > > > > Thanks for your testing. But first, can you have me check
> > > > > > > > if your ID wakeup is enabled?
> > > > > > > 
> > > > > > > ID wakeup? How do I check?
> > > > > > 
> > > > > > See otgsc at controller register, the ID wakeup enable is bit 24.
> > > > > 
> > > > > Yes, ID interrupt (IDIE) is set.
> > > > > 
> > > > > I noticed this backtrace in the kernel bootlog, but this only happens
> > > > > if the dr_mode="otg" , it comes from the host-mode irq handler :
> > > > > 
> > > > > [    2.757563] irq 238: nobody cared (try booting with the "irqpoll"
> > > > > option) [    2.764398] CPU: 0 PID: 1 Comm: swapper Not tainted
> > > > > 3.10.0- next-20130711-00013-g011c4b3-dirty #703
> > > > > [    2.773445] [<80013878>] (unwind_backtrace+0x0/0xe8) from
> > > > > [<80011644>] (show_stack+0x10/0x14)
> > > > > [    2.782027] [<80011644>] (show_stack+0x10/0x14) from [<800659f4>]
> > > > > (__report_bad_irq.isra.6+0x20/0xe0)
> > > > > [    2.791286] [<800659f4>] (__report_bad_irq.isra.6+0x20/0xe0) from
> > > > > [<80065c98>] (note_interrupt+0x16c/0x230)
> > > > > [    2.801063] [<80065c98>] (note_interrupt+0x16c/0x230) from
> > > > > [<80064000>] (handle_irq_event_percpu+0x10c/0x1a4)
> > > > > [    2.811010] [<80064000>] (handle_irq_event_percpu+0x10c/0x1a4)
> > > > > from [<800640e8>] (handle_irq_event+0x50/0x78)
> > > > > [    2.820958] [<800640e8>] (handle_irq_event+0x50/0x78) from
> > > > > [<8006652c>] (handle_level_irq+0x88/0x10c)
> > > > > [    2.830210] [<8006652c>] (handle_level_irq+0x88/0x10c) from
> > > > > [<800638d0>] (generic_handle_irq+0x28/0x3c)
> > > > > [    2.839637] [<800638d0>] (generic_handle_irq+0x28/0x3c) from
> > > > > [<8000f84c>] (handle_IRQ+0x30/0x84)
> > > > > [    2.848461] [<8000f84c>] (handle_IRQ+0x30/0x84) from [<80012160>]
> > > > > (__irq_svc+0x40/0x6c)
> > > > > [    2.856510] [<80012160>] (__irq_svc+0x40/0x6c) from [<80022a44>]
> > > > > (__do_softirq+0x90/0x1d8)
> > > > > [    2.864812] [<80022a44>] (__do_softirq+0x90/0x1d8) from
> > > > > [<80022edc>] (irq_exit+0x98/0xd4)
> > > > > [    2.873025] [<80022edc>] (irq_exit+0x98/0xd4) from [<8000f850>]
> > > > > (handle_IRQ+0x34/0x84)
> > > > > [    2.880980] [<8000f850>] (handle_IRQ+0x34/0x84) from [<80012160>]
> > > > > (__irq_svc+0x40/0x6c)
> > > > > [    2.889020] [<80012160>] (__irq_svc+0x40/0x6c) from [<8001d724>]
> > > > > (vprintk_emit+0x1bc/0x524)
> > > > > [    2.897411] [<8001d724>] (vprintk_emit+0x1bc/0x524) from
> > > > > [<804da5a4>] (printk+0x30/0x40)
> > > > > [    2.905551] [<804da5a4>] (printk+0x30/0x40) from [<80630138>]
> > > > > (mousedev_init+0x4c/0x60)
> > > > > [    2.913617] [<80630138>] (mousedev_init+0x4c/0x60) from
> > > > > [<806178fc>] (do_one_initcall+0x94/0x14c)
> > > > > [    2.922537] [<806178fc>] (do_one_initcall+0x94/0x14c) from
> > > > > [<80617b20>] (kernel_init_freeable+0x16c/0x22c)
> > > > > [    2.932230] [<80617b20>] (kernel_init_freeable+0x16c/0x22c) from
> > > > > [<804d8cbc>] (kernel_init+0x8/0x150)
> > > > > [    2.941486] [<804d8cbc>] (kernel_init+0x8/0x150) from [<8000ea70>]
> > > > > (ret_from_fork+0x14/0x24)
> > > > > [    2.949932] handlers:
> > > > > [    2.952227] [<8033fc58>] ci_irq
> > > > > [    2.955388] Disabling IRQ #238
> > > > 
> > > > Marek, I have a test at imx28evk (Freescale imx28evk) for this
> > > > patchset, it works well for dual-role switch after adding below dts
> > > > change. There is a kernel dump when works at udc mode(due to enable
> > > > CONFIG_LOCKUP_DETECTOR), at the first connect, but it does not affect
> > > > function, it should be a common chipidea problem, I will check later.
> > > 
> > > Sorry for the long delay. I finally got further with this, at least now I
> > > can switch Periph->Host again, but if I do so the other way around
> > > (unplug host adapter and plug computer cable) and dump the controller
> > > registers, I still see the controller in "host" (according to USBMODE
> > > register) mode. The controller stays in HOST mode even if I force it to
> > > gadget mode by writing "gadget" into debugfs "role" entry. I will keep
> > > poking.
> > > 
> > > In the meantime, I guess if it works on the EVK, it might be a hardware
> > > error so I better stop stalling you. I'll drop you an email if I find
> > > what this problem is.
> > 
> > No, the problem is you did not config the USB OTG ID pin.
> > Do the same thing I have done at imx28evk, you probably will work
> > if the ID pin is the same at your board.
> 
> That one I have configured, exactly the same way you did (except that mine is 
> MX28_PAD_PWM2__USB0_ID).
> 
> If it was the OTG ID pin issue, would the manual switching not work ?
> 

I can't see at your imx28-m28evk.dts, besides, make sure this pin can be
configed as USB OTG ID pin, and fsl,pull-up = <1>. Since you are still
at host mode, I suspect it is the ID problem.
You can check if there is ID INT when unplug out B-to-A cable.

I have not tried the manual switching, but first, you need to close your
vbus supply.

-- 

Best Regards,
Peter Chen



From kgene at kernel.org  Sun Jul 21 21:55:39 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Mon, 22 Jul 2013 10:55:39 +0900
Subject: [PATCH v4 00/20] Samsung PWM support cleanup
In-Reply-To: <9102768.ef8LAvpunv@flatron>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <51EC5F18.8040007@gmail.com> <9102768.ef8LAvpunv@flatron>
Message-ID: <0ab601ce867e$90b95770$b22c0650$@org>

Tomasz Figa wrote:
> 
> On Monday 22 of July 2013 00:22:16 Sylwester Nawrocki wrote:
> > On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> > > Since we now have a proper Samsung PWM clocksource driver in place,
> > > we can proceed with further cleanup of PWM timers support on Samsung
> > > SoCs.>
> > > This series attempts to achieve this goal by:
> > >   1) fixing up few things in samsung_pwm_timer clocksource driver,
> > >   2) moving remaining Samsung platforms to the new clocksource driver,
> > >   3) removing old clocksource driver,
> > >   4) adding new multiplatform- and DT-aware PWM driver,
> > >   5) moving all Samsung platforms to use the new PWM driver,
> > >   6) removing old PWM driver,
> > >   7) removing all PWM-related code that is not used anymore.
> > >
> > > Cleaning up the PWM driver is a bit tricky, because the design of
> > > current driver makes it completely unsuitable for DT and
> > > multiplatform and would require a heavy rework to make it usable,
> > > breaking any existing Samsung PWM users by the way. To avoid any
> > > breakage this series first renames the old driver, then adds new one
> > > using original name, migrates all platforms to use it and then
> > > finally removes the old driver.
> > >
> > > See particular patches for more detailed descriptions.
> > >
> > > [On S3C6410-based Tiny6410 (Mini6410-compatible) with pwm-beeper,
> > > SMDK6410 with PWM backlight and Exynos4210-based Origen board (with
> > > PWM0 attached to a scope)]
> > > Tested-by: Tomasz Figa<tomasz.figa at gmail.com>
> > >
> > > [On S3C2440-based Mini2440 board]
> > > Tested-by: Sylwester Nawrocki<sylvester.nawrocki at gmail.com>
> >
> > I have retested this series on top of v3.11-rc1 with pwm-backlight (and
> > buzzer
> > as the output :)) on Mini2440. It seems to work well - generated
> > frequencies are correct. I'll check pulse widths with a scope tomorrow,
> > as it's a bit late
> > now. FWIW you can add to this series my:
> >
> > Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> 
> Thanks. I hope we can finally get this series merged soon.
> 
Yes, this whole patches look good to me, and I'd like to take this whole
patches into the samsung tree...but need to get any response from PWM guy,
Thierry Reding. Let's wait for his response...

Thanks,
Kukjin



From kgene at kernel.org  Sun Jul 21 22:01:32 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Mon, 22 Jul 2013 11:01:32 +0900
Subject: [PATCH v4 00/20] Samsung PWM support cleanup
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <51EC5F18.8040007@gmail.com> <9102768.ef8LAvpunv@flatron>
Message-ID: <0ac901ce867f$638a7530$2a9f5f90$@org>

Kukjin Kim wrote:
> 
> Tomasz Figa wrote:
> >
> > On Monday 22 of July 2013 00:22:16 Sylwester Nawrocki wrote:
> > > On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> > > > Since we now have a proper Samsung PWM clocksource driver in place,
> > > > we can proceed with further cleanup of PWM timers support on Samsung
> > > > SoCs.>
> > > > This series attempts to achieve this goal by:
> > > >   1) fixing up few things in samsung_pwm_timer clocksource driver,
> > > >   2) moving remaining Samsung platforms to the new clocksource
> driver,
> > > >   3) removing old clocksource driver,
> > > >   4) adding new multiplatform- and DT-aware PWM driver,
> > > >   5) moving all Samsung platforms to use the new PWM driver,
> > > >   6) removing old PWM driver,
> > > >   7) removing all PWM-related code that is not used anymore.
> > > >
> > > > Cleaning up the PWM driver is a bit tricky, because the design of
> > > > current driver makes it completely unsuitable for DT and
> > > > multiplatform and would require a heavy rework to make it usable,
> > > > breaking any existing Samsung PWM users by the way. To avoid any
> > > > breakage this series first renames the old driver, then adds new one
> > > > using original name, migrates all platforms to use it and then
> > > > finally removes the old driver.
> > > >
> > > > See particular patches for more detailed descriptions.
> > > >
> > > > [On S3C6410-based Tiny6410 (Mini6410-compatible) with pwm-beeper,
> > > > SMDK6410 with PWM backlight and Exynos4210-based Origen board (with
> > > > PWM0 attached to a scope)]
> > > > Tested-by: Tomasz Figa<tomasz.figa at gmail.com>
> > > >
> > > > [On S3C2440-based Mini2440 board]
> > > > Tested-by: Sylwester Nawrocki<sylvester.nawrocki at gmail.com>
> > >
> > > I have retested this series on top of v3.11-rc1 with pwm-backlight
> (and
> > > buzzer
> > > as the output :)) on Mini2440. It seems to work well - generated
> > > frequencies are correct. I'll check pulse widths with a scope
tomorrow,
> > > as it's a bit late
> > > now. FWIW you can add to this series my:
> > >
> > > Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> >
> > Thanks. I hope we can finally get this series merged soon.
> >
> Yes, this whole patches look good to me, and I'd like to take this whole
> patches into the samsung tree...but need to get any response from PWM guy,
> Thierry Reding. Let's wait for his response...
> 
To be clarify, because his ack was on v3 and I remember he had a comment. So
would be better if we could get his ack on pwm change again.

Thanks,
Kukjin



From sachin.kamat at linaro.org  Sun Jul 21 22:59:02 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Mon, 22 Jul 2013 08:29:02 +0530
Subject: [PATCH 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <0ab301ce867d$9078c170$b16a4450$%kim@samsung.com>
References: <1372054438-15693-1-git-send-email-sachin.kamat@linaro.org>
 <0ab301ce867d$9078c170$b16a4450$%kim@samsung.com>
Message-ID: <CAK9yfHzmF_oxc3DsuT5wtXX2C5O+wLxz4C2Ps3cVPnKLb8jOEw@mail.gmail.com>

On 22 July 2013 07:18, Kukjin Kim <kgene.kim at samsung.com> wrote:
> Sachin Kamat wrote:
>>
>> With the recent cleanup in Exynos platform code notably commits
>> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
>> more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
>> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
>> Exynos4412 which have more (285) than the default number of GPIOs (255).
>> Thus define this number in Kconfig file. Without this patch we get the
>> following errors during boot:
>>
>> gpiochip_add: gpios 251..258 (gpv0) failed to register
>> samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
>> error code: -22
>> samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
>> Cc: Tomasz Figa <t.figa at samsung.com>
>> ---
>> Based on Kukjin's for-next tree.
>> ---
>>  arch/arm/Kconfig |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index ddf2667..380a53b 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1578,6 +1578,7 @@ config ARCH_NR_GPIO
>>       default 512 if SOC_OMAP5
>>       default 392 if ARCH_U8500
>>       default 352 if ARCH_VT8500
>> +     default 288 if ARCH_EXYNOS
>>       default 288 if ARCH_SUNXI
>>       default 264 if MACH_H4700
>>       default 0
>> --
>> 1.7.9.5
>
> Hmm, BTW, I'm wondering why it is 288 not 285 or other specific number...

I wasn't really sure if we can have any number there. I chose the
closest one (288) which was already used by other platform.
If there is no problem to use 285 itself then I can resend with that
number. Please let me know.


-- 
With warm regards,
Sachin


From josephl at nvidia.com  Sun Jul 21 23:15:16 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Mon, 22 Jul 2013 11:15:16 +0800
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <51E91A72.6070708@linaro.org>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
 <51E6FF0B.5000708@wwwdotorg.org>
 <1374145726.5610.73.camel@jlo-ubuntu-64.nvidia.com>
 <51E7E27B.9090605@linaro.org>
 <1374218064.24607.1.camel@jlo-ubuntu-64.nvidia.com>
 <51E91A72.6070708@linaro.org>
Message-ID: <1374462916.15946.14.camel@jlo-ubuntu-64.nvidia.com>

On Fri, 2013-07-19 at 18:52 +0800, Daniel Lezcano wrote:
> On 07/19/2013 09:14 AM, Joseph Lo wrote:
> > On Thu, 2013-07-18 at 20:41 +0800, Daniel Lezcano wrote:
> >> On 07/18/2013 01:08 PM, Joseph Lo wrote:
> >>> On Thu, 2013-07-18 at 04:31 +0800, Stephen Warren wrote:
> >>>> On 07/17/2013 04:15 AM, Joseph Lo wrote:
> >>>>> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
> >>>>>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
> >>>>>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
> >>>>>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
> >>>>>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
> >>>>>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
> >>>>>>>>> this state.
> >>>> ... [ discussion of issues with Joesph's patches applied]
> >>>>>
> >>>>> OK. I did more stress tests last night and today. I found it cause by
> >>>>> the patch "ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag" and
> >>>>> only impact the Tegra20 platform. The hot plug regression seems due to
> >>>>> this patch. After dropping this patch on top of v3.11-rc1, the Tegra20
> >>>>> can back to normal.
> >>>>>
> >>>>> And the hop plug and suspend stress test can pass on Tegra30/114 too.
> >>>>>
> >>>>> Can the other two patch series for Tegra114 to support CPU idle power
> >>>>> down mode and system suspend still moving forward, not be blocked by
> >>>>> this patch?
> >>>>>
> >>>>> Looks the CPUIDLE_FLAG_TIMER_STOP flag still cause some other issue for
> >>>>> hot plug on Tegra20, I will continue to check this. You can just drop
> >>>>> this patch.
> >>>>
> >>>> OK, if I drop that patch, then everything on Tegra20 and Tegra30 seems
> >>>> fine again.
> >>>>
> >>>> However, I've found some new and exciting issue on Tegra114!
> >>>>
> >>>> With unmodified v3.11-rc1, I can do the following without issue:
> >>>>
> >>>> * Unplug/replug CPUs, so that I had all combinations of CPU 1, 2, 3
> >>>> plugged/unpplugged (with CPU 0 always plugged).
> >>>>
> >>>> * Unplug/replug CPUs, so that I had all combinations of CPU 0, 1, 2, 3
> >>>> plugged/unpplugged (with the obvious exception of never having all CPUs
> >>>> unplugged).
> >>>>
> >>>> However, if I try this with your Tegra114 cpuidle and suspend patches
> >>>> applied, I see the following issues:
> >>>>
> >>>> 1) If I boot, unplug CPU 0, then replug CPU 0, the system immediately
> >>>> hard-hangs.
> >>>>
> >>> Sorry, I didn't apply the hotplug stress test on CPU0 too much. Because
> >>> all of our use cases and stress tests are focused on secondary CPUs
> >>> only.
> >>>
> >>> After doing some tests, here is my summary. This issue happens after we
> >>> support CPU idle power-down mode and relates to PMC or flow controller I
> >>> believe.
> >>>
> >>> i) on top of v3.11-rc1 (only support WFI in CPU idle)
> >>> When hot unplug CPU0, the PMC can power gate and put it into reset
> >>> state. This is what I expect and also true on all the other secondary
> >>> CPUs. The flow controller can maintain the CPU power state machine as
> >>> what we want.
> >>>
> >>> ii) on top of v3.11-rc1 + CPU idle power down mode support
> >>> a) I saw most of the time the CPU0,1,2,3 were in power down and reset
> >>> status. That means the idle power down mode works fine.
> >>>
> >>> b) Testing with the CPU hotplug stress test with the secondary CPUs (not
> >>> include CPU0), the result is good too.
> >>>
> >>> c) Testing hot plug on CPU0 with CPUIDLE_FLAG_TIMER_STOP apply or not
> >>> apply (Note 1), the result shows not good to me. The CPU0 have already
> >>> gone into WFI and the flow controller is set as WAITFOREVENT mode. But
> >>> the PMC always can't power gate CPU0 and sometimes can put it into
> >>> reset, but sometimes can't. That's why you can see it hanging after
> >>> unplug CPU0 sometimes.
> >>
> >> Are sure coupled idle state support hotplug and especially the cpu0
> >> hotplug ?
> > 
> > Tegra114 didn't use coupled idle framework.
> 
> Ok, so the problem occurs with the CPUIDLE_FLAG_TIMER_STOP flag only on
> tegra114, right ?
> 
> Sorry, I am a bit lost :)
> 
Here are the issues that happen after apply CPUIDLE_FLAG_TIMER_STOP.
1) Tegra114/30
The warning message at kernel/time/tick-broadcast.c:667
tick_broadcast_oneshot_control could be triggered when doing CPU hot
plug stress test.

2) Tegra20
The system is easy to stick or become lag.
The CPU hot plug is easy to cause system stick too.

The fix I suggested in another mail looks can fix all the issues above.
I verified it again today on 3 different Tegra SoC platforms.

Thanks,
Joseph




From gang.chen at asianux.com  Sun Jul 21 23:20:12 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Mon, 22 Jul 2013 11:20:12 +0800
Subject: [PATCH] ARM(64): KVM: add signed type cast for comparation
Message-ID: <51ECA4EC.3000408@asianux.com>

'len' is 'unsigned long' which is never less than zero.

So need a related type cast for comparation.

The related warning (when building ARM64 with allmodconfig):

  arch/arm64/kvm/../../../arch/arm/kvm/mmio.c:82:2: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]


Signed-off-by: Chen Gang <gang.chen at asianux.com>
---
 arch/arm/kvm/mmio.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
index b8e06b7..626dfc8 100644
--- a/arch/arm/kvm/mmio.c
+++ b/arch/arm/kvm/mmio.c
@@ -79,7 +79,7 @@ static int decode_hsr(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	}
 
 	len = kvm_vcpu_dabt_get_as(vcpu);
-	if (unlikely(len < 0))
+	if (unlikely((long)len < 0))
 		return len;
 
 	is_write = kvm_vcpu_dabt_iswrite(vcpu);
-- 
1.7.7.6


From kgene.kim at samsung.com  Sun Jul 21 23:33:05 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Mon, 22 Jul 2013 12:33:05 +0900
Subject: [PATCH 5/8] ARM: S3C64XX: move cpuidle driver to drivers/cpuidle/
References: <1372241747-21083-1-git-send-email-b.zolnierkie@samsung.com>
 <1372241747-21083-6-git-send-email-b.zolnierkie@samsung.com>
Message-ID: <0ad501ce868c$2d9d9ad0$88d8d070$%kim@samsung.com>

Kukjin Kim wrote:
> 
Re-sending due to e-mail client problem :-(

> Bartlomiej Zolnierkiewicz wrote:
> >
> > While at it:
> > - remove file path from comment
> >
> > Compile tested only.
> >
> > Cc: Ben Dooks <ben-linux at fluff.org>
> > Cc: Kukjin Kim <kgene.kim at samsung.com>
> > Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
> > Cc: "Rafael J. Wysocki" <rjw at sisk.pl>
> > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
> > ---
> >  arch/arm/mach-s3c64xx/Makefile    |  1 -
> >  arch/arm/mach-s3c64xx/cpuidle.c   | 63
---------------------------------
> --
> > ----
> >  drivers/cpuidle/Makefile          |  3 ++
> >  drivers/cpuidle/cpuidle-s3c64xx.c | 62
> > ++++++++++++++++++++++++++++++++++++++
> >  4 files changed, 65 insertions(+), 64 deletions(-)
> >  delete mode 100644 arch/arm/mach-s3c64xx/cpuidle.c
> >  create mode 100644 drivers/cpuidle/cpuidle-s3c64xx.c
> >
> Please see below with using '-M'.
> 
> --------8<-------------------------------8<--------
> obj-$(CONFIG_PM)		+= pm.o irq-pm.o sleep.o
> -obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
> 
>  # DMA support
> 
> diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/drivers/cpuidle/cpuidle-
> s3c64xx.c
> similarity index 92%
> rename from arch/arm/mach-s3c64xx/cpuidle.c
> rename to drivers/cpuidle/cpuidle-s3c64xx.c
> index 3c8ab07..c18d075 100644
> --- a/arch/arm/mach-s3c64xx/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle-s3c64xx.c
> @@ -1,5 +1,4 @@
> -/* linux/arch/arm/mach-s3c64xx/cpuidle.c
> - *
> +/*
>   * Copyright (c) 2011 Wolfson Microelectronics, plc
>   * Copyright (c) 2011 Samsung Electronics Co., Ltd.
>   *		http://www.samsung.com
> @@ -20,8 +19,8 @@
> 
>  #include <mach/map.h>
> 
> -#include "regs-sys.h"
> -#include "regs-syscon-power.h"
> +#include "../../arch/arm/mach-s3c64xx/regs-sys.h"
> +#include "../../arch/arm/mach-s3c64xx/regs-syscon-power.h"
> 
>  static int s3c64xx_enter_idle(struct cpuidle_device *dev,
>  			      struct cpuidle_driver *drv,
> --------8<-------------------------------8<--------
> 
> Would be helpful to check which codes have been changed...
> 
> Need to sort out above inclusions...
> 
> > diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-
> > s3c64xx/Makefile
> > index 31d0c91..e7a3ee7 100644
> > --- a/arch/arm/mach-s3c64xx/Makefile
> > +++ b/arch/arm/mach-s3c64xx/Makefile
> > @@ -22,7 +22,6 @@ obj-$(CONFIG_CPU_S3C6410)	+= s3c6410.o
> >  # PM
> >
> >  obj-$(CONFIG_PM)		+= pm.o irq-pm.o sleep.o
> > -obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
> >
> >  # DMA support
> >
> > diff --git a/arch/arm/mach-s3c64xx/cpuidle.c b/arch/arm/mach-
> > s3c64xx/cpuidle.c
> > deleted file mode 100644
> > index 3c8ab07..0000000
> > --- a/arch/arm/mach-s3c64xx/cpuidle.c
> > +++ /dev/null
> 
> [...]
> 
> > diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
> > index 6436c67..eed221e 100644
> > --- a/drivers/cpuidle/Makefile
> > +++ b/drivers/cpuidle/Makefile
> > @@ -31,4 +31,7 @@ ifeq ($(CONFIG_ARCH_OMAP4),y)
> >  	ccflags-y += -I$(srctree)/arch/arm/mach-omap2/include
> >  	obj-y += cpuidle-omap44xx.o
> >  endif
> > +ifeq ($(CONFIG_ARCH_S3C64XX),y)
> > +	obj-y += cpuidle-s3c64xx.o
> > +endif
> 
> I think, adding CONFIG_CPU_IDLE_S3C64XX like others, Calexeda, Zynq is
> better...?
> 
> >  obj-$(CONFIG_CPU_IDLE_ZYNQ) += cpuidle-zynq.o
> > diff --git a/drivers/cpuidle/cpuidle-s3c64xx.c
> b/drivers/cpuidle/cpuidle-
> > s3c64xx.c
> > new file mode 100644
> > index 0000000..c18d075
> > --- /dev/null
> > +++ b/drivers/cpuidle/cpuidle-s3c64xx.c
> 
> [...]
> 
> > --
> > 1.8.2.3
> 
> Thanks,
> Kukjin



From kgene at kernel.org  Sun Jul 21 23:37:52 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Mon, 22 Jul 2013 12:37:52 +0900
Subject: [PATCH 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <CAK9yfHzmF_oxc3DsuT5wtXX2C5O+wLxz4C2Ps3cVPnKLb8jOEw@mail.gmail.com>
References: <1372054438-15693-1-git-send-email-sachin.kamat@linaro.org>
 <0ab301ce867d$9078c170$b16a4450$%kim@samsung.com>
 <CAK9yfHzmF_oxc3DsuT5wtXX2C5O+wLxz4C2Ps3cVPnKLb8jOEw@mail.gmail.com>
Message-ID: <0ad601ce868c$d88bff40$89a3fdc0$@org>

Sachin Kamat wrote:
> 
> On 22 July 2013 07:18, Kukjin Kim <kgene.kim at samsung.com> wrote:
> > Sachin Kamat wrote:
> >>
> >> With the recent cleanup in Exynos platform code notably commits
> >> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
> >> more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
> >> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs
> like
> >> Exynos4412 which have more (285) than the default number of GPIOs
(255).
> >> Thus define this number in Kconfig file. Without this patch we get the
> >> following errors during boot:
> >>
> >> gpiochip_add: gpios 251..258 (gpv0) failed to register
> >> samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
> >> error code: -22
> >> samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
> >>
> >> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> >> Cc: Tomasz Figa <t.figa at samsung.com>
> >> ---
> >> Based on Kukjin's for-next tree.
> >> ---
> >>  arch/arm/Kconfig |    1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> index ddf2667..380a53b 100644
> >> --- a/arch/arm/Kconfig
> >> +++ b/arch/arm/Kconfig
> >> @@ -1578,6 +1578,7 @@ config ARCH_NR_GPIO
> >>       default 512 if SOC_OMAP5
> >>       default 392 if ARCH_U8500
> >>       default 352 if ARCH_VT8500
> >> +     default 288 if ARCH_EXYNOS
> >>       default 288 if ARCH_SUNXI
> >>       default 264 if MACH_H4700
> >>       default 0
> >> --
> >> 1.7.9.5
> >
> > Hmm, BTW, I'm wondering why it is 288 not 285 or other specific
number...
> 
> I wasn't really sure if we can have any number there. I chose the
> closest one (288) which was already used by other platform.
> If there is no problem to use 285 itself then I can resend with that
> number. Please let me know.
> 
If there is no reason, please don't use bigger value than necessary one.

Thanks,
Kukjin



From sachin.kamat at linaro.org  Sun Jul 21 23:40:55 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Mon, 22 Jul 2013 09:10:55 +0530
Subject: [PATCH 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <0ad601ce868c$d88bff40$89a3fdc0$@org>
References: <1372054438-15693-1-git-send-email-sachin.kamat@linaro.org>
 <0ab301ce867d$9078c170$b16a4450$%kim@samsung.com>
 <CAK9yfHzmF_oxc3DsuT5wtXX2C5O+wLxz4C2Ps3cVPnKLb8jOEw@mail.gmail.com>
 <0ad601ce868c$d88bff40$89a3fdc0$@org>
Message-ID: <CAK9yfHxq2ggVe9=_OVPa_KXN4HBed1_AwFQ3C_-Jxgzg6y1Pnw@mail.gmail.com>

On 22 July 2013 09:07, Kukjin Kim <kgene at kernel.org> wrote:
> Sachin Kamat wrote:
>>
>> On 22 July 2013 07:18, Kukjin Kim <kgene.kim at samsung.com> wrote:
>> > Sachin Kamat wrote:
>> >>
>> >> With the recent cleanup in Exynos platform code notably commits
>> >> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
>> >> more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
>> >> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs
>> like
>> >> Exynos4412 which have more (285) than the default number of GPIOs
> (255).
>> >> Thus define this number in Kconfig file. Without this patch we get the
>> >> following errors during boot:
>> >>
>> >> gpiochip_add: gpios 251..258 (gpv0) failed to register
>> >> samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
>> >> error code: -22
>> >> samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
>> >>
>> >> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
>> >> Cc: Tomasz Figa <t.figa at samsung.com>
>> >> ---
>> >> Based on Kukjin's for-next tree.
>> >> ---
>> >>  arch/arm/Kconfig |    1 +
>> >>  1 file changed, 1 insertion(+)
>> >>
>> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> >> index ddf2667..380a53b 100644
>> >> --- a/arch/arm/Kconfig
>> >> +++ b/arch/arm/Kconfig
>> >> @@ -1578,6 +1578,7 @@ config ARCH_NR_GPIO
>> >>       default 512 if SOC_OMAP5
>> >>       default 392 if ARCH_U8500
>> >>       default 352 if ARCH_VT8500
>> >> +     default 288 if ARCH_EXYNOS
>> >>       default 288 if ARCH_SUNXI
>> >>       default 264 if MACH_H4700
>> >>       default 0
>> >> --
>> >> 1.7.9.5
>> >
>> > Hmm, BTW, I'm wondering why it is 288 not 285 or other specific
> number...
>>
>> I wasn't really sure if we can have any number there. I chose the
>> closest one (288) which was already used by other platform.
>> If there is no problem to use 285 itself then I can resend with that
>> number. Please let me know.
>>
> If there is no reason, please don't use bigger value than necessary one.

Ok, I will resend this with exact value.
Thanks Kukjin.



-- 
With warm regards,
Sachin


From gang.chen at asianux.com  Sun Jul 21 23:40:38 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Mon, 22 Jul 2013 11:40:38 +0800
Subject: [PATCH] ARM64: include: asm: use 'int' instead of 'u32' for variable
 'target' in kvm_host.h.
Message-ID: <51ECA9B6.3010808@asianux.com>

'target' will be set to '-1' in kvm_arch_vcpu_init(), and it need check
'target' whether less than zero or not in kvm_vcpu_initialized().

So need define target as 'int' instead of 'u32', just like ARM has done.


The related warning:

  arch/arm64/kvm/../../../arch/arm/kvm/arm.c:497:2: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]

Signed-off-by: Chen Gang <gang.chen at asianux.com>
---
 arch/arm64/include/asm/kvm_host.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 644d739..0859a4d 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -129,7 +129,7 @@ struct kvm_vcpu_arch {
 	struct kvm_mmu_memory_cache mmu_page_cache;
 
 	/* Target CPU and feature flags */
-	u32 target;
+	int target;
 	DECLARE_BITMAP(features, KVM_VCPU_MAX_FEATURES);
 
 	/* Detect first run of a vcpu */
-- 
1.7.7.6


From daniel.lezcano at linaro.org  Sun Jul 21 23:50:09 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Jul 2013 05:50:09 +0200
Subject: [PATCH v4 02/20] clocksource: samsung_pwm_timer: Correct
 definition of AUTORELOAD bit
In-Reply-To: <1374278673-25615-4-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-4-git-send-email-tomasz.figa@gmail.com>
Message-ID: <51ECABF1.4040600@linaro.org>

On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> PWM channel 4 has its autoreload bit located at different position. This
> patch fixes the driver to account for that.
> 
> This fixes a problem with the clocksource hanging after it overflows because
> it is not reloaded any more.
> 
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> ---
>  drivers/clocksource/samsung_pwm_timer.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
> index 3fa5b07..e238fb0 100644
> --- a/drivers/clocksource/samsung_pwm_timer.c
> +++ b/drivers/clocksource/samsung_pwm_timer.c
> @@ -47,7 +47,8 @@
>  #define TCON_START(chan)		(1 << (4 * (chan) + 0))
>  #define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
>  #define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
> -#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
> +#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) \
> +						+ (((chan) < 5) ? 3 : 2)))

This macro is not readable. Please, fix it up with a comment please.

>  
>  DEFINE_SPINLOCK(samsung_pwm_lock);
>  EXPORT_SYMBOL(samsung_pwm_lock);
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Sun Jul 21 23:56:16 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Jul 2013 05:56:16 +0200
Subject: [PATCH v4 04/20] clocksource: samsung_pwm_timer: Do not use
 clocksource_mmio
In-Reply-To: <1374278673-25615-6-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-6-git-send-email-tomasz.figa@gmail.com>
Message-ID: <51ECAD60.1000109@linaro.org>

On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> In case of Samsung PWM timer, clocksource MMIO can not be used, because
> custom suspend/resume callbacks are required.
> 
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> ---

Reviewed-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Please in the future Cc me and Thomas Gleixner (clocksource/clockevent
maintainers).

Thanks
  -- Daniel

>  drivers/clocksource/Kconfig             |  1 -
>  drivers/clocksource/samsung_pwm_timer.c | 19 +++++++++++++++----
>  2 files changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index b7b9b04..41c6946 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -99,7 +99,6 @@ config CLKSRC_EXYNOS_MCT
>  
>  config CLKSRC_SAMSUNG_PWM
>  	bool
> -	select CLKSRC_MMIO
>  	help
>  	  This is a new clocksource driver for the PWM timer found in
>  	  Samsung S3C, S5P and Exynos SoCs, replacing an earlier driver
> diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
> index 823279b..753ffec 100644
> --- a/drivers/clocksource/samsung_pwm_timer.c
> +++ b/drivers/clocksource/samsung_pwm_timer.c
> @@ -288,6 +288,18 @@ static void __init samsung_clockevent_init(void)
>  	}
>  }
>  
> +static cycle_t samsung_clocksource_read(struct clocksource *c)
> +{
> +	return ~readl_relaxed(pwm.source_reg);
> +}
> +
> +static struct clocksource samsung_clocksource = {
> +	.name		= "samsung_clocksource_timer",
> +	.rating		= 250,
> +	.read		= samsung_clocksource_read,
> +	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
> +};
> +
>  /*
>   * Override the global weak sched_clock symbol with this
>   * local implementation which uses the clocksource to get some
> @@ -297,7 +309,7 @@ static void __init samsung_clockevent_init(void)
>   */
>  static u32 notrace samsung_read_sched_clock(void)
>  {
> -	return ~__raw_readl(pwm.source_reg);
> +	return samsung_clocksource_read(NULL);
>  }
>  
>  static void __init samsung_clocksource_init(void)
> @@ -324,9 +336,8 @@ static void __init samsung_clocksource_init(void)
>  	setup_sched_clock(samsung_read_sched_clock,
>  						pwm.variant.bits, clock_rate);
>  
> -	ret = clocksource_mmio_init(pwm.source_reg, "samsung_clocksource_timer",
> -					clock_rate, 250, pwm.variant.bits,
> -					clocksource_mmio_readl_down);
> +	samsung_clocksource.mask = CLOCKSOURCE_MASK(pwm.variant.bits);
> +	ret = clocksource_register_hz(&samsung_clocksource, clock_rate);
>  	if (ret)
>  		panic("samsung_clocksource_timer: can't register clocksource\n");
>  }
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Sun Jul 21 23:57:33 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Jul 2013 05:57:33 +0200
Subject: [PATCH v4 05/20] clocksource: samsung_pwm_timer: Handle
 suspend/resume correctly
In-Reply-To: <1374278673-25615-7-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-7-git-send-email-tomasz.figa@gmail.com>
Message-ID: <51ECADAD.3040303@linaro.org>

On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> Current suspend/resume handling of the driver was broken, because:
>  - periodic timer was being enabled in CLOCK_EVT_MODE_RESUME mode, which
>    does not seem to be correct behavior looking at other platforms,
>  - PWM divisors need to be restored, but they were not,
>  - clockevent interrupt mask needs to be restored, but it was not,
>  - clocksource was being restored in clockevent resume callback.
> 
> This patch fixes issues mentioned above, making suspend/resume handling
> in the driver correct.
> 
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> ---

Acked-by: Daniel Lezcano <daniel.lezcano at linaro.org>

>  drivers/clocksource/samsung_pwm_timer.c | 42 ++++++++++++++++++++++-----------
>  1 file changed, 28 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
> index 753ffec..282e0e2 100644
> --- a/drivers/clocksource/samsung_pwm_timer.c
> +++ b/drivers/clocksource/samsung_pwm_timer.c
> @@ -197,17 +197,6 @@ static int samsung_set_next_event(unsigned long cycles,
>  	return 0;
>  }
>  
> -static void samsung_timer_resume(void)
> -{
> -	/* event timer restart */
> -	samsung_time_setup(pwm.event_id, pwm.clock_count_per_tick - 1);
> -	samsung_time_start(pwm.event_id, true);
> -
> -	/* source timer restart */
> -	samsung_time_setup(pwm.source_id, pwm.tcnt_max);
> -	samsung_time_start(pwm.source_id, true);
> -}
> -
>  static void samsung_set_mode(enum clock_event_mode mode,
>  				struct clock_event_device *evt)
>  {
> @@ -224,20 +213,29 @@ static void samsung_set_mode(enum clock_event_mode mode,
>  
>  	case CLOCK_EVT_MODE_UNUSED:
>  	case CLOCK_EVT_MODE_SHUTDOWN:
> -		break;
> -
>  	case CLOCK_EVT_MODE_RESUME:
> -		samsung_timer_resume();
>  		break;
>  	}
>  }
>  
> +static void samsung_clockevent_resume(struct clock_event_device *cev)
> +{
> +	samsung_timer_set_prescale(pwm.event_id, pwm.tscaler_div);
> +	samsung_timer_set_divisor(pwm.event_id, pwm.tdiv);
> +
> +	if (pwm.variant.has_tint_cstat) {
> +		u32 mask = (1 << pwm.event_id);
> +		writel(mask | (mask << 5), pwm.base + REG_TINT_CSTAT);
> +	}
> +}
> +
>  static struct clock_event_device time_event_device = {
>  	.name		= "samsung_event_timer",
>  	.features	= CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
>  	.rating		= 200,
>  	.set_next_event	= samsung_set_next_event,
>  	.set_mode	= samsung_set_mode,
> +	.resume		= samsung_clockevent_resume,
>  };
>  
>  static irqreturn_t samsung_clock_event_isr(int irq, void *dev_id)
> @@ -288,6 +286,20 @@ static void __init samsung_clockevent_init(void)
>  	}
>  }
>  
> +static void samsung_clocksource_suspend(struct clocksource *cs)
> +{
> +	samsung_time_stop(pwm.source_id);
> +}
> +
> +static void samsung_clocksource_resume(struct clocksource *cs)
> +{
> +	samsung_timer_set_prescale(pwm.source_id, pwm.tscaler_div);
> +	samsung_timer_set_divisor(pwm.source_id, pwm.tdiv);
> +
> +	samsung_time_setup(pwm.source_id, pwm.tcnt_max);
> +	samsung_time_start(pwm.source_id, true);
> +}
> +
>  static cycle_t samsung_clocksource_read(struct clocksource *c)
>  {
>  	return ~readl_relaxed(pwm.source_reg);
> @@ -297,6 +309,8 @@ static struct clocksource samsung_clocksource = {
>  	.name		= "samsung_clocksource_timer",
>  	.rating		= 250,
>  	.read		= samsung_clocksource_read,
> +	.suspend	= samsung_clocksource_suspend,
> +	.resume		= samsung_clocksource_resume,
>  	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
>  };
>  
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Sun Jul 21 23:59:17 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Jul 2013 05:59:17 +0200
Subject: [PATCH v4 09/20] ARM: SAMSUNG: Move all platforms to new
 clocksource driver
In-Reply-To: <1374278673-25615-11-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-11-git-send-email-tomasz.figa@gmail.com>
Message-ID: <51ECAE15.4000507@linaro.org>

On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> This patch moves all Samsung platforms using PWM clocksource from legacy
> samsung-time to new samsung-pwm-timer driver.
> 
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> ---

Reviewed-by: Daniel Lezcano <daniel.lezcano at linaro.org>

>  arch/arm/Kconfig                | 10 +++++-----
>  arch/arm/mach-s3c24xx/Kconfig   |  6 ------
>  arch/arm/mach-s3c24xx/common.c  | 16 ++++++++++++++++
>  arch/arm/mach-s3c64xx/Kconfig   |  2 --
>  arch/arm/mach-s3c64xx/common.c  | 21 +++++++++++++++++----
>  arch/arm/mach-s5p64x0/Kconfig   |  2 --
>  arch/arm/mach-s5p64x0/common.c  | 17 +++++++++++++++++
>  arch/arm/mach-s5pc100/Kconfig   |  1 -
>  arch/arm/mach-s5pc100/common.c  | 17 +++++++++++++++++
>  arch/arm/mach-s5pv210/Kconfig   |  1 -
>  arch/arm/mach-s5pv210/common.c  | 17 +++++++++++++++++
>  arch/arm/plat-samsung/s5p-irq.c |  3 ---
>  12 files changed, 89 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index ba412e0..486ab0a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -700,7 +700,7 @@ config ARCH_S3C24XX
>  	select ARCH_HAS_CPUFREQ
>  	select ARCH_REQUIRE_GPIOLIB
>  	select CLKDEV_LOOKUP
> -	select CLKSRC_MMIO
> +	select CLKSRC_SAMSUNG_PWM
>  	select GENERIC_CLOCKEVENTS
>  	select GPIO_SAMSUNG
>  	select HAVE_CLK
> @@ -723,7 +723,7 @@ config ARCH_S3C64XX
>  	select ARCH_REQUIRE_GPIOLIB
>  	select ARM_VIC
>  	select CLKDEV_LOOKUP
> -	select CLKSRC_MMIO
> +	select CLKSRC_SAMSUNG_PWM
>  	select CPU_V6
>  	select GENERIC_CLOCKEVENTS
>  	select GPIO_SAMSUNG
> @@ -748,7 +748,7 @@ config ARCH_S3C64XX
>  config ARCH_S5P64X0
>  	bool "Samsung S5P6440 S5P6450"
>  	select CLKDEV_LOOKUP
> -	select CLKSRC_MMIO
> +	select CLKSRC_SAMSUNG_PWM
>  	select CPU_V6
>  	select GENERIC_CLOCKEVENTS
>  	select GPIO_SAMSUNG
> @@ -767,7 +767,7 @@ config ARCH_S5PC100
>  	bool "Samsung S5PC100"
>  	select ARCH_REQUIRE_GPIOLIB
>  	select CLKDEV_LOOKUP
> -	select CLKSRC_MMIO
> +	select CLKSRC_SAMSUNG_PWM
>  	select CPU_V7
>  	select GENERIC_CLOCKEVENTS
>  	select GPIO_SAMSUNG
> @@ -787,7 +787,7 @@ config ARCH_S5PV210
>  	select ARCH_HAS_HOLES_MEMORYMODEL
>  	select ARCH_SPARSEMEM_ENABLE
>  	select CLKDEV_LOOKUP
> -	select CLKSRC_MMIO
> +	select CLKSRC_SAMSUNG_PWM
>  	select CPU_V7
>  	select GENERIC_CLOCKEVENTS
>  	select GPIO_SAMSUNG
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index 6d9252e..b8ec0ec 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -30,7 +30,6 @@ config CPU_S3C2410
>  	select S3C2410_CLOCK
>  	select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ
>  	select S3C2410_PM if PM
> -	select SAMSUNG_HRT
>  	select SAMSUNG_WDT_RESET
>  	help
>  	  Support for S3C2410 and S3C2410A family from the S3C24XX line
> @@ -42,7 +41,6 @@ config CPU_S3C2412
>  	select CPU_LLSERIAL_S3C2440
>  	select S3C2412_DMA if S3C24XX_DMA
>  	select S3C2412_PM if PM
> -	select SAMSUNG_HRT
>  	help
>  	  Support for the S3C2412 and S3C2413 SoCs from the S3C24XX line
>  
> @@ -54,7 +52,6 @@ config CPU_S3C2416
>  	select S3C2443_COMMON
>  	select S3C2443_DMA if S3C24XX_DMA
>  	select SAMSUNG_CLKSRC
> -	select SAMSUNG_HRT
>  	help
>  	  Support for the S3C2416 SoC from the S3C24XX line
>  
> @@ -65,7 +62,6 @@ config CPU_S3C2440
>  	select S3C2410_CLOCK
>  	select S3C2410_PM if PM
>  	select S3C2440_DMA if S3C24XX_DMA
> -	select SAMSUNG_HRT
>  	help
>  	  Support for S3C2440 Samsung Mobile CPU based systems.
>  
> @@ -75,7 +71,6 @@ config CPU_S3C2442
>  	select CPU_LLSERIAL_S3C2440
>  	select S3C2410_CLOCK
>  	select S3C2410_PM if PM
> -	select SAMSUNG_HRT
>  	help
>  	  Support for S3C2442 Samsung Mobile CPU based systems.
>  
> @@ -91,7 +86,6 @@ config CPU_S3C2443
>  	select S3C2443_COMMON
>  	select S3C2443_DMA if S3C24XX_DMA
>  	select SAMSUNG_CLKSRC
> -	select SAMSUNG_HRT
>  	help
>  	  Support for the S3C2443 SoC from the S3C24XX line
>  
> diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
> index e5e7d7d..457261c 100644
> --- a/arch/arm/mach-s3c24xx/common.c
> +++ b/arch/arm/mach-s3c24xx/common.c
> @@ -245,6 +245,22 @@ void __init s3c24xx_init_io(struct map_desc *mach_desc, int size)
>  	samsung_pwm_set_platdata(&s3c24xx_pwm_variant);
>  }
>  
> +void __init samsung_set_timer_source(unsigned int event, unsigned int source)
> +{
> +	s3c24xx_pwm_variant.output_mask = BIT(SAMSUNG_PWM_NUM) - 1;
> +	s3c24xx_pwm_variant.output_mask &= ~(BIT(event) | BIT(source));
> +}
> +
> +void __init samsung_timer_init(void)
> +{
> +	unsigned int timer_irqs[SAMSUNG_PWM_NUM] = {
> +		IRQ_TIMER0, IRQ_TIMER1, IRQ_TIMER2, IRQ_TIMER3, IRQ_TIMER4,
> +	};
> +
> +	samsung_pwm_clocksource_init(S3C_VA_TIMER,
> +					timer_irqs, &s3c24xx_pwm_variant);
> +}
> +
>  /* Serial port registrations */
>  
>  #define S3C2410_PA_UART0      (S3C24XX_PA_UART)
> diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
> index 2057853..041da51 100644
> --- a/arch/arm/mach-s3c64xx/Kconfig
> +++ b/arch/arm/mach-s3c64xx/Kconfig
> @@ -17,13 +17,11 @@ config PLAT_S3C64XX
>  # Configuration options for the S3C6410 CPU
>  
>  config CPU_S3C6400
> -	select SAMSUNG_HRT
>  	bool
>  	help
>  	  Enable S3C6400 CPU support
>  
>  config CPU_S3C6410
> -	select SAMSUNG_HRT
>  	bool
>  	help
>  	  Enable S3C6410 CPU support
> diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
> index ca05e61..73d79cf 100644
> --- a/arch/arm/mach-s3c64xx/common.c
> +++ b/arch/arm/mach-s3c64xx/common.c
> @@ -43,7 +43,6 @@
>  #include <plat/pm.h>
>  #include <plat/gpio-cfg.h>
>  #include <plat/irq-uart.h>
> -#include <plat/irq-vic-timer.h>
>  #include <plat/pwm-core.h>
>  #include <plat/regs-irqtype.h>
>  #include <plat/regs-serial.h>
> @@ -158,6 +157,23 @@ static struct samsung_pwm_variant s3c64xx_pwm_variant = {
>  	.tclk_mask	= (1 << 7) | (1 << 6) | (1 << 5),
>  };
>  
> +void __init samsung_set_timer_source(unsigned int event, unsigned int source)
> +{
> +	s3c64xx_pwm_variant.output_mask = BIT(SAMSUNG_PWM_NUM) - 1;
> +	s3c64xx_pwm_variant.output_mask &= ~(BIT(event) | BIT(source));
> +}
> +
> +void __init samsung_timer_init(void)
> +{
> +	unsigned int timer_irqs[SAMSUNG_PWM_NUM] = {
> +		IRQ_TIMER0_VIC, IRQ_TIMER1_VIC, IRQ_TIMER2_VIC,
> +		IRQ_TIMER3_VIC, IRQ_TIMER4_VIC,
> +	};
> +
> +	samsung_pwm_clocksource_init(S3C_VA_TIMER,
> +					timer_irqs, &s3c64xx_pwm_variant);
> +}
> +
>  /* read cpu identification code */
>  
>  void __init s3c64xx_init_io(struct map_desc *mach_desc, int size)
> @@ -206,9 +222,6 @@ void __init s3c64xx_init_irq(u32 vic0_valid, u32 vic1_valid)
>  	/* initialise the pair of VICs */
>  	vic_init(VA_VIC0, IRQ_VIC0_BASE, vic0_valid, IRQ_VIC0_RESUME);
>  	vic_init(VA_VIC1, IRQ_VIC1_BASE, vic1_valid, IRQ_VIC1_RESUME);
> -
> -	/* add the timer sub-irqs */
> -	s3c_init_vic_timer_irq(5, IRQ_TIMER0);
>  }
>  
>  #define eint_offset(irq)	((irq) - IRQ_EINT(0))
> diff --git a/arch/arm/mach-s5p64x0/Kconfig b/arch/arm/mach-s5p64x0/Kconfig
> index 5a707bd..bb2111b 100644
> --- a/arch/arm/mach-s5p64x0/Kconfig
> +++ b/arch/arm/mach-s5p64x0/Kconfig
> @@ -11,14 +11,12 @@ config CPU_S5P6440
>  	bool
>  	select S5P_SLEEP if PM
>  	select SAMSUNG_DMADEV
> -	select SAMSUNG_HRT
>  	select SAMSUNG_WAKEMASK if PM
>  	help
>  	  Enable S5P6440 CPU support
>  
>  config CPU_S5P6450
>  	bool
> -	select SAMSUNG_HRT
>  	select S5P_SLEEP if PM
>  	select SAMSUNG_DMADEV
>  	select SAMSUNG_WAKEMASK if PM
> diff --git a/arch/arm/mach-s5p64x0/common.c b/arch/arm/mach-s5p64x0/common.c
> index 49687f2..42e14f2 100644
> --- a/arch/arm/mach-s5p64x0/common.c
> +++ b/arch/arm/mach-s5p64x0/common.c
> @@ -166,6 +166,23 @@ static struct samsung_pwm_variant s5p64x0_pwm_variant = {
>  	.tclk_mask	= 0,
>  };
>  
> +void __init samsung_set_timer_source(unsigned int event, unsigned int source)
> +{
> +	s5p64x0_pwm_variant.output_mask = BIT(SAMSUNG_PWM_NUM) - 1;
> +	s5p64x0_pwm_variant.output_mask &= ~(BIT(event) | BIT(source));
> +}
> +
> +void __init samsung_timer_init(void)
> +{
> +	unsigned int timer_irqs[SAMSUNG_PWM_NUM] = {
> +		IRQ_TIMER0_VIC, IRQ_TIMER1_VIC, IRQ_TIMER2_VIC,
> +		IRQ_TIMER3_VIC, IRQ_TIMER4_VIC,
> +	};
> +
> +	samsung_pwm_clocksource_init(S3C_VA_TIMER,
> +					timer_irqs, &s5p64x0_pwm_variant);
> +}
> +
>  /*
>   * s5p64x0_map_io
>   *
> diff --git a/arch/arm/mach-s5pc100/Kconfig b/arch/arm/mach-s5pc100/Kconfig
> index 2f456a4..15170be 100644
> --- a/arch/arm/mach-s5pc100/Kconfig
> +++ b/arch/arm/mach-s5pc100/Kconfig
> @@ -11,7 +11,6 @@ config CPU_S5PC100
>  	bool
>  	select S5P_EXT_INT
>  	select SAMSUNG_DMADEV
> -	select SAMSUNG_HRT
>  	help
>  	  Enable S5PC100 CPU support
>  
> diff --git a/arch/arm/mach-s5pc100/common.c b/arch/arm/mach-s5pc100/common.c
> index e0600af..c5a8eea 100644
> --- a/arch/arm/mach-s5pc100/common.c
> +++ b/arch/arm/mach-s5pc100/common.c
> @@ -141,6 +141,23 @@ static struct samsung_pwm_variant s5pc100_pwm_variant = {
>  	.tclk_mask	= (1 << 5),
>  };
>  
> +void __init samsung_set_timer_source(unsigned int event, unsigned int source)
> +{
> +	s5pc100_pwm_variant.output_mask = BIT(SAMSUNG_PWM_NUM) - 1;
> +	s5pc100_pwm_variant.output_mask &= ~(BIT(event) | BIT(source));
> +}
> +
> +void __init samsung_timer_init(void)
> +{
> +	unsigned int timer_irqs[SAMSUNG_PWM_NUM] = {
> +		IRQ_TIMER0_VIC, IRQ_TIMER1_VIC, IRQ_TIMER2_VIC,
> +		IRQ_TIMER3_VIC, IRQ_TIMER4_VIC,
> +	};
> +
> +	samsung_pwm_clocksource_init(S3C_VA_TIMER,
> +					timer_irqs, &s5pc100_pwm_variant);
> +}
> +
>  /*
>   * s5pc100_map_io
>   *
> diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
> index 0963283..caaedaf 100644
> --- a/arch/arm/mach-s5pv210/Kconfig
> +++ b/arch/arm/mach-s5pv210/Kconfig
> @@ -15,7 +15,6 @@ config CPU_S5PV210
>  	select S5P_PM if PM
>  	select S5P_SLEEP if PM
>  	select SAMSUNG_DMADEV
> -	select SAMSUNG_HRT
>  	help
>  	  Enable S5PV210 CPU support
>  
> diff --git a/arch/arm/mach-s5pv210/common.c b/arch/arm/mach-s5pv210/common.c
> index 306b29a..26027a2 100644
> --- a/arch/arm/mach-s5pv210/common.c
> +++ b/arch/arm/mach-s5pv210/common.c
> @@ -157,6 +157,23 @@ static struct samsung_pwm_variant s5pv210_pwm_variant = {
>  	.tclk_mask	= (1 << 5),
>  };
>  
> +void __init samsung_set_timer_source(unsigned int event, unsigned int source)
> +{
> +	s5pv210_pwm_variant.output_mask = BIT(SAMSUNG_PWM_NUM) - 1;
> +	s5pv210_pwm_variant.output_mask &= ~(BIT(event) | BIT(source));
> +}
> +
> +void __init samsung_timer_init(void)
> +{
> +	unsigned int timer_irqs[SAMSUNG_PWM_NUM] = {
> +		IRQ_TIMER0_VIC, IRQ_TIMER1_VIC, IRQ_TIMER2_VIC,
> +		IRQ_TIMER3_VIC, IRQ_TIMER4_VIC,
> +	};
> +
> +	samsung_pwm_clocksource_init(S3C_VA_TIMER,
> +					timer_irqs, &s5pv210_pwm_variant);
> +}
> +
>  /*
>   * s5pv210_map_io
>   *
> diff --git a/arch/arm/plat-samsung/s5p-irq.c b/arch/arm/plat-samsung/s5p-irq.c
> index ff1a760..6729cb2 100644
> --- a/arch/arm/plat-samsung/s5p-irq.c
> +++ b/arch/arm/plat-samsung/s5p-irq.c
> @@ -19,7 +19,6 @@
>  #include <mach/map.h>
>  #include <plat/regs-timer.h>
>  #include <plat/cpu.h>
> -#include <plat/irq-vic-timer.h>
>  
>  void __init s5p_init_irq(u32 *vic, u32 num_vic)
>  {
> @@ -30,6 +29,4 @@ void __init s5p_init_irq(u32 *vic, u32 num_vic)
>  	for (irq = 0; irq < num_vic; irq++)
>  		vic_init(VA_VIC(irq), VIC_BASE(irq), vic[irq], 0);
>  #endif
> -
> -	s3c_init_vic_timer_irq(5, IRQ_TIMER0);
>  }
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From paul at pwsan.com  Mon Jul 22 00:01:57 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 22 Jul 2013 04:01:57 +0000 (UTC)
Subject: OMAP baseline test results for Linux v3.11-rc2
Message-ID: <alpine.DEB.2.02.1307220400260.4804@utopia.booyaka.com>


Here are some basic OMAP test results for Linux v3.11-rc2.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v3.11-rc2/20130721203314/


Test summary
------------

Build: uImage:
    Pass (14/14): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
		  omap1_defconfig_1510innovator_only,
		  omap1_defconfig_5912osk_only, omap2plus_defconfig,
		  omap2plus_defconfig_2430sdp_only,
		  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
		  omap2plus_defconfig_omap2_4_only,
		  omap2plus_defconfig_omap3_4_only,
		  rmk_omap3430_ldp_allnoconfig,
		  rmk_omap3430_ldp_oldconfig,
		  rmk_omap4430_sdp_allnoconfig

Build: uImage+dtb:
    Pass ( 3/ 3): am33xx_only/am335x-bone,
		  omap2plus_defconfig/omap4-panda,
		  omap2plus_defconfig/omap4-panda-es

Build: zImage:
    Pass ( 1/ 1): omap2plus_defconfig

Boot to userspace:
    FAIL ( 5/11): 2430sdp, 3530es3beagle, 3730beaglexm, 5912osk,
		  am335xbonelt
    Pass ( 6/11): 3517evm, 37xxevm, 4430es2panda, 4460pandaes,
		  am335xbone, cmt3517

PM: chip retention via suspend:
    FAIL ( 4/ 6): 2430sdp, 3530es3beagle, 3730beaglexm, 4430es2panda
    Pass ( 2/ 6): 37xxevm, 4460pandaes

PM: chip retention via dynamic idle:
    FAIL ( 5/ 6): 2430sdp, 3530es3beagle, 3730beaglexm, 4430es2panda,
		  4460pandaes
    Pass ( 1/ 6): 37xxevm

PM: chip off except CORE via suspend:
    FAIL ( 1/ 1): 3730beaglexm

PM: chip off except CORE via dynamic idle:
    FAIL ( 1/ 1): 3730beaglexm

PM: chip off via suspend:
    FAIL ( 3/ 4): 3530es3beagle, 4430es2panda, 4460pandaes
    Pass ( 1/ 4): 37xxevm

PM: chip off via dynamic idle:
    FAIL ( 3/ 4): 3530es3beagle, 4430es2panda, 4460pandaes
    Pass ( 1/ 4): 37xxevm


vmlinux object size
(delta in bytes from test_v3.11-rc1 (ad81f0545ef01ea651886dddac4bef6cec930092)):
   text     data      bss    total  kernel
   +658     +320        0     +978  am33xx_only
   +350     +192        0     +542  n800_multi_omap2xxx
   +318     +192        0     +510  n800_only_a
   +490     +192        0     +682  omap1_defconfig
   +554     +224        0     +778  omap1_defconfig_1510innovator_only
   +490     +192        0     +682  omap1_defconfig_5912osk_only
   +670     +320        0     +990  omap2plus_defconfig
  +4834     +320        0    +5154  omap2plus_defconfig_2430sdp_only
   +618     +384        0    +1002  omap2plus_defconfig_cpupm
   +670     +256        0     +926  omap2plus_defconfig_no_pm
   +670     +320        0     +990  omap2plus_defconfig_omap2_4_only
   +670     +320        0     +990  omap2plus_defconfig_omap3_4_only
   +336      +96      -72     +360  rmk_omap3430_ldp_allnoconfig
   +318     +192        0     +510  rmk_omap3430_ldp_oldconfig
   +288      +96      -24     +360  rmk_omap4430_sdp_allnoconfig

Boot-time memory difference
(delta in bytes from test_v3.11-rc1 (ad81f0545ef01ea651886dddac4bef6cec930092))
  avail  rsrvd   high  freed  board          kconfig
  (no differences)



From horms+renesas at verge.net.au  Mon Jul 22 00:02:53 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 13:02:53 +0900
Subject: [PATCH] ARM: shmobile: Add lager defconfig
Message-ID: <1374465773-8123-1-git-send-email-horms+renesas@verge.net.au>

This is intended to be used until multi-arch is able to be
used for the lager board at which time a more generic configuration
will be used in place of this one.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/lager_defconfig | 121 +++++++++++++++++++++++++++++++++
 1 file changed, 121 insertions(+)
 create mode 100644 arch/arm/mach-shmobile/lager_defconfig

diff --git a/arch/arm/mach-shmobile/lager_defconfig b/arch/arm/mach-shmobile/lager_defconfig
new file mode 100644
index 0000000..ba839a2
--- /dev/null
+++ b/arch/arm/mach-shmobile/lager_defconfig
@@ -0,0 +1,121 @@
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
+CONFIG_SLAB=y
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_SHMOBILE=y
+CONFIG_ARCH_R8A7790=y
+CONFIG_MACH_LAGER=y
+# CONFIG_SH_TIMER_TMU is not set
+# CONFIG_EM_TIMER_STI is not set
+# CONFIG_SWP_EMULATE is not set
+CONFIG_ARM_ERRATA_430973=y
+CONFIG_ARM_ERRATA_458693=y
+CONFIG_ARM_ERRATA_460075=y
+CONFIG_ARM_ERRATA_743622=y
+CONFIG_ARM_ERRATA_754322=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2
+# CONFIG_LOCAL_TIMERS is not set
+CONFIG_AEABI=y
+# CONFIG_OABI_COMPAT is not set
+CONFIG_FORCE_MAX_ZONEORDER=13
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_KEXEC=y
+CONFIG_AUTO_ZRELADDR=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_PM_RUNTIME=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_NETDEVICES=y
+# CONFIG_NET_CORE is not set
+# CONFIG_NET_VENDOR_ARC is not set
+# CONFIG_NET_CADENCE is not set
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+CONFIG_SH_ETH=y
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
+CONFIG_INPUT_EVDEV=y
+# CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_GPIO=y
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_SH_SCI=y
+CONFIG_SERIAL_SH_SCI_NR_UARTS=8
+CONFIG_SERIAL_SH_SCI_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+CONFIG_I2C_GPIO=y
+CONFIG_I2C_SH_MOBILE=y
+CONFIG_GPIO_SH_PFC=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_RCAR=y
+# CONFIG_HWMON is not set
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_SDHI=y
+CONFIG_MMC_SH_MMCIF=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_RTC_CLASS=y
+CONFIG_DMADEVICES=y
+CONFIG_SH_DMAE=y
+# CONFIG_IOMMU_SUPPORT is not set
+# CONFIG_DNOTIFY is not set
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_CONFIGFS_FS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_NFS_V4_1=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+# CONFIG_ARM_UNWIND is not set
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+# CONFIG_CRYPTO_HW is not set
-- 
1.8.2.1



From daniel.lezcano at linaro.org  Mon Jul 22 00:04:19 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Jul 2013 06:04:19 +0200
Subject: [PATCH] clocksource: sh_cmt: 32-bit control register support
In-Reply-To: <2792cc6f22031110f6959c02d42d7b6116105a71.1374207810.git.horms+renesas@verge.net.au>
References: <cover.1374207810.git.horms+renesas@verge.net.au>
 <2792cc6f22031110f6959c02d42d7b6116105a71.1374207810.git.horms+renesas@verge.net.au>
Message-ID: <51ECAF43.80200@linaro.org>

On 07/19/2013 06:36 AM, Simon Horman wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Add support for CMT hardware with 32-bit control and counter
> registers, as found on r8a73a4 and r8a7790. To use the CMT
> with 32-bit hardware a second I/O memory resource needs to
> point out the CMSTR register and it needs to be 32 bit wide.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> ---

In the future, can you Cc drivers/clocksource maintainers please ?

Reviewed-by: Daniel Lezcano <daniel.lezcano at linaro.org>

>  drivers/clocksource/sh_cmt.c |   50 ++++++++++++++++++++++++++++++------------
>  1 file changed, 36 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/clocksource/sh_cmt.c b/drivers/clocksource/sh_cmt.c
> index 08d0c41..0965e98 100644
> --- a/drivers/clocksource/sh_cmt.c
> +++ b/drivers/clocksource/sh_cmt.c
> @@ -37,6 +37,7 @@
>  
>  struct sh_cmt_priv {
>  	void __iomem *mapbase;
> +	void __iomem *mapbase_str;
>  	struct clk *clk;
>  	unsigned long width; /* 16 or 32 bit version of hardware block */
>  	unsigned long overflow_bit;
> @@ -79,6 +80,12 @@ struct sh_cmt_priv {
>   * CMCSR 0xffca0060 16-bit
>   * CMCNT 0xffca0064 32-bit
>   * CMCOR 0xffca0068 32-bit
> + *
> + * "32-bit counter and 32-bit control" as found on r8a73a4 and r8a7790:
> + * CMSTR 0xffca0500 32-bit
> + * CMCSR 0xffca0510 32-bit
> + * CMCNT 0xffca0514 32-bit
> + * CMCOR 0xffca0518 32-bit
>   */
>  
>  static unsigned long sh_cmt_read16(void __iomem *base, unsigned long offs)
> @@ -109,9 +116,7 @@ static void sh_cmt_write32(void __iomem *base, unsigned long offs,
>  
>  static inline unsigned long sh_cmt_read_cmstr(struct sh_cmt_priv *p)
>  {
> -	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
> -
> -	return p->read_control(p->mapbase - cfg->channel_offset, 0);
> +	return p->read_control(p->mapbase_str, 0);
>  }
>  
>  static inline unsigned long sh_cmt_read_cmcsr(struct sh_cmt_priv *p)
> @@ -127,9 +132,7 @@ static inline unsigned long sh_cmt_read_cmcnt(struct sh_cmt_priv *p)
>  static inline void sh_cmt_write_cmstr(struct sh_cmt_priv *p,
>  				      unsigned long value)
>  {
> -	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
> -
> -	p->write_control(p->mapbase - cfg->channel_offset, 0, value);
> +	p->write_control(p->mapbase_str, 0, value);
>  }
>  
>  static inline void sh_cmt_write_cmcsr(struct sh_cmt_priv *p,
> @@ -676,7 +679,7 @@ static int sh_cmt_register(struct sh_cmt_priv *p, char *name,
>  static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
>  {
>  	struct sh_timer_config *cfg = pdev->dev.platform_data;
> -	struct resource *res;
> +	struct resource *res, *res2;
>  	int irq, ret;
>  	ret = -ENXIO;
>  
> @@ -694,6 +697,9 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
>  		goto err0;
>  	}
>  
> +	/* optional resource for the shared timer start/stop register */
> +	res2 = platform_get_resource(p->pdev, IORESOURCE_MEM, 1);
> +
>  	irq = platform_get_irq(p->pdev, 0);
>  	if (irq < 0) {
>  		dev_err(&p->pdev->dev, "failed to get irq\n");
> @@ -707,6 +713,15 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
>  		goto err0;
>  	}
>  
> +	/* map second resource for CMSTR */
> +	p->mapbase_str = ioremap_nocache(res2 ? res2->start :
> +					 res->start - cfg->channel_offset,
> +					 res2 ? resource_size(res2) : 2);
> +	if (p->mapbase_str == NULL) {
> +		dev_err(&p->pdev->dev, "failed to remap I/O second memory\n");
> +		goto err1;
> +	}
> +
>  	/* request irq using setup_irq() (too early for request_irq()) */
>  	p->irqaction.name = dev_name(&p->pdev->dev);
>  	p->irqaction.handler = sh_cmt_interrupt;
> @@ -719,11 +734,17 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
>  	if (IS_ERR(p->clk)) {
>  		dev_err(&p->pdev->dev, "cannot get clock\n");
>  		ret = PTR_ERR(p->clk);
> -		goto err1;
> +		goto err2;
>  	}
>  
> -	p->read_control = sh_cmt_read16;
> -	p->write_control = sh_cmt_write16;
> +	if (res2 && (resource_size(res2) == 4)) {
> +		/* assume both CMSTR and CMCSR to be 32-bit */
> +		p->read_control = sh_cmt_read32;
> +		p->write_control = sh_cmt_write32;
> +	} else {
> +		p->read_control = sh_cmt_read16;
> +		p->write_control = sh_cmt_write16;
> +	}
>  
>  	if (resource_size(res) == 6) {
>  		p->width = 16;
> @@ -752,22 +773,23 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
>  			      cfg->clocksource_rating);
>  	if (ret) {
>  		dev_err(&p->pdev->dev, "registration failed\n");
> -		goto err2;
> +		goto err3;
>  	}
>  	p->cs_enabled = false;
>  
>  	ret = setup_irq(irq, &p->irqaction);
>  	if (ret) {
>  		dev_err(&p->pdev->dev, "failed to request irq %d\n", irq);
> -		goto err2;
> +		goto err3;
>  	}
>  
>  	platform_set_drvdata(pdev, p);
>  
>  	return 0;
> -err2:
> +err3:
>  	clk_put(p->clk);
> -
> +err2:
> +	iounmap(p->mapbase_str);
>  err1:
>  	iounmap(p->mapbase);
>  err0:
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From horms+renesas at verge.net.au  Mon Jul 22 00:04:53 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 13:04:53 +0900
Subject: [PATCH 0/2] ARCH: ARM: shmobile: Remove kota2 and ag5evm board support
Message-ID: <1374465895-8372-1-git-send-email-horms+renesas@verge.net.au>

Remove support for the sh73a0 based kota2 and ag5evm boards.
Support for the sh72a0 SoC is continued using the kzm9g board.



From horms+renesas at verge.net.au  Mon Jul 22 00:04:54 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 13:04:54 +0900
Subject: [PATCH 1/2] ARCH: ARM: shmobile: Remove kota2 board support
In-Reply-To: <1374465895-8372-1-git-send-email-horms+renesas@verge.net.au>
References: <1374465895-8372-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1374465895-8372-2-git-send-email-horms+renesas@verge.net.au>

Remove support for the sh73a0 based kota2 board.

The sh73a0 SoC is continued to be supported using
the kzm9g board.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/kota2_defconfig     | 121 --------
 arch/arm/mach-shmobile/Kconfig       |   6 -
 arch/arm/mach-shmobile/Makefile      |   1 -
 arch/arm/mach-shmobile/Makefile.boot |   1 -
 arch/arm/mach-shmobile/board-kota2.c | 550 -----------------------------------
 5 files changed, 679 deletions(-)
 delete mode 100644 arch/arm/configs/kota2_defconfig
 delete mode 100644 arch/arm/mach-shmobile/board-kota2.c

diff --git a/arch/arm/configs/kota2_defconfig b/arch/arm/configs/kota2_defconfig
deleted file mode 100644
index 57ad3d4..0000000
--- a/arch/arm/configs/kota2_defconfig
+++ /dev/null
@@ -1,121 +0,0 @@
-# CONFIG_ARM_PATCH_PHYS_VIRT is not set
-CONFIG_EXPERIMENTAL=y
-CONFIG_SYSVIPC=y
-CONFIG_IKCONFIG=y
-CONFIG_IKCONFIG_PROC=y
-CONFIG_LOG_BUF_SHIFT=16
-CONFIG_CGROUPS=y
-CONFIG_CPUSETS=y
-CONFIG_NAMESPACES=y
-# CONFIG_UTS_NS is not set
-# CONFIG_IPC_NS is not set
-# CONFIG_USER_NS is not set
-# CONFIG_PID_NS is not set
-CONFIG_SYSCTL_SYSCALL=y
-CONFIG_EMBEDDED=y
-CONFIG_SLAB=y
-# CONFIG_BLK_DEV_BSG is not set
-# CONFIG_IOSCHED_DEADLINE is not set
-# CONFIG_IOSCHED_CFQ is not set
-CONFIG_ARCH_SHMOBILE=y
-CONFIG_KEYBOARD_GPIO_POLLED=y
-CONFIG_ARCH_SH73A0=y
-CONFIG_MACH_KOTA2=y
-CONFIG_MEMORY_SIZE=0x1e000000
-# CONFIG_SH_TIMER_TMU is not set
-# CONFIG_SWP_EMULATE is not set
-CONFIG_CPU_BPREDICT_DISABLE=y
-CONFIG_ARM_ERRATA_460075=y
-CONFIG_ARM_ERRATA_742230=y
-CONFIG_ARM_ERRATA_742231=y
-CONFIG_PL310_ERRATA_588369=y
-CONFIG_ARM_ERRATA_720789=y
-CONFIG_PL310_ERRATA_727915=y
-CONFIG_ARM_ERRATA_743622=y
-CONFIG_ARM_ERRATA_751472=y
-CONFIG_PL310_ERRATA_753970=y
-CONFIG_ARM_ERRATA_754322=y
-CONFIG_PL310_ERRATA_769419=y
-CONFIG_NO_HZ=y
-CONFIG_SMP=y
-CONFIG_AEABI=y
-# CONFIG_OABI_COMPAT is not set
-CONFIG_HIGHMEM=y
-CONFIG_ZBOOT_ROM_TEXT=0x0
-CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_CMDLINE="console=ttySC2,115200 earlyprintk=sh-sci.2,115200 ignore_loglevel"
-CONFIG_CMDLINE_FORCE=y
-CONFIG_KEXEC=y
-CONFIG_CPU_IDLE=y
-# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
-CONFIG_PM_RUNTIME=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_INET=y
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_INET_LRO is not set
-# CONFIG_INET_DIAG is not set
-# CONFIG_IPV6 is not set
-CONFIG_CFG80211=y
-CONFIG_WIRELESS_EXT_SYSFS=y
-CONFIG_MAC80211=y
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-# CONFIG_BLK_DEV is not set
-CONFIG_NETDEVICES=y
-# CONFIG_NET_VENDOR_BROADCOM is not set
-# CONFIG_NET_VENDOR_CHELSIO is not set
-# CONFIG_NET_VENDOR_FARADAY is not set
-# CONFIG_NET_VENDOR_INTEL is not set
-# CONFIG_NET_VENDOR_MARVELL is not set
-# CONFIG_NET_VENDOR_MICREL is not set
-# CONFIG_NET_VENDOR_NATSEMI is not set
-# CONFIG_NET_VENDOR_SEEQ is not set
-CONFIG_SMSC911X=y
-# CONFIG_NET_VENDOR_STMICRO is not set
-CONFIG_B43=y
-CONFIG_B43_PHY_N=y
-CONFIG_B43_DEBUG=y
-CONFIG_INPUT_SPARSEKMAP=y
-# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
-CONFIG_INPUT_EVDEV=y
-# CONFIG_KEYBOARD_ATKBD is not set
-CONFIG_KEYBOARD_GPIO=y
-CONFIG_KEYBOARD_SH_KEYSC=y
-# CONFIG_INPUT_MOUSE is not set
-# CONFIG_LEGACY_PTYS is not set
-CONFIG_SERIAL_SH_SCI=y
-CONFIG_SERIAL_SH_SCI_NR_UARTS=9
-CONFIG_SERIAL_SH_SCI_CONSOLE=y
-# CONFIG_HW_RANDOM is not set
-CONFIG_I2C_SH_MOBILE=y
-# CONFIG_HWMON is not set
-CONFIG_BCMA=y
-CONFIG_BCMA_DEBUG=y
-CONFIG_FB=y
-CONFIG_FB_SH_MOBILE_LCDC=y
-CONFIG_LCD_PLATFORM=y
-CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
-# CONFIG_HID_SUPPORT is not set
-# CONFIG_USB_SUPPORT is not set
-CONFIG_MMC=y
-CONFIG_MMC_SDHI=y
-CONFIG_MMC_SH_MMCIF=y
-CONFIG_NEW_LEDS=y
-CONFIG_LEDS_CLASS=y
-CONFIG_LEDS_GPIO=y
-CONFIG_LEDS_RENESAS_TPU=y
-CONFIG_LEDS_TRIGGERS=y
-# CONFIG_DNOTIFY is not set
-CONFIG_TMPFS=y
-# CONFIG_MISC_FILESYSTEMS is not set
-CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_INFO=y
-CONFIG_DEBUG_INFO_REDUCED=y
-# CONFIG_FTRACE is not set
-CONFIG_DEBUG_USER=y
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 3912ce9..734c21b 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -91,12 +91,6 @@ config MACH_MACKEREL
 	select SND_SOC_AK4642 if SND_SIMPLE_CARD
 	select USE_OF
 
-config MACH_KOTA2
-	bool "KOTA2 board"
-	depends on ARCH_SH73A0
-	select ARCH_REQUIRE_GPIOLIB
-	select REGULATOR_FIXED_VOLTAGE if REGULATOR
-
 config MACH_ARMADILLO800EVA
 	bool "Armadillo-800 EVA board"
 	depends on ARCH_R8A7740
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 6165a51..3cf1e7f 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -38,7 +38,6 @@ obj-$(CONFIG_ARCH_SH73A0)	+= pm-sh73a0.o
 obj-$(CONFIG_MACH_AG5EVM)	+= board-ag5evm.o
 obj-$(CONFIG_MACH_APE6EVM)	+= board-ape6evm.o
 obj-$(CONFIG_MACH_MACKEREL)	+= board-mackerel.o
-obj-$(CONFIG_MACH_KOTA2)	+= board-kota2.o
 obj-$(CONFIG_MACH_BOCKW)	+= board-bockw.o
 obj-$(CONFIG_MACH_MARZEN)	+= board-marzen.o
 obj-$(CONFIG_MACH_MARZEN_REFERENCE)	+= board-marzen-reference.o
diff --git a/arch/arm/mach-shmobile/Makefile.boot b/arch/arm/mach-shmobile/Makefile.boot
index 84c6868..fa96899 100644
--- a/arch/arm/mach-shmobile/Makefile.boot
+++ b/arch/arm/mach-shmobile/Makefile.boot
@@ -5,7 +5,6 @@ loadaddr-$(CONFIG_MACH_APE6EVM) += 0x40008000
 loadaddr-$(CONFIG_MACH_ARMADILLO800EVA) += 0x40008000
 loadaddr-$(CONFIG_MACH_ARMADILLO800EVA_REFERENCE) += 0x40008000
 loadaddr-$(CONFIG_MACH_BOCKW) += 0x60008000
-loadaddr-$(CONFIG_MACH_KOTA2) += 0x41008000
 loadaddr-$(CONFIG_MACH_KZM9D) += 0x40008000
 loadaddr-$(CONFIG_MACH_KZM9G) += 0x41008000
 loadaddr-$(CONFIG_MACH_KZM9G_REFERENCE) += 0x41008000
diff --git a/arch/arm/mach-shmobile/board-kota2.c b/arch/arm/mach-shmobile/board-kota2.c
deleted file mode 100644
index 6af20d9..0000000
--- a/arch/arm/mach-shmobile/board-kota2.c
+++ /dev/null
@@ -1,550 +0,0 @@
-/*
- * kota2 board support
- *
- * Copyright (C) 2011  Renesas Solutions Corp.
- * Copyright (C) 2011  Magnus Damm
- * Copyright (C) 2010  Takashi Yoshii <yoshii.takashi.zj at renesas.com>
- * Copyright (C) 2009  Yoshihiro Shimoda <shimoda.yoshihiro at renesas.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/interrupt.h>
-#include <linux/irq.h>
-#include <linux/pinctrl/machine.h>
-#include <linux/pinctrl/pinconf-generic.h>
-#include <linux/platform_data/pwm-renesas-tpu.h>
-#include <linux/platform_device.h>
-#include <linux/delay.h>
-#include <linux/io.h>
-#include <linux/regulator/fixed.h>
-#include <linux/regulator/machine.h>
-#include <linux/smsc911x.h>
-#include <linux/gpio.h>
-#include <linux/input.h>
-#include <linux/input/sh_keysc.h>
-#include <linux/gpio_keys.h>
-#include <linux/leds.h>
-#include <linux/leds_pwm.h>
-#include <linux/irqchip/arm-gic.h>
-#include <linux/mmc/host.h>
-#include <linux/mmc/sh_mmcif.h>
-#include <linux/mfd/tmio.h>
-#include <linux/mmc/sh_mobile_sdhi.h>
-#include <mach/hardware.h>
-#include <mach/irqs.h>
-#include <mach/sh73a0.h>
-#include <mach/common.h>
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <asm/mach/time.h>
-#include <asm/hardware/cache-l2x0.h>
-#include <asm/traps.h>
-
-/* Dummy supplies, where voltage doesn't matter */
-static struct regulator_consumer_supply dummy_supplies[] = {
-	REGULATOR_SUPPLY("vddvario", "smsc911x"),
-	REGULATOR_SUPPLY("vdd33a", "smsc911x"),
-};
-
-/* SMSC 9220 */
-static struct resource smsc9220_resources[] = {
-	[0] = {
-		.start		= 0x14000000, /* CS5A */
-		.end		= 0x140000ff, /* A1->A7 */
-		.flags		= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start		= SH73A0_PINT0_IRQ(2), /* PINTA2 */
-		.flags		= IORESOURCE_IRQ,
-	},
-};
-
-static struct smsc911x_platform_config smsc9220_platdata = {
-	.flags		= SMSC911X_USE_32BIT, /* 32-bit SW on 16-bit HW bus */
-	.phy_interface	= PHY_INTERFACE_MODE_MII,
-	.irq_polarity	= SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
-	.irq_type	= SMSC911X_IRQ_TYPE_PUSH_PULL,
-};
-
-static struct platform_device eth_device = {
-	.name		= "smsc911x",
-	.id		= 0,
-	.dev  = {
-		.platform_data = &smsc9220_platdata,
-	},
-	.resource	= smsc9220_resources,
-	.num_resources	= ARRAY_SIZE(smsc9220_resources),
-};
-
-/* KEYSC */
-static struct sh_keysc_info keysc_platdata = {
-	.mode		= SH_KEYSC_MODE_6,
-	.scan_timing	= 3,
-	.delay		= 100,
-	.keycodes	= {
-		KEY_NUMERIC_STAR, KEY_NUMERIC_0, KEY_NUMERIC_POUND,
-		0, 0, 0, 0, 0,
-		KEY_NUMERIC_7, KEY_NUMERIC_8, KEY_NUMERIC_9,
-		0, KEY_DOWN, 0, 0, 0,
-		KEY_NUMERIC_4, KEY_NUMERIC_5, KEY_NUMERIC_6,
-		KEY_LEFT, KEY_ENTER, KEY_RIGHT, 0, 0,
-		KEY_NUMERIC_1, KEY_NUMERIC_2, KEY_NUMERIC_3,
-		0, KEY_UP, 0, 0, 0,
-		0, 0, 0, 0, 0, 0, 0, 0,
-		0, 0, 0, 0, 0, 0, 0, 0,
-		0, 0, 0, 0, 0, 0, 0, 0,
-		0, 0, 0, 0, 0, 0, 0, 0,
-	},
-};
-
-static struct resource keysc_resources[] = {
-	[0] = {
-		.name	= "KEYSC",
-		.start	= 0xe61b0000,
-		.end	= 0xe61b0098 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_spi(71),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device keysc_device = {
-	.name		= "sh_keysc",
-	.id		= 0,
-	.num_resources	= ARRAY_SIZE(keysc_resources),
-	.resource	= keysc_resources,
-	.dev		= {
-		.platform_data	= &keysc_platdata,
-	},
-};
-
-/* GPIO KEY */
-#define GPIO_KEY(c, g, d) { .code = c, .gpio = g, .desc = d, .active_low = 1 }
-
-static struct gpio_keys_button gpio_buttons[] = {
-	GPIO_KEY(KEY_VOLUMEUP, 56, "+"), /* S2: VOL+ [IRQ9] */
-	GPIO_KEY(KEY_VOLUMEDOWN, 54, "-"), /* S3: VOL- [IRQ10] */
-	GPIO_KEY(KEY_MENU, 27, "Menu"), /* S4: MENU [IRQ30] */
-	GPIO_KEY(KEY_HOMEPAGE, 26, "Home"), /* S5: HOME [IRQ31] */
-	GPIO_KEY(KEY_BACK, 11, "Back"), /* S6: BACK [IRQ0] */
-	GPIO_KEY(KEY_PHONE, 238, "Tel"), /* S7: TEL [IRQ11] */
-	GPIO_KEY(KEY_POWER, 239, "C1"), /* S8: CAM [IRQ13] */
-	GPIO_KEY(KEY_MAIL, 224, "Mail"), /* S9: MAIL [IRQ3] */
-	/* Omitted button "C3?": 223 - S10: CUST [IRQ8] */
-	GPIO_KEY(KEY_CAMERA, 164, "C2"), /* S11: CAM_HALF [IRQ25] */
-	/* Omitted button "?": 152 - S12: CAM_FULL [No IRQ] */
-};
-
-static struct gpio_keys_platform_data gpio_key_info = {
-	.buttons        = gpio_buttons,
-	.nbuttons       = ARRAY_SIZE(gpio_buttons),
-};
-
-static struct platform_device gpio_keys_device = {
-	.name   = "gpio-keys",
-	.id     = -1,
-	.dev    = {
-		.platform_data  = &gpio_key_info,
-	},
-};
-
-/* GPIO LED */
-#define GPIO_LED(n, g) { .name = n, .gpio = g }
-
-static struct gpio_led gpio_leds[] = {
-	GPIO_LED("G", 20), /* PORT20 [GPO0] -> LED7 -> "G" */
-	GPIO_LED("H", 21), /* PORT21 [GPO1] -> LED8 -> "H" */
-	GPIO_LED("J", 22), /* PORT22 [GPO2] -> LED9 -> "J" */
-};
-
-static struct gpio_led_platform_data gpio_leds_info = {
-	.leds		= gpio_leds,
-	.num_leds	= ARRAY_SIZE(gpio_leds),
-};
-
-static struct platform_device gpio_leds_device = {
-	.name   = "leds-gpio",
-	.id     = -1,
-	.dev    = {
-		.platform_data  = &gpio_leds_info,
-	},
-};
-
-/* TPU LED */
-static struct resource tpu1_pwm_resources[] = {
-	[0] = {
-		.start	= 0xe6610000,
-		.end	= 0xe66100ff,
-		.flags	= IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device tpu1_pwm_device = {
-	.name = "renesas-tpu-pwm",
-	.id = 1,
-	.num_resources	= ARRAY_SIZE(tpu1_pwm_resources),
-	.resource	= tpu1_pwm_resources,
-};
-
-static struct resource tpu2_pwm_resources[] = {
-	[0] = {
-		.start	= 0xe6620000,
-		.end	= 0xe66200ff,
-		.flags	= IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device tpu2_pwm_device = {
-	.name = "renesas-tpu-pwm",
-	.id = 2,
-	.num_resources	= ARRAY_SIZE(tpu2_pwm_resources),
-	.resource	= tpu2_pwm_resources,
-};
-
-static struct resource tpu3_pwm_resources[] = {
-	[0] = {
-		.start	= 0xe6630000,
-		.end	= 0xe66300ff,
-		.flags	= IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device tpu3_pwm_device = {
-	.name = "renesas-tpu-pwm",
-	.id = 3,
-	.num_resources	= ARRAY_SIZE(tpu3_pwm_resources),
-	.resource	= tpu3_pwm_resources,
-};
-
-static struct resource tpu4_pwm_resources[] = {
-	[0] = {
-		.start	= 0xe6640000,
-		.end	= 0xe66400ff,
-		.flags	= IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device tpu4_pwm_device = {
-	.name = "renesas-tpu-pwm",
-	.id = 4,
-	.num_resources	= ARRAY_SIZE(tpu4_pwm_resources),
-	.resource	= tpu4_pwm_resources,
-};
-
-static struct pwm_lookup pwm_lookup[] = {
-	PWM_LOOKUP("renesas-tpu-pwm.1", 2, "leds-pwm.0", "V2513"),
-	PWM_LOOKUP("renesas-tpu-pwm.2", 1, "leds-pwm.0", "V2515"),
-	PWM_LOOKUP("renesas-tpu-pwm.3", 0, "leds-pwm.0", "KEYLED"),
-	PWM_LOOKUP("renesas-tpu-pwm.4", 1, "leds-pwm.0", "V2514"),
-};
-
-static struct led_pwm tpu_pwm_leds[] = {
-	{
-		.name		= "V2513",
-		.max_brightness	= 1000,
-	}, {
-		.name		= "V2515",
-		.max_brightness	= 1000,
-	}, {
-		.name		= "KEYLED",
-		.max_brightness	= 1000,
-	}, {
-		.name		= "V2514",
-		.max_brightness	= 1000,
-	},
-};
-
-static struct led_pwm_platform_data leds_pwm_pdata = {
-	.num_leds = ARRAY_SIZE(tpu_pwm_leds),
-	.leds = tpu_pwm_leds,
-};
-
-static struct platform_device leds_pwm_device = {
-	.name = "leds-pwm",
-	.id = 0,
-	.dev = {
-		.platform_data = &leds_pwm_pdata,
-	},
-};
-
-/* Fixed 1.8V regulator to be used by MMCIF */
-static struct regulator_consumer_supply fixed1v8_power_consumers[] =
-{
-	REGULATOR_SUPPLY("vmmc", "sh_mmcif.0"),
-	REGULATOR_SUPPLY("vqmmc", "sh_mmcif.0"),
-};
-
-/* MMCIF */
-static struct resource mmcif_resources[] = {
-	[0] = {
-		.name   = "MMCIF",
-		.start  = 0xe6bd0000,
-		.end    = 0xe6bd00ff,
-		.flags  = IORESOURCE_MEM,
-	},
-	[1] = {
-		.start  = gic_spi(140),
-		.flags  = IORESOURCE_IRQ,
-	},
-	[2] = {
-		.start  = gic_spi(141),
-		.flags  = IORESOURCE_IRQ,
-	},
-};
-
-static struct sh_mmcif_plat_data mmcif_info = {
-	.ocr            = MMC_VDD_165_195,
-	.caps           = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
-};
-
-static struct platform_device mmcif_device = {
-	.name           = "sh_mmcif",
-	.id             = 0,
-	.dev            = {
-		.platform_data          = &mmcif_info,
-	},
-	.num_resources  = ARRAY_SIZE(mmcif_resources),
-	.resource       = mmcif_resources,
-};
-
-/* Fixed 3.3V regulator to be used by SDHI0 and SDHI1 */
-static struct regulator_consumer_supply fixed3v3_power_consumers[] =
-{
-	REGULATOR_SUPPLY("vmmc", "sh_mobile_sdhi.0"),
-	REGULATOR_SUPPLY("vqmmc", "sh_mobile_sdhi.0"),
-	REGULATOR_SUPPLY("vmmc", "sh_mobile_sdhi.1"),
-	REGULATOR_SUPPLY("vqmmc", "sh_mobile_sdhi.1"),
-};
-
-/* SDHI0 */
-static struct sh_mobile_sdhi_info sdhi0_info = {
-	.tmio_caps      = MMC_CAP_SD_HIGHSPEED,
-	.tmio_flags     = TMIO_MMC_WRPROTECT_DISABLE | TMIO_MMC_HAS_IDLE_WAIT,
-};
-
-static struct resource sdhi0_resources[] = {
-	[0] = {
-		.name   = "SDHI0",
-		.start  = 0xee100000,
-		.end    = 0xee1000ff,
-		.flags  = IORESOURCE_MEM,
-	},
-	[1] = {
-		.start  = gic_spi(83),
-		.flags  = IORESOURCE_IRQ,
-	},
-	[2] = {
-		.start  = gic_spi(84),
-		.flags  = IORESOURCE_IRQ,
-	},
-	[3] = {
-		.start	= gic_spi(85),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device sdhi0_device = {
-	.name           = "sh_mobile_sdhi",
-	.id             = 0,
-	.num_resources  = ARRAY_SIZE(sdhi0_resources),
-	.resource       = sdhi0_resources,
-	.dev    = {
-		.platform_data  = &sdhi0_info,
-	},
-};
-
-/* SDHI1 */
-static struct sh_mobile_sdhi_info sdhi1_info = {
-	.tmio_caps      = MMC_CAP_NONREMOVABLE | MMC_CAP_SDIO_IRQ,
-	.tmio_flags     = TMIO_MMC_WRPROTECT_DISABLE | TMIO_MMC_HAS_IDLE_WAIT,
-};
-
-static struct resource sdhi1_resources[] = {
-	[0] = {
-		.name   = "SDHI1",
-		.start  = 0xee120000,
-		.end    = 0xee1200ff,
-		.flags  = IORESOURCE_MEM,
-	},
-	[1] = {
-		.start  = gic_spi(87),
-		.flags  = IORESOURCE_IRQ,
-	},
-	[2] = {
-		.start  = gic_spi(88),
-		.flags  = IORESOURCE_IRQ,
-	},
-	[3] = {
-		.start	= gic_spi(89),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device sdhi1_device = {
-	.name           = "sh_mobile_sdhi",
-	.id             = 1,
-	.num_resources  = ARRAY_SIZE(sdhi1_resources),
-	.resource       = sdhi1_resources,
-	.dev    = {
-		.platform_data  = &sdhi1_info,
-	},
-};
-
-static struct platform_device *kota2_devices[] __initdata = {
-	&eth_device,
-	&keysc_device,
-	&gpio_keys_device,
-	&gpio_leds_device,
-	&tpu1_pwm_device,
-	&tpu2_pwm_device,
-	&tpu3_pwm_device,
-	&tpu4_pwm_device,
-	&leds_pwm_device,
-	&mmcif_device,
-	&sdhi0_device,
-	&sdhi1_device,
-};
-
-static unsigned long pin_pullup_conf[] = {
-	PIN_CONF_PACKED(PIN_CONFIG_BIAS_PULL_UP, 0),
-};
-
-static const struct pinctrl_map kota2_pinctrl_map[] = {
-	/* KEYSC */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				  "keysc_in8", "keysc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				  "keysc_out04", "keysc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				  "keysc_out5", "keysc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				  "keysc_out6_0", "keysc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				  "keysc_out7_0", "keysc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				  "keysc_out8_0", "keysc"),
-	PIN_MAP_CONFIGS_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				      "keysc_in8", pin_pullup_conf),
-	/* MMCIF */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
-				  "mmc0_data8_0", "mmc0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
-				  "mmc0_ctrl_0", "mmc0"),
-	PIN_MAP_CONFIGS_PIN_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
-				    "PORT279", pin_pullup_conf),
-	PIN_MAP_CONFIGS_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
-				      "mmc0_data8_0", pin_pullup_conf),
-	/* SCIFA2 (UART2) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.2", "pfc-sh73a0",
-				  "scifa2_data_0", "scifa2"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.2", "pfc-sh73a0",
-				  "scifa2_ctrl_0", "scifa2"),
-	/* SCIFA4 (UART1) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-sh73a0",
-				  "scifa4_data", "scifa4"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-sh73a0",
-				  "scifa4_ctrl", "scifa4"),
-	/* SCIFB (BT) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.8", "pfc-sh73a0",
-				  "scifb_data_0", "scifb"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.8", "pfc-sh73a0",
-				  "scifb_clk_0", "scifb"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.8", "pfc-sh73a0",
-				  "scifb_ctrl_0", "scifb"),
-	/* SDHI0 (microSD) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
-				  "sdhi0_data4", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
-				  "sdhi0_ctrl", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
-				  "sdhi0_cd", "sdhi0"),
-	PIN_MAP_CONFIGS_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
-				      "sdhi0_data4", pin_pullup_conf),
-	PIN_MAP_CONFIGS_PIN_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
-				    "PORT256", pin_pullup_conf),
-	PIN_MAP_CONFIGS_PIN_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
-				    "PORT251", pin_pullup_conf),
-	/* SDHI1 (BCM4330) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.1", "pfc-sh73a0",
-				  "sdhi1_data4", "sdhi1"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.1", "pfc-sh73a0",
-				  "sdhi1_ctrl", "sdhi1"),
-	PIN_MAP_CONFIGS_GROUP_DEFAULT("sh_mobile_sdhi.1", "pfc-sh73a0",
-				      "sdhi1_data4", pin_pullup_conf),
-	PIN_MAP_CONFIGS_PIN_DEFAULT("sh_mobile_sdhi.1", "pfc-sh73a0",
-				    "PORT263", pin_pullup_conf),
-	/* SMSC911X */
-	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x.0", "pfc-sh73a0",
-				  "bsc_data_0_7", "bsc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x.0", "pfc-sh73a0",
-				  "bsc_data_8_15", "bsc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x.0", "pfc-sh73a0",
-				  "bsc_cs5_a", "bsc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x.0", "pfc-sh73a0",
-				  "bsc_we0", "bsc"),
-	/* TPU */
-	PIN_MAP_MUX_GROUP_DEFAULT("renesas-tpu-pwm.1", "pfc-sh73a0",
-				  "tpu1_to2", "tpu1"),
-	PIN_MAP_MUX_GROUP_DEFAULT("renesas-tpu-pwm.2", "pfc-sh73a0",
-				  "tpu2_to1", "tpu2"),
-	PIN_MAP_MUX_GROUP_DEFAULT("renesas-tpu-pwm.3", "pfc-sh73a0",
-				  "tpu3_to0", "tpu3"),
-	PIN_MAP_MUX_GROUP_DEFAULT("renesas-tpu-pwm.4", "pfc-sh73a0",
-				  "tpu4_to1", "tpu4"),
-};
-
-static void __init kota2_init(void)
-{
-	regulator_register_always_on(0, "fixed-1.8V", fixed1v8_power_consumers,
-				     ARRAY_SIZE(fixed1v8_power_consumers), 1800000);
-	regulator_register_always_on(1, "fixed-3.3V", fixed3v3_power_consumers,
-				     ARRAY_SIZE(fixed3v3_power_consumers), 3300000);
-	regulator_register_fixed(2, dummy_supplies, ARRAY_SIZE(dummy_supplies));
-
-	pinctrl_register_mappings(kota2_pinctrl_map,
-				  ARRAY_SIZE(kota2_pinctrl_map));
-	pwm_add_table(pwm_lookup, ARRAY_SIZE(pwm_lookup));
-
-	sh73a0_pinmux_init();
-
-	/* SMSC911X */
-	gpio_request_one(144, GPIOF_IN, NULL); /* PINTA2 */
-	gpio_request_one(145, GPIOF_OUT_INIT_HIGH, NULL); /* RESET */
-
-	/* MMCIF */
-	gpio_request_one(208, GPIOF_OUT_INIT_HIGH, NULL); /* Reset */
-
-#ifdef CONFIG_CACHE_L2X0
-	/* Early BRESP enable, Shared attribute override enable, 64K*8way */
-	l2x0_init(IOMEM(0xf0100000), 0x40460000, 0x82000fff);
-#endif
-	sh73a0_add_standard_devices();
-	platform_add_devices(kota2_devices, ARRAY_SIZE(kota2_devices));
-}
-
-MACHINE_START(KOTA2, "kota2")
-	.smp		= smp_ops(sh73a0_smp_ops),
-	.map_io		= sh73a0_map_io,
-	.init_early	= sh73a0_add_early_devices,
-	.nr_irqs	= NR_IRQS_LEGACY,
-	.init_irq	= sh73a0_init_irq,
-	.init_machine	= kota2_init,
-	.init_late	= shmobile_init_late,
-	.init_time	= sh73a0_earlytimer_init,
-MACHINE_END
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 00:04:55 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 13:04:55 +0900
Subject: [PATCH 2/2] ARCH: ARM: shmobile: Remove ag5evm board support
In-Reply-To: <1374465895-8372-1-git-send-email-horms+renesas@verge.net.au>
References: <1374465895-8372-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1374465895-8372-3-git-send-email-horms+renesas@verge.net.au>

Remove support for the sh73a0 based ag5evm board.

The sh73a0 SoC is continued to be supported using
the kzm9g board.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/ag5evm_defconfig     |  83 -----
 arch/arm/mach-shmobile/Kconfig        |   7 -
 arch/arm/mach-shmobile/Makefile       |   1 -
 arch/arm/mach-shmobile/Makefile.boot  |   1 -
 arch/arm/mach-shmobile/board-ag5evm.c | 639 ----------------------------------
 5 files changed, 731 deletions(-)
 delete mode 100644 arch/arm/configs/ag5evm_defconfig
 delete mode 100644 arch/arm/mach-shmobile/board-ag5evm.c

diff --git a/arch/arm/configs/ag5evm_defconfig b/arch/arm/configs/ag5evm_defconfig
deleted file mode 100644
index 212ead3..0000000
--- a/arch/arm/configs/ag5evm_defconfig
+++ /dev/null
@@ -1,83 +0,0 @@
-CONFIG_EXPERIMENTAL=y
-CONFIG_SYSVIPC=y
-CONFIG_IKCONFIG=y
-CONFIG_IKCONFIG_PROC=y
-CONFIG_LOG_BUF_SHIFT=16
-CONFIG_NAMESPACES=y
-# CONFIG_UTS_NS is not set
-# CONFIG_IPC_NS is not set
-# CONFIG_USER_NS is not set
-# CONFIG_PID_NS is not set
-CONFIG_BLK_DEV_INITRD=y
-CONFIG_INITRAMFS_SOURCE=""
-CONFIG_EXPERT=y
-CONFIG_SLAB=y
-# CONFIG_BLK_DEV_BSG is not set
-# CONFIG_IOSCHED_DEADLINE is not set
-# CONFIG_IOSCHED_CFQ is not set
-CONFIG_ARCH_SHMOBILE=y
-CONFIG_ARCH_SH73A0=y
-CONFIG_MACH_AG5EVM=y
-CONFIG_MEMORY_SIZE=0x10000000
-CONFIG_CPU_BPREDICT_DISABLE=y
-CONFIG_ARM_ERRATA_430973=y
-CONFIG_ARM_ERRATA_458693=y
-CONFIG_NO_HZ=y
-CONFIG_AEABI=y
-# CONFIG_OABI_COMPAT is not set
-CONFIG_HIGHMEM=y
-CONFIG_ZBOOT_ROM_TEXT=0x0
-CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_CMDLINE="console=tty0 console=ttySC2,115200 earlyprintk=sh-sci.2,115200 ignore_loglevel"
-CONFIG_CMDLINE_FORCE=y
-CONFIG_KEXEC=y
-# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
-CONFIG_PM=y
-# CONFIG_SUSPEND is not set
-CONFIG_PM_RUNTIME=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_INET=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_INET_LRO is not set
-# CONFIG_INET_DIAG is not set
-# CONFIG_IPV6 is not set
-# CONFIG_WIRELESS is not set
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-# CONFIG_BLK_DEV is not set
-CONFIG_NETDEVICES=y
-CONFIG_NET_ETHERNET=y
-CONFIG_SMSC911X=y
-# CONFIG_NETDEV_1000 is not set
-# CONFIG_NETDEV_10000 is not set
-# CONFIG_WLAN is not set
-CONFIG_INPUT_SPARSEKMAP=y
-# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
-CONFIG_INPUT_EVDEV=y
-# CONFIG_INPUT_KEYBOARD is not set
-# CONFIG_INPUT_MOUSE is not set
-CONFIG_SERIAL_SH_SCI=y
-CONFIG_SERIAL_SH_SCI_NR_UARTS=9
-CONFIG_SERIAL_SH_SCI_CONSOLE=y
-# CONFIG_LEGACY_PTYS is not set
-# CONFIG_HW_RANDOM is not set
-CONFIG_I2C=y
-CONFIG_I2C_SH_MOBILE=y
-# CONFIG_HWMON is not set
-# CONFIG_MFD_SUPPORT is not set
-CONFIG_FB=y
-CONFIG_FB_SH_MOBILE_LCDC=y
-CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
-# CONFIG_HID_SUPPORT is not set
-# CONFIG_USB_SUPPORT is not set
-# CONFIG_DNOTIFY is not set
-# CONFIG_INOTIFY_USER is not set
-CONFIG_TMPFS=y
-# CONFIG_MISC_FILESYSTEMS is not set
-CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_KERNEL=y
-# CONFIG_FTRACE is not set
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 734c21b..5436cc2 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -71,13 +71,6 @@ config ARCH_EMEV2
 
 comment "SH-Mobile Board Type"
 
-config MACH_AG5EVM
-	bool "AG5EVM board"
-	depends on ARCH_SH73A0
-	select ARCH_REQUIRE_GPIOLIB
-	select REGULATOR_FIXED_VOLTAGE if REGULATOR
-	select SH_LCD_MIPI_DSI
-
 config MACH_APE6EVM
 	bool "APE6EVM board"
 	depends on ARCH_R8A73A4
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 3cf1e7f..7550774 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -35,7 +35,6 @@ obj-$(CONFIG_ARCH_R8A7779)	+= pm-r8a7779.o
 obj-$(CONFIG_ARCH_SH73A0)	+= pm-sh73a0.o
 
 # Board objects
-obj-$(CONFIG_MACH_AG5EVM)	+= board-ag5evm.o
 obj-$(CONFIG_MACH_APE6EVM)	+= board-ape6evm.o
 obj-$(CONFIG_MACH_MACKEREL)	+= board-mackerel.o
 obj-$(CONFIG_MACH_BOCKW)	+= board-bockw.o
diff --git a/arch/arm/mach-shmobile/Makefile.boot b/arch/arm/mach-shmobile/Makefile.boot
index fa96899..563829b 100644
--- a/arch/arm/mach-shmobile/Makefile.boot
+++ b/arch/arm/mach-shmobile/Makefile.boot
@@ -1,6 +1,5 @@
 # per-board load address for uImage
 loadaddr-y	:=
-loadaddr-$(CONFIG_MACH_AG5EVM) += 0x40008000
 loadaddr-$(CONFIG_MACH_APE6EVM) += 0x40008000
 loadaddr-$(CONFIG_MACH_ARMADILLO800EVA) += 0x40008000
 loadaddr-$(CONFIG_MACH_ARMADILLO800EVA_REFERENCE) += 0x40008000
diff --git a/arch/arm/mach-shmobile/board-ag5evm.c b/arch/arm/mach-shmobile/board-ag5evm.c
deleted file mode 100644
index f6d6449..0000000
--- a/arch/arm/mach-shmobile/board-ag5evm.c
+++ /dev/null
@@ -1,639 +0,0 @@
-/*
- * arch/arm/mach-shmobile/board-ag5evm.c
- *
- * Copyright (C) 2010  Takashi Yoshii <yoshii.takashi.zj at renesas.com>
- * Copyright (C) 2009  Yoshihiro Shimoda <shimoda.yoshihiro at renesas.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
- *
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/interrupt.h>
-#include <linux/irq.h>
-#include <linux/pinctrl/machine.h>
-#include <linux/pinctrl/pinconf-generic.h>
-#include <linux/platform_device.h>
-#include <linux/delay.h>
-#include <linux/io.h>
-#include <linux/dma-mapping.h>
-#include <linux/regulator/fixed.h>
-#include <linux/regulator/machine.h>
-#include <linux/serial_sci.h>
-#include <linux/smsc911x.h>
-#include <linux/gpio.h>
-#include <linux/videodev2.h>
-#include <linux/input.h>
-#include <linux/input/sh_keysc.h>
-#include <linux/mmc/host.h>
-#include <linux/mmc/sh_mmcif.h>
-#include <linux/mmc/sh_mobile_sdhi.h>
-#include <linux/mfd/tmio.h>
-#include <linux/platform_data/bd6107.h>
-#include <linux/sh_clk.h>
-#include <linux/irqchip/arm-gic.h>
-#include <video/sh_mobile_lcdc.h>
-#include <video/sh_mipi_dsi.h>
-#include <sound/sh_fsi.h>
-#include <mach/hardware.h>
-#include <mach/irqs.h>
-#include <mach/sh73a0.h>
-#include <mach/common.h>
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <asm/hardware/cache-l2x0.h>
-#include <asm/traps.h>
-
-/* Dummy supplies, where voltage doesn't matter */
-static struct regulator_consumer_supply dummy_supplies[] = {
-	REGULATOR_SUPPLY("vddvario", "smsc911x"),
-	REGULATOR_SUPPLY("vdd33a", "smsc911x"),
-};
-
-static struct resource smsc9220_resources[] = {
-	[0] = {
-		.start		= 0x14000000,
-		.end		= 0x14000000 + SZ_64K - 1,
-		.flags		= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start		= SH73A0_PINT0_IRQ(2), /* PINTA2 */
-		.flags		= IORESOURCE_IRQ,
-	},
-};
-
-static struct smsc911x_platform_config smsc9220_platdata = {
-	.flags		= SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
-	.phy_interface	= PHY_INTERFACE_MODE_MII,
-	.irq_polarity	= SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
-	.irq_type	= SMSC911X_IRQ_TYPE_PUSH_PULL,
-};
-
-static struct platform_device eth_device = {
-	.name		= "smsc911x",
-	.id		= 0,
-	.dev  = {
-		.platform_data = &smsc9220_platdata,
-	},
-	.resource	= smsc9220_resources,
-	.num_resources	= ARRAY_SIZE(smsc9220_resources),
-};
-
-static struct sh_keysc_info keysc_platdata = {
-	.mode		= SH_KEYSC_MODE_6,
-	.scan_timing	= 3,
-	.delay		= 100,
-	.keycodes	= {
-		KEY_A, KEY_B, KEY_C, KEY_D, KEY_E, KEY_F, KEY_G,
-		KEY_H, KEY_I, KEY_J, KEY_K, KEY_L, KEY_M, KEY_N,
-		KEY_O, KEY_P, KEY_Q, KEY_R, KEY_S, KEY_T, KEY_U,
-		KEY_V, KEY_W, KEY_X, KEY_Y, KEY_Z, KEY_HOME, KEY_SLEEP,
-		KEY_SPACE, KEY_9, KEY_6, KEY_3, KEY_WAKEUP, KEY_RIGHT, \
-		KEY_COFFEE,
-		KEY_0, KEY_8, KEY_5, KEY_2, KEY_DOWN, KEY_ENTER, KEY_UP,
-		KEY_KPASTERISK, KEY_7, KEY_4, KEY_1, KEY_STOP, KEY_LEFT, \
-		KEY_COMPUTER,
-	},
-};
-
-static struct resource keysc_resources[] = {
-	[0] = {
-		.name	= "KEYSC",
-		.start	= 0xe61b0000,
-		.end	= 0xe61b0098 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_spi(71),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device keysc_device = {
-	.name		= "sh_keysc",
-	.id		= 0,
-	.num_resources	= ARRAY_SIZE(keysc_resources),
-	.resource	= keysc_resources,
-	.dev		= {
-		.platform_data	= &keysc_platdata,
-	},
-};
-
-/* FSI A */
-static struct resource fsi_resources[] = {
-	[0] = {
-		.name	= "FSI",
-		.start	= 0xEC230000,
-		.end	= 0xEC230400 - 1,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start  = gic_spi(146),
-		.flags  = IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device fsi_device = {
-	.name		= "sh_fsi2",
-	.id		= -1,
-	.num_resources	= ARRAY_SIZE(fsi_resources),
-	.resource	= fsi_resources,
-};
-
-/* Fixed 1.8V regulator to be used by MMCIF */
-static struct regulator_consumer_supply fixed1v8_power_consumers[] =
-{
-	REGULATOR_SUPPLY("vmmc", "sh_mmcif.0"),
-	REGULATOR_SUPPLY("vqmmc", "sh_mmcif.0"),
-};
-
-static struct resource sh_mmcif_resources[] = {
-	[0] = {
-		.name	= "MMCIF",
-		.start	= 0xe6bd0000,
-		.end	= 0xe6bd00ff,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_spi(141),
-		.flags	= IORESOURCE_IRQ,
-	},
-	[2] = {
-		.start	= gic_spi(140),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct sh_mmcif_plat_data sh_mmcif_platdata = {
-	.sup_pclk	= 0,
-	.ocr		= MMC_VDD_165_195,
-	.caps		= MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
-	.slave_id_tx	= SHDMA_SLAVE_MMCIF_TX,
-	.slave_id_rx	= SHDMA_SLAVE_MMCIF_RX,
-};
-
-static struct platform_device mmc_device = {
-	.name		= "sh_mmcif",
-	.id		= 0,
-	.dev		= {
-		.dma_mask		= NULL,
-		.coherent_dma_mask	= 0xffffffff,
-		.platform_data		= &sh_mmcif_platdata,
-	},
-	.num_resources	= ARRAY_SIZE(sh_mmcif_resources),
-	.resource	= sh_mmcif_resources,
-};
-
-/* IrDA */
-static struct resource irda_resources[] = {
-	[0] = {
-		.start	= 0xE6D00000,
-		.end	= 0xE6D01FD4 - 1,
-		.flags  = IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= gic_spi(95),
-		.flags  = IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device irda_device = {
-	.name           = "sh_irda",
-	.id		= 0,
-	.resource       = irda_resources,
-	.num_resources  = ARRAY_SIZE(irda_resources),
-};
-
-/* MIPI-DSI */
-static struct resource mipidsi0_resources[] = {
-	[0] = {
-		.name	= "DSI0",
-		.start  = 0xfeab0000,
-		.end    = 0xfeab3fff,
-		.flags  = IORESOURCE_MEM,
-	},
-	[1] = {
-		.name	= "DSI0",
-		.start  = 0xfeab4000,
-		.end    = 0xfeab7fff,
-		.flags  = IORESOURCE_MEM,
-	},
-};
-
-static int sh_mipi_set_dot_clock(struct platform_device *pdev,
-				 void __iomem *base,
-				 int enable)
-{
-	struct clk *pck, *phy;
-	int ret;
-
-	pck = clk_get(&pdev->dev, "dsip_clk");
-	if (IS_ERR(pck)) {
-		ret = PTR_ERR(pck);
-		goto sh_mipi_set_dot_clock_pck_err;
-	}
-
-	phy = clk_get(&pdev->dev, "dsiphy_clk");
-	if (IS_ERR(phy)) {
-		ret = PTR_ERR(phy);
-		goto sh_mipi_set_dot_clock_phy_err;
-	}
-
-	if (enable) {
-		clk_set_rate(pck, clk_round_rate(pck,  24000000));
-		clk_set_rate(phy, clk_round_rate(pck, 510000000));
-		clk_enable(pck);
-		clk_enable(phy);
-	} else {
-		clk_disable(pck);
-		clk_disable(phy);
-	}
-
-	ret = 0;
-
-	clk_put(phy);
-sh_mipi_set_dot_clock_phy_err:
-	clk_put(pck);
-sh_mipi_set_dot_clock_pck_err:
-	return ret;
-}
-
-static struct sh_mipi_dsi_info mipidsi0_info = {
-	.data_format	= MIPI_RGB888,
-	.channel	= LCDC_CHAN_MAINLCD,
-	.lane		= 2,
-	.vsynw_offset	= 20,
-	.clksrc		= 1,
-	.flags		= SH_MIPI_DSI_HSABM		|
-			  SH_MIPI_DSI_SYNC_PULSES_MODE	|
-			  SH_MIPI_DSI_HSbyteCLK,
-	.set_dot_clock	= sh_mipi_set_dot_clock,
-};
-
-static struct platform_device mipidsi0_device = {
-	.name           = "sh-mipi-dsi",
-	.num_resources  = ARRAY_SIZE(mipidsi0_resources),
-	.resource       = mipidsi0_resources,
-	.id             = 0,
-	.dev	= {
-		.platform_data	= &mipidsi0_info,
-	},
-};
-
-/* LCDC0 and backlight */
-static const struct fb_videomode lcdc0_modes[] = {
-	{
-		.name		= "R63302(QHD)",
-		.xres		= 544,
-		.yres		= 961,
-		.left_margin	= 72,
-		.right_margin	= 600,
-		.hsync_len	= 16,
-		.upper_margin	= 8,
-		.lower_margin	= 8,
-		.vsync_len	= 2,
-		.sync		= FB_SYNC_VERT_HIGH_ACT | FB_SYNC_HOR_HIGH_ACT,
-	},
-};
-
-static struct sh_mobile_lcdc_info lcdc0_info = {
-	.clock_source = LCDC_CLK_PERIPHERAL,
-	.ch[0] = {
-		.chan = LCDC_CHAN_MAINLCD,
-		.interface_type = RGB24,
-		.clock_divider = 1,
-		.flags = LCDC_FLAGS_DWPOL,
-		.fourcc = V4L2_PIX_FMT_RGB565,
-		.lcd_modes = lcdc0_modes,
-		.num_modes = ARRAY_SIZE(lcdc0_modes),
-		.panel_cfg = {
-			.width = 44,
-			.height = 79,
-		},
-		.tx_dev = &mipidsi0_device,
-	}
-};
-
-static struct resource lcdc0_resources[] = {
-	[0] = {
-		.name	= "LCDC0",
-		.start	= 0xfe940000, /* P4-only space */
-		.end	= 0xfe943fff,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= intcs_evt2irq(0x580),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device lcdc0_device = {
-	.name		= "sh_mobile_lcdc_fb",
-	.num_resources	= ARRAY_SIZE(lcdc0_resources),
-	.resource	= lcdc0_resources,
-	.id             = 0,
-	.dev	= {
-		.platform_data	= &lcdc0_info,
-		.coherent_dma_mask = ~0,
-	},
-};
-
-static struct bd6107_platform_data backlight_data = {
-	.fbdev = &lcdc0_device.dev,
-	.reset = 235,
-	.def_value = 0,
-};
-
-static struct i2c_board_info backlight_board_info = {
-	I2C_BOARD_INFO("bd6107", 0x6d),
-	.platform_data = &backlight_data,
-};
-
-/* Fixed 2.8V regulators to be used by SDHI0 */
-static struct regulator_consumer_supply fixed2v8_power_consumers[] =
-{
-	REGULATOR_SUPPLY("vmmc", "sh_mobile_sdhi.0"),
-	REGULATOR_SUPPLY("vqmmc", "sh_mobile_sdhi.0"),
-};
-
-/* SDHI0 */
-static struct sh_mobile_sdhi_info sdhi0_info = {
-	.dma_slave_tx	= SHDMA_SLAVE_SDHI0_TX,
-	.dma_slave_rx	= SHDMA_SLAVE_SDHI0_RX,
-	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_USE_GPIO_CD,
-	.tmio_caps	= MMC_CAP_SD_HIGHSPEED,
-	.tmio_ocr_mask	= MMC_VDD_27_28 | MMC_VDD_28_29,
-	.cd_gpio	= 251,
-};
-
-static struct resource sdhi0_resources[] = {
-	[0] = {
-		.name	= "SDHI0",
-		.start	= 0xee100000,
-		.end	= 0xee1000ff,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.name	= SH_MOBILE_SDHI_IRQ_CARD_DETECT,
-		.start	= gic_spi(83),
-		.flags	= IORESOURCE_IRQ,
-	},
-	[2] = {
-		.name	= SH_MOBILE_SDHI_IRQ_SDCARD,
-		.start	= gic_spi(84),
-		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
-		.name	= SH_MOBILE_SDHI_IRQ_SDIO,
-		.start	= gic_spi(85),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device sdhi0_device = {
-	.name		= "sh_mobile_sdhi",
-	.id		= 0,
-	.num_resources	= ARRAY_SIZE(sdhi0_resources),
-	.resource	= sdhi0_resources,
-	.dev	= {
-		.platform_data	= &sdhi0_info,
-	},
-};
-
-/* Fixed 3.3V regulator to be used by SDHI1 */
-static struct regulator_consumer_supply cn4_power_consumers[] =
-{
-	REGULATOR_SUPPLY("vmmc", "sh_mobile_sdhi.1"),
-	REGULATOR_SUPPLY("vqmmc", "sh_mobile_sdhi.1"),
-};
-
-static struct regulator_init_data cn4_power_init_data = {
-	.constraints = {
-		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
-	},
-	.num_consumer_supplies  = ARRAY_SIZE(cn4_power_consumers),
-	.consumer_supplies      = cn4_power_consumers,
-};
-
-static struct fixed_voltage_config cn4_power_info = {
-	.supply_name = "CN4 SD/MMC Vdd",
-	.microvolts = 3300000,
-	.gpio = 114,
-	.enable_high = 1,
-	.init_data = &cn4_power_init_data,
-};
-
-static struct platform_device cn4_power = {
-	.name = "reg-fixed-voltage",
-	.id   = 2,
-	.dev  = {
-		.platform_data = &cn4_power_info,
-	},
-};
-
-static void ag5evm_sdhi1_set_pwr(struct platform_device *pdev, int state)
-{
-	static int power_gpio = -EINVAL;
-
-	if (power_gpio < 0) {
-		int ret = gpio_request_one(114, GPIOF_OUT_INIT_LOW,
-					   "sdhi1_power");
-		if (!ret)
-			power_gpio = 114;
-	}
-
-	/*
-	 * If requesting the GPIO above failed, it means, that the regulator got
-	 * probed and grabbed the GPIO, but we don't know, whether the sdhi
-	 * driver already uses the regulator. If it doesn't, we have to toggle
-	 * the GPIO ourselves, even though it is now owned by the fixed
-	 * regulator driver. We have to live with the race in case the driver
-	 * gets unloaded and the GPIO freed between these two steps.
-	 */
-	gpio_set_value(114, state);
-}
-
-static struct sh_mobile_sdhi_info sh_sdhi1_info = {
-	.tmio_flags	= TMIO_MMC_WRPROTECT_DISABLE | TMIO_MMC_HAS_IDLE_WAIT,
-	.tmio_caps	= MMC_CAP_NONREMOVABLE | MMC_CAP_SDIO_IRQ,
-	.tmio_ocr_mask	= MMC_VDD_32_33 | MMC_VDD_33_34,
-	.set_pwr	= ag5evm_sdhi1_set_pwr,
-};
-
-static struct resource sdhi1_resources[] = {
-	[0] = {
-		.name	= "SDHI1",
-		.start	= 0xee120000,
-		.end	= 0xee1200ff,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.name	= SH_MOBILE_SDHI_IRQ_CARD_DETECT,
-		.start	= gic_spi(87),
-		.flags	= IORESOURCE_IRQ,
-	},
-	[2] = {
-		.name	= SH_MOBILE_SDHI_IRQ_SDCARD,
-		.start	= gic_spi(88),
-		.flags	= IORESOURCE_IRQ,
-	},
-	[3] = {
-		.name	= SH_MOBILE_SDHI_IRQ_SDIO,
-		.start	= gic_spi(89),
-		.flags	= IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device sdhi1_device = {
-	.name		= "sh_mobile_sdhi",
-	.id		= 1,
-	.dev		= {
-		.platform_data	= &sh_sdhi1_info,
-	},
-	.num_resources	= ARRAY_SIZE(sdhi1_resources),
-	.resource	= sdhi1_resources,
-};
-
-static struct platform_device *ag5evm_devices[] __initdata = {
-	&cn4_power,
-	&eth_device,
-	&keysc_device,
-	&fsi_device,
-	&mmc_device,
-	&irda_device,
-	&mipidsi0_device,
-	&lcdc0_device,
-	&sdhi0_device,
-	&sdhi1_device,
-};
-
-static unsigned long pin_pullup_conf[] = {
-	PIN_CONF_PACKED(PIN_CONFIG_BIAS_PULL_UP, 0),
-};
-
-static const struct pinctrl_map ag5evm_pinctrl_map[] = {
-	/* FSIA */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_fsi2.0", "pfc-sh73a0",
-				  "fsia_mclk_in", "fsia"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_fsi2.0", "pfc-sh73a0",
-				  "fsia_sclk_in", "fsia"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_fsi2.0", "pfc-sh73a0",
-				  "fsia_data_in", "fsia"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_fsi2.0", "pfc-sh73a0",
-				  "fsia_data_out", "fsia"),
-	/* I2C2 & I2C3 */
-	PIN_MAP_MUX_GROUP_DEFAULT("i2c-sh_mobile.2", "pfc-sh73a0",
-				  "i2c2_0", "i2c2"),
-	PIN_MAP_MUX_GROUP_DEFAULT("i2c-sh_mobile.3", "pfc-sh73a0",
-				  "i2c3_0", "i2c3"),
-	/* IrDA */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_irda.0", "pfc-sh73a0",
-				  "irda_0", "irda"),
-	/* KEYSC */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				  "keysc_in8", "keysc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				  "keysc_out04", "keysc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				  "keysc_out5", "keysc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				  "keysc_out6_0", "keysc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				  "keysc_out7_0", "keysc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				  "keysc_out8_0", "keysc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				  "keysc_out9_2", "keysc"),
-	PIN_MAP_CONFIGS_GROUP_DEFAULT("sh_keysc.0", "pfc-sh73a0",
-				      "keysc_in8", pin_pullup_conf),
-	/* MMCIF */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
-				  "mmc0_data8_0", "mmc0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
-				  "mmc0_ctrl_0", "mmc0"),
-	PIN_MAP_CONFIGS_PIN_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
-				    "PORT279", pin_pullup_conf),
-	PIN_MAP_CONFIGS_GROUP_DEFAULT("sh_mmcif.0", "pfc-sh73a0",
-				      "mmc0_data8_0", pin_pullup_conf),
-	/* SCIFA2 */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.2", "pfc-sh73a0",
-				  "scifa2_data_0", "scifa2"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.2", "pfc-sh73a0",
-				  "scifa2_ctrl_0", "scifa2"),
-	/* SDHI0 (CN15 [SD I/F]) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
-				  "sdhi0_data4", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
-				  "sdhi0_ctrl", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-sh73a0",
-				  "sdhi0_wp", "sdhi0"),
-	/* SDHI1 (CN4 [WLAN I/F]) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.1", "pfc-sh73a0",
-				  "sdhi1_data4", "sdhi1"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.1", "pfc-sh73a0",
-				  "sdhi1_ctrl", "sdhi1"),
-	PIN_MAP_CONFIGS_GROUP_DEFAULT("sh_mobile_sdhi.1", "pfc-sh73a0",
-				      "sdhi1_data4", pin_pullup_conf),
-	PIN_MAP_CONFIGS_PIN_DEFAULT("sh_mobile_sdhi.1", "pfc-sh73a0",
-				    "PORT263", pin_pullup_conf),
-};
-
-static void __init ag5evm_init(void)
-{
-	regulator_register_always_on(0, "fixed-1.8V", fixed1v8_power_consumers,
-				     ARRAY_SIZE(fixed1v8_power_consumers), 1800000);
-	regulator_register_always_on(1, "fixed-2.8V", fixed2v8_power_consumers,
-				     ARRAY_SIZE(fixed2v8_power_consumers), 3300000);
-	regulator_register_fixed(3, dummy_supplies, ARRAY_SIZE(dummy_supplies));
-
-	pinctrl_register_mappings(ag5evm_pinctrl_map,
-				  ARRAY_SIZE(ag5evm_pinctrl_map));
-	sh73a0_pinmux_init();
-
-	/* enable MMCIF */
-	gpio_request_one(208, GPIOF_OUT_INIT_HIGH, NULL); /* Reset */
-
-	/* enable SMSC911X */
-	gpio_request_one(144, GPIOF_IN, NULL); /* PINTA2 */
-	gpio_request_one(145, GPIOF_OUT_INIT_HIGH, NULL); /* RESET */
-
-	/* LCD panel */
-	gpio_request_one(217, GPIOF_OUT_INIT_LOW, NULL); /* RESET */
-	mdelay(1);
-	gpio_set_value(217, 1);
-	mdelay(100);
-
-
-#ifdef CONFIG_CACHE_L2X0
-	/* Shared attribute override enable, 64K*8way */
-	l2x0_init(IOMEM(0xf0100000), 0x00460000, 0xc2000fff);
-#endif
-	sh73a0_add_standard_devices();
-
-	i2c_register_board_info(1, &backlight_board_info, 1);
-
-	platform_add_devices(ag5evm_devices, ARRAY_SIZE(ag5evm_devices));
-}
-
-MACHINE_START(AG5EVM, "ag5evm")
-	.smp		= smp_ops(sh73a0_smp_ops),
-	.map_io		= sh73a0_map_io,
-	.init_early	= sh73a0_add_early_devices,
-	.nr_irqs	= NR_IRQS_LEGACY,
-	.init_irq	= sh73a0_init_irq,
-	.init_machine	= ag5evm_init,
-	.init_late	= shmobile_init_late,
-	.init_time	= sh73a0_earlytimer_init,
-MACHINE_END
-- 
1.8.2.1



From daniel.lezcano at linaro.org  Mon Jul 22 00:16:35 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Jul 2013 06:16:35 +0200
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <1374462916.15946.14.camel@jlo-ubuntu-64.nvidia.com>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
 <51E6FF0B.5000708@wwwdotorg.org>
 <1374145726.5610.73.camel@jlo-ubuntu-64.nvidia.com>
 <51E7E27B.9090605@linaro.org>
 <1374218064.24607.1.camel@jlo-ubuntu-64.nvidia.com>
 <51E91A72.6070708@linaro.org>
 <1374462916.15946.14.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <51ECB223.5000002@linaro.org>

On 07/22/2013 05:15 AM, Joseph Lo wrote:
> On Fri, 2013-07-19 at 18:52 +0800, Daniel Lezcano wrote:
>> On 07/19/2013 09:14 AM, Joseph Lo wrote:
>>> On Thu, 2013-07-18 at 20:41 +0800, Daniel Lezcano wrote:
>>>> On 07/18/2013 01:08 PM, Joseph Lo wrote:
>>>>> On Thu, 2013-07-18 at 04:31 +0800, Stephen Warren wrote:
>>>>>> On 07/17/2013 04:15 AM, Joseph Lo wrote:
>>>>>>> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
>>>>>>>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
>>>>>>>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
>>>>>>>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
>>>>>>>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
>>>>>>>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
>>>>>>>>>>> this state.
>>>>>> ... [ discussion of issues with Joesph's patches applied]
>>>>>>>
>>>>>>> OK. I did more stress tests last night and today. I found it cause by
>>>>>>> the patch "ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag" and
>>>>>>> only impact the Tegra20 platform. The hot plug regression seems due to
>>>>>>> this patch. After dropping this patch on top of v3.11-rc1, the Tegra20
>>>>>>> can back to normal.
>>>>>>>
>>>>>>> And the hop plug and suspend stress test can pass on Tegra30/114 too.
>>>>>>>
>>>>>>> Can the other two patch series for Tegra114 to support CPU idle power
>>>>>>> down mode and system suspend still moving forward, not be blocked by
>>>>>>> this patch?
>>>>>>>
>>>>>>> Looks the CPUIDLE_FLAG_TIMER_STOP flag still cause some other issue for
>>>>>>> hot plug on Tegra20, I will continue to check this. You can just drop
>>>>>>> this patch.
>>>>>>
>>>>>> OK, if I drop that patch, then everything on Tegra20 and Tegra30 seems
>>>>>> fine again.
>>>>>>
>>>>>> However, I've found some new and exciting issue on Tegra114!
>>>>>>
>>>>>> With unmodified v3.11-rc1, I can do the following without issue:
>>>>>>
>>>>>> * Unplug/replug CPUs, so that I had all combinations of CPU 1, 2, 3
>>>>>> plugged/unpplugged (with CPU 0 always plugged).
>>>>>>
>>>>>> * Unplug/replug CPUs, so that I had all combinations of CPU 0, 1, 2, 3
>>>>>> plugged/unpplugged (with the obvious exception of never having all CPUs
>>>>>> unplugged).
>>>>>>
>>>>>> However, if I try this with your Tegra114 cpuidle and suspend patches
>>>>>> applied, I see the following issues:
>>>>>>
>>>>>> 1) If I boot, unplug CPU 0, then replug CPU 0, the system immediately
>>>>>> hard-hangs.
>>>>>>
>>>>> Sorry, I didn't apply the hotplug stress test on CPU0 too much. Because
>>>>> all of our use cases and stress tests are focused on secondary CPUs
>>>>> only.
>>>>>
>>>>> After doing some tests, here is my summary. This issue happens after we
>>>>> support CPU idle power-down mode and relates to PMC or flow controller I
>>>>> believe.
>>>>>
>>>>> i) on top of v3.11-rc1 (only support WFI in CPU idle)
>>>>> When hot unplug CPU0, the PMC can power gate and put it into reset
>>>>> state. This is what I expect and also true on all the other secondary
>>>>> CPUs. The flow controller can maintain the CPU power state machine as
>>>>> what we want.
>>>>>
>>>>> ii) on top of v3.11-rc1 + CPU idle power down mode support
>>>>> a) I saw most of the time the CPU0,1,2,3 were in power down and reset
>>>>> status. That means the idle power down mode works fine.
>>>>>
>>>>> b) Testing with the CPU hotplug stress test with the secondary CPUs (not
>>>>> include CPU0), the result is good too.
>>>>>
>>>>> c) Testing hot plug on CPU0 with CPUIDLE_FLAG_TIMER_STOP apply or not
>>>>> apply (Note 1), the result shows not good to me. The CPU0 have already
>>>>> gone into WFI and the flow controller is set as WAITFOREVENT mode. But
>>>>> the PMC always can't power gate CPU0 and sometimes can put it into
>>>>> reset, but sometimes can't. That's why you can see it hanging after
>>>>> unplug CPU0 sometimes.
>>>>
>>>> Are sure coupled idle state support hotplug and especially the cpu0
>>>> hotplug ?
>>>
>>> Tegra114 didn't use coupled idle framework.
>>
>> Ok, so the problem occurs with the CPUIDLE_FLAG_TIMER_STOP flag only on
>> tegra114, right ?
>>
>> Sorry, I am a bit lost :)
>>
> Here are the issues that happen after apply CPUIDLE_FLAG_TIMER_STOP.
> 1) Tegra114/30
> The warning message at kernel/time/tick-broadcast.c:667
> tick_broadcast_oneshot_control could be triggered when doing CPU hot
> plug stress test.

With the fix for tick-broadcast.c [1] ?

> 2) Tegra20
> The system is easy to stick or become lag.
> The CPU hot plug is easy to cause system stick too.
> 
> The fix I suggested in another mail looks can fix all the issues above.
> I verified it again today on 3 different Tegra SoC platforms.

Not sure your patch fixes the problem.

I am wondering if there isn't a underlaying problem which surface with
the flag.

Thanks !
  -- Daniel

[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ea8deb8dfa6b0e8d1b3d1051585706739b46656c

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From josephl at nvidia.com  Mon Jul 22 00:24:45 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Mon, 22 Jul 2013 12:24:45 +0800
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <51ECB223.5000002@linaro.org>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
 <51E6FF0B.5000708@wwwdotorg.org>
 <1374145726.5610.73.camel@jlo-ubuntu-64.nvidia.com>
 <51E7E27B.9090605@linaro.org>
 <1374218064.24607.1.camel@jlo-ubuntu-64.nvidia.com>
 <51E91A72.6070708@linaro.org>
 <1374462916.15946.14.camel@jlo-ubuntu-64.nvidia.com>
 <51ECB223.5000002@linaro.org>
Message-ID: <1374467085.15946.16.camel@jlo-ubuntu-64.nvidia.com>

On Mon, 2013-07-22 at 12:16 +0800, Daniel Lezcano wrote:
> On 07/22/2013 05:15 AM, Joseph Lo wrote:
> > On Fri, 2013-07-19 at 18:52 +0800, Daniel Lezcano wrote:
> >> On 07/19/2013 09:14 AM, Joseph Lo wrote:
> >>> On Thu, 2013-07-18 at 20:41 +0800, Daniel Lezcano wrote:
> >>>> On 07/18/2013 01:08 PM, Joseph Lo wrote:
> >>>>> On Thu, 2013-07-18 at 04:31 +0800, Stephen Warren wrote:
> >>>>>> On 07/17/2013 04:15 AM, Joseph Lo wrote:
> >>>>>>> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
> >>>>>>>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
> >>>>>>>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
> >>>>>>>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
> >>>>>>>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
> >>>>>>>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
> >>>>>>>>>>> this state.
> >>>>>> ... [ discussion of issues with Joesph's patches applied]
> >>>>>>>
[...]
> >>
> >> Ok, so the problem occurs with the CPUIDLE_FLAG_TIMER_STOP flag only on
> >> tegra114, right ?
> >>
> >> Sorry, I am a bit lost :)
> >>
> > Here are the issues that happen after apply CPUIDLE_FLAG_TIMER_STOP.
> > 1) Tegra114/30
> > The warning message at kernel/time/tick-broadcast.c:667
> > tick_broadcast_oneshot_control could be triggered when doing CPU hot
> > plug stress test.
> 
> With the fix for tick-broadcast.c [1] ?
Yes.

> 
> > 2) Tegra20
> > The system is easy to stick or become lag.
> > The CPU hot plug is easy to cause system stick too.
> > 
> > The fix I suggested in another mail looks can fix all the issues above.
> > I verified it again today on 3 different Tegra SoC platforms.
> 
> Not sure your patch fixes the problem.
> 
> I am wondering if there isn't a underlaying problem which surface with
> the flag.
> 
> Thanks !
>   -- Daniel





From daniel.lezcano at linaro.org  Mon Jul 22 00:32:01 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Jul 2013 06:32:01 +0200
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <1374467085.15946.16.camel@jlo-ubuntu-64.nvidia.com>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
 <51E6FF0B.5000708@wwwdotorg.org>
 <1374145726.5610.73.camel@jlo-ubuntu-64.nvidia.com>
 <51E7E27B.9090605@linaro.org>
 <1374218064.24607.1.camel@jlo-ubuntu-64.nvidia.com>
 <51E91A72.6070708@linaro.org>
 <1374462916.15946.14.camel@jlo-ubuntu-64.nvidia.com>
 <51ECB223.5000002@linaro.org>
 <1374467085.15946.16.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <51ECB5C1.600@linaro.org>

On 07/22/2013 06:24 AM, Joseph Lo wrote:
> On Mon, 2013-07-22 at 12:16 +0800, Daniel Lezcano wrote:
>> On 07/22/2013 05:15 AM, Joseph Lo wrote:
>>> On Fri, 2013-07-19 at 18:52 +0800, Daniel Lezcano wrote:
>>>> On 07/19/2013 09:14 AM, Joseph Lo wrote:
>>>>> On Thu, 2013-07-18 at 20:41 +0800, Daniel Lezcano wrote:
>>>>>> On 07/18/2013 01:08 PM, Joseph Lo wrote:
>>>>>>> On Thu, 2013-07-18 at 04:31 +0800, Stephen Warren wrote:
>>>>>>>> On 07/17/2013 04:15 AM, Joseph Lo wrote:
>>>>>>>>> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
>>>>>>>>>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
>>>>>>>>>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
>>>>>>>>>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
>>>>>>>>>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
>>>>>>>>>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
>>>>>>>>>>>>> this state.
>>>>>>>> ... [ discussion of issues with Joesph's patches applied]
>>>>>>>>>
> [...]
>>>>
>>>> Ok, so the problem occurs with the CPUIDLE_FLAG_TIMER_STOP flag only on
>>>> tegra114, right ?
>>>>
>>>> Sorry, I am a bit lost :)
>>>>
>>> Here are the issues that happen after apply CPUIDLE_FLAG_TIMER_STOP.
>>> 1) Tegra114/30
>>> The warning message at kernel/time/tick-broadcast.c:667
>>> tick_broadcast_oneshot_control could be triggered when doing CPU hot
>>> plug stress test.
>>
>> With the fix for tick-broadcast.c [1] ?
> Yes.
> 
>>
>>> 2) Tegra20
>>> The system is easy to stick or become lag.
>>> The CPU hot plug is easy to cause system stick too.
>>>
>>> The fix I suggested in another mail looks can fix all the issues above.
>>> I verified it again today on 3 different Tegra SoC platforms.
>>
>> Not sure your patch fixes the problem.
>>
>> I am wondering if there isn't a underlaying problem which surface with
>> the flag.

Does the attached patch changes something ?


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0011-cpuidle-add-hotplug-support-to-initialize-the-timer-.patch
Type: text/x-diff
Size: 3462 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130722/66dbbf3f/attachment.bin>

From daniel.lezcano at linaro.org  Mon Jul 22 00:36:46 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Jul 2013 06:36:46 +0200
Subject: [PATCH 2/4] ARM: exynos: cpuidle: Use the common cpuidle register
 routine
In-Reply-To: <4097491.3y6BBYmzze@amdc1032>
References: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
 <1374152070-21008-2-git-send-email-daniel.lezcano@linaro.org>
 <4097491.3y6BBYmzze@amdc1032>
Message-ID: <51ECB6DE.9060701@linaro.org>

On 07/19/2013 06:03 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Thursday, July 18, 2013 02:54:28 PM Daniel Lezcano wrote:
>> Now we have the same routine than the one handled by the cpuidle framework.
> 
> Small nitpick:
> 
> To be exact the routine is not the same, on error cpuidle_register() does
> complete unregister operation of the cpuidle driver, exynos4_init_cpuidle()
> just stops the registration procedure. 
> 
> The change itself is okay but the patch description could be better.

Ok, I will fix the changelog.

> Anyway all patches (#1-4) look fine to me. Thanks for this work.

Thanks for the review. I assume it is an acked-by right ?

> Best regards,

Kukjin,

shall I take the patchset in my tree ?

Thanks
  -- Daniel

> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>  
>> Let's use it.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>> ---
>>  arch/arm/mach-exynos/cpuidle.c |   24 +-----------------------
>>  1 file changed, 1 insertion(+), 23 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
>> index cc4b097..d8fc1a2 100644
>> --- a/arch/arm/mach-exynos/cpuidle.c
>> +++ b/arch/arm/mach-exynos/cpuidle.c
>> @@ -41,8 +41,6 @@ static int exynos4_enter_lowpower(struct cpuidle_device *dev,
>>  				struct cpuidle_driver *drv,
>>  				int index);
>>  
>> -static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
>> -
>>  static struct cpuidle_driver exynos4_idle_driver = {
>>  	.name			= "exynos4_idle",
>>  	.owner			= THIS_MODULE,
>> @@ -188,29 +186,9 @@ static void __init exynos5_core_down_clk(void)
>>  
>>  static int __init exynos4_init_cpuidle(void)
>>  {
>> -	int cpu_id, ret;
>> -	struct cpuidle_device *device;
>> -
>>  	if (soc_is_exynos5250())
>>  		exynos5_core_down_clk();
>>  
>> -	ret = cpuidle_register_driver(&exynos4_idle_driver);
>> -	if (ret) {
>> -		printk(KERN_ERR "CPUidle failed to register driver\n");
>> -		return ret;
>> -	}
>> -
>> -	for_each_online_cpu(cpu_id) {
>> -		device = &per_cpu(exynos4_cpuidle_device, cpu_id);
>> -		device->cpu = cpu_id;
>> -
>> -		ret = cpuidle_register_device(device);
>> -		if (ret) {
>> -			printk(KERN_ERR "CPUidle register device failed\n");
>> -			return ret;
>> -		}
>> -	}
>> -
>> -	return 0;
>> +	return cpuidle_register(&exynos4_idle_driver, NULL);
>>  }
>>  device_initcall(exynos4_init_cpuidle);
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From kgene at kernel.org  Mon Jul 22 00:39:29 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Mon, 22 Jul 2013 13:39:29 +0900
Subject: [PATCH] ARM: S3C24XX: Add missing clkdev entries for s3c2440 UART
In-Reply-To: <1374435765-6747-1-git-send-email-sylvester.nawrocki@gmail.com>
References: <1374435765-6747-1-git-send-email-sylvester.nawrocki@gmail.com>
Message-ID: <0b0201ce8695$7434f5c0$5c9ee140$@org>

Sylwester Nawrocki wrote:
> 
> This patch restores serial port operation which has been broken since
> commit 60e93575476f90a72146b51283f514da655410a7
> serial: samsung: enable clock before clearing pending interrupts during
> init
> 
> That commit only uncovered the real issue which was missing clkdev
> entries for the "uart" clocks on S3C2440. It went unnoticed so far
> because return value of clk API calls were not being checked at all
> in the samsung serial port driver.
> 
> This patch should be backported to at least 3.10 stable kernel, since
> the serial port has not been working on s3c2440 since 3.10-rc5.
> 
OK, will apply into -fixes and let me add 'stable' tree in Cc, thanks for
your suggestion :-)

> Cc: Chander Kashyap <chander.kashyap at linaro.org>
> Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
> [on S3C2440 SoC based Mini2440 board]
> Tested-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
> ---
> 
> There seems to be something wrong with the process, as things are
> getting broken late in the -rc cycle.  It seems author of the above
> mentioned commit didn't test all 6 SoC series that the samsung
> serial driver handles.  While I can understand they might not have
> all required hardware it's a bit irritating that the patch that
> in practice caused regression appeared only on linux-serial mailing
> list. And it's not evident it was even tried to test it on all
> potentially affected platforms. It not clear on what platforms
> the patch has been tested.
> 
> My humble suggestion is, _please_ do send patches that affect multiple
> Samsung SoCs to linux-samsung at vger.kernel.org.  So there is better
> review and test exposure.  And we can reduce mess like this happening
> in the future.
> 
Absolutely!

Thanks,
Kukjin

> Thanks!
> Sylwester
> ---
>  arch/arm/mach-s3c24xx/clock-s3c2410.c      |  161
+++++++++++++++++--------
> ---
>  arch/arm/mach-s3c24xx/clock-s3c2440.c      |    3 +
>  arch/arm/plat-samsung/include/plat/clock.h |    5 +
>  3 files changed, 106 insertions(+), 63 deletions(-)
> 
> diff --git a/arch/arm/mach-s3c24xx/clock-s3c2410.c b/arch/arm/mach-
> s3c24xx/clock-s3c2410.c
> index afa0267..d39d3c7 100644
> --- a/arch/arm/mach-s3c24xx/clock-s3c2410.c
> +++ b/arch/arm/mach-s3c24xx/clock-s3c2410.c
> @@ -119,66 +119,101 @@ static struct clk init_clocks_off[] = {
>  	}
>  };
> 
> -static struct clk init_clocks[] = {
> -	{
> -		.name		= "lcd",
> -		.parent		= &clk_h,
> -		.enable		= s3c2410_clkcon_enable,
> -		.ctrlbit	= S3C2410_CLKCON_LCDC,
> -	}, {
> -		.name		= "gpio",
> -		.parent		= &clk_p,
> -		.enable		= s3c2410_clkcon_enable,
> -		.ctrlbit	= S3C2410_CLKCON_GPIO,
> -	}, {
> -		.name		= "usb-host",
> -		.parent		= &clk_h,
> -		.enable		= s3c2410_clkcon_enable,
> -		.ctrlbit	= S3C2410_CLKCON_USBH,
> -	}, {
> -		.name		= "usb-device",
> -		.parent		= &clk_h,
> -		.enable		= s3c2410_clkcon_enable,
> -		.ctrlbit	= S3C2410_CLKCON_USBD,
> -	}, {
> -		.name		= "timers",
> -		.parent		= &clk_p,
> -		.enable		= s3c2410_clkcon_enable,
> -		.ctrlbit	= S3C2410_CLKCON_PWMT,
> -	}, {
> -		.name		= "uart",
> -		.devname	= "s3c2410-uart.0",
> -		.parent		= &clk_p,
> -		.enable		= s3c2410_clkcon_enable,
> -		.ctrlbit	= S3C2410_CLKCON_UART0,
> -	}, {
> -		.name		= "uart",
> -		.devname	= "s3c2410-uart.1",
> -		.parent		= &clk_p,
> -		.enable		= s3c2410_clkcon_enable,
> -		.ctrlbit	= S3C2410_CLKCON_UART1,
> -	}, {
> -		.name		= "uart",
> -		.devname	= "s3c2410-uart.2",
> -		.parent		= &clk_p,
> -		.enable		= s3c2410_clkcon_enable,
> -		.ctrlbit	= S3C2410_CLKCON_UART2,
> -	}, {
> -		.name		= "rtc",
> -		.parent		= &clk_p,
> -		.enable		= s3c2410_clkcon_enable,
> -		.ctrlbit	= S3C2410_CLKCON_RTC,
> -	}, {
> -		.name		= "watchdog",
> -		.parent		= &clk_p,
> -		.ctrlbit	= 0,
> -	}, {
> -		.name		= "usb-bus-host",
> -		.parent		= &clk_usb_bus,
> -	}, {
> -		.name		= "usb-bus-gadget",
> -		.parent		= &clk_usb_bus,
> -	},
> +static struct clk clk_lcd = {
> +	.name		= "lcd",
> +	.parent		= &clk_h,
> +	.enable		= s3c2410_clkcon_enable,
> +	.ctrlbit	= S3C2410_CLKCON_LCDC,
> +};
> +
> +static struct clk clk_gpio = {
> +	.name		= "gpio",
> +	.parent		= &clk_p,
> +	.enable		= s3c2410_clkcon_enable,
> +	.ctrlbit	= S3C2410_CLKCON_GPIO,
> +};
> +
> +static struct clk clk_usb_host = {
> +	.name		= "usb-host",
> +	.parent		= &clk_h,
> +	.enable		= s3c2410_clkcon_enable,
> +	.ctrlbit	= S3C2410_CLKCON_USBH,
> +};
> +
> +static struct clk clk_usb_device = {
> +	.name		= "usb-device",
> +	.parent		= &clk_h,
> +	.enable		= s3c2410_clkcon_enable,
> +	.ctrlbit	= S3C2410_CLKCON_USBD,
> +};
> +
> +static struct clk clk_timers = {
> +	.name		= "timers",
> +	.parent		= &clk_p,
> +	.enable		= s3c2410_clkcon_enable,
> +	.ctrlbit	= S3C2410_CLKCON_PWMT,
> +};
> +
> +struct clk s3c24xx_clk_uart0 = {
> +	.name		= "uart",
> +	.devname	= "s3c2410-uart.0",
> +	.parent		= &clk_p,
> +	.enable		= s3c2410_clkcon_enable,
> +	.ctrlbit	= S3C2410_CLKCON_UART0,
> +};
> +
> +struct clk s3c24xx_clk_uart1 = {
> +	.name		= "uart",
> +	.devname	= "s3c2410-uart.1",
> +	.parent		= &clk_p,
> +	.enable		= s3c2410_clkcon_enable,
> +	.ctrlbit	= S3C2410_CLKCON_UART1,
> +};
> +
> +struct clk s3c24xx_clk_uart2 = {
> +	.name		= "uart",
> +	.devname	= "s3c2410-uart.2",
> +	.parent		= &clk_p,
> +	.enable		= s3c2410_clkcon_enable,
> +	.ctrlbit	= S3C2410_CLKCON_UART2,
> +};
> +
> +static struct clk clk_rtc = {
> +	.name		= "rtc",
> +	.parent		= &clk_p,
> +	.enable		= s3c2410_clkcon_enable,
> +	.ctrlbit	= S3C2410_CLKCON_RTC,
> +};
> +
> +static struct clk clk_watchdog = {
> +	.name		= "watchdog",
> +	.parent		= &clk_p,
> +	.ctrlbit	= 0,
> +};
> +
> +static struct clk clk_usb_bus_host = {
> +	.name		= "usb-bus-host",
> +	.parent		= &clk_usb_bus,
> +};
> +
> +static struct clk clk_usb_bus_gadget = {
> +	.name		= "usb-bus-gadget",
> +	.parent		= &clk_usb_bus,
> +};
> +
> +static struct clk *init_clocks[] = {
> +	&clk_lcd,
> +	&clk_gpio,
> +	&clk_usb_host,
> +	&clk_usb_device,
> +	&clk_timers,
> +	&s3c24xx_clk_uart0,
> +	&s3c24xx_clk_uart1,
> +	&s3c24xx_clk_uart2,
> +	&clk_rtc,
> +	&clk_watchdog,
> +	&clk_usb_bus_host,
> +	&clk_usb_bus_gadget,
>  };
> 
>  /* s3c2410_baseclk_add()
> @@ -195,7 +230,6 @@ int __init s3c2410_baseclk_add(void)
>  {
>  	unsigned long clkslow = __raw_readl(S3C2410_CLKSLOW);
>  	unsigned long clkcon  = __raw_readl(S3C2410_CLKCON);
> -	struct clk *clkp;
>  	struct clk *xtal;
>  	int ret;
>  	int ptr;
> @@ -207,8 +241,9 @@ int __init s3c2410_baseclk_add(void)
> 
>  	/* register clocks from clock array */
> 
> -	clkp = init_clocks;
> -	for (ptr = 0; ptr < ARRAY_SIZE(init_clocks); ptr++, clkp++) {
> +	for (ptr = 0; ptr < ARRAY_SIZE(init_clocks); ptr++) {
> +		struct clk *clkp = init_clocks[ptr];
> +
>  		/* ensure that we note the clock state */
> 
>  		clkp->usage = clkcon & clkp->ctrlbit ? 1 : 0;
> diff --git a/arch/arm/mach-s3c24xx/clock-s3c2440.c b/arch/arm/mach-
> s3c24xx/clock-s3c2440.c
> index 1069b56..aaf006d 100644
> --- a/arch/arm/mach-s3c24xx/clock-s3c2440.c
> +++ b/arch/arm/mach-s3c24xx/clock-s3c2440.c
> @@ -166,6 +166,9 @@ static struct clk_lookup s3c2440_clk_lookup[] = {
>  	CLKDEV_INIT(NULL, "clk_uart_baud1", &s3c24xx_uclk),
>  	CLKDEV_INIT(NULL, "clk_uart_baud2", &clk_p),
>  	CLKDEV_INIT(NULL, "clk_uart_baud3", &s3c2440_clk_fclk_n),
> +	CLKDEV_INIT("s3c2440-uart.0", "uart", &s3c24xx_clk_uart0),
> +	CLKDEV_INIT("s3c2440-uart.1", "uart", &s3c24xx_clk_uart1),
> +	CLKDEV_INIT("s3c2440-uart.2", "uart", &s3c24xx_clk_uart2),
>  	CLKDEV_INIT("s3c2440-camif", "camera", &s3c2440_clk_cam_upll),
>  };
> 
> diff --git a/arch/arm/plat-samsung/include/plat/clock.h b/arch/arm/plat-
> samsung/include/plat/clock.h
> index 254c3dd..63239f4 100644
> --- a/arch/arm/plat-samsung/include/plat/clock.h
> +++ b/arch/arm/plat-samsung/include/plat/clock.h
> @@ -83,6 +83,11 @@ extern struct clk clk_ext;
>  extern struct clksrc_clk clk_epllref;
>  extern struct clksrc_clk clk_esysclk;
> 
> +/* S3C24XX UART clocks */
> +extern struct clk s3c24xx_clk_uart0;
> +extern struct clk s3c24xx_clk_uart1;
> +extern struct clk s3c24xx_clk_uart2;
> +
>  /* S3C64XX specific clocks */
>  extern struct clk clk_h2;
>  extern struct clk clk_27m;
> --
> 1.7.4.1



From josephl at nvidia.com  Mon Jul 22 00:43:28 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Mon, 22 Jul 2013 12:43:28 +0800
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <51ECB5C1.600@linaro.org>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
 <51E6FF0B.5000708@wwwdotorg.org>
 <1374145726.5610.73.camel@jlo-ubuntu-64.nvidia.com>
 <51E7E27B.9090605@linaro.org>
 <1374218064.24607.1.camel@jlo-ubuntu-64.nvidia.com>
 <51E91A72.6070708@linaro.org>
 <1374462916.15946.14.camel@jlo-ubuntu-64.nvidia.com>
 <51ECB223.5000002@linaro.org>
 <1374467085.15946.16.camel@jlo-ubuntu-64.nvidia.com>
 <51ECB5C1.600@linaro.org>
Message-ID: <1374468208.15946.17.camel@jlo-ubuntu-64.nvidia.com>

On Mon, 2013-07-22 at 12:32 +0800, Daniel Lezcano wrote:
> On 07/22/2013 06:24 AM, Joseph Lo wrote:
> > On Mon, 2013-07-22 at 12:16 +0800, Daniel Lezcano wrote:
> >> On 07/22/2013 05:15 AM, Joseph Lo wrote:
> >>> On Fri, 2013-07-19 at 18:52 +0800, Daniel Lezcano wrote:
> >>>> On 07/19/2013 09:14 AM, Joseph Lo wrote:
> >>>>> On Thu, 2013-07-18 at 20:41 +0800, Daniel Lezcano wrote:
> >>>>>> On 07/18/2013 01:08 PM, Joseph Lo wrote:
> >>>>>>> On Thu, 2013-07-18 at 04:31 +0800, Stephen Warren wrote:
> >>>>>>>> On 07/17/2013 04:15 AM, Joseph Lo wrote:
> >>>>>>>>> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
> >>>>>>>>>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
> >>>>>>>>>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
> >>>>>>>>>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
> >>>>>>>>>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
> >>>>>>>>>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
> >>>>>>>>>>>>> this state.
> >>>>>>>> ... [ discussion of issues with Joesph's patches applied]
> >>>>>>>>>
> > [...]
> >>>>
> >>>> Ok, so the problem occurs with the CPUIDLE_FLAG_TIMER_STOP flag only on
> >>>> tegra114, right ?
> >>>>
> >>>> Sorry, I am a bit lost :)
> >>>>
> >>> Here are the issues that happen after apply CPUIDLE_FLAG_TIMER_STOP.
> >>> 1) Tegra114/30
> >>> The warning message at kernel/time/tick-broadcast.c:667
> >>> tick_broadcast_oneshot_control could be triggered when doing CPU hot
> >>> plug stress test.
> >>
> >> With the fix for tick-broadcast.c [1] ?
> > Yes.
> > 
> >>
> >>> 2) Tegra20
> >>> The system is easy to stick or become lag.
> >>> The CPU hot plug is easy to cause system stick too.
> >>>
> >>> The fix I suggested in another mail looks can fix all the issues above.
> >>> I verified it again today on 3 different Tegra SoC platforms.
> >>
> >> Not sure your patch fixes the problem.
> >>
> >> I am wondering if there isn't a underlaying problem which surface with
> >> the flag.
> 
> Does the attached patch changes something ?
> 
No, the result is the same.




From daniel.lezcano at linaro.org  Mon Jul 22 00:44:37 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Jul 2013 06:44:37 +0200
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
In-Reply-To: <1374468208.15946.17.camel@jlo-ubuntu-64.nvidia.com>
References: <1372152228-16199-1-git-send-email-josephl@nvidia.com>
 <51E439BC.9030608@wwwdotorg.org>
 <1373973447.8538.80.camel@jlo-ubuntu-64.nvidia.com>
 <51E5A438.10004@wwwdotorg.org>
 <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
 <51E6FF0B.5000708@wwwdotorg.org>
 <1374145726.5610.73.camel@jlo-ubuntu-64.nvidia.com>
 <51E7E27B.9090605@linaro.org>
 <1374218064.24607.1.camel@jlo-ubuntu-64.nvidia.com>
 <51E91A72.6070708@linaro.org>
 <1374462916.15946.14.camel@jlo-ubuntu-64.nvidia.com>
 <51ECB223.5000002@linaro.org>
 <1374467085.15946.16.camel@jlo-ubuntu-64.nvidia.com>
 <51ECB5C1.600@linaro.org>
 <1374468208.15946.17.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <51ECB8B5.4020002@linaro.org>

On 07/22/2013 06:43 AM, Joseph Lo wrote:
> On Mon, 2013-07-22 at 12:32 +0800, Daniel Lezcano wrote:
>> On 07/22/2013 06:24 AM, Joseph Lo wrote:
>>> On Mon, 2013-07-22 at 12:16 +0800, Daniel Lezcano wrote:
>>>> On 07/22/2013 05:15 AM, Joseph Lo wrote:
>>>>> On Fri, 2013-07-19 at 18:52 +0800, Daniel Lezcano wrote:
>>>>>> On 07/19/2013 09:14 AM, Joseph Lo wrote:
>>>>>>> On Thu, 2013-07-18 at 20:41 +0800, Daniel Lezcano wrote:
>>>>>>>> On 07/18/2013 01:08 PM, Joseph Lo wrote:
>>>>>>>>> On Thu, 2013-07-18 at 04:31 +0800, Stephen Warren wrote:
>>>>>>>>>> On 07/17/2013 04:15 AM, Joseph Lo wrote:
>>>>>>>>>>> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
>>>>>>>>>>>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
>>>>>>>>>>>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
>>>>>>>>>>>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
>>>>>>>>>>>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
>>>>>>>>>>>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
>>>>>>>>>>>>>>> this state.
>>>>>>>>>> ... [ discussion of issues with Joesph's patches applied]
>>>>>>>>>>>
>>> [...]
>>>>>>
>>>>>> Ok, so the problem occurs with the CPUIDLE_FLAG_TIMER_STOP flag only on
>>>>>> tegra114, right ?
>>>>>>
>>>>>> Sorry, I am a bit lost :)
>>>>>>
>>>>> Here are the issues that happen after apply CPUIDLE_FLAG_TIMER_STOP.
>>>>> 1) Tegra114/30
>>>>> The warning message at kernel/time/tick-broadcast.c:667
>>>>> tick_broadcast_oneshot_control could be triggered when doing CPU hot
>>>>> plug stress test.
>>>>
>>>> With the fix for tick-broadcast.c [1] ?
>>> Yes.
>>>
>>>>
>>>>> 2) Tegra20
>>>>> The system is easy to stick or become lag.
>>>>> The CPU hot plug is easy to cause system stick too.
>>>>>
>>>>> The fix I suggested in another mail looks can fix all the issues above.
>>>>> I verified it again today on 3 different Tegra SoC platforms.
>>>>
>>>> Not sure your patch fixes the problem.
>>>>
>>>> I am wondering if there isn't a underlaying problem which surface with
>>>> the flag.
>>
>> Does the attached patch changes something ?
>>
> No, the result is the same.

Ok, thanks for testing.

I will look more closely to the issue in the next days.


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From sachin.kamat at linaro.org  Mon Jul 22 00:30:14 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Mon, 22 Jul 2013 10:00:14 +0530
Subject: [PATCH v2 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
Message-ID: <1374467414-25801-1-git-send-email-sachin.kamat@linaro.org>

With the recent cleanup in Exynos platform code notably commits
17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
Exynos4412 which have more than the default number of GPIOs. Thus define
this number in KConfig file. Without this patch we get the following errors
during boot:

gpiochip_add: gpios 251..258 (gpv0) failed to register
samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
error code: -22
samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
Cc: Tomasz Figa <t.figa at samsung.com>
---
Changes since v1:
* Changed default number to 285 (as required by 4412).
---
 arch/arm/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..f4841a2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1605,6 +1605,7 @@ config ARCH_NR_GPIO
 	default 392 if ARCH_U8500
 	default 352 if ARCH_VT8500
 	default 288 if ARCH_SUNXI
+	default 285 if ARCH_EXYNOS
 	default 264 if MACH_H4700
 	default 0
 	help
-- 
1.7.9.5



From mturquette at linaro.org  Mon Jul 22 00:42:54 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Sun, 21 Jul 2013 21:42:54 -0700
Subject: [PATCH 1/1] of/documentation: Fix a typo in
 exynos5250-clock.txt
In-Reply-To: <0ab501ce867e$0adadd40$209097c0$%kim@samsung.com>
References: <1373012281-26433-1-git-send-email-sachin.kamat@linaro.org>
 <0ab501ce867e$0adadd40$209097c0$%kim@samsung.com>
Message-ID: <20130722044254.5453.82900@quantum>

Quoting Kukjin Kim (2013-07-21 18:51:54)
> Sachin Kamat wrote:
> > 
> > The clocks should be numbered sequentially as they are represented as
> > enum values in the clock driver.
> > 
> > Typo introduced by commit 17d4caccef ("clk: exynos5250: register
> > display block gate clocks to common clock framework")
> > 
> > Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> > ---
> >  .../devicetree/bindings/clock/exynos5250-clock.txt |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > index 781a627..1a05761 100644
> > --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > @@ -154,7 +154,7 @@ clock which they consume.
> >    dsim0                      341
> >    dp                 342
> >    mixer                      343
> > -  hdmi                       345
> > +  hdmi                       344
> > 
> >  Example 1: An example of a clock controller node is listed below.
> > 
> > --
> > 1.7.9.5
> 
> Looks OK to me.
> 
> Mike, do you want me to take into the samsung tree?

I've pulled this into clk-next.

Thanks!
Mike

> 
> Thanks,
> Kukjin


From sachin.kamat at linaro.org  Mon Jul 22 00:54:59 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Mon, 22 Jul 2013 10:24:59 +0530
Subject: [PATCH 1/1] of/documentation: Fix a typo in
 exynos5250-clock.txt
In-Reply-To: <20130722044254.5453.82900@quantum>
References: <1373012281-26433-1-git-send-email-sachin.kamat@linaro.org>
 <0ab501ce867e$0adadd40$209097c0$%kim@samsung.com>
 <20130722044254.5453.82900@quantum>
Message-ID: <CAK9yfHySzy620riyCBHKUVH8O7v74GrtgDrjVn4yd8KYKT0zSA@mail.gmail.com>

On 22 July 2013 10:12, Mike Turquette <mturquette at linaro.org> wrote:
> Quoting Kukjin Kim (2013-07-21 18:51:54)
>> Sachin Kamat wrote:
>> >
>> > The clocks should be numbered sequentially as they are represented as
>> > enum values in the clock driver.
>> >
>> > Typo introduced by commit 17d4caccef ("clk: exynos5250: register
>> > display block gate clocks to common clock framework")
>> >
>> > Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
>> > ---
>> >  .../devicetree/bindings/clock/exynos5250-clock.txt |    2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>> > b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>> > index 781a627..1a05761 100644
>> > --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>> > +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>> > @@ -154,7 +154,7 @@ clock which they consume.
>> >    dsim0                      341
>> >    dp                 342
>> >    mixer                      343
>> > -  hdmi                       345
>> > +  hdmi                       344
>> >
>> >  Example 1: An example of a clock controller node is listed below.
>> >
>> > --
>> > 1.7.9.5
>>
>> Looks OK to me.
>>
>> Mike, do you want me to take into the samsung tree?
>
> I've pulled this into clk-next.

Thanks Mike.
Please also consider the following patch series:

http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20829
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20582

-- 
With warm regards,
Sachin


From paul at pwsan.com  Mon Jul 22 00:56:05 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 22 Jul 2013 04:56:05 +0000 (UTC)
Subject: [GIT PULL] ARM: OMAP2+: PRCM: drop macros not currently in use
Message-ID: <alpine.DEB.2.02.1307220454470.4804@utopia.booyaka.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tony,

Sorry for the delay on this - wanted to make sure it passed the local
testbed before sending it upstream.

The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b:

  Linux 3.11-rc2 (2013-07-21 12:05:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.11-rc/omap-fixes-a

for you to fetch changes up to 11dab344053f726fe17ede95aa52c1eea1258a66:

  ARM: OMAP5: PRM/CM: Cleanup unused header (2013-07-21 22:10:25 -0600)

- ----------------------------------------------------------------
This series removes the currently-unused PRCM macros from
arch/arm/mach-omap2.

Basic test logs are available at:

http://www.pwsan.com/omap/testlogs/drop_unused_prcm_macros_v3.11-rc/20130721211401/

Once, years ago, we thought that it would be good to document the PRCM
register bits in the Linux codebase.  Most folks in the broader
community did not have access to the same documentation, so we thought
that they might be able to use these bits to fix bugs and improve the
code.

We were also able to autogenerate most of these macros, so it was
thought that defining them in advance would reduce the risk of error,
inconsistencies, and merge conflicts caused when patch sets
incrementally defined them by hand.

Well, nice thoughts.  But the first rationale was rendered partially
obsolete when TI started to release public TRM documentation PDFs at
some point in the OMAP3 timeframe.  (Despite their weaknesses, TI's
public OMAP TRMs remain the most useful public documentation available
for any ARM Linux SoC -- at least to the extent of my knowledge.)  And
then the current Linux development tropism towards
development-by-negative-diffstat obliterated the remainder of the
above two philosophies.

So, for the few, the masochistic, out there who wish to continue
developing TI PRCM code, I would ask that you resurrect any
additionally-needed macros from these commits, rather than writing
them manually.  Purely for the sake of a pleasant atavism, perhaps; the
way one appreciates a used bookstore, or a video rental store...

And thanks to the upstream maintainers for being patient while we
adjust.

- ----------------------------------------------------------------
Rajendra Nayak (4):
      ARM: OMAP2: PRM/CM: Cleanup unused header
      ARM: OMAP3: PRM/CM: Cleanup unused header
      ARM: OMAP4: PRM/CM: Cleanup unused header
      ARM: OMAP5: PRM/CM: Cleanup unused header

 arch/arm/mach-omap2/cm-regbits-24xx.h       |  318 ----
 arch/arm/mach-omap2/cm-regbits-33xx.h       |  749 --------
 arch/arm/mach-omap2/cm-regbits-34xx.h       |  632 -------
 arch/arm/mach-omap2/cm-regbits-44xx.h       | 1558 ---------------
 arch/arm/mach-omap2/cm-regbits-54xx.h       | 1633 ----------------
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c  |    1 -
 arch/arm/mach-omap2/powerdomains54xx_data.c |    1 -
 arch/arm/mach-omap2/prm-regbits-24xx.h      |  247 ---
 arch/arm/mach-omap2/prm-regbits-33xx.h      |  306 ---
 arch/arm/mach-omap2/prm-regbits-34xx.h      |  481 -----
 arch/arm/mach-omap2/prm-regbits-44xx.h      | 2226 ----------------------
 arch/arm/mach-omap2/prm-regbits-54xx.h      | 2701 ---------------------------
 12 files changed, 10853 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/prm-regbits-54xx.h
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)


/F87lgCvP2OvTuy3eABF
=NoFh
-----END PGP SIGNATURE-----


From paul at pwsan.com  Mon Jul 22 01:29:35 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 22 Jul 2013 05:29:35 +0000 (UTC)
Subject: [PATCH] ARM: OMAP3EVM: Marking omap3_evm_display_init() with
 CONFIG_BROKEN
Message-ID: <alpine.DEB.2.02.1307220523380.4804@utopia.booyaka.com>

From: Lokesh Vutla <lokeshvutla at ti.com>

On 37xx EVM non-dt boot fails with current mainline,
because of broken GPIO numbering in the board file
that uses hardcoded GPIOs.

So marking omap3_evm_display_init() with CONFIG_BROKEN
for now as suggested by Tony as per the below link:
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg90399.html

Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
Tested-by: Paul Walmsley <paul at pwsan.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>

---

Hi -stablers,

OMAP37xx EVM does not boot on v3.10 without this patch, so please consider 
it for the v3.10 stable releases.  It is upstream already as commit ID 
8fb61e8d84e673eebf31e564a83bb71a50b1ed48.  Perhaps if I had managed to 
test it sooner, we could have gotten it up during v3.10-rc, but, alas, 
stable it is...

 arch/arm/mach-omap2/board-omap3evm.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index f76d0de..278bf25 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -174,6 +174,7 @@ static struct panel_sharp_ls037v7dw01_data omap3_evm_lcd_data = {
 	.ud_gpio = OMAP3EVM_LCD_PANEL_UD,
 };
 
+#ifdef CONFIG_BROKEN
 static void __init omap3_evm_display_init(void)
 {
 	int r;
@@ -193,6 +194,7 @@ static void __init omap3_evm_display_init(void)
 	else
 		gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
 }
+#endif
 
 static struct omap_dss_device omap3_evm_lcd_device = {
 	.name			= "lcd",
@@ -715,7 +717,9 @@ static void __init omap3_evm_init(void)
 
 	omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
 	omap3evm_init_smsc911x();
+#ifdef CONFIG_BROKEN
 	omap3_evm_display_init();
+#endif
 	omap3_evm_wl12xx_init();
 	omap_twl4030_audio_init("omap3evm", NULL);
 }
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


From anup.patel at linaro.org  Mon Jul 22 01:31:59 2013
From: anup.patel at linaro.org (Anup Patel)
Date: Mon, 22 Jul 2013 11:01:59 +0530
Subject: [PATCH V4] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene host
Message-ID: <1374471119-26461-1-git-send-email-anup.patel@linaro.org>

This patch allows us to have X-Gene guest VCPU when using KVM arm64
on APM X-Gene host.

We add KVM_ARM_TARGET_XGENE_POTENZA for X-Gene Potenza compatible
guest VCPU and we return KVM_ARM_TARGET_XGENE_POTENZA in kvm_target_cpu()
when running on X-Gene host with Potenza core.

V4:
 - Remove default case from switch statments in kvm_target_cpu()

V3:
 - Reduce multiple "return -EINVAL" in kvm_target_cpu()

V2:
 - Renamed KVM_ARM_TARGET_XGENE_V8 to KVM_ARM_TARGET_XGENE_POTENZA

V1:
 - Initial patch with target named as KVM_ARM_TARGET_XGENE_V8

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
---
 arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
 arch/arm64/kvm/guest.c               |   32 +++++++++++++++++++-------------
 arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
 3 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 5031f42..d9f026b 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -55,8 +55,9 @@ struct kvm_regs {
 #define KVM_ARM_TARGET_AEM_V8		0
 #define KVM_ARM_TARGET_FOUNDATION_V8	1
 #define KVM_ARM_TARGET_CORTEX_A57	2
+#define KVM_ARM_TARGET_XGENE_POTENZA	3
 
-#define KVM_ARM_NUM_TARGETS		3
+#define KVM_ARM_NUM_TARGETS		4
 
 /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
 #define KVM_ARM_DEVICE_TYPE_SHIFT	0
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 2c3ff67..d7bf7d6 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -207,20 +207,26 @@ int __attribute_const__ kvm_target_cpu(void)
 	unsigned long implementor = read_cpuid_implementor();
 	unsigned long part_number = read_cpuid_part_number();
 
-	if (implementor != ARM_CPU_IMP_ARM)
-		return -EINVAL;
+	switch (implementor) {
+	case ARM_CPU_IMP_ARM:
+		switch (part_number) {
+		case ARM_CPU_PART_AEM_V8:
+			return KVM_ARM_TARGET_AEM_V8;
+		case ARM_CPU_PART_FOUNDATION:
+			return KVM_ARM_TARGET_FOUNDATION_V8;
+		case ARM_CPU_PART_CORTEX_A57:
+			return KVM_ARM_TARGET_CORTEX_A57;
+		};
+		break;
+	case ARM_CPU_IMP_APM:
+		switch (part_number) {
+		case APM_CPU_PART_POTENZA:
+			return KVM_ARM_TARGET_XGENE_POTENZA;
+		};
+		break;
+	};
 
-	switch (part_number) {
-	case ARM_CPU_PART_AEM_V8:
-		return KVM_ARM_TARGET_AEM_V8;
-	case ARM_CPU_PART_FOUNDATION:
-		return KVM_ARM_TARGET_FOUNDATION_V8;
-	case ARM_CPU_PART_CORTEX_A57:
-		/* Currently handled by the generic backend */
-		return KVM_ARM_TARGET_CORTEX_A57;
-	default:
-		return -EINVAL;
-	}
+	return -EINVAL;
 }
 
 int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
index 4268ab9..8fe6f76 100644
--- a/arch/arm64/kvm/sys_regs_generic_v8.c
+++ b/arch/arm64/kvm/sys_regs_generic_v8.c
@@ -90,6 +90,9 @@ static int __init sys_reg_genericv8_init(void)
 					  &genericv8_target_table);
 	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_CORTEX_A57,
 					  &genericv8_target_table);
+	kvm_register_target_sys_reg_table(KVM_ARM_TARGET_XGENE_POTENZA,
+					  &genericv8_target_table);
+
 	return 0;
 }
 late_initcall(sys_reg_genericv8_init);
-- 
1.7.9.5



From chanho61.park at samsung.com  Mon Jul 22 01:38:35 2013
From: chanho61.park at samsung.com (Chanho Park)
Date: Mon, 22 Jul 2013 14:38:35 +0900
Subject: [PATCH] dts: arm: add arm-pmu node for exynos4412
Message-ID: <1374471515-12403-1-git-send-email-chanho61.park@samsung.com>

The Exynos4412 has 4 cpus and each has a performance counter.
Thus, we should define 4 interrupts which are combined by irq-combiner for arm
pmu.

Signed-off-by: Chanho Park <chanho61.park at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/exynos4412.dtsi |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index e743e67..cfad655 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -35,6 +35,12 @@
 			     <0 107 0>, <0 108 0>, <0 48 0>, <0 42 0>;
 	};
 
+	pmu {
+		compatible = "arm,cortex-a9-pmu";
+		interrupt-parent = <&combiner>;
+		interrupts = <2 2>, <3 2>, <18 2>, <19 2>;
+	};
+
 	mct at 10050000 {
 		compatible = "samsung,exynos4412-mct";
 		reg = <0x10050000 0x800>;
-- 
1.7.9.5



From sathyap at ti.com  Mon Jul 22 02:03:17 2013
From: sathyap at ti.com (Sathya Prakash M R)
Date: Mon, 22 Jul 2013 11:33:17 +0530
Subject: [PATCH 2/2] ARM: DTS: AM43x: Add DSS node
In-Reply-To: <1374472997-9653-1-git-send-email-sathyap@ti.com>
References: <1374472997-9653-1-git-send-email-sathyap@ti.com>
Message-ID: <1374472997-9653-3-git-send-email-sathyap@ti.com>

Add device node for DSS module for AM43x

Signed-off-by: Sathya Prakash M R <sathyap at ti.com>
---
 arch/arm/boot/dts/am4372.dtsi |   27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..f10fc0a 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,32 @@
 			compatible = "ti,am4372-counter32k","ti,omap-counter32k";
 			reg = <0x44e86000 0x40>;
 		};
+
+		dss: dss at 4832A000 {
+			compatible = "ti,omap3-dss", "simple-bus";
+			reg = <0x4832A000 0x200>;
+			ti,hwmods = "dss_core";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			dispc at 4832A400 {
+				compatible = "ti,omap3-dispc";
+				reg = <0x4832A400 0x400>;
+				interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+				ti,hwmods = "dss_dispc";
+			};
+
+			dpi: dpi {
+				compatible = "ti,omap3-dpi";
+			};
+
+			rfbi: rfbi at 4832A800 {
+				compatible = "ti,omap3-rfbi";
+				reg = <0x4832A800 0x100>;
+				ti,hwmods = "dss_rfbi";
+			};
+
+		};
 	};
 };
-- 
1.7.9.5



From sathyap at ti.com  Mon Jul 22 02:03:16 2013
From: sathyap at ti.com (Sathya Prakash M R)
Date: Mon, 22 Jul 2013 11:33:16 +0530
Subject: [PATCH 1/2] ARM: OMAP2+: AM43x - Add DSS hwmod
In-Reply-To: <1374472997-9653-1-git-send-email-sathyap@ti.com>
References: <1374472997-9653-1-git-send-email-sathyap@ti.com>
Message-ID: <1374472997-9653-2-git-send-email-sathyap@ti.com>

Add DSS hwmod struct for AM43x SOC.

Signed-off-by: Sathya Prakash M R <sathyap at ti.com>
---
This is based on below patch series which is yet to be merged
http://permalink.gmane.org/gmane.linux.ports.arm.omap/100892

 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |   85 ++++++++++++++++++++++++++++
 arch/arm/mach-omap2/prcm43xx.h             |    1 +
 2 files changed, 86 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 319780e..a1884ce 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1937,6 +1937,55 @@ static struct omap_hwmod am43xx_spi4_hwmod = {
 	.dev_attr	= &mcspi_attrib,
 };
 
+/* Display sub system - DSS */
+
+static struct omap_hwmod_dma_info am43xx_dss_sdma_chs[] = {
+	{ .name = "dispc", .dma_req = 5 },
+	{ .dma_req = -1 }
+
+static struct omap_hwmod am43xx_dss_core_hwmod = {
+	.name		= "dss_core",
+	.class		= &omap2_dss_hwmod_class,
+	.clkdm_name	= "dss_clkdm",
+	.main_clk	= "disp_clk",
+	.sdma_reqs	= am43xx_dss_sdma_chs,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+/* display controller -dispc*/
+
+static struct omap_hwmod am43xx_dss_dispc_hwmod = {
+	.name		= "dss_dispc",
+	.class		= &omap3_dispc_hwmod_class,
+	.clkdm_name	= "dss_clkdm",
+	.main_clk	= "disp_clk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+};
+
+/*RFBI*/
+
+static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
+	.name		= "dss_rfbi",
+	.class		= &omap2_rfbi_hwmod_class,
+	.clkdm_name	= "dss_clkdm",
+	.main_clk	= "disp_clk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+};
+
+
 /*
  * Interfaces
  */
@@ -2874,6 +2923,38 @@ static struct omap_hwmod_ocp_if am43xx_l3_main__pruss = {
 	.user		= OCP_USER_MPU,
 };
 
+/* DSS -> L3 Main */
+static struct omap_hwmod_ocp_if am43xx_dss__l3_main = {
+	.master		= &am43xx_dss_core_hwmod,
+	.slave		= &am33xx_l3_main_hwmod,
+	.clk		= "disp_clk"
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4-ls -> DSS */
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_dss_core_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4_ls -> dss_dispc */
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_dispc = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_dss_dispc_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4_ls -> dss_rfbi */
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi = {
+	.master		= &am33xx_l4_ls_hwmod,
+	.slave		= &am43xx_dss_rfbi_hwmod,
+	.clk		= "l4ls_gclk",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 #define CLKCTRL(oh, clkctrl) ((oh).prcm.omap4.clkctrl_offs = (clkctrl))
 
 static void am43xx_hwmod_clkctrl(void)
@@ -3109,6 +3190,10 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
 	&am43xx_l4_ls__mcspi3,
 	&am43xx_l4_ls__mcspi4,
 	&am43xx_l3_main__pruss,
+	&am43xx_dss__l3_main,
+	&am43xx_l4_ls__dss,
+	&am43xx_l4_ls__dss_dispc,
+	&am43xx_l4_ls__dss_rfbi,
 	NULL,
 };
 
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index 0d05278..4dfd9be 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -144,5 +144,6 @@
 #define	AM43XX_CM_PER_SPI2_CLKCTRL_OFFSET		0x0510
 #define	AM43XX_CM_PER_SPI3_CLKCTRL_OFFSET		0x0518
 #define	AM43XX_CM_PER_SPI4_CLKCTRL_OFFSET		0x0520
+#define	AM43XX_CM_PER_DSS_CLKCTRL_OFFSET		0x0a00
 
 #endif
-- 
1.7.9.5



From sathyap at ti.com  Mon Jul 22 02:03:15 2013
From: sathyap at ti.com (Sathya Prakash M R)
Date: Mon, 22 Jul 2013 11:33:15 +0530
Subject: [PATCH 0/2] Add DSS nodes for AM43x
Message-ID: <1374472997-9653-1-git-send-email-sathyap@ti.com>

DSS support for AM437x is added in this patch series.
Patch #1 adds the hwmod entries and
patch #2 adds the DT entry.

Sathya Prakash M R (2):
  ARM: OMAP2+: AM43x - Add DSS hwmod
  ARM: DTS: AM43x: Add DSS node

 arch/arm/boot/dts/am4372.dtsi              |   27 +++++++++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |   85 ++++++++++++++++++++++++++++
 arch/arm/mach-omap2/prcm43xx.h             |    1 +
 3 files changed, 113 insertions(+)

-- 
1.7.9.5



From sajjan.linux at gmail.com  Mon Jul 22 02:15:27 2013
From: sajjan.linux at gmail.com (Vikas Sajjan)
Date: Mon, 22 Jul 2013 11:45:27 +0530
Subject: [PATCH v7 00/11] Add generic set_rate clk_ops for PLL35xx and
 PLL36xx for samsung SoCs
In-Reply-To: <CAKew6eVW6dOzLRN2CG8jT3Oo1uzKrXqi1aRYkAHmUu61dBSDpA@mail.gmail.com>
References: <1370943076-13461-1-git-send-email-yadi.brar@samsung.com>
 <CAKew6eUOy4=D08v_iq7CTRY5gvt37VAN7Z7WOr2Yt25znDJb2g@mail.gmail.com>
 <CAGm_ybiVZOPBJJ0bYX33wafn1So6aqSAnk7myXZ+Z+RfLBeBQw@mail.gmail.com>
 <1524664.UCV47tfIRU@flatron> <20130621163143.9136.28807@quantum>
 <51C85F8F.9050501@samsung.com> <20130624190227.20448.68120@quantum>
 <007001ce7149$1f683f40$5e38bdc0$%kim@samsung.com>
 <CAKew6eVW6dOzLRN2CG8jT3Oo1uzKrXqi1aRYkAHmUu61dBSDpA@mail.gmail.com>
Message-ID: <CAGm_ybj31kv=iW2YKsHnBRJ741G2amSNAJf+Mx8Z-JMoVynZ8w@mail.gmail.com>

Hi Kukjin / Mike,

Can you apply this series

On Tue, Jul 16, 2013 at 7:10 PM, Yadwinder Singh Brar
<yadi.brar01 at gmail.com> wrote:
> Hi Kukjin / Mike,
>
> On Tue, Jun 25, 2013 at 7:40 AM, Kukjin Kim <kgene.kim at samsung.com> wrote:
>> Mike Turquette wrote:
>>>
>>> Quoting Kukjin Kim (2013-06-24 08:02:39)
>>> > On 06/22/13 01:31, Mike Turquette wrote:
>>> > >
>>> > > Acked-by: Mike Turquette<mturquette at linaro.org>
>>> > >
>>> > > Or I can take this through the clk tree. Either way is fine.
>>> > >
>>> > Mike, please go ahead taking this series into the clk tree for 3.11.
>>>
>>> Actually it might be better for you to take it. Patch #5 relies on
>>> drivers/clk/samsung/clk-exynos5420.c which only exists in the samsung
>>> tree.  It was introduced by commit 1609027f, "clk: exynos5420: register
>>> clocks using common clock framework".
>>>
>> Yes, you're right. It depends on soc-exynos5420 stuff in samsung tree.
>>
>>> And these patches need to be applied with some fuzz to the clk tree due
>>> to other changes which are not in my tree and only present in yours.
>>>
>>> The best two options are either for you to take this series or it can be
>>> rebased on top of clk-next, after which I'll apply it.
>>>
>> Let me try to send this series via samsung tree for v3.11 but I'm not sure because it's a little bit late for arm-soc tree.
>>
>> Thanks for your ack, just note I will send to arm-soc tonight in my time.
>>
>
> Can we get this series merge now in any of trees.
> Please let me if its required to rebase it.
>
> Regards,
> Yadwinder


From chanho61.park at samsung.com  Mon Jul 22 02:49:24 2013
From: chanho61.park at samsung.com (Chanho Park)
Date: Mon, 22 Jul 2013 15:49:24 +0900
Subject: [PATCH 0/3] device tree support for exynos rotator
Message-ID: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>

This patchset includes dt support for exynos rotator.
The exynos4 platform is only dt-based since 3.10, we should convert driver data
and ids to dt-based parsing methods. The rotator driver has a limit table to
get size limit. The minimum size of RGB888 format is 8 x 8 and maximum size is
8K x 8K. The other format, YCbCr420 2-Plane has 32 x 32 min size and 32K x 32K
max size. Each format should be multiple of 'align' value.

Chanho Park (3):
  drm/exynos: add device tree support for rotator
  drm/exynos: add dt-binding documentation for rotator
  dts: ARM: add a rotator node for exynos4

 .../bindings/drm/exynos/samsung-rotator.txt        |   35 +++++++
 arch/arm/boot/dts/exynos4.dtsi                     |   23 ++++
 drivers/gpu/drm/exynos/exynos_drm_rotator.c        |  110 ++++++++++++++------
 3 files changed, 138 insertions(+), 30 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt

-- 
1.7.9.5



From chanho61.park at samsung.com  Mon Jul 22 02:49:26 2013
From: chanho61.park at samsung.com (Chanho Park)
Date: Mon, 22 Jul 2013 15:49:26 +0900
Subject: [PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
In-Reply-To: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
References: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
Message-ID: <1374475767-30085-3-git-send-email-chanho61.park@samsung.com>

This patch adds a dt-binding document for exynos rotator. It describes which
nodes should be defined to use the rotator.

Signed-off-by: Chanho Park <chanho61.park at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 .../bindings/drm/exynos/samsung-rotator.txt        |   35 ++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt

diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
new file mode 100644
index 0000000..6b1d704
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
@@ -0,0 +1,35 @@
+* Samsung Image Rotator
+
+Required properties:
+  - compatible : value should be the "samsung,exynos4210".
+  - reg : Physical base address of the IP registers and length of memory
+	  mapped region.
+  - interrupts : interrupt number to the CPU.
+  - clocks : clock number of exynos4 rotator clock.
+  - clocks : clock name of rotator
+  - status : "okay" or "disabled"
+  - limit table for image formats : min_w/min_h/max_w/max_h for min/max of image
+
+Example:
+	rotator: rotator at 12810000 {
+		compatible = "samsung,exynos4210-rotator";
+		reg = <0x12810000 0x1000>;
+		interrupts = <0 83 0>;
+		clocks = <&clock 278>;
+		clock-names = "rotator";
+		status = "disabled";
+		ycbcr420_2p {
+			min_w = <32>;
+			min_h = <32>;
+			max_w = <32768>;
+			max_h = <32768>;
+			align = <3>;
+		};
+		rgb888 {
+			min_w = <8>;
+			min_h = <8>;
+			max_w = <8192>;
+			max_h = <8192>;
+			align = <2>;
+		};
+	};
-- 
1.7.9.5



From chanho61.park at samsung.com  Mon Jul 22 02:49:25 2013
From: chanho61.park at samsung.com (Chanho Park)
Date: Mon, 22 Jul 2013 15:49:25 +0900
Subject: [PATCH 1/3] drm/exynos: add device tree support for rotator
In-Reply-To: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
References: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
Message-ID: <1374475767-30085-2-git-send-email-chanho61.park@samsung.com>

The exynos4 platform is only dt-based since 3.10, we should convert driver data
and ids to dt-based parsing methods. The rotator driver has a limit table to get
size limit. The minimum size of RGB888 format is 8 x 8 and maximum size is 8K x
8K. The other format, YCbCr420 2-Plane has 32 x 32 min size and 32K x 32K max
size. Each format should be multiple of 'align' value.

Signed-off-by: Chanho Park <chanho61.park at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  110 +++++++++++++++++++--------
 1 file changed, 80 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 427640a..b353a10 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -96,7 +96,7 @@ struct rot_context {
 	struct resource	*regs_res;
 	void __iomem	*regs;
 	struct clk	*clock;
-	struct rot_limit_table	*limit_tbl;
+	struct rot_limit_table	limit_tbl;
 	int	irq;
 	int	cur_buf_id[EXYNOS_DRM_OPS_MAX];
 	bool	suspended;
@@ -167,7 +167,7 @@ static irqreturn_t rotator_irq_handler(int irq, void *arg)
 static void rotator_align_size(struct rot_context *rot, u32 fmt, u32 *hsize,
 		u32 *vsize)
 {
-	struct rot_limit_table *limit_tbl = rot->limit_tbl;
+	struct rot_limit_table *limit_tbl = &rot->limit_tbl;
 	struct rot_limit *limit;
 	u32 mask, val;
 
@@ -632,6 +632,72 @@ static int rotator_ippdrv_start(struct device *dev, enum drm_exynos_ipp_cmd cmd)
 	return 0;
 }
 
+static const struct of_device_id exynos_rotator_match[] = {
+	{
+		.compatible = "samsung,exynos4210-rotator",
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, exynos_rotator_match);
+
+static int rotator_parse_dt_tbl(struct device_node *np, struct rot_limit *rlim)
+{
+	int ret;
+
+	ret = of_property_read_u32(np, "min_w", &rlim->min_w);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(np, "min_h", &rlim->min_h);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(np, "max_w", &rlim->max_w);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(np, "max_h", &rlim->max_h);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(np, "align", &rlim->align);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int rotator_parse_dt(struct device *dev, struct rot_context *rot)
+{
+	struct device_node *ycbcr_node, *rgb888_node;
+	int ret;
+
+	ycbcr_node = of_get_child_by_name(dev->of_node, "ycbcr420_2p");
+	if (!ycbcr_node) {
+		dev_err(dev, "can't find ycbcr420_2p node\n");
+		return -ENODEV;
+	}
+
+	rgb888_node = of_get_child_by_name(dev->of_node, "rgb888");
+	if (!rgb888_node) {
+		dev_err(dev, "can't find rgb888 node\n");
+		return -ENODEV;
+	}
+
+	ret = rotator_parse_dt_tbl(ycbcr_node, &rot->limit_tbl.ycbcr420_2p);
+	if (ret) {
+		dev_err(dev, "failed to parse ycbcr420 data\n");
+		return ret;
+	}
+	ret = rotator_parse_dt_tbl(rgb888_node, &rot->limit_tbl.rgb888);
+	if (ret) {
+		dev_err(dev, "failed to parse rgb888 data\n");
+		return ret;
+	}
+
+	return 0;
+}
+
 static int rotator_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -639,14 +705,23 @@ static int rotator_probe(struct platform_device *pdev)
 	struct exynos_drm_ippdrv *ippdrv;
 	int ret;
 
+	if (!dev->of_node) {
+		dev_err(dev, "Cannot find device tree node\n");
+		return -ENODEV;
+	}
+
 	rot = devm_kzalloc(dev, sizeof(*rot), GFP_KERNEL);
 	if (!rot) {
 		dev_err(dev, "failed to allocate rot\n");
 		return -ENOMEM;
 	}
 
-	rot->limit_tbl = (struct rot_limit_table *)
-				platform_get_device_id(pdev)->driver_data;
+	ret = rotator_parse_dt(dev, rot);
+	if (ret) {
+		dev_err(dev, "failed parse dt info\n");
+		devm_kfree(dev, rot);
+		return ret;
+	}
 
 	rot->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	rot->regs = devm_ioremap_resource(dev, rot->regs_res);
@@ -718,31 +793,6 @@ static int rotator_remove(struct platform_device *pdev)
 	return 0;
 }
 
-static struct rot_limit_table rot_limit_tbl = {
-	.ycbcr420_2p = {
-		.min_w = 32,
-		.min_h = 32,
-		.max_w = SZ_32K,
-		.max_h = SZ_32K,
-		.align = 3,
-	},
-	.rgb888 = {
-		.min_w = 8,
-		.min_h = 8,
-		.max_w = SZ_8K,
-		.max_h = SZ_8K,
-		.align = 2,
-	},
-};
-
-static struct platform_device_id rotator_driver_ids[] = {
-	{
-		.name		= "exynos-rot",
-		.driver_data	= (unsigned long)&rot_limit_tbl,
-	},
-	{},
-};
-
 static int rotator_clk_crtl(struct rot_context *rot, bool enable)
 {
 	if (enable) {
@@ -804,10 +854,10 @@ static const struct dev_pm_ops rotator_pm_ops = {
 struct platform_driver rotator_driver = {
 	.probe		= rotator_probe,
 	.remove		= rotator_remove,
-	.id_table	= rotator_driver_ids,
 	.driver		= {
 		.name	= "exynos-rot",
 		.owner	= THIS_MODULE,
 		.pm	= &rotator_pm_ops,
+		.of_match_table = of_match_ptr(exynos_rotator_match),
 	},
 };
-- 
1.7.9.5



From chanho61.park at samsung.com  Mon Jul 22 02:49:27 2013
From: chanho61.park at samsung.com (Chanho Park)
Date: Mon, 22 Jul 2013 15:49:27 +0900
Subject: [PATCH 3/3] dts: ARM: add a rotator node for exynos4
In-Reply-To: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
References: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
Message-ID: <1374475767-30085-4-git-send-email-chanho61.park@samsung.com>

This patch adds a device node of rotator for exynos4 platform. It has proper
register and clock information. It also has limit table to get restrictions of
the image size.

Signed-off-by: Chanho Park <chanho61.park at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/exynos4.dtsi |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 3f94fe8..7d7dcef 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -398,4 +398,27 @@
 		samsung,power-domain = <&pd_lcd0>;
 		status = "disabled";
 	};
+
+	rotator: rotator at 12810000 {
+		compatible = "samsung,exynos4210-rotator";
+		reg = <0x12810000 0x1000>;
+		interrupts = <0 83 0>;
+		clocks = <&clock 278>;
+		clock-names = "rotator";
+		status = "disabled";
+		ycbcr420_2p {
+			min_w = <32>;
+			min_h = <32>;
+			max_w = <32768>;
+			max_h = <32768>;
+			align = <3>;
+		};
+		rgb888 {
+			min_w = <8>;
+			min_h = <8>;
+			max_w = <8192>;
+			max_h = <8192>;
+			align = <2>;
+		};
+	};
 };
-- 
1.7.9.5



From acourbot at nvidia.com  Mon Jul 22 02:56:09 2013
From: acourbot at nvidia.com (Alexandre Courbot)
Date: Mon, 22 Jul 2013 15:56:09 +0900
Subject: [PATCH] decompressors: fix "no limit" output buffer length
Message-ID: <1374476169-32194-1-git-send-email-acourbot@nvidia.com>

When decompressing into memory, the output buffer length is set to some
arbitrarily high value (0x7fffffff) to indicate the output is,
virtually, unlimited in size.

The problem with this is that some platforms have their physical memory
at high physical addresses (0x80000000 or more), and that the output
buffer address and its "unlimited" length cannot be added without
overflowing. An example of this can be found in inflate_fast():

/* next_out is the output buffer address */
out = strm->next_out - OFF;
/* avail_out is the output buffer size. end will overflow if the output
 * address is >= 0x80000104 */
end = out + (strm->avail_out - 257);

This has huge consequences on the performance of kernel decompression,
since the following exit condition of inflate_fast() will be always
true:

} while (in < last && out < end);

Indeed, "end" has overflowed and is now always lower than "out". As a
result, inflate_fast() will return after processing one single byte of
input data, and will thus need to be called an unreasonably high number
of times. This probably went unnoticed because kernel decompression is
fast enough even with this issue.

Nonetheless, adjusting the output buffer length in such a way that the
above pointer arithmetic never overflows results in a kernel
decompression that is about 3 times faster on affected machines.

Signed-off-by: Alexandre Courbot <acourbot at nvidia.com>
---
 lib/decompress_inflate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/decompress_inflate.c b/lib/decompress_inflate.c
index 19ff89e..d619b28 100644
--- a/lib/decompress_inflate.c
+++ b/lib/decompress_inflate.c
@@ -48,7 +48,7 @@ STATIC int INIT gunzip(unsigned char *buf, int len,
 		out_len = 0x8000; /* 32 K */
 		out_buf = malloc(out_len);
 	} else {
-		out_len = 0x7fffffff; /* no limit */
+		out_len = ((size_t)~0) - (size_t)out_buf; /* no limit */
 	}
 	if (!out_buf) {
 		error("Out of memory while allocating output buffer");
-- 
1.8.3.2



From r65037 at freescale.com  Mon Jul 22 03:02:56 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Mon, 22 Jul 2013 07:02:56 +0000
Subject: [v3 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <20130706020737.GA9029@mtj.dyndns.org>
References: <1373017942-12583-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373017942-12583-4-git-send-email-Hong-Xing.Zhu@freescale.com>
 <20130705174305.GA28088@mtj.dyndns.org>
 <0E83723C55F66F43A6041464FE31119D31432D@039-SN2MPN1-012.039d.mgd.msft.net>
 <20130706020737.GA9029@mtj.dyndns.org>
Message-ID: <0E83723C55F66F43A6041464FE31119D3441A3@039-SN2MPN1-011.039d.mgd.msft.net>

Hi Tejun:
Re-send this email to you and community.
I'm afraid that you may be missed or don't receive it.

BTW, can you help to pick up the #2 and #3(reviewed and acked by Shawn) of the v7 patch-set of this serial?
Thanks in advance.

2013/7/10 HongXing Zhu <richard.zhuhongxing at gmail.com>

    Hi Tejun:
    There are some differences between generic AHCI controller and imx AHCI controller.

    The bits definitions of the HBA registers, the Vendor
    Specific registers, and the AHCI PHY clock, and the PHY signal adjustment window.

     - CAP_SSS(bit20) of the HOST_CAP is writable, default
     value is '0', should be configured to be '1'
     - bit0 (only one AHCI SATA port on imx6q) of the
     HOST_PORTS_IMPL should be set to be '1'.(default 0)
     - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
     should be configured regarding to the frequency of AHB
     bus clock.
     - Configurations of the AHCI PHY clock, and the signal
     parameters of the GPR13

    I'm afraid that the generic ahci_platform driver is not a good place to contain
    imx6q ahci specific differences.
    As I know that, the AHCI sata on imx53 doesn't have the PHY signal parameters
    adjustment window, but the AHCI sata on imx6q does has one.

    On imx6q, the standard .port_ops = &ahci_platform_ops, is used, but
    .port_ops       = &ahci_platform_retry_srst_ops, would be required by imx53 AHCI controller.

    We can put all the imx AHCI(imx6q, imx53) specific difference into the sata_imx driver,
    and keep ahci_platform as clean as possible, if the separate sata_imx driver can be created.

    How do you think about that?

    BTW, the version4 patch-set would be sent out  a moment later, any suggests and comments are appreciated.

    Best Regards.


    2013/7/6 Tejun Heo <tj at kernel.org>

        Hello,

        On Sat, Jul 06, 2013 at 02:03:30AM +0000, Zhu Richard-R65037 wrote:
        > [Richard] Just like what we dicussed in the previous v1/v2
        > patch-set.  Shawn has the concerns that the IP speicific codes
        > shouldn't be put in the platform level.  So he suggested that setup
        > a stand-alone driver, contained the imx6q ahci sata specific codes,
        > and re-use the generic ahci_platform driver as much as possible.
        > This imx6q standalone ahci sata driver just registers the platform
        > data, and the others would be handled by ahci_platform driver.

        Oh, I'm not objecting to the ahci specific part not being in platform
        code.  I'm wondering whether specific handling for imx6q can be
        included into ahci_platform rather than being in its own driver.  It
        just seems that there aren't too many differences.  I could be
        misreading it so if there are enough differences to warrant a separate
        driver, please enlighten me.

        Thanks!

        --
        tejun

Best Regards
Richard Zhu


-----Original Message-----
From: Tejun Heo [mailto:htejun at gmail.com] On Behalf Of Tejun Heo
Sent: Saturday, July 06, 2013 10:08 AM
To: Zhu Richard-R65037
Cc: Richard Zhu; shawn.guo at linaro.org; linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; avorontsov at ru.mvista.com; rob.herring at calxeda.com; s.hauer at pengutronix.de; linux-ide at vger.kernel.org
Subject: Re: [v3 3/3] sata: imx: add ahci sata support on imx platforms

Hello,

On Sat, Jul 06, 2013 at 02:03:30AM +0000, Zhu Richard-R65037 wrote:
> [Richard] Just like what we dicussed in the previous v1/v2 patch-set.  
> Shawn has the concerns that the IP speicific codes shouldn't be put in 
> the platform level.  So he suggested that setup a stand-alone driver, 
> contained the imx6q ahci sata specific codes, and re-use the generic 
> ahci_platform driver as much as possible.
> This imx6q standalone ahci sata driver just registers the platform 
> data, and the others would be handled by ahci_platform driver.

Oh, I'm not objecting to the ahci specific part not being in platform code.  I'm wondering whether specific handling for imx6q can be included into ahci_platform rather than being in its own driver.  It just seems that there aren't too many differences.  I could be misreading it so if there are enough differences to warrant a separate driver, please enlighten me.

Thanks!

--
tejun




From haojian.zhuang at linaro.org  Mon Jul 22 03:14:06 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Mon, 22 Jul 2013 15:14:06 +0800
Subject: [PATCH 1/5] gpio: pxa: remove dead code
In-Reply-To: <CACRpkdaB7JnWzoLKpQ1eLWAi7yFz9CanhbhwtiCnEtcNWzX3RQ@mail.gmail.com>
References: <1373555877-29887-1-git-send-email-zonque@gmail.com>
 <1373555877-29887-2-git-send-email-zonque@gmail.com>
 <CACRpkdaB7JnWzoLKpQ1eLWAi7yFz9CanhbhwtiCnEtcNWzX3RQ@mail.gmail.com>
Message-ID: <CAD6h2NS0p-kMUGyhbr93vd_oLSNyaB572riFB8mHt1cu5f-bGw@mail.gmail.com>

On 22 July 2013 00:15, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Thu, Jul 11, 2013 at 5:17 PM, Daniel Mack <zonque at gmail.com> wrote:
>
>> Commit f87311743 ("ARM: mmp: add more compatible names in gpio driver")
>> changed the driver logic to determine the number of available GPIOs from
>> the compatible string, and hence obsoleted the (undocumented) child
>> nodes that were previously necessary. However, it left some remainder
>> which can be safely removed now.
>>
>> Also, this patch makes pxa_gpio_probe_dt() return the correct value in
>> case irq_alloc_descs() fails.
>>
>> Signed-off-by: Daniel Mack <zonque at gmail.com>
>> Cc: Haojian Zhuang <haojian.zhuang at linaro.org>
>> Cc: Linus Walleij <linus.walleij at linaro.org>
>> Cc: Arnd Bergmann <arnd at arndb.de>
>
> Tentatively applied, Haojian, does this look allright?
>
> Yours,
> Linus Walleij

This patch is good.

Acked-by: Haojian Zhuang <haojian.zhuang at gmail.com>


From kishon at ti.com  Mon Jul 22 03:25:18 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 22 Jul 2013 12:55:18 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <Pine.LNX.4.44L0.1307211453450.19133-100000@netrider.rowland.org>
References: <Pine.LNX.4.44L0.1307211453450.19133-100000@netrider.rowland.org>
Message-ID: <51ECDE5E.3050104@ti.com>

Hi,

On Monday 22 July 2013 12:52 AM, Alan Stern wrote:
> On Sun, 21 Jul 2013, Sylwester Nawrocki wrote:
> 
>>> What's wrong with the platform_data structure, why can't that be used
>>> for this?
>>
>> At the point the platform data of some driver is initialized, e.g. in
>> board setup code the PHY pointer is not known, since the PHY supplier
>> driver has not initialized yet.  Even though we wanted to pass pointer
>> to a PHY through some notifier call, it would have been not clear
>> which PHY user driver should match on such notifier.  A single PHY
>> supplier driver can create M PHY objects and this needs to be mapped
>> to N PHY user drivers.  This mapping needs to be defined somewhere by
>> the system integrator.  It works well with device tree, but except that
>> there seems to be no other reliable infrastructure in the kernel to
>> define links/dependencies between devices, since device identifiers are
>> not known in advance in all cases.
>>
>> What Tomasz proposed seems currently most reasonable to me for non-dt.
>>
>>> Or, if not, we can always add pointers to the platform device structure,
>>> or even the main 'struct device' as well, that's what it is there for.
>>
>> Still we would need to solve a problem which platform device structure
>> gets which PHY pointer.
> 
> Can you explain the issues in more detail?  I don't fully understand 
> the situation.
> 
> Here's what I think I know:
> 
> 	The PHY and the controller it is attached to are both physical
> 	devices.
> 
> 	The connection between them is hardwired by the system
> 	manufacturer and cannot be changed by software.
> 
> 	PHYs are generally described by fixed system-specific board
> 	files or by Device Tree information.  Are they ever discovered
> 	dynamically?

No. They are created just like any other platform devices are created.
> 
> 	Is the same true for the controllers attached to the PHYs?
> 	If not -- if both a PHY and a controller are discovered 
> 	dynamically -- how does the kernel know whether they are 
> 	connected to each other?

No differences here. Both PHY and controller will have dt information or hwmod
data using which platform devices will be created.
> 
> 	The kernel needs to know which controller is attached to which
> 	PHY.  Currently this information is represented by name or ID
> 	strings embedded in platform data.

right. It's embedded in the platform data of the controller.
> 
> 	The PHY's driver (the supplier) uses the platform data to 
> 	construct a platform_device structure that represents the PHY.  

Currently the driver assigns static labels (corresponding to the label used in
the platform data of the controller).
> 	Until this is done, the controller's driver (the client) cannot 
> 	use the PHY.

right.
> 
> 	Since there is no parent-child relation between the PHY and the 
> 	controller, there is no guarantee that the PHY's driver will be
> 	ready when the controller's driver wants to use it.  A deferred
> 	probe may be needed.

right.
> 
> 	The issue (or one of the issues) in this discussion is that 
> 	Greg does not like the idea of using names or IDs to associate
> 	PHYs with controllers, because they are too prone to
> 	duplications or other errors.  Pointers are more reliable.
> 
> 	But pointers to what?  Since the only data known to be 
> 	available to both the PHY driver and controller driver is the
> 	platform data, the obvious answer is a pointer to platform data
> 	(either for the PHY or for the controller, or maybe both).

hmm.. it's not going to be simple though as the platform device for the PHY and
controller can be created in entirely different places. e.g., in some cases the
PHY device is a child of some mfd core device (the device will be created in
drivers/mfd) and the controller driver (usually) is created in board file. I
guess then we have to come up with something to share a pointer in two
different files.
> 
> Probably some of the details above are wrong; please indicate where I
> have gone astray.  Also, I'm not clear about the role played by various 
> APIs.  For example, where does phy_create() fit into this picture?

phy_create is the API by which the PHY's driver (the supplier) hook into the
PHY framework. It's like the controller driver will always interact with the
PHY driver through the PHY framework.

Thanks
Kishon


From horms+renesas at verge.net.au  Mon Jul 22 03:35:47 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:35:47 +0900
Subject: [GIT 00/11] Renesas ARM-based SoC DT updates for v3.12
Message-ID: <cover.1374478037.git.horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

please consider the following DT updates for v3.12.

This pull request is based on renesas-cleanup-for-v3.12 which I
have already sent a pull request for.

The following changes since commit ebd9616f439a8a46b9dca9a272b342f34c5f3614:

  ARM: shmobile: Remove unused mach/dma.h (2013-07-17 10:02:30 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-for-v3.12

for you to fetch changes up to 66a5cab04d339d02b93a4671eadf8e251dbfdc2c:

  ARM: shmobile: Add SMSC ethernet chip to KZM9D DT reference (2013-07-17 10:06:47 +0900)

----------------------------------------------------------------
Renesas ARM-based SoC DT updates for v3.12

* Reference implementation for kzm9d board
* Add MMCIF and SDHI DT templates for r8a7790 and r8a73a4 SoCs
* Use DT for SMP and GIC initialisation on emev2 SoC and kzm9d board
* Add GIO to dtsi of emev2 SoC
* Update dts command line of kzm9d board
* Add CPUFreq support to ape6evm board
* Add I2C controller DT nodes to r8a73a4 SoC

----------------------------------------------------------------
Guennadi Liakhovetski (4):
      ARM: shmobile: r8a73a4: add I2C controller DT nodes
      ARM: shmobile: ape6evm: add CPUFreq support
      ARM: shmobile: r8a73a4: add MMCIF and SDHI DT templates
      ARM: shmobile: r8a7790: add MMCIF and SDHI DT templates

Magnus Damm (7):
      ARM: shmobile: Update KZM9D dts command line
      ARM: shmobile: Add GIO to EMEV2 dtsi
      ARM: shmobile: Use DT for GIC on EMEV2 and KZM9D
      ARM: shmobile: Use DT for SMP on EMEV2 and KZM9D
      ARM: shmobile: EMEV2 map_io update
      ARM: shmobile: KZM9D DT reference implementation
      ARM: shmobile: Add SMSC ethernet chip to KZM9D DT reference

 arch/arm/boot/dts/Makefile                     |   1 +
 arch/arm/boot/dts/emev2-kzm9d-reference.dts    |  57 +++++++++++
 arch/arm/boot/dts/emev2-kzm9d.dts              |   2 +-
 arch/arm/boot/dts/emev2.dtsi                   |  59 ++++++++++++
 arch/arm/boot/dts/r8a73a4-ape6evm.dts          |  22 +++++
 arch/arm/boot/dts/r8a73a4.dtsi                 | 126 +++++++++++++++++++++++++
 arch/arm/boot/dts/r8a7790.dtsi                 |  54 +++++++++++
 arch/arm/mach-shmobile/Kconfig                 |  12 +++
 arch/arm/mach-shmobile/Makefile                |   1 +
 arch/arm/mach-shmobile/Makefile.boot           |   1 +
 arch/arm/mach-shmobile/board-kzm9d-reference.c |  46 +++++++++
 arch/arm/mach-shmobile/board-kzm9d.c           |   2 -
 arch/arm/mach-shmobile/include/mach/emev2.h    |   1 -
 arch/arm/mach-shmobile/setup-emev2.c           |  23 +----
 arch/arm/mach-shmobile/smp-emev2.c             |  17 +---
 15 files changed, 384 insertions(+), 40 deletions(-)
 create mode 100644 arch/arm/boot/dts/emev2-kzm9d-reference.dts
 create mode 100644 arch/arm/mach-shmobile/board-kzm9d-reference.c


From horms+renesas at verge.net.au  Mon Jul 22 03:36:15 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:36:15 +0900
Subject: [PATCH 03/11] ARM: shmobile: Update KZM9D dts command line
In-Reply-To: <cover.1374478037.git.horms+renesas@verge.net.au>
References: <cover.1374478037.git.horms+renesas@verge.net.au>
Message-ID: <8f675493f4706a9f92a822121fe38892a08e0161.1374478037.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Update the KZM9D DTS command line to remove following cruft:
 - console=tty0 - no graphic support upstream anyway
 - earlyprintk= - not supported by the 8250-em driver anyway
 - mem= - this is provided via DT anyway

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/emev2-kzm9d.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/emev2-kzm9d.dts b/arch/arm/boot/dts/emev2-kzm9d.dts
index b9b3241..dda13bc 100644
--- a/arch/arm/boot/dts/emev2-kzm9d.dts
+++ b/arch/arm/boot/dts/emev2-kzm9d.dts
@@ -21,6 +21,6 @@
 	};
 
 	chosen {
-		bootargs = "console=tty0 console=ttyS1,115200n81 earlyprintk=serial8250-em.1,115200n81 mem=128M at 0x40000000 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096";
+		bootargs = "console=ttyS1,115200n81 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096";
 	};
 };
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 03:36:14 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:36:14 +0900
Subject: [PATCH 02/11] ARM: shmobile: ape6evm: add CPUFreq support
In-Reply-To: <cover.1374478037.git.horms+renesas@verge.net.au>
References: <cover.1374478037.git.horms+renesas@verge.net.au>
Message-ID: <463a2432a435ea3eda4714626f231b7b22f0ac3d.1374478037.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

This patch adds OPPs to the CA15 DT node and a max8973 DT node to support
clock and voltage scaling, using the cpufreq-cpu0 CPUFreq driver.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a73a4-ape6evm.dts | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/r8a73a4-ape6evm.dts b/arch/arm/boot/dts/r8a73a4-ape6evm.dts
index f603c69..e657a9d 100644
--- a/arch/arm/boot/dts/r8a73a4-ape6evm.dts
+++ b/arch/arm/boot/dts/r8a73a4-ape6evm.dts
@@ -50,3 +50,25 @@
 		};
 	};
 };
+
+&i2c5 {
+	vdd_dvfs: max8973 at 1b {
+		compatible = "maxim,max8973";
+		reg = <0x1b>;
+
+		regulator-min-microvolt = <935000>;
+		regulator-max-microvolt = <1200000>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+};
+
+&cpu0 {
+	cpu0-supply = <&vdd_dvfs>;
+	operating-points = <
+		/* kHz  uV */
+		1950000 1115000
+		1462500  995000
+	>;
+	voltage-tolerance = <1>; /* 1% */
+};
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 03:36:16 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:36:16 +0900
Subject: [PATCH 04/11] ARM: shmobile: Add GIO to EMEV2 dtsi
In-Reply-To: <cover.1374478037.git.horms+renesas@verge.net.au>
References: <cover.1374478037.git.horms+renesas@verge.net.au>
Message-ID: <12d035b13b224ee69886b64fd33d1c1224e79187.1374478037.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add GIO0->GIO4 device nodes to the EMEV2 dtsi file.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/emev2.dtsi | 59 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

diff --git a/arch/arm/boot/dts/emev2.dtsi b/arch/arm/boot/dts/emev2.dtsi
index c8a8c08..99ad2b2 100644
--- a/arch/arm/boot/dts/emev2.dtsi
+++ b/arch/arm/boot/dts/emev2.dtsi
@@ -14,6 +14,14 @@
 	compatible = "renesas,emev2";
 	interrupt-parent = <&gic>;
 
+	aliases {
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
+		gpio4 = &gpio4;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
@@ -67,4 +75,55 @@
 		reg = <0xe1050000 0x38>;
 		interrupts = <0 11 0>;
 	};
+
+	gpio0: gpio at e0050000 {
+		compatible = "renesas,em-gio";
+		reg = <0xe0050000 0x2c>, <0xe0050040 0x20>;
+		interrupts = <0 67 0>, <0 68 0>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ngpios = <32>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+	gpio1: gpio at e0050080 {
+		compatible = "renesas,em-gio";
+		reg = <0xe0050080 0x2c>, <0xe00500c0 0x20>;
+		interrupts = <0 69 0>, <0 70 0>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ngpios = <32>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+	gpio2: gpio at e0050100 {
+		compatible = "renesas,em-gio";
+		reg = <0xe0050100 0x2c>, <0xe0050140 0x20>;
+		interrupts = <0 71 0>, <0 72 0>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ngpios = <32>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+	gpio3: gpio at e0050180 {
+		compatible = "renesas,em-gio";
+		reg = <0xe0050180 0x2c>, <0xe00501c0 0x20>;
+		interrupts = <0 73 0>, <0 74 0>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ngpios = <32>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+	gpio4: gpio at e0050200 {
+		compatible = "renesas,em-gio";
+		reg = <0xe0050200 0x2c>, <0xe0050240 0x20>;
+		interrupts = <0 75 0>, <0 76 0>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		ngpios = <31>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
 };
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 03:36:13 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:36:13 +0900
Subject: [PATCH 01/11] ARM: shmobile: r8a73a4: add I2C controller DT nodes
In-Reply-To: <cover.1374478037.git.horms+renesas@verge.net.au>
References: <cover.1374478037.git.horms+renesas@verge.net.au>
Message-ID: <f98c1069bf1748ffa18cbebbc3a9f88dfc19a631.1374478037.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Add Device Tree nodes for the 9 I2C controllers on r8a73a4, compatible with
the i2c-sh_mobile.c driver.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a73a4.dtsi | 81 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 4ff2019..4e1ddf0 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -85,4 +85,85 @@
 		interrupt-parent = <&gic>;
 		interrupts = <0 69 4>;
 	};
+
+	i2c0: i2c at e6500000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6500000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 174 0x4>;
+	};
+
+	i2c1: i2c at e6510000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6510000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 175 0x4>;
+	};
+
+	i2c2: i2c at e6520000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6520000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 176 0x4>;
+	};
+
+	i2c3: i2c at e6530000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6530000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 177 0x4>;
+	};
+
+	i2c4: i2c at e6540000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6540000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 178 0x4>;
+	};
+
+	i2c5: i2c at e60b0000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe60b0000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 179 0x4>;
+	};
+
+	i2c6: i2c at e6550000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6550000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 184 0x4>;
+	};
+
+	i2c7: i2c at e6560000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6560000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 185 0x4>;
+	};
+
+	i2c8: i2c at e6570000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,rmobile-iic";
+		reg = <0 0xe6570000 0 0x428>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 173 0x4>;
+	};
 };
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 03:36:17 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:36:17 +0900
Subject: [PATCH 05/11] ARM: shmobile: Use DT for GIC on EMEV2 and KZM9D
In-Reply-To: <cover.1374478037.git.horms+renesas@verge.net.au>
References: <cover.1374478037.git.horms+renesas@verge.net.au>
Message-ID: <23260e1b417843ea875bd7b21f17c5c80031c4cd.1374478037.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Remove the C version of the EMEV2 GIC setup code,
instead rely on GIC information provided by DT.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-kzm9d.c        |  2 --
 arch/arm/mach-shmobile/include/mach/emev2.h |  1 -
 arch/arm/mach-shmobile/setup-emev2.c        | 15 ---------------
 3 files changed, 18 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-kzm9d.c b/arch/arm/mach-shmobile/board-kzm9d.c
index 15900f1..30c2cc6 100644
--- a/arch/arm/mach-shmobile/board-kzm9d.c
+++ b/arch/arm/mach-shmobile/board-kzm9d.c
@@ -86,8 +86,6 @@ DT_MACHINE_START(KZM9D_DT, "kzm9d")
 	.smp		= smp_ops(emev2_smp_ops),
 	.map_io		= emev2_map_io,
 	.init_early	= emev2_init_delay,
-	.nr_irqs	= NR_IRQS_LEGACY,
-	.init_irq	= emev2_init_irq,
 	.init_machine	= kzm9d_add_standard_devices,
 	.init_late	= shmobile_init_late,
 	.dt_compat	= kzm9d_boards_compat_dt,
diff --git a/arch/arm/mach-shmobile/include/mach/emev2.h b/arch/arm/mach-shmobile/include/mach/emev2.h
index 3e0c044..b0ab4b7 100644
--- a/arch/arm/mach-shmobile/include/mach/emev2.h
+++ b/arch/arm/mach-shmobile/include/mach/emev2.h
@@ -2,7 +2,6 @@
 #define __ASM_EMEV2_H__
 
 extern void emev2_map_io(void);
-extern void emev2_init_irq(void);
 extern void emev2_init_delay(void);
 extern void emev2_add_standard_devices(void);
 extern void emev2_clock_init(void);
diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
index e4b4693..6fa485d 100644
--- a/arch/arm/mach-shmobile/setup-emev2.c
+++ b/arch/arm/mach-shmobile/setup-emev2.c
@@ -202,20 +202,6 @@ void __init emev2_init_delay(void)
 	shmobile_setup_delay(533, 1, 3); /* Cortex-A9 @ 533MHz */
 }
 
-void __init emev2_init_irq(void)
-{
-	void __iomem *gic_dist_base;
-	void __iomem *gic_cpu_base;
-
-	/* Static mappings, never released */
-	gic_dist_base = ioremap(0xe0028000, PAGE_SIZE);
-	gic_cpu_base = ioremap(0xe0020000, PAGE_SIZE);
-	BUG_ON(!gic_dist_base || !gic_cpu_base);
-
-	/* Use GIC to handle interrupts */
-	gic_init(0, 29, gic_dist_base, gic_cpu_base);
-}
-
 #ifdef CONFIG_USE_OF
 
 static const char *emev2_boards_compat_dt[] __initdata = {
@@ -226,7 +212,6 @@ static const char *emev2_boards_compat_dt[] __initdata = {
 DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
 	.smp		= smp_ops(emev2_smp_ops),
 	.init_early	= emev2_init_delay,
-	.nr_irqs	= NR_IRQS_LEGACY,
 	.dt_compat	= emev2_boards_compat_dt,
 MACHINE_END
 
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 03:36:47 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:36:47 +0900
Subject: [GIT 0/5] Renesas ARM based SoC fixes for v3.12
Message-ID: <cover.1374478336.git.horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,
										please consider the following fixes v3.12.

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-fixes-for-v3.12

for you to fetch changes up to 93d8a6fbe69a629a7bb37bb546699a5c49963dc5:

  ARM: shmobile: r8a7740: Fix TPU clock name (2013-07-19 11:12:35 +0900)

----------------------------------------------------------------
Renesas ARM based SoC fixes for v3.12

* Fix TPU clock name for r8a7740 SoC
* Update romImage to relocate appended DTB
* Thumb fixes

----------------------------------------------------------------
Laurent Pinchart (1):
      ARM: shmobile: r8a7740: Fix TPU clock name

Magnus Damm (1):
      ARM: shmobile: Update romImage to relocate appended DTB

Tetsuyuki Kobayashi (3):
      ARM: shmobile: fix compile error when CONFIG_THUMB2_KERNEL=y
      ARM: shmobile: Force ARM mode to compile reset vector for secondary CPUs
      ARM: shmobile: Insert align directives before 4 bytes data

 arch/arm/boot/compressed/head-shmobile.S    | 43 ++++++++++++++++++++++++++---
 arch/arm/mach-shmobile/clock-r8a7740.c      |  2 +-
 arch/arm/mach-shmobile/headsmp-scu.S        |  4 ++-
 arch/arm/mach-shmobile/headsmp.S            |  6 +++-
 arch/arm/mach-shmobile/include/mach/zboot.h |  2 --
 arch/arm/mach-shmobile/sleep-sh7372.S       |  2 ++
 6 files changed, 50 insertions(+), 9 deletions(-)


From horms+renesas at verge.net.au  Mon Jul 22 03:36:32 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:36:32 +0900
Subject: [PATCH 11/11] ARM: shmobile: Add SMSC ethernet chip to KZM9D DT
 reference
In-Reply-To: <cover.1374478037.git.horms+renesas@verge.net.au>
References: <cover.1374478037.git.horms+renesas@verge.net.au>
Message-ID: <66a5cab04d339d02b93a4671eadf8e251dbfdc2c.1374478037.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add support for the SMSC ethernet controller found
on the KZM9D board to the KZM9D DT Reference code.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/emev2-kzm9d-reference.dts | 31 +++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/emev2-kzm9d-reference.dts b/arch/arm/boot/dts/emev2-kzm9d-reference.dts
index 5ec065e..bed676b 100644
--- a/arch/arm/boot/dts/emev2-kzm9d-reference.dts
+++ b/arch/arm/boot/dts/emev2-kzm9d-reference.dts
@@ -23,4 +23,35 @@
 	chosen {
 		bootargs = "console=ttyS1,115200n81 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096";
 	};
+
+	reg_1p8v: regulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "fixed-1.8V";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	reg_3p3v: regulator at 1 {
+		compatible = "regulator-fixed";
+		regulator-name = "fixed-3.3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	lan9220 at 20000000 {
+		compatible = "smsc,lan9220", "smsc,lan9115";
+		reg = <0x20000000 0x10000>;
+		phy-mode = "mii";
+		interrupt-parent = <&gpio0>;
+		interrupts = <1 1>;	/* active high */
+		reg-io-width = <4>;
+		smsc,irq-active-high;
+		smsc,irq-push-pull;
+		vddvario-supply = <&reg_1p8v>;
+		vdd33a-supply = <&reg_3p3v>;
+	};
 };
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 03:36:19 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:36:19 +0900
Subject: [PATCH 07/11] ARM: shmobile: EMEV2 map_io update
In-Reply-To: <cover.1374478037.git.horms+renesas@verge.net.au>
References: <cover.1374478037.git.horms+renesas@verge.net.au>
Message-ID: <0ea2b5389ab1b63aa880c5735c15be0b26b91b1a.1374478037.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Update the EMEV2 struct map_desc to exclude the SMU
and also include the ->map_io() callback in the DT
version of EMEV2 board support.

The EMEV2 SMP code can these days perform ioremap()
early on without the SMU information in the io_desc[].

To correctly support SMP in case of DT-only board
support then the ->map_io() callback is needed.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-emev2.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
index 6fa485d..19980be 100644
--- a/arch/arm/mach-shmobile/setup-emev2.c
+++ b/arch/arm/mach-shmobile/setup-emev2.c
@@ -38,13 +38,6 @@
 
 static struct map_desc emev2_io_desc[] __initdata = {
 #ifdef CONFIG_SMP
-	/* 128K entity map for 0xe0100000 (SMU) */
-	{
-		.virtual	= 0xe0100000,
-		.pfn		= __phys_to_pfn(0xe0100000),
-		.length		= SZ_128K,
-		.type		= MT_DEVICE
-	},
 	/* 2M mapping for SCU + L2 controller */
 	{
 		.virtual	= 0xf0000000,
@@ -211,6 +204,7 @@ static const char *emev2_boards_compat_dt[] __initdata = {
 
 DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
 	.smp		= smp_ops(emev2_smp_ops),
+	.map_io		= emev2_map_io,
 	.init_early	= emev2_init_delay,
 	.dt_compat	= emev2_boards_compat_dt,
 MACHINE_END
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 03:36:18 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:36:18 +0900
Subject: [PATCH 06/11] ARM: shmobile: Use DT for SMP on EMEV2 and KZM9D
In-Reply-To: <cover.1374478037.git.horms+renesas@verge.net.au>
References: <cover.1374478037.git.horms+renesas@verge.net.au>
Message-ID: <683101a66203149da96e93fb8c0740c726bc114f.1374478037.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Rework the EMEV2 SMP code to rely on DT for CPU information
instead of reading out number of CPU cores from the SCU.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/smp-emev2.c | 17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-shmobile/smp-emev2.c b/arch/arm/mach-shmobile/smp-emev2.c
index 80991b3..9787165 100644
--- a/arch/arm/mach-shmobile/smp-emev2.c
+++ b/arch/arm/mach-shmobile/smp-emev2.c
@@ -38,9 +38,12 @@ static int __cpuinit emev2_boot_secondary(unsigned int cpu, struct task_struct *
 
 static void __init emev2_smp_prepare_cpus(unsigned int max_cpus)
 {
+	/* setup EMEV2 specific SCU base, enable */
+	shmobile_scu_base = ioremap(EMEV2_SCU_BASE, PAGE_SIZE);
 	scu_enable(shmobile_scu_base);
 
 	/* Tell ROM loader about our vector (in headsmp-scu.S, headsmp.S) */
+	emev2_clock_init(); /* need ioremapped SMU */
 	emev2_set_boot_vector(__pa(shmobile_boot_vector));
 	shmobile_boot_fn = virt_to_phys(shmobile_boot_scu);
 	shmobile_boot_arg = (unsigned long)shmobile_scu_base;
@@ -49,21 +52,7 @@ static void __init emev2_smp_prepare_cpus(unsigned int max_cpus)
 	scu_power_mode(shmobile_scu_base, SCU_PM_NORMAL);
 }
 
-static void __init emev2_smp_init_cpus(void)
-{
-	unsigned int ncores;
-
-	/* setup EMEV2 specific SCU base */
-	shmobile_scu_base = ioremap(EMEV2_SCU_BASE, PAGE_SIZE);
-	emev2_clock_init(); /* need ioremapped SMU */
-
-	ncores = shmobile_scu_base ? scu_get_core_count(shmobile_scu_base) : 1;
-
-	shmobile_smp_init_cpus(ncores);
-}
-
 struct smp_operations emev2_smp_ops __initdata = {
-	.smp_init_cpus		= emev2_smp_init_cpus,
 	.smp_prepare_cpus	= emev2_smp_prepare_cpus,
 	.smp_boot_secondary	= emev2_boot_secondary,
 };
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 03:36:20 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:36:20 +0900
Subject: [PATCH 08/11] ARM: shmobile: r8a73a4: add MMCIF and SDHI DT templates
In-Reply-To: <cover.1374478037.git.horms+renesas@verge.net.au>
References: <cover.1374478037.git.horms+renesas@verge.net.au>
Message-ID: <369ee2db438cc0adc6952b424743e9ed21a0edee.1374478037.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

This adds DT templates for all MMCIF and SDHI controllers on r8a73a4.
They are added with status="disabled". To use them platform-specific
DTs have to enable the required ones.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a73a4.dtsi | 45 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 4e1ddf0..6ce699b 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -166,4 +166,49 @@
 		interrupt-parent = <&gic>;
 		interrupts = <0 173 0x4>;
 	};
+
+	mmcif0: mmcif at ee200000 {
+		compatible = "renesas,sh-mmcif";
+		reg = <0 0xee200000 0 0x80>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 169 0x4>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	mmcif1: mmcif at ee220000 {
+		compatible = "renesas,sh-mmcif";
+		reg = <0 0xee220000 0 0x80>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 170 0x4>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	sdhi0: sdhi at ee100000 {
+		compatible = "renesas,r8a73a4-sdhi";
+		reg = <0 0xee100000 0 0x100>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 165 4>;
+		cap-sd-highspeed;
+		status = "disabled";
+	};
+
+	sdhi1: sdhi at ee120000 {
+		compatible = "renesas,r8a73a4-sdhi";
+		reg = <0 0xee120000 0 0x100>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 166 4>;
+		cap-sd-highspeed;
+		status = "disabled";
+	};
+
+	sdhi2: sdhi at ee140000 {
+		compatible = "renesas,r8a73a4-sdhi";
+		reg = <0 0xee140000 0 0x100>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 167 4>;
+		cap-sd-highspeed;
+		status = "disabled";
+	};
 };
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 03:36:21 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:36:21 +0900
Subject: [PATCH 09/11] ARM: shmobile: r8a7790: add MMCIF and SDHI DT templates
In-Reply-To: <cover.1374478037.git.horms+renesas@verge.net.au>
References: <cover.1374478037.git.horms+renesas@verge.net.au>
Message-ID: <8c9b1aa41853272adf505cc22be541f1eac2f94c.1374478037.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

This adds DT templates for all MMCIF and SDHI controllers on r8a7790.
They are added with status="disabled". To use them platform-specific
DTs have to enable the required ones.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 54 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 339d9b1..9cd8820 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -54,4 +54,58 @@
 		interrupt-parent = <&gic>;
 		interrupts = <0 0 4>, <0 1 4>, <0 2 4>,	<0 3 4>;
 	};
+
+	mmcif0: mmcif at ee200000 {
+		compatible = "renesas,sh-mmcif";
+		reg = <0 0xee200000 0 0x80>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 169 0x4>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	mmcif1: mmcif at ee220000 {
+		compatible = "renesas,sh-mmcif";
+		reg = <0 0xee220000 0 0x80>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 170 0x4>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	sdhi0: sdhi at ee100000 {
+		compatible = "renesas,r8a7790-sdhi";
+		reg = <0 0xee100000 0 0x100>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 165 4>;
+		cap-sd-highspeed;
+		status = "disabled";
+	};
+
+	sdhi1: sdhi at ee120000 {
+		compatible = "renesas,r8a7790-sdhi";
+		reg = <0 0xee120000 0 0x100>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 166 4>;
+		cap-sd-highspeed;
+		status = "disabled";
+	};
+
+	sdhi2: sdhi at ee140000 {
+		compatible = "renesas,r8a7790-sdhi";
+		reg = <0 0xee140000 0 0x100>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 167 4>;
+		cap-sd-highspeed;
+		status = "disabled";
+	};
+
+	sdhi3: sdhi at ee160000 {
+		compatible = "renesas,r8a7790-sdhi";
+		reg = <0 0xee160000 0 0x100>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 168 4>;
+		cap-sd-highspeed;
+		status = "disabled";
+	};
 };
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 03:37:02 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:37:02 +0900
Subject: [PATCH 5/5] ARM: shmobile: r8a7740: Fix TPU clock name
In-Reply-To: <cover.1374478336.git.horms+renesas@verge.net.au>
References: <cover.1374478336.git.horms+renesas@verge.net.au>
Message-ID: <93d8a6fbe69a629a7bb37bb546699a5c49963dc5.1374478336.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The TPU device is called renesas-tpu-pwm, not renesas_tpu_pwm. Fix the
clock name accordingly.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7740.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
index de10fd7..f4265e5 100644
--- a/arch/arm/mach-shmobile/clock-r8a7740.c
+++ b/arch/arm/mach-shmobile/clock-r8a7740.c
@@ -596,7 +596,7 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("e6bd0000.mmcif",         &mstp_clks[MSTP312]),
 	CLKDEV_DEV_ID("r8a7740-gether",		&mstp_clks[MSTP309]),
 	CLKDEV_DEV_ID("e9a00000.sh-eth",	&mstp_clks[MSTP309]),
-	CLKDEV_DEV_ID("renesas_tpu_pwm",	&mstp_clks[MSTP304]),
+	CLKDEV_DEV_ID("renesas-tpu-pwm",	&mstp_clks[MSTP304]),
 
 	CLKDEV_DEV_ID("sh_mobile_sdhi.2",	&mstp_clks[MSTP415]),
 	CLKDEV_DEV_ID("e6870000.sdhi",          &mstp_clks[MSTP415]),
-- 
1.8.2.1



From gleb at redhat.com  Mon Jul 22 03:36:39 2013
From: gleb at redhat.com (Gleb Natapov)
Date: Mon, 22 Jul 2013 10:36:39 +0300
Subject: [PATCH 4/4] arm64: KVM: remove __kvm_hyp_code_{start,end} from
 hyp.S
In-Reply-To: <1374242035-13199-5-git-send-email-marc.zyngier@arm.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-5-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130722073639.GK20379@redhat.com>

On Fri, Jul 19, 2013 at 02:53:55PM +0100, Marc Zyngier wrote:
> We already have __hyp_text_{start,end} to express the boundaries
> of the HYP text section, and __kvm_hyp_code_{start,end} are getting
> in the way of a more modular world switch code.
> 
> Just turn __kvm_hyp_code_{start,end} into #defines mapping the
> linker-emited symbols.
> 
Same here, why 3.11?

> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/kvm_asm.h | 6 ++++--
>  arch/arm64/include/asm/virt.h    | 4 ++++
>  arch/arm64/kvm/hyp.S             | 6 ------
>  3 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index b25763b..dddb345 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -18,6 +18,8 @@
>  #ifndef __ARM_KVM_ASM_H__
>  #define __ARM_KVM_ASM_H__
>  
> +#include <asm/virt.h>
> +
>  /*
>   * 0 is reserved as an invalid value.
>   * Order *must* be kept in sync with the hyp switch code.
> @@ -95,8 +97,8 @@ extern char __kvm_hyp_init_end[];
>  
>  extern char __kvm_hyp_vector[];
>  
> -extern char __kvm_hyp_code_start[];
> -extern char __kvm_hyp_code_end[];
> +#define	__kvm_hyp_code_start	__hyp_text_start
> +#define	__kvm_hyp_code_end	__hyp_text_end
>  
>  extern void __kvm_flush_vm_context(void);
>  extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> index 4398272..59d67f3 100644
> --- a/arch/arm64/include/asm/virt.h
> +++ b/arch/arm64/include/asm/virt.h
> @@ -49,6 +49,10 @@ static inline bool is_hyp_mode_mismatched(void)
>  	return __boot_cpu_mode[0] != __boot_cpu_mode[1];
>  }
>  
> +/* The section containing the hypervisor text */
> +extern char __hyp_text_start[];
> +extern char __hyp_text_end[];
> +
>  #endif /* __ASSEMBLY__ */
>  
>  #endif /* ! __ASM__VIRT_H */
> diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
> index e1ccfcc..19ccf48 100644
> --- a/arch/arm64/kvm/hyp.S
> +++ b/arch/arm64/kvm/hyp.S
> @@ -36,9 +36,6 @@
>  	.pushsection	.hyp.text, "ax"
>  	.align	PAGE_SHIFT
>  
> -__kvm_hyp_code_start:
> -	.globl __kvm_hyp_code_start
> -
>  .macro save_common_regs
>  	// x2: base address for cpu context
>  	// x3: tmp register
> @@ -837,7 +834,4 @@ ENTRY(__kvm_hyp_vector)
>  	ventry	el1_error_invalid		// Error 32-bit EL1
>  ENDPROC(__kvm_hyp_vector)
>  
> -__kvm_hyp_code_end:
> -	.globl	__kvm_hyp_code_end
> -
>  	.popsection
> -- 
> 1.8.2.3
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
			Gleb.


From horms+renesas at verge.net.au  Mon Jul 22 03:36:31 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:36:31 +0900
Subject: [PATCH 10/11] ARM: shmobile: KZM9D DT reference implementation
In-Reply-To: <cover.1374478037.git.horms+renesas@verge.net.au>
References: <cover.1374478037.git.horms+renesas@verge.net.au>
Message-ID: <03393e8fe651aaf8824c519effbb51bf460ca57f.1374478037.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add a DT reference implementation for the KZM9D board.

Only DT devices are used in this case. UART, STI, GPIO
and SMP / GIC are all provided by emev2.dtsi.

There is still a board specific C file used for enabling
legacy SH clocks. This file will be removed after we have
moved over to common clocks.

Signed-off-by: Magnus Damm <damm at opensource.se>
[horms+renesas at verge.net.au: Do not include trailing blank line in
 board-kzm9d-reference.c ]
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/Makefile                     |  1 +
 arch/arm/boot/dts/emev2-kzm9d-reference.dts    | 26 +++++++++++++++
 arch/arm/mach-shmobile/Kconfig                 | 12 +++++++
 arch/arm/mach-shmobile/Makefile                |  1 +
 arch/arm/mach-shmobile/Makefile.boot           |  1 +
 arch/arm/mach-shmobile/board-kzm9d-reference.c | 46 ++++++++++++++++++++++++++
 6 files changed, 87 insertions(+)
 create mode 100644 arch/arm/boot/dts/emev2-kzm9d-reference.dts
 create mode 100644 arch/arm/mach-shmobile/board-kzm9d-reference.c

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..af19e38 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -183,6 +183,7 @@ dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
 	ccu9540.dtb
 dtb-$(CONFIG_ARCH_S3C24XX) += s3c2416-smdk2416.dtb
 dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
+	emev2-kzm9d-reference.dtb \
 	r8a7740-armadillo800eva.dtb \
 	r8a7778-bockw.dtb \
 	r8a7740-armadillo800eva-reference.dtb \
diff --git a/arch/arm/boot/dts/emev2-kzm9d-reference.dts b/arch/arm/boot/dts/emev2-kzm9d-reference.dts
new file mode 100644
index 0000000..5ec065e
--- /dev/null
+++ b/arch/arm/boot/dts/emev2-kzm9d-reference.dts
@@ -0,0 +1,26 @@
+/*
+ * Device Tree Source for the KZM9D board
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+/dts-v1/;
+
+/include/ "emev2.dtsi"
+
+/ {
+	model = "EMEV2 KZM9D Board";
+	compatible = "renesas,kzm9d-reference", "renesas,emev2";
+
+	memory {
+		device_type = "memory";
+		reg = <0x40000000 0x8000000>;
+	};
+
+	chosen {
+		bootargs = "console=ttyS1,115200n81 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096";
+	};
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 3912ce9..7c5034a 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -156,6 +156,18 @@ config MACH_KZM9D
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select USE_OF
 
+config MACH_KZM9D_REFERENCE
+	bool "KZM9D board - Reference Device Tree Implementation"
+	depends on ARCH_EMEV2
+	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	select USE_OF
+	---help---
+	   Use reference implementation of KZM9D board support
+	   which makes a greater use of device tree at the expense
+	   of not supporting a number of devices.
+
+	   This is intended to aid developers
+
 config MACH_KZM9G
 	bool "KZM-A9-GT board"
 	depends on ARCH_SH73A0
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 6165a51..e8d0a2c 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_MACH_LAGER)	+= board-lager.o
 obj-$(CONFIG_MACH_ARMADILLO800EVA)	+= board-armadillo800eva.o
 obj-$(CONFIG_MACH_ARMADILLO800EVA_REFERENCE)	+= board-armadillo800eva-reference.o
 obj-$(CONFIG_MACH_KZM9D)	+= board-kzm9d.o
+obj-$(CONFIG_MACH_KZM9D_REFERENCE)	+= board-kzm9d-reference.o
 obj-$(CONFIG_MACH_KZM9G)	+= board-kzm9g.o
 obj-$(CONFIG_MACH_KZM9G_REFERENCE)	+= board-kzm9g-reference.o
 
diff --git a/arch/arm/mach-shmobile/Makefile.boot b/arch/arm/mach-shmobile/Makefile.boot
index 84c6868..7785c52 100644
--- a/arch/arm/mach-shmobile/Makefile.boot
+++ b/arch/arm/mach-shmobile/Makefile.boot
@@ -7,6 +7,7 @@ loadaddr-$(CONFIG_MACH_ARMADILLO800EVA_REFERENCE) += 0x40008000
 loadaddr-$(CONFIG_MACH_BOCKW) += 0x60008000
 loadaddr-$(CONFIG_MACH_KOTA2) += 0x41008000
 loadaddr-$(CONFIG_MACH_KZM9D) += 0x40008000
+loadaddr-$(CONFIG_MACH_KZM9D_REFERENCE) += 0x40008000
 loadaddr-$(CONFIG_MACH_KZM9G) += 0x41008000
 loadaddr-$(CONFIG_MACH_KZM9G_REFERENCE) += 0x41008000
 loadaddr-$(CONFIG_MACH_LAGER) += 0x40008000
diff --git a/arch/arm/mach-shmobile/board-kzm9d-reference.c b/arch/arm/mach-shmobile/board-kzm9d-reference.c
new file mode 100644
index 0000000..a7b28b2
--- /dev/null
+++ b/arch/arm/mach-shmobile/board-kzm9d-reference.c
@@ -0,0 +1,46 @@
+/*
+ * kzm9d board support - Reference DT implementation
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <linux/init.h>
+#include <linux/of_platform.h>
+#include <mach/emev2.h>
+#include <mach/common.h>
+#include <asm/mach/arch.h>
+
+static void __init kzm9d_add_standard_devices(void)
+{
+	emev2_clock_init();
+
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char *kzm9d_boards_compat_dt[] __initdata = {
+	"renesas,kzm9d-reference",
+	NULL,
+};
+
+DT_MACHINE_START(KZM9D_DT, "kzm9d")
+	.smp		= smp_ops(emev2_smp_ops),
+	.map_io		= emev2_map_io,
+	.init_early	= emev2_init_delay,
+	.init_machine	= kzm9d_add_standard_devices,
+	.init_late	= shmobile_init_late,
+	.dt_compat	= kzm9d_boards_compat_dt,
+MACHINE_END
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 03:37:00 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:37:00 +0900
Subject: [PATCH 3/5] ARM: shmobile: Force ARM mode to compile reset vector for
 secondary CPUs
In-Reply-To: <cover.1374478336.git.horms+renesas@verge.net.au>
References: <cover.1374478336.git.horms+renesas@verge.net.au>
Message-ID: <c1d7e2e80079148626e6c411e56708d86311d31a.1374478336.git.horms+renesas@verge.net.au>

From: Tetsuyuki Kobayashi <koba at kmckk.co.jp>

Instructions start from boot vector must be ARM mode.
This patch specify ARM mode explicitly and use 'bx' instruction to be
able to change to Thumb mode.

Signed-off-by: Tetsuyuki Kobayashi <koba at kmckk.co.jp>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/headsmp.S | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index 559d1ce..afed58e 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -26,10 +26,13 @@ ENDPROC(shmobile_invalidate_start)
  * This will be mapped at address 0 by SBAR register.
  * We need _long_ jump to the physical address.
  */
+	.arm
 	.align  12
 ENTRY(shmobile_boot_vector)
 	ldr     r0, 2f
-	ldr     pc, 1f
+	ldr     r1, 1f
+	bx	r1
+
 ENDPROC(shmobile_boot_vector)
 
 	.globl	shmobile_boot_fn
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 03:36:59 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:36:59 +0900
Subject: [PATCH 2/5] ARM: shmobile: fix compile error when
 CONFIG_THUMB2_KERNEL=y
In-Reply-To: <cover.1374478336.git.horms+renesas@verge.net.au>
References: <cover.1374478336.git.horms+renesas@verge.net.au>
Message-ID: <bdea6c657e15a709e666ea707e72327c555e8e04.1374478336.git.horms+renesas@verge.net.au>

From: Tetsuyuki Kobayashi <koba at kmckk.co.jp>

On KZM-A9-GT board (SMP), when CONFIG_THUMB2_KERNEL=y it fails to compile

  AS      arch/arm/mach-shmobile/headsmp-scu.o
/proj/koba/kernel/arm-soc/arch/arm/mach-shmobile/headsmp-scu.S: Assembler messages:
/proj/koba/kernel/arm-soc/arch/arm/mach-shmobile/headsmp-scu.S:41: Error: shift must be constant -- `bic r2,r2,r3,lsl r1'
make[2]: *** [arch/arm/mach-shmobile/headsmp-scu.o] Error 1
make[1]: *** [arch/arm/mach-shmobile] Error 2
make: *** [sub-make] Error 2

Instruction `bic r2,r2,r3,lsl r1' is not supported in thumb mode. This patch split it into 2 instructions.

Signed-off-by: Tetsuyuki Kobayashi <koba at kmckk.co.jp>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/headsmp-scu.S | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/headsmp-scu.S b/arch/arm/mach-shmobile/headsmp-scu.S
index 6f98654..5ce416c 100644
--- a/arch/arm/mach-shmobile/headsmp-scu.S
+++ b/arch/arm/mach-shmobile/headsmp-scu.S
@@ -38,7 +38,8 @@ ENTRY(shmobile_boot_scu)
 	lsl	r1, r1, #3		@ we will shift by cpu_id * 8 bits
 	ldr	r2, [r0, #8]		@ SCU Power Status Register
 	mov	r3, #3
-	bic	r2, r2, r3, lsl r1	@ Clear bits of our CPU (Run Mode)
+	lsl	r3, r3, r1
+	bic	r2, r2, r3		@ Clear bits of our CPU (Run Mode)
 	str	r2, [r0, #8]		@ write back
 
 	b	shmobile_invalidate_start
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 03:36:58 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:36:58 +0900
Subject: [PATCH 1/5] ARM: shmobile: Update romImage to relocate appended DTB
In-Reply-To: <cover.1374478336.git.horms+renesas@verge.net.au>
References: <cover.1374478336.git.horms+renesas@verge.net.au>
Message-ID: <2c408d149299e99c89fc4be80fb4fe00a7016f02.1374478336.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Instead of relying of MACH_TYPE for board identification,
update the romImage code to relocate an appended DTB to
the beginning of RAM. This implementation is independent
of ARM_APPENDED_DTB, this because it is necessary to copy
the DTB to memory so the kernel can access it.

Without this patch Mackerel does not boot via the Mask ROM
over USB (r_usb_boot) - this since non-DT boot was broken
ages ago in commit:

0ce53cd ARM: mach-shmobile: Use DT_MACHINE for mackerel

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/compressed/head-shmobile.S    | 43 ++++++++++++++++++++++++++---
 arch/arm/mach-shmobile/include/mach/zboot.h |  2 --
 2 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/compressed/head-shmobile.S b/arch/arm/boot/compressed/head-shmobile.S
index e2d6363..e7f8092 100644
--- a/arch/arm/boot/compressed/head-shmobile.S
+++ b/arch/arm/boot/compressed/head-shmobile.S
@@ -55,12 +55,47 @@ __tmp_stack:
 __continue:
 #endif /* CONFIG_ZBOOT_ROM_MMC || CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI */
 
-	/* Set board ID necessary for boot */
-	ldr	r7, 1f				@ Set machine type register
-	mov	r8, #0				@ pass null pointer as atag
+	adr	r0, dtb_info
+	ldmia	r0, {r1, r3, r4, r5, r7}
+
+	sub	r0, r0, r1		@ calculate the delta offset
+	add	r5, r5, r0		@ _edata
+
+	ldr	lr, [r5, #0]		@ check if valid DTB is present
+	cmp	lr, r3
+	bne	0f
+
+	add	r9, r7, #31		@ rounded up to a multiple
+	bic	r9, r9, #31		@ ... of 32 bytes
+
+	add	r6, r9, r5		@ copy from _edata
+	add	r9, r9, r4		@ to MEMORY_START
+
+1:	ldmdb	r6!, {r0 - r3, r10 - r12, lr}
+	cmp	r6, r5
+	stmdb	r9!, {r0 - r3, r10 - r12, lr}
+	bhi	1b
+
+	/* Success: Zero board ID, pointer to start of memory for atag/dtb */
+	mov	r7, #0
+	mov	r8, r4
 	b	2f
 
-1 :	.long MACH_TYPE
+	.align	2
+dtb_info:
+	.word	dtb_info
+#ifndef __ARMEB__
+	.word	0xedfe0dd0		@ sig is 0xd00dfeed big endian
+#else
+	.word	0xd00dfeed
+#endif
+	.word	MEMORY_START
+	.word	_edata
+	.word	0x4000			@ maximum DTB size
+0:
+	/* Failure: Zero board ID, NULL atag/dtb */
+	mov 	r7, #0
+	mov	r8, #0			@ pass null pointer as atag
 2 :
 
 #endif /* CONFIG_ZBOOT_ROM */
diff --git a/arch/arm/mach-shmobile/include/mach/zboot.h b/arch/arm/mach-shmobile/include/mach/zboot.h
index f2d8744..c3c4669 100644
--- a/arch/arm/mach-shmobile/include/mach/zboot.h
+++ b/arch/arm/mach-shmobile/include/mach/zboot.h
@@ -1,7 +1,6 @@
 #ifndef ZBOOT_H
 #define ZBOOT_H
 
-#include <asm/mach-types.h>
 #include <mach/zboot_macros.h>
 
 /**************************************************
@@ -11,7 +10,6 @@
  **************************************************/
 
 #ifdef CONFIG_MACH_MACKEREL
-#define MACH_TYPE	MACH_TYPE_MACKEREL
 #define MEMORY_START	0x40000000
 #include "mach/head-mackerel.txt"
 #else
-- 
1.8.2.1



From horms+renesas at verge.net.au  Mon Jul 22 03:37:01 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Mon, 22 Jul 2013 16:37:01 +0900
Subject: [PATCH 4/5] ARM: shmobile: Insert align directives before 4 bytes data
In-Reply-To: <cover.1374478336.git.horms+renesas@verge.net.au>
References: <cover.1374478336.git.horms+renesas@verge.net.au>
Message-ID: <0b933cb305e7a987e0a711ee15457bd70055d682.1374478336.git.horms+renesas@verge.net.au>

From: Tetsuyuki Kobayashi <koba at kmckk.co.jp>

In thumb2 mode instructions are not align to 4 byte. This patch insert
align directives before putting 4 byte data.

Signed-off-by: Tetsuyuki Kobayashi <koba at kmckk.co.jp>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/headsmp-scu.S  | 1 +
 arch/arm/mach-shmobile/headsmp.S      | 1 +
 arch/arm/mach-shmobile/sleep-sh7372.S | 2 ++
 3 files changed, 4 insertions(+)

diff --git a/arch/arm/mach-shmobile/headsmp-scu.S b/arch/arm/mach-shmobile/headsmp-scu.S
index 5ce416c..0a77488 100644
--- a/arch/arm/mach-shmobile/headsmp-scu.S
+++ b/arch/arm/mach-shmobile/headsmp-scu.S
@@ -46,6 +46,7 @@ ENTRY(shmobile_boot_scu)
 ENDPROC(shmobile_boot_scu)
 
 	.text
+	.align	2
 	.globl	shmobile_scu_base
 shmobile_scu_base:
 	.space	4
diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index afed58e..dfb41df 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -35,6 +35,7 @@ ENTRY(shmobile_boot_vector)
 
 ENDPROC(shmobile_boot_vector)
 
+	.align	2
 	.globl	shmobile_boot_fn
 shmobile_boot_fn:
 1:	.space	4
diff --git a/arch/arm/mach-shmobile/sleep-sh7372.S b/arch/arm/mach-shmobile/sleep-sh7372.S
index 53f4840..9782862 100644
--- a/arch/arm/mach-shmobile/sleep-sh7372.S
+++ b/arch/arm/mach-shmobile/sleep-sh7372.S
@@ -41,6 +41,7 @@
 sh7372_resume_core_standby_sysc:
 	ldr     pc, 1f
 
+	.align	2
 	.globl	sh7372_cpu_resume
 sh7372_cpu_resume:
 1:	.space	4
@@ -96,6 +97,7 @@ sh7372_do_idle_sysc:
 1:
 	b      1b
 
+	.align	2
 kernel_flush:
 	.word v7_flush_dcache_all
 #endif
-- 
1.8.2.1



From tomasz.figa at gmail.com  Mon Jul 22 03:43:23 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 09:43:23 +0200
Subject: [PATCH v4 02/20] clocksource: samsung_pwm_timer: Correct
 definition of AUTORELOAD bit
In-Reply-To: <51ECABF1.4040600@linaro.org>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-4-git-send-email-tomasz.figa@gmail.com>
 <51ECABF1.4040600@linaro.org>
Message-ID: <9612221.r4mx9bHE64@flatron>

On Monday 22 of July 2013 05:50:09 Daniel Lezcano wrote:
> On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> > PWM channel 4 has its autoreload bit located at different position.
> > This patch fixes the driver to account for that.
> > 
> > This fixes a problem with the clocksource hanging after it overflows
> > because it is not reloaded any more.
> > 
> > Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> > ---
> > 
> >  drivers/clocksource/samsung_pwm_timer.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/clocksource/samsung_pwm_timer.c
> > b/drivers/clocksource/samsung_pwm_timer.c index 3fa5b07..e238fb0
> > 100644
> > --- a/drivers/clocksource/samsung_pwm_timer.c
> > +++ b/drivers/clocksource/samsung_pwm_timer.c
> > @@ -47,7 +47,8 @@
> > 
> >  #define TCON_START(chan)		(1 << (4 * (chan) + 0))
> >  #define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
> >  #define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
> > 
> > -#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
> > +#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) \
> > +						+ (((chan) < 5) ? 3 : 2)))
> 
> This macro is not readable. Please, fix it up with a comment please.

/*
 * Channel 4 (logically 5 in TCON register) has different position
 * of autoreload bit.
 */
#define _TCON_AUTORELOAD(chan)			(1 << (4 * (chan) + 3))
#define _TCON_AUTORELOAD4(chan)			(1 << (4 * (chan) + 2))
#define TCON_AUTORELOAD(chan)			((chan < 5) ? 
		_TCON_AUTORELOAD(chan) : _TCON_AUTORELOAD4(chan))

What do you think?

Best regards,
Tomasz



From tomasz.figa at gmail.com  Mon Jul 22 03:47:04 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 09:47:04 +0200
Subject: [PATCH v4 04/20] clocksource: samsung_pwm_timer: Do not use
 clocksource_mmio
In-Reply-To: <51ECAD60.1000109@linaro.org>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-6-git-send-email-tomasz.figa@gmail.com>
 <51ECAD60.1000109@linaro.org>
Message-ID: <19090469.Cf6sbb33Ke@flatron>

Hi Daniel,

On Monday 22 of July 2013 05:56:16 Daniel Lezcano wrote:
> On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> > In case of Samsung PWM timer, clocksource MMIO can not be used,
> > because
> > custom suspend/resume callbacks are required.
> > 
> > Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> > ---
> 
> Reviewed-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Thanks for review.

> Please in the future Cc me and Thomas Gleixner (clocksource/clockevent
> maintainers).

Oh, right, sorry. This series originally was not touching the clocksource 
driver and I just kept original recipient list.

Btw. Have you updated MAINTAINERS file? In latest linux-next I can still 
see only John Stultz and Thomas Gleixner as maintainers of 
drivers/clocksource.

Best regards,
Tomasz



From shawn.guo at linaro.org  Mon Jul 22 03:47:35 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Jul 2013 15:47:35 +0800
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <51E95F10.5070006@wwwdotorg.org>
References: <20130716041056.GA30067@S2101-09.ap.freescale.net>
 <51E56AA7.7020103@wwwdotorg.org>
 <20130717030246.GA4541@S2101-09.ap.freescale.net>
 <51E6CCE4.20705@wwwdotorg.org>
 <20130717213836.GA13324@amd.pavel.ucw.cz>
 <51E719A6.6070105@wwwdotorg.org>
 <20130718112555.GB1021@amd.pavel.ucw.cz>
 <CAOesGMgi0j_mPyeBLVHb_QW+DwtAPoFY697eQO3-yp9tnP1vmA@mail.gmail.com>
 <20130719032328.GB20889@S2101-09.ap.freescale.net>
 <51E95F10.5070006@wwwdotorg.org>
Message-ID: <20130722074733.GA20271@S2101-09.ap.freescale.net>

On Fri, Jul 19, 2013 at 09:45:20AM -0600, Stephen Warren wrote:
> That sounds like it /could/ well be an issue. Do you have all that
> actually hooked up through device tree so you can demonstrate the amount
> of deferred probing that /actually/ happens though?
> 
> In order to push the probe order in the right direction, I would
> personally prefer to see some kind of explicit hinting or outright
> representation of probe order in the DT.

I do not have a kernel supporting all those devices yet.

Shawn



From tomasz.figa at gmail.com  Mon Jul 22 03:49:49 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 09:49:49 +0200
Subject: [PATCH v4 00/20] Samsung PWM support cleanup
In-Reply-To: <0ac901ce867f$638a7530$2a9f5f90$@org>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <9102768.ef8LAvpunv@flatron> <0ac901ce867f$638a7530$2a9f5f90$@org>
Message-ID: <2036745.TWe3OlGh9t@flatron>

On Monday 22 of July 2013 11:01:32 Kukjin Kim wrote:
> Kukjin Kim wrote:
> > Tomasz Figa wrote:
> > > On Monday 22 of July 2013 00:22:16 Sylwester Nawrocki wrote:
> > > > On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> > > > > Since we now have a proper Samsung PWM clocksource driver in
> > > > > place,
> > > > > we can proceed with further cleanup of PWM timers support on
> > > > > Samsung
> > > > > SoCs.>
> > > > > 
> > > > > This series attempts to achieve this goal by:
> > > > >   1) fixing up few things in samsung_pwm_timer clocksource
> > > > >   driver,
> > > > >   2) moving remaining Samsung platforms to the new clocksource
> > 
> > driver,
> > 
> > > > >   3) removing old clocksource driver,
> > > > >   4) adding new multiplatform- and DT-aware PWM driver,
> > > > >   5) moving all Samsung platforms to use the new PWM driver,
> > > > >   6) removing old PWM driver,
> > > > >   7) removing all PWM-related code that is not used anymore.
> > > > > 
> > > > > Cleaning up the PWM driver is a bit tricky, because the design
> > > > > of
> > > > > current driver makes it completely unsuitable for DT and
> > > > > multiplatform and would require a heavy rework to make it
> > > > > usable,
> > > > > breaking any existing Samsung PWM users by the way. To avoid any
> > > > > breakage this series first renames the old driver, then adds new
> > > > > one
> > > > > using original name, migrates all platforms to use it and then
> > > > > finally removes the old driver.
> > > > > 
> > > > > See particular patches for more detailed descriptions.
> > > > > 
> > > > > [On S3C6410-based Tiny6410 (Mini6410-compatible) with
> > > > > pwm-beeper,
> > > > > SMDK6410 with PWM backlight and Exynos4210-based Origen board
> > > > > (with
> > > > > PWM0 attached to a scope)]
> > > > > Tested-by: Tomasz Figa<tomasz.figa at gmail.com>
> > > > > 
> > > > > [On S3C2440-based Mini2440 board]
> > > > > Tested-by: Sylwester Nawrocki<sylvester.nawrocki at gmail.com>
> > > > 
> > > > I have retested this series on top of v3.11-rc1 with pwm-backlight
> > 
> > (and
> > 
> > > > buzzer
> > > > as the output :)) on Mini2440. It seems to work well - generated
> > > > frequencies are correct. I'll check pulse widths with a scope
> 
> tomorrow,
> 
> > > > as it's a bit late
> > > > now. FWIW you can add to this series my:
> > > > 
> > > > Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> > > 
> > > Thanks. I hope we can finally get this series merged soon.
> > 
> > Yes, this whole patches look good to me, and I'd like to take this
> > whole patches into the samsung tree...but need to get any response
> > from PWM guy, Thierry Reding. Let's wait for his response...
> 
> To be clarify, because his ack was on v3 and I remember he had a
> comment. So would be better if we could get his ack on pwm change
> again.

Sure.

Best regards,
Tomasz



From shawn.guo at linaro.org  Mon Jul 22 03:55:54 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Jul 2013 15:55:54 +0800
Subject: [PATCH 1/2] ARM: dts: mx6: Add support for mx6q nitrogen board
In-Reply-To: <1374118960-19060-1-git-send-email-festevam@gmail.com>
References: <1374118960-19060-1-git-send-email-festevam@gmail.com>
Message-ID: <20130722075552.GB20271@S2101-09.ap.freescale.net>

On Thu, Jul 18, 2013 at 12:42:39AM -0300, Fabio Estevam wrote:
> +&ecspi1 {
> +	fsl,spi-num-chipselects = <1>;
> +	cs-gpios = <&gpio3 19 0>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_ecspi1_1>;
> +	status = "okay";
> +
> +	flash: m25p80 at 0 {
> +		compatible = "sst,sst25vf016b";
> +		spi-max-frequency = <20000000>;
> +		reg = <0>;
> +	};
> +};
> +
> +&ssi1 {
> +	fsl,mode = "i2s-slave";
> +	status = "okay";
> +};
> +

Please take the chance to sort these node alphabetically.

Shawn

> +&iomuxc {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_hog>;
> +
> +	hog {
> +		pinctrl_hog: hoggrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x80000000
> +				MX6QDL_PAD_NANDF_D7__GPIO2_IO07 0x80000000
> +				MX6QDL_PAD_EIM_D19__GPIO3_IO19  0x80000000
> +				MX6QDL_PAD_EIM_D22__GPIO3_IO22  0x80000000
> +				MX6QDL_PAD_EIM_D23__GPIO3_IO23  0x80000000
> +				MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x80000000
> +				MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x1f0b0
> +				MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x80000000
> +			>;
> +		};
> +	};
> +};
> +
> +&usbotg {
> +	vbus-supply = <&reg_usb_otg_vbus>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usbotg_1>;
> +	disable-over-current;
> +	status = "okay";
> +};
> +
> +&usbh1 {
> +	status = "okay";
> +};
> +
> +&fec {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_enet_1>;
> +	phy-mode = "rgmii";
> +	phy-reset-gpios = <&gpio3 23 0>;
> +	status = "okay";
> +};
> +
> +&usdhc3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usdhc3_2>;
> +	cd-gpios = <&gpio7 0 0>;
> +	wp-gpios = <&gpio7 1 0>;
> +	vmmc-supply = <&reg_3p3v>;
> +	status = "okay";
> +};
> +
> +&usdhc4 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usdhc4_2>;
> +	cd-gpios = <&gpio2 6 0>;
> +	wp-gpios = <&gpio2 7 0>;
> +	vmmc-supply = <&reg_3p3v>;
> +	status = "okay";
> +};
> +
> +&audmux {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_audmux_1>;
> +};
> +
> +&uart2 {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart2_1>;
> +};
> +
> +&i2c1 {
> +	status = "okay";
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c1_1>;
> +
> +	codec: sgtl5000 at 0a {
> +		compatible = "fsl,sgtl5000";
> +		reg = <0x0a>;
> +		clocks = <&clks 169>;
> +		VDDA-supply = <&reg_2p5v>;
> +		VDDIO-supply = <&reg_3p3v>;
> +	};
> +};
> -- 
> 1.8.1.2
> 



From shawn.guo at linaro.org  Mon Jul 22 03:57:37 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Jul 2013 15:57:37 +0800
Subject: [PATCH 2/2] ARM: dts: mx6: Add support for imx6dl nitrogen board
In-Reply-To: <1374118960-19060-2-git-send-email-festevam@gmail.com>
References: <1374118960-19060-1-git-send-email-festevam@gmail.com>
 <1374118960-19060-2-git-send-email-festevam@gmail.com>
Message-ID: <20130722075736.GC20271@S2101-09.ap.freescale.net>

On Thu, Jul 18, 2013 at 12:42:40AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  arch/arm/boot/dts/Makefile            |  1 +
>  arch/arm/boot/dts/imx6dl-nitrogen.dts | 23 +++++++++++++++++++++++
>  2 files changed, 24 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6dl-nitrogen.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index eeb2275..3f1a75d 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -124,6 +124,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
>  	imx53-mba53.dtb \
>  	imx53-qsb.dtb \
>  	imx53-smd.dtb \
> +	imx6dl-nitrogen.dtb \
>  	imx6dl-sabreauto.dtb \
>  	imx6dl-sabresd.dtb \
>  	imx6dl-wandboard.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-nitrogen.dts b/arch/arm/boot/dts/imx6dl-nitrogen.dts
> new file mode 100644
> index 0000000..4f29207
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-nitrogen.dts
> @@ -0,0 +1,23 @@
> +/*
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * Author: Fabio Estevam <fabio.estevam at freescale.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +/dts-v1/;
> +#include "imx6q.dtsi"
> +#include "imx6qdl-nitrogen.dtsi"
> +
> +/ {
> +	model = "Boundary Devices i.MX6 Dual Lite Nitrogen Board";
> +	compatible = "boundary,imx6dl-nitrogen", "fsl,imx6dl";
> +
> +	memory {
> +		reg = <0x10000000 0x40000000>;
> +	};

This memory configuration is also common, right?

Shawn

> +};
> -- 
> 1.8.1.2
> 



From shawn.guo at linaro.org  Mon Jul 22 04:00:45 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Jul 2013 16:00:45 +0800
Subject: [PATCH] gpio/mxc: add chained_irq_enter/exit() to
 mx2_gpio_irq_handler
In-Reply-To: <1374152286-12955-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1374152286-12955-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <20130722080043.GD20271@S2101-09.ap.freescale.net>

On Thu, Jul 18, 2013 at 02:58:06PM +0200, Uwe Kleine-K?nig wrote:
> Similar to commit
> 
> 	0e44b6e (gpio/mxc: add chained_irq_enter/exit() to mx3_gpio_irq_handler())
> 
> . It doesn't seem to be critical to make the irqs work, but still it is
> more correct.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Acked-by: Shawn Guo <shawn.guo at linaro.org>

You may need to send the patch to Linus Walleij <linus.walleij at linaro.org>,
who seems to be collecting GPIO drive changes recently.

Shawn



From shawn.guo at linaro.org  Mon Jul 22 04:10:27 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Jul 2013 16:10:27 +0800
Subject: [PATCH v4 10/17] clocksource: mxs_timer: Switch to
 sched_clock_register()
In-Reply-To: <1374189690-10810-11-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-11-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130722081025.GE20271@S2101-09.ap.freescale.net>

On Thu, Jul 18, 2013 at 04:21:23PM -0700, Stephen Boyd wrote:
> The 32 bit sched_clock interface now supports 64 bits. Upgrade to
> the 64 bit function to allow us to remove the 32 bit registration
> interface.
> 
> Cc: Shawn Guo <shawn.guo at linaro.org>

Acked-by: Shawn Guo <shawn.guo at linaro.org>

BTW, will the series break setup_sched_clock() users that are not
converted, like arch/arm/mach-imx/time.c?  I can understand that's the
consequence of not moving things into drivers/ folder :)

Shawn

> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  drivers/clocksource/mxs_timer.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clocksource/mxs_timer.c b/drivers/clocksource/mxs_timer.c
> index 0f5e65f..445b68a 100644
> --- a/drivers/clocksource/mxs_timer.c
> +++ b/drivers/clocksource/mxs_timer.c
> @@ -222,7 +222,7 @@ static struct clocksource clocksource_mxs = {
>  	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
>  };
>  
> -static u32 notrace mxs_read_sched_clock_v2(void)
> +static u64 notrace mxs_read_sched_clock_v2(void)
>  {
>  	return ~readl_relaxed(mxs_timrot_base + HW_TIMROT_RUNNING_COUNTn(1));
>  }
> @@ -236,7 +236,7 @@ static int __init mxs_clocksource_init(struct clk *timer_clk)
>  	else {
>  		clocksource_mmio_init(mxs_timrot_base + HW_TIMROT_RUNNING_COUNTn(1),
>  			"mxs_timer", c, 200, 32, clocksource_mmio_readl_down);
> -		setup_sched_clock(mxs_read_sched_clock_v2, 32, c);
> +		sched_clock_register(mxs_read_sched_clock_v2, 32, c);
>  	}
>  
>  	return 0;
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 



From chanho61.park at samsung.com  Mon Jul 22 04:12:30 2013
From: chanho61.park at samsung.com (Chanho Park)
Date: Mon, 22 Jul 2013 17:12:30 +0900
Subject: [PATCH] clk: exynos4: fix g2d/mdma clocks of exynos4x12
Message-ID: <1374480750-30962-1-git-send-email-chanho61.park@samsung.com>

The exynos4x12 has different address of GATE_IP_IMAGE reg. We should use
EXYNOS4X12_GATE_IP_IMAGE for g2d gating clocks instead of 4210's reg.
In case of mdma node, We don't use it for any exynos4 chipsets. I think we'll
need to change it to 'none' or leave it on.

Signed-off-by: Chanho Park <chanho61.park at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/clk/samsung/clk-exynos4.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index 1bdb882..6300c9d 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -820,8 +820,10 @@ struct samsung_gate_clock exynos4210_gate_clks[] __initdata = {
 struct samsung_gate_clock exynos4x12_gate_clks[] __initdata = {
 	GATE(audss, "audss", "sclk_epll", E4X12_GATE_IP_MAUDIO, 0, 0, 0),
 	GATE(mdnie0, "mdnie0", "aclk160", GATE_IP_LCD0, 2, 0, 0),
+	GATE(g2d, "g2d", "aclk200", E4X12_GATE_IP_IMAGE, 0, 0, 0),
 	GATE(rotator, "rotator", "aclk200", E4X12_GATE_IP_IMAGE, 1, 0, 0),
-	GATE(mdma2, "mdma2", "aclk200", E4X12_GATE_IP_IMAGE, 2, 0, 0),
+	GATE(mdma, "mdma", "aclk200", E4X12_GATE_IP_IMAGE, 2, 0, 0),
+	GATE(smmu_g2d, "smmu_g2d", "aclk200", E4X12_GATE_IP_IMAGE, 3, 0, 0),
 	GATE(smmu_mdma, "smmu_mdma", "aclk200", E4X12_GATE_IP_IMAGE, 5, 0, 0),
 	GATE(mipi_hsi, "mipi_hsi", "aclk133", GATE_IP_FSYS, 10, 0, 0),
 	GATE(chipid, "chipid", "aclk100", E4X12_GATE_IP_PERIR, 0, 0, 0),
-- 
1.7.9.5



From gleb at redhat.com  Mon Jul 22 03:36:06 2013
From: gleb at redhat.com (Gleb Natapov)
Date: Mon, 22 Jul 2013 10:36:06 +0300
Subject: [PATCH 3/4] arm64: KVM: let other tasks run when hitting WFE
In-Reply-To: <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
Message-ID: <20130722073605.GJ20379@redhat.com>

On Fri, Jul 19, 2013 at 02:53:54PM +0100, Marc Zyngier wrote:
> So far, when a guest executes WFE (like when waiting for a spinlock
> to become unlocked), we don't do a thing and let it run uninterrupted.
> 
> Another option is to trap a blocking WFE and offer the opportunity
> to the scheduler to switch to another task, potentially giving the
> vcpu holding the spinlock a chance to run sooner.
> 
Why is this targeted at 3.11 as opposite to 3.12? Looks like an
optimization.

> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/kvm_arm.h |  6 ++++--
>  arch/arm64/kvm/handle_exit.c     | 18 +++++++++++++-----
>  2 files changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index a5f28e2..ac1ea05 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -63,6 +63,7 @@
>   * TAC:		Trap ACTLR
>   * TSC:		Trap SMC
>   * TSW:		Trap cache operations by set/way
> + * TWE:		Trap WFE
>   * TWI:		Trap WFI
>   * TIDCP:	Trap L2CTLR/L2ECTLR
>   * BSU_IS:	Upgrade barriers to the inner shareable domain
> @@ -72,8 +73,9 @@
>   * FMO:		Override CPSR.F and enable signaling with VF
>   * SWIO:	Turn set/way invalidates into set/way clean+invalidate
>   */
> -#define HCR_GUEST_FLAGS (HCR_TSC | HCR_TSW | HCR_TWI | HCR_VM | HCR_BSU_IS | \
> -			 HCR_FB | HCR_TAC | HCR_AMO | HCR_IMO | HCR_FMO | \
> +#define HCR_GUEST_FLAGS (HCR_TSC | HCR_TSW | HCR_TWE | HCR_TWI | HCR_VM | \
> +			 HCR_BSU_IS | HCR_FB | HCR_TAC | \
> +			 HCR_AMO | HCR_IMO | HCR_FMO | \
>  			 HCR_SWIO | HCR_TIDCP | HCR_RW)
>  #define HCR_VIRT_EXCP_MASK (HCR_VA | HCR_VI | HCR_VF)
>  
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 9beaca03..b0098c2 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -47,21 +47,29 @@ static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  }
>  
>  /**
> - * kvm_handle_wfi - handle a wait-for-interrupts instruction executed by a guest
> + * kvm_handle_wfx - handle a wait-for-interrupts or wait-for-event
> + *		    instruction executed by a guest
> + *
>   * @vcpu:	the vcpu pointer
>   *
> - * Simply call kvm_vcpu_block(), which will halt execution of
> + * WFE: Yield the CPU and come back to this vcpu when the scheduler
> + * decides to.
> + * WFI: Simply call kvm_vcpu_block(), which will halt execution of
>   * world-switches and schedule other host processes until there is an
>   * incoming IRQ or FIQ to the VM.
>   */
> -static int kvm_handle_wfi(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  {
> -	kvm_vcpu_block(vcpu);
> +	if (kvm_vcpu_get_hsr(vcpu) & 1)
> +		cond_resched();
> +	else
> +		kvm_vcpu_block(vcpu);
> +
>  	return 1;
>  }
>  
>  static exit_handle_fn arm_exit_handlers[] = {
> -	[ESR_EL2_EC_WFI]	= kvm_handle_wfi,
> +	[ESR_EL2_EC_WFI]	= kvm_handle_wfx,
>  	[ESR_EL2_EC_CP15_32]	= kvm_handle_cp15_32,
>  	[ESR_EL2_EC_CP15_64]	= kvm_handle_cp15_64,
>  	[ESR_EL2_EC_CP14_MR]	= kvm_handle_cp14_access,
> -- 
> 1.8.2.3
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
			Gleb.


From jg1.han at samsung.com  Mon Jul 22 04:30:44 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Mon, 22 Jul 2013 17:30:44 +0900
Subject: [PATCH 2/3] video: hx8357: Make IM pins optional
In-Reply-To: <20130719083555.GC5106@lukather>
References: <1373902022-20439-1-git-send-email-maxime.ripard@free-electrons.com>
 <1373902022-20439-3-git-send-email-maxime.ripard@free-electrons.com>
 <003501ce81be$4a945ed0$dfbd1c70$@samsung.com>
 <1373945380.7549.26.camel@marge.simpson.net> <20130719083555.GC5106@lukather>
Message-ID: <000301ce86b5$c280da30$47828e90$@samsung.com>

On Friday, July 19, 2013 5:36 PM, Maxime Ripard wrote:
> On Tue, Jul 16, 2013 at 05:29:40AM +0200, Mike Galbraith wrote:
> > On Tue, 2013-07-16 at 09:49 +0900, Jingoo Han wrote:
> > > On Tuesday, July 16, 2013 12:27 AM, Maxime Ripard wrote:
> >
> > > > +
> > > > +			ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
> > > > +						    GPIOF_OUT_INIT_LOW, "im_pins");
> > >
> > > This makes a checkpatch warning such as 'WARNING: line over 80 characters'.
> > > How about the following?
> > >
> > > 			ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
> > > 						GPIOF_OUT_INIT_LOW, "im_pins");
> >
> > IIRC, some maintainers gripe (davem?) when they see such alignment,
> > preferring the original arg below arg alignment vs strict 80 column.
> 
> As far as I know, the coding guide styles are quite fuzzy about this:
>   - The new line is not required to be aligned with the braces above
>   - Yet, the emacs config given does indent like this.
>   - 80 characters is said not to be a hard limit

Even though 80 characters is not a hard limit, 80 characters is preferred
if possible.

> 
> I don't really know if there's a better solution here, except maybe:
> ret = devm_gpio_request_one(&spi-dev, lcd->im_pins[i],
> 			    GPIOF_OUT_INIT_LOW,
> 			    "im_pins");

Yes, I think that this can be used. :)


Best regards,
Jingoo Han

> 
> But it's not really a big deal, is it?
> 
> Maxime
> 
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com



From elen.song at atmel.com  Mon Jul 22 04:30:23 2013
From: elen.song at atmel.com (Elen Song)
Date: Mon, 22 Jul 2013 16:30:23 +0800
Subject: [PATCH 0/8 V3] serial: at91: make usart and uart support dma transfer
Message-ID: <1374481831-24573-1-git-send-email-elen.song@atmel.com>

After at91sam9g45 socs, the usart only support dma transfer.
This patch serial focus on:
1) distinguish pdc and dma transfer
2) support usart dma rx and tx transfer
3) distinguish usart and uart
4) support uart dma rx and tx transfer

For those only support PDC transfer socs, we use "atmel,use-dma-rx/tx" to establish a PDC transfer.
For those only support DMA transfer socs, we not only use "atmel,use-dma-rx/tx", but also describe dma binding to establish a DMA transfer.
We switch the name from "use-dma" to "use-pdc" in serial driver to state more clearly.
We also distinguish usart and uart by read ip name, the dbgu is regard as a uart.
Because uart lack timeout function, we use software timer to trigger rx.

Compare to v1, this patch serials improve:
1) use function pointer instead of if/else
2) "atmel,use-dma-rx/tx" represent a PDC transfer,
   but when add the dma bindings, it is a dma transfer
3) do not use strncmp in get ip name
4) remove modification in documentation part

Compare to v2, this patch serials improve:
1) change type from short to bool in use_pdc_rx/tx
2) merge uart and dbgu patch
3) add document 

Elen Song (8):
  serial: at91: correct definition from DMA to PDC
  serial: at91: use function pointer to choose pdc or pio
  serial: at91: add tx dma support
  serial: at91: add rx dma support
  serial: at91: support run time switch transfer mode
  serial: at91: distinguish usart and uart
  serial: at91: make UART support dma and pdc transfers
  serial: at91: add dma support in usart binding descriptions

 .../devicetree/bindings/tty/serial/atmel-usart.txt |   18 +-
 drivers/tty/serial/atmel_serial.c                  |  842 ++++++++++++++++----
 include/linux/atmel_serial.h                       |    2 +
 3 files changed, 725 insertions(+), 137 deletions(-)

-- 
1.7.9.5



From elen.song at atmel.com  Mon Jul 22 04:30:24 2013
From: elen.song at atmel.com (Elen Song)
Date: Mon, 22 Jul 2013 16:30:24 +0800
Subject: [PATCH 1/8 V3] serial: at91: correct definition from DMA to PDC
In-Reply-To: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
References: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
Message-ID: <1374481831-24573-2-git-send-email-elen.song@atmel.com>

The DMA is available since at91sam9x5 socs, before that, we use PDC.

Signed-off-by: Elen Song <elen.song at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |   71 +++++++++++++++++++------------------
 1 file changed, 36 insertions(+), 35 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 3467462..81a8807 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -140,11 +140,11 @@ struct atmel_uart_port {
 	u32			backup_imr;	/* IMR saved during suspend */
 	int			break_active;	/* break being received */
 
-	short			use_dma_rx;	/* enable PDC receiver */
+	bool			use_pdc_rx;	/* enable PDC receiver */
 	short			pdc_rx_idx;	/* current PDC RX buffer */
 	struct atmel_dma_buffer	pdc_rx[2];	/* PDC receier */
 
-	short			use_dma_tx;	/* enable PDC transmitter */
+	bool			use_pdc_tx;	/* enable PDC transmitter */
 	struct atmel_dma_buffer	pdc_tx;		/* PDC transmitter */
 
 	struct tasklet_struct	tasklet;
@@ -181,26 +181,26 @@ to_atmel_uart_port(struct uart_port *uart)
 }
 
 #ifdef CONFIG_SERIAL_ATMEL_PDC
-static bool atmel_use_dma_rx(struct uart_port *port)
+static bool atmel_use_pdc_rx(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	return atmel_port->use_dma_rx;
+	return atmel_port->use_pdc_rx;
 }
 
-static bool atmel_use_dma_tx(struct uart_port *port)
+static bool atmel_use_pdc_tx(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	return atmel_port->use_dma_tx;
+	return atmel_port->use_pdc_tx;
 }
 #else
-static bool atmel_use_dma_rx(struct uart_port *port)
+static bool atmel_use_pdc_rx(struct uart_port *port)
 {
 	return false;
 }
 
-static bool atmel_use_dma_tx(struct uart_port *port)
+static bool atmel_use_pdc_tx(struct uart_port *port)
 {
 	return false;
 }
@@ -233,7 +233,7 @@ void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
 		mode |= ATMEL_US_USMODE_RS485;
 	} else {
 		dev_dbg(port->dev, "Setting UART to RS232\n");
-		if (atmel_use_dma_tx(port))
+		if (atmel_use_pdc_tx(port))
 			atmel_port->tx_done_mask = ATMEL_US_ENDTX |
 				ATMEL_US_TXBUFE;
 		else
@@ -345,7 +345,7 @@ static void atmel_stop_tx(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		/* disable PDC transmit */
 		UART_PUT_PTCR(port, ATMEL_PDC_TXTDIS);
 	}
@@ -364,7 +364,7 @@ static void atmel_start_tx(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		if (UART_GET_PTSR(port) & ATMEL_PDC_TXTEN)
 			/* The transmitter is already running.  Yes, we
 			   really need this.*/
@@ -390,7 +390,7 @@ static void atmel_start_rx(struct uart_port *port)
 
 	UART_PUT_CR(port, ATMEL_US_RXEN);
 
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		/* enable PDC controller */
 		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
 			port->read_status_mask);
@@ -407,7 +407,7 @@ static void atmel_stop_rx(struct uart_port *port)
 {
 	UART_PUT_CR(port, ATMEL_US_RXDIS);
 
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		/* disable PDC receive */
 		UART_PUT_PTCR(port, ATMEL_PDC_RXTDIS);
 		UART_PUT_IDR(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
@@ -572,7 +572,7 @@ atmel_handle_receive(struct uart_port *port, unsigned int pending)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		/*
 		 * PDC receive. Just schedule the tasklet and let it
 		 * figure out the details.
@@ -661,7 +661,7 @@ static irqreturn_t atmel_interrupt(int irq, void *dev_id)
 /*
  * Called from tasklet with ENDTX and TXBUFE interrupts disabled.
  */
-static void atmel_tx_dma(struct uart_port *port)
+static void atmel_tx_pdc(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 	struct circ_buf *xmit = &port->state->xmit;
@@ -778,7 +778,7 @@ static void atmel_rx_from_ring(struct uart_port *port)
 	spin_lock(&port->lock);
 }
 
-static void atmel_rx_from_dma(struct uart_port *port)
+static void atmel_rx_from_pdc(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 	struct tty_port *tport = &port->state->port;
@@ -868,8 +868,8 @@ static void atmel_tasklet_func(unsigned long data)
 	/* The interrupt handler does not take the lock */
 	spin_lock(&port->lock);
 
-	if (atmel_use_dma_tx(port))
-		atmel_tx_dma(port);
+	if (atmel_use_pdc_tx(port))
+		atmel_tx_pdc(port);
 	else
 		atmel_tx_chars(port);
 
@@ -893,8 +893,8 @@ static void atmel_tasklet_func(unsigned long data)
 		atmel_port->irq_status_prev = status;
 	}
 
-	if (atmel_use_dma_rx(port))
-		atmel_rx_from_dma(port);
+	if (atmel_use_pdc_rx(port))
+		atmel_rx_from_pdc(port);
 	else
 		atmel_rx_from_ring(port);
 
@@ -930,7 +930,7 @@ static int atmel_startup(struct uart_port *port)
 	/*
 	 * Initialize DMA (if necessary)
 	 */
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		int i;
 
 		for (i = 0; i < 2; i++) {
@@ -964,7 +964,7 @@ static int atmel_startup(struct uart_port *port)
 		UART_PUT_RNPR(port, atmel_port->pdc_rx[1].dma_addr);
 		UART_PUT_RNCR(port, PDC_BUFFER_SIZE);
 	}
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
 		struct circ_buf *xmit = &port->state->xmit;
 
@@ -1000,7 +1000,7 @@ static int atmel_startup(struct uart_port *port)
 	/* enable xmit & rcvr */
 	UART_PUT_CR(port, ATMEL_US_TXEN | ATMEL_US_RXEN);
 
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		/* set UART timeout */
 		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
 		UART_PUT_CR(port, ATMEL_US_STTTO);
@@ -1031,7 +1031,7 @@ static void atmel_shutdown(struct uart_port *port)
 	/*
 	 * Shut-down the DMA.
 	 */
-	if (atmel_use_dma_rx(port)) {
+	if (atmel_use_pdc_rx(port)) {
 		int i;
 
 		for (i = 0; i < 2; i++) {
@@ -1044,7 +1044,7 @@ static void atmel_shutdown(struct uart_port *port)
 			kfree(pdc->buf);
 		}
 	}
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
 
 		dma_unmap_single(port->dev,
@@ -1080,7 +1080,7 @@ static void atmel_flush_buffer(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_dma_tx(port)) {
+	if (atmel_use_pdc_tx(port)) {
 		UART_PUT_TCR(port, 0);
 		atmel_port->pdc_tx.ofs = 0;
 	}
@@ -1193,7 +1193,7 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
 	if (termios->c_iflag & (BRKINT | PARMRK))
 		port->read_status_mask |= ATMEL_US_RXBRK;
 
-	if (atmel_use_dma_rx(port))
+	if (atmel_use_pdc_rx(port))
 		/* need to enable error interrupts */
 		UART_PUT_IER(port, port->read_status_mask);
 
@@ -1430,13 +1430,14 @@ static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
 
 	/* DMA/PDC usage specification */
 	if (of_get_property(np, "atmel,use-dma-rx", NULL))
-		atmel_port->use_dma_rx	= 1;
+		atmel_port->use_pdc_rx	= true;
 	else
-		atmel_port->use_dma_rx	= 0;
+		atmel_port->use_pdc_rx	= false;
+
 	if (of_get_property(np, "atmel,use-dma-tx", NULL))
-		atmel_port->use_dma_tx	= 1;
+		atmel_port->use_pdc_tx	= true;
 	else
-		atmel_port->use_dma_tx	= 0;
+		atmel_port->use_pdc_tx	= false;
 
 	/* rs485 properties */
 	if (of_property_read_u32_array(np, "rs485-rts-delay",
@@ -1467,8 +1468,8 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 	if (pdev->dev.of_node) {
 		atmel_of_init_port(atmel_port, pdev->dev.of_node);
 	} else {
-		atmel_port->use_dma_rx	= pdata->use_dma_rx;
-		atmel_port->use_dma_tx	= pdata->use_dma_tx;
+		atmel_port->use_pdc_rx	= pdata->use_dma_rx;
+		atmel_port->use_pdc_tx	= pdata->use_dma_tx;
 		atmel_port->rs485	= pdata->rs485;
 	}
 
@@ -1505,7 +1506,7 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 	/* Use TXEMPTY for interrupt when rs485 else TXRDY or ENDTX|TXBUFE */
 	if (atmel_port->rs485.flags & SER_RS485_ENABLED)
 		atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
-	else if (atmel_use_dma_tx(port)) {
+	else if (atmel_use_pdc_tx(port)) {
 		port->fifosize = PDC_BUFFER_SIZE;
 		atmel_port->tx_done_mask = ATMEL_US_ENDTX | ATMEL_US_TXBUFE;
 	} else {
@@ -1794,7 +1795,7 @@ static int atmel_serial_probe(struct platform_device *pdev)
 		goto err;
 	}
 
-	if (!atmel_use_dma_rx(&port->uart)) {
+	if (!atmel_use_pdc_rx(&port->uart)) {
 		ret = -ENOMEM;
 		data = kmalloc(sizeof(struct atmel_uart_char)
 				* ATMEL_SERIAL_RINGSIZE, GFP_KERNEL);
-- 
1.7.9.5



From shawn.guo at linaro.org  Mon Jul 22 04:35:33 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Jul 2013 16:35:33 +0800
Subject: [PATCH] ARM: dts: imx6qdl-sabresd: Allow buttons to wake-up the
 system
In-Reply-To: <1374241223-27975-1-git-send-email-festevam@gmail.com>
References: <1374241223-27975-1-git-send-email-festevam@gmail.com>
Message-ID: <20130722083531.GG20271@S2101-09.ap.freescale.net>

On Fri, Jul 19, 2013 at 10:40:23AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> This is useful for testing suspend/resume sequence.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Applied, thanks.



From elen.song at atmel.com  Mon Jul 22 04:30:25 2013
From: elen.song at atmel.com (Elen Song)
Date: Mon, 22 Jul 2013 16:30:25 +0800
Subject: [PATCH 2/8 V3] serial: at91: use function pointer to choose pdc or pio
In-Reply-To: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
References: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
Message-ID: <1374481831-24573-3-git-send-email-elen.song@atmel.com>

use function pointer can avoid define atmel_use_pdc_tx/rx everywhere.
(*prepare_rx/tx)() is in setup transfer stage.
(*schedule_rx/tx)() is in tasklet schedule stage.
(*release_rx/tx)() is used when shutdown the transfer.

Signed-off-by: Elen Song <elen.song at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |  203 ++++++++++++++++++++++++-------------
 1 file changed, 130 insertions(+), 73 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 81a8807..ae61f2b 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -155,6 +155,12 @@ struct atmel_uart_port {
 
 	struct serial_rs485	rs485;		/* rs485 settings */
 	unsigned int		tx_done_mask;
+	int (*prepare_rx)(struct uart_port *port);
+	int (*prepare_tx)(struct uart_port *port);
+	void (*schedule_rx)(struct uart_port *port);
+	void (*schedule_tx)(struct uart_port *port);
+	void (*release_rx)(struct uart_port *port);
+	void (*release_tx)(struct uart_port *port);
 };
 
 static struct atmel_uart_port atmel_ports[ATMEL_MAX_UART];
@@ -658,6 +664,17 @@ static irqreturn_t atmel_interrupt(int irq, void *dev_id)
 	return pass_counter ? IRQ_HANDLED : IRQ_NONE;
 }
 
+static void atmel_release_tx_pdc(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
+
+	dma_unmap_single(port->dev,
+			 pdc->dma_addr,
+			 pdc->dma_size,
+			 DMA_TO_DEVICE);
+}
+
 /*
  * Called from tasklet with ENDTX and TXBUFE interrupts disabled.
  */
@@ -710,6 +727,23 @@ static void atmel_tx_pdc(struct uart_port *port)
 		uart_write_wakeup(port);
 }
 
+static int atmel_prepare_tx_pdc(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
+	struct circ_buf *xmit = &port->state->xmit;
+
+	pdc->buf = xmit->buf;
+	pdc->dma_addr = dma_map_single(port->dev,
+					pdc->buf,
+					UART_XMIT_SIZE,
+					DMA_TO_DEVICE);
+	pdc->dma_size = UART_XMIT_SIZE;
+	pdc->ofs = 0;
+
+	return 0;
+}
+
 static void atmel_rx_from_ring(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
@@ -778,6 +812,22 @@ static void atmel_rx_from_ring(struct uart_port *port)
 	spin_lock(&port->lock);
 }
 
+static void atmel_release_rx_pdc(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	int i;
+
+	for (i = 0; i < 2; i++) {
+		struct atmel_dma_buffer *pdc = &atmel_port->pdc_rx[i];
+
+		dma_unmap_single(port->dev,
+				 pdc->dma_addr,
+				 pdc->dma_size,
+				 DMA_FROM_DEVICE);
+		kfree(pdc->buf);
+	}
+}
+
 static void atmel_rx_from_pdc(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
@@ -855,6 +905,45 @@ static void atmel_rx_from_pdc(struct uart_port *port)
 	UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
 }
 
+static int atmel_prepare_rx_pdc(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	int i;
+
+	for (i = 0; i < 2; i++) {
+		struct atmel_dma_buffer *pdc = &atmel_port->pdc_rx[i];
+
+		pdc->buf = kmalloc(PDC_BUFFER_SIZE, GFP_KERNEL);
+		if (pdc->buf == NULL) {
+			if (i != 0) {
+				dma_unmap_single(port->dev,
+					atmel_port->pdc_rx[0].dma_addr,
+					PDC_BUFFER_SIZE,
+					DMA_FROM_DEVICE);
+				kfree(atmel_port->pdc_rx[0].buf);
+			}
+			atmel_port->use_pdc_rx = 0;
+			return -ENOMEM;
+		}
+		pdc->dma_addr = dma_map_single(port->dev,
+						pdc->buf,
+						PDC_BUFFER_SIZE,
+						DMA_FROM_DEVICE);
+		pdc->dma_size = PDC_BUFFER_SIZE;
+		pdc->ofs = 0;
+	}
+
+	atmel_port->pdc_rx_idx = 0;
+
+	UART_PUT_RPR(port, atmel_port->pdc_rx[0].dma_addr);
+	UART_PUT_RCR(port, PDC_BUFFER_SIZE);
+
+	UART_PUT_RNPR(port, atmel_port->pdc_rx[1].dma_addr);
+	UART_PUT_RNCR(port, PDC_BUFFER_SIZE);
+
+	return 0;
+}
+
 /*
  * tasklet handling tty stuff outside the interrupt handler.
  */
@@ -868,10 +957,7 @@ static void atmel_tasklet_func(unsigned long data)
 	/* The interrupt handler does not take the lock */
 	spin_lock(&port->lock);
 
-	if (atmel_use_pdc_tx(port))
-		atmel_tx_pdc(port);
-	else
-		atmel_tx_chars(port);
+	atmel_port->schedule_tx(port);
 
 	status = atmel_port->irq_status;
 	status_change = status ^ atmel_port->irq_status_prev;
@@ -893,14 +979,36 @@ static void atmel_tasklet_func(unsigned long data)
 		atmel_port->irq_status_prev = status;
 	}
 
-	if (atmel_use_pdc_rx(port))
-		atmel_rx_from_pdc(port);
-	else
-		atmel_rx_from_ring(port);
+	atmel_port->schedule_rx(port);
 
 	spin_unlock(&port->lock);
 }
 
+static void atmel_set_ops(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+	if (atmel_use_pdc_rx(port)) {
+		atmel_port->prepare_rx = &atmel_prepare_rx_pdc;
+		atmel_port->schedule_rx = &atmel_rx_from_pdc;
+		atmel_port->release_rx = &atmel_release_rx_pdc;
+	} else {
+		atmel_port->prepare_rx = NULL;
+		atmel_port->schedule_rx = &atmel_rx_from_ring;
+		atmel_port->release_rx = NULL;
+	}
+
+	if (atmel_use_pdc_tx(port)) {
+		atmel_port->prepare_tx = &atmel_prepare_tx_pdc;
+		atmel_port->schedule_tx = &atmel_tx_pdc;
+		atmel_port->release_tx = &atmel_release_tx_pdc;
+	} else {
+		atmel_port->prepare_tx = NULL;
+		atmel_port->schedule_tx = &atmel_tx_chars;
+		atmel_port->release_tx = NULL;
+	}
+}
+
 /*
  * Perform initialization and enable port for reception
  */
@@ -930,53 +1038,17 @@ static int atmel_startup(struct uart_port *port)
 	/*
 	 * Initialize DMA (if necessary)
 	 */
-	if (atmel_use_pdc_rx(port)) {
-		int i;
-
-		for (i = 0; i < 2; i++) {
-			struct atmel_dma_buffer *pdc = &atmel_port->pdc_rx[i];
-
-			pdc->buf = kmalloc(PDC_BUFFER_SIZE, GFP_KERNEL);
-			if (pdc->buf == NULL) {
-				if (i != 0) {
-					dma_unmap_single(port->dev,
-						atmel_port->pdc_rx[0].dma_addr,
-						PDC_BUFFER_SIZE,
-						DMA_FROM_DEVICE);
-					kfree(atmel_port->pdc_rx[0].buf);
-				}
-				free_irq(port->irq, port);
-				return -ENOMEM;
-			}
-			pdc->dma_addr = dma_map_single(port->dev,
-						       pdc->buf,
-						       PDC_BUFFER_SIZE,
-						       DMA_FROM_DEVICE);
-			pdc->dma_size = PDC_BUFFER_SIZE;
-			pdc->ofs = 0;
-		}
-
-		atmel_port->pdc_rx_idx = 0;
-
-		UART_PUT_RPR(port, atmel_port->pdc_rx[0].dma_addr);
-		UART_PUT_RCR(port, PDC_BUFFER_SIZE);
-
-		UART_PUT_RNPR(port, atmel_port->pdc_rx[1].dma_addr);
-		UART_PUT_RNCR(port, PDC_BUFFER_SIZE);
+	if (atmel_port->prepare_rx) {
+		retval = atmel_port->prepare_rx(port);
+		if (retval < 0)
+			atmel_set_ops(port);
 	}
-	if (atmel_use_pdc_tx(port)) {
-		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
-		struct circ_buf *xmit = &port->state->xmit;
 
-		pdc->buf = xmit->buf;
-		pdc->dma_addr = dma_map_single(port->dev,
-					       pdc->buf,
-					       UART_XMIT_SIZE,
-					       DMA_TO_DEVICE);
-		pdc->dma_size = UART_XMIT_SIZE;
-		pdc->ofs = 0;
+	if (atmel_port->prepare_tx) {
+		retval = atmel_port->prepare_tx(port);
+		if (retval < 0)
+			atmel_set_ops(port);
 	}
-
 	/*
 	 * If there is a specific "open" function (to register
 	 * control line interrupts)
@@ -1031,27 +1103,10 @@ static void atmel_shutdown(struct uart_port *port)
 	/*
 	 * Shut-down the DMA.
 	 */
-	if (atmel_use_pdc_rx(port)) {
-		int i;
-
-		for (i = 0; i < 2; i++) {
-			struct atmel_dma_buffer *pdc = &atmel_port->pdc_rx[i];
-
-			dma_unmap_single(port->dev,
-					 pdc->dma_addr,
-					 pdc->dma_size,
-					 DMA_FROM_DEVICE);
-			kfree(pdc->buf);
-		}
-	}
-	if (atmel_use_pdc_tx(port)) {
-		struct atmel_dma_buffer *pdc = &atmel_port->pdc_tx;
-
-		dma_unmap_single(port->dev,
-				 pdc->dma_addr,
-				 pdc->dma_size,
-				 DMA_TO_DEVICE);
-	}
+	if (atmel_port->release_rx)
+		atmel_port->release_rx(port);
+	if (atmel_port->release_tx)
+		atmel_port->release_tx(port);
 
 	/*
 	 * Disable all interrupts, port and break condition.
@@ -1473,6 +1528,8 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 		atmel_port->rs485	= pdata->rs485;
 	}
 
+	atmel_set_ops(port);
+
 	port->iotype		= UPIO_MEM;
 	port->flags		= UPF_BOOT_AUTOCONF;
 	port->ops		= &atmel_pops;
-- 
1.7.9.5



From christian.ruppert at abilis.com  Mon Jul 22 04:35:36 2013
From: christian.ruppert at abilis.com (Christian Ruppert)
Date: Mon, 22 Jul 2013 10:35:36 +0200
Subject: Issue with gpio and pinmux
In-Reply-To: <51EB590A.4010600@wwwdotorg.org>
References: <51E667BC.3070804@parrot.com> <51E82FBB.1080905@wwwdotorg.org>
 <CACRpkdb1n07KoQZSme1EMJfV-9pHr-kd_1eJ6HsBV5gz7Dh3Ww@mail.gmail.com>
 <51EB590A.4010600@wwwdotorg.org>
Message-ID: <20130722083535.GA19685@ab42.lan>

On Sat, Jul 20, 2013 at 09:44:10PM -0600, Stephen Warren wrote:
> On 07/20/2013 04:44 PM, Linus Walleij wrote:
> > On Thu, Jul 18, 2013 at 8:11 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> > 
> >> The issue is that some HW muxes groups of pins at a time, so simply
> >> because that group of pins is "claimed" by a mux function, implies
> >> nothing about which specific pins in that group are actually used; some
> >> may actually still be free for usage as a GPIO.
> > 
> > This we need to get into the documentation.
> > 
> >> The solution here may be one of:
> >>
> >> a) Modify pinctrl /not/ to allow both a GPIO and a mux function to claim
> >> a pin *if* the group that contains the pin only contains a single pin.
> >> This is a bit of a hacky special case though; there are other situations
> >> where "dual claiming" shouldn't be allowed, and this doesn't solve those.
> >>
> >> b) Ignore the issue; if the system configuration is correct, the issue
> >> won't cause problems in practice, since nothing will be configured to
> >> "dual claim" any pin.
> >>
> >> c) Enhance pinctrl with extra information, so it knows which pins in a
> >> group are usable as GPIO even when the group is claimed by a mux
> >> function. The list of pins could theoretically vary per mux function, so
> >> you'd need a table with lookup key (pin group, mux function) and output
> >> data (list of pins that can be "dual claimed"). This would be a complete
> >> solution. If a list wasn't provided, the pinctrl core could assume that
> >> mean no dual claim was allowed.
> > 
> > I guess (b) is what we have.
> > 
> > But it really feels incomplete does it not? IIRC the system was strict
> > not to allow simultaneous use of pins for GPIO and other functions
> > at all until the above corner case made it necessary to relax this
> > restriction.
> > 
> > A simple way to get (a) would be to just add a flag like ".strict"
> > to struct pinmux_ops but it feels cheap.
> > 
> > What do we need for (c)? I think we can refactor this as the Tegra
> > and U300 should be the two platforms with such tricky groups so
> > the impact should be fairly small right now. I'm just worried it would
> > be a complex and memory-consuming thing :-/
> 
> Actually, a better way to do (c) might be to just add an extra "op" to
> struct pinmux_ops; something like validate_gpio_mux(), passing in
> information such as whether a mux function is in effect on that pin,
> whether the pin is already claimed as a GPIO, and whether the function
> is being called to check a GPIO-claim or mux-claim operation . If the op
> is missing, no "dual claim" is allowed. If the op is present, the code
> in the op validates whether the particular GPIO is allowed to be claimed
> while the particular mux function is active.
> 
> That way, I think any driver that doesn't want to allow dual-claim
> doesn't have to do anything, but the few drivers that do can code up
> whatever algorithm they want; for Tegra, I'd just allow everything for
> simplicity, but we could always enhance that later if we want.

[ An introductory note on terminology: in the following, "port" refers
to a set of pins who's mux is controlled through the same bit field in
the same register, "interface" refers to the set of pins comprising a
functional unit, e.g. SCL and SDA of an I2C interface or the four pins
of an SPI interface ]

In my understanding, the problem stems from the fact that we always
claim an entire port instead of just the pins required for a given
functionality. The pinctrl core is already well equipped to manage
claiming interfaces instead of ports and thus a fourth alternative would
be to

d) implement gpio/pin conflict management in the already existing
callbacks inside the driver: Today, both enable and gpio_request_enable
exist (and can refuse a request for a configuration/pin).
If we only claim the pins used by a given interface instead of the
entire port, conflict management becomes natural (see
http://lkml.indiana.edu/hypermail/linux/kernel/1306.2/00749.html and the
following).

IMHO, the pinctrl drivers are the right place for everything but the
most basic pin conflict management since constraints on what can be
muxed at the same time are highly hardware implementation dependent. One
could e.g. imagine an implementation where a GPIO can override and snoop
a pin's output value in one mux configuration, just snoop the pin value
in another and do neither in a third.

I see two (independent) ways to enhance the pinctrl core in order to
support drivers in this task:
a) Add two functions pin_is_claimed and gpio_is_claimed which allow the
pinctrl driver to query if a given pin/gpio is available for muxing.
b) Add four functions lock_gpio/unlock_gpio and lock_pin/unlock_pin
which allow the pinctrl driver to prevent the core from granting
requests on GPIOs/pins.

This solution also has the advantage that it doesn't modify the default
behaviour of the core and it thus won't break existing drivers.

Greetings,
  Christian


From elen.song at atmel.com  Mon Jul 22 04:30:26 2013
From: elen.song at atmel.com (Elen Song)
Date: Mon, 22 Jul 2013 16:30:26 +0800
Subject: [PATCH 3/8 V3] serial: at91: add tx dma support
In-Reply-To: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
References: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
Message-ID: <1374481831-24573-4-git-send-email-elen.song@atmel.com>

Request a slave dma channel for tx dma use. Tx dma will setup a single transfer,
when transfer complete, it will call atmel_complete_tx_dma to do finish stuff.

Signed-off-by: Elen Song <elen.song at atmel.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |  210 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 206 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index ae61f2b..b8d8594 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -144,9 +144,15 @@ struct atmel_uart_port {
 	short			pdc_rx_idx;	/* current PDC RX buffer */
 	struct atmel_dma_buffer	pdc_rx[2];	/* PDC receier */
 
+	bool			use_dma_tx;     /* enable DMA transmitter */
 	bool			use_pdc_tx;	/* enable PDC transmitter */
 	struct atmel_dma_buffer	pdc_tx;		/* PDC transmitter */
 
+	spinlock_t			lock_tx;	/* port lock */
+	struct dma_chan			*chan_tx;
+	struct dma_async_tx_descriptor	*desc_tx;
+	dma_cookie_t			cookie_tx;
+	struct scatterlist		sg_tx;
 	struct tasklet_struct	tasklet;
 	unsigned int		irq_status;
 	unsigned int		irq_status_prev;
@@ -212,6 +218,13 @@ static bool atmel_use_pdc_tx(struct uart_port *port)
 }
 #endif
 
+static bool atmel_use_dma_tx(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+	return atmel_port->use_dma_tx;
+}
+
 /* Enable or disable the rs485 support */
 void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
 {
@@ -570,6 +583,182 @@ static void atmel_tx_chars(struct uart_port *port)
 		UART_PUT_IER(port, atmel_port->tx_done_mask);
 }
 
+static void atmel_complete_tx_dma(void *arg)
+{
+	struct atmel_uart_port *atmel_port = arg;
+	struct uart_port *port = &atmel_port->uart;
+	struct circ_buf *xmit = &port->state->xmit;
+	struct dma_chan *chan = atmel_port->chan_tx;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	if (chan)
+		dmaengine_terminate_all(chan);
+	xmit->tail += sg_dma_len(&atmel_port->sg_tx);
+	xmit->tail &= UART_XMIT_SIZE - 1;
+
+	port->icount.tx += sg_dma_len(&atmel_port->sg_tx);
+
+	spin_lock_irq(&atmel_port->lock_tx);
+	async_tx_ack(atmel_port->desc_tx);
+	atmel_port->cookie_tx = -EINVAL;
+	atmel_port->desc_tx = NULL;
+	spin_unlock_irq(&atmel_port->lock_tx);
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+
+	/* Do we really need this? */
+	if (!uart_circ_empty(xmit))
+		tasklet_schedule(&atmel_port->tasklet);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static void atmel_release_tx_dma(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct dma_chan *chan = atmel_port->chan_tx;
+
+	if (chan) {
+		dmaengine_terminate_all(chan);
+		dma_release_channel(chan);
+		dma_unmap_sg(port->dev, &atmel_port->sg_tx, 1,
+				DMA_MEM_TO_DEV);
+	}
+
+	atmel_port->desc_tx = NULL;
+	atmel_port->chan_tx = NULL;
+	atmel_port->cookie_tx = -EINVAL;
+}
+
+/*
+ * Called from tasklet with TXRDY interrupt is disabled.
+ */
+static void atmel_tx_dma(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct circ_buf *xmit = &port->state->xmit;
+	struct dma_chan *chan = atmel_port->chan_tx;
+	struct dma_async_tx_descriptor *desc;
+	struct scatterlist *sg = &atmel_port->sg_tx;
+
+	/* Make sure we have an idle channel */
+	if (atmel_port->desc_tx != NULL)
+		return;
+
+	if (!uart_circ_empty(xmit) && !uart_tx_stopped(port)) {
+		/*
+		 * DMA is idle now.
+		 * Port xmit buffer is already mapped,
+		 * and it is one page... Just adjust
+		 * offsets and lengths. Since it is a circular buffer,
+		 * we have to transmit till the end, and then the rest.
+		 * Take the port lock to get a
+		 * consistent xmit buffer state.
+		 */
+		sg->offset = xmit->tail & (UART_XMIT_SIZE - 1);
+		sg_dma_address(sg) = (sg_dma_address(sg) &
+					~(UART_XMIT_SIZE - 1))
+					+ sg->offset;
+		sg_dma_len(sg) = CIRC_CNT_TO_END(xmit->head,
+						xmit->tail,
+						UART_XMIT_SIZE);
+		BUG_ON(!sg_dma_len(sg));
+
+		desc = dmaengine_prep_slave_sg(chan,
+						sg,
+						1,
+						DMA_MEM_TO_DEV,
+						DMA_PREP_INTERRUPT |
+						DMA_CTRL_ACK);
+		if (!desc) {
+			dev_err(port->dev, "Failed to send via dma!\n");
+			return;
+		}
+
+		dma_sync_sg_for_device(port->dev, sg, 1, DMA_MEM_TO_DEV);
+
+		atmel_port->desc_tx = desc;
+		desc->callback = atmel_complete_tx_dma;
+		desc->callback_param = atmel_port;
+		atmel_port->cookie_tx = dmaengine_submit(desc);
+
+	} else {
+		if (atmel_port->rs485.flags & SER_RS485_ENABLED) {
+			/* DMA done, stop TX, start RX for RS485 */
+			atmel_start_rx(port);
+		}
+	}
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+}
+
+static int atmel_prepare_tx_dma(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	dma_cap_mask_t		mask;
+	struct dma_slave_config config;
+	int ret, nent;
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+
+	atmel_port->chan_tx = dma_request_slave_channel(port->dev, "tx");
+	if (atmel_port->chan_tx == NULL)
+		goto chan_err;
+	dev_info(port->dev, "using %s for tx DMA transfers\n",
+		dma_chan_name(atmel_port->chan_tx));
+
+	spin_lock_init(&atmel_port->lock_tx);
+	sg_init_table(&atmel_port->sg_tx, 1);
+	/* UART circular tx buffer is an aligned page. */
+	BUG_ON((int)port->state->xmit.buf & ~PAGE_MASK);
+	sg_set_page(&atmel_port->sg_tx,
+			virt_to_page(port->state->xmit.buf),
+			UART_XMIT_SIZE,
+			(int)port->state->xmit.buf & ~PAGE_MASK);
+	nent = dma_map_sg(port->dev,
+				&atmel_port->sg_tx,
+				1,
+				DMA_MEM_TO_DEV);
+
+	if (!nent) {
+		dev_dbg(port->dev, "need to release resource of dma\n");
+		goto chan_err;
+	} else {
+		dev_dbg(port->dev, "%s: mapped %d@%p to %x\n", __func__,
+			sg_dma_len(&atmel_port->sg_tx),
+			port->state->xmit.buf,
+			sg_dma_address(&atmel_port->sg_tx));
+	}
+
+	/* Configure the slave DMA */
+	memset(&config, 0, sizeof(config));
+	config.direction = DMA_MEM_TO_DEV;
+	config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	config.dst_addr = port->mapbase + ATMEL_US_THR;
+
+	ret = dmaengine_device_control(atmel_port->chan_tx,
+					DMA_SLAVE_CONFIG,
+					(unsigned long)&config);
+	if (ret) {
+		dev_err(port->dev, "DMA tx slave configuration failed\n");
+		goto chan_err;
+	}
+
+	return 0;
+
+chan_err:
+	dev_err(port->dev, "TX channel not available, switch to pio\n");
+	atmel_port->use_dma_tx = 0;
+	if (atmel_port->chan_tx)
+		atmel_release_tx_dma(port);
+	return -EINVAL;
+}
+
 /*
  * receive interrupt handler.
  */
@@ -998,7 +1187,11 @@ static void atmel_set_ops(struct uart_port *port)
 		atmel_port->release_rx = NULL;
 	}
 
-	if (atmel_use_pdc_tx(port)) {
+	if (atmel_use_dma_tx(port)) {
+		atmel_port->prepare_tx = &atmel_prepare_tx_dma;
+		atmel_port->schedule_tx = &atmel_tx_dma;
+		atmel_port->release_tx = &atmel_release_tx_dma;
+	} else if (atmel_use_pdc_tx(port)) {
 		atmel_port->prepare_tx = &atmel_prepare_tx_pdc;
 		atmel_port->schedule_tx = &atmel_tx_pdc;
 		atmel_port->release_tx = &atmel_release_tx_pdc;
@@ -1489,10 +1682,18 @@ static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
 	else
 		atmel_port->use_pdc_rx	= false;
 
-	if (of_get_property(np, "atmel,use-dma-tx", NULL))
-		atmel_port->use_pdc_tx	= true;
-	else
+	if (of_get_property(np, "atmel,use-dma-tx", NULL)) {
+		if (of_get_property(np, "dmas", NULL)) {
+			atmel_port->use_dma_tx	= true;
+			atmel_port->use_pdc_tx	= false;
+		} else {
+			atmel_port->use_dma_tx	= false;
+			atmel_port->use_pdc_tx	= true;
+		}
+	} else {
+		atmel_port->use_dma_tx	= false;
 		atmel_port->use_pdc_tx	= false;
+	}
 
 	/* rs485 properties */
 	if (of_property_read_u32_array(np, "rs485-rts-delay",
@@ -1525,6 +1726,7 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 	} else {
 		atmel_port->use_pdc_rx	= pdata->use_dma_rx;
 		atmel_port->use_pdc_tx	= pdata->use_dma_tx;
+		atmel_port->use_dma_tx	= false;
 		atmel_port->rs485	= pdata->rs485;
 	}
 
-- 
1.7.9.5



From elen.song at atmel.com  Mon Jul 22 04:30:27 2013
From: elen.song at atmel.com (Elen Song)
Date: Mon, 22 Jul 2013 16:30:27 +0800
Subject: [PATCH 4/8 V3] serial: at91: add rx dma support
In-Reply-To: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
References: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
Message-ID: <1374481831-24573-5-git-send-email-elen.song@atmel.com>

Request a cyclic dma channel for rx dma use. Use cyclic transfer is to prevent
receive data overrun.

We allocate a cycle dma cookie after request channel,
after that, enable uart timeout interrupt in startup stage, when data successful
received, the timeout callback will check the residual bytes and insert
receiving datas into the framework during the transfer interval.

When current descriptor finished, the dma callback will also check the residual
bytes and filp the receiving data.

Signed-off-by: Elen Song <elen.song at atmel.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |  224 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 220 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index b8d8594..0c15c5b 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -140,6 +140,7 @@ struct atmel_uart_port {
 	u32			backup_imr;	/* IMR saved during suspend */
 	int			break_active;	/* break being received */
 
+	bool			use_dma_rx;	/* enable DMA receiver */
 	bool			use_pdc_rx;	/* enable PDC receiver */
 	short			pdc_rx_idx;	/* current PDC RX buffer */
 	struct atmel_dma_buffer	pdc_rx[2];	/* PDC receier */
@@ -149,10 +150,15 @@ struct atmel_uart_port {
 	struct atmel_dma_buffer	pdc_tx;		/* PDC transmitter */
 
 	spinlock_t			lock_tx;	/* port lock */
+	spinlock_t			lock_rx;	/* port lock */
 	struct dma_chan			*chan_tx;
+	struct dma_chan			*chan_rx;
 	struct dma_async_tx_descriptor	*desc_tx;
+	struct dma_async_tx_descriptor	*desc_rx;
 	dma_cookie_t			cookie_tx;
+	dma_cookie_t			cookie_rx;
 	struct scatterlist		sg_tx;
+	struct scatterlist		sg_rx;
 	struct tasklet_struct	tasklet;
 	unsigned int		irq_status;
 	unsigned int		irq_status_prev;
@@ -225,6 +231,13 @@ static bool atmel_use_dma_tx(struct uart_port *port)
 	return atmel_port->use_dma_tx;
 }
 
+static bool atmel_use_dma_rx(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+	return atmel_port->use_dma_rx;
+}
+
 /* Enable or disable the rs485 support */
 void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
 {
@@ -759,6 +772,184 @@ chan_err:
 	return -EINVAL;
 }
 
+static void atmel_flip_buffer_rx_dma(struct uart_port *port,
+					char *buf, size_t count)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct tty_port *tport = &port->state->port;
+
+	dma_sync_sg_for_cpu(port->dev,
+				&atmel_port->sg_rx,
+				1,
+				DMA_DEV_TO_MEM);
+
+	tty_insert_flip_string(tport, buf, count);
+
+	dma_sync_sg_for_device(port->dev,
+				&atmel_port->sg_rx,
+				1,
+				DMA_DEV_TO_MEM);
+	/*
+	 * Drop the lock here since it might end up calling
+	 * uart_start(), which takes the lock.
+	 */
+	spin_unlock(&port->lock);
+	tty_flip_buffer_push(tport);
+	spin_lock(&port->lock);
+}
+
+static void atmel_complete_rx_dma(void *arg)
+{
+	struct uart_port *port = arg;
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+	tasklet_schedule(&atmel_port->tasklet);
+}
+
+static void atmel_release_rx_dma(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct dma_chan *chan = atmel_port->chan_rx;
+
+	if (chan) {
+		dmaengine_terminate_all(chan);
+		dma_release_channel(chan);
+		dma_unmap_sg(port->dev, &atmel_port->sg_rx, 1,
+				DMA_DEV_TO_MEM);
+	}
+
+	atmel_port->desc_rx = NULL;
+	atmel_port->chan_rx = NULL;
+	atmel_port->cookie_rx = -EINVAL;
+}
+
+static void atmel_rx_from_dma(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct circ_buf *ring = &atmel_port->rx_ring;
+	struct dma_chan *chan = atmel_port->chan_rx;
+	struct dma_tx_state state;
+	enum dma_status dmastat;
+	size_t pending, count;
+
+
+	/* Reset the UART timeout early so that we don't miss one */
+	UART_PUT_CR(port, ATMEL_US_STTTO);
+	dmastat = dmaengine_tx_status(chan,
+				atmel_port->cookie_rx,
+				&state);
+	/* Restart a new tasklet if DMA status is error */
+	if (dmastat == DMA_ERROR) {
+		dev_dbg(port->dev, "Get residue error, restart tasklet\n");
+		UART_PUT_IER(port, ATMEL_US_TIMEOUT);
+		tasklet_schedule(&atmel_port->tasklet);
+		return;
+	}
+	/* current transfer size should no larger than dma buffer */
+	pending = sg_dma_len(&atmel_port->sg_rx) - state.residue;
+	BUG_ON(pending > sg_dma_len(&atmel_port->sg_rx));
+
+	/*
+	 * This will take the chars we have so far,
+	 * ring->head will record the transfer size, only new bytes come
+	 * will insert into the framework.
+	 */
+	if (pending > ring->head) {
+		count = pending - ring->head;
+
+		atmel_flip_buffer_rx_dma(port, ring->buf + ring->head, count);
+
+		ring->head += count;
+		if (ring->head == sg_dma_len(&atmel_port->sg_rx))
+			ring->head = 0;
+
+		port->icount.rx += count;
+	}
+
+	UART_PUT_IER(port, ATMEL_US_TIMEOUT);
+}
+
+static int atmel_prepare_rx_dma(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct dma_async_tx_descriptor *desc;
+	dma_cap_mask_t		mask;
+	struct dma_slave_config config;
+	struct circ_buf		*ring;
+	int ret, nent;
+
+	ring = &atmel_port->rx_ring;
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_CYCLIC, mask);
+
+	atmel_port->chan_rx = dma_request_slave_channel(port->dev, "rx");
+	if (atmel_port->chan_rx == NULL)
+		goto chan_err;
+	dev_info(port->dev, "using %s for rx DMA transfers\n",
+		dma_chan_name(atmel_port->chan_rx));
+
+	spin_lock_init(&atmel_port->lock_rx);
+	sg_init_table(&atmel_port->sg_rx, 1);
+	/* UART circular rx buffer is an aligned page. */
+	BUG_ON((int)port->state->xmit.buf & ~PAGE_MASK);
+	sg_set_page(&atmel_port->sg_rx,
+			virt_to_page(ring->buf),
+			ATMEL_SERIAL_RINGSIZE,
+			(int)ring->buf & ~PAGE_MASK);
+			nent = dma_map_sg(port->dev,
+					&atmel_port->sg_rx,
+					1,
+					DMA_DEV_TO_MEM);
+
+	if (!nent) {
+		dev_dbg(port->dev, "need to release resource of dma\n");
+		goto chan_err;
+	} else {
+		dev_dbg(port->dev, "%s: mapped %d@%p to %x\n", __func__,
+			sg_dma_len(&atmel_port->sg_rx),
+			ring->buf,
+			sg_dma_address(&atmel_port->sg_rx));
+	}
+
+	/* Configure the slave DMA */
+	memset(&config, 0, sizeof(config));
+	config.direction = DMA_DEV_TO_MEM;
+	config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	config.src_addr = port->mapbase + ATMEL_US_RHR;
+
+	ret = dmaengine_device_control(atmel_port->chan_rx,
+					DMA_SLAVE_CONFIG,
+					(unsigned long)&config);
+	if (ret) {
+		dev_err(port->dev, "DMA rx slave configuration failed\n");
+		goto chan_err;
+	}
+	/*
+	 * Prepare a cyclic dma transfer, assign 2 descriptors,
+	 * each one is half ring buffer size
+	 */
+	desc = dmaengine_prep_dma_cyclic(atmel_port->chan_rx,
+				sg_dma_address(&atmel_port->sg_rx),
+				sg_dma_len(&atmel_port->sg_rx),
+				sg_dma_len(&atmel_port->sg_rx)/2,
+				DMA_DEV_TO_MEM,
+				DMA_PREP_INTERRUPT);
+	desc->callback = atmel_complete_rx_dma;
+	desc->callback_param = port;
+	atmel_port->desc_rx = desc;
+	atmel_port->cookie_rx = dmaengine_submit(desc);
+
+	return 0;
+
+chan_err:
+	dev_err(port->dev, "RX channel not available, switch to pio\n");
+	atmel_port->use_dma_rx = 0;
+	if (atmel_port->chan_rx)
+		atmel_release_rx_dma(port);
+	return -EINVAL;
+}
+
 /*
  * receive interrupt handler.
  */
@@ -786,6 +977,13 @@ atmel_handle_receive(struct uart_port *port, unsigned int pending)
 			atmel_pdc_rxerr(port, pending);
 	}
 
+	if (atmel_use_dma_rx(port)) {
+		if (pending & ATMEL_US_TIMEOUT) {
+			UART_PUT_IDR(port, ATMEL_US_TIMEOUT);
+			tasklet_schedule(&atmel_port->tasklet);
+		}
+	}
+
 	/* Interrupt receive */
 	if (pending & ATMEL_US_RXRDY)
 		atmel_rx_chars(port);
@@ -1177,7 +1375,11 @@ static void atmel_set_ops(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_pdc_rx(port)) {
+	if (atmel_use_dma_rx(port)) {
+		atmel_port->prepare_rx = &atmel_prepare_rx_dma;
+		atmel_port->schedule_rx = &atmel_rx_from_dma;
+		atmel_port->release_rx = &atmel_release_rx_dma;
+	} else if (atmel_use_pdc_rx(port)) {
 		atmel_port->prepare_rx = &atmel_prepare_rx_pdc;
 		atmel_port->schedule_rx = &atmel_rx_from_pdc;
 		atmel_port->release_rx = &atmel_release_rx_pdc;
@@ -1273,6 +1475,11 @@ static int atmel_startup(struct uart_port *port)
 		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
 		/* enable PDC controller */
 		UART_PUT_PTCR(port, ATMEL_PDC_RXTEN);
+	} else if (atmel_use_dma_rx(port)) {
+		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
+		UART_PUT_CR(port, ATMEL_US_STTTO);
+
+		UART_PUT_IER(port, ATMEL_US_TIMEOUT);
 	} else {
 		/* enable receive only */
 		UART_PUT_IER(port, ATMEL_US_RXRDY);
@@ -1677,10 +1884,18 @@ static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
 	u32 rs485_delay[2];
 
 	/* DMA/PDC usage specification */
-	if (of_get_property(np, "atmel,use-dma-rx", NULL))
-		atmel_port->use_pdc_rx	= true;
-	else
+	if (of_get_property(np, "atmel,use-dma-rx", NULL)) {
+		if (of_get_property(np, "dmas", NULL)) {
+			atmel_port->use_dma_rx	= true;
+			atmel_port->use_pdc_rx	= false;
+		} else {
+			atmel_port->use_dma_rx	= false;
+			atmel_port->use_pdc_rx	= true;
+		}
+	} else {
+		atmel_port->use_dma_rx	= false;
 		atmel_port->use_pdc_rx	= false;
+	}
 
 	if (of_get_property(np, "atmel,use-dma-tx", NULL)) {
 		if (of_get_property(np, "dmas", NULL)) {
@@ -1726,6 +1941,7 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 	} else {
 		atmel_port->use_pdc_rx	= pdata->use_dma_rx;
 		atmel_port->use_pdc_tx	= pdata->use_dma_tx;
+		atmel_port->use_dma_rx	= false;
 		atmel_port->use_dma_tx	= false;
 		atmel_port->rs485	= pdata->rs485;
 	}
-- 
1.7.9.5



From elen.song at atmel.com  Mon Jul 22 04:30:28 2013
From: elen.song at atmel.com (Elen Song)
Date: Mon, 22 Jul 2013 16:30:28 +0800
Subject: [PATCH 5/8 V3] serial: at91: support run time switch transfer mode
In-Reply-To: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
References: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
Message-ID: <1374481831-24573-6-git-send-email-elen.song@atmel.com>

We will switch to pio mode when request of dma or pdc fail.
But soon or later, when the request is success, the transfer mode can switch to them at
next open serial port action.
So in startup stage, we should get original transfer mode.

Signed-off-by: Elen Song <elen.song at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |  139 +++++++++++++++++++++----------------
 1 file changed, 80 insertions(+), 59 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 0c15c5b..7bd8607 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1371,6 +1371,80 @@ static void atmel_tasklet_func(unsigned long data)
 	spin_unlock(&port->lock);
 }
 
+static int atmel_init_property(struct atmel_uart_port *atmel_port,
+				struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct atmel_uart_data *pdata = pdev->dev.platform_data;
+
+	if (np) {
+		/* DMA/PDC usage specification */
+		if (of_get_property(np, "atmel,use-dma-rx", NULL)) {
+			if (of_get_property(np, "dmas", NULL)) {
+				atmel_port->use_dma_rx  = true;
+				atmel_port->use_pdc_rx  = false;
+			} else {
+				atmel_port->use_dma_rx  = false;
+				atmel_port->use_pdc_rx  = true;
+			}
+		} else {
+			atmel_port->use_dma_rx  = false;
+			atmel_port->use_pdc_rx  = false;
+		}
+
+		if (of_get_property(np, "atmel,use-dma-tx", NULL)) {
+			if (of_get_property(np, "dmas", NULL)) {
+				atmel_port->use_dma_tx  = true;
+				atmel_port->use_pdc_tx  = false;
+			} else {
+				atmel_port->use_dma_tx  = false;
+				atmel_port->use_pdc_tx  = true;
+			}
+		} else {
+			atmel_port->use_dma_tx  = false;
+			atmel_port->use_pdc_tx  = false;
+		}
+
+	} else {
+		atmel_port->use_pdc_rx  = pdata->use_dma_rx;
+		atmel_port->use_pdc_tx  = pdata->use_dma_tx;
+		atmel_port->use_dma_rx  = false;
+		atmel_port->use_dma_tx  = false;
+	}
+
+	return 0;
+}
+
+static void atmel_init_rs485(struct atmel_uart_port *atmel_port,
+				struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct atmel_uart_data *pdata = pdev->dev.platform_data;
+
+	if (np) {
+		u32 rs485_delay[2];
+		/* rs485 properties */
+		if (of_property_read_u32_array(np, "rs485-rts-delay",
+					rs485_delay, 2) == 0) {
+			struct serial_rs485 *rs485conf = &atmel_port->rs485;
+
+			rs485conf->delay_rts_before_send = rs485_delay[0];
+			rs485conf->delay_rts_after_send = rs485_delay[1];
+			rs485conf->flags = 0;
+
+		if (of_get_property(np, "rs485-rx-during-tx", NULL))
+			rs485conf->flags |= SER_RS485_RX_DURING_TX;
+
+		if (of_get_property(np, "linux,rs485-enabled-at-boot-time",
+								NULL))
+			rs485conf->flags |= SER_RS485_ENABLED;
+		}
+	} else {
+		atmel_port->rs485       = pdata->rs485;
+	}
+
+}
+
 static void atmel_set_ops(struct uart_port *port)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
@@ -1409,6 +1483,7 @@ static void atmel_set_ops(struct uart_port *port)
  */
 static int atmel_startup(struct uart_port *port)
 {
+	struct platform_device *pdev = to_platform_device(port->dev);
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 	struct tty_struct *tty = port->state->port.tty;
 	int retval;
@@ -1433,6 +1508,8 @@ static int atmel_startup(struct uart_port *port)
 	/*
 	 * Initialize DMA (if necessary)
 	 */
+	atmel_init_property(atmel_port, pdev);
+
 	if (atmel_port->prepare_rx) {
 		retval = atmel_port->prepare_rx(port);
 		if (retval < 0)
@@ -1878,55 +1955,6 @@ static struct uart_ops atmel_pops = {
 #endif
 };
 
-static void atmel_of_init_port(struct atmel_uart_port *atmel_port,
-					 struct device_node *np)
-{
-	u32 rs485_delay[2];
-
-	/* DMA/PDC usage specification */
-	if (of_get_property(np, "atmel,use-dma-rx", NULL)) {
-		if (of_get_property(np, "dmas", NULL)) {
-			atmel_port->use_dma_rx	= true;
-			atmel_port->use_pdc_rx	= false;
-		} else {
-			atmel_port->use_dma_rx	= false;
-			atmel_port->use_pdc_rx	= true;
-		}
-	} else {
-		atmel_port->use_dma_rx	= false;
-		atmel_port->use_pdc_rx	= false;
-	}
-
-	if (of_get_property(np, "atmel,use-dma-tx", NULL)) {
-		if (of_get_property(np, "dmas", NULL)) {
-			atmel_port->use_dma_tx	= true;
-			atmel_port->use_pdc_tx	= false;
-		} else {
-			atmel_port->use_dma_tx	= false;
-			atmel_port->use_pdc_tx	= true;
-		}
-	} else {
-		atmel_port->use_dma_tx	= false;
-		atmel_port->use_pdc_tx	= false;
-	}
-
-	/* rs485 properties */
-	if (of_property_read_u32_array(np, "rs485-rts-delay",
-					    rs485_delay, 2) == 0) {
-		struct serial_rs485 *rs485conf = &atmel_port->rs485;
-
-		rs485conf->delay_rts_before_send = rs485_delay[0];
-		rs485conf->delay_rts_after_send = rs485_delay[1];
-		rs485conf->flags = 0;
-
-		if (of_get_property(np, "rs485-rx-during-tx", NULL))
-			rs485conf->flags |= SER_RS485_RX_DURING_TX;
-
-		if (of_get_property(np, "linux,rs485-enabled-at-boot-time", NULL))
-			rs485conf->flags |= SER_RS485_ENABLED;
-	}
-}
-
 /*
  * Configure the port from the platform device resource info.
  */
@@ -1936,17 +1964,10 @@ static void atmel_init_port(struct atmel_uart_port *atmel_port,
 	struct uart_port *port = &atmel_port->uart;
 	struct atmel_uart_data *pdata = pdev->dev.platform_data;
 
-	if (pdev->dev.of_node) {
-		atmel_of_init_port(atmel_port, pdev->dev.of_node);
-	} else {
-		atmel_port->use_pdc_rx	= pdata->use_dma_rx;
-		atmel_port->use_pdc_tx	= pdata->use_dma_tx;
-		atmel_port->use_dma_rx	= false;
-		atmel_port->use_dma_tx	= false;
-		atmel_port->rs485	= pdata->rs485;
-	}
+	if (!atmel_init_property(atmel_port, pdev))
+		atmel_set_ops(port);
 
-	atmel_set_ops(port);
+	atmel_init_rs485(atmel_port, pdev);
 
 	port->iotype		= UPIO_MEM;
 	port->flags		= UPF_BOOT_AUTOCONF;
-- 
1.7.9.5



From shawn.guo at linaro.org  Mon Jul 22 04:39:05 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Jul 2013 16:39:05 +0800
Subject: [PATCH 1/6] ARM: dts: i.MX27: Using "wdog_ipg_gate" clock source
 for watchdog
In-Reply-To: <1374304679-27338-1-git-send-email-shc_work@mail.ru>
References: <1374304679-27338-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130722083903.GH20271@S2101-09.ap.freescale.net>

On Sat, Jul 20, 2013 at 11:17:54AM +0400, Alexander Shiyan wrote:
> Patch replaces "dummy" clock source for watchdog with "wdog_ipg_gate".
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>

Applied all 6, thanks.



From elen.song at atmel.com  Mon Jul 22 04:30:29 2013
From: elen.song at atmel.com (Elen Song)
Date: Mon, 22 Jul 2013 16:30:29 +0800
Subject: [PATCH 6/8 V3] serial: at91: distinguish usart and uart
In-Reply-To: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
References: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
Message-ID: <1374481831-24573-7-git-send-email-elen.song@atmel.com>

Distinguish usart and uart by read ip name register,
The usart read name is "USAR",
The uart and dbgu read name is "DBGU".

Signed-off-by: Elen Song <elen.song at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |   37 +++++++++++++++++++++++++++++++++++++
 include/linux/atmel_serial.h      |    2 ++
 2 files changed, 39 insertions(+)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 7bd8607..c9c42fd 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -98,6 +98,7 @@ static void atmel_stop_rx(struct uart_port *port);
 #define UART_PUT_BRGR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_BRGR)
 #define UART_PUT_RTOR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_RTOR)
 #define UART_PUT_TTGR(port, v)	__raw_writel(v, (port)->membase + ATMEL_US_TTGR)
+#define UART_GET_IP_NAME(port)	__raw_readl((port)->membase + ATMEL_US_NAME)
 
  /* PDC registers */
 #define UART_PUT_PTCR(port,v)	__raw_writel(v, (port)->membase + ATMEL_PDC_PTCR)
@@ -167,6 +168,7 @@ struct atmel_uart_port {
 
 	struct serial_rs485	rs485;		/* rs485 settings */
 	unsigned int		tx_done_mask;
+	bool			is_usart;	/* usart or uart */
 	int (*prepare_rx)(struct uart_port *port);
 	int (*prepare_tx)(struct uart_port *port);
 	void (*schedule_rx)(struct uart_port *port);
@@ -1479,6 +1481,34 @@ static void atmel_set_ops(struct uart_port *port)
 }
 
 /*
+ * Get ip name usart or uart
+ */
+static int atmel_get_ip_name(struct uart_port *port)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	int name = UART_GET_IP_NAME(port);
+	int usart, uart;
+	/* usart and uart ascii */
+	usart = 0x55534152;
+	uart = 0x44424755;
+
+	atmel_port->is_usart = false;
+
+	if (name == usart) {
+		dev_dbg(port->dev, "This is usart\n");
+		atmel_port->is_usart = true;
+	} else if (name == uart) {
+		dev_dbg(port->dev, "This is uart\n");
+		atmel_port->is_usart = false;
+	} else {
+		dev_err(port->dev, "Not supported ip name, set to uart\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/*
  * Perform initialization and enable port for reception
  */
 static int atmel_startup(struct uart_port *port)
@@ -2323,6 +2353,13 @@ static int atmel_serial_probe(struct platform_device *pdev)
 		UART_PUT_CR(&port->uart, ATMEL_US_RTSEN);
 	}
 
+	/*
+	 * Get port name of usart or uart
+	 */
+	ret = atmel_get_ip_name(&port->uart);
+	if (ret < 0)
+		goto err_add_port;
+
 	return 0;
 
 err_add_port:
diff --git a/include/linux/atmel_serial.h b/include/linux/atmel_serial.h
index fd68337..be201ca 100644
--- a/include/linux/atmel_serial.h
+++ b/include/linux/atmel_serial.h
@@ -124,4 +124,6 @@
 #define ATMEL_US_NER		0x44			/* Number of Errors Register */
 #define ATMEL_US_IF		0x4c			/* IrDA Filter Register */
 
+#define ATMEL_US_NAME		0xf0			/* Ip Name */
+
 #endif
-- 
1.7.9.5



From elen.song at atmel.com  Mon Jul 22 04:30:30 2013
From: elen.song at atmel.com (Elen Song)
Date: Mon, 22 Jul 2013 16:30:30 +0800
Subject: [PATCH 7/8 V3] serial: at91: make UART support dma and pdc transfers
In-Reply-To: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
References: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
Message-ID: <1374481831-24573-8-git-send-email-elen.song@atmel.com>

Because the UART lack of receive timeout register, so we use a timer to trigger
data receive.
The DBGU is regarded as UART.

Signed-off-by: Elen Song <elen.song at atmel.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/tty/serial/atmel_serial.c |   48 ++++++++++++++++++++++++++++++++-----
 1 file changed, 42 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index c9c42fd..6ade3f6 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -41,6 +41,7 @@
 #include <linux/uaccess.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/platform_data/atmel.h>
+#include <linux/timer.h>
 
 #include <asm/io.h>
 #include <asm/ioctls.h>
@@ -169,6 +170,7 @@ struct atmel_uart_port {
 	struct serial_rs485	rs485;		/* rs485 settings */
 	unsigned int		tx_done_mask;
 	bool			is_usart;	/* usart or uart */
+	struct timer_list	uart_timer;	/* uart timer */
 	int (*prepare_rx)(struct uart_port *port);
 	int (*prepare_tx)(struct uart_port *port);
 	void (*schedule_rx)(struct uart_port *port);
@@ -823,6 +825,9 @@ static void atmel_release_rx_dma(struct uart_port *port)
 	atmel_port->desc_rx = NULL;
 	atmel_port->chan_rx = NULL;
 	atmel_port->cookie_rx = -EINVAL;
+
+	if (!atmel_port->is_usart)
+		del_timer_sync(&atmel_port->uart_timer);
 }
 
 static void atmel_rx_from_dma(struct uart_port *port)
@@ -952,6 +957,15 @@ chan_err:
 	return -EINVAL;
 }
 
+static void atmel_uart_timer_callback(unsigned long data)
+{
+	struct uart_port *port = (void *)data;
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+	tasklet_schedule(&atmel_port->tasklet);
+	mod_timer(&atmel_port->uart_timer, jiffies + uart_poll_timeout(port));
+}
+
 /*
  * receive interrupt handler.
  */
@@ -1215,6 +1229,9 @@ static void atmel_release_rx_pdc(struct uart_port *port)
 				 DMA_FROM_DEVICE);
 		kfree(pdc->buf);
 	}
+
+	if (!atmel_port->is_usart)
+		del_timer_sync(&atmel_port->uart_timer);
 }
 
 static void atmel_rx_from_pdc(struct uart_port *port)
@@ -1576,17 +1593,36 @@ static int atmel_startup(struct uart_port *port)
 
 	if (atmel_use_pdc_rx(port)) {
 		/* set UART timeout */
-		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
-		UART_PUT_CR(port, ATMEL_US_STTTO);
+		if (!atmel_port->is_usart) {
+			setup_timer(&atmel_port->uart_timer,
+					atmel_uart_timer_callback,
+					(unsigned long)port);
+			mod_timer(&atmel_port->uart_timer,
+					jiffies + uart_poll_timeout(port));
+		/* set USART timeout */
+		} else {
+			UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
+			UART_PUT_CR(port, ATMEL_US_STTTO);
 
-		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
+			UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
+		}
 		/* enable PDC controller */
 		UART_PUT_PTCR(port, ATMEL_PDC_RXTEN);
 	} else if (atmel_use_dma_rx(port)) {
-		UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
-		UART_PUT_CR(port, ATMEL_US_STTTO);
+		/* set UART timeout */
+		if (!atmel_port->is_usart) {
+			setup_timer(&atmel_port->uart_timer,
+					atmel_uart_timer_callback,
+					(unsigned long)port);
+			mod_timer(&atmel_port->uart_timer,
+					jiffies + uart_poll_timeout(port));
+		/* set USART timeout */
+		} else {
+			UART_PUT_RTOR(port, PDC_RX_TIMEOUT);
+			UART_PUT_CR(port, ATMEL_US_STTTO);
 
-		UART_PUT_IER(port, ATMEL_US_TIMEOUT);
+			UART_PUT_IER(port, ATMEL_US_TIMEOUT);
+		}
 	} else {
 		/* enable receive only */
 		UART_PUT_IER(port, ATMEL_US_RXRDY);
-- 
1.7.9.5



From elen.song at atmel.com  Mon Jul 22 04:30:31 2013
From: elen.song at atmel.com (Elen Song)
Date: Mon, 22 Jul 2013 16:30:31 +0800
Subject: [PATCH 8/8 V3] serial: at91: add dma support in usart binding
 descriptions
In-Reply-To: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
References: <1374481831-24573-1-git-send-email-elen.song@atmel.com>
Message-ID: <1374481831-24573-9-git-send-email-elen.song@atmel.com>

Signed-off-by: Elen Song <elen.song at atmel.com>
---
 .../devicetree/bindings/tty/serial/atmel-usart.txt |   18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
index a49d9a1..2191dcb 100644
--- a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
@@ -10,13 +10,18 @@ Required properties:
 Optional properties:
 - atmel,use-dma-rx: use of PDC or DMA for receiving data
 - atmel,use-dma-tx: use of PDC or DMA for transmitting data
+- add dma bindings for dma transfer:
+	- dmas: DMA specifier, consisting of a phandle to DMA controller node,
+		memory peripheral interface and USART DMA channel ID, FIFO configuration.
+		Refer to dma.txt and atmel-dma.txt for details.
+	- dma-names: "rx" for RX channel, "tx" for TX channel.
 
 <chip> compatible description:
 - at91rm9200:  legacy USART support
 - at91sam9260: generic USART implementation for SAM9 SoCs
 
 Example:
-
+- use PDC:
 	usart0: serial at fff8c000 {
 		compatible = "atmel,at91sam9260-usart";
 		reg = <0xfff8c000 0x4000>;
@@ -25,3 +30,14 @@ Example:
 		atmel,use-dma-tx;
 	};
 
+- use DMA:
+	usart0: serial at f001c000 {
+		compatible = "atmel,at91sam9260-usart";
+		reg = <0xf001c000 0x100>;
+		interrupts = <12 4 5>;
+		atmel,use-dma-rx;
+		atmel,use-dma-tx;
+		dmas = <&dma0 2 0x3>,
+		       <&dma0 2 0x204>;
+		dma-names = "tx", "rx";
+	};
-- 
1.7.9.5



From mark.rutland at arm.com  Mon Jul 22 04:48:17 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Jul 2013 09:48:17 +0100
Subject: [PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
In-Reply-To: <1374475767-30085-3-git-send-email-chanho61.park@samsung.com>
References: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
 <1374475767-30085-3-git-send-email-chanho61.park@samsung.com>
Message-ID: <20130722084817.GA18731@e106331-lin.cambridge.arm.com>

On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> This patch adds a dt-binding document for exynos rotator. It describes which
> nodes should be defined to use the rotator.
> 
> Signed-off-by: Chanho Park <chanho61.park at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> ---
>  .../bindings/drm/exynos/samsung-rotator.txt        |   35 ++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> 
> diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> new file mode 100644
> index 0000000..6b1d704
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> @@ -0,0 +1,35 @@
> +* Samsung Image Rotator
> +
> +Required properties:
> +  - compatible : value should be the "samsung,exynos4210".
> +  - reg : Physical base address of the IP registers and length of memory
> +	  mapped region.
> +  - interrupts : interrupt number to the CPU.
> +  - clocks : clock number of exynos4 rotator clock.
> +  - clocks : clock name of rotator

clock-names?

> +  - status : "okay" or "disabled"
> +  - limit table for image formats : min_w/min_h/max_w/max_h for min/max of image

Limit table? This doesn't seem to be a well-defined binding, and it
seems like a relatively generic thing to describe.

> +
> +Example:
> +	rotator: rotator at 12810000 {
> +		compatible = "samsung,exynos4210-rotator";
> +		reg = <0x12810000 0x1000>;
> +		interrupts = <0 83 0>;
> +		clocks = <&clock 278>;
> +		clock-names = "rotator";
> +		status = "disabled";
> +		ycbcr420_2p {

Which names are allowed for these subnodes?

> +			min_w = <32>;
> +			min_h = <32>;
> +			max_w = <32768>;
> +			max_h = <32768>;
> +			align = <3>;

min-width, min-height, max-width, max-height? What units are they in?

What does alignment specify exactly?

Are these a configurable part of the rotator hardware, or are these
values always the same? If thery're always the same, there's no need to
describe in in the devicetree.

Thanks,
Mark.

> +		};
> +		rgb888 {
> +			min_w = <8>;
> +			min_h = <8>;
> +			max_w = <8192>;
> +			max_h = <8192>;
> +			align = <2>;
> +		};
> +	};
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From raghavendra.kt.linux at gmail.com  Mon Jul 22 04:53:50 2013
From: raghavendra.kt.linux at gmail.com (Raghavendra KT)
Date: Mon, 22 Jul 2013 14:23:50 +0530
Subject: [PATCH 3/4] arm64: KVM: let other tasks run when hitting WFE
In-Reply-To: <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
Message-ID: <CAC4Lta17bmNjBck6LzziBeU0Xc36F1Jms2tQPv6+GaXvik6Wyg@mail.gmail.com>

On Fri, Jul 19, 2013 at 7:23 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> So far, when a guest executes WFE (like when waiting for a spinlock
> to become unlocked), we don't do a thing and let it run uninterrupted.
>
> Another option is to trap a blocking WFE and offer the opportunity
> to the scheduler to switch to another task, potentially giving the
> vcpu holding the spinlock a chance to run sooner.
>

Idea looks to be correct from my experiments on x86. It does bring some
percentage of benefits in overcommitted guests. Infact,

https://lkml.org/lkml/2013/7/22/41 tries to do the same thing for x86.
(this results in using ple handler heuristics in vcpu_block pach).


From 21cnbao at gmail.com  Mon Jul 22 05:07:50 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Mon, 22 Jul 2013 17:07:50 +0800
Subject: [PATCH 2/6] ASoC: sirf: add I2S CPU DAI driver
In-Reply-To: <20130719165246.GL9858@sirena.org.uk>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
 <1374232042-26088-3-git-send-email-Baohua.Song@csr.com>
 <20130719165246.GL9858@sirena.org.uk>
Message-ID: <CAGsJ_4zO9k_66GST+Xyc+jaPZ5iBsT4Awo-Lgojf8=ZA_MgbLw@mail.gmail.com>

2013/7/20 Mark Brown <broonie at kernel.org>:
> On Fri, Jul 19, 2013 at 07:07:18PM +0800, Barry Song wrote:
>
> Pretty good overall - there's a few things below but should all be
> fairly small.
>
>> +static int sirf_i2s_startup(struct snd_pcm_substream *substream,
>> +             struct snd_soc_dai *dai)
>> +{
>> +
>> +     struct sirf_i2s *si2s = snd_soc_dai_get_drvdata(dai);
>> +
>> +     if (si2s->master_mode)
>> +             pwm_enable(si2s->mclk_pwm);
>> +     clk_prepare_enable(si2s->clk);
>> +
>> +     device_reset(dai->dev);
>> +     snd_soc_dai_set_dma_data(dai, substream,
>> +             &sirf_i2s_dai_dma_data[substream->stream]);
>> +     return 0;
>> +}
>
> device_reset() sounds like it's not going to work for simultaneous
> playback and capture.

right. i'll have rongjun to check whether this reset is necessary or
it can be moved to other place.
as here playback can break capture if we start a playback when we are
capturing here.

>
>> +static int sirf_i2s_trigger(struct snd_pcm_substream *substream,
>> +             int cmd, struct snd_soc_dai *dai)
>> +{
>> +     struct sirf_i2s *si2s = snd_soc_dai_get_drvdata(dai);
>> +     int playback = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK);
>> +
>> +     switch (cmd) {
>> +     case SNDRV_PCM_TRIGGER_START:
>> +     case SNDRV_PCM_TRIGGER_RESUME:
>> +     case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
>> +             spin_lock(&si2s->lock);
>> +
>> +             if (playback) {
>> +                     /* First start the FIFO, then enable the tx/rx */
>> +                     writel(AUDIO_FIFO_RESET,
>> +                             si2s->base + AUDIO_CTRL_EXT_TXFIFO1_OP);
>> +                     mdelay(1);
>> +                     writel(AUDIO_FIFO_START,
>> +                             si2s->base + AUDIO_CTRL_EXT_TXFIFO1_OP);
>> +                     mdelay(1);
>
> Do we really need these 1ms delays?  They're very long for the
> context...

the hardware does need a delay to be stable as said by hardware guys

>
>> +static int sirf_i2s_prepare(struct snd_pcm_substream *substream,
>> +                     struct snd_soc_dai *dai)
>> +{
>> +     struct snd_pcm_runtime *runtime = substream->runtime;
>> +     struct sirf_i2s *si2s = snd_soc_dai_get_drvdata(dai);
>> +     u32 ctrl = readl(si2s->base + AUDIO_CTRL_I2S_CTRL);
>> +
>> +     if (runtime->channels == 2)
>> +             ctrl &= ~I2S_SIX_CHANNELS;
>> +     else
>> +             ctrl |= I2S_SIX_CHANNELS;
>
> A switch statement for the number of channels would make me happier
> here.

here there is some hardware set to explain.

>
>> +     switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
>> +     case SND_SOC_DAIFMT_CBM_CFM:
>> +             ctrl = readl(si2s->base + AUDIO_CTRL_I2S_CTRL);
>> +             ctrl |= I2S_SLAVE_MODE;
>> +             writel(ctrl, si2s->base + AUDIO_CTRL_I2S_CTRL);
>> +             si2s->master_mode = 0;
>> +             break;
>
> Do we need locking on all these register updates?

yes if considering here it is happening read-modify-write.

>
>> +     case SND_SOC_DAIFMT_CBS_CFS:
>> +             si2s->master_mode = 1;
>> +             return -EINVAL;
>
> Should this be undoing the work done for _CBM_CFM?

it seems it need to rollback some registers. i'll have rongjun to check that.

>
>> +#ifdef CONFIG_PM
>> +static int sirf_i2s_suspend(struct platform_device *pdev,
>> +             pm_message_t state)
>> +{
>> +     struct sirf_i2s *si2s = platform_get_drvdata(pdev);
>> +
>> +     si2s->i2s_ctrl = readl(si2s->base+AUDIO_CTRL_I2S_CTRL);
>> +
>> +     clk_disable_unprepare(si2s->clk);
>> +
>> +     if (si2s->master_mode)
>> +             pwm_disable(si2s->mclk_pwm);
>> +     return 0;
>> +}
>
> Should these be runtime PM calls as well?  Seems like the bus could be
> unclocked whenever audio is not playing.  If you need the clock to write
> conifguraiton perhaps regmap-mmio could help?

i will make the runtime PM happen for this and other drivers on sirf platform.

>
>> +     spin_lock_init(&si2s->lock);
>
> What is this lock actually protecting?

sirf_i2s_trigger().

-barry


From oleksandr.kozaruk at ti.com  Mon Jul 22 05:12:07 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Mon, 22 Jul 2013 12:12:07 +0300
Subject: [PATCH v6 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <51EA69DE.4080908@kernel.org>
References: <1374226039-16943-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1374226039-16943-3-git-send-email-oleksandr.kozaruk@ti.com>
 <51EA69DE.4080908@kernel.org>
Message-ID: <CAPb7_mskrx9uKtYFi2sJiZu-r0Jb_JEm19e05ZmmjWTJ7Qnc+g@mail.gmail.com>

Hi Jonathan,

On Sat, Jul 20, 2013 at 1:43 PM, Jonathan Cameron <jic23 at kernel.org> wrote:
> On 07/19/2013 10:27 AM, Oleksandr Kozaruk wrote:
>> The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
>> known also as Phoenix and PhoenixLite.
>>
>> The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
>> respectively. Some channels have current source and are used for
>> measuring voltage drop on resistive load for detecting battery ID
>> resistance, or measuring voltage drop on NTC resistors for external
>> temperature measurements. Some channels measure voltage, (i.e. battery
>> voltage), and have voltage dividers, thus, capable to scale voltage.
>> Some channels are dedicated for measuring die temperature.
>>
>> Some channels are calibrated in 2 points, having offsets from ideal
>> values kept in trim registers. This is used to correct measurements.
>>
>> The differences between GPADC in TWL6030 and TWL6032:
>> - 10 bit vs 12 bit ADC;
>> - 17 vs 19 channels;
>> - channels have different purpose(i.e. battery voltage
>>   channel 8 vs channel 18);
>> - trim values are interpreted differently.
>>
>> Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
>> Girish S Ghongdemath.
>>
>> Signed-off-by: Balaji T K <balajitk at ti.com>
>> Signed-off-by: Graeme Gregory <gg at slimlogic.co.uk>
>> Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
> A few little bits and bobs inline.
>
> My only major query is about the lack of info for the temperature
> channels.  How do you convert these to useful real world units?

If I get your question right: the ADC channels 1, 4 are dedicated for
measuring resistive value.
The temperature measurement will depend on:
1) the ADC code(provided by the driver);
2) value of the NTC resistor, its characteristics, the way it is
plugged in the circuit,
and may be some calibration data(platform dependent); How the driver can the
drive take care of these?
[...]

>> +static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
>> +                          const struct iio_chan_spec *chan,
>> +                          int *val, int *val2, long mask)
>> +{
>> +     struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
>> +     int ret = -EINVAL;
> I'm suprised you didn't get a warning about the assigment above
> being pointless as you overwrite ret just below.
Indeed, ret is overwritten, though, there is no warning from make C=2
and checkpatch is silent.
I'll remove the initialization.
[...]

>> +
>> +#define TWL6030_GPADC_CHAN(chn, _type, chan_info) {  \
>> +     .type = _type,                                  \
>> +     .channel = chn,                                 \
>> +     .info_mask_separate = BIT(chan_info),           \
>> +     .indexed = 1,                                   \
>> +}
>> +
>
>
> Why list these at all?  I see they are no longer visible from
> userspace, but they are still taking up memory etc without I
> think ever being used?
I've kept it because for twl6032 there is a gap if I drop channels 15, 16,
as channels 17, 18 are used.

>> +/* internal test network channel */
>> +#define TWL6030_GPADC_TEST_CHAN(chn, chan_info) {    \
>> +     .type = IIO_VOLTAGE,                            \
>> +     .channel = chn,                                 \
>> +     .indexed = 1,                                   \
>> +}
>> +
>> +static const struct iio_chan_spec twl6030_gpadc_iio_channels[] = {
>> +     TWL6030_GPADC_CHAN(0, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
>> +     TWL6030_GPADC_CHAN(1, IIO_TEMP, IIO_CHAN_INFO_RAW),
> So we have no other information about the temp channels other than
> raw adc counts?  If so, how are these useful?  I guess you might
> be intending to use iio-hwmon to get these into hwmon the use
> lm-sensors config files to convert to something useful.
> Otherwise, you probably want to get the board specific info on
> the calibration of these in here to make the data available to userspace
> in a useful format...

Hmm, it seems that info on the NTC type is board specific. And we
should get it from device tree?
I thought the driver just gives the ADC code, and consumer will know
what to do with the ADC data.
So, calculation for converting to temperature should be done in this driver?
I don't know how yet.
[...]

>> +MODULE_AUTHOR("Texas Instruments Inc.");
>
> I would normally expect an actual person for
> the module author.  Is this TI policy or simply a case of no clear single
> author?  Note I believe there is no problem with having multiple
> MODULE_AUTHOR lines so that everyone who made a major contribution is
> included.

Yes, this is because of having multiple authors. I will change it for
Balaji, Graeme and myself.

Regards,
OK.


From manjunath.goudar at linaro.org  Mon Jul 22 05:19:24 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 14:49:24 +0530
Subject: [PATCH 0/6] USB: OHCI: more bus glues as separate modules
In-Reply-To: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>

These patches are for separating the SOC On-Chip ohci host controller
from ohci-hcd host code into its own driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.12.

V2:
  In patch 5/6 and 6/6:
  -Set non-standard fields in hc_driver manually, rather than
   relying on an expanded struct ohci_driver_overrides.
  -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
   relying on ohci_hub_control and hub_status_data being exported.

  In patch 1/6 to 4/6
  -ohci_setup() has been removed because it is called in .reset member
   of the ohci_hc_driver structure.

V3:
 In patch 5/6 and 6/6:
 -ohci_setup() has been removed because it is called in .reset member
  of the ohci_hc_driver structure.

 In patch 5/6:
 -The ohci_restart() function is not required in  current scenario,
  only discarding connection state of integrated transceivers is sufficient,
  for this directly handling ohci->hc_control.

 In patch 2/6 :
 -rewritten if (config->otg || config->rwc) block statements into
  two separate 'if blocks' to handle below scenarios
  1. config->otg set scenario.
  2. if any of these (config->otg, config->rwc) are set, this
     scenario should be handled only after ohci_setup()

 In patch 1/6 and 4/6:
  No change.

V4:
 In patch 1/6 and 4/6:
  No change.
 
 In patch 2/6 :
 -usb_remove_hcd() function is required a valid clock that is what
  omap_ohci_clock_power(0) is called after hcd shutdown.

 In patch 3/6 :
 -V3 modification revert back, only ohci->regs setting write()
  function has been removed because ohci->regs doesn't get set until
  usb_add_hcd.

 In patch 5/6 :
 - Removed extra space after "tristate".
 - Removed extra space between function name  and '(' characters.
 - MODULE_ALIAS line moved to last statement of ohci-at91 file.

 In patch 6/6 :
 - Removed extra space before the '='.
 - Moved  /* forward definitions */ line before the declarations of functions.

Manjunath Goudar (6):
  USB: OHCI: make ohci-exynos a separate driver
  USB: OHCI: make ohci-omap a separate driver
  USB: OHCI: make ohci-omap3 a separate driver
  USB: OHCI: make ohci-spear a separate driver
  USB: OHCI: make ohci-at91 a separate driver
  USB: OHCI: make ohci-s3c2410 a separate driver

 drivers/usb/host/Kconfig        |   30 ++++++-
 drivers/usb/host/Makefile       |    6 ++
 drivers/usb/host/ohci-at91.c    |  153 ++++++++++++++++-------------------
 drivers/usb/host/ohci-exynos.c  |  167 ++++++++++++++++-----------------------
 drivers/usb/host/ohci-hcd.c     |  108 -------------------------
 drivers/usb/host/ohci-omap.c    |  156 +++++++++++++-----------------------
 drivers/usb/host/ohci-omap3.c   |  118 +++++++++------------------
 drivers/usb/host/ohci-s3c2410.c |  128 +++++++++++++-----------------
 drivers/usb/host/ohci-spear.c   |  140 +++++++++++++-------------------
 9 files changed, 374 insertions(+), 632 deletions(-)

-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:19:25 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 14:49:25 +0530
Subject: [PATCH 1/6] USB: OHCI: make ohci-exynos a separate driver
In-Reply-To: <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
 <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374484770-24531-2-git-send-email-manjunath.goudar@linaro.org>

Separate the  Samsung OHCI EXYNOS host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Acked-by: Jingoo Han <jg1.han at samsung.com>
Cc: Vivek Gautam <gautam.vivek at samsung.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -exynos_ohci_hcd structure assignment error fixed.
 -Removed multiple usb_create_hcd() from prob funtion.
 -platform_set_drvdata() called before exynos_ohci_phy_enable().
 -ohci_setup() removed because it is called in .reset member
  of the ohci_hc_driver structure

V3:
 -No major changes only "exynos" written in capital letters
  in "OHCI exynos driver".
---
 drivers/usb/host/Kconfig       |    2 +-
 drivers/usb/host/Makefile      |    1 +
 drivers/usb/host/ohci-exynos.c |  167 +++++++++++++++++-----------------------
 drivers/usb/host/ohci-hcd.c    |   18 -----
 4 files changed, 71 insertions(+), 117 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 7bc598b..7b8f6bd 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -463,7 +463,7 @@ config USB_OHCI_SH
 	  If you use the PCI OHCI controller, this option is not necessary.
 
 config USB_OHCI_EXYNOS
-	boolean "OHCI support for Samsung EXYNOS SoC Series"
+	tristate "OHCI support for Samsung EXYNOS SoC Series"
 	depends on ARCH_EXYNOS
 	help
 	 Enable support for the Samsung Exynos SOC's on-chip OHCI controller.
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 480e203..26cf69a 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_USB_ISP1362_HCD)	+= isp1362-hcd.o
 obj-$(CONFIG_USB_OHCI_HCD)	+= ohci-hcd.o
 obj-$(CONFIG_USB_OHCI_HCD_PCI)	+= ohci-pci.o
 obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)	+= ohci-platform.o
+obj-$(CONFIG_USB_OHCI_EXYNOS)	+= ohci-exynos.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index b0b542c..ae6068d 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -12,24 +12,39 @@
  */
 
 #include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/platform_data/usb-ohci-exynos.h>
 #include <linux/usb/phy.h>
 #include <linux/usb/samsung_usb_phy.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/otg.h>
+
+#include "ohci.h"
+
+#define DRIVER_DESC "OHCI EXYNOS driver"
+
+static const char hcd_name[] = "ohci-exynos";
+static struct hc_driver __read_mostly exynos_ohci_hc_driver;
+
+#define to_exynos_ohci(hcd) (struct exynos_ohci_hcd *)(hcd_to_ohci(hcd)->priv)
 
 struct exynos_ohci_hcd {
-	struct device *dev;
-	struct usb_hcd *hcd;
 	struct clk *clk;
 	struct usb_phy *phy;
 	struct usb_otg *otg;
 	struct exynos4_ohci_platdata *pdata;
 };
 
-static void exynos_ohci_phy_enable(struct exynos_ohci_hcd *exynos_ohci)
+static void exynos_ohci_phy_enable(struct platform_device *pdev)
 {
-	struct platform_device *pdev = to_platform_device(exynos_ohci->dev);
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
+	struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 
 	if (exynos_ohci->phy)
 		usb_phy_init(exynos_ohci->phy);
@@ -37,9 +52,10 @@ static void exynos_ohci_phy_enable(struct exynos_ohci_hcd *exynos_ohci)
 		exynos_ohci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
 }
 
-static void exynos_ohci_phy_disable(struct exynos_ohci_hcd *exynos_ohci)
+static void exynos_ohci_phy_disable(struct platform_device *pdev)
 {
-	struct platform_device *pdev = to_platform_device(exynos_ohci->dev);
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
+	struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 
 	if (exynos_ohci->phy)
 		usb_phy_shutdown(exynos_ohci->phy);
@@ -47,63 +63,11 @@ static void exynos_ohci_phy_disable(struct exynos_ohci_hcd *exynos_ohci)
 		exynos_ohci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
 }
 
-static int ohci_exynos_reset(struct usb_hcd *hcd)
-{
-	return ohci_init(hcd_to_ohci(hcd));
-}
-
-static int ohci_exynos_start(struct usb_hcd *hcd)
-{
-	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
-	int ret;
-
-	ohci_dbg(ohci, "ohci_exynos_start, ohci:%p", ohci);
-
-	ret = ohci_run(ohci);
-	if (ret < 0) {
-		dev_err(hcd->self.controller, "can't start %s\n",
-			hcd->self.bus_name);
-		ohci_stop(hcd);
-		return ret;
-	}
-
-	return 0;
-}
-
-static const struct hc_driver exynos_ohci_hc_driver = {
-	.description		= hcd_name,
-	.product_desc		= "EXYNOS OHCI Host Controller",
-	.hcd_priv_size		= sizeof(struct ohci_hcd),
-
-	.irq			= ohci_irq,
-	.flags			= HCD_MEMORY|HCD_USB11,
-
-	.reset			= ohci_exynos_reset,
-	.start			= ohci_exynos_start,
-	.stop			= ohci_stop,
-	.shutdown		= ohci_shutdown,
-
-	.get_frame_number	= ohci_get_frame,
-
-	.urb_enqueue		= ohci_urb_enqueue,
-	.urb_dequeue		= ohci_urb_dequeue,
-	.endpoint_disable	= ohci_endpoint_disable,
-
-	.hub_status_data	= ohci_hub_status_data,
-	.hub_control		= ohci_hub_control,
-#ifdef	CONFIG_PM
-	.bus_suspend		= ohci_bus_suspend,
-	.bus_resume		= ohci_bus_resume,
-#endif
-	.start_port_reset	= ohci_start_port_reset,
-};
-
 static int exynos_ohci_probe(struct platform_device *pdev)
 {
 	struct exynos4_ohci_platdata *pdata = pdev->dev.platform_data;
 	struct exynos_ohci_hcd *exynos_ohci;
 	struct usb_hcd *hcd;
-	struct ohci_hcd *ohci;
 	struct resource *res;
 	struct usb_phy *phy;
 	int irq;
@@ -119,10 +83,14 @@ static int exynos_ohci_probe(struct platform_device *pdev)
 	if (!pdev->dev.coherent_dma_mask)
 		pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
 
-	exynos_ohci = devm_kzalloc(&pdev->dev, sizeof(struct exynos_ohci_hcd),
-					GFP_KERNEL);
-	if (!exynos_ohci)
+	hcd = usb_create_hcd(&exynos_ohci_hc_driver,
+				&pdev->dev, dev_name(&pdev->dev));
+	if (!hcd) {
+		dev_err(&pdev->dev, "Unable to create HCD\n");
 		return -ENOMEM;
+	}
+
+	exynos_ohci = to_exynos_ohci(hcd);
 
 	if (of_device_is_compatible(pdev->dev.of_node,
 					"samsung,exynos5440-ohci"))
@@ -143,17 +111,6 @@ static int exynos_ohci_probe(struct platform_device *pdev)
 	}
 
 skip_phy:
-
-	exynos_ohci->dev = &pdev->dev;
-
-	hcd = usb_create_hcd(&exynos_ohci_hc_driver, &pdev->dev,
-					dev_name(&pdev->dev));
-	if (!hcd) {
-		dev_err(&pdev->dev, "Unable to create HCD\n");
-		return -ENOMEM;
-	}
-
-	exynos_ohci->hcd = hcd;
 	exynos_ohci->clk = devm_clk_get(&pdev->dev, "usbhost");
 
 	if (IS_ERR(exynos_ohci->clk)) {
@@ -190,26 +147,21 @@ skip_phy:
 	}
 
 	if (exynos_ohci->otg)
-		exynos_ohci->otg->set_host(exynos_ohci->otg,
-					&exynos_ohci->hcd->self);
+		exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
 
-	exynos_ohci_phy_enable(exynos_ohci);
+	platform_set_drvdata(pdev, hcd);
 
-	ohci = hcd_to_ohci(hcd);
-	ohci_hcd_init(ohci);
+	exynos_ohci_phy_enable(pdev);
 
 	err = usb_add_hcd(hcd, irq, IRQF_SHARED);
 	if (err) {
 		dev_err(&pdev->dev, "Failed to add USB HCD\n");
 		goto fail_add_hcd;
 	}
-
-	platform_set_drvdata(pdev, exynos_ohci);
-
 	return 0;
 
 fail_add_hcd:
-	exynos_ohci_phy_disable(exynos_ohci);
+	exynos_ohci_phy_disable(pdev);
 fail_io:
 	clk_disable_unprepare(exynos_ohci->clk);
 fail_clk:
@@ -219,16 +171,15 @@ fail_clk:
 
 static int exynos_ohci_remove(struct platform_device *pdev)
 {
-	struct exynos_ohci_hcd *exynos_ohci = platform_get_drvdata(pdev);
-	struct usb_hcd *hcd = exynos_ohci->hcd;
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
+	struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 
 	usb_remove_hcd(hcd);
 
 	if (exynos_ohci->otg)
-		exynos_ohci->otg->set_host(exynos_ohci->otg,
-					&exynos_ohci->hcd->self);
+		exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
 
-	exynos_ohci_phy_disable(exynos_ohci);
+	exynos_ohci_phy_disable(pdev);
 
 	clk_disable_unprepare(exynos_ohci->clk);
 
@@ -239,8 +190,7 @@ static int exynos_ohci_remove(struct platform_device *pdev)
 
 static void exynos_ohci_shutdown(struct platform_device *pdev)
 {
-	struct exynos_ohci_hcd *exynos_ohci = platform_get_drvdata(pdev);
-	struct usb_hcd *hcd = exynos_ohci->hcd;
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
 
 	if (hcd->driver->shutdown)
 		hcd->driver->shutdown(hcd);
@@ -249,9 +199,10 @@ static void exynos_ohci_shutdown(struct platform_device *pdev)
 #ifdef CONFIG_PM
 static int exynos_ohci_suspend(struct device *dev)
 {
-	struct exynos_ohci_hcd *exynos_ohci = dev_get_drvdata(dev);
-	struct usb_hcd *hcd = exynos_ohci->hcd;
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
+	struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+	struct platform_device *pdev = to_platform_device(dev);
 	unsigned long flags;
 	int rc = 0;
 
@@ -271,10 +222,9 @@ static int exynos_ohci_suspend(struct device *dev)
 	clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
 
 	if (exynos_ohci->otg)
-		exynos_ohci->otg->set_host(exynos_ohci->otg,
-					&exynos_ohci->hcd->self);
+		exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
 
-	exynos_ohci_phy_disable(exynos_ohci);
+	exynos_ohci_phy_disable(pdev);
 
 	clk_disable_unprepare(exynos_ohci->clk);
 
@@ -286,16 +236,16 @@ fail:
 
 static int exynos_ohci_resume(struct device *dev)
 {
-	struct exynos_ohci_hcd *exynos_ohci = dev_get_drvdata(dev);
-	struct usb_hcd *hcd = exynos_ohci->hcd;
+	struct usb_hcd *hcd			= dev_get_drvdata(dev);
+	struct exynos_ohci_hcd *exynos_ohci	= to_exynos_ohci(hcd);
+	struct platform_device *pdev		= to_platform_device(dev);
 
 	clk_prepare_enable(exynos_ohci->clk);
 
 	if (exynos_ohci->otg)
-		exynos_ohci->otg->set_host(exynos_ohci->otg,
-					&exynos_ohci->hcd->self);
+		exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
 
-	exynos_ohci_phy_enable(exynos_ohci);
+	exynos_ohci_phy_enable(pdev);
 
 	ohci_resume(hcd, false);
 
@@ -306,6 +256,10 @@ static int exynos_ohci_resume(struct device *dev)
 #define exynos_ohci_resume	NULL
 #endif
 
+static const struct ohci_driver_overrides exynos_overrides __initconst = {
+	.extra_priv_size =	sizeof(struct exynos_ohci_hcd),
+};
+
 static const struct dev_pm_ops exynos_ohci_pm_ops = {
 	.suspend	= exynos_ohci_suspend,
 	.resume		= exynos_ohci_resume,
@@ -331,6 +285,23 @@ static struct platform_driver exynos_ohci_driver = {
 		.of_match_table	= of_match_ptr(exynos_ohci_match),
 	}
 };
+static int __init ohci_exynos_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+	ohci_init_driver(&exynos_ohci_hc_driver, &exynos_overrides);
+	return platform_driver_register(&exynos_ohci_driver);
+}
+module_init(ohci_exynos_init);
+
+static void __exit ohci_exynos_cleanup(void)
+{
+	platform_driver_unregister(&exynos_ohci_driver);
+}
+module_exit(ohci_exynos_cleanup);
 
 MODULE_ALIAS("platform:exynos-ohci");
 MODULE_AUTHOR("Jingoo Han <jg1.han at samsung.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index a9d3437..2980bb6 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1182,11 +1182,6 @@ MODULE_LICENSE ("GPL");
 #define S3C2410_PLATFORM_DRIVER	ohci_hcd_s3c2410_driver
 #endif
 
-#ifdef CONFIG_USB_OHCI_EXYNOS
-#include "ohci-exynos.c"
-#define EXYNOS_PLATFORM_DRIVER	exynos_ohci_driver
-#endif
-
 #ifdef CONFIG_USB_OHCI_HCD_OMAP1
 #include "ohci-omap.c"
 #define OMAP1_PLATFORM_DRIVER	ohci_hcd_omap_driver
@@ -1336,12 +1331,6 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_s3c2410;
 #endif
 
-#ifdef EXYNOS_PLATFORM_DRIVER
-	retval = platform_driver_register(&EXYNOS_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_exynos;
-#endif
-
 #ifdef EP93XX_PLATFORM_DRIVER
 	retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
 	if (retval < 0)
@@ -1395,10 +1384,6 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
  error_ep93xx:
 #endif
-#ifdef EXYNOS_PLATFORM_DRIVER
-	platform_driver_unregister(&EXYNOS_PLATFORM_DRIVER);
- error_exynos:
-#endif
 #ifdef S3C2410_PLATFORM_DRIVER
 	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
  error_s3c2410:
@@ -1463,9 +1448,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef EP93XX_PLATFORM_DRIVER
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
 #endif
-#ifdef EXYNOS_PLATFORM_DRIVER
-	platform_driver_unregister(&EXYNOS_PLATFORM_DRIVER);
-#endif
 #ifdef S3C2410_PLATFORM_DRIVER
 	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
 #endif
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:19:26 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 14:49:26 +0530
Subject: [PATCH 2/6] USB: OHCI: make ohci-omap a separate driver
In-Reply-To: <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
 <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374484770-24531-3-git-send-email-manjunath.goudar@linaro.org>

Separate the  TI OHCI OMAP1/2 host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: linux-usb at vger.kernel.org

V2:
 -omap_ohci_clock_power(0) called in usb_hcd_omap_remove().
 -Removed ohci_setup() call from usb_hcd_omap_probe().
 -host_enabled and host_initialized variables aren't used for anything
  thats what removed.

V3:
 -rewritten if (config->otg || config->rwc) block statements into
  two separate 'if blocks' to handle below scenarios
  1. config->otg set scenario.
  2. if any of these (config->otg, config->rwc) are set, this
     scenario should be handled only after ohci_setup()

V4:
 -usb_remove_hcd() function is required a valid clock that is what
  omap_ohci_clock_power(0) is called after hcd shutdown.
---
 drivers/usb/host/Kconfig     |    2 +-
 drivers/usb/host/Makefile    |    1 +
 drivers/usb/host/ohci-hcd.c  |   18 -----
 drivers/usb/host/ohci-omap.c |  156 ++++++++++++++----------------------------
 4 files changed, 55 insertions(+), 122 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 7b8f6bd..99b7e7e 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -376,7 +376,7 @@ config USB_OHCI_HCD
 if USB_OHCI_HCD
 
 config USB_OHCI_HCD_OMAP1
-	bool "OHCI support for OMAP1/2 chips"
+	tristate "OHCI support for OMAP1/2 chips"
 	depends on ARCH_OMAP1
 	default y
 	---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 26cf69a..c7076ec 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_USB_OHCI_HCD)	+= ohci-hcd.o
 obj-$(CONFIG_USB_OHCI_HCD_PCI)	+= ohci-pci.o
 obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)	+= ohci-platform.o
 obj-$(CONFIG_USB_OHCI_EXYNOS)	+= ohci-exynos.o
+obj-$(CONFIG_USB_OHCI_HCD_OMAP1)	+= ohci-omap.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 2980bb6..1abc1e7 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1182,11 +1182,6 @@ MODULE_LICENSE ("GPL");
 #define S3C2410_PLATFORM_DRIVER	ohci_hcd_s3c2410_driver
 #endif
 
-#ifdef CONFIG_USB_OHCI_HCD_OMAP1
-#include "ohci-omap.c"
-#define OMAP1_PLATFORM_DRIVER	ohci_hcd_omap_driver
-#endif
-
 #ifdef CONFIG_USB_OHCI_HCD_OMAP3
 #include "ohci-omap3.c"
 #define OMAP3_PLATFORM_DRIVER	ohci_hcd_omap3_driver
@@ -1289,12 +1284,6 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_platform;
 #endif
 
-#ifdef OMAP1_PLATFORM_DRIVER
-	retval = platform_driver_register(&OMAP1_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_omap1_platform;
-#endif
-
 #ifdef OMAP3_PLATFORM_DRIVER
 	retval = platform_driver_register(&OMAP3_PLATFORM_DRIVER);
 	if (retval < 0)
@@ -1408,10 +1397,6 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
  error_omap3_platform:
 #endif
-#ifdef OMAP1_PLATFORM_DRIVER
-	platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
- error_omap1_platform:
-#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
  error_platform:
@@ -1466,9 +1451,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef OMAP3_PLATFORM_DRIVER
 	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
 #endif
-#ifdef OMAP1_PLATFORM_DRIVER
-	platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
-#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 8747fa6..8149ef0 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -14,12 +14,21 @@
  * This file is licenced under the GPL.
  */
 
-#include <linux/signal.h>
-#include <linux/jiffies.h>
-#include <linux/platform_device.h>
 #include <linux/clk.h>
+#include <linux/dma-mapping.h>
 #include <linux/err.h>
 #include <linux/gpio.h>
+#include <linux/io.h>
+#include <linux/jiffies.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/usb/otg.h>
+#include <linux/platform_device.h>
+#include <linux/signal.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ohci.h"
 
 #include <asm/io.h>
 #include <asm/mach-types.h>
@@ -42,10 +51,7 @@
 #define OMAP1510_LB_MMU_RAM_H	0xfffec234
 #define OMAP1510_LB_MMU_RAM_L	0xfffec238
 
-
-#ifndef CONFIG_ARCH_OMAP
-#error "This file is OMAP bus glue.  CONFIG_OMAP must be defined."
-#endif
+#define DRIVER_DESC "OHCI OMAP driver"
 
 #ifdef CONFIG_TPS65010
 #include <linux/i2c/tps65010.h>
@@ -68,8 +74,9 @@ extern int ocpi_enable(void);
 
 static struct clk *usb_host_ck;
 static struct clk *usb_dc_ck;
-static int host_enabled;
-static int host_initialized;
+
+static const char hcd_name[] = "ohci-omap";
+static struct hc_driver __read_mostly ohci_omap_hc_driver;
 
 static void omap_ohci_clock_power(int on)
 {
@@ -188,7 +195,7 @@ static void start_hnp(struct ohci_hcd *ohci)
 
 /*-------------------------------------------------------------------------*/
 
-static int ohci_omap_init(struct usb_hcd *hcd)
+static int ohci_omap_reset(struct usb_hcd *hcd)
 {
 	struct ohci_hcd		*ohci = hcd_to_ohci(hcd);
 	struct omap_usb_config	*config = hcd->self.controller->platform_data;
@@ -198,9 +205,9 @@ static int ohci_omap_init(struct usb_hcd *hcd)
 	dev_dbg(hcd->self.controller, "starting USB Controller\n");
 
 	if (config->otg) {
-		ohci_to_hcd(ohci)->self.otg_port = config->otg;
+		hcd->self.otg_port = config->otg;
 		/* default/minimum OTG power budget:  8 mA */
-		ohci_to_hcd(ohci)->power_budget = 8;
+		hcd->power_budget = 8;
 	}
 
 	/* boards can use OTG transceivers in non-OTG modes */
@@ -238,9 +245,15 @@ static int ohci_omap_init(struct usb_hcd *hcd)
 		omap_1510_local_bus_init();
 	}
 
-	if ((ret = ohci_init(ohci)) < 0)
+	ret = ohci_setup(hcd);
+	if (ret < 0)
 		return ret;
 
+	if (config->otg || config->rwc) {
+		ohci->hc_control = OHCI_CTRL_RWC;
+		writel(OHCI_CTRL_RWC, &ohci->regs->control);
+	}
+
 	/* board-specific power switching and overcurrent support */
 	if (machine_is_omap_osk() || machine_is_omap_innovator()) {
 		u32	rh = roothub_a (ohci);
@@ -281,14 +294,6 @@ static int ohci_omap_init(struct usb_hcd *hcd)
 	return 0;
 }
 
-static void ohci_omap_stop(struct usb_hcd *hcd)
-{
-	dev_dbg(hcd->self.controller, "stopping USB Controller\n");
-	ohci_stop(hcd);
-	omap_ohci_clock_power(0);
-}
-
-
 /*-------------------------------------------------------------------------*/
 
 /**
@@ -304,7 +309,6 @@ static int usb_hcd_omap_probe (const struct hc_driver *driver,
 {
 	int retval, irq;
 	struct usb_hcd *hcd = 0;
-	struct ohci_hcd *ohci;
 
 	if (pdev->num_resources != 2) {
 		printk(KERN_ERR "hcd probe: invalid num_resources: %i\n",
@@ -354,12 +358,6 @@ static int usb_hcd_omap_probe (const struct hc_driver *driver,
 		goto err2;
 	}
 
-	ohci = hcd_to_ohci(hcd);
-	ohci_hcd_init(ohci);
-
-	host_initialized = 0;
-	host_enabled = 1;
-
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
 		retval = -ENXIO;
@@ -369,11 +367,6 @@ static int usb_hcd_omap_probe (const struct hc_driver *driver,
 	if (retval)
 		goto err3;
 
-	host_initialized = 1;
-
-	if (!host_enabled)
-		omap_ohci_clock_power(0);
-
 	return 0;
 err3:
 	iounmap(hcd->regs);
@@ -402,7 +395,9 @@ err0:
 static inline void
 usb_hcd_omap_remove (struct usb_hcd *hcd, struct platform_device *pdev)
 {
+	dev_dbg(hcd->self.controller, "stopping USB Controller\n");
 	usb_remove_hcd(hcd);
+	omap_ohci_clock_power(0);
 	if (!IS_ERR_OR_NULL(hcd->phy)) {
 		(void) otg_set_host(hcd->phy->otg, 0);
 		usb_put_phy(hcd->phy);
@@ -418,76 +413,6 @@ usb_hcd_omap_remove (struct usb_hcd *hcd, struct platform_device *pdev)
 
 /*-------------------------------------------------------------------------*/
 
-static int
-ohci_omap_start (struct usb_hcd *hcd)
-{
-	struct omap_usb_config *config;
-	struct ohci_hcd	*ohci = hcd_to_ohci (hcd);
-	int		ret;
-
-	if (!host_enabled)
-		return 0;
-	config = hcd->self.controller->platform_data;
-	if (config->otg || config->rwc) {
-		ohci->hc_control = OHCI_CTRL_RWC;
-		writel(OHCI_CTRL_RWC, &ohci->regs->control);
-	}
-
-	if ((ret = ohci_run (ohci)) < 0) {
-		dev_err(hcd->self.controller, "can't start\n");
-		ohci_stop (hcd);
-		return ret;
-	}
-	return 0;
-}
-
-/*-------------------------------------------------------------------------*/
-
-static const struct hc_driver ohci_omap_hc_driver = {
-	.description =		hcd_name,
-	.product_desc =		"OMAP OHCI",
-	.hcd_priv_size =	sizeof(struct ohci_hcd),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq =			ohci_irq,
-	.flags =		HCD_USB11 | HCD_MEMORY,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.reset =		ohci_omap_init,
-	.start =		ohci_omap_start,
-	.stop =			ohci_omap_stop,
-	.shutdown =		ohci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue =		ohci_urb_enqueue,
-	.urb_dequeue =		ohci_urb_dequeue,
-	.endpoint_disable =	ohci_endpoint_disable,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number =	ohci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data =	ohci_hub_status_data,
-	.hub_control =		ohci_hub_control,
-#ifdef	CONFIG_PM
-	.bus_suspend =		ohci_bus_suspend,
-	.bus_resume =		ohci_bus_resume,
-#endif
-	.start_port_reset =	ohci_start_port_reset,
-};
-
-/*-------------------------------------------------------------------------*/
-
 static int ohci_hcd_omap_drv_probe(struct platform_device *dev)
 {
 	return usb_hcd_omap_probe(&ohci_omap_hc_driver, dev);
@@ -553,4 +478,29 @@ static struct platform_driver ohci_hcd_omap_driver = {
 	},
 };
 
+static const struct ohci_driver_overrides omap_overrides __initconst = {
+	.product_desc	= "OMAP OHCI",
+	.reset		= ohci_omap_reset
+};
+
+static int __init ohci_omap_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ohci_init_driver(&ohci_omap_hc_driver, &omap_overrides);
+	return platform_driver_register(&ohci_hcd_omap_driver);
+}
+module_init(ohci_omap_init);
+
+static void __exit ohci_omap_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_omap_driver);
+}
+module_exit(ohci_omap_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_ALIAS("platform:ohci");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:19:27 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 14:49:27 +0530
Subject: [PATCH 3/6] USB: OHCI: make ohci-omap3 a separate driver
In-Reply-To: <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
 <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374484770-24531-4-git-send-email-manjunath.goudar@linaro.org>

Separate the  TI OHCI OMAP3 host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Cc: Anand Gadiyar <gadiyar at ti.com>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: linux-usb at vger.kernel.org

V2:
 -ohci_setup() removed because it is called in .reset member
  of the ohci_hc_driver structure.
 -The improper multi-line commenting style written in proper way.
  ('*' characters aligned in vertically).

V3:
 -RemoteWakeupConnected setting has been removed.

V4:
 -V3 modification revert back, only ohci->regs setting write()
  function has been removed because ohci->regs doesn't get set until
  usb_add_hcd.
---
 drivers/usb/host/Kconfig      |    2 +-
 drivers/usb/host/Makefile     |    1 +
 drivers/usb/host/ohci-hcd.c   |   18 -------
 drivers/usb/host/ohci-omap3.c |  118 +++++++++++++----------------------------
 4 files changed, 40 insertions(+), 99 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 99b7e7e..3eab432 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -383,7 +383,7 @@ config USB_OHCI_HCD_OMAP1
 	  Enables support for the OHCI controller on OMAP1/2 chips.
 
 config USB_OHCI_HCD_OMAP3
-	bool "OHCI support for OMAP3 and later chips"
+	tristate "OHCI support for OMAP3 and later chips"
 	depends on (ARCH_OMAP3 || ARCH_OMAP4)
 	default y
 	---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index c7076ec..954466d 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_USB_OHCI_HCD_PCI)	+= ohci-pci.o
 obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)	+= ohci-platform.o
 obj-$(CONFIG_USB_OHCI_EXYNOS)	+= ohci-exynos.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP1)	+= ohci-omap.o
+obj-$(CONFIG_USB_OHCI_HCD_OMAP3)	+= ohci-omap3.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 1abc1e7..cad51d2 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1182,11 +1182,6 @@ MODULE_LICENSE ("GPL");
 #define S3C2410_PLATFORM_DRIVER	ohci_hcd_s3c2410_driver
 #endif
 
-#ifdef CONFIG_USB_OHCI_HCD_OMAP3
-#include "ohci-omap3.c"
-#define OMAP3_PLATFORM_DRIVER	ohci_hcd_omap3_driver
-#endif
-
 #if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx)
 #include "ohci-pxa27x.c"
 #define PLATFORM_DRIVER		ohci_hcd_pxa27x_driver
@@ -1284,12 +1279,6 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_platform;
 #endif
 
-#ifdef OMAP3_PLATFORM_DRIVER
-	retval = platform_driver_register(&OMAP3_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_omap3_platform;
-#endif
-
 #ifdef OF_PLATFORM_DRIVER
 	retval = platform_driver_register(&OF_PLATFORM_DRIVER);
 	if (retval < 0)
@@ -1393,10 +1382,6 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
  error_of_platform:
 #endif
-#ifdef OMAP3_PLATFORM_DRIVER
-	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
- error_omap3_platform:
-#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
  error_platform:
@@ -1448,9 +1433,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef OF_PLATFORM_DRIVER
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
 #endif
-#ifdef OMAP3_PLATFORM_DRIVER
-	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
-#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
index 8f71357..e14f4d9 100644
--- a/drivers/usb/host/ohci-omap3.c
+++ b/drivers/usb/host/ohci-omap3.c
@@ -29,90 +29,22 @@
  *	- add kernel-doc
  */
 
+#include <linux/dma-mapping.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/usb/otg.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
-#include <linux/of.h>
-#include <linux/dma-mapping.h>
-
-/*-------------------------------------------------------------------------*/
-
-static int ohci_omap3_init(struct usb_hcd *hcd)
-{
-	dev_dbg(hcd->self.controller, "starting OHCI controller\n");
-
-	return ohci_init(hcd_to_ohci(hcd));
-}
-
-/*-------------------------------------------------------------------------*/
-
-static int ohci_omap3_start(struct usb_hcd *hcd)
-{
-	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
-	int ret;
-
-	/*
-	 * RemoteWakeupConnected has to be set explicitly before
-	 * calling ohci_run. The reset value of RWC is 0.
-	 */
-	ohci->hc_control = OHCI_CTRL_RWC;
-	writel(OHCI_CTRL_RWC, &ohci->regs->control);
-
-	ret = ohci_run(ohci);
-
-	if (ret < 0) {
-		dev_err(hcd->self.controller, "can't start\n");
-		ohci_stop(hcd);
-	}
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
 
-	return ret;
-}
+#include "ohci.h"
 
-/*-------------------------------------------------------------------------*/
+#define DRIVER_DESC "OHCI OMAP3 driver"
 
-static const struct hc_driver ohci_omap3_hc_driver = {
-	.description =		hcd_name,
-	.product_desc =		"OMAP3 OHCI Host Controller",
-	.hcd_priv_size =	sizeof(struct ohci_hcd),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq =			ohci_irq,
-	.flags =		HCD_USB11 | HCD_MEMORY,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.reset =		ohci_omap3_init,
-	.start =		ohci_omap3_start,
-	.stop =			ohci_stop,
-	.shutdown =		ohci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue =		ohci_urb_enqueue,
-	.urb_dequeue =		ohci_urb_dequeue,
-	.endpoint_disable =	ohci_endpoint_disable,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number =	ohci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data =	ohci_hub_status_data,
-	.hub_control =		ohci_hub_control,
-#ifdef	CONFIG_PM
-	.bus_suspend =		ohci_bus_suspend,
-	.bus_resume =		ohci_bus_resume,
-#endif
-	.start_port_reset =	ohci_start_port_reset,
-};
-
-/*-------------------------------------------------------------------------*/
+static const char hcd_name[] = "ohci-omap3";
+static struct hc_driver __read_mostly ohci_omap3_hc_driver;
 
 /*
  * configure so an HC device and id are always provided
@@ -129,6 +61,7 @@ static const struct hc_driver ohci_omap3_hc_driver = {
 static int ohci_hcd_omap3_probe(struct platform_device *pdev)
 {
 	struct device		*dev = &pdev->dev;
+	struct ohci_hcd		*ohci;
 	struct usb_hcd		*hcd = NULL;
 	void __iomem		*regs = NULL;
 	struct resource		*res;
@@ -185,7 +118,12 @@ static int ohci_hcd_omap3_probe(struct platform_device *pdev)
 	pm_runtime_enable(dev);
 	pm_runtime_get_sync(dev);
 
-	ohci_hcd_init(hcd_to_ohci(hcd));
+	ohci = hcd_to_ohci(hcd);
+	/*
+	 * RemoteWakeupConnected has to be set explicitly before
+	 * calling ohci_run. The reset value of RWC is 0.
+	 */
+	ohci->hc_control = OHCI_CTRL_RWC;
 
 	ret = usb_add_hcd(hcd, irq, 0);
 	if (ret) {
@@ -256,5 +194,25 @@ static struct platform_driver ohci_hcd_omap3_driver = {
 	},
 };
 
+static int __init ohci_omap3_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ohci_init_driver(&ohci_omap3_hc_driver, NULL);
+	return platform_driver_register(&ohci_hcd_omap3_driver);
+}
+module_init(ohci_omap3_init);
+
+static void __exit ohci_omap3_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_omap3_driver);
+}
+module_exit(ohci_omap3_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_ALIAS("platform:ohci-omap3");
 MODULE_AUTHOR("Anand Gadiyar <gadiyar at ti.com>");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:19:28 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 14:49:28 +0530
Subject: [PATCH 4/6] USB: OHCI: make ohci-spear a separate driver
In-Reply-To: <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
 <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374484770-24531-5-git-send-email-manjunath.goudar@linaro.org>

Separate the ST OHCI SPEAr host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Viresh Kumar <viresh.linux at gmail.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -ohci_setup() removed because it is called in .reset member
  of the ohci_hc_driver structure.
 -debugging stuff isn't needed any more that's what removed.

V3:
 No change.
---
 drivers/usb/host/Kconfig      |    8 +++
 drivers/usb/host/Makefile     |    1 +
 drivers/usb/host/ohci-hcd.c   |   18 ------
 drivers/usb/host/ohci-spear.c |  140 +++++++++++++++++------------------------
 4 files changed, 65 insertions(+), 102 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 3eab432..a5a34a3 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -382,6 +382,14 @@ config USB_OHCI_HCD_OMAP1
 	---help---
 	  Enables support for the OHCI controller on OMAP1/2 chips.
 
+config USB_OHCI_HCD_SPEAR
+        tristate "Support for ST SPEAr on-chip OHCI USB controller"
+        depends on USB_OHCI_HCD && PLAT_SPEAR
+        default y
+        ---help---
+          Enables support for the on-chip OHCI controller on
+          ST SPEAr chips.
+
 config USB_OHCI_HCD_OMAP3
 	tristate "OHCI support for OMAP3 and later chips"
 	depends on (ARCH_OMAP3 || ARCH_OMAP4)
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 954466d..b8ea17c 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)	+= ohci-platform.o
 obj-$(CONFIG_USB_OHCI_EXYNOS)	+= ohci-exynos.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP1)	+= ohci-omap.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP3)	+= ohci-omap3.o
+obj-$(CONFIG_USB_OHCI_HCD_SPEAR)	+= ohci-spear.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index cad51d2..34ec156 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1212,11 +1212,6 @@ MODULE_LICENSE ("GPL");
 #define OF_PLATFORM_DRIVER	ohci_hcd_ppc_of_driver
 #endif
 
-#ifdef CONFIG_PLAT_SPEAR
-#include "ohci-spear.c"
-#define SPEAR_PLATFORM_DRIVER	spear_ohci_hcd_driver
-#endif
-
 #ifdef CONFIG_PPC_PS3
 #include "ohci-ps3.c"
 #define PS3_SYSTEM_BUS_DRIVER	ps3_ohci_driver
@@ -1333,19 +1328,9 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_davinci;
 #endif
 
-#ifdef SPEAR_PLATFORM_DRIVER
-	retval = platform_driver_register(&SPEAR_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_spear;
-#endif
-
 	return retval;
 
 	/* Error path */
-#ifdef SPEAR_PLATFORM_DRIVER
-	platform_driver_unregister(&SPEAR_PLATFORM_DRIVER);
- error_spear:
-#endif
 #ifdef DAVINCI_PLATFORM_DRIVER
 	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
  error_davinci:
@@ -1403,9 +1388,6 @@ module_init(ohci_hcd_mod_init);
 
 static void __exit ohci_hcd_mod_exit(void)
 {
-#ifdef SPEAR_PLATFORM_DRIVER
-	platform_driver_unregister(&SPEAR_PLATFORM_DRIVER);
-#endif
 #ifdef DAVINCI_PLATFORM_DRIVER
 	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
index cc9dd9e..31ff3fc 100644
--- a/drivers/usb/host/ohci-spear.c
+++ b/drivers/usb/host/ohci-spear.c
@@ -11,92 +11,37 @@
 * warranty of any kind, whether express or implied.
 */
 
-#include <linux/signal.h>
-#include <linux/platform_device.h>
 #include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/signal.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ohci.h"
 
+#define DRIVER_DESC "OHCI SPEAr driver"
+
+static const char hcd_name[] = "SPEAr-ohci";
 struct spear_ohci {
-	struct ohci_hcd ohci;
 	struct clk *clk;
 };
 
-#define to_spear_ohci(hcd)	(struct spear_ohci *)hcd_to_ohci(hcd)
-
-static void spear_start_ohci(struct spear_ohci *ohci)
-{
-	clk_prepare_enable(ohci->clk);
-}
-
-static void spear_stop_ohci(struct spear_ohci *ohci)
-{
-	clk_disable_unprepare(ohci->clk);
-}
-
-static int ohci_spear_start(struct usb_hcd *hcd)
-{
-	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
-	int ret;
-
-	ret = ohci_init(ohci);
-	if (ret < 0)
-		return ret;
-	ohci->regs = hcd->regs;
-
-	ret = ohci_run(ohci);
-	if (ret < 0) {
-		dev_err(hcd->self.controller, "can't start\n");
-		ohci_stop(hcd);
-		return ret;
-	}
-
-	create_debug_files(ohci);
-
-#ifdef DEBUG
-	ohci_dump(ohci, 1);
-#endif
-	return 0;
-}
-
-static const struct hc_driver ohci_spear_hc_driver = {
-	.description		= hcd_name,
-	.product_desc		= "SPEAr OHCI",
-	.hcd_priv_size		= sizeof(struct spear_ohci),
-
-	/* generic hardware linkage */
-	.irq			= ohci_irq,
-	.flags			= HCD_USB11 | HCD_MEMORY,
-
-	/* basic lifecycle operations */
-	.start			= ohci_spear_start,
-	.stop			= ohci_stop,
-	.shutdown		= ohci_shutdown,
-#ifdef	CONFIG_PM
-	.bus_suspend		= ohci_bus_suspend,
-	.bus_resume		= ohci_bus_resume,
-#endif
-
-	/* managing i/o requests and associated device resources */
-	.urb_enqueue		= ohci_urb_enqueue,
-	.urb_dequeue		= ohci_urb_dequeue,
-	.endpoint_disable	= ohci_endpoint_disable,
-
-	/* scheduling support */
-	.get_frame_number	= ohci_get_frame,
+#define to_spear_ohci(hcd)     (struct spear_ohci *)(hcd_to_ohci(hcd)->priv)
 
-	/* root hub support */
-	.hub_status_data	= ohci_hub_status_data,
-	.hub_control		= ohci_hub_control,
-
-	.start_port_reset	= ohci_start_port_reset,
-};
+static struct hc_driver __read_mostly ohci_spear_hc_driver;
 
 static int spear_ohci_hcd_drv_probe(struct platform_device *pdev)
 {
 	const struct hc_driver *driver = &ohci_spear_hc_driver;
+	struct ohci_hcd *ohci;
 	struct usb_hcd *hcd = NULL;
 	struct clk *usbh_clk;
-	struct spear_ohci *ohci_p;
+	struct spear_ohci *sohci_p;
 	struct resource *res;
 	int retval, irq;
 
@@ -151,16 +96,18 @@ static int spear_ohci_hcd_drv_probe(struct platform_device *pdev)
 		goto err_put_hcd;
 	}
 
-	ohci_p = (struct spear_ohci *)hcd_to_ohci(hcd);
-	ohci_p->clk = usbh_clk;
-	spear_start_ohci(ohci_p);
-	ohci_hcd_init(hcd_to_ohci(hcd));
+	sohci_p = to_spear_ohci(hcd);
+	sohci_p->clk = usbh_clk;
+
+	clk_prepare_enable(sohci_p->clk);
+
+	ohci = hcd_to_ohci(hcd);
 
 	retval = usb_add_hcd(hcd, platform_get_irq(pdev, 0), 0);
 	if (retval == 0)
 		return retval;
 
-	spear_stop_ohci(ohci_p);
+	clk_disable_unprepare(sohci_p->clk);
 err_put_hcd:
 	usb_put_hcd(hcd);
 fail:
@@ -172,11 +119,11 @@ fail:
 static int spear_ohci_hcd_drv_remove(struct platform_device *pdev)
 {
 	struct usb_hcd *hcd = platform_get_drvdata(pdev);
-	struct spear_ohci *ohci_p = to_spear_ohci(hcd);
+	struct spear_ohci *sohci_p = to_spear_ohci(hcd);
 
 	usb_remove_hcd(hcd);
-	if (ohci_p->clk)
-		spear_stop_ohci(ohci_p);
+	if (sohci_p->clk)
+		clk_disable_unprepare(sohci_p->clk);
 
 	usb_put_hcd(hcd);
 	return 0;
@@ -188,13 +135,14 @@ static int spear_ohci_hcd_drv_suspend(struct platform_device *dev,
 {
 	struct usb_hcd *hcd = platform_get_drvdata(dev);
 	struct ohci_hcd	*ohci = hcd_to_ohci(hcd);
-	struct spear_ohci *ohci_p = to_spear_ohci(hcd);
+	struct spear_ohci *sohci_p = to_spear_ohci(hcd);
 
 	if (time_before(jiffies, ohci->next_statechange))
 		msleep(5);
 	ohci->next_statechange = jiffies;
 
-	spear_stop_ohci(ohci_p);
+	clk_disable_unprepare(sohci_p->clk);
+
 	return 0;
 }
 
@@ -202,13 +150,13 @@ static int spear_ohci_hcd_drv_resume(struct platform_device *dev)
 {
 	struct usb_hcd *hcd = platform_get_drvdata(dev);
 	struct ohci_hcd	*ohci = hcd_to_ohci(hcd);
-	struct spear_ohci *ohci_p = to_spear_ohci(hcd);
+	struct spear_ohci *sohci_p = to_spear_ohci(hcd);
 
 	if (time_before(jiffies, ohci->next_statechange))
 		msleep(5);
 	ohci->next_statechange = jiffies;
 
-	spear_start_ohci(ohci_p);
+	clk_prepare_enable(sohci_p->clk);
 	ohci_resume(hcd, false);
 	return 0;
 }
@@ -234,4 +182,28 @@ static struct platform_driver spear_ohci_hcd_driver = {
 	},
 };
 
+static const struct ohci_driver_overrides spear_overrides __initconst = {
+	.extra_priv_size = sizeof(struct spear_ohci),
+};
+static int __init ohci_spear_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ohci_init_driver(&ohci_spear_hc_driver, &spear_overrides);
+	return platform_driver_register(&spear_ohci_hcd_driver);
+}
+module_init(ohci_spear_init);
+
+static void __exit ohci_spear_cleanup(void)
+{
+	platform_driver_unregister(&spear_ohci_hcd_driver);
+}
+module_exit(ohci_spear_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_AUTHOR("Deepak Sikri");
+MODULE_LICENSE("GPL v2");
 MODULE_ALIAS("platform:spear-ohci");
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:19:29 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 14:49:29 +0530
Subject: [PATCH 5/6] USB: OHCI: make ohci-at91 a separate driver
In-Reply-To: <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
 <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374484770-24531-6-git-send-email-manjunath.goudar@linaro.org>

Separate the  TI OHCI Atmel host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.12.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -Set non-standard fields in ohci_at91_hc_driver manually, rather than
  relying on an expanded struct ohci_driver_overrides.
 -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
  relying on ohci_hub_control and hub_status_data being exported.
 -ohci_setup() has been removed because it is called in .reset member
  of the ohci_hc_driver structure.

V3:
 -The ohci_restart() function is not required in  current scenario,
  only discarding connection state of integrated transceivers is sufficient,
  for this directly handling ohci->hc_control.

V4:
 - Removed extra space after "tristate".
 - Removed extra space between function name  and '(' characters.
 - MODULE_ALIAS line moved to last statement of ohci-at91 file.
---
 drivers/usb/host/Kconfig     |    8 +++
 drivers/usb/host/Makefile    |    1 +
 drivers/usb/host/ohci-at91.c |  153 +++++++++++++++++++-----------------------
 drivers/usb/host/ohci-hcd.c  |   18 -----
 4 files changed, 77 insertions(+), 103 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a5a34a3..693560a 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR
           Enables support for the on-chip OHCI controller on
           ST SPEAr chips.
 
+config USB_OHCI_HCD_AT91
+        tristate "Support for Atmel on-chip OHCI USB controller"
+        depends on USB_OHCI_HCD && ARCH_AT91
+        default y
+        ---help---
+          Enables support for the on-chip OHCI controller on
+          Atmel chips.
+
 config USB_OHCI_HCD_OMAP3
 	tristate "OHCI support for OMAP3 and later chips"
 	depends on (ARCH_OMAP3 || ARCH_OMAP4)
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index b8ea17c..a70b044 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_USB_OHCI_EXYNOS)	+= ohci-exynos.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP1)	+= ohci-omap.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP3)	+= ohci-omap3.o
 obj-$(CONFIG_USB_OHCI_HCD_SPEAR)	+= ohci-spear.o
+obj-$(CONFIG_USB_OHCI_HCD_AT91)	+= ohci-at91.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 9677f68..08e28eb 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -13,27 +13,41 @@
  */
 
 #include <linux/clk.h>
-#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
 #include <linux/of_platform.h>
 #include <linux/of_gpio.h>
+#include <linux/platform_device.h>
 #include <linux/platform_data/atmel.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
 
 #include <mach/hardware.h>
 #include <asm/gpio.h>
 
 #include <mach/cpu.h>
 
-#ifndef CONFIG_ARCH_AT91
-#error "CONFIG_ARCH_AT91 must be defined."
-#endif
+
+#include "ohci.h"
 
 #define valid_port(index)	((index) >= 0 && (index) < AT91_MAX_USBH_PORTS)
 #define at91_for_each_port(index)	\
 		for ((index) = 0; (index) < AT91_MAX_USBH_PORTS; (index)++)
 
 /* interface and function clocks; sometimes also an AHB clock */
+
+#define DRIVER_DESC "OHCI Atmel driver"
+
+static const char hcd_name[] = "ohci-atmel";
+
+static struct hc_driver __read_mostly ohci_at91_hc_driver;
 static struct clk *iclk, *fclk, *hclk;
 static int clocked;
+static int (*orig_ohci_hub_control)(struct usb_hcd  *hcd, u16 typeReq,
+			u16 wValue, u16 wIndex, char *buf, u16 wLength);
+static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
 
 extern int usb_disabled(void);
 
@@ -111,6 +125,8 @@ static void usb_hcd_at91_remove (struct usb_hcd *, struct platform_device *);
 static int usb_hcd_at91_probe(const struct hc_driver *driver,
 			struct platform_device *pdev)
 {
+	struct at91_usbh_data *board;
+	struct ohci_hcd *ohci;
 	int retval;
 	struct usb_hcd *hcd = NULL;
 
@@ -163,8 +179,10 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
 		goto err5;
 	}
 
+	board = hcd->self.controller->platform_data;
+	ohci = hcd_to_ohci(hcd);
+	ohci->num_ports = board->ports;
 	at91_start_hc(pdev);
-	ohci_hcd_init(hcd_to_ohci(hcd));
 
 	retval = usb_add_hcd(hcd, pdev->resource[1].start, IRQF_SHARED);
 	if (retval == 0)
@@ -221,36 +239,6 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
 }
 
 /*-------------------------------------------------------------------------*/
-
-static int
-ohci_at91_reset (struct usb_hcd *hcd)
-{
-	struct at91_usbh_data	*board = hcd->self.controller->platform_data;
-	struct ohci_hcd		*ohci = hcd_to_ohci (hcd);
-	int			ret;
-
-	if ((ret = ohci_init(ohci)) < 0)
-		return ret;
-
-	ohci->num_ports = board->ports;
-	return 0;
-}
-
-static int
-ohci_at91_start (struct usb_hcd *hcd)
-{
-	struct ohci_hcd		*ohci = hcd_to_ohci (hcd);
-	int			ret;
-
-	if ((ret = ohci_run(ohci)) < 0) {
-		dev_err(hcd->self.controller, "can't start %s\n",
-			hcd->self.bus_name);
-		ohci_stop(hcd);
-		return ret;
-	}
-	return 0;
-}
-
 static void ohci_at91_usb_set_power(struct at91_usbh_data *pdata, int port, int enable)
 {
 	if (!valid_port(port))
@@ -281,7 +269,7 @@ static int ohci_at91_usb_get_power(struct at91_usbh_data *pdata, int port)
 static int ohci_at91_hub_status_data(struct usb_hcd *hcd, char *buf)
 {
 	struct at91_usbh_data *pdata = hcd->self.controller->platform_data;
-	int length = ohci_hub_status_data(hcd, buf);
+	int length = orig_ohci_hub_status_data(hcd, buf);
 	int port;
 
 	at91_for_each_port(port) {
@@ -359,7 +347,8 @@ static int ohci_at91_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
 		break;
 	}
 
-	ret = ohci_hub_control(hcd, typeReq, wValue, wIndex + 1, buf, wLength);
+	ret = orig_ohci_hub_control(hcd, typeReq, wValue, wIndex + 1,
+				buf, wLength);
 	if (ret)
 		goto out;
 
@@ -413,51 +402,6 @@ static int ohci_at91_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
 
 /*-------------------------------------------------------------------------*/
 
-static const struct hc_driver ohci_at91_hc_driver = {
-	.description =		hcd_name,
-	.product_desc =		"AT91 OHCI",
-	.hcd_priv_size =	sizeof(struct ohci_hcd),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq =			ohci_irq,
-	.flags =		HCD_USB11 | HCD_MEMORY,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.reset =		ohci_at91_reset,
-	.start =		ohci_at91_start,
-	.stop =			ohci_stop,
-	.shutdown =		ohci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue =		ohci_urb_enqueue,
-	.urb_dequeue =		ohci_urb_dequeue,
-	.endpoint_disable =	ohci_endpoint_disable,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number =	ohci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data =	ohci_at91_hub_status_data,
-	.hub_control =		ohci_at91_hub_control,
-#ifdef CONFIG_PM
-	.bus_suspend =		ohci_bus_suspend,
-	.bus_resume =		ohci_bus_resume,
-#endif
-	.start_port_reset =	ohci_start_port_reset,
-};
-
-/*-------------------------------------------------------------------------*/
-
 static irqreturn_t ohci_hcd_at91_overcurrent_irq(int irq, void *data)
 {
 	struct platform_device *pdev = data;
@@ -686,7 +630,11 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev, pm_message_t mesg)
 	 * REVISIT: some boards will be able to turn VBUS off...
 	 */
 	if (at91_suspend_entering_slow_clock()) {
-		ohci_usb_reset (ohci);
+		ohci->hc_control = ohci_readl(ohci, &ohci->regs->control);
+		ohci->hc_control &= OHCI_CTRL_RWC;
+		ohci_writel(ohci, ohci->hc_control, &ohci->regs->control);
+		ohci->rh_state = OHCI_RH_HALTED;
+
 		/* flush the writes */
 		(void) ohci_readl (ohci, &ohci->regs->control);
 		at91_stop_clock();
@@ -713,8 +661,6 @@ static int ohci_hcd_at91_drv_resume(struct platform_device *pdev)
 #define ohci_hcd_at91_drv_resume  NULL
 #endif
 
-MODULE_ALIAS("platform:at91_ohci");
-
 static struct platform_driver ohci_hcd_at91_driver = {
 	.probe		= ohci_hcd_at91_drv_probe,
 	.remove		= ohci_hcd_at91_drv_remove,
@@ -727,3 +673,40 @@ static struct platform_driver ohci_hcd_at91_driver = {
 		.of_match_table	= of_match_ptr(at91_ohci_dt_ids),
 	},
 };
+
+static int __init ohci_at91_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+	ohci_init_driver(&ohci_at91_hc_driver, NULL);
+
+	/*
+	 * The Atmel HW has some unusual quirks, which require Atmel-specific
+	 * workarounds. We override certain hc_driver functions here to
+	 * achieve that. We explicitly do not enhance ohci_driver_overrides to
+	 * allow this more easily, since this is an unusual case, and we don't
+	 * want to encourage others to override these functions by making it
+	 * too easy.
+	 */
+
+	orig_ohci_hub_control = ohci_at91_hc_driver.hub_control;
+	orig_ohci_hub_status_data = ohci_at91_hc_driver.hub_status_data;
+
+	ohci_at91_hc_driver.hub_status_data	= ohci_at91_hub_status_data;
+	ohci_at91_hc_driver.hub_control		= ohci_at91_hub_control;
+
+	return platform_driver_register(&ohci_hcd_at91_driver);
+}
+module_init(ohci_at91_init);
+
+static void __exit ohci_at91_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_at91_driver);
+}
+module_exit(ohci_at91_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:at91_ohci");
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 34ec156..b48c892 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1192,11 +1192,6 @@ MODULE_LICENSE ("GPL");
 #define EP93XX_PLATFORM_DRIVER	ohci_hcd_ep93xx_driver
 #endif
 
-#ifdef CONFIG_ARCH_AT91
-#include "ohci-at91.c"
-#define AT91_PLATFORM_DRIVER	ohci_hcd_at91_driver
-#endif
-
 #ifdef CONFIG_ARCH_LPC32XX
 #include "ohci-nxp.c"
 #define NXP_PLATFORM_DRIVER	usb_hcd_nxp_driver
@@ -1310,12 +1305,6 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_ep93xx;
 #endif
 
-#ifdef AT91_PLATFORM_DRIVER
-	retval = platform_driver_register(&AT91_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_at91;
-#endif
-
 #ifdef NXP_PLATFORM_DRIVER
 	retval = platform_driver_register(&NXP_PLATFORM_DRIVER);
 	if (retval < 0)
@@ -1339,10 +1328,6 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
  error_nxp:
 #endif
-#ifdef AT91_PLATFORM_DRIVER
-	platform_driver_unregister(&AT91_PLATFORM_DRIVER);
- error_at91:
-#endif
 #ifdef EP93XX_PLATFORM_DRIVER
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
  error_ep93xx:
@@ -1394,9 +1379,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef NXP_PLATFORM_DRIVER
 	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
 #endif
-#ifdef AT91_PLATFORM_DRIVER
-	platform_driver_unregister(&AT91_PLATFORM_DRIVER);
-#endif
 #ifdef EP93XX_PLATFORM_DRIVER
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
 #endif
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:19:30 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 14:49:30 +0530
Subject: [PATCH 6/6] USB: OHCI: make ohci-s3c2410 a separate driver
In-Reply-To: <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
 <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374484770-24531-7-git-send-email-manjunath.goudar@linaro.org>

Separate the Samsung OHCI S3CXXXX host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.12.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -Set non-standard fields in ohci_s3c2410_hc_driver manually, rather than
  relying on an expanded struct ohci_driver_overrides.
 -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
  relying on ohci_hub_control and hub_status_data being exported.

V3:
 -Kconfig wrong parentheses discription fixed.
 -ohci_setup() has been removed because it is called in .reset member
  of the ohci_hc_driver structure.

V4:
 - Removed extra space before the '='.
 - Moved  /* forward definitions */ line before the declarations of functions.
---
 drivers/usb/host/Kconfig        |    8 +++
 drivers/usb/host/Makefile       |    1 +
 drivers/usb/host/ohci-hcd.c     |   18 ------
 drivers/usb/host/ohci-s3c2410.c |  128 +++++++++++++++++----------------------
 4 files changed, 66 insertions(+), 89 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 693560a..795d14d 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR
           Enables support for the on-chip OHCI controller on
           ST SPEAr chips.
 
+config USB_OHCI_HCD_S3CXXXX
+        tristate "Support for S3CXXXX on-chip OHCI USB controller"
+        depends on USB_OHCI_HCD && (ARCH_S3C24XX || ARCH_S3C64XX)
+        default y
+        ---help---
+          Enables support for the on-chip OHCI controller on
+          S3CXXXX chips.
+
 config USB_OHCI_HCD_AT91
         tristate "Support for Atmel on-chip OHCI USB controller"
         depends on USB_OHCI_HCD && ARCH_AT91
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index a70b044..9dffe81 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_USB_OHCI_HCD_OMAP1)	+= ohci-omap.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP3)	+= ohci-omap3.o
 obj-$(CONFIG_USB_OHCI_HCD_SPEAR)	+= ohci-spear.o
 obj-$(CONFIG_USB_OHCI_HCD_AT91)	+= ohci-at91.o
+obj-$(CONFIG_USB_OHCI_HCD_S3CXXXX)	+= ohci-s3c2410.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index b48c892..b69a49e 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1177,11 +1177,6 @@ MODULE_LICENSE ("GPL");
 #define SA1111_DRIVER		ohci_hcd_sa1111_driver
 #endif
 
-#if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX)
-#include "ohci-s3c2410.c"
-#define S3C2410_PLATFORM_DRIVER	ohci_hcd_s3c2410_driver
-#endif
-
 #if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx)
 #include "ohci-pxa27x.c"
 #define PLATFORM_DRIVER		ohci_hcd_pxa27x_driver
@@ -1293,12 +1288,6 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_tmio;
 #endif
 
-#ifdef S3C2410_PLATFORM_DRIVER
-	retval = platform_driver_register(&S3C2410_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_s3c2410;
-#endif
-
 #ifdef EP93XX_PLATFORM_DRIVER
 	retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
 	if (retval < 0)
@@ -1332,10 +1321,6 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
  error_ep93xx:
 #endif
-#ifdef S3C2410_PLATFORM_DRIVER
-	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
- error_s3c2410:
-#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
  error_tmio:
@@ -1382,9 +1367,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef EP93XX_PLATFORM_DRIVER
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
 #endif
-#ifdef S3C2410_PLATFORM_DRIVER
-	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
-#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index e125770..48b5948 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -19,19 +19,36 @@
  * This file is licenced under the GPL.
 */
 
-#include <linux/platform_device.h>
 #include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
 #include <linux/platform_data/usb-ohci-s3c2410.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ohci.h"
+
 
 #define valid_port(idx) ((idx) == 1 || (idx) == 2)
 
 /* clock device associated with the hcd */
 
+
+#define DRIVER_DESC "OHCI S3CXXXX driver"
+
+static const char hcd_name[] = "ohci-s3cxxxx";
+
 static struct clk *clk;
 static struct clk *usb_clk;
 
 /* forward definitions */
 
+static int (*orig_ohci_hub_control)(struct usb_hcd  *hcd, u16 typeReq,
+			u16 wValue, u16 wIndex, char *buf, u16 wLength);
+static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
+
 static void s3c2410_hcd_oc(struct s3c2410_hcd_info *info, int port_oc);
 
 /* conversion functions */
@@ -93,7 +110,7 @@ ohci_s3c2410_hub_status_data(struct usb_hcd *hcd, char *buf)
 	int orig;
 	int portno;
 
-	orig  = ohci_hub_status_data(hcd, buf);
+	orig = orig_ohci_hub_status_data(hcd, buf);
 
 	if (info == NULL)
 		return orig;
@@ -164,7 +181,7 @@ static int ohci_s3c2410_hub_control(
 	 * process the request straight away and exit */
 
 	if (info == NULL) {
-		ret = ohci_hub_control(hcd, typeReq, wValue,
+		ret = orig_ohci_hub_control(hcd, typeReq, wValue,
 				       wIndex, buf, wLength);
 		goto out;
 	}
@@ -214,7 +231,7 @@ static int ohci_s3c2410_hub_control(
 		break;
 	}
 
-	ret = ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+	ret = orig_ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
 	if (ret)
 		goto out;
 
@@ -373,8 +390,6 @@ static int usb_hcd_s3c2410_probe(const struct hc_driver *driver,
 
 	s3c2410_start_hc(dev, hcd);
 
-	ohci_hcd_init(hcd_to_ohci(hcd));
-
 	retval = usb_add_hcd(hcd, dev->resource[1].start, 0);
 	if (retval != 0)
 		goto err_ioremap;
@@ -391,71 +406,7 @@ static int usb_hcd_s3c2410_probe(const struct hc_driver *driver,
 
 /*-------------------------------------------------------------------------*/
 
-static int
-ohci_s3c2410_start(struct usb_hcd *hcd)
-{
-	struct ohci_hcd	*ohci = hcd_to_ohci(hcd);
-	int ret;
-
-	ret = ohci_init(ohci);
-	if (ret < 0)
-		return ret;
-
-	ret = ohci_run(ohci);
-	if (ret < 0) {
-		dev_err(hcd->self.controller, "can't start %s\n",
-			hcd->self.bus_name);
-		ohci_stop(hcd);
-		return ret;
-	}
-
-	return 0;
-}
-
-
-static const struct hc_driver ohci_s3c2410_hc_driver = {
-	.description =		hcd_name,
-	.product_desc =		"S3C24XX OHCI",
-	.hcd_priv_size =	sizeof(struct ohci_hcd),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq =			ohci_irq,
-	.flags =		HCD_USB11 | HCD_MEMORY,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.start =		ohci_s3c2410_start,
-	.stop =			ohci_stop,
-	.shutdown =		ohci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue =		ohci_urb_enqueue,
-	.urb_dequeue =		ohci_urb_dequeue,
-	.endpoint_disable =	ohci_endpoint_disable,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number =	ohci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data =	ohci_s3c2410_hub_status_data,
-	.hub_control =		ohci_s3c2410_hub_control,
-#ifdef	CONFIG_PM
-	.bus_suspend =		ohci_bus_suspend,
-	.bus_resume =		ohci_bus_resume,
-#endif
-	.start_port_reset =	ohci_start_port_reset,
-};
-
-/* device driver */
+static struct hc_driver __read_mostly ohci_s3c2410_hc_driver;
 
 static int ohci_hcd_s3c2410_drv_probe(struct platform_device *pdev)
 {
@@ -532,4 +483,39 @@ static struct platform_driver ohci_hcd_s3c2410_driver = {
 	},
 };
 
+static int __init ohci_s3cxxxx_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+	ohci_init_driver(&ohci_s3c2410_hc_driver, NULL);
+
+	/*
+	 * The Samsung HW has some unusual quirks, which require
+	 * Sumsung-specific workarounds. We override certain hc_driver
+	 * functions here to achieve that. We explicitly do not enhance
+	 * ohci_driver_overrides to allow this more easily, since this
+	 * is an unusual case, and we don't want to encourage others to
+	 * override these functions by making it too easy.
+	 */
+
+	orig_ohci_hub_control = ohci_s3c2410_hc_driver.hub_control;
+	orig_ohci_hub_status_data = ohci_s3c2410_hc_driver.hub_status_data;
+
+	ohci_s3c2410_hc_driver.hub_status_data	= ohci_s3c2410_hub_status_data;
+	ohci_s3c2410_hc_driver.hub_control	= ohci_s3c2410_hub_control;
+
+	return platform_driver_register(&ohci_hcd_s3c2410_driver);
+}
+module_init(ohci_s3cxxxx_init);
+
+static void __exit ohci_s3cxxxx_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_s3c2410_driver);
+}
+module_exit(ohci_s3cxxxx_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:s3c2410-ohci");
-- 
1.7.9.5



From mark.rutland at arm.com  Mon Jul 22 05:21:38 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Jul 2013 10:21:38 +0100
Subject: [PATCH v5] clk: add MOXA ART SoCs clock driver
In-Reply-To: <1374221837-23773-1-git-send-email-jonas.jensen@gmail.com>
References: <1374221278-18204-1-git-send-email-jonas.jensen@gmail.com>
 <1374221837-23773-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <20130722092138.GB18731@e106331-lin.cambridge.arm.com>

On Fri, Jul 19, 2013 at 09:17:17AM +0100, Jonas Jensen wrote:
> This patch adds MOXA ART SoCs clock driver support.
> 
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
> ---
> 
> Notes:
>     Changes since v4:
>     
>     1. remove unnecessary header includes
>     
>     Applies to next-20130716
> 
>  .../bindings/clock/moxa,moxart-core-clock.txt      | 23 ++++++++
>  drivers/clk/Makefile                               |  1 +
>  drivers/clk/clk-moxart.c                           | 69 ++++++++++++++++++++++
>  3 files changed, 93 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
>  create mode 100644 drivers/clk/clk-moxart.c
> 
> diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
> new file mode 100644
> index 0000000..528c8b0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
> @@ -0,0 +1,23 @@
> +Device Tree Clock bindings for arch-moxart
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +MOXA ART SoCs allow to determine core clock frequencies by reading
> +a register.
> +
> +Required properties:
> +- compatible : Should be "moxa,moxart-core-clock"
> +- #clock-cells : Should be 0
> +- reg : Should contain registers location and length
> +- clock-output-names : Should be "coreclk"
> +
> +For example:
> +
> +	coreclk: core-clock at 98100000 {
> +		compatible = "moxa,moxart-core-clock";
> +		#clock-cells = <0>;
> +		reg = <0x98100000 0x34>;
> +		clock-output-names = "coreclk";
> +	};
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 4038c2b..933622f 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_COMMON_CLK)	+= clk-composite.o
>  
>  # SoCs specific
>  obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
> +obj-$(CONFIG_ARCH_MOXART)	+= clk-moxart.o
>  obj-$(CONFIG_ARCH_NOMADIK)	+= clk-nomadik.o
>  obj-$(CONFIG_ARCH_HIGHBANK)	+= clk-highbank.o
>  obj-$(CONFIG_ARCH_NSPIRE)	+= clk-nspire.o
> diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
> new file mode 100644
> index 0000000..5559371
> --- /dev/null
> +++ b/drivers/clk/clk-moxart.c
> @@ -0,0 +1,69 @@
> +/*
> + * MOXA ART SoCs clock driver.
> + *
> + * Copyright (C) 2013 Jonas Jensen
> + *
> + * Jonas Jensen <jonas.jensen at gmail.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/io.h>
> +#include <linux/of_address.h>
> +#include <linux/clkdev.h>
> +
> +void __init moxart_of_clk_init(struct device_node *node)
> +{
> +	static void __iomem *base;
> +	struct clk *clk;
> +	unsigned long rate;
> +	unsigned int mul, val, div;
> +	const char *name;
> +
> +	base = of_iomap(node, 0);
> +	if (IS_ERR(base))
> +		panic("%s: of_iomap failed\n", node->full_name);

As far as I'm aware, of_iomap returns NULL, not an ERR_PTR value.

Also, is it necessary to panic() ? In v1 of the patch you used pr_err...

Thanks,
Mark.

> +
> +	mul = (readl(base + 0x30) >> 3) & 0x1ff;
> +	val = (readl(base + 0x0c) >> 4) & 0x7;
> +
> +	switch (val) {
> +	case 1:
> +		div = 3;
> +		break;
> +	case 2:
> +		div = 4;
> +		break;
> +	case 3:
> +		div = 6;
> +		break;
> +	case 4:
> +		div = 8;
> +		break;
> +	default:
> +		div = 2;
> +		break;
> +	}
> +
> +	/*
> +	 * the rate calculation below is only tested and proven
> +	 * to be true for UC-7112-LX
> +	 *
> +	 * UC-7112-LX: mul=80 val=0
> +	 *
> +	 * to support other moxart SoC hardware, this may need
> +	 * a change, though it's possible it works there too
> +	 */
> +	rate = (mul * 1200000 / div);
> +
> +	of_property_read_string(node, "clock-output-names", &name);
> +	clk = clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
> +	clk_register_clkdev(clk, NULL, name);
> +	of_clk_add_provider(node, of_clk_src_simple_get, clk);
> +
> +	iounmap(base);
> +}
> +CLK_OF_DECLARE(moxart_core_clock, "moxa,moxart-core-clock", moxart_of_clk_init);
> -- 
> 1.8.2.1
> 
> 


From rogerq at ti.com  Mon Jul 22 05:30:20 2013
From: rogerq at ti.com (Roger Quadros)
Date: Mon, 22 Jul 2013 12:30:20 +0300
Subject: linux-3.11-rc1: Internal error: Oops - undefined instruction: 0 [#1]
 SMP ARM on OMAP3/AM335x
Message-ID: <51ECFBAC.7090900@ti.com>

Hi,

I observe the following problem on booting v3.11-rc1 on OMAP3 beagle board.

[    5.888946] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[    5.896057] Modules linked in:
[    5.899322] CPU: 0 PID: 9 Comm: rcu_sched Not tainted 3.11.0-rc2-00001-g1ea701a #876
[    5.907501] task: ce0720c0 ti: ce07a000 task.ti: ce07a000
[    5.913208] PC is at check_and_switch_context+0x130/0x4dc
[    5.918914] LR is at check_and_switch_context+0xd8/0x4dc
[    5.924530] pc : [<c0023d1c>]    lr : [<c0023cc4>]    psr: 40000193
[    5.924530] sp : ce07bd70  ip : 00000000  fp : c078d7b0
[    5.936645] r10: ce5084c0  r9 : 00000000  r8 : 00000201
[    5.942169] r7 : 00000000  r6 : 00000000  r5 : 00000000  r4 : c081de04
[    5.949066] r3 : 00000000  r2 : d0091010  r1 : 00000000  r0 : 00000001
[    5.955963] Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    5.963775] Control: 10c5387d  Table: 80004019  DAC: 00000017
[    5.969848] Process rcu_sched (pid: 9, stack limit = 0xce07a240)
[    5.976165] Stack: (0xce07bd70 to 0xce07c000)
[    5.980773] bd60:                                     c078c990 961b12b4 00000000 ce508658
[    5.989440] bd80: c0780510 20000193 00000200 00000000 c078c944 c0780510 c0780518 ce5084c0
[    5.998077] bda0: c0f90fc0 ce425440 ce5084c0 c078fd08 ce0720c0 ce184a40 ce07a000 c0f90fc0
[    6.006713] bdc0: ce07be74 c05065bc c081fe24 ce0720c0 ce072558 00000000 5efa46d6 00000001
[    6.015350] bde0: 00000000 c050331c c0782fc0 c0782fc0 c0782fc0 c0782fc0 0007735a 00000000
[    6.023986] be00: c0782fc0 c0782fc0 00000000 00000000 60000193 00000498 00000000 c08304c0
[    6.032623] be20: a0000113 c00531b8 ce07be78 ce07a000 ce0720c0 c05080dc 00000001 c07860c0
[    6.041259] be40: ce07bf00 ce07a000 00000064 c0097bfc a0000113 ce07be7c c08304c0 ffff8d19
[    6.049926] be60: c08304c0 c07860c0 ce07bf00 ce07a000 00000064 c050331c a0000113 c08305b8
[    6.058563] be80: c08305b8 ffff8d19 c08304c0 c005329c ce0720c0 ffffffff ffffffff 00000000
[    6.067199] bea0: 00000000 00000000 00000000 00000000 c083150c 00000000 00000000 c0663d9c
[    6.075836] bec0: c078d1e0 ce07a000 c07e4c50 c078d1e0 00000001 00000002 c07e4b40 c00aed80
[    6.084472] bee0: 00000000 ce07bf00 c07e4cb8 c07e4c00 00000001 00000000 ce0720c0 c006749c
[    6.093109] bf00: c07e4c70 c07e4c70 60000153 ce04be8c 00000000 c07e4b40 c00aeacc 00000000
[    6.101745] bf20: 00000000 00000000 00000000 c0066b74 00000001 00000000 00000000 c07e4b40
[    6.110382] bf40: 00000000 00000000 dead4ead ffffffff ffffffff c08323fc 00000000 00000000
[    6.119049] bf60: c0662544 ce07bf64 ce07bf64 00000000 00000000 dead4ead ffffffff ffffffff
[    6.127685] bf80: c08323fc 00000000 00000000 c0662544 ce07bf90 ce07bf90 ce072a80 ce04be8c
[    6.136322] bfa0: c0066ad0 00000000 00000000 c0013ea8 00000000 00000000 00000000 00000000
[    6.144958] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    6.153594] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 01ffdf08 20ffde24
[    6.162261] [<c0023d1c>] (check_and_switch_context+0x130/0x4dc) from [<c05065bc>] (__schedule+0x334/0x7f4)
[    6.172454] [<c05065bc>] (__schedule+0x334/0x7f4) from [<c050331c>] (schedule_timeout+0x124/0x214)
[    6.181945] [<c050331c>] (schedule_timeout+0x124/0x214) from [<c00aed80>] (rcu_gp_kthread+0x2b4/0x52c)
[    6.191772] [<c00aed80>] (rcu_gp_kthread+0x2b4/0x52c) from [<c0066b74>] (kthread+0xa4/0xb0)
[    6.200622] [<c0066b74>] (kthread+0xa4/0xb0) from [<c0013ea8>] (ret_from_fork+0x14/0x2c)
[    6.209167] Code: e3120602 1e083f13 ee073f9a ee073f95 (ee083f33) 
[    6.215606] ---[ end trace bad27cd834df5662 ]---

I'm suspecting the issue to be caused by the below commit

commit 93dc68876b608da041fe40ed39424b0fcd5aa2fb
Author: Catalin Marinas <catalin.marinas at arm.com>
Date:   Tue Mar 26 23:35:04 2013 +0100

    ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations)

It seems that in check_and_switch_context(), we call dummy_flush_tlb_a15_erratum() which an A15 instruction
without A15 revision check.

cheers,
-roger


From manjunath.goudar at linaro.org  Mon Jul 22 05:32:35 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 15:02:35 +0530
Subject: [PATCH 00/11] USB: OHCI:Properly handle ohci_suspend()routine in bus
 glue
In-Reply-To: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>

Suspend scenario in case of ohci bus glue was not properly handled as
it was not suspending generic part of ohci controller. Calling
explicitly the ohci_suspend()routine will ensure proper handling
of suspend scenario.

V2:
 -Incase ohci_suspend() fails, return right away without executing further.

V3:
 -New patch 1/11 added, for generic ohci-hcd suspend code.

V4:
 -Properly aligned "do_wakeup" and "ret" variables.

Manjunath Goudar (11):
  USB: OHCI: Properly handle OHCI controller suspend
  USB: OHCI: Properly handle ohci-at91 suspend
  USB: OHCI: Properly handle ohci-s3c2410 suspend
  USB: OHCI: Properly handle ohci-da8xx suspend
  USB: OHCI: Properly handle ohci-ep93xx suspend
  USB: OHCI: Properly handle ohci-exynos suspend
  USB: OHCI: Properly handle ohci-omap suspend
  USB: OHCI: Properly handle ohci-platform suspend
  USB: OHCI: Properly handle ohci-pxa27x suspend
  USB: OHCI: Properly handle ohci-sm501 suspend
  USB: OHCI: Properly handle ohci-spear suspend

 drivers/usb/host/ohci-at91.c     |   10 ++++++++--
 drivers/usb/host/ohci-da8xx.c    |   15 +++++++++++----
 drivers/usb/host/ohci-ep93xx.c   |    9 ++++++++-
 drivers/usb/host/ohci-exynos.c   |   20 +++++---------------
 drivers/usb/host/ohci-hcd.c      |    9 ++++++++-
 drivers/usb/host/ohci-omap.c     |   13 ++++++++++---
 drivers/usb/host/ohci-platform.c |    9 ++++++++-
 drivers/usb/host/ohci-pxa27x.c   |    8 +++++++-
 drivers/usb/host/ohci-s3c2410.c  |   19 ++++---------------
 drivers/usb/host/ohci-sm501.c    |   11 +++++++++--
 drivers/usb/host/ohci-spear.c    |   12 +++++++++---
 11 files changed, 87 insertions(+), 48 deletions(-)

-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:32:36 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 15:02:36 +0530
Subject: [PATCH 01/11] USB: OHCI: Properly handle OHCI controller suspend
In-Reply-To: <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374485566-3997-2-git-send-email-manjunath.goudar@linaro.org>

Suspend scenario in case of OHCI was not properly
handled in ochi_suspend()routine. This does proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V3: New patch.

V4: No change.
---
 drivers/usb/host/ohci-hcd.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index b69a49e..f3dcaa2 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1034,6 +1034,7 @@ int ohci_suspend(struct usb_hcd *hcd, bool do_wakeup)
 {
 	struct ohci_hcd	*ohci = hcd_to_ohci (hcd);
 	unsigned long	flags;
+	int		rc = 0;
 
 	/* Disable irq emission and mark HW unaccessible. Use
 	 * the spinlock to properly synchronize with possible pending
@@ -1046,7 +1047,13 @@ int ohci_suspend(struct usb_hcd *hcd, bool do_wakeup)
 	clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
 	spin_unlock_irqrestore (&ohci->lock, flags);
 
-	return 0;
+	synchronize_irq(hcd->irq);
+
+	if (do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+		ohci_resume(hcd, false);
+		rc = -EBUSY;
+	}
+	return rc;
 }
 EXPORT_SYMBOL_GPL(ohci_suspend);
 
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:32:37 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 15:02:37 +0530
Subject: [PATCH 02/11] USB: OHCI: Properly handle ohci-at91 suspend
In-Reply-To: <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374485566-3997-3-git-send-email-manjunath.goudar@linaro.org>

Suspend scenario in case of ohci-at91 glue was not properly
handled as it was not suspending generic part of ohci controller.
Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
  -Incase ohci_suspend() fails, return right away without executing further.

V3:
  -Aligned variable "do_wakeup" and "ret".

V4:
  - No change.
---
 drivers/usb/host/ohci-at91.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 08e28eb..008645c 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -618,8 +618,14 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev, pm_message_t mesg)
 {
 	struct usb_hcd	*hcd = platform_get_drvdata(pdev);
 	struct ohci_hcd	*ohci = hcd_to_ohci(hcd);
+	bool		do_wakeup = device_may_wakeup(&pdev->dev);
+	int		ret;
 
-	if (device_may_wakeup(&pdev->dev))
+	ret = ohci_suspend(hcd, do_wakeup);
+	if (ret)
+		return ret;
+
+	if (do_wakeup)
 		enable_irq_wake(hcd->irq);
 
 	/*
@@ -640,7 +646,7 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev, pm_message_t mesg)
 		at91_stop_clock();
 	}
 
-	return 0;
+	return ret;
 }
 
 static int ohci_hcd_at91_drv_resume(struct platform_device *pdev)
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:32:38 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 15:02:38 +0530
Subject: [PATCH 03/11] USB: OHCI: Properly handle ohci-s3c2410 suspend
In-Reply-To: <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374485566-3997-4-git-send-email-manjunath.goudar@linaro.org>

Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -Incase ohci_suspend() fails, return right away without
  executing further.
V3:
 -rid of unwanted code from ohci_hcd_s3c2410_drv_suspend()
  which already ohci_suspend() does it.

V4:
 -The do_wakeup variable alignment is removed.
---
 drivers/usb/host/ohci-s3c2410.c |   19 ++++---------------
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index 48b5948..d4cdf9c 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -427,26 +427,15 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device *dev)
 	struct usb_hcd *hcd = dev_get_drvdata(dev);
 	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
 	struct platform_device *pdev = to_platform_device(dev);
+	bool do_wakeup = device_may_wakeup(dev);
 	unsigned long flags;
 	int rc = 0;
 
-	/*
-	 * Root hub was already suspended. Disable irq emission and
-	 * mark HW unaccessible, bail out if RH has been resumed. Use
-	 * the spinlock to properly synchronize with possible pending
-	 * RH suspend or resume activity.
-	 */
-	spin_lock_irqsave(&ohci->lock, flags);
-	if (ohci->rh_state != OHCI_RH_SUSPENDED) {
-		rc = -EINVAL;
-		goto bail;
-	}
-
-	clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
+	rc = ohci_suspend(hcd, do_wakeup);
+	if (rc)
+		return rc;
 
 	s3c2410_stop_hc(pdev);
-bail:
-	spin_unlock_irqrestore(&ohci->lock, flags);
 
 	return rc;
 }
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:32:39 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 15:02:39 +0530
Subject: [PATCH 04/11] USB: OHCI: Properly handle ohci-da8xx suspend
In-Reply-To: <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374485566-3997-5-git-send-email-manjunath.goudar@linaro.org>

Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -Incase ohci_suspend() fails, return right away without
  executing further.

V3:
 -Aligned variable "do_wakeup" and "ret".
 -pdev->dev.power.power_state stuff has been removed.

V4:
 -Properly aligned "do_wakeup" and "ret" variable.
---
 drivers/usb/host/ohci-da8xx.c |   15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 6aaa9c9..c649a35 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -406,19 +406,26 @@ static int ohci_hcd_da8xx_drv_remove(struct platform_device *dev)
 }
 
 #ifdef CONFIG_PM
-static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t message)
+static int ohci_da8xx_suspend(struct platform_device *pdev,
+		pm_message_t message)
 {
-	struct usb_hcd	*hcd	= platform_get_drvdata(dev);
+	struct usb_hcd	*hcd	= platform_get_drvdata(pdev);
 	struct ohci_hcd	*ohci	= hcd_to_ohci(hcd);
+	bool		do_wakeup	= device_may_wakeup(&pdev->dev);
+	int		ret;
 
 	if (time_before(jiffies, ohci->next_statechange))
 		msleep(5);
 	ohci->next_statechange = jiffies;
 
+	ret = ohci_suspend(hcd, do_wakeup);
+	if (ret)
+		return ret;
+
 	ohci_da8xx_clock(0);
 	hcd->state = HC_STATE_SUSPENDED;
-	dev->dev.power.power_state = PMSG_SUSPEND;
-	return 0;
+
+	return ret;
 }
 
 static int ohci_da8xx_resume(struct platform_device *dev)
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:32:40 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 15:02:40 +0530
Subject: [PATCH 05/11] USB: OHCI: Properly handle ohci-ep93xx suspend
In-Reply-To: <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374485566-3997-6-git-send-email-manjunath.goudar@linaro.org>

Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -Incase ohci_suspend() fails, return right away without
  executing further.
V3:
 -Aligned variable "do_wakeup" and "ret".
V4:
 -The do_wakeup and ret variable alignment is removed.
---
 drivers/usb/host/ohci-ep93xx.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index 8704e9f..f0aaa48 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -174,13 +174,20 @@ static int ohci_hcd_ep93xx_drv_suspend(struct platform_device *pdev, pm_message_
 {
 	struct usb_hcd *hcd = platform_get_drvdata(pdev);
 	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+	bool do_wakeup = device_may_wakeup(&pdev->dev);
+	int ret;
 
 	if (time_before(jiffies, ohci->next_statechange))
 		msleep(5);
 	ohci->next_statechange = jiffies;
 
+	ret = ohci_suspend(hcd, do_wakeup);
+	if (ret)
+		return ret;
+
 	ep93xx_stop_hc(&pdev->dev);
-	return 0;
+
+	return ret;
 }
 
 static int ohci_hcd_ep93xx_drv_resume(struct platform_device *pdev)
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:32:41 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 15:02:41 +0530
Subject: [PATCH 06/11] USB: OHCI: Properly handle ohci-exynos suspend
In-Reply-To: <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374485566-3997-7-git-send-email-manjunath.goudar@linaro.org>

Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in exynos_ohci_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -Incase ohci_suspend() fails, return right away without
  executing further.

V3:
 -rid of unwanted code from ohci_hcd_s3c2410_drv_suspend() which already
  ohci_suspend() does it.
 -Aligned variable "do_wakeup" and "ret".

V4:
 -The do_wakeup and rc variable alignment is removed.
---
 drivers/usb/host/ohci-exynos.c |   20 +++++---------------
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index ae6068d..17de3dd 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -203,24 +203,15 @@ static int exynos_ohci_suspend(struct device *dev)
 	struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
 	struct platform_device *pdev = to_platform_device(dev);
+	bool do_wakeup = device_may_wakeup(dev);
 	unsigned long flags;
 	int rc = 0;
 
-	/*
-	 * Root hub was already suspended. Disable irq emission and
-	 * mark HW unaccessible, bail out if RH has been resumed. Use
-	 * the spinlock to properly synchronize with possible pending
-	 * RH suspend or resume activity.
-	 */
-	spin_lock_irqsave(&ohci->lock, flags);
-	if (ohci->rh_state != OHCI_RH_SUSPENDED &&
-			ohci->rh_state != OHCI_RH_HALTED) {
-		rc = -EINVAL;
-		goto fail;
-	}
-
-	clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
+	rc = ohci_suspend(hcd, do_wakeup);
+	if (rc)
+		return rc;
 
+	spin_lock_irqsave(&ohci->lock, flags);
 	if (exynos_ohci->otg)
 		exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
 
@@ -228,7 +219,6 @@ static int exynos_ohci_suspend(struct device *dev)
 
 	clk_disable_unprepare(exynos_ohci->clk);
 
-fail:
 	spin_unlock_irqrestore(&ohci->lock, flags);
 
 	return rc;
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:32:43 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 15:02:43 +0530
Subject: [PATCH 08/11] USB: OHCI: Properly handle ohci-platform suspend
In-Reply-To: <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374485566-3997-9-git-send-email-manjunath.goudar@linaro.org>

Suspend scenario in case of ohci-platform glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_platform_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -Incase ohci_suspend() fails, return right away without
  executing further.

V3:
 -Aligned variable "do_wakeup" and "ret".

V4:
 -The do_wakeup and ret variable alignment is removed.
---
 drivers/usb/host/ohci-platform.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index bc30475..b4a8784 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -139,14 +139,21 @@ static int ohci_platform_remove(struct platform_device *dev)
 
 static int ohci_platform_suspend(struct device *dev)
 {
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
 	struct usb_ohci_pdata *pdata = dev->platform_data;
 	struct platform_device *pdev =
 		container_of(dev, struct platform_device, dev);
+	bool do_wakeup = device_may_wakeup(dev);
+	int ret;
+
+	ret = ohci_suspend(hcd, do_wakeup);
+	if (ret)
+		return ret;
 
 	if (pdata->power_suspend)
 		pdata->power_suspend(pdev);
 
-	return 0;
+	return ret;
 }
 
 static int ohci_platform_resume(struct device *dev)
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:32:44 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 15:02:44 +0530
Subject: [PATCH 09/11] USB: OHCI: Properly handle ohci-pxa27x suspend
In-Reply-To: <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374485566-3997-10-git-send-email-manjunath.goudar@linaro.org>

Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_pxa27x_drv_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -Incase ohci_suspend() fails, return right away without
  executing further.
V3:
 -Aligned variable "do_wakeup" and "ret".

V4:
 -The do_wakeup and ret variable alignment is removed.
---
 drivers/usb/host/ohci-pxa27x.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 3a9c01d..5fb91f1 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -564,13 +564,19 @@ static int ohci_hcd_pxa27x_drv_suspend(struct device *dev)
 {
 	struct usb_hcd *hcd = dev_get_drvdata(dev);
 	struct pxa27x_ohci *ohci = to_pxa27x_ohci(hcd);
+	bool do_wakeup = device_may_wakeup(dev);
+	int ret;
 
 	if (time_before(jiffies, ohci->ohci.next_statechange))
 		msleep(5);
 	ohci->ohci.next_statechange = jiffies;
 
+	ret = ohci_suspend(hcd, do_wakeup);
+	if (ret)
+		return ret;
+
 	pxa27x_stop_hc(ohci, dev);
-	return 0;
+	return ret;
 }
 
 static int ohci_hcd_pxa27x_drv_resume(struct device *dev)
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:32:42 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 15:02:42 +0530
Subject: [PATCH 07/11] USB: OHCI: Properly handle ohci-omap suspend
In-Reply-To: <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374485566-3997-8-git-send-email-manjunath.goudar@linaro.org>

Suspend scenario in case of ohci-omap glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_omap_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -Incase ohci_suspend() fails, return right away without
  executing further.

V3:
 -Aligned variable "do_wakeup" and "ret".

V4:
 -The do_wakeup and ret variable alignment is removed.
---
 drivers/usb/host/ohci-omap.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 8149ef0..d13fb4f 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -431,16 +431,23 @@ static int ohci_hcd_omap_drv_remove(struct platform_device *dev)
 
 #ifdef	CONFIG_PM
 
-static int ohci_omap_suspend(struct platform_device *dev, pm_message_t message)
+static int ohci_omap_suspend(struct platform_device *pdev, pm_message_t message)
 {
-	struct ohci_hcd	*ohci = hcd_to_ohci(platform_get_drvdata(dev));
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
+	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+	bool do_wakeup = device_may_wakeup(&pdev->dev);
+	int ret;
 
 	if (time_before(jiffies, ohci->next_statechange))
 		msleep(5);
 	ohci->next_statechange = jiffies;
 
+	ret = ohci_suspend(hcd, do_wakeup);
+	if (ret)
+		return ret;
+
 	omap_ohci_clock_power(0);
-	return 0;
+	return ret;
 }
 
 static int ohci_omap_resume(struct platform_device *dev)
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:32:45 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 15:02:45 +0530
Subject: [PATCH 10/11] USB: OHCI: Properly handle ohci-sm501 suspend
In-Reply-To: <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374485566-3997-11-git-send-email-manjunath.goudar@linaro.org>

Suspend scenario in case of ohci-sm501 glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_sm501_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -Incase ohci_suspend() fails, return right away without
  executing further.
V3:
 -Aligned variable "do_wakeup" and "ret".

-V4:
 -The do_wakeup and ret variable alignment is removed.
---
 drivers/usb/host/ohci-sm501.c |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c
index d479d5d..2a5de5f 100644
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -216,14 +216,21 @@ static int ohci_hcd_sm501_drv_remove(struct platform_device *pdev)
 static int ohci_sm501_suspend(struct platform_device *pdev, pm_message_t msg)
 {
 	struct device *dev = &pdev->dev;
-	struct ohci_hcd	*ohci = hcd_to_ohci(platform_get_drvdata(pdev));
+	struct usb_hcd  *hcd = platform_get_drvdata(pdev);
+	struct ohci_hcd	*ohci = hcd_to_ohci(hcd);
+	bool do_wakeup = device_may_wakeup(dev);
+	int ret;
 
 	if (time_before(jiffies, ohci->next_statechange))
 		msleep(5);
 	ohci->next_statechange = jiffies;
 
+	ret = ohci_suspend(hcd, do_wakeup);
+	if (ret)
+		return ret;
+
 	sm501_unit_power(dev->parent, SM501_GATE_USB_HOST, 0);
-	return 0;
+	return ret;
 }
 
 static int ohci_sm501_resume(struct platform_device *pdev)
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:32:46 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 15:02:46 +0530
Subject: [PATCH 11/11] USB: OHCI: Properly handle ohci-spear suspend
In-Reply-To: <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374485566-3997-12-git-send-email-manjunath.goudar@linaro.org>

Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenario.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -Incase ohci_suspend() fails, return right away without
  executing further.
V3:
 -Aligned variable "do_wakeup" and "ret".

V4:
 -The do_wakeup and ret variable alignment is removed.
---
 drivers/usb/host/ohci-spear.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
index 31ff3fc..41148f8 100644
--- a/drivers/usb/host/ohci-spear.c
+++ b/drivers/usb/host/ohci-spear.c
@@ -130,20 +130,26 @@ static int spear_ohci_hcd_drv_remove(struct platform_device *pdev)
 }
 
 #if defined(CONFIG_PM)
-static int spear_ohci_hcd_drv_suspend(struct platform_device *dev,
+static int spear_ohci_hcd_drv_suspend(struct platform_device *pdev,
 		pm_message_t message)
 {
-	struct usb_hcd *hcd = platform_get_drvdata(dev);
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
 	struct ohci_hcd	*ohci = hcd_to_ohci(hcd);
 	struct spear_ohci *sohci_p = to_spear_ohci(hcd);
+	bool do_wakeup = device_may_wakeup(&pdev->dev);
+	int ret;
 
 	if (time_before(jiffies, ohci->next_statechange))
 		msleep(5);
 	ohci->next_statechange = jiffies;
 
+	ret = ohci_suspend(hcd, do_wakeup);
+	if (ret)
+		return ret;
+
 	clk_disable_unprepare(sohci_p->clk);
 
-	return 0;
+	return ret;
 }
 
 static int spear_ohci_hcd_drv_resume(struct platform_device *dev)
-- 
1.7.9.5



From b.zolnierkie at samsung.com  Mon Jul 22 05:35:10 2013
From: b.zolnierkie at samsung.com (Bartlomiej Zolnierkiewicz)
Date: Mon, 22 Jul 2013 11:35:10 +0200
Subject: [PATCH 2/4] ARM: exynos: cpuidle: Use the common cpuidle
 register routine
In-Reply-To: <51ECB6DE.9060701@linaro.org>
References: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
 <4097491.3y6BBYmzze@amdc1032> <51ECB6DE.9060701@linaro.org>
Message-ID: <1445208.tM84QonONK@amdc1032>

On Monday, July 22, 2013 06:36:46 AM Daniel Lezcano wrote:
> On 07/19/2013 06:03 PM, Bartlomiej Zolnierkiewicz wrote:
> > 
> > Hi,
> > 
> > On Thursday, July 18, 2013 02:54:28 PM Daniel Lezcano wrote:
> >> Now we have the same routine than the one handled by the cpuidle framework.
> > 
> > Small nitpick:
> > 
> > To be exact the routine is not the same, on error cpuidle_register() does
> > complete unregister operation of the cpuidle driver, exynos4_init_cpuidle()
> > just stops the registration procedure. 
> > 
> > The change itself is okay but the patch description could be better.
> 
> Ok, I will fix the changelog.
> 
> > Anyway all patches (#1-4) look fine to me. Thanks for this work.
> 
> Thanks for the review. I assume it is an acked-by right ?

Yes.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> > Best regards,
> 
> Kukjin,
> 
> shall I take the patchset in my tree ?
> 
> Thanks
>   -- Daniel
> 
> > --
> > Bartlomiej Zolnierkiewicz
> > Samsung R&D Institute Poland
> > Samsung Electronics
> >  
> >> Let's use it.
> >>
> >> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> >> ---
> >>  arch/arm/mach-exynos/cpuidle.c |   24 +-----------------------
> >>  1 file changed, 1 insertion(+), 23 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
> >> index cc4b097..d8fc1a2 100644
> >> --- a/arch/arm/mach-exynos/cpuidle.c
> >> +++ b/arch/arm/mach-exynos/cpuidle.c
> >> @@ -41,8 +41,6 @@ static int exynos4_enter_lowpower(struct cpuidle_device *dev,
> >>  				struct cpuidle_driver *drv,
> >>  				int index);
> >>  
> >> -static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
> >> -
> >>  static struct cpuidle_driver exynos4_idle_driver = {
> >>  	.name			= "exynos4_idle",
> >>  	.owner			= THIS_MODULE,
> >> @@ -188,29 +186,9 @@ static void __init exynos5_core_down_clk(void)
> >>  
> >>  static int __init exynos4_init_cpuidle(void)
> >>  {
> >> -	int cpu_id, ret;
> >> -	struct cpuidle_device *device;
> >> -
> >>  	if (soc_is_exynos5250())
> >>  		exynos5_core_down_clk();
> >>  
> >> -	ret = cpuidle_register_driver(&exynos4_idle_driver);
> >> -	if (ret) {
> >> -		printk(KERN_ERR "CPUidle failed to register driver\n");
> >> -		return ret;
> >> -	}
> >> -
> >> -	for_each_online_cpu(cpu_id) {
> >> -		device = &per_cpu(exynos4_cpuidle_device, cpu_id);
> >> -		device->cpu = cpu_id;
> >> -
> >> -		ret = cpuidle_register_device(device);
> >> -		if (ret) {
> >> -			printk(KERN_ERR "CPUidle register device failed\n");
> >> -			return ret;
> >> -		}
> >> -	}
> >> -
> >> -	return 0;
> >> +	return cpuidle_register(&exynos4_idle_driver, NULL);
> >>  }
> >>  device_initcall(exynos4_init_cpuidle);



From nsekhar at ti.com  Mon Jul 22 05:37:16 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 22 Jul 2013 15:07:16 +0530
Subject: [PATCH v3 1/2] media: i2c: adv7343: make the platform data members
 as array
In-Reply-To: <1374301266-26726-2-git-send-email-prabhakar.csengg@gmail.com>
References: <1374301266-26726-1-git-send-email-prabhakar.csengg@gmail.com>
 <1374301266-26726-2-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <51ECFD4C.8020407@ti.com>

On Saturday 20 July 2013 11:51 AM, Lad, Prabhakar wrote:
> From: "Lad, Prabhakar" <prabhakar.csengg at gmail.com>
> 
> This patch makes the platform data members as array wherever
> possible, so as this makes easier while collecting the data
> in DT case and read the entire array at once.
> 
> This patch also makes appropriate changes to board-da850-evm.c
> 
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> Cc: Sekhar Nori <nsekhar at ti.com>
> Cc: linux-arm-kernel at lists.infradead.org

For the board-da850-evm.c change:

Acked-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar



From tomi.valkeinen at ti.com  Mon Jul 22 05:40:13 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Mon, 22 Jul 2013 12:40:13 +0300
Subject: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c
In-Reply-To: <20130708142103.GX21614@n2100.arm.linux.org.uk>
References: <20130517191304.468.73487.stgit@localhost>
 <20130517191751.468.89202.stgit@localhost>
 <20130520095447.GR21614@n2100.arm.linux.org.uk>
 <20130706131057.GU21614@n2100.arm.linux.org.uk>
 <20130706133627.GV21614@n2100.arm.linux.org.uk>
 <20130708093410.GT5523@atomide.com>
 <20130708142103.GX21614@n2100.arm.linux.org.uk>
Message-ID: <51ECFDFD.60102@ti.com>

On 08/07/13 17:21, Russell King - ARM Linux wrote:

> Also looks like the nonfunctional video stuff is even more nonfunctional
> than usual:
> 
> omapdss DSI error: can't get VDDS_DSI regulator
> omapdss HDMI error: can't get VDDA_HDMI_DAC regulator

Those should be followed by "...requests probe deferral", and the driver
is probed again later.

The log
http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=946
shows "taal display2: panel revision e3.83.7d" which hints that the
panel (and DSS) was initialized properly.

Those error prints should probably be tuned down a bit now that the
driver uses probe deferral.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130722/b1fe83e3/attachment.sig>

From manjunath.goudar at linaro.org  Mon Jul 22 05:41:50 2013
From: manjunath.goudar at linaro.org (manjunath)
Date: Mon, 22 Jul 2013 15:11:50 +0530
Subject: [PATCH  V4 0/6] USB: OHCI: more bus glues as separate modules
In-Reply-To: <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
 <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <51ECFE5E.20300@linaro.org>

On Monday 22 July 2013 02:49 PM, Manjunath Goudar wrote:
> These patches are for separating the SOC On-Chip ohci host controller
> from ohci-hcd host code into its own driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.12.
>
> V2:
>    In patch 5/6 and 6/6:
>    -Set non-standard fields in hc_driver manually, rather than
>     relying on an expanded struct ohci_driver_overrides.
>    -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
>     relying on ohci_hub_control and hub_status_data being exported.
>
>    In patch 1/6 to 4/6
>    -ohci_setup() has been removed because it is called in .reset member
>     of the ohci_hc_driver structure.
>
> V3:
>   In patch 5/6 and 6/6:
>   -ohci_setup() has been removed because it is called in .reset member
>    of the ohci_hc_driver structure.
>
>   In patch 5/6:
>   -The ohci_restart() function is not required in  current scenario,
>    only discarding connection state of integrated transceivers is sufficient,
>    for this directly handling ohci->hc_control.
>
>   In patch 2/6 :
>   -rewritten if (config->otg || config->rwc) block statements into
>    two separate 'if blocks' to handle below scenarios
>    1. config->otg set scenario.
>    2. if any of these (config->otg, config->rwc) are set, this
>       scenario should be handled only after ohci_setup()
>
>   In patch 1/6 and 4/6:
>    No change.
>
> V4:
>   In patch 1/6 and 4/6:
>    No change.
>   
>   In patch 2/6 :
>   -usb_remove_hcd() function is required a valid clock that is what
>    omap_ohci_clock_power(0) is called after hcd shutdown.
>
>   In patch 3/6 :
>   -V3 modification revert back, only ohci->regs setting write()
>    function has been removed because ohci->regs doesn't get set until
>    usb_add_hcd.
>
>   In patch 5/6 :
>   - Removed extra space after "tristate".
>   - Removed extra space between function name  and '(' characters.
>   - MODULE_ALIAS line moved to last statement of ohci-at91 file.
>
>   In patch 6/6 :
>   - Removed extra space before the '='.
>   - Moved  /* forward definitions */ line before the declarations of functions.
>
> Manjunath Goudar (6):
>    USB: OHCI: make ohci-exynos a separate driver
>    USB: OHCI: make ohci-omap a separate driver
>    USB: OHCI: make ohci-omap3 a separate driver
>    USB: OHCI: make ohci-spear a separate driver
>    USB: OHCI: make ohci-at91 a separate driver
>    USB: OHCI: make ohci-s3c2410 a separate driver
>
>   drivers/usb/host/Kconfig        |   30 ++++++-
>   drivers/usb/host/Makefile       |    6 ++
>   drivers/usb/host/ohci-at91.c    |  153 ++++++++++++++++-------------------
>   drivers/usb/host/ohci-exynos.c  |  167 ++++++++++++++++-----------------------
>   drivers/usb/host/ohci-hcd.c     |  108 -------------------------
>   drivers/usb/host/ohci-omap.c    |  156 +++++++++++++-----------------------
>   drivers/usb/host/ohci-omap3.c   |  118 +++++++++------------------
>   drivers/usb/host/ohci-s3c2410.c |  128 +++++++++++++-----------------
>   drivers/usb/host/ohci-spear.c   |  140 +++++++++++++-------------------
>   9 files changed, 374 insertions(+), 632 deletions(-)
>
I am very sorry, this is patch V4 series.

Thanks
Manjunath Goudar


From stefano.stabellini at eu.citrix.com  Mon Jul 22 05:45:35 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 22 Jul 2013 10:45:35 +0100
Subject: [PATCH] xen/arm and xen/arm64: update xen_restart after
 ff701306cd49
In-Reply-To: <51EC4701.8020502@cogentembedded.com>
References: <1374420257-19467-1-git-send-email-stefano.stabellini@eu.citrix.com>
 <51EC4701.8020502@cogentembedded.com>
Message-ID: <alpine.DEB.2.02.1307221045200.4893@kaball.uk.xensource.com>

On Mon, 22 Jul 2013, Sergei Shtylyov wrote:
> Hello.
> 
> On 21-07-2013 19:24, Stefano Stabellini wrote:
> 
> > Commit ff701306cd49 changes the prototype of arm_pm_restart.
> 
>    Please also specify the summary line of that commit in parens.

Good idea, I'll repost


> > Update xen_restart accordingly.
> 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> 
> WBR, Sergei
> 


From stefano.stabellini at eu.citrix.com  Mon Jul 22 05:47:44 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 22 Jul 2013 10:47:44 +0100
Subject: [PATCH v2] xen/arm and xen/arm64: update xen_restart after
 ff701306cd49
Message-ID: <1374486464-25243-1-git-send-email-stefano.stabellini@eu.citrix.com>

Commit ff701306cd49 (arm64: use common reboot infrastructure) changes
the prototype of arm_pm_restart.  Update xen_restart accordingly.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/xen/enlighten.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index f71c37e..c9770ba 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -172,7 +172,7 @@ static void __init xen_percpu_init(void *unused)
 	enable_percpu_irq(xen_events_irq, 0);
 }
 
-static void xen_restart(char str, const char *cmd)
+static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
 {
 	struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
 	int rc;
-- 
1.7.2.5



From manjunath.goudar at linaro.org  Mon Jul 22 05:51:31 2013
From: manjunath.goudar at linaro.org (manjunath)
Date: Mon, 22 Jul 2013 15:21:31 +0530
Subject: [PATCH V4 00/11] USB: OHCI:Properly handle ohci_suspend()routine
 in bus glue
In-Reply-To: <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <51ED00A3.8080004@linaro.org>

On Monday 22 July 2013 03:02 PM, Manjunath Goudar wrote:
> Suspend scenario in case of ohci bus glue was not properly handled as
> it was not suspending generic part of ohci controller. Calling
> explicitly the ohci_suspend()routine will ensure proper handling
> of suspend scenario.
>
> V2:
>   -Incase ohci_suspend() fails, return right away without executing further.
>
> V3:
>   -New patch 1/11 added, for generic ohci-hcd suspend code.
>
> V4:
>   -Properly aligned "do_wakeup" and "ret" variables.
>
> Manjunath Goudar (11):
>    USB: OHCI: Properly handle OHCI controller suspend
>    USB: OHCI: Properly handle ohci-at91 suspend
>    USB: OHCI: Properly handle ohci-s3c2410 suspend
>    USB: OHCI: Properly handle ohci-da8xx suspend
>    USB: OHCI: Properly handle ohci-ep93xx suspend
>    USB: OHCI: Properly handle ohci-exynos suspend
>    USB: OHCI: Properly handle ohci-omap suspend
>    USB: OHCI: Properly handle ohci-platform suspend
>    USB: OHCI: Properly handle ohci-pxa27x suspend
>    USB: OHCI: Properly handle ohci-sm501 suspend
>    USB: OHCI: Properly handle ohci-spear suspend
>
>   drivers/usb/host/ohci-at91.c     |   10 ++++++++--
>   drivers/usb/host/ohci-da8xx.c    |   15 +++++++++++----
>   drivers/usb/host/ohci-ep93xx.c   |    9 ++++++++-
>   drivers/usb/host/ohci-exynos.c   |   20 +++++---------------
>   drivers/usb/host/ohci-hcd.c      |    9 ++++++++-
>   drivers/usb/host/ohci-omap.c     |   13 ++++++++++---
>   drivers/usb/host/ohci-platform.c |    9 ++++++++-
>   drivers/usb/host/ohci-pxa27x.c   |    8 +++++++-
>   drivers/usb/host/ohci-s3c2410.c  |   19 ++++---------------
>   drivers/usb/host/ohci-sm501.c    |   11 +++++++++--
>   drivers/usb/host/ohci-spear.c    |   12 +++++++++---
>   11 files changed, 87 insertions(+), 48 deletions(-)
>
I am sorry, not updated patch subject line. This is patch V4 series.

Thanks
Manjunath Goudar


From sachin.kamat at linaro.org  Mon Jul 22 06:00:40 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Mon, 22 Jul 2013 15:30:40 +0530
Subject: [PATCH] clk: exynos4: fix g2d/mdma clocks of exynos4x12
In-Reply-To: <1374480750-30962-1-git-send-email-chanho61.park@samsung.com>
References: <1374480750-30962-1-git-send-email-chanho61.park@samsung.com>
Message-ID: <CAK9yfHwNgZrZPT5c4DxfsDchWFXR2nWTVxCY2kZTEZW4PwyOng@mail.gmail.com>

Hi Chanho,

On 22 July 2013 13:42, Chanho Park <chanho61.park at samsung.com> wrote:
> The exynos4x12 has different address of GATE_IP_IMAGE reg. We should use
> EXYNOS4X12_GATE_IP_IMAGE for g2d gating clocks instead of 4210's reg.
> In case of mdma node, We don't use it for any exynos4 chipsets. I think we'll
> need to change it to 'none' or leave it on.
>
> Signed-off-by: Chanho Park <chanho61.park at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> ---
>  drivers/clk/samsung/clk-exynos4.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
> index 1bdb882..6300c9d 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -820,8 +820,10 @@ struct samsung_gate_clock exynos4210_gate_clks[] __initdata = {
>  struct samsung_gate_clock exynos4x12_gate_clks[] __initdata = {
>         GATE(audss, "audss", "sclk_epll", E4X12_GATE_IP_MAUDIO, 0, 0, 0),
>         GATE(mdnie0, "mdnie0", "aclk160", GATE_IP_LCD0, 2, 0, 0),
> +       GATE(g2d, "g2d", "aclk200", E4X12_GATE_IP_IMAGE, 0, 0, 0),
>         GATE(rotator, "rotator", "aclk200", E4X12_GATE_IP_IMAGE, 1, 0, 0),
> -       GATE(mdma2, "mdma2", "aclk200", E4X12_GATE_IP_IMAGE, 2, 0, 0),
> +       GATE(mdma, "mdma", "aclk200", E4X12_GATE_IP_IMAGE, 2, 0, 0),
> +       GATE(smmu_g2d, "smmu_g2d", "aclk200", E4X12_GATE_IP_IMAGE, 3, 0, 0),
>         GATE(smmu_mdma, "smmu_mdma", "aclk200", E4X12_GATE_IP_IMAGE, 5, 0, 0),
>         GATE(mipi_hsi, "mipi_hsi", "aclk133", GATE_IP_FSYS, 10, 0, 0),
>         GATE(chipid, "chipid", "aclk100", E4X12_GATE_IP_PERIR, 0, 0, 0),

Which kernel version is this patch based on? G2D clocks for 4x12 has
already been added by commit 5cd644d837 ("clk: exynos4: Add additional
G2D clocks").


-- 
With warm regards,
Sachin


From rnayak at ti.com  Mon Jul 22 06:01:13 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 22 Jul 2013 15:31:13 +0530
Subject: [PATCH 0/4] OMAP2+: Fix boot hang with earlycon enabled
Message-ID: <1374487277-26099-1-git-send-email-rnayak@ti.com>

Boot on all OMAP2+ devices is broken with earlycon enabled
as discussed here [1]

There were 2 issues which were rootcaused
1. Issue caused due to hwmod doing a reset of console uart while
earlycon was using it (seen only on am335x devices)

2. omap serial causing a NULL context restore with context loss
count missing.

This patch set attempts to fix both the issues and is one of the
different approaches discussed [1] on how to fix these issues.

Boot tested on omap4 panda es with and without earlycon (DT boot)
Boot tested on am335x bone black with and without earlycon (DT boot)
Boot tested on OMAP3 beagle XM with and without earlycon (non-DT boot)

[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg91662.html

Grygorii Strashko (1):
  serial: omap: enable PM runtime only when its fully configured

Rajendra Nayak (3):
  ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL
  ARM: OMAP2+: Avoid idling memory controllers with no drivers
  ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device
    state

 arch/arm/mach-omap2/omap_device.c                  |   18 ++++++++
 arch/arm/mach-omap2/omap_hwmod.h                   |   48 ++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |    6 +--
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    9 ++--
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    5 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    3 +-
 arch/arm/mach-omap2/serial.c                       |   11 -----
 drivers/tty/serial/omap-serial.c                   |    3 +-
 9 files changed, 81 insertions(+), 24 deletions(-)

-- 
1.7.9.5



From rnayak at ti.com  Mon Jul 22 06:01:14 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 22 Jul 2013 15:31:14 +0530
Subject: [PATCH 1/4] ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with
 DEBUG_LL
In-Reply-To: <1374487277-26099-1-git-send-email-rnayak@ti.com>
References: <1374487277-26099-1-git-send-email-rnayak@ti.com>
Message-ID: <1374487277-26099-2-git-send-email-rnayak@ti.com>

With commit '82702ea11ddfe0e43382e1fa5b66d807d8114916' "ARM: OMAP2+:
Fix serial init for device tree based booting" stubbing out omap_serial_early_init()
for Device tree based booting, there was a crash observed on AM335x based devices
when hwmod does a _setup_reset() early at boot.

This was rootcaused to hwmod trying to reset console uart while earlycon was using it.
The way to tell hwmod not to do this is to specify the HWMOD_INIT_NO_RESET flag,
which were infact set by the omap_serial_early_init() function by parsing the
cmdline to identify the console device.

Parsing the cmdline to identify the uart used by earlycon itself seems broken
as there is nothing preventing earlycon to use a different one.

This patch, instead, attempts to populate the requiste flags for hwmod based on
the CONFIG_DEBUG_OMAPxUARTy FLAGS. This gets rid of the need for cmdline parsing
in the DT as well as non-DT cases to identify the uart used by earlycon.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
Reported-by: Mark Jackson <mpfj-list at newflow.co.uk>
Reported-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.h                   |   48 ++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |    6 +--
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    9 ++--
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    5 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    3 +-
 arch/arm/mach-omap2/serial.c                       |   11 -----
 7 files changed, 61 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index aab33fd..8440a21 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -95,6 +95,54 @@ extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3;
 #define MODULEMODE_HWCTRL		1
 #define MODULEMODE_SWCTRL		2
 
+#define DEBUG_OMAP2UART1_FLAGS	0
+#define DEBUG_OMAP2UART2_FLAGS	0
+#define DEBUG_OMAP2UART3_FLAGS	0
+#define DEBUG_OMAP3UART3_FLAGS	0
+#define DEBUG_OMAP3UART4_FLAGS	0
+#define DEBUG_OMAP4UART3_FLAGS	0
+#define DEBUG_OMAP4UART4_FLAGS	0
+#define DEBUG_TI81XXUART1_FLAGS	0
+#define DEBUG_TI81XXUART2_FLAGS	0
+#define DEBUG_TI81XXUART3_FLAGS	0
+#define DEBUG_AM33XXUART1_FLAGS	0
+
+#define DEBUG_OMAPUART_FLAGS	(HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET)
+
+#if defined(CONFIG_DEBUG_OMAP2UART1)
+#undef DEBUG_OMAP2UART1_FLAGS
+#define DEBUG_OMAP2UART1_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_OMAP2UART2)
+#undef DEBUG_OMAP2UART2_FLAGS
+#define DEBUG_OMAP2UART2_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_OMAP2UART3)
+#undef DEBUG_OMAP2UART3_FLAGS
+#define DEBUG_OMAP2UART3_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_OMAP3UART3)
+#undef DEBUG_OMAP3UART3_FLAGS
+#define DEBUG_OMAP3UART3_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_OMAP3UART4)
+#undef DEBUG_OMAP3UART4_FLAGS
+#define DEBUG_OMAP3UART4_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_OMAP4UART3)
+#undef DEBUG_OMAP4UART3_FLAGS
+#define DEBUG_OMAP4UART3_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_OMAP4UART4)
+#undef DEBUG_OMAP4UART4_FLAGS
+#define DEBUG_OMAP4UART4_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_TI81XXUART1)
+#undef DEBUG_TI81XXUART1_FLAGS
+#define DEBUG_TI81XXUART1_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_TI81XXUART2)
+#undef DEBUG_TI81XXUART2_FLAGS
+#define DEBUG_TI81XXUART2_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_TI81XXUART3)
+#undef DEBUG_TI81XXUART3_FLAGS
+#define DEBUG_TI81XXUART3_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_AM33XXUART1)
+#undef DEBUG_AM33XXUART1_FLAGS
+#define DEBUG_AM33XXUART1_FLAGS DEBUG_OMAPUART_FLAGS
+#endif
 
 /**
  * struct omap_hwmod_mux_info - hwmod specific mux configuration
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index d05fc7b..56cebb0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -512,7 +512,7 @@ struct omap_hwmod omap2xxx_uart1_hwmod = {
 	.mpu_irqs	= omap2_uart1_mpu_irqs,
 	.sdma_reqs	= omap2_uart1_sdma_reqs,
 	.main_clk	= "uart1_fck",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP2UART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -532,7 +532,7 @@ struct omap_hwmod omap2xxx_uart2_hwmod = {
 	.mpu_irqs	= omap2_uart2_mpu_irqs,
 	.sdma_reqs	= omap2_uart2_sdma_reqs,
 	.main_clk	= "uart2_fck",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP2UART2_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -552,7 +552,7 @@ struct omap_hwmod omap2xxx_uart3_hwmod = {
 	.mpu_irqs	= omap2_uart3_mpu_irqs,
 	.sdma_reqs	= omap2_uart3_sdma_reqs,
 	.main_clk	= "uart3_fck",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP2UART3_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 28bbd56..d4114a9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1512,7 +1512,7 @@ static struct omap_hwmod am33xx_uart1_hwmod = {
 	.name		= "uart1",
 	.class		= &uart_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_AM33XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.main_clk	= "dpll_per_m2_div4_wkupdm_ck",
 	.prcm		= {
 		.omap4	= {
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f7a3df2..0c3a427 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -490,7 +490,7 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
 	.mpu_irqs	= omap2_uart1_mpu_irqs,
 	.sdma_reqs	= omap2_uart1_sdma_reqs,
 	.main_clk	= "uart1_fck",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -509,7 +509,7 @@ static struct omap_hwmod omap3xxx_uart2_hwmod = {
 	.mpu_irqs	= omap2_uart2_mpu_irqs,
 	.sdma_reqs	= omap2_uart2_sdma_reqs,
 	.main_clk	= "uart2_fck",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_TI81XXUART2_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -528,7 +528,8 @@ static struct omap_hwmod omap3xxx_uart3_hwmod = {
 	.mpu_irqs	= omap2_uart3_mpu_irqs,
 	.sdma_reqs	= omap2_uart3_sdma_reqs,
 	.main_clk	= "uart3_fck",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP3UART3_FLAGS | DEBUG_TI81XXUART3_FLAGS |
+				HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = OMAP3430_PER_MOD,
@@ -558,7 +559,7 @@ static struct omap_hwmod omap36xx_uart4_hwmod = {
 	.mpu_irqs	= uart4_mpu_irqs,
 	.sdma_reqs	= uart4_sdma_reqs,
 	.main_clk	= "uart4_fck",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP3UART4_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = OMAP3430_PER_MOD,
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index d04b5e6..9c3b504 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2858,8 +2858,7 @@ static struct omap_hwmod omap44xx_uart3_hwmod = {
 	.name		= "uart3",
 	.class		= &omap44xx_uart_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
-				HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP4UART3_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
@@ -2875,7 +2874,7 @@ static struct omap_hwmod omap44xx_uart4_hwmod = {
 	.name		= "uart4",
 	.class		= &omap44xx_uart_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP4UART4_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index f37ae96..3c70f5c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1375,7 +1375,7 @@ static struct omap_hwmod omap54xx_uart3_hwmod = {
 	.name		= "uart3",
 	.class		= &omap54xx_uart_hwmod_class,
 	.clkdm_name	= "l4per_clkdm",
-	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+	.flags		= DEBUG_OMAP4UART3_FLAGS,
 	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
@@ -1391,6 +1391,7 @@ static struct omap_hwmod omap54xx_uart4_hwmod = {
 	.name		= "uart4",
 	.class		= &omap54xx_uart_hwmod_class,
 	.clkdm_name	= "l4per_clkdm",
+	.flags		= DEBUG_OMAP4UART4_FLAGS,
 	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3a674de..a388f8c 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -208,17 +208,6 @@ static int __init omap_serial_early_init(void)
 				pr_info("%s used as console in debug mode: uart%d clocks will not be gated",
 					uart_name, uart->num);
 			}
-
-			/*
-			 * omap-uart can be used for earlyprintk logs
-			 * So if omap-uart is used as console then prevent
-			 * uart reset and idle to get logs from omap-uart
-			 * until uart console driver is available to take
-			 * care for console messages.
-			 * Idling or resetting omap-uart while printing logs
-			 * early boot logs can stall the boot-up.
-			 */
-			oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;
 		}
 	} while (1);
 
-- 
1.7.9.5



From rnayak at ti.com  Mon Jul 22 06:01:16 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 22 Jul 2013 15:31:16 +0530
Subject: [PATCH 3/4] ARM: OMAP2+: Avoid idling memory controllers with no
 drivers
In-Reply-To: <1374487277-26099-1-git-send-email-rnayak@ti.com>
References: <1374487277-26099-1-git-send-email-rnayak@ti.com>
Message-ID: <1374487277-26099-4-git-send-email-rnayak@ti.com>

Memory controllers in OMAP (like GPMC and EMIF) have the hwmods marked with
HWMOD_INIT_NO_IDLE and are left in enabled state post initial setup.

Even if they have drivers missing, avoid idling them as part of
omap_device_late_idle()

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/omap_device.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..1c82cde 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -842,6 +842,7 @@ static int __init omap_device_late_idle(struct device *dev, void *data)
 {
 	struct platform_device *pdev = to_platform_device(dev);
 	struct omap_device *od = to_omap_device(pdev);
+	int i;
 
 	if (!od)
 		return 0;
@@ -850,6 +851,15 @@ static int __init omap_device_late_idle(struct device *dev, void *data)
 	 * If omap_device state is enabled, but has no driver bound,
 	 * idle it.
 	 */
+
+	/*
+	 * Some devices (like memory controllers) are always kept
+	 * enabled, and should not be idled even with no drivers.
+	 */
+	for (i = 0; i < od->hwmods_cnt; i++)
+		if (od->hwmods[i]->flags & HWMOD_INIT_NO_IDLE)
+			return 0;
+
 	if (od->_driver_status != BUS_NOTIFY_BOUND_DRIVER) {
 		if (od->_state == OMAP_DEVICE_STATE_ENABLED) {
 			dev_warn(dev, "%s: enabled but no driver.  Idling\n",
-- 
1.7.9.5



From rnayak at ti.com  Mon Jul 22 06:01:15 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 22 Jul 2013 15:31:15 +0530
Subject: [PATCH 2/4] serial: omap: enable PM runtime only when its fully
 configured
In-Reply-To: <1374487277-26099-1-git-send-email-rnayak@ti.com>
References: <1374487277-26099-1-git-send-email-rnayak@ti.com>
Message-ID: <1374487277-26099-3-git-send-email-rnayak@ti.com>

From: Grygorii Strashko <grygorii.strashko at ti.com>

If earlyprintk is enabled and current UART is console port the platform
code can mark it as RPM_ACTIVE to sync real IP state with PM Runtime and
avoid resuming of already active device, but now, driver initialization
will be performed in the wrong way:

	pm_runtime_enable(&pdev->dev);
    <-- PM runtime alowed (device state RPM_ACTIVE)
	if (omap_up_info->autosuspend_timeout == 0)
		omap_up_info->autosuspend_timeout = -1;
	device_init_wakeup(up->dev, true);
	pm_runtime_use_autosuspend(&pdev->dev);
	<-- update_autosuspend() will be called and it will disable device
        (device state RPM_SUSPENDED)
	pm_runtime_set_autosuspend_delay(&pdev->dev,
			omap_up_info->autosuspend_timeout);
	<-- update_autosuspend() will be called which will re-enable device
        (device state RPM_ACTIVE), because autosuspend_timeout < 0

	pm_runtime_irq_safe(&pdev->dev);
	pm_runtime_get_sync(&pdev->dev);
	<-- will do nothing

Such behavior isn't expected by OMAP serial drivers and causes
unpredictable calls of serial_omap_runtime_suspend() and
serial_omap_runtime_resume().

Hence, fix it by allowing PM runtime only after all its parameters are
configured.

CC: Tony Lindgren <tony at atomide.com>
CC: Rajendra Nayak <rnayak at ti.com>
CC: Felipe Balbi <balbi at ti.com>
CC: Kevin Hilman <khilman at linaro.org>

Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
---
 drivers/tty/serial/omap-serial.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index b6d1728..f39bf0c 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1501,7 +1501,6 @@ static int serial_omap_probe(struct platform_device *pdev)
 	INIT_WORK(&up->qos_work, serial_omap_uart_qos_work);
 
 	platform_set_drvdata(pdev, up);
-	pm_runtime_enable(&pdev->dev);
 	if (omap_up_info->autosuspend_timeout == 0)
 		omap_up_info->autosuspend_timeout = -1;
 	device_init_wakeup(up->dev, true);
@@ -1510,6 +1509,8 @@ static int serial_omap_probe(struct platform_device *pdev)
 			omap_up_info->autosuspend_timeout);
 
 	pm_runtime_irq_safe(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+
 	pm_runtime_get_sync(&pdev->dev);
 
 	omap_serial_fill_features_erratas(up);
-- 
1.7.9.5



From rnayak at ti.com  Mon Jul 22 06:01:17 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 22 Jul 2013 15:31:17 +0530
Subject: [PATCH 4/4] ARM: OMAP2+: Sync hwmod state with the pm_runtime and
 omap_device state
In-Reply-To: <1374487277-26099-1-git-send-email-rnayak@ti.com>
References: <1374487277-26099-1-git-send-email-rnayak@ti.com>
Message-ID: <1374487277-26099-5-git-send-email-rnayak@ti.com>

Some hwmods which are marked with HWMOD_INIT_NO_IDLE are left in enabled
state post setup(). When a omap_device gets created for such hwmods
make sure the omap_device and pm_runtime states are also in sync for such
hwmods by doing a omap_device_enable() and pm_runtime_set_active() for the
device.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/omap_device.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 1c82cde..f99f68e 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
 	struct device_node *node = pdev->dev.of_node;
 	const char *oh_name;
 	int oh_cnt, i, ret = 0;
+	bool device_active = false;
 
 	oh_cnt = of_property_count_strings(node, "ti,hwmods");
 	if (oh_cnt <= 0) {
@@ -152,6 +153,8 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
 			goto odbfd_exit1;
 		}
 		hwmods[i] = oh;
+		if (oh->flags & HWMOD_INIT_NO_IDLE)
+			device_active = true;
 	}
 
 	od = omap_device_alloc(pdev, hwmods, oh_cnt);
@@ -172,6 +175,11 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
 
 	pdev->dev.pm_domain = &omap_device_pm_domain;
 
+	if (device_active) {
+		omap_device_enable(pdev);
+		pm_runtime_set_active(&pdev->dev);
+	}
+
 odbfd_exit1:
 	kfree(hwmods);
 odbfd_exit:
-- 
1.7.9.5



From nsekhar at ti.com  Mon Jul 22 06:03:13 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 22 Jul 2013 15:33:13 +0530
Subject: [PATCH v3 3/5] ARM: davinci: da850: do not specify clock_frequency
 for UART DT node
In-Reply-To: <1371633342-1210-4-git-send-email-prakash.pm@ti.com>
References: <1371633342-1210-1-git-send-email-prakash.pm@ti.com>
 <1371633342-1210-4-git-send-email-prakash.pm@ti.com>
Message-ID: <51ED0361.9020604@ti.com>

On Wednesday 19 June 2013 02:45 PM, Manjunathappa, Prakash wrote:
> DT kernel on da850-evm comes up with garbled UART logs. This is because
> of mismatch in actual module clock rate and rate specified(clock-frequency)
> in DT blob. kernel should not assume or depend on bootloaders clock
> configuration, instead let it find the clock rate at runtime.
> 
> Issue discussed here before arriving on this implementation:
> "ARM: davinci: da850 evm: update clock rate for UART 1/2 DT nodes"
> https://patchwork.kernel.org/patch/2162271/
> 
> Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>

Adding to v3.12/soc branch of my tree.

Thanks,
Sekhar



From nsekhar at ti.com  Mon Jul 22 06:03:54 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 22 Jul 2013 15:33:54 +0530
Subject: [PATCH v3 4/5] ARM: davinci: da8xx: remove da8xx_uart_clk_enable
In-Reply-To: <1371633342-1210-5-git-send-email-prakash.pm@ti.com>
References: <1371633342-1210-1-git-send-email-prakash.pm@ti.com>
 <1371633342-1210-5-git-send-email-prakash.pm@ti.com>
Message-ID: <51ED038A.6000009@ti.com>

On Wednesday 19 June 2013 02:45 PM, Manjunathappa, Prakash wrote:
> Serial clocks are enabled from of_platform_serial_setup:of_serial.c,
> so remove davinci_serial_setup_clk from here.
> 
> Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>

Adding to v3.12/soc branch.

Thanks,
Sekhar



From manjunath.goudar at linaro.org  Mon Jul 22 06:04:57 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 15:34:57 +0530
Subject: [PATCH V2] USB: OHCI: make ohci-nxp a separate driver
In-Reply-To: <1372585818-8441-1-git-send-email-manjunath.goudar@linaro.org>
References: <1372585818-8441-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374487497-11726-1-git-send-email-manjunath.goudar@linaro.org>

Separate the OHCI NXP host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.

Many place function name and struct name started with usb,
current scenario replaced usb with ohci for proper naming.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
  - Directive check NXP_PLATFORM_DRIVER block has been removed.
---
 drivers/usb/host/Kconfig    |    8 +++
 drivers/usb/host/Makefile   |    1 +
 drivers/usb/host/ohci-hcd.c |   18 -------
 drivers/usb/host/ohci-nxp.c |  124 +++++++++++++++++--------------------------
 4 files changed, 58 insertions(+), 93 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 795d14d..0519769 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -398,6 +398,14 @@ config USB_OHCI_HCD_S3CXXXX
           Enables support for the on-chip OHCI controller on
           S3CXXXX chips.
 
+config USB_OHCI_HCD_LPC32XX
+	tristate "Support for LPC on-chip OHCI USB controller"
+	depends on USB_OHCI_HCD && ARCH_LPC32XX
+	default y
+	---help---
+          Enables support for the on-chip OHCI controller on
+          NXP chips.
+
 config USB_OHCI_HCD_AT91
         tristate "Support for Atmel on-chip OHCI USB controller"
         depends on USB_OHCI_HCD && ARCH_AT91
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 9dffe81..edc0909 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_USB_OHCI_HCD_OMAP3)	+= ohci-omap3.o
 obj-$(CONFIG_USB_OHCI_HCD_SPEAR)	+= ohci-spear.o
 obj-$(CONFIG_USB_OHCI_HCD_AT91)	+= ohci-at91.o
 obj-$(CONFIG_USB_OHCI_HCD_S3CXXXX)	+= ohci-s3c2410.o
+obj-$(CONFIG_USB_OHCI_HCD_LPC32XX)	+= ohci-nxp.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index f3dcaa2..39d14f0 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1194,11 +1194,6 @@ MODULE_LICENSE ("GPL");
 #define EP93XX_PLATFORM_DRIVER	ohci_hcd_ep93xx_driver
 #endif
 
-#ifdef CONFIG_ARCH_LPC32XX
-#include "ohci-nxp.c"
-#define NXP_PLATFORM_DRIVER	usb_hcd_nxp_driver
-#endif
-
 #ifdef CONFIG_ARCH_DAVINCI_DA8XX
 #include "ohci-da8xx.c"
 #define DAVINCI_PLATFORM_DRIVER	ohci_hcd_da8xx_driver
@@ -1301,12 +1296,6 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_ep93xx;
 #endif
 
-#ifdef NXP_PLATFORM_DRIVER
-	retval = platform_driver_register(&NXP_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_nxp;
-#endif
-
 #ifdef DAVINCI_PLATFORM_DRIVER
 	retval = platform_driver_register(&DAVINCI_PLATFORM_DRIVER);
 	if (retval < 0)
@@ -1320,10 +1309,6 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
  error_davinci:
 #endif
-#ifdef NXP_PLATFORM_DRIVER
-	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
- error_nxp:
-#endif
 #ifdef EP93XX_PLATFORM_DRIVER
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
  error_ep93xx:
@@ -1368,9 +1353,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef DAVINCI_PLATFORM_DRIVER
 	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
 #endif
-#ifdef NXP_PLATFORM_DRIVER
-	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
-#endif
 #ifdef EP93XX_PLATFORM_DRIVER
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-nxp.c b/drivers/usb/host/ohci-nxp.c
index 7d7d507..8d6eecf 100644
--- a/drivers/usb/host/ohci-nxp.c
+++ b/drivers/usb/host/ohci-nxp.c
@@ -19,10 +19,19 @@
  * or implied.
  */
 #include <linux/clk.h>
-#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
 #include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/of.h>
+#include <linux/platform_device.h>
 #include <linux/usb/isp1301.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ohci.h"
+
 
 #include <mach/hardware.h>
 #include <asm/mach-types.h>
@@ -57,6 +66,11 @@
 #define start_int_umask(irq)
 #endif
 
+#define DRIVER_DESC "OHCI NXP driver"
+
+static const char hcd_name[] = "ohci-nxp";
+static struct hc_driver __read_mostly ohci_nxp_hc_driver;
+
 static struct i2c_client *isp1301_i2c_client;
 
 extern int usb_disabled(void);
@@ -132,14 +146,14 @@ static inline void isp1301_vbus_off(void)
 		OTG1_VBUS_DRV);
 }
 
-static void nxp_start_hc(void)
+static void ohci_nxp_start_hc(void)
 {
 	unsigned long tmp = __raw_readl(USB_OTG_STAT_CONTROL) | HOST_EN;
 	__raw_writel(tmp, USB_OTG_STAT_CONTROL);
 	isp1301_vbus_on();
 }
 
-static void nxp_stop_hc(void)
+static void ohci_nxp_stop_hc(void)
 {
 	unsigned long tmp;
 	isp1301_vbus_off();
@@ -147,68 +161,9 @@ static void nxp_stop_hc(void)
 	__raw_writel(tmp, USB_OTG_STAT_CONTROL);
 }
 
-static int ohci_nxp_start(struct usb_hcd *hcd)
-{
-	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
-	int ret;
-
-	if ((ret = ohci_init(ohci)) < 0)
-		return ret;
-
-	if ((ret = ohci_run(ohci)) < 0) {
-		dev_err(hcd->self.controller, "can't start\n");
-		ohci_stop(hcd);
-		return ret;
-	}
-	return 0;
-}
-
-static const struct hc_driver ohci_nxp_hc_driver = {
-	.description = hcd_name,
-	.product_desc =		"nxp OHCI",
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq = ohci_irq,
-	.flags = HCD_USB11 | HCD_MEMORY,
-
-	.hcd_priv_size =	sizeof(struct ohci_hcd),
-	/*
-	 * basic lifecycle operations
-	 */
-	.start = ohci_nxp_start,
-	.stop = ohci_stop,
-	.shutdown = ohci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue = ohci_urb_enqueue,
-	.urb_dequeue = ohci_urb_dequeue,
-	.endpoint_disable = ohci_endpoint_disable,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number = ohci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data = ohci_hub_status_data,
-	.hub_control = ohci_hub_control,
-#ifdef	CONFIG_PM
-	.bus_suspend = ohci_bus_suspend,
-	.bus_resume = ohci_bus_resume,
-#endif
-	.start_port_reset = ohci_start_port_reset,
-};
-
-static int usb_hcd_nxp_probe(struct platform_device *pdev)
+static int ohci_hcd_nxp_probe(struct platform_device *pdev)
 {
 	struct usb_hcd *hcd = 0;
-	struct ohci_hcd *ohci;
 	const struct hc_driver *driver = &ohci_nxp_hc_driver;
 	struct resource *res;
 	int ret = 0, irq;
@@ -313,17 +268,15 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
 		goto fail_resource;
 	}
 
-	nxp_start_hc();
+	ohci_nxp_start_hc();
 	platform_set_drvdata(pdev, hcd);
-	ohci = hcd_to_ohci(hcd);
-	ohci_hcd_init(ohci);
 
 	dev_info(&pdev->dev, "at 0x%p, irq %d\n", hcd->regs, hcd->irq);
 	ret = usb_add_hcd(hcd, irq, 0);
 	if (ret == 0)
 		return ret;
 
-	nxp_stop_hc();
+	ohci_nxp_stop_hc();
 fail_resource:
 	usb_put_hcd(hcd);
 fail_hcd:
@@ -345,12 +298,12 @@ fail_disable:
 	return ret;
 }
 
-static int usb_hcd_nxp_remove(struct platform_device *pdev)
+static int ohci_hcd_nxp_remove(struct platform_device *pdev)
 {
 	struct usb_hcd *hcd = platform_get_drvdata(pdev);
 
 	usb_remove_hcd(hcd);
-	nxp_stop_hc();
+	ohci_nxp_stop_hc();
 	usb_put_hcd(hcd);
 	clk_disable(usb_pll_clk);
 	clk_put(usb_pll_clk);
@@ -366,20 +319,41 @@ static int usb_hcd_nxp_remove(struct platform_device *pdev)
 MODULE_ALIAS("platform:usb-ohci");
 
 #ifdef CONFIG_OF
-static const struct of_device_id usb_hcd_nxp_match[] = {
+static const struct of_device_id ohci_hcd_nxp_match[] = {
 	{ .compatible = "nxp,ohci-nxp" },
 	{},
 };
-MODULE_DEVICE_TABLE(of, usb_hcd_nxp_match);
+MODULE_DEVICE_TABLE(of, ohci_hcd_nxp_match);
 #endif
 
-static struct platform_driver usb_hcd_nxp_driver = {
+static struct platform_driver ohci_hcd_nxp_driver = {
 	.driver = {
 		.name = "usb-ohci",
 		.owner	= THIS_MODULE,
-		.of_match_table = of_match_ptr(usb_hcd_nxp_match),
+		.of_match_table = of_match_ptr(ohci_hcd_nxp_match),
 	},
-	.probe = usb_hcd_nxp_probe,
-	.remove = usb_hcd_nxp_remove,
+	.probe = ohci_hcd_nxp_probe,
+	.remove = ohci_hcd_nxp_remove,
 };
 
+static int __init ohci_nxp_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ohci_init_driver(&ohci_nxp_hc_driver, NULL);
+	return platform_driver_register(&ohci_hcd_nxp_driver);
+}
+module_init(ohci_nxp_init);
+
+static void __exit ohci_nxp_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_nxp_driver);
+}
+module_exit(ohci_nxp_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL v2");
+
-- 
1.7.9.5



From nsekhar at ti.com  Mon Jul 22 06:11:00 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 22 Jul 2013 15:41:00 +0530
Subject: [PATCH v3 5/5] ARM: davinci: serial: platform code cleanup
In-Reply-To: <1371633342-1210-6-git-send-email-prakash.pm@ti.com>
References: <1371633342-1210-1-git-send-email-prakash.pm@ti.com>
 <1371633342-1210-6-git-send-email-prakash.pm@ti.com>
Message-ID: <51ED0534.2080408@ti.com>

On Wednesday 19 June 2013 02:45 PM, Manjunathappa, Prakash wrote:
> 1) "struct davinci_uart_config" is introduced to specify
>    UART ports brought out or enabled on the board. But
>    none of the boards use them for that purpose, so clean
>    it up.
> 2) Have pointer to platform device as a argument for
>    davinci_serial_init(), no need of serial_dev in
>    struct soc_info now.
> 3) No need of davinci_serial_setup_clk(), not called from
>    multiple places, hence reduce function call overhead.

1) and 2) are related but 3) can be moved into a different patch - this
patch will otherwise be doing too many things (hint for that is a vague
headline and too many items to list in description)

Can you respin just this patch based on v3.12/soc branch of my tree?

Thanks,
Sekhar



From manjunath.goudar at linaro.org  Mon Jul 22 06:19:40 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Mon, 22 Jul 2013 15:49:40 +0530
Subject: [PATCH V2] USB: EHCI: make ehci-w90X900 a separate driver
In-Reply-To: <1372347109-5563-1-git-send-email-manjunath.goudar@linaro.org>
References: <1372347109-5563-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374488380-26428-1-git-send-email-manjunath.goudar@linaro.org>

Separate the W90X900(W90P910) on-chip host controller driver from
ehci-hcd host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before W90X900(W90P910)
can be booted with a multi-platform kernel

and an ehci driver that only works on one of them.

With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the w90X900 bus glue.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Wan ZongShun <mcuos.com at gmail.com>
Cc: linux-usb at vger.kernel.org
Cc: linux-kernel at vger.kernel.org

V2:
 -Arranged  #include's in alphabetical order.
 -Replaced "w90p910" by "w90x900" because it is supports
  all series of w90x900.
---
 drivers/usb/host/Kconfig        |    2 +-
 drivers/usb/host/Makefile       |    1 +
 drivers/usb/host/ehci-hcd.c     |    5 ---
 drivers/usb/host/ehci-w90x900.c |   85 ++++++++++++++++-----------------------
 4 files changed, 37 insertions(+), 56 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index ba52912..7bc598b 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -244,7 +244,7 @@ config USB_EHCI_MV
 	  SoCs, see USB_EHCI_HCD_ORION for those.
 
 config USB_W90X900_EHCI
-	bool "W90X900(W90P910) EHCI support"
+	tristate "W90X900(W90P910) EHCI support"
 	depends on ARCH_W90X900
 	---help---
 		Enables support for the W90X900 USB controller
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 7664db8..28adb3f 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
 obj-$(CONFIG_USB_EHCI_MSM)	+= ehci-msm.o
 obj-$(CONFIG_USB_EHCI_TEGRA)	+= ehci-tegra.o
 obj-$(CONFIG_USB_EHCI_MV)       += ehci-mv.o
+obj-$(CONFIG_USB_W90X900_EHCI)	+= ehci-w90x900.o
 
 obj-$(CONFIG_USB_OXU210HP_HCD)	+= oxu210hp-hcd.o
 obj-$(CONFIG_USB_ISP116X_HCD)	+= isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 5717dcd..4a5644e 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1249,11 +1249,6 @@ MODULE_LICENSE ("GPL");
 #define XILINX_OF_PLATFORM_DRIVER	ehci_hcd_xilinx_of_driver
 #endif
 
-#ifdef CONFIG_USB_W90X900_EHCI
-#include "ehci-w90x900.c"
-#define	PLATFORM_DRIVER		ehci_hcd_w90x900_driver
-#endif
-
 #ifdef CONFIG_USB_OCTEON_EHCI
 #include "ehci-octeon.c"
 #define PLATFORM_DRIVER		ehci_octeon_driver
diff --git a/drivers/usb/host/ehci-w90x900.c b/drivers/usb/host/ehci-w90x900.c
index 59e0e24..4d6631d 100644
--- a/drivers/usb/host/ehci-w90x900.c
+++ b/drivers/usb/host/ehci-w90x900.c
@@ -11,13 +11,28 @@
  *
  */
 
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ehci.h"
 
 /* enable phy0 and phy1 for w90p910 */
 #define	ENPHY		(0x01<<8)
 #define PHY0_CTR	(0xA4)
 #define PHY1_CTR	(0xA8)
 
+#define DRIVER_DESC "EHCI w90x900 driver"
+
+static const char hcd_name[] = "ehci-w90x900 ";
+
+static struct hc_driver __read_mostly ehci_w90x900_hc_driver;
+
 static int usb_w90x900_probe(const struct hc_driver *driver,
 		      struct platform_device *pdev)
 {
@@ -99,54 +114,6 @@ void usb_w90x900_remove(struct usb_hcd *hcd, struct platform_device *pdev)
 	usb_put_hcd(hcd);
 }
 
-static const struct hc_driver ehci_w90x900_hc_driver = {
-	.description = hcd_name,
-	.product_desc = "Nuvoton w90x900 EHCI Host Controller",
-	.hcd_priv_size = sizeof(struct ehci_hcd),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq = ehci_irq,
-	.flags = HCD_USB2|HCD_MEMORY,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.reset = ehci_setup,
-	.start = ehci_run,
-
-	.stop = ehci_stop,
-	.shutdown = ehci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue = ehci_urb_enqueue,
-	.urb_dequeue = ehci_urb_dequeue,
-	.endpoint_disable = ehci_endpoint_disable,
-	.endpoint_reset = ehci_endpoint_reset,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number = ehci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data = ehci_hub_status_data,
-	.hub_control = ehci_hub_control,
-#ifdef	CONFIG_PM
-	.bus_suspend = ehci_bus_suspend,
-	.bus_resume = ehci_bus_resume,
-#endif
-	.relinquish_port	= ehci_relinquish_port,
-	.port_handed_over	= ehci_port_handed_over,
-
-	.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
-};
-
 static int ehci_w90x900_probe(struct platform_device *pdev)
 {
 	if (usb_disabled())
@@ -173,7 +140,25 @@ static struct platform_driver ehci_hcd_w90x900_driver = {
 	},
 };
 
+static int __init ehci_w90X900_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ehci_init_driver(&ehci_w90x900_hc_driver, NULL);
+	return platform_driver_register(&ehci_hcd_w90x900_driver);
+}
+module_init(ehci_w90X900_init);
+
+static void __exit ehci_w90X900_cleanup(void)
+{
+	platform_driver_unregister(&ehci_hcd_w90x900_driver);
+}
+module_exit(ehci_w90X900_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_AUTHOR("Wan ZongShun <mcuos.com at gmail.com>");
-MODULE_DESCRIPTION("w90p910 usb ehci driver!");
-MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:w90p910-ehci");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5



From lee.jones at linaro.org  Mon Jul 22 06:52:20 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:20 +0100
Subject: [PATCH 01/22] ARM: ux500: Remove '0x's from HREF v60+ DTS file
Message-ID: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/hrefv60plus.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/hrefv60plus.dts b/arch/arm/boot/dts/hrefv60plus.dts
index 3d580d6..46fd8af 100644
--- a/arch/arm/boot/dts/hrefv60plus.dts
+++ b/arch/arm/boot/dts/hrefv60plus.dts
@@ -26,7 +26,7 @@
 
 	soc {
 		i2c at 80110000 {
-			bu21013_tp at 0x5c {
+			bu21013_tp at 5c {
 				reset-gpio = <&gpio4 15 0x4>;
 			};
 		};
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:21 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:21 +0100
Subject: [PATCH 02/22] ARM: nomadik: Remove '0x's from nomadik stn8815 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-2-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
index a3acfa7..c2ee51e 100644
--- a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
+++ b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
@@ -742,14 +742,14 @@
 		#size-cells = <1>;
 		ranges;
 
-		vica: intc at 0x10140000 {
+		vica: intc at 10140000 {
 			compatible = "arm,versatile-vic";
 			interrupt-controller;
 			#interrupt-cells = <1>;
 			reg = <0x10140000 0x20>;
 		};
 
-		vicb: intc at 0x10140020 {
+		vicb: intc at 10140020 {
 			compatible = "arm,versatile-vic";
 			interrupt-controller;
 			#interrupt-cells = <1>;
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:25 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:25 +0100
Subject: [PATCH 06/22] ARM: dts: bcm281xx: Remove '0x's from BCM11351 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-6-git-send-email-lee.jones@linaro.org>

Cc: Christian Daudt <csd at broadcom.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/bcm11351.dtsi | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index c0cdf66..db5873a 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -34,7 +34,7 @@
 		      <0x3ff00100 0x100>;
 	};
 
-	smc at 0x3404c000 {
+	smc at 3404c000 {
 		compatible = "bcm,bcm11351-smc", "bcm,kona-smc";
 		reg = <0x3404c000 0x400>; /* 1 KiB in SRAM */
 	};
@@ -63,28 +63,28 @@
 		clock-frequency = <32768>;
 	};
 
-	sdio0: sdio at 0x3f180000 {
+	sdio0: sdio at 3f180000 {
 		compatible = "bcm,kona-sdhci";
 		reg = <0x3f180000 0x10000>;
 		interrupts = <0x0 77 0x4>;
 		status = "disabled";
 	};
 
-	sdio1: sdio at 0x3f190000 {
+	sdio1: sdio at 3f190000 {
 		compatible = "bcm,kona-sdhci";
 		reg = <0x3f190000 0x10000>;
 		interrupts = <0x0 76 0x4>;
 		status = "disabled";
 	};
 
-	sdio2: sdio at 0x3f1a0000 {
+	sdio2: sdio at 3f1a0000 {
 		compatible = "bcm,kona-sdhci";
 		reg = <0x3f1a0000 0x10000>;
 		interrupts = <0x0 74 0x4>;
 		status = "disabled";
 	};
 
-	sdio3: sdio at 0x3f1b0000 {
+	sdio3: sdio at 3f1b0000 {
 		compatible = "bcm,kona-sdhci";
 		reg = <0x3f1b0000 0x10000>;
 		interrupts = <0x0 73 0x4>;
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:22 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:22 +0100
Subject: [PATCH 03/22] ARM: u300: Remove '0x's from U300 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-3-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/ste-u300.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index 8a1032c..a9da480 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -307,7 +307,7 @@
 		clocks = <&i2c0_clk>;
 		#address-cells = <1>;
 		#size-cells = <0>;
-		ab3100: ab3100 at 0x48 {
+		ab3100: ab3100 at 48 {
 			compatible = "stericsson,ab3100";
 			reg = <0x48>;
 			interrupt-parent = <&vica>;
@@ -385,10 +385,10 @@
 		clocks = <&i2c1_clk>;
 		#address-cells = <1>;
 		#size-cells = <0>;
-		fwcam0: fwcam at 0x10 {
+		fwcam0: fwcam at 10 {
 			reg = <0x10>;
 		};
-		fwcam1: fwcam at 0x5d {
+		fwcam1: fwcam at 5d {
 			reg = <0x5d>;
 		};
 	};
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:24 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:24 +0100
Subject: [PATCH 05/22] ARM: dts: bcm281xx: Remove '0x's from BCM11351 BRT DTS
 file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-5-git-send-email-lee.jones@linaro.org>

Cc: Christian Daudt <csd at broadcom.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/bcm11351-brt.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/bcm11351-brt.dts b/arch/arm/boot/dts/bcm11351-brt.dts
index 67ec524..fdace5d 100644
--- a/arch/arm/boot/dts/bcm11351-brt.dts
+++ b/arch/arm/boot/dts/bcm11351-brt.dts
@@ -27,18 +27,18 @@
 		status = "okay";
 	};
 
-	sdio0: sdio at 0x3f180000 {
+	sdio0: sdio at 3f180000 {
 		max-frequency = <48000000>;
 		status = "okay";
 	};
 
-	sdio1: sdio at 0x3f190000 {
+	sdio1: sdio at 3f190000 {
 		non-removable;
 		max-frequency = <48000000>;
 		status = "okay";
 	};
 
-	sdio3: sdio at 0x3f1b0000 {
+	sdio3: sdio at 3f1b0000 {
 		max-frequency = <48000000>;
 		status = "okay";
 	};
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:26 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:26 +0100
Subject: [PATCH 07/22] ARM: exynos: Remove '0x's from Exynos4110 DTSI file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-7-git-send-email-lee.jones@linaro.org>

Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/exynos4210.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index b7f358a..53e2527 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -72,7 +72,7 @@
 		};
 	};
 
-	clock: clock-controller at 0x10030000 {
+	clock: clock-controller at 10030000 {
 		compatible = "samsung,exynos4210-clock";
 		reg = <0x10030000 0x20000>;
 		#clock-cells = <1>;
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:29 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:29 +0100
Subject: [PATCH 10/22] ARM: dts: Remove '0x's from Exynos5420 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-10-git-send-email-lee.jones@linaro.org>

Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/exynos5420.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 8c54c4b..9e90d1e 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -59,7 +59,7 @@
 		};
 	};
 
-	clock: clock-controller at 0x10010000 {
+	clock: clock-controller at 10010000 {
 		compatible = "samsung,exynos5420-clock";
 		reg = <0x10010000 0x30000>;
 		#clock-cells = <1>;
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:27 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:27 +0100
Subject: [PATCH 08/22] ARM: dts: Remove '0x's from Exynos4x12 DTSI file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-8-git-send-email-lee.jones@linaro.org>

Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index 01da194..3aa2f06 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -28,7 +28,7 @@
 		pinctrl3 = &pinctrl_3;
 	};
 
-	clock: clock-controller at 0x10030000 {
+	clock: clock-controller at 10030000 {
 		compatible = "samsung,exynos4412-clock";
 		reg = <0x10030000 0x20000>;
 		#clock-cells = <1>;
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:30 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:30 +0100
Subject: [PATCH 11/22] ARM: dts: Remove '0x's from Exynos5440 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-11-git-send-email-lee.jones@linaro.org>

Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/exynos5440.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index ff7f5d8..0cedba4 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -20,7 +20,7 @@
 		spi0 = &spi_0;
 	};
 
-	clock: clock-controller at 0x160000 {
+	clock: clock-controller at 160000 {
 		compatible = "samsung,exynos5440-clock";
 		reg = <0x160000 0x1000>;
 		#clock-cells = <1>;
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:23 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:23 +0100
Subject: [PATCH 04/22] ARM: at91: dt: Remove '0x's from Animeo IP DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-4-git-send-email-lee.jones@linaro.org>

Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/animeo_ip.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/animeo_ip.dts b/arch/arm/boot/dts/animeo_ip.dts
index 3a1de9e..4cb0342 100644
--- a/arch/arm/boot/dts/animeo_ip.dts
+++ b/arch/arm/boot/dts/animeo_ip.dts
@@ -105,7 +105,7 @@
 				reg = <0x48000 0x8000>;
 			};
 
-			user_block at 0x50000 {
+			user_block at 50000 {
 				label = "user_block";
 				reg = <0x50000 0xb0000>;
 			};
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:28 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:28 +0100
Subject: [PATCH 09/22] ARM: dts: Remove '0x's from Exynos5250 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-9-git-send-email-lee.jones@linaro.org>

Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/exynos5250.dtsi | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index ef57277..24c0888 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -68,17 +68,17 @@
 		};
 	};
 
-	pd_gsc: gsc-power-domain at 0x10044000 {
+	pd_gsc: gsc-power-domain at 10044000 {
 		compatible = "samsung,exynos4210-pd";
 		reg = <0x10044000 0x20>;
 	};
 
-	pd_mfc: mfc-power-domain at 0x10044040 {
+	pd_mfc: mfc-power-domain at 10044040 {
 		compatible = "samsung,exynos4210-pd";
 		reg = <0x10044040 0x20>;
 	};
 
-	clock: clock-controller at 0x10010000 {
+	clock: clock-controller at 10010000 {
 		compatible = "samsung,exynos5250-clock";
 		reg = <0x10010000 0x30000>;
 		#clock-cells = <1>;
@@ -562,7 +562,7 @@
 		};
 	};
 
-	gsc_0:  gsc at 0x13e00000 {
+	gsc_0:  gsc at 13e00000 {
 		compatible = "samsung,exynos5-gsc";
 		reg = <0x13e00000 0x1000>;
 		interrupts = <0 85 0>;
@@ -571,7 +571,7 @@
 		clock-names = "gscl";
 	};
 
-	gsc_1:  gsc at 0x13e10000 {
+	gsc_1:  gsc at 13e10000 {
 		compatible = "samsung,exynos5-gsc";
 		reg = <0x13e10000 0x1000>;
 		interrupts = <0 86 0>;
@@ -580,7 +580,7 @@
 		clock-names = "gscl";
 	};
 
-	gsc_2:  gsc at 0x13e20000 {
+	gsc_2:  gsc at 13e20000 {
 		compatible = "samsung,exynos5-gsc";
 		reg = <0x13e20000 0x1000>;
 		interrupts = <0 87 0>;
@@ -589,7 +589,7 @@
 		clock-names = "gscl";
 	};
 
-	gsc_3:  gsc at 0x13e30000 {
+	gsc_3:  gsc at 13e30000 {
 		compatible = "samsung,exynos5-gsc";
 		reg = <0x13e30000 0x1000>;
 		interrupts = <0 88 0>;
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:31 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:31 +0100
Subject: [PATCH 12/22] ARM: dts: Remove '0x's from OMAP2420 H4 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-12-git-send-email-lee.jones@linaro.org>

Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/omap2420-h4.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/omap2420-h4.dts b/arch/arm/boot/dts/omap2420-h4.dts
index 224c08f..34cdecb 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -50,15 +50,15 @@
 			label = "bootloader";
 			reg = <0 0x20000>;
 		};
-		partition at 0x20000 {
+		partition at 20000 {
 			label = "params";
 			reg = <0x20000 0x20000>;
 		};
-		partition at 0x40000 {
+		partition at 40000 {
 			label = "kernel";
 			reg = <0x40000 0x200000>;
 		};
-		partition at 0x240000 {
+		partition at 240000 {
 			label = "file-system";
 			reg = <0x240000 0x3dc0000>;
 		};
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:32 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:32 +0100
Subject: [PATCH 13/22] ARM: dts: Remove '0x's from OMAP3 IGEP0020 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-13-git-send-email-lee.jones@linaro.org>

Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/omap3-igep0020.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
index e8c4828..f7a8122 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -99,19 +99,19 @@
 			label = "SPL";
 			reg = <0 0x100000>;
 		};
-		partition at 0x80000 {
+		partition at 80000 {
 			label = "U-Boot";
 			reg = <0x100000 0x180000>;
 		};
-		partition at 0x1c0000 {
+		partition at 1c0000 {
 			label = "Environment";
 			reg = <0x280000 0x100000>;
 		};
-		partition at 0x280000 {
+		partition at 280000 {
 			label = "Kernel";
 			reg = <0x380000 0x300000>;
 		};
-		partition at 0x780000 {
+		partition at 780000 {
 			label = "Filesystem";
 			reg = <0x680000 0x1f980000>;
 		};
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:33 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:33 +0100
Subject: [PATCH 14/22] ARM: dts: Remove '0x's from OMAP3 IGEP0030 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-14-git-send-email-lee.jones@linaro.org>

Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/omap3-igep0030.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts
index 644d0538..f628200 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -74,19 +74,19 @@
 			label = "SPL";
 			reg = <0 0x100000>;
 		};
-		partition at 0x80000 {
+		partition at 80000 {
 			label = "U-Boot";
 			reg = <0x100000 0x180000>;
 		};
-		partition at 0x1c0000 {
+		partition at 1c0000 {
 			label = "Environment";
 			reg = <0x280000 0x100000>;
 		};
-		partition at 0x280000 {
+		partition at 280000 {
 			label = "Kernel";
 			reg = <0x380000 0x300000>;
 		};
-		partition at 0x780000 {
+		partition at 780000 {
 			label = "Filesystem";
 			reg = <0x680000 0x1f980000>;
 		};
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:34 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:34 +0100
Subject: [PATCH 15/22] ARM: dts: Remove '0x's from OMAP3 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-15-git-send-email-lee.jones@linaro.org>

Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/omap3.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..16420ae 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -111,7 +111,7 @@
 			pinctrl-single,function-mask = <0x7f1f>;
 		};
 
-		omap3_pmx_wkup: pinmux at 0x48002a00 {
+		omap3_pmx_wkup: pinmux at 48002a00 {
 			compatible = "ti,omap3-padconf", "pinctrl-single";
 			reg = <0x48002a00 0x5c>;
 			#address-cells = <1>;
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:35 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:35 +0100
Subject: [PATCH 16/22] ARM: dts: Remove '0x's from OMAP3430 SDP DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-16-git-send-email-lee.jones@linaro.org>

Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/omap3430-sdp.dts | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
index e2249bc..281914e 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -84,15 +84,15 @@
 			label = "bootloader-nor";
 			reg = <0 0x40000>;
 		};
-		partition at 0x40000 {
+		partition at 40000 {
 			label = "params-nor";
 			reg = <0x40000 0x40000>;
 		};
-		partition at 0x80000 {
+		partition at 80000 {
 			label = "kernel-nor";
 			reg = <0x80000 0x200000>;
 		};
-		partition at 0x280000 {
+		partition at 280000 {
 			label = "filesystem-nor";
 			reg = <0x240000 0x7d80000>;
 		};
@@ -125,19 +125,19 @@
 			label = "xloader-nand";
 			reg = <0 0x80000>;
 		};
-		partition at 0x80000 {
+		partition at 80000 {
 			label = "bootloader-nand";
 			reg = <0x80000 0x140000>;
 		};
-		partition at 0x1c0000 {
+		partition at 1c0000 {
 			label = "params-nand";
 			reg = <0x1c0000 0xc0000>;
 		};
-		partition at 0x280000 {
+		partition at 280000 {
 			label = "kernel-nand";
 			reg = <0x280000 0x500000>;
 		};
-		partition at 0x780000 {
+		partition at 780000 {
 			label = "filesystem-nand";
 			reg = <0x780000 0x7880000>;
 		};
@@ -170,19 +170,19 @@
 			label = "xloader-onenand";
 			reg = <0 0x80000>;
 		};
-		partition at 0x80000 {
+		partition at 80000 {
 			label = "bootloader-onenand";
 			reg = <0x80000 0x40000>;
 		};
-		partition at 0xc0000 {
+		partition at c0000 {
 			label = "params-onenand";
 			reg = <0xc0000 0x20000>;
 		};
-		partition at 0xe0000 {
+		partition at e0000 {
 			label = "kernel-onenand";
 			reg = <0xe0000 0x200000>;
 		};
-		partition at 0x2e0000 {
+		partition at 2e0000 {
 			label = "filesystem-onenand";
 			reg = <0x2e0000 0xfd20000>;
 		};
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:36 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:36 +0100
Subject: [PATCH 17/22] ARM: dts: Remove '0x's from OMAP4 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-17-git-send-email-lee.jones@linaro.org>

Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/omap4.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..45708e1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -56,7 +56,7 @@
 		cache-level = <2>;
 	};
 
-	local-timer at 0x48240600 {
+	local-timer at 48240600 {
 		compatible = "arm,cortex-a9-twd-timer";
 		reg = <0x48240600 0x20>;
 		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_RAW(3) | IRQ_TYPE_LEVEL_HIGH)>;
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:37 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:37 +0100
Subject: [PATCH 18/22] ARM: dts: Remove '0x's from OMAP5 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-18-git-send-email-lee.jones@linaro.org>

Cc: Beno?t Cousson <b-cousson at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/omap5.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..be58604 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -604,7 +604,7 @@
 			ti,hwmods = "wd_timer2";
 		};
 
-		emif1: emif at 0x4c000000 {
+		emif1: emif at 4c000000 {
 			compatible	= "ti,emif-4d5";
 			ti,hwmods	= "emif1";
 			phy-type	= <2>; /* DDR PHY type: Intelli PHY */
@@ -615,7 +615,7 @@
 			hw-caps-temp-alert;
 		};
 
-		emif2: emif at 0x4d000000 {
+		emif2: emif at 4d000000 {
 			compatible	= "ti,emif-4d5";
 			ti,hwmods	= "emif2";
 			phy-type	= <2>; /* DDR PHY type: Intelli PHY */
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:38 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:38 +0100
Subject: [PATCH 19/22] ARM: shmobile: r8a7779: Remove '0x's from R8A7779 DTS
 file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-19-git-send-email-lee.jones@linaro.org>

Cc: Simon Horman <horms+renesas at verge.net.au>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/r8a7779.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 7f146c6..86bd487 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -65,7 +65,7 @@
 		sense-bitfield-width = <2>;
 	};
 
-	i2c0: i2c at 0xffc70000 {
+	i2c0: i2c at ffc70000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "renesas,rmobile-iic";
@@ -74,7 +74,7 @@
 		interrupts = <0 79 0x4>;
 	};
 
-	i2c1: i2c at 0xffc71000 {
+	i2c1: i2c at ffc71000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "renesas,rmobile-iic";
@@ -83,7 +83,7 @@
 		interrupts = <0 82 0x4>;
 	};
 
-	i2c2: i2c at 0xffc72000 {
+	i2c2: i2c at ffc72000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "renesas,rmobile-iic";
@@ -92,7 +92,7 @@
 		interrupts = <0 80 0x4>;
 	};
 
-	i2c3: i2c at 0xffc73000 {
+	i2c3: i2c at ffc73000 {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		compatible = "renesas,rmobile-iic";
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:39 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:39 +0100
Subject: [PATCH 20/22] ARM: SPEAr3xx: DT: Remove '0x's from Spear 300 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-20-git-send-email-lee.jones@linaro.org>

Cc: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/spear300.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/spear300.dtsi b/arch/arm/boot/dts/spear300.dtsi
index f79b3df..8970a4a 100644
--- a/arch/arm/boot/dts/spear300.dtsi
+++ b/arch/arm/boot/dts/spear300.dtsi
@@ -52,7 +52,7 @@
 			status = "disabled";
 		};
 
-		shirq: interrupt-controller at 0x50000000 {
+		shirq: interrupt-controller at 50000000 {
 			compatible = "st,spear300-shirq";
 			reg = <0x50000000 0x1000>;
 			interrupts = <28>;
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:40 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:40 +0100
Subject: [PATCH 21/22] ARM: SPEAr3xx: DT: Remove '0x's from Spear 310 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-21-git-send-email-lee.jones@linaro.org>

Cc: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/spear310.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/spear310.dtsi b/arch/arm/boot/dts/spear310.dtsi
index 9537208..dc263e4 100644
--- a/arch/arm/boot/dts/spear310.dtsi
+++ b/arch/arm/boot/dts/spear310.dtsi
@@ -40,7 +40,7 @@
 			status = "disabled";
 		};
 
-		shirq: interrupt-controller at 0xb4000000 {
+		shirq: interrupt-controller at b4000000 {
 			compatible = "st,spear310-shirq";
 			reg = <0xb4000000 0x1000>;
 			interrupts = <28 29 30 1>;
-- 
1.8.1.2



From lee.jones at linaro.org  Mon Jul 22 06:52:41 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 11:52:41 +0100
Subject: [PATCH 22/22] ARM: SPEAr3xx: DT: Remove '0x's from Spear 320 DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1374490361-25769-22-git-send-email-lee.jones@linaro.org>

Cc: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/spear320.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/spear320.dtsi b/arch/arm/boot/dts/spear320.dtsi
index ffea342..a82d76e5 100644
--- a/arch/arm/boot/dts/spear320.dtsi
+++ b/arch/arm/boot/dts/spear320.dtsi
@@ -55,7 +55,7 @@
 			status = "disabled";
 		};
 
-		shirq: interrupt-controller at 0xb3000000 {
+		shirq: interrupt-controller at b3000000 {
 			compatible = "st,spear320-shirq";
 			reg = <0xb3000000 0x1000>;
 			interrupts = <30 28 29 1>;
-- 
1.8.1.2



From julien.grall at linaro.org  Mon Jul 22 06:57:34 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Mon, 22 Jul 2013 11:57:34 +0100
Subject: [PATCH v3] xen/arm: enable PV control for ARM
Message-ID: <1374490654-13373-1-git-send-email-julien.grall@linaro.org>

Enable power management from the toolstack for ARM guest.

Signed-off-by: Julien Grall <julien.grall at linaro.org>

---
    Changes in v3:
        - Fix condition to compile cpu_hotplug.o
    Changes in v2:
        - Don't compile xen/cpu_hotplug.o with ARM64
---
 drivers/xen/Makefile |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 2bf461a..f185e8d 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,9 +1,8 @@
-ifneq ($(CONFIG_ARM),y)
-obj-y	+= manage.o
+ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
 obj-$(CONFIG_X86)			+= fallback.o
-obj-y	+= grant-table.o features.o events.o balloon.o time.o
+obj-y	+= grant-table.o features.o events.o balloon.o time.o manage.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
-- 
1.7.10.4



From viresh.kumar at linaro.org  Mon Jul 22 07:07:08 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 22 Jul 2013 16:37:08 +0530
Subject: [PATCH 20/22] ARM: SPEAr3xx: DT: Remove '0x's from Spear 300 DTS
 file
In-Reply-To: <1374490361-25769-20-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-20-git-send-email-lee.jones@linaro.org>
Message-ID: <CAKohponyAzjehntxVr75qXDV9=j9_aBzK=w10QZYBXtg+w+q9A@mail.gmail.com>

On 22 July 2013 16:22, Lee Jones <lee.jones at linaro.org> wrote:
> Cc: Viresh Kumar <viresh.kumar at linaro.org>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  arch/arm/boot/dts/spear300.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

For all three SPEAr Patches.

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>


From florian at openwrt.org  Mon Jul 22 07:09:34 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Mon, 22 Jul 2013 12:09:34 +0100
Subject: [PATCH] net: Add MOXA ART SoCs ethernet driver
In-Reply-To: <1374140806-12485-1-git-send-email-jonas.jensen@gmail.com>
References: <1374140806-12485-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <CAGVrzcYdisg5AXMBa5q74GPz7ckWeoXJ9H5di2CGN41VyZ_4vw@mail.gmail.com>

Hello Jonas,

A bunch of comments inline.

2013/7/18 Jonas Jensen <jonas.jensen at gmail.com>:
> The MOXA UC-711X hardware(s) has an ethernet controller that seem to be
> developed internally. The IC used is "RTL8201CP".
>
> Since there is no public documentation, this driver is mostly the one
> published by MOXA that has been heavily cleaned up / ported from linux 2.6.9.
>
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
> ---
>
> Notes:
>     Applies to next-20130716
>
>  .../devicetree/bindings/net/moxa,moxart-mac.txt    |  25 +
>  drivers/net/ethernet/Kconfig                       |   1 +
>  drivers/net/ethernet/Makefile                      |   1 +
>  drivers/net/ethernet/moxa/Kconfig                  |  30 ++
>  drivers/net/ethernet/moxa/Makefile                 |   6 +
>  drivers/net/ethernet/moxa/moxart_ether.c           | 544 +++++++++++++++++++++
>  drivers/net/ethernet/moxa/moxart_ether.h           | 525 ++++++++++++++++++++
>  7 files changed, 1132 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
>  create mode 100644 drivers/net/ethernet/moxa/Kconfig
>  create mode 100644 drivers/net/ethernet/moxa/Makefile
>  create mode 100644 drivers/net/ethernet/moxa/moxart_ether.c
>  create mode 100644 drivers/net/ethernet/moxa/moxart_ether.h
>
> diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
> new file mode 100644
> index 0000000..12e12a5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
> @@ -0,0 +1,25 @@
> +MOXA ART Ethernet Controller
> +
> +Required properties:
> +
> +- compatible : Should be "moxa,moxart-mac"
> +- reg : Should contain registers location and length
> +  index 0 : main register
> +  index 1 : mac address (stored on flash)

That is kind of unusual, since the MAC register is within the range of
the MAC base register, just read the MAC from the base register and
use that to fill in dev->dev_addr in your ndo_open() callback.

[snip]

> +static void moxart_mac_setup_desc_ring(struct net_device *ndev)
> +{
> +       struct moxart_mac_priv_t *priv = netdev_priv(ndev);
> +       struct tx_desc_t *txdesc;
> +       struct rx_desc_t *rxdesc;
> +       unsigned char *virtbuf;
> +       unsigned int phybuf;
> +       int i;
> +
> +       virtbuf = priv->virt_tx_buf_baseaddr;
> +       phybuf = priv->phy_tx_buf_baseaddr;
> +       for (i = 0; i < TX_DESC_NUM; i++,
> +               virtbuf += TX_BUF_SIZE, phybuf += TX_BUF_SIZE) {
> +               txdesc = &priv->virt_tx_desc_baseaddr[i];
> +               memset(txdesc, 0, sizeof(struct tx_desc_t));
> +               txdesc->txdes2.phy_tx_buf_baseaddr = phybuf;
> +               txdesc->txdes2.virt_tx_buf_baseaddr = virtbuf;
> +       }
> +       priv->virt_tx_desc_baseaddr[TX_DESC_NUM - 1].txdes1.ubit.edotr = 1;
> +       priv->tx_desc_now = 0;
> +
> +       virtbuf = priv->virt_rx_buf_baseaddr;
> +       phybuf = priv->phy_rx_buf_baseaddr;
> +       for (i = 0; i < RX_DESC_NUM; i++,
> +               virtbuf += RX_BUF_SIZE, phybuf += RX_BUF_SIZE) {
> +               rxdesc = &priv->virt_rx_desc_baseaddr[i];
> +               memset(rxdesc, 0, sizeof(struct rx_desc_t));
> +               rxdesc->rxdes0.ubit.rx_dma_own = 1;
> +               rxdesc->rxdes1.ubit.rx_buf_size = RX_BUF_SIZE;
> +               rxdesc->rxdes2.phy_rx_buf_baseaddr = phybuf;
> +               rxdesc->rxdes2.virt_rx_buf_baseaddr = virtbuf;
> +       }

Your RX path is supposed to be preallocating SKBs, create a DMA
mapping for them and then only SKB refilling would then happen when
you process a SKB in your RX handler. I do not see you doing it here.

> +       priv->virt_rx_desc_baseaddr[RX_DESC_NUM - 1].rxdes1.ubit.edorr = 1;
> +       priv->rx_desc_now = 0;
> +
> +       /* reset the MAC controler TX/RX desciptor base address */
> +       writel(priv->phy_tx_desc_baseaddr, priv->base + TXR_BADR_REG_OFFSET);
> +       writel(priv->phy_rx_desc_baseaddr, priv->base + RXR_BADR_REG_OFFSET);
> +}
> +
> +static int moxart_mac_open(struct net_device *ndev)
> +{
> +       struct moxart_mac_priv_t *priv = netdev_priv(ndev);
> +
> +       if (!is_valid_ether_addr(ndev->dev_addr))
> +               return -EADDRNOTAVAIL;
> +
> +       spin_lock_irq(&priv->txlock);
> +       moxart_mac_reset(ndev);
> +       moxart_update_mac_address(ndev);
> +       moxart_mac_setup_desc_ring(ndev);
> +       moxart_mac_enable(ndev);
> +       spin_unlock_irq(&priv->txlock);

Unless you did not properly disable interrupts at the MAC level,
taking a spinlock here does not seem to be required at all since the
various steps you call are done in the correct order.

> +       netif_start_queue(ndev);
> +
> +       netdev_dbg(ndev, "%s: IMR=0x%x, MACCR=0x%x\n",
> +                  __func__, readl(priv->base + IMR_REG_OFFSET),
> +                  readl(priv->base + MACCR_REG_OFFSET));
> +
> +       return 0;
> +}
> +
> +static int moxart_mac_stop(struct net_device *ndev)
> +{
> +       struct moxart_mac_priv_t *priv = netdev_priv(ndev);
> +
> +       netif_stop_queue(ndev);
> +       spin_lock_irq(&priv->txlock);
> +
> +       /* disable all interrupts */
> +       writel(0, priv->base + IMR_REG_OFFSET);
> +
> +       /* disable all functions */
> +       writel(0, priv->base + MACCR_REG_OFFSET);
> +
> +       spin_unlock_irq(&priv->txlock);

Same here, the serialisation is not required here once you have
disabled the interrupts at the MAC level. You should also free the RX
buffers and the potentially remaining transmit SKBs.

> +
> +       return 0;
> +}
> +
> +static void moxart_mac_recv(struct work_struct *ptr)
> +{
> +       struct net_device *ndev = (struct net_device *) ptr;
> +       struct moxart_mac_priv_t *priv = netdev_priv((struct net_device *)ptr);
> +       struct rx_desc_t *rxdesc;
> +       struct sk_buff *skb;
> +       unsigned int ui, len;
> +       int rxnow = priv->rx_desc_now;
> +       int loops = RX_DESC_NUM;

This screams to me: implement NAPI. You are doing all of the
processing in an interrupt handler, which runs in hard IRQ context,
this is bad for latency. This very specific function won't change that
much once you convert it to NAPI.

> +
> +repeat_recv:
> +       rxdesc = &priv->virt_rx_desc_baseaddr[rxnow];
> +       ui = rxdesc->rxdes0.ui;
> +
> +       if (ui & RXDMA_OWN)
> +               return;
> +
> +       if (ui & (RX_ERR | CRC_ERR | FTL | RUNT | RX_ODD_NB)) {
> +               netdev_err(ndev, "%s: packet error\n", __func__);
> +               priv->stats.rx_dropped++;
> +               priv->stats.rx_errors++;
> +               goto recv_finish;
> +       }
> +
> +       len = ui & RFL_MASK;
> +
> +       if (len > RX_BUF_SIZE)
> +               len = RX_BUF_SIZE;
> +
> +       skb = dev_alloc_skb(len + 2);

You should use netdev_alloc_skb_ip_align() here.

> +       if (skb == NULL) {
> +               netdev_err(ndev, "%s: dev_alloc_skb failed\n", __func__);
> +               priv->stats.rx_dropped++;
> +               goto recv_finish;
> +       }
> +
> +       skb_reserve(skb, 2);

And remove this.

> +       skb->dev = ndev;

eth_type_trans() already does this for you.

> +       memcpy(skb_put(skb, len), rxdesc->rxdes2.virt_rx_buf_baseaddr, len);

You should use a dma_unmap_single() operation here.

> +       netif_rx(skb);
> +       skb->protocol = eth_type_trans(skb, ndev);

I think these two steps are inverted, you should first call eth_type_trans().

> +       ndev->last_rx = jiffies;
> +       priv->stats.rx_packets++;
> +       priv->stats.rx_bytes += len;
> +       if (ui & MULTICAST_RXDES0)
> +               priv->stats.multicast++;
> +
> +recv_finish:
> +       rxdesc->rxdes0.ui = RXDMA_OWN;
> +       rxnow++;
> +       rxnow &= RX_DESC_NUM_MASK;
> +       priv->rx_desc_now = rxnow;
> +       if (loops-- > 0)
> +               goto repeat_recv;

Better code this with a while() loop directly, using gotos here is
silly and I believe this might be bad for your CPU branch predictor as
well.

> +}
> +
> +static irqreturn_t moxart_mac_interrupt(int irq, void *dev_id)
> +{
> +       struct net_device *ndev = (struct net_device *) dev_id;
> +       struct moxart_mac_priv_t *priv = netdev_priv(ndev);
> +       unsigned int ists = readl(priv->base + ISR_REG_OFFSET);
> +
> +       if (ists & RPKT_FINISH)
> +               moxart_mac_recv((void *) ndev);

Unnecessary void * casting here.

> +
> +       return IRQ_HANDLED;
> +}
> +
> +static int moxart_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> +{
> +       struct moxart_mac_priv_t *priv = netdev_priv(ndev);
> +       struct tx_desc_t *txdesc;
> +       int len;
> +       int txnow = priv->tx_desc_now;
> +
> +       spin_lock_irq(&priv->txlock);
> +       txdesc = &priv->virt_tx_desc_baseaddr[txnow];
> +       if (txdesc->txdes0.ubit.tx_dma_own) {
> +               netdev_err(ndev, "%s: no TX space for packet\n", __func__);
> +               priv->stats.tx_dropped++;
> +               goto xmit_final;
> +       }

You should return NETDEV_TX_BUSY here if there are no TX descriptors available.

> +
> +       len = skb->len > TX_BUF_SIZE ? TX_BUF_SIZE : skb->len;
> +       memcpy(txdesc->txdes2.virt_tx_buf_baseaddr, skb->data, len);

This looks wrong, you should get a TX descriptor for this SKB, and
then perform a DMA mapping of skb->data for skb->len to that specific
TX descriptor address and set the transmit descriptor control words as
you do below.

> +
> +       if (skb->len < ETH_ZLEN) {
> +               memset(&txdesc->txdes2.virt_tx_buf_baseaddr[skb->len],
> +                      0, ETH_ZLEN - skb->len);
> +               len = ETH_ZLEN;
> +       }
> +
> +       txdesc->txdes1.ubit.lts = 1;
> +       txdesc->txdes1.ubit.fts = 1;
> +       txdesc->txdes1.ubit.tx2_fic = 0;
> +       txdesc->txdes1.ubit.tx_ic = 0;
> +       txdesc->txdes1.ubit.tx_buf_size = len;
> +       txdesc->txdes0.ui = TXDMA_OWN;
> +
> +       /* start to send packet */
> +       writel(0xffffffff, priv->base + TXPD_REG_OFFSET);
> +
> +       txnow++;
> +       txnow &= TX_DESC_NUM_MASK;
> +       priv->tx_desc_now = txnow;
> +       ndev->trans_start = jiffies;
> +       priv->stats.tx_packets++;
> +       priv->stats.tx_bytes += len;

Incrementing statistics must happen in the transmit completion
handler. At this point there is no guarantee that the hardware really
processed your packet (your DMA engine could signal an error like no
carrier or anything like that).

> +
> +xmit_final:
> +       spin_unlock_irq(&priv->txlock);
> +       dev_kfree_skb_any(skb);

This looks wrong, transmit buffer reclaim should happen once
transmission is complete. Your interrupt handler do not handle the
XPKT_FINISH_M bit which seems to indicate transmit completion of
buffers.

[snip]

> +
> +static int moxart_mac_probe(struct platform_device *pdev)
> +{
> +       struct device *p_dev = &pdev->dev;
> +       struct device_node *node = p_dev->of_node;
> +       struct net_device *ndev;
> +       struct moxart_mac_priv_t *priv;
> +       struct resource *res;
> +       unsigned int irq;
> +       void *tmp;
> +
> +       ndev = alloc_etherdev(sizeof(struct moxart_mac_priv_t));
> +       if (!ndev)
> +               return -ENOMEM;
> +
> +       irq = irq_of_parse_and_map(node, 0);
> +
> +       priv = netdev_priv(ndev);
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       ndev->base_addr = res->start;
> +       priv->base = devm_ioremap_resource(p_dev, res);
> +       if (IS_ERR(priv->base)) {
> +               dev_err(p_dev, "%s: devm_ioremap_resource res_mac failed\n",
> +                       __func__);
> +               goto init_fail;
> +       }
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +
> +       /* the flash driver (physmap_of) requests the same region
> +        * so use ioremap instead of devm_ioremap_resource
> +        */
> +       priv->flash_base = ioremap(res->start, resource_size(res));
> +       if (IS_ERR(priv->flash_base)) {
> +               dev_err(p_dev, "%s: devm_ioremap_resource res_flash failed\n",
> +                       __func__);
> +               goto init_fail;
> +       }

As stated above from the Device Tree binding documentation, this is
unnecessary, since you have a get_mac() function.

> +
> +       spin_lock_init(&priv->txlock);
> +
> +       tmp = dma_alloc_coherent(NULL, sizeof(struct tx_desc_t) * TX_DESC_NUM,
> +                                (dma_addr_t *) &priv->phy_tx_desc_baseaddr,
> +                                GFP_DMA | GFP_KERNEL);
> +       priv->virt_tx_desc_baseaddr = (struct tx_desc_t *) tmp;
> +       if (priv->virt_tx_desc_baseaddr == NULL ||
> +           (priv->phy_tx_desc_baseaddr & 0x0f)) {
> +               netdev_err(ndev, "TX descriptor alloc failed\n");
> +               goto init_fail;
> +       }
> +
> +       tmp = dma_alloc_coherent(NULL, sizeof(struct rx_desc_t) * RX_DESC_NUM,
> +                                (dma_addr_t *)&priv->phy_rx_desc_baseaddr,
> +                                GFP_DMA | GFP_KERNEL);
> +       priv->virt_rx_desc_baseaddr = (struct rx_desc_t *) tmp;
> +       if (priv->virt_rx_desc_baseaddr == NULL ||
> +           (priv->phy_rx_desc_baseaddr & 0x0f)) {
> +               netdev_err(ndev, "RX descriptor alloc failed\n");
> +               goto init_fail;
> +       }
> +
> +       tmp = dma_alloc_coherent(NULL, TX_BUF_SIZE * TX_DESC_NUM,
> +                                (dma_addr_t *)&priv->phy_tx_buf_baseaddr,
> +                                GFP_DMA | GFP_KERNEL);
> +       priv->virt_tx_buf_baseaddr = (unsigned char *) tmp;
> +       if (priv->virt_tx_buf_baseaddr == NULL ||
> +           (priv->phy_tx_buf_baseaddr & 0x03)) {
> +               netdev_err(ndev, "TX buffer alloc failed\n");
> +               goto init_fail;
> +       }
> +
> +       tmp = dma_alloc_coherent(NULL, RX_BUF_SIZE * RX_DESC_NUM,
> +                                (dma_addr_t *)&priv->phy_rx_buf_baseaddr,
> +                                GFP_DMA | GFP_KERNEL);
> +       priv->virt_rx_buf_baseaddr = (unsigned char *) tmp;
> +       if (priv->virt_rx_buf_baseaddr == NULL ||
> +           (priv->phy_rx_buf_baseaddr & 0x03)) {
> +               netdev_err(ndev, "RX buffer alloc failed\n");
> +               goto init_fail;
> +       }

This pool of buffers looks unnecessary, as stated above, you should
rather perform DMA map_single/unmap_single operations instead.
--
Florian


From linux at arm.linux.org.uk  Mon Jul 22 07:06:56 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Jul 2013 12:06:56 +0100
Subject: [PATCH RFC v2 0/14] Clean up debugging support
In-Reply-To: <20130720164332.GA26625@lunn.ch>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
 <20130717170406.GR24642@n2100.arm.linux.org.uk>
 <20130720164332.GA26625@lunn.ch>
Message-ID: <20130722110656.GJ24642@n2100.arm.linux.org.uk>

On Sat, Jul 20, 2013 at 06:43:32PM +0200, Andrew Lunn wrote:
> On Wed, Jul 17, 2013 at 06:04:06PM +0100, Russell King - ARM Linux wrote:
> > On Tue, Jul 16, 2013 at 05:32:43PM +0100, Russell King - ARM Linux wrote:
> > > This is the second posting of this series, with a few additional patches
> > > on top to go a little further.  Changes since the last posting:
> > 
> > Okay, I think everyone is happy with this, and it's time to go into
> > linux-next, so it'll be visible in my tree from tomorrow.
> > 
> > Please keep the tested-by/acked-by etc coming.
> 
> Hi Russell
> 
> Maybe i'm blind, but i don't seem to be able to see this in linux
> next, or your git tree.
> 
> Has it been pushed out yet?

You are correct that I hadn't pushed it out.  I decided to wait for -rc2
because I have a copy of a fix in my tree which was already applied after
-rc1, so wanted to rebase first.  Anyway, it's been pushed out now.


From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:21:19 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:21:19 +0100
Subject: [PATCH v2 0/3] ARM/ARM64 architected timer updates
In-Reply-To: <1371575223-21702-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1371575223-21702-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492082-13686-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

This patch series adds support to configure the rate and enable the event
stream for architected timer. Since the timer control register is reset to
zero on warm boot, CPU PM notifier is added to re-initialse it.

Changes v1->v2:
1. Saved event stream divider value on cold reset path and re-used it
   in CPU PM notifier instead of calculating every time.
2. Rebased on v3.11-rc2(to avoid conflicts with __cpuinit* deletion)
3. Dropped "ARM/ARM64: arch_timer: remove __cpuinit attribute for
   arch_counter_set_user_access"(already done as part of __cpuinit*
   deletion)

Regards,
Sudeep


Sudeep KarkadaNagesha (2):
  ARM: arch_timer: add macros for bits in control register
  drivers: clocksource: add CPU PM notifier for ARM architected timer

Will Deacon (1):
  drivers: clocksource: configure event stream for ARM arch timer

 arch/arm/include/asm/arch_timer.h    | 10 ++++++--
 arch/arm64/include/asm/arch_timer.h  | 12 +++++++---
 drivers/clocksource/arm_arch_timer.c | 45 +++++++++++++++++++++++++++++++++++-
 include/clocksource/arm_arch_timer.h | 10 ++++++++
 4 files changed, 71 insertions(+), 6 deletions(-)

-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:21:21 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:21:21 +0100
Subject: [PATCH v2 2/3] ARM: arch_timer: add macros for bits in control
 register
In-Reply-To: <1374492082-13686-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1371575223-21702-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492082-13686-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492082-13686-3-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Add macros to describe the bitfields in the ARM architected timer
control register to make code easy to understand.

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Reviewed-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/include/asm/arch_timer.h    |  9 +++++++--
 arch/arm64/include/asm/arch_timer.h  | 10 ++++++++--
 include/clocksource/arm_arch_timer.h |  8 ++++++++
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h
index c3d9ef7..26c65ae 100644
--- a/arch/arm/include/asm/arch_timer.h
+++ b/arch/arm/include/asm/arch_timer.h
@@ -96,8 +96,13 @@ static inline void arch_counter_set_user_access(int divider)
 	asm volatile("mrc p15, 0, %0, c14, c1, 0" : "=r" (cntkctl));
 
 	/* disable user access to everything */
-	cntkctl &= ~((3 << 8) | (0xf << 4) | (3 << 0));
-	cntkctl |= (divider << 4) | (1 << 2);
+	cntkctl &= ~(ARCH_TIMER_USR_PT_ACCESS_EN
+			| ARCH_TIMER_USR_VT_ACCESS_EN
+			| ARCH_TIMER_EVT_TRIGGER_MASK
+			| ARCH_TIMER_USR_VCT_ACCESS_EN
+			| ARCH_TIMER_USR_PCT_ACCESS_EN);
+	cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT)
+			| ARCH_TIMER_VIRT_EVT_EN;
 
 	asm volatile("mcr p15, 0, %0, c14, c1, 0" : : "r" (cntkctl));
 }
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index 8c1e42f..3494102 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -103,10 +103,16 @@ static inline void arch_counter_set_user_access(int divider)
 
 	/* Disable user access to the timers and the physical counter. */
 	asm volatile("mrs	%0, cntkctl_el1" : "=r" (cntkctl));
-	cntkctl &= ~((3 << 8) | (0xf << 4) | (1 << 0));
+	cntkctl &= ~(ARCH_TIMER_USR_PT_ACCESS_EN
+			| ARCH_TIMER_USR_VT_ACCESS_EN
+			| ARCH_TIMER_EVT_TRIGGER_MASK
+			| ARCH_TIMER_USR_PCT_ACCESS_EN)
 
 	/* Enable user access to the virtual counter and frequency. */
-	cntkctl |= (divider << 4) | (1 << 2) | (1 << 1);
+	cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT)
+			| ARCH_TIMER_VIRT_EVT_EN
+			| ARCH_TIMER_USR_VCT_ACCESS_EN;
+
 	asm volatile("msr	cntkctl_el1, %0" : : "r" (cntkctl));
 }
 
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index 24dc140..c4d0fc4 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -29,6 +29,14 @@
 #define ARCH_TIMER_PHYS_ACCESS		0
 #define ARCH_TIMER_VIRT_ACCESS		1
 
+#define ARCH_TIMER_USR_PCT_ACCESS_EN	(1 << 0) /* physical counter */
+#define ARCH_TIMER_USR_VCT_ACCESS_EN	(1 << 1) /* virtual counter */
+#define ARCH_TIMER_VIRT_EVT_EN		(1 << 2)
+#define ARCH_TIMER_EVT_TRIGGER_SHIFT	(4)
+#define ARCH_TIMER_EVT_TRIGGER_MASK	(0xF << ARCH_TIMER_EVT_TRIGGER_SHIFT)
+#define ARCH_TIMER_USR_VT_ACCESS_EN	(1 << 8) /* virtual timer registers */
+#define ARCH_TIMER_USR_PT_ACCESS_EN	(1 << 9) /* physical timer registers */
+
 #define ARCH_TIMER_EVT_STREAM_FREQ	10000	/* 100us */
 
 #ifdef CONFIG_ARM_ARCH_TIMER
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:21:22 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:21:22 +0100
Subject: [PATCH v2 3/3] drivers: clocksource: add CPU PM notifier for ARM
 architected timer
In-Reply-To: <1374492082-13686-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1371575223-21702-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492082-13686-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492082-13686-4-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Few control settings done in architected timer as part of initialisation
can be lost when CPU enters deeper power states. They need to be
re-initialised when the CPU is (warm)reset again.

This patch adds CPU PM notifiers to do the timer initialisation on warm
resets. It also save the event stream divider value calculated during
cold reset and uses the same in warm reset path.

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Reviewed-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/clocksource/arm_arch_timer.c | 38 +++++++++++++++++++++++++++++++++++-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 6301ee5..7057552 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -13,6 +13,7 @@
 #include <linux/device.h>
 #include <linux/smp.h>
 #include <linux/cpu.h>
+#include <linux/cpu_pm.h>
 #include <linux/clockchips.h>
 #include <linux/interrupt.h>
 #include <linux/of_irq.h>
@@ -39,6 +40,8 @@ static struct clock_event_device __percpu *arch_timer_evt;
 
 static bool arch_timer_use_virtual = true;
 
+static int arch_timer_evtstream_div;
+
 /*
  * Architected system timer support.
  */
@@ -160,7 +163,9 @@ static int arch_timer_setup(struct clock_event_device *clk)
 	pos = fls(evt_stream_div);
 	if (pos > 1 && !(evt_stream_div & (1 << (pos - 2))))
 		pos--;
-	arch_counter_set_user_access(min(pos, 15));
+	/* save divider value for use in CPU PM notifier */
+	arch_timer_evtstream_div = min(pos, 15);
+	arch_counter_set_user_access(arch_timer_evtstream_div);
 
 	return 0;
 }
@@ -267,6 +272,31 @@ static struct notifier_block arch_timer_cpu_nb = {
 	.notifier_call = arch_timer_cpu_notify,
 };
 
+#ifdef CONFIG_CPU_PM
+static int arch_timer_cpu_pm_notify(struct notifier_block *self,
+				    unsigned long action, void *hcpu)
+{
+	if (action == CPU_PM_EXIT)
+		arch_counter_set_user_access(arch_timer_evtstream_div);
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block arch_timer_cpu_pm_notifier = {
+	.notifier_call = arch_timer_cpu_pm_notify,
+};
+
+static int __init arch_timer_cpu_pm_init(void)
+{
+	return cpu_pm_register_notifier(&arch_timer_cpu_pm_notifier);
+}
+#else
+static int __init arch_timer_cpu_pm_init(void)
+{
+	return 0;
+}
+#endif
+
 static int __init arch_timer_register(void)
 {
 	int err;
@@ -316,11 +346,17 @@ static int __init arch_timer_register(void)
 	if (err)
 		goto out_free_irq;
 
+	err = arch_timer_cpu_pm_init();
+	if (err)
+		goto out_unreg_notify;
+
 	/* Immediately configure the timer on the boot CPU */
 	arch_timer_setup(this_cpu_ptr(arch_timer_evt));
 
 	return 0;
 
+out_unreg_notify:
+	unregister_cpu_notifier(&arch_timer_cpu_nb);
 out_free_irq:
 	if (arch_timer_use_virtual)
 		free_percpu_irq(arch_timer_ppi[VIRT_PPI], arch_timer_evt);
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:21:20 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:21:20 +0100
Subject: [PATCH v2 1/3] drivers: clocksource: configure event stream for ARM
 arch timer
In-Reply-To: <1374492082-13686-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1371575223-21702-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492082-13686-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492082-13686-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Will Deacon <will.deacon at arm.com>

The ARM architected timer can generate events (used for waking up
CPUs executing the wfe instruction) at a frequency represented as a
power-of-2 divisor of the clock rate.

This patch configures the event stream, aiming for a period of 100us
between events. This can be used to implement wfe-based timeouts for
userspace locking implementations.

Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/arch_timer.h    | 5 +++--
 arch/arm64/include/asm/arch_timer.h  | 6 +++---
 drivers/clocksource/arm_arch_timer.c | 9 ++++++++-
 include/clocksource/arm_arch_timer.h | 2 ++
 4 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h
index e406d57..c3d9ef7 100644
--- a/arch/arm/include/asm/arch_timer.h
+++ b/arch/arm/include/asm/arch_timer.h
@@ -89,14 +89,15 @@ static inline u64 arch_counter_get_cntvct(void)
 	return cval;
 }
 
-static inline void arch_counter_set_user_access(void)
+static inline void arch_counter_set_user_access(int divider)
 {
 	u32 cntkctl;
 
 	asm volatile("mrc p15, 0, %0, c14, c1, 0" : "=r" (cntkctl));
 
 	/* disable user access to everything */
-	cntkctl &= ~((3 << 8) | (7 << 0));
+	cntkctl &= ~((3 << 8) | (0xf << 4) | (3 << 0));
+	cntkctl |= (divider << 4) | (1 << 2);
 
 	asm volatile("mcr p15, 0, %0, c14, c1, 0" : : "r" (cntkctl));
 }
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index 98abd47..8c1e42f 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -97,16 +97,16 @@ static inline u32 arch_timer_get_cntfrq(void)
 	return val;
 }
 
-static inline void arch_counter_set_user_access(void)
+static inline void arch_counter_set_user_access(int divider)
 {
 	u32 cntkctl;
 
 	/* Disable user access to the timers and the physical counter. */
 	asm volatile("mrs	%0, cntkctl_el1" : "=r" (cntkctl));
-	cntkctl &= ~((3 << 8) | (1 << 0));
+	cntkctl &= ~((3 << 8) | (0xf << 4) | (1 << 0));
 
 	/* Enable user access to the virtual counter and frequency. */
-	cntkctl |= (1 << 1);
+	cntkctl |= (divider << 4) | (1 << 2) | (1 << 1);
 	asm volatile("msr	cntkctl_el1, %0" : : "r" (cntkctl));
 }
 
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index ffadd83..6301ee5 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -125,6 +125,8 @@ static int arch_timer_set_next_event_phys(unsigned long evt,
 
 static int arch_timer_setup(struct clock_event_device *clk)
 {
+	int evt_stream_div, pos;
+
 	clk->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP;
 	clk->name = "arch_sys_timer";
 	clk->rating = 450;
@@ -153,7 +155,12 @@ static int arch_timer_setup(struct clock_event_device *clk)
 			enable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI], 0);
 	}
 
-	arch_counter_set_user_access();
+	/* Find the closest power of two to the divisor */
+	evt_stream_div = arch_timer_rate / ARCH_TIMER_EVT_STREAM_FREQ;
+	pos = fls(evt_stream_div);
+	if (pos > 1 && !(evt_stream_div & (1 << (pos - 2))))
+		pos--;
+	arch_counter_set_user_access(min(pos, 15));
 
 	return 0;
 }
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index c463ce9..24dc140 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -29,6 +29,8 @@
 #define ARCH_TIMER_PHYS_ACCESS		0
 #define ARCH_TIMER_VIRT_ACCESS		1
 
+#define ARCH_TIMER_EVT_STREAM_FREQ	10000	/* 100us */
+
 #ifdef CONFIG_ARM_ARCH_TIMER
 
 extern u32 arch_timer_get_rate(void);
-- 
1.8.1.2




From linux at arm.linux.org.uk  Mon Jul 22 07:24:33 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Jul 2013 12:24:33 +0100
Subject: [PATCH] ARM: debug: use generic option for ep93xx PL10x debug port
In-Reply-To: <201307171048.17430.hartleys@visionengravers.com>
References: <201307171048.17430.hartleys@visionengravers.com>
Message-ID: <20130722112433.GK24642@n2100.arm.linux.org.uk>

On Wed, Jul 17, 2013 at 10:48:16AM -0700, H Hartley Sweeten wrote:
> The generic option DEBUG_LL_UART_PL01X is now used to select the UART
> type for the kernel low-level debugging on the ep93xx platform. This
> enables two config options to provide the physical and virtual base
> address of the debug UART.
> 
> Use the generic options instead of providing platform specific options
> to select the debug UART.
> 
> UART1 is selected with:  DEBUG_UART_PHYS = 0x808c0000
>                          DEBUG_UART_VIRT = 0xfedc0000
> 
> UART2 is selected with:  DEBUG_UART_PHYS = 0x808d0000
>                          DEBUG_UART_VIRT = 0xfedd0000
> 
> UART3 is selected with:  DEBUG_UART_PHYS = 0x808e0000
>                          DEBUG_UART_VIRT = 0xfede0000
> 
> The selected UART must already be initialized by the bootloader. If it
> isn't setup nothing will appear (which might be desired).
> 
> Signed-off-by: H Hartley Sweeten <hsweeten at visionengravers.com>
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> Cc: Ryan Mallon <rmallon at gmail.com>
> ---
> This applies on top of Russell King's "Clean up the debugging support".

Please put this in the patch system; I'll get a round tuit maybe later
this week, if not next week.


From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:14 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:14 +0100
Subject: [PATCH v3 03/16] driver/core: cpu: initialize of_node in cpu's device
 struture
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-4-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

CPUs are also registered as devices but the of_node in these cpu
devices are not initialized. Currently different drivers requiring
to access cpu device node are parsing the nodes themselves and
initialising the of_node in cpu device.

The of_node in all the cpu devices needs to be initialized properly
and at one place. The best place to update this is CPU subsystem
driver when registering the cpu devices.

The OF/DT core library now provides of_get_cpu_node to retrieve a cpu
device node for a given logical index by abstracting the architecture
specific details.

This patch uses of_get_cpu_node to assign of_node when registering the
cpu devices.

Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Acked-by: Rob Herring <rob.herring at calxeda.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/base/cpu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 4c358bc..ea51c6d 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -14,6 +14,7 @@
 #include <linux/slab.h>
 #include <linux/percpu.h>
 #include <linux/acpi.h>
+#include <linux/of.h>
 
 #include "base.h"
 
@@ -289,6 +290,7 @@ int register_cpu(struct cpu *cpu, int num)
 	cpu->dev.release = cpu_device_release;
 	cpu->dev.offline_disabled = !cpu->hotpluggable;
 	cpu->dev.offline = !cpu_online(num);
+	cpu->dev.of_node = of_get_cpu_node(num);
 #ifdef CONFIG_ARCH_HAS_CPU_AUTOPROBE
 	cpu->dev.bus->uevent = arch_cpu_uevent;
 #endif
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:12 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:12 +0100
Subject: [PATCH v3 01/16] of: add support for retrieving cpu node for a given
 logical cpu index
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Currently different drivers requiring to access cpu device node are
parsing the device tree themselves. Since the ordering in the DT need
not match the logical cpu ordering, the parsing logic needs to consider
that. However, this has resulted in lots of code duplication and in some
cases even incorrect logic.

It's better to consolidate them by adding support for getting cpu
device node for a given logical cpu index in DT core library. However
logical to physical index mapping can be architecture specific.

This patch adds of_get_cpu_node to retrieve a cpu device node for a
given logical cpu index. The default matching of the physical id to the
logical cpu index can be overridden by architecture specific code.

It is recommended to use these helper function only in pre-SMP/early
initialisation stages to retrieve CPU device node pointers in logical
ordering. Once the cpu devices are registered, it can be retrieved easily
from cpu device of_node which avoids unnecessary parsing and matching.

Acked-by: Rob Herring <rob.herring at calxeda.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/of/base.c  | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of.h |  6 +++++
 2 files changed, 78 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5c54279..1e690bf 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -230,6 +230,78 @@ const void *of_get_property(const struct device_node *np, const char *name,
 }
 EXPORT_SYMBOL(of_get_property);
 
+/*
+ * arch_match_cpu_phys_id - Match the given logical CPU and physical id
+ *
+ * @cpu: logical index of a cpu
+ * @phys_id: physical identifier of a cpu
+ *
+ * CPU logical to physical index mapping is architecture specific.
+ * However this __weak function provides a default match of physical
+ * id to logical cpu index.
+ *
+ * Returns true if the physical identifier and the logical index correspond
+ * to the same cpu, false otherwise.
+ */
+bool __weak arch_match_cpu_phys_id(int cpu, u64 phys_id)
+{
+	return (u32)phys_id == cpu;
+}
+
+/**
+ * of_get_cpu_node - Get device node associated with the given logical CPU
+ *
+ * @cpu: CPU number(logical index) for which device node is required
+ *
+ * The main purpose of this function is to retrieve the device node for the
+ * given logical CPU index. It should be used to intialize the of_node in
+ * cpu device. Once of_node in cpu device is populated, all the further
+ * references can use that instead.
+ *
+ * CPU logical to physical index mapping is architecture specific and is built
+ * before booting secondary cores. This function uses arch_match_cpu_phys_id
+ * which can be overridden by architecture specific implementation.
+ *
+ * Returns a node pointer for the logical cpu if found, else NULL.
+ */
+struct device_node *of_get_cpu_node(int cpu)
+{
+	struct device_node *cpun, *cpus;
+	const __be32 *cell;
+	u64 hwid;
+	int ac, prop_len;
+
+	cpus = of_find_node_by_path("/cpus");
+	if (!cpus) {
+		pr_warn("Missing cpus node, bailing out\n");
+		return NULL;
+	}
+
+	if (of_property_read_u32(cpus, "#address-cells", &ac)) {
+		pr_warn("%s: missing #address-cells\n", cpus->full_name);
+		ac = of_n_addr_cells(cpus);
+	}
+
+	for_each_child_of_node(cpus, cpun) {
+		if (of_node_cmp(cpun->type, "cpu"))
+			continue;
+		cell = of_get_property(cpun, "reg", &prop_len);
+		if (!cell) {
+			pr_warn("%s: missing reg property\n", cpun->full_name);
+			continue;
+		}
+		prop_len /= sizeof(*cell);
+		while (prop_len) {
+			hwid = of_read_number(cell, ac);
+			prop_len -= ac;
+			if (arch_match_cpu_phys_id(cpu, hwid))
+				return cpun;
+		}
+	}
+
+	return NULL;
+}
+
 /** Checks if the given "compat" string matches one of the strings in
  * the device's "compatible" property
  */
diff --git a/include/linux/of.h b/include/linux/of.h
index 1fd08ca..9e82812 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -266,6 +266,7 @@ extern int of_device_is_available(const struct device_node *device);
 extern const void *of_get_property(const struct device_node *node,
 				const char *name,
 				int *lenp);
+extern struct device_node *of_get_cpu_node(int cpu);
 #define for_each_property_of_node(dn, pp) \
 	for (pp = dn->properties; pp != NULL; pp = pp->next)
 
@@ -459,6 +460,11 @@ static inline const void *of_get_property(const struct device_node *node,
 	return NULL;
 }
 
+static inline struct device_node *of_get_cpu_node(int cpu)
+{
+	return NULL;
+}
+
 static inline int of_property_read_u64(const struct device_node *np,
 				       const char *propname, u64 *out_value)
 {
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:13 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:13 +0100
Subject: [PATCH v3 02/16] ARM: DT/kernel: define ARM specific
 arch_match_cpu_phys_id
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-3-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

OF/DT core library now provides architecture specific hook to match the
logical cpu index with the corresponding physical identifier. Most of the
cpu DT node parsing and initialisation is contained in devtree.c. So it's
better to define ARM specific arch_match_cpu_phys_id there.

This mainly helps to avoid replication of the code doing CPU node parsing
and physical(MPIDR) to logical mapping.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Acked-by: Rob Herring <rob.herring at calxeda.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/kernel/devtree.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 5859c8b..2ee8a17 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -169,6 +169,11 @@ void __init arm_dt_init_cpu_maps(void)
 	}
 }
 
+bool arch_match_cpu_phys_id(int cpu, u64 phys_id)
+{
+	return (phys_id & MPIDR_HWID_BITMASK) == cpu_logical_map(cpu);
+}
+
 /**
  * setup_machine_fdt - Machine setup when an dtb was passed to the kernel
  * @dt_phys: physical address of dt blob
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:17 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:17 +0100
Subject: [PATCH v3 06/16] drivers/bus: arm-cci: avoid parsing DT for cpu
 device nodes
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-7-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Since the CPU device nodes can be retrieved using arch_of_get_cpu_node,
we can use it to avoid parsing the cpus node searching the cpu nodes and
mapping to logical index.

This patch removes parsing DT for cpu nodes by using of_get_cpu_node.

Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/bus/arm-cci.c | 28 +++++++---------------------
 1 file changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 7332889..7dd891c 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -122,17 +122,8 @@ EXPORT_SYMBOL_GPL(cci_ace_get_port);
 
 static void __init cci_ace_init_ports(void)
 {
-	int port, ac, cpu;
-	u64 hwid;
-	const u32 *cell;
-	struct device_node *cpun, *cpus;
-
-	cpus = of_find_node_by_path("/cpus");
-	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
-		return;
-
-	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
-		ac = of_n_addr_cells(cpus);
+	int port, cpu;
+	struct device_node *cpun;
 
 	/*
 	 * Port index look-up speeds up the function disabling ports by CPU,
@@ -141,18 +132,13 @@ static void __init cci_ace_init_ports(void)
 	 * The stashed index array is initialized for all possible CPUs
 	 * at probe time.
 	 */
-	for_each_child_of_node(cpus, cpun) {
-		if (of_node_cmp(cpun->type, "cpu"))
-			continue;
-		cell = of_get_property(cpun, "reg", NULL);
-		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
-			continue;
-
-		hwid = of_read_number(cell, ac);
-		cpu = get_logical_index(hwid & MPIDR_HWID_BITMASK);
+	for_each_possible_cpu(cpu) {
+		/* too early to use cpu->of_node */
+		cpun = of_get_cpu_node(cpu);
 
-		if (cpu < 0 || !cpu_possible(cpu))
+		if (WARN(!cpun, "Missing cpu device node\n"))
 			continue;
+
 		port = __cci_ace_get_port(cpun, ACE_PORT);
 		if (port < 0)
 			continue;
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:16 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:16 +0100
Subject: [PATCH v3 05/16] ARM: mvebu: remove device tree parsing for cpu nodes
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-6-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Currently set_secondary_cpus_clock assume the CPU logical ordering
and the MPDIR in DT are same, which is incorrect.

Since the CPU device nodes can be retrieved in the logical ordering
using the DT helper, we can remove the devices tree parsing.

This patch removes DT parsing by making use of of_get_cpu_node.

Cc: Gregory Clement <gregory.clement at free-electrons.com>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Jason Cooper <jason at lakedaemon.net>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/mach-mvebu/platsmp.c | 52 ++++++++++++++++++++-----------------------
 1 file changed, 24 insertions(+), 28 deletions(-)

diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index ce81d30..001dd42 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -23,51 +23,47 @@
 #include <linux/of.h>
 #include <linux/mbus.h>
 #include <asm/cacheflush.h>
+#include <asm/prom.h>
 #include <asm/smp_plat.h>
 #include "common.h"
 #include "armada-370-xp.h"
 #include "pmsu.h"
 #include "coherency.h"
 
+static struct clk *__init get_cpu_clk(int cpu)
+{
+	struct clk *cpu_clk;
+	struct device_node *np = of_get_cpu_node(cpu);
+
+	if (WARN(!np, "missing cpu node\n"))
+		return NULL;
+	cpu_clk = of_clk_get(np, 0);
+	if (WARN_ON(IS_ERR(cpu_clk)))
+		return NULL;
+	return cpu_clk;
+}
+
 void __init set_secondary_cpus_clock(void)
 {
-	int thiscpu;
+	int thiscpu, cpu;
 	unsigned long rate;
-	struct clk *cpu_clk = NULL;
-	struct device_node *np = NULL;
+	struct clk *cpu_clk;
 
 	thiscpu = smp_processor_id();
-	for_each_node_by_type(np, "cpu") {
-		int err;
-		int cpu;
-
-		err = of_property_read_u32(np, "reg", &cpu);
-		if (WARN_ON(err))
-			return;
-
-		if (cpu == thiscpu) {
-			cpu_clk = of_clk_get(np, 0);
-			break;
-		}
-	}
-	if (WARN_ON(IS_ERR(cpu_clk)))
+	cpu_clk = get_cpu_clk(thiscpu);
+	if (!cpu_clk)
 		return;
 	clk_prepare_enable(cpu_clk);
 	rate = clk_get_rate(cpu_clk);
 
 	/* set all the other CPU clk to the same rate than the boot CPU */
-	for_each_node_by_type(np, "cpu") {
-		int err;
-		int cpu;
-
-		err = of_property_read_u32(np, "reg", &cpu);
-		if (WARN_ON(err))
+	for_each_possible_cpu(cpu) {
+		if (cpu == thiscpu)
+			continue;
+		cpu_clk = get_cpu_clk(cpu);
+		if (!cpu_clk)
 			return;
-
-		if (cpu != thiscpu) {
-			cpu_clk = of_clk_get(np, 0);
-			clk_set_rate(cpu_clk, rate);
-		}
+		clk_set_rate(cpu_clk, rate);
 	}
 }
 
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:11 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:11 +0100
Subject: [PATCH v3 00/16] DT/core: update cpu device of_node
In-Reply-To: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

As more and more information is getting added into the cpu node, the number
of drivers needing to parse the device tree for CPU nodes are increasing.
Most of the time, the information needed from the cpu node is preferred
in the logical CPU order. Hence many drivers first parse and search the
CPU node, match them to logical index if needed and then search for the
required property inside a particular cpu node. Some of them assume the
logical and physical CPU ordering to be same which is incorrect.

This patch series initialises the of_node in all the cpu devices when
registering the CPU device.
1. This avoids different drivers having to parse the cpu nodes to obtain
   different attributes like operating points, latency,...etc.
2. This handles different physical and logical cpu ordering which is not
   the case in current code.
3. Also all the cpu nodes will have their of_node initialised correctly.
   Currently different drivers assign them partially and incorrectly.
4. Removes all the reduntant parsing in various drivers.

Changes v2->v3:
1. Added new OF helper to get of_node from the cpu logical index.
   With the use of this help, removed lots of duplicated code from
   cpufreq drivers.
2. Fixed issue with property length calculation in of_get_cpu_node.
   (previously had assumed of_get_property returns number of cells)
3. Changed return type of arch_match_cpu_phys_id to bool(as suggested by Nico)
4. Re-ordered patch 2 and 3, and few typo fixes.
5. Rebased on v3.11-rc2(to avoid any conflicts with __cpuinit* deletion)

Changes v1->v2:
1. Moved most of arch_of_get_cpu_node to OF/DT core as of_get_cpu_node
   adding a provision for architecture specific hooks for matching
   logical and physical ids.
2. Extended removal of DT cpu node parsing to PPC cpufreq drivers
3. Added Acks from Viresh and Shawn

Regards,
Sudeep

Sudeep KarkadaNagesha (16):
  of: add support for retrieving cpu node for a given logical cpu index
  ARM: DT/kernel: define ARM specific arch_match_cpu_phys_id
  driver/core: cpu: initialize of_node in cpu's device struture
  ARM: topology: remove hwid/MPIDR dependency from cpu_capacity
  ARM: mvebu: remove device tree parsing for cpu nodes
  drivers/bus: arm-cci: avoid parsing DT for cpu device nodes
  of/device: add helper to get cpu device node from logical cpu index
  cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
  cpufreq: highbank-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: spear-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: arm_big_little: remove device tree parsing for cpu nodes
  cpufreq: maple-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: pmac64-cpufreq: remove device tree parsing for cpu nodes
  cpufreq: pmac32-cpufreq: remove device tree parsing for cpu nodes

 arch/arm/kernel/devtree.c           |  5 +++
 arch/arm/kernel/topology.c          | 61 ++++++++++---------------------
 arch/arm/mach-imx/mach-imx6q.c      |  3 +-
 arch/arm/mach-mvebu/platsmp.c       | 52 +++++++++++++--------------
 drivers/base/cpu.c                  |  2 ++
 drivers/bus/arm-cci.c               | 28 ++++-----------
 drivers/cpufreq/arm_big_little_dt.c | 40 ++++++++-------------
 drivers/cpufreq/cpufreq-cpu0.c      | 23 +++---------
 drivers/cpufreq/highbank-cpufreq.c  | 18 ++++------
 drivers/cpufreq/imx6q-cpufreq.c     |  4 +--
 drivers/cpufreq/kirkwood-cpufreq.c  |  8 +++--
 drivers/cpufreq/maple-cpufreq.c     | 23 ++----------
 drivers/cpufreq/pmac32-cpufreq.c    |  5 +--
 drivers/cpufreq/pmac64-cpufreq.c    | 47 ++++++------------------
 drivers/cpufreq/spear-cpufreq.c     |  4 +--
 drivers/of/base.c                   | 72 +++++++++++++++++++++++++++++++++++++
 include/linux/of.h                  |  6 ++++
 include/linux/of_device.h           | 15 ++++++++
 18 files changed, 200 insertions(+), 216 deletions(-)

-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:19 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:19 +0100
Subject: [PATCH v3 08/16] cpufreq: imx6q-cpufreq: remove device tree parsing
 for cpu nodes
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-9-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Acked-by: Shawn Guo <shawn.guo at linaro.org>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/mach-imx/mach-imx6q.c  | 3 +--
 drivers/cpufreq/imx6q-cpufreq.c | 4 +---
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 7be13f8..a02f275 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -254,13 +254,12 @@ static void __init imx6q_opp_init(struct device *cpu_dev)
 {
 	struct device_node *np;
 
-	np = of_find_node_by_path("/cpus/cpu at 0");
+	np = of_node_get(cpu_dev->of_node);
 	if (!np) {
 		pr_warn("failed to find cpu0 node\n");
 		return;
 	}
 
-	cpu_dev->of_node = np;
 	if (of_init_opp_table(cpu_dev)) {
 		pr_warn("failed to init OPP table\n");
 		goto put_node;
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index e37cdae..b16632b 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -221,14 +221,12 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev)
 
 	cpu_dev = &pdev->dev;
 
-	np = of_find_node_by_path("/cpus/cpu at 0");
+	np = of_node_get(cpu_dev->of_node);
 	if (!np) {
 		dev_err(cpu_dev, "failed to find cpu0 node\n");
 		return -ENOENT;
 	}
 
-	cpu_dev->of_node = np;
-
 	arm_clk = devm_clk_get(cpu_dev, "arm");
 	pll1_sys_clk = devm_clk_get(cpu_dev, "pll1_sys");
 	pll1_sw_clk = devm_clk_get(cpu_dev, "pll1_sw");
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:20 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:20 +0100
Subject: [PATCH v3 09/16] cpufreq: cpufreq-cpu0: remove device tree parsing
 for cpu nodes
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-10-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Acked-by: Shawn Guo <shawn.guo at linaro.org>
Acked-by: Rob Herring <rob.herring at calxeda.com>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/cpufreq-cpu0.c | 23 ++++-------------------
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..5b05c26 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -174,29 +174,17 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
 
 static int cpu0_cpufreq_probe(struct platform_device *pdev)
 {
-	struct device_node *np, *parent;
+	struct device_node *np;
 	int ret;
 
-	parent = of_find_node_by_path("/cpus");
-	if (!parent) {
-		pr_err("failed to find OF /cpus\n");
-		return -ENOENT;
-	}
-
-	for_each_child_of_node(parent, np) {
-		if (of_get_property(np, "operating-points", NULL))
-			break;
-	}
+	cpu_dev = &pdev->dev;
 
+	np = of_node_get(cpu_dev->of_node);
 	if (!np) {
 		pr_err("failed to find cpu0 node\n");
-		ret = -ENOENT;
-		goto out_put_parent;
+		return -ENOENT;
 	}
 
-	cpu_dev = &pdev->dev;
-	cpu_dev->of_node = np;
-
 	cpu_reg = devm_regulator_get(cpu_dev, "cpu0");
 	if (IS_ERR(cpu_reg)) {
 		/*
@@ -269,15 +257,12 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
 	}
 
 	of_node_put(np);
-	of_node_put(parent);
 	return 0;
 
 out_free_table:
 	opp_free_cpufreq_table(cpu_dev, &freq_table);
 out_put_node:
 	of_node_put(np);
-out_put_parent:
-	of_node_put(parent);
 	return ret;
 }
 
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:18 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:18 +0100
Subject: [PATCH v3 07/16] of/device: add helper to get cpu device node from
 logical cpu index
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-8-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Multiple drivers need to get the cpu device node from the cpu logical
index and then access the of_node.

This patch adds helper function to fetch the device node directly.

Cc: Rob Herring <rob.herring at calxeda.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 include/linux/of_device.h | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index 9d27475..82ce324 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -1,6 +1,7 @@
 #ifndef _LINUX_OF_DEVICE_H
 #define _LINUX_OF_DEVICE_H
 
+#include <linux/cpu.h>
 #include <linux/platform_device.h>
 #include <linux/of_platform.h> /* temporary until merge */
 
@@ -43,6 +44,15 @@ static inline void of_device_node_put(struct device *dev)
 	of_node_put(dev->of_node);
 }
 
+static inline struct device_node *of_cpu_device_node_get(int cpu)
+{
+	struct device *cpu_dev;
+	cpu_dev = get_cpu_device(cpu);
+	if (!cpu_dev)
+		return NULL;
+	return of_node_get(cpu_dev->of_node);
+}
+
 #else /* CONFIG_OF */
 
 static inline int of_driver_match_device(struct device *dev,
@@ -67,6 +77,11 @@ static inline const struct of_device_id *of_match_device(
 {
 	return NULL;
 }
+
+static inline struct device_node *of_cpu_device_node_get(int cpu)
+{
+	return NULL;
+}
 #endif /* CONFIG_OF */
 
 #endif /* _LINUX_OF_DEVICE_H */
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:21 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:21 +0100
Subject: [PATCH v3 10/16] cpufreq: highbank-cpufreq: remove device tree
 parsing for cpu nodes
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-11-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Cc: Mark Langsdorf <mark.langsdorf at calxeda.com>
Acked-by: Rob Herring <rob.herring at calxeda.com>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/highbank-cpufreq.c | 18 ++++++------------
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/cpufreq/highbank-cpufreq.c b/drivers/cpufreq/highbank-cpufreq.c
index b61b5a3..794123f 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -69,23 +69,17 @@ static int hb_cpufreq_driver_init(void)
 	if (!of_machine_is_compatible("calxeda,highbank"))
 		return -ENODEV;
 
-	for_each_child_of_node(of_find_node_by_path("/cpus"), np)
-		if (of_get_property(np, "operating-points", NULL))
-			break;
-
-	if (!np) {
-		pr_err("failed to find highbank cpufreq node\n");
-		return -ENOENT;
-	}
-
 	cpu_dev = get_cpu_device(0);
 	if (!cpu_dev) {
 		pr_err("failed to get highbank cpufreq device\n");
-		ret = -ENODEV;
-		goto out_put_node;
+		return -ENODEV;
 	}
 
-	cpu_dev->of_node = np;
+	np = of_node_get(cpu_dev->of_node);
+	if (!np) {
+		pr_err("failed to find highbank cpufreq node\n");
+		return -ENOENT;
+	}
 
 	cpu_clk = clk_get(cpu_dev, NULL);
 	if (IS_ERR(cpu_clk)) {
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:15 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:15 +0100
Subject: [PATCH v3 04/16] ARM: topology: remove hwid/MPIDR dependency from
 cpu_capacity
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-5-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Currently the topology code computes cpu capacity and stores it in
the list along with hwid(which is MPIDR) as it parses the CPU nodes
in the device tree. This is required as it needs to be mapped to the
logical CPU later.

Since the CPU device nodes can be retrieved in the logical ordering
using DT/OF helpers, its possible to store cpu_capacity also in logical
ordering and avoid storing hwid for each entry.

This patch removes hwid by making use of of_get_cpu_node.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Acked-by: Rob Herring <rob.herring at calxeda.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/kernel/topology.c | 61 +++++++++++++++-------------------------------
 1 file changed, 19 insertions(+), 42 deletions(-)

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index c5a5954..28ef27a 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -74,12 +74,8 @@ struct cpu_efficiency table_efficiency[] = {
 	{NULL, },
 };
 
-struct cpu_capacity {
-	unsigned long hwid;
-	unsigned long capacity;
-};
-
-struct cpu_capacity *cpu_capacity;
+unsigned long *__cpu_capacity;
+#define cpu_capacity(cpu)	__cpu_capacity[cpu]
 
 unsigned long middle_capacity = 1;
 
@@ -100,15 +96,19 @@ static void __init parse_dt_topology(void)
 	unsigned long capacity = 0;
 	int alloc_size, cpu = 0;
 
-	alloc_size = nr_cpu_ids * sizeof(struct cpu_capacity);
-	cpu_capacity = kzalloc(alloc_size, GFP_NOWAIT);
+	alloc_size = nr_cpu_ids * sizeof(*__cpu_capacity);
+	__cpu_capacity = kzalloc(alloc_size, GFP_NOWAIT);
 
-	while ((cn = of_find_node_by_type(cn, "cpu"))) {
-		const u32 *rate, *reg;
+	for_each_possible_cpu(cpu) {
+		const u32 *rate;
 		int len;
 
-		if (cpu >= num_possible_cpus())
-			break;
+		/* too early to use cpu->of_node */
+		cn = of_get_cpu_node(cpu);
+		if (!cn) {
+			pr_err("missing device node for CPU %d\n", cpu);
+			continue;
+		}
 
 		for (cpu_eff = table_efficiency; cpu_eff->compatible; cpu_eff++)
 			if (of_device_is_compatible(cn, cpu_eff->compatible))
@@ -124,12 +124,6 @@ static void __init parse_dt_topology(void)
 			continue;
 		}
 
-		reg = of_get_property(cn, "reg", &len);
-		if (!reg || len != 4) {
-			pr_err("%s missing reg property\n", cn->full_name);
-			continue;
-		}
-
 		capacity = ((be32_to_cpup(rate)) >> 20) * cpu_eff->efficiency;
 
 		/* Save min capacity of the system */
@@ -140,13 +134,9 @@ static void __init parse_dt_topology(void)
 		if (capacity > max_capacity)
 			max_capacity = capacity;
 
-		cpu_capacity[cpu].capacity = capacity;
-		cpu_capacity[cpu++].hwid = be32_to_cpup(reg);
+		cpu_capacity(cpu) = capacity;
 	}
 
-	if (cpu < num_possible_cpus())
-		cpu_capacity[cpu].hwid = (unsigned long)(-1);
-
 	/* If min and max capacities are equals, we bypass the update of the
 	 * cpu_scale because all CPUs have the same capacity. Otherwise, we
 	 * compute a middle_capacity factor that will ensure that the capacity
@@ -154,9 +144,7 @@ static void __init parse_dt_topology(void)
 	 * SCHED_POWER_SCALE, which is the default value, but with the
 	 * constraint explained near table_efficiency[].
 	 */
-	if (min_capacity == max_capacity)
-		cpu_capacity[0].hwid = (unsigned long)(-1);
-	else if (4*max_capacity < (3*(max_capacity + min_capacity)))
+	if (4*max_capacity < (3*(max_capacity + min_capacity)))
 		middle_capacity = (min_capacity + max_capacity)
 				>> (SCHED_POWER_SHIFT+1);
 	else
@@ -170,23 +158,12 @@ static void __init parse_dt_topology(void)
  * boot. The update of all CPUs is in O(n^2) for heteregeneous system but the
  * function returns directly for SMP system.
  */
-void update_cpu_power(unsigned int cpu, unsigned long hwid)
+void update_cpu_power(unsigned int cpu)
 {
-	unsigned int idx = 0;
-
-	/* look for the cpu's hwid in the cpu capacity table */
-	for (idx = 0; idx < num_possible_cpus(); idx++) {
-		if (cpu_capacity[idx].hwid == hwid)
-			break;
-
-		if (cpu_capacity[idx].hwid == -1)
-			return;
-	}
-
-	if (idx == num_possible_cpus())
+	if (!cpu_capacity(cpu))
 		return;
 
-	set_power_scale(cpu, cpu_capacity[idx].capacity / middle_capacity);
+	set_power_scale(cpu, cpu_capacity(cpu) / middle_capacity);
 
 	printk(KERN_INFO "CPU%u: update cpu_power %lu\n",
 		cpu, arch_scale_freq_power(NULL, cpu));
@@ -194,7 +171,7 @@ void update_cpu_power(unsigned int cpu, unsigned long hwid)
 
 #else
 static inline void parse_dt_topology(void) {}
-static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {}
+static inline void update_cpu_power(unsigned int cpuid) {}
 #endif
 
  /*
@@ -281,7 +258,7 @@ void store_cpu_topology(unsigned int cpuid)
 
 	update_siblings_masks(cpuid);
 
-	update_cpu_power(cpuid, mpidr & MPIDR_HWID_BITMASK);
+	update_cpu_power(cpuid);
 
 	printk(KERN_INFO "CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n",
 		cpuid, cpu_topology[cpuid].thread_id,
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:22 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:22 +0100
Subject: [PATCH v3 11/16] cpufreq: spear-cpufreq: remove device tree parsing
 for cpu nodes
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-12-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Cc: Deepak Sikri <deepak.sikri at st.com>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/spear-cpufreq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/spear-cpufreq.c b/drivers/cpufreq/spear-cpufreq.c
index c3efa7f..19e364fa 100644
--- a/drivers/cpufreq/spear-cpufreq.c
+++ b/drivers/cpufreq/spear-cpufreq.c
@@ -18,7 +18,7 @@
 #include <linux/err.h>
 #include <linux/init.h>
 #include <linux/module.h>
-#include <linux/of.h>
+#include <linux/of_device.h>
 #include <linux/slab.h>
 #include <linux/types.h>
 
@@ -223,7 +223,7 @@ static int spear_cpufreq_driver_init(void)
 	const __be32 *val;
 	int cnt, i, ret;
 
-	np = of_find_node_by_path("/cpus/cpu at 0");
+	np = of_cpu_device_node_get(0);
 	if (!np) {
 		pr_err("No cpu node found");
 		return -ENODEV;
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:23 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:23 +0100
Subject: [PATCH v3 12/16] cpufreq: kirkwood-cpufreq: remove device tree
 parsing for cpu nodes
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-13-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Jason Cooper <jason at lakedaemon.net>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/kirkwood-cpufreq.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
index c233ea6..25ac2cb 100644
--- a/drivers/cpufreq/kirkwood-cpufreq.c
+++ b/drivers/cpufreq/kirkwood-cpufreq.c
@@ -14,7 +14,7 @@
 #include <linux/clk.h>
 #include <linux/clk-provider.h>
 #include <linux/cpufreq.h>
-#include <linux/of.h>
+#include <linux/of_device.h>
 #include <linux/platform_device.h>
 #include <linux/io.h>
 #include <asm/proc-fns.h>
@@ -175,9 +175,11 @@ static int kirkwood_cpufreq_probe(struct platform_device *pdev)
 	if (IS_ERR(priv.base))
 		return PTR_ERR(priv.base);
 
-	np = of_find_node_by_path("/cpus/cpu at 0");
-	if (!np)
+	np = of_cpu_device_node_get(0);
+	if (!np) {
+		dev_err(&pdev->dev, "failed to get cpu device node\n");
 		return -ENODEV;
+	}
 
 	priv.cpu_clk = of_clk_get_by_name(np, "cpu_clk");
 	if (IS_ERR(priv.cpu_clk)) {
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:24 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:24 +0100
Subject: [PATCH v3 13/16] cpufreq: arm_big_little: remove device tree parsing
 for cpu nodes
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-14-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/arm_big_little_dt.c | 40 +++++++++++++------------------------
 1 file changed, 14 insertions(+), 26 deletions(-)

diff --git a/drivers/cpufreq/arm_big_little_dt.c b/drivers/cpufreq/arm_big_little_dt.c
index fd9e3ea..480c0bd 100644
--- a/drivers/cpufreq/arm_big_little_dt.c
+++ b/drivers/cpufreq/arm_big_little_dt.c
@@ -19,12 +19,11 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
-#include <linux/cpu.h>
 #include <linux/cpufreq.h>
 #include <linux/device.h>
 #include <linux/export.h>
 #include <linux/module.h>
-#include <linux/of.h>
+#include <linux/of_device.h>
 #include <linux/opp.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
@@ -34,27 +33,13 @@
 /* get cpu node with valid operating-points */
 static struct device_node *get_cpu_node_with_valid_op(int cpu)
 {
-	struct device_node *np = NULL, *parent;
-	int count = 0;
+	struct device_node *np = of_cpu_device_node_get(cpu);
 
-	parent = of_find_node_by_path("/cpus");
-	if (!parent) {
-		pr_err("failed to find OF /cpus\n");
-		return NULL;
+	if (!of_get_property(np, "operating-points", NULL)) {
+		of_node_put(np);
+		np = NULL;
 	}
 
-	for_each_child_of_node(parent, np) {
-		if (count++ != cpu)
-			continue;
-		if (!of_get_property(np, "operating-points", NULL)) {
-			of_node_put(np);
-			np = NULL;
-		}
-
-		break;
-	}
-
-	of_node_put(parent);
 	return np;
 }
 
@@ -63,11 +48,12 @@ static int dt_init_opp_table(struct device *cpu_dev)
 	struct device_node *np;
 	int ret;
 
-	np = get_cpu_node_with_valid_op(cpu_dev->id);
-	if (!np)
-		return -ENODATA;
+	np = of_node_get(cpu_dev->of_node);
+	if (!np) {
+		pr_err("failed to find cpu%d node\n", cpu_dev->id);
+		return -ENOENT;
+	}
 
-	cpu_dev->of_node = np;
 	ret = of_init_opp_table(cpu_dev);
 	of_node_put(np);
 
@@ -79,9 +65,11 @@ static int dt_get_transition_latency(struct device *cpu_dev)
 	struct device_node *np;
 	u32 transition_latency = CPUFREQ_ETERNAL;
 
-	np = get_cpu_node_with_valid_op(cpu_dev->id);
-	if (!np)
+	np = of_node_get(cpu_dev->of_node);
+	if (!np) {
+		pr_info("Failed to find cpu node. Use CPUFREQ_ETERNAL transition latency\n");
 		return CPUFREQ_ETERNAL;
+	}
 
 	of_property_read_u32(np, "clock-latency", &transition_latency);
 	of_node_put(np);
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:25 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:25 +0100
Subject: [PATCH v3 14/16] cpufreq: maple-cpufreq: remove device tree parsing
 for cpu nodes
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-15-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Cc: Dmitry Eremin-Solenikov <dbaryshkov at gmail.com>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/maple-cpufreq.c | 23 +++--------------------
 1 file changed, 3 insertions(+), 20 deletions(-)

diff --git a/drivers/cpufreq/maple-cpufreq.c b/drivers/cpufreq/maple-cpufreq.c
index cdd6291..f071dc4 100644
--- a/drivers/cpufreq/maple-cpufreq.c
+++ b/drivers/cpufreq/maple-cpufreq.c
@@ -24,7 +24,7 @@
 #include <linux/completion.h>
 #include <linux/mutex.h>
 #include <linux/time.h>
-#include <linux/of.h>
+#include <linux/of_device.h>
 
 #define DBG(fmt...) pr_debug(fmt)
 
@@ -201,7 +201,6 @@ static struct cpufreq_driver maple_cpufreq_driver = {
 
 static int __init maple_cpufreq_init(void)
 {
-	struct device_node *cpus;
 	struct device_node *cpunode;
 	unsigned int psize;
 	unsigned long max_freq;
@@ -217,24 +216,11 @@ static int __init maple_cpufreq_init(void)
 	    !of_machine_is_compatible("Momentum,Apache"))
 		return 0;
 
-	cpus = of_find_node_by_path("/cpus");
-	if (cpus == NULL) {
-		DBG("No /cpus node !\n");
-		return -ENODEV;
-	}
-
 	/* Get first CPU node */
-	for (cpunode = NULL;
-	     (cpunode = of_get_next_child(cpus, cpunode)) != NULL;) {
-		const u32 *reg = of_get_property(cpunode, "reg", NULL);
-		if (reg == NULL || (*reg) != 0)
-			continue;
-		if (!strcmp(cpunode->type, "cpu"))
-			break;
-	}
+	cpunode = of_cpu_device_node_get(0);
 	if (cpunode == NULL) {
 		printk(KERN_ERR "cpufreq: Can't find any CPU 0 node\n");
-		goto bail_cpus;
+		goto bail_noprops;
 	}
 
 	/* Check 970FX for now */
@@ -290,14 +276,11 @@ static int __init maple_cpufreq_init(void)
 	rc = cpufreq_register_driver(&maple_cpufreq_driver);
 
 	of_node_put(cpunode);
-	of_node_put(cpus);
 
 	return rc;
 
 bail_noprops:
 	of_node_put(cpunode);
-bail_cpus:
-	of_node_put(cpus);
 
 	return rc;
 }
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:26 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:26 +0100
Subject: [PATCH v3 15/16] cpufreq: pmac64-cpufreq: remove device tree parsing
 for cpu nodes
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-16-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes all DT parsing and uses cpu->of_node instead.

Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/pmac64-cpufreq.c | 47 ++++++++++------------------------------
 1 file changed, 11 insertions(+), 36 deletions(-)

diff --git a/drivers/cpufreq/pmac64-cpufreq.c b/drivers/cpufreq/pmac64-cpufreq.c
index 7ba4234..97b719f 100644
--- a/drivers/cpufreq/pmac64-cpufreq.c
+++ b/drivers/cpufreq/pmac64-cpufreq.c
@@ -22,6 +22,7 @@
 #include <linux/init.h>
 #include <linux/completion.h>
 #include <linux/mutex.h>
+#include <linux/of_device.h>
 #include <asm/prom.h>
 #include <asm/machdep.h>
 #include <asm/irq.h>
@@ -383,9 +384,8 @@ static struct cpufreq_driver g5_cpufreq_driver = {
 
 #ifdef CONFIG_PMAC_SMU
 
-static int __init g5_neo2_cpufreq_init(struct device_node *cpus)
+static int __init g5_neo2_cpufreq_init(struct device_node *cpunode)
 {
-	struct device_node *cpunode;
 	unsigned int psize, ssize;
 	unsigned long max_freq;
 	char *freq_method, *volt_method;
@@ -405,20 +405,6 @@ static int __init g5_neo2_cpufreq_init(struct device_node *cpus)
 	else
 		return -ENODEV;
 
-	/* Get first CPU node */
-	for (cpunode = NULL;
-	     (cpunode = of_get_next_child(cpus, cpunode)) != NULL;) {
-		const u32 *reg = of_get_property(cpunode, "reg", NULL);
-		if (reg == NULL || (*reg) != 0)
-			continue;
-		if (!strcmp(cpunode->type, "cpu"))
-			break;
-	}
-	if (cpunode == NULL) {
-		printk(KERN_ERR "cpufreq: Can't find any CPU 0 node\n");
-		return -ENODEV;
-	}
-
 	/* Check 970FX for now */
 	valp = of_get_property(cpunode, "cpu-version", NULL);
 	if (!valp) {
@@ -537,9 +523,9 @@ static int __init g5_neo2_cpufreq_init(struct device_node *cpus)
 #endif /* CONFIG_PMAC_SMU */
 
 
-static int __init g5_pm72_cpufreq_init(struct device_node *cpus)
+static int __init g5_pm72_cpufreq_init(struct device_node *cpunode)
 {
-	struct device_node *cpuid = NULL, *hwclock = NULL, *cpunode = NULL;
+	struct device_node *cpuid = NULL, *hwclock = NULL;
 	const u8 *eeprom = NULL;
 	const u32 *valp;
 	u64 max_freq, min_freq, ih, il;
@@ -548,17 +534,6 @@ static int __init g5_pm72_cpufreq_init(struct device_node *cpus)
 	DBG("cpufreq: Initializing for PowerMac7,2, PowerMac7,3 and"
 	    " RackMac3,1...\n");
 
-	/* Get first CPU node */
-	for (cpunode = NULL;
-	     (cpunode = of_get_next_child(cpus, cpunode)) != NULL;) {
-		if (!strcmp(cpunode->type, "cpu"))
-			break;
-	}
-	if (cpunode == NULL) {
-		printk(KERN_ERR "cpufreq: Can't find any CPU node\n");
-		return -ENODEV;
-	}
-
 	/* Lookup the cpuid eeprom node */
         cpuid = of_find_node_by_path("/u3 at 0,f8000000/i2c at f8001000/cpuid at a0");
 	if (cpuid != NULL)
@@ -718,25 +693,25 @@ static int __init g5_pm72_cpufreq_init(struct device_node *cpus)
 
 static int __init g5_cpufreq_init(void)
 {
-	struct device_node *cpus;
+	struct device_node *cpunode;
 	int rc = 0;
 
-	cpus = of_find_node_by_path("/cpus");
-	if (cpus == NULL) {
-		DBG("No /cpus node !\n");
+	/* Get first CPU node */
+	cpunode = of_cpu_device_node_get(0);
+	if (cpunode == NULL) {
+		pr_err("cpufreq: Can't find any CPU node\n");
 		return -ENODEV;
 	}
 
 	if (of_machine_is_compatible("PowerMac7,2") ||
 	    of_machine_is_compatible("PowerMac7,3") ||
 	    of_machine_is_compatible("RackMac3,1"))
-		rc = g5_pm72_cpufreq_init(cpus);
+		rc = g5_pm72_cpufreq_init(cpunode);
 #ifdef CONFIG_PMAC_SMU
 	else
-		rc = g5_neo2_cpufreq_init(cpus);
+		rc = g5_neo2_cpufreq_init(cpunode);
 #endif /* CONFIG_PMAC_SMU */
 
-	of_node_put(cpus);
 	return rc;
 }
 
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 07:32:27 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 12:32:27 +0100
Subject: [PATCH v3 16/16] cpufreq: pmac32-cpufreq: remove device tree parsing
 for cpu nodes
In-Reply-To: <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374492747-13879-17-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.

This patch removes DT parsing and uses cpu->of_node instead.

Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/cpufreq/pmac32-cpufreq.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/pmac32-cpufreq.c b/drivers/cpufreq/pmac32-cpufreq.c
index 3104fad..56bfb6f 100644
--- a/drivers/cpufreq/pmac32-cpufreq.c
+++ b/drivers/cpufreq/pmac32-cpufreq.c
@@ -25,6 +25,7 @@
 #include <linux/init.h>
 #include <linux/device.h>
 #include <linux/hardirq.h>
+#include <linux/of_device.h>
 #include <asm/prom.h>
 #include <asm/machdep.h>
 #include <asm/irq.h>
@@ -649,8 +650,8 @@ static int __init pmac_cpufreq_setup(void)
 	if (strstr(cmd_line, "nocpufreq"))
 		return 0;
 
-	/* Assume only one CPU */
-	cpunode = of_find_node_by_type(NULL, "cpu");
+	/* Get first CPU node */
+	cpunode = of_cpu_device_node_get(0);
 	if (!cpunode)
 		goto out;
 
-- 
1.8.1.2




From linux at arm.linux.org.uk  Mon Jul 22 07:40:10 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Jul 2013 12:40:10 +0100
Subject: [PATCH 08/10] ARM: clps711x: Add CLPS711X cpuidle driver
In-Reply-To: <20130721081138.75cf5437bc30f42284f12e47@mail.ru>
References: <1374172501-26796-1-git-send-email-shc_work@mail.ru>
 <1374172501-26796-9-git-send-email-shc_work@mail.ru>
 <51EB0433.3050308@linaro.org>
 <20130721081138.75cf5437bc30f42284f12e47@mail.ru>
Message-ID: <20130722114010.GL24642@n2100.arm.linux.org.uk>

On Sun, Jul 21, 2013 at 08:11:38AM +0400, Alexander Shiyan wrote:
> > > +static int clps711x_cpuidle_halt(struct cpuidle_device *dev,
> > > +				 struct cpuidle_driver *drv, int index)
> > > +{
> > > +	writel(1, clps711x_halt);
> > 
> > In what the 'clps711x_halt' differs from the usual WFI (cpu_do_idle) ?
> 
> AFAIK, ARM720T does not implement the WFI instruction.
> "HALT" register in CLPS711X do the same:
> "A write to this location will put the system into the Idle State by
> halting the clock to the processor until an interrupt is generated."
> 
> > > +	asm volatile ("mov r0, r0");
> > > +	asm volatile ("mov r0, r0");
> > 
> > Why are needed these two volatile ?
> 
> Two NOP instructions necessary following the enable or disable of the MMU.
> Documentation not say anything about using this for "HALT", maybe it's the
> remnants of the old code. I will remove it.

However, bear in mind that this is not how you insert two nops after
something; the compiler is free to add anything it likes before,
between separate asm() statements, or after them, even if they're
marked volatile.


From s.nawrocki at samsung.com  Mon Jul 22 08:14:40 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 22 Jul 2013 14:14:40 +0200
Subject: [PATCH] clk: exynos4: Add CLK_GET_RATE_NOCACHE flag for the
 Exynos4x12 ISP clocks
In-Reply-To: <1372099374-21008-1-git-send-email-s.nawrocki@samsung.com>
References: <1372099374-21008-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <51ED2230.8080100@samsung.com>

On 06/24/2013 08:42 PM, Sylwester Nawrocki wrote:
> The ISP clock registers belong to the ISP power domain and may change
> their values if this power domain is switched off/on. Add
> CLK_GET_RATE_NOCACHE flags to ensure we do not rely on invalid cached
> data when setting or getting frequency of those clocks.
> 
> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>

Mike,

would you consider queueing that patch for current -rc cycle ?

Thanks,
Sylwester



From gsi at denx.de  Mon Jul 22 08:14:27 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:27 +0200
Subject: [PATCH v3 00/31] add COMMON_CLK support for PowerPC MPC512x
In-Reply-To: <1374166855-7280-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-1-git-send-email-gsi@denx.de>

this series
- fixes several drivers that are used in the MPC512x platform (UART,
  SPI, ethernet, PCI, USB, CAN, NAND flash, video capture) in how they
  handle clocks (appropriately acquire and setup them, hold references
  during use, release clocks after use)
- introduces support for the common clock framework (CCF, COMMON_CLK
  Kconfig option) in the PowerPC based MPC512x platform, which brings
  device tree based clock lookup as well

although the series does touch several subsystems -- tty (serial), spi,
net (can, fs_enet), mtd (nfc), usb, i2c, media (viu), and dts -- all of
the patches are strictly clock related

it appears most appropriate to take this series through either the clk
or the powerpc trees after it has passed review and other subsystem
maintainers ACKed the clock setup related driver modifications

the series passes 'checkpatch.pl --strict' except for one warning which
cannot get resolved, since that either breaks compilation (the data type
is preset by the clk-provider.h API) or requires a cast which shadows
real mismatches:

  WARNING: static const char * array should probably be static const char * const
  #436: FILE: arch/powerpc/platforms/512x/clock-commonclk.c:335:
  +static const char *parent_names_mux0[] = {

  total: 0 errors, 1 warnings, 0 checks, 845 lines checked

each step in the series was build and run tested (with a display that is
attached to the DIU as well as SPI, with an SPI attached NOR flash, with
multiple UART ports such that one is not the boot console, with EEPROMs
attached to I2C, with an SD card, booting from network)


changes in v3:
- rebase the series against v3.11-rc2
- re-ordered the series to first address all general clock handling
  concerns in existing drivers, before introducing common clock support
  in the platform's clock driver
- slightly rework the SPI (01/31), UART (02/31), and PSC FIFO (23/31)
  clock handling in comparison to v2 which introduced those fixes
  (devm_{get,put}_clk() calls, fewer goto labels in error paths)
- fix and improve clock handling (balance allocation and release of
  clocks, check for errors during setup) in all of the other drivers
  which this series has touched before in naive ways: USB (03/31), NAND
  flash (04/31), video capture (05/31), I2C (06/31), ethernet (08/31),
  PCI (09/31), CAN (11/31)
- silence a build warning in the ethernet driver (07/31)
- eliminate all PPC_CLOCK references, use 'per' clock names for NAND
  flash (25/31) and VIU (26/31) as well
- unbreak CAN operation for the period between introducing common clock
  support in the platform's clock driver and introducing common clock
  support in the CAN peripheral driver as well as providing clock specs
  in the device tree (provide clkdev aliases for SYS and REF)
- improve common clock support for CAN (devm_{get,put}_clk() calls,
  check enable() errors, keep a reference to used clocks, disable and
  put clocks after use)
- reworded several commit messages to better reflect the kind of change
  and because fixes were applied before adding common infrastructure
  support
- point to individual numbered patches of the series in the list of
  changes for v2 as well

changes in v2:
- cleanup of the UART (02/24) and SPI (01/24) clock handling before the
  introduction of common clock support for the platform, as incomplete
  clock handling becomes fatal or more dangerous later (which in turn
  changes the context of the "device tree lookup only" followup patch
  later)
- reordered the sequence of patches to keep the serial communication
  related parts together (UART, SPI, and PSC FIFO changes after common
  clock support was introduced, which have become 11-14/24 now)
- updated commit messages for the clock API use cleanup in the serial
  communication drivers, updated comments and reworded commit messages
  in the core clock driver to expand on the pre-enable workaround and
  clkdev registration (09/24)
- keep a reference to the PSC FIFO clock during use instead of looking
  up the clock again in the uninit() routine (14/24)
- remove the clkdev.h header file inclusion directive with the removal
  of the clkdev registration call (13/24)


Gerhard Sittig (31):
  spi: mpc512x: cleanup clock API use
  serial: mpc512x: cleanup clock API use
  USB: fsl-mph-dr-of: cleanup clock API use
  mtd: mpc5121_nfc: cleanup clock API use
  [media] fsl-viu: cleanup clock API use
  i2c: mpc: cleanup clock API use
  fs_enet: silence a build warning (unused variable)
  fs_enet: cleanup clock API use
  powerpc/fsl-pci: improve clock API use
  net: can: mscan: add a comment on reg to idx mapping
  net: can: mscan: improve clock API use
  powerpc: mpc512x: array decl for MCLK registers in CCM
  clk: wrap I/O access for improved portability
  dts: mpc512x: prepare for preprocessor support
  dts: mpc512x: introduce dt-bindings/clock/ header
  dts: mpc512x: add clock related device tree specs
  clk: mpc512x: introduce COMMON_CLK for MPC512x
  dts: mpc512x: add clock specs for client lookups
  clk: mpc512x: don't pre-enable FEC and I2C clocks
  spi: mpc512x: remove now obsolete clock lookup name
  serial: mpc512x: remove now obsolete clock lookup name
  clk: mpc512x: remove clkdev registration (uart, spi)
  serial: mpc512x: setup the PSC FIFO clock as well
  USB: fsl-mph-dr-of: remove now obsolete clock lookup name
  mtd: mpc5121_nfc: remove now obsolete clock lookup name
  [media] fsl-viu: remove now obsolete clock lookup name
  net: can: mscan: add common clock support for  mpc512x
  powerpc/mpc512x: improve DIU related clock setup
  clk: mpc512x: switch to COMMON_CLK, remove PPC_CLOCK
  net: can: mscan: remove non-common_clock code for MPC512x
  clk: mpc512x: remove clkdev registration (sys/ref, header)

 arch/powerpc/boot/dts/ac14xx.dts                   |    9 +-
 arch/powerpc/boot/dts/include/dt-bindings          |    1 +
 arch/powerpc/boot/dts/mpc5121.dtsi                 |   94 ++-
 arch/powerpc/boot/dts/mpc5121ads.dts               |    2 +-
 arch/powerpc/boot/dts/pdm360ng.dts                 |    2 +-
 arch/powerpc/include/asm/mpc5121.h                 |   18 +-
 arch/powerpc/platforms/512x/Kconfig                |    2 +-
 arch/powerpc/platforms/512x/Makefile               |    3 +-
 arch/powerpc/platforms/512x/clock-commonclk.c      |  761 ++++++++++++++++++++
 arch/powerpc/platforms/512x/clock.c                |  753 -------------------
 arch/powerpc/platforms/512x/mpc512x_shared.c       |  165 +++--
 arch/powerpc/sysdev/fsl_pci.c                      |   23 +
 drivers/clk/clk-divider.c                          |    6 +-
 drivers/clk/clk-gate.c                             |    6 +-
 drivers/clk/clk-mux.c                              |    6 +-
 drivers/i2c/busses/i2c-mpc.c                       |   28 +
 drivers/media/platform/fsl-viu.c                   |   26 +-
 drivers/mtd/nand/mpc5121_nfc.c                     |   20 +-
 drivers/net/can/mscan/mpc5xxx_can.c                |  271 ++++---
 drivers/net/can/mscan/mscan.c                      |    9 +
 drivers/net/can/mscan/mscan.h                      |    2 +
 .../net/ethernet/freescale/fs_enet/fs_enet-main.c  |   26 +-
 drivers/spi/spi-mpc512x-psc.c                      |   48 +-
 drivers/tty/serial/mpc52xx_uart.c                  |  144 +++-
 drivers/usb/host/fsl-mph-dr-of.c                   |   26 +-
 include/dt-bindings/clock/mpc512x-clock.h          |   59 ++
 include/linux/clk-provider.h                       |   33 +
 include/linux/fs_enet_pd.h                         |    3 +
 28 files changed, 1493 insertions(+), 1053 deletions(-)
 create mode 120000 arch/powerpc/boot/dts/include/dt-bindings
 create mode 100644 arch/powerpc/platforms/512x/clock-commonclk.c
 delete mode 100644 arch/powerpc/platforms/512x/clock.c
 create mode 100644 include/dt-bindings/clock/mpc512x-clock.h


# uname -srm
Linux 3.11.0-rc2-00031-ge72cd55 ppc
# cat /sys/kernel/debug/clk/clk_summary
   clock                        enable_cnt  prepare_cnt  rate
---------------------------------------------------------------------
 ac97                           0           0            24567000
 spdif_rx_in                    0           0            0
 spdif_tx_in                    0           0            0
 psc_mclk_in                    0           0            25000000
 dummy                          1           1            0
 osc                            1           1            25000000
    ref                         1           1            25000000
       sys                      10          10           320000000
          spdif-mux0            0           0            320000000
             spdif-en0          0           0            320000000
                spdif_mclk_div  0           0            80000000
                   spdif_mclk_out 0           0            80000000
                      spdif_mclk 0           0            80000000
          mscan3-mux0           1           1            320000000
             mscan3-en0         1           1            320000000
                mscan3_mclk_div 1           1            80000000
                   mscan3_mclk_out 1           1            80000000
                      mscan3_mclk 1           1            80000000
          mscan2-mux0           1           1            320000000
             mscan2-en0         1           1            320000000
                mscan2_mclk_div 1           1            80000000
                   mscan2_mclk_out 1           1            80000000
                      mscan2_mclk 1           1            80000000
          mscan1-mux0           1           1            320000000
             mscan1-en0         1           1            320000000
                mscan1_mclk_div 1           1            16000000
                   mscan1_mclk_out 1           1            16000000
                      mscan1_mclk 1           2            16000000
          mscan0-mux0           1           1            320000000
             mscan0-en0         1           1            320000000
                mscan0_mclk_div 1           1            16000000
                   mscan0_mclk_out 1           1            16000000
                      mscan0_mclk 1           2            16000000
          psc11-mux0            0           0            320000000
             psc11-en0          0           0            320000000
                psc11_mclk_div  0           0            80000000
                   psc11_mclk_out 0           0            80000000
                      psc11_mclk 0           0            80000000
          psc10-mux0            0           0            320000000
             psc10-en0          0           0            320000000
                psc10_mclk_div  0           0            80000000
                   psc10_mclk_out 0           0            80000000
                      psc10_mclk 0           0            80000000
          psc9-mux0             0           0            320000000
             psc9-en0           0           0            320000000
                psc9_mclk_div   0           0            80000000
                   psc9_mclk_out 0           0            80000000
                      psc9_mclk 0           0            80000000
          psc8-mux0             0           0            320000000
             psc8-en0           0           0            320000000
                psc8_mclk_div   0           0            80000000
                   psc8_mclk_out 0           0            80000000
                      psc8_mclk 0           0            80000000
          psc7-mux0             1           1            320000000
             psc7-en0           1           1            320000000
                psc7_mclk_div   1           1            80000000
                   psc7_mclk_out 1           1            80000000
                      psc7_mclk 1           1            80000000
          psc6-mux0             0           0            320000000
             psc6-en0           0           0            320000000
                psc6_mclk_div   0           0            80000000
                   psc6_mclk_out 0           0            80000000
                      psc6_mclk 0           0            80000000
          psc5-mux0             1           1            320000000
             psc5-en0           1           1            320000000
                psc5_mclk_div   1           1            80000000
                   psc5_mclk_out 1           1            80000000
                      psc5_mclk 1           1            80000000
          psc4-mux0             1           1            320000000
             psc4-en0           1           1            320000000
                psc4_mclk_div   1           1            80000000
                   psc4_mclk_out 1           1            80000000
                      psc4_mclk 1           1            80000000
          psc3-mux0             1           1            320000000
             psc3-en0           1           1            320000000
                psc3_mclk_div   1           1            80000000
                   psc3_mclk_out 1           1            80000000
                      psc3_mclk 2           2            80000000
          psc2-mux0             0           0            320000000
             psc2-en0           0           0            320000000
                psc2_mclk_div   0           0            80000000
                   psc2_mclk_out 0           0            80000000
                      psc2_mclk 0           0            80000000
          psc1-mux0             0           0            320000000
             psc1-en0           0           0            320000000
                psc1_mclk_div   0           0            80000000
                   psc1_mclk_out 0           0            80000000
                      psc1_mclk 0           0            80000000
          psc0-mux0             0           0            320000000
             psc0-en0           0           0            320000000
                psc0_mclk_div   0           0            80000000
                   psc0_mclk_out 0           0            80000000
                      psc0_mclk 0           0            80000000
          ddr-ug                1           1            160000000
             ddr                1           1            160000000
          csb                   4           4            160000000
             viu                0           0            160000000
             iim                0           0            160000000
             usb2               0           0            160000000
             usb1               0           0            160000000
             axe                0           0            160000000
             pci-ug             0           0            26666666
                pci             0           0            26666666
             mbx-bus-ug         0           0            80000000
                mbx-bus         0           0            80000000
                mbx-ug          0           0            80000000
                   mbx          0           0            80000000
                   mbx-3d-ug    0           0            80000000
                      mbx-3d    0           0            80000000
             e300               1           1            400000000
             diu-x4             1           1            640000000
                diu-ug          1           1            2509803
                   diu          2           2            2509803
             sdhc-x4            1           1            640000000
                sdhc-ug         1           1            53333333
                   sdhc-2       0           0            53333333
                   sdhc         1           1            53333333
             ips                7           7            80000000
                i2c             3           3            80000000
                mem             1           1            80000000
                fec             1           1            80000000
                sata            0           0            80000000
                psc-fifo        1           1            80000000
                pata            0           0            80000000
                lpc-ug          1           1            40000000
                   lpc          1           1            40000000
                nfc-ug          0           0            40000000
                   nfc          0           0            40000000

-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:28 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:28 +0200
Subject: [PATCH v3 01/31] spi: mpc512x: cleanup clock API use
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-2-git-send-email-gsi@denx.de>

cleanup the MPC512x SoC's SPI master's use of the clock API
- get, prepare, and enable the MCLK during probe; disable, unprepare and
  put the MCLK upon remove; hold a reference to the clock over the
  period of use
- fetch MCLK rate (reference) once during probe and slightly reword BCLK
  (bitrate) determination to reduce redundancy as well as to not exceed
  the maximum text line length
- stick with the PPC_CLOCK 'psc%d_mclk' name for clock lookup, only
  switch to a fixed string later after device tree based clock lookup
  will have become available

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/spi/spi-mpc512x-psc.c |   52 +++++++++++++++++++++++++++--------------
 1 file changed, 34 insertions(+), 18 deletions(-)

diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
index 29fce6a..823e5e0 100644
--- a/drivers/spi/spi-mpc512x-psc.c
+++ b/drivers/spi/spi-mpc512x-psc.c
@@ -38,7 +38,8 @@ struct mpc512x_psc_spi {
 	struct mpc512x_psc_fifo __iomem *fifo;
 	unsigned int irq;
 	u8 bits_per_word;
-	u32 mclk;
+	struct clk *clk_mclk;
+	u32 mclk_rate;
 
 	struct completion txisrdone;
 };
@@ -72,6 +73,7 @@ static void mpc512x_psc_spi_activate_cs(struct spi_device *spi)
 	struct mpc52xx_psc __iomem *psc = mps->psc;
 	u32 sicr;
 	u32 ccr;
+	int speed;
 	u16 bclkdiv;
 
 	sicr = in_be32(&psc->sicr);
@@ -95,10 +97,10 @@ static void mpc512x_psc_spi_activate_cs(struct spi_device *spi)
 
 	ccr = in_be32(&psc->ccr);
 	ccr &= 0xFF000000;
-	if (cs->speed_hz)
-		bclkdiv = (mps->mclk / cs->speed_hz) - 1;
-	else
-		bclkdiv = (mps->mclk / 1000000) - 1;	/* default 1MHz */
+	speed = cs->speed_hz;
+	if (!speed)
+		speed = 1000000;	/* default 1MHz */
+	bclkdiv = (mps->mclk_rate / speed) - 1;
 
 	ccr |= (((bclkdiv & 0xff) << 16) | (((bclkdiv >> 8) & 0xff) << 8));
 	out_be32(&psc->ccr, ccr);
@@ -386,19 +388,11 @@ static int mpc512x_psc_spi_port_config(struct spi_master *master,
 {
 	struct mpc52xx_psc __iomem *psc = mps->psc;
 	struct mpc512x_psc_fifo __iomem *fifo = mps->fifo;
-	struct clk *spiclk;
-	int ret = 0;
-	char name[32];
 	u32 sicr;
 	u32 ccr;
+	int speed;
 	u16 bclkdiv;
 
-	sprintf(name, "psc%d_mclk", master->bus_num);
-	spiclk = clk_get(&master->dev, name);
-	clk_enable(spiclk);
-	mps->mclk = clk_get_rate(spiclk);
-	clk_put(spiclk);
-
 	/* Reset the PSC into a known state */
 	out_8(&psc->command, MPC52xx_PSC_RST_RX);
 	out_8(&psc->command, MPC52xx_PSC_RST_TX);
@@ -425,7 +419,8 @@ static int mpc512x_psc_spi_port_config(struct spi_master *master,
 
 	ccr = in_be32(&psc->ccr);
 	ccr &= 0xFF000000;
-	bclkdiv = (mps->mclk / 1000000) - 1;	/* default 1MHz */
+	speed = 1000000;	/* default 1MHz */
+	bclkdiv = (mps->mclk_rate / speed) - 1;
 	ccr |= (((bclkdiv & 0xff) << 16) | (((bclkdiv >> 8) & 0xff) << 8));
 	out_be32(&psc->ccr, ccr);
 
@@ -445,7 +440,7 @@ static int mpc512x_psc_spi_port_config(struct spi_master *master,
 
 	mps->bits_per_word = 8;
 
-	return ret;
+	return 0;
 }
 
 static irqreturn_t mpc512x_psc_spi_isr(int irq, void *dev_id)
@@ -479,6 +474,9 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
 	struct spi_master *master;
 	int ret;
 	void *tempp;
+	int psc_num;
+	char clk_name[16];
+	struct clk *clk;
 
 	master = spi_alloc_master(dev, sizeof *mps);
 	if (master == NULL)
@@ -521,16 +519,32 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
 		goto free_master;
 	init_completion(&mps->txisrdone);
 
+	psc_num = master->bus_num;
+	snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
+	clk = devm_clk_get(dev, clk_name);
+	if (IS_ERR(clk))
+		goto free_irq;
+	ret = clk_prepare_enable(clk);
+	if (ret) {
+		devm_clk_put(dev, clk);
+		goto free_irq;
+	}
+	mps->clk_mclk = clk;
+	mps->mclk_rate = clk_get_rate(clk);
+
 	ret = mpc512x_psc_spi_port_config(master, mps);
 	if (ret < 0)
-		goto free_irq;
+		goto free_clock;
 
 	ret = spi_register_master(master);
 	if (ret < 0)
-		goto free_irq;
+		goto free_clock;
 
 	return ret;
 
+free_clock:
+	clk_disable_unprepare(mps->clk_mclk);
+	devm_clk_put(dev, mps->clk_mclk);
 free_irq:
 	free_irq(mps->irq, mps);
 free_master:
@@ -547,6 +561,8 @@ static int mpc512x_psc_spi_do_remove(struct device *dev)
 	struct mpc512x_psc_spi *mps = spi_master_get_devdata(master);
 
 	spi_unregister_master(master);
+	clk_disable_unprepare(mps->clk_mclk);
+	devm_clk_put(dev, mps->clk_mclk);
 	free_irq(mps->irq, mps);
 	if (mps->psc)
 		iounmap(mps->psc);
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:30 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:30 +0200
Subject: [PATCH v3 03/31] USB: fsl-mph-dr-of: cleanup clock API use
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-4-git-send-email-gsi@denx.de>

error check in the clock setup, must prepare clocks before they
can get enabled, unprepare after disable, use devm_{get,put}_clk()

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/usb/host/fsl-mph-dr-of.c |   15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 11e0b79..5e51384 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -260,6 +260,7 @@ int fsl_usb2_mpc5121_init(struct platform_device *pdev)
 {
 	struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
 	struct clk *clk;
+	int err;
 	char clk_name[10];
 	int base, clk_num;
 
@@ -272,13 +273,17 @@ int fsl_usb2_mpc5121_init(struct platform_device *pdev)
 		return -ENODEV;
 
 	snprintf(clk_name, sizeof(clk_name), "usb%d_clk", clk_num);
-	clk = clk_get(&pdev->dev, clk_name);
+	clk = devm_clk_get(&pdev->dev, clk_name);
 	if (IS_ERR(clk)) {
 		dev_err(&pdev->dev, "failed to get clk\n");
 		return PTR_ERR(clk);
 	}
-
-	clk_enable(clk);
+	err = clk_prepare_enable(clk);
+	if (err) {
+		dev_err(&pdev->dev, "failed to enable clk\n");
+		devm_clk_put(&pdev->dev, clk);
+		return err;
+	}
 	pdata->clk = clk;
 
 	if (pdata->phy_mode == FSL_USB2_PHY_UTMI_WIDE) {
@@ -303,8 +308,8 @@ static void fsl_usb2_mpc5121_exit(struct platform_device *pdev)
 	pdata->regs = NULL;
 
 	if (pdata->clk) {
-		clk_disable(pdata->clk);
-		clk_put(pdata->clk);
+		clk_disable_unprepare(pdata->clk);
+		devm_clk_put(&pdev->dev, pdata->clk);
 	}
 }
 
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:32 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:32 +0200
Subject: [PATCH v3 05/31] [media] fsl-viu: cleanup clock API use
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-6-git-send-email-gsi@denx.de>

prepare clocks before enabling them, check for and propagate enable
errors, balance get/put and prepare/unprepare and enable/disable,
use devm_{get,put}_clk()

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/media/platform/fsl-viu.c |   26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index 221ec42..48fced4 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -1485,6 +1485,7 @@ static int viu_of_probe(struct platform_device *op)
 	struct viu_reg __iomem *viu_regs;
 	struct i2c_adapter *ad;
 	int ret, viu_irq;
+	struct clk *clk;
 
 	ret = of_address_to_resource(op->dev.of_node, 0, &r);
 	if (ret) {
@@ -1577,14 +1578,19 @@ static int viu_of_probe(struct platform_device *op)
 	}
 
 	/* enable VIU clock */
-	viu_dev->clk = clk_get(&op->dev, "viu_clk");
-	if (IS_ERR(viu_dev->clk)) {
-		dev_err(&op->dev, "failed to find the clock module!\n");
-		ret = -ENODEV;
+	clk = devm_clk_get(&op->dev, "viu_clk");
+	if (IS_ERR(clk)) {
+		dev_err(&op->dev, "failed to lookup the clock!\n");
+		ret = PTR_ERR(clk);
+		goto err_clk;
+	}
+	ret = clk_prepare_enable(clk);
+	if (ret) {
+		dev_err(&op->dev, "failed to enable the clock!\n");
+		devm_clk_put(&op->dev, clk);
 		goto err_clk;
-	} else {
-		clk_enable(viu_dev->clk);
 	}
+	viu_dev->clk = clk;
 
 	/* reset VIU module */
 	viu_reset(viu_dev->vr);
@@ -1602,8 +1608,8 @@ static int viu_of_probe(struct platform_device *op)
 	return ret;
 
 err_irq:
-	clk_disable(viu_dev->clk);
-	clk_put(viu_dev->clk);
+	clk_disable_unprepare(viu_dev->clk);
+	devm_clk_put(&op->dev, viu_dev->clk);
 err_clk:
 	video_unregister_device(viu_dev->vdev);
 err_vdev:
@@ -1626,8 +1632,8 @@ static int viu_of_remove(struct platform_device *op)
 	free_irq(dev->irq, (void *)dev);
 	irq_dispose_mapping(dev->irq);
 
-	clk_disable(dev->clk);
-	clk_put(dev->clk);
+	clk_disable_unprepare(dev->clk);
+	devm_clk_put(&op->dev, dev->clk);
 
 	video_unregister_device(dev->vdev);
 	i2c_put_adapter(client->adapter);
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:29 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:29 +0200
Subject: [PATCH v3 02/31] serial: mpc512x: cleanup clock API use
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-3-git-send-email-gsi@denx.de>

cleanup the clock API use of the UART driver which is shared among the
MPC512x and the MPC5200 platforms
- get, prepare, and enable the MCLK during port allocation; disable,
  unprepare and put the MCLK upon port release; hold a reference to the
  clock over the period of use; check for and propagate enable errors
- fix a buffer overflow for clock names with two digit PSC index numbers
- stick with the PPC_CLOCK 'psc%d_mclk' name for clock lookup, only
  switch to a fixed string later after device tree based clock lookup
  will have become available

to achieve support for MPC512x which is neutral to MPC5200, the
modification was done as follows
- introduce "clock alloc" and "clock release" routines in addition to
  the previous "clock enable/disable" routine in the psc_ops struct
- make the clock allocation a part of the port request (resource
  allocation), and make clock release a part of the port release, such
  that essential resources get allocated early
- just enable/disable the clock from within the .clock() callback
  without any allocation or preparation as the former implementation
  did, since this routine is called from within the startup and shutdown
  callbacks
- all of the above remains a NOP for the MPC5200 platform (no callbacks
  are provided on that platform)
- implementation note: the clock gets enabled upon allocation already
  just in case the clock is not only required for bitrate generation but
  for register access as well

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/tty/serial/mpc52xx_uart.c |  100 ++++++++++++++++++++++++++++++-------
 1 file changed, 83 insertions(+), 17 deletions(-)

diff --git a/drivers/tty/serial/mpc52xx_uart.c b/drivers/tty/serial/mpc52xx_uart.c
index e1280a2..8f16ed9 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -107,6 +107,8 @@ struct psc_ops {
 	unsigned int	(*set_baudrate)(struct uart_port *port,
 					struct ktermios *new,
 					struct ktermios *old);
+	int		(*clock_alloc)(struct uart_port *port);
+	void		(*clock_relse)(struct uart_port *port);
 	int		(*clock)(struct uart_port *port, int enable);
 	int		(*fifoc_init)(void);
 	void		(*fifoc_uninit)(void);
@@ -616,31 +618,75 @@ static irqreturn_t mpc512x_psc_handle_irq(struct uart_port *port)
 	return IRQ_NONE;
 }
 
-static int mpc512x_psc_clock(struct uart_port *port, int enable)
+static struct clk *psc_mclk_clk[MPC52xx_PSC_MAXNUM];
+
+/* called from within the .request_port() callback (allocation) */
+static int mpc512x_psc_alloc_clock(struct uart_port *port)
 {
-	struct clk *psc_clk;
 	int psc_num;
-	char clk_name[10];
+	char clk_name[16];
+	struct clk *clk;
+	int err;
+
+	psc_num = (port->mapbase & 0xf00) >> 8;
+	snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
+	clk = devm_clk_get(port->dev, clk_name);
+	if (IS_ERR(clk)) {
+		dev_err(port->dev, "Failed to get MCLK!\n");
+		return PTR_ERR(clk);
+	}
+	err = clk_prepare_enable(clk);
+	if (err) {
+		dev_err(port->dev, "Failed to enable MCLK!\n");
+		devm_clk_put(port->dev, clk);
+		return err;
+	}
+	psc_mclk_clk[psc_num] = clk;
+	return 0;
+}
+
+/* called from within the .release_port() callback (release) */
+static void mpc512x_psc_relse_clock(struct uart_port *port)
+{
+	int psc_num;
+	struct clk *clk;
+
+	psc_num = (port->mapbase & 0xf00) >> 8;
+	clk = psc_mclk_clk[psc_num];
+	if (clk) {
+		clk_disable_unprepare(clk);
+		devm_clk_put(port->dev, clk);
+		psc_mclk_clk[psc_num] = NULL;
+	}
+}
+
+/* implementation of the .clock() callback (enable/disable) */
+static int mpc512x_psc_endis_clock(struct uart_port *port, int enable)
+{
+	int psc_num;
+	struct clk *psc_clk;
+	int ret;
 
 	if (uart_console(port))
 		return 0;
 
 	psc_num = (port->mapbase & 0xf00) >> 8;
-	snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
-	psc_clk = clk_get(port->dev, clk_name);
-	if (IS_ERR(psc_clk)) {
+	psc_clk = psc_mclk_clk[psc_num];
+	if (!psc_clk) {
 		dev_err(port->dev, "Failed to get PSC clock entry!\n");
 		return -ENODEV;
 	}
 
-	dev_dbg(port->dev, "%s %sable\n", clk_name, enable ? "en" : "dis");
-
-	if (enable)
-		clk_enable(psc_clk);
-	else
+	dev_dbg(port->dev, "mclk %sable\n", enable ? "en" : "dis");
+	if (enable) {
+		ret = clk_enable(psc_clk);
+		if (ret)
+			dev_err(port->dev, "Failed to enable MCLK!\n");
+		return ret;
+	} else {
 		clk_disable(psc_clk);
-
-	return 0;
+		return 0;
+	}
 }
 
 static void mpc512x_psc_get_irq(struct uart_port *port, struct device_node *np)
@@ -873,7 +919,9 @@ static struct psc_ops mpc5125_psc_ops = {
 	.cw_disable_ints = mpc5125_psc_cw_disable_ints,
 	.cw_restore_ints = mpc5125_psc_cw_restore_ints,
 	.set_baudrate = mpc5125_psc_set_baudrate,
-	.clock = mpc512x_psc_clock,
+	.clock_alloc = mpc512x_psc_alloc_clock,
+	.clock_relse = mpc512x_psc_relse_clock,
+	.clock = mpc512x_psc_endis_clock,
 	.fifoc_init = mpc512x_psc_fifoc_init,
 	.fifoc_uninit = mpc512x_psc_fifoc_uninit,
 	.get_irq = mpc512x_psc_get_irq,
@@ -906,7 +954,9 @@ static struct psc_ops mpc512x_psc_ops = {
 	.cw_disable_ints = mpc512x_psc_cw_disable_ints,
 	.cw_restore_ints = mpc512x_psc_cw_restore_ints,
 	.set_baudrate = mpc512x_psc_set_baudrate,
-	.clock = mpc512x_psc_clock,
+	.clock_alloc = mpc512x_psc_alloc_clock,
+	.clock_relse = mpc512x_psc_relse_clock,
+	.clock = mpc512x_psc_endis_clock,
 	.fifoc_init = mpc512x_psc_fifoc_init,
 	.fifoc_uninit = mpc512x_psc_fifoc_uninit,
 	.get_irq = mpc512x_psc_get_irq,
@@ -1166,6 +1216,9 @@ mpc52xx_uart_type(struct uart_port *port)
 static void
 mpc52xx_uart_release_port(struct uart_port *port)
 {
+	if (psc_ops->clock_relse)
+		psc_ops->clock_relse(port);
+
 	/* remapped by us ? */
 	if (port->flags & UPF_IOREMAP) {
 		iounmap(port->membase);
@@ -1190,11 +1243,24 @@ mpc52xx_uart_request_port(struct uart_port *port)
 	err = request_mem_region(port->mapbase, sizeof(struct mpc52xx_psc),
 			"mpc52xx_psc_uart") != NULL ? 0 : -EBUSY;
 
-	if (err && (port->flags & UPF_IOREMAP)) {
+	if (err)
+		goto out_membase;
+
+	if (psc_ops->clock_alloc) {
+		err = psc_ops->clock_alloc(port);
+		if (err)
+			goto out_mapregion;
+	}
+
+	return 0;
+
+out_mapregion:
+	release_mem_region(port->mapbase, sizeof(struct mpc52xx_psc));
+out_membase:
+	if (port->flags & UPF_IOREMAP) {
 		iounmap(port->membase);
 		port->membase = NULL;
 	}
-
 	return err;
 }
 
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:31 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:31 +0200
Subject: [PATCH v3 04/31] mtd: mpc5121_nfc: cleanup clock API use
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-5-git-send-email-gsi@denx.de>

prepare before enable isn't optional, do check for and propagate clock
setup errors, adjust error code paths to correctly balance get/put and
prepare/unprepare and enable/disable, use devm_{get,put}_clk()

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/mtd/nand/mpc5121_nfc.c |   20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/mpc5121_nfc.c b/drivers/mtd/nand/mpc5121_nfc.c
index 3c9cdcb..9c0b8fe 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -618,8 +618,8 @@ static void mpc5121_nfc_free(struct device *dev, struct mtd_info *mtd)
 	struct mpc5121_nfc_prv *prv = chip->priv;
 
 	if (prv->clk) {
-		clk_disable(prv->clk);
-		clk_put(prv->clk);
+		clk_disable_unprepare(prv->clk);
+		devm_clk_put(dev, prv->clk);
 	}
 
 	if (prv->csreg)
@@ -629,6 +629,7 @@ static void mpc5121_nfc_free(struct device *dev, struct mtd_info *mtd)
 static int mpc5121_nfc_probe(struct platform_device *op)
 {
 	struct device_node *rootnode, *dn = op->dev.of_node;
+	struct clk *clk;
 	struct device *dev = &op->dev;
 	struct mpc5121_nfc_prv *prv;
 	struct resource res;
@@ -730,14 +731,19 @@ static int mpc5121_nfc_probe(struct platform_device *op)
 	of_node_put(rootnode);
 
 	/* Enable NFC clock */
-	prv->clk = clk_get(dev, "nfc_clk");
-	if (IS_ERR(prv->clk)) {
+	clk = devm_clk_get(dev, "nfc_clk");
+	if (IS_ERR(clk)) {
 		dev_err(dev, "Unable to acquire NFC clock!\n");
-		retval = PTR_ERR(prv->clk);
+		retval = PTR_ERR(clk);
 		goto error;
 	}
-
-	clk_enable(prv->clk);
+	retval = clk_prepare_enable(clk);
+	if (retval) {
+		dev_err(dev, "Unable to enable NFC clock!\n");
+		devm_clk_put(dev, clk);
+		goto error;
+	}
+	prv->clk = clk;
 
 	/* Reset NAND Flash controller */
 	nfc_set(mtd, NFC_CONFIG1, NFC_RESET);
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:33 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:33 +0200
Subject: [PATCH v3 06/31] i2c: mpc: cleanup clock API use
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-7-git-send-email-gsi@denx.de>

make the MPC I2C driver get, prepare and enable the peripheral clock
('per' for access to the peripheral's registers) during probe;
disable, unprepare and put the clock upon remove(); hold a reference
to the clock over the period of use

clock lookup is non-fatal in this implementation as not all platforms
may provide clock specs in their device tree, but enable errors for
specified clocks are considered fatal

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/i2c/busses/i2c-mpc.c |   28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 7607dc0..9e837be 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -21,6 +21,7 @@
 #include <linux/of_i2c.h>
 #include <linux/slab.h>
 
+#include <linux/clk.h>
 #include <linux/io.h>
 #include <linux/fsl_devices.h>
 #include <linux/i2c.h>
@@ -67,6 +68,7 @@ struct mpc_i2c {
 #ifdef CONFIG_PM
 	u8 fdr, dfsrr;
 #endif
+	struct clk *clk_per;
 };
 
 struct mpc_i2c_divider {
@@ -623,6 +625,8 @@ static int fsl_i2c_probe(struct platform_device *op)
 	u32 clock = MPC_I2C_CLOCK_LEGACY;
 	int result = 0;
 	int plen;
+	struct clk *clk;
+	int err;
 
 	match = of_match_device(mpc_i2c_of_match, &op->dev);
 	if (!match)
@@ -653,6 +657,21 @@ static int fsl_i2c_probe(struct platform_device *op)
 		}
 	}
 
+	/*
+	 * enable clock for the I2C peripheral (non fatal),
+	 * keep a reference upon successful allocation
+	 */
+	clk = devm_clk_get(&op->dev, "per");
+	if (!IS_ERR(clk)) {
+		err = clk_prepare_enable(clk);
+		if (err) {
+			dev_err(&op->dev, "failed to enable clock\n");
+			devm_clk_put(&op->dev, clk);
+		} else {
+			i2c->clk_per = clk;
+		}
+	}
+
 	if (of_get_property(op->dev.of_node, "fsl,preserve-clocking", NULL)) {
 		clock = MPC_I2C_CLOCK_PRESERVE;
 	} else {
@@ -696,6 +715,10 @@ static int fsl_i2c_probe(struct platform_device *op)
 	return result;
 
  fail_add:
+	if (i2c->clk_per) {
+		clk_disable_unprepare(i2c->clk_per);
+		devm_clk_put(&op->dev, i2c->clk_per);
+	}
 	free_irq(i2c->irq, i2c);
  fail_request:
 	irq_dispose_mapping(i2c->irq);
@@ -711,6 +734,11 @@ static int fsl_i2c_remove(struct platform_device *op)
 
 	i2c_del_adapter(&i2c->adap);
 
+	if (i2c->clk_per) {
+		clk_disable_unprepare(i2c->clk_per);
+		devm_clk_put(&op->dev, i2c->clk_per);
+	}
+
 	if (i2c->irq)
 		free_irq(i2c->irq, i2c);
 
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:36 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:36 +0200
Subject: [PATCH v3 09/31] powerpc/fsl-pci: improve clock API use
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-10-git-send-email-gsi@denx.de>

make the Freescale PCI driver get, prepare and enable the PCI clock
during probe()

clock lookup is non-fatal as not all platforms may provide clock specs
in their device tree, but failure to enable specified clocks are fatal

the driver appears to not have a remove() routine, so no reference to
the clock is kept during use, and the clock isn't released (the devm
approach will put the clock, but it won't get disabled or unprepared)

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/sysdev/fsl_pci.c |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 46ac1dd..5e2f411 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -17,6 +17,8 @@
  * Free Software Foundation;  either version 2 of the  License, or (at your
  * option) any later version.
  */
+
+#include <linux/clk.h>
 #include <linux/kernel.h>
 #include <linux/pci.h>
 #include <linux/delay.h>
@@ -926,12 +928,33 @@ void fsl_pci_assign_primary(void)
 
 static int fsl_pci_probe(struct platform_device *pdev)
 {
+	struct clk *clk;
 	int ret;
 	struct device_node *node;
 #ifdef CONFIG_SWIOTLB
 	struct pci_controller *hose;
 #endif
 
+	/*
+	 * clock lookup is non-fatal since the driver is shared among
+	 * platforms and not all of them provide clocks specs in their
+	 * device tree, but failure to enable a specified clock is
+	 * considered fatal
+	 */
+	clk = devm_clk_get(&pdev->dev, "per");
+	if (!IS_ERR(clk)) {
+		ret = clk_prepare_enable(clk);
+		if (ret) {
+			dev_err(dev, "Could not enable peripheral clock\n");
+			devm_clk_put(&pdev->dev, clk);
+			return ret;
+		}
+		/*
+		 * TODO where to store the 'clk' reference?  there appears
+		 * to be no remove() routine which undoes what probe() does
+		 */
+	}
+
 	node = pdev->dev.of_node;
 	ret = fsl_add_bridge(pdev, fsl_pci_primary == node);
 
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:46 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:46 +0200
Subject: [PATCH v3 19/31] clk: mpc512x: don't pre-enable FEC and I2C clocks
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-20-git-send-email-gsi@denx.de>

after the device tree nodes provide clock specs for client side lookups,
peripheral drivers can attach to their clocks and the clock driver need
no longer pre-enable those clock items

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index 762ee85..8b71ceb 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -713,9 +713,7 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	clk_prepare_enable(clks[MPC512x_CLK_PSC_FIFO]);
 	/* some are not yet acquired by their respective drivers */
 	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
-	clk_prepare_enable(clks[MPC512x_CLK_FEC]);	/* network, NFS */
 	clk_prepare_enable(clks[MPC512x_CLK_DIU]);	/* display */
-	clk_prepare_enable(clks[MPC512x_CLK_I2C]);
 	/*
 	 * some have their individual clock subtree with separate clock
 	 * items and their individual enable counters, yet share a
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:39 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:39 +0200
Subject: [PATCH v3 12/31] powerpc: mpc512x: array decl for MCLK registers in
 CCM
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-13-git-send-email-gsi@denx.de>

reword the clock control module's registers declaration such that the
MCLK related registers form an array and get indexed by PSC number

this change is in preparation to COMMON_CLK support for the MPC512x
platform, the changed declaration remains neutral to existing code since
the PSC and MSCAN CCR fields declared here aren't referenced anywhere

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/include/asm/mpc5121.h |   18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/include/asm/mpc5121.h b/arch/powerpc/include/asm/mpc5121.h
index 8ae133e..887d3d6 100644
--- a/arch/powerpc/include/asm/mpc5121.h
+++ b/arch/powerpc/include/asm/mpc5121.h
@@ -32,25 +32,11 @@ struct mpc512x_ccm {
 	u32	scfr2;	/* System Clock Frequency Register 2 */
 	u32	scfr2s;	/* System Clock Frequency Shadow Register 2 */
 	u32	bcr;	/* Bread Crumb Register */
-	u32	p0ccr;	/* PSC0 Clock Control Register */
-	u32	p1ccr;	/* PSC1 CCR */
-	u32	p2ccr;	/* PSC2 CCR */
-	u32	p3ccr;	/* PSC3 CCR */
-	u32	p4ccr;	/* PSC4 CCR */
-	u32	p5ccr;	/* PSC5 CCR */
-	u32	p6ccr;	/* PSC6 CCR */
-	u32	p7ccr;	/* PSC7 CCR */
-	u32	p8ccr;	/* PSC8 CCR */
-	u32	p9ccr;	/* PSC9 CCR */
-	u32	p10ccr;	/* PSC10 CCR */
-	u32	p11ccr;	/* PSC11 CCR */
+	u32	psc_ccr[12];	/* PSC Clock Control Registers */
 	u32	spccr;	/* SPDIF Clock Control Register */
 	u32	cccr;	/* CFM Clock Control Register */
 	u32	dccr;	/* DIU Clock Control Register */
-	u32	m1ccr;	/* MSCAN1 CCR */
-	u32	m2ccr;	/* MSCAN2 CCR */
-	u32	m3ccr;	/* MSCAN3 CCR */
-	u32	m4ccr;	/* MSCAN4 CCR */
+	u32	mscan_ccr[4];	/* MSCAN Clock Control Registers */
 	u8	res[0x98]; /* Reserved */
 };
 
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:35 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:35 +0200
Subject: [PATCH v3 08/31] fs_enet: cleanup clock API use
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-9-git-send-email-gsi@denx.de>

make the Freescale ethernet driver get, prepare and enable the FEC clock
during probe(); disable, unprepare and put the clock upon remove(); hold
a reference to the clock over the period of use; use devm_{get,put}_clk()

clock lookup is non-fatal as not all platforms provide clock specs in
their device tree; failure to enable specified clocks is fatal

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 .../net/ethernet/freescale/fs_enet/fs_enet-main.c  |   25 ++++++++++++++++++++
 include/linux/fs_enet_pd.h                         |    3 +++
 2 files changed, 28 insertions(+)

diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index c04eb3a..1f58f57 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -999,6 +999,8 @@ static int fs_enet_probe(struct platform_device *ofdev)
 	struct fs_enet_private *fep;
 	struct fs_platform_info *fpi;
 	const u32 *data;
+	struct clk *clk;
+	int err;
 	const u8 *mac_addr;
 	const char *phy_connection_type;
 	int privsize, len, ret = -ENODEV;
@@ -1036,6 +1038,21 @@ static int fs_enet_probe(struct platform_device *ofdev)
 			fpi->use_rmii = 1;
 	}
 
+	/* make clock lookup non-fatal (the driver is shared among platforms),
+	 * but require enable to succeed when a clock was specified/found,
+	 * keep a reference to the clock upon successful acquisition
+	 */
+	clk = devm_clk_get(&ofdev->dev, "per");
+	if (!IS_ERR(clk)) {
+		err = clk_prepare_enable(clk);
+		if (err) {
+			devm_clk_put(&ofdev->dev, clk);
+			ret = err;
+			goto out_free_fpi;
+		}
+		fpi->clk_per = clk;
+	}
+
 	privsize = sizeof(*fep) +
 	           sizeof(struct sk_buff **) *
 	           (fpi->rx_ring + fpi->tx_ring);
@@ -1107,6 +1124,10 @@ out_free_dev:
 	free_netdev(ndev);
 out_put:
 	of_node_put(fpi->phy_node);
+	if (fpi->clk_per) {
+		clk_disable_unprepare(fpi->clk_per);
+		devm_clk_put(&ofdev->dev, fpi->clk_per);
+	}
 out_free_fpi:
 	kfree(fpi);
 	return ret;
@@ -1123,6 +1144,10 @@ static int fs_enet_remove(struct platform_device *ofdev)
 	fep->ops->cleanup_data(ndev);
 	dev_set_drvdata(fep->dev, NULL);
 	of_node_put(fep->fpi->phy_node);
+	if (fep->fpi->clk_per) {
+		clk_disable_unprepare(fep->fpi->clk_per);
+		devm_clk_put(&ofdev->dev, fep->fpi->clk_per);
+	}
 	free_netdev(ndev);
 	return 0;
 }
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 51b7934..a978d0d 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -16,6 +16,7 @@
 #ifndef FS_ENET_PD_H
 #define FS_ENET_PD_H
 
+#include <linux/clk.h>
 #include <linux/string.h>
 #include <linux/of_mdio.h>
 #include <asm/types.h>
@@ -142,6 +143,8 @@ struct fs_platform_info {
 
 	int use_rmii;		/* use RMII mode 	       */
 	int has_phy;            /* if the network is phy container as well...*/
+
+	struct clk *clk_per;	/* 'per' clock for register access */
 };
 struct fs_mii_fec_platform_info {
 	u32 irq[32];
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:38 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:38 +0200
Subject: [PATCH v3 11/31] net: can: mscan: improve clock API use
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-12-git-send-email-gsi@denx.de>

the .get_clock() callback is run from probe() and might allocate
resources, introduce a .put_clock() callback that is run from remove()
to undo any allocation activities

use devm_get_clk() upon lookup (for SYS and REF) to have the clocks put
upon driver unload

assume that resources get prepared but not necessarily enabled in the
setup phase, make the open() and close() callbacks of the CAN network
device enable and disable a previously acquired and prepared clock

store pointers to data structures upon successful allocation already
instead of deferral until complete setup, such that subroutines in the
setup sequence may access those data structures as well to track their
resource acquisition

since clock allocation remains optional, the release callback as well as
the enable/disable calls in open/close are optional as well

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/net/can/mscan/mpc5xxx_can.c |   18 ++++++++++++------
 drivers/net/can/mscan/mscan.c       |    9 +++++++++
 drivers/net/can/mscan/mscan.h       |    2 ++
 3 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index bc422ba..e59b3a3 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -40,6 +40,7 @@ struct mpc5xxx_can_data {
 	unsigned int type;
 	u32 (*get_clock)(struct platform_device *ofdev, const char *clock_name,
 			 int *mscan_clksrc);
+	void (*put_clock)(struct platform_device *ofdev);
 };
 
 #ifdef CONFIG_PPC_MPC52xx
@@ -180,7 +181,7 @@ static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 			clockdiv = 1;
 
 		if (!clock_name || !strcmp(clock_name, "sys")) {
-			sys_clk = clk_get(&ofdev->dev, "sys_clk");
+			sys_clk = devm_clk_get(&ofdev->dev, "sys_clk");
 			if (IS_ERR(sys_clk)) {
 				dev_err(&ofdev->dev, "couldn't get sys_clk\n");
 				goto exit_unmap;
@@ -203,7 +204,7 @@ static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 		}
 
 		if (clocksrc < 0) {
-			ref_clk = clk_get(&ofdev->dev, "ref_clk");
+			ref_clk = devm_clk_get(&ofdev->dev, "ref_clk");
 			if (IS_ERR(ref_clk)) {
 				dev_err(&ofdev->dev, "couldn't get ref_clk\n");
 				goto exit_unmap;
@@ -280,6 +281,8 @@ static int mpc5xxx_can_probe(struct platform_device *ofdev)
 	dev = alloc_mscandev();
 	if (!dev)
 		goto exit_dispose_irq;
+	platform_set_drvdata(ofdev, dev);
+	SET_NETDEV_DEV(dev, &ofdev->dev);
 
 	priv = netdev_priv(dev);
 	priv->reg_base = base;
@@ -296,8 +299,6 @@ static int mpc5xxx_can_probe(struct platform_device *ofdev)
 		goto exit_free_mscan;
 	}
 
-	SET_NETDEV_DEV(dev, &ofdev->dev);
-
 	err = register_mscandev(dev, mscan_clksrc);
 	if (err) {
 		dev_err(&ofdev->dev, "registering %s failed (err=%d)\n",
@@ -305,8 +306,6 @@ static int mpc5xxx_can_probe(struct platform_device *ofdev)
 		goto exit_free_mscan;
 	}
 
-	platform_set_drvdata(ofdev, dev);
-
 	dev_info(&ofdev->dev, "MSCAN at 0x%p, irq %d, clock %d Hz\n",
 		 priv->reg_base, dev->irq, priv->can.clock.freq);
 
@@ -324,10 +323,17 @@ exit_unmap_mem:
 
 static int mpc5xxx_can_remove(struct platform_device *ofdev)
 {
+	const struct of_device_id *match;
+	const struct mpc5xxx_can_data *data;
 	struct net_device *dev = platform_get_drvdata(ofdev);
 	struct mscan_priv *priv = netdev_priv(dev);
 
+	match = of_match_device(mpc5xxx_can_table, &ofdev->dev);
+	data = match ? match->data : NULL;
+
 	unregister_mscandev(dev);
+	if (data && data->put_clock)
+		data->put_clock(ofdev);
 	iounmap(priv->reg_base);
 	irq_dispose_mapping(dev->irq);
 	free_candev(dev);
diff --git a/drivers/net/can/mscan/mscan.c b/drivers/net/can/mscan/mscan.c
index e6b4095..1c08ffe 100644
--- a/drivers/net/can/mscan/mscan.c
+++ b/drivers/net/can/mscan/mscan.c
@@ -573,6 +573,12 @@ static int mscan_open(struct net_device *dev)
 	struct mscan_priv *priv = netdev_priv(dev);
 	struct mscan_regs __iomem *regs = priv->reg_base;
 
+	if (priv->clk_can) {
+		ret = clk_enable(priv->clk_can);
+		if (ret)
+			return ret;
+	}
+
 	/* common open */
 	ret = open_candev(dev);
 	if (ret)
@@ -621,6 +627,9 @@ static int mscan_close(struct net_device *dev)
 	close_candev(dev);
 	free_irq(dev->irq, dev);
 
+	if (priv->clk_can)
+		clk_disable(priv->clk_can);
+
 	return 0;
 }
 
diff --git a/drivers/net/can/mscan/mscan.h b/drivers/net/can/mscan/mscan.h
index af2ed8b..f32e190 100644
--- a/drivers/net/can/mscan/mscan.h
+++ b/drivers/net/can/mscan/mscan.h
@@ -21,6 +21,7 @@
 #ifndef __MSCAN_H__
 #define __MSCAN_H__
 
+#include <linux/clk.h>
 #include <linux/types.h>
 
 /* MSCAN control register 0 (CANCTL0) bits */
@@ -283,6 +284,7 @@ struct mscan_priv {
 	unsigned int type; 	/* MSCAN type variants */
 	unsigned long flags;
 	void __iomem *reg_base;	/* ioremap'ed address to registers */
+	struct clk *clk_can;	/* clock for registers or bitrates */
 	u8 shadow_statflg;
 	u8 shadow_canrier;
 	u8 cur_pri;
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:45 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:45 +0200
Subject: [PATCH v3 18/31] dts: mpc512x: add clock specs for client lookups
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-19-git-send-email-gsi@denx.de>

this addresses the client side of device tree based clock lookups

add clock specifiers to the mbx, nfc, mscan, sdhc, i2c, axe, diu, viu,
mdio, fec, usb, pata, psc, psc fifo, and pci nodes in the shared
mpc5121.dtsi include

these specs map 'clock-names' encoded in drivers to their respective
'struct clk' items in the platform's clock driver

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/boot/dts/mpc5121.dtsi |   79 ++++++++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi b/arch/powerpc/boot/dts/mpc5121.dtsi
index 8f4cba0..3657ae6 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -51,6 +51,10 @@
 		compatible = "fsl,mpc5121-mbx";
 		reg = <0x20000000 0x4000>;
 		interrupts = <66 0x8>;
+		clocks = <&clks MPC512x_CLK_MBX_BUS>,
+			 <&clks MPC512x_CLK_MBX_3D>,
+			 <&clks MPC512x_CLK_MBX>;
+		clock-names = "mbx-bus", "mbx-3d", "mbx";
 	};
 
 	sram at 30000000 {
@@ -64,6 +68,8 @@
 		interrupts = <6 8>;
 		#address-cells = <1>;
 		#size-cells = <1>;
+		clocks = <&clks MPC512x_CLK_NFC>;
+		clock-names = "per";
 	};
 
 	localbus at 80000020 {
@@ -153,12 +159,22 @@
 			compatible = "fsl,mpc5121-mscan";
 			reg = <0x1300 0x80>;
 			interrupts = <12 0x8>;
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SYS>,
+				 <&clks MPC512x_CLK_REF>,
+				 <&clks MPC512x_CLK_MSCAN0_MCLK>;
+			clock-names = "ips", "sys", "ref", "mclk";
 		};
 
 		can at 1380 {
 			compatible = "fsl,mpc5121-mscan";
 			reg = <0x1380 0x80>;
 			interrupts = <13 0x8>;
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SYS>,
+				 <&clks MPC512x_CLK_REF>,
+				 <&clks MPC512x_CLK_MSCAN1_MCLK>;
+			clock-names = "ips", "sys", "ref", "mclk";
 		};
 
 		sdhc at 1500 {
@@ -167,6 +183,9 @@
 			interrupts = <8 0x8>;
 			dmas = <&dma0 30>;
 			dma-names = "rx-tx";
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SDHC>;
+			clock-names = "ipg", "per";
 		};
 
 		i2c at 1700 {
@@ -175,6 +194,8 @@
 			compatible = "fsl,mpc5121-i2c", "fsl-i2c";
 			reg = <0x1700 0x20>;
 			interrupts = <9 0x8>;
+			clocks = <&clks MPC512x_CLK_I2C>;
+			clock-names = "per";
 		};
 
 		i2c at 1720 {
@@ -183,6 +204,8 @@
 			compatible = "fsl,mpc5121-i2c", "fsl-i2c";
 			reg = <0x1720 0x20>;
 			interrupts = <10 0x8>;
+			clocks = <&clks MPC512x_CLK_I2C>;
+			clock-names = "per";
 		};
 
 		i2c at 1740 {
@@ -191,6 +214,8 @@
 			compatible = "fsl,mpc5121-i2c", "fsl-i2c";
 			reg = <0x1740 0x20>;
 			interrupts = <11 0x8>;
+			clocks = <&clks MPC512x_CLK_I2C>;
+			clock-names = "per";
 		};
 
 		i2ccontrol at 1760 {
@@ -202,30 +227,46 @@
 			compatible = "fsl,mpc5121-axe";
 			reg = <0x2000 0x100>;
 			interrupts = <42 0x8>;
+			clocks = <&clks MPC512x_CLK_AXE>;
+			clock-names = "per";
 		};
 
 		display at 2100 {
 			compatible = "fsl,mpc5121-diu";
 			reg = <0x2100 0x100>;
 			interrupts = <64 0x8>;
+			clocks = <&clks MPC512x_CLK_DIU>;
+			clock-names = "per";
 		};
 
 		can at 2300 {
 			compatible = "fsl,mpc5121-mscan";
 			reg = <0x2300 0x80>;
 			interrupts = <90 0x8>;
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SYS>,
+				 <&clks MPC512x_CLK_REF>,
+				 <&clks MPC512x_CLK_MSCAN2_MCLK>;
+			clock-names = "ips", "sys", "ref", "mclk";
 		};
 
 		can at 2380 {
 			compatible = "fsl,mpc5121-mscan";
 			reg = <0x2380 0x80>;
 			interrupts = <91 0x8>;
+			clocks = <&clks MPC512x_CLK_IPS>,
+				 <&clks MPC512x_CLK_SYS>,
+				 <&clks MPC512x_CLK_REF>,
+				 <&clks MPC512x_CLK_MSCAN3_MCLK>;
+			clock-names = "ips", "sys", "ref", "mclk";
 		};
 
 		viu at 2400 {
 			compatible = "fsl,mpc5121-viu";
 			reg = <0x2400 0x400>;
 			interrupts = <67 0x8>;
+			clocks = <&clks MPC512x_CLK_VIU>;
+			clock-names = "per";
 		};
 
 		mdio at 2800 {
@@ -233,6 +274,8 @@
 			reg = <0x2800 0x800>;
 			#address-cells = <1>;
 			#size-cells = <0>;
+			clocks = <&clks MPC512x_CLK_FEC>;
+			clock-names = "per";
 		};
 
 		eth0: ethernet at 2800 {
@@ -241,6 +284,8 @@
 			reg = <0x2800 0x800>;
 			local-mac-address = [ 00 00 00 00 00 00 ];
 			interrupts = <4 0x8>;
+			clocks = <&clks MPC512x_CLK_FEC>;
+			clock-names = "per";
 		};
 
 		/* USB1 using external ULPI PHY */
@@ -252,6 +297,8 @@
 			interrupts = <43 0x8>;
 			dr_mode = "otg";
 			phy_type = "ulpi";
+			clocks = <&clks MPC512x_CLK_USB1>;
+			clock-names = "per";
 		};
 
 		/* USB0 using internal UTMI PHY */
@@ -263,6 +310,8 @@
 			interrupts = <44 0x8>;
 			dr_mode = "otg";
 			phy_type = "utmi_wide";
+			clocks = <&clks MPC512x_CLK_USB2>;
+			clock-names = "per";
 		};
 
 		/* IO control */
@@ -281,6 +330,8 @@
 			compatible = "fsl,mpc5121-pata";
 			reg = <0x10200 0x100>;
 			interrupts = <5 0x8>;
+			clocks = <&clks MPC512x_CLK_PATA>;
+			clock-names = "per";
 		};
 
 		/* 512x PSCs are not 52xx PSC compatible */
@@ -292,6 +343,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC0_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC1 */
@@ -301,6 +354,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC1_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC2 */
@@ -310,6 +365,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC2_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC3 */
@@ -319,6 +376,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC3_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC4 */
@@ -328,6 +387,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC4_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC5 */
@@ -337,6 +398,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC5_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC6 */
@@ -346,6 +409,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC6_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC7 */
@@ -355,6 +420,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC7_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC8 */
@@ -364,6 +431,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC8_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC9 */
@@ -373,6 +442,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC9_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC10 */
@@ -382,6 +453,8 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC10_MCLK>;
+			clock-names = "mclk";
 		};
 
 		/* PSC11 */
@@ -391,12 +464,16 @@
 			interrupts = <40 0x8>;
 			fsl,rx-fifo-size = <16>;
 			fsl,tx-fifo-size = <16>;
+			clocks = <&clks MPC512x_CLK_PSC11_MCLK>;
+			clock-names = "mclk";
 		};
 
 		pscfifo at 11f00 {
 			compatible = "fsl,mpc5121-psc-fifo";
 			reg = <0x11f00 0x100>;
 			interrupts = <40 0x8>;
+			clocks = <&clks MPC512x_CLK_PSC_FIFO>;
+			clock-names = "per";
 		};
 
 		dma0: dma at 14000 {
@@ -414,6 +491,8 @@
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
+		clocks = <&clks MPC512x_CLK_PCI>;
+		clock-names = "per";
 
 		reg = <0x80008500 0x100	/* internal registers */
 		       0x80008300 0x8>;	/* config space access registers */
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:47 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:47 +0200
Subject: [PATCH v3 20/31] spi: mpc512x: remove now obsolete clock lookup name
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-21-git-send-email-gsi@denx.de>

after device tree based clock lookup became available, the peripheral
driver need no longer construct clock names which include the PSC index,
remove the "psc%d_mclk" template and unconditionally use "mclk"

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/spi/spi-mpc512x-psc.c |    6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c
index 823e5e0..1a4a983 100644
--- a/drivers/spi/spi-mpc512x-psc.c
+++ b/drivers/spi/spi-mpc512x-psc.c
@@ -474,8 +474,6 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
 	struct spi_master *master;
 	int ret;
 	void *tempp;
-	int psc_num;
-	char clk_name[16];
 	struct clk *clk;
 
 	master = spi_alloc_master(dev, sizeof *mps);
@@ -519,9 +517,7 @@ static int mpc512x_psc_spi_do_probe(struct device *dev, u32 regaddr,
 		goto free_master;
 	init_completion(&mps->txisrdone);
 
-	psc_num = master->bus_num;
-	snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
-	clk = devm_clk_get(dev, clk_name);
+	clk = devm_clk_get(dev, "mclk");
 	if (IS_ERR(clk))
 		goto free_irq;
 	ret = clk_prepare_enable(clk);
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:37 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:37 +0200
Subject: [PATCH v3 10/31] net: can: mscan: add a comment on reg to idx mapping
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-11-git-send-email-gsi@denx.de>

add a comment about the magic of deriving an MSCAN component index
from the peripheral's physical address / register offset

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/net/can/mscan/mpc5xxx_can.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index 5b0ee8e..bc422ba 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -148,7 +148,10 @@ static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 		goto exit_put;
 	}
 
-	/* Determine the MSCAN device index from the physical address */
+	/* Determine the MSCAN device index from the peripheral's
+	 * physical address. Register address offsets against the
+	 * IMMR base are:  0x1300, 0x1380, 0x2300, 0x2380
+	 */
 	pval = of_get_property(ofdev->dev.of_node, "reg", &plen);
 	BUG_ON(!pval || plen < sizeof(*pval));
 	clockidx = (*pval & 0x80) ? 1 : 0;
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:48 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:48 +0200
Subject: [PATCH v3 21/31] serial: mpc512x: remove now obsolete clock lookup
 name
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-22-git-send-email-gsi@denx.de>

after device tree based clock lookup became available, the peripheral
driver need no longer construct clock names which include the PSC index,
remove the "psc%d_mclk" template and unconditionally use "mclk"

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/tty/serial/mpc52xx_uart.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/mpc52xx_uart.c b/drivers/tty/serial/mpc52xx_uart.c
index 8f16ed9..04dc564 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -623,14 +623,11 @@ static struct clk *psc_mclk_clk[MPC52xx_PSC_MAXNUM];
 /* called from within the .request_port() callback (allocation) */
 static int mpc512x_psc_alloc_clock(struct uart_port *port)
 {
-	int psc_num;
-	char clk_name[16];
 	struct clk *clk;
 	int err;
+	int psc_num;
 
-	psc_num = (port->mapbase & 0xf00) >> 8;
-	snprintf(clk_name, sizeof(clk_name), "psc%d_mclk", psc_num);
-	clk = devm_clk_get(port->dev, clk_name);
+	clk = devm_clk_get(port->dev, "mclk");
 	if (IS_ERR(clk)) {
 		dev_err(port->dev, "Failed to get MCLK!\n");
 		return PTR_ERR(clk);
@@ -641,6 +638,7 @@ static int mpc512x_psc_alloc_clock(struct uart_port *port)
 		devm_clk_put(port->dev, clk);
 		return err;
 	}
+	psc_num = (port->mapbase & 0xf00) >> 8;
 	psc_mclk_clk[psc_num] = clk;
 	return 0;
 }
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:40 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:40 +0200
Subject: [PATCH v3 13/31] clk: wrap I/O access for improved portability
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-14-git-send-email-gsi@denx.de>

the common clock drivers were motivated/initiated by ARM development
and apparently assume little endian peripherals

wrap register/peripherals access in the common code (div, gate, mux)
in preparation of adding COMMON_CLK support for other platforms

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/clk/clk-divider.c    |    6 +++---
 drivers/clk/clk-gate.c       |    6 +++---
 drivers/clk/clk-mux.c        |    6 +++---
 include/linux/clk-provider.h |   17 +++++++++++++++++
 4 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 6d55eb2..2c07061 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -104,7 +104,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
 	struct clk_divider *divider = to_clk_divider(hw);
 	unsigned int div, val;
 
-	val = readl(divider->reg) >> divider->shift;
+	val = clk_readl(divider->reg) >> divider->shift;
 	val &= div_mask(divider);
 
 	div = _get_div(divider, val);
@@ -230,11 +230,11 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
 	if (divider->flags & CLK_DIVIDER_HIWORD_MASK) {
 		val = div_mask(divider) << (divider->shift + 16);
 	} else {
-		val = readl(divider->reg);
+		val = clk_readl(divider->reg);
 		val &= ~(div_mask(divider) << divider->shift);
 	}
 	val |= value << divider->shift;
-	writel(val, divider->reg);
+	clk_writel(val, divider->reg);
 
 	if (divider->lock)
 		spin_unlock_irqrestore(divider->lock, flags);
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 790306e..b7fbd96 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -58,7 +58,7 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable)
 		if (set)
 			reg |= BIT(gate->bit_idx);
 	} else {
-		reg = readl(gate->reg);
+		reg = clk_readl(gate->reg);
 
 		if (set)
 			reg |= BIT(gate->bit_idx);
@@ -66,7 +66,7 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable)
 			reg &= ~BIT(gate->bit_idx);
 	}
 
-	writel(reg, gate->reg);
+	clk_writel(reg, gate->reg);
 
 	if (gate->lock)
 		spin_unlock_irqrestore(gate->lock, flags);
@@ -89,7 +89,7 @@ static int clk_gate_is_enabled(struct clk_hw *hw)
 	u32 reg;
 	struct clk_gate *gate = to_clk_gate(hw);
 
-	reg = readl(gate->reg);
+	reg = clk_readl(gate->reg);
 
 	/* if a set bit disables this clk, flip it before masking */
 	if (gate->flags & CLK_GATE_SET_TO_DISABLE)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 614444c..02ef506 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -42,7 +42,7 @@ static u8 clk_mux_get_parent(struct clk_hw *hw)
 	 * OTOH, pmd_trace_clk_mux_ck uses a separate bit for each clock, so
 	 * val = 0x4 really means "bit 2, index starts at bit 0"
 	 */
-	val = readl(mux->reg) >> mux->shift;
+	val = clk_readl(mux->reg) >> mux->shift;
 	val &= mux->mask;
 
 	if (mux->table) {
@@ -89,11 +89,11 @@ static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
 	if (mux->flags & CLK_MUX_HIWORD_MASK) {
 		val = mux->mask << (mux->shift + 16);
 	} else {
-		val = readl(mux->reg);
+		val = clk_readl(mux->reg);
 		val &= ~(mux->mask << mux->shift);
 	}
 	val |= index << mux->shift;
-	writel(val, mux->reg);
+	clk_writel(val, mux->reg);
 
 	if (mux->lock)
 		spin_unlock_irqrestore(mux->lock, flags);
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1ec14a7..c4f7799 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -12,6 +12,7 @@
 #define __LINUX_CLK_PROVIDER_H
 
 #include <linux/clk.h>
+#include <linux/io.h>
 
 #ifdef CONFIG_COMMON_CLK
 
@@ -490,5 +491,21 @@ static inline const char *of_clk_get_parent_name(struct device_node *np,
 #define of_clk_init(matches) \
 	{ while (0); }
 #endif /* CONFIG_OF */
+
+/*
+ * wrap access to peripherals in accessor routines
+ * for improved portability across platforms
+ */
+
+static inline u32 clk_readl(u32 __iomem *reg)
+{
+	return readl(reg);
+}
+
+static inline void clk_writel(u32 val, u32 __iomem *reg)
+{
+	writel(val, reg);
+}
+
 #endif /* CONFIG_COMMON_CLK */
 #endif /* CLK_PROVIDER_H */
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:44 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:44 +0200
Subject: [PATCH v3 17/31] clk: mpc512x: introduce COMMON_CLK for MPC512x
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-18-git-send-email-gsi@denx.de>

this change implements a clock driver for the MPC512x PowerPC platform
which follows the COMMON_CLK approach and uses common clock drivers
shared with other platforms

this driver implements the publicly announced set of clocks (which can
get referenced by means of symbolic identifiers from the dt-bindings
header file), as well as generates additional 'struct clk' items where
the SoC hardware cannot easily get mapped to the common primitives of
the clock API, or requires "intermediate" clock nodes to represent
clocks that have both gates and dividers

the previous PPC_CLOCK implementation is kept in place and remains in
parallel to the common clock implementation for test and comparison
during migration, a compile time option picks one of the two
alternatives (Kconfig switch, common clock used by default)

some of the clock items get pre-enabled in the clock driver to not have
them automatically disabled by the underlying clock subsystem because of
their being unused -- this approach is desirable because
- some of the clocks are useful to have for diagnostics and information
  despite their not getting claimed by any drivers (CPU, internal and
  external RAM, internal busses, boot media)
- some of the clocks aren't claimed by their peripheral drivers yet,
  either because of missing driver support or because device tree specs
  aren't available yet (but the workarounds will get removed as the
  drivers get adjusted and the device tree provides the clock specs)
- some help introduce support for and migrate to the common
  infrastructure, while more appropriate support for specific hardware
  constraints isn't available yet (remaining changes are strictly
  internal to the clock driver and won't affect peripheral drivers)

clkdev registration provides "alias names" for few clock items
- to not break those peripheral drivers which encode their component
  index into the name that is used for clock lookup (UART, SPI, USB)
- to not break those drivers which use names for the clock lookup which
  were encoded in the previous PPC_CLOCK implementation (NFC, VIU, CAN)
this workaround will get removed as these drivers get adjusted after
device tree based clock lookup has become available

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/Kconfig           |   14 +-
 arch/powerpc/platforms/512x/Makefile          |    4 +-
 arch/powerpc/platforms/512x/clock-commonclk.c |  786 +++++++++++++++++++++++++
 include/linux/clk-provider.h                  |   16 +
 4 files changed, 818 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/platforms/512x/clock-commonclk.c

diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig
index fc9c1cb..c5fcdd0 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -1,9 +1,21 @@
+config MPC512x_COMMON_CLK
+	bool "MPC512x platform uses COMMON_CLK"
+	default y
+	depends on PPC_MPC512x
+	help
+	  This option is only here to support tests and comparison
+	  during development and migration.  This option will get
+	  removed after the COMMON_CLK support for MPC512x has become
+	  fully operational and all drivers were adjusted to explicitly
+	  acquire their required clocks.
+
 config PPC_MPC512x
 	bool "512x-based boards"
 	depends on 6xx
 	select FSL_SOC
 	select IPIC
-	select PPC_CLOCK
+	select PPC_CLOCK if !MPC512x_COMMON_CLK
+	select COMMON_CLK if MPC512x_COMMON_CLK
 	select PPC_PCI_CHOICE
 	select FSL_PCI if PCI
 	select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/powerpc/platforms/512x/Makefile b/arch/powerpc/platforms/512x/Makefile
index 72fb934..1e05f9d 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -1,7 +1,9 @@
 #
 # Makefile for the Freescale PowerPC 512x linux kernel.
 #
-obj-y				+= clock.o mpc512x_shared.o
+obj-$(CONFIG_PPC_CLOCK)		+= clock.o
+obj-$(CONFIG_COMMON_CLK)	+= clock-commonclk.o
+obj-y				+= mpc512x_shared.o
 obj-$(CONFIG_MPC5121_ADS)	+= mpc5121_ads.o mpc5121_ads_cpld.o
 obj-$(CONFIG_MPC512x_GENERIC)	+= mpc512x_generic.o
 obj-$(CONFIG_PDM360NG)		+= pdm360ng.o
diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
new file mode 100644
index 0000000..762ee85
--- /dev/null
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -0,0 +1,786 @@
+/*
+ * Copyright (C) 2013 DENX Software Engineering
+ *
+ * Gerhard Sittig, <gsi at denx.de>
+ *
+ * common clock driver support for the MPC512x platform
+ *
+ * This is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+#include <linux/of.h>
+
+#include <asm/mpc5121.h>
+#include <dt-bindings/clock/mpc512x-clock.h>
+
+#include "mpc512x.h"		/* our public mpc5121_clk_init() API */
+
+/* helpers to keep the MCLK intermediates "somewhere" in our table */
+enum {
+	MCLK_IDX_MUX0,
+	MCLK_IDX_EN0,
+	MCLK_IDX_DIV0,
+	MCLK_IDX_MUX1,
+	MCLK_MAX_IDX,
+};
+
+#define NR_PSCS			12
+#define NR_MSCANS		4
+#define NR_SPDIFS		1
+#define NR_MCLKS		(NR_PSCS + NR_MSCANS + NR_SPDIFS)
+
+/* extend the public set of clocks by adding internal slots for management */
+enum {
+	/* arrange for adjacent numbers after the public set */
+	MPC512x_CLK_START_PRIVATE = MPC512x_CLK_LAST_PUBLIC,
+	/* clocks which aren't announced to the public */
+	MPC512x_CLK_DDR,
+	MPC512x_CLK_MEM,
+	MPC512x_CLK_IIM,
+	MPC512x_CLK_SDHC_2,
+	/* intermediates in div+gate combos or fractional dividers */
+	MPC512x_CLK_DDR_UG,
+	MPC512x_CLK_SDHC_x4,
+	MPC512x_CLK_SDHC_UG,
+	MPC512x_CLK_DIU_x4,
+	MPC512x_CLK_DIU_UG,
+	MPC512x_CLK_MBX_BUS_UG,
+	MPC512x_CLK_MBX_UG,
+	MPC512x_CLK_MBX_3D_UG,
+	MPC512x_CLK_PCI_UG,
+	MPC512x_CLK_NFC_UG,
+	MPC512x_CLK_LPC_UG,
+	MPC512x_CLK_SPDIF_TX_IN,
+	/* intermediates for the mux+gate+div+mux MCLK generation */
+	MPC512x_CLK_MCLKS_FIRST,
+	MPC512x_CLK_MCLKS_LAST = MPC512x_CLK_MCLKS_FIRST
+				+ NR_MCLKS * MCLK_MAX_IDX,
+	/* internal, symbolic spec for the number of slots */
+	MPC512x_CLK_LAST_PRIVATE,
+};
+
+/* data required for the OF clock provider registration */
+static struct clk *clks[MPC512x_CLK_LAST_PRIVATE];
+static struct clk_onecell_data clk_data;
+
+/* CCM register access */
+static struct mpc512x_ccm __iomem *clkregs;
+static DEFINE_SPINLOCK(clklock);
+
+/* convenience wrappers around the common clk API */
+static inline struct clk *mpc512x_clk_fixed(const char *name, int rate)
+{
+	return clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
+}
+
+static inline struct clk *mpc512x_clk_factor(
+	const char *name, const char *parent_name,
+	int mul, int div)
+{
+	int clkflags;
+
+	clkflags = CLK_SET_RATE_PARENT;
+	return clk_register_fixed_factor(NULL, name, parent_name, clkflags,
+					 mul, div);
+}
+
+static inline struct clk *mpc512x_clk_divider(
+	const char *name, const char *parent_name, u8 clkflags,
+	u32 __iomem *reg, u8 pos, u8 len, int divflags)
+{
+	return clk_register_divider(NULL, name, parent_name, clkflags,
+				    reg, pos, len, divflags, &clklock);
+}
+
+static inline struct clk *mpc512x_clk_divtable(
+	const char *name, const char *parent_name,
+	u32 __iomem *reg, u8 pos, u8 len,
+	const struct clk_div_table *divtab)
+{
+	u8 divflags;
+
+	divflags = 0;
+	return clk_register_divider_table(NULL, name, parent_name, 0,
+					  reg, pos, len, divflags,
+					  divtab, &clklock);
+}
+
+static inline struct clk *mpc512x_clk_gated(
+	const char *name, const char *parent_name,
+	u32 __iomem *reg, u8 pos)
+{
+	int clkflags;
+
+	clkflags = CLK_SET_RATE_PARENT;
+	return clk_register_gate(NULL, name, parent_name, clkflags,
+				 reg, pos, 0, &clklock);
+}
+
+static inline struct clk *mpc512x_clk_muxed(const char *name,
+	const char **parent_names, int parent_count,
+	u32 __iomem *reg, u8 pos, u8 len)
+{
+	int clkflags;
+	u8 muxflags;
+
+	clkflags = CLK_SET_RATE_PARENT;
+	muxflags = 0;
+	return clk_register_mux(NULL, name,
+				parent_names, parent_count, clkflags,
+				reg, pos, len, muxflags, &clklock);
+}
+
+/* helper to isolate a bit field from a register */
+static inline int get_bit_field(uint32_t __iomem *reg, uint8_t pos, uint8_t len)
+{
+	uint32_t val;
+
+	val = in_be32(reg);
+	val >>= pos;
+	val &= (1 << len) - 1;
+	return val;
+}
+
+/* get the SPMF and translate it into the "sys pll" multiplier */
+static int get_spmf_mult(void)
+{
+	static int spmf_to_mult[] = {
+		68, 1, 12, 16, 20, 24, 28, 32,
+		36, 40, 44, 48, 52, 56, 60, 64,
+	};
+	int spmf;
+
+	spmf = get_bit_field(&clkregs->spmr, 24, 4);
+	return spmf_to_mult[spmf];
+}
+
+/*
+ * get the SYS_DIV value and translate it into a divide factor
+ *
+ * values returned from here are a multiple of the real factor since the
+ * divide ratio is fractional
+ */
+static int get_sys_div_x2(void)
+{
+	static int sysdiv_code_to_x2[] = {
+		4, 5, 6, 7, 8, 9, 10, 14,
+		12, 16, 18, 22, 20, 24, 26, 30,
+		28, 32, 34, 38, 36, 40, 42, 46,
+		44, 48, 50, 54, 52, 56, 58, 62,
+		60, 64, 66,
+	};
+	int divcode;
+
+	divcode = get_bit_field(&clkregs->scfr2, 26, 6);
+	return sysdiv_code_to_x2[divcode];
+}
+
+/*
+ * get the CPMF value and translate it into a multiplier factor
+ *
+ * values returned from here are a multiple of the real factor since the
+ * multiplier ratio is fractional
+ */
+static int get_cpmf_mult_x2(void)
+{
+	static int cpmf_to_mult[] = {
+		72, 2, 2, 3, 4, 5, 6, 7,
+	};
+	int cpmf;
+
+	cpmf = get_bit_field(&clkregs->spmr, 16, 4);
+	return cpmf_to_mult[cpmf];
+}
+
+/*
+ * some of the clock dividers do scale in a linear way, yet not all of
+ * their bit combinations are legal; use a divider table to get a
+ * resulting set of applicable divider values
+ */
+
+/* applies to the IPS_DIV, and PCI_DIV values */
+static struct clk_div_table divtab_2346[] = {
+	{ .val = 2, .div = 2, },
+	{ .val = 3, .div = 3, },
+	{ .val = 4, .div = 4, },
+	{ .val = 6, .div = 6, },
+	{ .div = 0, },
+};
+
+/* applies to the MBX_DIV, LPC_DIV, and NFC_DIV values */
+static struct clk_div_table divtab_1234[] = {
+	{ .val = 1, .div = 1, },
+	{ .val = 2, .div = 2, },
+	{ .val = 3, .div = 3, },
+	{ .val = 4, .div = 4, },
+	{ .div = 0, },
+};
+
+static int get_freq_from_dt(char *propname)
+{
+	struct device_node *np;
+	const unsigned int *prop;
+	int val;
+
+	val = 0;
+	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-immr");
+	if (np) {
+		prop = of_get_property(np, propname, NULL);
+		if (prop)
+			val = *prop;
+	    of_node_put(np);
+	}
+	return val;
+}
+
+static void mpc512x_clk_preset_data(void)
+{
+	size_t i;
+
+	for (i = 0; i < ARRAY_SIZE(clks); i++)
+		clks[i] = ERR_PTR(-ENODEV);
+}
+
+/*
+ * - receives the "bus frequency" from the caller (that's the IPS clock
+ *   rate, the historical source of clock information)
+ * - fetches the system PLL multiplier and divider values as well as the
+ *   IPS divider value from hardware
+ * - determines the REF clock rate either from the XTAL/OSC spec (if
+ *   there is a device tree node describing the oscillator) or from the
+ *   IPS bus clock (supported for backwards compatibility, such that
+ *   setups without XTAL/OSC specs keep working)
+ * - creates the "ref" clock item in the clock tree, such that
+ *   subsequent code can create the remainder of the hierarchy (REF ->
+ *   SYS -> CSB -> IPS) from the REF clock rate and the returned mul/div
+ *   values
+ */
+static void mpc512x_clk_setup_ref_clock(int bus_freq,
+	int *sys_mul, int *sys_div, int *ips_div)
+{
+	struct clk *osc_clk;
+	int calc_freq;
+
+	/* fetch mul/div factors from the hardware */
+	*sys_mul = get_spmf_mult();
+	*sys_mul *= 2;		/* compensate for the fractional divider */
+	*sys_div = get_sys_div_x2();
+	*ips_div = get_bit_field(&clkregs->scfr1, 23, 3);
+
+	/* lookup the oscillator node */
+	osc_clk = clk_get(NULL, "osc");
+	if (osc_clk) {
+		/* descend REF directly from OSC, verify the IPS rate */
+		clks[MPC512x_CLK_REF] = mpc512x_clk_factor("ref", "osc", 1, 1);
+		calc_freq = clk_get_rate(clks[MPC512x_CLK_REF]);
+		calc_freq *= *sys_mul;
+		calc_freq /= *sys_div;
+		calc_freq /= 2;
+		calc_freq /= *ips_div;
+		if (bus_freq && calc_freq != bus_freq)
+			pr_warn("calc rate %d != OF spec %d\n",
+				calc_freq, bus_freq);
+	} else {
+		/* calculate OSC rate and create REF from the freq value */
+		calc_freq = bus_freq;	/* start with IPS */
+		calc_freq *= *ips_div;	/* IPS -> CSB */
+		calc_freq *= 2;		/* CSB -> SYS */
+		calc_freq *= *sys_div;	/* SYS -> PLL out */
+		calc_freq /= *sys_mul;	/* PLL out -> REF == OSC */
+		clks[MPC512x_CLK_REF] = mpc512x_clk_fixed("ref", calc_freq);
+	}
+}
+
+/*
+ * helper code for the MCLK subtree setup
+ *
+ * the overview in section 5.2.4 of the MPC5121e Reference Manual rev4
+ * suggests that all instances of the "PSC clock generation" are equal,
+ * and that one might re-use the PSC setup for MSCAN clock generation
+ * (section 5.2.5) as well, at least the logic if not the data for
+ * description
+ *
+ * the details (starting at page 5-20) show differences in the specific
+ * inputs of the first mux stage ("can clk in", "spdif tx"), and the
+ * factual non-availability of the second mux stage (it's present yet
+ * only one input is valid)
+ *
+ * the MSCAN clock related registers (starting at page 5-35) all
+ * reference "spdif clk" at the first mux stage and don't mention any
+ * "can clk" at all, which somehow is unexpected
+ *
+ * TODO re-check the document, and clarify whether the RM is correct in
+ * the overview or in the details, and whether the difference is a
+ * clipboard induced error or results from chip revisions
+ *
+ * it turns out that the RM rev4 as of 2012-06 talks about "can" for the
+ * PSCs while RM rev3 as of 2008-10 talks about "spdif", so I guess that
+ * first a doc update is required which better reflects reality in the
+ * SoC before the implementation should follow while no questions remain
+ */
+
+/*
+ * note that this declaration raises a checkpatch warning, but
+ * it's the very data type which <linux/clk-provider.h> expects,
+ * making this declaration pass checkpatch will break compilation
+ */
+static const char *parent_names_mux0[] = {
+	"sys", "ref", "psc-mclk-in", "spdif-tx",
+};
+
+enum mclk_type {
+	MCLK_TYPE_PSC,
+	MCLK_TYPE_MSCAN,
+	MCLK_TYPE_SPDIF,
+};
+
+struct mclk_setup_data {
+	enum mclk_type type;
+	int comp_idx;
+	bool has_mclk1;
+	int bit_sccr1, bit_sccr2;
+	const char *name_mux0;
+	const char *name_en0;
+	const char *name_div0;
+	const char *parent_names_mux1[2];
+	const char *name_mux1;
+	const char *name_mclk;
+};
+
+#define MCLK_SETUP_DATA_PSC(id) { \
+	MCLK_TYPE_PSC, id, \
+	0, 27 - id, -1, \
+	"psc" #id "-mux0", \
+	"psc" #id "-en0", \
+	"psc" #id "_mclk_div", \
+	{ "psc" #id "_mclk_div", "dummy", }, \
+	"psc" #id "_mclk_out", \
+	"psc" #id "_mclk", \
+}
+
+#define MCLK_SETUP_DATA_MSCAN(id) { \
+	MCLK_TYPE_MSCAN, id, \
+	0, -1, 25, \
+	"mscan" #id "-mux0", \
+	"mscan" #id "-en0", \
+	"mscan" #id "_mclk_div", \
+	{ "mscan" #id "_mclk_div", "dummy", }, \
+	"mscan" #id "_mclk_out", \
+	"mscan" #id "_mclk", \
+}
+
+#define MCLK_SETUP_DATA_SPDIF { \
+	MCLK_TYPE_SPDIF, 0, \
+	1, -1, 23, \
+	"spdif-mux0", \
+	"spdif-en0", \
+	"spdif_mclk_div", \
+	{ "spdif_mclk_div", "spdif-rx", }, \
+	"spdif_mclk_out", \
+	"spdif_mclk", \
+}
+
+static struct mclk_setup_data mclk_psc_data[] = {
+	MCLK_SETUP_DATA_PSC(0),
+	MCLK_SETUP_DATA_PSC(1),
+	MCLK_SETUP_DATA_PSC(2),
+	MCLK_SETUP_DATA_PSC(3),
+	MCLK_SETUP_DATA_PSC(4),
+	MCLK_SETUP_DATA_PSC(5),
+	MCLK_SETUP_DATA_PSC(6),
+	MCLK_SETUP_DATA_PSC(7),
+	MCLK_SETUP_DATA_PSC(8),
+	MCLK_SETUP_DATA_PSC(9),
+	MCLK_SETUP_DATA_PSC(10),
+	MCLK_SETUP_DATA_PSC(11),
+};
+
+static struct mclk_setup_data mclk_mscan_data[] = {
+	MCLK_SETUP_DATA_MSCAN(0),
+	MCLK_SETUP_DATA_MSCAN(1),
+	MCLK_SETUP_DATA_MSCAN(2),
+	MCLK_SETUP_DATA_MSCAN(3),
+};
+
+static struct mclk_setup_data mclk_spdif_data[] = {
+	MCLK_SETUP_DATA_SPDIF,
+};
+
+/* setup the MCLK clock subtree of an individual PSC/MSCAN/SPDIF */
+static void mpc512x_clk_setup_mclk(struct mclk_setup_data *entry)
+{
+	size_t clks_idx_pub, clks_idx_int;
+	u32 __iomem *mccr_reg;	/* MCLK control register (mux, en, div) */
+	u32 __iomem *sccr_reg;	/* system clock control register (enable) */
+	int sccr_bit;
+	int div;
+
+	/* derive a few parameters from the component type and index */
+	switch (entry->type) {
+	case MCLK_TYPE_PSC:
+		clks_idx_pub = MPC512x_CLK_PSC0_MCLK + entry->comp_idx;
+		clks_idx_int = MPC512x_CLK_MCLKS_FIRST
+			     + (entry->comp_idx) * MCLK_MAX_IDX;
+		mccr_reg = &clkregs->psc_ccr[entry->comp_idx];
+		break;
+	case MCLK_TYPE_MSCAN:
+		clks_idx_pub = MPC512x_CLK_MSCAN0_MCLK + entry->comp_idx;
+		clks_idx_int = MPC512x_CLK_MCLKS_FIRST
+			     + (NR_PSCS + entry->comp_idx) * MCLK_MAX_IDX;
+		mccr_reg = &clkregs->mscan_ccr[entry->comp_idx];
+		break;
+	case MCLK_TYPE_SPDIF:
+		clks_idx_pub = MPC512x_CLK_SPDIF_MCLK;
+		clks_idx_int = MPC512x_CLK_MCLKS_FIRST
+			     + (NR_PSCS + NR_MSCANS) * MCLK_MAX_IDX;
+		mccr_reg = &clkregs->spccr;
+		break;
+	default:
+		return;
+	}
+	if (entry->bit_sccr1 >= 0) {
+		sccr_reg = &clkregs->sccr1;
+		sccr_bit = entry->bit_sccr1;
+	} else if (entry->bit_sccr2 >= 0) {
+		sccr_reg = &clkregs->sccr2;
+		sccr_bit = entry->bit_sccr2;
+	} else {
+		sccr_reg = NULL;
+	}
+
+	/*
+	 * this was grabbed from the PPC_CLOCK implementation, which
+	 * enforced a specific MCLK divider while the clock was gated
+	 * during setup (that's a documented hardware requirement)
+	 *
+	 * the PPC_CLOCK implementation might even have violated the
+	 * "MCLK <= IPS" constraint, the fixed divider value of 1
+	 * results in a divider of 2 and thus MCLK = SYS/2 which equals
+	 * CSB which is greater than IPS; the serial port setup may have
+	 * adjusted the divider which the clock setup might have left in
+	 * an undesirable state
+	 *
+	 * initial setup is:
+	 * - MCLK 0 from SYS
+	 * - MCLK DIV such to not exceed the IPS clock
+	 * - MCLK 0 enabled
+	 * - MCLK 1 from MCLK DIV
+	 */
+	div = clk_get_rate(clks[MPC512x_CLK_SYS]);
+	div /= clk_get_rate(clks[MPC512x_CLK_IPS]);
+	out_be32(mccr_reg, (0 << 16));
+	out_be32(mccr_reg, (0 << 16) | ((div - 1) << 17));
+	out_be32(mccr_reg, (1 << 16) | ((div - 1) << 17));
+
+	/*
+	 * create the 'struct clk' items of the MCLK's clock subtree
+	 *
+	 * note that by design we always create all nodes and won't take
+	 * shortcuts here, because
+	 * - the "internal" MCLK_DIV and MCLK_OUT signal in turn are
+	 *   selectable inputs to the CFM while those who "actually use"
+	 *   the PSC/MSCAN/SPDIF (serial drivers et al) need the MCLK
+	 *   for their bitrate
+	 * - in the absence of "aliases" for clocks we need to create
+	 *   individial 'struct clk' items for whatever might get
+	 *   referenced or looked up, even if several of those items are
+	 *   identical from the logical POV (their rate value)
+	 * - for easier future maintenance and for better reflection of
+	 *   the SoC's documentation, it appears appropriate to generate
+	 *   clock items even for those muxers which actually are NOPs
+	 *   (those with two inputs of which one is reserved)
+	 */
+	clks[clks_idx_int + MCLK_IDX_MUX0] = mpc512x_clk_muxed(
+			entry->name_mux0,
+			&parent_names_mux0[0], ARRAY_SIZE(parent_names_mux0),
+			mccr_reg, 14, 2);
+	clks[clks_idx_int + MCLK_IDX_EN0] = mpc512x_clk_gated(
+			entry->name_en0, entry->name_mux0,
+			mccr_reg, 16);
+	clks[clks_idx_int + MCLK_IDX_DIV0] = mpc512x_clk_divider(
+			entry->name_div0,
+			entry->name_en0, CLK_SET_RATE_GATE,
+			mccr_reg, 17, 15, 0);
+	if (entry->has_mclk1) {
+		clks[clks_idx_int + MCLK_IDX_MUX1] = mpc512x_clk_muxed(
+				entry->name_mux1,
+				&entry->parent_names_mux1[0],
+				ARRAY_SIZE(entry->parent_names_mux1),
+				mccr_reg, 7, 1);
+	} else {
+		clks[clks_idx_int + MCLK_IDX_MUX1] = mpc512x_clk_factor(
+				entry->name_mux1, entry->parent_names_mux1[0],
+				1, 1);
+	}
+	if (sccr_reg) {
+		clks[clks_idx_pub] = mpc512x_clk_gated(
+				entry->name_mclk,
+				entry->name_mux1, sccr_reg, sccr_bit);
+	} else {
+		clks[clks_idx_pub] = mpc512x_clk_factor(
+				entry->name_mclk,
+				entry->name_mux1, 1, 1);
+	}
+
+	/*
+	 * without this "clock device" registration, "simple" lookups in
+	 * the SPI master initialization and serial port setup will fail
+	 *
+	 * those drivers need to get adjusted to lookup their required
+	 * clocks from device tree specs, and device tree nodes need to
+	 * provide the clock specs, before this clkdev registration
+	 * becomes obsolete
+	 */
+	clk_register_clkdev(clks[clks_idx_pub], entry->name_mclk, NULL);
+}
+
+static void mpc512x_clk_setup_mclks(struct mclk_setup_data *table, size_t count)
+{
+	while (count-- > 0)
+		mpc512x_clk_setup_mclk(table++);
+}
+
+static void mpc512x_clk_setup_clock_tree(int busfreq)
+{
+	int sys_mul, sys_div, ips_div;
+	int mul, div;
+	int freq;
+
+	/*
+	 * TODO
+	 * - consider whether to handle clocks which have both gates and
+	 *   dividers via intermediates or by means of composites
+	 * - fractional dividers appear to not map well to composites
+	 *   since they can be seen as a fixed multiplier and an
+	 *   adjustable divider, while composites can only combine at
+	 *   most one of a mux, div, and gate each into one 'struct clk'
+	 *   item
+	 * - PSC/MSCAN/SPDIF clock generation OTOH already is very
+	 *   specific and cannot get mapped to componsites (at least not
+	 *   a single one, maybe two of them, but see the comment about
+	 *   "intermediates are referenced from elsewhere, too")
+	 * - trim the list of auto-enabled clocks after drivers acquire
+	 *   them correctly as needed
+	 */
+
+	/* regardless of whether XTAL/OSC exists, have REF created */
+	mpc512x_clk_setup_ref_clock(busfreq, &sys_mul, &sys_div, &ips_div);
+
+	/* now setup the REF -> SYS -> CSB -> IPS hierarchy */
+	clks[MPC512x_CLK_SYS] = mpc512x_clk_factor("sys", "ref",
+						   sys_mul, sys_div);
+	clks[MPC512x_CLK_CSB] = mpc512x_clk_factor("csb", "sys", 1, 2);
+	clks[MPC512x_CLK_IPS] = mpc512x_clk_divtable("ips", "csb",
+						     &clkregs->scfr1, 23, 3,
+						     divtab_2346);
+
+	/* now setup anything below SYS and CSB and IPS */
+	clks[MPC512x_CLK_DDR_UG] = mpc512x_clk_factor("ddr-ug", "sys", 1, 2);
+	clks[MPC512x_CLK_SDHC_x4] = mpc512x_clk_factor("sdhc-x4", "csb", 4, 1);
+	clks[MPC512x_CLK_SDHC_UG] = mpc512x_clk_divider("sdhc-ug", "sdhc-x4", 0,
+							&clkregs->scfr2, 0, 8,
+							CLK_DIVIDER_ONE_BASED);
+	clks[MPC512x_CLK_DIU_x4] = mpc512x_clk_factor("diu-x4", "csb", 4, 1);
+	clks[MPC512x_CLK_DIU_UG] = mpc512x_clk_divider("diu-ug", "diu-x4", 0,
+						       &clkregs->scfr1, 0, 8,
+						       CLK_DIVIDER_ONE_BASED);
+
+	/*
+	 * the "power architecture PLL" was setup from data which was
+	 * sampled from the reset config word, at this point in time the
+	 * configuration can be considered fixed and read only (i.e. no
+	 * longer adjustable, or no longer in need of adjustment), which
+	 * is why we don't register a PLL here but assume fixed factors
+	 */
+	mul = get_cpmf_mult_x2();
+	div = 2;	/* compensate for the fractional factor */
+	clks[MPC512x_CLK_E300] = mpc512x_clk_factor("e300", "csb", mul, div);
+
+	clks[MPC512x_CLK_MBX_BUS_UG] = mpc512x_clk_factor("mbx-bus-ug", "csb",
+							  1, 2);
+	clks[MPC512x_CLK_MBX_UG] = mpc512x_clk_divtable("mbx-ug", "mbx-bus-ug",
+							&clkregs->scfr1, 14, 3,
+							divtab_1234);
+	clks[MPC512x_CLK_MBX_3D_UG] = mpc512x_clk_factor("mbx-3d-ug", "mbx-ug",
+							 1, 1);
+	clks[MPC512x_CLK_PCI_UG] = mpc512x_clk_divtable("pci-ug", "csb",
+							&clkregs->scfr1, 20, 3,
+							divtab_2346);
+	clks[MPC512x_CLK_NFC_UG] = mpc512x_clk_divtable("nfc-ug", "ips",
+							&clkregs->scfr1, 8, 3,
+							divtab_1234);
+	clks[MPC512x_CLK_LPC_UG] = mpc512x_clk_divtable("lpc-ug", "ips",
+							&clkregs->scfr1, 11, 3,
+							divtab_1234);
+
+	clks[MPC512x_CLK_LPC] = mpc512x_clk_gated("lpc", "lpc-ug",
+						  &clkregs->sccr1, 30);
+	clks[MPC512x_CLK_NFC] = mpc512x_clk_gated("nfc", "nfc-ug",
+						  &clkregs->sccr1, 29);
+	clks[MPC512x_CLK_PATA] = mpc512x_clk_gated("pata", "ips",
+						   &clkregs->sccr1, 28);
+	mpc512x_clk_setup_mclks(mclk_psc_data, ARRAY_SIZE(mclk_psc_data));
+	clks[MPC512x_CLK_PSC_FIFO] = mpc512x_clk_gated("psc-fifo", "ips",
+						       &clkregs->sccr1, 15);
+	clks[MPC512x_CLK_SATA] = mpc512x_clk_gated("sata", "ips",
+						   &clkregs->sccr1, 14);
+	clks[MPC512x_CLK_FEC] = mpc512x_clk_gated("fec", "ips",
+						  &clkregs->sccr1, 13);
+	clks[MPC512x_CLK_PCI] = mpc512x_clk_gated("pci", "pci-ug",
+						  &clkregs->sccr1, 11);
+	clks[MPC512x_CLK_DDR] = mpc512x_clk_gated("ddr", "ddr-ug",
+						  &clkregs->sccr1, 10);
+
+	clks[MPC512x_CLK_DIU] = mpc512x_clk_gated("diu", "diu-ug",
+						  &clkregs->sccr2, 31);
+	clks[MPC512x_CLK_AXE] = mpc512x_clk_gated("axe", "csb",
+						  &clkregs->sccr2, 30);
+	clks[MPC512x_CLK_MEM] = mpc512x_clk_gated("mem", "ips",
+						  &clkregs->sccr2, 29);
+	clks[MPC512x_CLK_USB1] = mpc512x_clk_gated("usb1", "csb",
+						   &clkregs->sccr2, 28);
+	clks[MPC512x_CLK_USB2] = mpc512x_clk_gated("usb2", "csb",
+						   &clkregs->sccr2, 27);
+	clks[MPC512x_CLK_I2C] = mpc512x_clk_gated("i2c", "ips",
+						  &clkregs->sccr2, 26);
+	mpc512x_clk_setup_mclks(mclk_mscan_data, ARRAY_SIZE(mclk_mscan_data));
+	clks[MPC512x_CLK_SDHC] = mpc512x_clk_gated("sdhc", "sdhc-ug",
+						   &clkregs->sccr2, 24);
+	mpc512x_clk_setup_mclks(mclk_spdif_data, ARRAY_SIZE(mclk_spdif_data));
+	clks[MPC512x_CLK_MBX_BUS] = mpc512x_clk_gated("mbx-bus", "mbx-bus-ug",
+						      &clkregs->sccr2, 22);
+	clks[MPC512x_CLK_MBX] = mpc512x_clk_gated("mbx", "mbx-ug",
+						  &clkregs->sccr2, 21);
+	clks[MPC512x_CLK_MBX_3D] = mpc512x_clk_gated("mbx-3d", "mbx-3d-ug",
+						     &clkregs->sccr2, 20);
+	clks[MPC512x_CLK_IIM] = mpc512x_clk_gated("iim", "csb",
+						  &clkregs->sccr2, 19);
+	clks[MPC512x_CLK_VIU] = mpc512x_clk_gated("viu", "csb",
+						  &clkregs->sccr2, 18);
+	clks[MPC512x_CLK_SDHC_2] = mpc512x_clk_gated("sdhc-2", "sdhc-ug",
+						     &clkregs->sccr2, 17);
+
+	/*
+	 * externally provided clocks (when implemented in hardware,
+	 * device tree may specify values which otherwise were unknown)
+	 */
+	freq = get_freq_from_dt("psc_mclk_in");
+	if (!freq)
+		freq = 25000000;
+	clks[MPC512x_CLK_PSC_MCLK_IN] = mpc512x_clk_fixed("psc_mclk_in", freq);
+	freq = get_freq_from_dt("spdif_tx_in");
+	clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed("spdif_tx_in", freq);
+	freq = get_freq_from_dt("spdif_rx_in");
+	clks[MPC512x_CLK_SPDIF_TX_IN] = mpc512x_clk_fixed("spdif_rx_in", freq);
+
+	/* fixed frequency for AC97, always 24.567MHz */
+	clks[MPC512x_CLK_AC97] = mpc512x_clk_fixed("ac97", 24567000);
+
+	/* clkdev registration for compatibility reasons */
+	clk_register_clkdev(clks[MPC512x_CLK_REF], "ref_clk", NULL);
+	clk_register_clkdev(clks[MPC512x_CLK_SYS], "sys_clk", NULL);
+	clk_register_clkdev(clks[MPC512x_CLK_VIU], "viu_clk", NULL);
+	clk_register_clkdev(clks[MPC512x_CLK_NFC], "nfc_clk", NULL);
+	clk_register_clkdev(clks[MPC512x_CLK_USB1], "usb1_clk", NULL);
+	clk_register_clkdev(clks[MPC512x_CLK_USB2], "usb2_clk", NULL);
+
+	pr_debug("clock tree setup complete\n");
+	freq = clk_get_rate(clks[MPC512x_CLK_E300]);
+	pr_debug("derived PPC freq [%d]\n", freq);
+	freq = clk_get_rate(clks[MPC512x_CLK_IPS]);
+	pr_debug("derived IPS freq [%d]\n", freq);
+	freq = clk_get_rate(clks[MPC512x_CLK_LPC]);
+	pr_debug("derived LPC freq [%d]\n", freq);
+
+	/* enable some of the clocks here unconditionally because ... */
+	pr_debug("automatically enabling some clocks\n");
+	/* some are essential yet never get claimed by any driver */
+	clk_prepare_enable(clks[MPC512x_CLK_DUMMY]);
+	clk_prepare_enable(clks[MPC512x_CLK_E300]);	/* PowerPC CPU */
+	clk_prepare_enable(clks[MPC512x_CLK_DDR]);	/* DRAM */
+	clk_prepare_enable(clks[MPC512x_CLK_MEM]);	/* SRAM */
+	clk_prepare_enable(clks[MPC512x_CLK_IPS]);	/* SoC periph */
+	clk_prepare_enable(clks[MPC512x_CLK_LPC]);	/* boot media */
+	/* some are required yet no dependencies were declared */
+	clk_prepare_enable(clks[MPC512x_CLK_PSC_FIFO]);
+	/* some are not yet acquired by their respective drivers */
+	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
+	clk_prepare_enable(clks[MPC512x_CLK_FEC]);	/* network, NFS */
+	clk_prepare_enable(clks[MPC512x_CLK_DIU]);	/* display */
+	clk_prepare_enable(clks[MPC512x_CLK_I2C]);
+	/*
+	 * some have their individual clock subtree with separate clock
+	 * items and their individual enable counters, yet share a
+	 * common gate (refer to the same register location) while the
+	 * common clock driver code is not aware of the fact and the
+	 * platform's code doesn't provide specific support either
+	 *
+	 * what might happen is that e.g. enabling two MSCAN clock items
+	 * and disabling one of them will disable the common gate and
+	 * thus break the other MSCAN clock as well
+	 */
+	clk_prepare_enable(clks[MPC512x_CLK_MSCAN0_MCLK]);
+	clk_prepare_enable(clks[MPC512x_CLK_MSCAN1_MCLK]);
+	clk_prepare_enable(clks[MPC512x_CLK_MSCAN2_MCLK]);
+	clk_prepare_enable(clks[MPC512x_CLK_MSCAN3_MCLK]);
+}
+
+/*
+ * registers the set of public clocks (those listed in the dt-bindings/
+ * header file) for OF lookups, keeps the intermediates private to us
+ */
+static void mpc5121_clk_register_of_provider(struct device_node *np)
+{
+	clk_data.clks = clks;
+	clk_data.clk_num = MPC512x_CLK_LAST_PUBLIC + 1;	/* _not_ ARRAY_SIZE() */
+	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
+}
+
+int __init mpc5121_clk_init(void)
+{
+	struct device_node *clk_np;
+	int busfreq;
+
+	/* map the clock control registers */
+	clk_np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-clock");
+	if (!clk_np)
+		return -ENODEV;
+	clkregs = of_iomap(clk_np, 0);
+	WARN_ON(!clkregs);
+
+	/* invalidate all not yet registered clock slots */
+	mpc512x_clk_preset_data();
+
+	/*
+	 * have the device tree scanned for "fixed-clock" nodes (which
+	 * includes the oscillator node if the board's DT provides one)
+	 */
+	of_clk_init(NULL);
+
+	/*
+	 * add a dummy clock for those situations where a clock spec is
+	 * required yet no real clock is involved
+	 */
+	clks[MPC512x_CLK_DUMMY] = mpc512x_clk_fixed("dummy", 0);
+
+	/*
+	 * have all the real nodes in the clock tree populated from REF
+	 * down to all leaves, either starting from the OSC node or from
+	 * a REF root that was created from the IPS bus clock input
+	 */
+	busfreq = get_freq_from_dt("bus-frequency");
+	mpc512x_clk_setup_clock_tree(busfreq);
+
+	/* register as an OF clock provider */
+	mpc5121_clk_register_of_provider(clk_np);
+
+	return 0;
+}
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index c4f7799..7f8fc64 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -497,6 +497,20 @@ static inline const char *of_clk_get_parent_name(struct device_node *np,
  * for improved portability across platforms
  */
 
+#if IS_ENABLED(CONFIG_PPC)
+
+static inline u32 clk_readl(u32 __iomem *reg)
+{
+	return ioread32be(reg);
+}
+
+static inline void clk_writel(u32 val, u32 __iomem *reg)
+{
+	iowrite32be(val, reg);
+}
+
+#else	/* platform dependent I/O accessors */
+
 static inline u32 clk_readl(u32 __iomem *reg)
 {
 	return readl(reg);
@@ -507,5 +521,7 @@ static inline void clk_writel(u32 val, u32 __iomem *reg)
 	writel(val, reg);
 }
 
+#endif	/* platform dependent I/O accessors */
+
 #endif /* CONFIG_COMMON_CLK */
 #endif /* CLK_PROVIDER_H */
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:34 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:34 +0200
Subject: [PATCH v3 07/31] fs_enet: silence a build warning (unused variable)
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-8-git-send-email-gsi@denx.de>


Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 8de53a1..c04eb3a 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -583,7 +583,6 @@ static struct sk_buff *tx_skb_align_workaround(struct net_device *dev,
 					       struct sk_buff *skb)
 {
 	struct sk_buff *new_skb;
-	struct fs_enet_private *fep = netdev_priv(dev);
 
 	/* Alloc new skb */
 	new_skb = netdev_alloc_skb(dev, skb->len + 4);
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:42 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:42 +0200
Subject: [PATCH v3 15/31] dts: mpc512x: introduce dt-bindings/clock/ header
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-16-git-send-email-gsi@denx.de>

introduce a dt-bindings/ header file for MPC512x clocks,
providing symbolic identifiers for those SoC clocks which
clients will reference from their device tree nodes

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 include/dt-bindings/clock/mpc512x-clock.h |   59 +++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)
 create mode 100644 include/dt-bindings/clock/mpc512x-clock.h

diff --git a/include/dt-bindings/clock/mpc512x-clock.h b/include/dt-bindings/clock/mpc512x-clock.h
new file mode 100644
index 0000000..46c560e
--- /dev/null
+++ b/include/dt-bindings/clock/mpc512x-clock.h
@@ -0,0 +1,59 @@
+/*
+ * This header provides constants for MPC512x clock specs in DT bindings.
+ *
+ * Unfortunately the clock number declaration cannot be an enum but
+ * needs to be a list of #define directives since when referenced from
+ * within DTS files they need to get resolved "at compile time".
+ */
+
+#ifndef _DT_BINDINGS_CLOCK_MPC512x_CLOCK_H
+#define _DT_BINDINGS_CLOCK_MPC512x_CLOCK_H
+
+#define MPC512x_CLK_DUMMY		0
+#define MPC512x_CLK_REF			1
+#define MPC512x_CLK_SYS			2
+#define MPC512x_CLK_DIU			3
+#define MPC512x_CLK_VIU			4
+#define MPC512x_CLK_CSB			5
+#define MPC512x_CLK_E300		6
+#define MPC512x_CLK_IPS			7
+#define MPC512x_CLK_FEC			8
+#define MPC512x_CLK_SATA		9
+#define MPC512x_CLK_PATA		10
+#define MPC512x_CLK_NFC			11
+#define MPC512x_CLK_LPC			12
+#define MPC512x_CLK_MBX_BUS		13
+#define MPC512x_CLK_MBX			14
+#define MPC512x_CLK_MBX_3D		15
+#define MPC512x_CLK_AXE			16
+#define MPC512x_CLK_USB1		17
+#define MPC512x_CLK_USB2		18
+#define MPC512x_CLK_I2C			19
+#define MPC512x_CLK_MSCAN0_MCLK		20
+#define MPC512x_CLK_MSCAN1_MCLK		21
+#define MPC512x_CLK_MSCAN2_MCLK		22
+#define MPC512x_CLK_MSCAN3_MCLK		23
+#define MPC512x_CLK_SDHC		24
+#define MPC512x_CLK_PCI			25
+#define MPC512x_CLK_PSC_MCLK_IN		26
+#define MPC512x_CLK_SPDIF_TX		27
+#define MPC512x_CLK_SPDIF_RX		28
+#define MPC512x_CLK_SPDIF_MCLK		29
+#define MPC512x_CLK_AC97		30
+#define MPC512x_CLK_PSC0_MCLK		31
+#define MPC512x_CLK_PSC1_MCLK		32
+#define MPC512x_CLK_PSC2_MCLK		33
+#define MPC512x_CLK_PSC3_MCLK		34
+#define MPC512x_CLK_PSC4_MCLK		35
+#define MPC512x_CLK_PSC5_MCLK		36
+#define MPC512x_CLK_PSC6_MCLK		37
+#define MPC512x_CLK_PSC7_MCLK		38
+#define MPC512x_CLK_PSC8_MCLK		39
+#define MPC512x_CLK_PSC9_MCLK		40
+#define MPC512x_CLK_PSC10_MCLK		41
+#define MPC512x_CLK_PSC11_MCLK		42
+#define MPC512x_CLK_PSC_FIFO		43
+
+#define MPC512x_CLK_LAST_PUBLIC		43
+
+#endif
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:43 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:43 +0200
Subject: [PATCH v3 16/31] dts: mpc512x: add clock related device tree specs
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-17-git-send-email-gsi@denx.de>

this addresses the clock driver aka provider's side of clocks
- prepare for future '<&clks ID>' phandle references for device tree
  based clock lookup in client drivers
- introduce a 'clocks' subtree with an 'osc' node for the crystal
  or oscillator SoC input (fixed frequency)
- provide default values with 33MHz oscillator frequency in the
  common include (the 66MHz IPS bus already was there), add
  override values for the ifm AC14xx board which deviates from
  the reference design (25MHz xtal, 80MHz IPS bus)

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/boot/dts/ac14xx.dts   |    7 +++++++
 arch/powerpc/boot/dts/mpc5121.dtsi |   15 ++++++++++++++-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/ac14xx.dts b/arch/powerpc/boot/dts/ac14xx.dts
index a543c40..a1b8837 100644
--- a/arch/powerpc/boot/dts/ac14xx.dts
+++ b/arch/powerpc/boot/dts/ac14xx.dts
@@ -139,7 +139,14 @@
 		};
 	};
 
+	clocks {
+		osc {
+			clock-frequency = <25000000>;
+		};
+	};
+
 	soc at 80000000 {
+		bus-frequency = <80000000>;	/* 80 MHz ips bus */
 
 		clock at f00 {
 			compatible = "fsl,mpc5121rev2-clock", "fsl,mpc5121-clock";
diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi b/arch/powerpc/boot/dts/mpc5121.dtsi
index bd14c00..8f4cba0 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -9,6 +9,8 @@
  * option) any later version.
  */
 
+#include <dt-bindings/clock/mpc512x-clock.h>
+
 /dts-v1/;
 
 / {
@@ -73,6 +75,16 @@
 		ranges = <0x0 0x0 0xfc000000 0x04000000>;
 	};
 
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		osc {
+			compatible = "fsl,mpc512x-osc", "fixed-clock";
+			clock-frequency = <33000000>;
+		};
+	};
+
 	soc at 80000000 {
 		compatible = "fsl,mpc5121-immr";
 		#address-cells = <1>;
@@ -118,9 +130,10 @@
 		};
 
 		/* Clock control */
-		clock at f00 {
+		clks: clock at f00 {
 			compatible = "fsl,mpc5121-clock";
 			reg = <0xf00 0x100>;
+			#clock-cells = <1>;
 		};
 
 		/* Power Management Controller */
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:49 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:49 +0200
Subject: [PATCH v3 22/31] clk: mpc512x: remove clkdev registration (uart, spi)
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-23-git-send-email-gsi@denx.de>

after the UART and SPI peripheral drivers have switched to device tree
based clock lookup and no longer construct clock names from their PSC
component index, the "psc%d_mclk" alias names have become obsolete --
remove the corresponding clk_register_clkdev() calls

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |   11 -----------
 1 file changed, 11 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index 8b71ceb..a860ded 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -529,17 +529,6 @@ static void mpc512x_clk_setup_mclk(struct mclk_setup_data *entry)
 				entry->name_mclk,
 				entry->name_mux1, 1, 1);
 	}
-
-	/*
-	 * without this "clock device" registration, "simple" lookups in
-	 * the SPI master initialization and serial port setup will fail
-	 *
-	 * those drivers need to get adjusted to lookup their required
-	 * clocks from device tree specs, and device tree nodes need to
-	 * provide the clock specs, before this clkdev registration
-	 * becomes obsolete
-	 */
-	clk_register_clkdev(clks[clks_idx_pub], entry->name_mclk, NULL);
 }
 
 static void mpc512x_clk_setup_mclks(struct mclk_setup_data *table, size_t count)
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:50 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:50 +0200
Subject: [PATCH v3 23/31] serial: mpc512x: setup the PSC FIFO clock as well
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-24-git-send-email-gsi@denx.de>

prepare and enable the FIFO clock upon PSC FIFO initialization,
check for and propagage errors when enabling the PSC FIFO clock,
disable and unprepare the FIFO clock upon PSC FIFO uninitialization,
remove the pre-enable workaround from the platform's clock driver

devm_{get,put}_clk() doesn't apply here, as the SoC provides a
single FIFO component which is shared among several PSC components,
thus the FIFO isn't associated with a device (while the PSCs are)

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |    2 --
 drivers/tty/serial/mpc52xx_uart.c             |   46 +++++++++++++++++++++----
 2 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index a860ded..53f772b 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -698,8 +698,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	clk_prepare_enable(clks[MPC512x_CLK_MEM]);	/* SRAM */
 	clk_prepare_enable(clks[MPC512x_CLK_IPS]);	/* SoC periph */
 	clk_prepare_enable(clks[MPC512x_CLK_LPC]);	/* boot media */
-	/* some are required yet no dependencies were declared */
-	clk_prepare_enable(clks[MPC512x_CLK_PSC_FIFO]);
 	/* some are not yet acquired by their respective drivers */
 	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
 	clk_prepare_enable(clks[MPC512x_CLK_DIU]);	/* display */
diff --git a/drivers/tty/serial/mpc52xx_uart.c b/drivers/tty/serial/mpc52xx_uart.c
index 04dc564..23eef91 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -421,6 +421,7 @@ struct psc_fifoc {
 
 static struct psc_fifoc __iomem *psc_fifoc;
 static unsigned int psc_fifoc_irq;
+static struct clk *psc_fifoc_clk;
 
 static void mpc512x_psc_fifo_init(struct uart_port *port)
 {
@@ -568,36 +569,69 @@ static unsigned int mpc512x_psc_set_baudrate(struct uart_port *port,
 /* Init PSC FIFO Controller */
 static int __init mpc512x_psc_fifoc_init(void)
 {
+	int err;
 	struct device_node *np;
+	struct clk *clk;
+
+	/* default error code, potentially overwritten by clock calls */
+	err = -ENODEV;
 
 	np = of_find_compatible_node(NULL, NULL,
 				     "fsl,mpc5121-psc-fifo");
 	if (!np) {
 		pr_err("%s: Can't find FIFOC node\n", __func__);
-		return -ENODEV;
+		goto out_err;
 	}
 
+	clk = of_clk_get_by_name(np, "per");
+	if (IS_ERR(clk)) {
+		pr_err("%s: Can't lookup FIFO clock\n", __func__);
+		err = PTR_ERR(clk);
+		goto out_ofnode_put;
+	}
+	if (clk_prepare_enable(clk)) {
+		pr_err("%s: Can't enable FIFO clock\n", __func__);
+		clk_put(clk);
+		goto out_ofnode_put;
+	}
+	psc_fifoc_clk = clk;
+
 	psc_fifoc = of_iomap(np, 0);
 	if (!psc_fifoc) {
 		pr_err("%s: Can't map FIFOC\n", __func__);
-		of_node_put(np);
-		return -ENODEV;
+		goto out_clk_disable;
 	}
 
 	psc_fifoc_irq = irq_of_parse_and_map(np, 0);
-	of_node_put(np);
 	if (psc_fifoc_irq == 0) {
 		pr_err("%s: Can't get FIFOC irq\n", __func__);
-		iounmap(psc_fifoc);
-		return -ENODEV;
+		goto out_unmap;
 	}
 
+	of_node_put(np);
 	return 0;
+
+out_unmap:
+	iounmap(psc_fifoc);
+out_clk_disable:
+	clk_disable_unprepare(psc_fifoc_clk);
+	clk_put(psc_fifoc_clk);
+out_ofnode_put:
+	of_node_put(np);
+out_err:
+	return err;
 }
 
 static void __exit mpc512x_psc_fifoc_uninit(void)
 {
 	iounmap(psc_fifoc);
+
+	/* disable the clock, errors are not fatal */
+	if (psc_fifoc_clk) {
+		clk_disable_unprepare(psc_fifoc_clk);
+		clk_put(psc_fifoc_clk);
+		psc_fifoc_clk = NULL;
+	}
 }
 
 /* 512x specific interrupt handler. The caller holds the port lock */
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:51 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:51 +0200
Subject: [PATCH v3 24/31] USB: fsl-mph-dr-of: remove now obsolete clock lookup
 name
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-25-git-send-email-gsi@denx.de>

after device tree based clock lookup became available, the peripheral
driver need no longer construct clock names which include the component
index -- remove the "usb%d_clk" template and unconditionally use "per",
remove the clock driver's clkdev registration

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |    2 --
 drivers/usb/host/fsl-mph-dr-of.c              |   13 +------------
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index 53f772b..d0286a5 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -678,8 +678,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	clk_register_clkdev(clks[MPC512x_CLK_SYS], "sys_clk", NULL);
 	clk_register_clkdev(clks[MPC512x_CLK_VIU], "viu_clk", NULL);
 	clk_register_clkdev(clks[MPC512x_CLK_NFC], "nfc_clk", NULL);
-	clk_register_clkdev(clks[MPC512x_CLK_USB1], "usb1_clk", NULL);
-	clk_register_clkdev(clks[MPC512x_CLK_USB2], "usb2_clk", NULL);
 
 	pr_debug("clock tree setup complete\n");
 	freq = clk_get_rate(clks[MPC512x_CLK_E300]);
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 5e51384..49c1da8 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -261,19 +261,8 @@ int fsl_usb2_mpc5121_init(struct platform_device *pdev)
 	struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
 	struct clk *clk;
 	int err;
-	char clk_name[10];
-	int base, clk_num;
-
-	base = pdev->resource->start & 0xf000;
-	if (base == 0x3000)
-		clk_num = 1;
-	else if (base == 0x4000)
-		clk_num = 2;
-	else
-		return -ENODEV;
 
-	snprintf(clk_name, sizeof(clk_name), "usb%d_clk", clk_num);
-	clk = devm_clk_get(&pdev->dev, clk_name);
+	clk = devm_clk_get(&pdev->dev, "per");
 	if (IS_ERR(clk)) {
 		dev_err(&pdev->dev, "failed to get clk\n");
 		return PTR_ERR(clk);
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:57 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:57 +0200
Subject: [PATCH v3 30/31] net: can: mscan: remove non-common_clock code for
 MPC512x
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-31-git-send-email-gsi@denx.de>

transition to the common clock framework has completed and the PPC_CLOCK
is no longer available for the MPC512x platform, remove the now obsolete
code path of the mpc5xxx mscan driver which accessed clock control
module registers directly

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/net/can/mscan/mpc5xxx_can.c |  141 -----------------------------------
 1 file changed, 141 deletions(-)

diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index 4897929..dd6bdaa 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -109,9 +109,6 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
 #endif /* CONFIG_PPC_MPC52xx */
 
 #ifdef CONFIG_PPC_MPC512x
-
-#if IS_ENABLED(CONFIG_COMMON_CLK)
-
 static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 				 const char *clock_source, int *mscan_clksrc)
 {
@@ -267,144 +264,6 @@ static void mpc512x_can_put_clock(struct platform_device *ofdev)
 		devm_clk_put(&ofdev->dev, priv->clk_can);
 	}
 }
-
-#else	/* COMMON_CLK */
-
-struct mpc512x_clockctl {
-	u32 spmr;		/* System PLL Mode Reg */
-	u32 sccr[2];		/* System Clk Ctrl Reg 1 & 2 */
-	u32 scfr1;		/* System Clk Freq Reg 1 */
-	u32 scfr2;		/* System Clk Freq Reg 2 */
-	u32 reserved;
-	u32 bcr;		/* Bread Crumb Reg */
-	u32 pccr[12];		/* PSC Clk Ctrl Reg 0-11 */
-	u32 spccr;		/* SPDIF Clk Ctrl Reg */
-	u32 cccr;		/* CFM Clk Ctrl Reg */
-	u32 dccr;		/* DIU Clk Cnfg Reg */
-	u32 mccr[4];		/* MSCAN Clk Ctrl Reg 1-3 */
-};
-
-static struct of_device_id mpc512x_clock_ids[] = {
-	{ .compatible = "fsl,mpc5121-clock", },
-	{}
-};
-
-static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
-				 const char *clock_name, int *mscan_clksrc)
-{
-	struct mpc512x_clockctl __iomem *clockctl;
-	struct device_node *np_clock;
-	struct clk *sys_clk, *ref_clk;
-	int plen, clockidx, clocksrc = -1;
-	u32 sys_freq, val, clockdiv = 1, freq = 0;
-	const u32 *pval;
-
-	np_clock = of_find_matching_node(NULL, mpc512x_clock_ids);
-	if (!np_clock) {
-		dev_err(&ofdev->dev, "couldn't find clock node\n");
-		return 0;
-	}
-	clockctl = of_iomap(np_clock, 0);
-	if (!clockctl) {
-		dev_err(&ofdev->dev, "couldn't map clock registers\n");
-		goto exit_put;
-	}
-
-	/* Determine the MSCAN device index from the peripheral's
-	 * physical address. Register address offsets against the
-	 * IMMR base are:  0x1300, 0x1380, 0x2300, 0x2380
-	 */
-	pval = of_get_property(ofdev->dev.of_node, "reg", &plen);
-	BUG_ON(!pval || plen < sizeof(*pval));
-	clockidx = (*pval & 0x80) ? 1 : 0;
-	if (*pval & 0x2000)
-		clockidx += 2;
-
-	/*
-	 * Clock source and divider selection: 3 different clock sources
-	 * can be selected: "ip", "ref" or "sys". For the latter two, a
-	 * clock divider can be defined as well. If the clock source is
-	 * not specified by the device tree, we first try to find an
-	 * optimal CAN source clock based on the system clock. If that
-	 * is not posslible, the reference clock will be used.
-	 */
-	if (clock_name && !strcmp(clock_name, "ip")) {
-		*mscan_clksrc = MSCAN_CLKSRC_IPS;
-		freq = mpc5xxx_get_bus_frequency(ofdev->dev.of_node);
-	} else {
-		*mscan_clksrc = MSCAN_CLKSRC_BUS;
-
-		pval = of_get_property(ofdev->dev.of_node,
-				       "fsl,mscan-clock-divider", &plen);
-		if (pval && plen == sizeof(*pval))
-			clockdiv = *pval;
-		if (!clockdiv)
-			clockdiv = 1;
-
-		if (!clock_name || !strcmp(clock_name, "sys")) {
-			sys_clk = devm_clk_get(&ofdev->dev, "sys_clk");
-			if (IS_ERR(sys_clk)) {
-				dev_err(&ofdev->dev, "couldn't get sys_clk\n");
-				goto exit_unmap;
-			}
-			/* Get and round up/down sys clock rate */
-			sys_freq = 1000000 *
-				((clk_get_rate(sys_clk) + 499999) / 1000000);
-
-			if (!clock_name) {
-				/* A multiple of 16 MHz would be optimal */
-				if ((sys_freq % 16000000) == 0) {
-					clocksrc = 0;
-					clockdiv = sys_freq / 16000000;
-					freq = sys_freq / clockdiv;
-				}
-			} else {
-				clocksrc = 0;
-				freq = sys_freq / clockdiv;
-			}
-		}
-
-		if (clocksrc < 0) {
-			ref_clk = devm_clk_get(&ofdev->dev, "ref_clk");
-			if (IS_ERR(ref_clk)) {
-				dev_err(&ofdev->dev, "couldn't get ref_clk\n");
-				goto exit_unmap;
-			}
-			clocksrc = 1;
-			freq = clk_get_rate(ref_clk) / clockdiv;
-		}
-	}
-
-	/* Disable clock */
-	out_be32(&clockctl->mccr[clockidx], 0x0);
-	if (clocksrc >= 0) {
-		/* Set source and divider */
-		val = (clocksrc << 14) | ((clockdiv - 1) << 17);
-		out_be32(&clockctl->mccr[clockidx], val);
-		/* Enable clock */
-		out_be32(&clockctl->mccr[clockidx], val | 0x10000);
-	}
-
-	/* Enable MSCAN clock domain */
-	val = in_be32(&clockctl->sccr[1]);
-	if (!(val & (1 << 25)))
-		out_be32(&clockctl->sccr[1], val | (1 << 25));
-
-	dev_dbg(&ofdev->dev, "using '%s' with frequency divider %d\n",
-		*mscan_clksrc == MSCAN_CLKSRC_IPS ? "ips_clk" :
-		clocksrc == 1 ? "ref_clk" : "sys_clk", clockdiv);
-
-exit_unmap:
-	iounmap(clockctl);
-exit_put:
-	of_node_put(np_clock);
-	return freq;
-}
-
-#define mpc512x_can_put_clock NULL
-
-#endif	/* COMMON_CLK */
-
 #else /* !CONFIG_PPC_MPC512x */
 static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 				 const char *clock_name, int *mscan_clksrc)
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:58 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:58 +0200
Subject: [PATCH v3 31/31] clk: mpc512x: remove clkdev registration (sys/ref,
 header)
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-32-git-send-email-gsi@denx.de>

remove the last clkdev registration call ("sys_clk" and "ref_clk"
for mscan), as well as the clkdev header inclusion and the "compat
registration" comment

all client lookups for clock items are device tree based now, no
compatibility alias names need to get provided any longer

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |    5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index 893fbe5..e9451a7 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -12,7 +12,6 @@
  */
 
 #include <linux/clk-provider.h>
-#include <linux/clkdev.h>
 #include <linux/device.h>
 #include <linux/errno.h>
 #include <linux/io.h>
@@ -673,10 +672,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	/* fixed frequency for AC97, always 24.567MHz */
 	clks[MPC512x_CLK_AC97] = mpc512x_clk_fixed("ac97", 24567000);
 
-	/* clkdev registration for compatibility reasons */
-	clk_register_clkdev(clks[MPC512x_CLK_REF], "ref_clk", NULL);
-	clk_register_clkdev(clks[MPC512x_CLK_SYS], "sys_clk", NULL);
-
 	pr_debug("clock tree setup complete\n");
 	freq = clk_get_rate(clks[MPC512x_CLK_E300]);
 	pr_debug("derived PPC freq [%d]\n", freq);
-- 
1.7.10.4



From sergei.shtylyov at cogentembedded.com  Mon Jul 22 08:18:15 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 22 Jul 2013 16:18:15 +0400
Subject: [PATCH 04/11] USB: OHCI: Properly handle ohci-da8xx suspend
In-Reply-To: <1374485566-3997-5-git-send-email-manjunath.goudar@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-5-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <51ED2307.1040207@cogentembedded.com>

Hello.

On 22-07-2013 13:32, Manjunath Goudar wrote:

> Suspend scenario in case of ohci-da8xx glue was not
> properly handled as it was not suspending generic part
> of ohci controller. Calling explicitly the ohci_suspend()
> routine in ohci_da8xx_suspend() will ensure proper
> handling of suspend scenario.

> Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
> Acked-by: Alan Stern <stern at rowland.harvard.edu>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Greg KH <greg at kroah.com>
> Cc: linux-usb at vger.kernel.org

> V2:
>   -Incase ohci_suspend() fails, return right away without
>    executing further.

> V3:
>   -Aligned variable "do_wakeup" and "ret".
>   -pdev->dev.power.power_state stuff has been removed.

> V4:
>   -Properly aligned "do_wakeup" and "ret" variable.
> ---
>   drivers/usb/host/ohci-da8xx.c |   15 +++++++++++----
>   1 file changed, 11 insertions(+), 4 deletions(-)

> diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
> index 6aaa9c9..c649a35 100644
> --- a/drivers/usb/host/ohci-da8xx.c
> +++ b/drivers/usb/host/ohci-da8xx.c
> @@ -406,19 +406,26 @@ static int ohci_hcd_da8xx_drv_remove(struct platform_device *dev)
>   }
>
>   #ifdef CONFIG_PM
> -static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t message)
> +static int ohci_da8xx_suspend(struct platform_device *pdev,
> +		pm_message_t message)

    Please start this line under *struct* above. Don't break the coding style 
we used in this file.

WBR, Sergei



From gsi at denx.de  Mon Jul 22 08:14:55 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:55 +0200
Subject: [PATCH v3 28/31] powerpc/mpc512x: improve DIU related clock setup
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-29-git-send-email-gsi@denx.de>

adapt the DIU clock initialization to the COMMON_CLK approach: device
tree based clock lookup, prepare and unprepare for clocks, work with
frequencies not dividers, call the appropriate clk_*() routines and
don't access CCM registers, remove the pre-enable workaround in the
platform's clock driver

the "best clock" determination now completely relies on the platform's
clock driver to pick a frequency close to what the caller requests, and
merely checks whether the desired frequency was met (is acceptable since
it meets the tolerance of the monitor) -- this approach shall succeed
upon first try in the usual case, will test a few less desirable yet
acceptable frequencies in edge cases, and will fallback to "best effort"
if none of the previously tried frequencies pass the test

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |    1 -
 arch/powerpc/platforms/512x/mpc512x_shared.c  |  165 +++++++++++++------------
 2 files changed, 88 insertions(+), 78 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index f047d4c..893fbe5 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -696,7 +696,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	clk_prepare_enable(clks[MPC512x_CLK_LPC]);	/* boot media */
 	/* some are not yet acquired by their respective drivers */
 	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
-	clk_prepare_enable(clks[MPC512x_CLK_DIU]);	/* display */
 	/*
 	 * some have their individual clock subtree with separate clock
 	 * items and their individual enable counters, yet share a
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
index a82a41b..3381eea 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -12,6 +12,7 @@
  * (at your option) any later version.
  */
 
+#include <linux/clk.h>
 #include <linux/kernel.h>
 #include <linux/io.h>
 #include <linux/irq.h>
@@ -70,98 +71,108 @@ struct fsl_diu_shared_fb {
 	bool		in_use;
 };
 
-#define DIU_DIV_MASK	0x000000ff
+/* receives a pixel clock spec in pico seconds, adjusts the DIU clock rate */
 void mpc512x_set_pixel_clock(unsigned int pixclock)
 {
-	unsigned long bestval, bestfreq, speed, busfreq;
-	unsigned long minpixclock, maxpixclock, pixval;
-	struct mpc512x_ccm __iomem *ccm;
 	struct device_node *np;
-	u32 temp;
-	long err;
-	int i;
+	struct clk *clk_diu;
+	unsigned long epsilon, minpixclock, maxpixclock;
+	unsigned long offset, want, got, delta;
 
-	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-clock");
+	/* lookup and enable the DIU clock */
+	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-diu");
 	if (!np) {
-		pr_err("Can't find clock control module.\n");
+		pr_err("Could not find DIU device tree node.\n");
 		return;
 	}
-
-	ccm = of_iomap(np, 0);
+	clk_diu = of_clk_get_by_name(np, "per");
 	of_node_put(np);
-	if (!ccm) {
-		pr_err("Can't map clock control module reg.\n");
+	if (IS_ERR(clk_diu)) {
+		pr_err("Could not lookup DIU clock.\n");
 		return;
 	}
-
-	np = of_find_node_by_type(NULL, "cpu");
-	if (np) {
-		const unsigned int *prop =
-			of_get_property(np, "bus-frequency", NULL);
-
-		of_node_put(np);
-		if (prop) {
-			busfreq = *prop;
-		} else {
-			pr_err("Can't get bus-frequency property\n");
-			return;
-		}
-	} else {
-		pr_err("Can't find 'cpu' node.\n");
+	if (clk_prepare_enable(clk_diu)) {
+		pr_err("Could not enable DIU clock.\n");
 		return;
 	}
 
-	/* Pixel Clock configuration */
-	pr_debug("DIU: Bus Frequency = %lu\n", busfreq);
-	speed = busfreq * 4; /* DIU_DIV ratio is 4 * CSB_CLK / DIU_CLK */
-
-	/* Calculate the pixel clock with the smallest error */
-	/* calculate the following in steps to avoid overflow */
-	pr_debug("DIU pixclock in ps - %d\n", pixclock);
-	temp = (1000000000 / pixclock) * 1000;
-	pixclock = temp;
-	pr_debug("DIU pixclock freq - %u\n", pixclock);
-
-	temp = temp / 20; /* pixclock * 0.05 */
-	pr_debug("deviation = %d\n", temp);
-	minpixclock = pixclock - temp;
-	maxpixclock = pixclock + temp;
-	pr_debug("DIU minpixclock - %lu\n", minpixclock);
-	pr_debug("DIU maxpixclock - %lu\n", maxpixclock);
-	pixval = speed/pixclock;
-	pr_debug("DIU pixval = %lu\n", pixval);
-
-	err = LONG_MAX;
-	bestval = pixval;
-	pr_debug("DIU bestval = %lu\n", bestval);
-
-	bestfreq = 0;
-	for (i = -1; i <= 1; i++) {
-		temp = speed / (pixval+i);
-		pr_debug("DIU test pixval i=%d, pixval=%lu, temp freq. = %u\n",
-			i, pixval, temp);
-		if ((temp < minpixclock) || (temp > maxpixclock))
-			pr_debug("DIU exceeds monitor range (%lu to %lu)\n",
-				minpixclock, maxpixclock);
-		else if (abs(temp - pixclock) < err) {
-			pr_debug("Entered the else if block %d\n", i);
-			err = abs(temp - pixclock);
-			bestval = pixval + i;
-			bestfreq = temp;
-		}
+	/*
+	 * convert the picoseconds spec into the desired clock rate,
+	 * determine the acceptable clock range for the monitor (+/- 5%),
+	 * do the calculation in steps to avoid integer overflow
+	 */
+	pr_debug("DIU pixclock in ps - %u\n", pixclock);
+	pixclock = (1000000000 / pixclock) * 1000;
+	pr_debug("DIU pixclock freq  - %u\n", pixclock);
+	epsilon = pixclock / 20; /* pixclock * 0.05 */
+	pr_debug("DIU deviation      - %lu\n", epsilon);
+	minpixclock = pixclock - epsilon;
+	maxpixclock = pixclock + epsilon;
+	pr_debug("DIU minpixclock    - %lu\n", minpixclock);
+	pr_debug("DIU maxpixclock    - %lu\n", maxpixclock);
+
+	/*
+	 * check whether the DIU supports the desired pixel clock
+	 *
+	 * - simply request the desired clock and see what the
+	 *   platform's clock driver will make of it, assuming that it
+	 *   will setup the best approximation of the requested value
+	 * - try other candidate frequencies in the order of decreasing
+	 *   preference (i.e. with increasing distance from the desired
+	 *   pixel clock, and checking the lower frequency before the
+	 *   higher frequency to not overload the hardware) until the
+	 *   first match is found -- any potential subsequent match
+	 *   would only be as good as the former match or typically
+	 *   would be less preferrable
+	 *
+	 * the offset increment of pixelclock divided by 64 is an
+	 * arbitrary choice -- it's simple to calculate, in the typical
+	 * case we expect the first check to succeed already, in the
+	 * worst case seven frequencies get tested (the exact center and
+	 * three more values each to the left and to the right) before
+	 * the 5% tolerance window is exceeded, resulting in fast enough
+	 * execution yet high enough probability of finding a suitable
+	 * value, while the error rate will be in the order of single
+	 * percents
+	 */
+	for (offset = 0; offset <= epsilon; offset += pixclock / 64) {
+		want = pixclock - offset;
+		pr_debug("DIU checking clock - %lu\n", want);
+		clk_set_rate(clk_diu, want);
+		got = clk_get_rate(clk_diu);
+		delta = abs(pixclock - got);
+		if (delta < epsilon)
+			break;
+		if (!offset)
+			continue;
+		want = pixclock + offset;
+		pr_debug("DIU checking clock - %lu\n", want);
+		clk_set_rate(clk_diu, want);
+		got = clk_get_rate(clk_diu);
+		delta = abs(pixclock - got);
+		if (delta < epsilon)
+			break;
 	}
+	if (offset <= epsilon) {
+		pr_debug("DIU clock accepted - %lu\n", want);
+		pr_debug("DIU pixclock want %u, got %lu, delta %lu, eps %lu\n",
+			 pixclock, got, delta, epsilon);
+		return;
+	}
+	pr_warn("DIU pixclock auto search unsuccessful\n");
 
-	pr_debug("DIU chose = %lx\n", bestval);
-	pr_debug("DIU error = %ld\n NomPixClk ", err);
-	pr_debug("DIU: Best Freq = %lx\n", bestfreq);
-	/* Modify DIU_DIV in CCM SCFR1 */
-	temp = in_be32(&ccm->scfr1);
-	pr_debug("DIU: Current value of SCFR1: 0x%08x\n", temp);
-	temp &= ~DIU_DIV_MASK;
-	temp |= (bestval & DIU_DIV_MASK);
-	out_be32(&ccm->scfr1, temp);
-	pr_debug("DIU: Modified value of SCFR1: 0x%08x\n", temp);
-	iounmap(ccm);
+	/*
+	 * what is the most appropriate action to take when the search
+	 * for an available pixel clock which is acceptable to the
+	 * monitor has failed?  disable the DIU (clock) or just provide
+	 * a "best effort"?  we go with the latter
+	 */
+	pr_warn("DIU pixclock best effort fallback (backend's choice)\n");
+	clk_set_rate(clk_diu, pixclock);
+	got = clk_get_rate(clk_diu);
+	delta = abs(pixclock - got);
+	pr_debug("DIU pixclock want %u, got %lu, delta %lu, eps %lu\n",
+		 pixclock, got, delta, epsilon);
 }
 
 enum fsl_diu_monitor_port
-- 
1.7.10.4



From inki.dae at samsung.com  Mon Jul 22 08:20:23 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Mon, 22 Jul 2013 21:20:23 +0900
Subject: [PATCH 1/3] drm/exynos: add device tree support for rotator
In-Reply-To: <1374475767-30085-2-git-send-email-chanho61.park@samsung.com>
References: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
 <1374475767-30085-2-git-send-email-chanho61.park@samsung.com>
Message-ID: <025f01ce86d5$d7251210$856f3630$%dae@samsung.com>



> -----Original Message-----
> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
> owner at vger.kernel.org] On Behalf Of Chanho Park
> Sent: Monday, July 22, 2013 3:49 PM
> To: inki.dae at samsung.com; kgene.kim at samsung.com
> Cc: jy0922.shim at samsung.com; sw0312.kim at samsung.com;
> kyungmin.park at samsung.com; dri-devel at lists.freedesktop.org; linux-samsung-
> soc at vger.kernel.org; linux-arm-kernel at lists.infradead.org; devicetree-
> discuss at lists.ozlabs.org; Chanho Park
> Subject: [PATCH 1/3] drm/exynos: add device tree support for rotator
> 
> The exynos4 platform is only dt-based since 3.10, we should convert driver
> data
> and ids to dt-based parsing methods. The rotator driver has a limit table
> to get
> size limit. The minimum size of RGB888 format is 8 x 8 and maximum size is
> 8K x
> 8K. The other format, YCbCr420 2-Plane has 32 x 32 min size and 32K x 32K
> max
> size. Each format should be multiple of 'align' value.
> 
> Signed-off-by: Chanho Park <chanho61.park at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c |  110 +++++++++++++++++++---
> -----
>  1 file changed, 80 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> index 427640a..b353a10 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -96,7 +96,7 @@ struct rot_context {
>  	struct resource	*regs_res;
>  	void __iomem	*regs;
>  	struct clk	*clock;
> -	struct rot_limit_table	*limit_tbl;
> +	struct rot_limit_table	limit_tbl;
>  	int	irq;
>  	int	cur_buf_id[EXYNOS_DRM_OPS_MAX];
>  	bool	suspended;
> @@ -167,7 +167,7 @@ static irqreturn_t rotator_irq_handler(int irq, void
> *arg)
>  static void rotator_align_size(struct rot_context *rot, u32 fmt, u32
> *hsize,
>  		u32 *vsize)
>  {
> -	struct rot_limit_table *limit_tbl = rot->limit_tbl;
> +	struct rot_limit_table *limit_tbl = &rot->limit_tbl;
>  	struct rot_limit *limit;
>  	u32 mask, val;
> 
> @@ -632,6 +632,72 @@ static int rotator_ippdrv_start(struct device *dev,
> enum drm_exynos_ipp_cmd cmd)
>  	return 0;
>  }
> 
> +static const struct of_device_id exynos_rotator_match[] = {
> +	{
> +		.compatible = "samsung,exynos4210-rotator",
> +	},
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_rotator_match);

Rotator device cannot be plugged in. Please remove the above
MODULE_DEVICE_TABLE.


> +
> +static int rotator_parse_dt_tbl(struct device_node *np, struct rot_limit
> *rlim)
> +{
> +	int ret;
> +
> +	ret = of_property_read_u32(np, "min_w", &rlim->min_w);
> +	if (ret)
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "min_h", &rlim->min_h);
> +	if (ret)
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "max_w", &rlim->max_w);
> +	if (ret)
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "max_h", &rlim->max_h);
> +	if (ret)
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "align", &rlim->align);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +static int rotator_parse_dt(struct device *dev, struct rot_context *rot)
> +{
> +	struct device_node *ycbcr_node, *rgb888_node;
> +	int ret;
> +
> +	ycbcr_node = of_get_child_by_name(dev->of_node, "ycbcr420_2p");
> +	if (!ycbcr_node) {
> +		dev_err(dev, "can't find ycbcr420_2p node\n");
> +		return -ENODEV;
> +	}
> +
> +	rgb888_node = of_get_child_by_name(dev->of_node, "rgb888");
> +	if (!rgb888_node) {
> +		dev_err(dev, "can't find rgb888 node\n");
> +		return -ENODEV;
> +	}
> +
> +	ret = rotator_parse_dt_tbl(ycbcr_node, &rot->limit_tbl.ycbcr420_2p);
> +	if (ret) {
> +		dev_err(dev, "failed to parse ycbcr420 data\n");
> +		return ret;
> +	}
> +	ret = rotator_parse_dt_tbl(rgb888_node, &rot->limit_tbl.rgb888);
> +	if (ret) {
> +		dev_err(dev, "failed to parse rgb888 data\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
>  static int rotator_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> @@ -639,14 +705,23 @@ static int rotator_probe(struct platform_device
> *pdev)
>  	struct exynos_drm_ippdrv *ippdrv;
>  	int ret;
> 
> +	if (!dev->of_node) {
> +		dev_err(dev, "Cannot find device tree node\n");
> +		return -ENODEV;
> +	}
> +
>  	rot = devm_kzalloc(dev, sizeof(*rot), GFP_KERNEL);
>  	if (!rot) {
>  		dev_err(dev, "failed to allocate rot\n");
>  		return -ENOMEM;
>  	}
> 
> -	rot->limit_tbl = (struct rot_limit_table *)
> -				platform_get_device_id(pdev)->driver_data;
> +	ret = rotator_parse_dt(dev, rot);
> +	if (ret) {
> +		dev_err(dev, "failed parse dt info\n");
> +		devm_kfree(dev, rot);
> +		return ret;
> +	}
> 
>  	rot->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	rot->regs = devm_ioremap_resource(dev, rot->regs_res);
> @@ -718,31 +793,6 @@ static int rotator_remove(struct platform_device
> *pdev)
>  	return 0;
>  }
> 
> -static struct rot_limit_table rot_limit_tbl = {
> -	.ycbcr420_2p = {
> -		.min_w = 32,
> -		.min_h = 32,
> -		.max_w = SZ_32K,
> -		.max_h = SZ_32K,
> -		.align = 3,
> -	},
> -	.rgb888 = {
> -		.min_w = 8,
> -		.min_h = 8,
> -		.max_w = SZ_8K,
> -		.max_h = SZ_8K,
> -		.align = 2,
> -	},
> -};
> -
> -static struct platform_device_id rotator_driver_ids[] = {
> -	{
> -		.name		= "exynos-rot",
> -		.driver_data	= (unsigned long)&rot_limit_tbl,
> -	},
> -	{},
> -};
> -
>  static int rotator_clk_crtl(struct rot_context *rot, bool enable)
>  {
>  	if (enable) {
> @@ -804,10 +854,10 @@ static const struct dev_pm_ops rotator_pm_ops = {
>  struct platform_driver rotator_driver = {
>  	.probe		= rotator_probe,
>  	.remove		= rotator_remove,
> -	.id_table	= rotator_driver_ids,
>  	.driver		= {
>  		.name	= "exynos-rot",
>  		.owner	= THIS_MODULE,
>  		.pm	= &rotator_pm_ops,
> +		.of_match_table = of_match_ptr(exynos_rotator_match),
>  	},
>  };
> --
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From r.sricharan at ti.com  Mon Jul 22 08:20:21 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Mon, 22 Jul 2013 17:50:21 +0530
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <CACRpkdY3nQaWimTwB-Zt-8+Q_KZr8a0rpB1SUQq=AuoG4bAYnQ@mail.gmail.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <51E83A4F.5080904@ti.com>
 <CACRpkdY3nQaWimTwB-Zt-8+Q_KZr8a0rpB1SUQq=AuoG4bAYnQ@mail.gmail.com>
Message-ID: <51ED2385.60108@ti.com>

Hi Linus,
On Sunday 21 July 2013 10:19 PM, Linus Walleij wrote:
> On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon <nm at ti.com> wrote:
>
>> I carry forward my TI internal objection to this approach:
> It is actually a very good sign of FOSS-maturity that you as a company
> take unresolved architectural issues to the community. Kudos!
>
>> Lets see what happens as a result of this:
>>
>> https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
>> uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
>> uart1: serial at 4806a000 {
>> <snip>
>> +                       interrupts = <0 72 0x4>;
>> Assumes that GIC interrupt by default mapping used.
> So introducing this inbetween the GIC lines and its actual device IRQ
> lines inevitably means that the GIC three-cell concept is completely
> ill-devised to handle this.
>
> For routing IRQs, I think the proper solution would be to use a
> cascaded struct irqchip, which in turn contains an irqdomain
> translation to remux the signal onto the GIC inputs.
>
> I.e. the interrupt-controller given to that serial would be the
> crossbar irqchip, and that in turn will hog and allocate apropriate
> lines from the gic to it would probably itself list *all* the IRQs
> of the GIC as "its" IRQs.
>
> We already have plenty of cascading irqchips such as GPIO
> controller providing IRQs, just that they only multiplex on a
> single GIC line instead of the whole lot.
>
> Mock example:
>
>                 intc: interrupt-controller at 0 {
>                         compatible = "arm,cortex-a9-gic";
>                         #interrupt-cells = <3>;
>                         #address-cells = <1>;
>                         interrupt-controller;
>                         reg = ...;
>                 };
>
>                 crossbar: crossbar at 0 {
>                         compatible = "...";
>                         interrupt-controller;
>                         #interrupt-cells = <1>;
>                         interrupt-parent = <&intc>;
>                         interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
>                                           <0 1 IRQ_TYPE_LEVEL_HIGH>,
>                                           <0 2 IRQ_TYPE_LEVEL_HIGH>,
>                                           ....
>                                           <0 n IRQ_TYPE_LEVEL_HIGH>;
>                 };
>
>                 uart0: serial at 0 {
>                         compatible = "...";
>                         interrupt-parent = <&crossbar>;
>                         interrupts = <1234>;
>                  };
>
> Maybe the interrupts provided from crossbar cannot even be
> specified by a number, maybe a line name need to be used
> or so. I don't know the particulars.
>
> Whether this as a whole is a good idea, I don't know,
> but you would have to go about it something like this.
>
> What happens if there is no line to mux in a certain IRQ?
 Thanks for this.
 Was thinking of a similar kind of approach with irqchip.
 But then, there was a GAP since crossbar does not have an irq unlike
 other irqchips. But as you said  this can be done by setting the crossbar
 to map and receive the GIC interrupts and then direct to devices.
 Only thing is, this is fine for IRQs, and something different has to be done
 for DMA crossbars  again. Also when we allocate dynamically here,
 finding out a irq line when there is no free line is a question.

  With the other approach of using/extending  the pinctrl framework that you
 gave, it is good to handle both irqs/dma.  I looked at the other example in
 drivers/dma/amba-pl08x.c and i see that data is getting populated and passed
 from the platform. I initially started with something similar, where the data
 was passed statically from DT and a driver to use that.  So now it looks good
 to extend the pinctrl fw. I will try a approach for that first and see how it looks.

Regards,
 Sricharan




From festevam at gmail.com  Mon Jul 22 08:21:20 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 22 Jul 2013 09:21:20 -0300
Subject: [PATCH 2/2] ARM: dts: mx6: Add support for imx6dl nitrogen board
In-Reply-To: <20130722075736.GC20271@S2101-09.ap.freescale.net>
References: <1374118960-19060-1-git-send-email-festevam@gmail.com>
 <1374118960-19060-2-git-send-email-festevam@gmail.com>
 <20130722075736.GC20271@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5C8Zz27KQOQxnurRmEUqUPw6VZNPGc3g4oXEUZUDxtYVQ@mail.gmail.com>

Hi Shawn,

On Mon, Jul 22, 2013 at 4:57 AM, Shawn Guo <shawn.guo at linaro.org> wrote:

>> +/ {
>> +     model = "Boundary Devices i.MX6 Dual Lite Nitrogen Board";
>> +     compatible = "boundary,imx6dl-nitrogen", "fsl,imx6dl";
>> +
>> +     memory {
>> +             reg = <0x10000000 0x40000000>;
>> +     };
>
> This memory configuration is also common, right?

The reason I put the memory configuration in this file is because we
also have nitrogen quad and dual-lite versions with 2GB.

Regards,

Fabio Estevam


From oleksandr.kozaruk at ti.com  Mon Jul 22 08:22:50 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Mon, 22 Jul 2013 15:22:50 +0300
Subject: [PATCH v7 0/2] TWL6030, TWL6032 GPADC driver
Message-ID: <1374495772-17758-1-git-send-email-oleksandr.kozaruk@ti.com>

Hello,

v7 - addressed clean up comments, removed test channels
v6 - addressed comments about trim bits, checkpatch clean up
v5 - gpadc DT node renamed from "gpadc" to generic "adc", added
     temperature channels; raw code is corracted with calibration
     data.
v4 - addressed comments: fixed style violation, bug in freeing memory,
     added comments explaining calibration method, removed test network
     channels from exposing to userspace, error handling for 
     wait_for_complition
v3 - fixed compiler warning
v2 - the driver put in drivers/iio, and
converted using iio facilities as suggested by Graeme.

TWL603[02] GPADC is used to measure battery voltage,
battery temperature, battery presence ID, and could
be used to measure twl603[02] die temperature.
This is used on TI blaze, blaze tablet platforms.

The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19
channels respectively. Some channels have current
source and are used for measuring voltage drop
on resistive load for detecting battery ID resistance,
or measuring voltage drop on NTC resistors for external
temperature measurements, other channels measure voltage,
(i.e. battery voltage), and have inbuilt voltage dividers,
thus, capable to scale voltage. Some channels are dedicated
for measuring die temperature.

Some channels could be calibrated in 2 points, having
offsets from ideal values in trim registers.

The difference between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i. e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

The driver is derived from git://git.omapzoom.org/kernel/omap.git
The original driver's authors and contributors are Balaji T K,
Graeme Gregory, Ambresh K, Girish S Ghongdemath.

The changes to the original driver:
- device tree adaptation;
- drop ioctl support - never been used;
- unified measurement method for both devices;
- get rid of "if (device == X)" code style to data driven;
- drop polling end of conversion and use interrupt instead;
- iio framework is used

Tested with on blaze tablet 2 with OMAP4430(twl6030), and
OMAP4470(twl6032) SOMs.

The patches were tested against 3.11-rc2

Oleksandr Kozaruk (2):
  ARM: dts: twl: Add GPADC data to device tree
  iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

 arch/arm/boot/dts/twl6030.dtsi  |   6 +
 drivers/iio/adc/Kconfig         |  14 +
 drivers/iio/adc/Makefile        |   1 +
 drivers/iio/adc/twl6030-gpadc.c | 981 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 1002 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

-- 
1.8.1.2



From oleksandr.kozaruk at ti.com  Mon Jul 22 08:22:51 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Mon, 22 Jul 2013 15:22:51 +0300
Subject: [PATCH v7 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <1374495772-17758-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1374495772-17758-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1374495772-17758-2-git-send-email-oleksandr.kozaruk@ti.com>

GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.

Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..b78e1d5 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
 		compatible = "ti,twl6030-pwmled";
 		#pwm-cells = <2>;
 	};
+
+	adc {
+		compatible = "ti,twl6030-gpadc";
+		interrupts = <3>;
+		#io-channel-cells = <1>;
+	};
 };
-- 
1.8.1.2



From oleksandr.kozaruk at ti.com  Mon Jul 22 08:22:52 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Mon, 22 Jul 2013 15:22:52 +0300
Subject: [PATCH v7 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <1374495772-17758-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1374495772-17758-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1374495772-17758-3-git-send-email-oleksandr.kozaruk@ti.com>

The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
known also as Phoenix and PhoenixLite.

The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
respectively. Some channels have current source and are used for
measuring voltage drop on resistive load for detecting battery ID
resistance, or measuring voltage drop on NTC resistors for external
temperature measurements. Some channels measure voltage, (i.e. battery
voltage), and have voltage dividers, thus, capable to scale voltage.
Some channels are dedicated for measuring die temperature.

Some channels are calibrated in 2 points, having offsets from ideal
values kept in trim registers. This is used to correct measurements.

The differences between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i.e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
Girish S Ghongdemath.

Signed-off-by: Balaji T K <balajitk at ti.com>
Signed-off-by: Graeme Gregory <gg at slimlogic.co.uk>
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 drivers/iio/adc/Kconfig         |  14 +
 drivers/iio/adc/Makefile        |   1 +
 drivers/iio/adc/twl6030-gpadc.c | 981 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 996 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 93129ec..f8f9f18 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -160,6 +160,20 @@ config TI_AM335X_ADC
 	  Say yes here to build support for Texas Instruments ADC
 	  driver which is also a MFD client.
 
+config TWL6030_GPADC
+	tristate "TWL6030 GPADC (General Purpose A/D Converter) Support"
+	depends on TWL4030_CORE
+	default n
+	help
+	  Say yes here if you want support for the TWL6030/TWL6032 General
+	  Purpose A/D Converter. This will add support for battery type
+	  detection, battery voltage and temperature measurement, die
+	  temperature measurement, system supply voltage, audio accessory,
+	  USB ID detection.
+
+	  This driver can also be built as a module. If so, the module will be
+	  called twl6030-gpadc.
+
 config VIPERBOARD_ADC
 	tristate "Viperboard ADC support"
 	depends on MFD_VIPERBOARD && USB
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 8f475d3..db430bd 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -17,4 +17,5 @@ obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
 obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
+obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
 obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
new file mode 100644
index 0000000..1b1962e
--- /dev/null
+++ b/drivers/iio/adc/twl6030-gpadc.c
@@ -0,0 +1,981 @@
+/*
+ * TWL6030 GPADC module driver
+ *
+ * Copyright (C) 2009-2013 Texas Instruments Inc.
+ * Nishant Kamat <nskamat at ti.com>
+ * Balaji T K <balajitk at ti.com>
+ * Graeme Gregory <gg at slimlogic.co.uk>
+ * Girish S Ghongdemath <girishsg at ti.com>
+ * Ambresh K <ambresh at ti.com>
+ * Oleksandr Kozaruk <oleksandr.kozaruk at ti.com
+ *
+ * Based on twl4030-madc.c
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen <mikko.k.ylinen at nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of_platform.h>
+#include <linux/i2c/twl.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define DRIVER_NAME		"twl6030_gpadc"
+
+#define TWL6030_GPADC_MAX_CHANNELS		15
+#define TWL6032_GPADC_MAX_CHANNELS		19
+#define TWL6030_GPADC_NUM_TRIM_REGS		16
+
+#define TWL6030_GPADC_CTRL_P1			0x05
+
+#define TWL6032_GPADC_GPSELECT_ISB		0x07
+#define TWL6032_GPADC_CTRL_P1			0x08
+
+#define TWL6032_GPADC_GPCH0_LSB			0x0d
+#define TWL6032_GPADC_GPCH0_MSB			0x0e
+
+#define TWL6030_GPADC_CTRL_P1_SP1		BIT(3)
+
+#define TWL6030_GPADC_GPCH0_LSB			(0x29)
+
+#define TWL6030_GPADC_RT_SW1_EOC_MASK		BIT(5)
+
+#define TWL6030_GPADC_TRIM1			0xCD
+
+#define TWL6030_REG_TOGGLE1			0x90
+#define TWL6030_GPADCS				BIT(1)
+#define TWL6030_GPADCR				BIT(0)
+
+/**
+ * struct twl6030_chnl_calib - channel calibration
+ * @gain:		slope coefficient for ideal curve
+ * @gain_error:		gain error
+ * @offset_error:	offset of the real curve
+ */
+struct twl6030_chnl_calib {
+	s32 gain;
+	s32 gain_error;
+	s32 offset_error;
+};
+
+/**
+ * struct twl6030_ideal_code - GPADC calibration parameters
+ * GPADC is calibrated in two points: close to the beginning and
+ * to the and of the measurable input range
+ *
+ * @code1:	ideal code for the input at the beginning
+ * @code2:	ideal code for at the end of the range
+ * @volt1:	voltage input at the beginning(low voltage)
+ * @volt2:	voltage input at the end(high voltage)
+ */
+struct twl6030_ideal_code {
+	u16 code1;
+	u16 code2;
+	u16 volt1;
+	u16 volt2;
+};
+
+struct twl6030_gpadc_data;
+
+/**
+ * struct twl6030_gpadc_platform_data - platform specific data
+ * @nchannels:		number of GPADC channels
+ * @iio_channels:	iio channels
+ * @twl6030_ideal:	pointer to calibration parameters
+ * @start_conversion:	pointer to ADC start conversion function
+ * @channel_to_reg	pointer to ADC function to convert channel to
+ *			register address for reading conversion result
+ * @calibrate:		pointer to calibration function
+ */
+struct twl6030_gpadc_platform_data {
+	const int nchannels;
+	const struct iio_chan_spec *iio_channels;
+	const struct twl6030_ideal_code *ideal;
+	int (*start_conversion)(int channel);
+	u8 (*channel_to_reg)(int channel);
+	int (*calibrate)(struct twl6030_gpadc_data *gpadc);
+};
+
+/**
+ * struct twl6030_gpadc_data - GPADC data
+ * @dev:		device pointer
+ * @lock:		mutual exclusion lock for the structure
+ * @irq_complete:	completion to signal end of conversion
+ * @twl6030_cal_tbl:	pointer to calibration data for each
+ *			channel with gain error and offset
+ * @pdata:		pointer to device specific data
+ */
+struct twl6030_gpadc_data {
+	struct device	*dev;
+	struct mutex	lock;
+	struct completion	irq_complete;
+	struct twl6030_chnl_calib	*twl6030_cal_tbl;
+	const struct twl6030_gpadc_platform_data *pdata;
+};
+
+/*
+ * channels 11, 12, 13, 15 and 16 have no calibration data
+ * calibration offset is same for channels 1, 3, 4, 5
+ *
+ * The data is taken from GPADC_TRIM registers description.
+ * GPADC_TRIM registers keep difference between the code measured
+ * at volt1 and volt2 input voltages and corresponding code1 and code2
+ */
+static const struct twl6030_ideal_code
+	twl6030_ideal[TWL6030_GPADC_MAX_CHANNELS] = {
+	[0] = { /* ch 0, external, battery type, resistor value */
+		.code1 = 116,
+		.code2 = 745,
+		.volt1 = 141,
+		.volt2 = 910,
+	},
+	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[2] = { /* ch 2, external, audio accessory/general purpose */
+		.code1 = 55,
+		.code2 = 818,
+		.volt1 = 101,
+		.volt2 = 1499,
+	},
+	[3] = { /* ch 3, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[4] = { /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[5] = { /* ch 5, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[6] = { /* ch 6, external, general purpose */
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[7] = { /* ch 7, internal, main battery */
+		.code1 = 614,
+		.code2 = 941,
+		.volt1 = 3001,
+		.volt2 = 4599,
+	},
+	[8] = { /* ch 8, internal, backup battery */
+		.code1 = 82,
+		.code2 = 688,
+		.volt1 = 501,
+		.volt2 = 4203,
+	},
+	[9] = { /* ch 9, internal, external charger input */
+		.code1 = 182,
+		.code2 = 818,
+		.volt1 = 2001,
+		.volt2 = 8996,
+	},
+	[10] = { /* ch 10, internal, VBUS */
+		.code1 = 149,
+		.code2 = 818,
+		.volt1 = 1001,
+		.volt2 = 5497,
+	},
+	[11] = {},	/* ch 11, internal, VBUS charging current */
+	[12] = {},	/* ch 12, internal, Die temperature */
+	[13] = {},	/* ch 13, internal, Die temperature */
+	[14] = { /* ch 14, internal, USB ID line */
+		.code1 = 48,
+		.code2 = 714,
+		.volt1 = 323,
+		.volt2 = 4800,
+	},
+};
+
+static const struct twl6030_ideal_code
+			twl6032_ideal[TWL6032_GPADC_MAX_CHANNELS] = {
+	[0] = { /* ch 0, external, battery type, resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[2] = { /* ch 2, external, audio accessory/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 660,
+		.volt2 = 1500,
+	},
+	[3] = { /* ch 3, external, temperature with external diode/general
+								purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[4] = { /* ch 4, external, temperature measurement/general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[5] = { /* ch 5, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[6] = { /* ch 6, external, general purpose */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[7] = { /* ch7, internal, system supply */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+	[8] = { /* ch8, internal, backup battery */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+	[9] = { /* ch 9, internal, external charger input */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 3960,
+		.volt2 = 9000,
+	},
+	[10] = { /* ch10, internal, VBUS */
+		.code1 = 150,
+		.code2 = 751,
+		.volt1 = 1000,
+		.volt2 = 5000,
+	},
+	[11] = { /* ch 11, internal, VBUS DC-DC output current */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 660,
+		.volt2 = 1500,
+	},
+	[12] = { /* ch 12, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[13] = { /* ch 13, internal, Die temperature */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[14] = { /* ch 14, internal, USB ID line */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2420,
+		.volt2 = 5500,
+	},
+	[15] = {},	/* ch 15, internal, test network */
+	[16] = {},	/* ch 16, internal, test network */
+	[17] = {},	/* ch 17, internal, battery charging current */
+	[18] = { /* ch 18, internal, battery voltage */
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+};
+
+static inline int twl6030_gpadc_write(u8 reg, u8 val)
+{
+	return twl_i2c_write_u8(TWL6030_MODULE_GPADC, val, reg);
+}
+
+static inline int twl6030_gpadc_read(u8 reg, u8 *val)
+{
+
+	return twl_i2c_read(TWL6030_MODULE_GPADC, val, reg, 2);
+}
+
+static int twl6030_gpadc_enable_irq(u8 mask)
+{
+	int ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_LINE_B);
+	if (ret < 0)
+		return ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_STS_B);
+
+	return ret;
+}
+
+static void twl6030_gpadc_disable_irq(u8 mask)
+{
+	twl6030_interrupt_mask(mask, REG_INT_MSK_LINE_B);
+	twl6030_interrupt_mask(mask, REG_INT_MSK_STS_B);
+}
+
+static irqreturn_t twl6030_gpadc_irq_handler(int irq, void *indio_dev)
+{
+	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
+
+	complete(&gpadc->irq_complete);
+
+	return IRQ_HANDLED;
+}
+
+static int twl6030_start_conversion(int channel)
+{
+	return twl6030_gpadc_write(TWL6030_GPADC_CTRL_P1,
+					TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static int twl6032_start_conversion(int channel)
+{
+	int ret;
+
+	ret = twl6030_gpadc_write(TWL6032_GPADC_GPSELECT_ISB, channel);
+	if (ret)
+		return ret;
+
+	return twl6030_gpadc_write(TWL6032_GPADC_CTRL_P1,
+						TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static u8 twl6030_channel_to_reg(int channel)
+{
+	return TWL6030_GPADC_GPCH0_LSB + 2 * channel;
+}
+
+static u8 twl6032_channel_to_reg(int channel)
+{
+	/*
+	 * for any prior chosen channel, when the conversion is ready
+	 * the result is avalable in GPCH0_LSB, GPCH0_MSB.
+	 */
+
+	return TWL6032_GPADC_GPCH0_LSB;
+}
+
+static int twl6030_channel_calibrated(const struct twl6030_gpadc_platform_data
+		*pdata, int channel)
+{
+	/* not calibrated channels have 0 in all structure members */
+	return pdata->ideal[channel].code2;
+}
+
+static int twl6030_gpadc_make_correction(struct twl6030_gpadc_data *gpadc,
+		int channel, int raw_code)
+{
+	int corrected_code;
+
+	corrected_code = ((raw_code * 1000) -
+		gpadc->twl6030_cal_tbl[channel].offset_error) /
+		gpadc->twl6030_cal_tbl[channel].gain_error;
+
+	return corrected_code;
+}
+
+static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
+		int channel, int *res)
+{
+	u8 reg = gpadc->pdata->channel_to_reg(channel);
+	__le16 val;
+	int raw_code;
+	int ret;
+
+	ret = twl6030_gpadc_read(reg, (u8 *)&val);
+	if (ret) {
+		dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
+		return ret;
+	}
+
+	raw_code = le16_to_cpu(val);
+	dev_dbg(gpadc->dev, "GPADC raw code: %d", raw_code);
+
+	if (twl6030_channel_calibrated(gpadc->pdata, channel))
+		*res = twl6030_gpadc_make_correction(gpadc, channel, raw_code);
+	else
+		*res = raw_code;
+
+	return ret;
+}
+
+static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
+		int channel, int *val)
+{
+	int corrected_code;
+	int channel_value;
+	int ret;
+
+	ret = twl6030_gpadc_get_raw(gpadc, channel, &corrected_code);
+	if (ret)
+		return ret;
+
+	channel_value = corrected_code *
+			gpadc->twl6030_cal_tbl[channel].gain;
+
+	/* Shift back into mV range */
+	channel_value /= 1000;
+
+	dev_dbg(gpadc->dev, "GPADC corrected code: %d", corrected_code);
+	dev_dbg(gpadc->dev, "GPADC value: %d", channel_value);
+
+	*val = channel_value;
+
+	return ret;
+}
+
+static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
+			     const struct iio_chan_spec *chan,
+			     int *val, int *val2, long mask)
+{
+	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
+	int ret;
+	long timeout;
+
+	mutex_lock(&gpadc->lock);
+
+	ret = gpadc->pdata->start_conversion(chan->channel);
+	if (ret) {
+		dev_err(gpadc->dev, "failed to start conversion\n");
+		goto err;
+	}
+	/* wait for conversion to complete */
+	timeout = wait_for_completion_interruptible_timeout(
+				&gpadc->irq_complete, msecs_to_jiffies(5000));
+	if (timeout == 0) {
+		ret = -ETIMEDOUT;
+		goto err;
+	} else if (timeout < 0) {
+		goto err;
+		ret = -EINTR;
+	}
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	case IIO_CHAN_INFO_PROCESSED:
+		ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	default:
+		break;
+	}
+err:
+	mutex_unlock(&gpadc->lock);
+
+	return ret;
+}
+
+/*
+ * The GPADC channels are calibrated using a two point calibration method.
+ * The channels measured with two known values: volt1 and volt2, and
+ * ideal corresponding output codes are known: code1, code2.
+ * The difference(d1, d2) between ideal and measured codes stored in trim
+ * registers.
+ * The goal is to find offset and gain of the real curve for each calibrated
+ * channel.
+ * gain: k = 1 + ((d2 - d1) / (x2 - x1))
+ * offset: b = d1 + (k - 1) * x1
+ */
+static void twl6030_calibrate_channel(struct twl6030_gpadc_data *gpadc,
+					int channel, int d1, int d2)
+{
+	int b, k, gain, x1, x2;
+	const struct twl6030_ideal_code *ideal = gpadc->pdata->ideal;
+
+	/* Gain */
+	gain = ((ideal[channel].volt2 - ideal[channel].volt1) * 1000) /
+		(ideal[channel].code2 - ideal[channel].code1);
+
+	x1 = ideal[channel].code1;
+	x2 = ideal[channel].code2;
+
+	/* k - real curve gain */
+	k = 1000 + (((d2 - d1) * 1000) / (x2 - x1));
+
+	/* b - offset of the real curve gain */
+	b = (d1 * 1000) - (k - 1000) * x1;
+
+	gpadc->twl6030_cal_tbl[channel].gain = gain;
+	gpadc->twl6030_cal_tbl[channel].gain_error = k;
+	gpadc->twl6030_cal_tbl[channel].offset_error = b;
+
+	dev_dbg(gpadc->dev, "GPADC d1   for Chn: %d = %d\n", channel, d1);
+	dev_dbg(gpadc->dev, "GPADC d2   for Chn: %d = %d\n", channel, d2);
+	dev_dbg(gpadc->dev, "GPADC x1   for Chn: %d = %d\n", channel, x1);
+	dev_dbg(gpadc->dev, "GPADC x2   for Chn: %d = %d\n", channel, x2);
+	dev_dbg(gpadc->dev, "GPADC Gain for Chn: %d = %d\n", channel, gain);
+	dev_dbg(gpadc->dev, "GPADC k    for Chn: %d = %d\n", channel, k);
+	dev_dbg(gpadc->dev, "GPADC b    for Chn: %d = %d\n", channel, b);
+}
+
+static inline int twl6030_gpadc_get_trim_offset(s8 d)
+{
+	/*
+	 * XXX NOTE!
+	 * bit 0 - sign, bit 7 - reserved, 6..1 - trim value
+	 * though, the documentation states that trim value
+	 * is absolute value, the correct conversion results are
+	 * obtained if the value is interpreted as 2's complement.
+	 */
+	__u32 temp = ((d & 0x7f) >> 1) | ((d & 1) << 6);
+
+	return sign_extend32(temp, 6);
+}
+
+static int twl6030_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int ret;
+	int chn;
+	u8 trim_regs[TWL6030_GPADC_NUM_TRIM_REGS];
+	s8 d1, d2;
+
+	/*
+	 * for calibration two measurements have been performed at
+	 * factory, for some channels, during the production test and
+	 * have been stored in registers. This two stored values are
+	 * used to correct the measurements. The values represent
+	 * offsets for the given input from the output on ideal curve.
+	 */
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs,
+			TWL6030_GPADC_TRIM1, TWL6030_GPADC_NUM_TRIM_REGS);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	for (chn = 0; chn < TWL6030_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+			d1 = trim_regs[0];
+			d2 = trim_regs[1];
+			break;
+		case 1:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+			d1 = trim_regs[4];
+			d2 = trim_regs[5];
+			break;
+		case 2:
+			d1 = trim_regs[12];
+			d2 = trim_regs[13];
+			break;
+		case 7:
+			d1 = trim_regs[6];
+			d2 = trim_regs[7];
+			break;
+		case 8:
+			d1 = trim_regs[2];
+			d2 = trim_regs[3];
+			break;
+		case 9:
+			d1 = trim_regs[8];
+			d2 = trim_regs[9];
+			break;
+		case 10:
+			d1 = trim_regs[10];
+			d2 = trim_regs[11];
+			break;
+		case 14:
+			d1 = trim_regs[14];
+			d2 = trim_regs[15];
+			break;
+		default:
+			continue;
+		}
+
+		d1 = twl6030_gpadc_get_trim_offset(d1);
+		d2 = twl6030_gpadc_get_trim_offset(d2);
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+static int twl6032_get_trim_value(u8 *trim_regs, unsigned int reg0,
+		unsigned int reg1, unsigned int mask0, unsigned int mask1,
+		unsigned int shift0)
+{
+	int val;
+
+	val = (trim_regs[reg0] & mask0) << shift0;
+	val |= (trim_regs[reg1] & mask1) >> 1;
+	if (trim_regs[reg1] & 0x01)
+		val = -val;
+
+	return val;
+}
+
+static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int chn, d1 = 0, d2 = 0, temp;
+	u8 trim_regs[TWL6030_GPADC_NUM_TRIM_REGS];
+	int ret;
+
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs,
+			TWL6030_GPADC_TRIM1, TWL6030_GPADC_NUM_TRIM_REGS);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	/*
+	 * Loop to calculate the value needed for returning voltages from
+	 * GPADC not values.
+	 *
+	 * gain is calculated to 3 decimal places fixed point.
+	 */
+	for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+		case 1:
+		case 2:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+		case 11:
+		case 12:
+		case 13:
+		case 14:
+			d1 = twl6032_get_trim_value(trim_regs, 2, 0, 0x1f,
+								0x06, 2);
+			d2 = twl6032_get_trim_value(trim_regs, 3, 1, 0x3f,
+								0x06, 2);
+			break;
+		case 8:
+			temp = twl6032_get_trim_value(trim_regs, 2, 0, 0x1f,
+								0x06, 2);
+			d1 = temp + twl6032_get_trim_value(trim_regs, 7, 6,
+								0x18, 0x1E, 1);
+
+			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x3F,
+								0x06, 2);
+			d2 = temp + twl6032_get_trim_value(trim_regs, 9, 7,
+								0x1F, 0x06, 2);
+			break;
+		case 9:
+			temp = twl6032_get_trim_value(trim_regs, 2, 0, 0x1f,
+								0x06, 2);
+			d1 = temp + twl6032_get_trim_value(trim_regs, 13, 11,
+								0x18, 0x1E, 1);
+
+			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x3f,
+								0x06, 2);
+			d2 = temp + twl6032_get_trim_value(trim_regs, 15, 13,
+								0x1F, 0x06, 1);
+			break;
+		case 10:
+			d1 = twl6032_get_trim_value(trim_regs, 10, 8, 0x0f,
+								0x0E, 3);
+			d2 = twl6032_get_trim_value(trim_regs, 14, 12, 0x0f,
+								0x0E, 3);
+			break;
+		case 7:
+		case 18:
+			temp = twl6032_get_trim_value(trim_regs, 2, 0, 0x1f,
+								0x06, 2);
+
+			d1 = (trim_regs[4] & 0x7E) >> 1;
+			if (trim_regs[4] & 0x01)
+				d1 = -d1;
+			d1 += temp;
+
+			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x3f,
+								0x06, 2);
+
+			d2 = (trim_regs[5] & 0xFE) >> 1;
+			if (trim_regs[5] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		default:
+			/* No data for other channels */
+			continue;
+		}
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+#define TWL6030_GPADC_CHAN(chn, _type, chan_info) {	\
+	.type = _type,					\
+	.channel = chn,					\
+	.info_mask_separate = BIT(chan_info),		\
+	.indexed = 1,					\
+}
+
+static const struct iio_chan_spec twl6030_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(2, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(5, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(12, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(13, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(14, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+};
+
+static const struct iio_chan_spec twl6032_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(2, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(5, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(12, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(13, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(14, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	{}, /* test network, unused */
+	{}, /* test network, unused */
+	TWL6030_GPADC_CHAN(17, IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(18, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+};
+
+static const struct iio_info twl6030_gpadc_iio_info = {
+	.read_raw = &twl6030_gpadc_read_raw,
+	.driver_module = THIS_MODULE,
+};
+
+static const struct twl6030_gpadc_platform_data twl6030_pdata = {
+	.iio_channels = twl6030_gpadc_iio_channels,
+	.nchannels = TWL6030_GPADC_MAX_CHANNELS,
+	.ideal = twl6030_ideal,
+	.start_conversion = twl6030_start_conversion,
+	.channel_to_reg = twl6030_channel_to_reg,
+	.calibrate = twl6030_calibration,
+};
+
+static const struct twl6030_gpadc_platform_data twl6032_pdata = {
+	.iio_channels = twl6032_gpadc_iio_channels,
+	.nchannels = TWL6032_GPADC_MAX_CHANNELS,
+	.ideal = twl6032_ideal,
+	.start_conversion = twl6032_start_conversion,
+	.channel_to_reg = twl6032_channel_to_reg,
+	.calibrate = twl6032_calibration,
+};
+
+static const struct of_device_id of_twl6030_match_tbl[] = {
+	{
+		.compatible = "ti,twl6030-gpadc",
+		.data = &twl6030_pdata,
+	},
+	{
+		.compatible = "ti,twl6032-gpadc",
+		.data = &twl6032_pdata,
+	},
+	{ /* end */ }
+};
+
+static int twl6030_gpadc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct twl6030_gpadc_data *gpadc;
+	const struct twl6030_gpadc_platform_data *pdata;
+	const struct of_device_id *match;
+	struct iio_dev *indio_dev;
+	int irq;
+	int ret;
+
+	match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
+	if (!match)
+		return -EINVAL;
+
+	pdata = match->data;
+
+	indio_dev = iio_device_alloc(sizeof(*gpadc));
+	if (!indio_dev) {
+		dev_err(dev, "failed allocating iio device\n");
+		ret = -ENOMEM;
+	}
+
+	gpadc = iio_priv(indio_dev);
+
+	gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
+					sizeof(*gpadc->twl6030_cal_tbl) *
+					pdata->nchannels, GFP_KERNEL);
+	if (!gpadc->twl6030_cal_tbl)
+		goto err_free_device;
+
+	gpadc->dev = dev;
+	gpadc->pdata = pdata;
+
+	platform_set_drvdata(pdev, indio_dev);
+	mutex_init(&gpadc->lock);
+	init_completion(&gpadc->irq_complete);
+
+	ret = pdata->calibrate(gpadc);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to read calibration registers\n");
+		goto err_free_device;
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "failed to get irq\n");
+		goto err_free_device;
+	}
+
+	ret = request_threaded_irq(irq, NULL, twl6030_gpadc_irq_handler,
+				IRQF_ONESHOT, "twl6030_gpadc", indio_dev);
+	if (ret) {
+		dev_dbg(&pdev->dev, "could not request irq\n");
+		goto err_free_device;
+	}
+
+	ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
+		goto err_free_irq;
+	}
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+					TWL6030_REG_TOGGLE1);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC module\n");
+		goto err_free_irq;
+	}
+
+	indio_dev->name = DRIVER_NAME;
+	indio_dev->dev.parent = dev;
+	indio_dev->info = &twl6030_gpadc_iio_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->channels = pdata->iio_channels;
+	indio_dev->num_channels = pdata->nchannels;
+
+	ret = iio_device_register(indio_dev);
+	if (ret)
+		goto err_free_irq;
+
+	return ret;
+
+err_free_irq:
+	free_irq(irq, indio_dev);
+err_free_device:
+	iio_device_free(indio_dev);
+
+	return ret;
+}
+
+static int twl6030_gpadc_remove(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+
+	twl6030_gpadc_disable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	free_irq(platform_get_irq(pdev, 0), indio_dev);
+	iio_device_unregister(indio_dev);
+	iio_device_free(indio_dev);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int twl6030_gpadc_suspend(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCR,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error reseting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+
+static int twl6030_gpadc_resume(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error setting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+#endif
+
+static SIMPLE_DEV_PM_OPS(twl6030_gpadc_pm_ops, twl6030_gpadc_suspend,
+					twl6030_gpadc_resume);
+
+static struct platform_driver twl6030_gpadc_driver = {
+	.probe		= twl6030_gpadc_probe,
+	.remove		= twl6030_gpadc_remove,
+	.driver		= {
+		.name	= DRIVER_NAME,
+		.owner	= THIS_MODULE,
+		.pm	= &twl6030_gpadc_pm_ops,
+		.of_match_table = of_twl6030_match_tbl,
+	},
+};
+
+module_platform_driver(twl6030_gpadc_driver);
+
+MODULE_ALIAS("platform: " DRIVER_NAME);
+MODULE_AUTHOR("Balaji T K <balajitk at ti.com>, Graeme Gregory <gg at slimlogic.co.uk>, Oleksandr Kozaruk <oleksandr.kozaruk at ti.com");
+MODULE_DESCRIPTION("twl6030 ADC driver");
+MODULE_LICENSE("GPL");
-- 
1.8.1.2



From mkl at pengutronix.de  Mon Jul 22 08:28:36 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Mon, 22 Jul 2013 14:28:36 +0200
Subject: [PATCH v3 08/31] fs_enet: cleanup clock API use
In-Reply-To: <1374495298-22019-9-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
 <1374495298-22019-9-git-send-email-gsi@denx.de>
Message-ID: <51ED2574.9020105@pengutronix.de>

On 07/22/2013 02:14 PM, Gerhard Sittig wrote:
> make the Freescale ethernet driver get, prepare and enable the FEC clock
> during probe(); disable, unprepare and put the clock upon remove(); hold
> a reference to the clock over the period of use; use devm_{get,put}_clk()

There's no need for devm_clk_put(), devm will take care of this.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130722/3ac63ea1/attachment.sig>

From mkl at pengutronix.de  Mon Jul 22 08:31:21 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Mon, 22 Jul 2013 14:31:21 +0200
Subject: [PATCH v3 11/31] net: can: mscan: improve clock API use
In-Reply-To: <1374495298-22019-12-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
 <1374495298-22019-12-git-send-email-gsi@denx.de>
Message-ID: <51ED2619.5040107@pengutronix.de>

On 07/22/2013 02:14 PM, Gerhard Sittig wrote:
> the .get_clock() callback is run from probe() and might allocate
> resources, introduce a .put_clock() callback that is run from remove()
> to undo any allocation activities

looks good

> use devm_get_clk() upon lookup (for SYS and REF) to have the clocks put
> upon driver unload

fine

> assume that resources get prepared but not necessarily enabled in the
> setup phase, make the open() and close() callbacks of the CAN network
> device enable and disable a previously acquired and prepared clock

I think you should call prepare_enable and disable_unprepare in the
open/close functions.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130722/2eeb3687/attachment.sig>

From gsi at denx.de  Mon Jul 22 08:33:24 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:33:24 +0200
Subject: [PATCH v3 00/31] add COMMON_CLK support for PowerPC MPC512x
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <20130722123324.GE19071@book.gsilab.sittig.org>

[ manually added devicetree at vger now ]

On Mon, Jul 22, 2013 at 14:14 +0200, Gerhard Sittig wrote:
> 
> this series
> - fixes several drivers that are used in the MPC512x platform (UART,
>   SPI, ethernet, PCI, USB, CAN, NAND flash, video capture) in how they
>   handle clocks (appropriately acquire and setup them, hold references
>   during use, release clocks after use)
> - introduces support for the common clock framework (CCF, COMMON_CLK
>   Kconfig option) in the PowerPC based MPC512x platform, which brings
>   device tree based clock lookup as well

Haven't noticed before that the ozlabs device tree list started
actively rejecting reception.  And the scope of the series has
widened to include clock related fixes in many more drivers while
the initial submission only introduced CCF for MPC512x.

Shall I resend (with vger devicetree included and more subsystems
lists added)?  Which other lists to include without spamming too
many channels?  Poor moderators have to ACK messages for lists
that I'm not subscribed to.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


From mpfj-list at newflow.co.uk  Mon Jul 22 08:34:14 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Mon, 22 Jul 2013 13:34:14 +0100
Subject: [PATCH 01/22] ARM: ux500: Remove '0x's from HREF v60+ DTS file
In-Reply-To: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
Message-ID: <51ED26C6.6000004@newflow.co.uk>

On 22/07/13 11:52, Lee Jones wrote:
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  arch/arm/boot/dts/hrefv60plus.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/hrefv60plus.dts b/arch/arm/boot/dts/hrefv60plus.dts
> index 3d580d6..46fd8af 100644
> --- a/arch/arm/boot/dts/hrefv60plus.dts
> +++ b/arch/arm/boot/dts/hrefv60plus.dts
> @@ -26,7 +26,7 @@
>  
>  	soc {
>  		i2c at 80110000 {
> -			bu21013_tp at 0x5c {
> +			bu21013_tp at 5c {

Just a query ... why this one .... ^^^ ...

>  				reset-gpio = <&gpio4 15 0x4>;

... and not this one .................................. ^^^ ?

>  			};
>  		};
> 

The same for all the other patches in this series.

If this is by design, it might be worth mentioning why some are
removed and not others.

Mark J.


From inki.dae at samsung.com  Mon Jul 22 08:37:00 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Mon, 22 Jul 2013 21:37:00 +0900
Subject: [PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
In-Reply-To: <20130722084817.GA18731@e106331-lin.cambridge.arm.com>
References: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
 <1374475767-30085-3-git-send-email-chanho61.park@samsung.com>
 <20130722084817.GA18731@e106331-lin.cambridge.arm.com>
Message-ID: <026001ce86d8$2963d730$7c2b8590$%dae@samsung.com>



> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: Monday, July 22, 2013 5:48 PM
> To: Chanho Park
> Cc: inki.dae at samsung.com; kgene.kim at samsung.com; linux-samsung-
> soc at vger.kernel.org; jy0922.shim at samsung.com; devicetree-
> discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> devel at lists.freedesktop.org; kyungmin.park at samsung.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
> rotator
> 
> On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> > This patch adds a dt-binding document for exynos rotator. It describes
> which
> > nodes should be defined to use the rotator.
> >
> > Signed-off-by: Chanho Park <chanho61.park at samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> > ---
> >  .../bindings/drm/exynos/samsung-rotator.txt        |   35
> ++++++++++++++++++++
> >  1 file changed, 35 insertions(+)
> >  create mode 100644
> Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> >
> > diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-
> rotator.txt b/Documentation/devicetree/bindings/drm/exynos/samsung-
> rotator.txt
> > new file mode 100644
> > index 0000000..6b1d704
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> > @@ -0,0 +1,35 @@
> > +* Samsung Image Rotator
> > +
> > +Required properties:
> > +  - compatible : value should be the "samsung,exynos4210".

Please, add more compatible strings for other SoC.

> > +  - reg : Physical base address of the IP registers and length of
> memory
> > +	  mapped region.
> > +  - interrupts : interrupt number to the CPU.
> > +  - clocks : clock number of exynos4 rotator clock.
> > +  - clocks : clock name of rotator
> 
> clock-names?
> 
> > +  - status : "okay" or "disabled"
> > +  - limit table for image formats : min_w/min_h/max_w/max_h for min/max
> of image
> 
> Limit table? This doesn't seem to be a well-defined binding, and it
> seems like a relatively generic thing to describe.
> 
> > +
> > +Example:
> > +	rotator: rotator at 12810000 {
> > +		compatible = "samsung,exynos4210-rotator";
> > +		reg = <0x12810000 0x1000>;
> > +		interrupts = <0 83 0>;
> > +		clocks = <&clock 278>;
> > +		clock-names = "rotator";
> > +		status = "disabled";
> > +		ycbcr420_2p {
> 
> Which names are allowed for these subnodes?
> 
> > +			min_w = <32>;
> > +			min_h = <32>;
> > +			max_w = <32768>;
> > +			max_h = <32768>;
> > +			align = <3>;
> 
> min-width, min-height, max-width, max-height? What units are they in?
> 
> What does alignment specify exactly?
> 
> Are these a configurable part of the rotator hardware, or are these
> values always the same?

Right, that seems like configurable part. At least, min_w/h and max_w/h can
be different values according to SoC and pixel formats so they should be
described enough in this dt-binding document file.

Thanks,
Inki Dae

> If thery're always the same, there's no need to
> describe in in the devicetree.
> 
> Thanks,
> Mark.
> 
> > +		};
> > +		rgb888 {
> > +			min_w = <8>;
> > +			min_h = <8>;
> > +			max_w = <8192>;
> > +			max_h = <8192>;
> > +			align = <2>;
> > +		};
> > +	};
> > --
> > 1.7.9.5
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >



From gsi at denx.de  Mon Jul 22 08:14:56 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:56 +0200
Subject: [PATCH v3 29/31] clk: mpc512x: switch to COMMON_CLK, remove PPC_CLOCK
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-30-git-send-email-gsi@denx.de>

completely switch to, i.e. unconditionally use COMMON_CLK for the
MPC512x platform, and retire the PPC_CLOCK implementation for that
platform after the transition has completed

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/Kconfig  |   14 +-
 arch/powerpc/platforms/512x/Makefile |    3 +-
 arch/powerpc/platforms/512x/clock.c  |  753 ----------------------------------
 3 files changed, 2 insertions(+), 768 deletions(-)
 delete mode 100644 arch/powerpc/platforms/512x/clock.c

diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig
index c5fcdd0..5aa3f4b 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -1,21 +1,9 @@
-config MPC512x_COMMON_CLK
-	bool "MPC512x platform uses COMMON_CLK"
-	default y
-	depends on PPC_MPC512x
-	help
-	  This option is only here to support tests and comparison
-	  during development and migration.  This option will get
-	  removed after the COMMON_CLK support for MPC512x has become
-	  fully operational and all drivers were adjusted to explicitly
-	  acquire their required clocks.
-
 config PPC_MPC512x
 	bool "512x-based boards"
 	depends on 6xx
+	select COMMON_CLK
 	select FSL_SOC
 	select IPIC
-	select PPC_CLOCK if !MPC512x_COMMON_CLK
-	select COMMON_CLK if MPC512x_COMMON_CLK
 	select PPC_PCI_CHOICE
 	select FSL_PCI if PCI
 	select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/powerpc/platforms/512x/Makefile b/arch/powerpc/platforms/512x/Makefile
index 1e05f9d..bb20116 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -1,8 +1,7 @@
 #
 # Makefile for the Freescale PowerPC 512x linux kernel.
 #
-obj-$(CONFIG_PPC_CLOCK)		+= clock.o
-obj-$(CONFIG_COMMON_CLK)	+= clock-commonclk.o
+obj-y				+= clock-commonclk.o
 obj-y				+= mpc512x_shared.o
 obj-$(CONFIG_MPC5121_ADS)	+= mpc5121_ads.o mpc5121_ads_cpld.o
 obj-$(CONFIG_MPC512x_GENERIC)	+= mpc512x_generic.o
diff --git a/arch/powerpc/platforms/512x/clock.c b/arch/powerpc/platforms/512x/clock.c
deleted file mode 100644
index e504166..0000000
--- a/arch/powerpc/platforms/512x/clock.c
+++ /dev/null
@@ -1,753 +0,0 @@
-/*
- * Copyright (C) 2007,2008 Freescale Semiconductor, Inc. All rights reserved.
- *
- * Author: John Rigby <jrigby at freescale.com>
- *
- * Implements the clk api defined in include/linux/clk.h
- *
- *    Original based on linux/arch/arm/mach-integrator/clock.c
- *
- *    Copyright (C) 2004 ARM Limited.
- *    Written by Deep Blue Solutions Limited.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <linux/kernel.h>
-#include <linux/list.h>
-#include <linux/errno.h>
-#include <linux/err.h>
-#include <linux/module.h>
-#include <linux/string.h>
-#include <linux/clk.h>
-#include <linux/mutex.h>
-#include <linux/io.h>
-
-#include <linux/of_platform.h>
-#include <asm/mpc5xxx.h>
-#include <asm/mpc5121.h>
-#include <asm/clk_interface.h>
-
-#include "mpc512x.h"
-
-#undef CLK_DEBUG
-
-static int clocks_initialized;
-
-#define CLK_HAS_RATE	0x1	/* has rate in MHz */
-#define CLK_HAS_CTRL	0x2	/* has control reg and bit */
-
-struct clk {
-	struct list_head node;
-	char name[32];
-	int flags;
-	struct device *dev;
-	unsigned long rate;
-	struct module *owner;
-	void (*calc) (struct clk *);
-	struct clk *parent;
-	int reg, bit;		/* CLK_HAS_CTRL */
-	int div_shift;		/* only used by generic_div_clk_calc */
-};
-
-static LIST_HEAD(clocks);
-static DEFINE_MUTEX(clocks_mutex);
-
-static struct clk *mpc5121_clk_get(struct device *dev, const char *id)
-{
-	struct clk *p, *clk = ERR_PTR(-ENOENT);
-	int dev_match;
-	int id_match;
-
-	if (dev == NULL || id == NULL)
-		return clk;
-
-	mutex_lock(&clocks_mutex);
-	list_for_each_entry(p, &clocks, node) {
-		dev_match = id_match = 0;
-
-		if (dev == p->dev)
-			dev_match++;
-		if (strcmp(id, p->name) == 0)
-			id_match++;
-		if ((dev_match || id_match) && try_module_get(p->owner)) {
-			clk = p;
-			break;
-		}
-	}
-	mutex_unlock(&clocks_mutex);
-
-	return clk;
-}
-
-#ifdef CLK_DEBUG
-static void dump_clocks(void)
-{
-	struct clk *p;
-
-	mutex_lock(&clocks_mutex);
-	printk(KERN_INFO "CLOCKS:\n");
-	list_for_each_entry(p, &clocks, node) {
-		pr_info("  %s=%ld", p->name, p->rate);
-		if (p->parent)
-			pr_cont(" %s=%ld", p->parent->name,
-			       p->parent->rate);
-		if (p->flags & CLK_HAS_CTRL)
-			pr_cont(" reg/bit=%d/%d", p->reg, p->bit);
-		pr_cont("\n");
-	}
-	mutex_unlock(&clocks_mutex);
-}
-#define	DEBUG_CLK_DUMP() dump_clocks()
-#else
-#define	DEBUG_CLK_DUMP()
-#endif
-
-
-static void mpc5121_clk_put(struct clk *clk)
-{
-	module_put(clk->owner);
-}
-
-#define NRPSC 12
-
-struct mpc512x_clockctl {
-	u32 spmr;		/* System PLL Mode Reg */
-	u32 sccr[2];		/* System Clk Ctrl Reg 1 & 2 */
-	u32 scfr1;		/* System Clk Freq Reg 1 */
-	u32 scfr2;		/* System Clk Freq Reg 2 */
-	u32 reserved;
-	u32 bcr;		/* Bread Crumb Reg */
-	u32 pccr[NRPSC];	/* PSC Clk Ctrl Reg 0-11 */
-	u32 spccr;		/* SPDIF Clk Ctrl Reg */
-	u32 cccr;		/* CFM Clk Ctrl Reg */
-	u32 dccr;		/* DIU Clk Cnfg Reg */
-};
-
-static struct mpc512x_clockctl __iomem *clockctl;
-
-static int mpc5121_clk_enable(struct clk *clk)
-{
-	unsigned int mask;
-
-	if (clk->flags & CLK_HAS_CTRL) {
-		mask = in_be32(&clockctl->sccr[clk->reg]);
-		mask |= 1 << clk->bit;
-		out_be32(&clockctl->sccr[clk->reg], mask);
-	}
-	return 0;
-}
-
-static void mpc5121_clk_disable(struct clk *clk)
-{
-	unsigned int mask;
-
-	if (clk->flags & CLK_HAS_CTRL) {
-		mask = in_be32(&clockctl->sccr[clk->reg]);
-		mask &= ~(1 << clk->bit);
-		out_be32(&clockctl->sccr[clk->reg], mask);
-	}
-}
-
-static unsigned long mpc5121_clk_get_rate(struct clk *clk)
-{
-	if (clk->flags & CLK_HAS_RATE)
-		return clk->rate;
-	else
-		return 0;
-}
-
-static long mpc5121_clk_round_rate(struct clk *clk, unsigned long rate)
-{
-	return rate;
-}
-
-static int mpc5121_clk_set_rate(struct clk *clk, unsigned long rate)
-{
-	return 0;
-}
-
-static int clk_register(struct clk *clk)
-{
-	mutex_lock(&clocks_mutex);
-	list_add(&clk->node, &clocks);
-	mutex_unlock(&clocks_mutex);
-	return 0;
-}
-
-static unsigned long spmf_mult(void)
-{
-	/*
-	 * Convert spmf to multiplier
-	 */
-	static int spmf_to_mult[] = {
-		68, 1, 12, 16,
-		20, 24, 28, 32,
-		36, 40, 44, 48,
-		52, 56, 60, 64
-	};
-	int spmf = (in_be32(&clockctl->spmr) >> 24) & 0xf;
-	return spmf_to_mult[spmf];
-}
-
-static unsigned long sysdiv_div_x_2(void)
-{
-	/*
-	 * Convert sysdiv to divisor x 2
-	 * Some divisors have fractional parts so
-	 * multiply by 2 then divide by this value
-	 */
-	static int sysdiv_to_div_x_2[] = {
-		4, 5, 6, 7,
-		8, 9, 10, 14,
-		12, 16, 18, 22,
-		20, 24, 26, 30,
-		28, 32, 34, 38,
-		36, 40, 42, 46,
-		44, 48, 50, 54,
-		52, 56, 58, 62,
-		60, 64, 66,
-	};
-	int sysdiv = (in_be32(&clockctl->scfr2) >> 26) & 0x3f;
-	return sysdiv_to_div_x_2[sysdiv];
-}
-
-static unsigned long ref_to_sys(unsigned long rate)
-{
-	rate *= spmf_mult();
-	rate *= 2;
-	rate /= sysdiv_div_x_2();
-
-	return rate;
-}
-
-static unsigned long sys_to_ref(unsigned long rate)
-{
-	rate *= sysdiv_div_x_2();
-	rate /= 2;
-	rate /= spmf_mult();
-
-	return rate;
-}
-
-static long ips_to_ref(unsigned long rate)
-{
-	int ips_div = (in_be32(&clockctl->scfr1) >> 23) & 0x7;
-
-	rate *= ips_div;	/* csb_clk = ips_clk * ips_div */
-	rate *= 2;		/* sys_clk = csb_clk * 2 */
-	return sys_to_ref(rate);
-}
-
-static unsigned long devtree_getfreq(char *clockname)
-{
-	struct device_node *np;
-	const unsigned int *prop;
-	unsigned int val = 0;
-
-	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-immr");
-	if (np) {
-		prop = of_get_property(np, clockname, NULL);
-		if (prop)
-			val = *prop;
-	    of_node_put(np);
-	}
-	return val;
-}
-
-static void ref_clk_calc(struct clk *clk)
-{
-	unsigned long rate;
-
-	rate = devtree_getfreq("bus-frequency");
-	if (rate == 0) {
-		printk(KERN_ERR "No bus-frequency in dev tree\n");
-		clk->rate = 0;
-		return;
-	}
-	clk->rate = ips_to_ref(rate);
-}
-
-static struct clk ref_clk = {
-	.name = "ref_clk",
-	.calc = ref_clk_calc,
-};
-
-
-static void sys_clk_calc(struct clk *clk)
-{
-	clk->rate = ref_to_sys(ref_clk.rate);
-}
-
-static struct clk sys_clk = {
-	.name = "sys_clk",
-	.calc = sys_clk_calc,
-};
-
-static void diu_clk_calc(struct clk *clk)
-{
-	int diudiv_x_2 = in_be32(&clockctl->scfr1) & 0xff;
-	unsigned long rate;
-
-	rate = sys_clk.rate;
-
-	rate *= 2;
-	rate /= diudiv_x_2;
-
-	clk->rate = rate;
-}
-
-static void viu_clk_calc(struct clk *clk)
-{
-	unsigned long rate;
-
-	rate = sys_clk.rate;
-	rate /= 2;
-	clk->rate = rate;
-}
-
-static void half_clk_calc(struct clk *clk)
-{
-	clk->rate = clk->parent->rate / 2;
-}
-
-static void generic_div_clk_calc(struct clk *clk)
-{
-	int div = (in_be32(&clockctl->scfr1) >> clk->div_shift) & 0x7;
-
-	clk->rate = clk->parent->rate / div;
-}
-
-static void unity_clk_calc(struct clk *clk)
-{
-	clk->rate = clk->parent->rate;
-}
-
-static struct clk csb_clk = {
-	.name = "csb_clk",
-	.calc = half_clk_calc,
-	.parent = &sys_clk,
-};
-
-static void e300_clk_calc(struct clk *clk)
-{
-	int spmf = (in_be32(&clockctl->spmr) >> 16) & 0xf;
-	int ratex2 = clk->parent->rate * spmf;
-
-	clk->rate = ratex2 / 2;
-}
-
-static struct clk e300_clk = {
-	.name = "e300_clk",
-	.calc = e300_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk ips_clk = {
-	.name = "ips_clk",
-	.calc = generic_div_clk_calc,
-	.parent = &csb_clk,
-	.div_shift = 23,
-};
-
-/*
- * Clocks controlled by SCCR1 (.reg = 0)
- */
-static struct clk lpc_clk = {
-	.name = "lpc_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 30,
-	.calc = generic_div_clk_calc,
-	.parent = &ips_clk,
-	.div_shift = 11,
-};
-
-static struct clk nfc_clk = {
-	.name = "nfc_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 29,
-	.calc = generic_div_clk_calc,
-	.parent = &ips_clk,
-	.div_shift = 8,
-};
-
-static struct clk pata_clk = {
-	.name = "pata_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 28,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-/*
- * PSC clocks (bits 27 - 16)
- * are setup elsewhere
- */
-
-static struct clk sata_clk = {
-	.name = "sata_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 14,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk fec_clk = {
-	.name = "fec_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 13,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk pci_clk = {
-	.name = "pci_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 0,
-	.bit = 11,
-	.calc = generic_div_clk_calc,
-	.parent = &csb_clk,
-	.div_shift = 20,
-};
-
-/*
- * Clocks controlled by SCCR2 (.reg = 1)
- */
-static struct clk diu_clk = {
-	.name = "diu_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 31,
-	.calc = diu_clk_calc,
-};
-
-static struct clk viu_clk = {
-	.name = "viu_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 18,
-	.calc = viu_clk_calc,
-};
-
-static struct clk axe_clk = {
-	.name = "axe_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 30,
-	.calc = unity_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk usb1_clk = {
-	.name = "usb1_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 28,
-	.calc = unity_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk usb2_clk = {
-	.name = "usb2_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 27,
-	.calc = unity_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk i2c_clk = {
-	.name = "i2c_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 26,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk mscan_clk = {
-	.name = "mscan_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 25,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk sdhc_clk = {
-	.name = "sdhc_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 24,
-	.calc = unity_clk_calc,
-	.parent = &ips_clk,
-};
-
-static struct clk mbx_bus_clk = {
-	.name = "mbx_bus_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 22,
-	.calc = half_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk mbx_clk = {
-	.name = "mbx_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 21,
-	.calc = unity_clk_calc,
-	.parent = &csb_clk,
-};
-
-static struct clk mbx_3d_clk = {
-	.name = "mbx_3d_clk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 20,
-	.calc = generic_div_clk_calc,
-	.parent = &mbx_bus_clk,
-	.div_shift = 14,
-};
-
-static void psc_mclk_in_calc(struct clk *clk)
-{
-	clk->rate = devtree_getfreq("psc_mclk_in");
-	if (!clk->rate)
-		clk->rate = 25000000;
-}
-
-static struct clk psc_mclk_in = {
-	.name = "psc_mclk_in",
-	.calc = psc_mclk_in_calc,
-};
-
-static struct clk spdif_txclk = {
-	.name = "spdif_txclk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 23,
-};
-
-static struct clk spdif_rxclk = {
-	.name = "spdif_rxclk",
-	.flags = CLK_HAS_CTRL,
-	.reg = 1,
-	.bit = 23,
-};
-
-static void ac97_clk_calc(struct clk *clk)
-{
-	/* ac97 bit clock is always 24.567 MHz */
-	clk->rate = 24567000;
-}
-
-static struct clk ac97_clk = {
-	.name = "ac97_clk_in",
-	.calc = ac97_clk_calc,
-};
-
-static struct clk *rate_clks[] = {
-	&ref_clk,
-	&sys_clk,
-	&diu_clk,
-	&viu_clk,
-	&csb_clk,
-	&e300_clk,
-	&ips_clk,
-	&fec_clk,
-	&sata_clk,
-	&pata_clk,
-	&nfc_clk,
-	&lpc_clk,
-	&mbx_bus_clk,
-	&mbx_clk,
-	&mbx_3d_clk,
-	&axe_clk,
-	&usb1_clk,
-	&usb2_clk,
-	&i2c_clk,
-	&mscan_clk,
-	&sdhc_clk,
-	&pci_clk,
-	&psc_mclk_in,
-	&spdif_txclk,
-	&spdif_rxclk,
-	&ac97_clk,
-	NULL
-};
-
-static void rate_clk_init(struct clk *clk)
-{
-	if (clk->calc) {
-		clk->calc(clk);
-		clk->flags |= CLK_HAS_RATE;
-		clk_register(clk);
-	} else {
-		printk(KERN_WARNING
-		       "Could not initialize clk %s without a calc routine\n",
-		       clk->name);
-	}
-}
-
-static void rate_clks_init(void)
-{
-	struct clk **cpp, *clk;
-
-	cpp = rate_clks;
-	while ((clk = *cpp++))
-		rate_clk_init(clk);
-}
-
-/*
- * There are two clk enable registers with 32 enable bits each
- * psc clocks and device clocks are all stored in dev_clks
- */
-static struct clk dev_clks[2][32];
-
-/*
- * Given a psc number return the dev_clk
- * associated with it
- */
-static struct clk *psc_dev_clk(int pscnum)
-{
-	int reg, bit;
-	struct clk *clk;
-
-	reg = 0;
-	bit = 27 - pscnum;
-
-	clk = &dev_clks[reg][bit];
-	clk->reg = 0;
-	clk->bit = bit;
-	return clk;
-}
-
-/*
- * PSC clock rate calculation
- */
-static void psc_calc_rate(struct clk *clk, int pscnum, struct device_node *np)
-{
-	unsigned long mclk_src = sys_clk.rate;
-	unsigned long mclk_div;
-
-	/*
-	 * Can only change value of mclk divider
-	 * when the divider is disabled.
-	 *
-	 * Zero is not a valid divider so minimum
-	 * divider is 1
-	 *
-	 * disable/set divider/enable
-	 */
-	out_be32(&clockctl->pccr[pscnum], 0);
-	out_be32(&clockctl->pccr[pscnum], 0x00020000);
-	out_be32(&clockctl->pccr[pscnum], 0x00030000);
-
-	if (in_be32(&clockctl->pccr[pscnum]) & 0x80) {
-		clk->rate = spdif_rxclk.rate;
-		return;
-	}
-
-	switch ((in_be32(&clockctl->pccr[pscnum]) >> 14) & 0x3) {
-	case 0:
-		mclk_src = sys_clk.rate;
-		break;
-	case 1:
-		mclk_src = ref_clk.rate;
-		break;
-	case 2:
-		mclk_src = psc_mclk_in.rate;
-		break;
-	case 3:
-		mclk_src = spdif_txclk.rate;
-		break;
-	}
-
-	mclk_div = ((in_be32(&clockctl->pccr[pscnum]) >> 17) & 0x7fff) + 1;
-	clk->rate = mclk_src / mclk_div;
-}
-
-/*
- * Find all psc nodes in device tree and assign a clock
- * with name "psc%d_mclk" and dev pointing at the device
- * returned from of_find_device_by_node
- */
-static void psc_clks_init(void)
-{
-	struct device_node *np;
-	struct platform_device *ofdev;
-	u32 reg;
-	const char *psc_compat;
-
-	psc_compat = mpc512x_select_psc_compat();
-	if (!psc_compat)
-		return;
-
-	for_each_compatible_node(np, NULL, psc_compat) {
-		if (!of_property_read_u32(np, "reg", &reg)) {
-			int pscnum = (reg & 0xf00) >> 8;
-			struct clk *clk = psc_dev_clk(pscnum);
-
-			clk->flags = CLK_HAS_RATE | CLK_HAS_CTRL;
-			ofdev = of_find_device_by_node(np);
-			clk->dev = &ofdev->dev;
-			/*
-			 * AC97 is special rate clock does
-			 * not go through normal path
-			 */
-			if (of_device_is_compatible(np, "fsl,mpc5121-psc-ac97"))
-				clk->rate = ac97_clk.rate;
-			else
-				psc_calc_rate(clk, pscnum, np);
-			sprintf(clk->name, "psc%d_mclk", pscnum);
-			clk_register(clk);
-			clk_enable(clk);
-		}
-	}
-}
-
-static struct clk_interface mpc5121_clk_functions = {
-	.clk_get		= mpc5121_clk_get,
-	.clk_enable		= mpc5121_clk_enable,
-	.clk_disable		= mpc5121_clk_disable,
-	.clk_get_rate		= mpc5121_clk_get_rate,
-	.clk_put		= mpc5121_clk_put,
-	.clk_round_rate		= mpc5121_clk_round_rate,
-	.clk_set_rate		= mpc5121_clk_set_rate,
-	.clk_set_parent		= NULL,
-	.clk_get_parent		= NULL,
-};
-
-int __init mpc5121_clk_init(void)
-{
-	struct device_node *np;
-
-	np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-clock");
-	if (np) {
-		clockctl = of_iomap(np, 0);
-		of_node_put(np);
-	}
-
-	if (!clockctl) {
-		printk(KERN_ERR "Could not map clock control registers\n");
-		return 0;
-	}
-
-	rate_clks_init();
-	psc_clks_init();
-
-	/* leave clockctl mapped forever */
-	/*iounmap(clockctl); */
-	DEBUG_CLK_DUMP();
-	clocks_initialized++;
-	clk_functions = mpc5121_clk_functions;
-	return 0;
-}
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:54 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:54 +0200
Subject: [PATCH v3 27/31] net: can: mscan: add common clock support for mpc512x
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-28-git-send-email-gsi@denx.de>

implement a .get_clock() callback for the MPC512x platform which uses
the common clock infrastructure (eliminating direct access to the clock
control registers from within the CAN network driver), and provide the
corresponding .put_clock() callback to release resources after use

keep the previous implementation of MPC512x support in place during
migration, since common clock support is optional

this change is neutral to the MPC5200 platform

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 drivers/net/can/mscan/mpc5xxx_can.c |  169 +++++++++++++++++++++++++++++++++++
 1 file changed, 169 insertions(+)

diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index e59b3a3..4897929 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -109,6 +109,167 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
 #endif /* CONFIG_PPC_MPC52xx */
 
 #ifdef CONFIG_PPC_MPC512x
+
+#if IS_ENABLED(CONFIG_COMMON_CLK)
+
+static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
+				 const char *clock_source, int *mscan_clksrc)
+{
+	struct device_node *np;
+	u32 clockdiv;
+	enum {
+		CLK_FROM_AUTO,
+		CLK_FROM_IPS,
+		CLK_FROM_SYS,
+		CLK_FROM_REF,
+	} clk_from;
+	struct clk *clk_in, *clk_can;
+	unsigned long freq_calc;
+	struct mscan_priv *priv;
+
+	/* the caller passed in the clock source spec that was read from
+	 * the device tree, get the optional clock divider as well
+	 */
+	np = ofdev->dev.of_node;
+	clockdiv = 1;
+	of_property_read_u32(np, "fsl,mscan-clock-divider", &clockdiv);
+	dev_dbg(&ofdev->dev, "device tree specs: clk src[%s] div[%d]\n",
+		clock_source ? clock_source : "<NULL>", clockdiv);
+
+	/* when clock-source is 'ip', the CANCTL1[CLKSRC] bit needs to
+	 * get set, and the 'ips' clock is the input to the MSCAN
+	 * component
+	 *
+	 * for clock-source values of 'ref' or 'sys' the CANCTL1[CLKSRC]
+	 * bit needs to get cleared, an optional clock-divider may have
+	 * been specified (the default value is 1), the appropriate
+	 * MSCAN related MCLK is the input to the MSCAN component
+	 *
+	 * in the absence of a clock-source spec, first an optimal clock
+	 * gets determined based on the 'sys' clock, if that fails the
+	 * 'ref' clock is used
+	 */
+	clk_from = CLK_FROM_AUTO;
+	if (clock_source) {
+		/* interpret the device tree's spec for the clock source */
+		if (!strcmp(clock_source, "ip"))
+			clk_from = CLK_FROM_IPS;
+		else if (!strcmp(clock_source, "sys"))
+			clk_from = CLK_FROM_SYS;
+		else if (!strcmp(clock_source, "ref"))
+			clk_from = CLK_FROM_REF;
+		else
+			goto err_invalid;
+		dev_dbg(&ofdev->dev, "got a clk source spec[%d]\n", clk_from);
+	}
+	if (clk_from == CLK_FROM_AUTO) {
+		/* no spec so far, try the 'sys' clock; round to the
+		 * next MHz and see if we can get a multiple of 16MHz
+		 */
+		dev_dbg(&ofdev->dev, "no clk source spec, trying SYS\n");
+		clk_in = devm_clk_get(&ofdev->dev, "sys");
+		if (IS_ERR(clk_in))
+			goto err_notavail;
+		freq_calc = clk_get_rate(clk_in);
+		freq_calc +=  499999;
+		freq_calc /= 1000000;
+		freq_calc *= 1000000;
+		if ((freq_calc % 16000000) == 0) {
+			clk_from = CLK_FROM_SYS;
+			clockdiv = freq_calc / 16000000;
+			dev_dbg(&ofdev->dev,
+				"clk fit, sys[%lu] div[%d] freq[%lu]\n",
+				freq_calc, clockdiv, freq_calc / clockdiv);
+		}
+	}
+	if (clk_from == CLK_FROM_AUTO) {
+		/* no spec so far, use the 'ref' clock */
+		dev_dbg(&ofdev->dev, "no clk source spec, trying REF\n");
+		clk_in = devm_clk_get(&ofdev->dev, "ref");
+		if (IS_ERR(clk_in))
+			goto err_notavail;
+		clk_from = CLK_FROM_REF;
+		freq_calc = clk_get_rate(clk_in);
+		dev_dbg(&ofdev->dev,
+			"clk fit, ref[%lu] (no div) freq[%lu]\n",
+			freq_calc, freq_calc);
+	}
+
+	/* select IPS or MCLK as the MSCAN input (returned to the caller),
+	 * setup the MCLK mux source and rate if applicable, apply the
+	 * optionally specified or derived above divider, and determine
+	 * the actual resulting clock rate to return to the caller
+	 */
+	switch (clk_from) {
+	case CLK_FROM_IPS:
+		clk_can = devm_clk_get(&ofdev->dev, "ips");
+		if (IS_ERR(clk_can))
+			goto err_notavail;
+		if (clk_prepare(clk_can)) {
+			devm_clk_put(&ofdev->dev, clk_can);
+			goto err_notavail;
+		}
+		priv = netdev_priv(dev_get_drvdata(&ofdev->dev));
+		priv->clk_can = clk_can;
+		freq_calc = clk_get_rate(clk_can);
+		*mscan_clksrc = MSCAN_CLKSRC_IPS;
+		dev_dbg(&ofdev->dev, "clk from IPS, clksrc[%d] freq[%lu]\n",
+			*mscan_clksrc, freq_calc);
+		break;
+	case CLK_FROM_SYS:
+	case CLK_FROM_REF:
+		clk_can = devm_clk_get(&ofdev->dev, "mclk");
+		if (IS_ERR(clk_can))
+			goto err_notavail;
+		if (clk_prepare(clk_can)) {
+			devm_clk_put(&ofdev->dev, clk_can);
+			goto err_notavail;
+		}
+		priv = netdev_priv(dev_get_drvdata(&ofdev->dev));
+		priv->clk_can = clk_can;
+		if (clk_from == CLK_FROM_SYS)
+			clk_in = devm_clk_get(&ofdev->dev, "sys");
+		if (clk_from == CLK_FROM_REF)
+			clk_in = devm_clk_get(&ofdev->dev, "ref");
+		if (IS_ERR(clk_in))
+			goto err_notavail;
+		clk_set_parent(clk_can, clk_in);
+		freq_calc = clk_get_rate(clk_in);
+		freq_calc /= clockdiv;
+		clk_set_rate(clk_can, freq_calc);
+		freq_calc = clk_get_rate(clk_can);
+		*mscan_clksrc = MSCAN_CLKSRC_BUS;
+		dev_dbg(&ofdev->dev, "clk from MCLK, clksrc[%d] freq[%lu]\n",
+			*mscan_clksrc, freq_calc);
+		break;
+	default:
+		goto err_invalid;
+	}
+
+	return freq_calc;
+
+err_invalid:
+	dev_err(&ofdev->dev, "invalid clock source specification\n");
+	return 0;
+
+err_notavail:
+	dev_err(&ofdev->dev, "cannot acquire or setup clock source\n");
+	return 0;
+}
+
+static void mpc512x_can_put_clock(struct platform_device *ofdev)
+{
+	struct mscan_priv *priv;
+
+	priv = netdev_priv(dev_get_drvdata(&ofdev->dev));
+	if (priv->clk_can) {
+		clk_unprepare(priv->clk_can);
+		devm_clk_put(&ofdev->dev, priv->clk_can);
+	}
+}
+
+#else	/* COMMON_CLK */
+
 struct mpc512x_clockctl {
 	u32 spmr;		/* System PLL Mode Reg */
 	u32 sccr[2];		/* System Clk Ctrl Reg 1 & 2 */
@@ -239,12 +400,18 @@ exit_put:
 	of_node_put(np_clock);
 	return freq;
 }
+
+#define mpc512x_can_put_clock NULL
+
+#endif	/* COMMON_CLK */
+
 #else /* !CONFIG_PPC_MPC512x */
 static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 				 const char *clock_name, int *mscan_clksrc)
 {
 	return 0;
 }
+#define mpc512x_can_put_clock NULL
 #endif /* CONFIG_PPC_MPC512x */
 
 static const struct of_device_id mpc5xxx_can_table[];
@@ -386,11 +553,13 @@ static int mpc5xxx_can_resume(struct platform_device *ofdev)
 static const struct mpc5xxx_can_data mpc5200_can_data = {
 	.type = MSCAN_TYPE_MPC5200,
 	.get_clock = mpc52xx_can_get_clock,
+	/* .put_clock not applicable */
 };
 
 static const struct mpc5xxx_can_data mpc5121_can_data = {
 	.type = MSCAN_TYPE_MPC5121,
 	.get_clock = mpc512x_can_get_clock,
+	.put_clock = mpc512x_can_put_clock,
 };
 
 static const struct of_device_id mpc5xxx_can_table[] = {
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:53 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:53 +0200
Subject: [PATCH v3 26/31] [media] fsl-viu: remove now obsolete clock lookup
 name
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-27-git-send-email-gsi@denx.de>

after device tree based clock lookup became available, the VIU driver
need no longer use the previous "viu_clk" name but can switch to the
fixed "per" clock name -- adjust the peripheral driver and remove the
clock driver's clkdev registration

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |    1 -
 drivers/media/platform/fsl-viu.c              |    2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index 24e1706..f047d4c 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -676,7 +676,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	/* clkdev registration for compatibility reasons */
 	clk_register_clkdev(clks[MPC512x_CLK_REF], "ref_clk", NULL);
 	clk_register_clkdev(clks[MPC512x_CLK_SYS], "sys_clk", NULL);
-	clk_register_clkdev(clks[MPC512x_CLK_VIU], "viu_clk", NULL);
 
 	pr_debug("clock tree setup complete\n");
 	freq = clk_get_rate(clks[MPC512x_CLK_E300]);
diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index 48fced4..8a17433 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -1578,7 +1578,7 @@ static int viu_of_probe(struct platform_device *op)
 	}
 
 	/* enable VIU clock */
-	clk = devm_clk_get(&op->dev, "viu_clk");
+	clk = devm_clk_get(&op->dev, "per");
 	if (IS_ERR(clk)) {
 		dev_err(&op->dev, "failed to lookup the clock!\n");
 		ret = PTR_ERR(clk);
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:52 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:52 +0200
Subject: [PATCH v3 25/31] mtd: mpc5121_nfc: remove now obsolete clock lookup
 name
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-26-git-send-email-gsi@denx.de>

after device tree based clock lookup became available, the NAND flash
driver need no longer use the previous "nfc_clk" name but can switch to
the fixed "per" clock name -- adjust the peripheral driver and remove
the clock driver's clkdev registration

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/platforms/512x/clock-commonclk.c |    1 -
 drivers/mtd/nand/mpc5121_nfc.c                |    2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c b/arch/powerpc/platforms/512x/clock-commonclk.c
index d0286a5..24e1706 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -677,7 +677,6 @@ static void mpc512x_clk_setup_clock_tree(int busfreq)
 	clk_register_clkdev(clks[MPC512x_CLK_REF], "ref_clk", NULL);
 	clk_register_clkdev(clks[MPC512x_CLK_SYS], "sys_clk", NULL);
 	clk_register_clkdev(clks[MPC512x_CLK_VIU], "viu_clk", NULL);
-	clk_register_clkdev(clks[MPC512x_CLK_NFC], "nfc_clk", NULL);
 
 	pr_debug("clock tree setup complete\n");
 	freq = clk_get_rate(clks[MPC512x_CLK_E300]);
diff --git a/drivers/mtd/nand/mpc5121_nfc.c b/drivers/mtd/nand/mpc5121_nfc.c
index 9c0b8fe..6a5f851 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -731,7 +731,7 @@ static int mpc5121_nfc_probe(struct platform_device *op)
 	of_node_put(rootnode);
 
 	/* Enable NFC clock */
-	clk = devm_clk_get(dev, "nfc_clk");
+	clk = devm_clk_get(dev, "per");
 	if (IS_ERR(clk)) {
 		dev_err(dev, "Unable to acquire NFC clock!\n");
 		retval = PTR_ERR(clk);
-- 
1.7.10.4



From gsi at denx.de  Mon Jul 22 08:14:41 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Mon, 22 Jul 2013 14:14:41 +0200
Subject: [PATCH v3 14/31] dts: mpc512x: prepare for preprocessor support
In-Reply-To: <1374495298-22019-1-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
Message-ID: <1374495298-22019-15-git-send-email-gsi@denx.de>

prepare C preprocessor support when processing MPC512x DTS files
- switch from DTS syntax to CPP syntax for include specs
- create a symlink such that DTS processing can reference includes

Signed-off-by: Gerhard Sittig <gsi at denx.de>
---
 arch/powerpc/boot/dts/ac14xx.dts          |    2 +-
 arch/powerpc/boot/dts/include/dt-bindings |    1 +
 arch/powerpc/boot/dts/mpc5121ads.dts      |    2 +-
 arch/powerpc/boot/dts/pdm360ng.dts        |    2 +-
 4 files changed, 4 insertions(+), 3 deletions(-)
 create mode 120000 arch/powerpc/boot/dts/include/dt-bindings

diff --git a/arch/powerpc/boot/dts/ac14xx.dts b/arch/powerpc/boot/dts/ac14xx.dts
index a27a460..a543c40 100644
--- a/arch/powerpc/boot/dts/ac14xx.dts
+++ b/arch/powerpc/boot/dts/ac14xx.dts
@@ -10,7 +10,7 @@
  */
 
 
-/include/ "mpc5121.dtsi"
+#include <mpc5121.dtsi>
 
 / {
 	model = "ac14xx";
diff --git a/arch/powerpc/boot/dts/include/dt-bindings b/arch/powerpc/boot/dts/include/dt-bindings
new file mode 120000
index 0000000..08c00e4
--- /dev/null
+++ b/arch/powerpc/boot/dts/include/dt-bindings
@@ -0,0 +1 @@
+../../../../../include/dt-bindings
\ No newline at end of file
diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts b/arch/powerpc/boot/dts/mpc5121ads.dts
index 7d3cb79..c228a0a 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -9,7 +9,7 @@
  * option) any later version.
  */
 
-/include/ "mpc5121.dtsi"
+#include <mpc5121.dtsi>
 
 / {
 	model = "mpc5121ads";
diff --git a/arch/powerpc/boot/dts/pdm360ng.dts b/arch/powerpc/boot/dts/pdm360ng.dts
index 7433740..871c16d 100644
--- a/arch/powerpc/boot/dts/pdm360ng.dts
+++ b/arch/powerpc/boot/dts/pdm360ng.dts
@@ -13,7 +13,7 @@
  * option) any later version.
  */
 
-/include/ "mpc5121.dtsi"
+#include <mpc5121.dtsi>
 
 / {
 	model = "pdm360ng";
-- 
1.7.10.4



From shawn.guo at linaro.org  Mon Jul 22 08:42:16 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 22 Jul 2013 20:42:16 +0800
Subject: [PATCH 2/2] ARM: dts: mx6: Add support for imx6dl nitrogen board
In-Reply-To: <CAOMZO5C8Zz27KQOQxnurRmEUqUPw6VZNPGc3g4oXEUZUDxtYVQ@mail.gmail.com>
References: <1374118960-19060-1-git-send-email-festevam@gmail.com>
 <1374118960-19060-2-git-send-email-festevam@gmail.com>
 <20130722075736.GC20271@S2101-09.ap.freescale.net>
 <CAOMZO5C8Zz27KQOQxnurRmEUqUPw6VZNPGc3g4oXEUZUDxtYVQ@mail.gmail.com>
Message-ID: <20130722124213.GJ20271@S2101-09.ap.freescale.net>

On Mon, Jul 22, 2013 at 09:21:20AM -0300, Fabio Estevam wrote:
> Hi Shawn,
> 
> On Mon, Jul 22, 2013 at 4:57 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> 
> >> +/ {
> >> +     model = "Boundary Devices i.MX6 Dual Lite Nitrogen Board";
> >> +     compatible = "boundary,imx6dl-nitrogen", "fsl,imx6dl";
> >> +
> >> +     memory {
> >> +             reg = <0x10000000 0x40000000>;
> >> +     };
> >
> > This memory configuration is also common, right?
> 
> The reason I put the memory configuration in this file is because we
> also have nitrogen quad and dual-lite versions with 2GB.

Fine, then.

Shawn



From l.stach at pengutronix.de  Mon Jul 22 08:46:52 2013
From: l.stach at pengutronix.de (Lucas Stach)
Date: Mon, 22 Jul 2013 14:46:52 +0200
Subject: [PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
In-Reply-To: <026001ce86d8$2963d730$7c2b8590$%dae@samsung.com>
References: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
 <1374475767-30085-3-git-send-email-chanho61.park@samsung.com>
 <20130722084817.GA18731@e106331-lin.cambridge.arm.com>
 <026001ce86d8$2963d730$7c2b8590$%dae@samsung.com>
Message-ID: <1374497212.4456.4.camel@weser.hi.pengutronix.de>

Am Montag, den 22.07.2013, 21:37 +0900 schrieb Inki Dae:
> 
> > -----Original Message-----
> > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > Sent: Monday, July 22, 2013 5:48 PM
> > To: Chanho Park
> > Cc: inki.dae at samsung.com; kgene.kim at samsung.com; linux-samsung-
> > soc at vger.kernel.org; jy0922.shim at samsung.com; devicetree-
> > discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> > devel at lists.freedesktop.org; kyungmin.park at samsung.com; linux-arm-
> > kernel at lists.infradead.org
> > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
> > rotator
> > 
> > On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> > > This patch adds a dt-binding document for exynos rotator. It describes
> > which
> > > nodes should be defined to use the rotator.
> > >
> > > Signed-off-by: Chanho Park <chanho61.park at samsung.com>
> > > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> > > ---
> > >  .../bindings/drm/exynos/samsung-rotator.txt        |   35
> > ++++++++++++++++++++
> > >  1 file changed, 35 insertions(+)
> > >  create mode 100644
> > Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-
> > rotator.txt b/Documentation/devicetree/bindings/drm/exynos/samsung-
> > rotator.txt
> > > new file mode 100644
> > > index 0000000..6b1d704
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> > > @@ -0,0 +1,35 @@
> > > +* Samsung Image Rotator
> > > +
> > > +Required properties:
> > > +  - compatible : value should be the "samsung,exynos4210".
> 
> Please, add more compatible strings for other SoC.
> 
> > > +  - reg : Physical base address of the IP registers and length of
> > memory
> > > +	  mapped region.
> > > +  - interrupts : interrupt number to the CPU.
> > > +  - clocks : clock number of exynos4 rotator clock.
> > > +  - clocks : clock name of rotator
> > 
> > clock-names?
> > 
> > > +  - status : "okay" or "disabled"
> > > +  - limit table for image formats : min_w/min_h/max_w/max_h for min/max
> > of image
> > 
> > Limit table? This doesn't seem to be a well-defined binding, and it
> > seems like a relatively generic thing to describe.
> > 
> > > +
> > > +Example:
> > > +	rotator: rotator at 12810000 {
> > > +		compatible = "samsung,exynos4210-rotator";
> > > +		reg = <0x12810000 0x1000>;
> > > +		interrupts = <0 83 0>;
> > > +		clocks = <&clock 278>;
> > > +		clock-names = "rotator";
> > > +		status = "disabled";
> > > +		ycbcr420_2p {
> > 
> > Which names are allowed for these subnodes?
> > 
> > > +			min_w = <32>;
> > > +			min_h = <32>;
> > > +			max_w = <32768>;
> > > +			max_h = <32768>;
> > > +			align = <3>;
> > 
> > min-width, min-height, max-width, max-height? What units are they in?
> > 
> > What does alignment specify exactly?
> > 
> > Are these a configurable part of the rotator hardware, or are these
> > values always the same?
> 
> Right, that seems like configurable part. At least, min_w/h and max_w/h can
> be different values according to SoC and pixel formats so they should be
> described enough in this dt-binding document file.
> 
Is there really this much configurability? Could each of those values be
a different on different SoCs, or could you just extract those values
from the SoC/rotator hardware version and thus the DT compatible string?

> 
> > If thery're always the same, there's no need to
> > describe in in the devicetree.
> > 
> > Thanks,
> > Mark.
> > 
> > > +		};
> > > +		rgb888 {
> > > +			min_w = <8>;
> > > +			min_h = <8>;
> > > +			max_w = <8192>;
> > > +			max_h = <8192>;
> > > +			align = <2>;
> > > +		};
> > > +	};
> > > --
> > > 1.7.9.5
> > >
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > >
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



From christoffer.dall at linaro.org  Mon Jul 22 08:51:52 2013
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 22 Jul 2013 14:51:52 +0200
Subject: [PATCH 3/4] arm64: KVM: let other tasks run when hitting WFE
In-Reply-To: <CAC4Lta17bmNjBck6LzziBeU0Xc36F1Jms2tQPv6+GaXvik6Wyg@mail.gmail.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
 <CAC4Lta17bmNjBck6LzziBeU0Xc36F1Jms2tQPv6+GaXvik6Wyg@mail.gmail.com>
Message-ID: <CAMJs5B8Sg1MPHPsRV75mmagnYxkhzA0MKWVkwW2y0WdDVWTSxQ@mail.gmail.com>

On 22 July 2013 10:53, Raghavendra KT <raghavendra.kt.linux at gmail.com> wrote:
> On Fri, Jul 19, 2013 at 7:23 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> So far, when a guest executes WFE (like when waiting for a spinlock
>> to become unlocked), we don't do a thing and let it run uninterrupted.
>>
>> Another option is to trap a blocking WFE and offer the opportunity
>> to the scheduler to switch to another task, potentially giving the
>> vcpu holding the spinlock a chance to run sooner.
>>
>
> Idea looks to be correct from my experiments on x86. It does bring some
> percentage of benefits in overcommitted guests. Infact,
>
> https://lkml.org/lkml/2013/7/22/41 tries to do the same thing for x86.
> (this results in using ple handler heuristics in vcpu_block pach).

What about the adverse effect in the non-overcommitted case?


From will.deacon at arm.com  Mon Jul 22 09:01:18 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 22 Jul 2013 14:01:18 +0100
Subject: [PATCH 3/4] arm64: KVM: let other tasks run when hitting WFE
In-Reply-To: <CAMJs5B8Sg1MPHPsRV75mmagnYxkhzA0MKWVkwW2y0WdDVWTSxQ@mail.gmail.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
 <CAC4Lta17bmNjBck6LzziBeU0Xc36F1Jms2tQPv6+GaXvik6Wyg@mail.gmail.com>
 <CAMJs5B8Sg1MPHPsRV75mmagnYxkhzA0MKWVkwW2y0WdDVWTSxQ@mail.gmail.com>
Message-ID: <20130722130118.GA30857@mudshark.cambridge.arm.com>

On Mon, Jul 22, 2013 at 01:51:52PM +0100, Christoffer Dall wrote:
> On 22 July 2013 10:53, Raghavendra KT <raghavendra.kt.linux at gmail.com> wrote:
> > On Fri, Jul 19, 2013 at 7:23 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> >> So far, when a guest executes WFE (like when waiting for a spinlock
> >> to become unlocked), we don't do a thing and let it run uninterrupted.
> >>
> >> Another option is to trap a blocking WFE and offer the opportunity
> >> to the scheduler to switch to another task, potentially giving the
> >> vcpu holding the spinlock a chance to run sooner.
> >>
> >
> > Idea looks to be correct from my experiments on x86. It does bring some
> > percentage of benefits in overcommitted guests. Infact,
> >
> > https://lkml.org/lkml/2013/7/22/41 tries to do the same thing for x86.
> > (this results in using ple handler heuristics in vcpu_block pach).
> 
> What about the adverse effect in the non-overcommitted case?

You might hope to reduce overall system latency, in the same way that
PREEMPT kernels implement spin_lock in terms of spin_trylock. Marc might
have some ideas about the practical performance of this, but he's currently
on holiday and (assumedly) not reading the list!

Will


From csd at broadcom.com  Mon Jul 22 09:03:12 2013
From: csd at broadcom.com (Christian Daudt)
Date: Mon, 22 Jul 2013 06:03:12 -0700
Subject: [PATCH 05/22] ARM: dts: bcm281xx: Remove '0x's from
 BCM11351 BRT DTS file
In-Reply-To: <1374490361-25769-5-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-5-git-send-email-lee.jones@linaro.org>
Message-ID: <51ED2D90.4020209@broadcom.com>

On 13-07-22 03:52 AM, Lee Jones wrote:
> Cc: Christian Daudt <csd at broadcom.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>   arch/arm/boot/dts/bcm11351-brt.dts | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm11351-brt.dts b/arch/arm/boot/dts/bcm11351-brt.dts
> index 67ec524..fdace5d 100644
> --- a/arch/arm/boot/dts/bcm11351-brt.dts
> +++ b/arch/arm/boot/dts/bcm11351-brt.dts
> @@ -27,18 +27,18 @@
>   		status = "okay";
>   	};
>   
> -	sdio0: sdio at 0x3f180000 {
> +	sdio0: sdio at 3f180000 {
>   		max-frequency = <48000000>;
>   		status = "okay";
>   	};
>   
> -	sdio1: sdio at 0x3f190000 {
> +	sdio1: sdio at 3f190000 {
>   		non-removable;
>   		max-frequency = <48000000>;
>   		status = "okay";
>   	};
>   
> -	sdio3: sdio at 0x3f1b0000 {
> +	sdio3: sdio at 3f1b0000 {
>   		max-frequency = <48000000>;
>   		status = "okay";
>   	};
Hi Lee,
  Is this convention documented ? Someone called my attention to the 
fact that this dts files was inconsistent in its use of 0x in names, but 
I was not aware of a coding guideline for this.

  Thanks,
     csd




From mkl at pengutronix.de  Mon Jul 22 09:04:52 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Mon, 22 Jul 2013 15:04:52 +0200
Subject: [PATCH v3 27/31] net: can: mscan: add common clock support for
 mpc512x
In-Reply-To: <1374495298-22019-28-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
 <1374495298-22019-28-git-send-email-gsi@denx.de>
Message-ID: <51ED2DF4.2090606@pengutronix.de>

On 07/22/2013 02:14 PM, Gerhard Sittig wrote:
> implement a .get_clock() callback for the MPC512x platform which uses
> the common clock infrastructure (eliminating direct access to the clock
> control registers from within the CAN network driver), and provide the
> corresponding .put_clock() callback to release resources after use
> 
> keep the previous implementation of MPC512x support in place during
> migration, since common clock support is optional
> 
> this change is neutral to the MPC5200 platform
> 
> Signed-off-by: Gerhard Sittig <gsi at denx.de>
> ---
>  drivers/net/can/mscan/mpc5xxx_can.c |  169 +++++++++++++++++++++++++++++++++++
>  1 file changed, 169 insertions(+)
> 
> diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
> index e59b3a3..4897929 100644
> --- a/drivers/net/can/mscan/mpc5xxx_can.c
> +++ b/drivers/net/can/mscan/mpc5xxx_can.c
> @@ -109,6 +109,167 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
>  #endif /* CONFIG_PPC_MPC52xx */
>  
>  #ifdef CONFIG_PPC_MPC512x
> +
> +#if IS_ENABLED(CONFIG_COMMON_CLK)
> +
> +static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
> +				 const char *clock_source, int *mscan_clksrc)
> +{
> +	struct device_node *np;
> +	u32 clockdiv;
> +	enum {
> +		CLK_FROM_AUTO,
> +		CLK_FROM_IPS,
> +		CLK_FROM_SYS,
> +		CLK_FROM_REF,
> +	} clk_from;
> +	struct clk *clk_in, *clk_can;
> +	unsigned long freq_calc;
> +	struct mscan_priv *priv;
> +
> +	/* the caller passed in the clock source spec that was read from
> +	 * the device tree, get the optional clock divider as well
> +	 */
> +	np = ofdev->dev.of_node;
> +	clockdiv = 1;
> +	of_property_read_u32(np, "fsl,mscan-clock-divider", &clockdiv);
> +	dev_dbg(&ofdev->dev, "device tree specs: clk src[%s] div[%d]\n",
> +		clock_source ? clock_source : "<NULL>", clockdiv);
> +
> +	/* when clock-source is 'ip', the CANCTL1[CLKSRC] bit needs to
> +	 * get set, and the 'ips' clock is the input to the MSCAN
> +	 * component
> +	 *
> +	 * for clock-source values of 'ref' or 'sys' the CANCTL1[CLKSRC]
> +	 * bit needs to get cleared, an optional clock-divider may have
> +	 * been specified (the default value is 1), the appropriate
> +	 * MSCAN related MCLK is the input to the MSCAN component
> +	 *
> +	 * in the absence of a clock-source spec, first an optimal clock
> +	 * gets determined based on the 'sys' clock, if that fails the
> +	 * 'ref' clock is used
> +	 */
> +	clk_from = CLK_FROM_AUTO;
> +	if (clock_source) {
> +		/* interpret the device tree's spec for the clock source */
> +		if (!strcmp(clock_source, "ip"))
> +			clk_from = CLK_FROM_IPS;
> +		else if (!strcmp(clock_source, "sys"))
> +			clk_from = CLK_FROM_SYS;
> +		else if (!strcmp(clock_source, "ref"))
> +			clk_from = CLK_FROM_REF;
> +		else
> +			goto err_invalid;
> +		dev_dbg(&ofdev->dev, "got a clk source spec[%d]\n", clk_from);
> +	}
> +	if (clk_from == CLK_FROM_AUTO) {
> +		/* no spec so far, try the 'sys' clock; round to the
> +		 * next MHz and see if we can get a multiple of 16MHz
> +		 */
> +		dev_dbg(&ofdev->dev, "no clk source spec, trying SYS\n");
> +		clk_in = devm_clk_get(&ofdev->dev, "sys");
> +		if (IS_ERR(clk_in))
> +			goto err_notavail;
> +		freq_calc = clk_get_rate(clk_in);
> +		freq_calc +=  499999;
> +		freq_calc /= 1000000;
> +		freq_calc *= 1000000;
> +		if ((freq_calc % 16000000) == 0) {
> +			clk_from = CLK_FROM_SYS;
> +			clockdiv = freq_calc / 16000000;
> +			dev_dbg(&ofdev->dev,
> +				"clk fit, sys[%lu] div[%d] freq[%lu]\n",
> +				freq_calc, clockdiv, freq_calc / clockdiv);
> +		}
> +	}
> +	if (clk_from == CLK_FROM_AUTO) {
> +		/* no spec so far, use the 'ref' clock */
> +		dev_dbg(&ofdev->dev, "no clk source spec, trying REF\n");
> +		clk_in = devm_clk_get(&ofdev->dev, "ref");
> +		if (IS_ERR(clk_in))
> +			goto err_notavail;
> +		clk_from = CLK_FROM_REF;
> +		freq_calc = clk_get_rate(clk_in);
> +		dev_dbg(&ofdev->dev,
> +			"clk fit, ref[%lu] (no div) freq[%lu]\n",
> +			freq_calc, freq_calc);
> +	}
> +
> +	/* select IPS or MCLK as the MSCAN input (returned to the caller),
> +	 * setup the MCLK mux source and rate if applicable, apply the
> +	 * optionally specified or derived above divider, and determine
> +	 * the actual resulting clock rate to return to the caller
> +	 */
> +	switch (clk_from) {
> +	case CLK_FROM_IPS:
> +		clk_can = devm_clk_get(&ofdev->dev, "ips");
> +		if (IS_ERR(clk_can))
> +			goto err_notavail;
> +		if (clk_prepare(clk_can)) {

I would just call prepare_enable in the main mscan driver, then we don't
need a special "clock is prepared but not enabled" contract.

> +			devm_clk_put(&ofdev->dev, clk_can);

not needed, as this driver instance will fail, doesn't it?

> +			goto err_notavail;
> +		}
> +		priv = netdev_priv(dev_get_drvdata(&ofdev->dev));
> +		priv->clk_can = clk_can;
> +		freq_calc = clk_get_rate(clk_can);
> +		*mscan_clksrc = MSCAN_CLKSRC_IPS;
> +		dev_dbg(&ofdev->dev, "clk from IPS, clksrc[%d] freq[%lu]\n",
> +			*mscan_clksrc, freq_calc);
> +		break;
> +	case CLK_FROM_SYS:
> +	case CLK_FROM_REF:
> +		clk_can = devm_clk_get(&ofdev->dev, "mclk");
> +		if (IS_ERR(clk_can))
> +			goto err_notavail;
> +		if (clk_prepare(clk_can)) {
> +			devm_clk_put(&ofdev->dev, clk_can);

same here

> +			goto err_notavail;
> +		}
> +		priv = netdev_priv(dev_get_drvdata(&ofdev->dev));
> +		priv->clk_can = clk_can;
> +		if (clk_from == CLK_FROM_SYS)
> +			clk_in = devm_clk_get(&ofdev->dev, "sys");
> +		if (clk_from == CLK_FROM_REF)
> +			clk_in = devm_clk_get(&ofdev->dev, "ref");
> +		if (IS_ERR(clk_in))
> +			goto err_notavail;
> +		clk_set_parent(clk_can, clk_in);
> +		freq_calc = clk_get_rate(clk_in);
> +		freq_calc /= clockdiv;
> +		clk_set_rate(clk_can, freq_calc);
> +		freq_calc = clk_get_rate(clk_can);
> +		*mscan_clksrc = MSCAN_CLKSRC_BUS;
> +		dev_dbg(&ofdev->dev, "clk from MCLK, clksrc[%d] freq[%lu]\n",
> +			*mscan_clksrc, freq_calc);
> +		break;
> +	default:
> +		goto err_invalid;
> +	}
> +
> +	return freq_calc;
> +
> +err_invalid:
> +	dev_err(&ofdev->dev, "invalid clock source specification\n");
> +	return 0;

return 0 in case of error? Please add a comment what this 0 means here.
> +
> +err_notavail:
> +	dev_err(&ofdev->dev, "cannot acquire or setup clock source\n");
> +	return 0;
> +}
> +
> +static void mpc512x_can_put_clock(struct platform_device *ofdev)
> +{
> +	struct mscan_priv *priv;
> +
> +	priv = netdev_priv(dev_get_drvdata(&ofdev->dev));
> +	if (priv->clk_can) {
> +		clk_unprepare(priv->clk_can);
> +		devm_clk_put(&ofdev->dev, priv->clk_can);

devm_clk_put can be removed, it's called automatically.

> +	}
> +}
> +
> +#else	/* COMMON_CLK */
> +
>  struct mpc512x_clockctl {
>  	u32 spmr;		/* System PLL Mode Reg */
>  	u32 sccr[2];		/* System Clk Ctrl Reg 1 & 2 */
> @@ -239,12 +400,18 @@ exit_put:
>  	of_node_put(np_clock);
>  	return freq;
>  }
> +
> +#define mpc512x_can_put_clock NULL
> +
> +#endif	/* COMMON_CLK */
> +
>  #else /* !CONFIG_PPC_MPC512x */
>  static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
>  				 const char *clock_name, int *mscan_clksrc)
>  {
>  	return 0;
>  }
> +#define mpc512x_can_put_clock NULL
>  #endif /* CONFIG_PPC_MPC512x */
>  
>  static const struct of_device_id mpc5xxx_can_table[];
> @@ -386,11 +553,13 @@ static int mpc5xxx_can_resume(struct platform_device *ofdev)
>  static const struct mpc5xxx_can_data mpc5200_can_data = {
>  	.type = MSCAN_TYPE_MPC5200,
>  	.get_clock = mpc52xx_can_get_clock,
> +	/* .put_clock not applicable */
>  };
>  
>  static const struct mpc5xxx_can_data mpc5121_can_data = {
>  	.type = MSCAN_TYPE_MPC5121,
>  	.get_clock = mpc512x_can_get_clock,
> +	.put_clock = mpc512x_can_put_clock,
>  };
>  
>  static const struct of_device_id mpc5xxx_can_table[] = {
> 

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130722/62e0a5f8/attachment-0001.sig>

From rogerq at ti.com  Mon Jul 22 09:16:24 2013
From: rogerq at ti.com (Roger Quadros)
Date: Mon, 22 Jul 2013 16:16:24 +0300
Subject: [PATCH 6/6] USB: ehci-omap: Implement suspend/resume
In-Reply-To: <Pine.LNX.4.44L0.1307111106090.1276-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307111106090.1276-100000@iolanthe.rowland.org>
Message-ID: <51ED30A8.10200@ti.com>

Hi Alan,

On 07/11/2013 06:14 PM, Alan Stern wrote:
> On Thu, 11 Jul 2013, Roger Quadros wrote:
> 
>>> The other two problems are both related to the interaction between
>>> system PM and runtime PM.  Suppose the controller is already runtime
>>> suspended when the system goes to sleep.  Because it is runtime
>>> suspended, it is enabled for wakeup.  But device_may_wakeup() could
>>> return false; if this happens then you have to do a runtime-resume in
>>> omap_ehci_suspend() before calling ehci_suspend(), so that the
>>> controller can be suspended again with wakeups disabled.  (Or you could
>>> choose an alternative method for accomplishing the same result, such as
>>> disabling the wakeup signal from the pad without going through a whole
>>> EHCI resume/suspend cycle.)  Conversely, if device_may_wakeup() returns
>>> true then you shouldn't do anything at all, because the controller is
>>> already suspended with the correct wakeup setting.
>>
>> I think this case is taken care of by the Runtime PM core at least for the OMAP
>> platform according to the documentation
>>
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/power/runtime_pm.txt#n647
> 
> No; that section refers only to races, not to wakeup settings.
> 
>> At the end of this mail is the log during system suspend/resume
>>
>> You can notice the following sequence
>>
>> -ehci runtime suspends
>> -system suspend triggered
>> -ehci runtime resumes
>> -ehci suspends (uses new wakeup settings)
>> -system wakeup triggered
>> -ehci resumes
>> -ehci runtime suspends
> 
> This is because the root hub was runtime suspended with the wrong
> wakeup setting.  The USB core, which is careful about these things,
> resumed and re-suspended it with the proper wakeup setting.  In the 
> process, the controller had to be runtime resumed as well.
> 
> Try doing the test over again, but this time with the root hub enabled 
> for wakeup and the controller disabled.  (I know this is a bizarre 
> combination, but try it anyway.)  Also, after the system wakes up, see 
> whether the root hub and controller get runtime suspended.
> 

The first part of the test caught the problem were we were trying to access
EHCI registers when HW is not accessible. So this was a good test case.

>>> For the third problem, suppose the controller was runtime suspended
>>> when the system went to sleep.  When the system wakes up, the
>>> controller will become active, so you have to inform the runtime PM
>>> core about its change of state.  Basically, if omap_ehci_resume() sees
>>> that ehci_resume() returned 0 then it must do:
>>>
>>> 	pm_runtime_disable(dev);
>>> 	pm_runtime_set_active(dev);
>>> 	pm_runtime_enable(dev);
>>>
>>> All of these issues are discussed (among lots of other material) in 
>>> Documentation/power/runtime_pm.txt.
>>
>> Is this still applicable? Documentation claims
>>
>>    "During system resume it calls pm_runtime_enable() and pm_runtime_put_sync()
>>     for every device right after executing the subsystem-level .resume_early()
>>     callback and right after executing the subsystem-level .resume() callback
>>     for it, respectively."
> 
> Yes, this is applicable, but it is irrelevant to the problem I 
> described.  You still have to tell the runtime PM core that the device 
> is now active.

Right, I understand it now. How does the below code look?

+static int omap_ehci_suspend(struct device *dev)
+{
+       struct usb_hcd *hcd = dev_get_drvdata(dev);
+       bool do_wakeup = device_may_wakeup(dev);
+       int ret;
+
+       dev_dbg(dev, "%s may_wakeup %d\n", __func__, do_wakeup);
+
+       if (pm_runtime_status_suspended(dev)) {
+               pm_runtime_get_sync(dev);
+               ehci_resume(hcd, false);
+               ret = ehci_suspend(hcd, do_wakeup);
+               pm_runtime_put_sync(dev);
+
+       } else {
+               ret = ehci_suspend(hcd, do_wakeup);
+       }
+
+       return ret;
+}
+
+static int omap_ehci_resume(struct device *dev)
+{
+       struct usb_hcd *hcd = dev_get_drvdata(dev);
+       int ret;
+
+       dev_dbg(dev, "%s\n", __func__);
+
+       ret = ehci_resume(hcd, false);
+       if (!ret) {
+               /*
+                * Controller was powered ON so reflect state
+                */
+               pm_runtime_disable(dev);
+               pm_runtime_set_active(dev);
+               pm_runtime_enable(dev);
+       }
+
+       return ret;
+}
+
+static int omap_ehci_runtime_suspend(struct device *dev)
+{
+       struct usb_hcd *hcd = dev_get_drvdata(dev);
+       struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
+
+       dev_dbg(dev, "%s\n", __func__);
+
+       if (omap->bound)
+               ehci_suspend(hcd, true);
+
+       return 0;
+}
+
+static int omap_ehci_runtime_resume(struct device *dev)
+{
+       struct usb_hcd *hcd = dev_get_drvdata(dev);
+       struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
+
+       dev_dbg(dev, "%s\n", __func__);
+
+       if (omap->bound)
+               ehci_resume(hcd, false);
+
+       return 0;
+}


cheers,
-roger


From mark.rutland at arm.com  Mon Jul 22 09:17:47 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Jul 2013 14:17:47 +0100
Subject: [PATCH 5/5] iio: at91: introduce touch screen support in iio
 adc driver
In-Reply-To: <1373789069-11604-6-git-send-email-josh.wu@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-6-git-send-email-josh.wu@atmel.com>
Message-ID: <20130722131747.GA32221@e106331-lin.cambridge.arm.com>

On Sun, Jul 14, 2013 at 09:04:29AM +0100, Josh Wu wrote:
> AT91 ADC hardware integrate touch screen support. So this patch add touch
> screen support for at91 adc iio driver.
> To enable touch screen support in adc, you need to add the dt parameters:
>   which type of touch are used? (4 or 5 wires), sample period time,
>   pen detect debounce time, average samples and pen detect resistor.
> 
> In the meantime, since touch screen will use a interal period trigger of adc,
> so it is conflict to other hardware triggers. Driver will disable the hardware
> trigger support if touch screen is enabled.
> 
> This driver has been tested in AT91SAM9X5-EK and SAMA5D3x-EK.
> 
> Signed-off-by: Josh Wu <josh.wu at atmel.com>
> Cc: Dmitry Torokhov <dmitry.torokhov at gmail.com>
> ---
>  .../devicetree/bindings/arm/atmel-adc.txt          |   13 +
>  arch/arm/mach-at91/include/mach/at91_adc.h         |   34 ++
>  drivers/iio/adc/at91_adc.c                         |  389 ++++++++++++++++++--
>  3 files changed, 412 insertions(+), 24 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> index 0db2945..925d656 100644
> --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> @@ -29,6 +29,19 @@ Optional properties:
>    - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
>    - atmel,adc-clock-rate: ADC clock rate. If not specified, use the default
>                           adc_op_clk.
> +  - atmel,adc-touchscreen-wires: Number of touch screen wires. Only support
> +                                4 and 5 wires touch screen.

Are 4 and 5 wire configurations that can exist, or the only ones
supported by the driver?

> +    NOTE: when adc touch screen enabled, the adc hardware trigger will be
> +          disabled. Since touch screen will occupied the trigger register.
> +  - atmel,adc-ts-pendet-debounce: Debounce time in microsecond for touch pen
> +                                 detect.

For consistency with the adc-touchscreen-wires property, and  other
properties with timing information, how about
atmel,adc-touchscreen-debounce-delay-us ?

> +  - atmel,adc-ts-sample-period-time: Sample Period Time in microsecond for
> +                                    touch screen

Again, please be consistent with ts or touchscreen. It may also be good
to have -us to make the units explicit (though it does leave the
property name being quite a mothful):

atmel,adc-touchscreen-sample-period-us ?

> +  - atmel,adc-ts-filter-average: Numbers of sampling data will be averaged.
> +    0 means no average. 1 means average two samples. 2 means average four
> +    samples. 3 means average eight samples.

Is this averaging done in the hardware, or the kernel driver?

If it's the latter, this can be left for the kernel to decide.

> +  - atmel,adc-ts-pendet-sensitivity: Pen Detection input pull-up resistor.
> +    It can be 0, 1, 2, 3.

I think "pendet" is a bit opaque. "pen-detect" may be better. What
physical property does this represent (are these discrete values, or an
enumeration)?

Thanks,
Mark.

> 
>  Optional trigger Nodes:
>    - Required properties:
> diff --git a/arch/arm/mach-at91/include/mach/at91_adc.h b/arch/arm/mach-at91/include/mach/at91_adc.h
> index ab273ee..6d6cc14 100644
> --- a/arch/arm/mach-at91/include/mach/at91_adc.h
> +++ b/arch/arm/mach-at91/include/mach/at91_adc.h
> @@ -57,10 +57,44 @@
>  #define AT91_ADC_IER           0x24            /* Interrupt Enable Register */
>  #define AT91_ADC_IDR           0x28            /* Interrupt Disable Register */
>  #define AT91_ADC_IMR           0x2C            /* Interrupt Mask Register */
> +#define                AT91_ADC_IER_PEN        (1 << 29)
> +#define                AT91_ADC_IER_NOPEN      (1 << 30)
> +#define                AT91_ADC_IER_XRDY       (1 << 20)
> +#define                AT91_ADC_IER_YRDY       (1 << 21)
> +#define                AT91_ADC_IER_PRDY       (1 << 22)
> +#define                AT91_ADC_ISR_PENS       (1 << 31)
> 
>  #define AT91_ADC_CHR(n)                (0x30 + ((n) * 4))      /* Channel Data Register N */
>  #define                AT91_ADC_DATA           (0x3ff)
> 
> +#define AT91_ADC_ACR           0x94    /* Analog Control Register */
> +#define                AT91_ADC_ACR_PENDETSENS (0x3 << 0)      /* pull-up resistor */
> +
> +#define AT91_ADC_TSMR          0xB0
> +#define                AT91_ADC_TSMR_TSMODE    (3 << 0)        /* Touch Screen Mode */
> +#define                        AT91_ADC_TSMR_TSMODE_NONE               (0 << 0)
> +#define                        AT91_ADC_TSMR_TSMODE_4WIRE_NO_PRESS     (1 << 0)
> +#define                        AT91_ADC_TSMR_TSMODE_4WIRE_PRESS        (2 << 0)
> +#define                        AT91_ADC_TSMR_TSMODE_5WIRE              (3 << 0)
> +#define                AT91_ADC_TSMR_TSAV      (3 << 4)        /* Averages samples */
> +#define                        AT91_ADC_TSMR_TSAV_(x)          ((x) << 4)
> +#define                AT91_ADC_TSMR_SCTIM     (0x0f << 16)    /* Switch closure time */
> +#define                AT91_ADC_TSMR_PENDBC    (0x0f << 28)    /* Pen Debounce time */
> +#define                        AT91_ADC_TSMR_PENDBC_(x)        ((x) << 28)
> +#define                AT91_ADC_TSMR_NOTSDMA   (1 << 22)       /* No Touchscreen DMA */
> +#define                AT91_ADC_TSMR_PENDET_DIS        (0 << 24)       /* Pen contact detection disable */
> +#define                AT91_ADC_TSMR_PENDET_ENA        (1 << 24)       /* Pen contact detection enable */
> +
> +#define AT91_ADC_TSXPOSR       0xB4
> +#define AT91_ADC_TSYPOSR       0xB8
> +#define AT91_ADC_TSPRESSR      0xBC
> +
>  #define AT91_ADC_VERSION       0xFC
> 
> +/* Trigger Register bit field */
> +#define                AT91_ADC_TRGR_TRGPER    (0xffff << 16)
> +#define                        AT91_ADC_TRGR_TRGPER_(x)        ((x) << 16)
> +#define                AT91_ADC_TRGR_TRGMOD    (0x7 << 0)
> +#define                        AT91_ADC_TRGR_MOD_PERIOD_TRIG   (5 << 0)
> +
>  #endif
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index 8f1386f..ffc0e42 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -11,6 +11,7 @@
>  #include <linux/clk.h>
>  #include <linux/err.h>
>  #include <linux/io.h>
> +#include <linux/input.h>
>  #include <linux/interrupt.h>
>  #include <linux/jiffies.h>
>  #include <linux/kernel.h>
> @@ -39,12 +40,24 @@
>  #define at91_adc_writel(st, reg, val) \
>         (writel_relaxed(val, st->reg_base + reg))
> 
> +#define DRIVER_NAME            "at91_adc"
> +#define MAX_POS_BITS           12
> +
> +#define ZTHRESHOLD             9000
> +
>  struct at91_adc_caps {
> +       bool    has_12bits_xy;  /* true means use 12 bits. Otherwise 10 bits */
>         bool    has_tsmr;       /* only at91sam9x5, sama5d3 have TSMR reg */
>         u32     mr_prescal_mask;
>         u32     mr_startup_mask;
>  };
> 
> +enum atmel_adc_ts_type {
> +       ATMEL_ADC_TOUCHSCREEN_NONE = 0,
> +       ATMEL_ADC_TOUCHSCREEN_4WIRE,
> +       ATMEL_ADC_TOUCHSCREEN_5WIRE,
> +};
> +
>  struct at91_adc_state {
>         struct clk              *adc_clk;
>         u32                     adc_clk_rate;
> @@ -70,6 +83,29 @@ struct at91_adc_state {
>         bool                    low_res;        /* the resolution corresponds to the lowest one */
>         wait_queue_head_t       wq_data_avail;
>         struct at91_adc_caps    caps;
> +
> +       /*
> +        * Following ADC channels are shared by touchscreen:
> +        *
> +        * CH0 -- Touch screen XP/UL
> +        * CH1 -- Touch screen XM/UR
> +        * CH2 -- Touch screen YP/LL
> +        * CH3 -- Touch screen YM/Sense
> +        * CH4 -- Touch screen LR(5-wire only)
> +        *
> +        * The bitfields below represents the reserved channel in the
> +        * touchscreen mode.
> +        */
> +#define CHAN_MASK_TOUCHSCREEN_4WIRE    (0xf << 0)
> +#define CHAN_MASK_TOUCHSCREEN_5WIRE    (0x1f << 0)
> +       enum atmel_adc_ts_type  touchscreen_type;
> +       struct input_dev                *ts_input;
> +
> +       u8                      ts_filter_average;
> +       u16                     ts_pen_detect_debounce;
> +       u8                      ts_pen_detect_sensitivity;
> +       u16                     ts_sample_period_time;
> +       u16                     ts_sample_period_val;
>  };
> 
>  static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
> @@ -104,14 +140,10 @@ static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
>         return IRQ_HANDLED;
>  }
> 
> -static irqreturn_t at91_adc_eoc_trigger(int irq, void *private)
> +/* Handler for classic adc channel eoc trigger */
> +void handle_adc_eoc_trigger(int irq, struct iio_dev *idev)
>  {
> -       struct iio_dev *idev = private;
>         struct at91_adc_state *st = iio_priv(idev);
> -       u32 status = at91_adc_readl(st, st->registers->status_register);
> -
> -       if (!(status & st->registers->drdy_mask))
> -               return IRQ_HANDLED;
> 
>         if (iio_buffer_enabled(idev)) {
>                 disable_irq_nosync(irq);
> @@ -121,6 +153,115 @@ static irqreturn_t at91_adc_eoc_trigger(int irq, void *private)
>                 st->done = true;
>                 wake_up_interruptible(&st->wq_data_avail);
>         }
> +}
> +
> +static int at91_ts_sample(struct at91_adc_state *st)
> +{
> +       unsigned int xscale, yscale, reg, z1, z2;
> +       unsigned int x, y, pres, xpos, ypos;
> +       unsigned int rxp = 1;
> +       unsigned int factor = 1000;
> +       struct iio_dev *idev = iio_priv_to_dev(st);
> +
> +       unsigned int xyz_mask_bits = st->caps.has_12bits_xy ? 12 : 10;
> +       unsigned int xyz_mask = (1 << xyz_mask_bits) - 1;
> +
> +       /* calculate position */
> +       /* x position = (x / xscale) * max, max = 2^MAX_POS_BITS - 1 */
> +       reg = at91_adc_readl(st, AT91_ADC_TSXPOSR);
> +       xpos = reg & xyz_mask;
> +       x = (xpos << MAX_POS_BITS) - xpos;
> +       xscale = (reg >> 16) & xyz_mask;
> +       if (xscale != 0)
> +               x /= xscale;
> +       else
> +               dev_err(&idev->dev, "xscale == 0!!!\n");
> +
> +       /* y position = (y / yscale) * max, max = 2^MAX_POS_BITS - 1 */
> +       reg = at91_adc_readl(st, AT91_ADC_TSYPOSR);
> +       ypos = reg & xyz_mask;
> +       y = (ypos << MAX_POS_BITS) - ypos;
> +       yscale = (reg >> 16) & xyz_mask;
> +       if (yscale != 0)
> +               y /= yscale;
> +       else
> +               dev_err(&idev->dev, "yscale == 0!!!\n");
> +
> +       /* calculate the pressure */
> +       reg = at91_adc_readl(st, AT91_ADC_TSPRESSR);
> +       z1 = reg & xyz_mask;
> +       z2 = (reg >> 16) & xyz_mask;
> +
> +       if (z1 != 0)
> +               pres = rxp * (x * factor / 1024) * (z2 * factor / z1 - factor)
> +                       / factor;
> +       else
> +               pres = ZTHRESHOLD;      /* no pen contacted */
> +
> +       dev_dbg(&idev->dev, "xpos = %d, xscale = %d, ypos = %d, yscale = %d, z1 = %d, z2 = %d, press = %d\n",
> +                               xpos, xscale, ypos, yscale, z1, z2, pres);
> +
> +       if (pres < ZTHRESHOLD) {
> +               dev_dbg(&idev->dev, "x = %d, y = %d, pressure = %d\n",
> +                                       x, y, pres / factor);
> +               input_report_abs(st->ts_input, ABS_X, x);
> +               input_report_abs(st->ts_input, ABS_Y, y);
> +               input_report_abs(st->ts_input, ABS_PRESSURE, pres);
> +               input_report_key(st->ts_input, BTN_TOUCH, 1);
> +               input_sync(st->ts_input);
> +       } else {
> +               dev_dbg(&idev->dev,
> +                               "pressure too low: not reporting\n");
> +       }
> +
> +       return 0;
> +}
> +
> +
> +static irqreturn_t at91_adc_interrupt(int irq, void *private)
> +{
> +       struct iio_dev *idev = private;
> +       struct at91_adc_state *st = iio_priv(idev);
> +       u32 status = at91_adc_readl(st, st->registers->status_register);
> +       const uint32_t ts_data_irq_mask =
> +               AT91_ADC_IER_XRDY |
> +               AT91_ADC_IER_YRDY |
> +               AT91_ADC_IER_PRDY;
> +
> +       if (status & st->registers->drdy_mask)
> +               handle_adc_eoc_trigger(irq, idev);
> +
> +       if (status & AT91_ADC_IER_PEN) {
> +               at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_PEN);
> +               at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_NOPEN |
> +                       ts_data_irq_mask);
> +               /* Set up period trigger for sampling */
> +               at91_adc_writel(st, st->registers->trigger_register,
> +                       AT91_ADC_TRGR_MOD_PERIOD_TRIG |
> +                       AT91_ADC_TRGR_TRGPER_(st->ts_sample_period_val));
> +       } else if (status & AT91_ADC_IER_NOPEN) {
> +               at91_adc_writel(st, st->registers->trigger_register, 0);
> +               at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_NOPEN |
> +                       ts_data_irq_mask);
> +               at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_PEN);
> +
> +               input_report_key(st->ts_input, BTN_TOUCH, 0);
> +               input_sync(st->ts_input);
> +       } else if ((status & ts_data_irq_mask) == ts_data_irq_mask) {
> +               /* Now all touchscreen data is ready */
> +
> +               if (status & AT91_ADC_ISR_PENS) {
> +                       /* validate data by pen contact */
> +                       at91_ts_sample(st);
> +               } else {
> +                       /* triggered by event that is no pen contact, just read
> +                        * them to clean the interrupt and discard all.
> +                        */
> +                       at91_adc_readl(st, AT91_ADC_TSXPOSR);
> +                       at91_adc_readl(st, AT91_ADC_TSYPOSR);
> +                       at91_adc_readl(st, AT91_ADC_TSPRESSR);
> +               }
> +       }
> 
>         return IRQ_HANDLED;
>  }
> @@ -130,6 +271,16 @@ static int at91_adc_channel_init(struct iio_dev *idev)
>         struct at91_adc_state *st = iio_priv(idev);
>         struct iio_chan_spec *chan_array, *timestamp;
>         int bit, idx = 0;
> +       unsigned long rsvd_mask = 0;
> +
> +       /* If touchscreen is enable, then reserve the adc channels */
> +       if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_4WIRE)
> +               rsvd_mask = CHAN_MASK_TOUCHSCREEN_4WIRE;
> +       else if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_5WIRE)
> +               rsvd_mask = CHAN_MASK_TOUCHSCREEN_5WIRE;
> +
> +       /* set up the channel mask to reserve touchscreen channels */
> +       st->channels_mask &= ~rsvd_mask;
> 
>         idev->num_channels = bitmap_weight(&st->channels_mask,
>                                            st->num_channels) + 1;
> @@ -561,6 +712,57 @@ static int at91_adc_probe_dt(struct at91_adc_state *st,
>                 i++;
>         }
> 
> +       /* Check if touchscreen is enabled in DT. */
> +       ret = of_property_read_u32(node, "atmel,adc-touchscreen-wires", &prop);
> +       if (ret)
> +               dev_info(&idev->dev, "Touchscreen not enabled.\n");
> +       else if (prop == 4)
> +               st->touchscreen_type = ATMEL_ADC_TOUCHSCREEN_4WIRE;
> +       else if (prop == 5)
> +               st->touchscreen_type = ATMEL_ADC_TOUCHSCREEN_5WIRE;
> +       else
> +               dev_warn(&idev->dev, "Unsupported number of touchscreen wires (%d)\n",
> +                               prop);
> +
> +       if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_NONE)
> +               return 0;
> +
> +       /* Touch screen is enabled, so check touch screen dt parameters */
> +       if (of_property_read_u32(node, "atmel,adc-ts-filter-average", &prop)) {
> +               dev_err(&idev->dev, "Missing atmel,adc-ts-filtering-average property in the DT.\n");
> +               ret = -EINVAL;
> +               goto error_ret;
> +       }
> +       st->ts_filter_average = prop;
> +       if (st->ts_filter_average > 3) {
> +               dev_err(&idev->dev, "Invalid atmel,adc-ts-filtering-average property in the DT.\n");
> +               ret = -EINVAL;
> +               goto error_ret;
> +       }
> +
> +       prop = 0;
> +       of_property_read_u32(node, "atmel,adc-ts-pendet-debounce", &prop);
> +       st->ts_pen_detect_debounce = prop;
> +
> +       /* default sample period is 2ms. The real touch sample period should be
> +        * this period * TSFREQ.
> +        */
> +       prop = 2000;
> +       of_property_read_u32(node, "atmel,adc-ts-sample-period-time", &prop);
> +       st->ts_sample_period_time = prop;
> +
> +       if (of_property_read_u32(node, "atmel,adc-ts-pendet-sensitivity", &prop)) {
> +               dev_err(&idev->dev, "Missing atmel,adc-ts-pendet-sensitivity property in the DT.\n");
> +               ret = -EINVAL;
> +               goto error_ret;
> +       }
> +       st->ts_pen_detect_sensitivity = prop;
> +       if (st->ts_pen_detect_sensitivity > 3) {
> +               dev_err(&idev->dev, "Invalid atmel,adc-ts-pendet-sensitivity property in the DT.\n");
> +               ret = -EINVAL;
> +               goto error_ret;
> +       }
> +
>         return 0;
> 
>  error_ret:
> @@ -592,6 +794,114 @@ static const struct iio_info at91_adc_info = {
>         .read_raw = &at91_adc_read_raw,
>  };
> 
> +/* Touchscreen related functions */
> +static int atmel_ts_open(struct input_dev *dev)
> +{
> +       struct at91_adc_state *st = input_get_drvdata(dev);
> +
> +       at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_PEN);
> +       return 0;
> +}
> +
> +static void atmel_ts_close(struct input_dev *dev)
> +{
> +       struct at91_adc_state *st = input_get_drvdata(dev);
> +
> +       at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_PEN);
> +}
> +
> +static int at91_ts_hw_init(struct at91_adc_state *st, u32 adc_clk_khz)
> +{
> +       u32 reg = 0, pendbc;
> +       int i = 0;
> +
> +       if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_4WIRE)
> +               reg = AT91_ADC_TSMR_TSMODE_4WIRE_PRESS;
> +       else
> +               reg = AT91_ADC_TSMR_TSMODE_5WIRE;
> +
> +       /* a Pen Detect Debounce Time is necessary for the ADC Touch to avoid
> +        * pen detect noise.
> +        * The formula is : Pen Detect Debounce Time = (2 ^ pendbc) / ADCClock
> +        */
> +       pendbc = round_up(st->ts_pen_detect_debounce * adc_clk_khz / 1000, 1);
> +
> +       while (pendbc >> ++i)
> +               ;       /* Empty! Find the shift offset */
> +       if (abs(pendbc - (1 << i)) < abs(pendbc - (1 << (i - 1))))
> +               pendbc = i;
> +       else
> +               pendbc = i - 1;
> +
> +       if (st->caps.has_tsmr) {
> +               reg |= AT91_ADC_TSMR_TSAV_(st->ts_filter_average)
> +                               & AT91_ADC_TSMR_TSAV;
> +               reg |= AT91_ADC_TSMR_PENDBC_(pendbc) & AT91_ADC_TSMR_PENDBC;
> +               reg |= AT91_ADC_TSMR_NOTSDMA;
> +               reg |= AT91_ADC_TSMR_PENDET_ENA;
> +               reg |= 0x03 << 8;       /* TSFREQ, need bigger than TSAV */
> +
> +               at91_adc_writel(st, AT91_ADC_TSMR, reg);
> +       } else {
> +               /* TODO: for 9g45 which has no TSMR */
> +       }
> +
> +       /* Change adc internal resistor value for better pen detection,
> +        * default value is 100 kOhm.
> +        * 0 = 200 kOhm, 1 = 150 kOhm, 2 = 100 kOhm, 3 = 50 kOhm
> +        * option only available on ES2 and higher
> +        */
> +       at91_adc_writel(st, AT91_ADC_ACR, st->ts_pen_detect_sensitivity
> +                       & AT91_ADC_ACR_PENDETSENS);
> +
> +       /* Sample Peroid Time = (TRGPER + 1) / ADCClock */
> +       st->ts_sample_period_val = round_up((st->ts_sample_period_time *
> +                       adc_clk_khz / 1000) - 1, 1);
> +
> +       return 0;
> +}
> +
> +static int at91_ts_register(struct at91_adc_state *st)
> +{
> +       struct input_dev *input;
> +       struct iio_dev *idev = iio_priv_to_dev(st);
> +       int ret;
> +
> +       input = input_allocate_device();
> +       if (!input) {
> +               dev_err(&idev->dev, "Failed to allocate TS device!\n");
> +               return -ENOMEM;
> +       }
> +
> +       input->name = DRIVER_NAME;
> +       input->id.bustype = BUS_HOST;
> +       input->dev.parent = idev->dev.parent;
> +       input->open = atmel_ts_open;
> +       input->close = atmel_ts_close;
> +
> +       __set_bit(EV_ABS, input->evbit);
> +       __set_bit(EV_KEY, input->evbit);
> +       __set_bit(BTN_TOUCH, input->keybit);
> +       input_set_abs_params(input, ABS_X, 0, (1 << MAX_POS_BITS) - 1, 0, 0);
> +       input_set_abs_params(input, ABS_Y, 0, (1 << MAX_POS_BITS) - 1, 0, 0);
> +       input_set_abs_params(input, ABS_PRESSURE, 0, 0xffffff, 0, 0);
> +
> +       st->ts_input = input;
> +       input_set_drvdata(input, st);
> +
> +       ret = input_register_device(input);
> +       if (ret)
> +               input_free_device(st->ts_input);
> +
> +       return ret;
> +}
> +
> +static void at91_ts_unregister(struct at91_adc_state *st)
> +{
> +       input_unregister_device(st->ts_input);
> +       input_free_device(st->ts_input);
> +}
> +
>  /*
>   * Since atmel adc support different ip for touchscreen mode. Through the
>   * IP check, we will know the touchscreen capbilities.
> @@ -610,6 +920,7 @@ static void atmel_adc_get_cap(struct at91_adc_state *st)
>         /* keep only major version number */
>         switch (version & 0xf00) {
>         case 0x500:     /* SAMA5D3 */
> +               st->caps.has_12bits_xy = 1;
>         case 0x400:     /* AT91SAM9X5/9N12 */
>                 st->caps.has_tsmr = 1;
>                 st->caps.mr_startup_mask = AT91_ADC_STARTUP;
> @@ -683,7 +994,7 @@ static int at91_adc_probe(struct platform_device *pdev)
>         at91_adc_writel(st, AT91_ADC_CR, AT91_ADC_SWRST);
>         at91_adc_writel(st, AT91_ADC_IDR, 0xFFFFFFFF);
>         ret = request_irq(st->irq,
> -                         at91_adc_eoc_trigger,
> +                         at91_adc_interrupt,
>                           0,
>                           pdev->dev.driver->name,
>                           idev);
> @@ -731,6 +1042,10 @@ static int at91_adc_probe(struct platform_device *pdev)
>         adc_clk = st->adc_clk_rate ?
>                 st->adc_clk_rate : clk_get_rate(st->adc_clk);
>         adc_clk_khz = adc_clk / 1000;
> +
> +       dev_dbg(&pdev->dev, "Master clock is set as: %d Hz, adc_clk should set as: %d Hz\n",
> +               mstrclk, adc_clk);
> +
>         prsc = (mstrclk / (2 * adc_clk)) - 1;
> 
>         if (!st->startup_time) {
> @@ -799,30 +1114,52 @@ static int at91_adc_probe(struct platform_device *pdev)
>         init_waitqueue_head(&st->wq_data_avail);
>         mutex_init(&st->lock);
> 
> -       ret = at91_adc_buffer_init(idev);
> -       if (ret < 0) {
> -               dev_err(&pdev->dev, "Couldn't initialize the buffer.\n");
> -               goto error_disable_adc_clk;
> -       }
> +       /*
> +        * Since touch screen will set trigger register as period trigger. So
> +        * when touch screen is enabled, then we have to disable hardware
> +        * trigger for classic adc.
> +        */
> +       if (!st->touchscreen_type) {
> +               ret = at91_adc_buffer_init(idev);
> +               if (ret < 0) {
> +                       dev_err(&pdev->dev, "Couldn't initialize the buffer.\n");
> +                       goto error_disable_adc_clk;
> +               }
> 
> -       ret = at91_adc_trigger_init(idev);
> -       if (ret < 0) {
> -               dev_err(&pdev->dev, "Couldn't setup the triggers.\n");
> -               goto error_unregister_buffer;
> +               ret = at91_adc_trigger_init(idev);
> +               if (ret < 0) {
> +                       dev_err(&pdev->dev, "Couldn't setup the triggers.\n");
> +                       at91_adc_buffer_remove(idev);
> +                       goto error_disable_adc_clk;
> +               }
> +       } else {
> +               if (!st->caps.has_tsmr) {
> +                       dev_err(&pdev->dev, "We don't support non-TSMR adc\n");
> +                       goto error_disable_adc_clk;
> +               }
> +
> +               ret = at91_ts_register(st);
> +               if (ret)
> +                       goto error_disable_adc_clk;
> +
> +               at91_ts_hw_init(st, adc_clk_khz);
>         }
> 
>         ret = iio_device_register(idev);
>         if (ret < 0) {
>                 dev_err(&pdev->dev, "Couldn't register the device.\n");
> -               goto error_remove_triggers;
> +               goto error_iio_device_register;
>         }
> 
>         return 0;
> 
> -error_remove_triggers:
> -       at91_adc_trigger_remove(idev);
> -error_unregister_buffer:
> -       at91_adc_buffer_remove(idev);
> +error_iio_device_register:
> +       if (!st->touchscreen_type) {
> +               at91_adc_trigger_remove(idev);
> +               at91_adc_buffer_remove(idev);
> +       } else {
> +               at91_ts_unregister(st);
> +       }
>  error_disable_adc_clk:
>         clk_disable_unprepare(st->adc_clk);
>  error_disable_clk:
> @@ -841,8 +1178,12 @@ static int at91_adc_remove(struct platform_device *pdev)
>         struct at91_adc_state *st = iio_priv(idev);
> 
>         iio_device_unregister(idev);
> -       at91_adc_trigger_remove(idev);
> -       at91_adc_buffer_remove(idev);
> +       if (!st->touchscreen_type) {
> +               at91_adc_trigger_remove(idev);
> +               at91_adc_buffer_remove(idev);
> +       } else {
> +               at91_ts_unregister(st);
> +       }
>         clk_disable_unprepare(st->adc_clk);
>         clk_disable_unprepare(st->clk);
>         free_irq(st->irq, idev);
> @@ -861,7 +1202,7 @@ static struct platform_driver at91_adc_driver = {
>         .probe = at91_adc_probe,
>         .remove = at91_adc_remove,
>         .driver = {
> -                  .name = "at91_adc",
> +                  .name = DRIVER_NAME,
>                    .of_match_table = of_match_ptr(at91_adc_dt_ids),
>         },
>  };
> --
> 1.7.10
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From xvzhaobin at gmail.com  Mon Jul 22 09:28:50 2013
From: xvzhaobin at gmail.com (zhaobin xv)
Date: Mon, 22 Jul 2013 21:28:50 +0800
Subject: linux setup
Message-ID: <CANEcUBXMPhTjgVYbRN7NY+EUjh7DDGpKnZ8_LXY-ZLcfbH65Ug@mail.gmail.com>

Hi
I recently read lernel source .
I have a question:In
folder:linux/arch/arm/boot/compressed/head.S(linux2.6.22.6):


start:
        .type    start,#function
        .rept    8
        mov    r0, r0
        .endr

        b    1f
        .word    0x016f2818        @ Magic numbers to help the loader
        .word    start            @ absolute load/run zImage address
        .word    _edata            @ zImage end address
1:        mov    r7, r1            @ save architecture ID
        mov    r8, r2            @ save atags pointer


I don't kown why the ?mov r0 r0 ? repeated  emergence 8 times.


From sergei.shtylyov at cogentembedded.com  Mon Jul 22 09:30:25 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 22 Jul 2013 17:30:25 +0400
Subject: [PATCH] ARM: OMAP3EVM: Marking omap3_evm_display_init() with
 CONFIG_BROKEN
In-Reply-To: <alpine.DEB.2.02.1307220523380.4804@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307220523380.4804@utopia.booyaka.com>
Message-ID: <51ED33F1.4000801@cogentembedded.com>

Hello.

On 22-07-2013 9:29, Paul Walmsley wrote:

> From: Lokesh Vutla <lokeshvutla at ti.com>

> On 37xx EVM non-dt boot fails with current mainline,
> because of broken GPIO numbering in the board file
> that uses hardcoded GPIOs.

> So marking omap3_evm_display_init() with CONFIG_BROKEN
> for now as suggested by Tony as per the below link:
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg90399.html

> Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
> Tested-by: Paul Walmsley <paul at pwsan.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>

> ---

> Hi -stablers,

> OMAP37xx EVM does not boot on v3.10 without this patch, so please consider
> it for the v3.10 stable releases.  It is upstream already as commit ID
> 8fb61e8d84e673eebf31e564a83bb71a50b1ed48.  Perhaps if I had managed to
> test it sooner, we could have gotten it up during v3.10-rc, but, alas,
> stable it is...

>   arch/arm/mach-omap2/board-omap3evm.c |    4 ++++
>   1 file changed, 4 insertions(+)

> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
> index f76d0de..278bf25 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -174,6 +174,7 @@ static struct panel_sharp_ls037v7dw01_data omap3_evm_lcd_data = {
>   	.ud_gpio = OMAP3EVM_LCD_PANEL_UD,
>   };
>
> +#ifdef CONFIG_BROKEN
>   static void __init omap3_evm_display_init(void)
>   {
>   	int r;
> @@ -193,6 +194,7 @@ static void __init omap3_evm_display_init(void)
>   	else
>   		gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
>   }

    Perhaps it's better to follow what Documentation/SubmittingPatches suggests:

#else
static inline __init void omap3_evm_display_init(void) {}

> +#endif
>
>   static struct omap_dss_device omap3_evm_lcd_device = {
>   	.name			= "lcd",
> @@ -715,7 +717,9 @@ static void __init omap3_evm_init(void)
>
>   	omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
>   	omap3evm_init_smsc911x();
> +#ifdef CONFIG_BROKEN
>   	omap3_evm_display_init();
> +#endif

    ... and eliminate #ifdef here?

WBR, Sergei



From xvzhaobin at gmail.com  Mon Jul 22 09:30:44 2013
From: xvzhaobin at gmail.com (zhaobin xv)
Date: Mon, 22 Jul 2013 21:30:44 +0800
Subject: linux startup
Message-ID: <CANEcUBWUFA=nmoCOUbLPa=vfbfcaqaC=FStG_4hgk1oHR+mgYg@mail.gmail.com>

Hi
I recently read lernel source .
I have a question:In
folder:linux/arch/arm/boot/compressed/head.S(linux2.6.22.6):


start:
        .type    start,#function
        .rept    8
        mov    r0, r0
        .endr

        b    1f
        .word    0x016f2818        @ Magic numbers to help the loader
        .word    start            @ absolute load/run zImage address
        .word    _edata            @ zImage end address
1:        mov    r7, r1            @ save architecture ID
        mov    r8, r2            @ save atags pointer


I don't kown why the ?mov r0 r0 ? repeated  emergence 8 times.


From inki.dae at samsung.com  Mon Jul 22 09:31:42 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Mon, 22 Jul 2013 22:31:42 +0900
Subject: [PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
In-Reply-To: <1374497212.4456.4.camel@weser.hi.pengutronix.de>
References: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
 <1374475767-30085-3-git-send-email-chanho61.park@samsung.com>
 <20130722084817.GA18731@e106331-lin.cambridge.arm.com>
 <026001ce86d8$2963d730$7c2b8590$%dae@samsung.com>
 <1374497212.4456.4.camel@weser.hi.pengutronix.de>
Message-ID: <027201ce86df$cd883d90$6898b8b0$%dae@samsung.com>



> -----Original Message-----
> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
> owner at vger.kernel.org] On Behalf Of Lucas Stach
> Sent: Monday, July 22, 2013 9:47 PM
> To: Inki Dae
> Cc: 'Mark Rutland'; 'Chanho Park'; linux-samsung-soc at vger.kernel.org;
> devicetree-discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> devel at lists.freedesktop.org; kyungmin.park at samsung.com;
> kgene.kim at samsung.com; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
> rotator
> 
> Am Montag, den 22.07.2013, 21:37 +0900 schrieb Inki Dae:
> >
> > > -----Original Message-----
> > > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > > Sent: Monday, July 22, 2013 5:48 PM
> > > To: Chanho Park
> > > Cc: inki.dae at samsung.com; kgene.kim at samsung.com; linux-samsung-
> > > soc at vger.kernel.org; jy0922.shim at samsung.com; devicetree-
> > > discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> > > devel at lists.freedesktop.org; kyungmin.park at samsung.com; linux-arm-
> > > kernel at lists.infradead.org
> > > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
> > > rotator
> > >
> > > On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> > > > This patch adds a dt-binding document for exynos rotator. It
> describes
> > > which
> > > > nodes should be defined to use the rotator.
> > > >
> > > > Signed-off-by: Chanho Park <chanho61.park at samsung.com>
> > > > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> > > > ---
> > > >  .../bindings/drm/exynos/samsung-rotator.txt        |   35
> > > ++++++++++++++++++++
> > > >  1 file changed, 35 insertions(+)
> > > >  create mode 100644
> > > Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-
> > > rotator.txt b/Documentation/devicetree/bindings/drm/exynos/samsung-
> > > rotator.txt
> > > > new file mode 100644
> > > > index 0000000..6b1d704
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/drm/exynos/samsung-
> rotator.txt
> > > > @@ -0,0 +1,35 @@
> > > > +* Samsung Image Rotator
> > > > +
> > > > +Required properties:
> > > > +  - compatible : value should be the "samsung,exynos4210".
> >
> > Please, add more compatible strings for other SoC.
> >
> > > > +  - reg : Physical base address of the IP registers and length of
> > > memory
> > > > +	  mapped region.
> > > > +  - interrupts : interrupt number to the CPU.
> > > > +  - clocks : clock number of exynos4 rotator clock.
> > > > +  - clocks : clock name of rotator
> > >
> > > clock-names?
> > >
> > > > +  - status : "okay" or "disabled"
> > > > +  - limit table for image formats : min_w/min_h/max_w/max_h for
> min/max
> > > of image
> > >
> > > Limit table? This doesn't seem to be a well-defined binding, and it
> > > seems like a relatively generic thing to describe.
> > >
> > > > +
> > > > +Example:
> > > > +	rotator: rotator at 12810000 {
> > > > +		compatible = "samsung,exynos4210-rotator";
> > > > +		reg = <0x12810000 0x1000>;
> > > > +		interrupts = <0 83 0>;
> > > > +		clocks = <&clock 278>;
> > > > +		clock-names = "rotator";
> > > > +		status = "disabled";
> > > > +		ycbcr420_2p {
> > >
> > > Which names are allowed for these subnodes?
> > >
> > > > +			min_w = <32>;
> > > > +			min_h = <32>;
> > > > +			max_w = <32768>;
> > > > +			max_h = <32768>;
> > > > +			align = <3>;
> > >
> > > min-width, min-height, max-width, max-height? What units are they in?
> > >
> > > What does alignment specify exactly?
> > >
> > > Are these a configurable part of the rotator hardware, or are these
> > > values always the same?
> >
> > Right, that seems like configurable part. At least, min_w/h and max_w/h
> can
> > be different values according to SoC and pixel formats so they should be
> > described enough in this dt-binding document file.
> >
> Is there really this much configurability? Could each of those values be
> a different on different SoCs

Not much but Yes. Rotator devices of Exynos SoC support various pixel formats; RGB888, RGB565, YUV422, YUV420-2Plane, and YUV420-3Plane, and each of these pixel formats could be different limitation to minimum and maximum sizes.
For example, the below shows the limitation to Rotator device of Exynos4412 SoC according to pixel formats,
         Image format          Minimum size          Maximum size
          RGB888                    8x8                     8kx8k
          RGB565                    16x16                  16kx16k
          YUV422                    16x16                  16kx16k
          YUV420 2-Plane         32x32                  32kx32k(in case of Y components)
          YUV420 3-Plane         64x32                  32kx32k(in case of Y components)

And, I guess those limitations are slightly different according to Exynos SoC versions as long as I know.

Thanks,
Inki Dae

> , or could you just extract those values
> from the SoC/rotator hardware version and thus the DT compatible string?
> 
> >
> > > If thery're always the same, there's no need to
> > > describe in in the devicetree.
> > >
> > > Thanks,
> > > Mark.
> > >
> > > > +		};
> > > > +		rgb888 {
> > > > +			min_w = <8>;
> > > > +			min_h = <8>;
> > > > +			max_w = <8192>;
> > > > +			max_h = <8192>;
> > > > +			align = <2>;
> > > > +		};
> > > > +	};
> > > > --
> > > > 1.7.9.5
> > > >
> > > >
> > > > _______________________________________________
> > > > linux-arm-kernel mailing list
> > > > linux-arm-kernel at lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > > >
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> --
> Pengutronix e.K.                           | Lucas Stach                 |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From lee.jones at linaro.org  Mon Jul 22 09:38:52 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 14:38:52 +0100
Subject: [PATCH 05/22] ARM: dts: bcm281xx: Remove '0x's from BCM11351 BRT
 DTS file
In-Reply-To: <51ED2D90.4020209@broadcom.com>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-5-git-send-email-lee.jones@linaro.org>
 <51ED2D90.4020209@broadcom.com>
Message-ID: <20130722133852.GA26801@laptop>

On Mon, 22 Jul 2013, Christian Daudt wrote:

> On 13-07-22 03:52 AM, Lee Jones wrote:
> >Cc: Christian Daudt <csd at broadcom.com>
> >Signed-off-by: Lee Jones <lee.jones at linaro.org>
> >---
> >  arch/arm/boot/dts/bcm11351-brt.dts | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> >diff --git a/arch/arm/boot/dts/bcm11351-brt.dts b/arch/arm/boot/dts/bcm11351-brt.dts
> >index 67ec524..fdace5d 100644
> >--- a/arch/arm/boot/dts/bcm11351-brt.dts
> >+++ b/arch/arm/boot/dts/bcm11351-brt.dts
> >@@ -27,18 +27,18 @@
> >  		status = "okay";
> >  	};
> >-	sdio0: sdio at 0x3f180000 {
> >+	sdio0: sdio at 3f180000 {
> >  		max-frequency = <48000000>;
> >  		status = "okay";
> >  	};
> >-	sdio1: sdio at 0x3f190000 {
> >+	sdio1: sdio at 3f190000 {
> >  		non-removable;
> >  		max-frequency = <48000000>;
> >  		status = "okay";
> >  	};
> >-	sdio3: sdio at 0x3f1b0000 {
> >+	sdio3: sdio at 3f1b0000 {
> >  		max-frequency = <48000000>;
> >  		status = "okay";
> >  	};
> Hi Lee,
>  Is this convention documented ? Someone called my attention to the
> fact that this dts files was inconsistent in its use of 0x in names,
> but I was not aware of a coding guideline for this.

The best two places I can think of are:

Documentation/devicetree/usage-model.txt
and
http://www.devicetree.org/Device_Tree_Usage

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Mon Jul 22 09:41:07 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 22 Jul 2013 14:41:07 +0100
Subject: [PATCH 01/22] ARM: ux500: Remove '0x's from HREF v60+ DTS file
In-Reply-To: <51ED26C6.6000004@newflow.co.uk>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <51ED26C6.6000004@newflow.co.uk>
Message-ID: <20130722134107.GB26801@laptop>

On Mon, 22 Jul 2013, Mark Jackson wrote:

> On 22/07/13 11:52, Lee Jones wrote:
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > ---
> >  arch/arm/boot/dts/hrefv60plus.dts | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/hrefv60plus.dts b/arch/arm/boot/dts/hrefv60plus.dts
> > index 3d580d6..46fd8af 100644
> > --- a/arch/arm/boot/dts/hrefv60plus.dts
> > +++ b/arch/arm/boot/dts/hrefv60plus.dts
> > @@ -26,7 +26,7 @@
> >  
> >  	soc {
> >  		i2c at 80110000 {
> > -			bu21013_tp at 0x5c {
> > +			bu21013_tp at 5c {
> 
> Just a query ... why this one .... ^^^ ...
> 
> >  				reset-gpio = <&gpio4 15 0x4>;
> 
> ... and not this one .................................. ^^^ ?
> 
> >  			};
> >  		};
> > 
> 
> The same for all the other patches in this series.
> 
> If this is by design, it might be worth mentioning why some are
> removed and not others.

I can't explain why there seems to be inconsistencies between node
names and the remaining properties. The best I can do is refer you to
the documentation where you can see that this is the standard:

Documentation/devicetree/usage-model.txt
and
http://www.devicetree.org/Device_Tree_Usage


-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From mpfj-list at newflow.co.uk  Mon Jul 22 09:43:31 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Mon, 22 Jul 2013 14:43:31 +0100
Subject: [PATCH 01/22] ARM: ux500: Remove '0x's from HREF v60+ DTS file
In-Reply-To: <20130722134107.GB26801@laptop>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <51ED26C6.6000004@newflow.co.uk> <20130722134107.GB26801@laptop>
Message-ID: <51ED3703.9060703@newflow.co.uk>

On 22/07/13 14:41, Lee Jones wrote:
> On Mon, 22 Jul 2013, Mark Jackson wrote:
> 
>> On 22/07/13 11:52, Lee Jones wrote:
>>> Signed-off-by: Lee Jones <lee.jones at linaro.org>
>>> ---
>>>  arch/arm/boot/dts/hrefv60plus.dts | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/hrefv60plus.dts b/arch/arm/boot/dts/hrefv60plus.dts
>>> index 3d580d6..46fd8af 100644
>>> --- a/arch/arm/boot/dts/hrefv60plus.dts
>>> +++ b/arch/arm/boot/dts/hrefv60plus.dts
>>> @@ -26,7 +26,7 @@
>>>  
>>>  	soc {
>>>  		i2c at 80110000 {
>>> -			bu21013_tp at 0x5c {
>>> +			bu21013_tp at 5c {
>>
>> Just a query ... why this one .... ^^^ ...
>>
>>>  				reset-gpio = <&gpio4 15 0x4>;
>>
>> ... and not this one .................................. ^^^ ?
>>
>>>  			};
>>>  		};
>>>
>>
>> The same for all the other patches in this series.
>>
>> If this is by design, it might be worth mentioning why some are
>> removed and not others.
> 
> I can't explain why there seems to be inconsistencies between node
> names and the remaining properties. The best I can do is refer you to
> the documentation where you can see that this is the standard:
> 
> Documentation/devicetree/usage-model.txt
> and
> http://www.devicetree.org/Device_Tree_Usage

Ho, ho ... don't you just love "standards" !!



From will.deacon at arm.com  Mon Jul 22 09:45:15 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 22 Jul 2013 14:45:15 +0100
Subject: [PATCH] ARM: bugfix: Features of /proc/cpuinfo is wrong
In-Reply-To: <20130718155115.GC9733@mudshark.cambridge.arm.com>
References: <1374043709-24770-1-git-send-email-koba@kmckk.co.jp>
 <20130718155115.GC9733@mudshark.cambridge.arm.com>
Message-ID: <20130722134515.GB30857@mudshark.cambridge.arm.com>

On Thu, Jul 18, 2013 at 04:51:15PM +0100, Will Deacon wrote:
> On Wed, Jul 17, 2013 at 07:48:29AM +0100, Tetsuyuki Kobayashi wrote:
> > Array hwcap_str[19] should be "vfpd32" and hwcap_str[20] should be "lpae".
> > But actually "vfpd32" was missing and "lpae" was at wrong place.
> > 
> > Signed-off-by: Tetsuyuki Kobayashi <koba at kmckk.co.jp>
> 
> [...]
> 
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 63af9a7..96286cb 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -971,6 +971,7 @@ static const char *hwcap_str[] = {
> >  	"vfpv4",
> >  	"idiva",
> >  	"idivt",
> > +	"vfpd32",
> >  	"lpae",
> >  	NULL
> >  };
> > -- 
> 
> Acked-by: Will Deacon <will.deacon at arm.com>
> 
> Please can you put this into the patch system? It needs to get in for 3.11.

I still can't see this in the patch system. I've tested it on A5, A7, A9 and
A15 and it works as expected.

Will


From linux at arm.linux.org.uk  Mon Jul 22 09:46:59 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Jul 2013 14:46:59 +0100
Subject: linux startup
In-Reply-To: <CANEcUBWUFA=nmoCOUbLPa=vfbfcaqaC=FStG_4hgk1oHR+mgYg@mail.gmail.com>
References: <CANEcUBWUFA=nmoCOUbLPa=vfbfcaqaC=FStG_4hgk1oHR+mgYg@mail.gmail.com>
Message-ID: <20130722134659.GM24642@n2100.arm.linux.org.uk>

On Mon, Jul 22, 2013 at 09:30:44PM +0800, zhaobin xv wrote:
> Hi
> I recently read lernel source .
> I have a question:In
> folder:linux/arch/arm/boot/compressed/head.S(linux2.6.22.6):
> 
> 
> start:
>         .type    start,#function
>         .rept    8
>         mov    r0, r0
>         .endr
> 
>         b    1f
>         .word    0x016f2818        @ Magic numbers to help the loader
>         .word    start            @ absolute load/run zImage address
>         .word    _edata            @ zImage end address
> 1:        mov    r7, r1            @ save architecture ID
>         mov    r8, r2            @ save atags pointer
> 
> 
> I don't kown why the ?mov r0 r0 ? repeated  emergence 8 times.

(a) boot loaders used to call the kernel at an offset of 32 bytes into
the image, but now call at the start of the image.
(b) the magic numbers are placed at a fixed position.

So we need to fill the first 8 words with something.  They could have
all been branches to '1f' instead of that instruction.  It makes little
difference.


From mark.rutland at arm.com  Mon Jul 22 09:49:34 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Jul 2013 14:49:34 +0100
Subject: [PATCH v3] xen/arm: enable PV control for ARM
In-Reply-To: <1374490654-13373-1-git-send-email-julien.grall@linaro.org>
References: <1374490654-13373-1-git-send-email-julien.grall@linaro.org>
Message-ID: <20130722134934.GB32221@e106331-lin.cambridge.arm.com>

Hi,

[Adding Catalin to Cc]

On Mon, Jul 22, 2013 at 11:57:34AM +0100, Julien Grall wrote:
> Enable power management from the toolstack for ARM guest.
> 
> Signed-off-by: Julien Grall <julien.grall at linaro.org>
> 
> ---
>     Changes in v3:
>         - Fix condition to compile cpu_hotplug.o
>     Changes in v2:
>         - Don't compile xen/cpu_hotplug.o with ARM64

My arm64 cpu hotplug series is going to be dependent on not compiling
xen/cpu_hotplug.o. Currently I'm not able to compile an arm64 kernel
with my patches and Xen support.

How do you intend to push this? I'd like to ensure my cpu hotplug series
is able to go in for the next merge window.

> ---
>  drivers/xen/Makefile |    5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 2bf461a..f185e8d 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -1,9 +1,8 @@
> -ifneq ($(CONFIG_ARM),y)
> -obj-y	+= manage.o
> +ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>  endif

Might it make sense to enable this based on a list the architectures
that actually need this, rather than disabling it based on the list of
architectures that don't?

Thanks,
Mark.

>  obj-$(CONFIG_X86)			+= fallback.o
> -obj-y	+= grant-table.o features.o events.o balloon.o time.o
> +obj-y	+= grant-table.o features.o events.o balloon.o time.o manage.o
>  obj-y	+= xenbus/
>  
>  nostackp := $(call cc-option, -fno-stack-protector)
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From raghavendra.kt at linux.vnet.ibm.com  Mon Jul 22 09:57:58 2013
From: raghavendra.kt at linux.vnet.ibm.com (Raghavendra K T)
Date: Mon, 22 Jul 2013 19:27:58 +0530
Subject: [PATCH 3/4] arm64: KVM: let other tasks run when hitting WFE
In-Reply-To: <CAMJs5B8Sg1MPHPsRV75mmagnYxkhzA0MKWVkwW2y0WdDVWTSxQ@mail.gmail.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
 <CAC4Lta17bmNjBck6LzziBeU0Xc36F1Jms2tQPv6+GaXvik6Wyg@mail.gmail.com>
 <CAMJs5B8Sg1MPHPsRV75mmagnYxkhzA0MKWVkwW2y0WdDVWTSxQ@mail.gmail.com>
Message-ID: <51ED3A66.4050407@linux.vnet.ibm.com>

On 07/22/2013 06:21 PM, Christoffer Dall wrote:
> On 22 July 2013 10:53, Raghavendra KT <raghavendra.kt.linux at gmail.com> wrote:
>> On Fri, Jul 19, 2013 at 7:23 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>> So far, when a guest executes WFE (like when waiting for a spinlock
>>> to become unlocked), we don't do a thing and let it run uninterrupted.
>>>
>>> Another option is to trap a blocking WFE and offer the opportunity
>>> to the scheduler to switch to another task, potentially giving the
>>> vcpu holding the spinlock a chance to run sooner.
>>>
>>
>> Idea looks to be correct from my experiments on x86. It does bring some
>> percentage of benefits in overcommitted guests. Infact,
>>
>> https://lkml.org/lkml/2013/7/22/41 tries to do the same thing for x86.
>> (this results in using ple handler heuristics in vcpu_block pach).
>
> What about the adverse effect in the non-overcommitted case?
>

Ideally is should fail to schedule any other task and comeback to halt
loop. This should not hurt AFAICS. But I agree that, numbers needed to
support this argument.

For x86, I had seen no side effects with the experiments.



From arend at broadcom.com  Mon Jul 22 09:53:53 2013
From: arend at broadcom.com (Arend van Spriel)
Date: Mon, 22 Jul 2013 15:53:53 +0200
Subject: [PATCH 05/22] ARM: dts: bcm281xx: Remove '0x's from
 BCM11351 BRT DTS file
In-Reply-To: <20130722133852.GA26801@laptop>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-5-git-send-email-lee.jones@linaro.org>
 <51ED2D90.4020209@broadcom.com> <20130722133852.GA26801@laptop>
Message-ID: <51ED3971.905@broadcom.com>

On 07/22/2013 03:38 PM, Lee Jones wrote:
> On Mon, 22 Jul 2013, Christian Daudt wrote:
>
>> On 13-07-22 03:52 AM, Lee Jones wrote:
>>> Cc: Christian Daudt <csd at broadcom.com>
>>> Signed-off-by: Lee Jones <lee.jones at linaro.org>
>>> ---
>>>   arch/arm/boot/dts/bcm11351-brt.dts | 6 +++---
>>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/bcm11351-brt.dts b/arch/arm/boot/dts/bcm11351-brt.dts
>>> index 67ec524..fdace5d 100644
>>> --- a/arch/arm/boot/dts/bcm11351-brt.dts
>>> +++ b/arch/arm/boot/dts/bcm11351-brt.dts
>>> @@ -27,18 +27,18 @@
>>>   		status = "okay";
>>>   	};
>>> -	sdio0: sdio at 0x3f180000 {
>>> +	sdio0: sdio at 3f180000 {
>>>   		max-frequency = <48000000>;
>>>   		status = "okay";
>>>   	};
>>> -	sdio1: sdio at 0x3f190000 {
>>> +	sdio1: sdio at 3f190000 {
>>>   		non-removable;
>>>   		max-frequency = <48000000>;
>>>   		status = "okay";
>>>   	};
>>> -	sdio3: sdio at 0x3f1b0000 {
>>> +	sdio3: sdio at 3f1b0000 {
>>>   		max-frequency = <48000000>;
>>>   		status = "okay";
>>>   	};
>> Hi Lee,
>>   Is this convention documented ? Someone called my attention to the
>> fact that this dts files was inconsistent in its use of 0x in names,
>> but I was not aware of a coding guideline for this.
>
> The best two places I can think of are:
>
> Documentation/devicetree/usage-model.txt
> and
> http://www.devicetree.org/Device_Tree_Usage

And even those do not stick to a single convention, but that is what can 
be expected of a twiki page :-p

Regards,
Arend




From rric at kernel.org  Mon Jul 22 09:56:39 2013
From: rric at kernel.org (Robert Richter)
Date: Mon, 22 Jul 2013 15:56:39 +0200
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y
In-Reply-To: <20130721213753.GA29879@mudshark.cambridge.arm.com>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
 <20130715135420.GG10000@mudshark.cambridge.arm.com>
 <20130720044655.GC9433@mozilla.com>
 <20130721213753.GA29879@mudshark.cambridge.arm.com>
Message-ID: <20130722135639.GA6927@rric.localhost>

On 21.07.13 22:37:53, Will Deacon wrote:
> Ok, I think I'm with you now. I also think that a better solution would be
> to try and limit the r7/fp confusion to one place, perhaps behind something
> like:
> 
> void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);

In unwind_backtrace() there is already common code to do this and also
to get it from a task_struct. This could be ripped out. I would prefer
then the following function:

 void init_stackframe(struct stackframe *frame, struct pt_regs *regs,
      		      struct task_struct *tsk)

-Robert


From s.nawrocki at samsung.com  Mon Jul 22 10:00:22 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 22 Jul 2013 16:00:22 +0200
Subject: [PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
In-Reply-To: <027201ce86df$cd883d90$6898b8b0$%dae@samsung.com>
References: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
 <1374475767-30085-3-git-send-email-chanho61.park@samsung.com>
 <20130722084817.GA18731@e106331-lin.cambridge.arm.com>
 <026001ce86d8$2963d730$7c2b8590$%dae@samsung.com>
 <1374497212.4456.4.camel@weser.hi.pengutronix.de>
 <027201ce86df$cd883d90$6898b8b0$%dae@samsung.com>
Message-ID: <51ED3AF6.3090004@samsung.com>

On 07/22/2013 03:31 PM, Inki Dae wrote:
>> ---Original Message-----
>> > From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
>> > owner at vger.kernel.org] On Behalf Of Lucas Stach
>> > Sent: Monday, July 22, 2013 9:47 PM
>> > To: Inki Dae
>> > Cc: 'Mark Rutland'; 'Chanho Park'; linux-samsung-soc at vger.kernel.org;
>> > devicetree-discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
>> > devel at lists.freedesktop.org; kyungmin.park at samsung.com;
>> > kgene.kim at samsung.com; linux-arm-kernel at lists.infradead.org
>> > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
>> > rotator
>> > 
>> > Am Montag, den 22.07.2013, 21:37 +0900 schrieb Inki Dae:
>>> > >
>>>> > > > -----Original Message-----
>>>> > > > From: Mark Rutland [mailto:mark.rutland at arm.com]
>>>> > > > Sent: Monday, July 22, 2013 5:48 PM
>>>> > > > To: Chanho Park
>>>> > > > Cc: inki.dae at samsung.com; kgene.kim at samsung.com; linux-samsung-
>>>> > > > soc at vger.kernel.org; jy0922.shim at samsung.com; devicetree-
>>>> > > > discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
>>>> > > > devel at lists.freedesktop.org; kyungmin.park at samsung.com; linux-arm-
>>>> > > > kernel at lists.infradead.org
>>>> > > > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
>>>> > > > rotator
>>>> > > >
>>>> > > > On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
>>>>> > > > > This patch adds a dt-binding document for exynos rotator. It
>> > describes
>>>> > > > which
>>>>> > > > > nodes should be defined to use the rotator.
>>>>> > > > >
>>>>> > > > > Signed-off-by: Chanho Park <chanho61.park at samsung.com>
>>>>> > > > > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
>>>>> > > > > ---
>>>>> > > > >  .../bindings/drm/exynos/samsung-rotator.txt        |   35
>>>> > > > ++++++++++++++++++++
>>>>> > > > >  1 file changed, 35 insertions(+)
>>>>> > > > >  create mode 100644
>>>> > > > Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
>>>>> > > > >
>>>>> > > > > diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-
>>>> > > > rotator.txt b/Documentation/devicetree/bindings/drm/exynos/samsung-
>>>> > > > rotator.txt
>>>>> > > > > new file mode 100644
>>>>> > > > > index 0000000..6b1d704
>>>>> > > > > --- /dev/null
>>>>> > > > > +++ b/Documentation/devicetree/bindings/drm/exynos/samsung-
>> > rotator.txt
>>>>> > > > > @@ -0,0 +1,35 @@
>>>>> > > > > +* Samsung Image Rotator
>>>>> > > > > +
>>>>> > > > > +Required properties:
>>>>> > > > > +  - compatible : value should be the "samsung,exynos4210".
>>> > >
>>> > > Please, add more compatible strings for other SoC.
>>> > >
>>>>> > > > > +  - reg : Physical base address of the IP registers and length of
>>>> > > > memory
>>>>> > > > > +	  mapped region.
>>>>> > > > > +  - interrupts : interrupt number to the CPU.
>>>>> > > > > +  - clocks : clock number of exynos4 rotator clock.
>>>>> > > > > +  - clocks : clock name of rotator
>>>> > > >
>>>> > > > clock-names?
>>>> > > >
>>>>> > > > > +  - status : "okay" or "disabled"
>>>>> > > > > +  - limit table for image formats : min_w/min_h/max_w/max_h for
>> > min/max
>>>> > > > of image
>>>> > > >
>>>> > > > Limit table? This doesn't seem to be a well-defined binding, and it
>>>> > > > seems like a relatively generic thing to describe.
>>>> > > >
>>>>> > > > > +
>>>>> > > > > +Example:
>>>>> > > > > +	rotator: rotator at 12810000 {
>>>>> > > > > +		compatible = "samsung,exynos4210-rotator";
>>>>> > > > > +		reg = <0x12810000 0x1000>;
>>>>> > > > > +		interrupts = <0 83 0>;
>>>>> > > > > +		clocks = <&clock 278>;
>>>>> > > > > +		clock-names = "rotator";
>>>>> > > > > +		status = "disabled";
>>>>> > > > > +		ycbcr420_2p {
>>>> > > >
>>>> > > > Which names are allowed for these subnodes?
>>>> > > >
>>>>> > > > > +			min_w = <32>;
>>>>> > > > > +			min_h = <32>;
>>>>> > > > > +			max_w = <32768>;
>>>>> > > > > +			max_h = <32768>;
>>>>> > > > > +			align = <3>;
>>>> > > >
>>>> > > > min-width, min-height, max-width, max-height? What units are they in?
>>>> > > >
>>>> > > > What does alignment specify exactly?
>>>> > > >
>>>> > > > Are these a configurable part of the rotator hardware, or are these
>>>> > > > values always the same?
>>> > >
>>> > > Right, that seems like configurable part. At least, min_w/h and max_w/h
>> > can
>>> > > be different values according to SoC and pixel formats so they should be
>>> > > described enough in this dt-binding document file.
>>> > >
>> > Is there really this much configurability? Could each of those values be
>> > a different on different SoCs
> Not much but Yes. Rotator devices of Exynos SoC support various pixel formats; RGB888, RGB565, YUV422, YUV420-2Plane, and YUV420-3Plane, and each of these pixel formats could be different limitation to minimum and maximum sizes.
> For example, the below shows the limitation to Rotator device of Exynos4412 SoC according to pixel formats,
>          Image format          Minimum size          Maximum size
>           RGB888                    8x8                     8kx8k
>           RGB565                    16x16                  16kx16k
>           YUV422                    16x16                  16kx16k
>           YUV420 2-Plane         32x32                  32kx32k(in case of Y components)
>           YUV420 3-Plane         64x32                  32kx32k(in case of Y components)
> 
> And, I guess those limitations are slightly different according to Exynos SoC versions as long as I know.
> 
> Thanks,
> Inki Dae
> 
>> > , or could you just extract those values
>> > from the SoC/rotator hardware version and thus the DT compatible string?

My gut feeling is that those constraints could be well defined 
in the driver as static data and selected by the compatible property. 
Defining this in Device Tree may easily get out of control, when the 
limits become dependant on more parameters.

Whether devices should be described in much detail in DT rather than
using multiple compatible strings had been discussed multiple times, 
for instance please see thread [1].

Regards,
Sylwester

[1] http://www.mail-archive.com/devicetree-discuss at lists.ozlabs.org/msg36691.html



From broonie at kernel.org  Mon Jul 22 10:09:04 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 22 Jul 2013 15:09:04 +0100
Subject: [PATCH v3 01/31] spi: mpc512x: cleanup clock API use
In-Reply-To: <1374495298-22019-2-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
 <1374495298-22019-2-git-send-email-gsi@denx.de>
Message-ID: <20130722140904.GU9858@sirena.org.uk>

On Mon, Jul 22, 2013 at 02:14:28PM +0200, Gerhard Sittig wrote:

> +	ret = clk_prepare_enable(clk);
> +	if (ret) {
> +		devm_clk_put(dev, clk);
> +		goto free_irq;

The main point of the devm_ APIs is to avoid the need for explicit
freeing so you should just remove these puts.
-------------- 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/20130722/d3cc5152/attachment.sig>

From stefano.stabellini at eu.citrix.com  Mon Jul 22 10:09:10 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 22 Jul 2013 15:09:10 +0100
Subject: [PATCH v3] xen/arm: enable PV control for ARM
In-Reply-To: <1374490654-13373-1-git-send-email-julien.grall@linaro.org>
References: <1374490654-13373-1-git-send-email-julien.grall@linaro.org>
Message-ID: <alpine.DEB.2.02.1307221508260.4893@kaball.uk.xensource.com>

On Mon, 22 Jul 2013, Julien Grall wrote:
> Enable power management from the toolstack for ARM guest.
> 
> Signed-off-by: Julien Grall <julien.grall at linaro.org>
> 

Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>


>     Changes in v3:
>         - Fix condition to compile cpu_hotplug.o
>     Changes in v2:
>         - Don't compile xen/cpu_hotplug.o with ARM64
> ---
>  drivers/xen/Makefile |    5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 2bf461a..f185e8d 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -1,9 +1,8 @@
> -ifneq ($(CONFIG_ARM),y)
> -obj-y	+= manage.o
> +ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>  endif
>  obj-$(CONFIG_X86)			+= fallback.o
> -obj-y	+= grant-table.o features.o events.o balloon.o time.o
> +obj-y	+= grant-table.o features.o events.o balloon.o time.o manage.o
>  obj-y	+= xenbus/
>  
>  nostackp := $(call cc-option, -fno-stack-protector)
> -- 
> 1.7.10.4
> 


From stefano.stabellini at eu.citrix.com  Mon Jul 22 10:09:35 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 22 Jul 2013 15:09:35 +0100
Subject: [PATCH v3] xen/arm: enable PV control for ARM
In-Reply-To: <20130722134934.GB32221@e106331-lin.cambridge.arm.com>
References: <1374490654-13373-1-git-send-email-julien.grall@linaro.org>
 <20130722134934.GB32221@e106331-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1307221459200.4893@kaball.uk.xensource.com>

On Mon, 22 Jul 2013, Mark Rutland wrote:
> Hi,
> 
> [Adding Catalin to Cc]
> 
> On Mon, Jul 22, 2013 at 11:57:34AM +0100, Julien Grall wrote:
> > Enable power management from the toolstack for ARM guest.
> > 
> > Signed-off-by: Julien Grall <julien.grall at linaro.org>
> > 
> > ---
> >     Changes in v3:
> >         - Fix condition to compile cpu_hotplug.o
> >     Changes in v2:
> >         - Don't compile xen/cpu_hotplug.o with ARM64
> 
> My arm64 cpu hotplug series is going to be dependent on not compiling
> xen/cpu_hotplug.o. Currently I'm not able to compile an arm64 kernel
> with my patches and Xen support.
> 
> How do you intend to push this? I'd like to ensure my cpu hotplug series
> is able to go in for the next merge window.

This patch does exactly that: it makes sure cpu_hotplug is not compiled
on ARM64.
Given that this patch is for drivers/xen/Makefile, normally it goes via
Konrad's tree.


> > ---
> >  drivers/xen/Makefile |    5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> > index 2bf461a..f185e8d 100644
> > --- a/drivers/xen/Makefile
> > +++ b/drivers/xen/Makefile
> > @@ -1,9 +1,8 @@
> > -ifneq ($(CONFIG_ARM),y)
> > -obj-y	+= manage.o
> > +ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
> >  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
> >  endif
> 
> Might it make sense to enable this based on a list the architectures
> that actually need this, rather than disabling it based on the list of
> architectures that don't?

This is more philosophical than practical, but I would expect this
limitation to go away soon, and be able to compile cpu_hotplug without
issues on ARM and ARM64 too.


From nicolas.pitre at linaro.org  Mon Jul 22 10:14:02 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 10:14:02 -0400 (EDT)
Subject: [PATCH v3 01/16] of: add support for retrieving cpu node for a
 given logical cpu index
In-Reply-To: <1374492747-13879-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <alpine.LFD.2.03.1307221007160.15022@syhkavp.arg>

On Mon, 22 Jul 2013, Sudeep KarkadaNagesha wrote:

> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> Currently different drivers requiring to access cpu device node are
> parsing the device tree themselves. Since the ordering in the DT need
> not match the logical cpu ordering, the parsing logic needs to consider
> that. However, this has resulted in lots of code duplication and in some
> cases even incorrect logic.
> 
> It's better to consolidate them by adding support for getting cpu
> device node for a given logical cpu index in DT core library. However
> logical to physical index mapping can be architecture specific.
> 
> This patch adds of_get_cpu_node to retrieve a cpu device node for a
> given logical cpu index. The default matching of the physical id to the
> logical cpu index can be overridden by architecture specific code.
> 
> It is recommended to use these helper function only in pre-SMP/early
> initialisation stages to retrieve CPU device node pointers in logical
> ordering. Once the cpu devices are registered, it can be retrieved easily
> from cpu device of_node which avoids unnecessary parsing and matching.
> 
> Acked-by: Rob Herring <rob.herring at calxeda.com>
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Minor nits below.  Otherwise...

Acked-by: Nicolas Pitre <nico at linaro.org>

> ---
>  drivers/of/base.c  | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of.h |  6 +++++
>  2 files changed, 78 insertions(+)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 5c54279..1e690bf 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -230,6 +230,78 @@ const void *of_get_property(const struct device_node *np, const char *name,
>  }
>  EXPORT_SYMBOL(of_get_property);
>  
> +/*
> + * arch_match_cpu_phys_id - Match the given logical CPU and physical id
> + *
> + * @cpu: logical index of a cpu
> + * @phys_id: physical identifier of a cpu
> + *
> + * CPU logical to physical index mapping is architecture specific.
> + * However this __weak function provides a default match of physical
> + * id to logical cpu index.
> + *
> + * Returns true if the physical identifier and the logical index correspond
> + * to the same cpu, false otherwise.
> + */
> +bool __weak arch_match_cpu_phys_id(int cpu, u64 phys_id)

Maybe a prototype declaration for this function should be added to 
include/linux/of.h to avoid mismatch with architecture provided 
versions.

> +{
> +	return (u32)phys_id == cpu;
> +}
> +
> +/**
> + * of_get_cpu_node - Get device node associated with the given logical CPU
> + *
> + * @cpu: CPU number(logical index) for which device node is required
> + *
> + * The main purpose of this function is to retrieve the device node for the
> + * given logical CPU index. It should be used to intialize the of_node in

s/intialize/initialize/


Nicolas


From nicolas.pitre at linaro.org  Mon Jul 22 10:14:55 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 10:14:55 -0400 (EDT)
Subject: [PATCH v3 02/16] ARM: DT/kernel: define ARM specific
 arch_match_cpu_phys_id
In-Reply-To: <1374492747-13879-3-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-3-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <alpine.LFD.2.03.1307221014270.15022@syhkavp.arg>

On Mon, 22 Jul 2013, Sudeep KarkadaNagesha wrote:

> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> OF/DT core library now provides architecture specific hook to match the
> logical cpu index with the corresponding physical identifier. Most of the
> cpu DT node parsing and initialisation is contained in devtree.c. So it's
> better to define ARM specific arch_match_cpu_phys_id there.
> 
> This mainly helps to avoid replication of the code doing CPU node parsing
> and physical(MPIDR) to logical mapping.
> 
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> Acked-by: Rob Herring <rob.herring at calxeda.com>
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Acked-by: Nicolas Pitre <nico at linaro.org>


> ---
>  arch/arm/kernel/devtree.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 5859c8b..2ee8a17 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -169,6 +169,11 @@ void __init arm_dt_init_cpu_maps(void)
>  	}
>  }
>  
> +bool arch_match_cpu_phys_id(int cpu, u64 phys_id)
> +{
> +	return (phys_id & MPIDR_HWID_BITMASK) == cpu_logical_map(cpu);
> +}
> +
>  /**
>   * setup_machine_fdt - Machine setup when an dtb was passed to the kernel
>   * @dt_phys: physical address of dt blob
> -- 
> 1.8.1.2
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


From nicolas.pitre at linaro.org  Mon Jul 22 10:25:08 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 10:25:08 -0400 (EDT)
Subject: [PATCH v3 04/16] ARM: topology: remove hwid/MPIDR dependency
 from cpu_capacity
In-Reply-To: <1374492747-13879-5-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-5-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <alpine.LFD.2.03.1307221024370.15022@syhkavp.arg>

On Mon, 22 Jul 2013, Sudeep KarkadaNagesha wrote:

> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> Currently the topology code computes cpu capacity and stores it in
> the list along with hwid(which is MPIDR) as it parses the CPU nodes
> in the device tree. This is required as it needs to be mapped to the
> logical CPU later.
> 
> Since the CPU device nodes can be retrieved in the logical ordering
> using DT/OF helpers, its possible to store cpu_capacity also in logical
> ordering and avoid storing hwid for each entry.
> 
> This patch removes hwid by making use of of_get_cpu_node.
> 
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> Acked-by: Rob Herring <rob.herring at calxeda.com>
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Acked-by: Nicolas Pitre <nico at linaro.org>


> ---
>  arch/arm/kernel/topology.c | 61 +++++++++++++++-------------------------------
>  1 file changed, 19 insertions(+), 42 deletions(-)
> 
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index c5a5954..28ef27a 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -74,12 +74,8 @@ struct cpu_efficiency table_efficiency[] = {
>  	{NULL, },
>  };
>  
> -struct cpu_capacity {
> -	unsigned long hwid;
> -	unsigned long capacity;
> -};
> -
> -struct cpu_capacity *cpu_capacity;
> +unsigned long *__cpu_capacity;
> +#define cpu_capacity(cpu)	__cpu_capacity[cpu]
>  
>  unsigned long middle_capacity = 1;
>  
> @@ -100,15 +96,19 @@ static void __init parse_dt_topology(void)
>  	unsigned long capacity = 0;
>  	int alloc_size, cpu = 0;
>  
> -	alloc_size = nr_cpu_ids * sizeof(struct cpu_capacity);
> -	cpu_capacity = kzalloc(alloc_size, GFP_NOWAIT);
> +	alloc_size = nr_cpu_ids * sizeof(*__cpu_capacity);
> +	__cpu_capacity = kzalloc(alloc_size, GFP_NOWAIT);
>  
> -	while ((cn = of_find_node_by_type(cn, "cpu"))) {
> -		const u32 *rate, *reg;
> +	for_each_possible_cpu(cpu) {
> +		const u32 *rate;
>  		int len;
>  
> -		if (cpu >= num_possible_cpus())
> -			break;
> +		/* too early to use cpu->of_node */
> +		cn = of_get_cpu_node(cpu);
> +		if (!cn) {
> +			pr_err("missing device node for CPU %d\n", cpu);
> +			continue;
> +		}
>  
>  		for (cpu_eff = table_efficiency; cpu_eff->compatible; cpu_eff++)
>  			if (of_device_is_compatible(cn, cpu_eff->compatible))
> @@ -124,12 +124,6 @@ static void __init parse_dt_topology(void)
>  			continue;
>  		}
>  
> -		reg = of_get_property(cn, "reg", &len);
> -		if (!reg || len != 4) {
> -			pr_err("%s missing reg property\n", cn->full_name);
> -			continue;
> -		}
> -
>  		capacity = ((be32_to_cpup(rate)) >> 20) * cpu_eff->efficiency;
>  
>  		/* Save min capacity of the system */
> @@ -140,13 +134,9 @@ static void __init parse_dt_topology(void)
>  		if (capacity > max_capacity)
>  			max_capacity = capacity;
>  
> -		cpu_capacity[cpu].capacity = capacity;
> -		cpu_capacity[cpu++].hwid = be32_to_cpup(reg);
> +		cpu_capacity(cpu) = capacity;
>  	}
>  
> -	if (cpu < num_possible_cpus())
> -		cpu_capacity[cpu].hwid = (unsigned long)(-1);
> -
>  	/* If min and max capacities are equals, we bypass the update of the
>  	 * cpu_scale because all CPUs have the same capacity. Otherwise, we
>  	 * compute a middle_capacity factor that will ensure that the capacity
> @@ -154,9 +144,7 @@ static void __init parse_dt_topology(void)
>  	 * SCHED_POWER_SCALE, which is the default value, but with the
>  	 * constraint explained near table_efficiency[].
>  	 */
> -	if (min_capacity == max_capacity)
> -		cpu_capacity[0].hwid = (unsigned long)(-1);
> -	else if (4*max_capacity < (3*(max_capacity + min_capacity)))
> +	if (4*max_capacity < (3*(max_capacity + min_capacity)))
>  		middle_capacity = (min_capacity + max_capacity)
>  				>> (SCHED_POWER_SHIFT+1);
>  	else
> @@ -170,23 +158,12 @@ static void __init parse_dt_topology(void)
>   * boot. The update of all CPUs is in O(n^2) for heteregeneous system but the
>   * function returns directly for SMP system.
>   */
> -void update_cpu_power(unsigned int cpu, unsigned long hwid)
> +void update_cpu_power(unsigned int cpu)
>  {
> -	unsigned int idx = 0;
> -
> -	/* look for the cpu's hwid in the cpu capacity table */
> -	for (idx = 0; idx < num_possible_cpus(); idx++) {
> -		if (cpu_capacity[idx].hwid == hwid)
> -			break;
> -
> -		if (cpu_capacity[idx].hwid == -1)
> -			return;
> -	}
> -
> -	if (idx == num_possible_cpus())
> +	if (!cpu_capacity(cpu))
>  		return;
>  
> -	set_power_scale(cpu, cpu_capacity[idx].capacity / middle_capacity);
> +	set_power_scale(cpu, cpu_capacity(cpu) / middle_capacity);
>  
>  	printk(KERN_INFO "CPU%u: update cpu_power %lu\n",
>  		cpu, arch_scale_freq_power(NULL, cpu));
> @@ -194,7 +171,7 @@ void update_cpu_power(unsigned int cpu, unsigned long hwid)
>  
>  #else
>  static inline void parse_dt_topology(void) {}
> -static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {}
> +static inline void update_cpu_power(unsigned int cpuid) {}
>  #endif
>  
>   /*
> @@ -281,7 +258,7 @@ void store_cpu_topology(unsigned int cpuid)
>  
>  	update_siblings_masks(cpuid);
>  
> -	update_cpu_power(cpuid, mpidr & MPIDR_HWID_BITMASK);
> +	update_cpu_power(cpuid);
>  
>  	printk(KERN_INFO "CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n",
>  		cpuid, cpu_topology[cpuid].thread_id,
> -- 
> 1.8.1.2
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


From nicolas.pitre at linaro.org  Mon Jul 22 10:37:59 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 10:37:59 -0400 (EDT)
Subject: [PATCH v3 06/16] drivers/bus: arm-cci: avoid parsing DT for cpu
 device nodes
In-Reply-To: <1374492747-13879-7-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-7-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <alpine.LFD.2.03.1307221036510.15022@syhkavp.arg>

On Mon, 22 Jul 2013, Sudeep KarkadaNagesha wrote:

> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> Since the CPU device nodes can be retrieved using arch_of_get_cpu_node,
> we can use it to avoid parsing the cpus node searching the cpu nodes and
> mapping to logical index.
> 
> This patch removes parsing DT for cpu nodes by using of_get_cpu_node.
> 
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Acked-by: Nicolas Pitre <nico at linaro.org>


> ---
>  drivers/bus/arm-cci.c | 28 +++++++---------------------
>  1 file changed, 7 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> index 7332889..7dd891c 100644
> --- a/drivers/bus/arm-cci.c
> +++ b/drivers/bus/arm-cci.c
> @@ -122,17 +122,8 @@ EXPORT_SYMBOL_GPL(cci_ace_get_port);
>  
>  static void __init cci_ace_init_ports(void)
>  {
> -	int port, ac, cpu;
> -	u64 hwid;
> -	const u32 *cell;
> -	struct device_node *cpun, *cpus;
> -
> -	cpus = of_find_node_by_path("/cpus");
> -	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
> -		return;
> -
> -	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
> -		ac = of_n_addr_cells(cpus);
> +	int port, cpu;
> +	struct device_node *cpun;
>  
>  	/*
>  	 * Port index look-up speeds up the function disabling ports by CPU,
> @@ -141,18 +132,13 @@ static void __init cci_ace_init_ports(void)
>  	 * The stashed index array is initialized for all possible CPUs
>  	 * at probe time.
>  	 */
> -	for_each_child_of_node(cpus, cpun) {
> -		if (of_node_cmp(cpun->type, "cpu"))
> -			continue;
> -		cell = of_get_property(cpun, "reg", NULL);
> -		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
> -			continue;
> -
> -		hwid = of_read_number(cell, ac);
> -		cpu = get_logical_index(hwid & MPIDR_HWID_BITMASK);
> +	for_each_possible_cpu(cpu) {
> +		/* too early to use cpu->of_node */
> +		cpun = of_get_cpu_node(cpu);
>  
> -		if (cpu < 0 || !cpu_possible(cpu))
> +		if (WARN(!cpun, "Missing cpu device node\n"))
>  			continue;
> +
>  		port = __cci_ace_get_port(cpun, ACE_PORT);
>  		if (port < 0)
>  			continue;
> -- 
> 1.8.1.2
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


From mark.rutland at arm.com  Mon Jul 22 10:39:20 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Jul 2013 15:39:20 +0100
Subject: [PATCH v3] xen/arm: enable PV control for ARM
In-Reply-To: <alpine.DEB.2.02.1307221459200.4893@kaball.uk.xensource.com>
References: <1374490654-13373-1-git-send-email-julien.grall@linaro.org>
 <20130722134934.GB32221@e106331-lin.cambridge.arm.com>
 <alpine.DEB.2.02.1307221459200.4893@kaball.uk.xensource.com>
Message-ID: <20130722143920.GC32221@e106331-lin.cambridge.arm.com>

On Mon, Jul 22, 2013 at 03:09:35PM +0100, Stefano Stabellini wrote:
> On Mon, 22 Jul 2013, Mark Rutland wrote:
> > Hi,
> > 
> > [Adding Catalin to Cc]
> > 
> > On Mon, Jul 22, 2013 at 11:57:34AM +0100, Julien Grall wrote:
> > > Enable power management from the toolstack for ARM guest.
> > > 
> > > Signed-off-by: Julien Grall <julien.grall at linaro.org>
> > > 
> > > ---
> > >     Changes in v3:
> > >         - Fix condition to compile cpu_hotplug.o
> > >     Changes in v2:
> > >         - Don't compile xen/cpu_hotplug.o with ARM64
> > 
> > My arm64 cpu hotplug series is going to be dependent on not compiling
> > xen/cpu_hotplug.o. Currently I'm not able to compile an arm64 kernel
> > with my patches and Xen support.
> > 
> > How do you intend to push this? I'd like to ensure my cpu hotplug series
> > is able to go in for the next merge window.
> 
> This patch does exactly that: it makes sure cpu_hotplug is not compiled
> on ARM64.

Sorry, what I meant was that my series is going to be entirely dependent
on this patch or it'll break bisection. That'll make merging things a
little painful as I'll need a stable branch with this patch to base my
series upon.

Another option would be to split this patch into two parts, one enabling
power management and one fixing things up for HOTPLUG_CPU on arm64. That
way I could take the arm64 HOTPLUG_CPU fix in my series adding arm64
HOTPLUG_CPU support.

Would that be acceptable? Have I missed something?

> Given that this patch is for drivers/xen/Makefile, normally it goes via
> Konrad's tree.
> 
> 
> > > ---
> > >  drivers/xen/Makefile |    5 ++---
> > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> > > index 2bf461a..f185e8d 100644
> > > --- a/drivers/xen/Makefile
> > > +++ b/drivers/xen/Makefile
> > > @@ -1,9 +1,8 @@
> > > -ifneq ($(CONFIG_ARM),y)
> > > -obj-y	+= manage.o
> > > +ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
> > >  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
> > >  endif
> > 
> > Might it make sense to enable this based on a list the architectures
> > that actually need this, rather than disabling it based on the list of
> > architectures that don't?
> 
> This is more philosophical than practical, but I would expect this
> limitation to go away soon, and be able to compile cpu_hotplug without
> issues on ARM and ARM64 too.
> 

Ok, that's fine then.

Thanks,
Mark.


From stern at rowland.harvard.edu  Mon Jul 22 10:44:39 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Mon, 22 Jul 2013 10:44:39 -0400 (EDT)
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51ECDE5E.3050104@ti.com>
Message-ID: <Pine.LNX.4.44L0.1307221028440.1495-100000@iolanthe.rowland.org>

On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:

> > 	The PHY and the controller it is attached to are both physical
> > 	devices.
> > 
> > 	The connection between them is hardwired by the system
> > 	manufacturer and cannot be changed by software.
> > 
> > 	PHYs are generally described by fixed system-specific board
> > 	files or by Device Tree information.  Are they ever discovered
> > 	dynamically?
> 
> No. They are created just like any other platform devices are created.

Okay.  Are PHYs _always_ platform devices?

> > 	Is the same true for the controllers attached to the PHYs?
> > 	If not -- if both a PHY and a controller are discovered 
> > 	dynamically -- how does the kernel know whether they are 
> > 	connected to each other?
> 
> No differences here. Both PHY and controller will have dt information or hwmod
> data using which platform devices will be created.
> > 
> > 	The kernel needs to know which controller is attached to which
> > 	PHY.  Currently this information is represented by name or ID
> > 	strings embedded in platform data.
> 
> right. It's embedded in the platform data of the controller.

It must also be embedded in the PHY's platform data somehow.  
Otherwise, how would the kernel know which PHY to use?

> > 	The PHY's driver (the supplier) uses the platform data to 
> > 	construct a platform_device structure that represents the PHY.  
> 
> Currently the driver assigns static labels (corresponding to the label used in
> the platform data of the controller).
> > 	Until this is done, the controller's driver (the client) cannot 
> > 	use the PHY.
> 
> right.
> > 
> > 	Since there is no parent-child relation between the PHY and the 
> > 	controller, there is no guarantee that the PHY's driver will be
> > 	ready when the controller's driver wants to use it.  A deferred
> > 	probe may be needed.
> 
> right.
> > 
> > 	The issue (or one of the issues) in this discussion is that 
> > 	Greg does not like the idea of using names or IDs to associate
> > 	PHYs with controllers, because they are too prone to
> > 	duplications or other errors.  Pointers are more reliable.
> > 
> > 	But pointers to what?  Since the only data known to be 
> > 	available to both the PHY driver and controller driver is the
> > 	platform data, the obvious answer is a pointer to platform data
> > 	(either for the PHY or for the controller, or maybe both).
> 
> hmm.. it's not going to be simple though as the platform device for the PHY and
> controller can be created in entirely different places. e.g., in some cases the
> PHY device is a child of some mfd core device (the device will be created in
> drivers/mfd) and the controller driver (usually) is created in board file. I
> guess then we have to come up with something to share a pointer in two
> different files.

The ability for two different source files to share a pointer to a data 
item defined in a third source file has been around since long before 
the C language was invented.  :-)

In this case, it doesn't matter where the platform_device structures 
are created or where the driver source code is.  Let's take a simple 
example.  Suppose the system design includes a PHY named "foo".  Then 
the board file could contain:

struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);

and a header file would contain:

extern struct phy_info phy_foo;

The PHY supplier could then call phy_create(&phy_foo), and the PHY 
client could call phy_find(&phy_foo).  Or something like that; make up 
your own structure tags and function names.

It's still possible to have conflicts, but now two PHYs with the same 
name (or a misspelled name somewhere) will cause an error at link time.

> > Probably some of the details above are wrong; please indicate where I
> > have gone astray.  Also, I'm not clear about the role played by various 
> > APIs.  For example, where does phy_create() fit into this picture?
> 
> phy_create is the API by which the PHY's driver (the supplier) hook into the
> PHY framework. It's like the controller driver will always interact with the
> PHY driver through the PHY framework.

Alan Stern



From stefano.stabellini at eu.citrix.com  Mon Jul 22 10:46:34 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 22 Jul 2013 15:46:34 +0100
Subject: [PATCH v3] xen/arm: enable PV control for ARM
In-Reply-To: <20130722143920.GC32221@e106331-lin.cambridge.arm.com>
References: <1374490654-13373-1-git-send-email-julien.grall@linaro.org>
 <20130722134934.GB32221@e106331-lin.cambridge.arm.com>
 <alpine.DEB.2.02.1307221459200.4893@kaball.uk.xensource.com>
 <20130722143920.GC32221@e106331-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1307221545030.4893@kaball.uk.xensource.com>

On Mon, 22 Jul 2013, Mark Rutland wrote:
> On Mon, Jul 22, 2013 at 03:09:35PM +0100, Stefano Stabellini wrote:
> > On Mon, 22 Jul 2013, Mark Rutland wrote:
> > > Hi,
> > > 
> > > [Adding Catalin to Cc]
> > > 
> > > On Mon, Jul 22, 2013 at 11:57:34AM +0100, Julien Grall wrote:
> > > > Enable power management from the toolstack for ARM guest.
> > > > 
> > > > Signed-off-by: Julien Grall <julien.grall at linaro.org>
> > > > 
> > > > ---
> > > >     Changes in v3:
> > > >         - Fix condition to compile cpu_hotplug.o
> > > >     Changes in v2:
> > > >         - Don't compile xen/cpu_hotplug.o with ARM64
> > > 
> > > My arm64 cpu hotplug series is going to be dependent on not compiling
> > > xen/cpu_hotplug.o. Currently I'm not able to compile an arm64 kernel
> > > with my patches and Xen support.
> > > 
> > > How do you intend to push this? I'd like to ensure my cpu hotplug series
> > > is able to go in for the next merge window.
> > 
> > This patch does exactly that: it makes sure cpu_hotplug is not compiled
> > on ARM64.
> 
> Sorry, what I meant was that my series is going to be entirely dependent
> on this patch or it'll break bisection. That'll make merging things a
> little painful as I'll need a stable branch with this patch to base my
> series upon.
> 
> Another option would be to split this patch into two parts, one enabling
> power management and one fixing things up for HOTPLUG_CPU on arm64. That
> way I could take the arm64 HOTPLUG_CPU fix in my series adding arm64
> HOTPLUG_CPU support.
> 
> Would that be acceptable? Have I missed something?

As I am very sensitive to painful merging situations, I think we could
split the patch in two and send upstream the fix (not compiling
cpu_hotplug.o on ARM64) in 3.11-rc2 or rc3.  Konrad, what do you think?


From khc at pm.waw.pl  Mon Jul 22 10:49:27 2013
From: khc at pm.waw.pl (Krzysztof Halasa)
Date: Mon, 22 Jul 2013 16:49:27 +0200
Subject: [PATCH 1/2] arm: ixp4xx: set cohorent_dma_mask for ethernet
 platform devices
In-Reply-To: <1374424823.2804.25.camel@deadeye.wl.decadent.org.uk> (Ben
 Hutchings's message of "Sun, 21 Jul 2013 17:40:23 +0100")
References: <1374315339-31469-1-git-send-email-jogo@openwrt.org>
 <1374315339-31469-2-git-send-email-jogo@openwrt.org>
 <m3ip04ezty.fsf@intrepid.localdomain>
 <1374424823.2804.25.camel@deadeye.wl.decadent.org.uk>
Message-ID: <m3bo5uabuw.fsf@intrepid.localdomain>

Ben Hutchings <bhutchings at solarflare.com> writes:

> I think the problem is that the platform device and the platform data
> have not been properly separated.  The machine-specific setup functions
> should be passing the eth_plat_info and MAC ID into a common ixp4xx
> function which would then create the platform device with the correct
> DMA mask etc.

That's also my idea. Will look at this.
-- 
Krzysztof Halasa


From santosh.shilimkar at ti.com  Mon Jul 22 10:50:02 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 22 Jul 2013 10:50:02 -0400
Subject: [PATCH v2] of: Specify initrd location using 64-bit
In-Reply-To: <20130720053945.C7AC63E0C52@localhost>
References: <1372702835-5333-1-git-send-email-santosh.shilimkar@ti.com>
 <51D1F5E2.6070609@gmail.com> <20130720053945.C7AC63E0C52@localhost>
Message-ID: <51ED469A.9000801@ti.com>

On Saturday 20 July 2013 01:39 AM, Grant Likely wrote:
> On Mon, 01 Jul 2013 16:34:26 -0500, Rob Herring <robherring2 at gmail.com> wrote:
>> On 07/01/2013 01:20 PM, Santosh Shilimkar wrote:
>>> On some PAE architectures, the entire range of physical memory could reside
>>> outside the 32-bit limit.  These systems need the ability to specify the
>>> initrd location using 64-bit numbers.
>>>
>>> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
>>> use 64-bit numbers instead of the current unsigned long.
>>>
>>> There has been quite a bit of debate about whether to use u64 or phys_addr_t.
>>> It was concluded to stick to u64 to be consistent with rest of the device
>>> tree code. As summarized by Geert, "The address to load the initrd is decided
>>> by the bootloader/user and set at that point later in time. The dtb should not
>>> be tied to the kernel you are booting"
>>
>> That was quoting me. Otherwise:
>>
>> Acked-by: Rob Herring <rob.herring at calxeda.com>
>>
>> Unless Grant feels compelled to pick this up for 3.11, I think it has to
>> wait for 3.12.
> 
> Nope, 3.12 is fine. Applied.
> 
Thanks Grant.

Regards,
Santosh



From mpfj-list at newflow.co.uk  Mon Jul 22 10:52:41 2013
From: mpfj-list at newflow.co.uk (Mark Jackson)
Date: Mon, 22 Jul 2013 15:52:41 +0100
Subject: [PATCH 0/4] OMAP2+: Fix boot hang with earlycon enabled
In-Reply-To: <1374487277-26099-1-git-send-email-rnayak@ti.com>
References: <1374487277-26099-1-git-send-email-rnayak@ti.com>
Message-ID: <51ED4739.1090305@newflow.co.uk>

On 22/07/13 11:01, Rajendra Nayak wrote:
> Boot on all OMAP2+ devices is broken with earlycon enabled
> as discussed here [1]
> 
> There were 2 issues which were rootcaused
> 1. Issue caused due to hwmod doing a reset of console uart while
> earlycon was using it (seen only on am335x devices)
> 
> 2. omap serial causing a NULL context restore with context loss
> count missing.
> 
> This patch set attempts to fix both the issues and is one of the
> different approaches discussed [1] on how to fix these issues.
> 
> Boot tested on omap4 panda es with and without earlycon (DT boot)
> Boot tested on am335x bone black with and without earlycon (DT boot)
> Boot tested on OMAP3 beagle XM with and without earlycon (non-DT boot)
> 
> [1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg91662.html
> 
> Grygorii Strashko (1):
>   serial: omap: enable PM runtime only when its fully configured
> 
> Rajendra Nayak (3):
>   ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL
>   ARM: OMAP2+: Avoid idling memory controllers with no drivers
>   ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device
>     state
> 
>  arch/arm/mach-omap2/omap_device.c                  |   18 ++++++++
>  arch/arm/mach-omap2/omap_hwmod.h                   |   48 ++++++++++++++++++++
>  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |    6 +--
>  arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    2 +-
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    9 ++--
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    5 +-
>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    3 +-
>  arch/arm/mach-omap2/serial.c                       |   11 -----
>  drivers/tty/serial/omap-serial.c                   |    3 +-
>  9 files changed, 81 insertions(+), 24 deletions(-)
 
This now fixes the boot hang for me so ...

Tested-by: Mark Jackson <mpfj-list at newflow.co.uk>



From nicolas.pitre at linaro.org  Mon Jul 22 11:03:51 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 11:03:51 -0400 (EDT)
Subject: [PATCH 1/8] ARM: mm: LPAE: use phys_addr_t appropriately in p2v
 and v2p conversions
In-Reply-To: <1371858502-10083-2-git-send-email-santosh.shilimkar@ti.com>
References: <1371858502-10083-1-git-send-email-santosh.shilimkar@ti.com>
 <1371858502-10083-2-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <alpine.LFD.2.03.1307221103260.15022@syhkavp.arg>

On Fri, 21 Jun 2013, Santosh Shilimkar wrote:

> Fix remainder types used when converting back and forth between
> physical and virtual addresses.
> 
> Cc: Nicolas Pitre <nico at linaro.org>
> Cc: Will Deacon <will.deacon at arm.com>
> 
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

Acked-by: Nicolas Pitre <nico at linaro.org>



> ---
>  arch/arm/include/asm/memory.h |   22 ++++++++++++++++------
>  1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 584786f..93376e4 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -185,22 +185,32 @@ extern unsigned long __pv_phys_offset;
>  	: "=r" (to)					\
>  	: "r" (from), "I" (type))
>  
> -static inline unsigned long __virt_to_phys(unsigned long x)
> +static inline phys_addr_t __virt_to_phys(unsigned long x)
>  {
>  	unsigned long t;
>  	__pv_stub(x, t, "add", __PV_BITS_31_24);
>  	return t;
>  }
>  
> -static inline unsigned long __phys_to_virt(unsigned long x)
> +static inline unsigned long __phys_to_virt(phys_addr_t x)
>  {
>  	unsigned long t;
>  	__pv_stub(x, t, "sub", __PV_BITS_31_24);
>  	return t;
>  }
> +
>  #else
> -#define __virt_to_phys(x)	((x) - PAGE_OFFSET + PHYS_OFFSET)
> -#define __phys_to_virt(x)	((x) - PHYS_OFFSET + PAGE_OFFSET)
> +
> +static inline phys_addr_t __virt_to_phys(unsigned long x)
> +{
> +	return (phys_addr_t)x - PAGE_OFFSET + PHYS_OFFSET;
> +}
> +
> +static inline unsigned long __phys_to_virt(phys_addr_t x)
> +{
> +	return x - PHYS_OFFSET + PAGE_OFFSET;
> +}
> +
>  #endif
>  #endif
>  #endif /* __ASSEMBLY__ */
> @@ -238,14 +248,14 @@ static inline phys_addr_t virt_to_phys(const volatile void *x)
>  
>  static inline void *phys_to_virt(phys_addr_t x)
>  {
> -	return (void *)(__phys_to_virt((unsigned long)(x)));
> +	return (void *)__phys_to_virt(x);
>  }
>  
>  /*
>   * Drivers should NOT use these either.
>   */
>  #define __pa(x)			__virt_to_phys((unsigned long)(x))
> -#define __va(x)			((void *)__phys_to_virt((unsigned long)(x)))
> +#define __va(x)			((void *)__phys_to_virt((phys_addr_t)(x)))
>  #define pfn_to_kaddr(pfn)	__va((pfn) << PAGE_SHIFT)
>  
>  /*
> -- 
> 1.7.9.5
> 


From gregkh at linuxfoundation.org  Mon Jul 22 11:04:58 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Mon, 22 Jul 2013 08:04:58 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51ECDE5E.3050104@ti.com>
References: <Pine.LNX.4.44L0.1307211453450.19133-100000@netrider.rowland.org>
 <51ECDE5E.3050104@ti.com>
Message-ID: <20130722150458.GA18181@kroah.com>

On Mon, Jul 22, 2013 at 12:55:18PM +0530, Kishon Vijay Abraham I wrote:
> > 	The issue (or one of the issues) in this discussion is that 
> > 	Greg does not like the idea of using names or IDs to associate
> > 	PHYs with controllers, because they are too prone to
> > 	duplications or other errors.  Pointers are more reliable.
> > 
> > 	But pointers to what?  Since the only data known to be 
> > 	available to both the PHY driver and controller driver is the
> > 	platform data, the obvious answer is a pointer to platform data
> > 	(either for the PHY or for the controller, or maybe both).
> 
> hmm.. it's not going to be simple though as the platform device for the PHY and
> controller can be created in entirely different places. e.g., in some cases the
> PHY device is a child of some mfd core device (the device will be created in
> drivers/mfd) and the controller driver (usually) is created in board file. I
> guess then we have to come up with something to share a pointer in two
> different files.

What's wrong with using the platform_data structure that is unique to
all boards (see include/platform_data/ for examples)?  Isn't that what
this structure is there for?

greg k-h


From plagnioj at jcrosoft.com  Mon Jul 22 11:01:35 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 22 Jul 2013 17:01:35 +0200
Subject: [PATCH v2] of: Specify initrd location using 64-bit
In-Reply-To: <1372702835-5333-1-git-send-email-santosh.shilimkar@ti.com>
References: <1372702835-5333-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <20130722150135.GI16015@ns203013.ovh.net>

On 14:20 Mon 01 Jul     , Santosh Shilimkar wrote:
> On some PAE architectures, the entire range of physical memory could reside
> outside the 32-bit limit.  These systems need the ability to specify the
> initrd location using 64-bit numbers.
> 
> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
> use 64-bit numbers instead of the current unsigned long.
> 
> There has been quite a bit of debate about whether to use u64 or phys_addr_t.
> It was concluded to stick to u64 to be consistent with rest of the device
> tree code. As summarized by Geert, "The address to load the initrd is decided
> by the bootloader/user and set at that point later in time. The dtb should not
> be tied to the kernel you are booting"
> 
> More details on the discussion can be found here:
> https://lkml.org/lkml/2013/6/20/690
> https://lkml.org/lkml/2012/9/13/544
> 
> Cc: Grant Likely <grant.likely at linaro.org>
> Cc: Rob Herring <rob.herring at calxeda.com>
> Cc: Geert Uytterhoeven <geert at linux-m68k.org>
> Cc: Sebastian Andrzej Siewior <bigeasy at linutronix.de>
> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: Vineet Gupta <vgupta at synopsys.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Mark Salter <msalter at redhat.com>
> Cc: Aurelien Jacquiot <a-jacquiot at ti.com>
> Cc: James Hogan <james.hogan at imgtec.com>
> Cc: Michal Simek <monstr at monstr.eu>
> Cc: Ralf Baechle <ralf at linux-mips.org>
> Cc: Jonas Bonn <jonas at southpole.se>
> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> Cc: Paul Mackerras <paulus at samba.org>
> Cc: x86 at kernel.org
> Cc: arm at kernel.org
> Cc: Chris Zankel <chris at zankel.net>
> Cc: Max Filippov <jcmvbkbc at gmail.com>
> Cc: bigeasy at linutronix.de
> Cc: robherring2 at gmail.com
> Cc: Nicolas Pitre <nicolas.pitre at linaro.org>

Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

> 
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-c6x-dev at linux-c6x.org
> Cc: linux-mips at linux-mips.org
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: linux-xtensa at linux-xtensa.org
> Cc: devicetree-discuss at lists.ozlabs.org
> 
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arc/mm/init.c            |    5 ++---
>  arch/arm/mm/init.c            |    2 +-
>  arch/arm64/mm/init.c          |    3 +--
>  arch/c6x/kernel/devicetree.c  |    3 +--
>  arch/metag/mm/init.c          |    5 ++---
>  arch/microblaze/kernel/prom.c |    3 +--
>  arch/mips/kernel/prom.c       |    3 +--
>  arch/openrisc/kernel/prom.c   |    3 +--
>  arch/powerpc/kernel/prom.c    |    3 +--
>  arch/x86/kernel/devicetree.c  |    3 +--
>  arch/xtensa/kernel/setup.c    |    3 +--
>  drivers/of/fdt.c              |   10 ++++++----
>  include/linux/of_fdt.h        |    3 +--
>  13 files changed, 20 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> index 4a17736..7991e08 100644
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -157,9 +157,8 @@ void __init free_initrd_mem(unsigned long start, unsigned long end)
>  #endif
>  
>  #ifdef CONFIG_OF_FLATTREE
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -					    unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
> -	pr_err("%s(%lx, %lx)\n", __func__, start, end);
> +	pr_err("%s(%llx, %llx)\n", __func__, start, end);
>  }
>  #endif /* CONFIG_OF_FLATTREE */
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 9a5cdc0..afeaef7 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -76,7 +76,7 @@ static int __init parse_tag_initrd2(const struct tag *tag)
>  __tagtable(ATAG_INITRD2, parse_tag_initrd2);
>  
>  #ifdef CONFIG_OF_FLATTREE
> -void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	phys_initrd_start = start;
>  	phys_initrd_size = end - start;
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index f497ca7..7047708 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -44,8 +44,7 @@ static unsigned long phys_initrd_size __initdata = 0;
>  
>  phys_addr_t memstart_addr __read_mostly = 0;
>  
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -					    unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	phys_initrd_start = start;
>  	phys_initrd_size = end - start;
> diff --git a/arch/c6x/kernel/devicetree.c b/arch/c6x/kernel/devicetree.c
> index bdb56f0..287d0e6 100644
> --- a/arch/c6x/kernel/devicetree.c
> +++ b/arch/c6x/kernel/devicetree.c
> @@ -33,8 +33,7 @@ void __init early_init_devtree(void *params)
>  
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -		unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	initrd_start = (unsigned long)__va(start);
>  	initrd_end = (unsigned long)__va(end);
> diff --git a/arch/metag/mm/init.c b/arch/metag/mm/init.c
> index d05b845..bdc4811 100644
> --- a/arch/metag/mm/init.c
> +++ b/arch/metag/mm/init.c
> @@ -419,10 +419,9 @@ void free_initrd_mem(unsigned long start, unsigned long end)
>  #endif
>  
>  #ifdef CONFIG_OF_FLATTREE
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -					    unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
> -	pr_err("%s(%lx, %lx)\n",
> +	pr_err("%s(%llx, %llx)\n",
>  	       __func__, start, end);
>  }
>  #endif /* CONFIG_OF_FLATTREE */
> diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
> index 0a2c68f..62e2e8f 100644
> --- a/arch/microblaze/kernel/prom.c
> +++ b/arch/microblaze/kernel/prom.c
> @@ -136,8 +136,7 @@ void __init early_init_devtree(void *params)
>  }
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -		unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	initrd_start = (unsigned long)__va(start);
>  	initrd_end = (unsigned long)__va(end);
> diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
> index 5712bb5..32b8788 100644
> --- a/arch/mips/kernel/prom.c
> +++ b/arch/mips/kernel/prom.c
> @@ -58,8 +58,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
>  }
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -					    unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	initrd_start = (unsigned long)__va(start);
>  	initrd_end = (unsigned long)__va(end);
> diff --git a/arch/openrisc/kernel/prom.c b/arch/openrisc/kernel/prom.c
> index 5869e3f..150215a 100644
> --- a/arch/openrisc/kernel/prom.c
> +++ b/arch/openrisc/kernel/prom.c
> @@ -96,8 +96,7 @@ void __init early_init_devtree(void *params)
>  }
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -		unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	initrd_start = (unsigned long)__va(start);
>  	initrd_end = (unsigned long)__va(end);
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 8b6f7a9..2f3e252 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -550,8 +550,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
>  }
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -		unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	initrd_start = (unsigned long)__va(start);
>  	initrd_end = (unsigned long)__va(end);
> diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
> index b158152..2fbad6b 100644
> --- a/arch/x86/kernel/devicetree.c
> +++ b/arch/x86/kernel/devicetree.c
> @@ -52,8 +52,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
>  }
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -					    unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	initrd_start = (unsigned long)__va(start);
>  	initrd_end = (unsigned long)__va(end);
> diff --git a/arch/xtensa/kernel/setup.c b/arch/xtensa/kernel/setup.c
> index 6dd25ec..d45e602 100644
> --- a/arch/xtensa/kernel/setup.c
> +++ b/arch/xtensa/kernel/setup.c
> @@ -170,8 +170,7 @@ static int __init parse_tag_fdt(const bp_tag_t *tag)
>  
>  __tagtable(BP_TAG_FDT, parse_tag_fdt);
>  
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> -		unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>  {
>  	initrd_start = (void *)__va(start);
>  	initrd_end = (void *)__va(end);
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 808be06..21123b8 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -550,7 +550,8 @@ int __init of_flat_dt_match(unsigned long node, const char *const *compat)
>   */
>  void __init early_init_dt_check_for_initrd(unsigned long node)
>  {
> -	unsigned long start, end, len;
> +	u64 start, end;
> +	unsigned long len;
>  	__be32 *prop;
>  
>  	pr_debug("Looking for initrd properties... ");
> @@ -558,15 +559,16 @@ void __init early_init_dt_check_for_initrd(unsigned long node)
>  	prop = of_get_flat_dt_prop(node, "linux,initrd-start", &len);
>  	if (!prop)
>  		return;
> -	start = of_read_ulong(prop, len/4);
> +	start = of_read_number(prop, len/4);
>  
>  	prop = of_get_flat_dt_prop(node, "linux,initrd-end", &len);
>  	if (!prop)
>  		return;
> -	end = of_read_ulong(prop, len/4);
> +	end = of_read_number(prop, len/4);
>  
>  	early_init_dt_setup_initrd_arch(start, end);
> -	pr_debug("initrd_start=0x%lx  initrd_end=0x%lx\n", start, end);
> +	pr_debug("initrd_start=0x%llx  initrd_end=0x%llx\n",
> +		 (unsigned long long)start, (unsigned long long)end);
>  }
>  #else
>  inline void early_init_dt_check_for_initrd(unsigned long node)
> diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
> index ed136ad..4a17939 100644
> --- a/include/linux/of_fdt.h
> +++ b/include/linux/of_fdt.h
> @@ -106,8 +106,7 @@ extern u64 dt_mem_next_cell(int s, __be32 **cellp);
>   * physical addresses.
>   */
>  #ifdef CONFIG_BLK_DEV_INITRD
> -extern void early_init_dt_setup_initrd_arch(unsigned long start,
> -					    unsigned long end);
> +extern void early_init_dt_setup_initrd_arch(u64 start, u64 end);
>  #endif
>  
>  /* Early flat tree scan hooks */
> -- 
> 1.7.9.5
> 


From Sudeep.KarkadaNagesha at arm.com  Mon Jul 22 11:07:05 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 22 Jul 2013 16:07:05 +0100
Subject: [PATCH v3 01/16] of: add support for retrieving cpu node for
 a given logical cpu index
In-Reply-To: <alpine.LFD.2.03.1307221007160.15022@syhkavp.arg>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <alpine.LFD.2.03.1307221007160.15022@syhkavp.arg>
Message-ID: <51ED4A99.3030403@arm.com>

Hi Nico,

On 22/07/13 15:14, Nicolas Pitre wrote:
> On Mon, 22 Jul 2013, Sudeep KarkadaNagesha wrote:
> 
>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>>
>> Currently different drivers requiring to access cpu device node are
>> parsing the device tree themselves. Since the ordering in the DT need
>> not match the logical cpu ordering, the parsing logic needs to consider
>> that. However, this has resulted in lots of code duplication and in some
>> cases even incorrect logic.
>>
>> It's better to consolidate them by adding support for getting cpu
>> device node for a given logical cpu index in DT core library. However
>> logical to physical index mapping can be architecture specific.
>>
>> This patch adds of_get_cpu_node to retrieve a cpu device node for a
>> given logical cpu index. The default matching of the physical id to the
>> logical cpu index can be overridden by architecture specific code.
>>
>> It is recommended to use these helper function only in pre-SMP/early
>> initialisation stages to retrieve CPU device node pointers in logical
>> ordering. Once the cpu devices are registered, it can be retrieved easily
>> from cpu device of_node which avoids unnecessary parsing and matching.
>>
>> Acked-by: Rob Herring <rob.herring at calxeda.com>
>> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> Minor nits below.  Otherwise...
> 
> Acked-by: Nicolas Pitre <nico at linaro.org>
> 
Thanks for all the Acks.

>> ---
>>  drivers/of/base.c  | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  include/linux/of.h |  6 +++++
>>  2 files changed, 78 insertions(+)
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index 5c54279..1e690bf 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -230,6 +230,78 @@ const void *of_get_property(const struct device_node *np, const char *name,
>>  }
>>  EXPORT_SYMBOL(of_get_property);
>>  
>> +/*
>> + * arch_match_cpu_phys_id - Match the given logical CPU and physical id
>> + *
>> + * @cpu: logical index of a cpu
>> + * @phys_id: physical identifier of a cpu
>> + *
>> + * CPU logical to physical index mapping is architecture specific.
>> + * However this __weak function provides a default match of physical
>> + * id to logical cpu index.
>> + *
>> + * Returns true if the physical identifier and the logical index correspond
>> + * to the same cpu, false otherwise.
>> + */
>> +bool __weak arch_match_cpu_phys_id(int cpu, u64 phys_id)
> 
> Maybe a prototype declaration for this function should be added to 
> include/linux/of.h to avoid mismatch with architecture provided 
> versions.
> 
Agreed, but include/linux/of.h doesn't seem to be right choice for me as
this function is not really related to OF/DT. I can't choose any better
place either. I don't have a strong opinion on that, just a thought.

Regards,
Sudeep




From stern at rowland.harvard.edu  Mon Jul 22 11:18:46 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Mon, 22 Jul 2013 11:18:46 -0400 (EDT)
Subject: [PATCH 6/6] USB: ehci-omap: Implement suspend/resume
In-Reply-To: <51ED30A8.10200@ti.com>
Message-ID: <Pine.LNX.4.44L0.1307221111410.1495-100000@iolanthe.rowland.org>

On Mon, 22 Jul 2013, Roger Quadros wrote:

> Right, I understand it now. How does the below code look?
> 
> +static int omap_ehci_suspend(struct device *dev)
> +{
> +       struct usb_hcd *hcd = dev_get_drvdata(dev);
> +       bool do_wakeup = device_may_wakeup(dev);
> +       int ret;
> +
> +       dev_dbg(dev, "%s may_wakeup %d\n", __func__, do_wakeup);
> +
> +       if (pm_runtime_status_suspended(dev)) {

You need to do this only when do_wakeup is false.

> +               pm_runtime_get_sync(dev);
> +               ehci_resume(hcd, false);
> +               ret = ehci_suspend(hcd, do_wakeup);
> +               pm_runtime_put_sync(dev);

It would be better to call pm_runtime_resume(dev) at the start instead
of pm_runtime_get_sync(), and eliminate the last two lines.  Then the
ehci_suspend() below could be moved outside the "if" statement.

Alternatively, if you are able to turn off the wakeup setting without
going through an entire resume/suspend cycle, that would be preferable.

> +
> +       } else {
> +               ret = ehci_suspend(hcd, do_wakeup);
> +       }
> +
> +       return ret;
> +}
> +
> +static int omap_ehci_resume(struct device *dev)
> +{
> +       struct usb_hcd *hcd = dev_get_drvdata(dev);
> +       int ret;
> +
> +       dev_dbg(dev, "%s\n", __func__);
> +
> +       ret = ehci_resume(hcd, false);
> +       if (!ret) {
> +               /*
> +                * Controller was powered ON so reflect state
> +                */
> +               pm_runtime_disable(dev);
> +               pm_runtime_set_active(dev);
> +               pm_runtime_enable(dev);
> +       }
> +
> +       return ret;
> +}

All good.

Alan Stern



From shc_work at mail.ru  Mon Jul 22 11:18:44 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Mon, 22 Jul 2013 19:18:44 +0400
Subject: [RFC v2] ARM: i.MX pllv1: Implement set_rate
In-Reply-To: <20130721123759.GJ29785@pengutronix.de>
References: <1374308975-20596-1-git-send-email-shc_work@mail.ru>
 <20130720111639.GA29785@pengutronix.de>
 <20130720153104.96b6723a20bde172a8ea1ba1@mail.ru>
 <20130720115829.GD29785@pengutronix.de>
 <20130720161801.380bb0d9db75155f5401730b@mail.ru>
 <20130721123759.GJ29785@pengutronix.de>
Message-ID: <20130722191844.56e60280573dcab51187c9f3@mail.ru>

On Sun, 21 Jul 2013 14:37:59 +0200
Sascha Hauer <s.hauer at pengutronix.de> wrote:

> On Sat, Jul 20, 2013 at 04:18:01PM +0400, Alexander Shiyan wrote:
> > On Sat, 20 Jul 2013 13:58:29 +0200
> > Sascha Hauer <s.hauer at pengutronix.de> wrote:
> > 
> > > > > On Sat, Jul 20, 2013 at 12:29:35PM +0400, Alexander Shiyan wrote:
> > > > > > This patch implements frequency change for i.MX pllv1.
> > > > > > Selection of the values of the registers is not optimal, since is
> > > > > > made by simple enumeration of all possible values.
> > > > > 
> > > > > You do not mention why you want to adjust the rate. Normally we've been
> > > > > happy with the static values from the bootloader.
> > > > 
> > > > For CPUfreq.
> > > > Only one barrier to make it workable.
> > > 
> > > Isn't it better to adjust the dividers only? I haven't made good
> > > experience with adjusting the PLLs.
> > 
> > The frequency value after booting can be quite arbitrary.
> > 
> > Since we define possible frequencies for the CPU (266 and 399 MHz),
> > I can offer as variant to use a fixed constant values for PLL.
> 
> AFAIK the PLL should run at 800MHz. With dividers of 2, 3 and 6 we get
> 400, 266 and 133MHz. I don't think having more fine grained control
> about the CPU frequency is necessary from a power saving point of view.
> Let's keep the variants to a minimum to make the whole stuff more
> robust.

What about switching the source?
In any case, I have already made an efficient algorithm to calculate
the PLL and after some tests, I will introduce it.
Thanks.

-- 
Alexander Shiyan <shc_work at mail.ru>


From l.stach at pengutronix.de  Mon Jul 22 11:24:35 2013
From: l.stach at pengutronix.de (Lucas Stach)
Date: Mon, 22 Jul 2013 17:24:35 +0200
Subject: [RFC v2] ARM: i.MX pllv1: Implement set_rate
In-Reply-To: <20130722191844.56e60280573dcab51187c9f3@mail.ru>
References: <1374308975-20596-1-git-send-email-shc_work@mail.ru>
 <20130720111639.GA29785@pengutronix.de>
 <20130720153104.96b6723a20bde172a8ea1ba1@mail.ru>
 <20130720115829.GD29785@pengutronix.de>
 <20130720161801.380bb0d9db75155f5401730b@mail.ru>
 <20130721123759.GJ29785@pengutronix.de>
 <20130722191844.56e60280573dcab51187c9f3@mail.ru>
Message-ID: <1374506675.4128.6.camel@weser.hi.pengutronix.de>

Am Montag, den 22.07.2013, 19:18 +0400 schrieb Alexander Shiyan:
> On Sun, 21 Jul 2013 14:37:59 +0200
> Sascha Hauer <s.hauer at pengutronix.de> wrote:
> 
> > On Sat, Jul 20, 2013 at 04:18:01PM +0400, Alexander Shiyan wrote:
> > > On Sat, 20 Jul 2013 13:58:29 +0200
> > > Sascha Hauer <s.hauer at pengutronix.de> wrote:
> > > 
> > > > > > On Sat, Jul 20, 2013 at 12:29:35PM +0400, Alexander Shiyan wrote:
> > > > > > > This patch implements frequency change for i.MX pllv1.
> > > > > > > Selection of the values of the registers is not optimal, since is
> > > > > > > made by simple enumeration of all possible values.
> > > > > > 
> > > > > > You do not mention why you want to adjust the rate. Normally we've been
> > > > > > happy with the static values from the bootloader.
> > > > > 
> > > > > For CPUfreq.
> > > > > Only one barrier to make it workable.
> > > > 
> > > > Isn't it better to adjust the dividers only? I haven't made good
> > > > experience with adjusting the PLLs.
> > > 
> > > The frequency value after booting can be quite arbitrary.
> > > 
> > > Since we define possible frequencies for the CPU (266 and 399 MHz),
> > > I can offer as variant to use a fixed constant values for PLL.
> > 
> > AFAIK the PLL should run at 800MHz. With dividers of 2, 3 and 6 we get
> > 400, 266 and 133MHz. I don't think having more fine grained control
> > about the CPU frequency is necessary from a power saving point of view.
> > Let's keep the variants to a minimum to make the whole stuff more
> > robust.
> 
> What about switching the source?
> In any case, I have already made an efficient algorithm to calculate
> the PLL and after some tests, I will introduce it.
> Thanks.
> 
Both changing the divider or changing source should be glitchfree in the
CPU clock path. Using the divider should be enough to allow to scale the
CPU frequency with the accuracy needed for simple CPUfreq.

Using the PLL to scale the frequency is a really bad idea, as it's both
not glitchfree on it's own plus it adds considerable delay to the clock
change. In order to use the PLL for clock scaling you have to first
switch the CPU away from the PLL (making sure you have an alternative
clock path that can satisfy the CPUs requirements), then reprogram PLL,
wait for the PLL to lock, then switch back to the PLL. Sounds utterly
complex for a simple clock change that could be done by just flipping
the divider bits, isn't it?

Regards,
Lucas 
-- 
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



From mark.rutland at arm.com  Mon Jul 22 11:37:29 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Jul 2013 16:37:29 +0100
Subject: [PATCHv2 0/5] arm64: initial CPU hotplug support
Message-ID: <1374507454-4573-1-git-send-email-mark.rutland@arm.com>

The following patches add basic HOTPLUG_CPU support to arm64, which
combined with appropriate firmware (e.g. [1]) can be used to power CPUs
up and down dynamically.

Currently this clashes with Xen support on arm64, but there's already a patch
to fix that up [2], so hopefully that will get solved during the merge process.

I've tested this series with the bootwrapper PSCI implementation I've
placed on linux-arm.org [1] and a modified foundation model dts with a
psci node and each CPU's enable-method set to "psci", using a shell
while repeatedly cycling all cpus off and on:

for C in $(seq 0 3); do
	./cyclichotplug.sh $C >/dev/null 2>&1 &
done

---->8----
#!/bin/sh
# cyclichotplug.sh

CPU=$1;

if [ -z "$CPU" ]; then
	printf "Usage: $0 <cpu id>\n";
	exit 1;
fi

ONLINEFILE=/sys/devices/system/cpu/cpu$CPU/online;

while true; do
	echo 0 > $ONLINEFILE;
	echo 1 > $ONLINEFILE;
done
---->8----

Since v1 [3]:
* Rebased to v3.11-rc2 to solve cpuinit removal conflicts.
* Removed failure path for cpu_die, it causes more problems than it solves.
* Removed cpu_kill, we don't currently need it.
* Test for cpu_die in op_cpu_disable to fail early and survive when there's no
  mechanism for hot unplug.
* Change pr_err on failed cpu_die to a pr_crit.
* Removed dependency on HOTPLUG, which has been obliterated.

Thanks,
Mark.

[1] http://linux-arm.org/git?p=boot-wrapper-aarch64.git;a=shortlog;h=refs/tags/simple-psci
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185237.html
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/182880.html

Mark Rutland (5):
  arm64: reorganise smp_enable_ops
  arm64: factor out spin-table boot method
  arm64: read enable-method for CPU0
  arm64: add CPU_HOTPLUG infrastructure
  arm64: add PSCI CPU_OFF-based hotplug support

 arch/arm64/Kconfig                 |   7 ++
 arch/arm64/include/asm/irq.h       |   1 +
 arch/arm64/include/asm/smp.h       |  36 +++++--
 arch/arm64/kernel/cputable.c       |   2 +-
 arch/arm64/kernel/head.S           |  12 ++-
 arch/arm64/kernel/irq.c            |  61 +++++++++++
 arch/arm64/kernel/process.c        |   7 ++
 arch/arm64/kernel/smp.c            | 201 ++++++++++++++++++++++---------------
 arch/arm64/kernel/smp_psci.c       |  54 ++++++++--
 arch/arm64/kernel/smp_spin_table.c |  85 +++++++++++++++-
 arch/arm64/kernel/vmlinux.lds.S    |   1 -
 11 files changed, 360 insertions(+), 107 deletions(-)

-- 
1.8.1.1



From mark.rutland at arm.com  Mon Jul 22 11:37:30 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Jul 2013 16:37:30 +0100
Subject: [PATCHv2 1/5] arm64: reorganise smp_enable_ops
In-Reply-To: <1374507454-4573-1-git-send-email-mark.rutland@arm.com>
References: <1374507454-4573-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1374507454-4573-2-git-send-email-mark.rutland@arm.com>

For hotplug support, we're going to want a place to store operations
that do more than bring CPUs online, and it makes sense to group these
with our current smp_enable_ops.

This patch renames smp_enable_ops to smp_ops to make the intended use of
the structure clearer. While we're at it, fix up instances of the cpu
parameter to be an unsigned int, drop the init markings and rename the
*_cpu functions to cpu_* to reduce future churn when smp_operations is
extended.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/include/asm/smp.h       | 10 +++++-----
 arch/arm64/kernel/smp.c            | 24 ++++++++++++------------
 arch/arm64/kernel/smp_psci.c       | 10 +++++-----
 arch/arm64/kernel/smp_spin_table.c | 10 +++++-----
 4 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index 4b8023c..90626b6 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -68,13 +68,13 @@ extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
 
 struct device_node;
 
-struct smp_enable_ops {
+struct smp_operations {
 	const char	*name;
-	int		(*init_cpu)(struct device_node *, int);
-	int		(*prepare_cpu)(int);
+	int		(*cpu_init)(struct device_node *, unsigned int);
+	int		(*cpu_prepare)(unsigned int);
 };
 
-extern const struct smp_enable_ops smp_spin_table_ops;
-extern const struct smp_enable_ops smp_psci_ops;
+extern const struct smp_operations smp_spin_table_ops;
+extern const struct smp_operations smp_psci_ops;
 
 #endif /* ifndef __ASM_SMP_H */
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index fee5cce..533f405 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -236,17 +236,17 @@ void __init smp_prepare_boot_cpu(void)
 
 static void (*smp_cross_call)(const struct cpumask *, unsigned int);
 
-static const struct smp_enable_ops *enable_ops[] __initconst = {
+static const struct smp_operations *supported_smp_ops[] __initconst = {
 	&smp_spin_table_ops,
 	&smp_psci_ops,
 	NULL,
 };
 
-static const struct smp_enable_ops *smp_enable_ops[NR_CPUS];
+static const struct smp_operations *smp_ops[NR_CPUS];
 
-static const struct smp_enable_ops * __init smp_get_enable_ops(const char *name)
+static const struct smp_operations * __init smp_get_ops(const char *name)
 {
-	const struct smp_enable_ops **ops = enable_ops;
+	const struct smp_operations **ops = supported_smp_ops;
 
 	while (*ops) {
 		if (!strcmp(name, (*ops)->name))
@@ -267,7 +267,7 @@ void __init smp_init_cpus(void)
 {
 	const char *enable_method;
 	struct device_node *dn = NULL;
-	int i, cpu = 1;
+	unsigned int i, cpu = 1;
 	bool bootcpu_valid = false;
 
 	while ((dn = of_find_node_by_type(dn, "cpu"))) {
@@ -346,15 +346,15 @@ void __init smp_init_cpus(void)
 			goto next;
 		}
 
-		smp_enable_ops[cpu] = smp_get_enable_ops(enable_method);
+		smp_ops[cpu] = smp_get_ops(enable_method);
 
-		if (!smp_enable_ops[cpu]) {
+		if (!smp_ops[cpu]) {
 			pr_err("%s: invalid enable-method property: %s\n",
 			       dn->full_name, enable_method);
 			goto next;
 		}
 
-		if (smp_enable_ops[cpu]->init_cpu(dn, cpu))
+		if (smp_ops[cpu]->cpu_init(dn, cpu))
 			goto next;
 
 		pr_debug("cpu logical map 0x%llx\n", hwid);
@@ -384,8 +384,8 @@ next:
 
 void __init smp_prepare_cpus(unsigned int max_cpus)
 {
-	int cpu, err;
-	unsigned int ncores = num_possible_cpus();
+	int err;
+	unsigned int cpu, ncores = num_possible_cpus();
 
 	/*
 	 * are we trying to boot more cores than exist?
@@ -412,10 +412,10 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 		if (cpu == smp_processor_id())
 			continue;
 
-		if (!smp_enable_ops[cpu])
+		if (!smp_ops[cpu])
 			continue;
 
-		err = smp_enable_ops[cpu]->prepare_cpu(cpu);
+		err = smp_ops[cpu]->cpu_prepare(cpu);
 		if (err)
 			continue;
 
diff --git a/arch/arm64/kernel/smp_psci.c b/arch/arm64/kernel/smp_psci.c
index 0c53330..2f0d3dd 100644
--- a/arch/arm64/kernel/smp_psci.c
+++ b/arch/arm64/kernel/smp_psci.c
@@ -23,12 +23,12 @@
 #include <asm/psci.h>
 #include <asm/smp_plat.h>
 
-static int __init smp_psci_init_cpu(struct device_node *dn, int cpu)
+static int smp_psci_cpu_init(struct device_node *dn, unsigned int cpu)
 {
 	return 0;
 }
 
-static int __init smp_psci_prepare_cpu(int cpu)
+static int smp_psci_cpu_prepare(unsigned int cpu)
 {
 	int err;
 
@@ -46,8 +46,8 @@ static int __init smp_psci_prepare_cpu(int cpu)
 	return 0;
 }
 
-const struct smp_enable_ops smp_psci_ops __initconst = {
+const struct smp_operations smp_psci_ops = {
 	.name		= "psci",
-	.init_cpu	= smp_psci_init_cpu,
-	.prepare_cpu	= smp_psci_prepare_cpu,
+	.cpu_init	= smp_psci_cpu_init,
+	.cpu_prepare	= smp_psci_cpu_prepare,
 };
diff --git a/arch/arm64/kernel/smp_spin_table.c b/arch/arm64/kernel/smp_spin_table.c
index 7c35fa6..5fecffc 100644
--- a/arch/arm64/kernel/smp_spin_table.c
+++ b/arch/arm64/kernel/smp_spin_table.c
@@ -24,7 +24,7 @@
 
 static phys_addr_t cpu_release_addr[NR_CPUS];
 
-static int __init smp_spin_table_init_cpu(struct device_node *dn, int cpu)
+static int smp_spin_table_cpu_init(struct device_node *dn, unsigned int cpu)
 {
 	/*
 	 * Determine the address from which the CPU is polling.
@@ -40,7 +40,7 @@ static int __init smp_spin_table_init_cpu(struct device_node *dn, int cpu)
 	return 0;
 }
 
-static int __init smp_spin_table_prepare_cpu(int cpu)
+static int smp_spin_table_cpu_prepare(unsigned int cpu)
 {
 	void **release_addr;
 
@@ -59,8 +59,8 @@ static int __init smp_spin_table_prepare_cpu(int cpu)
 	return 0;
 }
 
-const struct smp_enable_ops smp_spin_table_ops __initconst = {
+const struct smp_operations smp_spin_table_ops = {
 	.name		= "spin-table",
-	.init_cpu 	= smp_spin_table_init_cpu,
-	.prepare_cpu	= smp_spin_table_prepare_cpu,
+	.cpu_init	= smp_spin_table_cpu_init,
+	.cpu_prepare	= smp_spin_table_cpu_prepare,
 };
-- 
1.8.1.1



From mark.rutland at arm.com  Mon Jul 22 11:37:31 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Jul 2013 16:37:31 +0100
Subject: [PATCHv2 2/5] arm64: factor out spin-table boot method
In-Reply-To: <1374507454-4573-1-git-send-email-mark.rutland@arm.com>
References: <1374507454-4573-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1374507454-4573-3-git-send-email-mark.rutland@arm.com>

The arm64 kernel has an internal holding pen, which is necessary for
some systems where we can't bring CPUs online individually and must hold
multiple CPUs in a safe area until the kernel is able to handle them.
The current SMP infrastructure for arm64 is closely coupled to this
holding pen, and alternative boot methods must launch CPUs into the pen,
from whence they are launched into the kernel proper.

With PSCI (and possibly other future boot methods), we can bring CPUs
online individually, and need not perform the secondary_holding_pen
dance. Instead, this patch factors the holding pen management code out
to the spin-table boot method code, as it is the only boot method
requiring the pen.

A new entry point for secondaries, secondary_entry is added for other
boot methods to use, which bypasses the holding pen and its associated
overhead when bringing CPUs online. The smp.pen.text section is also
removed, as the pen can live in head.text without problem.

The smp_operations structure is extended with two new functions,
cpu_boot and cpu_postboot, for bringing a cpu into the kernel and
performing any post-boot cleanup required by a bootmethod (e.g.
resetting the secondary_holding_pen_release to INVALID_HWID).

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/include/asm/smp.h       | 17 ++++++++-
 arch/arm64/kernel/head.S           | 12 +++++-
 arch/arm64/kernel/smp.c            | 67 +++-------------------------------
 arch/arm64/kernel/smp_psci.c       | 16 ++++----
 arch/arm64/kernel/smp_spin_table.c | 75 ++++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/vmlinux.lds.S    |  1 -
 6 files changed, 115 insertions(+), 73 deletions(-)

diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index 90626b6..af39644 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -60,8 +60,7 @@ struct secondary_data {
 	void *stack;
 };
 extern struct secondary_data secondary_data;
-extern void secondary_holding_pen(void);
-extern volatile unsigned long secondary_holding_pen_release;
+extern void secondary_entry(void);
 
 extern void arch_send_call_function_single_ipi(int cpu);
 extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
@@ -70,8 +69,22 @@ struct device_node;
 
 struct smp_operations {
 	const char	*name;
+	/*
+	 * Check devicetree data for cpu
+	 */
 	int		(*cpu_init)(struct device_node *, unsigned int);
+	/*
+	 * Test if cpu is present and bootable
+	 */
 	int		(*cpu_prepare)(unsigned int);
+	/*
+	 * Boot cpu into the kernel
+	 */
+	int		(*cpu_boot)(unsigned int);
+	/*
+	 * Performs post-boot cleanup
+	 */
+	void		(*cpu_postboot)(void);
 };
 
 extern const struct smp_operations smp_spin_table_ops;
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 53dcae4..3532ca6 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -217,7 +217,6 @@ ENTRY(__boot_cpu_mode)
 	.quad	PAGE_OFFSET
 
 #ifdef CONFIG_SMP
-	.pushsection    .smp.pen.text, "ax"
 	.align	3
 1:	.quad	.
 	.quad	secondary_holding_pen_release
@@ -242,7 +241,16 @@ pen:	ldr	x4, [x3]
 	wfe
 	b	pen
 ENDPROC(secondary_holding_pen)
-	.popsection
+
+	/*
+	 * Secondary entry point that jumps straight into the kernel. Only to
+	 * be used where CPUs are brought online dynamically by the kernel.
+	 */
+ENTRY(secondary_entry)
+	bl	__calc_phys_offset		// x2=phys offset
+	bl	el2_setup			// Drop to EL1
+	b	secondary_startup
+ENDPROC(secondary_entry)
 
 ENTRY(secondary_startup)
 	/*
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 533f405..72c2823 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -54,7 +54,6 @@
  * where to place its SVC stack
  */
 struct secondary_data secondary_data;
-volatile unsigned long secondary_holding_pen_release = INVALID_HWID;
 
 enum ipi_msg_type {
 	IPI_RESCHEDULE,
@@ -63,22 +62,7 @@ enum ipi_msg_type {
 	IPI_CPU_STOP,
 };
 
-static DEFINE_RAW_SPINLOCK(boot_lock);
-
-/*
- * Write secondary_holding_pen_release in a way that is guaranteed to be
- * visible to all observers, irrespective of whether they're taking part
- * in coherency or not.  This is necessary for the hotplug code to work
- * reliably.
- */
-static void write_pen_release(u64 val)
-{
-	void *start = (void *)&secondary_holding_pen_release;
-	unsigned long size = sizeof(secondary_holding_pen_release);
-
-	secondary_holding_pen_release = val;
-	__flush_dcache_area(start, size);
-}
+static const struct smp_operations *smp_ops[NR_CPUS];
 
 /*
  * Boot a secondary CPU, and assign it the specified idle task.
@@ -86,38 +70,10 @@ static void write_pen_release(u64 val)
  */
 static int boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
-	unsigned long timeout;
-
-	/*
-	 * Set synchronisation state between this boot processor
-	 * and the secondary one
-	 */
-	raw_spin_lock(&boot_lock);
-
-	/*
-	 * Update the pen release flag.
-	 */
-	write_pen_release(cpu_logical_map(cpu));
-
-	/*
-	 * Send an event, causing the secondaries to read pen_release.
-	 */
-	sev();
-
-	timeout = jiffies + (1 * HZ);
-	while (time_before(jiffies, timeout)) {
-		if (secondary_holding_pen_release == INVALID_HWID)
-			break;
-		udelay(10);
-	}
-
-	/*
-	 * Now the secondary core is starting up let it run its
-	 * calibrations, then wait for it to finish
-	 */
-	raw_spin_unlock(&boot_lock);
+	if (smp_ops[cpu]->cpu_boot)
+		return smp_ops[cpu]->cpu_boot(cpu);
 
-	return secondary_holding_pen_release != INVALID_HWID ? -ENOSYS : 0;
+	return -EOPNOTSUPP;
 }
 
 static DECLARE_COMPLETION(cpu_running);
@@ -187,17 +143,8 @@ asmlinkage void secondary_start_kernel(void)
 	preempt_disable();
 	trace_hardirqs_off();
 
-	/*
-	 * Let the primary processor know we're out of the
-	 * pen, then head off into the C entry point
-	 */
-	write_pen_release(INVALID_HWID);
-
-	/*
-	 * Synchronise with the boot thread.
-	 */
-	raw_spin_lock(&boot_lock);
-	raw_spin_unlock(&boot_lock);
+	if (smp_ops[cpu]->cpu_postboot)
+		smp_ops[cpu]->cpu_postboot();
 
 	/*
 	 * OK, now it's safe to let the boot CPU continue.  Wait for
@@ -242,8 +189,6 @@ static const struct smp_operations *supported_smp_ops[] __initconst = {
 	NULL,
 };
 
-static const struct smp_operations *smp_ops[NR_CPUS];
-
 static const struct smp_operations * __init smp_get_ops(const char *name)
 {
 	const struct smp_operations **ops = supported_smp_ops;
diff --git a/arch/arm64/kernel/smp_psci.c b/arch/arm64/kernel/smp_psci.c
index 2f0d3dd..20499bc 100644
--- a/arch/arm64/kernel/smp_psci.c
+++ b/arch/arm64/kernel/smp_psci.c
@@ -30,24 +30,26 @@ static int smp_psci_cpu_init(struct device_node *dn, unsigned int cpu)
 
 static int smp_psci_cpu_prepare(unsigned int cpu)
 {
-	int err;
-
 	if (!psci_ops.cpu_on) {
 		pr_err("psci: no cpu_on method, not booting CPU%d\n", cpu);
 		return -ENODEV;
 	}
 
-	err = psci_ops.cpu_on(cpu_logical_map(cpu), __pa(secondary_holding_pen));
-	if (err) {
+	return 0;
+}
+
+static int smp_psci_cpu_boot(unsigned int cpu)
+{
+	int err = psci_ops.cpu_on(cpu_logical_map(cpu), __pa(secondary_entry));
+	if (err)
 		pr_err("psci: failed to boot CPU%d (%d)\n", cpu, err);
-		return err;
-	}
 
-	return 0;
+	return err;
 }
 
 const struct smp_operations smp_psci_ops = {
 	.name		= "psci",
 	.cpu_init	= smp_psci_cpu_init,
 	.cpu_prepare	= smp_psci_cpu_prepare,
+	.cpu_boot	= smp_psci_cpu_boot,
 };
diff --git a/arch/arm64/kernel/smp_spin_table.c b/arch/arm64/kernel/smp_spin_table.c
index 5fecffc..87af6bb 100644
--- a/arch/arm64/kernel/smp_spin_table.c
+++ b/arch/arm64/kernel/smp_spin_table.c
@@ -16,13 +16,36 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/delay.h>
 #include <linux/init.h>
 #include <linux/of.h>
 #include <linux/smp.h>
 
 #include <asm/cacheflush.h>
+#include <asm/cputype.h>
+#include <asm/smp_plat.h>
+
+extern void secondary_holding_pen(void);
+volatile unsigned long secondary_holding_pen_release = INVALID_HWID;
 
 static phys_addr_t cpu_release_addr[NR_CPUS];
+static DEFINE_RAW_SPINLOCK(boot_lock);
+
+/*
+ * Write secondary_holding_pen_release in a way that is guaranteed to be
+ * visible to all observers, irrespective of whether they're taking part
+ * in coherency or not.  This is necessary for the hotplug code to work
+ * reliably.
+ */
+static void write_pen_release(u64 val)
+{
+	void *start = (void *)&secondary_holding_pen_release;
+	unsigned long size = sizeof(secondary_holding_pen_release);
+
+	secondary_holding_pen_release = val;
+	__flush_dcache_area(start, size);
+}
+
 
 static int smp_spin_table_cpu_init(struct device_node *dn, unsigned int cpu)
 {
@@ -59,8 +82,60 @@ static int smp_spin_table_cpu_prepare(unsigned int cpu)
 	return 0;
 }
 
+static int smp_spin_table_cpu_boot(unsigned int cpu)
+{
+	unsigned long timeout;
+
+	/*
+	 * Set synchronisation state between this boot processor
+	 * and the secondary one
+	 */
+	raw_spin_lock(&boot_lock);
+
+	/*
+	 * Update the pen release flag.
+	 */
+	write_pen_release(cpu_logical_map(cpu));
+
+	/*
+	 * Send an event, causing the secondaries to read pen_release.
+	 */
+	sev();
+
+	timeout = jiffies + (1 * HZ);
+	while (time_before(jiffies, timeout)) {
+		if (secondary_holding_pen_release == INVALID_HWID)
+			break;
+		udelay(10);
+	}
+
+	/*
+	 * Now the secondary core is starting up let it run its
+	 * calibrations, then wait for it to finish
+	 */
+	raw_spin_unlock(&boot_lock);
+
+	return secondary_holding_pen_release != INVALID_HWID ? -ENOSYS : 0;
+}
+
+void smp_spin_table_cpu_postboot(void)
+{
+	/*
+	 * Let the primary processor know we're out of the pen.
+	 */
+	write_pen_release(INVALID_HWID);
+
+	/*
+	 * Synchronise with the boot thread.
+	 */
+	raw_spin_lock(&boot_lock);
+	raw_spin_unlock(&boot_lock);
+}
+
 const struct smp_operations smp_spin_table_ops = {
 	.name		= "spin-table",
 	.cpu_init	= smp_spin_table_cpu_init,
 	.cpu_prepare	= smp_spin_table_cpu_prepare,
+	.cpu_boot	= smp_spin_table_cpu_boot,
+	.cpu_postboot	= smp_spin_table_cpu_postboot,
 };
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index f5e5574..d8ca8d9 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -54,7 +54,6 @@ SECTIONS
 	}
 	.text : {			/* Real text segment		*/
 		_stext = .;		/* Text and read-only data	*/
-			*(.smp.pen.text)
 			__exception_text_start = .;
 			*(.exception.text)
 			__exception_text_end = .;
-- 
1.8.1.1



From mark.rutland at arm.com  Mon Jul 22 11:37:32 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Jul 2013 16:37:32 +0100
Subject: [PATCHv2 3/5] arm64: read enable-method for CPU0
In-Reply-To: <1374507454-4573-1-git-send-email-mark.rutland@arm.com>
References: <1374507454-4573-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1374507454-4573-4-git-send-email-mark.rutland@arm.com>

With the advent of CPU_HOTPLUG, the enable-method property for CPU0
may tells us something useful (i.e. how to hotplug it back on), so
we must read it along with all the enable-method for all the other CPUs.

This patch ensures that CPU0's enable-method property is read.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/kernel/smp.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 72c2823..f6ce2ae 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -254,6 +254,8 @@ void __init smp_init_cpus(void)
 			}
 		}
 
+		enable_method = of_get_property(dn, "enable-method", NULL);
+
 		/*
 		 * The numbering scheme requires that the boot CPU
 		 * must be assigned logical id 0. Record it so that
@@ -269,11 +271,12 @@ void __init smp_init_cpus(void)
 
 			bootcpu_valid = true;
 
+			if (enable_method)
+				smp_ops[0] = smp_get_ops(enable_method);
+
 			/*
-			 * cpu_logical_map has already been
-			 * initialized and the boot cpu doesn't need
-			 * the enable-method so continue without
-			 * incrementing cpu.
+			 * cpu_logical_map has already been initialized so
+			 * continue without incrementing cpu.
 			 */
 			continue;
 		}
@@ -281,10 +284,6 @@ void __init smp_init_cpus(void)
 		if (cpu >= NR_CPUS)
 			goto next;
 
-		/*
-		 * We currently support only the "spin-table" enable-method.
-		 */
-		enable_method = of_get_property(dn, "enable-method", NULL);
 		if (!enable_method) {
 			pr_err("%s: missing enable-method property\n",
 				dn->full_name);
-- 
1.8.1.1



From mark.rutland at arm.com  Mon Jul 22 11:37:33 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Jul 2013 16:37:33 +0100
Subject: [PATCHv2 4/5] arm64: add CPU_HOTPLUG infrastructure
In-Reply-To: <1374507454-4573-1-git-send-email-mark.rutland@arm.com>
References: <1374507454-4573-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1374507454-4573-5-git-send-email-mark.rutland@arm.com>

This patch adds the basic infrastructure necessary to support
CPU_HOTPLUG on arm64, based on the arm implementation. Actual hotplug
support will depend on an implementation's smp_operations (e.g. PSCI).

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/Kconfig           |  7 ++++
 arch/arm64/include/asm/irq.h |  1 +
 arch/arm64/include/asm/smp.h |  9 ++++
 arch/arm64/kernel/cputable.c |  2 +-
 arch/arm64/kernel/irq.c      | 61 ++++++++++++++++++++++++++++
 arch/arm64/kernel/process.c  |  7 ++++
 arch/arm64/kernel/smp.c      | 97 ++++++++++++++++++++++++++++++++++++++++++++
 7 files changed, 183 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9737e97..5ce4ccb 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -158,6 +158,13 @@ config NR_CPUS
 	default "8" if ARCH_XGENE
 	default "4"
 
+config HOTPLUG_CPU
+	bool "Support for hot-pluggable CPUs"
+	depends on SMP
+	help
+	  Say Y here to experiment with turning CPUs off and on.  CPUs
+	  can be controlled through /sys/devices/system/cpu.
+
 source kernel/Kconfig.preempt
 
 config HZ
diff --git a/arch/arm64/include/asm/irq.h b/arch/arm64/include/asm/irq.h
index 0332fc0..e1f7ecd 100644
--- a/arch/arm64/include/asm/irq.h
+++ b/arch/arm64/include/asm/irq.h
@@ -4,6 +4,7 @@
 #include <asm-generic/irq.h>
 
 extern void (*handle_arch_irq)(struct pt_regs *);
+extern void migrate_irqs(void);
 extern void set_handle_irq(void (*handle_irq)(struct pt_regs *));
 
 #endif
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index af39644..844925d 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -67,6 +67,11 @@ extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
 
 struct device_node;
 
+extern int __cpu_disable(void);
+
+extern void __cpu_die(unsigned int cpu);
+extern void cpu_die(void);
+
 struct smp_operations {
 	const char	*name;
 	/*
@@ -85,6 +90,10 @@ struct smp_operations {
 	 * Performs post-boot cleanup
 	 */
 	void		(*cpu_postboot)(void);
+#ifdef CONFIG_HOTPLUG_CPU
+	int  (*cpu_disable)(unsigned int cpu);
+	void (*cpu_die)(unsigned int cpu);
+#endif
 };
 
 extern const struct smp_operations smp_spin_table_ops;
diff --git a/arch/arm64/kernel/cputable.c b/arch/arm64/kernel/cputable.c
index 63cfc4a..fd3993c 100644
--- a/arch/arm64/kernel/cputable.c
+++ b/arch/arm64/kernel/cputable.c
@@ -22,7 +22,7 @@
 
 extern unsigned long __cpu_setup(void);
 
-struct cpu_info __initdata cpu_table[] = {
+struct cpu_info cpu_table[] = {
 	{
 		.cpu_id_val	= 0x000f0000,
 		.cpu_id_mask	= 0x000f0000,
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index ecb3354..473e5db 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -81,3 +81,64 @@ void __init init_IRQ(void)
 	if (!handle_arch_irq)
 		panic("No interrupt controller found.");
 }
+
+#ifdef CONFIG_HOTPLUG_CPU
+static bool migrate_one_irq(struct irq_desc *desc)
+{
+	struct irq_data *d = irq_desc_get_irq_data(desc);
+	const struct cpumask *affinity = d->affinity;
+	struct irq_chip *c;
+	bool ret = false;
+
+	/*
+	 * If this is a per-CPU interrupt, or the affinity does not
+	 * include this CPU, then we have nothing to do.
+	 */
+	if (irqd_is_per_cpu(d) || !cpumask_test_cpu(smp_processor_id(), affinity))
+		return false;
+
+	if (cpumask_any_and(affinity, cpu_online_mask) >= nr_cpu_ids) {
+		affinity = cpu_online_mask;
+		ret = true;
+	}
+
+	c = irq_data_get_irq_chip(d);
+	if (!c->irq_set_affinity)
+		pr_debug("IRQ%u: unable to set affinity\n", d->irq);
+	else if (c->irq_set_affinity(d, affinity, true) == IRQ_SET_MASK_OK && ret)
+		cpumask_copy(d->affinity, affinity);
+
+	return ret;
+}
+
+/*
+ * The current CPU has been marked offline.  Migrate IRQs off this CPU.
+ * If the affinity settings do not allow other CPUs, force them onto any
+ * available CPU.
+ *
+ * Note: we must iterate over all IRQs, whether they have an attached
+ * action structure or not, as we need to get chained interrupts too.
+ */
+void migrate_irqs(void)
+{
+	unsigned int i;
+	struct irq_desc *desc;
+	unsigned long flags;
+
+	local_irq_save(flags);
+
+	for_each_irq_desc(i, desc) {
+		bool affinity_broken;
+
+		raw_spin_lock(&desc->lock);
+		affinity_broken = migrate_one_irq(desc);
+		raw_spin_unlock(&desc->lock);
+
+		if (affinity_broken)
+			pr_warn_ratelimited("IRQ%u no longer affine to CPU%u\n",
+					    i, smp_processor_id());
+	}
+
+	local_irq_restore(flags);
+}
+#endif /* CONFIG_HOTPLUG_CPU */
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 1788bf6..4835a33 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -102,6 +102,13 @@ void arch_cpu_idle(void)
 	local_irq_enable();
 }
 
+#ifdef CONFIG_HOTPLUG_CPU
+void arch_cpu_idle_dead(void)
+{
+       cpu_die();
+}
+#endif
+
 void machine_shutdown(void)
 {
 #ifdef CONFIG_SMP
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index f6ce2ae..bd9c980 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -168,6 +168,103 @@ asmlinkage void secondary_start_kernel(void)
 	cpu_startup_entry(CPUHP_ONLINE);
 }
 
+#ifdef CONFIG_HOTPLUG_CPU
+static int op_cpu_disable(unsigned int cpu)
+{
+	/*
+	 * If we don't have a cpu_die method, abort before we reach the point
+	 * of no return. CPU0 may not have an smp_ops, so test for it.
+	 */
+	if (!smp_ops[cpu] || !smp_ops[cpu]->cpu_die)
+		return -EOPNOTSUPP;
+
+	/*
+	 * We may need to abort a hot unplug for some other mechanism-specific
+	 * reason.
+	 */
+	if (smp_ops[cpu]->cpu_disable)
+		return smp_ops[cpu]->cpu_disable(cpu);
+
+	return 0;
+}
+
+/*
+ * __cpu_disable runs on the processor to be shutdown.
+ */
+int __cpu_disable(void)
+{
+	unsigned int cpu = smp_processor_id();
+	int ret;
+
+	ret = op_cpu_disable(cpu);
+	if (ret)
+		return ret;
+
+	/*
+	 * Take this CPU offline.  Once we clear this, we can't return,
+	 * and we must not schedule until we're ready to give up the cpu.
+	 */
+	set_cpu_online(cpu, false);
+
+	/*
+	 * OK - migrate IRQs away from this CPU
+	 */
+	migrate_irqs();
+
+	/*
+	 * Remove this CPU from the vm mask set of all processes.
+	 */
+	clear_tasks_mm_cpumask(cpu);
+
+	return 0;
+}
+
+static DECLARE_COMPLETION(cpu_died);
+
+/*
+ * called on the thread which is asking for a CPU to be shutdown -
+ * waits until shutdown has completed, or it is timed out.
+ */
+void __cpu_die(unsigned int cpu)
+{
+	if (!wait_for_completion_timeout(&cpu_died, msecs_to_jiffies(5000))) {
+		pr_crit("CPU%u: cpu didn't die\n", cpu);
+		return;
+	}
+	pr_notice("CPU%u: shutdown\n", cpu);
+}
+
+/*
+ * Called from the idle thread for the CPU which has been shutdown.
+ *
+ * Note that we disable IRQs here, but do not re-enable them
+ * before returning to the caller. This is also the behaviour
+ * of the other hotplug-cpu capable cores, so presumably coming
+ * out of idle fixes this.
+ */
+void __ref cpu_die(void)
+{
+	unsigned int cpu = smp_processor_id();
+
+	idle_task_exit();
+
+	local_irq_disable();
+	mb();
+
+	/* Tell __cpu_die() that this CPU is now safe to dispose of */
+	RCU_NONIDLE(complete(&cpu_died));
+
+	/*
+	 * Actually shutdown the CPU. This must never fail.
+	 */
+	smp_ops[cpu]->cpu_die(cpu);
+
+	BUG();
+}
+#endif
+
+
+
 void __init smp_cpus_done(unsigned int max_cpus)
 {
 	unsigned long bogosum = loops_per_jiffy * num_online_cpus();
-- 
1.8.1.1



From mark.rutland at arm.com  Mon Jul 22 11:37:34 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Jul 2013 16:37:34 +0100
Subject: [PATCHv2 5/5] arm64: add PSCI CPU_OFF-based hotplug support
In-Reply-To: <1374507454-4573-1-git-send-email-mark.rutland@arm.com>
References: <1374507454-4573-1-git-send-email-mark.rutland@arm.com>
Message-ID: <1374507454-4573-6-git-send-email-mark.rutland@arm.com>

This patch adds support for using PSCI CPU_OFF calls for CPU hotplug.
With this code it is possible to hot unplug CPUs with "psci" as their
boot-method, as long as there's an appropriate cpu_off function id
specified in the psci node.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/kernel/smp_psci.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm64/kernel/smp_psci.c b/arch/arm64/kernel/smp_psci.c
index 20499bc..06123de 100644
--- a/arch/arm64/kernel/smp_psci.c
+++ b/arch/arm64/kernel/smp_psci.c
@@ -47,9 +47,39 @@ static int smp_psci_cpu_boot(unsigned int cpu)
 	return err;
 }
 
+#ifdef CONFIG_HOTPLUG_CPU
+static int smp_psci_cpu_disable(unsigned int cpu)
+{
+	/* Fail early if we don't have CPU_OFF support */
+	if (!psci_ops.cpu_off)
+		return -EOPNOTSUPP;
+	return 0;
+}
+
+static void smp_psci_cpu_die(unsigned int cpu)
+{
+	int ret;
+	/*
+	 * There are no known implementations of PSCI actually using the
+	 * power state field, pass a sensible default for now.
+	 */
+	struct psci_power_state state = {
+		.type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+	};
+
+	ret = psci_ops.cpu_off(state);
+
+	pr_crit("psci: unable to power off CPU%u (%d)", cpu, ret);
+}
+#endif
+
 const struct smp_operations smp_psci_ops = {
 	.name		= "psci",
 	.cpu_init	= smp_psci_cpu_init,
 	.cpu_prepare	= smp_psci_cpu_prepare,
 	.cpu_boot	= smp_psci_cpu_boot,
+#ifdef CONFIG_HOTPLUG_CPU
+	.cpu_disable	= smp_psci_cpu_disable,
+	.cpu_die	= smp_psci_cpu_die,
+#endif
 };
-- 
1.8.1.1



From shc_work at mail.ru  Mon Jul 22 11:40:57 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Mon, 22 Jul 2013 19:40:57 +0400
Subject: [RFC v2] ARM: i.MX pllv1: Implement set_rate
In-Reply-To: <1374506675.4128.6.camel@weser.hi.pengutronix.de>
References: <1374308975-20596-1-git-send-email-shc_work@mail.ru>
 <20130720111639.GA29785@pengutronix.de>
 <20130720153104.96b6723a20bde172a8ea1ba1@mail.ru>
 <20130720115829.GD29785@pengutronix.de>
 <20130720161801.380bb0d9db75155f5401730b@mail.ru>
 <20130721123759.GJ29785@pengutronix.de>
 <20130722191844.56e60280573dcab51187c9f3@mail.ru>
 <1374506675.4128.6.camel@weser.hi.pengutronix.de>
Message-ID: <20130722194057.9c75acd43fd744279725bee4@mail.ru>

On Mon, 22 Jul 2013 17:24:35 +0200
Lucas Stach <l.stach at pengutronix.de> wrote:

> Am Montag, den 22.07.2013, 19:18 +0400 schrieb Alexander Shiyan:
> > On Sun, 21 Jul 2013 14:37:59 +0200
> > Sascha Hauer <s.hauer at pengutronix.de> wrote:
> > 
> > > On Sat, Jul 20, 2013 at 04:18:01PM +0400, Alexander Shiyan wrote:
> > > > On Sat, 20 Jul 2013 13:58:29 +0200
> > > > Sascha Hauer <s.hauer at pengutronix.de> wrote:
> > > > 
> > > > > > > On Sat, Jul 20, 2013 at 12:29:35PM +0400, Alexander Shiyan wrote:
> > > > > > > > This patch implements frequency change for i.MX pllv1.
> > > > > > > > Selection of the values of the registers is not optimal, since is
> > > > > > > > made by simple enumeration of all possible values.
> > > > > > > 
> > > > > > > You do not mention why you want to adjust the rate. Normally we've been
> > > > > > > happy with the static values from the bootloader.
> > > > > > 
> > > > > > For CPUfreq.
> > > > > > Only one barrier to make it workable.
> > > > > 
> > > > > Isn't it better to adjust the dividers only? I haven't made good
> > > > > experience with adjusting the PLLs.
> > > > 
> > > > The frequency value after booting can be quite arbitrary.
> > > > 
> > > > Since we define possible frequencies for the CPU (266 and 399 MHz),
> > > > I can offer as variant to use a fixed constant values for PLL.
> > > 
> > > AFAIK the PLL should run at 800MHz. With dividers of 2, 3 and 6 we get
> > > 400, 266 and 133MHz. I don't think having more fine grained control
> > > about the CPU frequency is necessary from a power saving point of view.
> > > Let's keep the variants to a minimum to make the whole stuff more
> > > robust.
> > 
> > What about switching the source?
> > In any case, I have already made an efficient algorithm to calculate
> > the PLL and after some tests, I will introduce it.
> > Thanks.
> > 
> Both changing the divider or changing source should be glitchfree in the
> CPU clock path. Using the divider should be enough to allow to scale the
> CPU frequency with the accuracy needed for simple CPUfreq.
> 
> Using the PLL to scale the frequency is a really bad idea, as it's both
> not glitchfree on it's own plus it adds considerable delay to the clock
> change. In order to use the PLL for clock scaling you have to first
> switch the CPU away from the PLL (making sure you have an alternative
> clock path that can satisfy the CPUs requirements), then reprogram PLL,
> wait for the PLL to lock, then switch back to the PLL. Sounds utterly
> complex for a simple clock change that could be done by just flipping
> the divider bits, isn't it?

It sounds logical, but the datasheet (i.MX27) says nothing about this order:

The i.MX27 device provides a way for software to save power under different
operating conditions.
- Software determines whether to change the operation frequency or not.
- Software uses DPTC to determine whether to reduce or increase the power supply.
- After the power supply has been changed, software can update MPLL configuration.
- It restarts the MPLL and operates with new frequency.

-- 
Alexander Shiyan <shc_work at mail.ru>


From andrew at lunn.ch  Mon Jul 22 11:53:33 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 22 Jul 2013 17:53:33 +0200
Subject: [PATCH RFC v2 0/14] Clean up debugging support
In-Reply-To: <20130716163243.GY21614@n2100.arm.linux.org.uk>
References: <20130716163243.GY21614@n2100.arm.linux.org.uk>
Message-ID: <20130722155333.GB30862@lunn.ch>

On Tue, Jul 16, 2013 at 05:32:43PM +0100, Russell King - ARM Linux wrote:
> This is the second posting of this series, with a few additional patches
> on top to go a little further.  Changes since the last posting:

Hi Russell

I boot tested on Kirkwood.

Tested-by: Andrew Lunn <andrew at lunn.ch>

	   Andrew

> 
> - we now provide a couple of generic options to allow the 8250 and PL01x
>   ports to be configured via Kconfig manually.  What this means is that
>   I do not expect to see further entries to the debug menu for platforms
>   which have PL01x or 8250 debug ports - use the generic options instead.
> 
> - I've converted a bunch of the dependencies to select statements here
>   to clean things up a little more.
> 
> - Made the '8250 32-bit access size" option depend on a shift >= 2
>   (it would be silly to do 32-bit accesses to byte offsets.)
> 
> - Made all 8250 options available to the user when 8250 support is
>   selected, allowing full configuration of 8250 options.
> 
> - Removed DEBUG_ROCKCHIP_UART which wasn't doing anything after this
>   cleanup.
> 
> - Converted Keystone, Davinci, and Spear to also use the generic 8250/PL01x
>   code; these had their own private implementations of the same without
>   using the generic versions for no reason that I could see.
> 
> The rest is the same boilerplate from last time with the exception of
> the diffstat.
> 
> This patch series cleans up some aspects of the LL debug support by:
> - Removing the multi-level choice madness
> - Consolidating the 8250 debug UART support
> - Consolidating the PL01x debug UART support
> 
> The differences between the various 8250 debug UART implementations are:
> - Physical/Virtual addresses
> - Register offset shift
> - Access size
> - Flow control
> 
> These are now parameterised in the Kconfig.  I've left OMAP because
> that's a complex case, but it looks like it can be adapted to it if
> some of the unnecessary complexity is eliminated.
> 
> Similar is done with the PL01x implementation, except a few complex
> cases are left - automatic detection on Versatile Express, and the
> Ux500 support which looks like it'll take some picking through header
> files to work out what the base addresses are.
> 
> The approach I've taken is to consolidate without losing any information
> - what that means it that the Kconfig parameters have rather a lot of
> dependencies/defaults associated with them, and the main choice
> statement keeps all its options.
> 
> Nevertheless, even avoiding the loss of information, I think the diffstat
> is quite impressive:
> 
>  arch/arm/Kconfig.debug                             |  553 ++++++++++++++------
>  arch/arm/include/asm/hardware/debug-8250.S         |   29 -
>  arch/arm/include/debug/8250.S                      |   54 ++
>  arch/arm/include/debug/8250_32.S                   |   27 -
>  arch/arm/include/debug/bcm2835.S                   |   22 -
>  arch/arm/include/debug/cns3xxx.S                   |   19 -
>  arch/arm/include/debug/highbank.S                  |   17 -
>  arch/arm/include/debug/keystone.S                  |   43 --
>  arch/arm/include/debug/mvebu.S                     |   30 -
>  arch/arm/include/debug/mxs.S                       |   27 -
>  arch/arm/include/debug/nomadik.S                   |   20 -
>  arch/arm/include/debug/nspire.S                    |   28 -
>  arch/arm/include/debug/picoxcell.S                 |   19 -
>  .../{asm/hardware/debug-pl01x.S => debug/pl01x.S}  |    9 +-
>  arch/arm/include/debug/pxa.S                       |   33 --
>  arch/arm/include/debug/rockchip.S                  |   42 --
>  arch/arm/include/debug/socfpga.S                   |   21 -
>  arch/arm/include/debug/sunxi.S                     |   27 -
>  arch/arm/include/debug/u300.S                      |   18 -
>  arch/arm/include/debug/ux500.S                     |    2 +-
>  arch/arm/include/debug/vexpress.S                  |   48 +--
>  arch/arm/mach-davinci/include/mach/debug-macro.S   |   65 ---
>  arch/arm/mach-dove/include/mach/debug-macro.S      |   19 -
>  arch/arm/mach-ebsa110/include/mach/debug-macro.S   |   22 -
>  arch/arm/mach-ep93xx/include/mach/debug-macro.S    |   21 -
>  .../arm/mach-footbridge/include/mach/debug-macro.S |   15 -
>  arch/arm/mach-gemini/include/mach/debug-macro.S    |   21 -
>  .../arm/mach-integrator/include/mach/debug-macro.S |   20 -
>  arch/arm/mach-iop13xx/include/mach/debug-macro.S   |   24 -
>  arch/arm/mach-iop32x/include/mach/debug-macro.S    |   21 -
>  arch/arm/mach-iop33x/include/mach/debug-macro.S    |   22 -
>  arch/arm/mach-ixp4xx/include/mach/debug-macro.S    |   26 -
>  arch/arm/mach-kirkwood/include/mach/debug-macro.S  |   19 -
>  arch/arm/mach-lpc32xx/include/mach/debug-macro.S   |   29 -
>  arch/arm/mach-mv78xx0/include/mach/debug-macro.S   |   19 -
>  arch/arm/mach-orion5x/include/mach/debug-macro.S   |   21 -
>  arch/arm/mach-realview/include/mach/debug-macro.S  |   29 -
>  arch/arm/mach-rpc/include/mach/debug-macro.S       |   23 -
>  arch/arm/mach-spear/include/mach/debug-macro.S     |   36 --
>  arch/arm/mach-spear/include/mach/spear.h           |    2 -
>  arch/arm/mach-versatile/include/mach/debug-macro.S |   21 -
>  41 files changed, 457 insertions(+), 1106 deletions(-)
>  delete mode 100644 arch/arm/include/asm/hardware/debug-8250.S
>  create mode 100644 arch/arm/include/debug/8250.S
>  delete mode 100644 arch/arm/include/debug/8250_32.S
>  delete mode 100644 arch/arm/include/debug/bcm2835.S
>  delete mode 100644 arch/arm/include/debug/cns3xxx.S
>  delete mode 100644 arch/arm/include/debug/highbank.S
>  delete mode 100644 arch/arm/include/debug/keystone.S
>  delete mode 100644 arch/arm/include/debug/mvebu.S
>  delete mode 100644 arch/arm/include/debug/mxs.S
>  delete mode 100644 arch/arm/include/debug/nomadik.S
>  delete mode 100644 arch/arm/include/debug/nspire.S
>  delete mode 100644 arch/arm/include/debug/picoxcell.S
>  rename arch/arm/include/{asm/hardware/debug-pl01x.S => debug/pl01x.S} (78%)
>  delete mode 100644 arch/arm/include/debug/pxa.S
>  delete mode 100644 arch/arm/include/debug/rockchip.S
>  delete mode 100644 arch/arm/include/debug/socfpga.S
>  delete mode 100644 arch/arm/include/debug/sunxi.S
>  delete mode 100644 arch/arm/include/debug/u300.S
>  delete mode 100644 arch/arm/mach-davinci/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-dove/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-ebsa110/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-ep93xx/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-gemini/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-integrator/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-iop13xx/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-iop32x/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-iop33x/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-ixp4xx/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-kirkwood/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-lpc32xx/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-mv78xx0/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-orion5x/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-realview/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-rpc/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-spear/include/mach/debug-macro.S
>  delete mode 100644 arch/arm/mach-versatile/include/mach/debug-macro.S


From santosh.shilimkar at ti.com  Mon Jul 22 12:23:02 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 22 Jul 2013 12:23:02 -0400
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <51ED2385.60108@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <51E83A4F.5080904@ti.com>
 <CACRpkdY3nQaWimTwB-Zt-8+Q_KZr8a0rpB1SUQq=AuoG4bAYnQ@mail.gmail.com>
 <51ED2385.60108@ti.com>
Message-ID: <51ED5C66.1010407@ti.com>

On Monday 22 July 2013 08:20 AM, Sricharan R wrote:
> Hi Linus,
> On Sunday 21 July 2013 10:19 PM, Linus Walleij wrote:
>> On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon <nm at ti.com> wrote:
>>
>>> I carry forward my TI internal objection to this approach:
>> It is actually a very good sign of FOSS-maturity that you as a company
>> take unresolved architectural issues to the community. Kudos!
>>
>>> Lets see what happens as a result of this:
>>>
>>> https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
>>> uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
>>> uart1: serial at 4806a000 {
>>> <snip>
>>> +                       interrupts = <0 72 0x4>;
>>> Assumes that GIC interrupt by default mapping used.
>> So introducing this inbetween the GIC lines and its actual device IRQ
>> lines inevitably means that the GIC three-cell concept is completely
>> ill-devised to handle this.
>>
>> For routing IRQs, I think the proper solution would be to use a
>> cascaded struct irqchip, which in turn contains an irqdomain
>> translation to remux the signal onto the GIC inputs.
>>
>> I.e. the interrupt-controller given to that serial would be the
>> crossbar irqchip, and that in turn will hog and allocate apropriate
>> lines from the gic to it would probably itself list *all* the IRQs
>> of the GIC as "its" IRQs.
>>
>> We already have plenty of cascading irqchips such as GPIO
>> controller providing IRQs, just that they only multiplex on a
>> single GIC line instead of the whole lot.
>>
>> Mock example:
>>
>>                 intc: interrupt-controller at 0 {
>>                         compatible = "arm,cortex-a9-gic";
>>                         #interrupt-cells = <3>;
>>                         #address-cells = <1>;
>>                         interrupt-controller;
>>                         reg = ...;
>>                 };
>>
>>                 crossbar: crossbar at 0 {
>>                         compatible = "...";
>>                         interrupt-controller;
>>                         #interrupt-cells = <1>;
>>                         interrupt-parent = <&intc>;
>>                         interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
>>                                           <0 1 IRQ_TYPE_LEVEL_HIGH>,
>>                                           <0 2 IRQ_TYPE_LEVEL_HIGH>,
>>                                           ....
>>                                           <0 n IRQ_TYPE_LEVEL_HIGH>;
>>                 };
>>
>>                 uart0: serial at 0 {
>>                         compatible = "...";
>>                         interrupt-parent = <&crossbar>;
>>                         interrupts = <1234>;
>>                  };
>>
>> Maybe the interrupts provided from crossbar cannot even be
>> specified by a number, maybe a line name need to be used
>> or so. I don't know the particulars.
>>
>> Whether this as a whole is a good idea, I don't know,
>> but you would have to go about it something like this.
>>
>> What happens if there is no line to mux in a certain IRQ?
>  Thanks for this.
>  Was thinking of a similar kind of approach with irqchip.
>  But then, there was a GAP since crossbar does not have an irq unlike
>  other irqchips. But as you said  this can be done by setting the crossbar
>  to map and receive the GIC interrupts and then direct to devices.
>  Only thing is, this is fine for IRQs, and something different has to be done
>  for DMA crossbars  again. Also when we allocate dynamically here,
>  finding out a irq line when there is no free line is a question.
> 
>   With the other approach of using/extending  the pinctrl framework that you
>  gave, it is good to handle both irqs/dma.  I looked at the other example in
>  drivers/dma/amba-pl08x.c and i see that data is getting populated and passed
>  from the platform. I initially started with something similar, where the data
>  was passed statically from DT and a driver to use that.  So now it looks good
>  to extend the pinctrl fw. I will try a approach for that first and see how it looks.
> 
Right. Thats the reason its not a typical chained IRQChip like GPIO, MFD PMIC etc etc.
Those chips always has a primary interrupt line and then secondary interrupts which
are kind of controlled at SW level(secondary logical IRQs) using some common
registers.

Cross-bar is just a dummy hardware. The only interesting part from IRQ chip
or DMA subsystem is "request_irq" or "request_dma" look-up which happens
at driver probe ideally should be transparent and then program the appropriate
cross-bar mux for IRQ or DMA routing. The actual IRQ assertion reporting or ISR
execution etc all has to be handled by primary IRQ controller since the cross-bar
has no intelligence or IRQ controller like capability.

To summaries it again, what I understood from Sricharan's proposal,

- Setup all the routing at cross-bar probe so that kernel continue to
work like normal IRQ controller with cross-bar scope vanishes once
the routing is done. Cross-bar does this before any of the devices
are created.
- Something similar needs to happen for DMA lines as well or for any
other event routing in future.
- Cross-bar callbacks for device drivers for error paths.
(Sricharan, you have to drop these because it doesn't bring any
functionality and rather can create a side effects of drivers
getting polluted.)

The concern raised on above was instead of fixing the routing at DT
statically, doing at the driver probes where the loop-up for IRQ or DMA
lines should happen in background transparently on drivers call of
request_irq/request_dma_channel etc with cross-bar number as
an input to it. Though it will be nice to have
such feature, it doesn't bring anything special and brings the
notion of these APIs which expect that you know what IRQ and DMA
lines you want while calling these.

Note that mux inputs are pretty much fixed. Its his connection
to IRQ controller or DMA controller is what needs to be programmed.
So scope is pretty much limited. I felt this requirement is pretty
similar to pin-mux and hence thought of it as a viable option.

Having said all of above, if there is a better alternative than
enhanced pin-mux we surely can do that.

Regards,
Santosh 


















From sboyd at codeaurora.org  Mon Jul 22 12:23:37 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 22 Jul 2013 09:23:37 -0700
Subject: [PATCH v4 10/17] clocksource: mxs_timer: Switch to
 sched_clock_register()
In-Reply-To: <20130722081025.GE20271@S2101-09.ap.freescale.net>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-11-git-send-email-sboyd@codeaurora.org>
 <20130722081025.GE20271@S2101-09.ap.freescale.net>
Message-ID: <20130722162337.GA19639@codeaurora.org>

On 07/22, Shawn Guo wrote:
> On Thu, Jul 18, 2013 at 04:21:23PM -0700, Stephen Boyd wrote:
> > The 32 bit sched_clock interface now supports 64 bits. Upgrade to
> > the 64 bit function to allow us to remove the 32 bit registration
> > interface.
> > 
> > Cc: Shawn Guo <shawn.guo at linaro.org>
> 
> Acked-by: Shawn Guo <shawn.guo at linaro.org>
> 
> BTW, will the series break setup_sched_clock() users that are not
> converted, like arch/arm/mach-imx/time.c?  I can understand that's the
> consequence of not moving things into drivers/ folder :)

Thanks.

I will convert all arch/arm users when this series is pulled into
the tip tree. The arm patches will have to go through the arm-soc
branch and so we'll need some stable branch in tip for that.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From sboyd at codeaurora.org  Mon Jul 22 12:24:34 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 22 Jul 2013 09:24:34 -0700
Subject: [PATCH v4 00/17] 64-bit friendly generic sched_clock()
In-Reply-To: <CACRpkdauSuk9xDSzUFN=OO0yVWZXSMTUuYTVDZb2_zYb=YMW_A@mail.gmail.com>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <CACRpkdauSuk9xDSzUFN=OO0yVWZXSMTUuYTVDZb2_zYb=YMW_A@mail.gmail.com>
Message-ID: <20130722162434.GB19639@codeaurora.org>

On 07/20, Linus Walleij wrote:
> On Fri, Jul 19, 2013 at 1:21 AM, Stephen Boyd <sboyd at codeaurora.org> wrote:
> 
> > This patchset adds support for 64 bit counters in the generic
> > sched_clock code and converts drivers over to use it. Based
> > on v3.11-rc1.
> >
> > Changes since v3:
> 
> >   ocksource: dbx500-prcmu: Switch to sched_clock_register()
> 
> Fix subject.
> 
> >   clocksource: nomadik: Switch to sched_clock_register()
> 
> Apart from that Acked-by: Linus Walleij <linus.walleij at linaro.org>
> for these two drivers.
> 
> BTW: why are you not patching arch/arm/mach-u300/timer.c?
> Please make sure to grep for all setup_sched_clock() if you're
> going to do this.

Thanks.

I'll convert the arch/arm users once this series is accepted into
the tip tree. Then send off the rest through the arm-soc tree.


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From t.figa at samsung.com  Mon Jul 22 12:28:47 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 18:28:47 +0200
Subject: [PATCH 2/4] clk: exynos-audss: allow input clocks to be specified
 in device tree
In-Reply-To: <1373458313-18970-3-git-send-email-padma.v@samsung.com>
References: <1373458313-18970-1-git-send-email-padma.v@samsung.com>
 <1373458313-18970-3-git-send-email-padma.v@samsung.com>
Message-ID: <1610421.OFFn8rqlxt@amdc1227>

Hi Padmavathi, Andrew,

On Wednesday 10 of July 2013 17:41:51 Padmavathi Venna wrote:
> From: Andrew Bresticker <abrestic at chromium.org>
> 
> This allows the input clocks to the Exynos AudioSS block to be specified
> via device-tree bindings.  Default names will be used when an input clock
> is not given.  This will be useful when adding support for the
> Exynos5420 where the audio bus clock is called "sclk_maudio0" instead of
> "sclk_audio0".
> 
> Signed-off-by: Andrew Bresticker <abrestic at chromium.org>
> Reviewed-on: https://gerrit.chromium.org/gerrit/57833
> Reviewed-by: Simon Glass <sjg at chromium.org>
> ---
>  .../devicetree/bindings/clock/clk-exynos-audss.txt |   31
> ++++++++++++++++++- drivers/clk/samsung/clk-exynos-audss.c             |
>   28 +++++++++++++++-- 2 files changed, 53 insertions(+), 6 deletions(-)

Well, this is basically how it should be done, but in current state of 
clock core I can see a problem: can we really rely on the order of clock 
initialization? I mean, we can't defer initialization of particular clock 
controller until all external clocks it needs are available, because there 
is no probing involved here.

Best regards,
Tomasz



From linux at arm.linux.org.uk  Mon Jul 22 12:31:55 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Jul 2013 17:31:55 +0100
Subject: [GIT PULL] ARM: kernel mode NEON support
In-Reply-To: <CAKv+Gu_0XXdCw4-V6LLHCiaH4Wc+=4DTzP6gwgV_h-Qb90gYTA@mail.gmail.com>
References: <CAKv+Gu_0XXdCw4-V6LLHCiaH4Wc+=4DTzP6gwgV_h-Qb90gYTA@mail.gmail.com>
Message-ID: <20130722163155.GN24642@n2100.arm.linux.org.uk>

On Mon, Jul 08, 2013 at 11:23:11PM +0100, Ard Biesheuvel wrote:
> The following changes since commit 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376:
> 
>   Linux 3.10 (2013-06-30 15:13:29 -0700)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/ardbiesheuvel/linux-arm.git for-rmk
> 
> for you to fetch changes up to 7d11965ddb9b9b1e0a5d13c58345ada1ccbc663b:
> 
>   lib/raid6: add ARM-NEON accelerated syndrome calculation (2013-07-08
> 22:09:18 +0100)

I'm assuming that the comments in your previous postings are valid as I've
included those in the merge commit:

    I have included two use cases that I have been using, XOR and RAID-6
    checksumming. The former gets a 60% performance boost on the NEON, the
    latter over 400%.

    ARM: add support for kernel mode NEON

    Adds kernel_neon_begin/end (renamed from kernel_vfp_begin/end in the
    previous version to de-emphasize the VFP part as VFP code that needs
    software assistance is not supported currently.)

    Introduces <asm/neon.h> and the Kconfig symbol KERNEL_MODE_NEON. This
    has been aligned with Catalin for arm64, so any NEON code that does
    not use assembly but intrinsics or the GCC vectorizer (such as my
    examples) can potentially be shared between arm and arm64 archs.

    ARM: move VFP init to an earlier boot stage

    This is needed so the NEON is enabled when the XOR and RAID-6 algo
    boot time benchmarks are run.

    ARM: be strict about FP exceptions in kernel mode

    This adds a check to vfp_support_entry() to flag unsupported uses of
    the NEON/VFP in kernel mode. FP exceptions (bounces) are flagged as
    a BUG(), this is because of their potentially intermittent nature.
    Exceptions caused by the fact that kernel_neon_begin has not been
    called are just routed through the undef handler.

    ARM: crypto: add NEON accelerated XOR implementation

    This is the xor_blocks() implementation built with -ftree-vectorize,
    60% faster than optimized ARM code. It calls in_interrupt() to check
    whether the NEON flavor can be used: this should really not be
    necessary, but due to xor_blocks'squite generic nature, there is no
    telling how exactly people may be using it in the real world.

    lib/raid6: add ARM-NEON accelerated syndrome calculation

    This is a port of the RAID-6 checksumming code in altivec.uc ported
    to use NEON intrinsics. It is about 4x faster than the sequential
    code.



From ben.dooks at codethink.co.uk  Mon Jul 22 12:33:49 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 22 Jul 2013 17:33:49 +0100
Subject: updates for be8 patch series
Message-ID: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>

I've updated the BE8 patch series after running further tests on the
kernel. I found an issue with the alignment handler (and I believe the
same issue with the trap handler).

I also ran tests with the module loader, which shows that if we are
in BE8 that it needs to fix up the relocations. Also the modules need
to be built --be8 otherwise they cannot be easily relocated when loaded.

Should patches 3 and 4 be together (ie, alter the LDFLAGS and the
module.c) and have I got the correct LDLAGS?

Comments and testing welcome. I will push out a new series later with
these in and possibly rebased on 3.11-rc2.



From ben.dooks at codethink.co.uk  Mon Jul 22 12:33:51 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 22 Jul 2013 17:33:51 +0100
Subject: [PATCH 2/4] ARM: traps: use <asm/opcodes.h> to get correct
 instruction order
In-Reply-To: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374510833-25716-3-git-send-email-ben.dooks@codethink.co.uk>

The trap handler needs to take into account the endian configuration of
the system when loading instructions. Use <asm/opcodes.h> to provide the
necessary conversion functions.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/kernel/traps.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 1c08911..0a56e13 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -34,6 +34,7 @@
 #include <asm/unwind.h>
 #include <asm/tls.h>
 #include <asm/system_misc.h>
+#include <asm/opcodes.h>
 
 #include "signal.h"
 
@@ -411,23 +412,24 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
 	if (processor_mode(regs) == SVC_MODE) {
 #ifdef CONFIG_THUMB2_KERNEL
 		if (thumb_mode(regs)) {
-			instr = ((u16 *)pc)[0];
+			instr = __mem_to_opcode_thumb16(((u16 *)pc)[0]);
 			if (is_wide_instruction(instr)) {
 				instr <<= 16;
-				instr |= ((u16 *)pc)[1];
+				instr |= __mem_to_opcode_thumb16(((u16 *)pc)[1]);
 			}
 		} else
 #endif
-			instr = *(u32 *) pc;
+			instr = __mem_to_opcode_arm(*(u32 *) pc);
 	} else if (thumb_mode(regs)) {
 		if (get_user(instr, (u16 __user *)pc))
 			goto die_sig;
+		instr = __mem_to_opcode_thumb16(instr);
 		if (is_wide_instruction(instr)) {
 			unsigned int instr2;
 			if (get_user(instr2, (u16 __user *)pc+1))
 				goto die_sig;
 			instr <<= 16;
-			instr |= instr2;
+			instr |= __mem_to_opcode_thumb16(instr2);
 		}
 	} else if (get_user(instr, (u32 __user *)pc)) {
 		goto die_sig;
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Mon Jul 22 12:33:50 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 22 Jul 2013 17:33:50 +0100
Subject: [PATCH 1/4] ARM: alignment: correctly decode instructions in BE8 mode.
In-Reply-To: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374510833-25716-2-git-send-email-ben.dooks@codethink.co.uk>

If we are in BE8 mode, we must deal with the instruction stream being
in LE order when data is being loaded in BE order. Ensure the data is
swapped before processing to avoid thre following:

Change to using <asm/opcodes.h> to provide the necessary conversion
functions to change the byte ordering.

Alignment trap: not handling instruction 030091e8 at [<80333e8c>]
Unhandled fault: alignment exception (0x001) at 0xbfa09567

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/mm/alignment.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index db26e2e..295d615 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -25,6 +25,7 @@
 #include <asm/cp15.h>
 #include <asm/system_info.h>
 #include <asm/unaligned.h>
+#include <asm/opcodes.h>
 
 #include "fault.h"
 
@@ -762,21 +763,24 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
 	if (thumb_mode(regs)) {
 		u16 *ptr = (u16 *)(instrptr & ~1);
 		fault = probe_kernel_address(ptr, tinstr);
+		tinstr = __mem_to_opcode_thumb16(tinstr);
 		if (!fault) {
 			if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
 			    IS_T32(tinstr)) {
 				/* Thumb-2 32-bit */
 				u16 tinst2 = 0;
 				fault = probe_kernel_address(ptr + 1, tinst2);
+				tinst2 = __mem_to_opcode_thumb16(tinst2);
 				instr = (tinstr << 16) | tinst2;
 				thumb2_32b = 1;
 			} else {
 				isize = 2;
-				instr = thumb2arm(tinstr);
 			}
 		}
-	} else
+	} else {
 		fault = probe_kernel_address(instrptr, instr);
+		instr = __mem_to_opcode_arm(instr);
+	}
 
 	if (fault) {
 		type = TYPE_FAULT;
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Mon Jul 22 12:33:53 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 22 Jul 2013 17:33:53 +0100
Subject: [PATCH 4/4] ARM: set --be8 when linking modules
In-Reply-To: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374510833-25716-5-git-send-email-ben.dooks@codethink.co.uk>

To avoid having to make every text section swap the instruction order
of all instructions, make sure modules are built also built with --be8
(as is the current kernel final link).

If we do not do this, we would end up having to swap all instructions
when loading a module, instead of just the instructions that we are
applying ELF relocations to.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/Makefile |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ee4605f..8173883 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -16,6 +16,7 @@ LDFLAGS		:=
 LDFLAGS_vmlinux	:=-p --no-undefined -X
 ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
 LDFLAGS_vmlinux	+= --be8
+LDFLAGS_MODULE	+= --be8
 endif
 
 OBJCOPYFLAGS	:=-O binary -R .comment -S
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Mon Jul 22 12:33:52 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 22 Jul 2013 17:33:52 +0100
Subject: [PATCH 3/4] ARM: module: correctly relocate instructions in BE8
In-Reply-To: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374510833-25716-4-git-send-email-ben.dooks@codethink.co.uk>

When in BE8 mode, our instructions are not in the same ordering as the
data, so use <asm/opcodes.h> to take this into account.

Note, also requires modules to be built --be8

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/kernel/module.c |   57 +++++++++++++++++++++++++++-------------------
 1 file changed, 34 insertions(+), 23 deletions(-)

diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 1e9be5d..7e13787 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -24,6 +24,7 @@
 #include <asm/sections.h>
 #include <asm/smp_plat.h>
 #include <asm/unwind.h>
+#include <asm/opcodes.h>
 
 #ifdef CONFIG_XIP_KERNEL
 /*
@@ -60,6 +61,7 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 		Elf32_Sym *sym;
 		const char *symname;
 		s32 offset;
+		u32 tmp;
 #ifdef CONFIG_THUMB2_KERNEL
 		u32 upper, lower, sign, j1, j2;
 #endif
@@ -95,7 +97,8 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 		case R_ARM_PC24:
 		case R_ARM_CALL:
 		case R_ARM_JUMP24:
-			offset = (*(u32 *)loc & 0x00ffffff) << 2;
+			offset = __mem_to_opcode_arm(*(u32 *)loc);
+			offset = (offset & 0x00ffffff) << 2;
 			if (offset & 0x02000000)
 				offset -= 0x04000000;
 
@@ -111,9 +114,10 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 			}
 
 			offset >>= 2;
+			offset &= 0x00ffffff;
 
-			*(u32 *)loc &= 0xff000000;
-			*(u32 *)loc |= offset & 0x00ffffff;
+			*(u32 *)loc &= __opcode_to_mem_arm(0xff000000);
+			*(u32 *)loc |= __opcode_to_mem_arm(offset);
 			break;
 
 	       case R_ARM_V4BX:
@@ -121,8 +125,8 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 			* other bits to re-code instruction as
 			* MOV PC,Rm.
 			*/
-		       *(u32 *)loc &= 0xf000000f;
-		       *(u32 *)loc |= 0x01a0f000;
+		       *(u32 *)loc &= __opcode_to_mem_arm(0xf000000f);
+		       *(u32 *)loc |= __opcode_to_mem_arm(0x01a0f000);
 		       break;
 
 		case R_ARM_PREL31:
@@ -132,7 +136,7 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 
 		case R_ARM_MOVW_ABS_NC:
 		case R_ARM_MOVT_ABS:
-			offset = *(u32 *)loc;
+			offset = tmp = __mem_to_opcode_arm(*(u32 *)loc);
 			offset = ((offset & 0xf0000) >> 4) | (offset & 0xfff);
 			offset = (offset ^ 0x8000) - 0x8000;
 
@@ -140,16 +144,18 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 			if (ELF32_R_TYPE(rel->r_info) == R_ARM_MOVT_ABS)
 				offset >>= 16;
 
-			*(u32 *)loc &= 0xfff0f000;
-			*(u32 *)loc |= ((offset & 0xf000) << 4) |
-					(offset & 0x0fff);
+			tmp &= 0xfff0f000;
+			tmp |= ((offset & 0xf000) << 4) |
+				(offset & 0x0fff);
+
+			*(u32 *)loc = __opcode_to_mem_arm(tmp);
 			break;
 
 #ifdef CONFIG_THUMB2_KERNEL
 		case R_ARM_THM_CALL:
 		case R_ARM_THM_JUMP24:
-			upper = *(u16 *)loc;
-			lower = *(u16 *)(loc + 2);
+			upper = __mem_to_opcode_thumb16(*(u16 *)loc);
+			lower = __mem_to_opcode_thumb16(*(u16 *)(loc + 2));
 
 			/*
 			 * 25 bit signed address range (Thumb-2 BL and B.W
@@ -198,17 +204,20 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 			sign = (offset >> 24) & 1;
 			j1 = sign ^ (~(offset >> 23) & 1);
 			j2 = sign ^ (~(offset >> 22) & 1);
-			*(u16 *)loc = (u16)((upper & 0xf800) | (sign << 10) |
+			upper = (u16)((upper & 0xf800) | (sign << 10) |
 					    ((offset >> 12) & 0x03ff));
-			*(u16 *)(loc + 2) = (u16)((lower & 0xd000) |
-						  (j1 << 13) | (j2 << 11) |
-						  ((offset >> 1) & 0x07ff));
+			lower = (u16)((lower & 0xd000) |
+				      (j1 << 13) | (j2 << 11) |
+				      ((offset >> 1) & 0x07ff));
+
+			*(u16 *)loc = __opcode_to_mem_thumb16(upper);
+			*(u16 *)(loc + 2) = __opcode_to_mem_thumb16(lower);
 			break;
 
 		case R_ARM_THM_MOVW_ABS_NC:
 		case R_ARM_THM_MOVT_ABS:
-			upper = *(u16 *)loc;
-			lower = *(u16 *)(loc + 2);
+			upper = __mem_to_opcode_thumb16(*(u16 *)loc);
+			lower = __mem_to_opcode_thumb16(*(u16 *)(loc + 2));
 
 			/*
 			 * MOVT/MOVW instructions encoding in Thumb-2:
@@ -229,12 +238,14 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 			if (ELF32_R_TYPE(rel->r_info) == R_ARM_THM_MOVT_ABS)
 				offset >>= 16;
 
-			*(u16 *)loc = (u16)((upper & 0xfbf0) |
-					    ((offset & 0xf000) >> 12) |
-					    ((offset & 0x0800) >> 1));
-			*(u16 *)(loc + 2) = (u16)((lower & 0x8f00) |
-						  ((offset & 0x0700) << 4) |
-						  (offset & 0x00ff));
+			upper = (u16)((upper & 0xfbf0) |
+				      ((offset & 0xf000) >> 12) |
+				      ((offset & 0x0800) >> 1));
+			lower = (u16)((lower & 0x8f00) |
+				      ((offset & 0x0700) << 4) |
+				      (offset & 0x00ff));
+			*(u16 *)loc = __opcode_to_mem_thumb16(upper);
+			*(u16 *)(loc + 2) = __opcode_to_mem_thumb16(lower);
 			break;
 #endif
 
-- 
1.7.10.4



From ard.biesheuvel at linaro.org  Mon Jul 22 12:45:31 2013
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Jul 2013 18:45:31 +0200
Subject: [GIT PULL] ARM: kernel mode NEON support
In-Reply-To: <20130722163155.GN24642@n2100.arm.linux.org.uk>
References: <CAKv+Gu_0XXdCw4-V6LLHCiaH4Wc+=4DTzP6gwgV_h-Qb90gYTA@mail.gmail.com>
 <20130722163155.GN24642@n2100.arm.linux.org.uk>
Message-ID: <CAKv+Gu9=7tg0u-X59u_wpZEk=w+uUQW_TWXNppfn1u24nm4oNw@mail.gmail.com>

On 22 July 2013 18:31, Russell King - ARM Linux <linux at arm.linux.org.uk> wrote:
> On Mon, Jul 08, 2013 at 11:23:11PM +0100, Ard Biesheuvel wrote:
>> The following changes since commit 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376:
>>
>>   Linux 3.10 (2013-06-30 15:13:29 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.linaro.org/people/ardbiesheuvel/linux-arm.git for-rmk
>>
>> for you to fetch changes up to 7d11965ddb9b9b1e0a5d13c58345ada1ccbc663b:
>>
>>   lib/raid6: add ARM-NEON accelerated syndrome calculation (2013-07-08
>> 22:09:18 +0100)
>
> I'm assuming that the comments in your previous postings are valid as I've
> included those in the merge commit:
>

I think they're close enough. I did remove the BUG() call in the
kernel mode FP exception handler, as just returning from that function
will cause an oops to be triggered anyway.

Cheers,
-- 
Ard.

>     I have included two use cases that I have been using, XOR and RAID-6
>     checksumming. The former gets a 60% performance boost on the NEON, the
>     latter over 400%.
>
>     ARM: add support for kernel mode NEON
>
>     Adds kernel_neon_begin/end (renamed from kernel_vfp_begin/end in the
>     previous version to de-emphasize the VFP part as VFP code that needs
>     software assistance is not supported currently.)
>
>     Introduces <asm/neon.h> and the Kconfig symbol KERNEL_MODE_NEON. This
>     has been aligned with Catalin for arm64, so any NEON code that does
>     not use assembly but intrinsics or the GCC vectorizer (such as my
>     examples) can potentially be shared between arm and arm64 archs.
>
>     ARM: move VFP init to an earlier boot stage
>
>     This is needed so the NEON is enabled when the XOR and RAID-6 algo
>     boot time benchmarks are run.
>
>     ARM: be strict about FP exceptions in kernel mode
>
>     This adds a check to vfp_support_entry() to flag unsupported uses of
>     the NEON/VFP in kernel mode. FP exceptions (bounces) are flagged as
>     a BUG(), this is because of their potentially intermittent nature.
>     Exceptions caused by the fact that kernel_neon_begin has not been
>     called are just routed through the undef handler.
>
>     ARM: crypto: add NEON accelerated XOR implementation
>
>     This is the xor_blocks() implementation built with -ftree-vectorize,
>     60% faster than optimized ARM code. It calls in_interrupt() to check
>     whether the NEON flavor can be used: this should really not be
>     necessary, but due to xor_blocks'squite generic nature, there is no
>     telling how exactly people may be using it in the real world.
>
>     lib/raid6: add ARM-NEON accelerated syndrome calculation
>
>     This is a port of the RAID-6 checksumming code in altivec.uc ported
>     to use NEON intrinsics. It is about 4x faster than the sequential
>     code.
>


From ben.dooks at codethink.co.uk  Mon Jul 22 12:49:04 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 22 Jul 2013 17:49:04 +0100
Subject: updates for be8 patch series
In-Reply-To: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <51ED6280.7020901@codethink.co.uk>

On 22/07/13 17:33, Ben Dooks wrote:
> I've updated the BE8 patch series after running further tests on the
> kernel. I found an issue with the alignment handler (and I believe the
> same issue with the trap handler).
>
> I also ran tests with the module loader, which shows that if we are
> in BE8 that it needs to fix up the relocations. Also the modules need
> to be built --be8 otherwise they cannot be easily relocated when loaded.
>
> Should patches 3 and 4 be together (ie, alter the LDFLAGS and the
> module.c) and have I got the correct LDLAGS?
>
> Comments and testing welcome. I will push out a new series later with
> these in and possibly rebased on 3.11-rc2.

New series based on 3.10 at:

	git://git.baserock.org/delta/linux.git
		baserock/311/be/core-v3
		baserock/311/be/atags-v3

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From paul at pwsan.com  Mon Jul 22 12:55:29 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 22 Jul 2013 16:55:29 +0000 (UTC)
Subject: linux-3.11-rc1: Internal error: Oops - undefined instruction:
 0 [#1] SMP ARM on OMAP3/AM335x
In-Reply-To: <51ECFBAC.7090900@ti.com>
References: <51ECFBAC.7090900@ti.com>
Message-ID: <alpine.DEB.2.02.1307221652350.10891@utopia.booyaka.com>

On Mon, 22 Jul 2013, Roger Quadros wrote:

> I observe the following problem on booting v3.11-rc1 on OMAP3 beagle board.
> 
> [    5.888946] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> [    5.896057] Modules linked in:
> [    5.899322] CPU: 0 PID: 9 Comm: rcu_sched Not tainted 3.11.0-rc2-00001-g1ea701a #876
> [    5.907501] task: ce0720c0 ti: ce07a000 task.ti: ce07a000
> [    5.913208] PC is at check_and_switch_context+0x130/0x4dc
> [    5.918914] LR is at check_and_switch_context+0xd8/0x4dc

It affects 3730beaglexm and am335xbonelt here too.

http://www.pwsan.com/omap/testlogs/test_v3.11-rc2/20130721203314/boot/am335xbonelt/am335x-bone/am335xbonelt_log.txt
http://www.pwsan.com/omap/testlogs/test_v3.11-rc2/20130721203314/boot/3730beaglexm/3730beaglexm_log.txt


- Paul


From plagnioj at jcrosoft.com  Mon Jul 22 12:57:07 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 22 Jul 2013 18:57:07 +0200
Subject: [PATCH 04/22] ARM: at91: dt: Remove '0x's from Animeo IP DTS file
In-Reply-To: <1374490361-25769-4-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-4-git-send-email-lee.jones@linaro.org>
Message-ID: <20130722165707.GJ16015@ns203013.ovh.net>

On 11:52 Mon 22 Jul     , Lee Jones wrote:
> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  arch/arm/boot/dts/animeo_ip.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/animeo_ip.dts b/arch/arm/boot/dts/animeo_ip.dts
> index 3a1de9e..4cb0342 100644
> --- a/arch/arm/boot/dts/animeo_ip.dts
> +++ b/arch/arm/boot/dts/animeo_ip.dts
> @@ -105,7 +105,7 @@
>  				reg = <0x48000 0x8000>;
>  			};
>  
> -			user_block at 0x50000 {
> +			user_block at 50000 {
>  				label = "user_block";
>  				reg = <0x50000 0xb0000>;
>  			};
> -- 
> 1.8.1.2
> 


From csd at broadcom.com  Mon Jul 22 12:57:42 2013
From: csd at broadcom.com (Christian Daudt)
Date: Mon, 22 Jul 2013 09:57:42 -0700
Subject: [PATCH 05/22] ARM: dts: bcm281xx: Remove '0x's from
 BCM11351 BRT DTS file
In-Reply-To: <51ED3971.905@broadcom.com>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-5-git-send-email-lee.jones@linaro.org>
 <51ED2D90.4020209@broadcom.com> <20130722133852.GA26801@laptop>
 <51ED3971.905@broadcom.com>
Message-ID: <51ED6486.3080700@broadcom.com>

On 13-07-22 06:53 AM, Arend van Spriel wrote:
> On 07/22/2013 03:38 PM, Lee Jones wrote:
>> On Mon, 22 Jul 2013, Christian Daudt wrote:
>>
>>> On 13-07-22 03:52 AM, Lee Jones wrote:
>>>> Cc: Christian Daudt <csd at broadcom.com>
>>>> Signed-off-by: Lee Jones <lee.jones at linaro.org>
>>>> ---
>>>>   arch/arm/boot/dts/bcm11351-brt.dts | 6 +++---
>>>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/bcm11351-brt.dts 
>>>> b/arch/arm/boot/dts/bcm11351-brt.dts
>>>> index 67ec524..fdace5d 100644
>>>> --- a/arch/arm/boot/dts/bcm11351-brt.dts
>>>> +++ b/arch/arm/boot/dts/bcm11351-brt.dts
>>>> @@ -27,18 +27,18 @@
>>>>           status = "okay";
>>>>       };
>>>> -    sdio0: sdio at 0x3f180000 {
>>>> +    sdio0: sdio at 3f180000 {
>>>>           max-frequency = <48000000>;
>>>>           status = "okay";
>>>>       };
>>>> -    sdio1: sdio at 0x3f190000 {
>>>> +    sdio1: sdio at 3f190000 {
>>>>           non-removable;
>>>>           max-frequency = <48000000>;
>>>>           status = "okay";
>>>>       };
>>>> -    sdio3: sdio at 0x3f1b0000 {
>>>> +    sdio3: sdio at 3f1b0000 {
>>>>           max-frequency = <48000000>;
>>>>           status = "okay";
>>>>       };
>>> Hi Lee,
>>>   Is this convention documented ? Someone called my attention to the
>>> fact that this dts files was inconsistent in its use of 0x in names,
>>> but I was not aware of a coding guideline for this.
>>
>> The best two places I can think of are:
>>
>> Documentation/devicetree/usage-model.txt
>> and
>> http://www.devicetree.org/Device_Tree_Usage
>
> And even those do not stick to a single convention, but that is what 
> can be expected of a twiki page :-p
[take 2 with in plain text]

Agreed. Quick search shows the following example on that page:
         pci at 0x10180000 {
             compatible = "arm,versatile-pci-hostbridge", "pci";
             reg = <0x10180000 0x1000>;
             interrupts = <8 0>;
             bus-ranges = <0 0>;
         };

though it is the minority in the examples, ultimately having more 
examples following one convention than the other does not a standard 
make :) While I like this just for the consistency, it'd be nice to have 
something to point people to as this being the best practice for kernel 
dev. It would be good to have a DeviceTreeGuidelines along the lines of 
the CodingGuidelines file in the kernel tree itself, to get some 
consistency on this.


  Thanks,
    csd




From t.figa at samsung.com  Mon Jul 22 13:00:44 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 19:00:44 +0200
Subject: [PATCH] irqchip: exynos: cleanup non-DT stuff in exynos-combiner
In-Reply-To: <027401ce81d3$ad706570$08513050$%kim@samsung.com>
References: <027401ce81d3$ad706570$08513050$%kim@samsung.com>
Message-ID: <8556897.hUyIfVfH2g@amdc1227>

On Tuesday 16 of July 2013 12:22:14 Kukjin Kim wrote:
> For EXYNOS SoCs, only can support for DT so removes non-DT stuff
> in exynos-combiner.
> 
> Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
> ---
>  drivers/irqchip/exynos-combiner.c |   44
> +------------------------------------ 1 file changed, 1 insertion(+), 43
> deletions(-)

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From plagnioj at jcrosoft.com  Mon Jul 22 13:03:44 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 22 Jul 2013 19:03:44 +0200
Subject: [PATCH v4 0/5] ARM: at91: prepare transition to common clk
 framework
In-Reply-To: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
References: <1374132753-15206-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <20130722170344.GK16015@ns203013.ovh.net>

On 09:32 Thu 18 Jul     , Boris BREZILLON wrote:
> Hello,
> 
> This patch series prepares the transition to common clk framework by
> replacing all the clk_enable and clk_disable calls by clk_prepare_unable and
> clk_disable_unprepare to avoid common clock framework warnings.
on the whole serie

Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

> 
> Best Regards,
> Boris
> 
> Changes since v3:
>  - move usb clock config patches out of this series
>  - move clk_prepare/unprepare calls out of critical sections (ssc and
>    mci drivers)
>  - remove already applied spi clk_prepare patch 
> 
> Changes since v2:
>  - add configuraton of usb clock in ohci and udc drivers
>  - add clk_prepare patch for usba udc driver
>  - add clk_prepare patch for spi driver
>  - remove already applied udc clk_prepare patch
> 
> Changes since v1:
>  - remove unneeded clk_unprepare in mci driver
>  - remove already applied patches (ehci, ohci, dma and serial)
> 
> Changes since common clk patch series:
>  - add clk_prepare_enable return check
>  - fix a deadlock in atmel-mci (missing spin_unlock)
>  - remove already applied patches (atmel-ssc and pwm-atmel-tcb)
> 
> Boris BREZILLON (5):
>   ARM: at91/tc/clocksource: replace clk_enable/disable with
>     clk_prepare_enable/disable_unprepare.
>   mmc: atmel-mci: prepare clk before calling enable
>   at91/avr32/atmel_lcdfb: prepare clk before calling enable
>   USB: gadget: atmel_usba: prepare clk before calling enable
>   ASoC: atmel-ssc: remove clk_disable_unprepare call from critical
>     section
> 
>  drivers/clocksource/tcb_clksrc.c    |   10 +++++-----
>  drivers/misc/atmel-ssc.c            |   11 ++++++++---
>  drivers/mmc/host/atmel-mci.c        |   34 +++++++++++++++++++++++++++-------
>  drivers/usb/gadget/atmel_usba_udc.c |   28 +++++++++++++++++++++-------
>  drivers/video/atmel_lcdfb.c         |    8 ++++----
>  5 files changed, 65 insertions(+), 26 deletions(-)
> 
> -- 
> 1.7.9.5
> 


From sboyd at codeaurora.org  Mon Jul 22 13:05:00 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 22 Jul 2013 10:05:00 -0700
Subject: [PATCH 4/4] ARM: set --be8 when linking modules
In-Reply-To: <1374510833-25716-5-git-send-email-ben.dooks@codethink.co.uk>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374510833-25716-5-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130722170500.GC19639@codeaurora.org>

On 07/22, Ben Dooks wrote:
> To avoid having to make every text section swap the instruction order
> of all instructions, make sure modules are built also built with --be8
> (as is the current kernel final link).
> 
> If we do not do this, we would end up having to swap all instructions
> when loading a module, instead of just the instructions that we are
> applying ELF relocations to.
> 

If someone tries to load a be8 module on a non-be8 kernel will it
still work? Or should we add an extra version magic string in
asm/module.h to prevent that?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From john.stultz at linaro.org  Mon Jul 22 13:07:10 2013
From: john.stultz at linaro.org (John Stultz)
Date: Mon, 22 Jul 2013 10:07:10 -0700
Subject: [PATCH v4 00/17] 64-bit friendly generic sched_clock()
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <51ED66BE.8040006@linaro.org>

On 07/18/2013 04:21 PM, Stephen Boyd wrote:
> This patchset adds support for 64 bit counters in the generic
> sched_clock code and converts drivers over to use it. Based
> on v3.11-rc1.
>
> Changes since v3:
>   * Move to use seqcount to fix issues with 64-bit cyc counters
>   * Move to hrtimer to fix underflow/overflow errors in wraparound
>     calculation
>   * Use of 1 hour in clocks_calc_mult_shift
>   * Converted over drivers in drivers/clocksource
>
> Stephen Boyd (17):
>    clocksource: Extract max nsec calculation into separate function
>    sched_clock: Use seqcount instead of rolling our own
>    sched_clock: Use an hrtimer instead of timer
>    sched_clock: Add support for >32 bit sched_clock
>    arch_timer: Move to generic sched_clock framework
>    sched_clock: Remove sched_clock_func() hook
>    clocksource: bcm2835: Switch to sched_clock_register()
>    ocksource: dbx500-prcmu: Switch to sched_clock_register()
>    clocksource: dw_apb_timer_of: Switch to sched_clock_register()
>    clocksource: mxs_timer: Switch to sched_clock_register()
>    clocksource: nomadik: Switch to sched_clock_register()
>    clocksource: samsung_pwm_timer: Switch to sched_clock_register()
>    clocksource: tegra: Switch to sched_clock_register()
>    clocksource: time-armada-370-xp: Switch to sched_clock_register()
>    clocksource: sirf: Switch to sched_clock_register() and use 64 bits
>    clocksource: vf_pit_timer: Switch to sched_clock_register()
>    sched_clock: Deprecate setup_sched_clock()

Ok, so if there's no major objections with this set, here's my plan:

1) I'm going to queue 1-4 in a fortglx/3.12/sched-clock64 branch, I'll 
send git pull requests to both Thomas and Olof, so they can both merge 
the common base for the conversion code in both drivers/clocksource and 
arch/arm.

2) If I can get Catalin's ack on 5/17, I'll queue it and 6/17 for 
tip/timers/core.

3) I'll also queue the rest and send to Thomas or Daniel for 
tip/timers/core.

That sound ok to everyone?

thanks
-john




From t.figa at samsung.com  Mon Jul 22 13:07:15 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 19:07:15 +0200
Subject: [PATCH v2 6/6] ARM: S3C24XX: Convert s3c2416 and s3c2443 to common
 clock framework
In-Reply-To: <02cf01ce81f3$6777e5f0$3667b1d0$%kim@samsung.com>
References: <201307100057.06061.heiko@sntech.de>
 <201307100100.28992.heiko@sntech.de>
 <02cf01ce81f3$6777e5f0$3667b1d0$%kim@samsung.com>
Message-ID: <2236509.stVfXyPhpt@amdc1227>

On Tuesday 16 of July 2013 16:09:24 Kukjin Kim wrote:
> Heiko St?bner wrote:
> > This converts the mentioned platforms to use the newly introduced
> > driver
> > for the common clock framework for them.
> > 
> > With this the whole legacy clock structure can go away too.
> > 
> > Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> > ---
> > 
> >  arch/arm/boot/dts/s3c2416-smdk2416.dts  |    7 +
> >  arch/arm/boot/dts/s3c2416.dtsi          |   42 ++
> >  arch/arm/mach-s3c24xx/Kconfig           |   14 +-
> >  arch/arm/mach-s3c24xx/Makefile          |    5 +-
> >  arch/arm/mach-s3c24xx/clock-s3c2416.c   |  171 --------
> >  arch/arm/mach-s3c24xx/clock-s3c2443.c   |  212 ----------
> >  arch/arm/mach-s3c24xx/common-s3c2443.c  |  677
> >  ---------------------------> 
> > ----
> 
> In this case, to use '-D' in format-patch would be better :-)
> 
> >  arch/arm/mach-s3c24xx/common.c          |   18 +-
> >  arch/arm/mach-s3c24xx/common.h          |    8 +
> >  arch/arm/mach-s3c24xx/mach-s3c2416-dt.c |   45 +-
> >  arch/arm/mach-s3c24xx/mach-smdk2416.c   |    9 +-
> >  arch/arm/mach-s3c24xx/mach-smdk2443.c   |    9 +-
> >  12 files changed, 102 insertions(+), 1115 deletions(-)
> >  delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2416.c
> >  delete mode 100644 arch/arm/mach-s3c24xx/clock-s3c2443.c
> >  delete mode 100644 arch/arm/mach-s3c24xx/common-s3c2443.c
> > 
> > diff --git a/arch/arm/boot/dts/s3c2416-smdk2416.dts
> > b/arch/arm/boot/dts/s3c2416-smdk2416.dts
> > index 59594cf..9caeb89 100644
> > --- a/arch/arm/boot/dts/s3c2416-smdk2416.dts
> > +++ b/arch/arm/boot/dts/s3c2416-smdk2416.dts
> > @@ -19,6 +19,13 @@
> > 
> >  		reg =  <0x30000000 0x4000000>;
> >  	
> >  	};
> > 
> > +	fixed-rate-clocks {
> > +		xti {
> > +			compatible = "samsung,clock-xti";
> > +			clock-frequency = <12000000>;
> > +		};
> > +	};
> > +
> > 
> >  	serial at 50000000 {
> >  	
> >  		status = "okay";
> >  		pinctrl-names = "default";
> > 
> > diff --git a/arch/arm/boot/dts/s3c2416.dtsi
> > b/arch/arm/boot/dts/s3c2416.dtsi
> > index e6555bd..c19d99c 100644
> > --- a/arch/arm/boot/dts/s3c2416.dtsi
> > +++ b/arch/arm/boot/dts/s3c2416.dtsi
> > @@ -8,6 +8,7 @@
> > 
> >   * published by the Free Software Foundation.
> >   */
> > 
> > +#include <dt-bindings/clock/samsung,s3c2443-clock.h>
> > 
> >  #include "s3c24xx.dtsi"
> >  #include "s3c2416-pinctrl.dtsi"
> > 
> > @@ -28,26 +29,53 @@
> > 
> >  		compatible = "samsung,s3c2416-irq";
> >  	
> >  	};
> > 
> > +	clocks: clock-controller at 0x4c000000 {
> 
> +	clock: clock-controller at 0x4c000000 {
> 
> for keeping same format for Samsung stuff...
> 

Also please remove the "0x" from node name.

> > +		compatible = "samsung,s3c2416-clock";
> > +		reg = <0x4c000000 0x40>;
> > +		#clock-cells = <1>;
> > +	};
> > +
> > 
> >  	pinctrl at 56000000 {
> >  	
> >  		compatible = "samsung,s3c2416-pinctrl";
> >  	
> >  	};
> > 
> > +	timer at 51000000 {
> > +		clocks = <&clocks PCLK_PWM>;
> 
> +		clocks = <&clock PCLK_PWM>;
> 
> And I'm not sure using definition PCLK_PWM is better here...

Care to explain your doubts about it? I think this is fine.

Best regards,
Tomasz



From mark.rutland at arm.com  Mon Jul 22 13:08:17 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Jul 2013 18:08:17 +0100
Subject: [PATCH v4 0/5] Memory mapped architected timers
In-Reply-To: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
References: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130722170817.GB4833@e106331-lin.cambridge.arm.com>

Hi Stephen,

On Fri, Jul 19, 2013 at 12:59:27AM +0100, Stephen Boyd wrote:
> This patchset adds support for memory mapped architected timers. We
> don't have any other global broadcast timer in our system, so we use the
> mmio timer during low power modes. The first patch changes the register
> accessor to an enum per Thomas' request. The second patch is the binding.
> The next two patches lay some groundwork so that the last patch is simpler.
> The final patch adds support for mmio timers.
> 
> Patches are based on v3.11-rc1.

Be aware that as of v3.11-rc2 this doesn't cleanly apply, as the
__cpuinit removal broke the final patch's context in a couple of places.
It would be nice to get rid of the new cpuinit additions too...

With that cleaned up locally, I've gave this a spin on tc2 and a
Foundation model to test the cp15/system timers, hotplugging CPUs and
running a basic test (`time sleep 5`). That all seems to work.

Unfortunately I have no way of testing the memory-mapped timer support,
but I trust you've tested that locally.

For the series:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Thanks,
Mark.

> 
> Updates since v3:
>  * Rebased onto v3.11-rc1
>  * New patch to use compiler warnings instead of BUILD_BUG_ON()
> 
> Updates since v2:
>  * Rebased onto v3.10-rc1
> 
> Updates since v1:
>  * Assigned counter reading function and commented why for arm64
>  * Updated DT binding to replace frame-id with frame-number and use status
>    property
> 
> 
> Stephen Boyd (5):
>   clocksource: arch_timer: Make register accessors less error-prone
>   Documentation: Add memory mapped ARM architected timer binding
>   clocksource: arch_timer: Pass clock event to set_mode callback
>   clocksource: arch_timer: Push the read/write wrappers deeper
>   clocksource: arch_timer: Add support for memory mapped timers
> 
>  .../devicetree/bindings/arm/arch_timer.txt         |  59 ++-
>  arch/arm/include/asm/arch_timer.h                  |  14 +-
>  arch/arm64/include/asm/arch_timer.h                |  23 +-
>  drivers/clocksource/arm_arch_timer.c               | 446 +++++++++++++++++----
>  include/clocksource/arm_arch_timer.h               |  10 +-
>  5 files changed, 455 insertions(+), 97 deletions(-)
> 
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
> 
> 


From t.figa at samsung.com  Mon Jul 22 13:10:26 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 19:10:26 +0200
Subject: [PATCH v2 0/6] clk: exynos: Some fixes and cleanup
In-Reply-To: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
References: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1648122.0DIdkVRanC@amdc1227>

On Thursday 18 of July 2013 15:31:16 Sachin Kamat wrote:
> Resending some of patches (1, 3 and 5) as per discussion in thread [1].
> Other patches in the series are new.
> 
> [1] http://comments.gmane.org/gmane.linux.kernel.samsung-soc/19933
> 
> Changes since v1:
> * Removed an unnecessary change in Patch 1 as pointed out by Kukjin Kim.
> * Added Kukjin's ack to patches 3~6.
> 
> Sachin Kamat (6):
>   clk: exynos4: Staticize local symbols
>   clk: exynos4: Remove unused function
>   clk: exynos5250: Staticize local symbols
>   clk: exynos5420: Staticize local symbols
>   clk: exynos5440: Staticize local symbols
>   clk: exynos-audss: Staticize exynos_audss_clk_init
> 
>  drivers/clk/samsung/clk-exynos-audss.c |    2 +-
>  drivers/clk/samsung/clk-exynos4.c      |   42
> ++++++++++++-------------------- drivers/clk/samsung/clk-exynos5250.c  
> |   14 +++++------
>  drivers/clk/samsung/clk-exynos5420.c   |   14 +++++------
>  drivers/clk/samsung/clk-exynos5440.c   |   14 +++++------
>  5 files changed, 37 insertions(+), 49 deletions(-)

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From t.figa at samsung.com  Mon Jul 22 13:10:41 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 19:10:41 +0200
Subject: [PATCH RESEND] ARM: plat-samsung: Fix switching FIFO in
 arch_enable_uart_fifo function
In-Reply-To: <1372792593-7457-1-git-send-email-shc_work@mail.ru>
References: <1372792593-7457-1-git-send-email-shc_work@mail.ru>
Message-ID: <1786279.J430QToqzW@amdc1227>

On Tuesday 02 of July 2013 23:16:33 Alexander Shiyan wrote:
> When CONFIG_S3C_BOOT_UART_FORCE_FIFO symbol is set, we should
> enable FIFO but actually switch command is missing in the code.
> This patch adds this switching.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  arch/arm/plat-samsung/include/plat/uncompress.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/plat-samsung/include/plat/uncompress.h
> b/arch/arm/plat-samsung/include/plat/uncompress.h index 4afc32f..f48dc0a
> 100644
> --- a/arch/arm/plat-samsung/include/plat/uncompress.h
> +++ b/arch/arm/plat-samsung/include/plat/uncompress.h
> @@ -145,6 +145,8 @@ static inline void arch_enable_uart_fifo(void)
>  			if (!(fifocon & S3C2410_UFCON_RESETBOTH))
>  				break;
>  		}
> +
> +		uart_wr(S3C2410_UFCON, S3C2410_UFCON_FIFOMODE);
>  	}
>  }
>  #else

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From t.figa at samsung.com  Mon Jul 22 13:14:53 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 19:14:53 +0200
Subject: [PATCH] ARM: S3C24XX: Add missing clkdev entries for s3c2440 UART
In-Reply-To: <1374435765-6747-1-git-send-email-sylvester.nawrocki@gmail.com>
References: <1374435765-6747-1-git-send-email-sylvester.nawrocki@gmail.com>
Message-ID: <1877003.j5SlNHUNT8@amdc1227>

On Sunday 21 of July 2013 21:42:45 Sylwester Nawrocki wrote:
> This patch restores serial port operation which has been broken since
> commit 60e93575476f90a72146b51283f514da655410a7
> serial: samsung: enable clock before clearing pending interrupts during
> init
> 
> That commit only uncovered the real issue which was missing clkdev
> entries for the "uart" clocks on S3C2440. It went unnoticed so far
> because return value of clk API calls were not being checked at all
> in the samsung serial port driver.
> 
> This patch should be backported to at least 3.10 stable kernel, since
> the serial port has not been working on s3c2440 since 3.10-rc5.
> 
> Cc: Chander Kashyap <chander.kashyap at linaro.org>
> Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
> [on S3C2440 SoC based Mini2440 board]
> Tested-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
> ---
> 
> There seems to be something wrong with the process, as things are
> getting broken late in the -rc cycle.  It seems author of the above
> mentioned commit didn't test all 6 SoC series that the samsung
> serial driver handles.  While I can understand they might not have
> all required hardware it's a bit irritating that the patch that
> in practice caused regression appeared only on linux-serial mailing
> list. And it's not evident it was even tried to test it on all
> potentially affected platforms. It not clear on what platforms
> the patch has been tested.
> 
> My humble suggestion is, _please_ do send patches that affect multiple
> Samsung SoCs to linux-samsung at vger.kernel.org.  So there is better
> review and test exposure.  And we can reduce mess like this happening
> in the future.
> 
> Thanks!
> Sylwester
> ---
>  arch/arm/mach-s3c24xx/clock-s3c2410.c      |  161
> +++++++++++++++++----------- arch/arm/mach-s3c24xx/clock-s3c2440.c     
> |    3 +
>  arch/arm/plat-samsung/include/plat/clock.h |    5 +
>  3 files changed, 106 insertions(+), 63 deletions(-)

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From ben.dooks at codethink.co.uk  Mon Jul 22 13:20:10 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 22 Jul 2013 18:20:10 +0100
Subject: [PATCH 4/4] ARM: set --be8 when linking modules
In-Reply-To: <20130722170500.GC19639@codeaurora.org>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374510833-25716-5-git-send-email-ben.dooks@codethink.co.uk>
 <20130722170500.GC19639@codeaurora.org>
Message-ID: <51ED69CA.3030501@codethink.co.uk>

On 22/07/13 18:05, Stephen Boyd wrote:
> On 07/22, Ben Dooks wrote:
>> To avoid having to make every text section swap the instruction order
>> of all instructions, make sure modules are built also built with --be8
>> (as is the current kernel final link).
>>
>> If we do not do this, we would end up having to swap all instructions
>> when loading a module, instead of just the instructions that we are
>> applying ELF relocations to.
>>
>
> If someone tries to load a be8 module on a non-be8 kernel will it
> still work? Or should we add an extra version magic string in
> asm/module.h to prevent that?

The ELF header changes the EI_DATA field in the ei_ident from
ELFDATA2LSB to ELFDATA2MSB when compiling so we should be able
to detect these when loading.

I have not checked to see if the kernel correctly checks for this.

I do not think it currently checks the ei_flags field for the
EF_ARM_BE8 in ABI 4 and 5. I am not sure if this is really important?

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From t.figa at samsung.com  Mon Jul 22 13:21:47 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 19:21:47 +0200
Subject: [PATCH 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <0ad601ce868c$d88bff40$89a3fdc0$@org>
References: <1372054438-15693-1-git-send-email-sachin.kamat@linaro.org>
 <CAK9yfHzmF_oxc3DsuT5wtXX2C5O+wLxz4C2Ps3cVPnKLb8jOEw@mail.gmail.com>
 <0ad601ce868c$d88bff40$89a3fdc0$@org>
Message-ID: <3136364.6D0qu7zGk3@amdc1227>

On Monday 22 of July 2013 12:37:52 Kukjin Kim wrote:
> Sachin Kamat wrote:
> > On 22 July 2013 07:18, Kukjin Kim <kgene.kim at samsung.com> wrote:
> > > Sachin Kamat wrote:
> > >> With the recent cleanup in Exynos platform code notably commits
> > >> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
> > >> more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the
> > >> definition
> > >> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs
> > 
> > like
> > 
> > >> Exynos4412 which have more (285) than the default number of GPIOs
> 
> (255).
> 
> > >> Thus define this number in Kconfig file. Without this patch we get
> > >> the
> > >> following errors during boot:
> > >> 
> > >> gpiochip_add: gpios 251..258 (gpv0) failed to register
> > >> samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
> > >> error code: -22
> > >> samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
> > >> 
> > >> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> > >> Cc: Tomasz Figa <t.figa at samsung.com>
> > >> ---
> > >> Based on Kukjin's for-next tree.
> > >> ---
> > >> 
> > >>  arch/arm/Kconfig |    1 +
> > >>  1 file changed, 1 insertion(+)
> > >> 
> > >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > >> index ddf2667..380a53b 100644
> > >> --- a/arch/arm/Kconfig
> > >> +++ b/arch/arm/Kconfig
> > >> @@ -1578,6 +1578,7 @@ config ARCH_NR_GPIO
> > >> 
> > >>       default 512 if SOC_OMAP5
> > >>       default 392 if ARCH_U8500
> > >>       default 352 if ARCH_VT8500
> > >> 
> > >> +     default 288 if ARCH_EXYNOS
> > >> 
> > >>       default 288 if ARCH_SUNXI
> > >>       default 264 if MACH_H4700
> > >>       default 0
> > >> 
> > >> --
> > >> 1.7.9.5
> > > 
> > > Hmm, BTW, I'm wondering why it is 288 not 285 or other specific
> 
> number...
> 
> > I wasn't really sure if we can have any number there. I chose the
> > closest one (288) which was already used by other platform.
> > If there is no problem to use 285 itself then I can resend with that
> > number. Please let me know.
> 
> If there is no reason, please don't use bigger value than necessary one.

Hmm, what about some GPIO expanders that would require bigger GPIO address 
space? I would reserve some space just in case, i.e. define this value to be 
the highest number of GPIOs on all Exynos SoCs + some extra, like 32 or 64.

Best regards,
Tomasz



From ben.dooks at codethink.co.uk  Mon Jul 22 13:30:43 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 22 Jul 2013 18:30:43 +0100
Subject: [PATCH 07/11] ARM: shmobile: EMEV2 map_io update
In-Reply-To: <0ea2b5389ab1b63aa880c5735c15be0b26b91b1a.1374478037.git.horms+renesas@verge.net.au>
References: <cover.1374478037.git.horms+renesas@verge.net.au>
 <0ea2b5389ab1b63aa880c5735c15be0b26b91b1a.1374478037.git.horms+renesas@verge.net.au>
Message-ID: <51ED6C43.5070404@codethink.co.uk>

On 22/07/13 08:36, Simon Horman wrote:
> From: Magnus Damm<damm at opensource.se>
>
> Update the EMEV2 struct map_desc to exclude the SMU
> and also include the ->map_io() callback in the DT
> version of EMEV2 board support.
>
> The EMEV2 SMP code can these days perform ioremap()
> early on without the SMU information in the io_desc[].
>
> To correctly support SMP in case of DT-only board
> support then the ->map_io() callback is needed.
>
> Signed-off-by: Magnus Damm<damm at opensource.se>
> Acked-by: Arnd Bergmann<arnd at arndb.de>
> Signed-off-by: Simon Horman<horms+renesas at verge.net.au>

This looks roughly what we did to get the the EMEV2 working
here, although ours is a little more hacky.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From paul at pwsan.com  Mon Jul 22 13:48:43 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 22 Jul 2013 17:48:43 +0000 (UTC)
Subject: [PATCH 3/4] ARM: OMAP2+: Avoid idling memory controllers with
 no drivers
In-Reply-To: <1374487277-26099-4-git-send-email-rnayak@ti.com>
References: <1374487277-26099-1-git-send-email-rnayak@ti.com>
 <1374487277-26099-4-git-send-email-rnayak@ti.com>
Message-ID: <alpine.DEB.2.02.1307221746430.10891@utopia.booyaka.com>

Hi

On Mon, 22 Jul 2013, Rajendra Nayak wrote:

> Memory controllers in OMAP (like GPMC and EMIF) have the hwmods marked with
> HWMOD_INIT_NO_IDLE and are left in enabled state post initial setup.
> 
> Even if they have drivers missing, avoid idling them as part of
> omap_device_late_idle()

Since this patch is intended for the -rc series, it's best if you explain 
here what effects this patch will fix.  i.e., does this fix a crash, a 
warning, etc?  Also maybe update your series description message?


- Paul


From joelf at ti.com  Mon Jul 22 13:49:17 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 22 Jul 2013 12:49:17 -0500
Subject: [PATCH] ARM: EDMA: Fix clearing of unused list for DT DMA resources
Message-ID: <1374515357-14574-1-git-send-email-joelf@ti.com>

HWMOD removal for MMC is breaking edma_start as the events are being manually
triggered due to unused channel list not being clear, Thanks to Balaji TK for
finding this issue.

This patch fixes the issue, by reading the "dmas" property from the DT node if
it exists and clearing the bits in the unused channel list.

Cc: Balaji T K <balajitk at ti.com>
Cc: Pantel Antoniou <panto at antoniou-consulting.com>
Signed-off-by: Joel Fernandes <joelf at ti.com>
---
Fixed pushed to git at github.com:joelagnel/linux-kernel.git
   99b65c9..a411a81  master-rebase -> master-rebase

 arch/arm/common/edma.c |   31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index a432e6c..720f958 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -561,14 +561,29 @@ static int reserve_contiguous_slots(int ctlr, unsigned int id,
 static int prepare_unused_channel_list(struct device *dev, void *data)
 {
 	struct platform_device *pdev = to_platform_device(dev);
-	int i, ctlr;
-
-	for (i = 0; i < pdev->num_resources; i++) {
-		if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
-				(int)pdev->resource[i].start >= 0) {
-			ctlr = EDMA_CTLR(pdev->resource[i].start);
-			clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
-					edma_cc[ctlr]->edma_unused);
+	int i = 0, ctlr;
+	u32 dma_chan;
+	__be32 *dma_chan_p;
+	struct property *prop;
+
+	if (dev->of_node) {
+		of_property_for_each_u32(dev->of_node, "dmas", prop, \
+					 dma_chan_p, dma_chan) {
+			if (i++ & 1) {
+				ctlr = EDMA_CTLR(dma_chan);
+				clear_bit(EDMA_CHAN_SLOT(dma_chan),
+						edma_cc[ctlr]->edma_unused);
+			}
+		}
+	} else {
+		for (; i < pdev->num_resources; i++) {
+			if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
+			    (int)pdev->resource[i].start >= 0) {
+				ctlr = EDMA_CTLR(pdev->resource[i].start);
+				clear_bit(EDMA_CHAN_SLOT(
+					  pdev->resource[i].start),
+					  edma_cc[ctlr]->edma_unused);
+			}
 		}
 	}
 
-- 
1.7.9.5



From nicolas.pitre at linaro.org  Mon Jul 22 13:58:12 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 13:58:12 -0400 (EDT)
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <20130719105907.GB27389@e102568-lin.cambridge.arm.com>
References: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
 <1374118116-16836-2-git-send-email-nicolas.pitre@linaro.org>
 <20130718150408.GB2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181231510.14924@syhkavp.arg>
 <20130718180323.GC2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181452480.14924@syhkavp.arg>
 <20130719102844.GA3746@localhost.localdomain>
 <20130719105907.GB27389@e102568-lin.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1307221353360.15022@syhkavp.arg>

On Fri, 19 Jul 2013, Lorenzo Pieralisi wrote:

> On Fri, Jul 19, 2013 at 11:28:49AM +0100, Dave Martin wrote:
> > On Thu, Jul 18, 2013 at 02:59:06PM -0400, Nicolas Pitre wrote:
> > > On Thu, 18 Jul 2013, Dave Martin wrote:
> > > 
> > > > I had other names in mind, like "coherency_exit" or "cache_exit".
> > > > Those are not very intelligible, but that might at least make people
> > > > pause and think before blindly using it.
> > > 
> > > Good point.  It should still embody the architecture name for which it 
> > > is valid though.
> > 
> > Sure, I was assuming something would be pasted on the start of the name.
> 
> v7 :-) with a comment describing the assumptions (in particular related
> as Dave mentioned to the SMP bit behaviour) ?

OK... What about this then:

----- >8
From: Nicolas Pitre <nicolas.pitre at linaro.org>
Date: Thu, 18 Jul 2013 13:12:48 -0400
Subject: [PATCH] ARM: cacheflush: consolidate single-CPU ARMv7 cache disabling
 code

This code is becoming duplicated in many places.  So let's consolidate
it into a handy macro that is known to be right and available for reuse.

Signed-off-by: Nicolas Pitre <nico at linaro.org>

diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
index 17d0ae8672..8f4e2297e2 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -436,4 +436,44 @@ static inline void __sync_cache_range_r(volatile void *p, size_t size)
 #define sync_cache_w(ptr) __sync_cache_range_w(ptr, sizeof *(ptr))
 #define sync_cache_r(ptr) __sync_cache_range_r(ptr, sizeof *(ptr))
 
+/*
+ * Disabling cache access for one CPU in an ARMv7 SMP system is tricky.
+ * To do so we must:
+ *
+ * - Clear the SCTLR.C bit to prevent further cache allocations
+ * - Flush the desired level of cache
+ * - Clear the ACTLR "SMP" bit to disable local coherency
+ *
+ * ... and so without any intervening memory access in between those steps,
+ * not even to the stack.
+ *
+ * WARNING -- After this has been called:
+ *
+ * - No ldr/str exclusive must be used.
+ * - The CPU is obviously no longer coherent with the other CPUs.
+ *
+ * Further considerations:
+ *
+ * - This relies on the presence and behavior of the AUXCR.SMP bit as
+ *   documented in the ARMv7 TRM.  Vendor implementations that deviate from
+ *   that will need their own procedure.
+ * - This is unlikely to work if Linux is running non-secure.
+ */
+#define v7_exit_coherency_flush(level) \
+	asm volatile( \
+	"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t" \
+	"bic	r0, r0, #"__stringify(CR_C)" \n\t" \
+	"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t" \
+	"isb	\n\t" \
+	"bl	v7_flush_dcache_"__stringify(level)" \n\t" \
+	"clrex	\n\t" \
+	"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t" \
+	"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t" \
+	"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t" \
+	"isb	\n\t" \
+	"dsb	" \
+	/* The clobber list is dictated by the call to v7_flush_dcache_* */ \
+	: : : "r0","r1","r2","r3","r4","r5","r6","r7", \
+	      "r9","r10","r11","lr","memory" )
+
 #endif
diff --git a/arch/arm/mach-vexpress/dcscb.c b/arch/arm/mach-vexpress/dcscb.c
index 85fffa702f..14d4996887 100644
--- a/arch/arm/mach-vexpress/dcscb.c
+++ b/arch/arm/mach-vexpress/dcscb.c
@@ -133,32 +133,8 @@ static void dcscb_power_down(void)
 	if (last_man && __mcpm_outbound_enter_critical(cpu, cluster)) {
 		arch_spin_unlock(&dcscb_lock);
 
-		/*
-		 * Flush all cache levels for this cluster.
-		 *
-		 * To do so we do:
-		 * - Clear the SCTLR.C bit to prevent further cache allocations
-		 * - Flush the whole cache
-		 * - Clear the ACTLR "SMP" bit to disable local coherency
-		 *
-		 * Let's do it in the safest possible way i.e. with
-		 * no memory access within the following sequence
-		 * including to the stack.
-		 */
-		asm volatile(
-		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
-		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
-		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
-		"isb	\n\t"
-		"bl	v7_flush_dcache_all \n\t"
-		"clrex	\n\t"
-		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
-		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
-		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
-		"isb	\n\t"
-		"dsb	"
-		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
-		      "r9","r10","r11","lr","memory");
+		/* Flush all cache levels for this cluster. */
+		v7_exit_coherency_flush(all);
 
 		/*
 		 * This is a harmless no-op.  On platforms with a real
@@ -177,24 +153,8 @@ static void dcscb_power_down(void)
 	} else {
 		arch_spin_unlock(&dcscb_lock);
 
-		/*
-		 * Flush the local CPU cache.
-		 * Let's do it in the safest possible way as above.
-		 */
-		asm volatile(
-		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
-		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
-		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
-		"isb	\n\t"
-		"bl	v7_flush_dcache_louis \n\t"
-		"clrex	\n\t"
-		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
-		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
-		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
-		"isb	\n\t"
-		"dsb	"
-		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
-		      "r9","r10","r11","lr","memory");
+		/* Disable and flush the local CPU cache. */
+		v7_exit_coherency_flush(louis);
 	}
 
 	__mcpm_cpu_down(cpu, cluster);
diff --git a/arch/arm/mach-vexpress/tc2_pm.c b/arch/arm/mach-vexpress/tc2_pm.c
index dfb55d45b6..5940f1e317 100644
--- a/arch/arm/mach-vexpress/tc2_pm.c
+++ b/arch/arm/mach-vexpress/tc2_pm.c
@@ -134,26 +134,7 @@ static void tc2_pm_down(u64 residency)
 			: : "r" (0x400) );
 		}
 
-		/*
-		 * We need to disable and flush the whole (L1 and L2) cache.
-		 * Let's do it in the safest possible way i.e. with
-		 * no memory access within the following sequence
-		 * including the stack.
-		 */
-		asm volatile(
-		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
-		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
-		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
-		"isb	\n\t"
-		"bl	v7_flush_dcache_all \n\t"
-		"clrex	\n\t"
-		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
-		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
-		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
-		"isb	\n\t"
-		"dsb	"
-		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
-		      "r9","r10","r11","lr","memory");
+		v7_exit_coherency_flush(all);
 
 		cci_disable_port_by_cpu(mpidr);
 
@@ -169,24 +150,7 @@ static void tc2_pm_down(u64 residency)
 
 		arch_spin_unlock(&tc2_pm_lock);
 
-		/*
-		 * We need to disable and flush only the L1 cache.
-		 * Let's do it in the safest possible way as above.
-		 */
-		asm volatile(
-		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
-		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
-		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
-		"isb	\n\t"
-		"bl	v7_flush_dcache_louis \n\t"
-		"clrex	\n\t"
-		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
-		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
-		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
-		"isb	\n\t"
-		"dsb	"
-		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
-		      "r9","r10","r11","lr","memory");
+		v7_exit_coherency_flush(louis);
 	}
 
 	__mcpm_cpu_down(cpu, cluster);


From joelf at ti.com  Mon Jul 22 13:59:49 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 22 Jul 2013 12:59:49 -0500
Subject: [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA resources
Message-ID: <1374515989-7391-1-git-send-email-joelf@ti.com>

HWMOD removal for MMC is breaking edma_start as the events are being manually
triggered due to unused channel list not being clear, Thanks to Balaji TK for
finding this issue.

This patch fixes the issue, by reading the "dmas" property from the DT node if
it exists and clearing the bits in the unused channel list.

Cc: Balaji T K <balajitk at ti.com>
Cc: Pantel Antoniou <panto at antoniou-consulting.com>
Signed-off-by: Joel Fernandes <joelf at ti.com>
---
v2 changes: Fixed compiler warning

 arch/arm/common/edma.c |   31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index a432e6c..765d578 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -561,14 +561,29 @@ static int reserve_contiguous_slots(int ctlr, unsigned int id,
 static int prepare_unused_channel_list(struct device *dev, void *data)
 {
 	struct platform_device *pdev = to_platform_device(dev);
-	int i, ctlr;
-
-	for (i = 0; i < pdev->num_resources; i++) {
-		if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
-				(int)pdev->resource[i].start >= 0) {
-			ctlr = EDMA_CTLR(pdev->resource[i].start);
-			clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
-					edma_cc[ctlr]->edma_unused);
+	int i = 0, ctlr;
+	u32 dma_chan;
+	const __be32 *dma_chan_p;
+	struct property *prop;
+
+	if (dev->of_node) {
+		of_property_for_each_u32(dev->of_node, "dmas", prop, \
+					 dma_chan_p, dma_chan) {
+			if (i++ & 1) {
+				ctlr = EDMA_CTLR(dma_chan);
+				clear_bit(EDMA_CHAN_SLOT(dma_chan),
+						edma_cc[ctlr]->edma_unused);
+			}
+		}
+	} else {
+		for (; i < pdev->num_resources; i++) {
+			if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
+			    (int)pdev->resource[i].start >= 0) {
+				ctlr = EDMA_CTLR(pdev->resource[i].start);
+				clear_bit(EDMA_CHAN_SLOT(
+					  pdev->resource[i].start),
+					  edma_cc[ctlr]->edma_unused);
+			}
 		}
 	}
 
-- 
1.7.9.5



From mturquette at linaro.org  Mon Jul 22 14:05:15 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 22 Jul 2013 11:05:15 -0700
Subject: [PATCH v2 0/6] clk: exynos: Some fixes and cleanup
In-Reply-To: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
References: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <20130722180515.7598.56428@quantum>

Quoting Sachin Kamat (2013-07-18 03:01:16)
> Resending some of patches (1, 3 and 5) as per discussion in thread [1].
> Other patches in the series are new.
> 
> [1] http://comments.gmane.org/gmane.linux.kernel.samsung-soc/19933
> 
> Changes since v1:
> * Removed an unnecessary change in Patch 1 as pointed out by Kukjin Kim.
> * Added Kukjin's ack to patches 3~6.

Thanks for the fixes! Will take into clk-next unless you need them to go
into -rc3, but I don't think there are any regression fixes here.

Regards,
Mike

> 
> Sachin Kamat (6):
>   clk: exynos4: Staticize local symbols
>   clk: exynos4: Remove unused function
>   clk: exynos5250: Staticize local symbols
>   clk: exynos5420: Staticize local symbols
>   clk: exynos5440: Staticize local symbols
>   clk: exynos-audss: Staticize exynos_audss_clk_init
> 
>  drivers/clk/samsung/clk-exynos-audss.c |    2 +-
>  drivers/clk/samsung/clk-exynos4.c      |   42 ++++++++++++--------------------
>  drivers/clk/samsung/clk-exynos5250.c   |   14 +++++------
>  drivers/clk/samsung/clk-exynos5420.c   |   14 +++++------
>  drivers/clk/samsung/clk-exynos5440.c   |   14 +++++------
>  5 files changed, 37 insertions(+), 49 deletions(-)
> 
> -- 
> 1.7.9.5


From paul at pwsan.com  Mon Jul 22 14:07:47 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 22 Jul 2013 18:07:47 +0000 (UTC)
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
Message-ID: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>


Hi,

After Linus's commit fb2af0020a51709ad87ea8055c325d3fbde04158 ("Merge 
branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm"), the 
OMAP2430 SDP here stopped booting.

Here's the bootlog at the commit before the merge, commit 790eac5640:

http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722015454/

and here's a log at commit fb2af0020a5:

http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722005921/

Any ideas as to what might have caused this?


- Paul


From tixy at linaro.org  Mon Jul 22 14:08:01 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Mon, 22 Jul 2013 19:08:01 +0100
Subject: [PATCH] decompressors: fix "no limit" output buffer length
In-Reply-To: <1374476169-32194-1-git-send-email-acourbot@nvidia.com>
References: <1374476169-32194-1-git-send-email-acourbot@nvidia.com>
Message-ID: <1374516481.14712.3.camel@linaro1.home>

On Mon, 2013-07-22 at 15:56 +0900, Alexandre Courbot wrote:
> When decompressing into memory, the output buffer length is set to some
> arbitrarily high value (0x7fffffff) to indicate the output is,
> virtually, unlimited in size.
> 
> The problem with this is that some platforms have their physical memory
> at high physical addresses (0x80000000 or more), and that the output
> buffer address and its "unlimited" length cannot be added without
> overflowing. An example of this can be found in inflate_fast():
> 
> /* next_out is the output buffer address */
> out = strm->next_out - OFF;
> /* avail_out is the output buffer size. end will overflow if the output
>  * address is >= 0x80000104 */
> end = out + (strm->avail_out - 257);
> 
> This has huge consequences on the performance of kernel decompression,
> since the following exit condition of inflate_fast() will be always
> true:
> 
> } while (in < last && out < end);
> 
> Indeed, "end" has overflowed and is now always lower than "out". As a
> result, inflate_fast() will return after processing one single byte of
> input data, and will thus need to be called an unreasonably high number
> of times. This probably went unnoticed because kernel decompression is
> fast enough even with this issue.
> 
> Nonetheless, adjusting the output buffer length in such a way that the
> above pointer arithmetic never overflows results in a kernel
> decompression that is about 3 times faster on affected machines.
> 
> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com>

This speeds up booting of my Versatile Express TC2 by 15 seconds when
starting on the A7 cluster :-)

Tested-by: Jon Medhurst <tixy at linaro.org>

> ---
>  lib/decompress_inflate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/decompress_inflate.c b/lib/decompress_inflate.c
> index 19ff89e..d619b28 100644
> --- a/lib/decompress_inflate.c
> +++ b/lib/decompress_inflate.c
> @@ -48,7 +48,7 @@ STATIC int INIT gunzip(unsigned char *buf, int len,
>  		out_len = 0x8000; /* 32 K */
>  		out_buf = malloc(out_len);
>  	} else {
> -		out_len = 0x7fffffff; /* no limit */
> +		out_len = ((size_t)~0) - (size_t)out_buf; /* no limit */
>  	}
>  	if (!out_buf) {
>  		error("Out of memory while allocating output buffer");




From mturquette at linaro.org  Mon Jul 22 14:15:30 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 22 Jul 2013 11:15:30 -0700
Subject: [PATCH 2/4] clk: exynos-audss: allow input clocks to be specified
 in device tree
In-Reply-To: <1610421.OFFn8rqlxt@amdc1227>
References: <1373458313-18970-1-git-send-email-padma.v@samsung.com>
 <1373458313-18970-3-git-send-email-padma.v@samsung.com>
 <1610421.OFFn8rqlxt@amdc1227>
Message-ID: <20130722181530.7598.73318@quantum>

Quoting Tomasz Figa (2013-07-22 09:28:47)
> Hi Padmavathi, Andrew,
> 
> On Wednesday 10 of July 2013 17:41:51 Padmavathi Venna wrote:
> > From: Andrew Bresticker <abrestic at chromium.org>
> > 
> > This allows the input clocks to the Exynos AudioSS block to be specified
> > via device-tree bindings.  Default names will be used when an input clock
> > is not given.  This will be useful when adding support for the
> > Exynos5420 where the audio bus clock is called "sclk_maudio0" instead of
> > "sclk_audio0".
> > 
> > Signed-off-by: Andrew Bresticker <abrestic at chromium.org>
> > Reviewed-on: https://gerrit.chromium.org/gerrit/57833
> > Reviewed-by: Simon Glass <sjg at chromium.org>
> > ---
> >  .../devicetree/bindings/clock/clk-exynos-audss.txt |   31
> > ++++++++++++++++++- drivers/clk/samsung/clk-exynos-audss.c             |
> >   28 +++++++++++++++-- 2 files changed, 53 insertions(+), 6 deletions(-)
> 
> Well, this is basically how it should be done, but in current state of 
> clock core I can see a problem: can we really rely on the order of clock 
> initialization? I mean, we can't defer initialization of particular clock 
> controller until all external clocks it needs are available, because there 
> is no probing involved here.

The clock core allows registering clocks even if their parents are not
yet registered. I test this path with some dummy clocks every so often
to make sure the re-parenting operation are completed successfully after
the parents eventually are registered.

This feature was not used in practice until recently with the advent of
multiple clock controllers getting registered and DT description of
clocks / clock controllers that may be "out of order". If you find any
bugs please let me know ;-)

Regards,
Mike

> 
> Best regards,
> Tomasz


From john.stultz at linaro.org  Mon Jul 22 14:21:19 2013
From: john.stultz at linaro.org (John Stultz)
Date: Mon, 22 Jul 2013 11:21:19 -0700
Subject: [PATCH v4 03/17] sched_clock: Use an hrtimer instead of timer
In-Reply-To: <1374189690-10810-4-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-4-git-send-email-sboyd@codeaurora.org>
Message-ID: <51ED781F.6060300@linaro.org>

On 07/18/2013 04:21 PM, Stephen Boyd wrote:
> In the next patch we're going to increase the number of bits that
> the generic sched_clock can handle to be greater than 32. With
> more than 32 bits the wraparound time can be larger than what can
> fit into the units that msecs_to_jiffies takes (unsigned int).
> Luckily, the wraparound is initially calculated in nanoseconds
> which we can easily use with hrtimers, so switch to using an
> hrtimer.
>
> Cc: Russell King <linux at arm.linux.org.uk>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>


Hrmm. So in my testing (under qemu), this patch causes bootup to hang.

qemu-system-arm -kernel zImage-arm -M vexpress-a9 -cpu cortex-a9 
-nographic -m 1024  -append 'root=/dev/mmcblk0p2 rw mem=1024M 
raid=noautodetect console=ttyAMA0,38400n8 rootwait vmalloc=256MB 
devtmpfs.mount=0' -sd test-arm.img -redir tcp:4300::22

Config file attached.

I haven't gotten a chance to look very closely, but it seems the 
folowing patch resolves the issue. I'm not sure if we're seeing callers 
to setup_sched_clock happen after sched_clock_postinit or what, but it 
probably needs another look over.

thanks
-john


diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index a269890b..c018ffc 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -138,12 +138,6 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
  	pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns\n",
  		bits, r, r_unit, res, wrap);
  
-	/*
-	 * Start the timer to keep sched_clock() properly updated and
-	 * sets the initial epoch.
-	 */
-	hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
-	sched_clock_timer.function = sched_clock_poll;
  	update_sched_clock();
  
  	/*
@@ -175,6 +169,13 @@ void __init sched_clock_postinit(void)
  		setup_sched_clock(jiffy_sched_clock_read, 32, HZ);
  
  	update_sched_clock();
+
+	/*
+	 * Start the timer to keep sched_clock() properly updated and
+	 * sets the initial epoch.
+	 */
+	hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+	sched_clock_timer.function = sched_clock_poll;
  	hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
  }
  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.vexpress-qemu.gz
Type: application/gzip
Size: 19985 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130722/8a938835/attachment-0001.gz>

From nico at fluxnic.net  Mon Jul 22 14:31:00 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Mon, 22 Jul 2013 14:31:00 -0400 (EDT)
Subject: alignment handler instruction endian-ness
In-Reply-To: <51E93CD0.3040302@codethink.co.uk>
References: <51E91BE5.8070809@codethink.co.uk>
 <20130719110947.GD24642@n2100.arm.linux.org.uk>
 <51E92DE5.6090404@codethink.co.uk>
 <20130719123249.GE24642@n2100.arm.linux.org.uk>
 <51E93CD0.3040302@codethink.co.uk>
Message-ID: <alpine.LFD.2.03.1307221428050.15022@syhkavp.arg>

On Fri, 19 Jul 2013, Ben Dooks wrote:
> On 19/07/13 13:32, Russell King - ARM Linux wrote:
> > If you value your soul, NEVER EVER EVER place stuff which is not part
> > of the user API in a header file in a UAPI subdirectory.  And never
> > modify a header file in a UAPI subdirectory without first having a
> > good long think about how that modification may impact _userspace_.
> 
> Sorry, searched for byteorder.h and just did not notice.
> 
> Where is the best place for these to go?

You should really have a look at arch/arm/include/asm/opcodes.h.


Nicolas


From ben.dooks at codethink.co.uk  Mon Jul 22 14:34:10 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 22 Jul 2013 19:34:10 +0100
Subject: alignment handler instruction endian-ness
In-Reply-To: <alpine.LFD.2.03.1307221428050.15022@syhkavp.arg>
References: <51E91BE5.8070809@codethink.co.uk>
 <20130719110947.GD24642@n2100.arm.linux.org.uk>
 <51E92DE5.6090404@codethink.co.uk>
 <20130719123249.GE24642@n2100.arm.linux.org.uk>
 <51E93CD0.3040302@codethink.co.uk>
 <alpine.LFD.2.03.1307221428050.15022@syhkavp.arg>
Message-ID: <51ED7B22.9040104@codethink.co.uk>

On 22/07/13 19:31, Nicolas Pitre wrote:
> On Fri, 19 Jul 2013, Ben Dooks wrote:
>> On 19/07/13 13:32, Russell King - ARM Linux wrote:
>>> If you value your soul, NEVER EVER EVER place stuff which is not part
>>> of the user API in a header file in a UAPI subdirectory.  And never
>>> modify a header file in a UAPI subdirectory without first having a
>>> good long think about how that modification may impact _userspace_.
>>
>> Sorry, searched for byteorder.h and just did not notice.
>>
>> Where is the best place for these to go?
>
> You should really have a look at arch/arm/include/asm/opcodes.h.

Yes, re-worked using <asm/opcodes.h> thanks.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From linux at arm.linux.org.uk  Mon Jul 22 14:43:26 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Jul 2013 19:43:26 +0100
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
Message-ID: <20130722184325.GA21614@n2100.arm.linux.org.uk>

On Mon, Jul 22, 2013 at 06:07:47PM +0000, Paul Walmsley wrote:
> After Linus's commit fb2af0020a51709ad87ea8055c325d3fbde04158 ("Merge 
> branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm"), the 
> OMAP2430 SDP here stopped booting.
> 
> Here's the bootlog at the commit before the merge, commit 790eac5640:
> 
> http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722015454/
> 
> and here's a log at commit fb2af0020a5:
> 
> http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722005921/
> 
> Any ideas as to what might have caused this?

Bear in mind that I'm almost at the point of not boot-testing anything
I sent to Linus because of the uselessness of the SDP4430 board now
that it's DT only - the only platform which boot-tests anything I send
is the 3430LDP board now.  If people care about that, maybe they can
assist with sorting out the issues I've raised on these lists about
the SDP4430 - and why the SDP4430 build remains disabled in my build
and boot system.

Looking at the boot log, it just stops after uboot hands over control.
With the lack of output from the decompressor, it's not possible to
tell whether it's a decompressor problem or a kernel problem.

I think you need to turn on the LL_DEBUG option, select the appropriate
output option, and also get the decompressor to use the kernel's debug
io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).


From sboyd at codeaurora.org  Mon Jul 22 14:45:41 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 22 Jul 2013 11:45:41 -0700
Subject: [PATCH v4 03/17] sched_clock: Use an hrtimer instead of timer
In-Reply-To: <51ED781F.6060300@linaro.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-4-git-send-email-sboyd@codeaurora.org>
 <51ED781F.6060300@linaro.org>
Message-ID: <51ED7DD5.8010000@codeaurora.org>

On 07/22/13 11:21, John Stultz wrote:
> On 07/18/2013 04:21 PM, Stephen Boyd wrote:
>> In the next patch we're going to increase the number of bits that
>> the generic sched_clock can handle to be greater than 32. With
>> more than 32 bits the wraparound time can be larger than what can
>> fit into the units that msecs_to_jiffies takes (unsigned int).
>> Luckily, the wraparound is initially calculated in nanoseconds
>> which we can easily use with hrtimers, so switch to using an
>> hrtimer.
>>
>> Cc: Russell King <linux at arm.linux.org.uk>
>> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>
>
> Hrmm. So in my testing (under qemu), this patch causes bootup to hang.
>
> qemu-system-arm -kernel zImage-arm -M vexpress-a9 -cpu cortex-a9
> -nographic -m 1024  -append 'root=/dev/mmcblk0p2 rw mem=1024M
> raid=noautodetect console=ttyAMA0,38400n8 rootwait vmalloc=256MB
> devtmpfs.mount=0' -sd test-arm.img -redir tcp:4300::22
>
> Config file attached.
>
> I haven't gotten a chance to look very closely, but it seems the
> folowing patch resolves the issue. I'm not sure if we're seeing
> callers to setup_sched_clock happen after sched_clock_postinit or
> what, but it probably needs another look over.
>
> thanks
> -john
>
>
> diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
> index a269890b..c018ffc 100644
> --- a/kernel/time/sched_clock.c
> +++ b/kernel/time/sched_clock.c
> @@ -138,12 +138,6 @@ void __init setup_sched_clock(u32 (*read)(void),
> int bits, unsigned long rate)
>      pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns,
> wraps every %lluns\n",
>          bits, r, r_unit, res, wrap);
>  
> -    /*
> -     * Start the timer to keep sched_clock() properly updated and
> -     * sets the initial epoch.
> -     */
> -    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> -    sched_clock_timer.function = sched_clock_poll;
>      update_sched_clock();
>  
>      /*
> @@ -175,6 +169,13 @@ void __init sched_clock_postinit(void)
>          setup_sched_clock(jiffy_sched_clock_read, 32, HZ);
>  
>      update_sched_clock();
> +
> +    /*
> +     * Start the timer to keep sched_clock() properly updated and
> +     * sets the initial epoch.
> +     */
> +    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> +    sched_clock_timer.function = sched_clock_poll;
>      hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
>  }
>  
>

Hmm. Is it too early to use hrtimers? Moving the hrtimer_start() into
sched_clock_register() also causes the same crash.

[    0.000000] Unable to handle kernel NULL pointer dereference at
virtual address 00000000
[    0.000000] pgd = c0004000
[    0.000000] [00000000] *pgd=00000000
[    0.000000] Internal error: Oops: 5 [#1] SMP ARM
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
3.11.0-rc1-00017-gecfb8ad-dirty #69
[    0.000000] task: c063b600 ti: c0630000 task.ti: c0630000
[    0.000000] PC is at _raw_spin_lock_irqsave+0xc/0x48
[    0.000000] LR is at lock_hrtimer_base+0x20/0x4c
[    0.000000] pc : [<c043b7f8>]    lr : [<c005edb8>]    psr: a00001d3
[    0.000000] sp : c0631f40  ip : 00000001  fp : 00000000
[    0.000000] r10: 00000000  r9 : 410fc090  r8 : c06e44c0
[    0.000000] r7 : c063c508  r6 : c0631f7c  r5 : c06e44c0  r4 : c062e538
[    0.000000] r3 : 00000024  r2 : 00000000  r1 : c0631f7c  r0 : a00001d3
[    0.000000] Flags: NzCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM 
Segment kernel
[    0.000000] Control: 10c5387d  Table: 6000406a  DAC: 00000015
[    0.000000] Process swapper/0 (pid: 0, stack limit = 0xc0630238)
[    0.000000] Stack: (0xc0631f40 to 0xc0632000)
[    0.000000] 1f40: c06be640 c06150a0 c0f05940 c005f344 00000000
00989680 755552dc 00000024
[    0.000000] 1f60: c063cd80 c0441354 755552dc 00000024 00000000
00000000 c063cd80 00000002
[    0.000000] 1f80: c0441354 c06be640 c06150a0 c0f05940 c063c508
6000406a 410fc090 00000000
[    0.000000] 1fa0: 00000000 c005f74c 00000000 00000001 00000001
00000000 00000000 c05e5984
[    0.000000] 1fc0: 00000001 c05c2e38 00000001 c05c06e0 ffffffff
ffffffff c05c02ec 00000000
[    0.000000] 1fe0: 00000000 c06150a0 10c5387d c0638418 c061509c
60008074 00000000 00000000
[    0.000000] [<c043b7f8>] (_raw_spin_lock_irqsave+0xc/0x48) from
[<c005edb8>] (lock_hrtimer_base+0x20/0x4c)
[    0.000000] [<c005edb8>] (lock_hrtimer_base+0x20/0x4c) from
[<c005f344>] (__hrtimer_start_range_ns+0x1c/0x3d8)
[    0.000000] [<c005f344>] (__hrtimer_start_range_ns+0x1c/0x3d8) from
[<c005f74c>] (hrtimer_start+0x20/0x28)
[    0.000000] [<c005f74c>] (hrtimer_start+0x20/0x28) from [<c05e5984>]
(sched_clock_postinit+0x44/0x5c)
[    0.000000] [<c05e5984>] (sched_clock_postinit+0x44/0x5c) from
[<c05c06e0>] (start_kernel+0x1d0/0x31c)
[    0.000000] [<c05c06e0>] (start_kernel+0x1d0/0x31c) from [<60008074>]
(0x60008074)
[    0.000000] Code: e12fff1e e1a02000 e10f0000 f10c0080 (e1923f9f)

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From Dave.Martin at arm.com  Mon Jul 22 14:52:39 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Mon, 22 Jul 2013 19:52:39 +0100
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y
In-Reply-To: <20130721213753.GA29879@mudshark.cambridge.arm.com>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
 <20130715135420.GG10000@mudshark.cambridge.arm.com>
 <20130720044655.GC9433@mozilla.com>
 <20130721213753.GA29879@mudshark.cambridge.arm.com>
Message-ID: <20130722185234.GA14519@localhost.localdomain>

On Sun, Jul 21, 2013 at 10:37:53PM +0100, Will Deacon wrote:
> Hello Jed,
> 
> Thanks for the reply.
> 
> On Sat, Jul 20, 2013 at 05:46:55AM +0100, Jed Davis wrote:
> > On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> > > On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> > [...]
> > > > Effects of this are probably limited to failure of EHABI unwinding when
> > > > starting from a function that uses r7 to restore its stack pointer, but
> > > > the possibility for further breakage (which would be invisible on
> > > > non-Thumb kernels) is worrying.
> > [...]
> > > I'm struggling to understand exactly the problem that this patch is trying
> > > to address. If it's just a code consistency issue, I don't think it's worth
> > > it (I actually find it less confusing the way we currently have things) but
> > > if there is a real bug, perhaps you could provide a testcase?
> > 
> > There is a real bug here, but my commit message wasn't very clear.  This
> > was breaking PERF_COUNT_SW_CONTEXT_SWITCHES with CONFIG_THUMB2_KERNEL=y
> > (with my other recently posted patch applied), because kernel/sched.c is
> > built with -fno-omit-frame-pointer (which is wrong, but that's a problem
> > for another patch) and so __schedule's EHABI entry uses 0x97 (mov sp, r7),
> > and somewhere along the line the unwinder gets the r11 value instead.
> > This would also apply to any function with a variable-length array, but
> > __schedule happens to have the perf hook I was trying to use.
> 
> Ok, I think I'm with you now. I also think that a better solution would be
> to try and limit the r7/fp confusion to one place, perhaps behind something
> like:
> 
> void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);
> 
> then that function can act as the bridge between pt_regs (where we leave
> everything as it is) and stackframe (where we assign either r7 or fp into
> the fp member). Then we just fix up the call sites to pass the regs they're
> interested in to our new function.
> 
> What do you think?

Do the ARM unwind tables guarantee not to need knowledge of any
virtual registers for the purpose of processing the opcodes of a single
function's unwind table entry, except those virtual regs that we happen
to initialise?  Or do we just rely on luck?

For compiler-generated unwind entries, sp is likely to be enough in most
cases... but I think that may be more a gcc implementation detail than
an ABI guarantee.  For custom unwind entries (we do have a few of those)
I think all bets might be off... but again, there's a limit to how
insane those are likely to be in practice, and there aren't many of
them.

If the unwind tables might need the value of r7 (or other random
registers), then we need r7 (or all possible regs) in struct stackframe.


Compiling a function with a simple runtime-sized array causes GCC
to generate:

        .setfp r7, sp, #0

among the unwind annotations, so the unwind opcodes will definitely
refer to r7 in that case.  But r7 is not a magic register in the ABI, so
I think the compiler would be allowed to use any other register for the
same purpose...

Frames of this sort will be relatively unusual, which might be why this
wasn't identified as a problem earlier.


GCC's commitment to r7 if a frame pointer is needed in Thumb appears
quite strong, even with -fomit-frame-pointer... but this is still
an implementation detail of GCC and a legacy of Thumb-1, rather than
ABI.

A variable-sized frame seems to cause GCC to force r7 as a framepointer
anyway.  Trying to clobber r7 from an asm within such a frame results
in a compile error, even with -fomit-frame-pointer.


The purist answer seems to be: we might need all the regs in struct
stackframe.

The pragmatic answer might be that we definitely need r7 for Thumb code,
but given the nimbleness of GCC to evolve we might get away with not
including extra registers for a long time yet.  Thumb code probably
doesn't use r11 ("fp") in the same way, though that will be needed for
ARM (with or without ARM_UNWIND).

A review of existing custom unwind annotations might be a good idea
anyway, to check whether any of them requires another register right now.


Cheers
---Dave



From nico at fluxnic.net  Mon Jul 22 14:53:23 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Mon, 22 Jul 2013 14:53:23 -0400 (EDT)
Subject: [PATCH 4/4] ARM: set --be8 when linking modules
In-Reply-To: <51ED69CA.3030501@codethink.co.uk>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374510833-25716-5-git-send-email-ben.dooks@codethink.co.uk>
 <20130722170500.GC19639@codeaurora.org> <51ED69CA.3030501@codethink.co.uk>
Message-ID: <alpine.LFD.2.03.1307221452210.15022@syhkavp.arg>

On Mon, 22 Jul 2013, Ben Dooks wrote:

> On 22/07/13 18:05, Stephen Boyd wrote:
> > On 07/22, Ben Dooks wrote:
> > > To avoid having to make every text section swap the instruction order
> > > of all instructions, make sure modules are built also built with --be8
> > > (as is the current kernel final link).
> > > 
> > > If we do not do this, we would end up having to swap all instructions
> > > when loading a module, instead of just the instructions that we are
> > > applying ELF relocations to.
> > > 
> > 
> > If someone tries to load a be8 module on a non-be8 kernel will it
> > still work? Or should we add an extra version magic string in
> > asm/module.h to prevent that?
> 
> The ELF header changes the EI_DATA field in the ei_ident from
> ELFDATA2LSB to ELFDATA2MSB when compiling so we should be able
> to detect these when loading.
> 
> I have not checked to see if the kernel correctly checks for this.
> 
> I do not think it currently checks the ei_flags field for the
> EF_ARM_BE8 in ABI 4 and 5. I am not sure if this is really important?

If the information is already there and easily accessible, then it 
should be used.


Nicolas


From ben.dooks at codethink.co.uk  Mon Jul 22 14:56:00 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 22 Jul 2013 19:56:00 +0100
Subject: [PATCH 4/4] ARM: set --be8 when linking modules
In-Reply-To: <alpine.LFD.2.03.1307221452210.15022@syhkavp.arg>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374510833-25716-5-git-send-email-ben.dooks@codethink.co.uk>
 <20130722170500.GC19639@codeaurora.org> <51ED69CA.3030501@codethink.co.uk>
 <alpine.LFD.2.03.1307221452210.15022@syhkavp.arg>
Message-ID: <51ED8040.2020803@codethink.co.uk>

On 22/07/13 19:53, Nicolas Pitre wrote:
> On Mon, 22 Jul 2013, Ben Dooks wrote:
>
>> On 22/07/13 18:05, Stephen Boyd wrote:
>>> On 07/22, Ben Dooks wrote:
>>>> To avoid having to make every text section swap the instruction order
>>>> of all instructions, make sure modules are built also built with --be8
>>>> (as is the current kernel final link).
>>>>
>>>> If we do not do this, we would end up having to swap all instructions
>>>> when loading a module, instead of just the instructions that we are
>>>> applying ELF relocations to.
>>>>
>>>
>>> If someone tries to load a be8 module on a non-be8 kernel will it
>>> still work? Or should we add an extra version magic string in
>>> asm/module.h to prevent that?
>>
>> The ELF header changes the EI_DATA field in the ei_ident from
>> ELFDATA2LSB to ELFDATA2MSB when compiling so we should be able
>> to detect these when loading.
>>
>> I have not checked to see if the kernel correctly checks for this.
>>
>> I do not think it currently checks the ei_flags field for the
>> EF_ARM_BE8 in ABI 4 and 5. I am not sure if this is really important?
>
> If the information is already there and easily accessible, then it
> should be used.
>
>
> Nicolas

I have something like this, it does not mess things up loading
BE8 binaries on my current system. I think we're building stuff
for EABI4 but haven't checked.

diff --git a/arch/arm/kernel/elf.c b/arch/arm/kernel/elf.c
index d0d1e83..3b0351c 100644
--- a/arch/arm/kernel/elf.c
+++ b/arch/arm/kernel/elf.c
@@ -34,6 +34,15 @@ int elf_check_arch(const struct elf32_hdr *x)
                 if (flt_fmt == EF_ARM_VFP_FLOAT && !(elf_hwcap & 
HWCAP_VFP))
                         return 0;
         }
+
+       if ((eflags & EF_ARM_EABI_MASK) >= EF_ARM_EABI_VER4) {
+               if (eflags & EF_ARM_BE8) {
+                       if (!IS_ENABLED(CONFIG_ARM_CPU_BE8))
+                               return 1;
+               } else if (IS_ENABLED(CONFIG_ARM_CPU_BE8))
+                       return 1;
+       }
+

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From sboyd at codeaurora.org  Mon Jul 22 14:58:47 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 22 Jul 2013 11:58:47 -0700
Subject: [PATCH v4 03/17] sched_clock: Use an hrtimer instead of timer
In-Reply-To: <51ED7DD5.8010000@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-4-git-send-email-sboyd@codeaurora.org>
 <51ED781F.6060300@linaro.org> <51ED7DD5.8010000@codeaurora.org>
Message-ID: <51ED80E7.4050606@codeaurora.org>

On 07/22/13 11:45, Stephen Boyd wrote:
> On 07/22/13 11:21, John Stultz wrote:
>> On 07/18/2013 04:21 PM, Stephen Boyd wrote:
>>> In the next patch we're going to increase the number of bits that
>>> the generic sched_clock can handle to be greater than 32. With
>>> more than 32 bits the wraparound time can be larger than what can
>>> fit into the units that msecs_to_jiffies takes (unsigned int).
>>> Luckily, the wraparound is initially calculated in nanoseconds
>>> which we can easily use with hrtimers, so switch to using an
>>> hrtimer.
>>>
>>> Cc: Russell King <linux at arm.linux.org.uk>
>>> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>>
>> Hrmm. So in my testing (under qemu), this patch causes bootup to hang.
>>
>> qemu-system-arm -kernel zImage-arm -M vexpress-a9 -cpu cortex-a9
>> -nographic -m 1024  -append 'root=/dev/mmcblk0p2 rw mem=1024M
>> raid=noautodetect console=ttyAMA0,38400n8 rootwait vmalloc=256MB
>> devtmpfs.mount=0' -sd test-arm.img -redir tcp:4300::22
>>
>> Config file attached.
>>
>> I haven't gotten a chance to look very closely, but it seems the
>> folowing patch resolves the issue. I'm not sure if we're seeing
>> callers to setup_sched_clock happen after sched_clock_postinit or
>> what, but it probably needs another look over.
>>
>> thanks
>> -john
>>
>>
>> diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
>> index a269890b..c018ffc 100644
>> --- a/kernel/time/sched_clock.c
>> +++ b/kernel/time/sched_clock.c
>> @@ -138,12 +138,6 @@ void __init setup_sched_clock(u32 (*read)(void),
>> int bits, unsigned long rate)
>>      pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns,
>> wraps every %lluns\n",
>>          bits, r, r_unit, res, wrap);
>>  
>> -    /*
>> -     * Start the timer to keep sched_clock() properly updated and
>> -     * sets the initial epoch.
>> -     */
>> -    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
>> -    sched_clock_timer.function = sched_clock_poll;
>>      update_sched_clock();
>>  
>>      /*
>> @@ -175,6 +169,13 @@ void __init sched_clock_postinit(void)
>>          setup_sched_clock(jiffy_sched_clock_read, 32, HZ);
>>  
>>      update_sched_clock();
>> +
>> +    /*
>> +     * Start the timer to keep sched_clock() properly updated and
>> +     * sets the initial epoch.
>> +     */
>> +    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
>> +    sched_clock_timer.function = sched_clock_poll;
>>      hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
>>  }
>>  
>>
> Hmm. Is it too early to use hrtimers? Moving the hrtimer_start() into
> sched_clock_register() also causes the same crash.

Yes that seems to be the problem. The vexpress board is setting up the
sched_clock in setup_arch() (via v2m_init_early) which runs before
hrtimers_init(). I've only tested this on boards that setup the timer in
the time_init() callback which runs after hrtimers_init(). Your patch
should be fine, although it would be nice if we didn't have callers
setting up the sched_clock so early.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From linux at arm.linux.org.uk  Mon Jul 22 15:07:17 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Jul 2013 20:07:17 +0100
Subject: [PATCH v4 03/17] sched_clock: Use an hrtimer instead of timer
In-Reply-To: <51ED80E7.4050606@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-4-git-send-email-sboyd@codeaurora.org>
 <51ED781F.6060300@linaro.org> <51ED7DD5.8010000@codeaurora.org>
 <51ED80E7.4050606@codeaurora.org>
Message-ID: <20130722190717.GO24642@n2100.arm.linux.org.uk>

On Mon, Jul 22, 2013 at 11:58:47AM -0700, Stephen Boyd wrote:
> On 07/22/13 11:45, Stephen Boyd wrote:
> > Hmm. Is it too early to use hrtimers? Moving the hrtimer_start() into
> > sched_clock_register() also causes the same crash.
> 
> Yes that seems to be the problem. The vexpress board is setting up the
> sched_clock in setup_arch() (via v2m_init_early) which runs before
> hrtimers_init(). I've only tested this on boards that setup the timer in
> the time_init() callback which runs after hrtimers_init(). Your patch
> should be fine, although it would be nice if we didn't have callers
> setting up the sched_clock so early.

However, it _is_ the correct place to do it, as I've repeatedly stated.
The reason for this is that the scheduler will have already read from
sched_clock() by the time you get to timer_init() to seed its idea of
the start time for PID0 - again, as I've explained multiple times.


From tomasz.figa at gmail.com  Mon Jul 22 15:25:35 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 21:25:35 +0200
Subject: [PATCH 07/22] ARM: exynos: Remove '0x's from Exynos4110 DTSI file
In-Reply-To: <1374490361-25769-7-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-7-git-send-email-lee.jones@linaro.org>
Message-ID: <2350088.9z671SCjFz@flatron>

Hi Lee,

On Monday 22 of July 2013 11:52:26 Lee Jones wrote:
> Cc: Kukjin Kim <kgene.kim at samsung.com>
> Cc: linux-samsung-soc at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  arch/arm/boot/dts/exynos4210.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> b/arch/arm/boot/dts/exynos4210.dtsi index b7f358a..53e2527 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -72,7 +72,7 @@
>  		};
>  	};
> 
> -	clock: clock-controller at 0x10030000 {
> +	clock: clock-controller at 10030000 {
>  		compatible = "samsung,exynos4210-clock";
>  		reg = <0x10030000 0x20000>;
>  		#clock-cells = <1>;

This looks fine, but please fix commit message - it should be Exynos4210. 
Also some explanation why this change is needed would be good, even if 
it's obvious.

Best regards,
Tomasz



From tomasz.figa at gmail.com  Mon Jul 22 15:28:53 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 21:28:53 +0200
Subject: [PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
In-Reply-To: <51ED3AF6.3090004@samsung.com>
References: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
 <027201ce86df$cd883d90$6898b8b0$%dae@samsung.com>
 <51ED3AF6.3090004@samsung.com>
Message-ID: <1654536.B4gG8HrWlH@flatron>

On Monday 22 of July 2013 16:00:22 Sylwester Nawrocki wrote:
> On 07/22/2013 03:31 PM, Inki Dae wrote:
> >> ---Original Message-----
> >> 
> >> > From: linux-samsung-soc-owner at vger.kernel.org
> >> > [mailto:linux-samsung-soc- owner at vger.kernel.org] On Behalf Of
> >> > Lucas Stach
> >> > Sent: Monday, July 22, 2013 9:47 PM
> >> > To: Inki Dae
> >> > Cc: 'Mark Rutland'; 'Chanho Park';
> >> > linux-samsung-soc at vger.kernel.org;
> >> > devicetree-discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> >> > devel at lists.freedesktop.org; kyungmin.park at samsung.com;
> >> > kgene.kim at samsung.com; linux-arm-kernel at lists.infradead.org
> >> > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation
> >> > for
> >> > rotator
> >> > 
> >> > Am Montag, den 22.07.2013, 21:37 +0900 schrieb Inki Dae:
> >>>> > > > -----Original Message-----
> >>>> > > > From: Mark Rutland [mailto:mark.rutland at arm.com]
> >>>> > > > Sent: Monday, July 22, 2013 5:48 PM
> >>>> > > > To: Chanho Park
> >>>> > > > Cc: inki.dae at samsung.com; kgene.kim at samsung.com;
> >>>> > > > linux-samsung-
> >>>> > > > soc at vger.kernel.org; jy0922.shim at samsung.com; devicetree-
> >>>> > > > discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> >>>> > > > devel at lists.freedesktop.org; kyungmin.park at samsung.com;
> >>>> > > > linux-arm-
> >>>> > > > kernel at lists.infradead.org
> >>>> > > > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding
> >>>> > > > documentation for
> >>>> > > > rotator
> >>>> > > > 
> >>>> > > > On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> >>>>> > > > > This patch adds a dt-binding document for exynos rotator.
> >>>>> > > > > It
> >> > 
> >> > describes
> >> > 
> >>>> > > > which
> >>>> > > > 
> >>>>> > > > > nodes should be defined to use the rotator.
> >>>>> > > > > 
> >>>>> > > > > Signed-off-by: Chanho Park <chanho61.park at samsung.com>
> >>>>> > > > > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> >>>>> > > > > ---
> >>>>> > > > > 
> >>>>> > > > >  .../bindings/drm/exynos/samsung-rotator.txt        |   35
> >>>> > > > 
> >>>> > > > ++++++++++++++++++++
> >>>> > > > 
> >>>>> > > > >  1 file changed, 35 insertions(+)
> >>>>> > > > >  create mode 100644
> >>>> > > > 
> >>>> > > > Documentation/devicetree/bindings/drm/exynos/samsung-rotator.
> >>>> > > > txt
> >>>> > > > 
> >>>>> > > > > diff --git
> >>>>> > > > > a/Documentation/devicetree/bindings/drm/exynos/samsung-
> >>>> > > > 
> >>>> > > > rotator.txt
> >>>> > > > b/Documentation/devicetree/bindings/drm/exynos/samsung-
> >>>> > > > rotator.txt
> >>>> > > > 
> >>>>> > > > > new file mode 100644
> >>>>> > > > > index 0000000..6b1d704
> >>>>> > > > > --- /dev/null
> >>>>> > > > > +++
> >>>>> > > > > b/Documentation/devicetree/bindings/drm/exynos/samsung-
> >> > 
> >> > rotator.txt
> >> > 
> >>>>> > > > > @@ -0,0 +1,35 @@
> >>>>> > > > > +* Samsung Image Rotator
> >>>>> > > > > +
> >>>>> > > > > +Required properties:
> >>>>> > > > > +  - compatible : value should be the
> >>>>> > > > > "samsung,exynos4210".
> >>> > > 
> >>> > > Please, add more compatible strings for other SoC.
> >>> > > 
> >>>>> > > > > +  - reg : Physical base address of the IP registers and
> >>>>> > > > > length of
> >>>> > > > 
> >>>> > > > memory
> >>>> > > > 
> >>>>> > > > > +	  mapped region.
> >>>>> > > > > +  - interrupts : interrupt number to the CPU.
> >>>>> > > > > +  - clocks : clock number of exynos4 rotator clock.
> >>>>> > > > > +  - clocks : clock name of rotator
> >>>> > > > 
> >>>> > > > clock-names?
> >>>> > > > 
> >>>>> > > > > +  - status : "okay" or "disabled"
> >>>>> > > > > +  - limit table for image formats :
> >>>>> > > > > min_w/min_h/max_w/max_h for
> >> > 
> >> > min/max
> >> > 
> >>>> > > > of image
> >>>> > > > 
> >>>> > > > Limit table? This doesn't seem to be a well-defined binding,
> >>>> > > > and it
> >>>> > > > seems like a relatively generic thing to describe.
> >>>> > > > 
> >>>>> > > > > +
> >>>>> > > > > +Example:
> >>>>> > > > > +	rotator: rotator at 12810000 {
> >>>>> > > > > +		compatible = "samsung,exynos4210-rotator";
> >>>>> > > > > +		reg = <0x12810000 0x1000>;
> >>>>> > > > > +		interrupts = <0 83 0>;
> >>>>> > > > > +		clocks = <&clock 278>;
> >>>>> > > > > +		clock-names = "rotator";
> >>>>> > > > > +		status = "disabled";
> >>>>> > > > > +		ycbcr420_2p {
> >>>> > > > 
> >>>> > > > Which names are allowed for these subnodes?
> >>>> > > > 
> >>>>> > > > > +			min_w = <32>;
> >>>>> > > > > +			min_h = <32>;
> >>>>> > > > > +			max_w = <32768>;
> >>>>> > > > > +			max_h = <32768>;
> >>>>> > > > > +			align = <3>;
> >>>> > > > 
> >>>> > > > min-width, min-height, max-width, max-height? What units are
> >>>> > > > they in?
> >>>> > > > 
> >>>> > > > What does alignment specify exactly?
> >>>> > > > 
> >>>> > > > Are these a configurable part of the rotator hardware, or are
> >>>> > > > these
> >>>> > > > values always the same?
> >>> > > 
> >>> > > Right, that seems like configurable part. At least, min_w/h and
> >>> > > max_w/h
> >> > 
> >> > can
> >> > 
> >>> > > be different values according to SoC and pixel formats so they
> >>> > > should be described enough in this dt-binding document file.
> >> > 
> >> > Is there really this much configurability? Could each of those
> >> > values be a different on different SoCs
> > 
> > Not much but Yes. Rotator devices of Exynos SoC support various pixel
> > formats; RGB888, RGB565, YUV422, YUV420-2Plane, and YUV420-3Plane,
> > and each of these pixel formats could be different limitation to
> > minimum and maximum sizes. For example, the below shows the
> > limitation to Rotator device of Exynos4412 SoC according to pixel
> > formats,> 
> >          Image format          Minimum size          Maximum size
> >          
> >           RGB888                    8x8                     8kx8k
> >           RGB565                    16x16                  16kx16k
> >           YUV422                    16x16                  16kx16k
> >           YUV420 2-Plane         32x32                  32kx32k(in
> >           case of Y components) YUV420 3-Plane         64x32         
> >                   32kx32k(in case of Y components)> 
> > And, I guess those limitations are slightly different according to
> > Exynos SoC versions as long as I know.
> > 
> > Thanks,
> > Inki Dae
> > 
> >> > , or could you just extract those values
> >> > from the SoC/rotator hardware version and thus the DT compatible
> >> > string?
> My gut feeling is that those constraints could be well defined
> in the driver as static data and selected by the compatible property.
> Defining this in Device Tree may easily get out of control, when the
> limits become dependant on more parameters.
> 
> Whether devices should be described in much detail in DT rather than
> using multiple compatible strings had been discussed multiple times,
> for instance please see thread [1].

+1

The binding should not describe hardware functionality and how it works, 
but rather what hardware it is, unless it is really necessary. In this 
case this information can be placed in per-compatible static driver data, 
so there is no such need.

Best regards,
Tomasz



From tomasz.figa at gmail.com  Mon Jul 22 15:32:07 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 21:32:07 +0200
Subject: [PATCH 1/3] drm/exynos: add device tree support for rotator
In-Reply-To: <1374475767-30085-2-git-send-email-chanho61.park@samsung.com>
References: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
 <1374475767-30085-2-git-send-email-chanho61.park@samsung.com>
Message-ID: <1944640.dQgavdmLbq@flatron>

On Monday 22 of July 2013 15:49:25 Chanho Park wrote:
> The exynos4 platform is only dt-based since 3.10, we should convert
> driver data and ids to dt-based parsing methods. The rotator driver has
> a limit table to get size limit. The minimum size of RGB888 format is 8
> x 8 and maximum size is 8K x 8K. The other format, YCbCr420 2-Plane has
> 32 x 32 min size and 32K x 32K max size. Each format should be multiple
> of 'align' value.
> 
> Signed-off-by: Chanho Park <chanho61.park at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c |  110
> +++++++++++++++++++-------- 1 file changed, 80 insertions(+), 30
> deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> b/drivers/gpu/drm/exynos/exynos_drm_rotator.c index 427640a..b353a10
> 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -96,7 +96,7 @@ struct rot_context {
>  	struct resource	*regs_res;
>  	void __iomem	*regs;
>  	struct clk	*clock;
> -	struct rot_limit_table	*limit_tbl;
> +	struct rot_limit_table	limit_tbl;
>  	int	irq;
>  	int	cur_buf_id[EXYNOS_DRM_OPS_MAX];
>  	bool	suspended;
> @@ -167,7 +167,7 @@ static irqreturn_t rotator_irq_handler(int irq, void
> *arg) static void rotator_align_size(struct rot_context *rot, u32 fmt,
> u32 *hsize, u32 *vsize)
>  {
> -	struct rot_limit_table *limit_tbl = rot->limit_tbl;
> +	struct rot_limit_table *limit_tbl = &rot->limit_tbl;
>  	struct rot_limit *limit;
>  	u32 mask, val;
> 
> @@ -632,6 +632,72 @@ static int rotator_ippdrv_start(struct device *dev,
> enum drm_exynos_ipp_cmd cmd) return 0;
>  }
> 
> +static const struct of_device_id exynos_rotator_match[] = {
> +	{
> +		.compatible = "samsung,exynos4210-rotator",
> +	},
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_rotator_match);
> +
> +static int rotator_parse_dt_tbl(struct device_node *np, struct
> rot_limit *rlim) +{
> +	int ret;
> +
> +	ret = of_property_read_u32(np, "min_w", &rlim->min_w);
> +	if (ret)
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "min_h", &rlim->min_h);
> +	if (ret)
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "max_w", &rlim->max_w);
> +	if (ret)
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "max_h", &rlim->max_h);
> +	if (ret)
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "align", &rlim->align);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +static int rotator_parse_dt(struct device *dev, struct rot_context
> *rot) +{
> +	struct device_node *ycbcr_node, *rgb888_node;
> +	int ret;
> +
> +	ycbcr_node = of_get_child_by_name(dev->of_node, "ycbcr420_2p");
> +	if (!ycbcr_node) {
> +		dev_err(dev, "can't find ycbcr420_2p node\n");
> +		return -ENODEV;
> +	}
> +
> +	rgb888_node = of_get_child_by_name(dev->of_node, "rgb888");
> +	if (!rgb888_node) {
> +		dev_err(dev, "can't find rgb888 node\n");
> +		return -ENODEV;
> +	}
> +
> +	ret = rotator_parse_dt_tbl(ycbcr_node, &rot-
>limit_tbl.ycbcr420_2p);
> +	if (ret) {
> +		dev_err(dev, "failed to parse ycbcr420 data\n");
> +		return ret;
> +	}
> +	ret = rotator_parse_dt_tbl(rgb888_node, &rot->limit_tbl.rgb888);
> +	if (ret) {
> +		dev_err(dev, "failed to parse rgb888 data\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
>  static int rotator_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> @@ -639,14 +705,23 @@ static int rotator_probe(struct platform_device
> *pdev) struct exynos_drm_ippdrv *ippdrv;
>  	int ret;
> 
> +	if (!dev->of_node) {
> +		dev_err(dev, "Cannot find device tree node\n");
> +		return -ENODEV;
> +	}
> +
>  	rot = devm_kzalloc(dev, sizeof(*rot), GFP_KERNEL);
>  	if (!rot) {
>  		dev_err(dev, "failed to allocate rot\n");
>  		return -ENOMEM;
>  	}
> 
> -	rot->limit_tbl = (struct rot_limit_table *)
> -				platform_get_device_id(pdev)->driver_data;
> +	ret = rotator_parse_dt(dev, rot);
> +	if (ret) {
> +		dev_err(dev, "failed parse dt info\n");
> +		devm_kfree(dev, rot);
> +		return ret;
> +	}
> 
>  	rot->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	rot->regs = devm_ioremap_resource(dev, rot->regs_res);
> @@ -718,31 +793,6 @@ static int rotator_remove(struct platform_device
> *pdev) return 0;
>  }
> 
> -static struct rot_limit_table rot_limit_tbl = {
> -	.ycbcr420_2p = {
> -		.min_w = 32,
> -		.min_h = 32,
> -		.max_w = SZ_32K,
> -		.max_h = SZ_32K,
> -		.align = 3,
> -	},
> -	.rgb888 = {
> -		.min_w = 8,
> -		.min_h = 8,
> -		.max_w = SZ_8K,
> -		.max_h = SZ_8K,
> -		.align = 2,
> -	},
> -};
> -
> -static struct platform_device_id rotator_driver_ids[] = {
> -	{
> -		.name		= "exynos-rot",
> -		.driver_data	= (unsigned long)&rot_limit_tbl,
> -	},
> -	{},
> -};
> -

I would keep these driver data here and just point to them from match_data 
of OF match table, as suggested in other replies.

Best regards,
Tomasz



From olof at lixom.net  Mon Jul 22 15:34:59 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 22 Jul 2013 12:34:59 -0700
Subject: [PATCH v4 00/20] Samsung PWM support cleanup
In-Reply-To: <0ac901ce867f$638a7530$2a9f5f90$@org>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <51EC5F18.8040007@gmail.com> <9102768.ef8LAvpunv@flatron>
 <0ac901ce867f$638a7530$2a9f5f90$@org>
Message-ID: <CAOesGMixczupXEv-iz2nd2GM0i5DTQvVaF2DqjFnDBqsCNKCYQ@mail.gmail.com>

On Sun, Jul 21, 2013 at 7:01 PM, Kukjin Kim <kgene at kernel.org> wrote:

>> Yes, this whole patches look good to me, and I'd like to take this whole
>> patches into the samsung tree...but need to get any response from PWM guy,
>> Thierry Reding. Let's wait for his response...
>>
> To be clarify, because his ack was on v3 and I remember he had a comment. So
> would be better if we could get his ack on pwm change again.
>
> Thanks,
> Kukjin
>

This is a nice cleanup series indeed.

Given the volume of changes coming from Tomasz, it seems appropriate
that he just sends you pull requests with this as a branch when they
are ready to go (i.e. have the appropriate acks), instead of you
having to apply them by hand, Kukjin.


-Olof


From sylvester.nawrocki at gmail.com  Mon Jul 22 15:36:42 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Mon, 22 Jul 2013 21:36:42 +0200
Subject: [PATCH 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <3136364.6D0qu7zGk3@amdc1227>
References: <1372054438-15693-1-git-send-email-sachin.kamat@linaro.org>
 <CAK9yfHzmF_oxc3DsuT5wtXX2C5O+wLxz4C2Ps3cVPnKLb8jOEw@mail.gmail.com>
 <0ad601ce868c$d88bff40$89a3fdc0$@org> <3136364.6D0qu7zGk3@amdc1227>
Message-ID: <51ED89CA.2040908@gmail.com>

On 07/22/2013 07:21 PM, Tomasz Figa wrote:
> On Monday 22 of July 2013 12:37:52 Kukjin Kim wrote:
>> Sachin Kamat wrote:
>>> On 22 July 2013 07:18, Kukjin Kim<kgene.kim at samsung.com>  wrote:
>>>> Sachin Kamat wrote:
>>>>> With the recent cleanup in Exynos platform code notably commits
>>>>> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
>>>>> more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the
>>>>> definition
>>>>> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs
>>>
>>> like
>>>
>>>>> Exynos4412 which have more (285) than the default number of GPIOs
>>
>> (255).
>>
>>>>> Thus define this number in Kconfig file. Without this patch we get
>>>>> the
>>>>> following errors during boot:
>>>>>
>>>>> gpiochip_add: gpios 251..258 (gpv0) failed to register
>>>>> samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
>>>>> error code: -22
>>>>> samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
>>>>>
>>>>> Signed-off-by: Sachin Kamat<sachin.kamat at linaro.org>
>>>>> Cc: Tomasz Figa<t.figa at samsung.com>
>>>>> ---
>>>>> Based on Kukjin's for-next tree.
>>>>> ---
>>>>>
>>>>>   arch/arm/Kconfig |    1 +
>>>>>   1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>>>> index ddf2667..380a53b 100644
>>>>> --- a/arch/arm/Kconfig
>>>>> +++ b/arch/arm/Kconfig
>>>>> @@ -1578,6 +1578,7 @@ config ARCH_NR_GPIO
>>>>>
>>>>>        default 512 if SOC_OMAP5
>>>>>        default 392 if ARCH_U8500
>>>>>        default 352 if ARCH_VT8500
>>>>>
>>>>> +     default 288 if ARCH_EXYNOS
>>>>>
>>>>>        default 288 if ARCH_SUNXI
>>>>>        default 264 if MACH_H4700
>>>>>        default 0
>>>>>
>>>>> --
>>>>> 1.7.9.5
>>>>
>>>> Hmm, BTW, I'm wondering why it is 288 not 285 or other specific
>>
>> number...
>>
>>> I wasn't really sure if we can have any number there. I chose the
>>> closest one (288) which was already used by other platform.
>>> If there is no problem to use 285 itself then I can resend with that
>>> number. Please let me know.
>>
>> If there is no reason, please don't use bigger value than necessary one.
>
> Hmm, what about some GPIO expanders that would require bigger GPIO address
> space? I would reserve some space just in case, i.e. define this value to be
> the highest number of GPIOs on all Exynos SoCs + some extra, like 32 or 64.

That sounds like a good idea. IIRC I once had to increase ARCH_NR_GPIO to
make the wm8994 GPIO controller working. The wm8994 driver also handles
WM1811 audio codec that some Exynos development boards are shipped with.

--
Regards,
Sylwester


From tomasz.figa at gmail.com  Mon Jul 22 15:42:31 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 21:42:31 +0200
Subject: [PATCH 2/4] clk: exynos-audss: allow input clocks to be specified
 in device tree
In-Reply-To: <20130722181530.7598.73318@quantum>
References: <1373458313-18970-1-git-send-email-padma.v@samsung.com>
 <1610421.OFFn8rqlxt@amdc1227> <20130722181530.7598.73318@quantum>
Message-ID: <5824726.DGbrnrmYE0@flatron>

On Monday 22 of July 2013 11:15:30 Mike Turquette wrote:
> Quoting Tomasz Figa (2013-07-22 09:28:47)
> 
> > Hi Padmavathi, Andrew,
> > 
> > On Wednesday 10 of July 2013 17:41:51 Padmavathi Venna wrote:
> > > From: Andrew Bresticker <abrestic at chromium.org>
> > > 
> > > This allows the input clocks to the Exynos AudioSS block to be
> > > specified via device-tree bindings.  Default names will be used
> > > when an input clock is not given.  This will be useful when adding
> > > support for the Exynos5420 where the audio bus clock is called
> > > "sclk_maudio0" instead of "sclk_audio0".
> > > 
> > > Signed-off-by: Andrew Bresticker <abrestic at chromium.org>
> > > Reviewed-on: https://gerrit.chromium.org/gerrit/57833
> > > Reviewed-by: Simon Glass <sjg at chromium.org>
> > > ---
> > > 
> > >  .../devicetree/bindings/clock/clk-exynos-audss.txt |   31
> > > 
> > > ++++++++++++++++++- drivers/clk/samsung/clk-exynos-audss.c          
> > >   |> > 
> > >   28 +++++++++++++++-- 2 files changed, 53 insertions(+), 6
> > >   deletions(-)
> > 
> > Well, this is basically how it should be done, but in current state of
> > clock core I can see a problem: can we really rely on the order of
> > clock initialization? I mean, we can't defer initialization of
> > particular clock controller until all external clocks it needs are
> > available, because there is no probing involved here.
> 
> The clock core allows registering clocks even if their parents are not
> yet registered. I test this path with some dummy clocks every so often
> to make sure the re-parenting operation are completed successfully after
> the parents eventually are registered.

Sure it does, but this patch is about something different. It adds device 
tree based lookup (of_clk_get_by_name()) of external clocks (as opposed to 
existing lookup by name), which will fail if provider pointed by phandle 
is not registered yet.

> This feature was not used in practice until recently with the advent of
> multiple clock controllers getting registered and DT description of
> clocks / clock controllers that may be "out of order". If you find any
> bugs please let me know ;-)

I will send you a bunch of patches sorting out issues I found in 
clk_set_rate() path, but give me some time to prepare them :).

As for multiple clock controllers, this is going to be funny. I have 
discussed this a bit with Sylwester and we managed to find some design 
issues that I think must be solved:

a) What about multiple controllers with identical clock names? Imagine two 
PMICs that can also generate 32 KHz clocks, both having them named 
"clk32k". Am I right saying that this won't work with current code?

b) What are the rules of using clock-output-names property (and what 
should be used in non-DT case)? I can imagine using it to assign platform-
specific names of clock outputs of extra clock controllers (this would 
help in the above case of "clk32k"), but currently it seems like it is 
optional to use it in clock drivers and the meaning is provider-specific.

Best regards,
Tomasz



From konrad.wilk at oracle.com  Mon Jul 22 16:00:20 2013
From: konrad.wilk at oracle.com (Konrad Rzeszutek Wilk)
Date: Mon, 22 Jul 2013 16:00:20 -0400
Subject: [PATCH v3] xen/arm: enable PV control for ARM
In-Reply-To: <alpine.DEB.2.02.1307221545030.4893@kaball.uk.xensource.com>
References: <1374490654-13373-1-git-send-email-julien.grall@linaro.org>
 <20130722134934.GB32221@e106331-lin.cambridge.arm.com>
 <alpine.DEB.2.02.1307221459200.4893@kaball.uk.xensource.com>
 <20130722143920.GC32221@e106331-lin.cambridge.arm.com>
 <alpine.DEB.2.02.1307221545030.4893@kaball.uk.xensource.com>
Message-ID: <20130722200020.GT30300@phenom.dumpdata.com>

On Mon, Jul 22, 2013 at 03:46:34PM +0100, Stefano Stabellini wrote:
> On Mon, 22 Jul 2013, Mark Rutland wrote:
> > On Mon, Jul 22, 2013 at 03:09:35PM +0100, Stefano Stabellini wrote:
> > > On Mon, 22 Jul 2013, Mark Rutland wrote:
> > > > Hi,
> > > > 
> > > > [Adding Catalin to Cc]
> > > > 
> > > > On Mon, Jul 22, 2013 at 11:57:34AM +0100, Julien Grall wrote:
> > > > > Enable power management from the toolstack for ARM guest.
> > > > > 
> > > > > Signed-off-by: Julien Grall <julien.grall at linaro.org>
> > > > > 
> > > > > ---
> > > > >     Changes in v3:
> > > > >         - Fix condition to compile cpu_hotplug.o
> > > > >     Changes in v2:
> > > > >         - Don't compile xen/cpu_hotplug.o with ARM64
> > > > 
> > > > My arm64 cpu hotplug series is going to be dependent on not compiling
> > > > xen/cpu_hotplug.o. Currently I'm not able to compile an arm64 kernel
> > > > with my patches and Xen support.
> > > > 
> > > > How do you intend to push this? I'd like to ensure my cpu hotplug series
> > > > is able to go in for the next merge window.
> > > 
> > > This patch does exactly that: it makes sure cpu_hotplug is not compiled
> > > on ARM64.
> > 
> > Sorry, what I meant was that my series is going to be entirely dependent
> > on this patch or it'll break bisection. That'll make merging things a
> > little painful as I'll need a stable branch with this patch to base my
> > series upon.
> > 
> > Another option would be to split this patch into two parts, one enabling
> > power management and one fixing things up for HOTPLUG_CPU on arm64. That
> > way I could take the arm64 HOTPLUG_CPU fix in my series adding arm64
> > HOTPLUG_CPU support.
> > 
> > Would that be acceptable? Have I missed something?
> 
> As I am very sensitive to painful merging situations, I think we could
> split the patch in two and send upstream the fix (not compiling
> cpu_hotplug.o on ARM64) in 3.11-rc2 or rc3.  Konrad, what do you think?

Sure, prep a patch and send it my way.


From nico at fluxnic.net  Mon Jul 22 16:02:45 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Mon, 22 Jul 2013 16:02:45 -0400 (EDT)
Subject: [GIT PULL] MCPM backends update
Message-ID: <alpine.LFD.2.03.1307221521200.15022@syhkavp.arg>

Hello gents,

Would you please pull the following into ARM-SOC:

	git://git.linaro.org/people/nico/linux mcpm+tc2

This contains

- Fixes to the existing Vexpress DCSCB backend.

- Lorenzo's minimal SPC driver required by the TC2 MCPM backend.
  As discussed on the list, this is not considered to be a MFD driver.
  This hardly qualify as a bus driver either.  Conceptually, this is
  a very platform specific register multiplex driver allowing subsystem
  drivers to hook into.  I therefore moved it to 
  drivers/platform/vexpress/ which seems to please everyone.

- The MCPM backend enabling SMP secondary boot and CPU hotplug
  on the VExpress TC2 big.LITTLE platform.

- MCPM suspend method to the TC2 backend allowing basic CPU 
  idle/suspend.  The cpuidle driver that hooks into this will be 
  submitted separately.

This is based on v3.11-rc2.  The diffstat follows:

 .../devicetree/bindings/arm/vexpress-spc.txt       |  36 +++
 arch/arm/mach-vexpress/Kconfig                     |   9 +
 arch/arm/mach-vexpress/Makefile                    |   1 +
 arch/arm/mach-vexpress/dcscb.c                     |  58 ++--
 arch/arm/mach-vexpress/tc2_pm.c                    | 304 +++++++++++++++++++++
 drivers/platform/Kconfig                           |   4 +-
 drivers/platform/Makefile                          |   1 +
 drivers/platform/vexpress/Kconfig                  |   9 +
 drivers/platform/vexpress/Makefile                 |   1 +
 drivers/platform/vexpress/spc.c                    | 253 +++++++++++++++++
 include/linux/vexpress.h                           |  17 ++
 11 files changed, 671 insertions(+), 22 deletions(-)


Nicolas


From paul at pwsan.com  Mon Jul 22 16:07:04 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 22 Jul 2013 20:07:04 +0000 (UTC)
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <20130722184325.GA21614@n2100.arm.linux.org.uk>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
Message-ID: <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>

On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:

> Bear in mind that I'm almost at the point of not boot-testing anything
> I sent to Linus because of the uselessness of the SDP4430 board now
> that it's DT only - the only platform which boot-tests anything I send
> is the 3430LDP board now.  If people care about that, maybe they can
> assist with sorting out the issues I've raised on these lists about
> the SDP4430 - and why the SDP4430 build remains disabled in my build
> and boot system.

I understand completely...

> Looking at the boot log, it just stops after uboot hands over control.
> With the lack of output from the decompressor, it's not possible to
> tell whether it's a decompressor problem or a kernel problem.
> 
> I think you need to turn on the LL_DEBUG option, select the appropriate
> output option, and also get the decompressor to use the kernel's debug
> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).

OK, will dig deeper here at the next opportunity.


- Paul


From daniel.lezcano at linaro.org  Mon Jul 22 16:13:17 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Jul 2013 22:13:17 +0200
Subject: [PATCH v4 04/20] clocksource: samsung_pwm_timer: Do not use
 clocksource_mmio
In-Reply-To: <19090469.Cf6sbb33Ke@flatron>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-6-git-send-email-tomasz.figa@gmail.com>
 <51ECAD60.1000109@linaro.org> <19090469.Cf6sbb33Ke@flatron>
Message-ID: <51ED925D.3060307@linaro.org>

On 07/22/2013 09:47 AM, Tomasz Figa wrote:
> Hi Daniel,
> 
> On Monday 22 of July 2013 05:56:16 Daniel Lezcano wrote:
>> On 07/20/2013 02:04 AM, Tomasz Figa wrote:
>>> In case of Samsung PWM timer, clocksource MMIO can not be used,
>>> because
>>> custom suspend/resume callbacks are required.
>>>
>>> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
>>> ---
>>
>> Reviewed-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> 
> Thanks for review.
> 
>> Please in the future Cc me and Thomas Gleixner (clocksource/clockevent
>> maintainers).
> 
> Oh, right, sorry. This series originally was not touching the clocksource 
> driver and I just kept original recipient list.
> 
> Btw. Have you updated MAINTAINERS file? In latest linux-next I can still 
> see only John Stultz and Thomas Gleixner as maintainers of 
> drivers/clocksource.

Yes, right last week :)

https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers/core&id=9222d247bcbaacc40fe15549158f9d67523c1ace

Thanks
  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From tomasz.figa at gmail.com  Mon Jul 22 16:17:23 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 22:17:23 +0200
Subject: [PATCH v4 04/20] clocksource: samsung_pwm_timer: Do not use
 clocksource_mmio
In-Reply-To: <51ED925D.3060307@linaro.org>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <19090469.Cf6sbb33Ke@flatron> <51ED925D.3060307@linaro.org>
Message-ID: <7854904.Q0hSxIdabT@flatron>

On Monday 22 of July 2013 22:13:17 Daniel Lezcano wrote:
> On 07/22/2013 09:47 AM, Tomasz Figa wrote:
> > Hi Daniel,
> > 
> > On Monday 22 of July 2013 05:56:16 Daniel Lezcano wrote:
> >> On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> >>> In case of Samsung PWM timer, clocksource MMIO can not be used,
> >>> because
> >>> custom suspend/resume callbacks are required.
> >>> 
> >>> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> >>> ---
> >> 
> >> Reviewed-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> > 
> > Thanks for review.
> > 
> >> Please in the future Cc me and Thomas Gleixner
> >> (clocksource/clockevent
> >> maintainers).
> > 
> > Oh, right, sorry. This series originally was not touching the
> > clocksource driver and I just kept original recipient list.
> > 
> > Btw. Have you updated MAINTAINERS file? In latest linux-next I can
> > still see only John Stultz and Thomas Gleixner as maintainers of
> > drivers/clocksource.
> 
> Yes, right last week :)
> 
> https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timer
> s/core&id=9222d247bcbaacc40fe15549158f9d67523c1ace

OK, great, just wanted to make sure. Apparently linux-next did not pick 
this up.

Best regards,
Tomasz



From ben.dooks at codethink.co.uk  Mon Jul 22 16:26:35 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Mon, 22 Jul 2013 21:26:35 +0100
Subject: [PATCH 4/4] ARM: set --be8 when linking modules
In-Reply-To: <alpine.LFD.2.03.1307221452210.15022@syhkavp.arg>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374510833-25716-5-git-send-email-ben.dooks@codethink.co.uk>
 <20130722170500.GC19639@codeaurora.org> <51ED69CA.3030501@codethink.co.uk>
 <alpine.LFD.2.03.1307221452210.15022@syhkavp.arg>
Message-ID: <51ED957B.80105@codethink.co.uk>

On 22/07/13 19:53, Nicolas Pitre wrote:
> On Mon, 22 Jul 2013, Ben Dooks wrote:
>
>> On 22/07/13 18:05, Stephen Boyd wrote:
>>> On 07/22, Ben Dooks wrote:
>>>> To avoid having to make every text section swap the instruction order
>>>> of all instructions, make sure modules are built also built with --be8
>>>> (as is the current kernel final link).
>>>>
>>>> If we do not do this, we would end up having to swap all instructions
>>>> when loading a module, instead of just the instructions that we are
>>>> applying ELF relocations to.
>>>>
>>>
>>> If someone tries to load a be8 module on a non-be8 kernel will it
>>> still work? Or should we add an extra version magic string in
>>> asm/module.h to prevent that?
>>
>> The ELF header changes the EI_DATA field in the ei_ident from
>> ELFDATA2LSB to ELFDATA2MSB when compiling so we should be able
>> to detect these when loading.
>>
>> I have not checked to see if the kernel correctly checks for this.
>>
>> I do not think it currently checks the ei_flags field for the
>> EF_ARM_BE8 in ABI 4 and 5. I am not sure if this is really important?
>
> If the information is already there and easily accessible, then it
> should be used.

I added this, which seems to actually work unlike my last effort.

I do not think it actually gets triggered, the ELF format contains
the endian-ness of the system it was built for and therefore fails
somewhere else.


diff --git a/arch/arm/kernel/elf.c b/arch/arm/kernel/elf.c
index d0d1e83..37c8e66 100644
--- a/arch/arm/kernel/elf.c
+++ b/arch/arm/kernel/elf.c
@@ -34,6 +34,17 @@ int elf_check_arch(const struct elf32_hdr *x)
                 if (flt_fmt == EF_ARM_VFP_FLOAT && !(elf_hwcap & 
HWCAP_VFP))
                         return 0;
         }
+
+       if ((eflags & EF_ARM_EABI_MASK) >= EF_ARM_EABI_VER4) {
+               bool is_be8 = IS_ENABLED(CONFIG_CPU_ENDIAN_BE8);
+
+               /* do some simple endian-ness verifications */
+               if (eflags & EF_ARM_BE8 && !is_be8)
+                       return 0;
+               if (eflags & EF_ARM_LE8 && is_be8)
+                       return 0;
+       }
+

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From festevam at gmail.com  Mon Jul 22 16:47:29 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 22 Jul 2013 17:47:29 -0300
Subject: [PATCH] ARM: dts: mxs: Add spi alias
Message-ID: <1374526049-29649-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

After providing spi alias, we can get the following message during probe:

m25p80 spi1.0: sst25vf016b (2048 Kbytes)

,which looks better than the original one:

m25p80 spi32766.0: sst25vf016b (2048 Kbytes)

While at it, keep the alias entries in alphabetical order.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/imx23.dtsi | 2 ++
 arch/arm/boot/dts/imx28.dtsi | 6 ++++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 1e528db..28b5ce2 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -20,6 +20,8 @@
 		gpio2 = &gpio2;
 		serial0 = &auart0;
 		serial1 = &auart1;
+		spi0 = &ssp0;
+		spi1 = &ssp1;
 	};
 
 	cpus {
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index db67eb6..89d98a1 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -15,6 +15,8 @@
 	interrupt-parent = <&icoll>;
 
 	aliases {
+		ethernet0 = &mac0;
+		ethernet1 = &mac1;
 		gpio0 = &gpio0;
 		gpio1 = &gpio1;
 		gpio2 = &gpio2;
@@ -22,13 +24,13 @@
 		gpio4 = &gpio4;
 		saif0 = &saif0;
 		saif1 = &saif1;
+		spi0 = &ssp1;
+		spi1 = &ssp2;
 		serial0 = &auart0;
 		serial1 = &auart1;
 		serial2 = &auart2;
 		serial3 = &auart3;
 		serial4 = &auart4;
-		ethernet0 = &mac0;
-		ethernet1 = &mac1;
 	};
 
 	cpus {
-- 
1.8.1.2



From john.stultz at linaro.org  Mon Jul 22 16:48:20 2013
From: john.stultz at linaro.org (John Stultz)
Date: Mon, 22 Jul 2013 13:48:20 -0700
Subject: [PATCH v4 03/17] sched_clock: Use an hrtimer instead of timer
In-Reply-To: <51ED80E7.4050606@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-4-git-send-email-sboyd@codeaurora.org>
 <51ED781F.6060300@linaro.org> <51ED7DD5.8010000@codeaurora.org>
 <51ED80E7.4050606@codeaurora.org>
Message-ID: <51ED9A94.3030204@linaro.org>

On 07/22/2013 11:58 AM, Stephen Boyd wrote:
> On 07/22/13 11:45, Stephen Boyd wrote:
>> On 07/22/13 11:21, John Stultz wrote:
>>> On 07/18/2013 04:21 PM, Stephen Boyd wrote:
>>>> In the next patch we're going to increase the number of bits that
>>>> the generic sched_clock can handle to be greater than 32. With
>>>> more than 32 bits the wraparound time can be larger than what can
>>>> fit into the units that msecs_to_jiffies takes (unsigned int).
>>>> Luckily, the wraparound is initially calculated in nanoseconds
>>>> which we can easily use with hrtimers, so switch to using an
>>>> hrtimer.
>>>>
>>>> Cc: Russell King <linux at arm.linux.org.uk>
>>>> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>>> Hrmm. So in my testing (under qemu), this patch causes bootup to hang.
>>>
>>> qemu-system-arm -kernel zImage-arm -M vexpress-a9 -cpu cortex-a9
>>> -nographic -m 1024  -append 'root=/dev/mmcblk0p2 rw mem=1024M
>>> raid=noautodetect console=ttyAMA0,38400n8 rootwait vmalloc=256MB
>>> devtmpfs.mount=0' -sd test-arm.img -redir tcp:4300::22
>>>
>>> Config file attached.
>>>
>>> I haven't gotten a chance to look very closely, but it seems the
>>> folowing patch resolves the issue. I'm not sure if we're seeing
>>> callers to setup_sched_clock happen after sched_clock_postinit or
>>> what, but it probably needs another look over.
>>>
>>> thanks
>>> -john
>>>
>>>
>>> diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
>>> index a269890b..c018ffc 100644
>>> --- a/kernel/time/sched_clock.c
>>> +++ b/kernel/time/sched_clock.c
>>> @@ -138,12 +138,6 @@ void __init setup_sched_clock(u32 (*read)(void),
>>> int bits, unsigned long rate)
>>>       pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns,
>>> wraps every %lluns\n",
>>>           bits, r, r_unit, res, wrap);
>>>   
>>> -    /*
>>> -     * Start the timer to keep sched_clock() properly updated and
>>> -     * sets the initial epoch.
>>> -     */
>>> -    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
>>> -    sched_clock_timer.function = sched_clock_poll;
>>>       update_sched_clock();
>>>   
>>>       /*
>>> @@ -175,6 +169,13 @@ void __init sched_clock_postinit(void)
>>>           setup_sched_clock(jiffy_sched_clock_read, 32, HZ);
>>>   
>>>       update_sched_clock();
>>> +
>>> +    /*
>>> +     * Start the timer to keep sched_clock() properly updated and
>>> +     * sets the initial epoch.
>>> +     */
>>> +    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
>>> +    sched_clock_timer.function = sched_clock_poll;
>>>       hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
>>>   }
>>>   
>>>
>> Hmm. Is it too early to use hrtimers? Moving the hrtimer_start() into
>> sched_clock_register() also causes the same crash.
> Yes that seems to be the problem. The vexpress board is setting up the
> sched_clock in setup_arch() (via v2m_init_early) which runs before
> hrtimers_init(). I've only tested this on boards that setup the timer in
> the time_init() callback which runs after hrtimers_init(). Your patch
> should be fine, although it would be nice if we didn't have callers
> setting up the sched_clock so early.

Although as Russell pointed out, setting up sched_clock later isn't 
really a good option (although I'd like it best if we could handle 
switching sched_clocks dynamically as needed so there were less 
constraints on when it has to be registered).

So I'll probably fold in my change into the patch if you're ok with that?

thanks
-john



From tomasz.figa at gmail.com  Mon Jul 22 16:50:40 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 22:50:40 +0200
Subject: [PATCH v5 13/20] pwm: Add new pwm-samsung driver
In-Reply-To: <1374278673-25615-15-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-15-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1478465.17AL5GbAI8@flatron>

This patch introduces new Samsung PWM driver, which uses Samsung
PWM/timer master driver to control shared parts of the hardware.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/pwm/Makefile      |   1 +
 drivers/pwm/pwm-samsung.c | 611 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 612 insertions(+)
 create mode 100644 drivers/pwm/pwm-samsung.c

Changes since v4:
 - made definition of TCON_AUTORELOAD macro more readable,
 - renamed s5p_variant to s5pc100_variant,
 - replaced overlooked pr_err() with dev_err().

diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index aa94807..86a5771 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_PWM_PUV3)		+= pwm-puv3.o
 obj-$(CONFIG_PWM_PXA)		+= pwm-pxa.o
 obj-$(CONFIG_PWM_RENESAS_TPU)	+= pwm-renesas-tpu.o
 obj-$(CONFIG_PWM_SAMSUNG)	+= pwm-samsung-legacy.o
+obj-$(CONFIG_PWM_SAMSUNG)	+= pwm-samsung.o
 obj-$(CONFIG_PWM_SPEAR)		+= pwm-spear.o
 obj-$(CONFIG_PWM_TEGRA)		+= pwm-tegra.o
 obj-$(CONFIG_PWM_TIECAP)	+= pwm-tiecap.o
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
new file mode 100644
index 0000000..9836a98
--- /dev/null
+++ b/drivers/pwm/pwm-samsung.c
@@ -0,0 +1,611 @@
+/*
+ * Copyright (c) 2007 Ben Dooks
+ * Copyright (c) 2008 Simtec Electronics
+ *     Ben Dooks <ben at simtec.co.uk>, <ben-linux at fluff.org>
+ * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
+ *
+ * PWM driver for Samsung SoCs
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/export.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/time.h>
+
+/* For struct samsung_timer_variant and samsung_pwm_lock. */
+#include <clocksource/samsung_pwm.h>
+
+#define REG_TCFG0			0x00
+#define REG_TCFG1			0x04
+#define REG_TCON			0x08
+
+#define REG_TCNTB(tmr)			(0x0c + ((tmr) * 0xc))
+#define REG_TCMPB(tmr)			(0x10 + ((tmr) * 0xc))
+
+#define TCFG0_PRESCALER_MASK		0xff
+#define TCFG0_PRESCALER1_SHIFT		8
+
+#define TCFG1_MUX_MASK			0xf
+#define TCFG1_SHIFT(x)			((x) * 4)
+
+#define TCON_START(chan)		(1 << (4 * (chan) + 0))
+#define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
+#define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
+#define _TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
+#define _TCON_AUTORELOAD4(chan)		(1 << (4 * (chan) + 2))
+/* Position of autoreload bit of channel 4 (5 in TCON reg.) is different. */
+#define TCON_AUTORELOAD(chan)		\
+	((chan < 5) ? _TCON_AUTORELOAD(chan) : _TCON_AUTORELOAD4(chan))
+
+/**
+ * struct samsung_pwm_channel - private data of PWM channel
+ * @period_ns:	current period in nanoseconds programmed to the hardware
+ * @duty_ns:	current duty time in nanoseconds programmed to the hardware
+ * @tin_ns:	time of one timer tick in nanoseconds with current timer rate
+ */
+struct samsung_pwm_channel {
+	u32 period_ns;
+	u32 duty_ns;
+	u32 tin_ns;
+};
+
+/**
+ * struct samsung_pwm_chip - private data of PWM chip
+ * @chip:		generic PWM chip
+ * @variant:		local copy of hardware variant data
+ * @inverter_mask:	inverter status for all channels - one bit per channel
+ * @base:		base address of mapped PWM registers
+ * @base_clk:		base clock used to drive the timers
+ * @tclk0:		external clock 0 (can be ERR_PTR if not present)
+ * @tclk1:		external clock 1 (can be ERR_PTR if not present)
+ */
+struct samsung_pwm_chip {
+	struct pwm_chip chip;
+	struct samsung_pwm_variant variant;
+	u8 inverter_mask;
+
+	void __iomem *base;
+	struct clk *base_clk;
+	struct clk *tclk0;
+	struct clk *tclk1;
+};
+
+#ifndef CONFIG_CLKSRC_SAMSUNG_PWM
+/*
+ * PWM block is shared between pwm-samsung and samsung_pwm_timer drivers
+ * and some registers need access synchronization. If both drivers are
+ * compiled in, the spinlock is defined in the clocksource driver,
+ * otherwise following definition is used.
+ *
+ * Currently we do not need any more complex synchronization method
+ * because all the supported SoCs contain only one instance of the PWM
+ * IP. Should this change, both drivers will need to be modified to
+ * properly synchronize accesses to particular instances.
+ */
+static DEFINE_SPINLOCK(samsung_pwm_lock);
+#endif
+
+static inline
+struct samsung_pwm_chip *to_samsung_pwm_chip(struct pwm_chip *chip)
+{
+	return container_of(chip, struct samsung_pwm_chip, chip);
+}
+
+static inline unsigned int to_tcon_channel(unsigned int channel)
+{
+	/* TCON register has a gap of 4 bits (1 channel) */
+	return (channel == 0) ? 0 : (channel + 1);
+}
+
+static void pwm_samsung_set_divisor(struct samsung_pwm_chip *pwm,
+				    unsigned int channel, u8 divisor)
+{
+	u8 shift = TCFG1_SHIFT(channel);
+	unsigned long flags;
+	u32 reg;
+	u8 bits;
+
+	bits = (fls(divisor) - 1) - pwm->variant.div_base;
+
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
+
+	reg = readl(pwm->base + REG_TCFG1);
+	reg &= ~(TCFG1_MUX_MASK << shift);
+	reg |= bits << shift;
+	writel(reg, pwm->base + REG_TCFG1);
+
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
+}
+
+static int pwm_samsung_is_tdiv(struct samsung_pwm_chip *chip, unsigned int chan)
+{
+	struct samsung_pwm_variant *variant = &chip->variant;
+	u32 reg;
+
+	reg = readl(chip->base + REG_TCFG1);
+	reg >>= TCFG1_SHIFT(chan);
+	reg &= TCFG1_MUX_MASK;
+
+	return (BIT(reg) & variant->tclk_mask) == 0;
+}
+
+static unsigned long pwm_samsung_get_tin_rate(struct samsung_pwm_chip *chip,
+					      unsigned int chan)
+{
+	unsigned long rate;
+	u32 reg;
+
+	rate = clk_get_rate(chip->base_clk);
+
+	reg = readl(chip->base + REG_TCFG0);
+	if (chan >= 2)
+		reg >>= TCFG0_PRESCALER1_SHIFT;
+	reg &= TCFG0_PRESCALER_MASK;
+
+	return rate / (reg + 1);
+}
+
+static unsigned long pwm_samsung_calc_tin(struct samsung_pwm_chip *chip,
+					  unsigned int chan, unsigned long freq)
+{
+	struct samsung_pwm_variant *variant = &chip->variant;
+	unsigned long rate;
+	struct clk *clk;
+	u8 div;
+
+	if (!pwm_samsung_is_tdiv(chip, chan)) {
+		clk = (chan < 2) ? chip->tclk0 : chip->tclk1;
+		if (!IS_ERR(clk)) {
+			rate = clk_get_rate(clk);
+			if (rate)
+				return rate;
+		}
+
+		dev_warn(chip->chip.dev,
+			"tclk of PWM %d is inoperational, using tdiv\n", chan);
+	}
+
+	rate = pwm_samsung_get_tin_rate(chip, chan);
+	dev_dbg(chip->chip.dev, "tin parent at %lu\n", rate);
+
+	/*
+	 * Compare minimum PWM frequency that can be achieved with possible
+	 * divider settings and choose the lowest divisor that can generate
+	 * frequencies lower than requested.
+	 */
+	for (div = variant->div_base; div < 4; ++div)
+		if ((rate >> (variant->bits + div)) < freq)
+			break;
+
+	pwm_samsung_set_divisor(chip, chan, BIT(div));
+
+	return rate >> div;
+}
+
+static int pwm_samsung_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	struct samsung_pwm_channel *our_chan;
+
+	if (!(our_chip->variant.output_mask & BIT(pwm->hwpwm))) {
+		dev_warn(chip->dev,
+			"tried to request PWM channel %d without output\n",
+			pwm->hwpwm);
+		return -EINVAL;
+	}
+
+	our_chan = devm_kzalloc(chip->dev, sizeof(*our_chan), GFP_KERNEL);
+	if (!our_chan)
+		return -ENOMEM;
+
+	pwm_set_chip_data(pwm, our_chan);
+
+	return 0;
+}
+
+static void pwm_samsung_free(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	pwm_set_chip_data(pwm, NULL);
+	devm_kfree(chip->dev, pwm_get_chip_data(pwm));
+}
+
+static int pwm_samsung_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	unsigned int tcon_chan = to_tcon_channel(pwm->hwpwm);
+	unsigned long flags;
+	u32 tcon;
+
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
+
+	tcon = readl(our_chip->base + REG_TCON);
+
+	tcon &= ~TCON_START(tcon_chan);
+	tcon |= TCON_MANUALUPDATE(tcon_chan);
+	writel(tcon, our_chip->base + REG_TCON);
+
+	tcon &= ~TCON_MANUALUPDATE(tcon_chan);
+	tcon |= TCON_START(tcon_chan) | TCON_AUTORELOAD(tcon_chan);
+	writel(tcon, our_chip->base + REG_TCON);
+
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
+
+	return 0;
+}
+
+static void pwm_samsung_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	unsigned int tcon_chan = to_tcon_channel(pwm->hwpwm);
+	unsigned long flags;
+	u32 tcon;
+
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
+
+	tcon = readl(our_chip->base + REG_TCON);
+	tcon &= ~TCON_AUTORELOAD(tcon_chan);
+	writel(tcon, our_chip->base + REG_TCON);
+
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
+}
+
+static int pwm_samsung_config(struct pwm_chip *chip, struct pwm_device *pwm,
+			      int duty_ns, int period_ns)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	struct samsung_pwm_channel *chan = pwm_get_chip_data(pwm);
+	u32 tin_ns = chan->tin_ns, tcnt, tcmp;
+
+	/*
+	 * We currently avoid using 64bit arithmetic by using the
+	 * fact that anything faster than 1Hz is easily representable
+	 * by 32bits.
+	 */
+	if (period_ns > NSEC_PER_SEC)
+		return -ERANGE;
+
+	if (period_ns == chan->period_ns && duty_ns == chan->duty_ns)
+		return 0;
+
+	tcnt = readl(our_chip->base + REG_TCNTB(pwm->hwpwm));
+
+	/* We need tick count for calculation, not last tick. */
+	++tcnt;
+
+	/* Check to see if we are changing the clock rate of the PWM. */
+	if (chan->period_ns != period_ns) {
+		unsigned long tin_rate;
+		u32 period;
+
+		period = NSEC_PER_SEC / period_ns;
+
+		dev_dbg(our_chip->chip.dev, "duty_ns=%d, period_ns=%d (%u)\n",
+						duty_ns, period_ns, period);
+
+		tin_rate = pwm_samsung_calc_tin(our_chip, pwm->hwpwm, period);
+
+		dev_dbg(our_chip->chip.dev, "tin_rate=%lu\n", tin_rate);
+
+		tin_ns = NSEC_PER_SEC / tin_rate;
+		tcnt = period_ns / tin_ns;
+	}
+
+	/* Period is too short. */
+	if (tcnt <= 1)
+		return -ERANGE;
+
+	/* Note that counters count down. */
+	tcmp = duty_ns / tin_ns;
+
+	/* 0% duty is not available */
+	if (!tcmp)
+		++tcmp;
+
+	tcmp = tcnt - tcmp;
+
+	/* Decrement to get tick numbers, instead of tick counts. */
+	--tcnt;
+	/* -1UL will give 100% duty. */
+	--tcmp;
+
+	dev_dbg(our_chip->chip.dev,
+				"tin_ns=%u, tcmp=%u/%u\n", tin_ns, tcmp, tcnt);
+
+	/* Update PWM registers. */
+	writel(tcnt, our_chip->base + REG_TCNTB(pwm->hwpwm));
+	writel(tcmp, our_chip->base + REG_TCMPB(pwm->hwpwm));
+
+	if (test_bit(PWMF_ENABLED, &pwm->flags))
+		pwm_samsung_enable(chip, pwm);
+
+	chan->period_ns = period_ns;
+	chan->tin_ns = tin_ns;
+	chan->duty_ns = duty_ns;
+
+	return 0;
+}
+
+static void pwm_samsung_set_invert(struct samsung_pwm_chip *chip,
+				   unsigned int channel, bool invert)
+{
+	unsigned int tcon_chan = to_tcon_channel(channel);
+	unsigned long flags;
+	u32 tcon;
+
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
+
+	tcon = readl(chip->base + REG_TCON);
+
+	if (invert) {
+		chip->inverter_mask |= BIT(channel);
+		tcon |= TCON_INVERT(tcon_chan);
+	} else {
+		chip->inverter_mask &= ~BIT(channel);
+		tcon &= ~TCON_INVERT(tcon_chan);
+	}
+
+	writel(tcon, chip->base + REG_TCON);
+
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
+}
+
+static int pwm_samsung_set_polarity(struct pwm_chip *chip,
+				    struct pwm_device *pwm,
+				    enum pwm_polarity polarity)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	bool invert = (polarity == PWM_POLARITY_NORMAL);
+
+	/* Inverted means normal in the hardware. */
+	pwm_samsung_set_invert(our_chip, pwm->hwpwm, invert);
+
+	return 0;
+}
+
+static const struct pwm_ops pwm_samsung_ops = {
+	.request	= pwm_samsung_request,
+	.free		= pwm_samsung_free,
+	.enable		= pwm_samsung_enable,
+	.disable	= pwm_samsung_disable,
+	.config		= pwm_samsung_config,
+	.set_polarity	= pwm_samsung_set_polarity,
+	.owner		= THIS_MODULE,
+};
+
+#ifdef CONFIG_OF
+static const struct samsung_pwm_variant s3c24xx_variant = {
+	.bits		= 16,
+	.div_base	= 1,
+	.has_tint_cstat	= false,
+	.tclk_mask	= BIT(4),
+};
+
+static const struct samsung_pwm_variant s3c64xx_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= BIT(7) | BIT(6) | BIT(5),
+};
+
+static const struct samsung_pwm_variant s5p64x0_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= 0,
+};
+
+static const struct samsung_pwm_variant s5pc100_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= BIT(5),
+};
+
+static const struct of_device_id samsung_pwm_matches[] = {
+	{ .compatible = "samsung,s3c2410-pwm", .data = &s3c24xx_variant },
+	{ .compatible = "samsung,s3c6400-pwm", .data = &s3c64xx_variant },
+	{ .compatible = "samsung,s5p6440-pwm", .data = &s5p64x0_variant },
+	{ .compatible = "samsung,s5pc100-pwm", .data = &s5pc100_variant },
+	{ .compatible = "samsung,exynos4210-pwm", .data = &s5p64x0_variant },
+	{},
+};
+
+static int pwm_samsung_parse_dt(struct samsung_pwm_chip *chip)
+{
+	struct device_node *np = chip->chip.dev->of_node;
+	const struct of_device_id *match;
+	struct property *prop;
+	const __be32 *cur;
+	u32 val;
+
+	match = of_match_node(samsung_pwm_matches, np);
+	if (!match)
+		return -ENODEV;
+
+	memcpy(&chip->variant, match->data, sizeof(chip->variant));
+
+	of_property_for_each_u32(np, "samsung,pwm-outputs", prop, cur, val) {
+		if (val >= SAMSUNG_PWM_NUM) {
+			dev_err(chip->chip.dev,
+				"%s: invalid channel index in samsung,pwm-outputs property\n",
+								__func__);
+			continue;
+		}
+		chip->variant.output_mask |= BIT(val);
+	}
+
+	return 0;
+}
+#else
+static int pwm_samsung_parse_dt(struct samsung_pwm_chip *chip)
+{
+	return -ENODEV;
+}
+#endif
+
+static int pwm_samsung_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct samsung_pwm_chip *chip;
+	struct resource *res;
+	unsigned int chan;
+	int ret;
+
+	chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
+	if (chip == NULL)
+		return -ENOMEM;
+
+	chip->chip.dev = &pdev->dev;
+	chip->chip.ops = &pwm_samsung_ops;
+	chip->chip.base = -1;
+	chip->chip.npwm = SAMSUNG_PWM_NUM;
+	chip->inverter_mask = BIT(SAMSUNG_PWM_NUM) - 1;
+
+	if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node) {
+		ret = pwm_samsung_parse_dt(chip);
+		if (ret)
+			return ret;
+
+		chip->chip.of_xlate = of_pwm_xlate_with_flags;
+		chip->chip.of_pwm_n_cells = 3;
+	} else {
+		if (!pdev->dev.platform_data) {
+			dev_err(&pdev->dev, "no platform data specified\n");
+			return -EINVAL;
+		}
+
+		memcpy(&chip->variant, pdev->dev.platform_data,
+							sizeof(chip->variant));
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	chip->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(chip->base))
+		return PTR_ERR(chip->base);
+
+	chip->base_clk = devm_clk_get(&pdev->dev, "timers");
+	if (IS_ERR(chip->base_clk)) {
+		dev_err(dev, "failed to get timer base clk\n");
+		return PTR_ERR(chip->base_clk);
+	}
+
+	ret = clk_prepare_enable(chip->base_clk);
+	if (ret < 0) {
+		dev_err(dev, "failed to enable base clock\n");
+		return ret;
+	}
+
+	for (chan = 0; chan < SAMSUNG_PWM_NUM; ++chan)
+		if (chip->variant.output_mask & BIT(chan))
+			pwm_samsung_set_invert(chip, chan, true);
+
+	/* Following clocks are optional. */
+	chip->tclk0 = devm_clk_get(&pdev->dev, "pwm-tclk0");
+	chip->tclk1 = devm_clk_get(&pdev->dev, "pwm-tclk1");
+
+	platform_set_drvdata(pdev, chip);
+
+	ret = pwmchip_add(&chip->chip);
+	if (ret < 0) {
+		dev_err(dev, "failed to register PWM chip\n");
+		clk_disable_unprepare(chip->base_clk);
+		return ret;
+	}
+
+	dev_dbg(dev, "base_clk at %lu, tclk0 at %lu, tclk1 at %lu\n",
+		clk_get_rate(chip->base_clk),
+		!IS_ERR(chip->tclk0) ? clk_get_rate(chip->tclk0) : 0,
+		!IS_ERR(chip->tclk1) ? clk_get_rate(chip->tclk1) : 0);
+
+	return 0;
+}
+
+static int pwm_samsung_remove(struct platform_device *pdev)
+{
+	struct samsung_pwm_chip *chip = platform_get_drvdata(pdev);
+	int ret;
+
+	ret = pwmchip_remove(&chip->chip);
+	if (ret < 0)
+		return ret;
+
+	clk_disable_unprepare(chip->base_clk);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int pwm_samsung_suspend(struct device *dev)
+{
+	struct samsung_pwm_chip *chip = dev_get_drvdata(dev);
+	unsigned int i;
+
+	/*
+	 * No one preserves these values during suspend so reset them.
+	 * Otherwise driver leaves PWM unconfigured if same values are
+	 * passed to pwm_config() next time.
+	 */
+	for (i = 0; i < SAMSUNG_PWM_NUM; ++i) {
+		struct pwm_device *pwm = &chip->chip.pwms[i];
+		struct samsung_pwm_channel *chan = pwm_get_chip_data(pwm);
+
+		if (!chan)
+			continue;
+
+		chan->period_ns = 0;
+		chan->duty_ns = 0;
+	}
+
+	return 0;
+}
+
+static int pwm_samsung_resume(struct device *dev)
+{
+	struct samsung_pwm_chip *chip = dev_get_drvdata(dev);
+	unsigned int chan;
+
+	/*
+	 * Inverter setting must be preserved across suspend/resume
+	 * as nobody really seems to configure it more than once.
+	 */
+	for (chan = 0; chan < SAMSUNG_PWM_NUM; ++chan) {
+		if (chip->variant.output_mask & BIT(chan))
+			pwm_samsung_set_invert(chip, chan,
+					chip->inverter_mask & BIT(chan));
+	}
+
+	return 0;
+}
+#endif
+
+static const struct dev_pm_ops pwm_samsung_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pwm_samsung_suspend, pwm_samsung_resume)
+};
+
+static struct platform_driver pwm_samsung_driver = {
+	.driver		= {
+		.name	= "samsung-pwm",
+		.owner	= THIS_MODULE,
+		.pm	= &pwm_samsung_pm_ops,
+		.of_match_table = of_match_ptr(samsung_pwm_matches),
+	},
+	.probe		= pwm_samsung_probe,
+	.remove		= pwm_samsung_remove,
+};
+module_platform_driver(pwm_samsung_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Tomasz Figa <tomasz.figa at gmail.com>");
+MODULE_ALIAS("platform:samsung-pwm");
-- 
1.8.3.2




From sboyd at codeaurora.org  Mon Jul 22 16:50:54 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 22 Jul 2013 13:50:54 -0700
Subject: [PATCH v4 03/17] sched_clock: Use an hrtimer instead of timer
In-Reply-To: <51ED9A94.3030204@linaro.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-4-git-send-email-sboyd@codeaurora.org>
 <51ED781F.6060300@linaro.org> <51ED7DD5.8010000@codeaurora.org>
 <51ED80E7.4050606@codeaurora.org> <51ED9A94.3030204@linaro.org>
Message-ID: <51ED9B2E.2030502@codeaurora.org>

On 07/22/13 13:48, John Stultz wrote:
> On 07/22/2013 11:58 AM, Stephen Boyd wrote:
>> On 07/22/13 11:45, Stephen Boyd wrote:
>>> On 07/22/13 11:21, John Stultz wrote:
>>>> On 07/18/2013 04:21 PM, Stephen Boyd wrote:
>>>>> In the next patch we're going to increase the number of bits that
>>>>> the generic sched_clock can handle to be greater than 32. With
>>>>> more than 32 bits the wraparound time can be larger than what can
>>>>> fit into the units that msecs_to_jiffies takes (unsigned int).
>>>>> Luckily, the wraparound is initially calculated in nanoseconds
>>>>> which we can easily use with hrtimers, so switch to using an
>>>>> hrtimer.
>>>>>
>>>>> Cc: Russell King <linux at arm.linux.org.uk>
>>>>> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>>>> Hrmm. So in my testing (under qemu), this patch causes bootup to hang.
>>>>
>>>> qemu-system-arm -kernel zImage-arm -M vexpress-a9 -cpu cortex-a9
>>>> -nographic -m 1024  -append 'root=/dev/mmcblk0p2 rw mem=1024M
>>>> raid=noautodetect console=ttyAMA0,38400n8 rootwait vmalloc=256MB
>>>> devtmpfs.mount=0' -sd test-arm.img -redir tcp:4300::22
>>>>
>>>> Config file attached.
>>>>
>>>> I haven't gotten a chance to look very closely, but it seems the
>>>> folowing patch resolves the issue. I'm not sure if we're seeing
>>>> callers to setup_sched_clock happen after sched_clock_postinit or
>>>> what, but it probably needs another look over.
>>>>
>>>> thanks
>>>> -john
>>>>
>>>>
>>>> diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
>>>> index a269890b..c018ffc 100644
>>>> --- a/kernel/time/sched_clock.c
>>>> +++ b/kernel/time/sched_clock.c
>>>> @@ -138,12 +138,6 @@ void __init setup_sched_clock(u32 (*read)(void),
>>>> int bits, unsigned long rate)
>>>>       pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns,
>>>> wraps every %lluns\n",
>>>>           bits, r, r_unit, res, wrap);
>>>>   -    /*
>>>> -     * Start the timer to keep sched_clock() properly updated and
>>>> -     * sets the initial epoch.
>>>> -     */
>>>> -    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC,
>>>> HRTIMER_MODE_REL);
>>>> -    sched_clock_timer.function = sched_clock_poll;
>>>>       update_sched_clock();
>>>>         /*
>>>> @@ -175,6 +169,13 @@ void __init sched_clock_postinit(void)
>>>>           setup_sched_clock(jiffy_sched_clock_read, 32, HZ);
>>>>         update_sched_clock();
>>>> +
>>>> +    /*
>>>> +     * Start the timer to keep sched_clock() properly updated and
>>>> +     * sets the initial epoch.
>>>> +     */
>>>> +    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC,
>>>> HRTIMER_MODE_REL);
>>>> +    sched_clock_timer.function = sched_clock_poll;
>>>>       hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
>>>>   }
>>>>  
>>> Hmm. Is it too early to use hrtimers? Moving the hrtimer_start() into
>>> sched_clock_register() also causes the same crash.
>> Yes that seems to be the problem. The vexpress board is setting up the
>> sched_clock in setup_arch() (via v2m_init_early) which runs before
>> hrtimers_init(). I've only tested this on boards that setup the timer in
>> the time_init() callback which runs after hrtimers_init(). Your patch
>> should be fine, although it would be nice if we didn't have callers
>> setting up the sched_clock so early.
>
> Although as Russell pointed out, setting up sched_clock later isn't
> really a good option (although I'd like it best if we could handle
> switching sched_clocks dynamically as needed so there were less
> constraints on when it has to be registered).
>
> So I'll probably fold in my change into the patch if you're ok with that?
>

Yes that's fine to fold it in.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From tomasz.figa at gmail.com  Mon Jul 22 16:52:51 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 22:52:51 +0200
Subject: [PATCH v5 07/20] ARM: SAMSUNG: Add new PWM platform device
In-Reply-To: <1374278673-25615-9-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-9-git-send-email-tomasz.figa@gmail.com>
Message-ID: <2424688.n7D1SHrQ2V@flatron>

This patch adds new samsung_device_pwm platform device that represents
the whole PWM/timer block and includes memory and IRQ resources.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/plat-samsung/devs.c                  | 17 +++++++++++++++++
 arch/arm/plat-samsung/include/plat/devs.h     |  1 +
 arch/arm/plat-samsung/include/plat/pwm-core.h | 22 ++++++++++++++++++++++
 3 files changed, 40 insertions(+)
 create mode 100644 arch/arm/plat-samsung/include/plat/pwm-core.h

Changes since v4:
 - cleaned up header of pwm-core.h file.

diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 0f9c3f4..bba6d78 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -58,6 +58,7 @@
 #include <plat/keypad.h>
 #include <linux/platform_data/mmc-s3cmci.h>
 #include <linux/platform_data/mtd-nand-s3c2410.h>
+#include <plat/pwm-core.h>
 #include <plat/sdhci.h>
 #include <linux/platform_data/touchscreen-s3c2410.h>
 #include <linux/platform_data/usb-s3c2410_udc.h>
@@ -1127,6 +1128,22 @@ struct platform_device s3c_device_timer[] = {
 	[3] = { DEFINE_S3C_TIMER(3, IRQ_TIMER3) },
 	[4] = { DEFINE_S3C_TIMER(4, IRQ_TIMER4) },
 };
+
+static struct resource samsung_pwm_resource[] = {
+	DEFINE_RES_MEM(SAMSUNG_PA_TIMER, SZ_4K),
+};
+
+struct platform_device samsung_device_pwm = {
+	.name		= "samsung-pwm",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(samsung_pwm_resource),
+	.resource	= samsung_pwm_resource,
+};
+
+void __init samsung_pwm_set_platdata(struct samsung_pwm_variant *pd)
+{
+	samsung_device_pwm.dev.platform_data = pd;
+}
 #endif /* CONFIG_SAMSUNG_DEV_PWM */
 
 /* RTC */
diff --git a/arch/arm/plat-samsung/include/plat/devs.h b/arch/arm/plat-samsung/include/plat/devs.h
index 87d501f..0dc4ac4 100644
--- a/arch/arm/plat-samsung/include/plat/devs.h
+++ b/arch/arm/plat-samsung/include/plat/devs.h
@@ -134,6 +134,7 @@ extern struct platform_device exynos4_device_spdif;
 
 extern struct platform_device samsung_asoc_idma;
 extern struct platform_device samsung_device_keypad;
+extern struct platform_device samsung_device_pwm;
 
 /* s3c2440 specific devices */
 
diff --git a/arch/arm/plat-samsung/include/plat/pwm-core.h b/arch/arm/plat-samsung/include/plat/pwm-core.h
new file mode 100644
index 0000000..77269a7
--- /dev/null
+++ b/arch/arm/plat-samsung/include/plat/pwm-core.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2013 Tomasz Figa <tomasz.figa at gmail.com>
+ *
+ * Samsung PWM controller platform data helpers.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_ARCH_PWM_CORE_H
+#define __ASM_ARCH_PWM_CORE_H __FILE__
+
+#include <clocksource/samsung_pwm.h>
+
+#ifdef CONFIG_SAMSUNG_DEV_PWM
+extern void samsung_pwm_set_platdata(struct samsung_pwm_variant *pd);
+#else
+static inline void samsung_pwm_set_platdata(struct samsung_pwm_variant *pd) { }
+#endif
+
+#endif /* __ASM_ARCH_PWM_CORE_H */
-- 
1.8.3.2




From tomasz.figa at gmail.com  Mon Jul 22 16:54:33 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 22:54:33 +0200
Subject: [PATCH v5 02/20] clocksource: samsung_pwm_timer: Correct definition
 of AUTORELOAD bit
In-Reply-To: <1374278673-25615-4-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-4-git-send-email-tomasz.figa@gmail.com>
Message-ID: <3872385.JQ2jXzack4@flatron>

PWM channel 4 has its autoreload bit located at different position. This
patch fixes the driver to account for that.

This fixes a problem with the clocksource hanging after it overflows because
it is not reloaded any more.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/clocksource/samsung_pwm_timer.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Changes since v4:
 - made the new definition more readable.

diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index 3fa5b07..89947c3 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -47,7 +47,11 @@
 #define TCON_START(chan)		(1 << (4 * (chan) + 0))
 #define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
 #define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
-#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
+#define _TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
+#define _TCON_AUTORELOAD4(chan)		(1 << (4 * (chan) + 2))
+/* Position of autoreload bit of channel 4 (5 in TCON reg.) is different. */
+#define TCON_AUTORELOAD(chan)		\
+	((chan < 5) ? _TCON_AUTORELOAD(chan) : _TCON_AUTORELOAD4(chan))
 
 DEFINE_SPINLOCK(samsung_pwm_lock);
 EXPORT_SYMBOL(samsung_pwm_lock);
-- 
1.8.3.2




From linus.walleij at linaro.org  Mon Jul 22 16:54:41 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Jul 2013 22:54:41 +0200
Subject: [PATCH 0/4] pinctrl single support for SoC specific features
In-Reply-To: <20130710122417.GT5523@atomide.com>
References: <20130607203936.16513.57494.stgit@localhost>
 <51DD4F30.7050603@ti.com> <20130710122417.GT5523@atomide.com>
Message-ID: <CACRpkdYGHy0jZ0TD8NejiT6TaR3txmXHKgvS=JXBV1-74jZeGw@mail.gmail.com>

On Wed, Jul 10, 2013 at 2:24 PM, Tony Lindgren <tony at atomide.com> wrote:

> How about I'll push an immutable branch against v3.11-rc1 when it's
> tagged and send a pull request to Linus W for the first three patches?
>
> That way we can base other branches on this if needed.
>
> Linus, does that sound OK to you?

OK but I still need to look closer at them as well, so no guarantee
I will pull it...

Yours,
Linus Walleij


From daniel.lezcano at linaro.org  Mon Jul 22 16:56:44 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Jul 2013 22:56:44 +0200
Subject: [PATCH v4 02/20] clocksource: samsung_pwm_timer: Correct
 definition of AUTORELOAD bit
In-Reply-To: <9612221.r4mx9bHE64@flatron>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-4-git-send-email-tomasz.figa@gmail.com>
 <51ECABF1.4040600@linaro.org> <9612221.r4mx9bHE64@flatron>
Message-ID: <51ED9C8C.10803@linaro.org>

On 07/22/2013 09:43 AM, Tomasz Figa wrote:
> On Monday 22 of July 2013 05:50:09 Daniel Lezcano wrote:
>> On 07/20/2013 02:04 AM, Tomasz Figa wrote:
>>> PWM channel 4 has its autoreload bit located at different position.
>>> This patch fixes the driver to account for that.
>>>
>>> This fixes a problem with the clocksource hanging after it overflows
>>> because it is not reloaded any more.
>>>
>>> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
>>> ---
>>>
>>>  drivers/clocksource/samsung_pwm_timer.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clocksource/samsung_pwm_timer.c
>>> b/drivers/clocksource/samsung_pwm_timer.c index 3fa5b07..e238fb0
>>> 100644
>>> --- a/drivers/clocksource/samsung_pwm_timer.c
>>> +++ b/drivers/clocksource/samsung_pwm_timer.c
>>> @@ -47,7 +47,8 @@
>>>
>>>  #define TCON_START(chan)		(1 << (4 * (chan) + 0))
>>>  #define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
>>>  #define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
>>>
>>> -#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
>>> +#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) \
>>> +						+ (((chan) < 5) ? 3 : 2)))
>>
>> This macro is not readable. Please, fix it up with a comment please.
> 
> /*
>  * Channel 4 (logically 5 in TCON register) has different position
>  * of autoreload bit.
>  */
> #define _TCON_AUTORELOAD(chan)			(1 << (4 * (chan) + 3))
> #define _TCON_AUTORELOAD4(chan)			(1 << (4 * (chan) + 2))
> #define TCON_AUTORELOAD(chan)			((chan < 5) ? 
> 		_TCON_AUTORELOAD(chan) : _TCON_AUTORELOAD4(chan))
> 
> What do you think?

I don't get the arithmetic here and the code is poor in comment. A nice
comment would valuable here.

May be you can replace 1 << bla by BIT(bla) ?


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From festevam at gmail.com  Mon Jul 22 16:57:01 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 22 Jul 2013 17:57:01 -0300
Subject: [PATCH v2] ARM: dts: mxs: Add spi alias
Message-ID: <1374526621-29874-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

After providing spi alias, we can get the following message during probe:

m25p80 spi1.0: sst25vf016b (2048 Kbytes)

,which looks better than the original one:

m25p80 spi32766.0: sst25vf016b (2048 Kbytes)

While at it, keep the alias entries in alphabetical order.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- Fix the alphabetical order 

 arch/arm/boot/dts/imx23.dtsi | 2 ++
 arch/arm/boot/dts/imx28.dtsi | 6 ++++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 1e528db..28b5ce2 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -20,6 +20,8 @@
 		gpio2 = &gpio2;
 		serial0 = &auart0;
 		serial1 = &auart1;
+		spi0 = &ssp0;
+		spi1 = &ssp1;
 	};
 
 	cpus {
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index db67eb6..47fc5ef 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -15,6 +15,8 @@
 	interrupt-parent = <&icoll>;
 
 	aliases {
+		ethernet0 = &mac0;
+		ethernet1 = &mac1;
 		gpio0 = &gpio0;
 		gpio1 = &gpio1;
 		gpio2 = &gpio2;
@@ -27,8 +29,8 @@
 		serial2 = &auart2;
 		serial3 = &auart3;
 		serial4 = &auart4;
-		ethernet0 = &mac0;
-		ethernet1 = &mac1;
+		spi0 = &ssp1;
+		spi1 = &ssp2;
 	};
 
 	cpus {
-- 
1.8.1.2



From linus.walleij at linaro.org  Mon Jul 22 17:00:07 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Jul 2013 23:00:07 +0200
Subject: [RFC] ARM: OMAP2+: omap_device: add pinctrl handling
In-Reply-To: <51E0227E.2000008@ti.com>
References: <1371826990-25820-1-git-send-email-grygorii.strashko@ti.com>
 <CACRpkdY=m1b9Lh27+wHP8FQ4SbVZKmAOCGhxe59aP+TcuR9QaA@mail.gmail.com>
 <20130625065811.GZ5523@atomide.com> <51CAEA90.90200@ti.com>
 <CACRpkdbKgEcfF67oO9HrczvDp4Po3Xt1hFajJ1vO8kEvsZH4jA@mail.gmail.com>
 <51CC45D3.2000305@ti.com>
 <CACRpkdYU13bhPaL2ZG9CT9JRv9sKQ+1N3zCUPizk571+LQqB4A@mail.gmail.com>
 <51E0227E.2000008@ti.com>
Message-ID: <CACRpkdYrXcYvXO=vJ1RxLkv4ou_08M3tS_gffDnwqEtod-68Ow@mail.gmail.com>

On Fri, Jul 12, 2013 at 5:36 PM, Grygorii Strashko
<grygorii.strashko at ti.com> wrote:
> On 07/10/2013 11:36 PM, Linus Walleij wrote:
>>
>> I guess we need a patch set prepared which adds the "active" state
>> and helper function as the first patch, i.e. this:
>> http://marc.info/?l=linux-kernel&m=137094012703340&w=2
>> Can I have your ACK on this patch?
>
> I've verified combination of
> [PATCH] drivers: pinctrl: add active state to core
> [RFC] ARM: OMAP2+: omap_device: add pinctrl handling
> on OMAP4 SDP board+UARTs and going to send patches on Monday.
>
> So, Acked/Tested-by: Grygorii Strashko <grygorii.strashko at ti.com>
> (I can't reply directly to thread - not signed to those lists :))
>
> What is the best branch to base my patches on?

I suggest you coordinate that with Tony. He can take my patch
with your ACK if it helps, but it seems he's already up to
optimizing the pinctrl core :-)

Yours,
Linus Walleij


From linus.walleij at linaro.org  Mon Jul 22 17:06:12 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Jul 2013 23:06:12 +0200
Subject: [GIT PULL] pinctrl-single SoC specific support for v3.12
In-Reply-To: <20130716091816.GU7656@atomide.com>
References: <20130716091816.GU7656@atomide.com>
Message-ID: <CACRpkdY2DRgDwmypYJv2WaBS1oH=mMhDLh69W4jeGyKvErvzqg@mail.gmail.com>

On Tue, Jul 16, 2013 at 11:18 AM, Tony Lindgren <tony at atomide.com> wrote:

> Here's a pull request for the pinctrl-single changes posted
> few weeks ago. Assuming this pull request and the patches
> are OK, I'd like to also merge this branch into omap tree so
> we can have the wake-up events working. So we'd have to
> establish keeping these commits immutable.

I see some issues with these patches ...

I will go back and review them.

Yours,
Linus Walleij


From tomasz.figa at gmail.com  Mon Jul 22 17:11:30 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 22 Jul 2013 23:11:30 +0200
Subject: [PATCH v4 02/20] clocksource: samsung_pwm_timer: Correct
 definition of AUTORELOAD bit
In-Reply-To: <51ED9C8C.10803@linaro.org>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <9612221.r4mx9bHE64@flatron> <51ED9C8C.10803@linaro.org>
Message-ID: <1658534.7nG6RFjcTc@flatron>

On Monday 22 of July 2013 22:56:44 Daniel Lezcano wrote:
> On 07/22/2013 09:43 AM, Tomasz Figa wrote:
> > On Monday 22 of July 2013 05:50:09 Daniel Lezcano wrote:
> >> On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> >>> PWM channel 4 has its autoreload bit located at different position.
> >>> This patch fixes the driver to account for that.
> >>> 
> >>> This fixes a problem with the clocksource hanging after it overflows
> >>> because it is not reloaded any more.
> >>> 
> >>> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> >>> ---
> >>> 
> >>>  drivers/clocksource/samsung_pwm_timer.c | 3 ++-
> >>>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/drivers/clocksource/samsung_pwm_timer.c
> >>> b/drivers/clocksource/samsung_pwm_timer.c index 3fa5b07..e238fb0
> >>> 100644
> >>> --- a/drivers/clocksource/samsung_pwm_timer.c
> >>> +++ b/drivers/clocksource/samsung_pwm_timer.c
> >>> @@ -47,7 +47,8 @@
> >>> 
> >>>  #define TCON_START(chan)		(1 << (4 * (chan) + 0))
> >>>  #define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
> >>>  #define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
> >>> 
> >>> -#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
> >>> +#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) \
> >>> +						+ (((chan) < 5) ? 3 : 2)))
> >> 
> >> This macro is not readable. Please, fix it up with a comment please.
> > 
> > /*
> > 
> >  * Channel 4 (logically 5 in TCON register) has different position
> >  * of autoreload bit.
> >  */
> > 
> > #define _TCON_AUTORELOAD(chan)			(1 << (4 * (chan) 
+ 3))
> > #define _TCON_AUTORELOAD4(chan)			(1 << (4 * (chan) 
+ 2))
> > #define TCON_AUTORELOAD(chan)			((chan < 5) ?
> > 
> > 		_TCON_AUTORELOAD(chan) : _TCON_AUTORELOAD4(chan))
> > 
> > What do you think?
> 
> I don't get the arithmetic here and the code is poor in comment. A nice
> comment would valuable here.

Each channel occupies 4 bits in TCON register, but there is a gap of 4 
bits after channel 0. In addition for channel 4 the location of autoreload 
bit in its set of bits is 2 as opposed to 3 for other channels. Here's the 
layout of the register, for reference:

Timer 4 Auto Reload on/off	[22]
Timer 4 Manual Update		[21]
Timer 4 Start/Stop		[20]

Timer 3 Auto Reload on/off	[19]
Reserved			[18]
Timer 3 Manual Update		[17]
Timer 3 Start/Stop		[16]

Timer 2 Auto Reload on/off	[15]
Reserved			[14]
Timer 2 Manual Update		[13]
Timer 2 Start/Stop		[12]

Timer 1 Auto Reload on/off	[11]
Timer 1 Output Inverter on/off	[10]
Timer 1 Manual Update		[9]
Timer 1 Start/Stop		[8]

Reserved			[7:5]
Dead zone enable/disable	[4]

Timer 0 Auto Reload on/off	[3]
Timer 0 Output Inverter on/off	[2]
Timer 0 Manual Update		[1]
Timer 0 Start/Stop		[0]

> May be you can replace 1 << bla by BIT(bla) ?

Yes, BIT() would be nice here, but IMHO this is material for separate 
patch as all the macros in this driver already use 1 << bla.

Best regards,
Tomasz



From cavokz at gmail.com  Mon Jul 22 17:14:35 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Mon, 22 Jul 2013 23:14:35 +0200
Subject: [PATCH 5/5] ARM: bcm4760: Add restart hook
In-Reply-To: <201307211020.25966.arnd@arndb.de>
References: <20130721002320.730568671@gmail.com>
 <20130721002714.732402573@gmail.com>
 <201307211020.25966.arnd@arndb.de>
Message-ID: <20130722211434.GA6665@glitch>

On Sun, Jul 21, 2013 at 10:20:25AM +0200, Arnd Bergmann wrote:
> On Sunday 21 July 2013, Domenico Andreoli wrote:
> > From: Domenico Andreoli <domenico.andreoli at linux.com>
> > 
> > Restart hook implementation for the Broadcom BCM4760 based ARM11 SoCs.
> > 
> > Cc: linux-arm-kernel at lists.infradead.org
> > Signed-off-by: Domenico Andreoli <domenico.andreoli at linux.com>
> > ---
> >  Documentation/devicetree/bindings/watchdog/brcm,bcm4760-pm-wdt.txt |   14 ++
> >  arch/arm/boot/dts/bcm4760.dtsi                                     |    5 +
> >  arch/arm/mach-bcm/bcm4760.c                                        |   78 ++++++++++
> >  3 files changed, 97 insertions(+)
> 
> The implementation looks ok to me, but I would prefer this to be part of a
> watchdog device driver that overrides the pm_power_off hook.

I'd appreciate if I could keep this implementation, which I don't plan to
develop further, but won't cry if it's left out.

> It can probably be done at a later stage when you submit a watchdog driver.

I should be able to reuse an existing ARM watchdog driver but I need to
investigate further.

BTW is it acceptable to loose the ability to reboot the board in case the
proper watchdog driver is not configured?

Domenico

> 
> 	Arnd
> 
> > Index: b/Documentation/devicetree/bindings/watchdog/brcm,bcm4760-pm-wdt.txt
> > ===================================================================
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm4760-pm-wdt.txt
> > @@ -0,0 +1,14 @@
> > +Broadcom BCM4760 watchdog timer device tree bindings
> > +----------------------------------------------------
> > +
> > +Required properties:
> > +
> > +- compatible : should be "brcm,bcm4760-pm-wdt"
> > +- reg : Specifies base physical address and size of the registers.
> > +
> > +Example:
> > +
> > +watchdog {
> > +	compatible = "brcm,bcm4760-pm-wdt";
> > +	reg = <0xbd000 0x1000>;
> > +};
> > Index: b/arch/arm/boot/dts/bcm4760.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/bcm4760.dtsi
> > +++ b/arch/arm/boot/dts/bcm4760.dtsi
> > @@ -23,6 +23,11 @@
> >  			reg = <0xbc000 0x1000>;
> >  		};
> >  
> > +		watchdog {
> > +			compatible = "brcm,bcm4760-pm-wdt";
> > +			reg = <0xbd000 0x1000>;
> > +		};
> > +
> >  		vic0: interrupt-controller at 80000 {
> >  			compatible = "brcm,bcm4760-pl192", "arm,pl192-vic", "arm,primecell";
> >  			reg = <0x80000 0x1000>;
> > Index: b/arch/arm/mach-bcm/bcm4760.c
> > ===================================================================
> > --- a/arch/arm/mach-bcm/bcm4760.c
> > +++ b/arch/arm/mach-bcm/bcm4760.c
> > @@ -16,7 +16,9 @@
> >  
> >  #include <linux/init.h>
> >  #include <linux/irqchip.h>
> > +#include <linux/delay.h>
> >  #include <linux/of_irq.h>
> > +#include <linux/of_address.h>
> >  #include <linux/of_platform.h>
> >  #include <linux/clk/bcm4760.h>
> >  
> > @@ -28,6 +30,17 @@
> >  #define BCM4760_PERIPH_VIRT   IOMEM(0xd0080000)
> >  #define BCM4760_PERIPH_SIZE   SZ_512K
> >  
> > +#define BCM4760_WDT_LOAD      0x000
> > +#define BCM4760_WDT_CTRL      0x008
> > +#define BCM4760_WDT_INTCLR    0x00c
> > +#define BCM4760_WDT_LOCK      0xc00
> > +
> > +#define BCM4760_WDT_PASSWORD  0x1acce551
> > +#define BCM4760_WDT_INTEN     BIT(0)
> > +#define BCM4760_WDT_RESEN     BIT(1)
> > +
> > +static void __iomem *wdt_regs;
> > +
> >  static struct map_desc io_map __initdata = {
> >  	.virtual = (unsigned long) BCM4760_PERIPH_VIRT,
> >  	.pfn = __phys_to_pfn(BCM4760_PERIPH_PHYS),
> > @@ -56,11 +69,75 @@ static void __init bcm4760_system_rev(vo
> >  		system_rev = id0 << 8 | (id1 & 0xff);
> >  }
> >  
> > +static const struct of_device_id bcm4760_pm_wdt_match[] __initconst = {
> > +	{ .compatible = "brcm,bcm4760-pm-wdt" },
> > +	{}
> > +};
> > +
> > +/*
> > + * The machine restart method can be called from an atomic context so we won't
> > + * be able to ioremap the regs then.
> > + */
> > +static void __init bcm4760_setup_restart(void)
> > +{
> > +	struct device_node *node;
> > +
> > +	node = of_find_matching_node(NULL, bcm4760_pm_wdt_match);
> > +	if (!node) {
> > +		pr_info("No bcm4760 watchdog node\n");
> > +		return;
> > +	}
> > +
> > +	wdt_regs = of_iomap(node, 0);
> > +	if (!wdt_regs) {
> > +		pr_err("Can't remap watchdog registers\n");
> > +		return;
> > +	}
> > +
> > +	/* unlock watchdog registers */
> > +	writel(BCM4760_WDT_PASSWORD, wdt_regs + BCM4760_WDT_LOCK);
> > +	/* disable watchdog */
> > +	writel(0, wdt_regs + BCM4760_WDT_CTRL);
> > +	/* lock watchdog registers */
> > +	writel(1, wdt_regs + BCM4760_WDT_LOCK);
> > +}
> > +
> > +static void bcm4760_restart(enum reboot_mode mode, const char *cmd)
> > +{
> > +	if (!wdt_regs) {
> > +		pr_err("No restart hook installed. ");
> > +		return;
> > +	}
> > +
> > +	/* unlock watchdog registers */
> > +	writel(BCM4760_WDT_PASSWORD, wdt_regs + BCM4760_WDT_LOCK);
> > +
> > +	/* disable watchdog */
> > +	writel(0, wdt_regs + BCM4760_WDT_CTRL);
> > +	udelay(20);
> > +
> > +	/* clear the irq status */
> > +	writel(1, wdt_regs + BCM4760_WDT_INTCLR);
> > +	udelay(20);
> > +
> > +	/* expire after 5 cycles (~156us) */
> > +	writel(5, wdt_regs + BCM4760_WDT_LOAD);
> > +	/* enable watchdog */
> > +	writel(BCM4760_WDT_INTEN | BCM4760_WDT_RESEN,
> > +		wdt_regs + BCM4760_WDT_CTRL);
> > +
> > +	/* lock watchdog registers */
> > +	writel(1, wdt_regs + BCM4760_WDT_LOCK);
> > +	/* wait the bite */
> > +	udelay(400);
> > +}
> > +
> >  static void __init bcm4760_init(void)
> >  {
> >  	int err;
> >  
> >  	bcm4760_system_rev();
> > +	bcm4760_setup_restart();
> >  	bcm4760_init_clocks();
> >  
> >  	err = of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> > @@ -78,5 +155,6 @@ static const char * const bcm4760_compat
> >  DT_MACHINE_START(BCM4760, "Broadcom BCM4760")
> >  	.map_io = bcm4760_map_io,
> >  	.init_machine = bcm4760_init,
> > +	.restart = bcm4760_restart,
> >  	.dt_compat = bcm4760_compat
> >  MACHINE_END
> > 
> > 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From linus.walleij at linaro.org  Mon Jul 22 17:15:52 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Jul 2013 23:15:52 +0200
Subject: [PATCH 1/4] pinctrl: single: Prepare for supporting SoC specific
 features
In-Reply-To: <20130608152732.GR3331@atomide.com>
References: <20130607203936.16513.57494.stgit@localhost>
 <20130607205037.16513.84242.stgit@localhost>
 <CAN1soZzLYpiakcgPR7mBOC7_mLFW=mZwOG98Dq6JpO+JHUW=cw@mail.gmail.com>
 <20130608152732.GR3331@atomide.com>
Message-ID: <CACRpkdapXZO003xhRCVg5sfQCfJUPMzunui5u6npmht-2hP7Tg@mail.gmail.com>

On Sat, Jun 8, 2013 at 5:27 PM, Tony Lindgren <tony at atomide.com> wrote:

> Subject: [PATCH] pinctrl: single: Prepare for supporting SoC specific features
>
> Let's replace is_pinconf with flags and add struct pcs_soc so we
> can support also other features like pin wake-up events. Let's
> export the probe so the SoC specific modules can pass their
> SoC specific data to pinctrl-single if needed.

I don't quite understand this motivation. Can this be more verbose and
include a bit about the mechanics?

- Why is this necessary? For example, pinctrl-single already supports
 generic pinconf, and we can surely add a PIN_CONFIG_WAKEUP
 to include/linux/pinctrl/pinconf-generic.h.

- Also: how does this cooperate with irq_set_wake()? If a pin is
 set to GPIO it is often backed by a GPIO driver (which is calling
 pinctrl_request_gpio() etc), maybe we should just add a
 pinctrl_set_wake() then that the irqchip portions of the GPIO drivers
 can call down to so the pinctrl driver sets this bit if need be?

I think this needs some more thought, especially the latter
concern.

Yours,
Linus Walleij


From daniel.lezcano at linaro.org  Mon Jul 22 17:28:10 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 22 Jul 2013 23:28:10 +0200
Subject: [PATCH v4 02/20] clocksource: samsung_pwm_timer: Correct
 definition of AUTORELOAD bit
In-Reply-To: <1658534.7nG6RFjcTc@flatron>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <9612221.r4mx9bHE64@flatron> <51ED9C8C.10803@linaro.org>
 <1658534.7nG6RFjcTc@flatron>
Message-ID: <51EDA3EA.9020502@linaro.org>

On 07/22/2013 11:11 PM, Tomasz Figa wrote:
> On Monday 22 of July 2013 22:56:44 Daniel Lezcano wrote:
>> On 07/22/2013 09:43 AM, Tomasz Figa wrote:
>>> On Monday 22 of July 2013 05:50:09 Daniel Lezcano wrote:
>>>> On 07/20/2013 02:04 AM, Tomasz Figa wrote:
>>>>> PWM channel 4 has its autoreload bit located at different position.
>>>>> This patch fixes the driver to account for that.
>>>>>
>>>>> This fixes a problem with the clocksource hanging after it overflows
>>>>> because it is not reloaded any more.
>>>>>
>>>>> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
>>>>> ---
>>>>>
>>>>>  drivers/clocksource/samsung_pwm_timer.c | 3 ++-
>>>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/clocksource/samsung_pwm_timer.c
>>>>> b/drivers/clocksource/samsung_pwm_timer.c index 3fa5b07..e238fb0
>>>>> 100644
>>>>> --- a/drivers/clocksource/samsung_pwm_timer.c
>>>>> +++ b/drivers/clocksource/samsung_pwm_timer.c
>>>>> @@ -47,7 +47,8 @@
>>>>>
>>>>>  #define TCON_START(chan)		(1 << (4 * (chan) + 0))
>>>>>  #define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
>>>>>  #define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
>>>>>
>>>>> -#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
>>>>> +#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) \
>>>>> +						+ (((chan) < 5) ? 3 : 2)))
>>>>
>>>> This macro is not readable. Please, fix it up with a comment please.
>>>
>>> /*
>>>
>>>  * Channel 4 (logically 5 in TCON register) has different position
>>>  * of autoreload bit.
>>>  */
>>>
>>> #define _TCON_AUTORELOAD(chan)			(1 << (4 * (chan) 
> + 3))
>>> #define _TCON_AUTORELOAD4(chan)			(1 << (4 * (chan) 
> + 2))
>>> #define TCON_AUTORELOAD(chan)			((chan < 5) ?
>>>
>>> 		_TCON_AUTORELOAD(chan) : _TCON_AUTORELOAD4(chan))
>>>
>>> What do you think?
>>
>> I don't get the arithmetic here and the code is poor in comment. A nice
>> comment would valuable here.
> 
> Each channel occupies 4 bits in TCON register, but there is a gap of 4 
> bits after channel 0. In addition for channel 4 the location of autoreload 
> bit in its set of bits is 2 as opposed to 3 for other channels. Here's the 
> layout of the register, for reference:
> 
> Timer 4 Auto Reload on/off	[22]
> Timer 4 Manual Update		[21]
> Timer 4 Start/Stop		[20]
> 
> Timer 3 Auto Reload on/off	[19]
> Reserved			[18]
> Timer 3 Manual Update		[17]
> Timer 3 Start/Stop		[16]
> 
> Timer 2 Auto Reload on/off	[15]
> Reserved			[14]
> Timer 2 Manual Update		[13]
> Timer 2 Start/Stop		[12]
> 
> Timer 1 Auto Reload on/off	[11]
> Timer 1 Output Inverter on/off	[10]
> Timer 1 Manual Update		[9]
> Timer 1 Start/Stop		[8]
> 
> Reserved			[7:5]
> Dead zone enable/disable	[4]
> 
> Timer 0 Auto Reload on/off	[3]
> Timer 0 Output Inverter on/off	[2]
> Timer 0 Manual Update		[1]
> Timer 0 Start/Stop		[0]

Ok, I understand now. Thanks for the clarification.

IMHO, the description you gave above (without layout) will fit well for
a comment :)

>> May be you can replace 1 << bla by BIT(bla) ?
> 
> Yes, BIT() would be nice here, but IMHO this is material for separate 
> patch as all the macros in this driver already use 1 << bla.

Yes, I agree.

Thanks
  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From s-anna at ti.com  Mon Jul 22 17:26:28 2013
From: s-anna at ti.com (Suman Anna)
Date: Mon, 22 Jul 2013 16:26:28 -0500
Subject: [PATCHv2 0/5] omap mailbox dt support
Message-ID: <1374528388-59442-1-git-send-email-s-anna@ti.com>

Hi,

This is an updated series for adding the device tree support to
the OMAP mailbox driver. The series is based on 3.11-rc2 and I
have tested this on Beagle-XM, Panda4 and OMAP5 uEVM (with
out-of-tree clock patches).

Changes in v2:
- Removed the #ti,mbox-data-cells from DT bindings and node data
- Includes 2 new patches that adds the data for OMAP5.

v1:
http://marc.info/?l=linux-omap&m=137159523405468&w=2

Suman Anna (5):
  mailbox/omap: add a parent structure common to all mboxes
  mailbox/omap: add support for parsing dt devices
  ARM: dts: OMAP2+: Add mailbox nodes
  ARM: OMAP5: hwmod data: Add mailbox data
  ARM: dts: OMAP5: Add mailbox dt node

 .../devicetree/bindings/mailbox/omap-mailbox.txt   |  43 ++++
 arch/arm/boot/dts/omap2420.dtsi                    |  12 ++
 arch/arm/boot/dts/omap2430.dtsi                    |  11 ++
 arch/arm/boot/dts/omap3.dtsi                       |  11 ++
 arch/arm/boot/dts/omap4.dtsi                       |  11 ++
 arch/arm/boot/dts/omap5.dtsi                       |  11 ++
 arch/arm/mach-omap2/devices.c                      |   2 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |  42 ++++
 drivers/mailbox/mailbox-omap1.c                    |  27 ++-
 drivers/mailbox/mailbox-omap2.c                    | 217 ++++++++++++++++-----
 drivers/mailbox/omap-mailbox.c                     |  32 ++-
 drivers/mailbox/omap-mbox.h                        |  10 +
 12 files changed, 355 insertions(+), 74 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt

-- 
1.8.3.3



From s-anna at ti.com  Mon Jul 22 17:26:38 2013
From: s-anna at ti.com (Suman Anna)
Date: Mon, 22 Jul 2013 16:26:38 -0500
Subject: [PATCHv2 1/5] mailbox/omap: add a parent structure common to all
 mboxes
Message-ID: <1374528398-59479-1-git-send-email-s-anna@ti.com>

A new structure, omap_mbox_device, is added to contain
the global variables pertinent to a mailbox h/w IP block.
This enables the support for having multiple instances of
the same h/w IP block in the SoC. The startup sequence for
each mailbox is also simplified along the way, removing the
usage of single global configuration variables for all h/w
instances.

Reviewed-by: Russ Dill <russ.dill at ti.com>
Signed-off-by: Suman Anna <s-anna at ti.com>
---
 drivers/mailbox/mailbox-omap1.c | 27 +++++++++---
 drivers/mailbox/mailbox-omap2.c | 95 +++++++++++++++++++++++++----------------
 drivers/mailbox/omap-mailbox.c  | 32 ++++++--------
 drivers/mailbox/omap-mbox.h     | 10 +++++
 4 files changed, 102 insertions(+), 62 deletions(-)

diff --git a/drivers/mailbox/mailbox-omap1.c b/drivers/mailbox/mailbox-omap1.c
index 9001b76..5e38ffc 100644
--- a/drivers/mailbox/mailbox-omap1.c
+++ b/drivers/mailbox/mailbox-omap1.c
@@ -26,7 +26,7 @@
 #define MAILBOX_DSP2ARM1_Flag		0x1c
 #define MAILBOX_DSP2ARM2_Flag		0x20
 
-static void __iomem *mbox_base;
+static struct omap_mbox_device omap1_mbox_device;
 
 struct omap_mbox1_fifo {
 	unsigned long cmd;
@@ -41,12 +41,12 @@ struct omap_mbox1_priv {
 
 static inline int mbox_read_reg(size_t ofs)
 {
-	return __raw_readw(mbox_base + ofs);
+	return __raw_readw(omap1_mbox_device.mbox_base + ofs);
 }
 
 static inline void mbox_write_reg(u32 val, size_t ofs)
 {
-	__raw_writew(val, mbox_base + ofs);
+	__raw_writew(val, omap1_mbox_device.mbox_base + ofs);
 }
 
 /* msg */
@@ -139,6 +139,7 @@ static struct omap_mbox mbox_dsp_info = {
 	.name	= "dsp",
 	.ops	= &omap1_mbox_ops,
 	.priv	= &omap1_mbox_dsp_priv,
+	.parent	= &omap1_mbox_device,
 };
 
 static struct omap_mbox *omap1_mboxes[] = { &mbox_dsp_info, NULL };
@@ -148,6 +149,7 @@ static int omap1_mbox_probe(struct platform_device *pdev)
 	struct resource *mem;
 	int ret;
 	struct omap_mbox **list;
+	struct omap_mbox_device *mdev = &omap1_mbox_device;
 
 	list = omap1_mboxes;
 	list[0]->irq = platform_get_irq_byname(pdev, "dsp");
@@ -156,13 +158,18 @@ static int omap1_mbox_probe(struct platform_device *pdev)
 	if (!mem)
 		return -ENOENT;
 
-	mbox_base = ioremap(mem->start, resource_size(mem));
-	if (!mbox_base)
+	mdev->mbox_base = ioremap(mem->start, resource_size(mem));
+	if (!mdev->mbox_base)
 		return -ENOMEM;
+	mutex_init(&mdev->cfg_lock);
+	mdev->dev = &pdev->dev;
+	mdev->mboxes = omap1_mboxes;
+	mdev->num_users = 2;
+	mdev->num_fifos = 4;
 
 	ret = omap_mbox_register(&pdev->dev, list);
 	if (ret) {
-		iounmap(mbox_base);
+		iounmap(mdev->mbox_base);
 		return ret;
 	}
 
@@ -171,8 +178,14 @@ static int omap1_mbox_probe(struct platform_device *pdev)
 
 static int omap1_mbox_remove(struct platform_device *pdev)
 {
+	struct omap_mbox_device *mdev = &omap1_mbox_device;
+
 	omap_mbox_unregister();
-	iounmap(mbox_base);
+	iounmap(mdev->mbox_base);
+	mdev->mbox_base = NULL;
+	mdev->mboxes = NULL;
+	mdev->dev = NULL;
+
 	return 0;
 }
 
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index eba380d..6c0687c 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -42,8 +42,6 @@
 #define MBOX_NR_REGS			(MBOX_REG_SIZE / sizeof(u32))
 #define OMAP4_MBOX_NR_REGS		(OMAP4_MBOX_REG_SIZE / sizeof(u32))
 
-static void __iomem *mbox_base;
-
 struct omap_mbox2_fifo {
 	unsigned long msg;
 	unsigned long fifo_stat;
@@ -62,34 +60,38 @@ struct omap_mbox2_priv {
 	u32 intr_type;
 };
 
-static inline unsigned int mbox_read_reg(size_t ofs)
+static inline
+unsigned int mbox_read_reg(struct omap_mbox_device *mdev, size_t ofs)
 {
-	return __raw_readl(mbox_base + ofs);
+	return __raw_readl(mdev->mbox_base + ofs);
 }
 
-static inline void mbox_write_reg(u32 val, size_t ofs)
+static inline
+void mbox_write_reg(struct omap_mbox_device *mdev, u32 val, size_t ofs)
 {
-	__raw_writel(val, mbox_base + ofs);
+	__raw_writel(val, mdev->mbox_base + ofs);
 }
 
 /* Mailbox H/W preparations */
 static int omap2_mbox_startup(struct omap_mbox *mbox)
 {
-	u32 l;
-
-	pm_runtime_enable(mbox->dev->parent);
-	pm_runtime_get_sync(mbox->dev->parent);
+	pm_runtime_get_sync(mbox->parent->dev);
 
-	l = mbox_read_reg(MAILBOX_REVISION);
-	pr_debug("omap mailbox rev %d.%d\n", (l & 0xf0) >> 4, (l & 0x0f));
+	/*
+	 * just print the raw revision register, the format is not
+	 * uniform across all SoCs
+	 */
+	if (!mbox->use_count) {
+		u32 l = mbox_read_reg(mbox->parent, MAILBOX_REVISION);
+		pr_debug("omap mailbox rev 0x%x\n", l);
+	}
 
 	return 0;
 }
 
 static void omap2_mbox_shutdown(struct omap_mbox *mbox)
 {
-	pm_runtime_put_sync(mbox->dev->parent);
-	pm_runtime_disable(mbox->dev->parent);
+	pm_runtime_put_sync(mbox->parent->dev);
 }
 
 /* Mailbox FIFO handle functions */
@@ -97,28 +99,28 @@ static mbox_msg_t omap2_mbox_fifo_read(struct omap_mbox *mbox)
 {
 	struct omap_mbox2_fifo *fifo =
 		&((struct omap_mbox2_priv *)mbox->priv)->rx_fifo;
-	return (mbox_msg_t) mbox_read_reg(fifo->msg);
+	return (mbox_msg_t) mbox_read_reg(mbox->parent, fifo->msg);
 }
 
 static void omap2_mbox_fifo_write(struct omap_mbox *mbox, mbox_msg_t msg)
 {
 	struct omap_mbox2_fifo *fifo =
 		&((struct omap_mbox2_priv *)mbox->priv)->tx_fifo;
-	mbox_write_reg(msg, fifo->msg);
+	mbox_write_reg(mbox->parent, msg, fifo->msg);
 }
 
 static int omap2_mbox_fifo_empty(struct omap_mbox *mbox)
 {
 	struct omap_mbox2_fifo *fifo =
 		&((struct omap_mbox2_priv *)mbox->priv)->rx_fifo;
-	return (mbox_read_reg(fifo->msg_stat) == 0);
+	return (mbox_read_reg(mbox->parent, fifo->msg_stat) == 0);
 }
 
 static int omap2_mbox_fifo_full(struct omap_mbox *mbox)
 {
 	struct omap_mbox2_fifo *fifo =
 		&((struct omap_mbox2_priv *)mbox->priv)->tx_fifo;
-	return mbox_read_reg(fifo->fifo_stat);
+	return mbox_read_reg(mbox->parent, fifo->fifo_stat);
 }
 
 /* Mailbox IRQ handle functions */
@@ -127,9 +129,9 @@ static void omap2_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
 	struct omap_mbox2_priv *p = mbox->priv;
 	u32 l, bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
 
-	l = mbox_read_reg(p->irqenable);
+	l = mbox_read_reg(mbox->parent, p->irqenable);
 	l |= bit;
-	mbox_write_reg(l, p->irqenable);
+	mbox_write_reg(mbox->parent, l, p->irqenable);
 }
 
 static void omap2_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
@@ -142,9 +144,9 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
 	 * OMAP4 and later SoCs have a dedicated interrupt disabling register.
 	 */
 	if (!p->intr_type)
-		bit = mbox_read_reg(p->irqdisable) & ~bit;
+		bit = mbox_read_reg(mbox->parent, p->irqdisable) & ~bit;
 
-	mbox_write_reg(bit, p->irqdisable);
+	mbox_write_reg(mbox->parent, bit, p->irqdisable);
 }
 
 static void omap2_mbox_ack_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
@@ -152,18 +154,18 @@ static void omap2_mbox_ack_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
 	struct omap_mbox2_priv *p = mbox->priv;
 	u32 bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
 
-	mbox_write_reg(bit, p->irqstatus);
+	mbox_write_reg(mbox->parent, bit, p->irqstatus);
 
 	/* Flush posted write for irq status to avoid spurious interrupts */
-	mbox_read_reg(p->irqstatus);
+	mbox_read_reg(mbox->parent, p->irqstatus);
 }
 
 static int omap2_mbox_is_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
 {
 	struct omap_mbox2_priv *p = mbox->priv;
 	u32 bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
-	u32 enable = mbox_read_reg(p->irqenable);
-	u32 status = mbox_read_reg(p->irqstatus);
+	u32 enable = mbox_read_reg(mbox->parent, p->irqenable);
+	u32 status = mbox_read_reg(mbox->parent, p->irqstatus);
 
 	return (int)(enable & status & bit);
 }
@@ -179,7 +181,7 @@ static void omap2_mbox_save_ctx(struct omap_mbox *mbox)
 	else
 		nr_regs = MBOX_NR_REGS;
 	for (i = 0; i < nr_regs; i++) {
-		p->ctx[i] = mbox_read_reg(i * sizeof(u32));
+		p->ctx[i] = mbox_read_reg(mbox->parent, i * sizeof(u32));
 
 		dev_dbg(mbox->dev, "%s: [%02x] %08x\n", __func__,
 			i, p->ctx[i]);
@@ -197,7 +199,7 @@ static void omap2_mbox_restore_ctx(struct omap_mbox *mbox)
 	else
 		nr_regs = MBOX_NR_REGS;
 	for (i = 0; i < nr_regs; i++) {
-		mbox_write_reg(p->ctx[i], i * sizeof(u32));
+		mbox_write_reg(mbox->parent, p->ctx[i], i * sizeof(u32));
 
 		dev_dbg(mbox->dev, "%s: [%02x] %08x\n", __func__,
 			i, p->ctx[i]);
@@ -228,6 +230,7 @@ static int omap2_mbox_probe(struct platform_device *pdev)
 	struct omap_mbox2_priv *priv, *privblk;
 	struct omap_mbox_pdata *pdata = pdev->dev.platform_data;
 	struct omap_mbox_dev_info *info;
+	struct omap_mbox_device *mdev;
 	int i;
 
 	if (!pdata || !pdata->info_cnt || !pdata->info) {
@@ -235,10 +238,16 @@ static int omap2_mbox_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
+	mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
+	if (!mdev)
+		return -ENOMEM;
+
 	/* allocate one extra for marking end of list */
 	list = kzalloc((pdata->info_cnt + 1) * sizeof(*list), GFP_KERNEL);
-	if (!list)
-		return -ENOMEM;
+	if (!list) {
+		ret = -ENOMEM;
+		goto free_mdev;
+	}
 
 	mboxblk = mbox = kzalloc(pdata->info_cnt * sizeof(*mbox), GFP_KERNEL);
 	if (!mboxblk) {
@@ -273,6 +282,7 @@ static int omap2_mbox_probe(struct platform_device *pdev)
 		priv->intr_type = pdata->intr_type;
 
 		mbox->priv = priv;
+		mbox->parent = mdev;
 		mbox->name = info->name;
 		mbox->ops = &omap2_mbox_ops;
 		mbox->irq = platform_get_irq(pdev, info->irq_id);
@@ -289,42 +299,55 @@ static int omap2_mbox_probe(struct platform_device *pdev)
 		goto free_privblk;
 	}
 
-	mbox_base = ioremap(mem->start, resource_size(mem));
-	if (!mbox_base) {
+	mdev->mbox_base = ioremap(mem->start, resource_size(mem));
+	if (!mdev->mbox_base) {
 		ret = -ENOMEM;
 		goto free_privblk;
 	}
 
+	mutex_init(&mdev->cfg_lock);
+	mdev->dev = &pdev->dev;
+	mdev->num_users = pdata->num_users;
+	mdev->num_fifos = pdata->num_fifos;
+	mdev->mboxes = list;
 	ret = omap_mbox_register(&pdev->dev, list);
 	if (ret)
 		goto unmap_mbox;
-	platform_set_drvdata(pdev, list);
+	platform_set_drvdata(pdev, mdev);
+
+	pm_runtime_enable(mdev->dev);
 
 	return 0;
 
 unmap_mbox:
-	iounmap(mbox_base);
+	iounmap(mdev->mbox_base);
 free_privblk:
 	kfree(privblk);
 free_mboxblk:
 	kfree(mboxblk);
 free_list:
 	kfree(list);
+free_mdev:
+	kfree(mdev);
 	return ret;
 }
 
 static int omap2_mbox_remove(struct platform_device *pdev)
 {
 	struct omap_mbox2_priv *privblk;
-	struct omap_mbox **list = platform_get_drvdata(pdev);
+	struct omap_mbox_device *mdev = platform_get_drvdata(pdev);
+	struct omap_mbox **list = mdev->mboxes;
 	struct omap_mbox *mboxblk = list[0];
 
+	pm_runtime_disable(mdev->dev);
+
 	privblk = mboxblk->priv;
 	omap_mbox_unregister();
-	iounmap(mbox_base);
+	iounmap(mdev->mbox_base);
 	kfree(privblk);
 	kfree(mboxblk);
 	kfree(list);
+	kfree(mdev);
 	platform_set_drvdata(pdev, NULL);
 
 	return 0;
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index d79a646..25a2da7 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -35,9 +35,6 @@
 
 static struct omap_mbox **mboxes;
 
-static int mbox_configured;
-static DEFINE_MUTEX(mbox_configured_lock);
-
 static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
 module_param(mbox_kfifo_size, uint, S_IRUGO);
 MODULE_PARM_DESC(mbox_kfifo_size, "Size of omap's mailbox kfifo (bytes)");
@@ -283,14 +280,12 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
 {
 	int ret = 0;
 	struct omap_mbox_queue *mq;
+	struct omap_mbox_device *mdev = mbox->parent;
 
-	mutex_lock(&mbox_configured_lock);
-	if (!mbox_configured++) {
-		if (likely(mbox->ops->startup)) {
-			ret = mbox->ops->startup(mbox);
-			if (unlikely(ret))
-				goto fail_startup;
-		} else
+	mutex_lock(&mdev->cfg_lock);
+	if (mbox->ops->startup) {
+		ret = mbox->ops->startup(mbox);
+		if (ret)
 			goto fail_startup;
 	}
 
@@ -319,7 +314,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
 
 		omap_mbox_enable_irq(mbox, IRQ_RX);
 	}
-	mutex_unlock(&mbox_configured_lock);
+	mutex_unlock(&mdev->cfg_lock);
 	return 0;
 
 fail_request_irq:
@@ -331,14 +326,15 @@ fail_alloc_txq:
 		mbox->ops->shutdown(mbox);
 	mbox->use_count--;
 fail_startup:
-	mbox_configured--;
-	mutex_unlock(&mbox_configured_lock);
+	mutex_unlock(&mdev->cfg_lock);
 	return ret;
 }
 
 static void omap_mbox_fini(struct omap_mbox *mbox)
 {
-	mutex_lock(&mbox_configured_lock);
+	struct omap_mbox_device *mdev = mbox->parent;
+
+	mutex_lock(&mdev->cfg_lock);
 
 	if (!--mbox->use_count) {
 		omap_mbox_disable_irq(mbox, IRQ_RX);
@@ -349,12 +345,10 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
 		mbox_queue_free(mbox->rxq);
 	}
 
-	if (likely(mbox->ops->shutdown)) {
-		if (!--mbox_configured)
-			mbox->ops->shutdown(mbox);
-	}
+	if (mbox->ops->shutdown)
+		mbox->ops->shutdown(mbox);
 
-	mutex_unlock(&mbox_configured_lock);
+	mutex_unlock(&mdev->cfg_lock);
 }
 
 struct omap_mbox *omap_mbox_get(const char *name, struct notifier_block *nb)
diff --git a/drivers/mailbox/omap-mbox.h b/drivers/mailbox/omap-mbox.h
index 6cd38fc..6df528a 100644
--- a/drivers/mailbox/omap-mbox.h
+++ b/drivers/mailbox/omap-mbox.h
@@ -50,12 +50,22 @@ struct omap_mbox_queue {
 	bool full;
 };
 
+struct omap_mbox_device {
+	struct device *dev;
+	struct mutex cfg_lock;
+	void __iomem *mbox_base;
+	u32 num_users;
+	u32 num_fifos;
+	struct omap_mbox **mboxes;
+};
+
 struct omap_mbox {
 	const char		*name;
 	unsigned int		irq;
 	struct omap_mbox_queue	*txq, *rxq;
 	struct omap_mbox_ops	*ops;
 	struct device		*dev;
+	struct omap_mbox_device *parent;
 	void			*priv;
 	int			use_count;
 	struct blocking_notifier_head	notifier;
-- 
1.8.3.3



From s-anna at ti.com  Mon Jul 22 17:26:46 2013
From: s-anna at ti.com (Suman Anna)
Date: Mon, 22 Jul 2013 16:26:46 -0500
Subject: [PATCHv2 2/5] mailbox/omap: add support for parsing dt devices
Message-ID: <1374528406-59515-1-git-send-email-s-anna@ti.com>

Logic has been added to the OMAP2+ mailbox code to
parse the mailbox dt nodes and construct the different
mailboxes associated with the instance. The design is
based on gathering the same information that was being
passed previously through the platform data, except for
the interrupt type configuration information.

Signed-off-by: Suman Anna <s-anna at ti.com>
---
 .../devicetree/bindings/mailbox/omap-mailbox.txt   |  43 +++++++
 drivers/mailbox/mailbox-omap2.c                    | 130 ++++++++++++++++++---
 2 files changed, 158 insertions(+), 15 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
new file mode 100644
index 0000000..8ffb08a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -0,0 +1,43 @@
+OMAP2+ Mailbox Driver
+
+Required properties:
+- compatible:		Should be one of the following,
+			    "ti,omap2-mailbox" for
+				OMAP2420, OMAP2430, OMAP3430, OMAP3630 SoCs
+			    "ti,omap4-mailbox" for
+				OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg:			Contains the mailbox register address range (base address
+			and length)
+- interrupts: 		Contains the interrupt information for the mailbox
+			device. The format is dependent on which interrupt
+			controller the OMAP device uses
+- ti,hwmods:		Name of the hwmod associated with the mailbox
+- ti,mbox-num-users:	Number of targets (processor devices) that the mailbox device
+			can interrupt
+- ti,mbox-num-fifos:	Number of h/w fifos within the mailbox device
+- ti,mbox-names:	Array of the names of the mailboxes
+- ti,mbox-data:		Mailbox descriptor data private to each mailbox. The 4
+			cells represent the following data,
+			  Cell #1 (tx_id) - mailbox fifo id used for
+						transmitting messages
+			  Cell #2 (rx_id) - mailbox fifo id on which messages
+						are received
+			  Cell #3 (irq_id) - irq identifier index number to use
+						from the interrupts data
+			  Cell #4 (usr_id) - mailbox user id for identifying the
+						interrupt into the MPU interrupt
+						controller.
+
+Example:
+
+/* OMAP4 */
+mailbox: mailbox at 4a0f4000 {
+	compatible = "ti,omap4-mailbox";
+	reg = <0x4a0f4000 0x200>;
+	interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+	ti,hwmods = "mailbox";
+	ti,mbox-num-users = <3>;
+	ti,mbox-num-fifos = <8>;
+	ti,mbox-names = "mbox-ipu", "mbox-dsp";
+	ti,mbox-data = <0 1 0 0>, <3 2 0 0>;
+};
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index 6c0687c..759f72c 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -14,6 +14,7 @@
 #include <linux/slab.h>
 #include <linux/clk.h>
 #include <linux/err.h>
+#include <linux/of_device.h>
 #include <linux/platform_device.h>
 #include <linux/io.h>
 #include <linux/pm_runtime.h>
@@ -222,6 +223,21 @@ static struct omap_mbox_ops omap2_mbox_ops = {
 	.restore_ctx	= omap2_mbox_restore_ctx,
 };
 
+static const struct of_device_id omap_mailbox_of_match[] = {
+	{
+		.compatible	= "ti,omap2-mailbox",
+		.data		= (void *) MBOX_INTR_CFG_TYPE1,
+	},
+	{
+		.compatible	= "ti,omap4-mailbox",
+		.data		= (void *) MBOX_INTR_CFG_TYPE2,
+	},
+	{
+		/* end */
+	},
+};
+MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
+
 static int omap2_mbox_probe(struct platform_device *pdev)
 {
 	struct resource *mem;
@@ -229,47 +245,127 @@ static int omap2_mbox_probe(struct platform_device *pdev)
 	struct omap_mbox **list, *mbox, *mboxblk;
 	struct omap_mbox2_priv *priv, *privblk;
 	struct omap_mbox_pdata *pdata = pdev->dev.platform_data;
-	struct omap_mbox_dev_info *info;
 	struct omap_mbox_device *mdev;
-	int i;
-
-	if (!pdata || !pdata->info_cnt || !pdata->info) {
+	struct omap_mbox_dev_info *info, *of_info = NULL;
+	struct device_node *node = pdev->dev.of_node;
+	int i, j;
+	u32 info_count = 0, intr_type = 0;
+	u32 num_users = 0, num_fifos = 0;
+	u32 dlen, dsize = 4;
+	u32 *tmp;
+	const __be32 *mbox_data;
+
+	if (!node && (!pdata || !pdata->info_cnt || !pdata->info)) {
 		pr_err("%s: platform not supported\n", __func__);
 		return -ENODEV;
 	}
 
+	if (node) {
+		intr_type = (u32)of_match_device(omap_mailbox_of_match,
+							&pdev->dev)->data;
+		if (intr_type != 0 && intr_type != 1) {
+			dev_err(&pdev->dev, "invalid match data value\n");
+			return -EINVAL;
+		}
+
+		if (of_property_read_u32(node, "ti,mbox-num-users",
+								&num_users)) {
+			dev_err(&pdev->dev,
+				"no ti,mbox-num-users configuration found\n");
+			return -ENODEV;
+		}
+
+		if (of_property_read_u32(node, "ti,mbox-num-fifos",
+								&num_fifos)) {
+			dev_err(&pdev->dev,
+				"no ti,mbox-num-fifos configuration found\n");
+			return -ENODEV;
+		}
+
+		info_count = of_property_count_strings(node, "ti,mbox-names");
+		if (!info_count) {
+			dev_err(&pdev->dev, "no mbox devices found\n");
+			return -ENODEV;
+		}
+
+		mbox_data = of_get_property(node, "ti,mbox-data", &dlen);
+		if (!mbox_data) {
+			dev_err(&pdev->dev, "no mbox device data found\n");
+			return -ENODEV;
+		}
+		dlen /= sizeof(dsize);
+		if (dlen != dsize * info_count) {
+			dev_err(&pdev->dev, "mbox device data is truncated\n");
+			return -ENODEV;
+		}
+
+		of_info = kzalloc(info_count * sizeof(*of_info), GFP_KERNEL);
+		if (!of_info)
+			return -ENOMEM;
+
+		i = 0;
+		while (i < info_count) {
+			info = of_info + i;
+			if (of_property_read_string_index(node,
+					"ti,mbox-names", i,  &info->name)) {
+				dev_err(&pdev->dev,
+					"mbox_name [%d] read failed\n", i);
+				ret = -ENODEV;
+				goto free_of;
+			}
+
+			tmp = &info->tx_id;
+			for (j = 0; j < dsize; j++) {
+				tmp[j] = of_read_number(
+						mbox_data + j + (i * dsize), 1);
+			}
+			i++;
+		}
+	}
+
+	if (!node) { /* non-DT device creation */
+		info_count = pdata->info_cnt;
+		info = pdata->info;
+		intr_type = pdata->intr_type;
+		num_users = pdata->num_users;
+		num_fifos = pdata->num_fifos;
+	} else {
+		info = of_info;
+	}
+
 	mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
-	if (!mdev)
-		return -ENOMEM;
+	if (!mdev) {
+		ret = -ENOMEM;
+		goto free_of;
+	}
 
 	/* allocate one extra for marking end of list */
-	list = kzalloc((pdata->info_cnt + 1) * sizeof(*list), GFP_KERNEL);
+	list = kzalloc((info_count + 1) * sizeof(*list), GFP_KERNEL);
 	if (!list) {
 		ret = -ENOMEM;
 		goto free_mdev;
 	}
 
-	mboxblk = mbox = kzalloc(pdata->info_cnt * sizeof(*mbox), GFP_KERNEL);
+	mboxblk = mbox = kzalloc(info_count * sizeof(*mbox), GFP_KERNEL);
 	if (!mboxblk) {
 		ret = -ENOMEM;
 		goto free_list;
 	}
 
-	privblk = priv = kzalloc(pdata->info_cnt * sizeof(*priv), GFP_KERNEL);
+	privblk = priv = kzalloc(info_count * sizeof(*priv), GFP_KERNEL);
 	if (!privblk) {
 		ret = -ENOMEM;
 		goto free_mboxblk;
 	}
 
-	info = pdata->info;
-	for (i = 0; i < pdata->info_cnt; i++, info++, priv++) {
+	for (i = 0; i < info_count; i++, info++, priv++) {
 		priv->tx_fifo.msg = MAILBOX_MESSAGE(info->tx_id);
 		priv->tx_fifo.fifo_stat = MAILBOX_FIFOSTATUS(info->tx_id);
 		priv->rx_fifo.msg =  MAILBOX_MESSAGE(info->rx_id);
 		priv->rx_fifo.msg_stat =  MAILBOX_MSGSTATUS(info->rx_id);
 		priv->notfull_bit = MAILBOX_IRQ_NOTFULL(info->tx_id);
 		priv->newmsg_bit = MAILBOX_IRQ_NEWMSG(info->rx_id);
-		if (pdata->intr_type) {
+		if (intr_type) {
 			priv->irqenable = OMAP4_MAILBOX_IRQENABLE(info->usr_id);
 			priv->irqstatus = OMAP4_MAILBOX_IRQSTATUS(info->usr_id);
 			priv->irqdisable =
@@ -279,7 +375,7 @@ static int omap2_mbox_probe(struct platform_device *pdev)
 			priv->irqstatus = MAILBOX_IRQSTATUS(info->usr_id);
 			priv->irqdisable = MAILBOX_IRQENABLE(info->usr_id);
 		}
-		priv->intr_type = pdata->intr_type;
+		priv->intr_type = intr_type;
 
 		mbox->priv = priv;
 		mbox->parent = mdev;
@@ -307,8 +403,8 @@ static int omap2_mbox_probe(struct platform_device *pdev)
 
 	mutex_init(&mdev->cfg_lock);
 	mdev->dev = &pdev->dev;
-	mdev->num_users = pdata->num_users;
-	mdev->num_fifos = pdata->num_fifos;
+	mdev->num_users = num_users;
+	mdev->num_fifos = num_fifos;
 	mdev->mboxes = list;
 	ret = omap_mbox_register(&pdev->dev, list);
 	if (ret)
@@ -317,6 +413,7 @@ static int omap2_mbox_probe(struct platform_device *pdev)
 
 	pm_runtime_enable(mdev->dev);
 
+	kfree(of_info);
 	return 0;
 
 unmap_mbox:
@@ -329,6 +426,8 @@ free_list:
 	kfree(list);
 free_mdev:
 	kfree(mdev);
+free_of:
+	kfree(of_info);
 	return ret;
 }
 
@@ -358,6 +457,7 @@ static struct platform_driver omap2_mbox_driver = {
 	.remove	= omap2_mbox_remove,
 	.driver	= {
 		.name = "omap-mailbox",
+		.of_match_table = omap_mailbox_of_match,
 	},
 };
 
-- 
1.8.3.3



From s-anna at ti.com  Mon Jul 22 17:26:55 2013
From: s-anna at ti.com (Suman Anna)
Date: Mon, 22 Jul 2013 16:26:55 -0500
Subject: [PATCHv2 3/5] ARM: dts: OMAP2+: Add mailbox nodes
Message-ID: <1374528415-59554-1-git-send-email-s-anna@ti.com>

The mailbox DT node data has been added for OMAP2420,
OMAP2430, OMAP3430/OMAP3630, OMAP44xx devices. Data
for OMAP5 and other SoCs will be added separately.

The mailbox static device initialization logic is also
adjusted for a DT boot.

Signed-off-by: Suman Anna <s-anna at ti.com>
---
 arch/arm/boot/dts/omap2420.dtsi | 12 ++++++++++++
 arch/arm/boot/dts/omap2430.dtsi | 11 +++++++++++
 arch/arm/boot/dts/omap3.dtsi    | 11 +++++++++++
 arch/arm/boot/dts/omap4.dtsi    | 11 +++++++++++
 arch/arm/mach-omap2/devices.c   |  2 +-
 5 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index c8f9c55..43081e9 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -114,6 +114,18 @@
 			dma-names = "tx", "rx";
 		};
 
+		mailbox: mailbox at 48094000 {
+			compatible = "ti,omap2-mailbox";
+			reg = <0x48094000 0x200>;
+			interrupts = <26>, /* DSP Interrupt */
+				     <34>; /* IVA Interrupt */
+			ti,hwmods = "mailbox";
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <6>;
+			ti,mbox-names = "dsp", "iva";
+			ti,mbox-data = <0 1 0 0>, <2 3 1 3>;
+		};
+
 		timer1: timer at 48028000 {
 			compatible = "ti,omap2420-timer";
 			reg = <0x48028000 0x400>;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c535a5a..55c4236 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -175,6 +175,17 @@
 			dma-names = "tx", "rx";
 		};
 
+		mailbox: mailbox at 48094000 {
+			compatible = "ti,omap2-mailbox";
+			reg = <0x48094000 0x200>;
+			interrupts = <26>;
+			ti,hwmods = "mailbox";
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <6>;
+			ti,mbox-names = "dsp";
+			ti,mbox-data = <0 1 0 0>;
+		};
+
 		timer1: timer at 49018000 {
 			compatible = "ti,omap2420-timer";
 			reg = <0x49018000 0x400>;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..7278656 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -386,6 +386,17 @@
 			dma-names = "tx", "rx";
 		};
 
+		mailbox: mailbox at 48094000 {
+			compatible = "ti,omap2-mailbox";
+			reg = <0x48094000 0x200>;
+			interrupts = <26>;
+			ti,hwmods = "mailbox";
+			ti,mbox-num-users = <2>;
+			ti,mbox-num-fifos = <2>;
+			ti,mbox-names = "dsp";
+			ti,mbox-data = <0 1 0 0>;
+		};
+
 		timer1: timer at 48318000 {
 			compatible = "ti,omap3430-timer";
 			reg = <0x48318000 0x400>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..66f11a3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -523,6 +523,17 @@
 			};
 		};
 
+		mailbox: mailbox at 4a0f4000 {
+			compatible = "ti,omap4-mailbox";
+			reg = <0x4a0f4000 0x200>;
+			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+			ti,hwmods = "mailbox";
+			ti,mbox-num-users = <3>;
+			ti,mbox-num-fifos = <8>;
+			ti,mbox-names = "mbox-ipu", "mbox-dsp";
+			ti,mbox-data = <0 1 0 0>, <3 2 0 0>;
+		};
+
 		timer1: timer at 4a318000 {
 			compatible = "ti,omap3430-timer";
 			reg = <0x4a318000 0x80>;
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 3c1279f..0afdf6f 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -562,10 +562,10 @@ static int __init omap2_init_devices(void)
 	omap_init_audio();
 	omap_init_camera();
 	omap_init_hdmi_audio();
-	omap_init_mbox();
 	/* If dtb is there, the devices will be created dynamically */
 	if (!of_have_populated_dt()) {
 		omap_init_dmic();
+		omap_init_mbox();
 		omap_init_mcpdm();
 		omap_init_mcspi();
 		omap_init_sham();
-- 
1.8.3.3



From s-anna at ti.com  Mon Jul 22 17:27:06 2013
From: s-anna at ti.com (Suman Anna)
Date: Mon, 22 Jul 2013 16:27:06 -0500
Subject: [PATCHv2 4/5] ARM: OMAP5: hwmod data: Add mailbox data
Message-ID: <1374528426-59590-1-git-send-email-s-anna@ti.com>

Add the hwmod data for the mailbox IP in OMAP5 SoC.
This is needed to be able to enable the OMAP mailbox
support for OMAP5.

Signed-off-by: Suman Anna <s-anna at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 42 ++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index f37ae96..e4f85da 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -741,6 +741,39 @@ static struct omap_hwmod omap54xx_kbd_hwmod = {
 };
 
 /*
+ * 'mailbox' class
+ * mailbox module allowing communication between the on-chip processors using a
+ * queued mailbox-interrupt mechanism.
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_mailbox_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_mailbox_hwmod_class = {
+	.name	= "mailbox",
+	.sysc	= &omap54xx_mailbox_sysc,
+};
+
+/* mailbox */
+static struct omap_hwmod omap54xx_mailbox_hwmod = {
+	.name		= "mailbox",
+	.class		= &omap54xx_mailbox_hwmod_class,
+	.clkdm_name	= "l4cfg_clkdm",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L4CFG_MAILBOX_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L4CFG_MAILBOX_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
  * 'mcbsp' class
  * multi channel buffered serial port controller
  */
@@ -1807,6 +1840,14 @@ static struct omap_hwmod_ocp_if omap54xx_l4_wkup__kbd = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_cfg -> mailbox */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__mailbox = {
+	.master		= &omap54xx_l4_cfg_hwmod,
+	.slave		= &omap54xx_mailbox_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_abe -> mcbsp1 */
 static struct omap_hwmod_ocp_if omap54xx_l4_abe__mcbsp1 = {
 	.master		= &omap54xx_l4_abe_hwmod,
@@ -2107,6 +2148,7 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] __initdata = {
 	&omap54xx_l4_per__i2c4,
 	&omap54xx_l4_per__i2c5,
 	&omap54xx_l4_wkup__kbd,
+	&omap54xx_l4_cfg__mailbox,
 	&omap54xx_l4_abe__mcbsp1,
 	&omap54xx_l4_abe__mcbsp2,
 	&omap54xx_l4_abe__mcbsp3,
-- 
1.8.3.3



From s-anna at ti.com  Mon Jul 22 17:27:16 2013
From: s-anna at ti.com (Suman Anna)
Date: Mon, 22 Jul 2013 16:27:16 -0500
Subject: [PATCHv2 5/5] ARM: dts: OMAP5: Add mailbox dt node
Message-ID: <1374528436-59626-1-git-send-email-s-anna@ti.com>

Add the mailbox device DT node for OMAP5 SoC.

Signed-off-by: Suman Anna <s-anna at ti.com>
---
 arch/arm/boot/dts/omap5.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..a08f1ca 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -505,6 +505,17 @@
 			dma-names = "tx", "rx";
 		};
 
+		mailbox: mailbox at 4a0f4000 {
+			compatible = "ti,omap4-mailbox";
+			reg = <0x4a0f4000 0x200>;
+			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+			ti,hwmods = "mailbox";
+			ti,mbox-num-users = <3>;
+			ti,mbox-num-fifos = <8>;
+			ti,mbox-names = "mbox-ipu", "mbox-dsp";
+			ti,mbox-data = <0 1 0 0>, <3 2 0 0>;
+		};
+
 		timer1: timer at 4ae18000 {
 			compatible = "ti,omap5430-timer";
 			reg = <0x4ae18000 0x80>;
-- 
1.8.3.3



From julien.grall at linaro.org  Mon Jul 22 17:40:58 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Mon, 22 Jul 2013 22:40:58 +0100
Subject: [PATCH] xen/arm64: Don't compile cpu hotplug
Message-ID: <1374529258-12866-1-git-send-email-julien.grall@linaro.org>

On ARM64, when CONFIG_XEN=y, the compilation will fail because CPU hotplug is
not yet supported with XEN. For now, disable it.

Signed-off-by: Julien Grall <julien.grall at linaro.org>
---
 drivers/xen/Makefile |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 2bf461a..a609353 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,4 +1,4 @@
-ifneq ($(CONFIG_ARM),y)
+ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
 obj-y	+= manage.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
-- 
1.7.10.4



From julien.grall at linaro.org  Mon Jul 22 17:42:01 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Mon, 22 Jul 2013 22:42:01 +0100
Subject: [PATCH v4] xen/arm: enable PV control for ARM
Message-ID: <1374529321-12955-1-git-send-email-julien.grall@linaro.org>

Enable power management from the toolstack for ARM guest.

Signed-off-by: Julien Grall <julien.grall at linaro.org>

---
    Changes in v4:
        - Divide the patch in 2 distinct parts
    Changes in v3:
        - Fix condition to compile cpu_hotplug.o
    Changes in v2:
        - Don't compile xen/cpu_hotplug.o with ARM64
---
 drivers/xen/Makefile |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index a609353..f185e8d 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,9 +1,8 @@
 ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
-obj-y	+= manage.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
 obj-$(CONFIG_X86)			+= fallback.o
-obj-y	+= grant-table.o features.o events.o balloon.o time.o
+obj-y	+= grant-table.o features.o events.o balloon.o time.o manage.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
-- 
1.7.10.4



From linus.walleij at linaro.org  Mon Jul 22 17:44:22 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Jul 2013 23:44:22 +0200
Subject: [PATCH 2/4] pinctrl: single: Add hardware specific hooks for IRQ
 and GPIO wake-up events
In-Reply-To: <20130610153637.GK8164@atomide.com>
References: <20130607203936.16513.57494.stgit@localhost>
 <20130607205040.16513.36794.stgit@localhost>
 <CAN1soZznJ1YxWhaFZ4rhQx+uk3aCigAcVeuLpOU+3oPzmfXF6w@mail.gmail.com>
 <20130610153637.GK8164@atomide.com>
Message-ID: <CACRpkdZNGHRJX3_HRCAfKgrRGLMVbqNzFBfu7wP-3YrhOUESkw@mail.gmail.com>

On Mon, Jun 10, 2013 at 5:36 PM, Tony Lindgren <tony at atomide.com> wrote:

> At least on omaps, each board typically has at least one device
> configured as wake-up capable from deeper idle modes. In the
> deeper idle modes the normal interrupt wake-up path won't work
> as the logic is powered off and separate wake-up hardware is
> available either via IO ring or GPIO hardware.

What I do not understand is why the irq_set_wake() should
not fall through to that IO ring / GPIO hardware.

For example: a composite GPIO+irqchip driver should surely
set the wake up for a certain line for irq_set_wake()?

> The wake-up
> event can be device specific, or may need to be dynamically
> remuxed to GPIO input for wake-up events. When the wake-up
> event happens, it's IRQ need to be called so the device won't
> lose interrupts.

I recognize this hardware type. The name I use for these
things are "latent interrupts".

What I think is that they should maybe be modeled as
irqchip from end to end, so that we don't orthogonally use
any pinctrl states to set this up.

> Allow supporting IRQ and GPIO wake-up events if a hardware
> spefific module is registered for the enable and disable

s/spefific/specific

> calls.
>
> Done in collaboration with Roger Quadros <rogerq at ti.com>.
>
> Cc: Haojian Zhuang <haojian.zhuang at gmail.com>
> Cc: Peter Ujfalusi <peter.ujfalusi at ti.com>
> Cc: devicetree-discuss at lists.ozlabs.org
> Signed-off-by: Roger Quadros <rogerq at ti.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>
(...)
> +- interrrupts : the interrupt that a function may have for a wake-up event

interrupts

> +
> +- gpios: the gpio that a function may have for a wake-up event

Is this a GPIO property or a pin property?

"wake up" is not supported by the GPIO subsystem is it?
Not in <linux/gpio.h> atleast.

This smells like shoehorning pin config stuff into the GPIO
subsystem again which is a no-no :-)

> diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
> @@ -1183,6 +1241,24 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
>         } else {
>                 *num_maps = 1;
>         }
> +
> +       if (pcs->flags & PCS_HAS_FUNCTION_IRQ)
> +               function->irq = irq_of_parse_and_map(np, 0);
> +
> +       if (pcs->flags & PCS_HAS_FUNCTION_GPIO) {
> +               function->gpio = of_get_gpio(np, 0);
> +               if (function->gpio > 0 && !function->irq) {
> +                       if (gpio_is_valid(function->gpio))
> +                               function->irq = gpio_to_irq(function->gpio);
> +               }
> +       }
> +
> +       if (function->irq > 0 && pcs->soc && pcs->soc->reg_init) {
> +               res = pcs_parse_wakeup(pcs, np, function);
> +               if (res)
> +                       goto free_pingroups;
> +       }

So this thing here. Instead of introducing a cross reference to the
IRQ and GPIO here and

> + * @irq:       optional irq specified for wake-up for example
> + * @gpio:      optional gpio specified for wake-up for example
> + * @node:      optional list
> + */
> +struct pcs_reg {
> +       unsigned (*read)(void __iomem *reg);
> +       void (*write)(unsigned val, void __iomem *reg);
> +       void __iomem *reg;
> +       unsigned val;
> +       int irq;
> +       int gpio;
> +       struct list_head node;
> +};
> +
> +#define PCS_HAS_FUNCTION_GPIO   (1 << 2)
> +#define PCS_HAS_FUNCTION_IRQ    (1 << 1)
>  #define PCS_HAS_PINCONF         (1 << 0)
>
>  /**
>   * struct pcs_soc - SoC specific interface to pinctrl-single
>   * @data:      SoC specific data pointer
>   * @flags:     mask of PCS_HAS_xxx values
> + * @reg_init:  SoC specific register init function
> + * @enable:    SoC specific enable function
> + * @disable:   SoC specific disable function
>   */
>  struct pcs_soc {
>         void *data;
>         unsigned flags;
> +       int (*reg_init)(const struct pcs_soc *soc, struct pcs_reg *r);
> +       int (*enable)(const struct pcs_soc *soc, struct pcs_reg *r);
> +       void (*disable)(const struct pcs_soc *soc, struct pcs_reg *r);

Then these quirks and sub-modules ...

Why can't the irqchip/GPIO driver call down to this driver
instead?

Yours,
Linus Walleij


From joelf at ti.com  Mon Jul 22 17:45:51 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 22 Jul 2013 16:45:51 -0500
Subject: [PATCH 1/3] dmaengine: add dma_get_slave_sg_limits()
In-Reply-To: <20130718161658.GW16653@intel.com>
References: <1374166001-31340-1-git-send-email-joelf@ti.com>
 <1374166001-31340-2-git-send-email-joelf@ti.com>
 <20130718161658.GW16653@intel.com>
Message-ID: <51EDA80F.7060606@ti.com>

On 07/18/2013 11:16 AM, Vinod Koul wrote:> On Thu, Jul 18, 2013 at
11:46:39AM -0500, Joel Fernandes wrote:
>> From: Matt Porter <mporter at ti.com>
>>
>> Add a dmaengine API to retrieve slave SG transfer limits.
>>
>> The API is optionally implemented by dmaengine drivers and when
>> unimplemented will return a NULL pointer. A client driver using
>> this API provides the required dma channel, address width, and
>> burst size of the transfer. dma_get_slave_sg_limits() returns an
>> SG limits structure with the maximum number and size of SG segments
>> that the given channel can handle.
> Hi Joel,
>
> I have already resurrected this and generalized the API to get the slave
> capablities.
> https://lkml.org/lkml/2013/7/15/147

Hi Vinod,

get_caps and get_sg_limits are 2 different things, looks like this was
already discussed earlier, and this patch series is a separate API that
adds support for SG limits.

Infact, you can already see here that he changed the name of the
function from caps to dma_get_slave_sg_limits:
http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2013-March/026601.html

Considering this, what is the way forward? Can this patch series be
merged as it is a different API as discussed above?

Summarizing:
* get_caps API cannot be used for this same purpose, as get_caps is done
_before_ the DMA channel can be configured from what it looks like:
* get_sg_limits, on the other hand is supposed to already have the
parameters required for configuring the DMA channel before hand.

Are there any other changes to the get_sg_limits series you would like
before it can be applied? Any other suggestions?

Thanks,

-Joel



From festevam at gmail.com  Mon Jul 22 17:54:15 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 22 Jul 2013 18:54:15 -0300
Subject: [PATCH v2 1/2] ARM: dts: mx6: Add support for mx6q nitrogen board
Message-ID: <1374530056-31335-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

mx6q sabrelite and nitrogen boards are hardware compatible.

Boundary Devices have a line of nitrogen boards based on quad/dual-lite and solo
variants.

Let's consolidate the common peripheral nodes into imx6qdl-nitrogen.dtsi and
add support for the mx6 quad nitrogen board.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/boot/dts/Makefile              |   1 +
 arch/arm/boot/dts/imx6q-nitrogen.dts    |  27 ++++++
 arch/arm/boot/dts/imx6q-sabrelite.dts   | 148 +----------------------------
 arch/arm/boot/dts/imx6qdl-nitrogen.dtsi | 161 ++++++++++++++++++++++++++++++++
 4 files changed, 190 insertions(+), 147 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6q-nitrogen.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-nitrogen.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index db510b3..d523340 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -128,6 +128,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx6dl-sabresd.dtb \
 	imx6dl-wandboard.dtb \
 	imx6q-arm2.dtb \
+	imx6q-nitrogen.dtb \
 	imx6q-phytec-pbab01.dtb \
 	imx6q-sabreauto.dtb \
 	imx6q-sabrelite.dtb \
diff --git a/arch/arm/boot/dts/imx6q-nitrogen.dts b/arch/arm/boot/dts/imx6q-nitrogen.dts
new file mode 100644
index 0000000..0ac5c59
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-nitrogen.dts
@@ -0,0 +1,27 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Fabio Estevam <fabio.estevam at freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-nitrogen.dtsi"
+
+/ {
+	model = "Boundary Devices i.MX6 Quad Nitrogen Board";
+	compatible = "boundary,imx6q-nitrogen", "fsl,imx6q";
+
+	memory {
+		reg = <0x10000000 0x40000000>;
+	};
+};
+
+&sata {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts b/arch/arm/boot/dts/imx6q-sabrelite.dts
index e0f4cd0..fc09c59 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -12,6 +12,7 @@
 
 /dts-v1/;
 #include "imx6q.dtsi"
+#include "imx6qdl-nitrogen.dtsi"
 
 / {
 	model = "Freescale i.MX6 Quad SABRE Lite Board";
@@ -20,155 +21,8 @@
 	memory {
 		reg = <0x10000000 0x40000000>;
 	};
-
-	regulators {
-		compatible = "simple-bus";
-
-		reg_2p5v: 2p5v {
-			compatible = "regulator-fixed";
-			regulator-name = "2P5V";
-			regulator-min-microvolt = <2500000>;
-			regulator-max-microvolt = <2500000>;
-			regulator-always-on;
-		};
-
-		reg_3p3v: 3p3v {
-			compatible = "regulator-fixed";
-			regulator-name = "3P3V";
-			regulator-min-microvolt = <3300000>;
-			regulator-max-microvolt = <3300000>;
-			regulator-always-on;
-		};
-
-		reg_usb_otg_vbus: usb_otg_vbus {
-			compatible = "regulator-fixed";
-			regulator-name = "usb_otg_vbus";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			gpio = <&gpio3 22 0>;
-			enable-active-high;
-		};
-	};
-
-	sound {
-		compatible = "fsl,imx6q-sabrelite-sgtl5000",
-			     "fsl,imx-audio-sgtl5000";
-		model = "imx6q-sabrelite-sgtl5000";
-		ssi-controller = <&ssi1>;
-		audio-codec = <&codec>;
-		audio-routing =
-			"MIC_IN", "Mic Jack",
-			"Mic Jack", "Mic Bias",
-			"Headphone Jack", "HP_OUT";
-		mux-int-port = <1>;
-		mux-ext-port = <4>;
-	};
 };
 
 &sata {
 	status = "okay";
 };
-
-&ecspi1 {
-	fsl,spi-num-chipselects = <1>;
-	cs-gpios = <&gpio3 19 0>;
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_ecspi1_1>;
-	status = "okay";
-
-	flash: m25p80 at 0 {
-		compatible = "sst,sst25vf016b";
-		spi-max-frequency = <20000000>;
-		reg = <0>;
-	};
-};
-
-&ssi1 {
-	fsl,mode = "i2s-slave";
-	status = "okay";
-};
-
-&iomuxc {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_hog>;
-
-	hog {
-		pinctrl_hog: hoggrp {
-			fsl,pins = <
-				MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x80000000
-				MX6QDL_PAD_NANDF_D7__GPIO2_IO07 0x80000000
-				MX6QDL_PAD_EIM_D19__GPIO3_IO19  0x80000000
-				MX6QDL_PAD_EIM_D22__GPIO3_IO22  0x80000000
-				MX6QDL_PAD_EIM_D23__GPIO3_IO23  0x80000000
-				MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x80000000
-				MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x1f0b0
-				MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x80000000
-			>;
-		};
-	};
-};
-
-&usbotg {
-	vbus-supply = <&reg_usb_otg_vbus>;
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_usbotg_1>;
-	disable-over-current;
-	status = "okay";
-};
-
-&usbh1 {
-	status = "okay";
-};
-
-&fec {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet_1>;
-	phy-mode = "rgmii";
-	phy-reset-gpios = <&gpio3 23 0>;
-	status = "okay";
-};
-
-&usdhc3 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_usdhc3_2>;
-	cd-gpios = <&gpio7 0 0>;
-	wp-gpios = <&gpio7 1 0>;
-	vmmc-supply = <&reg_3p3v>;
-	status = "okay";
-};
-
-&usdhc4 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_usdhc4_2>;
-	cd-gpios = <&gpio2 6 0>;
-	wp-gpios = <&gpio2 7 0>;
-	vmmc-supply = <&reg_3p3v>;
-	status = "okay";
-};
-
-&audmux {
-	status = "okay";
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_audmux_1>;
-};
-
-&uart2 {
-	status = "okay";
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_uart2_1>;
-};
-
-&i2c1 {
-	status = "okay";
-	clock-frequency = <100000>;
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_i2c1_1>;
-
-	codec: sgtl5000 at 0a {
-		compatible = "fsl,sgtl5000";
-		reg = <0x0a>;
-		clocks = <&clks 169>;
-		VDDA-supply = <&reg_2p5v>;
-		VDDIO-supply = <&reg_3p3v>;
-	};
-};
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen.dtsi
new file mode 100644
index 0000000..948063e
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen.dtsi
@@ -0,0 +1,161 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/ {
+	regulators {
+		compatible = "simple-bus";
+
+		reg_2p5v: 2p5v {
+			compatible = "regulator-fixed";
+			regulator-name = "2P5V";
+			regulator-min-microvolt = <2500000>;
+			regulator-max-microvolt = <2500000>;
+			regulator-always-on;
+		};
+
+		reg_3p3v: 3p3v {
+			compatible = "regulator-fixed";
+			regulator-name = "3P3V";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
+
+		reg_usb_otg_vbus: usb_otg_vbus {
+			compatible = "regulator-fixed";
+			regulator-name = "usb_otg_vbus";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			gpio = <&gpio3 22 0>;
+			enable-active-high;
+		};
+	};
+
+	sound {
+		compatible = "fsl,imx6q-sabrelite-sgtl5000",
+			     "fsl,imx-audio-sgtl5000";
+		model = "imx6q-sabrelite-sgtl5000";
+		ssi-controller = <&ssi1>;
+		audio-codec = <&codec>;
+		audio-routing =
+			"MIC_IN", "Mic Jack",
+			"Mic Jack", "Mic Bias",
+			"Headphone Jack", "HP_OUT";
+		mux-int-port = <1>;
+		mux-ext-port = <4>;
+	};
+};
+
+&audmux {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_audmux_1>;
+};
+
+&ecspi1 {
+	fsl,spi-num-chipselects = <1>;
+	cs-gpios = <&gpio3 19 0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi1_1>;
+	status = "okay";
+
+	flash: m25p80 at 0 {
+		compatible = "sst,sst25vf016b";
+		spi-max-frequency = <20000000>;
+		reg = <0>;
+	};
+};
+
+&i2c1 {
+	status = "okay";
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1_1>;
+
+	codec: sgtl5000 at 0a {
+		compatible = "fsl,sgtl5000";
+		reg = <0x0a>;
+		clocks = <&clks 169>;
+		VDDA-supply = <&reg_2p5v>;
+		VDDIO-supply = <&reg_3p3v>;
+	};
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	hog {
+		pinctrl_hog: hoggrp {
+			fsl,pins = <
+				MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x80000000
+				MX6QDL_PAD_NANDF_D7__GPIO2_IO07 0x80000000
+				MX6QDL_PAD_EIM_D19__GPIO3_IO19  0x80000000
+				MX6QDL_PAD_EIM_D22__GPIO3_IO22  0x80000000
+				MX6QDL_PAD_EIM_D23__GPIO3_IO23  0x80000000
+				MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x80000000
+				MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x1f0b0
+				MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x80000000
+			>;
+		};
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet_1>;
+	phy-mode = "rgmii";
+	phy-reset-gpios = <&gpio3 23 0>;
+	status = "okay";
+};
+
+&ssi1 {
+	fsl,mode = "i2s-slave";
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2_1>;
+};
+
+
+&usbh1 {
+	status = "okay";
+};
+
+&usbotg {
+	vbus-supply = <&reg_usb_otg_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbotg_1>;
+	disable-over-current;
+	status = "okay";
+};
+
+&usdhc3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc3_2>;
+	cd-gpios = <&gpio7 0 0>;
+	wp-gpios = <&gpio7 1 0>;
+	vmmc-supply = <&reg_3p3v>;
+	status = "okay";
+};
+
+&usdhc4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc4_2>;
+	cd-gpios = <&gpio2 6 0>;
+	wp-gpios = <&gpio2 7 0>;
+	vmmc-supply = <&reg_3p3v>;
+	status = "okay";
+};
-- 
1.8.1.2



From festevam at gmail.com  Mon Jul 22 17:54:16 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 22 Jul 2013 18:54:16 -0300
Subject: [PATCH v2 2/2] ARM: dts: mx6: Add support for imx6dl nitrogen board
In-Reply-To: <1374530056-31335-1-git-send-email-festevam@gmail.com>
References: <1374530056-31335-1-git-send-email-festevam@gmail.com>
Message-ID: <1374530056-31335-2-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- None

 arch/arm/boot/dts/Makefile            |  1 +
 arch/arm/boot/dts/imx6dl-nitrogen.dts | 27 +++++++++++++++++++++++++++
 2 files changed, 28 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-nitrogen.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index eeb2275..3f1a75d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -124,6 +124,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx53-mba53.dtb \
 	imx53-qsb.dtb \
 	imx53-smd.dtb \
+	imx6dl-nitrogen.dtb \
 	imx6dl-sabreauto.dtb \
 	imx6dl-sabresd.dtb \
 	imx6dl-wandboard.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-nitrogen.dts b/arch/arm/boot/dts/imx6dl-nitrogen.dts
new file mode 100644
index 0000000..d1ba3fc
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-nitrogen.dts
@@ -0,0 +1,27 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Fabio Estevam <fabio.estevam at freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-nitrogen.dtsi"
+
+/ {
+	model = "Boundary Devices i.MX6 Dual Lite Nitrogen Board";
+	compatible = "boundary,imx6dl-nitrogen", "fsl,imx6dl";
+
+	memory {
+		reg = <0x10000000 0x40000000>;
+	};
+};
+
+&sata {
+	status = "okay";
+};
-- 
1.8.1.2



From swarren at nvidia.com  Mon Jul 22 17:55:05 2013
From: swarren at nvidia.com (Stephen Warren)
Date: Mon, 22 Jul 2013 14:55:05 -0700
Subject: [PATCH v3] pinctrl: elaborate a bit on arrangements in doc
In-Reply-To: <1374428980-3997-1-git-send-email-linus.walleij@linaro.org>
References: <1374428980-3997-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <51EDAA39.8040004@nvidia.com>

On 07/21/2013 10:49 AM, Linus Walleij wrote:
> This elaborates a bit on the pin control and pin muxing
> logic vs GPIO arangements in the hardware.
> 
> Inspired by some drawings in a mail from Christian Ruppert.
> Both arrangements are confirmed to exist in practice.

Reviewed-by: Stephen Warren <swarren at nvidia.com>



From festevam at gmail.com  Mon Jul 22 17:56:11 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 22 Jul 2013 18:56:11 -0300
Subject: [PATCH v2 1/2] ARM: dts: mx6: Add support for mx6q nitrogen board
In-Reply-To: <1374530056-31335-1-git-send-email-festevam@gmail.com>
References: <1374530056-31335-1-git-send-email-festevam@gmail.com>
Message-ID: <CAOMZO5Cecs7DTHr_2KWXSBeTPXSZ_xZK7xbOxE8M=MyN4HWBrg@mail.gmail.com>

Hi Shawn,

On Mon, Jul 22, 2013 at 6:54 PM, Fabio Estevam <festevam at gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
>
> mx6q sabrelite and nitrogen boards are hardware compatible.
>
> Boundary Devices have a line of nitrogen boards based on quad/dual-lite and solo
> variants.
>
> Let's consolidate the common peripheral nodes into imx6qdl-nitrogen.dtsi and
> add support for the mx6 quad nitrogen board.
>
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

I missed to add:

Changes since v1:

- Put the nodes in alphabetical order
- Also add sata node for sabrelite


From mturquette at linaro.org  Mon Jul 22 18:02:53 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 22 Jul 2013 15:02:53 -0700
Subject: [PATCH] clk: exynos4: Add CLK_GET_RATE_NOCACHE flag for the
 Exynos4x12 ISP clocks
In-Reply-To: <51ED2230.8080100@samsung.com>
References: <1372099374-21008-1-git-send-email-s.nawrocki@samsung.com>
 <51ED2230.8080100@samsung.com>
Message-ID: <20130722220253.7598.5335@quantum>

Quoting Sylwester Nawrocki (2013-07-22 05:14:40)
> On 06/24/2013 08:42 PM, Sylwester Nawrocki wrote:
> > The ISP clock registers belong to the ISP power domain and may change
> > their values if this power domain is switched off/on. Add
> > CLK_GET_RATE_NOCACHE flags to ensure we do not rely on invalid cached
> > data when setting or getting frequency of those clocks.
> > 
> > Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> 
> Mike,
> 
> would you consider queueing that patch for current -rc cycle ?

Taken into clk-fixes. Will probably get it out before -rc3, but if not
definitely -rc4.

Regards,
Mike

> 
> Thanks,
> Sylwester


From linus.walleij at linaro.org  Mon Jul 22 18:03:01 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Jul 2013 00:03:01 +0200
Subject: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for
 wake-up events
In-Reply-To: <20130607205044.16513.27675.stgit@localhost>
References: <20130607203936.16513.57494.stgit@localhost>
 <20130607205044.16513.27675.stgit@localhost>
Message-ID: <CACRpkda-2HBkHP+ewkvMH5MV1GxEuXxS_nYEiDdgKtnoyTJpuQ@mail.gmail.com>

On Fri, Jun 7, 2013 at 10:50 PM, Tony Lindgren <tony at atomide.com> wrote:

> +static irqreturn_t pcs_omap_handle_irq(int irq, void *data)
> +{
> +       struct pcs_omap *pcso = data;
> +       struct list_head *pos;
> +       unsigned int wakeirq;
> +
> +       list_for_each(pos, &pcso->wakeirqs) {
> +               struct pcs_reg *pcsoi;
> +               u16 val;
> +
> +               pcsoi = list_entry(pos, struct pcs_reg, node);
> +               wakeirq = pcsoi->irq;
> +               val = pcsoi->read(pcsoi->reg);
> +               if ((val & OMAP_WAKEUP_EVENT_MASK) == OMAP_WAKEUP_EVENT_MASK)
> +                       generic_handle_irq(wakeirq);
> +       }
> +
> +       if (pcso->reconfigure_io_chain)
> +               pcso->reconfigure_io_chain();
> +
> +       return IRQ_HANDLED;
> +}

I fail to see why this is OMAP-specific.

I would prefer that this gets handled directly in the pinctrl core or
atleast in pinctrl-single in a generic way - latent IRQs is a generic
problem.

And I would also like it to work the other way around: when
irq_set_wake() is called from the irqchip it percolates down
to the pinctrl core and sets up a cross reference like this, for the pin,
so when an IRQ like this occurs, it will be routed up if and only
if it has been flagged as a wakeup from the irqchip layer.

The cross reference can be stored in struct pin_desc.

Yours,
Linus Walleij


From csd at broadcom.com  Mon Jul 22 18:03:35 2013
From: csd at broadcom.com (Christian Daudt)
Date: Mon, 22 Jul 2013 15:03:35 -0700
Subject: [PATCH 05/22] ARM: dts: bcm281xx: Remove '0x's from
 BCM11351 BRT DTS file
In-Reply-To: <1374490361-25769-5-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-5-git-send-email-lee.jones@linaro.org>
Message-ID: <51EDAC37.80305@broadcom.com>

On 13-07-22 03:52 AM, Lee Jones wrote:
> Cc: Christian Daudt <csd at broadcom.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>   arch/arm/boot/dts/bcm11351-brt.dts | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm11351-brt.dts b/arch/arm/boot/dts/bcm11351-brt.dts
> index 67ec524..fdace5d 100644
> --- a/arch/arm/boot/dts/bcm11351-brt.dts
> +++ b/arch/arm/boot/dts/bcm11351-brt.dts
> @@ -27,18 +27,18 @@
>   		status = "okay";
>   	};
>   
> -	sdio0: sdio at 0x3f180000 {
> +	sdio0: sdio at 3f180000 {
>   		max-frequency = <48000000>;
>   		status = "okay";
>   	};
>   
> -	sdio1: sdio at 0x3f190000 {
> +	sdio1: sdio at 3f190000 {
>   		non-removable;
>   		max-frequency = <48000000>;
>   		status = "okay";
>   	};
>   
> -	sdio3: sdio at 0x3f1b0000 {
> +	sdio3: sdio at 3f1b0000 {
>   		max-frequency = <48000000>;
>   		status = "okay";
>   	};
Acked-by: Christian Daudt <csd at broadcom.com>

  Thanks,
    csd




From csd at broadcom.com  Mon Jul 22 18:05:04 2013
From: csd at broadcom.com (Christian Daudt)
Date: Mon, 22 Jul 2013 15:05:04 -0700
Subject: [PATCH 06/22] ARM: dts: bcm281xx: Remove '0x's from
 BCM11351 DTS file
In-Reply-To: <1374490361-25769-6-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-6-git-send-email-lee.jones@linaro.org>
Message-ID: <51EDAC90.6010108@broadcom.com>

On 13-07-22 03:52 AM, Lee Jones wrote:
> Cc: Christian Daudt <csd at broadcom.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>   arch/arm/boot/dts/bcm11351.dtsi | 10 +++++-----
>   1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> index c0cdf66..db5873a 100644
> --- a/arch/arm/boot/dts/bcm11351.dtsi
> +++ b/arch/arm/boot/dts/bcm11351.dtsi
> @@ -34,7 +34,7 @@
>   		      <0x3ff00100 0x100>;
>   	};
>   
> -	smc at 0x3404c000 {
> +	smc at 3404c000 {
>   		compatible = "bcm,bcm11351-smc", "bcm,kona-smc";
>   		reg = <0x3404c000 0x400>; /* 1 KiB in SRAM */
>   	};
> @@ -63,28 +63,28 @@
>   		clock-frequency = <32768>;
>   	};
>   
> -	sdio0: sdio at 0x3f180000 {
> +	sdio0: sdio at 3f180000 {
>   		compatible = "bcm,kona-sdhci";
>   		reg = <0x3f180000 0x10000>;
>   		interrupts = <0x0 77 0x4>;
>   		status = "disabled";
>   	};
>   
> -	sdio1: sdio at 0x3f190000 {
> +	sdio1: sdio at 3f190000 {
>   		compatible = "bcm,kona-sdhci";
>   		reg = <0x3f190000 0x10000>;
>   		interrupts = <0x0 76 0x4>;
>   		status = "disabled";
>   	};
>   
> -	sdio2: sdio at 0x3f1a0000 {
> +	sdio2: sdio at 3f1a0000 {
>   		compatible = "bcm,kona-sdhci";
>   		reg = <0x3f1a0000 0x10000>;
>   		interrupts = <0x0 74 0x4>;
>   		status = "disabled";
>   	};
>   
> -	sdio3: sdio at 0x3f1b0000 {
> +	sdio3: sdio at 3f1b0000 {
>   		compatible = "bcm,kona-sdhci";
>   		reg = <0x3f1b0000 0x10000>;
>   		interrupts = <0x0 73 0x4>;
Acked-by: Christian Daudt <csd at broadcom.com>

  Thanks,
    csd



From linus.walleij at linaro.org  Mon Jul 22 18:06:12 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Jul 2013 00:06:12 +0200
Subject: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for
 wake-up events
In-Reply-To: <20130607205044.16513.27675.stgit@localhost>
References: <20130607203936.16513.57494.stgit@localhost>
 <20130607205044.16513.27675.stgit@localhost>
Message-ID: <CACRpkdathAjMtTGXz9U7EhsNEqdRCtxFuwQ2SFb=k8HEUewpAQ@mail.gmail.com>

On Fri, Jun 7, 2013 at 10:50 PM, Tony Lindgren <tony at atomide.com> wrote:

> For wake-up events from deeper idle modes we need to check the
> configured padconf registers for the wake-up bit and then call
> the related interrupt handler.
>
> Done in collaboration with Roger Quadros <rogerq at ti.com>.
>
> Cc: Haojian Zhuang <haojian.zhuang at gmail.com>
> Cc: Peter Ujfalusi <peter.ujfalusi at ti.com>
> Cc: devicetree-discuss at lists.ozlabs.org
> Signed-off-by: Roger Quadros <rogerq at ti.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>
(...)
> +                       pcsoi->gpio = r->gpio;

This "gpio" member appear to be used nowhere, which is probably
related to what I was saying about custom GPIO interfaces doing
pinconf, but I could be wrong...

> +/*
> + * Note that omap2430 has 8-bit padconf registers and uses
> + * the plain pinctrl-single binding.
> + */
> +static const struct of_device_id pcs_omap_of_match[] = {
> +       { .compatible = "ti,omap3-padconf", },
> +       { .compatible = "ti,omap4-padconf", },
> +       { .compatible = "ti,omap5-padconf", },
> +       {}
> +};

Goes into some binding document?

Yours,
Linus Walleij


From robertcnelson at gmail.com  Mon Jul 22 18:11:04 2013
From: robertcnelson at gmail.com (Robert Nelson)
Date: Mon, 22 Jul 2013 17:11:04 -0500
Subject: [PATCH v2 1/2] ARM: dts: mx6: Add support for mx6q nitrogen board
In-Reply-To: <1374530056-31335-1-git-send-email-festevam@gmail.com>
References: <1374530056-31335-1-git-send-email-festevam@gmail.com>
Message-ID: <CAOCHtYhB3b4PeYMYqsErUunF=Tbk=WY4tP=Lq9K15Cr98M0zpw@mail.gmail.com>

> diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen.dtsi
> new file mode 100644
> index 0000000..948063e
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-nitrogen.dtsi
> @@ -0,0 +1,161 @@
> +/*
> + * Copyright 2011 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/ {
> +       regulators {
> +               compatible = "simple-bus";
> +
> +               reg_2p5v: 2p5v {
> +                       compatible = "regulator-fixed";
> +                       regulator-name = "2P5V";
> +                       regulator-min-microvolt = <2500000>;
> +                       regulator-max-microvolt = <2500000>;
> +                       regulator-always-on;
> +               };
> +
> +               reg_3p3v: 3p3v {
> +                       compatible = "regulator-fixed";
> +                       regulator-name = "3P3V";
> +                       regulator-min-microvolt = <3300000>;
> +                       regulator-max-microvolt = <3300000>;
> +                       regulator-always-on;
> +               };
> +
> +               reg_usb_otg_vbus: usb_otg_vbus {
> +                       compatible = "regulator-fixed";
> +                       regulator-name = "usb_otg_vbus";
> +                       regulator-min-microvolt = <5000000>;
> +                       regulator-max-microvolt = <5000000>;
> +                       gpio = <&gpio3 22 0>;
> +                       enable-active-high;
> +               };
> +       };
> +
> +       sound {
> +               compatible = "fsl,imx6q-sabrelite-sgtl5000",
> +                            "fsl,imx-audio-sgtl5000";
> +               model = "imx6q-sabrelite-sgtl5000";
> +               ssi-controller = <&ssi1>;
> +               audio-codec = <&codec>;
> +               audio-routing =
> +                       "MIC_IN", "Mic Jack",
> +                       "Mic Jack", "Mic Bias",
> +                       "Headphone Jack", "HP_OUT";
> +               mux-int-port = <1>;
> +               mux-ext-port = <4>;
> +       };
> +};
> +
> +&audmux {
> +       status = "okay";
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_audmux_1>;
> +};
> +
> +&ecspi1 {
> +       fsl,spi-num-chipselects = <1>;
> +       cs-gpios = <&gpio3 19 0>;
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_ecspi1_1>;
> +       status = "okay";
> +
> +       flash: m25p80 at 0 {
> +               compatible = "sst,sst25vf016b";
> +               spi-max-frequency = <20000000>;
> +               reg = <0>;
> +       };
> +};
> +
> +&i2c1 {
> +       status = "okay";
> +       clock-frequency = <100000>;
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_i2c1_1>;
> +
> +       codec: sgtl5000 at 0a {
> +               compatible = "fsl,sgtl5000";
> +               reg = <0x0a>;
> +               clocks = <&clks 169>;
> +               VDDA-supply = <&reg_2p5v>;
> +               VDDIO-supply = <&reg_3p3v>;
> +       };
> +};
> +
> +&iomuxc {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_hog>;
> +
> +       hog {
> +               pinctrl_hog: hoggrp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x80000000
> +                               MX6QDL_PAD_NANDF_D7__GPIO2_IO07 0x80000000
> +                               MX6QDL_PAD_EIM_D19__GPIO3_IO19  0x80000000
> +                               MX6QDL_PAD_EIM_D22__GPIO3_IO22  0x80000000
> +                               MX6QDL_PAD_EIM_D23__GPIO3_IO23  0x80000000
> +                               MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x80000000
> +                               MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x1f0b0
> +                               MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x80000000
> +                       >;
> +               };
> +       };
> +};
> +
> +&fec {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_enet_1>;
> +       phy-mode = "rgmii";
> +       phy-reset-gpios = <&gpio3 23 0>;

This reset gpio is only good for the sabrelite, the Nitrogen use a
different gpio..

"phy-reset-gpios = <&gpio1 27 0>;"...

https://github.com/boundarydevices/u-boot-2009-08/commit/965c16903f3b15c24634b95feff85b8f14a31c66#L0R704
http://boundarydevices.com/differences-sabre-lite-nitrogen6x-and-som/

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/


From sergei.shtylyov at cogentembedded.com  Mon Jul 22 18:18:00 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Jul 2013 02:18:00 +0400
Subject: [PATCH v2 0/2] R8A7778/BOCK-W: HPB-DMAC support for SDHI0
Message-ID: <201307230218.01495.sergei.shtylyov@cogentembedded.com>

Hello.

   Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo,
'renesas-next-20130722' tag. Here we add the HPB-DMAC platform code working on
the R8A7778 and enable DMA for SDHI0 on BOCK-W. The patchset depends on the
R-Car HPB-DMAC driver patch posted earlier.

[1/2] ARM: shmobile: r8a7778: add HPB-DMAC support
[2/2] ARM: shmobile: BOCK-W: enable DMA for SDHI0

   The former patch #1 has been merged to the next patch moving the data from
the now removed <mach/dma.h> to <mach/r8a7778.h>.

WBR, Sergei


From sergei.shtylyov at cogentembedded.com  Mon Jul 22 18:22:04 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Jul 2013 02:22:04 +0400
Subject: [PATCH v2 1/2] ARM: shmobile: r8a7778: add HPB-DMAC support
In-Reply-To: <201307230218.01495.sergei.shtylyov@cogentembedded.com>
References: <201307230218.01495.sergei.shtylyov@cogentembedded.com>
Message-ID: <201307230222.04763.sergei.shtylyov@cogentembedded.com>

From: Max Filippov <max.filippov at cogentembedded.com>

Add HPB-DMAC platform device on R8A7778 SoC along with its slave and channel
configurations.

Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
[Sergei: moved *enum* declaring HPB-DMAC slave IDs from now removed <mach/dma.h>
to <mach/r8a7778.h>, removed #include <mach/dma.h> from setup-r8a7778.c, removed
SSI-related *enum* values and SSI-related data from hpb_dmae_slaves[] and
hpb_dmae_channels[].]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes in version 2:
- moved *enum* declaring HPB-DMAC slave IDs from the separate header file to
  <mach/r8a7778.h>, removed #include <mach/dma.h> from setup-r8a7778.c;
- removed SSI-related *enum* values and SSI-related data from hpb_dmae_slaves[]
  and hpb_dmae_channels[].

 arch/arm/mach-shmobile/include/mach/r8a7778.h |    8 ++
 arch/arm/mach-shmobile/setup-r8a7778.c        |   80 ++++++++++++++++++++++++++
 2 files changed, 88 insertions(+)

Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -1,6 +1,7 @@
 /*
  * Copyright (C) 2013  Renesas Solutions Corp.
  * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
+ * Copyright (C) 2013  Cogent Embedded, Inc.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -23,6 +24,13 @@
 #include <linux/sh_eth.h>
 #include <linux/platform_data/usb-rcar-phy.h>
 
+/* HPB-DMA slave IDs */
+enum {
+	HPBDMA_SLAVE_DUMMY,
+	HPBDMA_SLAVE_SDHI0_TX,
+	HPBDMA_SLAVE_SDHI0_RX,
+};
+
 extern void r8a7778_add_standard_devices(void);
 extern void r8a7778_add_standard_devices_dt(void);
 extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -24,6 +24,7 @@
 #include <linux/irqchip/arm-gic.h>
 #include <linux/of.h>
 #include <linux/of_platform.h>
+#include <linux/platform_data/dma-rcar-hpbdma.h>
 #include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_data/irq-renesas-intc-irqpin.h>
 #include <linux/platform_device.h>
@@ -333,6 +334,84 @@ void __init r8a7778_add_mmc_device(struc
 		info, sizeof(*info));
 }
 
+/* HPB-DMA */
+
+/* Asynchronous mode register (ASYNCMDR) bits */
+#define	ASYNCMDR_ASMD22_MASK	BIT(2)	/* SDHI0 */
+#define	ASYNCMDR_ASMD22_SINGLE	BIT(2)	/* SDHI0 */
+#define	ASYNCMDR_ASMD22_MULTI	0	/* SDHI0 */
+#define	ASYNCMDR_ASMD21_MASK	BIT(1)	/* SDHI0 */
+#define	ASYNCMDR_ASMD21_SINGLE	BIT(1)	/* SDHI0 */
+#define	ASYNCMDR_ASMD21_MULTI	0	/* SDHI0 */
+
+static const struct hpb_dmae_slave_config hpb_dmae_slaves[] = {
+	{
+		.id	= HPBDMA_SLAVE_SDHI0_TX,
+		.addr	= 0xffe4c000 + 0x30,
+		.dcr	= DCR_SPDS_16BIT | DCR_DMDL | DCR_DPDS_16BIT,
+		.rstr	= ASYNCRSTR_ASRST21 | ASYNCRSTR_ASRST22 |
+			  ASYNCRSTR_ASRST23,
+		.mdr	= ASYNCMDR_ASMD21_SINGLE,
+		.mdm	= ASYNCMDR_ASMD21_MASK,
+		.port	= 0x0D0C,
+		.flags	= HPB_DMAE_SET_ASYNC_RESET | HPB_DMAE_SET_ASYNC_MODE,
+		.dma_ch	= 21,
+	}, {
+		.id	= HPBDMA_SLAVE_SDHI0_RX,
+		.addr	= 0xffe4c000 + 0x30,
+		.dcr	= DCR_SMDL | DCR_SPDS_16BIT | DCR_DPDS_16BIT,
+		.rstr	= ASYNCRSTR_ASRST21 | ASYNCRSTR_ASRST22 |
+			  ASYNCRSTR_ASRST23,
+		.mdr	= ASYNCMDR_ASMD22_SINGLE,
+		.mdm	= ASYNCMDR_ASMD22_MASK,
+		.port	= 0x0D0C,
+		.flags	= HPB_DMAE_SET_ASYNC_RESET | HPB_DMAE_SET_ASYNC_MODE,
+		.dma_ch	= 22,
+	},
+};
+
+static const struct hpb_dmae_channel hpb_dmae_channels[] = {
+	/* ch. 21 SD0 */
+	HPB_DMAE_CHANNEL(0x7e, HPBDMA_SLAVE_SDHI0_TX),
+	/* ch. 22 SD0 */
+	HPB_DMAE_CHANNEL(0x7e, HPBDMA_SLAVE_SDHI0_RX),
+};
+
+static struct hpb_dmae_pdata dma_platform_data __initdata = {
+	.slaves			= hpb_dmae_slaves,
+	.num_slaves		= ARRAY_SIZE(hpb_dmae_slaves),
+	.channels		= hpb_dmae_channels,
+	.num_channels		= ARRAY_SIZE(hpb_dmae_channels),
+	.ts_shift		= {
+		[XMIT_SZ_8BIT]	= 0,
+		[XMIT_SZ_16BIT]	= 1,
+		[XMIT_SZ_32BIT]	= 2,
+	},
+	.num_hw_channels	= 39,
+};
+
+static struct resource hpb_dmae_resources[] __initdata = {
+	/* Channel registers */
+	DEFINE_RES_MEM(0xffc08000, 0x1000),
+	/* Common registers */
+	DEFINE_RES_MEM(0xffc09000, 0x170),
+	/* Asynchronous reset registers */
+	DEFINE_RES_MEM(0xffc00300, 4),
+	/* Asynchronous mode registers */
+	DEFINE_RES_MEM(0xffc00400, 4),
+	/* IRQ for DMA channels */
+	DEFINE_RES_NAMED(gic_iid(0x7b), 5, NULL, IORESOURCE_IRQ),
+};
+
+static void __init r8a7778_register_hpb_dmae(void)
+{
+	platform_device_register_resndata(&platform_bus, "hpb-dma-engine", -1,
+					  hpb_dmae_resources,
+					  ARRAY_SIZE(hpb_dmae_resources),
+					  &dma_platform_data,
+					  sizeof(dma_platform_data));
+}
+
 void __init r8a7778_add_standard_devices(void)
 {
 	int i;
@@ -355,6 +434,7 @@ void __init r8a7778_add_standard_devices
 
 	r8a7778_register_tmu(0);
 	r8a7778_register_tmu(1);
+	r8a7778_register_hpb_dmae();
 }
 
 void __init r8a7778_init_late(void)


From sergei.shtylyov at cogentembedded.com  Mon Jul 22 18:23:24 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Jul 2013 02:23:24 +0400
Subject: [PATCH v2 2/2] ARM: shmobile: BOCK-W: enable DMA for SDHI0
In-Reply-To: <201307230218.01495.sergei.shtylyov@cogentembedded.com>
References: <201307230218.01495.sergei.shtylyov@cogentembedded.com>
Message-ID: <201307230223.24954.sergei.shtylyov@cogentembedded.com>

From: Max Filippov <max.filippov at cogentembedded.com>

Pass HPB-DMA slave IDs in the SDHI0 platform data to enable DMA in the SDHI
driver.

Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
[Sergei: removed #include <mach/dma.h>]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes in version 2:
- removed #include <mach/dma.h>;
- refreshed the patch.

 arch/arm/mach-shmobile/board-bockw.c |    2 ++
 1 file changed, 2 insertions(+)

Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -81,6 +81,8 @@ static struct rcar_phy_platform_data usb
 
 /* SDHI */
 static struct sh_mobile_sdhi_info sdhi0_info = {
+	.dma_slave_tx	= HPBDMA_SLAVE_SDHI0_TX,
+	.dma_slave_rx	= HPBDMA_SLAVE_SDHI0_RX,
 	.tmio_caps	= MMC_CAP_SD_HIGHSPEED,
 	.tmio_ocr_mask	= MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
 	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT,


From linus.walleij at linaro.org  Mon Jul 22 18:31:45 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Jul 2013 00:31:45 +0200
Subject: [PATCH V2 1/5] gpio: clean up gpio-ranges documentation
In-Reply-To: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
References: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <CACRpkdYsZ0aMnANPpTiGuD1U23PCqyvVGS7vOOnOQUks5KSk9g@mail.gmail.com>

On Mon, Jul 15, 2013 at 8:40 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:

> This change makes documentation of the the gpio-ranges property shorter
> and more succinct, more consistent with the style of the rest of the
> document, and not mention Linux-specifics such as the API
> pinctrl_request_gpio(); DT binding documents should be OS independant
> where at all possible.

This is all good.

> This change also removes any mention of the #gpio-range-cells property.
> Such properties are useful when one node references a second node, and
> that second node dictates the format of the reference. However, that is
> not the case here; the definition of gpio-ranges itself always dictates
> its format entirely, and hence the value #gpio-range-cells must always
> be 3, and hence there is no point requiring any referenced node to
> include this property.
>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>

Can this mention the newly introduced Backus-Naur Form
description of the ranges.

> ---
> Patches 2-6 need to be applied in the same branch, since they all build
> upon each-other.
> ---

Still waiting for the OF maintainers to ACK so can't apply this. :-(

> +It is useful to represent which GPIOs correspond to which pins on which pin
> +controllers. The gpio-ranges property described below represents this, and
> +contains information strucutres as follows:

speling of strucutres

Should you mention that this is given in BNF?
Or is that implicit for all bindings?

>
> -This makes it logical to let gpio drivers announce their pin ranges to
> -the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to
> -request the corresponding pin before any gpio usage.
> +       gpio-range-list ::= <single-gpio-range> [gpio-range-list]
> +       single-gpio-range ::=
> +                       <pinctrl-phandle> <gpio-base> <pinctrl-base> <count>
> +       gpio-phandle : phandle to pin controller node.
> +       gpio-base : Base GPIO ID in the GPIO controller
> +       pinctrl-base : Base pinctrl pin ID in the pin controller
> +       count : The number of GPIOs/pins in this range

Yours,
Linus Walleij


From soren.brinkmann at xilinx.com  Mon Jul 22 18:41:01 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Mon, 22 Jul 2013 15:41:01 -0700
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <20130722201348.GI453@xsjandreislx>
References: <20130717210417.GP13667@xsjandreislx>
 <51E72DCA.9070500@codeaurora.org>
 <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
Message-ID: <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>

Hi,

adding LKML and LAKML (which I forgot on the original email, sorry)

On Mon, Jul 22, 2013 at 01:13:48PM -0700, S?ren Brinkmann wrote:
> On Mon, Jul 22, 2013 at 12:54:26PM -0700, Stephen Boyd wrote:
> > On 07/22/13 11:25, S?ren Brinkmann wrote:
> > > On Wed, Jul 17, 2013 at 06:22:35PM -0700, Stephen Boyd wrote:
> > >> On 07/17/13 17:59, S?ren Brinkmann wrote:
> > >>> Hi Stephen,
> > >>>
> > >>> On Wed, Jul 17, 2013 at 04:50:34PM -0700, Stephen Boyd wrote:
> > >>>> On 07/17/13 14:04, S?ren Brinkmann wrote:
> > >>>>> Hi all,
> > >>>>>
> > >>>>> I'm trying to enable the arm_global_timer on Zynq platforms with the
> > >>>>> attached patch. Unfortunately that patch breaks booting up. It hangs
> > >>>>> when handing over to init/early userspace (see attached boot.log).
> > >>>>>
> > >>>>> The funny thing is, if I remove either the global timer or the
> > >>>>> arm,cortex-a9-twd-timer node from my dts, it works. So, it looks like
> > >>>>> the two timer (drivers) interfere somehow. Does anybody have an idea of
> > >>>>> what is going on and probably even how to resolve it?
> > >>>>>
> > >>>>> The patch is based on commit c0d15cc in Linus' tree.
> > >>>> If you boot with one CPU does it hang? It looks like secondary CPUs
> > >>>> aren't getting interrupts but I'm not sure why. Maybe you can try this
> > >>>> patch and/or put some prints in the timer interrupt handler to see if
> > >>>> interrupts are firing on secondary CPUs.
> > >>> Your proposed patch does not seem to make a difference, but adding
> > >>> 'maxcpus=1' to the kernel command line makes the system boot.
> > >> Hmm I guess that doesn't really confirm much because TWD doesn't
> > >> register itself on maxcpus=1 systems, so it's the same as removing the
> > >> node from DT. Probably easier to put a printk in the interrupt handler
> > >> and confirm that you're receiving interrupts on secondary CPUs.
> > > Turns out it does work when I disable Zynq's cpuidle driver. I think I
> > > can blame that driver.
> > >
> > 
> > Hmm.. Perhaps the arm_global_timer driver also needs FEAT_C3_STOP added
> > to it. Do you know if that timer is reset during low power modes?
> 
> Our cpudidle driver is not powering off anything, AFAIK. I think it just
> executes 'wfi' on the CPU. I don't know how the timer core handles it,
> but I'd expect the CPU should find the timer just a it was left before
> entering idle (well, the timer continues to run I assume, but other than
> that).
> I'll do some debugging and see if I can find out what exactly causes the
> hang.

So, what I found:
The Zynq cpuidle driver provides two idle states, which are both
basically just ARM wfi states. But the second one set's these flags:
	.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_TIMER_STOP,

I don't know what these flags cause in detail. But the
CPUIDLE_FLAG_TIMER_STOP seemed suspicious, since wfi does not have any
effect on the timer. So, I removed that one and things are working.

I also tried the other approach: Leaving cpuidle as is and adding the
C3STOP flag to the global timer. That solves it too.

Does anybody know what the correct solution is?
In case the C3STOP flag is considered to be corret for the timer, I
could prepare a patch for that and bundle it with the one to enable the
timer for Zynq?

@Michal: What do we do about the cpuidle driver? If you asked me, we
should rip out the second state completely. We have it as disabled
placeholder in our vendor tree and it seems to break things having it
enabled in mainline.


	S?ren




From linus.walleij at linaro.org  Mon Jul 22 18:43:35 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Jul 2013 00:43:35 +0200
Subject: [PATCH 1/4] pinctrl: Remove duplicate code in
 pinctrl_pm_select_state functions
In-Reply-To: <20130718151504.30990.96819.stgit@localhost>
References: <20130718151213.30990.45828.stgit@localhost>
 <20130718151504.30990.96819.stgit@localhost>
Message-ID: <CACRpkdYbXEPmHwzGMwJ9e-VEJsOumYboGdQcPHqbq87FNL3fBw@mail.gmail.com>

On Thu, Jul 18, 2013 at 5:15 PM, Tony Lindgren <tony at atomide.com> wrote:

> There's no need to duplicate essentially the same functions. Let's
> introduce static int pinctrl_pm_select_state() and make the other
> related functions call that.
>
> This allows us to add support later on for multiple active states,
> and more optimized dynamic remuxing.
>
> Note that we still need to export the various pinctrl_pm_select
> functions as we want to keep struct pinctrl_state private to the
> pinctrl code, and cannot replace those with inline functions.
>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: Stephen Warren <swarren at wwwdotorg.org>
> Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>

Aha that is how to do it. Stephen complained about it earlier
but I couldn't come up with a good enough refactoring.

Patch applied.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Mon Jul 22 18:54:38 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Jul 2013 00:54:38 +0200
Subject: [PATCH 2/4] pinctrl: Allow pinctrl to have multiple active states
In-Reply-To: <20130718151507.30990.67174.stgit@localhost>
References: <20130718151213.30990.45828.stgit@localhost>
 <20130718151507.30990.67174.stgit@localhost>
Message-ID: <CACRpkdY5-OFN4YQywPj06jkf493BhwgJGMEnmKmbovTh+co2Yg@mail.gmail.com>

On Thu, Jul 18, 2013 at 5:15 PM, Tony Lindgren <tony at atomide.com> wrote:

> It's quite common that we need to dynamically change some pins for a
> device for runtime PM, or toggle a pin between rx and tx. Changing all

What does "change" mean above?

Please reword to "remux" if that is what is meant.

> the pins for a device is not efficient way of doing it.
>
> So let's allow setting up multiple active states for pinctrl.

Do you mean multiple default states?

I have a hard time understanding so please help me out :-/

> Currently
> we only need PINCTRL_STATIC and PINCTRL_DYNAMIC, where PINCTRL_STATIC
> covers the current default pins, and PINCTRL_DYNAMIC holds the dynamic
> pins that need to be toggled.

Toggled when?

When changing state to another one? Any other state? Or back to
this state? Sorry not following ... this needs to be more verbose.

>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: Grygorii Strashko <grygorii.strashko at ti.com>
> Cc: Stephen Warren <swarren at wwwdotorg.org>
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---
>  drivers/pinctrl/core.c |   18 ++++++++++--------
>  drivers/pinctrl/core.h |   10 ++++++++--
>  2 files changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> index a97b717..c9b709b 100644
> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -885,7 +885,8 @@ static void pinctrl_free(struct pinctrl *p, bool inlist)
>         mutex_lock(&pinctrl_list_mutex);
>         list_for_each_entry_safe(state, n1, &p->states, node) {
>                 list_for_each_entry_safe(setting, n2, &state->settings, node) {
> -                       pinctrl_free_setting(state == p->state, setting);
> +                       pinctrl_free_setting(state == p->state[PINCTRL_STATIC],
> +                                            setting);
>                         list_del(&setting->node);
>                         kfree(setting);
>                 }
> @@ -955,13 +956,13 @@ EXPORT_SYMBOL_GPL(pinctrl_lookup_state);
>  int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
>  {
>         struct pinctrl_setting *setting, *setting2;
> -       struct pinctrl_state *old_state = p->state;
> +       struct pinctrl_state *old_state = p->state[PINCTRL_STATIC];
>         int ret;
>
> -       if (p->state == state)
> +       if (old_state == state)
>                 return 0;
>
> -       if (p->state) {
> +       if (old_state) {
>                 /*
>                  * The set of groups with a mux configuration in the old state
>                  * may not be identical to the set of groups with a mux setting
> @@ -971,7 +972,7 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
>                  * but not in the new state, this code puts that group into a
>                  * safe/disabled state.
>                  */
> -               list_for_each_entry(setting, &p->state->settings, node) {
> +               list_for_each_entry(setting, &old_state->settings, node) {
>                         bool found = false;
>                         if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
>                                 continue;
> @@ -989,7 +990,7 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
>                 }
>         }
>
> -       p->state = NULL;
> +       p->state[PINCTRL_STATIC] = NULL;
>
>         /* Apply all the settings for the new state */
>         list_for_each_entry(setting, &state->settings, node) {
> @@ -1011,7 +1012,7 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
>                 }
>         }
>
> -       p->state = state;
> +       p->state[PINCTRL_STATIC] = state;
>
>         return 0;
>
> @@ -1492,7 +1493,8 @@ static int pinctrl_show(struct seq_file *s, void *what)
>         list_for_each_entry(p, &pinctrl_list, node) {
>                 seq_printf(s, "device: %s current state: %s\n",
>                            dev_name(p->dev),
> -                          p->state ? p->state->name : "none");
> +                          p->state[PINCTRL_STATIC] ?
> +                          p->state[PINCTRL_STATIC]->name : "none");
>
>                 list_for_each_entry(state, &p->states, node) {
>                         seq_printf(s, "  state: %s\n", state->name);
> diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
> index 75476b3..ac5a269 100644
> --- a/drivers/pinctrl/core.h
> +++ b/drivers/pinctrl/core.h
> @@ -53,12 +53,18 @@ struct pinctrl_dev {
>  #endif
>  };
>
> +enum pinctrl_states {
> +       PINCTRL_STATIC,
> +       PINCTRL_DYNAMIC,
> +       PINCTRL_NR_STATES,
> +};

This needs some very precise kerneldoc so it is chrystal clear what these
states are all about. "pinctrl_states" is not a good name for this enum,
please find some more precise name, because we have functions
with names like pinctrl_select_state() which is not related to this.

Is this substates or?

> +
>  /**
>   * struct pinctrl - per-device pin control state holder
>   * @node: global list node
>   * @dev: the device using this pin control handle
>   * @states: a list of states for this device
> - * @state: the current state
> + * @state: the current state(s)

How can more than one state be the current state? Sorry I don't get this.
This needs to be more precise I think.

>   * @dt_maps: the mapping table chunks dynamically parsed from device tree for
>   *     this device, if any
>   * @users: reference count
> @@ -67,7 +73,7 @@ struct pinctrl {
>         struct list_head node;
>         struct device *dev;
>         struct list_head states;
> -       struct pinctrl_state *state;
> +       struct pinctrl_state *state[PINCTRL_NR_STATES];
>         struct list_head dt_maps;
>         struct kref users;
>  };

Yours,
Linus Walleij


From linus.walleij at linaro.org  Mon Jul 22 19:07:57 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Jul 2013 01:07:57 +0200
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130716090536.5541.36289.stgit@localhost>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
Message-ID: <CACRpkdY6-f1DKfPDfCpYAX9weXMtB7koJ3VwkRgHGm_MzgFawQ@mail.gmail.com>

On Tue, Jul 16, 2013 at 11:05 AM, Tony Lindgren <tony at atomide.com> wrote:

> To toggle dynamic states, let's add the optional active state in
> addition to the static default state. Then if the optional active
> state is defined, we can require that idle and sleep states cover
> the same pingroups as the active state.

OK...

> Then let's add pinctrl_check_dynamic() and pinctrl_select_dynamic()
> to use instead of pinctrl_select() to avoid breaking existing users.
>
> With pinctrl_check_dynamic() we can check that idle and sleep states
> match the active state for pingroups during init, and don't need to
> do it during runtime.

I do not understand why this complexity need to be exposed outside
of the subsystem.

pinctrl_select_state() and the PM accessors are enough IMO. Why
should say a driver care about whether it is dynamic or not?

Surely the checking and different paths for static/dynamic configurations
can be an intrinsic detail of the pinctrl subsystem, by adding flags and
members to private structs like struct pinctrl itself in worst case.

So I'm not buying into this, it looks like it is making things complicated
for consumers outside the subsystem for no reason.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Mon Jul 22 19:15:13 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Jul 2013 01:15:13 +0200
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <51E98D89.9050407@wwwdotorg.org>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
 <51E70B5D.6030802@wwwdotorg.org>
 <20130718073638.GP7656@atomide.com>
 <51E84180.6080902@wwwdotorg.org>
 <20130719073957.GZ7656@atomide.com> <51E91516.2040301@ti.com>
 <51E98D89.9050407@wwwdotorg.org>
Message-ID: <CACRpkdbHj8R-ZFa2FB-pxcvgBRYH=1KKGNEbWieAnSZSv5LHaQ@mail.gmail.com>

On Fri, Jul 19, 2013 at 9:03 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/19/2013 04:29 AM, Grygorii Strashko wrote:

>> First of all, I'd like to mention that these patches do *not* connect
>> pinctrl to PM runtime, so until driver will call pinctrl_select_state()
>> or pinctrl_pm_select_*() there will be no pins state changes.
>
> Isn't the whole point of the pinctrl_pm_select*() APIs to eventually be
> called automatically by the runtime PM core,

Nah I had no such complete ambitions, just factoring around.

There are examples, such as deactivating a TTY from userspace,
that should result in the pins going to sleep while it may have nothing
to do with runtime PM.

> so that we don't need to
> write code to do this in every single driver, just like we moved the
> call to pinctrl_select_state(default) into the device core so that we
> didn't have to make every device do that manually?

I am pretty convinced that if this dynamic muxing stuff shall be
implemented, it should be a pinctrl subsystem intrinsic optimization
detail and should not be exposed to the outside with all these extra
functions at all. It looks overly complicated to me.

Yours,
Linus Walleij


From cavokz at gmail.com  Mon Jul 22 19:44:58 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Tue, 23 Jul 2013 01:44:58 +0200
Subject: [PATCH 2/5] ARM: bcm4760: Add system timer
In-Reply-To: <201307211014.21161.arnd@arndb.de>
References: <20130721002320.730568671@gmail.com>
 <20130721002713.813400062@gmail.com>
 <201307211014.21161.arnd@arndb.de>
Message-ID: <20130722234458.GB6665@glitch>

On Sun, Jul 21, 2013 at 10:14:20AM +0200, Arnd Bergmann wrote:
> +Daniel Lezcano
> 
> On Sunday 21 July 2013, Domenico Andreoli wrote:
> 
> > Index: b/Documentation/devicetree/bindings/timer/brcm,bcm4760-system-timer.txt
> > ===================================================================
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/timer/brcm,bcm4760-system-timer.txt
> > @@ -0,0 +1,23 @@
> > +Broadcom BCM4760 System Timer device tree bindings
> > +--------------------------------------------------
> > +
> > +The BCM4760 Timer peripheral provides either two or four 32-bit timer
> > +channels. Three timer blocks are available at 0xba000, 0xbb000 and
> > +0xd1000. The first two provide four channels, the last (in the AON -
> > +Always ON power domain) provides only two.
> > +
> > +Required properties:
> > +
> > +- compatible : should be "brcm,bcm4760-system-timer"
> > +- reg : Specifies base physical address and size of the registers.
> > +- interrupts : A list of 2 or 4 interrupt sinks; one per timer channel.
> > +- clock-frequency : The frequency of the clock that drives the counter, in Hz.
> 
> I think the current consensus is that if you have a clock driver (as added in
> patch 4), you should use a 'clocks' reference and clk_get_rate() to find the
> frequency rather than an explicit clock-frequency property.

This frequency can be either 32KHz or 24MHz (currently only 24MHz is
accepted) and is selected flipping bit TIMER_CTRL_CLK2 in the timer's control
register. It depends somehow on the pclk but I don't know the details.

I'm not sure a fake fixed-rate clock is needed here. Do you still think
I should add it? 

Domenico

> 
> I have no comments on the driver, the rest is quoted so Daniel can find it
> more easily.
> 
> 	Arnd
> 
> > +Example:
> > +
> > +timer at ba000 {
> > +	compatible = "brcm,bcm4760-system-timer";
> > +	reg = <0xba000 0x1000>;
> > +	interrupts = <4>, <11>;
> > +	clock-frequency = <24000000>;
> > +};
> > Index: b/arch/arm/boot/dts/bcm4760.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/bcm4760.dtsi
> > +++ b/arch/arm/boot/dts/bcm4760.dtsi
> > @@ -10,6 +10,14 @@
> >  		#size-cells = <1>;
> >  		ranges;
> >  
> > +		timer at ba000 {
> > +			compatible = "brcm,bcm4760-system-timer";
> > +			reg = <0xba000 0x1000>;
> > +			interrupt-parent = <&vic0>;
> > +			interrupts = <4>, <11>;
> > +			clock-frequency = <24000000>;
> > +		};
> > +
> >  		vic0: interrupt-controller at 80000 {
> >  			compatible = "brcm,bcm4760-pl192", "arm,pl192-vic", "arm,primecell";
> >  			reg = <0x80000 0x1000>;
> > Index: b/drivers/clocksource/Makefile
> > ===================================================================
> > --- a/drivers/clocksource/Makefile
> > +++ b/drivers/clocksource/Makefile
> > @@ -17,6 +17,7 @@ obj-$(CONFIG_CLKSRC_DBX500_PRCMU)	+= clk
> >  obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
> >  obj-$(CONFIG_ORION_TIMER)	+= time-orion.o
> >  obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
> > +obj-$(CONFIG_ARCH_BCM4760)	+= bcm4760_timer.o
> >  obj-$(CONFIG_ARCH_MARCO)	+= timer-marco.o
> >  obj-$(CONFIG_ARCH_MXS)		+= mxs_timer.o
> >  obj-$(CONFIG_ARCH_PRIMA2)	+= timer-prima2.o
> > Index: b/drivers/clocksource/bcm4760_timer.c
> > ===================================================================
> > --- /dev/null
> > +++ b/drivers/clocksource/bcm4760_timer.c
> > @@ -0,0 +1,170 @@
> > +/*
> > + * Broadcom BCM4760 based ARM11 SoCs system timer
> > + *
> > + * Copyright (C) 2012 Domenico Andreoli <domenico.andreoli at linux.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This 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.
> > + */
> > +
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/slab.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/clockchips.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/of_platform.h>
> > +
> > +#define TIMER_LOAD_OFFSET          0x00          /* load */
> > +#define TIMER_VALUE_OFFSET         0x04          /* value */
> > +#define TIMER_CONTROL_OFFSET       0x08          /* control */
> > +#define TIMER_INTCLR_OFFSET        0x0c          /* interrupt clear */
> > +#define TIMER_RIS_OFFSET           0x10          /* raw interrupt */
> > +#define TIMER_MIS_OFFSET           0x14          /* masked interrupt status */
> > +#define TIMER_BGLOAD_OFFSET        0x18          /* background load */
> > +
> > +#define TIMER_CTRL_ONESHOTMODE     BIT(0)        /* One shot mode */
> > +#define TIMER_CTRL_32BIT           BIT(1)        /* 32-bit counter mode */
> > +#define TIMER_CTRL_IE              BIT(5)        /* Interrupt enable */
> > +#define TIMER_CTRL_PERIODIC        BIT(6)        /* Periodic mode */
> > +#define TIMER_CTRL_EN              BIT(7)        /* Timer enable */
> > +#define TIMER_CTRL_CLK2            BIT(9)        /* Clock 2 selected */
> > +#define TIMER_CTRL_PREBY16         (1 << 2)      /* prescale divide by 16 */
> > +#define TIMER_CTRL_PREBY256        (2 << 2)      /* prescale divide by 256 */
> > +
> > +struct bcm4760_timer {
> > +	void __iomem *base;
> > +	struct clock_event_device evt;
> > +	struct irqaction act;
> > +};
> > +
> > +static inline void __iomem *to_load(struct bcm4760_timer *timer)
> > +{
> > +	return timer->base + TIMER_LOAD_OFFSET;
> > +}
> > +
> > +static inline void __iomem *to_control(struct bcm4760_timer *timer)
> > +{
> > +	return timer->base + TIMER_CONTROL_OFFSET;
> > +}
> > +
> > +static inline void __iomem *to_intclr(struct bcm4760_timer *timer)
> > +{
> > +	return timer->base + TIMER_INTCLR_OFFSET;
> > +}
> > +
> > +static inline void __iomem *to_ris(struct bcm4760_timer *timer)
> > +{
> > +	return timer->base + TIMER_RIS_OFFSET;
> > +}
> > +
> > +static inline void __iomem *to_mis(struct bcm4760_timer *timer)
> > +{
> > +	return timer->base + TIMER_MIS_OFFSET;
> > +}
> > +
> > +static void bcm4760_timer_set_mode(enum clock_event_mode mode,
> > +	struct clock_event_device *evt_dev)
> > +{
> > +	struct bcm4760_timer *timer;
> > +	u32 val;
> > +
> > +	timer = container_of(evt_dev, struct bcm4760_timer, evt);
> > +	val = TIMER_CTRL_CLK2 | TIMER_CTRL_32BIT |
> > +	      TIMER_CTRL_IE | TIMER_CTRL_EN;
> > +
> > +	switch (mode) {
> > +	case CLOCK_EVT_MODE_ONESHOT:
> > +		writel(val | TIMER_CTRL_ONESHOTMODE, to_control(timer));
> > +		break;
> > +	case CLOCK_EVT_MODE_RESUME:
> > +	case CLOCK_EVT_MODE_SHUTDOWN:
> > +		break;
> > +	default:
> > +		WARN(1, "%s: unhandled event mode %d\n", __func__, mode);
> > +		break;
> > +	}
> > +}
> > +
> > +static int bcm4760_timer_set_next_event(unsigned long event,
> > +	struct clock_event_device *evt_dev)
> > +{
> > +	struct bcm4760_timer *timer;
> > +
> > +	timer = container_of(evt_dev, struct bcm4760_timer, evt);
> > +	writel(event, to_load(timer));
> > +	return 0;
> > +}
> > +
> > +static irqreturn_t bcm4760_timer_interrupt(int irq, void *dev_id)
> > +{
> > +	struct bcm4760_timer *timer = dev_id;
> > +	void (*event_handler)(struct clock_event_device *);
> > +
> > +	/* check the (masked) interrupt status */
> > +	if (!readl_relaxed(to_mis(timer)))
> > +		return IRQ_NONE;
> > +
> > +	/* clear the timer interrupt */
> > +	writel_relaxed(1, to_intclr(timer));
> > +
> > +	event_handler = ACCESS_ONCE(timer->evt.event_handler);
> > +	if (event_handler)
> > +		event_handler(&timer->evt);
> > +
> > +	return IRQ_HANDLED;
> > +}
> > +
> > +static void __init bcm4760_init_time(struct device_node *node)
> > +{
> > +	void __iomem *base;
> > +	u32 freq;
> > +	int irq;
> > +	struct bcm4760_timer *timer;
> > +
> > +	base = of_iomap(node, 0);
> > +	if (!base)
> > +		panic("Can't remap timer registers");
> > +
> > +	if (of_property_read_u32(node, "clock-frequency", &freq))
> > +		panic("Can't read timer frequency");
> > +
> > +	/* TODO allow other frequences by using pre-scaling parameters */
> > +	if (freq != 24000000)
> > +		panic("Invalid timer frequency");
> > +
> > +	timer = kzalloc(sizeof(*timer), GFP_KERNEL);
> > +	if (!timer)
> > +		panic("Can't allocate timer struct\n");
> > +
> > +	irq = irq_of_parse_and_map(node, 0);
> > +	if (irq <= 0)
> > +		panic("Can't parse timer IRQ");
> > +
> > +	timer->base = base;
> > +	timer->evt.name = node->name;
> > +	timer->evt.rating = 300;
> > +	timer->evt.features = CLOCK_EVT_FEAT_ONESHOT;
> > +	timer->evt.set_mode = bcm4760_timer_set_mode;
> > +	timer->evt.set_next_event = bcm4760_timer_set_next_event;
> > +	timer->evt.cpumask = cpumask_of(0);
> > +	timer->act.name = node->name;
> > +	timer->act.flags = IRQF_TIMER | IRQF_SHARED;
> > +	timer->act.dev_id = timer;
> > +	timer->act.handler = bcm4760_timer_interrupt;
> > +
> > +	if (setup_irq(irq, &timer->act))
> > +		panic("Can't set up timer IRQ\n");
> > +
> > +	clockevents_config_and_register(&timer->evt, freq, 0xf, 0xffffffff);
> > +}
> > +
> > +CLOCKSOURCE_OF_DECLARE(bcm4760, "brcm,bcm4760-system-timer", bcm4760_init_time);
> > 
> > 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From linus.walleij at linaro.org  Mon Jul 22 19:45:39 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Jul 2013 01:45:39 +0200
Subject: [PATCH] pinctrl: fix a memleak when freeing maps
Message-ID: <1374536739-18966-1-git-send-email-linus.walleij@linaro.org>

We forgot to free the node itself when free:ing a map.

Reported-by: xulinuxkernel <xulinuxkernel at gmail.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 5b272bf..2a00239 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1193,6 +1193,7 @@ void pinctrl_unregister_map(struct pinctrl_map const *map)
 	list_for_each_entry(maps_node, &pinctrl_maps, node) {
 		if (maps_node->maps == map) {
 			list_del(&maps_node->node);
+			kfree(maps_node);
 			mutex_unlock(&pinctrl_maps_mutex);
 			return;
 		}
-- 
1.8.1.4



From tomasz.figa at gmail.com  Mon Jul 22 19:49:17 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 01:49:17 +0200
Subject: [PATCH v2 0/8] Common Clock Framework support for Samsung S3C64xx
Message-ID: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>

This series is an attempt to move clock support on Samsung S3C64xx SoCs
to Common Clock Framework.

First, support for PLL types present on S3C64xx SoCs is added to Samsung
Common Clock Framework driver. Then the main clock driver for mentioned
SoCs is introduced. Further patches contain fixes for drivers to make them
compliant with CCF semantics, migration of platform code to use the new
clock driver and removal of old clock management code.

Depends on:
 - [PATCH v4 00/20] Samsung PWM support cleanup
   http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20856

On S3C6410-based Tiny6410 board (Mini6410-compatible):

Tested-by: Tomasz Figa <tomasz.figa at gmail.com>

For v1:

Acked-by: Mike Turquette <mturquette at linaro.org>

Changes since v1:
 - added patch for read-only muxes,
 - exported configurable muxes and dividers,
 - defined mout_syncmux as read-only mux,
 - in DT-enabled case fixed-clock binding is used to define external clocks.

Tomasz Figa (8):
  clk: mux: Add support for read-only muxes.
  clk: samsung: pll: Add support for PLL6552 and PLL6553
  clk: samsung: Add clock driver for S3C64xx SoCs
  ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros
  ARM: s3c64xx: dma: Use clk_prepare_enable/clk_disable_unprepare
  usb: host: ohci-s3c2410 Use clk_prepare_enable/clk_disable_unprepare
  ARM: s3c64xx: Migrate clock handling to Common Clock Framework
  ARM: s3c64xx: Remove old clock management code

 .../bindings/clock/samsung,s3c64xx-clock.txt       |   77 ++
 arch/arm/Kconfig                                   |    2 +-
 arch/arm/mach-s3c64xx/Makefile                     |    2 +-
 arch/arm/mach-s3c64xx/clock.c                      | 1007 --------------------
 arch/arm/mach-s3c64xx/common.c                     |   21 +-
 arch/arm/mach-s3c64xx/common.h                     |   12 +-
 arch/arm/mach-s3c64xx/dma.c                        |    4 +-
 arch/arm/mach-s3c64xx/include/mach/regs-clock.h    |  132 +--
 arch/arm/mach-s3c64xx/mach-anw6410.c               |    2 +-
 arch/arm/mach-s3c64xx/mach-crag6410.c              |    2 +-
 arch/arm/mach-s3c64xx/mach-hmt.c                   |    2 +-
 arch/arm/mach-s3c64xx/mach-mini6410.c              |    2 +-
 arch/arm/mach-s3c64xx/mach-ncp.c                   |    2 +-
 arch/arm/mach-s3c64xx/mach-smartq.c                |   11 +-
 arch/arm/mach-s3c64xx/mach-smdk6400.c              |    2 +-
 arch/arm/mach-s3c64xx/mach-smdk6410.c              |    2 +-
 arch/arm/mach-s3c64xx/pm.c                         |   21 -
 arch/arm/mach-s3c64xx/s3c6400.c                    |    6 -
 arch/arm/mach-s3c64xx/s3c6410.c                    |    7 -
 arch/arm/plat-samsung/include/plat/cpu.h           |    4 +
 drivers/clk/clk-mux.c                              |   10 +-
 drivers/clk/samsung/Makefile                       |    1 +
 drivers/clk/samsung/clk-pll.c                      |  160 ++++
 drivers/clk/samsung/clk-pll.h                      |    4 +
 drivers/clk/samsung/clk-s3c64xx.c                  |  465 +++++++++
 drivers/usb/host/ohci-s3c2410.c                    |    8 +-
 include/dt-bindings/clock/samsung,s3c64xx-clock.h  |  178 ++++
 include/linux/clk-provider.h                       |    2 +
 28 files changed, 943 insertions(+), 1205 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
 delete mode 100644 arch/arm/mach-s3c64xx/clock.c
 create mode 100644 drivers/clk/samsung/clk-s3c64xx.c
 create mode 100644 include/dt-bindings/clock/samsung,s3c64xx-clock.h

-- 
1.8.3.2



From tomasz.figa at gmail.com  Mon Jul 22 19:49:18 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 01:49:18 +0200
Subject: [PATCH v2 1/8] clk: mux: Add support for read-only muxes.
In-Reply-To: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374536965-3545-2-git-send-email-tomasz.figa@gmail.com>

Some platforms have read-only clock muxes that are preconfigured at
reset and cannot be changed at runtime. This patch extends mux clock
driver to allow handling such read-only muxes by adding new
CLK_MUX_READ_ONLY mux flag.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/clk/clk-mux.c        | 10 +++++++++-
 include/linux/clk-provider.h |  2 ++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 614444c..92f1a1b 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -107,6 +107,11 @@ const struct clk_ops clk_mux_ops = {
 };
 EXPORT_SYMBOL_GPL(clk_mux_ops);
 
+const struct clk_ops clk_mux_ro_ops = {
+	.get_parent = clk_mux_get_parent,
+};
+EXPORT_SYMBOL_GPL(clk_mux_ro_ops);
+
 struct clk *clk_register_mux_table(struct device *dev, const char *name,
 		const char **parent_names, u8 num_parents, unsigned long flags,
 		void __iomem *reg, u8 shift, u32 mask,
@@ -133,7 +138,10 @@ struct clk *clk_register_mux_table(struct device *dev, const char *name,
 	}
 
 	init.name = name;
-	init.ops = &clk_mux_ops;
+	if (clk_mux_flags & CLK_MUX_READ_ONLY)
+		init.ops = &clk_mux_ro_ops;
+	else
+		init.ops = &clk_mux_ops;
 	init.flags = flags | CLK_IS_BASIC;
 	init.parent_names = parent_names;
 	init.num_parents = num_parents;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1ec14a7..9487b96 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -327,8 +327,10 @@ struct clk_mux {
 #define CLK_MUX_INDEX_ONE		BIT(0)
 #define CLK_MUX_INDEX_BIT		BIT(1)
 #define CLK_MUX_HIWORD_MASK		BIT(2)
+#define CLK_MUX_READ_ONLY	BIT(3) /* mux setting cannot be changed */
 
 extern const struct clk_ops clk_mux_ops;
+extern const struct clk_ops clk_mux_ro_ops;
 
 struct clk *clk_register_mux(struct device *dev, const char *name,
 		const char **parent_names, u8 num_parents, unsigned long flags,
-- 
1.8.3.2



From tomasz.figa at gmail.com  Mon Jul 22 19:49:21 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 01:49:21 +0200
Subject: [PATCH v2 4/8] ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros
In-Reply-To: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374536965-3545-5-git-send-email-tomasz.figa@gmail.com>

This patch adds soc_is_s3c6400() and soc_is_s3c6410() macros that allow
to distinguish between specific SoCs from s3c64xx series that is needed
to handle differences between them.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/plat-samsung/include/plat/cpu.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/plat-samsung/include/plat/cpu.h b/arch/arm/plat-samsung/include/plat/cpu.h
index 4fb1f03..335beb3 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -87,8 +87,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK)
 #endif
 
 #if defined(CONFIG_CPU_S3C6400) || defined(CONFIG_CPU_S3C6410)
+# define soc_is_s3c6400()	is_samsung_s3c6400()
+# define soc_is_s3c6410()	is_samsung_s3c6410()
 # define soc_is_s3c64xx()	(is_samsung_s3c6400() || is_samsung_s3c6410())
 #else
+# define soc_is_s3c6400()	0
+# define soc_is_s3c6410()	0
 # define soc_is_s3c64xx()	0
 #endif
 
-- 
1.8.3.2



From tomasz.figa at gmail.com  Mon Jul 22 19:49:19 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 01:49:19 +0200
Subject: [PATCH v2 2/8] clk: samsung: pll: Add support for PLL6552 and PLL6553
In-Reply-To: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374536965-3545-3-git-send-email-tomasz.figa@gmail.com>

This patch adds support for PLL6552 and PLL6553 PLLs present on Samsung
S3C64xx SoCs.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
Acked-by: Mike Turquette <mturquette at linaro.org>
---
 drivers/clk/samsung/clk-pll.c | 160 ++++++++++++++++++++++++++++++++++++++++++
 drivers/clk/samsung/clk-pll.h |   4 ++
 2 files changed, 164 insertions(+)

diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 362f12d..698e562 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -337,6 +337,166 @@ struct clk * __init samsung_clk_register_pll46xx(const char *name,
 }
 
 /*
+ * PLL6552 Clock Type
+ */
+
+#define PLL6552_LOCK_REG	0x00
+#define PLL6552_CON_REG		0x0c
+
+#define PLL6552_MDIV_MASK	0x3ff
+#define PLL6552_PDIV_MASK	0x3f
+#define PLL6552_SDIV_MASK	0x7
+#define PLL6552_MDIV_SHIFT	16
+#define PLL6552_PDIV_SHIFT	8
+#define PLL6552_SDIV_SHIFT	0
+
+struct samsung_clk_pll6552 {
+	struct clk_hw hw;
+	void __iomem *reg_base;
+};
+
+#define to_clk_pll6552(_hw) container_of(_hw, struct samsung_clk_pll6552, hw)
+
+static unsigned long samsung_pll6552_recalc_rate(struct clk_hw *hw,
+						unsigned long parent_rate)
+{
+	struct samsung_clk_pll6552 *pll = to_clk_pll6552(hw);
+	u32 mdiv, pdiv, sdiv, pll_con;
+	u64 fvco = parent_rate;
+
+	pll_con = __raw_readl(pll->reg_base + PLL6552_CON_REG);
+	mdiv = (pll_con >> PLL6552_MDIV_SHIFT) & PLL6552_MDIV_MASK;
+	pdiv = (pll_con >> PLL6552_PDIV_SHIFT) & PLL6552_PDIV_MASK;
+	sdiv = (pll_con >> PLL6552_SDIV_SHIFT) & PLL6552_SDIV_MASK;
+
+	fvco *= mdiv;
+	do_div(fvco, (pdiv << sdiv));
+
+	return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6552_clk_ops = {
+	.recalc_rate = samsung_pll6552_recalc_rate,
+};
+
+struct clk * __init samsung_clk_register_pll6552(const char *name,
+					const char *pname, void __iomem *base)
+{
+	struct samsung_clk_pll6552 *pll;
+	struct clk *clk;
+	struct clk_init_data init;
+
+	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+	if (!pll) {
+		pr_err("%s: could not allocate pll clk %s\n", __func__, name);
+		return NULL;
+	}
+
+	init.name = name;
+	init.ops = &samsung_pll6552_clk_ops;
+	init.parent_names = &pname;
+	init.num_parents = 1;
+
+	pll->hw.init = &init;
+	pll->reg_base = base;
+
+	clk = clk_register(NULL, &pll->hw);
+	if (IS_ERR(clk)) {
+		pr_err("%s: failed to register pll clock %s\n", __func__,
+				name);
+		kfree(pll);
+	}
+
+	if (clk_register_clkdev(clk, name, NULL))
+		pr_err("%s: failed to register lookup for %s", __func__, name);
+
+	return clk;
+}
+
+/*
+ * PLL6553 Clock Type
+ */
+
+#define PLL6553_LOCK_REG	0x00
+#define PLL6553_CON0_REG	0x0c
+#define PLL6553_CON1_REG	0x10
+
+#define PLL6553_MDIV_MASK	0xff
+#define PLL6553_PDIV_MASK	0x3f
+#define PLL6553_SDIV_MASK	0x7
+#define PLL6553_KDIV_MASK	0xffff
+#define PLL6553_MDIV_SHIFT	16
+#define PLL6553_PDIV_SHIFT	8
+#define PLL6553_SDIV_SHIFT	0
+#define PLL6553_KDIV_SHIFT	0
+
+struct samsung_clk_pll6553 {
+	struct clk_hw hw;
+	void __iomem *reg_base;
+};
+
+#define to_clk_pll6553(_hw) container_of(_hw, struct samsung_clk_pll6553, hw)
+
+static unsigned long samsung_pll6553_recalc_rate(struct clk_hw *hw,
+						unsigned long parent_rate)
+{
+	struct samsung_clk_pll6553 *pll = to_clk_pll6553(hw);
+	u32 mdiv, pdiv, sdiv, kdiv, pll_con0, pll_con1;
+	u64 fvco = parent_rate;
+
+	pll_con0 = __raw_readl(pll->reg_base + PLL6553_CON0_REG);
+	pll_con1 = __raw_readl(pll->reg_base + PLL6553_CON1_REG);
+	mdiv = (pll_con0 >> PLL6553_MDIV_SHIFT) & PLL6553_MDIV_MASK;
+	pdiv = (pll_con0 >> PLL6553_PDIV_SHIFT) & PLL6553_PDIV_MASK;
+	sdiv = (pll_con0 >> PLL6553_SDIV_SHIFT) & PLL6553_SDIV_MASK;
+	kdiv = (pll_con1 >> PLL6553_KDIV_SHIFT) & PLL6553_KDIV_MASK;
+
+	fvco *= (mdiv << 16) + kdiv;
+	do_div(fvco, (pdiv << sdiv));
+	fvco >>= 16;
+
+	return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6553_clk_ops = {
+	.recalc_rate = samsung_pll6553_recalc_rate,
+};
+
+struct clk * __init samsung_clk_register_pll6553(const char *name,
+					const char *pname, void __iomem *base)
+{
+	struct samsung_clk_pll6553 *pll;
+	struct clk *clk;
+	struct clk_init_data init;
+
+	pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+	if (!pll) {
+		pr_err("%s: could not allocate pll clk %s\n", __func__, name);
+		return NULL;
+	}
+
+	init.name = name;
+	init.ops = &samsung_pll6553_clk_ops;
+	init.parent_names = &pname;
+	init.num_parents = 1;
+
+	pll->hw.init = &init;
+	pll->reg_base = base;
+
+	clk = clk_register(NULL, &pll->hw);
+	if (IS_ERR(clk)) {
+		pr_err("%s: failed to register pll clock %s\n", __func__,
+				name);
+		kfree(pll);
+	}
+
+	if (clk_register_clkdev(clk, name, NULL))
+		pr_err("%s: failed to register lookup for %s", __func__, name);
+
+	return clk;
+}
+
+/*
  * PLL2550x Clock Type
  */
 
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
index f33786e..1d68a68 100644
--- a/drivers/clk/samsung/clk-pll.h
+++ b/drivers/clk/samsung/clk-pll.h
@@ -34,6 +34,10 @@ extern struct clk * __init samsung_clk_register_pll45xx(const char *name,
 extern struct clk * __init samsung_clk_register_pll46xx(const char *name,
 			const char *pname, const void __iomem *con_reg,
 			enum pll46xx_type type);
+extern struct clk *samsung_clk_register_pll6552(const char *name,
+			const char *pname, void __iomem *base);
+extern struct clk *samsung_clk_register_pll6553(const char *name,
+			const char *pname, void __iomem *base);
 extern struct clk * __init samsung_clk_register_pll2550x(const char *name,
 			const char *pname, const void __iomem *reg_base,
 			const unsigned long offset);
-- 
1.8.3.2



From tomasz.figa at gmail.com  Mon Jul 22 19:49:23 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 01:49:23 +0200
Subject: [PATCH v2 6/8] usb: host: ohci-s3c2410 Use
 clk_prepare_enable/clk_disable_unprepare
In-Reply-To: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374536965-3545-7-git-send-email-tomasz.figa@gmail.com>

This patch modifies the ohci-s3c2410 driver to prepare and unprepare
clocks in addition to enabling and disabling, since it is required
by common clock framework.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 drivers/usb/host/ohci-s3c2410.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index e125770..db096bf 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -47,10 +47,10 @@ static void s3c2410_start_hc(struct platform_device *dev, struct usb_hcd *hcd)
 
 	dev_dbg(&dev->dev, "s3c2410_start_hc:\n");
 
-	clk_enable(usb_clk);
+	clk_prepare_enable(usb_clk);
 	mdelay(2);			/* let the bus clock stabilise */
 
-	clk_enable(clk);
+	clk_prepare_enable(clk);
 
 	if (info != NULL) {
 		info->hcd	= hcd;
@@ -75,8 +75,8 @@ static void s3c2410_stop_hc(struct platform_device *dev)
 			(info->enable_oc)(info, 0);
 	}
 
-	clk_disable(clk);
-	clk_disable(usb_clk);
+	clk_disable_unprepare(clk);
+	clk_disable_unprepare(usb_clk);
 }
 
 /* ohci_s3c2410_hub_status_data
-- 
1.8.3.2



From tomasz.figa at gmail.com  Mon Jul 22 19:49:22 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 01:49:22 +0200
Subject: [PATCH v2 5/8] ARM: s3c64xx: dma: Use
 clk_prepare_enable/clk_disable_unprepare
In-Reply-To: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374536965-3545-6-git-send-email-tomasz.figa@gmail.com>

This patch modifies s3c64xx DMA driver to prepare and unprepare clocks
in addition to enableind and disabling, since it is required by common
clock framework.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/mach-s3c64xx/dma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/dma.c b/arch/arm/mach-s3c64xx/dma.c
index 759846c..c511dfa 100644
--- a/arch/arm/mach-s3c64xx/dma.c
+++ b/arch/arm/mach-s3c64xx/dma.c
@@ -677,7 +677,7 @@ static int s3c64xx_dma_init1(int chno, enum dma_ch chbase,
 		goto err_map;
 	}
 
-	clk_enable(dmac->clk);
+	clk_prepare_enable(dmac->clk);
 
 	dmac->regs = regs;
 	dmac->chanbase = chbase;
@@ -711,7 +711,7 @@ static int s3c64xx_dma_init1(int chno, enum dma_ch chbase,
 	return 0;
 
 err_clk:
-	clk_disable(dmac->clk);
+	clk_disable_unprepare(dmac->clk);
 	clk_put(dmac->clk);
 err_map:
 	iounmap(regs);
-- 
1.8.3.2



From tomasz.figa at gmail.com  Mon Jul 22 19:49:24 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 01:49:24 +0200
Subject: [PATCH v2 7/8] ARM: s3c64xx: Migrate clock handling to Common Clock
 Framework
In-Reply-To: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374536965-3545-8-git-send-email-tomasz.figa@gmail.com>

This patch migrates the s3c64xx platform to use the new clock driver
using Common Clock Framework.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/Kconfig                      |  2 +-
 arch/arm/mach-s3c64xx/Makefile        |  2 +-
 arch/arm/mach-s3c64xx/common.c        | 21 +++++++++++++++++----
 arch/arm/mach-s3c64xx/common.h        | 10 +++++-----
 arch/arm/mach-s3c64xx/mach-anw6410.c  |  2 +-
 arch/arm/mach-s3c64xx/mach-crag6410.c |  2 +-
 arch/arm/mach-s3c64xx/mach-hmt.c      |  2 +-
 arch/arm/mach-s3c64xx/mach-mini6410.c |  2 +-
 arch/arm/mach-s3c64xx/mach-ncp.c      |  2 +-
 arch/arm/mach-s3c64xx/mach-smartq.c   | 11 ++---------
 arch/arm/mach-s3c64xx/mach-smdk6400.c |  2 +-
 arch/arm/mach-s3c64xx/mach-smdk6410.c |  2 +-
 arch/arm/mach-s3c64xx/s3c6400.c       |  6 ------
 arch/arm/mach-s3c64xx/s3c6410.c       |  7 -------
 drivers/clk/samsung/Makefile          |  2 --
 15 files changed, 33 insertions(+), 42 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fa7ffca..cfa7e59 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -724,6 +724,7 @@ config ARCH_S3C64XX
 	select ARM_VIC
 	select CLKDEV_LOOKUP
 	select CLKSRC_SAMSUNG_PWM
+	select COMMON_CLK
 	select CPU_V6
 	select GENERIC_CLOCKEVENTS
 	select GPIO_SAMSUNG
@@ -737,7 +738,6 @@ config ARCH_S3C64XX
 	select S3C_DEV_NAND
 	select S3C_GPIO_TRACK
 	select SAMSUNG_ATAGS
-	select SAMSUNG_CLKSRC
 	select SAMSUNG_GPIOLIB_4BIT
 	select SAMSUNG_WDT_RESET
 	select USB_ARCH_HAS_OHCI
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index 31d0c91..645a8fe 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -12,7 +12,7 @@ obj-				:=
 
 # Core
 
-obj-y				+= common.o clock.o
+obj-y				+= common.o
 
 # Core support
 
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 73d79cf..7d3cb58 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -17,6 +17,7 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/module.h>
+#include <linux/clk-provider.h>
 #include <linux/interrupt.h>
 #include <linux/ioport.h>
 #include <linux/serial_core.h>
@@ -38,7 +39,6 @@
 #include <mach/regs-gpio.h>
 
 #include <plat/cpu.h>
-#include <plat/clock.h>
 #include <plat/devs.h>
 #include <plat/pm.h>
 #include <plat/gpio-cfg.h>
@@ -50,6 +50,19 @@
 
 #include "common.h"
 
+/* External clock frequency */
+static unsigned long xtal_f = 12000000, xusbxti_f = 48000000;
+
+void __init s3c64xx_set_xtal_freq(unsigned long freq)
+{
+	xtal_f = freq;
+}
+
+void __init s3c64xx_set_xusbxti_freq(unsigned long freq)
+{
+	xusbxti_f = freq;
+}
+
 /* uart registration process */
 
 static void __init s3c64xx_init_uarts(struct s3c2410_uartcfg *cfg, int no)
@@ -67,7 +80,6 @@ static struct cpu_table cpu_ids[] __initdata = {
 		.idcode		= S3C6400_CPU_ID,
 		.idmask		= S3C64XX_CPU_MASK,
 		.map_io		= s3c6400_map_io,
-		.init_clocks	= s3c6400_init_clocks,
 		.init_uarts	= s3c64xx_init_uarts,
 		.init		= s3c6400_init,
 		.name		= name_s3c6400,
@@ -75,7 +87,6 @@ static struct cpu_table cpu_ids[] __initdata = {
 		.idcode		= S3C6410_CPU_ID,
 		.idmask		= S3C64XX_CPU_MASK,
 		.map_io		= s3c6410_map_io,
-		.init_clocks	= s3c6410_init_clocks,
 		.init_uarts	= s3c64xx_init_uarts,
 		.init		= s3c6410_init,
 		.name		= name_s3c6410,
@@ -213,8 +224,10 @@ void __init s3c64xx_init_irq(u32 vic0_valid, u32 vic1_valid)
 {
 	/*
 	 * FIXME: there is no better place to put this at the moment
-	 * (samsung_wdt_reset_init needs clocks)
+	 * (s3c64xx_clk_init needs ioremap and must happen before init_time
+	 * samsung_wdt_reset_init needs clocks)
 	 */
+	s3c64xx_clk_init(NULL, xtal_f, xusbxti_f, soc_is_s3c6400(), S3C_VA_SYS);
 	samsung_wdt_reset_init(S3C_VA_WATCHDOG);
 
 	printk(KERN_DEBUG "%s: initialising interrupts\n", __func__);
diff --git a/arch/arm/mach-s3c64xx/common.h b/arch/arm/mach-s3c64xx/common.h
index e8f990b..a2af0e1 100644
--- a/arch/arm/mach-s3c64xx/common.h
+++ b/arch/arm/mach-s3c64xx/common.h
@@ -22,18 +22,19 @@
 void s3c64xx_init_irq(u32 vic0, u32 vic1);
 void s3c64xx_init_io(struct map_desc *mach_desc, int size);
 
-void s3c64xx_register_clocks(unsigned long xtal, unsigned armclk_limit);
-void s3c64xx_setup_clocks(void);
-
 void s3c64xx_restart(enum reboot_mode mode, const char *cmd);
 void s3c64xx_init_late(void);
 
+void s3c64xx_clk_init(struct device_node *np, unsigned long xtal_f,
+	unsigned long xusbxti_f, bool is_s3c6400, void __iomem *reg_base);
+void s3c64xx_set_xtal_freq(unsigned long freq);
+void s3c64xx_set_xusbxti_freq(unsigned long freq);
+
 #ifdef CONFIG_CPU_S3C6400
 
 extern  int s3c6400_init(void);
 extern void s3c6400_init_irq(void);
 extern void s3c6400_map_io(void);
-extern void s3c6400_init_clocks(int xtal);
 
 #else
 #define s3c6400_init_clocks NULL
@@ -46,7 +47,6 @@ extern void s3c6400_init_clocks(int xtal);
 extern  int s3c6410_init(void);
 extern void s3c6410_init_irq(void);
 extern void s3c6410_map_io(void);
-extern void s3c6410_init_clocks(int xtal);
 
 #else
 #define s3c6410_init_clocks NULL
diff --git a/arch/arm/mach-s3c64xx/mach-anw6410.c b/arch/arm/mach-s3c64xx/mach-anw6410.c
index 35e3f54..d266dd5 100644
--- a/arch/arm/mach-s3c64xx/mach-anw6410.c
+++ b/arch/arm/mach-s3c64xx/mach-anw6410.c
@@ -207,7 +207,7 @@ static struct platform_device *anw6410_devices[] __initdata = {
 static void __init anw6410_map_io(void)
 {
 	s3c64xx_init_io(anw6410_iodesc, ARRAY_SIZE(anw6410_iodesc));
-	s3c24xx_init_clocks(12000000);
+	s3c64xx_set_xtal_freq(12000000);
 	s3c24xx_init_uarts(anw6410_uartcfgs, ARRAY_SIZE(anw6410_uartcfgs));
 	samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
 
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 28889cc..4d92e4d 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -743,7 +743,7 @@ static struct s3c2410_platform_i2c i2c1_pdata = {
 static void __init crag6410_map_io(void)
 {
 	s3c64xx_init_io(NULL, 0);
-	s3c24xx_init_clocks(12000000);
+	s3c64xx_set_xtal_freq(12000000);
 	s3c24xx_init_uarts(crag6410_uartcfgs, ARRAY_SIZE(crag6410_uartcfgs));
 	samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
 
diff --git a/arch/arm/mach-s3c64xx/mach-hmt.c b/arch/arm/mach-s3c64xx/mach-hmt.c
index f39569e..e806404 100644
--- a/arch/arm/mach-s3c64xx/mach-hmt.c
+++ b/arch/arm/mach-s3c64xx/mach-hmt.c
@@ -247,7 +247,7 @@ static struct platform_device *hmt_devices[] __initdata = {
 static void __init hmt_map_io(void)
 {
 	s3c64xx_init_io(hmt_iodesc, ARRAY_SIZE(hmt_iodesc));
-	s3c24xx_init_clocks(12000000);
+	s3c64xx_set_xtal_freq(12000000);
 	s3c24xx_init_uarts(hmt_uartcfgs, ARRAY_SIZE(hmt_uartcfgs));
 	samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
 }
diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c
index 87f406e..3cceda2 100644
--- a/arch/arm/mach-s3c64xx/mach-mini6410.c
+++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
@@ -231,7 +231,7 @@ static void __init mini6410_map_io(void)
 	u32 tmp;
 
 	s3c64xx_init_io(NULL, 0);
-	s3c24xx_init_clocks(12000000);
+	s3c64xx_set_xtal_freq(12000000);
 	s3c24xx_init_uarts(mini6410_uartcfgs, ARRAY_SIZE(mini6410_uartcfgs));
 	samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
 
diff --git a/arch/arm/mach-s3c64xx/mach-ncp.c b/arch/arm/mach-s3c64xx/mach-ncp.c
index 7e2c390..2067b0b 100644
--- a/arch/arm/mach-s3c64xx/mach-ncp.c
+++ b/arch/arm/mach-s3c64xx/mach-ncp.c
@@ -86,7 +86,7 @@ static struct map_desc ncp_iodesc[] __initdata = {};
 static void __init ncp_map_io(void)
 {
 	s3c64xx_init_io(ncp_iodesc, ARRAY_SIZE(ncp_iodesc));
-	s3c24xx_init_clocks(12000000);
+	s3c64xx_set_xtal_freq(12000000);
 	s3c24xx_init_uarts(ncp_uartcfgs, ARRAY_SIZE(ncp_uartcfgs));
 	samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
 }
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c b/arch/arm/mach-s3c64xx/mach-smartq.c
index 86d980b..0f47237 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -337,13 +337,6 @@ err:
 	return ret;
 }
 
-static int __init smartq_usb_otg_init(void)
-{
-	clk_xusbxti.rate = 12000000;
-
-	return 0;
-}
-
 static int __init smartq_wifi_init(void)
 {
 	int ret;
@@ -377,7 +370,8 @@ static struct map_desc smartq_iodesc[] __initdata = {};
 void __init smartq_map_io(void)
 {
 	s3c64xx_init_io(smartq_iodesc, ARRAY_SIZE(smartq_iodesc));
-	s3c24xx_init_clocks(12000000);
+	s3c64xx_set_xtal_freq(12000000);
+	s3c64xx_set_xusbxti_freq(12000000);
 	s3c24xx_init_uarts(smartq_uartcfgs, ARRAY_SIZE(smartq_uartcfgs));
 	samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
 
@@ -399,7 +393,6 @@ void __init smartq_machine_init(void)
 	WARN_ON(smartq_lcd_setup_gpio());
 	WARN_ON(smartq_power_off_init());
 	WARN_ON(smartq_usb_host_init());
-	WARN_ON(smartq_usb_otg_init());
 	WARN_ON(smartq_wifi_init());
 
 	platform_add_devices(smartq_devices, ARRAY_SIZE(smartq_devices));
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6400.c b/arch/arm/mach-s3c64xx/mach-smdk6400.c
index d70c084..27381cf 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6400.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6400.c
@@ -65,7 +65,7 @@ static struct map_desc smdk6400_iodesc[] = {};
 static void __init smdk6400_map_io(void)
 {
 	s3c64xx_init_io(smdk6400_iodesc, ARRAY_SIZE(smdk6400_iodesc));
-	s3c24xx_init_clocks(12000000);
+	s3c64xx_set_xtal_freq(12000000);
 	s3c24xx_init_uarts(smdk6400_uartcfgs, ARRAY_SIZE(smdk6400_uartcfgs));
 	samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
 }
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index d90b450..2a7b32c 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -634,7 +634,7 @@ static void __init smdk6410_map_io(void)
 	u32 tmp;
 
 	s3c64xx_init_io(smdk6410_iodesc, ARRAY_SIZE(smdk6410_iodesc));
-	s3c24xx_init_clocks(12000000);
+	s3c64xx_set_xtal_freq(12000000);
 	s3c24xx_init_uarts(smdk6410_uartcfgs, ARRAY_SIZE(smdk6410_uartcfgs));
 	samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
 
diff --git a/arch/arm/mach-s3c64xx/s3c6400.c b/arch/arm/mach-s3c64xx/s3c6400.c
index 4869714..331fe8e 100644
--- a/arch/arm/mach-s3c64xx/s3c6400.c
+++ b/arch/arm/mach-s3c64xx/s3c6400.c
@@ -58,12 +58,6 @@ void __init s3c6400_map_io(void)
 	s3c64xx_onenand1_setname("s3c6400-onenand");
 }
 
-void __init s3c6400_init_clocks(int xtal)
-{
-	s3c64xx_register_clocks(xtal, S3C6400_CLKDIV0_ARM_MASK);
-	s3c64xx_setup_clocks();
-}
-
 void __init s3c6400_init_irq(void)
 {
 	/* VIC0 does not have IRQS 5..7,
diff --git a/arch/arm/mach-s3c64xx/s3c6410.c b/arch/arm/mach-s3c64xx/s3c6410.c
index 31c29fd..7e6fa12 100644
--- a/arch/arm/mach-s3c64xx/s3c6410.c
+++ b/arch/arm/mach-s3c64xx/s3c6410.c
@@ -62,13 +62,6 @@ void __init s3c6410_map_io(void)
 	s3c_cfcon_setname("s3c64xx-pata");
 }
 
-void __init s3c6410_init_clocks(int xtal)
-{
-	printk(KERN_DEBUG "%s: initialising clocks\n", __func__);
-	s3c64xx_register_clocks(xtal, S3C6410_CLKDIV0_ARM_MASK);
-	s3c64xx_setup_clocks();
-}
-
 void __init s3c6410_init_irq(void)
 {
 	/* VIC0 is missing IRQ7, VIC1 is fully populated. */
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 3413380..8eb4799 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -8,6 +8,4 @@ obj-$(CONFIG_SOC_EXYNOS5250)	+= clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5420)	+= clk-exynos5420.o
 obj-$(CONFIG_SOC_EXYNOS5440)	+= clk-exynos5440.o
 obj-$(CONFIG_ARCH_EXYNOS)	+= clk-exynos-audss.o
-ifdef CONFIG_COMMON_CLK
 obj-$(CONFIG_ARCH_S3C64XX)	+= clk-s3c64xx.o
-endif
-- 
1.8.3.2



From tomasz.figa at gmail.com  Mon Jul 22 19:49:20 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 01:49:20 +0200
Subject: [PATCH v2 3/8] clk: samsung: Add clock driver for S3C64xx SoCs
In-Reply-To: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374536965-3545-4-git-send-email-tomasz.figa@gmail.com>

This patch adds new, Common Clock Framework-based clock driver for Samsung
S3C64xx SoCs. The driver is just added, without actually letting the
platforms use it yet, since this requires more intermediate steps.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
Acked-by: Mike Turquette <mturquette at linaro.org>
---
 .../bindings/clock/samsung,s3c64xx-clock.txt       |  77 ++++
 drivers/clk/samsung/Makefile                       |   3 +
 drivers/clk/samsung/clk-s3c64xx.c                  | 465 +++++++++++++++++++++
 include/dt-bindings/clock/samsung,s3c64xx-clock.h  | 178 ++++++++
 4 files changed, 723 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
 create mode 100644 drivers/clk/samsung/clk-s3c64xx.c
 create mode 100644 include/dt-bindings/clock/samsung,s3c64xx-clock.h

diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
new file mode 100644
index 0000000..fa171dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
@@ -0,0 +1,77 @@
+* Samsung S3C64xx Clock Controller
+
+The S3C64xx clock controller generates and supplies clock to various controllers
+within the SoC. The clock binding described here is applicable to all SoCs in
+the S3C64xx family.
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "samsung,s3c6400-clock" - controller compatible with S3C6400 SoC.
+  - "samsung,s3c6410-clock" - controller compatible with S3C6410 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Some of the clocks are available only
+on a particular S3C64xx SoC and this is specified where applicable.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/samsung,s3c64xx-clock.h header and can be used in device
+tree sources.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "fin_pll" - PLL input clock (xtal/extclk) - required,
+ - "xusbxti" - USB xtal - required,
+ - "iiscdclk0" - I2S0 codec clock - optional,
+ - "iiscdclk1" - I2S1 codec clock - optional,
+ - "iiscdclk2" - I2S2 codec clock - optional,
+ - "pcmcdclk0" - PCM0 codec clock - optional,
+ - "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410.
+
+Example: Clock controller node:
+
+	clock: clock-controller at 7e00f000 {
+		compatible = "samsung,s3c6410-clock";
+		reg = <0x7e00f000 0x1000>;
+		#clock-cells = <1>;
+	};
+
+Example: Required external clocks:
+
+	fin_pll: clock-fin-pll {
+		compatible = "fixed-clock";
+		clock-output-names = "fin_pll";
+		clock-frequency = <12000000>;
+		#clock-cells = <0>;
+	};
+
+	xusbxti: clock-xusbxti {
+		compatible = "fixed-clock";
+		clock-output-names = "xusbxti";
+		clock-frequency = <48000000>;
+		#clock-cells = <0>;
+	};
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller (refer to the standard clock bindings for information about
+  "clocks" and "clock-names" properties):
+
+		uart0: serial at 7f005000 {
+			compatible = "samsung,s3c6400-uart";
+			reg = <0x7f005000 0x100>;
+			interrupt-parent = <&vic1>;
+			interrupts = <5>;
+			clock-names = "uart", "clk_uart_baud2",
+					"clk_uart_baud3";
+			clocks = <&clock PCLK_UART0>, <&clocks PCLK_UART0>,
+					<&clock SCLK_UART>;
+			status = "disabled";
+		};
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 5d4d432..3413380 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -8,3 +8,6 @@ obj-$(CONFIG_SOC_EXYNOS5250)	+= clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5420)	+= clk-exynos5420.o
 obj-$(CONFIG_SOC_EXYNOS5440)	+= clk-exynos5440.o
 obj-$(CONFIG_ARCH_EXYNOS)	+= clk-exynos-audss.o
+ifdef CONFIG_COMMON_CLK
+obj-$(CONFIG_ARCH_S3C64XX)	+= clk-s3c64xx.o
+endif
diff --git a/drivers/clk/samsung/clk-s3c64xx.c b/drivers/clk/samsung/clk-s3c64xx.c
new file mode 100644
index 0000000..6511f78
--- /dev/null
+++ b/drivers/clk/samsung/clk-s3c64xx.c
@@ -0,0 +1,465 @@
+/*
+ * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Common Clock Framework support for all S3C64xx SoCs.
+*/
+
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+#include <dt-bindings/clock/samsung,s3c64xx-clock.h>
+
+#include "clk.h"
+#include "clk-pll.h"
+
+/* S3C64xx clock controller register offsets. */
+#define APLL_LOCK		0x000
+#define MPLL_LOCK		0x004
+#define EPLL_LOCK		0x008
+#define APLL_CON		0x00c
+#define MPLL_CON		0x010
+#define EPLL_CON0		0x014
+#define EPLL_CON1		0x018
+#define CLK_SRC			0x01c
+#define CLK_DIV0		0x020
+#define CLK_DIV1		0x024
+#define CLK_DIV2		0x028
+#define HCLK_GATE		0x030
+#define PCLK_GATE		0x034
+#define SCLK_GATE		0x038
+#define MEM0_GATE		0x03c
+#define CLK_SRC2		0x10c
+#define OTHERS			0x900
+
+/* Helper macros to define clock arrays. */
+#define FIXED_RATE_CLOCKS(name)	\
+		static struct samsung_fixed_rate_clock name[]
+#define MUX_CLOCKS(name)	\
+		static struct samsung_mux_clock name[]
+#define DIV_CLOCKS(name)	\
+		static struct samsung_div_clock name[]
+#define GATE_CLOCKS(name)	\
+		static struct samsung_gate_clock name[]
+
+/* Helper macros for gate types present on S3C64xx. */
+#define GATE_BUS(_id, cname, pname, o, b) \
+		GATE(_id, cname, pname, o, b, 0, 0)
+#define GATE_SCLK(_id, cname, pname, o, b) \
+		GATE(_id, cname, pname, o, b, CLK_SET_RATE_PARENT, 0)
+#define GATE_ON(_id, cname, pname, o, b) \
+		GATE(_id, cname, pname, o, b, CLK_IGNORE_UNUSED, 0)
+
+/*
+ * List of controller registers to be saved and restored during
+ * a suspend/resume cycle.
+ */
+static __initdata unsigned long s3c64xx_clk_regs[] = {
+	APLL_LOCK,
+	MPLL_LOCK,
+	EPLL_LOCK,
+	APLL_CON,
+	MPLL_CON,
+	EPLL_CON0,
+	EPLL_CON1,
+	CLK_SRC,
+	CLK_DIV0,
+	CLK_DIV1,
+	CLK_DIV2,
+	HCLK_GATE,
+	PCLK_GATE,
+	SCLK_GATE,
+};
+
+static __initdata unsigned long s3c6410_clk_regs[] = {
+	CLK_SRC2,
+	MEM0_GATE,
+};
+
+/* List of parent clocks common for all S3C64xx SoCs. */
+PNAME(spi_mmc_p)	= { "mout_epll", "dout_mpll", "fin_pll", "clk27m" };
+PNAME(uart_p)		= { "mout_epll", "dout_mpll" };
+PNAME(audio0_p)		= { "mout_epll", "dout_mpll", "fin_pll", "iiscdclk0",
+				"pcmcdclk0", "none", "none", "none" };
+PNAME(audio1_p)		= { "mout_epll", "dout_mpll", "fin_pll", "iiscdclk1",
+				"pcmcdclk0", "none", "none", "none" };
+PNAME(mfc_p)		= { "hclkx2", "mout_epll" };
+PNAME(apll_p)		= { "fin_pll", "fout_apll" };
+PNAME(mpll_p)		= { "fin_pll", "fout_mpll" };
+PNAME(epll_p)		= { "fin_pll", "fout_epll" };
+PNAME(hclkx2_p)		= { "mout_mpll", "mout_apll" };
+
+/* S3C6400-specific parent clocks. */
+PNAME(scaler_lcd_p6400)	= { "mout_epll", "dout_mpll", "none", "none" };
+PNAME(irda_p6400)	= { "mout_epll", "dout_mpll", "none", "clk48m" };
+PNAME(uhost_p6400)	= { "clk48m", "mout_epll", "dout_mpll", "none" };
+
+/* S3C6410-specific parent clocks. */
+PNAME(clk27_p6410)	= { "clk27m", "fin_pll" };
+PNAME(scaler_lcd_p6410)	= { "mout_epll", "dout_mpll", "fin_pll", "none" };
+PNAME(irda_p6410)	= { "mout_epll", "dout_mpll", "fin_pll", "clk48m" };
+PNAME(uhost_p6410)	= { "clk48m", "mout_epll", "dout_mpll", "fin_pll" };
+PNAME(audio2_p6410)	= { "mout_epll", "dout_mpll", "fin_pll", "iiscdclk2",
+				"pcmcdclk1", "none", "none", "none" };
+
+/* Fixed rate clocks generated outside the SoC. */
+FIXED_RATE_CLOCKS(s3c64xx_fixed_rate_ext_clks) __initdata = {
+	FRATE(0, "fin_pll", NULL, CLK_IS_ROOT, 0),
+	FRATE(0, "xusbxti", NULL, CLK_IS_ROOT, 0),
+};
+
+/* Fixed rate clocks generated inside the SoC. */
+FIXED_RATE_CLOCKS(s3c64xx_fixed_rate_clks) __initdata = {
+	FRATE(CLK27M, "clk27m", NULL, CLK_IS_ROOT, 27000000),
+	FRATE(CLK48M, "clk48m", NULL, CLK_IS_ROOT, 48000000),
+};
+
+/* List of clock muxes present on all S3C64xx SoCs. */
+MUX_CLOCKS(s3c64xx_mux_clks) __initdata = {
+	MUX_F(0, "mout_syncmux", hclkx2_p, OTHERS, 6, 1, 0, CLK_MUX_READ_ONLY),
+	MUX(MOUT_APLL, "mout_apll", apll_p, CLK_SRC, 0, 1),
+	MUX(MOUT_MPLL, "mout_mpll", mpll_p, CLK_SRC, 1, 1),
+	MUX(MOUT_EPLL, "mout_epll", epll_p, CLK_SRC, 2, 1),
+	MUX(MOUT_MFC, "mout_mfc", mfc_p, CLK_SRC, 4, 1),
+	MUX(MOUT_AUDIO0, "mout_audio0", audio0_p, CLK_SRC, 7, 3),
+	MUX(MOUT_AUDIO1, "mout_audio1", audio1_p, CLK_SRC, 10, 3),
+	MUX(MOUT_UART, "mout_uart", uart_p, CLK_SRC, 13, 1),
+	MUX(MOUT_SPI0, "mout_spi0", spi_mmc_p, CLK_SRC, 14, 2),
+	MUX(MOUT_SPI1, "mout_spi1", spi_mmc_p, CLK_SRC, 16, 2),
+	MUX(MOUT_MMC0, "mout_mmc0", spi_mmc_p, CLK_SRC, 18, 2),
+	MUX(MOUT_MMC1, "mout_mmc1", spi_mmc_p, CLK_SRC, 20, 2),
+	MUX(MOUT_MMC2, "mout_mmc2", spi_mmc_p, CLK_SRC, 22, 2),
+};
+
+/* List of clock muxes present on S3C6400. */
+MUX_CLOCKS(s3c6400_mux_clks) __initdata = {
+	MUX(MOUT_UHOST, "mout_uhost", uhost_p6400, CLK_SRC, 5, 2),
+	MUX(MOUT_IRDA, "mout_irda", irda_p6400, CLK_SRC, 24, 2),
+	MUX(MOUT_LCD, "mout_lcd", scaler_lcd_p6400, CLK_SRC, 26, 2),
+	MUX(MOUT_SCALER, "mout_scaler", scaler_lcd_p6400, CLK_SRC, 28, 2),
+};
+
+/* List of clock muxes present on S3C6410. */
+MUX_CLOCKS(s3c6410_mux_clks) __initdata = {
+	MUX(MOUT_UHOST, "mout_uhost", uhost_p6410, CLK_SRC, 5, 2),
+	MUX(MOUT_IRDA, "mout_irda", irda_p6410, CLK_SRC, 24, 2),
+	MUX(MOUT_LCD, "mout_lcd", scaler_lcd_p6410, CLK_SRC, 26, 2),
+	MUX(MOUT_SCALER, "mout_scaler", scaler_lcd_p6410, CLK_SRC, 28, 2),
+	MUX(MOUT_DAC27, "mout_dac27", clk27_p6410, CLK_SRC, 30, 1),
+	MUX(MOUT_TV27, "mout_tv27", clk27_p6410, CLK_SRC, 31, 1),
+	MUX(MOUT_AUDIO2, "mout_audio2", audio2_p6410, CLK_SRC2, 0, 3),
+};
+
+/* List of clock dividers present on all S3C64xx SoCs. */
+DIV_CLOCKS(s3c64xx_div_clks) __initdata = {
+	DIV(DOUT_MPLL, "dout_mpll", "mout_mpll", CLK_DIV0, 4, 1),
+	DIV(HCLKX2, "hclkx2", "mout_syncmux", CLK_DIV0, 9, 3),
+	DIV(HCLK, "hclk", "hclkx2", CLK_DIV0, 8, 1),
+	DIV(PCLK, "pclk", "hclkx2", CLK_DIV0, 12, 4),
+	DIV(DOUT_SECUR, "dout_secur", "hclkx2", CLK_DIV0, 18, 2),
+	DIV(DOUT_CAM, "dout_cam", "hclkx2", CLK_DIV0, 20, 4),
+	DIV(DOUT_JPEG, "dout_jpeg", "hclkx2", CLK_DIV0, 24, 4),
+	DIV(DOUT_MFC, "dout_mfc", "mout_mfc", CLK_DIV0, 28, 4),
+	DIV(DOUT_MMC0, "dout_mmc0", "mout_mmc0", CLK_DIV1, 0, 4),
+	DIV(DOUT_MMC1, "dout_mmc1", "mout_mmc1", CLK_DIV1, 4, 4),
+	DIV(DOUT_MMC2, "dout_mmc2", "mout_mmc2", CLK_DIV1, 8, 4),
+	DIV(DOUT_LCD, "dout_lcd", "mout_lcd", CLK_DIV1, 12, 4),
+	DIV(DOUT_SCALER, "dout_scaler", "mout_scaler", CLK_DIV1, 16, 4),
+	DIV(DOUT_UHOST, "dout_uhost", "mout_uhost", CLK_DIV1, 20, 4),
+	DIV(DOUT_SPI0, "dout_spi0", "mout_spi0", CLK_DIV2, 0, 4),
+	DIV(DOUT_SPI1, "dout_spi1", "mout_spi1", CLK_DIV2, 4, 4),
+	DIV(DOUT_AUDIO0, "dout_audio0", "mout_audio0", CLK_DIV2, 8, 4),
+	DIV(DOUT_AUDIO1, "dout_audio1", "mout_audio1", CLK_DIV2, 12, 4),
+	DIV(DOUT_UART, "dout_uart", "mout_uart", CLK_DIV2, 16, 4),
+	DIV(DOUT_IRDA, "dout_irda", "mout_irda", CLK_DIV2, 20, 4),
+};
+
+/* List of clock dividers present on S3C6400. */
+DIV_CLOCKS(s3c6400_div_clks) __initdata = {
+	DIV(ARMCLK, "armclk", "mout_apll", CLK_DIV0, 0, 3),
+};
+
+/* List of clock dividers present on S3C6410. */
+DIV_CLOCKS(s3c6410_div_clks) __initdata = {
+	DIV(ARMCLK, "armclk", "mout_apll", CLK_DIV0, 0, 4),
+	DIV(DOUT_FIMC, "dout_fimc", "hclk", CLK_DIV1, 24, 4),
+	DIV(DOUT_AUDIO2, "dout_audio2", "mout_audio2", CLK_DIV2, 24, 4),
+};
+
+/* List of clock gates present on all S3C64xx SoCs. */
+GATE_CLOCKS(s3c64xx_gate_clks) __initdata = {
+	GATE_BUS(HCLK_UHOST, "hclk_uhost", "hclk", HCLK_GATE, 29),
+	GATE_BUS(HCLK_SECUR, "hclk_secur", "hclk", HCLK_GATE, 28),
+	GATE_BUS(HCLK_SDMA1, "hclk_sdma1", "hclk", HCLK_GATE, 27),
+	GATE_BUS(HCLK_SDMA0, "hclk_sdma0", "hclk", HCLK_GATE, 26),
+	GATE_ON(HCLK_DDR1, "hclk_ddr1", "hclk", HCLK_GATE, 24),
+	GATE_BUS(HCLK_USB, "hclk_usb", "hclk", HCLK_GATE, 20),
+	GATE_BUS(HCLK_HSMMC2, "hclk_hsmmc2", "hclk", HCLK_GATE, 19),
+	GATE_BUS(HCLK_HSMMC1, "hclk_hsmmc1", "hclk", HCLK_GATE, 18),
+	GATE_BUS(HCLK_HSMMC0, "hclk_hsmmc0", "hclk", HCLK_GATE, 17),
+	GATE_BUS(HCLK_MDP, "hclk_mdp", "hclk", HCLK_GATE, 16),
+	GATE_BUS(HCLK_DHOST, "hclk_dhost", "hclk", HCLK_GATE, 15),
+	GATE_BUS(HCLK_IHOST, "hclk_ihost", "hclk", HCLK_GATE, 14),
+	GATE_BUS(HCLK_DMA1, "hclk_dma1", "hclk", HCLK_GATE, 13),
+	GATE_BUS(HCLK_DMA0, "hclk_dma0", "hclk", HCLK_GATE, 12),
+	GATE_BUS(HCLK_JPEG, "hclk_jpeg", "hclk", HCLK_GATE, 11),
+	GATE_BUS(HCLK_CAMIF, "hclk_camif", "hclk", HCLK_GATE, 10),
+	GATE_BUS(HCLK_SCALER, "hclk_scaler", "hclk", HCLK_GATE, 9),
+	GATE_BUS(HCLK_2D, "hclk_2d", "hclk", HCLK_GATE, 8),
+	GATE_BUS(HCLK_TV, "hclk_tv", "hclk", HCLK_GATE, 7),
+	GATE_BUS(HCLK_POST0, "hclk_post0", "hclk", HCLK_GATE, 5),
+	GATE_BUS(HCLK_ROT, "hclk_rot", "hclk", HCLK_GATE, 4),
+	GATE_BUS(HCLK_LCD, "hclk_lcd", "hclk", HCLK_GATE, 3),
+	GATE_BUS(HCLK_TZIC, "hclk_tzic", "hclk", HCLK_GATE, 2),
+	GATE_ON(HCLK_INTC, "hclk_intc", "hclk", HCLK_GATE, 1),
+	GATE_ON(PCLK_SKEY, "pclk_skey", "pclk", PCLK_GATE, 24),
+	GATE_ON(PCLK_CHIPID, "pclk_chipid", "pclk", PCLK_GATE, 23),
+	GATE_BUS(PCLK_SPI1, "pclk_spi1", "pclk", PCLK_GATE, 22),
+	GATE_BUS(PCLK_SPI0, "pclk_spi0", "pclk", PCLK_GATE, 21),
+	GATE_BUS(PCLK_HSIRX, "pclk_hsirx", "pclk", PCLK_GATE, 20),
+	GATE_BUS(PCLK_HSITX, "pclk_hsitx", "pclk", PCLK_GATE, 19),
+	GATE_ON(PCLK_GPIO, "pclk_gpio", "pclk", PCLK_GATE, 18),
+	GATE_BUS(PCLK_IIC0, "pclk_iic0", "pclk", PCLK_GATE, 17),
+	GATE_BUS(PCLK_IIS1, "pclk_iis1", "pclk", PCLK_GATE, 16),
+	GATE_BUS(PCLK_IIS0, "pclk_iis0", "pclk", PCLK_GATE, 15),
+	GATE_BUS(PCLK_AC97, "pclk_ac97", "pclk", PCLK_GATE, 14),
+	GATE_BUS(PCLK_TZPC, "pclk_tzpc", "pclk", PCLK_GATE, 13),
+	GATE_BUS(PCLK_TSADC, "pclk_tsadc", "pclk", PCLK_GATE, 12),
+	GATE_BUS(PCLK_KEYPAD, "pclk_keypad", "pclk", PCLK_GATE, 11),
+	GATE_BUS(PCLK_IRDA, "pclk_irda", "pclk", PCLK_GATE, 10),
+	GATE_BUS(PCLK_PCM1, "pclk_pcm1", "pclk", PCLK_GATE, 9),
+	GATE_BUS(PCLK_PCM0, "pclk_pcm0", "pclk", PCLK_GATE, 8),
+	GATE_BUS(PCLK_PWM, "pclk_pwm", "pclk", PCLK_GATE, 7),
+	GATE_BUS(PCLK_RTC, "pclk_rtc", "pclk", PCLK_GATE, 6),
+	GATE_BUS(PCLK_WDT, "pclk_wdt", "pclk", PCLK_GATE, 5),
+	GATE_BUS(PCLK_UART3, "pclk_uart3", "pclk", PCLK_GATE, 4),
+	GATE_BUS(PCLK_UART2, "pclk_uart2", "pclk", PCLK_GATE, 3),
+	GATE_BUS(PCLK_UART1, "pclk_uart1", "pclk", PCLK_GATE, 2),
+	GATE_BUS(PCLK_UART0, "pclk_uart0", "pclk", PCLK_GATE, 1),
+	GATE_BUS(PCLK_MFC, "pclk_mfc", "pclk", PCLK_GATE, 0),
+	GATE_SCLK(SCLK_UHOST, "sclk_uhost", "dout_uhost", SCLK_GATE, 30),
+	GATE_SCLK(SCLK_MMC2_48, "sclk_mmc2_48", "clk48m", SCLK_GATE, 29),
+	GATE_SCLK(SCLK_MMC1_48, "sclk_mmc1_48", "clk48m", SCLK_GATE, 28),
+	GATE_SCLK(SCLK_MMC0_48, "sclk_mmc0_48", "clk48m", SCLK_GATE, 27),
+	GATE_SCLK(SCLK_MMC2, "sclk_mmc2", "dout_mmc2", SCLK_GATE, 26),
+	GATE_SCLK(SCLK_MMC1, "sclk_mmc1", "dout_mmc1", SCLK_GATE, 25),
+	GATE_SCLK(SCLK_MMC0, "sclk_mmc0", "dout_mmc0", SCLK_GATE, 24),
+	GATE_SCLK(SCLK_SPI1_48, "sclk_spi1_48", "clk48m", SCLK_GATE, 23),
+	GATE_SCLK(SCLK_SPI0_48, "sclk_spi0_48", "clk48m", SCLK_GATE, 22),
+	GATE_SCLK(SCLK_SPI1, "sclk_spi1", "dout_spi1", SCLK_GATE, 21),
+	GATE_SCLK(SCLK_SPI0, "sclk_spi0", "dout_spi0", SCLK_GATE, 20),
+	GATE_SCLK(SCLK_DAC27, "sclk_dac27", "mout_dac27", SCLK_GATE, 19),
+	GATE_SCLK(SCLK_TV27, "sclk_tv27", "mout_tv27", SCLK_GATE, 18),
+	GATE_SCLK(SCLK_SCALER27, "sclk_scaler27", "clk27m", SCLK_GATE, 17),
+	GATE_SCLK(SCLK_SCALER, "sclk_scaler", "dout_scaler", SCLK_GATE, 16),
+	GATE_SCLK(SCLK_LCD27, "sclk_lcd27", "clk27m", SCLK_GATE, 15),
+	GATE_SCLK(SCLK_LCD, "sclk_lcd", "dout_lcd", SCLK_GATE, 14),
+	GATE_SCLK(SCLK_POST0_27, "sclk_post0_27", "clk27m", SCLK_GATE, 12),
+	GATE_SCLK(SCLK_POST0, "sclk_post0", "dout_lcd", SCLK_GATE, 10),
+	GATE_SCLK(SCLK_AUDIO1, "sclk_audio1", "dout_audio1", SCLK_GATE, 9),
+	GATE_SCLK(SCLK_AUDIO0, "sclk_audio0", "dout_audio0", SCLK_GATE, 8),
+	GATE_SCLK(SCLK_SECUR, "sclk_secur", "dout_secur", SCLK_GATE, 7),
+	GATE_SCLK(SCLK_IRDA, "sclk_irda", "dout_irda", SCLK_GATE, 6),
+	GATE_SCLK(SCLK_UART, "sclk_uart", "dout_uart", SCLK_GATE, 5),
+	GATE_SCLK(SCLK_MFC, "sclk_mfc", "dout_mfc", SCLK_GATE, 3),
+	GATE_SCLK(SCLK_CAM, "sclk_cam", "dout_cam", SCLK_GATE, 2),
+	GATE_SCLK(SCLK_JPEG, "sclk_jpeg", "dout_jpeg", SCLK_GATE, 1),
+};
+
+/* List of clock gates present on S3C6400. */
+GATE_CLOCKS(s3c6400_gate_clks) __initdata = {
+	GATE_ON(HCLK_DDR0, "hclk_ddr0", "hclk", HCLK_GATE, 23),
+	GATE_SCLK(SCLK_ONENAND, "sclk_onenand", "parent", SCLK_GATE, 4),
+};
+
+/* List of clock gates present on S3C6410. */
+GATE_CLOCKS(s3c6410_gate_clks) __initdata = {
+	GATE_BUS(HCLK_3DSE, "hclk_3dse", "hclk", HCLK_GATE, 31),
+	GATE_ON(HCLK_IROM, "hclk_irom", "hclk", HCLK_GATE, 25),
+	GATE_ON(HCLK_MEM1, "hclk_mem1", "hclk", HCLK_GATE, 22),
+	GATE_ON(HCLK_MEM0, "hclk_mem0", "hclk", HCLK_GATE, 21),
+	GATE_BUS(HCLK_MFC, "hclk_mfc", "hclk", HCLK_GATE, 0),
+	GATE_BUS(PCLK_IIC1, "pclk_iic1", "pclk", PCLK_GATE, 27),
+	GATE_BUS(PCLK_IIS2, "pclk_iis2", "pclk", PCLK_GATE, 26),
+	GATE_SCLK(SCLK_FIMC, "sclk_fimc", "dout_fimc", SCLK_GATE, 13),
+	GATE_SCLK(SCLK_AUDIO2, "sclk_audio2", "dout_audio2", SCLK_GATE, 11),
+	GATE_BUS(MEM0_CFCON, "mem0_cfcon", "hclk_mem0", MEM0_GATE, 5),
+	GATE_BUS(MEM0_ONENAND1, "mem0_onenand1", "hclk_mem0", MEM0_GATE, 4),
+	GATE_BUS(MEM0_ONENAND0, "mem0_onenand0", "hclk_mem0", MEM0_GATE, 3),
+	GATE_BUS(MEM0_NFCON, "mem0_nfcon", "hclk_mem0", MEM0_GATE, 2),
+	GATE_ON(MEM0_SROM, "mem0_srom", "hclk_mem0", MEM0_GATE, 1),
+};
+
+/* Aliases for common s3c64xx clocks. */
+static struct samsung_clock_alias s3c64xx_clock_aliases[] = {
+	ALIAS(MOUT_EPLL, NULL, "mout_epll"),
+	ALIAS(DOUT_MPLL, NULL, "dout_mpll"),
+	ALIAS(HCLKX2, NULL, "hclk2"),
+	ALIAS(HCLK, NULL, "hclk"),
+	ALIAS(PCLK, NULL, "pclk"),
+	ALIAS(PCLK, NULL, "clk_uart_baud2"),
+	ALIAS(ARMCLK, NULL, "armclk"),
+	ALIAS(HCLK_UHOST, "s3c2410-ohci", "usb-host"),
+	ALIAS(HCLK_USB, "s3c-hsotg", "otg"),
+	ALIAS(HCLK_HSMMC2, "s3c-sdhci.2", "hsmmc"),
+	ALIAS(HCLK_HSMMC2, "s3c-sdhci.2", "mmc_busclk.0"),
+	ALIAS(HCLK_HSMMC1, "s3c-sdhci.1", "hsmmc"),
+	ALIAS(HCLK_HSMMC1, "s3c-sdhci.1", "mmc_busclk.0"),
+	ALIAS(HCLK_HSMMC0, "s3c-sdhci.0", "hsmmc"),
+	ALIAS(HCLK_HSMMC0, "s3c-sdhci.0", "mmc_busclk.0"),
+	ALIAS(HCLK_DMA1, NULL, "dma1"),
+	ALIAS(HCLK_DMA0, NULL, "dma0"),
+	ALIAS(HCLK_CAMIF, "s3c-camif", "camif"),
+	ALIAS(HCLK_LCD, "s3c-fb", "lcd"),
+	ALIAS(PCLK_SPI1, "s3c6410-spi.1", "spi"),
+	ALIAS(PCLK_SPI0, "s3c6410-spi.0", "spi"),
+	ALIAS(PCLK_IIC0, "s3c2440-i2c.0", "i2c"),
+	ALIAS(PCLK_IIS1, "samsung-i2s.1", "iis"),
+	ALIAS(PCLK_IIS0, "samsung-i2s.0", "iis"),
+	ALIAS(PCLK_AC97, "samsung-ac97", "ac97"),
+	ALIAS(PCLK_TSADC, "s3c64xx-adc", "adc"),
+	ALIAS(PCLK_KEYPAD, "samsung-keypad", "keypad"),
+	ALIAS(PCLK_PCM1, "samsung-pcm.1", "pcm"),
+	ALIAS(PCLK_PCM0, "samsung-pcm.0", "pcm"),
+	ALIAS(PCLK_PWM, NULL, "timers"),
+	ALIAS(PCLK_RTC, "s3c64xx-rtc", "rtc"),
+	ALIAS(PCLK_WDT, NULL, "watchdog"),
+	ALIAS(PCLK_UART3, "s3c6400-uart.3", "uart"),
+	ALIAS(PCLK_UART2, "s3c6400-uart.2", "uart"),
+	ALIAS(PCLK_UART1, "s3c6400-uart.1", "uart"),
+	ALIAS(PCLK_UART0, "s3c6400-uart.0", "uart"),
+	ALIAS(SCLK_UHOST, "s3c2410-ohci", "usb-bus-host"),
+	ALIAS(SCLK_MMC2, "s3c-sdhci.2", "mmc_busclk.2"),
+	ALIAS(SCLK_MMC1, "s3c-sdhci.1", "mmc_busclk.2"),
+	ALIAS(SCLK_MMC0, "s3c-sdhci.0", "mmc_busclk.2"),
+	ALIAS(SCLK_SPI1, "s3c6410-spi.1", "spi-bus"),
+	ALIAS(SCLK_SPI0, "s3c6410-spi.0", "spi-bus"),
+	ALIAS(SCLK_AUDIO1, "samsung-pcm.1", "audio-bus"),
+	ALIAS(SCLK_AUDIO1, "samsung-i2s.1", "audio-bus"),
+	ALIAS(SCLK_AUDIO0, "samsung-pcm.0", "audio-bus"),
+	ALIAS(SCLK_AUDIO0, "samsung-i2s.0", "audio-bus"),
+	ALIAS(SCLK_UART, NULL, "clk_uart_baud3"),
+	ALIAS(SCLK_CAM, "s3c-camif", "camera"),
+};
+
+/* Aliases for s3c6400-specific clocks. */
+static struct samsung_clock_alias s3c6400_clock_aliases[] = {
+	/* Nothing to place here yet. */
+};
+
+/* Aliases for s3c6410-specific clocks. */
+static struct samsung_clock_alias s3c6410_clock_aliases[] = {
+	ALIAS(PCLK_IIC1, "s3c2440-i2c.1", "i2c"),
+	ALIAS(PCLK_IIS2, "samsung-i2s.2", "iis"),
+	ALIAS(SCLK_FIMC, "s3c-camif", "fimc"),
+	ALIAS(SCLK_AUDIO2, "samsung-i2s.2", "audio-bus"),
+	ALIAS(MEM0_SROM, NULL, "srom"),
+};
+
+static void __init s3c64xx_clk_register_fixed_ext(unsigned long fin_pll_f,
+							unsigned long xusbxti_f)
+{
+	s3c64xx_fixed_rate_ext_clks[0].fixed_rate = fin_pll_f;
+	s3c64xx_fixed_rate_ext_clks[1].fixed_rate = xusbxti_f;
+	samsung_clk_register_fixed_rate(s3c64xx_fixed_rate_ext_clks,
+				ARRAY_SIZE(s3c64xx_fixed_rate_ext_clks));
+}
+
+/* Register s3c64xx clocks. */
+void __init s3c64xx_clk_init(struct device_node *np, unsigned long xtal_f,
+			     unsigned long xusbxti_f, bool is_s3c6400,
+			     void __iomem *reg_base)
+{
+	struct clk *clk;
+	unsigned long *soc_regs = NULL;
+	unsigned long nr_soc_regs = 0;
+
+	if (np) {
+		reg_base = of_iomap(np, 0);
+		if (!reg_base)
+			panic("%s: failed to map registers\n", __func__);
+	}
+
+	if (!is_s3c6400) {
+		soc_regs = s3c6410_clk_regs;
+		nr_soc_regs = ARRAY_SIZE(s3c6410_clk_regs);
+	}
+
+	samsung_clk_init(np, reg_base, NR_CLKS, s3c64xx_clk_regs,
+			ARRAY_SIZE(s3c64xx_clk_regs), soc_regs, nr_soc_regs);
+
+	/* Register external clocks. */
+	if (!np)
+		s3c64xx_clk_register_fixed_ext(xtal_f, xusbxti_f);
+
+	/* Register PLLs. */
+	clk = samsung_clk_register_pll6552("fout_apll",
+					"fin_pll", reg_base + APLL_LOCK);
+	samsung_clk_add_lookup(clk, FOUT_APLL);
+
+	clk = samsung_clk_register_pll6552("fout_mpll",
+					"fin_pll", reg_base + MPLL_LOCK);
+	samsung_clk_add_lookup(clk, FOUT_MPLL);
+
+	clk = samsung_clk_register_pll6553("fout_epll",
+					"fin_pll", reg_base + EPLL_LOCK);
+	samsung_clk_add_lookup(clk, FOUT_EPLL);
+
+	/* Register common internal clocks. */
+	samsung_clk_register_fixed_rate(s3c64xx_fixed_rate_clks,
+					ARRAY_SIZE(s3c64xx_fixed_rate_clks));
+	samsung_clk_register_mux(s3c64xx_mux_clks,
+					ARRAY_SIZE(s3c64xx_mux_clks));
+	samsung_clk_register_div(s3c64xx_div_clks,
+					ARRAY_SIZE(s3c64xx_div_clks));
+	samsung_clk_register_gate(s3c64xx_gate_clks,
+					ARRAY_SIZE(s3c64xx_gate_clks));
+
+	/* Register SoC-specific clocks. */
+	if (is_s3c6400) {
+		samsung_clk_register_mux(s3c6400_mux_clks,
+					ARRAY_SIZE(s3c6400_mux_clks));
+		samsung_clk_register_div(s3c6400_div_clks,
+					ARRAY_SIZE(s3c6400_div_clks));
+		samsung_clk_register_gate(s3c6400_gate_clks,
+					ARRAY_SIZE(s3c6400_gate_clks));
+		samsung_clk_register_alias(s3c6400_clock_aliases,
+					ARRAY_SIZE(s3c6400_clock_aliases));
+	} else {
+		samsung_clk_register_mux(s3c6410_mux_clks,
+					ARRAY_SIZE(s3c6410_mux_clks));
+		samsung_clk_register_div(s3c6410_div_clks,
+					ARRAY_SIZE(s3c6410_div_clks));
+		samsung_clk_register_gate(s3c6410_gate_clks,
+					ARRAY_SIZE(s3c6410_gate_clks));
+		samsung_clk_register_alias(s3c6410_clock_aliases,
+					ARRAY_SIZE(s3c6410_clock_aliases));
+	}
+
+	samsung_clk_register_alias(s3c64xx_clock_aliases,
+					ARRAY_SIZE(s3c64xx_clock_aliases));
+
+	pr_info("%s clocks: apll = %lu, mpll = %lu\n"
+		"\tepll = %lu, arm_clk = %lu\n",
+		is_s3c6400 ? "S3C6400" : "S3C6410",
+		_get_rate("fout_apll"),	_get_rate("fout_mpll"),
+		_get_rate("fout_epll"), _get_rate("armclk"));
+}
+
+static void __init s3c6400_clk_init(struct device_node *np)
+{
+	s3c64xx_clk_init(np, 0, 0, true, NULL);
+}
+CLK_OF_DECLARE(s3c6400_clk, "samsung,s3c6400-clock", s3c6400_clk_init);
+
+static void __init s3c6410_clk_init(struct device_node *np)
+{
+	s3c64xx_clk_init(np, 0, 0, false, NULL);
+}
+CLK_OF_DECLARE(s3c6410_clk, "samsung,s3c6410-clock", s3c6410_clk_init);
diff --git a/include/dt-bindings/clock/samsung,s3c64xx-clock.h b/include/dt-bindings/clock/samsung,s3c64xx-clock.h
new file mode 100644
index 0000000..ad95c7f
--- /dev/null
+++ b/include/dt-bindings/clock/samsung,s3c64xx-clock.h
@@ -0,0 +1,178 @@
+/*
+ * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Device Tree binding constants for Samsung S3C64xx clock controller.
+*/
+
+#ifndef _DT_BINDINGS_CLOCK_SAMSUNG_S3C64XX_CLOCK_H
+#define _DT_BINDINGS_CLOCK_SAMSUNG_S3C64XX_CLOCK_H
+
+/*
+ * Let each exported clock get a unique index, which is used on DT-enabled
+ * platforms to lookup the clock from a clock specifier. These indices are
+ * therefore considered an ABI and so must not be changed. This implies
+ * that new clocks should be added either in free spaces between clock groups
+ * or at the end.
+ */
+
+/* Core clocks. */
+#define CLK27M			1
+#define CLK48M			2
+#define FOUT_APLL		3
+#define FOUT_MPLL		4
+#define FOUT_EPLL		5
+#define ARMCLK			6
+#define HCLKX2			7
+#define HCLK			8
+#define PCLK			9
+
+/* HCLK bus clocks. */
+#define HCLK_3DSE		16
+#define HCLK_UHOST		17
+#define HCLK_SECUR		18
+#define HCLK_SDMA1		19
+#define HCLK_SDMA0		20
+#define HCLK_IROM		21
+#define HCLK_DDR1		22
+#define HCLK_MEM1		23
+#define HCLK_MEM0		24
+#define HCLK_USB		25
+#define HCLK_HSMMC2		26
+#define HCLK_HSMMC1		27
+#define HCLK_HSMMC0		28
+#define HCLK_MDP		29
+#define HCLK_DHOST		30
+#define HCLK_IHOST		31
+#define HCLK_DMA1		32
+#define HCLK_DMA0		33
+#define HCLK_JPEG		34
+#define HCLK_CAMIF		35
+#define HCLK_SCALER		36
+#define HCLK_2D			37
+#define HCLK_TV			38
+#define HCLK_POST0		39
+#define HCLK_ROT		40
+#define HCLK_LCD		41
+#define HCLK_TZIC		42
+#define HCLK_INTC		43
+#define HCLK_MFC		44
+#define HCLK_DDR0		45
+
+/* PCLK bus clocks. */
+#define PCLK_IIC1		48
+#define PCLK_IIS2		49
+#define PCLK_SKEY		50
+#define PCLK_CHIPID		51
+#define PCLK_SPI1		52
+#define PCLK_SPI0		53
+#define PCLK_HSIRX		54
+#define PCLK_HSITX		55
+#define PCLK_GPIO		56
+#define PCLK_IIC0		57
+#define PCLK_IIS1		58
+#define PCLK_IIS0		59
+#define PCLK_AC97		60
+#define PCLK_TZPC		61
+#define PCLK_TSADC		62
+#define PCLK_KEYPAD		63
+#define PCLK_IRDA		64
+#define PCLK_PCM1		65
+#define PCLK_PCM0		66
+#define PCLK_PWM		67
+#define PCLK_RTC		68
+#define PCLK_WDT		69
+#define PCLK_UART3		70
+#define PCLK_UART2		71
+#define PCLK_UART1		72
+#define PCLK_UART0		73
+#define PCLK_MFC		74
+
+/* Special clocks. */
+#define SCLK_UHOST		80
+#define SCLK_MMC2_48		81
+#define SCLK_MMC1_48		82
+#define SCLK_MMC0_48		83
+#define SCLK_MMC2		84
+#define SCLK_MMC1		85
+#define SCLK_MMC0		86
+#define SCLK_SPI1_48		87
+#define SCLK_SPI0_48		88
+#define SCLK_SPI1		89
+#define SCLK_SPI0		90
+#define SCLK_DAC27		91
+#define SCLK_TV27		92
+#define SCLK_SCALER27		93
+#define SCLK_SCALER		94
+#define SCLK_LCD27		95
+#define SCLK_LCD		96
+#define SCLK_FIMC		97
+#define SCLK_POST0_27		98
+#define SCLK_AUDIO2		99
+#define SCLK_POST0		100
+#define SCLK_AUDIO1		101
+#define SCLK_AUDIO0		102
+#define SCLK_SECUR		103
+#define SCLK_IRDA		104
+#define SCLK_UART		105
+#define SCLK_MFC		106
+#define SCLK_CAM		107
+#define SCLK_JPEG		108
+#define SCLK_ONENAND		109
+
+/* MEM0 bus clocks - S3C6410-specific. */
+#define MEM0_CFCON		112
+#define MEM0_ONENAND1		113
+#define MEM0_ONENAND0		114
+#define MEM0_NFCON		115
+#define MEM0_SROM		116
+
+/* Muxes. */
+#define MOUT_APLL		128
+#define MOUT_MPLL		129
+#define MOUT_EPLL		130
+#define MOUT_MFC		131
+#define MOUT_AUDIO0		132
+#define MOUT_AUDIO1		133
+#define MOUT_UART		134
+#define MOUT_SPI0		135
+#define MOUT_SPI1		136
+#define MOUT_MMC0		137
+#define MOUT_MMC1		138
+#define MOUT_MMC2		139
+#define MOUT_UHOST		140
+#define MOUT_IRDA		141
+#define MOUT_LCD		142
+#define MOUT_SCALER		143
+#define MOUT_DAC27		144
+#define MOUT_TV27		145
+#define MOUT_AUDIO2		146
+
+/* Dividers. */
+#define DOUT_MPLL		160
+#define DOUT_SECUR		161
+#define DOUT_CAM		162
+#define DOUT_JPEG		163
+#define DOUT_MFC		164
+#define DOUT_MMC0		165
+#define DOUT_MMC1		166
+#define DOUT_MMC2		167
+#define DOUT_LCD		168
+#define DOUT_SCALER		169
+#define DOUT_UHOST		170
+#define DOUT_SPI0		171
+#define DOUT_SPI1		172
+#define DOUT_AUDIO0		173
+#define DOUT_AUDIO1		174
+#define DOUT_UART		175
+#define DOUT_IRDA		176
+#define DOUT_FIMC		177
+#define DOUT_AUDIO2		178
+
+/* Total number of clocks. */
+#define NR_CLKS			(DOUT_AUDIO2 + 1)
+
+#endif /* _DT_BINDINGS_CLOCK_SAMSUNG_S3C64XX_CLOCK_H */
-- 
1.8.3.2



From tomasz.figa at gmail.com  Mon Jul 22 19:49:25 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 01:49:25 +0200
Subject: [PATCH v2 8/8] ARM: s3c64xx: Remove old clock management code
In-Reply-To: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1374536965-3545-9-git-send-email-tomasz.figa@gmail.com>

This patch removes old clock management code of S3C64xx, since the
platform has been already moved to the new clock driver using Common
Clock Framework.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
---
 arch/arm/mach-s3c64xx/clock.c                   | 1007 -----------------------
 arch/arm/mach-s3c64xx/common.h                  |    2 -
 arch/arm/mach-s3c64xx/include/mach/regs-clock.h |  132 +--
 arch/arm/mach-s3c64xx/pm.c                      |   21 -
 4 files changed, 4 insertions(+), 1158 deletions(-)
 delete mode 100644 arch/arm/mach-s3c64xx/clock.c

diff --git a/arch/arm/mach-s3c64xx/clock.c b/arch/arm/mach-s3c64xx/clock.c
deleted file mode 100644
index c1bcc4a..0000000
--- a/arch/arm/mach-s3c64xx/clock.c
+++ /dev/null
@@ -1,1007 +0,0 @@
-/* linux/arch/arm/plat-s3c64xx/clock.c
- *
- * Copyright 2008 Openmoko, Inc.
- * Copyright 2008 Simtec Electronics
- *	Ben Dooks <ben at simtec.co.uk>
- *	http://armlinux.simtec.co.uk/
- *
- * S3C64XX Base clock support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include <linux/init.h>
-#include <linux/module.h>
-#include <linux/interrupt.h>
-#include <linux/ioport.h>
-#include <linux/clk.h>
-#include <linux/err.h>
-#include <linux/io.h>
-
-#include <mach/hardware.h>
-#include <mach/map.h>
-
-#include <mach/regs-clock.h>
-
-#include <plat/cpu.h>
-#include <plat/devs.h>
-#include <plat/cpu-freq.h>
-#include <plat/clock.h>
-#include <plat/clock-clksrc.h>
-#include <plat/pll.h>
-
-#include "regs-sys.h"
-
-/* fin_apll, fin_mpll and fin_epll are all the same clock, which we call
- * ext_xtal_mux for want of an actual name from the manual.
-*/
-
-static struct clk clk_ext_xtal_mux = {
-	.name		= "ext_xtal",
-};
-
-#define clk_fin_apll clk_ext_xtal_mux
-#define clk_fin_mpll clk_ext_xtal_mux
-#define clk_fin_epll clk_ext_xtal_mux
-
-#define clk_fout_mpll	clk_mpll
-#define clk_fout_epll	clk_epll
-
-struct clk clk_h2 = {
-	.name		= "hclk2",
-	.rate		= 0,
-};
-
-struct clk clk_27m = {
-	.name		= "clk_27m",
-	.rate		= 27000000,
-};
-
-static int clk_48m_ctrl(struct clk *clk, int enable)
-{
-	unsigned long flags;
-	u32 val;
-
-	/* can't rely on clock lock, this register has other usages */
-	local_irq_save(flags);
-
-	val = __raw_readl(S3C64XX_OTHERS);
-	if (enable)
-		val |= S3C64XX_OTHERS_USBMASK;
-	else
-		val &= ~S3C64XX_OTHERS_USBMASK;
-
-	__raw_writel(val, S3C64XX_OTHERS);
-	local_irq_restore(flags);
-
-	return 0;
-}
-
-struct clk clk_48m = {
-	.name		= "clk_48m",
-	.rate		= 48000000,
-	.enable		= clk_48m_ctrl,
-};
-
-struct clk clk_xusbxti = {
-	.name		= "xusbxti",
-	.rate		= 48000000,
-};
-
-static int inline s3c64xx_gate(void __iomem *reg,
-				struct clk *clk,
-				int enable)
-{
-	unsigned int ctrlbit = clk->ctrlbit;
-	u32 con;
-
-	con = __raw_readl(reg);
-
-	if (enable)
-		con |= ctrlbit;
-	else
-		con &= ~ctrlbit;
-
-	__raw_writel(con, reg);
-	return 0;
-}
-
-static int s3c64xx_pclk_ctrl(struct clk *clk, int enable)
-{
-	return s3c64xx_gate(S3C_PCLK_GATE, clk, enable);
-}
-
-static int s3c64xx_hclk_ctrl(struct clk *clk, int enable)
-{
-	return s3c64xx_gate(S3C_HCLK_GATE, clk, enable);
-}
-
-int s3c64xx_sclk_ctrl(struct clk *clk, int enable)
-{
-	return s3c64xx_gate(S3C_SCLK_GATE, clk, enable);
-}
-
-static struct clk init_clocks_off[] = {
-	{
-		.name		= "nand",
-		.parent		= &clk_h,
-	}, {
-		.name		= "rtc",
-		.parent		= &clk_p,
-		.enable		= s3c64xx_pclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_PCLK_RTC,
-	}, {
-		.name		= "adc",
-		.parent		= &clk_p,
-		.enable		= s3c64xx_pclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_PCLK_TSADC,
-	}, {
-		.name		= "i2c",
-		.devname        = "s3c2440-i2c.0",
-		.parent		= &clk_p,
-		.enable		= s3c64xx_pclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_PCLK_IIC,
-	}, {
-		.name		= "i2c",
-		.devname	= "s3c2440-i2c.1",
-		.parent		= &clk_p,
-		.enable		= s3c64xx_pclk_ctrl,
-		.ctrlbit	= S3C6410_CLKCON_PCLK_I2C1,
-	}, {
-		.name		= "keypad",
-		.parent		= &clk_p,
-		.enable		= s3c64xx_pclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_PCLK_KEYPAD,
-	}, {
-		.name		= "spi",
-		.devname	= "s3c6410-spi.0",
-		.parent		= &clk_p,
-		.enable		= s3c64xx_pclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_PCLK_SPI0,
-	}, {
-		.name		= "spi",
-		.devname	= "s3c6410-spi.1",
-		.parent		= &clk_p,
-		.enable		= s3c64xx_pclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_PCLK_SPI1,
-	}, {
-		.name		= "48m",
-		.devname	= "s3c-sdhci.0",
-		.parent		= &clk_48m,
-		.enable		= s3c64xx_sclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_SCLK_MMC0_48,
-	}, {
-		.name		= "48m",
-		.devname	= "s3c-sdhci.1",
-		.parent		= &clk_48m,
-		.enable		= s3c64xx_sclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_SCLK_MMC1_48,
-	}, {
-		.name		= "48m",
-		.devname	= "s3c-sdhci.2",
-		.parent		= &clk_48m,
-		.enable		= s3c64xx_sclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_SCLK_MMC2_48,
-	}, {
-		.name		= "ac97",
-		.parent		= &clk_p,
-		.ctrlbit	= S3C_CLKCON_PCLK_AC97,
-	}, {
-		.name		= "cfcon",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_IHOST,
-	}, {
-		.name		= "dma0",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_DMA0,
-	}, {
-		.name		= "dma1",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_DMA1,
-	}, {
-		.name		= "3dse",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_3DSE,
-	}, {
-		.name		= "hclk_secur",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_SECUR,
-	}, {
-		.name		= "sdma1",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_SDMA1,
-	}, {
-		.name		= "sdma0",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_SDMA0,
-	}, {
-		.name		= "hclk_jpeg",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_JPEG,
-	}, {
-		.name		= "camif",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_CAMIF,
-	}, {
-		.name		= "hclk_scaler",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_SCALER,
-	}, {
-		.name		= "2d",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_2D,
-	}, {
-		.name		= "tv",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_TV,
-	}, {
-		.name		= "post0",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_POST0,
-	}, {
-		.name		= "rot",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_ROT,
-	}, {
-		.name		= "hclk_mfc",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_MFC,
-	}, {
-		.name		= "pclk_mfc",
-		.parent		= &clk_p,
-		.enable		= s3c64xx_pclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_PCLK_MFC,
-	}, {
-		.name		= "dac27",
-		.enable		= s3c64xx_sclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_SCLK_DAC27,
-	}, {
-		.name		= "tv27",
-		.enable		= s3c64xx_sclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_SCLK_TV27,
-	}, {
-		.name		= "scaler27",
-		.enable		= s3c64xx_sclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_SCLK_SCALER27,
-	}, {
-		.name		= "sclk_scaler",
-		.enable		= s3c64xx_sclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_SCLK_SCALER,
-	}, {
-		.name		= "post0_27",
-		.enable		= s3c64xx_sclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_SCLK_POST0_27,
-	}, {
-		.name		= "secur",
-		.enable		= s3c64xx_sclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_SCLK_SECUR,
-	}, {
-		.name		= "sclk_mfc",
-		.enable		= s3c64xx_sclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_SCLK_MFC,
-	}, {
-		.name		= "sclk_jpeg",
-		.enable		= s3c64xx_sclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_SCLK_JPEG,
-	},
-};
-
-static struct clk clk_48m_spi0 = {
-	.name		= "spi_48m",
-	.devname	= "s3c6410-spi.0",
-	.parent		= &clk_48m,
-	.enable		= s3c64xx_sclk_ctrl,
-	.ctrlbit	= S3C_CLKCON_SCLK_SPI0_48,
-};
-
-static struct clk clk_48m_spi1 = {
-	.name		= "spi_48m",
-	.devname	= "s3c6410-spi.1",
-	.parent		= &clk_48m,
-	.enable		= s3c64xx_sclk_ctrl,
-	.ctrlbit	= S3C_CLKCON_SCLK_SPI1_48,
-};
-
-static struct clk clk_i2s0 = {
-	.name		= "iis",
-	.devname	= "samsung-i2s.0",
-	.parent		= &clk_p,
-	.enable		= s3c64xx_pclk_ctrl,
-	.ctrlbit	= S3C_CLKCON_PCLK_IIS0,
-};
-
-static struct clk clk_i2s1 = {
-	.name		= "iis",
-	.devname	= "samsung-i2s.1",
-	.parent		= &clk_p,
-	.enable		= s3c64xx_pclk_ctrl,
-	.ctrlbit	= S3C_CLKCON_PCLK_IIS1,
-};
-
-#ifdef CONFIG_CPU_S3C6410
-static struct clk clk_i2s2 = {
-	.name		= "iis",
-	.devname	= "samsung-i2s.2",
-	.parent		= &clk_p,
-	.enable		= s3c64xx_pclk_ctrl,
-	.ctrlbit	= S3C6410_CLKCON_PCLK_IIS2,
-};
-#endif
-
-static struct clk init_clocks[] = {
-	{
-		.name		= "lcd",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_LCD,
-	}, {
-		.name		= "gpio",
-		.parent		= &clk_p,
-		.enable		= s3c64xx_pclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_PCLK_GPIO,
-	}, {
-		.name		= "usb-host",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_UHOST,
-	}, {
-		.name		= "otg",
-		.parent		= &clk_h,
-		.enable		= s3c64xx_hclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_HCLK_USB,
-	}, {
-		.name		= "timers",
-		.parent		= &clk_p,
-		.enable		= s3c64xx_pclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_PCLK_PWM,
-	}, {
-		.name		= "uart",
-		.devname	= "s3c6400-uart.0",
-		.parent		= &clk_p,
-		.enable		= s3c64xx_pclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_PCLK_UART0,
-	}, {
-		.name		= "uart",
-		.devname	= "s3c6400-uart.1",
-		.parent		= &clk_p,
-		.enable		= s3c64xx_pclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_PCLK_UART1,
-	}, {
-		.name		= "uart",
-		.devname	= "s3c6400-uart.2",
-		.parent		= &clk_p,
-		.enable		= s3c64xx_pclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_PCLK_UART2,
-	}, {
-		.name		= "uart",
-		.devname	= "s3c6400-uart.3",
-		.parent		= &clk_p,
-		.enable		= s3c64xx_pclk_ctrl,
-		.ctrlbit	= S3C_CLKCON_PCLK_UART3,
-	}, {
-		.name		= "watchdog",
-		.parent		= &clk_p,
-		.ctrlbit	= S3C_CLKCON_PCLK_WDT,
-	},
-};
-
-static struct clk clk_hsmmc0 = {
-	.name		= "hsmmc",
-	.devname	= "s3c-sdhci.0",
-	.parent		= &clk_h,
-	.enable		= s3c64xx_hclk_ctrl,
-	.ctrlbit	= S3C_CLKCON_HCLK_HSMMC0,
-};
-
-static struct clk clk_hsmmc1 = {
-	.name		= "hsmmc",
-	.devname	= "s3c-sdhci.1",
-	.parent		= &clk_h,
-	.enable		= s3c64xx_hclk_ctrl,
-	.ctrlbit	= S3C_CLKCON_HCLK_HSMMC1,
-};
-
-static struct clk clk_hsmmc2 = {
-	.name		= "hsmmc",
-	.devname	= "s3c-sdhci.2",
-	.parent		= &clk_h,
-	.enable		= s3c64xx_hclk_ctrl,
-	.ctrlbit	= S3C_CLKCON_HCLK_HSMMC2,
-};
-
-static struct clk clk_fout_apll = {
-	.name		= "fout_apll",
-};
-
-static struct clk *clk_src_apll_list[] = {
-	[0] = &clk_fin_apll,
-	[1] = &clk_fout_apll,
-};
-
-static struct clksrc_sources clk_src_apll = {
-	.sources	= clk_src_apll_list,
-	.nr_sources	= ARRAY_SIZE(clk_src_apll_list),
-};
-
-static struct clksrc_clk clk_mout_apll = {
-	.clk	= {
-		.name		= "mout_apll",
-	},
-	.reg_src	= { .reg = S3C_CLK_SRC, .shift = 0, .size = 1  },
-	.sources	= &clk_src_apll,
-};
-
-static struct clk *clk_src_epll_list[] = {
-	[0] = &clk_fin_epll,
-	[1] = &clk_fout_epll,
-};
-
-static struct clksrc_sources clk_src_epll = {
-	.sources	= clk_src_epll_list,
-	.nr_sources	= ARRAY_SIZE(clk_src_epll_list),
-};
-
-static struct clksrc_clk clk_mout_epll = {
-	.clk	= {
-		.name		= "mout_epll",
-	},
-	.reg_src	= { .reg = S3C_CLK_SRC, .shift = 2, .size = 1  },
-	.sources	= &clk_src_epll,
-};
-
-static struct clk *clk_src_mpll_list[] = {
-	[0] = &clk_fin_mpll,
-	[1] = &clk_fout_mpll,
-};
-
-static struct clksrc_sources clk_src_mpll = {
-	.sources	= clk_src_mpll_list,
-	.nr_sources	= ARRAY_SIZE(clk_src_mpll_list),
-};
-
-static struct clksrc_clk clk_mout_mpll = {
-	.clk = {
-		.name		= "mout_mpll",
-	},
-	.reg_src	= { .reg = S3C_CLK_SRC, .shift = 1, .size = 1  },
-	.sources	= &clk_src_mpll,
-};
-
-static unsigned int armclk_mask;
-
-static unsigned long s3c64xx_clk_arm_get_rate(struct clk *clk)
-{
-	unsigned long rate = clk_get_rate(clk->parent);
-	u32 clkdiv;
-
-	/* divisor mask starts at bit0, so no need to shift */
-	clkdiv = __raw_readl(S3C_CLK_DIV0) & armclk_mask;
-
-	return rate / (clkdiv + 1);
-}
-
-static unsigned long s3c64xx_clk_arm_round_rate(struct clk *clk,
-						unsigned long rate)
-{
-	unsigned long parent = clk_get_rate(clk->parent);
-	u32 div;
-
-	if (parent < rate)
-		return parent;
-
-	div = (parent / rate) - 1;
-	if (div > armclk_mask)
-		div = armclk_mask;
-
-	return parent / (div + 1);
-}
-
-static int s3c64xx_clk_arm_set_rate(struct clk *clk, unsigned long rate)
-{
-	unsigned long parent = clk_get_rate(clk->parent);
-	u32 div;
-	u32 val;
-
-	if (rate < parent / (armclk_mask + 1))
-		return -EINVAL;
-
-	rate = clk_round_rate(clk, rate);
-	div = clk_get_rate(clk->parent) / rate;
-
-	val = __raw_readl(S3C_CLK_DIV0);
-	val &= ~armclk_mask;
-	val |= (div - 1);
-	__raw_writel(val, S3C_CLK_DIV0);
-
-	return 0;
-
-}
-
-static struct clk clk_arm = {
-	.name		= "armclk",
-	.parent		= &clk_mout_apll.clk,
-	.ops		= &(struct clk_ops) {
-		.get_rate	= s3c64xx_clk_arm_get_rate,
-		.set_rate	= s3c64xx_clk_arm_set_rate,
-		.round_rate	= s3c64xx_clk_arm_round_rate,
-	},
-};
-
-static unsigned long s3c64xx_clk_doutmpll_get_rate(struct clk *clk)
-{
-	unsigned long rate = clk_get_rate(clk->parent);
-
-	printk(KERN_DEBUG "%s: parent is %ld\n", __func__, rate);
-
-	if (__raw_readl(S3C_CLK_DIV0) & S3C6400_CLKDIV0_MPLL_MASK)
-		rate /= 2;
-
-	return rate;
-}
-
-static struct clk_ops clk_dout_ops = {
-	.get_rate	= s3c64xx_clk_doutmpll_get_rate,
-};
-
-static struct clk clk_dout_mpll = {
-	.name		= "dout_mpll",
-	.parent		= &clk_mout_mpll.clk,
-	.ops		= &clk_dout_ops,
-};
-
-static struct clk *clkset_spi_mmc_list[] = {
-	&clk_mout_epll.clk,
-	&clk_dout_mpll,
-	&clk_fin_epll,
-	&clk_27m,
-};
-
-static struct clksrc_sources clkset_spi_mmc = {
-	.sources	= clkset_spi_mmc_list,
-	.nr_sources	= ARRAY_SIZE(clkset_spi_mmc_list),
-};
-
-static struct clk *clkset_irda_list[] = {
-	&clk_mout_epll.clk,
-	&clk_dout_mpll,
-	NULL,
-	&clk_27m,
-};
-
-static struct clksrc_sources clkset_irda = {
-	.sources	= clkset_irda_list,
-	.nr_sources	= ARRAY_SIZE(clkset_irda_list),
-};
-
-static struct clk *clkset_uart_list[] = {
-	&clk_mout_epll.clk,
-	&clk_dout_mpll,
-	NULL,
-	NULL
-};
-
-static struct clksrc_sources clkset_uart = {
-	.sources	= clkset_uart_list,
-	.nr_sources	= ARRAY_SIZE(clkset_uart_list),
-};
-
-static struct clk *clkset_uhost_list[] = {
-	&clk_48m,
-	&clk_mout_epll.clk,
-	&clk_dout_mpll,
-	&clk_fin_epll,
-};
-
-static struct clksrc_sources clkset_uhost = {
-	.sources	= clkset_uhost_list,
-	.nr_sources	= ARRAY_SIZE(clkset_uhost_list),
-};
-
-/* The peripheral clocks are all controlled via clocksource followed
- * by an optional divider and gate stage. We currently roll this into
- * one clock which hides the intermediate clock from the mux.
- *
- * Note, the JPEG clock can only be an even divider...
- *
- * The scaler and LCD clocks depend on the S3C64XX version, and also
- * have a common parent divisor so are not included here.
- */
-
-/* clocks that feed other parts of the clock source tree */
-
-static struct clk clk_iis_cd0 = {
-	.name		= "iis_cdclk0",
-};
-
-static struct clk clk_iis_cd1 = {
-	.name		= "iis_cdclk1",
-};
-
-static struct clk clk_iisv4_cd = {
-	.name		= "iis_cdclk_v4",
-};
-
-static struct clk clk_pcm_cd = {
-	.name		= "pcm_cdclk",
-};
-
-static struct clk *clkset_audio0_list[] = {
-	[0] = &clk_mout_epll.clk,
-	[1] = &clk_dout_mpll,
-	[2] = &clk_fin_epll,
-	[3] = &clk_iis_cd0,
-	[4] = &clk_pcm_cd,
-};
-
-static struct clksrc_sources clkset_audio0 = {
-	.sources	= clkset_audio0_list,
-	.nr_sources	= ARRAY_SIZE(clkset_audio0_list),
-};
-
-static struct clk *clkset_audio1_list[] = {
-	[0] = &clk_mout_epll.clk,
-	[1] = &clk_dout_mpll,
-	[2] = &clk_fin_epll,
-	[3] = &clk_iis_cd1,
-	[4] = &clk_pcm_cd,
-};
-
-static struct clksrc_sources clkset_audio1 = {
-	.sources	= clkset_audio1_list,
-	.nr_sources	= ARRAY_SIZE(clkset_audio1_list),
-};
-
-#ifdef CONFIG_CPU_S3C6410
-static struct clk *clkset_audio2_list[] = {
-	[0] = &clk_mout_epll.clk,
-	[1] = &clk_dout_mpll,
-	[2] = &clk_fin_epll,
-	[3] = &clk_iisv4_cd,
-	[4] = &clk_pcm_cd,
-};
-
-static struct clksrc_sources clkset_audio2 = {
-	.sources	= clkset_audio2_list,
-	.nr_sources	= ARRAY_SIZE(clkset_audio2_list),
-};
-#endif
-
-static struct clksrc_clk clksrcs[] = {
-	{
-		.clk	= {
-			.name		= "usb-bus-host",
-			.ctrlbit        = S3C_CLKCON_SCLK_UHOST,
-			.enable		= s3c64xx_sclk_ctrl,
-		},
-		.reg_src 	= { .reg = S3C_CLK_SRC, .shift = 5, .size = 2  },
-		.reg_div	= { .reg = S3C_CLK_DIV1, .shift = 20, .size = 4  },
-		.sources	= &clkset_uhost,
-	}, {
-		.clk	= {
-			.name		= "irda-bus",
-			.ctrlbit        = S3C_CLKCON_SCLK_IRDA,
-			.enable		= s3c64xx_sclk_ctrl,
-		},
-		.reg_src	= { .reg = S3C_CLK_SRC, .shift = 24, .size = 2  },
-		.reg_div	= { .reg = S3C_CLK_DIV2, .shift = 20, .size = 4  },
-		.sources	= &clkset_irda,
-	}, {
-		.clk	= {
-			.name		= "camera",
-			.ctrlbit        = S3C_CLKCON_SCLK_CAM,
-			.enable		= s3c64xx_sclk_ctrl,
-			.parent		= &clk_h2,
-		},
-		.reg_div	= { .reg = S3C_CLK_DIV0, .shift = 20, .size = 4  },
-	},
-};
-
-/* Where does UCLK0 come from? */
-static struct clksrc_clk clk_sclk_uclk = {
-	.clk	= {
-		.name		= "uclk1",
-		.ctrlbit        = S3C_CLKCON_SCLK_UART,
-		.enable		= s3c64xx_sclk_ctrl,
-	},
-	.reg_src	= { .reg = S3C_CLK_SRC, .shift = 13, .size = 1  },
-	.reg_div	= { .reg = S3C_CLK_DIV2, .shift = 16, .size = 4  },
-	.sources	= &clkset_uart,
-};
-
-static struct clksrc_clk clk_sclk_mmc0 = {
-	.clk	= {
-		.name		= "mmc_bus",
-		.devname	= "s3c-sdhci.0",
-		.ctrlbit        = S3C_CLKCON_SCLK_MMC0,
-		.enable		= s3c64xx_sclk_ctrl,
-	},
-	.reg_src	= { .reg = S3C_CLK_SRC, .shift = 18, .size = 2  },
-	.reg_div	= { .reg = S3C_CLK_DIV1, .shift = 0, .size = 4  },
-	.sources	= &clkset_spi_mmc,
-};
-
-static struct clksrc_clk clk_sclk_mmc1 = {
-	.clk	= {
-		.name		= "mmc_bus",
-		.devname	= "s3c-sdhci.1",
-		.ctrlbit        = S3C_CLKCON_SCLK_MMC1,
-		.enable		= s3c64xx_sclk_ctrl,
-	},
-	.reg_src	= { .reg = S3C_CLK_SRC, .shift = 20, .size = 2  },
-	.reg_div	= { .reg = S3C_CLK_DIV1, .shift = 4, .size = 4  },
-	.sources	= &clkset_spi_mmc,
-};
-
-static struct clksrc_clk clk_sclk_mmc2 = {
-	.clk	= {
-		.name		= "mmc_bus",
-		.devname	= "s3c-sdhci.2",
-		.ctrlbit        = S3C_CLKCON_SCLK_MMC2,
-		.enable		= s3c64xx_sclk_ctrl,
-	},
-	.reg_src	= { .reg = S3C_CLK_SRC, .shift = 22, .size = 2  },
-	.reg_div	= { .reg = S3C_CLK_DIV1, .shift = 8, .size = 4  },
-	.sources	= &clkset_spi_mmc,
-};
-
-static struct clksrc_clk clk_sclk_spi0 = {
-	.clk	= {
-		.name		= "spi-bus",
-		.devname	= "s3c6410-spi.0",
-		.ctrlbit	= S3C_CLKCON_SCLK_SPI0,
-		.enable		= s3c64xx_sclk_ctrl,
-	},
-	.reg_src = { .reg = S3C_CLK_SRC, .shift = 14, .size = 2 },
-	.reg_div = { .reg = S3C_CLK_DIV2, .shift = 0, .size = 4 },
-	.sources = &clkset_spi_mmc,
-};
-
-static struct clksrc_clk clk_sclk_spi1 = {
-	.clk	= {
-		.name		= "spi-bus",
-		.devname	= "s3c6410-spi.1",
-		.ctrlbit	= S3C_CLKCON_SCLK_SPI1,
-		.enable		= s3c64xx_sclk_ctrl,
-	},
-	.reg_src = { .reg = S3C_CLK_SRC, .shift = 16, .size = 2 },
-	.reg_div = { .reg = S3C_CLK_DIV2, .shift = 4, .size = 4 },
-	.sources = &clkset_spi_mmc,
-};
-
-static struct clksrc_clk clk_audio_bus0 = {
-	.clk	= {
-		.name		= "audio-bus",
-		.devname	= "samsung-i2s.0",
-		.ctrlbit	= S3C_CLKCON_SCLK_AUDIO0,
-		.enable		= s3c64xx_sclk_ctrl,
-	},
-	.reg_src	= { .reg = S3C_CLK_SRC, .shift = 7, .size = 3  },
-	.reg_div	= { .reg = S3C_CLK_DIV2, .shift = 8, .size = 4  },
-	.sources	= &clkset_audio0,
-};
-
-static struct clksrc_clk clk_audio_bus1 = {
-	.clk	= {
-		.name		= "audio-bus",
-		.devname	= "samsung-i2s.1",
-		.ctrlbit	= S3C_CLKCON_SCLK_AUDIO1,
-		.enable		= s3c64xx_sclk_ctrl,
-	},
-	.reg_src	= { .reg = S3C_CLK_SRC, .shift = 10, .size = 3  },
-	.reg_div	= { .reg = S3C_CLK_DIV2, .shift = 12, .size = 4  },
-	.sources	= &clkset_audio1,
-};
-
-#ifdef CONFIG_CPU_S3C6410
-static struct clksrc_clk clk_audio_bus2 = {
-	.clk	= {
-		.name		= "audio-bus",
-		.devname	= "samsung-i2s.2",
-		.ctrlbit	= S3C6410_CLKCON_SCLK_AUDIO2,
-		.enable		= s3c64xx_sclk_ctrl,
-	},
-	.reg_src	= { .reg = S3C6410_CLK_SRC2, .shift = 0, .size = 3  },
-	.reg_div	= { .reg = S3C_CLK_DIV2, .shift = 24, .size = 4  },
-	.sources	= &clkset_audio2,
-};
-#endif
-/* Clock initialisation code */
-
-static struct clksrc_clk *init_parents[] = {
-	&clk_mout_apll,
-	&clk_mout_epll,
-	&clk_mout_mpll,
-};
-
-static struct clksrc_clk *clksrc_cdev[] = {
-	&clk_sclk_uclk,
-	&clk_sclk_mmc0,
-	&clk_sclk_mmc1,
-	&clk_sclk_mmc2,
-	&clk_sclk_spi0,
-	&clk_sclk_spi1,
-	&clk_audio_bus0,
-	&clk_audio_bus1,
-};
-
-static struct clk *clk_cdev[] = {
-	&clk_hsmmc0,
-	&clk_hsmmc1,
-	&clk_hsmmc2,
-	&clk_48m_spi0,
-	&clk_48m_spi1,
-	&clk_i2s0,
-	&clk_i2s1,
-};
-
-static struct clk_lookup s3c64xx_clk_lookup[] = {
-	CLKDEV_INIT(NULL, "clk_uart_baud2", &clk_p),
-	CLKDEV_INIT(NULL, "clk_uart_baud3", &clk_sclk_uclk.clk),
-	CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.0", &clk_hsmmc0),
-	CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.0", &clk_hsmmc1),
-	CLKDEV_INIT("s3c-sdhci.2", "mmc_busclk.0", &clk_hsmmc2),
-	CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.2", &clk_sclk_mmc0.clk),
-	CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2", &clk_sclk_mmc1.clk),
-	CLKDEV_INIT("s3c-sdhci.2", "mmc_busclk.2", &clk_sclk_mmc2.clk),
-	CLKDEV_INIT(NULL, "spi_busclk0", &clk_p),
-	CLKDEV_INIT("s3c6410-spi.0", "spi_busclk1", &clk_sclk_spi0.clk),
-	CLKDEV_INIT("s3c6410-spi.0", "spi_busclk2", &clk_48m_spi0),
-	CLKDEV_INIT("s3c6410-spi.1", "spi_busclk1", &clk_sclk_spi1.clk),
-	CLKDEV_INIT("s3c6410-spi.1", "spi_busclk2", &clk_48m_spi1),
-	CLKDEV_INIT("samsung-i2s.0", "i2s_opclk0", &clk_i2s0),
-	CLKDEV_INIT("samsung-i2s.0", "i2s_opclk1", &clk_audio_bus0.clk),
-	CLKDEV_INIT("samsung-i2s.1", "i2s_opclk0", &clk_i2s1),
-	CLKDEV_INIT("samsung-i2s.1", "i2s_opclk1", &clk_audio_bus1.clk),
-#ifdef CONFIG_CPU_S3C6410
-	CLKDEV_INIT("samsung-i2s.2", "i2s_opclk0", &clk_i2s2),
-	CLKDEV_INIT("samsung-i2s.2", "i2s_opclk1", &clk_audio_bus2.clk),
-#endif
-};
-
-#define GET_DIV(clk, field) ((((clk) & field##_MASK) >> field##_SHIFT) + 1)
-
-void __init_or_cpufreq s3c64xx_setup_clocks(void)
-{
-	struct clk *xtal_clk;
-	unsigned long xtal;
-	unsigned long fclk;
-	unsigned long hclk;
-	unsigned long hclk2;
-	unsigned long pclk;
-	unsigned long epll;
-	unsigned long apll;
-	unsigned long mpll;
-	unsigned int ptr;
-	u32 clkdiv0;
-
-	printk(KERN_DEBUG "%s: registering clocks\n", __func__);
-
-	clkdiv0 = __raw_readl(S3C_CLK_DIV0);
-	printk(KERN_DEBUG "%s: clkdiv0 = %08x\n", __func__, clkdiv0);
-
-	xtal_clk = clk_get(NULL, "xtal");
-	BUG_ON(IS_ERR(xtal_clk));
-
-	xtal = clk_get_rate(xtal_clk);
-	clk_put(xtal_clk);
-
-	printk(KERN_DEBUG "%s: xtal is %ld\n", __func__, xtal);
-
-	/* For now assume the mux always selects the crystal */
-	clk_ext_xtal_mux.parent = xtal_clk;
-
-	epll = s3c_get_pll6553x(xtal, __raw_readl(S3C_EPLL_CON0),
-				__raw_readl(S3C_EPLL_CON1));
-	mpll = s3c6400_get_pll(xtal, __raw_readl(S3C_MPLL_CON));
-	apll = s3c6400_get_pll(xtal, __raw_readl(S3C_APLL_CON));
-
-	fclk = mpll;
-
-	printk(KERN_INFO "S3C64XX: PLL settings, A=%ld, M=%ld, E=%ld\n",
-	       apll, mpll, epll);
-
-	if(__raw_readl(S3C64XX_OTHERS) & S3C64XX_OTHERS_SYNCMUXSEL)
-		/* Synchronous mode */
-		hclk2 = apll / GET_DIV(clkdiv0, S3C6400_CLKDIV0_HCLK2);
-	else
-		/* Asynchronous mode */
-		hclk2 = mpll / GET_DIV(clkdiv0, S3C6400_CLKDIV0_HCLK2);
-
-	hclk = hclk2 / GET_DIV(clkdiv0, S3C6400_CLKDIV0_HCLK);
-	pclk = hclk2 / GET_DIV(clkdiv0, S3C6400_CLKDIV0_PCLK);
-
-	printk(KERN_INFO "S3C64XX: HCLK2=%ld, HCLK=%ld, PCLK=%ld\n",
-	       hclk2, hclk, pclk);
-
-	clk_fout_mpll.rate = mpll;
-	clk_fout_epll.rate = epll;
-	clk_fout_apll.rate = apll;
-
-	clk_h2.rate = hclk2;
-	clk_h.rate = hclk;
-	clk_p.rate = pclk;
-	clk_f.rate = fclk;
-
-	for (ptr = 0; ptr < ARRAY_SIZE(init_parents); ptr++)
-		s3c_set_clksrc(init_parents[ptr], true);
-
-	for (ptr = 0; ptr < ARRAY_SIZE(clksrcs); ptr++)
-		s3c_set_clksrc(&clksrcs[ptr], true);
-}
-
-static struct clk *clks1[] __initdata = {
-	&clk_ext_xtal_mux,
-	&clk_iis_cd0,
-	&clk_iis_cd1,
-	&clk_iisv4_cd,
-	&clk_pcm_cd,
-	&clk_mout_epll.clk,
-	&clk_mout_mpll.clk,
-	&clk_dout_mpll,
-	&clk_arm,
-};
-
-static struct clk *clks[] __initdata = {
-	&clk_ext,
-	&clk_epll,
-	&clk_27m,
-	&clk_48m,
-	&clk_h2,
-	&clk_xusbxti,
-};
-
-/**
- * s3c64xx_register_clocks - register clocks for s3c6400 and s3c6410
- * @xtal: The rate for the clock crystal feeding the PLLs.
- * @armclk_divlimit: Divisor mask for ARMCLK.
- *
- * Register the clocks for the S3C6400 and S3C6410 SoC range, such
- * as ARMCLK as well as the necessary parent clocks.
- *
- * This call does not setup the clocks, which is left to the
- * s3c64xx_setup_clocks() call which may be needed by the cpufreq
- * or resume code to re-set the clocks if the bootloader has changed
- * them.
- */
-void __init s3c64xx_register_clocks(unsigned long xtal, 
-				    unsigned armclk_divlimit)
-{
-	unsigned int cnt;
-
-	armclk_mask = armclk_divlimit;
-
-	s3c24xx_register_baseclocks(xtal);
-	s3c24xx_register_clocks(clks, ARRAY_SIZE(clks));
-
-	s3c_register_clocks(init_clocks, ARRAY_SIZE(init_clocks));
-
-	s3c_register_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
-	s3c_disable_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
-
-	s3c24xx_register_clocks(clk_cdev, ARRAY_SIZE(clk_cdev));
-	for (cnt = 0; cnt < ARRAY_SIZE(clk_cdev); cnt++)
-		s3c_disable_clocks(clk_cdev[cnt], 1);
-
-	s3c24xx_register_clocks(clks1, ARRAY_SIZE(clks1));
-	s3c_register_clksrc(clksrcs, ARRAY_SIZE(clksrcs));
-	for (cnt = 0; cnt < ARRAY_SIZE(clksrc_cdev); cnt++)
-		s3c_register_clksrc(clksrc_cdev[cnt], 1);
-	clkdev_add_table(s3c64xx_clk_lookup, ARRAY_SIZE(s3c64xx_clk_lookup));
-}
diff --git a/arch/arm/mach-s3c64xx/common.h b/arch/arm/mach-s3c64xx/common.h
index a2af0e1..bd3bd56 100644
--- a/arch/arm/mach-s3c64xx/common.h
+++ b/arch/arm/mach-s3c64xx/common.h
@@ -37,7 +37,6 @@ extern void s3c6400_init_irq(void);
 extern void s3c6400_map_io(void);
 
 #else
-#define s3c6400_init_clocks NULL
 #define s3c6400_map_io NULL
 #define s3c6400_init NULL
 #endif
@@ -49,7 +48,6 @@ extern void s3c6410_init_irq(void);
 extern void s3c6410_map_io(void);
 
 #else
-#define s3c6410_init_clocks NULL
 #define s3c6410_map_io NULL
 #define s3c6410_init NULL
 #endif
diff --git a/arch/arm/mach-s3c64xx/include/mach/regs-clock.h b/arch/arm/mach-s3c64xx/include/mach/regs-clock.h
index 05332b9..4f44aac 100644
--- a/arch/arm/mach-s3c64xx/include/mach/regs-clock.h
+++ b/arch/arm/mach-s3c64xx/include/mach/regs-clock.h
@@ -15,145 +15,21 @@
 #ifndef __PLAT_REGS_CLOCK_H
 #define __PLAT_REGS_CLOCK_H __FILE__
 
+/*
+ * FIXME: Remove remaining definitions
+ */
+
 #define S3C_CLKREG(x)		(S3C_VA_SYS + (x))
 
-#define S3C_APLL_LOCK		S3C_CLKREG(0x00)
-#define S3C_MPLL_LOCK		S3C_CLKREG(0x04)
-#define S3C_EPLL_LOCK		S3C_CLKREG(0x08)
-#define S3C_APLL_CON		S3C_CLKREG(0x0C)
-#define S3C_MPLL_CON		S3C_CLKREG(0x10)
-#define S3C_EPLL_CON0		S3C_CLKREG(0x14)
-#define S3C_EPLL_CON1		S3C_CLKREG(0x18)
-#define S3C_CLK_SRC		S3C_CLKREG(0x1C)
-#define S3C_CLK_DIV0		S3C_CLKREG(0x20)
-#define S3C_CLK_DIV1		S3C_CLKREG(0x24)
-#define S3C_CLK_DIV2		S3C_CLKREG(0x28)
-#define S3C_CLK_OUT		S3C_CLKREG(0x2C)
-#define S3C_HCLK_GATE		S3C_CLKREG(0x30)
 #define S3C_PCLK_GATE		S3C_CLKREG(0x34)
-#define S3C_SCLK_GATE		S3C_CLKREG(0x38)
-#define S3C_MEM0_GATE		S3C_CLKREG(0x3C)
 #define S3C6410_CLK_SRC2	S3C_CLKREG(0x10C)
 #define S3C_MEM_SYS_CFG		S3C_CLKREG(0x120)
 
-/* CLKDIV0 */
-#define S3C6400_CLKDIV0_PCLK_MASK	(0xf << 12)
-#define S3C6400_CLKDIV0_PCLK_SHIFT	(12)
-#define S3C6400_CLKDIV0_HCLK2_MASK	(0x7 << 9)
-#define S3C6400_CLKDIV0_HCLK2_SHIFT	(9)
-#define S3C6400_CLKDIV0_HCLK_MASK	(0x1 << 8)
-#define S3C6400_CLKDIV0_HCLK_SHIFT	(8)
-#define S3C6400_CLKDIV0_MPLL_MASK	(0x1 << 4)
-#define S3C6400_CLKDIV0_MPLL_SHIFT	(4)
-
-#define S3C6400_CLKDIV0_ARM_MASK	(0x7 << 0)
-#define S3C6410_CLKDIV0_ARM_MASK	(0xf << 0)
-#define S3C6400_CLKDIV0_ARM_SHIFT	(0)
-
-/* HCLK GATE Registers */
-#define S3C_CLKCON_HCLK_3DSE	(1<<31)
-#define S3C_CLKCON_HCLK_UHOST	(1<<29)
-#define S3C_CLKCON_HCLK_SECUR	(1<<28)
-#define S3C_CLKCON_HCLK_SDMA1	(1<<27)
-#define S3C_CLKCON_HCLK_SDMA0	(1<<26)
-#define S3C_CLKCON_HCLK_IROM	(1<<25)
-#define S3C_CLKCON_HCLK_DDR1	(1<<24)
-#define S3C_CLKCON_HCLK_DDR0	(1<<23)
-#define S3C_CLKCON_HCLK_MEM1	(1<<22)
-#define S3C_CLKCON_HCLK_MEM0	(1<<21)
-#define S3C_CLKCON_HCLK_USB	(1<<20)
-#define S3C_CLKCON_HCLK_HSMMC2	(1<<19)
-#define S3C_CLKCON_HCLK_HSMMC1	(1<<18)
-#define S3C_CLKCON_HCLK_HSMMC0	(1<<17)
-#define S3C_CLKCON_HCLK_MDP	(1<<16)
-#define S3C_CLKCON_HCLK_DHOST	(1<<15)
-#define S3C_CLKCON_HCLK_IHOST	(1<<14)
-#define S3C_CLKCON_HCLK_DMA1	(1<<13)
-#define S3C_CLKCON_HCLK_DMA0	(1<<12)
-#define S3C_CLKCON_HCLK_JPEG	(1<<11)
-#define S3C_CLKCON_HCLK_CAMIF	(1<<10)
-#define S3C_CLKCON_HCLK_SCALER	(1<<9)
-#define S3C_CLKCON_HCLK_2D	(1<<8)
-#define S3C_CLKCON_HCLK_TV	(1<<7)
-#define S3C_CLKCON_HCLK_POST0	(1<<5)
-#define S3C_CLKCON_HCLK_ROT	(1<<4)
-#define S3C_CLKCON_HCLK_LCD	(1<<3)
-#define S3C_CLKCON_HCLK_TZIC	(1<<2)
-#define S3C_CLKCON_HCLK_INTC	(1<<1)
-#define S3C_CLKCON_HCLK_MFC	(1<<0)
-
 /* PCLK GATE Registers */
-#define S3C6410_CLKCON_PCLK_I2C1	(1<<27)
-#define S3C6410_CLKCON_PCLK_IIS2	(1<<26)
-#define S3C_CLKCON_PCLK_SKEY		(1<<24)
-#define S3C_CLKCON_PCLK_CHIPID		(1<<23)
-#define S3C_CLKCON_PCLK_SPI1		(1<<22)
-#define S3C_CLKCON_PCLK_SPI0		(1<<21)
-#define S3C_CLKCON_PCLK_HSIRX		(1<<20)
-#define S3C_CLKCON_PCLK_HSITX		(1<<19)
-#define S3C_CLKCON_PCLK_GPIO		(1<<18)
-#define S3C_CLKCON_PCLK_IIC		(1<<17)
-#define S3C_CLKCON_PCLK_IIS1		(1<<16)
-#define S3C_CLKCON_PCLK_IIS0		(1<<15)
-#define S3C_CLKCON_PCLK_AC97		(1<<14)
-#define S3C_CLKCON_PCLK_TZPC		(1<<13)
-#define S3C_CLKCON_PCLK_TSADC		(1<<12)
-#define S3C_CLKCON_PCLK_KEYPAD		(1<<11)
-#define S3C_CLKCON_PCLK_IRDA		(1<<10)
-#define S3C_CLKCON_PCLK_PCM1		(1<<9)
-#define S3C_CLKCON_PCLK_PCM0		(1<<8)
-#define S3C_CLKCON_PCLK_PWM		(1<<7)
-#define S3C_CLKCON_PCLK_RTC		(1<<6)
-#define S3C_CLKCON_PCLK_WDT		(1<<5)
 #define S3C_CLKCON_PCLK_UART3		(1<<4)
 #define S3C_CLKCON_PCLK_UART2		(1<<3)
 #define S3C_CLKCON_PCLK_UART1		(1<<2)
 #define S3C_CLKCON_PCLK_UART0		(1<<1)
-#define S3C_CLKCON_PCLK_MFC		(1<<0)
-
-/* SCLK GATE Registers */
-#define S3C_CLKCON_SCLK_UHOST		(1<<30)
-#define S3C_CLKCON_SCLK_MMC2_48		(1<<29)
-#define S3C_CLKCON_SCLK_MMC1_48		(1<<28)
-#define S3C_CLKCON_SCLK_MMC0_48		(1<<27)
-#define S3C_CLKCON_SCLK_MMC2		(1<<26)
-#define S3C_CLKCON_SCLK_MMC1		(1<<25)
-#define S3C_CLKCON_SCLK_MMC0		(1<<24)
-#define S3C_CLKCON_SCLK_SPI1_48 	(1<<23)
-#define S3C_CLKCON_SCLK_SPI0_48 	(1<<22)
-#define S3C_CLKCON_SCLK_SPI1		(1<<21)
-#define S3C_CLKCON_SCLK_SPI0		(1<<20)
-#define S3C_CLKCON_SCLK_DAC27		(1<<19)
-#define S3C_CLKCON_SCLK_TV27		(1<<18)
-#define S3C_CLKCON_SCLK_SCALER27	(1<<17)
-#define S3C_CLKCON_SCLK_SCALER		(1<<16)
-#define S3C_CLKCON_SCLK_LCD27		(1<<15)
-#define S3C_CLKCON_SCLK_LCD		(1<<14)
-#define S3C6400_CLKCON_SCLK_POST1_27	(1<<13)
-#define S3C6410_CLKCON_FIMC		(1<<13)
-#define S3C_CLKCON_SCLK_POST0_27	(1<<12)
-#define S3C6400_CLKCON_SCLK_POST1	(1<<11)
-#define S3C6410_CLKCON_SCLK_AUDIO2	(1<<11)
-#define S3C_CLKCON_SCLK_POST0		(1<<10)
-#define S3C_CLKCON_SCLK_AUDIO1		(1<<9)
-#define S3C_CLKCON_SCLK_AUDIO0		(1<<8)
-#define S3C_CLKCON_SCLK_SECUR		(1<<7)
-#define S3C_CLKCON_SCLK_IRDA		(1<<6)
-#define S3C_CLKCON_SCLK_UART		(1<<5)
-#define S3C_CLKCON_SCLK_ONENAND 	(1<<4)
-#define S3C_CLKCON_SCLK_MFC		(1<<3)
-#define S3C_CLKCON_SCLK_CAM		(1<<2)
-#define S3C_CLKCON_SCLK_JPEG		(1<<1)
-
-/* CLKSRC */
-
-#define S3C6400_CLKSRC_APLL_MOUT	(1 << 0)
-#define S3C6400_CLKSRC_MPLL_MOUT	(1 << 1)
-#define S3C6400_CLKSRC_EPLL_MOUT	(1 << 2)
-#define S3C6400_CLKSRC_APLL_MOUT_SHIFT	(0)
-#define S3C6400_CLKSRC_MPLL_MOUT_SHIFT	(1)
-#define S3C6400_CLKSRC_EPLL_MOUT_SHIFT	(2)
-#define S3C6400_CLKSRC_MFC		(1 << 4)
 
 /* MEM_SYS_CFG */
 #define MEM_SYS_CFG_INDEP_CF		0x4000
diff --git a/arch/arm/mach-s3c64xx/pm.c b/arch/arm/mach-s3c64xx/pm.c
index 6a1f91f..8cdb824 100644
--- a/arch/arm/mach-s3c64xx/pm.c
+++ b/arch/arm/mach-s3c64xx/pm.c
@@ -194,29 +194,8 @@ void s3c_pm_debug_smdkled(u32 set, u32 clear)
 #endif
 
 static struct sleep_save core_save[] = {
-	SAVE_ITEM(S3C_APLL_LOCK),
-	SAVE_ITEM(S3C_MPLL_LOCK),
-	SAVE_ITEM(S3C_EPLL_LOCK),
-	SAVE_ITEM(S3C_CLK_SRC),
-	SAVE_ITEM(S3C_CLK_DIV0),
-	SAVE_ITEM(S3C_CLK_DIV1),
-	SAVE_ITEM(S3C_CLK_DIV2),
-	SAVE_ITEM(S3C_CLK_OUT),
-	SAVE_ITEM(S3C_HCLK_GATE),
-	SAVE_ITEM(S3C_PCLK_GATE),
-	SAVE_ITEM(S3C_SCLK_GATE),
-	SAVE_ITEM(S3C_MEM0_GATE),
-
-	SAVE_ITEM(S3C_EPLL_CON1),
-	SAVE_ITEM(S3C_EPLL_CON0),
-
 	SAVE_ITEM(S3C64XX_MEM0DRVCON),
 	SAVE_ITEM(S3C64XX_MEM1DRVCON),
-
-#ifndef CONFIG_CPU_FREQ
-	SAVE_ITEM(S3C_APLL_CON),
-	SAVE_ITEM(S3C_MPLL_CON),
-#endif
 };
 
 static struct sleep_save misc_save[] = {
-- 
1.8.3.2



From cavokz at gmail.com  Mon Jul 22 19:52:38 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Tue, 23 Jul 2013 01:52:38 +0200
Subject: [PATCH 1/5] ARM: bcm4760: Add platform infrastructure
In-Reply-To: <201307211400.21295.arnd@arndb.de>
References: <20130721002320.730568671@gmail.com>
 <201307211009.31789.arnd@arndb.de>
 <d40f0756-7ba0-4416-9576-63470274be1b@email.android.com>
 <201307211400.21295.arnd@arndb.de>
Message-ID: <20130722235238.GC6665@glitch>

On Sun, Jul 21, 2013 at 02:00:21PM +0200, Arnd Bergmann wrote:
> On Sunday 21 July 2013, Domenico Andreoli wrote:
> > >bonus points if you use soc_device_register();
> > >
> > >What is the system_rev variable actually used for?
> > 
> > I use it to show something sensible in /proc/cpuinfo, to report
> > whether the soc is  a 4760 or 4761 and the silicon revision.
> > 
> > If the proper way to deal with this has so much boilerplate as
> > you say, I think I'll drop it altogether. I'd like to print the info
> > somewhere in the bootlog anyway.
> > 
> > btw this could well be one of the accesses requiring the io
> > mapping above.
> 
> If it's just for informational purposes, soc_device_register() sounds like
> the correct place to put that information, you can register a couple
> of strings there that get put into sysfs at a known location for the
> SoC, and keeps the cpuinfo for the actual CPU core.
> 
> 	Arnd

I've implemented the registration using soc_device_register() but I've
postponed to a later stage, these registers are in block I need to add
later also for the clocks.

This showed to be also the only user of the early io mapping, which is
now gone.

I'll respin the patchset as soon as you suggest what to do with the
clock-frequency of the system timer.

BRs,
Domenico


From festevam at gmail.com  Mon Jul 22 20:15:12 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 22 Jul 2013 21:15:12 -0300
Subject: [PATCH v2 6/8] usb: host: ohci-s3c2410 Use
 clk_prepare_enable/clk_disable_unprepare
In-Reply-To: <1374536965-3545-7-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
 <1374536965-3545-7-git-send-email-tomasz.figa@gmail.com>
Message-ID: <CAOMZO5D4X+GT+LdUOjorJ8xgBCwv9iAP4W-RzKrbnE-93kxmUg@mail.gmail.com>

On Mon, Jul 22, 2013 at 8:49 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:

>         dev_dbg(&dev->dev, "s3c2410_start_hc:\n");
>
> -       clk_enable(usb_clk);
> +       clk_prepare_enable(usb_clk);

 clk_prepare_enable may fail, so you would better check its return value.


From bhelgaas at google.com  Mon Jul 22 20:30:26 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Mon, 22 Jul 2013 18:30:26 -0600
Subject: [PATCHv5 00/11] MSI support for Marvell EBU PCIe driver
In-Reply-To: <20130716234307.3d5ed229@skate>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E4167B.4000208@wwwdotorg.org>
 <20130715162709.GA24625@dhcp-172-17-186-34.nvidia.com>
 <20130716103351.15b0fb50@skate>
 <20130716210509.GA29318@dhcp-172-17-186-34.nvidia.com>
 <20130716234307.3d5ed229@skate>
Message-ID: <CAErSpo5G=d=WsN0MnXrwYa4HgTVFre5QYj+hDeHGVXnz-Aeygg@mail.gmail.com>

On Tue, Jul 16, 2013 at 3:43 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Thierry,
>
> On Tue, 16 Jul 2013 14:05:10 -0700, Thierry Reding wrote:
>
>> > This is from:
>> >
>> > Subject: Re: [PATCH v2 6/8] pci: mvebu: add support for MSI
>> > Date: Tue, 18 Jun 2013 16:57:11 -0600
>>
>> Yes, I'm aware of that discussion. However we currently need to have the
>> custom root bus scan implementation anyway because pci_scan_root_bus()
>> just doesn't work on ARM. So again, since we'll have to rework the
>> driver anyway in order to use pci_scan_root_bus() once the issues have
>> been resolved, it wouldn't hurt to postpone the transition to the new
>> ARM pcibios_add_bus() support until that point.
>>
>> All I was trying to do was reduce the list of common dependencies in an
>> attempt to make merging it easier.
>
> Understood. Bjorn, since you are the one who originally requested
> the usage of pcibios_add_bus(), would you agree with the idea proposed
> by Thierry? It would remove one dependency for both the Marvell MSI
> support and Tegra PCIe support, which would help getting this code
> merged.
>
> As Thierry points out, this can easily be resolved at a later point,
> once the new hooks are merged in the ARM PCI core.

Yep, that's fine with me.


From konrad.wilk at oracle.com  Mon Jul 22 20:32:06 2013
From: konrad.wilk at oracle.com (Konrad Rzeszutek Wilk)
Date: Mon, 22 Jul 2013 20:32:06 -0400
Subject: [PATCH v4] xen/arm: enable PV control for ARM
In-Reply-To: <1374529321-12955-1-git-send-email-julien.grall@linaro.org>
References: <1374529321-12955-1-git-send-email-julien.grall@linaro.org>
Message-ID: <5228e08a-1cdb-4240-b10f-9ad690c94ac4@email.android.com>

Julien Grall <julien.grall at linaro.org> wrote:
>Enable power management from the toolstack for ARM guest.
>
>Signed-off-by: Julien Grall <julien.grall at linaro.org>
>
>---
>    Changes in v4:
>        - Divide the patch in 2 distinct parts
>    Changes in v3:
>        - Fix condition to compile cpu_hotplug.o
>    Changes in v2:
>        - Don't compile xen/cpu_hotplug.o with ARM64
>---
> drivers/xen/Makefile |    3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
>diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
>index a609353..f185e8d 100644
>--- a/drivers/xen/Makefile
>+++ b/drivers/xen/Makefile
>@@ -1,9 +1,8 @@
> ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
>-obj-y	+= manage.o
> obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
> endif
> obj-$(CONFIG_X86)			+= fallback.o
>-obj-y	+= grant-table.o features.o events.o balloon.o time.o
>+obj-y	+= grant-table.o features.o events.o balloon.o time.o manage.o
> obj-y	+= xenbus/
> 
> nostackp := $(call cc-option, -fno-stack-protector)

The patch looks Ok but the description is off.  Power management is the term used for cpu freq,  C states and P states. While this patch touches none of that. 


From tomasz.figa at gmail.com  Mon Jul 22 20:44:59 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 02:44:59 +0200
Subject: [PATCH v2 6/8] usb: host: ohci-s3c2410 Use
 clk_prepare_enable/clk_disable_unprepare
In-Reply-To: <CAOMZO5D4X+GT+LdUOjorJ8xgBCwv9iAP4W-RzKrbnE-93kxmUg@mail.gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
 <1374536965-3545-7-git-send-email-tomasz.figa@gmail.com>
 <CAOMZO5D4X+GT+LdUOjorJ8xgBCwv9iAP4W-RzKrbnE-93kxmUg@mail.gmail.com>
Message-ID: <1749259.aa65CrEVoR@flatron>

On Monday 22 of July 2013 21:15:12 Fabio Estevam wrote:
> On Mon, Jul 22, 2013 at 8:49 PM, Tomasz Figa <tomasz.figa at gmail.com> 
wrote:
> >         dev_dbg(&dev->dev, "s3c2410_start_hc:\n");
> > 
> > -       clk_enable(usb_clk);
> > +       clk_prepare_enable(usb_clk);
> 
>  clk_prepare_enable may fail, so you would better check its return
> value.

Well, ideally yes, but since this driver doesn't have any error path here 
anyway and on Samsung platforms clk_prepare_enable() simply can't fail, 
I'd keep it this way until somebody fixes this driver, as it has more 
issues than just this one.

Best regards,
Tomasz



From emilio at elopez.com.ar  Mon Jul 22 21:01:05 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Mon, 22 Jul 2013 22:01:05 -0300
Subject: [PATCH RFC 1/8] clk: sunxi: fix initialization of basic clocks
In-Reply-To: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
References: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1374541272-32173-2-git-send-email-emilio@elopez.com.ar>

With the recent move towards CLK_OF_DECLARE(...), the driver stopped
initializing osc32k, which is compatible "fixed-clock". This is because
we never called of_clk_init(NULL). Fix this by moving the only other
simple clock (osc24M) to use CLK_OF_DECLARE(...) and call of_clk_init(NULL)
to initialize both of them.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 drivers/clk/sunxi/clk-sunxi.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 412912b..323366b 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -411,10 +411,7 @@ static void __init sunxi_gates_clk_setup(struct device_node *node,
 }
 
 /* Matches for of_clk_init */
-static const __initconst struct of_device_id clk_match[] = {
-	{.compatible = "allwinner,sun4i-osc-clk", .data = sunxi_osc_clk_setup,},
-	{}
-};
+CLK_OF_DECLARE(sunxi_osc, "allwinner,sun4i-osc-clk", sunxi_osc_clk_setup);
 
 /* Matches for factors clocks */
 static const __initconst struct of_device_id clk_factors_match[] = {
@@ -467,8 +464,8 @@ static void __init of_sunxi_table_clock_setup(const struct of_device_id *clk_mat
 
 void __init sunxi_init_clocks(void)
 {
-	/* Register all the simple sunxi clocks on DT */
-	of_clk_init(clk_match);
+	/* Register all the simple and basic clocks on DT */
+	of_clk_init(NULL);
 
 	/* Register factor clocks */
 	of_sunxi_table_clock_setup(clk_factors_match, sunxi_factors_clk_setup);
-- 
1.8.3.3



From emilio at elopez.com.ar  Mon Jul 22 21:01:07 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Mon, 22 Jul 2013 22:01:07 -0300
Subject: [PATCH RFC 3/8] clk: sunxi: add gating support to PLL1
In-Reply-To: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
References: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1374541272-32173-4-git-send-email-emilio@elopez.com.ar>

This commit adds gating support to PLL1 on the clock driver. This makes
the PLL1 implementation fully compatible with PLL4 as well.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 Documentation/devicetree/bindings/clock/sunxi.txt | 2 +-
 drivers/clk/sunxi/clk-sunxi.c                     | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index d495521..9a28022 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -7,7 +7,7 @@ This binding uses the common clock binding[1].
 Required properties:
 - compatible : shall be one of the following:
 	"allwinner,sun4i-osc-clk" - for a gatable oscillator
-	"allwinner,sun4i-pll1-clk" - for the main PLL clock
+	"allwinner,sun4i-pll1-clk" - for the main PLL clock as well as PLL4
 	"allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
 	"allwinner,sun4i-axi-clk" - for the AXI clock
 	"allwinner,sun4i-axi-gates-clk" - for the AXI gates
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index f258a20..4dccdb9 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -201,6 +201,7 @@ static struct clk_factors_config apb1_config = {
 };
 
 static const __initconst struct factors_data pll1_data = {
+	.enable = 31,
 	.table = &pll1_config,
 	.getter = sunxi_get_pll1_factors,
 };
-- 
1.8.3.3



From emilio at elopez.com.ar  Mon Jul 22 21:01:04 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Mon, 22 Jul 2013 22:01:04 -0300
Subject: [PATCH RFC 0/8] sunxi clk: PLL4/5/6 and module 0 support
Message-ID: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>

Hi everyone,

This patchset provides more clock support for the sunxi platform. Its 
main aim is to implement support for PLL4, 5 and 6, as well as 
MOD0-style clocks, used for various components such as MMC and IR.

The first patch fixes a small regression found while testing on 
3.11-rc1. It does not affect the system in any way though, so there is 
no real need to submit it as an rc fix.

The second patch reworks the way factor clocks are registered. By doing 
so behind a composite clock, we gain the ability to divide, mux or gate 
these clocks. This comes in handy to implement PLL5, PLL6 and MOD0

The third patch adds gating support to PLL1, and by doing so, it also 
becomes bit-compatible with PLL4. The fourth patch adds a node on DT to 
get PLL4 supported this way.

The fifth and sixth patches implement support for PLL5 and 6 on the 
driver and adding the DT node, respectively.

Patches 7 and 8 implement support for module 0 style clocks and add all
the corresponding DT nodes for sun4i.

I have marked this series as RFC as I still need to write the bindings 
for sun5i mod0 clocks and might change a thing or two on the other patches,
but I wanted to get this code out there for review early this cycle.

As always, any comments will be highly appreciated.

Thanks,

Emilio

Emilio L?pez (8):
  clk: sunxi: fix initialization of basic clocks
  clk: sunxi: register factors clocks behind composite
  clk: sunxi: add gating support to PLL1
  ARM: sunxi: add PLL4 support
  clk: sunxi: add PLL5 and PLL6 support
  ARM: sunxi: add PLL5 and PLL6 support
  clk: sunxi: mod0 support
  ARM: sun4i: mod0 clocks

 Documentation/devicetree/bindings/clock/sunxi.txt |   5 +-
 arch/arm/boot/dts/sun4i-a10.dtsi                  | 131 +++++++++-
 arch/arm/boot/dts/sun5i-a10s.dtsi                 |  26 +-
 arch/arm/boot/dts/sun5i-a13.dtsi                  |  26 +-
 drivers/clk/sunxi/clk-factors.c                   |  63 +----
 drivers/clk/sunxi/clk-factors.h                   |  16 +-
 drivers/clk/sunxi/clk-sunxi.c                     | 285 +++++++++++++++++++++-
 7 files changed, 466 insertions(+), 86 deletions(-)

-- 
1.8.3.3



From emilio at elopez.com.ar  Mon Jul 22 21:01:06 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Mon, 22 Jul 2013 22:01:06 -0300
Subject: [PATCH RFC 2/8] clk: sunxi: register factors clocks behind composite
In-Reply-To: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
References: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1374541272-32173-3-git-send-email-emilio@elopez.com.ar>

This commit reworks factors clock registration to be done behind a
composite clock. This allows us to additionally add a gate, mux or
divisors, as it will be needed by some future PLLs.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 drivers/clk/sunxi/clk-factors.c | 63 +--------------------------------------
 drivers/clk/sunxi/clk-factors.h | 16 +++++-----
 drivers/clk/sunxi/clk-sunxi.c   | 66 ++++++++++++++++++++++++++++++++++++++---
 3 files changed, 72 insertions(+), 73 deletions(-)

diff --git a/drivers/clk/sunxi/clk-factors.c b/drivers/clk/sunxi/clk-factors.c
index 88523f9..6e3926c 100644
--- a/drivers/clk/sunxi/clk-factors.c
+++ b/drivers/clk/sunxi/clk-factors.c
@@ -30,14 +30,6 @@
  * parent - fixed parent.  No clk_set_parent support
  */
 
-struct clk_factors {
-	struct clk_hw hw;
-	void __iomem *reg;
-	struct clk_factors_config *config;
-	void (*get_factors) (u32 *rate, u32 parent, u8 *n, u8 *k, u8 *m, u8 *p);
-	spinlock_t *lock;
-};
-
 #define to_clk_factors(_hw) container_of(_hw, struct clk_factors, hw)
 
 #define SETMASK(len, pos)		(((-1U) >> (31-len))  << (pos))
@@ -120,61 +112,8 @@ static int clk_factors_set_rate(struct clk_hw *hw, unsigned long rate,
 	return 0;
 }
 
-static const struct clk_ops clk_factors_ops = {
+const struct clk_ops clk_factors_ops = {
 	.recalc_rate = clk_factors_recalc_rate,
 	.round_rate = clk_factors_round_rate,
 	.set_rate = clk_factors_set_rate,
 };
-
-/**
- * clk_register_factors - register a factors clock with
- * the clock framework
- * @dev: device registering this clock
- * @name: name of this clock
- * @parent_name: name of clock's parent
- * @flags: framework-specific flags
- * @reg: register address to adjust factors
- * @config: shift and width of factors n, k, m and p
- * @get_factors: function to calculate the factors for a given frequency
- * @lock: shared register lock for this clock
- */
-struct clk *clk_register_factors(struct device *dev, const char *name,
-				 const char *parent_name,
-				 unsigned long flags, void __iomem *reg,
-				 struct clk_factors_config *config,
-				 void (*get_factors)(u32 *rate, u32 parent,
-						     u8 *n, u8 *k, u8 *m, u8 *p),
-				 spinlock_t *lock)
-{
-	struct clk_factors *factors;
-	struct clk *clk;
-	struct clk_init_data init;
-
-	/* allocate the factors */
-	factors = kzalloc(sizeof(struct clk_factors), GFP_KERNEL);
-	if (!factors) {
-		pr_err("%s: could not allocate factors clk\n", __func__);
-		return ERR_PTR(-ENOMEM);
-	}
-
-	init.name = name;
-	init.ops = &clk_factors_ops;
-	init.flags = flags;
-	init.parent_names = (parent_name ? &parent_name : NULL);
-	init.num_parents = (parent_name ? 1 : 0);
-
-	/* struct clk_factors assignments */
-	factors->reg = reg;
-	factors->config = config;
-	factors->lock = lock;
-	factors->hw.init = &init;
-	factors->get_factors = get_factors;
-
-	/* register the clock */
-	clk = clk_register(dev, &factors->hw);
-
-	if (IS_ERR(clk))
-		kfree(factors);
-
-	return clk;
-}
diff --git a/drivers/clk/sunxi/clk-factors.h b/drivers/clk/sunxi/clk-factors.h
index f49851c..02e1a43 100644
--- a/drivers/clk/sunxi/clk-factors.h
+++ b/drivers/clk/sunxi/clk-factors.h
@@ -17,11 +17,13 @@ struct clk_factors_config {
 	u8 pwidth;
 };
 
-struct clk *clk_register_factors(struct device *dev, const char *name,
-				 const char *parent_name,
-				 unsigned long flags, void __iomem *reg,
-				 struct clk_factors_config *config,
-				 void (*get_factors) (u32 *rate, u32 parent_rate,
-						      u8 *n, u8 *k, u8 *m, u8 *p),
-				 spinlock_t *lock);
+struct clk_factors {
+	struct clk_hw hw;
+	void __iomem *reg;
+	struct clk_factors_config *config;
+	void (*get_factors) (u32 *rate, u32 parent, u8 *n, u8 *k, u8 *m, u8 *p);
+	spinlock_t *lock;
+};
+
+extern const struct clk_ops clk_factors_ops;
 #endif
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 323366b..f258a20 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -173,7 +173,11 @@ static void sunxi_get_apb1_factors(u32 *freq, u32 parent_rate,
  * sunxi_factors_clk_setup() - Setup function for factor clocks
  */
 
+#define SUNXI_FACTORS_MUX_MASK 0x3
+
 struct factors_data {
+	int enable;
+	int mux;
 	struct clk_factors_config *table;
 	void (*getter) (u32 *rate, u32 parent_rate, u8 *n, u8 *k, u8 *m, u8 *p);
 };
@@ -210,16 +214,70 @@ static void __init sunxi_factors_clk_setup(struct device_node *node,
 					   struct factors_data *data)
 {
 	struct clk *clk;
+	struct clk_factors *factors;
+	struct clk_gate *gate = NULL;
+	struct clk_mux *mux = NULL;
+	struct clk_hw *gate_hw = NULL;
+	struct clk_hw *mux_hw = NULL;
 	const char *clk_name = node->name;
-	const char *parent;
+	const char *parents[5];
 	void *reg;
+	int i = 0;
 
 	reg = of_iomap(node, 0);
 
-	parent = of_clk_get_parent_name(node, 0);
+	/* if we have a mux, we will have >1 parents */
+	while (i < 5 && (parents[i] = of_clk_get_parent_name(node, i)) != NULL)
+		i++;
+
+	factors = kzalloc(sizeof(struct clk_factors), GFP_KERNEL);
+	if (!factors)
+		return;
 
-	clk = clk_register_factors(NULL, clk_name, parent, 0, reg,
-				   data->table, data->getter, &clk_lock);
+	/* Add a gate if this factor clock can be gated */
+	if (data->enable) {
+		gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
+		if (!gate) {
+			kfree(factors);
+			return;
+		}
+
+		/* set up gate properties */
+		gate->reg = reg;
+		gate->bit_idx = data->enable;
+		gate->lock = &clk_lock;
+		gate_hw = &gate->hw;
+	}
+
+	/* Add a mux if this factor clock can be muxed */
+	if (data->mux) {
+		mux = kzalloc(sizeof(struct clk_mux), GFP_KERNEL);
+		if (!mux) {
+			kfree(factors);
+			kfree(gate);
+			return;
+		}
+
+		/* set up gate properties */
+		mux->reg = reg;
+		mux->shift = data->mux;
+		mux->mask = SUNXI_FACTORS_MUX_MASK;
+		mux->lock = &clk_lock;
+		mux_hw = &mux->hw;
+	}
+
+	/* set up factors properties */
+	factors->reg = reg;
+	factors->config = data->table;
+	factors->get_factors = data->getter;
+	factors->lock = &clk_lock;
+
+	clk = clk_register_composite(NULL, clk_name,
+			parents, i,
+			mux_hw, &clk_mux_ops,
+			&factors->hw, &clk_factors_ops,
+			gate_hw, &clk_gate_ops,
+			i ? 0 : CLK_IS_ROOT);
 
 	if (clk) {
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
-- 
1.8.3.3



From emilio at elopez.com.ar  Mon Jul 22 21:01:08 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Mon, 22 Jul 2013 22:01:08 -0300
Subject: [PATCH RFC 4/8] ARM: sunxi: add PLL4 support
In-Reply-To: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
References: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1374541272-32173-5-git-send-email-emilio@elopez.com.ar>

This commit adds the PLL4 definition to the sun4i and sun5i device
trees. PLL4 is compatible with PLL1.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 arch/arm/boot/dts/sun4i-a10.dtsi  | 7 +++++++
 arch/arm/boot/dts/sun5i-a10s.dtsi | 7 +++++++
 arch/arm/boot/dts/sun5i-a13.dtsi  | 7 +++++++
 3 files changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index b2bd6e1..6d569fd 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -66,6 +66,13 @@
 			clocks = <&osc24M>;
 		};
 
+		pll4: pll4 at 01c20018 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-pll1-clk";
+			reg = <0x01c20018 0x4>;
+			clocks = <&osc24M>;
+		};
+
 		/* dummy is 200M */
 		cpu: cpu at 01c20054 {
 			#clock-cells = <0>;
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 2307ce8..9c1a2b9 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -63,6 +63,13 @@
 			clocks = <&osc24M>;
 		};
 
+		pll4: pll4 at 01c20018 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-pll1-clk";
+			reg = <0x01c20018 0x4>;
+			clocks = <&osc24M>;
+		};
+
 		/* dummy is 200M */
 		cpu: cpu at 01c20054 {
 			#clock-cells = <0>;
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 7363211..67889cf 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -67,6 +67,13 @@
 			clocks = <&osc24M>;
 		};
 
+		pll4: pll4 at 01c20018 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-pll1-clk";
+			reg = <0x01c20018 0x4>;
+			clocks = <&osc24M>;
+		};
+
 		/* dummy is 200M */
 		cpu: cpu at 01c20054 {
 			#clock-cells = <0>;
-- 
1.8.3.3



From emilio at elopez.com.ar  Mon Jul 22 21:01:09 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Mon, 22 Jul 2013 22:01:09 -0300
Subject: [PATCH RFC 5/8] clk: sunxi: add PLL5 and PLL6 support
In-Reply-To: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
References: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1374541272-32173-6-git-send-email-emilio@elopez.com.ar>

This commit implements PLL5 and PLL6 support on the sunxi clock driver.
These PLLs use a similar factor clock, but differ on their outputs.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 Documentation/devicetree/bindings/clock/sunxi.txt |   2 +
 drivers/clk/sunxi/clk-sunxi.c                     | 159 +++++++++++++++++++++-
 2 files changed, 159 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 9a28022..6634eac 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -8,6 +8,8 @@ Required properties:
 - compatible : shall be one of the following:
 	"allwinner,sun4i-osc-clk" - for a gatable oscillator
 	"allwinner,sun4i-pll1-clk" - for the main PLL clock as well as PLL4
+	"allwinner,sun4i-pll5-clk" - for the PLL5 clock
+	"allwinner,sun4i-pll6-clk" - for the PLL6 clock
 	"allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
 	"allwinner,sun4i-axi-clk" - for the AXI clock
 	"allwinner,sun4i-axi-gates-clk" - for the AXI gates
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 4dccdb9..743c2c2 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -127,6 +127,38 @@ static void sunxi_get_pll1_factors(u32 *freq, u32 parent_rate,
 
 
 /**
+ * sunxi_get_pll5_factors() - calculates n, k factors for PLL5
+ * PLL5 rate is calculated as follows
+ * rate = parent_rate * n * (k + 1)
+ * parent_rate is always 24Mhz
+ */
+
+static void sunxi_get_pll5_factors(u32 *freq, u32 parent_rate,
+				   u8 *n, u8 *k, u8 *m, u8 *p)
+{
+	u8 div;
+
+	/* Normalize value to a 24M multiple */
+	div = *freq / 24000000;
+	*freq = 24000000 * div;
+
+	/* we were called to round the frequency, we can now return */
+	if (n == NULL)
+		return;
+
+	if (*freq < 480000000)
+		*k = 0;
+	else if (*freq < 960000000)
+		*k = 1;
+	else
+		*k = 3;
+
+	*n = DIV_ROUND_UP(*freq, ((*k+1) * 24000000));
+}
+
+
+
+/**
  * sunxi_get_apb1_factors() - calculates m, p factors for APB1
  * APB1 rate is calculated as follows
  * rate = (parent_rate >> p) / (m + 1);
@@ -193,6 +225,13 @@ static struct clk_factors_config pll1_config = {
 	.pwidth = 2,
 };
 
+static struct clk_factors_config pll5_config = {
+	.nshift = 8,
+	.nwidth = 5,
+	.kshift = 4,
+	.kwidth = 2,
+};
+
 static struct clk_factors_config apb1_config = {
 	.mshift = 0,
 	.mwidth = 5,
@@ -206,6 +245,12 @@ static const __initconst struct factors_data pll1_data = {
 	.getter = sunxi_get_pll1_factors,
 };
 
+static const __initconst struct factors_data pll5_data = {
+	.enable = 31,
+	.table = &pll5_config,
+	.getter = sunxi_get_pll5_factors,
+};
+
 static const __initconst struct factors_data apb1_data = {
 	.table = &apb1_config,
 	.getter = sunxi_get_apb1_factors,
@@ -223,6 +268,7 @@ static void __init sunxi_factors_clk_setup(struct device_node *node,
 	const char *clk_name = node->name;
 	const char *parents[5];
 	void *reg;
+	unsigned long flags;
 	int i = 0;
 
 	reg = of_iomap(node, 0);
@@ -273,12 +319,14 @@ static void __init sunxi_factors_clk_setup(struct device_node *node,
 	factors->get_factors = data->getter;
 	factors->lock = &clk_lock;
 
+	/* We should not disable pll5, it powers the RAM */
+	flags = !strcmp("pll5", clk_name) ? CLK_IGNORE_UNUSED : 0;
+
 	clk = clk_register_composite(NULL, clk_name,
 			parents, i,
 			mux_hw, &clk_mux_ops,
 			&factors->hw, &clk_factors_ops,
-			gate_hw, &clk_gate_ops,
-			i ? 0 : CLK_IS_ROOT);
+			gate_hw, &clk_gate_ops, flags);
 
 	if (clk) {
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
@@ -469,6 +517,103 @@ static void __init sunxi_gates_clk_setup(struct device_node *node,
 	of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
 }
 
+
+
+/**
+ * sunxi_divs_clk_setup() - Setup function for leaf divisors on clocks
+ */
+
+#define SUNXI_DIVS_MAX_QTY	2
+
+struct divs_data {
+	const struct factors_data *factors; /* data for the factor clock */
+	struct {
+		u8 fixed; /* is it a fixed divisor? if not... */
+		struct clk_div_table *table; /* is it a table based divisor? */
+		u8 shift; /* otherwise it's a normal divisor with this shift */
+		u8 pow;   /* is it power-of-two based? */
+	} div[SUNXI_DIVS_MAX_QTY];
+};
+
+static struct clk_div_table pll6_sata_table[] = {
+	{ .val = 0, .div = 6, },
+	{ .val = 1, .div = 12, },
+	{ .val = 2, .div = 18, },
+	{ .val = 3, .div = 24, },
+	{ } /* sentinel */
+};
+
+static const __initconst struct divs_data pll5_divs_data = {
+	.factors = &pll5_data,
+	.div = {
+		{ .shift = 0, .pow = 0, }, /* M, DDR */
+		{ .shift = 16, .pow = 1, }, /* P, other */
+	}
+};
+
+static const __initconst struct divs_data pll6_divs_data = {
+	.factors = &pll5_data,
+	.div = {
+		{ .shift = 0, .table = pll6_sata_table }, /* M, SATA */
+		{ .fixed = 2 }, /* P, other */
+	}
+};
+
+static void __init sunxi_divs_clk_setup(struct device_node *node,
+					struct divs_data *data)
+{
+	struct clk_onecell_data *clk_data;
+	const char *parent  = node->name;
+	const char *clk_name;
+	struct clk **clks;
+	void *reg;
+	int i = 0;
+	int flags;
+
+	/* Set up factor clock that we will be dividing */
+	sunxi_factors_clk_setup(node, (struct factors_data *)data->factors);
+
+	reg = of_iomap(node, 0);
+
+	clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
+	if (!clk_data)
+		return;
+	clks = kzalloc(SUNXI_DIVS_MAX_QTY * sizeof(struct clk *), GFP_KERNEL);
+	if (!clk_data->clks) {
+		kfree(clk_data);
+		return;
+	}
+	clk_data->clks = clks;
+
+	for (i = 0; i < SUNXI_DIVS_MAX_QTY; i++) {
+		if (of_property_read_string_index(node, "clock-output-names",
+						  i, &clk_name) != 0)
+			break;
+
+		if (data->div[i].fixed) {
+			clks[i] = clk_register_fixed_factor(NULL, clk_name,
+							    parent, 0, 1,
+							    data->div[i].fixed);
+		} else {
+			flags = data->div[i].pow ? CLK_DIVIDER_POWER_OF_TWO : 0;
+			clks[i] = clk_register_divider_table(NULL, clk_name,
+							     parent, 0, reg,
+							     data->div[i].shift,
+							     SUNXI_DIVISOR_WIDTH,
+							     flags,
+							     data->div[i].table,
+							     &clk_lock);
+		}
+
+		WARN_ON(IS_ERR(clk_data->clks[i]));
+	}
+
+	/* Adjust to the real max */
+	clk_data->clk_num = i;
+
+	of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+}
+
 /* Matches for of_clk_init */
 CLK_OF_DECLARE(sunxi_osc, "allwinner,sun4i-osc-clk", sunxi_osc_clk_setup);
 
@@ -487,6 +632,13 @@ static const __initconst struct of_device_id clk_div_match[] = {
 	{}
 };
 
+/* Matches for divided outputs */
+static const __initconst struct of_device_id clk_divs_match[] = {
+	{.compatible = "allwinner,sun4i-pll5-clk", .data = &pll5_divs_data,},
+	{.compatible = "allwinner,sun4i-pll6-clk", .data = &pll6_divs_data,},
+	{}
+};
+
 /* Matches for mux clocks */
 static const __initconst struct of_device_id clk_mux_match[] = {
 	{.compatible = "allwinner,sun4i-cpu-clk", .data = &cpu_mux_data,},
@@ -532,6 +684,9 @@ void __init sunxi_init_clocks(void)
 	/* Register divider clocks */
 	of_sunxi_table_clock_setup(clk_div_match, sunxi_divider_clk_setup);
 
+	/* Register divided output clocks */
+	of_sunxi_table_clock_setup(clk_divs_match, sunxi_divs_clk_setup);
+
 	/* Register mux clocks */
 	of_sunxi_table_clock_setup(clk_mux_match, sunxi_mux_clk_setup);
 
-- 
1.8.3.3



From emilio at elopez.com.ar  Mon Jul 22 21:01:10 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Mon, 22 Jul 2013 22:01:10 -0300
Subject: [PATCH RFC 6/8] ARM: sunxi: add PLL5 and PLL6 support
In-Reply-To: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
References: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1374541272-32173-7-git-send-email-emilio@elopez.com.ar>

This commit adds PLL5 and PLL6 nodes to the sun4i and sun5i device trees.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 arch/arm/boot/dts/sun4i-a10.dtsi  | 19 +++++++++++++++++--
 arch/arm/boot/dts/sun5i-a10s.dtsi | 19 +++++++++++++++++--
 arch/arm/boot/dts/sun5i-a13.dtsi  | 19 +++++++++++++++++--
 3 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 6d569fd..620290b 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -73,6 +73,22 @@
 			clocks = <&osc24M>;
 		};
 
+		pll5: pll5 at 01c20020 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun4i-pll5-clk";
+			reg = <0x01c20020 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll5_ddr", "pll5_other";
+		};
+
+		pll6: pll6 at 01c20028 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun4i-pll6-clk";
+			reg = <0x01c20028 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll6_sata", "pll6_other";
+		};
+
 		/* dummy is 200M */
 		cpu: cpu at 01c20054 {
 			#clock-cells = <0>;
@@ -138,12 +154,11 @@
 				"apb0_ir1", "apb0_keypad";
 		};
 
-		/* dummy is pll62 */
 		apb1_mux: apb1_mux at 01c20058 {
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-apb1-mux-clk";
 			reg = <0x01c20058 0x4>;
-			clocks = <&osc24M>, <&dummy>, <&osc32k>;
+			clocks = <&osc24M>, <&pll6 1>, <&osc32k>;
 		};
 
 		apb1: apb1 at 01c20058 {
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 9c1a2b9..4d47abc 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -70,6 +70,22 @@
 			clocks = <&osc24M>;
 		};
 
+		pll5: pll5 at 01c20020 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun4i-pll5-clk";
+			reg = <0x01c20020 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll5_ddr", "pll5_other";
+		};
+
+		pll6: pll6 at 01c20028 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun4i-pll6-clk";
+			reg = <0x01c20028 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll6_sata", "pll6_other";
+		};
+
 		/* dummy is 200M */
 		cpu: cpu at 01c20054 {
 			#clock-cells = <0>;
@@ -135,12 +151,11 @@
 				"apb0_ir1", "apb0_keypad";
 		};
 
-		/* dummy is pll62 */
 		apb1_mux: apb1_mux at 01c20058 {
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-apb1-mux-clk";
 			reg = <0x01c20058 0x4>;
-			clocks = <&osc24M>, <&dummy>, <&osc32k>;
+			clocks = <&osc24M>, <&pll6 1>, <&osc32k>;
 		};
 
 		apb1: apb1 at 01c20058 {
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 67889cf..e652b5f 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -74,6 +74,22 @@
 			clocks = <&osc24M>;
 		};
 
+		pll5: pll5 at 01c20020 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun4i-pll5-clk";
+			reg = <0x01c20020 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll5_ddr", "pll5_other";
+		};
+
+		pll6: pll6 at 01c20028 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun4i-pll6-clk";
+			reg = <0x01c20028 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll6_sata", "pll6_other";
+		};
+
 		/* dummy is 200M */
 		cpu: cpu at 01c20054 {
 			#clock-cells = <0>;
@@ -132,12 +148,11 @@
 			clock-output-names = "apb0_codec", "apb0_pio", "apb0_ir";
 		};
 
-		/* dummy is pll6 */
 		apb1_mux: apb1_mux at 01c20058 {
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-apb1-mux-clk";
 			reg = <0x01c20058 0x4>;
-			clocks = <&osc24M>, <&dummy>, <&osc32k>;
+			clocks = <&osc24M>, <&pll6 1>, <&osc32k>;
 		};
 
 		apb1: apb1 at 01c20058 {
-- 
1.8.3.3



From emilio at elopez.com.ar  Mon Jul 22 21:01:12 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Mon, 22 Jul 2013 22:01:12 -0300
Subject: [PATCH RFC 8/8] ARM: sun4i: mod0 clocks
In-Reply-To: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
References: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1374541272-32173-9-git-send-email-emilio@elopez.com.ar>

This commit adds all the mod0 clocks present on sun4i to its device tree

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 arch/arm/boot/dts/sun4i-a10.dtsi | 105 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 105 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 620290b..90493e3 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -180,6 +180,111 @@
 				"apb1_uart4", "apb1_uart5", "apb1_uart6",
 				"apb1_uart7";
 		};
+
+		nand: nand at 01c20080 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c20080 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
+
+		ms: ms at 01c20084 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c20084 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
+
+		mmc0: mmc0 at 01c20088 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c20088 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
+
+		mmc1: mmc1 at 01c2008c {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c2008c 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
+
+		mmc2: mmc2 at 01c20090 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c20090 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
+
+		mmc3: mmc3 at 01c20094 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c20094 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
+
+		ts: ts at 01c20098 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c20098 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
+
+		ss: ss at 01c2009c {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c2009c 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
+
+		spi0: spi0 at 01c200a0 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c200a0 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
+
+		spi1: spi0 at 01c200a4 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c200a4 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
+
+		spi2: spi0 at 01c200a8 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c200a8 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
+
+		pata: pata at 01c200ac {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c200ac 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
+
+		ir0: ir0 at 01c200b0 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c200b0 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
+
+		ir1: ir1 at 01c200b4 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c200b4 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
+
+		spi3: spi3 at 01c200d4 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-mod0-clk";
+			reg = <0x01c200d4 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+		};
 	};
 
 	soc at 01c20000 {
-- 
1.8.3.3



From emilio at elopez.com.ar  Mon Jul 22 21:01:11 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Mon, 22 Jul 2013 22:01:11 -0300
Subject: [PATCH RFC 7/8] clk: sunxi: mod0 support
In-Reply-To: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
References: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1374541272-32173-8-git-send-email-emilio@elopez.com.ar>

This commit implements support for the "module 0" type of clocks, as
used by MMC, IR, NAND, SATA and other components.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
 drivers/clk/sunxi/clk-sunxi.c                     | 54 +++++++++++++++++++++++
 2 files changed, 55 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 6634eac..74c8f2e 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -23,6 +23,7 @@ Required properties:
 	"allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing
 	"allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10
 	"allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
+	"allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 743c2c2..28bf36f 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -202,6 +202,44 @@ static void sunxi_get_apb1_factors(u32 *freq, u32 parent_rate,
 
 
 /**
+ * sunxi_get_mod0_factors() - calculates m, n factors for MOD0-style clocks
+ * MMC rate is calculated as follows
+ * rate = (parent_rate >> p) / (m + 1);
+ */
+
+static void sunxi_get_mod0_factors(u32 *freq, u32 parent_rate,
+				   u8 *n, u8 *k, u8 *m, u8 *p)
+{
+	u8 div, calcm, calcp;
+
+	/* Normalize value to a division of the parent */
+	div = parent_rate / *freq;
+	*freq = parent_rate / div;
+
+	if (div < 16)
+		calcp = 0;
+	else if (div / 2 < 16)
+		calcp = 1;
+	else if (div / 4 < 16)
+		calcp = 2;
+	else
+		calcp = 3;
+
+	calcm = DIV_ROUND_UP(div, 1 << calcp);
+
+	*freq = (parent_rate >> calcp) / calcm;
+
+	/* we were called to round the frequency, we can now return */
+	if (n == NULL)
+		return;
+
+	*m = calcm - 1;
+	*p = calcp;
+}
+
+
+
+/**
  * sunxi_factors_clk_setup() - Setup function for factor clocks
  */
 
@@ -239,6 +277,14 @@ static struct clk_factors_config apb1_config = {
 	.pwidth = 2,
 };
 
+/* user manual says "n" but it's really "p" */
+static struct clk_factors_config mod0_config = {
+	.mshift = 0,
+	.mwidth = 4,
+	.pshift = 16,
+	.pwidth = 2,
+};
+
 static const __initconst struct factors_data pll1_data = {
 	.enable = 31,
 	.table = &pll1_config,
@@ -256,6 +302,13 @@ static const __initconst struct factors_data apb1_data = {
 	.getter = sunxi_get_apb1_factors,
 };
 
+static const __initconst struct factors_data mod0_data = {
+	.enable = 31,
+	.mux = 24,
+	.table = &mod0_config,
+	.getter = sunxi_get_mod0_factors,
+};
+
 static void __init sunxi_factors_clk_setup(struct device_node *node,
 					   struct factors_data *data)
 {
@@ -621,6 +674,7 @@ CLK_OF_DECLARE(sunxi_osc, "allwinner,sun4i-osc-clk", sunxi_osc_clk_setup);
 static const __initconst struct of_device_id clk_factors_match[] = {
 	{.compatible = "allwinner,sun4i-pll1-clk", .data = &pll1_data,},
 	{.compatible = "allwinner,sun4i-apb1-clk", .data = &apb1_data,},
+	{.compatible = "allwinner,sun4i-mod0-clk", .data = &mod0_data,},
 	{}
 };
 
-- 
1.8.3.3



From horms at verge.net.au  Mon Jul 22 21:11:47 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Jul 2013 10:11:47 +0900
Subject: [PATCH v2 2/2] ARM: shmobile: BOCK-W: enable DMA for SDHI0
In-Reply-To: <201307230223.24954.sergei.shtylyov@cogentembedded.com>
References: <201307230218.01495.sergei.shtylyov@cogentembedded.com>
 <201307230223.24954.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130723011147.GA17885@verge.net.au>

On Tue, Jul 23, 2013 at 02:23:24AM +0400, Sergei Shtylyov wrote:
> From: Max Filippov <max.filippov at cogentembedded.com>
> 
> Pass HPB-DMA slave IDs in the SDHI0 platform data to enable DMA in the SDHI
> driver.
> 
> Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
> [Sergei: removed #include <mach/dma.h>]
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

I don't see HPBDMA_SLAVE_SDHI0_TX in v3.11-rc2.
Please repost this patch when it is available in
a branch I can used as a base.

> 
> ---
> Changes in version 2:
> - removed #include <mach/dma.h>;
> - refreshed the patch.
> 
>  arch/arm/mach-shmobile/board-bockw.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> Index: renesas/arch/arm/mach-shmobile/board-bockw.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
> +++ renesas/arch/arm/mach-shmobile/board-bockw.c
> @@ -81,6 +81,8 @@ static struct rcar_phy_platform_data usb
>  
>  /* SDHI */
>  static struct sh_mobile_sdhi_info sdhi0_info = {
> +	.dma_slave_tx	= HPBDMA_SLAVE_SDHI0_TX,
> +	.dma_slave_rx	= HPBDMA_SLAVE_SDHI0_RX,
>  	.tmio_caps	= MMC_CAP_SD_HIGHSPEED,
>  	.tmio_ocr_mask	= MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
>  	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT,
> 


From emilio at elopez.com.ar  Mon Jul 22 21:19:01 2013
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Mon, 22 Jul 2013 22:19:01 -0300
Subject: [PATCH] ARM: sunxi: make the leds' names conform to the current
 naming convention
Message-ID: <1374542341-3429-1-git-send-email-emilio@elopez.com.ar>

Quoting from Documentation/leds/leds-class.txt:

    LED Device Naming
    =================

    Is currently of the form:

    "devicename:colour:function"

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
---
 arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
index 757c4cd..4580b62 100644
--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
+++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
@@ -76,12 +76,12 @@
 		pinctrl-0 = <&led_pins_cubieboard>;
 
 		blue {
-			label = "cubieboard::blue";
+			label = "cubieboard:blue:usr";
 			gpios = <&pio 7 21 0>; /* LED1 */
 		};
 
 		green {
-			label = "cubieboard::green";
+			label = "cubieboard:green:usr";
 			gpios = <&pio 7 20 0>; /* LED2 */
 			linux,default-trigger = "heartbeat";
 		};
-- 
1.8.3.3



From horms at verge.net.au  Mon Jul 22 21:24:33 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Jul 2013 10:24:33 +0900
Subject: [PATCH v2 03/04] ARM: shmobile: Add EMEV2 and KZM9D to
 ARCH_SHMOBILE_MULTI
In-Reply-To: <20130717203118.27542.37940.sendpatchset@w520>
References: <20130717203049.27542.78385.sendpatchset@w520>
 <20130717203118.27542.37940.sendpatchset@w520>
Message-ID: <20130723012432.GA16481@verge.net.au>

On Thu, Jul 18, 2013 at 05:31:18AM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Enable build of EMEV2 and KZM9D DT Reference in
> case of ARCH_MULTIPLATFORM and ARCH_SHMOBILE_MULTI.
> 
> IS_ENABLED() is leaves the clock-emev2.c file out
> in case of COMMON_CLK=y.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  Changes since V1:
>  - use IS_ENABLED() instead of weak symbol, thanks Arnd!
> 
>  arch/arm/boot/dts/Makefile                     |    1 +
>  arch/arm/mach-shmobile/Kconfig                 |   15 +++++++++++++++
>  arch/arm/mach-shmobile/board-kzm9d-reference.c |    3 ++-
>  arch/arm/mach-shmobile/setup-emev2.c           |    3 ++-
>  4 files changed, 20 insertions(+), 2 deletions(-)

Thanks, I have queued this up for v3.12 in a new multiarch branch
of the renesas tree.



From horms at verge.net.au  Mon Jul 22 21:24:42 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Jul 2013 10:24:42 +0900
Subject: [PATCH v2 01/04] ARM: shmobile: Only build clocks when
 COMMON_CLK=n
In-Reply-To: <20130717203059.27542.57468.sendpatchset@w520>
References: <20130717203049.27542.78385.sendpatchset@w520>
 <20130717203059.27542.57468.sendpatchset@w520>
Message-ID: <20130723012441.GC16481@verge.net.au>

On Thu, Jul 18, 2013 at 05:30:59AM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Move shared clock.c file and per-SoC clock-xxx.c files
> to only build when CONFIG_COMMON_CLK != y.
> 
> The regular ARCH_SHMOBILE case with legacy SH clock framework
> will build just as before with this patch applied, however
> the case when COMMON_CLK=y will exclude all the clock files.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

Thanks, I have queued this up for v3.12 in a new multiarch branch
of the renesas tree.

> ---
> 
>  Changes since V1:
>  - wrap clock objects in ifndef, thanks Arnd and Laurent!
> 
>  arch/arm/mach-shmobile/Makefile |   31 ++++++++++++++++++++++---------
>  1 file changed, 22 insertions(+), 9 deletions(-)
> 
> --- 0001/arch/arm/mach-shmobile/Makefile
> +++ work/arch/arm/mach-shmobile/Makefile	2013-07-18 05:05:41.000000000 +0900
> @@ -3,17 +3,30 @@
>  #
>  
>  # Common objects
> -obj-y				:= timer.o console.o clock.o
> +obj-y				:= timer.o console.o
>  
>  # CPU objects
> -obj-$(CONFIG_ARCH_SH7372)	+= setup-sh7372.o clock-sh7372.o intc-sh7372.o
> -obj-$(CONFIG_ARCH_SH73A0)	+= setup-sh73a0.o clock-sh73a0.o intc-sh73a0.o
> -obj-$(CONFIG_ARCH_R8A73A4)	+= setup-r8a73a4.o clock-r8a73a4.o
> -obj-$(CONFIG_ARCH_R8A7740)	+= setup-r8a7740.o clock-r8a7740.o intc-r8a7740.o
> -obj-$(CONFIG_ARCH_R8A7778)	+= setup-r8a7778.o clock-r8a7778.o
> -obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o clock-r8a7779.o intc-r8a7779.o
> -obj-$(CONFIG_ARCH_R8A7790)	+= setup-r8a7790.o clock-r8a7790.o
> -obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o clock-emev2.o
> +obj-$(CONFIG_ARCH_SH7372)	+= setup-sh7372.o intc-sh7372.o
> +obj-$(CONFIG_ARCH_SH73A0)	+= setup-sh73a0.o intc-sh73a0.o
> +obj-$(CONFIG_ARCH_R8A73A4)	+= setup-r8a73a4.o
> +obj-$(CONFIG_ARCH_R8A7740)	+= setup-r8a7740.o intc-r8a7740.o
> +obj-$(CONFIG_ARCH_R8A7778)	+= setup-r8a7778.o
> +obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o intc-r8a7779.o
> +obj-$(CONFIG_ARCH_R8A7790)	+= setup-r8a7790.o
> +obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o
> +
> +# Clock objects
> +ifndef CONFIG_COMMON_CLK
> +obj-y				+= clock.o
> +obj-$(CONFIG_ARCH_SH7372)	+= clock-sh7372.o
> +obj-$(CONFIG_ARCH_SH73A0)	+= clock-sh73a0.o
> +obj-$(CONFIG_ARCH_R8A73A4)	+= clock-r8a73a4.o
> +obj-$(CONFIG_ARCH_R8A7740)	+= clock-r8a7740.o
> +obj-$(CONFIG_ARCH_R8A7778)	+= clock-r8a7778.o
> +obj-$(CONFIG_ARCH_R8A7779)	+= clock-r8a7779.o
> +obj-$(CONFIG_ARCH_R8A7790)	+= clock-r8a7790.o
> +obj-$(CONFIG_ARCH_EMEV2)	+= clock-emev2.o
> +endif
>  
>  # SMP objects
>  smp-y				:= platsmp.o headsmp.o
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From horms at verge.net.au  Mon Jul 22 21:24:45 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Jul 2013 10:24:45 +0900
Subject: [PATCH 02/04] ARM: shmobile: Introduce ARCH_SHMOBILE_MULTI
In-Reply-To: <20130717203109.27542.77708.sendpatchset@w520>
References: <20130717203049.27542.78385.sendpatchset@w520>
 <20130717203109.27542.77708.sendpatchset@w520>
Message-ID: <20130723012444.GD16481@verge.net.au>

On Thu, Jul 18, 2013 at 05:31:09AM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Add ARCH_SHMOBILE_MULTI to mach-shmobile that can be used
> to enable ARCH_MULTIPLATFORM on selected SoCs and boards.
> 
> The headers stay under arch/arm/mach-shmobile/include/mach/
> for now, they can and will be migrated independently over time.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  arch/arm/Makefile               |    1 +
>  arch/arm/mach-shmobile/Kconfig  |   21 +++++++++++++++++++++
>  arch/arm/mach-shmobile/Makefile |    2 ++
>  3 files changed, 24 insertions(+)

Thanks, I have queued this up for v3.12 in a new multiarch branch
of the renesas tree.



From horms at verge.net.au  Mon Jul 22 21:24:55 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Jul 2013 10:24:55 +0900
Subject: [PATCH 04/04] ARM: shmobile: Allow ARCH_SHMOBILE_MULTI timer
 configuration
In-Reply-To: <20130717203127.27542.41663.sendpatchset@w520>
References: <20130717203049.27542.78385.sendpatchset@w520>
 <20130717203127.27542.41663.sendpatchset@w520>
Message-ID: <20130723012454.GE16481@verge.net.au>

On Thu, Jul 18, 2013 at 05:31:27AM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Move the timer configuration bits to allow use in
> case of ARCH_SHMOBILE or ARCH_SHMOBILE_MULTI.
> 
> The timers all make use of the regular driver model
> so they are safe to enable for ARCH_MULTIPLATFORM.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  arch/arm/mach-shmobile/Kconfig |   16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)

Thanks, I have queued this up for v3.12 in a new multiarch branch
of the renesas tree.


From mturquette at linaro.org  Mon Jul 22 21:26:21 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 22 Jul 2013 18:26:21 -0700
Subject: [PATCH v7 00/11] Add generic set_rate clk_ops for PLL35xx and
 PLL36xx for samsung SoCs
In-Reply-To: <CAGm_ybj31kv=iW2YKsHnBRJ741G2amSNAJf+Mx8Z-JMoVynZ8w@mail.gmail.com>
References: <1370943076-13461-1-git-send-email-yadi.brar@samsung.com>
 <CAKew6eUOy4=D08v_iq7CTRY5gvt37VAN7Z7WOr2Yt25znDJb2g@mail.gmail.com>
 <CAGm_ybiVZOPBJJ0bYX33wafn1So6aqSAnk7myXZ+Z+RfLBeBQw@mail.gmail.com>
 <1524664.UCV47tfIRU@flatron> <20130621163143.9136.28807@quantum>
 <51C85F8F.9050501@samsung.com> <20130624190227.20448.68120@quantum>
 <007001ce7149$1f683f40$5e38bdc0$%kim@samsung.com>
 <CAKew6eVW6dOzLRN2CG8jT3Oo1uzKrXqi1aRYkAHmUu61dBSDpA@mail.gmail.com>
 <CAGm_ybj31kv=iW2YKsHnBRJ741G2amSNAJf+Mx8Z-JMoVynZ8w@mail.gmail.com>
Message-ID: <20130723012621.7598.46496@quantum>

Quoting Vikas Sajjan (2013-07-21 23:15:27)
> Hi Kukjin / Mike,
> 
> Can you apply this series

Let me apply this to see if the dependencies are taken care of now. If
so I'll just take it through the clk tree.

Regards,
Mike

> 
> On Tue, Jul 16, 2013 at 7:10 PM, Yadwinder Singh Brar
> <yadi.brar01 at gmail.com> wrote:
> > Hi Kukjin / Mike,
> >
> > On Tue, Jun 25, 2013 at 7:40 AM, Kukjin Kim <kgene.kim at samsung.com> wrote:
> >> Mike Turquette wrote:
> >>>
> >>> Quoting Kukjin Kim (2013-06-24 08:02:39)
> >>> > On 06/22/13 01:31, Mike Turquette wrote:
> >>> > >
> >>> > > Acked-by: Mike Turquette<mturquette at linaro.org>
> >>> > >
> >>> > > Or I can take this through the clk tree. Either way is fine.
> >>> > >
> >>> > Mike, please go ahead taking this series into the clk tree for 3.11.
> >>>
> >>> Actually it might be better for you to take it. Patch #5 relies on
> >>> drivers/clk/samsung/clk-exynos5420.c which only exists in the samsung
> >>> tree.  It was introduced by commit 1609027f, "clk: exynos5420: register
> >>> clocks using common clock framework".
> >>>
> >> Yes, you're right. It depends on soc-exynos5420 stuff in samsung tree.
> >>
> >>> And these patches need to be applied with some fuzz to the clk tree due
> >>> to other changes which are not in my tree and only present in yours.
> >>>
> >>> The best two options are either for you to take this series or it can be
> >>> rebased on top of clk-next, after which I'll apply it.
> >>>
> >> Let me try to send this series via samsung tree for v3.11 but I'm not sure because it's a little bit late for arm-soc tree.
> >>
> >> Thanks for your ack, just note I will send to arm-soc tonight in my time.
> >>
> >
> > Can we get this series merge now in any of trees.
> > Please let me if its required to rebase it.
> >
> > Regards,
> > Yadwinder


From horms at verge.net.au  Mon Jul 22 21:33:43 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Jul 2013 10:33:43 +0900
Subject: [PATCH 19/22] ARM: shmobile: r8a7779: Remove '0x's from R8A7779
 DTS file
In-Reply-To: <1374490361-25769-19-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-19-git-send-email-lee.jones@linaro.org>
Message-ID: <20130723013343.GG16481@verge.net.au>

On Mon, Jul 22, 2013 at 11:52:38AM +0100, Lee Jones wrote:
> Cc: Simon Horman <horms+renesas at verge.net.au>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Acked-by: Simon Horman <horms+renesas at verge.net.au>

Let me know if you want me to take this through the renesas tree.

> ---
>  arch/arm/boot/dts/r8a7779.dtsi | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
> index 7f146c6..86bd487 100644
> --- a/arch/arm/boot/dts/r8a7779.dtsi
> +++ b/arch/arm/boot/dts/r8a7779.dtsi
> @@ -65,7 +65,7 @@
>  		sense-bitfield-width = <2>;
>  	};
>  
> -	i2c0: i2c at 0xffc70000 {
> +	i2c0: i2c at ffc70000 {
>  		#address-cells = <1>;
>  		#size-cells = <0>;
>  		compatible = "renesas,rmobile-iic";
> @@ -74,7 +74,7 @@
>  		interrupts = <0 79 0x4>;
>  	};
>  
> -	i2c1: i2c at 0xffc71000 {
> +	i2c1: i2c at ffc71000 {
>  		#address-cells = <1>;
>  		#size-cells = <0>;
>  		compatible = "renesas,rmobile-iic";
> @@ -83,7 +83,7 @@
>  		interrupts = <0 82 0x4>;
>  	};
>  
> -	i2c2: i2c at 0xffc72000 {
> +	i2c2: i2c at ffc72000 {
>  		#address-cells = <1>;
>  		#size-cells = <0>;
>  		compatible = "renesas,rmobile-iic";
> @@ -92,7 +92,7 @@
>  		interrupts = <0 80 0x4>;
>  	};
>  
> -	i2c3: i2c at 0xffc73000 {
> +	i2c3: i2c at ffc73000 {
>  		#address-cells = <1>;
>  		#size-cells = <0>;
>  		compatible = "renesas,rmobile-iic";
> -- 
> 1.8.1.2
> 


From inki.dae at samsung.com  Mon Jul 22 21:35:45 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Tue, 23 Jul 2013 10:35:45 +0900
Subject: [PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
In-Reply-To: <00f701ce8742$fa8c67e0$efa537a0$@samsusng.com>
References: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
 <1374475767-30085-3-git-send-email-chanho61.park@samsung.com>
 <20130722084817.GA18731@e106331-lin.cambridge.arm.com>
 <00f701ce8742$fa8c67e0$efa537a0$@samsusng.com>
Message-ID: <007f01ce8744$f3d1c560$db755020$%dae@samsung.com>



> -----Original Message-----
> From: Chanho Park [mailto:chanho61.park at samsusng.com]
> Sent: Tuesday, July 23, 2013 10:22 AM
> To: 'Mark Rutland'; 'Chanho Park'
> Cc: inki.dae at samsung.com; kgene.kim at samsung.com; linux-samsung-
> soc at vger.kernel.org; jy0922.shim at samsung.com; sw0312.kim at samsung.com; dri-
> devel at lists.freedesktop.org; kyungmin.park at samsung.com; linux-arm-
> kernel at lists.infradead.org
> Subject: RE: [PATCH 2/3] drm/exynos: add dt-binding documentation for
> rotator
> 
> Hi Mark,
> Thank you for your review.
> 
> > -----Original Message-----
> > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > Sent: Monday, July 22, 2013 5:48 PM
> > To: Chanho Park
> > Cc: inki.dae at samsung.com; kgene.kim at samsung.com; linux-samsung-
> > soc at vger.kernel.org; jy0922.shim at samsung.com; devicetree-
> > discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> > devel at lists.freedesktop.org; kyungmin.park at samsung.com; linux-arm-
> > kernel at lists.infradead.org
> > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
> > rotator
> >
> > On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> > > This patch adds a dt-binding document for exynos rotator. It describes
> > > which nodes should be defined to use the rotator.
> > >
> > > Signed-off-by: Chanho Park <chanho61.park at samsung.com>
> > > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> > > ---
> > >  .../bindings/drm/exynos/samsung-rotator.txt        |   35
> > ++++++++++++++++++++
> > >  1 file changed, 35 insertions(+)
> > >  create mode 100644
> > > Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> > > b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> > > new file mode 100644
> > > index 0000000..6b1d704
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> > > @@ -0,0 +1,35 @@
> > > +* Samsung Image Rotator
> > > +
> > > +Required properties:
> > > +  - compatible : value should be the "samsung,exynos4210".
> > > +  - reg : Physical base address of the IP registers and length of
> > memory
> > > +	  mapped region.
> > > +  - interrupts : interrupt number to the CPU.
> > > +  - clocks : clock number of exynos4 rotator clock.
> > > +  - clocks : clock name of rotator
> >
> > clock-names?
> 
> Yes. It seems to have ??a mistake during copy and paste.
> I'll modify it next patch.
> 
> >
> > > +  - status : "okay" or "disabled"
> > > +  - limit table for image formats : min_w/min_h/max_w/max_h for
> > > + min/max of image
> >
> > Limit table? This doesn't seem to be a well-defined binding, and it
> > seems like a relatively generic thing to describe.
> >
> > > +
> > > +Example:
> > > +	rotator: rotator at 12810000 {
> > > +		compatible = "samsung,exynos4210-rotator";
> > > +		reg = <0x12810000 0x1000>;
> > > +		interrupts = <0 83 0>;
> > > +		clocks = <&clock 278>;
> > > +		clock-names = "rotator";
> > > +		status = "disabled";
> > > +		ycbcr420_2p {
> >
> > Which names are allowed for these subnodes?
> >
> > > +			min_w = <32>;
> > > +			min_h = <32>;
> > > +			max_w = <32768>;
> > > +			max_h = <32768>;
> > > +			align = <3>;
> >
> > min-width, min-height, max-width, max-height? What units are they in?
> >
> > What does alignment specify exactly?
> >
> > Are these a configurable part of the rotator hardware, or are these
> > values always the same? If thery're always the same, there's no need to
> > describe in in the devicetree.
> 
> I've checked the rotator limitation for all of exynos4 chipsets and
> exynos5250.
> As a result, these have same value.

Not true. See the Exynos4210 user manual again. At least, the manual says maximum size is 64k x 64k in case of Y components.

> I think it seems to be better leave on static value.
> I'll prepare next patches including your suggestion.
> 

So, you should consider such a little bit difference.

> Thanks
> 
> Best Regards,
> Chanho Park
> 
> >
> > Thanks,
> > Mark.
> >
> > > +		};
> > > +		rgb888 {
> > > +			min_w = <8>;
> > > +			min_h = <8>;
> > > +			max_w = <8192>;
> > > +			max_h = <8192>;
> > > +			align = <2>;
> > > +		};
> > > +	};
> > > --
> > > 1.7.9.5
> > >
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > >



From horms at verge.net.au  Mon Jul 22 21:58:24 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Jul 2013 10:58:24 +0900
Subject: [PATCH v2 2/2] ARM: shmobile: BOCK-W: enable DMA for SDHI0
In-Reply-To: <20130723011147.GA17885@verge.net.au>
References: <201307230218.01495.sergei.shtylyov@cogentembedded.com>
 <201307230223.24954.sergei.shtylyov@cogentembedded.com>
 <20130723011147.GA17885@verge.net.au>
Message-ID: <20130723015824.GJ16481@verge.net.au>

On Tue, Jul 23, 2013 at 10:11:47AM +0900, Simon Horman wrote:
> On Tue, Jul 23, 2013 at 02:23:24AM +0400, Sergei Shtylyov wrote:
> > From: Max Filippov <max.filippov at cogentembedded.com>
> > 
> > Pass HPB-DMA slave IDs in the SDHI0 platform data to enable DMA in the SDHI
> > driver.
> > 
> > Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
> > [Sergei: removed #include <mach/dma.h>]
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> I don't see HPBDMA_SLAVE_SDHI0_TX in v3.11-rc2.
> Please repost this patch when it is available in
> a branch I can used as a base.

Sorry, I now see it in patch 1/2.
Somehow I missed that :(


From inki.dae at samsung.com  Mon Jul 22 22:00:32 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Tue, 23 Jul 2013 11:00:32 +0900
Subject: [PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
In-Reply-To: <1654536.B4gG8HrWlH@flatron>
References: <1374475767-30085-1-git-send-email-chanho61.park@samsung.com>
 <027201ce86df$cd883d90$6898b8b0$%dae@samsung.com>
 <51ED3AF6.3090004@samsung.com> <1654536.B4gG8HrWlH@flatron>
Message-ID: <008001ce8748$6a0a2d50$3e1e87f0$%dae@samsung.com>



> -----Original Message-----
> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
> owner at vger.kernel.org] On Behalf Of Tomasz Figa
> Sent: Tuesday, July 23, 2013 4:29 AM
> To: Sylwester Nawrocki
> Cc: Inki Dae; 'Chanho Park'; 'Lucas Stach'; 'Mark Rutland'; linux-samsung-
> soc at vger.kernel.org; devicetree-discuss at lists.ozlabs.org;
> sw0312.kim at samsung.com; dri-devel at lists.freedesktop.org;
> kyungmin.park at samsung.com; kgene.kim at samsung.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
> rotator
> 
> On Monday 22 of July 2013 16:00:22 Sylwester Nawrocki wrote:
> > On 07/22/2013 03:31 PM, Inki Dae wrote:
> > >> ---Original Message-----
> > >>
> > >> > From: linux-samsung-soc-owner at vger.kernel.org
> > >> > [mailto:linux-samsung-soc- owner at vger.kernel.org] On Behalf Of
> > >> > Lucas Stach
> > >> > Sent: Monday, July 22, 2013 9:47 PM
> > >> > To: Inki Dae
> > >> > Cc: 'Mark Rutland'; 'Chanho Park';
> > >> > linux-samsung-soc at vger.kernel.org;
> > >> > devicetree-discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> > >> > devel at lists.freedesktop.org; kyungmin.park at samsung.com;
> > >> > kgene.kim at samsung.com; linux-arm-kernel at lists.infradead.org
> > >> > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation
> > >> > for
> > >> > rotator
> > >> >
> > >> > Am Montag, den 22.07.2013, 21:37 +0900 schrieb Inki Dae:
> > >>>> > > > -----Original Message-----
> > >>>> > > > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > >>>> > > > Sent: Monday, July 22, 2013 5:48 PM
> > >>>> > > > To: Chanho Park
> > >>>> > > > Cc: inki.dae at samsung.com; kgene.kim at samsung.com;
> > >>>> > > > linux-samsung-
> > >>>> > > > soc at vger.kernel.org; jy0922.shim at samsung.com; devicetree-
> > >>>> > > > discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> > >>>> > > > devel at lists.freedesktop.org; kyungmin.park at samsung.com;
> > >>>> > > > linux-arm-
> > >>>> > > > kernel at lists.infradead.org
> > >>>> > > > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding
> > >>>> > > > documentation for
> > >>>> > > > rotator
> > >>>> > > >
> > >>>> > > > On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> > >>>>> > > > > This patch adds a dt-binding document for exynos rotator.
> > >>>>> > > > > It
> > >> >
> > >> > describes
> > >> >
> > >>>> > > > which
> > >>>> > > >
> > >>>>> > > > > nodes should be defined to use the rotator.
> > >>>>> > > > >
> > >>>>> > > > > Signed-off-by: Chanho Park <chanho61.park at samsung.com>
> > >>>>> > > > > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> > >>>>> > > > > ---
> > >>>>> > > > >
> > >>>>> > > > >  .../bindings/drm/exynos/samsung-rotator.txt        |   35
> > >>>> > > >
> > >>>> > > > ++++++++++++++++++++
> > >>>> > > >
> > >>>>> > > > >  1 file changed, 35 insertions(+)
> > >>>>> > > > >  create mode 100644
> > >>>> > > >
> > >>>> > > > Documentation/devicetree/bindings/drm/exynos/samsung-rotator.
> > >>>> > > > txt
> > >>>> > > >
> > >>>>> > > > > diff --git
> > >>>>> > > > > a/Documentation/devicetree/bindings/drm/exynos/samsung-
> > >>>> > > >
> > >>>> > > > rotator.txt
> > >>>> > > > b/Documentation/devicetree/bindings/drm/exynos/samsung-
> > >>>> > > > rotator.txt
> > >>>> > > >
> > >>>>> > > > > new file mode 100644
> > >>>>> > > > > index 0000000..6b1d704
> > >>>>> > > > > --- /dev/null
> > >>>>> > > > > +++
> > >>>>> > > > > b/Documentation/devicetree/bindings/drm/exynos/samsung-
> > >> >
> > >> > rotator.txt
> > >> >
> > >>>>> > > > > @@ -0,0 +1,35 @@
> > >>>>> > > > > +* Samsung Image Rotator
> > >>>>> > > > > +
> > >>>>> > > > > +Required properties:
> > >>>>> > > > > +  - compatible : value should be the
> > >>>>> > > > > "samsung,exynos4210".
> > >>> > >
> > >>> > > Please, add more compatible strings for other SoC.
> > >>> > >
> > >>>>> > > > > +  - reg : Physical base address of the IP registers and
> > >>>>> > > > > length of
> > >>>> > > >
> > >>>> > > > memory
> > >>>> > > >
> > >>>>> > > > > +	  mapped region.
> > >>>>> > > > > +  - interrupts : interrupt number to the CPU.
> > >>>>> > > > > +  - clocks : clock number of exynos4 rotator clock.
> > >>>>> > > > > +  - clocks : clock name of rotator
> > >>>> > > >
> > >>>> > > > clock-names?
> > >>>> > > >
> > >>>>> > > > > +  - status : "okay" or "disabled"
> > >>>>> > > > > +  - limit table for image formats :
> > >>>>> > > > > min_w/min_h/max_w/max_h for
> > >> >
> > >> > min/max
> > >> >
> > >>>> > > > of image
> > >>>> > > >
> > >>>> > > > Limit table? This doesn't seem to be a well-defined binding,
> > >>>> > > > and it
> > >>>> > > > seems like a relatively generic thing to describe.
> > >>>> > > >
> > >>>>> > > > > +
> > >>>>> > > > > +Example:
> > >>>>> > > > > +	rotator: rotator at 12810000 {
> > >>>>> > > > > +		compatible = "samsung,exynos4210-rotator";
> > >>>>> > > > > +		reg = <0x12810000 0x1000>;
> > >>>>> > > > > +		interrupts = <0 83 0>;
> > >>>>> > > > > +		clocks = <&clock 278>;
> > >>>>> > > > > +		clock-names = "rotator";
> > >>>>> > > > > +		status = "disabled";
> > >>>>> > > > > +		ycbcr420_2p {
> > >>>> > > >
> > >>>> > > > Which names are allowed for these subnodes?
> > >>>> > > >
> > >>>>> > > > > +			min_w = <32>;
> > >>>>> > > > > +			min_h = <32>;
> > >>>>> > > > > +			max_w = <32768>;
> > >>>>> > > > > +			max_h = <32768>;
> > >>>>> > > > > +			align = <3>;
> > >>>> > > >
> > >>>> > > > min-width, min-height, max-width, max-height? What units are
> > >>>> > > > they in?
> > >>>> > > >
> > >>>> > > > What does alignment specify exactly?
> > >>>> > > >
> > >>>> > > > Are these a configurable part of the rotator hardware, or are
> > >>>> > > > these
> > >>>> > > > values always the same?
> > >>> > >
> > >>> > > Right, that seems like configurable part. At least, min_w/h and
> > >>> > > max_w/h
> > >> >
> > >> > can
> > >> >
> > >>> > > be different values according to SoC and pixel formats so they
> > >>> > > should be described enough in this dt-binding document file.
> > >> >
> > >> > Is there really this much configurability? Could each of those
> > >> > values be a different on different SoCs
> > >
> > > Not much but Yes. Rotator devices of Exynos SoC support various pixel
> > > formats; RGB888, RGB565, YUV422, YUV420-2Plane, and YUV420-3Plane,
> > > and each of these pixel formats could be different limitation to
> > > minimum and maximum sizes. For example, the below shows the
> > > limitation to Rotator device of Exynos4412 SoC according to pixel
> > > formats,>
> > >          Image format          Minimum size          Maximum size
> > >
> > >           RGB888                    8x8                     8kx8k
> > >           RGB565                    16x16                  16kx16k
> > >           YUV422                    16x16                  16kx16k
> > >           YUV420 2-Plane         32x32                  32kx32k(in
> > >           case of Y components) YUV420 3-Plane         64x32
> > >                   32kx32k(in case of Y components)>
> > > And, I guess those limitations are slightly different according to
> > > Exynos SoC versions as long as I know.
> > >
> > > Thanks,
> > > Inki Dae
> > >
> > >> > , or could you just extract those values
> > >> > from the SoC/rotator hardware version and thus the DT compatible
> > >> > string?
> > My gut feeling is that those constraints could be well defined
> > in the driver as static data and selected by the compatible property.
> > Defining this in Device Tree may easily get out of control, when the
> > limits become dependant on more parameters.
> >
> > Whether devices should be described in much detail in DT rather than
> > using multiple compatible strings had been discussed multiple times,
> > for instance please see thread [1].
> 
> +1
> 
> The binding should not describe hardware functionality and how it works,
> but rather what hardware it is, unless it is really necessary.

Good comments. Agree.

Thanks,
Inki Dae

> In this
> case this information can be placed in per-compatible static driver data,
> so there is no such need.
> 
> Best regards,
> Tomasz
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From mcuos.com at gmail.com  Mon Jul 22 22:05:39 2013
From: mcuos.com at gmail.com (Wan ZongShun)
Date: Tue, 23 Jul 2013 10:05:39 +0800
Subject: [PATCH V2] USB: EHCI: make ehci-w90X900 a separate driver
In-Reply-To: <1374488380-26428-1-git-send-email-manjunath.goudar@linaro.org>
References: <1372347109-5563-1-git-send-email-manjunath.goudar@linaro.org>
 <1374488380-26428-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <CAKT61h_fdTHH=K2-6oHM4L+Ec6h2zRjS19gDKOZVyv2BCrpJhA@mail.gmail.com>

2013/7/22 Manjunath Goudar <manjunath.goudar at linaro.org>:
> Separate the W90X900(W90P910) on-chip host controller driver from
> ehci-hcd host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> however, note that other changes are still needed before W90X900(W90P910)
> can be booted with a multi-platform kernel
>
> and an ehci driver that only works on one of them.
>
> With the infrastructure added by Alan Stern in patch 3e0232039
> "USB: EHCI: prepare to make ehci-hcd a library module", we can
> avoid this problem by turning a bus glue into a separate
> module, as we do here for the w90X900 bus glue.
>
> Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Greg KH <greg at kroah.com>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Wan ZongShun <mcuos.com at gmail.com>
> Cc: linux-usb at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
>

Manjunath,

Thanks for your patch, it is good to me.

Acked-by: Wan Zongshun <mcuos.com at gmail.com>

> V2:
>  -Arranged  #include's in alphabetical order.
>  -Replaced "w90p910" by "w90x900" because it is supports
>   all series of w90x900.
> ---
>  drivers/usb/host/Kconfig        |    2 +-
>  drivers/usb/host/Makefile       |    1 +
>  drivers/usb/host/ehci-hcd.c     |    5 ---
>  drivers/usb/host/ehci-w90x900.c |   85 ++++++++++++++++-----------------------
>  4 files changed, 37 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index ba52912..7bc598b 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -244,7 +244,7 @@ config USB_EHCI_MV
>           SoCs, see USB_EHCI_HCD_ORION for those.
>
>  config USB_W90X900_EHCI
> -       bool "W90X900(W90P910) EHCI support"
> +       tristate "W90X900(W90P910) EHCI support"
>         depends on ARCH_W90X900
>         ---help---
>                 Enables support for the W90X900 USB controller
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index 7664db8..28adb3f 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -35,6 +35,7 @@ obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
>  obj-$(CONFIG_USB_EHCI_MSM)     += ehci-msm.o
>  obj-$(CONFIG_USB_EHCI_TEGRA)   += ehci-tegra.o
>  obj-$(CONFIG_USB_EHCI_MV)       += ehci-mv.o
> +obj-$(CONFIG_USB_W90X900_EHCI) += ehci-w90x900.o
>
>  obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
>  obj-$(CONFIG_USB_ISP116X_HCD)  += isp116x-hcd.o
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index 5717dcd..4a5644e 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -1249,11 +1249,6 @@ MODULE_LICENSE ("GPL");
>  #define XILINX_OF_PLATFORM_DRIVER      ehci_hcd_xilinx_of_driver
>  #endif
>
> -#ifdef CONFIG_USB_W90X900_EHCI
> -#include "ehci-w90x900.c"
> -#define        PLATFORM_DRIVER         ehci_hcd_w90x900_driver
> -#endif
> -
>  #ifdef CONFIG_USB_OCTEON_EHCI
>  #include "ehci-octeon.c"
>  #define PLATFORM_DRIVER                ehci_octeon_driver
> diff --git a/drivers/usb/host/ehci-w90x900.c b/drivers/usb/host/ehci-w90x900.c
> index 59e0e24..4d6631d 100644
> --- a/drivers/usb/host/ehci-w90x900.c
> +++ b/drivers/usb/host/ehci-w90x900.c
> @@ -11,13 +11,28 @@
>   *
>   */
>
> +#include <linux/dma-mapping.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
>  #include <linux/platform_device.h>
> +#include <linux/usb.h>
> +#include <linux/usb/hcd.h>
> +
> +#include "ehci.h"
>
>  /* enable phy0 and phy1 for w90p910 */
>  #define        ENPHY           (0x01<<8)
>  #define PHY0_CTR       (0xA4)
>  #define PHY1_CTR       (0xA8)
>
> +#define DRIVER_DESC "EHCI w90x900 driver"
> +
> +static const char hcd_name[] = "ehci-w90x900 ";
> +
> +static struct hc_driver __read_mostly ehci_w90x900_hc_driver;
> +
>  static int usb_w90x900_probe(const struct hc_driver *driver,
>                       struct platform_device *pdev)
>  {
> @@ -99,54 +114,6 @@ void usb_w90x900_remove(struct usb_hcd *hcd, struct platform_device *pdev)
>         usb_put_hcd(hcd);
>  }
>
> -static const struct hc_driver ehci_w90x900_hc_driver = {
> -       .description = hcd_name,
> -       .product_desc = "Nuvoton w90x900 EHCI Host Controller",
> -       .hcd_priv_size = sizeof(struct ehci_hcd),
> -
> -       /*
> -        * generic hardware linkage
> -        */
> -       .irq = ehci_irq,
> -       .flags = HCD_USB2|HCD_MEMORY,
> -
> -       /*
> -        * basic lifecycle operations
> -        */
> -       .reset = ehci_setup,
> -       .start = ehci_run,
> -
> -       .stop = ehci_stop,
> -       .shutdown = ehci_shutdown,
> -
> -       /*
> -        * managing i/o requests and associated device resources
> -        */
> -       .urb_enqueue = ehci_urb_enqueue,
> -       .urb_dequeue = ehci_urb_dequeue,
> -       .endpoint_disable = ehci_endpoint_disable,
> -       .endpoint_reset = ehci_endpoint_reset,
> -
> -       /*
> -        * scheduling support
> -        */
> -       .get_frame_number = ehci_get_frame,
> -
> -       /*
> -        * root hub support
> -        */
> -       .hub_status_data = ehci_hub_status_data,
> -       .hub_control = ehci_hub_control,
> -#ifdef CONFIG_PM
> -       .bus_suspend = ehci_bus_suspend,
> -       .bus_resume = ehci_bus_resume,
> -#endif
> -       .relinquish_port        = ehci_relinquish_port,
> -       .port_handed_over       = ehci_port_handed_over,
> -
> -       .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
> -};
> -
>  static int ehci_w90x900_probe(struct platform_device *pdev)
>  {
>         if (usb_disabled())
> @@ -173,7 +140,25 @@ static struct platform_driver ehci_hcd_w90x900_driver = {
>         },
>  };
>
> +static int __init ehci_w90X900_init(void)
> +{
> +       if (usb_disabled())
> +               return -ENODEV;
> +
> +       pr_info("%s: " DRIVER_DESC "\n", hcd_name);
> +
> +       ehci_init_driver(&ehci_w90x900_hc_driver, NULL);
> +       return platform_driver_register(&ehci_hcd_w90x900_driver);
> +}
> +module_init(ehci_w90X900_init);
> +
> +static void __exit ehci_w90X900_cleanup(void)
> +{
> +       platform_driver_unregister(&ehci_hcd_w90x900_driver);
> +}
> +module_exit(ehci_w90X900_cleanup);
> +
> +MODULE_DESCRIPTION(DRIVER_DESC);
>  MODULE_AUTHOR("Wan ZongShun <mcuos.com at gmail.com>");
> -MODULE_DESCRIPTION("w90p910 usb ehci driver!");
> -MODULE_LICENSE("GPL");
>  MODULE_ALIAS("platform:w90p910-ehci");
> +MODULE_LICENSE("GPL v2");
> --
> 1.7.9.5
>



--
Wan ZongShun.
www.mcuos.com


From acourbot at nvidia.com  Mon Jul 22 22:15:00 2013
From: acourbot at nvidia.com (Alex Courbot)
Date: Tue, 23 Jul 2013 11:15:00 +0900
Subject: [PATCH] decompressors: fix "no limit" output buffer length
In-Reply-To: <1374516481.14712.3.camel@linaro1.home>
References: <1374476169-32194-1-git-send-email-acourbot@nvidia.com>
 <1374516481.14712.3.camel@linaro1.home>
Message-ID: <51EDE724.5020507@nvidia.com>

On 07/23/2013 03:08 AM, Jon Medhurst (Tixy) wrote:
> On Mon, 2013-07-22 at 15:56 +0900, Alexandre Courbot wrote:
>> When decompressing into memory, the output buffer length is set to some
>> arbitrarily high value (0x7fffffff) to indicate the output is,
>> virtually, unlimited in size.
>>
>> The problem with this is that some platforms have their physical memory
>> at high physical addresses (0x80000000 or more), and that the output
>> buffer address and its "unlimited" length cannot be added without
>> overflowing. An example of this can be found in inflate_fast():
>>
>> /* next_out is the output buffer address */
>> out = strm->next_out - OFF;
>> /* avail_out is the output buffer size. end will overflow if the output
>>   * address is >= 0x80000104 */
>> end = out + (strm->avail_out - 257);
>>
>> This has huge consequences on the performance of kernel decompression,
>> since the following exit condition of inflate_fast() will be always
>> true:
>>
>> } while (in < last && out < end);
>>
>> Indeed, "end" has overflowed and is now always lower than "out". As a
>> result, inflate_fast() will return after processing one single byte of
>> input data, and will thus need to be called an unreasonably high number
>> of times. This probably went unnoticed because kernel decompression is
>> fast enough even with this issue.
>>
>> Nonetheless, adjusting the output buffer length in such a way that the
>> above pointer arithmetic never overflows results in a kernel
>> decompression that is about 3 times faster on affected machines.
>>
>> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com>
>
> This speeds up booting of my Versatile Express TC2 by 15 seconds when
> starting on the A7 cluster :-)
>
> Tested-by: Jon Medhurst <tixy at linaro.org>

Good to hear! Thanks for taking the time to test this.

Although the patch seems ok to me in its current form, there are two 
points for which I still have small doubts:

1) Whether size_t and pointers will have the same size on all platforms. 
It not we might end up with some funny behaviors. My limited research on 
the topic did not end up with evidence that their size may differ, but I 
don't have a definite case that they do neither.
2) Whether all platforms have their address space ending at (~0). I do 
not have a concrete example in mind, but can imagine, say, a platform 
which represents its addresses as 32-bit pointers but has a smaller 
physical bus. In this case the current calculation could cause overflows 
again.

If one (or both) of these points are to be concerned about, there may 
exist macros I am not aware of that better represent the actual limits 
of pointers in the kernel.

Thanks,
Alex.

>
>> ---
>>   lib/decompress_inflate.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/decompress_inflate.c b/lib/decompress_inflate.c
>> index 19ff89e..d619b28 100644
>> --- a/lib/decompress_inflate.c
>> +++ b/lib/decompress_inflate.c
>> @@ -48,7 +48,7 @@ STATIC int INIT gunzip(unsigned char *buf, int len,
>>   		out_len = 0x8000; /* 32 K */
>>   		out_buf = malloc(out_len);
>>   	} else {
>> -		out_len = 0x7fffffff; /* no limit */
>> +		out_len = ((size_t)~0) - (size_t)out_buf; /* no limit */
>>   	}
>>   	if (!out_buf) {
>>   		error("Out of memory while allocating output buffer");
>
>



From olof at lixom.net  Mon Jul 22 22:35:40 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 22 Jul 2013 19:35:40 -0700
Subject: [PATCH v2 2/2] ARM: STi: Set correct ARM ERRATAs.
In-Reply-To: <1373354793-26400-1-git-send-email-srinivas.kandagatla@st.com>
References: <1373354752-26292-1-git-send-email-srinivas.kandagatla@st.com>
 <1373354793-26400-1-git-send-email-srinivas.kandagatla@st.com>
Message-ID: <20130723023540.GA14983@quad.lixom.net>

On Tue, Jul 09, 2013 at 08:26:33AM +0100, Srinivas KANDAGATLA wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla at st.com>
> 
> Some of the ARM_ERRATA selection is not done in the initial SOC support
> patches. This patch selects 2 new ARM_ERRATA's and removes one which was
> actually fixed.

These entries should be sorted, and you inserted in random order.

I'll rearrange the order when applying.

(Patch applied with that change).

Thanks,

-Olof


From olof at lixom.net  Mon Jul 22 22:35:52 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 22 Jul 2013 19:35:52 -0700
Subject: [PATCH v2 1/2] ARM: dts: STi: Fix pinconf setup for STiH416
 serial2
In-Reply-To: <1373354784-26357-1-git-send-email-srinivas.kandagatla@st.com>
References: <1373354752-26292-1-git-send-email-srinivas.kandagatla@st.com>
 <1373354784-26357-1-git-send-email-srinivas.kandagatla@st.com>
Message-ID: <20130723023552.GB14983@quad.lixom.net>

On Tue, Jul 09, 2013 at 08:26:24AM +0100, Srinivas KANDAGATLA wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla at st.com>
> 
> This patch fixes a bug in pinctrl setup of serial2 device, Some of the
> pins in the pinctrl node of serial2 do not belong to that
> pin-controller. This patch divides them in the pins into there
> respective pin controller nodes.
> 
> Without this patch serial on StiH416-B2000 Board will not work as it
> fails with:
> 
> "st-pinctrl pin-controller-rear.3: failed to get pin(99) name
> st-pinctrl pin-controller-rear.3: maps: function serial2 group serial2-0
> num 4
> pinconfig core: failed to register map default (3): no group/pin given"
> 
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at st.com>

Applied to fixes, thanks.


-Olof


From olof at lixom.net  Mon Jul 22 22:39:07 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 22 Jul 2013 19:39:07 -0700
Subject: [PATCH] dmaengine: shdma: fix a build failure on platforms with
 no DMA support
In-Reply-To: <20130716012041.GA942@verge.net.au>
References: <1373422152-29976-1-git-send-email-horms+renesas@verge.net.au>
 <20130716012041.GA942@verge.net.au>
Message-ID: <20130723023907.GC14983@quad.lixom.net>

On Tue, Jul 16, 2013 at 10:20:41AM +0900, Simon Horman wrote:
> On Wed, Jul 10, 2013 at 11:09:12AM +0900, Simon Horman wrote:
> > From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
> > 
> > On platforms with no support for the shdma dmaengine driver build is
> > currently failing with
> > 
> > drivers/built-in.o: In function `sh_mobile_sdhi_probe':
> > drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference to`shdma_chan_filter'
> > 
> > Fix the breakage by defining shdma_chan_filter to NULL in such
> > configurations.
> > 
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> > [horms+renesas at verge.net.au: Apply change to shdma-base.h instead of sh_dma.h]
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> > ---
> >  include/linux/shdma-base.h | 4 ++++
> >  1 file changed, 4 insertions(+)
> 
> > 
> > Hi Vinod,
> > 
> > please consider this fix from Guennadi for v3.11 which I have rebased on top of
> > next-20130709. It fixes a build problem on a number of shmobile defconfigs
> > including bockw.
> 
> Ping.
> 
> Would it be appropriate for me to take this change through my tree?
> It seems to resolve a regression in v3.11-rc1.

I'll take it through arm-soc since there's no response from Vinod. I've
applied it in the fixes branch we have.


-Olof


From olof at lixom.net  Mon Jul 22 22:41:12 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 22 Jul 2013 19:41:12 -0700
Subject: [PATCH fix for v3.11 (repost)] dmaengine: shdma: fix a build
 failure on platforms with no DMA support
In-Reply-To: <20130717235058.GA10683@verge.net.au>
References: <20130717235058.GA10683@verge.net.au>
Message-ID: <20130723024112.GA15637@quad.lixom.net>

On Thu, Jul 18, 2013 at 08:50:58AM +0900, Simon Horman wrote:
> From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
> 
> On platforms with no support for the shdma dmaengine driver build is
> currently failing with
> 
> drivers/built-in.o: In function `sh_mobile_sdhi_probe':
> drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference to`shdma_chan_filter'
> 
> Fix the breakage by defining shdma_chan_filter to NULL in such
> configurations.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> [horms+renesas at verge.net.au: Apply change to shdma-base.h instead of sh_dma.h]
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> ---
>  include/linux/shdma-base.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> Hi Vinod,
> 
> please consider this fix from Guennadi for v3.11 which I have rebased on top of
> next-20130709. It fixes a build problem on a number of shmobile defconfigs
> including bockw.
> 
> Alternatively, I would be happy to take this through the renesas tree.
> 
> I posted this patch last week but I'm wondering if you missed it somehow.
> This patch resolves a regression in v3.11-rc1.

As mentioned on the other thread, I have applied this in the arm-soc fixes
branch for 3.11 now.


-Olof


From olof at lixom.net  Mon Jul 22 22:47:39 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 22 Jul 2013 19:47:39 -0700
Subject: [PATCH] ARM: multi_v7: Enabled omap4430 sdp nfsroot
In-Reply-To: <20130715132326.GA12025@arwen.pp.htv.fi>
References: <20130715075816.GN7656@atomide.com>
 <20130715132326.GA12025@arwen.pp.htv.fi>
Message-ID: <20130723024739.GB15637@quad.lixom.net>

On Mon, Jul 15, 2013 at 04:23:26PM +0300, Felipe Balbi wrote:
> On Mon, Jul 15, 2013 at 12:58:17AM -0700, Tony Lindgren wrote:
> > Author: Tony Lindgren <tony at atomide.com>
> > Date:   Mon Jul 15 00:39:41 2013 -0700
> > 
> >     ARM: multi_v7: Enabled omap4430 sdp nfsroot
> >     
> >     By adding support for OCP2SCP, SPI and KS8851 I can also boot test
> >     multi_v7_defconfig easily.
> >     
> >     Note that if using an older u-boot, CONFIG_ARM_ATAG_DTB_COMPAT=y
> >     may also be needed for the appended DTB based booting.
> >     
> >     Signed-off-by: Tony Lindgren <tony at atomide.com>
> 
> We will also use OCP2SCP driver to enable USB3 on OMAP5 uEVM, good it's
> already enabled in multi_v7 after this patch.
> 
> Reviewed-by: Felipe Balbi <balbi at ti.com>

Applied to fixes for 3.11 since it gives us networking on panda.


-Olof


From olof at lixom.net  Mon Jul 22 22:50:48 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 22 Jul 2013 19:50:48 -0700
Subject: [GIT PULL] DaVinci fixes for v3.11-rc2
In-Reply-To: <51E572A9.2080201@ti.com>
References: <51E572A9.2080201@ti.com>
Message-ID: <20130723025048.GC15637@quad.lixom.net>

On Tue, Jul 16, 2013 at 09:49:53PM +0530, Sekhar Nori wrote:
> Hi Arnd, Olof,
> 
> Can you please pull the following fixes for v3.11-rc2?
> 
> Thanks,
> Sekhar
> 
> The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:
> 
>   Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v3.11-rc2
> 
> for you to fetch changes up to cf690331642010a837c026088588761f61528ddf:
> 
>   ARM: davinci: defconfig: enable EDMA driver (2013-07-16 20:39:39 +0530)
> 
> ----------------------------------------------------------------
> DaVinci fixes for v3.11-rc2
> 
> The pull request includes fixes for sparse
> warnings, defconfig changes to enable DMA
> usage on peripherals and removal of a duplicated
> include file.

Pulled, thanks.

-Olof


From sachin.kamat at linaro.org  Mon Jul 22 22:53:57 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Tue, 23 Jul 2013 08:23:57 +0530
Subject: [PATCH v2 0/6] clk: exynos: Some fixes and cleanup
In-Reply-To: <20130722180515.7598.56428@quantum>
References: <1374141682-29432-1-git-send-email-sachin.kamat@linaro.org>
 <20130722180515.7598.56428@quantum>
Message-ID: <CAK9yfHziN=_vw-JtMTf_58L-5YrGo1j-A35Lt5TKaQHOj_wv1Q@mail.gmail.com>

On 22 July 2013 23:35, Mike Turquette <mturquette at linaro.org> wrote:
> Quoting Sachin Kamat (2013-07-18 03:01:16)
>> Resending some of patches (1, 3 and 5) as per discussion in thread [1].
>> Other patches in the series are new.
>>
>> [1] http://comments.gmane.org/gmane.linux.kernel.samsung-soc/19933
>>
>> Changes since v1:
>> * Removed an unnecessary change in Patch 1 as pointed out by Kukjin Kim.
>> * Added Kukjin's ack to patches 3~6.
>
> Thanks for the fixes! Will take into clk-next unless you need them to go
> into -rc3, but I don't think there are any regression fixes here.

Not at all. They can all go in for 3.12.
Thanks.

-- 
With warm regards,
Sachin


From olof at lixom.net  Mon Jul 22 22:54:11 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 22 Jul 2013 19:54:11 -0700
Subject: [GIT PULL] omap fixes against v3.11-rc1
In-Reply-To: <20130719104538.GE7656@atomide.com>
References: <20130719104538.GE7656@atomide.com>
Message-ID: <20130723025411.GD15637@quad.lixom.net>

On Fri, Jul 19, 2013 at 03:45:38AM -0700, Tony Lindgren wrote:
> 
> The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:
> 
>   Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/fixes-against-rc1
> 
> for you to fetch changes up to 7956c487e407bdbf7f8c8a570fd5d4d089973692:
> 
>   Merge branch 'omap-for-v3.11/dt-fixes' into omap-for-v3.11/fixes (2013-07-19 03:28:35 -0700)

Pulled, thanks. I've dropped the multi_v7 defconfig update I had applied
manually since it came in through here too.


-Olof


From olof at lixom.net  Mon Jul 22 22:59:35 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 22 Jul 2013 19:59:35 -0700
Subject: [GIT PULL] ARM: imx: fixes for 3.11
In-Reply-To: <20130715161236.GC23589@S2101-09.ap.freescale.net>
References: <20130715161236.GC23589@S2101-09.ap.freescale.net>
Message-ID: <20130723025935.GA16733@quad.lixom.net>

On Tue, Jul 16, 2013 at 12:12:38AM +0800, Shawn Guo wrote:
> The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:
> 
>   Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-fixes-3.11

Pulled, thanks. Some of these would have been nice to see a little earlier, but
I also wasn't very fast at pulling them so I can't complain that loudly. :)



-Olof


From olof at lixom.net  Mon Jul 22 23:02:01 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 22 Jul 2013 20:02:01 -0700
Subject: [PATCH] ARM: footbridge: fix overlapping PCI mappings
In-Reply-To: <CAL_JsqKaha08U0fN1FruEEfsH=jAGzsxeJATJqeDvburd6EDjw@mail.gmail.com>
References: <1372387356-15341-1-git-send-email-vapier@gentoo.org>
 <CAL_JsqKaha08U0fN1FruEEfsH=jAGzsxeJATJqeDvburd6EDjw@mail.gmail.com>
Message-ID: <20130723030201.GB16733@quad.lixom.net>

On Mon, Jul 15, 2013 at 03:52:12PM -0500, Rob Herring wrote:
> On Thu, Jun 27, 2013 at 9:42 PM, Mike Frysinger <vapier at gentoo.org> wrote:
> > Commit 8ef6e6201b26cb9fde79c1baa08145af6aca2815 (ARM: footbridge: use
> > fixed PCI i/o mapping) broke booting on my netwinder.  Before that,
> > everything boots fine.  Since then, it crashes on boot.
> >
> > With earlyprintk, I see it BUG-ing like so:
> > kernel BUG at lib/ioremap.c:27!
> > Internal error: Oops - BUG: 0 [#1] ARM
> > ...
> > [<c0139b54>] (ioremap_page_range+0x128/0x154) from [<c02e6a6c>] (dc21285_setup+0xd0/0x114)
> > [<c02e6a6c>] (dc21285_setup+0xd0/0x114) from [<c02e4874>] (pci_common_init+0xa0/0x298)
> > [<c02e4874>] (pci_common_init+0xa0/0x298) from [<c02e793c>] (netwinder_pci_init+0xc/0x18)
> > [<c02e793c>] (netwinder_pci_init+0xc/0x18) from [<c02e27d0>] (do_one_initcall+0xb4/0x180)
> > ...
> >
> > Russell points out it's because of overlapping PCI mappings that was
> > added with the aforementioned commit.  Rob thought the code would re-use
> > the static mapping, but that turns out to not be the case and instead
> > hits the BUG further down.
> >
> > After deleting this hunk as suggested by Russel, the system boots up fine
> > again and all my PCI devices work (IDE, ethernet, the DC21285).
> >
> > Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> 
> Acked-by: Rob Herring <rob.herring at calxeda.com>
> 
> Olof, Kevin,
> 
> Please apply and add stable.

Done (stable v3.5+). Thanks.


-Olof


From olof at lixom.net  Mon Jul 22 23:03:46 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 22 Jul 2013 20:03:46 -0700
Subject: [GIT PULL] Nomadik defconfig updates
In-Reply-To: <CACRpkdZxSkLrKY1rZwdbo2ZJpVqExu7GRyhWN5T8V+aR_jx2Dw@mail.gmail.com>
References: <CACRpkdZxSkLrKY1rZwdbo2ZJpVqExu7GRyhWN5T8V+aR_jx2Dw@mail.gmail.com>
Message-ID: <20130723030346.GC16733@quad.lixom.net>

On Sat, Jul 20, 2013 at 01:34:18PM +0200, Linus Walleij wrote:
> Hi ARM SoC folks,
> 
> now we are past -rc1 and I'd like to have these defconfig changes for
> the Nomadik pulled in. It is similar in scope to the ux500 defconfig
> updates I sent the other week, and all have been circulated on the
> mailing list.
> 
> Please pull them in!
> 
> Yours,
> Linus Walleij
> 
> 
> The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:
> 
>   Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
> tags/nomadik-defconfig-for-arm-soc
> 
> for you to fetch changes up to fec57e15527ab2e3d22cfbf04f2b98f823f294ff:
> 
>   ARM: nomadik: configure for NO_HZ and HRTIMERS (2013-07-20 11:59:45 +0200)
> 
> ----------------------------------------------------------------
> This updates the Nomadik defconfig post-v3.11-rc1:
> - Update the baseline so we need not rely on make
>   oldconfig so much
> - MMC defconfig updates
> - Activate NO_HZ_IDLE and HRTIMERS

Pulled, thanks. Next time feel free to post these kind of patches as soon as
the bulk of our merge has been done so we can get it in during -rc1 or -rc2.


-Olof


From olof at lixom.net  Mon Jul 22 23:04:19 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 22 Jul 2013 20:04:19 -0700
Subject: [PATCH] ARM: highbank: Only touch common coherency control
 register fields
In-Reply-To: <1374436417-29761-1-git-send-email-robherring2@gmail.com>
References: <1374436417-29761-1-git-send-email-robherring2@gmail.com>
Message-ID: <20130723030419.GD16733@quad.lixom.net>

On Sun, Jul 21, 2013 at 02:53:37PM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> Midway adds new register fields to the coherency control registers, so
> writing absolute values will break on Midway. Change the register
> accesses to only modify the necessary and common fields in order to
> support both Midway and Highbank.
> 
> Signed-off-by: Rob Herring <rob.herring at calxeda.com>

Applied to fixes, thanks.


-Olof


From sachin.kamat at linaro.org  Mon Jul 22 23:11:32 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Tue, 23 Jul 2013 08:41:32 +0530
Subject: [PATCH 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <51ED89CA.2040908@gmail.com>
References: <1372054438-15693-1-git-send-email-sachin.kamat@linaro.org>
 <CAK9yfHzmF_oxc3DsuT5wtXX2C5O+wLxz4C2Ps3cVPnKLb8jOEw@mail.gmail.com>
 <0ad601ce868c$d88bff40$89a3fdc0$@org> <3136364.6D0qu7zGk3@amdc1227>
 <51ED89CA.2040908@gmail.com>
Message-ID: <CAK9yfHyNqDJKuC8urpyrKR564jVJVfsJRRF0Z9a3p52iLWLZ8A@mail.gmail.com>

On 23 July 2013 01:06, Sylwester Nawrocki <sylvester.nawrocki at gmail.com> wrote:
> On 07/22/2013 07:21 PM, Tomasz Figa wrote:
>>
>> On Monday 22 of July 2013 12:37:52 Kukjin Kim wrote:
>>>
>>> Sachin Kamat wrote:
>>>>
>>>> On 22 July 2013 07:18, Kukjin Kim<kgene.kim at samsung.com>  wrote:
>>>>>
>>>>> Sachin Kamat wrote:
>>>>>>
>>>>>> With the recent cleanup in Exynos platform code notably commits
>>>>>> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
>>>>>> more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the
>>>>>> definition
>>>>>> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs
>>>>
>>>>
>>>> like
>>>>
>>>>>> Exynos4412 which have more (285) than the default number of GPIOs
>>>
>>>
>>> (255).
>>>
>>>>>> Thus define this number in Kconfig file. Without this patch we get
>>>>>> the
>>>>>> following errors during boot:
>>>>>>
>>>>>> gpiochip_add: gpios 251..258 (gpv0) failed to register
>>>>>> samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
>>>>>> error code: -22
>>>>>> samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
>>>>>>
>>>>>> Signed-off-by: Sachin Kamat<sachin.kamat at linaro.org>
>>>>>> Cc: Tomasz Figa<t.figa at samsung.com>
>>>>>> ---
>>>>>> Based on Kukjin's for-next tree.
>>>>>> ---
>>>>>>
>>>>>>   arch/arm/Kconfig |    1 +
>>>>>>   1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>>>>> index ddf2667..380a53b 100644
>>>>>> --- a/arch/arm/Kconfig
>>>>>> +++ b/arch/arm/Kconfig
>>>>>> @@ -1578,6 +1578,7 @@ config ARCH_NR_GPIO
>>>>>>
>>>>>>        default 512 if SOC_OMAP5
>>>>>>        default 392 if ARCH_U8500
>>>>>>        default 352 if ARCH_VT8500
>>>>>>
>>>>>> +     default 288 if ARCH_EXYNOS
>>>>>>
>>>>>>        default 288 if ARCH_SUNXI
>>>>>>        default 264 if MACH_H4700
>>>>>>        default 0
>>>>>>
>>>>>> --
>>>>>> 1.7.9.5
>>>>>
>>>>>
>>>>> Hmm, BTW, I'm wondering why it is 288 not 285 or other specific
>>>
>>>
>>> number...
>>>
>>>> I wasn't really sure if we can have any number there. I chose the
>>>> closest one (288) which was already used by other platform.
>>>> If there is no problem to use 285 itself then I can resend with that
>>>> number. Please let me know.
>>>
>>>
>>> If there is no reason, please don't use bigger value than necessary one.
>>
>>
>> Hmm, what about some GPIO expanders that would require bigger GPIO address
>> space? I would reserve some space just in case, i.e. define this value to
>> be
>> the highest number of GPIOs on all Exynos SoCs + some extra, like 32 or
>> 64.
>
>
> That sounds like a good idea. IIRC I once had to increase ARCH_NR_GPIO to
> make the wm8994 GPIO controller working. The wm8994 driver also handles
> WM1811 audio codec that some Exynos development boards are shipped with.

Looks like a valid point.

Kukjin,
Let me know your opinion about this before I respin the patch.

-- 
With warm regards,
Sachin


From nicolas.pitre at linaro.org  Mon Jul 22 23:31:16 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 23:31:16 -0400
Subject: [PATCH 00/13] The big.LITTLE In-Kernel Switcher (IKS), part 1
Message-ID: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>

This is the initial posting of the b.L switcher patches for public review.
The tentative goal is to have those patches merged upstream during the
next (v3.12) merge window.

The rationale for this code can be found here:

   http://lwn.net/Articles/481055/

Here is the first part of the patch series with only the core patches
providing basic switcher functionality.  The second part consists of
optimizations to reduce switching latency as well as tracing
infrastructure support.  The third part adds switcher support to the
arm_big_little cpufreq driver.

To simplify the review process, only the first part is posted for
review at this time.  The first and second parts still can be found here:

   git://git.linaro.org/people/nico/linux iks

The first and second parts are meant to go through RMK's tree.
The third part should be merged via the cpufreq tree once at least
the first part has been accepted for mainline inclusion.

As the diffstat shows, this code is very much self contained and doesn't
really intrude into core parts of the kernel.


 arch/arm/Kconfig                       |  25 ++
 arch/arm/common/Makefile               |   2 +
 arch/arm/common/bL_switcher.c          | 611 +++++++++++++++++++++++++++
 arch/arm/common/bL_switcher_dummy_if.c |  71 ++++
 arch/arm/include/asm/bL_switcher.h     |  17 +
 arch/arm/kernel/sleep.S                |  25 +-
 arch/arm/kernel/suspend.c              |   8 +-
 drivers/irqchip/irq-gic.c              | 102 ++++-
 include/linux/irqchip/arm-gic.h        |   5 +
 9 files changed, 846 insertions(+), 20 deletions(-)


Nicolas




From nicolas.pitre at linaro.org  Mon Jul 22 23:31:18 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 23:31:18 -0400
Subject: [PATCH 02/13] ARM: gic: add CPU migration support
In-Reply-To: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374550289-25305-3-git-send-email-nicolas.pitre@linaro.org>

This is required by the big.LITTLE switcher code.

The gic_migrate_target() changes the CPU interface mapping for the
current CPU to redirect SGIs to the specified interface, and it also
updates the target CPU for each interrupts to that CPU interface
if they were targeting the current interface.  Finally, pending
SGIs for the current CPU are forwarded to the new interface.

Because Linux does not use it, the SGI source information for the
forwarded SGIs is not preserved.  Neither is the source information
for the SGIs sent by the current CPU to other CPUs adjusted to match
the new CPU interface mapping.  The required registers are banked so
only the target CPU could do it.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
---
 drivers/irqchip/irq-gic.c       | 81 +++++++++++++++++++++++++++++++++++++++--
 include/linux/irqchip/arm-gic.h |  4 ++
 2 files changed, 82 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index ee7c503120..6bd5a8c1aa 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -253,10 +253,9 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
 	if (cpu >= NR_GIC_CPU_IF || cpu >= nr_cpu_ids)
 		return -EINVAL;
 
+	raw_spin_lock(&irq_controller_lock);
 	mask = 0xff << shift;
 	bit = gic_cpu_map[cpu] << shift;
-
-	raw_spin_lock(&irq_controller_lock);
 	val = readl_relaxed(reg) & ~mask;
 	writel_relaxed(val | bit, reg);
 	raw_spin_unlock(&irq_controller_lock);
@@ -646,7 +645,9 @@ static void __init gic_pm_init(struct gic_chip_data *gic)
 void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
 {
 	int cpu;
-	unsigned long map = 0;
+	unsigned long flags, map = 0;
+
+	raw_spin_lock_irqsave(&irq_controller_lock, flags);
 
 	/* Convert our logical CPU mask into a physical one. */
 	for_each_cpu(cpu, mask)
@@ -660,6 +661,80 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
 
 	/* this always happens on GIC0 */
 	writel_relaxed(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
+
+	raw_spin_unlock_irqrestore(&irq_controller_lock, flags);
+}
+#endif
+
+#ifdef CONFIG_BL_SWITCHER
+/*
+ * gic_migrate_target - migrate IRQs to another PU interface
+ *
+ * @new_cpu_id: the CPU target ID to migrate IRQs to
+ *
+ * Migrate all peripheral interrupts with a target matching the current CPU
+ * to the interface corresponding to @new_cpu_id.  The CPU interface mapping
+ * is also updated.  Targets to other CPU interfaces are unchanged.
+ * This must be called with IRQs locally disabled.
+ */
+void gic_migrate_target(unsigned int new_cpu_id)
+{
+	unsigned int old_cpu_id, gic_irqs, gic_nr = 0;
+	void __iomem *dist_base;
+	int i, ror_val, cpu = smp_processor_id();
+	u32 val, old_mask, active_mask;
+
+	if (gic_nr >= MAX_GIC_NR)
+		BUG();
+
+	dist_base = gic_data_dist_base(&gic_data[gic_nr]);
+	if (!dist_base)
+		return;
+	gic_irqs = gic_data[gic_nr].gic_irqs;
+
+	old_cpu_id = __ffs(gic_cpu_map[cpu]);
+	old_mask = 0x01010101 << old_cpu_id;
+	ror_val = (old_cpu_id - new_cpu_id) & 31;
+
+	raw_spin_lock(&irq_controller_lock);
+
+	gic_cpu_map[cpu] = 1 << new_cpu_id;
+
+	for (i = 8; i < DIV_ROUND_UP(gic_irqs, 4); i++) {
+		val = readl_relaxed(dist_base + GIC_DIST_TARGET + i * 4);
+		active_mask = val & old_mask;
+		if (active_mask) {
+			val &= ~active_mask;
+			val |= ror32(active_mask, ror_val);
+			writel_relaxed(val, dist_base + GIC_DIST_TARGET + i*4);
+		}
+	}
+
+	raw_spin_unlock(&irq_controller_lock);
+
+	/*
+	 * Now let's migrate and clear any potential SGIs that might be
+	 * pending for us (old_cpu_id).  Since GIC_DIST_SGI_PENDING_SET
+	 * is a banked register, we can only forward the SGI using
+	 * GIC_DIST_SOFTINT.  The original SGI source is lost but Linux
+	 * doesn't use that information anyway.
+	 *
+	 * For the same reason we do not adjust SGI source information
+	 * for previously sent SGIs by us to other CPUs either.
+	 */
+	for (i = 0; i < 16; i += 4) {
+		int j;
+		val = readl_relaxed(dist_base + GIC_DIST_SGI_PENDING_SET + i);
+		if (!val)
+			continue;
+		writel_relaxed(val, dist_base + GIC_DIST_SGI_PENDING_CLEAR + i);
+		for (j = i; j < i + 4; j++) {
+			if (val & 0xff)
+				writel_relaxed((1 << (new_cpu_id + 16)) | j,
+						dist_base + GIC_DIST_SOFTINT);
+			val >>= 8;
+		}
+	}
 }
 #endif
 
diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 3e203eb23c..40bfcac959 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -31,6 +31,8 @@
 #define GIC_DIST_TARGET			0x800
 #define GIC_DIST_CONFIG			0xc00
 #define GIC_DIST_SOFTINT		0xf00
+#define GIC_DIST_SGI_PENDING_CLEAR	0xf10
+#define GIC_DIST_SGI_PENDING_SET	0xf20
 
 #define GICH_HCR			0x0
 #define GICH_VTR			0x4
@@ -73,6 +75,8 @@ static inline void gic_init(unsigned int nr, int start,
 	gic_init_bases(nr, start, dist, cpu, 0, NULL);
 }
 
+void gic_migrate_target(unsigned int new_cpu_id);
+
 #endif /* __ASSEMBLY */
 
 #endif
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Mon Jul 22 23:31:17 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 23:31:17 -0400
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value to index
 into save array
In-Reply-To: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374550289-25305-2-git-send-email-nicolas.pitre@linaro.org>

Currently we hash the MPIDR of the CPU being suspended to determine which
entry in the sleep_save_sp array to use. In some situations, such as when
we want to resume on another physical CPU, the MPIDR of another CPU should
be used instead.

So let's use the value of cpu_logical_map(smp_processor_id()) in place
of the MPIDR in the suspend path.  This will result in the same index
being used as with the previous code unless the caller has modified
cpu_logical_map() beforehand.

The register allocation in __cpu_suspend is reworked in order to better
accommodate the additional argument.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/kernel/sleep.S   | 25 +++++++++++--------------
 arch/arm/kernel/suspend.c |  8 +++++---
 2 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index db1536b8b3..836d10e698 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -55,6 +55,7 @@
  * specific registers and some other data for resume.
  *  r0 = suspend function arg0
  *  r1 = suspend function
+ *  r2 = MPIDR value used to index into sleep_save_sp
  */
 ENTRY(__cpu_suspend)
 	stmfd	sp!, {r4 - r11, lr}
@@ -67,23 +68,19 @@ ENTRY(__cpu_suspend)
 	mov	r5, sp			@ current virtual SP
 	add	r4, r4, #12		@ Space for pgd, virt sp, phys resume fn
 	sub	sp, sp, r4		@ allocate CPU state on stack
-	stmfd	sp!, {r0, r1}		@ save suspend func arg and pointer
-	add	r0, sp, #8		@ save pointer to save block
-	mov	r1, r4			@ size of save block
-	mov	r2, r5			@ virtual SP
 	ldr	r3, =sleep_save_sp
+	stmfd	sp!, {r0, r1}		@ save suspend func arg and pointer
 	ldr	r3, [r3, #SLEEP_SAVE_SP_VIRT]
-	ALT_SMP(mrc p15, 0, r9, c0, c0, 5)
-        ALT_UP_B(1f)
-	ldr	r8, =mpidr_hash
-	/*
-	 * This ldmia relies on the memory layout of the mpidr_hash
-	 * struct mpidr_hash.
-	 */
-	ldmia	r8, {r4-r7}	@ r4 = mpidr mask (r5,r6,r7) = l[0,1,2] shifts
-	compute_mpidr_hash	lr, r5, r6, r7, r9, r4
-	add	r3, r3, lr, lsl #2
+	ALT_SMP(ldr r0, =mpidr_hash)
+       ALT_UP_B(1f)
+	/* This ldmia relies on the memory layout of the mpidr_hash struct */
+	ldmia	r0, {r1, r6-r8}	@ r1 = mpidr mask (r6,r7,r8) = l[0,1,2] shifts
+	compute_mpidr_hash	r0, r6, r7, r8, r2, r1
+	add	r3, r3, r0, lsl #2
 1:
+	mov	r2, r5			@ virtual SP
+	mov	r1, r4			@ size of save block
+	add	r0, sp, #8		@ pointer to save block
 	bl	__cpu_suspend_save
 	adr	lr, BSYM(cpu_suspend_abort)
 	ldmfd	sp!, {r0, pc}		@ call suspend fn
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 41cf3cbf75..2835d35234 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -10,7 +10,7 @@
 #include <asm/suspend.h>
 #include <asm/tlbflush.h>
 
-extern int __cpu_suspend(unsigned long, int (*)(unsigned long));
+extern int __cpu_suspend(unsigned long, int (*)(unsigned long), u32 cpuid);
 extern void cpu_resume_mmu(void);
 
 #ifdef CONFIG_MMU
@@ -21,6 +21,7 @@ extern void cpu_resume_mmu(void);
 int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
 {
 	struct mm_struct *mm = current->active_mm;
+	u32 __mpidr = cpu_logical_map(smp_processor_id());
 	int ret;
 
 	if (!idmap_pgd)
@@ -32,7 +33,7 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
 	 * resume (indicated by a zero return code), we need to switch
 	 * back to the correct page tables.
 	 */
-	ret = __cpu_suspend(arg, fn);
+	ret = __cpu_suspend(arg, fn, __mpidr);
 	if (ret == 0) {
 		cpu_switch_mm(mm->pgd, mm);
 		local_flush_bp_all();
@@ -44,7 +45,8 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
 #else
 int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
 {
-	return __cpu_suspend(arg, fn);
+	u32 __mpidr = cpu_logical_map(smp_processor_id());
+	return __cpu_suspend(arg, fn, __mpidr);
 }
 #define	idmap_pgd	NULL
 #endif
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Mon Jul 22 23:31:20 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 23:31:20 -0400
Subject: [PATCH 04/13] ARM: bL_switcher: add clockevent save/restore support
In-Reply-To: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374550289-25305-5-git-send-email-nicolas.pitre@linaro.org>

From: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

Per-CPU timers that are shutdown when a CPU is switched over must be disabled
upon switching and reprogrammed on the inbound CPU by relying on the
clock events management API. save/restore sequence is executed with irqs
disabled as mandated by the clock events API.

The next_event is an absolute time, hence, when the inbound CPU resumes,
if the timer has expired the min delta is forced into the tick device to
fire after few cycles.

This patch adds switching support for clock events that are per-CPU and
have to be migrated when a switch takes place; the cpumask of the clock
event device is checked against the cpumask of the current cpu, and if
they match, the clockevent device mode is saved and it is put in
shutdown mode. Resume code reprogrammes the tick device accordingly.

Tested on A15/A7 fast models and architected timers.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/common/bL_switcher.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
index e63881b430..d6f7e507d9 100644
--- a/arch/arm/common/bL_switcher.c
+++ b/arch/arm/common/bL_switcher.c
@@ -15,7 +15,11 @@
 #include <linux/sched.h>
 #include <linux/interrupt.h>
 #include <linux/cpu_pm.h>
+#include <linux/cpumask.h>
 #include <linux/workqueue.h>
+#include <linux/clockchips.h>
+#include <linux/hrtimer.h>
+#include <linux/tick.h>
 #include <linux/mm.h>
 #include <linux/string.h>
 #include <linux/irqchip/arm-gic.h>
@@ -122,6 +126,8 @@ static int bL_switchpoint(unsigned long _arg)
 static int bL_switch_to(unsigned int new_cluster_id)
 {
 	unsigned int mpidr, cpuid, clusterid, ob_cluster, ib_cluster, this_cpu;
+	struct tick_device *tdev;
+	enum clock_event_mode tdev_mode;
 	int ret;
 
 	mpidr = read_mpidr();
@@ -167,6 +173,14 @@ static int bL_switch_to(unsigned int new_cluster_id)
 	 */
 	arch_send_wakeup_ipi_mask(cpumask_of(this_cpu));
 
+	tdev = tick_get_device(this_cpu);
+	if (tdev && !cpumask_equal(tdev->evtdev->cpumask, cpumask_of(this_cpu)))
+		tdev = NULL;
+	if (tdev) {
+		tdev_mode = tdev->evtdev->mode;
+		clockevents_set_mode(tdev->evtdev, CLOCK_EVT_MODE_SHUTDOWN);
+	}
+
 	ret = cpu_pm_enter();
 
 	/* we can not tolerate errors at this point */
@@ -197,6 +211,12 @@ static int bL_switch_to(unsigned int new_cluster_id)
 
 	ret = cpu_pm_exit();
 
+	if (tdev) {
+		clockevents_set_mode(tdev->evtdev, tdev_mode);
+		clockevents_program_event(tdev->evtdev,
+					  tdev->evtdev->next_event, 1);
+	}
+
 	local_fiq_enable();
 	local_irq_enable();
 
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Mon Jul 22 23:31:22 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 23:31:22 -0400
Subject: [PATCH 06/13] ARM: bL_switcher: simplify stack isolation
In-Reply-To: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374550289-25305-7-git-send-email-nicolas.pitre@linaro.org>

We now have a dedicated thread for each logical CPU.  That's plenty
of stack space for our needs.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/common/bL_switcher.c | 23 ++++++++---------------
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
index c2355cafc9..3ff7bfe126 100644
--- a/arch/arm/common/bL_switcher.c
+++ b/arch/arm/common/bL_switcher.c
@@ -54,12 +54,6 @@ static void bL_do_switch(void *_unused)
 {
 	unsigned mpidr, cpuid, clusterid, ob_cluster, ib_cluster;
 
-	/*
-	 * We now have a piece of stack borrowed from the init task's.
-	 * Let's also switch to init_mm right away to match it.
-	 */
-	cpu_switch_mm(init_mm.pgd, &init_mm);
-
 	pr_debug("%s\n", __func__);
 
 	mpidr = read_mpidr();
@@ -94,22 +88,21 @@ static void bL_do_switch(void *_unused)
 }
 
 /*
- * Stack isolation.  To ensure 'current' remains valid, we just borrow
- * a slice of the init/idle task which should be fairly lightly used.
- * The borrowed area starts just above the thread_info structure located
- * at the very bottom of the stack, aligned to a cache line.
+ * Stack isolation.  To ensure 'current' remains valid, we just use another
+ * piece of our thread's stack space which should be fairly lightly used.
+ * The selected area starts just above the thread_info structure located
+ * at the very bottom of the stack, aligned to a cache line, and indexed
+ * with the cluster number.
  */
-#define STACK_SIZE 256
+#define STACK_SIZE 512
 extern void call_with_stack(void (*fn)(void *), void *arg, void *sp);
 static int bL_switchpoint(unsigned long _arg)
 {
 	unsigned int mpidr = read_mpidr();
-	unsigned int cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
 	unsigned int clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
-	unsigned int cpu_index = cpuid + clusterid * MAX_CPUS_PER_CLUSTER;
-	void *stack = &init_thread_info + 1;
+	void *stack = current_thread_info() + 1;
 	stack = PTR_ALIGN(stack, L1_CACHE_BYTES);
-	stack += cpu_index * STACK_SIZE + STACK_SIZE;
+	stack += clusterid * STACK_SIZE + STACK_SIZE;
 	call_with_stack(bL_do_switch, (void *)_arg, stack);
 	BUG();
 }
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Mon Jul 22 23:31:19 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 23:31:19 -0400
Subject: [PATCH 03/13] ARM: b.L: core switcher code
In-Reply-To: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374550289-25305-4-git-send-email-nicolas.pitre@linaro.org>

This is the core code implementing big.LITTLE switcher functionality.
Rational for this code is available here:

http://lwn.net/Articles/481055/

The main entry point for a switch request is:

void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)

If the calling CPU is not the wanted one, this wrapper takes care of
sending the request to the appropriate CPU with schedule_work_on().

At the moment the core switch operation is handled by bL_switch_to()
which must be called on the CPU for which a switch is requested.

What this code does:

  * Return early if the current cluster is the wanted one.

  * Close the gate in the kernel entry vector for both the inbound
    and outbound CPUs.

  * Wake up the inbound CPU so it can perform its reset sequence in
    parallel up to the kernel entry vector gate.

  * Migrate all interrupts in the GIC targeting the outbound CPU
    interface to the inbound CPU interface, including SGIs. This is
    performed by gic_migrate_target() in drivers/irqchip/irq-gic.c.

  * Call cpu_pm_enter() which takes care of flushing the VFP state to
    RAM and save the CPU interface config from the GIC to RAM.

  * Modify the cpu_logical_map to refer to the inbound physical CPU.

  * Call cpu_suspend() which saves the CPU state (general purpose
    registers, page table address) onto the stack and store the
    resulting stack pointer in an array indexed by the updated
    cpu_logical_map, then call the provided shutdown function.
    This happens in arch/arm/kernel/sleep.S.

At this point, the provided shutdown function executed by the outbound
CPU ungates the inbound CPU. Therefore the inbound CPU:

  * Picks up the saved stack pointer in the array indexed by its MPIDR
    in arch/arm/kernel/sleep.S.

  * The MMU and caches are re-enabled using the saved state on the
    provided stack, just like if this was a resume operation from a
    suspended state.

  * Then cpu_suspend() returns, although this is on the inbound CPU
    rather than the outbound CPU which called it initially.

  * The function cpu_pm_exit() is called which effect is to restore the
    CPU interface state in the GIC using the state previously saved by
    the outbound CPU.

  * Exit of bL_switch_to() to resume normal kernel execution on the
    new CPU.

However, the outbound CPU is potentially still running in parallel while
the inbound CPU is resuming normal kernel execution, hence we need
per CPU stack isolation to execute bL_do_switch().  After the outbound
CPU has ungated the inbound CPU, it calls mcpm_cpu_power_down() to:

  * Clean its L1 cache.

  * If it is the last CPU still alive in its cluster (last man standing),
    it also cleans its L2 cache and disables cache snooping from the other
    cluster.

  * Power down the CPU (or whole cluster).

Code called from bL_do_switch() might end up referencing 'current' for
some reasons.  However, 'current' is derived from the stack pointer.
With any arbitrary stack, the returned value for 'current' and any
dereferenced values through it are just random garbage which may lead to
segmentation faults.

The active page table during the execution of bL_do_switch() is also a
problem.  There is no guarantee that the inbound CPU won't destroy the
corresponding task which would free the attached page table while the
outbound CPU is still running and relying on it.

To solve both issues, we borrow some of the task space belonging to
the init/idle task which, by its nature, is lightly used and therefore
is unlikely to clash with our usage.  The init task is also never going
away.

Right now the logical CPU number is assumed to be equivalent to the
physical CPU number within each cluster. The kernel should also be
booted with only one cluster active.  These limitations will be lifted
eventually.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/Kconfig                   |  17 +++
 arch/arm/common/Makefile           |   1 +
 arch/arm/common/bL_switcher.c      | 247 +++++++++++++++++++++++++++++++++++++
 arch/arm/include/asm/bL_switcher.h |  17 +++
 4 files changed, 282 insertions(+)
 create mode 100644 arch/arm/common/bL_switcher.c
 create mode 100644 arch/arm/include/asm/bL_switcher.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e02ec..2c9e5bf734 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1538,6 +1538,23 @@ config MCPM
 	  for (multi-)cluster based systems, such as big.LITTLE based
 	  systems.
 
+config BIG_LITTLE
+	bool "big.LITTLE support (Experimental)"
+	depends on CPU_V7 && SMP
+	select MCPM
+	help
+	  This option enables support for the big.LITTLE architecture.
+
+config BL_SWITCHER
+	bool "big.LITTLE switcher support"
+	depends on BIG_LITTLE && MCPM && HOTPLUG_CPU
+	select CPU_PM
+	select ARM_CPU_SUSPEND
+	help
+	  The big.LITTLE "switcher" provides the core functionality to
+	  transparently handle transition between a cluster of A15's
+	  and a cluster of A7's in a big.LITTLE system.
+
 choice
 	prompt "Memory split"
 	default VMSPLIT_3G
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 8c60f473e9..2586240d5a 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_MCPM)		+= mcpm_head.o mcpm_entry.o mcpm_platsmp.o vlock.o
 AFLAGS_mcpm_head.o		:= -march=armv7-a
 AFLAGS_vlock.o			:= -march=armv7-a
 obj-$(CONFIG_TI_PRIV_EDMA)	+= edma.o
+obj-$(CONFIG_BL_SWITCHER)	+= bL_switcher.o
diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
new file mode 100644
index 0000000000..e63881b430
--- /dev/null
+++ b/arch/arm/common/bL_switcher.c
@@ -0,0 +1,247 @@
+/*
+ * arch/arm/common/bL_switcher.c -- big.LITTLE cluster switcher core driver
+ *
+ * Created by:	Nicolas Pitre, March 2012
+ * Copyright:	(C) 2012-2013  Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/sched.h>
+#include <linux/interrupt.h>
+#include <linux/cpu_pm.h>
+#include <linux/workqueue.h>
+#include <linux/mm.h>
+#include <linux/string.h>
+#include <linux/irqchip/arm-gic.h>
+
+#include <asm/smp_plat.h>
+#include <asm/cacheflush.h>
+#include <asm/suspend.h>
+#include <asm/mcpm.h>
+#include <asm/bL_switcher.h>
+
+
+/*
+ * Use our own MPIDR accessors as the generic ones in asm/cputype.h have
+ * __attribute_const__ and we don't want the compiler to assume any
+ * constness here as the value _does_ change along some code paths.
+ */
+
+static int read_mpidr(void)
+{
+	unsigned int id;
+	asm volatile ("mrc\tp15, 0, %0, c0, c0, 5" : "=r" (id));
+	return id & MPIDR_HWID_BITMASK;
+}
+
+/*
+ * bL switcher core code.
+ */
+
+static void bL_do_switch(void *_unused)
+{
+	unsigned mpidr, cpuid, clusterid, ob_cluster, ib_cluster;
+
+	/*
+	 * We now have a piece of stack borrowed from the init task's.
+	 * Let's also switch to init_mm right away to match it.
+	 */
+	cpu_switch_mm(init_mm.pgd, &init_mm);
+
+	pr_debug("%s\n", __func__);
+
+	mpidr = read_mpidr();
+	cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+	clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+	ob_cluster = clusterid;
+	ib_cluster = clusterid ^ 1;
+
+	/*
+	 * Our state has been saved at this point.  Let's release our
+	 * inbound CPU.
+	 */
+	mcpm_set_entry_vector(cpuid, ib_cluster, cpu_resume);
+	sev();
+
+	/*
+	 * From this point, we must assume that our counterpart CPU might
+	 * have taken over in its parallel world already, as if execution
+	 * just returned from cpu_suspend().  It is therefore important to
+	 * be very careful not to make any change the other guy is not
+	 * expecting.  This is why we need stack isolation.
+	 *
+	 * Fancy under cover tasks could be performed here.  For now
+	 * we have none.
+	 */
+
+	/* Let's put ourself down. */
+	mcpm_cpu_power_down();
+
+	/* should never get here */
+	BUG();
+}
+
+/*
+ * Stack isolation.  To ensure 'current' remains valid, we just borrow
+ * a slice of the init/idle task which should be fairly lightly used.
+ * The borrowed area starts just above the thread_info structure located
+ * at the very bottom of the stack, aligned to a cache line.
+ */
+#define STACK_SIZE 256
+extern void call_with_stack(void (*fn)(void *), void *arg, void *sp);
+static int bL_switchpoint(unsigned long _arg)
+{
+	unsigned int mpidr = read_mpidr();
+	unsigned int cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+	unsigned int clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+	unsigned int cpu_index = cpuid + clusterid * MAX_CPUS_PER_CLUSTER;
+	void *stack = &init_thread_info + 1;
+	stack = PTR_ALIGN(stack, L1_CACHE_BYTES);
+	stack += cpu_index * STACK_SIZE + STACK_SIZE;
+	call_with_stack(bL_do_switch, (void *)_arg, stack);
+	BUG();
+}
+
+/*
+ * Generic switcher interface
+ */
+
+/*
+ * bL_switch_to - Switch to a specific cluster for the current CPU
+ * @new_cluster_id: the ID of the cluster to switch to.
+ *
+ * This function must be called on the CPU to be switched.
+ * Returns 0 on success, else a negative status code.
+ */
+static int bL_switch_to(unsigned int new_cluster_id)
+{
+	unsigned int mpidr, cpuid, clusterid, ob_cluster, ib_cluster, this_cpu;
+	int ret;
+
+	mpidr = read_mpidr();
+	cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+	clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+	ob_cluster = clusterid;
+	ib_cluster = clusterid ^ 1;
+
+	if (new_cluster_id == clusterid)
+		return 0;
+
+	pr_debug("before switch: CPU %d in cluster %d\n", cpuid, clusterid);
+
+	/* Close the gate for our entry vectors */
+	mcpm_set_entry_vector(cpuid, ob_cluster, NULL);
+	mcpm_set_entry_vector(cpuid, ib_cluster, NULL);
+
+	/*
+	 * Let's wake up the inbound CPU now in case it requires some delay
+	 * to come online, but leave it gated in our entry vector code.
+	 */
+	ret = mcpm_cpu_power_up(cpuid, ib_cluster);
+	if (ret) {
+		pr_err("%s: mcpm_cpu_power_up() returned %d\n", __func__, ret);
+		return ret;
+	}
+
+	/*
+	 * From this point we are entering the switch critical zone
+	 * and can't sleep/schedule anymore.
+	 */
+	local_irq_disable();
+	local_fiq_disable();
+
+	this_cpu = smp_processor_id();
+
+	/* redirect GIC's SGIs to our counterpart */
+	gic_migrate_target(cpuid + ib_cluster*4);
+
+	/*
+	 * Raise a SGI on the inbound CPU to make sure it doesn't stall
+	 * in a possible WFI, such as in mcpm_power_down().
+	 */
+	arch_send_wakeup_ipi_mask(cpumask_of(this_cpu));
+
+	ret = cpu_pm_enter();
+
+	/* we can not tolerate errors at this point */
+	if (ret)
+		panic("%s: cpu_pm_enter() returned %d\n", __func__, ret);
+
+	/*
+	 * Flip the cluster in the CPU logical map for this CPU.
+	 * This must be flushed to RAM as the resume code
+	 * needs to access it while the caches are still disabled.
+	 */
+	cpu_logical_map(this_cpu) ^= (1 << 8);
+	sync_cache_w(&cpu_logical_map(this_cpu));
+
+	/* Let's do the actual CPU switch. */
+	ret = cpu_suspend(0, bL_switchpoint);
+	if (ret > 0)
+		panic("%s: cpu_suspend() returned %d\n", __func__, ret);
+
+	/* We are executing on the inbound CPU at this point */
+	mpidr = read_mpidr();
+	cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+	clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+	pr_debug("after switch: CPU %d in cluster %d\n", cpuid, clusterid);
+	BUG_ON(clusterid != ib_cluster);
+
+	mcpm_cpu_powered_up();
+
+	ret = cpu_pm_exit();
+
+	local_fiq_enable();
+	local_irq_enable();
+
+	if (ret)
+		pr_err("%s exiting with error %d\n", __func__, ret);
+	return ret;
+}
+
+struct switch_args {
+	unsigned int cluster;
+	struct work_struct work;
+};
+
+static void __bL_switch_to(struct work_struct *work)
+{
+	struct switch_args *args = container_of(work, struct switch_args, work);
+	bL_switch_to(args->cluster);
+}
+
+/*
+ * bL_switch_request - Switch to a specific cluster for the given CPU
+ *
+ * @cpu: the CPU to switch
+ * @new_cluster_id: the ID of the cluster to switch to.
+ *
+ * This function causes a cluster switch on the given CPU.  If the given
+ * CPU is the same as the calling CPU then the switch happens right away.
+ * Otherwise the request is put on a work queue to be scheduled on the
+ * remote CPU.
+ */
+void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
+{
+	unsigned int this_cpu = get_cpu();
+	struct switch_args args;
+
+	if (cpu == this_cpu) {
+		bL_switch_to(new_cluster_id);
+		put_cpu();
+		return;
+	}
+	put_cpu();
+
+	args.cluster = new_cluster_id;
+	INIT_WORK_ONSTACK(&args.work, __bL_switch_to);
+	schedule_work_on(cpu, &args.work);
+	flush_work(&args.work);
+}
+EXPORT_SYMBOL_GPL(bL_switch_request);
diff --git a/arch/arm/include/asm/bL_switcher.h b/arch/arm/include/asm/bL_switcher.h
new file mode 100644
index 0000000000..72efe3f349
--- /dev/null
+++ b/arch/arm/include/asm/bL_switcher.h
@@ -0,0 +1,17 @@
+/*
+ * arch/arm/include/asm/bL_switcher.h
+ *
+ * Created by:  Nicolas Pitre, April 2012
+ * Copyright:   (C) 2012-2013  Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef ASM_BL_SWITCHER_H
+#define ASM_BL_SWITCHER_H
+
+void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id);
+
+#endif
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Mon Jul 22 23:31:21 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 23:31:21 -0400
Subject: [PATCH 05/13] ARM: bL_switcher: move to dedicated threads rather than
 workqueues
In-Reply-To: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374550289-25305-6-git-send-email-nicolas.pitre@linaro.org>

The workqueues are problematic as they may be contended.
They can't be scheduled with top priority either.  Also the optimization
in bL_switch_request() to skip the workqueue entirely when the target CPU
and the calling CPU were the same didn't allow for bL_switch_request() to
be called from atomic context, as might be the case for some cpufreq
drivers.

Let's move to dedicated kthreads instead.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/common/bL_switcher.c      | 101 ++++++++++++++++++++++++++++---------
 arch/arm/include/asm/bL_switcher.h |   2 +-
 2 files changed, 79 insertions(+), 24 deletions(-)

diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
index d6f7e507d9..c2355cafc9 100644
--- a/arch/arm/common/bL_switcher.c
+++ b/arch/arm/common/bL_switcher.c
@@ -15,8 +15,10 @@
 #include <linux/sched.h>
 #include <linux/interrupt.h>
 #include <linux/cpu_pm.h>
+#include <linux/cpu.h>
 #include <linux/cpumask.h>
-#include <linux/workqueue.h>
+#include <linux/kthread.h>
+#include <linux/wait.h>
 #include <linux/clockchips.h>
 #include <linux/hrtimer.h>
 #include <linux/tick.h>
@@ -225,15 +227,48 @@ static int bL_switch_to(unsigned int new_cluster_id)
 	return ret;
 }
 
-struct switch_args {
-	unsigned int cluster;
-	struct work_struct work;
+struct bL_thread {
+	struct task_struct *task;
+	wait_queue_head_t wq;
+	int wanted_cluster;
 };
 
-static void __bL_switch_to(struct work_struct *work)
+static struct bL_thread bL_threads[MAX_CPUS_PER_CLUSTER];
+
+static int bL_switcher_thread(void *arg)
+{
+	struct bL_thread *t = arg;
+	struct sched_param param = { .sched_priority = 1 };
+	int cluster;
+
+	sched_setscheduler_nocheck(current, SCHED_FIFO, &param);
+
+	do {
+		if (signal_pending(current))
+			flush_signals(current);
+		wait_event_interruptible(t->wq,
+				t->wanted_cluster != -1 ||
+				kthread_should_stop());
+		cluster = xchg(&t->wanted_cluster, -1);
+		if (cluster != -1)
+			bL_switch_to(cluster);
+	} while (!kthread_should_stop());
+
+	return 0;
+}
+
+static struct task_struct * __init bL_switcher_thread_create(int cpu, void *arg)
 {
-	struct switch_args *args = container_of(work, struct switch_args, work);
-	bL_switch_to(args->cluster);
+	struct task_struct *task;
+
+	task = kthread_create_on_node(bL_switcher_thread, arg,
+				      cpu_to_node(cpu), "kswitcher_%d", cpu);
+	if (!IS_ERR(task)) {
+		kthread_bind(task, cpu);
+		wake_up_process(task);
+	} else
+		pr_err("%s failed for CPU %d\n", __func__, cpu);
+	return task;
 }
 
 /*
@@ -242,26 +277,46 @@ static void __bL_switch_to(struct work_struct *work)
  * @cpu: the CPU to switch
  * @new_cluster_id: the ID of the cluster to switch to.
  *
- * This function causes a cluster switch on the given CPU.  If the given
- * CPU is the same as the calling CPU then the switch happens right away.
- * Otherwise the request is put on a work queue to be scheduled on the
- * remote CPU.
+ * This function causes a cluster switch on the given CPU by waking up
+ * the appropriate switcher thread.  This function may or may not return
+ * before the switch has occurred.
  */
-void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
+int bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
 {
-	unsigned int this_cpu = get_cpu();
-	struct switch_args args;
+	struct bL_thread *t;
 
-	if (cpu == this_cpu) {
-		bL_switch_to(new_cluster_id);
-		put_cpu();
-		return;
+	if (cpu >= MAX_CPUS_PER_CLUSTER) {
+		pr_err("%s: cpu %d out of bounds\n", __func__, cpu);
+		return -EINVAL;
 	}
-	put_cpu();
 
-	args.cluster = new_cluster_id;
-	INIT_WORK_ONSTACK(&args.work, __bL_switch_to);
-	schedule_work_on(cpu, &args.work);
-	flush_work(&args.work);
+	t = &bL_threads[cpu];
+	if (IS_ERR(t->task))
+		return PTR_ERR(t->task);
+	if (!t->task)
+		return -ESRCH;
+
+	t->wanted_cluster = new_cluster_id;
+	wake_up(&t->wq);
+	return 0;
 }
 EXPORT_SYMBOL_GPL(bL_switch_request);
+
+static int __init bL_switcher_init(void)
+{
+	int cpu;
+
+	pr_info("big.LITTLE switcher initializing\n");
+
+	for_each_online_cpu(cpu) {
+		struct bL_thread *t = &bL_threads[cpu];
+		init_waitqueue_head(&t->wq);
+		t->wanted_cluster = -1;
+		t->task = bL_switcher_thread_create(cpu, t);
+	}
+
+	pr_info("big.LITTLE switcher initialized\n");
+	return 0;
+}
+
+late_initcall(bL_switcher_init);
diff --git a/arch/arm/include/asm/bL_switcher.h b/arch/arm/include/asm/bL_switcher.h
index 72efe3f349..e0c0bba70b 100644
--- a/arch/arm/include/asm/bL_switcher.h
+++ b/arch/arm/include/asm/bL_switcher.h
@@ -12,6 +12,6 @@
 #ifndef ASM_BL_SWITCHER_H
 #define ASM_BL_SWITCHER_H
 
-void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id);
+int bL_switch_request(unsigned int cpu, unsigned int new_cluster_id);
 
 #endif
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Mon Jul 22 23:31:23 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 23:31:23 -0400
Subject: [PATCH 07/13] ARM: bL_switcher: hot-unplug half of the available CPUs
In-Reply-To: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374550289-25305-8-git-send-email-nicolas.pitre@linaro.org>

In a regular kernel configuration, all the CPUs are initially available.
But the switcher execution model uses half of them at any time.  Instead
of hacking the DTB to remove half of the CPUs, let's remove them at
run time and make sure we still have a working switcher configuration.
This way, the same DTB can be used whether or not the switcher is used.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/common/bL_switcher.c | 78 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 77 insertions(+), 1 deletion(-)

diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
index 3ff7bfe126..4273be76ba 100644
--- a/arch/arm/common/bL_switcher.c
+++ b/arch/arm/common/bL_switcher.c
@@ -295,18 +295,94 @@ int bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
 }
 EXPORT_SYMBOL_GPL(bL_switch_request);
 
+/*
+ * Activation and configuration code.
+ */
+
+static cpumask_t bL_switcher_removed_logical_cpus;
+
+static void __init bL_switcher_restore_cpus(void)
+{
+	int i;
+
+	for_each_cpu(i, &bL_switcher_removed_logical_cpus)
+		cpu_up(i);
+}
+
+static int __init bL_switcher_halve_cpus(void)
+{
+	int cpu, cluster, i, ret;
+	cpumask_t cluster_mask[2], common_mask;
+
+	cpumask_clear(&bL_switcher_removed_logical_cpus);
+	cpumask_clear(&cluster_mask[0]);
+	cpumask_clear(&cluster_mask[1]);
+
+	for_each_online_cpu(i) {
+		cpu = cpu_logical_map(i) & 0xff;
+		cluster = (cpu_logical_map(i) >> 8) & 0xff;
+		if (cluster >= 2) {
+			pr_err("%s: only dual cluster systems are supported\n", __func__);
+			return -EINVAL;
+		}
+		cpumask_set_cpu(cpu, &cluster_mask[cluster]);
+	}
+
+	if (!cpumask_and(&common_mask, &cluster_mask[0], &cluster_mask[1])) {
+		pr_err("%s: no common set of CPUs\n", __func__);
+		return -EINVAL;
+	}
+
+	for_each_online_cpu(i) {
+		cpu = cpu_logical_map(i) & 0xff;
+		cluster = (cpu_logical_map(i) >> 8) & 0xff;
+
+		if (cpumask_test_cpu(cpu, &common_mask)) {
+			/*
+			 * We keep only those logical CPUs which number
+			 * is equal to their physical CPU number. This is
+			 * not perfect but good enough for now.
+			 */
+			if (cpu == i)
+				continue;
+		}
+
+		ret = cpu_down(i);
+		if (ret) {
+			bL_switcher_restore_cpus();
+			return ret;
+		}
+		cpumask_set_cpu(i, &bL_switcher_removed_logical_cpus);
+	}
+
+	return 0;
+}
+
 static int __init bL_switcher_init(void)
 {
-	int cpu;
+	int cpu, ret;
 
 	pr_info("big.LITTLE switcher initializing\n");
 
+	if (MAX_NR_CLUSTERS != 2) {
+		pr_err("%s: only dual cluster systems are supported\n", __func__);
+		return -EINVAL;
+	}
+
+	cpu_hotplug_driver_lock();
+	ret = bL_switcher_halve_cpus();
+	if (ret) {
+		cpu_hotplug_driver_unlock();
+		return ret;
+	}
+
 	for_each_online_cpu(cpu) {
 		struct bL_thread *t = &bL_threads[cpu];
 		init_waitqueue_head(&t->wq);
 		t->wanted_cluster = -1;
 		t->task = bL_switcher_thread_create(cpu, t);
 	}
+	cpu_hotplug_driver_unlock();
 
 	pr_info("big.LITTLE switcher initialized\n");
 	return 0;
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Mon Jul 22 23:31:24 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 23:31:24 -0400
Subject: [PATCH 08/13] ARM: bL_switcher: do not hardcode GIC IDs in the code
In-Reply-To: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374550289-25305-9-git-send-email-nicolas.pitre@linaro.org>

Currently, GIC IDs are hardcoded making the code dependent on the 4+4 b.L
configuration.  Let's allow for GIC IDs to be discovered upon switcher
initialization to support other b.L configurations such as the 1+1 one,
or 2+3 as on the VExpress TC2.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/common/bL_switcher.c   | 14 +++++++++++++-
 drivers/irqchip/irq-gic.c       | 21 +++++++++++++++++++++
 include/linux/irqchip/arm-gic.h |  1 +
 3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
index 4273be76ba..34eff3bc25 100644
--- a/arch/arm/common/bL_switcher.c
+++ b/arch/arm/common/bL_switcher.c
@@ -111,6 +111,8 @@ static int bL_switchpoint(unsigned long _arg)
  * Generic switcher interface
  */
 
+static unsigned int bL_gic_id[MAX_CPUS_PER_CLUSTER][MAX_NR_CLUSTERS];
+
 /*
  * bL_switch_to - Switch to a specific cluster for the current CPU
  * @new_cluster_id: the ID of the cluster to switch to.
@@ -160,7 +162,7 @@ static int bL_switch_to(unsigned int new_cluster_id)
 	this_cpu = smp_processor_id();
 
 	/* redirect GIC's SGIs to our counterpart */
-	gic_migrate_target(cpuid + ib_cluster*4);
+	gic_migrate_target(bL_gic_id[cpuid][ib_cluster]);
 
 	/*
 	 * Raise a SGI on the inbound CPU to make sure it doesn't stall
@@ -338,6 +340,16 @@ static int __init bL_switcher_halve_cpus(void)
 		cluster = (cpu_logical_map(i) >> 8) & 0xff;
 
 		if (cpumask_test_cpu(cpu, &common_mask)) {
+			/* Let's take note of the GIC ID for this CPU */
+			int gic_id = gic_get_cpu_id(i);
+			if (gic_id < 0) {
+				pr_err("%s: bad GIC ID for CPU %d\n", __func__, i);
+				return -EINVAL;
+			}
+			bL_gic_id[cpu][cluster] = gic_id;
+			pr_info("GIC ID for CPU %u cluster %u is %u\n",
+				cpu, cluster, gic_id);
+
 			/*
 			 * We keep only those logical CPUs which number
 			 * is equal to their physical CPU number. This is
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 6bd5a8c1aa..0b6b8bf5df 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -668,6 +668,27 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
 
 #ifdef CONFIG_BL_SWITCHER
 /*
+ * gic_get_cpu_id - get the CPU interface ID for the specified CPU
+ *
+ * @cpu: the logical CPU number to get the GIC ID for.
+ *
+ * Return the CPU interface ID for the given logical CPU number,
+ * or -1 if the CPU number is too large or the interface ID is
+ * unknown (more than one bit set).
+ */
+int gic_get_cpu_id(unsigned int cpu)
+{
+	unsigned int cpu_bit;
+
+	if (cpu >= NR_GIC_CPU_IF)
+		return -1;
+	cpu_bit = gic_cpu_map[cpu];
+	if (cpu_bit & (cpu_bit - 1))
+		return -1;
+	return __ffs(cpu_bit);
+}
+
+/*
  * gic_migrate_target - migrate IRQs to another PU interface
  *
  * @new_cpu_id: the CPU target ID to migrate IRQs to
diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 40bfcac959..2d7d47e8df 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -75,6 +75,7 @@ static inline void gic_init(unsigned int nr, int start,
 	gic_init_bases(nr, start, dist, cpu, 0, NULL);
 }
 
+int gic_get_cpu_id(unsigned int cpu);
 void gic_migrate_target(unsigned int new_cpu_id);
 
 #endif /* __ASSEMBLY */
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Mon Jul 22 23:31:26 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 23:31:26 -0400
Subject: [PATCH 10/13] ARM: bL_switcher: add kernel cmdline param to disable
 the switcher on boot
In-Reply-To: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374550289-25305-11-git-send-email-nicolas.pitre@linaro.org>

By adding no_bL_switcher to the kernel cmdline string, the switcher
won't be activated automatically at boot time.  It is still possible
to activate it later with:

	echo 1 > /sys/kernel/bL_switcher/active

Signed-off-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/common/bL_switcher.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
index abeeff5520..704c4b4ef3 100644
--- a/arch/arm/common/bL_switcher.c
+++ b/arch/arm/common/bL_switcher.c
@@ -26,6 +26,7 @@
 #include <linux/string.h>
 #include <linux/sysfs.h>
 #include <linux/irqchip/arm-gic.h>
+#include <linux/moduleparam.h>
 
 #include <asm/smp_plat.h>
 #include <asm/cacheflush.h>
@@ -527,6 +528,9 @@ static int __init bL_switcher_sysfs_init(void)
 
 #endif  /* CONFIG_SYSFS */
 
+static bool no_bL_switcher;
+core_param(no_bL_switcher, no_bL_switcher, bool, 0644);
+
 static int __init bL_switcher_init(void)
 {
 	int ret;
@@ -536,9 +540,11 @@ static int __init bL_switcher_init(void)
 		return -EINVAL;
 	}
 
-	ret = bL_switcher_enable();
-	if (ret)
-		return ret;
+	if (!no_bL_switcher) {
+		ret = bL_switcher_enable();
+		if (ret)
+			return ret;
+	}
 
 #ifdef CONFIG_SYSFS
 	ret = bL_switcher_sysfs_init();
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Mon Jul 22 23:31:25 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 23:31:25 -0400
Subject: [PATCH 09/13] ARM: bL_switcher: ability to enable and disable the
 switcher via sysfs
In-Reply-To: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374550289-25305-10-git-send-email-nicolas.pitre@linaro.org>

The /sys/kernel/bL_switcher/enable file allows to enable or disable
the switcher by writing 1 or 0 to it respectively.  It is still enabled
by default on boot.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/common/bL_switcher.c | 171 +++++++++++++++++++++++++++++++++++++++---
 1 file changed, 160 insertions(+), 11 deletions(-)

diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
index 34eff3bc25..abeeff5520 100644
--- a/arch/arm/common/bL_switcher.c
+++ b/arch/arm/common/bL_switcher.c
@@ -24,6 +24,7 @@
 #include <linux/tick.h>
 #include <linux/mm.h>
 #include <linux/string.h>
+#include <linux/sysfs.h>
 #include <linux/irqchip/arm-gic.h>
 
 #include <asm/smp_plat.h>
@@ -226,6 +227,7 @@ struct bL_thread {
 	struct task_struct *task;
 	wait_queue_head_t wq;
 	int wanted_cluster;
+	struct completion started;
 };
 
 static struct bL_thread bL_threads[MAX_CPUS_PER_CLUSTER];
@@ -237,6 +239,7 @@ static int bL_switcher_thread(void *arg)
 	int cluster;
 
 	sched_setscheduler_nocheck(current, SCHED_FIFO, &param);
+	complete(&t->started);
 
 	do {
 		if (signal_pending(current))
@@ -252,7 +255,7 @@ static int bL_switcher_thread(void *arg)
 	return 0;
 }
 
-static struct task_struct * __init bL_switcher_thread_create(int cpu, void *arg)
+static struct task_struct *bL_switcher_thread_create(int cpu, void *arg)
 {
 	struct task_struct *task;
 
@@ -301,9 +304,11 @@ EXPORT_SYMBOL_GPL(bL_switch_request);
  * Activation and configuration code.
  */
 
+static unsigned int bL_switcher_active;
+static unsigned int bL_switcher_cpu_original_cluster[MAX_CPUS_PER_CLUSTER];
 static cpumask_t bL_switcher_removed_logical_cpus;
 
-static void __init bL_switcher_restore_cpus(void)
+static void bL_switcher_restore_cpus(void)
 {
 	int i;
 
@@ -311,7 +316,7 @@ static void __init bL_switcher_restore_cpus(void)
 		cpu_up(i);
 }
 
-static int __init bL_switcher_halve_cpus(void)
+static int bL_switcher_halve_cpus(void)
 {
 	int cpu, cluster, i, ret;
 	cpumask_t cluster_mask[2], common_mask;
@@ -355,8 +360,10 @@ static int __init bL_switcher_halve_cpus(void)
 			 * is equal to their physical CPU number. This is
 			 * not perfect but good enough for now.
 			 */
-			if (cpu == i)
+			if (cpu == i) {
+				bL_switcher_cpu_original_cluster[cpu] = cluster;
 				continue;
+			}
 		}
 
 		ret = cpu_down(i);
@@ -370,18 +377,18 @@ static int __init bL_switcher_halve_cpus(void)
 	return 0;
 }
 
-static int __init bL_switcher_init(void)
+static int bL_switcher_enable(void)
 {
 	int cpu, ret;
 
-	pr_info("big.LITTLE switcher initializing\n");
-
-	if (MAX_NR_CLUSTERS != 2) {
-		pr_err("%s: only dual cluster systems are supported\n", __func__);
-		return -EINVAL;
+	cpu_hotplug_driver_lock();
+	if (bL_switcher_active) {
+		cpu_hotplug_driver_unlock();
+		return 0;
 	}
 
-	cpu_hotplug_driver_lock();
+	pr_info("big.LITTLE switcher initializing\n");
+
 	ret = bL_switcher_halve_cpus();
 	if (ret) {
 		cpu_hotplug_driver_unlock();
@@ -391,13 +398,155 @@ static int __init bL_switcher_init(void)
 	for_each_online_cpu(cpu) {
 		struct bL_thread *t = &bL_threads[cpu];
 		init_waitqueue_head(&t->wq);
+		init_completion(&t->started);
 		t->wanted_cluster = -1;
 		t->task = bL_switcher_thread_create(cpu, t);
 	}
+
+	bL_switcher_active = 1;
 	cpu_hotplug_driver_unlock();
 
 	pr_info("big.LITTLE switcher initialized\n");
 	return 0;
 }
 
+#ifdef CONFIG_SYSFS
+
+static void bL_switcher_disable(void)
+{
+	unsigned int cpu, cluster, i;
+	struct bL_thread *t;
+	struct task_struct *task;
+
+	cpu_hotplug_driver_lock();
+	if (!bL_switcher_active) {
+		cpu_hotplug_driver_unlock();
+		return;
+	}
+	bL_switcher_active = 0;
+
+	/*
+	 * To deactivate the switcher, we must shut down the switcher
+	 * threads to prevent any other requests from being accepted.
+	 * Then, if the final cluster for given logical CPU is not the
+	 * same as the original one, we'll recreate a switcher thread
+	 * just for the purpose of switching the CPU back without any
+	 * possibility for interference from external requests.
+	 */
+	for_each_online_cpu(cpu) {
+		BUG_ON(cpu != (cpu_logical_map(cpu) & 0xff));
+		t = &bL_threads[cpu];
+		task = t->task;
+		t->task = NULL;
+		if (!task || IS_ERR(task))
+			continue;
+		kthread_stop(task);
+		/* no more switch may happen on this CPU at this point */
+		cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(cpu), 1);
+		if (cluster == bL_switcher_cpu_original_cluster[cpu])
+			continue;
+		init_completion(&t->started);
+		t->wanted_cluster = bL_switcher_cpu_original_cluster[cpu];
+		task = bL_switcher_thread_create(cpu, t);
+		if (!IS_ERR(task)) {
+			wait_for_completion(&t->started);
+			kthread_stop(task);
+			cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(cpu), 1);
+			if (cluster == bL_switcher_cpu_original_cluster[cpu])
+				continue;
+		}
+		/* If execution gets here, we're in trouble. */
+		pr_crit("%s: unable to restore original cluster for CPU %d\n",
+			__func__, cpu);
+		for_each_cpu(i, &bL_switcher_removed_logical_cpus) {
+			if ((cpu_logical_map(i) & 0xff) != cpu)
+				continue;
+			pr_crit("%s: CPU %d can't be restored\n",
+				__func__, i);
+			cpumask_clear_cpu(i, &bL_switcher_removed_logical_cpus);
+			break;
+		}
+	}
+
+	bL_switcher_restore_cpus();
+	cpu_hotplug_driver_unlock();
+}
+
+static ssize_t bL_switcher_active_show(struct kobject *kobj,
+		struct kobj_attribute *attr, char *buf)
+{
+	return sprintf(buf, "%u\n", bL_switcher_active);
+}
+
+static ssize_t bL_switcher_active_store(struct kobject *kobj,
+		struct kobj_attribute *attr, const char *buf, size_t count)
+{
+	int ret;
+
+	switch (buf[0]) {
+	case '0':
+		bL_switcher_disable();
+		ret = 0;
+		break;
+	case '1':
+		ret = bL_switcher_enable();
+		break;
+	default:
+		ret = -EINVAL;
+	}
+
+	return (ret >= 0) ? count : ret;
+}
+
+static struct kobj_attribute bL_switcher_active_attr =
+	__ATTR(active, 0644, bL_switcher_active_show, bL_switcher_active_store);
+
+static struct attribute *bL_switcher_attrs[] = {
+	&bL_switcher_active_attr.attr,
+	NULL,
+};
+
+static struct attribute_group bL_switcher_attr_group = {
+	.attrs = bL_switcher_attrs,
+};
+
+static struct kobject *bL_switcher_kobj;
+
+static int __init bL_switcher_sysfs_init(void)
+{
+	int ret;
+
+	bL_switcher_kobj = kobject_create_and_add("bL_switcher", kernel_kobj);
+	if (!bL_switcher_kobj)
+		return -ENOMEM;
+	ret = sysfs_create_group(bL_switcher_kobj, &bL_switcher_attr_group);
+	if (ret)
+		kobject_put(bL_switcher_kobj);
+	return ret;
+}
+
+#endif  /* CONFIG_SYSFS */
+
+static int __init bL_switcher_init(void)
+{
+	int ret;
+
+	if (MAX_NR_CLUSTERS != 2) {
+		pr_err("%s: only dual cluster systems are supported\n", __func__);
+		return -EINVAL;
+	}
+
+	ret = bL_switcher_enable();
+	if (ret)
+		return ret;
+
+#ifdef CONFIG_SYSFS
+	ret = bL_switcher_sysfs_init();
+	if (ret)
+		pr_err("%s: unable to create sysfs entry\n", __func__);
+#endif
+
+	return 0;
+}
+
 late_initcall(bL_switcher_init);
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Mon Jul 22 23:31:27 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 23:31:27 -0400
Subject: [PATCH 11/13] ARM: bL_switcher: veto CPU hotplug requests when the
 switcher is active
In-Reply-To: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374550289-25305-12-git-send-email-nicolas.pitre@linaro.org>

Trying to support both the switcher and CPU hotplug at the same time
is quickly becoming very complex due to ambiguous semantics.  So let's
simply veto any hotplug requests when the switcher is active for now.

This restriction might be loosened eventually.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/common/bL_switcher.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
index 704c4b4ef3..2fe3911601 100644
--- a/arch/arm/common/bL_switcher.c
+++ b/arch/arm/common/bL_switcher.c
@@ -528,6 +528,25 @@ static int __init bL_switcher_sysfs_init(void)
 
 #endif  /* CONFIG_SYSFS */
 
+/*
+ * Veto any CPU hotplug operation while the switcher is active.
+ * We're just not ready to deal with that given the trickery involved.
+ */
+static int bL_switcher_hotplug_callback(struct notifier_block *nfb,
+					unsigned long action, void *hcpu)
+{
+	switch (action) {
+	case CPU_UP_PREPARE:
+	case CPU_DOWN_PREPARE:
+		if (bL_switcher_active)
+			return NOTIFY_BAD;
+	}
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block bL_switcher_hotplug_notifier =
+	{ &bL_switcher_hotplug_callback, NULL, 0 };
+
 static bool no_bL_switcher;
 core_param(no_bL_switcher, no_bL_switcher, bool, 0644);
 
@@ -540,6 +559,8 @@ static int __init bL_switcher_init(void)
 		return -EINVAL;
 	}
 
+	register_cpu_notifier(&bL_switcher_hotplug_notifier);
+
 	if (!no_bL_switcher) {
 		ret = bL_switcher_enable();
 		if (ret)
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Mon Jul 22 23:31:29 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 23:31:29 -0400
Subject: [PATCH 13/13] ARM: bL_switcher: add a simple /dev user interface for
 debugging purposes
In-Reply-To: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374550289-25305-14-git-send-email-nicolas.pitre@linaro.org>

Only the basic call to aid debugging.

*** NOT FOR PRODUCTION ***

Usage:

	echo <cpuid>,<clusterid> > /dev/b.L_switcher

where <cpuid> is the logical CPU number, and <clusterid> is 0 for the
first cluster and 1 for the second cluster.

Signed-off-by: nicolas Pitre <nico at linaro.org>
---
 arch/arm/Kconfig                       |  8 ++++
 arch/arm/common/Makefile               |  1 +
 arch/arm/common/bL_switcher_dummy_if.c | 71 ++++++++++++++++++++++++++++++++++
 3 files changed, 80 insertions(+)
 create mode 100644 arch/arm/common/bL_switcher_dummy_if.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c9e5bf734..ccc5b39594 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1555,6 +1555,14 @@ config BL_SWITCHER
 	  transparently handle transition between a cluster of A15's
 	  and a cluster of A7's in a big.LITTLE system.
 
+config BL_SWITCHER_DUMMY_IF
+	tristate "Simple big.LITTLE switcher user interface"
+	depends on BL_SWITCHER && DEBUG_KERNEL
+	help
+	  This is a simple and dummy char dev interface to control
+	  the big.LITTLE switcher core code.  It is meant for
+	  debugging purposes only.
+
 choice
 	prompt "Memory split"
 	default VMSPLIT_3G
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 2586240d5a..5c8584c494 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -18,3 +18,4 @@ AFLAGS_mcpm_head.o		:= -march=armv7-a
 AFLAGS_vlock.o			:= -march=armv7-a
 obj-$(CONFIG_TI_PRIV_EDMA)	+= edma.o
 obj-$(CONFIG_BL_SWITCHER)	+= bL_switcher.o
+obj-$(CONFIG_BL_SWITCHER_DUMMY_IF) += bL_switcher_dummy_if.o
diff --git a/arch/arm/common/bL_switcher_dummy_if.c b/arch/arm/common/bL_switcher_dummy_if.c
new file mode 100644
index 0000000000..3f47f1203c
--- /dev/null
+++ b/arch/arm/common/bL_switcher_dummy_if.c
@@ -0,0 +1,71 @@
+/*
+ * arch/arm/common/bL_switcher_dummy_if.c -- b.L switcher dummy interface
+ *
+ * Created by:	Nicolas Pitre, November 2012
+ * Copyright:	(C) 2012-2013  Linaro Limited
+ *
+ * Dummy interface to user space for debugging purpose only.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/miscdevice.h>
+#include <asm/uaccess.h>
+#include <asm/bL_switcher.h>
+
+static ssize_t bL_switcher_write(struct file *file, const char __user *buf,
+			size_t len, loff_t *pos)
+{
+	unsigned char val[3];
+	unsigned int cpu, cluster;
+	int ret;
+
+	pr_debug("%s\n", __func__);
+
+	if (len < 3)
+		return -EINVAL;
+
+	if (copy_from_user(val, buf, 3))
+		return -EFAULT;
+
+	/* format: <cpu#>,<cluster#> */
+	if (val[0] < '0' || val[0] > '9' ||
+	    val[1] != ',' ||
+	    val[2] < '0' || val[2] > '1')
+		return -EINVAL;
+
+	cpu = val[0] - '0';
+	cluster = val[2] - '0';
+	ret = bL_switch_request(cpu, cluster);
+
+	return ret ? : len;
+}
+
+static const struct file_operations bL_switcher_fops = {
+	.write		= bL_switcher_write,
+	.owner	= THIS_MODULE,
+};
+
+static struct miscdevice bL_switcher_device = {
+	MISC_DYNAMIC_MINOR,
+	"b.L_switcher",
+	&bL_switcher_fops
+};
+
+static int __init bL_switcher_dummy_if_init(void)
+{
+	return misc_register(&bL_switcher_device);
+}
+
+static void __exit bL_switcher_dummy_if_exit(void)
+{
+	misc_deregister(&bL_switcher_device);
+}
+
+module_init(bL_switcher_dummy_if_init);
+module_exit(bL_switcher_dummy_if_exit);
-- 
1.8.1.2



From nicolas.pitre at linaro.org  Mon Jul 22 23:31:28 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 22 Jul 2013 23:31:28 -0400
Subject: [PATCH 12/13] ARM: bL_switcher: remove assumptions between logical and
 physical CPUs
In-Reply-To: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <1374550289-25305-13-git-send-email-nicolas.pitre@linaro.org>

Up to now, the logical CPU was somehow tied to the physical CPU number
within a cluster.  This causes problems when forcing the boot CPU to be
different from the first enumerated CPU in the device tree creating a
discrepancy between logical and physical CPU numbers.

Let's make the pairing completely independent from physical CPU numbers.

Let's keep only those logical CPUs with same initial CPU cluster to create
a uniform scheduler profile without having to modify any of the probed
topology and compute capacity data.  This has the potential to create
a non contiguous CPU numbering space when the switcher is active with
potential impact on buggy user space tools.  It is however better to fix
those tools rather than making the switcher code more intrusive.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/common/bL_switcher.c | 180 +++++++++++++++++++++++++-----------------
 1 file changed, 106 insertions(+), 74 deletions(-)

diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
index 2fe3911601..7bf2396cb0 100644
--- a/arch/arm/common/bL_switcher.c
+++ b/arch/arm/common/bL_switcher.c
@@ -54,21 +54,19 @@ static int read_mpidr(void)
 
 static void bL_do_switch(void *_unused)
 {
-	unsigned mpidr, cpuid, clusterid, ob_cluster, ib_cluster;
+	unsigned ib_mpidr, ib_cpu, ib_cluster;
 
 	pr_debug("%s\n", __func__);
 
-	mpidr = read_mpidr();
-	cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
-	clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
-	ob_cluster = clusterid;
-	ib_cluster = clusterid ^ 1;
+	ib_mpidr = cpu_logical_map(smp_processor_id());
+	ib_cpu = MPIDR_AFFINITY_LEVEL(ib_mpidr, 0);
+	ib_cluster = MPIDR_AFFINITY_LEVEL(ib_mpidr, 1);
 
 	/*
 	 * Our state has been saved at this point.  Let's release our
 	 * inbound CPU.
 	 */
-	mcpm_set_entry_vector(cpuid, ib_cluster, cpu_resume);
+	mcpm_set_entry_vector(ib_cpu, ib_cluster, cpu_resume);
 	sev();
 
 	/*
@@ -114,6 +112,7 @@ static int bL_switchpoint(unsigned long _arg)
  */
 
 static unsigned int bL_gic_id[MAX_CPUS_PER_CLUSTER][MAX_NR_CLUSTERS];
+static int bL_switcher_cpu_pairing[NR_CPUS];
 
 /*
  * bL_switch_to - Switch to a specific cluster for the current CPU
@@ -124,31 +123,38 @@ static unsigned int bL_gic_id[MAX_CPUS_PER_CLUSTER][MAX_NR_CLUSTERS];
  */
 static int bL_switch_to(unsigned int new_cluster_id)
 {
-	unsigned int mpidr, cpuid, clusterid, ob_cluster, ib_cluster, this_cpu;
+	unsigned int mpidr, this_cpu, that_cpu;
+	unsigned int ob_mpidr, ob_cpu, ob_cluster, ib_mpidr, ib_cpu, ib_cluster;
 	struct tick_device *tdev;
 	enum clock_event_mode tdev_mode;
 	int ret;
 
-	mpidr = read_mpidr();
-	cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
-	clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
-	ob_cluster = clusterid;
-	ib_cluster = clusterid ^ 1;
+	this_cpu = smp_processor_id();
+	ob_mpidr = read_mpidr();
+	ob_cpu = MPIDR_AFFINITY_LEVEL(ob_mpidr, 0);
+	ob_cluster = MPIDR_AFFINITY_LEVEL(ob_mpidr, 1);
+	BUG_ON(cpu_logical_map(this_cpu) != ob_mpidr);
 
-	if (new_cluster_id == clusterid)
+	if (new_cluster_id == ob_cluster)
 		return 0;
 
-	pr_debug("before switch: CPU %d in cluster %d\n", cpuid, clusterid);
+	that_cpu = bL_switcher_cpu_pairing[this_cpu];
+	ib_mpidr = cpu_logical_map(that_cpu);
+	ib_cpu = MPIDR_AFFINITY_LEVEL(ib_mpidr, 0);
+	ib_cluster = MPIDR_AFFINITY_LEVEL(ib_mpidr, 1);
+
+	pr_debug("before switch: CPU %d MPIDR %#x -> %#x\n",
+		 this_cpu, ob_mpidr, ib_mpidr);
 
 	/* Close the gate for our entry vectors */
-	mcpm_set_entry_vector(cpuid, ob_cluster, NULL);
-	mcpm_set_entry_vector(cpuid, ib_cluster, NULL);
+	mcpm_set_entry_vector(ob_cpu, ob_cluster, NULL);
+	mcpm_set_entry_vector(ib_cpu, ib_cluster, NULL);
 
 	/*
 	 * Let's wake up the inbound CPU now in case it requires some delay
 	 * to come online, but leave it gated in our entry vector code.
 	 */
-	ret = mcpm_cpu_power_up(cpuid, ib_cluster);
+	ret = mcpm_cpu_power_up(ib_cpu, ib_cluster);
 	if (ret) {
 		pr_err("%s: mcpm_cpu_power_up() returned %d\n", __func__, ret);
 		return ret;
@@ -161,10 +167,8 @@ static int bL_switch_to(unsigned int new_cluster_id)
 	local_irq_disable();
 	local_fiq_disable();
 
-	this_cpu = smp_processor_id();
-
 	/* redirect GIC's SGIs to our counterpart */
-	gic_migrate_target(bL_gic_id[cpuid][ib_cluster]);
+	gic_migrate_target(bL_gic_id[ib_cpu][ib_cluster]);
 
 	/*
 	 * Raise a SGI on the inbound CPU to make sure it doesn't stall
@@ -187,11 +191,12 @@ static int bL_switch_to(unsigned int new_cluster_id)
 		panic("%s: cpu_pm_enter() returned %d\n", __func__, ret);
 
 	/*
-	 * Flip the cluster in the CPU logical map for this CPU.
+	 * Swap the physical CPUs in the logical map for this logical CPU.
 	 * This must be flushed to RAM as the resume code
 	 * needs to access it while the caches are still disabled.
 	 */
-	cpu_logical_map(this_cpu) ^= (1 << 8);
+	cpu_logical_map(this_cpu) = ib_mpidr;
+	cpu_logical_map(that_cpu) = ob_mpidr;
 	sync_cache_w(&cpu_logical_map(this_cpu));
 
 	/* Let's do the actual CPU switch. */
@@ -201,10 +206,8 @@ static int bL_switch_to(unsigned int new_cluster_id)
 
 	/* We are executing on the inbound CPU at this point */
 	mpidr = read_mpidr();
-	cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
-	clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
-	pr_debug("after switch: CPU %d in cluster %d\n", cpuid, clusterid);
-	BUG_ON(clusterid != ib_cluster);
+	pr_debug("after switch: CPU %d MPIDR %#x\n", this_cpu, mpidr);
+	BUG_ON(mpidr != ib_mpidr);
 
 	mcpm_cpu_powered_up();
 
@@ -231,7 +234,7 @@ struct bL_thread {
 	struct completion started;
 };
 
-static struct bL_thread bL_threads[MAX_CPUS_PER_CLUSTER];
+static struct bL_thread bL_threads[NR_CPUS];
 
 static int bL_switcher_thread(void *arg)
 {
@@ -284,7 +287,7 @@ int bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
 {
 	struct bL_thread *t;
 
-	if (cpu >= MAX_CPUS_PER_CLUSTER) {
+	if (cpu >= ARRAY_SIZE(bL_threads)) {
 		pr_err("%s: cpu %d out of bounds\n", __func__, cpu);
 		return -EINVAL;
 	}
@@ -306,7 +309,7 @@ EXPORT_SYMBOL_GPL(bL_switch_request);
  */
 
 static unsigned int bL_switcher_active;
-static unsigned int bL_switcher_cpu_original_cluster[MAX_CPUS_PER_CLUSTER];
+static unsigned int bL_switcher_cpu_original_cluster[NR_CPUS];
 static cpumask_t bL_switcher_removed_logical_cpus;
 
 static void bL_switcher_restore_cpus(void)
@@ -319,52 +322,86 @@ static void bL_switcher_restore_cpus(void)
 
 static int bL_switcher_halve_cpus(void)
 {
-	int cpu, cluster, i, ret;
-	cpumask_t cluster_mask[2], common_mask;
-
-	cpumask_clear(&bL_switcher_removed_logical_cpus);
-	cpumask_clear(&cluster_mask[0]);
-	cpumask_clear(&cluster_mask[1]);
+	int i, j, cluster_0, gic_id, ret;
+	unsigned int cpu, cluster, mask;
+	cpumask_t available_cpus;
 
+	/* First pass to validate what we have */
+	mask = 0;
 	for_each_online_cpu(i) {
-		cpu = cpu_logical_map(i) & 0xff;
-		cluster = (cpu_logical_map(i) >> 8) & 0xff;
+		cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 0);
+		cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 1);
 		if (cluster >= 2) {
 			pr_err("%s: only dual cluster systems are supported\n", __func__);
 			return -EINVAL;
 		}
-		cpumask_set_cpu(cpu, &cluster_mask[cluster]);
+		if (WARN_ON(cpu >= MAX_CPUS_PER_CLUSTER))
+			return -EINVAL;
+		mask |= (1 << cluster);
 	}
-
-	if (!cpumask_and(&common_mask, &cluster_mask[0], &cluster_mask[1])) {
-		pr_err("%s: no common set of CPUs\n", __func__);
+	if (mask != 3) {
+		pr_err("%s: no CPU pairing possible\n", __func__);
 		return -EINVAL;
 	}
 
-	for_each_online_cpu(i) {
-		cpu = cpu_logical_map(i) & 0xff;
-		cluster = (cpu_logical_map(i) >> 8) & 0xff;
-
-		if (cpumask_test_cpu(cpu, &common_mask)) {
-			/* Let's take note of the GIC ID for this CPU */
-			int gic_id = gic_get_cpu_id(i);
-			if (gic_id < 0) {
-				pr_err("%s: bad GIC ID for CPU %d\n", __func__, i);
-				return -EINVAL;
-			}
-			bL_gic_id[cpu][cluster] = gic_id;
-			pr_info("GIC ID for CPU %u cluster %u is %u\n",
-				cpu, cluster, gic_id);
-
+	/*
+	 * Now let's do the pairing.  We match each CPU with another CPU
+	 * from a different cluster.  To get a uniform scheduling behavior
+	 * without fiddling with CPU topology and compute capacity data,
+	 * we'll use logical CPUs initially belonging to the same cluster.
+	 */
+	memset(bL_switcher_cpu_pairing, -1, sizeof(bL_switcher_cpu_pairing));
+	cpumask_copy(&available_cpus, cpu_online_mask);
+	cluster_0 = -1;
+	for_each_cpu(i, &available_cpus) {
+		int match = -1;
+		cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 1);
+		if (cluster_0 == -1)
+			cluster_0 = cluster;
+		if (cluster != cluster_0)
+			continue;
+		cpumask_clear_cpu(i, &available_cpus);
+		for_each_cpu(j, &available_cpus) {
+			cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(j), 1);
 			/*
-			 * We keep only those logical CPUs which number
-			 * is equal to their physical CPU number. This is
-			 * not perfect but good enough for now.
+			 * Let's remember the last match to create "odd"
+			 * pairings on purpose in order for other code not
+			 * to assume any relation between physical and
+			 * logical CPU numbers.
 			 */
-			if (cpu == i) {
-				bL_switcher_cpu_original_cluster[cpu] = cluster;
-				continue;
-			}
+			if (cluster != cluster_0)
+				match = j;
+		}
+		if (match != -1) {
+			bL_switcher_cpu_pairing[i] = match;
+			cpumask_clear_cpu(match, &available_cpus);
+			pr_info("CPU%d paired with CPU%d\n", i, match);
+		}
+	}
+
+	/*
+	 * Now we disable the unwanted CPUs i.e. everything that has no
+	 * pairing information (that includes the pairing counterparts).
+	 */
+	cpumask_clear(&bL_switcher_removed_logical_cpus);
+	for_each_online_cpu(i) {
+		cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 0);
+		cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 1);
+
+		/* Let's take note of the GIC ID for this CPU */
+		gic_id = gic_get_cpu_id(i);
+		if (gic_id < 0) {
+			pr_err("%s: bad GIC ID for CPU %d\n", __func__, i);
+			bL_switcher_restore_cpus();
+			return -EINVAL;
+		}
+		bL_gic_id[cpu][cluster] = gic_id;
+		pr_info("GIC ID for CPU %u cluster %u is %u\n",
+			cpu, cluster, gic_id);
+
+		if (bL_switcher_cpu_pairing[i] != -1) {
+			bL_switcher_cpu_original_cluster[i] = cluster;
+			continue;
 		}
 
 		ret = cpu_down(i);
@@ -415,7 +452,7 @@ static int bL_switcher_enable(void)
 
 static void bL_switcher_disable(void)
 {
-	unsigned int cpu, cluster, i;
+	unsigned int cpu, cluster;
 	struct bL_thread *t;
 	struct task_struct *task;
 
@@ -435,7 +472,6 @@ static void bL_switcher_disable(void)
 	 * possibility for interference from external requests.
 	 */
 	for_each_online_cpu(cpu) {
-		BUG_ON(cpu != (cpu_logical_map(cpu) & 0xff));
 		t = &bL_threads[cpu];
 		task = t->task;
 		t->task = NULL;
@@ -459,14 +495,10 @@ static void bL_switcher_disable(void)
 		/* If execution gets here, we're in trouble. */
 		pr_crit("%s: unable to restore original cluster for CPU %d\n",
 			__func__, cpu);
-		for_each_cpu(i, &bL_switcher_removed_logical_cpus) {
-			if ((cpu_logical_map(i) & 0xff) != cpu)
-				continue;
-			pr_crit("%s: CPU %d can't be restored\n",
-				__func__, i);
-			cpumask_clear_cpu(i, &bL_switcher_removed_logical_cpus);
-			break;
-		}
+		pr_crit("%s: CPU %d can't be restored\n",
+			__func__, bL_switcher_cpu_pairing[cpu]);
+		cpumask_clear_cpu(bL_switcher_cpu_pairing[cpu],
+				  &bL_switcher_removed_logical_cpus);
 	}
 
 	bL_switcher_restore_cpus();
-- 
1.8.1.2



From swarren at wwwdotorg.org  Mon Jul 22 23:32:11 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 22 Jul 2013 20:32:11 -0700
Subject: [PATCH] decompressors: fix "no limit" output buffer length
In-Reply-To: <51EDE724.5020507@nvidia.com>
References: <1374476169-32194-1-git-send-email-acourbot@nvidia.com>
 <1374516481.14712.3.camel@linaro1.home> <51EDE724.5020507@nvidia.com>
Message-ID: <51EDF93B.1070101@wwwdotorg.org>

On 07/22/2013 07:15 PM, Alex Courbot wrote:
...
> Although the patch seems ok to me in its current form, there are two
> points for which I still have small doubts:
> 
> 1) Whether size_t and pointers will have the same size on all platforms.

ptrsize_t?


From padma.kvr at gmail.com  Tue Jul 23 00:08:00 2013
From: padma.kvr at gmail.com (Padma Venkat)
Date: Tue, 23 Jul 2013 09:38:00 +0530
Subject: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on
 Exynos5420
In-Reply-To: <20130712084932.GY24508@sirena.org.uk>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
 <29860116.IF545KsGYb@thinkpad>
 <20130711112023.GM24508@sirena.org.uk>
 <2214161.FSfscAvpna@thinkpad>
 <20130711130139.GQ24508@sirena.org.uk>
 <CAAgF-BdM4jw0o4+ELVo_N029tbgMJBBqJxU91e=TgBNiiREyaA@mail.gmail.com>
 <20130712084932.GY24508@sirena.org.uk>
Message-ID: <CAAgF-BfdfuhoFDH+SeZogXh1wju34hGp-T9N7_+mnapHfc2yww@mail.gmail.com>

Hi Mark,

On Fri, Jul 12, 2013 at 2:19 PM, Mark Brown <broonie at kernel.org> wrote:
> On Fri, Jul 12, 2013 at 10:07:22AM +0530, Padma Venkat wrote:
>
>> A new version number is added when a there was some change in the IP
>> like adding a internal mux to the IP, adding multi channel support,
>> adding reset control bit. This was done in the older code with
>> platform device.
>> Same thing is followed here. So as previously done, adding a new
>> compatible name like "samsung,i2s-v6" with new quirk
>> "samsung,supports-tdm" is okey?
>
> Yes, this is good but the quirk should just be found by software based
> on the compatible string rather than in the DT.

You mean I just need to initialize the quirks in the driver based on
the compatible string?
So what about the quirks that I added previously on 5250? Should I
also follow the same thing for other quirks?

Or it need to be passed via driver data as it is done in spi driver?
Please clarify me.

Thanks
Padma


From horms at verge.net.au  Tue Jul 23 00:12:23 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Jul 2013 13:12:23 +0900
Subject: [PATCH] dmaengine: shdma: fix a build failure on platforms with
 no DMA support
In-Reply-To: <20130723023907.GC14983@quad.lixom.net>
References: <1373422152-29976-1-git-send-email-horms+renesas@verge.net.au>
 <20130716012041.GA942@verge.net.au>
 <20130723023907.GC14983@quad.lixom.net>
Message-ID: <20130723041220.GA22253@verge.net.au>

On Mon, Jul 22, 2013 at 07:39:07PM -0700, Olof Johansson wrote:
> On Tue, Jul 16, 2013 at 10:20:41AM +0900, Simon Horman wrote:
> > On Wed, Jul 10, 2013 at 11:09:12AM +0900, Simon Horman wrote:
> > > From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
> > > 
> > > On platforms with no support for the shdma dmaengine driver build is
> > > currently failing with
> > > 
> > > drivers/built-in.o: In function `sh_mobile_sdhi_probe':
> > > drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference to`shdma_chan_filter'
> > > 
> > > Fix the breakage by defining shdma_chan_filter to NULL in such
> > > configurations.
> > > 
> > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> > > [horms+renesas at verge.net.au: Apply change to shdma-base.h instead of sh_dma.h]
> > > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> > > ---
> > >  include/linux/shdma-base.h | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > 
> > > 
> > > Hi Vinod,
> > > 
> > > please consider this fix from Guennadi for v3.11 which I have rebased on top of
> > > next-20130709. It fixes a build problem on a number of shmobile defconfigs
> > > including bockw.
> > 
> > Ping.
> > 
> > Would it be appropriate for me to take this change through my tree?
> > It seems to resolve a regression in v3.11-rc1.
> 
> I'll take it through arm-soc since there's no response from Vinod. I've
> applied it in the fixes branch we have.

Thanks!

Very much appreciated.


From rusty at rustcorp.com.au  Mon Jul 22 22:30:30 2013
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Tue, 23 Jul 2013 12:00:30 +0930
Subject: scatterlist: sg_set_buf() argument must be in linear mapping
 (sha1: ac4e97abce9b80c020e7113325f49e58b7b15e3f)
In-Reply-To: <51ED2C74.7050502@monstr.eu>
References: <51E64C6B.3080306@monstr.eu> <87siz7xt4z.fsf@rustcorp.com.au>
 <51ED2C74.7050502@monstr.eu>
Message-ID: <87ppua9feh.fsf@rustcorp.com.au>

Michal Simek <monstr at monstr.eu> writes:
> + Ohad
>
> On 07/22/2013 03:47 AM, Rusty Russell wrote:
>> Michal Simek <monstr at monstr.eu> writes:
>>> Hi Rusty and Jens,
>>>
>>> I am getting problem with your patch which you have added to the kernel.
>>> The problem is with my arm zynq remoteproc driver where
>>> I use dma_declare_coherent_memory() to specify memory for remoteproc
>>> which is ioremap to the vmalloc area.
>>>
>>> Based on that buf addr is not inside ram even this coherent memory is in ram.
>>> That's why virt_addr_valid(buf) is failing.
>> 
>> But sg_set_buf() calls virt_to_page(buf).  So does that work?
>> 
>> I would think calling sg_set_page() directly would be what you want
>> here...
>
> Let me take some code from virtio_rpmsg_bus.c to show that problematic part.
>
> bufs_va = dma_alloc_coherent(vdev->dev.parent->parent,
> 				RPMSG_TOTAL_BUF_SPACE,
> 				&vrp->bufs_dma, GFP_KERNEL);
> vrp->rbufs = bufs_va;
> for (i = 0; i < RPMSG_NUM_BUFS / 2; i++) {
> 	struct scatterlist sg;
> 	void *cpu_addr = vrp->rbufs + i * RPMSG_BUF_SIZE;
>
> 	sg_init_one(&sg, cpu_addr, RPMSG_BUF_SIZE);
> }

Hmm.  Looking at arch/arm/include/asm/memory.h:

#define virt_to_page(kaddr)	pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
#define virt_addr_valid(kaddr)	((unsigned long)(kaddr) >= PAGE_OFFSET && (unsigned long)(kaddr) < (unsigned long)high_memory)

pfn_to_page in ARM seems to be the asm-generic one, which depends on
CONFIG_SPARSEMEM/CONFIG_DISCONTIGMEM/CONFIG_FLATMEM etc.

Perhaps virt_addr_valid() is wrong for your config?  It's pretty clear
that you shouldn't call virt_to_page() on something for which
!virt_addr_valid().

Cheers,
Rusty.


From horms at verge.net.au  Tue Jul 23 00:31:16 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 23 Jul 2013 13:31:16 +0900
Subject: [PATCH] ARM: shmobile: r8a7790 SMP prototype v5
In-Reply-To: <20130719022904.GG4403@verge.net.au>
References: <20130717204918.30125.40588.sendpatchset@w520>
 <51E7379A.1080408@renesas.com> <20130719022904.GG4403@verge.net.au>
Message-ID: <20130723043116.GA26723@verge.net.au>

On Fri, Jul 19, 2013 at 11:29:04AM +0900, Simon Horman wrote:
> On Thu, Jul 18, 2013 at 09:32:26AM +0900, Shinya Kuribayashi wrote:
> > On 7/18/2013 5:49 AM, Magnus Damm wrote:
> > >  Changes since v4:
> > >  - Rolled in the following patches from Kuribayashi-san, thanks!
> > >    ARM: shmobile: smp-r8a7790: remove the obsolete RESCNT register
> > >    ARM: shmobile: smp-r8a7790: rename s/carescnt/rescnt/g
> > >    ARM: shmobile: smp-r8a7790: rename s/cabar/bar/g as well
> > >    ARM: shmobile: smp-r8a7790: power up a CPU core at .smp_boot_secondary stage
> > > 
> > >  Written against kernel.org renesas git tag renesas-devel-20130717
> > 
> > Thanks for the update, looks good to me.
> 
> Thanks.
> 
> This seems like it is ready to queue-up.
> Magnus, are there any outstanding reviews or issues?

I have placed this in topic/lager-smp-v5 in the renesas tree
to aid review. It is not yet queued up for mainline.

topic/lager-smp still contains v3 of this patch.
Let me know if I can delete this branch.


From festevam at gmail.com  Tue Jul 23 00:52:55 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 23 Jul 2013 01:52:55 -0300
Subject: linux-3.11-rc1: Internal error: Oops - undefined instruction: 0
 [#1] SMP ARM on OMAP3/AM335x
In-Reply-To: <51ECFBAC.7090900@ti.com>
References: <51ECFBAC.7090900@ti.com>
Message-ID: <CAOMZO5AAz+O=Xtajc8uojMniEkzvXk-kT6QAUtMXTnmiqbS63g@mail.gmail.com>

Hi Roger,

On Mon, Jul 22, 2013 at 6:30 AM, Roger Quadros <rogerq at ti.com> wrote:
> Hi,
>
> I observe the following problem on booting v3.11-rc1 on OMAP3 beagle board.
>
> [    5.888946] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> [    5.896057] Modules linked in:
> [    5.899322] CPU: 0 PID: 9 Comm: rcu_sched Not tainted 3.11.0-rc2-00001-g1ea701a #876
> [    5.907501] task: ce0720c0 ti: ce07a000 task.ti: ce07a000
> [    5.913208] PC is at check_and_switch_context+0x130/0x4dc
> [    5.918914] LR is at check_and_switch_context+0xd8/0x4dc

Got the same issue on a mx53 and prepared a fix. Will submit it shortly.

Regards,

Fabio Estevam


From rnayak at ti.com  Tue Jul 23 00:59:22 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 23 Jul 2013 10:29:22 +0530
Subject: [PATCH 3/4] ARM: OMAP2+: Avoid idling memory controllers with
 no drivers
In-Reply-To: <alpine.DEB.2.02.1307221746430.10891@utopia.booyaka.com>
References: <1374487277-26099-1-git-send-email-rnayak@ti.com>
 <1374487277-26099-4-git-send-email-rnayak@ti.com>
 <alpine.DEB.2.02.1307221746430.10891@utopia.booyaka.com>
Message-ID: <51EE0DAA.9000203@ti.com>

On Monday 22 July 2013 11:18 PM, Paul Walmsley wrote:
> Hi
> 
> On Mon, 22 Jul 2013, Rajendra Nayak wrote:
> 
>> Memory controllers in OMAP (like GPMC and EMIF) have the hwmods marked with
>> HWMOD_INIT_NO_IDLE and are left in enabled state post initial setup.
>>
>> Even if they have drivers missing, avoid idling them as part of
>> omap_device_late_idle()
> 
> Since this patch is intended for the -rc series, it's best if you explain 
> here what effects this patch will fix.  i.e., does this fix a crash, a 
> warning, etc?  Also maybe update your series description message?

This patch infact is needed because of 'PATCH 4/4' in the series which makes
sure the omap_device and pm_runtime state are in sync with the hwmod state.

Without that we always had gpmc and emif having the hwmod state as enabled but
omap_device state as disabled and we never hit the issue of omap_device_late_idle()
trying to disable gpmc and emif.

So in short, this does not fix anything in the existing code, but something that
was uncovered by syncing the states across hwmod and omap_device.

regards,
Rajendra

> 
> 
> - Paul
> 



From acourbot at nvidia.com  Tue Jul 23 01:01:32 2013
From: acourbot at nvidia.com (Alex Courbot)
Date: Tue, 23 Jul 2013 14:01:32 +0900
Subject: [PATCH] decompressors: fix "no limit" output buffer length
In-Reply-To: <51EDF93B.1070101@wwwdotorg.org>
References: <1374476169-32194-1-git-send-email-acourbot@nvidia.com>
 <1374516481.14712.3.camel@linaro1.home> <51EDE724.5020507@nvidia.com>
 <51EDF93B.1070101@wwwdotorg.org>
Message-ID: <51EE0E2C.8090103@nvidia.com>

On 07/23/2013 12:32 PM, Stephen Warren wrote:
> On 07/22/2013 07:15 PM, Alex Courbot wrote:
> ...
>> Although the patch seems ok to me in its current form, there are two
>> points for which I still have small doubts:
>>
>> 1) Whether size_t and pointers will have the same size on all platforms.
>
> ptrsize_t?
>

Do you mean ptrdiff_t? (I cannot find ptrsize_t anywhere in the kernel)

Looking further about the uses of size_t and ptrdiff_t, it seems like 
size_t is designed to store the maximum addressable member of an array, 
whereas ptrdiff_t is used to store a substraction of two pointers. In 
effect, they translate to the unsigned (size_t) and signed (ptrdiff_t) 
variants of the same type.

But since here we know that the result of the substraction will always 
be positive and potentially big (for devices with memory in the lower 
half of the address space) using size_t sounds safer to avoid overflows 
and sign-conversion issues (strm->avail_out, where the value of out_len 
eventually ends, is an unsigned int).

So point 1) at least seems to be handled correctly with size_t. Point 2) 
might still be of concern, but if your uncompressed kernel image ends up 
overflowing your addressable memory, I guess you have a bigger problem 
to start with. :)

Andrew, do you think you can merge this as-is? Sorry if you are not the 
right person to ask, but there is no clear maintainer for this part of 
the code and you appear to have handled the latest patches that affect 
the same file.

Thanks,
Alex.



From festevam at gmail.com  Tue Jul 23 01:19:34 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 23 Jul 2013 02:19:34 -0300
Subject: [PATCH] ARM: Do not run dummy_flush_tlb_a15_erratum() on
 non-Cortex-A15
Message-ID: <1374556774-18795-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Commit 93dc688 (ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 
(TLBI/DSB operations)) causes the following undefined instruction error on a
mx53 (Cortex-A8):

Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
CPU: 0 PID: 275 Comm: modprobe Not tainted 3.11.0-rc2-next-20130722-00009-g9b0f371 #881
task: df46cc00 ti: df48e000 task.ti: df48e000
PC is at check_and_switch_context+0x17c/0x4d0
LR is at check_and_switch_context+0xdc/0x4d0

This problem happens because check_and_switch_context() calls 
dummy_flush_tlb_a15_erratum() without checking if we are really running on a 
Cortex-A15 or not. 

To avoid this issue, always check if we are running on a Cortex-A15 or not 
(via erratum_a15_798181()) inside dummy_flush_tlb_a15_erratum(), so that we do 
not need to keep doing the same check in all occurrences of 
dummy_flush_tlb_a15_erratum().

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/include/asm/tlbflush.h | 18 ++++++++++++++++++
 arch/arm/kernel/smp_tlb.c       | 23 -----------------------
 2 files changed, 18 insertions(+), 23 deletions(-)

diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index fdbb9e3..2478b6f 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -443,9 +443,22 @@ static inline void local_flush_bp_all(void)
 		isb();
 }
 
+#include <asm/cputype.h>
 #ifdef CONFIG_ARM_ERRATA_798181
+static inline int erratum_a15_798181(void)
+{
+	unsigned int midr = read_cpuid_id();
+
+	/* Cortex-A15 r0p0..r3p2 affected */
+	if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2)
+		return 0;
+	return 1;
+}
+
 static inline void dummy_flush_tlb_a15_erratum(void)
 {
+	if (!erratum_a15_798181())
+		return;
 	/*
 	 * Dummy TLBIMVAIS. Using the unmapped address 0 and ASID 0.
 	 */
@@ -453,6 +466,11 @@ static inline void dummy_flush_tlb_a15_erratum(void)
 	dsb();
 }
 #else
+static inline int erratum_a15_798181(void)
+{
+	return 0;
+}
+
 static inline void dummy_flush_tlb_a15_erratum(void)
 {
 }
diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
index a98b62d..29e9038 100644
--- a/arch/arm/kernel/smp_tlb.c
+++ b/arch/arm/kernel/smp_tlb.c
@@ -70,23 +70,6 @@ static inline void ipi_flush_bp_all(void *ignored)
 	local_flush_bp_all();
 }
 
-#ifdef CONFIG_ARM_ERRATA_798181
-static int erratum_a15_798181(void)
-{
-	unsigned int midr = read_cpuid_id();
-
-	/* Cortex-A15 r0p0..r3p2 affected */
-	if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2)
-		return 0;
-	return 1;
-}
-#else
-static int erratum_a15_798181(void)
-{
-	return 0;
-}
-#endif
-
 static void ipi_flush_tlb_a15_erratum(void *arg)
 {
 	dmb();
@@ -94,9 +77,6 @@ static void ipi_flush_tlb_a15_erratum(void *arg)
 
 static void broadcast_tlb_a15_erratum(void)
 {
-	if (!erratum_a15_798181())
-		return;
-
 	dummy_flush_tlb_a15_erratum();
 	smp_call_function(ipi_flush_tlb_a15_erratum, NULL, 1);
 }
@@ -106,9 +86,6 @@ static void broadcast_tlb_mm_a15_erratum(struct mm_struct *mm)
 	int this_cpu;
 	cpumask_t mask = { CPU_BITS_NONE };
 
-	if (!erratum_a15_798181())
-		return;
-
 	dummy_flush_tlb_a15_erratum();
 	this_cpu = get_cpu();
 	a15_erratum_get_cpumask(this_cpu, mm, &mask);
-- 
1.8.1.2



From kishon at ti.com  Tue Jul 23 01:34:53 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 23 Jul 2013 11:04:53 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130722150458.GA18181@kroah.com>
References: <Pine.LNX.4.44L0.1307211453450.19133-100000@netrider.rowland.org>
 <51ECDE5E.3050104@ti.com> <20130722150458.GA18181@kroah.com>
Message-ID: <51EE15FD.2010205@ti.com>

Hi,

On Monday 22 July 2013 08:34 PM, Greg KH wrote:
> On Mon, Jul 22, 2013 at 12:55:18PM +0530, Kishon Vijay Abraham I wrote:
>>> 	The issue (or one of the issues) in this discussion is that 
>>> 	Greg does not like the idea of using names or IDs to associate
>>> 	PHYs with controllers, because they are too prone to
>>> 	duplications or other errors.  Pointers are more reliable.
>>>
>>> 	But pointers to what?  Since the only data known to be 
>>> 	available to both the PHY driver and controller driver is the
>>> 	platform data, the obvious answer is a pointer to platform data
>>> 	(either for the PHY or for the controller, or maybe both).
>>
>> hmm.. it's not going to be simple though as the platform device for the PHY and
>> controller can be created in entirely different places. e.g., in some cases the
>> PHY device is a child of some mfd core device (the device will be created in
>> drivers/mfd) and the controller driver (usually) is created in board file. I
>> guess then we have to come up with something to share a pointer in two
>> different files.
> 
> What's wrong with using the platform_data structure that is unique to
> all boards (see include/platform_data/ for examples)?  Isn't that what
> this structure is there for?

Alright. I got some ideas from Alan Stern. I'll use it with platform_data and
repost the series.

Thanks
Kishon


From kishon at ti.com  Tue Jul 23 01:47:40 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 23 Jul 2013 11:17:40 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <Pine.LNX.4.44L0.1307221028440.1495-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307221028440.1495-100000@iolanthe.rowland.org>
Message-ID: <51EE18FC.2070505@ti.com>

Hi,

On Monday 22 July 2013 08:14 PM, Alan Stern wrote:
> On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
> 
>>> 	The PHY and the controller it is attached to are both physical
>>> 	devices.
>>>
>>> 	The connection between them is hardwired by the system
>>> 	manufacturer and cannot be changed by software.
>>>
>>> 	PHYs are generally described by fixed system-specific board
>>> 	files or by Device Tree information.  Are they ever discovered
>>> 	dynamically?
>>
>> No. They are created just like any other platform devices are created.
> 
> Okay.  Are PHYs _always_ platform devices?

Not always. It can be any other device also.
> 
>>> 	Is the same true for the controllers attached to the PHYs?
>>> 	If not -- if both a PHY and a controller are discovered 
>>> 	dynamically -- how does the kernel know whether they are 
>>> 	connected to each other?
>>
>> No differences here. Both PHY and controller will have dt information or hwmod
>> data using which platform devices will be created.
>>>
>>> 	The kernel needs to know which controller is attached to which
>>> 	PHY.  Currently this information is represented by name or ID
>>> 	strings embedded in platform data.
>>
>> right. It's embedded in the platform data of the controller.
> 
> It must also be embedded in the PHY's platform data somehow.  
> Otherwise, how would the kernel know which PHY to use?
> 
>>> 	The PHY's driver (the supplier) uses the platform data to 
>>> 	construct a platform_device structure that represents the PHY.  
>>
>> Currently the driver assigns static labels (corresponding to the label used in
>> the platform data of the controller).
>>> 	Until this is done, the controller's driver (the client) cannot 
>>> 	use the PHY.
>>
>> right.
>>>
>>> 	Since there is no parent-child relation between the PHY and the 
>>> 	controller, there is no guarantee that the PHY's driver will be
>>> 	ready when the controller's driver wants to use it.  A deferred
>>> 	probe may be needed.
>>
>> right.
>>>
>>> 	The issue (or one of the issues) in this discussion is that 
>>> 	Greg does not like the idea of using names or IDs to associate
>>> 	PHYs with controllers, because they are too prone to
>>> 	duplications or other errors.  Pointers are more reliable.
>>>
>>> 	But pointers to what?  Since the only data known to be 
>>> 	available to both the PHY driver and controller driver is the
>>> 	platform data, the obvious answer is a pointer to platform data
>>> 	(either for the PHY or for the controller, or maybe both).
>>
>> hmm.. it's not going to be simple though as the platform device for the PHY and
>> controller can be created in entirely different places. e.g., in some cases the
>> PHY device is a child of some mfd core device (the device will be created in
>> drivers/mfd) and the controller driver (usually) is created in board file. I
>> guess then we have to come up with something to share a pointer in two
>> different files.
> 
> The ability for two different source files to share a pointer to a data 
> item defined in a third source file has been around since long before 
> the C language was invented.  :-)
> 
> In this case, it doesn't matter where the platform_device structures 
> are created or where the driver source code is.  Let's take a simple 
> example.  Suppose the system design includes a PHY named "foo".  Then 
> the board file could contain:
> 
> struct phy_info { ... } phy_foo;
> EXPORT_SYMBOL_GPL(phy_foo);
> 
> and a header file would contain:
> 
> extern struct phy_info phy_foo;
> 
> The PHY supplier could then call phy_create(&phy_foo), and the PHY 
> client could call phy_find(&phy_foo).  Or something like that; make up 
> your own structure tags and function names.

Alright. Thanks for the hint :-)

Thanks
Kishon


From rnayak at ti.com  Tue Jul 23 02:24:36 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 23 Jul 2013 11:54:36 +0530
Subject: [PATCH 0/3] OMAP2+: hwmod: Add support to parse clock info from DT
Message-ID: <1374560679-14666-1-git-send-email-rnayak@ti.com>

With all of OMAP clock data now moving to DT, its possible to pass the
main or functional clock and all optional clocks information for a
device from DT instead of having these as part of hwmod static data
in the kernel.

This patch series is based on 'v3' of omap4 clock movement to DT
patches [1] and is boot tested on a omap4 panda es.

The series does leave all the interface clocks as part of hwmod (and
main and optional clocks for devices which are missing DT drivers).

[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/100117

Rajendra Nayak (3):
  ARM: OMAP2+: Add support to parse 'main_clk' info from DT
  ARM: OMAP2+: Add support to parse optional clk info from DT
  ARM: OMAP4: dts: Add main and optional clock data into DT

 arch/arm/boot/dts/omap4.dtsi               |  100 +++++++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod.c           |  100 +++++++++++++++++++++----
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  112 ----------------------------
 3 files changed, 185 insertions(+), 127 deletions(-)

-- 
1.7.9.5



From rnayak at ti.com  Tue Jul 23 02:24:37 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 23 Jul 2013 11:54:37 +0530
Subject: [PATCH 1/3] ARM: OMAP2+: Add support to parse 'main_clk' info from DT
In-Reply-To: <1374560679-14666-1-git-send-email-rnayak@ti.com>
References: <1374560679-14666-1-git-send-email-rnayak@ti.com>
Message-ID: <1374560679-14666-2-git-send-email-rnayak@ti.com>

With clocks for OMAP moving to DT, its now possible to pass the 'main_clk'
data for each device from DT instead of having it in hwmod.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |   34 +++++++++++++++++++++-------------
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5cc5123..12fa589 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -728,14 +728,18 @@ static int _del_initiator_dep(struct omap_hwmod *oh, struct omap_hwmod *init_oh)
  * functional clock pointer) if a main_clk is present.  Returns 0 on
  * success or -EINVAL on error.
  */
-static int _init_main_clk(struct omap_hwmod *oh)
+static int _init_main_clk(struct omap_hwmod *oh, struct device_node *np)
 {
 	int ret = 0;
 
-	if (!oh->main_clk)
+	if (!oh->main_clk && !of_get_property(np, "clocks", NULL))
 		return 0;
 
-	oh->_clk = clk_get(NULL, oh->main_clk);
+	if (oh->main_clk)
+		oh->_clk = clk_get(NULL, oh->main_clk);
+	else
+		oh->_clk = of_clk_get_by_name(np, "fck");
+
 	if (IS_ERR(oh->_clk)) {
 		pr_warning("omap_hwmod: %s: cannot clk_get main_clk %s\n",
 			   oh->name, oh->main_clk);
@@ -1561,7 +1565,8 @@ static int _init_clkdm(struct omap_hwmod *oh)
  * Resolves all clock names embedded in the hwmod.  Returns 0 on
  * success, or a negative error code on failure.
  */
-static int _init_clocks(struct omap_hwmod *oh, void *data)
+static int _init_clocks(struct omap_hwmod *oh, void *data,
+			struct device_node *np)
 {
 	int ret = 0;
 
@@ -1573,7 +1578,7 @@ static int _init_clocks(struct omap_hwmod *oh, void *data)
 	if (soc_ops.init_clkdm)
 		ret |= soc_ops.init_clkdm(oh);
 
-	ret |= _init_main_clk(oh);
+	ret |= _init_main_clk(oh, np);
 	ret |= _init_interface_clks(oh);
 	ret |= _init_opt_clks(oh);
 
@@ -2361,11 +2366,11 @@ static struct device_node *of_dev_hwmod_lookup(struct device_node *np,
  * are part of the device's address space can be ioremapped properly.
  * No return value.
  */
-static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data)
+static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data,
+				     struct device_node *np)
 {
 	struct omap_hwmod_addr_space *mem;
 	void __iomem *va_start = NULL;
-	struct device_node *np;
 
 	if (!oh)
 		return;
@@ -2381,12 +2386,10 @@ static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data)
 			 oh->name);
 
 		/* Extract the IO space from device tree blob */
-		if (!of_have_populated_dt())
+		if (!np)
 			return;
 
-		np = of_dev_hwmod_lookup(of_find_node_by_name(NULL, "ocp"), oh);
-		if (np)
-			va_start = of_iomap(np, 0);
+		va_start = of_iomap(np, 0);
 	} else {
 		va_start = ioremap(mem->pa_start, mem->pa_end - mem->pa_start);
 	}
@@ -2418,14 +2421,19 @@ static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data)
 static int __init _init(struct omap_hwmod *oh, void *data)
 {
 	int r;
+	struct device_node *np = NULL;
 
 	if (oh->_state != _HWMOD_STATE_REGISTERED)
 		return 0;
 
+	/* If booting with DT, parse the DT node for IO space/clocks etc */
+	if (of_have_populated_dt())
+		np = of_dev_hwmod_lookup(of_find_node_by_name(NULL, "ocp"), oh);
+
 	if (oh->class->sysc)
-		_init_mpu_rt_base(oh, NULL);
+		_init_mpu_rt_base(oh, NULL, np);
 
-	r = _init_clocks(oh, NULL);
+	r = _init_clocks(oh, NULL, np);
 	if (r < 0) {
 		WARN(1, "omap_hwmod: %s: couldn't init clocks\n", oh->name);
 		return -EINVAL;
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul 23 02:24:38 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 23 Jul 2013 11:54:38 +0530
Subject: [PATCH 2/3] ARM: OMAP2+: Add support to parse optional clk info from
 DT
In-Reply-To: <1374560679-14666-1-git-send-email-rnayak@ti.com>
References: <1374560679-14666-1-git-send-email-rnayak@ti.com>
Message-ID: <1374560679-14666-3-git-send-email-rnayak@ti.com>

With clocks for OMAP moving to DT, its now possible to pass all optional clock
data for each device from DT instead of having it in hwmod.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |   66 ++++++++++++++++++++++++++++++++++++--
 1 file changed, 64 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 12fa589..e5c804b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -805,6 +805,65 @@ static int _init_interface_clks(struct omap_hwmod *oh)
 	return ret;
 }
 
+static const char **_parse_opt_clks_dt(struct omap_hwmod *oh,
+				       struct device_node *np,
+				       int *opt_clks_cnt)
+{
+	int i, clks_cnt;
+	const char *clk_name;
+	const char **opt_clk_names;
+
+	clks_cnt = of_property_count_strings(np, "clock-names");
+	if (!clks_cnt)
+		return NULL;
+
+	opt_clk_names = kzalloc(sizeof(char *)*clks_cnt, GFP_KERNEL);
+	if (!opt_clk_names)
+		return NULL;
+
+	for (i = 0; i < clks_cnt; i++) {
+		of_property_read_string_index(np, "clock-names", i, &clk_name);
+		if (!strcmp(clk_name, "fck"))
+			continue;
+		opt_clks_cnt++;
+		opt_clk_names[i] = clk_name;
+	}
+	return opt_clk_names;
+}
+
+static int _init_opt_clks_dt(struct omap_hwmod *oh, struct device_node *np)
+{
+	struct clk *c;
+	int i, opt_clks_cnt = 0;
+	int ret = 0;
+	const char **opt_clk_names;
+
+	opt_clk_names = _parse_opt_clks_dt(oh, np, &opt_clks_cnt);
+	if (!opt_clk_names)
+		return -EINVAL;
+
+	oh->opt_clks = kzalloc(sizeof(struct omap_hwmod_opt_clk *)
+			       * opt_clks_cnt, GFP_KERNEL);
+	if (!oh->opt_clks)
+		return -ENOMEM;
+
+	oh->opt_clks_cnt = opt_clks_cnt;
+
+	for (i = 0; i < oh->opt_clks_cnt; i++) {
+		c = of_clk_get_by_name(np, opt_clk_names[i]);
+		if (IS_ERR(c)) {
+			pr_warn("omap_hwmod: %s: cannot clk_get opt_clk %s\n",
+				oh->name, opt_clk_names[i]);
+			ret = -EINVAL;
+		}
+		oh->opt_clks[i]._clk = c;
+		oh->opt_clks[i].role = opt_clk_names[i];
+		oh->opt_clks_cnt++;
+		clk_prepare(oh->opt_clks[i]._clk);
+	}
+	return ret;
+}
+
 /**
  * _init_opt_clk - get a struct clk * for the the hwmod's optional clocks
  * @oh: struct omap_hwmod *
@@ -812,13 +871,16 @@ static int _init_interface_clks(struct omap_hwmod *oh)
  * Called from _init_clocks().  Populates the @oh omap_hwmod_opt_clk
  * clock pointers.  Returns 0 on success or -EINVAL on error.
  */
-static int _init_opt_clks(struct omap_hwmod *oh)
+static int _init_opt_clks(struct omap_hwmod *oh, struct device_node *np)
 {
 	struct omap_hwmod_opt_clk *oc;
 	struct clk *c;
 	int i;
 	int ret = 0;
 
+	if (of_get_property(np, "clocks", NULL))
+		return _init_opt_clks_dt(oh, np);
+
 	for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++) {
 		c = clk_get(NULL, oc->clk);
 		if (IS_ERR(c)) {
@@ -1580,7 +1642,7 @@ static int _init_clocks(struct omap_hwmod *oh, void *data,
 
 	ret |= _init_main_clk(oh, np);
 	ret |= _init_interface_clks(oh);
-	ret |= _init_opt_clks(oh);
+	ret |= _init_opt_clks(oh, np);
 
 	if (!ret)
 		oh->_state = _HWMOD_STATE_CLKS_INITED;
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul 23 02:24:39 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 23 Jul 2013 11:54:39 +0530
Subject: [PATCH 3/3] ARM: OMAP4: dts: Add main and optional clock data into DT
In-Reply-To: <1374560679-14666-1-git-send-email-rnayak@ti.com>
References: <1374560679-14666-1-git-send-email-rnayak@ti.com>
Message-ID: <1374560679-14666-4-git-send-email-rnayak@ti.com>

With support to parse clock data from DT, move all main and optional
clock information from hwmod to DT.

We still retain clocks in hwmod for devices which do not have a DT node.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/boot/dts/omap4.dtsi               |  100 +++++++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  112 ----------------------------
 2 files changed, 100 insertions(+), 112 deletions(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 8e142f9..4dddf64 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -106,6 +106,8 @@
 			compatible = "ti,omap-counter32k";
 			reg = <0x4a304000 0x20>;
 			ti,hwmods = "counter_32k";
+			clocks = <&sys_32k_ck>;
+			clock-names = "fck";
 		};
 
 		omap4_pmx_core: pinmux at 4a100040 {
@@ -135,6 +137,8 @@
 			#dma-cells = <1>;
 			#dma-channels = <32>;
 			#dma-requests = <127>;
+			clocks = <&l3_div_ck>;
+			clock-names = "fck";
 		};
 
 		gpio1: gpio at 4a310000 {
@@ -147,6 +151,8 @@
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
+			clocks = <&l4_wkup_clk_mux_ck>, <&gpio1_dbclk>;
+			clock-names = "fck", "dbclk";
 		};
 
 		gpio2: gpio at 48055000 {
@@ -158,6 +164,8 @@
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
+			clocks = <&l4_div_ck>, <&gpio2_dbclk>;
+			clock-names = "fck", "dbclk";
 		};
 
 		gpio3: gpio at 48057000 {
@@ -169,6 +177,8 @@
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
+			clocks = <&l4_div_ck>, <&gpio3_dbclk>;
+			clock-names = "fck", "dbclk";
 		};
 
 		gpio4: gpio at 48059000 {
@@ -180,6 +190,8 @@
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
+			clocks = <&l4_div_ck>, <&gpio4_dbclk>;
+			clock-names = "fck", "dbclk";
 		};
 
 		gpio5: gpio at 4805b000 {
@@ -191,6 +203,8 @@
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
+			clocks = <&l4_div_ck>, <&gpio5_dbclk>;
+			clock-names = "fck", "dbclk";
 		};
 
 		gpio6: gpio at 4805d000 {
@@ -202,6 +216,8 @@
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
+			clocks = <&l4_div_ck>, <&gpio6_dbclk>;
+			clock-names = "fck", "dbclk";
 		};
 
 		gpmc: gpmc at 50000000 {
@@ -221,6 +237,8 @@
 			interrupts = <0 72 0x4>;
 			ti,hwmods = "uart1";
 			clock-frequency = <48000000>;
+			clocks = <&func_48m_fclk>;
+			clock-names = "fck";
 		};
 
 		uart2: serial at 4806c000 {
@@ -229,6 +247,8 @@
 			interrupts = <0 73 0x4>;
 			ti,hwmods = "uart2";
 			clock-frequency = <48000000>;
+			clocks = <&func_48m_fclk>;
+			clock-names = "fck";
 		};
 
 		uart3: serial at 48020000 {
@@ -237,6 +257,8 @@
 			interrupts = <0 74 0x4>;
 			ti,hwmods = "uart3";
 			clock-frequency = <48000000>;
+			clocks = <&func_48m_fclk>;
+			clock-names = "fck";
 		};
 
 		uart4: serial at 4806e000 {
@@ -245,6 +267,8 @@
 			interrupts = <0 70 0x4>;
 			ti,hwmods = "uart4";
 			clock-frequency = <48000000>;
+			clocks = <&func_48m_fclk>;
+			clock-names = "fck";
 		};
 
 		i2c1: i2c at 48070000 {
@@ -254,6 +278,8 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 			ti,hwmods = "i2c1";
+			clocks = <&func_96m_fclk>;
+			clock-names = "fck";
 		};
 
 		i2c2: i2c at 48072000 {
@@ -263,6 +289,8 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 			ti,hwmods = "i2c2";
+			clocks = <&func_96m_fclk>;
+			clock-names = "fck";
 		};
 
 		i2c3: i2c at 48060000 {
@@ -272,6 +300,8 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 			ti,hwmods = "i2c3";
+			clocks = <&func_96m_fclk>;
+			clock-names = "fck";
 		};
 
 		i2c4: i2c at 48350000 {
@@ -281,6 +311,8 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 			ti,hwmods = "i2c4";
+			clocks = <&func_96m_fclk>;
+			clock-names = "fck";
 		};
 
 		mcspi1: spi at 48098000 {
@@ -301,6 +333,8 @@
 			       <&sdma 42>;
 			dma-names = "tx0", "rx0", "tx1", "rx1",
 				    "tx2", "rx2", "tx3", "rx3";
+			clocks = <&func_48m_fclk>;
+			clock-names = "fck";
 		};
 
 		mcspi2: spi at 4809a000 {
@@ -316,6 +350,8 @@
 			       <&sdma 45>,
 			       <&sdma 46>;
 			dma-names = "tx0", "rx0", "tx1", "rx1";
+			clocks = <&func_48m_fclk>;
+			clock-names = "fck";
 		};
 
 		mcspi3: spi at 480b8000 {
@@ -328,6 +364,8 @@
 			ti,spi-num-cs = <2>;
 			dmas = <&sdma 15>, <&sdma 16>;
 			dma-names = "tx0", "rx0";
+			clocks = <&func_48m_fclk>;
+			clock-names = "fck";
 		};
 
 		mcspi4: spi at 480ba000 {
@@ -340,6 +378,8 @@
 			ti,spi-num-cs = <1>;
 			dmas = <&sdma 70>, <&sdma 71>;
 			dma-names = "tx0", "rx0";
+			clocks = <&func_48m_fclk>;
+			clock-names = "fck";
 		};
 
 		mmc1: mmc at 4809c000 {
@@ -351,6 +391,8 @@
 			ti,needs-special-reset;
 			dmas = <&sdma 61>, <&sdma 62>;
 			dma-names = "tx", "rx";
+			clocks = <&hsmmc1_fclk>;
+			clock-names = "fck";
 		};
 
 		mmc2: mmc at 480b4000 {
@@ -361,6 +403,8 @@
 			ti,needs-special-reset;
 			dmas = <&sdma 47>, <&sdma 48>;
 			dma-names = "tx", "rx";
+			clocks = <&hsmmc2_fclk>;
+			clock-names = "fck";
 		};
 
 		mmc3: mmc at 480ad000 {
@@ -371,6 +415,8 @@
 			ti,needs-special-reset;
 			dmas = <&sdma 77>, <&sdma 78>;
 			dma-names = "tx", "rx";
+			clocks = <&func_48m_fclk>;
+			clock-names = "fck";
 		};
 
 		mmc4: mmc at 480d1000 {
@@ -381,6 +427,8 @@
 			ti,needs-special-reset;
 			dmas = <&sdma 57>, <&sdma 58>;
 			dma-names = "tx", "rx";
+			clocks = <&func_48m_fclk>;
+			clock-names = "fck";
 		};
 
 		mmc5: mmc at 480d5000 {
@@ -391,6 +439,8 @@
 			ti,needs-special-reset;
 			dmas = <&sdma 59>, <&sdma 60>;
 			dma-names = "tx", "rx";
+			clocks = <&func_48m_fclk>;
+			clock-names = "fck";
 		};
 
 		wdt2: wdt at 4a314000 {
@@ -398,6 +448,8 @@
 			reg = <0x4a314000 0x80>;
 			interrupts = <0 80 0x4>;
 			ti,hwmods = "wd_timer2";
+			clocks = <&sys_32k_ck>;
+			clock-names = "fck";
 		};
 
 		mcpdm: mcpdm at 40132000 {
@@ -410,6 +462,8 @@
 			dmas = <&sdma 65>,
 			       <&sdma 66>;
 			dma-names = "up_link", "dn_link";
+			clocks = <&pad_clks_ck>;
+			clock-names = "fck";
 		};
 
 		dmic: dmic at 4012e000 {
@@ -421,6 +475,8 @@
 			ti,hwmods = "dmic";
 			dmas = <&sdma 67>;
 			dma-names = "up_link";
+			clocks = <&func_dmic_abe_gfclk>;
+			clock-names = "fck";
 		};
 
 		mcbsp1: mcbsp at 40122000 {
@@ -435,6 +491,8 @@
 			dmas = <&sdma 33>,
 			       <&sdma 34>;
 			dma-names = "tx", "rx";
+			clocks = <&func_mcbsp1_gfclk>, <&pad_clks_ck>, <&mcbsp1_sync_mux_ck>;
+			clock-names = "fck", "pad_fck", "prcm_fck";
 		};
 
 		mcbsp2: mcbsp at 40124000 {
@@ -449,6 +507,8 @@
 			dmas = <&sdma 17>,
 			       <&sdma 18>;
 			dma-names = "tx", "rx";
+			clocks = <&func_mcbsp2_gfclk>, <&pad_clks_ck>, <&mcbsp2_sync_mux_ck>;
+			clock-names = "fck", "pad_fck", "prcm_fck";
 		};
 
 		mcbsp3: mcbsp at 40126000 {
@@ -463,6 +523,8 @@
 			dmas = <&sdma 19>,
 			       <&sdma 20>;
 			dma-names = "tx", "rx";
+			clocks = <&func_mcbsp3_gfclk>, <&pad_clks_ck>, <&mcbsp3_sync_mux_ck>;
+			clock-names = "fck", "pad_fck", "prcm_fck";
 		};
 
 		mcbsp4: mcbsp at 48096000 {
@@ -476,6 +538,8 @@
 			dmas = <&sdma 31>,
 			       <&sdma 32>;
 			dma-names = "tx", "rx";
+			clocks = <&per_mcbsp4_gfclk>, <&pad_clks_ck>, <&mcbsp4_sync_mux_ck>;
+			clock-names = "fck", "pad_fck", "prcm_fck";
 		};
 
 		keypad: keypad at 4a31c000 {
@@ -484,6 +548,8 @@
 			interrupts = <0 120 0x4>;
 			reg-names = "mpu";
 			ti,hwmods = "kbd";
+			clocks = <&sys_32k_ck>;
+			clock-names = "fck";
 		};
 
 		emif1: emif at 4c000000 {
@@ -495,6 +561,8 @@
 			hw-caps-read-idle-ctrl;
 			hw-caps-ll-interface;
 			hw-caps-temp-alert;
+			clocks = <&ddrphy_ck>;
+			clock-names = "fck";
 		};
 
 		emif2: emif at 4d000000 {
@@ -506,6 +574,8 @@
 			hw-caps-read-idle-ctrl;
 			hw-caps-ll-interface;
 			hw-caps-temp-alert;
+			clocks = <&ddrphy_ck>;
+			clock-names = "fck";
 		};
 
 		ocp2scp at 4a0ad000 {
@@ -515,6 +585,8 @@
 			#size-cells = <1>;
 			ranges;
 			ti,hwmods = "ocp2scp_usb_phy";
+			clocks = <&ocp2scp_usb_phy_phy_48m>;
+			clock-names = "fck";
 			usb2_phy: usb2phy at 4a0ad080 {
 				compatible = "ti,omap-usb2";
 				reg = <0x4a0ad080 0x58>;
@@ -528,6 +600,8 @@
 			interrupts = <0 37 0x4>;
 			ti,hwmods = "timer1";
 			ti,timer-alwon;
+			clocks = <&dmt1_clk_mux>;
+			clock-names = "fck";
 		};
 
 		timer2: timer at 48032000 {
@@ -535,6 +609,8 @@
 			reg = <0x48032000 0x80>;
 			interrupts = <0 38 0x4>;
 			ti,hwmods = "timer2";
+			clocks = <&cm2_dm2_mux>;
+			clock-names = "fck";
 		};
 
 		timer3: timer at 48034000 {
@@ -542,6 +618,8 @@
 			reg = <0x48034000 0x80>;
 			interrupts = <0 39 0x4>;
 			ti,hwmods = "timer3";
+			clocks = <&cm2_dm3_mux>;
+			clock-names = "fck";
 		};
 
 		timer4: timer at 48036000 {
@@ -549,6 +627,8 @@
 			reg = <0x48036000 0x80>;
 			interrupts = <0 40 0x4>;
 			ti,hwmods = "timer4";
+			clocks = <&cm2_dm4_mux>;
+			clock-names = "fck";
 		};
 
 		timer5: timer at 40138000 {
@@ -558,6 +638,8 @@
 			interrupts = <0 41 0x4>;
 			ti,hwmods = "timer5";
 			ti,timer-dsp;
+			clocks = <&timer5_sync_mux>;
+			clock-names = "fck";
 		};
 
 		timer6: timer at 4013a000 {
@@ -567,6 +649,8 @@
 			interrupts = <0 42 0x4>;
 			ti,hwmods = "timer6";
 			ti,timer-dsp;
+			clocks = <&timer6_sync_mux>;
+			clock-names = "fck";
 		};
 
 		timer7: timer at 4013c000 {
@@ -576,6 +660,8 @@
 			interrupts = <0 43 0x4>;
 			ti,hwmods = "timer7";
 			ti,timer-dsp;
+			clocks = <&timer7_sync_mux>;
+			clock-names = "fck";
 		};
 
 		timer8: timer at 4013e000 {
@@ -586,6 +672,8 @@
 			ti,hwmods = "timer8";
 			ti,timer-pwm;
 			ti,timer-dsp;
+			clocks = <&timer8_sync_mux>;
+			clock-names = "fck";
 		};
 
 		timer9: timer at 4803e000 {
@@ -594,6 +682,8 @@
 			interrupts = <0 45 0x4>;
 			ti,hwmods = "timer9";
 			ti,timer-pwm;
+			clocks = <&cm2_dm9_mux>;
+			clock-names = "fck";
 		};
 
 		timer10: timer at 48086000 {
@@ -602,6 +692,8 @@
 			interrupts = <0 46 0x4>;
 			ti,hwmods = "timer10";
 			ti,timer-pwm;
+			clocks = <&cm2_dm10_mux>;
+			clock-names = "fck";
 		};
 
 		timer11: timer at 48088000 {
@@ -610,6 +702,8 @@
 			interrupts = <0 47 0x4>;
 			ti,hwmods = "timer11";
 			ti,timer-pwm;
+			clocks = <&cm2_dm11_mux>;
+			clock-names = "fck";
 		};
 
 		usbhstll: usbhstll at 4a062000 {
@@ -617,6 +711,8 @@
 			reg = <0x4a062000 0x1000>;
 			interrupts = <0 78 0x4>;
 			ti,hwmods = "usb_tll_hs";
+			clocks = <&usb_tll_hs_ick>;
+			clock-names = "fck";
 		};
 
 		usbhshost: usbhshost at 4a064000 {
@@ -626,6 +722,8 @@
 			#address-cells = <1>;
 			#size-cells = <1>;
 			ranges;
+			clocks = <&usb_host_hs_fck>;
+			clock-names = "fck";
 
 			usbhsohci: ohci at 4a064800 {
 				compatible = "ti,ohci-omap3", "usb-ohci";
@@ -661,6 +759,8 @@
 			num-eps = <16>;
 			ram-bits = <12>;
 			ti,has-mailbox;
+			clocks = <&usb_otg_hs_ick>;
+			clock-names = "fck";
 		};
 	};
 };
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 848b6dc..5ea01ea 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -419,7 +419,6 @@ static struct omap_hwmod omap44xx_counter_32k_hwmod = {
 	.class		= &omap44xx_counter_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
 	.flags		= HWMOD_SWSUP_SIDLE,
-	.main_clk	= "sys_32k_ck",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_WKUP_SYNCTIMER_CLKCTRL_OFFSET,
@@ -570,7 +569,6 @@ static struct omap_hwmod omap44xx_dma_system_hwmod = {
 	.class		= &omap44xx_dma_hwmod_class,
 	.clkdm_name	= "l3_dma_clkdm",
 	.mpu_irqs	= omap44xx_dma_system_irqs,
-	.main_clk	= "l3_div_ck",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_SDMA_SDMA_CLKCTRL_OFFSET,
@@ -617,7 +615,6 @@ static struct omap_hwmod omap44xx_dmic_hwmod = {
 	.clkdm_name	= "abe_clkdm",
 	.mpu_irqs	= omap44xx_dmic_irqs,
 	.sdma_reqs	= omap44xx_dmic_sdma_reqs,
-	.main_clk	= "func_dmic_abe_gfclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM1_ABE_DMIC_CLKCTRL_OFFSET,
@@ -1036,7 +1033,6 @@ static struct omap_hwmod omap44xx_emif1_hwmod = {
 	.clkdm_name	= "l3_emif_clkdm",
 	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
 	.mpu_irqs	= omap44xx_emif1_irqs,
-	.main_clk	= "ddrphy_ck",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_MEMIF_EMIF_1_CLKCTRL_OFFSET,
@@ -1058,7 +1054,6 @@ static struct omap_hwmod omap44xx_emif2_hwmod = {
 	.clkdm_name	= "l3_emif_clkdm",
 	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
 	.mpu_irqs	= omap44xx_emif2_irqs,
-	.main_clk	= "ddrphy_ck",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_MEMIF_EMIF_2_CLKCTRL_OFFSET,
@@ -1153,16 +1148,11 @@ static struct omap_hwmod_irq_info omap44xx_gpio1_irqs[] = {
 	{ .irq = -1 }
 };
 
-static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
-	{ .role = "dbclk", .clk = "gpio1_dbclk" },
-};
-
 static struct omap_hwmod omap44xx_gpio1_hwmod = {
 	.name		= "gpio1",
 	.class		= &omap44xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
 	.mpu_irqs	= omap44xx_gpio1_irqs,
-	.main_clk	= "l4_wkup_clk_mux_ck",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_WKUP_GPIO1_CLKCTRL_OFFSET,
@@ -1170,8 +1160,6 @@ static struct omap_hwmod omap44xx_gpio1_hwmod = {
 			.modulemode   = MODULEMODE_HWCTRL,
 		},
 	},
-	.opt_clks	= gpio1_opt_clks,
-	.opt_clks_cnt	= ARRAY_SIZE(gpio1_opt_clks),
 	.dev_attr	= &gpio_dev_attr,
 };
 
@@ -1181,17 +1169,12 @@ static struct omap_hwmod_irq_info omap44xx_gpio2_irqs[] = {
 	{ .irq = -1 }
 };
 
-static struct omap_hwmod_opt_clk gpio2_opt_clks[] = {
-	{ .role = "dbclk", .clk = "gpio2_dbclk" },
-};
-
 static struct omap_hwmod omap44xx_gpio2_hwmod = {
 	.name		= "gpio2",
 	.class		= &omap44xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
 	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
 	.mpu_irqs	= omap44xx_gpio2_irqs,
-	.main_clk	= "l4_div_ck",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_GPIO2_CLKCTRL_OFFSET,
@@ -1199,8 +1182,6 @@ static struct omap_hwmod omap44xx_gpio2_hwmod = {
 			.modulemode   = MODULEMODE_HWCTRL,
 		},
 	},
-	.opt_clks	= gpio2_opt_clks,
-	.opt_clks_cnt	= ARRAY_SIZE(gpio2_opt_clks),
 	.dev_attr	= &gpio_dev_attr,
 };
 
@@ -1210,17 +1191,12 @@ static struct omap_hwmod_irq_info omap44xx_gpio3_irqs[] = {
 	{ .irq = -1 }
 };
 
-static struct omap_hwmod_opt_clk gpio3_opt_clks[] = {
-	{ .role = "dbclk", .clk = "gpio3_dbclk" },
-};
-
 static struct omap_hwmod omap44xx_gpio3_hwmod = {
 	.name		= "gpio3",
 	.class		= &omap44xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
 	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
 	.mpu_irqs	= omap44xx_gpio3_irqs,
-	.main_clk	= "l4_div_ck",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_GPIO3_CLKCTRL_OFFSET,
@@ -1228,8 +1204,6 @@ static struct omap_hwmod omap44xx_gpio3_hwmod = {
 			.modulemode   = MODULEMODE_HWCTRL,
 		},
 	},
-	.opt_clks	= gpio3_opt_clks,
-	.opt_clks_cnt	= ARRAY_SIZE(gpio3_opt_clks),
 	.dev_attr	= &gpio_dev_attr,
 };
 
@@ -1239,17 +1213,12 @@ static struct omap_hwmod_irq_info omap44xx_gpio4_irqs[] = {
 	{ .irq = -1 }
 };
 
-static struct omap_hwmod_opt_clk gpio4_opt_clks[] = {
-	{ .role = "dbclk", .clk = "gpio4_dbclk" },
-};
-
 static struct omap_hwmod omap44xx_gpio4_hwmod = {
 	.name		= "gpio4",
 	.class		= &omap44xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
 	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
 	.mpu_irqs	= omap44xx_gpio4_irqs,
-	.main_clk	= "l4_div_ck",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_GPIO4_CLKCTRL_OFFSET,
@@ -1257,8 +1226,6 @@ static struct omap_hwmod omap44xx_gpio4_hwmod = {
 			.modulemode   = MODULEMODE_HWCTRL,
 		},
 	},
-	.opt_clks	= gpio4_opt_clks,
-	.opt_clks_cnt	= ARRAY_SIZE(gpio4_opt_clks),
 	.dev_attr	= &gpio_dev_attr,
 };
 
@@ -1268,17 +1235,12 @@ static struct omap_hwmod_irq_info omap44xx_gpio5_irqs[] = {
 	{ .irq = -1 }
 };
 
-static struct omap_hwmod_opt_clk gpio5_opt_clks[] = {
-	{ .role = "dbclk", .clk = "gpio5_dbclk" },
-};
-
 static struct omap_hwmod omap44xx_gpio5_hwmod = {
 	.name		= "gpio5",
 	.class		= &omap44xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
 	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
 	.mpu_irqs	= omap44xx_gpio5_irqs,
-	.main_clk	= "l4_div_ck",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_GPIO5_CLKCTRL_OFFSET,
@@ -1286,8 +1248,6 @@ static struct omap_hwmod omap44xx_gpio5_hwmod = {
 			.modulemode   = MODULEMODE_HWCTRL,
 		},
 	},
-	.opt_clks	= gpio5_opt_clks,
-	.opt_clks_cnt	= ARRAY_SIZE(gpio5_opt_clks),
 	.dev_attr	= &gpio_dev_attr,
 };
 
@@ -1297,17 +1257,12 @@ static struct omap_hwmod_irq_info omap44xx_gpio6_irqs[] = {
 	{ .irq = -1 }
 };
 
-static struct omap_hwmod_opt_clk gpio6_opt_clks[] = {
-	{ .role = "dbclk", .clk = "gpio6_dbclk" },
-};
-
 static struct omap_hwmod omap44xx_gpio6_hwmod = {
 	.name		= "gpio6",
 	.class		= &omap44xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
 	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
 	.mpu_irqs	= omap44xx_gpio6_irqs,
-	.main_clk	= "l4_div_ck",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_GPIO6_CLKCTRL_OFFSET,
@@ -1315,8 +1270,6 @@ static struct omap_hwmod omap44xx_gpio6_hwmod = {
 			.modulemode   = MODULEMODE_HWCTRL,
 		},
 	},
-	.opt_clks	= gpio6_opt_clks,
-	.opt_clks_cnt	= ARRAY_SIZE(gpio6_opt_clks),
 	.dev_attr	= &gpio_dev_attr,
 };
 
@@ -1551,7 +1504,6 @@ static struct omap_hwmod omap44xx_i2c1_hwmod = {
 	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
 	.mpu_irqs	= omap44xx_i2c1_irqs,
 	.sdma_reqs	= omap44xx_i2c1_sdma_reqs,
-	.main_clk	= "func_96m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_I2C1_CLKCTRL_OFFSET,
@@ -1581,7 +1533,6 @@ static struct omap_hwmod omap44xx_i2c2_hwmod = {
 	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
 	.mpu_irqs	= omap44xx_i2c2_irqs,
 	.sdma_reqs	= omap44xx_i2c2_sdma_reqs,
-	.main_clk	= "func_96m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_I2C2_CLKCTRL_OFFSET,
@@ -1611,7 +1562,6 @@ static struct omap_hwmod omap44xx_i2c3_hwmod = {
 	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
 	.mpu_irqs	= omap44xx_i2c3_irqs,
 	.sdma_reqs	= omap44xx_i2c3_sdma_reqs,
-	.main_clk	= "func_96m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_I2C3_CLKCTRL_OFFSET,
@@ -1641,7 +1591,6 @@ static struct omap_hwmod omap44xx_i2c4_hwmod = {
 	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
 	.mpu_irqs	= omap44xx_i2c4_irqs,
 	.sdma_reqs	= omap44xx_i2c4_sdma_reqs,
-	.main_clk	= "func_96m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_I2C4_CLKCTRL_OFFSET,
@@ -1830,7 +1779,6 @@ static struct omap_hwmod omap44xx_kbd_hwmod = {
 	.class		= &omap44xx_kbd_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
 	.mpu_irqs	= omap44xx_kbd_irqs,
-	.main_clk	= "sys_32k_ck",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_WKUP_KEYBOARD_CLKCTRL_OFFSET,
@@ -1962,18 +1910,12 @@ static struct omap_hwmod_dma_info omap44xx_mcbsp1_sdma_reqs[] = {
 	{ .dma_req = -1 }
 };
 
-static struct omap_hwmod_opt_clk mcbsp1_opt_clks[] = {
-	{ .role = "pad_fck", .clk = "pad_clks_ck" },
-	{ .role = "prcm_fck", .clk = "mcbsp1_sync_mux_ck" },
-};
-
 static struct omap_hwmod omap44xx_mcbsp1_hwmod = {
 	.name		= "mcbsp1",
 	.class		= &omap44xx_mcbsp_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
 	.mpu_irqs	= omap44xx_mcbsp1_irqs,
 	.sdma_reqs	= omap44xx_mcbsp1_sdma_reqs,
-	.main_clk	= "func_mcbsp1_gfclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM1_ABE_MCBSP1_CLKCTRL_OFFSET,
@@ -1981,8 +1923,6 @@ static struct omap_hwmod omap44xx_mcbsp1_hwmod = {
 			.modulemode   = MODULEMODE_SWCTRL,
 		},
 	},
-	.opt_clks	= mcbsp1_opt_clks,
-	.opt_clks_cnt	= ARRAY_SIZE(mcbsp1_opt_clks),
 };
 
 /* mcbsp2 */
@@ -1997,18 +1937,12 @@ static struct omap_hwmod_dma_info omap44xx_mcbsp2_sdma_reqs[] = {
 	{ .dma_req = -1 }
 };
 
-static struct omap_hwmod_opt_clk mcbsp2_opt_clks[] = {
-	{ .role = "pad_fck", .clk = "pad_clks_ck" },
-	{ .role = "prcm_fck", .clk = "mcbsp2_sync_mux_ck" },
-};
-
 static struct omap_hwmod omap44xx_mcbsp2_hwmod = {
 	.name		= "mcbsp2",
 	.class		= &omap44xx_mcbsp_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
 	.mpu_irqs	= omap44xx_mcbsp2_irqs,
 	.sdma_reqs	= omap44xx_mcbsp2_sdma_reqs,
-	.main_clk	= "func_mcbsp2_gfclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM1_ABE_MCBSP2_CLKCTRL_OFFSET,
@@ -2016,8 +1950,6 @@ static struct omap_hwmod omap44xx_mcbsp2_hwmod = {
 			.modulemode   = MODULEMODE_SWCTRL,
 		},
 	},
-	.opt_clks	= mcbsp2_opt_clks,
-	.opt_clks_cnt	= ARRAY_SIZE(mcbsp2_opt_clks),
 };
 
 /* mcbsp3 */
@@ -2032,18 +1964,12 @@ static struct omap_hwmod_dma_info omap44xx_mcbsp3_sdma_reqs[] = {
 	{ .dma_req = -1 }
 };
 
-static struct omap_hwmod_opt_clk mcbsp3_opt_clks[] = {
-	{ .role = "pad_fck", .clk = "pad_clks_ck" },
-	{ .role = "prcm_fck", .clk = "mcbsp3_sync_mux_ck" },
-};
-
 static struct omap_hwmod omap44xx_mcbsp3_hwmod = {
 	.name		= "mcbsp3",
 	.class		= &omap44xx_mcbsp_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
 	.mpu_irqs	= omap44xx_mcbsp3_irqs,
 	.sdma_reqs	= omap44xx_mcbsp3_sdma_reqs,
-	.main_clk	= "func_mcbsp3_gfclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM1_ABE_MCBSP3_CLKCTRL_OFFSET,
@@ -2051,8 +1977,6 @@ static struct omap_hwmod omap44xx_mcbsp3_hwmod = {
 			.modulemode   = MODULEMODE_SWCTRL,
 		},
 	},
-	.opt_clks	= mcbsp3_opt_clks,
-	.opt_clks_cnt	= ARRAY_SIZE(mcbsp3_opt_clks),
 };
 
 /* mcbsp4 */
@@ -2067,11 +1991,6 @@ static struct omap_hwmod_dma_info omap44xx_mcbsp4_sdma_reqs[] = {
 	{ .dma_req = -1 }
 };
 
-static struct omap_hwmod_opt_clk mcbsp4_opt_clks[] = {
-	{ .role = "pad_fck", .clk = "pad_clks_ck" },
-	{ .role = "prcm_fck", .clk = "mcbsp4_sync_mux_ck" },
-};
-
 static struct omap_hwmod omap44xx_mcbsp4_hwmod = {
 	.name		= "mcbsp4",
 	.class		= &omap44xx_mcbsp_hwmod_class,
@@ -2086,8 +2005,6 @@ static struct omap_hwmod omap44xx_mcbsp4_hwmod = {
 			.modulemode   = MODULEMODE_SWCTRL,
 		},
 	},
-	.opt_clks	= mcbsp4_opt_clks,
-	.opt_clks_cnt	= ARRAY_SIZE(mcbsp4_opt_clks),
 };
 
 /*
@@ -2141,7 +2058,6 @@ static struct omap_hwmod omap44xx_mcpdm_hwmod = {
 	.flags		= HWMOD_EXT_OPT_MAIN_CLK | HWMOD_SWSUP_SIDLE,
 	.mpu_irqs	= omap44xx_mcpdm_irqs,
 	.sdma_reqs	= omap44xx_mcpdm_sdma_reqs,
-	.main_clk	= "pad_clks_ck",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM1_ABE_PDM_CLKCTRL_OFFSET,
@@ -2202,7 +2118,6 @@ static struct omap_hwmod omap44xx_mcspi1_hwmod = {
 	.clkdm_name	= "l4_per_clkdm",
 	.mpu_irqs	= omap44xx_mcspi1_irqs,
 	.sdma_reqs	= omap44xx_mcspi1_sdma_reqs,
-	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_MCSPI1_CLKCTRL_OFFSET,
@@ -2238,7 +2153,6 @@ static struct omap_hwmod omap44xx_mcspi2_hwmod = {
 	.clkdm_name	= "l4_per_clkdm",
 	.mpu_irqs	= omap44xx_mcspi2_irqs,
 	.sdma_reqs	= omap44xx_mcspi2_sdma_reqs,
-	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_MCSPI2_CLKCTRL_OFFSET,
@@ -2274,7 +2188,6 @@ static struct omap_hwmod omap44xx_mcspi3_hwmod = {
 	.clkdm_name	= "l4_per_clkdm",
 	.mpu_irqs	= omap44xx_mcspi3_irqs,
 	.sdma_reqs	= omap44xx_mcspi3_sdma_reqs,
-	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_MCSPI3_CLKCTRL_OFFSET,
@@ -2308,7 +2221,6 @@ static struct omap_hwmod omap44xx_mcspi4_hwmod = {
 	.clkdm_name	= "l4_per_clkdm",
 	.mpu_irqs	= omap44xx_mcspi4_irqs,
 	.sdma_reqs	= omap44xx_mcspi4_sdma_reqs,
-	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_MCSPI4_CLKCTRL_OFFSET,
@@ -2364,7 +2276,6 @@ static struct omap_hwmod omap44xx_mmc1_hwmod = {
 	.clkdm_name	= "l3_init_clkdm",
 	.mpu_irqs	= omap44xx_mmc1_irqs,
 	.sdma_reqs	= omap44xx_mmc1_sdma_reqs,
-	.main_clk	= "hsmmc1_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L3INIT_MMC1_CLKCTRL_OFFSET,
@@ -2393,7 +2304,6 @@ static struct omap_hwmod omap44xx_mmc2_hwmod = {
 	.clkdm_name	= "l3_init_clkdm",
 	.mpu_irqs	= omap44xx_mmc2_irqs,
 	.sdma_reqs	= omap44xx_mmc2_sdma_reqs,
-	.main_clk	= "hsmmc2_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L3INIT_MMC2_CLKCTRL_OFFSET,
@@ -2421,7 +2331,6 @@ static struct omap_hwmod omap44xx_mmc3_hwmod = {
 	.clkdm_name	= "l4_per_clkdm",
 	.mpu_irqs	= omap44xx_mmc3_irqs,
 	.sdma_reqs	= omap44xx_mmc3_sdma_reqs,
-	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_MMCSD3_CLKCTRL_OFFSET,
@@ -2449,7 +2358,6 @@ static struct omap_hwmod omap44xx_mmc4_hwmod = {
 	.clkdm_name	= "l4_per_clkdm",
 	.mpu_irqs	= omap44xx_mmc4_irqs,
 	.sdma_reqs	= omap44xx_mmc4_sdma_reqs,
-	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_MMCSD4_CLKCTRL_OFFSET,
@@ -2477,7 +2385,6 @@ static struct omap_hwmod omap44xx_mmc5_hwmod = {
 	.clkdm_name	= "l4_per_clkdm",
 	.mpu_irqs	= omap44xx_mmc5_irqs,
 	.sdma_reqs	= omap44xx_mmc5_sdma_reqs,
-	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_MMCSD5_CLKCTRL_OFFSET,
@@ -2729,7 +2636,6 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
 	 * So listing ocp2scp_usb_phy_phy_48m as a main_clk here seems
 	 * to be the best workaround.
 	 */
-	.main_clk	= "ocp2scp_usb_phy_phy_48m",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL_OFFSET,
@@ -3189,7 +3095,6 @@ static struct omap_hwmod omap44xx_timer2_hwmod = {
 	.clkdm_name	= "l4_per_clkdm",
 	.flags		= HWMOD_SET_DEFAULT_CLOCKACT,
 	.mpu_irqs	= omap44xx_timer2_irqs,
-	.main_clk	= "cm2_dm2_mux",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_DMTIMER2_CLKCTRL_OFFSET,
@@ -3210,7 +3115,6 @@ static struct omap_hwmod omap44xx_timer3_hwmod = {
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
 	.mpu_irqs	= omap44xx_timer3_irqs,
-	.main_clk	= "cm2_dm3_mux",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_DMTIMER3_CLKCTRL_OFFSET,
@@ -3231,7 +3135,6 @@ static struct omap_hwmod omap44xx_timer4_hwmod = {
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
 	.mpu_irqs	= omap44xx_timer4_irqs,
-	.main_clk	= "cm2_dm4_mux",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_DMTIMER4_CLKCTRL_OFFSET,
@@ -3252,7 +3155,6 @@ static struct omap_hwmod omap44xx_timer5_hwmod = {
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
 	.mpu_irqs	= omap44xx_timer5_irqs,
-	.main_clk	= "timer5_sync_mux",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM1_ABE_TIMER5_CLKCTRL_OFFSET,
@@ -3274,7 +3176,6 @@ static struct omap_hwmod omap44xx_timer6_hwmod = {
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
 	.mpu_irqs	= omap44xx_timer6_irqs,
-	.main_clk	= "timer6_sync_mux",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM1_ABE_TIMER6_CLKCTRL_OFFSET,
@@ -3296,7 +3197,6 @@ static struct omap_hwmod omap44xx_timer7_hwmod = {
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
 	.mpu_irqs	= omap44xx_timer7_irqs,
-	.main_clk	= "timer7_sync_mux",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM1_ABE_TIMER7_CLKCTRL_OFFSET,
@@ -3318,7 +3218,6 @@ static struct omap_hwmod omap44xx_timer8_hwmod = {
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
 	.mpu_irqs	= omap44xx_timer8_irqs,
-	.main_clk	= "timer8_sync_mux",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM1_ABE_TIMER8_CLKCTRL_OFFSET,
@@ -3340,7 +3239,6 @@ static struct omap_hwmod omap44xx_timer9_hwmod = {
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
 	.mpu_irqs	= omap44xx_timer9_irqs,
-	.main_clk	= "cm2_dm9_mux",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_DMTIMER9_CLKCTRL_OFFSET,
@@ -3363,7 +3261,6 @@ static struct omap_hwmod omap44xx_timer10_hwmod = {
 	.clkdm_name	= "l4_per_clkdm",
 	.flags		= HWMOD_SET_DEFAULT_CLOCKACT,
 	.mpu_irqs	= omap44xx_timer10_irqs,
-	.main_clk	= "cm2_dm10_mux",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_DMTIMER10_CLKCTRL_OFFSET,
@@ -3385,7 +3282,6 @@ static struct omap_hwmod omap44xx_timer11_hwmod = {
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
 	.mpu_irqs	= omap44xx_timer11_irqs,
-	.main_clk	= "cm2_dm11_mux",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_DMTIMER11_CLKCTRL_OFFSET,
@@ -3437,7 +3333,6 @@ static struct omap_hwmod omap44xx_uart1_hwmod = {
 	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.mpu_irqs	= omap44xx_uart1_irqs,
 	.sdma_reqs	= omap44xx_uart1_sdma_reqs,
-	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_UART1_CLKCTRL_OFFSET,
@@ -3466,7 +3361,6 @@ static struct omap_hwmod omap44xx_uart2_hwmod = {
 	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.mpu_irqs	= omap44xx_uart2_irqs,
 	.sdma_reqs	= omap44xx_uart2_sdma_reqs,
-	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_UART2_CLKCTRL_OFFSET,
@@ -3496,7 +3390,6 @@ static struct omap_hwmod omap44xx_uart3_hwmod = {
 				HWMOD_SWSUP_SIDLE_ACT,
 	.mpu_irqs	= omap44xx_uart3_irqs,
 	.sdma_reqs	= omap44xx_uart3_sdma_reqs,
-	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_UART3_CLKCTRL_OFFSET,
@@ -3525,7 +3418,6 @@ static struct omap_hwmod omap44xx_uart4_hwmod = {
 	.flags		= HWMOD_SWSUP_SIDLE_ACT,
 	.mpu_irqs	= omap44xx_uart4_irqs,
 	.sdma_reqs	= omap44xx_uart4_sdma_reqs,
-	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_UART4_CLKCTRL_OFFSET,
@@ -3617,7 +3509,6 @@ static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
 	.name		= "usb_host_hs",
 	.class		= &omap44xx_usb_host_hs_hwmod_class,
 	.clkdm_name	= "l3_init_clkdm",
-	.main_clk	= "usb_host_hs_fck",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET,
@@ -3716,7 +3607,6 @@ static struct omap_hwmod omap44xx_usb_otg_hs_hwmod = {
 	.clkdm_name	= "l3_init_clkdm",
 	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
 	.mpu_irqs	= omap44xx_usb_otg_hs_irqs,
-	.main_clk	= "usb_otg_hs_ick",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L3INIT_USB_OTG_CLKCTRL_OFFSET,
@@ -3759,7 +3649,6 @@ static struct omap_hwmod omap44xx_usb_tll_hs_hwmod = {
 	.class		= &omap44xx_usb_tll_hs_hwmod_class,
 	.clkdm_name	= "l3_init_clkdm",
 	.mpu_irqs	= omap44xx_usb_tll_hs_irqs,
-	.main_clk	= "usb_tll_hs_ick",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L3INIT_USB_TLL_CLKCTRL_OFFSET,
@@ -3804,7 +3693,6 @@ static struct omap_hwmod omap44xx_wd_timer2_hwmod = {
 	.class		= &omap44xx_wd_timer_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
 	.mpu_irqs	= omap44xx_wd_timer2_irqs,
-	.main_clk	= "sys_32k_ck",
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_WKUP_WDT2_CLKCTRL_OFFSET,
-- 
1.7.9.5



From lars at metafoo.de  Tue Jul 23 02:41:40 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Tue, 23 Jul 2013 08:41:40 +0200
Subject: [PATCH 1/3] dmaengine: add dma_get_slave_sg_limits()
In-Reply-To: <51EDA80F.7060606@ti.com>
References: <1374166001-31340-1-git-send-email-joelf@ti.com>
 <1374166001-31340-2-git-send-email-joelf@ti.com>
 <20130718161658.GW16653@intel.com> <51EDA80F.7060606@ti.com>
Message-ID: <51EE25A4.7000609@metafoo.de>

On 07/22/2013 11:45 PM, Joel Fernandes wrote:
> On 07/18/2013 11:16 AM, Vinod Koul wrote:> On Thu, Jul 18, 2013 at
> 11:46:39AM -0500, Joel Fernandes wrote:
>>> From: Matt Porter <mporter at ti.com>
>>>
>>> Add a dmaengine API to retrieve slave SG transfer limits.
>>>
>>> The API is optionally implemented by dmaengine drivers and when
>>> unimplemented will return a NULL pointer. A client driver using
>>> this API provides the required dma channel, address width, and
>>> burst size of the transfer. dma_get_slave_sg_limits() returns an
>>> SG limits structure with the maximum number and size of SG segments
>>> that the given channel can handle.
>> Hi Joel,
>>
>> I have already resurrected this and generalized the API to get the slave
>> capablities.
>> https://lkml.org/lkml/2013/7/15/147
>
> Hi Vinod,
>
> get_caps and get_sg_limits are 2 different things, looks like this was
> already discussed earlier, and this patch series is a separate API that
> adds support for SG limits.
>
> Infact, you can already see here that he changed the name of the
> function from caps to dma_get_slave_sg_limits:
> http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2013-March/026601.html
>

And it was changed back, since we need to provide more information than just 
the sg limits. So the name didn't fit anymore. The dma_get_slave_caps() API 
patch was based on the dma_get_slave_sg_limits() patch.

> Considering this, what is the way forward? Can this patch series be
> merged as it is a different API as discussed above?
>
> Summarizing:
> * get_caps API cannot be used for this same purpose, as get_caps is done
> _before_ the DMA channel can be configured from what it looks like:
> * get_sg_limits, on the other hand is supposed to already have the
> parameters required for configuring the DMA channel before hand.
>
> Are there any other changes to the get_sg_limits series you would like
> before it can be applied? Any other suggestions?

If you need to calculate the limit based on a certain configuration I'd suggest 
to add a optional dma_slave_config parameter to the dma_slave_get_caps() function.

- Lars



From joelf at ti.com  Tue Jul 23 02:50:00 2013
From: joelf at ti.com (Joel Fernandes)
Date: Tue, 23 Jul 2013 01:50:00 -0500
Subject: [PATCH 1/3] dmaengine: add dma_get_slave_sg_limits()
In-Reply-To: <51EE25A4.7000609@metafoo.de>
References: <1374166001-31340-1-git-send-email-joelf@ti.com>
 <1374166001-31340-2-git-send-email-joelf@ti.com>
 <20130718161658.GW16653@intel.com> <51EDA80F.7060606@ti.com>
 <51EE25A4.7000609@metafoo.de>
Message-ID: <51EE2798.9020008@ti.com>

On 07/23/2013 01:41 AM, Lars-Peter Clausen wrote:
> On 07/22/2013 11:45 PM, Joel Fernandes wrote:
>> On 07/18/2013 11:16 AM, Vinod Koul wrote:> On Thu, Jul 18, 2013 at
>> 11:46:39AM -0500, Joel Fernandes wrote:
>>>> From: Matt Porter <mporter at ti.com>
>>>>
>>>> Add a dmaengine API to retrieve slave SG transfer limits.
>>>>
>>>> The API is optionally implemented by dmaengine drivers and when
>>>> unimplemented will return a NULL pointer. A client driver using
>>>> this API provides the required dma channel, address width, and
>>>> burst size of the transfer. dma_get_slave_sg_limits() returns an
>>>> SG limits structure with the maximum number and size of SG segments
>>>> that the given channel can handle.
>>> Hi Joel,
>>>
>>> I have already resurrected this and generalized the API to get the slave
>>> capablities.
>>> https://lkml.org/lkml/2013/7/15/147
>>
>> Hi Vinod,
>>
>> get_caps and get_sg_limits are 2 different things, looks like this was
>> already discussed earlier, and this patch series is a separate API that
>> adds support for SG limits.
>>
>> Infact, you can already see here that he changed the name of the
>> function from caps to dma_get_slave_sg_limits:
>> http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2013-March/026601.html
>>
>>
> 
> And it was changed back, since we need to provide more information than
> just the sg limits. So the name didn't fit anymore. The
> dma_get_slave_caps() API patch was based on the
> dma_get_slave_sg_limits() patch.

Well including the functionality together with it doesn't seem to solve
the problem, but correct me if I'm wrong..

The only I have with get_slave_caps is due to the other additional
information it provides like "addr widths allowed" etc.. it seems that
it should called *before* the channel configuration. Is this not true?

If that's the case then we can't use it, because we want a caps API that
can be called either after a channel is configured or the available
address widths are already known..

So the flow would go something like:
1. Determine address widths, etc before hand (driver already knows..)
2. Configure the channel or store this info somewhere.
3. Pass this information to get_caps and the max segment size which is
calculated by the get_caps implementation based on the data passed in 1.

So 3. depends on 1.
Is that an acceptable use? If semantically we can use it as above then
I'm ok.. we will just ignore the extra "possible widths" and other info
stored in get_caps..

-Joel

> 
>> Considering this, what is the way forward? Can this patch series be
>> merged as it is a different API as discussed above?
>>
>> Summarizing:
>> * get_caps API cannot be used for this same purpose, as get_caps is done
>> _before_ the DMA channel can be configured from what it looks like:
>> * get_sg_limits, on the other hand is supposed to already have the
>> parameters required for configuring the DMA channel before hand.
>>
>> Are there any other changes to the get_sg_limits series you would like
>> before it can be applied? Any other suggestions?
> 
> If you need to calculate the limit based on a certain configuration I'd
> suggest to add a optional dma_slave_config parameter to the
> dma_slave_get_caps() function.
> 
> - Lars
> 


-- 
Thanks,

-Joel


From rnayak at ti.com  Tue Jul 23 03:03:03 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 23 Jul 2013 12:33:03 +0530
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
Message-ID: <51EE2AA7.5060503@ti.com>

On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
> 
>> Bear in mind that I'm almost at the point of not boot-testing anything
>> I sent to Linus because of the uselessness of the SDP4430 board now
>> that it's DT only - the only platform which boot-tests anything I send
>> is the 3430LDP board now.  If people care about that, maybe they can
>> assist with sorting out the issues I've raised on these lists about
>> the SDP4430 - and why the SDP4430 build remains disabled in my build
>> and boot system.
> 
> I understand completely...
> 
>> Looking at the boot log, it just stops after uboot hands over control.
>> With the lack of output from the decompressor, it's not possible to
>> tell whether it's a decompressor problem or a kernel problem.
>>
>> I think you need to turn on the LL_DEBUG option, select the appropriate
>> output option, and also get the decompressor to use the kernel's debug
>> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
> 
> OK, will dig deeper here at the next opportunity.

Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
2430sdp as the subject says, or was that a typo?

> 
> 
> - Paul
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 



From paul at pwsan.com  Tue Jul 23 03:04:29 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 23 Jul 2013 07:04:29 +0000 (UTC)
Subject: [PATCH] ARM: Do not run dummy_flush_tlb_a15_erratum() on
 non-Cortex-A15
In-Reply-To: <1374556774-18795-1-git-send-email-festevam@gmail.com>
References: <1374556774-18795-1-git-send-email-festevam@gmail.com>
Message-ID: <alpine.DEB.2.02.1307230659430.27017@utopia.booyaka.com>

On Tue, 23 Jul 2013, Fabio Estevam wrote:

> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Commit 93dc688 (ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 
> (TLBI/DSB operations)) causes the following undefined instruction error on a
> mx53 (Cortex-A8):
> 
> Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> CPU: 0 PID: 275 Comm: modprobe Not tainted 3.11.0-rc2-next-20130722-00009-g9b0f371 #881
> task: df46cc00 ti: df48e000 task.ti: df48e000
> PC is at check_and_switch_context+0x17c/0x4d0
> LR is at check_and_switch_context+0xdc/0x4d0
> 
> This problem happens because check_and_switch_context() calls 
> dummy_flush_tlb_a15_erratum() without checking if we are really running on a 
> Cortex-A15 or not. 
> 
> To avoid this issue, always check if we are running on a Cortex-A15 or not 
> (via erratum_a15_798181()) inside dummy_flush_tlb_a15_erratum(), so that we do 
> not need to keep doing the same check in all occurrences of 
> dummy_flush_tlb_a15_erratum().
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Nice work.  This fixes the v3.11-rc boot regression on most OMAP3/AM33xx 
devices.

Tested-by: Paul Walmsley <paul at pwsan.com> # for OMAP2,3,4,AM33xx



- Paul


From paul at pwsan.com  Tue Jul 23 03:07:31 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 23 Jul 2013 07:07:31 +0000 (UTC)
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <51EE2AA7.5060503@ti.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
Message-ID: <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>

Hi Rajendra,

On Tue, 23 Jul 2013, Rajendra Nayak wrote:

> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
> > On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
> > 
> >> Bear in mind that I'm almost at the point of not boot-testing anything
> >> I sent to Linus because of the uselessness of the SDP4430 board now
> >> that it's DT only - the only platform which boot-tests anything I send
> >> is the 3430LDP board now.  If people care about that, maybe they can
> >> assist with sorting out the issues I've raised on these lists about
> >> the SDP4430 - and why the SDP4430 build remains disabled in my build
> >> and boot system.
> > 
> > I understand completely...
> > 
> >> Looking at the boot log, it just stops after uboot hands over control.
> >> With the lack of output from the decompressor, it's not possible to
> >> tell whether it's a decompressor problem or a kernel problem.
> >>
> >> I think you need to turn on the LL_DEBUG option, select the appropriate
> >> output option, and also get the decompressor to use the kernel's debug
> >> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
> > 
> > OK, will dig deeper here at the next opportunity.
> 
> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
> 2430sdp as the subject says, or was that a typo?

Thanks for the offer.  The issue that I'm seeing is on the 2430SDP in my 
testbed.

I don't have a 4430SDP, so you might consider touching base with rmk for 
that one.


- Paul


From t-kristo at ti.com  Tue Jul 23 03:19:55 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:19:55 +0300
Subject: [PATCHv4 00/33] ARM: OMAP: clock conversion to DT
Message-ID: <1374564028-11352-1-git-send-email-t-kristo@ti.com>

Hi,

Changes compared to previous version:

- Clock init files moved from mach-omap2/ to drivers/clk/omap/
- AM33xx support added [patches 15-20]
- OMAP3 support added [patches 21-29]
- DRA7 APLL support added (thanks Keerthy) [patches 30-33]

Test branch on top of 3.11-rc1 available here:

git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.11-rc1-omap-dt-clks

Testing done:

- boot + suspend tested on OMAP3 beagle C4 (omap3530)
- boot + suspend tested on OMAP4 panda ES (omap4460)
- boot tested on beagle bone (am335x)

A boot test was also executed for DRA7 and OMAP5 on a separate branch
(mainline does not have OMAP5 / DRA7 support so far.)

TODO:
- Add AM35xx support (OMAP3 derivative, AM35xx only clock nodes missing)

Overall diffstat added just for fun:

 arch/arm/boot/dts/am33xx-clocks.dtsi               |  663 ++++
 arch/arm/boot/dts/am33xx.dtsi                      |    7 +
 arch/arm/boot/dts/dra7xx-clocks.dtsi               | 2113 ++++++++++++
 arch/arm/boot/dts/omap3.dtsi                       |    7 +
 arch/arm/boot/dts/omap3430es1-clocks.dtsi          |  166 +
 arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi    |  240 ++
 arch/arm/boot/dts/omap34xx.dtsi                    |    9 +
 .../omap36xx-am35xx-omap3430es2plus-clocks.dtsi    |  214 ++
 arch/arm/boot/dts/omap36xx-clocks.dtsi             |   97 +
 .../boot/dts/omap36xx-omap3430es2plus-clocks.dtsi  |  185 +
 arch/arm/boot/dts/omap36xx.dtsi                    |   10 +
 arch/arm/boot/dts/omap3xxx-clocks.dtsi             | 1594 +++++++++
 arch/arm/boot/dts/omap443x-clocks.dtsi             |   17 +
 arch/arm/boot/dts/omap443x.dtsi                    |    8 +
 arch/arm/boot/dts/omap4460.dtsi                    |    8 +
 arch/arm/boot/dts/omap446x-clocks.dtsi             |   27 +
 arch/arm/boot/dts/omap44xx-clocks.dtsi             | 1654 +++++++++
 arch/arm/boot/dts/omap54xx-clocks.dtsi             | 1416 ++++++++
 arch/arm/mach-omap2/Makefile                       |    5 +-
 arch/arm/mach-omap2/cclock33xx_data.c              | 1059 ------
 arch/arm/mach-omap2/cclock3xxx_data.c              | 3641 --------------------
 arch/arm/mach-omap2/cclock44xx_data.c              | 1730 ----------
 arch/arm/mach-omap2/clock.c                        |    6 +
 arch/arm/mach-omap2/clock.h                        |  163 +-
 arch/arm/mach-omap2/clock3xxx.h                    |    7 +-
 arch/arm/mach-omap2/io.c                           |    7 +-
 arch/arm/mach-omap2/omap_hwmod.c                   |    5 +-
 drivers/clk/Makefile                               |    1 +
 drivers/clk/clk-divider.c                          |    6 +-
 drivers/clk/clk-fixed-factor.c                     |    6 +-
 drivers/clk/clk-gate.c                             |    8 +-
 drivers/clk/clk-mux.c                              |    6 +-
 drivers/clk/clkdev.c                               |   32 +
 drivers/clk/omap/Makefile                          |    4 +
 drivers/clk/omap/apll.c                            |  213 ++
 drivers/clk/omap/autoidle.c                        |  130 +
 drivers/clk/omap/clk-33xx.c                        |   85 +
 drivers/clk/omap/clk-3xxx.c                        |  171 +
 drivers/clk/omap/clk-44xx.c                        |  118 +
 drivers/clk/omap/clk-54xx.c                        |   58 +
 drivers/clk/omap/clk-7xx.c                         |   67 +
 drivers/clk/omap/clk.c                             |   84 +
 drivers/clk/omap/dpll.c                            |  387 +++
 drivers/clk/omap/gate.c                            |  166 +
 drivers/clk/omap/interface.c                       |  110 +
 include/linux/clk/omap.h                           |  223 ++
 46 files changed, 10327 insertions(+), 6606 deletions(-)

-Tero



From t-kristo at ti.com  Tue Jul 23 03:19:56 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:19:56 +0300
Subject: [PATCHv4 01/33] CLK: clkdev: add support for looking up clocks from DT
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-2-git-send-email-t-kristo@ti.com>

clk_get_sys / clk_get can now find clocks from device-tree. If a DT clock
is found, an entry is added to the clk_lookup list also for subsequent
searches.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
Cc: Russell King <linux at arm.linux.org.uk>
---
 drivers/clk/clkdev.c |   32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..e39f082 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -93,6 +93,18 @@ struct clk *of_clk_get_by_name(struct device_node *np, const char *name)
 EXPORT_SYMBOL(of_clk_get_by_name);
 #endif
 
+/**
+ * clkdev_add_nolock - add lookup entry for a clock
+ * @cl: pointer to new clock lookup entry
+ *
+ * Non-locking version, used internally by clk_find() to add DT based
+ * clock lookup entries.
+ */
+static void clkdev_add_nolock(struct clk_lookup *cl)
+{
+	list_add_tail(&cl->node, &clocks);
+}
+
 /*
  * Find the correct struct clk for the device and connection ID.
  * We do slightly fuzzy matching here:
@@ -106,6 +118,9 @@ static struct clk_lookup *clk_find(const char *dev_id, const char *con_id)
 {
 	struct clk_lookup *p, *cl = NULL;
 	int match, best_found = 0, best_possible = 0;
+	struct device_node *node;
+	struct clk *clk;
+	struct of_phandle_args clkspec;
 
 	if (dev_id)
 		best_possible += 2;
@@ -133,6 +148,23 @@ static struct clk_lookup *clk_find(const char *dev_id, const char *con_id)
 				break;
 		}
 	}
+
+	if (cl)
+		return cl;
+
+	/* If clock was not found, attempt to look-up from DT */
+	node = of_find_node_by_name(NULL, con_id);
+
+	clkspec.np = node;
+
+	clk = of_clk_get_from_provider(&clkspec);
+
+	if (!IS_ERR(clk)) {
+		/* We found a clock, add node to clkdev */
+		cl = clkdev_alloc(clk, con_id, dev_id);
+		clkdev_add_nolock(cl);
+	}
+
 	return cl;
 }
 
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:19:57 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:19:57 +0300
Subject: [PATCHv4 02/33] clk: omap: introduce clock driver
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-3-git-send-email-t-kristo@ti.com>

Parses OMAP clock data from DT and registers those clocks with the clock
framework.  dt_omap_clk_init must be called early during boot for timer
initialization so it is exported and called from the existing clock code
instead of probing like a real driver. Based on initial work done by
Mike Turquette.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
Cc: Mike Turquette <mturquette at linaro.org>
---
 drivers/clk/Makefile      |    1 +
 drivers/clk/omap/Makefile |    1 +
 drivers/clk/omap/clk.c    |   39 +++++++++++++++++++++++++++++++++++++++
 include/linux/clk/omap.h  |   24 ++++++++++++++++++++++++
 4 files changed, 65 insertions(+)
 create mode 100644 drivers/clk/omap/Makefile
 create mode 100644 drivers/clk/omap/clk.c
 create mode 100644 include/linux/clk/omap.h

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4038c2b..d3c3733 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500.o
 obj-$(CONFIG_ARCH_ZYNQ)		+= zynq/
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
 obj-$(CONFIG_PLAT_SAMSUNG)	+= samsung/
+obj-$(CONFIG_ARCH_OMAP)		+= omap/
 
 obj-$(CONFIG_X86)		+= x86/
 
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 0000000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y					+= clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 0000000..4bf1929
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,39 @@
+/*
+ * OMAP PRCM clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *     Tero Kristo <t-kristo at ti.com>
+ *     Mike Turquette <mturquette at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clk/omap.h>
+#include <linux/kernel.h>
+#include <linux/of_device.h>
+
+/* FIXME - should the OMAP PRCM clock driver match generic types? */
+static const struct of_device_id clk_match[] = {
+	{.compatible = "fixed-clock", .data = of_fixed_clk_setup, },
+	{.compatible = "mux-clock", .data = of_mux_clk_setup, },
+	{.compatible = "fixed-factor-clock",
+		.data = of_fixed_factor_clk_setup, },
+	{.compatible = "divider-clock", .data = of_divider_clk_setup, },
+	{.compatible = "gate-clock", .data = of_gate_clk_setup, },
+	{},
+};
+
+/* FIXME - need to initialize early; skip real driver registration & probe */
+int __init dt_omap_clk_init(void)
+{
+	of_clk_init(clk_match);
+	return 0;
+}
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
new file mode 100644
index 0000000..647f02f
--- /dev/null
+++ b/include/linux/clk/omap.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#ifndef __LINUX_CLK_OMAP_H_
+#define __LINUX_CLK_OMAP_H_
+
+int __init dt_omap_clk_init(void);
+
+#endif
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:19:58 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:19:58 +0300
Subject: [PATCHv4 03/33] CLK: OMAP4: Add DPLL clock support
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-4-git-send-email-t-kristo@ti.com>

The OMAP clock driver now supports DPLL clock type. This patch also
adds support for DT DPLL nodes.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 drivers/clk/omap/Makefile |    2 +-
 drivers/clk/omap/clk.c    |    1 +
 drivers/clk/omap/dpll.c   |  295 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 297 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/omap/dpll.c

diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 8195931..4cad480 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y					+= clk.o
+obj-y					+= clk.o dpll.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index 4bf1929..1dafdaa 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -28,6 +28,7 @@ static const struct of_device_id clk_match[] = {
 		.data = of_fixed_factor_clk_setup, },
 	{.compatible = "divider-clock", .data = of_divider_clk_setup, },
 	{.compatible = "gate-clock", .data = of_gate_clk_setup, },
+	{.compatible = "ti,omap4-dpll-clock", .data = of_omap4_dpll_setup, },
 	{},
 };
 
diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
new file mode 100644
index 0000000..66e82be
--- /dev/null
+++ b/drivers/clk/omap/dpll.c
@@ -0,0 +1,295 @@
+/*
+ * OMAP DPLL clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo <t-kristo at ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/string.h>
+#include <linux/log2.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/clk/omap.h>
+
+static const struct clk_ops dpll_m4xen_ck_ops = {
+	.enable		= &omap3_noncore_dpll_enable,
+	.disable	= &omap3_noncore_dpll_disable,
+	.recalc_rate	= &omap4_dpll_regm4xen_recalc,
+	.round_rate	= &omap4_dpll_regm4xen_round_rate,
+	.set_rate	= &omap3_noncore_dpll_set_rate,
+	.get_parent	= &omap2_init_dpll_parent,
+};
+
+static const struct clk_ops dpll_core_ck_ops = {
+	.recalc_rate	= &omap3_dpll_recalc,
+	.get_parent	= &omap2_init_dpll_parent,
+};
+
+static const struct clk_ops dpll_ck_ops = {
+	.enable		= &omap3_noncore_dpll_enable,
+	.disable	= &omap3_noncore_dpll_disable,
+	.recalc_rate	= &omap3_dpll_recalc,
+	.round_rate	= &omap2_dpll_round_rate,
+	.set_rate	= &omap3_noncore_dpll_set_rate,
+	.get_parent	= &omap2_init_dpll_parent,
+	.init		= &omap2_init_clk_clkdm,
+};
+
+static const struct clk_ops dpll_x2_ck_ops = {
+	.recalc_rate	= &omap3_clkoutx2_recalc,
+};
+
+struct clk *omap_clk_register_dpll(struct device *dev, const char *name,
+		const char **parent_names, int num_parents, unsigned long flags,
+		struct dpll_data *dpll_data, const char *clkdm_name,
+		const struct clk_ops *ops)
+{
+	struct clk *clk;
+	struct clk_init_data init;
+	struct clk_hw_omap *clk_hw;
+
+	/* allocate the divider */
+	clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+	if (!clk_hw) {
+		pr_err("%s: could not allocate clk_hw_omap\n", __func__);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	clk_hw->dpll_data = dpll_data;
+	clk_hw->ops = &clkhwops_omap3_dpll;
+	clk_hw->clkdm_name = clkdm_name;
+	clk_hw->hw.init = &init;
+
+	init.name = name;
+	init.ops = ops;
+	init.flags = flags;
+	init.parent_names = parent_names;
+	init.num_parents = num_parents;
+
+	/* register the clock */
+	clk = clk_register(dev, &clk_hw->hw);
+
+	if (IS_ERR(clk))
+		kfree(clk_hw);
+	else
+		omap2_init_clk_hw_omap_clocks(clk);
+
+	return clk;
+}
+
+struct clk *omap_clk_register_dpll_x2(struct device *dev, const char *name,
+		const char *parent_name, void __iomem *reg,
+		const struct clk_ops *ops)
+{
+	struct clk *clk;
+	struct clk_init_data init;
+	struct clk_hw_omap *clk_hw;
+
+	if (!parent_name) {
+		pr_err("%s: dpll_x2 must have parent\n", __func__);
+		return ERR_PTR(-EINVAL);
+	}
+
+	clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+	if (!clk_hw) {
+		pr_err("%s: could not allocate clk_hw_omap\n", __func__);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	clk_hw->ops = &clkhwops_omap4_dpllmx;
+	clk_hw->clksel_reg = reg;
+	clk_hw->hw.init = &init;
+
+	init.name = name;
+	init.ops = ops;
+	init.parent_names = &parent_name;
+	init.num_parents = 1;
+
+	/* register the clock */
+	clk = clk_register(dev, &clk_hw->hw);
+
+	if (IS_ERR(clk))
+		kfree(clk_hw);
+	else
+		omap2_init_clk_hw_omap_clocks(clk);
+
+	return clk;
+}
+
+#ifdef CONFIG_OF
+
+/**
+ * of_omap_dpll_setup() - Setup function for OMAP DPLL clocks
+ */
+static void __init of_omap_dpll_setup(struct device_node *node,
+					const struct clk_ops *ops)
+{
+	struct clk *clk;
+	const char *clk_name = node->name;
+	int num_parents;
+	const char **parent_names;
+	const char *clkdm_name = NULL;
+	struct of_phandle_args clkspec;
+	u8 dpll_flags = 0;
+	struct dpll_data *dd;
+	u32 idlest_mask = 0x1;
+	u32 enable_mask = 0x7;
+	u32 autoidle_mask = 0x7;
+	u32 mult_mask = 0x7ff << 8;
+	u32 div1_mask = 0x7f;
+	u32 max_multiplier = 2047;
+	u32 max_divider = 128;
+	u32 min_divider = 1;
+	int i;
+
+	dd = kzalloc(sizeof(struct dpll_data), GFP_KERNEL);
+	if (!dd) {
+		pr_err("%s: could not allocate dpll_data\n", __func__);
+		return;
+	}
+
+	of_property_read_string(node, "clock-output-names", &clk_name);
+
+	num_parents = of_clk_get_parent_count(node);
+	if (num_parents < 1) {
+		pr_err("%s: omap dpll %s must have parent(s)\n",
+			__func__, node->name);
+		goto cleanup;
+	}
+
+	parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
+
+	for (i = 0; i < num_parents; i++)
+		parent_names[i] = of_clk_get_parent_name(node, i);
+
+	of_property_read_u32(node, "ti,idlest-mask", &idlest_mask);
+
+	of_property_read_u32(node, "ti,enable-mask", &enable_mask);
+
+	of_property_read_u32(node, "ti,autoidle-mask", &autoidle_mask);
+
+	clkspec.np = of_parse_phandle(node, "ti,clk-ref", 0);
+	dd->clk_ref = of_clk_get_from_provider(&clkspec);
+	if (!dd->clk_ref) {
+		pr_err("%s: ti,clk-ref for %s not found\n", __func__,
+			clk_name);
+		goto cleanup;
+	}
+
+	clkspec.np = of_parse_phandle(node, "ti,clk-bypass", 0);
+	dd->clk_bypass = of_clk_get_from_provider(&clkspec);
+	if (!dd->clk_bypass) {
+		pr_err("%s: ti,clk-bypass for %s not found\n", __func__,
+			clk_name);
+		goto cleanup;
+	}
+
+	of_property_read_string(node, "ti,clkdm-name", &clkdm_name);
+
+	dd->control_reg = of_iomap(node, 0);
+	dd->idlest_reg = of_iomap(node, 1);
+	dd->autoidle_reg = of_iomap(node, 2);
+	dd->mult_div1_reg = of_iomap(node, 3);
+
+	dd->idlest_mask = idlest_mask;
+	dd->enable_mask = enable_mask;
+	dd->autoidle_mask = autoidle_mask;
+
+	dd->modes = 0xa0;
+
+	if (of_property_read_bool(node, "ti,dpll-j-type")) {
+		dd->sddiv_mask = 0xff000000;
+		mult_mask = 0xfff << 8;
+		div1_mask = 0xff;
+		max_multiplier = 4095;
+		max_divider = 256;
+	}
+
+	if (of_property_read_bool(node, "ti,dpll-regm4xen")) {
+		dd->m4xen_mask = 0x800;
+		dd->lpmode_mask = 1 << 10;
+	}
+
+	dd->mult_mask = mult_mask;
+	dd->div1_mask = div1_mask;
+	dd->max_multiplier = max_multiplier;
+	dd->max_divider = max_divider;
+	dd->min_divider = min_divider;
+
+	clk = omap_clk_register_dpll(NULL, clk_name, parent_names,
+				num_parents, dpll_flags, dd,
+				clkdm_name, ops);
+
+	if (!IS_ERR(clk))
+		of_clk_add_provider(node, of_clk_src_simple_get, clk);
+	return;
+
+cleanup:
+	kfree(dd);
+	return;
+}
+
+static void __init of_omap_dpll_x2_setup(struct device_node *node)
+{
+	struct clk *clk;
+	const char *clk_name = node->name;
+	void __iomem *reg;
+	const char *parent_name;
+
+	of_property_read_string(node, "clock-output-names", &clk_name);
+
+	parent_name = of_clk_get_parent_name(node, 0);
+
+	reg = of_iomap(node, 0);
+
+	clk = omap_clk_register_dpll_x2(NULL, clk_name, parent_name,
+				reg, &dpll_x2_ck_ops);
+
+	if (!IS_ERR(clk))
+		of_clk_add_provider(node, of_clk_src_simple_get, clk);
+}
+
+__init void of_omap3_dpll_setup(struct device_node *node)
+{
+	/* XXX: to be done */
+}
+EXPORT_SYMBOL_GPL(of_omap3_dpll_setup);
+CLK_OF_DECLARE(omap3_dpll_clock, "ti,omap3-dpll-clock", of_omap3_dpll_setup);
+
+__init void of_omap4_dpll_setup(struct device_node *node)
+{
+	const struct clk_ops *ops;
+
+	ops = &dpll_ck_ops;
+
+	if (of_property_read_bool(node, "ti,dpll-regm4xen"))
+		ops = &dpll_m4xen_ck_ops;
+
+	if (of_property_read_bool(node, "ti,dpll-core"))
+		ops = &dpll_core_ck_ops;
+
+	if (of_property_read_bool(node, "ti,dpll-clk-x2")) {
+		of_omap_dpll_x2_setup(node);
+		return;
+	}
+
+	of_omap_dpll_setup(node, ops);
+}
+EXPORT_SYMBOL_GPL(of_omap4_dpll_setup);
+CLK_OF_DECLARE(omap4_dpll_clock, "ti,omap4-dpll-clock", of_omap4_dpll_setup);
+#endif
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:00 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:00 +0300
Subject: [PATCHv4 05/33] CLK: omap: add DT duplicate clock registration
 mechanism
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-6-git-send-email-t-kristo@ti.com>

Some devices require their clocks to be available with a specific
dev-id con-id mapping. With DT, the clocks can be found by default
only with their name, or alternatively through the device node of
the consumer. With drivers, that don't support DT fully yet, add
mechanism to register specific clock names.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 drivers/clk/omap/clk.c   |   39 +++++++++++++++++++++++++++++++++++++++
 include/linux/clk/omap.h |   17 +++++++++++++++++
 2 files changed, 56 insertions(+)

diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index 1dafdaa..cd31a81 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -32,6 +32,45 @@ static const struct of_device_id clk_match[] = {
 	{},
 };
 
+ /**
+ * omap_dt_clocks_register - register DT duplicate clocks during boot
+ * @oclks: list of clocks to register
+ * @cnt: number of clocks
+ *
+ * Register duplicate or non-standard DT clock entries during boot. By
+ * default, DT clocks are found based on their node name. If any
+ * additional con-id / dev-id -> clock mapping is required, use this
+ * function to list these.
+ */
+void __init omap_dt_clocks_register(struct omap_dt_clk oclks[], int cnt)
+{
+	struct omap_dt_clk *c;
+	struct device_node *n;
+	struct clk *clk;
+	struct of_phandle_args clkspec;
+
+	for (c = oclks; c < oclks + cnt; c++) {
+		n = of_find_node_by_name(NULL, c->node_name);
+
+		if (!n) {
+			pr_err("%s: %s not found!\n", __func__, c->node_name);
+			continue;
+		}
+
+		clkspec.np = n;
+
+		clk = of_clk_get_from_provider(&clkspec);
+
+		if (!clk) {
+			pr_err("%s: %s has no clock!\n", __func__,
+				c->node_name);
+			continue;
+		}
+		c->lk.clk = clk;
+		clkdev_add(&c->lk);
+	}
+}
+
 /* FIXME - need to initialize early; skip real driver registration & probe */
 int __init dt_omap_clk_init(void)
 {
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
index cba892a..c39e775 100644
--- a/include/linux/clk/omap.h
+++ b/include/linux/clk/omap.h
@@ -19,6 +19,8 @@
 #ifndef __LINUX_CLK_OMAP_H_
 #define __LINUX_CLK_OMAP_H_
 
+#include <linux/clkdev.h>
+
 /**
  * struct dpll_data - DPLL registers and integration data
  * @mult_div1_reg: register containing the DPLL M and N bitfields
@@ -146,6 +148,20 @@ struct clk_hw_omap_ops {
 	void			(*deny_idle)(struct clk_hw_omap *oclk);
 };
 
+struct omap_dt_clk {
+	struct clk_lookup		lk;
+	const char			*node_name;
+};
+
+#define DT_CLK(dev, con, name)		\
+	{				\
+		.lk = {			\
+			.dev_id = dev,	\
+			.con_id = con,	\
+		},			\
+		.node_name = name,	\
+	}
+
 void omap2_init_clk_hw_omap_clocks(struct clk *clk);
 int omap3_noncore_dpll_enable(struct clk_hw *hw);
 void omap3_noncore_dpll_disable(struct clk_hw *hw);
@@ -174,6 +190,7 @@ extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx;
 
 /* DT functions */
 int dt_omap_clk_init(void);
+extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int cnt);
 void of_omap4_dpll_setup(struct device_node *node);
 
 #endif
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:01 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:01 +0300
Subject: [PATCHv4 06/33] CLK: omap: add autoidle support
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-7-git-send-email-t-kristo@ti.com>

OMAP clk driver now routes some of the basic clocks through own
registration routine to allow autoidle support. This routine just
checks a couple of device node properties and adds autoidle support
if required, and just passes the registration forward to basic clocks.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 arch/arm/mach-omap2/clock.c |    6 ++
 drivers/clk/omap/Makefile   |    2 +-
 drivers/clk/omap/autoidle.c |  130 +++++++++++++++++++++++++++++++++++++++++++
 drivers/clk/omap/clk.c      |    4 +-
 include/linux/clk/omap.h    |    4 ++
 5 files changed, 143 insertions(+), 3 deletions(-)
 create mode 100644 drivers/clk/omap/autoidle.c

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 0c38ca9..669d4c4 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -520,6 +520,9 @@ int omap2_clk_enable_autoidle_all(void)
 	list_for_each_entry(c, &clk_hw_omap_clocks, node)
 		if (c->ops && c->ops->allow_idle)
 			c->ops->allow_idle(c);
+
+	of_omap_clk_allow_autoidle_all();
+
 	return 0;
 }
 
@@ -539,6 +542,9 @@ int omap2_clk_disable_autoidle_all(void)
 	list_for_each_entry(c, &clk_hw_omap_clocks, node)
 		if (c->ops && c->ops->deny_idle)
 			c->ops->deny_idle(c);
+
+	of_omap_clk_deny_autoidle_all();
+
 	return 0;
 }
 
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 4cad480..ca56700 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y					+= clk.o dpll.o
+obj-y					+= clk.o dpll.o autoidle.o
diff --git a/drivers/clk/omap/autoidle.c b/drivers/clk/omap/autoidle.c
new file mode 100644
index 0000000..6424cb2
--- /dev/null
+++ b/drivers/clk/omap/autoidle.c
@@ -0,0 +1,130 @@
+/*
+ * OMAP clock autoidle support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo <t-kristo at ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/string.h>
+#include <linux/log2.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+#ifdef CONFIG_OF
+struct clk_omap_autoidle {
+	void __iomem		*reg;
+	u8			shift;
+	u8			flags;
+	const char		*name;
+	struct list_head	node;
+};
+
+#define AUTOIDLE_LOW		0x1
+
+static LIST_HEAD(autoidle_clks);
+
+static void omap_allow_autoidle(struct clk_omap_autoidle *clk)
+{
+	u32 val;
+
+	val = readl(clk->reg);
+
+	if (clk->flags & AUTOIDLE_LOW)
+		val &= ~(1 << clk->shift);
+	else
+		val |= (1 << clk->shift);
+
+	writel(val, clk->reg);
+}
+
+static void omap_deny_autoidle(struct clk_omap_autoidle *clk)
+{
+	u32 val;
+
+	val = readl(clk->reg);
+
+	if (clk->flags & AUTOIDLE_LOW)
+		val |= (1 << clk->shift);
+	else
+		val &= ~(1 << clk->shift);
+
+	writel(val, clk->reg);
+}
+
+void of_omap_clk_allow_autoidle_all(void)
+{
+	struct clk_omap_autoidle *c;
+
+	list_for_each_entry(c, &autoidle_clks, node)
+		omap_allow_autoidle(c);
+}
+
+void of_omap_clk_deny_autoidle_all(void)
+{
+	struct clk_omap_autoidle *c;
+
+	list_for_each_entry(c, &autoidle_clks, node)
+		omap_deny_autoidle(c);
+}
+
+static __init void of_omap_autoidle_setup(struct device_node *node)
+{
+	u32 shift;
+	void __iomem *reg;
+	struct clk_omap_autoidle *clk;
+
+	if (of_property_read_u32(node, "ti,autoidle-shift", &shift))
+		return;
+
+	reg = of_iomap(node, 0);
+
+	clk = kzalloc(sizeof(struct clk_omap_autoidle), GFP_KERNEL);
+
+	if (!clk) {
+		pr_err("%s: kzalloc failed\n", __func__);
+		return;
+	}
+
+	clk->shift = shift;
+	clk->name = node->name;
+	clk->reg = reg;
+
+	if (of_property_read_bool(node, "ti,autoidle-low"))
+		clk->flags |= AUTOIDLE_LOW;
+
+	list_add(&clk->node, &autoidle_clks);
+}
+
+void __init of_omap_divider_setup(struct device_node *node)
+{
+	of_divider_clk_setup(node);
+	of_omap_autoidle_setup(node);
+}
+EXPORT_SYMBOL_GPL(of_omap_divider_setup);
+CLK_OF_DECLARE(omap_autoidle_clock, "divider-clock", of_omap_divider_setup);
+
+void __init of_omap_fixed_factor_setup(struct device_node *node)
+{
+	of_fixed_factor_clk_setup(node);
+	of_omap_autoidle_setup(node);
+}
+EXPORT_SYMBOL_GPL(of_omap_fixed_factor_setup);
+CLK_OF_DECLARE(omap_fixed_factor_clock, "fixed-factor-clock",
+	of_omap_fixed_factor_setup);
+
+#endif
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index cd31a81..c149097 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -25,8 +25,8 @@ static const struct of_device_id clk_match[] = {
 	{.compatible = "fixed-clock", .data = of_fixed_clk_setup, },
 	{.compatible = "mux-clock", .data = of_mux_clk_setup, },
 	{.compatible = "fixed-factor-clock",
-		.data = of_fixed_factor_clk_setup, },
-	{.compatible = "divider-clock", .data = of_divider_clk_setup, },
+		.data = of_omap_fixed_factor_setup, },
+	{.compatible = "divider-clock", .data = of_omap_divider_setup, },
 	{.compatible = "gate-clock", .data = of_gate_clk_setup, },
 	{.compatible = "ti,omap4-dpll-clock", .data = of_omap4_dpll_setup, },
 	{},
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
index c39e775..904bdad 100644
--- a/include/linux/clk/omap.h
+++ b/include/linux/clk/omap.h
@@ -192,5 +192,9 @@ extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx;
 int dt_omap_clk_init(void);
 extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int cnt);
 void of_omap4_dpll_setup(struct device_node *node);
+void of_omap_fixed_factor_setup(struct device_node *node);
+void of_omap_divider_setup(struct device_node *node);
+void of_omap_clk_allow_autoidle_all(void);
+void of_omap_clk_deny_autoidle_all(void);
 
 #endif
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:02 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:02 +0300
Subject: [PATCHv4 07/33] CLK: omap: add support for OMAP gate clock
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-8-git-send-email-t-kristo@ti.com>

This node adds support for a clock node which allows control to the
clockdomain enable / disable.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 drivers/clk/omap/Makefile |    2 +-
 drivers/clk/omap/clk.c    |    1 +
 drivers/clk/omap/gate.c   |   88 +++++++++++++++++++++++++++++++++++++++++++++
 include/linux/clk/omap.h  |    1 +
 4 files changed, 91 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/omap/gate.c

diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index ca56700..3d3ca30f 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y					+= clk.o dpll.o autoidle.o
+obj-y					+= clk.o dpll.o autoidle.o gate.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index c149097..8c89714 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -29,6 +29,7 @@ static const struct of_device_id clk_match[] = {
 	{.compatible = "divider-clock", .data = of_omap_divider_setup, },
 	{.compatible = "gate-clock", .data = of_gate_clk_setup, },
 	{.compatible = "ti,omap4-dpll-clock", .data = of_omap4_dpll_setup, },
+	{.compatible = "ti,gate-clock", .data = of_omap_gate_clk_setup, },
 	{},
 };
 
diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
new file mode 100644
index 0000000..7186bb2
--- /dev/null
+++ b/drivers/clk/omap/gate.c
@@ -0,0 +1,88 @@
+/*
+ * OMAP gate clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo <t-kristo at ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/string.h>
+#include <linux/log2.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/clk/omap.h>
+
+#ifdef CONFIG_OF
+
+static const struct clk_ops omap_gate_clk_ops = {
+	.init		= &omap2_init_clk_clkdm,
+	.enable		= &omap2_clkops_enable_clkdm,
+	.disable	= &omap2_clkops_disable_clkdm,
+};
+
+void __init of_omap_gate_clk_setup(struct device_node *node)
+{
+	struct clk *clk;
+	struct clk_init_data init;
+	struct clk_hw_omap *clk_hw;
+	const char *clk_name = node->name;
+	int num_parents;
+	const char **parent_names;
+	int i;
+
+	clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+	if (!clk_hw) {
+		pr_err("%s: could not allocate clk_hw_omap\n", __func__);
+		return;
+	}
+
+	clk_hw->hw.init = &init;
+
+	of_property_read_string(node, "clock-output-names", &clk_name);
+	of_property_read_string(node, "ti,clkdm-name", &clk_hw->clkdm_name);
+
+	init.name = clk_name;
+	init.ops = &omap_gate_clk_ops;
+
+	num_parents = of_clk_get_parent_count(node);
+	if (num_parents < 1) {
+		pr_err("%s: omap trace_clk %s must have parent(s)\n",
+			__func__, node->name);
+		goto cleanup;
+	}
+
+	parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
+
+	for (i = 0; i < num_parents; i++)
+		parent_names[i] = of_clk_get_parent_name(node, i);
+
+	init.num_parents = num_parents;
+	init.parent_names = parent_names;
+
+	clk = clk_register(NULL, &clk_hw->hw);
+
+	if (!IS_ERR(clk)) {
+		of_clk_add_provider(node, of_clk_src_simple_get, clk);
+		return;
+	}
+
+cleanup:
+	kfree(clk_hw);
+}
+EXPORT_SYMBOL(of_omap_gate_clk_setup);
+CLK_OF_DECLARE(omap_gate_clk, "ti,omap-gate-clock", of_omap_gate_clk_setup);
+#endif
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
index 904bdad..58ebb80 100644
--- a/include/linux/clk/omap.h
+++ b/include/linux/clk/omap.h
@@ -194,6 +194,7 @@ extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int cnt);
 void of_omap4_dpll_setup(struct device_node *node);
 void of_omap_fixed_factor_setup(struct device_node *node);
 void of_omap_divider_setup(struct device_node *node);
+void of_omap_gate_clk_setup(struct device_node *node);
 void of_omap_clk_allow_autoidle_all(void);
 void of_omap_clk_deny_autoidle_all(void);
 
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:19:59 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:19:59 +0300
Subject: [PATCHv4 04/33] CLK: omap: move part of the machine specific clock
 header contents to driver
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-5-git-send-email-t-kristo@ti.com>

Some of the clock.h contents are needed by the new OMAP clock driver,
including dpll_data and clk_hw_omap. Thus, move these to the generic
omap header file which can be accessed by the driver.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 arch/arm/mach-omap2/clock.h |  151 +----------------------------------------
 include/linux/clk/omap.h    |  157 ++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 157 insertions(+), 151 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 7aa32cd..d1a3125 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -21,6 +21,7 @@
 
 #include <linux/clkdev.h>
 #include <linux/clk-provider.h>
+#include <linux/clk/omap.h>
 
 struct omap_clk {
 	u16				cpu;
@@ -178,83 +179,6 @@ struct clksel {
 	const struct clksel_rate *rates;
 };
 
-/**
- * struct dpll_data - DPLL registers and integration data
- * @mult_div1_reg: register containing the DPLL M and N bitfields
- * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg
- * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg
- * @clk_bypass: struct clk pointer to the clock's bypass clock input
- * @clk_ref: struct clk pointer to the clock's reference clock input
- * @control_reg: register containing the DPLL mode bitfield
- * @enable_mask: mask of the DPLL mode bitfield in @control_reg
- * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate()
- * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate()
- * @last_rounded_m4xen: cache of the last M4X result of
- *			omap4_dpll_regm4xen_round_rate()
- * @last_rounded_lpmode: cache of the last lpmode result of
- *			 omap4_dpll_lpmode_recalc()
- * @max_multiplier: maximum valid non-bypass multiplier value (actual)
- * @last_rounded_n: cache of the last N result of omap2_dpll_round_rate()
- * @min_divider: minimum valid non-bypass divider value (actual)
- * @max_divider: maximum valid non-bypass divider value (actual)
- * @modes: possible values of @enable_mask
- * @autoidle_reg: register containing the DPLL autoidle mode bitfield
- * @idlest_reg: register containing the DPLL idle status bitfield
- * @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg
- * @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg
- * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg
- * @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg
- * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg
- * @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg
- * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs
- * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs
- * @flags: DPLL type/features (see below)
- *
- * Possible values for @flags:
- * DPLL_J_TYPE: "J-type DPLL" (only some 36xx, 4xxx DPLLs)
- *
- * @freqsel_mask is only used on the OMAP34xx family and AM35xx.
- *
- * XXX Some DPLLs have multiple bypass inputs, so it's not technically
- * correct to only have one @clk_bypass pointer.
- *
- * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m,
- * @last_rounded_n) should be separated from the runtime-fixed fields
- * and placed into a different structure, so that the runtime-fixed data
- * can be placed into read-only space.
- */
-struct dpll_data {
-	void __iomem		*mult_div1_reg;
-	u32			mult_mask;
-	u32			div1_mask;
-	struct clk		*clk_bypass;
-	struct clk		*clk_ref;
-	void __iomem		*control_reg;
-	u32			enable_mask;
-	unsigned long		last_rounded_rate;
-	u16			last_rounded_m;
-	u8			last_rounded_m4xen;
-	u8			last_rounded_lpmode;
-	u16			max_multiplier;
-	u8			last_rounded_n;
-	u8			min_divider;
-	u16			max_divider;
-	u8			modes;
-	void __iomem		*autoidle_reg;
-	void __iomem		*idlest_reg;
-	u32			autoidle_mask;
-	u32			freqsel_mask;
-	u32			idlest_mask;
-	u32			dco_mask;
-	u32			sddiv_mask;
-	u32			lpmode_mask;
-	u32			m4xen_mask;
-	u8			auto_recal_bit;
-	u8			recal_en_bit;
-	u8			recal_st_bit;
-	u8			flags;
-};
-
 /*
  * struct clk.flags possibilities
  *
@@ -274,56 +198,6 @@ struct dpll_data {
 #define INVERT_ENABLE		(1 << 4)	/* 0 enables, 1 disables */
 #define CLOCK_CLKOUTX2		(1 << 5)
 
-/**
- * struct clk_hw_omap - OMAP struct clk
- * @node: list_head connecting this clock into the full clock list
- * @enable_reg: register to write to enable the clock (see @enable_bit)
- * @enable_bit: bitshift to write to enable/disable the clock (see @enable_reg)
- * @flags: see "struct clk.flags possibilities" above
- * @clksel_reg: for clksel clks, register va containing src/divisor select
- * @clksel_mask: bitmask in @clksel_reg for the src/divisor selector
- * @clksel: for clksel clks, pointer to struct clksel for this clock
- * @dpll_data: for DPLLs, pointer to struct dpll_data for this clock
- * @clkdm_name: clockdomain name that this clock is contained in
- * @clkdm: pointer to struct clockdomain, resolved from @clkdm_name at runtime
- * @rate_offset: bitshift for rate selection bitfield (OMAP1 only)
- * @src_offset: bitshift for source selection bitfield (OMAP1 only)
- *
- * XXX @rate_offset, @src_offset should probably be removed and OMAP1
- * clock code converted to use clksel.
- *
- */
-
-struct clk_hw_omap_ops;
-
-struct clk_hw_omap {
-	struct clk_hw		hw;
-	struct list_head	node;
-	unsigned long		fixed_rate;
-	u8			fixed_div;
-	void __iomem		*enable_reg;
-	u8			enable_bit;
-	u8			flags;
-	void __iomem		*clksel_reg;
-	u32			clksel_mask;
-	const struct clksel	*clksel;
-	struct dpll_data	*dpll_data;
-	const char		*clkdm_name;
-	struct clockdomain	*clkdm;
-	const struct clk_hw_omap_ops	*ops;
-};
-
-struct clk_hw_omap_ops {
-	void			(*find_idlest)(struct clk_hw_omap *oclk,
-					void __iomem **idlest_reg,
-					u8 *idlest_bit, u8 *idlest_val);
-	void			(*find_companion)(struct clk_hw_omap *oclk,
-					void __iomem **other_reg,
-					u8 *other_bit);
-	void			(*allow_idle)(struct clk_hw_omap *oclk);
-	void			(*deny_idle)(struct clk_hw_omap *oclk);
-};
-
 unsigned long omap_fixed_divisor_recalc(struct clk_hw *hw,
 					unsigned long parent_rate);
 
@@ -356,28 +230,13 @@ unsigned long omap_fixed_divisor_recalc(struct clk_hw *hw,
 /* DPLL Type and DCO Selection Flags */
 #define DPLL_J_TYPE		0x1
 
-long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
-			unsigned long *parent_rate);
-unsigned long omap3_dpll_recalc(struct clk_hw *hw, unsigned long parent_rate);
-int omap3_noncore_dpll_enable(struct clk_hw *hw);
-void omap3_noncore_dpll_disable(struct clk_hw *hw);
-int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned long rate,
-				unsigned long parent_rate);
 u32 omap3_dpll_autoidle_read(struct clk_hw_omap *clk);
 void omap3_dpll_allow_idle(struct clk_hw_omap *clk);
 void omap3_dpll_deny_idle(struct clk_hw_omap *clk);
-unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
-				    unsigned long parent_rate);
 int omap4_dpllmx_gatectrl_read(struct clk_hw_omap *clk);
 void omap4_dpllmx_allow_gatectrl(struct clk_hw_omap *clk);
 void omap4_dpllmx_deny_gatectrl(struct clk_hw_omap *clk);
-unsigned long omap4_dpll_regm4xen_recalc(struct clk_hw *hw,
-				unsigned long parent_rate);
-long omap4_dpll_regm4xen_round_rate(struct clk_hw *hw,
-				    unsigned long target_rate,
-				    unsigned long *parent_rate);
 
-void omap2_init_clk_clkdm(struct clk_hw *clk);
 void __init omap2_clk_disable_clkdm_control(void);
 
 /* clkt_clksel.c public functions */
@@ -396,7 +255,6 @@ int omap2_clksel_set_parent(struct clk_hw *hw, u8 field_val);
 extern void omap2_clkt_iclk_allow_idle(struct clk_hw_omap *clk);
 extern void omap2_clkt_iclk_deny_idle(struct clk_hw_omap *clk);
 
-u8 omap2_init_dpll_parent(struct clk_hw *hw);
 unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk);
 
 int omap2_dflt_clk_enable(struct clk_hw *hw);
@@ -408,9 +266,7 @@ void omap2_clk_dflt_find_companion(struct clk_hw_omap *clk,
 void omap2_clk_dflt_find_idlest(struct clk_hw_omap *clk,
 				void __iomem **idlest_reg,
 				u8 *idlest_bit, u8 *idlest_val);
-void omap2_init_clk_hw_omap_clocks(struct clk *clk);
 int omap2_clk_enable_autoidle_all(void);
-int omap2_clk_disable_autoidle_all(void);
 void omap2_clk_enable_init_clocks(const char **clk_names, u8 num_clocks);
 int omap2_clk_switch_mpurate_at_boot(const char *mpurate_ck_name);
 void omap2_clk_print_new_rates(const char *hfclkin_ck_name,
@@ -431,10 +287,8 @@ extern const struct clksel_rate gfx_l3_rates[];
 extern const struct clksel_rate dsp_ick_rates[];
 extern struct clk dummy_ck;
 
-extern const struct clk_hw_omap_ops clkhwops_omap3_dpll;
 extern const struct clk_hw_omap_ops clkhwops_iclk_wait;
 extern const struct clk_hw_omap_ops clkhwops_wait;
-extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx;
 extern const struct clk_hw_omap_ops clkhwops_iclk;
 extern const struct clk_hw_omap_ops clkhwops_omap3430es2_ssi_wait;
 extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_ssi_wait;
@@ -460,8 +314,5 @@ extern const struct clksel_rate div31_1to31_rates[];
 
 extern int am33xx_clk_init(void);
 
-extern int omap2_clkops_enable_clkdm(struct clk_hw *hw);
-extern void omap2_clkops_disable_clkdm(struct clk_hw *hw);
-
 extern void omap_clocks_register(struct omap_clk *oclks, int cnt);
 #endif
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
index 647f02f..cba892a 100644
--- a/include/linux/clk/omap.h
+++ b/include/linux/clk/omap.h
@@ -19,6 +19,161 @@
 #ifndef __LINUX_CLK_OMAP_H_
 #define __LINUX_CLK_OMAP_H_
 
-int __init dt_omap_clk_init(void);
+/**
+ * struct dpll_data - DPLL registers and integration data
+ * @mult_div1_reg: register containing the DPLL M and N bitfields
+ * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg
+ * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg
+ * @clk_bypass: struct clk pointer to the clock's bypass clock input
+ * @clk_ref: struct clk pointer to the clock's reference clock input
+ * @control_reg: register containing the DPLL mode bitfield
+ * @enable_mask: mask of the DPLL mode bitfield in @control_reg
+ * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate()
+ * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate()
+ * @last_rounded_m4xen: cache of the last M4X result of
+ *                     omap4_dpll_regm4xen_round_rate()
+ * @last_rounded_lpmode: cache of the last lpmode result of
+ *                      omap4_dpll_lpmode_recalc()
+ * @max_multiplier: maximum valid non-bypass multiplier value (actual)
+ * @last_rounded_n: cache of the last N result of omap2_dpll_round_rate()
+ * @min_divider: minimum valid non-bypass divider value (actual)
+ * @max_divider: maximum valid non-bypass divider value (actual)
+ * @modes: possible values of @enable_mask
+ * @autoidle_reg: register containing the DPLL autoidle mode bitfield
+ * @idlest_reg: register containing the DPLL idle status bitfield
+ * @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg
+ * @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg
+ * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg
+ * @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg
+ * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg
+ * @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg
+ * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs
+ * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs
+ * @flags: DPLL type/features (see below)
+ *
+ * Possible values for @flags:
+ * DPLL_J_TYPE: "J-type DPLL" (only some 36xx, 4xxx DPLLs)
+ *
+ * @freqsel_mask is only used on the OMAP34xx family and AM35xx.
+ *
+ * XXX Some DPLLs have multiple bypass inputs, so it's not technically
+ * correct to only have one @clk_bypass pointer.
+ *
+ * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m,
+ * @last_rounded_n) should be separated from the runtime-fixed fields
+ * and placed into a different structure, so that the runtime-fixed data
+ * can be placed into read-only space.
+ */
+struct dpll_data {
+	void __iomem		*mult_div1_reg;
+	u32			mult_mask;
+	u32			div1_mask;
+	struct clk		*clk_bypass;
+	struct clk		*clk_ref;
+	void __iomem		*control_reg;
+	u32			enable_mask;
+	unsigned long		last_rounded_rate;
+	u16			last_rounded_m;
+	u8			last_rounded_m4xen;
+	u8			last_rounded_lpmode;
+	u16			max_multiplier;
+	u8			last_rounded_n;
+	u8			min_divider;
+	u16			max_divider;
+	u8			modes;
+	void __iomem		*autoidle_reg;
+	void __iomem		*idlest_reg;
+	u32			autoidle_mask;
+	u32			freqsel_mask;
+	u32			idlest_mask;
+	u32			dco_mask;
+	u32			sddiv_mask;
+	u32			lpmode_mask;
+	u32			m4xen_mask;
+	u8			auto_recal_bit;
+	u8			recal_en_bit;
+	u8			recal_st_bit;
+	u8			flags;
+};
+
+/**
+ * struct clk_hw_omap - OMAP struct clk
+ * @node: list_head connecting this clock into the full clock list
+ * @enable_reg: register to write to enable the clock (see @enable_bit)
+ * @enable_bit: bitshift to write to enable/disable the clock (see @enable_reg)
+ * @flags: see "struct clk.flags possibilities" above
+ * @clksel_reg: for clksel clks, register va containing src/divisor select
+ * @clksel_mask: bitmask in @clksel_reg for the src/divisor selector
+ * @clksel: for clksel clks, pointer to struct clksel for this clock
+ * @dpll_data: for DPLLs, pointer to struct dpll_data for this clock
+ * @clkdm_name: clockdomain name that this clock is contained in
+ * @clkdm: pointer to struct clockdomain, resolved from @clkdm_name at runtime
+ * @rate_offset: bitshift for rate selection bitfield (OMAP1 only)
+ * @src_offset: bitshift for source selection bitfield (OMAP1 only)
+ *
+ * XXX @rate_offset, @src_offset should probably be removed and OMAP1
+ * clock code converted to use clksel.
+ *
+ */
+
+struct clk_hw_omap_ops;
+
+struct clk_hw_omap {
+	struct clk_hw		hw;
+	struct list_head	node;
+	unsigned long		fixed_rate;
+	u8			fixed_div;
+	void __iomem		*enable_reg;
+	u8			enable_bit;
+	u8			flags;
+	void __iomem		*clksel_reg;
+	u32			clksel_mask;
+	const struct clksel	*clksel;
+	struct dpll_data	*dpll_data;
+	const char		*clkdm_name;
+	struct clockdomain	*clkdm;
+	const struct clk_hw_omap_ops	*ops;
+};
+
+struct clk_hw_omap_ops {
+	void			(*find_idlest)(struct clk_hw_omap *oclk,
+					void __iomem **idlest_reg,
+					u8 *idlest_bit, u8 *idlest_val);
+	void			(*find_companion)(struct clk_hw_omap *oclk,
+					void __iomem **other_reg,
+					u8 *other_bit);
+	void			(*allow_idle)(struct clk_hw_omap *oclk);
+	void			(*deny_idle)(struct clk_hw_omap *oclk);
+};
+
+void omap2_init_clk_hw_omap_clocks(struct clk *clk);
+int omap3_noncore_dpll_enable(struct clk_hw *hw);
+void omap3_noncore_dpll_disable(struct clk_hw *hw);
+int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned long rate,
+				unsigned long parent_rate);
+unsigned long omap4_dpll_regm4xen_recalc(struct clk_hw *hw,
+				unsigned long parent_rate);
+long omap4_dpll_regm4xen_round_rate(struct clk_hw *hw,
+				    unsigned long target_rate,
+				    unsigned long *parent_rate);
+u8 omap2_init_dpll_parent(struct clk_hw *hw);
+unsigned long omap3_dpll_recalc(struct clk_hw *hw, unsigned long parent_rate);
+long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
+			unsigned long *parent_rate);
+void omap2_init_clk_clkdm(struct clk_hw *clk);
+unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
+				    unsigned long parent_rate);
+
+int omap2_clkops_enable_clkdm(struct clk_hw *hw);
+void omap2_clkops_disable_clkdm(struct clk_hw *hw);
+
+int omap2_clk_disable_autoidle_all(void);
+
+extern const struct clk_hw_omap_ops clkhwops_omap3_dpll;
+extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx;
+
+/* DT functions */
+int dt_omap_clk_init(void);
+void of_omap4_dpll_setup(struct device_node *node);
 
 #endif
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:04 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:04 +0300
Subject: [PATCHv4 09/33] CLK: omap: add omap4 clock init file
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-10-git-send-email-t-kristo@ti.com>

clk-44xx.c now contains the clock init functionality for omap4, including
DT clock registration and adding of static clkdev entries.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 drivers/clk/omap/clk-44xx.c |  118 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 118 insertions(+)
 create mode 100644 drivers/clk/omap/clk-44xx.c

diff --git a/drivers/clk/omap/clk-44xx.c b/drivers/clk/omap/clk-44xx.c
new file mode 100644
index 0000000..cc12134
--- /dev/null
+++ b/drivers/clk/omap/clk-44xx.c
@@ -0,0 +1,118 @@
+/*
+ * OMAP4 Clock data
+ *
+ * Copyright (C) 2009-2012 Texas Instruments, Inc.
+ * Copyright (C) 2009-2010 Nokia Corporation
+ *
+ * Paul Walmsley (paul at pwsan.com)
+ * Rajendra Nayak (rnayak at ti.com)
+ * Benoit Cousson (b-cousson at ti.com)
+ * Mike Turquette (mturquette at ti.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * XXX Some of the ES1 clocks have been removed/changed; once support
+ * is added for discriminating clocks by ES level, these should be added back
+ * in.
+ *
+ * XXX All of the remaining MODULEMODE clock nodes should be removed
+ * once the drivers are updated to use pm_runtime or to use the appropriate
+ * upstream clock node for rate/parent selection.
+ */
+
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/clk-private.h>
+#include <linux/clkdev.h>
+#include <linux/io.h>
+#include <linux/clk/omap.h>
+
+/*
+ * OMAP4 ABE DPLL default frequency. In OMAP4460 TRM version V, section
+ * "3.6.3.2.3 CM1_ABE Clock Generator" states that the "DPLL_ABE_X2_CLK
+ * must be set to 196.608 MHz" and hence, the DPLL locked frequency is
+ * half of this value.
+ */
+#define OMAP4_DPLL_ABE_DEFFREQ				98304000
+
+/*
+ * OMAP4 USB DPLL default frequency. In OMAP4430 TRM version V, section
+ * "3.6.3.9.5 DPLL_USB Preferred Settings" shows that the preferred
+ * locked frequency for the USB DPLL is 960MHz.
+ */
+#define OMAP4_DPLL_USB_DEFFREQ				960000000
+
+static struct omap_dt_clk omap44xx_clks[] = {
+	DT_CLK("smp_twd",	NULL,			"mpu_periphclk"),
+	DT_CLK("omapdss_dss", "ick", "dss_fck"),
+	DT_CLK("usbhs_omap", "fs_fck", "usb_host_fs_fck"),
+	DT_CLK("usbhs_omap", "hs_fck", "usb_host_hs_fck"),
+	DT_CLK("usbhs_omap", "usbtll_ick", "usb_tll_hs_ick"),
+	DT_CLK("usbhs_tll", "usbtll_ick", "usb_tll_hs_ick"),
+	DT_CLK(NULL,	"timer_32k_ck",	"sys_32k_ck"),
+	/* TODO: Remove "omap_timer.X" aliases once DT migration is complete */
+	DT_CLK("omap_timer.1",	"timer_sys_ck",	"sys_clkin_ck"),
+	DT_CLK("omap_timer.2",	"timer_sys_ck",	"sys_clkin_ck"),
+	DT_CLK("omap_timer.3",	"timer_sys_ck",	"sys_clkin_ck"),
+	DT_CLK("omap_timer.4",	"timer_sys_ck",	"sys_clkin_ck"),
+	DT_CLK("omap_timer.9",	"timer_sys_ck",	"sys_clkin_ck"),
+	DT_CLK("omap_timer.10",	"timer_sys_ck",	"sys_clkin_ck"),
+	DT_CLK("omap_timer.11",	"timer_sys_ck",	"sys_clkin_ck"),
+	DT_CLK("omap_timer.5",	"timer_sys_ck",	"syc_clk_div_ck"),
+	DT_CLK("omap_timer.6",	"timer_sys_ck",	"syc_clk_div_ck"),
+	DT_CLK("omap_timer.7",	"timer_sys_ck",	"syc_clk_div_ck"),
+	DT_CLK("omap_timer.8",	"timer_sys_ck",	"syc_clk_div_ck"),
+	DT_CLK("4a318000.timer",	"timer_sys_ck",	"sys_clkin_ck"),
+	DT_CLK("48032000.timer",	"timer_sys_ck",	"sys_clkin_ck"),
+	DT_CLK("48034000.timer",	"timer_sys_ck",	"sys_clkin_ck"),
+	DT_CLK("48036000.timer",	"timer_sys_ck",	"sys_clkin_ck"),
+	DT_CLK("4803e000.timer",	"timer_sys_ck",	"sys_clkin_ck"),
+	DT_CLK("48086000.timer",	"timer_sys_ck",	"sys_clkin_ck"),
+	DT_CLK("48088000.timer",	"timer_sys_ck",	"sys_clkin_ck"),
+	DT_CLK("40138000.timer",	"timer_sys_ck",	"syc_clk_div_ck"),
+	DT_CLK("4013a000.timer",	"timer_sys_ck",	"syc_clk_div_ck"),
+	DT_CLK("4013c000.timer",	"timer_sys_ck",	"syc_clk_div_ck"),
+	DT_CLK("4013e000.timer",	"timer_sys_ck",	"syc_clk_div_ck"),
+	DT_CLK(NULL,	"cpufreq_ck",	"dpll_mpu_ck"),
+};
+
+int __init omap4xxx_clk_init(void)
+{
+	int rc;
+	struct clk *abe_dpll_ref, *abe_dpll, *sys_32k_ck, *usb_dpll;
+
+	/* FIXME register clocks from DT first */
+	dt_omap_clk_init();
+
+	omap_dt_clocks_register(omap44xx_clks, ARRAY_SIZE(omap44xx_clks));
+
+	omap2_clk_disable_autoidle_all();
+
+	/*
+	 * On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
+	 * state when turning the ABE clock domain. Workaround this by
+	 * locking the ABE DPLL on boot.
+	 * Lock the ABE DPLL in any case to avoid issues with audio.
+	 */
+	abe_dpll_ref = clk_get_sys(NULL, "abe_dpll_refclk_mux_ck");
+	sys_32k_ck = clk_get_sys(NULL, "sys_32k_ck");
+	rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
+	abe_dpll = clk_get_sys(NULL, "dpll_abe_ck");
+	if (!rc)
+		rc = clk_set_rate(abe_dpll, OMAP4_DPLL_ABE_DEFFREQ);
+	if (rc)
+		pr_err("%s: failed to configure ABE DPLL!\n", __func__);
+
+	/*
+	 * Lock USB DPLL on OMAP4 devices so that the L3INIT power
+	 * domain can transition to retention state when not in use.
+	 */
+	usb_dpll = clk_get_sys(NULL, "dpll_usb_ck");
+	rc = clk_set_rate(usb_dpll, OMAP4_DPLL_USB_DEFFREQ);
+	if (rc)
+		pr_err("%s: failed to configure USB DPLL!\n", __func__);
+
+	return 0;
+}
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:03 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:03 +0300
Subject: [PATCHv4 08/33] ARM: dts: omap4 clock data
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-9-git-send-email-t-kristo@ti.com>

This patch creates a unique node for each clock in the OMAP4 power,
reset and clock manager (PRCM). OMAP443x and OMAP446x have slightly
different clock tree which is taken into account in the data.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 arch/arm/boot/dts/omap443x-clocks.dtsi |   17 +
 arch/arm/boot/dts/omap443x.dtsi        |    8 +
 arch/arm/boot/dts/omap4460.dtsi        |    8 +
 arch/arm/boot/dts/omap446x-clocks.dtsi |   27 +
 arch/arm/boot/dts/omap44xx-clocks.dtsi | 1654 ++++++++++++++++++++++++++++++++
 5 files changed, 1714 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap443x-clocks.dtsi
 create mode 100644 arch/arm/boot/dts/omap446x-clocks.dtsi
 create mode 100644 arch/arm/boot/dts/omap44xx-clocks.dtsi

diff --git a/arch/arm/boot/dts/omap443x-clocks.dtsi b/arch/arm/boot/dts/omap443x-clocks.dtsi
new file mode 100644
index 0000000..2bd82b2
--- /dev/null
+++ b/arch/arm/boot/dts/omap443x-clocks.dtsi
@@ -0,0 +1,17 @@
+/*
+ * Device Tree Source for OMAP443x clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+bandgap_fclk: bandgap_fclk at 4a307888 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a307888 0x4>;
+};
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..dfd648c 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -30,4 +30,12 @@
 		       0x4a00232C 0x4>;
 		compatible = "ti,omap4430-bandgap";
 	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/include/ "omap44xx-clocks.dtsi"
+		/include/ "omap443x-clocks.dtsi"
+	};
 };
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index c2f0f39..d9d00b2 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -38,4 +38,12 @@
 		interrupts = <0 126 IRQ_TYPE_LEVEL_HIGH>; /* talert */
 		gpios = <&gpio3 22 0>; /* tshut */
 	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/include/ "omap44xx-clocks.dtsi"
+		/include/ "omap446x-clocks.dtsi"
+	};
 };
diff --git a/arch/arm/boot/dts/omap446x-clocks.dtsi b/arch/arm/boot/dts/omap446x-clocks.dtsi
new file mode 100644
index 0000000..86d0805
--- /dev/null
+++ b/arch/arm/boot/dts/omap446x-clocks.dtsi
@@ -0,0 +1,27 @@
+/*
+ * Device Tree Source for OMAP446x clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+div_ts_ck: div_ts_ck at 4a307888 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&l4_wkup_clk_mux_ck>;
+	bit-shift = <24>;
+	reg = <0x4a307888 0x4>;
+	table = < 8 0 >, < 16 1 >, < 32 2 >;
+	bit-mask = <0x3>;
+};
+
+bandgap_ts_fclk: bandgap_ts_fclk at 4a307888 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&div_ts_ck>;
+	bit-shift = <8>;
+	reg = <0x4a307888 0x4>;
+};
diff --git a/arch/arm/boot/dts/omap44xx-clocks.dtsi b/arch/arm/boot/dts/omap44xx-clocks.dtsi
new file mode 100644
index 0000000..ed6bc9b
--- /dev/null
+++ b/arch/arm/boot/dts/omap44xx-clocks.dtsi
@@ -0,0 +1,1654 @@
+/*
+ * Device Tree Source for OMAP4 clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+extalt_clkin_ck: extalt_clkin_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <59000000>;
+};
+
+pad_clks_src_ck: pad_clks_src_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <12000000>;
+};
+
+pad_clks_ck: pad_clks_ck at 4a004108 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&pad_clks_src_ck>;
+	bit-shift = <8>;
+	reg = <0x4a004108 0x4>;
+};
+
+pad_slimbus_core_clks_ck: pad_slimbus_core_clks_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <12000000>;
+};
+
+secure_32k_clk_src_ck: secure_32k_clk_src_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <32768>;
+};
+
+slimbus_src_clk: slimbus_src_clk {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <12000000>;
+};
+
+slimbus_clk: slimbus_clk at 4a004108 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&slimbus_src_clk>;
+	bit-shift = <10>;
+	reg = <0x4a004108 0x4>;
+};
+
+sys_32k_ck: sys_32k_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <32768>;
+};
+
+virt_12000000_ck: virt_12000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <12000000>;
+};
+
+virt_13000000_ck: virt_13000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <13000000>;
+};
+
+virt_16800000_ck: virt_16800000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <16800000>;
+};
+
+virt_19200000_ck: virt_19200000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <19200000>;
+};
+
+virt_26000000_ck: virt_26000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <26000000>;
+};
+
+virt_27000000_ck: virt_27000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <27000000>;
+};
+
+virt_38400000_ck: virt_38400000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <38400000>;
+};
+
+sys_clkin_ck: sys_clkin_ck at 4a306110 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&virt_12000000_ck>, <&virt_13000000_ck>, <&virt_16800000_ck>, <&virt_19200000_ck>, <&virt_26000000_ck>, <&virt_27000000_ck>, <&virt_38400000_ck>;
+	reg = <0x4a306110 0x4>;
+	bit-mask = <0x7>;
+	index-starts-at-one;
+};
+
+tie_low_clock_ck: tie_low_clock_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+utmi_phy_clkout_ck: utmi_phy_clkout_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <60000000>;
+};
+
+xclk60mhsp1_ck: xclk60mhsp1_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <60000000>;
+};
+
+xclk60mhsp2_ck: xclk60mhsp2_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <60000000>;
+};
+
+xclk60motg_ck: xclk60motg_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <60000000>;
+};
+
+abe_dpll_bypass_clk_mux_ck: abe_dpll_bypass_clk_mux_ck at 4a306108 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a306108 0x4>;
+	bit-mask = <0x1>;
+};
+
+abe_dpll_refclk_mux_ck: abe_dpll_refclk_mux_ck at 4a30610c {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
+	reg = <0x4a30610c 0x4>;
+	bit-mask = <0x1>;
+};
+
+dpll_abe_ck: dpll_abe_ck at 4a0041e0 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&abe_dpll_refclk_mux_ck>, <&abe_dpll_bypass_clk_mux_ck>;
+	reg = <0x4a0041e0 0x4>, <0x4a0041e4 0x4>, <0x4a0041e8 0x4>, <0x4a0041ec 0x4>;
+	ti,clk-ref = <&abe_dpll_refclk_mux_ck>;
+	ti,clk-bypass = <&abe_dpll_bypass_clk_mux_ck>;
+	ti,dpll-regm4xen;
+};
+
+dpll_abe_x2_ck: dpll_abe_x2_ck at 4a0041f0 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_abe_ck>;
+	reg = <0x4a0041f0 0x4>;
+	ti,dpll-clk-x2;
+};
+
+dpll_abe_m2x2_ck: dpll_abe_m2x2_ck at 4a0041f0 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0041f0 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+abe_24m_fclk: abe_24m_fclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_abe_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <8>;
+};
+
+abe_clk: abe_clk at 4a004108 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_m2x2_ck>;
+	reg = <0x4a004108 0x4>;
+	bit-mask = <0x3>;
+	index-power-of-two;
+};
+
+aess_fclk: aess_fclk at 4a004528 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&abe_clk>;
+	bit-shift = <24>;
+	reg = <0x4a004528 0x4>;
+	bit-mask = <0x1>;
+};
+
+dpll_abe_m3x2_ck: dpll_abe_m3x2_ck at 4a0041f4 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0041f4 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+core_hsd_byp_clk_mux_ck: core_hsd_byp_clk_mux_ck at 4a00412c {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&dpll_abe_m3x2_ck>;
+	bit-shift = <23>;
+	reg = <0x4a00412c 0x4>;
+	bit-mask = <0x1>;
+};
+
+dpll_core_ck: dpll_core_ck at 4a004120 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin_ck>, <&core_hsd_byp_clk_mux_ck>;
+	reg = <0x4a004120 0x4>, <0x4a004124 0x4>, <0x4a004128 0x4>, <0x4a00412c 0x4>;
+	ti,clk-ref = <&sys_clkin_ck>;
+	ti,clk-bypass = <&core_hsd_byp_clk_mux_ck>;
+	ti,dpll-core;
+};
+
+dpll_core_x2_ck: dpll_core_x2_ck {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_core_ck>;
+	ti,dpll-clk-x2;
+};
+
+dpll_core_m6x2_ck: dpll_core_m6x2_ck at 4a004140 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a004140 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dbgclk_mux_ck: dbgclk_mux_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll_core_m2_ck: dpll_core_m2_ck at 4a004130 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a004130 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+ddrphy_ck: ddrphy_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+dpll_core_m5x2_ck: dpll_core_m5x2_ck at 4a00413c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a00413c 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+div_core_ck: div_core_ck at 4a004100 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_m5x2_ck>;
+	reg = <0x4a004100 0x4>;
+	bit-mask = <0x1>;
+};
+
+div_iva_hs_clk: div_iva_hs_clk at 4a0041dc {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_m5x2_ck>;
+	reg = <0x4a0041dc 0x4>;
+	bit-mask = <0x3>;
+	index-power-of-two;
+};
+
+div_mpu_hs_clk: div_mpu_hs_clk at 4a00419c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_m5x2_ck>;
+	reg = <0x4a00419c 0x4>;
+	bit-mask = <0x3>;
+	index-power-of-two;
+};
+
+dpll_core_m4x2_ck: dpll_core_m4x2_ck at 4a004138 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a004138 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dll_clk_div_ck: dll_clk_div_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_m4x2_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+dpll_abe_m2_ck: dpll_abe_m2_ck at 4a0041f0 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_ck>;
+	reg = <0x4a0041f0 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+dpll_core_m3x2_div_ck: dpll_core_m3x2_div_ck at 4a004134 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	reg = <0x4a004134 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+dpll_core_m3x2_ck: dpll_core_m3x2_ck at 4a004134 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_core_m3x2_div_ck>;
+	bit-shift = <8>;
+	reg = <0x4a004134 0x4>;
+};
+
+dpll_core_m7x2_ck: dpll_core_m7x2_ck at 4a004144 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a004144 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+iva_hsd_byp_clk_mux_ck: iva_hsd_byp_clk_mux_ck at 4a0041ac {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&div_iva_hs_clk>;
+	bit-shift = <23>;
+	reg = <0x4a0041ac 0x4>;
+	bit-mask = <0x1>;
+};
+
+dpll_iva_ck: dpll_iva_ck at 4a0041a0 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin_ck>, <&iva_hsd_byp_clk_mux_ck>;
+	reg = <0x4a0041a0 0x4>, <0x4a0041a4 0x4>, <0x4a0041a8 0x4>, <0x4a0041ac 0x4>;
+	ti,clk-ref = <&sys_clkin_ck>;
+	ti,clk-bypass = <&iva_hsd_byp_clk_mux_ck>;
+};
+
+dpll_iva_x2_ck: dpll_iva_x2_ck {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_iva_ck>;
+	ti,dpll-clk-x2;
+};
+
+dpll_iva_m4x2_ck: dpll_iva_m4x2_ck at 4a0041b8 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_iva_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0041b8 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_iva_m5x2_ck: dpll_iva_m5x2_ck at 4a0041bc {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_iva_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0041bc 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_mpu_ck: dpll_mpu_ck at 4a004160 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin_ck>, <&div_mpu_hs_clk>;
+	reg = <0x4a004160 0x4>, <0x4a004164 0x4>, <0x4a004168 0x4>, <0x4a00416c 0x4>;
+	ti,clk-ref = <&sys_clkin_ck>;
+	ti,clk-bypass = <&div_mpu_hs_clk>;
+};
+
+dpll_mpu_m2_ck: dpll_mpu_m2_ck at 4a004170 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_mpu_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a004170 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+per_hs_clk_div_ck: per_hs_clk_div_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_abe_m3x2_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+per_hsd_byp_clk_mux_ck: per_hsd_byp_clk_mux_ck at 4a00814c {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&per_hs_clk_div_ck>;
+	bit-shift = <23>;
+	reg = <0x4a00814c 0x4>;
+	bit-mask = <0x1>;
+};
+
+dpll_per_ck: dpll_per_ck at 4a008140 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin_ck>, <&per_hsd_byp_clk_mux_ck>;
+	reg = <0x4a008140 0x4>, <0x4a008144 0x4>, <0x4a008148 0x4>, <0x4a00814c 0x4>;
+	ti,clk-ref = <&sys_clkin_ck>;
+	ti,clk-bypass = <&per_hsd_byp_clk_mux_ck>;
+};
+
+dpll_per_m2_ck: dpll_per_m2_ck at 4a008150 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_ck>;
+	reg = <0x4a008150 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+dpll_per_x2_ck: dpll_per_x2_ck at 4a008150 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_per_ck>;
+	reg = <0x4a008150 0x4>;
+	ti,dpll-clk-x2;
+};
+
+dpll_per_m2x2_ck: dpll_per_m2x2_ck at 4a008150 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008150 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_per_m3x2_div_ck: dpll_per_m3x2_div_ck at 4a008154 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	reg = <0x4a008154 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+dpll_per_m3x2_ck: dpll_per_m3x2_ck at 4a008154 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_per_m3x2_div_ck>;
+	bit-shift = <8>;
+	reg = <0x4a008154 0x4>;
+};
+
+dpll_per_m4x2_ck: dpll_per_m4x2_ck at 4a008158 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008158 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_per_m5x2_ck: dpll_per_m5x2_ck at 4a00815c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a00815c 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_per_m6x2_ck: dpll_per_m6x2_ck at 4a008160 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008160 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_per_m7x2_ck: dpll_per_m7x2_ck at 4a008164 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008164 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+usb_hs_clk_div_ck: usb_hs_clk_div_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_abe_m3x2_ck>;
+	clock-mult = <1>;
+	clock-div = <3>;
+};
+
+dpll_usb_ck: dpll_usb_ck at 4a008180 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin_ck>, <&usb_hs_clk_div_ck>;
+	ti,clk-bypass = <&usb_hs_clk_div_ck>;
+	reg = <0x4a008180 0x4>, <0x4a008184 0x4>, <0x4a008188 0x4>, <0x4a00818c 0x4>;
+	ti,clk-ref = <&sys_clkin_ck>;
+	ti,clkdm-name = "l3_init_clkdm";
+	ti,dpll-j-type;
+};
+
+dpll_usb_clkdcoldo_ck: dpll_usb_clkdcoldo_ck at 4a0081b4 {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_usb_ck>;
+	ti,autoidle-shift = <8>;
+	clock-div = <1>;
+	reg = <0x4a0081b4 0x4>;
+	clock-mult = <1>;
+	ti,autoidle-low;
+};
+
+dpll_usb_m2_ck: dpll_usb_m2_ck at 4a008190 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_usb_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008190 0x4>;
+	bit-mask = <0x7f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+ducati_clk_mux_ck: ducati_clk_mux_ck at 4a008100 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&div_core_ck>, <&dpll_per_m6x2_ck>;
+	reg = <0x4a008100 0x4>;
+	bit-mask = <0x1>;
+};
+
+func_12m_fclk: func_12m_fclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <16>;
+};
+
+func_24m_clk: func_24m_clk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <4>;
+};
+
+func_24mc_fclk: func_24mc_fclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <8>;
+};
+
+func_48m_fclk: func_48m_fclk at 4a008108 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_m2x2_ck>;
+	reg = <0x4a008108 0x4>;
+	table = < 4 0 >, < 8 1 >;
+	bit-mask = <0x1>;
+};
+
+func_48mc_fclk: func_48mc_fclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <4>;
+};
+
+func_64m_fclk: func_64m_fclk at 4a008108 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_m4x2_ck>;
+	reg = <0x4a008108 0x4>;
+	table = < 2 0 >, < 4 1 >;
+	bit-mask = <0x1>;
+};
+
+func_96m_fclk: func_96m_fclk at 4a008108 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_m2x2_ck>;
+	reg = <0x4a008108 0x4>;
+	table = < 2 0 >, < 4 1 >;
+	bit-mask = <0x1>;
+};
+
+init_60m_fclk: init_60m_fclk at 4a008104 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_usb_m2_ck>;
+	reg = <0x4a008104 0x4>;
+	table = < 1 0 >, < 8 1 >;
+	bit-mask = <0x1>;
+};
+
+l3_div_ck: l3_div_ck at 4a004100 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&div_core_ck>;
+	bit-shift = <4>;
+	reg = <0x4a004100 0x4>;
+	bit-mask = <0x1>;
+};
+
+l4_div_ck: l4_div_ck at 4a004100 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&l3_div_ck>;
+	bit-shift = <8>;
+	reg = <0x4a004100 0x4>;
+	bit-mask = <0x1>;
+};
+
+lp_clk_div_ck: lp_clk_div_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_abe_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <16>;
+};
+
+l4_wkup_clk_mux_ck: l4_wkup_clk_mux_ck at 4a306108 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&lp_clk_div_ck>;
+	reg = <0x4a306108 0x4>;
+	bit-mask = <0x1>;
+};
+
+mpu_periphclk: mpu_periphclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_mpu_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+ocp_abe_iclk: ocp_abe_iclk at 4a004528 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&aess_fclk>;
+	bit-shift = <24>;
+	reg = <0x4a004528 0x4>;
+	table = < 2 0 >, < 1 1 >;
+	bit-mask = <0x1>;
+};
+
+per_abe_24m_fclk: per_abe_24m_fclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_abe_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <4>;
+};
+
+per_abe_nc_fclk: per_abe_nc_fclk at 4a008108 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_m2_ck>;
+	reg = <0x4a008108 0x4>;
+	bit-mask = <0x1>;
+};
+
+syc_clk_div_ck: syc_clk_div_ck at 4a306100 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&sys_clkin_ck>;
+	reg = <0x4a306100 0x4>;
+	bit-mask = <0x1>;
+};
+
+aes1_fck: aes1_fck at 4a0095a0 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l3_div_ck>;
+	bit-shift = <1>;
+	reg = <0x4a0095a0 0x4>;
+};
+
+aes2_fck: aes2_fck at 4a0095a8 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l3_div_ck>;
+	bit-shift = <1>;
+	reg = <0x4a0095a8 0x4>;
+};
+
+dmic_sync_mux_ck: dmic_sync_mux_ck at 4a004538 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&syc_clk_div_ck>, <&func_24m_clk>;
+	bit-shift = <25>;
+	reg = <0x4a004538 0x4>;
+	bit-mask = <0x1>;
+};
+
+func_dmic_abe_gfclk: func_dmic_abe_gfclk at 4a004538 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dmic_sync_mux_ck>, <&pad_clks_ck>, <&slimbus_clk>;
+	bit-shift = <24>;
+	reg = <0x4a004538 0x4>;
+	bit-mask = <0x3>;
+};
+
+dss_sys_clk: dss_sys_clk at 4a009120 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&syc_clk_div_ck>;
+	bit-shift = <10>;
+	reg = <0x4a009120 0x4>;
+};
+
+dss_tv_clk: dss_tv_clk at 4a009120 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&extalt_clkin_ck>;
+	bit-shift = <11>;
+	reg = <0x4a009120 0x4>;
+};
+
+dss_dss_clk: dss_dss_clk at 4a009120 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_per_m5x2_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009120 0x4>;
+};
+
+dss_48mhz_clk: dss_48mhz_clk at 4a009120 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&func_48mc_fclk>;
+	bit-shift = <9>;
+	reg = <0x4a009120 0x4>;
+};
+
+dss_fck: dss_fck at 4a009120 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l3_div_ck>;
+	bit-shift = <1>;
+	reg = <0x4a009120 0x4>;
+};
+
+fdif_fck: fdif_fck at 4a009028 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_m4x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009028 0x4>;
+	bit-mask = <0x3>;
+	index-power-of-two;
+};
+
+gpio1_dbclk: gpio1_dbclk at 4a307838 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a307838 0x4>;
+};
+
+gpio2_dbclk: gpio2_dbclk at 4a009460 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009460 0x4>;
+};
+
+gpio3_dbclk: gpio3_dbclk at 4a009468 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009468 0x4>;
+};
+
+gpio4_dbclk: gpio4_dbclk at 4a009470 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009470 0x4>;
+};
+
+gpio5_dbclk: gpio5_dbclk at 4a009478 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009478 0x4>;
+};
+
+gpio6_dbclk: gpio6_dbclk at 4a009480 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009480 0x4>;
+};
+
+sgx_clk_mux: sgx_clk_mux at 4a009220 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dpll_core_m7x2_ck>, <&dpll_per_m7x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009220 0x4>;
+	bit-mask = <0x1>;
+};
+
+hsi_fck: hsi_fck at 4a009338 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009338 0x4>;
+	bit-mask = <0x3>;
+	index-power-of-two;
+};
+
+iss_ctrlclk: iss_ctrlclk at 4a009020 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&func_96m_fclk>;
+	bit-shift = <8>;
+	reg = <0x4a009020 0x4>;
+};
+
+mcasp_sync_mux_ck: mcasp_sync_mux_ck at 4a004540 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&syc_clk_div_ck>, <&func_24m_clk>;
+	bit-shift = <25>;
+	reg = <0x4a004540 0x4>;
+	bit-mask = <0x1>;
+};
+
+func_mcasp_abe_gfclk: func_mcasp_abe_gfclk at 4a004540 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&mcasp_sync_mux_ck>, <&pad_clks_ck>, <&slimbus_clk>;
+	bit-shift = <24>;
+	reg = <0x4a004540 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcbsp1_sync_mux_ck: mcbsp1_sync_mux_ck at 4a004548 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&syc_clk_div_ck>, <&func_24m_clk>;
+	bit-shift = <25>;
+	reg = <0x4a004548 0x4>;
+	bit-mask = <0x1>;
+};
+
+func_mcbsp1_gfclk: func_mcbsp1_gfclk at 4a004548 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&mcbsp1_sync_mux_ck>, <&pad_clks_ck>, <&slimbus_clk>;
+	bit-shift = <24>;
+	reg = <0x4a004548 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcbsp2_sync_mux_ck: mcbsp2_sync_mux_ck at 4a004550 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&syc_clk_div_ck>, <&func_24m_clk>;
+	bit-shift = <25>;
+	reg = <0x4a004550 0x4>;
+	bit-mask = <0x1>;
+};
+
+func_mcbsp2_gfclk: func_mcbsp2_gfclk at 4a004550 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&mcbsp2_sync_mux_ck>, <&pad_clks_ck>, <&slimbus_clk>;
+	bit-shift = <24>;
+	reg = <0x4a004550 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcbsp3_sync_mux_ck: mcbsp3_sync_mux_ck at 4a004558 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&syc_clk_div_ck>, <&func_24m_clk>;
+	bit-shift = <25>;
+	reg = <0x4a004558 0x4>;
+	bit-mask = <0x1>;
+};
+
+func_mcbsp3_gfclk: func_mcbsp3_gfclk at 4a004558 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&mcbsp3_sync_mux_ck>, <&pad_clks_ck>, <&slimbus_clk>;
+	bit-shift = <24>;
+	reg = <0x4a004558 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcbsp4_sync_mux_ck: mcbsp4_sync_mux_ck at 4a0094e0 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_96m_fclk>, <&per_abe_nc_fclk>;
+	bit-shift = <25>;
+	reg = <0x4a0094e0 0x4>;
+	bit-mask = <0x1>;
+};
+
+per_mcbsp4_gfclk: per_mcbsp4_gfclk at 4a0094e0 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&mcbsp4_sync_mux_ck>, <&pad_clks_ck>;
+	bit-shift = <24>;
+	reg = <0x4a0094e0 0x4>;
+	bit-mask = <0x1>;
+};
+
+hsmmc1_fclk: hsmmc1_fclk at 4a009328 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_64m_fclk>, <&func_96m_fclk>;
+	bit-shift = <24>;
+	reg = <0x4a009328 0x4>;
+	bit-mask = <0x1>;
+};
+
+hsmmc2_fclk: hsmmc2_fclk at 4a009330 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_64m_fclk>, <&func_96m_fclk>;
+	bit-shift = <24>;
+	reg = <0x4a009330 0x4>;
+	bit-mask = <0x1>;
+};
+
+ocp2scp_usb_phy_phy_48m: ocp2scp_usb_phy_phy_48m at 4a0093e0 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&func_48m_fclk>;
+	bit-shift = <8>;
+	reg = <0x4a0093e0 0x4>;
+};
+
+sha2md5_fck: sha2md5_fck at 4a0095c8 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l3_div_ck>;
+	bit-shift = <1>;
+	reg = <0x4a0095c8 0x4>;
+};
+
+slimbus1_fclk_1: slimbus1_fclk_1 at 4a004560 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&func_24m_clk>;
+	bit-shift = <9>;
+	reg = <0x4a004560 0x4>;
+};
+
+slimbus1_fclk_0: slimbus1_fclk_0 at 4a004560 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&abe_24m_fclk>;
+	bit-shift = <8>;
+	reg = <0x4a004560 0x4>;
+};
+
+slimbus1_fclk_2: slimbus1_fclk_2 at 4a004560 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&pad_clks_ck>;
+	bit-shift = <10>;
+	reg = <0x4a004560 0x4>;
+};
+
+slimbus1_slimbus_clk: slimbus1_slimbus_clk at 4a004560 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&slimbus_clk>;
+	bit-shift = <11>;
+	reg = <0x4a004560 0x4>;
+};
+
+slimbus2_fclk_1: slimbus2_fclk_1 at 4a009538 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&per_abe_24m_fclk>;
+	bit-shift = <9>;
+	reg = <0x4a009538 0x4>;
+};
+
+slimbus2_fclk_0: slimbus2_fclk_0 at 4a009538 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&func_24mc_fclk>;
+	bit-shift = <8>;
+	reg = <0x4a009538 0x4>;
+};
+
+slimbus2_slimbus_clk: slimbus2_slimbus_clk at 4a009538 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&pad_slimbus_core_clks_ck>;
+	bit-shift = <10>;
+	reg = <0x4a009538 0x4>;
+};
+
+smartreflex_core_fck: smartreflex_core_fck at 4a008638 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l4_wkup_clk_mux_ck>;
+	bit-shift = <1>;
+	reg = <0x4a008638 0x4>;
+};
+
+smartreflex_iva_fck: smartreflex_iva_fck at 4a008630 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l4_wkup_clk_mux_ck>;
+	bit-shift = <1>;
+	reg = <0x4a008630 0x4>;
+};
+
+smartreflex_mpu_fck: smartreflex_mpu_fck at 4a008628 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l4_wkup_clk_mux_ck>;
+	bit-shift = <1>;
+	reg = <0x4a008628 0x4>;
+};
+
+dmt1_clk_mux: dmt1_clk_mux at 4a307840 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a307840 0x4>;
+	bit-mask = <0x1>;
+};
+
+cm2_dm10_mux: cm2_dm10_mux at 4a009428 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009428 0x4>;
+	bit-mask = <0x1>;
+};
+
+cm2_dm11_mux: cm2_dm11_mux at 4a009430 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009430 0x4>;
+	bit-mask = <0x1>;
+};
+
+cm2_dm2_mux: cm2_dm2_mux at 4a009438 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009438 0x4>;
+	bit-mask = <0x1>;
+};
+
+cm2_dm3_mux: cm2_dm3_mux at 4a009440 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009440 0x4>;
+	bit-mask = <0x1>;
+};
+
+cm2_dm4_mux: cm2_dm4_mux at 4a009448 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009448 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer5_sync_mux: timer5_sync_mux at 4a004568 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&syc_clk_div_ck>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a004568 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer6_sync_mux: timer6_sync_mux at 4a004570 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&syc_clk_div_ck>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a004570 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer7_sync_mux: timer7_sync_mux at 4a004578 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&syc_clk_div_ck>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a004578 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer8_sync_mux: timer8_sync_mux at 4a004580 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&syc_clk_div_ck>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a004580 0x4>;
+	bit-mask = <0x1>;
+};
+
+cm2_dm9_mux: cm2_dm9_mux at 4a009450 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009450 0x4>;
+	bit-mask = <0x1>;
+};
+
+usb_host_fs_fck: usb_host_fs_fck at 4a0093d0 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&func_48mc_fclk>;
+	reg = <0x4a0093d0 0x4>;
+	bit-shift = <1>;
+};
+
+utmi_p1_gfclk: utmi_p1_gfclk at 4a009358 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&init_60m_fclk>, <&xclk60mhsp1_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009358 0x4>;
+	bit-mask = <0x1>;
+};
+
+usb_host_hs_utmi_p1_clk: usb_host_hs_utmi_p1_clk at 4a009358 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&utmi_p1_gfclk>;
+	bit-shift = <8>;
+	reg = <0x4a009358 0x4>;
+};
+
+utmi_p2_gfclk: utmi_p2_gfclk at 4a009358 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&init_60m_fclk>, <&xclk60mhsp2_ck>;
+	bit-shift = <25>;
+	reg = <0x4a009358 0x4>;
+	bit-mask = <0x1>;
+};
+
+usb_host_hs_utmi_p2_clk: usb_host_hs_utmi_p2_clk at 4a009358 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&utmi_p2_gfclk>;
+	bit-shift = <9>;
+	reg = <0x4a009358 0x4>;
+};
+
+usb_host_hs_utmi_p3_clk: usb_host_hs_utmi_p3_clk at 4a009358 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&init_60m_fclk>;
+	bit-shift = <10>;
+	reg = <0x4a009358 0x4>;
+};
+
+usb_host_hs_hsic480m_p1_clk: usb_host_hs_hsic480m_p1_clk at 4a009358 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_usb_m2_ck>;
+	bit-shift = <13>;
+	reg = <0x4a009358 0x4>;
+};
+
+usb_host_hs_hsic60m_p1_clk: usb_host_hs_hsic60m_p1_clk at 4a009358 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&init_60m_fclk>;
+	bit-shift = <11>;
+	reg = <0x4a009358 0x4>;
+};
+
+usb_host_hs_hsic60m_p2_clk: usb_host_hs_hsic60m_p2_clk at 4a009358 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&init_60m_fclk>;
+	bit-shift = <12>;
+	reg = <0x4a009358 0x4>;
+};
+
+usb_host_hs_hsic480m_p2_clk: usb_host_hs_hsic480m_p2_clk at 4a009358 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_usb_m2_ck>;
+	bit-shift = <14>;
+	reg = <0x4a009358 0x4>;
+};
+
+usb_host_hs_func48mclk: usb_host_hs_func48mclk at 4a009358 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&func_48mc_fclk>;
+	bit-shift = <15>;
+	reg = <0x4a009358 0x4>;
+};
+
+usb_host_hs_fck: usb_host_hs_fck at 4a009358 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&init_60m_fclk>;
+	bit-shift = <1>;
+	reg = <0x4a009358 0x4>;
+};
+
+otg_60m_gfclk: otg_60m_gfclk at 4a009360 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&utmi_phy_clkout_ck>, <&xclk60motg_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009360 0x4>;
+	bit-mask = <0x1>;
+};
+
+usb_otg_hs_xclk: usb_otg_hs_xclk at 4a009360 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&otg_60m_gfclk>;
+	bit-shift = <8>;
+	reg = <0x4a009360 0x4>;
+};
+
+usb_otg_hs_ick: usb_otg_hs_ick at 4a009360 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l3_div_ck>;
+	bit-shift = <0>;
+	reg = <0x4a009360 0x4>;
+};
+
+usb_phy_cm_clk32k: usb_phy_cm_clk32k at 4a008640 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a008640 0x4>;
+};
+
+usb_tll_hs_usb_ch2_clk: usb_tll_hs_usb_ch2_clk at 4a009368 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&init_60m_fclk>;
+	bit-shift = <10>;
+	reg = <0x4a009368 0x4>;
+};
+
+usb_tll_hs_usb_ch0_clk: usb_tll_hs_usb_ch0_clk at 4a009368 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&init_60m_fclk>;
+	bit-shift = <8>;
+	reg = <0x4a009368 0x4>;
+};
+
+usb_tll_hs_usb_ch1_clk: usb_tll_hs_usb_ch1_clk at 4a009368 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&init_60m_fclk>;
+	bit-shift = <9>;
+	reg = <0x4a009368 0x4>;
+};
+
+usb_tll_hs_ick: usb_tll_hs_ick at 4a009368 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l4_div_ck>;
+	bit-shift = <0>;
+	reg = <0x4a009368 0x4>;
+};
+
+usim_ck: usim_ck at 4a307858 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_m4x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a307858 0x4>;
+	table = < 14 0 >, < 18 1 >;
+	bit-mask = <0x1>;
+};
+
+usim_fclk: usim_fclk at 4a307858 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&usim_ck>;
+	bit-shift = <8>;
+	reg = <0x4a307858 0x4>;
+};
+
+pmd_stm_clock_mux_ck: pmd_stm_clock_mux_ck at 4a307a20 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&dpll_core_m6x2_ck>, <&tie_low_clock_ck>;
+	bit-shift = <20>;
+	reg = <0x4a307a20 0x4>;
+	bit-mask = <0x3>;
+};
+
+pmd_trace_clk_mux_ck: pmd_trace_clk_mux_ck at 4a307a20 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&dpll_core_m6x2_ck>, <&tie_low_clock_ck>;
+	bit-shift = <22>;
+	reg = <0x4a307a20 0x4>;
+	bit-mask = <0x3>;
+};
+
+stm_clk_div_ck: stm_clk_div_ck at 4a307a20 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&pmd_stm_clock_mux_ck>;
+	bit-shift = <27>;
+	reg = <0x4a307a20 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+trace_clk_div_div_ck: trace_clk_div_div_ck at 4a307a20 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	bit-shift = <24>;
+	reg = <0x4a307a20 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+trace_clk_div_ck: trace_clk_div_ck {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&trace_clk_div_div_ck>;
+	ti,clkdm-name = "emu_sys_clkdm";
+};
+
+auxclk0_src_mux_ck: auxclk0_src_mux_ck at 4a30a310 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&dpll_core_m3x2_ck>, <&dpll_per_m3x2_ck>;
+	bit-shift = <1>;
+	reg = <0x4a30a310 0x4>;
+	bit-mask = <0x3>;
+};
+
+auxclk0_src_ck: auxclk0_src_ck at 4a30a310 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&auxclk0_src_mux_ck>;
+	bit-shift = <8>;
+	reg = <0x4a30a310 0x4>;
+};
+
+auxclk0_ck: auxclk0_ck at 4a30a310 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&auxclk0_src_ck>;
+	bit-shift = <16>;
+	reg = <0x4a30a310 0x4>;
+	bit-mask = <0xf>;
+};
+
+auxclk1_src_mux_ck: auxclk1_src_mux_ck at 4a30a314 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&dpll_core_m3x2_ck>, <&dpll_per_m3x2_ck>;
+	bit-shift = <1>;
+	reg = <0x4a30a314 0x4>;
+	bit-mask = <0x3>;
+};
+
+auxclk1_src_ck: auxclk1_src_ck at 4a30a314 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&auxclk1_src_mux_ck>;
+	bit-shift = <8>;
+	reg = <0x4a30a314 0x4>;
+};
+
+auxclk1_ck: auxclk1_ck at 4a30a314 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&auxclk1_src_ck>;
+	bit-shift = <16>;
+	reg = <0x4a30a314 0x4>;
+	bit-mask = <0xf>;
+};
+
+auxclk2_src_mux_ck: auxclk2_src_mux_ck at 4a30a318 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&dpll_core_m3x2_ck>, <&dpll_per_m3x2_ck>;
+	bit-shift = <1>;
+	reg = <0x4a30a318 0x4>;
+	bit-mask = <0x3>;
+};
+
+auxclk2_src_ck: auxclk2_src_ck at 4a30a318 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&auxclk2_src_mux_ck>;
+	bit-shift = <8>;
+	reg = <0x4a30a318 0x4>;
+};
+
+auxclk2_ck: auxclk2_ck at 4a30a318 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&auxclk2_src_ck>;
+	bit-shift = <16>;
+	reg = <0x4a30a318 0x4>;
+	bit-mask = <0xf>;
+};
+
+auxclk3_src_mux_ck: auxclk3_src_mux_ck at 4a30a31c {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&dpll_core_m3x2_ck>, <&dpll_per_m3x2_ck>;
+	bit-shift = <1>;
+	reg = <0x4a30a31c 0x4>;
+	bit-mask = <0x3>;
+};
+
+auxclk3_src_ck: auxclk3_src_ck at 4a30a31c {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&auxclk3_src_mux_ck>;
+	bit-shift = <8>;
+	reg = <0x4a30a31c 0x4>;
+};
+
+auxclk3_ck: auxclk3_ck at 4a30a31c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&auxclk3_src_ck>;
+	bit-shift = <16>;
+	reg = <0x4a30a31c 0x4>;
+	bit-mask = <0xf>;
+};
+
+auxclk4_src_mux_ck: auxclk4_src_mux_ck at 4a30a320 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&dpll_core_m3x2_ck>, <&dpll_per_m3x2_ck>;
+	bit-shift = <1>;
+	reg = <0x4a30a320 0x4>;
+	bit-mask = <0x3>;
+};
+
+auxclk4_src_ck: auxclk4_src_ck at 4a30a320 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&auxclk4_src_mux_ck>;
+	bit-shift = <8>;
+	reg = <0x4a30a320 0x4>;
+};
+
+auxclk4_ck: auxclk4_ck at 4a30a320 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&auxclk4_src_ck>;
+	bit-shift = <16>;
+	reg = <0x4a30a320 0x4>;
+	bit-mask = <0xf>;
+};
+
+auxclk5_src_mux_ck: auxclk5_src_mux_ck at 4a30a324 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&dpll_core_m3x2_ck>, <&dpll_per_m3x2_ck>;
+	bit-shift = <1>;
+	reg = <0x4a30a324 0x4>;
+	bit-mask = <0x3>;
+};
+
+auxclk5_src_ck: auxclk5_src_ck at 4a30a324 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&auxclk5_src_mux_ck>;
+	bit-shift = <8>;
+	reg = <0x4a30a324 0x4>;
+};
+
+auxclk5_ck: auxclk5_ck at 4a30a324 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&auxclk5_src_ck>;
+	bit-shift = <16>;
+	reg = <0x4a30a324 0x4>;
+	bit-mask = <0xf>;
+};
+
+auxclkreq0_ck: auxclkreq0_ck at 4a30a210 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&auxclk0_ck>, <&auxclk1_ck>, <&auxclk2_ck>, <&auxclk3_ck>, <&auxclk4_ck>, <&auxclk5_ck>;
+	bit-shift = <2>;
+	reg = <0x4a30a210 0x4>;
+	bit-mask = <0x7>;
+};
+
+auxclkreq1_ck: auxclkreq1_ck at 4a30a214 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&auxclk0_ck>, <&auxclk1_ck>, <&auxclk2_ck>, <&auxclk3_ck>, <&auxclk4_ck>, <&auxclk5_ck>;
+	bit-shift = <2>;
+	reg = <0x4a30a214 0x4>;
+	bit-mask = <0x7>;
+};
+
+auxclkreq2_ck: auxclkreq2_ck at 4a30a218 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&auxclk0_ck>, <&auxclk1_ck>, <&auxclk2_ck>, <&auxclk3_ck>, <&auxclk4_ck>, <&auxclk5_ck>;
+	bit-shift = <2>;
+	reg = <0x4a30a218 0x4>;
+	bit-mask = <0x7>;
+};
+
+auxclkreq3_ck: auxclkreq3_ck at 4a30a21c {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&auxclk0_ck>, <&auxclk1_ck>, <&auxclk2_ck>, <&auxclk3_ck>, <&auxclk4_ck>, <&auxclk5_ck>;
+	bit-shift = <2>;
+	reg = <0x4a30a21c 0x4>;
+	bit-mask = <0x7>;
+};
+
+auxclkreq4_ck: auxclkreq4_ck at 4a30a220 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&auxclk0_ck>, <&auxclk1_ck>, <&auxclk2_ck>, <&auxclk3_ck>, <&auxclk4_ck>, <&auxclk5_ck>;
+	bit-shift = <2>;
+	reg = <0x4a30a220 0x4>;
+	bit-mask = <0x7>;
+};
+
+auxclkreq5_ck: auxclkreq5_ck at 4a30a224 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&auxclk0_ck>, <&auxclk1_ck>, <&auxclk2_ck>, <&auxclk3_ck>, <&auxclk4_ck>, <&auxclk5_ck>;
+	bit-shift = <2>;
+	reg = <0x4a30a224 0x4>;
+	bit-mask = <0x7>;
+};
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:07 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:07 +0300
Subject: [PATCHv4 12/33] CLK: omap: add omap5 clock init file
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-13-git-send-email-t-kristo@ti.com>

clk-54xx.c now contains the clock init functionality for omap5, including
DT clock registration and adding of static clkdev entries.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 drivers/clk/omap/Makefile   |    2 +-
 drivers/clk/omap/clk-54xx.c |   58 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 59 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/omap/clk-54xx.c

diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 9ad10be..74385f2 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1,2 +1,2 @@
 obj-y					+= clk.o dpll.o autoidle.o gate.o \
-					   clk-44xx.o
+					   clk-44xx.o clk-54xx.o
diff --git a/drivers/clk/omap/clk-54xx.c b/drivers/clk/omap/clk-54xx.c
new file mode 100644
index 0000000..ade0481
--- /dev/null
+++ b/drivers/clk/omap/clk-54xx.c
@@ -0,0 +1,58 @@
+/*
+ * OMAP5 Clock init
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo (t-kristo at ti.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/clk-private.h>
+#include <linux/clkdev.h>
+#include <linux/io.h>
+#include <linux/clk/omap.h>
+
+#define OMAP5_DPLL_ABE_DEFFREQ				98304000
+
+static struct omap_dt_clk omap54xx_clks[] = {
+	DT_CLK(NULL, "timer_32k_ck", "sys_32k_ck"),
+	DT_CLK("omap_timer.1", "sys_ck", "sys_clkin"),
+	DT_CLK("omap_timer.2", "sys_ck", "sys_clkin"),
+	DT_CLK("omap_timer.3", "sys_ck", "sys_clkin"),
+	DT_CLK("omap_timer.4", "sys_ck", "sys_clkin"),
+	DT_CLK("omap_timer.9", "sys_ck", "sys_clkin"),
+	DT_CLK("omap_timer.10", "sys_ck", "sys_clkin"),
+	DT_CLK("omap_timer.11", "sys_ck", "sys_clkin"),
+	DT_CLK("omap_timer.5", "sys_ck", "dss_syc_gfclk_div"),
+	DT_CLK("omap_timer.6", "sys_ck", "dss_syc_gfclk_div"),
+	DT_CLK("omap_timer.7", "sys_ck", "dss_syc_gfclk_div"),
+	DT_CLK("omap_timer.8", "sys_ck", "dss_syc_gfclk_div"),
+};
+
+int __init omap5xxx_clk_init(void)
+{
+	int rc;
+	struct clk *abe_dpll_ref, *abe_dpll, *sys_32k_ck;
+
+	dt_omap_clk_init();
+
+	omap_dt_clocks_register(omap54xx_clks, ARRAY_SIZE(omap54xx_clks));
+
+	omap2_clk_disable_autoidle_all();
+
+	abe_dpll_ref = clk_get_sys(NULL, "abe_dpll_clk_mux");
+	sys_32k_ck = clk_get_sys(NULL, "sys_32k_ck");
+	rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
+	abe_dpll = clk_get_sys(NULL, "dpll_abe_ck");
+	if (!rc)
+		rc = clk_set_rate(abe_dpll, OMAP5_DPLL_ABE_DEFFREQ);
+	if (rc)
+		pr_err("%s: failed to configure ABE DPLL!\n", __func__);
+
+	return 0;
+}
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:10 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:10 +0300
Subject: [PATCHv4 15/33] CLK: OMAP: DPLL: add support for DT property ti,
 dpll-no-gate
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-16-git-send-email-t-kristo@ti.com>

AM335x has DPLL clocks that should never be attempted to be gated. Adding
ti,dpll-no-gate property for them handles this situation.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 drivers/clk/omap/dpll.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
index 66e82be..1d24feada 100644
--- a/drivers/clk/omap/dpll.c
+++ b/drivers/clk/omap/dpll.c
@@ -54,6 +54,13 @@ static const struct clk_ops dpll_x2_ck_ops = {
 	.recalc_rate	= &omap3_clkoutx2_recalc,
 };
 
+static const struct clk_ops dpll_no_gate_ck_ops = {
+	.recalc_rate	= &omap3_dpll_recalc,
+	.get_parent	= &omap2_init_dpll_parent,
+	.round_rate	= &omap2_dpll_round_rate,
+	.set_rate	= &omap3_noncore_dpll_set_rate,
+};
+
 struct clk *omap_clk_register_dpll(struct device *dev, const char *name,
 		const char **parent_names, int num_parents, unsigned long flags,
 		struct dpll_data *dpll_data, const char *clkdm_name,
@@ -288,6 +295,9 @@ __init void of_omap4_dpll_setup(struct device_node *node)
 		return;
 	}
 
+	if (of_property_read_bool(node, "ti,dpll-no-gate"))
+		ops = &dpll_no_gate_ck_ops;
+
 	of_omap_dpll_setup(node, ops);
 }
 EXPORT_SYMBOL_GPL(of_omap4_dpll_setup);
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:12 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:12 +0300
Subject: [PATCHv4 17/33] CLK: DT: add support for set-rate-parent flag
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-18-git-send-email-t-kristo@ti.com>

Adding set-rate-parent to clock node now allows a node to forward
clk_set_rate request to its parent clock.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 drivers/clk/clk-divider.c      |    6 +++++-
 drivers/clk/clk-fixed-factor.c |    6 +++++-
 drivers/clk/clk-gate.c         |    8 ++++++--
 drivers/clk/clk-mux.c          |    6 +++++-
 4 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index ff24ec2..01d967f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -388,6 +388,7 @@ void of_divider_clk_setup(struct device_node *node)
 	u32 mask = 0;
 	u32 shift = 0;
 	struct clk_div_table *table;
+	u32 flags = 0;
 
 	of_property_read_string(node, "clock-output-names", &clk_name);
 
@@ -418,12 +419,15 @@ void of_divider_clk_setup(struct device_node *node)
 	if (of_property_read_bool(node, "hiword-mask"))
 		clk_divider_flags |= CLK_DIVIDER_HIWORD_MASK;
 
+	if (of_property_read_bool(node, "set-rate-parent"))
+		flags |= CLK_SET_RATE_PARENT;
+
 	table = of_clk_get_div_table(node);
 	if (IS_ERR(table))
 		return;
 
 	clk = _register_divider(NULL, clk_name,
-			parent_name, 0,
+			parent_name, flags,
 			reg, (u8) shift, mask,
 			clk_divider_flags, table,
 			NULL);
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 9ff7d51..30aa121 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -107,6 +107,7 @@ void __init of_fixed_factor_clk_setup(struct device_node *node)
 	const char *clk_name = node->name;
 	const char *parent_name;
 	u32 div, mult;
+	u32 flags = 0;
 
 	if (of_property_read_u32(node, "clock-div", &div)) {
 		pr_err("%s Fixed factor clock <%s> must have a clock-div property\n",
@@ -123,7 +124,10 @@ void __init of_fixed_factor_clk_setup(struct device_node *node)
 	of_property_read_string(node, "clock-output-names", &clk_name);
 	parent_name = of_clk_get_parent_name(node, 0);
 
-	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
+	if (of_property_read_bool(node, "set-rate-parent"))
+		flags |= CLK_SET_RATE_PARENT;
+
+	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, flags,
 					mult, div);
 	if (!IS_ERR(clk))
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index cd595ec..0be25b9 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -176,6 +176,7 @@ void of_gate_clk_setup(struct device_node *node)
 	const char *parent_name;
 	u8 clk_gate_flags = 0;
 	u32 bit_idx = 0;
+	u32 flags = 0;
 
 	of_property_read_string(node, "clock-output-names", &clk_name);
 
@@ -195,8 +196,11 @@ void of_gate_clk_setup(struct device_node *node)
 	if (of_property_read_bool(node, "hiword-mask"))
 		clk_gate_flags |= CLK_GATE_HIWORD_MASK;
 
-	clk = clk_register_gate(NULL, clk_name, parent_name, 0, reg, (u8) bit_idx,
-			clk_gate_flags, NULL);
+	if (of_property_read_bool(node, "set-rate-parent"))
+		flags |= CLK_SET_RATE_PARENT;
+
+	clk = clk_register_gate(NULL, clk_name, parent_name, flags, reg,
+			(u8) bit_idx, clk_gate_flags, NULL);
 
 	if (!IS_ERR(clk))
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 4751bce..890ddbf 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -184,6 +184,7 @@ void of_mux_clk_setup(struct device_node *node)
 	u8 clk_mux_flags = 0;
 	u32 mask = 0;
 	u32 shift = 0;
+	u32 flags = 0;
 
 	of_property_read_string(node, "clock-output-names", &clk_name);
 
@@ -219,8 +220,11 @@ void of_mux_clk_setup(struct device_node *node)
 	if (of_property_read_bool(node, "hiword-mask"))
 		clk_mux_flags |= CLK_MUX_HIWORD_MASK;
 
+	if (of_property_read_bool(node, "set-rate-parent"))
+		flags |= CLK_SET_RATE_PARENT;
+
 	clk = clk_register_mux_table(NULL, clk_name, parent_names, num_parents,
-			0, reg, (u8) shift, mask, clk_mux_flags,
+			flags, reg, (u8) shift, mask, clk_mux_flags,
 			NULL, NULL);
 
 	if (!IS_ERR(clk))
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:06 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:06 +0300
Subject: [PATCHv4 11/33] ARM: dts: omap5 clock data
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-12-git-send-email-t-kristo@ti.com>

This patch creates a unique node for each clock in the OMAP5 power,
reset and clock manager (PRCM).

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 arch/arm/boot/dts/omap54xx-clocks.dtsi | 1416 ++++++++++++++++++++++++++++++++
 1 file changed, 1416 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap54xx-clocks.dtsi

diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi b/arch/arm/boot/dts/omap54xx-clocks.dtsi
new file mode 100644
index 0000000..391edee
--- /dev/null
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -0,0 +1,1416 @@
+/*
+ * Device Tree Source for OMAP5 clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+pad_clks_src_ck: pad_clks_src_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <12000000>;
+};
+
+pad_clks_ck: pad_clks_ck at 4a004108 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&pad_clks_src_ck>;
+	bit-shift = <8>;
+	reg = <0x4a004108 0x4>;
+};
+
+secure_32k_clk_src_ck: secure_32k_clk_src_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <32768>;
+};
+
+slimbus_src_clk: slimbus_src_clk {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <12000000>;
+};
+
+slimbus_clk: slimbus_clk at 4a004108 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&slimbus_src_clk>;
+	bit-shift = <10>;
+	reg = <0x4a004108 0x4>;
+};
+
+sys_32k_ck: sys_32k_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <32768>;
+};
+
+virt_12000000_ck: virt_12000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <12000000>;
+};
+
+virt_13000000_ck: virt_13000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <13000000>;
+};
+
+virt_16800000_ck: virt_16800000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <16800000>;
+};
+
+virt_19200000_ck: virt_19200000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <19200000>;
+};
+
+virt_26000000_ck: virt_26000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <26000000>;
+};
+
+virt_27000000_ck: virt_27000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <27000000>;
+};
+
+virt_38400000_ck: virt_38400000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <38400000>;
+};
+
+sys_clkin: sys_clkin at 4ae06110 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&virt_12000000_ck>, <&virt_13000000_ck>, <&virt_16800000_ck>, <&virt_19200000_ck>, <&virt_26000000_ck>, <&virt_27000000_ck>, <&virt_38400000_ck>;
+	reg = <0x4ae06110 0x4>;
+	bit-mask = <0x7>;
+	index-starts-at-one;
+};
+
+xclk60mhsp1_ck: xclk60mhsp1_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <60000000>;
+};
+
+xclk60mhsp2_ck: xclk60mhsp2_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <60000000>;
+};
+
+abe_dpll_bypass_clk_mux: abe_dpll_bypass_clk_mux at 4ae06108 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&sys_32k_ck>;
+	reg = <0x4ae06108 0x4>;
+	bit-mask = <0x1>;
+};
+
+abe_dpll_clk_mux: abe_dpll_clk_mux at 4ae0610c {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&sys_32k_ck>;
+	reg = <0x4ae0610c 0x4>;
+	bit-mask = <0x1>;
+};
+
+dpll_abe_ck: dpll_abe_ck at 4a0041e0 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&abe_dpll_clk_mux>, <&abe_dpll_bypass_clk_mux>;
+	reg = <0x4a0041e0 0x4>, <0x4a0041e4 0x4>, <0x4a0041e8 0x4>, <0x4a0041ec 0x4>;
+	ti,clk-ref = <&abe_dpll_clk_mux>;
+	ti,clk-bypass = <&abe_dpll_bypass_clk_mux>;
+	ti,dpll-regm4xen;
+};
+
+dpll_abe_x2_ck: dpll_abe_x2_ck {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_abe_ck>;
+	ti,dpll-clk-x2;
+};
+
+dpll_abe_m2x2_ck: dpll_abe_m2x2_ck at 4a0041f0 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0041f0 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+abe_24m_fclk: abe_24m_fclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_abe_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <8>;
+};
+
+abe_clk: abe_clk at 4a004108 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_m2x2_ck>;
+	reg = <0x4a004108 0x4>;
+	bit-mask = <0x3>;
+	index-power-of-two;
+};
+
+abe_iclk: abe_iclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&abe_clk>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+abe_lp_clk_div: abe_lp_clk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_abe_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <16>;
+};
+
+dpll_abe_m3x2_ck: dpll_abe_m3x2_ck at 4a0041f4 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0041f4 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_core_ck: dpll_core_ck at 4a004120 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin>, <&dpll_abe_m3x2_ck>;
+	reg = <0x4a004120 0x4>, <0x4a004124 0x4>, <0x4a004128 0x4>, <0x4a00412c 0x4>;
+	ti,clk-ref = <&sys_clkin>;
+	ti,clk-bypass = <&dpll_abe_m3x2_ck>;
+	ti,dpll-core;
+};
+
+dpll_core_x2_ck: dpll_core_x2_ck {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_core_ck>;
+	ti,dpll-clk-x2;
+};
+
+dpll_core_h21x2_ck: dpll_core_h21x2_ck at 4a004150 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a004150 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+c2c_fclk: c2c_fclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_h21x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+c2c_iclk: c2c_iclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&c2c_fclk>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+custefuse_sys_gfclk_div: custefuse_sys_gfclk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_clkin>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+dpll_core_h11x2_ck: dpll_core_h11x2_ck at 4a004138 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a004138 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_core_h12x2_ck: dpll_core_h12x2_ck at 4a00413c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a00413c 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_core_h13x2_ck: dpll_core_h13x2_ck at 4a004140 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a004140 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_core_h14x2_ck: dpll_core_h14x2_ck at 4a004144 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a004144 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_core_h22x2_ck: dpll_core_h22x2_ck at 4a004154 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a004154 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_core_h23x2_ck: dpll_core_h23x2_ck at 4a004158 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a004158 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_core_h24x2_ck: dpll_core_h24x2_ck at 4a00415c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a00415c 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_core_m2_ck: dpll_core_m2_ck at 4a004130 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a004130 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_core_m3x2_ck: dpll_core_m3x2_ck at 4a004134 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a004134 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+iva_dpll_hs_clk_div: iva_dpll_hs_clk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_h12x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll_iva_ck: dpll_iva_ck at 4a0041a0 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin>, <&iva_dpll_hs_clk_div>;
+	reg = <0x4a0041a0 0x4>, <0x4a0041a4 0x4>, <0x4a0041a8 0x4>, <0x4a0041ac 0x4>;
+	ti,clk-ref = <&sys_clkin>;
+	ti,clk-bypass = <&iva_dpll_hs_clk_div>;
+};
+
+dpll_iva_x2_ck: dpll_iva_x2_ck {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_iva_ck>;
+	ti,dpll-clk-x2;
+};
+
+dpll_iva_h11x2_ck: dpll_iva_h11x2_ck at 4a0041b8 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_iva_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0041b8 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_iva_h12x2_ck: dpll_iva_h12x2_ck at 4a0041bc {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_iva_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0041bc 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+mpu_dpll_hs_clk_div: mpu_dpll_hs_clk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_h12x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll_mpu_ck: dpll_mpu_ck at 4a004160 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin>, <&mpu_dpll_hs_clk_div>;
+	reg = <0x4a004160 0x4>, <0x4a004164 0x4>, <0x4a004168 0x4>, <0x4a00416c 0x4>;
+	ti,clk-ref = <&sys_clkin>;
+	ti,clk-bypass = <&mpu_dpll_hs_clk_div>;
+};
+
+dpll_mpu_m2_ck: dpll_mpu_m2_ck at 4a004170 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_mpu_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a004170 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+per_dpll_hs_clk_div: per_dpll_hs_clk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_abe_m3x2_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+dpll_per_ck: dpll_per_ck at 4a008140 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin>, <&per_dpll_hs_clk_div>;
+	reg = <0x4a008140 0x4>, <0x4a008144 0x4>, <0x4a008148 0x4>, <0x4a00814c 0x4>;
+	ti,clk-ref = <&sys_clkin>;
+	ti,clk-bypass = <&per_dpll_hs_clk_div>;
+};
+
+dpll_per_x2_ck: dpll_per_x2_ck {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_per_ck>;
+	ti,dpll-clk-x2;
+};
+
+dpll_per_h11x2_ck: dpll_per_h11x2_ck at 4a008158 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008158 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_per_h12x2_ck: dpll_per_h12x2_ck at 4a00815c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a00815c 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_per_h14x2_ck: dpll_per_h14x2_ck at 4a008164 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008164 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_per_m2_ck: dpll_per_m2_ck at 4a008150 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008150 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_per_m2x2_ck: dpll_per_m2x2_ck at 4a008150 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008150 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_per_m3x2_ck: dpll_per_m3x2_ck at 4a008154 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008154 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_unipro1_ck: dpll_unipro1_ck at 4a008200 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin>;
+	reg = <0x4a008200 0x4>, <0x4a008204 0x4>, <0x4a008208 0x4>, <0x4a00820c 0x4>;
+	ti,clk-ref = <&sys_clkin>;
+	ti,clk-bypass = <&sys_clkin>;
+};
+
+dpll_unipro1_clkdcoldo: dpll_unipro1_clkdcoldo {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_unipro1_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll_unipro1_m2_ck: dpll_unipro1_m2_ck at 4a008210 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_unipro1_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008210 0x4>;
+	bit-mask = <0x7f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_unipro2_ck: dpll_unipro2_ck at 4a0081c0 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin>;
+	reg = <0x4a0081c0 0x4>, <0x4a0081c4 0x4>, <0x4a0081c8 0x4>, <0x4a0081cc 0x4>;
+	ti,clk-ref = <&sys_clkin>;
+	ti,clk-bypass = <&sys_clkin>;
+};
+
+dpll_unipro2_clkdcoldo: dpll_unipro2_clkdcoldo {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_unipro2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll_unipro2_m2_ck: dpll_unipro2_m2_ck at 4a0081d0 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_unipro2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0081d0 0x4>;
+	bit-mask = <0x7f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+usb_dpll_hs_clk_div: usb_dpll_hs_clk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_abe_m3x2_ck>;
+	clock-mult = <1>;
+	clock-div = <3>;
+};
+
+dpll_usb_ck: dpll_usb_ck at 4a008180 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin>, <&usb_dpll_hs_clk_div>;
+	ti,clk-bypass = <&usb_dpll_hs_clk_div>;
+	reg = <0x4a008180 0x4>, <0x4a008184 0x4>, <0x4a008188 0x4>, <0x4a00818c 0x4>;
+	ti,clk-ref = <&sys_clkin>;
+	ti,clkdm-name = "l3init_clkdm";
+	ti,dpll-j-type;
+};
+
+dpll_usb_clkdcoldo: dpll_usb_clkdcoldo {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_usb_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll_usb_m2_ck: dpll_usb_m2_ck at 4a008190 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_usb_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008190 0x4>;
+	bit-mask = <0x7f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dss_syc_gfclk_div: dss_syc_gfclk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_clkin>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+func_128m_clk: func_128m_clk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_h11x2_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+func_12m_fclk: func_12m_fclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <16>;
+};
+
+func_24m_clk: func_24m_clk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <4>;
+};
+
+func_48m_fclk: func_48m_fclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <4>;
+};
+
+func_96m_fclk: func_96m_fclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+l3_iclk_div: l3_iclk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_h12x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+gpu_l3_iclk: gpu_l3_iclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&l3_iclk_div>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+l3init_60m_fclk: l3init_60m_fclk at 4a008104 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_usb_m2_ck>;
+	reg = <0x4a008104 0x4>;
+	table = < 1 0 >, < 8 1 >;
+	bit-mask = <0x1>;
+};
+
+wkupaon_iclk_mux: wkupaon_iclk_mux at 4ae06108 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&abe_lp_clk_div>;
+	reg = <0x4ae06108 0x4>;
+	bit-mask = <0x1>;
+};
+
+l3instr_ts_gclk_div: l3instr_ts_gclk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&wkupaon_iclk_mux>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+l4_root_clk_div: l4_root_clk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&l3_iclk_div>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dss_32khz_clk: dss_32khz_clk at 4a009420 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <11>;
+	reg = <0x4a009420 0x4>;
+};
+
+dss_48mhz_clk: dss_48mhz_clk at 4a009420 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&func_48m_fclk>;
+	bit-shift = <9>;
+	reg = <0x4a009420 0x4>;
+};
+
+dss_dss_clk: dss_dss_clk at 4a009420 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_per_h12x2_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009420 0x4>;
+};
+
+dss_sys_clk: dss_sys_clk at 4a009420 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dss_syc_gfclk_div>;
+	bit-shift = <10>;
+	reg = <0x4a009420 0x4>;
+};
+
+gpio1_dbclk: gpio1_dbclk at 4ae07938 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4ae07938 0x4>;
+};
+
+gpio2_dbclk: gpio2_dbclk at 4a009060 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009060 0x4>;
+};
+
+gpio3_dbclk: gpio3_dbclk at 4a009068 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009068 0x4>;
+};
+
+gpio4_dbclk: gpio4_dbclk at 4a009070 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009070 0x4>;
+};
+
+gpio5_dbclk: gpio5_dbclk at 4a009078 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009078 0x4>;
+};
+
+gpio6_dbclk: gpio6_dbclk at 4a009080 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009080 0x4>;
+};
+
+gpio7_dbclk: gpio7_dbclk at 4a009110 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009110 0x4>;
+};
+
+gpio8_dbclk: gpio8_dbclk at 4a009118 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009118 0x4>;
+};
+
+iss_ctrlclk: iss_ctrlclk at 4a009320 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&func_96m_fclk>;
+	bit-shift = <8>;
+	reg = <0x4a009320 0x4>;
+};
+
+lli_txphy_clk: lli_txphy_clk at 4a008f20 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_unipro1_clkdcoldo>;
+	bit-shift = <8>;
+	reg = <0x4a008f20 0x4>;
+};
+
+lli_txphy_ls_clk: lli_txphy_ls_clk at 4a008f20 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_unipro1_m2_ck>;
+	bit-shift = <9>;
+	reg = <0x4a008f20 0x4>;
+};
+
+mmc1_32khz_clk: mmc1_32khz_clk at 4a009628 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009628 0x4>;
+};
+
+sata_ref_clk: sata_ref_clk at 4a009688 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_clkin>;
+	bit-shift = <8>;
+	reg = <0x4a009688 0x4>;
+};
+
+slimbus1_slimbus_clk: slimbus1_slimbus_clk at 4a004560 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&slimbus_clk>;
+	bit-shift = <11>;
+	reg = <0x4a004560 0x4>;
+};
+
+usb_host_hs_hsic480m_p1_clk: usb_host_hs_hsic480m_p1_clk at 4a009658 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_usb_m2_ck>;
+	bit-shift = <13>;
+	reg = <0x4a009658 0x4>;
+};
+
+usb_host_hs_hsic480m_p2_clk: usb_host_hs_hsic480m_p2_clk at 4a009658 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_usb_m2_ck>;
+	bit-shift = <14>;
+	reg = <0x4a009658 0x4>;
+};
+
+usb_host_hs_hsic480m_p3_clk: usb_host_hs_hsic480m_p3_clk at 4a009658 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_usb_m2_ck>;
+	bit-shift = <7>;
+	reg = <0x4a009658 0x4>;
+};
+
+usb_host_hs_hsic60m_p1_clk: usb_host_hs_hsic60m_p1_clk at 4a009658 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l3init_60m_fclk>;
+	bit-shift = <11>;
+	reg = <0x4a009658 0x4>;
+};
+
+usb_host_hs_hsic60m_p2_clk: usb_host_hs_hsic60m_p2_clk at 4a009658 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l3init_60m_fclk>;
+	bit-shift = <12>;
+	reg = <0x4a009658 0x4>;
+};
+
+usb_host_hs_hsic60m_p3_clk: usb_host_hs_hsic60m_p3_clk at 4a009658 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l3init_60m_fclk>;
+	bit-shift = <6>;
+	reg = <0x4a009658 0x4>;
+};
+
+utmi_p1_gfclk: utmi_p1_gfclk at 4a009658 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&l3init_60m_fclk>, <&xclk60mhsp1_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009658 0x4>;
+	bit-mask = <0x1>;
+};
+
+usb_host_hs_utmi_p1_clk: usb_host_hs_utmi_p1_clk at 4a009658 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&utmi_p1_gfclk>;
+	bit-shift = <8>;
+	reg = <0x4a009658 0x4>;
+};
+
+utmi_p2_gfclk: utmi_p2_gfclk at 4a009658 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&l3init_60m_fclk>, <&xclk60mhsp2_ck>;
+	bit-shift = <25>;
+	reg = <0x4a009658 0x4>;
+	bit-mask = <0x1>;
+};
+
+usb_host_hs_utmi_p2_clk: usb_host_hs_utmi_p2_clk at 4a009658 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&utmi_p2_gfclk>;
+	bit-shift = <9>;
+	reg = <0x4a009658 0x4>;
+};
+
+usb_host_hs_utmi_p3_clk: usb_host_hs_utmi_p3_clk at 4a009658 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l3init_60m_fclk>;
+	bit-shift = <10>;
+	reg = <0x4a009658 0x4>;
+};
+
+usb_otg_ss_refclk960m: usb_otg_ss_refclk960m at 4a0096f0 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_usb_clkdcoldo>;
+	bit-shift = <8>;
+	reg = <0x4a0096f0 0x4>;
+};
+
+usb_phy_cm_clk32k: usb_phy_cm_clk32k at 4a008640 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a008640 0x4>;
+};
+
+usb_tll_hs_usb_ch0_clk: usb_tll_hs_usb_ch0_clk at 4a009668 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l3init_60m_fclk>;
+	bit-shift = <8>;
+	reg = <0x4a009668 0x4>;
+};
+
+usb_tll_hs_usb_ch1_clk: usb_tll_hs_usb_ch1_clk at 4a009668 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l3init_60m_fclk>;
+	bit-shift = <9>;
+	reg = <0x4a009668 0x4>;
+};
+
+usb_tll_hs_usb_ch2_clk: usb_tll_hs_usb_ch2_clk at 4a009668 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&l3init_60m_fclk>;
+	bit-shift = <10>;
+	reg = <0x4a009668 0x4>;
+};
+
+aess_fclk: aess_fclk at 4a004528 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&abe_clk>;
+	bit-shift = <24>;
+	reg = <0x4a004528 0x4>;
+	bit-mask = <0x1>;
+};
+
+dmic_sync_mux_ck: dmic_sync_mux_ck at 4a004538 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&dss_syc_gfclk_div>, <&func_24m_clk>;
+	bit-shift = <26>;
+	reg = <0x4a004538 0x4>;
+	bit-mask = <0x3>;
+};
+
+dmic_gfclk: dmic_gfclk at 4a004538 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dmic_sync_mux_ck>, <&pad_clks_ck>, <&slimbus_clk>;
+	bit-shift = <24>;
+	reg = <0x4a004538 0x4>;
+	bit-mask = <0x3>;
+};
+
+fdif_fclk: fdif_fclk at 4a009328 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_h11x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009328 0x4>;
+	bit-mask = <0x1>;
+};
+
+gpu_core_gclk_mux: gpu_core_gclk_mux at 4a009520 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dpll_core_h14x2_ck>, <&dpll_per_h14x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009520 0x4>;
+	bit-mask = <0x1>;
+};
+
+gpu_hyd_gclk_mux: gpu_hyd_gclk_mux at 4a009520 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dpll_core_h14x2_ck>, <&dpll_per_h14x2_ck>;
+	bit-shift = <25>;
+	reg = <0x4a009520 0x4>;
+	bit-mask = <0x1>;
+};
+
+hsi_fclk: hsi_fclk at 4a009638 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009638 0x4>;
+	bit-mask = <0x1>;
+};
+
+mcasp_sync_mux_ck: mcasp_sync_mux_ck at 4a004540 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&dss_syc_gfclk_div>, <&func_24m_clk>;
+	bit-shift = <26>;
+	reg = <0x4a004540 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcasp_gfclk: mcasp_gfclk at 4a004540 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&mcasp_sync_mux_ck>, <&pad_clks_ck>, <&slimbus_clk>;
+	bit-shift = <24>;
+	reg = <0x4a004540 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcbsp1_sync_mux_ck: mcbsp1_sync_mux_ck at 4a004548 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&dss_syc_gfclk_div>, <&func_24m_clk>;
+	bit-shift = <26>;
+	reg = <0x4a004548 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcbsp1_gfclk: mcbsp1_gfclk at 4a004548 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&mcbsp1_sync_mux_ck>, <&pad_clks_ck>, <&slimbus_clk>;
+	bit-shift = <24>;
+	reg = <0x4a004548 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcbsp2_sync_mux_ck: mcbsp2_sync_mux_ck at 4a004550 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&dss_syc_gfclk_div>, <&func_24m_clk>;
+	bit-shift = <26>;
+	reg = <0x4a004550 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcbsp2_gfclk: mcbsp2_gfclk at 4a004550 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&mcbsp2_sync_mux_ck>, <&pad_clks_ck>, <&slimbus_clk>;
+	bit-shift = <24>;
+	reg = <0x4a004550 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcbsp3_sync_mux_ck: mcbsp3_sync_mux_ck at 4a004558 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&dss_syc_gfclk_div>, <&func_24m_clk>;
+	bit-shift = <26>;
+	reg = <0x4a004558 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcbsp3_gfclk: mcbsp3_gfclk at 4a004558 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&mcbsp3_sync_mux_ck>, <&pad_clks_ck>, <&slimbus_clk>;
+	bit-shift = <24>;
+	reg = <0x4a004558 0x4>;
+	bit-mask = <0x3>;
+};
+
+mmc1_fclk_mux: mmc1_fclk_mux at 4a009628 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_128m_clk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009628 0x4>;
+	bit-mask = <0x1>;
+};
+
+mmc1_fclk: mmc1_fclk at 4a009628 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&mmc1_fclk_mux>;
+	bit-shift = <25>;
+	reg = <0x4a009628 0x4>;
+	bit-mask = <0x1>;
+};
+
+mmc2_fclk_mux: mmc2_fclk_mux at 4a009630 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_128m_clk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009630 0x4>;
+	bit-mask = <0x1>;
+};
+
+mmc2_fclk: mmc2_fclk at 4a009630 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&mmc2_fclk_mux>;
+	bit-shift = <25>;
+	reg = <0x4a009630 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer10_gfclk_mux: timer10_gfclk_mux at 4a009028 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009028 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer11_gfclk_mux: timer11_gfclk_mux at 4a009030 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009030 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer1_gfclk_mux: timer1_gfclk_mux at 4ae07940 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4ae07940 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer2_gfclk_mux: timer2_gfclk_mux at 4a009038 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009038 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer3_gfclk_mux: timer3_gfclk_mux at 4a009040 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009040 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer4_gfclk_mux: timer4_gfclk_mux at 4a009048 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009048 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer5_gfclk_mux: timer5_gfclk_mux at 4a004568 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dss_syc_gfclk_div>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a004568 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer6_gfclk_mux: timer6_gfclk_mux at 4a004570 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dss_syc_gfclk_div>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a004570 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer7_gfclk_mux: timer7_gfclk_mux at 4a004578 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dss_syc_gfclk_div>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a004578 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer8_gfclk_mux: timer8_gfclk_mux at 4a004580 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dss_syc_gfclk_div>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a004580 0x4>;
+	bit-mask = <0x1>;
+};
+
+timer9_gfclk_mux: timer9_gfclk_mux at 4a009050 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&sys_32k_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009050 0x4>;
+	bit-mask = <0x1>;
+};
+
+auxclk0_src_mux_ck: auxclk0_src_mux_ck at 4ae0a310 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&dpll_core_m3x2_ck>, <&dpll_per_m3x2_ck>;
+	bit-shift = <1>;
+	reg = <0x4ae0a310 0x4>;
+	bit-mask = <0x3>;
+};
+
+auxclk0_src_ck: auxclk0_src_ck at 4ae0a310 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&auxclk0_src_mux_ck>;
+	bit-shift = <8>;
+	reg = <0x4ae0a310 0x4>;
+};
+
+auxclk0_ck: auxclk0_ck at 4ae0a310 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&auxclk0_src_ck>;
+	bit-shift = <16>;
+	reg = <0x4ae0a310 0x4>;
+	bit-mask = <0xf>;
+};
+
+auxclk1_src_mux_ck: auxclk1_src_mux_ck at 4ae0a314 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&dpll_core_m3x2_ck>, <&dpll_per_m3x2_ck>;
+	bit-shift = <1>;
+	reg = <0x4ae0a314 0x4>;
+	bit-mask = <0x3>;
+};
+
+auxclk1_src_ck: auxclk1_src_ck at 4ae0a314 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&auxclk1_src_mux_ck>;
+	bit-shift = <8>;
+	reg = <0x4ae0a314 0x4>;
+};
+
+auxclk1_ck: auxclk1_ck at 4ae0a314 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&auxclk1_src_ck>;
+	bit-shift = <16>;
+	reg = <0x4ae0a314 0x4>;
+	bit-mask = <0xf>;
+};
+
+auxclk2_src_mux_ck: auxclk2_src_mux_ck at 4ae0a318 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&dpll_core_m3x2_ck>, <&dpll_per_m3x2_ck>;
+	bit-shift = <1>;
+	reg = <0x4ae0a318 0x4>;
+	bit-mask = <0x3>;
+};
+
+auxclk2_src_ck: auxclk2_src_ck at 4ae0a318 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&auxclk2_src_mux_ck>;
+	bit-shift = <8>;
+	reg = <0x4ae0a318 0x4>;
+};
+
+auxclk2_ck: auxclk2_ck at 4ae0a318 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&auxclk2_src_ck>;
+	bit-shift = <16>;
+	reg = <0x4ae0a318 0x4>;
+	bit-mask = <0xf>;
+};
+
+auxclk3_src_mux_ck: auxclk3_src_mux_ck at 4ae0a31c {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&dpll_core_m3x2_ck>, <&dpll_per_m3x2_ck>;
+	bit-shift = <1>;
+	reg = <0x4ae0a31c 0x4>;
+	bit-mask = <0x3>;
+};
+
+auxclk3_src_ck: auxclk3_src_ck at 4ae0a31c {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&auxclk3_src_mux_ck>;
+	bit-shift = <8>;
+	reg = <0x4ae0a31c 0x4>;
+};
+
+auxclk3_ck: auxclk3_ck at 4ae0a31c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&auxclk3_src_ck>;
+	bit-shift = <16>;
+	reg = <0x4ae0a31c 0x4>;
+	bit-mask = <0xf>;
+};
+
+auxclk4_src_mux_ck: auxclk4_src_mux_ck at 4ae0a320 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin>, <&dpll_core_m3x2_ck>, <&dpll_per_m3x2_ck>;
+	bit-shift = <1>;
+	reg = <0x4ae0a320 0x4>;
+	bit-mask = <0x3>;
+};
+
+auxclk4_src_ck: auxclk4_src_ck at 4ae0a320 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&auxclk4_src_mux_ck>;
+	bit-shift = <8>;
+	reg = <0x4ae0a320 0x4>;
+};
+
+auxclk4_ck: auxclk4_ck at 4ae0a320 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&auxclk4_src_ck>;
+	bit-shift = <16>;
+	reg = <0x4ae0a320 0x4>;
+	bit-mask = <0xf>;
+};
+
+auxclkreq0_ck: auxclkreq0_ck at 4ae0a210 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&auxclk0_ck>, <&auxclk1_ck>, <&auxclk2_ck>, <&auxclk3_ck>, <&auxclk4_ck>;
+	bit-shift = <2>;
+	reg = <0x4ae0a210 0x4>;
+	bit-mask = <0x7>;
+};
+
+auxclkreq1_ck: auxclkreq1_ck at 4ae0a214 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&auxclk0_ck>, <&auxclk1_ck>, <&auxclk2_ck>, <&auxclk3_ck>, <&auxclk4_ck>;
+	bit-shift = <2>;
+	reg = <0x4ae0a214 0x4>;
+	bit-mask = <0x7>;
+};
+
+auxclkreq2_ck: auxclkreq2_ck at 4ae0a218 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&auxclk0_ck>, <&auxclk1_ck>, <&auxclk2_ck>, <&auxclk3_ck>, <&auxclk4_ck>;
+	bit-shift = <2>;
+	reg = <0x4ae0a218 0x4>;
+	bit-mask = <0x7>;
+};
+
+auxclkreq3_ck: auxclkreq3_ck at 4ae0a21c {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&auxclk0_ck>, <&auxclk1_ck>, <&auxclk2_ck>, <&auxclk3_ck>, <&auxclk4_ck>;
+	bit-shift = <2>;
+	reg = <0x4ae0a21c 0x4>;
+	bit-mask = <0x7>;
+};
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:14 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:14 +0300
Subject: [PATCHv4 19/33] CLK: omap: add am33xx clock init file
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-20-git-send-email-t-kristo@ti.com>

clk-33xx.c now contains the clock init functionality for am33xx, including
DT clock registration and adding of static clkdev entries.

This patch also moves the omap2_clk_enable_init_clocks declaration to
the driver include, as this is needed by the am33xx clock init code.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 arch/arm/mach-omap2/clock.h |    1 -
 drivers/clk/omap/clk-33xx.c |   85 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/clk/omap.h    |    1 +
 3 files changed, 86 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/omap/clk-33xx.c

diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index d1a3125..6273f14 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -267,7 +267,6 @@ void omap2_clk_dflt_find_idlest(struct clk_hw_omap *clk,
 				void __iomem **idlest_reg,
 				u8 *idlest_bit, u8 *idlest_val);
 int omap2_clk_enable_autoidle_all(void);
-void omap2_clk_enable_init_clocks(const char **clk_names, u8 num_clocks);
 int omap2_clk_switch_mpurate_at_boot(const char *mpurate_ck_name);
 void omap2_clk_print_new_rates(const char *hfclkin_ck_name,
 			       const char *core_ck_name,
diff --git a/drivers/clk/omap/clk-33xx.c b/drivers/clk/omap/clk-33xx.c
new file mode 100644
index 0000000..3ada30e
--- /dev/null
+++ b/drivers/clk/omap/clk-33xx.c
@@ -0,0 +1,85 @@
+/*
+ * AM33XX Clock init
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc
+ *     Tero Kristo (t-kristo at ti.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/clk-provider.h>
+#include <linux/clk/omap.h>
+
+
+static struct omap_dt_clk am33xx_clks[] = {
+	DT_CLK("cpu0", NULL, "dpll_mpu_ck"),
+	DT_CLK("481cc000.d_can", NULL, "dcan0_fck"),
+	DT_CLK("481d0000.d_can", NULL, "dcan1_fck"),
+	DT_CLK(NULL, "timer_32k_ck", "clkdiv32k_ick"),
+	DT_CLK(NULL, "timer_sys_ck", "sys_clkin_ck"),
+	DT_CLK("48300200.ehrpwm", "tbclk", "ehrpwm0_tbclk"),
+	DT_CLK("48302200.ehrpwm", "tbclk", "ehrpwm1_tbclk"),
+	DT_CLK("48304200.ehrpwm", "tbclk", "ehrpwm2_tbclk"),
+};
+
+static const char *enable_init_clks[] = {
+	"dpll_ddr_m2_ck",
+	"dpll_mpu_m2_ck",
+	"l3_gclk",
+	"l4hs_gclk",
+	"l4fw_gclk",
+	"l4ls_gclk",
+	/* Required for external peripherals like, Audio codecs */
+	"clkout2_ck",
+};
+
+int __init am33xx_clk_init(void)
+{
+	struct clk *clk1, *clk2;
+
+	dt_omap_clk_init();
+
+	omap_dt_clocks_register(am33xx_clks, ARRAY_SIZE(am33xx_clks));
+
+	omap2_clk_disable_autoidle_all();
+
+	omap2_clk_enable_init_clocks(enable_init_clks,
+				     ARRAY_SIZE(enable_init_clks));
+
+	/* TRM ERRATA: Timer 3 & 6 default parent (TCLKIN) may not be always
+	 *    physically present, in such a case HWMOD enabling of
+	 *    clock would be failure with default parent. And timer
+	 *    probe thinks clock is already enabled, this leads to
+	 *    crash upon accessing timer 3 & 6 registers in probe.
+	 *    Fix by setting parent of both these timers to master
+	 *    oscillator clock.
+	 */
+
+	clk1 = clk_get_sys(NULL, "sys_clkin_ck");
+	clk2 = clk_get_sys(NULL, "timer3_fck");
+	clk_set_parent(clk2, clk1);
+
+	clk2 = clk_get_sys(NULL, "timer6_fck");
+	clk_set_parent(clk2, clk1);
+	/*
+	 * The On-Chip 32K RC Osc clock is not an accurate clock-source as per
+	 * the design/spec, so as a result, for example, timer which supposed
+	 * to get expired @60Sec, but will expire somewhere ~@40Sec, which is
+	 * not expected by any use-case, so change WDT1 clock source to PRCM
+	 * 32KHz clock.
+	 */
+	clk1 = clk_get_sys(NULL, "wdt1_fck");
+	clk2 = clk_get_sys(NULL, "clkdiv32k_ick");
+	clk_set_parent(clk1, clk2);
+
+	return 0;
+}
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
index 58ebb80..c8d9468 100644
--- a/include/linux/clk/omap.h
+++ b/include/linux/clk/omap.h
@@ -184,6 +184,7 @@ int omap2_clkops_enable_clkdm(struct clk_hw *hw);
 void omap2_clkops_disable_clkdm(struct clk_hw *hw);
 
 int omap2_clk_disable_autoidle_all(void);
+void omap2_clk_enable_init_clocks(const char **clk_names, u8 num_clocks);
 
 extern const struct clk_hw_omap_ops clkhwops_omap3_dpll;
 extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx;
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:09 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:09 +0300
Subject: [PATCHv4 14/33] CLK: omap: add dra7 clock init file
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-15-git-send-email-t-kristo@ti.com>

clk-7xx.c now contains the clock init functionality for dra7, including
DT clock registration and adding of static clkdev entries.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 drivers/clk/omap/Makefile  |    2 +-
 drivers/clk/omap/clk-7xx.c |   67 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 68 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/omap/clk-7xx.c

diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 74385f2..b8dbfda 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1,2 +1,2 @@
 obj-y					+= clk.o dpll.o autoidle.o gate.o \
-					   clk-44xx.o clk-54xx.o
+					   clk-44xx.o clk-54xx.o clk-7xx.o
diff --git a/drivers/clk/omap/clk-7xx.c b/drivers/clk/omap/clk-7xx.c
new file mode 100644
index 0000000..ddb39dd
--- /dev/null
+++ b/drivers/clk/omap/clk-7xx.c
@@ -0,0 +1,67 @@
+/*
+ * DRA7 Clock init
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo (t-kristo at ti.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/clk-private.h>
+#include <linux/clkdev.h>
+#include <linux/io.h>
+#include <linux/clk/omap.h>
+
+#define DRA7_DPLL_ABE_DEFFREQ				361267200
+#define DRA7_DPLL_GMAC_DEFFREQ				1000000000
+
+
+static struct omap_dt_clk dra7xx_clks[] = {
+	DT_CLK(NULL, "timer_32k_ck", "sys_32k_ck"),
+	DT_CLK("4ae18000.timer", "timer_sys_ck", "sys_clkin2"),
+	DT_CLK("48032000.timer", "timer_sys_ck", "sys_clkin2"),
+	DT_CLK("48034000.timer", "timer_sys_ck", "sys_clkin2"),
+	DT_CLK("48036000.timer", "timer_sys_ck", "sys_clkin2"),
+	DT_CLK("4803e000.timer", "timer_sys_ck", "sys_clkin2"),
+	DT_CLK("48086000.timer", "timer_sys_ck", "sys_clkin2"),
+	DT_CLK("48088000.timer", "timer_sys_ck", "sys_clkin2"),
+	DT_CLK("48820000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+	DT_CLK("48822000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+	DT_CLK("48824000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+	DT_CLK("48826000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+	DT_CLK(NULL, "sys_clkin", "sys_clkin1"),
+};
+
+int __init dra7xx_clk_init(void)
+{
+	int rc;
+	struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck;
+
+	dt_omap_clk_init();
+
+	omap_dt_clocks_register(dra7xx_clks, ARRAY_SIZE(dra7xx_clks));
+
+	omap2_clk_disable_autoidle_all();
+
+	abe_dpll_mux = clk_get_sys(NULL, "abe_dpll_sys_clk_mux");
+	sys_clkin2 = clk_get_sys(NULL, "sys_clkin2");
+	dpll_ck = clk_get_sys(NULL, "dpll_abe_ck");
+
+	rc = clk_set_parent(abe_dpll_mux, sys_clkin2);
+	if (!rc)
+		rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ);
+	if (rc)
+		pr_err("%s: failed to configure ABE DPLL!\n", __func__);
+
+	dpll_ck = clk_get_sys(NULL, "dpll_gmac_ck");
+	rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
+	if (rc)
+		pr_err("%s: failed to configure GMAC DPLL!\n", __func__);
+
+	return rc;
+}
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:11 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:11 +0300
Subject: [PATCHv4 16/33] CLK: OMAP: DPLL: do not of_iomap NULL autoidle
 register
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-17-git-send-email-t-kristo@ti.com>

AM33xx series SoCs do not have autoidle support, and for these the
autoidle register is marked as NULL. Check against a NULL pointer and
do not attempt to of_iomap in this case, as this just creates a bogus
pointer and causes a kernel crash during boot.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 drivers/clk/omap/dpll.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
index 1d24feada..d8a958a 100644
--- a/drivers/clk/omap/dpll.c
+++ b/drivers/clk/omap/dpll.c
@@ -162,6 +162,7 @@ static void __init of_omap_dpll_setup(struct device_node *node,
 	u32 max_multiplier = 2047;
 	u32 max_divider = 128;
 	u32 min_divider = 1;
+	u32 val;
 	int i;
 
 	dd = kzalloc(sizeof(struct dpll_data), GFP_KERNEL);
@@ -210,7 +211,14 @@ static void __init of_omap_dpll_setup(struct device_node *node,
 
 	dd->control_reg = of_iomap(node, 0);
 	dd->idlest_reg = of_iomap(node, 1);
-	dd->autoidle_reg = of_iomap(node, 2);
+	/*
+	 * AM33xx DPLLs have no autoidle support, and the autoidle reg
+	 * for these is NULL. Do not attempt to of_iomap in this case,
+	 * as this just creates a bogus pointer and crashes the kernel.
+	 */
+	of_property_read_u32_index(node, "reg", 2 * 2, &val);
+	if (val)
+		dd->autoidle_reg = of_iomap(node, 2);
 	dd->mult_div1_reg = of_iomap(node, 3);
 
 	dd->idlest_mask = idlest_mask;
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:13 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:13 +0300
Subject: [PATCHv4 18/33] ARM: dts: am33xx clock data
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-19-git-send-email-t-kristo@ti.com>

This patch creates a unique node for each clock in the AM33xx power,
reset and clock manager (PRCM).

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 arch/arm/boot/dts/am33xx-clocks.dtsi |  663 ++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/am33xx.dtsi        |    7 +
 2 files changed, 670 insertions(+)
 create mode 100644 arch/arm/boot/dts/am33xx-clocks.dtsi

diff --git a/arch/arm/boot/dts/am33xx-clocks.dtsi b/arch/arm/boot/dts/am33xx-clocks.dtsi
new file mode 100644
index 0000000..1b19443
--- /dev/null
+++ b/arch/arm/boot/dts/am33xx-clocks.dtsi
@@ -0,0 +1,663 @@
+/*
+ * Device Tree Source for AM33xx clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+clk_32768_ck: clk_32768_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <32768>;
+};
+
+clk_rc32k_ck: clk_rc32k_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <32000>;
+};
+
+virt_19200000_ck: virt_19200000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <19200000>;
+};
+
+virt_24000000_ck: virt_24000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <24000000>;
+};
+
+virt_25000000_ck: virt_25000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <25000000>;
+};
+
+virt_26000000_ck: virt_26000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <26000000>;
+};
+
+sys_clkin_ck: sys_clkin_ck at 44e10040 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&virt_19200000_ck>, <&virt_24000000_ck>, <&virt_25000000_ck>, <&virt_26000000_ck>;
+	bit-shift = <22>;
+	reg = <0x44e10040 0x4>;
+	bit-mask = <0x3>;
+};
+
+tclkin_ck: tclkin_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <12000000>;
+};
+
+dpll_core_ck: dpll_core_ck at 44e00490 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin_ck>;
+	reg = <0x44e00490 0x4>, <0x44e0045c 0x4>, <0x0 0x4>, <0x44e00468 0x4>;
+	ti,clk-ref = <&sys_clkin_ck>;
+	ti,clk-bypass = <&sys_clkin_ck>;
+	ti,dpll-core;
+};
+
+dpll_core_x2_ck: dpll_core_x2_ck {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_core_ck>;
+	ti,dpll-clk-x2;
+};
+
+dpll_core_m4_ck: dpll_core_m4_ck at 44e00480 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	reg = <0x44e00480 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+dpll_core_m5_ck: dpll_core_m5_ck at 44e00484 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	reg = <0x44e00484 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+dpll_core_m6_ck: dpll_core_m6_ck at 44e004d8 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	reg = <0x44e004d8 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+dpll_mpu_ck: dpll_mpu_ck at 44e00488 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin_ck>;
+	reg = <0x44e00488 0x4>, <0x44e00420 0x4>, <0x0 0x4>, <0x44e0042c 0x4>;
+	ti,clk-ref = <&sys_clkin_ck>;
+	ti,clk-bypass = <&sys_clkin_ck>;
+};
+
+dpll_mpu_m2_ck: dpll_mpu_m2_ck at 44e004a8 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_mpu_ck>;
+	reg = <0x44e004a8 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+dpll_ddr_ck: dpll_ddr_ck at 44e00494 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin_ck>;
+	reg = <0x44e00494 0x4>, <0x44e00434 0x4>, <0x0 0x4>, <0x44e00440 0x4>;
+	ti,clk-ref = <&sys_clkin_ck>;
+	ti,clk-bypass = <&sys_clkin_ck>;
+	ti,dpll-no-gate;
+};
+
+dpll_ddr_m2_ck: dpll_ddr_m2_ck at 44e004a0 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_ddr_ck>;
+	reg = <0x44e004a0 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+dpll_ddr_m2_div2_ck: dpll_ddr_m2_div2_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_ddr_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+dpll_disp_ck: dpll_disp_ck at 44e00498 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin_ck>;
+	reg = <0x44e00498 0x4>, <0x44e00448 0x4>, <0x0 0x4>, <0x44e00454 0x4>;
+	ti,clk-ref = <&sys_clkin_ck>;
+	ti,clk-bypass = <&sys_clkin_ck>;
+	ti,dpll-no-gate;
+};
+
+dpll_disp_m2_ck: dpll_disp_m2_ck at 44e004a4 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_disp_ck>;
+	reg = <0x44e004a4 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	set-rate-parent;
+};
+
+dpll_per_ck: dpll_per_ck at 44e0048c {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin_ck>;
+	reg = <0x44e0048c 0x4>, <0x44e00470 0x4>, <0x0 0x4>, <0x44e0049c 0x4>;
+	ti,clk-ref = <&sys_clkin_ck>;
+	ti,clk-bypass = <&sys_clkin_ck>;
+	ti,dpll-no-gate;
+};
+
+dpll_per_m2_ck: dpll_per_m2_ck at 44e004ac {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_ck>;
+	reg = <0x44e004ac 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+dpll_per_m2_div4_wkupdm_ck: dpll_per_m2_div4_wkupdm_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <4>;
+};
+
+dpll_per_m2_div4_ck: dpll_per_m2_div4_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <4>;
+};
+
+adc_tsc_fck: adc_tsc_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+cefuse_fck: cefuse_fck at 44e00a20 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_clkin_ck>;
+	bit-shift = <1>;
+	reg = <0x44e00a20 0x4>;
+};
+
+clk_24mhz: clk_24mhz {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <8>;
+};
+
+clkdiv32k_ck: clkdiv32k_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&clk_24mhz>;
+	clock-mult = <1>;
+	clock-div = <732>;
+};
+
+clkdiv32k_ick: clkdiv32k_ick at 44e0014c {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&clkdiv32k_ck>;
+	reg = <0x44e0014c 0x4>;
+	bit-shift = <1>;
+};
+
+dcan0_fck: dcan0_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dcan1_fck: dcan1_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+l3_gclk: l3_gclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_m4_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+pruss_ocp_gclk: pruss_ocp_gclk at 44e00530 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&l3_gclk>, <&dpll_disp_m2_ck>;
+	reg = <0x44e00530 0x4>;
+	bit-mask = <0x1>;
+};
+
+mcasp0_fck: mcasp0_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+mcasp1_fck: mcasp1_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+mmu_fck: mmu_fck at 44e00914 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_core_m4_ck>;
+	bit-shift = <1>;
+	reg = <0x44e00914 0x4>;
+};
+
+smartreflex0_fck: smartreflex0_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+smartreflex1_fck: smartreflex1_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+sha0_fck: sha0_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+aes0_fck: aes0_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+timer1_fck: timer1_fck at 44e00528 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin_ck>, <&clkdiv32k_ick>, <&tclkin_ck>, <&clk_rc32k_ck>, <&clk_32768_ck>;
+	reg = <0x44e00528 0x4>;
+	bit-mask = <0x7>;
+};
+
+timer2_fck: timer2_fck at 44e00508 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>;
+	reg = <0x44e00508 0x4>;
+	bit-mask = <0x3>;
+};
+
+timer3_fck: timer3_fck at 44e0050c {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>;
+	reg = <0x44e0050c 0x4>;
+	bit-mask = <0x3>;
+};
+
+timer4_fck: timer4_fck at 44e00510 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>;
+	reg = <0x44e00510 0x4>;
+	bit-mask = <0x3>;
+};
+
+timer5_fck: timer5_fck at 44e00518 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>;
+	reg = <0x44e00518 0x4>;
+	bit-mask = <0x3>;
+};
+
+timer6_fck: timer6_fck at 44e0051c {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>;
+	reg = <0x44e0051c 0x4>;
+	bit-mask = <0x3>;
+};
+
+timer7_fck: timer7_fck at 44e00504 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&tclkin_ck>, <&sys_clkin_ck>, <&clkdiv32k_ick>;
+	reg = <0x44e00504 0x4>;
+	bit-mask = <0x3>;
+};
+
+usbotg_fck: usbotg_fck at 44e0047c {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_per_ck>;
+	bit-shift = <8>;
+	reg = <0x44e0047c 0x4>;
+};
+
+dpll_core_m4_div2_ck: dpll_core_m4_div2_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_m4_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+ieee5000_fck: ieee5000_fck at 44e000e4 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_core_m4_div2_ck>;
+	bit-shift = <1>;
+	reg = <0x44e000e4 0x4>;
+};
+
+wdt1_fck: wdt1_fck at 44e00538 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&clk_rc32k_ck>, <&clkdiv32k_ick>;
+	reg = <0x44e00538 0x4>;
+	bit-mask = <0x3>;
+};
+
+l4_rtc_gclk: l4_rtc_gclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_m4_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+l4hs_gclk: l4hs_gclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_m4_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+l3s_gclk: l3s_gclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_m4_div2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+l4fw_gclk: l4fw_gclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_m4_div2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+l4ls_gclk: l4ls_gclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_m4_div2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+sysclk_div_ck: sysclk_div_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_m4_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+cpsw_125mhz_gclk: cpsw_125mhz_gclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_m5_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+cpsw_cpts_rft_clk: cpsw_cpts_rft_clk at 44e00520 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dpll_core_m5_ck>, <&dpll_core_m4_ck>;
+	reg = <0x44e00520 0x4>;
+	bit-mask = <0x1>;
+};
+
+gpio0_dbclk_mux_ck: gpio0_dbclk_mux_ck at 44e0053c {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&clk_rc32k_ck>, <&clk_32768_ck>, <&clkdiv32k_ick>;
+	reg = <0x44e0053c 0x4>;
+	bit-mask = <0x3>;
+};
+
+gpio0_dbclk: gpio0_dbclk at 44e00408 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&gpio0_dbclk_mux_ck>;
+	bit-shift = <18>;
+	reg = <0x44e00408 0x4>;
+};
+
+gpio1_dbclk: gpio1_dbclk at 44e000ac {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&clkdiv32k_ick>;
+	bit-shift = <18>;
+	reg = <0x44e000ac 0x4>;
+};
+
+gpio2_dbclk: gpio2_dbclk at 44e000b0 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&clkdiv32k_ick>;
+	bit-shift = <18>;
+	reg = <0x44e000b0 0x4>;
+};
+
+gpio3_dbclk: gpio3_dbclk at 44e000b4 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&clkdiv32k_ick>;
+	bit-shift = <18>;
+	reg = <0x44e000b4 0x4>;
+};
+
+lcd_gclk: lcd_gclk at 44e00534 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dpll_disp_m2_ck>, <&dpll_core_m5_ck>, <&dpll_per_m2_ck>;
+	reg = <0x44e00534 0x4>;
+	bit-mask = <0x3>;
+	set-rate-parent;
+};
+
+mmc_clk: mmc_clk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+gfx_fclk_clksel_ck: gfx_fclk_clksel_ck at 44e0052c {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dpll_core_m4_ck>, <&dpll_per_m2_ck>;
+	bit-shift = <1>;
+	reg = <0x44e0052c 0x4>;
+	bit-mask = <0x1>;
+};
+
+gfx_fck_div_ck: gfx_fck_div_ck at 44e0052c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&gfx_fclk_clksel_ck>;
+	reg = <0x44e0052c 0x4>;
+	table = < 1 0 >, < 2 1 >;
+	bit-mask = <0x1>;
+};
+
+sysclkout_pre_ck: sysclkout_pre_ck at 44e00700 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&clk_32768_ck>, <&l3_gclk>, <&dpll_ddr_m2_ck>, <&dpll_per_m2_ck>, <&lcd_gclk>;
+	reg = <0x44e00700 0x4>;
+	bit-mask = <0x7>;
+};
+
+clkout2_div_ck: clkout2_div_ck at 44e00700 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&sysclkout_pre_ck>;
+	bit-shift = <3>;
+	reg = <0x44e00700 0x4>;
+	table = < 1 0 >, < 2 1 >, < 3 2 >, < 4 3 >, < 5 4 >, < 6 5 >, < 7 6 >, < 8 7 >;
+	bit-mask = <0x7>;
+};
+
+dbg_sysclk_ck: dbg_sysclk_ck at 44e00414 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_clkin_ck>;
+	bit-shift = <19>;
+	reg = <0x44e00414 0x4>;
+};
+
+dbg_clka_ck: dbg_clka_ck at 44e00414 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_core_m4_ck>;
+	bit-shift = <30>;
+	reg = <0x44e00414 0x4>;
+};
+
+stm_pmd_clock_mux_ck: stm_pmd_clock_mux_ck at 44e00414 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dbg_sysclk_ck>, <&dbg_clka_ck>;
+	bit-shift = <22>;
+	reg = <0x44e00414 0x4>;
+	bit-mask = <0x3>;
+};
+
+trace_pmd_clk_mux_ck: trace_pmd_clk_mux_ck at 44e00414 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dbg_sysclk_ck>, <&dbg_clka_ck>;
+	bit-shift = <20>;
+	reg = <0x44e00414 0x4>;
+	bit-mask = <0x3>;
+};
+
+stm_clk_div_ck: stm_clk_div_ck at 44e00414 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&stm_pmd_clock_mux_ck>;
+	bit-shift = <27>;
+	reg = <0x44e00414 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+trace_clk_div_ck: trace_clk_div_ck at 44e00414 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&trace_pmd_clk_mux_ck>;
+	bit-shift = <24>;
+	reg = <0x44e00414 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+clkout2_ck: clkout2_ck at 44e00700 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&clkout2_div_ck>;
+	bit-shift = <7>;
+	reg = <0x44e00700 0x4>;
+};
+
+ehrpwm0_tbclk: ehrpwm0_tbclk at 44e10664 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_per_m2_ck>;
+	bit-shift = <0>;
+	reg = <0x44e10664 0x4>;
+};
+
+ehrpwm1_tbclk: ehrpwm1_tbclk at 44e10664 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_per_m2_ck>;
+	bit-shift = <1>;
+	reg = <0x44e10664 0x4>;
+};
+
+ehrpwm2_tbclk: ehrpwm2_tbclk at 44e10664 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_per_m2_ck>;
+	bit-shift = <2>;
+	reg = <0x44e10664 0x4>;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..4701e3c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -531,4 +531,11 @@
 			status = "disabled";
 		};
 	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/include/ "am33xx-clocks.dtsi"
+	};
 };
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:16 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:16 +0300
Subject: [PATCHv4 21/33] CLK: OMAP: DPLL: add omap3 dpll support
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-22-git-send-email-t-kristo@ti.com>

OMAP3 has slightly different DPLLs from those compared to OMAP4. Modified
code for the same.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 drivers/clk/omap/dpll.c |   96 +++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 85 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
index d8a958a..ecb1fbd 100644
--- a/drivers/clk/omap/dpll.c
+++ b/drivers/clk/omap/dpll.c
@@ -26,6 +26,11 @@
 #include <linux/of_address.h>
 #include <linux/clk/omap.h>
 
+enum {
+	SUBTYPE_OMAP3_DPLL,
+	SUBTYPE_OMAP4_DPLL,
+};
+
 static const struct clk_ops dpll_m4xen_ck_ops = {
 	.enable		= &omap3_noncore_dpll_enable,
 	.disable	= &omap3_noncore_dpll_disable,
@@ -40,6 +45,13 @@ static const struct clk_ops dpll_core_ck_ops = {
 	.get_parent	= &omap2_init_dpll_parent,
 };
 
+static const struct clk_ops omap3_dpll_core_ck_ops = {
+	.init		= &omap2_init_clk_clkdm,
+	.get_parent	= &omap2_init_dpll_parent,
+	.recalc_rate	= &omap3_dpll_recalc,
+	.round_rate	= &omap2_dpll_round_rate,
+};
+
 static const struct clk_ops dpll_ck_ops = {
 	.enable		= &omap3_noncore_dpll_enable,
 	.disable	= &omap3_noncore_dpll_disable,
@@ -50,6 +62,26 @@ static const struct clk_ops dpll_ck_ops = {
 	.init		= &omap2_init_clk_clkdm,
 };
 
+static const struct clk_ops omap3_dpll_ck_ops = {
+	.init		= &omap2_init_clk_clkdm,
+	.enable		= &omap3_noncore_dpll_enable,
+	.disable	= &omap3_noncore_dpll_disable,
+	.get_parent	= &omap2_init_dpll_parent,
+	.recalc_rate	= &omap3_dpll_recalc,
+	.set_rate	= &omap3_noncore_dpll_set_rate,
+	.round_rate	= &omap2_dpll_round_rate,
+};
+
+static const struct clk_ops omap3_dpll_per_ck_ops = {
+	.init		= &omap2_init_clk_clkdm,
+	.enable		= &omap3_noncore_dpll_enable,
+	.disable	= &omap3_noncore_dpll_disable,
+	.get_parent	= &omap2_init_dpll_parent,
+	.recalc_rate	= &omap3_dpll_recalc,
+	.set_rate	= &omap3_dpll4_set_rate,
+	.round_rate	= &omap2_dpll_round_rate,
+};
+
 static const struct clk_ops dpll_x2_ck_ops = {
 	.recalc_rate	= &omap3_clkoutx2_recalc,
 };
@@ -144,7 +176,9 @@ struct clk *omap_clk_register_dpll_x2(struct device *dev, const char *name,
  * of_omap_dpll_setup() - Setup function for OMAP DPLL clocks
  */
 static void __init of_omap_dpll_setup(struct device_node *node,
-					const struct clk_ops *ops)
+					const struct clk_ops *ops, u32 freqsel,
+					u32 modes, u8 mul_div_shift,
+					int subtype)
 {
 	struct clk *clk;
 	const char *clk_name = node->name;
@@ -157,8 +191,8 @@ static void __init of_omap_dpll_setup(struct device_node *node,
 	u32 idlest_mask = 0x1;
 	u32 enable_mask = 0x7;
 	u32 autoidle_mask = 0x7;
-	u32 mult_mask = 0x7ff << 8;
-	u32 div1_mask = 0x7f;
+	u32 mult_mask = 0x7ff << (8 + mul_div_shift);
+	u32 div1_mask = 0x7f << mul_div_shift;
 	u32 max_multiplier = 2047;
 	u32 max_divider = 128;
 	u32 min_divider = 1;
@@ -193,7 +227,7 @@ static void __init of_omap_dpll_setup(struct device_node *node,
 
 	clkspec.np = of_parse_phandle(node, "ti,clk-ref", 0);
 	dd->clk_ref = of_clk_get_from_provider(&clkspec);
-	if (!dd->clk_ref) {
+	if (IS_ERR(dd->clk_ref)) {
 		pr_err("%s: ti,clk-ref for %s not found\n", __func__,
 			clk_name);
 		goto cleanup;
@@ -201,7 +235,7 @@ static void __init of_omap_dpll_setup(struct device_node *node,
 
 	clkspec.np = of_parse_phandle(node, "ti,clk-bypass", 0);
 	dd->clk_bypass = of_clk_get_from_provider(&clkspec);
-	if (!dd->clk_bypass) {
+	if (IS_ERR(dd->clk_bypass)) {
 		pr_err("%s: ti,clk-bypass for %s not found\n", __func__,
 			clk_name);
 		goto cleanup;
@@ -225,14 +259,31 @@ static void __init of_omap_dpll_setup(struct device_node *node,
 	dd->enable_mask = enable_mask;
 	dd->autoidle_mask = autoidle_mask;
 
-	dd->modes = 0xa0;
+	if (!of_property_read_u32(node, "ti,recal-en-bit", &val))
+		dd->recal_en_bit = val;
+
+	if (!of_property_read_u32(node, "ti,recal-st-bit", &val))
+		dd->recal_st_bit = val;
+
+	if (!of_property_read_u32(node, "ti,auto-recal-bit", &val))
+		dd->auto_recal_bit = val;
+
+	of_property_read_u32(node, "ti,modes", &modes);
+
+	dd->modes = modes;
+
+	dd->freqsel_mask = freqsel;
 
 	if (of_property_read_bool(node, "ti,dpll-j-type")) {
 		dd->sddiv_mask = 0xff000000;
-		mult_mask = 0xfff << 8;
-		div1_mask = 0xff;
+		mult_mask = 0xfff << (8 + mul_div_shift);
 		max_multiplier = 4095;
-		max_divider = 256;
+		if (subtype == SUBTYPE_OMAP3_DPLL) {
+			dd->dco_mask = 0xe00000;
+		} else {
+			div1_mask = 0xff << mul_div_shift;
+			max_divider = 256;
+		}
 	}
 
 	if (of_property_read_bool(node, "ti,dpll-regm4xen")) {
@@ -281,7 +332,30 @@ static void __init of_omap_dpll_x2_setup(struct device_node *node)
 
 __init void of_omap3_dpll_setup(struct device_node *node)
 {
-	/* XXX: to be done */
+	const struct clk_ops *ops;
+	u32 freqsel = 0xf0;
+	u32 modes = 0xa0;
+	u8 mul_div_shift = 0;
+
+	ops = &omap3_dpll_ck_ops;
+
+	if (of_property_read_bool(node, "ti,dpll-core")) {
+		ops = &omap3_dpll_core_ck_ops;
+		mul_div_shift = 8;
+		modes = 0x0;
+	}
+
+	if (of_property_read_bool(node, "ti,dpll-peripheral")) {
+		ops = &omap3_dpll_per_ck_ops;
+		freqsel = 0xf00000;
+	}
+
+	if (of_property_read_bool(node, "ti,dpll-j-type"))
+		freqsel = 0x0;
+
+	of_omap_dpll_setup(node, ops, freqsel, modes, mul_div_shift,
+		SUBTYPE_OMAP3_DPLL);
+
 }
 EXPORT_SYMBOL_GPL(of_omap3_dpll_setup);
 CLK_OF_DECLARE(omap3_dpll_clock, "ti,omap3-dpll-clock", of_omap3_dpll_setup);
@@ -306,7 +380,7 @@ __init void of_omap4_dpll_setup(struct device_node *node)
 	if (of_property_read_bool(node, "ti,dpll-no-gate"))
 		ops = &dpll_no_gate_ck_ops;
 
-	of_omap_dpll_setup(node, ops);
+	of_omap_dpll_setup(node, ops, 0, 0xa0, 0, SUBTYPE_OMAP4_DPLL);
 }
 EXPORT_SYMBOL_GPL(of_omap4_dpll_setup);
 CLK_OF_DECLARE(omap4_dpll_clock, "ti,omap4-dpll-clock", of_omap4_dpll_setup);
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:17 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:17 +0300
Subject: [PATCHv4 22/33] CLK: OMAP: update gate clock setup for OMAP3
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-23-git-send-email-t-kristo@ti.com>

OMAP3 gate clocks are handled through the clk driver now. Basic gate
clock can't be used as the OMAP3 gate clocks have some special features,
namely the idle status linkage which is on separate register.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 drivers/clk/omap/gate.c |   27 +++++++++++++++++++++++++--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
index 7186bb2..b560ff4 100644
--- a/drivers/clk/omap/gate.c
+++ b/drivers/clk/omap/gate.c
@@ -28,12 +28,19 @@
 
 #ifdef CONFIG_OF
 
-static const struct clk_ops omap_gate_clk_ops = {
+static const struct clk_ops omap_gate_clkdm_clk_ops = {
 	.init		= &omap2_init_clk_clkdm,
 	.enable		= &omap2_clkops_enable_clkdm,
 	.disable	= &omap2_clkops_disable_clkdm,
 };
 
+static const struct clk_ops omap_gate_clk_ops = {
+	.init		= &omap2_init_clk_clkdm,
+	.enable		= &omap2_dflt_clk_enable,
+	.disable	= &omap2_dflt_clk_disable,
+	.is_enabled	= &omap2_dflt_clk_is_enabled,
+};
+
 void __init of_omap_gate_clk_setup(struct device_node *node)
 {
 	struct clk *clk;
@@ -43,6 +50,7 @@ void __init of_omap_gate_clk_setup(struct device_node *node)
 	int num_parents;
 	const char **parent_names;
 	int i;
+	u32 val;
 
 	clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
 	if (!clk_hw) {
@@ -56,7 +64,22 @@ void __init of_omap_gate_clk_setup(struct device_node *node)
 	of_property_read_string(node, "ti,clkdm-name", &clk_hw->clkdm_name);
 
 	init.name = clk_name;
-	init.ops = &omap_gate_clk_ops;
+	init.flags = 0;
+
+	if (of_property_read_u32_index(node, "reg", 0, &val)) {
+		/* No register, clkdm control only */
+		init.ops = &omap_gate_clkdm_clk_ops;
+	} else {
+		init.ops = &omap_gate_clk_ops;
+		clk_hw->enable_reg = of_iomap(node, 0);
+		of_property_read_u32(node, "ti,enable-bit", &val);
+		clk_hw->enable_bit = val;
+
+		if (of_property_read_bool(node, "ti,dss-clk"))
+			clk_hw->ops = &clkhwops_omap3430es2_dss_usbhost_wait;
+		else
+			clk_hw->ops = &clkhwops_wait;
+	}
 
 	num_parents = of_clk_get_parent_count(node);
 	if (num_parents < 1) {
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:05 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:05 +0300
Subject: [PATCHv4 10/33] ARM: OMAP4: remove old clock data and link in new
 clock init code
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-11-git-send-email-t-kristo@ti.com>

OMAP4 clocks have now been moved to DT, thus remove the old data file
and use the new init code under drivers/clk/omap/clk-44xx.c.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 arch/arm/mach-omap2/Makefile          |    2 +-
 arch/arm/mach-omap2/cclock44xx_data.c | 1730 ---------------------------------
 drivers/clk/omap/Makefile             |    3 +-
 3 files changed, 3 insertions(+), 1732 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/cclock44xx_data.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d4f6715..9f8d3ed 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -175,7 +175,7 @@ obj-$(CONFIG_ARCH_OMAP3)		+= clock34xx.o clkt34xx_dpll3m2.o
 obj-$(CONFIG_ARCH_OMAP3)		+= clock3517.o clock36xx.o
 obj-$(CONFIG_ARCH_OMAP3)		+= dpll3xxx.o cclock3xxx_data.o
 obj-$(CONFIG_ARCH_OMAP3)		+= clkt_iclk.o
-obj-$(CONFIG_ARCH_OMAP4)		+= $(clock-common) cclock44xx_data.o
+obj-$(CONFIG_ARCH_OMAP4)		+= $(clock-common)
 obj-$(CONFIG_ARCH_OMAP4)		+= dpll3xxx.o dpll44xx.o
 obj-$(CONFIG_SOC_AM33XX)		+= $(clock-common) dpll3xxx.o
 obj-$(CONFIG_SOC_AM33XX)		+= cclock33xx_data.o
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
deleted file mode 100644
index 88e37a4..0000000
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ /dev/null
@@ -1,1730 +0,0 @@
-/*
- * OMAP4 Clock data
- *
- * Copyright (C) 2009-2012 Texas Instruments, Inc.
- * Copyright (C) 2009-2010 Nokia Corporation
- *
- * Paul Walmsley (paul at pwsan.com)
- * Rajendra Nayak (rnayak at ti.com)
- * Benoit Cousson (b-cousson at ti.com)
- * Mike Turquette (mturquette at ti.com)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * XXX Some of the ES1 clocks have been removed/changed; once support
- * is added for discriminating clocks by ES level, these should be added back
- * in.
- *
- * XXX All of the remaining MODULEMODE clock nodes should be removed
- * once the drivers are updated to use pm_runtime or to use the appropriate
- * upstream clock node for rate/parent selection.
- */
-
-#include <linux/kernel.h>
-#include <linux/list.h>
-#include <linux/clk-private.h>
-#include <linux/clkdev.h>
-#include <linux/io.h>
-
-#include "soc.h"
-#include "iomap.h"
-#include "clock.h"
-#include "clock44xx.h"
-#include "cm1_44xx.h"
-#include "cm2_44xx.h"
-#include "cm-regbits-44xx.h"
-#include "prm44xx.h"
-#include "prm-regbits-44xx.h"
-#include "control.h"
-#include "scrm44xx.h"
-
-/* OMAP4 modulemode control */
-#define OMAP4430_MODULEMODE_HWCTRL_SHIFT		0
-#define OMAP4430_MODULEMODE_SWCTRL_SHIFT		1
-
-/*
- * OMAP4 ABE DPLL default frequency. In OMAP4460 TRM version V, section
- * "3.6.3.2.3 CM1_ABE Clock Generator" states that the "DPLL_ABE_X2_CLK
- * must be set to 196.608 MHz" and hence, the DPLL locked frequency is
- * half of this value.
- */
-#define OMAP4_DPLL_ABE_DEFFREQ				98304000
-
-/*
- * OMAP4 USB DPLL default frequency. In OMAP4430 TRM version V, section
- * "3.6.3.9.5 DPLL_USB Preferred Settings" shows that the preferred
- * locked frequency for the USB DPLL is 960MHz.
- */
-#define OMAP4_DPLL_USB_DEFFREQ				960000000
-
-/* Root clocks */
-
-DEFINE_CLK_FIXED_RATE(extalt_clkin_ck, CLK_IS_ROOT, 59000000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(pad_clks_src_ck, CLK_IS_ROOT, 12000000, 0x0);
-
-DEFINE_CLK_GATE(pad_clks_ck, "pad_clks_src_ck", &pad_clks_src_ck, 0x0,
-		OMAP4430_CM_CLKSEL_ABE, OMAP4430_PAD_CLKS_GATE_SHIFT,
-		0x0, NULL);
-
-DEFINE_CLK_FIXED_RATE(pad_slimbus_core_clks_ck, CLK_IS_ROOT, 12000000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(secure_32k_clk_src_ck, CLK_IS_ROOT, 32768, 0x0);
-
-DEFINE_CLK_FIXED_RATE(slimbus_src_clk, CLK_IS_ROOT, 12000000, 0x0);
-
-DEFINE_CLK_GATE(slimbus_clk, "slimbus_src_clk", &slimbus_src_clk, 0x0,
-		OMAP4430_CM_CLKSEL_ABE, OMAP4430_SLIMBUS_CLK_GATE_SHIFT,
-		0x0, NULL);
-
-DEFINE_CLK_FIXED_RATE(sys_32k_ck, CLK_IS_ROOT, 32768, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_12000000_ck, CLK_IS_ROOT, 12000000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_13000000_ck, CLK_IS_ROOT, 13000000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_16800000_ck, CLK_IS_ROOT, 16800000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_19200000_ck, CLK_IS_ROOT, 19200000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_26000000_ck, CLK_IS_ROOT, 26000000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_27000000_ck, CLK_IS_ROOT, 27000000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_38400000_ck, CLK_IS_ROOT, 38400000, 0x0);
-
-static const char *sys_clkin_ck_parents[] = {
-	"virt_12000000_ck", "virt_13000000_ck", "virt_16800000_ck",
-	"virt_19200000_ck", "virt_26000000_ck", "virt_27000000_ck",
-	"virt_38400000_ck",
-};
-
-DEFINE_CLK_MUX(sys_clkin_ck, sys_clkin_ck_parents, NULL, 0x0,
-	       OMAP4430_CM_SYS_CLKSEL, OMAP4430_SYS_CLKSEL_SHIFT,
-	       OMAP4430_SYS_CLKSEL_WIDTH, CLK_MUX_INDEX_ONE, NULL);
-
-DEFINE_CLK_FIXED_RATE(tie_low_clock_ck, CLK_IS_ROOT, 0, 0x0);
-
-DEFINE_CLK_FIXED_RATE(utmi_phy_clkout_ck, CLK_IS_ROOT, 60000000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(xclk60mhsp1_ck, CLK_IS_ROOT, 60000000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(xclk60mhsp2_ck, CLK_IS_ROOT, 60000000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(xclk60motg_ck, CLK_IS_ROOT, 60000000, 0x0);
-
-/* Module clocks and DPLL outputs */
-
-static const char *abe_dpll_bypass_clk_mux_ck_parents[] = {
-	"sys_clkin_ck", "sys_32k_ck",
-};
-
-DEFINE_CLK_MUX(abe_dpll_bypass_clk_mux_ck, abe_dpll_bypass_clk_mux_ck_parents,
-	       NULL, 0x0, OMAP4430_CM_L4_WKUP_CLKSEL, OMAP4430_CLKSEL_SHIFT,
-	       OMAP4430_CLKSEL_WIDTH, 0x0, NULL);
-
-DEFINE_CLK_MUX(abe_dpll_refclk_mux_ck, abe_dpll_bypass_clk_mux_ck_parents, NULL,
-	       0x0, OMAP4430_CM_ABE_PLL_REF_CLKSEL, OMAP4430_CLKSEL_0_0_SHIFT,
-	       OMAP4430_CLKSEL_0_0_WIDTH, 0x0, NULL);
-
-/* DPLL_ABE */
-static struct dpll_data dpll_abe_dd = {
-	.mult_div1_reg	= OMAP4430_CM_CLKSEL_DPLL_ABE,
-	.clk_bypass	= &abe_dpll_bypass_clk_mux_ck,
-	.clk_ref	= &abe_dpll_refclk_mux_ck,
-	.control_reg	= OMAP4430_CM_CLKMODE_DPLL_ABE,
-	.modes		= (1 << DPLL_LOW_POWER_BYPASS) | (1 << DPLL_LOCKED),
-	.autoidle_reg	= OMAP4430_CM_AUTOIDLE_DPLL_ABE,
-	.idlest_reg	= OMAP4430_CM_IDLEST_DPLL_ABE,
-	.mult_mask	= OMAP4430_DPLL_MULT_MASK,
-	.div1_mask	= OMAP4430_DPLL_DIV_MASK,
-	.enable_mask	= OMAP4430_DPLL_EN_MASK,
-	.autoidle_mask	= OMAP4430_AUTO_DPLL_MODE_MASK,
-	.idlest_mask	= OMAP4430_ST_DPLL_CLK_MASK,
-	.m4xen_mask	= OMAP4430_DPLL_REGM4XEN_MASK,
-	.lpmode_mask	= OMAP4430_DPLL_LPMODE_EN_MASK,
-	.max_multiplier	= 2047,
-	.max_divider	= 128,
-	.min_divider	= 1,
-};
-
-
-static const char *dpll_abe_ck_parents[] = {
-	"abe_dpll_refclk_mux_ck",
-};
-
-static struct clk dpll_abe_ck;
-
-static const struct clk_ops dpll_abe_ck_ops = {
-	.enable		= &omap3_noncore_dpll_enable,
-	.disable	= &omap3_noncore_dpll_disable,
-	.recalc_rate	= &omap4_dpll_regm4xen_recalc,
-	.round_rate	= &omap4_dpll_regm4xen_round_rate,
-	.set_rate	= &omap3_noncore_dpll_set_rate,
-	.get_parent	= &omap2_init_dpll_parent,
-};
-
-static struct clk_hw_omap dpll_abe_ck_hw = {
-	.hw = {
-		.clk = &dpll_abe_ck,
-	},
-	.dpll_data	= &dpll_abe_dd,
-	.ops		= &clkhwops_omap3_dpll,
-};
-
-DEFINE_STRUCT_CLK(dpll_abe_ck, dpll_abe_ck_parents, dpll_abe_ck_ops);
-
-static const char *dpll_abe_x2_ck_parents[] = {
-	"dpll_abe_ck",
-};
-
-static struct clk dpll_abe_x2_ck;
-
-static const struct clk_ops dpll_abe_x2_ck_ops = {
-	.recalc_rate	= &omap3_clkoutx2_recalc,
-};
-
-static struct clk_hw_omap dpll_abe_x2_ck_hw = {
-	.hw = {
-		.clk = &dpll_abe_x2_ck,
-	},
-	.flags		= CLOCK_CLKOUTX2,
-	.clksel_reg	= OMAP4430_CM_DIV_M2_DPLL_ABE,
-	.ops		= &clkhwops_omap4_dpllmx,
-};
-
-DEFINE_STRUCT_CLK(dpll_abe_x2_ck, dpll_abe_x2_ck_parents, dpll_abe_x2_ck_ops);
-
-static const struct clk_ops omap_hsdivider_ops = {
-	.set_rate	= &omap2_clksel_set_rate,
-	.recalc_rate	= &omap2_clksel_recalc,
-	.round_rate	= &omap2_clksel_round_rate,
-};
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_abe_m2x2_ck, "dpll_abe_x2_ck", &dpll_abe_x2_ck,
-			  0x0, OMAP4430_CM_DIV_M2_DPLL_ABE,
-			  OMAP4430_DPLL_CLKOUT_DIV_MASK);
-
-DEFINE_CLK_FIXED_FACTOR(abe_24m_fclk, "dpll_abe_m2x2_ck", &dpll_abe_m2x2_ck,
-			0x0, 1, 8);
-
-DEFINE_CLK_DIVIDER(abe_clk, "dpll_abe_m2x2_ck", &dpll_abe_m2x2_ck, 0x0,
-		   OMAP4430_CM_CLKSEL_ABE, OMAP4430_CLKSEL_OPP_SHIFT,
-		   OMAP4430_CLKSEL_OPP_WIDTH, CLK_DIVIDER_POWER_OF_TWO, NULL);
-
-DEFINE_CLK_DIVIDER(aess_fclk, "abe_clk", &abe_clk, 0x0,
-		   OMAP4430_CM1_ABE_AESS_CLKCTRL,
-		   OMAP4430_CLKSEL_AESS_FCLK_SHIFT,
-		   OMAP4430_CLKSEL_AESS_FCLK_WIDTH,
-		   0x0, NULL);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_abe_m3x2_ck, "dpll_abe_x2_ck", &dpll_abe_x2_ck,
-			  0x0, OMAP4430_CM_DIV_M3_DPLL_ABE,
-			  OMAP4430_DPLL_CLKOUTHIF_DIV_MASK);
-
-static const char *core_hsd_byp_clk_mux_ck_parents[] = {
-	"sys_clkin_ck", "dpll_abe_m3x2_ck",
-};
-
-DEFINE_CLK_MUX(core_hsd_byp_clk_mux_ck, core_hsd_byp_clk_mux_ck_parents, NULL,
-	       0x0, OMAP4430_CM_CLKSEL_DPLL_CORE,
-	       OMAP4430_DPLL_BYP_CLKSEL_SHIFT, OMAP4430_DPLL_BYP_CLKSEL_WIDTH,
-	       0x0, NULL);
-
-/* DPLL_CORE */
-static struct dpll_data dpll_core_dd = {
-	.mult_div1_reg	= OMAP4430_CM_CLKSEL_DPLL_CORE,
-	.clk_bypass	= &core_hsd_byp_clk_mux_ck,
-	.clk_ref	= &sys_clkin_ck,
-	.control_reg	= OMAP4430_CM_CLKMODE_DPLL_CORE,
-	.modes		= (1 << DPLL_LOW_POWER_BYPASS) | (1 << DPLL_LOCKED),
-	.autoidle_reg	= OMAP4430_CM_AUTOIDLE_DPLL_CORE,
-	.idlest_reg	= OMAP4430_CM_IDLEST_DPLL_CORE,
-	.mult_mask	= OMAP4430_DPLL_MULT_MASK,
-	.div1_mask	= OMAP4430_DPLL_DIV_MASK,
-	.enable_mask	= OMAP4430_DPLL_EN_MASK,
-	.autoidle_mask	= OMAP4430_AUTO_DPLL_MODE_MASK,
-	.idlest_mask	= OMAP4430_ST_DPLL_CLK_MASK,
-	.max_multiplier	= 2047,
-	.max_divider	= 128,
-	.min_divider	= 1,
-};
-
-
-static const char *dpll_core_ck_parents[] = {
-	"sys_clkin_ck", "core_hsd_byp_clk_mux_ck"
-};
-
-static struct clk dpll_core_ck;
-
-static const struct clk_ops dpll_core_ck_ops = {
-	.recalc_rate	= &omap3_dpll_recalc,
-	.get_parent	= &omap2_init_dpll_parent,
-};
-
-static struct clk_hw_omap dpll_core_ck_hw = {
-	.hw = {
-		.clk = &dpll_core_ck,
-	},
-	.dpll_data	= &dpll_core_dd,
-	.ops		= &clkhwops_omap3_dpll,
-};
-
-DEFINE_STRUCT_CLK(dpll_core_ck, dpll_core_ck_parents, dpll_core_ck_ops);
-
-static const char *dpll_core_x2_ck_parents[] = {
-	"dpll_core_ck",
-};
-
-static struct clk dpll_core_x2_ck;
-
-static struct clk_hw_omap dpll_core_x2_ck_hw = {
-	.hw = {
-		.clk = &dpll_core_x2_ck,
-	},
-};
-
-DEFINE_STRUCT_CLK(dpll_core_x2_ck, dpll_core_x2_ck_parents, dpll_abe_x2_ck_ops);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_core_m6x2_ck, "dpll_core_x2_ck",
-			  &dpll_core_x2_ck, 0x0, OMAP4430_CM_DIV_M6_DPLL_CORE,
-			  OMAP4430_HSDIVIDER_CLKOUT3_DIV_MASK);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_core_m2_ck, "dpll_core_ck", &dpll_core_ck, 0x0,
-			  OMAP4430_CM_DIV_M2_DPLL_CORE,
-			  OMAP4430_DPLL_CLKOUT_DIV_MASK);
-
-DEFINE_CLK_FIXED_FACTOR(ddrphy_ck, "dpll_core_m2_ck", &dpll_core_m2_ck, 0x0, 1,
-			2);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_core_m5x2_ck, "dpll_core_x2_ck",
-			  &dpll_core_x2_ck, 0x0, OMAP4430_CM_DIV_M5_DPLL_CORE,
-			  OMAP4430_HSDIVIDER_CLKOUT2_DIV_MASK);
-
-DEFINE_CLK_DIVIDER(div_core_ck, "dpll_core_m5x2_ck", &dpll_core_m5x2_ck, 0x0,
-		   OMAP4430_CM_CLKSEL_CORE, OMAP4430_CLKSEL_CORE_SHIFT,
-		   OMAP4430_CLKSEL_CORE_WIDTH, 0x0, NULL);
-
-DEFINE_CLK_DIVIDER(div_iva_hs_clk, "dpll_core_m5x2_ck", &dpll_core_m5x2_ck,
-		   0x0, OMAP4430_CM_BYPCLK_DPLL_IVA, OMAP4430_CLKSEL_0_1_SHIFT,
-		   OMAP4430_CLKSEL_0_1_WIDTH, CLK_DIVIDER_POWER_OF_TWO, NULL);
-
-DEFINE_CLK_DIVIDER(div_mpu_hs_clk, "dpll_core_m5x2_ck", &dpll_core_m5x2_ck,
-		   0x0, OMAP4430_CM_BYPCLK_DPLL_MPU, OMAP4430_CLKSEL_0_1_SHIFT,
-		   OMAP4430_CLKSEL_0_1_WIDTH, CLK_DIVIDER_POWER_OF_TWO, NULL);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_core_m4x2_ck, "dpll_core_x2_ck",
-			  &dpll_core_x2_ck, 0x0, OMAP4430_CM_DIV_M4_DPLL_CORE,
-			  OMAP4430_HSDIVIDER_CLKOUT1_DIV_MASK);
-
-DEFINE_CLK_FIXED_FACTOR(dll_clk_div_ck, "dpll_core_m4x2_ck", &dpll_core_m4x2_ck,
-			0x0, 1, 2);
-
-DEFINE_CLK_DIVIDER(dpll_abe_m2_ck, "dpll_abe_ck", &dpll_abe_ck, 0x0,
-		   OMAP4430_CM_DIV_M2_DPLL_ABE, OMAP4430_DPLL_CLKOUT_DIV_SHIFT,
-		   OMAP4430_DPLL_CLKOUT_DIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);
-
-static const struct clk_ops dpll_hsd_ops = {
-	.enable		= &omap2_dflt_clk_enable,
-	.disable	= &omap2_dflt_clk_disable,
-	.is_enabled	= &omap2_dflt_clk_is_enabled,
-	.recalc_rate	= &omap2_clksel_recalc,
-	.get_parent	= &omap2_clksel_find_parent_index,
-	.set_parent	= &omap2_clksel_set_parent,
-	.init		= &omap2_init_clk_clkdm,
-};
-
-static const struct clk_ops func_dmic_abe_gfclk_ops = {
-	.recalc_rate	= &omap2_clksel_recalc,
-	.get_parent	= &omap2_clksel_find_parent_index,
-	.set_parent	= &omap2_clksel_set_parent,
-};
-
-static const char *dpll_core_m3x2_ck_parents[] = {
-	"dpll_core_x2_ck",
-};
-
-static const struct clksel dpll_core_m3x2_div[] = {
-	{ .parent = &dpll_core_x2_ck, .rates = div31_1to31_rates },
-	{ .parent = NULL },
-};
-
-/* XXX Missing round_rate, set_rate in ops */
-DEFINE_CLK_OMAP_MUX_GATE(dpll_core_m3x2_ck, NULL, dpll_core_m3x2_div,
-			 OMAP4430_CM_DIV_M3_DPLL_CORE,
-			 OMAP4430_DPLL_CLKOUTHIF_DIV_MASK,
-			 OMAP4430_CM_DIV_M3_DPLL_CORE,
-			 OMAP4430_DPLL_CLKOUTHIF_GATE_CTRL_SHIFT, NULL,
-			 dpll_core_m3x2_ck_parents, dpll_hsd_ops);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_core_m7x2_ck, "dpll_core_x2_ck",
-			  &dpll_core_x2_ck, 0x0, OMAP4430_CM_DIV_M7_DPLL_CORE,
-			  OMAP4430_HSDIVIDER_CLKOUT4_DIV_MASK);
-
-static const char *iva_hsd_byp_clk_mux_ck_parents[] = {
-	"sys_clkin_ck", "div_iva_hs_clk",
-};
-
-DEFINE_CLK_MUX(iva_hsd_byp_clk_mux_ck, iva_hsd_byp_clk_mux_ck_parents, NULL,
-	       0x0, OMAP4430_CM_CLKSEL_DPLL_IVA, OMAP4430_DPLL_BYP_CLKSEL_SHIFT,
-	       OMAP4430_DPLL_BYP_CLKSEL_WIDTH, 0x0, NULL);
-
-/* DPLL_IVA */
-static struct dpll_data dpll_iva_dd = {
-	.mult_div1_reg	= OMAP4430_CM_CLKSEL_DPLL_IVA,
-	.clk_bypass	= &iva_hsd_byp_clk_mux_ck,
-	.clk_ref	= &sys_clkin_ck,
-	.control_reg	= OMAP4430_CM_CLKMODE_DPLL_IVA,
-	.modes		= (1 << DPLL_LOW_POWER_BYPASS) | (1 << DPLL_LOCKED),
-	.autoidle_reg	= OMAP4430_CM_AUTOIDLE_DPLL_IVA,
-	.idlest_reg	= OMAP4430_CM_IDLEST_DPLL_IVA,
-	.mult_mask	= OMAP4430_DPLL_MULT_MASK,
-	.div1_mask	= OMAP4430_DPLL_DIV_MASK,
-	.enable_mask	= OMAP4430_DPLL_EN_MASK,
-	.autoidle_mask	= OMAP4430_AUTO_DPLL_MODE_MASK,
-	.idlest_mask	= OMAP4430_ST_DPLL_CLK_MASK,
-	.max_multiplier	= 2047,
-	.max_divider	= 128,
-	.min_divider	= 1,
-};
-
-static const char *dpll_iva_ck_parents[] = {
-	"sys_clkin_ck", "iva_hsd_byp_clk_mux_ck"
-};
-
-static struct clk dpll_iva_ck;
-
-static const struct clk_ops dpll_ck_ops = {
-	.enable		= &omap3_noncore_dpll_enable,
-	.disable	= &omap3_noncore_dpll_disable,
-	.recalc_rate	= &omap3_dpll_recalc,
-	.round_rate	= &omap2_dpll_round_rate,
-	.set_rate	= &omap3_noncore_dpll_set_rate,
-	.get_parent	= &omap2_init_dpll_parent,
-};
-
-static struct clk_hw_omap dpll_iva_ck_hw = {
-	.hw = {
-		.clk = &dpll_iva_ck,
-	},
-	.dpll_data	= &dpll_iva_dd,
-	.ops		= &clkhwops_omap3_dpll,
-};
-
-DEFINE_STRUCT_CLK(dpll_iva_ck, dpll_iva_ck_parents, dpll_ck_ops);
-
-static const char *dpll_iva_x2_ck_parents[] = {
-	"dpll_iva_ck",
-};
-
-static struct clk dpll_iva_x2_ck;
-
-static struct clk_hw_omap dpll_iva_x2_ck_hw = {
-	.hw = {
-		.clk = &dpll_iva_x2_ck,
-	},
-};
-
-DEFINE_STRUCT_CLK(dpll_iva_x2_ck, dpll_iva_x2_ck_parents, dpll_abe_x2_ck_ops);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_iva_m4x2_ck, "dpll_iva_x2_ck", &dpll_iva_x2_ck,
-			  0x0, OMAP4430_CM_DIV_M4_DPLL_IVA,
-			  OMAP4430_HSDIVIDER_CLKOUT1_DIV_MASK);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_iva_m5x2_ck, "dpll_iva_x2_ck", &dpll_iva_x2_ck,
-			  0x0, OMAP4430_CM_DIV_M5_DPLL_IVA,
-			  OMAP4430_HSDIVIDER_CLKOUT2_DIV_MASK);
-
-/* DPLL_MPU */
-static struct dpll_data dpll_mpu_dd = {
-	.mult_div1_reg	= OMAP4430_CM_CLKSEL_DPLL_MPU,
-	.clk_bypass	= &div_mpu_hs_clk,
-	.clk_ref	= &sys_clkin_ck,
-	.control_reg	= OMAP4430_CM_CLKMODE_DPLL_MPU,
-	.modes		= (1 << DPLL_LOW_POWER_BYPASS) | (1 << DPLL_LOCKED),
-	.autoidle_reg	= OMAP4430_CM_AUTOIDLE_DPLL_MPU,
-	.idlest_reg	= OMAP4430_CM_IDLEST_DPLL_MPU,
-	.mult_mask	= OMAP4430_DPLL_MULT_MASK,
-	.div1_mask	= OMAP4430_DPLL_DIV_MASK,
-	.enable_mask	= OMAP4430_DPLL_EN_MASK,
-	.autoidle_mask	= OMAP4430_AUTO_DPLL_MODE_MASK,
-	.idlest_mask	= OMAP4430_ST_DPLL_CLK_MASK,
-	.max_multiplier	= 2047,
-	.max_divider	= 128,
-	.min_divider	= 1,
-};
-
-static const char *dpll_mpu_ck_parents[] = {
-	"sys_clkin_ck", "div_mpu_hs_clk"
-};
-
-static struct clk dpll_mpu_ck;
-
-static struct clk_hw_omap dpll_mpu_ck_hw = {
-	.hw = {
-		.clk = &dpll_mpu_ck,
-	},
-	.dpll_data	= &dpll_mpu_dd,
-	.ops		= &clkhwops_omap3_dpll,
-};
-
-DEFINE_STRUCT_CLK(dpll_mpu_ck, dpll_mpu_ck_parents, dpll_ck_ops);
-
-DEFINE_CLK_FIXED_FACTOR(mpu_periphclk, "dpll_mpu_ck", &dpll_mpu_ck, 0x0, 1, 2);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_mpu_m2_ck, "dpll_mpu_ck", &dpll_mpu_ck, 0x0,
-			  OMAP4430_CM_DIV_M2_DPLL_MPU,
-			  OMAP4430_DPLL_CLKOUT_DIV_MASK);
-
-DEFINE_CLK_FIXED_FACTOR(per_hs_clk_div_ck, "dpll_abe_m3x2_ck",
-			&dpll_abe_m3x2_ck, 0x0, 1, 2);
-
-static const char *per_hsd_byp_clk_mux_ck_parents[] = {
-	"sys_clkin_ck", "per_hs_clk_div_ck",
-};
-
-DEFINE_CLK_MUX(per_hsd_byp_clk_mux_ck, per_hsd_byp_clk_mux_ck_parents, NULL,
-	       0x0, OMAP4430_CM_CLKSEL_DPLL_PER, OMAP4430_DPLL_BYP_CLKSEL_SHIFT,
-	       OMAP4430_DPLL_BYP_CLKSEL_WIDTH, 0x0, NULL);
-
-/* DPLL_PER */
-static struct dpll_data dpll_per_dd = {
-	.mult_div1_reg	= OMAP4430_CM_CLKSEL_DPLL_PER,
-	.clk_bypass	= &per_hsd_byp_clk_mux_ck,
-	.clk_ref	= &sys_clkin_ck,
-	.control_reg	= OMAP4430_CM_CLKMODE_DPLL_PER,
-	.modes		= (1 << DPLL_LOW_POWER_BYPASS) | (1 << DPLL_LOCKED),
-	.autoidle_reg	= OMAP4430_CM_AUTOIDLE_DPLL_PER,
-	.idlest_reg	= OMAP4430_CM_IDLEST_DPLL_PER,
-	.mult_mask	= OMAP4430_DPLL_MULT_MASK,
-	.div1_mask	= OMAP4430_DPLL_DIV_MASK,
-	.enable_mask	= OMAP4430_DPLL_EN_MASK,
-	.autoidle_mask	= OMAP4430_AUTO_DPLL_MODE_MASK,
-	.idlest_mask	= OMAP4430_ST_DPLL_CLK_MASK,
-	.max_multiplier	= 2047,
-	.max_divider	= 128,
-	.min_divider	= 1,
-};
-
-static const char *dpll_per_ck_parents[] = {
-	"sys_clkin_ck", "per_hsd_byp_clk_mux_ck"
-};
-
-static struct clk dpll_per_ck;
-
-static struct clk_hw_omap dpll_per_ck_hw = {
-	.hw = {
-		.clk = &dpll_per_ck,
-	},
-	.dpll_data	= &dpll_per_dd,
-	.ops		= &clkhwops_omap3_dpll,
-};
-
-DEFINE_STRUCT_CLK(dpll_per_ck, dpll_per_ck_parents, dpll_ck_ops);
-
-DEFINE_CLK_DIVIDER(dpll_per_m2_ck, "dpll_per_ck", &dpll_per_ck, 0x0,
-		   OMAP4430_CM_DIV_M2_DPLL_PER, OMAP4430_DPLL_CLKOUT_DIV_SHIFT,
-		   OMAP4430_DPLL_CLKOUT_DIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);
-
-static const char *dpll_per_x2_ck_parents[] = {
-	"dpll_per_ck",
-};
-
-static struct clk dpll_per_x2_ck;
-
-static struct clk_hw_omap dpll_per_x2_ck_hw = {
-	.hw = {
-		.clk = &dpll_per_x2_ck,
-	},
-	.flags		= CLOCK_CLKOUTX2,
-	.clksel_reg	= OMAP4430_CM_DIV_M2_DPLL_PER,
-	.ops		= &clkhwops_omap4_dpllmx,
-};
-
-DEFINE_STRUCT_CLK(dpll_per_x2_ck, dpll_per_x2_ck_parents, dpll_abe_x2_ck_ops);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_per_m2x2_ck, "dpll_per_x2_ck", &dpll_per_x2_ck,
-			  0x0, OMAP4430_CM_DIV_M2_DPLL_PER,
-			  OMAP4430_DPLL_CLKOUT_DIV_MASK);
-
-static const char *dpll_per_m3x2_ck_parents[] = {
-	"dpll_per_x2_ck",
-};
-
-static const struct clksel dpll_per_m3x2_div[] = {
-	{ .parent = &dpll_per_x2_ck, .rates = div31_1to31_rates },
-	{ .parent = NULL },
-};
-
-/* XXX Missing round_rate, set_rate in ops */
-DEFINE_CLK_OMAP_MUX_GATE(dpll_per_m3x2_ck, NULL, dpll_per_m3x2_div,
-			 OMAP4430_CM_DIV_M3_DPLL_PER,
-			 OMAP4430_DPLL_CLKOUTHIF_DIV_MASK,
-			 OMAP4430_CM_DIV_M3_DPLL_PER,
-			 OMAP4430_DPLL_CLKOUTHIF_GATE_CTRL_SHIFT, NULL,
-			 dpll_per_m3x2_ck_parents, dpll_hsd_ops);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_per_m4x2_ck, "dpll_per_x2_ck", &dpll_per_x2_ck,
-			  0x0, OMAP4430_CM_DIV_M4_DPLL_PER,
-			  OMAP4430_HSDIVIDER_CLKOUT1_DIV_MASK);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_per_m5x2_ck, "dpll_per_x2_ck", &dpll_per_x2_ck,
-			  0x0, OMAP4430_CM_DIV_M5_DPLL_PER,
-			  OMAP4430_HSDIVIDER_CLKOUT2_DIV_MASK);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_per_m6x2_ck, "dpll_per_x2_ck", &dpll_per_x2_ck,
-			  0x0, OMAP4430_CM_DIV_M6_DPLL_PER,
-			  OMAP4430_HSDIVIDER_CLKOUT3_DIV_MASK);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_per_m7x2_ck, "dpll_per_x2_ck", &dpll_per_x2_ck,
-			  0x0, OMAP4430_CM_DIV_M7_DPLL_PER,
-			  OMAP4430_HSDIVIDER_CLKOUT4_DIV_MASK);
-
-DEFINE_CLK_FIXED_FACTOR(usb_hs_clk_div_ck, "dpll_abe_m3x2_ck",
-			&dpll_abe_m3x2_ck, 0x0, 1, 3);
-
-/* DPLL_USB */
-static struct dpll_data dpll_usb_dd = {
-	.mult_div1_reg	= OMAP4430_CM_CLKSEL_DPLL_USB,
-	.clk_bypass	= &usb_hs_clk_div_ck,
-	.flags		= DPLL_J_TYPE,
-	.clk_ref	= &sys_clkin_ck,
-	.control_reg	= OMAP4430_CM_CLKMODE_DPLL_USB,
-	.modes		= (1 << DPLL_LOW_POWER_BYPASS) | (1 << DPLL_LOCKED),
-	.autoidle_reg	= OMAP4430_CM_AUTOIDLE_DPLL_USB,
-	.idlest_reg	= OMAP4430_CM_IDLEST_DPLL_USB,
-	.mult_mask	= OMAP4430_DPLL_MULT_USB_MASK,
-	.div1_mask	= OMAP4430_DPLL_DIV_0_7_MASK,
-	.enable_mask	= OMAP4430_DPLL_EN_MASK,
-	.autoidle_mask	= OMAP4430_AUTO_DPLL_MODE_MASK,
-	.idlest_mask	= OMAP4430_ST_DPLL_CLK_MASK,
-	.sddiv_mask	= OMAP4430_DPLL_SD_DIV_MASK,
-	.max_multiplier	= 4095,
-	.max_divider	= 256,
-	.min_divider	= 1,
-};
-
-static const char *dpll_usb_ck_parents[] = {
-	"sys_clkin_ck", "usb_hs_clk_div_ck"
-};
-
-static struct clk dpll_usb_ck;
-
-static const struct clk_ops dpll_usb_ck_ops = {
-	.enable		= &omap3_noncore_dpll_enable,
-	.disable	= &omap3_noncore_dpll_disable,
-	.recalc_rate	= &omap3_dpll_recalc,
-	.round_rate	= &omap2_dpll_round_rate,
-	.set_rate	= &omap3_noncore_dpll_set_rate,
-	.get_parent	= &omap2_init_dpll_parent,
-	.init		= &omap2_init_clk_clkdm,
-};
-
-static struct clk_hw_omap dpll_usb_ck_hw = {
-	.hw = {
-		.clk = &dpll_usb_ck,
-	},
-	.dpll_data	= &dpll_usb_dd,
-	.clkdm_name	= "l3_init_clkdm",
-	.ops		= &clkhwops_omap3_dpll,
-};
-
-DEFINE_STRUCT_CLK(dpll_usb_ck, dpll_usb_ck_parents, dpll_usb_ck_ops);
-
-static const char *dpll_usb_clkdcoldo_ck_parents[] = {
-	"dpll_usb_ck",
-};
-
-static struct clk dpll_usb_clkdcoldo_ck;
-
-static const struct clk_ops dpll_usb_clkdcoldo_ck_ops = {
-};
-
-static struct clk_hw_omap dpll_usb_clkdcoldo_ck_hw = {
-	.hw = {
-		.clk = &dpll_usb_clkdcoldo_ck,
-	},
-	.clksel_reg	= OMAP4430_CM_CLKDCOLDO_DPLL_USB,
-	.ops		= &clkhwops_omap4_dpllmx,
-};
-
-DEFINE_STRUCT_CLK(dpll_usb_clkdcoldo_ck, dpll_usb_clkdcoldo_ck_parents,
-		  dpll_usb_clkdcoldo_ck_ops);
-
-DEFINE_CLK_OMAP_HSDIVIDER(dpll_usb_m2_ck, "dpll_usb_ck", &dpll_usb_ck, 0x0,
-			  OMAP4430_CM_DIV_M2_DPLL_USB,
-			  OMAP4430_DPLL_CLKOUT_DIV_0_6_MASK);
-
-static const char *ducati_clk_mux_ck_parents[] = {
-	"div_core_ck", "dpll_per_m6x2_ck",
-};
-
-DEFINE_CLK_MUX(ducati_clk_mux_ck, ducati_clk_mux_ck_parents, NULL, 0x0,
-	       OMAP4430_CM_CLKSEL_DUCATI_ISS_ROOT, OMAP4430_CLKSEL_0_0_SHIFT,
-	       OMAP4430_CLKSEL_0_0_WIDTH, 0x0, NULL);
-
-DEFINE_CLK_FIXED_FACTOR(func_12m_fclk, "dpll_per_m2x2_ck", &dpll_per_m2x2_ck,
-			0x0, 1, 16);
-
-DEFINE_CLK_FIXED_FACTOR(func_24m_clk, "dpll_per_m2_ck", &dpll_per_m2_ck, 0x0,
-			1, 4);
-
-DEFINE_CLK_FIXED_FACTOR(func_24mc_fclk, "dpll_per_m2x2_ck", &dpll_per_m2x2_ck,
-			0x0, 1, 8);
-
-static const struct clk_div_table func_48m_fclk_rates[] = {
-	{ .div = 4, .val = 0 },
-	{ .div = 8, .val = 1 },
-	{ .div = 0 },
-};
-DEFINE_CLK_DIVIDER_TABLE(func_48m_fclk, "dpll_per_m2x2_ck", &dpll_per_m2x2_ck,
-			 0x0, OMAP4430_CM_SCALE_FCLK, OMAP4430_SCALE_FCLK_SHIFT,
-			 OMAP4430_SCALE_FCLK_WIDTH, 0x0, func_48m_fclk_rates,
-			 NULL);
-
-DEFINE_CLK_FIXED_FACTOR(func_48mc_fclk,	"dpll_per_m2x2_ck", &dpll_per_m2x2_ck,
-			0x0, 1, 4);
-
-static const struct clk_div_table func_64m_fclk_rates[] = {
-	{ .div = 2, .val = 0 },
-	{ .div = 4, .val = 1 },
-	{ .div = 0 },
-};
-DEFINE_CLK_DIVIDER_TABLE(func_64m_fclk, "dpll_per_m4x2_ck", &dpll_per_m4x2_ck,
-			 0x0, OMAP4430_CM_SCALE_FCLK, OMAP4430_SCALE_FCLK_SHIFT,
-			 OMAP4430_SCALE_FCLK_WIDTH, 0x0, func_64m_fclk_rates,
-			 NULL);
-
-static const struct clk_div_table func_96m_fclk_rates[] = {
-	{ .div = 2, .val = 0 },
-	{ .div = 4, .val = 1 },
-	{ .div = 0 },
-};
-DEFINE_CLK_DIVIDER_TABLE(func_96m_fclk, "dpll_per_m2x2_ck", &dpll_per_m2x2_ck,
-			 0x0, OMAP4430_CM_SCALE_FCLK, OMAP4430_SCALE_FCLK_SHIFT,
-			 OMAP4430_SCALE_FCLK_WIDTH, 0x0, func_96m_fclk_rates,
-			 NULL);
-
-static const struct clk_div_table init_60m_fclk_rates[] = {
-	{ .div = 1, .val = 0 },
-	{ .div = 8, .val = 1 },
-	{ .div = 0 },
-};
-DEFINE_CLK_DIVIDER_TABLE(init_60m_fclk, "dpll_usb_m2_ck", &dpll_usb_m2_ck,
-			 0x0, OMAP4430_CM_CLKSEL_USB_60MHZ,
-			 OMAP4430_CLKSEL_0_0_SHIFT, OMAP4430_CLKSEL_0_0_WIDTH,
-			 0x0, init_60m_fclk_rates, NULL);
-
-DEFINE_CLK_DIVIDER(l3_div_ck, "div_core_ck", &div_core_ck, 0x0,
-		   OMAP4430_CM_CLKSEL_CORE, OMAP4430_CLKSEL_L3_SHIFT,
-		   OMAP4430_CLKSEL_L3_WIDTH, 0x0, NULL);
-
-DEFINE_CLK_DIVIDER(l4_div_ck, "l3_div_ck", &l3_div_ck, 0x0,
-		   OMAP4430_CM_CLKSEL_CORE, OMAP4430_CLKSEL_L4_SHIFT,
-		   OMAP4430_CLKSEL_L4_WIDTH, 0x0, NULL);
-
-DEFINE_CLK_FIXED_FACTOR(lp_clk_div_ck, "dpll_abe_m2x2_ck", &dpll_abe_m2x2_ck,
-			0x0, 1, 16);
-
-static const char *l4_wkup_clk_mux_ck_parents[] = {
-	"sys_clkin_ck", "lp_clk_div_ck",
-};
-
-DEFINE_CLK_MUX(l4_wkup_clk_mux_ck, l4_wkup_clk_mux_ck_parents, NULL, 0x0,
-	       OMAP4430_CM_L4_WKUP_CLKSEL, OMAP4430_CLKSEL_0_0_SHIFT,
-	       OMAP4430_CLKSEL_0_0_WIDTH, 0x0, NULL);
-
-static const struct clk_div_table ocp_abe_iclk_rates[] = {
-	{ .div = 2, .val = 0 },
-	{ .div = 1, .val = 1 },
-	{ .div = 0 },
-};
-DEFINE_CLK_DIVIDER_TABLE(ocp_abe_iclk, "aess_fclk", &aess_fclk, 0x0,
-			 OMAP4430_CM1_ABE_AESS_CLKCTRL,
-			 OMAP4430_CLKSEL_AESS_FCLK_SHIFT,
-			 OMAP4430_CLKSEL_AESS_FCLK_WIDTH,
-			 0x0, ocp_abe_iclk_rates, NULL);
-
-DEFINE_CLK_FIXED_FACTOR(per_abe_24m_fclk, "dpll_abe_m2_ck", &dpll_abe_m2_ck,
-			0x0, 1, 4);
-
-DEFINE_CLK_DIVIDER(per_abe_nc_fclk, "dpll_abe_m2_ck", &dpll_abe_m2_ck, 0x0,
-		   OMAP4430_CM_SCALE_FCLK, OMAP4430_SCALE_FCLK_SHIFT,
-		   OMAP4430_SCALE_FCLK_WIDTH, 0x0, NULL);
-
-DEFINE_CLK_DIVIDER(syc_clk_div_ck, "sys_clkin_ck", &sys_clkin_ck, 0x0,
-		   OMAP4430_CM_ABE_DSS_SYS_CLKSEL, OMAP4430_CLKSEL_0_0_SHIFT,
-		   OMAP4430_CLKSEL_0_0_WIDTH, 0x0, NULL);
-
-static const char *dbgclk_mux_ck_parents[] = {
-	"sys_clkin_ck"
-};
-
-static struct clk dbgclk_mux_ck;
-DEFINE_STRUCT_CLK_HW_OMAP(dbgclk_mux_ck, NULL);
-DEFINE_STRUCT_CLK(dbgclk_mux_ck, dbgclk_mux_ck_parents,
-		  dpll_usb_clkdcoldo_ck_ops);
-
-/* Leaf clocks controlled by modules */
-
-DEFINE_CLK_GATE(aes1_fck, "l3_div_ck", &l3_div_ck, 0x0,
-		OMAP4430_CM_L4SEC_AES1_CLKCTRL,
-		OMAP4430_MODULEMODE_SWCTRL_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(aes2_fck, "l3_div_ck", &l3_div_ck, 0x0,
-		OMAP4430_CM_L4SEC_AES2_CLKCTRL,
-		OMAP4430_MODULEMODE_SWCTRL_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(bandgap_fclk, "sys_32k_ck", &sys_32k_ck, 0x0,
-		OMAP4430_CM_WKUP_BANDGAP_CLKCTRL,
-		OMAP4430_OPTFCLKEN_BGAP_32K_SHIFT, 0x0, NULL);
-
-static const struct clk_div_table div_ts_ck_rates[] = {
-	{ .div = 8, .val = 0 },
-	{ .div = 16, .val = 1 },
-	{ .div = 32, .val = 2 },
-	{ .div = 0 },
-};
-DEFINE_CLK_DIVIDER_TABLE(div_ts_ck, "l4_wkup_clk_mux_ck", &l4_wkup_clk_mux_ck,
-			 0x0, OMAP4430_CM_WKUP_BANDGAP_CLKCTRL,
-			 OMAP4430_CLKSEL_24_25_SHIFT,
-			 OMAP4430_CLKSEL_24_25_WIDTH, 0x0, div_ts_ck_rates,
-			 NULL);
-
-DEFINE_CLK_GATE(bandgap_ts_fclk, "div_ts_ck", &div_ts_ck, 0x0,
-		OMAP4430_CM_WKUP_BANDGAP_CLKCTRL,
-		OMAP4460_OPTFCLKEN_TS_FCLK_SHIFT,
-		0x0, NULL);
-
-static const char *dmic_sync_mux_ck_parents[] = {
-	"abe_24m_fclk", "syc_clk_div_ck", "func_24m_clk",
-};
-
-DEFINE_CLK_MUX(dmic_sync_mux_ck, dmic_sync_mux_ck_parents, NULL,
-	       0x0, OMAP4430_CM1_ABE_DMIC_CLKCTRL,
-	       OMAP4430_CLKSEL_INTERNAL_SOURCE_SHIFT,
-	       OMAP4430_CLKSEL_INTERNAL_SOURCE_WIDTH, 0x0, NULL);
-
-static const struct clksel func_dmic_abe_gfclk_sel[] = {
-	{ .parent = &dmic_sync_mux_ck, .rates = div_1_0_rates },
-	{ .parent = &pad_clks_ck, .rates = div_1_1_rates },
-	{ .parent = &slimbus_clk, .rates = div_1_2_rates },
-	{ .parent = NULL },
-};
-
-static const char *func_dmic_abe_gfclk_parents[] = {
-	"dmic_sync_mux_ck", "pad_clks_ck", "slimbus_clk",
-};
-
-DEFINE_CLK_OMAP_MUX(func_dmic_abe_gfclk, "abe_clkdm", func_dmic_abe_gfclk_sel,
-		    OMAP4430_CM1_ABE_DMIC_CLKCTRL, OMAP4430_CLKSEL_SOURCE_MASK,
-		    func_dmic_abe_gfclk_parents, func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_GATE(dss_sys_clk, "syc_clk_div_ck", &syc_clk_div_ck, 0x0,
-		OMAP4430_CM_DSS_DSS_CLKCTRL,
-		OMAP4430_OPTFCLKEN_SYS_CLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(dss_tv_clk, "extalt_clkin_ck", &extalt_clkin_ck, 0x0,
-		OMAP4430_CM_DSS_DSS_CLKCTRL,
-		OMAP4430_OPTFCLKEN_TV_CLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(dss_dss_clk, "dpll_per_m5x2_ck", &dpll_per_m5x2_ck, 0x0,
-		OMAP4430_CM_DSS_DSS_CLKCTRL, OMAP4430_OPTFCLKEN_DSSCLK_SHIFT,
-		0x0, NULL);
-
-DEFINE_CLK_GATE(dss_48mhz_clk, "func_48mc_fclk", &func_48mc_fclk, 0x0,
-		OMAP4430_CM_DSS_DSS_CLKCTRL, OMAP4430_OPTFCLKEN_48MHZ_CLK_SHIFT,
-		0x0, NULL);
-
-DEFINE_CLK_GATE(dss_fck, "l3_div_ck", &l3_div_ck, 0x0,
-		OMAP4430_CM_DSS_DSS_CLKCTRL, OMAP4430_MODULEMODE_SWCTRL_SHIFT,
-		0x0, NULL);
-
-DEFINE_CLK_DIVIDER(fdif_fck, "dpll_per_m4x2_ck", &dpll_per_m4x2_ck, 0x0,
-		   OMAP4430_CM_CAM_FDIF_CLKCTRL, OMAP4430_CLKSEL_FCLK_SHIFT,
-		   OMAP4430_CLKSEL_FCLK_WIDTH, CLK_DIVIDER_POWER_OF_TWO, NULL);
-
-DEFINE_CLK_GATE(gpio1_dbclk, "sys_32k_ck", &sys_32k_ck, 0x0,
-		OMAP4430_CM_WKUP_GPIO1_CLKCTRL,
-		OMAP4430_OPTFCLKEN_DBCLK_SHIFT,	0x0, NULL);
-
-DEFINE_CLK_GATE(gpio2_dbclk, "sys_32k_ck", &sys_32k_ck, 0x0,
-		OMAP4430_CM_L4PER_GPIO2_CLKCTRL, OMAP4430_OPTFCLKEN_DBCLK_SHIFT,
-		0x0, NULL);
-
-DEFINE_CLK_GATE(gpio3_dbclk, "sys_32k_ck", &sys_32k_ck, 0x0,
-		OMAP4430_CM_L4PER_GPIO3_CLKCTRL,
-		OMAP4430_OPTFCLKEN_DBCLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(gpio4_dbclk, "sys_32k_ck", &sys_32k_ck, 0x0,
-		OMAP4430_CM_L4PER_GPIO4_CLKCTRL, OMAP4430_OPTFCLKEN_DBCLK_SHIFT,
-		0x0, NULL);
-
-DEFINE_CLK_GATE(gpio5_dbclk, "sys_32k_ck", &sys_32k_ck, 0x0,
-		OMAP4430_CM_L4PER_GPIO5_CLKCTRL, OMAP4430_OPTFCLKEN_DBCLK_SHIFT,
-		0x0, NULL);
-
-DEFINE_CLK_GATE(gpio6_dbclk, "sys_32k_ck", &sys_32k_ck, 0x0,
-		OMAP4430_CM_L4PER_GPIO6_CLKCTRL, OMAP4430_OPTFCLKEN_DBCLK_SHIFT,
-		0x0, NULL);
-
-static const struct clksel sgx_clk_mux_sel[] = {
-	{ .parent = &dpll_core_m7x2_ck, .rates = div_1_0_rates },
-	{ .parent = &dpll_per_m7x2_ck, .rates = div_1_1_rates },
-	{ .parent = NULL },
-};
-
-static const char *sgx_clk_mux_parents[] = {
-	"dpll_core_m7x2_ck", "dpll_per_m7x2_ck",
-};
-
-DEFINE_CLK_OMAP_MUX(sgx_clk_mux, "l3_gfx_clkdm", sgx_clk_mux_sel,
-		    OMAP4430_CM_GFX_GFX_CLKCTRL, OMAP4430_CLKSEL_SGX_FCLK_MASK,
-		    sgx_clk_mux_parents, func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_DIVIDER(hsi_fck, "dpll_per_m2x2_ck", &dpll_per_m2x2_ck, 0x0,
-		   OMAP4430_CM_L3INIT_HSI_CLKCTRL, OMAP4430_CLKSEL_24_25_SHIFT,
-		   OMAP4430_CLKSEL_24_25_WIDTH, CLK_DIVIDER_POWER_OF_TWO,
-		   NULL);
-
-DEFINE_CLK_GATE(iss_ctrlclk, "func_96m_fclk", &func_96m_fclk, 0x0,
-		OMAP4430_CM_CAM_ISS_CLKCTRL, OMAP4430_OPTFCLKEN_CTRLCLK_SHIFT,
-		0x0, NULL);
-
-DEFINE_CLK_MUX(mcasp_sync_mux_ck, dmic_sync_mux_ck_parents, NULL, 0x0,
-	       OMAP4430_CM1_ABE_MCASP_CLKCTRL,
-	       OMAP4430_CLKSEL_INTERNAL_SOURCE_SHIFT,
-	       OMAP4430_CLKSEL_INTERNAL_SOURCE_WIDTH, 0x0, NULL);
-
-static const struct clksel func_mcasp_abe_gfclk_sel[] = {
-	{ .parent = &mcasp_sync_mux_ck, .rates = div_1_0_rates },
-	{ .parent = &pad_clks_ck, .rates = div_1_1_rates },
-	{ .parent = &slimbus_clk, .rates = div_1_2_rates },
-	{ .parent = NULL },
-};
-
-static const char *func_mcasp_abe_gfclk_parents[] = {
-	"mcasp_sync_mux_ck", "pad_clks_ck", "slimbus_clk",
-};
-
-DEFINE_CLK_OMAP_MUX(func_mcasp_abe_gfclk, "abe_clkdm", func_mcasp_abe_gfclk_sel,
-		    OMAP4430_CM1_ABE_MCASP_CLKCTRL, OMAP4430_CLKSEL_SOURCE_MASK,
-		    func_mcasp_abe_gfclk_parents, func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_MUX(mcbsp1_sync_mux_ck, dmic_sync_mux_ck_parents, NULL, 0x0,
-	       OMAP4430_CM1_ABE_MCBSP1_CLKCTRL,
-	       OMAP4430_CLKSEL_INTERNAL_SOURCE_SHIFT,
-	       OMAP4430_CLKSEL_INTERNAL_SOURCE_WIDTH, 0x0, NULL);
-
-static const struct clksel func_mcbsp1_gfclk_sel[] = {
-	{ .parent = &mcbsp1_sync_mux_ck, .rates = div_1_0_rates },
-	{ .parent = &pad_clks_ck, .rates = div_1_1_rates },
-	{ .parent = &slimbus_clk, .rates = div_1_2_rates },
-	{ .parent = NULL },
-};
-
-static const char *func_mcbsp1_gfclk_parents[] = {
-	"mcbsp1_sync_mux_ck", "pad_clks_ck", "slimbus_clk",
-};
-
-DEFINE_CLK_OMAP_MUX(func_mcbsp1_gfclk, "abe_clkdm", func_mcbsp1_gfclk_sel,
-		    OMAP4430_CM1_ABE_MCBSP1_CLKCTRL,
-		    OMAP4430_CLKSEL_SOURCE_MASK, func_mcbsp1_gfclk_parents,
-		    func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_MUX(mcbsp2_sync_mux_ck, dmic_sync_mux_ck_parents, NULL, 0x0,
-	       OMAP4430_CM1_ABE_MCBSP2_CLKCTRL,
-	       OMAP4430_CLKSEL_INTERNAL_SOURCE_SHIFT,
-	       OMAP4430_CLKSEL_INTERNAL_SOURCE_WIDTH, 0x0, NULL);
-
-static const struct clksel func_mcbsp2_gfclk_sel[] = {
-	{ .parent = &mcbsp2_sync_mux_ck, .rates = div_1_0_rates },
-	{ .parent = &pad_clks_ck, .rates = div_1_1_rates },
-	{ .parent = &slimbus_clk, .rates = div_1_2_rates },
-	{ .parent = NULL },
-};
-
-static const char *func_mcbsp2_gfclk_parents[] = {
-	"mcbsp2_sync_mux_ck", "pad_clks_ck", "slimbus_clk",
-};
-
-DEFINE_CLK_OMAP_MUX(func_mcbsp2_gfclk, "abe_clkdm", func_mcbsp2_gfclk_sel,
-		    OMAP4430_CM1_ABE_MCBSP2_CLKCTRL,
-		    OMAP4430_CLKSEL_SOURCE_MASK, func_mcbsp2_gfclk_parents,
-		    func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_MUX(mcbsp3_sync_mux_ck, dmic_sync_mux_ck_parents, NULL, 0x0,
-	       OMAP4430_CM1_ABE_MCBSP3_CLKCTRL,
-	       OMAP4430_CLKSEL_INTERNAL_SOURCE_SHIFT,
-	       OMAP4430_CLKSEL_INTERNAL_SOURCE_WIDTH, 0x0, NULL);
-
-static const struct clksel func_mcbsp3_gfclk_sel[] = {
-	{ .parent = &mcbsp3_sync_mux_ck, .rates = div_1_0_rates },
-	{ .parent = &pad_clks_ck, .rates = div_1_1_rates },
-	{ .parent = &slimbus_clk, .rates = div_1_2_rates },
-	{ .parent = NULL },
-};
-
-static const char *func_mcbsp3_gfclk_parents[] = {
-	"mcbsp3_sync_mux_ck", "pad_clks_ck", "slimbus_clk",
-};
-
-DEFINE_CLK_OMAP_MUX(func_mcbsp3_gfclk, "abe_clkdm", func_mcbsp3_gfclk_sel,
-		    OMAP4430_CM1_ABE_MCBSP3_CLKCTRL,
-		    OMAP4430_CLKSEL_SOURCE_MASK, func_mcbsp3_gfclk_parents,
-		    func_dmic_abe_gfclk_ops);
-
-static const char *mcbsp4_sync_mux_ck_parents[] = {
-	"func_96m_fclk", "per_abe_nc_fclk",
-};
-
-DEFINE_CLK_MUX(mcbsp4_sync_mux_ck, mcbsp4_sync_mux_ck_parents, NULL, 0x0,
-	       OMAP4430_CM_L4PER_MCBSP4_CLKCTRL,
-	       OMAP4430_CLKSEL_INTERNAL_SOURCE_SHIFT,
-	       OMAP4430_CLKSEL_INTERNAL_SOURCE_WIDTH, 0x0, NULL);
-
-static const struct clksel per_mcbsp4_gfclk_sel[] = {
-	{ .parent = &mcbsp4_sync_mux_ck, .rates = div_1_0_rates },
-	{ .parent = &pad_clks_ck, .rates = div_1_1_rates },
-	{ .parent = NULL },
-};
-
-static const char *per_mcbsp4_gfclk_parents[] = {
-	"mcbsp4_sync_mux_ck", "pad_clks_ck",
-};
-
-DEFINE_CLK_OMAP_MUX(per_mcbsp4_gfclk, "l4_per_clkdm", per_mcbsp4_gfclk_sel,
-		    OMAP4430_CM_L4PER_MCBSP4_CLKCTRL,
-		    OMAP4430_CLKSEL_SOURCE_24_24_MASK, per_mcbsp4_gfclk_parents,
-		    func_dmic_abe_gfclk_ops);
-
-static const struct clksel hsmmc1_fclk_sel[] = {
-	{ .parent = &func_64m_fclk, .rates = div_1_0_rates },
-	{ .parent = &func_96m_fclk, .rates = div_1_1_rates },
-	{ .parent = NULL },
-};
-
-static const char *hsmmc1_fclk_parents[] = {
-	"func_64m_fclk", "func_96m_fclk",
-};
-
-DEFINE_CLK_OMAP_MUX(hsmmc1_fclk, "l3_init_clkdm", hsmmc1_fclk_sel,
-		    OMAP4430_CM_L3INIT_MMC1_CLKCTRL, OMAP4430_CLKSEL_MASK,
-		    hsmmc1_fclk_parents, func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_OMAP_MUX(hsmmc2_fclk, "l3_init_clkdm", hsmmc1_fclk_sel,
-		    OMAP4430_CM_L3INIT_MMC2_CLKCTRL, OMAP4430_CLKSEL_MASK,
-		    hsmmc1_fclk_parents, func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_GATE(ocp2scp_usb_phy_phy_48m, "func_48m_fclk", &func_48m_fclk, 0x0,
-		OMAP4430_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL,
-		OMAP4430_OPTFCLKEN_PHY_48M_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(sha2md5_fck, "l3_div_ck", &l3_div_ck, 0x0,
-		OMAP4430_CM_L4SEC_SHA2MD51_CLKCTRL,
-		OMAP4430_MODULEMODE_SWCTRL_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(slimbus1_fclk_1, "func_24m_clk", &func_24m_clk, 0x0,
-		OMAP4430_CM1_ABE_SLIMBUS_CLKCTRL,
-		OMAP4430_OPTFCLKEN_FCLK1_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(slimbus1_fclk_0, "abe_24m_fclk", &abe_24m_fclk, 0x0,
-		OMAP4430_CM1_ABE_SLIMBUS_CLKCTRL,
-		OMAP4430_OPTFCLKEN_FCLK0_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(slimbus1_fclk_2, "pad_clks_ck", &pad_clks_ck, 0x0,
-		OMAP4430_CM1_ABE_SLIMBUS_CLKCTRL,
-		OMAP4430_OPTFCLKEN_FCLK2_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(slimbus1_slimbus_clk, "slimbus_clk", &slimbus_clk, 0x0,
-		OMAP4430_CM1_ABE_SLIMBUS_CLKCTRL,
-		OMAP4430_OPTFCLKEN_SLIMBUS_CLK_11_11_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(slimbus2_fclk_1, "per_abe_24m_fclk", &per_abe_24m_fclk, 0x0,
-		OMAP4430_CM_L4PER_SLIMBUS2_CLKCTRL,
-		OMAP4430_OPTFCLKEN_PERABE24M_GFCLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(slimbus2_fclk_0, "func_24mc_fclk", &func_24mc_fclk, 0x0,
-		OMAP4430_CM_L4PER_SLIMBUS2_CLKCTRL,
-		OMAP4430_OPTFCLKEN_PER24MC_GFCLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(slimbus2_slimbus_clk, "pad_slimbus_core_clks_ck",
-		&pad_slimbus_core_clks_ck, 0x0,
-		OMAP4430_CM_L4PER_SLIMBUS2_CLKCTRL,
-		OMAP4430_OPTFCLKEN_SLIMBUS_CLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(smartreflex_core_fck, "l4_wkup_clk_mux_ck", &l4_wkup_clk_mux_ck,
-		0x0, OMAP4430_CM_ALWON_SR_CORE_CLKCTRL,
-		OMAP4430_MODULEMODE_SWCTRL_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(smartreflex_iva_fck, "l4_wkup_clk_mux_ck", &l4_wkup_clk_mux_ck,
-		0x0, OMAP4430_CM_ALWON_SR_IVA_CLKCTRL,
-		OMAP4430_MODULEMODE_SWCTRL_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(smartreflex_mpu_fck, "l4_wkup_clk_mux_ck", &l4_wkup_clk_mux_ck,
-		0x0, OMAP4430_CM_ALWON_SR_MPU_CLKCTRL,
-		OMAP4430_MODULEMODE_SWCTRL_SHIFT, 0x0, NULL);
-
-static const struct clksel dmt1_clk_mux_sel[] = {
-	{ .parent = &sys_clkin_ck, .rates = div_1_0_rates },
-	{ .parent = &sys_32k_ck, .rates = div_1_1_rates },
-	{ .parent = NULL },
-};
-
-DEFINE_CLK_OMAP_MUX(dmt1_clk_mux, "l4_wkup_clkdm", dmt1_clk_mux_sel,
-		    OMAP4430_CM_WKUP_TIMER1_CLKCTRL, OMAP4430_CLKSEL_MASK,
-		    abe_dpll_bypass_clk_mux_ck_parents,
-		    func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_OMAP_MUX(cm2_dm10_mux, "l4_per_clkdm", dmt1_clk_mux_sel,
-		    OMAP4430_CM_L4PER_DMTIMER10_CLKCTRL, OMAP4430_CLKSEL_MASK,
-		    abe_dpll_bypass_clk_mux_ck_parents,
-		    func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_OMAP_MUX(cm2_dm11_mux, "l4_per_clkdm", dmt1_clk_mux_sel,
-		    OMAP4430_CM_L4PER_DMTIMER11_CLKCTRL, OMAP4430_CLKSEL_MASK,
-		    abe_dpll_bypass_clk_mux_ck_parents,
-		    func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_OMAP_MUX(cm2_dm2_mux, "l4_per_clkdm", dmt1_clk_mux_sel,
-		    OMAP4430_CM_L4PER_DMTIMER2_CLKCTRL, OMAP4430_CLKSEL_MASK,
-		    abe_dpll_bypass_clk_mux_ck_parents,
-		    func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_OMAP_MUX(cm2_dm3_mux, "l4_per_clkdm", dmt1_clk_mux_sel,
-		    OMAP4430_CM_L4PER_DMTIMER3_CLKCTRL, OMAP4430_CLKSEL_MASK,
-		    abe_dpll_bypass_clk_mux_ck_parents,
-		    func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_OMAP_MUX(cm2_dm4_mux, "l4_per_clkdm", dmt1_clk_mux_sel,
-		    OMAP4430_CM_L4PER_DMTIMER4_CLKCTRL, OMAP4430_CLKSEL_MASK,
-		    abe_dpll_bypass_clk_mux_ck_parents,
-		    func_dmic_abe_gfclk_ops);
-
-static const struct clksel timer5_sync_mux_sel[] = {
-	{ .parent = &syc_clk_div_ck, .rates = div_1_0_rates },
-	{ .parent = &sys_32k_ck, .rates = div_1_1_rates },
-	{ .parent = NULL },
-};
-
-static const char *timer5_sync_mux_parents[] = {
-	"syc_clk_div_ck", "sys_32k_ck",
-};
-
-DEFINE_CLK_OMAP_MUX(timer5_sync_mux, "abe_clkdm", timer5_sync_mux_sel,
-		    OMAP4430_CM1_ABE_TIMER5_CLKCTRL, OMAP4430_CLKSEL_MASK,
-		    timer5_sync_mux_parents, func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_OMAP_MUX(timer6_sync_mux, "abe_clkdm", timer5_sync_mux_sel,
-		    OMAP4430_CM1_ABE_TIMER6_CLKCTRL, OMAP4430_CLKSEL_MASK,
-		    timer5_sync_mux_parents, func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_OMAP_MUX(timer7_sync_mux, "abe_clkdm", timer5_sync_mux_sel,
-		    OMAP4430_CM1_ABE_TIMER7_CLKCTRL, OMAP4430_CLKSEL_MASK,
-		    timer5_sync_mux_parents, func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_OMAP_MUX(timer8_sync_mux, "abe_clkdm", timer5_sync_mux_sel,
-		    OMAP4430_CM1_ABE_TIMER8_CLKCTRL, OMAP4430_CLKSEL_MASK,
-		    timer5_sync_mux_parents, func_dmic_abe_gfclk_ops);
-
-DEFINE_CLK_OMAP_MUX(cm2_dm9_mux, "l4_per_clkdm", dmt1_clk_mux_sel,
-		    OMAP4430_CM_L4PER_DMTIMER9_CLKCTRL, OMAP4430_CLKSEL_MASK,
-		    abe_dpll_bypass_clk_mux_ck_parents,
-		    func_dmic_abe_gfclk_ops);
-
-static struct clk usb_host_fs_fck;
-
-static const char *usb_host_fs_fck_parent_names[] = {
-	"func_48mc_fclk",
-};
-
-static const struct clk_ops usb_host_fs_fck_ops = {
-	.enable		= &omap2_dflt_clk_enable,
-	.disable	= &omap2_dflt_clk_disable,
-	.is_enabled	= &omap2_dflt_clk_is_enabled,
-};
-
-static struct clk_hw_omap usb_host_fs_fck_hw = {
-	.hw = {
-		.clk = &usb_host_fs_fck,
-	},
-	.enable_reg	= OMAP4430_CM_L3INIT_USB_HOST_FS_CLKCTRL,
-	.enable_bit	= OMAP4430_MODULEMODE_SWCTRL_SHIFT,
-	.clkdm_name	= "l3_init_clkdm",
-};
-
-DEFINE_STRUCT_CLK(usb_host_fs_fck, usb_host_fs_fck_parent_names,
-		  usb_host_fs_fck_ops);
-
-static const char *utmi_p1_gfclk_parents[] = {
-	"init_60m_fclk", "xclk60mhsp1_ck",
-};
-
-DEFINE_CLK_MUX(utmi_p1_gfclk, utmi_p1_gfclk_parents, NULL, 0x0,
-	       OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-	       OMAP4430_CLKSEL_UTMI_P1_SHIFT, OMAP4430_CLKSEL_UTMI_P1_WIDTH,
-	       0x0, NULL);
-
-DEFINE_CLK_GATE(usb_host_hs_utmi_p1_clk, "utmi_p1_gfclk", &utmi_p1_gfclk, 0x0,
-		OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-		OMAP4430_OPTFCLKEN_UTMI_P1_CLK_SHIFT, 0x0, NULL);
-
-static const char *utmi_p2_gfclk_parents[] = {
-	"init_60m_fclk", "xclk60mhsp2_ck",
-};
-
-DEFINE_CLK_MUX(utmi_p2_gfclk, utmi_p2_gfclk_parents, NULL, 0x0,
-	       OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-	       OMAP4430_CLKSEL_UTMI_P2_SHIFT, OMAP4430_CLKSEL_UTMI_P2_WIDTH,
-	       0x0, NULL);
-
-DEFINE_CLK_GATE(usb_host_hs_utmi_p2_clk, "utmi_p2_gfclk", &utmi_p2_gfclk, 0x0,
-		OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-		OMAP4430_OPTFCLKEN_UTMI_P2_CLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(usb_host_hs_utmi_p3_clk, "init_60m_fclk", &init_60m_fclk, 0x0,
-		OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-		OMAP4430_OPTFCLKEN_UTMI_P3_CLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(usb_host_hs_hsic480m_p1_clk, "dpll_usb_m2_ck",
-		&dpll_usb_m2_ck, 0x0,
-		OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-		OMAP4430_OPTFCLKEN_HSIC480M_P1_CLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(usb_host_hs_hsic60m_p1_clk, "init_60m_fclk",
-		&init_60m_fclk, 0x0,
-		OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-		OMAP4430_OPTFCLKEN_HSIC60M_P1_CLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(usb_host_hs_hsic60m_p2_clk, "init_60m_fclk",
-		&init_60m_fclk, 0x0,
-		OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-		OMAP4430_OPTFCLKEN_HSIC60M_P2_CLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(usb_host_hs_hsic480m_p2_clk, "dpll_usb_m2_ck",
-		&dpll_usb_m2_ck, 0x0,
-		OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-		OMAP4430_OPTFCLKEN_HSIC480M_P2_CLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(usb_host_hs_func48mclk, "func_48mc_fclk", &func_48mc_fclk, 0x0,
-		OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-		OMAP4430_OPTFCLKEN_FUNC48MCLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(usb_host_hs_fck, "init_60m_fclk", &init_60m_fclk, 0x0,
-		OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-		OMAP4430_MODULEMODE_SWCTRL_SHIFT, 0x0, NULL);
-
-static const char *otg_60m_gfclk_parents[] = {
-	"utmi_phy_clkout_ck", "xclk60motg_ck",
-};
-
-DEFINE_CLK_MUX(otg_60m_gfclk, otg_60m_gfclk_parents, NULL, 0x0,
-	       OMAP4430_CM_L3INIT_USB_OTG_CLKCTRL, OMAP4430_CLKSEL_60M_SHIFT,
-	       OMAP4430_CLKSEL_60M_WIDTH, 0x0, NULL);
-
-DEFINE_CLK_GATE(usb_otg_hs_xclk, "otg_60m_gfclk", &otg_60m_gfclk, 0x0,
-		OMAP4430_CM_L3INIT_USB_OTG_CLKCTRL,
-		OMAP4430_OPTFCLKEN_XCLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(usb_otg_hs_ick, "l3_div_ck", &l3_div_ck, 0x0,
-		OMAP4430_CM_L3INIT_USB_OTG_CLKCTRL,
-		OMAP4430_MODULEMODE_HWCTRL_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(usb_phy_cm_clk32k, "sys_32k_ck", &sys_32k_ck, 0x0,
-		OMAP4430_CM_ALWON_USBPHY_CLKCTRL,
-		OMAP4430_OPTFCLKEN_CLK32K_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(usb_tll_hs_usb_ch2_clk, "init_60m_fclk", &init_60m_fclk, 0x0,
-		OMAP4430_CM_L3INIT_USB_TLL_CLKCTRL,
-		OMAP4430_OPTFCLKEN_USB_CH2_CLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(usb_tll_hs_usb_ch0_clk, "init_60m_fclk", &init_60m_fclk, 0x0,
-		OMAP4430_CM_L3INIT_USB_TLL_CLKCTRL,
-		OMAP4430_OPTFCLKEN_USB_CH0_CLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(usb_tll_hs_usb_ch1_clk, "init_60m_fclk", &init_60m_fclk, 0x0,
-		OMAP4430_CM_L3INIT_USB_TLL_CLKCTRL,
-		OMAP4430_OPTFCLKEN_USB_CH1_CLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(usb_tll_hs_ick, "l4_div_ck", &l4_div_ck, 0x0,
-		OMAP4430_CM_L3INIT_USB_TLL_CLKCTRL,
-		OMAP4430_MODULEMODE_HWCTRL_SHIFT, 0x0, NULL);
-
-static const struct clk_div_table usim_ck_rates[] = {
-	{ .div = 14, .val = 0 },
-	{ .div = 18, .val = 1 },
-	{ .div = 0 },
-};
-DEFINE_CLK_DIVIDER_TABLE(usim_ck, "dpll_per_m4x2_ck", &dpll_per_m4x2_ck, 0x0,
-			 OMAP4430_CM_WKUP_USIM_CLKCTRL,
-			 OMAP4430_CLKSEL_DIV_SHIFT, OMAP4430_CLKSEL_DIV_WIDTH,
-			 0x0, usim_ck_rates, NULL);
-
-DEFINE_CLK_GATE(usim_fclk, "usim_ck", &usim_ck, 0x0,
-		OMAP4430_CM_WKUP_USIM_CLKCTRL, OMAP4430_OPTFCLKEN_FCLK_SHIFT,
-		0x0, NULL);
-
-/* Remaining optional clocks */
-static const char *pmd_stm_clock_mux_ck_parents[] = {
-	"sys_clkin_ck", "dpll_core_m6x2_ck", "tie_low_clock_ck",
-};
-
-DEFINE_CLK_MUX(pmd_stm_clock_mux_ck, pmd_stm_clock_mux_ck_parents, NULL, 0x0,
-	       OMAP4430_CM_EMU_DEBUGSS_CLKCTRL, OMAP4430_PMD_STM_MUX_CTRL_SHIFT,
-	       OMAP4430_PMD_STM_MUX_CTRL_WIDTH, 0x0, NULL);
-
-DEFINE_CLK_MUX(pmd_trace_clk_mux_ck, pmd_stm_clock_mux_ck_parents, NULL, 0x0,
-	       OMAP4430_CM_EMU_DEBUGSS_CLKCTRL,
-	       OMAP4430_PMD_TRACE_MUX_CTRL_SHIFT,
-	       OMAP4430_PMD_TRACE_MUX_CTRL_WIDTH, 0x0, NULL);
-
-DEFINE_CLK_DIVIDER(stm_clk_div_ck, "pmd_stm_clock_mux_ck",
-		   &pmd_stm_clock_mux_ck, 0x0, OMAP4430_CM_EMU_DEBUGSS_CLKCTRL,
-		   OMAP4430_CLKSEL_PMD_STM_CLK_SHIFT,
-		   OMAP4430_CLKSEL_PMD_STM_CLK_WIDTH, CLK_DIVIDER_POWER_OF_TWO,
-		   NULL);
-
-static const char *trace_clk_div_ck_parents[] = {
-	"pmd_trace_clk_mux_ck",
-};
-
-static const struct clksel trace_clk_div_div[] = {
-	{ .parent = &pmd_trace_clk_mux_ck, .rates = div3_1to4_rates },
-	{ .parent = NULL },
-};
-
-static struct clk trace_clk_div_ck;
-
-static const struct clk_ops trace_clk_div_ck_ops = {
-	.recalc_rate	= &omap2_clksel_recalc,
-	.set_rate	= &omap2_clksel_set_rate,
-	.round_rate	= &omap2_clksel_round_rate,
-	.init		= &omap2_init_clk_clkdm,
-	.enable		= &omap2_clkops_enable_clkdm,
-	.disable	= &omap2_clkops_disable_clkdm,
-};
-
-static struct clk_hw_omap trace_clk_div_ck_hw = {
-	.hw = {
-		.clk = &trace_clk_div_ck,
-	},
-	.clkdm_name	= "emu_sys_clkdm",
-	.clksel		= trace_clk_div_div,
-	.clksel_reg	= OMAP4430_CM_EMU_DEBUGSS_CLKCTRL,
-	.clksel_mask	= OMAP4430_CLKSEL_PMD_TRACE_CLK_MASK,
-};
-
-DEFINE_STRUCT_CLK(trace_clk_div_ck, trace_clk_div_ck_parents,
-		  trace_clk_div_ck_ops);
-
-/* SCRM aux clk nodes */
-
-static const struct clksel auxclk_src_sel[] = {
-	{ .parent = &sys_clkin_ck, .rates = div_1_0_rates },
-	{ .parent = &dpll_core_m3x2_ck, .rates = div_1_1_rates },
-	{ .parent = &dpll_per_m3x2_ck, .rates = div_1_2_rates },
-	{ .parent = NULL },
-};
-
-static const char *auxclk_src_ck_parents[] = {
-	"sys_clkin_ck", "dpll_core_m3x2_ck", "dpll_per_m3x2_ck",
-};
-
-static const struct clk_ops auxclk_src_ck_ops = {
-	.enable		= &omap2_dflt_clk_enable,
-	.disable	= &omap2_dflt_clk_disable,
-	.is_enabled	= &omap2_dflt_clk_is_enabled,
-	.recalc_rate	= &omap2_clksel_recalc,
-	.get_parent	= &omap2_clksel_find_parent_index,
-};
-
-DEFINE_CLK_OMAP_MUX_GATE(auxclk0_src_ck, NULL, auxclk_src_sel,
-			 OMAP4_SCRM_AUXCLK0, OMAP4_SRCSELECT_MASK,
-			 OMAP4_SCRM_AUXCLK0, OMAP4_ENABLE_SHIFT, NULL,
-			 auxclk_src_ck_parents, auxclk_src_ck_ops);
-
-DEFINE_CLK_DIVIDER(auxclk0_ck, "auxclk0_src_ck", &auxclk0_src_ck, 0x0,
-		   OMAP4_SCRM_AUXCLK0, OMAP4_CLKDIV_SHIFT, OMAP4_CLKDIV_WIDTH,
-		   0x0, NULL);
-
-DEFINE_CLK_OMAP_MUX_GATE(auxclk1_src_ck, NULL, auxclk_src_sel,
-			 OMAP4_SCRM_AUXCLK1, OMAP4_SRCSELECT_MASK,
-			 OMAP4_SCRM_AUXCLK1, OMAP4_ENABLE_SHIFT, NULL,
-			 auxclk_src_ck_parents, auxclk_src_ck_ops);
-
-DEFINE_CLK_DIVIDER(auxclk1_ck, "auxclk1_src_ck", &auxclk1_src_ck, 0x0,
-		   OMAP4_SCRM_AUXCLK1, OMAP4_CLKDIV_SHIFT, OMAP4_CLKDIV_WIDTH,
-		   0x0, NULL);
-
-DEFINE_CLK_OMAP_MUX_GATE(auxclk2_src_ck, NULL, auxclk_src_sel,
-			 OMAP4_SCRM_AUXCLK2, OMAP4_SRCSELECT_MASK,
-			 OMAP4_SCRM_AUXCLK2, OMAP4_ENABLE_SHIFT, NULL,
-			 auxclk_src_ck_parents, auxclk_src_ck_ops);
-
-DEFINE_CLK_DIVIDER(auxclk2_ck, "auxclk2_src_ck", &auxclk2_src_ck, 0x0,
-		   OMAP4_SCRM_AUXCLK2, OMAP4_CLKDIV_SHIFT, OMAP4_CLKDIV_WIDTH,
-		   0x0, NULL);
-
-DEFINE_CLK_OMAP_MUX_GATE(auxclk3_src_ck, NULL, auxclk_src_sel,
-			 OMAP4_SCRM_AUXCLK3, OMAP4_SRCSELECT_MASK,
-			 OMAP4_SCRM_AUXCLK3, OMAP4_ENABLE_SHIFT, NULL,
-			 auxclk_src_ck_parents, auxclk_src_ck_ops);
-
-DEFINE_CLK_DIVIDER(auxclk3_ck, "auxclk3_src_ck", &auxclk3_src_ck, 0x0,
-		   OMAP4_SCRM_AUXCLK3, OMAP4_CLKDIV_SHIFT, OMAP4_CLKDIV_WIDTH,
-		   0x0, NULL);
-
-DEFINE_CLK_OMAP_MUX_GATE(auxclk4_src_ck, NULL, auxclk_src_sel,
-			 OMAP4_SCRM_AUXCLK4, OMAP4_SRCSELECT_MASK,
-			 OMAP4_SCRM_AUXCLK4, OMAP4_ENABLE_SHIFT, NULL,
-			 auxclk_src_ck_parents, auxclk_src_ck_ops);
-
-DEFINE_CLK_DIVIDER(auxclk4_ck, "auxclk4_src_ck", &auxclk4_src_ck, 0x0,
-		   OMAP4_SCRM_AUXCLK4, OMAP4_CLKDIV_SHIFT, OMAP4_CLKDIV_WIDTH,
-		   0x0, NULL);
-
-DEFINE_CLK_OMAP_MUX_GATE(auxclk5_src_ck, NULL, auxclk_src_sel,
-			 OMAP4_SCRM_AUXCLK5, OMAP4_SRCSELECT_MASK,
-			 OMAP4_SCRM_AUXCLK5, OMAP4_ENABLE_SHIFT, NULL,
-			 auxclk_src_ck_parents, auxclk_src_ck_ops);
-
-DEFINE_CLK_DIVIDER(auxclk5_ck, "auxclk5_src_ck", &auxclk5_src_ck, 0x0,
-		   OMAP4_SCRM_AUXCLK5, OMAP4_CLKDIV_SHIFT, OMAP4_CLKDIV_WIDTH,
-		   0x0, NULL);
-
-static const char *auxclkreq_ck_parents[] = {
-	"auxclk0_ck", "auxclk1_ck", "auxclk2_ck", "auxclk3_ck", "auxclk4_ck",
-	"auxclk5_ck",
-};
-
-DEFINE_CLK_MUX(auxclkreq0_ck, auxclkreq_ck_parents, NULL, 0x0,
-	       OMAP4_SCRM_AUXCLKREQ0, OMAP4_MAPPING_SHIFT, OMAP4_MAPPING_WIDTH,
-	       0x0, NULL);
-
-DEFINE_CLK_MUX(auxclkreq1_ck, auxclkreq_ck_parents, NULL, 0x0,
-	       OMAP4_SCRM_AUXCLKREQ1, OMAP4_MAPPING_SHIFT, OMAP4_MAPPING_WIDTH,
-	       0x0, NULL);
-
-DEFINE_CLK_MUX(auxclkreq2_ck, auxclkreq_ck_parents, NULL, 0x0,
-	       OMAP4_SCRM_AUXCLKREQ2, OMAP4_MAPPING_SHIFT, OMAP4_MAPPING_WIDTH,
-	       0x0, NULL);
-
-DEFINE_CLK_MUX(auxclkreq3_ck, auxclkreq_ck_parents, NULL, 0x0,
-	       OMAP4_SCRM_AUXCLKREQ3, OMAP4_MAPPING_SHIFT, OMAP4_MAPPING_WIDTH,
-	       0x0, NULL);
-
-DEFINE_CLK_MUX(auxclkreq4_ck, auxclkreq_ck_parents, NULL, 0x0,
-	       OMAP4_SCRM_AUXCLKREQ4, OMAP4_MAPPING_SHIFT, OMAP4_MAPPING_WIDTH,
-	       0x0, NULL);
-
-DEFINE_CLK_MUX(auxclkreq5_ck, auxclkreq_ck_parents, NULL, 0x0,
-	       OMAP4_SCRM_AUXCLKREQ5, OMAP4_MAPPING_SHIFT, OMAP4_MAPPING_WIDTH,
-	       0x0, NULL);
-
-/*
- * clocks specific to omap4460
- */
-static struct omap_clk omap446x_clks[] = {
-	CLK(NULL,	"div_ts_ck",			&div_ts_ck),
-	CLK(NULL,	"bandgap_ts_fclk",		&bandgap_ts_fclk),
-};
-
-/*
- * clocks specific to omap4430
- */
-static struct omap_clk omap443x_clks[] = {
-	CLK(NULL,	"bandgap_fclk",			&bandgap_fclk),
-};
-
-/*
- * clocks common to omap44xx
- */
-static struct omap_clk omap44xx_clks[] = {
-	CLK(NULL,	"extalt_clkin_ck",		&extalt_clkin_ck),
-	CLK(NULL,	"pad_clks_src_ck",		&pad_clks_src_ck),
-	CLK(NULL,	"pad_clks_ck",			&pad_clks_ck),
-	CLK(NULL,	"pad_slimbus_core_clks_ck",	&pad_slimbus_core_clks_ck),
-	CLK(NULL,	"secure_32k_clk_src_ck",	&secure_32k_clk_src_ck),
-	CLK(NULL,	"slimbus_src_clk",		&slimbus_src_clk),
-	CLK(NULL,	"slimbus_clk",			&slimbus_clk),
-	CLK(NULL,	"sys_32k_ck",			&sys_32k_ck),
-	CLK(NULL,	"virt_12000000_ck",		&virt_12000000_ck),
-	CLK(NULL,	"virt_13000000_ck",		&virt_13000000_ck),
-	CLK(NULL,	"virt_16800000_ck",		&virt_16800000_ck),
-	CLK(NULL,	"virt_19200000_ck",		&virt_19200000_ck),
-	CLK(NULL,	"virt_26000000_ck",		&virt_26000000_ck),
-	CLK(NULL,	"virt_27000000_ck",		&virt_27000000_ck),
-	CLK(NULL,	"virt_38400000_ck",		&virt_38400000_ck),
-	CLK(NULL,	"sys_clkin_ck",			&sys_clkin_ck),
-	CLK(NULL,	"tie_low_clock_ck",		&tie_low_clock_ck),
-	CLK(NULL,	"utmi_phy_clkout_ck",		&utmi_phy_clkout_ck),
-	CLK(NULL,	"xclk60mhsp1_ck",		&xclk60mhsp1_ck),
-	CLK(NULL,	"xclk60mhsp2_ck",		&xclk60mhsp2_ck),
-	CLK(NULL,	"xclk60motg_ck",		&xclk60motg_ck),
-	CLK(NULL,	"abe_dpll_bypass_clk_mux_ck",	&abe_dpll_bypass_clk_mux_ck),
-	CLK(NULL,	"abe_dpll_refclk_mux_ck",	&abe_dpll_refclk_mux_ck),
-	CLK(NULL,	"dpll_abe_ck",			&dpll_abe_ck),
-	CLK(NULL,	"dpll_abe_x2_ck",		&dpll_abe_x2_ck),
-	CLK(NULL,	"dpll_abe_m2x2_ck",		&dpll_abe_m2x2_ck),
-	CLK(NULL,	"abe_24m_fclk",			&abe_24m_fclk),
-	CLK(NULL,	"abe_clk",			&abe_clk),
-	CLK(NULL,	"aess_fclk",			&aess_fclk),
-	CLK(NULL,	"dpll_abe_m3x2_ck",		&dpll_abe_m3x2_ck),
-	CLK(NULL,	"core_hsd_byp_clk_mux_ck",	&core_hsd_byp_clk_mux_ck),
-	CLK(NULL,	"dpll_core_ck",			&dpll_core_ck),
-	CLK(NULL,	"dpll_core_x2_ck",		&dpll_core_x2_ck),
-	CLK(NULL,	"dpll_core_m6x2_ck",		&dpll_core_m6x2_ck),
-	CLK(NULL,	"dbgclk_mux_ck",		&dbgclk_mux_ck),
-	CLK(NULL,	"dpll_core_m2_ck",		&dpll_core_m2_ck),
-	CLK(NULL,	"ddrphy_ck",			&ddrphy_ck),
-	CLK(NULL,	"dpll_core_m5x2_ck",		&dpll_core_m5x2_ck),
-	CLK(NULL,	"div_core_ck",			&div_core_ck),
-	CLK(NULL,	"div_iva_hs_clk",		&div_iva_hs_clk),
-	CLK(NULL,	"div_mpu_hs_clk",		&div_mpu_hs_clk),
-	CLK(NULL,	"dpll_core_m4x2_ck",		&dpll_core_m4x2_ck),
-	CLK(NULL,	"dll_clk_div_ck",		&dll_clk_div_ck),
-	CLK(NULL,	"dpll_abe_m2_ck",		&dpll_abe_m2_ck),
-	CLK(NULL,	"dpll_core_m3x2_ck",		&dpll_core_m3x2_ck),
-	CLK(NULL,	"dpll_core_m7x2_ck",		&dpll_core_m7x2_ck),
-	CLK(NULL,	"iva_hsd_byp_clk_mux_ck",	&iva_hsd_byp_clk_mux_ck),
-	CLK(NULL,	"dpll_iva_ck",			&dpll_iva_ck),
-	CLK(NULL,	"dpll_iva_x2_ck",		&dpll_iva_x2_ck),
-	CLK(NULL,	"dpll_iva_m4x2_ck",		&dpll_iva_m4x2_ck),
-	CLK(NULL,	"dpll_iva_m5x2_ck",		&dpll_iva_m5x2_ck),
-	CLK(NULL,	"dpll_mpu_ck",			&dpll_mpu_ck),
-	CLK(NULL,	"dpll_mpu_m2_ck",		&dpll_mpu_m2_ck),
-	CLK(NULL,	"per_hs_clk_div_ck",		&per_hs_clk_div_ck),
-	CLK(NULL,	"per_hsd_byp_clk_mux_ck",	&per_hsd_byp_clk_mux_ck),
-	CLK(NULL,	"dpll_per_ck",			&dpll_per_ck),
-	CLK(NULL,	"dpll_per_m2_ck",		&dpll_per_m2_ck),
-	CLK(NULL,	"dpll_per_x2_ck",		&dpll_per_x2_ck),
-	CLK(NULL,	"dpll_per_m2x2_ck",		&dpll_per_m2x2_ck),
-	CLK(NULL,	"dpll_per_m3x2_ck",		&dpll_per_m3x2_ck),
-	CLK(NULL,	"dpll_per_m4x2_ck",		&dpll_per_m4x2_ck),
-	CLK(NULL,	"dpll_per_m5x2_ck",		&dpll_per_m5x2_ck),
-	CLK(NULL,	"dpll_per_m6x2_ck",		&dpll_per_m6x2_ck),
-	CLK(NULL,	"dpll_per_m7x2_ck",		&dpll_per_m7x2_ck),
-	CLK(NULL,	"usb_hs_clk_div_ck",		&usb_hs_clk_div_ck),
-	CLK(NULL,	"dpll_usb_ck",			&dpll_usb_ck),
-	CLK(NULL,	"dpll_usb_clkdcoldo_ck",	&dpll_usb_clkdcoldo_ck),
-	CLK(NULL,	"dpll_usb_m2_ck",		&dpll_usb_m2_ck),
-	CLK(NULL,	"ducati_clk_mux_ck",		&ducati_clk_mux_ck),
-	CLK(NULL,	"func_12m_fclk",		&func_12m_fclk),
-	CLK(NULL,	"func_24m_clk",			&func_24m_clk),
-	CLK(NULL,	"func_24mc_fclk",		&func_24mc_fclk),
-	CLK(NULL,	"func_48m_fclk",		&func_48m_fclk),
-	CLK(NULL,	"func_48mc_fclk",		&func_48mc_fclk),
-	CLK(NULL,	"func_64m_fclk",		&func_64m_fclk),
-	CLK(NULL,	"func_96m_fclk",		&func_96m_fclk),
-	CLK(NULL,	"init_60m_fclk",		&init_60m_fclk),
-	CLK(NULL,	"l3_div_ck",			&l3_div_ck),
-	CLK(NULL,	"l4_div_ck",			&l4_div_ck),
-	CLK(NULL,	"lp_clk_div_ck",		&lp_clk_div_ck),
-	CLK(NULL,	"l4_wkup_clk_mux_ck",		&l4_wkup_clk_mux_ck),
-	CLK("smp_twd",	NULL,				&mpu_periphclk),
-	CLK(NULL,	"ocp_abe_iclk",			&ocp_abe_iclk),
-	CLK(NULL,	"per_abe_24m_fclk",		&per_abe_24m_fclk),
-	CLK(NULL,	"per_abe_nc_fclk",		&per_abe_nc_fclk),
-	CLK(NULL,	"syc_clk_div_ck",		&syc_clk_div_ck),
-	CLK(NULL,	"aes1_fck",			&aes1_fck),
-	CLK(NULL,	"aes2_fck",			&aes2_fck),
-	CLK(NULL,	"dmic_sync_mux_ck",		&dmic_sync_mux_ck),
-	CLK(NULL,	"func_dmic_abe_gfclk",		&func_dmic_abe_gfclk),
-	CLK(NULL,	"dss_sys_clk",			&dss_sys_clk),
-	CLK(NULL,	"dss_tv_clk",			&dss_tv_clk),
-	CLK(NULL,	"dss_dss_clk",			&dss_dss_clk),
-	CLK(NULL,	"dss_48mhz_clk",		&dss_48mhz_clk),
-	CLK(NULL,	"dss_fck",			&dss_fck),
-	CLK("omapdss_dss",	"ick",			&dss_fck),
-	CLK(NULL,	"fdif_fck",			&fdif_fck),
-	CLK(NULL,	"gpio1_dbclk",			&gpio1_dbclk),
-	CLK(NULL,	"gpio2_dbclk",			&gpio2_dbclk),
-	CLK(NULL,	"gpio3_dbclk",			&gpio3_dbclk),
-	CLK(NULL,	"gpio4_dbclk",			&gpio4_dbclk),
-	CLK(NULL,	"gpio5_dbclk",			&gpio5_dbclk),
-	CLK(NULL,	"gpio6_dbclk",			&gpio6_dbclk),
-	CLK(NULL,	"sgx_clk_mux",			&sgx_clk_mux),
-	CLK(NULL,	"hsi_fck",			&hsi_fck),
-	CLK(NULL,	"iss_ctrlclk",			&iss_ctrlclk),
-	CLK(NULL,	"mcasp_sync_mux_ck",		&mcasp_sync_mux_ck),
-	CLK(NULL,	"func_mcasp_abe_gfclk",		&func_mcasp_abe_gfclk),
-	CLK(NULL,	"mcbsp1_sync_mux_ck",		&mcbsp1_sync_mux_ck),
-	CLK(NULL,	"func_mcbsp1_gfclk",		&func_mcbsp1_gfclk),
-	CLK(NULL,	"mcbsp2_sync_mux_ck",		&mcbsp2_sync_mux_ck),
-	CLK(NULL,	"func_mcbsp2_gfclk",		&func_mcbsp2_gfclk),
-	CLK(NULL,	"mcbsp3_sync_mux_ck",		&mcbsp3_sync_mux_ck),
-	CLK(NULL,	"func_mcbsp3_gfclk",		&func_mcbsp3_gfclk),
-	CLK(NULL,	"mcbsp4_sync_mux_ck",		&mcbsp4_sync_mux_ck),
-	CLK(NULL,	"per_mcbsp4_gfclk",		&per_mcbsp4_gfclk),
-	CLK(NULL,	"hsmmc1_fclk",			&hsmmc1_fclk),
-	CLK(NULL,	"hsmmc2_fclk",			&hsmmc2_fclk),
-	CLK(NULL,	"ocp2scp_usb_phy_phy_48m",	&ocp2scp_usb_phy_phy_48m),
-	CLK(NULL,	"sha2md5_fck",			&sha2md5_fck),
-	CLK(NULL,	"slimbus1_fclk_1",		&slimbus1_fclk_1),
-	CLK(NULL,	"slimbus1_fclk_0",		&slimbus1_fclk_0),
-	CLK(NULL,	"slimbus1_fclk_2",		&slimbus1_fclk_2),
-	CLK(NULL,	"slimbus1_slimbus_clk",		&slimbus1_slimbus_clk),
-	CLK(NULL,	"slimbus2_fclk_1",		&slimbus2_fclk_1),
-	CLK(NULL,	"slimbus2_fclk_0",		&slimbus2_fclk_0),
-	CLK(NULL,	"slimbus2_slimbus_clk",		&slimbus2_slimbus_clk),
-	CLK(NULL,	"smartreflex_core_fck",		&smartreflex_core_fck),
-	CLK(NULL,	"smartreflex_iva_fck",		&smartreflex_iva_fck),
-	CLK(NULL,	"smartreflex_mpu_fck",		&smartreflex_mpu_fck),
-	CLK(NULL,	"dmt1_clk_mux",			&dmt1_clk_mux),
-	CLK(NULL,	"cm2_dm10_mux",			&cm2_dm10_mux),
-	CLK(NULL,	"cm2_dm11_mux",			&cm2_dm11_mux),
-	CLK(NULL,	"cm2_dm2_mux",			&cm2_dm2_mux),
-	CLK(NULL,	"cm2_dm3_mux",			&cm2_dm3_mux),
-	CLK(NULL,	"cm2_dm4_mux",			&cm2_dm4_mux),
-	CLK(NULL,	"timer5_sync_mux",		&timer5_sync_mux),
-	CLK(NULL,	"timer6_sync_mux",		&timer6_sync_mux),
-	CLK(NULL,	"timer7_sync_mux",		&timer7_sync_mux),
-	CLK(NULL,	"timer8_sync_mux",		&timer8_sync_mux),
-	CLK(NULL,	"cm2_dm9_mux",			&cm2_dm9_mux),
-	CLK(NULL,	"usb_host_fs_fck",		&usb_host_fs_fck),
-	CLK("usbhs_omap",	"fs_fck",		&usb_host_fs_fck),
-	CLK(NULL,	"utmi_p1_gfclk",		&utmi_p1_gfclk),
-	CLK(NULL,	"usb_host_hs_utmi_p1_clk",	&usb_host_hs_utmi_p1_clk),
-	CLK(NULL,	"utmi_p2_gfclk",		&utmi_p2_gfclk),
-	CLK(NULL,	"usb_host_hs_utmi_p2_clk",	&usb_host_hs_utmi_p2_clk),
-	CLK(NULL,	"usb_host_hs_utmi_p3_clk",	&usb_host_hs_utmi_p3_clk),
-	CLK(NULL,	"usb_host_hs_hsic480m_p1_clk",	&usb_host_hs_hsic480m_p1_clk),
-	CLK(NULL,	"usb_host_hs_hsic60m_p1_clk",	&usb_host_hs_hsic60m_p1_clk),
-	CLK(NULL,	"usb_host_hs_hsic60m_p2_clk",	&usb_host_hs_hsic60m_p2_clk),
-	CLK(NULL,	"usb_host_hs_hsic480m_p2_clk",	&usb_host_hs_hsic480m_p2_clk),
-	CLK(NULL,	"usb_host_hs_func48mclk",	&usb_host_hs_func48mclk),
-	CLK(NULL,	"usb_host_hs_fck",		&usb_host_hs_fck),
-	CLK("usbhs_omap",	"hs_fck",		&usb_host_hs_fck),
-	CLK(NULL,	"otg_60m_gfclk",		&otg_60m_gfclk),
-	CLK(NULL,	"usb_otg_hs_xclk",		&usb_otg_hs_xclk),
-	CLK(NULL,	"usb_otg_hs_ick",		&usb_otg_hs_ick),
-	CLK("musb-omap2430",	"ick",			&usb_otg_hs_ick),
-	CLK(NULL,	"usb_phy_cm_clk32k",		&usb_phy_cm_clk32k),
-	CLK(NULL,	"usb_tll_hs_usb_ch2_clk",	&usb_tll_hs_usb_ch2_clk),
-	CLK(NULL,	"usb_tll_hs_usb_ch0_clk",	&usb_tll_hs_usb_ch0_clk),
-	CLK(NULL,	"usb_tll_hs_usb_ch1_clk",	&usb_tll_hs_usb_ch1_clk),
-	CLK(NULL,	"usb_tll_hs_ick",		&usb_tll_hs_ick),
-	CLK("usbhs_omap",	"usbtll_ick",		&usb_tll_hs_ick),
-	CLK("usbhs_tll",	"usbtll_ick",		&usb_tll_hs_ick),
-	CLK(NULL,	"usim_ck",			&usim_ck),
-	CLK(NULL,	"usim_fclk",			&usim_fclk),
-	CLK(NULL,	"pmd_stm_clock_mux_ck",		&pmd_stm_clock_mux_ck),
-	CLK(NULL,	"pmd_trace_clk_mux_ck",		&pmd_trace_clk_mux_ck),
-	CLK(NULL,	"stm_clk_div_ck",		&stm_clk_div_ck),
-	CLK(NULL,	"trace_clk_div_ck",		&trace_clk_div_ck),
-	CLK(NULL,	"auxclk0_src_ck",		&auxclk0_src_ck),
-	CLK(NULL,	"auxclk0_ck",			&auxclk0_ck),
-	CLK(NULL,	"auxclkreq0_ck",		&auxclkreq0_ck),
-	CLK(NULL,	"auxclk1_src_ck",		&auxclk1_src_ck),
-	CLK(NULL,	"auxclk1_ck",			&auxclk1_ck),
-	CLK(NULL,	"auxclkreq1_ck",		&auxclkreq1_ck),
-	CLK(NULL,	"auxclk2_src_ck",		&auxclk2_src_ck),
-	CLK(NULL,	"auxclk2_ck",			&auxclk2_ck),
-	CLK(NULL,	"auxclkreq2_ck",		&auxclkreq2_ck),
-	CLK(NULL,	"auxclk3_src_ck",		&auxclk3_src_ck),
-	CLK(NULL,	"auxclk3_ck",			&auxclk3_ck),
-	CLK(NULL,	"auxclkreq3_ck",		&auxclkreq3_ck),
-	CLK(NULL,	"auxclk4_src_ck",		&auxclk4_src_ck),
-	CLK(NULL,	"auxclk4_ck",			&auxclk4_ck),
-	CLK(NULL,	"auxclkreq4_ck",		&auxclkreq4_ck),
-	CLK(NULL,	"auxclk5_src_ck",		&auxclk5_src_ck),
-	CLK(NULL,	"auxclk5_ck",			&auxclk5_ck),
-	CLK(NULL,	"auxclkreq5_ck",		&auxclkreq5_ck),
-	CLK("omap-gpmc",	"fck",			&dummy_ck),
-	CLK("omap_i2c.1",	"ick",			&dummy_ck),
-	CLK("omap_i2c.2",	"ick",			&dummy_ck),
-	CLK("omap_i2c.3",	"ick",			&dummy_ck),
-	CLK("omap_i2c.4",	"ick",			&dummy_ck),
-	CLK(NULL,	"mailboxes_ick",		&dummy_ck),
-	CLK("omap_hsmmc.0",	"ick",			&dummy_ck),
-	CLK("omap_hsmmc.1",	"ick",			&dummy_ck),
-	CLK("omap_hsmmc.2",	"ick",			&dummy_ck),
-	CLK("omap_hsmmc.3",	"ick",			&dummy_ck),
-	CLK("omap_hsmmc.4",	"ick",			&dummy_ck),
-	CLK("omap-mcbsp.1",	"ick",			&dummy_ck),
-	CLK("omap-mcbsp.2",	"ick",			&dummy_ck),
-	CLK("omap-mcbsp.3",	"ick",			&dummy_ck),
-	CLK("omap-mcbsp.4",	"ick",			&dummy_ck),
-	CLK("omap2_mcspi.1",	"ick",			&dummy_ck),
-	CLK("omap2_mcspi.2",	"ick",			&dummy_ck),
-	CLK("omap2_mcspi.3",	"ick",			&dummy_ck),
-	CLK("omap2_mcspi.4",	"ick",			&dummy_ck),
-	CLK(NULL,	"uart1_ick",			&dummy_ck),
-	CLK(NULL,	"uart2_ick",			&dummy_ck),
-	CLK(NULL,	"uart3_ick",			&dummy_ck),
-	CLK(NULL,	"uart4_ick",			&dummy_ck),
-	CLK("usbhs_omap",	"usbhost_ick",		&dummy_ck),
-	CLK("usbhs_omap",	"usbtll_fck",		&dummy_ck),
-	CLK("usbhs_tll",	"usbtll_fck",		&dummy_ck),
-	CLK("omap_wdt",	"ick",				&dummy_ck),
-	CLK(NULL,	"timer_32k_ck",	&sys_32k_ck),
-	/* TODO: Remove "omap_timer.X" aliases once DT migration is complete */
-	CLK("omap_timer.1",	"timer_sys_ck",	&sys_clkin_ck),
-	CLK("omap_timer.2",	"timer_sys_ck",	&sys_clkin_ck),
-	CLK("omap_timer.3",	"timer_sys_ck",	&sys_clkin_ck),
-	CLK("omap_timer.4",	"timer_sys_ck",	&sys_clkin_ck),
-	CLK("omap_timer.9",	"timer_sys_ck",	&sys_clkin_ck),
-	CLK("omap_timer.10",	"timer_sys_ck",	&sys_clkin_ck),
-	CLK("omap_timer.11",	"timer_sys_ck",	&sys_clkin_ck),
-	CLK("omap_timer.5",	"timer_sys_ck",	&syc_clk_div_ck),
-	CLK("omap_timer.6",	"timer_sys_ck",	&syc_clk_div_ck),
-	CLK("omap_timer.7",	"timer_sys_ck",	&syc_clk_div_ck),
-	CLK("omap_timer.8",	"timer_sys_ck",	&syc_clk_div_ck),
-	CLK("4a318000.timer",	"timer_sys_ck",	&sys_clkin_ck),
-	CLK("48032000.timer",	"timer_sys_ck",	&sys_clkin_ck),
-	CLK("48034000.timer",	"timer_sys_ck",	&sys_clkin_ck),
-	CLK("48036000.timer",	"timer_sys_ck",	&sys_clkin_ck),
-	CLK("4803e000.timer",	"timer_sys_ck",	&sys_clkin_ck),
-	CLK("48086000.timer",	"timer_sys_ck",	&sys_clkin_ck),
-	CLK("48088000.timer",	"timer_sys_ck",	&sys_clkin_ck),
-	CLK("40138000.timer",	"timer_sys_ck",	&syc_clk_div_ck),
-	CLK("4013a000.timer",	"timer_sys_ck",	&syc_clk_div_ck),
-	CLK("4013c000.timer",	"timer_sys_ck",	&syc_clk_div_ck),
-	CLK("4013e000.timer",	"timer_sys_ck",	&syc_clk_div_ck),
-	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck),
-};
-
-int __init omap4xxx_clk_init(void)
-{
-	int rc;
-
-	if (cpu_is_omap443x()) {
-		cpu_mask = RATE_IN_4430;
-		omap_clocks_register(omap443x_clks, ARRAY_SIZE(omap443x_clks));
-	} else if (cpu_is_omap446x() || cpu_is_omap447x()) {
-		cpu_mask = RATE_IN_4460 | RATE_IN_4430;
-		omap_clocks_register(omap446x_clks, ARRAY_SIZE(omap446x_clks));
-		if (cpu_is_omap447x())
-			pr_warn("WARNING: OMAP4470 clock data incomplete!\n");
-	} else {
-		return 0;
-	}
-
-	omap_clocks_register(omap44xx_clks, ARRAY_SIZE(omap44xx_clks));
-
-	omap2_clk_disable_autoidle_all();
-
-	/*
-	 * On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
-	 * state when turning the ABE clock domain. Workaround this by
-	 * locking the ABE DPLL on boot.
-	 * Lock the ABE DPLL in any case to avoid issues with audio.
-	 */
-	rc = clk_set_parent(&abe_dpll_refclk_mux_ck, &sys_32k_ck);
-	if (!rc)
-		rc = clk_set_rate(&dpll_abe_ck, OMAP4_DPLL_ABE_DEFFREQ);
-	if (rc)
-		pr_err("%s: failed to configure ABE DPLL!\n", __func__);
-
-	/*
-	 * Lock USB DPLL on OMAP4 devices so that the L3INIT power
-	 * domain can transition to retention state when not in use.
-	 */
-	rc = clk_set_rate(&dpll_usb_ck, OMAP4_DPLL_USB_DEFFREQ);
-	if (rc)
-		pr_err("%s: failed to configure USB DPLL!\n", __func__);
-
-	return 0;
-}
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 3d3ca30f..9ad10be 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1,2 @@
-obj-y					+= clk.o dpll.o autoidle.o gate.o
+obj-y					+= clk.o dpll.o autoidle.o gate.o \
+					   clk-44xx.o
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:21 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:21 +0300
Subject: [PATCHv4 26/33] CLK: omap: gate: add support for OMAP36xx
 dpllx_mx_ck:s
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-27-git-send-email-t-kristo@ti.com>

OMAP3630 dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck,
dpll4_m5_ck & dpll4_m6_ck dividers gets loaded with reset
value after their respective PWRDN bits are set.  Any dummy write
(Any other value different from the Read value) to the
corresponding CM_CLKSEL register will refresh the dividers.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 drivers/clk/omap/gate.c |   57 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 56 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
index b560ff4..50c7f2e 100644
--- a/drivers/clk/omap/gate.c
+++ b/drivers/clk/omap/gate.c
@@ -28,6 +28,10 @@
 
 #ifdef CONFIG_OF
 
+#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
+
+static int omap36xx_gate_clk_enable_with_hsdiv_restore(struct clk_hw *clk);
+
 static const struct clk_ops omap_gate_clkdm_clk_ops = {
 	.init		= &omap2_init_clk_clkdm,
 	.enable		= &omap2_clkops_enable_clkdm,
@@ -41,6 +45,54 @@ static const struct clk_ops omap_gate_clk_ops = {
 	.is_enabled	= &omap2_dflt_clk_is_enabled,
 };
 
+static const struct clk_ops omap_gate_clk_hsdiv_restore_ops = {
+	.init		= &omap2_init_clk_clkdm,
+	.enable		= &omap36xx_gate_clk_enable_with_hsdiv_restore,
+	.disable	= &omap2_dflt_clk_disable,
+	.is_enabled	= &omap2_dflt_clk_is_enabled,
+};
+
+/**
+ * omap36xx_gate_clk_enable_with_hsdiv_restore - enable clocks suffering
+ *         from HSDivider PWRDN problem Implements Errata ID: i556.
+ * @clk: DPLL output struct clk
+ *
+ * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck,
+ * dpll4_m5_ck & dpll4_m6_ck dividers gets loaded with reset
+ * valueafter their respective PWRDN bits are set.  Any dummy write
+ * (Any other value different from the Read value) to the
+ * corresponding CM_CLKSEL register will refresh the dividers.
+ */
+static int omap36xx_gate_clk_enable_with_hsdiv_restore(struct clk_hw *clk)
+{
+	struct clk_divider *parent;
+	struct clk_hw *parent_hw;
+	u32 dummy_v, orig_v;
+	int ret;
+
+	/* Clear PWRDN bit of HSDIVIDER */
+	ret = omap2_dflt_clk_enable(clk);
+
+	/* Parent is the x2 node, get parent of parent for the m2 div */
+	parent_hw = __clk_get_hw(__clk_get_parent(__clk_get_parent(clk->clk)));
+	parent = to_clk_divider(parent_hw);
+
+	/* Restore the dividers */
+	if (!ret) {
+		orig_v = __raw_readl(parent->reg);
+		dummy_v = orig_v;
+
+		/* Write any other value different from the Read value */
+		dummy_v ^= (1 << parent->shift);
+		__raw_writel(dummy_v, parent->reg);
+
+		/* Write the original divider */
+		__raw_writel(orig_v, parent->reg);
+	}
+
+	return ret;
+}
+
 void __init of_omap_gate_clk_setup(struct device_node *node)
 {
 	struct clk *clk;
@@ -70,7 +122,10 @@ void __init of_omap_gate_clk_setup(struct device_node *node)
 		/* No register, clkdm control only */
 		init.ops = &omap_gate_clkdm_clk_ops;
 	} else {
-		init.ops = &omap_gate_clk_ops;
+		if (of_property_read_bool(node, "ti,hsdiv-restore"))
+			init.ops = &omap_gate_clk_hsdiv_restore_ops;
+		else
+			init.ops = &omap_gate_clk_ops;
 		clk_hw->enable_reg = of_iomap(node, 0);
 		of_property_read_u32(node, "ti,enable-bit", &val);
 		clk_hw->enable_bit = val;
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:18 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:18 +0300
Subject: [PATCHv4 23/33] CLK: OMAP: add interface clock support for OMAP3
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-24-git-send-email-t-kristo@ti.com>

OMAP3 has interface clocks in addition to functional clocks, which
require special handling for the autoidle and idle status register
offsets mainly.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 drivers/clk/omap/Makefile    |    2 +-
 drivers/clk/omap/clk.c       |    3 ++
 drivers/clk/omap/interface.c |  110 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 114 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/omap/interface.c

diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index c4e8825..faaeb62 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1,3 +1,3 @@
 obj-y					+= clk.o dpll.o autoidle.o gate.o \
 					   clk-44xx.o clk-54xx.o clk-7xx.o \
-					   clk-33xx.o
+					   clk-33xx.o interface.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index 8c89714..5cbefde 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -30,6 +30,9 @@ static const struct of_device_id clk_match[] = {
 	{.compatible = "gate-clock", .data = of_gate_clk_setup, },
 	{.compatible = "ti,omap4-dpll-clock", .data = of_omap4_dpll_setup, },
 	{.compatible = "ti,gate-clock", .data = of_omap_gate_clk_setup, },
+	{.compatible = "ti,interface-clock",
+		.data = of_omap_interface_clk_setup, },
+	{.compatible = "ti,omap3-dpll-clock", .data = of_omap3_dpll_setup, },
 	{},
 };
 
diff --git a/drivers/clk/omap/interface.c b/drivers/clk/omap/interface.c
new file mode 100644
index 0000000..f1f1a1a
--- /dev/null
+++ b/drivers/clk/omap/interface.c
@@ -0,0 +1,110 @@
+/*
+ * OMAP interface clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo <t-kristo at ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/string.h>
+#include <linux/log2.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/clk/omap.h>
+
+#ifdef CONFIG_OF
+
+static const struct clk_ops omap_interface_clk_ops = {
+	.init		= &omap2_init_clk_clkdm,
+	.enable		= &omap2_dflt_clk_enable,
+	.disable	= &omap2_dflt_clk_disable,
+	.is_enabled	= &omap2_dflt_clk_is_enabled,
+};
+
+void __init of_omap_interface_clk_setup(struct device_node *node)
+{
+	struct clk *clk;
+	struct clk_init_data init;
+	struct clk_hw_omap *clk_hw;
+	const char *clk_name = node->name;
+	int num_parents;
+	const char **parent_names;
+	int i;
+	u32 val;
+
+	clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+	if (!clk_hw) {
+		pr_err("%s: could not allocate clk_hw_omap\n", __func__);
+		return;
+	}
+
+	clk_hw->hw.init = &init;
+	clk_hw->ops = &clkhwops_iclk_wait;
+	clk_hw->enable_reg = of_iomap(node, 0);
+
+	if (!of_property_read_u32(node, "ti,enable-bit", &val))
+		clk_hw->enable_bit = val;
+
+	if (of_property_read_bool(node, "ti,iclk-no-wait"))
+		clk_hw->ops = &clkhwops_iclk;
+
+	if (of_property_read_bool(node, "ti,iclk-hsotgusb"))
+		clk_hw->ops = &clkhwops_omap3430es2_iclk_hsotgusb_wait;
+
+	if (of_property_read_bool(node, "ti,iclk-dss"))
+		clk_hw->ops = &clkhwops_omap3430es2_iclk_dss_usbhost_wait;
+
+	if (of_property_read_bool(node, "ti,iclk-ssi"))
+		clk_hw->ops = &clkhwops_omap3430es2_iclk_ssi_wait;
+
+	of_property_read_string(node, "clock-output-names", &clk_name);
+	of_property_read_string(node, "ti,clkdm-name", &clk_hw->clkdm_name);
+
+	init.name = clk_name;
+	init.ops = &omap_interface_clk_ops;
+	init.flags = 0;
+
+	num_parents = of_clk_get_parent_count(node);
+	if (num_parents < 1) {
+		pr_err("%s: omap interface_clk %s must have parent(s)\n",
+			__func__, node->name);
+		goto cleanup;
+	}
+
+	parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
+
+	for (i = 0; i < num_parents; i++)
+		parent_names[i] = of_clk_get_parent_name(node, i);
+
+	init.num_parents = num_parents;
+	init.parent_names = parent_names;
+
+	clk = clk_register(NULL, &clk_hw->hw);
+
+	if (!IS_ERR(clk)) {
+		of_clk_add_provider(node, of_clk_src_simple_get, clk);
+		omap2_init_clk_hw_omap_clocks(clk);
+		return;
+	}
+
+cleanup:
+	kfree(clk_hw);
+}
+EXPORT_SYMBOL(of_omap_interface_clk_setup);
+CLK_OF_DECLARE(omap_interface_clk, "ti,omap-interface-clock",
+		of_omap_interface_clk_setup);
+#endif
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:19 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:19 +0300
Subject: [PATCHv4 24/33] CLK: OMAP: move some defines from machine to driver
 header
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-25-git-send-email-t-kristo@ti.com>

This is done in preparation for adding support for OMAP3 clocks.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 arch/arm/mach-omap2/clock.h |   10 ----------
 include/linux/clk/omap.h    |   16 ++++++++++++++++
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 6273f14..949d293 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -257,9 +257,6 @@ extern void omap2_clkt_iclk_deny_idle(struct clk_hw_omap *clk);
 
 unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk);
 
-int omap2_dflt_clk_enable(struct clk_hw *hw);
-void omap2_dflt_clk_disable(struct clk_hw *hw);
-int omap2_dflt_clk_is_enabled(struct clk_hw *hw);
 void omap2_clk_dflt_find_companion(struct clk_hw_omap *clk,
 				   void __iomem **other_reg,
 				   u8 *other_bit);
@@ -286,14 +283,7 @@ extern const struct clksel_rate gfx_l3_rates[];
 extern const struct clksel_rate dsp_ick_rates[];
 extern struct clk dummy_ck;
 
-extern const struct clk_hw_omap_ops clkhwops_iclk_wait;
-extern const struct clk_hw_omap_ops clkhwops_wait;
-extern const struct clk_hw_omap_ops clkhwops_iclk;
 extern const struct clk_hw_omap_ops clkhwops_omap3430es2_ssi_wait;
-extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_ssi_wait;
-extern const struct clk_hw_omap_ops clkhwops_omap3430es2_dss_usbhost_wait;
-extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_dss_usbhost_wait;
-extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_hsotgusb_wait;
 extern const struct clk_hw_omap_ops clkhwops_omap3430es2_hsotgusb_wait;
 extern const struct clk_hw_omap_ops clkhwops_am35xx_ipss_module_wait;
 extern const struct clk_hw_omap_ops clkhwops_am35xx_ipss_wait;
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
index c8d9468..24bdd83 100644
--- a/include/linux/clk/omap.h
+++ b/include/linux/clk/omap.h
@@ -183,19 +183,35 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
 int omap2_clkops_enable_clkdm(struct clk_hw *hw);
 void omap2_clkops_disable_clkdm(struct clk_hw *hw);
 
+int omap2_dflt_clk_enable(struct clk_hw *hw);
+void omap2_dflt_clk_disable(struct clk_hw *hw);
+int omap2_dflt_clk_is_enabled(struct clk_hw *hw);
+
+int omap3_dpll4_set_rate(struct clk_hw *clk, unsigned long rate,
+			 unsigned long parent_rate);
+
 int omap2_clk_disable_autoidle_all(void);
 void omap2_clk_enable_init_clocks(const char **clk_names, u8 num_clocks);
 
 extern const struct clk_hw_omap_ops clkhwops_omap3_dpll;
 extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx;
+extern const struct clk_hw_omap_ops clkhwops_omap3430es2_dss_usbhost_wait;
+extern const struct clk_hw_omap_ops clkhwops_wait;
+extern const struct clk_hw_omap_ops clkhwops_iclk_wait;
+extern const struct clk_hw_omap_ops clkhwops_iclk;
+extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_ssi_wait;
+extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_dss_usbhost_wait;
+extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_hsotgusb_wait;
 
 /* DT functions */
 int dt_omap_clk_init(void);
 extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int cnt);
 void of_omap4_dpll_setup(struct device_node *node);
+void of_omap3_dpll_setup(struct device_node *node);
 void of_omap_fixed_factor_setup(struct device_node *node);
 void of_omap_divider_setup(struct device_node *node);
 void of_omap_gate_clk_setup(struct device_node *node);
+void of_omap_interface_clk_setup(struct device_node *node);
 void of_omap_clk_allow_autoidle_all(void);
 void of_omap_clk_deny_autoidle_all(void);
 
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:20 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:20 +0300
Subject: [PATCHv4 25/33] ARM: OMAP: hwmod: fix an incorrect clk type cast with
 _get_clkdm
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-26-git-send-email-t-kristo@ti.com>

If the main clock for a hwmod is of basic clock type, it is illegal to type
cast this to clk_hw_omap and will result in bogus data. Fixed by checking
the clock flags before attempting the type cast.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5cc5123..a6a59bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -656,6 +656,8 @@ static struct clockdomain *_get_clkdm(struct omap_hwmod *oh)
 	if (oh->clkdm) {
 		return oh->clkdm;
 	} else if (oh->_clk) {
+		if (__clk_get_flags(oh->_clk) & CLK_IS_BASIC)
+			return NULL;
 		clk = to_clk_hw_omap(__clk_get_hw(oh->_clk));
 		return  clk->clkdm;
 	}
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:22 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:22 +0300
Subject: [PATCHv4 27/33] ARM: OMAP3: hwmod: initialize clkdm from clkdm_name
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-28-git-send-email-t-kristo@ti.com>

DT clocks are mostly missing clkdm info now, and this causes an issue with
counter32k which makes its slave idlemode wrong and prevents core idle.

Fixed by initializing the hwmod clkdm pointers for omap3 also which makes
sure the clkdm flag matching logic works properly.

This patch also changes the return value for _init_clkdm to 0 for
incorrect clkdm_name, as this a warning, not a fatal error.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index a6a59bd..da26659 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1544,7 +1544,7 @@ static int _init_clkdm(struct omap_hwmod *oh)
 	if (!oh->clkdm) {
 		pr_warning("omap_hwmod: %s: could not associate to clkdm %s\n",
 			oh->name, oh->clkdm_name);
-		return -EINVAL;
+		return 0;
 	}
 
 	pr_debug("omap_hwmod: %s: associated to clkdm %s\n",
@@ -4115,6 +4115,7 @@ void __init omap_hwmod_init(void)
 		soc_ops.assert_hardreset = _omap2_assert_hardreset;
 		soc_ops.deassert_hardreset = _omap2_deassert_hardreset;
 		soc_ops.is_hardreset_asserted = _omap2_is_hardreset_asserted;
+		soc_ops.init_clkdm = _init_clkdm;
 	} else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
 		soc_ops.enable_module = _omap4_enable_module;
 		soc_ops.disable_module = _omap4_disable_module;
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:08 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:08 +0300
Subject: [PATCHv4 13/33] ARM: dts: dra7 clock data
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-14-git-send-email-t-kristo@ti.com>

This patch creates a unique node for each clock in the DRA7 power,
reset and clock manager (PRCM).

TODO: apll_pcie clock node is still a dummy in this version, and
proper support for the APLL should be added.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 arch/arm/boot/dts/dra7xx-clocks.dtsi | 2081 ++++++++++++++++++++++++++++++++++
 1 file changed, 2081 insertions(+)
 create mode 100644 arch/arm/boot/dts/dra7xx-clocks.dtsi

diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi
new file mode 100644
index 0000000..8477ff9
--- /dev/null
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -0,0 +1,2081 @@
+/*
+ * Device Tree Source for DRA7xx clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+atl_clkin0_ck: atl_clkin0_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+atl_clkin1_ck: atl_clkin1_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+atl_clkin2_ck: atl_clkin2_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+atlclkin3_ck: atlclkin3_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+hdmi_clkin_ck: hdmi_clkin_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+mlb_clkin_ck: mlb_clkin_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+mlbp_clkin_ck: mlbp_clkin_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+pciesref_acs_clk_ck: pciesref_acs_clk_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <100000000>;
+};
+
+ref_clkin0_ck: ref_clkin0_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+ref_clkin1_ck: ref_clkin1_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+ref_clkin2_ck: ref_clkin2_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+ref_clkin3_ck: ref_clkin3_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+rmii_clk_ck: rmii_clk_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+sdvenc_clkin_ck: sdvenc_clkin_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+secure_32k_clk_src_ck: secure_32k_clk_src_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <32768>;
+};
+
+sys_32k_ck: sys_32k_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <32768>;
+};
+
+virt_12000000_ck: virt_12000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <12000000>;
+};
+
+virt_13000000_ck: virt_13000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <13000000>;
+};
+
+virt_16800000_ck: virt_16800000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <16800000>;
+};
+
+virt_19200000_ck: virt_19200000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <19200000>;
+};
+
+virt_20000000_ck: virt_20000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <20000000>;
+};
+
+virt_26000000_ck: virt_26000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <26000000>;
+};
+
+virt_27000000_ck: virt_27000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <27000000>;
+};
+
+virt_38400000_ck: virt_38400000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <38400000>;
+};
+
+sys_clkin1: sys_clkin1 at 4ae06110 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&virt_12000000_ck>, <&virt_20000000_ck>, <&virt_16800000_ck>, <&virt_19200000_ck>, <&virt_26000000_ck>, <&virt_27000000_ck>, <&virt_38400000_ck>;
+	reg = <0x4ae06110 0x4>;
+	bit-mask = <0x7>;
+	index-starts-at-one;
+};
+
+sys_clkin2: sys_clkin2 {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <22579200>;
+};
+
+usb_otg_clkin_ck: usb_otg_clkin_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+video1_clkin_ck: video1_clkin_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+video1_m2_clkin_ck: video1_m2_clkin_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+video2_clkin_ck: video2_clkin_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+video2_m2_clkin_ck: video2_m2_clkin_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0>;
+};
+
+abe_dpll_sys_clk_mux: abe_dpll_sys_clk_mux at 4ae06118 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin1>, <&sys_clkin2>;
+	reg = <0x4ae06118 0x4>;
+	bit-mask = <0x1>;
+};
+
+abe_dpll_bypass_clk_mux: abe_dpll_bypass_clk_mux at 4ae06114 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_dpll_sys_clk_mux>, <&sys_32k_ck>;
+	reg = <0x4ae06114 0x4>;
+	bit-mask = <0x1>;
+};
+
+abe_dpll_clk_mux: abe_dpll_clk_mux at 4ae0610c {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_dpll_sys_clk_mux>, <&sys_32k_ck>;
+	reg = <0x4ae0610c 0x4>;
+	bit-mask = <0x1>;
+};
+
+dpll_abe_ck: dpll_abe_ck at 4a0051e0 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&abe_dpll_clk_mux>, <&abe_dpll_bypass_clk_mux>;
+	reg = <0x4a0051e0 0x4>, <0x4a0051e4 0x4>, <0x4a0051e8 0x4>, <0x4a0051ec 0x4>;
+	ti,clk-ref = <&abe_dpll_clk_mux>;
+	ti,clk-bypass = <&abe_dpll_bypass_clk_mux>;
+	ti,dpll-regm4xen;
+};
+
+dpll_abe_x2_ck: dpll_abe_x2_ck {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_abe_ck>;
+	ti,dpll-clk-x2;
+};
+
+dpll_abe_m2x2_ck: dpll_abe_m2x2_ck at 4a0051f0 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0051f0 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+abe_24m_fclk: abe_24m_fclk at 4ae0611c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_m2x2_ck>;
+	reg = <0x4ae0611c 0x4>;
+	table = < 8 0 >, < 16 1 >;
+	bit-mask = <0x1>;
+};
+
+abe_clk: abe_clk at 4a005108 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_m2x2_ck>;
+	reg = <0x4a005108 0x4>;
+	bit-mask = <0x3>;
+	index-power-of-two;
+};
+
+aess_fclk: aess_fclk at 4ae06178 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&abe_clk>;
+	reg = <0x4ae06178 0x4>;
+	bit-mask = <0x1>;
+};
+
+abe_giclk_div: abe_giclk_div at 4ae06174 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&aess_fclk>;
+	reg = <0x4ae06174 0x4>;
+	bit-mask = <0x1>;
+};
+
+abe_lp_clk_div: abe_lp_clk_div at 4ae061d8 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_m2x2_ck>;
+	reg = <0x4ae061d8 0x4>;
+	table = < 16 0 >, < 32 1 >;
+	bit-mask = <0x1>;
+};
+
+abe_sys_clk_div: abe_sys_clk_div at 4ae06120 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&sys_clkin1>;
+	reg = <0x4ae06120 0x4>;
+	bit-mask = <0x1>;
+};
+
+adc_gfclk_mux: adc_gfclk_mux at 4ae061dc {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin1>, <&sys_clkin2>, <&sys_32k_ck>;
+	reg = <0x4ae061dc 0x4>;
+	bit-mask = <0x7>;
+};
+
+dpll_pcie_ref_ck: dpll_pcie_ref_ck at 4a008200 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin1>;
+	reg = <0x4a008200 0x4>, <0x4a008204 0x4>, <0x4a008208 0x4>, <0x4a00820c 0x4>;
+	ti,clk-ref = <&sys_clkin1>;
+	ti,clk-bypass = <&sys_clkin1>;
+};
+
+dpll_pcie_ref_m2ldo_ck: dpll_pcie_ref_m2ldo_ck at 4a008210 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_pcie_ref_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008210 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+apll_pcie_ck: apll_pcie_ck at 4a008200 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_pcie_ref_ck>;
+	reg = <0x4a008200 0x4>, <0x4a008204 0x4>, <0x4a008208 0x4>, <0x4a00820c 0x4>;
+	ti,clk-ref = <&dpll_pcie_ref_ck>;
+	ti,clk-bypass = <&dpll_pcie_ref_ck>;
+};
+
+apll_pcie_clkvcoldo: apll_pcie_clkvcoldo {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&apll_pcie_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+apll_pcie_clkvcoldo_div: apll_pcie_clkvcoldo_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&apll_pcie_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+apll_pcie_m2_ck: apll_pcie_m2_ck at 4a008224 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&apll_pcie_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008224 0x4>;
+	bit-mask = <0x7f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+sys_clk1_dclk_div: sys_clk1_dclk_div at 4ae061c8 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&sys_clkin1>;
+	reg = <0x4ae061c8 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+sys_clk2_dclk_div: sys_clk2_dclk_div at 4ae061cc {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&sys_clkin2>;
+	reg = <0x4ae061cc 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+dpll_abe_m2_ck: dpll_abe_m2_ck at 4a0051f0 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0051f0 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+per_abe_x1_dclk_div: per_abe_x1_dclk_div at 4ae061bc {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_m2_ck>;
+	reg = <0x4ae061bc 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+dpll_abe_m3x2_ck: dpll_abe_m3x2_ck at 4a0051f4 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0051f4 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_core_ck: dpll_core_ck at 4a005120 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin1>, <&dpll_abe_m3x2_ck>;
+	reg = <0x4a005120 0x4>, <0x4a005124 0x4>, <0x4a005128 0x4>, <0x4a00512c 0x4>;
+	ti,clk-ref = <&sys_clkin1>;
+	ti,clk-bypass = <&dpll_abe_m3x2_ck>;
+	ti,dpll-core;
+};
+
+dpll_core_x2_ck: dpll_core_x2_ck {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_core_ck>;
+	ti,dpll-clk-x2;
+};
+
+dpll_core_h12x2_ck: dpll_core_h12x2_ck at 4a00513c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a00513c 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+mpu_dpll_hs_clk_div: mpu_dpll_hs_clk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_h12x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll_mpu_ck: dpll_mpu_ck at 4a005160 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin1>, <&mpu_dpll_hs_clk_div>;
+	reg = <0x4a005160 0x4>, <0x4a005164 0x4>, <0x4a005168 0x4>, <0x4a00516c 0x4>;
+	ti,clk-ref = <&sys_clkin1>;
+	ti,clk-bypass = <&mpu_dpll_hs_clk_div>;
+};
+
+dpll_mpu_m2_ck: dpll_mpu_m2_ck at 4a005170 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_mpu_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a005170 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+mpu_dclk_div: mpu_dclk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_mpu_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dsp_dpll_hs_clk_div: dsp_dpll_hs_clk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_h12x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll_dsp_ck: dpll_dsp_ck at 4a005234 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin1>, <&dsp_dpll_hs_clk_div>;
+	reg = <0x4a005234 0x4>, <0x4a005238 0x4>, <0x4a00523c 0x4>, <0x4a005240 0x4>;
+	ti,clk-ref = <&sys_clkin1>;
+	ti,clk-bypass = <&dsp_dpll_hs_clk_div>;
+};
+
+dpll_dsp_m2_ck: dpll_dsp_m2_ck at 4a005244 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_dsp_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a005244 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dsp_gclk_div: dsp_gclk_div at 4ae0618c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_dsp_m2_ck>;
+	reg = <0x4ae0618c 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+iva_dpll_hs_clk_div: iva_dpll_hs_clk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_h12x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll_iva_ck: dpll_iva_ck at 4a0051a0 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin1>, <&iva_dpll_hs_clk_div>;
+	reg = <0x4a0051a0 0x4>, <0x4a0051a4 0x4>, <0x4a0051a8 0x4>, <0x4a0051ac 0x4>;
+	ti,clk-ref = <&sys_clkin1>;
+	ti,clk-bypass = <&iva_dpll_hs_clk_div>;
+};
+
+dpll_iva_m2_ck: dpll_iva_m2_ck at 4a0051b0 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_iva_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0051b0 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+iva_dclk: iva_dclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_iva_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll_gpu_ck: dpll_gpu_ck at 4a0052d8 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin1>, <&dpll_abe_m3x2_ck>;
+	reg = <0x4a0052d8 0x4>, <0x4a0052dc 0x4>, <0x4a0052e0 0x4>, <0x4a0052e4 0x4>;
+	ti,clk-ref = <&sys_clkin1>;
+	ti,clk-bypass = <&dpll_abe_m3x2_ck>;
+};
+
+dpll_gpu_m2_ck: dpll_gpu_m2_ck at 4a0052e8 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_gpu_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0052e8 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+gpu_dclk: gpu_dclk at 4ae061a0 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_gpu_m2_ck>;
+	reg = <0x4ae061a0 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+dpll_core_m2_ck: dpll_core_m2_ck at 4a005130 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a005130 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+core_dpll_out_dclk_div: core_dpll_out_dclk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll_ddr_ck: dpll_ddr_ck at 4a005210 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin1>, <&dpll_abe_m3x2_ck>;
+	reg = <0x4a005210 0x4>, <0x4a005214 0x4>, <0x4a005218 0x4>, <0x4a00521c 0x4>;
+	ti,clk-ref = <&sys_clkin1>;
+	ti,clk-bypass = <&dpll_abe_m3x2_ck>;
+};
+
+dpll_ddr_m2_ck: dpll_ddr_m2_ck at 4a005220 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_ddr_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a005220 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+emif_phy_dclk_div: emif_phy_dclk_div at 4ae06190 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_ddr_m2_ck>;
+	reg = <0x4ae06190 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+dpll_gmac_ck: dpll_gmac_ck at 4a0052a8 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin1>, <&dpll_abe_m3x2_ck>;
+	reg = <0x4a0052a8 0x4>, <0x4a0052ac 0x4>, <0x4a0052b0 0x4>, <0x4a0052b4 0x4>;
+	ti,clk-ref = <&sys_clkin1>;
+	ti,clk-bypass = <&dpll_abe_m3x2_ck>;
+};
+
+dpll_gmac_m2_ck: dpll_gmac_m2_ck at 4a0052b8 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_gmac_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0052b8 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+gmac_250m_dclk_div: gmac_250m_dclk_div at 4ae0619c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_gmac_m2_ck>;
+	reg = <0x4ae0619c 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+video2_dclk_div: video2_dclk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&video2_m2_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+video1_dclk_div: video1_dclk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&video1_m2_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+hdmi_dclk_div: hdmi_dclk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&hdmi_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+per_dpll_hs_clk_div: per_dpll_hs_clk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_abe_m3x2_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+dpll_per_ck: dpll_per_ck at 4a008140 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin1>, <&per_dpll_hs_clk_div>;
+	reg = <0x4a008140 0x4>, <0x4a008144 0x4>, <0x4a008148 0x4>, <0x4a00814c 0x4>;
+	ti,clk-ref = <&sys_clkin1>;
+	ti,clk-bypass = <&per_dpll_hs_clk_div>;
+};
+
+dpll_per_m2_ck: dpll_per_m2_ck at 4a008150 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008150 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+func_96m_aon_dclk_div: func_96m_aon_dclk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+usb_dpll_hs_clk_div: usb_dpll_hs_clk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_abe_m3x2_ck>;
+	clock-mult = <1>;
+	clock-div = <3>;
+};
+
+dpll_usb_ck: dpll_usb_ck at 4a008180 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin1>, <&usb_dpll_hs_clk_div>;
+	ti,clk-bypass = <&usb_dpll_hs_clk_div>;
+	reg = <0x4a008180 0x4>, <0x4a008184 0x4>, <0x4a008188 0x4>, <0x4a00818c 0x4>;
+	ti,clk-ref = <&sys_clkin1>;
+	ti,clkdm-name = "coreaon_clkdm";
+	ti,dpll-j-type;
+};
+
+dpll_usb_m2_ck: dpll_usb_m2_ck at 4a008190 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_usb_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008190 0x4>;
+	bit-mask = <0x7f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+l3init_480m_dclk_div: l3init_480m_dclk_div at 4ae061ac {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_usb_m2_ck>;
+	reg = <0x4ae061ac 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+usb_otg_dclk_div: usb_otg_dclk_div at 4ae06184 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&usb_otg_clkin_ck>;
+	reg = <0x4ae06184 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+sata_dclk_div: sata_dclk_div at 4ae061c0 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&sys_clkin1>;
+	reg = <0x4ae061c0 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+dpll_pcie_ref_m2_ck: dpll_pcie_ref_m2_ck at 4a008210 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_pcie_ref_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008210 0x4>;
+	bit-mask = <0x7f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+pcie2_dclk_div: pcie2_dclk_div at 4ae061b8 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_pcie_ref_m2_ck>;
+	reg = <0x4ae061b8 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+pcie_dclk_div: pcie_dclk_div at 4ae061b4 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&apll_pcie_m2_ck>;
+	reg = <0x4ae061b4 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+emu_dclk_div: emu_dclk_div at 4ae06194 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&sys_clkin1>;
+	reg = <0x4ae06194 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+secure_32k_dclk_div: secure_32k_dclk_div at 4ae061c4 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&secure_32k_clk_src_ck>;
+	reg = <0x4ae061c4 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+eve_dpll_hs_clk_div: eve_dpll_hs_clk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_h12x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll_eve_ck: dpll_eve_ck at 4a005284 {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&sys_clkin1>, <&eve_dpll_hs_clk_div>;
+	reg = <0x4a005284 0x4>, <0x4a005288 0x4>, <0x4a00528c 0x4>, <0x4a005290 0x4>;
+	ti,clk-ref = <&sys_clkin1>;
+	ti,clk-bypass = <&eve_dpll_hs_clk_div>;
+};
+
+dpll_eve_m2_ck: dpll_eve_m2_ck at 4a005294 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_eve_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a005294 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+eve_dclk_div: eve_dclk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_eve_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+clkoutmux0_clk_mux: clkoutmux0_clk_mux at 4ae06158 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clk1_dclk_div>, <&sys_clk2_dclk_div>, <&per_abe_x1_dclk_div>, <&mpu_dclk_div>, <&dsp_gclk_div>, <&iva_dclk>, <&gpu_dclk>, <&core_dpll_out_dclk_div>, <&emif_phy_dclk_div>, <&gmac_250m_dclk_div>, <&video2_dclk_div>, <&video1_dclk_div>, <&hdmi_dclk_div>, <&func_96m_aon_dclk_div>, <&l3init_480m_dclk_div>, <&usb_otg_dclk_div>, <&sata_dclk_div>, <&pcie2_dclk_div>, <&pcie_dclk_div>, <&emu_dclk_div>, <&secure_32k_dclk_div>, <&eve_dclk_div>;
+	reg = <0x4ae06158 0x4>;
+	bit-mask = <0x1f>;
+};
+
+clkoutmux1_clk_mux: clkoutmux1_clk_mux at 4ae0615c {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clk1_dclk_div>, <&sys_clk2_dclk_div>, <&per_abe_x1_dclk_div>, <&mpu_dclk_div>, <&dsp_gclk_div>, <&iva_dclk>, <&gpu_dclk>, <&core_dpll_out_dclk_div>, <&emif_phy_dclk_div>, <&gmac_250m_dclk_div>, <&video2_dclk_div>, <&video1_dclk_div>, <&hdmi_dclk_div>, <&func_96m_aon_dclk_div>, <&l3init_480m_dclk_div>, <&usb_otg_dclk_div>, <&sata_dclk_div>, <&pcie2_dclk_div>, <&pcie_dclk_div>, <&emu_dclk_div>, <&secure_32k_dclk_div>, <&eve_dclk_div>;
+	reg = <0x4ae0615c 0x4>;
+	bit-mask = <0x1f>;
+};
+
+clkoutmux2_clk_mux: clkoutmux2_clk_mux at 4ae06160 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clk1_dclk_div>, <&sys_clk2_dclk_div>, <&per_abe_x1_dclk_div>, <&mpu_dclk_div>, <&dsp_gclk_div>, <&iva_dclk>, <&gpu_dclk>, <&core_dpll_out_dclk_div>, <&emif_phy_dclk_div>, <&gmac_250m_dclk_div>, <&video2_dclk_div>, <&video1_dclk_div>, <&hdmi_dclk_div>, <&func_96m_aon_dclk_div>, <&l3init_480m_dclk_div>, <&usb_otg_dclk_div>, <&sata_dclk_div>, <&pcie2_dclk_div>, <&pcie_dclk_div>, <&emu_dclk_div>, <&secure_32k_dclk_div>, <&eve_dclk_div>;
+	reg = <0x4ae06160 0x4>;
+	bit-mask = <0x1f>;
+};
+
+custefuse_sys_gfclk_div: custefuse_sys_gfclk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_clkin1>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+dpll_core_h13x2_ck: dpll_core_h13x2_ck at 4a005140 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a005140 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_core_h14x2_ck: dpll_core_h14x2_ck at 4a005144 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a005144 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_core_h22x2_ck: dpll_core_h22x2_ck at 4a005154 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a005154 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_core_h23x2_ck: dpll_core_h23x2_ck at 4a005158 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a005158 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_core_h24x2_ck: dpll_core_h24x2_ck at 4a00515c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_core_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a00515c 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_ddr_x2_ck: dpll_ddr_x2_ck {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_ddr_ck>;
+	ti,dpll-clk-x2;
+};
+
+dpll_ddr_h11x2_ck: dpll_ddr_h11x2_ck at 4a005228 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_ddr_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a005228 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_dsp_x2_ck: dpll_dsp_x2_ck {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_dsp_ck>;
+	ti,dpll-clk-x2;
+};
+
+dpll_dsp_m3x2_ck: dpll_dsp_m3x2_ck at 4a005248 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_dsp_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a005248 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_gmac_x2_ck: dpll_gmac_x2_ck {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_gmac_ck>;
+	ti,dpll-clk-x2;
+};
+
+dpll_gmac_h11x2_ck: dpll_gmac_h11x2_ck at 4a0052c0 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_gmac_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0052c0 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_gmac_h12x2_ck: dpll_gmac_h12x2_ck at 4a0052c4 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_gmac_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0052c4 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_gmac_h13x2_ck: dpll_gmac_h13x2_ck at 4a0052c8 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_gmac_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0052c8 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_gmac_m3x2_ck: dpll_gmac_m3x2_ck at 4a0052bc {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_gmac_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a0052bc 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_per_x2_ck: dpll_per_x2_ck {
+	#clock-cells = <0>;
+	compatible = "ti,omap4-dpll-clock";
+	clocks = <&dpll_per_ck>;
+	ti,dpll-clk-x2;
+};
+
+dpll_per_h11x2_ck: dpll_per_h11x2_ck at 4a008158 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008158 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_per_h12x2_ck: dpll_per_h12x2_ck at 4a00815c {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a00815c 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_per_h13x2_ck: dpll_per_h13x2_ck at 4a008160 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008160 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_per_h14x2_ck: dpll_per_h14x2_ck at 4a008164 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008164 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_per_m2x2_ck: dpll_per_m2x2_ck at 4a008150 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_per_x2_ck>;
+	ti,autoidle-shift = <8>;
+	reg = <0x4a008150 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+	ti,autoidle-low;
+};
+
+dpll_usb_clkdcoldo: dpll_usb_clkdcoldo {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_usb_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+eve_clk: eve_clk at 4ae06180 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dpll_eve_m2_ck>, <&dpll_dsp_m3x2_ck>;
+	reg = <0x4ae06180 0x4>;
+	bit-mask = <0x1>;
+};
+
+func_128m_clk: func_128m_clk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_h11x2_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+func_12m_fclk: func_12m_fclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <16>;
+};
+
+func_24m_clk: func_24m_clk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <4>;
+};
+
+func_48m_fclk: func_48m_fclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <4>;
+};
+
+func_96m_fclk: func_96m_fclk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_per_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+gmii_m_clk_div: gmii_m_clk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_gmac_h11x2_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+hdmi_clk2_div: hdmi_clk2_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&hdmi_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+hdmi_div_clk: hdmi_div_clk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&hdmi_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+hdmi_dpll_clk_mux: hdmi_dpll_clk_mux at 4ae061a4 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin1>, <&sys_clkin2>;
+	reg = <0x4ae061a4 0x4>;
+	bit-mask = <0x7>;
+};
+
+l3_iclk_div: l3_iclk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll_core_h12x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+l3init_60m_fclk: l3init_60m_fclk at 4a008104 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_usb_m2_ck>;
+	reg = <0x4a008104 0x4>;
+	table = < 1 0 >, < 8 1 >;
+	bit-mask = <0x1>;
+};
+
+l4_root_clk_div: l4_root_clk_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&l3_iclk_div>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+mlb_clk: mlb_clk at 4ae06134 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&mlb_clkin_ck>;
+	reg = <0x4ae06134 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+mlbp_clk: mlbp_clk at 4ae06130 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&mlbp_clkin_ck>;
+	reg = <0x4ae06130 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+per_abe_x1_gfclk2_div: per_abe_x1_gfclk2_div at 4ae06138 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_abe_m2_ck>;
+	reg = <0x4ae06138 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+timer_sys_clk_div: timer_sys_clk_div at 4ae06144 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&sys_clkin1>;
+	reg = <0x4ae06144 0x4>;
+	bit-mask = <0x1>;
+};
+
+video1_clk2_div: video1_clk2_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&video1_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+video1_div_clk: video1_div_clk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&video1_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+video1_dpll_clk_mux: video1_dpll_clk_mux at 4ae061d0 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin1>, <&sys_clkin2>;
+	reg = <0x4ae061d0 0x4>;
+	bit-mask = <0x7>;
+};
+
+video2_clk2_div: video2_clk2_div {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&video2_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+video2_div_clk: video2_div_clk {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&video2_clkin_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+video2_dpll_clk_mux: video2_dpll_clk_mux at 4ae061d4 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin1>, <&sys_clkin2>;
+	reg = <0x4ae061d4 0x4>;
+	bit-mask = <0x7>;
+};
+
+wkupaon_iclk_mux: wkupaon_iclk_mux at 4ae06108 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin1>, <&abe_lp_clk_div>;
+	reg = <0x4ae06108 0x4>;
+	bit-mask = <0x1>;
+};
+
+dss_32khz_clk: dss_32khz_clk at 4a009120 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <11>;
+	reg = <0x4a009120 0x4>;
+};
+
+dss_48mhz_clk: dss_48mhz_clk at 4a009120 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&func_48m_fclk>;
+	bit-shift = <9>;
+	reg = <0x4a009120 0x4>;
+};
+
+dss_dss_clk: dss_dss_clk at 4a009120 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_per_h12x2_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009120 0x4>;
+};
+
+dss_hdmi_clk: dss_hdmi_clk at 4a009120 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&hdmi_dpll_clk_mux>;
+	bit-shift = <10>;
+	reg = <0x4a009120 0x4>;
+};
+
+dss_video1_clk: dss_video1_clk at 4a009120 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&video1_dpll_clk_mux>;
+	bit-shift = <12>;
+	reg = <0x4a009120 0x4>;
+};
+
+dss_video2_clk: dss_video2_clk at 4a009120 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&video2_dpll_clk_mux>;
+	bit-shift = <13>;
+	reg = <0x4a009120 0x4>;
+};
+
+gpio1_dbclk: gpio1_dbclk at 4ae07838 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4ae07838 0x4>;
+};
+
+gpio2_dbclk: gpio2_dbclk at 4a009760 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009760 0x4>;
+};
+
+gpio3_dbclk: gpio3_dbclk at 4a009768 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009768 0x4>;
+};
+
+gpio4_dbclk: gpio4_dbclk at 4a009770 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009770 0x4>;
+};
+
+gpio5_dbclk: gpio5_dbclk at 4a009778 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009778 0x4>;
+};
+
+gpio6_dbclk: gpio6_dbclk at 4a009780 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009780 0x4>;
+};
+
+gpio7_dbclk: gpio7_dbclk at 4a009810 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009810 0x4>;
+};
+
+gpio8_dbclk: gpio8_dbclk at 4a009818 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009818 0x4>;
+};
+
+mmc1_clk32k: mmc1_clk32k at 4a009328 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009328 0x4>;
+};
+
+mmc2_clk32k: mmc2_clk32k at 4a009330 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009330 0x4>;
+};
+
+mmc3_clk32k: mmc3_clk32k at 4a009820 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009820 0x4>;
+};
+
+mmc4_clk32k: mmc4_clk32k at 4a009828 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a009828 0x4>;
+};
+
+sata_ref_clk: sata_ref_clk at 4a009388 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_clkin1>;
+	bit-shift = <8>;
+	reg = <0x4a009388 0x4>;
+};
+
+usb_otg_ss1_refclk960m: usb_otg_ss1_refclk960m at 4a0093f0 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_usb_clkdcoldo>;
+	bit-shift = <8>;
+	reg = <0x4a0093f0 0x4>;
+};
+
+usb_otg_ss2_refclk960m: usb_otg_ss2_refclk960m at 4a009340 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll_usb_clkdcoldo>;
+	bit-shift = <8>;
+	reg = <0x4a009340 0x4>;
+};
+
+usb_phy1_always_on_clk32k: usb_phy1_always_on_clk32k at 4a008640 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a008640 0x4>;
+};
+
+usb_phy2_always_on_clk32k: usb_phy2_always_on_clk32k at 4a008688 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a008688 0x4>;
+};
+
+usb_phy3_always_on_clk32k: usb_phy3_always_on_clk32k at 4a008698 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_32k_ck>;
+	bit-shift = <8>;
+	reg = <0x4a008698 0x4>;
+};
+
+atl_dpll_clk_mux: atl_dpll_clk_mux at 4a008c00 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_32k_ck>, <&video1_clkin_ck>, <&video2_clkin_ck>, <&hdmi_clkin_ck>;
+	bit-shift = <24>;
+	reg = <0x4a008c00 0x4>;
+	bit-mask = <0x3>;
+};
+
+atl_gfclk_mux: atl_gfclk_mux at 4a008c00 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&l3_iclk_div>, <&dpll_abe_m2_ck>, <&atl_dpll_clk_mux>;
+	bit-shift = <26>;
+	reg = <0x4a008c00 0x4>;
+	bit-mask = <0x3>;
+};
+
+dcan1_sys_clk_mux: dcan1_sys_clk_mux at 4ae07888 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_clkin1>, <&sys_clkin2>;
+	bit-shift = <24>;
+	reg = <0x4ae07888 0x4>;
+	bit-mask = <0x1>;
+};
+
+gmac_gmii_ref_clk_div: gmac_gmii_ref_clk_div at 4a0093d0 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll_gmac_m2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a0093d0 0x4>;
+	table = < 2 0 >;
+	bit-mask = <0x1>;
+};
+
+gmac_rft_clk_mux: gmac_rft_clk_mux at 4a0093d0 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&video1_clkin_ck>, <&video2_clkin_ck>, <&dpll_abe_m2_ck>, <&hdmi_clkin_ck>, <&l3_iclk_div>;
+	bit-shift = <25>;
+	reg = <0x4a0093d0 0x4>;
+	bit-mask = <0x7>;
+};
+
+gpu_core_gclk_mux: gpu_core_gclk_mux at 4a009220 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dpll_core_h14x2_ck>, <&dpll_per_h14x2_ck>, <&dpll_gpu_m2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009220 0x4>;
+	bit-mask = <0x3>;
+};
+
+gpu_hyd_gclk_mux: gpu_hyd_gclk_mux at 4a009220 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dpll_core_h14x2_ck>, <&dpll_per_h14x2_ck>, <&dpll_gpu_m2_ck>;
+	bit-shift = <26>;
+	reg = <0x4a009220 0x4>;
+	bit-mask = <0x3>;
+};
+
+ipu1_gfclk_mux: ipu1_gfclk_mux at 4a005520 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dpll_abe_m2x2_ck>, <&dpll_core_h22x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a005520 0x4>;
+	bit-mask = <0x1>;
+};
+
+l3instr_ts_gclk_div: l3instr_ts_gclk_div at 4a008e50 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&wkupaon_iclk_mux>;
+	bit-shift = <24>;
+	reg = <0x4a008e50 0x4>;
+	table = < 8 0 >, < 16 1 >, < 32 2 >;
+	bit-mask = <0x3>;
+};
+
+mcasp1_ahclkr_mux: mcasp1_ahclkr_mux at 4a005550 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>, <&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+	bit-shift = <28>;
+	reg = <0x4a005550 0x4>;
+	bit-mask = <0xf>;
+};
+
+mcasp1_ahclkx_mux: mcasp1_ahclkx_mux at 4a005550 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>, <&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+	bit-shift = <24>;
+	reg = <0x4a005550 0x4>;
+	bit-mask = <0xf>;
+};
+
+mcasp1_aux_gfclk_mux: mcasp1_aux_gfclk_mux at 4a005550 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&per_abe_x1_gfclk2_div>, <&video1_clk2_div>, <&video2_clk2_div>, <&hdmi_clk2_div>;
+	bit-shift = <22>;
+	reg = <0x4a005550 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcasp2_ahclkr_mux: mcasp2_ahclkr_mux at 4a009860 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>, <&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+	bit-shift = <28>;
+	reg = <0x4a009860 0x4>;
+	bit-mask = <0xf>;
+};
+
+mcasp2_ahclkx_mux: mcasp2_ahclkx_mux at 4a009860 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>, <&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+	bit-shift = <28>;
+	reg = <0x4a009860 0x4>;
+	bit-mask = <0xf>;
+};
+
+mcasp2_aux_gfclk_mux: mcasp2_aux_gfclk_mux at 4a009860 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&per_abe_x1_gfclk2_div>, <&video1_clk2_div>, <&video2_clk2_div>, <&hdmi_clk2_div>;
+	bit-shift = <22>;
+	reg = <0x4a009860 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcasp3_ahclkx_mux: mcasp3_ahclkx_mux at 4a009868 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>, <&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+	bit-shift = <24>;
+	reg = <0x4a009868 0x4>;
+	bit-mask = <0xf>;
+};
+
+mcasp3_aux_gfclk_mux: mcasp3_aux_gfclk_mux at 4a009868 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&per_abe_x1_gfclk2_div>, <&video1_clk2_div>, <&video2_clk2_div>, <&hdmi_clk2_div>;
+	bit-shift = <22>;
+	reg = <0x4a009868 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcasp4_ahclkx_mux: mcasp4_ahclkx_mux at 4a009898 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>, <&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+	bit-shift = <24>;
+	reg = <0x4a009898 0x4>;
+	bit-mask = <0xf>;
+};
+
+mcasp4_aux_gfclk_mux: mcasp4_aux_gfclk_mux at 4a009898 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&per_abe_x1_gfclk2_div>, <&video1_clk2_div>, <&video2_clk2_div>, <&hdmi_clk2_div>;
+	bit-shift = <22>;
+	reg = <0x4a009898 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcasp5_ahclkx_mux: mcasp5_ahclkx_mux at 4a009878 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>, <&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+	bit-shift = <24>;
+	reg = <0x4a009878 0x4>;
+	bit-mask = <0xf>;
+};
+
+mcasp5_aux_gfclk_mux: mcasp5_aux_gfclk_mux at 4a009878 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&per_abe_x1_gfclk2_div>, <&video1_clk2_div>, <&video2_clk2_div>, <&hdmi_clk2_div>;
+	bit-shift = <22>;
+	reg = <0x4a009878 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcasp6_ahclkx_mux: mcasp6_ahclkx_mux at 4a009904 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>, <&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+	bit-shift = <24>;
+	reg = <0x4a009904 0x4>;
+	bit-mask = <0xf>;
+};
+
+mcasp6_aux_gfclk_mux: mcasp6_aux_gfclk_mux at 4a009904 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&per_abe_x1_gfclk2_div>, <&video1_clk2_div>, <&video2_clk2_div>, <&hdmi_clk2_div>;
+	bit-shift = <22>;
+	reg = <0x4a009904 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcasp7_ahclkx_mux: mcasp7_ahclkx_mux at 4a009908 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>, <&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+	bit-shift = <24>;
+	reg = <0x4a009908 0x4>;
+	bit-mask = <0xf>;
+};
+
+mcasp7_aux_gfclk_mux: mcasp7_aux_gfclk_mux at 4a009908 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&per_abe_x1_gfclk2_div>, <&video1_clk2_div>, <&video2_clk2_div>, <&hdmi_clk2_div>;
+	bit-shift = <22>;
+	reg = <0x4a009908 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcasp8_ahclk_mux: mcasp8_ahclk_mux at 4a009890 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>, <&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+	bit-shift = <22>;
+	reg = <0x4a009890 0x4>;
+	bit-mask = <0x3>;
+};
+
+mcasp8_aux_gfclk_mux: mcasp8_aux_gfclk_mux at 4a009890 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&per_abe_x1_gfclk2_div>, <&video1_clk2_div>, <&video2_clk2_div>, <&hdmi_clk2_div>;
+	bit-shift = <24>;
+	reg = <0x4a009890 0x4>;
+	bit-mask = <0xf>;
+};
+
+mmc1_fclk_mux: mmc1_fclk_mux at 4a009328 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_128m_clk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009328 0x4>;
+	bit-mask = <0x1>;
+};
+
+mmc1_fclk_div: mmc1_fclk_div at 4a009328 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&mmc1_fclk_mux>;
+	bit-shift = <25>;
+	reg = <0x4a009328 0x4>;
+	bit-mask = <0x3>;
+	index-power-of-two;
+};
+
+mmc2_fclk_mux: mmc2_fclk_mux at 4a009330 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_128m_clk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009330 0x4>;
+	bit-mask = <0x1>;
+};
+
+mmc2_fclk_div: mmc2_fclk_div at 4a009330 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&mmc2_fclk_mux>;
+	bit-shift = <25>;
+	reg = <0x4a009330 0x4>;
+	bit-mask = <0x3>;
+	index-power-of-two;
+};
+
+mmc3_gfclk_mux: mmc3_gfclk_mux at 4a009820 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_48m_fclk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009820 0x4>;
+	bit-mask = <0x1>;
+};
+
+mmc3_gfclk_div: mmc3_gfclk_div at 4a009820 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&mmc3_gfclk_mux>;
+	bit-shift = <25>;
+	reg = <0x4a009820 0x4>;
+	bit-mask = <0x3>;
+	index-power-of-two;
+};
+
+mmc4_gfclk_mux: mmc4_gfclk_mux at 4a009828 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_48m_fclk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009828 0x4>;
+	bit-mask = <0x1>;
+};
+
+mmc4_gfclk_div: mmc4_gfclk_div at 4a009828 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&mmc4_gfclk_mux>;
+	bit-shift = <25>;
+	reg = <0x4a009828 0x4>;
+	bit-mask = <0x3>;
+	index-power-of-two;
+};
+
+qspi_gfclk_mux: qspi_gfclk_mux at 4a009838 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_128m_clk>, <&dpll_per_h13x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009838 0x4>;
+	bit-mask = <0x1>;
+};
+
+qspi_gfclk_div: qspi_gfclk_div at 4a009838 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&qspi_gfclk_mux>;
+	bit-shift = <25>;
+	reg = <0x4a009838 0x4>;
+	bit-mask = <0x3>;
+	index-power-of-two;
+};
+
+timer10_gfclk_mux: timer10_gfclk_mux at 4a009728 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>;
+	bit-shift = <24>;
+	reg = <0x4a009728 0x4>;
+	bit-mask = <0xf>;
+};
+
+timer11_gfclk_mux: timer11_gfclk_mux at 4a009730 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>;
+	bit-shift = <24>;
+	reg = <0x4a009730 0x4>;
+	bit-mask = <0xf>;
+};
+
+timer13_gfclk_mux: timer13_gfclk_mux at 4a0097c8 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>;
+	bit-shift = <24>;
+	reg = <0x4a0097c8 0x4>;
+	bit-mask = <0xf>;
+};
+
+timer14_gfclk_mux: timer14_gfclk_mux at 4a0097d0 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>;
+	bit-shift = <24>;
+	reg = <0x4a0097d0 0x4>;
+	bit-mask = <0xf>;
+};
+
+timer15_gfclk_mux: timer15_gfclk_mux at 4a0097d8 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>;
+	bit-shift = <24>;
+	reg = <0x4a0097d8 0x4>;
+	bit-mask = <0xf>;
+};
+
+timer16_gfclk_mux: timer16_gfclk_mux at 4a009830 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>;
+	bit-shift = <24>;
+	reg = <0x4a009830 0x4>;
+	bit-mask = <0xf>;
+};
+
+timer1_gfclk_mux: timer1_gfclk_mux at 4ae07840 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>;
+	bit-shift = <24>;
+	reg = <0x4ae07840 0x4>;
+	bit-mask = <0xf>;
+};
+
+timer2_gfclk_mux: timer2_gfclk_mux at 4a009738 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>;
+	bit-shift = <24>;
+	reg = <0x4a009738 0x4>;
+	bit-mask = <0xf>;
+};
+
+timer3_gfclk_mux: timer3_gfclk_mux at 4a009740 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>;
+	bit-shift = <24>;
+	reg = <0x4a009740 0x4>;
+	bit-mask = <0xf>;
+};
+
+timer4_gfclk_mux: timer4_gfclk_mux at 4a009748 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>;
+	bit-shift = <24>;
+	reg = <0x4a009748 0x4>;
+	bit-mask = <0xf>;
+};
+
+timer5_gfclk_mux: timer5_gfclk_mux at 4a005558 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>, <&clkoutmux0_clk_mux>;
+	bit-shift = <24>;
+	reg = <0x4a005558 0x4>;
+	bit-mask = <0xf>;
+};
+
+timer6_gfclk_mux: timer6_gfclk_mux at 4a005560 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>, <&clkoutmux0_clk_mux>;
+	bit-shift = <24>;
+	reg = <0x4a005560 0x4>;
+	bit-mask = <0xf>;
+};
+
+timer7_gfclk_mux: timer7_gfclk_mux at 4a005568 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>, <&clkoutmux0_clk_mux>;
+	bit-shift = <24>;
+	reg = <0x4a005568 0x4>;
+	bit-mask = <0xf>;
+};
+
+timer8_gfclk_mux: timer8_gfclk_mux at 4a005570 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>, <&clkoutmux0_clk_mux>;
+	bit-shift = <24>;
+	reg = <0x4a005570 0x4>;
+	bit-mask = <0xf>;
+};
+
+timer9_gfclk_mux: timer9_gfclk_mux at 4a009750 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&timer_sys_clk_div>, <&sys_32k_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&abe_giclk_div>, <&video1_div_clk>, <&video2_div_clk>, <&hdmi_div_clk>;
+	bit-shift = <24>;
+	reg = <0x4a009750 0x4>;
+	bit-mask = <0xf>;
+};
+
+uart10_gfclk_mux: uart10_gfclk_mux at 4ae07880 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_48m_fclk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4ae07880 0x4>;
+	bit-mask = <0x1>;
+};
+
+uart1_gfclk_mux: uart1_gfclk_mux at 4a009840 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_48m_fclk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009840 0x4>;
+	bit-mask = <0x1>;
+};
+
+uart2_gfclk_mux: uart2_gfclk_mux at 4a009848 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_48m_fclk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009848 0x4>;
+	bit-mask = <0x1>;
+};
+
+uart3_gfclk_mux: uart3_gfclk_mux at 4a009850 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_48m_fclk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009850 0x4>;
+	bit-mask = <0x1>;
+};
+
+uart4_gfclk_mux: uart4_gfclk_mux at 4a009858 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_48m_fclk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009858 0x4>;
+	bit-mask = <0x1>;
+};
+
+uart5_gfclk_mux: uart5_gfclk_mux at 4a009870 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_48m_fclk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009870 0x4>;
+	bit-mask = <0x1>;
+};
+
+uart6_gfclk_mux: uart6_gfclk_mux at 4a005580 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_48m_fclk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a005580 0x4>;
+	bit-mask = <0x1>;
+};
+
+uart7_gfclk_mux: uart7_gfclk_mux at 4a0098d0 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_48m_fclk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a0098d0 0x4>;
+	bit-mask = <0x1>;
+};
+
+uart8_gfclk_mux: uart8_gfclk_mux at 4a0098e0 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_48m_fclk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a0098e0 0x4>;
+	bit-mask = <0x1>;
+};
+
+uart9_gfclk_mux: uart9_gfclk_mux at 4a0098e8 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&func_48m_fclk>, <&dpll_per_m2x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a0098e8 0x4>;
+	bit-mask = <0x1>;
+};
+
+vip1_gclk_mux: vip1_gclk_mux at 4a009020 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&l3_iclk_div>, <&dpll_core_h23x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009020 0x4>;
+	bit-mask = <0x1>;
+};
+
+vip2_gclk_mux: vip2_gclk_mux at 4a009028 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&l3_iclk_div>, <&dpll_core_h23x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009028 0x4>;
+	bit-mask = <0x1>;
+};
+
+vip3_gclk_mux: vip3_gclk_mux at 4a009030 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&l3_iclk_div>, <&dpll_core_h23x2_ck>;
+	bit-shift = <24>;
+	reg = <0x4a009030 0x4>;
+	bit-mask = <0x1>;
+};
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:15 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:15 +0300
Subject: [PATCHv4 20/33] ARM: AM33xx: remove old clock data and link in new
 clock init code
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-21-git-send-email-t-kristo@ti.com>

AM33xx clocks have now been moved to DT, thus remove the old data file
and use the new init code under OMAP clock driver.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 arch/arm/mach-omap2/Makefile          |    1 -
 arch/arm/mach-omap2/cclock33xx_data.c | 1059 ---------------------------------
 drivers/clk/omap/Makefile             |    3 +-
 3 files changed, 2 insertions(+), 1061 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/cclock33xx_data.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 9f8d3ed..a4782e2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -178,7 +178,6 @@ obj-$(CONFIG_ARCH_OMAP3)		+= clkt_iclk.o
 obj-$(CONFIG_ARCH_OMAP4)		+= $(clock-common)
 obj-$(CONFIG_ARCH_OMAP4)		+= dpll3xxx.o dpll44xx.o
 obj-$(CONFIG_SOC_AM33XX)		+= $(clock-common) dpll3xxx.o
-obj-$(CONFIG_SOC_AM33XX)		+= cclock33xx_data.o
 obj-$(CONFIG_SOC_OMAP5)			+= $(clock-common)
 obj-$(CONFIG_SOC_OMAP5)			+= dpll3xxx.o dpll44xx.o
 
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
deleted file mode 100644
index ba6534d..0000000
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ /dev/null
@@ -1,1059 +0,0 @@
-/*
- * AM33XX Clock data
- *
- * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
- * Vaibhav Hiremath <hvaibhav at ti.com>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation version 2.
- *
- * This program is distributed "as is" WITHOUT ANY WARRANTY of any
- * kind, whether express or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include <linux/kernel.h>
-#include <linux/list.h>
-#include <linux/clk-private.h>
-#include <linux/clkdev.h>
-#include <linux/io.h>
-
-#include "am33xx.h"
-#include "soc.h"
-#include "iomap.h"
-#include "clock.h"
-#include "control.h"
-#include "cm.h"
-#include "cm33xx.h"
-#include "cm-regbits-33xx.h"
-#include "prm.h"
-
-/* Modulemode control */
-#define AM33XX_MODULEMODE_HWCTRL_SHIFT		0
-#define AM33XX_MODULEMODE_SWCTRL_SHIFT		1
-
-/*LIST_HEAD(clocks);*/
-
-/* Root clocks */
-
-/* RTC 32k */
-DEFINE_CLK_FIXED_RATE(clk_32768_ck, CLK_IS_ROOT, 32768, 0x0);
-
-/* On-Chip 32KHz RC OSC */
-DEFINE_CLK_FIXED_RATE(clk_rc32k_ck, CLK_IS_ROOT, 32000, 0x0);
-
-/* Crystal input clks */
-DEFINE_CLK_FIXED_RATE(virt_19200000_ck, CLK_IS_ROOT, 19200000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_24000000_ck, CLK_IS_ROOT, 24000000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_25000000_ck, CLK_IS_ROOT, 25000000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_26000000_ck, CLK_IS_ROOT, 26000000, 0x0);
-
-/* Oscillator clock */
-/* 19.2, 24, 25 or 26 MHz */
-static const char *sys_clkin_ck_parents[] = {
-	"virt_19200000_ck", "virt_24000000_ck", "virt_25000000_ck",
-	"virt_26000000_ck",
-};
-
-/*
- * sys_clk in: input to the dpll and also used as funtional clock for,
- *   adc_tsc, smartreflex0-1, timer1-7, mcasp0-1, dcan0-1, cefuse
- *
- */
-DEFINE_CLK_MUX(sys_clkin_ck, sys_clkin_ck_parents, NULL, 0x0,
-	       AM33XX_CTRL_REGADDR(AM33XX_CONTROL_STATUS),
-	       AM33XX_CONTROL_STATUS_SYSBOOT1_SHIFT,
-	       AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH,
-	       0, NULL);
-
-/* External clock - 12 MHz */
-DEFINE_CLK_FIXED_RATE(tclkin_ck, CLK_IS_ROOT, 12000000, 0x0);
-
-/* Module clocks and DPLL outputs */
-
-/* DPLL_CORE */
-static struct dpll_data dpll_core_dd = {
-	.mult_div1_reg	= AM33XX_CM_CLKSEL_DPLL_CORE,
-	.clk_bypass	= &sys_clkin_ck,
-	.clk_ref	= &sys_clkin_ck,
-	.control_reg	= AM33XX_CM_CLKMODE_DPLL_CORE,
-	.modes		= (1 << DPLL_LOW_POWER_BYPASS) | (1 << DPLL_LOCKED),
-	.idlest_reg	= AM33XX_CM_IDLEST_DPLL_CORE,
-	.mult_mask	= AM33XX_DPLL_MULT_MASK,
-	.div1_mask	= AM33XX_DPLL_DIV_MASK,
-	.enable_mask	= AM33XX_DPLL_EN_MASK,
-	.idlest_mask	= AM33XX_ST_DPLL_CLK_MASK,
-	.max_multiplier	= 2047,
-	.max_divider	= 128,
-	.min_divider	= 1,
-};
-
-/* CLKDCOLDO output */
-static const char *dpll_core_ck_parents[] = {
-	"sys_clkin_ck",
-};
-
-static struct clk dpll_core_ck;
-
-static const struct clk_ops dpll_core_ck_ops = {
-	.recalc_rate	= &omap3_dpll_recalc,
-	.get_parent	= &omap2_init_dpll_parent,
-};
-
-static struct clk_hw_omap dpll_core_ck_hw = {
-	.hw	= {
-		.clk	= &dpll_core_ck,
-	},
-	.dpll_data	= &dpll_core_dd,
-	.ops		= &clkhwops_omap3_dpll,
-};
-
-DEFINE_STRUCT_CLK(dpll_core_ck, dpll_core_ck_parents, dpll_core_ck_ops);
-
-static const char *dpll_core_x2_ck_parents[] = {
-	"dpll_core_ck",
-};
-
-static struct clk dpll_core_x2_ck;
-
-static const struct clk_ops dpll_x2_ck_ops = {
-	.recalc_rate	= &omap3_clkoutx2_recalc,
-};
-
-static struct clk_hw_omap dpll_core_x2_ck_hw = {
-	.hw	= {
-		.clk	= &dpll_core_x2_ck,
-	},
-	.flags		= CLOCK_CLKOUTX2,
-};
-
-DEFINE_STRUCT_CLK(dpll_core_x2_ck, dpll_core_x2_ck_parents, dpll_x2_ck_ops);
-
-DEFINE_CLK_DIVIDER(dpll_core_m4_ck, "dpll_core_x2_ck", &dpll_core_x2_ck,
-		   0x0, AM33XX_CM_DIV_M4_DPLL_CORE,
-		   AM33XX_HSDIVIDER_CLKOUT1_DIV_SHIFT,
-		   AM33XX_HSDIVIDER_CLKOUT1_DIV_WIDTH, CLK_DIVIDER_ONE_BASED,
-		   NULL);
-
-DEFINE_CLK_DIVIDER(dpll_core_m5_ck, "dpll_core_x2_ck", &dpll_core_x2_ck,
-		   0x0, AM33XX_CM_DIV_M5_DPLL_CORE,
-		   AM33XX_HSDIVIDER_CLKOUT2_DIV_SHIFT,
-		   AM33XX_HSDIVIDER_CLKOUT2_DIV_WIDTH,
-		   CLK_DIVIDER_ONE_BASED, NULL);
-
-DEFINE_CLK_DIVIDER(dpll_core_m6_ck, "dpll_core_x2_ck", &dpll_core_x2_ck,
-		   0x0, AM33XX_CM_DIV_M6_DPLL_CORE,
-		   AM33XX_HSDIVIDER_CLKOUT3_DIV_SHIFT,
-		   AM33XX_HSDIVIDER_CLKOUT3_DIV_WIDTH,
-		   CLK_DIVIDER_ONE_BASED, NULL);
-
-
-/* DPLL_MPU */
-static struct dpll_data dpll_mpu_dd = {
-	.mult_div1_reg	= AM33XX_CM_CLKSEL_DPLL_MPU,
-	.clk_bypass	= &sys_clkin_ck,
-	.clk_ref	= &sys_clkin_ck,
-	.control_reg	= AM33XX_CM_CLKMODE_DPLL_MPU,
-	.modes		= (1 << DPLL_LOW_POWER_BYPASS) | (1 << DPLL_LOCKED),
-	.idlest_reg	= AM33XX_CM_IDLEST_DPLL_MPU,
-	.mult_mask	= AM33XX_DPLL_MULT_MASK,
-	.div1_mask	= AM33XX_DPLL_DIV_MASK,
-	.enable_mask	= AM33XX_DPLL_EN_MASK,
-	.idlest_mask	= AM33XX_ST_DPLL_CLK_MASK,
-	.max_multiplier	= 2047,
-	.max_divider	= 128,
-	.min_divider	= 1,
-};
-
-/* CLKOUT: fdpll/M2 */
-static struct clk dpll_mpu_ck;
-
-static const struct clk_ops dpll_mpu_ck_ops = {
-	.enable		= &omap3_noncore_dpll_enable,
-	.disable	= &omap3_noncore_dpll_disable,
-	.recalc_rate	= &omap3_dpll_recalc,
-	.round_rate	= &omap2_dpll_round_rate,
-	.set_rate	= &omap3_noncore_dpll_set_rate,
-	.get_parent	= &omap2_init_dpll_parent,
-};
-
-static struct clk_hw_omap dpll_mpu_ck_hw = {
-	.hw = {
-		.clk	= &dpll_mpu_ck,
-	},
-	.dpll_data	= &dpll_mpu_dd,
-	.ops		= &clkhwops_omap3_dpll,
-};
-
-DEFINE_STRUCT_CLK(dpll_mpu_ck, dpll_core_ck_parents, dpll_mpu_ck_ops);
-
-/*
- * TODO: Add clksel here (sys_clkin, CORE_CLKOUTM6, PER_CLKOUTM2
- * and ALT_CLK1/2)
- */
-DEFINE_CLK_DIVIDER(dpll_mpu_m2_ck, "dpll_mpu_ck", &dpll_mpu_ck,
-		   0x0, AM33XX_CM_DIV_M2_DPLL_MPU, AM33XX_DPLL_CLKOUT_DIV_SHIFT,
-		   AM33XX_DPLL_CLKOUT_DIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);
-
-/* DPLL_DDR */
-static struct dpll_data dpll_ddr_dd = {
-	.mult_div1_reg	= AM33XX_CM_CLKSEL_DPLL_DDR,
-	.clk_bypass	= &sys_clkin_ck,
-	.clk_ref	= &sys_clkin_ck,
-	.control_reg	= AM33XX_CM_CLKMODE_DPLL_DDR,
-	.modes		= (1 << DPLL_LOW_POWER_BYPASS) | (1 << DPLL_LOCKED),
-	.idlest_reg	= AM33XX_CM_IDLEST_DPLL_DDR,
-	.mult_mask	= AM33XX_DPLL_MULT_MASK,
-	.div1_mask	= AM33XX_DPLL_DIV_MASK,
-	.enable_mask	= AM33XX_DPLL_EN_MASK,
-	.idlest_mask	= AM33XX_ST_DPLL_CLK_MASK,
-	.max_multiplier	= 2047,
-	.max_divider	= 128,
-	.min_divider	= 1,
-};
-
-/* CLKOUT: fdpll/M2 */
-static struct clk dpll_ddr_ck;
-
-static const struct clk_ops dpll_ddr_ck_ops = {
-	.recalc_rate	= &omap3_dpll_recalc,
-	.get_parent	= &omap2_init_dpll_parent,
-	.round_rate	= &omap2_dpll_round_rate,
-	.set_rate	= &omap3_noncore_dpll_set_rate,
-};
-
-static struct clk_hw_omap dpll_ddr_ck_hw = {
-	.hw = {
-		.clk	= &dpll_ddr_ck,
-	},
-	.dpll_data	= &dpll_ddr_dd,
-	.ops		= &clkhwops_omap3_dpll,
-};
-
-DEFINE_STRUCT_CLK(dpll_ddr_ck, dpll_core_ck_parents, dpll_ddr_ck_ops);
-
-/*
- * TODO: Add clksel here (sys_clkin, CORE_CLKOUTM6, PER_CLKOUTM2
- * and ALT_CLK1/2)
- */
-DEFINE_CLK_DIVIDER(dpll_ddr_m2_ck, "dpll_ddr_ck", &dpll_ddr_ck,
-		   0x0, AM33XX_CM_DIV_M2_DPLL_DDR,
-		   AM33XX_DPLL_CLKOUT_DIV_SHIFT, AM33XX_DPLL_CLKOUT_DIV_WIDTH,
-		   CLK_DIVIDER_ONE_BASED, NULL);
-
-/* emif_fck functional clock */
-DEFINE_CLK_FIXED_FACTOR(dpll_ddr_m2_div2_ck, "dpll_ddr_m2_ck", &dpll_ddr_m2_ck,
-			0x0, 1, 2);
-
-/* DPLL_DISP */
-static struct dpll_data dpll_disp_dd = {
-	.mult_div1_reg	= AM33XX_CM_CLKSEL_DPLL_DISP,
-	.clk_bypass	= &sys_clkin_ck,
-	.clk_ref	= &sys_clkin_ck,
-	.control_reg	= AM33XX_CM_CLKMODE_DPLL_DISP,
-	.modes		= (1 << DPLL_LOW_POWER_BYPASS) | (1 << DPLL_LOCKED),
-	.idlest_reg	= AM33XX_CM_IDLEST_DPLL_DISP,
-	.mult_mask	= AM33XX_DPLL_MULT_MASK,
-	.div1_mask	= AM33XX_DPLL_DIV_MASK,
-	.enable_mask	= AM33XX_DPLL_EN_MASK,
-	.idlest_mask	= AM33XX_ST_DPLL_CLK_MASK,
-	.max_multiplier	= 2047,
-	.max_divider	= 128,
-	.min_divider	= 1,
-};
-
-/* CLKOUT: fdpll/M2 */
-static struct clk dpll_disp_ck;
-
-static struct clk_hw_omap dpll_disp_ck_hw = {
-	.hw = {
-		.clk	= &dpll_disp_ck,
-	},
-	.dpll_data	= &dpll_disp_dd,
-	.ops		= &clkhwops_omap3_dpll,
-};
-
-DEFINE_STRUCT_CLK(dpll_disp_ck, dpll_core_ck_parents, dpll_ddr_ck_ops);
-
-/*
- * TODO: Add clksel here (sys_clkin, CORE_CLKOUTM6, PER_CLKOUTM2
- * and ALT_CLK1/2)
- */
-DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, "dpll_disp_ck", &dpll_disp_ck,
-		   CLK_SET_RATE_PARENT, AM33XX_CM_DIV_M2_DPLL_DISP,
-		   AM33XX_DPLL_CLKOUT_DIV_SHIFT, AM33XX_DPLL_CLKOUT_DIV_WIDTH,
-		   CLK_DIVIDER_ONE_BASED, NULL);
-
-/* DPLL_PER */
-static struct dpll_data dpll_per_dd = {
-	.mult_div1_reg	= AM33XX_CM_CLKSEL_DPLL_PERIPH,
-	.clk_bypass	= &sys_clkin_ck,
-	.clk_ref	= &sys_clkin_ck,
-	.control_reg	= AM33XX_CM_CLKMODE_DPLL_PER,
-	.modes		= (1 << DPLL_LOW_POWER_BYPASS) | (1 << DPLL_LOCKED),
-	.idlest_reg	= AM33XX_CM_IDLEST_DPLL_PER,
-	.mult_mask	= AM33XX_DPLL_MULT_PERIPH_MASK,
-	.div1_mask	= AM33XX_DPLL_PER_DIV_MASK,
-	.enable_mask	= AM33XX_DPLL_EN_MASK,
-	.idlest_mask	= AM33XX_ST_DPLL_CLK_MASK,
-	.max_multiplier	= 2047,
-	.max_divider	= 128,
-	.min_divider	= 1,
-	.flags		= DPLL_J_TYPE,
-};
-
-/* CLKDCOLDO */
-static struct clk dpll_per_ck;
-
-static struct clk_hw_omap dpll_per_ck_hw = {
-	.hw	= {
-		.clk	= &dpll_per_ck,
-	},
-	.dpll_data	= &dpll_per_dd,
-	.ops		= &clkhwops_omap3_dpll,
-};
-
-DEFINE_STRUCT_CLK(dpll_per_ck, dpll_core_ck_parents, dpll_ddr_ck_ops);
-
-/* CLKOUT: fdpll/M2 */
-DEFINE_CLK_DIVIDER(dpll_per_m2_ck, "dpll_per_ck", &dpll_per_ck, 0x0,
-		   AM33XX_CM_DIV_M2_DPLL_PER, AM33XX_DPLL_CLKOUT_DIV_SHIFT,
-		   AM33XX_DPLL_CLKOUT_DIV_WIDTH, CLK_DIVIDER_ONE_BASED,
-		   NULL);
-
-DEFINE_CLK_FIXED_FACTOR(dpll_per_m2_div4_wkupdm_ck, "dpll_per_m2_ck",
-			&dpll_per_m2_ck, 0x0, 1, 4);
-
-DEFINE_CLK_FIXED_FACTOR(dpll_per_m2_div4_ck, "dpll_per_m2_ck",
-			&dpll_per_m2_ck, 0x0, 1, 4);
-
-DEFINE_CLK_FIXED_FACTOR(dpll_core_m4_div2_ck, "dpll_core_m4_ck",
-			&dpll_core_m4_ck, 0x0, 1, 2);
-
-DEFINE_CLK_FIXED_FACTOR(l4_rtc_gclk, "dpll_core_m4_ck", &dpll_core_m4_ck, 0x0,
-			1, 2);
-
-DEFINE_CLK_FIXED_FACTOR(clk_24mhz, "dpll_per_m2_ck", &dpll_per_m2_ck, 0x0, 1,
-			8);
-
-/*
- * Below clock nodes describes clockdomains derived out
- * of core clock.
- */
-static const struct clk_ops clk_ops_null = {
-};
-
-static const char *l3_gclk_parents[] = {
-	"dpll_core_m4_ck"
-};
-
-static struct clk l3_gclk;
-DEFINE_STRUCT_CLK_HW_OMAP(l3_gclk, NULL);
-DEFINE_STRUCT_CLK(l3_gclk, l3_gclk_parents, clk_ops_null);
-
-static struct clk l4hs_gclk;
-DEFINE_STRUCT_CLK_HW_OMAP(l4hs_gclk, NULL);
-DEFINE_STRUCT_CLK(l4hs_gclk, l3_gclk_parents, clk_ops_null);
-
-static const char *l3s_gclk_parents[] = {
-	"dpll_core_m4_div2_ck"
-};
-
-static struct clk l3s_gclk;
-DEFINE_STRUCT_CLK_HW_OMAP(l3s_gclk, NULL);
-DEFINE_STRUCT_CLK(l3s_gclk, l3s_gclk_parents, clk_ops_null);
-
-static struct clk l4fw_gclk;
-DEFINE_STRUCT_CLK_HW_OMAP(l4fw_gclk, NULL);
-DEFINE_STRUCT_CLK(l4fw_gclk, l3s_gclk_parents, clk_ops_null);
-
-static struct clk l4ls_gclk;
-DEFINE_STRUCT_CLK_HW_OMAP(l4ls_gclk, NULL);
-DEFINE_STRUCT_CLK(l4ls_gclk, l3s_gclk_parents, clk_ops_null);
-
-static struct clk sysclk_div_ck;
-DEFINE_STRUCT_CLK_HW_OMAP(sysclk_div_ck, NULL);
-DEFINE_STRUCT_CLK(sysclk_div_ck, l3_gclk_parents, clk_ops_null);
-
-/*
- * In order to match the clock domain with hwmod clockdomain entry,
- * separate clock nodes is required for the modules which are
- * directly getting their funtioncal clock from sys_clkin.
- */
-static struct clk adc_tsc_fck;
-DEFINE_STRUCT_CLK_HW_OMAP(adc_tsc_fck, NULL);
-DEFINE_STRUCT_CLK(adc_tsc_fck, dpll_core_ck_parents, clk_ops_null);
-
-static struct clk dcan0_fck;
-DEFINE_STRUCT_CLK_HW_OMAP(dcan0_fck, NULL);
-DEFINE_STRUCT_CLK(dcan0_fck, dpll_core_ck_parents, clk_ops_null);
-
-static struct clk dcan1_fck;
-DEFINE_STRUCT_CLK_HW_OMAP(dcan1_fck, NULL);
-DEFINE_STRUCT_CLK(dcan1_fck, dpll_core_ck_parents, clk_ops_null);
-
-static struct clk mcasp0_fck;
-DEFINE_STRUCT_CLK_HW_OMAP(mcasp0_fck, NULL);
-DEFINE_STRUCT_CLK(mcasp0_fck, dpll_core_ck_parents, clk_ops_null);
-
-static struct clk mcasp1_fck;
-DEFINE_STRUCT_CLK_HW_OMAP(mcasp1_fck, NULL);
-DEFINE_STRUCT_CLK(mcasp1_fck, dpll_core_ck_parents, clk_ops_null);
-
-static struct clk smartreflex0_fck;
-DEFINE_STRUCT_CLK_HW_OMAP(smartreflex0_fck, NULL);
-DEFINE_STRUCT_CLK(smartreflex0_fck, dpll_core_ck_parents, clk_ops_null);
-
-static struct clk smartreflex1_fck;
-DEFINE_STRUCT_CLK_HW_OMAP(smartreflex1_fck, NULL);
-DEFINE_STRUCT_CLK(smartreflex1_fck, dpll_core_ck_parents, clk_ops_null);
-
-static struct clk sha0_fck;
-DEFINE_STRUCT_CLK_HW_OMAP(sha0_fck, NULL);
-DEFINE_STRUCT_CLK(sha0_fck, dpll_core_ck_parents, clk_ops_null);
-
-static struct clk aes0_fck;
-DEFINE_STRUCT_CLK_HW_OMAP(aes0_fck, NULL);
-DEFINE_STRUCT_CLK(aes0_fck, dpll_core_ck_parents, clk_ops_null);
-
-/*
- * Modules clock nodes
- *
- * The following clock leaf nodes are added for the moment because:
- *
- *  - hwmod data is not present for these modules, either hwmod
- *    control is not required or its not populated.
- *  - Driver code is not yet migrated to use hwmod/runtime pm
- *  - Modules outside kernel access (to disable them by default)
- *
- *     - mmu (gfx domain)
- *     - cefuse
- *     - usbotg_fck (its additional clock and not really a modulemode)
- *     - ieee5000
- */
-
-DEFINE_CLK_GATE(mmu_fck, "dpll_core_m4_ck", &dpll_core_m4_ck, 0x0,
-		AM33XX_CM_GFX_MMUDATA_CLKCTRL, AM33XX_MODULEMODE_SWCTRL_SHIFT,
-		0x0, NULL);
-
-DEFINE_CLK_GATE(cefuse_fck, "sys_clkin_ck", &sys_clkin_ck, 0x0,
-		AM33XX_CM_CEFUSE_CEFUSE_CLKCTRL, AM33XX_MODULEMODE_SWCTRL_SHIFT,
-		0x0, NULL);
-
-/*
- * clkdiv32 is generated from fixed division of 732.4219
- */
-DEFINE_CLK_FIXED_FACTOR(clkdiv32k_ck, "clk_24mhz", &clk_24mhz, 0x0, 1, 732);
-
-static struct clk clkdiv32k_ick;
-
-static const char *clkdiv32k_ick_parent_names[] = {
-	"clkdiv32k_ck",
-};
-
-static const struct clk_ops clkdiv32k_ick_ops = {
-	.enable         = &omap2_dflt_clk_enable,
-	.disable        = &omap2_dflt_clk_disable,
-	.is_enabled     = &omap2_dflt_clk_is_enabled,
-	.init           = &omap2_init_clk_clkdm,
-};
-
-static struct clk_hw_omap clkdiv32k_ick_hw = {
-	.hw	= {
-		.clk	= &clkdiv32k_ick,
-	},
-	.enable_reg	= AM33XX_CM_PER_CLKDIV32K_CLKCTRL,
-	.enable_bit	= AM33XX_MODULEMODE_SWCTRL_SHIFT,
-	.clkdm_name	= "clk_24mhz_clkdm",
-};
-
-DEFINE_STRUCT_CLK(clkdiv32k_ick, clkdiv32k_ick_parent_names, clkdiv32k_ick_ops);
-
-/* "usbotg_fck" is an additional clock and not really a modulemode */
-DEFINE_CLK_GATE(usbotg_fck, "dpll_per_ck", &dpll_per_ck, 0x0,
-		AM33XX_CM_CLKDCOLDO_DPLL_PER, AM33XX_ST_DPLL_CLKDCOLDO_SHIFT,
-		0x0, NULL);
-
-DEFINE_CLK_GATE(ieee5000_fck, "dpll_core_m4_div2_ck", &dpll_core_m4_div2_ck,
-		0x0, AM33XX_CM_PER_IEEE5000_CLKCTRL,
-		AM33XX_MODULEMODE_SWCTRL_SHIFT, 0x0, NULL);
-
-/* Timers */
-static const struct clksel timer1_clkmux_sel[] = {
-	{ .parent = &sys_clkin_ck, .rates = div_1_0_rates },
-	{ .parent = &clkdiv32k_ick, .rates = div_1_1_rates },
-	{ .parent = &tclkin_ck, .rates = div_1_2_rates },
-	{ .parent = &clk_rc32k_ck, .rates = div_1_3_rates },
-	{ .parent = &clk_32768_ck, .rates = div_1_4_rates },
-	{ .parent = NULL },
-};
-
-static const char *timer1_ck_parents[] = {
-	"sys_clkin_ck", "clkdiv32k_ick", "tclkin_ck", "clk_rc32k_ck",
-	"clk_32768_ck",
-};
-
-static struct clk timer1_fck;
-
-static const struct clk_ops timer1_fck_ops = {
-	.recalc_rate	= &omap2_clksel_recalc,
-	.get_parent	= &omap2_clksel_find_parent_index,
-	.set_parent	= &omap2_clksel_set_parent,
-	.init		= &omap2_init_clk_clkdm,
-};
-
-static struct clk_hw_omap timer1_fck_hw = {
-	.hw	= {
-		.clk	= &timer1_fck,
-	},
-	.clkdm_name	= "l4ls_clkdm",
-	.clksel		= timer1_clkmux_sel,
-	.clksel_reg	= AM33XX_CLKSEL_TIMER1MS_CLK,
-	.clksel_mask	= AM33XX_CLKSEL_0_2_MASK,
-};
-
-DEFINE_STRUCT_CLK(timer1_fck, timer1_ck_parents, timer1_fck_ops);
-
-static const struct clksel timer2_to_7_clk_sel[] = {
-	{ .parent = &tclkin_ck, .rates = div_1_0_rates },
-	{ .parent = &sys_clkin_ck, .rates = div_1_1_rates },
-	{ .parent = &clkdiv32k_ick, .rates = div_1_2_rates },
-	{ .parent = NULL },
-};
-
-static const char *timer2_to_7_ck_parents[] = {
-	"tclkin_ck", "sys_clkin_ck", "clkdiv32k_ick",
-};
-
-static struct clk timer2_fck;
-
-static struct clk_hw_omap timer2_fck_hw = {
-	.hw	= {
-		.clk	= &timer2_fck,
-	},
-	.clkdm_name	= "l4ls_clkdm",
-	.clksel		= timer2_to_7_clk_sel,
-	.clksel_reg	= AM33XX_CLKSEL_TIMER2_CLK,
-	.clksel_mask	= AM33XX_CLKSEL_0_1_MASK,
-};
-
-DEFINE_STRUCT_CLK(timer2_fck, timer2_to_7_ck_parents, timer1_fck_ops);
-
-static struct clk timer3_fck;
-
-static struct clk_hw_omap timer3_fck_hw = {
-	.hw	= {
-		.clk	= &timer3_fck,
-	},
-	.clkdm_name	= "l4ls_clkdm",
-	.clksel		= timer2_to_7_clk_sel,
-	.clksel_reg	= AM33XX_CLKSEL_TIMER3_CLK,
-	.clksel_mask	= AM33XX_CLKSEL_0_1_MASK,
-};
-
-DEFINE_STRUCT_CLK(timer3_fck, timer2_to_7_ck_parents, timer1_fck_ops);
-
-static struct clk timer4_fck;
-
-static struct clk_hw_omap timer4_fck_hw = {
-	.hw	= {
-		.clk	= &timer4_fck,
-	},
-	.clkdm_name	= "l4ls_clkdm",
-	.clksel		= timer2_to_7_clk_sel,
-	.clksel_reg	= AM33XX_CLKSEL_TIMER4_CLK,
-	.clksel_mask	= AM33XX_CLKSEL_0_1_MASK,
-};
-
-DEFINE_STRUCT_CLK(timer4_fck, timer2_to_7_ck_parents, timer1_fck_ops);
-
-static struct clk timer5_fck;
-
-static struct clk_hw_omap timer5_fck_hw = {
-	.hw	= {
-		.clk	= &timer5_fck,
-	},
-	.clkdm_name	= "l4ls_clkdm",
-	.clksel		= timer2_to_7_clk_sel,
-	.clksel_reg	= AM33XX_CLKSEL_TIMER5_CLK,
-	.clksel_mask	= AM33XX_CLKSEL_0_1_MASK,
-};
-
-DEFINE_STRUCT_CLK(timer5_fck, timer2_to_7_ck_parents, timer1_fck_ops);
-
-static struct clk timer6_fck;
-
-static struct clk_hw_omap timer6_fck_hw = {
-	.hw	= {
-		.clk	= &timer6_fck,
-	},
-	.clkdm_name	= "l4ls_clkdm",
-	.clksel		= timer2_to_7_clk_sel,
-	.clksel_reg	= AM33XX_CLKSEL_TIMER6_CLK,
-	.clksel_mask	= AM33XX_CLKSEL_0_1_MASK,
-};
-
-DEFINE_STRUCT_CLK(timer6_fck, timer2_to_7_ck_parents, timer1_fck_ops);
-
-static struct clk timer7_fck;
-
-static struct clk_hw_omap timer7_fck_hw = {
-	.hw	= {
-		.clk	= &timer7_fck,
-	},
-	.clkdm_name	= "l4ls_clkdm",
-	.clksel		= timer2_to_7_clk_sel,
-	.clksel_reg	= AM33XX_CLKSEL_TIMER7_CLK,
-	.clksel_mask	= AM33XX_CLKSEL_0_1_MASK,
-};
-
-DEFINE_STRUCT_CLK(timer7_fck, timer2_to_7_ck_parents, timer1_fck_ops);
-
-DEFINE_CLK_FIXED_FACTOR(cpsw_125mhz_gclk,
-			"dpll_core_m5_ck",
-			&dpll_core_m5_ck,
-			0x0,
-			1, 2);
-
-static const struct clk_ops cpsw_fck_ops = {
-	.recalc_rate	= &omap2_clksel_recalc,
-	.get_parent	= &omap2_clksel_find_parent_index,
-	.set_parent	= &omap2_clksel_set_parent,
-};
-
-static const struct clksel cpsw_cpts_rft_clkmux_sel[] = {
-	{ .parent = &dpll_core_m5_ck, .rates = div_1_0_rates },
-	{ .parent = &dpll_core_m4_ck, .rates = div_1_1_rates },
-	{ .parent = NULL },
-};
-
-static const char *cpsw_cpts_rft_ck_parents[] = {
-	"dpll_core_m5_ck", "dpll_core_m4_ck",
-};
-
-static struct clk cpsw_cpts_rft_clk;
-
-static struct clk_hw_omap cpsw_cpts_rft_clk_hw = {
-	.hw	= {
-		.clk	= &cpsw_cpts_rft_clk,
-	},
-	.clkdm_name	= "cpsw_125mhz_clkdm",
-	.clksel		= cpsw_cpts_rft_clkmux_sel,
-	.clksel_reg	= AM33XX_CM_CPTS_RFT_CLKSEL,
-	.clksel_mask	= AM33XX_CLKSEL_0_0_MASK,
-};
-
-DEFINE_STRUCT_CLK(cpsw_cpts_rft_clk, cpsw_cpts_rft_ck_parents, cpsw_fck_ops);
-
-
-/* gpio */
-static const char *gpio0_ck_parents[] = {
-	"clk_rc32k_ck", "clk_32768_ck", "clkdiv32k_ick",
-};
-
-static const struct clksel gpio0_dbclk_mux_sel[] = {
-	{ .parent = &clk_rc32k_ck, .rates = div_1_0_rates },
-	{ .parent = &clk_32768_ck, .rates = div_1_1_rates },
-	{ .parent = &clkdiv32k_ick, .rates = div_1_2_rates },
-	{ .parent = NULL },
-};
-
-static const struct clk_ops gpio_fck_ops = {
-	.recalc_rate	= &omap2_clksel_recalc,
-	.get_parent	= &omap2_clksel_find_parent_index,
-	.set_parent	= &omap2_clksel_set_parent,
-	.init		= &omap2_init_clk_clkdm,
-};
-
-static struct clk gpio0_dbclk_mux_ck;
-
-static struct clk_hw_omap gpio0_dbclk_mux_ck_hw = {
-	.hw	= {
-		.clk	= &gpio0_dbclk_mux_ck,
-	},
-	.clkdm_name	= "l4_wkup_clkdm",
-	.clksel		= gpio0_dbclk_mux_sel,
-	.clksel_reg	= AM33XX_CLKSEL_GPIO0_DBCLK,
-	.clksel_mask	= AM33XX_CLKSEL_0_1_MASK,
-};
-
-DEFINE_STRUCT_CLK(gpio0_dbclk_mux_ck, gpio0_ck_parents, gpio_fck_ops);
-
-DEFINE_CLK_GATE(gpio0_dbclk, "gpio0_dbclk_mux_ck", &gpio0_dbclk_mux_ck, 0x0,
-		AM33XX_CM_WKUP_GPIO0_CLKCTRL,
-		AM33XX_OPTFCLKEN_GPIO0_GDBCLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(gpio1_dbclk, "clkdiv32k_ick", &clkdiv32k_ick, 0x0,
-		AM33XX_CM_PER_GPIO1_CLKCTRL,
-		AM33XX_OPTFCLKEN_GPIO_1_GDBCLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(gpio2_dbclk, "clkdiv32k_ick", &clkdiv32k_ick, 0x0,
-		AM33XX_CM_PER_GPIO2_CLKCTRL,
-		AM33XX_OPTFCLKEN_GPIO_2_GDBCLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(gpio3_dbclk, "clkdiv32k_ick", &clkdiv32k_ick, 0x0,
-		AM33XX_CM_PER_GPIO3_CLKCTRL,
-		AM33XX_OPTFCLKEN_GPIO_3_GDBCLK_SHIFT, 0x0, NULL);
-
-
-static const char *pruss_ck_parents[] = {
-	"l3_gclk", "dpll_disp_m2_ck",
-};
-
-static const struct clksel pruss_ocp_clk_mux_sel[] = {
-	{ .parent = &l3_gclk, .rates = div_1_0_rates },
-	{ .parent = &dpll_disp_m2_ck, .rates = div_1_1_rates },
-	{ .parent = NULL },
-};
-
-static struct clk pruss_ocp_gclk;
-
-static struct clk_hw_omap pruss_ocp_gclk_hw = {
-	.hw	= {
-		.clk	= &pruss_ocp_gclk,
-	},
-	.clkdm_name	= "pruss_ocp_clkdm",
-	.clksel		= pruss_ocp_clk_mux_sel,
-	.clksel_reg	= AM33XX_CLKSEL_PRUSS_OCP_CLK,
-	.clksel_mask	= AM33XX_CLKSEL_0_0_MASK,
-};
-
-DEFINE_STRUCT_CLK(pruss_ocp_gclk, pruss_ck_parents, gpio_fck_ops);
-
-static const char *lcd_ck_parents[] = {
-	"dpll_disp_m2_ck", "dpll_core_m5_ck", "dpll_per_m2_ck",
-};
-
-static const struct clksel lcd_clk_mux_sel[] = {
-	{ .parent = &dpll_disp_m2_ck, .rates = div_1_0_rates },
-	{ .parent = &dpll_core_m5_ck, .rates = div_1_1_rates },
-	{ .parent = &dpll_per_m2_ck, .rates = div_1_2_rates },
-	{ .parent = NULL },
-};
-
-static struct clk lcd_gclk;
-
-static struct clk_hw_omap lcd_gclk_hw = {
-	.hw	= {
-		.clk	= &lcd_gclk,
-	},
-	.clkdm_name	= "lcdc_clkdm",
-	.clksel		= lcd_clk_mux_sel,
-	.clksel_reg	= AM33XX_CLKSEL_LCDC_PIXEL_CLK,
-	.clksel_mask	= AM33XX_CLKSEL_0_1_MASK,
-};
-
-DEFINE_STRUCT_CLK_FLAGS(lcd_gclk, lcd_ck_parents,
-			gpio_fck_ops, CLK_SET_RATE_PARENT);
-
-DEFINE_CLK_FIXED_FACTOR(mmc_clk, "dpll_per_m2_ck", &dpll_per_m2_ck, 0x0, 1, 2);
-
-static const char *gfx_ck_parents[] = {
-	"dpll_core_m4_ck", "dpll_per_m2_ck",
-};
-
-static const struct clksel gfx_clksel_sel[] = {
-	{ .parent = &dpll_core_m4_ck, .rates = div_1_0_rates },
-	{ .parent = &dpll_per_m2_ck, .rates = div_1_1_rates },
-	{ .parent = NULL },
-};
-
-static struct clk gfx_fclk_clksel_ck;
-
-static struct clk_hw_omap gfx_fclk_clksel_ck_hw = {
-	.hw	= {
-		.clk	= &gfx_fclk_clksel_ck,
-	},
-	.clksel		= gfx_clksel_sel,
-	.clksel_reg	= AM33XX_CLKSEL_GFX_FCLK,
-	.clksel_mask	= AM33XX_CLKSEL_GFX_FCLK_MASK,
-};
-
-DEFINE_STRUCT_CLK(gfx_fclk_clksel_ck, gfx_ck_parents, gpio_fck_ops);
-
-static const struct clk_div_table div_1_0_2_1_rates[] = {
-	{ .div = 1, .val = 0, },
-	{ .div = 2, .val = 1, },
-	{ .div = 0 },
-};
-
-DEFINE_CLK_DIVIDER_TABLE(gfx_fck_div_ck, "gfx_fclk_clksel_ck",
-			 &gfx_fclk_clksel_ck, 0x0, AM33XX_CLKSEL_GFX_FCLK,
-			 AM33XX_CLKSEL_0_0_SHIFT, AM33XX_CLKSEL_0_0_WIDTH,
-			 0x0, div_1_0_2_1_rates, NULL);
-
-static const char *sysclkout_ck_parents[] = {
-	"clk_32768_ck", "l3_gclk", "dpll_ddr_m2_ck", "dpll_per_m2_ck",
-	"lcd_gclk",
-};
-
-static const struct clksel sysclkout_pre_sel[] = {
-	{ .parent = &clk_32768_ck, .rates = div_1_0_rates },
-	{ .parent = &l3_gclk, .rates = div_1_1_rates },
-	{ .parent = &dpll_ddr_m2_ck, .rates = div_1_2_rates },
-	{ .parent = &dpll_per_m2_ck, .rates = div_1_3_rates },
-	{ .parent = &lcd_gclk, .rates = div_1_4_rates },
-	{ .parent = NULL },
-};
-
-static struct clk sysclkout_pre_ck;
-
-static struct clk_hw_omap sysclkout_pre_ck_hw = {
-	.hw	= {
-		.clk	= &sysclkout_pre_ck,
-	},
-	.clksel		= sysclkout_pre_sel,
-	.clksel_reg	= AM33XX_CM_CLKOUT_CTRL,
-	.clksel_mask	= AM33XX_CLKOUT2SOURCE_MASK,
-};
-
-DEFINE_STRUCT_CLK(sysclkout_pre_ck, sysclkout_ck_parents, gpio_fck_ops);
-
-/* Divide by 8 clock rates with default clock is 1/1*/
-static const struct clk_div_table div8_rates[] = {
-	{ .div = 1, .val = 0, },
-	{ .div = 2, .val = 1, },
-	{ .div = 3, .val = 2, },
-	{ .div = 4, .val = 3, },
-	{ .div = 5, .val = 4, },
-	{ .div = 6, .val = 5, },
-	{ .div = 7, .val = 6, },
-	{ .div = 8, .val = 7, },
-	{ .div = 0 },
-};
-
-DEFINE_CLK_DIVIDER_TABLE(clkout2_div_ck, "sysclkout_pre_ck", &sysclkout_pre_ck,
-			 0x0, AM33XX_CM_CLKOUT_CTRL, AM33XX_CLKOUT2DIV_SHIFT,
-			 AM33XX_CLKOUT2DIV_WIDTH, 0x0, div8_rates, NULL);
-
-DEFINE_CLK_GATE(clkout2_ck, "clkout2_div_ck", &clkout2_div_ck, 0x0,
-		AM33XX_CM_CLKOUT_CTRL, AM33XX_CLKOUT2EN_SHIFT, 0x0, NULL);
-
-static const char *wdt_ck_parents[] = {
-	"clk_rc32k_ck", "clkdiv32k_ick",
-};
-
-static const struct clksel wdt_clkmux_sel[] = {
-	{ .parent = &clk_rc32k_ck, .rates = div_1_0_rates },
-	{ .parent = &clkdiv32k_ick, .rates = div_1_1_rates },
-	{ .parent = NULL },
-};
-
-static struct clk wdt1_fck;
-
-static struct clk_hw_omap wdt1_fck_hw = {
-	.hw	= {
-		.clk	= &wdt1_fck,
-	},
-	.clkdm_name	= "l4_wkup_clkdm",
-	.clksel		= wdt_clkmux_sel,
-	.clksel_reg	= AM33XX_CLKSEL_WDT1_CLK,
-	.clksel_mask	= AM33XX_CLKSEL_0_1_MASK,
-};
-
-DEFINE_STRUCT_CLK(wdt1_fck, wdt_ck_parents, gpio_fck_ops);
-
-static const char *pwmss_clk_parents[] = {
-	"dpll_per_m2_ck",
-};
-
-static const struct clk_ops ehrpwm_tbclk_ops = {
-	.enable		= &omap2_dflt_clk_enable,
-	.disable	= &omap2_dflt_clk_disable,
-};
-
-DEFINE_CLK_OMAP_MUX_GATE(ehrpwm0_tbclk, "l4ls_clkdm",
-			 NULL, NULL, 0,
-			 AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
-			 AM33XX_PWMSS0_TBCLKEN_SHIFT,
-			 NULL, pwmss_clk_parents, ehrpwm_tbclk_ops);
-
-DEFINE_CLK_OMAP_MUX_GATE(ehrpwm1_tbclk, "l4ls_clkdm",
-			 NULL, NULL, 0,
-			 AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
-			 AM33XX_PWMSS1_TBCLKEN_SHIFT,
-			 NULL, pwmss_clk_parents, ehrpwm_tbclk_ops);
-
-DEFINE_CLK_OMAP_MUX_GATE(ehrpwm2_tbclk, "l4ls_clkdm",
-			 NULL, NULL, 0,
-			 AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
-			 AM33XX_PWMSS2_TBCLKEN_SHIFT,
-			 NULL, pwmss_clk_parents, ehrpwm_tbclk_ops);
-
-/*
- * debugss optional clocks
- */
-DEFINE_CLK_GATE(dbg_sysclk_ck, "sys_clkin_ck", &sys_clkin_ck,
-		0x0, AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
-		AM33XX_OPTFCLKEN_DBGSYSCLK_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(dbg_clka_ck, "dpll_core_m4_ck", &dpll_core_m4_ck,
-		0x0, AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
-		AM33XX_OPTCLK_DEBUG_CLKA_SHIFT, 0x0, NULL);
-
-static const char *stm_pmd_clock_mux_ck_parents[] = {
-	"dbg_sysclk_ck", "dbg_clka_ck",
-};
-
-DEFINE_CLK_MUX(stm_pmd_clock_mux_ck, stm_pmd_clock_mux_ck_parents, NULL, 0x0,
-	       AM33XX_CM_WKUP_DEBUGSS_CLKCTRL, AM33XX_STM_PMD_CLKSEL_SHIFT,
-	       AM33XX_STM_PMD_CLKSEL_WIDTH, 0x0, NULL);
-
-DEFINE_CLK_MUX(trace_pmd_clk_mux_ck, stm_pmd_clock_mux_ck_parents, NULL, 0x0,
-	       AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
-	       AM33XX_TRC_PMD_CLKSEL_SHIFT,
-	       AM33XX_TRC_PMD_CLKSEL_WIDTH, 0x0, NULL);
-
-DEFINE_CLK_DIVIDER(stm_clk_div_ck, "stm_pmd_clock_mux_ck",
-		   &stm_pmd_clock_mux_ck, 0x0, AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
-		   AM33XX_STM_PMD_CLKDIVSEL_SHIFT,
-		   AM33XX_STM_PMD_CLKDIVSEL_WIDTH, CLK_DIVIDER_POWER_OF_TWO,
-		   NULL);
-
-DEFINE_CLK_DIVIDER(trace_clk_div_ck, "trace_pmd_clk_mux_ck",
-		   &trace_pmd_clk_mux_ck, 0x0, AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
-		   AM33XX_TRC_PMD_CLKDIVSEL_SHIFT,
-		   AM33XX_TRC_PMD_CLKDIVSEL_WIDTH, CLK_DIVIDER_POWER_OF_TWO,
-		   NULL);
-
-/*
- * clkdev
- */
-static struct omap_clk am33xx_clks[] = {
-	CLK(NULL,	"clk_32768_ck",		&clk_32768_ck),
-	CLK(NULL,	"clk_rc32k_ck",		&clk_rc32k_ck),
-	CLK(NULL,	"virt_19200000_ck",	&virt_19200000_ck),
-	CLK(NULL,	"virt_24000000_ck",	&virt_24000000_ck),
-	CLK(NULL,	"virt_25000000_ck",	&virt_25000000_ck),
-	CLK(NULL,	"virt_26000000_ck",	&virt_26000000_ck),
-	CLK(NULL,	"sys_clkin_ck",		&sys_clkin_ck),
-	CLK(NULL,	"tclkin_ck",		&tclkin_ck),
-	CLK(NULL,	"dpll_core_ck",		&dpll_core_ck),
-	CLK(NULL,	"dpll_core_x2_ck",	&dpll_core_x2_ck),
-	CLK(NULL,	"dpll_core_m4_ck",	&dpll_core_m4_ck),
-	CLK(NULL,	"dpll_core_m5_ck",	&dpll_core_m5_ck),
-	CLK(NULL,	"dpll_core_m6_ck",	&dpll_core_m6_ck),
-	CLK(NULL,	"dpll_mpu_ck",		&dpll_mpu_ck),
-	CLK("cpu0",	NULL,			&dpll_mpu_ck),
-	CLK(NULL,	"dpll_mpu_m2_ck",	&dpll_mpu_m2_ck),
-	CLK(NULL,	"dpll_ddr_ck",		&dpll_ddr_ck),
-	CLK(NULL,	"dpll_ddr_m2_ck",	&dpll_ddr_m2_ck),
-	CLK(NULL,	"dpll_ddr_m2_div2_ck",	&dpll_ddr_m2_div2_ck),
-	CLK(NULL,	"dpll_disp_ck",		&dpll_disp_ck),
-	CLK(NULL,	"dpll_disp_m2_ck",	&dpll_disp_m2_ck),
-	CLK(NULL,	"dpll_per_ck",		&dpll_per_ck),
-	CLK(NULL,	"dpll_per_m2_ck",	&dpll_per_m2_ck),
-	CLK(NULL,	"dpll_per_m2_div4_wkupdm_ck",	&dpll_per_m2_div4_wkupdm_ck),
-	CLK(NULL,	"dpll_per_m2_div4_ck",	&dpll_per_m2_div4_ck),
-	CLK(NULL,	"adc_tsc_fck",		&adc_tsc_fck),
-	CLK(NULL,	"cefuse_fck",		&cefuse_fck),
-	CLK(NULL,	"clkdiv32k_ck",		&clkdiv32k_ck),
-	CLK(NULL,	"clkdiv32k_ick",	&clkdiv32k_ick),
-	CLK(NULL,	"dcan0_fck",		&dcan0_fck),
-	CLK("481cc000.d_can",	NULL,		&dcan0_fck),
-	CLK(NULL,	"dcan1_fck",		&dcan1_fck),
-	CLK("481d0000.d_can",	NULL,		&dcan1_fck),
-	CLK(NULL,	"pruss_ocp_gclk",	&pruss_ocp_gclk),
-	CLK(NULL,	"mcasp0_fck",		&mcasp0_fck),
-	CLK(NULL,	"mcasp1_fck",		&mcasp1_fck),
-	CLK(NULL,	"mmu_fck",		&mmu_fck),
-	CLK(NULL,	"smartreflex0_fck",	&smartreflex0_fck),
-	CLK(NULL,	"smartreflex1_fck",	&smartreflex1_fck),
-	CLK(NULL,	"sha0_fck",		&sha0_fck),
-	CLK(NULL,	"aes0_fck",		&aes0_fck),
-	CLK(NULL,	"timer1_fck",		&timer1_fck),
-	CLK(NULL,	"timer2_fck",		&timer2_fck),
-	CLK(NULL,	"timer3_fck",		&timer3_fck),
-	CLK(NULL,	"timer4_fck",		&timer4_fck),
-	CLK(NULL,	"timer5_fck",		&timer5_fck),
-	CLK(NULL,	"timer6_fck",		&timer6_fck),
-	CLK(NULL,	"timer7_fck",		&timer7_fck),
-	CLK(NULL,	"usbotg_fck",		&usbotg_fck),
-	CLK(NULL,	"ieee5000_fck",		&ieee5000_fck),
-	CLK(NULL,	"wdt1_fck",		&wdt1_fck),
-	CLK(NULL,	"l4_rtc_gclk",		&l4_rtc_gclk),
-	CLK(NULL,	"l3_gclk",		&l3_gclk),
-	CLK(NULL,	"dpll_core_m4_div2_ck",	&dpll_core_m4_div2_ck),
-	CLK(NULL,	"l4hs_gclk",		&l4hs_gclk),
-	CLK(NULL,	"l3s_gclk",		&l3s_gclk),
-	CLK(NULL,	"l4fw_gclk",		&l4fw_gclk),
-	CLK(NULL,	"l4ls_gclk",		&l4ls_gclk),
-	CLK(NULL,	"clk_24mhz",		&clk_24mhz),
-	CLK(NULL,	"sysclk_div_ck",	&sysclk_div_ck),
-	CLK(NULL,	"cpsw_125mhz_gclk",	&cpsw_125mhz_gclk),
-	CLK(NULL,	"cpsw_cpts_rft_clk",	&cpsw_cpts_rft_clk),
-	CLK(NULL,	"gpio0_dbclk_mux_ck",	&gpio0_dbclk_mux_ck),
-	CLK(NULL,	"gpio0_dbclk",		&gpio0_dbclk),
-	CLK(NULL,	"gpio1_dbclk",		&gpio1_dbclk),
-	CLK(NULL,	"gpio2_dbclk",		&gpio2_dbclk),
-	CLK(NULL,	"gpio3_dbclk",		&gpio3_dbclk),
-	CLK(NULL,	"lcd_gclk",		&lcd_gclk),
-	CLK(NULL,	"mmc_clk",		&mmc_clk),
-	CLK(NULL,	"gfx_fclk_clksel_ck",	&gfx_fclk_clksel_ck),
-	CLK(NULL,	"gfx_fck_div_ck",	&gfx_fck_div_ck),
-	CLK(NULL,	"sysclkout_pre_ck",	&sysclkout_pre_ck),
-	CLK(NULL,	"clkout2_div_ck",	&clkout2_div_ck),
-	CLK(NULL,	"timer_32k_ck",		&clkdiv32k_ick),
-	CLK(NULL,	"timer_sys_ck",		&sys_clkin_ck),
-	CLK(NULL,	"dbg_sysclk_ck",	&dbg_sysclk_ck),
-	CLK(NULL,	"dbg_clka_ck",		&dbg_clka_ck),
-	CLK(NULL,	"stm_pmd_clock_mux_ck",	&stm_pmd_clock_mux_ck),
-	CLK(NULL,	"trace_pmd_clk_mux_ck",	&trace_pmd_clk_mux_ck),
-	CLK(NULL,	"stm_clk_div_ck",	&stm_clk_div_ck),
-	CLK(NULL,	"trace_clk_div_ck",	&trace_clk_div_ck),
-	CLK(NULL,	"clkout2_ck",		&clkout2_ck),
-	CLK("48300200.ehrpwm",	"tbclk",	&ehrpwm0_tbclk),
-	CLK("48302200.ehrpwm",	"tbclk",	&ehrpwm1_tbclk),
-	CLK("48304200.ehrpwm",	"tbclk",	&ehrpwm2_tbclk),
-};
-
-
-static const char *enable_init_clks[] = {
-	"dpll_ddr_m2_ck",
-	"dpll_mpu_m2_ck",
-	"l3_gclk",
-	"l4hs_gclk",
-	"l4fw_gclk",
-	"l4ls_gclk",
-	"clkout2_ck",	/* Required for external peripherals like, Audio codecs */
-};
-
-int __init am33xx_clk_init(void)
-{
-	if (soc_is_am33xx())
-		cpu_mask = RATE_IN_AM33XX;
-
-	omap_clocks_register(am33xx_clks, ARRAY_SIZE(am33xx_clks));
-
-	omap2_clk_disable_autoidle_all();
-
-	omap2_clk_enable_init_clocks(enable_init_clks,
-				     ARRAY_SIZE(enable_init_clks));
-
-	/* TRM ERRATA: Timer 3 & 6 default parent (TCLKIN) may not be always
-	 *    physically present, in such a case HWMOD enabling of
-	 *    clock would be failure with default parent. And timer
-	 *    probe thinks clock is already enabled, this leads to
-	 *    crash upon accessing timer 3 & 6 registers in probe.
-	 *    Fix by setting parent of both these timers to master
-	 *    oscillator clock.
-	 */
-
-	clk_set_parent(&timer3_fck, &sys_clkin_ck);
-	clk_set_parent(&timer6_fck, &sys_clkin_ck);
-	/*
-	 * The On-Chip 32K RC Osc clock is not an accurate clock-source as per
-	 * the design/spec, so as a result, for example, timer which supposed
-	 * to get expired @60Sec, but will expire somewhere ~@40Sec, which is
-	 * not expected by any use-case, so change WDT1 clock source to PRCM
-	 * 32KHz clock.
-	 */
-	clk_set_parent(&wdt1_fck, &clkdiv32k_ick);
-
-	return 0;
-}
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index b8dbfda..c4e8825 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1,2 +1,3 @@
 obj-y					+= clk.o dpll.o autoidle.o gate.o \
-					   clk-44xx.o clk-54xx.o clk-7xx.o
+					   clk-44xx.o clk-54xx.o clk-7xx.o \
+					   clk-33xx.o
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:26 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:26 +0300
Subject: [PATCHv4 31/33] ARM: dts: clk: Add apll related clocks
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-32-git-send-email-t-kristo@ti.com>

From: Keerthy <j-keerthy at ti.com>

The patch adds a mux node to choose the parent of apll_pcie_ck node.

Signed-off-by: Keerthy <j-keerthy at ti.com>
---
 arch/arm/boot/dts/dra7xx-clocks.dtsi |   19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 8477ff9..e923311 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -328,13 +328,24 @@ dpll_pcie_ref_m2ldo_ck: dpll_pcie_ref_m2ldo_ck at 4a008210 {
 	ti,autoidle-low;
 };
 
+/* APLL_PCIE */
+
+/* mux clock to select the reference clock */
+apll_pcie_in_clk_mux: apll_pcie_in_clk_mux at 4ae06118 {
+	compatible = "mux-clock";
+	clocks = <&dpll_pcie_ref_ck>, <&pciesref_acs_clk_ck>;
+	#clock-cells = <0>;
+	reg = <0x4a00821c 0x4>;
+	bit-mask = <0x80>;
+};
+
 apll_pcie_ck: apll_pcie_ck at 4a008200 {
 	#clock-cells = <0>;
-	compatible = "ti,omap4-dpll-clock";
-	clocks = <&dpll_pcie_ref_ck>;
-	reg = <0x4a008200 0x4>, <0x4a008204 0x4>, <0x4a008208 0x4>, <0x4a00820c 0x4>;
-	ti,clk-ref = <&dpll_pcie_ref_ck>;
+	clocks = <&apll_pcie_in_clk_mux>;
+	reg = <0x4a00821c 0x4>, <0x4a008220 0x4>;
 	ti,clk-bypass = <&dpll_pcie_ref_ck>;
+	ti,clk-ref = <&apll_pcie_in_clk_mux>;
+	compatible = "ti,dra7-apll-clock";
 };
 
 apll_pcie_clkvcoldo: apll_pcie_clkvcoldo {
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:28 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:28 +0300
Subject: [PATCHv4 33/33] clk: DTS: DRA7: Add PCIe related clock nodes
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-34-git-send-email-t-kristo@ti.com>

From: Keerthy <j-keerthy at ti.com>

This patch adds optfclk_pciephy_clk and optfclk_pciephy_div_clk
which are used by PCIe phy. It also adds a mux clock to choose
the source of optfclk_pciephy_div_clk clock.

Signed-off-by: Keerthy <j-keerthy at ti.com>
---
 arch/arm/boot/dts/dra7xx-clocks.dtsi |   24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index fcc14d4..32b9985 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -2087,3 +2087,27 @@ vip3_gclk_mux: vip3_gclk_mux at 4a009030 {
 	reg = <0x4a009030 0x4>;
 	bit-mask = <0x1>;
 };
+
+optfclk_pciephy_div: optfclk_pciephy_div at 4a00821c {
+	compatible = "divider-clock";
+	clocks = <&apll_pcie_ck>;
+	#clock-cells = <0>;
+	reg = <0x4a00821c 0x4>;
+	bit-mask = <0x100>;
+};
+
+optfclk_pciephy_clk: optfclk_pciephy_clk at 4a0093b0 {
+	compatible = "gate-clock";
+	clocks = <&apll_pcie_ck>;
+	#clock-cells = <0>;
+	reg = <0x4a0093b0 0x4>;
+	bit-shift = <9>;
+};
+
+optfclk_pciephy_div_clk: optfclk_pciephy_div_clk at 4a0093b0 {
+	compatible = "gate-clock";
+	clocks = <&optfclk_pciephy_div>;
+	#clock-cells = <0>;
+	reg = <0x4a0093b0 0x4>;
+	bit-shift = <10>;
+};
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:25 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:25 +0300
Subject: [PATCHv4 30/33] clk: OMAP: DRA7: Add APLL support
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-31-git-send-email-t-kristo@ti.com>

From: Keerthy <j-keerthy at ti.com>

The patch adds support for DRA7 PCIe APLL. The APLL
sources the optional functional clocks for PCIe module.

APLL stands for Analog PLL. This is different when comapred
with DPLL meaning Digital PLL, the phase detection is done
using an analog circuit.

Signed-off-by: Keerthy <j-keerthy at ti.com>
---
 arch/arm/mach-omap2/clock.h |    1 -
 drivers/clk/omap/Makefile   |    3 +-
 drivers/clk/omap/apll.c     |  213 +++++++++++++++++++++++++++++++++++++++++++
 drivers/clk/omap/clk.c      |    1 +
 include/linux/clk/omap.h    |    3 +
 5 files changed, 219 insertions(+), 2 deletions(-)
 create mode 100644 drivers/clk/omap/apll.c

diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 949d293..5f1c7d4 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -38,7 +38,6 @@ struct omap_clk {
 	}
 
 struct clockdomain;
-#define to_clk_hw_omap(_hw) container_of(_hw, struct clk_hw_omap, hw)
 
 #define DEFINE_STRUCT_CLK(_name, _parent_array_name, _clkops_name)	\
 	static struct clk _name = {				\
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 85b0dc7..6bceb27 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1,3 +1,4 @@
 obj-y					+= clk.o dpll.o autoidle.o gate.o \
 					   clk-44xx.o clk-54xx.o clk-7xx.o \
-					   clk-33xx.o interface.o clk-3xxx.o
+					   clk-33xx.o interface.o clk-3xxx.o \
+					   apll.o
diff --git a/drivers/clk/omap/apll.c b/drivers/clk/omap/apll.c
new file mode 100644
index 0000000..3a216b8
--- /dev/null
+++ b/drivers/clk/omap/apll.c
@@ -0,0 +1,213 @@
+/*
+ * OMAP APLL clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * J Keerthy <j-keerthy at ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/string.h>
+#include <linux/log2.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/clk/omap.h>
+#include <linux/delay.h>
+
+#define APLL_FORCE_LOCK 0x1
+#define APLL_AUTO_IDLE	0x2
+#define MAX_APLL_WAIT_TRIES		1000000
+
+int dra7_apll_enable(struct clk_hw *hw)
+{
+	struct clk_hw_omap *clk = to_clk_hw_omap(hw);
+	int r = 0, i = 0;
+	struct dpll_data *ad;
+	const char *clk_name;
+	u8 state = 1;
+	u32 v;
+
+	ad = clk->dpll_data;
+	if (!ad)
+		return -EINVAL;
+
+	clk_name = __clk_get_name(clk->hw.clk);
+
+	state <<= __ffs(ad->idlest_mask);
+
+	/* Check is already locked */
+	if ((__raw_readl(ad->idlest_reg) & ad->idlest_mask) == state)
+		return r;
+
+	v = __raw_readl(ad->control_reg);
+	v &= ~ad->enable_mask;
+	v |= APLL_FORCE_LOCK << __ffs(ad->enable_mask);
+	__raw_writel(v, ad->control_reg);
+
+	state <<= __ffs(ad->idlest_mask);
+
+	while (((__raw_readl(ad->idlest_reg) & ad->idlest_mask) != state) &&
+	       i < MAX_APLL_WAIT_TRIES) {
+		i++;
+		udelay(1);
+	}
+
+	if (i == MAX_APLL_WAIT_TRIES) {
+		pr_warn("clock: %s failed transition to '%s'\n",
+		       clk_name, (state) ? "locked" : "bypassed");
+	} else {
+		pr_debug("clock: %s transition to '%s' in %d loops\n",
+			 clk_name, (state) ? "locked" : "bypassed", i);
+
+		r = 0;
+	}
+
+	return r;
+}
+
+void dra7_apll_disable(struct clk_hw *hw)
+{
+	struct clk_hw_omap *clk = to_clk_hw_omap(hw);
+	struct dpll_data *ad;
+	u8 state = 1;
+	u32 v;
+
+	ad = clk->dpll_data;
+
+	state <<= __ffs(ad->idlest_mask);
+
+	v = __raw_readl(ad->control_reg);
+	v &= ~ad->enable_mask;
+	v |= APLL_AUTO_IDLE << __ffs(ad->enable_mask);
+	__raw_writel(v, ad->control_reg);
+}
+
+u8 dra7_init_apll_parent(struct clk_hw *hw)
+{
+	return 0;
+}
+
+static const struct clk_ops apll_ck_ops = {
+	.enable		= &dra7_apll_enable,
+	.disable	= &dra7_apll_disable,
+	.get_parent	= &dra7_init_apll_parent,
+};
+
+struct clk *omap_clk_register_apll(struct device *dev, const char *name,
+		const char **parent_names, int num_parents, unsigned long flags,
+		struct dpll_data *dpll_data, const char *clkdm_name,
+		const struct clk_ops *ops)
+{
+	struct clk *clk;
+	struct clk_init_data init;
+	struct clk_hw_omap *clk_hw;
+
+	clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+	if (!clk_hw) {
+		pr_err("%s: could not allocate clk_hw_omap\n", __func__);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	clk_hw->dpll_data = dpll_data;
+	clk_hw->hw.init = &init;
+
+	init.name = name;
+	init.ops = ops;
+	init.flags = flags;
+	init.parent_names = parent_names;
+	init.num_parents = num_parents;
+
+	/* register the clock */
+	clk = clk_register(dev, &clk_hw->hw);
+
+	return clk;
+}
+
+#ifdef CONFIG_OF
+
+__init void of_dra7_apll_setup(struct device_node *node)
+{
+	const struct clk_ops *ops;
+	struct clk *clk;
+	const char *clk_name = node->name;
+	int num_parents;
+	const char **parent_names;
+	struct of_phandle_args clkspec;
+	u8 apll_flags = 0;
+	struct dpll_data *ad;
+	u32 idlest_mask = 0x1;
+	u32 autoidle_mask = 0x3;
+	int i;
+
+	ops = &apll_ck_ops;
+	ad = kzalloc(sizeof(struct dpll_data), GFP_KERNEL);
+	if (!ad) {
+		pr_err("%s: could not allocate dpll_data\n", __func__);
+		return;
+	}
+
+	of_property_read_string(node, "clock-output-names", &clk_name);
+
+	num_parents = of_clk_get_parent_count(node);
+	if (num_parents < 1) {
+		pr_err("%s: omap dpll %s must have parent(s)\n",
+			__func__, node->name);
+		goto cleanup;
+	}
+
+	parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
+
+	for (i = 0; i < num_parents; i++)
+		parent_names[i] = of_clk_get_parent_name(node, i);
+
+	clkspec.np = of_parse_phandle(node, "ti,clk-ref", 0);
+	ad->clk_ref = of_clk_get_from_provider(&clkspec);
+	if (!ad->clk_ref) {
+		pr_err("%s: ti,clk-ref for %s not found\n", __func__,
+			clk_name);
+		goto cleanup;
+	}
+
+	clkspec.np = of_parse_phandle(node, "ti,clk-bypass", 0);
+	ad->clk_bypass = of_clk_get_from_provider(&clkspec);
+	if (!ad->clk_bypass) {
+		pr_err("%s: ti,clk-bypass for %s not found\n", __func__,
+			clk_name);
+		goto cleanup;
+	}
+
+	ad->control_reg = of_iomap(node, 0);
+	ad->idlest_reg = of_iomap(node, 1);
+
+	ad->idlest_mask = idlest_mask;
+	ad->enable_mask = autoidle_mask;
+
+	clk = omap_clk_register_apll(NULL, clk_name, parent_names,
+				num_parents, apll_flags, ad,
+				NULL, ops);
+
+	if (!IS_ERR(clk))
+		of_clk_add_provider(node, of_clk_src_simple_get, clk);
+	return;
+
+cleanup:
+	kfree(ad);
+	return;
+
+}
+EXPORT_SYMBOL_GPL(of_dra7_apll_setup);
+CLK_OF_DECLARE(dra7_apll_clock, "ti,dra7-apll-clock", of_dra7_apll_setup);
+#endif
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index 5cbefde..476f6cb 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -29,6 +29,7 @@ static const struct of_device_id clk_match[] = {
 	{.compatible = "divider-clock", .data = of_omap_divider_setup, },
 	{.compatible = "gate-clock", .data = of_gate_clk_setup, },
 	{.compatible = "ti,omap4-dpll-clock", .data = of_omap4_dpll_setup, },
+	{.compatible = "ti,dra7-apll-clock", .data = of_dra7_apll_setup, },
 	{.compatible = "ti,gate-clock", .data = of_omap_gate_clk_setup, },
 	{.compatible = "ti,interface-clock",
 		.data = of_omap_interface_clk_setup, },
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
index 35008d9..0d70cd1 100644
--- a/include/linux/clk/omap.h
+++ b/include/linux/clk/omap.h
@@ -162,6 +162,8 @@ struct omap_dt_clk {
 		.node_name = name,	\
 	}
 
+#define to_clk_hw_omap(_hw) container_of(_hw, struct clk_hw_omap, hw)
+
 void omap2_init_clk_hw_omap_clocks(struct clk *clk);
 int omap3_noncore_dpll_enable(struct clk_hw *hw);
 void omap3_noncore_dpll_disable(struct clk_hw *hw);
@@ -209,6 +211,7 @@ extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_hsotgusb_wait;
 int dt_omap_clk_init(void);
 extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int cnt);
 void of_omap4_dpll_setup(struct device_node *node);
+void of_dra7_apll_setup(struct device_node *node);
 void of_omap3_dpll_setup(struct device_node *node);
 void of_omap_fixed_factor_setup(struct device_node *node);
 void of_omap_divider_setup(struct device_node *node);
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:27 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:27 +0300
Subject: [PATCHv4 32/33] clk: OMAP: DRA7: Change apll_pcie_m2_ck to fixed
 factor clock
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-33-git-send-email-t-kristo@ti.com>

From: Keerthy <j-keerthy at ti.com>

This patch changes apll_pcie_m2_ck to fixed factor
clock as there are no configurable divider associated to m2.

Signed-off-by: Keerthy <j-keerthy at ti.com>
---
 arch/arm/boot/dts/dra7xx-clocks.dtsi |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index e923311..fcc14d4 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -366,13 +366,10 @@ apll_pcie_clkvcoldo_div: apll_pcie_clkvcoldo_div {
 
 apll_pcie_m2_ck: apll_pcie_m2_ck at 4a008224 {
 	#clock-cells = <0>;
-	compatible = "divider-clock";
+	compatible = "fixed-factor-clock";
 	clocks = <&apll_pcie_ck>;
-	ti,autoidle-shift = <8>;
-	reg = <0x4a008224 0x4>;
-	bit-mask = <0x7f>;
-	index-starts-at-one;
-	ti,autoidle-low;
+	clock-mult = <1>;
+	clock-div = <1>;
 };
 
 sys_clk1_dclk_div: sys_clk1_dclk_div at 4ae061c8 {
-- 
1.7.9.5



From t-kristo at ti.com  Tue Jul 23 03:20:23 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 10:20:23 +0300
Subject: [PATCHv4 28/33] ARM: dts: omap3 clock data
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <1374564028-11352-29-git-send-email-t-kristo@ti.com>

This patch creates a unique node for each clock in the OMAP3 power,
reset and clock manager (PRCM).

TODO: add still missing am35xx only clock nodes

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
 arch/arm/boot/dts/omap3.dtsi                       |    7 +
 arch/arm/boot/dts/omap3430es1-clocks.dtsi          |  166 ++
 arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi    |  240 +++
 arch/arm/boot/dts/omap34xx.dtsi                    |    9 +
 .../omap36xx-am35xx-omap3430es2plus-clocks.dtsi    |  214 +++
 arch/arm/boot/dts/omap36xx-clocks.dtsi             |   97 ++
 .../boot/dts/omap36xx-omap3430es2plus-clocks.dtsi  |  185 +++
 arch/arm/boot/dts/omap36xx.dtsi                    |   10 +
 arch/arm/boot/dts/omap3xxx-clocks.dtsi             | 1594 ++++++++++++++++++++
 9 files changed, 2522 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap3430es1-clocks.dtsi
 create mode 100644 arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
 create mode 100644 arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
 create mode 100644 arch/arm/boot/dts/omap36xx-clocks.dtsi
 create mode 100644 arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi
 create mode 100644 arch/arm/boot/dts/omap3xxx-clocks.dtsi

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..939cc20 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -533,4 +533,11 @@
 			ram-bits = <12>;
 		};
 	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/include/ "omap3xxx-clocks.dtsi"
+	};
 };
diff --git a/arch/arm/boot/dts/omap3430es1-clocks.dtsi b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
new file mode 100644
index 0000000..1d85f45
--- /dev/null
+++ b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
@@ -0,0 +1,166 @@
+/*
+ * Device Tree Source for OMAP3430 ES1 clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+gfx_l3_fck: gfx_l3_fck at 48004b40 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&l3_ick>;
+	reg = <0x48004b40 0x4>;
+	bit-mask = <0x7>;
+	index-starts-at-one;
+};
+
+gfx_l3_ck: gfx_l3_ck {
+	#clock-cells = <0>;
+	compatible = ;
+};
+
+gfx_l3_ick: gfx_l3_ick {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&gfx_l3_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+gfx_cg1_ck: gfx_cg1_ck at 48004b00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&gfx_l3_fck>;
+	reg = <0x48004b00 0x4>;
+	ti,clkdm-name = "gfx_3430es1_clkdm";
+	ti,enable-bit = <1>;
+};
+
+gfx_cg2_ck: gfx_cg2_ck at 48004b00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&gfx_l3_fck>;
+	reg = <0x48004b00 0x4>;
+	ti,clkdm-name = "gfx_3430es1_clkdm";
+	ti,enable-bit = <2>;
+};
+
+d2d_26m_fck: d2d_26m_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&sys_ck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "d2d_clkdm";
+	ti,enable-bit = <3>;
+};
+
+fshostusb_fck: fshostusb_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_48m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <5>;
+};
+
+ssi_ssr_div_fck_3430es1: ssi_ssr_div_fck_3430es1 at 48004a40 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&corex2_fck>;
+	bit-shift = <8>;
+	reg = <0x48004a40 0x4>;
+	table = < 1 1 >, < 2 2 >, < 3 3 >, < 4 4 >, < 6 6 >, < 8 8 >;
+	bit-mask = <0xf>;
+};
+
+ssi_ssr_fck_3430es1: ssi_ssr_fck_3430es1 at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&ssi_ssr_div_fck_3430es1>;
+	bit-shift = <0>;
+	reg = <0x48004a00 0x4>;
+};
+
+ssi_sst_fck_3430es1: ssi_sst_fck_3430es1 {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&ssi_ssr_fck_3430es1>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+hsotgusb_ick_3430es1: hsotgusb_ick_3430es1 at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l3_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l3_clkdm";
+	ti,enable-bit = <4>;
+	ti,iclk-no-wait;
+};
+
+fac_ick: fac_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <8>;
+};
+
+ssi_l4_ick: ssi_l4_ick {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&l4_ick>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+ssi_ick_3430es1: ssi_ick_3430es1 at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&ssi_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <0>;
+	ti,iclk-no-wait;
+};
+
+usb_l4_div_ick: usb_l4_div_ick at 48004a40 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&l4_ick>;
+	bit-shift = <4>;
+	reg = <0x48004a40 0x4>;
+	bit-mask = <0x3>;
+	index-starts-at-one;
+};
+
+usb_l4_ick: usb_l4_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&usb_l4_div_ick>;
+	bit-shift = <5>;
+	reg = <0x48004a10 0x4>;
+};
+
+dss1_alwon_fck_3430es1: dss1_alwon_fck_3430es1 at 48004e00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll4_m4x2_ck>;
+	reg = <0x48004e00 0x4>;
+	bit-shift = <0>;
+};
+
+dss_ick_3430es1: dss_ick_3430es1 at 48004e10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&l4_ick>;
+	reg = <0x48004e10 0x4>;
+	ti,clkdm-name = "dss_clkdm";
+	ti,enable-bit = <0>;
+	ti,iclk-no-wait;
+};
diff --git a/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi b/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
new file mode 100644
index 0000000..8da7ba1
--- /dev/null
+++ b/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
@@ -0,0 +1,240 @@
+/*
+ * Device Tree Source for OMAP34xx/OMAP36xx clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+security_l4_ick2: security_l4_ick2 {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&l4_ick>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+aes1_ick: aes1_ick at 48004a14 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&security_l4_ick2>;
+	reg = <0x48004a14 0x4>;
+	ti,enable-bit = <3>;
+};
+
+rng_ick: rng_ick at 48004a14 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&security_l4_ick2>;
+	reg = <0x48004a14 0x4>;
+	ti,enable-bit = <2>;
+};
+
+sha11_ick: sha11_ick at 48004a14 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&security_l4_ick2>;
+	reg = <0x48004a14 0x4>;
+	ti,enable-bit = <1>;
+};
+
+des1_ick: des1_ick at 48004a14 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&security_l4_ick2>;
+	reg = <0x48004a14 0x4>;
+	ti,enable-bit = <0>;
+};
+
+cam_mclk: cam_mclk at 48004f00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll4_m5x2_ck>;
+	bit-shift = <0>;
+	reg = <0x48004f00 0x4>;
+	set-rate-parent;
+};
+
+cam_ick: cam_ick at 48004f10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&l4_ick>;
+	reg = <0x48004f10 0x4>;
+	ti,clkdm-name = "cam_clkdm";
+	ti,enable-bit = <0>;
+	ti,iclk-no-wait;
+};
+
+csi2_96m_fck: csi2_96m_fck at 48004f00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&core_96m_fck>;
+	reg = <0x48004f00 0x4>;
+	bit-shift = <1>;
+};
+
+security_l3_ick: security_l3_ick {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&l3_ick>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+pka_ick: pka_ick at 48004a14 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&security_l3_ick>;
+	reg = <0x48004a14 0x4>;
+	ti,enable-bit = <4>;
+};
+
+icr_ick: icr_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <29>;
+};
+
+des2_ick: des2_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <26>;
+};
+
+mspro_ick: mspro_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <23>;
+};
+
+mailboxes_ick: mailboxes_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <7>;
+};
+
+ssi_l4_ick: ssi_l4_ick {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&l4_ick>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+sr1_fck: sr1_fck at 48004c00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&sys_ck>;
+	reg = <0x48004c00 0x4>;
+	ti,clkdm-name = "wkup_clkdm";
+	ti,enable-bit = <6>;
+};
+
+sr2_fck: sr2_fck at 48004c00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&sys_ck>;
+	reg = <0x48004c00 0x4>;
+	ti,clkdm-name = "wkup_clkdm";
+	ti,enable-bit = <7>;
+};
+
+sr_l4_ick: sr_l4_ick {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&l4_ick>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll2_fck: dpll2_fck at 48004040 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&core_ck>;
+	bit-shift = <19>;
+	reg = <0x48004040 0x4>;
+	bit-mask = <0x7>;
+	index-starts-at-one;
+};
+
+dpll2_ck: dpll2_ck at 48004004 {
+	#clock-cells = <0>;
+	compatible = "ti,omap3-dpll-clock";
+	clocks = <&sys_ck>;
+	ti,modes = <0xa2>;
+	ti,clk-bypass = <&dpll2_fck>;
+	reg = <0x48004004 0x4>, <0x48004024 0x4>, <0x48004034 0x4>, <0x48004040 0x4>;
+	ti,clkdm-name = "dpll2_clkdm";
+	ti,clk-ref = <&sys_ck>;
+	ti,recal-en-bit = <0x8>;
+	ti,auto-recal-bit = <0x3>;
+	ti,recal-st-bit = <0x8>;
+};
+
+dpll2_m2_ck: dpll2_m2_ck at 48004044 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll2_ck>;
+	reg = <0x48004044 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+iva2_ck: iva2_ck at 48004000 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&dpll2_m2_ck>;
+	reg = <0x48004000 0x4>;
+	ti,clkdm-name = "iva2_clkdm";
+	ti,enable-bit = <0>;
+};
+
+modem_fck: modem_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&sys_ck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "d2d_clkdm";
+	ti,enable-bit = <31>;
+};
+
+sad2d_ick: sad2d_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&l3_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "d2d_clkdm";
+	ti,enable-bit = <3>;
+};
+
+mad2d_ick: mad2d_ick at 48004a18 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&l3_ick>;
+	reg = <0x48004a18 0x4>;
+	ti,clkdm-name = "d2d_clkdm";
+	ti,enable-bit = <3>;
+};
+
+mspro_fck: mspro_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_96m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <23>;
+};
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 5355d61..5f3c2ca 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -25,4 +25,13 @@
 			clock-latency = <300000>; /* From legacy driver */
 		};
 	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/include/ "omap34xx-omap36xx-clocks.dtsi"
+		/include/ "omap36xx-omap3430es2plus-clocks.dtsi"
+		/include/ "omap36xx-am35xx-omap3430es2plus-clocks.dtsi"
+	};
 };
diff --git a/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi b/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
new file mode 100644
index 0000000..e0bdfb3
--- /dev/null
+++ b/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
@@ -0,0 +1,214 @@
+/*
+ * Device Tree Source for OMAP36xx/AM35xx/OMAP34xx clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+dpll5_ck: dpll5_ck at 48004d04 {
+	#clock-cells = <0>;
+	compatible = "ti,omap3-dpll-clock";
+	clocks = <&sys_ck>;
+	ti,modes = <0x82>;
+	ti,clk-bypass = <&sys_ck>;
+	reg = <0x48004d04 0x4>, <0x48004d24 0x4>, <0x48004d34 0x4>, <0x48004d4c 0x4>;
+	ti,clkdm-name = "dpll5_clkdm";
+	ti,clk-ref = <&sys_ck>;
+	ti,recal-en-bit = <0x19>;
+	ti,auto-recal-bit = <0x3>;
+	ti,recal-st-bit = <0x19>;
+};
+
+dpll5_m2_ck: dpll5_m2_ck at 48004d50 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll5_ck>;
+	reg = <0x48004d50 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+core_d3_ck: core_d3_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&core_ck>;
+	clock-mult = <1>;
+	clock-div = <3>;
+};
+
+core_d4_ck: core_d4_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&core_ck>;
+	clock-mult = <1>;
+	clock-div = <4>;
+};
+
+core_d6_ck: core_d6_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&core_ck>;
+	clock-mult = <1>;
+	clock-div = <6>;
+};
+
+omap_192m_alwon_fck: omap_192m_alwon_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll4_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+core_d2_ck: core_d2_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&core_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+corex2_d3_fck: corex2_d3_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&corex2_fck>;
+	clock-mult = <1>;
+	clock-div = <3>;
+};
+
+corex2_d5_fck: corex2_d5_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&corex2_fck>;
+	clock-mult = <1>;
+	clock-div = <5>;
+};
+
+sgx_mux_fck: sgx_mux_fck at 48004b40 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&core_d3_ck>, <&core_d4_ck>, <&core_d6_ck>, <&cm_96m_fck>, <&omap_192m_alwon_fck>, <&core_d2_ck>, <&corex2_d3_fck>, <&corex2_d5_fck>;
+	reg = <0x48004b40 0x4>;
+	table = <&core_d3_ck 0>, <&core_d4_ck 1>, <&core_d6_ck 2>, <&cm_96m_fck 3>, <&omap_192m_alwon_fck 4>, <&core_d2_ck 5>, <&corex2_d3_fck 6>, <&corex2_d5_fck 7>;
+	bit-mask = <0x7>;
+};
+
+sgx_fck: sgx_fck at 48004b00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sgx_mux_fck>;
+	bit-shift = <1>;
+	reg = <0x48004b00 0x4>;
+};
+
+sgx_ick: sgx_ick at 48004b10 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&l3_ick>;
+	reg = <0x48004b10 0x4>;
+	ti,clkdm-name = "sgx_clkdm";
+	ti,enable-bit = <0>;
+};
+
+cpefuse_fck: cpefuse_fck at 48004a08 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_ck>;
+	reg = <0x48004a08 0x4>;
+	bit-shift = <0>;
+};
+
+ts_fck: ts_fck at 48004a08 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&omap_32k_fck>;
+	reg = <0x48004a08 0x4>;
+	bit-shift = <1>;
+};
+
+usbtll_fck: usbtll_fck at 48004a08 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&dpll5_m2_ck>;
+	reg = <0x48004a08 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <2>;
+};
+
+usbtll_ick: usbtll_ick at 48004a18 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a18 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <2>;
+};
+
+mmchs3_ick: mmchs3_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <30>;
+};
+
+mmchs3_fck: mmchs3_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_96m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <30>;
+};
+
+dss1_alwon_fck_3430es2: dss1_alwon_fck_3430es2 at 48004e00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&dpll4_m4x2_ck>;
+	reg = <0x48004e00 0x4>;
+	ti,clkdm-name = "dss_clkdm";
+	ti,enable-bit = <0>;
+	ti,dss-clk;
+};
+
+dss_ick_3430es2: dss_ick_3430es2 at 48004e10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&l4_ick>;
+	reg = <0x48004e10 0x4>;
+	ti,clkdm-name = "dss_clkdm";
+	ti,enable-bit = <0>;
+	ti,iclk-dss;
+};
+
+usbhost_120m_fck: usbhost_120m_fck at 48005400 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll5_m2_ck>;
+	reg = <0x48005400 0x4>;
+	bit-shift = <1>;
+};
+
+usbhost_48m_fck: usbhost_48m_fck at 48005400 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&omap_48m_fck>;
+	reg = <0x48005400 0x4>;
+	ti,clkdm-name = "usbhost_clkdm";
+	ti,enable-bit = <0>;
+	ti,dss-clk;
+};
+
+usbhost_ick: usbhost_ick at 48005410 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&l4_ick>;
+	reg = <0x48005410 0x4>;
+	ti,clkdm-name = "usbhost_clkdm";
+	ti,enable-bit = <0>;
+	ti,iclk-dss;
+};
diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi b/arch/arm/boot/dts/omap36xx-clocks.dtsi
new file mode 100644
index 0000000..a52faa4
--- /dev/null
+++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
@@ -0,0 +1,97 @@
+/*
+ * Device Tree Source for OMAP36xx clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+dpll4_ck: dpll4_ck at 48004d00 {
+	#clock-cells = <0>;
+	compatible = "ti,omap3-dpll-clock";
+	clocks = <&sys_ck>;
+	ti,autoidle-mask = <0x38>;
+	ti,idlest-mask = <0x2>;
+	ti,clkdm-name = "dpll4_clkdm";
+	ti,recal-en-bit = <0x6>;
+	ti,auto-recal-bit = <0x13>;
+	ti,enable-mask = <0x70000>;
+	ti,recal-st-bit = <0x6>;
+	ti,clk-bypass = <&sys_ck>;
+	ti,modes = <0x82>;
+	ti,dco-mask = <0xe00000>;
+	reg = <0x48004d00 0x4>, <0x48004d20 0x4>, <0x48004d30 0x4>, <0x48004d44 0x4>;
+	ti,clk-ref = <&sys_ck>;
+	ti,dpll-j-type;
+	ti,dpll-peripheral;
+};
+
+dpll4_m2x2_ck: dpll4_m2x2_ck at 48004d00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&dpll4_m2x2_mul_ck>;
+	bit-shift = <0x1b>;
+	reg = <0x48004d00 0x4>;
+	set-bit-to-disable;
+	ti,hsdiv-restore;
+};
+
+dpll3_m3x2_ck: dpll3_m3x2_ck at 48004d00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&dpll3_m3x2_mul_ck>;
+	bit-shift = <0xc>;
+	reg = <0x48004d00 0x4>;
+	set-bit-to-disable;
+	ti,hsdiv-restore;
+};
+
+dpll4_m3x2_ck: dpll4_m3x2_ck at 48004d00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&dpll4_m3x2_mul_ck>;
+	bit-shift = <0x1c>;
+	reg = <0x48004d00 0x4>;
+	set-bit-to-disable;
+	ti,hsdiv-restore;
+};
+
+dpll4_m5x2_ck: dpll4_m5x2_ck at 48004d00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&dpll4_m5x2_mul_ck>;
+	bit-shift = <0x1e>;
+	reg = <0x48004d00 0x4>;
+	ti,hsdiv-restore;
+	set-rate-parent;
+	set-bit-to-disable;
+};
+
+dpll4_m6x2_ck: dpll4_m6x2_ck at 48004d00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&dpll4_m6x2_mul_ck>;
+	bit-shift = <0x1f>;
+	reg = <0x48004d00 0x4>;
+	set-bit-to-disable;
+	ti,hsdiv-restore;
+};
+
+omap_192m_alwon_fck: omap_192m_alwon_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll4_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+uart4_fck: uart4_fck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&per_48m_fck>;
+	reg = <0x48005000 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <18>;
+};
diff --git a/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi b/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi
new file mode 100644
index 0000000..0b93647
--- /dev/null
+++ b/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi
@@ -0,0 +1,185 @@
+/*
+ * Device Tree Source for OMAP34xx/OMAP36xx clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+ssi_ssr_div_fck_3430es2: ssi_ssr_div_fck_3430es2 at 48004a40 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&corex2_fck>;
+	bit-shift = <8>;
+	reg = <0x48004a40 0x4>;
+	table = < 1 1 >, < 2 2 >, < 3 3 >, < 4 4 >, < 6 6 >, < 8 8 >;
+	bit-mask = <0xf>;
+};
+
+ssi_ssr_fck_3430es2: ssi_ssr_fck_3430es2 at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&ssi_ssr_div_fck_3430es2>;
+	bit-shift = <0>;
+	reg = <0x48004a00 0x4>;
+};
+
+ssi_sst_fck_3430es2: ssi_sst_fck_3430es2 {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&ssi_ssr_fck_3430es2>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+hsotgusb_ick_3430es2: hsotgusb_ick_3430es2 at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l3_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l3_clkdm";
+	ti,enable-bit = <4>;
+	ti,iclk-hsotgusb;
+};
+
+ssi_l4_ick: ssi_l4_ick {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&l4_ick>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+ssi_ick_3430es2: ssi_ick_3430es2 at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&ssi_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <0>;
+	ti,iclk-ssi;
+};
+
+dpll5_ck: dpll5_ck at 48004d04 {
+	#clock-cells = <0>;
+	compatible = "ti,omap3-dpll-clock";
+	clocks = <&sys_ck>;
+	ti,modes = <0x82>;
+	ti,clk-bypass = <&sys_ck>;
+	reg = <0x48004d04 0x4>, <0x48004d24 0x4>, <0x48004d34 0x4>, <0x48004d4c 0x4>;
+	ti,clkdm-name = "dpll5_clkdm";
+	ti,clk-ref = <&sys_ck>;
+	ti,recal-en-bit = <0x19>;
+	ti,auto-recal-bit = <0x3>;
+	ti,recal-st-bit = <0x19>;
+};
+
+dpll5_m2_ck: dpll5_m2_ck at 48004d50 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll5_ck>;
+	reg = <0x48004d50 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+dpll5_m2_d20_ck: dpll5_m2_d20_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll5_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <20>;
+};
+
+sys_d2_ck: sys_d2_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_ck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+omap_96m_d2_fck: omap_96m_d2_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&omap_96m_fck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+omap_96m_d4_fck: omap_96m_d4_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&omap_96m_fck>;
+	clock-mult = <1>;
+	clock-div = <4>;
+};
+
+omap_96m_d8_fck: omap_96m_d8_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&omap_96m_fck>;
+	clock-mult = <1>;
+	clock-div = <8>;
+};
+
+omap_96m_d10_fck: omap_96m_d10_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&omap_96m_fck>;
+	clock-mult = <1>;
+	clock-div = <10>;
+};
+
+dpll5_m2_d4_ck: dpll5_m2_d4_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll5_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <4>;
+};
+
+dpll5_m2_d8_ck: dpll5_m2_d8_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll5_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <8>;
+};
+
+dpll5_m2_d16_ck: dpll5_m2_d16_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll5_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <16>;
+};
+
+usim_mux_fck: usim_mux_fck at 48004c40 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_ck>, <&dpll5_m2_d20_ck>, <&sys_d2_ck>, <&omap_96m_d2_fck>, <&omap_96m_d4_fck>, <&omap_96m_d8_fck>, <&omap_96m_d10_fck>, <&dpll5_m2_d4_ck>, <&dpll5_m2_d8_ck>, <&dpll5_m2_d16_ck>;
+	bit-shift = <3>;
+	reg = <0x48004c40 0x4>;
+	table = <&sys_ck 1>, <&dpll5_m2_d20_ck 10>, <&sys_d2_ck 2>, <&omap_96m_d2_fck 3>, <&omap_96m_d4_fck 4>, <&omap_96m_d8_fck 5>, <&omap_96m_d10_fck 6>, <&dpll5_m2_d4_ck 7>, <&dpll5_m2_d8_ck 8>, <&dpll5_m2_d16_ck 9>;
+	bit-mask = <0xf>;
+};
+
+usim_fck: usim_fck at 48004c00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&usim_mux_fck>;
+	bit-shift = <9>;
+	reg = <0x48004c00 0x4>;
+};
+
+usim_ick: usim_ick at 48004c10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&wkup_l4_ick>;
+	reg = <0x48004c10 0x4>;
+	ti,clkdm-name = "wkup_clkdm";
+	ti,enable-bit = <9>;
+};
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index f8b3765..583c212 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -35,4 +35,14 @@
 			clock-frequency = <48000000>;
 		};
 	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/include/ "omap36xx-clocks.dtsi"
+		/include/ "omap34xx-omap36xx-clocks.dtsi"
+		/include/ "omap36xx-omap3430es2plus-clocks.dtsi"
+		/include/ "omap36xx-am35xx-omap3430es2plus-clocks.dtsi"
+	};
 };
diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
new file mode 100644
index 0000000..18a723f
--- /dev/null
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -0,0 +1,1594 @@
+/*
+ * Device Tree Source for OMAP3 clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+dummy_apb_pclk: dummy_apb_pclk {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0x0>;
+};
+
+omap_32k_fck: omap_32k_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <32768>;
+};
+
+virt_12m_ck: virt_12m_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <12000000>;
+};
+
+virt_13m_ck: virt_13m_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <13000000>;
+};
+
+virt_19200000_ck: virt_19200000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <19200000>;
+};
+
+virt_26000000_ck: virt_26000000_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <26000000>;
+};
+
+virt_38_4m_ck: virt_38_4m_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <38400000>;
+};
+
+virt_16_8m_ck: virt_16_8m_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <16800000>;
+};
+
+osc_sys_ck: osc_sys_ck at 48306d40 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&virt_12m_ck>, <&virt_13m_ck>, <&virt_19200000_ck>, <&virt_26000000_ck>, <&virt_38_4m_ck>, <&virt_16_8m_ck>;
+	reg = <0x48306d40 0x4>;
+	bit-mask = <0x7>;
+};
+
+sys_ck: sys_ck at 48307270 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&osc_sys_ck>;
+	bit-shift = <6>;
+	reg = <0x48307270 0x4>;
+	bit-mask = <0x3>;
+	index-starts-at-one;
+};
+
+dpll4_ck: dpll4_ck at 48004d00 {
+	#clock-cells = <0>;
+	compatible = "ti,omap3-dpll-clock";
+	clocks = <&sys_ck>;
+	ti,autoidle-mask = <0x38>;
+	ti,modes = <0x82>;
+	ti,clk-bypass = <&sys_ck>;
+	ti,idlest-mask = <0x2>;
+	reg = <0x48004d00 0x4>, <0x48004d20 0x4>, <0x48004d30 0x4>, <0x48004d44 0x4>;
+	ti,clkdm-name = "dpll4_clkdm";
+	ti,clk-ref = <&sys_ck>;
+	ti,recal-en-bit = <0x6>;
+	ti,auto-recal-bit = <0x13>;
+	ti,enable-mask = <0x70000>;
+	ti,recal-st-bit = <0x6>;
+	ti,dpll-peripheral;
+};
+
+dpll4_m2_ck: dpll4_m2_ck at 48004d48 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll4_ck>;
+	reg = <0x48004d48 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+};
+
+dpll4_m2x2_mul_ck: dpll4_m2x2_mul_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll4_m2_ck>;
+	clock-mult = <2>;
+	clock-div = <1>;
+};
+
+dpll4_m2x2_ck: dpll4_m2x2_ck at 48004d00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll4_m2x2_mul_ck>;
+	bit-shift = <0x1b>;
+	reg = <0x48004d00 0x4>;
+	set-bit-to-disable;
+};
+
+omap_96m_alwon_fck: omap_96m_alwon_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll4_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll3_ck: dpll3_ck at 48004d00 {
+	#clock-cells = <0>;
+	compatible = "ti,omap3-dpll-clock";
+	clocks = <&sys_ck>;
+	ti,clk-bypass = <&sys_ck>;
+	reg = <0x48004d00 0x4>, <0x48004d20 0x4>, <0x48004d30 0x4>, <0x48004d40 0x4>;
+	ti,clk-ref = <&sys_ck>;
+	ti,clkdm-name = "dpll3_clkdm";
+	ti,recal-en-bit = <0x5>;
+	ti,auto-recal-bit = <0x3>;
+	ti,recal-st-bit = <0x5>;
+	ti,dpll-core;
+};
+
+dpll3_m3_ck: dpll3_m3_ck at 48005140 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll3_ck>;
+	bit-shift = <16>;
+	reg = <0x48005140 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+dpll3_m3x2_mul_ck: dpll3_m3x2_mul_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll3_m3_ck>;
+	clock-mult = <2>;
+	clock-div = <1>;
+};
+
+dpll3_m3x2_ck: dpll3_m3x2_ck at 48004d00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll3_m3x2_mul_ck>;
+	bit-shift = <0xc>;
+	reg = <0x48004d00 0x4>;
+	set-bit-to-disable;
+};
+
+emu_core_alwon_ck: emu_core_alwon_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll3_m3x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+sys_altclk: sys_altclk {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0x0>;
+};
+
+mcbsp_clks: mcbsp_clks {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <0x0>;
+};
+
+sys_clkout1: sys_clkout1 at 48306d70 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&osc_sys_ck>;
+	reg = <0x48306d70 0x4>;
+	bit-shift = <7>;
+};
+
+dpll1_ck: dpll1_ck at 48004904 {
+	#clock-cells = <0>;
+	compatible = "ti,omap3-dpll-clock";
+	clocks = <&sys_ck>;
+	ti,clk-bypass = <&dpll1_fck>;
+	reg = <0x48004904 0x4>, <0x48004924 0x4>, <0x48004934 0x4>, <0x48004940 0x4>;
+	ti,clk-ref = <&sys_ck>;
+	ti,clkdm-name = "dpll1_clkdm";
+	ti,recal-en-bit = <0x7>;
+	ti,auto-recal-bit = <0x3>;
+	ti,recal-st-bit = <0x7>;
+};
+
+dpll1_x2_ck: dpll1_x2_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll1_ck>;
+	clock-mult = <2>;
+	clock-div = <1>;
+};
+
+dpll1_x2m2_ck: dpll1_x2m2_ck at 48004944 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll1_x2_ck>;
+	reg = <0x48004944 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+dpll3_m2_ck: dpll3_m2_ck at 48004d40 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll3_ck>;
+	bit-shift = <27>;
+	reg = <0x48004d40 0x4>;
+	bit-mask = <0x1f>;
+	index-starts-at-one;
+};
+
+core_ck: core_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll3_m2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll3_x2_ck: dpll3_x2_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll3_ck>;
+	clock-mult = <2>;
+	clock-div = <1>;
+};
+
+dpll3_m2x2_ck: dpll3_m2x2_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll3_m2_ck>;
+	clock-mult = <2>;
+	clock-div = <1>;
+};
+
+dpll4_x2_ck: dpll4_x2_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll4_ck>;
+	clock-mult = <2>;
+	clock-div = <1>;
+};
+
+cm_96m_fck: cm_96m_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&omap_96m_alwon_fck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+omap_96m_fck: omap_96m_fck at 48004d40 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&cm_96m_fck>, <&sys_ck>;
+	bit-shift = <6>;
+	reg = <0x48004d40 0x4>;
+	bit-mask = <0x1>;
+};
+
+dpll4_m3_ck: dpll4_m3_ck at 48004e40 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll4_ck>;
+	bit-shift = <8>;
+	reg = <0x48004e40 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+};
+
+dpll4_m3x2_mul_ck: dpll4_m3x2_mul_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll4_m3_ck>;
+	clock-mult = <2>;
+	clock-div = <1>;
+};
+
+dpll4_m3x2_ck: dpll4_m3x2_ck at 48004d00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll4_m3x2_mul_ck>;
+	bit-shift = <0x1c>;
+	reg = <0x48004d00 0x4>;
+	set-bit-to-disable;
+};
+
+omap_54m_fck: omap_54m_fck at 48004d40 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&dpll4_m3x2_ck>, <&sys_altclk>;
+	bit-shift = <5>;
+	reg = <0x48004d40 0x4>;
+	bit-mask = <0x1>;
+};
+
+cm_96m_d2_fck: cm_96m_d2_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&cm_96m_fck>;
+	clock-mult = <1>;
+	clock-div = <2>;
+};
+
+omap_48m_fck: omap_48m_fck at 48004d40 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&cm_96m_d2_fck>, <&sys_altclk>;
+	bit-shift = <3>;
+	reg = <0x48004d40 0x4>;
+	table = <&cm_96m_d2_fck 0>, <&sys_altclk 1>;
+	bit-mask = <0x1>;
+};
+
+omap_12m_fck: omap_12m_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&omap_48m_fck>;
+	clock-mult = <1>;
+	clock-div = <4>;
+};
+
+dpll4_m4_ck: dpll4_m4_ck at 48004e40 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll4_ck>;
+	reg = <0x48004e40 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+};
+
+dpll4_m4x2_mul_ck: dpll4_m4x2_mul_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll4_m4_ck>;
+	clock-mult = <2>;
+	clock-div = <1>;
+};
+
+dpll4_m4x2_ck: dpll4_m4x2_ck at 48004d00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll4_m4x2_mul_ck>;
+	bit-shift = <0x1d>;
+	reg = <0x48004d00 0x4>;
+	set-bit-to-disable;
+};
+
+dpll4_m5_ck: dpll4_m5_ck at 48004f40 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll4_ck>;
+	reg = <0x48004f40 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+};
+
+dpll4_m5x2_mul_ck: dpll4_m5x2_mul_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll4_m5_ck>;
+	clock-mult = <2>;
+	clock-div = <1>;
+};
+
+dpll4_m5x2_ck: dpll4_m5x2_ck at 48004d00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll4_m5x2_mul_ck>;
+	bit-shift = <0x1e>;
+	reg = <0x48004d00 0x4>;
+	set-bit-to-disable;
+};
+
+dpll4_m6_ck: dpll4_m6_ck at 48005140 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&dpll4_ck>;
+	bit-shift = <24>;
+	reg = <0x48005140 0x4>;
+	bit-mask = <0x3f>;
+	index-starts-at-one;
+};
+
+dpll4_m6x2_mul_ck: dpll4_m6x2_mul_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll4_m6_ck>;
+	clock-mult = <2>;
+	clock-div = <1>;
+};
+
+dpll4_m6x2_ck: dpll4_m6x2_ck at 48004d00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&dpll4_m6x2_mul_ck>;
+	bit-shift = <0x1f>;
+	reg = <0x48004d00 0x4>;
+	set-bit-to-disable;
+};
+
+emu_per_alwon_ck: emu_per_alwon_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll4_m6x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+clkout2_src_mux_ck: clkout2_src_mux_ck at 48004d70 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&core_ck>, <&sys_ck>, <&cm_96m_fck>, <&omap_54m_fck>;
+	reg = <0x48004d70 0x4>;
+	bit-mask = <0x3>;
+};
+
+clkout2_src_ck: clkout2_src_ck at 48004d70 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&clkout2_src_mux_ck>;
+	bit-shift = <7>;
+	reg = <0x48004d70 0x4>;
+};
+
+sys_clkout2: sys_clkout2 at 48004d70 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&clkout2_src_ck>;
+	bit-shift = <3>;
+	reg = <0x48004d70 0x4>;
+	bit-mask = <0x7>;
+	index-power-of-two;
+};
+
+corex2_fck: corex2_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll3_m2x2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+dpll1_fck: dpll1_fck at 48004940 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&core_ck>;
+	bit-shift = <19>;
+	reg = <0x48004940 0x4>;
+	bit-mask = <0x7>;
+	index-starts-at-one;
+};
+
+mpu_ck: mpu_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&dpll1_x2m2_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+arm_fck: arm_fck at 48004924 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&mpu_ck>;
+	reg = <0x48004924 0x4>;
+	bit-mask = <0x1>;
+};
+
+emu_mpu_alwon_ck: emu_mpu_alwon_ck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&mpu_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+l3_ick: l3_ick at 48004a40 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&core_ck>;
+	reg = <0x48004a40 0x4>;
+	bit-mask = <0x3>;
+	index-starts-at-one;
+};
+
+l4_ick: l4_ick at 48004a40 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&l3_ick>;
+	bit-shift = <2>;
+	reg = <0x48004a40 0x4>;
+	bit-mask = <0x3>;
+	index-starts-at-one;
+};
+
+rm_ick: rm_ick at 48004c40 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&l4_ick>;
+	bit-shift = <1>;
+	reg = <0x48004c40 0x4>;
+	bit-mask = <0x3>;
+	index-starts-at-one;
+};
+
+gpt10_mux_fck: gpt10_mux_fck at 48004a40 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&omap_32k_fck>, <&sys_ck>;
+	bit-shift = <6>;
+	reg = <0x48004a40 0x4>;
+	bit-mask = <0x1>;
+};
+
+gpt10_fck: gpt10_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&gpt10_mux_fck>;
+	bit-shift = <11>;
+	reg = <0x48004a00 0x4>;
+};
+
+gpt11_mux_fck: gpt11_mux_fck at 48004a40 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&omap_32k_fck>, <&sys_ck>;
+	bit-shift = <7>;
+	reg = <0x48004a40 0x4>;
+	bit-mask = <0x1>;
+};
+
+gpt11_fck: gpt11_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&gpt11_mux_fck>;
+	bit-shift = <12>;
+	reg = <0x48004a00 0x4>;
+};
+
+core_96m_fck: core_96m_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&omap_96m_fck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+mmchs2_fck: mmchs2_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_96m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <25>;
+};
+
+mmchs1_fck: mmchs1_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_96m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <24>;
+};
+
+i2c3_fck: i2c3_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_96m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <17>;
+};
+
+i2c2_fck: i2c2_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_96m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <16>;
+};
+
+i2c1_fck: i2c1_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_96m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <15>;
+};
+
+mcbsp5_mux_fck: mcbsp5_mux_fck at 480022d8 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&core_96m_fck>, <&mcbsp_clks>;
+	bit-shift = <4>;
+	reg = <0x480022d8 0x4>;
+	bit-mask = <0x1>;
+};
+
+mcbsp5_fck: mcbsp5_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&mcbsp5_mux_fck>;
+	bit-shift = <10>;
+	reg = <0x48004a00 0x4>;
+};
+
+mcbsp1_mux_fck: mcbsp1_mux_fck at 48002274 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&core_96m_fck>, <&mcbsp_clks>;
+	bit-shift = <2>;
+	reg = <0x48002274 0x4>;
+	bit-mask = <0x1>;
+};
+
+mcbsp1_fck: mcbsp1_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&mcbsp1_mux_fck>;
+	bit-shift = <9>;
+	reg = <0x48004a00 0x4>;
+};
+
+core_48m_fck: core_48m_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&omap_48m_fck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+mcspi4_fck: mcspi4_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_48m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <21>;
+};
+
+mcspi3_fck: mcspi3_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_48m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <20>;
+};
+
+mcspi2_fck: mcspi2_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_48m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <19>;
+};
+
+mcspi1_fck: mcspi1_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_48m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <18>;
+};
+
+uart2_fck: uart2_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_48m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <14>;
+};
+
+uart1_fck: uart1_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_48m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <13>;
+};
+
+core_12m_fck: core_12m_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&omap_12m_fck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+hdq_fck: hdq_fck at 48004a00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_12m_fck>;
+	reg = <0x48004a00 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <22>;
+};
+
+core_l3_ick: core_l3_ick {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&l3_ick>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+sdrc_ick: sdrc_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&core_l3_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l3_clkdm";
+	ti,enable-bit = <1>;
+};
+
+gpmc_fck: gpmc_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&core_l3_ick>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+core_l4_ick: core_l4_ick {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&l4_ick>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+mmchs2_ick: mmchs2_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <25>;
+};
+
+mmchs1_ick: mmchs1_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <24>;
+};
+
+hdq_ick: hdq_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <22>;
+};
+
+mcspi4_ick: mcspi4_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <21>;
+};
+
+mcspi3_ick: mcspi3_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <20>;
+};
+
+mcspi2_ick: mcspi2_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <19>;
+};
+
+mcspi1_ick: mcspi1_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <18>;
+};
+
+i2c3_ick: i2c3_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <17>;
+};
+
+i2c2_ick: i2c2_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <16>;
+};
+
+i2c1_ick: i2c1_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <15>;
+};
+
+uart2_ick: uart2_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <14>;
+};
+
+uart1_ick: uart1_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <13>;
+};
+
+gpt11_ick: gpt11_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <12>;
+};
+
+gpt10_ick: gpt10_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <11>;
+};
+
+mcbsp5_ick: mcbsp5_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <10>;
+};
+
+mcbsp1_ick: mcbsp1_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <9>;
+};
+
+omapctrl_ick: omapctrl_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <6>;
+};
+
+dss_tv_fck: dss_tv_fck at 48004e00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&omap_54m_fck>;
+	reg = <0x48004e00 0x4>;
+	bit-shift = <2>;
+};
+
+dss_96m_fck: dss_96m_fck at 48004e00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&omap_96m_fck>;
+	reg = <0x48004e00 0x4>;
+	bit-shift = <2>;
+};
+
+dss2_alwon_fck: dss2_alwon_fck at 48004e00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&sys_ck>;
+	reg = <0x48004e00 0x4>;
+	bit-shift = <1>;
+};
+
+gpt1_mux_fck: gpt1_mux_fck at 48004c40 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&omap_32k_fck>, <&sys_ck>;
+	reg = <0x48004c40 0x4>;
+	bit-mask = <0x1>;
+};
+
+gpt1_fck: gpt1_fck at 48004c00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&gpt1_mux_fck>;
+	bit-shift = <0>;
+	reg = <0x48004c00 0x4>;
+};
+
+aes2_ick: aes2_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <28>;
+};
+
+wkup_32k_fck: wkup_32k_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&omap_32k_fck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+gpio1_dbck: gpio1_dbck at 48004c00 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&wkup_32k_fck>;
+	reg = <0x48004c00 0x4>;
+	bit-shift = <3>;
+};
+
+sha12_ick: sha12_ick at 48004a10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&core_l4_ick>;
+	reg = <0x48004a10 0x4>;
+	ti,clkdm-name = "core_l4_clkdm";
+	ti,enable-bit = <27>;
+};
+
+wdt2_fck: wdt2_fck at 48004c00 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&wkup_32k_fck>;
+	reg = <0x48004c00 0x4>;
+	ti,clkdm-name = "wkup_clkdm";
+	ti,enable-bit = <5>;
+};
+
+wkup_l4_ick: wkup_l4_ick {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&sys_ck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+wdt2_ick: wdt2_ick at 48004c10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&wkup_l4_ick>;
+	reg = <0x48004c10 0x4>;
+	ti,clkdm-name = "wkup_clkdm";
+	ti,enable-bit = <5>;
+};
+
+wdt1_ick: wdt1_ick at 48004c10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&wkup_l4_ick>;
+	reg = <0x48004c10 0x4>;
+	ti,clkdm-name = "wkup_clkdm";
+	ti,enable-bit = <4>;
+};
+
+gpio1_ick: gpio1_ick at 48004c10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&wkup_l4_ick>;
+	reg = <0x48004c10 0x4>;
+	ti,clkdm-name = "wkup_clkdm";
+	ti,enable-bit = <3>;
+};
+
+omap_32ksync_ick: omap_32ksync_ick at 48004c10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&wkup_l4_ick>;
+	reg = <0x48004c10 0x4>;
+	ti,clkdm-name = "wkup_clkdm";
+	ti,enable-bit = <2>;
+};
+
+gpt12_ick: gpt12_ick at 48004c10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&wkup_l4_ick>;
+	reg = <0x48004c10 0x4>;
+	ti,clkdm-name = "wkup_clkdm";
+	ti,enable-bit = <1>;
+};
+
+gpt1_ick: gpt1_ick at 48004c10 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&wkup_l4_ick>;
+	reg = <0x48004c10 0x4>;
+	ti,clkdm-name = "wkup_clkdm";
+	ti,enable-bit = <0>;
+};
+
+per_96m_fck: per_96m_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&omap_96m_alwon_fck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+per_48m_fck: per_48m_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&omap_48m_fck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+uart3_fck: uart3_fck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&per_48m_fck>;
+	reg = <0x48005000 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <11>;
+};
+
+gpt2_mux_fck: gpt2_mux_fck at 48005040 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&omap_32k_fck>, <&sys_ck>;
+	reg = <0x48005040 0x4>;
+	bit-mask = <0x1>;
+};
+
+gpt2_fck: gpt2_fck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&gpt2_mux_fck>;
+	bit-shift = <3>;
+	reg = <0x48005000 0x4>;
+};
+
+gpt3_mux_fck: gpt3_mux_fck at 48005040 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&omap_32k_fck>, <&sys_ck>;
+	bit-shift = <1>;
+	reg = <0x48005040 0x4>;
+	bit-mask = <0x1>;
+};
+
+gpt3_fck: gpt3_fck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&gpt3_mux_fck>;
+	bit-shift = <4>;
+	reg = <0x48005000 0x4>;
+};
+
+gpt4_mux_fck: gpt4_mux_fck at 48005040 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&omap_32k_fck>, <&sys_ck>;
+	bit-shift = <2>;
+	reg = <0x48005040 0x4>;
+	bit-mask = <0x1>;
+};
+
+gpt4_fck: gpt4_fck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&gpt4_mux_fck>;
+	bit-shift = <5>;
+	reg = <0x48005000 0x4>;
+};
+
+gpt5_mux_fck: gpt5_mux_fck at 48005040 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&omap_32k_fck>, <&sys_ck>;
+	bit-shift = <3>;
+	reg = <0x48005040 0x4>;
+	bit-mask = <0x1>;
+};
+
+gpt5_fck: gpt5_fck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&gpt5_mux_fck>;
+	bit-shift = <6>;
+	reg = <0x48005000 0x4>;
+};
+
+gpt6_mux_fck: gpt6_mux_fck at 48005040 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&omap_32k_fck>, <&sys_ck>;
+	bit-shift = <4>;
+	reg = <0x48005040 0x4>;
+	bit-mask = <0x1>;
+};
+
+gpt6_fck: gpt6_fck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&gpt6_mux_fck>;
+	bit-shift = <7>;
+	reg = <0x48005000 0x4>;
+};
+
+gpt7_mux_fck: gpt7_mux_fck at 48005040 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&omap_32k_fck>, <&sys_ck>;
+	bit-shift = <5>;
+	reg = <0x48005040 0x4>;
+	bit-mask = <0x1>;
+};
+
+gpt7_fck: gpt7_fck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&gpt7_mux_fck>;
+	bit-shift = <8>;
+	reg = <0x48005000 0x4>;
+};
+
+gpt8_mux_fck: gpt8_mux_fck at 48005040 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&omap_32k_fck>, <&sys_ck>;
+	bit-shift = <6>;
+	reg = <0x48005040 0x4>;
+	bit-mask = <0x1>;
+};
+
+gpt8_fck: gpt8_fck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&gpt8_mux_fck>;
+	bit-shift = <9>;
+	reg = <0x48005000 0x4>;
+};
+
+gpt9_mux_fck: gpt9_mux_fck at 48005040 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&omap_32k_fck>, <&sys_ck>;
+	bit-shift = <7>;
+	reg = <0x48005040 0x4>;
+	bit-mask = <0x1>;
+};
+
+gpt9_fck: gpt9_fck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&gpt9_mux_fck>;
+	bit-shift = <10>;
+	reg = <0x48005000 0x4>;
+};
+
+per_32k_alwon_fck: per_32k_alwon_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&omap_32k_fck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+gpio6_dbck: gpio6_dbck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&per_32k_alwon_fck>;
+	reg = <0x48005000 0x4>;
+	bit-shift = <17>;
+};
+
+gpio5_dbck: gpio5_dbck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&per_32k_alwon_fck>;
+	reg = <0x48005000 0x4>;
+	bit-shift = <16>;
+};
+
+gpio4_dbck: gpio4_dbck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&per_32k_alwon_fck>;
+	reg = <0x48005000 0x4>;
+	bit-shift = <15>;
+};
+
+gpio3_dbck: gpio3_dbck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&per_32k_alwon_fck>;
+	reg = <0x48005000 0x4>;
+	bit-shift = <14>;
+};
+
+gpio2_dbck: gpio2_dbck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&per_32k_alwon_fck>;
+	reg = <0x48005000 0x4>;
+	bit-shift = <13>;
+};
+
+wdt3_fck: wdt3_fck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&per_32k_alwon_fck>;
+	reg = <0x48005000 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <12>;
+};
+
+per_l4_ick: per_l4_ick {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&l4_ick>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+gpio6_ick: gpio6_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <17>;
+};
+
+gpio5_ick: gpio5_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <16>;
+};
+
+gpio4_ick: gpio4_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <15>;
+};
+
+gpio3_ick: gpio3_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <14>;
+};
+
+gpio2_ick: gpio2_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <13>;
+};
+
+wdt3_ick: wdt3_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <12>;
+};
+
+uart3_ick: uart3_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <11>;
+};
+
+uart4_ick: uart4_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <18>;
+};
+
+gpt9_ick: gpt9_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <10>;
+};
+
+gpt8_ick: gpt8_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <9>;
+};
+
+gpt7_ick: gpt7_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <8>;
+};
+
+gpt6_ick: gpt6_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <7>;
+};
+
+gpt5_ick: gpt5_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <6>;
+};
+
+gpt4_ick: gpt4_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <5>;
+};
+
+gpt3_ick: gpt3_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <4>;
+};
+
+gpt2_ick: gpt2_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <3>;
+};
+
+mcbsp2_ick: mcbsp2_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <0>;
+};
+
+mcbsp3_ick: mcbsp3_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <1>;
+};
+
+mcbsp4_ick: mcbsp4_ick at 48005010 {
+	#clock-cells = <0>;
+	compatible = "ti,interface-clock";
+	clocks = <&per_l4_ick>;
+	reg = <0x48005010 0x4>;
+	ti,clkdm-name = "per_clkdm";
+	ti,enable-bit = <2>;
+};
+
+mcbsp2_mux_fck: mcbsp2_mux_fck at 48002274 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&per_96m_fck>, <&mcbsp_clks>;
+	bit-shift = <6>;
+	reg = <0x48002274 0x4>;
+	bit-mask = <0x1>;
+};
+
+mcbsp2_fck: mcbsp2_fck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&mcbsp2_mux_fck>;
+	bit-shift = <0>;
+	reg = <0x48005000 0x4>;
+};
+
+mcbsp3_mux_fck: mcbsp3_mux_fck at 480022d8 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&per_96m_fck>, <&mcbsp_clks>;
+	reg = <0x480022d8 0x4>;
+	bit-mask = <0x1>;
+};
+
+mcbsp3_fck: mcbsp3_fck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&mcbsp3_mux_fck>;
+	bit-shift = <1>;
+	reg = <0x48005000 0x4>;
+};
+
+mcbsp4_mux_fck: mcbsp4_mux_fck at 480022d8 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&per_96m_fck>, <&mcbsp_clks>;
+	bit-shift = <2>;
+	reg = <0x480022d8 0x4>;
+	bit-mask = <0x1>;
+};
+
+mcbsp4_fck: mcbsp4_fck at 48005000 {
+	#clock-cells = <0>;
+	compatible = "gate-clock";
+	clocks = <&mcbsp4_mux_fck>;
+	bit-shift = <2>;
+	reg = <0x48005000 0x4>;
+};
+
+emu_src_mux_ck: emu_src_mux_ck at 48005140 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_ck>, <&emu_core_alwon_ck>, <&emu_per_alwon_ck>, <&emu_mpu_alwon_ck>;
+	reg = <0x48005140 0x4>;
+	bit-mask = <0x3>;
+};
+
+emu_src_ck: emu_src_ck {
+	#clock-cells = <0>;
+	compatible = "ti,gate-clock";
+	clocks = <&emu_src_mux_ck>;
+	ti,clkdm-name = "emu_clkdm";
+};
+
+pclk_fck: pclk_fck at 48005140 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&emu_src_ck>;
+	bit-shift = <8>;
+	reg = <0x48005140 0x4>;
+	bit-mask = <0x7>;
+	index-starts-at-one;
+};
+
+pclkx2_fck: pclkx2_fck at 48005140 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&emu_src_ck>;
+	bit-shift = <6>;
+	reg = <0x48005140 0x4>;
+	bit-mask = <0x3>;
+	index-starts-at-one;
+};
+
+atclk_fck: atclk_fck at 48005140 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&emu_src_ck>;
+	bit-shift = <4>;
+	reg = <0x48005140 0x4>;
+	bit-mask = <0x3>;
+	index-starts-at-one;
+};
+
+traceclk_src_fck: traceclk_src_fck at 48005140 {
+	#clock-cells = <0>;
+	compatible = "mux-clock";
+	clocks = <&sys_ck>, <&emu_core_alwon_ck>, <&emu_per_alwon_ck>, <&emu_mpu_alwon_ck>;
+	bit-shift = <2>;
+	reg = <0x48005140 0x4>;
+	bit-mask = <0x3>;
+};
+
+traceclk_fck: traceclk_fck at 48005140 {
+	#clock-cells = <0>;
+	compatible = "divider-clock";
+	clocks = <&traceclk_src_fck>;
+	bit-shift = <11>;
+	reg = <0x48005140 0x4>;
+	bit-mask = <0x7>;
+	index-starts-at-one;
+};
+
+secure_32k_fck: secure_32k_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-clock";
+	clock-frequency = <32768>;
+};
+
+gpt12_fck: gpt12_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&secure_32k_fck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
+
+wdt1_fck: wdt1_fck {
+	#clock-cells = <0>;
+	compatible = "fixed-factor-clock";
+	clocks = <&secure_32k_fck>;
+	clock-mult = <1>;
+	clock-div = <1>;
+};
-- 
1.7.9.5



From tomasz.figa at gmail.com  Tue Jul 23 03:29:32 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 09:29:32 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <Pine.LNX.4.44L0.1307221028440.1495-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307221028440.1495-100000@iolanthe.rowland.org>
Message-ID: <1714400.neMPBWOlzi@flatron>

Hi Alan,

On Monday 22 of July 2013 10:44:39 Alan Stern wrote:
> On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
> > > 	The PHY and the controller it is attached to are both physical
> > > 	devices.
> > > 	
> > > 	The connection between them is hardwired by the system
> > > 	manufacturer and cannot be changed by software.
> > > 	
> > > 	PHYs are generally described by fixed system-specific board
> > > 	files or by Device Tree information.  Are they ever discovered
> > > 	dynamically?
> > 
> > No. They are created just like any other platform devices are created.
> 
> Okay.  Are PHYs _always_ platform devices?

They can be i2c, spi or any other device types as well.

> > > 	Is the same true for the controllers attached to the PHYs?
> > > 	If not -- if both a PHY and a controller are discovered
> > > 	dynamically -- how does the kernel know whether they are
> > > 	connected to each other?
> > 
> > No differences here. Both PHY and controller will have dt information
> > or hwmod data using which platform devices will be created.
> > 
> > > 	The kernel needs to know which controller is attached to which
> > > 	PHY.  Currently this information is represented by name or ID
> > > 	strings embedded in platform data.
> > 
> > right. It's embedded in the platform data of the controller.
> 
> It must also be embedded in the PHY's platform data somehow.
> Otherwise, how would the kernel know which PHY to use?

By using a PHY lookup as Stephen and I suggested in our previous replies. 
Without any extra data in platform data. (I have even posted a code 
example.)

> > > 	The PHY's driver (the supplier) uses the platform data to
> > > 	construct a platform_device structure that represents the PHY.
> > 
> > Currently the driver assigns static labels (corresponding to the label
> > used in the platform data of the controller).
> > 
> > > 	Until this is done, the controller's driver (the client) cannot
> > > 	use the PHY.
> > 
> > right.
> > 
> > > 	Since there is no parent-child relation between the PHY and the
> > > 	controller, there is no guarantee that the PHY's driver will be
> > > 	ready when the controller's driver wants to use it.  A deferred
> > > 	probe may be needed.
> > 
> > right.
> > 
> > > 	The issue (or one of the issues) in this discussion is that
> > > 	Greg does not like the idea of using names or IDs to associate
> > > 	PHYs with controllers, because they are too prone to
> > > 	duplications or other errors.  Pointers are more reliable.
> > > 	
> > > 	But pointers to what?  Since the only data known to be
> > > 	available to both the PHY driver and controller driver is the
> > > 	platform data, the obvious answer is a pointer to platform data
> > > 	(either for the PHY or for the controller, or maybe both).
> > 
> > hmm.. it's not going to be simple though as the platform device for
> > the PHY and controller can be created in entirely different places.
> > e.g., in some cases the PHY device is a child of some mfd core device
> > (the device will be created in drivers/mfd) and the controller driver
> > (usually) is created in board file. I guess then we have to come up
> > with something to share a pointer in two different files.
> 
> The ability for two different source files to share a pointer to a data
> item defined in a third source file has been around since long before
> the C language was invented.  :-)
> 
> In this case, it doesn't matter where the platform_device structures
> are created or where the driver source code is.  Let's take a simple
> example.  Suppose the system design includes a PHY named "foo".  Then
> the board file could contain:
> 
> struct phy_info { ... } phy_foo;
> EXPORT_SYMBOL_GPL(phy_foo);
> 
> and a header file would contain:
> 
> extern struct phy_info phy_foo;
> 
> The PHY supplier could then call phy_create(&phy_foo), and the PHY
> client could call phy_find(&phy_foo).  Or something like that; make up
> your own structure tags and function names.
> 
> It's still possible to have conflicts, but now two PHYs with the same
> name (or a misspelled name somewhere) will cause an error at link time.

This is incorrect, sorry. First of all it's a layering violation - you 
export random driver-specific symbols from one driver to another. Then 
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and 
there are two types of consumer drivers (e.g. USB host controllers). Now 
consider following mapping:

SoC	PHY	consumer
A	PHY1	HOST1
B	PHY1	HOST2
C	PHY2	HOST1
D	PHY2	HOST2

So we have to be able to use any of the PHYs with any of the host drivers. 
This means you would have to export symbol with the same name from both 
PHY drivers, which obviously would not work in this case, because having 
both drivers enabled (in a multiplatform aware configuration) would lead 
to linking conflict.

Best regards,
Tomasz



From srinivas.kandagatla at st.com  Tue Jul 23 03:23:31 2013
From: srinivas.kandagatla at st.com (Srinivas KANDAGATLA)
Date: Tue, 23 Jul 2013 08:23:31 +0100
Subject: [PATCH v2 2/2] ARM: STi: Set correct ARM ERRATAs.
In-Reply-To: <20130723023540.GA14983@quad.lixom.net>
References: <1373354752-26292-1-git-send-email-srinivas.kandagatla@st.com>
 <1373354793-26400-1-git-send-email-srinivas.kandagatla@st.com>
 <20130723023540.GA14983@quad.lixom.net>
Message-ID: <51EE2F73.9070600@st.com>


On 23/07/13 03:35, Olof Johansson wrote:
> On Tue, Jul 09, 2013 at 08:26:33AM +0100, Srinivas KANDAGATLA wrote:
>> From: Srinivas Kandagatla <srinivas.kandagatla at st.com>
>>
>> Some of the ARM_ERRATA selection is not done in the initial SOC support
>> patches. This patch selects 2 new ARM_ERRATA's and removes one which was
>> actually fixed.
> 
> These entries should be sorted, and you inserted in random order.
Thanks Olof.
I will take a note of it.

> 
> I'll rearrange the order when applying.
> 
> (Patch applied with that change).
> 
> Thanks,
> 
> -Olof
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 



From shawn.guo at linaro.org  Tue Jul 23 03:38:26 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 23 Jul 2013 15:38:26 +0800
Subject: [PATCH] ARM: dts: imx: ocram size is different between imx6q and
 imx6dl
Message-ID: <1374565107-9658-1-git-send-email-shawn.guo@linaro.org>

The ocram on imx6q is 256 KiB while on imx6dl it's 128 KiB.  Let's
have separate node for imx6q and imx6dl.  It also changes imx6q size
0x3f000 to 0x40000 to match the hardware.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 arch/arm/boot/dts/imx6dl.dtsi  |    6 ++++++
 arch/arm/boot/dts/imx6q.dtsi   |    6 ++++++
 arch/arm/boot/dts/imx6qdl.dtsi |    6 ------
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index e9cb589..9e8ae11 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -32,6 +32,12 @@
 	};
 
 	soc {
+		ocram: sram at 00900000 {
+			compatible = "mmio-sram";
+			reg = <0x00900000 0x20000>;
+			clocks = <&clks 142>;
+		};
+
 		aips1: aips-bus at 02000000 {
 			iomuxc: iomuxc at 020e0000 {
 				compatible = "fsl,imx6dl-iomuxc";
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 76a84e8..f024ef2 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -61,6 +61,12 @@
 	};
 
 	soc {
+		ocram: sram at 00900000 {
+			compatible = "mmio-sram";
+			reg = <0x00900000 0x40000>;
+			clocks = <&clks 142>;
+		};
+
 		aips-bus at 02000000 { /* AIPS1 */
 			spba-bus at 02000000 {
 				ecspi5: ecspi at 02018000 {
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index bc4ca03..ccd55c2 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -99,12 +99,6 @@
 			status = "disabled";
 		};
 
-		ocram: sram at 00900000 {
-			compatible = "mmio-sram";
-			reg = <0x00900000 0x3f000>;
-			clocks = <&clks 142>;
-		};
-
 		timer at 00a00600 {
 			compatible = "arm,cortex-a9-twd-timer";
 			reg = <0x00a00600 0x20>;
-- 
1.7.9.5




From lee.jones at linaro.org  Tue Jul 23 03:52:32 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Jul 2013 08:52:32 +0100
Subject: [PATCH 19/22] ARM: shmobile: r8a7779: Remove '0x's from R8A7779
 DTS file
In-Reply-To: <20130723013343.GG16481@verge.net.au>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-19-git-send-email-lee.jones@linaro.org>
 <20130723013343.GG16481@verge.net.au>
Message-ID: <20130723075232.GD26801@laptop>

On Tue, 23 Jul 2013, Simon Horman wrote:

> On Mon, Jul 22, 2013 at 11:52:38AM +0100, Lee Jones wrote:
> > Cc: Simon Horman <horms+renesas at verge.net.au>
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> Acked-by: Simon Horman <horms+renesas at verge.net.au>
> 
> Let me know if you want me to take this through the renesas tree.

Thanks Simon. To save on conflicts, I think that's best.

I will take all orphaned patches or ones without maintainers associated
with them through ARM SoC, but if you can take it, please do.

> > ---
> >  arch/arm/boot/dts/r8a7779.dtsi | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
> > index 7f146c6..86bd487 100644
> > --- a/arch/arm/boot/dts/r8a7779.dtsi
> > +++ b/arch/arm/boot/dts/r8a7779.dtsi
> > @@ -65,7 +65,7 @@
> >  		sense-bitfield-width = <2>;
> >  	};
> >  
> > -	i2c0: i2c at 0xffc70000 {
> > +	i2c0: i2c at ffc70000 {
> >  		#address-cells = <1>;
> >  		#size-cells = <0>;
> >  		compatible = "renesas,rmobile-iic";
> > @@ -74,7 +74,7 @@
> >  		interrupts = <0 79 0x4>;
> >  	};
> >  
> > -	i2c1: i2c at 0xffc71000 {
> > +	i2c1: i2c at ffc71000 {
> >  		#address-cells = <1>;
> >  		#size-cells = <0>;
> >  		compatible = "renesas,rmobile-iic";
> > @@ -83,7 +83,7 @@
> >  		interrupts = <0 82 0x4>;
> >  	};
> >  
> > -	i2c2: i2c at 0xffc72000 {
> > +	i2c2: i2c at ffc72000 {
> >  		#address-cells = <1>;
> >  		#size-cells = <0>;
> >  		compatible = "renesas,rmobile-iic";
> > @@ -92,7 +92,7 @@
> >  		interrupts = <0 80 0x4>;
> >  	};
> >  
> > -	i2c3: i2c at 0xffc73000 {
> > +	i2c3: i2c at ffc73000 {
> >  		#address-cells = <1>;
> >  		#size-cells = <0>;
> >  		compatible = "renesas,rmobile-iic";

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Tue Jul 23 03:53:09 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Jul 2013 08:53:09 +0100
Subject: [PATCH 06/22] ARM: dts: bcm281xx: Remove '0x's from BCM11351 DTS
 file
In-Reply-To: <51EDAC90.6010108@broadcom.com>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-6-git-send-email-lee.jones@linaro.org>
 <51EDAC90.6010108@broadcom.com>
Message-ID: <20130723075309.GE26801@laptop>

> Acked-by: Christian Daudt <csd at broadcom.com>

Thanks Christian, for both.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From tomasz.figa at gmail.com  Tue Jul 23 03:55:08 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 09:55:08 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <1714400.neMPBWOlzi@flatron>
References: <Pine.LNX.4.44L0.1307221028440.1495-100000@iolanthe.rowland.org>
 <1714400.neMPBWOlzi@flatron>
Message-ID: <3419798.aorxYv8pdo@flatron>

[Fixed address of devicetree mailing list and added more people on CC.]

For reference, full thread can be found under following link:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813

Best regards,
Tomasz

On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> Hi Alan,
> 
> On Monday 22 of July 2013 10:44:39 Alan Stern wrote:
> > On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
> > > > 	The PHY and the controller it is attached to are both 
physical
> > > > 	devices.
> > > > 	
> > > > 	The connection between them is hardwired by the system
> > > > 	manufacturer and cannot be changed by software.
> > > > 	
> > > > 	PHYs are generally described by fixed system-specific 
board
> > > > 	files or by Device Tree information.  Are they ever 
discovered
> > > > 	dynamically?
> > > 
> > > No. They are created just like any other platform devices are
> > > created.
> > 
> > Okay.  Are PHYs _always_ platform devices?
> 
> They can be i2c, spi or any other device types as well.
> 
> > > > 	Is the same true for the controllers attached to the PHYs?
> > > > 	If not -- if both a PHY and a controller are discovered
> > > > 	dynamically -- how does the kernel know whether they are
> > > > 	connected to each other?
> > > 
> > > No differences here. Both PHY and controller will have dt
> > > information
> > > or hwmod data using which platform devices will be created.
> > > 
> > > > 	The kernel needs to know which controller is attached to 
which
> > > > 	PHY.  Currently this information is represented by name or 
ID
> > > > 	strings embedded in platform data.
> > > 
> > > right. It's embedded in the platform data of the controller.
> > 
> > It must also be embedded in the PHY's platform data somehow.
> > Otherwise, how would the kernel know which PHY to use?
> 
> By using a PHY lookup as Stephen and I suggested in our previous
> replies. Without any extra data in platform data. (I have even posted a
> code example.)
> 
> > > > 	The PHY's driver (the supplier) uses the platform data to
> > > > 	construct a platform_device structure that represents the 
PHY.
> > > 
> > > Currently the driver assigns static labels (corresponding to the
> > > label
> > > used in the platform data of the controller).
> > > 
> > > > 	Until this is done, the controller's driver (the client) 
cannot
> > > > 	use the PHY.
> > > 
> > > right.
> > > 
> > > > 	Since there is no parent-child relation between the PHY 
and the
> > > > 	controller, there is no guarantee that the PHY's driver 
will be
> > > > 	ready when the controller's driver wants to use it.  A 
deferred
> > > > 	probe may be needed.
> > > 
> > > right.
> > > 
> > > > 	The issue (or one of the issues) in this discussion is 
that
> > > > 	Greg does not like the idea of using names or IDs to 
associate
> > > > 	PHYs with controllers, because they are too prone to
> > > > 	duplications or other errors.  Pointers are more reliable.
> > > > 	
> > > > 	But pointers to what?  Since the only data known to be
> > > > 	available to both the PHY driver and controller driver is 
the
> > > > 	platform data, the obvious answer is a pointer to platform 
data
> > > > 	(either for the PHY or for the controller, or maybe both).
> > > 
> > > hmm.. it's not going to be simple though as the platform device for
> > > the PHY and controller can be created in entirely different places.
> > > e.g., in some cases the PHY device is a child of some mfd core
> > > device
> > > (the device will be created in drivers/mfd) and the controller
> > > driver
> > > (usually) is created in board file. I guess then we have to come up
> > > with something to share a pointer in two different files.
> > 
> > The ability for two different source files to share a pointer to a
> > data
> > item defined in a third source file has been around since long before
> > the C language was invented.  :-)
> > 
> > In this case, it doesn't matter where the platform_device structures
> > are created or where the driver source code is.  Let's take a simple
> > example.  Suppose the system design includes a PHY named "foo".  Then
> > the board file could contain:
> > 
> > struct phy_info { ... } phy_foo;
> > EXPORT_SYMBOL_GPL(phy_foo);
> > 
> > and a header file would contain:
> > 
> > extern struct phy_info phy_foo;
> > 
> > The PHY supplier could then call phy_create(&phy_foo), and the PHY
> > client could call phy_find(&phy_foo).  Or something like that; make up
> > your own structure tags and function names.
> > 
> > It's still possible to have conflicts, but now two PHYs with the same
> > name (or a misspelled name somewhere) will cause an error at link
> > time.
> 
> This is incorrect, sorry. First of all it's a layering violation - you
> export random driver-specific symbols from one driver to another. Then
> imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
> there are two types of consumer drivers (e.g. USB host controllers). Now
> consider following mapping:
> 
> SoC	PHY	consumer
> A	PHY1	HOST1
> B	PHY1	HOST2
> C	PHY2	HOST1
> D	PHY2	HOST2
> 
> So we have to be able to use any of the PHYs with any of the host
> drivers. This means you would have to export symbol with the same name
> from both PHY drivers, which obviously would not work in this case,
> because having both drivers enabled (in a multiplatform aware
> configuration) would lead to linking conflict.
> 
> Best regards,
> Tomasz


From jbe at pengutronix.de  Tue Jul 23 03:57:17 2013
From: jbe at pengutronix.de (=?iso-8859-1?q?J=FCrgen_Beisert?=)
Date: Tue, 23 Jul 2013 09:57:17 +0200
Subject: [PATCH] ARM: S3C24XX: Add missing clkdev entries for s3c2440 UART
In-Reply-To: <1374435765-6747-1-git-send-email-sylvester.nawrocki@gmail.com>
References: <1374435765-6747-1-git-send-email-sylvester.nawrocki@gmail.com>
Message-ID: <201307230957.17329.jbe@pengutronix.de>

On Sunday 21 July 2013 21:42:45 Sylwester Nawrocki wrote:
> This patch restores serial port operation which has been broken since
> commit 60e93575476f90a72146b51283f514da655410a7
> serial: samsung: enable clock before clearing pending interrupts during
> init
>
> That commit only uncovered the real issue which was missing clkdev
> entries for the "uart" clocks on S3C2440. It went unnoticed so far
> because return value of clk API calls were not being checked at all
> in the samsung serial port driver.
>
> This patch should be backported to at least 3.10 stable kernel, since
> the serial port has not been working on s3c2440 since 3.10-rc5.
>
> Cc: Chander Kashyap <chander.kashyap at linaro.org>
> Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
> [on S3C2440 SoC based Mini2440 board]
> Tested-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
>
> [...]

Tested-by: Juergen Beisert <jbe at pengutronix.de>

-- 
Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| Juergen Beisert ? ? ? ? ? ? |
Linux Solutions for Science and Industry ? ? ?| Phone: +49-5121-206917-5128 |
Peiner Str. 6-8, 31137 Hildesheim, Germany ? ?| Fax: ? +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 ? ? ? ? ? ? ?| http://www.pengutronix.de/ ?|


From shawn.guo at linaro.org  Tue Jul 23 03:58:24 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 23 Jul 2013 15:58:24 +0800
Subject: [PATCH] ARM: imx: add ocram clock for imx53
Message-ID: <1374566304-13488-1-git-send-email-shawn.guo@linaro.org>

Add missing ocram gate clock for imx53 and also represent it in device
tree ocram node.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 .../devicetree/bindings/clock/imx5-clock.txt       |    1 +
 arch/arm/boot/dts/imx53.dtsi                       |    1 +
 arch/arm/mach-imx/clk-imx51-imx53.c                |    3 ++-
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt
index f46f562..4c029a8 100644
--- a/Documentation/devicetree/bindings/clock/imx5-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt
@@ -197,6 +197,7 @@ clocks and IDs.
 	spdif0_gate		183
 	spdif1_gate		184
 	spdif_ipg_gate		185
+	ocram			186
 
 Examples (for mx53):
 
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 44a0170..4307e80 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -1121,6 +1121,7 @@
 		ocram: sram at f8000000 {
 			compatible = "mmio-sram";
 			reg = <0xf8000000 0x20000>;
+			clocks = <&clks 186>;
 		};
 	};
 };
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 9afac26..1a56a33 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -119,7 +119,7 @@ enum imx5_clks {
 	srtc_gate, pata_gate, sata_gate, spdif_xtal_sel, spdif0_sel,
 	spdif1_sel, spdif0_pred, spdif0_podf, spdif1_pred, spdif1_podf,
 	spdif0_com_s, spdif1_com_sel, spdif0_gate, spdif1_gate, spdif_ipg_gate,
-	clk_max
+	ocram, clk_max
 };
 
 static struct clk *clk[clk_max];
@@ -506,6 +506,7 @@ int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
 				mx53_can_sel, ARRAY_SIZE(mx53_can_sel));
 	clk[can1_serial_gate] = imx_clk_gate2("can1_serial_gate", "can_sel", MXC_CCM_CCGR6, 22);
 	clk[can1_ipg_gate] = imx_clk_gate2("can1_ipg_gate", "ipg", MXC_CCM_CCGR6, 20);
+	clk[ocram] = imx_clk_gate2("ocram", "ahb", MXC_CCM_CCGR6, 2);
 	clk[can2_serial_gate] = imx_clk_gate2("can2_serial_gate", "can_sel", MXC_CCM_CCGR4, 8);
 	clk[can2_ipg_gate] = imx_clk_gate2("can2_ipg_gate", "ipg", MXC_CCM_CCGR4, 6);
 	clk[i2c3_gate] = imx_clk_gate2("i2c3_gate", "per_root", MXC_CCM_CCGR1, 22);
-- 
1.7.9.5




From Ying.Liu at freescale.com  Tue Jul 23 04:04:03 2013
From: Ying.Liu at freescale.com (Liu Ying)
Date: Tue, 23 Jul 2013 16:04:03 +0800
Subject: [PATCH] ARM: dts: imx: ocram size is different between imx6q
 and imx6dl
In-Reply-To: <1374565107-9658-1-git-send-email-shawn.guo@linaro.org>
References: <1374565107-9658-1-git-send-email-shawn.guo@linaro.org>
Message-ID: <51EE38F3.7020503@freescale.com>

On 07/23/2013 03:38 PM, Shawn Guo wrote:
> The ocram on imx6q is 256 KiB while on imx6dl it's 128 KiB.  Let's
> have separate node for imx6q and imx6dl.  It also changes imx6q size
> 0x3f000 to 0x40000 to match the hardware.
> 
> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>

Acked-by: Liu Ying <Ying.Liu at freescale.com>

> ---
>  arch/arm/boot/dts/imx6dl.dtsi  |    6 ++++++
>  arch/arm/boot/dts/imx6q.dtsi   |    6 ++++++
>  arch/arm/boot/dts/imx6qdl.dtsi |    6 ------
>  3 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index e9cb589..9e8ae11 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boot/dts/imx6dl.dtsi
> @@ -32,6 +32,12 @@
>  	};
>  
>  	soc {
> +		ocram: sram at 00900000 {
> +			compatible = "mmio-sram";
> +			reg = <0x00900000 0x20000>;
> +			clocks = <&clks 142>;
> +		};
> +
>  		aips1: aips-bus at 02000000 {
>  			iomuxc: iomuxc at 020e0000 {
>  				compatible = "fsl,imx6dl-iomuxc";
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index 76a84e8..f024ef2 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -61,6 +61,12 @@
>  	};
>  
>  	soc {
> +		ocram: sram at 00900000 {
> +			compatible = "mmio-sram";
> +			reg = <0x00900000 0x40000>;
> +			clocks = <&clks 142>;
> +		};
> +
>  		aips-bus at 02000000 { /* AIPS1 */
>  			spba-bus at 02000000 {
>  				ecspi5: ecspi at 02018000 {
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index bc4ca03..ccd55c2 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -99,12 +99,6 @@
>  			status = "disabled";
>  		};
>  
> -		ocram: sram at 00900000 {
> -			compatible = "mmio-sram";
> -			reg = <0x00900000 0x3f000>;
> -			clocks = <&clks 142>;
> -		};
> -
>  		timer at 00a00600 {
>  			compatible = "arm,cortex-a9-twd-timer";
>  			reg = <0x00a00600 0x20>;
> 




From shawn.guo at linaro.org  Tue Jul 23 04:05:43 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 23 Jul 2013 16:05:43 +0800
Subject: [PATCH] ARM: imx6q: add vdoa gate clock
Message-ID: <1374566744-13692-1-git-send-email-shawn.guo@linaro.org>

Add the missing vdoa gate clock for imx6q.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 .../devicetree/bindings/clock/imx6q-clock.txt      |    1 +
 arch/arm/mach-imx/clk-imx6q.c                      |    3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 3066f181..5a90a72 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -214,6 +214,7 @@ clocks and IDs.
 	cko2_podf      		199
 	cko2      		200
 	cko      		201
+	vdoa      		202
 
 Examples:
 
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index ed19b33..bbafa3c 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -251,7 +251,7 @@ enum mx6q_clks {
 	ssi2_ipg, ssi3_ipg, rom, usbphy1, usbphy2, ldb_di0_div_3_5, ldb_di1_div_3_5,
 	sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref, usbphy1_gate,
 	usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
-	spdif, cko2_sel, cko2_podf, cko2, cko, clk_max
+	spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, clk_max
 };
 
 static struct clk *clk[clk_max];
@@ -501,6 +501,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[i2c3]         = imx_clk_gate2("i2c3",          "ipg_per",           base + 0x70, 10);
 	clk[iim]          = imx_clk_gate2("iim",           "ipg",               base + 0x70, 12);
 	clk[enfc]         = imx_clk_gate2("enfc",          "enfc_podf",         base + 0x70, 14);
+	clk[vdoa]         = imx_clk_gate2("vdoa",          "vdo_axi",           base + 0x70, 26);
 	clk[ipu1]         = imx_clk_gate2("ipu1",          "ipu1_podf",         base + 0x74, 0);
 	clk[ipu1_di0]     = imx_clk_gate2("ipu1_di0",      "ipu1_di0_sel",      base + 0x74, 2);
 	clk[ipu1_di1]     = imx_clk_gate2("ipu1_di1",      "ipu1_di1_sel",      base + 0x74, 4);
-- 
1.7.9.5




From tomasz.figa at gmail.com  Tue Jul 23 04:09:06 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 10:09:06 +0200
Subject: [PATCH v5] clk: add MOXA ART SoCs clock driver
In-Reply-To: <20130722092138.GB18731@e106331-lin.cambridge.arm.com>
References: <1374221278-18204-1-git-send-email-jonas.jensen@gmail.com>
 <1374221837-23773-1-git-send-email-jonas.jensen@gmail.com>
 <20130722092138.GB18731@e106331-lin.cambridge.arm.com>
Message-ID: <2711657.Br6v071qBc@flatron>

On Monday 22 of July 2013 10:21:38 Mark Rutland wrote:
> On Fri, Jul 19, 2013 at 09:17:17AM +0100, Jonas Jensen wrote:
> > This patch adds MOXA ART SoCs clock driver support.
> > 
> > Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
> > ---
> > 
> > Notes:
> >     Changes since v4:
> >     
> >     1. remove unnecessary header includes
> >     
> >     Applies to next-20130716
> >  
> >  .../bindings/clock/moxa,moxart-core-clock.txt      | 23 ++++++++
> >  drivers/clk/Makefile                               |  1 +
> >  drivers/clk/clk-moxart.c                           | 69
> >  ++++++++++++++++++++++ 3 files changed, 93 insertions(+)
> >  create mode 100644
> >  Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
> >  create mode 100644 drivers/clk/clk-moxart.c
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
> > b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
> > new file mode 100644
> > index 0000000..528c8b0
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
> > @@ -0,0 +1,23 @@
> > +Device Tree Clock bindings for arch-moxart
> > +
> > +This binding uses the common clock binding[1].
> > +
> > +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +
> > +MOXA ART SoCs allow to determine core clock frequencies by reading
> > +a register.
> > +
> > +Required properties:
> > +- compatible : Should be "moxa,moxart-core-clock"
> > +- #clock-cells : Should be 0
> > +- reg : Should contain registers location and length
> > +- clock-output-names : Should be "coreclk"
> > +
> > +For example:
> > +
> > +	coreclk: core-clock at 98100000 {
> > +		compatible = "moxa,moxart-core-clock";
> > +		#clock-cells = <0>;
> > +		reg = <0x98100000 0x34>;
> > +		clock-output-names = "coreclk";
> > +	};
> > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> > index 4038c2b..933622f 100644
> > --- a/drivers/clk/Makefile
> > +++ b/drivers/clk/Makefile
> > @@ -11,6 +11,7 @@ obj-$(CONFIG_COMMON_CLK)	+= clk-composite.o
> > 
> >  # SoCs specific
> >  obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
> > 
> > +obj-$(CONFIG_ARCH_MOXART)	+= clk-moxart.o
> > 
> >  obj-$(CONFIG_ARCH_NOMADIK)	+= clk-nomadik.o
> >  obj-$(CONFIG_ARCH_HIGHBANK)	+= clk-highbank.o
> >  obj-$(CONFIG_ARCH_NSPIRE)	+= clk-nspire.o
> > 
> > diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
> > new file mode 100644
> > index 0000000..5559371
> > --- /dev/null
> > +++ b/drivers/clk/clk-moxart.c
> > @@ -0,0 +1,69 @@
> > +/*
> > + * MOXA ART SoCs clock driver.
> > + *
> > + * Copyright (C) 2013 Jonas Jensen
> > + *
> > + * Jonas Jensen <jonas.jensen at gmail.com>
> > + *
> > + * This file is licensed under the terms of the GNU General Public
> > + * License version 2.  This program is licensed "as is" without any
> > + * warranty of any kind, whether express or implied.
> > + */
> > +
> > +#include <linux/clk-provider.h>
> > +#include <linux/io.h>
> > +#include <linux/of_address.h>
> > +#include <linux/clkdev.h>
> > +
> > +void __init moxart_of_clk_init(struct device_node *node)
> > +{
> > +	static void __iomem *base;
> > +	struct clk *clk;
> > +	unsigned long rate;
> > +	unsigned int mul, val, div;
> > +	const char *name;
> > +
> > +	base = of_iomap(node, 0);
> > +	if (IS_ERR(base))
> > +		panic("%s: of_iomap failed\n", node->full_name);
> 
> As far as I'm aware, of_iomap returns NULL, not an ERR_PTR value.
> 
> Also, is it necessary to panic() ? In v1 of the patch you used pr_err...

This is a good question in general, not only for this driver.

IMHO if you know early that something is really wrong, to the point that 
the system won't be able to work normally (and failing to initialize 
clocks looks like it) it is better to let the user/developer know that 
something is utterly wrong at this point without letting the system run 
for a bit more and fail anyway with a harder to track down error message.

It's not so obvious, though, what kinds of failure should be considered 
critical. IMHO any failure in low level initialization code, but this is 
debatable, I guess.

Best regards,
Tomasz



From horms+renesas at verge.net.au  Tue Jul 23 04:09:26 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 23 Jul 2013 17:09:26 +0900
Subject: [PATCH v2] ARM: shmobile: Add lager defconfig
Message-ID: <1374566966-30345-1-git-send-email-horms+renesas@verge.net.au>

This is intended to be used until multi-arch is able to be
used for the lager board at which time a more generic configuration
will be used in place of this one.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

v2
* Place defconfig in correct directory
* Bump SERIAL_SH_SCI_NR_UARTS up to 10 to reflect the
  number of devices present
---
 arch/arm/configs/lager_defconfig | 121 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 121 insertions(+)
 create mode 100644 arch/arm/configs/lager_defconfig

diff --git a/arch/arm/configs/lager_defconfig b/arch/arm/configs/lager_defconfig
new file mode 100644
index 0000000..f9efae1
--- /dev/null
+++ b/arch/arm/configs/lager_defconfig
@@ -0,0 +1,121 @@
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
+CONFIG_SLAB=y
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_SHMOBILE=y
+CONFIG_ARCH_R8A7790=y
+CONFIG_MACH_LAGER=y
+# CONFIG_SH_TIMER_TMU is not set
+# CONFIG_EM_TIMER_STI is not set
+# CONFIG_SWP_EMULATE is not set
+CONFIG_ARM_ERRATA_430973=y
+CONFIG_ARM_ERRATA_458693=y
+CONFIG_ARM_ERRATA_460075=y
+CONFIG_ARM_ERRATA_743622=y
+CONFIG_ARM_ERRATA_754322=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2
+# CONFIG_LOCAL_TIMERS is not set
+CONFIG_AEABI=y
+# CONFIG_OABI_COMPAT is not set
+CONFIG_FORCE_MAX_ZONEORDER=13
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_KEXEC=y
+CONFIG_AUTO_ZRELADDR=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_PM_RUNTIME=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_NETDEVICES=y
+# CONFIG_NET_CORE is not set
+# CONFIG_NET_VENDOR_ARC is not set
+# CONFIG_NET_CADENCE is not set
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+CONFIG_SH_ETH=y
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
+CONFIG_INPUT_EVDEV=y
+# CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_GPIO=y
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_SH_SCI=y
+CONFIG_SERIAL_SH_SCI_NR_UARTS=10
+CONFIG_SERIAL_SH_SCI_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+CONFIG_I2C_GPIO=y
+CONFIG_I2C_SH_MOBILE=y
+CONFIG_GPIO_SH_PFC=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_RCAR=y
+# CONFIG_HWMON is not set
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_SDHI=y
+CONFIG_MMC_SH_MMCIF=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_RTC_CLASS=y
+CONFIG_DMADEVICES=y
+CONFIG_SH_DMAE=y
+# CONFIG_IOMMU_SUPPORT is not set
+# CONFIG_DNOTIFY is not set
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_CONFIGFS_FS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_NFS_V4_1=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+# CONFIG_ARM_UNWIND is not set
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+# CONFIG_CRYPTO_HW is not set
-- 
1.8.2.1



From LW at KARO-electronics.de  Tue Jul 23 04:09:40 2013
From: LW at KARO-electronics.de (=?utf-8?Q?Lothar_Wa=C3=9Fmann?=)
Date: Tue, 23 Jul 2013 10:09:40 +0200
Subject: [PATCH 2/2] ARM: dts: mx6: Add support for imx6dl nitrogen board
In-Reply-To: <CAOMZO5C8Zz27KQOQxnurRmEUqUPw6VZNPGc3g4oXEUZUDxtYVQ@mail.gmail.com>
References: <1374118960-19060-1-git-send-email-festevam@gmail.com>
 <1374118960-19060-2-git-send-email-festevam@gmail.com>
 <20130722075736.GC20271@S2101-09.ap.freescale.net>
 <CAOMZO5C8Zz27KQOQxnurRmEUqUPw6VZNPGc3g4oXEUZUDxtYVQ@mail.gmail.com>
Message-ID: <20974.14916.259380.424120@ipc1.ka-ro>

Hi,

Fabio Estevam writes:
> Hi Shawn,
> 
> On Mon, Jul 22, 2013 at 4:57 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> 
> >> +/ {
> >> +     model = "Boundary Devices i.MX6 Dual Lite Nitrogen Board";
> >> +     compatible = "boundary,imx6dl-nitrogen", "fsl,imx6dl";
> >> +
> >> +     memory {
> >> +             reg = <0x10000000 0x40000000>;
> >> +     };
> >
> > This memory configuration is also common, right?
> 
> The reason I put the memory configuration in this file is because we
> also have nitrogen quad and dual-lite versions with 2GB.
> 
U-Boot is able to fill in these according to the actual amount of
memory detected.


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________


From rogerq at ti.com  Tue Jul 23 04:13:58 2013
From: rogerq at ti.com (Roger Quadros)
Date: Tue, 23 Jul 2013 11:13:58 +0300
Subject: [PATCH] ARM: Do not run dummy_flush_tlb_a15_erratum() on
 non-Cortex-A15
In-Reply-To: <1374556774-18795-1-git-send-email-festevam@gmail.com>
References: <1374556774-18795-1-git-send-email-festevam@gmail.com>
Message-ID: <51EE3B46.7020906@ti.com>

Hi Fabio,

On 07/23/2013 08:19 AM, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Commit 93dc688 (ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 
> (TLBI/DSB operations)) causes the following undefined instruction error on a
> mx53 (Cortex-A8):
> 
> Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> CPU: 0 PID: 275 Comm: modprobe Not tainted 3.11.0-rc2-next-20130722-00009-g9b0f371 #881
> task: df46cc00 ti: df48e000 task.ti: df48e000
> PC is at check_and_switch_context+0x17c/0x4d0
> LR is at check_and_switch_context+0xdc/0x4d0
> 
> This problem happens because check_and_switch_context() calls 
> dummy_flush_tlb_a15_erratum() without checking if we are really running on a 
> Cortex-A15 or not. 
> 
> To avoid this issue, always check if we are running on a Cortex-A15 or not 
> (via erratum_a15_798181()) inside dummy_flush_tlb_a15_erratum(), so that we do 
> not need to keep doing the same check in all occurrences of 
> dummy_flush_tlb_a15_erratum().
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  arch/arm/include/asm/tlbflush.h | 18 ++++++++++++++++++
>  arch/arm/kernel/smp_tlb.c       | 23 -----------------------
>  2 files changed, 18 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
> index fdbb9e3..2478b6f 100644
> --- a/arch/arm/include/asm/tlbflush.h
> +++ b/arch/arm/include/asm/tlbflush.h
> @@ -443,9 +443,22 @@ static inline void local_flush_bp_all(void)
>  		isb();
>  }
>  
> +#include <asm/cputype.h>
>  #ifdef CONFIG_ARM_ERRATA_798181
> +static inline int erratum_a15_798181(void)
> +{
> +	unsigned int midr = read_cpuid_id();
> +
> +	/* Cortex-A15 r0p0..r3p2 affected */
> +	if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2)
> +		return 0;
> +	return 1;
> +}
> +
>  static inline void dummy_flush_tlb_a15_erratum(void)
>  {
> +	if (!erratum_a15_798181())
> +		return;
>  	/*
>  	 * Dummy TLBIMVAIS. Using the unmapped address 0 and ASID 0.
>  	 */
> @@ -453,6 +466,11 @@ static inline void dummy_flush_tlb_a15_erratum(void)
>  	dsb();
>  }
>  #else
> +static inline int erratum_a15_798181(void)
> +{
> +	return 0;
> +}
> +
>  static inline void dummy_flush_tlb_a15_erratum(void)
>  {
>  }
> diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
> index a98b62d..29e9038 100644
> --- a/arch/arm/kernel/smp_tlb.c
> +++ b/arch/arm/kernel/smp_tlb.c
> @@ -70,23 +70,6 @@ static inline void ipi_flush_bp_all(void *ignored)
>  	local_flush_bp_all();
>  }
>  
> -#ifdef CONFIG_ARM_ERRATA_798181
> -static int erratum_a15_798181(void)
> -{
> -	unsigned int midr = read_cpuid_id();
> -
> -	/* Cortex-A15 r0p0..r3p2 affected */
> -	if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2)
> -		return 0;
> -	return 1;
> -}
> -#else
> -static int erratum_a15_798181(void)
> -{
> -	return 0;
> -}
> -#endif
> -
>  static void ipi_flush_tlb_a15_erratum(void *arg)
>  {
>  	dmb();
> @@ -94,9 +77,6 @@ static void ipi_flush_tlb_a15_erratum(void *arg)
>  
>  static void broadcast_tlb_a15_erratum(void)
>  {
> -	if (!erratum_a15_798181())
> -		return;
> -

Removing this if statement will cause "ipi_flush_tlb_a15_erratum" to be called
on non A15 platforms. So I would just keep it to be safe.

>  	dummy_flush_tlb_a15_erratum();
>  	smp_call_function(ipi_flush_tlb_a15_erratum, NULL, 1);
>  }
> @@ -106,9 +86,6 @@ static void broadcast_tlb_mm_a15_erratum(struct mm_struct *mm)
>  	int this_cpu;
>  	cpumask_t mask = { CPU_BITS_NONE };
>  
> -	if (!erratum_a15_798181())
> -		return;
> -

same here.
>  	dummy_flush_tlb_a15_erratum();
>  	this_cpu = get_cpu();
>  	a15_erratum_get_cpumask(this_cpu, mm, &mask);
> 

cheers,
-roger


From ben.dooks at codethink.co.uk  Tue Jul 23 04:16:39 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Tue, 23 Jul 2013 09:16:39 +0100
Subject: [PATCH 4/4] ARM: set --be8 when linking modules
In-Reply-To: <51ED8040.2020803@codethink.co.uk>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374510833-25716-5-git-send-email-ben.dooks@codethink.co.uk>
 <20130722170500.GC19639@codeaurora.org> <51ED69CA.3030501@codethink.co.uk>
 <alpine.LFD.2.03.1307221452210.15022@syhkavp.arg>
 <51ED8040.2020803@codethink.co.uk>
Message-ID: <51EE3BE7.2030706@codethink.co.uk>

On 22/07/13 19:56, Ben Dooks wrote:
> On 22/07/13 19:53, Nicolas Pitre wrote:
>> On Mon, 22 Jul 2013, Ben Dooks wrote:
>>
>>> On 22/07/13 18:05, Stephen Boyd wrote:
>>>> On 07/22, Ben Dooks wrote:
>>>>> To avoid having to make every text section swap the instruction order
>>>>> of all instructions, make sure modules are built also built with --be8
>>>>> (as is the current kernel final link).
>>>>>
>>>>> If we do not do this, we would end up having to swap all instructions
>>>>> when loading a module, instead of just the instructions that we are
>>>>> applying ELF relocations to.
>>>>>
>>>>
>>>> If someone tries to load a be8 module on a non-be8 kernel will it
>>>> still work? Or should we add an extra version magic string in
>>>> asm/module.h to prevent that?
>>>
>>> The ELF header changes the EI_DATA field in the ei_ident from
>>> ELFDATA2LSB to ELFDATA2MSB when compiling so we should be able
>>> to detect these when loading.
>>>
>>> I have not checked to see if the kernel correctly checks for this.
>>>
>>> I do not think it currently checks the ei_flags field for the
>>> EF_ARM_BE8 in ABI 4 and 5. I am not sure if this is really important?
>>
>> If the information is already there and easily accessible, then it
>> should be used.
>>
>>
>> Nicolas
>
> I have something like this, it does not mess things up loading
> BE8 binaries on my current system. I think we're building stuff
> for EABI4 but haven't checked.
>
> diff --git a/arch/arm/kernel/elf.c b/arch/arm/kernel/elf.c
> index d0d1e83..3b0351c 100644
> --- a/arch/arm/kernel/elf.c
> +++ b/arch/arm/kernel/elf.c
> @@ -34,6 +34,15 @@ int elf_check_arch(const struct elf32_hdr *x)
> if (flt_fmt == EF_ARM_VFP_FLOAT && !(elf_hwcap & HWCAP_VFP))
> return 0;
> }
> +
> + if ((eflags & EF_ARM_EABI_MASK) >= EF_ARM_EABI_VER4) {
> + if (eflags & EF_ARM_BE8) {
> + if (!IS_ENABLED(CONFIG_ARM_CPU_BE8))
> + return 1;
> + } else if (IS_ENABLED(CONFIG_ARM_CPU_BE8))
> + return 1;
> + }

dis-regard this, it does not work. I blame the heat.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From tomasz.figa at gmail.com  Tue Jul 23 04:23:17 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 10:23:17 +0200
Subject: [PATCH 6/6] USB: OHCI: make ohci-s3c2410 a separate driver
In-Reply-To: <1374484770-24531-7-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
 <1374484770-24531-1-git-send-email-manjunath.goudar@linaro.org>
 <1374484770-24531-7-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <3454167.krWglU43Yy@flatron>

Hi Manjunath,

Please see some comments inline.

On Monday 22 of July 2013 14:49:30 Manjunath Goudar wrote:
> Separate the Samsung OHCI S3CXXXX host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.12.
> 
> Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
> Acked-by: Alan Stern <stern at rowland.harvard.edu>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Greg KH <greg at kroah.com>
> Cc: linux-usb at vger.kernel.org
> 
> V2:
>  -Set non-standard fields in ohci_s3c2410_hc_driver manually, rather
> than relying on an expanded struct ohci_driver_overrides.
>  -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
>   relying on ohci_hub_control and hub_status_data being exported.
> 
> V3:
>  -Kconfig wrong parentheses discription fixed.
>  -ohci_setup() has been removed because it is called in .reset member
>   of the ohci_hc_driver structure.
> 
> V4:
>  - Removed extra space before the '='.
>  - Moved  /* forward definitions */ line before the declarations of
> functions. ---
>  drivers/usb/host/Kconfig        |    8 +++
>  drivers/usb/host/Makefile       |    1 +
>  drivers/usb/host/ohci-hcd.c     |   18 ------
>  drivers/usb/host/ohci-s3c2410.c |  128
> +++++++++++++++++---------------------- 4 files changed, 66
> insertions(+), 89 deletions(-)
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 693560a..795d14d 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR
>            Enables support for the on-chip OHCI controller on
>            ST SPEAr chips.
> 
> +config USB_OHCI_HCD_S3CXXXX
> +        tristate "Support for S3CXXXX on-chip OHCI USB controller"
> +        depends on USB_OHCI_HCD && (ARCH_S3C24XX || ARCH_S3C64XX)
> +        default y
> +        ---help---
> +          Enables support for the on-chip OHCI controller on
> +          S3CXXXX chips.
> +

Please keep the name s3c2410 for consistency. Having all the names come 
from the first SoC with this hardware is somewhat deterministic as opposed 
to some other naming methods, e.g. ohci-exynos2, while later on a 
different SoC from Exynos 2 shows up that needs a different driver.

>  config USB_OHCI_HCD_AT91
>          tristate "Support for Atmel on-chip OHCI USB controller"
>          depends on USB_OHCI_HCD && ARCH_AT91
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index a70b044..9dffe81 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_USB_OHCI_HCD_OMAP1)	+= ohci-omap.o
>  obj-$(CONFIG_USB_OHCI_HCD_OMAP3)	+= ohci-omap3.o
>  obj-$(CONFIG_USB_OHCI_HCD_SPEAR)	+= ohci-spear.o
>  obj-$(CONFIG_USB_OHCI_HCD_AT91)	+= ohci-at91.o
> +obj-$(CONFIG_USB_OHCI_HCD_S3CXXXX)	+= ohci-s3c2410.o
> 
>  obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
>  obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index b48c892..b69a49e 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -1177,11 +1177,6 @@ MODULE_LICENSE ("GPL");
>  #define SA1111_DRIVER		ohci_hcd_sa1111_driver
>  #endif
> 
> -#if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX)
> -#include "ohci-s3c2410.c"
> -#define S3C2410_PLATFORM_DRIVER	ohci_hcd_s3c2410_driver
> -#endif
> -
>  #if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx)
>  #include "ohci-pxa27x.c"
>  #define PLATFORM_DRIVER		ohci_hcd_pxa27x_driver
> @@ -1293,12 +1288,6 @@ static int __init ohci_hcd_mod_init(void)
>  		goto error_tmio;
>  #endif
> 
> -#ifdef S3C2410_PLATFORM_DRIVER
> -	retval = platform_driver_register(&S3C2410_PLATFORM_DRIVER);
> -	if (retval < 0)
> -		goto error_s3c2410;
> -#endif
> -
>  #ifdef EP93XX_PLATFORM_DRIVER
>  	retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
>  	if (retval < 0)
> @@ -1332,10 +1321,6 @@ static int __init ohci_hcd_mod_init(void)
>  	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
>   error_ep93xx:
>  #endif
> -#ifdef S3C2410_PLATFORM_DRIVER
> -	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
> - error_s3c2410:
> -#endif
>  #ifdef TMIO_OHCI_DRIVER
>  	platform_driver_unregister(&TMIO_OHCI_DRIVER);
>   error_tmio:
> @@ -1382,9 +1367,6 @@ static void __exit ohci_hcd_mod_exit(void)
>  #ifdef EP93XX_PLATFORM_DRIVER
>  	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
>  #endif
> -#ifdef S3C2410_PLATFORM_DRIVER
> -	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
> -#endif
>  #ifdef TMIO_OHCI_DRIVER
>  	platform_driver_unregister(&TMIO_OHCI_DRIVER);
>  #endif
> diff --git a/drivers/usb/host/ohci-s3c2410.c
> b/drivers/usb/host/ohci-s3c2410.c index e125770..48b5948 100644
> --- a/drivers/usb/host/ohci-s3c2410.c
> +++ b/drivers/usb/host/ohci-s3c2410.c
> @@ -19,19 +19,36 @@
>   * This file is licenced under the GPL.
>  */
> 
> -#include <linux/platform_device.h>
>  #include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
>  #include <linux/platform_data/usb-ohci-s3c2410.h>
> +#include <linux/usb.h>
> +#include <linux/usb/hcd.h>
> +
> +#include "ohci.h"
> +
> 
>  #define valid_port(idx) ((idx) == 1 || (idx) == 2)
> 
>  /* clock device associated with the hcd */
> 
> +
> +#define DRIVER_DESC "OHCI S3CXXXX driver"
> +
> +static const char hcd_name[] = "ohci-s3cxxxx";
> +

Ditto.

>  static struct clk *clk;
>  static struct clk *usb_clk;
> 
>  /* forward definitions */
> 
> +static int (*orig_ohci_hub_control)(struct usb_hcd  *hcd, u16 typeReq,
> +			u16 wValue, u16 wIndex, char *buf, u16 wLength);
> +static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char
> *buf); +
>  static void s3c2410_hcd_oc(struct s3c2410_hcd_info *info, int port_oc);
> 
>  /* conversion functions */
> @@ -93,7 +110,7 @@ ohci_s3c2410_hub_status_data(struct usb_hcd *hcd,
> char *buf) int orig;
>  	int portno;
> 
> -	orig  = ohci_hub_status_data(hcd, buf);
> +	orig = orig_ohci_hub_status_data(hcd, buf);
> 
>  	if (info == NULL)
>  		return orig;
> @@ -164,7 +181,7 @@ static int ohci_s3c2410_hub_control(
>  	 * process the request straight away and exit */
> 
>  	if (info == NULL) {
> -		ret = ohci_hub_control(hcd, typeReq, wValue,
> +		ret = orig_ohci_hub_control(hcd, typeReq, wValue,
>  				       wIndex, buf, wLength);
>  		goto out;
>  	}
> @@ -214,7 +231,7 @@ static int ohci_s3c2410_hub_control(
>  		break;
>  	}
> 
> -	ret = ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, 
wLength);
> +	ret = orig_ohci_hub_control(hcd, typeReq, wValue, wIndex, buf,
> wLength); if (ret)
>  		goto out;
> 
> @@ -373,8 +390,6 @@ static int usb_hcd_s3c2410_probe(const struct
> hc_driver *driver,
> 
>  	s3c2410_start_hc(dev, hcd);
> 
> -	ohci_hcd_init(hcd_to_ohci(hcd));
> -
>  	retval = usb_add_hcd(hcd, dev->resource[1].start, 0);
>  	if (retval != 0)
>  		goto err_ioremap;
> @@ -391,71 +406,7 @@ static int usb_hcd_s3c2410_probe(const struct
> hc_driver *driver,
> 
>  /*---------------------------------------------------------------------
> ----*/
> 
> -static int
> -ohci_s3c2410_start(struct usb_hcd *hcd)
> -{
> -	struct ohci_hcd	*ohci = hcd_to_ohci(hcd);
> -	int ret;
> -
> -	ret = ohci_init(ohci);
> -	if (ret < 0)
> -		return ret;
> -
> -	ret = ohci_run(ohci);
> -	if (ret < 0) {
> -		dev_err(hcd->self.controller, "can't start %s\n",
> -			hcd->self.bus_name);
> -		ohci_stop(hcd);
> -		return ret;
> -	}
> -
> -	return 0;
> -}
> -
> -
> -static const struct hc_driver ohci_s3c2410_hc_driver = {
> -	.description =		hcd_name,
> -	.product_desc =		"S3C24XX OHCI",
> -	.hcd_priv_size =	sizeof(struct ohci_hcd),
> -
> -	/*
> -	 * generic hardware linkage
> -	 */
> -	.irq =			ohci_irq,
> -	.flags =		HCD_USB11 | HCD_MEMORY,
> -
> -	/*
> -	 * basic lifecycle operations
> -	 */
> -	.start =		ohci_s3c2410_start,
> -	.stop =			ohci_stop,
> -	.shutdown =		ohci_shutdown,
> -
> -	/*
> -	 * managing i/o requests and associated device resources
> -	 */
> -	.urb_enqueue =		ohci_urb_enqueue,
> -	.urb_dequeue =		ohci_urb_dequeue,
> -	.endpoint_disable =	ohci_endpoint_disable,
> -
> -	/*
> -	 * scheduling support
> -	 */
> -	.get_frame_number =	ohci_get_frame,
> -
> -	/*
> -	 * root hub support
> -	 */
> -	.hub_status_data =	ohci_s3c2410_hub_status_data,
> -	.hub_control =		ohci_s3c2410_hub_control,
> -#ifdef	CONFIG_PM
> -	.bus_suspend =		ohci_bus_suspend,
> -	.bus_resume =		ohci_bus_resume,
> -#endif
> -	.start_port_reset =	ohci_start_port_reset,
> -};
> -
> -/* device driver */
> +static struct hc_driver __read_mostly ohci_s3c2410_hc_driver;
> 
>  static int ohci_hcd_s3c2410_drv_probe(struct platform_device *pdev)
>  {
> @@ -532,4 +483,39 @@ static struct platform_driver
> ohci_hcd_s3c2410_driver = { },
>  };
> 
> +static int __init ohci_s3cxxxx_init(void)
> +{
> +	if (usb_disabled())
> +		return -ENODEV;
> +
> +	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
> +	ohci_init_driver(&ohci_s3c2410_hc_driver, NULL);
> +
> +	/*
> +	 * The Samsung HW has some unusual quirks, which require
> +	 * Sumsung-specific workarounds. We override certain hc_driver
> +	 * functions here to achieve that. We explicitly do not enhance
> +	 * ohci_driver_overrides to allow this more easily, since this
> +	 * is an unusual case, and we don't want to encourage others to
> +	 * override these functions by making it too easy.
> +	 */
> +
> +	orig_ohci_hub_control = ohci_s3c2410_hc_driver.hub_control;
> +	orig_ohci_hub_status_data = 
ohci_s3c2410_hc_driver.hub_status_data;
> +
> +	ohci_s3c2410_hc_driver.hub_status_data	= 
ohci_s3c2410_hub_status_data;
> +	ohci_s3c2410_hc_driver.hub_control	= 
ohci_s3c2410_hub_control; +
> +	return platform_driver_register(&ohci_hcd_s3c2410_driver);
> +}
> +module_init(ohci_s3cxxxx_init);
> +
> +static void __exit ohci_s3cxxxx_cleanup(void)
> +{
> +	platform_driver_unregister(&ohci_hcd_s3c2410_driver);
> +}
> +module_exit(ohci_s3cxxxx_cleanup);
> +
> +MODULE_DESCRIPTION(DRIVER_DESC);
> +MODULE_LICENSE("GPL");
>  MODULE_ALIAS("platform:s3c2410-ohci");

Otherwise looks good to me. I will try to test this on S3C6410 in next 
days.

Best regards,
Tomasz



From t-kristo at ti.com  Tue Jul 23 04:24:31 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Tue, 23 Jul 2013 11:24:31 +0300
Subject: [PATCHv4 00/33] ARM: OMAP: clock conversion to DT
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <51EE3DBF.9060101@ti.com>

Hrmph,

Seems like the old devicetree list was terminated yesterday, so if you 
reply to this you will get some bounces. Sorry about that.

-Tero

On 07/23/2013 10:19 AM, Tero Kristo wrote:
> Hi,
>
> Changes compared to previous version:
>
> - Clock init files moved from mach-omap2/ to drivers/clk/omap/
> - AM33xx support added [patches 15-20]
> - OMAP3 support added [patches 21-29]
> - DRA7 APLL support added (thanks Keerthy) [patches 30-33]
>
> Test branch on top of 3.11-rc1 available here:
>
> git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
> branch: mainline-3.11-rc1-omap-dt-clks
>
> Testing done:
>
> - boot + suspend tested on OMAP3 beagle C4 (omap3530)
> - boot + suspend tested on OMAP4 panda ES (omap4460)
> - boot tested on beagle bone (am335x)
>
> A boot test was also executed for DRA7 and OMAP5 on a separate branch
> (mainline does not have OMAP5 / DRA7 support so far.)
>
> TODO:
> - Add AM35xx support (OMAP3 derivative, AM35xx only clock nodes missing)
>
> Overall diffstat added just for fun:
>
>   arch/arm/boot/dts/am33xx-clocks.dtsi               |  663 ++++
>   arch/arm/boot/dts/am33xx.dtsi                      |    7 +
>   arch/arm/boot/dts/dra7xx-clocks.dtsi               | 2113 ++++++++++++
>   arch/arm/boot/dts/omap3.dtsi                       |    7 +
>   arch/arm/boot/dts/omap3430es1-clocks.dtsi          |  166 +
>   arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi    |  240 ++
>   arch/arm/boot/dts/omap34xx.dtsi                    |    9 +
>   .../omap36xx-am35xx-omap3430es2plus-clocks.dtsi    |  214 ++
>   arch/arm/boot/dts/omap36xx-clocks.dtsi             |   97 +
>   .../boot/dts/omap36xx-omap3430es2plus-clocks.dtsi  |  185 +
>   arch/arm/boot/dts/omap36xx.dtsi                    |   10 +
>   arch/arm/boot/dts/omap3xxx-clocks.dtsi             | 1594 +++++++++
>   arch/arm/boot/dts/omap443x-clocks.dtsi             |   17 +
>   arch/arm/boot/dts/omap443x.dtsi                    |    8 +
>   arch/arm/boot/dts/omap4460.dtsi                    |    8 +
>   arch/arm/boot/dts/omap446x-clocks.dtsi             |   27 +
>   arch/arm/boot/dts/omap44xx-clocks.dtsi             | 1654 +++++++++
>   arch/arm/boot/dts/omap54xx-clocks.dtsi             | 1416 ++++++++
>   arch/arm/mach-omap2/Makefile                       |    5 +-
>   arch/arm/mach-omap2/cclock33xx_data.c              | 1059 ------
>   arch/arm/mach-omap2/cclock3xxx_data.c              | 3641 --------------------
>   arch/arm/mach-omap2/cclock44xx_data.c              | 1730 ----------
>   arch/arm/mach-omap2/clock.c                        |    6 +
>   arch/arm/mach-omap2/clock.h                        |  163 +-
>   arch/arm/mach-omap2/clock3xxx.h                    |    7 +-
>   arch/arm/mach-omap2/io.c                           |    7 +-
>   arch/arm/mach-omap2/omap_hwmod.c                   |    5 +-
>   drivers/clk/Makefile                               |    1 +
>   drivers/clk/clk-divider.c                          |    6 +-
>   drivers/clk/clk-fixed-factor.c                     |    6 +-
>   drivers/clk/clk-gate.c                             |    8 +-
>   drivers/clk/clk-mux.c                              |    6 +-
>   drivers/clk/clkdev.c                               |   32 +
>   drivers/clk/omap/Makefile                          |    4 +
>   drivers/clk/omap/apll.c                            |  213 ++
>   drivers/clk/omap/autoidle.c                        |  130 +
>   drivers/clk/omap/clk-33xx.c                        |   85 +
>   drivers/clk/omap/clk-3xxx.c                        |  171 +
>   drivers/clk/omap/clk-44xx.c                        |  118 +
>   drivers/clk/omap/clk-54xx.c                        |   58 +
>   drivers/clk/omap/clk-7xx.c                         |   67 +
>   drivers/clk/omap/clk.c                             |   84 +
>   drivers/clk/omap/dpll.c                            |  387 +++
>   drivers/clk/omap/gate.c                            |  166 +
>   drivers/clk/omap/interface.c                       |  110 +
>   include/linux/clk/omap.h                           |  223 ++
>   46 files changed, 10327 insertions(+), 6606 deletions(-)
>
> -Tero
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



From ben.dooks at codethink.co.uk  Tue Jul 23 04:31:35 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Tue, 23 Jul 2013 09:31:35 +0100
Subject: alignment handler instruction endian-ness (Ben Dooks)
In-Reply-To: <CALicx6tS2B_itZHdFh2YrQ2VZOoacx-MuO5vkNfqypH9v5rEiQ@mail.gmail.com>
References: <CALicx6tS2B_itZHdFh2YrQ2VZOoacx-MuO5vkNfqypH9v5rEiQ@mail.gmail.com>
Message-ID: <51EE3F67.4050709@codethink.co.uk>

On 19/07/13 12:38, Vijay Kilari wrote:
> On Fri, Jul 19, 2013 at 5:06 PM, Vijay Kilari<vijay.kilari at gmail.com>  wrote:
>>> Message: 4
>>> Date: Fri, 19 Jul 2013 11:58:45 +0100
>>> From: Ben Dooks<ben.dooks at codethink.co.uk>
>>> To: "linux-arm-kernel at lists.infradead.org"
>>>          <linux-arm-kernel at lists.infradead.org>
>>> Subject: alignment handler instruction endian-ness
>>> Message-ID:<51E91BE5.8070809 at codethink.co.uk>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>


[snip]

>>>
>>
>   I think some changes are required in arch/arm/kernel/traps.c
>   for handling undefined instruction as well

I've added those now thanks.


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From lee.jones at linaro.org  Tue Jul 23 04:55:52 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Jul 2013 09:55:52 +0100
Subject: [PATCH 07/22] ARM: exynos: Remove '0x's from Exynos4110 DTSI file
In-Reply-To: <2350088.9z671SCjFz@flatron>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-7-git-send-email-lee.jones@linaro.org>
 <2350088.9z671SCjFz@flatron>
Message-ID: <20130723085552.GF26801@laptop>

On Mon, 22 Jul 2013, Tomasz Figa wrote:

> Hi Lee,
> 
> On Monday 22 of July 2013 11:52:26 Lee Jones wrote:
> > Cc: Kukjin Kim <kgene.kim at samsung.com>
> > Cc: linux-samsung-soc at vger.kernel.org
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > ---
> >  arch/arm/boot/dts/exynos4210.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> > b/arch/arm/boot/dts/exynos4210.dtsi index b7f358a..53e2527 100644
> > --- a/arch/arm/boot/dts/exynos4210.dtsi
> > +++ b/arch/arm/boot/dts/exynos4210.dtsi
> > @@ -72,7 +72,7 @@
> >  		};
> >  	};
> > 
> > -	clock: clock-controller at 0x10030000 {
> > +	clock: clock-controller at 10030000 {
> >  		compatible = "samsung,exynos4210-clock";
> >  		reg = <0x10030000 0x20000>;
> >  		#clock-cells = <1>;
> 
> This looks fine, but please fix commit message - it should be Exynos4210. 
> Also some explanation why this change is needed would be good, even if 
> it's obvious.

Hi Tomasz,

I'm happy to fixup the $SUBJECT line, but do we really have to enter
an explanation if it's obvious? Seems a little belt and braces.

Kind regards,
Lee

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Tue Jul 23 04:56:43 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 23 Jul 2013 09:56:43 +0100
Subject: [PATCH 04/22] ARM: at91: dt: Remove '0x's from Animeo IP DTS file
In-Reply-To: <20130722165707.GJ16015@ns203013.ovh.net>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-4-git-send-email-lee.jones@linaro.org>
 <20130722165707.GJ16015@ns203013.ovh.net>
Message-ID: <20130723085643.GG26801@laptop>

On Mon, 22 Jul 2013, Jean-Christophe PLAGNIOL-VILLARD wrote:

> On 11:52 Mon 22 Jul     , Lee Jones wrote:
> > Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> > Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

Thanks Jean-Christophe.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From rnayak at ti.com  Tue Jul 23 05:05:17 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 23 Jul 2013 14:35:17 +0530
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
Message-ID: <51EE474D.5070804@ti.com>

On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:
> Hi Rajendra,
> 
> On Tue, 23 Jul 2013, Rajendra Nayak wrote:
> 
>> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
>>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
>>>
>>>> Bear in mind that I'm almost at the point of not boot-testing anything
>>>> I sent to Linus because of the uselessness of the SDP4430 board now
>>>> that it's DT only - the only platform which boot-tests anything I send
>>>> is the 3430LDP board now.  If people care about that, maybe they can
>>>> assist with sorting out the issues I've raised on these lists about
>>>> the SDP4430 - and why the SDP4430 build remains disabled in my build
>>>> and boot system.
>>>
>>> I understand completely...
>>>
>>>> Looking at the boot log, it just stops after uboot hands over control.
>>>> With the lack of output from the decompressor, it's not possible to
>>>> tell whether it's a decompressor problem or a kernel problem.
>>>>
>>>> I think you need to turn on the LL_DEBUG option, select the appropriate
>>>> output option, and also get the decompressor to use the kernel's debug
>>>> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
>>>
>>> OK, will dig deeper here at the next opportunity.
>>
>> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
>> 2430sdp as the subject says, or was that a typo?
> 
> Thanks for the offer.  The issue that I'm seeing is on the 2430SDP in my 
> testbed.
> 
> I don't have a 4430SDP, so you might consider touching base with rmk for 
> that one.

So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
the below errors. (I am using the mainline bootloaders which do not lock any
additional DPLLs like USB)

[    0.000000] clock: dpll_usb_ck failed transition to 'locked'
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] clock: trace_clk_div_ck: could not find divisor for target rate 0 for parent pmd_trace_clk_mux_ck
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7
[    0.000000] [<c001bfe8>] (unwind_backtrace+0x0/0xf4) from [<c001868c>] (show_stack+0x10/0x14)
[    0.000000] [<c001868c>] (show_stack+0x10/0x14) from [<c02deb28>] (Ldiv0+0x8/0x10)
[    0.000000] [<c02deb28>] (Ldiv0+0x8/0x10) from [<c0477030>] (clk_divider_set_rate+0x10/0x114)
[    0.000000] [<c0477030>] (clk_divider_set_rate+0x10/0x114) from [<c0476ef4>] (clk_change_rate+0x38/0xb8)
[    0.000000] [<c0476ef4>] (clk_change_rate+0x38/0xb8) from [<c0476f5c>] (clk_change_rate+0xa0/0xb8)
[    0.000000] clock: dpll_per_m7x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m6x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m5x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck
[    0.000000] clock: dpll_per_m4x2_ck: could not find divisor for target rate 0 for parent dpll_per_x2_ck

> 
> 
> - Paul
> 



From tomi.valkeinen at ti.com  Tue Jul 23 05:06:43 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 23 Jul 2013 12:06:43 +0300
Subject: [PATCH 0/2] OMAP: Panda DVI fix and a cleanup
Message-ID: <1374570405-8301-1-git-send-email-tomi.valkeinen@ti.com>

Hi Tony,

Here's a fix for 3.11 that makes EDID read for DVI work again.

I also included a cleanup patch that removes the non-DT support functions that
are no longer called from anywhere. It's not a fix, but as we're in quite early
rcs, I thought it would be nice to remove the dead code.

Up to you if you want to include that one for 3.11 or not. If not, I'll include
it in a board file series for 3.12 that I'll send soon.

 Tomi

Tomi Valkeinen (2):
  ARM: OMAP: dss-common: fix Panda's DVI DDC channel
  ARM: OMAP2+: Remove legacy DSS initialization for omap4

 arch/arm/mach-omap2/dss-common.c | 49 +---------------------------------------
 arch/arm/mach-omap2/dss-common.h |  2 --
 2 files changed, 1 insertion(+), 50 deletions(-)

-- 
1.8.1.2



From tomi.valkeinen at ti.com  Tue Jul 23 05:06:44 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 23 Jul 2013 12:06:44 +0300
Subject: [PATCH 1/2] ARM: OMAP: dss-common: fix Panda's DVI DDC channel
In-Reply-To: <1374570405-8301-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374570405-8301-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374570405-8301-2-git-send-email-tomi.valkeinen@ti.com>

Panda's DVI connector's DDC pins are connected to OMAP's third i2c bus.
With non-DT, the bus number was 3, and that is what is used in the
dss-common.c which contains the platform data for Panda's DVI.

However, with DT, the bus number is 2. As we now only have DT boot for
Panda, we have to change the bus number to make DVI EDID read
operational.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/dss-common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 393aeef..043e570 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -42,7 +42,7 @@
 
 /* Using generic display panel */
 static struct tfp410_platform_data omap4_dvi_panel = {
-	.i2c_bus_num		= 3,
+	.i2c_bus_num		= 2,
 	.power_down_gpio	= PANDA_DVI_TFP410_POWER_DOWN_GPIO,
 };
 
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Tue Jul 23 05:06:45 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 23 Jul 2013 12:06:45 +0300
Subject: [PATCH 2/2] ARM: OMAP2+: Remove legacy DSS initialization for omap4
In-Reply-To: <1374570405-8301-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374570405-8301-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374570405-8301-3-git-send-email-tomi.valkeinen@ti.com>

This is no longer needed as omap4 is now booted using device tree.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/dss-common.c | 47 ----------------------------------------
 arch/arm/mach-omap2/dss-common.h |  2 --
 2 files changed, 49 deletions(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 043e570..00c0492 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -80,24 +80,6 @@ static struct omap_dss_board_info omap4_panda_dss_data = {
 	.default_device	= &omap4_panda_dvi_device,
 };
 
-void __init omap4_panda_display_init(void)
-{
-	omap_display_init(&omap4_panda_dss_data);
-
-	/*
-	 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
-	 * later have external pull up on the HDMI I2C lines
-	 */
-	if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
-		omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
-	else
-		omap_hdmi_init(0);
-
-	omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
-}
-
 void __init omap4_panda_display_init_of(void)
 {
 	omap_display_init(&omap4_panda_dss_data);
@@ -204,35 +186,6 @@ static struct omap_dss_board_info sdp4430_dss_data = {
  * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
  * selected by default
  */
-void __init omap_4430sdp_display_init(void)
-{
-	int r;
-
-	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
-			"display_sel");
-	if (r)
-		pr_err("%s: Could not get display_sel GPIO\n", __func__);
-
-	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
-		"DLP POWER ON");
-	if (r)
-		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
-
-	omap_display_init(&sdp4430_dss_data);
-	/*
-	 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
-	 * later have external pull up on the HDMI I2C lines
-	 */
-	if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
-		omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
-	else
-		omap_hdmi_init(0);
-
-	omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
-}
-
 void __init omap_4430sdp_display_init_of(void)
 {
 	int r;
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
index 915f6ff..c28fe3c 100644
--- a/arch/arm/mach-omap2/dss-common.h
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -6,9 +6,7 @@
  * This file will be removed when DSS supports DT.
  */
 
-void __init omap4_panda_display_init(void);
 void __init omap4_panda_display_init_of(void);
-void __init omap_4430sdp_display_init(void);
 void __init omap_4430sdp_display_init_of(void);
 
 #endif
-- 
1.8.1.2



From rogerq at ti.com  Tue Jul 23 05:18:52 2013
From: rogerq at ti.com (Roger Quadros)
Date: Tue, 23 Jul 2013 12:18:52 +0300
Subject: [PATCH 6/6] USB: ehci-omap: Implement suspend/resume
In-Reply-To: <Pine.LNX.4.44L0.1307221111410.1495-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307221111410.1495-100000@iolanthe.rowland.org>
Message-ID: <51EE4A7C.2020709@ti.com>

On 07/22/2013 06:18 PM, Alan Stern wrote:
> On Mon, 22 Jul 2013, Roger Quadros wrote:
> 
>> Right, I understand it now. How does the below code look?
>>
>> +static int omap_ehci_suspend(struct device *dev)
>> +{
>> +       struct usb_hcd *hcd = dev_get_drvdata(dev);
>> +       bool do_wakeup = device_may_wakeup(dev);
>> +       int ret;
>> +
>> +       dev_dbg(dev, "%s may_wakeup %d\n", __func__, do_wakeup);
>> +
>> +       if (pm_runtime_status_suspended(dev)) {
> 
> You need to do this only when do_wakeup is false.

Right. Missed that.
> 
>> +               pm_runtime_get_sync(dev);
>> +               ehci_resume(hcd, false);
>> +               ret = ehci_suspend(hcd, do_wakeup);
>> +               pm_runtime_put_sync(dev);
> 
> It would be better to call pm_runtime_resume(dev) at the start instead
> of pm_runtime_get_sync(), and eliminate the last two lines.  Then the
> ehci_suspend() below could be moved outside the "if" statement.

Why do I find pm_runtime_* so confusing ;)

> 
> Alternatively, if you are able to turn off the wakeup setting without
> going through an entire resume/suspend cycle, that would be preferable.
> 

As we don't rely on the EHCI controller's interrupt any more after we
power it down, maybe ehci_resume/suspend cycle is not required at all on OMAP,
even if the wakeup setting is disabled during system suspend.

As the wakeup is controlled entirely by pad wakeup, all we need to do is make sure
the IO pad wakeup is configured correctly based on do_wakeup. How this is done
is still in transition but it might be turn out to be as simple as irq_set_irq_wake()

So IMHO, for ehci-omap this should suffice

static int omap_ehci_suspend(struct device *dev)
{
	struct usb_hcd *hcd = dev_get_drvdata(dev);
	bool do_wakeup = device_may_wakeup(dev);
	int ret = 0;

	if (!pm_runtime_status_suspended(dev))
		ret = ehci_suspend(hcd, do_wakeup);

	/* Not tested yet */
	irq_set_irq_wake(hcd->irq, do_wakeup);

	return ret;
}

What do you think?

As the OMAP IO pad wakeup management code [1] is still in transition, I'll wait till
that gets settled and then resend this series.

cheers,
-roger

[1] - http://thread.gmane.org/gmane.linux.ports.arm.omap/99010


From andrew at lunn.ch  Tue Jul 23 05:25:16 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 23 Jul 2013 11:25:16 +0200
Subject: [PATCH v3 12/16] cpufreq: kirkwood-cpufreq: remove device tree
 parsing for cpu nodes
In-Reply-To: <1374492747-13879-13-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-13-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <20130723092516.GC6846@lunn.ch>

On Mon, Jul 22, 2013 at 12:32:23PM +0100, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> Now that the cpu device registration initialises the of_node(if available)
> appropriately for all the cpus, parsing here is redundant.
> 
> This patch removes all DT parsing and uses cpu->of_node instead.
> 
> Cc: Andrew Lunn <andrew at lunn.ch>
> Cc: Jason Cooper <jason at lakedaemon.net>
> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> ---
>  drivers/cpufreq/kirkwood-cpufreq.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
> index c233ea6..25ac2cb 100644
> --- a/drivers/cpufreq/kirkwood-cpufreq.c
> +++ b/drivers/cpufreq/kirkwood-cpufreq.c
> @@ -14,7 +14,7 @@
>  #include <linux/clk.h>
>  #include <linux/clk-provider.h>
>  #include <linux/cpufreq.h>
> -#include <linux/of.h>
> +#include <linux/of_device.h>
>  #include <linux/platform_device.h>
>  #include <linux/io.h>
>  #include <asm/proc-fns.h>
> @@ -175,9 +175,11 @@ static int kirkwood_cpufreq_probe(struct platform_device *pdev)
>  	if (IS_ERR(priv.base))
>  		return PTR_ERR(priv.base);
>  
> -	np = of_find_node_by_path("/cpus/cpu at 0");
> -	if (!np)
> +	np = of_cpu_device_node_get(0);
> +	if (!np) {
> +		dev_err(&pdev->dev, "failed to get cpu device node\n");
>  		return -ENODEV;
> +	}
>  
>  	priv.cpu_clk = of_clk_get_by_name(np, "cpu_clk");
>  	if (IS_ERR(priv.cpu_clk)) {
> -- 
> 1.8.1.2

Hi Sudeep

I've not had chance to test it, but it looks O.K.

Acked-by: Andrew Lunn <andrew at lunn.ch>

	  Andrew



From t.figa at samsung.com  Tue Jul 23 05:32:43 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 11:32:43 +0200
Subject: [PATCH 07/22] ARM: exynos: Remove '0x's from Exynos4110 DTSI file
In-Reply-To: <20130723085552.GF26801@laptop>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <2350088.9z671SCjFz@flatron> <20130723085552.GF26801@laptop>
Message-ID: <1610492.3P9vcH2Wcz@amdc1227>

On Tuesday 23 of July 2013 09:55:52 Lee Jones wrote:
> On Mon, 22 Jul 2013, Tomasz Figa wrote:
> > Hi Lee,
> > 
> > On Monday 22 of July 2013 11:52:26 Lee Jones wrote:
> > > Cc: Kukjin Kim <kgene.kim at samsung.com>
> > > Cc: linux-samsung-soc at vger.kernel.org
> > > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > > ---
> > > 
> > >  arch/arm/boot/dts/exynos4210.dtsi | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> > > b/arch/arm/boot/dts/exynos4210.dtsi index b7f358a..53e2527 100644
> > > --- a/arch/arm/boot/dts/exynos4210.dtsi
> > > +++ b/arch/arm/boot/dts/exynos4210.dtsi
> > > @@ -72,7 +72,7 @@
> > > 
> > >  		};
> > >  	
> > >  	};
> > > 
> > > -	clock: clock-controller at 0x10030000 {
> > > +	clock: clock-controller at 10030000 {
> > > 
> > >  		compatible = "samsung,exynos4210-clock";
> > >  		reg = <0x10030000 0x20000>;
> > >  		#clock-cells = <1>;
> > 
> > This looks fine, but please fix commit message - it should be
> > Exynos4210. Also some explanation why this change is needed would be
> > good, even if it's obvious.
> 
> Hi Tomasz,
> 
> I'm happy to fixup the $SUBJECT line, but do we really have to enter
> an explanation if it's obvious? Seems a little belt and braces.

It's obvious for us, people working with device tree, but for people that 
usually don't it might not be.

Something among following lines would be fine:

This patch removes "0x" prefix from addresses in DT nodes for the sake of 
consistency with other nodes and assumed convention.

Best regards,
Tomasz



From maxime.ripard at free-electrons.com  Tue Jul 23 05:33:13 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 23 Jul 2013 11:33:13 +0200
Subject: [PATCH RFC 1/8] clk: sunxi: fix initialization of basic clocks
In-Reply-To: <1374541272-32173-2-git-send-email-emilio@elopez.com.ar>
References: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
 <1374541272-32173-2-git-send-email-emilio@elopez.com.ar>
Message-ID: <20130723093313.GB10389@lukather>

Hi Emilio,

On Mon, Jul 22, 2013 at 10:01:05PM -0300, Emilio L?pez wrote:
> With the recent move towards CLK_OF_DECLARE(...), the driver stopped
> initializing osc32k, which is compatible "fixed-clock". This is because
> we never called of_clk_init(NULL). Fix this by moving the only other
> simple clock (osc24M) to use CLK_OF_DECLARE(...) and call of_clk_init(NULL)
> to initialize both of them.
> 
> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
> ---
>  drivers/clk/sunxi/clk-sunxi.c | 9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 412912b..323366b 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -411,10 +411,7 @@ static void __init sunxi_gates_clk_setup(struct device_node *node,
>  }
>  
>  /* Matches for of_clk_init */
> -static const __initconst struct of_device_id clk_match[] = {
> -	{.compatible = "allwinner,sun4i-osc-clk", .data = sunxi_osc_clk_setup,},
> -	{}
> -};
> +CLK_OF_DECLARE(sunxi_osc, "allwinner,sun4i-osc-clk", sunxi_osc_clk_setup);

Maybe we can drop the comment and the newline above?

Apart from this nitpick,
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130723/2c6476d6/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Jul 23 05:35:00 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 23 Jul 2013 11:35:00 +0200
Subject: [PATCH RFC 2/8] clk: sunxi: register factors clocks behind
 composite
In-Reply-To: <1374541272-32173-3-git-send-email-emilio@elopez.com.ar>
References: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
 <1374541272-32173-3-git-send-email-emilio@elopez.com.ar>
Message-ID: <20130723093500.GC10389@lukather>

Hi Emilio,

On Mon, Jul 22, 2013 at 10:01:06PM -0300, Emilio L?pez wrote:
> This commit reworks factors clock registration to be done behind a
> composite clock. This allows us to additionally add a gate, mux or
> divisors, as it will be needed by some future PLLs.

Thanks for this patch, it looks fine.

I'm actually wondering if we could do this as well for the mux/gate/div
that we have?

This way, we would cover all the cases, and could only have one clock
defined per actual hardware clock.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130723/84a933b0/attachment-0001.sig>

From mark.rutland at arm.com  Tue Jul 23 05:35:13 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 23 Jul 2013 10:35:13 +0100
Subject: [PATCH] xen/arm64: Don't compile cpu hotplug
In-Reply-To: <1374529258-12866-1-git-send-email-julien.grall@linaro.org>
References: <1374529258-12866-1-git-send-email-julien.grall@linaro.org>
Message-ID: <20130723093513.GC4833@e106331-lin.cambridge.arm.com>

On Mon, Jul 22, 2013 at 10:40:58PM +0100, Julien Grall wrote:
> On ARM64, when CONFIG_XEN=y, the compilation will fail because CPU hotplug is
> not yet supported with XEN. For now, disable it.
> 
> Signed-off-by: Julien Grall <julien.grall at linaro.org>

With this applied I'm able to build an arm64 kernel with both
CONFIG_HOTPLUG_CPU (from local patches) and CONFIG_XEN.

Acked-by: Mark Rutland <mark.rutland at arm.com>

Cheers,
Mark.

> ---
>  drivers/xen/Makefile |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 2bf461a..a609353 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -1,4 +1,4 @@
> -ifneq ($(CONFIG_ARM),y)
> +ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
>  obj-y	+= manage.o
>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>  endif
> -- 
> 1.7.10.4
> 
> 


From heiko at sntech.de  Tue Jul 23 05:36:14 2013
From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=)
Date: Tue, 23 Jul 2013 11:36:14 +0200
Subject: [PATCH] ARM: rockchip: remove obsolete rockchip,config properties
Message-ID: <201307231136.14603.heiko@sntech.de>

These were used only in one intermediate variant of the pinctrl
driver but forgotten in the dtsi file. rockchip,config properties are
neither part of the actual binding nor handled by the pinctrl driver
at all, so remove them.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 arch/arm/boot/dts/rk3066a.dtsi |   22 ----------------------
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 457f380..258197e 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -213,17 +213,14 @@
 				uart0_xfer: uart0-xfer {
 					rockchip,pins = <RK_GPIO1 0 RK_FUNC_1 &pcfg_pull_default>,
 							<RK_GPIO1 1 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				uart0_cts: uart0-cts {
 					rockchip,pins = <RK_GPIO1 2 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				uart0_rts: uart0-rts {
 					rockchip,pins = <RK_GPIO1 3 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 			};
 
@@ -231,17 +228,14 @@
 				uart1_xfer: uart1-xfer {
 					rockchip,pins = <RK_GPIO1 4 RK_FUNC_1 &pcfg_pull_default>,
 							<RK_GPIO1 5 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				uart1_cts: uart1-cts {
 					rockchip,pins = <RK_GPIO1 6 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				uart1_rts: uart1-rts {
 					rockchip,pins = <RK_GPIO1 7 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 			};
 
@@ -249,7 +243,6 @@
 				uart2_xfer: uart2-xfer {
 					rockchip,pins = <RK_GPIO1 8 RK_FUNC_1 &pcfg_pull_default>,
 							<RK_GPIO1 9 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 				/* no rts / cts for uart2 */
 			};
@@ -258,44 +251,36 @@
 				uart3_xfer: uart3-xfer {
 					rockchip,pins = <RK_GPIO3 27 RK_FUNC_1 &pcfg_pull_default>,
 							<RK_GPIO3 28 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				uart3_cts: uart3-cts {
 					rockchip,pins = <RK_GPIO3 29 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				uart3_rts: uart3-rts {
 					rockchip,pins = <RK_GPIO3 30 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 			};
 
 			sd0 {
 				sd0_clk: sd0-clk {
 					rockchip,pins = <RK_GPIO3 8 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				sd0_cmd: sd0-cmd {
 					rockchip,pins = <RK_GPIO3 9 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				sd0_cd: sd0-cd {
 					rockchip,pins = <RK_GPIO3 14 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				sd0_wp: sd0-wp {
 					rockchip,pins = <RK_GPIO3 15 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				sd0_bus1: sd0-bus-width1 {
 					rockchip,pins = <RK_GPIO3 10 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				sd0_bus4: sd0-bus-width4 {
@@ -303,34 +288,28 @@
 							<RK_GPIO3 11 RK_FUNC_1 &pcfg_pull_default>,
 							<RK_GPIO3 12 RK_FUNC_1 &pcfg_pull_default>,
 							<RK_GPIO3 13 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 			};
 
 			sd1 {
 				sd1_clk: sd1-clk {
 					rockchip,pins = <RK_GPIO3 21 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				sd1_cmd: sd1-cmd {
 					rockchip,pins = <RK_GPIO3 16 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				sd1_cd: sd1-cd {
 					rockchip,pins = <RK_GPIO3 22 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				sd1_wp: sd1-wp {
 					rockchip,pins = <RK_GPIO3 23 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				sd1_bus1: sd1-bus-width1 {
 					rockchip,pins = <RK_GPIO3 17 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 
 				sd1_bus4: sd1-bus-width4 {
@@ -338,7 +317,6 @@
 							<RK_GPIO3 18 RK_FUNC_1 &pcfg_pull_default>,
 							<RK_GPIO3 19 RK_FUNC_1 &pcfg_pull_default>,
 							<RK_GPIO3 20 RK_FUNC_1 &pcfg_pull_default>;
-					rockchip,config = <&pcfg_pull_default>;
 				};
 			};
 		};
-- 
1.7.10.4



From mingo at kernel.org  Tue Jul 23 05:36:28 2013
From: mingo at kernel.org (Ingo Molnar)
Date: Tue, 23 Jul 2013 11:36:28 +0200
Subject: [PATCH, re-send] Always trap on BUG()
In-Reply-To: <51E47924.9030005@zytor.com>
References: <201307051738.35930.arnd@arndb.de>
 <20130715151612.9499c2b2ad40e88d183a4600@linux-foundation.org>
 <20130715222755.GY24642@n2100.arm.linux.org.uk>
 <51E47924.9030005@zytor.com>
Message-ID: <20130723093628.GC19786@gmail.com>


* H. Peter Anvin <hpa at zytor.com> wrote:

> On 07/15/2013 03:27 PM, Russell King - ARM Linux wrote:
> > On Mon, Jul 15, 2013 at 03:16:12PM -0700, Andrew Morton wrote:
> >> I've been thinking for a while that CONFIG_BUG=n is a pretty dumb thing
> >> to do, and that maintaining it (and trying to fix the warnings it
> >> produces) aren't worth the effort and that we should remove the whole
> >> thing.  Perhaps your patch changes that calculus, dunno.  Please discuss.
> > 
> > This isn't about introducing "CONFIG_BUG=n" - this is about making a
> > kernel with CONFIG_BUG=n build without producing tonnes and tonnes of
> > warnings, as it does today.  It makes building randconfig pretty
> > useless to find what could be more important warnings.
> > 
> 
> Well, there are three alternatives here, right:
> 
> 1. We can use unreachable(), which means that the compiler can assume it
> never happens.

AFAICS this is dangerous as it loses warnings and moves execution into 
la-la-land without any obvious sign at the C level.

> 2. We can trap without metadata.

This is what the patch does.

> 3. We can trap with metadata (current CONFIG_BUG=y).

That is still kept with the patch.

> I am *guessing* this does 2, but it isn't clear.

Yes, that's what it does - and I think it's the best of all worlds:

Acked-by: Ingo Molnar <mingo at kernel.org>

(the crazies can keep a separate patch to remove even more of BUG() to win 
a K or two.)

Thanks,

	Ingo


From chander.kashyap at linaro.org  Tue Jul 23 05:39:05 2013
From: chander.kashyap at linaro.org (Chander Kashyap)
Date: Tue, 23 Jul 2013 15:09:05 +0530
Subject: [PATCH] arm: l2x0: add support for prefetch and pwr control register
 configuration
Message-ID: <1374572345-5763-1-git-send-email-chander.kashyap@linaro.org>

This patch adds support to configure prefetch and pwr control registers
of pl310 cache controllor.

Signed-off-by: Chander Kashyap <chander.kashyap at linaro.org>
---
 Documentation/devicetree/bindings/arm/l2cc.txt |    6 ++++
 arch/arm/include/asm/hardware/cache-l2x0.h     |   23 +++++++++++++
 arch/arm/mm/cache-l2x0.c                       |   44 ++++++++++++++++++++++++
 3 files changed, 73 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
index cbef09b..66876b6 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -34,6 +34,12 @@ Optional properties:
 - arm,filter-ranges : <start length> Starting address and length of window to
   filter. Addresses in the filter window are directed to the M1 port. Other
   addresses will go to the M0 port.
+- arm,prefetch-control : Prefetch related configurations. Specifies 8 cells of
+  prefetch-offset, not-same-ID-on-exclusive-sequence-en, incr-double-Linefill-en,
+  prefetch-drop-en, data-prefetch-en, instruction-prefetch-en and
+  double-linefill-en.
+- arm,pwr-control : Operting mode clock and power mode selection. Specifies two
+  cells of standby-mode-en and dynamic_clk_gating_en.
 - interrupts : 1 combined interrupt.
 - cache-id-part: cache id part number to be used if it is not present
   on hardware
diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
index 3b2c40b..188f4da 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -106,6 +106,29 @@
 
 #define L2X0_WAY_SIZE_SHIFT		3
 
+#define L2X0_PREFETCH_CTRL_OFFSET_SHIFT			0
+#define L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT		21
+#define L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT	23
+#define L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT		24
+#define L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT	27
+#define L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT	28
+#define L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT	29
+#define L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT	30
+
+#define PREFETCH_R2P0_MASK	(~(1 << L2X0_PREFETCH_CTRL_OFFSET_SHIFT))
+#define PREFETCH_R3P0_MASK \
+		(~((1 << L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT) | \
+		   (1 << L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT) | \
+		   (1 << L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT) | \
+		   (1 << L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT) | \
+		   (1 << L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT) | \
+		   (1 << L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT)))
+#define PREFETCH_R3P1_MASK \
+		(~(1 << L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT))
+
+#define L2X0_PWR_CTRL_STANDBY_MODE_EN_SHIFT	0
+#define L2X0_PWR_CTRL_DYNAMIC_CLK_GATE_EN_SHIFT	1
+
 #ifndef __ASSEMBLY__
 extern void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask);
 #if defined(CONFIG_CACHE_L2X0) && defined(CONFIG_OF)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index c465fac..490e182 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -563,6 +563,11 @@ static void __init pl310_of_setup(const struct device_node *np,
 	u32 data[3] = { 0, 0, 0 };
 	u32 tag[3] = { 0, 0, 0 };
 	u32 filter[2] = { 0, 0 };
+	u32 prefetch[8] = { 0, 0, 0, 0, 0, 0, 0, 0 };
+	u32 prefetch_val;
+	u32 pwr[2] = { 0, 0 };
+	u32 l2x0_revision = readl_relaxed(l2x0_base + L2X0_CACHE_ID) &
+		L2X0_CACHE_ID_RTL_MASK;
 
 	of_property_read_u32_array(np, "arm,tag-latency", tag, ARRAY_SIZE(tag));
 	if (tag[0] && tag[1] && tag[2])
@@ -589,6 +594,45 @@ static void __init pl310_of_setup(const struct device_node *np,
 		writel_relaxed((filter[0] & ~(SZ_1M - 1)) | L2X0_ADDR_FILTER_EN,
 			       l2x0_base + L2X0_ADDR_FILTER_START);
 	}
+
+	if (l2x0_revision >= L2X0_CACHE_ID_RTL_R2P0) {
+		of_property_read_u32_array(np, "arm,prefetch-control",
+						prefetch, ARRAY_SIZE(prefetch));
+		prefetch_val = readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
+		prefetch_val &= PREFETCH_R2P0_MASK;
+		prefetch_val |= prefetch[0] << L2X0_PREFETCH_CTRL_OFFSET_SHIFT;
+		if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P0) {
+			prefetch_val &= PREFETCH_R3P0_MASK;
+			prefetch_val |=
+			 ((prefetch[1]) <<
+			   L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT) |
+			 ((prefetch[2]) <<
+			   L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT) |
+			 ((prefetch[3]) <<
+			   L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT) |
+			 ((prefetch[5]) <<
+			   L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT) |
+			 ((prefetch[6]) <<
+			   L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT) |
+			 ((prefetch[7]) <<
+			   L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT);
+			if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P1) {
+				prefetch_val &= PREFETCH_R3P1_MASK;
+				prefetch_val |=
+				 ((prefetch[4]) <<
+				   L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT);
+			}
+			writel_relaxed(prefetch_val,
+					l2x0_base + L2X0_PREFETCH_CTRL);
+
+			of_property_read_u32_array(np, "arm,pwr-control",
+						pwr, ARRAY_SIZE(pwr));
+			writel_relaxed(
+			 ((pwr[0]) << L2X0_PWR_CTRL_STANDBY_MODE_EN_SHIFT) |
+			 ((pwr[1]) << L2X0_PWR_CTRL_DYNAMIC_CLK_GATE_EN_SHIFT),
+			   l2x0_base + L2X0_POWER_CTRL);
+		}
+	}
 }
 
 static void __init pl310_save(void)
-- 
1.7.9.5



From chander.kashyap at linaro.org  Tue Jul 23 05:47:58 2013
From: chander.kashyap at linaro.org (Chander Kashyap)
Date: Tue, 23 Jul 2013 15:17:58 +0530
Subject: [PATCH] ARM: DT: Exynos: fix number of interrupt-cells in mct node
In-Reply-To: <1371220886-11616-1-git-send-email-chander.kashyap@linaro.org>
References: <1371220886-11616-1-git-send-email-chander.kashyap@linaro.org>
Message-ID: <CANuQgHH+nebJf4HPrsWPLECyvWO8OGJj=YeDG4GQAmLHM8GrPw@mail.gmail.com>

ping.

On 14 June 2013 20:11, Chander Kashyap <chander.kashyap at linaro.org> wrote:
> Two cells were used to specify interrupts in mct node, while second cell
> always remains unused. Hence use only one cell.
> Suggested by Tomasz Figa.
>
> Signed-off-by: Chander Kashyap <chander.kashyap at linaro.org>
> ---
>  arch/arm/boot/dts/exynos4210.dtsi |   19 +++++++++----------
>  arch/arm/boot/dts/exynos4212.dtsi |   19 +++++++++----------
>  arch/arm/boot/dts/exynos4412.dtsi |   23 +++++++++++------------
>  arch/arm/boot/dts/exynos5250.dtsi |   19 +++++++++----------
>  4 files changed, 38 insertions(+), 42 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
> index 54710de..ad50010 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -52,23 +52,22 @@
>                 compatible = "samsung,exynos4210-mct";
>                 reg = <0x10050000 0x800>;
>                 interrupt-controller;
> -               #interrups-cells = <2>;
> +               #interrups-cells = <1>;
>                 interrupt-parent = <&mct_map>;
> -               interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
> -                            <4 0>, <5 0>;
> +               interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
>                 clocks = <&clock 3>, <&clock 344>;
>                 clock-names = "fin_pll", "mct";
>
>                 mct_map: mct-map {
> -                       #interrupt-cells = <2>;
> +                       #interrupt-cells = <1>;
>                         #address-cells = <0>;
>                         #size-cells = <0>;
> -                       interrupt-map = <0x0 0 &gic 0 57 0>,
> -                                       <0x1 0 &gic 0 69 0>,
> -                                       <0x2 0 &combiner 12 6>,
> -                                       <0x3 0 &combiner 12 7>,
> -                                       <0x4 0 &gic 0 42 0>,
> -                                       <0x5 0 &gic 0 48 0>;
> +                       interrupt-map = <0 &gic 0 57 0>,
> +                                       <1 &gic 0 69 0>,
> +                                       <2 &combiner 12 6>,
> +                                       <3 &combiner 12 7>,
> +                                       <4 &gic 0 42 0>,
> +                                       <5 &gic 0 48 0>;
>                 };
>         };
>
> diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
> index c0f60f4..ba9ada1 100644
> --- a/arch/arm/boot/dts/exynos4212.dtsi
> +++ b/arch/arm/boot/dts/exynos4212.dtsi
> @@ -39,21 +39,20 @@
>                 compatible = "samsung,exynos4412-mct";
>                 reg = <0x10050000 0x800>;
>                 interrupt-controller;
> -               #interrups-cells = <2>;
> +               #interrups-cells = <1>;
>                 interrupt-parent = <&mct_map>;
> -               interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
> -                            <4 0>, <5 0>;
> +               interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
>
>                 mct_map: mct-map {
> -                       #interrupt-cells = <2>;
> +                       #interrupt-cells = <>;
>                         #address-cells = <0>;
>                         #size-cells = <0>;
> -                       interrupt-map = <0x0 0 &gic 0 57 0>,
> -                                       <0x1 0 &combiner 12 5>,
> -                                       <0x2 0 &combiner 12 6>,
> -                                       <0x3 0 &combiner 12 7>,
> -                                       <0x4 0 &gic 1 12 0>,
> -                                       <0x5 0 &gic 1 12 0>;
> +                       interrupt-map = <0 &gic 0 57 0>,
> +                                       <1 &combiner 12 5>,
> +                                       <2 &combiner 12 6>,
> +                                       <3 &combiner 12 7>,
> +                                       <4 &gic 1 12 0>,
> +                                       <5 &gic 1 12 0>;
>                 };
>         };
>  };
> diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
> index 270b389..a680de7 100644
> --- a/arch/arm/boot/dts/exynos4412.dtsi
> +++ b/arch/arm/boot/dts/exynos4412.dtsi
> @@ -39,25 +39,24 @@
>                 compatible = "samsung,exynos4412-mct";
>                 reg = <0x10050000 0x800>;
>                 interrupt-controller;
> -               #interrups-cells = <2>;
> +               #interrups-cells = <1>;
>                 interrupt-parent = <&mct_map>;
> -               interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
> -                            <4 0>, <5 0>, <6 0>, <7 0>;
> +               interrupts = <0>, <1>, <2>, <3>, <4>, <5>, <6>, <7>;
>                 clocks = <&clock 3>, <&clock 344>;
>                 clock-names = "fin_pll", "mct";
>
>                 mct_map: mct-map {
> -                       #interrupt-cells = <2>;
> +                       #interrupt-cells = <1>;
>                         #address-cells = <0>;
>                         #size-cells = <0>;
> -                       interrupt-map = <0x0 0 &gic 0 57 0>,
> -                                       <0x1 0 &combiner 12 5>,
> -                                       <0x2 0 &combiner 12 6>,
> -                                       <0x3 0 &combiner 12 7>,
> -                                       <0x4 0 &gic 1 12 0>,
> -                                       <0x5 0 &gic 1 12 0>,
> -                                       <0x6 0 &gic 1 12 0>,
> -                                       <0x7 0 &gic 1 12 0>;
> +                       interrupt-map = <0 &gic 0 57 0>,
> +                                       <1 &combiner 12 5>,
> +                                       <2 &combiner 12 6>,
> +                                       <3 &combiner 12 7>,
> +                                       <4 &gic 1 12 0>,
> +                                       <5 &gic 1 12 0>,
> +                                       <6 &gic 1 12 0>,
> +                                       <7 &gic 1 12 0>;
>                 };
>         };
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> index a7cf3f5..4e633ef 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -94,23 +94,22 @@
>                 compatible = "samsung,exynos4210-mct";
>                 reg = <0x101C0000 0x800>;
>                 interrupt-controller;
> -               #interrups-cells = <2>;
> +               #interrups-cells = <1>;
>                 interrupt-parent = <&mct_map>;
> -               interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
> -                            <4 0>, <5 0>;
> +               interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
>                 clocks = <&clock 1>, <&clock 335>;
>                 clock-names = "fin_pll", "mct";
>
>                 mct_map: mct-map {
> -                       #interrupt-cells = <2>;
> +                       #interrupt-cells = <1>;
>                         #address-cells = <0>;
>                         #size-cells = <0>;
> -                       interrupt-map = <0x0 0 &combiner 23 3>,
> -                                       <0x1 0 &combiner 23 4>,
> -                                       <0x2 0 &combiner 25 2>,
> -                                       <0x3 0 &combiner 25 3>,
> -                                       <0x4 0 &gic 0 120 0>,
> -                                       <0x5 0 &gic 0 121 0>;
> +                       interrupt-map = <0 &combiner 23 3>,
> +                                       <1 &combiner 23 4>,
> +                                       <2 &combiner 25 2>,
> +                                       <3 &combiner 25 3>,
> +                                       <4 &gic 0 120 0>,
> +                                       <5 &gic 0 121 0>;
>                 };
>         };
>
> --
> 1.7.9.5
>



-- 
with warm regards,
Chander Kashyap


From hpa at zytor.com  Tue Jul 23 05:54:06 2013
From: hpa at zytor.com (H. Peter Anvin)
Date: Tue, 23 Jul 2013 02:54:06 -0700
Subject: [PATCH, re-send] Always trap on BUG()
In-Reply-To: <20130723093628.GC19786@gmail.com>
References: <201307051738.35930.arnd@arndb.de>
 <20130715151612.9499c2b2ad40e88d183a4600@linux-foundation.org>
 <20130715222755.GY24642@n2100.arm.linux.org.uk> <51E47924.9030005@zytor.com>
 <20130723093628.GC19786@gmail.com>
Message-ID: <51EE52BE.5080204@zytor.com>

On 07/23/2013 02:36 AM, Ingo Molnar wrote:
>>
>> Well, there are three alternatives here, right:
>>
>> 1. We can use unreachable(), which means that the compiler can assume it
>> never happens.
> 
> AFAICS this is dangerous as it loses warnings and moves execution into 
> la-la-land without any obvious sign at the C level.
> 

Extremely dangerous.

	-hpa



From catalin.marinas at arm.com  Tue Jul 23 06:01:24 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Jul 2013 11:01:24 +0100
Subject: [PATCH 0/3] arm/arm64: a trio of boot mode detection fixes
In-Reply-To: <20130718162501.GA20870@e106331-lin.cambridge.arm.com>
References: <1373379366-15689-1-git-send-email-mark.rutland@arm.com>
 <51E8091A.5040302@arm.com>
 <20130718162501.GA20870@e106331-lin.cambridge.arm.com>
Message-ID: <20130723100122.GA3748@MacBook-Pro.local>

On Thu, Jul 18, 2013 at 05:25:01PM +0100, Mark Rutland wrote:
> On Thu, Jul 18, 2013 at 04:26:18PM +0100, Marc Zyngier wrote:
> > On 09/07/13 15:16, Mark Rutland wrote:
> > > The following patches fix a couple of issues in the boot mode detection
> > > code where in the case of mismatched boot modes we can corrupt a small
> > > portion of memory or fail to detect the fact we've booted CPUs with
> > > mismatched modes due to the boot mode being logged incoherently.
> > 
> > Sorry for the delay in replying to this. The whole series looks good to
> > me, so: Acked-by: Marc Zyngier <marc.zyngier at arm.com>
> 
> Cheers.
> 
> Russell,
> I've dropped the first two patches into the patch system as 7786/1 and
> 7787/1.
> 
> Catalin,
> Are you happy to pick up the third patch?

Yes. Thanks.

-- 
Catalin


From a.motakis at virtualopensystems.com  Tue Jul 23 06:01:32 2013
From: a.motakis at virtualopensystems.com (Antonios Motakis)
Date: Tue, 23 Jul 2013 12:01:32 +0200
Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to an
 IOMMU group
Message-ID: <1374573694-30595-1-git-send-email-a.motakis@virtualopensystems.com>

IOMMU groups are expected by certain users of the IOMMU API,
e.g. VFIO. Since each device is behind its own System MMU, we
can allocate a new IOMMU group for each device.

This patch depends on Cho KyongHo's patch series titled "[PATCH v7 00/12]
iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
applied on a Linux 3.10.1 kernel. It has been tested on the Arndale board.

Signed-off-by: Antonios Motakis <a.motakis at virtualopensystems.com>
---
 drivers/iommu/exynos-iommu.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 51d43bb..9f39eaa 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1134,6 +1134,28 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct iommu_domain *domain,
 	return phys;
 }
 
+static int exynos_iommu_add_device(struct device *dev)
+{
+	struct iommu_group *group;
+	int ret;
+
+	group = iommu_group_alloc();
+	if (IS_ERR(group)) {
+		dev_err(dev, "Failed to allocate IOMMU group\n");
+		return PTR_ERR(group);
+	}
+
+	ret = iommu_group_add_device(group, dev);
+	iommu_group_put(group);
+
+	return ret;
+}
+
+static void exynos_iommu_remove_device(struct device *dev)
+{
+	iommu_group_remove_device(dev);
+}
+
 static struct iommu_ops exynos_iommu_ops = {
 	.domain_init = &exynos_iommu_domain_init,
 	.domain_destroy = &exynos_iommu_domain_destroy,
@@ -1142,6 +1164,8 @@ static struct iommu_ops exynos_iommu_ops = {
 	.map = &exynos_iommu_map,
 	.unmap = &exynos_iommu_unmap,
 	.iova_to_phys = &exynos_iommu_iova_to_phys,
+	.add_device	= exynos_iommu_add_device,
+	.remove_device	= exynos_iommu_remove_device,
 	.pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
 };
 
-- 
1.8.1.2



From josephl at nvidia.com  Tue Jul 23 06:09:51 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 23 Jul 2013 18:09:51 +0800
Subject: [PATCH] ARM: dts: tegra114: dalmore: fix the irq trigger type of
 Palmas MFD device
Message-ID: <1374574191-24396-1-git-send-email-josephl@nvidia.com>

The IRQ trigger type of Palmas MFD device (tps65913) is low-level
sensitive. The wrong configuration would cause an interrupt storm
when booting the system. Fixing it in DT with appropriate interrupt
type.

Cc: Laxman Dewangan <ldewangan at nvidia.com>
Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/boot/dts/tegra114-dalmore.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index 76529e4..70b9d0c 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -840,7 +840,7 @@
 		palmas: tps65913 {
 			compatible = "ti,palmas";
 			reg = <0x58>;
-			interrupts = <0 86 0x4>;
+			interrupts = <0 86 0x8>;
 
 			#interrupt-cells = <2>;
 			interrupt-controller;
-- 
1.8.3.2



From catalin.marinas at arm.com  Tue Jul 23 06:20:07 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Jul 2013 11:20:07 +0100
Subject: [PATCH v2] xen/arm and xen/arm64: update xen_restart after
 ff701306cd49
In-Reply-To: <1374486464-25243-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1374486464-25243-1-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <20130723102006.GB3748@MacBook-Pro.local>

On Mon, Jul 22, 2013 at 10:47:44AM +0100, Stefano Stabellini wrote:
> Commit ff701306cd49 (arm64: use common reboot infrastructure) changes
> the prototype of arm_pm_restart.  Update xen_restart accordingly.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>

You may even want to quote 7b6d864b48d9 (reboot: arm: change reboot_mode
to use enum reboot_mode) since you are changing a file under arch/arm ;)

-- 
Catalin


From mark.rutland at arm.com  Tue Jul 23 06:22:12 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 23 Jul 2013 11:22:12 +0100
Subject: [PATCH] arm: l2x0: add support for prefetch and pwr control
 register configuration
In-Reply-To: <1374572345-5763-1-git-send-email-chander.kashyap@linaro.org>
References: <1374572345-5763-1-git-send-email-chander.kashyap@linaro.org>
Message-ID: <20130723102212.GD4833@e106331-lin.cambridge.arm.com>

Hi,

[adding Rob Herring to Cc]

On Tue, Jul 23, 2013 at 10:39:05AM +0100, Chander Kashyap wrote:
> This patch adds support to configure prefetch and pwr control registers
> of pl310 cache controllor.
> 
> Signed-off-by: Chander Kashyap <chander.kashyap at linaro.org>
> ---
>  Documentation/devicetree/bindings/arm/l2cc.txt |    6 ++++
>  arch/arm/include/asm/hardware/cache-l2x0.h     |   23 +++++++++++++
>  arch/arm/mm/cache-l2x0.c                       |   44 ++++++++++++++++++++++++
>  3 files changed, 73 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
> index cbef09b..66876b6 100644
> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
> @@ -34,6 +34,12 @@ Optional properties:
>  - arm,filter-ranges : <start length> Starting address and length of window to
>    filter. Addresses in the filter window are directed to the M1 port. Other
>    addresses will go to the M0 port.
> +- arm,prefetch-control : Prefetch related configurations. Specifies 8 cells of
> +  prefetch-offset, not-same-ID-on-exclusive-sequence-en, incr-double-Linefill-en,
> +  prefetch-drop-en, data-prefetch-en, instruction-prefetch-en and
> +  double-linefill-en.

This looks like configuration rather than hardware specification. 

Is there any reason we couldn't have Linux configure this itself? I'm
not sure having a fixed configuration of these values makes sense - the
configuration values could interact badly with future changes to Linux
(e.g. performance improvements or errata workarounds), and then we'd
have to ignore the described values and/or decide on more suitable ones
dynamically anyway.

I assume that these cells are meant to either be zero or one? If they're
necessary, they should be separate boolean properties rather than
grouped together by the register they're configured by (see the way
arm,tag-latency and arm,data-latency are handled). 

Also, I'd prefer "-enable" to "-en".

> +- arm,pwr-control : Operting mode clock and power mode selection. Specifies two

s/Operting/Operating/

I'd prefer "power" to "pwr" (though there's precedent for both in
bindings...).

> +  cells of standby-mode-en and dynamic_clk_gating_en.

More boolean properties.

>  - interrupts : 1 combined interrupt.
>  - cache-id-part: cache id part number to be used if it is not present
>    on hardware

No amendments to the example?

> diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
> index 3b2c40b..188f4da 100644
> --- a/arch/arm/include/asm/hardware/cache-l2x0.h
> +++ b/arch/arm/include/asm/hardware/cache-l2x0.h
> @@ -106,6 +106,29 @@
>  
>  #define L2X0_WAY_SIZE_SHIFT		3
>  
> +#define L2X0_PREFETCH_CTRL_OFFSET_SHIFT			0
> +#define L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT		21
> +#define L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT	23
> +#define L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT		24
> +#define L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT	27
> +#define L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT	28
> +#define L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT	29
> +#define L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT	30
> +
> +#define PREFETCH_R2P0_MASK	(~(1 << L2X0_PREFETCH_CTRL_OFFSET_SHIFT))
> +#define PREFETCH_R3P0_MASK \
> +		(~((1 << L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT) | \
> +		   (1 << L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT) | \
> +		   (1 << L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT) | \
> +		   (1 << L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT) | \
> +		   (1 << L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT) | \
> +		   (1 << L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT)))
> +#define PREFETCH_R3P1_MASK \
> +		(~(1 << L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT))
> +
> +#define L2X0_PWR_CTRL_STANDBY_MODE_EN_SHIFT	0
> +#define L2X0_PWR_CTRL_DYNAMIC_CLK_GATE_EN_SHIFT	1
> +
>  #ifndef __ASSEMBLY__
>  extern void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask);
>  #if defined(CONFIG_CACHE_L2X0) && defined(CONFIG_OF)
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index c465fac..490e182 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -563,6 +563,11 @@ static void __init pl310_of_setup(const struct device_node *np,
>  	u32 data[3] = { 0, 0, 0 };
>  	u32 tag[3] = { 0, 0, 0 };
>  	u32 filter[2] = { 0, 0 };
> +	u32 prefetch[8] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> +	u32 prefetch_val;
> +	u32 pwr[2] = { 0, 0 };
> +	u32 l2x0_revision = readl_relaxed(l2x0_base + L2X0_CACHE_ID) &
> +		L2X0_CACHE_ID_RTL_MASK;
>  
>  	of_property_read_u32_array(np, "arm,tag-latency", tag, ARRAY_SIZE(tag));
>  	if (tag[0] && tag[1] && tag[2])
> @@ -589,6 +594,45 @@ static void __init pl310_of_setup(const struct device_node *np,
>  		writel_relaxed((filter[0] & ~(SZ_1M - 1)) | L2X0_ADDR_FILTER_EN,
>  			       l2x0_base + L2X0_ADDR_FILTER_START);
>  	}
> +
> +	if (l2x0_revision >= L2X0_CACHE_ID_RTL_R2P0) {

You didn't describe that some properties were dependent on a particular
revision.

> +		of_property_read_u32_array(np, "arm,prefetch-control",
> +						prefetch, ARRAY_SIZE(prefetch));
> +		prefetch_val = readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
> +		prefetch_val &= PREFETCH_R2P0_MASK;
> +		prefetch_val |= prefetch[0] << L2X0_PREFETCH_CTRL_OFFSET_SHIFT;
> +		if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P0) {
> +			prefetch_val &= PREFETCH_R3P0_MASK;
> +			prefetch_val |=
> +			 ((prefetch[1]) <<
> +			   L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT) |
> +			 ((prefetch[2]) <<
> +			   L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT) |
> +			 ((prefetch[3]) <<
> +			   L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT) |
> +			 ((prefetch[5]) <<
> +			   L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT) |
> +			 ((prefetch[6]) <<
> +			   L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT) |
> +			 ((prefetch[7]) <<
> +			   L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT);

You've not sanity checked these properties. What If I typo a value as
something other than 0 or 1?

Use boolean properties and of_property_read_bool (or even better,
configure this dynamically based on revision rather than having a dt
description).

> +			if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P1) {
> +				prefetch_val &= PREFETCH_R3P1_MASK;
> +				prefetch_val |=
> +				 ((prefetch[4]) <<
> +				   L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT);
> +			}

Another undocumented revision dependency.

> +			writel_relaxed(prefetch_val,
> +					l2x0_base + L2X0_PREFETCH_CTRL);
> +
> +			of_property_read_u32_array(np, "arm,pwr-control",
> +						pwr, ARRAY_SIZE(pwr));
> +			writel_relaxed(
> +			 ((pwr[0]) << L2X0_PWR_CTRL_STANDBY_MODE_EN_SHIFT) |
> +			 ((pwr[1]) << L2X0_PWR_CTRL_DYNAMIC_CLK_GATE_EN_SHIFT),
> +			   l2x0_base + L2X0_POWER_CTRL);

Again, use boolean properties or do this dynamically.

Do none of these values need to be saved for the resume callback?

Thanks,
Mark.

> +		}
> +	}
>  }
>  
>  static void __init pl310_save(void)
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From catalin.marinas at arm.com  Tue Jul 23 06:23:34 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Jul 2013 11:23:34 +0100
Subject: [PATCH v2 1/3] drivers: clocksource: configure event stream for
 ARM arch timer
In-Reply-To: <1374492082-13686-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1371575223-21702-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492082-13686-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492082-13686-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <20130723102334.GC3748@MacBook-Pro.local>

On Mon, Jul 22, 2013 at 12:21:20PM +0100, Sudeep KarkadaNagesha wrote:
> From: Will Deacon <will.deacon at arm.com>
> 
> The ARM architected timer can generate events (used for waking up
> CPUs executing the wfe instruction) at a frequency represented as a
> power-of-2 divisor of the clock rate.
> 
> This patch configures the event stream, aiming for a period of 100us
> between events. This can be used to implement wfe-based timeouts for
> userspace locking implementations.
...
> --- a/include/clocksource/arm_arch_timer.h
> +++ b/include/clocksource/arm_arch_timer.h
> @@ -29,6 +29,8 @@
>  #define ARCH_TIMER_PHYS_ACCESS		0
>  #define ARCH_TIMER_VIRT_ACCESS		1
>  
> +#define ARCH_TIMER_EVT_STREAM_FREQ	10000	/* 100us */

BTW, if user-space starts using this, it will become an ABI. Is this the
right frequency?

In addition, do we want to expose this via hwcap? Something like
HWCAP_EVSTR100US?

-- 
Catalin


From padma.kvr at gmail.com  Tue Jul 23 06:25:04 2013
From: padma.kvr at gmail.com (Padma Venkat)
Date: Tue, 23 Jul 2013 15:55:04 +0530
Subject: [PATCH 2/4] clk: exynos-audss: allow input clocks to be specified
 in device tree
In-Reply-To: <5824726.DGbrnrmYE0@flatron>
References: <1373458313-18970-1-git-send-email-padma.v@samsung.com>
 <1610421.OFFn8rqlxt@amdc1227> <20130722181530.7598.73318@quantum>
 <5824726.DGbrnrmYE0@flatron>
Message-ID: <CAAgF-BeKm3EqyV9UAt0i44-dXK3n58RuCTYiRBNpsW=aED_tkg@mail.gmail.com>

Hi Tomasz,

On Tue, Jul 23, 2013 at 1:12 AM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> On Monday 22 of July 2013 11:15:30 Mike Turquette wrote:
>> Quoting Tomasz Figa (2013-07-22 09:28:47)
>>
>> > Hi Padmavathi, Andrew,
>> >
>> > On Wednesday 10 of July 2013 17:41:51 Padmavathi Venna wrote:
>> > > From: Andrew Bresticker <abrestic at chromium.org>
>> > >
>> > > This allows the input clocks to the Exynos AudioSS block to be
>> > > specified via device-tree bindings.  Default names will be used
>> > > when an input clock is not given.  This will be useful when adding
>> > > support for the Exynos5420 where the audio bus clock is called
>> > > "sclk_maudio0" instead of "sclk_audio0".
>> > >
>> > > Signed-off-by: Andrew Bresticker <abrestic at chromium.org>
>> > > Reviewed-on: https://gerrit.chromium.org/gerrit/57833
>> > > Reviewed-by: Simon Glass <sjg at chromium.org>
>> > > ---
>> > >
>> > >  .../devicetree/bindings/clock/clk-exynos-audss.txt |   31
>> > >
>> > > ++++++++++++++++++- drivers/clk/samsung/clk-exynos-audss.c
>> > >   |> >
>> > >   28 +++++++++++++++-- 2 files changed, 53 insertions(+), 6
>> > >   deletions(-)
>> >
>> > Well, this is basically how it should be done, but in current state of
>> > clock core I can see a problem: can we really rely on the order of
>> > clock initialization? I mean, we can't defer initialization of
>> > particular clock controller until all external clocks it needs are
>> > available, because there is no probing involved here.

your point is valid. In this case audio clk controller registration
happening only after CMU clk
controller from which audss needs clks. So this patch can't be taken in?

Thanks
Padma

>>
>> The clock core allows registering clocks even if their parents are not
>> yet registered. I test this path with some dummy clocks every so often
>> to make sure the re-parenting operation are completed successfully after
>> the parents eventually are registered.
>
> Sure it does, but this patch is about something different. It adds device
> tree based lookup (of_clk_get_by_name()) of external clocks (as opposed to
> existing lookup by name), which will fail if provider pointed by phandle
> is not registered yet.
>
>> This feature was not used in practice until recently with the advent of
>> multiple clock controllers getting registered and DT description of
>> clocks / clock controllers that may be "out of order". If you find any
>> bugs please let me know ;-)
>
> I will send you a bunch of patches sorting out issues I found in
> clk_set_rate() path, but give me some time to prepare them :).
>
> As for multiple clock controllers, this is going to be funny. I have
> discussed this a bit with Sylwester and we managed to find some design
> issues that I think must be solved:
>
> a) What about multiple controllers with identical clock names? Imagine two
> PMICs that can also generate 32 KHz clocks, both having them named
> "clk32k". Am I right saying that this won't work with current code?
>
> b) What are the rules of using clock-output-names property (and what
> should be used in non-DT case)? I can imagine using it to assign platform-
> specific names of clock outputs of extra clock controllers (this would
> help in the above case of "clk32k"), but currently it seems like it is
> optional to use it in clock drivers and the meaning is provider-specific.
>
> Best regards,
> Tomasz
>


From catalin.marinas at arm.com  Tue Jul 23 06:25:54 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Jul 2013 11:25:54 +0100
Subject: linux setup
In-Reply-To: <CANEcUBXMPhTjgVYbRN7NY+EUjh7DDGpKnZ8_LXY-ZLcfbH65Ug@mail.gmail.com>
References: <CANEcUBXMPhTjgVYbRN7NY+EUjh7DDGpKnZ8_LXY-ZLcfbH65Ug@mail.gmail.com>
Message-ID: <20130723102554.GD3748@MacBook-Pro.local>

On Mon, Jul 22, 2013 at 02:28:50PM +0100, zhaobin xv wrote:
> I recently read lernel source .
> I have a question:In
> folder:linux/arch/arm/boot/compressed/head.S(linux2.6.22.6):
> 
> 
> start:
>         .type    start,#function
>         .rept    8
>         mov    r0, r0
>         .endr
> 
>         b    1f
>         .word    0x016f2818        @ Magic numbers to help the loader
>         .word    start            @ absolute load/run zImage address
>         .word    _edata            @ zImage end address
> 1:        mov    r7, r1            @ save architecture ID
>         mov    r8, r2            @ save atags pointer
> 
> 
> I don't kown why the ?mov r0 r0 ? repeated  emergence 8 times.

I think some people used that in the past to be able to modify the
zImage binary directly and work around wrong register values passed by
the boot loader. I've never used it myself but I saw it mentioned once.

-- 
Catalin


From inki.dae at samsung.com  Tue Jul 23 06:31:54 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Tue, 23 Jul 2013 19:31:54 +0900
Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to an
 IOMMU group
In-Reply-To: <1374573694-30595-1-git-send-email-a.motakis@virtualopensystems.com>
References: <1374573694-30595-1-git-send-email-a.motakis@virtualopensystems.com>
Message-ID: <00d701ce878f$da099fe0$8e1cdfa0$%dae@samsung.com>



> -----Original Message-----
> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
> owner at vger.kernel.org] On Behalf Of Antonios Motakis
> Sent: Tuesday, July 23, 2013 7:02 PM
> To: linux-arm-kernel at lists.infradead.org;
iommu at lists.linux-foundation.org;
> linux-samsung-soc at vger.kernel.org
> Cc: kvmarm at lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo; Joerg
> Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to
> an IOMMU group
> 
> IOMMU groups are expected by certain users of the IOMMU API,
> e.g. VFIO. Since each device is behind its own System MMU, we
> can allocate a new IOMMU group for each device.
> 
> This patch depends on Cho KyongHo's patch series titled "[PATCH v7 00/12]
> iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> applied on a Linux 3.10.1 kernel. It has been tested on the Arndale board.
> 
> Signed-off-by: Antonios Motakis <a.motakis at virtualopensystems.com>
> ---
>  drivers/iommu/exynos-iommu.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 51d43bb..9f39eaa 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1134,6 +1134,28 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct
> iommu_domain *domain,
>  	return phys;
>  }
> 
> +static int exynos_iommu_add_device(struct device *dev)
> +{
> +	struct iommu_group *group;
> +	int ret;
> +
> +	group = iommu_group_alloc();

Is that correct? I don't see why you allocate a group object every time
add_device callback is called. That doesn't have any meaning we have to use
iommu group feature. I think the implementation should be one more devices
per a group. So I guess a given device object should be wrapped by higher
device object than the given device object. For a good example, you can
refer to intel-iommu.c file.

Thanks,
Inki Dae

> +	if (IS_ERR(group)) {
> +		dev_err(dev, "Failed to allocate IOMMU group\n");
> +		return PTR_ERR(group);
> +	}
> +
> +	ret = iommu_group_add_device(group, dev);
> +	iommu_group_put(group);
> +
> +	return ret;
> +}
> +
> +static void exynos_iommu_remove_device(struct device *dev)
> +{
> +	iommu_group_remove_device(dev);
> +}
> +
>  static struct iommu_ops exynos_iommu_ops = {
>  	.domain_init = &exynos_iommu_domain_init,
>  	.domain_destroy = &exynos_iommu_domain_destroy,
> @@ -1142,6 +1164,8 @@ static struct iommu_ops exynos_iommu_ops = {
>  	.map = &exynos_iommu_map,
>  	.unmap = &exynos_iommu_unmap,
>  	.iova_to_phys = &exynos_iommu_iova_to_phys,
> +	.add_device	= exynos_iommu_add_device,
> +	.remove_device	= exynos_iommu_remove_device,
>  	.pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
>  };
> 
> --
> 1.8.1.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From will.deacon at arm.com  Tue Jul 23 06:33:33 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 11:33:33 +0100
Subject: [PATCH v2 1/3] drivers: clocksource: configure event stream for
 ARM arch timer
In-Reply-To: <20130723102334.GC3748@MacBook-Pro.local>
References: <1371575223-21702-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492082-13686-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492082-13686-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <20130723102334.GC3748@MacBook-Pro.local>
Message-ID: <20130723103333.GB30942@mudshark.cambridge.arm.com>

On Tue, Jul 23, 2013 at 11:23:34AM +0100, Catalin Marinas wrote:
> On Mon, Jul 22, 2013 at 12:21:20PM +0100, Sudeep KarkadaNagesha wrote:
> > From: Will Deacon <will.deacon at arm.com>
> > 
> > The ARM architected timer can generate events (used for waking up
> > CPUs executing the wfe instruction) at a frequency represented as a
> > power-of-2 divisor of the clock rate.
> > 
> > This patch configures the event stream, aiming for a period of 100us
> > between events. This can be used to implement wfe-based timeouts for
> > userspace locking implementations.
> ...
> > --- a/include/clocksource/arm_arch_timer.h
> > +++ b/include/clocksource/arm_arch_timer.h
> > @@ -29,6 +29,8 @@
> >  #define ARCH_TIMER_PHYS_ACCESS		0
> >  #define ARCH_TIMER_VIRT_ACCESS		1
> >  
> > +#define ARCH_TIMER_EVT_STREAM_FREQ	10000	/* 100us */
> 
> BTW, if user-space starts using this, it will become an ABI. Is this the
> right frequency?

It doesn't quite become ABI; not all platforms will use the architected
timers and not all timers can support an arbitrary frequency. The best we
can do is calculate something as close to the target value as possible.

I spoke to both tools developers and some HSA driver guys about the frequency,
and this is what ended up being suggested.

> In addition, do we want to expose this via hwcap? Something like
> HWCAP_EVSTR100US?

Hmm, maybe, but we don't want people to try and use this for any accurate
time measurements, so I wouldn't include the period.

Will


From jonathan.austin at arm.com  Tue Jul 23 06:33:55 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Tue, 23 Jul 2013 11:33:55 +0100
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
Message-ID: <51EE5C13.1000004@arm.com>

Hi Paul,

On 22/07/13 19:07, Paul Walmsley wrote:
>
> Hi,
>
> After Linus's commit fb2af0020a51709ad87ea8055c325d3fbde04158 ("Merge
> branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm"), the
> OMAP2430 SDP here stopped booting.
>
> Here's the bootlog at the commit before the merge, commit 790eac5640:
>
> http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722015454/
>
> and here's a log at commit fb2af0020a5:
>
> http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722005921/
>
> Any ideas as to what might have caused this?
>

I've just had a quick go at booting 3.11-rc2 on an integrator-cp (1136) 
in the hope that we might be able to reproduce this on those boards, but 
I'm afraid the integrator works...

I took your config, modified it as little as possible to switch to 
Integrator and turn on earlyprintk, and then tried to boot. That *did* 
require switching away from ARCH_MULTIPLATFORM, so it isn't as similar 
as I'd like, though...

So I think we can at least say that this is not 1136 specific... Sorry 
not to be more helpful...

Jonny




From linux at arm.linux.org.uk  Tue Jul 23 06:37:04 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Jul 2013 11:37:04 +0100
Subject: scatterlist: sg_set_buf() argument must be in linear mapping
 (sha1: ac4e97abce9b80c020e7113325f49e58b7b15e3f)
In-Reply-To: <87ppua9feh.fsf@rustcorp.com.au>
References: <51E64C6B.3080306@monstr.eu> <87siz7xt4z.fsf@rustcorp.com.au>
 <51ED2C74.7050502@monstr.eu> <87ppua9feh.fsf@rustcorp.com.au>
Message-ID: <20130723103704.GS24642@n2100.arm.linux.org.uk>

On Tue, Jul 23, 2013 at 12:00:30PM +0930, Rusty Russell wrote:
> Michal Simek <monstr at monstr.eu> writes:
> > Let me take some code from virtio_rpmsg_bus.c to show that problematic part.
> >
> > bufs_va = dma_alloc_coherent(vdev->dev.parent->parent,
> > 				RPMSG_TOTAL_BUF_SPACE,
> > 				&vrp->bufs_dma, GFP_KERNEL);
> > vrp->rbufs = bufs_va;
> > for (i = 0; i < RPMSG_NUM_BUFS / 2; i++) {
> > 	struct scatterlist sg;
> > 	void *cpu_addr = vrp->rbufs + i * RPMSG_BUF_SIZE;
> >
> > 	sg_init_one(&sg, cpu_addr, RPMSG_BUF_SIZE);
> > }
> 
> Hmm.  Looking at arch/arm/include/asm/memory.h:
> 
> #define virt_to_page(kaddr)	pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
> #define virt_addr_valid(kaddr)	((unsigned long)(kaddr) >= PAGE_OFFSET && (unsigned long)(kaddr) < (unsigned long)high_memory)
> 
> pfn_to_page in ARM seems to be the asm-generic one, which depends on
> CONFIG_SPARSEMEM/CONFIG_DISCONTIGMEM/CONFIG_FLATMEM etc.
> 
> Perhaps virt_addr_valid() is wrong for your config?  It's pretty clear
> that you shouldn't call virt_to_page() on something for which
> !virt_addr_valid().

The above code fragment is just wrong.  You can't make any assumptions about
the memory returned from dma_alloc_coherent(), because:

- On x86, it is kernel direct mapped memory, where things like
  virt_to_phys(cpuaddr) will work fine with it.

- On any architecture which needs to remap memory to make it coherent
  with the DMA device, the key word there is "remap" - it's not kernel
  direct mapped memory, and virt_to_phys(cpuaddr) on it is illegal.

The only valid operation with scatterlists and such memory returned from
dma_alloc_coherent() is:

	sg_dma_address(sg) = dma_address;
	sg_dma_len(sg) = dma_length;

and not to use the virtual address(es) at all in the scatterlist.  And
it is very very important to realise that you must not mix the streaming
and coherent DMA APIs - you must never pass coherent memory into the
dma_map_* functions.


From catalin.marinas at arm.com  Tue Jul 23 06:41:14 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Jul 2013 11:41:14 +0100
Subject: [PATCH 3/4] arm64: KVM: let other tasks run when hitting WFE
In-Reply-To: <CAMJs5B8Sg1MPHPsRV75mmagnYxkhzA0MKWVkwW2y0WdDVWTSxQ@mail.gmail.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
 <CAC4Lta17bmNjBck6LzziBeU0Xc36F1Jms2tQPv6+GaXvik6Wyg@mail.gmail.com>
 <CAMJs5B8Sg1MPHPsRV75mmagnYxkhzA0MKWVkwW2y0WdDVWTSxQ@mail.gmail.com>
Message-ID: <20130723104113.GE3748@MacBook-Pro.local>

On Mon, Jul 22, 2013 at 01:51:52PM +0100, Christoffer Dall wrote:
> On 22 July 2013 10:53, Raghavendra KT <raghavendra.kt.linux at gmail.com> wrote:
> > On Fri, Jul 19, 2013 at 7:23 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> >> So far, when a guest executes WFE (like when waiting for a spinlock
> >> to become unlocked), we don't do a thing and let it run uninterrupted.
> >>
> >> Another option is to trap a blocking WFE and offer the opportunity
> >> to the scheduler to switch to another task, potentially giving the
> >> vcpu holding the spinlock a chance to run sooner.
> >>
> >
> > Idea looks to be correct from my experiments on x86. It does bring some
> > percentage of benefits in overcommitted guests. Infact,
> >
> > https://lkml.org/lkml/2013/7/22/41 tries to do the same thing for x86.
> > (this results in using ple handler heuristics in vcpu_block pach).
> 
> What about the adverse effect in the non-overcommitted case?

Could we not detect overcommitment and only set the TWE bit in this case
(per VCPU scheduled to run)?

The advantage of a properly para-virtualised lock is that you can target
which VCPU to wake up. I don't think we can do this currently (without
assumptions about the underlying OS and how the compiler allocates
registers in the ticket spinlocks).

There have been suggestions to use WFE in user-space for a more power
efficient busy loop (usually in user-only locking, I think some
PostreSQL does that) together with an automatic even stream for waking
up the WFE (Sudeep posted some patches recently for enabling 100us event
stream). If such feature gets used, we have a new meaning for WFE and we
may not want to trap it all the time.

Question for Will - do we have a PMU counter for WFE? (don't ask why ;))

-- 
Catalin


From Dave.Martin at arm.com  Tue Jul 23 06:43:57 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Tue, 23 Jul 2013 11:43:57 +0100
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <alpine.LFD.2.03.1307221353360.15022@syhkavp.arg>
References: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
 <1374118116-16836-2-git-send-email-nicolas.pitre@linaro.org>
 <20130718150408.GB2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181231510.14924@syhkavp.arg>
 <20130718180323.GC2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181452480.14924@syhkavp.arg>
 <20130719102844.GA3746@localhost.localdomain>
 <20130719105907.GB27389@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307221353360.15022@syhkavp.arg>
Message-ID: <20130723104352.GA3023@localhost.localdomain>

On Mon, Jul 22, 2013 at 01:58:12PM -0400, Nicolas Pitre wrote:
> On Fri, 19 Jul 2013, Lorenzo Pieralisi wrote:
> 
> > On Fri, Jul 19, 2013 at 11:28:49AM +0100, Dave Martin wrote:
> > > On Thu, Jul 18, 2013 at 02:59:06PM -0400, Nicolas Pitre wrote:
> > > > On Thu, 18 Jul 2013, Dave Martin wrote:
> > > > 
> > > > > I had other names in mind, like "coherency_exit" or "cache_exit".
> > > > > Those are not very intelligible, but that might at least make people
> > > > > pause and think before blindly using it.
> > > > 
> > > > Good point.  It should still embody the architecture name for which it 
> > > > is valid though.
> > > 
> > > Sure, I was assuming something would be pasted on the start of the name.
> > 
> > v7 :-) with a comment describing the assumptions (in particular related
> > as Dave mentioned to the SMP bit behaviour) ?
> 
> OK... What about this then:
> 
> ----- >8
> From: Nicolas Pitre <nicolas.pitre at linaro.org>
> Date: Thu, 18 Jul 2013 13:12:48 -0400
> Subject: [PATCH] ARM: cacheflush: consolidate single-CPU ARMv7 cache disabling
>  code
> 
> This code is becoming duplicated in many places.  So let's consolidate
> it into a handy macro that is known to be right and available for reuse.
> 
> Signed-off-by: Nicolas Pitre <nico at linaro.org>
> 
> diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
> index 17d0ae8672..8f4e2297e2 100644
> --- a/arch/arm/include/asm/cacheflush.h
> +++ b/arch/arm/include/asm/cacheflush.h
> @@ -436,4 +436,44 @@ static inline void __sync_cache_range_r(volatile void *p, size_t size)
>  #define sync_cache_w(ptr) __sync_cache_range_w(ptr, sizeof *(ptr))
>  #define sync_cache_r(ptr) __sync_cache_range_r(ptr, sizeof *(ptr))
>  
> +/*
> + * Disabling cache access for one CPU in an ARMv7 SMP system is tricky.
> + * To do so we must:
> + *
> + * - Clear the SCTLR.C bit to prevent further cache allocations
> + * - Flush the desired level of cache
> + * - Clear the ACTLR "SMP" bit to disable local coherency
> + *
> + * ... and so without any intervening memory access in between those steps,
> + * not even to the stack.
> + *
> + * WARNING -- After this has been called:
> + *
> + * - No ldr/str exclusive must be used.

Maybe write ldrex/strex (I misread that the first time around as "no
ldr/str ... must be used", which seemed a bit drastic)

> + * - The CPU is obviously no longer coherent with the other CPUs.
> + *
> + * Further considerations:
> + *
> + * - This relies on the presence and behavior of the AUXCR.SMP bit as
> + *   documented in the ARMv7 TRM.  Vendor implementations that deviate from

Sorry to be pedantic here, but there is no "ARMv7 TRM".  The SMP bit is
not part of ARMv7 at all.  Also, it seems that A9 isn't precisely the
same: two ACTLR bits need to be twiddled.  R-class CPUs are generally
not the same either.

This is why I preferred to treat the whole sequence as specific to a
particular CPU implementation.  The similarity between A7 and A15
might be viewed as a happy coincidence (it also makes life easier in
big.LITTLE land).

(Also, you mix the names "ACTLR" and "AUXCR", but people will generally
be able to guess those are the same thing)

 
> + *   that will need their own procedure.
> + * - This is unlikely to work if Linux is running non-secure.
> + */
> +#define v7_exit_coherency_flush(level) \

... hence:

#define cortex_a15_exit_coherency(level) ...

#define cortex_a7_exit_coherency(level) cortex_a15_exit_coherency(level)


What do you think?

Cheers
---Dave

> +	asm volatile( \
> +	"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t" \
> +	"bic	r0, r0, #"__stringify(CR_C)" \n\t" \
> +	"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t" \
> +	"isb	\n\t" \
> +	"bl	v7_flush_dcache_"__stringify(level)" \n\t" \
> +	"clrex	\n\t" \
> +	"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t" \
> +	"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t" \
> +	"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t" \
> +	"isb	\n\t" \
> +	"dsb	" \
> +	/* The clobber list is dictated by the call to v7_flush_dcache_* */ \
> +	: : : "r0","r1","r2","r3","r4","r5","r6","r7", \
> +	      "r9","r10","r11","lr","memory" )
> +
>  #endif
> diff --git a/arch/arm/mach-vexpress/dcscb.c b/arch/arm/mach-vexpress/dcscb.c
> index 85fffa702f..14d4996887 100644
> --- a/arch/arm/mach-vexpress/dcscb.c
> +++ b/arch/arm/mach-vexpress/dcscb.c
> @@ -133,32 +133,8 @@ static void dcscb_power_down(void)
>  	if (last_man && __mcpm_outbound_enter_critical(cpu, cluster)) {
>  		arch_spin_unlock(&dcscb_lock);
>  
> -		/*
> -		 * Flush all cache levels for this cluster.
> -		 *
> -		 * To do so we do:
> -		 * - Clear the SCTLR.C bit to prevent further cache allocations
> -		 * - Flush the whole cache
> -		 * - Clear the ACTLR "SMP" bit to disable local coherency
> -		 *
> -		 * Let's do it in the safest possible way i.e. with
> -		 * no memory access within the following sequence
> -		 * including to the stack.
> -		 */
> -		asm volatile(
> -		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
> -		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
> -		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
> -		"isb	\n\t"
> -		"bl	v7_flush_dcache_all \n\t"
> -		"clrex	\n\t"
> -		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
> -		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
> -		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
> -		"isb	\n\t"
> -		"dsb	"
> -		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
> -		      "r9","r10","r11","lr","memory");
> +		/* Flush all cache levels for this cluster. */
> +		v7_exit_coherency_flush(all);
>  
>  		/*
>  		 * This is a harmless no-op.  On platforms with a real
> @@ -177,24 +153,8 @@ static void dcscb_power_down(void)
>  	} else {
>  		arch_spin_unlock(&dcscb_lock);
>  
> -		/*
> -		 * Flush the local CPU cache.
> -		 * Let's do it in the safest possible way as above.
> -		 */
> -		asm volatile(
> -		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
> -		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
> -		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
> -		"isb	\n\t"
> -		"bl	v7_flush_dcache_louis \n\t"
> -		"clrex	\n\t"
> -		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
> -		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
> -		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
> -		"isb	\n\t"
> -		"dsb	"
> -		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
> -		      "r9","r10","r11","lr","memory");
> +		/* Disable and flush the local CPU cache. */
> +		v7_exit_coherency_flush(louis);
>  	}
>  
>  	__mcpm_cpu_down(cpu, cluster);
> diff --git a/arch/arm/mach-vexpress/tc2_pm.c b/arch/arm/mach-vexpress/tc2_pm.c
> index dfb55d45b6..5940f1e317 100644
> --- a/arch/arm/mach-vexpress/tc2_pm.c
> +++ b/arch/arm/mach-vexpress/tc2_pm.c
> @@ -134,26 +134,7 @@ static void tc2_pm_down(u64 residency)
>  			: : "r" (0x400) );
>  		}
>  
> -		/*
> -		 * We need to disable and flush the whole (L1 and L2) cache.
> -		 * Let's do it in the safest possible way i.e. with
> -		 * no memory access within the following sequence
> -		 * including the stack.
> -		 */
> -		asm volatile(
> -		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
> -		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
> -		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
> -		"isb	\n\t"
> -		"bl	v7_flush_dcache_all \n\t"
> -		"clrex	\n\t"
> -		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
> -		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
> -		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
> -		"isb	\n\t"
> -		"dsb	"
> -		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
> -		      "r9","r10","r11","lr","memory");
> +		v7_exit_coherency_flush(all);
>  
>  		cci_disable_port_by_cpu(mpidr);
>  
> @@ -169,24 +150,7 @@ static void tc2_pm_down(u64 residency)
>  
>  		arch_spin_unlock(&tc2_pm_lock);
>  
> -		/*
> -		 * We need to disable and flush only the L1 cache.
> -		 * Let's do it in the safest possible way as above.
> -		 */
> -		asm volatile(
> -		"mrc	p15, 0, r0, c1, c0, 0	@ get CR \n\t"
> -		"bic	r0, r0, #"__stringify(CR_C)" \n\t"
> -		"mcr	p15, 0, r0, c1, c0, 0	@ set CR \n\t"
> -		"isb	\n\t"
> -		"bl	v7_flush_dcache_louis \n\t"
> -		"clrex	\n\t"
> -		"mrc	p15, 0, r0, c1, c0, 1	@ get AUXCR \n\t"
> -		"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t"
> -		"mcr	p15, 0, r0, c1, c0, 1	@ set AUXCR \n\t"
> -		"isb	\n\t"
> -		"dsb	"
> -		: : : "r0","r1","r2","r3","r4","r5","r6","r7",
> -		      "r9","r10","r11","lr","memory");
> +		v7_exit_coherency_flush(louis);
>  	}
>  
>  	__mcpm_cpu_down(cpu, cluster);
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From julien.grall at linaro.org  Tue Jul 23 06:52:18 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Tue, 23 Jul 2013 11:52:18 +0100
Subject: [PATCH v4] xen/arm: enable PV control for ARM
In-Reply-To: <5228e08a-1cdb-4240-b10f-9ad690c94ac4@email.android.com>
References: <1374529321-12955-1-git-send-email-julien.grall@linaro.org>
 <5228e08a-1cdb-4240-b10f-9ad690c94ac4@email.android.com>
Message-ID: <51EE6062.3080304@linaro.org>

On 07/23/2013 01:32 AM, Konrad Rzeszutek Wilk wrote:
> Julien Grall <julien.grall at linaro.org> wrote:
>> Enable power management from the toolstack for ARM guest.
>>
>> Signed-off-by: Julien Grall <julien.grall at linaro.org>
>>
>> ---
>>    Changes in v4:
>>        - Divide the patch in 2 distinct parts
>>    Changes in v3:
>>        - Fix condition to compile cpu_hotplug.o
>>    Changes in v2:
>>        - Don't compile xen/cpu_hotplug.o with ARM64
>> ---
>> drivers/xen/Makefile |    3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
>> index a609353..f185e8d 100644
>> --- a/drivers/xen/Makefile
>> +++ b/drivers/xen/Makefile
>> @@ -1,9 +1,8 @@
>> ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
>> -obj-y	+= manage.o
>> obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>> endif
>> obj-$(CONFIG_X86)			+= fallback.o
>> -obj-y	+= grant-table.o features.o events.o balloon.o time.o
>> +obj-y	+= grant-table.o features.o events.o balloon.o time.o manage.o
>> obj-y	+= xenbus/
>>
>> nostackp := $(call cc-option, -fno-stack-protector)
> 
> The patch looks Ok but the description is off.  Power management is the term used for cpu freq,  C states and P states. While this patch touches none of that. 
> 

What about : "Enable lifecycle (reboot, shutdown) management from the
toolstack for ARM guest"?

-- 
Julien



From Sudeep.KarkadaNagesha at arm.com  Tue Jul 23 06:54:10 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Tue, 23 Jul 2013 11:54:10 +0100
Subject: [PATCH v3 01/16] of: add support for retrieving cpu node for a given
 logical cpu index
In-Reply-To: <51ED4A99.3030403@arm.com>
References: <51ED4A99.3030403@arm.com>
Message-ID: <1374576850-9667-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Currently different drivers requiring to access cpu device node are
parsing the device tree themselves. Since the ordering in the DT need
not match the logical cpu ordering, the parsing logic needs to consider
that. However, this has resulted in lots of code duplication and in some
cases even incorrect logic.

It's better to consolidate them by adding support for getting cpu
device node for a given logical cpu index in DT core library. However
logical to physical index mapping can be architecture specific.

This patch adds of_get_cpu_node to retrieve a cpu device node for a
given logical cpu index. The default matching of the physical id to the
logical cpu index can be overridden by architecture specific code.

It is recommended to use these helper function only in pre-SMP/early
initialisation stages to retrieve CPU device node pointers in logical
ordering. Once the cpu devices are registered, it can be retrieved easily
from cpu device of_node which avoids unnecessary parsing and matching.

Acked-by: Rob Herring <rob.herring at calxeda.com>
Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 drivers/of/base.c   | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/cpu.h |  1 +
 include/linux/of.h  |  6 +++++
 3 files changed, 80 insertions(+)

----------------->8--------------------------
Hi Nico,

I found include/linux/cpu.h is more appropriate for this.
Is that fine ?

Regards,
Sudeep

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5c54279..052b4b2 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -18,6 +18,7 @@
  *      2 of the License, or (at your option) any later version.
  */
 #include <linux/ctype.h>
+#include <linux/cpu.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/spinlock.h>
@@ -230,6 +231,78 @@ const void *of_get_property(const struct device_node *np, const char *name,
 }
 EXPORT_SYMBOL(of_get_property);
 
+/*
+ * arch_match_cpu_phys_id - Match the given logical CPU and physical id
+ *
+ * @cpu: logical index of a cpu
+ * @phys_id: physical identifier of a cpu
+ *
+ * CPU logical to physical index mapping is architecture specific.
+ * However this __weak function provides a default match of physical
+ * id to logical cpu index.
+ *
+ * Returns true if the physical identifier and the logical index correspond
+ * to the same cpu, false otherwise.
+ */
+bool __weak arch_match_cpu_phys_id(int cpu, u64 phys_id)
+{
+	return (u32)phys_id == cpu;
+}
+
+/**
+ * of_get_cpu_node - Get device node associated with the given logical CPU
+ *
+ * @cpu: CPU number(logical index) for which device node is required
+ *
+ * The main purpose of this function is to retrieve the device node for the
+ * given logical CPU index. It should be used to initialize the of_node in
+ * cpu device. Once of_node in cpu device is populated, all the further
+ * references can use that instead.
+ *
+ * CPU logical to physical index mapping is architecture specific and is built
+ * before booting secondary cores. This function uses arch_match_cpu_phys_id
+ * which can be overridden by architecture specific implementation.
+ *
+ * Returns a node pointer for the logical cpu if found, else NULL.
+ */
+struct device_node *of_get_cpu_node(int cpu)
+{
+	struct device_node *cpun, *cpus;
+	const __be32 *cell;
+	u64 hwid;
+	int ac, prop_len;
+
+	cpus = of_find_node_by_path("/cpus");
+	if (!cpus) {
+		pr_warn("Missing cpus node, bailing out\n");
+		return NULL;
+	}
+
+	if (of_property_read_u32(cpus, "#address-cells", &ac)) {
+		pr_warn("%s: missing #address-cells\n", cpus->full_name);
+		ac = of_n_addr_cells(cpus);
+	}
+
+	for_each_child_of_node(cpus, cpun) {
+		if (of_node_cmp(cpun->type, "cpu"))
+			continue;
+		cell = of_get_property(cpun, "reg", &prop_len);
+		if (!cell) {
+			pr_warn("%s: missing reg property\n", cpun->full_name);
+			continue;
+		}
+		prop_len /= sizeof(*cell);
+		while (prop_len) {
+			hwid = of_read_number(cell, ac);
+			prop_len -= ac;
+			if (arch_match_cpu_phys_id(cpu, hwid))
+				return cpun;
+		}
+	}
+
+	return NULL;
+}
+
 /** Checks if the given "compat" string matches one of the strings in
  * the device's "compatible" property
  */
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index ab0eade..d0c8204 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -34,6 +34,7 @@ extern void cpu_remove_dev_attr(struct device_attribute *attr);
 
 extern int cpu_add_dev_attr_group(struct attribute_group *attrs);
 extern void cpu_remove_dev_attr_group(struct attribute_group *attrs);
+extern bool arch_match_cpu_phys_id(int cpu, u64 phys_id);
 
 #ifdef CONFIG_HOTPLUG_CPU
 extern void unregister_cpu(struct cpu *cpu);
diff --git a/include/linux/of.h b/include/linux/of.h
index 1fd08ca..9e82812 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -266,6 +266,7 @@ extern int of_device_is_available(const struct device_node *device);
 extern const void *of_get_property(const struct device_node *node,
 				const char *name,
 				int *lenp);
+extern struct device_node *of_get_cpu_node(int cpu);
 #define for_each_property_of_node(dn, pp) \
 	for (pp = dn->properties; pp != NULL; pp = pp->next)
 
@@ -459,6 +460,11 @@ static inline const void *of_get_property(const struct device_node *node,
 	return NULL;
 }
 
+static inline struct device_node *of_get_cpu_node(int cpu)
+{
+	return NULL;
+}
+
 static inline int of_property_read_u64(const struct device_node *np,
 				       const char *propname, u64 *out_value)
 {
-- 
1.8.1.2




From a.motakis at virtualopensystems.com  Tue Jul 23 07:00:29 2013
From: a.motakis at virtualopensystems.com (Antonios Motakis)
Date: Tue, 23 Jul 2013 13:00:29 +0200
Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to
 an IOMMU group
In-Reply-To: <00d701ce878f$da099fe0$8e1cdfa0$%dae@samsung.com>
References: <1374573694-30595-1-git-send-email-a.motakis@virtualopensystems.com>
 <00d701ce878f$da099fe0$8e1cdfa0$%dae@samsung.com>
Message-ID: <CAG8rG2wNG9wVjKxtaDzLRybvh3wPVR08j9G9OPcK=a2Gwbtg-g@mail.gmail.com>

On Tue, Jul 23, 2013 at 12:31 PM, Inki Dae <inki.dae at samsung.com> wrote:
>
>
>
> > -----Original Message-----
> > From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
> > owner at vger.kernel.org] On Behalf Of Antonios Motakis
> > Sent: Tuesday, July 23, 2013 7:02 PM
> > To: linux-arm-kernel at lists.infradead.org;
> iommu at lists.linux-foundation.org;
> > linux-samsung-soc at vger.kernel.org
> > Cc: kvmarm at lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo; Joerg
> > Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> > Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to
> > an IOMMU group
> >
> > IOMMU groups are expected by certain users of the IOMMU API,
> > e.g. VFIO. Since each device is behind its own System MMU, we
> > can allocate a new IOMMU group for each device.
> >
> > This patch depends on Cho KyongHo's patch series titled "[PATCH v7 00/12]
> > iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> > applied on a Linux 3.10.1 kernel. It has been tested on the Arndale board.
> >
> > Signed-off-by: Antonios Motakis <a.motakis at virtualopensystems.com>
> > ---
> >  drivers/iommu/exynos-iommu.c | 24 ++++++++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> > index 51d43bb..9f39eaa 100644
> > --- a/drivers/iommu/exynos-iommu.c
> > +++ b/drivers/iommu/exynos-iommu.c
> > @@ -1134,6 +1134,28 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct
> > iommu_domain *domain,
> >       return phys;
> >  }
> >
> > +static int exynos_iommu_add_device(struct device *dev)
> > +{
> > +     struct iommu_group *group;
> > +     int ret;
> > +
> > +     group = iommu_group_alloc();
>
> Is that correct? I don't see why you allocate a group object every time
> add_device callback is called. That doesn't have any meaning we have to use
> iommu group feature. I think the implementation should be one more devices
> per a group. So I guess a given device object should be wrapped by higher
> device object than the given device object. For a good example, you can
> refer to intel-iommu.c file.

With an Intel IOMMU it can be the case that 2 devices have to share
the same IOMMU mappings (i.e. you can't program them separately). With
the Exynos System MMU, there is always one System MMU per device, so
there is nothing stopping you from programming any 2 devices' mappings
differently. So yes, the right thing to do here is to have a one to
one relationship between devices and IOMMU groups.

(resending because of html mail)

Cheers,
Antonios

>
>
> Thanks,
> Inki Dae
>
> > +     if (IS_ERR(group)) {
> > +             dev_err(dev, "Failed to allocate IOMMU group\n");
> > +             return PTR_ERR(group);
> > +     }
> > +
> > +     ret = iommu_group_add_device(group, dev);
> > +     iommu_group_put(group);
> > +
> > +     return ret;
> > +}
> > +
> > +static void exynos_iommu_remove_device(struct device *dev)
> > +{
> > +     iommu_group_remove_device(dev);
> > +}
> > +
> >  static struct iommu_ops exynos_iommu_ops = {
> >       .domain_init = &exynos_iommu_domain_init,
> >       .domain_destroy = &exynos_iommu_domain_destroy,
> > @@ -1142,6 +1164,8 @@ static struct iommu_ops exynos_iommu_ops = {
> >       .map = &exynos_iommu_map,
> >       .unmap = &exynos_iommu_unmap,
> >       .iova_to_phys = &exynos_iommu_iova_to_phys,
> > +     .add_device     = exynos_iommu_add_device,
> > +     .remove_device  = exynos_iommu_remove_device,
> >       .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
> >  };
> >
> > --
> > 1.8.1.2
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> > soc" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


From festevam at gmail.com  Tue Jul 23 07:02:12 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 23 Jul 2013 08:02:12 -0300
Subject: [PATCH] ARM: Do not run dummy_flush_tlb_a15_erratum() on
 non-Cortex-A15
In-Reply-To: <51EE3B46.7020906@ti.com>
References: <1374556774-18795-1-git-send-email-festevam@gmail.com>
 <51EE3B46.7020906@ti.com>
Message-ID: <CAOMZO5Brgj2CzJXqjUfihi-aNxumvamDUGdvZuU94rHMwutCog@mail.gmail.com>

Hi Roger,

On Tue, Jul 23, 2013 at 5:13 AM, Roger Quadros <rogerq at ti.com> wrote:

>> -     if (!erratum_a15_798181())
>> -             return;
>> -
>
> Removing this if statement will cause "ipi_flush_tlb_a15_erratum" to be called
> on non A15 platforms. So I would just keep it to be safe.

I just moved the if statement into the the beginning of
dummy_flush_tlb_a15_erratum(), so ipi_flush_tlb_a15_erratum will not
be called on non-A15 systems.

Regards,

Fabio Esteva,


From catalin.marinas at arm.com  Tue Jul 23 07:07:12 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Jul 2013 12:07:12 +0100
Subject: [PATCH] ARM: Do not run dummy_flush_tlb_a15_erratum() on
 non-Cortex-A15
In-Reply-To: <51EE3B46.7020906@ti.com>
References: <1374556774-18795-1-git-send-email-festevam@gmail.com>
 <51EE3B46.7020906@ti.com>
Message-ID: <20130723110712.GF3748@MacBook-Pro.local>

On Tue, Jul 23, 2013 at 09:13:58AM +0100, Roger Quadros wrote:
> On 07/23/2013 08:19 AM, Fabio Estevam wrote:
> > From: Fabio Estevam <fabio.estevam at freescale.com>
> > 
> > Commit 93dc688 (ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 
> > (TLBI/DSB operations)) causes the following undefined instruction error on a
> > mx53 (Cortex-A8):
> > 
> > Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> > CPU: 0 PID: 275 Comm: modprobe Not tainted 3.11.0-rc2-next-20130722-00009-g9b0f371 #881
> > task: df46cc00 ti: df48e000 task.ti: df48e000
> > PC is at check_and_switch_context+0x17c/0x4d0
> > LR is at check_and_switch_context+0xdc/0x4d0
> > 
> > This problem happens because check_and_switch_context() calls 
> > dummy_flush_tlb_a15_erratum() without checking if we are really running on a 
> > Cortex-A15 or not. 
> > 
> > To avoid this issue, always check if we are running on a Cortex-A15 or not 
> > (via erratum_a15_798181()) inside dummy_flush_tlb_a15_erratum(), so that we do 
> > not need to keep doing the same check in all occurrences of 
> > dummy_flush_tlb_a15_erratum().
> > 
> > Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> > ---
> >  arch/arm/include/asm/tlbflush.h | 18 ++++++++++++++++++
> >  arch/arm/kernel/smp_tlb.c       | 23 -----------------------
> >  2 files changed, 18 insertions(+), 23 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
> > index fdbb9e3..2478b6f 100644
> > --- a/arch/arm/include/asm/tlbflush.h
> > +++ b/arch/arm/include/asm/tlbflush.h
> > @@ -443,9 +443,22 @@ static inline void local_flush_bp_all(void)
> >  		isb();
> >  }
> >  
> > +#include <asm/cputype.h>
> >  #ifdef CONFIG_ARM_ERRATA_798181
> > +static inline int erratum_a15_798181(void)
> > +{
> > +	unsigned int midr = read_cpuid_id();
> > +
> > +	/* Cortex-A15 r0p0..r3p2 affected */
> > +	if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2)
> > +		return 0;
> > +	return 1;
> > +}
> > +
> >  static inline void dummy_flush_tlb_a15_erratum(void)
> >  {
> > +	if (!erratum_a15_798181())
> > +		return;
> >  	/*
> >  	 * Dummy TLBIMVAIS. Using the unmapped address 0 and ASID 0.
> >  	 */
> > @@ -453,6 +466,11 @@ static inline void dummy_flush_tlb_a15_erratum(void)
> >  	dsb();
> >  }
> >  #else
> > +static inline int erratum_a15_798181(void)
> > +{
> > +	return 0;
> > +}
> > +
> >  static inline void dummy_flush_tlb_a15_erratum(void)
> >  {
> >  }
> > diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
> > index a98b62d..29e9038 100644
> > --- a/arch/arm/kernel/smp_tlb.c
> > +++ b/arch/arm/kernel/smp_tlb.c
> > @@ -70,23 +70,6 @@ static inline void ipi_flush_bp_all(void *ignored)
> >  	local_flush_bp_all();
> >  }
> >  
> > -#ifdef CONFIG_ARM_ERRATA_798181
> > -static int erratum_a15_798181(void)
> > -{
> > -	unsigned int midr = read_cpuid_id();
> > -
> > -	/* Cortex-A15 r0p0..r3p2 affected */
> > -	if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2)
> > -		return 0;
> > -	return 1;
> > -}
> > -#else
> > -static int erratum_a15_798181(void)
> > -{
> > -	return 0;
> > -}
> > -#endif
> > -
> >  static void ipi_flush_tlb_a15_erratum(void *arg)
> >  {
> >  	dmb();
> > @@ -94,9 +77,6 @@ static void ipi_flush_tlb_a15_erratum(void *arg)
> >  
> >  static void broadcast_tlb_a15_erratum(void)
> >  {
> > -	if (!erratum_a15_798181())
> > -		return;
> > -
> 
> Removing this if statement will cause "ipi_flush_tlb_a15_erratum" to be called
> on non A15 platforms. So I would just keep it to be safe.

I agree, this must stay. But to avoid erratum_a15_798181() called too
many times, I would rather add the condition in
check_and_switch_context() where dummy_flush_tlb_a15_erratum() is
called.

An alternative (and Will has a patch) is to always use
cpumask_setall(&tlb_flush_pending) in flush_context() and the
check_and_switch_context() function doesn't need to guarantee any
broadcast. In this case we simply remove dummy_flush_tlb_a15_erratum()
in context.c (but I guess for cc: stable we can use an 'if (erratum...)').

-- 
Catalin


From will.deacon at arm.com  Tue Jul 23 07:09:16 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:09:16 +0100
Subject: [PATCH v3 04/12] ARM: tlb: don't perform inner-shareable invalidation
 for local BP ops
In-Reply-To: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
References: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374577764-32480-5-git-send-email-will.deacon@arm.com>

Now that the ASID allocator doesn't require inner-shareable maintenance,
we can convert the local_bp_flush_all function to perform only
non-shareable flushing, in a similar manner to the TLB invalidation
routines.

Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/tlbflush.h | 22 ++++++++++++++++++++--
 arch/arm/kernel/smp_tlb.c       |  2 +-
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index f096add..0fc1272 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -531,17 +531,35 @@ static inline void __flush_tlb_kernel_page(unsigned long kaddr)
  * Branch predictor maintenance is paired with full TLB invalidation, so
  * there is no need for any barriers here.
  */
+static inline void __local_flush_bp_all(void)
+{
+	const int zero = 0;
+	const unsigned int __tlb_flag = __cpu_tlb_flags;
+
+	if (tlb_flag(TLB_V6_BP))
+		asm("mcr p15, 0, %0, c7, c5, 6" : : "r" (zero));
+}
+
 static inline void local_flush_bp_all(void)
 {
 	const int zero = 0;
 	const unsigned int __tlb_flag = __cpu_tlb_flags;
 
+	__local_flush_bp_all();
 	if (tlb_flag(TLB_V7_UIS_BP))
-		asm("mcr p15, 0, %0, c7, c1, 6" : : "r" (zero));
-	else if (tlb_flag(TLB_V6_BP))
 		asm("mcr p15, 0, %0, c7, c5, 6" : : "r" (zero));
 }
 
+static inline void __flush_bp_all(void)
+{
+	const int zero = 0;
+	const unsigned int __tlb_flag = __cpu_tlb_flags;
+
+	__local_flush_bp_all();
+	if (tlb_flag(TLB_V7_UIS_BP))
+		asm("mcr p15, 0, %0, c7, c1, 6" : : "r" (zero));
+}
+
 #ifdef CONFIG_ARM_ERRATA_798181
 static inline void dummy_flush_tlb_a15_erratum(void)
 {
diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
index 1c94776..f4bb369 100644
--- a/arch/arm/kernel/smp_tlb.c
+++ b/arch/arm/kernel/smp_tlb.c
@@ -190,5 +190,5 @@ void flush_bp_all(void)
 	if (tlb_ops_need_broadcast())
 		on_each_cpu(ipi_flush_bp_all, NULL, 1);
 	else
-		local_flush_bp_all();
+		__flush_bp_all();
 }
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:09:22 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:09:22 +0100
Subject: [PATCH v3 10/12] ARM: mcpm: use -st dsb option prior to sev
 instructions
In-Reply-To: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
References: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374577764-32480-11-git-send-email-will.deacon@arm.com>

In a similar manner to our spinlock implementation, mcpm uses sev to
wake up cores waiting on a lock when the lock is unlocked. In order to
ensure that the final write unlocking the lock is visible, a dsb
instruction is executed immediately prior to the sev.

This patch changes these dsbs to use the -st option, since we only
require that the store unlocking the lock is made visible.

Acked-by: Nicolas Pitre <nico at linaro.org>
Reviewed-by: Dave Martin <dave.martin at arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/common/mcpm_head.S | 2 +-
 arch/arm/common/vlock.S     | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/common/mcpm_head.S b/arch/arm/common/mcpm_head.S
index 80f033614..39c96df 100644
--- a/arch/arm/common/mcpm_head.S
+++ b/arch/arm/common/mcpm_head.S
@@ -151,7 +151,7 @@ mcpm_setup_leave:
 
 	mov	r0, #INBOUND_NOT_COMING_UP
 	strb	r0, [r8, #MCPM_SYNC_CLUSTER_INBOUND]
-	dsb
+	dsb	st
 	sev
 
 	mov	r0, r11
diff --git a/arch/arm/common/vlock.S b/arch/arm/common/vlock.S
index ff19858..8b7df28 100644
--- a/arch/arm/common/vlock.S
+++ b/arch/arm/common/vlock.S
@@ -42,7 +42,7 @@
 	dmb
 	mov	\rscratch, #0
 	strb	\rscratch, [\rbase, \rcpu]
-	dsb
+	dsb	st
 	sev
 .endm
 
@@ -102,7 +102,7 @@ ENTRY(vlock_unlock)
 	dmb
 	mov	r1, #VLOCK_OWNER_NONE
 	strb	r1, [r0, #VLOCK_OWNER_OFFSET]
-	dsb
+	dsb	st
 	sev
 	bx	lr
 ENDPROC(vlock_unlock)
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:09:13 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:09:13 +0100
Subject: [PATCH v3 01/12] ARM: mm: remove redundant dsb() prior to range TLB
 invalidation
In-Reply-To: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
References: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374577764-32480-2-git-send-email-will.deacon@arm.com>

The kernel TLB range invalidation functions already contain dsb
instructions before and after the maintenance, so there is no need to
introduce additional barriers.

Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/mm/dma-mapping.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 7f9b179..0c17f69 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -455,7 +455,6 @@ static void __dma_remap(struct page *page, size_t size, pgprot_t prot)
 	unsigned end = start + size;
 
 	apply_to_page_range(&init_mm, start, size, __dma_update_pte, &prot);
-	dsb();
 	flush_tlb_kernel_range(start, end);
 }
 
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:09:20 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:09:20 +0100
Subject: [PATCH v3 08/12] ARM: spinlock: use inner-shareable dsb variant prior
 to sev instruction
In-Reply-To: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
References: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374577764-32480-9-git-send-email-will.deacon@arm.com>

When unlocking a spinlock, we use the sev instruction to signal other
CPUs waiting on the lock. Since sev is not a memory access instruction,
we require a dsb in order to ensure that the sev is not issued ahead
of the store placing the lock in an unlocked state.

However, as sev is only concerned with other processors in a
multiprocessor system, we can restrict the scope of the preceding dsb
to the inner-shareable domain. Furthermore, we can restrict the scope to
consider only stores, since there are no independent loads on the unlock
path.

A side-effect of this change is that a spin_unlock operation no longer
forces completion of pending TLB invalidation, something which we rely
on when unlocking runqueues to ensure that CPU migration during TLB
maintenance routines doesn't cause us to continue before the operation
has completed.

This patch adds the -ishst suffix to the ARMv7 definition of dsb_sev()
and adds an inner-shareable dsb to the context-switch path when running
a preemptible, SMP, v7 kernel.

Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/spinlock.h  |  2 +-
 arch/arm/include/asm/switch_to.h | 10 ++++++++++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index f8b8965..2c1e748 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -46,7 +46,7 @@ static inline void dsb_sev(void)
 {
 #if __LINUX_ARM_ARCH__ >= 7
 	__asm__ __volatile__ (
-		"dsb\n"
+		"dsb ishst\n"
 		SEV
 	);
 #else
diff --git a/arch/arm/include/asm/switch_to.h b/arch/arm/include/asm/switch_to.h
index fa09e6b..c99e259 100644
--- a/arch/arm/include/asm/switch_to.h
+++ b/arch/arm/include/asm/switch_to.h
@@ -4,6 +4,16 @@
 #include <linux/thread_info.h>
 
 /*
+ * For v7 SMP cores running a preemptible kernel we may be pre-empted
+ * during a TLB maintenance operation, so execute an inner-shareable dsb
+ * to ensure that the maintenance completes in case we migrate to another
+ * CPU.
+ */
+#if defined(CONFIG_PREEMPT) && defined(CONFIG_SMP) && defined(CONFIG_CPU_V7)
+#define finish_arch_switch(prev)	dsb(ish)
+#endif
+
+/*
  * switch_to(prev, next) should switch from task `prev' to `next'
  * `prev' will never be the same as `next'.  schedule() itself
  * contains the memory barrier to tell GCC not to cache `current'.
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:09:12 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:09:12 +0100
Subject: [PATCH v3 00/12] Make use of v7 barriers variants in Linux
Message-ID: <1374577764-32480-1-git-send-email-will.deacon@arm.com>

Hi all,

This is the third version of the patches I previously posted here:

v1: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173952.html
v2: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/178583.html

The only change since v2 is that the series is now based on 3.11-rc2.
I plan to send a pull request to Russell targetting 3.12 pending no
further feedback.

Cheers,

Will


Will Deacon (12):
  ARM: mm: remove redundant dsb() prior to range TLB invalidation
  ARM: tlb: don't perform inner-shareable invalidation for local TLB ops
  ARM: tlb: don't bother with barriers for branch predictor maintenance
  ARM: tlb: don't perform inner-shareable invalidation for local BP ops
  ARM: barrier: allow options to be passed to memory barrier
    instructions
  ARM: tlb: reduce scope of barrier domains for TLB invalidation
  ARM: mm: use inner-shareable barriers for TLB and user cache
    operations
  ARM: spinlock: use inner-shareable dsb variant prior to sev
    instruction
  ARM: kvm: use inner-shareable barriers after TLB flushing
  ARM: mcpm: use -st dsb option prior to sev instructions
  ARM: l2x0: use -st dsb option for ordering writel_relaxed with unlock
  ARM: cacheflush: use -ishst dsb variant for ensuring flush completion

 arch/arm/common/mcpm_head.S       |   2 +-
 arch/arm/common/vlock.S           |   4 +-
 arch/arm/include/asm/assembler.h  |   4 +-
 arch/arm/include/asm/barrier.h    |  32 +++----
 arch/arm/include/asm/cacheflush.h |   2 +-
 arch/arm/include/asm/spinlock.h   |   2 +-
 arch/arm/include/asm/switch_to.h  |  10 +++
 arch/arm/include/asm/tlbflush.h   | 181 +++++++++++++++++++++++++++++++-------
 arch/arm/kernel/smp_tlb.c         |  10 +--
 arch/arm/kvm/init.S               |   2 +-
 arch/arm/kvm/interrupts.S         |   4 +-
 arch/arm/mm/cache-l2x0.c          |   2 +-
 arch/arm/mm/cache-v7.S            |   4 +-
 arch/arm/mm/context.c             |   6 +-
 arch/arm/mm/dma-mapping.c         |   1 -
 arch/arm/mm/proc-v7.S             |   2 +-
 arch/arm/mm/tlb-v7.S              |   8 +-
 17 files changed, 199 insertions(+), 77 deletions(-)

-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:09:17 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:09:17 +0100
Subject: [PATCH v3 05/12] ARM: barrier: allow options to be passed to memory
 barrier instructions
In-Reply-To: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
References: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374577764-32480-6-git-send-email-will.deacon@arm.com>

On ARMv7, the memory barrier instructions take an optional `option'
field which can be used to constrain the effects of a memory barrier
based on shareability and access type.

This patch allows the caller to pass these options if required, and
updates the smp_*() barriers to request inner-shareable barriers,
affecting only stores for the _wmb variant. wmb() is also changed to
use the -st version of dsb.

Reported-by: Albin Tonnerre <albin.tonnerre at arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/assembler.h |  4 ++--
 arch/arm/include/asm/barrier.h   | 32 ++++++++++++++++----------------
 2 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index a5fef71..fcc1b5b 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -220,9 +220,9 @@
 #ifdef CONFIG_SMP
 #if __LINUX_ARM_ARCH__ >= 7
 	.ifeqs "\mode","arm"
-	ALT_SMP(dmb)
+	ALT_SMP(dmb	ish)
 	.else
-	ALT_SMP(W(dmb))
+	ALT_SMP(W(dmb)	ish)
 	.endif
 #elif __LINUX_ARM_ARCH__ == 6
 	ALT_SMP(mcr	p15, 0, r0, c7, c10, 5)	@ dmb
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 8dcd9c7..60f15e2 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -14,27 +14,27 @@
 #endif
 
 #if __LINUX_ARM_ARCH__ >= 7
-#define isb() __asm__ __volatile__ ("isb" : : : "memory")
-#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
-#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
+#define isb(option) __asm__ __volatile__ ("isb " #option : : : "memory")
+#define dsb(option) __asm__ __volatile__ ("dsb " #option : : : "memory")
+#define dmb(option) __asm__ __volatile__ ("dmb " #option : : : "memory")
 #elif defined(CONFIG_CPU_XSC3) || __LINUX_ARM_ARCH__ == 6
-#define isb() __asm__ __volatile__ ("mcr p15, 0, %0, c7, c5, 4" \
+#define isb(x) __asm__ __volatile__ ("mcr p15, 0, %0, c7, c5, 4" \
 				    : : "r" (0) : "memory")
-#define dsb() __asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 4" \
+#define dsb(x) __asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 4" \
 				    : : "r" (0) : "memory")
-#define dmb() __asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 5" \
+#define dmb(x) __asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 5" \
 				    : : "r" (0) : "memory")
 #elif defined(CONFIG_CPU_FA526)
-#define isb() __asm__ __volatile__ ("mcr p15, 0, %0, c7, c5, 4" \
+#define isb(x) __asm__ __volatile__ ("mcr p15, 0, %0, c7, c5, 4" \
 				    : : "r" (0) : "memory")
-#define dsb() __asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 4" \
+#define dsb(x) __asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 4" \
 				    : : "r" (0) : "memory")
-#define dmb() __asm__ __volatile__ ("" : : : "memory")
+#define dmb(x) __asm__ __volatile__ ("" : : : "memory")
 #else
-#define isb() __asm__ __volatile__ ("" : : : "memory")
-#define dsb() __asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 4" \
+#define isb(x) __asm__ __volatile__ ("" : : : "memory")
+#define dsb(x) __asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 4" \
 				    : : "r" (0) : "memory")
-#define dmb() __asm__ __volatile__ ("" : : : "memory")
+#define dmb(x) __asm__ __volatile__ ("" : : : "memory")
 #endif
 
 #ifdef CONFIG_ARCH_HAS_BARRIERS
@@ -42,7 +42,7 @@
 #elif defined(CONFIG_ARM_DMA_MEM_BUFFERABLE) || defined(CONFIG_SMP)
 #define mb()		do { dsb(); outer_sync(); } while (0)
 #define rmb()		dsb()
-#define wmb()		mb()
+#define wmb()		do { dsb(st); outer_sync(); } while (0)
 #else
 #define mb()		barrier()
 #define rmb()		barrier()
@@ -54,9 +54,9 @@
 #define smp_rmb()	barrier()
 #define smp_wmb()	barrier()
 #else
-#define smp_mb()	dmb()
-#define smp_rmb()	dmb()
-#define smp_wmb()	dmb()
+#define smp_mb()	dmb(ish)
+#define smp_rmb()	smp_mb()
+#define smp_wmb()	dmb(ishst)
 #endif
 
 #define read_barrier_depends()		do { } while(0)
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:09:23 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:09:23 +0100
Subject: [PATCH v3 11/12] ARM: l2x0: use -st dsb option for ordering
 writel_relaxed with unlock
In-Reply-To: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
References: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374577764-32480-12-git-send-email-will.deacon@arm.com>

writel_relaxed and spin_unlock are both store operations, so we only
need to enforce store ordering in the dsb.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/mm/cache-l2x0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index d70e0ab..0c3fc27 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -290,7 +290,7 @@ static void l2x0_disable(void)
 	raw_spin_lock_irqsave(&l2x0_lock, flags);
 	__l2x0_flush_all();
 	writel_relaxed(0, l2x0_base + L2X0_CTRL);
-	dsb();
+	dsb(st);
 	raw_spin_unlock_irqrestore(&l2x0_lock, flags);
 }
 
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:09:24 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:09:24 +0100
Subject: [PATCH v3 12/12] ARM: cacheflush: use -ishst dsb variant for ensuring
 flush completion
In-Reply-To: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
References: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374577764-32480-13-git-send-email-will.deacon@arm.com>

flush_cache_vmap contains a dsb to ensure that any cacheflushing
operations to flush out newly written ptes have completed.

This patch adds the -ishst option to the dsb, since that is all that is
required for completing cacheflushing in the inner-shareable domain.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/cacheflush.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
index 17d0ae8..04d7326 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -352,7 +352,7 @@ static inline void flush_cache_vmap(unsigned long start, unsigned long end)
 		 * set_pte_at() called from vmap_pte_range() does not
 		 * have a DSB after cleaning the cache line.
 		 */
-		dsb();
+		dsb(ishst);
 }
 
 static inline void flush_cache_vunmap(unsigned long start, unsigned long end)
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:09:14 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:09:14 +0100
Subject: [PATCH v3 02/12] ARM: tlb: don't perform inner-shareable invalidation
 for local TLB ops
In-Reply-To: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
References: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374577764-32480-3-git-send-email-will.deacon@arm.com>

Inner-shareable TLB invalidation is typically more expensive than local
(non-shareable) invalidation, so performing the broadcasting for
local_flush_tlb_* operations is a waste of cycles and needlessly
clobbers entries in the TLBs of other CPUs.

This patch introduces __flush_tlb_* versions for many of the TLB
invalidation functions, which only respect inner-shareable variants of
the invalidation instructions when presented with the TLB_V7_UIS_FULL
flag. The local version is also inlined to prevent SMP_ON_UP kernels
from missing flushes, where the __flush variant would be called with
the UP flags.

This gains us around 0.5% in hackbench scores for a dual-core A15, but I
would expect this to improve as more cores (and clusters) are added to
the equation.

Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
Reported-by: Albin Tonnerre <Albin.Tonnerre at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/tlbflush.h | 138 ++++++++++++++++++++++++++++++++++------
 arch/arm/kernel/smp_tlb.c       |   8 +--
 arch/arm/mm/context.c           |   6 +-
 3 files changed, 123 insertions(+), 29 deletions(-)

diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index fdbb9e3..0f029a6 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -319,6 +319,16 @@ extern struct cpu_tlb_fns cpu_tlb;
 #define tlb_op(f, regs, arg)	__tlb_op(f, "p15, 0, %0, " regs, arg)
 #define tlb_l2_op(f, regs, arg)	__tlb_op(f, "p15, 1, %0, " regs, arg)
 
+static inline void __local_flush_tlb_all(void)
+{
+	const int zero = 0;
+	const unsigned int __tlb_flag = __cpu_tlb_flags;
+
+	tlb_op(TLB_V4_U_FULL | TLB_V6_U_FULL, "c8, c7, 0", zero);
+	tlb_op(TLB_V4_D_FULL | TLB_V6_D_FULL, "c8, c6, 0", zero);
+	tlb_op(TLB_V4_I_FULL | TLB_V6_I_FULL, "c8, c5, 0", zero);
+}
+
 static inline void local_flush_tlb_all(void)
 {
 	const int zero = 0;
@@ -327,10 +337,8 @@ static inline void local_flush_tlb_all(void)
 	if (tlb_flag(TLB_WB))
 		dsb();
 
-	tlb_op(TLB_V4_U_FULL | TLB_V6_U_FULL, "c8, c7, 0", zero);
-	tlb_op(TLB_V4_D_FULL | TLB_V6_D_FULL, "c8, c6, 0", zero);
-	tlb_op(TLB_V4_I_FULL | TLB_V6_I_FULL, "c8, c5, 0", zero);
-	tlb_op(TLB_V7_UIS_FULL, "c8, c3, 0", zero);
+	__local_flush_tlb_all();
+	tlb_op(TLB_V7_UIS_FULL, "c8, c7, 0", zero);
 
 	if (tlb_flag(TLB_BARRIER)) {
 		dsb();
@@ -338,31 +346,69 @@ static inline void local_flush_tlb_all(void)
 	}
 }
 
-static inline void local_flush_tlb_mm(struct mm_struct *mm)
+static inline void __flush_tlb_all(void)
 {
 	const int zero = 0;
-	const int asid = ASID(mm);
 	const unsigned int __tlb_flag = __cpu_tlb_flags;
 
 	if (tlb_flag(TLB_WB))
 		dsb();
 
+	__local_flush_tlb_all();
+	tlb_op(TLB_V7_UIS_FULL, "c8, c3, 0", zero);
+
+	if (tlb_flag(TLB_BARRIER)) {
+		dsb();
+		isb();
+	}
+}
+
+static inline void __local_flush_tlb_mm(struct mm_struct *mm)
+{
+	const int zero = 0;
+	const int asid = ASID(mm);
+	const unsigned int __tlb_flag = __cpu_tlb_flags;
+
 	if (possible_tlb_flags & (TLB_V4_U_FULL|TLB_V4_D_FULL|TLB_V4_I_FULL)) {
-		if (cpumask_test_cpu(get_cpu(), mm_cpumask(mm))) {
+		if (cpumask_test_cpu(smp_processor_id(), mm_cpumask(mm))) {
 			tlb_op(TLB_V4_U_FULL, "c8, c7, 0", zero);
 			tlb_op(TLB_V4_D_FULL, "c8, c6, 0", zero);
 			tlb_op(TLB_V4_I_FULL, "c8, c5, 0", zero);
 		}
-		put_cpu();
 	}
 
 	tlb_op(TLB_V6_U_ASID, "c8, c7, 2", asid);
 	tlb_op(TLB_V6_D_ASID, "c8, c6, 2", asid);
 	tlb_op(TLB_V6_I_ASID, "c8, c5, 2", asid);
+}
+
+static inline void local_flush_tlb_mm(struct mm_struct *mm)
+{
+	const int asid = ASID(mm);
+	const unsigned int __tlb_flag = __cpu_tlb_flags;
+
+	if (tlb_flag(TLB_WB))
+		dsb();
+
+	__local_flush_tlb_mm(mm);
+	tlb_op(TLB_V7_UIS_ASID, "c8, c7, 2", asid);
+
+	if (tlb_flag(TLB_BARRIER))
+		dsb();
+}
+
+static inline void __flush_tlb_mm(struct mm_struct *mm)
+{
+	const unsigned int __tlb_flag = __cpu_tlb_flags;
+
+	if (tlb_flag(TLB_WB))
+		dsb();
+
+	__local_flush_tlb_mm(mm);
 #ifdef CONFIG_ARM_ERRATA_720789
-	tlb_op(TLB_V7_UIS_ASID, "c8, c3, 0", zero);
+	tlb_op(TLB_V7_UIS_ASID, "c8, c3, 0", 0);
 #else
-	tlb_op(TLB_V7_UIS_ASID, "c8, c3, 2", asid);
+	tlb_op(TLB_V7_UIS_ASID, "c8, c3, 2", ASID(mm));
 #endif
 
 	if (tlb_flag(TLB_BARRIER))
@@ -370,16 +416,13 @@ static inline void local_flush_tlb_mm(struct mm_struct *mm)
 }
 
 static inline void
-local_flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
+__local_flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
 {
 	const int zero = 0;
 	const unsigned int __tlb_flag = __cpu_tlb_flags;
 
 	uaddr = (uaddr & PAGE_MASK) | ASID(vma->vm_mm);
 
-	if (tlb_flag(TLB_WB))
-		dsb();
-
 	if (possible_tlb_flags & (TLB_V4_U_PAGE|TLB_V4_D_PAGE|TLB_V4_I_PAGE|TLB_V4_I_FULL) &&
 	    cpumask_test_cpu(smp_processor_id(), mm_cpumask(vma->vm_mm))) {
 		tlb_op(TLB_V4_U_PAGE, "c8, c7, 1", uaddr);
@@ -392,6 +435,36 @@ local_flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
 	tlb_op(TLB_V6_U_PAGE, "c8, c7, 1", uaddr);
 	tlb_op(TLB_V6_D_PAGE, "c8, c6, 1", uaddr);
 	tlb_op(TLB_V6_I_PAGE, "c8, c5, 1", uaddr);
+}
+
+static inline void
+local_flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
+{
+	const unsigned int __tlb_flag = __cpu_tlb_flags;
+
+	uaddr = (uaddr & PAGE_MASK) | ASID(vma->vm_mm);
+
+	if (tlb_flag(TLB_WB))
+		dsb();
+
+	__local_flush_tlb_page(vma, uaddr);
+	tlb_op(TLB_V7_UIS_PAGE, "c8, c7, 1", uaddr);
+
+	if (tlb_flag(TLB_BARRIER))
+		dsb();
+}
+
+static inline void
+__flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
+{
+	const unsigned int __tlb_flag = __cpu_tlb_flags;
+
+	uaddr = (uaddr & PAGE_MASK) | ASID(vma->vm_mm);
+
+	if (tlb_flag(TLB_WB))
+		dsb();
+
+	__local_flush_tlb_page(vma, uaddr);
 #ifdef CONFIG_ARM_ERRATA_720789
 	tlb_op(TLB_V7_UIS_PAGE, "c8, c3, 3", uaddr & PAGE_MASK);
 #else
@@ -402,16 +475,11 @@ local_flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
 		dsb();
 }
 
-static inline void local_flush_tlb_kernel_page(unsigned long kaddr)
+static inline void __local_flush_tlb_kernel_page(unsigned long kaddr)
 {
 	const int zero = 0;
 	const unsigned int __tlb_flag = __cpu_tlb_flags;
 
-	kaddr &= PAGE_MASK;
-
-	if (tlb_flag(TLB_WB))
-		dsb();
-
 	tlb_op(TLB_V4_U_PAGE, "c8, c7, 1", kaddr);
 	tlb_op(TLB_V4_D_PAGE, "c8, c6, 1", kaddr);
 	tlb_op(TLB_V4_I_PAGE, "c8, c5, 1", kaddr);
@@ -421,6 +489,36 @@ static inline void local_flush_tlb_kernel_page(unsigned long kaddr)
 	tlb_op(TLB_V6_U_PAGE, "c8, c7, 1", kaddr);
 	tlb_op(TLB_V6_D_PAGE, "c8, c6, 1", kaddr);
 	tlb_op(TLB_V6_I_PAGE, "c8, c5, 1", kaddr);
+}
+
+static inline void local_flush_tlb_kernel_page(unsigned long kaddr)
+{
+	const unsigned int __tlb_flag = __cpu_tlb_flags;
+
+	kaddr &= PAGE_MASK;
+
+	if (tlb_flag(TLB_WB))
+		dsb();
+
+	__local_flush_tlb_kernel_page(kaddr);
+	tlb_op(TLB_V7_UIS_PAGE, "c8, c7, 1", kaddr);
+
+	if (tlb_flag(TLB_BARRIER)) {
+		dsb();
+		isb();
+	}
+}
+
+static inline void __flush_tlb_kernel_page(unsigned long kaddr)
+{
+	const unsigned int __tlb_flag = __cpu_tlb_flags;
+
+	kaddr &= PAGE_MASK;
+
+	if (tlb_flag(TLB_WB))
+		dsb();
+
+	__local_flush_tlb_kernel_page(kaddr);
 	tlb_op(TLB_V7_UIS_PAGE, "c8, c3, 1", kaddr);
 
 	if (tlb_flag(TLB_BARRIER)) {
diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
index a98b62d..1c94776 100644
--- a/arch/arm/kernel/smp_tlb.c
+++ b/arch/arm/kernel/smp_tlb.c
@@ -121,7 +121,7 @@ void flush_tlb_all(void)
 	if (tlb_ops_need_broadcast())
 		on_each_cpu(ipi_flush_tlb_all, NULL, 1);
 	else
-		local_flush_tlb_all();
+		__flush_tlb_all();
 	broadcast_tlb_a15_erratum();
 }
 
@@ -130,7 +130,7 @@ void flush_tlb_mm(struct mm_struct *mm)
 	if (tlb_ops_need_broadcast())
 		on_each_cpu_mask(mm_cpumask(mm), ipi_flush_tlb_mm, mm, 1);
 	else
-		local_flush_tlb_mm(mm);
+		__flush_tlb_mm(mm);
 	broadcast_tlb_mm_a15_erratum(mm);
 }
 
@@ -143,7 +143,7 @@ void flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
 		on_each_cpu_mask(mm_cpumask(vma->vm_mm), ipi_flush_tlb_page,
 					&ta, 1);
 	} else
-		local_flush_tlb_page(vma, uaddr);
+		__flush_tlb_page(vma, uaddr);
 	broadcast_tlb_mm_a15_erratum(vma->vm_mm);
 }
 
@@ -154,7 +154,7 @@ void flush_tlb_kernel_page(unsigned long kaddr)
 		ta.ta_start = kaddr;
 		on_each_cpu(ipi_flush_tlb_kernel_page, &ta, 1);
 	} else
-		local_flush_tlb_kernel_page(kaddr);
+		__flush_tlb_kernel_page(kaddr);
 	broadcast_tlb_a15_erratum();
 }
 
diff --git a/arch/arm/mm/context.c b/arch/arm/mm/context.c
index b55b101..84e6f77 100644
--- a/arch/arm/mm/context.c
+++ b/arch/arm/mm/context.c
@@ -162,10 +162,7 @@ static void flush_context(unsigned int cpu)
 	}
 
 	/* Queue a TLB invalidate and flush the I-cache if necessary. */
-	if (!tlb_ops_need_broadcast())
-		cpumask_set_cpu(cpu, &tlb_flush_pending);
-	else
-		cpumask_setall(&tlb_flush_pending);
+	cpumask_setall(&tlb_flush_pending);
 
 	if (icache_is_vivt_asid_tagged())
 		__flush_icache_all();
@@ -245,7 +242,6 @@ void check_and_switch_context(struct mm_struct *mm, struct task_struct *tsk)
 	if (cpumask_test_and_clear_cpu(cpu, &tlb_flush_pending)) {
 		local_flush_bp_all();
 		local_flush_tlb_all();
-		dummy_flush_tlb_a15_erratum();
 	}
 
 	atomic64_set(&per_cpu(active_asids, cpu), asid);
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:09:21 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:09:21 +0100
Subject: [PATCH v3 09/12] ARM: kvm: use inner-shareable barriers after TLB
 flushing
In-Reply-To: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
References: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374577764-32480-10-git-send-email-will.deacon@arm.com>

When flushing the TLB at PL2 in response to remapping at stage-2 or VMID
rollover, we have a dsb instruction to ensure completion of the command
before continuing.

Since we only care about other processors for TLB invalidation, use the
inner-shareable variant of the dsb instruction instead.

Acked-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/kvm/init.S       | 2 +-
 arch/arm/kvm/interrupts.S | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
index f048338..1b9844d 100644
--- a/arch/arm/kvm/init.S
+++ b/arch/arm/kvm/init.S
@@ -142,7 +142,7 @@ target:	@ We're now in the trampoline code, switch page tables
 
 	@ Invalidate the old TLBs
 	mcr	p15, 4, r0, c8, c7, 0	@ TLBIALLH
-	dsb
+	dsb	ish
 
 	eret
 
diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index 16cd4ba..f85052f 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -55,7 +55,7 @@ ENTRY(__kvm_tlb_flush_vmid_ipa)
 	mcrr	p15, 6, r2, r3, c2	@ Write VTTBR
 	isb
 	mcr     p15, 0, r0, c8, c3, 0	@ TLBIALLIS (rt ignored)
-	dsb
+	dsb	ish
 	isb
 	mov	r2, #0
 	mov	r3, #0
@@ -79,7 +79,7 @@ ENTRY(__kvm_flush_vm_context)
 	mcr     p15, 4, r0, c8, c3, 4
 	/* Invalidate instruction caches Inner Shareable (ICIALLUIS) */
 	mcr     p15, 0, r0, c7, c1, 0
-	dsb
+	dsb	ish
 	isb				@ Not necessary if followed by eret
 
 	bx	lr
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:09:15 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:09:15 +0100
Subject: [PATCH v3 03/12] ARM: tlb: don't bother with barriers for branch
 predictor maintenance
In-Reply-To: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
References: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374577764-32480-4-git-send-email-will.deacon@arm.com>

Branch predictor maintenance is only required when we are either
changing the kernel's view of memory (switching tables completely) or
dealing with ASID rollover.

Both of these use-cases require subsequent TLB invalidation, which has
the relevant barrier instructions to ensure completion and visibility
of the maintenance, so this patch removes the instruction barrier from
[local_]flush_bp_all.

Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/tlbflush.h | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index 0f029a6..f096add 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -527,6 +527,10 @@ static inline void __flush_tlb_kernel_page(unsigned long kaddr)
 	}
 }
 
+/*
+ * Branch predictor maintenance is paired with full TLB invalidation, so
+ * there is no need for any barriers here.
+ */
 static inline void local_flush_bp_all(void)
 {
 	const int zero = 0;
@@ -536,9 +540,6 @@ static inline void local_flush_bp_all(void)
 		asm("mcr p15, 0, %0, c7, c1, 6" : : "r" (zero));
 	else if (tlb_flag(TLB_V6_BP))
 		asm("mcr p15, 0, %0, c7, c5, 6" : : "r" (zero));
-
-	if (tlb_flag(TLB_BARRIER))
-		isb();
 }
 
 #ifdef CONFIG_ARM_ERRATA_798181
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:09:19 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:09:19 +0100
Subject: [PATCH v3 07/12] ARM: mm: use inner-shareable barriers for TLB and
 user cache operations
In-Reply-To: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
References: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374577764-32480-8-git-send-email-will.deacon@arm.com>

System-wide barriers aren't required for situations where we only need
to make visibility and ordering guarantees in the inner-shareable domain
(i.e. we are not dealing with devices or potentially incoherent CPUs).

This patch changes the v7 TLB operations, coherent_user_range and
dcache_clean_area functions to user inner-shareable barriers. For cache
maintenance, only the store access type is required to ensure completion.

Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/mm/cache-v7.S | 4 ++--
 arch/arm/mm/proc-v7.S  | 2 +-
 arch/arm/mm/tlb-v7.S   | 8 ++++----
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index 515b000..b5c467a 100644
--- a/arch/arm/mm/cache-v7.S
+++ b/arch/arm/mm/cache-v7.S
@@ -282,7 +282,7 @@ ENTRY(v7_coherent_user_range)
 	add	r12, r12, r2
 	cmp	r12, r1
 	blo	1b
-	dsb
+	dsb	ishst
 	icache_line_size r2, r3
 	sub	r3, r2, #1
 	bic	r12, r0, r3
@@ -294,7 +294,7 @@ ENTRY(v7_coherent_user_range)
 	mov	r0, #0
 	ALT_SMP(mcr	p15, 0, r0, c7, c1, 6)	@ invalidate BTB Inner Shareable
 	ALT_UP(mcr	p15, 0, r0, c7, c5, 6)	@ invalidate BTB
-	dsb
+	dsb	ishst
 	isb
 	mov	pc, lr
 
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 5c6d5a3..6147e04 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -82,7 +82,7 @@ ENTRY(cpu_v7_dcache_clean_area)
 	add	r0, r0, r2
 	subs	r1, r1, r2
 	bhi	1b
-	dsb
+	dsb	ishst
 	mov	pc, lr
 ENDPROC(cpu_v7_dcache_clean_area)
 
diff --git a/arch/arm/mm/tlb-v7.S b/arch/arm/mm/tlb-v7.S
index ea94765..3553087 100644
--- a/arch/arm/mm/tlb-v7.S
+++ b/arch/arm/mm/tlb-v7.S
@@ -35,7 +35,7 @@
 ENTRY(v7wbi_flush_user_tlb_range)
 	vma_vm_mm r3, r2			@ get vma->vm_mm
 	mmid	r3, r3				@ get vm_mm->context.id
-	dsb
+	dsb	ish
 	mov	r0, r0, lsr #PAGE_SHIFT		@ align address
 	mov	r1, r1, lsr #PAGE_SHIFT
 	asid	r3, r3				@ mask ASID
@@ -56,7 +56,7 @@ ENTRY(v7wbi_flush_user_tlb_range)
 	add	r0, r0, #PAGE_SZ
 	cmp	r0, r1
 	blo	1b
-	dsb
+	dsb	ish
 	mov	pc, lr
 ENDPROC(v7wbi_flush_user_tlb_range)
 
@@ -69,7 +69,7 @@ ENDPROC(v7wbi_flush_user_tlb_range)
  *	- end   - end address (exclusive, may not be aligned)
  */
 ENTRY(v7wbi_flush_kern_tlb_range)
-	dsb
+	dsb	ish
 	mov	r0, r0, lsr #PAGE_SHIFT		@ align address
 	mov	r1, r1, lsr #PAGE_SHIFT
 	mov	r0, r0, lsl #PAGE_SHIFT
@@ -84,7 +84,7 @@ ENTRY(v7wbi_flush_kern_tlb_range)
 	add	r0, r0, #PAGE_SZ
 	cmp	r0, r1
 	blo	1b
-	dsb
+	dsb	ish
 	isb
 	mov	pc, lr
 ENDPROC(v7wbi_flush_kern_tlb_range)
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:09:18 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:09:18 +0100
Subject: [PATCH v3 06/12] ARM: tlb: reduce scope of barrier domains for TLB
 invalidation
In-Reply-To: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
References: <1374577764-32480-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374577764-32480-7-git-send-email-will.deacon@arm.com>

Our TLB invalidation routines may require a barrier before the
maintenance (in order to ensure pending page table writes are visible to
the hardware walker) and barriers afterwards (in order to ensure
completion of the maintenance and visibility in the instruction stream).

Whilst this is expensive, the cost can be reduced somewhat by reducing
the scope of the barrier instructions:

  - The barrier before only needs to apply to stores (pte writes)
  - Local ops are required only to affect the non-shareable domain
  - Global ops are required only to affect the inner-shareable domain

This patch makes these changes for the TLB flushing code.

Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/tlbflush.h | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index 0fc1272..9297685 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -335,13 +335,13 @@ static inline void local_flush_tlb_all(void)
 	const unsigned int __tlb_flag = __cpu_tlb_flags;
 
 	if (tlb_flag(TLB_WB))
-		dsb();
+		dsb(nshst);
 
 	__local_flush_tlb_all();
 	tlb_op(TLB_V7_UIS_FULL, "c8, c7, 0", zero);
 
 	if (tlb_flag(TLB_BARRIER)) {
-		dsb();
+		dsb(nsh);
 		isb();
 	}
 }
@@ -352,13 +352,13 @@ static inline void __flush_tlb_all(void)
 	const unsigned int __tlb_flag = __cpu_tlb_flags;
 
 	if (tlb_flag(TLB_WB))
-		dsb();
+		dsb(ishst);
 
 	__local_flush_tlb_all();
 	tlb_op(TLB_V7_UIS_FULL, "c8, c3, 0", zero);
 
 	if (tlb_flag(TLB_BARRIER)) {
-		dsb();
+		dsb(ish);
 		isb();
 	}
 }
@@ -388,13 +388,13 @@ static inline void local_flush_tlb_mm(struct mm_struct *mm)
 	const unsigned int __tlb_flag = __cpu_tlb_flags;
 
 	if (tlb_flag(TLB_WB))
-		dsb();
+		dsb(nshst);
 
 	__local_flush_tlb_mm(mm);
 	tlb_op(TLB_V7_UIS_ASID, "c8, c7, 2", asid);
 
 	if (tlb_flag(TLB_BARRIER))
-		dsb();
+		dsb(nsh);
 }
 
 static inline void __flush_tlb_mm(struct mm_struct *mm)
@@ -402,7 +402,7 @@ static inline void __flush_tlb_mm(struct mm_struct *mm)
 	const unsigned int __tlb_flag = __cpu_tlb_flags;
 
 	if (tlb_flag(TLB_WB))
-		dsb();
+		dsb(ishst);
 
 	__local_flush_tlb_mm(mm);
 #ifdef CONFIG_ARM_ERRATA_720789
@@ -412,7 +412,7 @@ static inline void __flush_tlb_mm(struct mm_struct *mm)
 #endif
 
 	if (tlb_flag(TLB_BARRIER))
-		dsb();
+		dsb(ish);
 }
 
 static inline void
@@ -445,13 +445,13 @@ local_flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
 	uaddr = (uaddr & PAGE_MASK) | ASID(vma->vm_mm);
 
 	if (tlb_flag(TLB_WB))
-		dsb();
+		dsb(nshst);
 
 	__local_flush_tlb_page(vma, uaddr);
 	tlb_op(TLB_V7_UIS_PAGE, "c8, c7, 1", uaddr);
 
 	if (tlb_flag(TLB_BARRIER))
-		dsb();
+		dsb(nsh);
 }
 
 static inline void
@@ -462,7 +462,7 @@ __flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
 	uaddr = (uaddr & PAGE_MASK) | ASID(vma->vm_mm);
 
 	if (tlb_flag(TLB_WB))
-		dsb();
+		dsb(ishst);
 
 	__local_flush_tlb_page(vma, uaddr);
 #ifdef CONFIG_ARM_ERRATA_720789
@@ -472,7 +472,7 @@ __flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
 #endif
 
 	if (tlb_flag(TLB_BARRIER))
-		dsb();
+		dsb(ish);
 }
 
 static inline void __local_flush_tlb_kernel_page(unsigned long kaddr)
@@ -498,13 +498,13 @@ static inline void local_flush_tlb_kernel_page(unsigned long kaddr)
 	kaddr &= PAGE_MASK;
 
 	if (tlb_flag(TLB_WB))
-		dsb();
+		dsb(nshst);
 
 	__local_flush_tlb_kernel_page(kaddr);
 	tlb_op(TLB_V7_UIS_PAGE, "c8, c7, 1", kaddr);
 
 	if (tlb_flag(TLB_BARRIER)) {
-		dsb();
+		dsb(nsh);
 		isb();
 	}
 }
@@ -516,13 +516,13 @@ static inline void __flush_tlb_kernel_page(unsigned long kaddr)
 	kaddr &= PAGE_MASK;
 
 	if (tlb_flag(TLB_WB))
-		dsb();
+		dsb(ishst);
 
 	__local_flush_tlb_kernel_page(kaddr);
 	tlb_op(TLB_V7_UIS_PAGE, "c8, c3, 1", kaddr);
 
 	if (tlb_flag(TLB_BARRIER)) {
-		dsb();
+		dsb(ish);
 		isb();
 	}
 }
@@ -567,7 +567,7 @@ static inline void dummy_flush_tlb_a15_erratum(void)
 	 * Dummy TLBIMVAIS. Using the unmapped address 0 and ASID 0.
 	 */
 	asm("mcr p15, 0, %0, c8, c3, 1" : : "r" (0));
-	dsb();
+	dsb(ish);
 }
 #else
 static inline void dummy_flush_tlb_a15_erratum(void)
@@ -596,7 +596,7 @@ static inline void flush_pmd_entry(void *pmd)
 	tlb_l2_op(TLB_L2CLEAN_FR, "c15, c9, 1  @ L2 flush_pmd", pmd);
 
 	if (tlb_flag(TLB_WB))
-		dsb();
+		dsb(ishst);
 }
 
 static inline void clean_pmd_entry(void *pmd)
-- 
1.8.2.2



From catalin.marinas at arm.com  Tue Jul 23 07:12:47 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Jul 2013 12:12:47 +0100
Subject: [PATCH v2 1/3] drivers: clocksource: configure event stream for
 ARM arch timer
In-Reply-To: <20130723103333.GB30942@mudshark.cambridge.arm.com>
References: <1371575223-21702-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492082-13686-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492082-13686-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <20130723102334.GC3748@MacBook-Pro.local>
 <20130723103333.GB30942@mudshark.cambridge.arm.com>
Message-ID: <20130723111247.GG3748@MacBook-Pro.local>

On Tue, Jul 23, 2013 at 11:33:33AM +0100, Will Deacon wrote:
> On Tue, Jul 23, 2013 at 11:23:34AM +0100, Catalin Marinas wrote:
> > On Mon, Jul 22, 2013 at 12:21:20PM +0100, Sudeep KarkadaNagesha wrote:
> > > From: Will Deacon <will.deacon at arm.com>
> > > 
> > > The ARM architected timer can generate events (used for waking up
> > > CPUs executing the wfe instruction) at a frequency represented as a
> > > power-of-2 divisor of the clock rate.
> > > 
> > > This patch configures the event stream, aiming for a period of 100us
> > > between events. This can be used to implement wfe-based timeouts for
> > > userspace locking implementations.
> > ...
> > > --- a/include/clocksource/arm_arch_timer.h
> > > +++ b/include/clocksource/arm_arch_timer.h
> > > @@ -29,6 +29,8 @@
> > >  #define ARCH_TIMER_PHYS_ACCESS		0
> > >  #define ARCH_TIMER_VIRT_ACCESS		1
> > >  
> > > +#define ARCH_TIMER_EVT_STREAM_FREQ	10000	/* 100us */
> > 
> > BTW, if user-space starts using this, it will become an ABI. Is this the
> > right frequency?
> 
> It doesn't quite become ABI; not all platforms will use the architected
> timers and not all timers can support an arbitrary frequency. The best we
> can do is calculate something as close to the target value as possible.

ABI in the sense that if it is available and advertised by the kernel as
such, people may use it.

> I spoke to both tools developers and some HSA driver guys about the frequency,
> and this is what ended up being suggested.
> 
> > In addition, do we want to expose this via hwcap? Something like
> > HWCAP_EVSTR100US?
> 
> Hmm, maybe, but we don't want people to try and use this for any accurate
> time measurements, so I wouldn't include the period.

Definitely not for accurate time but some user-space may find the delay
too small or too large. I'm fine without specifying the period, maybe
add a comment in the kernel like /* currently 100us */.

-- 
Catalin


From rogerq at ti.com  Tue Jul 23 07:13:54 2013
From: rogerq at ti.com (Roger Quadros)
Date: Tue, 23 Jul 2013 14:13:54 +0300
Subject: [PATCH] ARM: Do not run dummy_flush_tlb_a15_erratum() on
 non-Cortex-A15
In-Reply-To: <CAOMZO5Brgj2CzJXqjUfihi-aNxumvamDUGdvZuU94rHMwutCog@mail.gmail.com>
References: <1374556774-18795-1-git-send-email-festevam@gmail.com>
 <51EE3B46.7020906@ti.com>
 <CAOMZO5Brgj2CzJXqjUfihi-aNxumvamDUGdvZuU94rHMwutCog@mail.gmail.com>
Message-ID: <51EE6572.50909@ti.com>

On 07/23/2013 02:02 PM, Fabio Estevam wrote:
> Hi Roger,
> 
> On Tue, Jul 23, 2013 at 5:13 AM, Roger Quadros <rogerq at ti.com> wrote:
> 
>>> -     if (!erratum_a15_798181())
>>> -             return;
>>> -
>>
>> Removing this if statement will cause "ipi_flush_tlb_a15_erratum" to be called
>> on non A15 platforms. So I would just keep it to be safe.
> 
> I just moved the if statement into the the beginning of
> dummy_flush_tlb_a15_erratum(), so ipi_flush_tlb_a15_erratum will not
> be called on non-A15 systems.

It will be called. Please see the code below after your patch is applied.

 static void broadcast_tlb_a15_erratum(void)
 {
 	dummy_flush_tlb_a15_erratum();
 	smp_call_function(ipi_flush_tlb_a15_erratum, NULL, 1);
 }

cheers,
-roger


From inki.dae at samsung.com  Tue Jul 23 07:21:13 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Tue, 23 Jul 2013 20:21:13 +0900
Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to an
 IOMMU group
In-Reply-To: <CAG8rG2wNG9wVjKxtaDzLRybvh3wPVR08j9G9OPcK=a2Gwbtg-g@mail.gmail.com>
References: <1374573694-30595-1-git-send-email-a.motakis@virtualopensystems.com>
 <00d701ce878f$da099fe0$8e1cdfa0$%dae@samsung.com>
 <CAG8rG2wNG9wVjKxtaDzLRybvh3wPVR08j9G9OPcK=a2Gwbtg-g@mail.gmail.com>
Message-ID: <00e601ce8796$bdca50c0$395ef240$%dae@samsung.com>



> -----Original Message-----
> From: Antonios Motakis [mailto:a.motakis at virtualopensystems.com]
> Sent: Tuesday, July 23, 2013 8:00 PM
> To: Inki Dae
> Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
KyongHo;
> Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> Subject: Re: [PATCH] iommu/exynos: add devices attached to the System MMU
> to an IOMMU group
> 
> On Tue, Jul 23, 2013 at 12:31 PM, Inki Dae <inki.dae at samsung.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-
> soc-
> > > owner at vger.kernel.org] On Behalf Of Antonios Motakis
> > > Sent: Tuesday, July 23, 2013 7:02 PM
> > > To: linux-arm-kernel at lists.infradead.org;
> > iommu at lists.linux-foundation.org;
> > > linux-samsung-soc at vger.kernel.org
> > > Cc: kvmarm at lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo; Joerg
> > > Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> > > Subject: [PATCH] iommu/exynos: add devices attached to the System MMU
> to
> > > an IOMMU group
> > >
> > > IOMMU groups are expected by certain users of the IOMMU API,
> > > e.g. VFIO. Since each device is behind its own System MMU, we
> > > can allocate a new IOMMU group for each device.
> > >
> > > This patch depends on Cho KyongHo's patch series titled "[PATCH v7
> 00/12]
> > > iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> > > applied on a Linux 3.10.1 kernel. It has been tested on the Arndale
> board.
> > >
> > > Signed-off-by: Antonios Motakis <a.motakis at virtualopensystems.com>
> > > ---
> > >  drivers/iommu/exynos-iommu.c | 24 ++++++++++++++++++++++++
> > >  1 file changed, 24 insertions(+)
> > >
> > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-
> iommu.c
> > > index 51d43bb..9f39eaa 100644
> > > --- a/drivers/iommu/exynos-iommu.c
> > > +++ b/drivers/iommu/exynos-iommu.c
> > > @@ -1134,6 +1134,28 @@ static phys_addr_t
> exynos_iommu_iova_to_phys(struct
> > > iommu_domain *domain,
> > >       return phys;
> > >  }
> > >
> > > +static int exynos_iommu_add_device(struct device *dev)
> > > +{
> > > +     struct iommu_group *group;
> > > +     int ret;
> > > +
> > > +     group = iommu_group_alloc();
> >
> > Is that correct? I don't see why you allocate a group object every time
> > add_device callback is called. That doesn't have any meaning we have to
> use
> > iommu group feature. I think the implementation should be one more
> devices
> > per a group. So I guess a given device object should be wrapped by
> higher
> > device object than the given device object. For a good example, you can
> > refer to intel-iommu.c file.
> 
> With an Intel IOMMU it can be the case that 2 devices have to share
> the same IOMMU mappings (i.e. you can't program them separately). With
> the Exynos System MMU, there is always one System MMU per device, so
> there is nothing stopping you from programming any 2 devices' mappings
> differently. So yes, the right thing to do here is to have a one to
> one relationship between devices and IOMMU groups.

In case of Exynos drm driver, a unified iommu mapping table is used for all
devices (fimd, g2d, hdmi, fimc, gsc, rotator) based on drm so they use the
same iommu mapping table even though they have each iommu hardware unit. And
the iommu mapping table is just logical data structure for hardware
translation process by each DMA. Actually, I am considering using iommu
group feature for more generic implementation.

And one question. Why do you allocate a iommu group object if we should have
one to one relationship between devices and iommu groups? In this case, is
there any reason you have to use the iommu group object?

Thanks,
Inki Dae

> 
> (resending because of html mail)
> 
> Cheers,
> Antonios
> 
> >
> >
> > Thanks,
> > Inki Dae
> >
> > > +     if (IS_ERR(group)) {
> > > +             dev_err(dev, "Failed to allocate IOMMU group\n");
> > > +             return PTR_ERR(group);
> > > +     }
> > > +
> > > +     ret = iommu_group_add_device(group, dev);
> > > +     iommu_group_put(group);
> > > +
> > > +     return ret;
> > > +}
> > > +
> > > +static void exynos_iommu_remove_device(struct device *dev)
> > > +{
> > > +     iommu_group_remove_device(dev);
> > > +}
> > > +
> > >  static struct iommu_ops exynos_iommu_ops = {
> > >       .domain_init = &exynos_iommu_domain_init,
> > >       .domain_destroy = &exynos_iommu_domain_destroy,
> > > @@ -1142,6 +1164,8 @@ static struct iommu_ops exynos_iommu_ops = {
> > >       .map = &exynos_iommu_map,
> > >       .unmap = &exynos_iommu_unmap,
> > >       .iova_to_phys = &exynos_iommu_iova_to_phys,
> > > +     .add_device     = exynos_iommu_add_device,
> > > +     .remove_device  = exynos_iommu_remove_device,
> > >       .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
> > >  };
> > >
> > > --
> > > 1.8.1.2
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-
> samsung-
> > > soc" in
> > > the body of a message to majordomo at vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >



From sergei.shtylyov at cogentembedded.com  Tue Jul 23 07:22:44 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 23 Jul 2013 15:22:44 +0400
Subject: [PATCH v2 1/8] clk: mux: Add support for read-only muxes.
In-Reply-To: <1374536965-3545-2-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
 <1374536965-3545-2-git-send-email-tomasz.figa@gmail.com>
Message-ID: <51EE6784.2090808@cogentembedded.com>

Hello.

On 23-07-2013 3:49, Tomasz Figa wrote:

> Some platforms have read-only clock muxes that are preconfigured at
> reset and cannot be changed at runtime. This patch extends mux clock
> driver to allow handling such read-only muxes by adding new
> CLK_MUX_READ_ONLY mux flag.

> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
[...]

> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 1ec14a7..9487b96 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -327,8 +327,10 @@ struct clk_mux {
> #define CLK_MUX_INDEX_ONE		BIT(0)
> #define CLK_MUX_INDEX_BIT		BIT(1)
> #define CLK_MUX_HIWORD_MASK		BIT(2)
> +#define CLK_MUX_READ_ONLY	BIT(3) /* mux setting cannot be changed */

    Please align BIT(3) with the above BIT() invocations.

WBR, Sergei



From mark.rutland at arm.com  Tue Jul 23 07:22:59 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 23 Jul 2013 12:22:59 +0100
Subject: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link'
 property
In-Reply-To: <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130723112259.GE4833@e106331-lin.cambridge.arm.com>

Hi Thomas,

On Mon, Jul 15, 2013 at 04:34:08PM +0100, Thomas Petazzoni wrote:
> Some Ethernet MACs have a "fixed link", and are not connected to a
> normal MDIO-managed PHY device. For those situations, a Device Tree
> binding allows to describe a "fixed link", as a "fixed-link" property
> of the Ethernet device Device Tree node.
> 
> This patch adds:
> 
>  * A documentation for the Device Tree property "fixed-link".
> 
>  * A of_phy_register_fixed_link() OF helper, which provided an OF node
>    that contains a "fixed-link" property, registers the corresponding
>    fixed PHY.
> 
>  * Removes the warning on the of_phy_connect_fixed_link() that says
>    new drivers should not use it, since Grant Likely indicated that
>    this "fixed-link" property is indeed the way to go.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  .../devicetree/bindings/net/fixed-link.txt         | 26 ++++++++++++++++
>  drivers/of/of_mdio.c                               | 36 +++++++++++++++++++---
>  include/linux/of_mdio.h                            | 10 ++++++
>  3 files changed, 68 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/fixed-link.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt
> new file mode 100644
> index 0000000..25a009a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/fixed-link.txt
> @@ -0,0 +1,26 @@
> +Fixed link Device Tree binding
> +------------------------------
> +
> +Some Ethernet MACs have a "fixed link", and are not connected to a
> +normal MDIO-managed PHY device. For those situations, a Device Tree
> +binding allows to describe a "fixed link".

Are partictular MACs fixed link, or can some either be either fixed link
or wired to an MDIO-managed PHY? i.e. can we assume a given MAC is
fixed-link from its compatible string?

> +
> +Such a fixed link situation is described within an Ethernet device
> +Device Tree node using a 'fixed-link' property, composed of 5
> +elements:

I'm not sure grouping these values together is the best way of handling
this. It's rather opaque, and inflexible for future extension.

> +
> + 1. A fake PHY ID, which must be unique accross all fixed-link PHYs in
> +    the system.

Is there any reason this couldn't be allocated dynamically within the
kernel as needed? I don't see why an arbitrary unique value should be a
dt binding requirement; it seems like a leak of Linux implementation
details.

> + 2. The duplex (1 for full-duplex, 0 for half-duplex)

Will this change for a given MAC?

Could we not have a boolean property for each of these, and require one
to be present?

Possibly fixed-link-full-duplex / fix-link-half-duplex?

> + 3. The speed (10, 100, 1000)

fixed-link-speed?

> + 4. The pause setting (1 for enabled, 0 for disabled)
> + 5. The asym pause setting (1 for enabled, 0 for disabled)

Boolean properties for both of these?

Thanks,
Mark.

> +
> +Example:
> +
> +ethernet at 0 {
> +	...
> +	fixed-link = <1 1 1000 0 0>;
> +	...
> +};
> +
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index d5a57a9..66d5591 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -14,6 +14,7 @@
>  #include <linux/netdevice.h>
>  #include <linux/err.h>
>  #include <linux/phy.h>
> +#include <linux/phy_fixed.h>
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_mdio.h>
> @@ -215,10 +216,6 @@ EXPORT_SYMBOL(of_phy_connect);
>   * @dev: pointer to net_device claiming the phy
>   * @hndlr: Link state callback for the network device
>   * @iface: PHY data interface type
> - *
> - * This function is a temporary stop-gap and will be removed soon.  It is
> - * only to support the fs_enet, ucc_geth and gianfar Ethernet drivers.  Do
> - * not call this function from new drivers.
>   */
>  struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
>  					     void (*hndlr)(struct net_device *),
> @@ -247,3 +244,34 @@ struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
>  	return IS_ERR(phy) ? NULL : phy;
>  }
>  EXPORT_SYMBOL(of_phy_connect_fixed_link);
> +
> +#if defined(CONFIG_FIXED_PHY)
> +/**
> + * of_phy_register_fixed_link - Parse fixed-link property and register a dummy phy
> + * @np: pointer to the OF device node that contains the "fixed-link"
> + * property for which a dummy phy should be registered.
> + */
> +#define FIXED_LINK_PROPERTIES_COUNT 5
> +int of_phy_register_fixed_link(struct device_node *np)
> +{
> +	struct fixed_phy_status status = {};
> +	u32 fixed_link_props[FIXED_LINK_PROPERTIES_COUNT];
> +	int ret;
> +
> +	ret = of_property_read_u32_array(np, "fixed-link",
> +					 fixed_link_props,
> +					 FIXED_LINK_PROPERTIES_COUNT);
> +	if (ret < 0)
> +		return ret;
> +
> +	status.link       = 1;
> +	status.duplex     = fixed_link_props[1];
> +	status.speed      = fixed_link_props[2];
> +	status.pause      = fixed_link_props[3];
> +	status.asym_pause = fixed_link_props[4];
> +
> +	return fixed_phy_add(PHY_POLL, fixed_link_props[0],
> +			     &status);
> +}
> +EXPORT_SYMBOL(of_phy_register_fixed_link);
> +#endif
> diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
> index 8163107..bf6efea 100644
> --- a/include/linux/of_mdio.h
> +++ b/include/linux/of_mdio.h
> @@ -57,4 +57,14 @@ static inline struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np)
>  }
>  #endif /* CONFIG_OF */
>  
> +#if defined(CONFIG_OF) && defined(CONFIG_FIXED_PHY)
> +extern int of_phy_register_fixed_link(struct device_node *np);
> +#else
> +static inline int of_phy_register_fixed_link(struct device_node *np)
> +{
> +	return -ENOSYS;
> +}
> +#endif
> +
> +
>  #endif /* __LINUX_OF_MDIO_H */
> -- 
> 1.8.1.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From t.figa at samsung.com  Tue Jul 23 07:25:25 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 13:25:25 +0200
Subject: [PATCH v2 1/8] clk: mux: Add support for read-only muxes.
In-Reply-To: <51EE6784.2090808@cogentembedded.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
 <1374536965-3545-2-git-send-email-tomasz.figa@gmail.com>
 <51EE6784.2090808@cogentembedded.com>
Message-ID: <3464612.aV7xx5H2mf@amdc1227>

Hi Sergei,

On Tuesday 23 of July 2013 15:22:44 Sergei Shtylyov wrote:
> Hello.
> 
> On 23-07-2013 3:49, Tomasz Figa wrote:
> > Some platforms have read-only clock muxes that are preconfigured at
> > reset and cannot be changed at runtime. This patch extends mux clock
> > driver to allow handling such read-only muxes by adding new
> > CLK_MUX_READ_ONLY mux flag.
> > 
> > Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> 
> [...]
> 
> > diff --git a/include/linux/clk-provider.h
> > b/include/linux/clk-provider.h
> > index 1ec14a7..9487b96 100644
> > --- a/include/linux/clk-provider.h
> > +++ b/include/linux/clk-provider.h
> > @@ -327,8 +327,10 @@ struct clk_mux {
> > #define CLK_MUX_INDEX_ONE		BIT(0)
> > #define CLK_MUX_INDEX_BIT		BIT(1)
> > #define CLK_MUX_HIWORD_MASK		BIT(2)
> > +#define CLK_MUX_READ_ONLY	BIT(3) /* mux setting cannot be changed */
> 
>     Please align BIT(3) with the above BIT() invocations.

Different indentation was intended here to fit the comment, like in case of 
generic flags. IMHO remaining flags should be changed to this way as well, 
but this is probably material for another patch.

Best regards,
Tomasz



From Sudeep.KarkadaNagesha at arm.com  Tue Jul 23 07:32:43 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Tue, 23 Jul 2013 12:32:43 +0100
Subject: [PATCH 4/5] ARM: highbank: remove redundant smp_init_cpus definition
In-Reply-To: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374579164-30255-5-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

arm_dt_init_cpu_maps is called before smp_init_cpus, which sets the
cpu_possible_mask appropriately. Since highbank_smp_init_cpus does
nothing extra, it can be removed.

Cc: Rob Herring <rob.herring at calxeda.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/mach-highbank/platsmp.c | 22 ----------------------
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/mach-highbank/platsmp.c b/arch/arm/mach-highbank/platsmp.c
index 32d75cf5..25b0bae 100644
--- a/arch/arm/mach-highbank/platsmp.c
+++ b/arch/arm/mach-highbank/platsmp.c
@@ -31,27 +31,6 @@ static int highbank_boot_secondary(unsigned int cpu, struct task_struct *idle)
 	return 0;
 }
 
-/*
- * Initialise the CPU possible map early - this describes the CPUs
- * which may be present or become present in the system.
- */
-static void __init highbank_smp_init_cpus(void)
-{
-	unsigned int i, ncores = 4;
-
-	/* sanity check */
-	if (ncores > NR_CPUS) {
-		printk(KERN_WARNING
-		       "highbank: no. of cores (%d) greater than configured "
-		       "maximum of %d - clipping\n",
-		       ncores, NR_CPUS);
-		ncores = NR_CPUS;
-	}
-
-	for (i = 0; i < ncores; i++)
-		set_cpu_possible(i, true);
-}
-
 static void __init highbank_smp_prepare_cpus(unsigned int max_cpus)
 {
 	if (scu_base_addr)
@@ -59,7 +38,6 @@ static void __init highbank_smp_prepare_cpus(unsigned int max_cpus)
 }
 
 struct smp_operations highbank_smp_ops __initdata = {
-	.smp_init_cpus		= highbank_smp_init_cpus,
 	.smp_prepare_cpus	= highbank_smp_prepare_cpus,
 	.smp_boot_secondary	= highbank_boot_secondary,
 #ifdef CONFIG_HOTPLUG_CPU
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Tue Jul 23 07:32:41 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Tue, 23 Jul 2013 12:32:41 +0100
Subject: [PATCH 2/5] ARM: vexpress: remove redundant vexpress_dt_cpus_num to
 get cpu count
In-Reply-To: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374579164-30255-3-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

arm_dt_init_cpu_maps parses the device tree, validates and sets the
cpu_possible_mask appropriately. It is unnecessary to do another DT
parse to get the number of cpus, use num_possible_cpus instead.

This patch also removes setting cpu_present_mask as platforms should
only re-initialize it in smp_prepare_cpus() if present != possible.

Acked-by: Pawel Moll <pawel.moll at arm.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/mach-vexpress/platsmp.c | 32 +-------------------------------
 1 file changed, 1 insertion(+), 31 deletions(-)

diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
index 993c9ae..4a2d8c4 100644
--- a/arch/arm/mach-vexpress/platsmp.c
+++ b/arch/arm/mach-vexpress/platsmp.c
@@ -77,39 +77,13 @@ void __init vexpress_dt_smp_map_io(void)
 		WARN_ON(of_scan_flat_dt(vexpress_dt_find_scu, NULL));
 }
 
-static int __init vexpress_dt_cpus_num(unsigned long node, const char *uname,
-		int depth, void *data)
-{
-	static int prev_depth = -1;
-	static int nr_cpus = -1;
-
-	if (prev_depth > depth && nr_cpus > 0)
-		return nr_cpus;
-
-	if (nr_cpus < 0 && strcmp(uname, "cpus") == 0)
-		nr_cpus = 0;
-
-	if (nr_cpus >= 0) {
-		const char *device_type = of_get_flat_dt_prop(node,
-				"device_type", NULL);
-
-		if (device_type && strcmp(device_type, "cpu") == 0)
-			nr_cpus++;
-	}
-
-	prev_depth = depth;
-
-	return 0;
-}
-
 static void __init vexpress_dt_smp_init_cpus(void)
 {
 	int ncores = 0, i;
 
 	switch (vexpress_dt_scu) {
 	case GENERIC_SCU:
-		ncores = of_scan_flat_dt(vexpress_dt_cpus_num, NULL);
-		break;
+		return;
 	case CORTEX_A9_SCU:
 		ncores = scu_get_core_count(vexpress_dt_cortex_a9_scu_base);
 		break;
@@ -133,12 +107,8 @@ static void __init vexpress_dt_smp_init_cpus(void)
 
 static void __init vexpress_dt_smp_prepare_cpus(unsigned int max_cpus)
 {
-	int i;
-
 	switch (vexpress_dt_scu) {
 	case GENERIC_SCU:
-		for (i = 0; i < max_cpus; i++)
-			set_cpu_present(i, true);
 		break;
 	case CORTEX_A9_SCU:
 		scu_enable(vexpress_dt_cortex_a9_scu_base);
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Tue Jul 23 07:32:40 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Tue, 23 Jul 2013 12:32:40 +0100
Subject: [PATCH 1/5] ARM: keystone: remove redundant smp_init_cpus definition
In-Reply-To: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374579164-30255-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

arm_dt_init_cpu_maps is called before smp_init_cpus. It makes the
platform/SoC definition of smp_init_cpus unnecessary.

Cc: Santosh Shilimkar <santosh.shilimkar at ti.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/mach-keystone/platsmp.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-keystone/platsmp.c b/arch/arm/mach-keystone/platsmp.c
index 14378e3..c122961 100644
--- a/arch/arm/mach-keystone/platsmp.c
+++ b/arch/arm/mach-keystone/platsmp.c
@@ -38,6 +38,5 @@ static int keystone_smp_boot_secondary(unsigned int cpu,
 }
 
 struct smp_operations keystone_smp_ops __initdata = {
-	.smp_init_cpus		= arm_dt_init_cpu_maps,
 	.smp_boot_secondary	= keystone_smp_boot_secondary,
 };
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Tue Jul 23 07:32:39 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Tue, 23 Jul 2013 12:32:39 +0100
Subject: [PATCH 0/5] ARM: DT: remove redundant DT related code
Message-ID: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

Hi,

As part of my changes to remove duplicate code for parsing cpu nodes
in the device tree, I found few unnecessary code mostly around smp_init_cpus.
Most of the ARM Cortex A9 based platforms use SCU to get the number of cpus
while many others depend on the device tree.

Even on DT based platforms using SCU, they can be made to depend on DT
to cpu count simplifying smp_init_cpus. In fact arm_dt_init_cpu_maps called
before smp_init_cpus, already does the device tree parsing, validating
nr_cpu_ids and setting the cpu_possible_mask appropriately. 

However this series targets only the platforms using DT for cpu count
(i.e. not using SCU)

Regards,
Sudeep

Sudeep KarkadaNagesha (5):
  ARM: keystone: remove redundant smp_init_cpus definition
  ARM: vexpress: remove redundant vexpress_dt_cpus_num to get cpu count
  ARM: mach-mvebu: remove redundant DT parsing and validation
  ARM: highbank: remove redundant smp_init_cpus definition
  ARM: zynq: remove unnecessary setting of cpu_present_mask

 arch/arm/mach-highbank/platsmp.c | 22 ----------------------
 arch/arm/mach-keystone/platsmp.c |  1 -
 arch/arm/mach-mvebu/platsmp.c    | 19 +------------------
 arch/arm/mach-vexpress/platsmp.c | 32 +-------------------------------
 arch/arm/mach-zynq/platsmp.c     |  9 ---------
 5 files changed, 2 insertions(+), 81 deletions(-)

-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Tue Jul 23 07:32:42 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Tue, 23 Jul 2013 12:32:42 +0100
Subject: [PATCH 3/5] ARM: mach-mvebu: remove redundant DT parsing and
 validation
In-Reply-To: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374579164-30255-4-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

arm_dt_init_cpu_maps parses the device tree, validates and sets the
cpu_possible_mask appropriately. It is unnecessary to do another DT
parse to get the number of cpus, use num_possible_cpus instead.

Cc: Gregory Clement <gregory.clement at free-electrons.com>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/mach-mvebu/platsmp.c | 19 +------------------
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index ce81d30..2e4508a 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -87,28 +87,11 @@ static int armada_xp_boot_secondary(unsigned int cpu, struct task_struct *idle)
 
 static void __init armada_xp_smp_init_cpus(void)
 {
-	struct device_node *np;
-	unsigned int i, ncores;
+	unsigned int ncores = num_possible_cpus();
 
-	np = of_find_node_by_name(NULL, "cpus");
-	if (!np)
-		panic("No 'cpus' node found\n");
-
-	ncores = of_get_child_count(np);
 	if (ncores == 0 || ncores > ARMADA_XP_MAX_CPUS)
 		panic("Invalid number of CPUs in DT\n");
 
-	/* Limit possible CPUs to defconfig */
-	if (ncores > nr_cpu_ids) {
-		pr_warn("SMP: %d CPUs physically present. Only %d configured.",
-			ncores, nr_cpu_ids);
-		pr_warn("Clipping CPU count to %d\n", nr_cpu_ids);
-		ncores = nr_cpu_ids;
-	}
-
-	for (i = 0; i < ncores; i++)
-		set_cpu_possible(i, true);
-
 	set_smp_cross_call(armada_mpic_send_doorbell);
 }
 
-- 
1.8.1.2




From Sudeep.KarkadaNagesha at arm.com  Tue Jul 23 07:32:44 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Tue, 23 Jul 2013 12:32:44 +0100
Subject: [PATCH 5/5] ARM: zynq: remove unnecessary setting of cpu_present_mask
In-Reply-To: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374579164-30255-6-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

This patch also removes setting cpu_present_mask as platforms should
only re-initialize it in smp_prepare_cpus() if present != possible.

Cc: Michal Simek <michal.simek at xilinx.com>
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
---
 arch/arm/mach-zynq/platsmp.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
index 689fbbc..ae121b8 100644
--- a/arch/arm/mach-zynq/platsmp.c
+++ b/arch/arm/mach-zynq/platsmp.c
@@ -114,15 +114,6 @@ static void __init zynq_smp_init_cpus(void)
 
 static void __init zynq_smp_prepare_cpus(unsigned int max_cpus)
 {
-	int i;
-
-	/*
-	 * Initialise the present map, which describes the set of CPUs
-	 * actually populated at the present time.
-	 */
-	for (i = 0; i < max_cpus; i++)
-		set_cpu_present(i, true);
-
 	scu_enable(zynq_scu_base);
 }
 
-- 
1.8.1.2




From stefano.stabellini at eu.citrix.com  Tue Jul 23 07:35:40 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 23 Jul 2013 12:35:40 +0100
Subject: [PATCH] xen/arm64: Don't compile cpu hotplug
In-Reply-To: <1374529258-12866-1-git-send-email-julien.grall@linaro.org>
References: <1374529258-12866-1-git-send-email-julien.grall@linaro.org>
Message-ID: <alpine.DEB.2.02.1307231235330.4893@kaball.uk.xensource.com>

On Mon, 22 Jul 2013, Julien Grall wrote:
> On ARM64, when CONFIG_XEN=y, the compilation will fail because CPU hotplug is
> not yet supported with XEN. For now, disable it.
> 
> Signed-off-by: Julien Grall <julien.grall at linaro.org>

Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>


>  drivers/xen/Makefile |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 2bf461a..a609353 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -1,4 +1,4 @@
> -ifneq ($(CONFIG_ARM),y)
> +ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
>  obj-y	+= manage.o
>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>  endif
> -- 
> 1.7.10.4
> 


From will.deacon at arm.com  Tue Jul 23 07:36:24 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:36:24 +0100
Subject: [PATCH 1/6] ARM: prefetch: remove redundant "cc" clobber
In-Reply-To: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374579389-32704-2-git-send-email-will.deacon@arm.com>

The pld instruction does not affect the condition flags, so don't bother
clobbering them.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/processor.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 06e7d50..91cfe08 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -101,9 +101,7 @@ static inline void prefetch(const void *ptr)
 {
 	__asm__ __volatile__(
 		"pld\t%a0"
-		:
-		: "p" (ptr)
-		: "cc");
+		:: "p" (ptr));
 }
 
 #define ARCH_HAS_PREFETCHW
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:36:25 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:36:25 +0100
Subject: [PATCH 2/6] ARM: smp_on_up: move inline asm ALT_SMP patching macro
 out of spinlock.h
In-Reply-To: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374579389-32704-3-git-send-email-will.deacon@arm.com>

Patching UP/SMP alternatives inside inline assembly blocks is useful
outside of the spinlock implementation, where it is used for sev and wfe.

This patch lifts the macro into processor.h and gives it a scarier name
to (a) avoid conflicts in the global namespace and (b) to try and deter
its usage unless you "know what you're doing". The W macro for generating
wide instructions when targetting Thumb-2 is also made available under
the name WASM, to reduce the potential for conflicts with other headers.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/processor.h | 12 ++++++++++++
 arch/arm/include/asm/spinlock.h  | 15 ++++-----------
 arch/arm/include/asm/unified.h   |  4 ++++
 3 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 91cfe08..cbdb130 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -22,6 +22,7 @@
 #include <asm/hw_breakpoint.h>
 #include <asm/ptrace.h>
 #include <asm/types.h>
+#include <asm/unified.h>
 
 #ifdef __KERNEL__
 #define STACK_TOP	((current->personality & ADDR_LIMIT_32BIT) ? \
@@ -91,6 +92,17 @@ unsigned long get_wchan(struct task_struct *p);
 #define KSTK_EIP(tsk)	task_pt_regs(tsk)->ARM_pc
 #define KSTK_ESP(tsk)	task_pt_regs(tsk)->ARM_sp
 
+#ifdef CONFIG_SMP
+#define __ALT_SMP_ASM(smp, up)						\
+	"9998:	" smp "\n"						\
+	"	.pushsection \".alt.smp.init\", \"a\"\n"		\
+	"	.long	9998b\n"					\
+	"	" up "\n"						\
+	"	.popsection\n"
+#else
+#define __ALT_SMP_ASM(smp, up)	up
+#endif
+
 /*
  * Prefetching support - only ARMv5.
  */
diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index f8b8965..0de7bec 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -11,15 +11,7 @@
  * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
  * extensions, so when running on UP, we have to patch these instructions away.
  */
-#define ALT_SMP(smp, up)					\
-	"9998:	" smp "\n"					\
-	"	.pushsection \".alt.smp.init\", \"a\"\n"	\
-	"	.long	9998b\n"				\
-	"	" up "\n"					\
-	"	.popsection\n"
-
 #ifdef CONFIG_THUMB2_KERNEL
-#define SEV		ALT_SMP("sev.w", "nop.w")
 /*
  * For Thumb-2, special care is needed to ensure that the conditional WFE
  * instruction really does assemble to exactly 4 bytes (as required by
@@ -31,17 +23,18 @@
  * the assembler won't change IT instructions which are explicitly present
  * in the input.
  */
-#define WFE(cond)	ALT_SMP(		\
+#define WFE(cond)	__ALT_SMP_ASM(		\
 	"it " cond "\n\t"			\
 	"wfe" cond ".n",			\
 						\
 	"nop.w"					\
 )
 #else
-#define SEV		ALT_SMP("sev", "nop")
-#define WFE(cond)	ALT_SMP("wfe" cond, "nop")
+#define WFE(cond)	__ALT_SMP_ASM("wfe" cond, "nop")
 #endif
 
+#define SEV		__ALT_SMP_ASM(WASM(sev), WASM(nop))
+
 static inline void dsb_sev(void)
 {
 #if __LINUX_ARM_ARCH__ >= 7
diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
index f5989f4..b88beab 100644
--- a/arch/arm/include/asm/unified.h
+++ b/arch/arm/include/asm/unified.h
@@ -38,6 +38,8 @@
 #ifdef __ASSEMBLY__
 #define W(instr)	instr.w
 #define BSYM(sym)	sym + 1
+#else
+#define WASM(instr)	#instr ".w"
 #endif
 
 #else	/* !CONFIG_THUMB2_KERNEL */
@@ -50,6 +52,8 @@
 #ifdef __ASSEMBLY__
 #define W(instr)	instr
 #define BSYM(sym)	sym
+#else
+#define WASM(instr)	#instr
 #endif
 
 #endif	/* CONFIG_THUMB2_KERNEL */
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:36:29 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:36:29 +0100
Subject: [PATCH 6/6] ARM: bitops: prefetch the destination word for write
 prior to strex
In-Reply-To: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374579389-32704-7-git-send-email-will.deacon@arm.com>

The cost of changing a cacheline from shared to exclusive state can be
significant, especially when this is triggered by an exclusive store,
since it may result in having to retry the transaction.

This patch prefixes our atomic bitops implementation with prefetchw,
to try and grab the line in exclusive state from the start. The testop
macro is left alone, since the barrier semantics limit the usefulness
of prefetching data.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/lib/bitops.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index d6408d1..e0c68d5 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h
@@ -10,6 +10,11 @@ UNWIND(	.fnstart	)
 	and	r3, r0, #31		@ Get bit offset
 	mov	r0, r0, lsr #5
 	add	r1, r1, r0, lsl #2	@ Get word offset
+#if __LINUX_ARM_ARCH__ >= 7
+	.arch_extension	mp
+	ALT_SMP(W(pldw)	[r1])
+	ALT_UP(W(nop))
+#endif
 	mov	r3, r2, lsl r3
 1:	ldrex	r2, [r1]
 	\instr	r2, r2, r3
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:36:26 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:36:26 +0100
Subject: [PATCH 3/6] ARM: prefetch: add support for prefetchw using pldw on
 SMP ARMv7+ CPUs
In-Reply-To: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374579389-32704-4-git-send-email-will.deacon@arm.com>

SMP ARMv7 CPUs implement the pldw instruction, which allows them to
prefetch data cachelines in an exclusive state.

This patch defines the prefetchw macro using pldw for CPUs that support
it.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/processor.h | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index cbdb130..d571697 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -116,12 +116,19 @@ static inline void prefetch(const void *ptr)
 		:: "p" (ptr));
 }
 
+#if __LINUX_ARM_ARCH__ >= 7 && defined(CONFIG_SMP)
 #define ARCH_HAS_PREFETCHW
-#define prefetchw(ptr)	prefetch(ptr)
-
-#define ARCH_HAS_SPINLOCK_PREFETCH
-#define spin_lock_prefetch(x) do { } while (0)
-
+static inline void prefetchw(const void *ptr)
+{
+	__asm__ __volatile__(
+		".arch_extension	mp\n"
+	__ALT_SMP_ASM(
+		WASM(pldw)		"\t%a0",
+		WASM(pld)		"\t%a0"
+	)
+		:: "p" (ptr));
+}
+#endif
 #endif
 
 #define HAVE_ARCH_PICK_MMAP_LAYOUT
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:36:28 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:36:28 +0100
Subject: [PATCH 5/6] ARM: atomics: prefetch the destination word for write
 prior to strex
In-Reply-To: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374579389-32704-6-git-send-email-will.deacon@arm.com>

The cost of changing a cacheline from shared to exclusive state can be
significant, especially when this is triggered by an exclusive store,
since it may result in having to retry the transaction.

This patch prefixes our atomic access implementations with pldw
instructions (on CPUs which support them) to try and grab the line in
exclusive state from the start. Only the barrier-less functions are
updated, since memory barriers can limit the usefulness of prefetching
data.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/atomic.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index da1c77d..e3f052a 100644
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h
@@ -12,6 +12,7 @@
 #define __ASM_ARM_ATOMIC_H
 
 #include <linux/compiler.h>
+#include <linux/prefetch.h>
 #include <linux/types.h>
 #include <linux/irqflags.h>
 #include <asm/barrier.h>
@@ -41,6 +42,7 @@ static inline void atomic_add(int i, atomic_t *v)
 	unsigned long tmp;
 	int result;
 
+	prefetchw((const void *)&v->counter);
 	__asm__ __volatile__("@ atomic_add\n"
 "1:	ldrex	%0, [%3]\n"
 "	add	%0, %0, %4\n"
@@ -79,6 +81,7 @@ static inline void atomic_sub(int i, atomic_t *v)
 	unsigned long tmp;
 	int result;
 
+	prefetchw((const void *)&v->counter);
 	__asm__ __volatile__("@ atomic_sub\n"
 "1:	ldrex	%0, [%3]\n"
 "	sub	%0, %0, %4\n"
@@ -138,6 +141,7 @@ static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
 {
 	unsigned long tmp, tmp2;
 
+	prefetchw((const void *)addr);
 	__asm__ __volatile__("@ atomic_clear_mask\n"
 "1:	ldrex	%0, [%3]\n"
 "	bic	%0, %0, %4\n"
@@ -283,6 +287,7 @@ static inline void atomic64_set(atomic64_t *v, u64 i)
 {
 	u64 tmp;
 
+	prefetchw((const void *)&v->counter);
 	__asm__ __volatile__("@ atomic64_set\n"
 "1:	ldrexd	%0, %H0, [%2]\n"
 "	strexd	%0, %3, %H3, [%2]\n"
@@ -299,6 +304,7 @@ static inline void atomic64_add(u64 i, atomic64_t *v)
 	u64 result;
 	unsigned long tmp;
 
+	prefetchw((const void *)&v->counter);
 	__asm__ __volatile__("@ atomic64_add\n"
 "1:	ldrexd	%0, %H0, [%3]\n"
 "	adds	%0, %0, %4\n"
@@ -339,6 +345,7 @@ static inline void atomic64_sub(u64 i, atomic64_t *v)
 	u64 result;
 	unsigned long tmp;
 
+	prefetchw((const void *)&v->counter);
 	__asm__ __volatile__("@ atomic64_sub\n"
 "1:	ldrexd	%0, %H0, [%3]\n"
 "	subs	%0, %0, %4\n"
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:36:23 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:36:23 +0100
Subject: [PATCH 0/6] Add support for pldw instruction on v7 MP cores
Message-ID: <1374579389-32704-1-git-send-email-will.deacon@arm.com>

Hello,

This patch series adds support for the pldw instruction implemented on
ARMv7 SMP processors. The instruction is used to implement the prefetchw
macro, which is then used around barrier-less ldrex/strex sections (i.e.
the prefetch isn't blocked either side by memory barriers) to increase
the chances of the strex succeeding initially.

On my TC2 board (A7s + A15s), I see a ~1.3% boost in hackbench scores
on top of my barriers patch series.

All feedback welcome,

Will


Will Deacon (6):
  ARM: prefetch: remove redundant "cc" clobber
  ARM: smp_on_up: move inline asm ALT_SMP patching macro out of
    spinlock.h
  ARM: prefetch: add support for prefetchw using pldw on SMP ARMv7+ CPUs
  ARM: locks: prefetch the destination word for write prior to strex
  ARM: atomics: prefetch the destination word for write prior to strex
  ARM: bitops: prefetch the destination word for write prior to strex

 arch/arm/include/asm/atomic.h    |  7 +++++++
 arch/arm/include/asm/processor.h | 33 +++++++++++++++++++++++++--------
 arch/arm/include/asm/spinlock.h  | 24 ++++++++++++------------
 arch/arm/include/asm/unified.h   |  4 ++++
 arch/arm/lib/bitops.h            |  5 +++++
 5 files changed, 53 insertions(+), 20 deletions(-)

-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 23 07:36:27 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 12:36:27 +0100
Subject: [PATCH 4/6] ARM: locks: prefetch the destination word for write prior
 to strex
In-Reply-To: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374579389-32704-5-git-send-email-will.deacon@arm.com>

The cost of changing a cacheline from shared to exclusive state can be
significant, especially when this is triggered by an exclusive store,
since it may result in having to retry the transaction.

This patch prefixes our {spin,read,write}_[try]lock implementations with
pldw instructions (on CPUs which support them) to try and grab the line
in exclusive state from the start.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/spinlock.h | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index 0de7bec..3e1cc9d 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -5,7 +5,7 @@
 #error SMP not supported on pre-ARMv6 CPUs
 #endif
 
-#include <asm/processor.h>
+#include <linux/prefetch.h>
 
 /*
  * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
@@ -70,6 +70,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
 	u32 newval;
 	arch_spinlock_t lockval;
 
+	prefetchw((const void *)&lock->slock);
 	__asm__ __volatile__(
 "1:	ldrex	%0, [%3]\n"
 "	add	%1, %0, %4\n"
@@ -93,6 +94,7 @@ static inline int arch_spin_trylock(arch_spinlock_t *lock)
 	unsigned long contended, res;
 	u32 slock;
 
+	prefetchw((const void *)&lock->slock);
 	do {
 		__asm__ __volatile__(
 		"	ldrex	%0, [%3]\n"
@@ -145,6 +147,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
 {
 	unsigned long tmp;
 
+	prefetchw((const void *)&rw->lock);
 	__asm__ __volatile__(
 "1:	ldrex	%0, [%1]\n"
 "	teq	%0, #0\n"
@@ -163,6 +166,7 @@ static inline int arch_write_trylock(arch_rwlock_t *rw)
 {
 	unsigned long tmp;
 
+	prefetchw((const void *)&rw->lock);
 	__asm__ __volatile__(
 "	ldrex	%0, [%1]\n"
 "	teq	%0, #0\n"
@@ -211,6 +215,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
 {
 	unsigned long tmp, tmp2;
 
+	prefetchw((const void *)&rw->lock);
 	__asm__ __volatile__(
 "1:	ldrex	%0, [%2]\n"
 "	adds	%0, %0, #1\n"
@@ -231,6 +236,7 @@ static inline void arch_read_unlock(arch_rwlock_t *rw)
 
 	smp_mb();
 
+	prefetchw((const void *)&rw->lock);
 	__asm__ __volatile__(
 "1:	ldrex	%0, [%2]\n"
 "	sub	%0, %0, #1\n"
@@ -249,6 +255,7 @@ static inline int arch_read_trylock(arch_rwlock_t *rw)
 {
 	unsigned long tmp, tmp2 = 1;
 
+	prefetchw((const void *)&rw->lock);
 	__asm__ __volatile__(
 "	ldrex	%0, [%2]\n"
 "	adds	%0, %0, #1\n"
-- 
1.8.2.2



From stefano.stabellini at eu.citrix.com  Tue Jul 23 07:37:04 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 23 Jul 2013 12:37:04 +0100
Subject: [PATCH v4] xen/arm: enable PV control for ARM
In-Reply-To: <5228e08a-1cdb-4240-b10f-9ad690c94ac4@email.android.com>
References: <1374529321-12955-1-git-send-email-julien.grall@linaro.org>
 <5228e08a-1cdb-4240-b10f-9ad690c94ac4@email.android.com>
Message-ID: <alpine.DEB.2.02.1307231235510.4893@kaball.uk.xensource.com>

On Mon, 22 Jul 2013, Konrad Rzeszutek Wilk wrote:
> Julien Grall <julien.grall at linaro.org> wrote:
> >Enable power management from the toolstack for ARM guest.
> >
> >Signed-off-by: Julien Grall <julien.grall at linaro.org>
> >
> >---
> >    Changes in v4:
> >        - Divide the patch in 2 distinct parts
> >    Changes in v3:
> >        - Fix condition to compile cpu_hotplug.o
> >    Changes in v2:
> >        - Don't compile xen/cpu_hotplug.o with ARM64
> >---
> > drivers/xen/Makefile |    3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> >diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> >index a609353..f185e8d 100644
> >--- a/drivers/xen/Makefile
> >+++ b/drivers/xen/Makefile
> >@@ -1,9 +1,8 @@
> > ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
> >-obj-y	+= manage.o
> > obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
> > endif
> > obj-$(CONFIG_X86)			+= fallback.o
> >-obj-y	+= grant-table.o features.o events.o balloon.o time.o
> >+obj-y	+= grant-table.o features.o events.o balloon.o time.o manage.o
> > obj-y	+= xenbus/
> > 
> > nostackp := $(call cc-option, -fno-stack-protector)
> 
> The patch looks Ok but the description is off.  Power management is the term used for cpu freq,  C states and P states. While this patch touches none of that. 
> 

That's a very x86-centric view of the world, but it's true that manage.c
is about shutdown, restart and other operations that don't fit under
"power management".
It could benefit from a better description.


From grant.likely at secretlab.ca  Tue Jul 23 07:39:52 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Tue, 23 Jul 2013 12:39:52 +0100
Subject: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link'
 property
In-Reply-To: <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CACxGe6td6uM0v5w92xPVCaVH4tP4AJ-h4SnN-mFoz5gSSosnQw@mail.gmail.com>

On Mon, Jul 15, 2013 at 4:34 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Some Ethernet MACs have a "fixed link", and are not connected to a
> normal MDIO-managed PHY device. For those situations, a Device Tree
> binding allows to describe a "fixed link", as a "fixed-link" property
> of the Ethernet device Device Tree node.
>
> This patch adds:
>
>  * A documentation for the Device Tree property "fixed-link".
>
>  * A of_phy_register_fixed_link() OF helper, which provided an OF node
>    that contains a "fixed-link" property, registers the corresponding
>    fixed PHY.
>
>  * Removes the warning on the of_phy_connect_fixed_link() that says
>    new drivers should not use it, since Grant Likely indicated that
>    this "fixed-link" property is indeed the way to go.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  .../devicetree/bindings/net/fixed-link.txt         | 26 ++++++++++++++++
>  drivers/of/of_mdio.c                               | 36 +++++++++++++++++++---
>  include/linux/of_mdio.h                            | 10 ++++++
>  3 files changed, 68 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/fixed-link.txt
>
> diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt
> new file mode 100644
> index 0000000..25a009a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/fixed-link.txt
> @@ -0,0 +1,26 @@
> +Fixed link Device Tree binding
> +------------------------------
> +
> +Some Ethernet MACs have a "fixed link", and are not connected to a
> +normal MDIO-managed PHY device. For those situations, a Device Tree
> +binding allows to describe a "fixed link".
> +
> +Such a fixed link situation is described within an Ethernet device
> +Device Tree node using a 'fixed-link' property, composed of 5
> +elements:
> +
> + 1. A fake PHY ID, which must be unique accross all fixed-link PHYs in
> +    the system.

That's just loony!  :)  Regardless of existing code doing this, it is
absolutely ridiculous to have it in the driver. The kernel should
handle generating a phy id transparently. I'd rather mark this field
as reserved in the binding and change the code to not care about it
anymore.

g.

> + 2. The duplex (1 for full-duplex, 0 for half-duplex)
> + 3. The speed (10, 100, 1000)
> + 4. The pause setting (1 for enabled, 0 for disabled)
> + 5. The asym pause setting (1 for enabled, 0 for disabled)
> +
> +Example:
> +
> +ethernet at 0 {
> +       ...
> +       fixed-link = <1 1 1000 0 0>;
> +       ...
> +};
> +
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index d5a57a9..66d5591 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -14,6 +14,7 @@
>  #include <linux/netdevice.h>
>  #include <linux/err.h>
>  #include <linux/phy.h>
> +#include <linux/phy_fixed.h>
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_mdio.h>
> @@ -215,10 +216,6 @@ EXPORT_SYMBOL(of_phy_connect);
>   * @dev: pointer to net_device claiming the phy
>   * @hndlr: Link state callback for the network device
>   * @iface: PHY data interface type
> - *
> - * This function is a temporary stop-gap and will be removed soon.  It is
> - * only to support the fs_enet, ucc_geth and gianfar Ethernet drivers.  Do
> - * not call this function from new drivers.
>   */
>  struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
>                                              void (*hndlr)(struct net_device *),
> @@ -247,3 +244,34 @@ struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
>         return IS_ERR(phy) ? NULL : phy;
>  }
>  EXPORT_SYMBOL(of_phy_connect_fixed_link);
> +
> +#if defined(CONFIG_FIXED_PHY)
> +/**
> + * of_phy_register_fixed_link - Parse fixed-link property and register a dummy phy
> + * @np: pointer to the OF device node that contains the "fixed-link"
> + * property for which a dummy phy should be registered.
> + */
> +#define FIXED_LINK_PROPERTIES_COUNT 5
> +int of_phy_register_fixed_link(struct device_node *np)
> +{
> +       struct fixed_phy_status status = {};
> +       u32 fixed_link_props[FIXED_LINK_PROPERTIES_COUNT];
> +       int ret;
> +
> +       ret = of_property_read_u32_array(np, "fixed-link",
> +                                        fixed_link_props,
> +                                        FIXED_LINK_PROPERTIES_COUNT);
> +       if (ret < 0)
> +               return ret;
> +
> +       status.link       = 1;
> +       status.duplex     = fixed_link_props[1];
> +       status.speed      = fixed_link_props[2];
> +       status.pause      = fixed_link_props[3];
> +       status.asym_pause = fixed_link_props[4];
> +
> +       return fixed_phy_add(PHY_POLL, fixed_link_props[0],
> +                            &status);
> +}
> +EXPORT_SYMBOL(of_phy_register_fixed_link);
> +#endif
> diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
> index 8163107..bf6efea 100644
> --- a/include/linux/of_mdio.h
> +++ b/include/linux/of_mdio.h
> @@ -57,4 +57,14 @@ static inline struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np)
>  }
>  #endif /* CONFIG_OF */
>
> +#if defined(CONFIG_OF) && defined(CONFIG_FIXED_PHY)
> +extern int of_phy_register_fixed_link(struct device_node *np);
> +#else
> +static inline int of_phy_register_fixed_link(struct device_node *np)
> +{
> +       return -ENOSYS;
> +}
> +#endif
> +
> +
>  #endif /* __LINUX_OF_MDIO_H */
> --
> 1.8.1.2
>


From florian at openwrt.org  Tue Jul 23 07:39:56 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Tue, 23 Jul 2013 12:39:56 +0100
Subject: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link'
 property
In-Reply-To: <20130723112259.GE4833@e106331-lin.cambridge.arm.com>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130723112259.GE4833@e106331-lin.cambridge.arm.com>
Message-ID: <CAGVrzcaAw4TNLUKw6L52jXY0KTHShZWS7tnP5mHHky9eFVKsYg@mail.gmail.com>

Hello,

2013/7/23 Mark Rutland <mark.rutland at arm.com>:
[snip]

>> +++ b/Documentation/devicetree/bindings/net/fixed-link.txt
>> @@ -0,0 +1,26 @@
>> +Fixed link Device Tree binding
>> +------------------------------
>> +
>> +Some Ethernet MACs have a "fixed link", and are not connected to a
>> +normal MDIO-managed PHY device. For those situations, a Device Tree
>> +binding allows to describe a "fixed link".
>
> Are partictular MACs fixed link, or can some either be either fixed link
> or wired to an MDIO-managed PHY? i.e. can we assume a given MAC is
> fixed-link from its compatible string?

There are different use-cases out there:

- you lack or do not want to have a proper switch/PHY library driver
for an Ethernet switch, but that specific switch may still be
accessible on the MDIO bus, yet you just want to expose a link UP from
the CPU port perspective, that specific use case should dissapear in
favor of a simplified PHY library driver which just eventually makes
the link appear as UP from the CPU port perspective

- you have absolutely no control over the PHY on the MDIO bus
        * for switches, it could be SPI, I2C, GPIO whatever, so to
avoid any dependency, you might just want to let the link appear as UP
        * or you could have a very different PHY whose data-path is
Ethernet, but the control-path is something else, e.g: MoCA (which is
more the kind of use-case I am interested in)

>
>> +
>> +Such a fixed link situation is described within an Ethernet device
>> +Device Tree node using a 'fixed-link' property, composed of 5
>> +elements:
>
> I'm not sure grouping these values together is the best way of handling
> this. It's rather opaque, and inflexible for future extension.

Well, I proposed making them look like a "standard" Ethernet PHY node
but this somehow got rejected, see at the very bottom.

>
>> +
>> + 1. A fake PHY ID, which must be unique accross all fixed-link PHYs in
>> +    the system.
>
> Is there any reason this couldn't be allocated dynamically within the
> kernel as needed? I don't see why an arbitrary unique value should be a
> dt binding requirement; it seems like a leak of Linux implementation
> details.

Honestly, I do not really think actually letting this be configurable
is a good idea because it would become some sort of user-space ABI. If
we want to expose some PHY identification registers, we could use some
ID2 and ID3 values which are not allocated to any vendor, or allocated
to the Linux foundation (e.g; like what USB does with Linux HUBs).

>
>> + 2. The duplex (1 for full-duplex, 0 for half-duplex)
>
> Will this change for a given MAC?
>
> Could we not have a boolean property for each of these, and require one
> to be present?
>
> Possibly fixed-link-full-duplex / fix-link-half-duplex?
>
>> + 3. The speed (10, 100, 1000)
>
> fixed-link-speed?
>
>> + 4. The pause setting (1 for enabled, 0 for disabled)
>> + 5. The asym pause setting (1 for enabled, 0 for disabled)
>
> Boolean properties for both of these?
>
> Thanks,
> Mark.
>
>> +
>> +Example:
>> +
>> +ethernet at 0 {
>> +     ...
>> +     fixed-link = <1 1 1000 0 0>;
>> +     ...
>> +};
>> +

The initial proposal that I had suggested was this:

ethernet-phy at 0 {
     reg = <0>;
     id = <0xdeadbeef>;
     speed = <1000>;
     full-duplex;
     pause;
     asym-pause;
};

which looks more or less what you seem to want as well but this
somehow makes it look like a real PHY device, so we could argue that
this has nowhere to be in the Device Tree. Arguably there are a
gazillions of other bindings which imho should also not be in a Device
Tree.
--
Florian


From gsi at denx.de  Tue Jul 23 07:53:48 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Tue, 23 Jul 2013 13:53:48 +0200
Subject: [PATCH v3 11/31] net: can: mscan: improve clock API use
In-Reply-To: <51ED2619.5040107@pengutronix.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
 <1374495298-22019-12-git-send-email-gsi@denx.de>
 <51ED2619.5040107@pengutronix.de>
Message-ID: <20130723115348.GF19071@book.gsilab.sittig.org>

On Mon, Jul 22, 2013 at 14:31 +0200, Marc Kleine-Budde wrote:
> 
> On 07/22/2013 02:14 PM, Gerhard Sittig wrote:
> > the .get_clock() callback is run from probe() and might allocate
> > resources, introduce a .put_clock() callback that is run from remove()
> > to undo any allocation activities
> 
> looks good
> 
> > use devm_get_clk() upon lookup (for SYS and REF) to have the clocks put
> > upon driver unload
> 
> fine
> 
> > assume that resources get prepared but not necessarily enabled in the
> > setup phase, make the open() and close() callbacks of the CAN network
> > device enable and disable a previously acquired and prepared clock
> 
> I think you should call prepare_enable and disable_unprepare in the
> open/close functions.

After more local research, which totally eliminated the need to
pre-enable the CAN related clocks, but might need more discussion
as it touches the common gate support, I've learned something
more:

The CAN clock needs to get enabled during probe() already, since
registers get accessed between probe() for the driver and open()
for the network device -- while access to peripheral registers
crashes the kernel when clocks still are disabled (other hardware
may just hang or provide fake data, neither of this is OK).

But I see the point in your suggestion to prepare _and_ enable
the clock during open() as well -- to have open() cope with
whatever probe() did, after all the driver is shared among
platforms, which may differ in what they do during probe().

So I will:
- make open() of the network device prepare _and_ enable the
  clock for the peripheral (if acquired during probe())
- adjust open() because ATM it leaves the clock enabled when the
  network device operation fails (the error path is incomplete in
  v3)
- make the MPC512x specific probe() time .get_clock() routine not
  just prepare but enable the clock as well
- and of course address all the shutdown counter parts of the
  above setup paths

This results in:
- specific chip drivers only need to balance their private get
  and put clock routines which are called from probe and remove,
  common paths DTRT for all of them
- correct operation for MPC512x, where common clock is used
- still everything is neutral for MPC5200 where common clock
  isn't used, behaviour is identical to before the change
- no assumptions are made about what occurs or doesn't occur
  during probe(), when the network device is used then the clock
  is fully setup and operational
- when the CAN network device isn't setup (because device tree
  doesn't describe it, or disables that node), then its clock
  remains idle (neither gets setup nor enabled)
- complete preparation for future improvement wrt power
  consumption, where potential changes remain isolated to the
  specific chip (probe() time setup, get_clock() routine) while
  the ndo part need not get touched any more

So this is the most appropriate approach I can come up with.


Removing unnecessary devm_put_clk() calls is orthogonal to that.
Putting these in isn't totally wrong (they won't harm, and they
do signal "visual balance" more clearly such that the next person
won't stop and wonder), but it's true that they are redundant.
"Trained persons" will wonder as much about their presence as
untrained persons wonder about their absence. :)  Apparently I'm
not well trained yet.

I thought that being explicit and cautious would be good, but the
feedback I got suggests that encoding unnecessary instructions
isn't desirable.  So I will remove those devm_put_clk() in v4.

To save us one more iteration, shall I remove those calls only
from error paths during setup?  Or shall I remove them from
regular shutdown paths as well?  How much pain does the community
feel with harmless yet unnecessary instructions? :)


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


From gsi at denx.de  Tue Jul 23 07:58:12 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Tue, 23 Jul 2013 13:58:12 +0200
Subject: [PATCH v3 01/31] spi: mpc512x: cleanup clock API use
In-Reply-To: <20130722140904.GU9858@sirena.org.uk>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
 <1374495298-22019-2-git-send-email-gsi@denx.de>
 <20130722140904.GU9858@sirena.org.uk>
Message-ID: <20130723115812.GG19071@book.gsilab.sittig.org>

[ devicetree at vger adjusted ]

On Mon, Jul 22, 2013 at 15:09 +0100, Mark Brown wrote:
> 
> On Mon, Jul 22, 2013 at 02:14:28PM +0200, Gerhard Sittig wrote:
> 
> > +	ret = clk_prepare_enable(clk);
> > +	if (ret) {
> > +		devm_clk_put(dev, clk);
> > +		goto free_irq;
> 
> The main point of the devm_ APIs is to avoid the need for explicit
> freeing so you should just remove these puts.

OK, will do in v4.

Shall these get removed everywhere including regular shutdown
paths, or just from error paths during setup?

[ the same topic came up for the CAN patch, might answer there ]


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


From stefano.stabellini at eu.citrix.com  Tue Jul 23 08:01:17 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 23 Jul 2013 13:01:17 +0100
Subject: [PATCH v3] xen/arm,
 arm64: update xen_restart after ff701306cd49 and 7b6d864b48d9
Message-ID: <1374580878-22202-1-git-send-email-stefano.stabellini@eu.citrix.com>

Commit 7b6d864b48d9 (reboot: arm: change reboot_mode to use enum
reboot_mode) and ff701306cd49 (arm64: use common reboot infrastructure)
change the prototype of arm_pm_restart on arm and arm64.
Update xen_restart accordingly.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/xen/enlighten.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index f71c37e..c9770ba 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -172,7 +172,7 @@ static void __init xen_percpu_init(void *unused)
 	enable_percpu_irq(xen_events_irq, 0);
 }
 
-static void xen_restart(char str, const char *cmd)
+static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
 {
 	struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
 	int rc;
-- 
1.7.2.5



From a.motakis at virtualopensystems.com  Tue Jul 23 08:04:56 2013
From: a.motakis at virtualopensystems.com (Antonios Motakis)
Date: Tue, 23 Jul 2013 14:04:56 +0200
Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to
 an IOMMU group
In-Reply-To: <00e601ce8796$bdca50c0$395ef240$%dae@samsung.com>
References: <1374573694-30595-1-git-send-email-a.motakis@virtualopensystems.com>
 <00d701ce878f$da099fe0$8e1cdfa0$%dae@samsung.com>
 <CAG8rG2wNG9wVjKxtaDzLRybvh3wPVR08j9G9OPcK=a2Gwbtg-g@mail.gmail.com>
 <00e601ce8796$bdca50c0$395ef240$%dae@samsung.com>
Message-ID: <CAG8rG2xJ4z9cwrMtLhOrPKnw+fdL_H4doDPARNfvLj+JHTjByQ@mail.gmail.com>

On Tue, Jul 23, 2013 at 1:21 PM, Inki Dae <inki.dae at samsung.com> wrote:
>
>
>> -----Original Message-----
>> From: Antonios Motakis [mailto:a.motakis at virtualopensystems.com]
>> Sent: Tuesday, July 23, 2013 8:00 PM
>> To: Inki Dae
>> Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
> KyongHo;
>> Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
>> Subject: Re: [PATCH] iommu/exynos: add devices attached to the System MMU
>> to an IOMMU group
>>
>> On Tue, Jul 23, 2013 at 12:31 PM, Inki Dae <inki.dae at samsung.com> wrote:
>> >
>> >
>> >
>> > > -----Original Message-----
>> > > From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-
>> soc-
>> > > owner at vger.kernel.org] On Behalf Of Antonios Motakis
>> > > Sent: Tuesday, July 23, 2013 7:02 PM
>> > > To: linux-arm-kernel at lists.infradead.org;
>> > iommu at lists.linux-foundation.org;
>> > > linux-samsung-soc at vger.kernel.org
>> > > Cc: kvmarm at lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo; Joerg
>> > > Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
>> > > Subject: [PATCH] iommu/exynos: add devices attached to the System MMU
>> to
>> > > an IOMMU group
>> > >
>> > > IOMMU groups are expected by certain users of the IOMMU API,
>> > > e.g. VFIO. Since each device is behind its own System MMU, we
>> > > can allocate a new IOMMU group for each device.
>> > >
>> > > This patch depends on Cho KyongHo's patch series titled "[PATCH v7
>> 00/12]
>> > > iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
>> > > applied on a Linux 3.10.1 kernel. It has been tested on the Arndale
>> board.
>> > >
>> > > Signed-off-by: Antonios Motakis <a.motakis at virtualopensystems.com>
>> > > ---
>> > >  drivers/iommu/exynos-iommu.c | 24 ++++++++++++++++++++++++
>> > >  1 file changed, 24 insertions(+)
>> > >
>> > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-
>> iommu.c
>> > > index 51d43bb..9f39eaa 100644
>> > > --- a/drivers/iommu/exynos-iommu.c
>> > > +++ b/drivers/iommu/exynos-iommu.c
>> > > @@ -1134,6 +1134,28 @@ static phys_addr_t
>> exynos_iommu_iova_to_phys(struct
>> > > iommu_domain *domain,
>> > >       return phys;
>> > >  }
>> > >
>> > > +static int exynos_iommu_add_device(struct device *dev)
>> > > +{
>> > > +     struct iommu_group *group;
>> > > +     int ret;
>> > > +
>> > > +     group = iommu_group_alloc();
>> >
>> > Is that correct? I don't see why you allocate a group object every time
>> > add_device callback is called. That doesn't have any meaning we have to
>> use
>> > iommu group feature. I think the implementation should be one more
>> devices
>> > per a group. So I guess a given device object should be wrapped by
>> higher
>> > device object than the given device object. For a good example, you can
>> > refer to intel-iommu.c file.
>>
>> With an Intel IOMMU it can be the case that 2 devices have to share
>> the same IOMMU mappings (i.e. you can't program them separately). With
>> the Exynos System MMU, there is always one System MMU per device, so
>> there is nothing stopping you from programming any 2 devices' mappings
>> differently. So yes, the right thing to do here is to have a one to
>> one relationship between devices and IOMMU groups.
>
> In case of Exynos drm driver, a unified iommu mapping table is used for all
> devices (fimd, g2d, hdmi, fimc, gsc, rotator) based on drm so they use the
> same iommu mapping table even though they have each iommu hardware unit. And
> the iommu mapping table is just logical data structure for hardware
> translation process by each DMA. Actually, I am considering using iommu
> group feature for more generic implementation.

But is this grouping imposed by the hardware in some way, or is it
just the way you handle them in software? In the latter case, then
what you are looking for are IOMMU domains (which can contain multiple
groups). IOMMU groups describe something that is imposed by the
hardware.

>
> And one question. Why do you allocate a iommu group object if we should have
> one to one relationship between devices and iommu groups? In this case, is
> there any reason you have to use the iommu group object?

Generic IOMMU code (such as VFIO) will check for IOMMU groups to
determine how the devices behind an IOMMU relate to each other.
Returning a unique IOMMU group object per device provides this
information - that each device can also be programmed separately. VFIO
relies on this behavior - if it doesn't find any IOMMU group objects
it will refuse to use the device.

Additionally, this information can be seen by userspace. Being able to
programmatically determine that there is a one to one relationship is
certainly useful.

I don't think the lack of IOMMU groups implies no grouping - I think
it implies unknown grouping or an incomplete driver, so in my opinion
VFIO is correct in refusing to work without IOMMU groups. So any
future ARM support for VFIO, will also rely on IOMMU groups.

>
> Thanks,
> Inki Dae
>
>>
>> (resending because of html mail)
>>
>> Cheers,
>> Antonios
>>
>> >
>> >
>> > Thanks,
>> > Inki Dae
>> >
>> > > +     if (IS_ERR(group)) {
>> > > +             dev_err(dev, "Failed to allocate IOMMU group\n");
>> > > +             return PTR_ERR(group);
>> > > +     }
>> > > +
>> > > +     ret = iommu_group_add_device(group, dev);
>> > > +     iommu_group_put(group);
>> > > +
>> > > +     return ret;
>> > > +}
>> > > +
>> > > +static void exynos_iommu_remove_device(struct device *dev)
>> > > +{
>> > > +     iommu_group_remove_device(dev);
>> > > +}
>> > > +
>> > >  static struct iommu_ops exynos_iommu_ops = {
>> > >       .domain_init = &exynos_iommu_domain_init,
>> > >       .domain_destroy = &exynos_iommu_domain_destroy,
>> > > @@ -1142,6 +1164,8 @@ static struct iommu_ops exynos_iommu_ops = {
>> > >       .map = &exynos_iommu_map,
>> > >       .unmap = &exynos_iommu_unmap,
>> > >       .iova_to_phys = &exynos_iommu_iova_to_phys,
>> > > +     .add_device     = exynos_iommu_add_device,
>> > > +     .remove_device  = exynos_iommu_remove_device,
>> > >       .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
>> > >  };
>> > >
>> > > --
>> > > 1.8.1.2
>> > >
>> > > --
>> > > To unsubscribe from this list: send the line "unsubscribe linux-
>> samsung-
>> > > soc" in
>> > > the body of a message to majordomo at vger.kernel.org
>> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>


From festevam at gmail.com  Tue Jul 23 08:06:39 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 23 Jul 2013 09:06:39 -0300
Subject: [PATCH v2] ARM: Do not run dummy_flush_tlb_a15_erratum() on
 non-Cortex-A15
Message-ID: <1374581199-8277-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Commit 93dc688 (ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 
(TLBI/DSB operations)) causes the following undefined instruction error on a
mx53 (Cortex-A8):

Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
CPU: 0 PID: 275 Comm: modprobe Not tainted 3.11.0-rc2-next-20130722-00009-g9b0f371 #881
task: df46cc00 ti: df48e000 task.ti: df48e000
PC is at check_and_switch_context+0x17c/0x4d0
LR is at check_and_switch_context+0xdc/0x4d0

This problem happens because check_and_switch_context() calls 
dummy_flush_tlb_a15_erratum() without checking if we are really running on a 
Cortex-A15 or not. 

To avoid this issue, only call dummy_flush_tlb_a15_erratum() inside 
check_and_switch_context() if erratum_a15_798181() returns true, which means
that we are really running on a Cortex-A15.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- Add 'if (erratum_a15_798181())' inside check_and_switch_context()

 arch/arm/include/asm/tlbflush.h | 16 ++++++++++++++++
 arch/arm/kernel/smp_tlb.c       | 17 -----------------
 arch/arm/mm/context.c           |  3 ++-
 3 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index fdbb9e3..f467e9b 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -443,7 +443,18 @@ static inline void local_flush_bp_all(void)
 		isb();
 }
 
+#include <asm/cputype.h>
 #ifdef CONFIG_ARM_ERRATA_798181
+static inline int erratum_a15_798181(void)
+{
+	unsigned int midr = read_cpuid_id();
+
+	/* Cortex-A15 r0p0..r3p2 affected */
+	if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2)
+		return 0;
+	return 1;
+}
+
 static inline void dummy_flush_tlb_a15_erratum(void)
 {
 	/*
@@ -453,6 +464,11 @@ static inline void dummy_flush_tlb_a15_erratum(void)
 	dsb();
 }
 #else
+static inline int erratum_a15_798181(void)
+{
+	return 0;
+}
+
 static inline void dummy_flush_tlb_a15_erratum(void)
 {
 }
diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
index a98b62d..c2edfff 100644
--- a/arch/arm/kernel/smp_tlb.c
+++ b/arch/arm/kernel/smp_tlb.c
@@ -70,23 +70,6 @@ static inline void ipi_flush_bp_all(void *ignored)
 	local_flush_bp_all();
 }
 
-#ifdef CONFIG_ARM_ERRATA_798181
-static int erratum_a15_798181(void)
-{
-	unsigned int midr = read_cpuid_id();
-
-	/* Cortex-A15 r0p0..r3p2 affected */
-	if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2)
-		return 0;
-	return 1;
-}
-#else
-static int erratum_a15_798181(void)
-{
-	return 0;
-}
-#endif
-
 static void ipi_flush_tlb_a15_erratum(void *arg)
 {
 	dmb();
diff --git a/arch/arm/mm/context.c b/arch/arm/mm/context.c
index b55b101..4a05444 100644
--- a/arch/arm/mm/context.c
+++ b/arch/arm/mm/context.c
@@ -245,7 +245,8 @@ void check_and_switch_context(struct mm_struct *mm, struct task_struct *tsk)
 	if (cpumask_test_and_clear_cpu(cpu, &tlb_flush_pending)) {
 		local_flush_bp_all();
 		local_flush_tlb_all();
-		dummy_flush_tlb_a15_erratum();
+		if (erratum_a15_798181())
+			dummy_flush_tlb_a15_erratum();
 	}
 
 	atomic64_set(&per_cpu(active_asids, cpu), asid);
-- 
1.8.1.2



From gsi at denx.de  Tue Jul 23 08:07:33 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Tue, 23 Jul 2013 14:07:33 +0200
Subject: [PATCH v3 27/31] net: can: mscan: add common clock support for
 mpc512x
In-Reply-To: <51ED2DF4.2090606@pengutronix.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
 <1374495298-22019-28-git-send-email-gsi@denx.de>
 <51ED2DF4.2090606@pengutronix.de>
Message-ID: <20130723120733.GH19071@book.gsilab.sittig.org>

[ adjusted devtree to use the vger address ]

On Mon, Jul 22, 2013 at 15:04 +0200, Marc Kleine-Budde wrote:
> 
> On 07/22/2013 02:14 PM, Gerhard Sittig wrote:
> > implement a .get_clock() callback for the MPC512x platform which uses
> > the common clock infrastructure (eliminating direct access to the clock
> > control registers from within the CAN network driver), and provide the
> > corresponding .put_clock() callback to release resources after use
> > 
> > keep the previous implementation of MPC512x support in place during
> > migration, since common clock support is optional
> > 
> > this change is neutral to the MPC5200 platform
> > 
> > Signed-off-by: Gerhard Sittig <gsi at denx.de>
> > ---
> >  drivers/net/can/mscan/mpc5xxx_can.c |  169 +++++++++++++++++++++++++++++++++++
> >  1 file changed, 169 insertions(+)
> > 
> > diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
> > index e59b3a3..4897929 100644
> > --- a/drivers/net/can/mscan/mpc5xxx_can.c
> > +++ b/drivers/net/can/mscan/mpc5xxx_can.c
> > @@ -109,6 +109,167 @@ static u32 mpc52xx_can_get_clock(struct platform_device *ofdev,
> >  #endif /* CONFIG_PPC_MPC52xx */
> >  
> >  #ifdef CONFIG_PPC_MPC512x
> > +
> > +#if IS_ENABLED(CONFIG_COMMON_CLK)
> > +
> > +static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
> > +				 const char *clock_source, int *mscan_clksrc)
> > +{
> > +	struct device_node *np;
> > +	u32 clockdiv;
> > +	enum {
> > +		CLK_FROM_AUTO,
> > +		CLK_FROM_IPS,
> > +		CLK_FROM_SYS,
> > +		CLK_FROM_REF,
> > +	} clk_from;
> > +	struct clk *clk_in, *clk_can;
> > +	unsigned long freq_calc;
> > +	struct mscan_priv *priv;
> > +
> > +	/* the caller passed in the clock source spec that was read from
> > +	 * the device tree, get the optional clock divider as well
> > +	 */
> > +	np = ofdev->dev.of_node;
> > +	clockdiv = 1;
> > +	of_property_read_u32(np, "fsl,mscan-clock-divider", &clockdiv);
> > +	dev_dbg(&ofdev->dev, "device tree specs: clk src[%s] div[%d]\n",
> > +		clock_source ? clock_source : "<NULL>", clockdiv);
> > +
> > +	/* when clock-source is 'ip', the CANCTL1[CLKSRC] bit needs to
> > +	 * get set, and the 'ips' clock is the input to the MSCAN
> > +	 * component
> > +	 *
> > +	 * for clock-source values of 'ref' or 'sys' the CANCTL1[CLKSRC]
> > +	 * bit needs to get cleared, an optional clock-divider may have
> > +	 * been specified (the default value is 1), the appropriate
> > +	 * MSCAN related MCLK is the input to the MSCAN component
> > +	 *
> > +	 * in the absence of a clock-source spec, first an optimal clock
> > +	 * gets determined based on the 'sys' clock, if that fails the
> > +	 * 'ref' clock is used
> > +	 */
> > +	clk_from = CLK_FROM_AUTO;
> > +	if (clock_source) {
> > +		/* interpret the device tree's spec for the clock source */
> > +		if (!strcmp(clock_source, "ip"))
> > +			clk_from = CLK_FROM_IPS;
> > +		else if (!strcmp(clock_source, "sys"))
> > +			clk_from = CLK_FROM_SYS;
> > +		else if (!strcmp(clock_source, "ref"))
> > +			clk_from = CLK_FROM_REF;
> > +		else
> > +			goto err_invalid;
> > +		dev_dbg(&ofdev->dev, "got a clk source spec[%d]\n", clk_from);
> > +	}
> > +	if (clk_from == CLK_FROM_AUTO) {
> > +		/* no spec so far, try the 'sys' clock; round to the
> > +		 * next MHz and see if we can get a multiple of 16MHz
> > +		 */
> > +		dev_dbg(&ofdev->dev, "no clk source spec, trying SYS\n");
> > +		clk_in = devm_clk_get(&ofdev->dev, "sys");
> > +		if (IS_ERR(clk_in))
> > +			goto err_notavail;
> > +		freq_calc = clk_get_rate(clk_in);
> > +		freq_calc +=  499999;
> > +		freq_calc /= 1000000;
> > +		freq_calc *= 1000000;
> > +		if ((freq_calc % 16000000) == 0) {
> > +			clk_from = CLK_FROM_SYS;
> > +			clockdiv = freq_calc / 16000000;
> > +			dev_dbg(&ofdev->dev,
> > +				"clk fit, sys[%lu] div[%d] freq[%lu]\n",
> > +				freq_calc, clockdiv, freq_calc / clockdiv);
> > +		}
> > +	}
> > +	if (clk_from == CLK_FROM_AUTO) {
> > +		/* no spec so far, use the 'ref' clock */
> > +		dev_dbg(&ofdev->dev, "no clk source spec, trying REF\n");
> > +		clk_in = devm_clk_get(&ofdev->dev, "ref");
> > +		if (IS_ERR(clk_in))
> > +			goto err_notavail;
> > +		clk_from = CLK_FROM_REF;
> > +		freq_calc = clk_get_rate(clk_in);
> > +		dev_dbg(&ofdev->dev,
> > +			"clk fit, ref[%lu] (no div) freq[%lu]\n",
> > +			freq_calc, freq_calc);
> > +	}
> > +
> > +	/* select IPS or MCLK as the MSCAN input (returned to the caller),
> > +	 * setup the MCLK mux source and rate if applicable, apply the
> > +	 * optionally specified or derived above divider, and determine
> > +	 * the actual resulting clock rate to return to the caller
> > +	 */
> > +	switch (clk_from) {
> > +	case CLK_FROM_IPS:
> > +		clk_can = devm_clk_get(&ofdev->dev, "ips");
> > +		if (IS_ERR(clk_can))
> > +			goto err_notavail;
> > +		if (clk_prepare(clk_can)) {
> 
> I would just call prepare_enable in the main mscan driver, then we don't
> need a special "clock is prepared but not enabled" contract.

Yes, I addressed this concern (although differently after
learning more from a local test setup), see the other reply for
the CAN driver adjustment for clock API use.

> 
> > +			devm_clk_put(&ofdev->dev, clk_can);
> 
> not needed, as this driver instance will fail, doesn't it?

This is discussed in the other subthread as well.  The only
remaining question is how many of them to remove, before I'll
update the series.

> > +			goto err_notavail;
> > +		}
> > +		priv = netdev_priv(dev_get_drvdata(&ofdev->dev));
> > +		priv->clk_can = clk_can;
> > +		freq_calc = clk_get_rate(clk_can);
> > +		*mscan_clksrc = MSCAN_CLKSRC_IPS;
> > +		dev_dbg(&ofdev->dev, "clk from IPS, clksrc[%d] freq[%lu]\n",
> > +			*mscan_clksrc, freq_calc);
> > +		break;
> > +	case CLK_FROM_SYS:
> > +	case CLK_FROM_REF:
> > +		clk_can = devm_clk_get(&ofdev->dev, "mclk");
> > +		if (IS_ERR(clk_can))
> > +			goto err_notavail;
> > +		if (clk_prepare(clk_can)) {
> > +			devm_clk_put(&ofdev->dev, clk_can);
> 
> same here
> 
> > +			goto err_notavail;
> > +		}
> > +		priv = netdev_priv(dev_get_drvdata(&ofdev->dev));
> > +		priv->clk_can = clk_can;
> > +		if (clk_from == CLK_FROM_SYS)
> > +			clk_in = devm_clk_get(&ofdev->dev, "sys");
> > +		if (clk_from == CLK_FROM_REF)
> > +			clk_in = devm_clk_get(&ofdev->dev, "ref");
> > +		if (IS_ERR(clk_in))
> > +			goto err_notavail;
> > +		clk_set_parent(clk_can, clk_in);
> > +		freq_calc = clk_get_rate(clk_in);
> > +		freq_calc /= clockdiv;
> > +		clk_set_rate(clk_can, freq_calc);
> > +		freq_calc = clk_get_rate(clk_can);
> > +		*mscan_clksrc = MSCAN_CLKSRC_BUS;
> > +		dev_dbg(&ofdev->dev, "clk from MCLK, clksrc[%d] freq[%lu]\n",
> > +			*mscan_clksrc, freq_calc);
> > +		break;
> > +	default:
> > +		goto err_invalid;
> > +	}
> > +
> > +	return freq_calc;
> > +
> > +err_invalid:
> > +	dev_err(&ofdev->dev, "invalid clock source specification\n");
> > +	return 0;
> 
> return 0 in case of error? Please add a comment what this 0 means here.

The .get_clock() callback is supposed to return the resulting
rate after the clock source was determined and the clock subtree
was setup.  It wasn't (explicitly) documented before (in the
non-common-clock case), so I did not bother to comment it in the
parallel common-clock case.

But it's true that returning zero in the error case may be
unexpected, and I will add a comment in v4 (in all the
.get_clock() implementations).

> > +
> > +err_notavail:
> > +	dev_err(&ofdev->dev, "cannot acquire or setup clock source\n");
> > +	return 0;
> > +}
> > +
> > +static void mpc512x_can_put_clock(struct platform_device *ofdev)
> > +{
> > +	struct mscan_priv *priv;
> > +
> > +	priv = netdev_priv(dev_get_drvdata(&ofdev->dev));
> > +	if (priv->clk_can) {
> > +		clk_unprepare(priv->clk_can);
> > +		devm_clk_put(&ofdev->dev, priv->clk_can);
> 
> devm_clk_put can be removed, it's called automatically.
> 
> > +	}
> > +}
> > +
> > +#else	/* COMMON_CLK */
> > +
> >  struct mpc512x_clockctl {
> >  	u32 spmr;		/* System PLL Mode Reg */
> >  	u32 sccr[2];		/* System Clk Ctrl Reg 1 & 2 */
> > @@ -239,12 +400,18 @@ exit_put:
> >  	of_node_put(np_clock);
> >  	return freq;
> >  }
> > +
> > +#define mpc512x_can_put_clock NULL
> > +
> > +#endif	/* COMMON_CLK */
> > +
> >  #else /* !CONFIG_PPC_MPC512x */
> >  static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
> >  				 const char *clock_name, int *mscan_clksrc)
> >  {
> >  	return 0;
> >  }
> > +#define mpc512x_can_put_clock NULL
> >  #endif /* CONFIG_PPC_MPC512x */
> >  
> >  static const struct of_device_id mpc5xxx_can_table[];
> > @@ -386,11 +553,13 @@ static int mpc5xxx_can_resume(struct platform_device *ofdev)
> >  static const struct mpc5xxx_can_data mpc5200_can_data = {
> >  	.type = MSCAN_TYPE_MPC5200,
> >  	.get_clock = mpc52xx_can_get_clock,
> > +	/* .put_clock not applicable */
> >  };
> >  
> >  static const struct mpc5xxx_can_data mpc5121_can_data = {
> >  	.type = MSCAN_TYPE_MPC5121,
> >  	.get_clock = mpc512x_can_get_clock,
> > +	.put_clock = mpc512x_can_put_clock,
> >  };
> >  
> >  static const struct of_device_id mpc5xxx_can_table[] = {
> > 
> 
> Marc

Thank you for the fast and detailled review.  It's very much
appreciated.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


From monstr at monstr.eu  Tue Jul 23 08:12:09 2013
From: monstr at monstr.eu (Michal Simek)
Date: Tue, 23 Jul 2013 14:12:09 +0200
Subject: scatterlist: sg_set_buf() argument must be in linear mapping
 (sha1: ac4e97abce9b80c020e7113325f49e58b7b15e3f)
In-Reply-To: <20130723103704.GS24642@n2100.arm.linux.org.uk>
References: <51E64C6B.3080306@monstr.eu> <87siz7xt4z.fsf@rustcorp.com.au>
 <51ED2C74.7050502@monstr.eu> <87ppua9feh.fsf@rustcorp.com.au>
 <20130723103704.GS24642@n2100.arm.linux.org.uk>
Message-ID: <51EE7319.408@monstr.eu>

On 07/23/2013 12:37 PM, Russell King - ARM Linux wrote:
> On Tue, Jul 23, 2013 at 12:00:30PM +0930, Rusty Russell wrote:
>> Michal Simek <monstr at monstr.eu> writes:
>>> Let me take some code from virtio_rpmsg_bus.c to show that problematic part.
>>>
>>> bufs_va = dma_alloc_coherent(vdev->dev.parent->parent,
>>> 				RPMSG_TOTAL_BUF_SPACE,
>>> 				&vrp->bufs_dma, GFP_KERNEL);
>>> vrp->rbufs = bufs_va;
>>> for (i = 0; i < RPMSG_NUM_BUFS / 2; i++) {
>>> 	struct scatterlist sg;
>>> 	void *cpu_addr = vrp->rbufs + i * RPMSG_BUF_SIZE;
>>>
>>> 	sg_init_one(&sg, cpu_addr, RPMSG_BUF_SIZE);
>>> }
>>
>> Hmm.  Looking at arch/arm/include/asm/memory.h:
>>
>> #define virt_to_page(kaddr)	pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
>> #define virt_addr_valid(kaddr)	((unsigned long)(kaddr) >= PAGE_OFFSET && (unsigned long)(kaddr) < (unsigned long)high_memory)
>>
>> pfn_to_page in ARM seems to be the asm-generic one, which depends on
>> CONFIG_SPARSEMEM/CONFIG_DISCONTIGMEM/CONFIG_FLATMEM etc.
>>
>> Perhaps virt_addr_valid() is wrong for your config?  It's pretty clear
>> that you shouldn't call virt_to_page() on something for which
>> !virt_addr_valid().
> 
> The above code fragment is just wrong.  You can't make any assumptions about
> the memory returned from dma_alloc_coherent(), because:
> 
> - On x86, it is kernel direct mapped memory, where things like
>   virt_to_phys(cpuaddr) will work fine with it.
> 
> - On any architecture which needs to remap memory to make it coherent
>   with the DMA device, the key word there is "remap" - it's not kernel
>   direct mapped memory, and virt_to_phys(cpuaddr) on it is illegal.
> 
> The only valid operation with scatterlists and such memory returned from
> dma_alloc_coherent() is:
> 
> 	sg_dma_address(sg) = dma_address;
> 	sg_dma_len(sg) = dma_length;
> 
> and not to use the virtual address(es) at all in the scatterlist.  And
> it is very very important to realise that you must not mix the streaming
> and coherent DMA APIs - you must never pass coherent memory into the
> dma_map_* functions.

Ohad: This code is probably yours and you know the whole history of it.
Can you please comment it?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130723/e40ca146/attachment.sig>

From pullip.cho at samsung.com  Tue Jul 23 08:13:04 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Tue, 23 Jul 2013 21:13:04 +0900
Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to an
 IOMMU group
In-Reply-To: <00e601ce8796$bdca50c0$395ef240$%dae@samsung.com>
References: <1374573694-30595-1-git-send-email-a.motakis@virtualopensystems.com>
 <00d701ce878f$da099fe0$8e1cdfa0$%dae@samsung.com>
 <CAG8rG2wNG9wVjKxtaDzLRybvh3wPVR08j9G9OPcK=a2Gwbtg-g@mail.gmail.com>
 <00e601ce8796$bdca50c0$395ef240$%dae@samsung.com>
Message-ID: <002901ce879d$fbec5db0$f3c51910$@samsung.com>

> -----Original Message-----
> From: Inki Dae [mailto:inki.dae at samsung.com]
> Sent: Tuesday, July 23, 2013 8:21 PM
> 
> > -----Original Message-----
> > From: Antonios Motakis [mailto:a.motakis at virtualopensystems.com]
> > Sent: Tuesday, July 23, 2013 8:00 PM
> > To: Inki Dae
> > Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
> KyongHo;
> > Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> > Subject: Re: [PATCH] iommu/exynos: add devices attached to the System MMU
> > to an IOMMU group
> >
> > On Tue, Jul 23, 2013 at 12:31 PM, Inki Dae <inki.dae at samsung.com> wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-
> > soc-
> > > > owner at vger.kernel.org] On Behalf Of Antonios Motakis
> > > > Sent: Tuesday, July 23, 2013 7:02 PM
> > > > To: linux-arm-kernel at lists.infradead.org;
> > > iommu at lists.linux-foundation.org;
> > > > linux-samsung-soc at vger.kernel.org
> > > > Cc: kvmarm at lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo; Joerg
> > > > Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> > > > Subject: [PATCH] iommu/exynos: add devices attached to the System MMU
> > to
> > > > an IOMMU group
> > > >
> > > > IOMMU groups are expected by certain users of the IOMMU API,
> > > > e.g. VFIO. Since each device is behind its own System MMU, we
> > > > can allocate a new IOMMU group for each device.
> > > >
> > > > This patch depends on Cho KyongHo's patch series titled "[PATCH v7
> > 00/12]
> > > > iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> > > > applied on a Linux 3.10.1 kernel. It has been tested on the Arndale
> > board.
> > > >
> > > > Signed-off-by: Antonios Motakis <a.motakis at virtualopensystems.com>
> > > > ---
> > > >  drivers/iommu/exynos-iommu.c | 24 ++++++++++++++++++++++++
> > > >  1 file changed, 24 insertions(+)
> > > >
> > > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-
> > iommu.c
> > > > index 51d43bb..9f39eaa 100644
> > > > --- a/drivers/iommu/exynos-iommu.c
> > > > +++ b/drivers/iommu/exynos-iommu.c
> > > > @@ -1134,6 +1134,28 @@ static phys_addr_t
> > exynos_iommu_iova_to_phys(struct
> > > > iommu_domain *domain,
> > > >       return phys;
> > > >  }
> > > >
> > > > +static int exynos_iommu_add_device(struct device *dev)
> > > > +{
> > > > +     struct iommu_group *group;
> > > > +     int ret;
> > > > +
> > > > +     group = iommu_group_alloc();
> > >
> > > Is that correct? I don't see why you allocate a group object every time
> > > add_device callback is called. That doesn't have any meaning we have to
> > use
> > > iommu group feature. I think the implementation should be one more
> > devices
> > > per a group. So I guess a given device object should be wrapped by
> > higher
> > > device object than the given device object. For a good example, you can
> > > refer to intel-iommu.c file.
> >
> > With an Intel IOMMU it can be the case that 2 devices have to share
> > the same IOMMU mappings (i.e. you can't program them separately). With
> > the Exynos System MMU, there is always one System MMU per device, so
> > there is nothing stopping you from programming any 2 devices' mappings
> > differently. So yes, the right thing to do here is to have a one to
> > one relationship between devices and IOMMU groups.
> 
> In case of Exynos drm driver, a unified iommu mapping table is used for all
> devices (fimd, g2d, hdmi, fimc, gsc, rotator) based on drm so they use the
> same iommu mapping table even though they have each iommu hardware unit. And
> the iommu mapping table is just logical data structure for hardware
> translation process by each DMA. Actually, I am considering using iommu
> group feature for more generic implementation.
> 
> And one question. Why do you allocate a iommu group object if we should have
> one to one relationship between devices and iommu groups? In this case, is
> there any reason you have to use the iommu group object?
> 
> Thanks,
> Inki Dae
> 
Antonios,

Your patch always creates new iommu group whenever .add_device() is called,
which results in memory leak. You need to check if the given device is already
involved in an iommu group.

BTW, I will post new patchset in a few days.
It will not be such different from previous one and your patch
will be rebased on that in a trivial manner.

Regards,
Cho KyongHo

> >
> > (resending because of html mail)
> >
> > Cheers,
> > Antonios
> >
> > >
> > >
> > > Thanks,
> > > Inki Dae
> > >
> > > > +     if (IS_ERR(group)) {
> > > > +             dev_err(dev, "Failed to allocate IOMMU group\n");
> > > > +             return PTR_ERR(group);
> > > > +     }
> > > > +
> > > > +     ret = iommu_group_add_device(group, dev);
> > > > +     iommu_group_put(group);
> > > > +
> > > > +     return ret;
> > > > +}
> > > > +
> > > > +static void exynos_iommu_remove_device(struct device *dev)
> > > > +{
> > > > +     iommu_group_remove_device(dev);
> > > > +}
> > > > +
> > > >  static struct iommu_ops exynos_iommu_ops = {
> > > >       .domain_init = &exynos_iommu_domain_init,
> > > >       .domain_destroy = &exynos_iommu_domain_destroy,
> > > > @@ -1142,6 +1164,8 @@ static struct iommu_ops exynos_iommu_ops = {
> > > >       .map = &exynos_iommu_map,
> > > >       .unmap = &exynos_iommu_unmap,
> > > >       .iova_to_phys = &exynos_iommu_iova_to_phys,
> > > > +     .add_device     = exynos_iommu_add_device,
> > > > +     .remove_device  = exynos_iommu_remove_device,
> > > >       .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
> > > >  };
> > > >
> > > > --
> > > > 1.8.1.2
> > > >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-
> > samsung-
> > > > soc" in
> > > > the body of a message to majordomo at vger.kernel.org
> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > >



From nicolas.pitre at linaro.org  Tue Jul 23 08:28:16 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Jul 2013 08:28:16 -0400 (EDT)
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <20130723104352.GA3023@localhost.localdomain>
References: <1374118116-16836-1-git-send-email-nicolas.pitre@linaro.org>
 <1374118116-16836-2-git-send-email-nicolas.pitre@linaro.org>
 <20130718150408.GB2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181231510.14924@syhkavp.arg>
 <20130718180323.GC2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181452480.14924@syhkavp.arg>
 <20130719102844.GA3746@localhost.localdomain>
 <20130719105907.GB27389@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307221353360.15022@syhkavp.arg>
 <20130723104352.GA3023@localhost.localdomain>
Message-ID: <alpine.LFD.2.03.1307230821270.15022@syhkavp.arg>

On Tue, 23 Jul 2013, Dave Martin wrote:

> On Mon, Jul 22, 2013 at 01:58:12PM -0400, Nicolas Pitre wrote:
> > On Fri, 19 Jul 2013, Lorenzo Pieralisi wrote:
> > 
> > > On Fri, Jul 19, 2013 at 11:28:49AM +0100, Dave Martin wrote:
> > > > On Thu, Jul 18, 2013 at 02:59:06PM -0400, Nicolas Pitre wrote:
> > > > > On Thu, 18 Jul 2013, Dave Martin wrote:
> > > > > 
> > > > > > I had other names in mind, like "coherency_exit" or "cache_exit".
> > > > > > Those are not very intelligible, but that might at least make people
> > > > > > pause and think before blindly using it.
> > > > > 
> > > > > Good point.  It should still embody the architecture name for which it 
> > > > > is valid though.
> > > > 
> > > > Sure, I was assuming something would be pasted on the start of the name.
> > > 
> > > v7 :-) with a comment describing the assumptions (in particular related
> > > as Dave mentioned to the SMP bit behaviour) ?
> > 
> > OK... What about this then:
> > 
> > ----- >8
> > From: Nicolas Pitre <nicolas.pitre at linaro.org>
> > Date: Thu, 18 Jul 2013 13:12:48 -0400
> > Subject: [PATCH] ARM: cacheflush: consolidate single-CPU ARMv7 cache disabling
> >  code
> > 
> > This code is becoming duplicated in many places.  So let's consolidate
> > it into a handy macro that is known to be right and available for reuse.
> > 
> > Signed-off-by: Nicolas Pitre <nico at linaro.org>
> > 
> > diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
> > index 17d0ae8672..8f4e2297e2 100644
> > --- a/arch/arm/include/asm/cacheflush.h
> > +++ b/arch/arm/include/asm/cacheflush.h
> > @@ -436,4 +436,44 @@ static inline void __sync_cache_range_r(volatile void *p, size_t size)
> >  #define sync_cache_w(ptr) __sync_cache_range_w(ptr, sizeof *(ptr))
> >  #define sync_cache_r(ptr) __sync_cache_range_r(ptr, sizeof *(ptr))
> >  
> > +/*
> > + * Disabling cache access for one CPU in an ARMv7 SMP system is tricky.
> > + * To do so we must:
> > + *
> > + * - Clear the SCTLR.C bit to prevent further cache allocations
> > + * - Flush the desired level of cache
> > + * - Clear the ACTLR "SMP" bit to disable local coherency
> > + *
> > + * ... and so without any intervening memory access in between those steps,
> > + * not even to the stack.
> > + *
> > + * WARNING -- After this has been called:
> > + *
> > + * - No ldr/str exclusive must be used.
> 
> Maybe write ldrex/strex (I misread that the first time around as "no
> ldr/str ... must be used", which seemed a bit drastic)

OK.

> > + * - The CPU is obviously no longer coherent with the other CPUs.
> > + *
> > + * Further considerations:
> > + *
> > + * - This relies on the presence and behavior of the AUXCR.SMP bit as
> > + *   documented in the ARMv7 TRM.  Vendor implementations that deviate from
> 
> Sorry to be pedantic here, but there is no "ARMv7 TRM".  The SMP bit is
> not part of ARMv7 at all.

Well, I just copied Lorenzo's words here, trusting he knew more about it 
than I do.

> Also, it seems that A9 isn't precisely the
> same: two ACTLR bits need to be twiddled.  R-class CPUs are generally
> not the same either.
> 
> This is why I preferred to treat the whole sequence as specific to a
> particular CPU implementation.  The similarity between A7 and A15
> might be viewed as a happy coincidence (it also makes life easier in
> big.LITTLE land).

Fair enough.

> (Also, you mix the names "ACTLR" and "AUXCR", but people will generally
> be able to guess those are the same thing)

We apparently use both in the kernel already.  Which one is the 
canonical one?

> > + *   that will need their own procedure.
> > + * - This is unlikely to work if Linux is running non-secure.
> > + */
> > +#define v7_exit_coherency_flush(level) \
> 
> ... hence:
> 
> #define cortex_a15_exit_coherency(level) ...
> 
> #define cortex_a7_exit_coherency(level) cortex_a15_exit_coherency(level)
> 
> What do you think?

To be pedantic again, we don't really exit coherency at some cache 
level.  Hence my usage of "flush" indicating that the level argument 
applies only to that and not to the coherency status.


Nicolas


From a.motakis at virtualopensystems.com  Tue Jul 23 08:23:23 2013
From: a.motakis at virtualopensystems.com (Antonios Motakis)
Date: Tue, 23 Jul 2013 14:23:23 +0200
Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to
 an IOMMU group
In-Reply-To: <002901ce879d$fbec5db0$f3c51910$@samsung.com>
References: <1374573694-30595-1-git-send-email-a.motakis@virtualopensystems.com>
 <00d701ce878f$da099fe0$8e1cdfa0$%dae@samsung.com>
 <CAG8rG2wNG9wVjKxtaDzLRybvh3wPVR08j9G9OPcK=a2Gwbtg-g@mail.gmail.com>
 <00e601ce8796$bdca50c0$395ef240$%dae@samsung.com>
 <002901ce879d$fbec5db0$f3c51910$@samsung.com>
Message-ID: <CAG8rG2xSzMrUU813RPQbDpdoYnj-_Kcx689TMZgX8kYXQRidHg@mail.gmail.com>

On Tue, Jul 23, 2013 at 2:13 PM, Cho KyongHo <pullip.cho at samsung.com> wrote:
>> -----Original Message-----
>> From: Inki Dae [mailto:inki.dae at samsung.com]
>> Sent: Tuesday, July 23, 2013 8:21 PM
>>
>> > -----Original Message-----
>> > From: Antonios Motakis [mailto:a.motakis at virtualopensystems.com]
>> > Sent: Tuesday, July 23, 2013 8:00 PM
>> > To: Inki Dae
>> > Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
>> KyongHo;
>> > Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
>> > Subject: Re: [PATCH] iommu/exynos: add devices attached to the System MMU
>> > to an IOMMU group
>> >
>> > On Tue, Jul 23, 2013 at 12:31 PM, Inki Dae <inki.dae at samsung.com> wrote:
>> > >
>> > >
>> > >
>> > > > -----Original Message-----
>> > > > From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-
>> > soc-
>> > > > owner at vger.kernel.org] On Behalf Of Antonios Motakis
>> > > > Sent: Tuesday, July 23, 2013 7:02 PM
>> > > > To: linux-arm-kernel at lists.infradead.org;
>> > > iommu at lists.linux-foundation.org;
>> > > > linux-samsung-soc at vger.kernel.org
>> > > > Cc: kvmarm at lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo; Joerg
>> > > > Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
>> > > > Subject: [PATCH] iommu/exynos: add devices attached to the System MMU
>> > to
>> > > > an IOMMU group
>> > > >
>> > > > IOMMU groups are expected by certain users of the IOMMU API,
>> > > > e.g. VFIO. Since each device is behind its own System MMU, we
>> > > > can allocate a new IOMMU group for each device.
>> > > >
>> > > > This patch depends on Cho KyongHo's patch series titled "[PATCH v7
>> > 00/12]
>> > > > iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
>> > > > applied on a Linux 3.10.1 kernel. It has been tested on the Arndale
>> > board.
>> > > >
>> > > > Signed-off-by: Antonios Motakis <a.motakis at virtualopensystems.com>
>> > > > ---
>> > > >  drivers/iommu/exynos-iommu.c | 24 ++++++++++++++++++++++++
>> > > >  1 file changed, 24 insertions(+)
>> > > >
>> > > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-
>> > iommu.c
>> > > > index 51d43bb..9f39eaa 100644
>> > > > --- a/drivers/iommu/exynos-iommu.c
>> > > > +++ b/drivers/iommu/exynos-iommu.c
>> > > > @@ -1134,6 +1134,28 @@ static phys_addr_t
>> > exynos_iommu_iova_to_phys(struct
>> > > > iommu_domain *domain,
>> > > >       return phys;
>> > > >  }
>> > > >
>> > > > +static int exynos_iommu_add_device(struct device *dev)
>> > > > +{
>> > > > +     struct iommu_group *group;
>> > > > +     int ret;
>> > > > +
>> > > > +     group = iommu_group_alloc();
>> > >
>> > > Is that correct? I don't see why you allocate a group object every time
>> > > add_device callback is called. That doesn't have any meaning we have to
>> > use
>> > > iommu group feature. I think the implementation should be one more
>> > devices
>> > > per a group. So I guess a given device object should be wrapped by
>> > higher
>> > > device object than the given device object. For a good example, you can
>> > > refer to intel-iommu.c file.
>> >
>> > With an Intel IOMMU it can be the case that 2 devices have to share
>> > the same IOMMU mappings (i.e. you can't program them separately). With
>> > the Exynos System MMU, there is always one System MMU per device, so
>> > there is nothing stopping you from programming any 2 devices' mappings
>> > differently. So yes, the right thing to do here is to have a one to
>> > one relationship between devices and IOMMU groups.
>>
>> In case of Exynos drm driver, a unified iommu mapping table is used for all
>> devices (fimd, g2d, hdmi, fimc, gsc, rotator) based on drm so they use the
>> same iommu mapping table even though they have each iommu hardware unit. And
>> the iommu mapping table is just logical data structure for hardware
>> translation process by each DMA. Actually, I am considering using iommu
>> group feature for more generic implementation.
>>
>> And one question. Why do you allocate a iommu group object if we should have
>> one to one relationship between devices and iommu groups? In this case, is
>> there any reason you have to use the iommu group object?
>>
>> Thanks,
>> Inki Dae
>>
> Antonios,
>
> Your patch always creates new iommu group whenever .add_device() is called,
> which results in memory leak. You need to check if the given device is already
> involved in an iommu group.
>
> BTW, I will post new patchset in a few days.
> It will not be such different from previous one and your patch
> will be rebased on that in a trivial manner.

It is not clear to me why this is the case, can add_device be called
multiple times per device? I will take a look into this.

Anyway thanks for taking this into account.

>
> Regards,
> Cho KyongHo
>
>> >
>> > (resending because of html mail)
>> >
>> > Cheers,
>> > Antonios
>> >
>> > >
>> > >
>> > > Thanks,
>> > > Inki Dae
>> > >
>> > > > +     if (IS_ERR(group)) {
>> > > > +             dev_err(dev, "Failed to allocate IOMMU group\n");
>> > > > +             return PTR_ERR(group);
>> > > > +     }
>> > > > +
>> > > > +     ret = iommu_group_add_device(group, dev);
>> > > > +     iommu_group_put(group);
>> > > > +
>> > > > +     return ret;
>> > > > +}
>> > > > +
>> > > > +static void exynos_iommu_remove_device(struct device *dev)
>> > > > +{
>> > > > +     iommu_group_remove_device(dev);
>> > > > +}
>> > > > +
>> > > >  static struct iommu_ops exynos_iommu_ops = {
>> > > >       .domain_init = &exynos_iommu_domain_init,
>> > > >       .domain_destroy = &exynos_iommu_domain_destroy,
>> > > > @@ -1142,6 +1164,8 @@ static struct iommu_ops exynos_iommu_ops = {
>> > > >       .map = &exynos_iommu_map,
>> > > >       .unmap = &exynos_iommu_unmap,
>> > > >       .iova_to_phys = &exynos_iommu_iova_to_phys,
>> > > > +     .add_device     = exynos_iommu_add_device,
>> > > > +     .remove_device  = exynos_iommu_remove_device,
>> > > >       .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
>> > > >  };
>> > > >
>> > > > --
>> > > > 1.8.1.2
>> > > >
>> > > > --
>> > > > To unsubscribe from this list: send the line "unsubscribe linux-
>> > samsung-
>> > > > soc" in
>> > > > the body of a message to majordomo at vger.kernel.org
>> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> > >
>


From monstr at monstr.eu  Tue Jul 23 08:31:22 2013
From: monstr at monstr.eu (Michal Simek)
Date: Tue, 23 Jul 2013 14:31:22 +0200
Subject: [PATCH 0/5] ARM: DT: remove redundant DT related code
In-Reply-To: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <51EE779A.8000205@monstr.eu>

On 07/23/2013 01:32 PM, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> Hi,
> 
> As part of my changes to remove duplicate code for parsing cpu nodes
> in the device tree, I found few unnecessary code mostly around smp_init_cpus.
> Most of the ARM Cortex A9 based platforms use SCU to get the number of cpus
> while many others depend on the device tree.
> 
> Even on DT based platforms using SCU, they can be made to depend on DT
> to cpu count simplifying smp_init_cpus. In fact arm_dt_init_cpu_maps called
> before smp_init_cpus, already does the device tree parsing, validating
> nr_cpu_ids and setting the cpu_possible_mask appropriately. 
> 
> However this series targets only the platforms using DT for cpu count
> (i.e. not using SCU)

Just a note. Zynq is using SCU to get cpu count not DT.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130723/4d2280f8/attachment.sig>

From mkl at pengutronix.de  Tue Jul 23 08:33:00 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Tue, 23 Jul 2013 14:33:00 +0200
Subject: [PATCH v3 11/31] net: can: mscan: improve clock API use
In-Reply-To: <20130723115348.GF19071@book.gsilab.sittig.org>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
 <1374495298-22019-12-git-send-email-gsi@denx.de>
 <51ED2619.5040107@pengutronix.de>
 <20130723115348.GF19071@book.gsilab.sittig.org>
Message-ID: <51EE77FC.8090809@pengutronix.de>

On 07/23/2013 01:53 PM, Gerhard Sittig wrote:
> On Mon, Jul 22, 2013 at 14:31 +0200, Marc Kleine-Budde wrote:
>>
>> On 07/22/2013 02:14 PM, Gerhard Sittig wrote:
>>> the .get_clock() callback is run from probe() and might allocate
>>> resources, introduce a .put_clock() callback that is run from remove()
>>> to undo any allocation activities
>>
>> looks good
>>
>>> use devm_get_clk() upon lookup (for SYS and REF) to have the clocks put
>>> upon driver unload
>>
>> fine
>>
>>> assume that resources get prepared but not necessarily enabled in the
>>> setup phase, make the open() and close() callbacks of the CAN network
>>> device enable and disable a previously acquired and prepared clock
>>
>> I think you should call prepare_enable and disable_unprepare in the
>> open/close functions.
> 
> After more local research, which totally eliminated the need to
> pre-enable the CAN related clocks, but might need more discussion
> as it touches the common gate support, I've learned something
> more:
> 
> The CAN clock needs to get enabled during probe() already, since
> registers get accessed between probe() for the driver and open()
> for the network device -- while access to peripheral registers
> crashes the kernel when clocks still are disabled (other hardware
> may just hang or provide fake data, neither of this is OK).

Then call prepare_enable(); before and disable_unprepare(); after
accessing the registers. Have a look at the flexcan driver.

> But I see the point in your suggestion to prepare _and_ enable
> the clock during open() as well -- to have open() cope with
> whatever probe() did, after all the driver is shared among
> platforms, which may differ in what they do during probe().

If you enable a clock to access the registers before open() (and disable
it afterwards), it should not harm any architecture that doesn't need
this clock enabled.

> So I will:
> - make open() of the network device prepare _and_ enable the
>   clock for the peripheral (if acquired during probe())

good

> - adjust open() because ATM it leaves the clock enabled when the
>   network device operation fails (the error path is incomplete in
>   v3)

yes, clock should be disabled if open() fails.

> - make the MPC512x specific probe() time .get_clock() routine not
>   just prepare but enable the clock as well

If needed enable the clock, but disable after probe() has finished.

> - and of course address all the shutdown counter parts of the
>   above setup paths

> This results in:
> - specific chip drivers only need to balance their private get
>   and put clock routines which are called from probe and remove,
>   common paths DTRT for all of them

Yes, but clock should not stay enabled between probe() and open().

[...]

> Removing unnecessary devm_put_clk() calls is orthogonal to that.
> Putting these in isn't totally wrong (they won't harm, and they
> do signal "visual balance" more clearly such that the next person
> won't stop and wonder), but it's true that they are redundant.
> "Trained persons" will wonder as much about their presence as
> untrained persons wonder about their absence. :)  Apparently I'm
> not well trained yet.

The whole point about devm_* is to get rid of auto manually tear down
functions. So please remove all devm_put_clk() calls, as it will be
called automatically if a driver instance is removed.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130723/b5b60aaf/attachment-0001.sig>

From Sudeep.KarkadaNagesha at arm.com  Tue Jul 23 08:36:32 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Tue, 23 Jul 2013 13:36:32 +0100
Subject: [PATCH 0/5] ARM: DT: remove redundant DT related code
In-Reply-To: <51EE779A.8000205@monstr.eu>
References: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <51EE779A.8000205@monstr.eu>
Message-ID: <51EE78D0.50803@arm.com>

On 23/07/13 13:31, Michal Simek wrote:
> On 07/23/2013 01:32 PM, Sudeep KarkadaNagesha wrote:
>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>>
>> Hi,
>>
>> As part of my changes to remove duplicate code for parsing cpu nodes
>> in the device tree, I found few unnecessary code mostly around smp_init_cpus.
>> Most of the ARM Cortex A9 based platforms use SCU to get the number of cpus
>> while many others depend on the device tree.
>>
>> Even on DT based platforms using SCU, they can be made to depend on DT
>> to cpu count simplifying smp_init_cpus. In fact arm_dt_init_cpu_maps called
>> before smp_init_cpus, already does the device tree parsing, validating
>> nr_cpu_ids and setting the cpu_possible_mask appropriately. 
>>
>> However this series targets only the platforms using DT for cpu count
>> (i.e. not using SCU)
> 
> Just a note. Zynq is using SCU to get cpu count not DT.
> 
Correct, when I saw that vexpress and zynq were only 2 platforms
setting cpu_present_mask which is unnecessary, I added Zynq last minute
to this series.

Regards,
Sudeep




From pullip.cho at samsung.com  Tue Jul 23 08:36:43 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Tue, 23 Jul 2013 21:36:43 +0900
Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to an
 IOMMU group
In-Reply-To: <CAG8rG2xSzMrUU813RPQbDpdoYnj-_Kcx689TMZgX8kYXQRidHg@mail.gmail.com>
References: <1374573694-30595-1-git-send-email-a.motakis@virtualopensystems.com>
 <00d701ce878f$da099fe0$8e1cdfa0$%dae@samsung.com>
 <CAG8rG2wNG9wVjKxtaDzLRybvh3wPVR08j9G9OPcK=a2Gwbtg-g@mail.gmail.com>
 <00e601ce8796$bdca50c0$395ef240$%dae@samsung.com>
 <002901ce879d$fbec5db0$f3c51910$@samsung.com>
 <CAG8rG2xSzMrUU813RPQbDpdoYnj-_Kcx689TMZgX8kYXQRidHg@mail.gmail.com>
Message-ID: <002d01ce87a1$499e5240$dcdaf6c0$@samsung.com>

> -----Original Message-----
> From: Antonios Motakis [mailto:a.motakis at virtualopensystems.com]
> Sent: Tuesday, July 23, 2013 9:23 PM
> 
> On Tue, Jul 23, 2013 at 2:13 PM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> >> -----Original Message-----
> >> From: Inki Dae [mailto:inki.dae at samsung.com]
> >> Sent: Tuesday, July 23, 2013 8:21 PM
> >>
> >> > -----Original Message-----
> >> > From: Antonios Motakis [mailto:a.motakis at virtualopensystems.com]
> >> > Sent: Tuesday, July 23, 2013 8:00 PM
> >> > To: Inki Dae
> >> > Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
> >> KyongHo;
> >> > Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> >> > Subject: Re: [PATCH] iommu/exynos: add devices attached to the System MMU
> >> > to an IOMMU group
> >> >
> >> > On Tue, Jul 23, 2013 at 12:31 PM, Inki Dae <inki.dae at samsung.com> wrote:
> >> > >
> >> > >
> >> > >
> >> > > > -----Original Message-----
> >> > > > From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-
> >> > soc-
> >> > > > owner at vger.kernel.org] On Behalf Of Antonios Motakis
> >> > > > Sent: Tuesday, July 23, 2013 7:02 PM
> >> > > > To: linux-arm-kernel at lists.infradead.org;
> >> > > iommu at lists.linux-foundation.org;
> >> > > > linux-samsung-soc at vger.kernel.org
> >> > > > Cc: kvmarm at lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo; Joerg
> >> > > > Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> >> > > > Subject: [PATCH] iommu/exynos: add devices attached to the System MMU
> >> > to
> >> > > > an IOMMU group
> >> > > >
> >> > > > IOMMU groups are expected by certain users of the IOMMU API,
> >> > > > e.g. VFIO. Since each device is behind its own System MMU, we
> >> > > > can allocate a new IOMMU group for each device.
> >> > > >
> >> > > > This patch depends on Cho KyongHo's patch series titled "[PATCH v7
> >> > 00/12]
> >> > > > iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> >> > > > applied on a Linux 3.10.1 kernel. It has been tested on the Arndale
> >> > board.
> >> > > >
> >> > > > Signed-off-by: Antonios Motakis <a.motakis at virtualopensystems.com>
> >> > > > ---
> >> > > >  drivers/iommu/exynos-iommu.c | 24 ++++++++++++++++++++++++
> >> > > >  1 file changed, 24 insertions(+)
> >> > > >
> >> > > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-
> >> > iommu.c
> >> > > > index 51d43bb..9f39eaa 100644
> >> > > > --- a/drivers/iommu/exynos-iommu.c
> >> > > > +++ b/drivers/iommu/exynos-iommu.c
> >> > > > @@ -1134,6 +1134,28 @@ static phys_addr_t
> >> > exynos_iommu_iova_to_phys(struct
> >> > > > iommu_domain *domain,
> >> > > >       return phys;
> >> > > >  }
> >> > > >
> >> > > > +static int exynos_iommu_add_device(struct device *dev)
> >> > > > +{
> >> > > > +     struct iommu_group *group;
> >> > > > +     int ret;
> >> > > > +
> >> > > > +     group = iommu_group_alloc();
> >> > >
> >> > > Is that correct? I don't see why you allocate a group object every time
> >> > > add_device callback is called. That doesn't have any meaning we have to
> >> > use
> >> > > iommu group feature. I think the implementation should be one more
> >> > devices
> >> > > per a group. So I guess a given device object should be wrapped by
> >> > higher
> >> > > device object than the given device object. For a good example, you can
> >> > > refer to intel-iommu.c file.
> >> >
> >> > With an Intel IOMMU it can be the case that 2 devices have to share
> >> > the same IOMMU mappings (i.e. you can't program them separately). With
> >> > the Exynos System MMU, there is always one System MMU per device, so
> >> > there is nothing stopping you from programming any 2 devices' mappings
> >> > differently. So yes, the right thing to do here is to have a one to
> >> > one relationship between devices and IOMMU groups.
> >>
> >> In case of Exynos drm driver, a unified iommu mapping table is used for all
> >> devices (fimd, g2d, hdmi, fimc, gsc, rotator) based on drm so they use the
> >> same iommu mapping table even though they have each iommu hardware unit. And
> >> the iommu mapping table is just logical data structure for hardware
> >> translation process by each DMA. Actually, I am considering using iommu
> >> group feature for more generic implementation.
> >>
> >> And one question. Why do you allocate a iommu group object if we should have
> >> one to one relationship between devices and iommu groups? In this case, is
> >> there any reason you have to use the iommu group object?
> >>
> >> Thanks,
> >> Inki Dae
> >>
> > Antonios,
> >
> > Your patch always creates new iommu group whenever .add_device() is called,
> > which results in memory leak. You need to check if the given device is already
> > involved in an iommu group.
> >
> > BTW, I will post new patchset in a few days.
> > It will not be such different from previous one and your patch
> > will be rebased on that in a trivial manner.
> 
> It is not clear to me why this is the case, can add_device be called
> multiple times per device? I will take a look into this.
> 
Yes, the case you have mentioned.
Even though it must not happen with perfect device drivers,
IOMMU driver needs to care about it IMHO.

> Anyway thanks for taking this into account.
> 
> >
> > Regards,
> > Cho KyongHo
> >
> >> >
> >> > (resending because of html mail)
> >> >
> >> > Cheers,
> >> > Antonios
> >> >
> >> > >
> >> > >
> >> > > Thanks,
> >> > > Inki Dae
> >> > >
> >> > > > +     if (IS_ERR(group)) {
> >> > > > +             dev_err(dev, "Failed to allocate IOMMU group\n");
> >> > > > +             return PTR_ERR(group);
> >> > > > +     }
> >> > > > +
> >> > > > +     ret = iommu_group_add_device(group, dev);
> >> > > > +     iommu_group_put(group);
> >> > > > +
> >> > > > +     return ret;
> >> > > > +}
> >> > > > +
> >> > > > +static void exynos_iommu_remove_device(struct device *dev)
> >> > > > +{
> >> > > > +     iommu_group_remove_device(dev);
> >> > > > +}
> >> > > > +
> >> > > >  static struct iommu_ops exynos_iommu_ops = {
> >> > > >       .domain_init = &exynos_iommu_domain_init,
> >> > > >       .domain_destroy = &exynos_iommu_domain_destroy,
> >> > > > @@ -1142,6 +1164,8 @@ static struct iommu_ops exynos_iommu_ops = {
> >> > > >       .map = &exynos_iommu_map,
> >> > > >       .unmap = &exynos_iommu_unmap,
> >> > > >       .iova_to_phys = &exynos_iommu_iova_to_phys,
> >> > > > +     .add_device     = exynos_iommu_add_device,
> >> > > > +     .remove_device  = exynos_iommu_remove_device,
> >> > > >       .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
> >> > > >  };
> >> > > >
> >> > > > --
> >> > > > 1.8.1.2
> >> > > >
> >> > > > --
> >> > > > To unsubscribe from this list: send the line "unsubscribe linux-
> >> > samsung-
> >> > > > soc" in
> >> > > > the body of a message to majordomo at vger.kernel.org
> >> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> > >
> >



From mkl at pengutronix.de  Tue Jul 23 08:37:29 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Tue, 23 Jul 2013 14:37:29 +0200
Subject: [PATCH v3 27/31] net: can: mscan: add common clock support for
 mpc512x
In-Reply-To: <20130723120733.GH19071@book.gsilab.sittig.org>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
 <1374495298-22019-28-git-send-email-gsi@denx.de>
 <51ED2DF4.2090606@pengutronix.de>
 <20130723120733.GH19071@book.gsilab.sittig.org>
Message-ID: <51EE7909.6080804@pengutronix.de>

On 07/23/2013 02:07 PM, Gerhard Sittig wrote:
[...]

>>> +	return freq_calc;
>>> +
>>> +err_invalid:
>>> +	dev_err(&ofdev->dev, "invalid clock source specification\n");
>>> +	return 0;
>>
>> return 0 in case of error? Please add a comment what this 0 means here.
> 
> The .get_clock() callback is supposed to return the resulting
> rate after the clock source was determined and the clock subtree
> was setup.  It wasn't (explicitly) documented before (in the
> non-common-clock case), so I did not bother to comment it in the
> parallel common-clock case.

Yes, but returning 0 in case of error should be documented, as it's very
uncommon.

> But it's true that returning zero in the error case may be
> unexpected, and I will add a comment in v4 (in all the
> .get_clock() implementations).

I think a one liner stating that the return value is the clock rate and
"0" indicates is an invalid clock rate, this meaning an error here, is
enough.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130723/e4b5a260/attachment.sig>

From B16395 at freescale.com  Tue Jul 23 08:46:27 2013
From: B16395 at freescale.com (Sethi Varun-B16395)
Date: Tue, 23 Jul 2013 12:46:27 +0000
Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to
 an	IOMMU group
In-Reply-To: <1374573694-30595-1-git-send-email-a.motakis@virtualopensystems.com>
References: <1374573694-30595-1-git-send-email-a.motakis@virtualopensystems.com>
Message-ID: <C5ECD7A89D1DC44195F34B25E172658D0A3C0DB3@039-SN2MPN1-012.039d.mgd.msft.net>



> -----Original Message-----
> From: iommu-bounces at lists.linux-foundation.org [mailto:iommu-
> bounces at lists.linux-foundation.org] On Behalf Of Antonios Motakis
> Sent: Tuesday, July 23, 2013 3:32 PM
> To: linux-arm-kernel at lists.infradead.org; iommu at lists.linux-
> foundation.org; linux-samsung-soc at vger.kernel.org
> Cc: Sachin Kamat; Jiri Kosina; open list; Wei Yongjun; Antonios Motakis;
> Cho KyongHo; kvmarm at lists.cs.columbia.edu
> Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to
> an IOMMU group
> 
> IOMMU groups are expected by certain users of the IOMMU API, e.g. VFIO.
> Since each device is behind its own System MMU, we can allocate a new
> IOMMU group for each device.
> 
> This patch depends on Cho KyongHo's patch series titled "[PATCH v7 00/12]
> iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> applied on a Linux 3.10.1 kernel. It has been tested on the Arndale
> board.
> 
> Signed-off-by: Antonios Motakis <a.motakis at virtualopensystems.com>
> ---
>  drivers/iommu/exynos-iommu.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 51d43bb..9f39eaa 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1134,6 +1134,28 @@ static phys_addr_t
> exynos_iommu_iova_to_phys(struct iommu_domain *domain,
>  	return phys;
>  }
> 
> +static int exynos_iommu_add_device(struct device *dev) {
> +	struct iommu_group *group;
> +	int ret;
> +
> +	group = iommu_group_alloc();
> +	if (IS_ERR(group)) {
> +		dev_err(dev, "Failed to allocate IOMMU group\n");
> +		return PTR_ERR(group);
> +	}
> +
> +	ret = iommu_group_add_device(group, dev);
> +	iommu_group_put(group);
> +
> +	return ret;
> +}
> +
> +static void exynos_iommu_remove_device(struct device *dev) {
> +	iommu_group_remove_device(dev);
> +}
> +
>  static struct iommu_ops exynos_iommu_ops = {
>  	.domain_init = &exynos_iommu_domain_init,
>  	.domain_destroy = &exynos_iommu_domain_destroy, @@ -1142,6 +1164,8
> @@ static struct iommu_ops exynos_iommu_ops = {
>  	.map = &exynos_iommu_map,
>  	.unmap = &exynos_iommu_unmap,
>  	.iova_to_phys = &exynos_iommu_iova_to_phys,
> +	.add_device	= exynos_iommu_add_device,
> +	.remove_device	= exynos_iommu_remove_device,
>  	.pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,  };
> 
[Sethi Varun-B16395] Do you support PCI devices? This assumption of one iommu group per pci device may not hold true in case of PCI devices.

-Varun



From inki.dae at samsung.com  Tue Jul 23 08:59:54 2013
From: inki.dae at samsung.com (Inki Dae)
Date: Tue, 23 Jul 2013 21:59:54 +0900
Subject: [PATCH] iommu/exynos: add devices attached to the System MMU to an
 IOMMU group
In-Reply-To: <CAG8rG2xJ4z9cwrMtLhOrPKnw+fdL_H4doDPARNfvLj+JHTjByQ@mail.gmail.com>
References: <1374573694-30595-1-git-send-email-a.motakis@virtualopensystems.com>
 <00d701ce878f$da099fe0$8e1cdfa0$%dae@samsung.com>
 <CAG8rG2wNG9wVjKxtaDzLRybvh3wPVR08j9G9OPcK=a2Gwbtg-g@mail.gmail.com>
 <00e601ce8796$bdca50c0$395ef240$%dae@samsung.com>
 <CAG8rG2xJ4z9cwrMtLhOrPKnw+fdL_H4doDPARNfvLj+JHTjByQ@mail.gmail.com>
Message-ID: <00ef01ce87a4$870d86c0$95289440$%dae@samsung.com>



> -----Original Message-----
> From: Antonios Motakis [mailto:a.motakis at virtualopensystems.com]
> Sent: Tuesday, July 23, 2013 9:05 PM
> To: Inki Dae
> Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
KyongHo;
> Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list; Alex
> Williamson
> Subject: Re: [PATCH] iommu/exynos: add devices attached to the System MMU
> to an IOMMU group
> 
> On Tue, Jul 23, 2013 at 1:21 PM, Inki Dae <inki.dae at samsung.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Antonios Motakis [mailto:a.motakis at virtualopensystems.com]
> >> Sent: Tuesday, July 23, 2013 8:00 PM
> >> To: Inki Dae
> >> Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
> > KyongHo;
> >> Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> >> Subject: Re: [PATCH] iommu/exynos: add devices attached to the System
> MMU
> >> to an IOMMU group
> >>
> >> On Tue, Jul 23, 2013 at 12:31 PM, Inki Dae <inki.dae at samsung.com>
wrote:
> >> >
> >> >
> >> >
> >> > > -----Original Message-----
> >> > > From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-
> samsung-
> >> soc-
> >> > > owner at vger.kernel.org] On Behalf Of Antonios Motakis
> >> > > Sent: Tuesday, July 23, 2013 7:02 PM
> >> > > To: linux-arm-kernel at lists.infradead.org;
> >> > iommu at lists.linux-foundation.org;
> >> > > linux-samsung-soc at vger.kernel.org
> >> > > Cc: kvmarm at lists.cs.columbia.edu; Antonios Motakis; Cho KyongHo;
> Joerg
> >> > > Roedel; Sachin Kamat; Jiri Kosina; Wei Yongjun; open list
> >> > > Subject: [PATCH] iommu/exynos: add devices attached to the System
> MMU
> >> to
> >> > > an IOMMU group
> >> > >
> >> > > IOMMU groups are expected by certain users of the IOMMU API,
> >> > > e.g. VFIO. Since each device is behind its own System MMU, we
> >> > > can allocate a new IOMMU group for each device.
> >> > >
> >> > > This patch depends on Cho KyongHo's patch series titled "[PATCH v7
> >> 00/12]
> >> > > iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> >> > > applied on a Linux 3.10.1 kernel. It has been tested on the Arndale
> >> board.
> >> > >
> >> > > Signed-off-by: Antonios Motakis <a.motakis at virtualopensystems.com>
> >> > > ---
> >> > >  drivers/iommu/exynos-iommu.c | 24 ++++++++++++++++++++++++
> >> > >  1 file changed, 24 insertions(+)
> >> > >
> >> > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-
> >> iommu.c
> >> > > index 51d43bb..9f39eaa 100644
> >> > > --- a/drivers/iommu/exynos-iommu.c
> >> > > +++ b/drivers/iommu/exynos-iommu.c
> >> > > @@ -1134,6 +1134,28 @@ static phys_addr_t
> >> exynos_iommu_iova_to_phys(struct
> >> > > iommu_domain *domain,
> >> > >       return phys;
> >> > >  }
> >> > >
> >> > > +static int exynos_iommu_add_device(struct device *dev)
> >> > > +{
> >> > > +     struct iommu_group *group;
> >> > > +     int ret;
> >> > > +
> >> > > +     group = iommu_group_alloc();
> >> >
> >> > Is that correct? I don't see why you allocate a group object every
> time
> >> > add_device callback is called. That doesn't have any meaning we have
> to
> >> use
> >> > iommu group feature. I think the implementation should be one more
> >> devices
> >> > per a group. So I guess a given device object should be wrapped by
> >> higher
> >> > device object than the given device object. For a good example, you
> can
> >> > refer to intel-iommu.c file.
> >>
> >> With an Intel IOMMU it can be the case that 2 devices have to share
> >> the same IOMMU mappings (i.e. you can't program them separately). With
> >> the Exynos System MMU, there is always one System MMU per device, so
> >> there is nothing stopping you from programming any 2 devices' mappings
> >> differently. So yes, the right thing to do here is to have a one to
> >> one relationship between devices and IOMMU groups.
> >
> > In case of Exynos drm driver, a unified iommu mapping table is used for
> all
> > devices (fimd, g2d, hdmi, fimc, gsc, rotator) based on drm so they use
> the
> > same iommu mapping table even though they have each iommu hardware unit.
> And
> > the iommu mapping table is just logical data structure for hardware
> > translation process by each DMA. Actually, I am considering using iommu
> > group feature for more generic implementation.
> 
> But is this grouping imposed by the hardware in some way, or is it
> just the way you handle them in software? In the latter case, then
> what you are looking for are IOMMU domains (which can contain multiple
> groups). IOMMU groups describe something that is imposed by the
> hardware.
> 

That's true. That seems like out of my intention that we try to use the
iommu group feature.

> >
> > And one question. Why do you allocate a iommu group object if we should
> have
> > one to one relationship between devices and iommu groups? In this case,
> is
> > there any reason you have to use the iommu group object?
> 
> Generic IOMMU code (such as VFIO) will check for IOMMU groups to
> determine how the devices behind an IOMMU relate to each other.
> Returning a unique IOMMU group object per device provides this
> information - that each device can also be programmed separately. VFIO
> relies on this behavior - if it doesn't find any IOMMU group objects
> it will refuse to use the device.
> 
> Additionally, this information can be seen by userspace. Being able to
> programmatically determine that there is a one to one relationship is
> certainly useful.
> 

I have read VFIO document file just now. The VFIO framework is similar to
UIO that is used to write user space device driver. But the VFIO is more
secure, and provides more featureful userspace driver environment than UIO.
And the VFIO requires iommu group object. I didn't check this. Sorry about
that.

Thanks,
Inki Dae

> I don't think the lack of IOMMU groups implies no grouping - I think
> it implies unknown grouping or an incomplete driver, so in my opinion
> VFIO is correct in refusing to work without IOMMU groups. So any
> future ARM support for VFIO, will also rely on IOMMU groups.
> 
> >
> > Thanks,
> > Inki Dae
> >
> >>
> >> (resending because of html mail)
> >>
> >> Cheers,
> >> Antonios
> >>
> >> >
> >> >
> >> > Thanks,
> >> > Inki Dae
> >> >
> >> > > +     if (IS_ERR(group)) {
> >> > > +             dev_err(dev, "Failed to allocate IOMMU group\n");
> >> > > +             return PTR_ERR(group);
> >> > > +     }
> >> > > +
> >> > > +     ret = iommu_group_add_device(group, dev);
> >> > > +     iommu_group_put(group);
> >> > > +
> >> > > +     return ret;
> >> > > +}
> >> > > +
> >> > > +static void exynos_iommu_remove_device(struct device *dev)
> >> > > +{
> >> > > +     iommu_group_remove_device(dev);
> >> > > +}
> >> > > +
> >> > >  static struct iommu_ops exynos_iommu_ops = {
> >> > >       .domain_init = &exynos_iommu_domain_init,
> >> > >       .domain_destroy = &exynos_iommu_domain_destroy,
> >> > > @@ -1142,6 +1164,8 @@ static struct iommu_ops exynos_iommu_ops = {
> >> > >       .map = &exynos_iommu_map,
> >> > >       .unmap = &exynos_iommu_unmap,
> >> > >       .iova_to_phys = &exynos_iommu_iova_to_phys,
> >> > > +     .add_device     = exynos_iommu_add_device,
> >> > > +     .remove_device  = exynos_iommu_remove_device,
> >> > >       .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
> >> > >  };
> >> > >
> >> > > --
> >> > > 1.8.1.2
> >> > >
> >> > > --
> >> > > To unsubscribe from this list: send the line "unsubscribe linux-
> >> samsung-
> >> > > soc" in
> >> > > the body of a message to majordomo at vger.kernel.org
> >> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> >
> >



From catalin.marinas at arm.com  Tue Jul 23 09:08:37 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Jul 2013 14:08:37 +0100
Subject: [PATCH v2] ARM: Do not run dummy_flush_tlb_a15_erratum() on
 non-Cortex-A15
In-Reply-To: <1374581199-8277-1-git-send-email-festevam@gmail.com>
References: <1374581199-8277-1-git-send-email-festevam@gmail.com>
Message-ID: <20130723130837.GA4654@MacBook-Pro.local>

On Tue, Jul 23, 2013 at 01:06:39PM +0100, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Commit 93dc688 (ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 
> (TLBI/DSB operations)) causes the following undefined instruction error on a
> mx53 (Cortex-A8):
> 
> Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> CPU: 0 PID: 275 Comm: modprobe Not tainted 3.11.0-rc2-next-20130722-00009-g9b0f371 #881
> task: df46cc00 ti: df48e000 task.ti: df48e000
> PC is at check_and_switch_context+0x17c/0x4d0
> LR is at check_and_switch_context+0xdc/0x4d0
> 
> This problem happens because check_and_switch_context() calls 
> dummy_flush_tlb_a15_erratum() without checking if we are really running on a 
> Cortex-A15 or not. 
> 
> To avoid this issue, only call dummy_flush_tlb_a15_erratum() inside 
> check_and_switch_context() if erratum_a15_798181() returns true, which means
> that we are really running on a Cortex-A15.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From robherring2 at gmail.com  Tue Jul 23 09:13:39 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 23 Jul 2013 08:13:39 -0500
Subject: [PATCH] arm: l2x0: add support for prefetch and pwr control
 register configuration
In-Reply-To: <20130723102212.GD4833@e106331-lin.cambridge.arm.com>
References: <1374572345-5763-1-git-send-email-chander.kashyap@linaro.org>
 <20130723102212.GD4833@e106331-lin.cambridge.arm.com>
Message-ID: <51EE8183.9010703@gmail.com>

On 07/23/2013 05:22 AM, Mark Rutland wrote:
> Hi,
> 
> [adding Rob Herring to Cc]

Thanks.

> On Tue, Jul 23, 2013 at 10:39:05AM +0100, Chander Kashyap wrote:
>> This patch adds support to configure prefetch and pwr control registers
>> of pl310 cache controllor.
>>
>> Signed-off-by: Chander Kashyap <chander.kashyap at linaro.org>
>> ---
>>  Documentation/devicetree/bindings/arm/l2cc.txt |    6 ++++
>>  arch/arm/include/asm/hardware/cache-l2x0.h     |   23 +++++++++++++
>>  arch/arm/mm/cache-l2x0.c                       |   44 ++++++++++++++++++++++++
>>  3 files changed, 73 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
>> index cbef09b..66876b6 100644
>> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
>> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
>> @@ -34,6 +34,12 @@ Optional properties:
>>  - arm,filter-ranges : <start length> Starting address and length of window to
>>    filter. Addresses in the filter window are directed to the M1 port. Other
>>    addresses will go to the M0 port.
>> +- arm,prefetch-control : Prefetch related configurations. Specifies 8 cells of
>> +  prefetch-offset, not-same-ID-on-exclusive-sequence-en, incr-double-Linefill-en,
>> +  prefetch-drop-en, data-prefetch-en, instruction-prefetch-en and
>> +  double-linefill-en.
> 
> This looks like configuration rather than hardware specification. 

I think weigh whether this is configuration based on the h/w or just
user preference. This would be the former, but...

> Is there any reason we couldn't have Linux configure this itself? I'm
> not sure having a fixed configuration of these values makes sense - the
> configuration values could interact badly with future changes to Linux
> (e.g. performance improvements or errata workarounds), and then we'd
> have to ignore the described values and/or decide on more suitable ones
> dynamically anyway.

Does having a variable configuration for these make sense either? I mean
other than an errata work-around, why would you ever turn off prefetch
or double linefill?

None of these fields can be set in NS world. We've already laid down the
law in regards to setting secure only bits for errata work-arounds. I
think this is no different and we should move towards the kernel doesn't
touch aux ctrl at all. There might be an exception with the event bus
enable, but you would still have the secure vs. non-secure issue and no
way to detect that.

Rob

> 
> I assume that these cells are meant to either be zero or one? If they're
> necessary, they should be separate boolean properties rather than
> grouped together by the register they're configured by (see the way
> arm,tag-latency and arm,data-latency are handled). 
> 
> Also, I'd prefer "-enable" to "-en".
> 
>> +- arm,pwr-control : Operting mode clock and power mode selection. Specifies two
> 
> s/Operting/Operating/
> 
> I'd prefer "power" to "pwr" (though there's precedent for both in
> bindings...).
> 
>> +  cells of standby-mode-en and dynamic_clk_gating_en.
> 
> More boolean properties.
> 
>>  - interrupts : 1 combined interrupt.
>>  - cache-id-part: cache id part number to be used if it is not present
>>    on hardware
> 
> No amendments to the example?
> 
>> diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
>> index 3b2c40b..188f4da 100644
>> --- a/arch/arm/include/asm/hardware/cache-l2x0.h
>> +++ b/arch/arm/include/asm/hardware/cache-l2x0.h
>> @@ -106,6 +106,29 @@
>>  
>>  #define L2X0_WAY_SIZE_SHIFT		3
>>  
>> +#define L2X0_PREFETCH_CTRL_OFFSET_SHIFT			0
>> +#define L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT		21
>> +#define L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT	23
>> +#define L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT		24
>> +#define L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT	27
>> +#define L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT	28
>> +#define L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT	29
>> +#define L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT	30
>> +
>> +#define PREFETCH_R2P0_MASK	(~(1 << L2X0_PREFETCH_CTRL_OFFSET_SHIFT))
>> +#define PREFETCH_R3P0_MASK \
>> +		(~((1 << L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT) | \
>> +		   (1 << L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT) | \
>> +		   (1 << L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT) | \
>> +		   (1 << L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT) | \
>> +		   (1 << L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT) | \
>> +		   (1 << L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT)))
>> +#define PREFETCH_R3P1_MASK \
>> +		(~(1 << L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT))
>> +
>> +#define L2X0_PWR_CTRL_STANDBY_MODE_EN_SHIFT	0
>> +#define L2X0_PWR_CTRL_DYNAMIC_CLK_GATE_EN_SHIFT	1
>> +
>>  #ifndef __ASSEMBLY__
>>  extern void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask);
>>  #if defined(CONFIG_CACHE_L2X0) && defined(CONFIG_OF)
>> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
>> index c465fac..490e182 100644
>> --- a/arch/arm/mm/cache-l2x0.c
>> +++ b/arch/arm/mm/cache-l2x0.c
>> @@ -563,6 +563,11 @@ static void __init pl310_of_setup(const struct device_node *np,
>>  	u32 data[3] = { 0, 0, 0 };
>>  	u32 tag[3] = { 0, 0, 0 };
>>  	u32 filter[2] = { 0, 0 };
>> +	u32 prefetch[8] = { 0, 0, 0, 0, 0, 0, 0, 0 };
>> +	u32 prefetch_val;
>> +	u32 pwr[2] = { 0, 0 };
>> +	u32 l2x0_revision = readl_relaxed(l2x0_base + L2X0_CACHE_ID) &
>> +		L2X0_CACHE_ID_RTL_MASK;
>>  
>>  	of_property_read_u32_array(np, "arm,tag-latency", tag, ARRAY_SIZE(tag));
>>  	if (tag[0] && tag[1] && tag[2])
>> @@ -589,6 +594,45 @@ static void __init pl310_of_setup(const struct device_node *np,
>>  		writel_relaxed((filter[0] & ~(SZ_1M - 1)) | L2X0_ADDR_FILTER_EN,
>>  			       l2x0_base + L2X0_ADDR_FILTER_START);
>>  	}
>> +
>> +	if (l2x0_revision >= L2X0_CACHE_ID_RTL_R2P0) {
> 
> You didn't describe that some properties were dependent on a particular
> revision.
> 
>> +		of_property_read_u32_array(np, "arm,prefetch-control",
>> +						prefetch, ARRAY_SIZE(prefetch));
>> +		prefetch_val = readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
>> +		prefetch_val &= PREFETCH_R2P0_MASK;
>> +		prefetch_val |= prefetch[0] << L2X0_PREFETCH_CTRL_OFFSET_SHIFT;
>> +		if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P0) {
>> +			prefetch_val &= PREFETCH_R3P0_MASK;
>> +			prefetch_val |=
>> +			 ((prefetch[1]) <<
>> +			   L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT) |
>> +			 ((prefetch[2]) <<
>> +			   L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT) |
>> +			 ((prefetch[3]) <<
>> +			   L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT) |
>> +			 ((prefetch[5]) <<
>> +			   L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT) |
>> +			 ((prefetch[6]) <<
>> +			   L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT) |
>> +			 ((prefetch[7]) <<
>> +			   L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT);
> 
> You've not sanity checked these properties. What If I typo a value as
> something other than 0 or 1?
> 
> Use boolean properties and of_property_read_bool (or even better,
> configure this dynamically based on revision rather than having a dt
> description).
> 
>> +			if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P1) {
>> +				prefetch_val &= PREFETCH_R3P1_MASK;
>> +				prefetch_val |=
>> +				 ((prefetch[4]) <<
>> +				   L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT);
>> +			}
> 
> Another undocumented revision dependency.
> 
>> +			writel_relaxed(prefetch_val,
>> +					l2x0_base + L2X0_PREFETCH_CTRL);
>> +
>> +			of_property_read_u32_array(np, "arm,pwr-control",
>> +						pwr, ARRAY_SIZE(pwr));
>> +			writel_relaxed(
>> +			 ((pwr[0]) << L2X0_PWR_CTRL_STANDBY_MODE_EN_SHIFT) |
>> +			 ((pwr[1]) << L2X0_PWR_CTRL_DYNAMIC_CLK_GATE_EN_SHIFT),
>> +			   l2x0_base + L2X0_POWER_CTRL);
> 
> Again, use boolean properties or do this dynamically.
> 
> Do none of these values need to be saved for the resume callback?
> 
> Thanks,
> Mark.
> 
>> +		}
>> +	}
>>  }
>>  
>>  static void __init pl310_save(void)
>> -- 
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>



From gsi at denx.de  Tue Jul 23 09:14:06 2013
From: gsi at denx.de (Gerhard Sittig)
Date: Tue, 23 Jul 2013 15:14:06 +0200
Subject: [PATCH v3 17/31] clk: mpc512x: introduce COMMON_CLK for MPC512x
In-Reply-To: <1374495298-22019-18-git-send-email-gsi@denx.de>
References: <1374166855-7280-1-git-send-email-gsi@denx.de>
 <1374495298-22019-1-git-send-email-gsi@denx.de>
 <1374495298-22019-18-git-send-email-gsi@denx.de>
Message-ID: <20130723131406.GI19071@book.gsilab.sittig.org>

[ summary: "shared gate" support desirable? approach acceptable? ]

On Mon, Jul 22, 2013 at 14:14 +0200, Gerhard Sittig wrote:
> 
> this change implements a clock driver for the MPC512x PowerPC platform
> which follows the COMMON_CLK approach and uses common clock drivers
> shared with other platforms
> 
> [ ... ]
> 
> some of the clock items get pre-enabled in the clock driver to not have
> them automatically disabled by the underlying clock subsystem because of
> their being unused -- this approach is desirable because
> [ ... ]
> - some help introduce support for and migrate to the common
>   infrastructure, while more appropriate support for specific hardware
>   constraints isn't available yet (remaining changes are strictly
>   internal to the clock driver and won't affect peripheral drivers)

This remark was related to the CAN clocks of the MPC512x SoC.

The clock subtrees which are involved in generating CAN bitrates
include one path from the XTAL to an internal MCLK (this is part
of the CCF support for the platform), and another path from the
MCLK or yet another IP bus clock to the actual bitrate on the
wire (this is taken care of within the mscan(4) driver).

The MCLK generation for CAN is documented in the MPC5121e
Reference Manual, chapter 5, section 5.2.5 "MSCAN Clock
Generation".  SYS, REF (both internal), PSC_MCLK_IN, and SPDIF_TX
(both external) are muxed, gated, and divided.  The result is
muxed with IP.  The result is fed into the MSCAN component and
gets muxed with IP again (can't tell why, maybe for backwards
compatibility).

In parallel to this MCLK block there is SCCR2[25], the "BDLC and
MSCAN clock enable", documented in section 5.3.1.3 "System Clock
Control Register 2".  So there is a gate that "somehow needs to
get setup" yet isn't part of the visible MCLK chain.

The series up to and including v3 approaches the problem by
- adding a gate after the second MCLK mux, which gets exported
  for client lookups and is the MCLK input for the mscan(4)
  driver
- creating that gate for each of the four MSCAN clocks of the
  SoC, all of them referencing the single "enable" bit in the
  SCCR2 register
- pre-enabling the MSCAN clocks from within the clock driver, and
  thus avoid having the clock disabled from the common
  infrastructure, because disabling one of these clocks had
  closed the shared gate and thus had broken all other clock uses

> clkdev registration provides "alias names" for few clock items
> [ ... ]
> 
[ ... ]
> +
> +/* setup the MCLK clock subtree of an individual PSC/MSCAN/SPDIF */
> +static void mpc512x_clk_setup_mclk(struct mclk_setup_data *entry)
> +{
> +	size_t clks_idx_pub, clks_idx_int;
> +	u32 __iomem *mccr_reg;	/* MCLK control register (mux, en, div) */
> +	u32 __iomem *sccr_reg;	/* system clock control register (enable) */
> +	int sccr_bit;
> +	int div;
> +
> +	/* derive a few parameters from the component type and index */
> +	switch (entry->type) {
> +	case MCLK_TYPE_PSC:
> +		clks_idx_pub = MPC512x_CLK_PSC0_MCLK + entry->comp_idx;
> +		clks_idx_int = MPC512x_CLK_MCLKS_FIRST
> +			     + (entry->comp_idx) * MCLK_MAX_IDX;
> +		mccr_reg = &clkregs->psc_ccr[entry->comp_idx];
> +		break;
> +	case MCLK_TYPE_MSCAN:
> +		clks_idx_pub = MPC512x_CLK_MSCAN0_MCLK + entry->comp_idx;
> +		clks_idx_int = MPC512x_CLK_MCLKS_FIRST
> +			     + (NR_PSCS + entry->comp_idx) * MCLK_MAX_IDX;
> +		mccr_reg = &clkregs->mscan_ccr[entry->comp_idx];
> +		break;
> +	case MCLK_TYPE_SPDIF:
> +		clks_idx_pub = MPC512x_CLK_SPDIF_MCLK;
> +		clks_idx_int = MPC512x_CLK_MCLKS_FIRST
> +			     + (NR_PSCS + NR_MSCANS) * MCLK_MAX_IDX;
> +		mccr_reg = &clkregs->spccr;
> +		break;
> +	default:
> +		return;
> +	}
> +	if (entry->bit_sccr1 >= 0) {
> +		sccr_reg = &clkregs->sccr1;
> +		sccr_bit = entry->bit_sccr1;
> +	} else if (entry->bit_sccr2 >= 0) {
> +		sccr_reg = &clkregs->sccr2;
> +		sccr_bit = entry->bit_sccr2;
> +	} else {
> +		sccr_reg = NULL;
> +	}
> +
> +	/*
> +	 * this was grabbed from the PPC_CLOCK implementation, which
> +	 * enforced a specific MCLK divider while the clock was gated
> +	 * during setup (that's a documented hardware requirement)
> +	 *
> +	 * the PPC_CLOCK implementation might even have violated the
> +	 * "MCLK <= IPS" constraint, the fixed divider value of 1
> +	 * results in a divider of 2 and thus MCLK = SYS/2 which equals
> +	 * CSB which is greater than IPS; the serial port setup may have
> +	 * adjusted the divider which the clock setup might have left in
> +	 * an undesirable state
> +	 *
> +	 * initial setup is:
> +	 * - MCLK 0 from SYS
> +	 * - MCLK DIV such to not exceed the IPS clock
> +	 * - MCLK 0 enabled
> +	 * - MCLK 1 from MCLK DIV
> +	 */
> +	div = clk_get_rate(clks[MPC512x_CLK_SYS]);
> +	div /= clk_get_rate(clks[MPC512x_CLK_IPS]);
> +	out_be32(mccr_reg, (0 << 16));
> +	out_be32(mccr_reg, (0 << 16) | ((div - 1) << 17));
> +	out_be32(mccr_reg, (1 << 16) | ((div - 1) << 17));
> +
> +	/*
> +	 * create the 'struct clk' items of the MCLK's clock subtree
> +	 *
> +	 * note that by design we always create all nodes and won't take
> +	 * shortcuts here, because
> +	 * - the "internal" MCLK_DIV and MCLK_OUT signal in turn are
> +	 *   selectable inputs to the CFM while those who "actually use"
> +	 *   the PSC/MSCAN/SPDIF (serial drivers et al) need the MCLK
> +	 *   for their bitrate
> +	 * - in the absence of "aliases" for clocks we need to create
> +	 *   individial 'struct clk' items for whatever might get
> +	 *   referenced or looked up, even if several of those items are
> +	 *   identical from the logical POV (their rate value)
> +	 * - for easier future maintenance and for better reflection of
> +	 *   the SoC's documentation, it appears appropriate to generate
> +	 *   clock items even for those muxers which actually are NOPs
> +	 *   (those with two inputs of which one is reserved)
> +	 */
> +	clks[clks_idx_int + MCLK_IDX_MUX0] = mpc512x_clk_muxed(
> +			entry->name_mux0,
> +			&parent_names_mux0[0], ARRAY_SIZE(parent_names_mux0),
> +			mccr_reg, 14, 2);
> +	clks[clks_idx_int + MCLK_IDX_EN0] = mpc512x_clk_gated(
> +			entry->name_en0, entry->name_mux0,
> +			mccr_reg, 16);
> +	clks[clks_idx_int + MCLK_IDX_DIV0] = mpc512x_clk_divider(
> +			entry->name_div0,
> +			entry->name_en0, CLK_SET_RATE_GATE,
> +			mccr_reg, 17, 15, 0);
> +	if (entry->has_mclk1) {
> +		clks[clks_idx_int + MCLK_IDX_MUX1] = mpc512x_clk_muxed(
> +				entry->name_mux1,
> +				&entry->parent_names_mux1[0],
> +				ARRAY_SIZE(entry->parent_names_mux1),
> +				mccr_reg, 7, 1);
> +	} else {
> +		clks[clks_idx_int + MCLK_IDX_MUX1] = mpc512x_clk_factor(
> +				entry->name_mux1, entry->parent_names_mux1[0],
> +				1, 1);
> +	}
> +	if (sccr_reg) {
> +		clks[clks_idx_pub] = mpc512x_clk_gated(
> +				entry->name_mclk,
> +				entry->name_mux1, sccr_reg, sccr_bit);
> +	} else {
> +		clks[clks_idx_pub] = mpc512x_clk_factor(
> +				entry->name_mclk,
> +				entry->name_mux1, 1, 1);
> +	}
> +
> +	/*
> +	 * without this "clock device" registration, "simple" lookups in
> +	 * the SPI master initialization and serial port setup will fail
> +	 *
> +	 * those drivers need to get adjusted to lookup their required
> +	 * clocks from device tree specs, and device tree nodes need to
> +	 * provide the clock specs, before this clkdev registration
> +	 * becomes obsolete
> +	 */
> +	clk_register_clkdev(clks[clks_idx_pub], entry->name_mclk, NULL);
> +}
> [ ... ]

This was the routine which sets up _one_ MCLK block, note the
assignment at the routine's end to the "published" clock item
that's the gate's output after the second mux stage.

> [ ... ]
> +	clks[MPC512x_CLK_I2C] = mpc512x_clk_gated("i2c", "ips",
> +						  &clkregs->sccr2, 26);
> +	mpc512x_clk_setup_mclks(mclk_mscan_data, ARRAY_SIZE(mclk_mscan_data));
> +	clks[MPC512x_CLK_SDHC] = mpc512x_clk_gated("sdhc", "sdhc-ug",
> +						   &clkregs->sccr2, 24);
> +	mpc512x_clk_setup_mclks(mclk_spdif_data, ARRAY_SIZE(mclk_spdif_data));
> [ ... ]

This is the invocation of the routine which sets up four MCLK
blocks for the MSCAN components, while all of them refer to bit
25 of SCCR2.

> [ ... ]
> +
> +	/* enable some of the clocks here unconditionally because ... */
> +	pr_debug("automatically enabling some clocks\n");
> +	/* some are essential yet never get claimed by any driver */
> +	clk_prepare_enable(clks[MPC512x_CLK_DUMMY]);
> +	clk_prepare_enable(clks[MPC512x_CLK_E300]);	/* PowerPC CPU */
> +	clk_prepare_enable(clks[MPC512x_CLK_DDR]);	/* DRAM */
> +	clk_prepare_enable(clks[MPC512x_CLK_MEM]);	/* SRAM */
> +	clk_prepare_enable(clks[MPC512x_CLK_IPS]);	/* SoC periph */
> +	clk_prepare_enable(clks[MPC512x_CLK_LPC]);	/* boot media */
> +	/* some are required yet no dependencies were declared */
> +	clk_prepare_enable(clks[MPC512x_CLK_PSC_FIFO]);
> +	/* some are not yet acquired by their respective drivers */
> +	clk_prepare_enable(clks[MPC512x_CLK_PSC3_MCLK]);/* serial console */
> +	clk_prepare_enable(clks[MPC512x_CLK_FEC]);	/* network, NFS */
> +	clk_prepare_enable(clks[MPC512x_CLK_DIU]);	/* display */
> +	clk_prepare_enable(clks[MPC512x_CLK_I2C]);
> +	/*
> +	 * some have their individual clock subtree with separate clock
> +	 * items and their individual enable counters, yet share a
> +	 * common gate (refer to the same register location) while the
> +	 * common clock driver code is not aware of the fact and the
> +	 * platform's code doesn't provide specific support either
> +	 *
> +	 * what might happen is that e.g. enabling two MSCAN clock items
> +	 * and disabling one of them will disable the common gate and
> +	 * thus break the other MSCAN clock as well
> +	 */
> +	clk_prepare_enable(clks[MPC512x_CLK_MSCAN0_MCLK]);
> +	clk_prepare_enable(clks[MPC512x_CLK_MSCAN1_MCLK]);
> +	clk_prepare_enable(clks[MPC512x_CLK_MSCAN2_MCLK]);
> +	clk_prepare_enable(clks[MPC512x_CLK_MSCAN3_MCLK]);
> +}

This is the pre-enable workaround for the MSCAN0 to MSCAN3 clock
items.

The above approach does work in that it introduces complete
support for common clock on the MPC512x platform, with the CAN
component being operational, and the clock driver using shared
logic across platforms.

The remaining issue is that regardless of whether CAN is used,
the (chip internal) clock is enabled.  This may not be a problem
when bitrates aren't generated and the wire isn't driven.


The question now is how to correctly support the situation where
a gate is shared between subtrees yet isn't really part of any
path within the subtrees.  I really cannot find a single spot
where to introduce the gate such that it's not duplicated.

The appropriate solution would not be to pre-enable those clocks,
but to either introduce another gate clock type which supports a
shared reference, or to add support for the shared reference to
the existing gate code.


I'd rather not duplicate most or all of the code of clk-gate.c,
instead I looked into how to add "shared gate" support to the
existing driver.

My question is whether the approach is acceptable.  It adds
minimal overhead and shall be OK for the enable/disable path from
a technical POV.  And it doesn't feel like too much of a stretch.
But there may be non-technical reasons to reject the approach.
I'd like to learn whether to follow that path before preparing
another version of the patch series.

The diffs were taken with the '-w -b' options to demonstrate
their essence and not drown it in whitespace changes.  The
implementation assumes that the caller which registers the gate
(the platform's clock driver) provides both the counter cell and
the lock.  And that all gates with a "shared use counter" use the
same lock (which is satisfied as they all get registered from the
same spot in the platform's clock driver).

The CLK_IGNORE_UNUSED flag addresses a different problem.  The
SoC has four MSCAN components, while two of them are enabled in
the device tree (the other two are present but disabled).  So
during probe two of the clocks get enabled.  After probe all
unused clocks automatically get disabled (that's another two).
So the "shared use counter" drops to zero although components are
in use, because "disable, it's unused" isn't told from "disable
after enable, regular use".  The flag would become obsolete if
the common gate logic would implement a separate disable_unused()
routine, but I guess this isn't necessary and the use of the flag
is appropriate.

That the example use creates a field for just one counter is to
better demonstrate the use and potential extension as need
arises.  Reducing this to a mere integer variable would be a
micro optimization.


The extension of the existing clk_gate implementation:

--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -46,6 +46,7 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable)
 	struct clk_gate *gate = to_clk_gate(hw);
 	int set = gate->flags & CLK_GATE_SET_TO_DISABLE ? 1 : 0;
 	unsigned long flags = 0;
+	int need_reg_access;
 	u32 reg;
 
 	set ^= enable;
@@ -53,6 +54,20 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable)
 	if (gate->lock)
 		spin_lock_irqsave(gate->lock, flags);
 
+	/*
+	 * if a "shared use counter" was specified, keep track of enable
+	 * and disable calls and only access hardware registers upon the
+	 * very first enable or very last disable call
+	 */
+	if (!gate->share_count) {
+		need_reg_access = 1;
+	} else if (enable) {
+		need_reg_access = (*gate->share_count)++ == 0;
+	} else {
+		need_reg_access = --(*gate->share_count) == 0;
+	}
+
+	if (need_reg_access) {
 		if (gate->flags & CLK_GATE_HIWORD_MASK) {
 			reg = BIT(gate->bit_idx + 16);
 			if (set)
@@ -67,6 +82,7 @@ static void clk_gate_endisable(struct clk_hw *hw, int enable)
 		}
 
 		clk_writel(reg, gate->reg);
+	}
 
 	if (gate->lock)
 		spin_unlock_irqrestore(gate->lock, flags);
@@ -118,10 +134,11 @@ EXPORT_SYMBOL_GPL(clk_gate_ops);
  * @clk_gate_flags: gate-specific flags for this clock
  * @lock: shared register lock for this clock
  */
-struct clk *clk_register_gate(struct device *dev, const char *name,
+struct clk *clk_register_gate_shared(struct device *dev, const char *name,
 		const char *parent_name, unsigned long flags,
 		void __iomem *reg, u8 bit_idx,
-		u8 clk_gate_flags, spinlock_t *lock)
+		u8 clk_gate_flags, spinlock_t *lock,
+		int *share_count)
 {
 	struct clk_gate *gate;
 	struct clk *clk;
@@ -152,6 +169,7 @@ struct clk *clk_register_gate(struct device *dev, const char *name,
 	gate->bit_idx = bit_idx;
 	gate->flags = clk_gate_flags;
 	gate->lock = lock;
+	gate->share_count = share_count;
 	gate->hw.init = &init;
 
 	clk = clk_register(dev, &gate->hw);
@@ -161,3 +179,14 @@ struct clk *clk_register_gate(struct device *dev, const char *name,
 
 	return clk;
 }
+
+struct clk *clk_register_gate(struct device *dev, const char *name,
+		const char *parent_name, unsigned long flags,
+		void __iomem *reg, u8 bit_idx,
+		u8 clk_gate_flags, spinlock_t *lock)
+{
+
+	return clk_register_gate_shared(dev, name, parent_name, flags,
+					reg, bit_idx, clk_gate_flags,
+					lock, NULL);
+}
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -222,6 +222,7 @@ struct clk_gate {
 	u8		bit_idx;
 	u8		flags;
 	spinlock_t	*lock;
+	int		*share_count;
 };
 
 #define CLK_GATE_SET_TO_DISABLE		BIT(0)
@@ -232,6 +233,11 @@ struct clk *clk_register_gate(struct device *dev, const char *name,
 		const char *parent_name, unsigned long flags,
 		void __iomem *reg, u8 bit_idx,
 		u8 clk_gate_flags, spinlock_t *lock);
+struct clk *clk_register_gate_shared(struct device *dev, const char *name,
+		const char *parent_name, unsigned long flags,
+		void __iomem *reg, u8 bit_idx,
+		u8 clk_gate_flags, spinlock_t *lock,
+		int *share_count);
 
 struct clk_div_table {
 	unsigned int	val;


How to use these shared gates:

--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -123,6 +123,39 @@ static inline struct clk *mpc512x_clk_gated(
				 reg, pos, 0, &clklock);
 }
 
+enum mpc512x_clk_shared_gate_id_t {
+	MPC512x_CLK_SHARED_GATE_MSCAN,
+	MPC512x_CLK_SHARED_GATE_MAX,
+};
+
+static int mpc512x_clk_gate_counters[MPC512x_CLK_SHARED_GATE_MAX];
+
+/*
+ * implementor's note:  since clk_gate items don't implement a separate
+ * .disable_unused() callback, their .disable() routine gets called and
+ * "disable the clock as we can't see it's in use" cannot be told from
+ * "regular disable, count these events please"
+ *
+ * passing the CLK_IGNORE_UNUSED flag upon clock creation will suppress
+ * the "disable, unused" call, so use counts won't get unbalanced, the
+ * clock either never got enabled and thus need not get disabled, or
+ * part of the hardware got enabled while disabling the other part isn't
+ * wanted
+ */
+static inline struct clk *mpc512x_clk_gated_shared(
+	const char *name, const char *parent_name,
+	u32 __iomem *reg, u8 pos,
+	enum mpc512x_clk_shared_gate_id_t share_id)
+{
+	int clkflags;
+
+	clkflags = CLK_SET_RATE_PARENT;
+	clkflags |= CLK_IGNORE_UNUSED;
+	return clk_register_gate_shared(NULL, name, parent_name, clkflags,
+					reg, pos, 0, &clklock,
+					&mpc512x_clk_gate_counters[share_id]);
+}
+
 static inline struct clk *mpc512x_clk_muxed(const char *name,
	const char **parent_names, int parent_count,
	u32 __iomem *reg, u8 pos, u8 len)
@@ -520,9 +553,16 @@ static void mpc512x_clk_setup_mclk(struct mclk_setup_data *entry)
				1, 1);
	}
	if (sccr_reg) {
+		if (entry->type == MCLK_TYPE_MSCAN) {
+			clks[clks_idx_pub] = mpc512x_clk_gated_shared(
+					entry->name_mclk,
+					entry->name_mux1, sccr_reg, sccr_bit,
+					MPC512x_CLK_SHARED_GATE_MSCAN);
+		} else {
			clks[clks_idx_pub] = mpc512x_clk_gated(
					entry->name_mclk,
					entry->name_mux1, sccr_reg, sccr_bit);
+		}
	} else {
		clks[clks_idx_pub] = mpc512x_clk_factor(
				entry->name_mclk,

Local tests have shown that the extension solves the problem of
how to satisfy the SoC's constraints on the MPC512x platform.
The MSCAN clocks no longer need to get pre-enabled, instead they
get setup and enabled only as the mscan(4) driver probes devices
according to how it was instructed (device tree nodes).

What do you think?  Is the "shared gate" support in the common
logic appropriate?  I'd rather not duplicate all of this code
just to introduce the specific gate I need, while most of the
logic is identical to the existing gate implementation.  The
desire isn't to override the gate's operations, but to wrap them
and to consult a counter in addition, while the register access
still applies.



virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de


From maxime.ripard at free-electrons.com  Tue Jul 23 09:15:24 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 23 Jul 2013 15:15:24 +0200
Subject: [PATCH RFC 3/8] clk: sunxi: add gating support to PLL1
In-Reply-To: <1374541272-32173-4-git-send-email-emilio@elopez.com.ar>
References: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
 <1374541272-32173-4-git-send-email-emilio@elopez.com.ar>
Message-ID: <20130723131524.GD10389@lukather>

On Mon, Jul 22, 2013 at 10:01:07PM -0300, Emilio L?pez wrote:
> This commit adds gating support to PLL1 on the clock driver. This makes
> the PLL1 implementation fully compatible with PLL4 as well.
> 
> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>

Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130723/10e37aeb/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Jul 23 09:22:49 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 23 Jul 2013 15:22:49 +0200
Subject: [PATCH RFC 5/8] clk: sunxi: add PLL5 and PLL6 support
In-Reply-To: <1374541272-32173-6-git-send-email-emilio@elopez.com.ar>
References: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
 <1374541272-32173-6-git-send-email-emilio@elopez.com.ar>
Message-ID: <20130723132249.GE10389@lukather>

Hi Emilio,

On Mon, Jul 22, 2013 at 10:01:09PM -0300, Emilio L?pez wrote:
> This commit implements PLL5 and PLL6 support on the sunxi clock driver.
> These PLLs use a similar factor clock, but differ on their outputs.
> 
> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt |   2 +
>  drivers/clk/sunxi/clk-sunxi.c                     | 159 +++++++++++++++++++++-
>  2 files changed, 159 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 9a28022..6634eac 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -8,6 +8,8 @@ Required properties:
>  - compatible : shall be one of the following:
>  	"allwinner,sun4i-osc-clk" - for a gatable oscillator
>  	"allwinner,sun4i-pll1-clk" - for the main PLL clock as well as PLL4
> +	"allwinner,sun4i-pll5-clk" - for the PLL5 clock
> +	"allwinner,sun4i-pll6-clk" - for the PLL6 clock
>  	"allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
>  	"allwinner,sun4i-axi-clk" - for the AXI clock
>  	"allwinner,sun4i-axi-gates-clk" - for the AXI gates
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 4dccdb9..743c2c2 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -127,6 +127,38 @@ static void sunxi_get_pll1_factors(u32 *freq, u32 parent_rate,
>  
>  
>  /**
> + * sunxi_get_pll5_factors() - calculates n, k factors for PLL5
> + * PLL5 rate is calculated as follows
> + * rate = parent_rate * n * (k + 1)

In the A10 and A10s datasheet, the given formula is:

for the DDR

rate = parent * n * (k + 1) / (m + 1)

and for the other output

rate = (parent * n * (k + 1)) >> (p + 1)

so it doesn't look very right to me here.

> + * parent_rate is always 24Mhz
> + */
> +
> +static void sunxi_get_pll5_factors(u32 *freq, u32 parent_rate,
> +				   u8 *n, u8 *k, u8 *m, u8 *p)
> +{
> +	u8 div;
> +
> +	/* Normalize value to a 24M multiple */
> +	div = *freq / 24000000;
> +	*freq = 24000000 * div;

And that also means that we can generate frequencies that are not
necessarily multiples of 24MHz, so the round up here is wrong as well.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130723/ce2aee0b/attachment.sig>

From santosh.shilimkar at ti.com  Tue Jul 23 09:26:34 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 23 Jul 2013 09:26:34 -0400
Subject: [PATCH 1/5] ARM: keystone: remove redundant smp_init_cpus
 definition
In-Reply-To: <1374579164-30255-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374579164-30255-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <51EE848A.8050904@ti.com>

On Tuesday 23 July 2013 07:32 AM, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> arm_dt_init_cpu_maps is called before smp_init_cpus. It makes the
> platform/SoC definition of smp_init_cpus unnecessary.
> 
> Cc: Santosh Shilimkar <santosh.shilimkar at ti.com>
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> ---
Looks good, thanks. I will pick this up.

Regards,
Santosh



From maxime.ripard at free-electrons.com  Tue Jul 23 09:29:10 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 23 Jul 2013 15:29:10 +0200
Subject: [PATCH RFC 7/8] clk: sunxi: mod0 support
In-Reply-To: <1374541272-32173-8-git-send-email-emilio@elopez.com.ar>
References: <1374541272-32173-1-git-send-email-emilio@elopez.com.ar>
 <1374541272-32173-8-git-send-email-emilio@elopez.com.ar>
Message-ID: <20130723132910.GF10389@lukather>

On Mon, Jul 22, 2013 at 10:01:11PM -0300, Emilio L?pez wrote:
> This commit implements support for the "module 0" type of clocks, as
> used by MMC, IR, NAND, SATA and other components.
> 
> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>

It looks right to me,
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130723/a39266d4/attachment.sig>

From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:05 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:05 -0300
Subject: [PATCH v8 01/28] memory: mvebu-devbus: Remove address decoding window
 workaround
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-2-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus device tree binding has been introduced, remove the address
decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in
the device tree, as described by the mbus binding documentation.

Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/memory/mvebu-devbus.c | 64 ++-----------------------------------------
 1 file changed, 2 insertions(+), 62 deletions(-)

diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
index 978e8e3..94c9248 100644
--- a/drivers/memory/mvebu-devbus.c
+++ b/drivers/memory/mvebu-devbus.c
@@ -208,16 +208,11 @@ static int mvebu_devbus_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct device_node *node = pdev->dev.of_node;
-	struct device_node *parent;
 	struct devbus *devbus;
 	struct resource *res;
 	struct clk *clk;
 	unsigned long rate;
-	const __be32 *ranges;
-	int err, cs;
-	int addr_cells, p_addr_cells, size_cells;
-	int ranges_len, tuple_len;
-	u32 base, size;
+	int err;
 
 	devbus = devm_kzalloc(&pdev->dev, sizeof(struct devbus), GFP_KERNEL);
 	if (!devbus)
@@ -248,68 +243,13 @@ static int mvebu_devbus_probe(struct platform_device *pdev)
 		return err;
 
 	/*
-	 * Allocate an address window for this device.
-	 * If the device probing fails, then we won't be able to
-	 * remove the allocated address decoding window.
-	 *
-	 * FIXME: This is only a temporary hack! We need to do this here
-	 * because we still don't have device tree bindings for mbus.
-	 * Once that support is added, we will declare these address windows
-	 * statically in the device tree, and remove the window configuration
-	 * from here.
-	 */
-
-	/*
-	 * Get the CS to choose the window string.
-	 * This is a bit hacky, but it will be removed once the
-	 * address windows are declared in the device tree.
-	 */
-	cs = (((unsigned long)devbus->base) % 0x400) / 8;
-
-	/*
-	 * Parse 'ranges' property to obtain a (base,size) window tuple.
-	 * This will be removed once the address windows
-	 * are declared in the device tree.
-	 */
-	parent = of_get_parent(node);
-	if (!parent)
-		return -EINVAL;
-
-	p_addr_cells = of_n_addr_cells(parent);
-	of_node_put(parent);
-
-	addr_cells = of_n_addr_cells(node);
-	size_cells = of_n_size_cells(node);
-	tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
-
-	ranges = of_get_property(node, "ranges", &ranges_len);
-	if (ranges == NULL || ranges_len != tuple_len)
-		return -EINVAL;
-
-	base = of_translate_address(node, ranges + addr_cells);
-	if (base == OF_BAD_ADDR)
-		return -EINVAL;
-	size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
-
-	/*
-	 * Create an mbus address windows.
-	 * FIXME: Remove this, together with the above code, once the
-	 * address windows are declared in the device tree.
-	 */
-	err = mvebu_mbus_add_window(devbus_wins[cs], base, size);
-	if (err < 0)
-		return err;
-
-	/*
 	 * We need to create a child device explicitly from here to
 	 * guarantee that the child will be probed after the timing
 	 * parameters for the bus are written.
 	 */
 	err = of_platform_populate(node, NULL, NULL, dev);
-	if (err < 0) {
-		mvebu_mbus_del_window(base, size);
+	if (err < 0)
 		return err;
-	}
 
 	return 0;
 }
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:04 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:04 -0300
Subject: [PATCH v8 00/28] MBus DT binding for Armada 370/XP and Kirkwood
Message-ID: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>

After Andrew Lunn reported [1] this work need to take account of Kirkwood
to prevent breaking PCIe on such platform, here's a new version adding
MBus DT binding for Kirkwood and in particular using it to declare PCIe
properly.

I've chosen a PCIe memory and I/O aperture size following the legacy PCIe
initialization in implemented arch/arm/mach-kirkwood/pcie.c.
Namely 0xe0000000-0xf0000000 for memory space, and 0xf200000-0xf2100000 for
I/O space. Keep in mind, this is just a particular choice and can be overriden
in per-board DT files.

This patchset is tested on several Armada 370/XP and on
Plathome Openblocks A6 Kirkwood board.

Due to lack of more Kirkwood boards, I'd like to have Tested-by's for
legacy (non-DT) initialized Kirkwood boards, and PCIe-capable Kirkwood boards.

To make it easier for these testings, there's a public branch:

  https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v8

Last but not least, I'd like to have formal Acked-by from DT maintainers
to the DT binding itself (notice this is independent of the recently
found kirkwood breakage).

This is based on v3.11-rc2.

[1] http://www.mail-archive.com/devicetree-discuss at lists.ozlabs.org/msg37059.html

Changelog
---------

v8:

 * Introduce Kirkwood MBus DT binding and use it to relocate
   the PCIe nodes *only*.

 * Allow MBus to initialize when the node has no ranges property.

 * Add a sanity check for PCIe port base address to prevent a kernel
   panic when this address has not been obtained. Instead of panic,
   the PCIe won't work in such cases.

v7:

 * Add two optional properties pcie-{mem,io}-aperture to the MBus node
   defining the PCIe mem and IO region apertures.

 * Encode the PCIe port in the second cell of the ranges entries, using
   the PCIe slot; and remove such encoding from the first cell, since it
   was violating the specification.

   Quoting Jason Gunthorpe:
   """ [...] the OF spec says that the phys.hi fields of the child address
   spaces in the "ranges" property for PCI does not contain the same
   information as "reg" property entries within PCI nodes. The only information
   that is present in "ranges" phys.hi entries are the non-relocatable,
   prefetchable and the PCI address space bits for which the entry applies.
   I.e., only the n, p and ss bits are present; the bbbbbbbb, ddddd, fff and
   rrrrrrrr fields are 0."""

v6:

 * Change the PCIe ranges translations encoding, removing the big fake
   window encoded as MBUS_ID(0xf0, 0x02) by an array of entries representing
   the PCIe real windows with full 4 GiB size.

 * The corresponding PCIe port is selected by encoding the bus in the first cell
   of the PCIe controller node ranges entry.

 * Remove the name-based MBus window allocation API, replacing it by an
   ID-based API.

v5:

 * Add a required a 'controller' property to specify a phandle containing
   the MBus controller MMIO registers.

v4:

 * Fixed the pcie-controller to mbus address space translations, to match
   a 1:1 mapping between the PCI and CPU busses.

 * Fixed the binding documentation with suggestions from Arnd Bergmann.

 * Added a BootROM sanity check on AXP SMP initialization, as suggested
   by Jason Gunthorpe. This also implied changing slightly the bootrom
   node.

 * Changed the first cell format for the MBus address space.

v3:

 * Replaced the PCIe mapping with 0xffff0002, to avoid using a representation
   that might correspond to a possible window id.

 * Remove every mbus-node 'ranges' property from the dtsi files. Having them
   on the per-board dts files only makes maintaince less painful.

 * Declare children window size, in the children 'ranges' property, as large
   as possible (4 GiB size) and move the property to the dtsi files.
   The per-board dts, does not need to declare that property now.

 * The MBus driver now creates the decoding window using the base address and
   size specified in the mbus-node, instead of using the children entries.

v2:

 * Use the preprocessor on the DT and define a macro for the window ID.

 * Changed the way the address spaces were declared: the window's base
   addresses are only present in the mbus-node ranges property.
   This makes sense since that information belongs only to the MBus
   address space.

 * Drop the ranges dynamic update, since now the DT translations are complete.

 * Replaced the internal register first cell mapping with 0xffff0001, to avoid
   clashing when using 0x00000000.

 * Replaced the PCIe mapping with 0xffff0000.

v1:

  * Initial proposal

Example
-------

Here's an example showing how the MBus DT binding looks now:

soc {
	compatible = "marvell,armadaxp-mbus", "simple-bus";
	controller = <&mbusc>;
	pcie-mem-aperture = <0xe0000000 0x8000000>;
	pcie-io-aperture  = <0xe8000000 0x100000>;

	ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
		  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
		  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;

	bootrom {
		compatible = "marvell,bootrom";
		reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
	};

	devbus-bootcs {
		status = "okay";
		ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;

		/* NOR */
		nor {
			compatible = "cfi-flash";
			reg = <0 0x8000000>;
			bank-width = <2>;
		};
	};

	pcie-controller {
		compatible = "marvell,armada-xp-pcie";
		status = "okay";
		device_type = "pci";
		#address-cells = <3>;
		#size-cells = <2>;

		ranges =
			<0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
			0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
			0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
			0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
			0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
			0x82000000 0x1 0       MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
			0x81000000 0x1 0       MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */
			0x82000000 0x2 0       MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
			0x81000000 0x2 0       MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */>;


		pcie at 1,0 {
			device_type = "pci";
			assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
			reg = <0x0800 0 0 0 0>;
			#address-cells = <3>;
			#size-cells = <2>;
			#interrupt-cells = <1>;
			ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
				  0x81000000 0 0 0x81000000 0x1 0 1 0>;
			interrupt-map-mask = <0 0 0 0>;
			interrupt-map = <0 0 0 0 &mpic 58>;
			marvell,pcie-port = <0>;
			marvell,pcie-lane = <0>;
			clocks = <&gateclk 5>;
			status = "disabled";
		};

		pcie at 2,0 {
			device_type = "pci";
			assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
			reg = <0x1000 0 0 0 0>;
			#address-cells = <3>;
			#size-cells = <2>;
			#interrupt-cells = <1>;
			ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
				  0x81000000 0 0 0x81000000 0x2 0 1 0>;
			interrupt-map-mask = <0 0 0 0>;
			interrupt-map = <0 0 0 0 &mpic 62>;
			marvell,pcie-port = <1>;
			marvell,pcie-lane = <0>;
			clocks = <&gateclk 9>;
			status = "disabled";
		};
	};

	internal-regs {
		compatible = "simple-bus";
		#address-cells = <1>;
		#size-cells = <1>;
		ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;

		mbusc: mbus-controller at 20000 {
			reg = <0x20000 0x100>, <0x20180 0x20>;
		};

		interrupt-controller at 20000 {
			reg = <0x20a00 0x2d0>, <0x21070 0x58>;
		};
	};
};


Ezequiel Garcia (18):
  memory: mvebu-devbus: Remove address decoding window workaround
  bus: mvebu-mbus: Factor out initialization details
  bus: mvebu-mbus: Introduce device tree binding
  bus: mvebu-mbus: Add static window allocation to the DT binding
  bus: mvebu-mbus: Add new API for the PCIe memory and IO aperture
  PCI: mvebu: Check valid base address before port setup
  ARM: mvebu: Remove the harcoded BootROM window allocation
  ARM: mvebu: Initialize MBus using the DT binding
  ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
  ARM: mvebu: Add MBus to Armada 370/XP device tree
  ARM: mvebu: Add BootROM to Armada 370/XP device tree
  ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
  ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes
  ARM: kirkwood: Split DT and legacy MBus initialization
  ARM: kirkwood: Use the preprocessor on device tree files
  ARM: kirkwood: Introduce MBus DT node
  ARM: kirkwood: Introduce MBUS_ID
  ARM: kirkwood: Relocate PCIe device tree nodes

Thomas Petazzoni (10):
  bus: mvebu-mbus: Add new API for window creation
  ARM: kirkwood: Move to ID based MBus window creation
  ARM: mv78xx0: Move to ID based window creation
  ARM: orion5x: Move to ID based window creation
  ARM: dove: Move to ID based window creation
  PCI: mvebu: Adapt to the new device tree layout
  bus: mvebu-mbus: Remove the no longer used name-based API
  bus: mvebu-mbus: Remove name -> target, attribute mapping tables
  bus: mvebu-mbus: Update main description
  bus: mvebu-mbus: Factorize Armada 370/XP data structures

 .../devicetree/bindings/bus/mvebu-mbus.txt         | 267 +++++++++++++
 .../devicetree/bindings/pci/mvebu-pci.txt          | 145 +++++--
 arch/arm/boot/dts/armada-370-db.dts                |   5 +-
 arch/arm/boot/dts/armada-370-mirabox.dts           |  37 +-
 arch/arm/boot/dts/armada-370-rd.dts                |   5 +-
 arch/arm/boot/dts/armada-370-xp.dtsi               | 111 +++---
 arch/arm/boot/dts/armada-370.dtsi                  | 112 +++---
 arch/arm/boot/dts/armada-xp-db.dts                 | 131 +++---
 arch/arm/boot/dts/armada-xp-gp.dts                 | 107 +++--
 arch/arm/boot/dts/armada-xp-mv78230.dtsi           | 222 ++++++-----
 arch/arm/boot/dts/armada-xp-mv78260.dtsi           | 263 ++++++------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi           | 411 ++++++++++---------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |  88 ++--
 arch/arm/boot/dts/armada-xp.dtsi                   |   9 +-
 arch/arm/boot/dts/kirkwood-6281.dtsi               |  66 +--
 arch/arm/boot/dts/kirkwood-6282.dtsi               | 102 ++---
 arch/arm/boot/dts/kirkwood-cloudbox.dts            |   4 +-
 arch/arm/boot/dts/kirkwood-db-88f6281.dts          |   7 +-
 arch/arm/boot/dts/kirkwood-db-88f6282.dts          |   7 +-
 arch/arm/boot/dts/kirkwood-db.dtsi                 |  10 +-
 arch/arm/boot/dts/kirkwood-dns320.dts              |   2 +-
 arch/arm/boot/dts/kirkwood-dns325.dts              |   2 +-
 arch/arm/boot/dts/kirkwood-dnskw.dtsi              |   4 +-
 arch/arm/boot/dts/kirkwood-dockstar.dts            |   4 +-
 arch/arm/boot/dts/kirkwood-dreamplug.dts           |   4 +-
 arch/arm/boot/dts/kirkwood-goflexnet.dts           |   4 +-
 .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |   4 +-
 arch/arm/boot/dts/kirkwood-ib62x0.dts              |   4 +-
 arch/arm/boot/dts/kirkwood-iconnect.dts            |  23 +-
 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts      |   4 +-
 arch/arm/boot/dts/kirkwood-is2.dts                 |   2 +-
 arch/arm/boot/dts/kirkwood-km_kirkwood.dts         |   4 +-
 arch/arm/boot/dts/kirkwood-lschlv2.dts             |   2 +-
 arch/arm/boot/dts/kirkwood-lsxhl.dts               |   2 +-
 arch/arm/boot/dts/kirkwood-lsxl.dtsi               |   4 +-
 arch/arm/boot/dts/kirkwood-mplcec4.dts             |  23 +-
 .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  |  23 +-
 arch/arm/boot/dts/kirkwood-ns2-common.dtsi         |   4 +-
 arch/arm/boot/dts/kirkwood-ns2.dts                 |   2 +-
 arch/arm/boot/dts/kirkwood-ns2lite.dts             |   2 +-
 arch/arm/boot/dts/kirkwood-ns2max.dts              |   2 +-
 arch/arm/boot/dts/kirkwood-ns2mini.dts             |   2 +-
 arch/arm/boot/dts/kirkwood-nsa310.dts              |  23 +-
 arch/arm/boot/dts/kirkwood-openblocks_a6.dts       |   4 +-
 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi  |   4 +-
 arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts    |   2 +-
 arch/arm/boot/dts/kirkwood-sheevaplug.dts          |   2 +-
 arch/arm/boot/dts/kirkwood-topkick.dts             |   4 +-
 arch/arm/boot/dts/kirkwood-ts219-6281.dts          |   6 +-
 arch/arm/boot/dts/kirkwood-ts219-6282.dts          |  25 +-
 arch/arm/boot/dts/kirkwood-ts219.dtsi              |  17 +-
 arch/arm/boot/dts/kirkwood.dtsi                    |  17 +-
 arch/arm/mach-dove/common.c                        |  68 ++--
 arch/arm/mach-kirkwood/board-dt.c                  |   1 +
 arch/arm/mach-kirkwood/common.c                    |  26 +-
 arch/arm/mach-kirkwood/pcie.c                      |  40 +-
 arch/arm/mach-mv78xx0/pcie.c                       |  23 +-
 arch/arm/mach-mvebu/armada-370-xp.c                |  34 +-
 arch/arm/mach-mvebu/platsmp.c                      |  25 +-
 arch/arm/mach-orion5x/common.c                     |  36 +-
 arch/arm/mach-orion5x/common.h                     |  17 +
 arch/arm/mach-orion5x/d2net-setup.c                |   6 +-
 arch/arm/mach-orion5x/db88f5281-setup.c            |  24 +-
 arch/arm/mach-orion5x/dns323-setup.c               |   6 +-
 arch/arm/mach-orion5x/edmini_v2-setup.c            |   6 +-
 arch/arm/mach-orion5x/kurobox_pro-setup.c          |  12 +-
 arch/arm/mach-orion5x/ls-chl-setup.c               |   6 +-
 arch/arm/mach-orion5x/ls_hgl-setup.c               |   6 +-
 arch/arm/mach-orion5x/lsmini-setup.c               |   6 +-
 arch/arm/mach-orion5x/mss2-setup.c                 |   6 +-
 arch/arm/mach-orion5x/mv2120-setup.c               |   6 +-
 arch/arm/mach-orion5x/net2big-setup.c              |   6 +-
 arch/arm/mach-orion5x/pci.c                        |   9 +-
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c       |   6 +-
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c        |   6 +-
 arch/arm/mach-orion5x/rd88f5182-setup.c            |  13 +-
 arch/arm/mach-orion5x/terastation_pro2-setup.c     |   6 +-
 arch/arm/mach-orion5x/ts209-setup.c                |   6 +-
 arch/arm/mach-orion5x/ts409-setup.c                |   6 +-
 arch/arm/mach-orion5x/wnr854t-setup.c              |   6 +-
 arch/arm/mach-orion5x/wrt350n-v2-setup.c           |   6 +-
 drivers/bus/mvebu-mbus.c                           | 441 ++++++++++++---------
 drivers/memory/mvebu-devbus.c                      |  64 +--
 drivers/pci/host/pci-mvebu.c                       | 115 ++++--
 include/linux/mbus.h                               |  16 +-
 85 files changed, 2021 insertions(+), 1379 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt

-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:06 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:06 -0300
Subject: [PATCH v8 02/28] bus: mvebu-mbus: Add new API for window creation
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-3-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

We add an API to create MBus address decoding windows from the target
ID and attribute. This function will be used later and deprecate the
current name based scheme.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 33 +++++++++++++++++++++++++--------
 include/linux/mbus.h     |  6 ++++++
 2 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 33c6947..827468a 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -748,6 +748,22 @@ static const struct of_device_id of_mvebu_mbus_ids[] = {
 /*
  * Public API of the driver
  */
+int mvebu_mbus_add_window_remap_by_id(unsigned int target,
+				      unsigned int attribute,
+				      phys_addr_t base, size_t size,
+				      phys_addr_t remap)
+{
+	struct mvebu_mbus_state *s = &mbus_state;
+
+	if (!mvebu_mbus_window_conflicts(s, base, size, target, attribute)) {
+		pr_err("cannot add window '%x:%x', conflicts with another window\n",
+		       target, attribute);
+		return -EINVAL;
+	}
+
+	return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
+}
+
 int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 				      size_t size, phys_addr_t remap,
 				      unsigned int flags)
@@ -776,14 +792,8 @@ int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 	else if (flags == MVEBU_MBUS_PCI_WA)
 		attr |= 0x28;
 
-	if (!mvebu_mbus_window_conflicts(s, base, size, target, attr)) {
-		pr_err("cannot add window '%s', conflicts with another window\n",
-		       devname);
-		return -EINVAL;
-	}
-
-	return mvebu_mbus_alloc_window(s, base, size, remap, target, attr);
-
+	return mvebu_mbus_add_window_remap_by_id(target, attr, base,
+						 size, remap);
 }
 
 int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
@@ -792,6 +802,13 @@ int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
 						 MVEBU_MBUS_NO_REMAP, 0);
 }
 
+int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
+				phys_addr_t base, size_t size)
+{
+	return mvebu_mbus_add_window_remap_by_id(target, attribute, base,
+						 size, MVEBU_MBUS_NO_REMAP);
+}
+
 int mvebu_mbus_del_window(phys_addr_t base, size_t size)
 {
 	int win;
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index dba482e..9245b66 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -62,8 +62,14 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
 int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 				      size_t size, phys_addr_t remap,
 				      unsigned int flags);
+int mvebu_mbus_add_window_remap_by_id(unsigned int target,
+				      unsigned int attribute,
+				      phys_addr_t base, size_t size,
+				      phys_addr_t remap);
 int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
 			  size_t size);
+int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
+				phys_addr_t base, size_t size);
 int mvebu_mbus_del_window(phys_addr_t base, size_t size);
 int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
 		    size_t mbus_size, phys_addr_t sdram_phys_base,
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:07 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:07 -0300
Subject: [PATCH v8 03/28] ARM: kirkwood: Move to ID based MBus window creation
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-4-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-kirkwood/common.c | 18 ++++++++++++++----
 arch/arm/mach-kirkwood/pcie.c   | 40 ++++++++++++++++++++++++----------------
 2 files changed, 38 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index e9238b5..165e751 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -37,6 +37,12 @@
 #include <linux/platform_data/dma-mv_xor.h>
 #include "common.h"
 
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_NAND_TARGET 0x01
+#define KIRKWOOD_MBUS_NAND_ATTR   0x2f
+#define KIRKWOOD_MBUS_SRAM_TARGET 0x03
+#define KIRKWOOD_MBUS_SRAM_ATTR   0x01
+
 /*****************************************************************************
  * I/O Address Mapping
  ****************************************************************************/
@@ -672,10 +678,14 @@ char * __init kirkwood_id(void)
 
 void __init kirkwood_setup_wins(void)
 {
-	mvebu_mbus_add_window("nand", KIRKWOOD_NAND_MEM_PHYS_BASE,
-			      KIRKWOOD_NAND_MEM_SIZE);
-	mvebu_mbus_add_window("sram", KIRKWOOD_SRAM_PHYS_BASE,
-			      KIRKWOOD_SRAM_SIZE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_NAND_TARGET,
+				    KIRKWOOD_MBUS_NAND_ATTR,
+				    KIRKWOOD_NAND_MEM_PHYS_BASE,
+				    KIRKWOOD_NAND_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_SRAM_TARGET,
+				    KIRKWOOD_MBUS_SRAM_ATTR,
+				    KIRKWOOD_SRAM_PHYS_BASE,
+				    KIRKWOOD_SRAM_SIZE);
 }
 
 void __init kirkwood_l2_init(void)
diff --git a/arch/arm/mach-kirkwood/pcie.c b/arch/arm/mach-kirkwood/pcie.c
index ddcb09f..12d86f3 100644
--- a/arch/arm/mach-kirkwood/pcie.c
+++ b/arch/arm/mach-kirkwood/pcie.c
@@ -20,6 +20,16 @@
 #include <mach/bridge-regs.h>
 #include "common.h"
 
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_PCIE0_MEM_TARGET    0x4
+#define KIRKWOOD_MBUS_PCIE0_MEM_ATTR      0xe8
+#define KIRKWOOD_MBUS_PCIE0_IO_TARGET     0x4
+#define KIRKWOOD_MBUS_PCIE0_IO_ATTR       0xe0
+#define KIRKWOOD_MBUS_PCIE1_MEM_TARGET    0x4
+#define KIRKWOOD_MBUS_PCIE1_MEM_ATTR      0xd8
+#define KIRKWOOD_MBUS_PCIE1_IO_TARGET     0x4
+#define KIRKWOOD_MBUS_PCIE1_IO_ATTR       0xd0
+
 static void kirkwood_enable_pcie_clk(const char *port)
 {
 	struct clk *clk;
@@ -254,26 +264,24 @@ static void __init add_pcie_port(int index, void __iomem *base)
 
 void __init kirkwood_pcie_init(unsigned int portmask)
 {
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
+	mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE0_IO_TARGET,
+					  KIRKWOOD_MBUS_PCIE0_IO_ATTR,
 					  KIRKWOOD_PCIE_IO_PHYS_BASE,
 					  KIRKWOOD_PCIE_IO_SIZE,
-					  KIRKWOOD_PCIE_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
-					  KIRKWOOD_PCIE_MEM_PHYS_BASE,
-					  KIRKWOOD_PCIE_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
+					  KIRKWOOD_PCIE_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_PCIE0_MEM_TARGET,
+				    KIRKWOOD_MBUS_PCIE0_MEM_ATTR,
+				    KIRKWOOD_PCIE_MEM_PHYS_BASE,
+				    KIRKWOOD_PCIE_MEM_SIZE);
+	mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE1_IO_TARGET,
+					  KIRKWOOD_MBUS_PCIE1_IO_ATTR,
 					  KIRKWOOD_PCIE1_IO_PHYS_BASE,
 					  KIRKWOOD_PCIE1_IO_SIZE,
-					  KIRKWOOD_PCIE1_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
-					  KIRKWOOD_PCIE1_MEM_PHYS_BASE,
-					  KIRKWOOD_PCIE1_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+					  KIRKWOOD_PCIE1_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_PCIE1_MEM_TARGET,
+				    KIRKWOOD_MBUS_PCIE1_MEM_ATTR,
+				    KIRKWOOD_PCIE1_MEM_PHYS_BASE,
+				    KIRKWOOD_PCIE1_MEM_SIZE);
 
 	vga_base = KIRKWOOD_PCIE_MEM_PHYS_BASE;
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:08 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:08 -0300
Subject: [PATCH v8 04/28] ARM: mv78xx0: Move to ID based window creation
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-5-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-mv78xx0/pcie.c | 23 +++++++++++------------
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-mv78xx0/pcie.c b/arch/arm/mach-mv78xx0/pcie.c
index dc26a65..397afde 100644
--- a/arch/arm/mach-mv78xx0/pcie.c
+++ b/arch/arm/mach-mv78xx0/pcie.c
@@ -18,6 +18,11 @@
 #include <mach/mv78xx0.h>
 #include "common.h"
 
+#define MV78XX0_MBUS_PCIE_MEM_TARGET(port, lane) ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_MEM_ATTR(port, lane)   (0xf8 & ~(0x10 << (lane)))
+#define MV78XX0_MBUS_PCIE_IO_TARGET(port, lane)  ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_IO_ATTR(port, lane)    (0xf0 & ~(0x10 << (lane)))
+
 struct pcie_port {
 	u8			maj;
 	u8			min;
@@ -71,7 +76,6 @@ static void __init mv78xx0_pcie_preinit(void)
 	start = MV78XX0_PCIE_MEM_PHYS_BASE;
 	for (i = 0; i < num_pcie_ports; i++) {
 		struct pcie_port *pp = pcie_port + i;
-		char winname[MVEBU_MBUS_MAX_WINNAME_SZ];
 
 		snprintf(pp->mem_space_name, sizeof(pp->mem_space_name),
 			"PCIe %d.%d MEM", pp->maj, pp->min);
@@ -85,17 +89,12 @@ static void __init mv78xx0_pcie_preinit(void)
 		if (request_resource(&iomem_resource, &pp->res))
 			panic("can't allocate PCIe MEM sub-space");
 
-		snprintf(winname, sizeof(winname), "pcie%d.%d",
-			 pp->maj, pp->min);
-
-		mvebu_mbus_add_window_remap_flags(winname,
-						  pp->res.start,
-						  resource_size(&pp->res),
-						  MVEBU_MBUS_NO_REMAP,
-						  MVEBU_MBUS_PCI_MEM);
-		mvebu_mbus_add_window_remap_flags(winname,
-						  i * SZ_64K, SZ_64K,
-						  0, MVEBU_MBUS_PCI_IO);
+		mvebu_mbus_add_window_by_id(MV78XX0_MBUS_PCIE_MEM_TARGET(pp->maj, pp->min),
+					    MV78XX0_MBUS_PCIE_MEM_ATTR(pp->maj, pp->min),
+					    pp->res.start, resource_size(&pp->res));
+		mvebu_mbus_add_window_remap_by_id(MV78XX0_MBUS_PCIE_IO_TARGET(pp->maj, pp->min),
+						  MV78XX0_MBUS_PCIE_IO_ATTR(pp->maj, pp->min),
+						  i * SZ_64K, SZ_64K, 0);
 	}
 }
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:09 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:09 -0300
Subject: [PATCH v8 05/28] ARM: orion5x: Move to ID based window creation
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-6-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-orion5x/common.c                 | 36 ++++++++++++++------------
 arch/arm/mach-orion5x/common.h                 | 17 ++++++++++++
 arch/arm/mach-orion5x/d2net-setup.c            |  6 +++--
 arch/arm/mach-orion5x/db88f5281-setup.c        | 24 +++++++++++------
 arch/arm/mach-orion5x/dns323-setup.c           |  6 +++--
 arch/arm/mach-orion5x/edmini_v2-setup.c        |  6 +++--
 arch/arm/mach-orion5x/kurobox_pro-setup.c      | 12 ++++++---
 arch/arm/mach-orion5x/ls-chl-setup.c           |  6 +++--
 arch/arm/mach-orion5x/ls_hgl-setup.c           |  6 +++--
 arch/arm/mach-orion5x/lsmini-setup.c           |  6 +++--
 arch/arm/mach-orion5x/mss2-setup.c             |  6 +++--
 arch/arm/mach-orion5x/mv2120-setup.c           |  6 +++--
 arch/arm/mach-orion5x/net2big-setup.c          |  6 +++--
 arch/arm/mach-orion5x/pci.c                    |  9 +++----
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c   |  6 +++--
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c    |  6 +++--
 arch/arm/mach-orion5x/rd88f5182-setup.c        | 13 ++++++----
 arch/arm/mach-orion5x/terastation_pro2-setup.c |  6 +++--
 arch/arm/mach-orion5x/ts209-setup.c            |  6 +++--
 arch/arm/mach-orion5x/ts409-setup.c            |  6 +++--
 arch/arm/mach-orion5x/wnr854t-setup.c          |  6 +++--
 arch/arm/mach-orion5x/wrt350n-v2-setup.c       |  6 +++--
 22 files changed, 137 insertions(+), 70 deletions(-)

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index b41599f..91a5852 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -174,8 +174,10 @@ void __init orion5x_xor_init(void)
  ****************************************************************************/
 static void __init orion5x_crypto_init(void)
 {
-	mvebu_mbus_add_window("sram", ORION5X_SRAM_PHYS_BASE,
-			      ORION5X_SRAM_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_SRAM_TARGET,
+				    ORION_MBUS_SRAM_ATTR,
+				    ORION5X_SRAM_PHYS_BASE,
+				    ORION5X_SRAM_SIZE);
 	orion_crypto_init(ORION5X_CRYPTO_PHYS_BASE, ORION5X_SRAM_PHYS_BASE,
 			  SZ_8K, IRQ_ORION5X_CESA);
 }
@@ -222,22 +224,24 @@ void orion5x_setup_wins(void)
 	 * The PCIe windows will no longer be statically allocated
 	 * here once Orion5x is migrated to the pci-mvebu driver.
 	 */
-	mvebu_mbus_add_window_remap_flags("pcie0.0", ORION5X_PCIE_IO_PHYS_BASE,
+	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
+					  ORION_MBUS_PCIE_IO_ATTR,
+					  ORION5X_PCIE_IO_PHYS_BASE,
 					  ORION5X_PCIE_IO_SIZE,
-					  ORION5X_PCIE_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0", ORION5X_PCIE_MEM_PHYS_BASE,
-					  ORION5X_PCIE_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pci0.0", ORION5X_PCI_IO_PHYS_BASE,
+					  ORION5X_PCIE_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
+				    ORION_MBUS_PCIE_MEM_ATTR,
+				    ORION5X_PCIE_MEM_PHYS_BASE,
+				    ORION5X_PCIE_MEM_SIZE);
+	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
+					  ORION_MBUS_PCI_IO_ATTR,
+					  ORION5X_PCI_IO_PHYS_BASE,
 					  ORION5X_PCI_IO_SIZE,
-					  ORION5X_PCI_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pci0.0", ORION5X_PCI_MEM_PHYS_BASE,
-					  ORION5X_PCI_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+					  ORION5X_PCI_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
+				    ORION_MBUS_PCI_MEM_ATTR,
+				    ORION5X_PCI_MEM_PHYS_BASE,
+				    ORION5X_PCI_MEM_SIZE);
 }
 
 int orion5x_tclk;
diff --git a/arch/arm/mach-orion5x/common.h b/arch/arm/mach-orion5x/common.h
index a909afb..f565f99 100644
--- a/arch/arm/mach-orion5x/common.h
+++ b/arch/arm/mach-orion5x/common.h
@@ -7,6 +7,23 @@ struct dsa_platform_data;
 struct mv643xx_eth_platform_data;
 struct mv_sata_platform_data;
 
+#define ORION_MBUS_PCIE_MEM_TARGET    0x04
+#define ORION_MBUS_PCIE_MEM_ATTR      0x59
+#define ORION_MBUS_PCIE_IO_TARGET     0x04
+#define ORION_MBUS_PCIE_IO_ATTR       0x51
+#define ORION_MBUS_PCIE_WA_TARGET     0x04
+#define ORION_MBUS_PCIE_WA_ATTR       0x79
+#define ORION_MBUS_PCI_MEM_TARGET     0x03
+#define ORION_MBUS_PCI_MEM_ATTR       0x59
+#define ORION_MBUS_PCI_IO_TARGET      0x03
+#define ORION_MBUS_PCI_IO_ATTR        0x51
+#define ORION_MBUS_DEVBUS_BOOT_TARGET 0x01
+#define ORION_MBUS_DEVBUS_BOOT_ATTR   0x0f
+#define ORION_MBUS_DEVBUS_TARGET(cs)  0x01
+#define ORION_MBUS_DEVBUS_ATTR(cs)    (~(1 << cs))
+#define ORION_MBUS_SRAM_TARGET        0x00
+#define ORION_MBUS_SRAM_ATTR          0x00
+
 /*
  * Basic Orion init functions used early by machine-setup.
  */
diff --git a/arch/arm/mach-orion5x/d2net-setup.c b/arch/arm/mach-orion5x/d2net-setup.c
index 16c88bb..8f68b74 100644
--- a/arch/arm/mach-orion5x/d2net-setup.c
+++ b/arch/arm/mach-orion5x/d2net-setup.c
@@ -317,8 +317,10 @@ static void __init d2net_init(void)
 	d2net_sata_power_init();
 	orion5x_sata_init(&d2net_sata_data);
 
-	mvebu_mbus_add_window("devbus-boot", D2NET_NOR_BOOT_BASE,
-			      D2NET_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    D2NET_NOR_BOOT_BASE,
+				    D2NET_NOR_BOOT_SIZE);
 	platform_device_register(&d2net_nor_flash);
 
 	platform_device_register(&d2net_gpio_buttons);
diff --git a/arch/arm/mach-orion5x/db88f5281-setup.c b/arch/arm/mach-orion5x/db88f5281-setup.c
index 4e1263d..4b2aefd 100644
--- a/arch/arm/mach-orion5x/db88f5281-setup.c
+++ b/arch/arm/mach-orion5x/db88f5281-setup.c
@@ -340,19 +340,27 @@ static void __init db88f5281_init(void)
 	orion5x_uart0_init();
 	orion5x_uart1_init();
 
-	mvebu_mbus_add_window("devbus-boot", DB88F5281_NOR_BOOT_BASE,
-			      DB88F5281_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    DB88F5281_NOR_BOOT_BASE,
+				    DB88F5281_NOR_BOOT_SIZE);
 	platform_device_register(&db88f5281_boot_flash);
 
-	mvebu_mbus_add_window("devbus-cs0", DB88F5281_7SEG_BASE,
-			      DB88F5281_7SEG_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(0),
+				    ORION_MBUS_DEVBUS_ATTR(0),
+				    DB88F5281_7SEG_BASE,
+				    DB88F5281_7SEG_SIZE);
 
-	mvebu_mbus_add_window("devbus-cs1", DB88F5281_NOR_BASE,
-			      DB88F5281_NOR_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(1),
+				    ORION_MBUS_DEVBUS_ATTR(1),
+				    DB88F5281_NOR_BASE,
+				    DB88F5281_NOR_SIZE);
 	platform_device_register(&db88f5281_nor_flash);
 
-	mvebu_mbus_add_window("devbus-cs2", DB88F5281_NAND_BASE,
-			      DB88F5281_NAND_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(2),
+				    ORION_MBUS_DEVBUS_ATTR(2),
+				    DB88F5281_NAND_BASE,
+				    DB88F5281_NAND_SIZE);
 	platform_device_register(&db88f5281_nand_flash);
 
 	i2c_register_board_info(0, &db88f5281_i2c_rtc, 1);
diff --git a/arch/arm/mach-orion5x/dns323-setup.c b/arch/arm/mach-orion5x/dns323-setup.c
index 9e6baf5..7097473 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -611,8 +611,10 @@ static void __init dns323_init(void)
 	/* setup flash mapping
 	 * CS3 holds a 8 MB Spansion S29GL064M90TFIR4
 	 */
-	mvebu_mbus_add_window("devbus-boot", DNS323_NOR_BOOT_BASE,
-			      DNS323_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    DNS323_NOR_BOOT_BASE,
+				    DNS323_NOR_BOOT_SIZE);
 	platform_device_register(&dns323_nor_flash);
 
 	/* Sort out LEDs, Buttons and i2c devices */
diff --git a/arch/arm/mach-orion5x/edmini_v2-setup.c b/arch/arm/mach-orion5x/edmini_v2-setup.c
index 1476155..0fc33c5 100644
--- a/arch/arm/mach-orion5x/edmini_v2-setup.c
+++ b/arch/arm/mach-orion5x/edmini_v2-setup.c
@@ -154,8 +154,10 @@ void __init edmini_v2_init(void)
 	orion5x_ehci0_init();
 	orion5x_eth_init(&edmini_v2_eth_data);
 
-	mvebu_mbus_add_window("devbus-boot", EDMINI_V2_NOR_BOOT_BASE,
-			      EDMINI_V2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    EDMINI_V2_NOR_BOOT_BASE,
+				    EDMINI_V2_NOR_BOOT_SIZE);
 	platform_device_register(&edmini_v2_nor_flash);
 
 	pr_notice("edmini_v2: USB device port, flash write and power-off "
diff --git a/arch/arm/mach-orion5x/kurobox_pro-setup.c b/arch/arm/mach-orion5x/kurobox_pro-setup.c
index aae10e4..fe6a48a 100644
--- a/arch/arm/mach-orion5x/kurobox_pro-setup.c
+++ b/arch/arm/mach-orion5x/kurobox_pro-setup.c
@@ -359,13 +359,17 @@ static void __init kurobox_pro_init(void)
 	orion5x_uart1_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", KUROBOX_PRO_NOR_BOOT_BASE,
-			      KUROBOX_PRO_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    KUROBOX_PRO_NOR_BOOT_BASE,
+				    KUROBOX_PRO_NOR_BOOT_SIZE);
 	platform_device_register(&kurobox_pro_nor_flash);
 
 	if (machine_is_kurobox_pro()) {
-		mvebu_mbus_add_window("devbus-cs0", KUROBOX_PRO_NAND_BASE,
-				      KUROBOX_PRO_NAND_SIZE);
+		mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(0),
+					    ORION_MBUS_DEVBUS_ATTR(0),
+					    KUROBOX_PRO_NAND_BASE,
+					    KUROBOX_PRO_NAND_SIZE);
 		platform_device_register(&kurobox_pro_nand_flash);
 	}
 
diff --git a/arch/arm/mach-orion5x/ls-chl-setup.c b/arch/arm/mach-orion5x/ls-chl-setup.c
index 6234977..028ea03 100644
--- a/arch/arm/mach-orion5x/ls-chl-setup.c
+++ b/arch/arm/mach-orion5x/ls-chl-setup.c
@@ -294,8 +294,10 @@ static void __init lschl_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LSCHL_NOR_BOOT_BASE,
-			      LSCHL_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LSCHL_NOR_BOOT_BASE,
+				    LSCHL_NOR_BOOT_SIZE);
 	platform_device_register(&lschl_nor_flash);
 
 	platform_device_register(&lschl_leds);
diff --git a/arch/arm/mach-orion5x/ls_hgl-setup.c b/arch/arm/mach-orion5x/ls_hgl-setup.c
index fe04c4b..32b7129 100644
--- a/arch/arm/mach-orion5x/ls_hgl-setup.c
+++ b/arch/arm/mach-orion5x/ls_hgl-setup.c
@@ -243,8 +243,10 @@ static void __init ls_hgl_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LS_HGL_NOR_BOOT_BASE,
-			      LS_HGL_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LS_HGL_NOR_BOOT_BASE,
+				    LS_HGL_NOR_BOOT_SIZE);
 	platform_device_register(&ls_hgl_nor_flash);
 
 	platform_device_register(&ls_hgl_button_device);
diff --git a/arch/arm/mach-orion5x/lsmini-setup.c b/arch/arm/mach-orion5x/lsmini-setup.c
index ca4dbe9..a6493e7 100644
--- a/arch/arm/mach-orion5x/lsmini-setup.c
+++ b/arch/arm/mach-orion5x/lsmini-setup.c
@@ -244,8 +244,10 @@ static void __init lsmini_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LSMINI_NOR_BOOT_BASE,
-			      LSMINI_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LSMINI_NOR_BOOT_BASE,
+				    LSMINI_NOR_BOOT_SIZE);
 	platform_device_register(&lsmini_nor_flash);
 
 	platform_device_register(&lsmini_button_device);
diff --git a/arch/arm/mach-orion5x/mss2-setup.c b/arch/arm/mach-orion5x/mss2-setup.c
index 827acba..e105130 100644
--- a/arch/arm/mach-orion5x/mss2-setup.c
+++ b/arch/arm/mach-orion5x/mss2-setup.c
@@ -241,8 +241,10 @@ static void __init mss2_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", MSS2_NOR_BOOT_BASE,
-			      MSS2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    MSS2_NOR_BOOT_BASE,
+				    MSS2_NOR_BOOT_SIZE);
 	platform_device_register(&mss2_nor_flash);
 
 	platform_device_register(&mss2_button_device);
diff --git a/arch/arm/mach-orion5x/mv2120-setup.c b/arch/arm/mach-orion5x/mv2120-setup.c
index 92600ae..e032f01 100644
--- a/arch/arm/mach-orion5x/mv2120-setup.c
+++ b/arch/arm/mach-orion5x/mv2120-setup.c
@@ -204,8 +204,10 @@ static void __init mv2120_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", MV2120_NOR_BOOT_BASE,
-			      MV2120_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    MV2120_NOR_BOOT_BASE,
+				    MV2120_NOR_BOOT_SIZE);
 	platform_device_register(&mv2120_nor_flash);
 
 	platform_device_register(&mv2120_button_device);
diff --git a/arch/arm/mach-orion5x/net2big-setup.c b/arch/arm/mach-orion5x/net2big-setup.c
index dd0641a..ba73dc7 100644
--- a/arch/arm/mach-orion5x/net2big-setup.c
+++ b/arch/arm/mach-orion5x/net2big-setup.c
@@ -397,8 +397,10 @@ static void __init net2big_init(void)
 	net2big_sata_power_init();
 	orion5x_sata_init(&net2big_sata_data);
 
-	mvebu_mbus_add_window("devbus-boot", NET2BIG_NOR_BOOT_BASE,
-			      NET2BIG_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    NET2BIG_NOR_BOOT_BASE,
+				    NET2BIG_NOR_BOOT_SIZE);
 	platform_device_register(&net2big_nor_flash);
 
 	platform_device_register(&net2big_gpio_buttons);
diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion5x/pci.c
index 5033680..7fab670 100644
--- a/arch/arm/mach-orion5x/pci.c
+++ b/arch/arm/mach-orion5x/pci.c
@@ -157,11 +157,10 @@ static int __init pcie_setup(struct pci_sys_data *sys)
 	if (dev == MV88F5181_DEV_ID || dev == MV88F5182_DEV_ID) {
 		printk(KERN_NOTICE "Applying Orion-1/Orion-NAS PCIe config "
 				   "read transaction workaround\n");
-		mvebu_mbus_add_window_remap_flags("pcie0.0",
-						  ORION5X_PCIE_WA_PHYS_BASE,
-						  ORION5X_PCIE_WA_SIZE,
-						  MVEBU_MBUS_NO_REMAP,
-						  MVEBU_MBUS_PCI_WA);
+		mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_WA_TARGET,
+					    ORION_MBUS_PCIE_WA_ATTR,
+					    ORION5X_PCIE_WA_PHYS_BASE,
+					    ORION5X_PCIE_WA_SIZE);
 		pcie_ops.read = pcie_rd_conf_wa;
 	}
 
diff --git a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
index 1c4498b..213b3e1 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
@@ -123,8 +123,10 @@ static void __init rd88f5181l_fxo_init(void)
 	orion5x_eth_switch_init(&rd88f5181l_fxo_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5181L_FXO_NOR_BOOT_BASE,
-			      RD88F5181L_FXO_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5181L_FXO_NOR_BOOT_BASE,
+				    RD88F5181L_FXO_NOR_BOOT_SIZE);
 	platform_device_register(&rd88f5181l_fxo_nor_boot_flash);
 }
 
diff --git a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
index adabe34..594800e 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
@@ -130,8 +130,10 @@ static void __init rd88f5181l_ge_init(void)
 	orion5x_i2c_init();
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5181L_GE_NOR_BOOT_BASE,
-			      RD88F5181L_GE_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5181L_GE_NOR_BOOT_BASE,
+				    RD88F5181L_GE_NOR_BOOT_SIZE);
 	platform_device_register(&rd88f5181l_ge_nor_boot_flash);
 
 	i2c_register_board_info(0, &rd88f5181l_ge_i2c_rtc, 1);
diff --git a/arch/arm/mach-orion5x/rd88f5182-setup.c b/arch/arm/mach-orion5x/rd88f5182-setup.c
index 66e77ec..b1cf684 100644
--- a/arch/arm/mach-orion5x/rd88f5182-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5182-setup.c
@@ -264,11 +264,14 @@ static void __init rd88f5182_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5182_NOR_BOOT_BASE,
-			      RD88F5182_NOR_BOOT_SIZE);
-
-	mvebu_mbus_add_window("devbus-cs1", RD88F5182_NOR_BASE,
-			      RD88F5182_NOR_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5182_NOR_BOOT_BASE,
+				    RD88F5182_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(1),
+				    ORION_MBUS_DEVBUS_ATTR(1),
+				    RD88F5182_NOR_BASE,
+				    RD88F5182_NOR_SIZE);
 	platform_device_register(&rd88f5182_nor_flash);
 	platform_device_register(&rd88f5182_gpio_leds);
 
diff --git a/arch/arm/mach-orion5x/terastation_pro2-setup.c b/arch/arm/mach-orion5x/terastation_pro2-setup.c
index a0bfa53..7e90648 100644
--- a/arch/arm/mach-orion5x/terastation_pro2-setup.c
+++ b/arch/arm/mach-orion5x/terastation_pro2-setup.c
@@ -329,8 +329,10 @@ static void __init tsp2_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", TSP2_NOR_BOOT_BASE,
-			      TSP2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    TSP2_NOR_BOOT_BASE,
+				    TSP2_NOR_BOOT_SIZE);
 	platform_device_register(&tsp2_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/ts209-setup.c b/arch/arm/mach-orion5x/ts209-setup.c
index 80174f0..e90c061 100644
--- a/arch/arm/mach-orion5x/ts209-setup.c
+++ b/arch/arm/mach-orion5x/ts209-setup.c
@@ -286,8 +286,10 @@ static void __init qnap_ts209_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", QNAP_TS209_NOR_BOOT_BASE,
-			      QNAP_TS209_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    QNAP_TS209_NOR_BOOT_BASE,
+				    QNAP_TS209_NOR_BOOT_SIZE);
 	platform_device_register(&qnap_ts209_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/ts409-setup.c b/arch/arm/mach-orion5x/ts409-setup.c
index 9259279..5c079d3 100644
--- a/arch/arm/mach-orion5x/ts409-setup.c
+++ b/arch/arm/mach-orion5x/ts409-setup.c
@@ -277,8 +277,10 @@ static void __init qnap_ts409_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", QNAP_TS409_NOR_BOOT_BASE,
-			      QNAP_TS409_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    QNAP_TS409_NOR_BOOT_BASE,
+				    QNAP_TS409_NOR_BOOT_SIZE);
 	platform_device_register(&qnap_ts409_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/wnr854t-setup.c b/arch/arm/mach-orion5x/wnr854t-setup.c
index 6b84863..80a56ee 100644
--- a/arch/arm/mach-orion5x/wnr854t-setup.c
+++ b/arch/arm/mach-orion5x/wnr854t-setup.c
@@ -127,8 +127,10 @@ static void __init wnr854t_init(void)
 	orion5x_eth_switch_init(&wnr854t_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", WNR854T_NOR_BOOT_BASE,
-			      WNR854T_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    WNR854T_NOR_BOOT_BASE,
+				    WNR854T_NOR_BOOT_SIZE);
 	platform_device_register(&wnr854t_nor_flash);
 }
 
diff --git a/arch/arm/mach-orion5x/wrt350n-v2-setup.c b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
index fae684b..670e30d 100644
--- a/arch/arm/mach-orion5x/wrt350n-v2-setup.c
+++ b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
@@ -213,8 +213,10 @@ static void __init wrt350n_v2_init(void)
 	orion5x_eth_switch_init(&wrt350n_v2_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", WRT350N_V2_NOR_BOOT_BASE,
-			      WRT350N_V2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    WRT350N_V2_NOR_BOOT_BASE,
+				    WRT350N_V2_NOR_BOOT_SIZE);
 	platform_device_register(&wrt350n_v2_nor_flash);
 	platform_device_register(&wrt350n_v2_leds);
 	platform_device_register(&wrt350n_v2_button_device);
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:10 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:10 -0300
Subject: [PATCH v8 06/28] ARM: dove: Move to ID based window creation
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-7-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/mach-dove/common.c | 68 ++++++++++++++++++++++++++++++---------------
 1 file changed, 45 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 00247c7..bc22056 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -27,6 +27,22 @@
 #include <plat/time.h>
 #include "common.h"
 
+/* These can go away once Dove uses the mvebu-mbus DT binding */
+#define DOVE_MBUS_PCIE0_MEM_TARGET    0x4
+#define DOVE_MBUS_PCIE0_MEM_ATTR      0xe8
+#define DOVE_MBUS_PCIE0_IO_TARGET     0x4
+#define DOVE_MBUS_PCIE0_IO_ATTR       0xe0
+#define DOVE_MBUS_PCIE1_MEM_TARGET    0x8
+#define DOVE_MBUS_PCIE1_MEM_ATTR      0xe8
+#define DOVE_MBUS_PCIE1_IO_TARGET     0x8
+#define DOVE_MBUS_PCIE1_IO_ATTR       0xe0
+#define DOVE_MBUS_CESA_TARGET         0x3
+#define DOVE_MBUS_CESA_ATTR           0x1
+#define DOVE_MBUS_BOOTROM_TARGET      0x1
+#define DOVE_MBUS_BOOTROM_ATTR        0xfd
+#define DOVE_MBUS_SCRATCHPAD_TARGET   0xd
+#define DOVE_MBUS_SCRATCHPAD_ATTR     0x0
+
 /*****************************************************************************
  * I/O Address Mapping
  ****************************************************************************/
@@ -332,34 +348,40 @@ void __init dove_setup_cpu_wins(void)
 {
 	/*
 	 * The PCIe windows will no longer be statically allocated
-	 * here once Dove is migrated to the pci-mvebu driver.
+	 * here once Dove is migrated to the pci-mvebu driver. The
+	 * non-PCIe windows will no longer be created here once Dove
+	 * fully moves to DT.
 	 */
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
+	mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE0_IO_TARGET,
+					  DOVE_MBUS_PCIE0_IO_ATTR,
 					  DOVE_PCIE0_IO_PHYS_BASE,
 					  DOVE_PCIE0_IO_SIZE,
-					  DOVE_PCIE0_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
+					  DOVE_PCIE0_IO_BUS_BASE);
+	mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE1_IO_TARGET,
+					  DOVE_MBUS_PCIE1_IO_ATTR,
 					  DOVE_PCIE1_IO_PHYS_BASE,
 					  DOVE_PCIE1_IO_SIZE,
-					  DOVE_PCIE1_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
-					  DOVE_PCIE0_MEM_PHYS_BASE,
-					  DOVE_PCIE0_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
-					  DOVE_PCIE1_MEM_PHYS_BASE,
-					  DOVE_PCIE1_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window("cesa", DOVE_CESA_PHYS_BASE,
-			      DOVE_CESA_SIZE);
-	mvebu_mbus_add_window("bootrom", DOVE_BOOTROM_PHYS_BASE,
-			      DOVE_BOOTROM_SIZE);
-	mvebu_mbus_add_window("scratchpad", DOVE_SCRATCHPAD_PHYS_BASE,
-			      DOVE_SCRATCHPAD_SIZE);
+					  DOVE_PCIE1_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE0_MEM_TARGET,
+				    DOVE_MBUS_PCIE0_MEM_ATTR,
+				    DOVE_PCIE0_MEM_PHYS_BASE,
+				    DOVE_PCIE0_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE1_MEM_TARGET,
+				    DOVE_MBUS_PCIE1_MEM_ATTR,
+				    DOVE_PCIE1_MEM_PHYS_BASE,
+				    DOVE_PCIE1_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_CESA_TARGET,
+				    DOVE_MBUS_CESA_ATTR,
+				    DOVE_CESA_PHYS_BASE,
+				    DOVE_CESA_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_BOOTROM_TARGET,
+				    DOVE_MBUS_BOOTROM_ATTR,
+				    DOVE_BOOTROM_PHYS_BASE,
+				    DOVE_BOOTROM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_SCRATCHPAD_TARGET,
+				    DOVE_MBUS_SCRATCHPAD_ATTR,
+				    DOVE_SCRATCHPAD_PHYS_BASE,
+				    DOVE_SCRATCHPAD_SIZE);
 }
 
 void __init dove_init(void)
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:11 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:11 -0300
Subject: [PATCH v8 07/28] bus: mvebu-mbus: Factor out initialization details
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-8-git-send-email-ezequiel.garcia@free-electrons.com>

We introduce a common initialization function mvebu_mbus_common_init()
that will be used by both legacy and device-tree initialization code.
This patch is an intermediate step, which will allow to introduce the
DT binding for this driver in a less intrusive way.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 47 ++++++++++++++++++++++++++++++-----------------
 1 file changed, 30 insertions(+), 17 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 827468a..1b17954 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -847,26 +847,14 @@ static __init int mvebu_mbus_debugfs_init(void)
 }
 fs_initcall(mvebu_mbus_debugfs_init);
 
-int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
-			   size_t mbuswins_size,
-			   phys_addr_t sdramwins_phys_base,
-			   size_t sdramwins_size)
+static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
+					 phys_addr_t mbuswins_phys_base,
+					 size_t mbuswins_size,
+					 phys_addr_t sdramwins_phys_base,
+					 size_t sdramwins_size)
 {
-	struct mvebu_mbus_state *mbus = &mbus_state;
-	const struct of_device_id *of_id;
 	int win;
 
-	for (of_id = of_mvebu_mbus_ids; of_id->compatible; of_id++)
-		if (!strcmp(of_id->compatible, soc))
-			break;
-
-	if (!of_id->compatible) {
-		pr_err("could not find a matching SoC family\n");
-		return -ENODEV;
-	}
-
-	mbus->soc = of_id->data;
-
 	mbus->mbuswins_base = ioremap(mbuswins_phys_base, mbuswins_size);
 	if (!mbus->mbuswins_base)
 		return -ENOMEM;
@@ -887,3 +875,28 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 
 	return 0;
 }
+
+int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
+			   size_t mbuswins_size,
+			   phys_addr_t sdramwins_phys_base,
+			   size_t sdramwins_size)
+{
+	const struct of_device_id *of_id;
+
+	for (of_id = of_mvebu_mbus_ids; of_id->compatible; of_id++)
+		if (!strcmp(of_id->compatible, soc))
+			break;
+
+	if (!of_id->compatible) {
+		pr_err("could not find a matching SoC family\n");
+		return -ENODEV;
+	}
+
+	mbus_state.soc = of_id->data;
+
+	return mvebu_mbus_common_init(&mbus_state,
+			mbuswins_phys_base,
+			mbuswins_size,
+			sdramwins_phys_base,
+			sdramwins_size);
+}
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:12 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:12 -0300
Subject: [PATCH v8 08/28] bus: mvebu-mbus: Introduce device tree binding
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-9-git-send-email-ezequiel.garcia@free-electrons.com>

This patch adds the most fundamental device-tree initialization.
We only introduce what's required to be able to probe the mvebu-mbus
driver from the DT. Follow-up patches will extend the device tree binding,
allowing to describe static address decoding windows.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mbus.h     |  1 +
 2 files changed, 50 insertions(+)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 1b17954..44a07c4 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -900,3 +900,52 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 			sdramwins_phys_base,
 			sdramwins_size);
 }
+
+#ifdef CONFIG_OF
+int __init mvebu_mbus_dt_init(void)
+{
+	struct resource mbuswins_res, sdramwins_res;
+	struct device_node *np, *controller;
+	const struct of_device_id *of_id;
+	const __be32 *prop;
+	int ret;
+
+	np = of_find_matching_node(NULL, of_mvebu_mbus_ids);
+	if (!np) {
+		pr_err("could not find a matching SoC family\n");
+		return -ENODEV;
+	}
+
+	of_id = of_match_node(of_mvebu_mbus_ids, np);
+	mbus_state.soc = of_id->data;
+
+	prop = of_get_property(np, "controller", NULL);
+	if (!prop) {
+		pr_err("required 'controller' property missing\n");
+		return -EINVAL;
+	}
+
+	controller = of_find_node_by_phandle(be32_to_cpup(prop));
+	if (!controller) {
+		pr_err("could not find an 'mbus-controller' node\n");
+		return -ENODEV;
+	}
+
+	if (of_address_to_resource(controller, 0, &mbuswins_res)) {
+		pr_err("cannot get MBUS register address\n");
+		return -EINVAL;
+	}
+
+	if (of_address_to_resource(controller, 1, &sdramwins_res)) {
+		pr_err("cannot get SDRAM register address\n");
+		return -EINVAL;
+	}
+
+	ret = mvebu_mbus_common_init(&mbus_state,
+				     mbuswins_res.start,
+				     resource_size(&mbuswins_res),
+				     sdramwins_res.start,
+				     resource_size(&sdramwins_res));
+	return ret;
+}
+#endif
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 9245b66..eadefd6 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -74,5 +74,6 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size);
 int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
 		    size_t mbus_size, phys_addr_t sdram_phys_base,
 		    size_t sdram_size);
+int mvebu_mbus_dt_init(void);
 
 #endif /* __LINUX_MBUS_H */
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:13 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:13 -0300
Subject: [PATCH v8 09/28] bus: mvebu-mbus: Add static window allocation to the
 DT binding
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-10-git-send-email-ezequiel.garcia@free-electrons.com>

This patch adds static window allocation to the device tree binding.
Each first-child of the mbus-compatible node, with a suitable 'ranges'
property, declaring an address translation, will trigger an address
decoding window allocation.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
Changes from v7:
 * Allow nodes with no ranges property

 .../devicetree/bindings/bus/mvebu-mbus.txt         | 253 +++++++++++++++++++++
 drivers/bus/mvebu-mbus.c                           | 127 ++++++++++-
 2 files changed, 379 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt

diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
new file mode 100644
index 0000000..cce863f
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -0,0 +1,253 @@
+
+* Marvell MBus
+
+Required properties:
+
+- compatible:	 Should be set to one of the following:
+		 marvell,armada370-mbus
+		 marvell,armadaxp-mbus
+
+- address-cells: Must be '2'. The first cell for the MBus ID encoding,
+                 the second cell for the address offset within the window.
+
+- size-cells:    Must be '1'.
+
+- ranges:        Must be set up to provide a proper translation for each child.
+	         See the examples below.
+
+- controller:    Contains a single phandle referring to the MBus controller
+                 node. This allows to specify the node that contains the
+		 registers that control the MBus, which is typically contained
+		 within the internal register window (see below).
+
+* Marvell MBus controller
+
+Required properties:
+
+- compatible:	Should be set to "marvell,mbus-controller".
+
+- reg:          Device's register space.
+		Two entries are expected (see the examples below):
+		the first one controls the devices decoding window and
+		the second one controls the SDRAM decoding window.
+
+Example:
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+
+		internal-regs {
+			compatible = "simple-bus";
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* more children ...*/
+		};
+	};
+
+** MBus address decoding window specification
+
+The MBus children address space is comprised of two cells: the first one for
+the window ID and the second one for the offset within the window.
+In order to allow to describe valid and non-valid window entries, the
+following encoding is used:
+
+  0xSIAA0000 0x00oooooo
+
+Where:
+
+  S = 0x0 for a MBus valid window
+  S = 0xf for a non-valid window (see below)
+
+If S = 0x0, then:
+
+   I = 4-bit window target ID
+  AA = windpw attribute
+
+If S = 0xf, then:
+
+   I = don't care
+   AA = 1 for internal register
+
+Following the above encoding, for each ranges entry for a MBus valid window
+(S = 0x0), an address decoding window is allocated. On the other side,
+entries for translation that do not correspond to valid windows (S = 0xf)
+are skipped.
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+
+		ranges = <0xf0010000 0 0 0xd0000000 0x100000
+			  0x01e00000 0 0 0xfff00000 0x100000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <0x01e00000 0 0x100000>;
+		};
+
+		/* other children */
+		...
+
+		internal-regs {
+			compatible = "simple-bus";
+			ranges = <0 0xf0010000 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* more children ...*/
+		};
+	};
+
+In the shown example, the translation entry in the 'ranges' property is what
+makes the MBus driver create a static decoding window for the corresponding
+given child device. Note that the binding does not require child nodes to be
+present. Of course, child nodes are needed to probe the devices.
+
+Since each window is identified by its target ID and attribute ID there's
+a special macro that can be use to simplify the translation entries:
+
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
+Using this macro, the above example would be:
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+
+		ranges = < MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			   MBUS_ID(0x01, 0xe0) 0 0 0xfff00000 0x100000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
+		};
+
+		/* other children */
+		...
+
+		internal-regs {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* other children */
+			...
+		};
+	};
+
+
+** About the window base address
+
+Remember the MBus controller allows a great deal of flexibility for choosing
+the decoding window base address. When planning the device tree layout it's
+possible to choose any address as the base address, provided of course there's
+a region large enough available, and with the required alignment.
+
+Yet in other words: there's nothing preventing us from setting a base address
+of 0xf0000000, or 0xd0000000 for the NOR device shown above, if such region is
+unused.
+
+** Window allocation policy
+
+The mbus-node ranges property defines a set of mbus windows that are expected
+to be set by the operating system and that are guaranteed to be free of overlaps
+with one another or with the system memory ranges.
+
+Each entry in the property refers to exactly one window. If the operating system
+choses to use a different set of mbus windows, it must ensure that any address
+translations performed from downstream devices are adapted accordingly.
+
+The operating system may insert additional mbus windows that do not conflict
+with the ones listed in the ranges, e.g. for mapping PCIe devices.
+As a special case, the internal register window must be set up by the boot
+loader at the address listed in the ranges property, since access to that region
+is needed to set up the other windows.
+
+** Example
+
+See the example below, where a more complete device tree is shown:
+
+	soc {
+		compatible = "marvell,armadaxp-mbus", "simple-bus";
+		controller = <&mbusc>;
+
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
+		};
+
+		devbus-bootcs {
+			status = "okay";
+			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;
+
+			/* NOR */
+			nor {
+				compatible = "cfi-flash";
+				reg = <0 0x8000000>;
+				bank-width = <2>;
+			};
+		};
+
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "okay";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
+				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>;
+
+
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+		};
+
+		internal-regs {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			interrupt-controller at 20000 {
+			      reg = <0x20a00 0x2d0>, <0x21070 0x58>;
+			};
+		};
+	};
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 44a07c4..78b8c04 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -902,6 +902,127 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 }
 
 #ifdef CONFIG_OF
+/*
+ * The window IDs in the ranges DT property have the following format:
+ *  - bits 28 to 31: MBus custom field
+ *  - bits 24 to 27: window target ID
+ *  - bits 16 to 23: window attribute ID
+ *  - bits  0 to 15: unused
+ */
+#define CUSTOM(id) (((id) & 0xF0000000) >> 24)
+#define TARGET(id) (((id) & 0x0F000000) >> 24)
+#define ATTR(id)   (((id) & 0x00FF0000) >> 16)
+
+static int __init mbus_dt_setup_win(struct mvebu_mbus_state *mbus,
+				    u32 base, u32 size,
+				    u8 target, u8 attr)
+{
+	const struct mvebu_mbus_mapping *map = mbus->soc->map;
+	const char *name;
+	int i;
+
+	/* Search for a suitable window in the existing mappings */
+	for (i = 0; map[i].name; i++)
+		if (map[i].target == target &&
+		    map[i].attr == (attr & map[i].attrmask))
+			break;
+
+	name = map[i].name;
+	if (!name) {
+		pr_err("window 0x%x:0x%x is unknown, skipping\n",
+		       target, attr);
+		return -EINVAL;
+	}
+
+	if (!mvebu_mbus_window_conflicts(mbus, base, size, target, attr)) {
+		pr_err("cannot add window '%s', conflicts with another window\n",
+		       name);
+		return -EBUSY;
+	}
+
+	if (mvebu_mbus_alloc_window(mbus, base, size, MVEBU_MBUS_NO_REMAP,
+				    target, attr)) {
+		pr_err("cannot add window '%s', too many windows\n",
+		       name);
+		return -ENOMEM;
+	}
+	return 0;
+}
+
+static int __init
+mbus_parse_ranges(struct device_node *node,
+		  int *addr_cells, int *c_addr_cells, int *c_size_cells,
+		  int *cell_count, const __be32 **ranges_start,
+		  const __be32 **ranges_end)
+{
+	const __be32 *prop;
+	int ranges_len, tuple_len;
+
+	/* Allow a node with no 'ranges' property */
+	*ranges_start = of_get_property(node, "ranges", &ranges_len);
+	if (*ranges_start == NULL) {
+		*addr_cells = *c_addr_cells = *c_size_cells = *cell_count = 0;
+		*ranges_start = *ranges_end = NULL;
+		return 0;
+	}
+	*ranges_end = *ranges_start + ranges_len / sizeof(__be32);
+
+	*addr_cells = of_n_addr_cells(node);
+
+	prop = of_get_property(node, "#address-cells", NULL);
+	*c_addr_cells = be32_to_cpup(prop);
+
+	prop = of_get_property(node, "#size-cells", NULL);
+	*c_size_cells = be32_to_cpup(prop);
+
+	*cell_count = *addr_cells + *c_addr_cells + *c_size_cells;
+	tuple_len = (*cell_count) * sizeof(__be32);
+
+	if (ranges_len % tuple_len) {
+		pr_warn("malformed ranges entry '%s'\n", node->name);
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static int __init mbus_dt_setup(struct mvebu_mbus_state *mbus,
+				struct device_node *np)
+{
+	int addr_cells, c_addr_cells, c_size_cells;
+	int i, ret, cell_count;
+	const __be32 *r, *ranges_start, *ranges_end;
+
+	ret = mbus_parse_ranges(np, &addr_cells, &c_addr_cells,
+				&c_size_cells, &cell_count,
+				&ranges_start, &ranges_end);
+	if (ret < 0)
+		return ret;
+
+	for (i = 0, r = ranges_start; r < ranges_end; r += cell_count, i++) {
+		u32 windowid, base, size;
+		u8 target, attr;
+
+		/*
+		 * An entry with a non-zero custom field do not
+		 * correspond to a static window, so skip it.
+		 */
+		windowid = of_read_number(r, 1);
+		if (CUSTOM(windowid))
+			continue;
+
+		target = TARGET(windowid);
+		attr = ATTR(windowid);
+
+		base = of_read_number(r + c_addr_cells, addr_cells);
+		size = of_read_number(r + c_addr_cells + addr_cells,
+				      c_size_cells);
+		ret = mbus_dt_setup_win(mbus, base, size, target, attr);
+		if (ret < 0)
+			return ret;
+	}
+	return 0;
+}
+
 int __init mvebu_mbus_dt_init(void)
 {
 	struct resource mbuswins_res, sdramwins_res;
@@ -946,6 +1067,10 @@ int __init mvebu_mbus_dt_init(void)
 				     resource_size(&mbuswins_res),
 				     sdramwins_res.start,
 				     resource_size(&sdramwins_res));
-	return ret;
+	if (ret)
+		return ret;
+
+	/* Setup statically declared windows in the DT */
+	return mbus_dt_setup(&mbus_state, np);
 }
 #endif
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:14 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:14 -0300
Subject: [PATCH v8 10/28] bus: mvebu-mbus: Add new API for the PCIe memory and
 IO aperture
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-11-git-send-email-ezequiel.garcia@free-electrons.com>

We add two optional properties to the MBus DT binding, to encode
the PCIe memory and IO aperture. This allows such information to
be retrieved by -for instance- the pci driver to allocate the
MBus decoding windows.

Correspondingly, and in order to retrieve this information,
we add two new APIs.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 .../devicetree/bindings/bus/mvebu-mbus.txt         | 14 +++++++
 drivers/bus/mvebu-mbus.c                           | 49 ++++++++++++++++++++++
 include/linux/mbus.h                               |  4 ++
 3 files changed, 67 insertions(+)

diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
index cce863f..960186f 100644
--- a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -20,6 +20,18 @@ Required properties:
 		 registers that control the MBus, which is typically contained
 		 within the internal register window (see below).
 
+Optional properties:
+
+- pcie-mem-aperture:	This optional property contains the aperture for
+			the memory region of the PCIe driver.
+			If it's defined, it must encode the base address and
+			size for the address decoding windows allocated for
+			the PCIe memory region.
+
+- pcie-io-aperture:	Just as explained for the above property, this
+			optional property contains the aperture for the
+			I/O region of the PCIe driver.
+
 * Marvell MBus controller
 
 Required properties:
@@ -38,6 +50,8 @@ Example:
 		#address-cells = <2>;
 		#size-cells = <1>;
 		controller = <&mbusc>;
+		pcie-mem-aperture = <0xe0000000 0x8000000>;
+		pcie-io-aperture  = <0xe8000000 0x100000>;
 
 		internal-regs {
 			compatible = "simple-bus";
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 78b8c04..929fed1 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -142,6 +142,8 @@ struct mvebu_mbus_state {
 	struct dentry *debugfs_root;
 	struct dentry *debugfs_sdram;
 	struct dentry *debugfs_devs;
+	struct resource pcie_mem_aperture;
+	struct resource pcie_io_aperture;
 	const struct mvebu_mbus_soc_data *soc;
 	int hw_io_coherency;
 };
@@ -821,6 +823,20 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size)
 	return 0;
 }
 
+void mvebu_mbus_get_pcie_mem_aperture(struct resource *res)
+{
+	if (!res)
+		return;
+	*res = mbus_state.pcie_mem_aperture;
+}
+
+void mvebu_mbus_get_pcie_io_aperture(struct resource *res)
+{
+	if (!res)
+		return;
+	*res = mbus_state.pcie_io_aperture;
+}
+
 static __init int mvebu_mbus_debugfs_init(void)
 {
 	struct mvebu_mbus_state *s = &mbus_state;
@@ -1023,6 +1039,35 @@ static int __init mbus_dt_setup(struct mvebu_mbus_state *mbus,
 	return 0;
 }
 
+static void __init mvebu_mbus_get_pcie_resources(struct device_node *np,
+						 struct resource *mem,
+						 struct resource *io)
+{
+	u32 reg[2];
+	int ret;
+
+	/*
+	 * These are optional, so we clear them and they'll
+	 * be zero if they are missing from the DT.
+	 */
+	memset(mem, 0, sizeof(struct resource));
+	memset(io, 0, sizeof(struct resource));
+
+	ret = of_property_read_u32_array(np, "pcie-mem-aperture", reg, ARRAY_SIZE(reg));
+	if (!ret) {
+		mem->start = reg[0];
+		mem->end = mem->start + reg[1];
+		mem->flags = IORESOURCE_MEM;
+	}
+
+	ret = of_property_read_u32_array(np, "pcie-io-aperture", reg, ARRAY_SIZE(reg));
+	if (!ret) {
+		io->start = reg[0];
+		io->end = io->start + reg[1];
+		io->flags = IORESOURCE_IO;
+	}
+}
+
 int __init mvebu_mbus_dt_init(void)
 {
 	struct resource mbuswins_res, sdramwins_res;
@@ -1062,6 +1107,10 @@ int __init mvebu_mbus_dt_init(void)
 		return -EINVAL;
 	}
 
+	/* Get optional pcie-{mem,io}-aperture properties */
+	mvebu_mbus_get_pcie_resources(np, &mbus_state.pcie_mem_aperture,
+					  &mbus_state.pcie_io_aperture);
+
 	ret = mvebu_mbus_common_init(&mbus_state,
 				     mbuswins_res.start,
 				     resource_size(&mbuswins_res),
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index eadefd6..650bc15 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -11,6 +11,8 @@
 #ifndef __LINUX_MBUS_H
 #define __LINUX_MBUS_H
 
+struct resource;
+
 struct mbus_dram_target_info
 {
 	/*
@@ -59,6 +61,8 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
 }
 #endif
 
+void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
+void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
 int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 				      size_t size, phys_addr_t remap,
 				      unsigned int flags);
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:15 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:15 -0300
Subject: [PATCH v8 11/28] PCI: mvebu: Adapt to the new device tree layout
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-12-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

The new device tree layout encodes the window's target ID and attribute
in the PCIe controller node's ranges property. This allows to parse
such entries to obtain such information and use the recently introduced
MBus API to create the windows, instead of using the current name based
scheme.

Acked-by: Bjorn Helgaas <bhelgaas at google.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../devicetree/bindings/pci/mvebu-pci.txt          | 145 ++++++++++++++++-----
 drivers/pci/host/pci-mvebu.c                       | 113 +++++++++++-----
 2 files changed, 193 insertions(+), 65 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index f8d4058..9556e2f 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -1,6 +1,7 @@
 * Marvell EBU PCIe interfaces
 
 Mandatory properties:
+
 - compatible: one of the following values:
     marvell,armada-370-pcie
     marvell,armada-xp-pcie
@@ -10,11 +11,49 @@ Mandatory properties:
 - #interrupt-cells, set to <1>
 - bus-range: PCI bus numbers covered
 - device_type, set to "pci"
-- ranges: ranges for the PCI memory and I/O regions, as well as the
-  MMIO registers to control the PCIe interfaces.
+- ranges: ranges describing the MMIO registers to control the PCIe
+  interfaces, and ranges describing the MBus windows needed to access
+  the memory and I/O regions of each PCIe interface.
+
+The ranges describing the MMIO registers have the following layout:
+
+    0x82000000 0 r MBUS_ID(0xf0, 0x01) r 0 s
+
+where:
+
+  * r is a 32-bits value that gives the offset of the MMIO
+  registers of this PCIe interface, from the base of the internal
+  registers.
+
+  * s is a 32-bits value that give the size of this MMIO
+  registers area. This range entry translates the '0x82000000 0 r' PCI
+  address into the 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part
+  of the internal register window (as identified by MBUS_ID(0xf0,
+  0x01)).
+
+The ranges describing the MBus windows have the following layout:
+
+    0x8t000000 s 0     MBUS_ID(w, a) 0 1 0
+
+where:
+
+   * t is the type of the MBus window (as defined by the standard PCI DT
+   bindings), 1 for I/O and 2 for memory.
 
-In addition, the Device Tree node must have sub-nodes describing each
+   * s is the PCI slot that corresponds to this PCIe interface
+
+   * w is the 'target ID' value for the MBus window
+
+   * a the 'attribute' value for the MBus window.
+
+Since the location and size of the different MBus windows is not fixed in
+hardware, and only determined in runtime, those ranges cover the full first
+4 GB of the physical address space, and do not translate into a valid CPU
+address.
+
+In addition, the device tree node must have sub-nodes describing each
 PCIe interface, having the following mandatory properties:
+
 - reg: used only for interrupt mapping, so only the first four bytes
   are used to refer to the correct bus number and device number.
 - assigned-addresses: reference to the MMIO registers used to control
@@ -26,7 +65,8 @@ PCIe interface, having the following mandatory properties:
 - #address-cells, set to <3>
 - #size-cells, set to <2>
 - #interrupt-cells, set to <1>
-- ranges, empty property.
+- ranges, translating the MBus windows ranges of the parent node into
+  standard PCI addresses.
 - interrupt-map-mask and interrupt-map, standard PCI properties to
   define the mapping of the PCIe interface to interrupt numbers.
 
@@ -47,27 +87,50 @@ pcie-controller {
 
 	bus-range = <0x00 0xff>;
 
-	ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
-		  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
-		  0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
-		  0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
-		  0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
-		  0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
-		  0x82000000 0 0xd0082000 0xd0082000 0 0x00002000   /* Port 3.0 registers */
-		  0x82000000 0 0xd0084000 0xd0084000 0 0x00002000   /* Port 1.1 registers */
-		  0x82000000 0 0xd0088000 0xd0088000 0 0x00002000   /* Port 1.2 registers */
-		  0x82000000 0 0xd008c000 0xd008c000 0 0x00002000   /* Port 1.3 registers */
-		  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-		  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
+	ranges =
+	       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000	/* Port 0.0 registers */
+		0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000	/* Port 2.0 registers */
+		0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000	/* Port 0.1 registers */
+		0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000	/* Port 0.2 registers */
+		0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000	/* Port 0.3 registers */
+		0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000	/* Port 1.0 registers */
+		0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000	/* Port 3.0 registers */
+		0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000	/* Port 1.1 registers */
+		0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000	/* Port 1.2 registers */
+		0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000	/* Port 1.3 registers */
+		0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+		0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+		0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+		0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+		0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+		0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+		0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+		0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+
+		0x82000000 0x5 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
+		0x81000000 0x5 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
+		0x82000000 0x6 0     MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */
+		0x81000000 0x6 0     MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO  */
+		0x82000000 0x7 0     MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */
+		0x81000000 0x7 0     MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO  */
+		0x82000000 0x8 0     MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */
+		0x81000000 0x8 0     MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO  */
+
+		0x82000000 0x9 0     MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
+		0x81000000 0x9 0     MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */
+
+		0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
+		0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
 
 	pcie at 1,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+		assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
 		reg = <0x0800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+			  0x81000000 0 0 0x81000000 0x1 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 58>;
 		marvell,pcie-port = <0>;
@@ -78,12 +141,13 @@ pcie-controller {
 
 	pcie at 2,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>;
+		assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
 		reg = <0x1000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+			  0x81000000 0 0 0x81000000 0x2 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 59>;
 		marvell,pcie-port = <0>;
@@ -94,12 +158,13 @@ pcie-controller {
 
 	pcie at 3,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>;
+		assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
 		reg = <0x1800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+			  0x81000000 0 0 0x81000000 0x3 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 60>;
 		marvell,pcie-port = <0>;
@@ -110,12 +175,13 @@ pcie-controller {
 
 	pcie at 4,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>;
+		assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
 		reg = <0x2000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+			  0x81000000 0 0 0x81000000 0x4 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 61>;
 		marvell,pcie-port = <0>;
@@ -126,12 +192,13 @@ pcie-controller {
 
 	pcie at 5,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
+		assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
 		reg = <0x2800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
+			  0x81000000 0 0 0x81000000 0x5 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 62>;
 		marvell,pcie-port = <1>;
@@ -142,12 +209,13 @@ pcie-controller {
 
 	pcie at 6,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>;
+		assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
 		reg = <0x3000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0
+			  0x81000000 0 0 0x81000000 0x6 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 63>;
 		marvell,pcie-port = <1>;
@@ -158,12 +226,13 @@ pcie-controller {
 
 	pcie at 7,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>;
+		assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
 		reg = <0x3800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0
+			  0x81000000 0 0 0x81000000 0x7 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 64>;
 		marvell,pcie-port = <1>;
@@ -174,12 +243,13 @@ pcie-controller {
 
 	pcie at 8,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>;
+		assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
 		reg = <0x4000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0
+			  0x81000000 0 0 0x81000000 0x8 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 65>;
 		marvell,pcie-port = <1>;
@@ -187,14 +257,16 @@ pcie-controller {
 		clocks = <&gateclk 12>;
 		status = "disabled";
 	};
+
 	pcie at 9,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>;
+		assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
 		reg = <0x4800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+			  0x81000000 0 0 0x81000000 0x9 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 99>;
 		marvell,pcie-port = <2>;
@@ -205,12 +277,13 @@ pcie-controller {
 
 	pcie at 10,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>;
+		assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
 		reg = <0x5000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
+			  0x81000000 0 0 0x81000000 0xa 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 103>;
 		marvell,pcie-port = <3>;
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 13a633b..424a7b8 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -123,6 +123,10 @@ struct mvebu_pcie_port {
 	u32 port;
 	u32 lane;
 	int devfn;
+	unsigned int mem_target;
+	unsigned int mem_attr;
+	unsigned int io_target;
+	unsigned int io_attr;
 	struct clk *clk;
 	struct mvebu_sw_pci_bridge bridge;
 	struct device_node *dn;
@@ -307,10 +311,9 @@ static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port *port)
 			    (port->bridge.iolimitupper << 16)) -
 			    iobase);
 
-	mvebu_mbus_add_window_remap_flags(port->name, port->iowin_base,
-					  port->iowin_size,
-					  iobase,
-					  MVEBU_MBUS_PCI_IO);
+	mvebu_mbus_add_window_remap_by_id(port->io_target, port->io_attr,
+					  port->iowin_base, port->iowin_size,
+					  iobase);
 
 	pci_ioremap_io(iobase, port->iowin_base);
 }
@@ -342,10 +345,8 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
 		(((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) -
 		port->memwin_base;
 
-	mvebu_mbus_add_window_remap_flags(port->name, port->memwin_base,
-					  port->memwin_size,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+	mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr,
+				    port->memwin_base, port->memwin_size);
 }
 
 /*
@@ -755,12 +756,54 @@ mvebu_pcie_map_registers(struct platform_device *pdev,
 	return devm_request_and_ioremap(&pdev->dev, &regs);
 }
 
+#define DT_FLAGS_TO_TYPE(flags)       (((flags) >> 24) & 0x03)
+#define    DT_TYPE_IO                 0x1
+#define    DT_TYPE_MEM32              0x2
+#define DT_CPUADDR_TO_TARGET(cpuaddr) (((cpuaddr) >> 56) & 0xFF)
+#define DT_CPUADDR_TO_ATTR(cpuaddr)   (((cpuaddr) >> 48) & 0xFF)
+
+static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
+			      unsigned long type, int *tgt, int *attr)
+{
+	const int na = 3, ns = 2;
+	const __be32 *range;
+	int rlen, nranges, rangesz, pna, i;
+
+	range = of_get_property(np, "ranges", &rlen);
+	if (!range)
+		return -EINVAL;
+
+	pna = of_n_addr_cells(np);
+	rangesz = pna + na + ns;
+	nranges = rlen / sizeof(__be32) / rangesz;
+
+	for (i = 0; i < nranges; i++) {
+		u32 flags = of_read_number(range, 1);
+		u32 slot = of_read_number(range, 2);
+		u64 cpuaddr = of_read_number(range + na, pna);
+		unsigned long rtype;
+
+		if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_IO)
+			rtype = IORESOURCE_IO;
+		else if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_MEM32)
+			rtype = IORESOURCE_MEM;
+
+		if (slot == PCI_SLOT(devfn) && type == rtype) {
+			*tgt = DT_CPUADDR_TO_TARGET(cpuaddr);
+			*attr = DT_CPUADDR_TO_ATTR(cpuaddr);
+			return 0;
+		}
+
+		range += rangesz;
+	}
+
+	return -ENOENT;
+}
+
 static int __init mvebu_pcie_probe(struct platform_device *pdev)
 {
 	struct mvebu_pcie *pcie;
 	struct device_node *np = pdev->dev.of_node;
-	struct of_pci_range range;
-	struct of_pci_range_parser parser;
 	struct device_node *child;
 	int i, ret;
 
@@ -771,29 +814,25 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
 
 	pcie->pdev = pdev;
 
-	if (of_pci_range_parser_init(&parser, np))
+	/* Get the PCIe memory and I/O aperture */
+	mvebu_mbus_get_pcie_mem_aperture(&pcie->mem);
+	if (resource_size(&pcie->mem) == 0) {
+		dev_err(&pdev->dev, "invalid memory aperture size\n");
 		return -EINVAL;
+	}
 
-	/* Get the I/O and memory ranges from DT */
-	for_each_of_pci_range(&parser, &range) {
-		unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
-		if (restype == IORESOURCE_IO) {
-			of_pci_range_to_resource(&range, np, &pcie->io);
-			of_pci_range_to_resource(&range, np, &pcie->realio);
-			pcie->io.name = "I/O";
-			pcie->realio.start = max_t(resource_size_t,
-						   PCIBIOS_MIN_IO,
-						   range.pci_addr);
-			pcie->realio.end = min_t(resource_size_t,
-						 IO_SPACE_LIMIT,
-						 range.pci_addr + range.size);
-		}
-		if (restype == IORESOURCE_MEM) {
-			of_pci_range_to_resource(&range, np, &pcie->mem);
-			pcie->mem.name = "MEM";
-		}
+	mvebu_mbus_get_pcie_io_aperture(&pcie->io);
+	if (resource_size(&pcie->io) == 0) {
+		dev_err(&pdev->dev, "invalid I/O aperture size\n");
+		return -EINVAL;
 	}
 
+	pcie->realio.flags = pcie->io.flags;
+	pcie->realio.start = PCIBIOS_MIN_IO;
+	pcie->realio.end = min_t(resource_size_t,
+				  IO_SPACE_LIMIT,
+				  resource_size(&pcie->io));
+
 	/* Get the bus range */
 	ret = of_pci_parse_bus_range(np, &pcie->busn);
 	if (ret) {
@@ -841,6 +880,22 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
 		if (port->devfn < 0)
 			continue;
 
+		ret = mvebu_get_tgt_attr(np, port->devfn, IORESOURCE_MEM,
+					 &port->mem_target, &port->mem_attr);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "PCIe%d.%d: cannot get tgt/attr for mem window\n",
+				port->port, port->lane);
+			continue;
+		}
+
+		ret = mvebu_get_tgt_attr(np, port->devfn, IORESOURCE_IO,
+					 &port->io_target, &port->io_attr);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "PCIe%d.%d: cannot get tgt/attr for io window\n",
+				port->port, port->lane);
+			continue;
+		}
+
 		port->base = mvebu_pcie_map_registers(pdev, child, port);
 		if (!port->base) {
 			dev_err(&pdev->dev, "PCIe%d.%d: cannot map registers\n",
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:16 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:16 -0300
Subject: [PATCH v8 12/28] PCI: mvebu: Check valid base address before port
 setup
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-13-git-send-email-ezequiel.garcia@free-electrons.com>

This driver does not fail to probe when it cannot obtain
a port base address. Therefore, add a check for NULL base address
before setting up the port, which prevents a kernel panic in such
cases.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 drivers/pci/host/pci-mvebu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 424a7b8..338691b 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -662,6 +662,8 @@ static int __init mvebu_pcie_setup(int nr, struct pci_sys_data *sys)
 
 	for (i = 0; i < pcie->nports; i++) {
 		struct mvebu_pcie_port *port = &pcie->ports[i];
+		if (!port->base)
+			continue;
 		mvebu_pcie_setup_hw(port);
 	}
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:17 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:17 -0300
Subject: [PATCH v8 13/28] bus: mvebu-mbus: Remove the no longer used
 name-based API
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-14-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Now that every user of the deprecated name-based API has been
converted to using the ID-based API, let's remove the former one.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 38 --------------------------------------
 include/linux/mbus.h     |  5 -----
 2 files changed, 43 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 929fed1..b4a7382 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -766,44 +766,6 @@ int mvebu_mbus_add_window_remap_by_id(unsigned int target,
 	return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
 }
 
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
-				      size_t size, phys_addr_t remap,
-				      unsigned int flags)
-{
-	struct mvebu_mbus_state *s = &mbus_state;
-	u8 target, attr;
-	int i;
-
-	if (!s->soc->map)
-		return -ENODEV;
-
-	for (i = 0; s->soc->map[i].name; i++)
-		if (!strcmp(s->soc->map[i].name, devname))
-			break;
-
-	if (!s->soc->map[i].name) {
-		pr_err("unknown device '%s'\n", devname);
-		return -ENODEV;
-	}
-
-	target = s->soc->map[i].target;
-	attr   = s->soc->map[i].attr;
-
-	if (flags == MVEBU_MBUS_PCI_MEM)
-		attr |= 0x8;
-	else if (flags == MVEBU_MBUS_PCI_WA)
-		attr |= 0x28;
-
-	return mvebu_mbus_add_window_remap_by_id(target, attr, base,
-						 size, remap);
-}
-
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
-{
-	return mvebu_mbus_add_window_remap_flags(devname, base, size,
-						 MVEBU_MBUS_NO_REMAP, 0);
-}
-
 int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
 				phys_addr_t base, size_t size)
 {
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 650bc15..345b8c5 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -63,15 +63,10 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
 
 void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
 void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
-				      size_t size, phys_addr_t remap,
-				      unsigned int flags);
 int mvebu_mbus_add_window_remap_by_id(unsigned int target,
 				      unsigned int attribute,
 				      phys_addr_t base, size_t size,
 				      phys_addr_t remap);
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
-			  size_t size);
 int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
 				phys_addr_t base, size_t size);
 int mvebu_mbus_del_window(phys_addr_t base, size_t size);
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:19 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:19 -0300
Subject: [PATCH v8 15/28] bus: mvebu-mbus: Update main description
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-16-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

After replacing the MBus name-based by the new ID-based API
let's fix the general description of the driver at the beginning
of the file.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index c182ef5..26af145 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -35,13 +35,9 @@
  *
  * - Provides an API for platform code or device drivers to
  *   dynamically add or remove address decoding windows for the CPU ->
- *   device accesses. This API is mvebu_mbus_add_window(),
- *   mvebu_mbus_add_window_remap_flags() and
- *   mvebu_mbus_del_window(). Since the (target, attribute) values
- *   differ from one SoC family to another, the API uses a 'const char
- *   *' string to identify devices, and this driver is responsible for
- *   knowing the mapping between the name of a device and its
- *   corresponding (target, attribute) in the current SoC family.
+ *   device accesses. This API is mvebu_mbus_add_window_by_id(),
+ *   mvebu_mbus_add_window_remap_by_id() and
+ *   mvebu_mbus_del_window().
  *
  * - Provides a debugfs interface in /sys/kernel/debug/mvebu-mbus/ to
  *   see the list of CPU -> SDRAM windows and their configuration
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:18 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:18 -0300
Subject: [PATCH v8 14/28] bus: mvebu-mbus: Remove name -> target,
 attribute mapping tables
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-15-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

This tables were used together with the name-based MBus window
creation API. Since that's has been removed, we can also remove
the tables.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 150 +++--------------------------------------------
 1 file changed, 7 insertions(+), 143 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index b4a7382..c182ef5 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -97,33 +97,6 @@
 
 #define DOVE_DDR_BASE_CS_OFF(n) ((n) << 4)
 
-struct mvebu_mbus_mapping {
-	const char *name;
-	u8 target;
-	u8 attr;
-	u8 attrmask;
-};
-
-/*
- * Masks used for the 'attrmask' field of mvebu_mbus_mapping. They
- * allow to get the real attribute value, discarding the special bits
- * used to select a PCI MEM region or a PCI WA region. This allows the
- * debugfs code to reverse-match the name of a device from its
- * target/attr values.
- *
- * For all devices except PCI, all bits of 'attr' must be
- * considered. For most SoCs, only bit 3 should be ignored (it allows
- * to select between PCI MEM and PCI I/O). On Orion5x however, there
- * is the special bit 5 to select a PCI WA region.
- */
-#define MAPDEF_NOMASK       0xff
-#define MAPDEF_PCIMASK      0xf7
-#define MAPDEF_ORIONPCIMASK 0xd7
-
-/* Macro used to define one mvebu_mbus_mapping entry */
-#define MAPDEF(__n, __t, __a, __m) \
-	{ .name = __n, .target = __t, .attr = __a, .attrmask = __m }
-
 struct mvebu_mbus_state;
 
 struct mvebu_mbus_soc_data {
@@ -133,7 +106,6 @@ struct mvebu_mbus_soc_data {
 	void (*setup_cpu_target)(struct mvebu_mbus_state *s);
 	int (*show_cpu_target)(struct mvebu_mbus_state *s,
 			       struct seq_file *seq, void *v);
-	const struct mvebu_mbus_mapping *map;
 };
 
 struct mvebu_mbus_state {
@@ -430,8 +402,7 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void *v)
 		u64 wbase, wremap;
 		u32 wsize;
 		u8 wtarget, wattr;
-		int enabled, i;
-		const char *name;
+		int enabled;
 
 		mvebu_mbus_read_window(mbus, win,
 				       &enabled, &wbase, &wsize,
@@ -442,18 +413,9 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void *v)
 			continue;
 		}
 
-
-		for (i = 0; mbus->soc->map[i].name; i++)
-			if (mbus->soc->map[i].target == wtarget &&
-			    mbus->soc->map[i].attr ==
-			    (wattr & mbus->soc->map[i].attrmask))
-				break;
-
-		name = mbus->soc->map[i].name ?: "unknown";
-
-		seq_printf(seq, "[%02d] %016llx - %016llx : %s",
+		seq_printf(seq, "[%02d] %016llx - %016llx : %04x:%04x",
 			   win, (unsigned long long)wbase,
-			   (unsigned long long)(wbase + wsize), name);
+			   (unsigned long long)(wbase + wsize), wtarget, wattr);
 
 		if (win < mbus->soc->num_remappable_wins) {
 			seq_printf(seq, " (remap %016llx)\n",
@@ -578,45 +540,12 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
 	mvebu_mbus_dram_info.num_cs = cs;
 }
 
-static const struct mvebu_mbus_mapping armada_370_map[] = {
-	MAPDEF("bootrom",     1, 0xe0, MAPDEF_NOMASK),
-	MAPDEF("devbus-boot", 1, 0x2f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x3e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x3d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x3b, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs3",  1, 0x37, MAPDEF_NOMASK),
-	MAPDEF("pcie0.0",     4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",     8, 0xe0, MAPDEF_PCIMASK),
-	{},
-};
-
 static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
 	.num_wins            = 20,
 	.num_remappable_wins = 8,
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = armada_370_map,
-};
-
-static const struct mvebu_mbus_mapping armada_xp_map[] = {
-	MAPDEF("bootrom",     1, 0x1d, MAPDEF_NOMASK),
-	MAPDEF("devbus-boot", 1, 0x2f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x3e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x3d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x3b, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs3",  1, 0x37, MAPDEF_NOMASK),
-	MAPDEF("pcie0.0",     4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.1",     4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.2",     4, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.3",     4, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",     8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.1",     8, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.2",     8, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.3",     8, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie2.0",     4, 0xf0, MAPDEF_PCIMASK),
-	MAPDEF("pcie3.0",     8, 0xf0, MAPDEF_PCIMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
@@ -625,15 +554,6 @@ static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = armada_xp_map,
-};
-
-static const struct mvebu_mbus_mapping kirkwood_map[] = {
-	MAPDEF("pcie0.0", 4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0", 4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("sram",    3, 0x01, MAPDEF_NOMASK),
-	MAPDEF("nand",    1, 0x2f, MAPDEF_NOMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data kirkwood_mbus_data = {
@@ -642,16 +562,6 @@ static const struct mvebu_mbus_soc_data kirkwood_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = kirkwood_map,
-};
-
-static const struct mvebu_mbus_mapping dove_map[] = {
-	MAPDEF("pcie0.0",    0x4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",    0x8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("cesa",       0x3, 0x01, MAPDEF_NOMASK),
-	MAPDEF("bootrom",    0x1, 0xfd, MAPDEF_NOMASK),
-	MAPDEF("scratchpad", 0xd, 0x0, MAPDEF_NOMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data dove_mbus_data = {
@@ -660,18 +570,6 @@ static const struct mvebu_mbus_soc_data dove_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_dove_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_dove,
-	.map                 = dove_map,
-};
-
-static const struct mvebu_mbus_mapping orion5x_map[] = {
-	MAPDEF("pcie0.0",     4, 0x51, MAPDEF_ORIONPCIMASK),
-	MAPDEF("pci0.0",      3, 0x51, MAPDEF_ORIONPCIMASK),
-	MAPDEF("devbus-boot", 1, 0x0f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x1e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x1d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x1b, MAPDEF_NOMASK),
-	MAPDEF("sram",        0, 0x00, MAPDEF_NOMASK),
-	{},
 };
 
 /*
@@ -684,7 +582,6 @@ static const struct mvebu_mbus_soc_data orion5x_4win_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = orion5x_map,
 };
 
 static const struct mvebu_mbus_soc_data orion5x_2win_mbus_data = {
@@ -693,21 +590,6 @@ static const struct mvebu_mbus_soc_data orion5x_2win_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = orion5x_map,
-};
-
-static const struct mvebu_mbus_mapping mv78xx0_map[] = {
-	MAPDEF("pcie0.0", 4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.1", 4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.2", 4, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.3", 4, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0", 8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.1", 8, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.2", 8, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.3", 8, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie2.0", 4, 0xf0, MAPDEF_PCIMASK),
-	MAPDEF("pcie3.0", 8, 0xf0, MAPDEF_PCIMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
@@ -716,7 +598,6 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
 	.win_cfg_offset      = mv78xx0_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = mv78xx0_map,
 };
 
 /*
@@ -895,33 +776,16 @@ static int __init mbus_dt_setup_win(struct mvebu_mbus_state *mbus,
 				    u32 base, u32 size,
 				    u8 target, u8 attr)
 {
-	const struct mvebu_mbus_mapping *map = mbus->soc->map;
-	const char *name;
-	int i;
-
-	/* Search for a suitable window in the existing mappings */
-	for (i = 0; map[i].name; i++)
-		if (map[i].target == target &&
-		    map[i].attr == (attr & map[i].attrmask))
-			break;
-
-	name = map[i].name;
-	if (!name) {
-		pr_err("window 0x%x:0x%x is unknown, skipping\n",
-		       target, attr);
-		return -EINVAL;
-	}
-
 	if (!mvebu_mbus_window_conflicts(mbus, base, size, target, attr)) {
-		pr_err("cannot add window '%s', conflicts with another window\n",
-		       name);
+		pr_err("cannot add window '%04x:%04x', conflicts with another window\n",
+		       target, attr);
 		return -EBUSY;
 	}
 
 	if (mvebu_mbus_alloc_window(mbus, base, size, MVEBU_MBUS_NO_REMAP,
 				    target, attr)) {
-		pr_err("cannot add window '%s', too many windows\n",
-		       name);
+		pr_err("cannot add window '%04x:%04x', too many windows\n",
+		       target, attr);
 		return -ENOMEM;
 	}
 	return 0;
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:20 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:20 -0300
Subject: [PATCH v8 16/28] bus: mvebu-mbus: Factorize Armada 370/XP data
 structures
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-17-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

These structures were only different in the mapping tables.
Now that those tables have been removed, it doesn't make any sense
to keep different structures.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 26af145..19ab6ff 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -536,15 +536,7 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
 	mvebu_mbus_dram_info.num_cs = cs;
 }
 
-static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
-	.num_wins            = 20,
-	.num_remappable_wins = 8,
-	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
-	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
-	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-};
-
-static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
+static const struct mvebu_mbus_soc_data armada_370_xp_mbus_data = {
 	.num_wins            = 20,
 	.num_remappable_wins = 8,
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
@@ -604,9 +596,9 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
  */
 static const struct of_device_id of_mvebu_mbus_ids[] = {
 	{ .compatible = "marvell,armada370-mbus",
-	  .data = &armada_370_mbus_data, },
+	  .data = &armada_370_xp_mbus_data, },
 	{ .compatible = "marvell,armadaxp-mbus",
-	  .data = &armada_xp_mbus_data, },
+	  .data = &armada_370_xp_mbus_data, },
 	{ .compatible = "marvell,kirkwood-mbus",
 	  .data = &kirkwood_mbus_data, },
 	{ .compatible = "marvell,dove-mbus",
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:21 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:21 -0300
Subject: [PATCH v8 17/28] ARM: mvebu: Remove the harcoded BootROM window
 allocation
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-18-git-send-email-ezequiel.garcia@free-electrons.com>

The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/mach-mvebu/platsmp.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index ce81d30..7be1ec2 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -21,6 +21,7 @@
 #include <linux/smp.h>
 #include <linux/clk.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/mbus.h>
 #include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
@@ -29,6 +30,9 @@
 #include "pmsu.h"
 #include "coherency.h"
 
+#define AXP_BOOTROM_BASE 0xfff00000
+#define AXP_BOOTROM_SIZE 0x100000
+
 void __init set_secondary_cpus_clock(void)
 {
 	int thiscpu;
@@ -114,10 +118,29 @@ static void __init armada_xp_smp_init_cpus(void)
 
 void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
 {
+	struct device_node *node;
+	struct resource res;
+	int err;
+
 	set_secondary_cpus_clock();
 	flush_cache_all();
 	set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
-	mvebu_mbus_add_window("bootrom", 0xfff00000, SZ_1M);
+
+	/*
+	 * In order to boot the secondary CPUs we need to ensure
+	 * the bootROM is mapped at the correct address.
+	 */
+	node = of_find_compatible_node(NULL, NULL, "marvell,bootrom");
+	if (!node)
+		panic("Cannot find 'marvell,bootrom' compatible node");
+
+	err = of_address_to_resource(node, 0, &res);
+	if (err < 0)
+		panic("Cannot get 'bootrom' node address");
+
+	if (res.start != AXP_BOOTROM_BASE ||
+	    resource_size(&res) != AXP_BOOTROM_SIZE)
+		panic("The address for the BootROM is incorrect");
 }
 
 struct smp_operations armada_xp_smp_ops __initdata = {
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:22 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:22 -0300
Subject: [PATCH v8 18/28] ARM: mvebu: Initialize MBus using the DT binding
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-19-git-send-email-ezequiel.garcia@free-electrons.com>

Now that the mbus device tree binding has been introduced, we can
switch over to it.

Also, and since the initialization of the mbus driver is quite
fundamental for the system to work properly, this patch adds a BUG()
in case mbus fails to initialize.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/mach-mvebu/armada-370-xp.c | 34 +---------------------------------
 1 file changed, 1 insertion(+), 33 deletions(-)

diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 97cbb80..829b573 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -34,44 +34,12 @@ static void __init armada_370_xp_map_io(void)
 	debug_ll_io_init();
 }
 
-/*
- * This initialization will be replaced by a DT-based
- * initialization once the mvebu-mbus driver gains DT support.
- */
-
-#define ARMADA_370_XP_MBUS_WINS_OFFS   0x20000
-#define ARMADA_370_XP_MBUS_WINS_SIZE   0x100
-#define ARMADA_370_XP_SDRAM_WINS_OFFS  0x20180
-#define ARMADA_370_XP_SDRAM_WINS_SIZE  0x20
-
-static void __init armada_370_xp_mbus_init(void)
-{
-	char *mbus_soc_name;
-	struct device_node *dn;
-	const __be32 mbus_wins_offs = cpu_to_be32(ARMADA_370_XP_MBUS_WINS_OFFS);
-	const __be32 sdram_wins_offs = cpu_to_be32(ARMADA_370_XP_SDRAM_WINS_OFFS);
-
-	if (of_machine_is_compatible("marvell,armada370"))
-		mbus_soc_name = "marvell,armada370-mbus";
-	else
-		mbus_soc_name = "marvell,armadaxp-mbus";
-
-	dn = of_find_node_by_name(NULL, "internal-regs");
-	BUG_ON(!dn);
-
-	mvebu_mbus_init(mbus_soc_name,
-			of_translate_address(dn, &mbus_wins_offs),
-			ARMADA_370_XP_MBUS_WINS_SIZE,
-			of_translate_address(dn, &sdram_wins_offs),
-			ARMADA_370_XP_SDRAM_WINS_SIZE);
-}
-
 static void __init armada_370_xp_timer_and_clk_init(void)
 {
 	of_clk_init(NULL);
 	armada_370_xp_timer_init();
 	coherency_init();
-	armada_370_xp_mbus_init();
+	BUG_ON(mvebu_mbus_dt_init());
 #ifdef CONFIG_CACHE_L2X0
 	l2x0_of_init(0, ~0UL);
 #endif
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:25 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:25 -0300
Subject: [PATCH v8 21/28] ARM: mvebu: Add BootROM to Armada 370/XP device tree
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-22-git-send-email-ezequiel.garcia@free-electrons.com>

In order to access the SoC BootROM, we need to declare a mapping
(through a ranges property). The mbus driver will use this property
to allocate a suitable address decoding window.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              | 3 ++-
 arch/arm/boot/dts/armada-370-mirabox.dts         | 3 ++-
 arch/arm/boot/dts/armada-370-rd.dts              | 3 ++-
 arch/arm/boot/dts/armada-370.dtsi                | 5 +++++
 arch/arm/boot/dts/armada-xp-db.dts               | 3 ++-
 arch/arm/boot/dts/armada-xp-gp.dts               | 3 ++-
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 3 ++-
 arch/arm/boot/dts/armada-xp.dtsi                 | 5 +++++
 8 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 5920b4e..90ce29d 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,7 +30,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index a4202b6..19341d2 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,7 +25,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index dd0ba01..0b3acf3 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,7 +28,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 4b54e51..bd21d49 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -31,6 +31,11 @@
 	soc {
 		compatible = "marvell,armada370-mbus", "simple-bus";
 
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
+		};
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 0d4ce54..857f272 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,7 +30,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 2fa9209..934dc46 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,7 +39,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index a3e3a12..1700f6f 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,7 +27,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 8033824..7ba99ce 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -29,6 +29,11 @@
 	soc {
 		compatible = "marvell,armadaxp-mbus", "simple-bus";
 
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
+		};
+
 		internal-regs {
 			L2: l2-cache {
 				compatible = "marvell,aurora-system-cache";
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:23 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:23 -0300
Subject: [PATCH v8 19/28] ARM: mvebu: Use the preprocessor on Armada 370/XP
 device tree files
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-20-git-send-email-ezequiel.garcia@free-electrons.com>

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              | 2 +-
 arch/arm/boot/dts/armada-370-mirabox.dts         | 2 +-
 arch/arm/boot/dts/armada-370-rd.dts              | 2 +-
 arch/arm/boot/dts/armada-370.dtsi                | 2 +-
 arch/arm/boot/dts/armada-xp-db.dts               | 2 +-
 arch/arm/boot/dts/armada-xp-gp.dts               | 2 +-
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         | 2 +-
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         | 2 +-
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 2 +-
 arch/arm/boot/dts/armada-xp.dtsi                 | 2 +-
 10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index beee169..55b986c 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Marvell Armada 370 Evaluation Board";
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 45b1077..37530af 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -9,7 +9,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Globalscale Mirabox";
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index a3a2fed..7aa2171 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -12,7 +12,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Marvell Armada 370 Reference Design";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..08ec6e3 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -15,7 +15,7 @@
  * common to all Armada SoCs.
  */
 
-/include/ "armada-370-xp.dtsi"
+#include "armada-370-xp.dtsi"
 /include/ "skeleton.dtsi"
 
 / {
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index e28e68f..a9bd766 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78460.dtsi"
+#include "armada-xp-mv78460.dtsi"
 
 / {
 	model = "Marvell Armada XP Evaluation Board";
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index c87b2de..54843e5 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78460.dtsi"
+#include "armada-xp-mv78460.dtsi"
 
 / {
 	model = "Marvell Armada XP Development Board DB-MV784MP-GP";
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2d9335d..985373a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -13,7 +13,7 @@
  * common to all Armada XP SoCs.
  */
 
-/include/ "armada-xp.dtsi"
+#include "armada-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP MV78260 SoC";
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index c7b1f4d..f8bf25a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -13,7 +13,7 @@
  * common to all Armada XP SoCs.
  */
 
-/include/ "armada-xp.dtsi"
+#include "armada-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP MV78460 SoC";
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 8f51045..d090264 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -11,7 +11,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78260.dtsi"
+#include "armada-xp-mv78260.dtsi"
 
 / {
 	model = "PlatHome OpenBlocks AX3-4 board";
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 416eb94..8c07bfe 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -16,7 +16,7 @@
  * common to all Armada SoCs.
  */
 
-/include/ "armada-370-xp.dtsi"
+#include "armada-370-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP family SoC";
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:24 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:24 -0300
Subject: [PATCH v8 20/28] ARM: mvebu: Add MBus to Armada 370/XP device tree
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-21-git-send-email-ezequiel.garcia@free-electrons.com>

The Armada 370/XP SoC family has a completely configurable address
space handled by the MBus controller.

This patch introduces the device tree layout of MBus, making the
'soc' node as mbus-compatible.
Since every peripheral/controller is a child of this 'soc' node,
this makes all of them sit behind the mbus, thus describing the
hardware accurately.

A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-db.dts              |  2 ++
 arch/arm/boot/dts/armada-370-mirabox.dts         |  2 ++
 arch/arm/boot/dts/armada-370-rd.dts              |  2 ++
 arch/arm/boot/dts/armada-370-xp.dtsi             | 15 ++++++++++-----
 arch/arm/boot/dts/armada-370.dtsi                |  4 ++--
 arch/arm/boot/dts/armada-xp-db.dts               |  4 +---
 arch/arm/boot/dts/armada-xp-gp.dts               |  4 +---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  4 +---
 arch/arm/boot/dts/armada-xp.dtsi                 |  2 ++
 9 files changed, 23 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 55b986c..5920b4e 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,6 +30,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 37530af..a4202b6 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,6 +25,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index 7aa2171..dd0ba01 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,6 +28,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 90b1176..62639b4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -18,6 +18,8 @@
 
 /include/ "skeleton64.dtsi"
 
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
 / {
 	model = "Marvell Armada 370 and XP SoC";
 	compatible = "marvell,armada-370-xp";
@@ -38,18 +40,21 @@
 	};
 
 	soc {
-		#address-cells = <1>;
+		#address-cells = <2>;
 		#size-cells = <1>;
-		compatible = "simple-bus";
+		controller = <&mbusc>;
 		interrupt-parent = <&mpic>;
-		ranges = <0          0 0xd0000000 0x0100000 /* internal registers */
-			  0xe0000000 0 0xe0000000 0x8100000 /* PCIe */>;
 
 		internal-regs {
 			compatible = "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
-			ranges;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
 
 			mpic: interrupt-controller at 20000 {
 				compatible = "marvell,mpic";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 08ec6e3..4b54e51 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -29,8 +29,8 @@
 	};
 
 	soc {
-		ranges = <0          0xd0000000 0x0100000 /* internal registers */
-			  0xe0000000 0xe0000000 0x8100000 /* PCIe */>;
+		compatible = "marvell,armada370-mbus", "simple-bus";
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index a9bd766..0d4ce54 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,9 +30,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000	/* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000     /* PCIe */
-			  0xf0000000 0 0xf0000000 0x1000000>;	/* Device Bus, NOR 16MiB   */
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 54843e5..2fa9209 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,9 +39,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000  /* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000 /* PCIe */
-			  0xf0000000 0 0xf0000000 0x1000000 /* Device Bus, NOR 16MiB  */>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index d090264..a3e3a12 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,9 +27,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000	/* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000     /* PCIe */
-			  0xf0000000 0 0xf0000000 0x8000000     /* Device Bus, NOR 128MiB   */>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 8c07bfe..8033824 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -27,6 +27,8 @@
 	};
 
 	soc {
+		compatible = "marvell,armadaxp-mbus", "simple-bus";
+
 		internal-regs {
 			L2: l2-cache {
 				compatible = "marvell,aurora-system-cache";
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:28 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:28 -0300
Subject: [PATCH v8 24/28] ARM: kirkwood: Split DT and legacy MBus
 initialization
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-25-git-send-email-ezequiel.garcia@free-electrons.com>

This commit replaces the legacy MBus initialization with the new
DT-based in Kirkwood. For boards that are not yet converted to DT,
we keep the legacy initialization.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/mach-kirkwood/board-dt.c | 1 +
 arch/arm/mach-kirkwood/common.c   | 8 ++++----
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 6e122ed..682b7ac 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -87,6 +87,7 @@ static void __init kirkwood_dt_init(void)
 	 */
 	writel(readl(CPU_CONFIG) & ~CPU_CONFIG_ERROR_PROP, CPU_CONFIG);
 
+	BUG_ON(mvebu_mbus_dt_init());
 	kirkwood_setup_wins();
 
 	kirkwood_l2_init();
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index 165e751..15b7e72 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -534,10 +534,6 @@ void __init kirkwood_cpuidle_init(void)
 void __init kirkwood_init_early(void)
 {
 	orion_time_set_base(TIMER_VIRT_BASE);
-
-	mvebu_mbus_init("marvell,kirkwood-mbus",
-			BRIDGE_WINS_BASE, BRIDGE_WINS_SZ,
-			DDR_WINDOW_CPU_BASE, DDR_WINDOW_CPU_SZ);
 }
 
 int kirkwood_tclk;
@@ -713,6 +709,10 @@ void __init kirkwood_init(void)
 	 */
 	writel(readl(CPU_CONFIG) & ~CPU_CONFIG_ERROR_PROP, CPU_CONFIG);
 
+	BUG_ON(mvebu_mbus_init("marvell,kirkwood-mbus",
+			BRIDGE_WINS_BASE, BRIDGE_WINS_SZ,
+			DDR_WINDOW_CPU_BASE, DDR_WINDOW_CPU_SZ));
+
 	kirkwood_setup_wins();
 
 	kirkwood_l2_init();
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:27 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:27 -0300
Subject: [PATCH v8 23/28] ARM: mvebu: Relocate Armada 370/XP PCIe device tree
 nodes
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-24-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.

Moving the PCIe nodes, we now need to introduce an extra cell to
encode the window target ID and attribute. Since this depends on
the PCIe port, we split the ranges translation entries, to correspond
to each MBus window.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-mirabox.dts         |  32 +-
 arch/arm/boot/dts/armada-370-xp.dtsi             |   2 +
 arch/arm/boot/dts/armada-370.dtsi                | 101 +++---
 arch/arm/boot/dts/armada-xp-db.dts               |  67 ++--
 arch/arm/boot/dts/armada-xp-gp.dts               |  42 +--
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         | 222 ++++++------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         | 261 ++++++++-------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         | 409 ++++++++++++-----------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  18 +-
 9 files changed, 612 insertions(+), 542 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 19341d2..2471d9d 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -28,6 +28,22 @@
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
 			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
+		pcie-controller {
+			status = "okay";
+
+			/* Internal mini-PCIe connector */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+
+			/* Connected on the PCB to a USB 3.0 XHCI controller */
+			pcie at 2,0 {
+				/* Port 1, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
@@ -123,22 +139,6 @@
 					reg = <0x25>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/* Internal mini-PCIe connector */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-
-				/* Connected on the PCB to a USB 3.0 XHCI controller */
-				pcie at 2,0 {
-					/* Port 1, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 073dd20..e984ce6 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -44,6 +44,8 @@
 		#size-cells = <1>;
 		controller = <&mbusc>;
 		interrupt-parent = <&mpic>;
+		pcie-mem-aperture = <0xe0000000 0x8000000>;
+		pcie-io-aperture  = <0xe8000000 0x100000>;
 
 		devbus-bootcs {
 			compatible = "marvell,mvebu-devbus";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index bd21d49..648e530 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -36,6 +36,59 @@
 			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
 		};
 
+		pcie-controller {
+			compatible = "marvell,armada-370-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0       1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0       1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0     MBUS_ID(0x08, 0xe8) 0       1 0 /* Port 1.0 MEM */
+				0x81000000 0x2 0     MBUS_ID(0x08, 0xe0) 0       1 0 /* Port 1.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+                                ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+                                          0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+                                ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+                                          0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 62>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 9>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
@@ -174,54 +227,6 @@
 					0x18304 0x4>;
 				status = "okay";
 			};
-
-			pcie-controller {
-				compatible = "marvell,armada-370-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 62>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 9>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 76ae1a9..bcf6d79 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -62,6 +62,39 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+
+			/*
+			 * All 6 slots are physically present as
+			 * standard PCIe slots on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+			pcie at 2,0 {
+				/* Port 0, Lane 1 */
+				status = "okay";
+			};
+			pcie at 3,0 {
+				/* Port 0, Lane 2 */
+				status = "okay";
+			};
+			pcie at 4,0 {
+				/* Port 0, Lane 3 */
+				status = "okay";
+			};
+			pcie at 9,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+			pcie at 10,0 {
+				/* Port 3, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -155,40 +188,6 @@
 					spi-max-frequency = <20000000>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/*
-				 * All 6 slots are physically present as
-				 * standard PCIe slots on the board.
-				 */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-				pcie at 2,0 {
-					/* Port 0, Lane 1 */
-					status = "okay";
-				};
-				pcie at 3,0 {
-					/* Port 0, Lane 2 */
-					status = "okay";
-				};
-				pcie at 4,0 {
-					/* Port 0, Lane 3 */
-					status = "okay";
-				};
-				pcie at 9,0 {
-					/* Port 2, Lane 0 */
-					status = "okay";
-				};
-				pcie at 10,0 {
-					/* Port 3, Lane 0 */
-					status = "okay";
-				};
-			};
-
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 8c0de20..2298e4a 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -71,6 +71,27 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+
+			/*
+			 * The 3 slots are physically present as
+			 * standard PCIe slots on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+			pcie at 9,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+			pcie at 10,0 {
+				/* Port 3, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -154,27 +175,6 @@
 					spi-max-frequency = <108000000>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/*
-				 * The 3 slots are physically present as
-				 * standard PCIe slots on the board.
-				 */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-				pcie at 9,0 {
-					/* Port 2, Lane 0 */
-					status = "okay";
-				};
-				pcie at 10,0 {
-					/* Port 3, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f8eaa38..f093e39 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -44,6 +44,124 @@
 	};
 
 	soc {
+		/*
+		 * MV78230 has 2 PCIe units Gen2.0: One unit can be
+		 * configured as x4 or quad x1 lanes. One unit is
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000000 0x1 0       MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0       MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0       MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+				0x81000000 0x2 0       MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+				0x82000000 0x3 0       MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+				0x81000000 0x3 0       MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+				0x82000000 0x4 0       MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+				0x81000000 0x4 0       MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+				0x82000000 0x9 0       MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
+				0x81000000 0x9 0       MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+					  0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+					  0x81000000 0 0 0x81000000 0x3 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+					  0x81000000 0 0 0x81000000 0x4 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+					  0x81000000 0 0 0x81000000 0x9 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78230-pinctrl";
@@ -77,110 +195,6 @@
 				#interrupts-cells = <2>;
 				interrupts = <87>, <88>, <89>;
 			};
-
-			/*
-			 * MV78230 has 2 PCIe units Gen2.0: One unit can be
-			 * configured as x4 or quad x1 lanes. One unit is
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-#address-cells = <3>;
-#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 985373a..6dc3921 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -45,6 +45,145 @@
 	};
 
 	soc {
+		/*
+		 * MV78260 has 3 PCIe units Gen2.0: Two units can be
+		 * configured as x4 or quad x1 lanes. One unit is
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000   /* Port 1.0 registers */
+				0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000   /* Port 3.0 registers */
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+				0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+				0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+				0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+				0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+				0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+				0x82000000 0x9 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
+				0x81000000 0x9 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
+				0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
+				0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+                                ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+                                          0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+					  0x81000000 0 0 0x81000000 0x3 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+					  0x81000000 0 0 0x81000000 0x4 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+					  0x81000000 0 0 0x81000000 0x9 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+
+			pcie at 10,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x82000 0 0x2000>;
+				reg = <0x5000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
+					  0x81000000 0 0 0x81000000 0xa 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 103>;
+				marvell,pcie-port = <3>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 27>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78260-pinctrl";
@@ -97,128 +236,6 @@
 				clocks = <&gateclk 1>;
 				status = "disabled";
 			};
-
-			/*
-			 * MV78260 has 3 PCIe units Gen2.0: Two units can be
-			 * configured as x4 or quad x1 lanes. One unit is
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-
-				pcie at 10,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x82000 0 0x2000>;
-					reg = <0x5000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 103>;
-					marvell,pcie-port = <3>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 27>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index f8bf25a..a6661e3 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -61,6 +61,227 @@
 	};
 
 	soc {
+		/*
+		 * MV78460 has 4 PCIe units Gen2.0: Two units can be
+		 * configured as x4 or quad x1 lanes. Two units are
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000   /* Port 1.0 registers */
+				0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000   /* Port 3.0 registers */
+				0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000   /* Port 1.1 registers */
+				0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000   /* Port 1.2 registers */
+				0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000   /* Port 1.3 registers */
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+				0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+				0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+				0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+				0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+				0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+
+				0x82000000 0x5 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
+				0x81000000 0x5 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
+				0x82000000 0x6 0     MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */
+				0x81000000 0x6 0     MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO  */
+				0x82000000 0x7 0     MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */
+				0x81000000 0x7 0     MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO  */
+				0x82000000 0x8 0     MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */
+				0x81000000 0x8 0     MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO  */
+
+				0x82000000 0x9 0     MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
+				0x81000000 0x9 0     MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */
+
+				0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
+				0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+					  0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+					  0x81000000 0 0 0x81000000 0x3 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+					  0x81000000 0 0 0x81000000 0x4 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 5,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
+				reg = <0x2800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
+					  0x81000000 0 0 0x81000000 0x5 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 62>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 9>;
+				status = "disabled";
+			};
+
+			pcie at 6,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
+				reg = <0x3000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0
+					  0x81000000 0 0 0x81000000 0x6 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 63>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 10>;
+				status = "disabled";
+			};
+
+			pcie at 7,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
+				reg = <0x3800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0
+					  0x81000000 0 0 0x81000000 0x7 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 64>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 11>;
+				status = "disabled";
+			};
+
+			pcie at 8,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
+				reg = <0x4000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0
+					  0x81000000 0 0 0x81000000 0x8 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 65>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 12>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+					  0x81000000 0 0 0x81000000 0x9 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+
+			pcie at 10,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
+				reg = <0x5000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
+					  0x81000000 0 0 0x81000000 0xa 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 103>;
+				marvell,pcie-port = <3>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 27>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78460-pinctrl";
@@ -113,194 +334,6 @@
 				clocks = <&gateclk 1>;
 				status = "disabled";
 			};
-
-			/*
-			 * MV78460 has 4 PCIe units Gen2.0: Two units can be
-			 * configured as x4 or quad x1 lanes. Two units are
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
-					0x82000000 0 0x84000 0x84000 0 0x00002000   /* Port 1.1 registers */
-					0x82000000 0 0x88000 0x88000 0 0x00002000   /* Port 1.2 registers */
-					0x82000000 0 0x8c000 0x8c000 0 0x00002000   /* Port 1.3 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 5,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
-					reg = <0x2800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 62>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 9>;
-					status = "disabled";
-				};
-
-				pcie at 6,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
-					reg = <0x3000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 63>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 10>;
-					status = "disabled";
-				};
-
-				pcie at 7,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
-					reg = <0x3800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 64>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 11>;
-					status = "disabled";
-				};
-
-				pcie at 8,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
-					reg = <0x4000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 65>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 12>;
-					status = "disabled";
-				};
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-
-				pcie at 10,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
-					reg = <0x5000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 103>;
-					marvell,pcie-port = <3>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 27>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 2b60ee0..5695afc 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -59,6 +59,15 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+			/* Internal mini-PCIe connector */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -176,15 +185,6 @@
 			usb at 51000 {
 				status = "okay";
 			};
-
-			pcie-controller {
-				status = "okay";
-				/* Internal mini-PCIe connector */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:30 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:30 -0300
Subject: [PATCH v8 26/28] ARM: kirkwood: Introduce MBus DT node
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-27-git-send-email-ezequiel.garcia@free-electrons.com>

Add a minimal MBus node, just to allow the MBus driver to probe.
Follow-up patches will migrate the rest of the nodes appropriately.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/kirkwood.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 9809fc1..83d53b3 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -28,6 +28,11 @@
 		      <0xf1020214 0x04>;
 	};
 
+	mbus {
+		compatible = "marvell,kirkwood-mbus", "simple-bus";
+		controller = <&mbusc>;
+	};
+
 	ocp at f1000000 {
 		compatible = "simple-bus";
 		ranges = <0x00000000 0xf1000000 0x0100000
@@ -37,6 +42,11 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 
+		mbusc: mbus-controller at 20000 {
+			compatible = "marvell,mbus-controller";
+			reg = <0x20000 0x80>, <0x1500 0x20>;
+		};
+
 		core_clk: core-clocks at 10030 {
 			compatible = "marvell,kirkwood-core-clock";
 			reg = <0x10030 0x4>;
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:31 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:31 -0300
Subject: [PATCH v8 27/28] ARM: kirkwood: Introduce MBUS_ID
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-28-git-send-email-ezequiel.garcia@free-electrons.com>

This macro is used to define window's target ID and attribute cells
for the MBus ranges entries.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/kirkwood.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 83d53b3..5003c83 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -1,5 +1,7 @@
 /include/ "skeleton.dtsi"
 
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
 / {
 	compatible = "marvell,kirkwood";
 	interrupt-parent = <&intc>;
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:32 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:32 -0300
Subject: [PATCH v8 28/28] ARM: kirkwood: Relocate PCIe device tree nodes
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-29-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of the ocp node, placing it directly
below the mbus. This is a more accurate representation of the hardware.

Moving the PCIe nodes, we now need to introduce an extra cell to
encode the window target ID and attribute. Since this depends on
the PCIe port, we split the ranges translation entries, to
correspond to each MBus window.

In addition, we encode the PCIe memory and I/O apertures in the MBus
node, according to the MBus DT binding specification. The choice made
is 0xe0000000-0xf0000000 for memory space, and 0xf200000-0xf2100000 for
I/O space. These apertures can be changed in each per-board DT file.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/kirkwood-6281.dtsi               |  66 ++++++-------
 arch/arm/boot/dts/kirkwood-6282.dtsi               | 102 +++++++++++----------
 arch/arm/boot/dts/kirkwood-db-88f6281.dts          |   3 +-
 arch/arm/boot/dts/kirkwood-db-88f6282.dts          |   3 +-
 arch/arm/boot/dts/kirkwood-db.dtsi                 |   8 --
 arch/arm/boot/dts/kirkwood-iconnect.dts            |  19 ++--
 arch/arm/boot/dts/kirkwood-mplcec4.dts             |  19 ++--
 .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  |  19 ++--
 arch/arm/boot/dts/kirkwood-nsa310.dts              |  19 ++--
 arch/arm/boot/dts/kirkwood-ts219-6282.dts          |  19 ++--
 arch/arm/boot/dts/kirkwood-ts219.dtsi              |  17 ++--
 arch/arm/boot/dts/kirkwood.dtsi                    |   5 +-
 12 files changed, 163 insertions(+), 136 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-6281.dtsi b/arch/arm/boot/dts/kirkwood-6281.dtsi
index 1e5bef0..650ef30 100644
--- a/arch/arm/boot/dts/kirkwood-6281.dtsi
+++ b/arch/arm/boot/dts/kirkwood-6281.dtsi
@@ -1,4 +1,39 @@
 / {
+	mbus {
+		pcie-controller {
+			compatible = "marvell,kirkwood-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0       1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0       1 0 /* Port 0.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &intc 9>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gate_clk 2>;
+				status = "disabled";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		pinctrl: pinctrl at 10000 {
 			compatible = "marvell,88f6281-pinctrl";
@@ -41,37 +76,6 @@
 			};
 		};
 
-		pcie-controller {
-			compatible = "marvell,kirkwood-pcie";
-			status = "disabled";
-			device_type = "pci";
-
-			#address-cells = <3>;
-			#size-cells = <2>;
-
-			bus-range = <0x00 0xff>;
-
-			ranges = <0x82000000 0 0x00040000 0x00040000 0 0x00002000   /* Port 0.0 registers */
-				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-			          0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
-
-			pcie at 1,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
-				reg = <0x0800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &intc 9>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gate_clk 2>;
-				status = "disabled";
-			};
-		};
-
 		rtc at 10300 {
 			compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc";
 			reg = <0x10300 0x20>;
diff --git a/arch/arm/boot/dts/kirkwood-6282.dtsi b/arch/arm/boot/dts/kirkwood-6282.dtsi
index a63a111..3933a33 100644
--- a/arch/arm/boot/dts/kirkwood-6282.dtsi
+++ b/arch/arm/boot/dts/kirkwood-6282.dtsi
@@ -1,4 +1,59 @@
 / {
+	mbus {
+		pcie-controller {
+			compatible = "marvell,kirkwood-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
+			        0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0       1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0       1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0       1 0 /* Port 1.0 MEM */
+				0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0       1 0 /* Port 1.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &intc 9>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gate_clk 2>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001000 0 0x00044000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+					  0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &intc 10>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gate_clk 18>;
+				status = "disabled";
+			};
+		};
+	};
 	ocp at f1000000 {
 
 		pinctrl: pinctrl at 10000 {
@@ -94,52 +149,5 @@
 			status = "disabled";
 		};
 
-		pcie-controller {
-			compatible = "marvell,kirkwood-pcie";
-			status = "disabled";
-			device_type = "pci";
-
-			#address-cells = <3>;
-			#size-cells = <2>;
-
-			bus-range = <0x00 0xff>;
-
-			ranges = <0x82000000 0 0x00040000 0x00040000 0 0x00002000   /* Port 0.0 registers */
-			          0x82000000 0 0x00044000 0x00044000 0 0x00002000   /* Port 1.0 registers */
-				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-			          0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
-
-			pcie at 1,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
-				reg = <0x0800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &intc 9>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gate_clk 2>;
-				status = "disabled";
-			};
-
-			pcie at 2,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82001000 0 0x00044000 0 0x2000>;
-				reg = <0x1000 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &intc 10>;
-				marvell,pcie-port = <1>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gate_clk 18>;
-				status = "disabled";
-			};
-		};
 	};
 };
diff --git a/arch/arm/boot/dts/kirkwood-db-88f6281.dts b/arch/arm/boot/dts/kirkwood-db-88f6281.dts
index f420cbe..72c4b0a 100644
--- a/arch/arm/boot/dts/kirkwood-db-88f6281.dts
+++ b/arch/arm/boot/dts/kirkwood-db-88f6281.dts
@@ -18,7 +18,8 @@
 	model = "Marvell DB-88F6281-BP Development Board";
 	compatible = "marvell,db-88f6281-bp", "marvell,kirkwood-88f6281", "marvell,kirkwood";
 
-	ocp at f1000000 {
+	mbus {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>;
 		pcie-controller {
 			status = "okay";
 
diff --git a/arch/arm/boot/dts/kirkwood-db-88f6282.dts b/arch/arm/boot/dts/kirkwood-db-88f6282.dts
index c5df866..36c411d 100644
--- a/arch/arm/boot/dts/kirkwood-db-88f6282.dts
+++ b/arch/arm/boot/dts/kirkwood-db-88f6282.dts
@@ -18,7 +18,8 @@
 	model = "Marvell DB-88F6282-BP Development Board";
 	compatible = "marvell,db-88f6282-bp", "marvell,kirkwood-88f6282", "marvell,kirkwood";
 
-	ocp at f1000000 {
+	mbus {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>;
 		pcie-controller {
 			status = "okay";
 
diff --git a/arch/arm/boot/dts/kirkwood-db.dtsi b/arch/arm/boot/dts/kirkwood-db.dtsi
index 29bd98e..45c1bf7 100644
--- a/arch/arm/boot/dts/kirkwood-db.dtsi
+++ b/arch/arm/boot/dts/kirkwood-db.dtsi
@@ -77,13 +77,5 @@
 			cd-gpios = <&gpio1 6 0>;
 			status = "okay";
 		};
-
-		pcie-controller {
-			status = "okay";
-
-			pcie at 1,0 {
-				status = "okay";
-			};
-		};
 	};
 };
diff --git a/arch/arm/boot/dts/kirkwood-iconnect.dts b/arch/arm/boot/dts/kirkwood-iconnect.dts
index 1a98487..8314118 100644
--- a/arch/arm/boot/dts/kirkwood-iconnect.dts
+++ b/arch/arm/boot/dts/kirkwood-iconnect.dts
@@ -18,6 +18,17 @@
 		linux,initrd-end   = <0x4800000>;
 	};
 
+	mbus {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>;
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		pinctrl: pinctrl at 10000 {
 			pmx_button_reset: pmx-button-reset {
@@ -101,14 +112,6 @@
 				reg = <0x980000 0x1f400000>;
 			};
 		};
-
-		pcie-controller {
-			status = "okay";
-
-			pcie at 1,0 {
-				status = "okay";
-			};
-		};
 	};
 
 	gpio-leds {
diff --git a/arch/arm/boot/dts/kirkwood-mplcec4.dts b/arch/arm/boot/dts/kirkwood-mplcec4.dts
index 382ad99..21f1954 100644
--- a/arch/arm/boot/dts/kirkwood-mplcec4.dts
+++ b/arch/arm/boot/dts/kirkwood-mplcec4.dts
@@ -16,6 +16,17 @@
                 bootargs = "console=ttyS0,115200n8 earlyprintk";
         };
 
+	mbus {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>;
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		pinctrl: pinctrl at 10000 {
 			pmx_led_health: pmx-led-health {
@@ -134,14 +145,6 @@
 			cd-gpios = <&gpio1 15 1>;
 			/* No WP GPIO */
 		};
-
-		pcie-controller {
-			status = "okay";
-
-			pcie at 1,0 {
-				status = "okay";
-			};
-		};
 	};
 
 	gpio-leds {
diff --git a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
index 8be68bd..84ff31c 100644
--- a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
+++ b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
@@ -16,6 +16,17 @@
 		bootargs = "console=ttyS0,115200n8 earlyprintk";
 	};
 
+	mbus {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>;
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		pinctrl: pinctrl at 10000 {
 			pmx_button_power: pmx-button-power {
@@ -101,14 +112,6 @@
 			status = "okay";
 			nr-ports = <2>;
 		};
-
-		pcie-controller {
-			status = "okay";
-
-			pcie at 1,0 {
-				status = "okay";
-			};
-		};
 	};
 
 	gpio-leds {
diff --git a/arch/arm/boot/dts/kirkwood-nsa310.dts b/arch/arm/boot/dts/kirkwood-nsa310.dts
index 8fd683c..bd7f05f 100644
--- a/arch/arm/boot/dts/kirkwood-nsa310.dts
+++ b/arch/arm/boot/dts/kirkwood-nsa310.dts
@@ -16,6 +16,17 @@
 		bootargs = "console=ttyS0,115200";
 	};
 
+	mbus {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>;
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		pinctrl: pinctrl at 10000 {
 			pinctrl-0 = <&pmx_unknown>;
@@ -162,14 +173,6 @@
 				reg = <0x5040000 0x2fc0000>;
 			};
 		};
-
-		pcie-controller {
-			status = "okay";
-
-			pcie at 1,0 {
-				status = "okay";
-			};
-		};
 	};
 
 	gpio_keys {
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
index 7d6cc86..04f6fe1 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -5,6 +5,17 @@
 #include "kirkwood-ts219.dtsi"
 
 / {
+	mbus {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>;
+		pcie-controller {
+			status = "okay";
+
+			pcie at 2,0 {
+				status = "okay";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		pinctrl: pinctrl at 10000 {
 
@@ -30,14 +41,6 @@
 				marvell,function = "gpio";
 			};
 		};
-		pcie-controller {
-			status = "okay";
-
-			pcie at 2,0 {
-				status = "okay";
-			};
-		};
-
 	};
 
 	gpio_keys {
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
index 0c9a94c..7019cf6 100644
--- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -11,6 +11,16 @@
 		bootargs = "console=ttyS0,115200n8";
 	};
 
+	mbus {
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		i2c at 11000 {
 			status = "okay";
@@ -87,12 +97,5 @@
 			status = "okay";
 			nr-ports = <2>;
 		};
-		pcie-controller {
-			status = "okay";
-
-			pcie at 1,0 {
-				status = "okay";
-			};
-		};
 	};
 };
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 5003c83..70f414d 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -32,13 +32,16 @@
 
 	mbus {
 		compatible = "marvell,kirkwood-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
 		controller = <&mbusc>;
+		pcie-mem-aperture = <0xe0000000 0x10000000>; /* 256 MiB memory space */
+		pcie-io-aperture  = <0xf2000000 0x100000>;   /*   1 MiB    I/O space */
 	};
 
 	ocp at f1000000 {
 		compatible = "simple-bus";
 		ranges = <0x00000000 0xf1000000 0x0100000
-		          0xe0000000 0xe0000000 0x8100000 /* PCIE */
 		          0xf4000000 0xf4000000 0x0000400
 		          0xf5000000 0xf5000000 0x0000400>;
 		#address-cells = <1>;
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:26 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:26 -0300
Subject: [PATCH v8 22/28] ARM: mvebu: Relocate Armada 370/XP DeviceBus device
 tree nodes
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-23-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus has been added to the device tree, it's possible to
move the DeviceBus out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the hardware.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi             | 94 +++++++++++++-----------
 arch/arm/boot/dts/armada-xp-db.dts               | 59 +++++++--------
 arch/arm/boot/dts/armada-xp-gp.dts               | 60 +++++++--------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 65 ++++++++--------
 4 files changed, 140 insertions(+), 138 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 62639b4..073dd20 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -45,6 +45,56 @@
 		controller = <&mbusc>;
 		interrupt-parent = <&mpic>;
 
+		devbus-bootcs {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs0 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs1 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs2 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs3 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
 		internal-regs {
 			compatible = "simple-bus";
 			#address-cells = <1>;
@@ -200,50 +250,6 @@
 				status = "disabled";
 			};
 
-			devbus-bootcs at 10400 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10400 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs0 at 10408 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10408 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs1 at 10410 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10410 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs2 at 10418 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10418 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs3 at 10420 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10420 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
 		};
 	};
  };
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 857f272..76ae1a9 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -31,7 +31,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x1000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -160,34 +189,6 @@
 				};
 			};
 
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x1000000>;
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 16 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x1000000>;
-					bank-width = <2>;
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 934dc46..8c0de20 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -40,7 +40,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x1000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -126,35 +155,6 @@
 				};
 			};
 
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf000000, size 0x1000000 */
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 16 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x1000000>;
-					bank-width = <2>;
-				};
-			};
-
 			pcie-controller {
 				status = "okay";
 
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 1700f6f..2b60ee0 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -28,7 +28,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 128 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x8000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -148,40 +177,6 @@
 				status = "okay";
 			};
 
-			/* USB interface in the mini-PCIe connector */
-			usb at 52000 {
-				status = "okay";
-			};
-
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x8000000>; /* @addr 0xf000000, size 0x8000000 */
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 128 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x8000000>;
-					bank-width = <2>;
-				};
-			};
-
 			pcie-controller {
 				status = "okay";
 				/* Internal mini-PCIe connector */
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 09:31:29 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 10:31:29 -0300
Subject: [PATCH v8 25/28] ARM: kirkwood: Use the preprocessor on device tree
 files
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374586292-4941-26-git-send-email-ezequiel.garcia@free-electrons.com>

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
---
 arch/arm/boot/dts/kirkwood-cloudbox.dts                | 4 ++--
 arch/arm/boot/dts/kirkwood-db-88f6281.dts              | 4 ++--
 arch/arm/boot/dts/kirkwood-db-88f6282.dts              | 4 ++--
 arch/arm/boot/dts/kirkwood-db.dtsi                     | 2 +-
 arch/arm/boot/dts/kirkwood-dns320.dts                  | 2 +-
 arch/arm/boot/dts/kirkwood-dns325.dts                  | 2 +-
 arch/arm/boot/dts/kirkwood-dnskw.dtsi                  | 4 ++--
 arch/arm/boot/dts/kirkwood-dockstar.dts                | 4 ++--
 arch/arm/boot/dts/kirkwood-dreamplug.dts               | 4 ++--
 arch/arm/boot/dts/kirkwood-goflexnet.dts               | 4 ++--
 arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts    | 4 ++--
 arch/arm/boot/dts/kirkwood-ib62x0.dts                  | 4 ++--
 arch/arm/boot/dts/kirkwood-iconnect.dts                | 4 ++--
 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts          | 4 ++--
 arch/arm/boot/dts/kirkwood-is2.dts                     | 2 +-
 arch/arm/boot/dts/kirkwood-km_kirkwood.dts             | 4 ++--
 arch/arm/boot/dts/kirkwood-lschlv2.dts                 | 2 +-
 arch/arm/boot/dts/kirkwood-lsxhl.dts                   | 2 +-
 arch/arm/boot/dts/kirkwood-lsxl.dtsi                   | 4 ++--
 arch/arm/boot/dts/kirkwood-mplcec4.dts                 | 4 ++--
 arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts | 4 ++--
 arch/arm/boot/dts/kirkwood-ns2-common.dtsi             | 4 ++--
 arch/arm/boot/dts/kirkwood-ns2.dts                     | 2 +-
 arch/arm/boot/dts/kirkwood-ns2lite.dts                 | 2 +-
 arch/arm/boot/dts/kirkwood-ns2max.dts                  | 2 +-
 arch/arm/boot/dts/kirkwood-ns2mini.dts                 | 2 +-
 arch/arm/boot/dts/kirkwood-nsa310.dts                  | 4 ++--
 arch/arm/boot/dts/kirkwood-openblocks_a6.dts           | 4 ++--
 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi      | 4 ++--
 arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts        | 2 +-
 arch/arm/boot/dts/kirkwood-sheevaplug.dts              | 2 +-
 arch/arm/boot/dts/kirkwood-topkick.dts                 | 4 ++--
 arch/arm/boot/dts/kirkwood-ts219-6281.dts              | 6 +++---
 arch/arm/boot/dts/kirkwood-ts219-6282.dts              | 6 +++---
 34 files changed, 58 insertions(+), 58 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-cloudbox.dts b/arch/arm/boot/dts/kirkwood-cloudbox.dts
index 00c48d2..9bf139c 100644
--- a/arch/arm/boot/dts/kirkwood-cloudbox.dts
+++ b/arch/arm/boot/dts/kirkwood-cloudbox.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "LaCie CloudBox";
diff --git a/arch/arm/boot/dts/kirkwood-db-88f6281.dts b/arch/arm/boot/dts/kirkwood-db-88f6281.dts
index 9d777ed..f420cbe 100644
--- a/arch/arm/boot/dts/kirkwood-db-88f6281.dts
+++ b/arch/arm/boot/dts/kirkwood-db-88f6281.dts
@@ -11,8 +11,8 @@
 
 /dts-v1/;
 
-/include/ "kirkwood-db.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood-db.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "Marvell DB-88F6281-BP Development Board";
diff --git a/arch/arm/boot/dts/kirkwood-db-88f6282.dts b/arch/arm/boot/dts/kirkwood-db-88f6282.dts
index f4c8528..c5df866 100644
--- a/arch/arm/boot/dts/kirkwood-db-88f6282.dts
+++ b/arch/arm/boot/dts/kirkwood-db-88f6282.dts
@@ -11,8 +11,8 @@
 
 /dts-v1/;
 
-/include/ "kirkwood-db.dtsi"
-/include/ "kirkwood-6282.dtsi"
+#include "kirkwood-db.dtsi"
+#include "kirkwood-6282.dtsi"
 
 / {
 	model = "Marvell DB-88F6282-BP Development Board";
diff --git a/arch/arm/boot/dts/kirkwood-db.dtsi b/arch/arm/boot/dts/kirkwood-db.dtsi
index c87cfb8..29bd98e 100644
--- a/arch/arm/boot/dts/kirkwood-db.dtsi
+++ b/arch/arm/boot/dts/kirkwood-db.dtsi
@@ -12,7 +12,7 @@
  * and 6282 variants of the Marvell Kirkwood Development Board.
  */
 
-/include/ "kirkwood.dtsi"
+#include "kirkwood.dtsi"
 
 / {
 	memory {
diff --git a/arch/arm/boot/dts/kirkwood-dns320.dts b/arch/arm/boot/dts/kirkwood-dns320.dts
index 14d4cee..e112ca6 100644
--- a/arch/arm/boot/dts/kirkwood-dns320.dts
+++ b/arch/arm/boot/dts/kirkwood-dns320.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-dnskw.dtsi"
+#include "kirkwood-dnskw.dtsi"
 
 / {
 	model = "D-Link DNS-320 NAS (Rev A1)";
diff --git a/arch/arm/boot/dts/kirkwood-dns325.dts b/arch/arm/boot/dts/kirkwood-dns325.dts
index 6387257..5119fb8 100644
--- a/arch/arm/boot/dts/kirkwood-dns325.dts
+++ b/arch/arm/boot/dts/kirkwood-dns325.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-dnskw.dtsi"
+#include "kirkwood-dnskw.dtsi"
 
 / {
 	model = "D-Link DNS-325 NAS (Rev A1)";
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 0afe1d0..2e04284 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -1,5 +1,5 @@
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "D-Link DNS NASes (kirkwood-based)";
diff --git a/arch/arm/boot/dts/kirkwood-dockstar.dts b/arch/arm/boot/dts/kirkwood-dockstar.dts
index 7714742..4387ae8 100644
--- a/arch/arm/boot/dts/kirkwood-dockstar.dts
+++ b/arch/arm/boot/dts/kirkwood-dockstar.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "Seagate FreeAgent Dockstar";
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 36c7ba3..c628378 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "Globalscale Technologies Dreamplug";
diff --git a/arch/arm/boot/dts/kirkwood-goflexnet.dts b/arch/arm/boot/dts/kirkwood-goflexnet.dts
index 31caa64..e571180 100644
--- a/arch/arm/boot/dts/kirkwood-goflexnet.dts
+++ b/arch/arm/boot/dts/kirkwood-goflexnet.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "Seagate GoFlex Net";
diff --git a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
index 1e642f3..2c5673a 100644
--- a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
+++ b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "Globalscale Technologies Guruplug Server Plus";
diff --git a/arch/arm/boot/dts/kirkwood-ib62x0.dts b/arch/arm/boot/dts/kirkwood-ib62x0.dts
index 20c4b08..158161f 100644
--- a/arch/arm/boot/dts/kirkwood-ib62x0.dts
+++ b/arch/arm/boot/dts/kirkwood-ib62x0.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "RaidSonic ICY BOX IB-NAS62x0 (Rev B)";
diff --git a/arch/arm/boot/dts/kirkwood-iconnect.dts b/arch/arm/boot/dts/kirkwood-iconnect.dts
index 441204e..1a98487 100644
--- a/arch/arm/boot/dts/kirkwood-iconnect.dts
+++ b/arch/arm/boot/dts/kirkwood-iconnect.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "Iomega Iconnect";
diff --git a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
index 00a7bfe..fd7f053 100644
--- a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
+++ b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "Iomega StorCenter ix2-200";
diff --git a/arch/arm/boot/dts/kirkwood-is2.dts b/arch/arm/boot/dts/kirkwood-is2.dts
index c3f036b..bd88a23 100644
--- a/arch/arm/boot/dts/kirkwood-is2.dts
+++ b/arch/arm/boot/dts/kirkwood-is2.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-ns2-common.dtsi"
+#include "kirkwood-ns2-common.dtsi"
 
 / {
 	model = "LaCie Internet Space v2";
diff --git a/arch/arm/boot/dts/kirkwood-km_kirkwood.dts b/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
index 5d9f5ea..b071d37 100644
--- a/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
+++ b/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-98dx4122.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-98dx4122.dtsi"
 
 / {
 	model = "Keymile Kirkwood Reference Design";
diff --git a/arch/arm/boot/dts/kirkwood-lschlv2.dts b/arch/arm/boot/dts/kirkwood-lschlv2.dts
index 9f55d95..e2fa368 100644
--- a/arch/arm/boot/dts/kirkwood-lschlv2.dts
+++ b/arch/arm/boot/dts/kirkwood-lschlv2.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-lsxl.dtsi"
+#include "kirkwood-lsxl.dtsi"
 
 / {
 	model = "Buffalo Linkstation LS-CHLv2";
diff --git a/arch/arm/boot/dts/kirkwood-lsxhl.dts b/arch/arm/boot/dts/kirkwood-lsxhl.dts
index 5c84c11..8d89cdf 100644
--- a/arch/arm/boot/dts/kirkwood-lsxhl.dts
+++ b/arch/arm/boot/dts/kirkwood-lsxhl.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-lsxl.dtsi"
+#include "kirkwood-lsxl.dtsi"
 
 / {
 	model = "Buffalo Linkstation LS-XHL";
diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
index 31b17f5..f7e247c 100644
--- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
+++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
@@ -1,5 +1,5 @@
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	chosen {
diff --git a/arch/arm/boot/dts/kirkwood-mplcec4.dts b/arch/arm/boot/dts/kirkwood-mplcec4.dts
index 6179333..382ad99 100644
--- a/arch/arm/boot/dts/kirkwood-mplcec4.dts
+++ b/arch/arm/boot/dts/kirkwood-mplcec4.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "MPL CEC4";
diff --git a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
index ad6ade7..8be68bd 100644
--- a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
+++ b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6282.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6282.dtsi"
 
 / {
 	model = "NETGEAR ReadyNAS Duo v2";
diff --git a/arch/arm/boot/dts/kirkwood-ns2-common.dtsi b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
index 2afac04..d0fb34d 100644
--- a/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
@@ -1,5 +1,5 @@
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	chosen {
diff --git a/arch/arm/boot/dts/kirkwood-ns2.dts b/arch/arm/boot/dts/kirkwood-ns2.dts
index b50e93d..0599f3c 100644
--- a/arch/arm/boot/dts/kirkwood-ns2.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-ns2-common.dtsi"
+#include "kirkwood-ns2-common.dtsi"
 
 / {
 	model = "LaCie Network Space v2";
diff --git a/arch/arm/boot/dts/kirkwood-ns2lite.dts b/arch/arm/boot/dts/kirkwood-ns2lite.dts
index af8259f..b0e1798 100644
--- a/arch/arm/boot/dts/kirkwood-ns2lite.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2lite.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-ns2-common.dtsi"
+#include "kirkwood-ns2-common.dtsi"
 
 / {
 	model = "LaCie Network Space Lite v2";
diff --git a/arch/arm/boot/dts/kirkwood-ns2max.dts b/arch/arm/boot/dts/kirkwood-ns2max.dts
index 85f24d2..d4f6a58 100644
--- a/arch/arm/boot/dts/kirkwood-ns2max.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2max.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-ns2-common.dtsi"
+#include "kirkwood-ns2-common.dtsi"
 
 / {
 	model = "LaCie Network Space Max v2";
diff --git a/arch/arm/boot/dts/kirkwood-ns2mini.dts b/arch/arm/boot/dts/kirkwood-ns2mini.dts
index 329e530..f30e05a 100644
--- a/arch/arm/boot/dts/kirkwood-ns2mini.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2mini.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-ns2-common.dtsi"
+#include "kirkwood-ns2-common.dtsi"
 
 / {
 	/* This machine is embedded in the first LaCie CloudBox product. */
diff --git a/arch/arm/boot/dts/kirkwood-nsa310.dts b/arch/arm/boot/dts/kirkwood-nsa310.dts
index 6900359..8fd683c 100644
--- a/arch/arm/boot/dts/kirkwood-nsa310.dts
+++ b/arch/arm/boot/dts/kirkwood-nsa310.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "ZyXEL NSA310";
diff --git a/arch/arm/boot/dts/kirkwood-openblocks_a6.dts b/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
index 38dc851..365b792 100644
--- a/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
+++ b/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6282.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6282.dtsi"
 
 / {
 	model = "Plat'Home OpenBlocksA6";
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
index f7143f1..0cc5f26 100644
--- a/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
@@ -6,8 +6,8 @@
  * Licensed under GPLv2
  */
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	memory {
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts b/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
index f620ce4..eac6a21 100644
--- a/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
@@ -8,7 +8,7 @@
 
 /dts-v1/;
 
-/include/ "kirkwood-sheevaplug-common.dtsi"
+#include "kirkwood-sheevaplug-common.dtsi"
 
 / {
 	model = "Globalscale Technologies eSATA SheevaPlug";
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug.dts b/arch/arm/boot/dts/kirkwood-sheevaplug.dts
index bf1dff2..bb61918 100644
--- a/arch/arm/boot/dts/kirkwood-sheevaplug.dts
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug.dts
@@ -8,7 +8,7 @@
 
 /dts-v1/;
 
-/include/ "kirkwood-sheevaplug-common.dtsi"
+#include "kirkwood-sheevaplug-common.dtsi"
 
 / {
 	model = "Globalscale Technologies SheevaPlug";
diff --git a/arch/arm/boot/dts/kirkwood-topkick.dts b/arch/arm/boot/dts/kirkwood-topkick.dts
index f2052d7..974f1e0 100644
--- a/arch/arm/boot/dts/kirkwood-topkick.dts
+++ b/arch/arm/boot/dts/kirkwood-topkick.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6282.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6282.dtsi"
 
 / {
 	model = "Univeral Scientific Industrial Co. Topkick-1281P2";
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6281.dts b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
index 6dd1038..3867ae3 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6281.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
@@ -1,8 +1,8 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
-/include/ "kirkwood-ts219.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
+#include "kirkwood-ts219.dtsi"
 
 / {
 	ocp at f1000000 {
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
index 6fdc5ff..7d6cc86 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -1,8 +1,8 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6282.dtsi"
-/include/ "kirkwood-ts219.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6282.dtsi"
+#include "kirkwood-ts219.dtsi"
 
 / {
 	ocp at f1000000 {
-- 
1.8.1.5



From shawn.guo at linaro.org  Tue Jul 23 09:38:02 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 23 Jul 2013 21:38:02 +0800
Subject: [PATCH] ARM: dts: mxs: Add spi alias
In-Reply-To: <1374526049-29649-1-git-send-email-festevam@gmail.com>
References: <1374526049-29649-1-git-send-email-festevam@gmail.com>
Message-ID: <20130723133800.GA17327@S2101-09.ap.freescale.net>

On Mon, Jul 22, 2013 at 05:47:29PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> After providing spi alias, we can get the following message during probe:
> 
> m25p80 spi1.0: sst25vf016b (2048 Kbytes)
> 
> ,which looks better than the original one:
> 
> m25p80 spi32766.0: sst25vf016b (2048 Kbytes)
> 
> While at it, keep the alias entries in alphabetical order.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  arch/arm/boot/dts/imx23.dtsi | 2 ++
>  arch/arm/boot/dts/imx28.dtsi | 6 ++++--
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
> index 1e528db..28b5ce2 100644
> --- a/arch/arm/boot/dts/imx23.dtsi
> +++ b/arch/arm/boot/dts/imx23.dtsi
> @@ -20,6 +20,8 @@
>  		gpio2 = &gpio2;
>  		serial0 = &auart0;
>  		serial1 = &auart1;
> +		spi0 = &ssp0;
> +		spi1 = &ssp1;
>  	};
>  
>  	cpus {
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index db67eb6..89d98a1 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -15,6 +15,8 @@
>  	interrupt-parent = <&icoll>;
>  
>  	aliases {
> +		ethernet0 = &mac0;
> +		ethernet1 = &mac1;
>  		gpio0 = &gpio0;
>  		gpio1 = &gpio1;
>  		gpio2 = &gpio2;
> @@ -22,13 +24,13 @@
>  		gpio4 = &gpio4;
>  		saif0 = &saif0;
>  		saif1 = &saif1;
> +		spi0 = &ssp1;
> +		spi1 = &ssp2;

So this should be put after serial, right?

Shawn

>  		serial0 = &auart0;
>  		serial1 = &auart1;
>  		serial2 = &auart2;
>  		serial3 = &auart3;
>  		serial4 = &auart4;
> -		ethernet0 = &mac0;
> -		ethernet1 = &mac1;
>  	};
>  
>  	cpus {
> -- 
> 1.8.1.2
> 



From fabio.estevam at freescale.com  Tue Jul 23 09:36:11 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Tue, 23 Jul 2013 10:36:11 -0300
Subject: [PATCH] ARM: dts: mxs: Add spi alias
In-Reply-To: <20130723133800.GA17327@S2101-09.ap.freescale.net>
References: <1374526049-29649-1-git-send-email-festevam@gmail.com>
 <20130723133800.GA17327@S2101-09.ap.freescale.net>
Message-ID: <51EE86CB.3010901@freescale.com>

On 07/23/2013 10:38 AM, Shawn Guo wrote:
   		gpio2 = &gpio2;
>> @@ -22,13 +24,13 @@
>>   		gpio4 = &gpio4;
>>   		saif0 = &saif0;
>>   		saif1 = &saif1;
>> +		spi0 = &ssp1;
>> +		spi1 = &ssp2;
>
> So this should be put after serial, right?

Yes, please check v2, which has this fixed.

Thanks,

Fabio Estevam




From shawn.guo at linaro.org  Tue Jul 23 09:40:13 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 23 Jul 2013 21:40:13 +0800
Subject: [PATCH v2] ARM: dts: mxs: Add spi alias
In-Reply-To: <1374526621-29874-1-git-send-email-festevam@gmail.com>
References: <1374526621-29874-1-git-send-email-festevam@gmail.com>
Message-ID: <20130723134012.GB17327@S2101-09.ap.freescale.net>

On Mon, Jul 22, 2013 at 05:57:01PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> After providing spi alias, we can get the following message during probe:
> 
> m25p80 spi1.0: sst25vf016b (2048 Kbytes)
> 
> ,which looks better than the original one:
> 
> m25p80 spi32766.0: sst25vf016b (2048 Kbytes)
> 
> While at it, keep the alias entries in alphabetical order.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Applied, thanks.



From rogerq at ti.com  Tue Jul 23 10:04:48 2013
From: rogerq at ti.com (Roger Quadros)
Date: Tue, 23 Jul 2013 17:04:48 +0300
Subject: [PATCH v2] ARM: Do not run dummy_flush_tlb_a15_erratum() on
 non-Cortex-A15
In-Reply-To: <1374581199-8277-1-git-send-email-festevam@gmail.com>
References: <1374581199-8277-1-git-send-email-festevam@gmail.com>
Message-ID: <51EE8D80.8010409@ti.com>

On 07/23/2013 03:06 PM, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Commit 93dc688 (ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 
> (TLBI/DSB operations)) causes the following undefined instruction error on a
> mx53 (Cortex-A8):
> 
> Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> CPU: 0 PID: 275 Comm: modprobe Not tainted 3.11.0-rc2-next-20130722-00009-g9b0f371 #881
> task: df46cc00 ti: df48e000 task.ti: df48e000
> PC is at check_and_switch_context+0x17c/0x4d0
> LR is at check_and_switch_context+0xdc/0x4d0
> 
> This problem happens because check_and_switch_context() calls 
> dummy_flush_tlb_a15_erratum() without checking if we are really running on a 
> Cortex-A15 or not. 
> 
> To avoid this issue, only call dummy_flush_tlb_a15_erratum() inside 
> check_and_switch_context() if erratum_a15_798181() returns true, which means
> that we are really running on a Cortex-A15.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Reviewed-by: Roger Quadros <rogerq at ti.com>


From mkl at pengutronix.de  Tue Jul 23 10:08:43 2013
From: mkl at pengutronix.de (Marc Kleine-Budde)
Date: Tue, 23 Jul 2013 16:08:43 +0200
Subject: [PATCH v2] arm: Fix deferred mm switch on VIVT processors
In-Reply-To: <1374252329-5345-1-git-send-email-catalin.marinas@arm.com>
References: <1374252329-5345-1-git-send-email-catalin.marinas@arm.com>
Message-ID: <51EE8E6B.7070801@pengutronix.de>

On 07/19/2013 06:45 PM, Catalin Marinas wrote:
> As of commit b9d4d42ad9 (ARM: Remove __ARCH_WANT_INTERRUPTS_ON_CTXSW on
> pre-ARMv6 CPUs), the mm switching on VIVT processors is done in the
> finish_arch_post_lock_switch() function to avoid whole cache flushing
> with interrupts disabled. The need for deferred mm switch is stored as a
> thread flag (TIF_SWITCH_MM). However, with preemption enabled, we can
> have another thread switch before finish_arch_post_lock_switch(). If the
> new thread has the same mm as the previous 'next' thread, the scheduler
> will not call switch_mm() and the TIF_SWITCH_MM flag won't be set for
> the new thread.
> 
> This patch moves the switch pending flag to the mm_context_t structure
> since this is specific to the mm rather than thread.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
> Reported-by: Marc Kleine-Budde <mkl at pengutronix.de>
> Cc: Marc Kleine-Budde <mkl at pengutronix.de>
> Cc: <stable at vger.kernel.org> # 3.5+

Tested-by: Marc Kleine-Budde <mkl at pengutronix.de>

regards,
Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130723/ab545a0c/attachment.sig>

From stern at rowland.harvard.edu  Tue Jul 23 10:14:01 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 23 Jul 2013 10:14:01 -0400 (EDT)
Subject: [PATCH 6/6] USB: ehci-omap: Implement suspend/resume
In-Reply-To: <51EE4A7C.2020709@ti.com>
Message-ID: <Pine.LNX.4.44L0.1307231009120.1304-100000@iolanthe.rowland.org>

On Tue, 23 Jul 2013, Roger Quadros wrote:

> >> +               pm_runtime_get_sync(dev);
> >> +               ehci_resume(hcd, false);
> >> +               ret = ehci_suspend(hcd, do_wakeup);
> >> +               pm_runtime_put_sync(dev);
> > 
> > It would be better to call pm_runtime_resume(dev) at the start instead
> > of pm_runtime_get_sync(), and eliminate the last two lines.  Then the
> > ehci_suspend() below could be moved outside the "if" statement.
> 
> Why do I find pm_runtime_* so confusing ;)

It tries to provide every service anyone might want, and ends up being 
confusingly large.

In this case, though, the reasoning is simple.  We know that after the 
system resumes, the device will be back in the active state.  Hence 
there's no point in calling pm_runtime_put_sync here, other than to 
balance the _get_sync above.  Since there's no danger of another thread 
trying to do a runtime suspend at this point, you don't need to 
increment the usage counter.  Therefore pm_runtime_resume is good 
enough.

> > Alternatively, if you are able to turn off the wakeup setting without
> > going through an entire resume/suspend cycle, that would be preferable.
> > 
> 
> As we don't rely on the EHCI controller's interrupt any more after we
> power it down, maybe ehci_resume/suspend cycle is not required at all on OMAP,
> even if the wakeup setting is disabled during system suspend.
> 
> As the wakeup is controlled entirely by pad wakeup, all we need to do is make sure
> the IO pad wakeup is configured correctly based on do_wakeup. How this is done
> is still in transition but it might be turn out to be as simple as irq_set_irq_wake()
> 
> So IMHO, for ehci-omap this should suffice
> 
> static int omap_ehci_suspend(struct device *dev)
> {
> 	struct usb_hcd *hcd = dev_get_drvdata(dev);
> 	bool do_wakeup = device_may_wakeup(dev);
> 	int ret = 0;
> 
> 	if (!pm_runtime_status_suspended(dev))
> 		ret = ehci_suspend(hcd, do_wakeup);
> 
> 	/* Not tested yet */
> 	irq_set_irq_wake(hcd->irq, do_wakeup);
> 
> 	return ret;
> }
> 
> What do you think?

Nice and simple.  It looks good.

> As the OMAP IO pad wakeup management code [1] is still in transition, I'll wait till
> that gets settled and then resend this series.

Okay.

Alan Stern



From s.hauer at pengutronix.de  Tue Jul 23 10:17:27 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Jul 2013 16:17:27 +0200
Subject: [PATCH v5] linux,stdout-path helper
In-Reply-To: <20121121155312.GX4398@game.jcrosoft.org>
References: <20121121155312.GX4398@game.jcrosoft.org>
Message-ID: <20130723141727.GA6807@pengutronix.de>

On Wed, Nov 21, 2012 at 04:53:12PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> The following adds a helper for matching the linux,stdout-path property
> in the chosen node and makes use of it in the i.MX serial and Atmel serial driver.

Seems this got stuck. Jean-Christophe, will you update this series? I
could really make use of this.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From ldewangan at nvidia.com  Tue Jul 23 10:43:23 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Tue, 23 Jul 2013 20:13:23 +0530
Subject: [PATCH] ARM: dts: tegra114: dalmore: fix the irq trigger type
 of Palmas MFD device
In-Reply-To: <1374574191-24396-1-git-send-email-josephl@nvidia.com>
References: <1374574191-24396-1-git-send-email-josephl@nvidia.com>
Message-ID: <51EE968B.1050103@nvidia.com>

On Tuesday 23 July 2013 03:39 PM, Joseph Lo wrote:
> The IRQ trigger type of Palmas MFD device (tps65913) is low-level
> sensitive. The wrong configuration would cause an interrupt storm
> when booting the system. Fixing it in DT with appropriate interrupt
> type.
>
> Cc: Laxman Dewangan <ldewangan at nvidia.com>
> Signed-off-by: Joseph Lo <josephl at nvidia.com>
> ---
>   arch/arm/boot/dts/tegra114-dalmore.dts | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
> index 76529e4..70b9d0c 100644
> --- a/arch/arm/boot/dts/tegra114-dalmore.dts
> +++ b/arch/arm/boot/dts/tegra114-dalmore.dts
> @@ -840,7 +840,7 @@
>   		palmas: tps65913 {
>   			compatible = "ti,palmas";
>   			reg = <0x58>;
> -			interrupts = <0 86 0x4>;
> +			interrupts = <0 86 0x8>;
>   

This fails as GIC does not support the interrupt flag of 8.

[   13.007755] genirq: Setting trigger mode 8 for irq 118 failed 
(gic_set_type+0x0/0xf0)
[   13.009152] palmas 1-0058: Irq flag is 0x00000000


I did not get the interrupt storm and even interrupt is not working on tot.
Two ways to resolve this:
- Change the interrupt flag to 0 from 4. Or
- Remove the nvidia,invert-interrupt; for PMC node.




From stern at rowland.harvard.edu  Tue Jul 23 10:37:05 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 23 Jul 2013 10:37:05 -0400 (EDT)
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <3419798.aorxYv8pdo@flatron>
Message-ID: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>

On Tue, 23 Jul 2013, Tomasz Figa wrote:

> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> > Hi Alan,

Thanks for helping to clarify the issues here.

> > > Okay.  Are PHYs _always_ platform devices?
> > 
> > They can be i2c, spi or any other device types as well.

In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device.  Then how does the
kernel know which controller is attached to the PHY?  Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?

> > > > > 	PHY.  Currently this information is represented by name or 
> ID
> > > > > 	strings embedded in platform data.
> > > > 
> > > > right. It's embedded in the platform data of the controller.
> > > 
> > > It must also be embedded in the PHY's platform data somehow.
> > > Otherwise, how would the kernel know which PHY to use?
> > 
> > By using a PHY lookup as Stephen and I suggested in our previous
> > replies. Without any extra data in platform data. (I have even posted a
> > code example.)

I don't understand, because I don't know what "a PHY lookup" does.

> > > In this case, it doesn't matter where the platform_device structures
> > > are created or where the driver source code is.  Let's take a simple
> > > example.  Suppose the system design includes a PHY named "foo".  Then
> > > the board file could contain:
> > > 
> > > struct phy_info { ... } phy_foo;
> > > EXPORT_SYMBOL_GPL(phy_foo);
> > > 
> > > and a header file would contain:
> > > 
> > > extern struct phy_info phy_foo;
> > > 
> > > The PHY supplier could then call phy_create(&phy_foo), and the PHY
> > > client could call phy_find(&phy_foo).  Or something like that; make up
> > > your own structure tags and function names.
> > > 
> > > It's still possible to have conflicts, but now two PHYs with the same
> > > name (or a misspelled name somewhere) will cause an error at link
> > > time.
> > 
> > This is incorrect, sorry. First of all it's a layering violation - you
> > export random driver-specific symbols from one driver to another. Then

No, that's not what I said.  Neither the PHY driver nor the controller
driver exports anything to the other.  Instead, both drivers use data
exported by the board file.

> > imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
> > there are two types of consumer drivers (e.g. USB host controllers). Now
> > consider following mapping:
> > 
> > SoC	PHY	consumer
> > A	PHY1	HOST1
> > B	PHY1	HOST2
> > C	PHY2	HOST1
> > D	PHY2	HOST2
> > 
> > So we have to be able to use any of the PHYs with any of the host
> > drivers. This means you would have to export symbol with the same name
> > from both PHY drivers, which obviously would not work in this case,
> > because having both drivers enabled (in a multiplatform aware
> > configuration) would lead to linking conflict.

You're right; the scheme was too simple.  Instead, the board file must
export two types of data structures, one for PHYs and one for
controllers.  Like this:

struct phy_info {
	/* Info for the controller attached to this PHY */
	struct controller_info	*hinfo;
};

struct controller_info {
	/* Info for the PHY which this controller is attached to */
	struct phy_info		*pinfo;
};

The board file for SoC A would contain:

struct phy_info phy1 = {&host1);
EXPORT_SYMBOL(phy1);
struct controller_info host1 = {&phy1};
EXPORT_SYMBOL(host1);

The board file for SoC B would contain:

struct phy_info phy1 = {&host2);
EXPORT_SYMBOL(phy1);
struct controller_info host2 = {&phy1};
EXPORT_SYMBOL(host2);

And so on.  This explicitly gives the connection between PHYs and
controllers.  The PHY providers would use &phy1 or &phy2, and the PHY
consumers would use &host1 or &host2.

Alan Stern



From t.figa at samsung.com  Tue Jul 23 10:50:52 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 16:50:52 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
Message-ID: <2147402.ggVzZLIPLp@amdc1227>

On Tuesday 23 of July 2013 10:37:05 Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> > > Hi Alan,
> 
> Thanks for helping to clarify the issues here.
> 
> > > > Okay.  Are PHYs _always_ platform devices?
> > > 
> > > They can be i2c, spi or any other device types as well.
> 
> In those other cases, presumably there is no platform data associated
> with the PHY since it isn't a platform device.  Then how does the
> kernel know which controller is attached to the PHY?  Is this spelled
> out in platform data associated with the PHY's i2c/spi/whatever parent?
> 
> > > > > > 	PHY.  Currently this information is represented by name or
> > 
> > ID
> > 
> > > > > > 	strings embedded in platform data.
> > > > > 
> > > > > right. It's embedded in the platform data of the controller.
> > > > 
> > > > It must also be embedded in the PHY's platform data somehow.
> > > > Otherwise, how would the kernel know which PHY to use?
> > > 
> > > By using a PHY lookup as Stephen and I suggested in our previous
> > > replies. Without any extra data in platform data. (I have even posted
> > > a
> > > code example.)
> 
> I don't understand, because I don't know what "a PHY lookup" does.

I have provided a code example in [1]. Feel free to ask questions about 
those code snippets.

[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=20889

> > > > In this case, it doesn't matter where the platform_device
> > > > structures
> > > > are created or where the driver source code is.  Let's take a
> > > > simple
> > > > example.  Suppose the system design includes a PHY named "foo". 
> > > > Then
> > > > the board file could contain:
> > > > 
> > > > struct phy_info { ... } phy_foo;
> > > > EXPORT_SYMBOL_GPL(phy_foo);
> > > > 
> > > > and a header file would contain:
> > > > 
> > > > extern struct phy_info phy_foo;
> > > > 
> > > > The PHY supplier could then call phy_create(&phy_foo), and the PHY
> > > > client could call phy_find(&phy_foo).  Or something like that; make
> > > > up
> > > > your own structure tags and function names.
> > > > 
> > > > It's still possible to have conflicts, but now two PHYs with the
> > > > same
> > > > name (or a misspelled name somewhere) will cause an error at link
> > > > time.
> > > 
> > > This is incorrect, sorry. First of all it's a layering violation -
> > > you
> > > export random driver-specific symbols from one driver to another.
> > > Then
> 
> No, that's not what I said.  Neither the PHY driver nor the controller
> driver exports anything to the other.  Instead, both drivers use data
> exported by the board file.

It's still a random, driver-specific global symbol exported from board file 
to drivers.

> > > imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2
> > > and
> > > there are two types of consumer drivers (e.g. USB host controllers).
> > > Now
> > > consider following mapping:
> > > 
> > > SoC	PHY	consumer
> > > A	PHY1	HOST1
> > > B	PHY1	HOST2
> > > C	PHY2	HOST1
> > > D	PHY2	HOST2
> > > 
> > > So we have to be able to use any of the PHYs with any of the host
> > > drivers. This means you would have to export symbol with the same
> > > name
> > > from both PHY drivers, which obviously would not work in this case,
> > > because having both drivers enabled (in a multiplatform aware
> > > configuration) would lead to linking conflict.
> 
> You're right; the scheme was too simple.  Instead, the board file must
> export two types of data structures, one for PHYs and one for
> controllers.  Like this:
> 
> struct phy_info {
> 	/* Info for the controller attached to this PHY */
> 	struct controller_info	*hinfo;
> };
> 
> struct controller_info {
> 	/* Info for the PHY which this controller is attached to */
> 	struct phy_info		*pinfo;
> };
> 
> The board file for SoC A would contain:
> 
> struct phy_info phy1 = {&host1);
> EXPORT_SYMBOL(phy1);
> struct controller_info host1 = {&phy1};
> EXPORT_SYMBOL(host1);
> 
> The board file for SoC B would contain:
> 
> struct phy_info phy1 = {&host2);
> EXPORT_SYMBOL(phy1);
> struct controller_info host2 = {&phy1};
> EXPORT_SYMBOL(host2);
> 
> And so on.  This explicitly gives the connection between PHYs and
> controllers.  The PHY providers would use &phy1 or &phy2, and the PHY
> consumers would use &host1 or &host2.

This could work assuming that only one SoC and one board is supported in 
single kernel image. However it's not the case.

We've used to support multiple boards since a long time already and now for 
selected platforms we even support multiplatform, i.e. multiple SoCs in 
single zImage. Such solution will not work.

Best regards,
Tomasz



From robherring2 at gmail.com  Tue Jul 23 11:03:20 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 23 Jul 2013 10:03:20 -0500
Subject: [PATCH 4/5] ARM: highbank: remove redundant smp_init_cpus
 definition
In-Reply-To: <1374579164-30255-5-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374579164-30255-5-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <51EE9B38.5030003@gmail.com>

On 07/23/2013 06:32 AM, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> arm_dt_init_cpu_maps is called before smp_init_cpus, which sets the
> cpu_possible_mask appropriately. Since highbank_smp_init_cpus does
> nothing extra, it can be removed.

This is all going to get removed in my PSCI support series. Trying to
get an updated version out soon.

Rob

> Cc: Rob Herring <rob.herring at calxeda.com>
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> ---
>  arch/arm/mach-highbank/platsmp.c | 22 ----------------------
>  1 file changed, 22 deletions(-)
> 
> diff --git a/arch/arm/mach-highbank/platsmp.c b/arch/arm/mach-highbank/platsmp.c
> index 32d75cf5..25b0bae 100644
> --- a/arch/arm/mach-highbank/platsmp.c
> +++ b/arch/arm/mach-highbank/platsmp.c
> @@ -31,27 +31,6 @@ static int highbank_boot_secondary(unsigned int cpu, struct task_struct *idle)
>  	return 0;
>  }
>  
> -/*
> - * Initialise the CPU possible map early - this describes the CPUs
> - * which may be present or become present in the system.
> - */
> -static void __init highbank_smp_init_cpus(void)
> -{
> -	unsigned int i, ncores = 4;
> -
> -	/* sanity check */
> -	if (ncores > NR_CPUS) {
> -		printk(KERN_WARNING
> -		       "highbank: no. of cores (%d) greater than configured "
> -		       "maximum of %d - clipping\n",
> -		       ncores, NR_CPUS);
> -		ncores = NR_CPUS;
> -	}
> -
> -	for (i = 0; i < ncores; i++)
> -		set_cpu_possible(i, true);
> -}
> -
>  static void __init highbank_smp_prepare_cpus(unsigned int max_cpus)
>  {
>  	if (scu_base_addr)
> @@ -59,7 +38,6 @@ static void __init highbank_smp_prepare_cpus(unsigned int max_cpus)
>  }
>  
>  struct smp_operations highbank_smp_ops __initdata = {
> -	.smp_init_cpus		= highbank_smp_init_cpus,
>  	.smp_prepare_cpus	= highbank_smp_prepare_cpus,
>  	.smp_boot_secondary	= highbank_boot_secondary,
>  #ifdef CONFIG_HOTPLUG_CPU
> 



From catalin.marinas at arm.com  Tue Jul 23 11:16:38 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Jul 2013 16:16:38 +0100
Subject: [PATCH v2] arm: Fix deferred mm switch on VIVT processors
In-Reply-To: <51EE8E6B.7070801@pengutronix.de>
References: <1374252329-5345-1-git-send-email-catalin.marinas@arm.com>
 <51EE8E6B.7070801@pengutronix.de>
Message-ID: <20130723151637.GC32692@arm.com>

On Tue, Jul 23, 2013 at 03:08:43PM +0100, Marc Kleine-Budde wrote:
> On 07/19/2013 06:45 PM, Catalin Marinas wrote:
> > As of commit b9d4d42ad9 (ARM: Remove __ARCH_WANT_INTERRUPTS_ON_CTXSW on
> > pre-ARMv6 CPUs), the mm switching on VIVT processors is done in the
> > finish_arch_post_lock_switch() function to avoid whole cache flushing
> > with interrupts disabled. The need for deferred mm switch is stored as a
> > thread flag (TIF_SWITCH_MM). However, with preemption enabled, we can
> > have another thread switch before finish_arch_post_lock_switch(). If the
> > new thread has the same mm as the previous 'next' thread, the scheduler
> > will not call switch_mm() and the TIF_SWITCH_MM flag won't be set for
> > the new thread.
> > 
> > This patch moves the switch pending flag to the mm_context_t structure
> > since this is specific to the mm rather than thread.
> > 
> > Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
> > Reported-by: Marc Kleine-Budde <mkl at pengutronix.de>
> > Cc: Marc Kleine-Budde <mkl at pengutronix.de>
> > Cc: <stable at vger.kernel.org> # 3.5+
> 
> Tested-by: Marc Kleine-Budde <mkl at pengutronix.de>

Thanks. Submitted as:

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7790/1

-- 
Catalin


From santosh.shilimkar at ti.com  Tue Jul 23 11:17:13 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 23 Jul 2013 11:17:13 -0400
Subject: [PATCHv2 2/5] arm64: factor out spin-table boot method
In-Reply-To: <1374507454-4573-3-git-send-email-mark.rutland@arm.com>
References: <1374507454-4573-1-git-send-email-mark.rutland@arm.com>
 <1374507454-4573-3-git-send-email-mark.rutland@arm.com>
Message-ID: <51EE9E79.6080005@ti.com>

On Monday 22 July 2013 11:37 AM, Mark Rutland wrote:
> The arm64 kernel has an internal holding pen, which is necessary for
> some systems where we can't bring CPUs online individually and must hold
> multiple CPUs in a safe area until the kernel is able to handle them.
> The current SMP infrastructure for arm64 is closely coupled to this
> holding pen, and alternative boot methods must launch CPUs into the pen,
> from whence they are launched into the kernel proper.
>
s/whence/where
 
> With PSCI (and possibly other future boot methods), we can bring CPUs
> online individually, and need not perform the secondary_holding_pen
> dance. Instead, this patch factors the holding pen management code out
> to the spin-table boot method code, as it is the only boot method
> requiring the pen.
> 
> A new entry point for secondaries, secondary_entry is added for other
> boot methods to use, which bypasses the holding pen and its associated
> overhead when bringing CPUs online. The smp.pen.text section is also
> removed, as the pen can live in head.text without problem.
> 
> The smp_operations structure is extended with two new functions,
> cpu_boot and cpu_postboot, for bringing a cpu into the kernel and
> performing any post-boot cleanup required by a bootmethod (e.g.
> resetting the secondary_holding_pen_release to INVALID_HWID).
> 
> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> ---
>  arch/arm64/include/asm/smp.h       | 17 ++++++++-
>  arch/arm64/kernel/head.S           | 12 +++++-
>  arch/arm64/kernel/smp.c            | 67 +++-------------------------------
>  arch/arm64/kernel/smp_psci.c       | 16 ++++----
>  arch/arm64/kernel/smp_spin_table.c | 75 ++++++++++++++++++++++++++++++++++++++
>  arch/arm64/kernel/vmlinux.lds.S    |  1 -
>  6 files changed, 115 insertions(+), 73 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> index 90626b6..af39644 100644
> --- a/arch/arm64/include/asm/smp.h
> +++ b/arch/arm64/include/asm/smp.h
> @@ -60,8 +60,7 @@ struct secondary_data {
>  	void *stack;
>  };
>  extern struct secondary_data secondary_data;
> -extern void secondary_holding_pen(void);
> -extern volatile unsigned long secondary_holding_pen_release;
> +extern void secondary_entry(void);
>  
>  extern void arch_send_call_function_single_ipi(int cpu);
>  extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
> @@ -70,8 +69,22 @@ struct device_node;
>  
>  struct smp_operations {
>  	const char	*name;
> +	/*
> +	 * Check devicetree data for cpu
> +	 */
All these comments can go above the struct as mentioned
in kerneldoc.

>  	int		(*cpu_init)(struct device_node *, unsigned int);
> +	/*
> +	 * Test if cpu is present and bootable
> +	 */
>  	int		(*cpu_prepare)(unsigned int);
> +	/*
> +	 * Boot cpu into the kernel
> +	 */
> +	int		(*cpu_boot)(unsigned int);
> +	/*
> +	 * Performs post-boot cleanup
> +	 */
> +	void		(*cpu_postboot)(void);
>  };
>  
>  extern const struct smp_operations smp_spin_table_ops;
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 53dcae4..3532ca6 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -217,7 +217,6 @@ ENTRY(__boot_cpu_mode)
>  	.quad	PAGE_OFFSET
>  
>  #ifdef CONFIG_SMP
> -	.pushsection    .smp.pen.text, "ax"
>  	.align	3
>  1:	.quad	.
>  	.quad	secondary_holding_pen_release
> @@ -242,7 +241,16 @@ pen:	ldr	x4, [x3]
>  	wfe
>  	b	pen
>  ENDPROC(secondary_holding_pen)
> -	.popsection
> +
> +	/*
> +	 * Secondary entry point that jumps straight into the kernel. Only to
> +	 * be used where CPUs are brought online dynamically by the kernel.
> +	 */
> +ENTRY(secondary_entry)
> +	bl	__calc_phys_offset		// x2=phys offset
> +	bl	el2_setup			// Drop to EL1
> +	b	secondary_startup
> +ENDPROC(secondary_entry)
>  
>  ENTRY(secondary_startup)
>  	/*
Other than that, rest of the patch looks fine too me.

regards,
Santosh



From simon.guinot at sequanux.org  Tue Jul 23 11:18:34 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Tue, 23 Jul 2013 17:18:34 +0200
Subject: Location for a kind of GPIO bus driver
Message-ID: <20130723151834.GJ9916@kw.sim.vm.gnt>

Hi,

I am currently working on converting the LED driver leds-netxbig to DT.
Doing so, I am also considering to move the GPIO extension bus functions
(which are currently parts of leds-netxbig) into a separate driver.

On the LaCie "Big Network" board family (netxbig), the LEDs are
controlled by a CPLD. In turn, the CPLD can be configured (mostly the
LEDs modes) through a kind of parallel GPIO bus, called GPIO extension
bus. Two registers (address and data) are exposed. Each of them is made
up of several GPIOs. An extra GPIO is used to notify the CPLD that the
registers have been updated. The leds-netxbig driver uses some dedicated
functions (prefixed by "gpio_ext_") to handle the GPIO bus extension.

On the latest "Big Network" boards, this bus is also used to enable the
PM wakeup sources: the CPLD can be asked to keep powered some devices
(as the RTC or the Ethernet PHY) while the board is down. I think it
could be nice to expose this feature to the userland. That's why I am
thinking about moving the GPIO extension bus support into a separate
driver. The problem is that I can't find a proper location for a such
driver. AFAIK, it doesn't fit with anything existing supported by Linux.
Maybe I should consider drivers/bus ? Or even drivers/misc ?

Also from a DT point, it not clear to me how the resulting bus and LEDs
driver are going to work together.

Any advice is welcome. Thanks in advance.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130723/14d4cf33/attachment.sig>

From kishon at ti.com  Tue Jul 23 11:18:24 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 23 Jul 2013 20:48:24 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
Message-ID: <51EE9EC0.6060905@ti.com>

Hi,

On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> 
>> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
>>> Hi Alan,
> 
> Thanks for helping to clarify the issues here.
> 
>>>> Okay.  Are PHYs _always_ platform devices?
>>>
>>> They can be i2c, spi or any other device types as well.
> 
> In those other cases, presumably there is no platform data associated
> with the PHY since it isn't a platform device.  Then how does the
> kernel know which controller is attached to the PHY?  Is this spelled
> out in platform data associated with the PHY's i2c/spi/whatever parent?

Yes. I think we could use i2c_board_info for passing platform data.
> 
>>>>>> 	PHY.  Currently this information is represented by name or 
>> ID
>>>>>> 	strings embedded in platform data.
>>>>>
>>>>> right. It's embedded in the platform data of the controller.
>>>>
>>>> It must also be embedded in the PHY's platform data somehow.
>>>> Otherwise, how would the kernel know which PHY to use?
>>>
>>> By using a PHY lookup as Stephen and I suggested in our previous
>>> replies. Without any extra data in platform data. (I have even posted a
>>> code example.)
> 
> I don't understand, because I don't know what "a PHY lookup" does.

It is how the PHY framework finds a PHY, when the controller (say USB)requests
a PHY from the PHY framework.
> 
>>>> In this case, it doesn't matter where the platform_device structures
>>>> are created or where the driver source code is.  Let's take a simple
>>>> example.  Suppose the system design includes a PHY named "foo".  Then
>>>> the board file could contain:
>>>>
>>>> struct phy_info { ... } phy_foo;
>>>> EXPORT_SYMBOL_GPL(phy_foo);
>>>>
>>>> and a header file would contain:
>>>>
>>>> extern struct phy_info phy_foo;
>>>>
>>>> The PHY supplier could then call phy_create(&phy_foo), and the PHY
>>>> client could call phy_find(&phy_foo).  Or something like that; make up
>>>> your own structure tags and function names.
>>>>
>>>> It's still possible to have conflicts, but now two PHYs with the same
>>>> name (or a misspelled name somewhere) will cause an error at link
>>>> time.
>>>
>>> This is incorrect, sorry. First of all it's a layering violation - you
>>> export random driver-specific symbols from one driver to another. Then
> 
> No, that's not what I said.  Neither the PHY driver nor the controller
> driver exports anything to the other.  Instead, both drivers use data
> exported by the board file.

I think instead we can use the same data while creating the platform data of
the controller and the PHY.
The PHY driver while creating the PHY (using PHY framework) will also pass the
*data* it actually got from the platform data to the framework.
The PHY user driver (USB), while requesting for the PHY (from the PHY
framework) will pass the *data* it got from its platform data.
The PHY framework can do a comparison of the *data* pointers it has and return
the appropriate PHY to the controller.
> 
>>> imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
>>> there are two types of consumer drivers (e.g. USB host controllers). Now
>>> consider following mapping:
>>>
>>> SoC	PHY	consumer
>>> A	PHY1	HOST1
>>> B	PHY1	HOST2
>>> C	PHY2	HOST1
>>> D	PHY2	HOST2
>>>
>>> So we have to be able to use any of the PHYs with any of the host
>>> drivers. This means you would have to export symbol with the same name
>>> from both PHY drivers, which obviously would not work in this case,
>>> because having both drivers enabled (in a multiplatform aware
>>> configuration) would lead to linking conflict.
> 
> You're right; the scheme was too simple.  Instead, the board file must
> export two types of data structures, one for PHYs and one for
> controllers.  Like this:
> 
> struct phy_info {
> 	/* Info for the controller attached to this PHY */
> 	struct controller_info	*hinfo;
> };
> 
> struct controller_info {
> 	/* Info for the PHY which this controller is attached to */
> 	struct phy_info		*pinfo;
> };
> 
> The board file for SoC A would contain:
> 
> struct phy_info phy1 = {&host1);
> EXPORT_SYMBOL(phy1);
> struct controller_info host1 = {&phy1};
> EXPORT_SYMBOL(host1);
> 
> The board file for SoC B would contain:
> 
> struct phy_info phy1 = {&host2);
> EXPORT_SYMBOL(phy1);
> struct controller_info host2 = {&phy1};
> EXPORT_SYMBOL(host2);

I meant something like this
struct phy_info {
	const char *name;
};

struct phy_platform_data {
	.
	.
	struct phy_info *info;
};

struct usb_controller_platform_data {
	.
	.
	struct phy_info *info;
};

struct phy_info phy_info;

While creating the phy device
	struct phy_platform_data phy_data;
	phy_data.info = &info;
	platform_device_add_data(pdev, &phy_data, sizeof(*phy_data))
	platform_device_add();

While creating the controller device
	struct usb_controller_platform_data controller_data;
	controller_data.info = &info;
	platform_device_add_data(pdev, &controller_data, sizeof(*controller_data))
	platform_device_add();

Then modify PHY framework API phy create
	phy_create((struct device *dev, const struct phy_ops *ops,
        void *priv)  {//API changed to take void pointer instead of label
		. //existing implementation
		.
		phy->priv = priv;
	}

	struct phy *phy_get(struct device *dev, const char *string, void *priv) {
//API changed to take an additional pointer
		phy_lookup(priv)
	}

	static struct phy *phy_lookup(void *priv) {
		.
		.
		if (phy->priv==priv) //instead of string comparison, we'll use pointer
			return phy;
	}

PHY driver should be like
	phy_create((dev, ops, pdata->info);

The controller driver would do
	phy_get(dev, NULL, pdata->info);

Now the PHY framework will check for a match of *priv* pointer and return the PHY.

I think this should be possible?

Thanks
Kishon


From julien.grall at linaro.org  Tue Jul 23 11:21:28 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Tue, 23 Jul 2013 16:21:28 +0100
Subject: [PATCH v5] xen/arm: enable PV control for ARM
Message-ID: <1374592888-5520-1-git-send-email-julien.grall@linaro.org>

Enable lifecyle management (reboot, shutdown...) from the toolstack
for ARM guest.

Signed-off-by: Julien Grall <julien.grall at linaro.org>

---
    Changes in v5:
        - Rework commit message
    Changes in v4:
        - Divide the patch in 2 distinct parts
    Changes in v3:
        - Fix condition to compile cpu_hotplug.o
    Changes in v2:
        - Don't compile xen/cpu_hotplug.o with ARM64
---
 drivers/xen/Makefile |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index a609353..f185e8d 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,9 +1,8 @@
 ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
-obj-y	+= manage.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 endif
 obj-$(CONFIG_X86)			+= fallback.o
-obj-y	+= grant-table.o features.o events.o balloon.o time.o
+obj-y	+= grant-table.o features.o events.o balloon.o time.o manage.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
-- 
1.7.10.4



From andrew at lunn.ch  Tue Jul 23 11:24:06 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 23 Jul 2013 17:24:06 +0200
Subject: [PATCH v8 00/28] MBus DT binding for Armada 370/XP and Kirkwood
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130723152406.GH6846@lunn.ch>

On Tue, Jul 23, 2013 at 10:31:04AM -0300, Ezequiel Garcia wrote:
> After Andrew Lunn reported [1] this work need to take account of Kirkwood
> to prevent breaking PCIe on such platform, here's a new version adding
> MBus DT binding for Kirkwood and in particular using it to declare PCIe
> properly.

Hi Ezequiel

I boot tested on my Kirkwood QNAP. Both DT and legacy style. Both boot
O.K. My device does not actually have any PCI devices on the bus, so
it is not too good a test. But at least the regression is gone.

Tested-by: Andrew Lunn <andrew at lunn.ch>

	   Andrew


From stefano.stabellini at eu.citrix.com  Tue Jul 23 11:28:53 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 23 Jul 2013 16:28:53 +0100
Subject: [PATCH v5] xen/arm: enable PV control for ARM
In-Reply-To: <1374592888-5520-1-git-send-email-julien.grall@linaro.org>
References: <1374592888-5520-1-git-send-email-julien.grall@linaro.org>
Message-ID: <alpine.DEB.2.02.1307231628330.4893@kaball.uk.xensource.com>

On Tue, 23 Jul 2013, Julien Grall wrote:
> Enable lifecyle management (reboot, shutdown...) from the toolstack
> for ARM guest.
              ^ guests

> Signed-off-by: Julien Grall <julien.grall at linaro.org>

Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>


> ---
>     Changes in v5:
>         - Rework commit message
>     Changes in v4:
>         - Divide the patch in 2 distinct parts
>     Changes in v3:
>         - Fix condition to compile cpu_hotplug.o
>     Changes in v2:
>         - Don't compile xen/cpu_hotplug.o with ARM64
> ---
>  drivers/xen/Makefile |    3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index a609353..f185e8d 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -1,9 +1,8 @@
>  ifeq ($(filter y, $(CONFIG_ARM) $(CONFIG_ARM64)),)
> -obj-y	+= manage.o
>  obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
>  endif
>  obj-$(CONFIG_X86)			+= fallback.o
> -obj-y	+= grant-table.o features.o events.o balloon.o time.o
> +obj-y	+= grant-table.o features.o events.o balloon.o time.o manage.o
>  obj-y	+= xenbus/
>  
>  nostackp := $(call cc-option, -fno-stack-protector)
> -- 
> 1.7.10.4
> 


From thierry.reding at gmail.com  Tue Jul 23 11:30:16 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 23 Jul 2013 08:30:16 -0700
Subject: [PATCH v4 00/20] Samsung PWM support cleanup
In-Reply-To: <2036745.TWe3OlGh9t@flatron>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <9102768.ef8LAvpunv@flatron> <0ac901ce867f$638a7530$2a9f5f90$@org>
 <2036745.TWe3OlGh9t@flatron>
Message-ID: <20130723153015.GA2066@dhcp-172-17-186-34.nvidia.com>

On Mon, Jul 22, 2013 at 09:49:49AM +0200, Tomasz Figa wrote:
> On Monday 22 of July 2013 11:01:32 Kukjin Kim wrote:
> > Kukjin Kim wrote:
> > > Tomasz Figa wrote:
> > > > On Monday 22 of July 2013 00:22:16 Sylwester Nawrocki wrote:
> > > > > On 07/20/2013 02:04 AM, Tomasz Figa wrote:
> > > > > > Since we now have a proper Samsung PWM clocksource driver in
> > > > > > place,
> > > > > > we can proceed with further cleanup of PWM timers support on
> > > > > > Samsung
> > > > > > SoCs.>
> > > > > > 
> > > > > > This series attempts to achieve this goal by:
> > > > > >   1) fixing up few things in samsung_pwm_timer clocksource
> > > > > >   driver,
> > > > > >   2) moving remaining Samsung platforms to the new clocksource
> > > 
> > > driver,
> > > 
> > > > > >   3) removing old clocksource driver,
> > > > > >   4) adding new multiplatform- and DT-aware PWM driver,
> > > > > >   5) moving all Samsung platforms to use the new PWM driver,
> > > > > >   6) removing old PWM driver,
> > > > > >   7) removing all PWM-related code that is not used anymore.
> > > > > > 
> > > > > > Cleaning up the PWM driver is a bit tricky, because the design
> > > > > > of
> > > > > > current driver makes it completely unsuitable for DT and
> > > > > > multiplatform and would require a heavy rework to make it
> > > > > > usable,
> > > > > > breaking any existing Samsung PWM users by the way. To avoid any
> > > > > > breakage this series first renames the old driver, then adds new
> > > > > > one
> > > > > > using original name, migrates all platforms to use it and then
> > > > > > finally removes the old driver.
> > > > > > 
> > > > > > See particular patches for more detailed descriptions.
> > > > > > 
> > > > > > [On S3C6410-based Tiny6410 (Mini6410-compatible) with
> > > > > > pwm-beeper,
> > > > > > SMDK6410 with PWM backlight and Exynos4210-based Origen board
> > > > > > (with
> > > > > > PWM0 attached to a scope)]
> > > > > > Tested-by: Tomasz Figa<tomasz.figa at gmail.com>
> > > > > > 
> > > > > > [On S3C2440-based Mini2440 board]
> > > > > > Tested-by: Sylwester Nawrocki<sylvester.nawrocki at gmail.com>
> > > > > 
> > > > > I have retested this series on top of v3.11-rc1 with pwm-backlight
> > > 
> > > (and
> > > 
> > > > > buzzer
> > > > > as the output :)) on Mini2440. It seems to work well - generated
> > > > > frequencies are correct. I'll check pulse widths with a scope
> > 
> > tomorrow,
> > 
> > > > > as it's a bit late
> > > > > now. FWIW you can add to this series my:
> > > > > 
> > > > > Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> > > > 
> > > > Thanks. I hope we can finally get this series merged soon.
> > > 
> > > Yes, this whole patches look good to me, and I'd like to take this
> > > whole patches into the samsung tree...but need to get any response
> > > from PWM guy, Thierry Reding. Let's wait for his response...
> > 
> > To be clarify, because his ack was on v3 and I remember he had a
> > comment. So would be better if we could get his ack on pwm change
> > again.
> 
> Sure.

Patches 12, 13 and 16:

Acked-by: Thierry Reding <thierry.reding at gmail.com>
-------------- 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/20130723/6a086acb/attachment.sig>

From Sudeep.KarkadaNagesha at arm.com  Tue Jul 23 11:34:36 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Tue, 23 Jul 2013 16:34:36 +0100
Subject: [PATCH 4/5] ARM: highbank: remove redundant smp_init_cpus
 definition
In-Reply-To: <51EE9B38.5030003@gmail.com>
References: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374579164-30255-5-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <51EE9B38.5030003@gmail.com>
Message-ID: <51EEA28C.9070506@arm.com>

On 23/07/13 16:03, Rob Herring wrote:
> On 07/23/2013 06:32 AM, Sudeep KarkadaNagesha wrote:
>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>>
>> arm_dt_init_cpu_maps is called before smp_init_cpus, which sets the
>> cpu_possible_mask appropriately. Since highbank_smp_init_cpus does
>> nothing extra, it can be removed.
> 
> This is all going to get removed in my PSCI support series. Trying to
> get an updated version out soon.
> 
Thanks for the update.

Regards,
Sudeep




From ezequiel.garcia at free-electrons.com  Tue Jul 23 11:36:47 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 12:36:47 -0300
Subject: [PATCH v8 00/28] MBus DT binding for Armada 370/XP and Kirkwood
In-Reply-To: <20130723152406.GH6846@lunn.ch>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <20130723152406.GH6846@lunn.ch>
Message-ID: <20130723153645.GA5296@localhost>

On Tue, Jul 23, 2013 at 05:24:06PM +0200, Andrew Lunn wrote:
> On Tue, Jul 23, 2013 at 10:31:04AM -0300, Ezequiel Garcia wrote:
> > After Andrew Lunn reported [1] this work need to take account of Kirkwood
> > to prevent breaking PCIe on such platform, here's a new version adding
> > MBus DT binding for Kirkwood and in particular using it to declare PCIe
> > properly.
> 
> Hi Ezequiel
> 
> I boot tested on my Kirkwood QNAP. Both DT and legacy style. Both boot
> O.K. My device does not actually have any PCI devices on the bus, so
> it is not too good a test. But at least the regression is gone.
> 
> Tested-by: Andrew Lunn <andrew at lunn.ch>
> 

Good!

Huge thanks for the test!

Jason: How about picking this up? As I already said, I think it's better
to have this merged sooner than later, and get people to start using it.

I'm ready to fix at once whatever issues might appear.
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From thierry.reding at gmail.com  Tue Jul 23 11:37:49 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 23 Jul 2013 08:37:49 -0700
Subject: [PATCH v2 0/4] Add PWM polarity flag macro for DT
In-Reply-To: <10033310.z2U2FSCElN@avalon>
References: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <51E81E1C.20708@wwwdotorg.org> <10033310.z2U2FSCElN@avalon>
Message-ID: <20130723153748.GC2066@dhcp-172-17-186-34.nvidia.com>

On Fri, Jul 19, 2013 at 01:29:13PM +0200, Laurent Pinchart wrote:
> Hi Stephen,
> 
> On Thursday 18 July 2013 10:55:56 Stephen Warren wrote:
> > On 07/17/2013 04:54 PM, Laurent Pinchart wrote:
> > > Hello,
> > > 
> > > Here's a small patch set that replaces PWM polarity numerical constants
> > > with macros in DT.
> > 
> > The series,
> > Reviewed-by: Stephen Warren <swarren at nvidia.com>
> > 
> > I'm (very very) slightly hesitant about patch 3/4, since it's moving towards
> > all PWMs having to use the same specifier format, whereas specifiers are at
> > least potentially binding-specific, not device-type-specific. However,
> > consistency is good; there's no need to do something different just for the
> > heck of it. Equally, there's nothing actually stopping a new binding from
> > defining its own format rather than simply deferring to pwm.txt if it
> > absolutely has to, so I think this will turn out fine.
> 
> Exactly, that's why I don't think it's an issue. pwm.txt defines a common 
> format, individual bindings are free to use it or not.
> 
> Thierry, if you're fine with the patches, could you take them in your tree 
> with Stephen's Reviewed-by, or should I report them and send you a pull 
> request ?

They look good to me. I'll take them into my tree and add Stephen's
Reviwed-by. It might take me another week, though, as I'm currently
rather busy with other things.

Thierry
-------------- 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/20130723/07ae3e46/attachment-0001.sig>

From jonathan.austin at arm.com  Tue Jul 23 11:42:16 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Tue, 23 Jul 2013 16:42:16 +0100
Subject: [PATCH 0/2] Restore Integrator/CP CLCD to fully working state
Message-ID: <1374594138-17080-1-git-send-email-jonathan.austin@arm.com>

Over time and with refactoring, the use of the Integrator/CP LCD seems to have
broken.

This series restores the ability to use the Integrator's CLCD and an external
VGA display.

Jonathan Austin (2):
  ARM: integrator_cp: Set LCD{0,1} enable lines when turning on CLCD
  clk: fixup argument order when setting VCO parameters

 arch/arm/mach-integrator/integrator_cp.c |    3 ++-
 drivers/clk/versatile/clk-icst.c         |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

-- 
1.7.9.5




From jonathan.austin at arm.com  Tue Jul 23 11:42:17 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Tue, 23 Jul 2013 16:42:17 +0100
Subject: [PATCH 1/2] ARM: integrator_cp: Set LCD{0,
 1} enable lines when turning on CLCD
In-Reply-To: <1374594138-17080-1-git-send-email-jonathan.austin@arm.com>
References: <1374594138-17080-1-git-send-email-jonathan.austin@arm.com>
Message-ID: <1374594138-17080-2-git-send-email-jonathan.austin@arm.com>

This turns on the internal integrator LCD display(s). It seems that the code
to do this got lost in refactoring of the CLCD driver.

Cc: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Jonathan Austin <jonathan.austin at arm.com>
---
 arch/arm/mach-integrator/integrator_cp.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-integrator/integrator_cp.c b/arch/arm/mach-integrator/integrator_cp.c
index 8c60fcb..2f4c9248 100644
--- a/arch/arm/mach-integrator/integrator_cp.c
+++ b/arch/arm/mach-integrator/integrator_cp.c
@@ -199,7 +199,8 @@ static struct mmci_platform_data mmc_data = {
 static void cp_clcd_enable(struct clcd_fb *fb)
 {
 	struct fb_var_screeninfo *var = &fb->fb.var;
-	u32 val = CM_CTRL_STATIC1 | CM_CTRL_STATIC2;
+	u32 val = CM_CTRL_STATIC1 | CM_CTRL_STATIC2
+			| CM_CTRL_LCDEN0 | CM_CTRL_LCDEN1;
 
 	if (var->bits_per_pixel <= 8 ||
 	    (var->bits_per_pixel == 16 && var->green.length == 5))
-- 
1.7.9.5




From jonathan.austin at arm.com  Tue Jul 23 11:42:18 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Tue, 23 Jul 2013 16:42:18 +0100
Subject: [PATCH 2/2] clk: fixup argument order when setting VCO parameters
In-Reply-To: <1374594138-17080-1-git-send-email-jonathan.austin@arm.com>
References: <1374594138-17080-1-git-send-email-jonathan.austin@arm.com>
Message-ID: <1374594138-17080-3-git-send-email-jonathan.austin@arm.com>

The order of arguments in the call to vco_set() for the ICST clocks appears to
have been switched in error, which results in the VCO not being initialised
correctly. This in turn stops the integrated LCD on things like Integrator/CP
from working correctly.

This patch fixes the order and restores the expected functionality.

Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Mike Turquette <mturquette at linaro.org>
Signed-off-by: Jonathan Austin <jonathan.austin at arm.com>
---
 drivers/clk/versatile/clk-icst.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/versatile/clk-icst.c b/drivers/clk/versatile/clk-icst.c
index 67ccf4a..f5e4c21 100644
--- a/drivers/clk/versatile/clk-icst.c
+++ b/drivers/clk/versatile/clk-icst.c
@@ -107,7 +107,7 @@ static int icst_set_rate(struct clk_hw *hw, unsigned long rate,
 
 	vco = icst_hz_to_vco(icst->params, rate);
 	icst->rate = icst_hz(icst->params, vco);
-	vco_set(icst->vcoreg, icst->lockreg, vco);
+	vco_set(icst->lockreg, icst->vcoreg, vco);
 	return 0;
 }
 
-- 
1.7.9.5




From thierry.reding at gmail.com  Tue Jul 23 11:44:39 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 23 Jul 2013 08:44:39 -0700
Subject: [PATCH V4 2/4] ARM: tegra114: Reprogram GIC CPU interface to
 bypass IRQ on CPU PM entry
In-Reply-To: <1374225926-26832-3-git-send-email-josephl@nvidia.com>
References: <1374225926-26832-1-git-send-email-josephl@nvidia.com>
 <1374225926-26832-3-git-send-email-josephl@nvidia.com>
Message-ID: <20130723154438.GA2864@dhcp-172-17-186-34.nvidia.com>

On Fri, Jul 19, 2013 at 05:25:24PM +0800, Joseph Lo wrote:
> There is a difference between GICv1 and v2 when CPU in power management
> mode (aka CPU power down on Tegra). For GICv1, IRQ/FIQ interrupt lines
> going to CPU are same lines which are also used for wake-interrupt.
> Therefore, we cannot disable the GIC CPU interface if we need to use same
> interrupts for CPU wake purpose. This creates a race condition for CPU
> power off entry. Also, in GICv1, disabling GICv1 CPU interface puts GICv1
> into bypass mode such that incoming legacy IRQ/FIQ are sent to CPU, which
> means disabling GIC CPU interface doesn't really disable IRQ/FIQ to CPU.
> 
> GICv2 provides a wake IRQ/FIQ (for wake-event purpose), which are not
> disabled by GIC CPU interface. This is done by adding a bypass override
> capability when the interrupts are disabled at the CPU interface. To
> support this, there are four bits about IRQ/FIQ BypassDisable in CPU
> interface Control Register. When the IRQ/FIQ not being driver by the
> CPU interface, each interrupt output signal can be deasserted rather
> than being driven by the legacy interrupt input.
> 
> So the wake-event can be used as wakeup signals to SoC (system power
> controller).
> 
> To prevent race conditions and ensure proper interrupt routing on
> Cortex-A15 CPUs when they are power-gated, add a CPU PM notifier
> call-back to reprogram the GIC CPU interface on PM entry. The
> GIC CPU interface will be reset back to its normal state by
> the common GIC CPU PM exit callback when the CPU wakes up.
> 
> Based on the work by: Scott Williams <scwilliams at nvidia.com>
> 
> Signed-off-by: Joseph Lo <josephl at nvidia.com>

Hi Joseph,

We've had a rather long-standing issue with PCIe and MSI related to LP2
on Tegra20. I wonder if that's somehow related to this. Given that this
is marked as Tegra114 patch explicitly I suppose not, but it certainly
sounds very similar to the description above.

Thierry
-------------- 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/20130723/8bc7f376/attachment.sig>

From swarren at wwwdotorg.org  Tue Jul 23 11:47:22 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 23 Jul 2013 08:47:22 -0700
Subject: Issue with gpio and pinmux
In-Reply-To: <20130722083535.GA19685@ab42.lan>
References: <51E667BC.3070804@parrot.com> <51E82FBB.1080905@wwwdotorg.org>
 <CACRpkdb1n07KoQZSme1EMJfV-9pHr-kd_1eJ6HsBV5gz7Dh3Ww@mail.gmail.com>
 <51EB590A.4010600@wwwdotorg.org> <20130722083535.GA19685@ab42.lan>
Message-ID: <51EEA58A.30206@wwwdotorg.org>

On 07/22/2013 01:35 AM, Christian Ruppert wrote:
> On Sat, Jul 20, 2013 at 09:44:10PM -0600, Stephen Warren wrote:
>> On 07/20/2013 04:44 PM, Linus Walleij wrote:
>>> On Thu, Jul 18, 2013 at 8:11 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>
>>>> The issue is that some HW muxes groups of pins at a time, so simply
>>>> because that group of pins is "claimed" by a mux function, implies
>>>> nothing about which specific pins in that group are actually used; some
>>>> may actually still be free for usage as a GPIO.
>>>
>>> This we need to get into the documentation.
>>>
>>>> The solution here may be one of:
>>>>
>>>> a) Modify pinctrl /not/ to allow both a GPIO and a mux function to claim
>>>> a pin *if* the group that contains the pin only contains a single pin.
>>>> This is a bit of a hacky special case though; there are other situations
>>>> where "dual claiming" shouldn't be allowed, and this doesn't solve those.
>>>>
>>>> b) Ignore the issue; if the system configuration is correct, the issue
>>>> won't cause problems in practice, since nothing will be configured to
>>>> "dual claim" any pin.
>>>>
>>>> c) Enhance pinctrl with extra information, so it knows which pins in a
>>>> group are usable as GPIO even when the group is claimed by a mux
>>>> function. The list of pins could theoretically vary per mux function, so
>>>> you'd need a table with lookup key (pin group, mux function) and output
>>>> data (list of pins that can be "dual claimed"). This would be a complete
>>>> solution. If a list wasn't provided, the pinctrl core could assume that
>>>> mean no dual claim was allowed.
>>>
>>> I guess (b) is what we have.
>>>
>>> But it really feels incomplete does it not? IIRC the system was strict
>>> not to allow simultaneous use of pins for GPIO and other functions
>>> at all until the above corner case made it necessary to relax this
>>> restriction.
>>>
>>> A simple way to get (a) would be to just add a flag like ".strict"
>>> to struct pinmux_ops but it feels cheap.
>>>
>>> What do we need for (c)? I think we can refactor this as the Tegra
>>> and U300 should be the two platforms with such tricky groups so
>>> the impact should be fairly small right now. I'm just worried it would
>>> be a complex and memory-consuming thing :-/
>>
>> Actually, a better way to do (c) might be to just add an extra "op" to
>> struct pinmux_ops; something like validate_gpio_mux(), passing in
>> information such as whether a mux function is in effect on that pin,
>> whether the pin is already claimed as a GPIO, and whether the function
>> is being called to check a GPIO-claim or mux-claim operation . If the op
>> is missing, no "dual claim" is allowed. If the op is present, the code
>> in the op validates whether the particular GPIO is allowed to be claimed
>> while the particular mux function is active.
>>
>> That way, I think any driver that doesn't want to allow dual-claim
>> doesn't have to do anything, but the few drivers that do can code up
>> whatever algorithm they want; for Tegra, I'd just allow everything for
>> simplicity, but we could always enhance that later if we want.
> 
> [ An introductory note on terminology: in the following, "port" refers
> to a set of pins who's mux is controlled through the same bit field in
> the same register,

I believe that's exactly what a "pingroup" is in pinctrl subsystem
terminology. Where there is already an existing name for something, it'd
be best to use that so that every person doesn't use a different name
for everything.

> "interface" refers to the set of pins comprising a
> functional unit, e.g. SCL and SDA of an I2C interface or the four pins
> of an SPI interface ]
> 
> In my understanding, the problem stems from the fact that we always
> claim an entire port instead of just the pins required for a given
> functionality.

Yes.

> The pinctrl core is already well equipped to manage
> claiming interfaces instead of ports and thus a fourth alternative would
> be to

I would argue that's not the case. pinctrl knows absolutely nothing
about "interfaces"; there is no data structure defines that describes
interfaces at all.

That's not saying such a thing could not be added; I'm simply arguing
that "well equipped" doesn't seem to be true at the moment.

> d) implement gpio/pin conflict management in the already existing
> callbacks inside the driver: Today, both enable and gpio_request_enable
> exist (and can refuse a request for a configuration/pin).
> If we only claim the pins used by a given interface instead of the
> entire port, conflict management becomes natural (see
> http://lkml.indiana.edu/hypermail/linux/kernel/1306.2/00749.html and the
> following).

OK, that's basically the same as my proposal to add a new callback; it's
simply re-using and existing driver callback rather than creating a new
one solely for conflict checking.

Re-using the existing callback(s) seems fine, with appropriate prototype
modification to pass back the list of pins that can-or-can't be
dual-claimed I suppose.

> IMHO, the pinctrl drivers are the right place for everything but the
> most basic pin conflict management since constraints on what can be
> muxed at the same time are highly hardware implementation dependent. One
> could e.g. imagine an implementation where a GPIO can override and snoop
> a pin's output value in one mux configuration, just snoop the pin value
> in another and do neither in a third.
> 
> I see two (independent) ways to enhance the pinctrl core in order to
> support drivers in this task:
> a) Add two functions pin_is_claimed and gpio_is_claimed which allow the
> pinctrl driver to query if a given pin/gpio is available for muxing.
> b) Add four functions lock_gpio/unlock_gpio and lock_pin/unlock_pin
> which allow the pinctrl driver to prevent the core from granting
> requests on GPIOs/pins.

Yes, either of those are basically what I proposed in my followup to the
email you're replying to.

> This solution also has the advantage that it doesn't modify the default
> behaviour of the core and it thus won't break existing drivers.



From swarren at nvidia.com  Tue Jul 23 12:01:38 2013
From: swarren at nvidia.com (Stephen Warren)
Date: Tue, 23 Jul 2013 09:01:38 -0700
Subject: [PATCH] pinctrl: fix a memleak when freeing maps
In-Reply-To: <1374536739-18966-1-git-send-email-linus.walleij@linaro.org>
References: <1374536739-18966-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <51EEA8E2.6020003@nvidia.com>

On 07/22/2013 04:45 PM, Linus Walleij wrote:
> We forgot to free the node itself when free:ing a map.
> 
> Reported-by: xulinuxkernel <xulinuxkernel at gmail.com>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

Reviewed-by: Stephen Warren <swarren at nvidia.com>

The full name in the reported-by doesn't look accurate, but I suppose
that isn't an s-o-b entry, so it's not a big deal.


From will.deacon at arm.com  Tue Jul 23 12:04:59 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Jul 2013 17:04:59 +0100
Subject: [PATCH 3/4] arm64: KVM: let other tasks run when hitting WFE
In-Reply-To: <20130723104113.GE3748@MacBook-Pro.local>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
 <CAC4Lta17bmNjBck6LzziBeU0Xc36F1Jms2tQPv6+GaXvik6Wyg@mail.gmail.com>
 <CAMJs5B8Sg1MPHPsRV75mmagnYxkhzA0MKWVkwW2y0WdDVWTSxQ@mail.gmail.com>
 <20130723104113.GE3748@MacBook-Pro.local>
Message-ID: <20130723160459.GN30942@mudshark.cambridge.arm.com>

On Tue, Jul 23, 2013 at 11:41:14AM +0100, Catalin Marinas wrote:
> On Mon, Jul 22, 2013 at 01:51:52PM +0100, Christoffer Dall wrote:
> > On 22 July 2013 10:53, Raghavendra KT <raghavendra.kt.linux at gmail.com> wrote:
> > > On Fri, Jul 19, 2013 at 7:23 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> > >> So far, when a guest executes WFE (like when waiting for a spinlock
> > >> to become unlocked), we don't do a thing and let it run uninterrupted.
> > >>
> > >> Another option is to trap a blocking WFE and offer the opportunity
> > >> to the scheduler to switch to another task, potentially giving the
> > >> vcpu holding the spinlock a chance to run sooner.
> > >>
> > >
> > > Idea looks to be correct from my experiments on x86. It does bring some
> > > percentage of benefits in overcommitted guests. Infact,
> > >
> > > https://lkml.org/lkml/2013/7/22/41 tries to do the same thing for x86.
> > > (this results in using ple handler heuristics in vcpu_block pach).
> > 
> > What about the adverse effect in the non-overcommitted case?
> 
> Could we not detect overcommitment and only set the TWE bit in this case
> (per VCPU scheduled to run)?
> 
> The advantage of a properly para-virtualised lock is that you can target
> which VCPU to wake up. I don't think we can do this currently (without
> assumptions about the underlying OS and how the compiler allocates
> registers in the ticket spinlocks).
> 
> There have been suggestions to use WFE in user-space for a more power
> efficient busy loop (usually in user-only locking, I think some
> PostreSQL does that) together with an automatic even stream for waking
> up the WFE (Sudeep posted some patches recently for enabling 100us event
> stream). If such feature gets used, we have a new meaning for WFE and we
> may not want to trap it all the time.
> 
> Question for Will - do we have a PMU counter for WFE? (don't ask why ;))

Step away from the CPU! There's nothing architected for counting wfe
instructions so, although a CPU might expose such an event, software can't
rely on it.

Will


From bhelgaas at google.com  Tue Jul 23 12:06:26 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Tue, 23 Jul 2013 10:06:26 -0600
Subject: Linux Plumbers ACPI/PM, PCI Microconference
In-Reply-To: <CAL-B5D03ki8NHsM6EuESTH2K-Eh+XyFHNXPDYwgDq+oagDjtMQ@mail.gmail.com>
References: <CAL-B5D03ki8NHsM6EuESTH2K-Eh+XyFHNXPDYwgDq+oagDjtMQ@mail.gmail.com>
Message-ID: <CAErSpo7TexM5-7Z=8H+B5=49-GzoKd_prn=LbMFZWV9rpdn__A@mail.gmail.com>

On Tue, Jul 16, 2013 at 8:21 PM, Myron Stowe <myron.stowe at gmail.com> wrote:
> Linux Plumbers has approved an ACPI/PM, PCI microconference. The
> overview page is here:
>
> http://wiki.linuxplumbersconf.org/2013:pci_subsystem
>
> We would like to start receiving volunteers for presenting topics of
> interest.  There is a lot of activity in these subsystems so please
> respond by submitting presentation or discussion proposals that you
> would be willing to cover for consideration.  You should also feel
> free to submit ideas as proposals that others could cover.

Somebody else privately suggested these ARM/PCI topics:

> -> how it's been cleaned up to be more common across arm-32 machines
> -> dependencies on dtb
> -> future use/dependency(s) on ACPI
> -> hotplug support issues (if any; acpi (host-bridge) vs <whatever ARM uses> ?)

and I'm interested in those as well.  There seems to be a lot of
activity in that area.  In addition, I'm interested in ARM IOMMU
support.  I see drivers/iommu/arm-smmu.c, but it's brand-new and I
haven't looked at it at all.

Bjorn


From swarren at wwwdotorg.org  Tue Jul 23 12:14:11 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 23 Jul 2013 09:14:11 -0700
Subject: [PATCH V2 1/5] gpio: clean up gpio-ranges documentation
In-Reply-To: <CACRpkdYsZ0aMnANPpTiGuD1U23PCqyvVGS7vOOnOQUks5KSk9g@mail.gmail.com>
References: <1373913629-32179-1-git-send-email-swarren@wwwdotorg.org>
 <CACRpkdYsZ0aMnANPpTiGuD1U23PCqyvVGS7vOOnOQUks5KSk9g@mail.gmail.com>
Message-ID: <51EEABD3.6000307@wwwdotorg.org>

On 07/22/2013 03:31 PM, Linus Walleij wrote:
> On Mon, Jul 15, 2013 at 8:40 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> 
>> This change makes documentation of the the gpio-ranges property shorter
>> and more succinct, more consistent with the style of the rest of the
>> document, and not mention Linux-specifics such as the API
>> pinctrl_request_gpio(); DT binding documents should be OS independant
>> where at all possible.
>>
>> This change also removes any mention of the #gpio-range-cells property.
>> Such properties are useful when one node references a second node, and
>> that second node dictates the format of the reference. However, that is
>> not the case here; the definition of gpio-ranges itself always dictates
>> its format entirely, and hence the value #gpio-range-cells must always
>> be 3, and hence there is no point requiring any referenced node to
>> include this property.

>> +It is useful to represent which GPIOs correspond to which pins on which pin
>> +controllers. The gpio-ranges property described below represents this, and
>> +contains information strucutres as follows:
> 
> speling of strucutres
> 
> Should you mention that this is given in BNF?
> Or is that implicit for all bindings?

The rest of the document already has a couple of other sections written
that way, so explicitly mentioning BNF seems like a logically unrelated
patch to fix a separate issue in the document. I didn't actually check
whether the syntax used here is strictly BNF either:-) Either way
though, I think it's easy enough to read the BNF without having to
explicitly know it's BNF or anything in-particular, so I'd err on the
side of not bothering to mention that myself...

I'll fix the other issues you mentioned locally, and wait for an ack for
drivers/of before reposting.


From gregkh at linuxfoundation.org  Tue Jul 23 12:18:46 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 23 Jul 2013 09:18:46 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51EE9EC0.6060905@ti.com>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <51EE9EC0.6060905@ti.com>
Message-ID: <20130723161846.GD2486@kroah.com>

On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
> > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > 
> >> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> >>> Hi Alan,
> > 
> > Thanks for helping to clarify the issues here.
> > 
> >>>> Okay.  Are PHYs _always_ platform devices?
> >>>
> >>> They can be i2c, spi or any other device types as well.
> > 
> > In those other cases, presumably there is no platform data associated
> > with the PHY since it isn't a platform device.  Then how does the
> > kernel know which controller is attached to the PHY?  Is this spelled
> > out in platform data associated with the PHY's i2c/spi/whatever parent?
> 
> Yes. I think we could use i2c_board_info for passing platform data.
> > 
> >>>>>> 	PHY.  Currently this information is represented by name or 
> >> ID
> >>>>>> 	strings embedded in platform data.
> >>>>>
> >>>>> right. It's embedded in the platform data of the controller.
> >>>>
> >>>> It must also be embedded in the PHY's platform data somehow.
> >>>> Otherwise, how would the kernel know which PHY to use?
> >>>
> >>> By using a PHY lookup as Stephen and I suggested in our previous
> >>> replies. Without any extra data in platform data. (I have even posted a
> >>> code example.)
> > 
> > I don't understand, because I don't know what "a PHY lookup" does.
> 
> It is how the PHY framework finds a PHY, when the controller (say USB)requests
> a PHY from the PHY framework.
> > 
> >>>> In this case, it doesn't matter where the platform_device structures
> >>>> are created or where the driver source code is.  Let's take a simple
> >>>> example.  Suppose the system design includes a PHY named "foo".  Then
> >>>> the board file could contain:
> >>>>
> >>>> struct phy_info { ... } phy_foo;
> >>>> EXPORT_SYMBOL_GPL(phy_foo);
> >>>>
> >>>> and a header file would contain:
> >>>>
> >>>> extern struct phy_info phy_foo;
> >>>>
> >>>> The PHY supplier could then call phy_create(&phy_foo), and the PHY
> >>>> client could call phy_find(&phy_foo).  Or something like that; make up
> >>>> your own structure tags and function names.
> >>>>
> >>>> It's still possible to have conflicts, but now two PHYs with the same
> >>>> name (or a misspelled name somewhere) will cause an error at link
> >>>> time.
> >>>
> >>> This is incorrect, sorry. First of all it's a layering violation - you
> >>> export random driver-specific symbols from one driver to another. Then
> > 
> > No, that's not what I said.  Neither the PHY driver nor the controller
> > driver exports anything to the other.  Instead, both drivers use data
> > exported by the board file.
> 
> I think instead we can use the same data while creating the platform data of
> the controller and the PHY.
> The PHY driver while creating the PHY (using PHY framework) will also pass the
> *data* it actually got from the platform data to the framework.
> The PHY user driver (USB), while requesting for the PHY (from the PHY
> framework) will pass the *data* it got from its platform data.
> The PHY framework can do a comparison of the *data* pointers it has and return
> the appropriate PHY to the controller.
> > 
> >>> imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
> >>> there are two types of consumer drivers (e.g. USB host controllers). Now
> >>> consider following mapping:
> >>>
> >>> SoC	PHY	consumer
> >>> A	PHY1	HOST1
> >>> B	PHY1	HOST2
> >>> C	PHY2	HOST1
> >>> D	PHY2	HOST2
> >>>
> >>> So we have to be able to use any of the PHYs with any of the host
> >>> drivers. This means you would have to export symbol with the same name
> >>> from both PHY drivers, which obviously would not work in this case,
> >>> because having both drivers enabled (in a multiplatform aware
> >>> configuration) would lead to linking conflict.
> > 
> > You're right; the scheme was too simple.  Instead, the board file must
> > export two types of data structures, one for PHYs and one for
> > controllers.  Like this:
> > 
> > struct phy_info {
> > 	/* Info for the controller attached to this PHY */
> > 	struct controller_info	*hinfo;
> > };
> > 
> > struct controller_info {
> > 	/* Info for the PHY which this controller is attached to */
> > 	struct phy_info		*pinfo;
> > };
> > 
> > The board file for SoC A would contain:
> > 
> > struct phy_info phy1 = {&host1);
> > EXPORT_SYMBOL(phy1);
> > struct controller_info host1 = {&phy1};
> > EXPORT_SYMBOL(host1);
> > 
> > The board file for SoC B would contain:
> > 
> > struct phy_info phy1 = {&host2);
> > EXPORT_SYMBOL(phy1);
> > struct controller_info host2 = {&phy1};
> > EXPORT_SYMBOL(host2);
> 
> I meant something like this
> struct phy_info {
> 	const char *name;
> };
> 
> struct phy_platform_data {
> 	.
> 	.
> 	struct phy_info *info;
> };
> 
> struct usb_controller_platform_data {
> 	.
> 	.
> 	struct phy_info *info;
> };
> 
> struct phy_info phy_info;
> 
> While creating the phy device
> 	struct phy_platform_data phy_data;
> 	phy_data.info = &info;
> 	platform_device_add_data(pdev, &phy_data, sizeof(*phy_data))
> 	platform_device_add();
> 
> While creating the controller device
> 	struct usb_controller_platform_data controller_data;
> 	controller_data.info = &info;
> 	platform_device_add_data(pdev, &controller_data, sizeof(*controller_data))
> 	platform_device_add();
> 
> Then modify PHY framework API phy create
> 	phy_create((struct device *dev, const struct phy_ops *ops,
>         void *priv)  {//API changed to take void pointer instead of label
> 		. //existing implementation
> 		.
> 		phy->priv = priv;
> 	}
> 
> 	struct phy *phy_get(struct device *dev, const char *string, void *priv) {
> //API changed to take an additional pointer
> 		phy_lookup(priv)
> 	}
> 
> 	static struct phy *phy_lookup(void *priv) {
> 		.
> 		.
> 		if (phy->priv==priv) //instead of string comparison, we'll use pointer
> 			return phy;
> 	}
> 
> PHY driver should be like
> 	phy_create((dev, ops, pdata->info);
> 
> The controller driver would do
> 	phy_get(dev, NULL, pdata->info);
> 
> Now the PHY framework will check for a match of *priv* pointer and return the PHY.
> 
> I think this should be possible?

Ick, no.  Why can't you just pass the pointer to the phy itself?  If you
had a "priv" pointer to search from, then you could have just passed the
original phy pointer in the first place, right?

The issue is that a string "name" is not going to scale at all, as it
requires hard-coded information that will change over time (as the
existing clock interface is already showing.)

Please just pass the real "phy" pointer around, that's what it is there
for.  Your "board binding" logic/code should be able to handle this, as
it somehow was going to do the same thing with a "name".

thanks,

greg k-h


From tj at kernel.org  Tue Jul 23 12:26:23 2013
From: tj at kernel.org (Tejun Heo)
Date: Tue, 23 Jul 2013 12:26:23 -0400
Subject: [v3 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <0E83723C55F66F43A6041464FE31119D3441A3@039-SN2MPN1-011.039d.mgd.msft.net>
References: <1373017942-12583-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373017942-12583-4-git-send-email-Hong-Xing.Zhu@freescale.com>
 <20130705174305.GA28088@mtj.dyndns.org>
 <0E83723C55F66F43A6041464FE31119D31432D@039-SN2MPN1-012.039d.mgd.msft.net>
 <20130706020737.GA9029@mtj.dyndns.org>
 <0E83723C55F66F43A6041464FE31119D3441A3@039-SN2MPN1-011.039d.mgd.msft.net>
Message-ID: <20130723162623.GD21100@mtj.dyndns.org>

Hello,

On Mon, Jul 22, 2013 at 07:02:56AM +0000, Zhu Richard-R65037 wrote:
> Re-send this email to you and community.
> I'm afraid that you may be missed or don't receive it.

Sorry about the delay.  I was on the road.

> BTW, can you help to pick up the #2 and #3(reviewed and acked by Shawn) of the v7 patch-set of this serial?
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Just one thing, can you please rename the driver to ahci_imx?  I'd
like to keep all ahci drivers with ahci prefix (yeah, there's already
an exception, I know).

Thanks.

-- 
tejun


From kishon at ti.com  Tue Jul 23 12:28:34 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 23 Jul 2013 21:58:34 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130723161846.GD2486@kroah.com>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <51EE9EC0.6060905@ti.com> <20130723161846.GD2486@kroah.com>
Message-ID: <51EEAF32.4040905@ti.com>

Hi Greg,

On Tuesday 23 July 2013 09:48 PM, Greg KH wrote:
> On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
>>> On Tue, 23 Jul 2013, Tomasz Figa wrote:
>>>
>>>> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
>>>>> Hi Alan,
>>>
>>> Thanks for helping to clarify the issues here.
>>>
>>>>>> Okay.  Are PHYs _always_ platform devices?
>>>>>
>>>>> They can be i2c, spi or any other device types as well.
>>>
>>> In those other cases, presumably there is no platform data associated
>>> with the PHY since it isn't a platform device.  Then how does the
>>> kernel know which controller is attached to the PHY?  Is this spelled
>>> out in platform data associated with the PHY's i2c/spi/whatever parent?
.
.
<snip>
.
.
>>
>> 	static struct phy *phy_lookup(void *priv) {
>> 		.
>> 		.
>> 		if (phy->priv==priv) //instead of string comparison, we'll use pointer
>> 			return phy;
>> 	}
>>
>> PHY driver should be like
>> 	phy_create((dev, ops, pdata->info);
>>
>> The controller driver would do
>> 	phy_get(dev, NULL, pdata->info);
>>
>> Now the PHY framework will check for a match of *priv* pointer and return the PHY.
>>
>> I think this should be possible?
> 
> Ick, no.  Why can't you just pass the pointer to the phy itself?  If you
> had a "priv" pointer to search from, then you could have just passed the
> original phy pointer in the first place, right?
> 
> The issue is that a string "name" is not going to scale at all, as it
> requires hard-coded information that will change over time (as the
> existing clock interface is already showing.)
> 
> Please just pass the real "phy" pointer around, that's what it is there
> for.  Your "board binding" logic/code should be able to handle this, as
> it somehow was going to do the same thing with a "name".

The problem is the board file won't have the *phy* pointer. *phy* pointer is
created at a much later time when the phy driver is probed.

Thanks
Kishon


From lorenzo.pieralisi at arm.com  Tue Jul 23 12:33:19 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 23 Jul 2013 17:33:19 +0100
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <alpine.LFD.2.03.1307230821270.15022@syhkavp.arg>
References: <1374118116-16836-2-git-send-email-nicolas.pitre@linaro.org>
 <20130718150408.GB2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181231510.14924@syhkavp.arg>
 <20130718180323.GC2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181452480.14924@syhkavp.arg>
 <20130719102844.GA3746@localhost.localdomain>
 <20130719105907.GB27389@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307221353360.15022@syhkavp.arg>
 <20130723104352.GA3023@localhost.localdomain>
 <alpine.LFD.2.03.1307230821270.15022@syhkavp.arg>
Message-ID: <20130723163319.GA781@e102568-lin.cambridge.arm.com>

On Tue, Jul 23, 2013 at 01:28:16PM +0100, Nicolas Pitre wrote:

[...]

> > > + * - The CPU is obviously no longer coherent with the other CPUs.
> > > + *
> > > + * Further considerations:
> > > + *
> > > + * - This relies on the presence and behavior of the AUXCR.SMP bit as
> > > + *   documented in the ARMv7 TRM.  Vendor implementations that deviate from
> > 
> > Sorry to be pedantic here, but there is no "ARMv7 TRM".  The SMP bit is
> > not part of ARMv7 at all.
> 
> Well, I just copied Lorenzo's words here, trusting he knew more about it 
> than I do.
> 
> > Also, it seems that A9 isn't precisely the
> > same: two ACTLR bits need to be twiddled.  R-class CPUs are generally
> > not the same either.

If you mean the ACTLR.FW bit in A9, A5, and R7, then, IIRC, we do not need to
clear it, clearing the SMP bit is enough.

See, Dave has a point, there is no explicit "unified v7 TRM disable
clean and exit coherency procedure" even though the designers end goal is to
have one and that's the one you wrote. The code you posted is perfectly ok on
all v7 implementations in the kernel I am aware of, I stand to be corrected
but to the best of my knowledge that's the case.

> > This is why I preferred to treat the whole sequence as specific to a
> > particular CPU implementation.  The similarity between A7 and A15
> > might be viewed as a happy coincidence (it also makes life easier in
> > big.LITTLE land).
> 
> Fair enough.

I disagree on the happy coincidence but the point is taken. I am not
sure about what we should do, but I reiterate my point, the sequence as
it stands is OK on all NS v7 implementations I am aware of. We can add
macros to differentiate processors when we need them, but again that's
just my opinion, as correct as it can be.

Lorenzo



From gregkh at linuxfoundation.org  Tue Jul 23 12:35:51 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 23 Jul 2013 09:35:51 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51EEAF32.4040905@ti.com>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <51EE9EC0.6060905@ti.com> <20130723161846.GD2486@kroah.com>
 <51EEAF32.4040905@ti.com>
Message-ID: <20130723163551.GA12990@kroah.com>

On Tue, Jul 23, 2013 at 09:58:34PM +0530, Kishon Vijay Abraham I wrote:
> Hi Greg,
> 
> On Tuesday 23 July 2013 09:48 PM, Greg KH wrote:
> > On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
> >> Hi,
> >>
> >> On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
> >>> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> >>>
> >>>> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> >>>>> Hi Alan,
> >>>
> >>> Thanks for helping to clarify the issues here.
> >>>
> >>>>>> Okay.  Are PHYs _always_ platform devices?
> >>>>>
> >>>>> They can be i2c, spi or any other device types as well.
> >>>
> >>> In those other cases, presumably there is no platform data associated
> >>> with the PHY since it isn't a platform device.  Then how does the
> >>> kernel know which controller is attached to the PHY?  Is this spelled
> >>> out in platform data associated with the PHY's i2c/spi/whatever parent?
> .
> .
> <snip>
> .
> .
> >>
> >> 	static struct phy *phy_lookup(void *priv) {
> >> 		.
> >> 		.
> >> 		if (phy->priv==priv) //instead of string comparison, we'll use pointer
> >> 			return phy;
> >> 	}
> >>
> >> PHY driver should be like
> >> 	phy_create((dev, ops, pdata->info);
> >>
> >> The controller driver would do
> >> 	phy_get(dev, NULL, pdata->info);
> >>
> >> Now the PHY framework will check for a match of *priv* pointer and return the PHY.
> >>
> >> I think this should be possible?
> > 
> > Ick, no.  Why can't you just pass the pointer to the phy itself?  If you
> > had a "priv" pointer to search from, then you could have just passed the
> > original phy pointer in the first place, right?
> > 
> > The issue is that a string "name" is not going to scale at all, as it
> > requires hard-coded information that will change over time (as the
> > existing clock interface is already showing.)
> > 
> > Please just pass the real "phy" pointer around, that's what it is there
> > for.  Your "board binding" logic/code should be able to handle this, as
> > it somehow was going to do the same thing with a "name".
> 
> The problem is the board file won't have the *phy* pointer. *phy* pointer is
> created at a much later time when the phy driver is probed.

Ok, then save it then, as no one could have used it before then, right?

All I don't want to see is any "get by name/void *" functions in the
api, as that way is fragile and will break, as people have already
shown.

Just pass the real pointer around.  If that is somehow a problem, then
something larger is a problem with how board devices are tied together :)

thanks,

greg k-h


From jonathan.austin at arm.com  Tue Jul 23 12:41:51 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Tue, 23 Jul 2013 17:41:51 +0100
Subject: [PATCH resend] ARM: nommu: remove ARCH_MULTIPLATFORM's dependency on
 CONFIG_MMU
Message-ID: <1374597712-18112-1-git-send-email-jonathan.austin@arm.com>

From: Arnd Bergmann <arnd at arndb.de>

ARCH_MULTIPLATFORM currently requires CONFIG_MMU to be set, however it is
intended that all future V6/V7 platforms are compatible with
ARCH_MULTIPLATFORM, and so this requirement precludes that addition of new
!MMU platforms.

Furthermore, this requirement creates unnecessary differences between the MMU
and !MMU worlds, which is undesirable.

This patch allows ARCH_MULTIPLATFORM to remain selected in a !MMU
configuration. There is still a need to hardcode CONFIG_DRAM_BASE and other
parameters relating to the system, so this patch is less about making an
actual multiplatform kernel for !MMU and more about consistency across the
kernel.

Along with the nommu-fixes, R7 support and MPU support already sent to this
list, this patch is sufficient to allow building and booting of kernel for a
Cortex-R7 core on a Versatile Express platform.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Jonathan Austin <jonathan.austin at arm.com>
---

This patch was written by Arnd and after some discussion/testing at my end he
asked me to send it to the list with a full description.

I'm resending this after testing it still allows R7 to boot on 3.11.

Assuming no comments, I'll drop this in the patch system shortly. Any calls for
Cc-ing stable?

Jonny

 arch/arm/Kconfig |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 49d993c..5a61686 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -289,8 +289,7 @@ choice
 
 config ARCH_MULTIPLATFORM
 	bool "Allow multiple platforms to be selected"
-	depends on MMU
-	select ARM_PATCH_PHYS_VIRT
+	select ARM_PATCH_PHYS_VIRT if MMU
 	select AUTO_ZRELADDR
 	select COMMON_CLK
 	select MULTI_IRQ_HANDLER
-- 
1.7.9.5




From joelf at ti.com  Tue Jul 23 12:43:24 2013
From: joelf at ti.com (Joel Fernandes)
Date: Tue, 23 Jul 2013 11:43:24 -0500
Subject: [PATCH] dma: edma: add device_slave_caps() support
Message-ID: <1374597804-3961-1-git-send-email-joelf@ti.com>

Implement device_slave_caps(). EDMA has a limited number of slots.
Slave drivers such as omap_hsmmc will query the driver to make
sure they don't pass in more than these many scatter segments.

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
Vinod, or Dan- If this patch looks ok, can you please merge in for
-rc cycle? This patch is required to fix MMC support on AM33xx. This
patch is blocking 3 other patches which fix various MMC things. Thanks!

Notes:
(1) this approach is temporary and only for -rc cycle to fix MMC on
AM335x. It will be replace by the RFC series in future kernels:
http://www.spinics.net/lists/arm-kernel/msg260094.html

(2) Patch depends Vinod's patch at:
http://permalink.gmane.org/gmane.linux.kernel/1525112

 drivers/dma/edma.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7222cbe..81d5429 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -517,6 +517,14 @@ static void edma_issue_pending(struct dma_chan *chan)
 	spin_unlock_irqrestore(&echan->vchan.lock, flags);
 }
 
+static inline int edma_slave_caps(struct dma_chan *chan,
+	struct dma_slave_caps *caps)
+{
+	caps->max_sg_nr = MAX_NR_SG;
+
+	return 0;
+}
+
 static size_t edma_desc_size(struct edma_desc *edesc)
 {
 	int i;
@@ -594,6 +602,7 @@ static void edma_dma_init(struct edma_cc *ecc, struct dma_device *dma,
 	dma->device_issue_pending = edma_issue_pending;
 	dma->device_tx_status = edma_tx_status;
 	dma->device_control = edma_control;
+	dma->device_slave_caps = edma_slave_caps;
 	dma->dev = dev;
 
 	INIT_LIST_HEAD(&dma->channels);
-- 
1.7.9.5



From stefano.stabellini at eu.citrix.com  Tue Jul 23 12:46:58 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 23 Jul 2013 17:46:58 +0100
Subject: [PATCH] do not allow XEN_TMEM on ARM64
Message-ID: <alpine.DEB.2.02.1307231745520.4893@kaball.uk.xensource.com>

tmem is not supported on arm or arm64 yet.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 9e02d60..a18f350 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -145,7 +146,7 @@ config SWIOTLB_XEN
 
 config XEN_TMEM
 	tristate
-	depends on !ARM
+	depends on !ARM && !ARM64
 	default m if (CLEANCACHE || FRONTSWAP)
 	help
 	  Shim to interface in-kernel Transcendent Memory hooks


From t.figa at samsung.com  Tue Jul 23 12:50:29 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 18:50:29 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130723161846.GD2486@kroah.com>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <51EE9EC0.6060905@ti.com> <20130723161846.GD2486@kroah.com>
Message-ID: <1446965.6APW5ZgLBW@amdc1227>

On Tuesday 23 of July 2013 09:18:46 Greg KH wrote:
> On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
> > Hi,
> > 
> > On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
> > > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > >> On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
> > >>> Hi Alan,
> > > 
> > > Thanks for helping to clarify the issues here.
> > > 
> > >>>> Okay.  Are PHYs _always_ platform devices?
> > >>> 
> > >>> They can be i2c, spi or any other device types as well.
> > > 
> > > In those other cases, presumably there is no platform data associated
> > > with the PHY since it isn't a platform device.  Then how does the
> > > kernel know which controller is attached to the PHY?  Is this spelled
> > > out in platform data associated with the PHY's i2c/spi/whatever
> > > parent?
> > 
> > Yes. I think we could use i2c_board_info for passing platform data.
> > 
> > >>>>>> 	PHY.  Currently this information is represented by name or
> > >> 
> > >> ID
> > >> 
> > >>>>>> 	strings embedded in platform data.
> > >>>>> 
> > >>>>> right. It's embedded in the platform data of the controller.
> > >>>> 
> > >>>> It must also be embedded in the PHY's platform data somehow.
> > >>>> Otherwise, how would the kernel know which PHY to use?
> > >>> 
> > >>> By using a PHY lookup as Stephen and I suggested in our previous
> > >>> replies. Without any extra data in platform data. (I have even
> > >>> posted a
> > >>> code example.)
> > > 
> > > I don't understand, because I don't know what "a PHY lookup" does.
> > 
> > It is how the PHY framework finds a PHY, when the controller (say
> > USB)requests a PHY from the PHY framework.
> > 
> > >>>> In this case, it doesn't matter where the platform_device
> > >>>> structures
> > >>>> are created or where the driver source code is.  Let's take a
> > >>>> simple
> > >>>> example.  Suppose the system design includes a PHY named "foo". 
> > >>>> Then
> > >>>> the board file could contain:
> > >>>> 
> > >>>> struct phy_info { ... } phy_foo;
> > >>>> EXPORT_SYMBOL_GPL(phy_foo);
> > >>>> 
> > >>>> and a header file would contain:
> > >>>> 
> > >>>> extern struct phy_info phy_foo;
> > >>>> 
> > >>>> The PHY supplier could then call phy_create(&phy_foo), and the PHY
> > >>>> client could call phy_find(&phy_foo).  Or something like that;
> > >>>> make up
> > >>>> your own structure tags and function names.
> > >>>> 
> > >>>> It's still possible to have conflicts, but now two PHYs with the
> > >>>> same
> > >>>> name (or a misspelled name somewhere) will cause an error at link
> > >>>> time.
> > >>> 
> > >>> This is incorrect, sorry. First of all it's a layering violation -
> > >>> you
> > >>> export random driver-specific symbols from one driver to another.
> > >>> Then
> > > 
> > > No, that's not what I said.  Neither the PHY driver nor the
> > > controller
> > > driver exports anything to the other.  Instead, both drivers use data
> > > exported by the board file.
> > 
> > I think instead we can use the same data while creating the platform
> > data of the controller and the PHY.
> > The PHY driver while creating the PHY (using PHY framework) will also
> > pass the *data* it actually got from the platform data to the
> > framework. The PHY user driver (USB), while requesting for the PHY
> > (from the PHY framework) will pass the *data* it got from its platform
> > data.
> > The PHY framework can do a comparison of the *data* pointers it has and
> > return the appropriate PHY to the controller.
> > 
> > >>> imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2
> > >>> and
> > >>> there are two types of consumer drivers (e.g. USB host
> > >>> controllers). Now
> > >>> consider following mapping:
> > >>> 
> > >>> SoC	PHY	consumer
> > >>> A	PHY1	HOST1
> > >>> B	PHY1	HOST2
> > >>> C	PHY2	HOST1
> > >>> D	PHY2	HOST2
> > >>> 
> > >>> So we have to be able to use any of the PHYs with any of the host
> > >>> drivers. This means you would have to export symbol with the same
> > >>> name
> > >>> from both PHY drivers, which obviously would not work in this case,
> > >>> because having both drivers enabled (in a multiplatform aware
> > >>> configuration) would lead to linking conflict.
> > > 
> > > You're right; the scheme was too simple.  Instead, the board file
> > > must
> > > export two types of data structures, one for PHYs and one for
> > > controllers.  Like this:
> > > 
> > > struct phy_info {
> > > 
> > > 	/* Info for the controller attached to this PHY */
> > > 	struct controller_info	*hinfo;
> > > 
> > > };
> > > 
> > > struct controller_info {
> > > 
> > > 	/* Info for the PHY which this controller is attached to */
> > > 	struct phy_info		*pinfo;
> > > 
> > > };
> > > 
> > > The board file for SoC A would contain:
> > > 
> > > struct phy_info phy1 = {&host1);
> > > EXPORT_SYMBOL(phy1);
> > > struct controller_info host1 = {&phy1};
> > > EXPORT_SYMBOL(host1);
> > > 
> > > The board file for SoC B would contain:
> > > 
> > > struct phy_info phy1 = {&host2);
> > > EXPORT_SYMBOL(phy1);
> > > struct controller_info host2 = {&phy1};
> > > EXPORT_SYMBOL(host2);
> > 
> > I meant something like this
> > struct phy_info {
> > 
> > 	const char *name;
> > 
> > };
> > 
> > struct phy_platform_data {
> > 
> > 	.
> > 	.
> > 	struct phy_info *info;
> > 
> > };
> > 
> > struct usb_controller_platform_data {
> > 
> > 	.
> > 	.
> > 	struct phy_info *info;
> > 
> > };
> > 
> > struct phy_info phy_info;
> > 
> > While creating the phy device
> > 
> > 	struct phy_platform_data phy_data;
> > 	phy_data.info = &info;
> > 	platform_device_add_data(pdev, &phy_data, sizeof(*phy_data))
> > 	platform_device_add();
> > 
> > While creating the controller device
> > 
> > 	struct usb_controller_platform_data controller_data;
> > 	controller_data.info = &info;
> > 	platform_device_add_data(pdev, &controller_data,
> > 	sizeof(*controller_data)) platform_device_add();
> > 
> > Then modify PHY framework API phy create
> > 
> > 	phy_create((struct device *dev, const struct phy_ops *ops,
> > 	
> >         void *priv)  {//API changed to take void pointer instead of
> >         label
> > 		
> > 		. //existing implementation
> > 		.
> > 		phy->priv = priv;
> > 	
> > 	}
> > 	
> > 	struct phy *phy_get(struct device *dev, const char *string, void
> > 	*priv) {> 
> > //API changed to take an additional pointer
> > 
> > 		phy_lookup(priv)
> > 	
> > 	}
> > 	
> > 	static struct phy *phy_lookup(void *priv) {
> > 	
> > 		.
> > 		.
> > 		if (phy->priv==priv) //instead of string comparison, we'll use
> > 		pointer
> > 		
> > 			return phy;
> > 	
> > 	}
> > 
> > PHY driver should be like
> > 
> > 	phy_create((dev, ops, pdata->info);
> > 
> > The controller driver would do
> > 
> > 	phy_get(dev, NULL, pdata->info);
> > 
> > Now the PHY framework will check for a match of *priv* pointer and
> > return the PHY.
> > 
> > I think this should be possible?
> 
> Ick, no.  Why can't you just pass the pointer to the phy itself?  If you
> had a "priv" pointer to search from, then you could have just passed the
> original phy pointer in the first place, right?

IMHO it would be better if you provided some code example, but let's try to 
check if I understood you correctly.

8><------------------------------------------------------------------------

[Board file]

static struct phy my_phy;

static struct platform_device phy_pdev = {
	/* ... */
	.platform_data = &my_phy;
	/* ... */
};

static struct platform_device phy_pdev = {
	/* ... */
	.platform_data = &my_phy;
	/* ... */
};

[Provider driver]

struct phy *phy = pdev->dev.platform_data;

ret = phy_create(phy);

[Consumer driver]

struct phy *phy = pdev->dev.platform_data;

ret = phy_get(&pdev->dev, phy);

------------------------------------------------------------------------><8

Is this what you mean?

> The issue is that a string "name" is not going to scale at all, as it
> requires hard-coded information that will change over time (as the
> existing clock interface is already showing.)

I fully agree that a simple, single string will not scale even in some, not 
so uncommon cases, but there is already a lot of existing lookup solutions 
over the kernel and so there is no point in introducing another one.

> Please just pass the real "phy" pointer around, that's what it is there
> for.  Your "board binding" logic/code should be able to handle this, as
> it somehow was going to do the same thing with a "name".

It's technically correct, but quality of this solution isn't really nice, 
because it's a layering violation (at least if I understood what you mean). 
This is because you need to have full definition of struct phy in board file 
and a structure that is used as private data in PHY core comes from 
platform code.

Best regards,
Tomasz



From sboyd at codeaurora.org  Tue Jul 23 13:01:53 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 23 Jul 2013 10:01:53 -0700
Subject: [PATCH] irqchip: gic: Don't complain in gic_get_cpumask() if
 UP system
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EEB180B@DBDE04.ent.ti.com>
References: <1373067573-29946-1-git-send-email-sboyd@codeaurora.org>
 <B5906170F1614E41A8A28DE3B8D121433EEB180B@DBDE04.ent.ti.com>
Message-ID: <20130723170153.GA27761@codeaurora.org>

On 07/20, Bedia, Vaibhav wrote:
> Hi,
> 
> On Sat, Jul 06, 2013 at 05:09:33, Stephen Boyd wrote:
> > In a uniprocessor implementation the interrupt processor targets
> > registers are read-as-zero/write-ignored (RAZ/WI). Unfortunately
> > gic_get_cpumask() will print a critical message saying
> > 
> >  GIC CPU mask not found - kernel will fail to boot.
> > 
> > if these registers all read as zero, but there won't actually be
> > a problem on uniprocessor systems and the kernel will boot just
> > fine. Skip this check if we're running a UP kernel or if we
> > detect that the hardware only supports a single processor.
> > 
> > Cc: Nicolas Pitre <nico at linaro.org>
> > Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> > Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> > ---
> > 
> > Maybe we should just drop the check entirely? It looks like it may
> > just be debug code that won't ever trigger in practice, even on the
> > 11MPCore that caused this code to be introduced.
> > 
> 
> Apologies if I missed v2 of this patch if there was one. I could not
> locate it in my inbox or the list archives.
> 
> We have a yet to be released single-core A9 MPCore system (AM437x) which
> needs to co-exist in omap2plus_defconfig wherein NR_CPUS is set to 2. 
> This currently leads to the "GIC CPU mask not found..." being printed
> twice during bootup. If the check is really some debug code, can it be
> completely dropped?

I have sent both versions of the patch in hopes that one or the
other will be accepted. Either way works for me.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From fabio.estevam at freescale.com  Tue Jul 23 13:02:06 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Tue, 23 Jul 2013 14:02:06 -0300
Subject: [PATCH] ARM: multi_v7_defconfig: Select USB chipidea driver
Message-ID: <1374598926-23761-1-git-send-email-fabio.estevam@freescale.com>

CONFIG_USB_EHCI_MXC selects the old i.mx USB driver, which does not support 
device tree.

Select the USB chipidea driver instead, so that USB can be functional on i.mx.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/configs/multi_v7_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index fe0bdc3..ade8328 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -111,11 +111,12 @@ CONFIG_FB_SIMPLE=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_EHCI_MXC=y
 CONFIG_USB_EHCI_TEGRA=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
 CONFIG_USB_ISP1760_HCD=y
 CONFIG_USB_STORAGE=y
+CONFIG_USB_CHIPIDEA=y
+CONFIG_USB_CHIPIDEA_HOST=y
 CONFIG_AB8500_USB=y
 CONFIG_NOP_USB_XCEIV=y
 CONFIG_OMAP_USB2=y
-- 
1.8.1.2




From olof at lixom.net  Tue Jul 23 13:10:31 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 23 Jul 2013 10:10:31 -0700
Subject: [PATCH v8 00/28] MBus DT binding for Armada 370/XP and Kirkwood
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <CAOesGMh5GjCkaGX1O1VdkQUKdM8z0XPEc08OFPjJcGgP6s9nRw@mail.gmail.com>

On Tue, Jul 23, 2013 at 6:31 AM, Ezequiel Garcia
<ezequiel.garcia at free-electrons.com> wrote:
> After Andrew Lunn reported [1] this work need to take account of Kirkwood
> to prevent breaking PCIe on such platform, here's a new version adding
> MBus DT binding for Kirkwood and in particular using it to declare PCIe
> properly.

Ezequiel,

This is a prime example of someone sending a whole patch series to the
devicetree mailing list, when only the bindings updates should go
there. There are a lot of readers of the devicetree lists that can't
keep up with the volume of email due to this reason.

So, while I'm commenting on your email, this goes for everybody
mailing to this list (and I expect to repeat myself a few times in the
weeks and months ahead): Do not post the driver updates to the
devicetree list, only the bindings updates.


-Olof


From tobetter at gmail.com  Tue Jul 23 13:31:17 2013
From: tobetter at gmail.com (Dongjin Kim)
Date: Wed, 24 Jul 2013 02:31:17 +0900
Subject: [PATCH] ARM: dts: Add USBPHY nodes to Exynos4x12
Message-ID: <1374600682-19376-1-git-send-email-tobetter@gmail.com>

This patch adds device nodes for USBPHY to Exynos4x12.

Signed-off-by: Dongjin Kim <tobetter at gmail.com>
---
 arch/arm/boot/dts/exynos4x12.dtsi |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index 01da194..9c3335b 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -73,4 +73,22 @@
 		clock-names = "sclk_fimg2d", "fimg2d";
 		status = "disabled";
 	};
+
+	usbphy at 125B00000 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "samsung,exynos4x12-usb2phy";
+		reg = <0x125B0000 0x100>;
+		ranges;
+
+		clocks = <&clock 2>, <&clock 305>;
+		clock-names = "xusbxti", "otg";
+		status = "disabled";
+
+		usbphy-sys {
+			/* USB device and host PHY_CONTROL registers */
+			reg = <0x10020704 0xc>,
+			      <0x1001021c 0x4>;
+		};
+	};
 };
-- 
1.7.9.5



From tobetter at gmail.com  Tue Jul 23 13:32:40 2013
From: tobetter at gmail.com (Dongjin Kim)
Date: Wed, 24 Jul 2013 02:32:40 +0900
Subject: [PATCH] ARM: dts: Add USB host node for Exynos4
Message-ID: <1374600763-19466-1-git-send-email-tobetter@gmail.com>

This patch adds EHCI and OHCI host device nodes for Exynos4.

Signed-off-by: Dongjin Kim <tobetter at gmail.com>
---
 arch/arm/boot/dts/exynos4.dtsi |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 3f94fe8..1cdbf89 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -155,6 +155,26 @@
 		status = "disabled";
 	};
 
+	ehci at 12580000 {
+		compatible = "samsung,exynos4210-ehci";
+		reg = <0x12580000 0x100>;
+		interrupts = <0 70 0>;
+		status = "disabled";
+
+		clocks = <&clock 304>;
+		clock-names = "usbhost";
+	};
+
+	ohci at 12590000 {
+		compatible = "samsung,exynos4210-ohci";
+		reg = <0x12580000 0x100>;
+		interrupts = <0 70 0>;
+		status = "disabled";
+
+		clocks = <&clock 304>;
+		clock-names = "usbhost";
+	};
+
 	mfc: codec at 13400000 {
 		compatible = "samsung,mfc-v5";
 		reg = <0x13400000 0x10000>;
-- 
1.7.9.5



From ezequiel.garcia at free-electrons.com  Tue Jul 23 13:35:00 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 23 Jul 2013 14:35:00 -0300
Subject: [PATCH v8 00/28] MBus DT binding for Armada 370/XP and Kirkwood
In-Reply-To: <CAOesGMh5GjCkaGX1O1VdkQUKdM8z0XPEc08OFPjJcGgP6s9nRw@mail.gmail.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <CAOesGMh5GjCkaGX1O1VdkQUKdM8z0XPEc08OFPjJcGgP6s9nRw@mail.gmail.com>
Message-ID: <20130723173459.GA11373@localhost>

Olof,

On Tue, Jul 23, 2013 at 10:10:31AM -0700, Olof Johansson wrote:
> On Tue, Jul 23, 2013 at 6:31 AM, Ezequiel Garcia
> <ezequiel.garcia at free-electrons.com> wrote:
> > After Andrew Lunn reported [1] this work need to take account of Kirkwood
> > to prevent breaking PCIe on such platform, here's a new version adding
> > MBus DT binding for Kirkwood and in particular using it to declare PCIe
> > properly.
> 
> This is a prime example of someone sending a whole patch series to the
> devicetree mailing list, when only the bindings updates should go
> there. There are a lot of readers of the devicetree lists that can't
> keep up with the volume of email due to this reason.
> 
> So, while I'm commenting on your email, this goes for everybody
> mailing to this list (and I expect to repeat myself a few times in the
> weeks and months ahead): Do not post the driver updates to the
> devicetree list, only the bindings updates.
> 

Okey, got it. Won't happen again.

Thanks for the notice,
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From broonie at kernel.org  Tue Jul 23 13:34:54 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 23 Jul 2013 18:34:54 +0100
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
References: <3419798.aorxYv8pdo@flatron>
 <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
Message-ID: <20130723173454.GK9858@sirena.org.uk>

On Tue, Jul 23, 2013 at 10:37:05AM -0400, Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:

> > > > Okay.  Are PHYs _always_ platform devices?

> > > They can be i2c, spi or any other device types as well.

> In those other cases, presumably there is no platform data associated
> with the PHY since it isn't a platform device.  Then how does the
> kernel know which controller is attached to the PHY?  Is this spelled
> out in platform data associated with the PHY's i2c/spi/whatever parent?

Platform data is nothing to do with the platform bus - it's board
specific data (ie, data for the platform) and can be done with any
device.
-------------- 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/20130723/9aafc3b9/attachment-0001.sig>

From gregkh at linuxfoundation.org  Tue Jul 23 13:37:11 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 23 Jul 2013 10:37:11 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <1446965.6APW5ZgLBW@amdc1227>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <51EE9EC0.6060905@ti.com> <20130723161846.GD2486@kroah.com>
 <1446965.6APW5ZgLBW@amdc1227>
Message-ID: <20130723173710.GB28284@kroah.com>

On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > Ick, no.  Why can't you just pass the pointer to the phy itself?  If you
> > had a "priv" pointer to search from, then you could have just passed the
> > original phy pointer in the first place, right?
> 
> IMHO it would be better if you provided some code example, but let's try to 
> check if I understood you correctly.

It's not my code that I want to have added, so I don't have to write
examples, I just get to complain about the existing stuff :)

> 8><------------------------------------------------------------------------
> 
> [Board file]
> 
> static struct phy my_phy;
> 
> static struct platform_device phy_pdev = {
> 	/* ... */
> 	.platform_data = &my_phy;
> 	/* ... */
> };
> 
> static struct platform_device phy_pdev = {
> 	/* ... */
> 	.platform_data = &my_phy;
> 	/* ... */
> };
> 
> [Provider driver]
> 
> struct phy *phy = pdev->dev.platform_data;
> 
> ret = phy_create(phy);
> 
> [Consumer driver]
> 
> struct phy *phy = pdev->dev.platform_data;
> 
> ret = phy_get(&pdev->dev, phy);
> 
> ------------------------------------------------------------------------><8
> 
> Is this what you mean?

No.  Well, kind of.  What's wrong with using the platform data structure
unique to the board to have the pointer?

For example (just randomly picking one), the ata-pxa driver would change
include/linux/platform_data/ata-pxa.h to have a phy pointer in it:

struct phy;

struct  pata_pxa_pdata {
	/* PXA DMA DREQ<0:2> pin */
	uint32_t	dma_dreq;
	/* Register shift */
	uint32_t	reg_shift;
	/* IRQ flags */
	uint32_t	irq_flags;
	/* PHY */
	struct phy	*phy;
};

Then, when you create the platform, set the phy* pointer with a call to
phy_create().  Then you can use that pointer wherever that plaform data
is available (i.e. whereever platform_data is at).

> > The issue is that a string "name" is not going to scale at all, as it
> > requires hard-coded information that will change over time (as the
> > existing clock interface is already showing.)
> 
> I fully agree that a simple, single string will not scale even in some, not 
> so uncommon cases, but there is already a lot of existing lookup solutions 
> over the kernel and so there is no point in introducing another one.

I'm trying to get _rid_ of lookup "solutions" and just use a real
pointer, as you should.  I'll go tackle those other ones after this one
is taken care of, to show how the others should be handled as well.

> > Please just pass the real "phy" pointer around, that's what it is there
> > for.  Your "board binding" logic/code should be able to handle this, as
> > it somehow was going to do the same thing with a "name".
> 
> It's technically correct, but quality of this solution isn't really nice, 
> because it's a layering violation (at least if I understood what you mean). 
> This is because you need to have full definition of struct phy in board file 
> and a structure that is used as private data in PHY core comes from 
> platform code.

No, just a pointer, you don't need the "full" structure until you get to
some .c code that actually manipulates the phy itself, for all other
places, you are just dealing with a pointer and a structure you never
reference.

Does that make more sense?

thanks,

greg k-h


From ben.dooks at codethink.co.uk  Tue Jul 23 13:40:18 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Tue, 23 Jul 2013 18:40:18 +0100
Subject: updates for be8 patch series
In-Reply-To: <CAA3XUr3h5C0oJVrN5iXsM=NFkLMz_Tssp28CysZfwMNS5KvO-Q@mail.gmail.com>
References: <CAA3XUr3h5C0oJVrN5iXsM=NFkLMz_Tssp28CysZfwMNS5KvO-Q@mail.gmail.com>
Message-ID: <51EEC002.9070808@codethink.co.uk>

On 23/07/13 18:24, Victor Kamensky wrote:
> Hi Ben,
>
> Wrt BE8 little endian instructions you will need to fix couple more places:
>      ftrace arch/arm/kernel/ftrace.c
>      kprobes arch/arm/kernel/kprobes.c
> Also in big endian mode atomic64_xxx function will need fixes, otherwise
> perf
> counters will be truncated on max of 32bit values
>      atomic64 arch/arm/include/asm/atomic.h

Hmm, thought ftrace already did the right endian-ness conversions,
although it is possible it could have missed one.

The atomic instructions should work fine for BE8, they're using
STRD which should be correct.

> I've attached board independent (core) patch from my work that made
> Pandaboard ES
> kernel run in BE mode. You can check my version of fixes for above
> issues in the
> patch. Look for corresponding files changes. Please rework them
> according to style
> and rules of your patch series. Note the patch itself contains fixes for
> few other
> issues that already fixed in your series. I'll cross check and compare
> individual
> areas latter. I think you may find attached patch interesting as well,
> it was developed
> independent from yours but matches its very well.

>

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From broonie at kernel.org  Tue Jul 23 13:44:56 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 23 Jul 2013 18:44:56 +0100
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130723173710.GB28284@kroah.com>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <51EE9EC0.6060905@ti.com> <20130723161846.GD2486@kroah.com>
 <1446965.6APW5ZgLBW@amdc1227> <20130723173710.GB28284@kroah.com>
Message-ID: <20130723174456.GM9858@sirena.org.uk>

On Tue, Jul 23, 2013 at 10:37:11AM -0700, Greg KH wrote:
> On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:

> > I fully agree that a simple, single string will not scale even in some, not 
> > so uncommon cases, but there is already a lot of existing lookup solutions 
> > over the kernel and so there is no point in introducing another one.

> I'm trying to get _rid_ of lookup "solutions" and just use a real
> pointer, as you should.  I'll go tackle those other ones after this one
> is taken care of, to show how the others should be handled as well.

What are the problems you are seeing with doing things with lookups?
Having to write platform data for everything gets old fast and the code
duplication is pretty tedious...
-------------- 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/20130723/5a9806af/attachment.sig>

From t.figa at samsung.com  Tue Jul 23 13:48:11 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 19:48:11 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130723173710.GB28284@kroah.com>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <1446965.6APW5ZgLBW@amdc1227> <20130723173710.GB28284@kroah.com>
Message-ID: <19656720.FrnhefyPXl@amdc1227>

On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
> On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > > Ick, no.  Why can't you just pass the pointer to the phy itself?  If
> > > you
> > > had a "priv" pointer to search from, then you could have just passed
> > > the
> > > original phy pointer in the first place, right?
> > 
> > IMHO it would be better if you provided some code example, but let's
> > try to check if I understood you correctly.
> 
> It's not my code that I want to have added, so I don't have to write
> examples, I just get to complain about the existing stuff :)

Still, I think that some small code snippets illustrating the idea are 
really helpful.

> > 8><--------------------------------------------------------------------
> > ----
> > 
> > [Board file]
> > 
> > static struct phy my_phy;
> > 
> > static struct platform_device phy_pdev = {
> > 
> > 	/* ... */
> > 	.platform_data = &my_phy;
> > 	/* ... */
> > 
> > };
> > 
> > static struct platform_device phy_pdev = {
> > 
> > 	/* ... */
> > 	.platform_data = &my_phy;
> > 	/* ... */
> > 
> > };
> > 
> > [Provider driver]
> > 
> > struct phy *phy = pdev->dev.platform_data;
> > 
> > ret = phy_create(phy);
> > 
> > [Consumer driver]
> > 
> > struct phy *phy = pdev->dev.platform_data;
> > 
> > ret = phy_get(&pdev->dev, phy);
> > 
> > -----------------------------------------------------------------------
> > -><8
> > 
> > Is this what you mean?
> 
> No.  Well, kind of.  What's wrong with using the platform data structure
> unique to the board to have the pointer?
> 
> For example (just randomly picking one), the ata-pxa driver would change
> include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
> 
> struct phy;
> 
> struct  pata_pxa_pdata {
> 	/* PXA DMA DREQ<0:2> pin */
> 	uint32_t	dma_dreq;
> 	/* Register shift */
> 	uint32_t	reg_shift;
> 	/* IRQ flags */
> 	uint32_t	irq_flags;
> 	/* PHY */
> 	struct phy	*phy;
> };
> 
> Then, when you create the platform, set the phy* pointer with a call to
> phy_create().  Then you can use that pointer wherever that plaform data
> is available (i.e. whereever platform_data is at).

Hmm? So, do you suggest to call phy_create() from board file? What phy_ops 
struct and other hardware parameters would it take?

> > > The issue is that a string "name" is not going to scale at all, as it
> > > requires hard-coded information that will change over time (as the
> > > existing clock interface is already showing.)
> > 
> > I fully agree that a simple, single string will not scale even in some,
> > not so uncommon cases, but there is already a lot of existing lookup
> > solutions over the kernel and so there is no point in introducing
> > another one.
> I'm trying to get _rid_ of lookup "solutions" and just use a real
> pointer, as you should.  I'll go tackle those other ones after this one
> is taken care of, to show how the others should be handled as well.

There was a reason for introducing lookup solutions. The reason was that in 
board file there is no way to get a pointer to something that is going to be 
created much later in time. We don't do time travel ;-).

> > > Please just pass the real "phy" pointer around, that's what it is
> > > there
> > > for.  Your "board binding" logic/code should be able to handle this,
> > > as
> > > it somehow was going to do the same thing with a "name".
> > 
> > It's technically correct, but quality of this solution isn't really
> > nice, because it's a layering violation (at least if I understood what
> > you mean). This is because you need to have full definition of struct
> > phy in board file and a structure that is used as private data in PHY
> > core comes from platform code.
> 
> No, just a pointer, you don't need the "full" structure until you get to
> some .c code that actually manipulates the phy itself, for all other
> places, you are just dealing with a pointer and a structure you never
> reference.
> 
> Does that make more sense?

Well, to the point that I think I now understood your suggestion. 
Unfortunately the suggestion alone isn't really something that can be done, 
considering how driver core and generic frameworks work.

Best regards,
Tomasz



From fkan at apm.com  Tue Jul 23 13:52:31 2013
From: fkan at apm.com (Feng Kan)
Date: Tue, 23 Jul 2013 10:52:31 -0700
Subject: [PATCH] arm64: Change kernel stack size to 16K.
Message-ID: <1374601951-4091-1-git-send-email-fkan@apm.com>

Written by Catalin Marinas, tested by APM on storm platform. This is needed 
because of the failures encountered when running SpecWeb benchmark test.

Signed-off-by: Feng Kan <fkan at apm.com>
Acked-by: Kumar Sankaran <ksankaran at apm.com>
---
 arch/arm64/include/asm/thread_info.h |    4 ++--
 arch/arm64/kernel/entry.S            |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
index 3659e46..23a3c47 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -24,10 +24,10 @@
 #include <linux/compiler.h>
 
 #ifndef CONFIG_ARM64_64K_PAGES
-#define THREAD_SIZE_ORDER	1
+#define THREAD_SIZE_ORDER	2
 #endif
 
-#define THREAD_SIZE		8192
+#define THREAD_SIZE		16384
 #define THREAD_START_SP		(THREAD_SIZE - 16)
 
 #ifndef __ASSEMBLY__
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 1d13142..6ad781b 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -121,7 +121,7 @@
 
 	.macro	get_thread_info, rd
 	mov	\rd, sp
-	and	\rd, \rd, #~((1 << 13) - 1)	// top of 8K stack
+	and	\rd, \rd, #~(THREAD_SIZE - 1)	// top of stack
 	.endm
 
 /*
-- 
1.7.6.1



From victor.kamensky at linaro.org  Tue Jul 23 13:53:04 2013
From: victor.kamensky at linaro.org (Victor Kamensky)
Date: Tue, 23 Jul 2013 10:53:04 -0700
Subject: updates for be8 patch series
In-Reply-To: <51EEC002.9070808@codethink.co.uk>
References: <CAA3XUr3h5C0oJVrN5iXsM=NFkLMz_Tssp28CysZfwMNS5KvO-Q@mail.gmail.com>
 <51EEC002.9070808@codethink.co.uk>
Message-ID: <CAA3XUr2oDEDD6LFjnZ_N0JGTFUMDZG6O9b3JoeJ8AELrK2KDiw@mail.gmail.com>

On 23 July 2013 10:40, Ben Dooks <ben.dooks at codethink.co.uk> wrote:
> On 23/07/13 18:24, Victor Kamensky wrote:
>>
>> Hi Ben,
>>
>> Wrt BE8 little endian instructions you will need to fix couple more
>> places:
>>      ftrace arch/arm/kernel/ftrace.c
>>      kprobes arch/arm/kernel/kprobes.c
>> Also in big endian mode atomic64_xxx function will need fixes, otherwise
>> perf
>> counters will be truncated on max of 32bit values
>>      atomic64 arch/arm/include/asm/atomic.h
>
>
> Hmm, thought ftrace already did the right endian-ness conversions,
> although it is possible it could have missed one.
>
> The atomic instructions should work fine for BE8, they're using
> STRD which should be correct.

atomic64_read and atomic64_set are fine, but atomic64_add,
atomic64_add_return, atomic64_sub, atomic64_sub_return, etc are not OK.
The issue is in arithmetic operations not load/store.

Thanks,
Victor

>
>> I've attached board independent (core) patch from my work that made
>> Pandaboard ES
>> kernel run in BE mode. You can check my version of fixes for above
>> issues in the
>> patch. Look for corresponding files changes. Please rework them
>> according to style
>> and rules of your patch series. Note the patch itself contains fixes for
>> few other
>> issues that already fixed in your series. I'll cross check and compare
>> individual
>> areas latter. I think you may find attached patch interesting as well,
>> it was developed
>> independent from yours but matches its very well.
>
>
>>
>
> --
> Ben Dooks                               http://www.codethink.co.uk/
> Senior Engineer                         Codethink - Providing Genius


From gregkh at linuxfoundation.org  Tue Jul 23 14:01:10 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 23 Jul 2013 11:01:10 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130723174456.GM9858@sirena.org.uk>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <51EE9EC0.6060905@ti.com> <20130723161846.GD2486@kroah.com>
 <1446965.6APW5ZgLBW@amdc1227> <20130723173710.GB28284@kroah.com>
 <20130723174456.GM9858@sirena.org.uk>
Message-ID: <20130723180110.GA8688@kroah.com>

On Tue, Jul 23, 2013 at 06:44:56PM +0100, Mark Brown wrote:
> On Tue, Jul 23, 2013 at 10:37:11AM -0700, Greg KH wrote:
> > On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> 
> > > I fully agree that a simple, single string will not scale even in some, not 
> > > so uncommon cases, but there is already a lot of existing lookup solutions 
> > > over the kernel and so there is no point in introducing another one.
> 
> > I'm trying to get _rid_ of lookup "solutions" and just use a real
> > pointer, as you should.  I'll go tackle those other ones after this one
> > is taken care of, to show how the others should be handled as well.
> 
> What are the problems you are seeing with doing things with lookups?

You don't "know" the id of the device you are looking up, due to
multiple devices being in the system (dynamic ids, look back earlier in
this thread for details about that.)

> Having to write platform data for everything gets old fast and the code
> duplication is pretty tedious...

Adding a single pointer is "tedious"?  Where is the "name" that you are
going to lookup going to come from?  That code doesn't write itself...

thanks,

greg k-h


From ben.dooks at codethink.co.uk  Tue Jul 23 14:02:36 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Tue, 23 Jul 2013 19:02:36 +0100
Subject: updates for be8 patch series
In-Reply-To: <CAA3XUr2oDEDD6LFjnZ_N0JGTFUMDZG6O9b3JoeJ8AELrK2KDiw@mail.gmail.com>
References: <CAA3XUr3h5C0oJVrN5iXsM=NFkLMz_Tssp28CysZfwMNS5KvO-Q@mail.gmail.com>
 <51EEC002.9070808@codethink.co.uk>
 <CAA3XUr2oDEDD6LFjnZ_N0JGTFUMDZG6O9b3JoeJ8AELrK2KDiw@mail.gmail.com>
Message-ID: <51EEC53C.4080505@codethink.co.uk>

On 23/07/13 18:53, Victor Kamensky wrote:
> On 23 July 2013 10:40, Ben Dooks<ben.dooks at codethink.co.uk>  wrote:
>> On 23/07/13 18:24, Victor Kamensky wrote:
>>>
>>> Hi Ben,
>>>
>>> Wrt BE8 little endian instructions you will need to fix couple more
>>> places:
>>>       ftrace arch/arm/kernel/ftrace.c
>>>       kprobes arch/arm/kernel/kprobes.c
>>> Also in big endian mode atomic64_xxx function will need fixes, otherwise
>>> perf
>>> counters will be truncated on max of 32bit values
>>>       atomic64 arch/arm/include/asm/atomic.h
>>
>>
>> Hmm, thought ftrace already did the right endian-ness conversions,
>> although it is possible it could have missed one.
>>
>> The atomic instructions should work fine for BE8, they're using
>> STRD which should be correct.
>
> atomic64_read and atomic64_set are fine, but atomic64_add,
> atomic64_add_return, atomic64_sub, atomic64_sub_return, etc are not OK.
> The issue is in arithmetic operations not load/store.

I'm still surprised these don't work. What exact situation are you
seeing the failures in? Code would be very helpful here.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From ben.dooks at codethink.co.uk  Tue Jul 23 14:02:34 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Tue, 23 Jul 2013 19:02:34 +0100
Subject: updates for be8 patch series
In-Reply-To: <CAA3XUr1o0cOCybSR=pCUT-WYP4xus5VrES6Hyzo-Wy4tcutTvQ@mail.gmail.com>
References: <CAA3XUr1o0cOCybSR=pCUT-WYP4xus5VrES6Hyzo-Wy4tcutTvQ@mail.gmail.com>
Message-ID: <51EEC53A.8070608@codethink.co.uk>

On 23/07/13 18:40, Victor Kamensky wrote:
> [resend in plain-text mode]
>
> Hi Ben,
>
> Wrt BE8 little endian instructions you will need to fix couple more places:
>      ftrace arch/arm/kernel/ftrace.c
>      kprobes arch/arm/kernel/kprobes.c
> Also in big endian mode atomic64_xxx function will need fixes, otherwise perf
> counters will be truncated on max of 32bit values
>      atomic64 arch/arm/include/asm/atomic.h
>
> I've attached board independent (core) patch from my work that made
> Pandaboard ES
> kernel run in BE mode. You can check my version of fixes for above issues in the
> patch. Look for corresponding files changes. Please rework them
> according to style
> and rules of your patch series. Note the patch itself contains fixes
> for few other
> issues that already fixed in your series. I'll cross check and compare
> individual
> areas latter. I think you may find attached patch interesting as well,
> it was developed
> independent from yours but matches it very well.
>
> Wrt of testing: ftrace was tested on Pandaboard ES, krprobes changes were tested
> with SystemTap at some point of patch version on Pandaboard ES (not
> thumb mode though),
> also it may deteriorated while ported across different kernel version,
> good idea to
> rested last patch. atomic64 were tested on Pandaboard ES and Marvell Armada XP.

Please wrap your emails to <80 characters, it was really difficult
to read this.

The atomic64 ops is an interesting one, I still think the in-kernel
one is correct. Why are atomic64 being used on 32bit? If you are
trying to decompose a 64bit into two 32bits, then that's probably
the problem.

The relocation code, the R_ARM instruction relocations should only
be instructions and therefore can be safely swapped using the correct
op-code accesses. The R_ARM_ABS32 IIRC is always in the same ordering
as the CPU would access data.

The kprobes stuff I am surprised if it works, due to the fact it calls
patch_text() which already uses <asm/opcodes.h> to do the relevant
byte-swapping. I think you only need to apply swaps to anything
that it loads from memory.

Which version of Linux did you patch?

I think this is the necessary change to kprobes:

diff --git a/arch/arm/kernel/kprobes.c b/arch/arm/kernel/kprobes.c
index 170e9f3..c548356 100644
--- a/arch/arm/kernel/kprobes.c
+++ b/arch/arm/kernel/kprobes.c
@@ -26,6 +26,7 @@
  #include <linux/stop_machine.h>
  #include <linux/stringify.h>
  #include <asm/traps.h>
+#include <asm/opcodes.h>
  #include <asm/cacheflush.h>

  #include "kprobes.h"
@@ -62,10 +63,10 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
  #ifdef CONFIG_THUMB2_KERNEL
         thumb = true;
         addr &= ~1; /* Bit 0 would normally be set to indicate Thumb 
code */
-       insn = ((u16 *)addr)[0];
+       insn = __mem_to_opcode_thumb16(((u16 *)addr)[0]);
         if (is_wide_instruction(insn)) {
                 insn <<= 16;
-               insn |= ((u16 *)addr)[1];
+               insn |= __mem_to_opcode_thumb16(((u16 *)addr)[1]);
                 decode_insn = thumb32_kprobe_decode_insn;
         } else
                 decode_insn = thumb16_kprobe_decode_insn;
@@ -73,7 +74,7 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
         thumb = false;
         if (addr & 0x3)
                 return -EINVAL;
-       insn = *p->addr;
+       insn = __mem_to_opcode_arm(*p->addr);
         decode_insn = arm_kprobe_decode_insn;
  #endif



-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From wsa at the-dreams.de  Tue Jul 23 14:01:39 2013
From: wsa at the-dreams.de (Wolfram Sang)
Date: Tue, 23 Jul 2013 20:01:39 +0200
Subject: [PATCH 06/27] drivers/i2c/busses: don't check resource with
 devm_ioremap_resource
In-Reply-To: <1374602524-3398-1-git-send-email-wsa@the-dreams.de>
References: <1374602524-3398-1-git-send-email-wsa@the-dreams.de>
Message-ID: <1374602524-3398-7-git-send-email-wsa@the-dreams.de>

devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.

Signed-off-by: Wolfram Sang <wsa at the-dreams.de>
---
Please apply via the subsystem-tree.

 drivers/i2c/busses/i2c-stu300.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-stu300.c b/drivers/i2c/busses/i2c-stu300.c
index d1a6b20..ded21cf 100644
--- a/drivers/i2c/busses/i2c-stu300.c
+++ b/drivers/i2c/busses/i2c-stu300.c
@@ -884,9 +884,6 @@ stu300_probe(struct platform_device *pdev)
 
 	dev->pdev = pdev;
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (!res)
-		return -ENOENT;
-
 	dev->virtbase = devm_ioremap_resource(&pdev->dev, res);
 	dev_dbg(&pdev->dev, "initialize bus device I2C%d on virtual "
 		"base %p\n", bus_nr, dev->virtbase);
-- 
1.7.10.4



From gregkh at linuxfoundation.org  Tue Jul 23 14:04:14 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 23 Jul 2013 11:04:14 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <19656720.FrnhefyPXl@amdc1227>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <1446965.6APW5ZgLBW@amdc1227> <20130723173710.GB28284@kroah.com>
 <19656720.FrnhefyPXl@amdc1227>
Message-ID: <20130723180414.GA9630@kroah.com>

On Tue, Jul 23, 2013 at 07:48:11PM +0200, Tomasz Figa wrote:
> On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
> > On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > > > Ick, no.  Why can't you just pass the pointer to the phy itself?  If
> > > > you
> > > > had a "priv" pointer to search from, then you could have just passed
> > > > the
> > > > original phy pointer in the first place, right?
> > > 
> > > IMHO it would be better if you provided some code example, but let's
> > > try to check if I understood you correctly.
> > 
> > It's not my code that I want to have added, so I don't have to write
> > examples, I just get to complain about the existing stuff :)
> 
> Still, I think that some small code snippets illustrating the idea are 
> really helpful.
> 
> > > 8><--------------------------------------------------------------------
> > > ----
> > > 
> > > [Board file]
> > > 
> > > static struct phy my_phy;
> > > 
> > > static struct platform_device phy_pdev = {
> > > 
> > > 	/* ... */
> > > 	.platform_data = &my_phy;
> > > 	/* ... */
> > > 
> > > };
> > > 
> > > static struct platform_device phy_pdev = {
> > > 
> > > 	/* ... */
> > > 	.platform_data = &my_phy;
> > > 	/* ... */
> > > 
> > > };
> > > 
> > > [Provider driver]
> > > 
> > > struct phy *phy = pdev->dev.platform_data;
> > > 
> > > ret = phy_create(phy);
> > > 
> > > [Consumer driver]
> > > 
> > > struct phy *phy = pdev->dev.platform_data;
> > > 
> > > ret = phy_get(&pdev->dev, phy);
> > > 
> > > -----------------------------------------------------------------------
> > > -><8
> > > 
> > > Is this what you mean?
> > 
> > No.  Well, kind of.  What's wrong with using the platform data structure
> > unique to the board to have the pointer?
> > 
> > For example (just randomly picking one), the ata-pxa driver would change
> > include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
> > 
> > struct phy;
> > 
> > struct  pata_pxa_pdata {
> > 	/* PXA DMA DREQ<0:2> pin */
> > 	uint32_t	dma_dreq;
> > 	/* Register shift */
> > 	uint32_t	reg_shift;
> > 	/* IRQ flags */
> > 	uint32_t	irq_flags;
> > 	/* PHY */
> > 	struct phy	*phy;
> > };
> > 
> > Then, when you create the platform, set the phy* pointer with a call to
> > phy_create().  Then you can use that pointer wherever that plaform data
> > is available (i.e. whereever platform_data is at).
> 
> Hmm? So, do you suggest to call phy_create() from board file? What phy_ops 
> struct and other hardware parameters would it take?
> 
> > > > The issue is that a string "name" is not going to scale at all, as it
> > > > requires hard-coded information that will change over time (as the
> > > > existing clock interface is already showing.)
> > > 
> > > I fully agree that a simple, single string will not scale even in some,
> > > not so uncommon cases, but there is already a lot of existing lookup
> > > solutions over the kernel and so there is no point in introducing
> > > another one.
> > I'm trying to get _rid_ of lookup "solutions" and just use a real
> > pointer, as you should.  I'll go tackle those other ones after this one
> > is taken care of, to show how the others should be handled as well.
> 
> There was a reason for introducing lookup solutions. The reason was that in 
> board file there is no way to get a pointer to something that is going to be 
> created much later in time. We don't do time travel ;-).
> 
> > > > Please just pass the real "phy" pointer around, that's what it is
> > > > there
> > > > for.  Your "board binding" logic/code should be able to handle this,
> > > > as
> > > > it somehow was going to do the same thing with a "name".
> > > 
> > > It's technically correct, but quality of this solution isn't really
> > > nice, because it's a layering violation (at least if I understood what
> > > you mean). This is because you need to have full definition of struct
> > > phy in board file and a structure that is used as private data in PHY
> > > core comes from platform code.
> > 
> > No, just a pointer, you don't need the "full" structure until you get to
> > some .c code that actually manipulates the phy itself, for all other
> > places, you are just dealing with a pointer and a structure you never
> > reference.
> > 
> > Does that make more sense?
> 
> Well, to the point that I think I now understood your suggestion. 
> Unfortunately the suggestion alone isn't really something that can be done, 
> considering how driver core and generic frameworks work.

Ok, given that I seem to be totally confused as to exactly how the
board-specific frameworks work, I'll take your word for it.

But again, I will not accept "lookup by name" type solutions, when the
"name" is dynamic and will change.  Because you are using a "name", you
can deal with a pointer, putting it _somewhere_ in your board-specific
data structures, as you are going to need to store it anyway (hint, you
had to get that "name" from somewhere, right?)

And maybe the way that these "generic frameworks" are created is wrong,
given that you don't feel that a generic pointer can be passed to the
needed devices.  That seems like a huge problem, one that has already
been pointed out is causing issues with other subsystems.

So maybe they need to be fixed?

thanks,

greg k-h


From olof at lixom.net  Tue Jul 23 14:03:05 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 23 Jul 2013 11:03:05 -0700
Subject: [PATCH linux-next] arm: zynq: fix compilation warning
In-Reply-To: <20130628103855.c4a89a6f1c6ef425fee34bc6@canb.auug.org.au>
References: <1372336962-6459-1-git-send-email-vincent.stehle@freescale.com>
 <51CC37BF.8030309@monstr.eu>
 <20130628103855.c4a89a6f1c6ef425fee34bc6@canb.auug.org.au>
Message-ID: <CAOesGMgCDb=YUdNsmNw7GfnnQM0F1C2r18h0orW8Zf4-nFWT1w@mail.gmail.com>

On Thu, Jun 27, 2013 at 5:38 PM, Stephen Rothwell <sfr at canb.auug.org.au> wrote:
> On Thu, 27 Jun 2013 15:01:51 +0200 Michal Simek <monstr at monstr.eu> wrote:
>>
>> Arnd asked in this post
>> http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg454947.html
>> to fold his small patch to that larger one.
>>
>> Not sure why it is not there.
>> Arnd, Robin?
>
> Should have asked Andrew :-)
>
> I have added (most of) Arnd's patch to the end of the akpm tree today.

It was a dependency thing where new code was added in arm-soc, so the
sweeping patches in Andrew's tree couldn't cover them (without adding
said dependency and thus no longer apply on top of mainline).

I'll apply this and the keystone fix to the arm-soc fixes branch now
for 3.11-rc3.


-Olof


From plagnioj at jcrosoft.com  Tue Jul 23 14:03:30 2013
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 23 Jul 2013 20:03:30 +0200
Subject: [PATCH v2 01/42] ARM: at91: move at91_pmc.h to
 include/linux/clk/at91.h
In-Reply-To: <1374068247-13574-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <1374068247-13574-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <20130723180330.GL16015@ns203013.ovh.net>

On 15:37 Wed 17 Jul     , Boris BREZILLON wrote:
> This patch moves at91_pmc.h header from machine specific directory
> (arch/arm/mach-at91/include/mach/at91_pmc.h) to clk include directory
> (include/linux/clk/at91.h).

please the at91_pmc.h in the name

so we known the IP that we use and if we change it we will not have to rename
it in the futur

otherwise
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

Best Regards,
J.
> We need this to avoid reference to machine specific headers in clk
> drivers.
> 
> Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
> ---
>  arch/arm/mach-at91/at91rm9200.c                    |    2 +-
>  arch/arm/mach-at91/at91sam9260.c                   |    2 +-
>  arch/arm/mach-at91/at91sam9261.c                   |    2 +-
>  arch/arm/mach-at91/at91sam9263.c                   |    2 +-
>  arch/arm/mach-at91/at91sam9g45.c                   |    2 +-
>  arch/arm/mach-at91/at91sam9n12.c                   |    2 +-
>  arch/arm/mach-at91/at91sam9rl.c                    |    2 +-
>  arch/arm/mach-at91/at91sam9x5.c                    |    2 +-
>  arch/arm/mach-at91/clock.c                         |    2 +-
>  arch/arm/mach-at91/pm.c                            |    2 +-
>  arch/arm/mach-at91/pm_slowclock.S                  |    2 +-
>  arch/arm/mach-at91/sama5d3.c                       |    2 +-
>  arch/arm/mach-at91/setup.c                         |    2 +-
>  drivers/usb/gadget/atmel_usba_udc.c                |    2 +-
>  .../mach/at91_pmc.h => include/linux/clk/at91.h    |    2 +-
>  15 files changed, 15 insertions(+), 15 deletions(-)
>  rename arch/arm/mach-at91/include/mach/at91_pmc.h => include/linux/clk/at91.h (99%)
> 
> diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
> index 4aad93d..8de5b02 100644
> --- a/arch/arm/mach-at91/at91rm9200.c
> +++ b/arch/arm/mach-at91/at91rm9200.c
> @@ -12,13 +12,13 @@
>  
>  #include <linux/module.h>
>  #include <linux/reboot.h>
> +#include <linux/clk/at91.h>
>  
>  #include <asm/irq.h>
>  #include <asm/mach/arch.h>
>  #include <asm/mach/map.h>
>  #include <asm/system_misc.h>
>  #include <mach/at91rm9200.h>
> -#include <mach/at91_pmc.h>
>  #include <mach/at91_st.h>
>  #include <mach/cpu.h>
>  
> diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
> index 5de6074..db9d89a 100644
> --- a/arch/arm/mach-at91/at91sam9260.c
> +++ b/arch/arm/mach-at91/at91sam9260.c
> @@ -11,6 +11,7 @@
>   */
>  
>  #include <linux/module.h>
> +#include <linux/clk/at91.h>
>  
>  #include <asm/proc-fns.h>
>  #include <asm/irq.h>
> @@ -20,7 +21,6 @@
>  #include <mach/cpu.h>
>  #include <mach/at91_dbgu.h>
>  #include <mach/at91sam9260.h>
> -#include <mach/at91_pmc.h>
>  
>  #include "at91_aic.h"
>  #include "at91_rstc.h"
> diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
> index 0e07932..a4123bd 100644
> --- a/arch/arm/mach-at91/at91sam9261.c
> +++ b/arch/arm/mach-at91/at91sam9261.c
> @@ -11,6 +11,7 @@
>   */
>  
>  #include <linux/module.h>
> +#include <linux/clk/at91.h>
>  
>  #include <asm/proc-fns.h>
>  #include <asm/irq.h>
> @@ -19,7 +20,6 @@
>  #include <asm/system_misc.h>
>  #include <mach/cpu.h>
>  #include <mach/at91sam9261.h>
> -#include <mach/at91_pmc.h>
>  
>  #include "at91_aic.h"
>  #include "at91_rstc.h"
> diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
> index 6ce7d18..e0a1a68 100644
> --- a/arch/arm/mach-at91/at91sam9263.c
> +++ b/arch/arm/mach-at91/at91sam9263.c
> @@ -11,6 +11,7 @@
>   */
>  
>  #include <linux/module.h>
> +#include <linux/clk/at91.h>
>  
>  #include <asm/proc-fns.h>
>  #include <asm/irq.h>
> @@ -18,7 +19,6 @@
>  #include <asm/mach/map.h>
>  #include <asm/system_misc.h>
>  #include <mach/at91sam9263.h>
> -#include <mach/at91_pmc.h>
>  
>  #include "at91_aic.h"
>  #include "at91_rstc.h"
> diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
> index 474ee04..29ba2ca 100644
> --- a/arch/arm/mach-at91/at91sam9g45.c
> +++ b/arch/arm/mach-at91/at91sam9g45.c
> @@ -12,13 +12,13 @@
>  
>  #include <linux/module.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/clk/at91.h>
>  
>  #include <asm/irq.h>
>  #include <asm/mach/arch.h>
>  #include <asm/mach/map.h>
>  #include <asm/system_misc.h>
>  #include <mach/at91sam9g45.h>
> -#include <mach/at91_pmc.h>
>  #include <mach/cpu.h>
>  
>  #include "at91_aic.h"
> diff --git a/arch/arm/mach-at91/at91sam9n12.c b/arch/arm/mach-at91/at91sam9n12.c
> index c7d670d..c270503 100644
> --- a/arch/arm/mach-at91/at91sam9n12.c
> +++ b/arch/arm/mach-at91/at91sam9n12.c
> @@ -8,12 +8,12 @@
>  
>  #include <linux/module.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/clk/at91.h>
>  
>  #include <asm/irq.h>
>  #include <asm/mach/arch.h>
>  #include <asm/mach/map.h>
>  #include <mach/at91sam9n12.h>
> -#include <mach/at91_pmc.h>
>  #include <mach/cpu.h>
>  
>  #include "board.h"
> diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c
> index d4ec0d9..2694bd1 100644
> --- a/arch/arm/mach-at91/at91sam9rl.c
> +++ b/arch/arm/mach-at91/at91sam9rl.c
> @@ -10,6 +10,7 @@
>   */
>  
>  #include <linux/module.h>
> +#include <linux/clk/at91.h>
>  
>  #include <asm/proc-fns.h>
>  #include <asm/irq.h>
> @@ -19,7 +20,6 @@
>  #include <mach/cpu.h>
>  #include <mach/at91_dbgu.h>
>  #include <mach/at91sam9rl.h>
> -#include <mach/at91_pmc.h>
>  
>  #include "at91_aic.h"
>  #include "at91_rstc.h"
> diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
> index 2abee66..9fdea07 100644
> --- a/arch/arm/mach-at91/at91sam9x5.c
> +++ b/arch/arm/mach-at91/at91sam9x5.c
> @@ -8,12 +8,12 @@
>  
>  #include <linux/module.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/clk/at91.h>
>  
>  #include <asm/irq.h>
>  #include <asm/mach/arch.h>
>  #include <asm/mach/map.h>
>  #include <mach/at91sam9x5.h>
> -#include <mach/at91_pmc.h>
>  #include <mach/cpu.h>
>  
>  #include "board.h"
> diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
> index 6b2630a..cc263d0 100644
> --- a/arch/arm/mach-at91/clock.c
> +++ b/arch/arm/mach-at91/clock.c
> @@ -24,9 +24,9 @@
>  #include <linux/clk.h>
>  #include <linux/io.h>
>  #include <linux/of_address.h>
> +#include <linux/clk/at91.h>
>  
>  #include <mach/hardware.h>
> -#include <mach/at91_pmc.h>
>  #include <mach/cpu.h>
>  
>  #include <asm/proc-fns.h>
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index 15afb5d..de425e0 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -19,13 +19,13 @@
>  #include <linux/module.h>
>  #include <linux/platform_device.h>
>  #include <linux/io.h>
> +#include <linux/clk/at91.h>
>  
>  #include <asm/irq.h>
>  #include <linux/atomic.h>
>  #include <asm/mach/time.h>
>  #include <asm/mach/irq.h>
>  
> -#include <mach/at91_pmc.h>
>  #include <mach/cpu.h>
>  
>  #include "at91_aic.h"
> diff --git a/arch/arm/mach-at91/pm_slowclock.S b/arch/arm/mach-at91/pm_slowclock.S
> index 098c28d..76387e0 100644
> --- a/arch/arm/mach-at91/pm_slowclock.S
> +++ b/arch/arm/mach-at91/pm_slowclock.S
> @@ -13,8 +13,8 @@
>   */
>  
>  #include <linux/linkage.h>
> +#include <linux/clk/at91.h>
>  #include <mach/hardware.h>
> -#include <mach/at91_pmc.h>
>  #include <mach/at91_ramc.h>
>  
>  
> diff --git a/arch/arm/mach-at91/sama5d3.c b/arch/arm/mach-at91/sama5d3.c
> index 4012797..32e0522 100644
> --- a/arch/arm/mach-at91/sama5d3.c
> +++ b/arch/arm/mach-at91/sama5d3.c
> @@ -9,12 +9,12 @@
>  
>  #include <linux/module.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/clk/at91.h>
>  
>  #include <asm/irq.h>
>  #include <asm/mach/arch.h>
>  #include <asm/mach/map.h>
>  #include <mach/sama5d3.h>
> -#include <mach/at91_pmc.h>
>  #include <mach/cpu.h>
>  
>  #include "soc.h"
> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
> index b17fbcf..de3c519 100644
> --- a/arch/arm/mach-at91/setup.c
> +++ b/arch/arm/mach-at91/setup.c
> @@ -11,6 +11,7 @@
>  #include <linux/pm.h>
>  #include <linux/of_address.h>
>  #include <linux/pinctrl/machine.h>
> +#include <linux/clk/at91.h>
>  
>  #include <asm/system_misc.h>
>  #include <asm/mach/map.h>
> @@ -18,7 +19,6 @@
>  #include <mach/hardware.h>
>  #include <mach/cpu.h>
>  #include <mach/at91_dbgu.h>
> -#include <mach/at91_pmc.h>
>  
>  #include "at91_shdwc.h"
>  #include "soc.h"
> diff --git a/drivers/usb/gadget/atmel_usba_udc.c b/drivers/usb/gadget/atmel_usba_udc.c
> index f018017..a678537 100644
> --- a/drivers/usb/gadget/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/atmel_usba_udc.c
> @@ -326,7 +326,7 @@ static int vbus_is_present(struct usba_udc *udc)
>  
>  #if defined(CONFIG_ARCH_AT91SAM9RL)
>  
> -#include <mach/at91_pmc.h>
> +#include <linux/clk/at91.h>
>  
>  static void toggle_bias(int is_on)
>  {
> diff --git a/arch/arm/mach-at91/include/mach/at91_pmc.h b/include/linux/clk/at91.h
> similarity index 99%
> rename from arch/arm/mach-at91/include/mach/at91_pmc.h
> rename to include/linux/clk/at91.h
> index c604cc6..0ce9586 100644
> --- a/arch/arm/mach-at91/include/mach/at91_pmc.h
> +++ b/include/linux/clk/at91.h
> @@ -1,5 +1,5 @@
>  /*
> - * arch/arm/mach-at91/include/mach/at91_pmc.h
> + * include/linux/clk/at91.h
>   *
>   * Copyright (C) 2005 Ivan Kokshaysky
>   * Copyright (C) SAN People
> -- 
> 1.7.9.5
> 


From wsa at the-dreams.de  Tue Jul 23 14:01:53 2013
From: wsa at the-dreams.de (Wolfram Sang)
Date: Tue, 23 Jul 2013 20:01:53 +0200
Subject: [PATCH 20/27] drivers/watchdog: don't check resource with
 devm_ioremap_resource
In-Reply-To: <1374602524-3398-1-git-send-email-wsa@the-dreams.de>
References: <1374602524-3398-1-git-send-email-wsa@the-dreams.de>
Message-ID: <1374602524-3398-21-git-send-email-wsa@the-dreams.de>

devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.

Signed-off-by: Wolfram Sang <wsa at the-dreams.de>
---
Please apply via the subsystem-tree.

 drivers/watchdog/nuc900_wdt.c |    5 -----
 drivers/watchdog/ts72xx_wdt.c |   10 ----------
 2 files changed, 15 deletions(-)

diff --git a/drivers/watchdog/nuc900_wdt.c b/drivers/watchdog/nuc900_wdt.c
index e2b6d2c..b15b6ef 100644
--- a/drivers/watchdog/nuc900_wdt.c
+++ b/drivers/watchdog/nuc900_wdt.c
@@ -256,11 +256,6 @@ static int nuc900wdt_probe(struct platform_device *pdev)
 	spin_lock_init(&nuc900_wdt->wdt_lock);
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (res == NULL) {
-		dev_err(&pdev->dev, "no memory resource specified\n");
-		return -ENOENT;
-	}
-
 	nuc900_wdt->wdt_base = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(nuc900_wdt->wdt_base))
 		return PTR_ERR(nuc900_wdt->wdt_base);
diff --git a/drivers/watchdog/ts72xx_wdt.c b/drivers/watchdog/ts72xx_wdt.c
index 4da59b4..42913f1 100644
--- a/drivers/watchdog/ts72xx_wdt.c
+++ b/drivers/watchdog/ts72xx_wdt.c
@@ -403,21 +403,11 @@ static int ts72xx_wdt_probe(struct platform_device *pdev)
 	}
 
 	r1 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (!r1) {
-		dev_err(&pdev->dev, "failed to get memory resource\n");
-		return -ENODEV;
-	}
-
 	wdt->control_reg = devm_ioremap_resource(&pdev->dev, r1);
 	if (IS_ERR(wdt->control_reg))
 		return PTR_ERR(wdt->control_reg);
 
 	r2 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-	if (!r2) {
-		dev_err(&pdev->dev, "failed to get memory resource\n");
-		return -ENODEV;
-	}
-
 	wdt->feed_reg = devm_ioremap_resource(&pdev->dev, r2);
 	if (IS_ERR(wdt->feed_reg))
 		return PTR_ERR(wdt->feed_reg);
-- 
1.7.10.4



From victor.kamensky at linaro.org  Tue Jul 23 14:03:54 2013
From: victor.kamensky at linaro.org (Victor Kamensky)
Date: Tue, 23 Jul 2013 11:03:54 -0700
Subject: updates for be8 patch series
In-Reply-To: <CAA3XUr2oDEDD6LFjnZ_N0JGTFUMDZG6O9b3JoeJ8AELrK2KDiw@mail.gmail.com>
References: <CAA3XUr3h5C0oJVrN5iXsM=NFkLMz_Tssp28CysZfwMNS5KvO-Q@mail.gmail.com>
 <51EEC002.9070808@codethink.co.uk>
 <CAA3XUr2oDEDD6LFjnZ_N0JGTFUMDZG6O9b3JoeJ8AELrK2KDiw@mail.gmail.com>
Message-ID: <CAA3XUr1BJD-ypfJiEsp079qHDERjGp-xFxc_ke_Ep9z3N=UPaA@mail.gmail.com>

Hi Ben,

Sorry for multiple post. I am new to this, and I could not get mailing
list to accept my original email.
For sake of others so people can see discussed patch, here it goes
again with patch file inlined
now. Hope it will this time

Wrt BE8 little endian instructions you will need to fix couple more places:
    ftrace arch/arm/kernel/ftrace.c
    kprobes arch/arm/kernel/kprobes.c
Also in big endian mode atomic64_xxx function will need fixes, otherwise perf
counters will be truncated on max of 32bit values
    atomic64 arch/arm/include/asm/atomic.h

I've attached board independent (core) patch from my work that made
Pandaboard ES
kernel run in BE mode. You can check my version of fixes for above issues in the
patch. Look for corresponding files changes. Please rework them
according to style
and rules of your patch series. Note the patch itself contains fixes
for few other
issues that already fixed in your series. I'll cross check and compare
individual
areas latter. I think you may find attached patch interesting as well,
it was developed
independent from yours but matches its very well.

Wrt of testing: ftrace was tested on Pandaboard ES, krprobes changes were tested
with SystemTap at some point of patch version on Pandaboard ES (not
thumb mode though),
also it may deteriorated while ported across different kernel version,
good idea to
rested last patch. atomic64 were tested on Pandaboard ES and Marvell Armada XP.

Thanks,
Victor

Index: linux-linaro-tracking/arch/arm/Makefile
===================================================================
--- linux-linaro-tracking.orig/arch/arm/Makefile
+++ linux-linaro-tracking/arch/arm/Makefile
@@ -16,6 +16,7 @@ LDFLAGS        :=
 LDFLAGS_vmlinux    :=-p --no-undefined -X
 ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
 LDFLAGS_vmlinux    += --be8
+KBUILD_LDFLAGS_MODULE += --be8
 endif

 OBJCOPYFLAGS    :=-O binary -R .comment -S
@@ -43,12 +44,19 @@ ifeq ($(CONFIG_CC_STACKPROTECTOR),y)
 KBUILD_CFLAGS    +=-fstack-protector
 endif

+# Passing endian compilation flag in both CPPFLAGS ad CFLAGS. There are
+# places where CFLAGS alone are used (cmd_record_mcount). And it has to
+# be in CPPFLAGS because it affects what macros (__ARMEB__, __BYTE_ORDER__,
+# __FLOAT_WORD_ORDER__) are defined. So replication of flag seems to be
+# good compromise
 ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
 KBUILD_CPPFLAGS    += -mbig-endian
+KBUILD_CFLAGS    += -mbig-endian
 AS        += -EB
 LD        += -EB
 else
 KBUILD_CPPFLAGS    += -mlittle-endian
+KBUILD_CFLAGS    += -mlittle-endian
 AS        += -EL
 LD        += -EL
 endif
Index: linux-linaro-tracking/arch/arm/boot/compressed/Makefile
===================================================================
--- linux-linaro-tracking.orig/arch/arm/boot/compressed/Makefile
+++ linux-linaro-tracking/arch/arm/boot/compressed/Makefile
@@ -138,6 +138,24 @@ endif
 ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
 LDFLAGS_vmlinux += --be8
 endif
+
+# Passing endian compilation flag in both CPPFLAGS ad CFLAGS. There are
+# places where CFLAGS alone are used (cmd_record_mcount). And it has to
+# be in CPPFLAGS because it affects what macros (__ARMEB__, __BYTE_ORDER__,
+# __FLOAT_WORD_ORDER__) are defined. So replication of flag seems to be
+# good compromise
+ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
+KBUILD_CPPFLAGS    += -mbig-endian
+KBUILD_CFLAGS    += -mbig-endian
+AS        += -EB
+LD        += -EB
+else
+KBUILD_CPPFLAGS    += -mlittle-endian
+KBUILD_CFLAGS    += -mlittle-endian
+AS        += -EL
+LD        += -EL
+endif
+
 # ?
 LDFLAGS_vmlinux += -p
 # Report unresolved symbol references
Index: linux-linaro-tracking/arch/arm/boot/compressed/head.S
===================================================================
--- linux-linaro-tracking.orig/arch/arm/boot/compressed/head.S
+++ linux-linaro-tracking/arch/arm/boot/compressed/head.S
@@ -141,6 +141,12 @@ start:
 #endif
         mov    r7, r1            @ save architecture ID
         mov    r8, r2            @ save atags pointer
+#ifdef CONFIG_LITTLE_ENDIAN_LOADER
+                /*
+                 * Switch to bigendian mode
+                 */
+                setend  be
+#endif /* CONFIG_LITTLE_ENDIAN_LOADER */

 #ifndef __ARM_ARCH_2__
         /*
Index: linux-linaro-tracking/arch/arm/include/asm/setup.h
===================================================================
--- linux-linaro-tracking.orig/arch/arm/include/asm/setup.h
+++ linux-linaro-tracking/arch/arm/include/asm/setup.h
@@ -53,4 +53,8 @@ extern int arm_add_memory(phys_addr_t st
 extern void early_print(const char *str, ...);
 extern void dump_machine_table(void);

+#ifdef CONFIG_LITTLE_ENDIAN_LOADER
+void byteswap_tags(struct tag *t);
+#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
+
 #endif
Index: linux-linaro-tracking/arch/arm/kernel/Makefile
===================================================================
--- linux-linaro-tracking.orig/arch/arm/kernel/Makefile
+++ linux-linaro-tracking/arch/arm/kernel/Makefile
@@ -22,6 +22,7 @@ obj-y        := elf.o entry-armv.o entry-commo
 obj-$(CONFIG_ATAGS)        += atags_parse.o
 obj-$(CONFIG_ATAGS_PROC)    += atags_proc.o
 obj-$(CONFIG_DEPRECATED_PARAM_STRUCT) += atags_compat.o
+obj-$(CONFIG_LITTLE_ENDIAN_LOADER) += atags_byteswap.o

 obj-$(CONFIG_OC_ETM)        += etm.o
 obj-$(CONFIG_CPU_IDLE)        += cpuidle.o
Index: linux-linaro-tracking/arch/arm/kernel/atags_byteswap.c
===================================================================
--- /dev/null
+++ linux-linaro-tracking/arch/arm/kernel/atags_byteswap.c
@@ -0,0 +1,119 @@
+#include <linux/slab.h>
+#include <linux/proc_fs.h>
+#include <linux/swab.h>
+#include <asm/setup.h>
+#include <asm/types.h>
+#include <asm/page.h>
+
+#define byteswap32(x) (x) = __swab32((x))
+#define byteswap16(x) (x) = __swab16((x))
+
+static void __init byteswap_tag_core(struct tag *tag)
+{
+  byteswap32(tag->u.core.flags);
+  byteswap32(tag->u.core.pagesize);
+  byteswap32(tag->u.core.rootdev);
+}
+
+static void __init byteswap_tag_mem32(struct tag *tag)
+{
+  byteswap32(tag->u.mem.size);
+  byteswap32(tag->u.mem.start);
+}
+
+static void __init byteswap_tag_videotext(struct tag *tag)
+{
+  byteswap16(tag->u.videotext.video_page);
+  byteswap16(tag->u.videotext.video_ega_bx);
+  byteswap16(tag->u.videotext.video_points);
+}
+
+static void __init byteswap_tag_ramdisk(struct tag *tag)
+{
+  byteswap32(tag->u.ramdisk.flags);
+  byteswap32(tag->u.ramdisk.size);
+  byteswap32(tag->u.ramdisk.start);
+}
+
+static void __init byteswap_tag_initrd(struct tag *tag)
+{
+  byteswap32(tag->u.initrd.start);
+  byteswap32(tag->u.initrd.size);
+}
+
+static void __init byteswap_tag_serialnr(struct tag *tag)
+{
+  byteswap32(tag->u.serialnr.low);
+  byteswap32(tag->u.serialnr.high);
+}
+
+static void __init byteswap_tag_revision(struct tag *tag)
+{
+    byteswap32(tag->u.revision.rev);
+}
+
+static void __init byteswap_tag_videolfb(struct tag *tag)
+{
+    byteswap16(tag->u.videolfb.lfb_width);
+    byteswap16(tag->u.videolfb.lfb_height);
+    byteswap16(tag->u.videolfb.lfb_depth);
+    byteswap16(tag->u.videolfb.lfb_linelength);
+    byteswap32(tag->u.videolfb.lfb_base);
+    byteswap32(tag->u.videolfb.lfb_size);
+}
+
+static void __init byteswap_tag_acorn(struct tag *tag)
+{
+    byteswap32(tag->u.acorn.memc_control_reg);
+    byteswap32(tag->u.acorn.vram_pages);
+}
+
+static void __init byteswap_tag_memclk(struct tag *tag)
+{
+    byteswap32(tag->u.memclk.fmemclk);
+}
+
+void __init byteswap_tags(struct tag *t)
+{
+  for (; t->hdr.size; t = tag_next(t)) {
+    byteswap32(t->hdr.size);
+    byteswap32(t->hdr.tag);
+    switch(t->hdr.tag) {
+    case ATAG_CORE:
+      byteswap_tag_core(t);
+      break;
+    case ATAG_MEM:
+      byteswap_tag_mem32(t);
+      break;
+    case ATAG_VIDEOTEXT:
+      byteswap_tag_videotext(t);
+      break;
+    case ATAG_RAMDISK:
+      byteswap_tag_ramdisk(t);
+      break;
+    case ATAG_INITRD2:
+      byteswap_tag_initrd(t);
+      break;
+    case ATAG_SERIAL:
+      byteswap_tag_serialnr(t);
+      break;
+    case ATAG_REVISION:
+      byteswap_tag_revision(t);
+      break;
+    case ATAG_VIDEOLFB:
+      byteswap_tag_videolfb(t);
+      break;
+    case ATAG_CMDLINE:
+      break;
+    case ATAG_ACORN:
+      byteswap_tag_acorn(t);
+      break;
+    case ATAG_MEMCLK:
+      byteswap_tag_memclk(t);
+      break;
+    default:
+      /* Need to complain? */
+      break;
+    }
+  }
+}
Index: linux-linaro-tracking/arch/arm/kernel/head-common.S
===================================================================
--- linux-linaro-tracking.orig/arch/arm/kernel/head-common.S
+++ linux-linaro-tracking/arch/arm/kernel/head-common.S
@@ -48,6 +48,9 @@ __vet_atags:
     bne    1f

     ldr    r5, [r2, #0]
+#ifdef CONFIG_LITTLE_ENDIAN_LOADER
+        rev     r5, r5
+#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
 #ifdef CONFIG_OF_FLATTREE
     ldr    r6, =OF_DT_MAGIC        @ is it a DTB?
     cmp    r5, r6
@@ -57,6 +60,9 @@ __vet_atags:
     cmpne    r5, #ATAG_CORE_SIZE_EMPTY
     bne    1f
     ldr    r5, [r2, #4]
+#ifdef CONFIG_LITTLE_ENDIAN_LOADER
+        rev     r5, r5
+#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
     ldr    r6, =ATAG_CORE
     cmp    r5, r6
     bne    1f
Index: linux-linaro-tracking/arch/arm/kernel/module.c
===================================================================
--- linux-linaro-tracking.orig/arch/arm/kernel/module.c
+++ linux-linaro-tracking/arch/arm/kernel/module.c
@@ -45,6 +45,65 @@ void *module_alloc(unsigned long size)
 }
 #endif

+/*
+ * For relocations in exectuable sections if we configured with
+ * CONFIG_CPU_ENDIAN_BE8 we assume that code is in little endian byteswap
+ * form already and we need to byteswap value when we read and when we
+ * write. If relocaton R_ARM_ABS32 type we assume that it is relocation for
+ * data piece and we do not perform byteswaps when such relocation applied.
+ * This herustic based approach may break in future.
+ *
+ * It seems that more correct way to handle be8 in kernel module is
+ * to build module without --be8 option, but perform instruction byteswap
+ * when module sections are loaded, after all relocation are applied.
+ * In order to do such byteswap we need to read all mappings symbols ($a,
+ * $d, $t), sort them, and apply byteswaps for $a and $t entries.
+ */
+static inline u32 read_section_u32(Elf32_Shdr *dstsec, unsigned long loc)
+{
+       u32 retval = *(u32 *)loc;
+
+#ifdef CONFIG_CPU_ENDIAN_BE8
+        if (dstsec->sh_flags & SHF_EXECINSTR) {
+                retval = __swab32(retval);
+        }
+#endif /* CONFIG_CPU_ENDIAN_BE8 */
+        return retval;
+}
+
+static inline void write_section_u32(Elf32_Shdr *dstsec, unsigned
long loc, u32 value)
+{
+#ifdef CONFIG_CPU_ENDIAN_BE8
+        if (dstsec->sh_flags & SHF_EXECINSTR) {
+                value = __swab32(value);
+        }
+#endif /* CONFIG_CPU_ENDIAN_BE8 */
+        *(u32 *) loc = value;
+}
+
+#ifdef CONFIG_THUMB2_KERNEL
+static inline u16 read_section_u16(Elf32_Shdr *dstsec, unsigned long loc)
+{
+        u16 retval = *(u16 *) loc;
+#ifdef CONFIG_CPU_ENDIAN_BE8
+        if (dstsec->sh_flags & SHF_EXECINSTR) {
+                retval = __swab16(retval);
+        }
+#endif /* CONFIG_CPU_ENDIAN_BE8 */
+        return retval;
+}
+
+static inline void write_section_u16(Elf32_Shdr *dstsec, unsigned
long loc, u16 value)
+{
+#ifdef CONFIG_CPU_ENDIAN_BE8
+        if (dstsec->sh_flags & SHF_EXECINSTR) {
+                value = __swab16(value);
+        }
+#endif /* CONFIG_CPU_ENDIAN_BE8 */
+        *(u16 *) loc = value;
+}
+#endif /* CONFIG_THUMB2_KERNEL */
+
 int
 apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
            unsigned int relindex, struct module *module)
@@ -60,6 +119,7 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
         Elf32_Sym *sym;
         const char *symname;
         s32 offset;
+                u32 loc_u32;
 #ifdef CONFIG_THUMB2_KERNEL
         u32 upper, lower, sign, j1, j2;
 #endif
@@ -95,7 +155,8 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
         case R_ARM_PC24:
         case R_ARM_CALL:
         case R_ARM_JUMP24:
-            offset = (*(u32 *)loc & 0x00ffffff) << 2;
+                        loc_u32 = read_section_u32(dstsec, loc);
+            offset = (loc_u32 & 0x00ffffff) << 2;
             if (offset & 0x02000000)
                 offset -= 0x04000000;

@@ -112,27 +173,33 @@ apply_relocate(Elf32_Shdr *sechdrs, cons

             offset >>= 2;

-            *(u32 *)loc &= 0xff000000;
-            *(u32 *)loc |= offset & 0x00ffffff;
+            loc_u32 &= 0xff000000;
+            loc_u32 |= offset & 0x00ffffff;
+                        write_section_u32(dstsec, loc, loc_u32);
             break;

-           case R_ARM_V4BX:
+                case R_ARM_V4BX:
+                        loc_u32 = read_section_u32(dstsec, loc);
                /* Preserve Rm and the condition code. Alter
             * other bits to re-code instruction as
             * MOV PC,Rm.
             */
-               *(u32 *)loc &= 0xf000000f;
-               *(u32 *)loc |= 0x01a0f000;
+               loc_u32 &= 0xf000000f;
+               loc_u32 |= 0x01a0f000;
+                       write_section_u32(dstsec, loc, loc_u32);
                break;

         case R_ARM_PREL31:
-            offset = *(u32 *)loc + sym->st_value - loc;
-            *(u32 *)loc = offset & 0x7fffffff;
+                        loc_u32 = read_section_u32(dstsec, loc);
+            offset = loc_u32 + sym->st_value - loc;
+            loc_u32 = offset & 0x7fffffff;
+                        write_section_u32(dstsec, loc, loc_u32);
             break;

         case R_ARM_MOVW_ABS_NC:
         case R_ARM_MOVT_ABS:
-            offset = *(u32 *)loc;
+                        loc_u32 = read_section_u32(dstsec, loc);
+            offset = loc_u32;
             offset = ((offset & 0xf0000) >> 4) | (offset & 0xfff);
             offset = (offset ^ 0x8000) - 0x8000;

@@ -140,16 +207,17 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
             if (ELF32_R_TYPE(rel->r_info) == R_ARM_MOVT_ABS)
                 offset >>= 16;

-            *(u32 *)loc &= 0xfff0f000;
-            *(u32 *)loc |= ((offset & 0xf000) << 4) |
-                    (offset & 0x0fff);
+            loc_u32 &= 0xfff0f000;
+            loc_u32 |= ((offset & 0xf000) << 4) |
+                                   (offset & 0x0fff);
+                        write_section_u32(dstsec, loc, loc_u32);
             break;

 #ifdef CONFIG_THUMB2_KERNEL
         case R_ARM_THM_CALL:
         case R_ARM_THM_JUMP24:
-            upper = *(u16 *)loc;
-            lower = *(u16 *)(loc + 2);
+                        upper = read_section_u16(dstsec, loc);
+            lower = read_section_u16(dstsec, loc + 2);

             /*
              * 25 bit signed address range (Thumb-2 BL and B.W
@@ -198,17 +266,19 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
             sign = (offset >> 24) & 1;
             j1 = sign ^ (~(offset >> 23) & 1);
             j2 = sign ^ (~(offset >> 22) & 1);
-            *(u16 *)loc = (u16)((upper & 0xf800) | (sign << 10) |
-                        ((offset >> 12) & 0x03ff));
-            *(u16 *)(loc + 2) = (u16)((lower & 0xd000) |
-                          (j1 << 13) | (j2 << 11) |
-                          ((offset >> 1) & 0x07ff));
+                        write_section_u16(dstsec, loc,
+                                          (u16)((upper & 0xf800) |
(sign << 10) |
+                                                ((offset >> 12) & 0x03ff)));
+                        write_section_u16(dstsec, loc + 2,
+                                          (u16)((lower & 0xd000) |
+                                                (j1 << 13) | (j2 << 11) |
+                                                ((offset >> 1) & 0x07ff)));
             break;

         case R_ARM_THM_MOVW_ABS_NC:
         case R_ARM_THM_MOVT_ABS:
-            upper = *(u16 *)loc;
-            lower = *(u16 *)(loc + 2);
+                        upper = read_section_u16(dstsec, loc);
+            lower = read_section_u16(dstsec, loc + 2);

             /*
              * MOVT/MOVW instructions encoding in Thumb-2:
@@ -229,12 +299,14 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
             if (ELF32_R_TYPE(rel->r_info) == R_ARM_THM_MOVT_ABS)
                 offset >>= 16;

-            *(u16 *)loc = (u16)((upper & 0xfbf0) |
-                        ((offset & 0xf000) >> 12) |
-                        ((offset & 0x0800) >> 1));
-            *(u16 *)(loc + 2) = (u16)((lower & 0x8f00) |
-                          ((offset & 0x0700) << 4) |
-                          (offset & 0x00ff));
+                        write_section_u16(dstsec, loc,
+                                          (u16)((upper & 0xfbf0) |
+                                                ((offset & 0xf000) >> 12) |
+                                                ((offset & 0x0800) >> 1)));
+                        write_section_u16(dstsec, loc + 2,
+                                          (u16)((lower & 0x8f00) |
+                                                ((offset & 0x0700) << 4) |
+                                                (offset & 0x00ff)));
             break;
 #endif

Index: linux-linaro-tracking/arch/arm/mm/Kconfig
===================================================================
--- linux-linaro-tracking.orig/arch/arm/mm/Kconfig
+++ linux-linaro-tracking/arch/arm/mm/Kconfig
@@ -695,6 +695,15 @@ config CPU_ENDIAN_BE32
     help
       Support for the BE-32 (big-endian) mode on pre-ARMv6 processors.

+config LITTLE_ENDIAN_LOADER
+        bool
+        depends on CPU_BIG_ENDIAN
+        default y
+        help
+          If Linux should operate in big-endian mode, but bootloader
(i.e u-boot)
+          is still in little endian mode and passes boot information in little
+          endian form set this flag
+
 config CPU_HIGH_VECTOR
     depends on !MMU && CPU_CP15 && !CPU_ARM740T
     bool "Select the High exception vector"
Index: linux-linaro-tracking/arch/arm/mm/alignment.c
===================================================================
--- linux-linaro-tracking.orig/arch/arm/mm/alignment.c
+++ linux-linaro-tracking/arch/arm/mm/alignment.c
@@ -792,6 +792,10 @@ do_alignment(unsigned long addr, unsigne

     regs->ARM_pc += isize;

+#ifdef CONFIG_CPU_ENDIAN_BE8
+        instr = __swab32(instr); /* little endian instruction */
+#endif /* CONFIG_CPU_ENDIAN_BE8 */
+
     switch (CODING_BITS(instr)) {
     case 0x00000000:    /* 3.13.4 load/store instruction extensions */
         if (LDSTHD_I_BIT(instr))
Index: linux-linaro-tracking/arch/arm/kernel/head.S
===================================================================
--- linux-linaro-tracking.orig/arch/arm/kernel/head.S
+++ linux-linaro-tracking/arch/arm/kernel/head.S
@@ -89,6 +89,12 @@ ENTRY(stext)
     @ ensure svc mode and all interrupts masked
     safe_svcmode_maskall r9

+#ifdef CONFIG_LITTLE_ENDIAN_LOADER
+    /*
+    * Switch to bigendian mode
+    */
+    setend    be
+#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
     mrc    p15, 0, r9, c0, c0        @ get processor id
     bl    __lookup_processor_type        @ r5=procinfo r9=cpuid
     movs    r10, r5                @ invalid processor (r5=0)?
@@ -356,6 +362,12 @@ ENTRY(secondary_startup)
 #endif
     safe_svcmode_maskall r9

+#ifdef CONFIG_LITTLE_ENDIAN_LOADER
+    /*
+    * Switch to bigendian mode
+    */
+    setend    be
+#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
     mrc    p15, 0, r9, c0, c0        @ get processor id
     bl    __lookup_processor_type
     movs    r10, r5                @ invalid processor?
@@ -427,6 +439,9 @@ __enable_mmu:
 #ifdef CONFIG_CPU_ICACHE_DISABLE
     bic    r0, r0, #CR_I
 #endif
+#ifdef CONFIG_CPU_ENDIAN_BE8
+    orr    r0, r0, #CR_EE    @ big-endian page tables
+#endif
 #ifdef CONFIG_ARM_LPAE
     mov    r5, #0
     mcrr    p15, 0, r4, r5, c2        @ load TTBR0
@@ -592,8 +607,14 @@ __fixup_a_pv_table:
     b    2f
 1:    add     r7, r3
     ldrh    ip, [r7, #2]
+#ifdef __ARMEB__
+        rev     ip, ip   @ byteswap instruction
+#endif /* __ARMEB__ */
     and    ip, 0x8f00
     orr    ip, r6    @ mask in offset bits 31-24
+#ifdef __ARMEB__
+        rev     ip, ip   @ byteswap instruction
+#endif /* __ARMEB__ */
     strh    ip, [r7, #2]
 2:    cmp    r4, r5
     ldrcc    r7, [r4], #4    @ use branch for delay slot
@@ -602,8 +623,14 @@ __fixup_a_pv_table:
 #else
     b    2f
 1:    ldr    ip, [r7, r3]
+#ifdef __ARMEB__
+        rev     ip, ip   @ byteswap instruction
+#endif /* __ARMEB__ */
     bic    ip, ip, #0x000000ff
     orr    ip, ip, r6    @ mask in offset bits 31-24
+#ifdef __ARMEB__
+        rev     ip, ip   @ byteswap instruction
+#endif /* __ARMEB__ */
     str    ip, [r7, r3]
 2:    cmp    r4, r5
     ldrcc    r7, [r4], #4    @ use branch for delay slot
Index: linux-linaro-tracking/arch/arm/kernel/kprobes.c
===================================================================
--- linux-linaro-tracking.orig/arch/arm/kernel/kprobes.c
+++ linux-linaro-tracking/arch/arm/kernel/kprobes.c
@@ -66,14 +66,24 @@ int __kprobes arch_prepare_kprobe(struct
     if (is_wide_instruction(insn)) {
         insn <<= 16;
         insn |= ((u16 *)addr)[1];
+#ifdef CONFIG_CPU_ENDIAN_BE8
+                insn = __swab32(insn); /* little endian instruction */
+#endif
         decode_insn = thumb32_kprobe_decode_insn;
-    } else
-        decode_insn = thumb16_kprobe_decode_insn;
+    } else {
+                decode_insn = thumb16_kprobe_decode_insn;
+#ifdef CONFIG_CPU_ENDIAN_BE8
+                insn = __swab16(insn); /* little endian instruction */
+#endif
+        }
 #else /* !CONFIG_THUMB2_KERNEL */
     thumb = false;
     if (addr & 0x3)
         return -EINVAL;
     insn = *p->addr;
+#ifdef CONFIG_CPU_ENDIAN_BE8
+        insn = __swab32(insn); /* little endian instruction */
+#endif
     decode_insn = arm_kprobe_decode_insn;
 #endif

@@ -89,7 +99,11 @@ int __kprobes arch_prepare_kprobe(struct
         if (!p->ainsn.insn)
             return -ENOMEM;
         for (is = 0; is < MAX_INSN_SIZE; ++is)
+#ifndef CONFIG_CPU_ENDIAN_BE8
             p->ainsn.insn[is] = tmp_insn[is];
+#else
+                        p->ainsn.insn[is] = __swab32(tmp_insn[is]);
/* little endian instruction */
+#endif
         flush_insns(p->ainsn.insn,
                 sizeof(p->ainsn.insn[0]) * MAX_INSN_SIZE);
         p->ainsn.insn_fn = (kprobe_insn_fn_t *)
@@ -113,10 +127,17 @@ void __kprobes arch_arm_kprobe(struct kp
         /* Remove any Thumb flag */
         addr = (void *)((uintptr_t)p->addr & ~1);

-        if (is_wide_instruction(p->opcode))
+        if (is_wide_instruction(p->opcode)) {
             brkp = KPROBE_THUMB32_BREAKPOINT_INSTRUCTION;
-        else
+#ifdef CONFIG_CPU_ENDIAN_BE8
+                brkp = __swab32(brkp);
+#endif /* CONFIG_CPU_ENDIAN_BE8 */
+        } else {
             brkp = KPROBE_THUMB16_BREAKPOINT_INSTRUCTION;
+#ifdef CONFIG_CPU_ENDIAN_BE8
+                brkp = __swab16(brkp);
+#endif /* CONFIG_CPU_ENDIAN_BE8 */
+            }
     } else {
         kprobe_opcode_t insn = p->opcode;

@@ -127,6 +148,10 @@ void __kprobes arch_arm_kprobe(struct kp
             brkp |= 0xe0000000;  /* Unconditional instruction */
         else
             brkp |= insn & 0xf0000000;  /* Copy condition from insn */
+#ifdef CONFIG_CPU_ENDIAN_BE8
+        brkp = __swab32(brkp);
+#endif /* CONFIG_CPU_ENDIAN_BE8 */
+
     }

     patch_text(addr, brkp);
@@ -144,8 +169,12 @@ int __kprobes __arch_disarm_kprobe(void
 {
     struct kprobe *kp = p;
     void *addr = (void *)((uintptr_t)kp->addr & ~1);
+    kprobe_opcode_t insn = kp->opcode;

-    __patch_text(addr, kp->opcode);
+#ifdef CONFIG_CPU_ENDIAN_BE8
+        insn = __swab32(insn); /* little endian instruction */
+#endif
+    __patch_text(addr, insn);

     return 0;
 }
Index: linux-linaro-tracking/arch/arm/kernel/traps.c
===================================================================
--- linux-linaro-tracking.orig/arch/arm/kernel/traps.c
+++ linux-linaro-tracking/arch/arm/kernel/traps.c
@@ -426,6 +426,10 @@ asmlinkage void __exception do_undefinst
         goto die_sig;
     }

+#ifdef CONFIG_CPU_ENDIAN_BE8
+        instr = __swab32(instr); /* little endian instruction */
+#endif /* CONFIG_CPU_ENDIAN_BE8 */
+
     if (call_undef_hook(regs, instr) == 0)
         return;

Index: linux-linaro-tracking/arch/arm/kernel/ftrace.c
===================================================================
--- linux-linaro-tracking.orig/arch/arm/kernel/ftrace.c
+++ linux-linaro-tracking/arch/arm/kernel/ftrace.c
@@ -100,10 +100,18 @@ static int ftrace_modify_code(unsigned l
         if (probe_kernel_read(&replaced, (void *)pc, MCOUNT_INSN_SIZE))
             return -EFAULT;

+#ifdef CONFIG_CPU_ENDIAN_BE8
+        replaced = __swab32(replaced); /* little endian instruction */
+#endif /* CONFIG_CPU_ENDIAN_BE8 */
+
         if (replaced != old)
             return -EINVAL;
     }

+#ifdef CONFIG_CPU_ENDIAN_BE8
+        new = __swab32(new); /* little endian instruction */
+#endif /* CONFIG_CPU_ENDIAN_BE8 */
+
     if (probe_kernel_write((void *)pc, &new, MCOUNT_INSN_SIZE))
         return -EPERM;

Index: linux-linaro-tracking/arch/arm/kernel/atags_parse.c
===================================================================
--- linux-linaro-tracking.orig/arch/arm/kernel/atags_parse.c
+++ linux-linaro-tracking/arch/arm/kernel/atags_parse.c
@@ -216,6 +216,10 @@ struct machine_desc * __init setup_machi
     if (tags->hdr.tag != ATAG_CORE)
         convert_to_tag_list(tags);
 #endif
+#ifdef CONFIG_LITTLE_ENDIAN_LOADER
+    byteswap_tags(tags);
+#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
+
     if (tags->hdr.tag != ATAG_CORE) {
         early_print("Warning: Neither atags nor dtb found\n");
         tags = (struct tag *)&default_tags;
Index: linux-linaro-tracking/arch/arm/kernel/sleep.S
===================================================================
--- linux-linaro-tracking.orig/arch/arm/kernel/sleep.S
+++ linux-linaro-tracking/arch/arm/kernel/sleep.S
@@ -81,6 +81,13 @@ ENDPROC(cpu_resume_after_mmu)
     .data
     .align
 ENTRY(cpu_resume)
+#ifdef CONFIG_LITTLE_ENDIAN_LOADER
+        /*
+         * Switch to bigendian mode.
+         * Platform resume code most likely already did that, but just in case
+         */
+        setend  be
+#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
 #ifdef CONFIG_SMP
     mov    r1, #0            @ fall-back logical index for UP
     ALT_SMP(mrc p15, 0, r0, c0, c0, 5)
Index: linux-linaro-tracking/arch/arm/include/asm/atomic.h
===================================================================
--- linux-linaro-tracking.orig/arch/arm/include/asm/atomic.h
+++ linux-linaro-tracking/arch/arm/include/asm/atomic.h
@@ -301,8 +301,13 @@ static inline void atomic64_add(u64 i, a

     __asm__ __volatile__("@ atomic64_add\n"
 "1:    ldrexd    %0, %H0, [%3]\n"
+#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
 "    adds    %0, %0, %4\n"
 "    adc    %H0, %H0, %H4\n"
+#else
+"    adds    %H0, %H0, %H4\n"
+"    adc    %0, %0, %4\n"
+#endif
 "    strexd    %1, %0, %H0, [%3]\n"
 "    teq    %1, #0\n"
 "    bne    1b"
@@ -320,8 +325,13 @@ static inline u64 atomic64_add_return(u6

     __asm__ __volatile__("@ atomic64_add_return\n"
 "1:    ldrexd    %0, %H0, [%3]\n"
+#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
 "    adds    %0, %0, %4\n"
 "    adc    %H0, %H0, %H4\n"
+#else
+"    adds    %H0, %H0, %H4\n"
+"    adc    %0, %0, %4\n"
+#endif
 "    strexd    %1, %0, %H0, [%3]\n"
 "    teq    %1, #0\n"
 "    bne    1b"
@@ -341,8 +351,13 @@ static inline void atomic64_sub(u64 i, a

     __asm__ __volatile__("@ atomic64_sub\n"
 "1:    ldrexd    %0, %H0, [%3]\n"
+#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
 "    subs    %0, %0, %4\n"
 "    sbc    %H0, %H0, %H4\n"
+#else
+"    subs    %H0, %H0, %H4\n"
+"    sbc    %0, %0, %4\n"
+#endif
 "    strexd    %1, %0, %H0, [%3]\n"
 "    teq    %1, #0\n"
 "    bne    1b"
@@ -360,8 +375,13 @@ static inline u64 atomic64_sub_return(u6

     __asm__ __volatile__("@ atomic64_sub_return\n"
 "1:    ldrexd    %0, %H0, [%3]\n"
+#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
 "    subs    %0, %0, %4\n"
 "    sbc    %H0, %H0, %H4\n"
+#else
+"    subs    %H0, %H0, %H4\n"
+"    sbc    %0, %0, %4\n"
+#endif
 "    strexd    %1, %0, %H0, [%3]\n"
 "    teq    %1, #0\n"
 "    bne    1b"
@@ -428,9 +448,15 @@ static inline u64 atomic64_dec_if_positi

     __asm__ __volatile__("@ atomic64_dec_if_positive\n"
 "1:    ldrexd    %0, %H0, [%3]\n"
+#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
 "    subs    %0, %0, #1\n"
 "    sbc    %H0, %H0, #0\n"
 "    teq    %H0, #0\n"
+#else
+"    subs    %H0, %H0, #1\n"
+"    sbc    %0, %0, #0\n"
+"    teq    %0, #0\n"
+#endif
 "    bmi    2f\n"
 "    strexd    %1, %0, %H0, [%3]\n"
 "    teq    %1, #0\n"
@@ -459,8 +485,13 @@ static inline int atomic64_add_unless(at
 "    teqeq    %H0, %H5\n"
 "    moveq    %1, #0\n"
 "    beq    2f\n"
+#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
 "    adds    %0, %0, %6\n"
 "    adc    %H0, %H0, %H6\n"
+#else
+"    adds    %H0, %H0, %H6\n"
+"    adc    %0, %0, %6\n"
+#endif
 "    strexd    %2, %0, %H0, [%4]\n"
 "    teq    %2, #0\n"
 "    bne    1b\n"


On 23 July 2013 10:53, Victor Kamensky <victor.kamensky at linaro.org> wrote:
> On 23 July 2013 10:40, Ben Dooks <ben.dooks at codethink.co.uk> wrote:
>> On 23/07/13 18:24, Victor Kamensky wrote:
>>>
>>> Hi Ben,
>>>
>>> Wrt BE8 little endian instructions you will need to fix couple more
>>> places:
>>>      ftrace arch/arm/kernel/ftrace.c
>>>      kprobes arch/arm/kernel/kprobes.c
>>> Also in big endian mode atomic64_xxx function will need fixes, otherwise
>>> perf
>>> counters will be truncated on max of 32bit values
>>>      atomic64 arch/arm/include/asm/atomic.h
>>
>>
>> Hmm, thought ftrace already did the right endian-ness conversions,
>> although it is possible it could have missed one.
>>
>> The atomic instructions should work fine for BE8, they're using
>> STRD which should be correct.
>
> atomic64_read and atomic64_set are fine, but atomic64_add,
> atomic64_add_return, atomic64_sub, atomic64_sub_return, etc are not OK.
> The issue is in arithmetic operations not load/store.
>
> Thanks,
> Victor
>
>>
>>> I've attached board independent (core) patch from my work that made
>>> Pandaboard ES
>>> kernel run in BE mode. You can check my version of fixes for above
>>> issues in the
>>> patch. Look for corresponding files changes. Please rework them
>>> according to style
>>> and rules of your patch series. Note the patch itself contains fixes for
>>> few other
>>> issues that already fixed in your series. I'll cross check and compare
>>> individual
>>> areas latter. I think you may find attached patch interesting as well,
>>> it was developed
>>> independent from yours but matches its very well.
>>
>>
>>>
>>
>> --
>> Ben Dooks                               http://www.codethink.co.uk/
>> Senior Engineer                         Codethink - Providing Genius


From wsa at the-dreams.de  Tue Jul 23 14:01:57 2013
From: wsa at the-dreams.de (Wolfram Sang)
Date: Tue, 23 Jul 2013 20:01:57 +0200
Subject: [PATCH 24/27] sound/soc/pxa: don't check resource with
 devm_ioremap_resource
In-Reply-To: <1374602524-3398-1-git-send-email-wsa@the-dreams.de>
References: <1374602524-3398-1-git-send-email-wsa@the-dreams.de>
Message-ID: <1374602524-3398-25-git-send-email-wsa@the-dreams.de>

devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.

Signed-off-by: Wolfram Sang <wsa at the-dreams.de>
---
Please apply via the subsystem-tree.

 sound/soc/pxa/mmp-sspa.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/sound/soc/pxa/mmp-sspa.c b/sound/soc/pxa/mmp-sspa.c
index 62142ce..1605934 100644
--- a/sound/soc/pxa/mmp-sspa.c
+++ b/sound/soc/pxa/mmp-sspa.c
@@ -430,9 +430,6 @@ static int asoc_mmp_sspa_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (res == NULL)
-		return -ENOMEM;
-
 	priv->sspa->mmio_base = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(priv->sspa->mmio_base))
 		return PTR_ERR(priv->sspa->mmio_base);
-- 
1.7.10.4



From swarren at wwwdotorg.org  Tue Jul 23 14:11:45 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 23 Jul 2013 11:11:45 -0700
Subject: [PATCH] ARM: tegra: enable ULPI phy on Colibri T20
Message-ID: <1374603105-21226-1-git-send-email-swarren@wwwdotorg.org>

From: Lucas Stach <dev at lynxeye.de>

This was missed when splitting out the phy from the controller node in
commit 9dffe3be3f32 (ARM: tegra: modify ULPI reset GPIO properties).

Signed-off-by: Lucas Stach <dev at lynxeye.de>
Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
Olof, Arnd, this is a fix for 3.11. Thanks!

 arch/arm/boot/dts/tegra20-colibri-512.dtsi |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
index 2fcb3f2..5592be6 100644
--- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
@@ -457,6 +457,7 @@
 	};
 
 	usb-phy at c5004000 {
+		status = "okay";
 		nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1)
 			GPIO_ACTIVE_LOW>;
 	};
-- 
1.7.10.4



From swarren at wwwdotorg.org  Tue Jul 23 14:15:12 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 23 Jul 2013 11:15:12 -0700
Subject: [PATCH] ARM: dts: tegra114: dalmore: fix the irq trigger type
 of Palmas MFD device
In-Reply-To: <51EE968B.1050103@nvidia.com>
References: <1374574191-24396-1-git-send-email-josephl@nvidia.com>
 <51EE968B.1050103@nvidia.com>
Message-ID: <51EEC830.9000407@wwwdotorg.org>

On 07/23/2013 07:43 AM, Laxman Dewangan wrote:
> On Tuesday 23 July 2013 03:39 PM, Joseph Lo wrote:
>> The IRQ trigger type of Palmas MFD device (tps65913) is low-level
>> sensitive. The wrong configuration would cause an interrupt storm
>> when booting the system. Fixing it in DT with appropriate interrupt
>> type.

>> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts

>>           palmas: tps65913 {
>>               compatible = "ti,palmas";
>>               reg = <0x58>;
>> -            interrupts = <0 86 0x4>;
>> +            interrupts = <0 86 0x8>;
> 
> This fails as GIC does not support the interrupt flag of 8.
...
> I did not get the interrupt storm and even interrupt is not working on tot.
> Two ways to resolve this:
> - Change the interrupt flag to 0 from 4. Or
> - Remove the nvidia,invert-interrupt; for PMC node.

Yes, use the PMIC property please.



From ben.dooks at codethink.co.uk  Tue Jul 23 14:30:21 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Tue, 23 Jul 2013 19:30:21 +0100
Subject: updates for be8 patch series
In-Reply-To: <CAA3XUr1BJD-ypfJiEsp079qHDERjGp-xFxc_ke_Ep9z3N=UPaA@mail.gmail.com>
References: <CAA3XUr3h5C0oJVrN5iXsM=NFkLMz_Tssp28CysZfwMNS5KvO-Q@mail.gmail.com>
 <51EEC002.9070808@codethink.co.uk>
 <CAA3XUr2oDEDD6LFjnZ_N0JGTFUMDZG6O9b3JoeJ8AELrK2KDiw@mail.gmail.com>
 <CAA3XUr1BJD-ypfJiEsp079qHDERjGp-xFxc_ke_Ep9z3N=UPaA@mail.gmail.com>
Message-ID: <51EECBBD.20000@codethink.co.uk>

On 23/07/13 19:03, Victor Kamensky wrote:
> Hi Ben,
>
> Sorry for multiple post. I am new to this, and I could not get mailing
> list to accept my original email.
> For sake of others so people can see discussed patch, here it goes
> again with patch file inlined
> now. Hope it will this time
>
> Wrt BE8 little endian instructions you will need to fix couple more places:
>      ftrace arch/arm/kernel/ftrace.c
>      kprobes arch/arm/kernel/kprobes.c
> Also in big endian mode atomic64_xxx function will need fixes, otherwise perf
> counters will be truncated on max of 32bit values
>      atomic64 arch/arm/include/asm/atomic.h
>
> I've attached board independent (core) patch from my work that made
> Pandaboard ES
> kernel run in BE mode. You can check my version of fixes for above issues in the
> patch. Look for corresponding files changes. Please rework them
> according to style
> and rules of your patch series. Note the patch itself contains fixes
> for few other
> issues that already fixed in your series. I'll cross check and compare
> individual
> areas latter. I think you may find attached patch interesting as well,
> it was developed
> independent from yours but matches its very well.
>
> Wrt of testing: ftrace was tested on Pandaboard ES, krprobes changes were tested
> with SystemTap at some point of patch version on Pandaboard ES (not
> thumb mode though),
> also it may deteriorated while ported across different kernel version,
> good idea to
> rested last patch. atomic64 were tested on Pandaboard ES and Marvell Armada XP.
>
> Thanks,
> Victor

First notes, please always format your emails (where possible) to
under 80 characters per line so that they do not get mangled when
viewed on limited screens (for example, I often read email via a
24x80 terminal)

Second note, when producing patches, it is better to try and split
them into a series of patches to reach a goal than just one large
patch. It keeps a lot of useful information (see patch comments)
and it means that if there is a problem, then bits can be lifted
out to check.


> Index: linux-linaro-tracking/arch/arm/Makefile
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/Makefile
> +++ linux-linaro-tracking/arch/arm/Makefile
> @@ -16,6 +16,7 @@ LDFLAGS        :=
>   LDFLAGS_vmlinux    :=-p --no-undefined -X
>   ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
>   LDFLAGS_vmlinux    += --be8
> +KBUILD_LDFLAGS_MODULE += --be8
>   endif
>
>   OBJCOPYFLAGS    :=-O binary -R .comment -S
> @@ -43,12 +44,19 @@ ifeq ($(CONFIG_CC_STACKPROTECTOR),y)
>   KBUILD_CFLAGS    +=-fstack-protector
>   endif
>
> +# Passing endian compilation flag in both CPPFLAGS ad CFLAGS. There are
> +# places where CFLAGS alone are used (cmd_record_mcount). And it has to
> +# be in CPPFLAGS because it affects what macros (__ARMEB__, __BYTE_ORDER__,
> +# __FLOAT_WORD_ORDER__) are defined. So replication of flag seems to be
> +# good compromise
>   ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
>   KBUILD_CPPFLAGS    += -mbig-endian
> +KBUILD_CFLAGS    += -mbig-endian
>   AS        += -EB
>   LD        += -EB
>   else
>   KBUILD_CPPFLAGS    += -mlittle-endian
> +KBUILD_CFLAGS    += -mlittle-endian
>   AS        += -EL
>   LD        += -EL
>   endif

See the comment below.

> Index: linux-linaro-tracking/arch/arm/boot/compressed/Makefile
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/boot/compressed/Makefile
> +++ linux-linaro-tracking/arch/arm/boot/compressed/Makefile
> @@ -138,6 +138,24 @@ endif
>   ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
>   LDFLAGS_vmlinux += --be8
>   endif
> +
> +# Passing endian compilation flag in both CPPFLAGS ad CFLAGS. There are
> +# places where CFLAGS alone are used (cmd_record_mcount). And it has to
> +# be in CPPFLAGS because it affects what macros (__ARMEB__, __BYTE_ORDER__,
> +# __FLOAT_WORD_ORDER__) are defined. So replication of flag seems to be
> +# good compromise
> +ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
> +KBUILD_CPPFLAGS    += -mbig-endian
> +KBUILD_CFLAGS    += -mbig-endian
> +AS        += -EB
> +LD        += -EB
> +else
> +KBUILD_CPPFLAGS    += -mlittle-endian
> +KBUILD_CFLAGS    += -mlittle-endian
> +AS        += -EL
> +LD        += -EL
> +endif
> +
>   # ?
>   LDFLAGS_vmlinux += -p
>   # Report unresolved symbol references

I've not been bitten by this one. Is there anyone else who can comment
on KBUILD_CFLAGS vs KBUILD_CPPFLAGS?

I had assumed that arch/arm/boot/compressed/Makefile would have
inherited the flags from the arch/arm/Makefile. Someone else would
be better qualified to comment on this.

> Index: linux-linaro-tracking/arch/arm/boot/compressed/head.S
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/boot/compressed/head.S
> +++ linux-linaro-tracking/arch/arm/boot/compressed/head.S
> @@ -141,6 +141,12 @@ start:
>   #endif
>           mov    r7, r1            @ save architecture ID
>           mov    r8, r2            @ save atags pointer
> +#ifdef CONFIG_LITTLE_ENDIAN_LOADER
> +                /*
> +                 * Switch to bigendian mode
> +                 */
> +                setend  be
> +#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
>
>   #ifndef __ARM_ARCH_2__
>           /*
> Index: linux-linaro-tracking/arch/arm/include/asm/setup.h
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/include/asm/setup.h
> +++ linux-linaro-tracking/arch/arm/include/asm/setup.h
> @@ -53,4 +53,8 @@ extern int arm_add_memory(phys_addr_t st
>   extern void early_print(const char *str, ...);
>   extern void dump_machine_table(void);
>
> +#ifdef CONFIG_LITTLE_ENDIAN_LOADER
> +void byteswap_tags(struct tag *t);
> +#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
> +
>   #endif

You could have done

#ifdef CONFIG_LITTLE_ENDIAN_LOADER
void byteswap_tags(struct tag *t);
#else
static inline void byteswap_tags(struct tag *t) { }
#endif /* CONFIG_LITTLE_ENDIAN_LOADER */


> Index: linux-linaro-tracking/arch/arm/kernel/Makefile
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/kernel/Makefile
> +++ linux-linaro-tracking/arch/arm/kernel/Makefile
> @@ -22,6 +22,7 @@ obj-y        := elf.o entry-armv.o entry-commo
>   obj-$(CONFIG_ATAGS)        += atags_parse.o
>   obj-$(CONFIG_ATAGS_PROC)    += atags_proc.o
>   obj-$(CONFIG_DEPRECATED_PARAM_STRUCT) += atags_compat.o
> +obj-$(CONFIG_LITTLE_ENDIAN_LOADER) += atags_byteswap.o
>
>   obj-$(CONFIG_OC_ETM)        += etm.o
>   obj-$(CONFIG_CPU_IDLE)        += cpuidle.o
> Index: linux-linaro-tracking/arch/arm/kernel/atags_byteswap.c
> ===================================================================
> --- /dev/null
> +++ linux-linaro-tracking/arch/arm/kernel/atags_byteswap.c
> @@ -0,0 +1,119 @@
> +#include<linux/slab.h>
> +#include<linux/proc_fs.h>
> +#include<linux/swab.h>
> +#include<asm/setup.h>
> +#include<asm/types.h>
> +#include<asm/page.h>
> +
> +#define byteswap32(x) (x) = __swab32((x))
> +#define byteswap16(x) (x) = __swab16((x))
> +
> +static void __init byteswap_tag_core(struct tag *tag)
> +{
> +  byteswap32(tag->u.core.flags);
> +  byteswap32(tag->u.core.pagesize);
> +  byteswap32(tag->u.core.rootdev);
> +}
> +
> +static void __init byteswap_tag_mem32(struct tag *tag)
> +{
> +  byteswap32(tag->u.mem.size);
> +  byteswap32(tag->u.mem.start);
> +}
> +
> +static void __init byteswap_tag_videotext(struct tag *tag)
> +{
> +  byteswap16(tag->u.videotext.video_page);
> +  byteswap16(tag->u.videotext.video_ega_bx);
> +  byteswap16(tag->u.videotext.video_points);
> +}
> +
> +static void __init byteswap_tag_ramdisk(struct tag *tag)
> +{
> +  byteswap32(tag->u.ramdisk.flags);
> +  byteswap32(tag->u.ramdisk.size);
> +  byteswap32(tag->u.ramdisk.start);
> +}
> +
> +static void __init byteswap_tag_initrd(struct tag *tag)
> +{
> +  byteswap32(tag->u.initrd.start);
> +  byteswap32(tag->u.initrd.size);
> +}
> +
> +static void __init byteswap_tag_serialnr(struct tag *tag)
> +{
> +  byteswap32(tag->u.serialnr.low);
> +  byteswap32(tag->u.serialnr.high);
> +}
> +
> +static void __init byteswap_tag_revision(struct tag *tag)
> +{
> +    byteswap32(tag->u.revision.rev);
> +}
> +
> +static void __init byteswap_tag_videolfb(struct tag *tag)
> +{
> +    byteswap16(tag->u.videolfb.lfb_width);
> +    byteswap16(tag->u.videolfb.lfb_height);
> +    byteswap16(tag->u.videolfb.lfb_depth);
> +    byteswap16(tag->u.videolfb.lfb_linelength);
> +    byteswap32(tag->u.videolfb.lfb_base);
> +    byteswap32(tag->u.videolfb.lfb_size);
> +}
> +
> +static void __init byteswap_tag_acorn(struct tag *tag)
> +{
> +    byteswap32(tag->u.acorn.memc_control_reg);
> +    byteswap32(tag->u.acorn.vram_pages);
> +}
> +
> +static void __init byteswap_tag_memclk(struct tag *tag)
> +{
> +    byteswap32(tag->u.memclk.fmemclk);
> +}
> +
> +void __init byteswap_tags(struct tag *t)
> +{
> +  for (; t->hdr.size; t = tag_next(t)) {
> +    byteswap32(t->hdr.size);
> +    byteswap32(t->hdr.tag);
> +    switch(t->hdr.tag) {
> +    case ATAG_CORE:
> +      byteswap_tag_core(t);
> +      break;
> +    case ATAG_MEM:
> +      byteswap_tag_mem32(t);
> +      break;
> +    case ATAG_VIDEOTEXT:
> +      byteswap_tag_videotext(t);
> +      break;
> +    case ATAG_RAMDISK:
> +      byteswap_tag_ramdisk(t);
> +      break;
> +    case ATAG_INITRD2:
> +      byteswap_tag_initrd(t);
> +      break;
> +    case ATAG_SERIAL:
> +      byteswap_tag_serialnr(t);
> +      break;
> +    case ATAG_REVISION:
> +      byteswap_tag_revision(t);
> +      break;
> +    case ATAG_VIDEOLFB:
> +      byteswap_tag_videolfb(t);
> +      break;
> +    case ATAG_CMDLINE:
> +      break;
> +    case ATAG_ACORN:
> +      byteswap_tag_acorn(t);
> +      break;
> +    case ATAG_MEMCLK:
> +      byteswap_tag_memclk(t);
> +      break;
> +    default:
> +      /* Need to complain? */
> +      break;
> +    }
> +  }
> +}

I think swapping on read is a better idea, as it leaves
these in their original format.

PS, looks like you either have a formatting issue with
your email client or your code. Did this pass checkpatch?

> Index: linux-linaro-tracking/arch/arm/kernel/head-common.S
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/kernel/head-common.S
> +++ linux-linaro-tracking/arch/arm/kernel/head-common.S
> @@ -48,6 +48,9 @@ __vet_atags:
>       bne    1f
>
>       ldr    r5, [r2, #0]
> +#ifdef CONFIG_LITTLE_ENDIAN_LOADER
> +        rev     r5, r5
> +#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
>   #ifdef CONFIG_OF_FLATTREE
>       ldr    r6, =OF_DT_MAGIC        @ is it a DTB?
>       cmp    r5, r6
> @@ -57,6 +60,9 @@ __vet_atags:
>       cmpne    r5, #ATAG_CORE_SIZE_EMPTY
>       bne    1f
>       ldr    r5, [r2, #4]
> +#ifdef CONFIG_LITTLE_ENDIAN_LOADER
> +        rev     r5, r5
> +#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
>       ldr    r6, =ATAG_CORE
>       cmp    r5, r6
>       bne    1f

bit-untidy. also, does OF_DT_MAGIC get changed by the
endian-ness, or is that somewhere else in the head code?

> Index: linux-linaro-tracking/arch/arm/kernel/module.c
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/kernel/module.c
> +++ linux-linaro-tracking/arch/arm/kernel/module.c
> @@ -45,6 +45,65 @@ void *module_alloc(unsigned long size)
>   }
>   #endif
>
> +/*
> + * For relocations in exectuable sections if we configured with
> + * CONFIG_CPU_ENDIAN_BE8 we assume that code is in little endian byteswap
> + * form already and we need to byteswap value when we read and when we
> + * write. If relocaton R_ARM_ABS32 type we assume that it is relocation for
> + * data piece and we do not perform byteswaps when such relocation applied.
> + * This herustic based approach may break in future.
> + *
> + * It seems that more correct way to handle be8 in kernel module is
> + * to build module without --be8 option, but perform instruction byteswap
> + * when module sections are loaded, after all relocation are applied.
> + * In order to do such byteswap we need to read all mappings symbols ($a,
> + * $d, $t), sort them, and apply byteswaps for $a and $t entries.
> + */
> +static inline u32 read_section_u32(Elf32_Shdr *dstsec, unsigned long loc)
> +{
> +       u32 retval = *(u32 *)loc;
> +
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +        if (dstsec->sh_flags&  SHF_EXECINSTR) {
> +                retval = __swab32(retval);
> +        }
> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
> +        return retval;
> +}
> +
> +static inline void write_section_u32(Elf32_Shdr *dstsec, unsigned
> long loc, u32 value)
> +{
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +        if (dstsec->sh_flags&  SHF_EXECINSTR) {
> +                value = __swab32(value);
> +        }
> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
> +        *(u32 *) loc = value;
> +}
> +
> +#ifdef CONFIG_THUMB2_KERNEL
> +static inline u16 read_section_u16(Elf32_Shdr *dstsec, unsigned long loc)
> +{
> +        u16 retval = *(u16 *) loc;
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +        if (dstsec->sh_flags&  SHF_EXECINSTR) {
> +                retval = __swab16(retval);
> +        }
> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
> +        return retval;
> +}
> +
> +static inline void write_section_u16(Elf32_Shdr *dstsec, unsigned
> long loc, u16 value)
> +{
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +        if (dstsec->sh_flags&  SHF_EXECINSTR) {
> +                value = __swab16(value);
> +        }
> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
> +        *(u16 *) loc = value;
> +}
> +#endif /* CONFIG_THUMB2_KERNEL */
> +
>   int
>   apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
>              unsigned int relindex, struct module *module)
> @@ -60,6 +119,7 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
>           Elf32_Sym *sym;
>           const char *symname;
>           s32 offset;
> +                u32 loc_u32;
>   #ifdef CONFIG_THUMB2_KERNEL
>           u32 upper, lower, sign, j1, j2;
>   #endif
> @@ -95,7 +155,8 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
>           case R_ARM_PC24:
>           case R_ARM_CALL:
>           case R_ARM_JUMP24:
> -            offset = (*(u32 *)loc&  0x00ffffff)<<  2;
> +                        loc_u32 = read_section_u32(dstsec, loc);
> +            offset = (loc_u32&  0x00ffffff)<<  2;
>               if (offset&  0x02000000)
>                   offset -= 0x04000000;
>
> @@ -112,27 +173,33 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
>
>               offset>>= 2;
>
> -            *(u32 *)loc&= 0xff000000;
> -            *(u32 *)loc |= offset&  0x00ffffff;
> +            loc_u32&= 0xff000000;
> +            loc_u32 |= offset&  0x00ffffff;
> +                        write_section_u32(dstsec, loc, loc_u32);
>               break;
>
> -           case R_ARM_V4BX:
> +                case R_ARM_V4BX:
> +                        loc_u32 = read_section_u32(dstsec, loc);
>                  /* Preserve Rm and the condition code. Alter
>               * other bits to re-code instruction as
>               * MOV PC,Rm.
>               */
> -               *(u32 *)loc&= 0xf000000f;
> -               *(u32 *)loc |= 0x01a0f000;
> +               loc_u32&= 0xf000000f;
> +               loc_u32 |= 0x01a0f000;
> +                       write_section_u32(dstsec, loc, loc_u32);
>                  break;
>
>           case R_ARM_PREL31:
> -            offset = *(u32 *)loc + sym->st_value - loc;
> -            *(u32 *)loc = offset&  0x7fffffff;
> +                        loc_u32 = read_section_u32(dstsec, loc);
> +            offset = loc_u32 + sym->st_value - loc;
> +            loc_u32 = offset&  0x7fffffff;
> +                        write_section_u32(dstsec, loc, loc_u32);
>               break;
>
>           case R_ARM_MOVW_ABS_NC:
>           case R_ARM_MOVT_ABS:
> -            offset = *(u32 *)loc;
> +                        loc_u32 = read_section_u32(dstsec, loc);
> +            offset = loc_u32;
>               offset = ((offset&  0xf0000)>>  4) | (offset&  0xfff);
>               offset = (offset ^ 0x8000) - 0x8000;
>
> @@ -140,16 +207,17 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
>               if (ELF32_R_TYPE(rel->r_info) == R_ARM_MOVT_ABS)
>                   offset>>= 16;
>
> -            *(u32 *)loc&= 0xfff0f000;
> -            *(u32 *)loc |= ((offset&  0xf000)<<  4) |
> -                    (offset&  0x0fff);
> +            loc_u32&= 0xfff0f000;
> +            loc_u32 |= ((offset&  0xf000)<<  4) |
> +                                   (offset&  0x0fff);
> +                        write_section_u32(dstsec, loc, loc_u32);
>               break;
>
>   #ifdef CONFIG_THUMB2_KERNEL
>           case R_ARM_THM_CALL:
>           case R_ARM_THM_JUMP24:
> -            upper = *(u16 *)loc;
> -            lower = *(u16 *)(loc + 2);
> +                        upper = read_section_u16(dstsec, loc);
> +            lower = read_section_u16(dstsec, loc + 2);
>
>               /*
>                * 25 bit signed address range (Thumb-2 BL and B.W
> @@ -198,17 +266,19 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
>               sign = (offset>>  24)&  1;
>               j1 = sign ^ (~(offset>>  23)&  1);
>               j2 = sign ^ (~(offset>>  22)&  1);
> -            *(u16 *)loc = (u16)((upper&  0xf800) | (sign<<  10) |
> -                        ((offset>>  12)&  0x03ff));
> -            *(u16 *)(loc + 2) = (u16)((lower&  0xd000) |
> -                          (j1<<  13) | (j2<<  11) |
> -                          ((offset>>  1)&  0x07ff));
> +                        write_section_u16(dstsec, loc,
> +                                          (u16)((upper&  0xf800) |
> (sign<<  10) |
> +                                                ((offset>>  12)&  0x03ff)));
> +                        write_section_u16(dstsec, loc + 2,
> +                                          (u16)((lower&  0xd000) |
> +                                                (j1<<  13) | (j2<<  11) |
> +                                                ((offset>>  1)&  0x07ff)));
>               break;
>
>           case R_ARM_THM_MOVW_ABS_NC:
>           case R_ARM_THM_MOVT_ABS:
> -            upper = *(u16 *)loc;
> -            lower = *(u16 *)(loc + 2);
> +                        upper = read_section_u16(dstsec, loc);
> +            lower = read_section_u16(dstsec, loc + 2);
>
>               /*
>                * MOVT/MOVW instructions encoding in Thumb-2:
> @@ -229,12 +299,14 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
>               if (ELF32_R_TYPE(rel->r_info) == R_ARM_THM_MOVT_ABS)
>                   offset>>= 16;
>
> -            *(u16 *)loc = (u16)((upper&  0xfbf0) |
> -                        ((offset&  0xf000)>>  12) |
> -                        ((offset&  0x0800)>>  1));
> -            *(u16 *)(loc + 2) = (u16)((lower&  0x8f00) |
> -                          ((offset&  0x0700)<<  4) |
> -                          (offset&  0x00ff));
> +                        write_section_u16(dstsec, loc,
> +                                          (u16)((upper&  0xfbf0) |
> +                                                ((offset&  0xf000)>>  12) |
> +                                                ((offset&  0x0800)>>  1)));
> +                        write_section_u16(dstsec, loc + 2,
> +                                          (u16)((lower&  0x8f00) |
> +                                                ((offset&  0x0700)<<  4) |
> +                                                (offset&  0x00ff)));
>               break;
>   #endif
>

I'm still not sure about this, I think the use of <asm/opcodes.h>
is better here. Not sure if there's much point in checking the flags
on the sections as I think the relocations pretty much define which
endian they will be in.

> Index: linux-linaro-tracking/arch/arm/mm/Kconfig
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/mm/Kconfig
> +++ linux-linaro-tracking/arch/arm/mm/Kconfig
> @@ -695,6 +695,15 @@ config CPU_ENDIAN_BE32
>       help
>         Support for the BE-32 (big-endian) mode on pre-ARMv6 processors.
>
> +config LITTLE_ENDIAN_LOADER
> +        bool
> +        depends on CPU_BIG_ENDIAN
> +        default y
> +        help
> +          If Linux should operate in big-endian mode, but bootloader
> (i.e u-boot)
> +          is still in little endian mode and passes boot information in little
> +          endian form set this flag
> +
>   config CPU_HIGH_VECTOR
>       depends on !MMU&&  CPU_CP15&&  !CPU_ARM740T
>       bool "Select the High exception vector"


> Index: linux-linaro-tracking/arch/arm/mm/alignment.c
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/mm/alignment.c
> +++ linux-linaro-tracking/arch/arm/mm/alignment.c
> @@ -792,6 +792,10 @@ do_alignment(unsigned long addr, unsigne
>
>       regs->ARM_pc += isize;
>
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +        instr = __swab32(instr); /* little endian instruction */
> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
> +
>       switch (CODING_BITS(instr)) {
>       case 0x00000000:    /* 3.13.4 load/store instruction extensions */
>           if (LDSTHD_I_BIT(instr))

See comments on <asm/opcodes.h>

> Index: linux-linaro-tracking/arch/arm/kernel/head.S
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/kernel/head.S
> +++ linux-linaro-tracking/arch/arm/kernel/head.S
> @@ -89,6 +89,12 @@ ENTRY(stext)
>       @ ensure svc mode and all interrupts masked
>       safe_svcmode_maskall r9
>
> +#ifdef CONFIG_LITTLE_ENDIAN_LOADER
> +    /*
> +    * Switch to bigendian mode
> +    */
> +    setend    be
> +#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
>       mrc    p15, 0, r9, c0, c0        @ get processor id
>       bl    __lookup_processor_type        @ r5=procinfo r9=cpuid
>       movs    r10, r5                @ invalid processor (r5=0)?
> @@ -356,6 +362,12 @@ ENTRY(secondary_startup)
>   #endif
>       safe_svcmode_maskall r9
>
> +#ifdef CONFIG_LITTLE_ENDIAN_LOADER
> +    /*
> +    * Switch to bigendian mode
> +    */
> +    setend    be
> +#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
>       mrc    p15, 0, r9, c0, c0        @ get processor id
>       bl    __lookup_processor_type
>       movs    r10, r5                @ invalid processor?
> @@ -427,6 +439,9 @@ __enable_mmu:
>   #ifdef CONFIG_CPU_ICACHE_DISABLE
>       bic    r0, r0, #CR_I
>   #endif
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +    orr    r0, r0, #CR_EE    @ big-endian page tables
> +#endif
>   #ifdef CONFIG_ARM_LPAE
>       mov    r5, #0
>       mcrr    p15, 0, r4, r5, c2        @ load TTBR0
> @@ -592,8 +607,14 @@ __fixup_a_pv_table:
>       b    2f
>   1:    add     r7, r3
>       ldrh    ip, [r7, #2]
> +#ifdef __ARMEB__
> +        rev     ip, ip   @ byteswap instruction
> +#endif /* __ARMEB__ */
>       and    ip, 0x8f00
>       orr    ip, r6    @ mask in offset bits 31-24
> +#ifdef __ARMEB__
> +        rev     ip, ip   @ byteswap instruction
> +#endif /* __ARMEB__ */
>       strh    ip, [r7, #2]
>   2:    cmp    r4, r5
>       ldrcc    r7, [r4], #4    @ use branch for delay slot
> @@ -602,8 +623,14 @@ __fixup_a_pv_table:
>   #else
>       b    2f
>   1:    ldr    ip, [r7, r3]
> +#ifdef __ARMEB__
> +        rev     ip, ip   @ byteswap instruction
> +#endif /* __ARMEB__ */
>       bic    ip, ip, #0x000000ff
>       orr    ip, ip, r6    @ mask in offset bits 31-24
> +#ifdef __ARMEB__
> +        rev     ip, ip   @ byteswap instruction
> +#endif /* __ARMEB__ */
>       str    ip, [r7, r3]
>   2:    cmp    r4, r5
>       ldrcc    r7, [r4], #4    @ use branch for delay slot

Yeah, prefer my macros for doing this.


> Index: linux-linaro-tracking/arch/arm/kernel/kprobes.c
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/kernel/kprobes.c
> +++ linux-linaro-tracking/arch/arm/kernel/kprobes.c
> @@ -66,14 +66,24 @@ int __kprobes arch_prepare_kprobe(struct
>       if (is_wide_instruction(insn)) {
>           insn<<= 16;
>           insn |= ((u16 *)addr)[1];
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +                insn = __swab32(insn); /* little endian instruction */
> +#endif
>           decode_insn = thumb32_kprobe_decode_insn;
> -    } else
> -        decode_insn = thumb16_kprobe_decode_insn;
> +    } else {
> +                decode_insn = thumb16_kprobe_decode_insn;
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +                insn = __swab16(insn); /* little endian instruction */
> +#endif
> +        }
>   #else /* !CONFIG_THUMB2_KERNEL */
>       thumb = false;
>       if (addr&  0x3)
>           return -EINVAL;
>       insn = *p->addr;
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +        insn = __swab32(insn); /* little endian instruction */
> +#endif
>       decode_insn = arm_kprobe_decode_insn;
>   #endif
>
> @@ -89,7 +99,11 @@ int __kprobes arch_prepare_kprobe(struct
>           if (!p->ainsn.insn)
>               return -ENOMEM;
>           for (is = 0; is<  MAX_INSN_SIZE; ++is)
> +#ifndef CONFIG_CPU_ENDIAN_BE8
>               p->ainsn.insn[is] = tmp_insn[is];
> +#else
> +                        p->ainsn.insn[is] = __swab32(tmp_insn[is]);
> /* little endian instruction */
> +#endif
>           flush_insns(p->ainsn.insn,
>                   sizeof(p->ainsn.insn[0]) * MAX_INSN_SIZE);
>           p->ainsn.insn_fn = (kprobe_insn_fn_t *)
> @@ -113,10 +127,17 @@ void __kprobes arch_arm_kprobe(struct kp
>           /* Remove any Thumb flag */
>           addr = (void *)((uintptr_t)p->addr&  ~1);
>
> -        if (is_wide_instruction(p->opcode))
> +        if (is_wide_instruction(p->opcode)) {
>               brkp = KPROBE_THUMB32_BREAKPOINT_INSTRUCTION;
> -        else
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +                brkp = __swab32(brkp);
> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
> +        } else {
>               brkp = KPROBE_THUMB16_BREAKPOINT_INSTRUCTION;
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +                brkp = __swab16(brkp);
> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
> +            }
>       } else {
>           kprobe_opcode_t insn = p->opcode;
>
> @@ -127,6 +148,10 @@ void __kprobes arch_arm_kprobe(struct kp
>               brkp |= 0xe0000000;  /* Unconditional instruction */
>           else
>               brkp |= insn&  0xf0000000;  /* Copy condition from insn */
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +        brkp = __swab32(brkp);
> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
> +
>       }
>
>       patch_text(addr, brkp);
> @@ -144,8 +169,12 @@ int __kprobes __arch_disarm_kprobe(void
>   {
>       struct kprobe *kp = p;
>       void *addr = (void *)((uintptr_t)kp->addr&  ~1);
> +    kprobe_opcode_t insn = kp->opcode;
>
> -    __patch_text(addr, kp->opcode);
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +        insn = __swab32(insn); /* little endian instruction */
> +#endif
> +    __patch_text(addr, insn);
>
>       return 0;
>

__patch_text already does swapping, so a little concerned that it
is being done twice in some places.


> Index: linux-linaro-tracking/arch/arm/kernel/traps.c
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/kernel/traps.c
> +++ linux-linaro-tracking/arch/arm/kernel/traps.c
> @@ -426,6 +426,10 @@ asmlinkage void __exception do_undefinst
>           goto die_sig;
>       }
>
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +        instr = __swab32(instr); /* little endian instruction */
> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
> +
>       if (call_undef_hook(regs, instr) == 0)
>           return;

already fixed.

> Index: linux-linaro-tracking/arch/arm/kernel/ftrace.c
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/kernel/ftrace.c
> +++ linux-linaro-tracking/arch/arm/kernel/ftrace.c
> @@ -100,10 +100,18 @@ static int ftrace_modify_code(unsigned l
>           if (probe_kernel_read(&replaced, (void *)pc, MCOUNT_INSN_SIZE))
>               return -EFAULT;
>
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +        replaced = __swab32(replaced); /* little endian instruction */
> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
> +
>           if (replaced != old)
>               return -EINVAL;
>       }
>
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +        new = __swab32(new); /* little endian instruction */
> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
> +
>       if (probe_kernel_write((void *)pc,&new, MCOUNT_INSN_SIZE))
>           return -EPERM;

Please see <asm/opcodes.h> for dealing with the op-codes like this.

> Index: linux-linaro-tracking/arch/arm/kernel/atags_parse.c
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/kernel/atags_parse.c
> +++ linux-linaro-tracking/arch/arm/kernel/atags_parse.c
> @@ -216,6 +216,10 @@ struct machine_desc * __init setup_machi
>       if (tags->hdr.tag != ATAG_CORE)
>           convert_to_tag_list(tags);
>   #endif
> +#ifdef CONFIG_LITTLE_ENDIAN_LOADER
> +    byteswap_tags(tags);
> +#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
> +
>       if (tags->hdr.tag != ATAG_CORE) {
>           early_print("Warning: Neither atags nor dtb found\n");
>           tags = (struct tag *)&default_tags;
> Index: linux-linaro-tracking/arch/arm/kernel/sleep.S

I really don't like this way, it makes it difficult to deal with
if you export this data to user-space to then do things like md5sum
it. Also, if you're going to kexec() a new kernel, would you have
to re-swap it back before this?

> Index: linux-linaro-tracking/arch/arm/include/asm/atomic.h
> ===================================================================
> --- linux-linaro-tracking.orig/arch/arm/include/asm/atomic.h
> +++ linux-linaro-tracking/arch/arm/include/asm/atomic.h
> @@ -301,8 +301,13 @@ static inline void atomic64_add(u64 i, a
>
>       __asm__ __volatile__("@ atomic64_add\n"
>   "1:    ldrexd    %0, %H0, [%3]\n"
> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>   "    adds    %0, %0, %4\n"
>   "    adc    %H0, %H0, %H4\n"
> +#else
> +"    adds    %H0, %H0, %H4\n"
> +"    adc    %0, %0, %4\n"
> +#endif
>   "    strexd    %1, %0, %H0, [%3]\n"
>   "    teq    %1, #0\n"
>   "    bne    1b"
> @@ -320,8 +325,13 @@ static inline u64 atomic64_add_return(u6
>
>       __asm__ __volatile__("@ atomic64_add_return\n"
>   "1:    ldrexd    %0, %H0, [%3]\n"
> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>   "    adds    %0, %0, %4\n"
>   "    adc    %H0, %H0, %H4\n"
> +#else
> +"    adds    %H0, %H0, %H4\n"
> +"    adc    %0, %0, %4\n"
> +#endif
>   "    strexd    %1, %0, %H0, [%3]\n"
>   "    teq    %1, #0\n"
>   "    bne    1b"
> @@ -341,8 +351,13 @@ static inline void atomic64_sub(u64 i, a
>
>       __asm__ __volatile__("@ atomic64_sub\n"
>   "1:    ldrexd    %0, %H0, [%3]\n"
> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>   "    subs    %0, %0, %4\n"
>   "    sbc    %H0, %H0, %H4\n"
> +#else
> +"    subs    %H0, %H0, %H4\n"
> +"    sbc    %0, %0, %4\n"
> +#endif
>   "    strexd    %1, %0, %H0, [%3]\n"
>   "    teq    %1, #0\n"
>   "    bne    1b"
> @@ -360,8 +375,13 @@ static inline u64 atomic64_sub_return(u6
>
>       __asm__ __volatile__("@ atomic64_sub_return\n"
>   "1:    ldrexd    %0, %H0, [%3]\n"
> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>   "    subs    %0, %0, %4\n"
>   "    sbc    %H0, %H0, %H4\n"
> +#else
> +"    subs    %H0, %H0, %H4\n"
> +"    sbc    %0, %0, %4\n"
> +#endif
>   "    strexd    %1, %0, %H0, [%3]\n"
>   "    teq    %1, #0\n"
>   "    bne    1b"
> @@ -428,9 +448,15 @@ static inline u64 atomic64_dec_if_positi
>
>       __asm__ __volatile__("@ atomic64_dec_if_positive\n"
>   "1:    ldrexd    %0, %H0, [%3]\n"
> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>   "    subs    %0, %0, #1\n"
>   "    sbc    %H0, %H0, #0\n"
>   "    teq    %H0, #0\n"
> +#else
> +"    subs    %H0, %H0, #1\n"
> +"    sbc    %0, %0, #0\n"
> +"    teq    %0, #0\n"
> +#endif
>   "    bmi    2f\n"
>   "    strexd    %1, %0, %H0, [%3]\n"
>   "    teq    %1, #0\n"
> @@ -459,8 +485,13 @@ static inline int atomic64_add_unless(at
>   "    teqeq    %H0, %H5\n"
>   "    moveq    %1, #0\n"
>   "    beq    2f\n"
> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>   "    adds    %0, %0, %6\n"
>   "    adc    %H0, %H0, %H6\n"
> +#else
> +"    adds    %H0, %H0, %H6\n"
> +"    adc    %0, %0, %6\n"
> +#endif
>   "    strexd    %2, %0, %H0, [%4]\n"
>   "    teq    %2, #0\n"
>   "    bne    1b\n"

I still believe that you're doing the wrong thing here
and that these can be left well enough alone. Please give
a concrete piece of code that can show they're actually
doing the wrong thing.



-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From stern at rowland.harvard.edu  Tue Jul 23 14:39:12 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 23 Jul 2013 14:39:12 -0400 (EDT)
Subject: [PATCH 2/6] USB: OHCI: make ohci-omap a separate driver
In-Reply-To: <1374484770-24531-3-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <Pine.LNX.4.44L0.1307231436010.1304-100000@iolanthe.rowland.org>

On Mon, 22 Jul 2013, Manjunath Goudar wrote:

> Separate the  TI OHCI OMAP1/2 host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.11.
> 
> Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Greg KH <greg at kroah.com>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: linux-usb at vger.kernel.org
> 
> V2:
>  -omap_ohci_clock_power(0) called in usb_hcd_omap_remove().
>  -Removed ohci_setup() call from usb_hcd_omap_probe().
>  -host_enabled and host_initialized variables aren't used for anything
>   thats what removed.
> 
> V3:
>  -rewritten if (config->otg || config->rwc) block statements into
>   two separate 'if blocks' to handle below scenarios
>   1. config->otg set scenario.
>   2. if any of these (config->otg, config->rwc) are set, this
>      scenario should be handled only after ohci_setup()
> 
> V4:
>  -usb_remove_hcd() function is required a valid clock that is what
>   omap_ohci_clock_power(0) is called after hcd shutdown.

> @@ -369,11 +367,6 @@ static int usb_hcd_omap_probe (const struct hc_driver *driver,
>  	if (retval)
>  		goto err3;
>  
> -	host_initialized = 1;
> -
> -	if (!host_enabled)
> -		omap_ohci_clock_power(0);
> -
>  	return 0;
>  err3:
>  	iounmap(hcd->regs);

I suspect there's a mistake here, and the omap_ohci_clock_power() call 
perhaps should be moved after the "err3:" label.  But that mistake (if 
it is a mistake) was present in the original code, and this patch 
shouldn't change it.

Acked-by: Alan Stern <stern at rowland.harvard.edu>



From stern at rowland.harvard.edu  Tue Jul 23 14:43:12 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 23 Jul 2013 14:43:12 -0400 (EDT)
Subject: [PATCH 3/6] USB: OHCI: make ohci-omap3 a separate driver
In-Reply-To: <1374484770-24531-4-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <Pine.LNX.4.44L0.1307231442040.1304-100000@iolanthe.rowland.org>

On Mon, 22 Jul 2013, Manjunath Goudar wrote:

> Separate the  TI OHCI OMAP3 host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.11.
> 
> Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
> Cc: Anand Gadiyar <gadiyar at ti.com>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Greg KH <greg at kroah.com>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: linux-usb at vger.kernel.org
> 
> V2:
>  -ohci_setup() removed because it is called in .reset member
>   of the ohci_hc_driver structure.
>  -The improper multi-line commenting style written in proper way.
>   ('*' characters aligned in vertically).
> 
> V3:
>  -RemoteWakeupConnected setting has been removed.
> 
> V4:
>  -V3 modification revert back, only ohci->regs setting write()
>   function has been removed because ohci->regs doesn't get set until
>   usb_add_hcd.

Acked-by: Alan Stern <stern at rowland.harvard.edu>



From stern at rowland.harvard.edu  Tue Jul 23 14:45:48 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 23 Jul 2013 14:45:48 -0400 (EDT)
Subject: [PATCH 5/6] USB: OHCI: make ohci-at91 a separate driver
In-Reply-To: <1374484770-24531-6-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <Pine.LNX.4.44L0.1307231445230.1304-100000@iolanthe.rowland.org>

On Mon, 22 Jul 2013, Manjunath Goudar wrote:

> Separate the  TI OHCI Atmel host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.12.
> 
> Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Greg KH <greg at kroah.com>
> Cc: linux-usb at vger.kernel.org
> 
> V2:
>  -Set non-standard fields in ohci_at91_hc_driver manually, rather than
>   relying on an expanded struct ohci_driver_overrides.
>  -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
>   relying on ohci_hub_control and hub_status_data being exported.
>  -ohci_setup() has been removed because it is called in .reset member
>   of the ohci_hc_driver structure.
> 
> V3:
>  -The ohci_restart() function is not required in  current scenario,
>   only discarding connection state of integrated transceivers is sufficient,
>   for this directly handling ohci->hc_control.
> 
> V4:
>  - Removed extra space after "tristate".
>  - Removed extra space between function name  and '(' characters.
>  - MODULE_ALIAS line moved to last statement of ohci-at91 file.

Acked-by: Alan Stern <stern at rowland.harvard.edu>



From matt.porter at linaro.org  Tue Jul 23 14:49:08 2013
From: matt.porter at linaro.org (Matt Porter)
Date: Tue, 23 Jul 2013 14:49:08 -0400
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <2043662.BcW19XTTMG@lenovo>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
Message-ID: <20130723184907.GA6811@ohporter.com>

On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote:
> Hello,
> 
> Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :
> > > +	compatible = "brcm,bcm5301x";
> > 
> > Ok, this was nagging at me before I went on my very long vacation. I see
> > the "brcm" vendor prefix as a real consistency problem. I noticed on the
> > bcm281xx/kona family, we have been using "bcm" which is not logged in
> > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
> > already established use of "brcm" before any of the bcm281xx support
> > came in. Ideally, the vendor prefix should change to "bcm" since every
> > reference in the family names is BCM. However, if others want the least
> > amount of churn in making this consistent, we might have to go with
> > "brcm" across the board.
> 
> I would like to keep "brcm" here because that is what has been defined as a 
> vendor prefix, and is used beyond the scope of the ARM Linux kernel support 
> even within Broadcom. Maybe it was an oversight, or rather a mistake to let 

[Update: I thought some more about this and investigated why Broadcom started
 using "bcm" and changed my mind]

Can you provide a cite? I can tell you that within Broadcom they have
been moving to get rid of it. That is why you see all this Broadcom
originated code using "bcm" because it actually matches their part
number prefix. As further evidence of the preference for "bcm", feel free to
look through the entire public catalog of parts at
http://www.broadcom.com/products/ and note that they all have BCM as the part
prefix...this carries over into all driver references to the parts as well
including everything in the wireless world.

> the bcm281x/kona family support code be merged and use "bcm" there, without 
> registering it. Besides, a simple rule of number here wins:
> 
> git grep "brcm," * | wc -l
> 63
> git grep "bcm," * | wc -l
> 25
> 
> (as of Linux 3.11-rc1)
> 
> So consistency we should get the bcm281x/kona DT bindings to rename their 
> vendor prefix as well.

I believe getting this "right" is far more important than the difference
in churn of a mere 38 instances of use of brcm. "Right" is two things:
1) it needs to be consistent 2) it should be what makes sense.

-Matt


From stern at rowland.harvard.edu  Tue Jul 23 14:53:28 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 23 Jul 2013 14:53:28 -0400 (EDT)
Subject: [PATCH V2] USB: EHCI: make ehci-w90X900 a separate driver
In-Reply-To: <1374488380-26428-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <Pine.LNX.4.44L0.1307231450340.1304-100000@iolanthe.rowland.org>

On Mon, 22 Jul 2013, Manjunath Goudar wrote:

> Separate the W90X900(W90P910) on-chip host controller driver from
> ehci-hcd host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> however, note that other changes are still needed before W90X900(W90P910)
> can be booted with a multi-platform kernel
> 
> and an ehci driver that only works on one of them.
> 
> With the infrastructure added by Alan Stern in patch 3e0232039
> "USB: EHCI: prepare to make ehci-hcd a library module", we can
> avoid this problem by turning a bus glue into a separate
> module, as we do here for the w90X900 bus glue.
> 
> Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Cc: Greg KH <greg at kroah.com>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Wan ZongShun <mcuos.com at gmail.com>
> Cc: linux-usb at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> 
> V2:
>  -Arranged  #include's in alphabetical order.
>  -Replaced "w90p910" by "w90x900" because it is supports
>   all series of w90x900.

> +MODULE_DESCRIPTION(DRIVER_DESC);
>  MODULE_AUTHOR("Wan ZongShun <mcuos.com at gmail.com>");
> -MODULE_DESCRIPTION("w90p910 usb ehci driver!");
> -MODULE_LICENSE("GPL");
>  MODULE_ALIAS("platform:w90p910-ehci");
> +MODULE_LICENSE("GPL v2");

Are you sure the license is supposed to be changed?  Is that okay with 
Wan ZongShun?

Alan Stern



From f.fainelli at gmail.com  Tue Jul 23 14:56:26 2013
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 23 Jul 2013 19:56:26 +0100
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with
 ARM CPU
In-Reply-To: <20130723184907.GA6811@ohporter.com>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130723184907.GA6811@ohporter.com>
Message-ID: <CAGVrzcbA72AYu6J3JXBirQQeTiDH9cJThdBdH=Q=gJtOnqz-AA@mail.gmail.com>

2013/7/23 Matt Porter <matt.porter at linaro.org>:
> On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote:
>> Hello,
>>
>> Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :
>> > > + compatible = "brcm,bcm5301x";
>> >
>> > Ok, this was nagging at me before I went on my very long vacation. I see
>> > the "brcm" vendor prefix as a real consistency problem. I noticed on the
>> > bcm281xx/kona family, we have been using "bcm" which is not logged in
>> > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
>> > already established use of "brcm" before any of the bcm281xx support
>> > came in. Ideally, the vendor prefix should change to "bcm" since every
>> > reference in the family names is BCM. However, if others want the least
>> > amount of churn in making this consistent, we might have to go with
>> > "brcm" across the board.
>>
>> I would like to keep "brcm" here because that is what has been defined as a
>> vendor prefix, and is used beyond the scope of the ARM Linux kernel support
>> even within Broadcom. Maybe it was an oversight, or rather a mistake to let
>
> [Update: I thought some more about this and investigated why Broadcom started
>  using "bcm" and changed my mind]
>
> Can you provide a cite?

Well, I can tell you that this is what my group is using for its
vendor prefix in DT because this is the one that was allocated in
vendor-prefixes.txt. This is also what the upstream BCM63xx DSL SoC is
using even though that port is still WIP, so could be subject to
changing.

> I can tell you that within Broadcom they have
> been moving to get rid of it. That is why you see all this Broadcom
> originated code using "bcm" because it actually matches their part
> number prefix. As further evidence of the preference for "bcm", feel free to
> look through the entire public catalog of parts at
> http://www.broadcom.com/products/ and note that they all have BCM as the part
> prefix...this carries over into all driver references to the parts as well
> including everything in the wireless world.

If you want to add more confusion, because there is,
drivers/staging/bcm which stands for Beceem has been later acquired by
Broadcom, eventually turning this 3 letter word into something
"consistent" from a Broadcom point of view. As far as I am concerned,
I would just stick with the allocated vendor prefix and replace "bcm"
with "brcm" because the allocated one is the authoritative one.

>
>> the bcm281x/kona family support code be merged and use "bcm" there, without
>> registering it. Besides, a simple rule of number here wins:
>>
>> git grep "brcm," * | wc -l
>> 63
>> git grep "bcm," * | wc -l
>> 25
>>
>> (as of Linux 3.11-rc1)
>>
>> So consistency we should get the bcm281x/kona DT bindings to rename their
>> vendor prefix as well.
>
> I believe getting this "right" is far more important than the difference
> in churn of a mere 38 instances of use of brcm. "Right" is two things:
> 1) it needs to be consistent 2) it should be what makes sense.

I agree, which is the reason why I would stick with the vendor prefix
and end the story there.
--
Florian


From matt.porter at linaro.org  Tue Jul 23 14:57:34 2013
From: matt.porter at linaro.org (Matt Porter)
Date: Tue, 23 Jul 2013 14:57:34 -0400
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <20130719020611.GA4941@glitch>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130719020611.GA4941@glitch>
Message-ID: <20130723185733.GB6811@ohporter.com>

On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
> On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote:
> > Hello,
> > 
> > Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :
> > > > +	compatible = "brcm,bcm5301x";
> > > 
> > > Ok, this was nagging at me before I went on my very long vacation. I see
> > > the "brcm" vendor prefix as a real consistency problem. I noticed on the
> > > bcm281xx/kona family, we have been using "bcm" which is not logged in
> > > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
> > > already established use of "brcm" before any of the bcm281xx support
> > > came in. Ideally, the vendor prefix should change to "bcm" since every
> > > reference in the family names is BCM. However, if others want the least
> > > amount of churn in making this consistent, we might have to go with
> > > "brcm" across the board.
> > 
> > I would like to keep "brcm" here because that is what has been defined as a 
> > vendor prefix, and is used beyond the scope of the ARM Linux kernel support 
> > even within Broadcom. Maybe it was an oversight, or rather a mistake to let 
> 
> brcm is the stock ticker. As far as I can search, this is the convention
> for the vendor prefixes.

No, correlation does not equal causation. The fact that some vendor
prefixes in DT match the stock symbol is by chance of 3-4 character name
being the same...nothing more.

It's pretty easy to see that the "ti" vendor prefix has no relation at
all to their TXN symbol so that blows that convention out of the water.
Rather, the prefix is based on somebody's notion of how that vendor's
part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
never TXN OMAP. :)

For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.

> I'm theb not that surprised that it's common within broadcom ;)

It's no longer common as mentioned in my other post.

-Matt


From f.fainelli at gmail.com  Tue Jul 23 15:05:28 2013
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 23 Jul 2013 20:05:28 +0100
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC with
 ARM CPU
In-Reply-To: <20130723185733.GB6811@ohporter.com>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130719020611.GA4941@glitch> <20130723185733.GB6811@ohporter.com>
Message-ID: <CAGVrzcYnoN9NnJGvubS7=bVJDk37xSt4BimtvDWghe7OHEWALQ@mail.gmail.com>

2013/7/23 Matt Porter <matt.porter at linaro.org>:
> On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
>> On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote:
>> > Hello,
>> >
>> > Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :
>> > > > +       compatible = "brcm,bcm5301x";
>> > >
>> > > Ok, this was nagging at me before I went on my very long vacation. I see
>> > > the "brcm" vendor prefix as a real consistency problem. I noticed on the
>> > > bcm281xx/kona family, we have been using "bcm" which is not logged in
>> > > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
>> > > already established use of "brcm" before any of the bcm281xx support
>> > > came in. Ideally, the vendor prefix should change to "bcm" since every
>> > > reference in the family names is BCM. However, if others want the least
>> > > amount of churn in making this consistent, we might have to go with
>> > > "brcm" across the board.
>> >
>> > I would like to keep "brcm" here because that is what has been defined as a
>> > vendor prefix, and is used beyond the scope of the ARM Linux kernel support
>> > even within Broadcom. Maybe it was an oversight, or rather a mistake to let
>>
>> brcm is the stock ticker. As far as I can search, this is the convention
>> for the vendor prefixes.
>
> No, correlation does not equal causation. The fact that some vendor
> prefixes in DT match the stock symbol is by chance of 3-4 character name
> being the same...nothing more.

That was a bad argument as was later explained to me, I won't use that
reason again.

>
> It's pretty easy to see that the "ti" vendor prefix has no relation at
> all to their TXN symbol so that blows that convention out of the water.
> Rather, the prefix is based on somebody's notion of how that vendor's
> part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
> never TXN OMAP. :)
>
> For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.

It was appropriate before being the "wrong" vendor prefix was
allocated, now that "brcm" has been allocated we should stick to it
because otherwise we will break existing and on-going DT work.

At the very least, all possible confusion would be avoided by using
"broadcom" instead of any other abreviation.
--
Florian


From arend at broadcom.com  Tue Jul 23 15:14:49 2013
From: arend at broadcom.com (Arend van Spriel)
Date: Tue, 23 Jul 2013 21:14:49 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X
 SoC with ARM CPU
In-Reply-To: <CAGVrzcbA72AYu6J3JXBirQQeTiDH9cJThdBdH=Q=gJtOnqz-AA@mail.gmail.com>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130723184907.GA6811@ohporter.com>
 <CAGVrzcbA72AYu6J3JXBirQQeTiDH9cJThdBdH=Q=gJtOnqz-AA@mail.gmail.com>
Message-ID: <51EED629.1000404@broadcom.com>

On 07/23/2013 08:56 PM, Florian Fainelli wrote:
> If you want to add more confusion, because there is,
> drivers/staging/bcm which stands for Beceem has been later acquired by
> Broadcom, eventually turning this 3 letter word into something
> "consistent" from a Broadcom point of view. As far as I am concerned,
> I would just stick with the allocated vendor prefix and replace "bcm"
> with "brcm" because the allocated one is the authoritative one.

Nice, huh. In device-tree notation it identifies the vendor and I agree 
that brcm is a better/preferred vendor id. The confusion here is that 
the device identifiers are all prefixed with "bcm", which is something 
different than the vendor id. I do not think consistency was the goal in 
the acquisition of Beceem ;-)

>> >
>>> >>the bcm281x/kona family support code be merged and use "bcm" there, without
>>> >>registering it. Besides, a simple rule of number here wins:
>>> >>
>>> >>git grep "brcm," * | wc -l
>>> >>63
>>> >>git grep "bcm," * | wc -l
>>> >>25
>>> >>
>>> >>(as of Linux 3.11-rc1)
>>> >>
>>> >>So consistency we should get the bcm281x/kona DT bindings to rename their
>>> >>vendor prefix as well.
>> >
>> >I believe getting this "right" is far more important than the difference
>> >in churn of a mere 38 instances of use of brcm. "Right" is two things:
>> >1) it needs to be consistent 2) it should be what makes sense.
> I agree, which is the reason why I would stick with the vendor prefix
> and end the story there.

Agree.

> --
> Florian

Regards,
Arend



From olof at lixom.net  Tue Jul 23 15:15:54 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 23 Jul 2013 12:15:54 -0700
Subject: [PATCH] ARM: pxa: propagate errors from regulator_enable() to
 pxamci
In-Reply-To: <8638rt3svt.fsf@void.printf.net>
References: <201307051751.20729.arnd@arndb.de> <8638rt3svt.fsf@void.printf.net>
Message-ID: <CAOesGMiVzH7qyu_tBpKV5PTHBvvwE9E6Q9f39ENfVOO-6wY3+w@mail.gmail.com>

On Fri, Jul 5, 2013 at 8:53 AM, Chris Ball <cjb at laptop.org> wrote:
> Hi,
>
> On Fri, Jul 05 2013, Arnd Bergmann wrote:
>> The em_x270_mci_setpower() and em_x270_usb_hub_init() functions
>> call regulator_enable(), which may return an error that must
>> be checked.
>>
>> This changes the em_x270_usb_hub_init() function to bail out
>> if it fails, and changes the pxamci_platform_data->setpower
>> callback so that the a failed em_x270_mci_setpower call
>> can be propagated by the pxamci driver into the mmc core.
>>
>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>
> For pxamci:
>
> Acked-by: Chris Ball <cjb at laptop.org>

Applied with your ack to arm-soc fixes branch for 3.11, after fixing
the set/test ordering pointed out in the thread.

Thanks!

-Olof


From olof at lixom.net  Tue Jul 23 15:18:33 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 23 Jul 2013 12:18:33 -0700
Subject: [PATCH] ARM: multi_v7_defconfig: Select USB chipidea driver
In-Reply-To: <1374598926-23761-1-git-send-email-fabio.estevam@freescale.com>
References: <1374598926-23761-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <20130723191833.GA16811@quad.lixom.net>

On Tue, Jul 23, 2013 at 02:02:06PM -0300, Fabio Estevam wrote:
> CONFIG_USB_EHCI_MXC selects the old i.mx USB driver, which does not support 
> device tree.
> 
> Select the USB chipidea driver instead, so that USB can be functional on i.mx.

Applied to 3.11 fixes branch, but we should probably stop updating defconfigs
for 3.11 now unless it's because of real problems.


-Olof


From matt at ohporter.com  Tue Jul 23 15:22:04 2013
From: matt at ohporter.com (Matt Porter)
Date: Tue, 23 Jul 2013 15:22:04 -0400
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <CAGVrzcbA72AYu6J3JXBirQQeTiDH9cJThdBdH=Q=gJtOnqz-AA@mail.gmail.com>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130723184907.GA6811@ohporter.com>
 <CAGVrzcbA72AYu6J3JXBirQQeTiDH9cJThdBdH=Q=gJtOnqz-AA@mail.gmail.com>
Message-ID: <20130723192203.GC6811@ohporter.com>

On Tue, Jul 23, 2013 at 07:56:26PM +0100, Florian Fainelli wrote:
> 2013/7/23 Matt Porter <matt.porter at linaro.org>:
> > On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote:
> >> Hello,
> >>
> >> Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :
> >> > > + compatible = "brcm,bcm5301x";
> >> >
> >> > Ok, this was nagging at me before I went on my very long vacation. I see
> >> > the "brcm" vendor prefix as a real consistency problem. I noticed on the
> >> > bcm281xx/kona family, we have been using "bcm" which is not logged in
> >> > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
> >> > already established use of "brcm" before any of the bcm281xx support
> >> > came in. Ideally, the vendor prefix should change to "bcm" since every
> >> > reference in the family names is BCM. However, if others want the least
> >> > amount of churn in making this consistent, we might have to go with
> >> > "brcm" across the board.
> >>
> >> I would like to keep "brcm" here because that is what has been defined as a
> >> vendor prefix, and is used beyond the scope of the ARM Linux kernel support
> >> even within Broadcom. Maybe it was an oversight, or rather a mistake to let
> >
> > [Update: I thought some more about this and investigated why Broadcom started
> >  using "bcm" and changed my mind]
> >
> > Can you provide a cite?
> 
> Well, I can tell you that this is what my group is using for its
> vendor prefix in DT because this is the one that was allocated in
> vendor-prefixes.txt. This is also what the upstream BCM63xx DSL SoC is
> using even though that port is still WIP, so could be subject to
> changing.
> 
> > I can tell you that within Broadcom they have
> > been moving to get rid of it. That is why you see all this Broadcom
> > originated code using "bcm" because it actually matches their part
> > number prefix. As further evidence of the preference for "bcm", feel free to
> > look through the entire public catalog of parts at
> > http://www.broadcom.com/products/ and note that they all have BCM as the part
> > prefix...this carries over into all driver references to the parts as well
> > including everything in the wireless world.
> 
> If you want to add more confusion, because there is,
> drivers/staging/bcm which stands for Beceem has been later acquired by
> Broadcom, eventually turning this 3 letter word into something
> "consistent" from a Broadcom point of view. As far as I am concerned,
> I would just stick with the allocated vendor prefix and replace "bcm"
> with "brcm" because the allocated one is the authoritative one.
> 
> >
> >> the bcm281x/kona family support code be merged and use "bcm" there, without
> >> registering it. Besides, a simple rule of number here wins:
> >>
> >> git grep "brcm," * | wc -l
> >> 63
> >> git grep "bcm," * | wc -l
> >> 25
> >>
> >> (as of Linux 3.11-rc1)
> >>
> >> So consistency we should get the bcm281x/kona DT bindings to rename their
> >> vendor prefix as well.
> >
> > I believe getting this "right" is far more important than the difference
> > in churn of a mere 38 instances of use of brcm. "Right" is two things:
> > 1) it needs to be consistent 2) it should be what makes sense.
> 
> I agree, which is the reason why I would stick with the vendor prefix
> and end the story there.

It doesn't end there. An update to all the in process stuff has to
happen, plus the upstream stuff. So in both cases there are changes to
be made both upstream and with work-in-progress. The only difference is
that I was suggesting an update to correct the prefix in
vendor-prefixes.txt.

However, if I'm the only one that cares enough to speak up for "bcm"
I'll abandon that and submit the patch to adjust bcm281xx to be
compliant with the current state of vendor-prefixes.txt. :)

-Matt


From broonie at kernel.org  Tue Jul 23 15:31:05 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 23 Jul 2013 20:31:05 +0100
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130723180110.GA8688@kroah.com>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <51EE9EC0.6060905@ti.com> <20130723161846.GD2486@kroah.com>
 <1446965.6APW5ZgLBW@amdc1227> <20130723173710.GB28284@kroah.com>
 <20130723174456.GM9858@sirena.org.uk>
 <20130723180110.GA8688@kroah.com>
Message-ID: <20130723193105.GP9858@sirena.org.uk>

On Tue, Jul 23, 2013 at 11:01:10AM -0700, Greg KH wrote:
> On Tue, Jul 23, 2013 at 06:44:56PM +0100, Mark Brown wrote:

> > What are the problems you are seeing with doing things with lookups?

> You don't "know" the id of the device you are looking up, due to
> multiple devices being in the system (dynamic ids, look back earlier in
> this thread for details about that.)

I got copied in very late so don't have most of the thread I'm afraid, 
I did try looking at web archives but didn't see a clear problem
statement.  In any case this is why the APIs doing lookups do the
lookups in the context of the requesting device - devices ask for
whatever name they use locally.

> > Having to write platform data for everything gets old fast and the code
> > duplication is pretty tedious...

> Adding a single pointer is "tedious"?  Where is the "name" that you are
> going to lookup going to come from?  That code doesn't write itself...

It's adding platform data in the first place that gets tedious - and of
course there's also DT and ACPI to worry about, it's not just a case of
platform data and then you're done.  Pushing the lookup into library
code means that drivers don't have to worry about any of this stuff.

For most of the APIs doing this there is a clear and unambiguous name in
the hardware that can be used (and for hardware process reasons is
unlikely to get changed).  The major exception to this is the clock API
since it is relatively rare to have clear, segregated IP level
information for IPs baked into larger chips.  The other APIs tend to be
establishing chip to chip links.
-------------- 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/20130723/3c3ea43f/attachment-0001.sig>

From nico at fluxnic.net  Tue Jul 23 15:34:25 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Tue, 23 Jul 2013 15:34:25 -0400 (EDT)
Subject: linux setup
In-Reply-To: <20130723102554.GD3748@MacBook-Pro.local>
References: <CANEcUBXMPhTjgVYbRN7NY+EUjh7DDGpKnZ8_LXY-ZLcfbH65Ug@mail.gmail.com>
 <20130723102554.GD3748@MacBook-Pro.local>
Message-ID: <alpine.LFD.2.03.1307231530080.15022@syhkavp.arg>

On Tue, 23 Jul 2013, Catalin Marinas wrote:

> On Mon, Jul 22, 2013 at 02:28:50PM +0100, zhaobin xv wrote:
> > I recently read lernel source .
> > I have a question:In
> > folder:linux/arch/arm/boot/compressed/head.S(linux2.6.22.6):
> > 
> > 
> > start:
> >         .type    start,#function
> >         .rept    8
> >         mov    r0, r0
> >         .endr
> > 
> >         b    1f
> >         .word    0x016f2818        @ Magic numbers to help the loader
> >         .word    start            @ absolute load/run zImage address
> >         .word    _edata            @ zImage end address
> > 1:        mov    r7, r1            @ save architecture ID
> >         mov    r8, r2            @ save atags pointer
> > 
> > 
> > I don't kown why the ?mov r0 r0 ? repeated  emergence 8 times.
> 
> I think some people used that in the past to be able to modify the
> zImage binary directly and work around wrong register values passed by
> the boot loader. I've never used it myself but I saw it mentioned once.

The whole reason for this is because in a distant past the kernel image 
was an a.out binary containing a 32-bytes header.  Those nops are simply 
padding so to be compatible with those bootloaders expecting the kernel 
code to start at an offset of 32.


Nicolas

From stern at rowland.harvard.edu  Tue Jul 23 15:36:00 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 23 Jul 2013 15:36:00 -0400 (EDT)
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <1446965.6APW5ZgLBW@amdc1227>
Message-ID: <Pine.LNX.4.44L0.1307231518310.1304-100000@iolanthe.rowland.org>

On Tue, 23 Jul 2013, Tomasz Figa wrote:

> IMHO it would be better if you provided some code example, but let's try to 
> check if I understood you correctly.
> 
> 8><------------------------------------------------------------------------
> 
> [Board file]
> 
> static struct phy my_phy;
> 
> static struct platform_device phy_pdev = {
> 	/* ... */
> 	.platform_data = &my_phy;
> 	/* ... */
> };
> 
> static struct platform_device phy_pdev = {

This should be controller_pdev, not phy_pdev, yes?

> 	/* ... */
> 	.platform_data = &my_phy;
> 	/* ... */
> };
> 
> [Provider driver]
> 
> struct phy *phy = pdev->dev.platform_data;
> 
> ret = phy_create(phy);
> 
> [Consumer driver]
> 
> struct phy *phy = pdev->dev.platform_data;
> 
> ret = phy_get(&pdev->dev, phy);

Or even just phy_get(&pdev->dev), because phy_get() could be smart 
enough to to set phy = dev->platform_data.

> ------------------------------------------------------------------------><8
> 
> Is this what you mean?

That's what I was going to suggest too.  The struct phy is defined in
the board file, which already knows about all the PHYs that exist in
the system.  (Or perhaps it is allocated dynamically, so that when many
board files are present in the same kernel, only the entries listed in
the board file for the current system get created.)  Then the
structure's address is stored in the platform data and made available
to both the provider and the consumer.

Even though the struct phy is defined (or allocated) in the board file,
its contents don't get filled in until the PHY driver provides the
details.

> It's technically correct, but quality of this solution isn't really nice, 
> because it's a layering violation (at least if I understood what you mean). 
> This is because you need to have full definition of struct phy in board file 
> and a structure that is used as private data in PHY core comes from 
> platform code.

You don't have to have a full definition in the board file.  Just a 
partial definition -- most of the contents can be filled in later, when 
the PHY driver is ready to store the private data.

It's not a layering violation for one region of the kernel to store 
private data in a structure defined by another part of the kernel.  
This happens all the time (e.g., dev_set_drvdata).

Alan Stern



From gregkh at linuxfoundation.org  Tue Jul 23 15:44:23 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 23 Jul 2013 12:44:23 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130723193105.GP9858@sirena.org.uk>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <51EE9EC0.6060905@ti.com> <20130723161846.GD2486@kroah.com>
 <1446965.6APW5ZgLBW@amdc1227> <20130723173710.GB28284@kroah.com>
 <20130723174456.GM9858@sirena.org.uk>
 <20130723180110.GA8688@kroah.com>
 <20130723193105.GP9858@sirena.org.uk>
Message-ID: <20130723194423.GA22984@kroah.com>

On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
> > You don't "know" the id of the device you are looking up, due to
> > multiple devices being in the system (dynamic ids, look back earlier in
> > this thread for details about that.)
> 
> I got copied in very late so don't have most of the thread I'm afraid, 
> I did try looking at web archives but didn't see a clear problem
> statement.  In any case this is why the APIs doing lookups do the
> lookups in the context of the requesting device - devices ask for
> whatever name they use locally.

What do you mean by "locally"?

The problem with the api was that the phy core wanted a id and a name to
create a phy, and then later other code was doing a "lookup" based on
the name and id (mushed together), because it "knew" that this device
was the one it wanted.

Just like the clock api, which, for multiple devices, has proven to
cause problems.  I don't want to see us accept an api that we know has
issues in it now, I'd rather us fix it up properly.

Subsystems should be able to create ids how ever they want to, and not
rely on the code calling them to specify the names of the devices that
way, otherwise the api is just too fragile.

I think, that if you create a device, then just carry around the pointer
to that device (in this case a phy) and pass it to whatever other code
needs it.  No need to do lookups on "known names" or anything else, just
normal pointers, with no problems for multiple devices, busses, or
naming issues.

> > > Having to write platform data for everything gets old fast and the code
> > > duplication is pretty tedious...
> 
> > Adding a single pointer is "tedious"?  Where is the "name" that you are
> > going to lookup going to come from?  That code doesn't write itself...
> 
> It's adding platform data in the first place that gets tedious - and of
> course there's also DT and ACPI to worry about, it's not just a case of
> platform data and then you're done.  Pushing the lookup into library
> code means that drivers don't have to worry about any of this stuff.

I agree, so just pass around the pointer to the phy and all is good.  No
need to worry about DT or ACPI or anything else.

> For most of the APIs doing this there is a clear and unambiguous name in
> the hardware that can be used (and for hardware process reasons is
> unlikely to get changed).  The major exception to this is the clock API
> since it is relatively rare to have clear, segregated IP level
> information for IPs baked into larger chips.  The other APIs tend to be
> establishing chip to chip links.

The clock api is having problems with multiple "names" due to dynamic
devices from what I was told.  I want to prevent the PHY interface from
having that same issue.

thanks,

greg k-h


From broonie at kernel.org  Tue Jul 23 15:44:47 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 23 Jul 2013 20:44:47 +0100
Subject: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on
 Exynos5420
In-Reply-To: <CAAgF-BfdfuhoFDH+SeZogXh1wju34hGp-T9N7_+mnapHfc2yww@mail.gmail.com>
References: <1373526505-27115-1-git-send-email-padma.v@samsung.com>
 <29860116.IF545KsGYb@thinkpad>
 <20130711112023.GM24508@sirena.org.uk>
 <2214161.FSfscAvpna@thinkpad>
 <20130711130139.GQ24508@sirena.org.uk>
 <CAAgF-BdM4jw0o4+ELVo_N029tbgMJBBqJxU91e=TgBNiiREyaA@mail.gmail.com>
 <20130712084932.GY24508@sirena.org.uk>
 <CAAgF-BfdfuhoFDH+SeZogXh1wju34hGp-T9N7_+mnapHfc2yww@mail.gmail.com>
Message-ID: <20130723194447.GT9858@sirena.org.uk>

On Tue, Jul 23, 2013 at 09:38:00AM +0530, Padma Venkat wrote:
> On Fri, Jul 12, 2013 at 2:19 PM, Mark Brown <broonie at kernel.org> wrote:

> > Yes, this is good but the quirk should just be found by software based
> > on the compatible string rather than in the DT.

> You mean I just need to initialize the quirks in the driver based on
> the compatible string?

That's the gold standard.

> So what about the quirks that I added previously on 5250? Should I
> also follow the same thing for other quirks?

Yes, ideally.

> Or it need to be passed via driver data as it is done in spi driver?
> Please clarify me.

This is a good way to initialise things based on the name - the core
will do the lookups for you.
-------------- 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/20130723/09c53da6/attachment.sig>

From nicolas.pitre at linaro.org  Tue Jul 23 15:45:01 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Jul 2013 15:45:01 -0400 (EDT)
Subject: [PATCH 0/5] ARM: DT: remove redundant DT related code
In-Reply-To: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <alpine.LFD.2.03.1307231543480.15022@syhkavp.arg>

On Tue, 23 Jul 2013, Sudeep KarkadaNagesha wrote:

> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
> 
> Hi,
> 
> As part of my changes to remove duplicate code for parsing cpu nodes
> in the device tree, I found few unnecessary code mostly around smp_init_cpus.
> Most of the ARM Cortex A9 based platforms use SCU to get the number of cpus
> while many others depend on the device tree.
> 
> Even on DT based platforms using SCU, they can be made to depend on DT
> to cpu count simplifying smp_init_cpus. In fact arm_dt_init_cpu_maps called
> before smp_init_cpus, already does the device tree parsing, validating
> nr_cpu_ids and setting the cpu_possible_mask appropriately. 
> 
> However this series targets only the platforms using DT for cpu count
> (i.e. not using SCU)
> 
> Regards,
> Sudeep
For the whole series:

Acked-by: Nicolas Pitre <nico at linaro.org>


> Sudeep KarkadaNagesha (5):
>   ARM: keystone: remove redundant smp_init_cpus definition
>   ARM: vexpress: remove redundant vexpress_dt_cpus_num to get cpu count
>   ARM: mach-mvebu: remove redundant DT parsing and validation
>   ARM: highbank: remove redundant smp_init_cpus definition
>   ARM: zynq: remove unnecessary setting of cpu_present_mask
> 
>  arch/arm/mach-highbank/platsmp.c | 22 ----------------------
>  arch/arm/mach-keystone/platsmp.c |  1 -
>  arch/arm/mach-mvebu/platsmp.c    | 19 +------------------
>  arch/arm/mach-vexpress/platsmp.c | 32 +-------------------------------
>  arch/arm/mach-zynq/platsmp.c     |  9 ---------
>  5 files changed, 2 insertions(+), 81 deletions(-)
> 
> -- 
> 1.8.1.2
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From nico at fluxnic.net  Tue Jul 23 15:48:11 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Tue, 23 Jul 2013 15:48:11 -0400 (EDT)
Subject: [PATCH 1/6] ARM: prefetch: remove redundant "cc" clobber
In-Reply-To: <1374579389-32704-2-git-send-email-will.deacon@arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-2-git-send-email-will.deacon@arm.com>
Message-ID: <alpine.LFD.2.03.1307231547010.15022@syhkavp.arg>

On Tue, 23 Jul 2013, Will Deacon wrote:

> The pld instruction does not affect the condition flags, so don't bother
> clobbering them.
> 
> Signed-off-by: Will Deacon <will.deacon at arm.com>

Acked-by: Nicolas Pitre <nico at linaro.org>

You know the legacy reason why the cc clobber was there, right?
It certainly doesn't apply anymore.



> ---
>  arch/arm/include/asm/processor.h | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
> index 06e7d50..91cfe08 100644
> --- a/arch/arm/include/asm/processor.h
> +++ b/arch/arm/include/asm/processor.h
> @@ -101,9 +101,7 @@ static inline void prefetch(const void *ptr)
>  {
>  	__asm__ __volatile__(
>  		"pld\t%a0"
> -		:
> -		: "p" (ptr)
> -		: "cc");
> +		:: "p" (ptr));
>  }
>  
>  #define ARCH_HAS_PREFETCHW
> -- 
> 1.8.2.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From nicolas.pitre at linaro.org  Tue Jul 23 15:55:42 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Jul 2013 15:55:42 -0400 (EDT)
Subject: [PATCH 2/6] ARM: smp_on_up: move inline asm ALT_SMP patching
 macro out of spinlock.h
In-Reply-To: <1374579389-32704-3-git-send-email-will.deacon@arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-3-git-send-email-will.deacon@arm.com>
Message-ID: <alpine.LFD.2.03.1307231555240.15022@syhkavp.arg>

On Tue, 23 Jul 2013, Will Deacon wrote:

> Patching UP/SMP alternatives inside inline assembly blocks is useful
> outside of the spinlock implementation, where it is used for sev and wfe.
> 
> This patch lifts the macro into processor.h and gives it a scarier name
> to (a) avoid conflicts in the global namespace and (b) to try and deter
> its usage unless you "know what you're doing". The W macro for generating
> wide instructions when targetting Thumb-2 is also made available under
> the name WASM, to reduce the potential for conflicts with other headers.
> 
> Signed-off-by: Will Deacon <will.deacon at arm.com>

Acked-by: Nicolas Pitre <nico at linaro.org>

> ---
>  arch/arm/include/asm/processor.h | 12 ++++++++++++
>  arch/arm/include/asm/spinlock.h  | 15 ++++-----------
>  arch/arm/include/asm/unified.h   |  4 ++++
>  3 files changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
> index 91cfe08..cbdb130 100644
> --- a/arch/arm/include/asm/processor.h
> +++ b/arch/arm/include/asm/processor.h
> @@ -22,6 +22,7 @@
>  #include <asm/hw_breakpoint.h>
>  #include <asm/ptrace.h>
>  #include <asm/types.h>
> +#include <asm/unified.h>
>  
>  #ifdef __KERNEL__
>  #define STACK_TOP	((current->personality & ADDR_LIMIT_32BIT) ? \
> @@ -91,6 +92,17 @@ unsigned long get_wchan(struct task_struct *p);
>  #define KSTK_EIP(tsk)	task_pt_regs(tsk)->ARM_pc
>  #define KSTK_ESP(tsk)	task_pt_regs(tsk)->ARM_sp
>  
> +#ifdef CONFIG_SMP
> +#define __ALT_SMP_ASM(smp, up)						\
> +	"9998:	" smp "\n"						\
> +	"	.pushsection \".alt.smp.init\", \"a\"\n"		\
> +	"	.long	9998b\n"					\
> +	"	" up "\n"						\
> +	"	.popsection\n"
> +#else
> +#define __ALT_SMP_ASM(smp, up)	up
> +#endif
> +
>  /*
>   * Prefetching support - only ARMv5.
>   */
> diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
> index f8b8965..0de7bec 100644
> --- a/arch/arm/include/asm/spinlock.h
> +++ b/arch/arm/include/asm/spinlock.h
> @@ -11,15 +11,7 @@
>   * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
>   * extensions, so when running on UP, we have to patch these instructions away.
>   */
> -#define ALT_SMP(smp, up)					\
> -	"9998:	" smp "\n"					\
> -	"	.pushsection \".alt.smp.init\", \"a\"\n"	\
> -	"	.long	9998b\n"				\
> -	"	" up "\n"					\
> -	"	.popsection\n"
> -
>  #ifdef CONFIG_THUMB2_KERNEL
> -#define SEV		ALT_SMP("sev.w", "nop.w")
>  /*
>   * For Thumb-2, special care is needed to ensure that the conditional WFE
>   * instruction really does assemble to exactly 4 bytes (as required by
> @@ -31,17 +23,18 @@
>   * the assembler won't change IT instructions which are explicitly present
>   * in the input.
>   */
> -#define WFE(cond)	ALT_SMP(		\
> +#define WFE(cond)	__ALT_SMP_ASM(		\
>  	"it " cond "\n\t"			\
>  	"wfe" cond ".n",			\
>  						\
>  	"nop.w"					\
>  )
>  #else
> -#define SEV		ALT_SMP("sev", "nop")
> -#define WFE(cond)	ALT_SMP("wfe" cond, "nop")
> +#define WFE(cond)	__ALT_SMP_ASM("wfe" cond, "nop")
>  #endif
>  
> +#define SEV		__ALT_SMP_ASM(WASM(sev), WASM(nop))
> +
>  static inline void dsb_sev(void)
>  {
>  #if __LINUX_ARM_ARCH__ >= 7
> diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
> index f5989f4..b88beab 100644
> --- a/arch/arm/include/asm/unified.h
> +++ b/arch/arm/include/asm/unified.h
> @@ -38,6 +38,8 @@
>  #ifdef __ASSEMBLY__
>  #define W(instr)	instr.w
>  #define BSYM(sym)	sym + 1
> +#else
> +#define WASM(instr)	#instr ".w"
>  #endif
>  
>  #else	/* !CONFIG_THUMB2_KERNEL */
> @@ -50,6 +52,8 @@
>  #ifdef __ASSEMBLY__
>  #define W(instr)	instr
>  #define BSYM(sym)	sym
> +#else
> +#define WASM(instr)	#instr
>  #endif
>  
>  #endif	/* CONFIG_THUMB2_KERNEL */
> -- 
> 1.8.2.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From nico at fluxnic.net  Tue Jul 23 16:05:58 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Tue, 23 Jul 2013 16:05:58 -0400 (EDT)
Subject: [PATCH 3/6] ARM: prefetch: add support for prefetchw using pldw on
 SMP ARMv7+ CPUs
In-Reply-To: <1374579389-32704-4-git-send-email-will.deacon@arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-4-git-send-email-will.deacon@arm.com>
Message-ID: <alpine.LFD.2.03.1307231559120.15022@syhkavp.arg>

On Tue, 23 Jul 2013, Will Deacon wrote:

> SMP ARMv7 CPUs implement the pldw instruction, which allows them to
> prefetch data cachelines in an exclusive state.
> 
> This patch defines the prefetchw macro using pldw for CPUs that support
> it.
> 
> Signed-off-by: Will Deacon <will.deacon at arm.com>

Minor nit below.  Otherwise:

Acked-by: Nicolas Pitre <nico at linaro.org>

> ---
>  arch/arm/include/asm/processor.h | 17 ++++++++++++-----
>  1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
> index cbdb130..d571697 100644
> --- a/arch/arm/include/asm/processor.h
> +++ b/arch/arm/include/asm/processor.h
> @@ -116,12 +116,19 @@ static inline void prefetch(const void *ptr)
>  		:: "p" (ptr));
>  }
>  
> +#if __LINUX_ARM_ARCH__ >= 7 && defined(CONFIG_SMP)
>  #define ARCH_HAS_PREFETCHW
> -#define prefetchw(ptr)	prefetch(ptr)
> -
> -#define ARCH_HAS_SPINLOCK_PREFETCH
> -#define spin_lock_prefetch(x) do { } while (0)
> -

What about keeping the above definitions when __LINUX_ARM_ARCH__ >= 7
&& defined(CONFIG_SMP) is not true?

> +static inline void prefetchw(const void *ptr)
> +{
> +	__asm__ __volatile__(
> +		".arch_extension	mp\n"
> +	__ALT_SMP_ASM(
> +		WASM(pldw)		"\t%a0",
> +		WASM(pld)		"\t%a0"
> +	)

The paren indentation looks odd.  If you shift the whole __ALT_SMP_ASM 
block right then it is also less likely to look like a sequential 
execution of pldw followed by pld to the casual reader.

> +		:: "p" (ptr));
> +}
> +#endif
>  #endif
>  
>  #define HAVE_ARCH_PICK_MMAP_LAYOUT
> -- 
> 1.8.2.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From tomasz.figa at gmail.com  Tue Jul 23 16:07:52 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 22:07:52 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130723194423.GA22984@kroah.com>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <20130723193105.GP9858@sirena.org.uk> <20130723194423.GA22984@kroah.com>
Message-ID: <1731726.KENstTPhkb@flatron>

On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
> On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
> > > You don't "know" the id of the device you are looking up, due to
> > > multiple devices being in the system (dynamic ids, look back earlier
> > > in
> > > this thread for details about that.)
> > 
> > I got copied in very late so don't have most of the thread I'm afraid,
> > I did try looking at web archives but didn't see a clear problem
> > statement.  In any case this is why the APIs doing lookups do the
> > lookups in the context of the requesting device - devices ask for
> > whatever name they use locally.
> 
> What do you mean by "locally"?
> 
> The problem with the api was that the phy core wanted a id and a name to
> create a phy, and then later other code was doing a "lookup" based on
> the name and id (mushed together), because it "knew" that this device
> was the one it wanted.
> 
> Just like the clock api, which, for multiple devices, has proven to
> cause problems.  I don't want to see us accept an api that we know has
> issues in it now, I'd rather us fix it up properly.
> 
> Subsystems should be able to create ids how ever they want to, and not
> rely on the code calling them to specify the names of the devices that
> way, otherwise the api is just too fragile.
> 
> I think, that if you create a device, then just carry around the pointer
> to that device (in this case a phy) and pass it to whatever other code
> needs it.  No need to do lookups on "known names" or anything else,
> just normal pointers, with no problems for multiple devices, busses, or
> naming issues.

PHY object is not a device, it is something that a device driver creates 
(one or more instances of) when it is being probed. You don't have a clean 
way to export this PHY object to other driver, other than keeping this PHY 
on a list inside PHY core with some well-known ID (e.g. device name + 
consumer port name/index, like in regulator core) and then to use this 
well-known ID inside consumer driver as a lookup key passed to phy_get();

Actually I think for PHY case, exactly the same way as used for regulators 
might be completely fine:

1. Each PHY would have some kind of platform, non-unique name, that is 
just used to print some messages (like the platform/board name of a 
regulator).
2. Each PHY would have an array of consumers. Consumer specifier would 
consist of consumer device name and consumer port name - just like in 
regulator subsystem.
3. PHY driver receives an array of, let's say, phy_init_data inside its 
platform data that it would use to register its PHYs.
4. Consumer drivers would have constant consumer port names and wouldn't 
receive any information about PHYs from platform code.

Code example:

[Board file]

static const struct phy_consumer_data usb_20_phy0_consumers[] = {
	{
		.devname = "foo-ehci",
		.port = "usbphy",
	},
};

static const struct phy_consumer_data usb_20_phy1_consumers[] = {
	{
		.devname = "foo-otg",
		.port = "otgphy",
	},
};

static const struct phy_init_data my_phys[] = {
	{
		.name = "USB 2.0 PHY 0",
		.consumers = usb_20_phy0_consumers,
		.num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
	},
	{
		.name = "USB 2.0 PHY 1",
		.consumers = usb_20_phy1_consumers,
		.num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
	},
	{ }
};

static const struct platform_device usb_phy_pdev = {
	.name = "foo-usbphy",
	.id = -1,
	.dev = {
		.platform_data = my_phys,
	},
};

[PHY driver]

static int foo_usbphy_probe(pdev)
{
	struct foo_usbphy *foo;
	struct phy_init_data *init_data = pdev->dev.platform_data;
	/* ... */
	// for each PHY in init_data {
		phy_register(&foo->phy[i], &init_data[i]);
	// }
	/* ... */
}

[EHCI driver]

static int foo_ehci_probe(pdev)
{
	struct phy *phy;
	/* ... */
	phy = phy_get(&pdev->dev, "usbphy");
	/* ... */
}

[OTG driver]

static int foo_otg_probe(pdev)
{
	struct phy *phy;
	/* ... */
	phy = phy_get(&pdev->dev, "otgphy");
	/* ... */
}

> > > > Having to write platform data for everything gets old fast and the
> > > > code
> > > > duplication is pretty tedious...
> > > 
> > > Adding a single pointer is "tedious"?  Where is the "name" that you
> > > are
> > > going to lookup going to come from?  That code doesn't write
> > > itself...
> > 
> > It's adding platform data in the first place that gets tedious - and
> > of
> > course there's also DT and ACPI to worry about, it's not just a case
> > of
> > platform data and then you're done.  Pushing the lookup into library
> > code means that drivers don't have to worry about any of this stuff.
> 
> I agree, so just pass around the pointer to the phy and all is good.  No
> need to worry about DT or ACPI or anything else.

With Device Tree we don't have board files anymore. How would you pass any 
pointers between provider and consumer drivers in this case?

> > For most of the APIs doing this there is a clear and unambiguous name
> > in the hardware that can be used (and for hardware process reasons is
> > unlikely to get changed).  The major exception to this is the clock
> > API since it is relatively rare to have clear, segregated IP level
> > information for IPs baked into larger chips.  The other APIs tend to
> > be establishing chip to chip links.
> 
> The clock api is having problems with multiple "names" due to dynamic
> devices from what I was told.  I want to prevent the PHY interface from
> having that same issue.

Yes, the clock API has a problem related to the clock namespace being 
global for all registered clock controllers. This is not a problem with 
lookup in general, but with wrong lookup key chosen.

Best regards,
Tomasz



From nicolas.pitre at linaro.org  Tue Jul 23 16:10:33 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Jul 2013 16:10:33 -0400 (EDT)
Subject: [PATCH 4/6] ARM: locks: prefetch the destination word for write
 prior to strex
In-Reply-To: <1374579389-32704-5-git-send-email-will.deacon@arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-5-git-send-email-will.deacon@arm.com>
Message-ID: <alpine.LFD.2.03.1307231609170.15022@syhkavp.arg>

On Tue, 23 Jul 2013, Will Deacon wrote:

> The cost of changing a cacheline from shared to exclusive state can be
> significant, especially when this is triggered by an exclusive store,
> since it may result in having to retry the transaction.
> 
> This patch prefixes our {spin,read,write}_[try]lock implementations with
> pldw instructions (on CPUs which support them) to try and grab the line
> in exclusive state from the start.
> 
> Signed-off-by: Will Deacon <will.deacon at arm.com>
> ---
>  arch/arm/include/asm/spinlock.h | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
> index 0de7bec..3e1cc9d 100644
> --- a/arch/arm/include/asm/spinlock.h
> +++ b/arch/arm/include/asm/spinlock.h
> @@ -5,7 +5,7 @@
>  #error SMP not supported on pre-ARMv6 CPUs
>  #endif
>  
> -#include <asm/processor.h>
> +#include <linux/prefetch.h>
>  
>  /*
>   * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
> @@ -70,6 +70,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
>  	u32 newval;
>  	arch_spinlock_t lockval;
>  
> +	prefetchw((const void *)&lock->slock);

Couldn't that cast be carried in the definition of prefetchw() instead?


Other than that:

Acked-by: Nicolas Pitre <nico at linaro.org>





>  	__asm__ __volatile__(
>  "1:	ldrex	%0, [%3]\n"
>  "	add	%1, %0, %4\n"
> @@ -93,6 +94,7 @@ static inline int arch_spin_trylock(arch_spinlock_t *lock)
>  	unsigned long contended, res;
>  	u32 slock;
>  
> +	prefetchw((const void *)&lock->slock);
>  	do {
>  		__asm__ __volatile__(
>  		"	ldrex	%0, [%3]\n"
> @@ -145,6 +147,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
>  {
>  	unsigned long tmp;
>  
> +	prefetchw((const void *)&rw->lock);
>  	__asm__ __volatile__(
>  "1:	ldrex	%0, [%1]\n"
>  "	teq	%0, #0\n"
> @@ -163,6 +166,7 @@ static inline int arch_write_trylock(arch_rwlock_t *rw)
>  {
>  	unsigned long tmp;
>  
> +	prefetchw((const void *)&rw->lock);
>  	__asm__ __volatile__(
>  "	ldrex	%0, [%1]\n"
>  "	teq	%0, #0\n"
> @@ -211,6 +215,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
>  {
>  	unsigned long tmp, tmp2;
>  
> +	prefetchw((const void *)&rw->lock);
>  	__asm__ __volatile__(
>  "1:	ldrex	%0, [%2]\n"
>  "	adds	%0, %0, #1\n"
> @@ -231,6 +236,7 @@ static inline void arch_read_unlock(arch_rwlock_t *rw)
>  
>  	smp_mb();
>  
> +	prefetchw((const void *)&rw->lock);
>  	__asm__ __volatile__(
>  "1:	ldrex	%0, [%2]\n"
>  "	sub	%0, %0, #1\n"
> @@ -249,6 +255,7 @@ static inline int arch_read_trylock(arch_rwlock_t *rw)
>  {
>  	unsigned long tmp, tmp2 = 1;
>  
> +	prefetchw((const void *)&rw->lock);
>  	__asm__ __volatile__(
>  "	ldrex	%0, [%2]\n"
>  "	adds	%0, %0, #1\n"
> -- 
> 1.8.2.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From nicolas.pitre at linaro.org  Tue Jul 23 16:12:57 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Jul 2013 16:12:57 -0400 (EDT)
Subject: [PATCH 5/6] ARM: atomics: prefetch the destination word for
 write prior to strex
In-Reply-To: <1374579389-32704-6-git-send-email-will.deacon@arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-6-git-send-email-will.deacon@arm.com>
Message-ID: <alpine.LFD.2.03.1307231611550.15022@syhkavp.arg>

On Tue, 23 Jul 2013, Will Deacon wrote:

> The cost of changing a cacheline from shared to exclusive state can be
> significant, especially when this is triggered by an exclusive store,
> since it may result in having to retry the transaction.
> 
> This patch prefixes our atomic access implementations with pldw
> instructions (on CPUs which support them) to try and grab the line in
> exclusive state from the start. Only the barrier-less functions are
> updated, since memory barriers can limit the usefulness of prefetching
> data.
> 
> Signed-off-by: Will Deacon <will.deacon at arm.com>
> ---
>  arch/arm/include/asm/atomic.h | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
> index da1c77d..e3f052a 100644
> --- a/arch/arm/include/asm/atomic.h
> +++ b/arch/arm/include/asm/atomic.h
> @@ -12,6 +12,7 @@
>  #define __ASM_ARM_ATOMIC_H
>  
>  #include <linux/compiler.h>
> +#include <linux/prefetch.h>
>  #include <linux/types.h>
>  #include <linux/irqflags.h>
>  #include <asm/barrier.h>
> @@ -41,6 +42,7 @@ static inline void atomic_add(int i, atomic_t *v)
>  	unsigned long tmp;
>  	int result;
>  
> +	prefetchw((const void *)&v->counter);

Same comment as for the previous patch wrt the cast.  Even more so given 
it is spreading all over the place now.






>  	__asm__ __volatile__("@ atomic_add\n"
>  "1:	ldrex	%0, [%3]\n"
>  "	add	%0, %0, %4\n"
> @@ -79,6 +81,7 @@ static inline void atomic_sub(int i, atomic_t *v)
>  	unsigned long tmp;
>  	int result;
>  
> +	prefetchw((const void *)&v->counter);
>  	__asm__ __volatile__("@ atomic_sub\n"
>  "1:	ldrex	%0, [%3]\n"
>  "	sub	%0, %0, %4\n"
> @@ -138,6 +141,7 @@ static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
>  {
>  	unsigned long tmp, tmp2;
>  
> +	prefetchw((const void *)addr);
>  	__asm__ __volatile__("@ atomic_clear_mask\n"
>  "1:	ldrex	%0, [%3]\n"
>  "	bic	%0, %0, %4\n"
> @@ -283,6 +287,7 @@ static inline void atomic64_set(atomic64_t *v, u64 i)
>  {
>  	u64 tmp;
>  
> +	prefetchw((const void *)&v->counter);
>  	__asm__ __volatile__("@ atomic64_set\n"
>  "1:	ldrexd	%0, %H0, [%2]\n"
>  "	strexd	%0, %3, %H3, [%2]\n"
> @@ -299,6 +304,7 @@ static inline void atomic64_add(u64 i, atomic64_t *v)
>  	u64 result;
>  	unsigned long tmp;
>  
> +	prefetchw((const void *)&v->counter);
>  	__asm__ __volatile__("@ atomic64_add\n"
>  "1:	ldrexd	%0, %H0, [%3]\n"
>  "	adds	%0, %0, %4\n"
> @@ -339,6 +345,7 @@ static inline void atomic64_sub(u64 i, atomic64_t *v)
>  	u64 result;
>  	unsigned long tmp;
>  
> +	prefetchw((const void *)&v->counter);
>  	__asm__ __volatile__("@ atomic64_sub\n"
>  "1:	ldrexd	%0, %H0, [%3]\n"
>  "	subs	%0, %0, %4\n"
> -- 
> 1.8.2.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From vivien.didelot at savoirfairelinux.com  Tue Jul 23 16:13:02 2013
From: vivien.didelot at savoirfairelinux.com (Vivien Didelot)
Date: Tue, 23 Jul 2013 16:13:02 -0400
Subject: [RFC] ARM: davinci: da850: add a few pinmux definitions
Message-ID: <1374610382-11204-1-git-send-email-vivien.didelot@savoirfairelinux.com>

This patch adds some pinmux definitions that we needed, such as SPI0,
SPI1 and some GPIO.

Note: I sent the patch as an RFC because I would like a confirmation for the
appropriate name for SPI*_SCS* and EMA_A_RW pinmuxes.

Signed-off-by: Vivien Didelot <vivien.didelot at savoirfairelinux.com>
---
 arch/arm/mach-davinci/da850.c            | 77 ++++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/mux.h | 80 ++++++++++++++++++++++++++++++++
 2 files changed, 157 insertions(+)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index a0d4f60..adefc17 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -504,6 +504,30 @@ static const struct mux_config da850_pins[] = {
 	/* I2C0 function */
 	MUX_CFG(DA850, I2C0_SDA,	4,	12,	15,	2,	false)
 	MUX_CFG(DA850, I2C0_SCL,	4,	8,	15,	2,	false)
+	/* SPI0 function */
+	MUX_CFG(DA850, SPI0_CLK,	3,	0,	15,	1,	false)
+	MUX_CFG(DA850, SPI0_ENA,	3,	4,	15,	1,	false)
+	MUX_CFG(DA850, SPI0_SOMI,	3,	8,	15,	1,	false)
+	MUX_CFG(DA850, SPI0_SIMO,	3,	12,	15,	1,	false)
+	MUX_CFG(DA850, SPI0_SCS0,	4,	4,	15,	1,	false)
+	MUX_CFG(DA850, SPI0_SCS1,	4,	0,	15,	1,	false)
+	MUX_CFG(DA850, SPI0_SCS2,	3,	28,	15,	1,	false)
+	MUX_CFG(DA850, SPI0_SCS3,	3,	24,	15,	1,	false)
+	MUX_CFG(DA850, SPI0_SCS4,	3,	20,	15,	1,	false)
+	MUX_CFG(DA850, SPI0_SCS5,	3,	16,	15,	1,	false)
+	/* SPI1 function */
+	MUX_CFG(DA850, SPI1_CLK,	5,	8,	15,	1,	false)
+	MUX_CFG(DA850, SPI1_ENA,	5,	12,	15,	1,	false)
+	MUX_CFG(DA850, SPI1_SOMI,	5,	16,	15,	1,	false)
+	MUX_CFG(DA850, SPI1_SIMO,	5,	20,	15,	1,	false)
+	MUX_CFG(DA850, SPI1_SCS0,	5,	4,	15,	1,	false)
+	MUX_CFG(DA850, SPI1_SCS1,	5,	0,	15,	1,	false)
+	MUX_CFG(DA850, SPI1_SCS2,	4,	28,	15,	1,	false)
+	MUX_CFG(DA850, SPI1_SCS3,	4,	24,	15,	1,	false)
+	MUX_CFG(DA850, SPI1_SCS4,	4,	20,	15,	1,	false)
+	MUX_CFG(DA850, SPI1_SCS5,	4,	16,	15,	1,	false)
+	MUX_CFG(DA850, SPI1_SCS6,	4,	12,	15,	1,	false)
+	MUX_CFG(DA850, SPI1_SCS7,	4,	8,	15,	1,	false)
 	/* EMAC function */
 	MUX_CFG(DA850, MII_TXEN,	2,	4,	15,	8,	false)
 	MUX_CFG(DA850, MII_TXCLK,	2,	8,	15,	8,	false)
@@ -604,6 +628,7 @@ static const struct mux_config da850_pins[] = {
 	MUX_CFG(DA850, NEMA_CS_4,	7,	8,	15,	1,	false)
 	MUX_CFG(DA850, NEMA_WE,		7,	16,	15,	1,	false)
 	MUX_CFG(DA850, NEMA_OE,		7,	20,	15,	1,	false)
+	MUX_CFG(DA850, EMA_A_RW,	7,	24,	15,	1,	false)
 	MUX_CFG(DA850, EMA_A_0,		12,	28,	15,	1,	false)
 	MUX_CFG(DA850, EMA_A_3,		12,	16,	15,	1,	false)
 	MUX_CFG(DA850, EMA_A_4,		12,	12,	15,	1,	false)
@@ -639,17 +664,69 @@ static const struct mux_config da850_pins[] = {
 	MUX_CFG(DA850, EMA_WAIT_1,	6,	24,	15,	1,	false)
 	MUX_CFG(DA850, NEMA_CS_2,	7,	0,	15,	1,	false)
 	/* GPIO function */
+	MUX_CFG(DA850, GPIO0_1,		1,	24,	15,	8,	false)
+	MUX_CFG(DA850, GPIO0_2,		1,	20,	15,	8,	false)
+	MUX_CFG(DA850, GPIO0_3,		1,	16,	15,	8,	false)
+	MUX_CFG(DA850, GPIO0_4,		1,	12,	15,	8,	false)
+	MUX_CFG(DA850, GPIO0_5,		1,	8,	15,	8,	false)
+	MUX_CFG(DA850, GPIO0_6,		1,	4,	15,	8,	false)
+	MUX_CFG(DA850, GPIO0_13,	0,	8,	15,	8,	false)
+	MUX_CFG(DA850, GPIO0_15,	0,	0,	15,	8,	false)
+	MUX_CFG(DA850, GPIO1_8,		3,	0,	15,	4,	false)
+	MUX_CFG(DA850, GPIO1_12,	2,	12,	15,	4,	false)
+	MUX_CFG(DA850, GPIO1_14,	2,	4,	15,	4,	false)
+	MUX_CFG(DA850, GPIO2_3,		6,	16,	15,	8,	false)
 	MUX_CFG(DA850, GPIO2_4,		6,	12,	15,	8,	false)
 	MUX_CFG(DA850, GPIO2_6,		6,	4,	15,	8,	false)
+	MUX_CFG(DA850, GPIO2_7,		6,	0,	15,	8,	false)
 	MUX_CFG(DA850, GPIO2_8,		5,	28,	15,	8,	false)
+	MUX_CFG(DA850, GPIO2_9,		5,	24,	15,	8,	false)
 	MUX_CFG(DA850, GPIO2_15,	5,	0,	15,	8,	false)
+	MUX_CFG(DA850, GPIO3_0,		8,	28,	15,	8,	false)
+	MUX_CFG(DA850, GPIO3_1,		8,	24,	15,	8,	false)
+	MUX_CFG(DA850, GPIO3_2,		8,	20,	15,	8,	false)
+	MUX_CFG(DA850, GPIO3_3,		8,	16,	15,	8,	false)
+	MUX_CFG(DA850, GPIO3_4,		8,	12,	15,	8,	false)
+	MUX_CFG(DA850, GPIO3_5,		8,	8,	15,	8,	false)
+	MUX_CFG(DA850, GPIO3_6,		8,	4,	15,	8,	false)
+	MUX_CFG(DA850, GPIO3_7,		8,	0,	15,	8,	false)
+	MUX_CFG(DA850, GPIO3_8,		7,	28,	15,	8,	false)
 	MUX_CFG(DA850, GPIO3_12,	7,	12,	15,	8,	false)
 	MUX_CFG(DA850, GPIO3_13,	7,	8,	15,	8,	false)
 	MUX_CFG(DA850, GPIO4_0,		10,	28,	15,	8,	false)
 	MUX_CFG(DA850, GPIO4_1,		10,	24,	15,	8,	false)
+	MUX_CFG(DA850, GPIO4_2,		10,	20,	15,	8,	false)
+	MUX_CFG(DA850, GPIO4_3,		10,	16,	15,	8,	false)
+	MUX_CFG(DA850, GPIO4_4,		10,	12,	15,	8,	false)
+	MUX_CFG(DA850, GPIO4_5,		10,	8,	15,	8,	false)
+	MUX_CFG(DA850, GPIO4_6,		10,	4,	15,	8,	false)
+	MUX_CFG(DA850, GPIO4_7,		10,	0,	15,	8,	false)
+	MUX_CFG(DA850, GPIO4_8,		9,	28,	15,	8,	false)
+	MUX_CFG(DA850, GPIO4_9,		9,	24,	15,	8,	false)
+	MUX_CFG(DA850, GPIO4_10,	9,	20,	15,	8,	false)
+	MUX_CFG(DA850, GPIO4_11,	9,	16,	15,	8,	false)
+	MUX_CFG(DA850, GPIO4_12,	9,	12,	15,	8,	false)
+	MUX_CFG(DA850, GPIO4_13,	9,	8,	15,	8,	false)
+	MUX_CFG(DA850, GPIO4_14,	9,	4,	15,	8,	false)
+	MUX_CFG(DA850, GPIO4_15,	9,	0,	15,	8,	false)
+	MUX_CFG(DA850, GPIO5_0,		12,	28,	15,	8,	false)
+	MUX_CFG(DA850, GPIO5_2,		12,	20,	15,	8,	false)
+	MUX_CFG(DA850, GPIO5_3,		12,	16,	15,	8,	false)
+	MUX_CFG(DA850, GPIO5_4,		12,	12,	15,	8,	false)
+	MUX_CFG(DA850, GPIO5_5,		12,	8,	15,	8,	false)
+	MUX_CFG(DA850, GPIO5_6,		12,	4,	15,	8,	false)
+	MUX_CFG(DA850, GPIO6_0,		19,	24,	15,	8,	false)
+	MUX_CFG(DA850, GPIO6_1,		19,	20,	15,	8,	false)
 	MUX_CFG(DA850, GPIO6_9,		13,	24,	15,	8,	false)
 	MUX_CFG(DA850, GPIO6_10,	13,	20,	15,	8,	false)
+	MUX_CFG(DA850, GPIO6_11,	13,	16,	15,	8,	false)
 	MUX_CFG(DA850, GPIO6_13,	13,	8,	15,	8,	false)
+	MUX_CFG(DA850, GPIO6_15,	13,	 0,	15,	8,	false)
+	MUX_CFG(DA850, GPIO8_5,		3,	12,	15,	4,	false)
+	MUX_CFG(DA850, GPIO8_6,		3,	 8,	15,	4,	false)
+	MUX_CFG(DA850, GPIO8_11,	18,	24,	15,	8,	false)
+	MUX_CFG(DA850, GPIO8_12,	18,	20,	15,	8,	false)
+	MUX_CFG(DA850, GPIO8_13,	18,	16,	15,	8,	false)
 	MUX_CFG(DA850, RTC_ALARM,	0,	28,	15,	2,	false)
 	/* VPIF Capture */
 	MUX_CFG(DA850, VPIF_DIN0,	15,	4,	15,	1,	false)
diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
index 9e95b8a..af5b34d 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -775,6 +775,32 @@ enum davinci_da850_index {
 	DA850_I2C0_SDA,
 	DA850_I2C0_SCL,
 
+	/* SPI0 function */
+	DA850_SPI0_CLK,
+	DA850_SPI0_ENA,
+	DA850_SPI0_SOMI,
+	DA850_SPI0_SIMO,
+	DA850_SPI0_SCS0,
+	DA850_SPI0_SCS1,
+	DA850_SPI0_SCS2,
+	DA850_SPI0_SCS3,
+	DA850_SPI0_SCS4,
+	DA850_SPI0_SCS5,
+
+	/* SPI1 function */
+	DA850_SPI1_CLK,
+	DA850_SPI1_ENA,
+	DA850_SPI1_SOMI,
+	DA850_SPI1_SIMO,
+	DA850_SPI1_SCS0,
+	DA850_SPI1_SCS1,
+	DA850_SPI1_SCS2,
+	DA850_SPI1_SCS3,
+	DA850_SPI1_SCS4,
+	DA850_SPI1_SCS5,
+	DA850_SPI1_SCS6,
+	DA850_SPI1_SCS7,
+
 	/* EMAC function */
 	DA850_MII_TXEN,
 	DA850_MII_TXCLK,
@@ -880,6 +906,7 @@ enum davinci_da850_index {
 	DA850_NEMA_CS_4,
 	DA850_NEMA_WE,
 	DA850_NEMA_OE,
+	DA850_EMA_A_RW,
 	DA850_EMA_D_15,
 	DA850_EMA_D_14,
 	DA850_EMA_D_13,
@@ -916,17 +943,70 @@ enum davinci_da850_index {
 	DA850_NEMA_CS_2,
 
 	/* GPIO function */
+	DA850_GPIO0_1,
+	DA850_GPIO0_2,
+	DA850_GPIO0_3,
+	DA850_GPIO0_4,
+	DA850_GPIO0_5,
+	DA850_GPIO0_6,
+	DA850_GPIO0_13,
+	DA850_GPIO0_15,
+	DA850_GPIO1_8,
+	DA850_GPIO1_12,
+	DA850_GPIO1_14,
+	DA850_GPIO2_3,
 	DA850_GPIO2_4,
 	DA850_GPIO2_6,
+	DA850_GPIO2_7,
 	DA850_GPIO2_8,
+	DA850_GPIO2_9,
 	DA850_GPIO2_15,
+	DA850_GPIO3_0,
+	DA850_GPIO3_1,
+	DA850_GPIO3_2,
+	DA850_GPIO3_3,
+	DA850_GPIO3_4,
+	DA850_GPIO3_5,
+	DA850_GPIO3_6,
+	DA850_GPIO3_7,
+	DA850_GPIO3_8,
 	DA850_GPIO3_12,
 	DA850_GPIO3_13,
 	DA850_GPIO4_0,
 	DA850_GPIO4_1,
+	DA850_GPIO4_2,
+	DA850_GPIO4_3,
+	DA850_GPIO4_4,
+	DA850_GPIO4_5,
+	DA850_GPIO4_6,
+	DA850_GPIO4_7,
+	DA850_GPIO4_8,
+	DA850_GPIO4_9,
+	DA850_GPIO4_10,
+	DA850_GPIO4_11,
+	DA850_GPIO4_12,
+	DA850_GPIO4_13,
+	DA850_GPIO4_14,
+	DA850_GPIO4_15,
+	DA850_GPIO5_0,
+	DA850_GPIO5_2,
+	DA850_GPIO5_3,
+	DA850_GPIO5_4,
+	DA850_GPIO5_5,
+	DA850_GPIO5_6,
+	DA850_GPIO6_0,
+	DA850_GPIO6_1,
 	DA850_GPIO6_9,
 	DA850_GPIO6_10,
+	DA850_GPIO6_11,
 	DA850_GPIO6_13,
+	DA850_GPIO6_15,
+	DA850_GPIO7_8,
+	DA850_GPIO8_5,
+	DA850_GPIO8_6,
+	DA850_GPIO8_11,
+	DA850_GPIO8_12,
+	DA850_GPIO8_13,
 	DA850_RTC_ALARM,
 
 	/* VPIF Capture */
-- 
1.8.3.3



From nicolas.pitre at linaro.org  Tue Jul 23 16:15:59 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Jul 2013 16:15:59 -0400 (EDT)
Subject: [PATCH 6/6] ARM: bitops: prefetch the destination word for write
 prior to strex
In-Reply-To: <1374579389-32704-7-git-send-email-will.deacon@arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-7-git-send-email-will.deacon@arm.com>
Message-ID: <alpine.LFD.2.03.1307231615370.15022@syhkavp.arg>

On Tue, 23 Jul 2013, Will Deacon wrote:

> The cost of changing a cacheline from shared to exclusive state can be
> significant, especially when this is triggered by an exclusive store,
> since it may result in having to retry the transaction.
> 
> This patch prefixes our atomic bitops implementation with prefetchw,
> to try and grab the line in exclusive state from the start. The testop
> macro is left alone, since the barrier semantics limit the usefulness
> of prefetching data.
> 
> Signed-off-by: Will Deacon <will.deacon at arm.com>

Acked-by: Nicolas Pitre <nico at linaro.org>

> ---
>  arch/arm/lib/bitops.h | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
> index d6408d1..e0c68d5 100644
> --- a/arch/arm/lib/bitops.h
> +++ b/arch/arm/lib/bitops.h
> @@ -10,6 +10,11 @@ UNWIND(	.fnstart	)
>  	and	r3, r0, #31		@ Get bit offset
>  	mov	r0, r0, lsr #5
>  	add	r1, r1, r0, lsl #2	@ Get word offset
> +#if __LINUX_ARM_ARCH__ >= 7
> +	.arch_extension	mp
> +	ALT_SMP(W(pldw)	[r1])
> +	ALT_UP(W(nop))
> +#endif
>  	mov	r3, r2, lsl r3
>  1:	ldrex	r2, [r1]
>  	\instr	r2, r2, r3
> -- 
> 1.8.2.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From tomasz.figa at gmail.com  Tue Jul 23 16:20:53 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 22:20:53 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <Pine.LNX.4.44L0.1307231518310.1304-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307231518310.1304-100000@iolanthe.rowland.org>
Message-ID: <1387574.Tkg16KearS@flatron>

On Tuesday 23 of July 2013 15:36:00 Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > IMHO it would be better if you provided some code example, but let's
> > try to check if I understood you correctly.
> > 
> > 8><-------------------------------------------------------------------
> > -----
> > 
> > [Board file]
> > 
> > static struct phy my_phy;
> > 
> > static struct platform_device phy_pdev = {
> > 
> > 	/* ... */
> > 	.platform_data = &my_phy;
> > 	/* ... */
> > 
> > };
> > 
> > static struct platform_device phy_pdev = {
> 
> This should be controller_pdev, not phy_pdev, yes?

Right. A copy-pasto.

> 
> > 	/* ... */
> > 	.platform_data = &my_phy;
> > 	/* ... */
> > 
> > };
> > 
> > [Provider driver]
> > 
> > struct phy *phy = pdev->dev.platform_data;
> > 
> > ret = phy_create(phy);
> > 
> > [Consumer driver]
> > 
> > struct phy *phy = pdev->dev.platform_data;
> > 
> > ret = phy_get(&pdev->dev, phy);
> 
> Or even just phy_get(&pdev->dev), because phy_get() could be smart
> enough to to set phy = dev->platform_data.

Unless you need more than one PHY in this driver...

> 
> > ----------------------------------------------------------------------
> > --><8
> > 
> > Is this what you mean?
> 
> That's what I was going to suggest too.  The struct phy is defined in
> the board file, which already knows about all the PHYs that exist in
> the system.  (Or perhaps it is allocated dynamically, so that when many
> board files are present in the same kernel, only the entries listed in
> the board file for the current system get created.) 

Well, such dynamic allocation is a must. We don't accept non-multiplatform 
aware code anymore, not even saying about multiboard.

> Then the
> structure's address is stored in the platform data and made available
> to both the provider and the consumer.

Yes, technically this can work. You would still have to perform some kind 
of synchronization to make sure that the PHY bound to this structure is 
actually present. This is again technically doable (e.g. a list of 
registered struct phys inside PHY core).

> Even though the struct phy is defined (or allocated) in the board file,
> its contents don't get filled in until the PHY driver provides the
> details.

You can't assure this. Board file is free to do whatever it wants with 
this struct. A clean solution would prevent this.

> > It's technically correct, but quality of this solution isn't really
> > nice, because it's a layering violation (at least if I understood
> > what you mean). This is because you need to have full definition of
> > struct phy in board file and a structure that is used as private data
> > in PHY core comes from platform code.
> 
> You don't have to have a full definition in the board file.  Just a
> partial definition -- most of the contents can be filled in later, when
> the PHY driver is ready to store the private data.
> 
> It's not a layering violation for one region of the kernel to store
> private data in a structure defined by another part of the kernel.
> This happens all the time (e.g., dev_set_drvdata).

Not really. The phy struct is something that _is_ private data of PHY 
subsystem, not something that can store private data of PHY subsystem 
(sure it can store private data of particular PHY driver, but that's 
another story) and only PHY subsystem should have access to its contents.

By the way, we need to consider other cases here as well, for example it 
would be nice to have a single phy_get() function that works for both non-
DT and DT cases to make the consumer driver not have to worry whether it's 
being probed from DT or not.

I'd suggest simply reusing the lookup method of regulator framework, just 
as I suggested here:

http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=101661

Best regards,
Tomasz



From tomasz.figa at gmail.com  Tue Jul 23 16:46:53 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 22:46:53 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130723180414.GA9630@kroah.com>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <19656720.FrnhefyPXl@amdc1227> <20130723180414.GA9630@kroah.com>
Message-ID: <5349166.Wm3v7zlK1Z@flatron>

On Tuesday 23 of July 2013 11:04:14 Greg KH wrote:
> On Tue, Jul 23, 2013 at 07:48:11PM +0200, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
> > > On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
> > > > > Ick, no.  Why can't you just pass the pointer to the phy itself?
> > > > >  If
> > > > > you
> > > > > had a "priv" pointer to search from, then you could have just
> > > > > passed
> > > > > the
> > > > > original phy pointer in the first place, right?
> > > > 
> > > > IMHO it would be better if you provided some code example, but
> > > > let's
> > > > try to check if I understood you correctly.
> > > 
> > > It's not my code that I want to have added, so I don't have to write
> > > examples, I just get to complain about the existing stuff :)
> > 
> > Still, I think that some small code snippets illustrating the idea are
> > really helpful.
> > 
> > > > 8><---------------------------------------------------------------
> > > > -----
> > > > ----
> > > > 
> > > > [Board file]
> > > > 
> > > > static struct phy my_phy;
> > > > 
> > > > static struct platform_device phy_pdev = {
> > > > 
> > > > 	/* ... */
> > > > 	.platform_data = &my_phy;
> > > > 	/* ... */
> > > > 
> > > > };
> > > > 
> > > > static struct platform_device phy_pdev = {
> > > > 
> > > > 	/* ... */
> > > > 	.platform_data = &my_phy;
> > > > 	/* ... */
> > > > 
> > > > };
> > > > 
> > > > [Provider driver]
> > > > 
> > > > struct phy *phy = pdev->dev.platform_data;
> > > > 
> > > > ret = phy_create(phy);
> > > > 
> > > > [Consumer driver]
> > > > 
> > > > struct phy *phy = pdev->dev.platform_data;
> > > > 
> > > > ret = phy_get(&pdev->dev, phy);
> > > > 
> > > > ------------------------------------------------------------------
> > > > -----
> > > > -><8
> > > > 
> > > > Is this what you mean?
> > > 
> > > No.  Well, kind of.  What's wrong with using the platform data
> > > structure unique to the board to have the pointer?
> > > 
> > > For example (just randomly picking one), the ata-pxa driver would
> > > change include/linux/platform_data/ata-pxa.h to have a phy pointer
> > > in it:
> > > 
> > > struct phy;
> > > 
> > > struct  pata_pxa_pdata {
> > > 
> > > 	/* PXA DMA DREQ<0:2> pin */
> > > 	uint32_t	dma_dreq;
> > > 	/* Register shift */
> > > 	uint32_t	reg_shift;
> > > 	/* IRQ flags */
> > > 	uint32_t	irq_flags;
> > > 	/* PHY */
> > > 	struct phy	*phy;
> > > 
> > > };
> > > 
> > > Then, when you create the platform, set the phy* pointer with a call
> > > to
> > > phy_create().  Then you can use that pointer wherever that plaform
> > > data
> > > is available (i.e. whereever platform_data is at).
> > 
> > Hmm? So, do you suggest to call phy_create() from board file? What
> > phy_ops struct and other hardware parameters would it take?
> > 
> > > > > The issue is that a string "name" is not going to scale at all,
> > > > > as it
> > > > > requires hard-coded information that will change over time (as
> > > > > the
> > > > > existing clock interface is already showing.)
> > > > 
> > > > I fully agree that a simple, single string will not scale even in
> > > > some,
> > > > not so uncommon cases, but there is already a lot of existing
> > > > lookup
> > > > solutions over the kernel and so there is no point in introducing
> > > > another one.
> > > 
> > > I'm trying to get _rid_ of lookup "solutions" and just use a real
> > > pointer, as you should.  I'll go tackle those other ones after this
> > > one
> > > is taken care of, to show how the others should be handled as well.
> > 
> > There was a reason for introducing lookup solutions. The reason was
> > that in board file there is no way to get a pointer to something that
> > is going to be created much later in time. We don't do time travel
> > ;-).
> > 
> > > > > Please just pass the real "phy" pointer around, that's what it
> > > > > is
> > > > > there
> > > > > for.  Your "board binding" logic/code should be able to handle
> > > > > this,
> > > > > as
> > > > > it somehow was going to do the same thing with a "name".
> > > > 
> > > > It's technically correct, but quality of this solution isn't
> > > > really
> > > > nice, because it's a layering violation (at least if I understood
> > > > what
> > > > you mean). This is because you need to have full definition of
> > > > struct
> > > > phy in board file and a structure that is used as private data in
> > > > PHY
> > > > core comes from platform code.
> > > 
> > > No, just a pointer, you don't need the "full" structure until you
> > > get to some .c code that actually manipulates the phy itself, for
> > > all other places, you are just dealing with a pointer and a
> > > structure you never reference.
> > > 
> > > Does that make more sense?
> > 
> > Well, to the point that I think I now understood your suggestion.
> > Unfortunately the suggestion alone isn't really something that can be
> > done, considering how driver core and generic frameworks work.
> 
> Ok, given that I seem to be totally confused as to exactly how the
> board-specific frameworks work, I'll take your word for it.

Well, they are working in a way that keeps separation of layers, making 
things clean. Platform code should not (well, there might exist some in 
tree hacks, but this should not be propagated) used to exchange data 
between drivers, but rather to specify board specific parameters for 
generic drivers. If drivers need to cooperate, there must be a dedicated 
interface for this, like the PHY framework Kishon is introducing here.

Sure, with platform code you can do a lot of hacky things, for example you 
can simply provide PHY callbacks inside platform_data, like it was being 
done historically, but that's just ugly.

Anyway, board files should now be rather considered a historical thing. We 
are moving towards full DT-based description on ARM systems and so board 
files and related things, like name-based lookups, statically registered 
platform devices and so one are going away. Device Tree handles such 
provider-consumer links automatically using specifiers with phandles and 
lookup by node + provider-specific specifier args, so all the problems 
with binding things together just go away.

> But again, I will not accept "lookup by name" type solutions, when the
> "name" is dynamic and will change.  Because you are using a "name", you
> can deal with a pointer, putting it _somewhere_ in your board-specific
> data structures, as you are going to need to store it anyway (hint, you
> had to get that "name" from somewhere, right?)

Yes. This kind of artificial names passed to both provider and consumer 
isn't really a good way of lookup. This is just an example of bad lookup 
key, though. IMHO for a good example of lookup you should see regulator 
framework.

> And maybe the way that these "generic frameworks" are created is wrong,
> given that you don't feel that a generic pointer can be passed to the
> needed devices.  That seems like a huge problem, one that has already
> been pointed out is causing issues with other subsystems.

What problem are you talking about here? AFAIK frameworks using correctly 
designed lookup do work fine for most, if not all, people. See the 
regulator framework.

> So maybe they need to be fixed?

I don't really think anything is broken here, so there is nothing to fix.

Best regards,
Tomasz



From gregkh at linuxfoundation.org  Tue Jul 23 16:50:07 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 23 Jul 2013 13:50:07 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <1731726.KENstTPhkb@flatron>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <20130723193105.GP9858@sirena.org.uk>
 <20130723194423.GA22984@kroah.com> <1731726.KENstTPhkb@flatron>
Message-ID: <20130723205007.GA27166@kroah.com>

On Tue, Jul 23, 2013 at 10:07:52PM +0200, Tomasz Figa wrote:
> On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
> > On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
> > > > You don't "know" the id of the device you are looking up, due to
> > > > multiple devices being in the system (dynamic ids, look back earlier
> > > > in
> > > > this thread for details about that.)
> > > 
> > > I got copied in very late so don't have most of the thread I'm afraid,
> > > I did try looking at web archives but didn't see a clear problem
> > > statement.  In any case this is why the APIs doing lookups do the
> > > lookups in the context of the requesting device - devices ask for
> > > whatever name they use locally.
> > 
> > What do you mean by "locally"?
> > 
> > The problem with the api was that the phy core wanted a id and a name to
> > create a phy, and then later other code was doing a "lookup" based on
> > the name and id (mushed together), because it "knew" that this device
> > was the one it wanted.
> > 
> > Just like the clock api, which, for multiple devices, has proven to
> > cause problems.  I don't want to see us accept an api that we know has
> > issues in it now, I'd rather us fix it up properly.
> > 
> > Subsystems should be able to create ids how ever they want to, and not
> > rely on the code calling them to specify the names of the devices that
> > way, otherwise the api is just too fragile.
> > 
> > I think, that if you create a device, then just carry around the pointer
> > to that device (in this case a phy) and pass it to whatever other code
> > needs it.  No need to do lookups on "known names" or anything else,
> > just normal pointers, with no problems for multiple devices, busses, or
> > naming issues.
> 
> PHY object is not a device, it is something that a device driver creates 
> (one or more instances of) when it is being probed.

But you created a 'struct device' for it, so I think of it as a "device"
be it "virtual" or "real" :)

> You don't have a clean way to export this PHY object to other driver,
> other than keeping this PHY on a list inside PHY core with some
> well-known ID (e.g. device name + consumer port name/index, like in
> regulator core) and then to use this well-known ID inside consumer
> driver as a lookup key passed to phy_get();
> 
> Actually I think for PHY case, exactly the same way as used for
> regulators might be completely fine:
> 
> 1. Each PHY would have some kind of platform, non-unique name, that is 
> just used to print some messages (like the platform/board name of a 
> regulator).
> 2. Each PHY would have an array of consumers. Consumer specifier would 
> consist of consumer device name and consumer port name - just like in 
> regulator subsystem.
> 3. PHY driver receives an array of, let's say, phy_init_data inside its 
> platform data that it would use to register its PHYs.
> 4. Consumer drivers would have constant consumer port names and wouldn't 
> receive any information about PHYs from platform code.
> 
> Code example:
> 
> [Board file]
> 
> static const struct phy_consumer_data usb_20_phy0_consumers[] = {
> 	{
> 		.devname = "foo-ehci",
> 		.port = "usbphy",
> 	},
> };
> 
> static const struct phy_consumer_data usb_20_phy1_consumers[] = {
> 	{
> 		.devname = "foo-otg",
> 		.port = "otgphy",
> 	},
> };
> 
> static const struct phy_init_data my_phys[] = {
> 	{
> 		.name = "USB 2.0 PHY 0",
> 		.consumers = usb_20_phy0_consumers,
> 		.num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
> 	},
> 	{
> 		.name = "USB 2.0 PHY 1",
> 		.consumers = usb_20_phy1_consumers,
> 		.num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
> 	},
> 	{ }
> };
> 
> static const struct platform_device usb_phy_pdev = {
> 	.name = "foo-usbphy",
> 	.id = -1,
> 	.dev = {
> 		.platform_data = my_phys,
> 	},
> };
> 
> [PHY driver]
> 
> static int foo_usbphy_probe(pdev)
> {
> 	struct foo_usbphy *foo;
> 	struct phy_init_data *init_data = pdev->dev.platform_data;
> 	/* ... */
> 	// for each PHY in init_data {
> 		phy_register(&foo->phy[i], &init_data[i]);
> 	// }
> 	/* ... */
> }
> 
> [EHCI driver]
> 
> static int foo_ehci_probe(pdev)
> {
> 	struct phy *phy;
> 	/* ... */
> 	phy = phy_get(&pdev->dev, "usbphy");
> 	/* ... */
> }
> 
> [OTG driver]
> 
> static int foo_otg_probe(pdev)
> {
> 	struct phy *phy;
> 	/* ... */
> 	phy = phy_get(&pdev->dev, "otgphy");
> 	/* ... */
> }

That's not so bad, as long as you let the phy core use whatever name it
wants for the device when it registers it with sysfs.  Use the name you
are requesting as a "tag" or some such "hint" as to what the phy can be
looked up by.

Good luck handling duplicate "tags" :)

thanks,

greg k-h


From stern at rowland.harvard.edu  Tue Jul 23 16:53:55 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 23 Jul 2013 16:53:55 -0400 (EDT)
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <1387574.Tkg16KearS@flatron>
Message-ID: <Pine.LNX.4.44L0.1307231632580.1304-100000@iolanthe.rowland.org>

On Tue, 23 Jul 2013, Tomasz Figa wrote:

> > That's what I was going to suggest too.  The struct phy is defined in
> > the board file, which already knows about all the PHYs that exist in
> > the system.  (Or perhaps it is allocated dynamically, so that when many
> > board files are present in the same kernel, only the entries listed in
> > the board file for the current system get created.) 
> 
> Well, such dynamic allocation is a must. We don't accept non-multiplatform 
> aware code anymore, not even saying about multiboard.
> 
> > Then the
> > structure's address is stored in the platform data and made available
> > to both the provider and the consumer.
> 
> Yes, technically this can work. You would still have to perform some kind 
> of synchronization to make sure that the PHY bound to this structure is 
> actually present. This is again technically doable (e.g. a list of 
> registered struct phys inside PHY core).

The synchronization takes place inside phy_get.  If phy_create hasn't
been called for this structure by the time phy_get runs, phy_get will 
return an error.

> > Even though the struct phy is defined (or allocated) in the board file,
> > its contents don't get filled in until the PHY driver provides the
> > details.
> 
> You can't assure this. Board file is free to do whatever it wants with 
> this struct. A clean solution would prevent this.

I'm not sure what you mean here.  Of course I can't prevent a board 
file from messing up a data structure.  I can't prevent it from causing 
memory access violations either; in fact, I can't prevent any bugs in 
other people's code.

Besides, why do you say the board file is free to do whatever it wants 
with the struct phy?  Currently the struct phy is created by the PHY 
provider and the PHY core, right?  It's not even mentioned in the board 
file.

> > > It's technically correct, but quality of this solution isn't really
> > > nice, because it's a layering violation (at least if I understood
> > > what you mean). This is because you need to have full definition of
> > > struct phy in board file and a structure that is used as private data
> > > in PHY core comes from platform code.
> > 
> > You don't have to have a full definition in the board file.  Just a
> > partial definition -- most of the contents can be filled in later, when
> > the PHY driver is ready to store the private data.
> > 
> > It's not a layering violation for one region of the kernel to store
> > private data in a structure defined by another part of the kernel.
> > This happens all the time (e.g., dev_set_drvdata).
> 
> Not really. The phy struct is something that _is_ private data of PHY 
> subsystem, not something that can store private data of PHY subsystem 
> (sure it can store private data of particular PHY driver, but that's 
> another story) and only PHY subsystem should have access to its contents.

If you want to keep the phy struct completely separate from the board
file, there's an easy way to do it.  Let's say the board file knows
about N different PHYs in the system.  Then you define an array of N
pointers to phys:

struct phy *(phy_address[N]);

In the platform data for both PHY j and its controller, store
&phy_address[j].  The PHY provider passes this cookie to phy_create:

	cookie = pdev->dev.platform_data;
	ret = phy_create(phy, cookie);

and phy_create simply stores: *cookie = phy.  The PHY consumer does
much the same the same thing:

	cookie = pdev->dev.platform_data;
	phy = phy_get(cookie);

phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise.

> By the way, we need to consider other cases here as well, for example it 
> would be nice to have a single phy_get() function that works for both non-
> DT and DT cases to make the consumer driver not have to worry whether it's 
> being probed from DT or not.

You ought to be able to adapt this scheme to work with DT.  Maybe by 
having multiple "phy_address" arrays.

Alan Stern



From tomasz.figa at gmail.com  Tue Jul 23 17:02:57 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 23:02:57 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <Pine.LNX.4.44L0.1307231632580.1304-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307231632580.1304-100000@iolanthe.rowland.org>
Message-ID: <1388978.Qc6sFy33oS@flatron>

On Tuesday 23 of July 2013 16:53:55 Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > > That's what I was going to suggest too.  The struct phy is defined
> > > in
> > > the board file, which already knows about all the PHYs that exist in
> > > the system.  (Or perhaps it is allocated dynamically, so that when
> > > many
> > > board files are present in the same kernel, only the entries listed
> > > in
> > > the board file for the current system get created.)
> > 
> > Well, such dynamic allocation is a must. We don't accept
> > non-multiplatform aware code anymore, not even saying about
> > multiboard.
> > 
> > > Then the
> > > structure's address is stored in the platform data and made
> > > available
> > > to both the provider and the consumer.
> > 
> > Yes, technically this can work. You would still have to perform some
> > kind of synchronization to make sure that the PHY bound to this
> > structure is actually present. This is again technically doable (e.g.
> > a list of registered struct phys inside PHY core).
> 
> The synchronization takes place inside phy_get.  If phy_create hasn't
> been called for this structure by the time phy_get runs, phy_get will
> return an error.

Yes, this is the solution that I had in mind when saying that this is 
doable.

> > > Even though the struct phy is defined (or allocated) in the board
> > > file,
> > > its contents don't get filled in until the PHY driver provides the
> > > details.
> > 
> > You can't assure this. Board file is free to do whatever it wants with
> > this struct. A clean solution would prevent this.
> 
> I'm not sure what you mean here.  Of course I can't prevent a board
> file from messing up a data structure.  I can't prevent it from causing
> memory access violations either; in fact, I can't prevent any bugs in
> other people's code.
> 
> Besides, why do you say the board file is free to do whatever it wants
> with the struct phy?  Currently the struct phy is created by the PHY
> provider and the PHY core, right?  It's not even mentioned in the board
> file.

I mean, if you have a struct type of which full declaration is available 
for some code, this code can access any memeber of it without any hacks, 
which is not something that we want to have in board files. The phy struct 
should be opaque for them.

> > > > It's technically correct, but quality of this solution isn't
> > > > really
> > > > nice, because it's a layering violation (at least if I understood
> > > > what you mean). This is because you need to have full definition
> > > > of
> > > > struct phy in board file and a structure that is used as private
> > > > data
> > > > in PHY core comes from platform code.
> > > 
> > > You don't have to have a full definition in the board file.  Just a
> > > partial definition -- most of the contents can be filled in later,
> > > when
> > > the PHY driver is ready to store the private data.
> > > 
> > > It's not a layering violation for one region of the kernel to store
> > > private data in a structure defined by another part of the kernel.
> > > This happens all the time (e.g., dev_set_drvdata).
> > 
> > Not really. The phy struct is something that _is_ private data of PHY
> > subsystem, not something that can store private data of PHY subsystem
> > (sure it can store private data of particular PHY driver, but that's
> > another story) and only PHY subsystem should have access to its
> > contents.
> If you want to keep the phy struct completely separate from the board
> file, there's an easy way to do it.  Let's say the board file knows
> about N different PHYs in the system.  Then you define an array of N
> pointers to phys:
> 
> struct phy *(phy_address[N]);
> 
> In the platform data for both PHY j and its controller, store
> &phy_address[j].  The PHY provider passes this cookie to phy_create:
> 
> 	cookie = pdev->dev.platform_data;
> 	ret = phy_create(phy, cookie);
> 
> and phy_create simply stores: *cookie = phy.  The PHY consumer does
> much the same the same thing:
> 
> 	cookie = pdev->dev.platform_data;
> 	phy = phy_get(cookie);
> 
> phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise.

OK, this can work. Again, just technically, because it's rather ugly.

> > By the way, we need to consider other cases here as well, for example
> > it would be nice to have a single phy_get() function that works for
> > both non- DT and DT cases to make the consumer driver not have to
> > worry whether it's being probed from DT or not.
> 
> You ought to be able to adapt this scheme to work with DT.  Maybe by
> having multiple "phy_address" arrays.

Where would you want to have those phy_address arrays stored? There are no 
board files when booting with DT. Not even saying that you don't need to 
use any hacky schemes like this when you have DT that nicely specifies 
relations between devices.

Anyway, board file should not be considered as a method to exchange data 
between drivers. It should be used only to pass data from it to drivers, 
not the other way. Ideally all data in a board file should be marked as 
const and __init and dropped after system initialization.

Best regards,
Tomasz



From tomasz.figa at gmail.com  Tue Jul 23 17:05:48 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 23:05:48 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130723205007.GA27166@kroah.com>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <1731726.KENstTPhkb@flatron> <20130723205007.GA27166@kroah.com>
Message-ID: <1769609.rbAYfG9ir3@flatron>

On Tuesday 23 of July 2013 13:50:07 Greg KH wrote:
> On Tue, Jul 23, 2013 at 10:07:52PM +0200, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
> > > On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
> > > > > You don't "know" the id of the device you are looking up, due to
> > > > > multiple devices being in the system (dynamic ids, look back
> > > > > earlier
> > > > > in
> > > > > this thread for details about that.)
> > > > 
> > > > I got copied in very late so don't have most of the thread I'm
> > > > afraid,
> > > > I did try looking at web archives but didn't see a clear problem
> > > > statement.  In any case this is why the APIs doing lookups do the
> > > > lookups in the context of the requesting device - devices ask for
> > > > whatever name they use locally.
> > > 
> > > What do you mean by "locally"?
> > > 
> > > The problem with the api was that the phy core wanted a id and a
> > > name to create a phy, and then later other code was doing a
> > > "lookup" based on the name and id (mushed together), because it
> > > "knew" that this device was the one it wanted.
> > > 
> > > Just like the clock api, which, for multiple devices, has proven to
> > > cause problems.  I don't want to see us accept an api that we know
> > > has
> > > issues in it now, I'd rather us fix it up properly.
> > > 
> > > Subsystems should be able to create ids how ever they want to, and
> > > not
> > > rely on the code calling them to specify the names of the devices
> > > that
> > > way, otherwise the api is just too fragile.
> > > 
> > > I think, that if you create a device, then just carry around the
> > > pointer to that device (in this case a phy) and pass it to whatever
> > > other code needs it.  No need to do lookups on "known names" or
> > > anything else, just normal pointers, with no problems for multiple
> > > devices, busses, or naming issues.
> > 
> > PHY object is not a device, it is something that a device driver
> > creates (one or more instances of) when it is being probed.
> 
> But you created a 'struct device' for it, so I think of it as a "device"
> be it "virtual" or "real" :)

Keep in mind that those virtual devices are created by PHY driver bound to 
a real device and one real device can have multiple virtual devices behind 
it.

> > You don't have a clean way to export this PHY object to other driver,
> > other than keeping this PHY on a list inside PHY core with some
> > well-known ID (e.g. device name + consumer port name/index, like in
> > regulator core) and then to use this well-known ID inside consumer
> > driver as a lookup key passed to phy_get();
> > 
> > Actually I think for PHY case, exactly the same way as used for
> > regulators might be completely fine:
> > 
> > 1. Each PHY would have some kind of platform, non-unique name, that is
> > just used to print some messages (like the platform/board name of a
> > regulator).
> > 2. Each PHY would have an array of consumers. Consumer specifier would
> > consist of consumer device name and consumer port name - just like in
> > regulator subsystem.
> > 3. PHY driver receives an array of, let's say, phy_init_data inside
> > its
> > platform data that it would use to register its PHYs.
> > 4. Consumer drivers would have constant consumer port names and
> > wouldn't receive any information about PHYs from platform code.
> > 
> > Code example:
> > 
> > [Board file]
> > 
> > static const struct phy_consumer_data usb_20_phy0_consumers[] = {
> > 
> > 	{
> > 	
> > 		.devname = "foo-ehci",
> > 		.port = "usbphy",
> > 	
> > 	},
> > 
> > };
> > 
> > static const struct phy_consumer_data usb_20_phy1_consumers[] = {
> > 
> > 	{
> > 	
> > 		.devname = "foo-otg",
> > 		.port = "otgphy",
> > 	
> > 	},
> > 
> > };
> > 
> > static const struct phy_init_data my_phys[] = {
> > 
> > 	{
> > 	
> > 		.name = "USB 2.0 PHY 0",
> > 		.consumers = usb_20_phy0_consumers,
> > 		.num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
> > 	
> > 	},
> > 	{
> > 	
> > 		.name = "USB 2.0 PHY 1",
> > 		.consumers = usb_20_phy1_consumers,
> > 		.num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
> > 	
> > 	},
> > 	{ }
> > 
> > };
> > 
> > static const struct platform_device usb_phy_pdev = {
> > 
> > 	.name = "foo-usbphy",
> > 	.id = -1,
> > 	.dev = {
> > 	
> > 		.platform_data = my_phys,
> > 	
> > 	},
> > 
> > };
> > 
> > [PHY driver]
> > 
> > static int foo_usbphy_probe(pdev)
> > {
> > 
> > 	struct foo_usbphy *foo;
> > 	struct phy_init_data *init_data = pdev->dev.platform_data;
> > 	/* ... */
> > 	// for each PHY in init_data {
> > 	
> > 		phy_register(&foo->phy[i], &init_data[i]);
> > 	
> > 	// }
> > 	/* ... */
> > 
> > }
> > 
> > [EHCI driver]
> > 
> > static int foo_ehci_probe(pdev)
> > {
> > 
> > 	struct phy *phy;
> > 	/* ... */
> > 	phy = phy_get(&pdev->dev, "usbphy");
> > 	/* ... */
> > 
> > }
> > 
> > [OTG driver]
> > 
> > static int foo_otg_probe(pdev)
> > {
> > 
> > 	struct phy *phy;
> > 	/* ... */
> > 	phy = phy_get(&pdev->dev, "otgphy");
> > 	/* ... */
> > 
> > }
> 
> That's not so bad, as long as you let the phy core use whatever name it
> wants for the device when it registers it with sysfs.

Yes, in regulator core consumer names are completely separated from this. 
Regulator core simply assigns a sequential integer ID to each regulator 
and registers /sys/class/regulator/regulator.ID for each regulator.

> Use the name you
> are requesting as a "tag" or some such "hint" as to what the phy can be
> looked up by.
> 
> Good luck handling duplicate "tags" :)

The tag alone is not a key. Lookup key consists of two components, 
consumer device name and consumer tag. What kind of duplicate tags can be 
a problem here?

Best regards,
Tomasz



From stern at rowland.harvard.edu  Tue Jul 23 17:14:20 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 23 Jul 2013 17:14:20 -0400 (EDT)
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <1388978.Qc6sFy33oS@flatron>
Message-ID: <Pine.LNX.4.44L0.1307231708020.1304-100000@iolanthe.rowland.org>

On Tue, 23 Jul 2013, Tomasz Figa wrote:

> > If you want to keep the phy struct completely separate from the board
> > file, there's an easy way to do it.  Let's say the board file knows
> > about N different PHYs in the system.  Then you define an array of N
> > pointers to phys:
> > 
> > struct phy *(phy_address[N]);
> > 
> > In the platform data for both PHY j and its controller, store
> > &phy_address[j].  The PHY provider passes this cookie to phy_create:
> > 
> > 	cookie = pdev->dev.platform_data;
> > 	ret = phy_create(phy, cookie);
> > 
> > and phy_create simply stores: *cookie = phy.  The PHY consumer does
> > much the same the same thing:
> > 
> > 	cookie = pdev->dev.platform_data;
> > 	phy = phy_get(cookie);
> > 
> > phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise.
> 
> OK, this can work. Again, just technically, because it's rather ugly.

There's no reason the phy_address things have to be arrays.  A separate
individual pointer for each PHY would work just as well.

> Where would you want to have those phy_address arrays stored? There are no 
> board files when booting with DT. Not even saying that you don't need to 
> use any hacky schemes like this when you have DT that nicely specifies 
> relations between devices.

If everybody agrees DT has a nice scheme for specifying relations
between devices, why not use that same scheme in the PHY core?

> Anyway, board file should not be considered as a method to exchange data 
> between drivers. It should be used only to pass data from it to drivers, 
> not the other way. Ideally all data in a board file should be marked as 
> const and __init and dropped after system initialization.

The phy_address things don't have to be defined or allocated in the 
board file; they could be set up along with the platform data.

In any case, this was simply meant to be a suggestion to show that it 
is relatively easy to do what you need without using name or ID 
strings.

Alan Stern



From gregkh at linuxfoundation.org  Tue Jul 23 17:23:34 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 23 Jul 2013 14:23:34 -0700
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <1769609.rbAYfG9ir3@flatron>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <1731726.KENstTPhkb@flatron> <20130723205007.GA27166@kroah.com>
 <1769609.rbAYfG9ir3@flatron>
Message-ID: <20130723212334.GA21945@kroah.com>

On Tue, Jul 23, 2013 at 11:05:48PM +0200, Tomasz Figa wrote:
> > That's not so bad, as long as you let the phy core use whatever name it
> > wants for the device when it registers it with sysfs.
> 
> Yes, in regulator core consumer names are completely separated from this. 
> Regulator core simply assigns a sequential integer ID to each regulator 
> and registers /sys/class/regulator/regulator.ID for each regulator.

Yes, that's fine.

> > Use the name you
> > are requesting as a "tag" or some such "hint" as to what the phy can be
> > looked up by.
> > 
> > Good luck handling duplicate "tags" :)
> 
> The tag alone is not a key. Lookup key consists of two components, 
> consumer device name and consumer tag. What kind of duplicate tags can be 
> a problem here?

Ok, I didn't realize it looked at both parts, that makes sense, thanks.

greg k-h


From tomasz.figa at gmail.com  Tue Jul 23 17:31:31 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 23 Jul 2013 23:31:31 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <Pine.LNX.4.44L0.1307231708020.1304-100000@iolanthe.rowland.org>
References: <Pine.LNX.4.44L0.1307231708020.1304-100000@iolanthe.rowland.org>
Message-ID: <5977067.8rykRgjgre@flatron>

On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > > If you want to keep the phy struct completely separate from the
> > > board
> > > file, there's an easy way to do it.  Let's say the board file knows
> > > about N different PHYs in the system.  Then you define an array of N
> > > pointers to phys:
> > > 
> > > struct phy *(phy_address[N]);
> > > 
> > > In the platform data for both PHY j and its controller, store
> > > 
> > > &phy_address[j].  The PHY provider passes this cookie to phy_create:
> > > 	cookie = pdev->dev.platform_data;
> > > 	ret = phy_create(phy, cookie);
> > > 
> > > and phy_create simply stores: *cookie = phy.  The PHY consumer does
> > > 
> > > much the same the same thing:
> > > 	cookie = pdev->dev.platform_data;
> > > 	phy = phy_get(cookie);
> > > 
> > > phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise.
> > 
> > OK, this can work. Again, just technically, because it's rather ugly.
> 
> There's no reason the phy_address things have to be arrays.  A separate
> individual pointer for each PHY would work just as well.
> 
> > Where would you want to have those phy_address arrays stored? There
> > are no board files when booting with DT. Not even saying that you
> > don't need to use any hacky schemes like this when you have DT that
> > nicely specifies relations between devices.
> 
> If everybody agrees DT has a nice scheme for specifying relations
> between devices, why not use that same scheme in the PHY core?

It is already used, for cases when consumer device has a DT node attached. 
In non-DT case this kind lookup translates loosely to something that is 
being done in regulator framework - you can't bind devices by pointers, 
because you don't have those pointers, so you need to use device names.

> > Anyway, board file should not be considered as a method to exchange
> > data between drivers. It should be used only to pass data from it to
> > drivers, not the other way. Ideally all data in a board file should
> > be marked as const and __init and dropped after system
> > initialization.
> 
> The phy_address things don't have to be defined or allocated in the
> board file; they could be set up along with the platform data.

There is no platform data when booting with DT.

> In any case, this was simply meant to be a suggestion to show that it
> is relatively easy to do what you need without using name or ID
> strings.

Sure. It's good to have different options discussed as well.

Best regards,
Tomasz



From festevam at gmail.com  Tue Jul 23 17:41:16 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 23 Jul 2013 18:41:16 -0300
Subject: [PATCH 1/2] ARM: dts: imx6qdl-sabresd: Add touchscreen support
Message-ID: <1374615677-18437-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

mx6 sabresd boards have a egalax touchscreen controller connected via i2c2.

Add support for it.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Hi Shawn,

I don't have access to a sabresd board at the moment, so could not test this.

 arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 166b9ae..5124994 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -129,6 +129,21 @@
        };
 };
 
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2_2>;
+	status = "okay";
+
+	egalax_ts at 04 {
+		compatible = "eeti,egalax_ts";
+		reg = <0x04>;
+		interrupt-parent = <&gpio6>;
+		interrupts = <8 2>;
+		wakeup-gpios = <&gpio6 8 0>;
+	};
+};
+
 &iomuxc {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_hog>;
@@ -143,6 +158,7 @@
 				MX6QDL_PAD_NANDF_D2__GPIO2_IO02 0x80000000
 				MX6QDL_PAD_NANDF_D3__GPIO2_IO03 0x80000000
 				MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x130b0
+				MX6QDL_PAD_NANDF_ALE__GPIO6_IO08 0x80000000
 			>;
 		};
 	};
-- 
1.8.1.2



From festevam at gmail.com  Tue Jul 23 17:41:17 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 23 Jul 2013 18:41:17 -0300
Subject: [PATCH 2/2] ARM: imx_v6_v7_defconfig: Select CONFIG_TOUCHSCREEN_EGALAX
In-Reply-To: <1374615677-18437-1-git-send-email-festevam@gmail.com>
References: <1374615677-18437-1-git-send-email-festevam@gmail.com>
Message-ID: <1374615677-18437-2-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

egalax touchscren controller is present on mx6 sabresd/sabrelite, so let's 
enable it by default.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/configs/imx_v6_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f1662d3..9e15992 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -127,6 +127,7 @@ CONFIG_KEYBOARD_IMX=y
 CONFIG_MOUSE_PS2=m
 CONFIG_MOUSE_PS2_ELANTECH=y
 CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_TOUCHSCREEN_EGALAX=y
 CONFIG_TOUCHSCREEN_MC13783=y
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_MMA8450=y
-- 
1.8.1.2



From hauke at hauke-m.de  Tue Jul 23 17:54:57 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Tue, 23 Jul 2013 23:54:57 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <20130719022314.GB4941@glitch>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130719022314.GB4941@glitch>
Message-ID: <51EEFBB1.6070408@hauke-m.de>

On 07/19/2013 04:23 AM, Domenico Andreoli wrote:
> Hi Hauke,
> 
> On Tue, Jul 16, 2013 at 03:52:07PM +0200, Hauke Mehrtens wrote:
>> This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU.
>> Currently just booting to a shell is working and nothing else, no
>> Ethernet, wifi, flash, ...
>>
>> This SoC uses a Dual core CPU, but this is currently not implemented.
>> More information about this SoC can be found here:
>> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers
>>
>> Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
>> ---
> 
> ...
> 
>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>> index e401a76..74e32f6 100644
>> --- a/arch/arm/Kconfig.debug
>> +++ b/arch/arm/Kconfig.debug
>> @@ -93,6 +93,10 @@ choice
>>  		bool "Kernel low-level debugging on BCM2835 PL011 UART"
>>  		depends on ARCH_BCM2835
>>  
>> +	config DEBUG_BCM53XX
>> +		bool "Kernel low-level debugging on BCM53XX UART1"
>> +		depends on ARCH_BCM53XX
>> +
>>  	config DEBUG_CLPS711X_UART1
>>  		bool "Kernel low-level debugging messages via UART1"
>>  		depends on ARCH_CLPS711X
>> @@ -762,6 +766,7 @@ endchoice
>>  config DEBUG_LL_INCLUDE
>>  	string
>>  	default "debug/bcm2835.S" if DEBUG_BCM2835
>> +	default "debug/bcm53xx.S" if DEBUG_BCM53XX
>>  	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
>>  	default "debug/exynos.S" if DEBUG_EXYNOS_UART
>>  	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
> 
> ...
> 
>> diff --git a/arch/arm/include/debug/bcm53xx.S b/arch/arm/include/debug/bcm53xx.S
>> new file mode 100644
>> index 0000000..98c836b
>> --- /dev/null
>> +++ b/arch/arm/include/debug/bcm53xx.S
>> @@ -0,0 +1,19 @@
>> +/*
>> + * Macros used for EARLY_PRINTK, in low-level UART debug console
>> + *
>> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
>> + *
>> + * Licensed under the GNU/GPL. See COPYING for details.
>> + */
>> +
>> +#define BCM53XX_UART1_PHYS	0x18000300
>> +#define BCM53XX_UART1_VIRT	0xf1000300
>> +#define BCM53XX_UART1_SH	0
>> +
>> +	.macro	addruart, rp, rv, tmp
>> +	ldr	\rp, =BCM53XX_UART1_PHYS 	@ MMU off, Physical
>> +	ldr	\rv, =BCM53XX_UART1_VIRT 	@ MMU on, Virtual
>> +	.endm
>> +
>> +#define UART_SHIFT	BCM53XX_UART1_SH
>> +#include <asm/hardware/debug-8250.S>
> 
> don't know if it's worth to add this debug uart support here. there is a
> series from Russel to consolidate 8250 and pl01x debug uarts. maybe you
> want to delay this.

Yes, I saw the patch submission and now it is in linux-next. I will add
debugging into a separate patch.

> 
>> diff --git a/arch/arm/mach-bcm53xx/bcm53xx.c b/arch/arm/mach-bcm53xx/bcm53xx.c
>> new file mode 100644
>> index 0000000..aa5bd397
>> --- /dev/null
>> +++ b/arch/arm/mach-bcm53xx/bcm53xx.c
>> @@ -0,0 +1,68 @@
>> +/*
>> + * Broadcom BCM47XX / BCM53XX ARM platform code.
>> + *
>> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
>> + *
>> + * Licensed under the GNU/GPL. See COPYING for details.
>> + */
>> +#include <linux/of_address.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/irqchip.h>
>> +#include <linux/clocksource.h>
>> +#include <linux/clk-provider.h>
>> +
>> +#include <asm/mach/arch.h>
>> +#include <asm/mach/map.h>
>> +#include <asm/signal.h>
>> +
>> +static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
>> +				 struct pt_regs *regs)
>> +{
>> +	/*
>> +	 * These happen for no good reason
>> +	 * possibly left over from CFE
>> +	 */
>> +	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
>> +		addr, fsr);
>> +
>> +	/* Returning non-zero causes fault display and panic */
>> +	return 0;
>> +}
>> +
>> +static void bcm53xx_aborts_enable(void)
>> +{
>> +	/* Install our hook */
>> +	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
>> +			"imprecise external abort");
>> +}
>> +
>> +static void __init bcm53xx_timer_init(void)
>> +{
>> +	of_clk_init(NULL);
>> +	clocksource_of_init();
>> +}
>> +
>> +void __init bcm53xx_map_io(void)
>> +{
>> +	debug_ll_io_init();
>> +	bcm53xx_aborts_enable();
>> +}
>> +
>> +static void __init bcm53xx_dt_init(void)
>> +{
>> +	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>> +}
>> +
>> +static const char const *bcm53xx_dt_compat[] = {
>> +	"brcm,bcm5301x",
>> +	"netgear,r6250v1",
>> +	NULL,
>> +};
>> +
>> +DT_MACHINE_START(BCM53XX, "BCM53XX")
>> +	.init_machine = bcm53xx_dt_init,
>> +	.map_io = bcm53xx_map_io,
>> +	.init_irq = irqchip_init,
>> +	.init_time = bcm53xx_timer_init,
>> +	.dt_compat = bcm53xx_dt_compat,
>> +MACHINE_END
> 
> the trend is to consolidate machine descriptors.
> 
> so .init_irq can go, irqchip_init is picked anyway if .init_irq is NULL.
Thanks for the info, I will removed it.
> 
> also .init_time could be dropped, it can be specified using
> CLOCKSOURCE_OF_DECLARE(), but I see bcm53xx_timer_init is already quite
> minimal here and I'm struggling to see the big picture here. So mine is
> actually a question for others... :)

I will leave it for now like it is, if someone has a better idea I will
change it.

Hauke


From olof at lixom.net  Tue Jul 23 18:10:17 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 23 Jul 2013 15:10:17 -0700
Subject: [GIT PULL] Remove ARM local timer API
In-Reply-To: <20130625200211.GA11625@codeaurora.org>
References: <20130625200211.GA11625@codeaurora.org>
Message-ID: <CAOesGMj5AZcB7-kcS8_JqfKAg_RUKqTdDZf7bdwkebn3pwADAw@mail.gmail.com>

On Tue, Jun 25, 2013 at 1:02 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
> Olof/Arnd,
>
> These patches remove the ARM local timer API. The ARM architected
> timers have already moved away from this API so this series
> migrates the rest of the users allowing us to remove the API
> entirely. Thomas has been kind enough to take the first two
> patches into timers/core in the tip tree (thanks Thomas!) so I've
> merged that into v3.10-rc1 and then applied the rest of the
> patches on top. Let me know if this is acceptable.
>
> These patches have been through multiple rounds and tested by
> multiple people since before the 3.10 merge window closed. Only
> Barry's ack is missing (Cced).
>
> Since I don't have a tree on kernel.org, David Brown has been
> kind enough to push my tag out to his repo. Please pull.
>
> The following changes since commit 42cba6e27c4cddc4df701c597dbfa666e1c013c8:
>
>   Merge branch 'timers/core' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip into remove-local-timers (2013-06-24 17:45:02 -0700)
>
> are available in the git repository at:
>
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git tags/remove-local-timers
>
> for you to fetch changes up to 060fd3043e5e3488504b9e70182e188dd9113aea:
>
>   ARM: smp: Remove local timer API (2013-06-24 17:47:34 -0700)
>
> ----------------------------------------------------------------
> Now that we have a generic arch hook for broadcast we can remove the local
> timer API entirely. Doing so will reduce code in ARM core, reduce the
> architecture dependencies of our timer drivers, and simplify the code because
> we no longer go through an architecture layer that is essentially a hotplug
> notifier.

Hi,

Merged in as localtimer/removal into next/cleanup.

I had quite a few merge conflicts due to the __cpuinit removal, so
please double-check my resolutions.


-Olof


From hauke at hauke-m.de  Tue Jul 23 18:10:57 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Wed, 24 Jul 2013 00:10:57 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <20130719013646.GA16615@glitch>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716172023.64337690@skate> <51E56839.8010205@hauke-m.de>
 <20130719013646.GA16615@glitch>
Message-ID: <51EEFF71.8090203@hauke-m.de>

On 07/19/2013 03:36 AM, Domenico Andreoli wrote:
> On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote:
>> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote:
>>>
>>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig b/arch/arm/mach-bcm53xx/Kconfig
>>>> new file mode 100644
>>>> index 0000000..1e16e87
>>>> --- /dev/null
>>>> +++ b/arch/arm/mach-bcm53xx/Kconfig
>>>> @@ -0,0 +1,10 @@
>>>> +config ARCH_BCM53XX
>>>> +	bool "Broadcom BCM47XX / BCM53XX ARM SoC"
>>>
>>> So the directory is named mach-bcm53xx, but you also handle BCM47xx
>>> SoCs. This doesn't sound really easy to follow.
> 
> At the time of the BCM281XX merge we considered that such directories would
> mostly contain board files only, being these new entries DT based. Hence
> the choice of mach-bcm to collect all of them.
> 
> I think you should then put this stuff there.

So you think I should move the file from
arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?
Most (All?) of the Router SoCs in the BCM53XX and BCM47XX line are from
the same family and they should be supported by the same code, so there
is no reason to have a bcm47xx.c and a bcm53xx.c.

>> Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I
>> do not know why there are two different names, probably marketing.
>>
>> Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a
>> MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to
>> not conflict with the MIPS part now. I know this could still cause
>> problems and people will get confused, but I do not know a better name.
> 
> I'll throw also BCM476x (bcm4760 and bcm4761) on the table. These are ARM11,
> single-core SoCs.
> 
> Can we agree on a nice naming so that we actually clarify this silliness?

We could name it BCM5301X like it is named the the vendor source code.
Currently there are the following SoCs of this family available:
BCM53010, BCM53011, BCM53012, BCM53014, BCM53015, BCM53016, BCM53017,
BCM53018, BCM4707, BCM4708 and BCM4709. Internal there are two different
chip IDs available 53010 (BCM4707) and 53018 (BCM53018).

Hauke


From maxime.ripard at free-electrons.com  Tue Jul 23 18:25:03 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 00:25:03 +0200
Subject: [PATCH 01/10] irqchip: GIC: Add Cortex-A7 compatible string
In-Reply-To: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374618312-19001-2-git-send-email-maxime.ripard@free-electrons.com>

The GIC can also be found on Cortex-A7 based SoCs. Register a new
compatible string for those cases.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/irqchip/irq-gic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 19ceaa6..5b5fe23 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -854,6 +854,7 @@ int __init gic_of_init(struct device_node *node, struct device_node *parent)
 }
 IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
 IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
+IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init);
 IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init);
 IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Tue Jul 23 18:25:02 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 00:25:02 +0200
Subject: [PATCH 00/10] ARM: sunxi: Add support for the Allwinner A31 SoC
Message-ID: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>

Hi everyone,

This patchset add support in Linux for the Allwinner A31 SoC. This SoC is the
current high-end Allwinner SoC, and is powered by 4 Cortex-A7.

SMP support is not there yet, but should come eventually, so does the clock
support.

As usual, since we don't have any storage device driver yet, it only boots from
an initramfs.

Finally, something worth mentionning is that with the current bootloader,
you'll encounter 2 ~6s hangs during the boot. This is because the SMP bit of
the Cortex-A7 doesn't appear to be set, leading to the CPU caches being
disabled. This can partially be addressed by selecting CONFIG_SMP, that will
remove the second hang, because the SMP bit is set after kernel decompression.

Obviously, this won't remove the first hang that happens during decompression,
but it's better than nothing. A proper fix would be to fix the bootloader.

Thanks,
Maxime

Emilio L?pez (1):
  clk: sunxi: fix initialization of basic clocks

Maxime Ripard (9):
  irqchip: GIC: Add Cortex-A7 compatible string
  ARM: sunxi: Add the Allwinner A31 compatible to the machine definition
  ARM: sun6i: Add restart code for the A31
  ARM: sunxi: Add Allwinner A31 DTSI
  ARM: sun6i: Add WITS Colombus A31 evaluation kit support
  pinctrl: sunxi: Add Allwinner A31 pins set
  ARM: sunxi: dt: Add PIO controller to A31 DTSI
  ARM: sun6i: Add UART0 muxing options
  ARM: sun6i: colombus: Add uart0 muxing

 arch/arm/boot/dts/Makefile               |   3 +-
 arch/arm/boot/dts/sun6i-a31-colombus.dts |  32 ++
 arch/arm/boot/dts/sun6i-a31.dtsi         | 174 +++++++
 arch/arm/mach-sunxi/Kconfig              |   2 +
 arch/arm/mach-sunxi/sunxi.c              |  38 ++
 drivers/clk/sunxi/clk-sunxi.c            |  11 +-
 drivers/irqchip/irq-gic.c                |   1 +
 drivers/pinctrl/pinctrl-sunxi-pins.h     | 820 +++++++++++++++++++++++++++++++
 drivers/pinctrl/pinctrl-sunxi.c          |   1 +
 9 files changed, 1073 insertions(+), 9 deletions(-)
 create mode 100644 arch/arm/boot/dts/sun6i-a31-colombus.dts
 create mode 100644 arch/arm/boot/dts/sun6i-a31.dtsi

-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Tue Jul 23 18:25:05 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 00:25:05 +0200
Subject: [PATCH 03/10] ARM: sunxi: Add the Allwinner A31 compatible to the
 machine definition
In-Reply-To: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374618312-19001-4-git-send-email-maxime.ripard@free-electrons.com>

The Allwinner A31 is a quad-Cortex-A7 based SoC, which shares a lot of
differences with the previous SoCs from Allwinner, like the PIO, I2C,
UARTs, timers, watchdog IPs, but also differs but droping the WEMAC
ethernet controller and most notably droping the in-house IRQ controller
in favor of a ARM GIC one.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/mach-sunxi/Kconfig | 2 ++
 arch/arm/mach-sunxi/sunxi.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 5b045e3..3ab2f65 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -10,3 +10,5 @@ config ARCH_SUNXI
 	select SPARSE_IRQ
 	select SUN4I_TIMER
 	select PINCTRL_SUNXI
+	select ARM_GIC
+	select HAVE_SMP
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 38a3c55..11326d9 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -96,6 +96,7 @@ static const char * const sunxi_board_dt_compat[] = {
 	"allwinner,sun4i-a10",
 	"allwinner,sun5i-a10s",
 	"allwinner,sun5i-a13",
+	"allwinner,sun6i-a31",
 	NULL,
 };
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Tue Jul 23 18:25:06 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 00:25:06 +0200
Subject: [PATCH 04/10] ARM: sun6i: Add restart code for the A31
In-Reply-To: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374618312-19001-5-git-send-email-maxime.ripard@free-electrons.com>

The Allwinner A31 has a sligthly different watchdog that requires a
different restart code.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/mach-sunxi/sunxi.c | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 11326d9..c18ef3a 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -32,6 +32,15 @@
 #define SUN4I_WATCHDOG_MODE_ENABLE		(1 << 0)
 #define SUN4I_WATCHDOG_MODE_RESET_ENABLE	(1 << 1)
 
+#define SUN6I_WATCHDOG1_IRQ_REG		0x00
+#define SUN6I_WATCHDOG1_CTRL_REG	0x10
+#define SUN6I_WATCHDOG1_CTRL_RESTART		(1 << 0)
+#define SUN6I_WATCHDOG1_CONFIG_REG	0x14
+#define SUN6I_WATCHDOG1_CONFIG_RESTART		(1 << 0)
+#define SUN6I_WATCHDOG1_CONFIG_IRQ		(1 << 1)
+#define SUN6I_WATCHDOG1_MODE_REG	0x18
+#define SUN6I_WATCHDOG1_MODE_ENABLE		(1 << 0)
+
 static void __iomem *wdt_base;
 
 static void sun4i_restart(enum reboot_mode mode, const char *cmd)
@@ -56,8 +65,36 @@ static void sun4i_restart(enum reboot_mode mode, const char *cmd)
 	}
 }
 
+static void sun6i_restart(char mode, const char *cmd)
+{
+	if (!wdt_base)
+		return;
+
+	/* Disable interrupts */
+	writel(0, wdt_base + SUN6I_WATCHDOG1_IRQ_REG);
+
+	/* We want to disable the IRQ and just reset the whole system */
+	writel(SUN6I_WATCHDOG1_CONFIG_RESTART,
+		wdt_base + SUN6I_WATCHDOG1_CONFIG_REG);
+
+	/* Enable timer. The default and lowest interval value is 0.5s */
+	writel(SUN6I_WATCHDOG1_MODE_ENABLE,
+		wdt_base + SUN6I_WATCHDOG1_MODE_REG);
+
+	/* Restart the watchdog. */
+	writel(SUN6I_WATCHDOG1_CTRL_RESTART,
+		wdt_base + SUN6I_WATCHDOG1_CTRL_REG);
+
+	while (1) {
+		mdelay(5);
+		writel(SUN6I_WATCHDOG1_MODE_ENABLE,
+			wdt_base + SUN6I_WATCHDOG1_MODE_REG);
+	}
+}
+
 static struct of_device_id sunxi_restart_ids[] = {
 	{ .compatible = "allwinner,sun4i-wdt", .data = sun4i_restart },
+	{ .compatible = "allwinner,sun6i-wdt", .data = sun6i_restart },
 	{ /*sentinel*/ }
 };
 
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Tue Jul 23 18:25:04 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 00:25:04 +0200
Subject: [PATCH 02/10] clk: sunxi: fix initialization of basic clocks
In-Reply-To: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374618312-19001-3-git-send-email-maxime.ripard@free-electrons.com>

From: Emilio L?pez <emilio at elopez.com.ar>

With the recent move towards CLK_OF_DECLARE(...), the driver stopped
initializing osc32k, which is compatible "fixed-clock". This is because
we never called of_clk_init(NULL). Fix this by moving the only other
simple clock (osc24M) to use CLK_OF_DECLARE(...) and call of_clk_init(NULL)
to initialize both of them.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 412912b..fe1528e 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -409,12 +409,7 @@ static void __init sunxi_gates_clk_setup(struct device_node *node,
 
 	of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
 }
-
-/* Matches for of_clk_init */
-static const __initconst struct of_device_id clk_match[] = {
-	{.compatible = "allwinner,sun4i-osc-clk", .data = sunxi_osc_clk_setup,},
-	{}
-};
+CLK_OF_DECLARE(sunxi_osc, "allwinner,sun4i-osc-clk", sunxi_osc_clk_setup);
 
 /* Matches for factors clocks */
 static const __initconst struct of_device_id clk_factors_match[] = {
@@ -467,8 +462,8 @@ static void __init of_sunxi_table_clock_setup(const struct of_device_id *clk_mat
 
 void __init sunxi_init_clocks(void)
 {
-	/* Register all the simple sunxi clocks on DT */
-	of_clk_init(clk_match);
+	/* Register all the simple and basic clocks on DT */
+	of_clk_init(NULL);
 
 	/* Register factor clocks */
 	of_sunxi_table_clock_setup(clk_factors_match, sunxi_factors_clk_setup);
-- 
1.8.3.2



From b.brezillon at overkiz.com  Tue Jul 23 18:24:49 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Wed, 24 Jul 2013 00:24:49 +0200
Subject: [PATCH v2 01/42] ARM: at91: move at91_pmc.h to
 include/linux/clk/at91.h
In-Reply-To: <20130723180330.GL16015@ns203013.ovh.net>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <1374068247-13574-1-git-send-email-b.brezillon@overkiz.com>
 <20130723180330.GL16015@ns203013.ovh.net>
Message-ID: <51EF02B1.8030201@overkiz.com>

Le 23/07/2013 20:03, Jean-Christophe PLAGNIOL-VILLARD a ?crit :
> On 15:37 Wed 17 Jul     , Boris BREZILLON wrote:
>> This patch moves at91_pmc.h header from machine specific directory
>> (arch/arm/mach-at91/include/mach/at91_pmc.h) to clk include directory
>> (include/linux/clk/at91.h).
> please the at91_pmc.h in the name
>
> so we known the IP that we use and if we change it we will not have to rename
> it in the futur
OK. I will change the name to at91_pmc.h in the next version.
>
> otherwise
> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
>
> Best Regards,
> J.
>> We need this to avoid reference to machine specific headers in clk
>> drivers.
>>
>> Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
>> ---
>>   arch/arm/mach-at91/at91rm9200.c                    |    2 +-
>>   arch/arm/mach-at91/at91sam9260.c                   |    2 +-
>>   arch/arm/mach-at91/at91sam9261.c                   |    2 +-
>>   arch/arm/mach-at91/at91sam9263.c                   |    2 +-
>>   arch/arm/mach-at91/at91sam9g45.c                   |    2 +-
>>   arch/arm/mach-at91/at91sam9n12.c                   |    2 +-
>>   arch/arm/mach-at91/at91sam9rl.c                    |    2 +-
>>   arch/arm/mach-at91/at91sam9x5.c                    |    2 +-
>>   arch/arm/mach-at91/clock.c                         |    2 +-
>>   arch/arm/mach-at91/pm.c                            |    2 +-
>>   arch/arm/mach-at91/pm_slowclock.S                  |    2 +-
>>   arch/arm/mach-at91/sama5d3.c                       |    2 +-
>>   arch/arm/mach-at91/setup.c                         |    2 +-
>>   drivers/usb/gadget/atmel_usba_udc.c                |    2 +-
>>   .../mach/at91_pmc.h => include/linux/clk/at91.h    |    2 +-
>>   15 files changed, 15 insertions(+), 15 deletions(-)
>>   rename arch/arm/mach-at91/include/mach/at91_pmc.h => include/linux/clk/at91.h (99%)
>>
>> diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
>> index 4aad93d..8de5b02 100644
>> --- a/arch/arm/mach-at91/at91rm9200.c
>> +++ b/arch/arm/mach-at91/at91rm9200.c
>> @@ -12,13 +12,13 @@
>>   
>>   #include <linux/module.h>
>>   #include <linux/reboot.h>
>> +#include <linux/clk/at91.h>
>>   
>>   #include <asm/irq.h>
>>   #include <asm/mach/arch.h>
>>   #include <asm/mach/map.h>
>>   #include <asm/system_misc.h>
>>   #include <mach/at91rm9200.h>
>> -#include <mach/at91_pmc.h>
>>   #include <mach/at91_st.h>
>>   #include <mach/cpu.h>
>>   
>> diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
>> index 5de6074..db9d89a 100644
>> --- a/arch/arm/mach-at91/at91sam9260.c
>> +++ b/arch/arm/mach-at91/at91sam9260.c
>> @@ -11,6 +11,7 @@
>>    */
>>   
>>   #include <linux/module.h>
>> +#include <linux/clk/at91.h>
>>   
>>   #include <asm/proc-fns.h>
>>   #include <asm/irq.h>
>> @@ -20,7 +21,6 @@
>>   #include <mach/cpu.h>
>>   #include <mach/at91_dbgu.h>
>>   #include <mach/at91sam9260.h>
>> -#include <mach/at91_pmc.h>
>>   
>>   #include "at91_aic.h"
>>   #include "at91_rstc.h"
>> diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
>> index 0e07932..a4123bd 100644
>> --- a/arch/arm/mach-at91/at91sam9261.c
>> +++ b/arch/arm/mach-at91/at91sam9261.c
>> @@ -11,6 +11,7 @@
>>    */
>>   
>>   #include <linux/module.h>
>> +#include <linux/clk/at91.h>
>>   
>>   #include <asm/proc-fns.h>
>>   #include <asm/irq.h>
>> @@ -19,7 +20,6 @@
>>   #include <asm/system_misc.h>
>>   #include <mach/cpu.h>
>>   #include <mach/at91sam9261.h>
>> -#include <mach/at91_pmc.h>
>>   
>>   #include "at91_aic.h"
>>   #include "at91_rstc.h"
>> diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
>> index 6ce7d18..e0a1a68 100644
>> --- a/arch/arm/mach-at91/at91sam9263.c
>> +++ b/arch/arm/mach-at91/at91sam9263.c
>> @@ -11,6 +11,7 @@
>>    */
>>   
>>   #include <linux/module.h>
>> +#include <linux/clk/at91.h>
>>   
>>   #include <asm/proc-fns.h>
>>   #include <asm/irq.h>
>> @@ -18,7 +19,6 @@
>>   #include <asm/mach/map.h>
>>   #include <asm/system_misc.h>
>>   #include <mach/at91sam9263.h>
>> -#include <mach/at91_pmc.h>
>>   
>>   #include "at91_aic.h"
>>   #include "at91_rstc.h"
>> diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
>> index 474ee04..29ba2ca 100644
>> --- a/arch/arm/mach-at91/at91sam9g45.c
>> +++ b/arch/arm/mach-at91/at91sam9g45.c
>> @@ -12,13 +12,13 @@
>>   
>>   #include <linux/module.h>
>>   #include <linux/dma-mapping.h>
>> +#include <linux/clk/at91.h>
>>   
>>   #include <asm/irq.h>
>>   #include <asm/mach/arch.h>
>>   #include <asm/mach/map.h>
>>   #include <asm/system_misc.h>
>>   #include <mach/at91sam9g45.h>
>> -#include <mach/at91_pmc.h>
>>   #include <mach/cpu.h>
>>   
>>   #include "at91_aic.h"
>> diff --git a/arch/arm/mach-at91/at91sam9n12.c b/arch/arm/mach-at91/at91sam9n12.c
>> index c7d670d..c270503 100644
>> --- a/arch/arm/mach-at91/at91sam9n12.c
>> +++ b/arch/arm/mach-at91/at91sam9n12.c
>> @@ -8,12 +8,12 @@
>>   
>>   #include <linux/module.h>
>>   #include <linux/dma-mapping.h>
>> +#include <linux/clk/at91.h>
>>   
>>   #include <asm/irq.h>
>>   #include <asm/mach/arch.h>
>>   #include <asm/mach/map.h>
>>   #include <mach/at91sam9n12.h>
>> -#include <mach/at91_pmc.h>
>>   #include <mach/cpu.h>
>>   
>>   #include "board.h"
>> diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c
>> index d4ec0d9..2694bd1 100644
>> --- a/arch/arm/mach-at91/at91sam9rl.c
>> +++ b/arch/arm/mach-at91/at91sam9rl.c
>> @@ -10,6 +10,7 @@
>>    */
>>   
>>   #include <linux/module.h>
>> +#include <linux/clk/at91.h>
>>   
>>   #include <asm/proc-fns.h>
>>   #include <asm/irq.h>
>> @@ -19,7 +20,6 @@
>>   #include <mach/cpu.h>
>>   #include <mach/at91_dbgu.h>
>>   #include <mach/at91sam9rl.h>
>> -#include <mach/at91_pmc.h>
>>   
>>   #include "at91_aic.h"
>>   #include "at91_rstc.h"
>> diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
>> index 2abee66..9fdea07 100644
>> --- a/arch/arm/mach-at91/at91sam9x5.c
>> +++ b/arch/arm/mach-at91/at91sam9x5.c
>> @@ -8,12 +8,12 @@
>>   
>>   #include <linux/module.h>
>>   #include <linux/dma-mapping.h>
>> +#include <linux/clk/at91.h>
>>   
>>   #include <asm/irq.h>
>>   #include <asm/mach/arch.h>
>>   #include <asm/mach/map.h>
>>   #include <mach/at91sam9x5.h>
>> -#include <mach/at91_pmc.h>
>>   #include <mach/cpu.h>
>>   
>>   #include "board.h"
>> diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
>> index 6b2630a..cc263d0 100644
>> --- a/arch/arm/mach-at91/clock.c
>> +++ b/arch/arm/mach-at91/clock.c
>> @@ -24,9 +24,9 @@
>>   #include <linux/clk.h>
>>   #include <linux/io.h>
>>   #include <linux/of_address.h>
>> +#include <linux/clk/at91.h>
>>   
>>   #include <mach/hardware.h>
>> -#include <mach/at91_pmc.h>
>>   #include <mach/cpu.h>
>>   
>>   #include <asm/proc-fns.h>
>> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
>> index 15afb5d..de425e0 100644
>> --- a/arch/arm/mach-at91/pm.c
>> +++ b/arch/arm/mach-at91/pm.c
>> @@ -19,13 +19,13 @@
>>   #include <linux/module.h>
>>   #include <linux/platform_device.h>
>>   #include <linux/io.h>
>> +#include <linux/clk/at91.h>
>>   
>>   #include <asm/irq.h>
>>   #include <linux/atomic.h>
>>   #include <asm/mach/time.h>
>>   #include <asm/mach/irq.h>
>>   
>> -#include <mach/at91_pmc.h>
>>   #include <mach/cpu.h>
>>   
>>   #include "at91_aic.h"
>> diff --git a/arch/arm/mach-at91/pm_slowclock.S b/arch/arm/mach-at91/pm_slowclock.S
>> index 098c28d..76387e0 100644
>> --- a/arch/arm/mach-at91/pm_slowclock.S
>> +++ b/arch/arm/mach-at91/pm_slowclock.S
>> @@ -13,8 +13,8 @@
>>    */
>>   
>>   #include <linux/linkage.h>
>> +#include <linux/clk/at91.h>
>>   #include <mach/hardware.h>
>> -#include <mach/at91_pmc.h>
>>   #include <mach/at91_ramc.h>
>>   
>>   
>> diff --git a/arch/arm/mach-at91/sama5d3.c b/arch/arm/mach-at91/sama5d3.c
>> index 4012797..32e0522 100644
>> --- a/arch/arm/mach-at91/sama5d3.c
>> +++ b/arch/arm/mach-at91/sama5d3.c
>> @@ -9,12 +9,12 @@
>>   
>>   #include <linux/module.h>
>>   #include <linux/dma-mapping.h>
>> +#include <linux/clk/at91.h>
>>   
>>   #include <asm/irq.h>
>>   #include <asm/mach/arch.h>
>>   #include <asm/mach/map.h>
>>   #include <mach/sama5d3.h>
>> -#include <mach/at91_pmc.h>
>>   #include <mach/cpu.h>
>>   
>>   #include "soc.h"
>> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
>> index b17fbcf..de3c519 100644
>> --- a/arch/arm/mach-at91/setup.c
>> +++ b/arch/arm/mach-at91/setup.c
>> @@ -11,6 +11,7 @@
>>   #include <linux/pm.h>
>>   #include <linux/of_address.h>
>>   #include <linux/pinctrl/machine.h>
>> +#include <linux/clk/at91.h>
>>   
>>   #include <asm/system_misc.h>
>>   #include <asm/mach/map.h>
>> @@ -18,7 +19,6 @@
>>   #include <mach/hardware.h>
>>   #include <mach/cpu.h>
>>   #include <mach/at91_dbgu.h>
>> -#include <mach/at91_pmc.h>
>>   
>>   #include "at91_shdwc.h"
>>   #include "soc.h"
>> diff --git a/drivers/usb/gadget/atmel_usba_udc.c b/drivers/usb/gadget/atmel_usba_udc.c
>> index f018017..a678537 100644
>> --- a/drivers/usb/gadget/atmel_usba_udc.c
>> +++ b/drivers/usb/gadget/atmel_usba_udc.c
>> @@ -326,7 +326,7 @@ static int vbus_is_present(struct usba_udc *udc)
>>   
>>   #if defined(CONFIG_ARCH_AT91SAM9RL)
>>   
>> -#include <mach/at91_pmc.h>
>> +#include <linux/clk/at91.h>
>>   
>>   static void toggle_bias(int is_on)
>>   {
>> diff --git a/arch/arm/mach-at91/include/mach/at91_pmc.h b/include/linux/clk/at91.h
>> similarity index 99%
>> rename from arch/arm/mach-at91/include/mach/at91_pmc.h
>> rename to include/linux/clk/at91.h
>> index c604cc6..0ce9586 100644
>> --- a/arch/arm/mach-at91/include/mach/at91_pmc.h
>> +++ b/include/linux/clk/at91.h
>> @@ -1,5 +1,5 @@
>>   /*
>> - * arch/arm/mach-at91/include/mach/at91_pmc.h
>> + * include/linux/clk/at91.h
>>    *
>>    * Copyright (C) 2005 Ivan Kokshaysky
>>    * Copyright (C) SAN People
>> -- 
>> 1.7.9.5
>>



From maxime.ripard at free-electrons.com  Tue Jul 23 18:25:12 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 00:25:12 +0200
Subject: [PATCH 10/10] ARM: sun6i: colombus: Add uart0 muxing
In-Reply-To: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374618312-19001-11-git-send-email-maxime.ripard@free-electrons.com>

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun6i-a31-colombus.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31-colombus.dts b/arch/arm/boot/dts/sun6i-a31-colombus.dts
index 0128754..1f2c0f0 100644
--- a/arch/arm/boot/dts/sun6i-a31-colombus.dts
+++ b/arch/arm/boot/dts/sun6i-a31-colombus.dts
@@ -24,6 +24,8 @@
 
 	soc at 01c20000 {
 		uart0: serial at 01c28000 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&uart0_pins_a>;
 			status = "okay";
 		};
 	};
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Tue Jul 23 18:25:11 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 00:25:11 +0200
Subject: [PATCH 09/10] ARM: sun6i: Add UART0 muxing options
In-Reply-To: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374618312-19001-10-git-send-email-maxime.ripard@free-electrons.com>

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 0443628..40a7ea6 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -77,6 +77,13 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 			#gpio-cells = <3>;
+
+			uart0_pins_a: uart0 at 0 {
+				allwinner,pins = "PH20", "PH21";
+				allwinner,function = "uart0";
+				allwinner,drive = <0>;
+				allwinner,pull = <0>;
+			};
 		};
 
 		timer at 01c20c00 {
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Tue Jul 23 18:25:10 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 00:25:10 +0200
Subject: [PATCH 08/10] ARM: sunxi: dt: Add PIO controller to A31 DTSI
In-Reply-To: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374618312-19001-9-git-send-email-maxime.ripard@free-electrons.com>

The A31 has a different set of pins than the one found on the A10 and
A13, so we will need a different compatible string, even though the IP
is the same.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index c6c19a9..0443628 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -67,6 +67,18 @@
 		reg = <0x01c20000 0x300000>;
 		ranges;
 
+		pio: pinctrl at 01c20800 {
+			compatible = "allwinner,sun6i-a31-pinctrl";
+			reg = <0x01c20800 0x400>;
+			interrupts = <0 11 1>, <0 15 1>, <0 16 1>, <0 17 1>;
+			clocks = <&osc>;
+			gpio-controller;
+			interrupt-controller;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			#gpio-cells = <3>;
+		};
+
 		timer at 01c20c00 {
 			compatible = "allwinner,sun4i-timer";
 			reg = <0x01c20c00 0xa0>;
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Tue Jul 23 18:25:08 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 00:25:08 +0200
Subject: [PATCH 06/10] ARM: sun6i: Add WITS Colombus A31 evaluation kit support
In-Reply-To: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374618312-19001-7-git-send-email-maxime.ripard@free-electrons.com>

This platform from WITS is the evaluation board for the Allwinner A31.
It features a quad-Cortex A7, 2048MB of RAM, NAND, USB, MMC, several
UART, HDMI, a 2048 x 1536 10" screen, powered by a PowerVR, etc.

Of course, most of these peripherals aren't supported yet, but support
for those will come eventually.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun6i-a31-colombus.dts | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun6i-a31-colombus.dts

diff --git a/arch/arm/boot/dts/sun6i-a31-colombus.dts b/arch/arm/boot/dts/sun6i-a31-colombus.dts
new file mode 100644
index 0000000..0128754
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31-colombus.dts
@@ -0,0 +1,30 @@
+/*
+ * Copyright 2013 Maxime Ripard
+ *
+ * Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "sun6i-a31.dtsi"
+
+/ {
+	model = "WITS A31 Colombus Evaluation Board";
+	compatible = "wits,colombus", "allwinner,sun6i-a31";
+
+	chosen {
+		bootargs = "earlyprintk console=ttyS0,115200";
+	};
+
+	soc at 01c20000 {
+		uart0: serial at 01c28000 {
+			status = "okay";
+		};
+	};
+};
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Tue Jul 23 18:25:07 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 00:25:07 +0200
Subject: [PATCH 05/10] ARM: sunxi: Add Allwinner A31 DTSI
In-Reply-To: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374618312-19001-6-git-send-email-maxime.ripard@free-electrons.com>

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/Makefile       |   3 +-
 arch/arm/boot/dts/sun6i-a31.dtsi | 155 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 157 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun6i-a31.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..1482533 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -210,7 +210,8 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
 	sun4i-a10-mini-xplus.dtb \
 	sun4i-a10-hackberry.dtb \
 	sun5i-a10s-olinuxino-micro.dtb \
-	sun5i-a13-olinuxino.dtb
+	sun5i-a13-olinuxino.dtb \
+	sun6i-a31-colombus.dtb
 dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
 	tegra20-iris-512.dtb \
 	tegra20-medcom-wide.dtb \
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
new file mode 100644
index 0000000..c6c19a9
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -0,0 +1,155 @@
+/*
+ * Copyright 2013 Maxime Ripard
+ *
+ * Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	interrupt-parent = <&gic>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <0>;
+		};
+
+		cpu at 1 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <1>;
+		};
+
+		cpu at 2 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <2>;
+		};
+
+		cpu at 3 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <3>;
+		};
+	};
+
+	memory {
+		reg = <0x40000000 0x80000000>;
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		osc: oscillator {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <24000000>;
+		};
+	};
+
+	soc at 01c20000 {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0x01c20000 0x300000>;
+		ranges;
+
+		timer at 01c20c00 {
+			compatible = "allwinner,sun4i-timer";
+			reg = <0x01c20c00 0xa0>;
+			interrupts = <
+					0 18 1
+					0 19 1
+					0 20 1
+					0 21 1
+					0 22 1
+					>;
+			clocks = <&osc>;
+		};
+
+		wdt1: watchdog at 01c20ca0 {
+			compatible = "allwinner,sun6i-wdt";
+			reg = <0x01c20ca0 0x20>;
+		};
+
+		uart0: serial at 01c28000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28000 0x400>;
+			interrupts = <0 0 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc>;
+			status = "disabled";
+		};
+
+		uart1: serial at 01c28400 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28400 0x400>;
+			interrupts = <0 1 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc>;
+			status = "disabled";
+		};
+
+		uart2: serial at 01c28800 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28800 0x400>;
+			interrupts = <0 2 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc>;
+			status = "disabled";
+		};
+
+		uart3: serial at 01c28c00 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28c00 0x400>;
+			interrupts = <0 3 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc>;
+			status = "disabled";
+		};
+
+		uart4: serial at 01c29000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c29000 0x400>;
+			interrupts = <0 4 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc>;
+			status = "disabled";
+		};
+
+		uart5: serial at 01c29400 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c29400 0x400>;
+			interrupts = <0 5 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc>;
+			status = "disabled";
+		};
+
+		gic: interrupt-controller at 01c81000 {
+			compatible = "arm,cortex-a7-gic";
+			reg = <0x01c81000 0x1000>, <0x01c82000 0x100>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
+	};
+};
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Tue Jul 23 18:25:09 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 00:25:09 +0200
Subject: [PATCH 07/10] pinctrl: sunxi: Add Allwinner A31 pins set
In-Reply-To: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374618312-19001-8-git-send-email-maxime.ripard@free-electrons.com>

The Allwinner A31 SoC uses the same IP than the one found in the
A10/A13, with only different pins. Add the pins and the associated
functions found in the A31.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/pinctrl/pinctrl-sunxi-pins.h | 820 +++++++++++++++++++++++++++++++++++
 drivers/pinctrl/pinctrl-sunxi.c      |   1 +
 2 files changed, 821 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-sunxi-pins.h b/drivers/pinctrl/pinctrl-sunxi-pins.h
index 2eeae0c..5b783cb 100644
--- a/drivers/pinctrl/pinctrl-sunxi-pins.h
+++ b/drivers/pinctrl/pinctrl-sunxi-pins.h
@@ -2005,6 +2005,821 @@ static const struct sunxi_desc_pin sun5i_a13_pins[] = {
 		  SUNXI_FUNCTION_IRQ(0x6, 12)),		/* EINT12 */
 };
 
+static const struct sunxi_desc_pin sun6i_a31_pins[] = {
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA0,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* TXD0 */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D0 */
+		SUNXI_FUNCTION(0x4, "uart1")),		/* DTR */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA1,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* TXD1 */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D1 */
+		SUNXI_FUNCTION(0x4, "uart1")),		/* DSR */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA2,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* TXD2 */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D2 */
+		SUNXI_FUNCTION(0x4, "uart1")),		/* DCD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA3,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* TXD3 */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D3 */
+		SUNXI_FUNCTION(0x4, "uart1")),		/* RING */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA4,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* TXD4 */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D4 */
+		SUNXI_FUNCTION(0x4, "uart1")),		/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA5,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* TXD5 */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D5 */
+		SUNXI_FUNCTION(0x4, "uart1")),		/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA6,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* TXD6 */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D6 */
+		SUNXI_FUNCTION(0x4, "uart1")),		/* RTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA7,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* TXD7 */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D7 */
+		SUNXI_FUNCTION(0x4, "uart1")),		/* CTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA8,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* TXCLK */
+		SUNXI_FUNCTION(0x3, "lcd1")),		/* D8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA9,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* TXEN */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D9 */
+		SUNXI_FUNCTION(0x4, "mmc3"),		/* CMD */
+		SUNXI_FUNCTION(0x5, "mmc2")),		/* CMD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA10,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* GTXCLK */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D10 */
+		SUNXI_FUNCTION(0x4, "mmc3"),		/* CLK */
+		SUNXI_FUNCTION(0x5, "mmc2")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA11,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* RXD0 */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D11 */
+		SUNXI_FUNCTION(0x4, "mmc3"),		/* D0 */
+		SUNXI_FUNCTION(0x5, "mmc2")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA12,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* RXD1 */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D12 */
+		SUNXI_FUNCTION(0x4, "mmc3"),		/* D1 */
+		SUNXI_FUNCTION(0x5, "mmc2")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA13,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* RXD2 */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D13 */
+		SUNXI_FUNCTION(0x4, "mmc3"),		/* D2 */
+		SUNXI_FUNCTION(0x5, "mmc2")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA14,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* RXD3 */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D14 */
+		SUNXI_FUNCTION(0x4, "mmc3"),		/* D3 */
+		SUNXI_FUNCTION(0x5, "mmc2")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA15,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* RXD4 */
+		SUNXI_FUNCTION(0x3, "lcd1")),		/* D15 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA16,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* RXD5 */
+		SUNXI_FUNCTION(0x3, "lcd1")),		/* D16 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA17,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* RXD6 */
+		SUNXI_FUNCTION(0x3, "lcd1")),		/* D17 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA18,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* RXD7 */
+		SUNXI_FUNCTION(0x3, "lcd1")),		/* D18 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA19,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* RXDV */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D19 */
+		SUNXI_FUNCTION(0x4, "pwm3")),		/* Positive */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA20,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* RXCLK */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D20 */
+		SUNXI_FUNCTION(0x4, "pwm3")),		/* Negative */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA21,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* TXERR */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D21 */
+		SUNXI_FUNCTION(0x4, "spi3")),		/* CS0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA22,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* RXERR */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D22 */
+		SUNXI_FUNCTION(0x4, "spi3")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA23,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* COL */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* D23 */
+		SUNXI_FUNCTION(0x4, "spi3")),		/* MOSI */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA24,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* CRS */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* CLK */
+		SUNXI_FUNCTION(0x4, "spi3")),		/* MISO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA25,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* CLKIN */
+		SUNXI_FUNCTION(0x3, "lcd1"),		/* DE */
+		SUNXI_FUNCTION(0x4, "spi3")),		/* CS1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA26,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* MDC */
+		SUNXI_FUNCTION(0x3, "lcd1")),		/* HSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA27,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "gmac"),		/* MDIO */
+		SUNXI_FUNCTION(0x3, "lcd1")),		/* VSYNC */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB0,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2s0"),		/* MCLK */
+		SUNXI_FUNCTION(0x3, "uart3"),		/* CTS */
+		SUNXI_FUNCTION(0x4, "csi")),		/* MCLK1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB1,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2s0")),		/* BCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB2,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2s0")),		/* LRCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB3,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2s0")),		/* DO0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB4,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2s0"),		/* DO1 */
+		SUNXI_FUNCTION(0x3, "uart3")),		/* RTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB5,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2s0"),		/* DO2 */
+		SUNXI_FUNCTION(0x3, "uart3"),		/* TX */
+		SUNXI_FUNCTION(0x4, "i2c3")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB6,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2s0"),		/* DO3 */
+		SUNXI_FUNCTION(0x3, "uart3"),		/* RX */
+		SUNXI_FUNCTION(0x4, "i2c3")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB7,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x3, "i2s0")),		/* DI */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC0,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* WE */
+		SUNXI_FUNCTION(0x3, "spi0")),		/* MOSI */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC1,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* ALE */
+		SUNXI_FUNCTION(0x3, "spi0")),		/* MISO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC2,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* CLE */
+		SUNXI_FUNCTION(0x3, "spi0")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC3,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0")),		/* CE1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC4,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0")),		/* CE0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC5,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0")),		/* RE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC6,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* RB0 */
+		SUNXI_FUNCTION(0x3, "mmc2"),		/* CMD */
+		SUNXI_FUNCTION(0x4, "mmc3")),		/* CMD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC7,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* RB1 */
+		SUNXI_FUNCTION(0x3, "mmc2"),		/* CLK */
+		SUNXI_FUNCTION(0x4, "mmc3")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC8,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ0 */
+		SUNXI_FUNCTION(0x3, "mmc2"),		/* D0 */
+		SUNXI_FUNCTION(0x4, "mmc3")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC9,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ1 */
+		SUNXI_FUNCTION(0x3, "mmc2"),		/* D1 */
+		SUNXI_FUNCTION(0x4, "mmc3")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC10,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ2 */
+		SUNXI_FUNCTION(0x3, "mmc2"),		/* D2 */
+		SUNXI_FUNCTION(0x4, "mmc3")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC11,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ3 */
+		SUNXI_FUNCTION(0x3, "mmc2"),		/* D3 */
+		SUNXI_FUNCTION(0x4, "mmc3")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC12,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ4 */
+		SUNXI_FUNCTION(0x3, "mmc2"),		/* D4 */
+		SUNXI_FUNCTION(0x4, "mmc3")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC13,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ5 */
+		SUNXI_FUNCTION(0x3, "mmc2"),		/* D5 */
+		SUNXI_FUNCTION(0x4, "mmc3")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC14,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ6 */
+		SUNXI_FUNCTION(0x3, "mmc2"),		/* D6 */
+		SUNXI_FUNCTION(0x4, "mmc3")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC15,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ7 */
+		SUNXI_FUNCTION(0x3, "mmc2"),		/* D7 */
+		SUNXI_FUNCTION(0x4, "mmc3")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC16,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ8 */
+		SUNXI_FUNCTION(0x3, "nand1")),		/* DQ0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC17,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ9 */
+		SUNXI_FUNCTION(0x3, "nand1")),		/* DQ1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC18,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ10 */
+		SUNXI_FUNCTION(0x3, "nand1")),		/* DQ2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC19,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ11 */
+		SUNXI_FUNCTION(0x3, "nand1")),		/* DQ3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC20,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ12 */
+		SUNXI_FUNCTION(0x3, "nand1")),		/* DQ4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC21,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ13 */
+		SUNXI_FUNCTION(0x3, "nand1")),		/* DQ5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC22,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ14 */
+		SUNXI_FUNCTION(0x3, "nand1")),		/* DQ6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC23,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQ15 */
+		SUNXI_FUNCTION(0x3, "nand1")),		/* DQ7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC24,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0"),		/* DQS */
+		SUNXI_FUNCTION(0x3, "mmc2"),		/* RST */
+		SUNXI_FUNCTION(0x4, "mmc3")),		/* RST */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC25,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0")),		/* CE2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC26,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand0")),		/* CE3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC27,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x3, "spi0")),		/* CS0 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD0,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D0 */
+		SUNXI_FUNCTION(0x3, "lvds0")),		/* VP0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD1,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D1 */
+		SUNXI_FUNCTION(0x3, "lvds0")),		/* VN0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD2,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D2 */
+		SUNXI_FUNCTION(0x3, "lvds0")),		/* VP1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD3,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D3 */
+		SUNXI_FUNCTION(0x3, "lvds0")),		/* VN1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD4,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D4 */
+		SUNXI_FUNCTION(0x3, "lvds0")),		/* VP2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD5,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D5 */
+		SUNXI_FUNCTION(0x3, "lvds0")),		/* VN2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD6,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D6 */
+		SUNXI_FUNCTION(0x3, "lvds0")),		/* VPC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD7,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D7 */
+		SUNXI_FUNCTION(0x3, "lvds0")),		/* VNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD8,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D8 */
+		SUNXI_FUNCTION(0x3, "lvds0")),		/* VP3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD9,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D9 */
+		SUNXI_FUNCTION(0x3, "lvds0")),		/* VN3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD10,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D10 */
+		SUNXI_FUNCTION(0x3, "lvds1")),		/* VP0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD11,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D11 */
+		SUNXI_FUNCTION(0x3, "lvds1")),		/* VN0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD12,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D12 */
+		SUNXI_FUNCTION(0x3, "lvds1")),		/* VP1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD13,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D13 */
+		SUNXI_FUNCTION(0x3, "lvds1")),		/* VN1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD14,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D14 */
+		SUNXI_FUNCTION(0x3, "lvds1")),		/* VP2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD15,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D15 */
+		SUNXI_FUNCTION(0x3, "lvds1")),		/* VN2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD16,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D16 */
+		SUNXI_FUNCTION(0x3, "lvds1")),		/* VPC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD17,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D17 */
+		SUNXI_FUNCTION(0x3, "lvds1")),		/* VNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD18,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D18 */
+		SUNXI_FUNCTION(0x3, "lvds1")),		/* VP3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD19,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0"),		/* D19 */
+		SUNXI_FUNCTION(0x3, "lvds1")),		/* VN3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD20,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0")),		/* D20 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD21,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0")),		/* D21 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD22,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0")),		/* D22 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD23,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0")),		/* D23 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD24,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD25,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0")),		/* DE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD26,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0")),		/* HSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD27,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "lcd0")),		/* VSYNC */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE0,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* PCLK */
+		SUNXI_FUNCTION(0x3, "ts")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE1,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* MCLK */
+		SUNXI_FUNCTION(0x3, "ts")),		/* ERR */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE2,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* HSYNC */
+		SUNXI_FUNCTION(0x3, "ts")),		/* SYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE3,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* VSYNC */
+		SUNXI_FUNCTION(0x3, "ts")),		/* DVLD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE4,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* D0 */
+		SUNXI_FUNCTION(0x3, "uart5")),		/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE5,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* D1 */
+		SUNXI_FUNCTION(0x3, "uart5")),		/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE6,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* D2 */
+		SUNXI_FUNCTION(0x3, "uart5")),		/* RTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE7,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* D3 */
+		SUNXI_FUNCTION(0x3, "uart5")),		/* CTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE8,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* D4 */
+		SUNXI_FUNCTION(0x3, "ts")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE9,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* D5 */
+		SUNXI_FUNCTION(0x3, "ts")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE10,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* D6 */
+		SUNXI_FUNCTION(0x3, "ts")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE11,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* D7 */
+		SUNXI_FUNCTION(0x3, "ts")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE12,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* D8 */
+		SUNXI_FUNCTION(0x3, "ts")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE13,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* D9 */
+		SUNXI_FUNCTION(0x3, "ts")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE14,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* D10 */
+		SUNXI_FUNCTION(0x3, "ts")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE15,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi"),		/* D11 */
+		SUNXI_FUNCTION(0x3, "ts")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE16,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "csi")),		/* MIPI CSI MCLK */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF0,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "mmc0"),		/* D1 */
+		SUNXI_FUNCTION(0x4, "jtag")),		/* MS1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF1,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "mmc0"),		/* D0 */
+		SUNXI_FUNCTION(0x4, "jtag")),		/* DI1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF2,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "mmc0"),		/* CLK */
+		SUNXI_FUNCTION(0x4, "uart0")),		/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF3,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "mmc0"),		/* CMD */
+		SUNXI_FUNCTION(0x4, "jtag")),		/* DO1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF4,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "mmc0"),		/* D3 */
+		SUNXI_FUNCTION(0x4, "uart0")),		/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF5,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "mmc0"),		/* D2 */
+		SUNXI_FUNCTION(0x4, "jtag")),		/* CK1 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG0,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "mmc1")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG1,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "mmc1")),		/* CMD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG2,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "mmc1")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG3,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "mmc1")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG4,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "mmc1")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG5,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "mmc1")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG6,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "uart2")),		/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG7,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "uart2")),		/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG8,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "uart2")),		/* RTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG9,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "uart2")),		/* CTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG10,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2c3"),		/* SCK */
+		SUNXI_FUNCTION(0x3, "usb")),		/* DP3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG11,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2c3"),		/* SDA */
+		SUNXI_FUNCTION(0x3, "usb")),		/* DM3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG12,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "spi1"),		/* CS1 */
+		SUNXI_FUNCTION(0x3, "i2s1")),		/* MCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG13,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "spi1"),		/* CS0 */
+		SUNXI_FUNCTION(0x3, "i2s1")),		/* BCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG14,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "spi1"),		/* CLK */
+		SUNXI_FUNCTION(0x3, "i2s1")),		/* LRCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG15,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "spi1"),		/* MOSI */
+		SUNXI_FUNCTION(0x3, "i2s1")),		/* DIN */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG16,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "spi1"),		/* MISO */
+		SUNXI_FUNCTION(0x3, "i2s1")),		/* DOUT */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG17,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "uart4")),		/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG18,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "uart4")),		/* RX */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH0,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand1")),		/* WE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH1,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand1")),		/* ALE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH2,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand1")),		/* CLE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH3,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand1")),		/* CE1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH4,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand1")),		/* CE0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH5,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand1")),		/* RE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH6,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand1")),		/* RB0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH7,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand1")),		/* RB1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH8,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand1")),		/* DQS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH9,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "spi2"),		/* CS0 */
+		SUNXI_FUNCTION(0x3, "jtag"),		/* MS0 */
+		SUNXI_FUNCTION(0x4, "pwm1")),		/* Positive */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH10,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "spi2"),		/* CLK */
+		SUNXI_FUNCTION(0x3, "jtag"),		/* CK0 */
+		SUNXI_FUNCTION(0x4, "pwm1")),		/* Negative */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH11,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "spi2"),		/* MOSI */
+		SUNXI_FUNCTION(0x3, "jtag"),		/* DO0 */
+		SUNXI_FUNCTION(0x4, "pwm2")),		/* Positive */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH12,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "spi2"),		/* MISO */
+		SUNXI_FUNCTION(0x3, "jtag"),		/* DI0 */
+		SUNXI_FUNCTION(0x4, "pwm2")),		/* Negative */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH13,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "pwm0")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH14,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2c0")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH15,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2c0")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH16,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2c1")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH17,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2c1")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH18,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2c2")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH19,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "i2c2")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH20,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "uart0")),		/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH21,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "uart0")),		/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH22,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH23,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH24,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH25,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH26,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH27,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH28,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH29,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand1")),		/* CE2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH30,
+		SUNXI_FUNCTION(0x0, "gpio_in"),
+		SUNXI_FUNCTION(0x1, "gpio_out"),
+		SUNXI_FUNCTION(0x2, "nand1")),		/* CE3 */
+};
+
 static const struct sunxi_pinctrl_desc sun4i_a10_pinctrl_data = {
 	.pins = sun4i_a10_pins,
 	.npins = ARRAY_SIZE(sun4i_a10_pins),
@@ -2020,4 +2835,9 @@ static const struct sunxi_pinctrl_desc sun5i_a13_pinctrl_data = {
 	.npins = ARRAY_SIZE(sun5i_a13_pins),
 };
 
+static const struct sunxi_pinctrl_desc sun6i_a31_pinctrl_data = {
+	.pins = sun6i_a31_pins,
+	.npins = ARRAY_SIZE(sun6i_a31_pins),
+};
+
 #endif /* __PINCTRL_SUNXI_PINS_H */
diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
index c47fd1e..5985e60 100644
--- a/drivers/pinctrl/pinctrl-sunxi.c
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -631,6 +631,7 @@ static struct of_device_id sunxi_pinctrl_match[] = {
 	{ .compatible = "allwinner,sun4i-a10-pinctrl", .data = (void *)&sun4i_a10_pinctrl_data },
 	{ .compatible = "allwinner,sun5i-a10s-pinctrl", .data = (void *)&sun5i_a10s_pinctrl_data },
 	{ .compatible = "allwinner,sun5i-a13-pinctrl", .data = (void *)&sun5i_a13_pinctrl_data },
+	{ .compatible = "allwinner,sun6i-a31-pinctrl", .data = (void *)&sun6i_a31_pinctrl_data },
 	{}
 };
 MODULE_DEVICE_TABLE(of, sunxi_pinctrl_match);
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Tue Jul 23 18:28:23 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 00:28:23 +0200
Subject: [PATCH 1/2] clk: sunxi: Add A10s gates
In-Reply-To: <1374618504-19391-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618504-19391-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374618504-19391-2-git-send-email-maxime.ripard@free-electrons.com>

The Allwinner A10s has a slightly different gates set than the A10 and
A13, so add these gates to the clk driver.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 412912b..db1c45b 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -341,6 +341,10 @@ static const __initconst struct gates_data sun4i_ahb_gates_data = {
 	.mask = {0x7F77FFF, 0x14FB3F},
 };
 
+static const __initconst struct gates_data sun5i_a10s_ahb_gates_data = {
+	.mask = {0x147667e7, 0x185915},
+};
+
 static const __initconst struct gates_data sun5i_a13_ahb_gates_data = {
 	.mask = {0x107067e7, 0x185111},
 };
@@ -349,6 +353,10 @@ static const __initconst struct gates_data sun4i_apb0_gates_data = {
 	.mask = {0x4EF},
 };
 
+static const __initconst struct gates_data sun5i_a10s_apb0_gates_data = {
+	.mask = {0x469},
+};
+
 static const __initconst struct gates_data sun5i_a13_apb0_gates_data = {
 	.mask = {0x61},
 };
@@ -357,6 +365,10 @@ static const __initconst struct gates_data sun4i_apb1_gates_data = {
 	.mask = {0xFF00F7},
 };
 
+static const __initconst struct gates_data sun5i_a10s_apb1_gates_data = {
+	.mask = {0xf0007},
+};
+
 static const __initconst struct gates_data sun5i_a13_apb1_gates_data = {
 	.mask = {0xa0007},
 };
@@ -442,10 +454,13 @@ static const __initconst struct of_device_id clk_mux_match[] = {
 static const __initconst struct of_device_id clk_gates_match[] = {
 	{.compatible = "allwinner,sun4i-axi-gates-clk", .data = &sun4i_axi_gates_data,},
 	{.compatible = "allwinner,sun4i-ahb-gates-clk", .data = &sun4i_ahb_gates_data,},
+	{.compatible = "allwinner,sun5i-a10s-ahb-gates-clk", .data = &sun5i_a10s_ahb_gates_data,},
 	{.compatible = "allwinner,sun5i-a13-ahb-gates-clk", .data = &sun5i_a13_ahb_gates_data,},
 	{.compatible = "allwinner,sun4i-apb0-gates-clk", .data = &sun4i_apb0_gates_data,},
+	{.compatible = "allwinner,sun5i-a10s-apb0-gates-clk", .data = &sun5i_a10s_apb0_gates_data,},
 	{.compatible = "allwinner,sun5i-a13-apb0-gates-clk", .data = &sun5i_a13_apb0_gates_data,},
 	{.compatible = "allwinner,sun4i-apb1-gates-clk", .data = &sun4i_apb1_gates_data,},
+	{.compatible = "allwinner,sun5i-a10s-apb1-gates-clk", .data = &sun5i_a10s_apb1_gates_data,},
 	{.compatible = "allwinner,sun5i-a13-apb1-gates-clk", .data = &sun5i_a13_apb1_gates_data,},
 	{}
 };
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Tue Jul 23 18:28:24 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 00:28:24 +0200
Subject: [PATCH 2/2] ARM: sun5i: dt: Use the A10s gates in the DTSI
In-Reply-To: <1374618504-19391-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618504-19391-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374618504-19391-3-git-send-email-maxime.ripard@free-electrons.com>

The A10s has only a subset of the A10 gates. Now that the clock driver
has support for this gates set, switch to it in the DTSI.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun5i-a10s.dtsi | 36 ++++++++++++++----------------------
 1 file changed, 14 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 0f0881a..b8fc1c2 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -95,20 +95,16 @@
 
 		ahb_gates: ahb_gates at 01c20060 {
 			#clock-cells = <1>;
-			compatible = "allwinner,sun4i-ahb-gates-clk";
+			compatible = "allwinner,sun5i-a10s-ahb-gates-clk";
 			reg = <0x01c20060 0x8>;
 			clocks = <&ahb>;
-			clock-output-names = "ahb_usb0", "ahb_ehci0",
-				"ahb_ohci0", "ahb_ehci1", "ahb_ohci1", "ahb_ss",
-				"ahb_dma", "ahb_bist", "ahb_mmc0", "ahb_mmc1",
-				"ahb_mmc2", "ahb_mmc3", "ahb_ms", "ahb_nand",
-				"ahb_sdram", "ahb_ace",	"ahb_emac", "ahb_ts",
-				"ahb_spi0", "ahb_spi1", "ahb_spi2", "ahb_spi3",
-				"ahb_pata", "ahb_sata", "ahb_gps", "ahb_ve",
-				"ahb_tvd", "ahb_tve0", "ahb_tve1", "ahb_lcd0",
-				"ahb_lcd1", "ahb_csi0", "ahb_csi1", "ahb_hdmi",
-				"ahb_de_be0", "ahb_de_be1", "ahb_de_fe0",
-				"ahb_de_fe1", "ahb_mp", "ahb_mali400";
+			clock-output-names = "ahb_usbotg", "ahb_ehci", "ahb_ohci",
+				"ahb_ss", "ahb_dma", "ahb_bist", "ahb_mmc0",
+				"ahb_mmc1", "ahb_mmc2", "ahb_nand", "ahb_sdram",
+				"ahb_emac", "ahb_ts", "ahb_spi0", "ahb_spi1",
+				"ahb_spi2", "ahb_gps", "ahb_stimer", "ahb_ve",
+				"ahb_tve", "ahb_lcd", "ahb_csi", "ahb_hdmi",
+				"ahb_de_be", "ahb_de_fe", "ahb_iep", "ahb_mali400";
 		};
 
 		apb0: apb0 at 01c20054 {
@@ -120,12 +116,11 @@
 
 		apb0_gates: apb0_gates at 01c20068 {
 			#clock-cells = <1>;
-			compatible = "allwinner,sun4i-apb0-gates-clk";
+			compatible = "allwinner,sun5i-a10s-apb0-gates-clk";
 			reg = <0x01c20068 0x4>;
 			clocks = <&apb0>;
-			clock-output-names = "apb0_codec", "apb0_spdif",
-				"apb0_ac97", "apb0_iis", "apb0_pio", "apb0_ir0",
-				"apb0_ir1", "apb0_keypad";
+			clock-output-names = "apb0_codec", "apb0_iis", "apb0_pio",
+				"apb0_ir", "apb0_keypad";
 		};
 
 		/* dummy is pll62 */
@@ -145,15 +140,12 @@
 
 		apb1_gates: apb1_gates at 01c2006c {
 			#clock-cells = <1>;
-			compatible = "allwinner,sun4i-apb1-gates-clk";
+			compatible = "allwinner,sun5i-a10s-apb1-gates-clk";
 			reg = <0x01c2006c 0x4>;
 			clocks = <&apb1>;
 			clock-output-names = "apb1_i2c0", "apb1_i2c1",
-				"apb1_i2c2", "apb1_can", "apb1_scr",
-				"apb1_ps20", "apb1_ps21", "apb1_uart0",
-				"apb1_uart1", "apb1_uart2", "apb1_uart3",
-				"apb1_uart4", "apb1_uart5", "apb1_uart6",
-				"apb1_uart7";
+				"apb1_i2c2", "apb1_uart0", "apb1_uart1",
+				"apb1_uart2", "apb1_uart3";
 		};
 	};
 
-- 
1.8.3.2



From b.brezillon at overkiz.com  Tue Jul 23 18:29:32 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Wed, 24 Jul 2013 00:29:32 +0200
Subject: [PATCH v2 17/42] ARM: at91: move at91sam9g45 SoC to new at91
 clk implem
In-Reply-To: <1374072548-19702-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <1374072548-19702-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <51EF03CC.2080303@overkiz.com>

Le 17/07/2013 16:49, Boris BREZILLON a ?crit :
> This patch removes all references to the old at91 clks implementation and
> make use of the new at91 clk implem for at91sam9g45 SoC.
>
> All dt specific lookups are removed (handled in clk device tree binding).
>
> Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
> ---
>   arch/arm/mach-at91/at91sam9g45.c         |  702 ++++++++++++++++++------------
>   arch/arm/mach-at91/at91sam9g45_devices.c |    1 -
>   2 files changed, 424 insertions(+), 279 deletions(-)
>
> diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
> index 29ba2ca..a24915a 100644
> --- a/arch/arm/mach-at91/at91sam9g45.c
> +++ b/arch/arm/mach-at91/at91sam9g45.c
> @@ -24,7 +24,6 @@
>   #include "at91_aic.h"
>   #include "soc.h"
>   #include "generic.h"
> -#include "clock.h"
>   #include "sam9_smc.h"
>   
>   /* --------------------------------------------------------------------
> @@ -34,299 +33,446 @@
>   /*
>    * The peripheral clocks.
>    */
> -static struct clk pioA_clk = {
> -	.name		= "pioA_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_PIOA,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk pioB_clk = {
> -	.name		= "pioB_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_PIOB,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk pioC_clk = {
> -	.name		= "pioC_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_PIOC,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk pioDE_clk = {
> -	.name		= "pioDE_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_PIODE,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk trng_clk = {
> -	.name		= "trng_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_TRNG,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk usart0_clk = {
> -	.name		= "usart0_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_US0,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk usart1_clk = {
> -	.name		= "usart1_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_US1,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk usart2_clk = {
> -	.name		= "usart2_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_US2,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk usart3_clk = {
> -	.name		= "usart3_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_US3,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk mmc0_clk = {
> -	.name		= "mci0_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_MCI0,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk twi0_clk = {
> -	.name		= "twi0_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_TWI0,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk twi1_clk = {
> -	.name		= "twi1_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_TWI1,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk spi0_clk = {
> -	.name		= "spi0_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_SPI0,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk spi1_clk = {
> -	.name		= "spi1_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_SPI1,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk ssc0_clk = {
> -	.name		= "ssc0_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_SSC0,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk ssc1_clk = {
> -	.name		= "ssc1_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_SSC1,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk tcb0_clk = {
> -	.name		= "tcb0_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_TCB,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk pwm_clk = {
> -	.name		= "pwm_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_PWMC,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk tsc_clk = {
> -	.name		= "tsc_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_TSC,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk dma_clk = {
> -	.name		= "dma_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_DMA,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk uhphs_clk = {
> -	.name		= "uhphs_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_UHPHS,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk lcdc_clk = {
> -	.name		= "lcdc_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_LCDC,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk ac97_clk = {
> -	.name		= "ac97_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_AC97C,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk macb_clk = {
> -	.name		= "pclk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_EMAC,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk isi_clk = {
> -	.name		= "isi_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_ISI,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk udphs_clk = {
> -	.name		= "udphs_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_UDPHS,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -static struct clk mmc1_clk = {
> -	.name		= "mci1_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_MCI1,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -
> -/* Video decoder clock - Only for sam9m10/sam9m11 */
> -static struct clk vdec_clk = {
> -	.name		= "vdec_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_VDEC,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -
> -static struct clk adc_op_clk = {
> -	.name		= "adc_op_clk",
> -	.type		= CLK_TYPE_PERIPHERAL,
> -	.rate_hz	= 13200000,
> -};
> -
> -/* AES/TDES/SHA clock - Only for sam9m11/sam9g56 */
> -static struct clk aestdessha_clk = {
> -	.name		= "aestdessha_clk",
> -	.pmc_mask	= 1 << AT91SAM9G45_ID_AESTDESSHA,
> -	.type		= CLK_TYPE_PERIPHERAL,
> -};
> -
> -static struct clk *periph_clocks[] __initdata = {
> -	&pioA_clk,
> -	&pioB_clk,
> -	&pioC_clk,
> -	&pioDE_clk,
> -	&trng_clk,
> -	&usart0_clk,
> -	&usart1_clk,
> -	&usart2_clk,
> -	&usart3_clk,
> -	&mmc0_clk,
> -	&twi0_clk,
> -	&twi1_clk,
> -	&spi0_clk,
> -	&spi1_clk,
> -	&ssc0_clk,
> -	&ssc1_clk,
> -	&tcb0_clk,
> -	&pwm_clk,
> -	&tsc_clk,
> -	&dma_clk,
> -	&uhphs_clk,
> -	&lcdc_clk,
> -	&ac97_clk,
> -	&macb_clk,
> -	&isi_clk,
> -	&udphs_clk,
> -	&mmc1_clk,
> -	&adc_op_clk,
> -	&aestdessha_clk,
> -	// irq0
> -};
> -
> -static struct clk_lookup periph_clocks_lookups[] = {
> -	/* One additional fake clock for macb_hclk */
> -	CLKDEV_CON_ID("hclk", &macb_clk),
> -	/* One additional fake clock for ohci */
> -	CLKDEV_CON_ID("ohci_clk", &uhphs_clk),
> -	CLKDEV_CON_DEV_ID("hclk", "at91sam9g45-lcdfb.0", &lcdc_clk),
> -	CLKDEV_CON_DEV_ID("hclk", "at91sam9g45es-lcdfb.0", &lcdc_clk),
> -	CLKDEV_CON_DEV_ID("ehci_clk", "atmel-ehci", &uhphs_clk),
> -	CLKDEV_CON_DEV_ID("hclk", "atmel_usba_udc", &utmi_clk),
> -	CLKDEV_CON_DEV_ID("pclk", "atmel_usba_udc", &udphs_clk),
> -	CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.0", &mmc0_clk),
> -	CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.1", &mmc1_clk),
> -	CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk),
> -	CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.1", &spi1_clk),
> -	CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tcb0_clk),
> -	CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tcb0_clk),
> -	CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.0", &twi0_clk),
> -	CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.1", &twi1_clk),
> -	CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", &ssc0_clk),
> -	CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.1", &ssc1_clk),
> -	CLKDEV_CON_DEV_ID("pclk", "fff9c000.ssc", &ssc0_clk),
> -	CLKDEV_CON_DEV_ID("pclk", "fffa0000.ssc", &ssc1_clk),
> -	CLKDEV_CON_DEV_ID(NULL, "atmel-trng", &trng_clk),
> -	CLKDEV_CON_DEV_ID(NULL, "atmel_sha", &aestdessha_clk),
> -	CLKDEV_CON_DEV_ID(NULL, "atmel_tdes", &aestdessha_clk),
> -	CLKDEV_CON_DEV_ID(NULL, "atmel_aes", &aestdessha_clk),
> -	/* more usart lookup table for DT entries */
> -	CLKDEV_CON_DEV_ID("usart", "ffffee00.serial", &mck),
> -	CLKDEV_CON_DEV_ID("usart", "fff8c000.serial", &usart0_clk),
> -	CLKDEV_CON_DEV_ID("usart", "fff90000.serial", &usart1_clk),
> -	CLKDEV_CON_DEV_ID("usart", "fff94000.serial", &usart2_clk),
> -	CLKDEV_CON_DEV_ID("usart", "fff98000.serial", &usart3_clk),
> -	/* more tc lookup table for DT entries */
> -	CLKDEV_CON_DEV_ID("t0_clk", "fff7c000.timer", &tcb0_clk),
> -	CLKDEV_CON_DEV_ID("t0_clk", "fffd4000.timer", &tcb0_clk),
> -	CLKDEV_CON_DEV_ID("hclk", "700000.ohci", &uhphs_clk),
> -	CLKDEV_CON_DEV_ID("ehci_clk", "800000.ehci", &uhphs_clk),
> -	CLKDEV_CON_DEV_ID("mci_clk", "fff80000.mmc", &mmc0_clk),
> -	CLKDEV_CON_DEV_ID("mci_clk", "fffd0000.mmc", &mmc1_clk),
> -	CLKDEV_CON_DEV_ID(NULL, "fff84000.i2c", &twi0_clk),
> -	CLKDEV_CON_DEV_ID(NULL, "fff88000.i2c", &twi1_clk),
> -	CLKDEV_CON_DEV_ID("spi_clk", "fffa4000.spi", &spi0_clk),
> -	CLKDEV_CON_DEV_ID("spi_clk", "fffa8000.spi", &spi1_clk),
> -	CLKDEV_CON_DEV_ID("hclk", "600000.gadget", &utmi_clk),
> -	CLKDEV_CON_DEV_ID("pclk", "600000.gadget", &udphs_clk),
> -	/* fake hclk clock */
> -	CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &uhphs_clk),
> -	CLKDEV_CON_DEV_ID(NULL, "fffff200.gpio", &pioA_clk),
> -	CLKDEV_CON_DEV_ID(NULL, "fffff400.gpio", &pioB_clk),
> -	CLKDEV_CON_DEV_ID(NULL, "fffff600.gpio", &pioC_clk),
> -	CLKDEV_CON_DEV_ID(NULL, "fffff800.gpio", &pioDE_clk),
> -	CLKDEV_CON_DEV_ID(NULL, "fffffa00.gpio", &pioDE_clk),
> -
> -	CLKDEV_CON_ID("pioA", &pioA_clk),
> -	CLKDEV_CON_ID("pioB", &pioB_clk),
> -	CLKDEV_CON_ID("pioC", &pioC_clk),
> -	CLKDEV_CON_ID("pioD", &pioDE_clk),
> -	CLKDEV_CON_ID("pioE", &pioDE_clk),
> -	/* Fake adc clock */
> -	CLKDEV_CON_ID("adc_clk", &tsc_clk),
> -};
> -
> -static struct clk_lookup usart_clocks_lookups[] = {
> -	CLKDEV_CON_DEV_ID("usart", "atmel_usart.0", &mck),
> -	CLKDEV_CON_DEV_ID("usart", "atmel_usart.1", &usart0_clk),
> -	CLKDEV_CON_DEV_ID("usart", "atmel_usart.2", &usart1_clk),
> -	CLKDEV_CON_DEV_ID("usart", "atmel_usart.3", &usart2_clk),
> -	CLKDEV_CON_DEV_ID("usart", "atmel_usart.4", &usart3_clk),
> +static struct clk_lookup pioA_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "pioA_clk", NULL),
> +	CLKDEV_INIT(NULL, "pioA", NULL),
> +};
> +
> +static struct clk_lookup pioB_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "pioB_clk", NULL),
> +	CLKDEV_INIT(NULL, "pioB", NULL),
> +};
> +
> +static struct clk_lookup pioC_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "pioC_clk", NULL),
> +	CLKDEV_INIT(NULL, "pioC", NULL),
> +};
> +
> +static struct clk_lookup pioDE_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "pioDE_clk", NULL),
> +	CLKDEV_INIT(NULL, "pioD", NULL),
> +	CLKDEV_INIT(NULL, "pioE", NULL),
> +};
> +
> +static struct clk_lookup trng_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "trng_clk", NULL),
> +	CLKDEV_INIT("atmel-trng", NULL, NULL),
> +};
> +
> +static struct clk_lookup usart0_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "usart0_clk", NULL),
> +	CLKDEV_INIT("atmel_usart.1", "usart", NULL),
> +};
> +
> +static struct clk_lookup usart1_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "usart1_clk", NULL),
> +	CLKDEV_INIT("atmel_usart.2", "usart", NULL),
> +};
> +
> +static struct clk_lookup usart2_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "usart2_clk", NULL),
> +	CLKDEV_INIT("atmel_usart.3", "usart", NULL),
> +};
> +
> +static struct clk_lookup usart3_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "usart3_clk", NULL),
> +	CLKDEV_INIT("atmel_usart.4", "usart", NULL),
> +};
> +
> +static struct clk_lookup mci0_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "mci0_clk", NULL),
> +	CLKDEV_INIT("atmel_mci.0", "mci_clk", NULL),
> +};
> +
> +static struct clk_lookup twi0_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "twi0_clk", NULL),
> +	CLKDEV_INIT("i2c-at91sam9g10.0", NULL, NULL),
> +};
> +
> +static struct clk_lookup twi1_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "twi1_clk", NULL),
> +	CLKDEV_INIT("i2c-at91sam9g10.1", NULL, NULL),
> +};
> +
> +static struct clk_lookup spi0_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "spi0_clk", NULL),
> +	CLKDEV_INIT("atmel_spi.0", "spi_clk", NULL),
> +};
> +
> +static struct clk_lookup spi1_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "spi0_clk", NULL),
> +	CLKDEV_INIT("atmel_spi.1", "spi_clk", NULL),
> +};
> +
> +static struct clk_lookup ssc0_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "ssc0_clk", NULL),
> +	CLKDEV_INIT("at91sam9g45_ssc.0", "pclk", NULL),
> +};
> +
> +static struct clk_lookup ssc1_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "ssc1_clk", NULL),
> +	CLKDEV_INIT("at91sam9g45_ssc.0", "pclk", NULL),
> +};
> +
> +static struct clk_lookup tcb0_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "tcb0_clk", NULL),
> +	CLKDEV_INIT("atmel_tcb.0", "t0_clk", NULL),
> +	CLKDEV_INIT("atmel_tcb.1", "t0_clk", NULL),
> +};
> +
> +static struct clk_lookup pwm_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "pwm_clk", NULL),
> +};
> +
> +static struct clk_lookup tsc_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "tsc_clk", NULL),
> +	CLKDEV_INIT("adc_clk", NULL, NULL),
> +};
> +
> +static struct clk_lookup dma_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "dma_clk", NULL),
> +};
> +
> +static struct clk_lookup uhphs_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "uhphs_clk", NULL),
> +	CLKDEV_INIT(NULL, "ohci_clk", NULL),
> +	CLKDEV_INIT("atmel-ehci", "ehci_clk", NULL),
> +	CLKDEV_INIT("at91_ohci", "hclk", NULL),
> +};
> +
> +static struct clk_lookup lcdc_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "lcdc_clk", NULL),
> +	CLKDEV_INIT("hclk", "at91sam9g45-lcdfb.0", NULL),
> +	CLKDEV_INIT("hclk", "at91sam9g45es-lcdfb.0", NULL),
> +};
> +
> +static struct clk_lookup ac97_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "ac97_clk", NULL),
> +};
> +
> +static struct clk_lookup macb_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "pclk", NULL),
> +	CLKDEV_INIT(NULL, "hclk", NULL),
> +};
> +
> +static struct clk_lookup isi_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "isi_clk", NULL),
> +};
> +
> +static struct clk_lookup udphs_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "udphs_clk", NULL),
> +	CLKDEV_INIT("atmel_usba_udc", "pclk", NULL),
> +};
> +
> +static struct clk_lookup aestdessha_clk_lookup[] = {
> +	CLKDEV_INIT("atmel_sha", NULL, NULL),
> +	CLKDEV_INIT("atmel_tdes", NULL, NULL),
> +	CLKDEV_INIT("atmel_aes", NULL, NULL),
> +};
> +
> +static struct clk_lookup mci1_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "mci1_clk", NULL),
> +	CLKDEV_INIT("atmel_mci.1", "mci_clk", NULL),
> +};
> +
> +static struct clk_lookup vdec_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "vdec_clk", NULL),
> +};
> +
> +static size_t periph_clock_lookup_sizes[] __initdata = {
> +	0,
> +	0,
> +	ARRAY_SIZE(pioA_clk_lookup),
> +	ARRAY_SIZE(pioB_clk_lookup),
> +	ARRAY_SIZE(pioC_clk_lookup),
> +	ARRAY_SIZE(pioDE_clk_lookup),
> +	ARRAY_SIZE(trng_clk_lookup),
> +	ARRAY_SIZE(usart0_clk_lookup),
> +	ARRAY_SIZE(usart1_clk_lookup),
> +	ARRAY_SIZE(usart2_clk_lookup),
> +	ARRAY_SIZE(usart3_clk_lookup),
> +	ARRAY_SIZE(mci0_clk_lookup),
> +	ARRAY_SIZE(twi0_clk_lookup),
> +	ARRAY_SIZE(twi1_clk_lookup),
> +	ARRAY_SIZE(spi0_clk_lookup),
> +	ARRAY_SIZE(spi1_clk_lookup),
> +	ARRAY_SIZE(ssc0_clk_lookup),
> +	ARRAY_SIZE(ssc1_clk_lookup),
> +	ARRAY_SIZE(tcb0_clk_lookup),
> +	ARRAY_SIZE(pwm_clk_lookup),
> +	ARRAY_SIZE(tsc_clk_lookup),
> +	ARRAY_SIZE(dma_clk_lookup),
> +	ARRAY_SIZE(uhphs_clk_lookup),
> +	ARRAY_SIZE(lcdc_clk_lookup),
> +	ARRAY_SIZE(ac97_clk_lookup),
> +	ARRAY_SIZE(macb_clk_lookup),
> +	ARRAY_SIZE(isi_clk_lookup),
> +	ARRAY_SIZE(udphs_clk_lookup),
> +	0,
> +	ARRAY_SIZE(mci1_clk_lookup),
> +};
> +
> +static struct clk_lookup *periph_clock_lookups[] __initdata = {
> +	NULL,
> +	NULL,
> +	pioA_clk_lookup,
> +	pioB_clk_lookup,
> +	pioC_clk_lookup,
> +	pioDE_clk_lookup,
> +	trng_clk_lookup,
> +	usart0_clk_lookup,
> +	usart1_clk_lookup,
> +	usart2_clk_lookup,
> +	usart3_clk_lookup,
> +	mci0_clk_lookup,
> +	twi0_clk_lookup,
> +	twi1_clk_lookup,
> +	spi0_clk_lookup,
> +	spi1_clk_lookup,
> +	ssc0_clk_lookup,
> +	ssc1_clk_lookup,
> +	tcb0_clk_lookup,
> +	pwm_clk_lookup,
> +	tsc_clk_lookup,
> +	dma_clk_lookup,
> +	uhphs_clk_lookup,
> +	lcdc_clk_lookup,
> +	ac97_clk_lookup,
> +	macb_clk_lookup,
> +	isi_clk_lookup,
> +	udphs_clk_lookup,
> +	NULL,
> +	mci1_clk_lookup,
> +};
> +
> +
> +/*
> + * The system clocks.
> + */
> +static struct clk_lookup ddr_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "ddrck", NULL),
> +};
> +
> +static struct clk_lookup uhp_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "uhpck", NULL),
> +};
> +
> +static struct clk_lookup pck0_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "pck0", NULL),
> +};
> +
> +static struct clk_lookup pck1_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "pck1", NULL),
> +};
> +
> +static size_t system_clock_lookup_sizes[] __initdata = {
> +	0,
> +	0,
> +	ARRAY_SIZE(ddr_clk_lookup),
> +	0,
> +	0,
> +	0,
> +	ARRAY_SIZE(uhp_clk_lookup),
> +	0,
> +	ARRAY_SIZE(pck0_clk_lookup),
> +	ARRAY_SIZE(pck1_clk_lookup),
> +};
> +
> +static struct clk_lookup *system_clock_lookups[] __initdata = {
> +	NULL,
> +	NULL,
> +	ddr_clk_lookup,
> +	NULL,
> +	NULL,
> +	NULL,
> +	uhp_clk_lookup,
> +	NULL,
> +	pck0_clk_lookup,
> +	pck1_clk_lookup,
>   };
>   
>   /*
>    * The two programmable clocks.
>    * You must configure pin multiplexing to bring these signals out.
>    */
> -static struct clk pck0 = {
> -	.name		= "pck0",
> -	.pmc_mask	= AT91_PMC_PCK0,
> -	.type		= CLK_TYPE_PROGRAMMABLE,
> -	.id		= 0,
> +static const char *prog_clock_parent_names[] __initdata = {
> +	"clk32k",
> +	"main",
> +	"plladiv",
> +	"utmi_clk",
> +	"mck",
>   };
> -static struct clk pck1 = {
> -	.name		= "pck1",
> -	.pmc_mask	= AT91_PMC_PCK1,
> -	.type		= CLK_TYPE_PROGRAMMABLE,
> -	.id		= 1,
> +
> +static const char *prog_clock_names[] __initdata = {
> +	"prog0",
> +	"prog1",
> +};
> +
> +/*
> + * The pll clocks.
> + */
> +static struct clk_lookup pll_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "plla", NULL),
> +};
> +
> +static struct clk_range at91sam9g45_plla_output[] = {
> +	CLK_RANGE(745000000, 800000000),
> +	CLK_RANGE(695000000, 750000000),
> +	CLK_RANGE(645000000, 700000000),
> +	CLK_RANGE(595000000, 650000000),
> +	CLK_RANGE(545000000, 600000000),
> +	CLK_RANGE(495000000, 550000000),
> +	CLK_RANGE(445000000, 500000000),
> +	CLK_RANGE(400000000, 450000000),
> +};
> +static u8 at91sam9g45_plla_out[] = {0, 1, 2, 3, 0, 1, 2, 3};
> +static u16 at91sam9g45_plla_icpll[] = {0, 0, 0, 0, 1, 1, 1, 1};
> +
> +struct clk_pll_characteristics at91sam9g45_plla_characteristics = {
> +	.input = CLK_RANGE(2000000, 32000000),
> +	.num_output = ARRAY_SIZE(at91sam9g45_plla_output),
> +	.output = at91sam9g45_plla_output,
> +	.out = at91sam9g45_plla_out,
> +	.icpll = at91sam9g45_plla_icpll,
> +};
> +
> +
> +/*
> + * The master clock.
> + */
> +static struct clk_lookup mck_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "mck", NULL),
> +	CLKDEV_INIT("atmel_usart.0", "usart", NULL),
> +};
> +
> +struct clk_master_characteristics at91sam9g45_master_characteristics = {
> +	.output = CLK_RANGE(0, 133000000),
> +	.have_div3_pres = 0,
> +	.divisors = {1, 2, 4, 3},
> +};
> +
> +static const char *master_clock_parent_names[] __initdata = {
> +	"clk32k",
> +	"main",
> +	"plladiv",
> +	"utmi_clk",
> +};
> +
> +/*
> + * UTMI clock.
> + */
> +static struct clk_lookup utmi_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "utmi_clk", NULL),
> +	CLKDEV_INIT("atmel_usba_udc", "hclk", NULL),
> +};
> +
> +/*
> + * USB clock.
> + */
> +static const char *usb_clock_parent_names[] __initdata = {
> +	"plladiv",
> +	"utmi_clk",
> +};
> +
> +static struct clk_lookup usb_clk_lookup[] = {
> +	CLKDEV_INIT(NULL, "usb_clk", NULL),
>   };
>   
>   static void __init at91sam9g45_register_clocks(void)
>   {
>   	int i;
> +	int k;
> +	size_t size;
> +	struct clk *clk;
> +	const char *name;
> +	struct clk_lookup *lookup;
> +
> +	clk = at91_clk_register_pll("plla", "main", 0,
> +				    &at91sam9g45_pll_layout,
> +				    &at91sam9g45_plla_characteristics);
> +	for (i = 0; i < ARRAY_SIZE(pll_clk_lookup); i++)
> +		pll_clk_lookup[i].clk = clk;
> +	clkdev_add_table(pll_clk_lookup, ARRAY_SIZE(pll_clk_lookup));
> +	clk = at91_clk_register_plldiv("plladiv", "plla");
>   
> -	for (i = 0; i < ARRAY_SIZE(periph_clocks); i++)
> -		clk_register(periph_clocks[i]);
> +	clk = at91_clk_register_utmi("utmi_clk", "main");
> +	for (i = 0; i < ARRAY_SIZE(utmi_clk_lookup); i++)
> +		utmi_clk_lookup[i].clk = clk;
> +	clkdev_add_table(utmi_clk_lookup, ARRAY_SIZE(utmi_clk_lookup));
>   
> -	clkdev_add_table(periph_clocks_lookups,
> -			 ARRAY_SIZE(periph_clocks_lookups));
> -	clkdev_add_table(usart_clocks_lookups,
> -			 ARRAY_SIZE(usart_clocks_lookups));
> +	clk = at91_clk_register_master("mck",
> +				       ARRAY_SIZE(master_clock_parent_names),
> +				       master_clock_parent_names,
> +				       &at91rm9200_master_layout,
> +				       &at91sam9g45_master_characteristics);
> +	for (i = 0; i < ARRAY_SIZE(mck_clk_lookup); i++)
> +		mck_clk_lookup[i].clk = clk;
> +	clkdev_add_table(mck_clk_lookup, ARRAY_SIZE(mck_clk_lookup));
>   
> -	if (cpu_is_at91sam9m10() || cpu_is_at91sam9m11())
> -		clk_register(&vdec_clk);
> +	for (i = 0; i < ARRAY_SIZE(periph_clock_lookup_sizes); i++) {
> +		size = periph_clock_lookup_sizes[i];
> +		lookup = periph_clock_lookups[i];
> +		if (!size || !lookup)
> +			continue;
> +		name = periph_clock_lookups[i][0].con_id;
> +		if (!name)
> +			continue;
> +		clk = at91_clk_register_peripheral(name, "mck", i);
> +
> +		for (k = 0; k < size; k++)
> +			lookup[k].clk = clk;
> +		clkdev_add_table(lookup, size);
> +	}
> +
> +	if (cpu_is_at91sam9m10() || cpu_is_at91sam9m11()) {
> +		clk = at91_clk_register_peripheral(vdec_clk_lookup[0].con_id,
> +						   "mck",
> +						   AT91SAM9G45_ID_VDEC);
> +		for (k = 0; k < ARRAY_SIZE(vdec_clk_lookup); k++)
> +			vdec_clk_lookup[k].clk = clk;
> +		clkdev_add_table(vdec_clk_lookup, ARRAY_SIZE(vdec_clk_lookup));
> +	}
> +
> +	if (cpu_is_at91sam9m11() || cpu_is_at91sam9g46()) {
> +		clk = at91_clk_register_peripheral(vdec_clk_lookup[0].con_id,
> +						   "mck",
> +						   AT91SAM9G45_ID_AESTDESSHA);
There is a bug here. It should be:
clk = at91_clk_register_peripheral(aestdessha_clk_lookup[0].con_id, 
"mck", AT91SAM9G45_ID_AESTDESSHA);
> +		for (k = 0; k < ARRAY_SIZE(aestdessha_clk_lookup); k++)
> +			aestdessha_clk_lookup[k].clk = clk;
> +		clkdev_add_table(vdec_clk_lookup,
> +				 ARRAY_SIZE(aestdessha_clk_lookup));
Same bug here:

clkdev_add_table(aestdessha_clk_lookup, ARRAY_SIZE(aestdessha_clk_lookup));


These bugs will be fixed in next version.
> +	}
> +
> +	for (i = 0; i < ARRAY_SIZE(prog_clock_names); i++) {
> +		name = prog_clock_names[i];
> +		clk = at91_clk_register_programmable(name,
> +					prog_clock_parent_names,
> +					ARRAY_SIZE(prog_clock_parent_names),
> +					i, &at91sam9g45_programmable_layout);
> +	}
> +
> +	clk = at91sam9x5_clk_register_usb("usbck", usb_clock_parent_names,
> +					  ARRAY_SIZE(usb_clock_parent_names),
> +					  0);
> +	for (i = 0; i < ARRAY_SIZE(usb_clk_lookup); i++)
> +		usb_clk_lookup[i].clk = clk;
> +	clkdev_add_table(usb_clk_lookup, ARRAY_SIZE(usb_clk_lookup));
> +
> +	for (i = 0; i < ARRAY_SIZE(system_clock_lookup_sizes); i++) {
> +		size = system_clock_lookup_sizes[i];
> +		lookup = system_clock_lookups[i];
> +		if (!size || !lookup)
> +			continue;
> +		name = system_clock_lookups[i][0].con_id;
> +		if (!name)
> +			continue;
> +		clk = at91_clk_register_system(name, i);
> +		for (k = 0; k < size; k++)
> +			lookup[k].clk = clk;
> +		clkdev_add_table(lookup, size);
> +	}
>   
> -	clk_register(&pck0);
> -	clk_register(&pck1);
> +	clk_register_fixed_rate(NULL, "adc_op_clk", "mck", 0, 13200000);
>   }
>   
>   /* --------------------------------------------------------------------
> diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
> index cb36fa8..13c650c 100644
> --- a/arch/arm/mach-at91/at91sam9g45_devices.c
> +++ b/arch/arm/mach-at91/at91sam9g45_devices.c
> @@ -37,7 +37,6 @@
>   
>   #include "board.h"
>   #include "generic.h"
> -#include "clock.h"
>   
>   
>   /* --------------------------------------------------------------------



From maxime.ripard at free-electrons.com  Tue Jul 23 18:28:22 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 00:28:22 +0200
Subject: [PATCH 0/2] clk: sunxi: Add clock support for the A10s
Message-ID: <1374618504-19391-1-git-send-email-maxime.ripard@free-electrons.com>

Hi,

This small patchset adds support for the gates found in the Allwinner A10s SoC.
Since the gates are the only clock that differ from the other supported
Allwinner SoCs so far, the two patches are quite trivial.

Thanks,
Maxime

Maxime Ripard (2):
  clk: sunxi: Add A10s gates
  ARM: sun5i: dt: Use the A10s gates in the DTSI

 arch/arm/boot/dts/sun5i-a10s.dtsi | 36 ++++++++++++++----------------------
 drivers/clk/sunxi/clk-sunxi.c     | 15 +++++++++++++++
 2 files changed, 29 insertions(+), 22 deletions(-)

-- 
1.8.3.2



From greg at kroah.com  Tue Jul 23 19:06:14 2013
From: greg at kroah.com (Greg KH)
Date: Tue, 23 Jul 2013 16:06:14 -0700
Subject: [PATCH V4 00/11]  USB: OHCI:Properly handle
 ohci_suspend()routine in bus glue
In-Reply-To: <51ED00A3.8080004@linaro.org>
References: <1371050918-29472-1-git-send-email-manjunath.goudar@linaro.org>
 <1374485566-3997-1-git-send-email-manjunath.goudar@linaro.org>
 <51ED00A3.8080004@linaro.org>
Message-ID: <20130723230614.GA13083@kroah.com>

On Mon, Jul 22, 2013 at 03:21:31PM +0530, manjunath wrote:
> On Monday 22 July 2013 03:02 PM, Manjunath Goudar wrote:
> >Suspend scenario in case of ohci bus glue was not properly handled as
> >it was not suspending generic part of ohci controller. Calling
> >explicitly the ohci_suspend()routine will ensure proper handling
> >of suspend scenario.
> >
> >V2:
> >  -Incase ohci_suspend() fails, return right away without executing further.
> >
> >V3:
> >  -New patch 1/11 added, for generic ohci-hcd suspend code.
> >
> >V4:
> >  -Properly aligned "do_wakeup" and "ret" variables.
> >
> >Manjunath Goudar (11):
> >   USB: OHCI: Properly handle OHCI controller suspend
> >   USB: OHCI: Properly handle ohci-at91 suspend
> >   USB: OHCI: Properly handle ohci-s3c2410 suspend
> >   USB: OHCI: Properly handle ohci-da8xx suspend
> >   USB: OHCI: Properly handle ohci-ep93xx suspend
> >   USB: OHCI: Properly handle ohci-exynos suspend
> >   USB: OHCI: Properly handle ohci-omap suspend
> >   USB: OHCI: Properly handle ohci-platform suspend
> >   USB: OHCI: Properly handle ohci-pxa27x suspend
> >   USB: OHCI: Properly handle ohci-sm501 suspend
> >   USB: OHCI: Properly handle ohci-spear suspend
> >
> >  drivers/usb/host/ohci-at91.c     |   10 ++++++++--
> >  drivers/usb/host/ohci-da8xx.c    |   15 +++++++++++----
> >  drivers/usb/host/ohci-ep93xx.c   |    9 ++++++++-
> >  drivers/usb/host/ohci-exynos.c   |   20 +++++---------------
> >  drivers/usb/host/ohci-hcd.c      |    9 ++++++++-
> >  drivers/usb/host/ohci-omap.c     |   13 ++++++++++---
> >  drivers/usb/host/ohci-platform.c |    9 ++++++++-
> >  drivers/usb/host/ohci-pxa27x.c   |    8 +++++++-
> >  drivers/usb/host/ohci-s3c2410.c  |   19 ++++---------------
> >  drivers/usb/host/ohci-sm501.c    |   11 +++++++++--
> >  drivers/usb/host/ohci-spear.c    |   12 +++++++++---
> >  11 files changed, 87 insertions(+), 48 deletions(-)
> >
> I am sorry, not updated patch subject line. This is patch V4 series.

I'm totally confused by all of the different series of patches you've
sent out, and I don't see Arnd's acks on any of them, so I'll just purge
them all from my queue and wait for the next round.

Also, after what happened last time, I require Arnd to sign-off on all
of these types of patches, if for no other reason than I want someone I
know to be around when they break things :)

thanks,

greg k-h


From laurent.pinchart at ideasonboard.com  Tue Jul 23 19:21:44 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 01:21:44 +0200
Subject: How to create IRQ mappings in a GPIO driver that doesn't control its
 IRQ domain ?
Message-ID: <1624911.6TtmtVmU1T@avalon>

Hello,

I'm running into an issue on several Renesas SoC with IRQ domains and GPIOs.

On sh73a0, r8a73a4 and r8a7740, GPIOs and external interrupts are handled by 
two separate IP cores, namely the PFC (Pin Function Controller) and INTC 
(Interrupt Controller). The former is handled by the sh-pfc driver 
(drivers/pinctrl/sh-pfc) and the later by the irq-renesas-intc-irqpin driver 
(drivers/irqchip), referred to below as the irqpin driver.

The sh73a0, for instance, has 32 external interrupt lines that are multiplexed 
on pins usable as GPIOs. Both the GPIO and external interrupt functions are 
usable at the same time, which allows reading the state of the interrupt 
lines.

These external interrupts are for MMC/SD support, among other devices. In this 
specific case the MMC/SD Card Detect signal is wired to one of the external 
interrupt signals, and the corresponding GPIO is passed to the MMC/SD 
controller driver. Depending on other configuration parameters the driver can 
then either poll the Card Detect signal, or register an interrupt handler to 
detect changes in the signal state. This features is implemented by the MMC/SD 
core, which call gpio_to_irq() on the GPIO to retrieve the corresponding IRQ 
number.

On non-DT systems the external IRQs are statically mapped at a known offset. 
The sh-pfc driver, to implement the gpio_to_irq() function (through its 
gpiochip .to_irq() handler), simply searches a SoC-specific lookup table for 
the fixed IRQ number associated with a given GPIO.

However, on DT systems, IRQs are mapped dynamically on demand. The irqpin 
driver registers a simple IRQ domain, and the irq_create_mapping() function 
can then be used to map a given IRQ, specified as an offset in the domain. 
This is where the problem appears, as the irqchip .to_irq() function is 
implemented in the sh-pfc driver, which doesn't have access to the IRQ domain 
registered by the irqpin driver.

I could hack around this by exporting a function in the irqpin driver that 
would map an IRQ, and call that function from the sh-pfc driver. I'd rather 
avoid that solution as it would add a direct dependency between the two 
drivers.

Has anyone run into a similar issue ? My gut feeling is that the architecture 
isn't right somewhere, but I can't really pinpoint where. As the external IRQs 
are handled by an IP core separate from the PFC one could argue that the 
corresponding IRQs are not really GPIO IRQs, and that the PFC driver shouldn't 
implement the .to_irq() operation. However, this would push the problem down 
to all drivers that need a GPIO they can read and a (possibly optional) IRQ 
associated with the same signal, and that rely on gpio_to_irq() to retrieve 
the IRQ associated with the signal. If all those drivers were required to 
handle the GPIO and the IRQ separately, then we could as well completely 
remove gpio_to_irq() from the kernel, which doesn't sound like the right thing 
to do.

Advices and opinions will be welcome.

-- 
Regards,

Laurent Pinchart



From tomasz.figa at gmail.com  Tue Jul 23 19:32:31 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 24 Jul 2013 01:32:31 +0200
Subject: [PATCH v6 02/20] clocksource: samsung_pwm_timer: Correct definition
 of AUTORELOAD bit
In-Reply-To: <51EDA3EA.9020502@linaro.org>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1658534.7nG6RFjcTc@flatron> <51EDA3EA.9020502@linaro.org>
Message-ID: <2416336.ny4L9Sf7Ts@flatron>

PWM channel 4 has its autoreload bit located at different position. This
patch fixes the driver to account for that.

This fixes a problem with the clocksource hanging after it overflows because
it is not reloaded any more.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 drivers/clocksource/samsung_pwm_timer.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

Changes since v5:
 - Added more detailed comment about bit layout in TCON register.

diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index 3fa5b07..5d0049f 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -44,10 +44,21 @@
 #define TCFG1_SHIFT(x)	  		((x) * 4)
 #define TCFG1_MUX_MASK	  		0xf
 
+/*
+ * Each channel occupies 4 bits in TCON register, but there is a gap of 4
+ * bits (one channel) after channel 0, so channels have different numbering
+ * when accessing TCON register.
+ *
+ * In addition, the location of autoreload bit for channel 4 (TCON channel 5)
+ * in its set of bits is 2 as opposed to 3 for other channels.
+ */
 #define TCON_START(chan)		(1 << (4 * (chan) + 0))
 #define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
 #define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
-#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
+#define _TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
+#define _TCON_AUTORELOAD4(chan)		(1 << (4 * (chan) + 2))
+#define TCON_AUTORELOAD(chan)		\
+	((chan < 5) ? _TCON_AUTORELOAD(chan) : _TCON_AUTORELOAD4(chan))
 
 DEFINE_SPINLOCK(samsung_pwm_lock);
 EXPORT_SYMBOL(samsung_pwm_lock);
-- 
1.8.3.2




From sboyd at codeaurora.org  Tue Jul 23 19:40:40 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 23 Jul 2013 16:40:40 -0700
Subject: [GIT PULL] Remove ARM local timer API
In-Reply-To: <CAOesGMj5AZcB7-kcS8_JqfKAg_RUKqTdDZf7bdwkebn3pwADAw@mail.gmail.com>
References: <20130625200211.GA11625@codeaurora.org>
 <CAOesGMj5AZcB7-kcS8_JqfKAg_RUKqTdDZf7bdwkebn3pwADAw@mail.gmail.com>
Message-ID: <20130723234040.GB27761@codeaurora.org>

On 07/23, Olof Johansson wrote:
> On Tue, Jun 25, 2013 at 1:02 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
> > Olof/Arnd,
> >
> > These patches remove the ARM local timer API. The ARM architected
> > timers have already moved away from this API so this series
> > migrates the rest of the users allowing us to remove the API
> > entirely. Thomas has been kind enough to take the first two
> > patches into timers/core in the tip tree (thanks Thomas!) so I've
> > merged that into v3.10-rc1 and then applied the rest of the
> > patches on top. Let me know if this is acceptable.
> >
> > These patches have been through multiple rounds and tested by
> > multiple people since before the 3.10 merge window closed. Only
> > Barry's ack is missing (Cced).
> >
> > Since I don't have a tree on kernel.org, David Brown has been
> > kind enough to push my tag out to his repo. Please pull.
> >
> > The following changes since commit 42cba6e27c4cddc4df701c597dbfa666e1c013c8:
> >
> >   Merge branch 'timers/core' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip into remove-local-timers (2013-06-24 17:45:02 -0700)
> >
> > are available in the git repository at:
> >
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git tags/remove-local-timers
> >
> > for you to fetch changes up to 060fd3043e5e3488504b9e70182e188dd9113aea:
> >
> >   ARM: smp: Remove local timer API (2013-06-24 17:47:34 -0700)
> >
> > ----------------------------------------------------------------
> > Now that we have a generic arch hook for broadcast we can remove the local
> > timer API entirely. Doing so will reduce code in ARM core, reduce the
> > architecture dependencies of our timer drivers, and simplify the code because
> > we no longer go through an architecture layer that is essentially a hotplug
> > notifier.
> 
> Hi,
> 
> Merged in as localtimer/removal into next/cleanup.
> 
> I had quite a few merge conflicts due to the __cpuinit removal, so
> please double-check my resolutions.
> 

A __cpuinit is leftover in smp_twd.c. Hopefully you can just
redo the merge?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From tomasz.figa at gmail.com  Tue Jul 23 19:43:15 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 24 Jul 2013 01:43:15 +0200
Subject: [PATCH v6 13/20] pwm: Add new pwm-samsung driver
In-Reply-To: <1478465.17AL5GbAI8@flatron>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-15-git-send-email-tomasz.figa@gmail.com>
 <1478465.17AL5GbAI8@flatron>
Message-ID: <1374623475.SoL01ZHzWk@flatron>

This patch introduces new Samsung PWM driver, which is completely
rewritten to be multiplatform- and DeviceTree-aware.

In addition, remaining problems of old driver are fixed, such as:
 - proper handling of hardware variants,
 - synchronization on SMP systems,
 - handling of boundary parameter values,
 - hardware sharing with PWM clocksource driver,
 - undefined state of PWM output after stopping PWM channel.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Acked-by: Thierry Reding <thierry.reding at gmail.com>
---
 drivers/pwm/Makefile      |   1 +
 drivers/pwm/pwm-samsung.c | 618 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 619 insertions(+)
 create mode 100644 drivers/pwm/pwm-samsung.c

Changes since v5:
 - No functional changes, just following cosmetic improvements.
 - Used BIT() macro to define bits instead of shifting 1s directly.
 - Added comment about bit layout in TCON register.
 - Made macros used to define bits have more meaningful parameter names.
 - Updated commit message.

diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index aa94807..86a5771 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_PWM_PUV3)		+= pwm-puv3.o
 obj-$(CONFIG_PWM_PXA)		+= pwm-pxa.o
 obj-$(CONFIG_PWM_RENESAS_TPU)	+= pwm-renesas-tpu.o
 obj-$(CONFIG_PWM_SAMSUNG)	+= pwm-samsung-legacy.o
+obj-$(CONFIG_PWM_SAMSUNG)	+= pwm-samsung.o
 obj-$(CONFIG_PWM_SPEAR)		+= pwm-spear.o
 obj-$(CONFIG_PWM_TEGRA)		+= pwm-tegra.o
 obj-$(CONFIG_PWM_TIECAP)	+= pwm-tiecap.o
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
new file mode 100644
index 0000000..fcc8b9a
--- /dev/null
+++ b/drivers/pwm/pwm-samsung.c
@@ -0,0 +1,618 @@
+/*
+ * Copyright (c) 2007 Ben Dooks
+ * Copyright (c) 2008 Simtec Electronics
+ *     Ben Dooks <ben at simtec.co.uk>, <ben-linux at fluff.org>
+ * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
+ *
+ * PWM driver for Samsung SoCs
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/export.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/time.h>
+
+/* For struct samsung_timer_variant and samsung_pwm_lock. */
+#include <clocksource/samsung_pwm.h>
+
+#define REG_TCFG0			0x00
+#define REG_TCFG1			0x04
+#define REG_TCON			0x08
+
+#define REG_TCNTB(chan)			(0x0c + ((chan) * 0xc))
+#define REG_TCMPB(chan)			(0x10 + ((chan) * 0xc))
+
+#define TCFG0_PRESCALER_MASK		0xff
+#define TCFG0_PRESCALER1_SHIFT		8
+
+#define TCFG1_MUX_MASK			0xf
+#define TCFG1_SHIFT(chan)		(4 * (chan))
+
+/*
+ * Each channel occupies 4 bits in TCON register, but there is a gap of 4
+ * bits (one channel) after channel 0, so channels have different numbering
+ * when accessing TCON register. See to_tcon_channel() function.
+ *
+ * In addition, the location of autoreload bit for channel 4 (TCON channel 5)
+ * in its set of bits is 2 as opposed to 3 for other channels.
+ */
+#define TCON_START(chan)		BIT(4 * (chan) + 0)
+#define TCON_MANUALUPDATE(chan)		BIT(4 * (chan) + 1)
+#define TCON_INVERT(chan)		BIT(4 * (chan) + 2)
+#define _TCON_AUTORELOAD(chan)		BIT(4 * (chan) + 3)
+#define _TCON_AUTORELOAD4(chan)		BIT(4 * (chan) + 2)
+#define TCON_AUTORELOAD(chan)		\
+	((chan < 5) ? _TCON_AUTORELOAD(chan) : _TCON_AUTORELOAD4(chan))
+
+/**
+ * struct samsung_pwm_channel - private data of PWM channel
+ * @period_ns:	current period in nanoseconds programmed to the hardware
+ * @duty_ns:	current duty time in nanoseconds programmed to the hardware
+ * @tin_ns:	time of one timer tick in nanoseconds with current timer rate
+ */
+struct samsung_pwm_channel {
+	u32 period_ns;
+	u32 duty_ns;
+	u32 tin_ns;
+};
+
+/**
+ * struct samsung_pwm_chip - private data of PWM chip
+ * @chip:		generic PWM chip
+ * @variant:		local copy of hardware variant data
+ * @inverter_mask:	inverter status for all channels - one bit per channel
+ * @base:		base address of mapped PWM registers
+ * @base_clk:		base clock used to drive the timers
+ * @tclk0:		external clock 0 (can be ERR_PTR if not present)
+ * @tclk1:		external clock 1 (can be ERR_PTR if not present)
+ */
+struct samsung_pwm_chip {
+	struct pwm_chip chip;
+	struct samsung_pwm_variant variant;
+	u8 inverter_mask;
+
+	void __iomem *base;
+	struct clk *base_clk;
+	struct clk *tclk0;
+	struct clk *tclk1;
+};
+
+#ifndef CONFIG_CLKSRC_SAMSUNG_PWM
+/*
+ * PWM block is shared between pwm-samsung and samsung_pwm_timer drivers
+ * and some registers need access synchronization. If both drivers are
+ * compiled in, the spinlock is defined in the clocksource driver,
+ * otherwise following definition is used.
+ *
+ * Currently we do not need any more complex synchronization method
+ * because all the supported SoCs contain only one instance of the PWM
+ * IP. Should this change, both drivers will need to be modified to
+ * properly synchronize accesses to particular instances.
+ */
+static DEFINE_SPINLOCK(samsung_pwm_lock);
+#endif
+
+static inline
+struct samsung_pwm_chip *to_samsung_pwm_chip(struct pwm_chip *chip)
+{
+	return container_of(chip, struct samsung_pwm_chip, chip);
+}
+
+static inline unsigned int to_tcon_channel(unsigned int channel)
+{
+	/* TCON register has a gap of 4 bits (1 channel) after channel 0 */
+	return (channel == 0) ? 0 : (channel + 1);
+}
+
+static void pwm_samsung_set_divisor(struct samsung_pwm_chip *pwm,
+				    unsigned int channel, u8 divisor)
+{
+	u8 shift = TCFG1_SHIFT(channel);
+	unsigned long flags;
+	u32 reg;
+	u8 bits;
+
+	bits = (fls(divisor) - 1) - pwm->variant.div_base;
+
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
+
+	reg = readl(pwm->base + REG_TCFG1);
+	reg &= ~(TCFG1_MUX_MASK << shift);
+	reg |= bits << shift;
+	writel(reg, pwm->base + REG_TCFG1);
+
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
+}
+
+static int pwm_samsung_is_tdiv(struct samsung_pwm_chip *chip, unsigned int chan)
+{
+	struct samsung_pwm_variant *variant = &chip->variant;
+	u32 reg;
+
+	reg = readl(chip->base + REG_TCFG1);
+	reg >>= TCFG1_SHIFT(chan);
+	reg &= TCFG1_MUX_MASK;
+
+	return (BIT(reg) & variant->tclk_mask) == 0;
+}
+
+static unsigned long pwm_samsung_get_tin_rate(struct samsung_pwm_chip *chip,
+					      unsigned int chan)
+{
+	unsigned long rate;
+	u32 reg;
+
+	rate = clk_get_rate(chip->base_clk);
+
+	reg = readl(chip->base + REG_TCFG0);
+	if (chan >= 2)
+		reg >>= TCFG0_PRESCALER1_SHIFT;
+	reg &= TCFG0_PRESCALER_MASK;
+
+	return rate / (reg + 1);
+}
+
+static unsigned long pwm_samsung_calc_tin(struct samsung_pwm_chip *chip,
+					  unsigned int chan, unsigned long freq)
+{
+	struct samsung_pwm_variant *variant = &chip->variant;
+	unsigned long rate;
+	struct clk *clk;
+	u8 div;
+
+	if (!pwm_samsung_is_tdiv(chip, chan)) {
+		clk = (chan < 2) ? chip->tclk0 : chip->tclk1;
+		if (!IS_ERR(clk)) {
+			rate = clk_get_rate(clk);
+			if (rate)
+				return rate;
+		}
+
+		dev_warn(chip->chip.dev,
+			"tclk of PWM %d is inoperational, using tdiv\n", chan);
+	}
+
+	rate = pwm_samsung_get_tin_rate(chip, chan);
+	dev_dbg(chip->chip.dev, "tin parent at %lu\n", rate);
+
+	/*
+	 * Compare minimum PWM frequency that can be achieved with possible
+	 * divider settings and choose the lowest divisor that can generate
+	 * frequencies lower than requested.
+	 */
+	for (div = variant->div_base; div < 4; ++div)
+		if ((rate >> (variant->bits + div)) < freq)
+			break;
+
+	pwm_samsung_set_divisor(chip, chan, BIT(div));
+
+	return rate >> div;
+}
+
+static int pwm_samsung_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	struct samsung_pwm_channel *our_chan;
+
+	if (!(our_chip->variant.output_mask & BIT(pwm->hwpwm))) {
+		dev_warn(chip->dev,
+			"tried to request PWM channel %d without output\n",
+			pwm->hwpwm);
+		return -EINVAL;
+	}
+
+	our_chan = devm_kzalloc(chip->dev, sizeof(*our_chan), GFP_KERNEL);
+	if (!our_chan)
+		return -ENOMEM;
+
+	pwm_set_chip_data(pwm, our_chan);
+
+	return 0;
+}
+
+static void pwm_samsung_free(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	pwm_set_chip_data(pwm, NULL);
+	devm_kfree(chip->dev, pwm_get_chip_data(pwm));
+}
+
+static int pwm_samsung_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	unsigned int tcon_chan = to_tcon_channel(pwm->hwpwm);
+	unsigned long flags;
+	u32 tcon;
+
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
+
+	tcon = readl(our_chip->base + REG_TCON);
+
+	tcon &= ~TCON_START(tcon_chan);
+	tcon |= TCON_MANUALUPDATE(tcon_chan);
+	writel(tcon, our_chip->base + REG_TCON);
+
+	tcon &= ~TCON_MANUALUPDATE(tcon_chan);
+	tcon |= TCON_START(tcon_chan) | TCON_AUTORELOAD(tcon_chan);
+	writel(tcon, our_chip->base + REG_TCON);
+
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
+
+	return 0;
+}
+
+static void pwm_samsung_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	unsigned int tcon_chan = to_tcon_channel(pwm->hwpwm);
+	unsigned long flags;
+	u32 tcon;
+
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
+
+	tcon = readl(our_chip->base + REG_TCON);
+	tcon &= ~TCON_AUTORELOAD(tcon_chan);
+	writel(tcon, our_chip->base + REG_TCON);
+
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
+}
+
+static int pwm_samsung_config(struct pwm_chip *chip, struct pwm_device *pwm,
+			      int duty_ns, int period_ns)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	struct samsung_pwm_channel *chan = pwm_get_chip_data(pwm);
+	u32 tin_ns = chan->tin_ns, tcnt, tcmp;
+
+	/*
+	 * We currently avoid using 64bit arithmetic by using the
+	 * fact that anything faster than 1Hz is easily representable
+	 * by 32bits.
+	 */
+	if (period_ns > NSEC_PER_SEC)
+		return -ERANGE;
+
+	if (period_ns == chan->period_ns && duty_ns == chan->duty_ns)
+		return 0;
+
+	tcnt = readl(our_chip->base + REG_TCNTB(pwm->hwpwm));
+
+	/* We need tick count for calculation, not last tick. */
+	++tcnt;
+
+	/* Check to see if we are changing the clock rate of the PWM. */
+	if (chan->period_ns != period_ns) {
+		unsigned long tin_rate;
+		u32 period;
+
+		period = NSEC_PER_SEC / period_ns;
+
+		dev_dbg(our_chip->chip.dev, "duty_ns=%d, period_ns=%d (%u)\n",
+						duty_ns, period_ns, period);
+
+		tin_rate = pwm_samsung_calc_tin(our_chip, pwm->hwpwm, period);
+
+		dev_dbg(our_chip->chip.dev, "tin_rate=%lu\n", tin_rate);
+
+		tin_ns = NSEC_PER_SEC / tin_rate;
+		tcnt = period_ns / tin_ns;
+	}
+
+	/* Period is too short. */
+	if (tcnt <= 1)
+		return -ERANGE;
+
+	/* Note that counters count down. */
+	tcmp = duty_ns / tin_ns;
+
+	/* 0% duty is not available */
+	if (!tcmp)
+		++tcmp;
+
+	tcmp = tcnt - tcmp;
+
+	/* Decrement to get tick numbers, instead of tick counts. */
+	--tcnt;
+	/* -1UL will give 100% duty. */
+	--tcmp;
+
+	dev_dbg(our_chip->chip.dev,
+				"tin_ns=%u, tcmp=%u/%u\n", tin_ns, tcmp, tcnt);
+
+	/* Update PWM registers. */
+	writel(tcnt, our_chip->base + REG_TCNTB(pwm->hwpwm));
+	writel(tcmp, our_chip->base + REG_TCMPB(pwm->hwpwm));
+
+	if (test_bit(PWMF_ENABLED, &pwm->flags))
+		pwm_samsung_enable(chip, pwm);
+
+	chan->period_ns = period_ns;
+	chan->tin_ns = tin_ns;
+	chan->duty_ns = duty_ns;
+
+	return 0;
+}
+
+static void pwm_samsung_set_invert(struct samsung_pwm_chip *chip,
+				   unsigned int channel, bool invert)
+{
+	unsigned int tcon_chan = to_tcon_channel(channel);
+	unsigned long flags;
+	u32 tcon;
+
+	spin_lock_irqsave(&samsung_pwm_lock, flags);
+
+	tcon = readl(chip->base + REG_TCON);
+
+	if (invert) {
+		chip->inverter_mask |= BIT(channel);
+		tcon |= TCON_INVERT(tcon_chan);
+	} else {
+		chip->inverter_mask &= ~BIT(channel);
+		tcon &= ~TCON_INVERT(tcon_chan);
+	}
+
+	writel(tcon, chip->base + REG_TCON);
+
+	spin_unlock_irqrestore(&samsung_pwm_lock, flags);
+}
+
+static int pwm_samsung_set_polarity(struct pwm_chip *chip,
+				    struct pwm_device *pwm,
+				    enum pwm_polarity polarity)
+{
+	struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
+	bool invert = (polarity == PWM_POLARITY_NORMAL);
+
+	/* Inverted means normal in the hardware. */
+	pwm_samsung_set_invert(our_chip, pwm->hwpwm, invert);
+
+	return 0;
+}
+
+static const struct pwm_ops pwm_samsung_ops = {
+	.request	= pwm_samsung_request,
+	.free		= pwm_samsung_free,
+	.enable		= pwm_samsung_enable,
+	.disable	= pwm_samsung_disable,
+	.config		= pwm_samsung_config,
+	.set_polarity	= pwm_samsung_set_polarity,
+	.owner		= THIS_MODULE,
+};
+
+#ifdef CONFIG_OF
+static const struct samsung_pwm_variant s3c24xx_variant = {
+	.bits		= 16,
+	.div_base	= 1,
+	.has_tint_cstat	= false,
+	.tclk_mask	= BIT(4),
+};
+
+static const struct samsung_pwm_variant s3c64xx_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= BIT(7) | BIT(6) | BIT(5),
+};
+
+static const struct samsung_pwm_variant s5p64x0_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= 0,
+};
+
+static const struct samsung_pwm_variant s5pc100_variant = {
+	.bits		= 32,
+	.div_base	= 0,
+	.has_tint_cstat	= true,
+	.tclk_mask	= BIT(5),
+};
+
+static const struct of_device_id samsung_pwm_matches[] = {
+	{ .compatible = "samsung,s3c2410-pwm", .data = &s3c24xx_variant },
+	{ .compatible = "samsung,s3c6400-pwm", .data = &s3c64xx_variant },
+	{ .compatible = "samsung,s5p6440-pwm", .data = &s5p64x0_variant },
+	{ .compatible = "samsung,s5pc100-pwm", .data = &s5pc100_variant },
+	{ .compatible = "samsung,exynos4210-pwm", .data = &s5p64x0_variant },
+	{},
+};
+
+static int pwm_samsung_parse_dt(struct samsung_pwm_chip *chip)
+{
+	struct device_node *np = chip->chip.dev->of_node;
+	const struct of_device_id *match;
+	struct property *prop;
+	const __be32 *cur;
+	u32 val;
+
+	match = of_match_node(samsung_pwm_matches, np);
+	if (!match)
+		return -ENODEV;
+
+	memcpy(&chip->variant, match->data, sizeof(chip->variant));
+
+	of_property_for_each_u32(np, "samsung,pwm-outputs", prop, cur, val) {
+		if (val >= SAMSUNG_PWM_NUM) {
+			dev_err(chip->chip.dev,
+				"%s: invalid channel index in samsung,pwm-outputs property\n",
+								__func__);
+			continue;
+		}
+		chip->variant.output_mask |= BIT(val);
+	}
+
+	return 0;
+}
+#else
+static int pwm_samsung_parse_dt(struct samsung_pwm_chip *chip)
+{
+	return -ENODEV;
+}
+#endif
+
+static int pwm_samsung_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct samsung_pwm_chip *chip;
+	struct resource *res;
+	unsigned int chan;
+	int ret;
+
+	chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
+	if (chip == NULL)
+		return -ENOMEM;
+
+	chip->chip.dev = &pdev->dev;
+	chip->chip.ops = &pwm_samsung_ops;
+	chip->chip.base = -1;
+	chip->chip.npwm = SAMSUNG_PWM_NUM;
+	chip->inverter_mask = BIT(SAMSUNG_PWM_NUM) - 1;
+
+	if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node) {
+		ret = pwm_samsung_parse_dt(chip);
+		if (ret)
+			return ret;
+
+		chip->chip.of_xlate = of_pwm_xlate_with_flags;
+		chip->chip.of_pwm_n_cells = 3;
+	} else {
+		if (!pdev->dev.platform_data) {
+			dev_err(&pdev->dev, "no platform data specified\n");
+			return -EINVAL;
+		}
+
+		memcpy(&chip->variant, pdev->dev.platform_data,
+							sizeof(chip->variant));
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	chip->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(chip->base))
+		return PTR_ERR(chip->base);
+
+	chip->base_clk = devm_clk_get(&pdev->dev, "timers");
+	if (IS_ERR(chip->base_clk)) {
+		dev_err(dev, "failed to get timer base clk\n");
+		return PTR_ERR(chip->base_clk);
+	}
+
+	ret = clk_prepare_enable(chip->base_clk);
+	if (ret < 0) {
+		dev_err(dev, "failed to enable base clock\n");
+		return ret;
+	}
+
+	for (chan = 0; chan < SAMSUNG_PWM_NUM; ++chan)
+		if (chip->variant.output_mask & BIT(chan))
+			pwm_samsung_set_invert(chip, chan, true);
+
+	/* Following clocks are optional. */
+	chip->tclk0 = devm_clk_get(&pdev->dev, "pwm-tclk0");
+	chip->tclk1 = devm_clk_get(&pdev->dev, "pwm-tclk1");
+
+	platform_set_drvdata(pdev, chip);
+
+	ret = pwmchip_add(&chip->chip);
+	if (ret < 0) {
+		dev_err(dev, "failed to register PWM chip\n");
+		clk_disable_unprepare(chip->base_clk);
+		return ret;
+	}
+
+	dev_dbg(dev, "base_clk at %lu, tclk0 at %lu, tclk1 at %lu\n",
+		clk_get_rate(chip->base_clk),
+		!IS_ERR(chip->tclk0) ? clk_get_rate(chip->tclk0) : 0,
+		!IS_ERR(chip->tclk1) ? clk_get_rate(chip->tclk1) : 0);
+
+	return 0;
+}
+
+static int pwm_samsung_remove(struct platform_device *pdev)
+{
+	struct samsung_pwm_chip *chip = platform_get_drvdata(pdev);
+	int ret;
+
+	ret = pwmchip_remove(&chip->chip);
+	if (ret < 0)
+		return ret;
+
+	clk_disable_unprepare(chip->base_clk);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int pwm_samsung_suspend(struct device *dev)
+{
+	struct samsung_pwm_chip *chip = dev_get_drvdata(dev);
+	unsigned int i;
+
+	/*
+	 * No one preserves these values during suspend so reset them.
+	 * Otherwise driver leaves PWM unconfigured if same values are
+	 * passed to pwm_config() next time.
+	 */
+	for (i = 0; i < SAMSUNG_PWM_NUM; ++i) {
+		struct pwm_device *pwm = &chip->chip.pwms[i];
+		struct samsung_pwm_channel *chan = pwm_get_chip_data(pwm);
+
+		if (!chan)
+			continue;
+
+		chan->period_ns = 0;
+		chan->duty_ns = 0;
+	}
+
+	return 0;
+}
+
+static int pwm_samsung_resume(struct device *dev)
+{
+	struct samsung_pwm_chip *chip = dev_get_drvdata(dev);
+	unsigned int chan;
+
+	/*
+	 * Inverter setting must be preserved across suspend/resume
+	 * as nobody really seems to configure it more than once.
+	 */
+	for (chan = 0; chan < SAMSUNG_PWM_NUM; ++chan) {
+		if (chip->variant.output_mask & BIT(chan))
+			pwm_samsung_set_invert(chip, chan,
+					chip->inverter_mask & BIT(chan));
+	}
+
+	return 0;
+}
+#endif
+
+static const struct dev_pm_ops pwm_samsung_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pwm_samsung_suspend, pwm_samsung_resume)
+};
+
+static struct platform_driver pwm_samsung_driver = {
+	.driver		= {
+		.name	= "samsung-pwm",
+		.owner	= THIS_MODULE,
+		.pm	= &pwm_samsung_pm_ops,
+		.of_match_table = of_match_ptr(samsung_pwm_matches),
+	},
+	.probe		= pwm_samsung_probe,
+	.remove		= pwm_samsung_remove,
+};
+module_platform_driver(pwm_samsung_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Tomasz Figa <tomasz.figa at gmail.com>");
+MODULE_ALIAS("platform:samsung-pwm");
-- 
1.8.3.2




From broonie at kernel.org  Tue Jul 23 19:48:30 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 24 Jul 2013 00:48:30 +0100
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130723194423.GA22984@kroah.com>
References: <Pine.LNX.4.44L0.1307231017290.1304-100000@iolanthe.rowland.org>
 <51EE9EC0.6060905@ti.com> <20130723161846.GD2486@kroah.com>
 <1446965.6APW5ZgLBW@amdc1227> <20130723173710.GB28284@kroah.com>
 <20130723174456.GM9858@sirena.org.uk>
 <20130723180110.GA8688@kroah.com>
 <20130723193105.GP9858@sirena.org.uk>
 <20130723194423.GA22984@kroah.com>
Message-ID: <20130723234830.GU9858@sirena.org.uk>

On Tue, Jul 23, 2013 at 12:44:23PM -0700, Greg KH wrote:
> On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:

> > statement.  In any case this is why the APIs doing lookups do the
> > lookups in the context of the requesting device - devices ask for
> > whatever name they use locally.

> What do you mean by "locally"?

Within themselves - for example a regulator consumer asks for a given
supply on the device in terms of the supply names the device has.

> The problem with the api was that the phy core wanted a id and a name to
> create a phy, and then later other code was doing a "lookup" based on
> the name and id (mushed together), because it "knew" that this device
> was the one it wanted.

Ah, that sounds like the API is missing a component to link things
together.  But I could be wrong.  What I would expect to see is that the
consumer says "I want the PHY called X" and the PHY driver says "I
provide this set of PHYs" with a layer in between that plugs those
together.  This would normally involve talking about the parent device
rather than the PHY itself.

> I think, that if you create a device, then just carry around the pointer
> to that device (in this case a phy) and pass it to whatever other code
> needs it.  No need to do lookups on "known names" or anything else, just
> normal pointers, with no problems for multiple devices, busses, or
> naming issues.

I think you're not really talking about the lookup API at all here but
rather about one way in which the matching code can be written.  What
everything *really* wants to do is work in terms of resources namespaced
within struct devices since every bit of hardware in the system should
have one of those it can use and if you have a struct device you can do
useful things like call dev_printk() and find the device tree data to do
device tree based lookups.

Unfortunately for a number of buses even when statically registering the
struct device doesn't get allocated until the device is probed so what
everyone fell back on doing was using dev_name() in cases where the
struct device wasn't there yet, or just always using it for consistency
since for most of the affected buses dev_name() is fixed for human
interface reasons.  I think this is the issue you're concerned about
here since if the dev_name() is dynamically allocated this breaks down.
This only affects board files, DT and ACPI can both use their own data
structures to do the mapping.

I had thought you were talking about picking the names that the
consumers use (which isn't actually that big a deal, it's just a bit
annoying for the clock API).

> > It's adding platform data in the first place that gets tedious - and of
> > course there's also DT and ACPI to worry about, it's not just a case of
> > platform data and then you're done.  Pushing the lookup into library
> > code means that drivers don't have to worry about any of this stuff.

> I agree, so just pass around the pointer to the phy and all is good.  No
> need to worry about DT or ACPI or anything else.

No, in practice passing around the pointer gets tricky if you're using
something other than board files (or even are doing any kind of dynamic
stuff with board files) since the two devices need to find each other
and if you're using platform data then the code doing the matching has
to know about the platform data for every device it might need to match
which is just miserable.

Something would need to do something like allocate the PHY objects and
then arrange for them to be passed to both provider and consumer devices
prior to those being registered, knowing where to place the pointers in
the platform data for each device.  This is straightforward with board
files but not otherwise, people have tried this before.

> > For most of the APIs doing this there is a clear and unambiguous name in
> > the hardware that can be used (and for hardware process reasons is
> > unlikely to get changed).  The major exception to this is the clock API
> > since it is relatively rare to have clear, segregated IP level
> > information for IPs baked into larger chips.  The other APIs tend to be
> > establishing chip to chip links.

> The clock api is having problems with multiple "names" due to dynamic
> devices from what I was told.  I want to prevent the PHY interface from
> having that same issue.

I think the underlying issue here is that we don't have a good enough
general way for board files (or other C code but mostly them) to talk
about devices prior to their being registered - rather than have the
pointer you're talking about be the PHY object itself have the pointer
be something which allows us to match the struct device when it's
created.  This should be transparent to drivers and would be usable by
all the existing APIs.
-------------- 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/20130724/937f4864/attachment.sig>

From tomasz.figa at gmail.com  Tue Jul 23 19:52:19 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 24 Jul 2013 01:52:19 +0200
Subject: [PATCH v3 2/8] clk: samsung: pll: Add support for PLL6552 and PLL6553
In-Reply-To: <1374536965-3545-3-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
 <1374536965-3545-3-git-send-email-tomasz.figa@gmail.com>
Message-ID: <11551938.yDBcNngaZN@flatron>

This patch adds support for PLL6552 and PLL6553 PLLs present on Samsung
S3C64xx SoCs.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
Acked-by: Mike Turquette <mturquette at linaro.org>
---
 drivers/clk/samsung/clk-pll.c | 77 +++++++++++++++++++++++++++++++++++++++++++
 drivers/clk/samsung/clk-pll.h |  2 ++
 2 files changed, 79 insertions(+)

Changes since v2:
 - Reworked to use new PLL registration method introduced by Yadwinder
   Singh Brar's patch series:
   ( http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20041 )

diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index f80efb6..7572d1d 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -438,6 +438,77 @@ struct clk * __init samsung_clk_register_pll46xx(const char *name,
 }
 
 /*
+ * PLL6552 Clock Type
+ */
+
+#define PLL6552_MDIV_MASK	0x3ff
+#define PLL6552_PDIV_MASK	0x3f
+#define PLL6552_SDIV_MASK	0x7
+#define PLL6552_MDIV_SHIFT	16
+#define PLL6552_PDIV_SHIFT	8
+#define PLL6552_SDIV_SHIFT	0
+
+static unsigned long samsung_pll6552_recalc_rate(struct clk_hw *hw,
+						unsigned long parent_rate)
+{
+	struct samsung_clk_pll *pll = to_clk_pll(hw);
+	u32 mdiv, pdiv, sdiv, pll_con;
+	u64 fvco = parent_rate;
+
+	pll_con = __raw_readl(pll->con_reg);
+	mdiv = (pll_con >> PLL6552_MDIV_SHIFT) & PLL6552_MDIV_MASK;
+	pdiv = (pll_con >> PLL6552_PDIV_SHIFT) & PLL6552_PDIV_MASK;
+	sdiv = (pll_con >> PLL6552_SDIV_SHIFT) & PLL6552_SDIV_MASK;
+
+	fvco *= mdiv;
+	do_div(fvco, (pdiv << sdiv));
+
+	return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6552_clk_ops = {
+	.recalc_rate = samsung_pll6552_recalc_rate,
+};
+
+/*
+ * PLL6553 Clock Type
+ */
+
+#define PLL6553_MDIV_MASK	0xff
+#define PLL6553_PDIV_MASK	0x3f
+#define PLL6553_SDIV_MASK	0x7
+#define PLL6553_KDIV_MASK	0xffff
+#define PLL6553_MDIV_SHIFT	16
+#define PLL6553_PDIV_SHIFT	8
+#define PLL6553_SDIV_SHIFT	0
+#define PLL6553_KDIV_SHIFT	0
+
+static unsigned long samsung_pll6553_recalc_rate(struct clk_hw *hw,
+						unsigned long parent_rate)
+{
+	struct samsung_clk_pll *pll = to_clk_pll(hw);
+	u32 mdiv, pdiv, sdiv, kdiv, pll_con0, pll_con1;
+	u64 fvco = parent_rate;
+
+	pll_con0 = __raw_readl(pll->con_reg);
+	pll_con1 = __raw_readl(pll->con_reg + 0x4);
+	mdiv = (pll_con0 >> PLL6553_MDIV_SHIFT) & PLL6553_MDIV_MASK;
+	pdiv = (pll_con0 >> PLL6553_PDIV_SHIFT) & PLL6553_PDIV_MASK;
+	sdiv = (pll_con0 >> PLL6553_SDIV_SHIFT) & PLL6553_SDIV_MASK;
+	kdiv = (pll_con1 >> PLL6553_KDIV_SHIFT) & PLL6553_KDIV_MASK;
+
+	fvco *= (mdiv << 16) + kdiv;
+	do_div(fvco, (pdiv << sdiv));
+	fvco >>= 16;
+
+	return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6553_clk_ops = {
+	.recalc_rate = samsung_pll6553_recalc_rate,
+};
+
+/*
  * PLL2550x Clock Type
  */
 
@@ -572,6 +643,12 @@ static void __init _samsung_clk_register_pll(struct samsung_pll_clock *pll_clk,
 		else
 			init.ops = &samsung_pll36xx_clk_ops;
 		break;
+	case pll_6552:
+		init.ops = &samsung_pll6552_clk_ops;
+		break;
+	case pll_6553:
+		init.ops = &samsung_pll6553_clk_ops;
+		break;
 	default:
 		pr_warn("%s: Unknown pll type for pll clk %s\n",
 			__func__, pll_clk->name);
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
index 95ae23d..cd11037 100644
--- a/drivers/clk/samsung/clk-pll.h
+++ b/drivers/clk/samsung/clk-pll.h
@@ -17,6 +17,8 @@ enum samsung_pll_type {
 	pll_36xx,
 	pll_2550,
 	pll_2650,
+	pll_6552,
+	pll_6553,
 };
 
 #define PLL_35XX_RATE(_rate, _m, _p, _s)			\
-- 
1.8.3.2




From tomasz.figa at gmail.com  Tue Jul 23 19:55:15 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 24 Jul 2013 01:55:15 +0200
Subject: [PATCH v3 3/8] clk: samsung: Add clock driver for S3C64xx SoCs
In-Reply-To: <1374536965-3545-4-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
 <1374536965-3545-4-git-send-email-tomasz.figa@gmail.com>
Message-ID: <2125091.5PZbhuSZeB@flatron>

This patch adds new, Common Clock Framework-based clock driver for Samsung
S3C64xx SoCs. The driver is just added, without actually letting the
platforms use it yet, since this requires more intermediate steps.

Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
Acked-by: Mike Turquette <mturquette at linaro.org>
---
 .../bindings/clock/samsung,s3c64xx-clock.txt       |  77 ++++
 drivers/clk/samsung/Makefile                       |   3 +
 drivers/clk/samsung/clk-s3c64xx.c                  | 473 +++++++++++++++++++++
 include/dt-bindings/clock/samsung,s3c64xx-clock.h  | 178 ++++++++
 4 files changed, 731 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
 create mode 100644 drivers/clk/samsung/clk-s3c64xx.c
 create mode 100644 include/dt-bindings/clock/samsung,s3c64xx-clock.h

Changes since v2:
 - Reworked to use new PLL registration method introduced by Yadwinder
   Singh Brar's patch series:
   ( http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20041 )

diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
new file mode 100644
index 0000000..fa171dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
@@ -0,0 +1,77 @@
+* Samsung S3C64xx Clock Controller
+
+The S3C64xx clock controller generates and supplies clock to various controllers
+within the SoC. The clock binding described here is applicable to all SoCs in
+the S3C64xx family.
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "samsung,s3c6400-clock" - controller compatible with S3C6400 SoC.
+  - "samsung,s3c6410-clock" - controller compatible with S3C6410 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Some of the clocks are available only
+on a particular S3C64xx SoC and this is specified where applicable.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/samsung,s3c64xx-clock.h header and can be used in device
+tree sources.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "fin_pll" - PLL input clock (xtal/extclk) - required,
+ - "xusbxti" - USB xtal - required,
+ - "iiscdclk0" - I2S0 codec clock - optional,
+ - "iiscdclk1" - I2S1 codec clock - optional,
+ - "iiscdclk2" - I2S2 codec clock - optional,
+ - "pcmcdclk0" - PCM0 codec clock - optional,
+ - "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410.
+
+Example: Clock controller node:
+
+	clock: clock-controller at 7e00f000 {
+		compatible = "samsung,s3c6410-clock";
+		reg = <0x7e00f000 0x1000>;
+		#clock-cells = <1>;
+	};
+
+Example: Required external clocks:
+
+	fin_pll: clock-fin-pll {
+		compatible = "fixed-clock";
+		clock-output-names = "fin_pll";
+		clock-frequency = <12000000>;
+		#clock-cells = <0>;
+	};
+
+	xusbxti: clock-xusbxti {
+		compatible = "fixed-clock";
+		clock-output-names = "xusbxti";
+		clock-frequency = <48000000>;
+		#clock-cells = <0>;
+	};
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller (refer to the standard clock bindings for information about
+  "clocks" and "clock-names" properties):
+
+		uart0: serial at 7f005000 {
+			compatible = "samsung,s3c6400-uart";
+			reg = <0x7f005000 0x100>;
+			interrupt-parent = <&vic1>;
+			interrupts = <5>;
+			clock-names = "uart", "clk_uart_baud2",
+					"clk_uart_baud3";
+			clocks = <&clock PCLK_UART0>, <&clocks PCLK_UART0>,
+					<&clock SCLK_UART>;
+			status = "disabled";
+		};
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 5d4d432..3413380 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -8,3 +8,6 @@ obj-$(CONFIG_SOC_EXYNOS5250)	+= clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5420)	+= clk-exynos5420.o
 obj-$(CONFIG_SOC_EXYNOS5440)	+= clk-exynos5440.o
 obj-$(CONFIG_ARCH_EXYNOS)	+= clk-exynos-audss.o
+ifdef CONFIG_COMMON_CLK
+obj-$(CONFIG_ARCH_S3C64XX)	+= clk-s3c64xx.o
+endif
diff --git a/drivers/clk/samsung/clk-s3c64xx.c b/drivers/clk/samsung/clk-s3c64xx.c
new file mode 100644
index 0000000..eeda567
--- /dev/null
+++ b/drivers/clk/samsung/clk-s3c64xx.c
@@ -0,0 +1,473 @@
+/*
+ * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Common Clock Framework support for all S3C64xx SoCs.
+*/
+
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+#include <dt-bindings/clock/samsung,s3c64xx-clock.h>
+
+#include "clk.h"
+#include "clk-pll.h"
+
+/* S3C64xx clock controller register offsets. */
+#define APLL_LOCK		0x000
+#define MPLL_LOCK		0x004
+#define EPLL_LOCK		0x008
+#define APLL_CON		0x00c
+#define MPLL_CON		0x010
+#define EPLL_CON0		0x014
+#define EPLL_CON1		0x018
+#define CLK_SRC			0x01c
+#define CLK_DIV0		0x020
+#define CLK_DIV1		0x024
+#define CLK_DIV2		0x028
+#define HCLK_GATE		0x030
+#define PCLK_GATE		0x034
+#define SCLK_GATE		0x038
+#define MEM0_GATE		0x03c
+#define CLK_SRC2		0x10c
+#define OTHERS			0x900
+
+/* Helper macros to define clock arrays. */
+#define FIXED_RATE_CLOCKS(name)	\
+		static struct samsung_fixed_rate_clock name[]
+#define MUX_CLOCKS(name)	\
+		static struct samsung_mux_clock name[]
+#define DIV_CLOCKS(name)	\
+		static struct samsung_div_clock name[]
+#define GATE_CLOCKS(name)	\
+		static struct samsung_gate_clock name[]
+
+/* Helper macros for gate types present on S3C64xx. */
+#define GATE_BUS(_id, cname, pname, o, b) \
+		GATE(_id, cname, pname, o, b, 0, 0)
+#define GATE_SCLK(_id, cname, pname, o, b) \
+		GATE(_id, cname, pname, o, b, CLK_SET_RATE_PARENT, 0)
+#define GATE_ON(_id, cname, pname, o, b) \
+		GATE(_id, cname, pname, o, b, CLK_IGNORE_UNUSED, 0)
+
+/* list of PLLs to be registered */
+enum s3c64xx_plls {
+	apll, mpll, epll,
+};
+
+/*
+ * List of controller registers to be saved and restored during
+ * a suspend/resume cycle.
+ */
+static __initdata unsigned long s3c64xx_clk_regs[] = {
+	APLL_LOCK,
+	MPLL_LOCK,
+	EPLL_LOCK,
+	APLL_CON,
+	MPLL_CON,
+	EPLL_CON0,
+	EPLL_CON1,
+	CLK_SRC,
+	CLK_DIV0,
+	CLK_DIV1,
+	CLK_DIV2,
+	HCLK_GATE,
+	PCLK_GATE,
+	SCLK_GATE,
+};
+
+static __initdata unsigned long s3c6410_clk_regs[] = {
+	CLK_SRC2,
+	MEM0_GATE,
+};
+
+/* List of parent clocks common for all S3C64xx SoCs. */
+PNAME(spi_mmc_p)	= { "mout_epll", "dout_mpll", "fin_pll", "clk27m" };
+PNAME(uart_p)		= { "mout_epll", "dout_mpll" };
+PNAME(audio0_p)		= { "mout_epll", "dout_mpll", "fin_pll", "iiscdclk0",
+				"pcmcdclk0", "none", "none", "none" };
+PNAME(audio1_p)		= { "mout_epll", "dout_mpll", "fin_pll", "iiscdclk1",
+				"pcmcdclk0", "none", "none", "none" };
+PNAME(mfc_p)		= { "hclkx2", "mout_epll" };
+PNAME(apll_p)		= { "fin_pll", "fout_apll" };
+PNAME(mpll_p)		= { "fin_pll", "fout_mpll" };
+PNAME(epll_p)		= { "fin_pll", "fout_epll" };
+PNAME(hclkx2_p)		= { "mout_mpll", "mout_apll" };
+
+/* S3C6400-specific parent clocks. */
+PNAME(scaler_lcd_p6400)	= { "mout_epll", "dout_mpll", "none", "none" };
+PNAME(irda_p6400)	= { "mout_epll", "dout_mpll", "none", "clk48m" };
+PNAME(uhost_p6400)	= { "clk48m", "mout_epll", "dout_mpll", "none" };
+
+/* S3C6410-specific parent clocks. */
+PNAME(clk27_p6410)	= { "clk27m", "fin_pll" };
+PNAME(scaler_lcd_p6410)	= { "mout_epll", "dout_mpll", "fin_pll", "none" };
+PNAME(irda_p6410)	= { "mout_epll", "dout_mpll", "fin_pll", "clk48m" };
+PNAME(uhost_p6410)	= { "clk48m", "mout_epll", "dout_mpll", "fin_pll" };
+PNAME(audio2_p6410)	= { "mout_epll", "dout_mpll", "fin_pll", "iiscdclk2",
+				"pcmcdclk1", "none", "none", "none" };
+
+/* Fixed rate clocks generated outside the SoC. */
+FIXED_RATE_CLOCKS(s3c64xx_fixed_rate_ext_clks) __initdata = {
+	FRATE(0, "fin_pll", NULL, CLK_IS_ROOT, 0),
+	FRATE(0, "xusbxti", NULL, CLK_IS_ROOT, 0),
+};
+
+/* Fixed rate clocks generated inside the SoC. */
+FIXED_RATE_CLOCKS(s3c64xx_fixed_rate_clks) __initdata = {
+	FRATE(CLK27M, "clk27m", NULL, CLK_IS_ROOT, 27000000),
+	FRATE(CLK48M, "clk48m", NULL, CLK_IS_ROOT, 48000000),
+};
+
+/* List of clock muxes present on all S3C64xx SoCs. */
+MUX_CLOCKS(s3c64xx_mux_clks) __initdata = {
+	MUX_F(0, "mout_syncmux", hclkx2_p, OTHERS, 6, 1, 0, CLK_MUX_READ_ONLY),
+	MUX(MOUT_APLL, "mout_apll", apll_p, CLK_SRC, 0, 1),
+	MUX(MOUT_MPLL, "mout_mpll", mpll_p, CLK_SRC, 1, 1),
+	MUX(MOUT_EPLL, "mout_epll", epll_p, CLK_SRC, 2, 1),
+	MUX(MOUT_MFC, "mout_mfc", mfc_p, CLK_SRC, 4, 1),
+	MUX(MOUT_AUDIO0, "mout_audio0", audio0_p, CLK_SRC, 7, 3),
+	MUX(MOUT_AUDIO1, "mout_audio1", audio1_p, CLK_SRC, 10, 3),
+	MUX(MOUT_UART, "mout_uart", uart_p, CLK_SRC, 13, 1),
+	MUX(MOUT_SPI0, "mout_spi0", spi_mmc_p, CLK_SRC, 14, 2),
+	MUX(MOUT_SPI1, "mout_spi1", spi_mmc_p, CLK_SRC, 16, 2),
+	MUX(MOUT_MMC0, "mout_mmc0", spi_mmc_p, CLK_SRC, 18, 2),
+	MUX(MOUT_MMC1, "mout_mmc1", spi_mmc_p, CLK_SRC, 20, 2),
+	MUX(MOUT_MMC2, "mout_mmc2", spi_mmc_p, CLK_SRC, 22, 2),
+};
+
+/* List of clock muxes present on S3C6400. */
+MUX_CLOCKS(s3c6400_mux_clks) __initdata = {
+	MUX(MOUT_UHOST, "mout_uhost", uhost_p6400, CLK_SRC, 5, 2),
+	MUX(MOUT_IRDA, "mout_irda", irda_p6400, CLK_SRC, 24, 2),
+	MUX(MOUT_LCD, "mout_lcd", scaler_lcd_p6400, CLK_SRC, 26, 2),
+	MUX(MOUT_SCALER, "mout_scaler", scaler_lcd_p6400, CLK_SRC, 28, 2),
+};
+
+/* List of clock muxes present on S3C6410. */
+MUX_CLOCKS(s3c6410_mux_clks) __initdata = {
+	MUX(MOUT_UHOST, "mout_uhost", uhost_p6410, CLK_SRC, 5, 2),
+	MUX(MOUT_IRDA, "mout_irda", irda_p6410, CLK_SRC, 24, 2),
+	MUX(MOUT_LCD, "mout_lcd", scaler_lcd_p6410, CLK_SRC, 26, 2),
+	MUX(MOUT_SCALER, "mout_scaler", scaler_lcd_p6410, CLK_SRC, 28, 2),
+	MUX(MOUT_DAC27, "mout_dac27", clk27_p6410, CLK_SRC, 30, 1),
+	MUX(MOUT_TV27, "mout_tv27", clk27_p6410, CLK_SRC, 31, 1),
+	MUX(MOUT_AUDIO2, "mout_audio2", audio2_p6410, CLK_SRC2, 0, 3),
+};
+
+/* List of clock dividers present on all S3C64xx SoCs. */
+DIV_CLOCKS(s3c64xx_div_clks) __initdata = {
+	DIV(DOUT_MPLL, "dout_mpll", "mout_mpll", CLK_DIV0, 4, 1),
+	DIV(HCLKX2, "hclkx2", "mout_syncmux", CLK_DIV0, 9, 3),
+	DIV(HCLK, "hclk", "hclkx2", CLK_DIV0, 8, 1),
+	DIV(PCLK, "pclk", "hclkx2", CLK_DIV0, 12, 4),
+	DIV(DOUT_SECUR, "dout_secur", "hclkx2", CLK_DIV0, 18, 2),
+	DIV(DOUT_CAM, "dout_cam", "hclkx2", CLK_DIV0, 20, 4),
+	DIV(DOUT_JPEG, "dout_jpeg", "hclkx2", CLK_DIV0, 24, 4),
+	DIV(DOUT_MFC, "dout_mfc", "mout_mfc", CLK_DIV0, 28, 4),
+	DIV(DOUT_MMC0, "dout_mmc0", "mout_mmc0", CLK_DIV1, 0, 4),
+	DIV(DOUT_MMC1, "dout_mmc1", "mout_mmc1", CLK_DIV1, 4, 4),
+	DIV(DOUT_MMC2, "dout_mmc2", "mout_mmc2", CLK_DIV1, 8, 4),
+	DIV(DOUT_LCD, "dout_lcd", "mout_lcd", CLK_DIV1, 12, 4),
+	DIV(DOUT_SCALER, "dout_scaler", "mout_scaler", CLK_DIV1, 16, 4),
+	DIV(DOUT_UHOST, "dout_uhost", "mout_uhost", CLK_DIV1, 20, 4),
+	DIV(DOUT_SPI0, "dout_spi0", "mout_spi0", CLK_DIV2, 0, 4),
+	DIV(DOUT_SPI1, "dout_spi1", "mout_spi1", CLK_DIV2, 4, 4),
+	DIV(DOUT_AUDIO0, "dout_audio0", "mout_audio0", CLK_DIV2, 8, 4),
+	DIV(DOUT_AUDIO1, "dout_audio1", "mout_audio1", CLK_DIV2, 12, 4),
+	DIV(DOUT_UART, "dout_uart", "mout_uart", CLK_DIV2, 16, 4),
+	DIV(DOUT_IRDA, "dout_irda", "mout_irda", CLK_DIV2, 20, 4),
+};
+
+/* List of clock dividers present on S3C6400. */
+DIV_CLOCKS(s3c6400_div_clks) __initdata = {
+	DIV(ARMCLK, "armclk", "mout_apll", CLK_DIV0, 0, 3),
+};
+
+/* List of clock dividers present on S3C6410. */
+DIV_CLOCKS(s3c6410_div_clks) __initdata = {
+	DIV(ARMCLK, "armclk", "mout_apll", CLK_DIV0, 0, 4),
+	DIV(DOUT_FIMC, "dout_fimc", "hclk", CLK_DIV1, 24, 4),
+	DIV(DOUT_AUDIO2, "dout_audio2", "mout_audio2", CLK_DIV2, 24, 4),
+};
+
+/* List of clock gates present on all S3C64xx SoCs. */
+GATE_CLOCKS(s3c64xx_gate_clks) __initdata = {
+	GATE_BUS(HCLK_UHOST, "hclk_uhost", "hclk", HCLK_GATE, 29),
+	GATE_BUS(HCLK_SECUR, "hclk_secur", "hclk", HCLK_GATE, 28),
+	GATE_BUS(HCLK_SDMA1, "hclk_sdma1", "hclk", HCLK_GATE, 27),
+	GATE_BUS(HCLK_SDMA0, "hclk_sdma0", "hclk", HCLK_GATE, 26),
+	GATE_ON(HCLK_DDR1, "hclk_ddr1", "hclk", HCLK_GATE, 24),
+	GATE_BUS(HCLK_USB, "hclk_usb", "hclk", HCLK_GATE, 20),
+	GATE_BUS(HCLK_HSMMC2, "hclk_hsmmc2", "hclk", HCLK_GATE, 19),
+	GATE_BUS(HCLK_HSMMC1, "hclk_hsmmc1", "hclk", HCLK_GATE, 18),
+	GATE_BUS(HCLK_HSMMC0, "hclk_hsmmc0", "hclk", HCLK_GATE, 17),
+	GATE_BUS(HCLK_MDP, "hclk_mdp", "hclk", HCLK_GATE, 16),
+	GATE_BUS(HCLK_DHOST, "hclk_dhost", "hclk", HCLK_GATE, 15),
+	GATE_BUS(HCLK_IHOST, "hclk_ihost", "hclk", HCLK_GATE, 14),
+	GATE_BUS(HCLK_DMA1, "hclk_dma1", "hclk", HCLK_GATE, 13),
+	GATE_BUS(HCLK_DMA0, "hclk_dma0", "hclk", HCLK_GATE, 12),
+	GATE_BUS(HCLK_JPEG, "hclk_jpeg", "hclk", HCLK_GATE, 11),
+	GATE_BUS(HCLK_CAMIF, "hclk_camif", "hclk", HCLK_GATE, 10),
+	GATE_BUS(HCLK_SCALER, "hclk_scaler", "hclk", HCLK_GATE, 9),
+	GATE_BUS(HCLK_2D, "hclk_2d", "hclk", HCLK_GATE, 8),
+	GATE_BUS(HCLK_TV, "hclk_tv", "hclk", HCLK_GATE, 7),
+	GATE_BUS(HCLK_POST0, "hclk_post0", "hclk", HCLK_GATE, 5),
+	GATE_BUS(HCLK_ROT, "hclk_rot", "hclk", HCLK_GATE, 4),
+	GATE_BUS(HCLK_LCD, "hclk_lcd", "hclk", HCLK_GATE, 3),
+	GATE_BUS(HCLK_TZIC, "hclk_tzic", "hclk", HCLK_GATE, 2),
+	GATE_ON(HCLK_INTC, "hclk_intc", "hclk", HCLK_GATE, 1),
+	GATE_ON(PCLK_SKEY, "pclk_skey", "pclk", PCLK_GATE, 24),
+	GATE_ON(PCLK_CHIPID, "pclk_chipid", "pclk", PCLK_GATE, 23),
+	GATE_BUS(PCLK_SPI1, "pclk_spi1", "pclk", PCLK_GATE, 22),
+	GATE_BUS(PCLK_SPI0, "pclk_spi0", "pclk", PCLK_GATE, 21),
+	GATE_BUS(PCLK_HSIRX, "pclk_hsirx", "pclk", PCLK_GATE, 20),
+	GATE_BUS(PCLK_HSITX, "pclk_hsitx", "pclk", PCLK_GATE, 19),
+	GATE_ON(PCLK_GPIO, "pclk_gpio", "pclk", PCLK_GATE, 18),
+	GATE_BUS(PCLK_IIC0, "pclk_iic0", "pclk", PCLK_GATE, 17),
+	GATE_BUS(PCLK_IIS1, "pclk_iis1", "pclk", PCLK_GATE, 16),
+	GATE_BUS(PCLK_IIS0, "pclk_iis0", "pclk", PCLK_GATE, 15),
+	GATE_BUS(PCLK_AC97, "pclk_ac97", "pclk", PCLK_GATE, 14),
+	GATE_BUS(PCLK_TZPC, "pclk_tzpc", "pclk", PCLK_GATE, 13),
+	GATE_BUS(PCLK_TSADC, "pclk_tsadc", "pclk", PCLK_GATE, 12),
+	GATE_BUS(PCLK_KEYPAD, "pclk_keypad", "pclk", PCLK_GATE, 11),
+	GATE_BUS(PCLK_IRDA, "pclk_irda", "pclk", PCLK_GATE, 10),
+	GATE_BUS(PCLK_PCM1, "pclk_pcm1", "pclk", PCLK_GATE, 9),
+	GATE_BUS(PCLK_PCM0, "pclk_pcm0", "pclk", PCLK_GATE, 8),
+	GATE_BUS(PCLK_PWM, "pclk_pwm", "pclk", PCLK_GATE, 7),
+	GATE_BUS(PCLK_RTC, "pclk_rtc", "pclk", PCLK_GATE, 6),
+	GATE_BUS(PCLK_WDT, "pclk_wdt", "pclk", PCLK_GATE, 5),
+	GATE_BUS(PCLK_UART3, "pclk_uart3", "pclk", PCLK_GATE, 4),
+	GATE_BUS(PCLK_UART2, "pclk_uart2", "pclk", PCLK_GATE, 3),
+	GATE_BUS(PCLK_UART1, "pclk_uart1", "pclk", PCLK_GATE, 2),
+	GATE_BUS(PCLK_UART0, "pclk_uart0", "pclk", PCLK_GATE, 1),
+	GATE_BUS(PCLK_MFC, "pclk_mfc", "pclk", PCLK_GATE, 0),
+	GATE_SCLK(SCLK_UHOST, "sclk_uhost", "dout_uhost", SCLK_GATE, 30),
+	GATE_SCLK(SCLK_MMC2_48, "sclk_mmc2_48", "clk48m", SCLK_GATE, 29),
+	GATE_SCLK(SCLK_MMC1_48, "sclk_mmc1_48", "clk48m", SCLK_GATE, 28),
+	GATE_SCLK(SCLK_MMC0_48, "sclk_mmc0_48", "clk48m", SCLK_GATE, 27),
+	GATE_SCLK(SCLK_MMC2, "sclk_mmc2", "dout_mmc2", SCLK_GATE, 26),
+	GATE_SCLK(SCLK_MMC1, "sclk_mmc1", "dout_mmc1", SCLK_GATE, 25),
+	GATE_SCLK(SCLK_MMC0, "sclk_mmc0", "dout_mmc0", SCLK_GATE, 24),
+	GATE_SCLK(SCLK_SPI1_48, "sclk_spi1_48", "clk48m", SCLK_GATE, 23),
+	GATE_SCLK(SCLK_SPI0_48, "sclk_spi0_48", "clk48m", SCLK_GATE, 22),
+	GATE_SCLK(SCLK_SPI1, "sclk_spi1", "dout_spi1", SCLK_GATE, 21),
+	GATE_SCLK(SCLK_SPI0, "sclk_spi0", "dout_spi0", SCLK_GATE, 20),
+	GATE_SCLK(SCLK_DAC27, "sclk_dac27", "mout_dac27", SCLK_GATE, 19),
+	GATE_SCLK(SCLK_TV27, "sclk_tv27", "mout_tv27", SCLK_GATE, 18),
+	GATE_SCLK(SCLK_SCALER27, "sclk_scaler27", "clk27m", SCLK_GATE, 17),
+	GATE_SCLK(SCLK_SCALER, "sclk_scaler", "dout_scaler", SCLK_GATE, 16),
+	GATE_SCLK(SCLK_LCD27, "sclk_lcd27", "clk27m", SCLK_GATE, 15),
+	GATE_SCLK(SCLK_LCD, "sclk_lcd", "dout_lcd", SCLK_GATE, 14),
+	GATE_SCLK(SCLK_POST0_27, "sclk_post0_27", "clk27m", SCLK_GATE, 12),
+	GATE_SCLK(SCLK_POST0, "sclk_post0", "dout_lcd", SCLK_GATE, 10),
+	GATE_SCLK(SCLK_AUDIO1, "sclk_audio1", "dout_audio1", SCLK_GATE, 9),
+	GATE_SCLK(SCLK_AUDIO0, "sclk_audio0", "dout_audio0", SCLK_GATE, 8),
+	GATE_SCLK(SCLK_SECUR, "sclk_secur", "dout_secur", SCLK_GATE, 7),
+	GATE_SCLK(SCLK_IRDA, "sclk_irda", "dout_irda", SCLK_GATE, 6),
+	GATE_SCLK(SCLK_UART, "sclk_uart", "dout_uart", SCLK_GATE, 5),
+	GATE_SCLK(SCLK_MFC, "sclk_mfc", "dout_mfc", SCLK_GATE, 3),
+	GATE_SCLK(SCLK_CAM, "sclk_cam", "dout_cam", SCLK_GATE, 2),
+	GATE_SCLK(SCLK_JPEG, "sclk_jpeg", "dout_jpeg", SCLK_GATE, 1),
+};
+
+/* List of clock gates present on S3C6400. */
+GATE_CLOCKS(s3c6400_gate_clks) __initdata = {
+	GATE_ON(HCLK_DDR0, "hclk_ddr0", "hclk", HCLK_GATE, 23),
+	GATE_SCLK(SCLK_ONENAND, "sclk_onenand", "parent", SCLK_GATE, 4),
+};
+
+/* List of clock gates present on S3C6410. */
+GATE_CLOCKS(s3c6410_gate_clks) __initdata = {
+	GATE_BUS(HCLK_3DSE, "hclk_3dse", "hclk", HCLK_GATE, 31),
+	GATE_ON(HCLK_IROM, "hclk_irom", "hclk", HCLK_GATE, 25),
+	GATE_ON(HCLK_MEM1, "hclk_mem1", "hclk", HCLK_GATE, 22),
+	GATE_ON(HCLK_MEM0, "hclk_mem0", "hclk", HCLK_GATE, 21),
+	GATE_BUS(HCLK_MFC, "hclk_mfc", "hclk", HCLK_GATE, 0),
+	GATE_BUS(PCLK_IIC1, "pclk_iic1", "pclk", PCLK_GATE, 27),
+	GATE_BUS(PCLK_IIS2, "pclk_iis2", "pclk", PCLK_GATE, 26),
+	GATE_SCLK(SCLK_FIMC, "sclk_fimc", "dout_fimc", SCLK_GATE, 13),
+	GATE_SCLK(SCLK_AUDIO2, "sclk_audio2", "dout_audio2", SCLK_GATE, 11),
+	GATE_BUS(MEM0_CFCON, "mem0_cfcon", "hclk_mem0", MEM0_GATE, 5),
+	GATE_BUS(MEM0_ONENAND1, "mem0_onenand1", "hclk_mem0", MEM0_GATE, 4),
+	GATE_BUS(MEM0_ONENAND0, "mem0_onenand0", "hclk_mem0", MEM0_GATE, 3),
+	GATE_BUS(MEM0_NFCON, "mem0_nfcon", "hclk_mem0", MEM0_GATE, 2),
+	GATE_ON(MEM0_SROM, "mem0_srom", "hclk_mem0", MEM0_GATE, 1),
+};
+
+/* List of PLL clocks. */
+static struct samsung_pll_clock s3c64xx_pll_clks[] __initdata = {
+	[apll] = PLL(pll_6552, FOUT_APLL, "fout_apll", "fin_pll",
+						APLL_LOCK, APLL_CON, NULL),
+	[mpll] = PLL(pll_6552, FOUT_MPLL, "fout_mpll", "fin_pll",
+						MPLL_LOCK, MPLL_CON, NULL),
+	[epll] = PLL(pll_6553, FOUT_EPLL, "fout_epll", "fin_pll",
+						EPLL_LOCK, EPLL_CON0, NULL),
+};
+
+/* Aliases for common s3c64xx clocks. */
+static struct samsung_clock_alias s3c64xx_clock_aliases[] = {
+	ALIAS(FOUT_APLL, NULL, "fout_apll"),
+	ALIAS(FOUT_MPLL, NULL, "fout_mpll"),
+	ALIAS(FOUT_EPLL, NULL, "fout_epll"),
+	ALIAS(MOUT_EPLL, NULL, "mout_epll"),
+	ALIAS(DOUT_MPLL, NULL, "dout_mpll"),
+	ALIAS(HCLKX2, NULL, "hclk2"),
+	ALIAS(HCLK, NULL, "hclk"),
+	ALIAS(PCLK, NULL, "pclk"),
+	ALIAS(PCLK, NULL, "clk_uart_baud2"),
+	ALIAS(ARMCLK, NULL, "armclk"),
+	ALIAS(HCLK_UHOST, "s3c2410-ohci", "usb-host"),
+	ALIAS(HCLK_USB, "s3c-hsotg", "otg"),
+	ALIAS(HCLK_HSMMC2, "s3c-sdhci.2", "hsmmc"),
+	ALIAS(HCLK_HSMMC2, "s3c-sdhci.2", "mmc_busclk.0"),
+	ALIAS(HCLK_HSMMC1, "s3c-sdhci.1", "hsmmc"),
+	ALIAS(HCLK_HSMMC1, "s3c-sdhci.1", "mmc_busclk.0"),
+	ALIAS(HCLK_HSMMC0, "s3c-sdhci.0", "hsmmc"),
+	ALIAS(HCLK_HSMMC0, "s3c-sdhci.0", "mmc_busclk.0"),
+	ALIAS(HCLK_DMA1, NULL, "dma1"),
+	ALIAS(HCLK_DMA0, NULL, "dma0"),
+	ALIAS(HCLK_CAMIF, "s3c-camif", "camif"),
+	ALIAS(HCLK_LCD, "s3c-fb", "lcd"),
+	ALIAS(PCLK_SPI1, "s3c6410-spi.1", "spi"),
+	ALIAS(PCLK_SPI0, "s3c6410-spi.0", "spi"),
+	ALIAS(PCLK_IIC0, "s3c2440-i2c.0", "i2c"),
+	ALIAS(PCLK_IIS1, "samsung-i2s.1", "iis"),
+	ALIAS(PCLK_IIS0, "samsung-i2s.0", "iis"),
+	ALIAS(PCLK_AC97, "samsung-ac97", "ac97"),
+	ALIAS(PCLK_TSADC, "s3c64xx-adc", "adc"),
+	ALIAS(PCLK_KEYPAD, "samsung-keypad", "keypad"),
+	ALIAS(PCLK_PCM1, "samsung-pcm.1", "pcm"),
+	ALIAS(PCLK_PCM0, "samsung-pcm.0", "pcm"),
+	ALIAS(PCLK_PWM, NULL, "timers"),
+	ALIAS(PCLK_RTC, "s3c64xx-rtc", "rtc"),
+	ALIAS(PCLK_WDT, NULL, "watchdog"),
+	ALIAS(PCLK_UART3, "s3c6400-uart.3", "uart"),
+	ALIAS(PCLK_UART2, "s3c6400-uart.2", "uart"),
+	ALIAS(PCLK_UART1, "s3c6400-uart.1", "uart"),
+	ALIAS(PCLK_UART0, "s3c6400-uart.0", "uart"),
+	ALIAS(SCLK_UHOST, "s3c2410-ohci", "usb-bus-host"),
+	ALIAS(SCLK_MMC2, "s3c-sdhci.2", "mmc_busclk.2"),
+	ALIAS(SCLK_MMC1, "s3c-sdhci.1", "mmc_busclk.2"),
+	ALIAS(SCLK_MMC0, "s3c-sdhci.0", "mmc_busclk.2"),
+	ALIAS(SCLK_SPI1, "s3c6410-spi.1", "spi-bus"),
+	ALIAS(SCLK_SPI0, "s3c6410-spi.0", "spi-bus"),
+	ALIAS(SCLK_AUDIO1, "samsung-pcm.1", "audio-bus"),
+	ALIAS(SCLK_AUDIO1, "samsung-i2s.1", "audio-bus"),
+	ALIAS(SCLK_AUDIO0, "samsung-pcm.0", "audio-bus"),
+	ALIAS(SCLK_AUDIO0, "samsung-i2s.0", "audio-bus"),
+	ALIAS(SCLK_UART, NULL, "clk_uart_baud3"),
+	ALIAS(SCLK_CAM, "s3c-camif", "camera"),
+};
+
+/* Aliases for s3c6400-specific clocks. */
+static struct samsung_clock_alias s3c6400_clock_aliases[] = {
+	/* Nothing to place here yet. */
+};
+
+/* Aliases for s3c6410-specific clocks. */
+static struct samsung_clock_alias s3c6410_clock_aliases[] = {
+	ALIAS(PCLK_IIC1, "s3c2440-i2c.1", "i2c"),
+	ALIAS(PCLK_IIS2, "samsung-i2s.2", "iis"),
+	ALIAS(SCLK_FIMC, "s3c-camif", "fimc"),
+	ALIAS(SCLK_AUDIO2, "samsung-i2s.2", "audio-bus"),
+	ALIAS(MEM0_SROM, NULL, "srom"),
+};
+
+static void __init s3c64xx_clk_register_fixed_ext(unsigned long fin_pll_f,
+							unsigned long xusbxti_f)
+{
+	s3c64xx_fixed_rate_ext_clks[0].fixed_rate = fin_pll_f;
+	s3c64xx_fixed_rate_ext_clks[1].fixed_rate = xusbxti_f;
+	samsung_clk_register_fixed_rate(s3c64xx_fixed_rate_ext_clks,
+				ARRAY_SIZE(s3c64xx_fixed_rate_ext_clks));
+}
+
+/* Register s3c64xx clocks. */
+void __init s3c64xx_clk_init(struct device_node *np, unsigned long xtal_f,
+			     unsigned long xusbxti_f, bool is_s3c6400,
+			     void __iomem *reg_base)
+{
+	unsigned long *soc_regs = NULL;
+	unsigned long nr_soc_regs = 0;
+
+	if (np) {
+		reg_base = of_iomap(np, 0);
+		if (!reg_base)
+			panic("%s: failed to map registers\n", __func__);
+	}
+
+	if (!is_s3c6400) {
+		soc_regs = s3c6410_clk_regs;
+		nr_soc_regs = ARRAY_SIZE(s3c6410_clk_regs);
+	}
+
+	samsung_clk_init(np, reg_base, NR_CLKS, s3c64xx_clk_regs,
+			ARRAY_SIZE(s3c64xx_clk_regs), soc_regs, nr_soc_regs);
+
+	/* Register external clocks. */
+	if (!np)
+		s3c64xx_clk_register_fixed_ext(xtal_f, xusbxti_f);
+
+	/* Register PLLs. */
+	samsung_clk_register_pll(s3c64xx_pll_clks,
+				ARRAY_SIZE(s3c64xx_pll_clks), reg_base);
+
+	/* Register common internal clocks. */
+	samsung_clk_register_fixed_rate(s3c64xx_fixed_rate_clks,
+					ARRAY_SIZE(s3c64xx_fixed_rate_clks));
+	samsung_clk_register_mux(s3c64xx_mux_clks,
+					ARRAY_SIZE(s3c64xx_mux_clks));
+	samsung_clk_register_div(s3c64xx_div_clks,
+					ARRAY_SIZE(s3c64xx_div_clks));
+	samsung_clk_register_gate(s3c64xx_gate_clks,
+					ARRAY_SIZE(s3c64xx_gate_clks));
+
+	/* Register SoC-specific clocks. */
+	if (is_s3c6400) {
+		samsung_clk_register_mux(s3c6400_mux_clks,
+					ARRAY_SIZE(s3c6400_mux_clks));
+		samsung_clk_register_div(s3c6400_div_clks,
+					ARRAY_SIZE(s3c6400_div_clks));
+		samsung_clk_register_gate(s3c6400_gate_clks,
+					ARRAY_SIZE(s3c6400_gate_clks));
+		samsung_clk_register_alias(s3c6400_clock_aliases,
+					ARRAY_SIZE(s3c6400_clock_aliases));
+	} else {
+		samsung_clk_register_mux(s3c6410_mux_clks,
+					ARRAY_SIZE(s3c6410_mux_clks));
+		samsung_clk_register_div(s3c6410_div_clks,
+					ARRAY_SIZE(s3c6410_div_clks));
+		samsung_clk_register_gate(s3c6410_gate_clks,
+					ARRAY_SIZE(s3c6410_gate_clks));
+		samsung_clk_register_alias(s3c6410_clock_aliases,
+					ARRAY_SIZE(s3c6410_clock_aliases));
+	}
+
+	samsung_clk_register_alias(s3c64xx_clock_aliases,
+					ARRAY_SIZE(s3c64xx_clock_aliases));
+
+	pr_info("%s clocks: apll = %lu, mpll = %lu\n"
+		"\tepll = %lu, arm_clk = %lu\n",
+		is_s3c6400 ? "S3C6400" : "S3C6410",
+		_get_rate("fout_apll"),	_get_rate("fout_mpll"),
+		_get_rate("fout_epll"), _get_rate("armclk"));
+}
+
+static void __init s3c6400_clk_init(struct device_node *np)
+{
+	s3c64xx_clk_init(np, 0, 0, true, NULL);
+}
+CLK_OF_DECLARE(s3c6400_clk, "samsung,s3c6400-clock", s3c6400_clk_init);
+
+static void __init s3c6410_clk_init(struct device_node *np)
+{
+	s3c64xx_clk_init(np, 0, 0, false, NULL);
+}
+CLK_OF_DECLARE(s3c6410_clk, "samsung,s3c6410-clock", s3c6410_clk_init);
diff --git a/include/dt-bindings/clock/samsung,s3c64xx-clock.h b/include/dt-bindings/clock/samsung,s3c64xx-clock.h
new file mode 100644
index 0000000..ad95c7f
--- /dev/null
+++ b/include/dt-bindings/clock/samsung,s3c64xx-clock.h
@@ -0,0 +1,178 @@
+/*
+ * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Device Tree binding constants for Samsung S3C64xx clock controller.
+*/
+
+#ifndef _DT_BINDINGS_CLOCK_SAMSUNG_S3C64XX_CLOCK_H
+#define _DT_BINDINGS_CLOCK_SAMSUNG_S3C64XX_CLOCK_H
+
+/*
+ * Let each exported clock get a unique index, which is used on DT-enabled
+ * platforms to lookup the clock from a clock specifier. These indices are
+ * therefore considered an ABI and so must not be changed. This implies
+ * that new clocks should be added either in free spaces between clock groups
+ * or at the end.
+ */
+
+/* Core clocks. */
+#define CLK27M			1
+#define CLK48M			2
+#define FOUT_APLL		3
+#define FOUT_MPLL		4
+#define FOUT_EPLL		5
+#define ARMCLK			6
+#define HCLKX2			7
+#define HCLK			8
+#define PCLK			9
+
+/* HCLK bus clocks. */
+#define HCLK_3DSE		16
+#define HCLK_UHOST		17
+#define HCLK_SECUR		18
+#define HCLK_SDMA1		19
+#define HCLK_SDMA0		20
+#define HCLK_IROM		21
+#define HCLK_DDR1		22
+#define HCLK_MEM1		23
+#define HCLK_MEM0		24
+#define HCLK_USB		25
+#define HCLK_HSMMC2		26
+#define HCLK_HSMMC1		27
+#define HCLK_HSMMC0		28
+#define HCLK_MDP		29
+#define HCLK_DHOST		30
+#define HCLK_IHOST		31
+#define HCLK_DMA1		32
+#define HCLK_DMA0		33
+#define HCLK_JPEG		34
+#define HCLK_CAMIF		35
+#define HCLK_SCALER		36
+#define HCLK_2D			37
+#define HCLK_TV			38
+#define HCLK_POST0		39
+#define HCLK_ROT		40
+#define HCLK_LCD		41
+#define HCLK_TZIC		42
+#define HCLK_INTC		43
+#define HCLK_MFC		44
+#define HCLK_DDR0		45
+
+/* PCLK bus clocks. */
+#define PCLK_IIC1		48
+#define PCLK_IIS2		49
+#define PCLK_SKEY		50
+#define PCLK_CHIPID		51
+#define PCLK_SPI1		52
+#define PCLK_SPI0		53
+#define PCLK_HSIRX		54
+#define PCLK_HSITX		55
+#define PCLK_GPIO		56
+#define PCLK_IIC0		57
+#define PCLK_IIS1		58
+#define PCLK_IIS0		59
+#define PCLK_AC97		60
+#define PCLK_TZPC		61
+#define PCLK_TSADC		62
+#define PCLK_KEYPAD		63
+#define PCLK_IRDA		64
+#define PCLK_PCM1		65
+#define PCLK_PCM0		66
+#define PCLK_PWM		67
+#define PCLK_RTC		68
+#define PCLK_WDT		69
+#define PCLK_UART3		70
+#define PCLK_UART2		71
+#define PCLK_UART1		72
+#define PCLK_UART0		73
+#define PCLK_MFC		74
+
+/* Special clocks. */
+#define SCLK_UHOST		80
+#define SCLK_MMC2_48		81
+#define SCLK_MMC1_48		82
+#define SCLK_MMC0_48		83
+#define SCLK_MMC2		84
+#define SCLK_MMC1		85
+#define SCLK_MMC0		86
+#define SCLK_SPI1_48		87
+#define SCLK_SPI0_48		88
+#define SCLK_SPI1		89
+#define SCLK_SPI0		90
+#define SCLK_DAC27		91
+#define SCLK_TV27		92
+#define SCLK_SCALER27		93
+#define SCLK_SCALER		94
+#define SCLK_LCD27		95
+#define SCLK_LCD		96
+#define SCLK_FIMC		97
+#define SCLK_POST0_27		98
+#define SCLK_AUDIO2		99
+#define SCLK_POST0		100
+#define SCLK_AUDIO1		101
+#define SCLK_AUDIO0		102
+#define SCLK_SECUR		103
+#define SCLK_IRDA		104
+#define SCLK_UART		105
+#define SCLK_MFC		106
+#define SCLK_CAM		107
+#define SCLK_JPEG		108
+#define SCLK_ONENAND		109
+
+/* MEM0 bus clocks - S3C6410-specific. */
+#define MEM0_CFCON		112
+#define MEM0_ONENAND1		113
+#define MEM0_ONENAND0		114
+#define MEM0_NFCON		115
+#define MEM0_SROM		116
+
+/* Muxes. */
+#define MOUT_APLL		128
+#define MOUT_MPLL		129
+#define MOUT_EPLL		130
+#define MOUT_MFC		131
+#define MOUT_AUDIO0		132
+#define MOUT_AUDIO1		133
+#define MOUT_UART		134
+#define MOUT_SPI0		135
+#define MOUT_SPI1		136
+#define MOUT_MMC0		137
+#define MOUT_MMC1		138
+#define MOUT_MMC2		139
+#define MOUT_UHOST		140
+#define MOUT_IRDA		141
+#define MOUT_LCD		142
+#define MOUT_SCALER		143
+#define MOUT_DAC27		144
+#define MOUT_TV27		145
+#define MOUT_AUDIO2		146
+
+/* Dividers. */
+#define DOUT_MPLL		160
+#define DOUT_SECUR		161
+#define DOUT_CAM		162
+#define DOUT_JPEG		163
+#define DOUT_MFC		164
+#define DOUT_MMC0		165
+#define DOUT_MMC1		166
+#define DOUT_MMC2		167
+#define DOUT_LCD		168
+#define DOUT_SCALER		169
+#define DOUT_UHOST		170
+#define DOUT_SPI0		171
+#define DOUT_SPI1		172
+#define DOUT_AUDIO0		173
+#define DOUT_AUDIO1		174
+#define DOUT_UART		175
+#define DOUT_IRDA		176
+#define DOUT_FIMC		177
+#define DOUT_AUDIO2		178
+
+/* Total number of clocks. */
+#define NR_CLKS			(DOUT_AUDIO2 + 1)
+
+#endif /* _DT_BINDINGS_CLOCK_SAMSUNG_S3C64XX_CLOCK_H */
-- 
1.8.3.2




From csd at broadcom.com  Tue Jul 23 19:57:10 2013
From: csd at broadcom.com (Christian Daudt)
Date: Tue, 23 Jul 2013 16:57:10 -0700
Subject: [PATCH] MAINTAINERS: Add mach-bcm and drivers
Message-ID: <1374623830-32105-1-git-send-email-csd@broadcom.com>

Adding ownership to maintainers file for the mach-bcm related files,
including drivers that are used for the SoCs defined in mach-bcm.

Signed-off-by: Christian Daudt <csd at broadcom.com>

diff --git a/MAINTAINERS b/MAINTAINERS
index bf61e04..49480494 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1785,6 +1785,17 @@ L:	netdev at vger.kernel.org
 S:	Supported
 F:	drivers/net/ethernet/broadcom/bnx2x/
 
+BROADCOM BCM281XX/BCM11XXX ARM ARCHITECTURE
+M:	Christian Daudt <csd at broadcom.com>
+T:	git git://git.github.com/broadcom/bcm11351
+S:	Maintained
+F:	arch/arm/mach-bcm/
+F:	arch/arm/boot/dts/bcm113*
+F:	arch/arm/boot/dts/bcm281*
+F:	arch/arm/configs/bcm_defconfig
+F:	drivers/mmc/host/sdhci_bcm_kona.c
+F:	drivers/clocksource/bcm_kona_timer.c
+
 BROADCOM BCM2835 ARM ARCHICTURE
 M:	Stephen Warren <swarren at wwwdotorg.org>
 L:	linux-rpi-kernel at lists.infradead.org (moderated for non-subscribers)
-- 
1.7.10.4




From gang.chen at asianux.com  Tue Jul 23 20:00:54 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Wed, 24 Jul 2013 08:00:54 +0800
Subject: [PATCH, re-send] Always trap on BUG()
In-Reply-To: <20130723093628.GC19786@gmail.com>
References: <201307051738.35930.arnd@arndb.de>
 <20130715151612.9499c2b2ad40e88d183a4600@linux-foundation.org>
 <20130715222755.GY24642@n2100.arm.linux.org.uk> <51E47924.9030005@zytor.com>
 <20130723093628.GC19786@gmail.com>
Message-ID: <51EF1936.7090801@asianux.com>

On 07/23/2013 05:36 PM, Ingo Molnar wrote:
> 
> (the crazies can keep a separate patch to remove even more of BUG() to win 
> a K or two.)
> 

Excuse me, my English is not quite well, I do not quite understand your
meaning, could you please repeat again in details or say more clearly ?

Thanks.
-- 
Chen Gang


From olof at lixom.net  Tue Jul 23 19:56:09 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 23 Jul 2013 16:56:09 -0700
Subject: [GIT PULL] Remove ARM local timer API
In-Reply-To: <20130723234040.GB27761@codeaurora.org>
References: <20130625200211.GA11625@codeaurora.org>
 <CAOesGMj5AZcB7-kcS8_JqfKAg_RUKqTdDZf7bdwkebn3pwADAw@mail.gmail.com>
 <20130723234040.GB27761@codeaurora.org>
Message-ID: <CAOesGMiornt0twdQv=tYMtAX56Lc79MVyNrHaK1nWpOk189dDA@mail.gmail.com>

On Tue, Jul 23, 2013 at 4:40 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
> On 07/23, Olof Johansson wrote:

>> Merged in as localtimer/removal into next/cleanup.
>>
>> I had quite a few merge conflicts due to the __cpuinit removal, so
>> please double-check my resolutions.
>>
>
> A __cpuinit is leftover in smp_twd.c. Hopefully you can just
> redo the merge?

Done, thanks for catching it. I thought I grepped for them but I
somehow missed that one. Fixed now.


-Olof


From csd at broadcom.com  Tue Jul 23 20:10:52 2013
From: csd at broadcom.com (Christian Daudt)
Date: Tue, 23 Jul 2013 17:10:52 -0700
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X
 SoC with ARM CPU
In-Reply-To: <20130723192203.GC6811@ohporter.com>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130723184907.GA6811@ohporter.com>
 <CAGVrzcbA72AYu6J3JXBirQQeTiDH9cJThdBdH=Q=gJtOnqz-AA@mail.gmail.com>
 <20130723192203.GC6811@ohporter.com>
Message-ID: <51EF1B8C.9020304@broadcom.com>

On 13-07-23 12:22 PM, Matt Porter wrote:
>>>> the bcm281x/kona family support code be merged and use "bcm" there, without
>>>> registering it. Besides, a simple rule of number here wins:
>>>>
>>>> git grep "brcm," * | wc -l
>>>> 63
>>>> git grep "bcm," * | wc -l
>>>> 25
>>>>
>>>> (as of Linux 3.11-rc1)
>>>>
>>>> So consistency we should get the bcm281x/kona DT bindings to rename their
>>>> vendor prefix as well.
>>> I believe getting this "right" is far more important than the difference
>>> in churn of a mere 38 instances of use of brcm. "Right" is two things:
>>> 1) it needs to be consistent 2) it should be what makes sense.
>> I agree, which is the reason why I would stick with the vendor prefix
>> and end the story there.
> It doesn't end there. An update to all the in process stuff has to
> happen, plus the upstream stuff. So in both cases there are changes to
> be made both upstream and with work-in-progress. The only difference is
> that I was suggesting an update to correct the prefix in
> vendor-prefixes.txt.
>
> However, if I'm the only one that cares enough to speak up for "bcm"
> I'll abandon that and submit the patch to adjust bcm281xx to be
> compliant with the current state of vendor-prefixes.txt. :)
>
bcm has been used internally but not consistently - about as 
consistently as brcm has been used in upstream :) Given that I've 
submitted most/all of the non-compliant code, I'll send a patch 
rectifying it and request internal team to switch to using brcm, for 
devicetree bindings, as atonement. If Matt doesn't beat me to it...

  Thanks,
    csd




From horms at verge.net.au  Tue Jul 23 20:26:55 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:26:55 +0900
Subject: [PATCH] clocksource: sh_cmt: 32-bit control register support
In-Reply-To: <51ECAF43.80200@linaro.org>
References: <cover.1374207810.git.horms+renesas@verge.net.au>
 <2792cc6f22031110f6959c02d42d7b6116105a71.1374207810.git.horms+renesas@verge.net.au>
 <51ECAF43.80200@linaro.org>
Message-ID: <20130724002655.GA532@verge.net.au>

On Mon, Jul 22, 2013 at 06:04:19AM +0200, Daniel Lezcano wrote:
> On 07/19/2013 06:36 AM, Simon Horman wrote:
> > From: Magnus Damm <damm at opensource.se>
> > 
> > Add support for CMT hardware with 32-bit control and counter
> > registers, as found on r8a73a4 and r8a7790. To use the CMT
> > with 32-bit hardware a second I/O memory resource needs to
> > point out the CMSTR register and it needs to be 32 bit wide.
> > 
> > Signed-off-by: Magnus Damm <damm at opensource.se>
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> > ---
> 
> In the future, can you Cc drivers/clocksource maintainers please ?

Yes of course, sorry for that oversight.

> Reviewed-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Olof, Arnd, please let me know if you wish me to re-send the pull
request with Daniel's Reviewed-by added to this patch.

> 
> >  drivers/clocksource/sh_cmt.c |   50 ++++++++++++++++++++++++++++++------------
> >  1 file changed, 36 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/clocksource/sh_cmt.c b/drivers/clocksource/sh_cmt.c
> > index 08d0c41..0965e98 100644
> > --- a/drivers/clocksource/sh_cmt.c
> > +++ b/drivers/clocksource/sh_cmt.c
> > @@ -37,6 +37,7 @@
> >  
> >  struct sh_cmt_priv {
> >  	void __iomem *mapbase;
> > +	void __iomem *mapbase_str;
> >  	struct clk *clk;
> >  	unsigned long width; /* 16 or 32 bit version of hardware block */
> >  	unsigned long overflow_bit;
> > @@ -79,6 +80,12 @@ struct sh_cmt_priv {
> >   * CMCSR 0xffca0060 16-bit
> >   * CMCNT 0xffca0064 32-bit
> >   * CMCOR 0xffca0068 32-bit
> > + *
> > + * "32-bit counter and 32-bit control" as found on r8a73a4 and r8a7790:
> > + * CMSTR 0xffca0500 32-bit
> > + * CMCSR 0xffca0510 32-bit
> > + * CMCNT 0xffca0514 32-bit
> > + * CMCOR 0xffca0518 32-bit
> >   */
> >  
> >  static unsigned long sh_cmt_read16(void __iomem *base, unsigned long offs)
> > @@ -109,9 +116,7 @@ static void sh_cmt_write32(void __iomem *base, unsigned long offs,
> >  
> >  static inline unsigned long sh_cmt_read_cmstr(struct sh_cmt_priv *p)
> >  {
> > -	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
> > -
> > -	return p->read_control(p->mapbase - cfg->channel_offset, 0);
> > +	return p->read_control(p->mapbase_str, 0);
> >  }
> >  
> >  static inline unsigned long sh_cmt_read_cmcsr(struct sh_cmt_priv *p)
> > @@ -127,9 +132,7 @@ static inline unsigned long sh_cmt_read_cmcnt(struct sh_cmt_priv *p)
> >  static inline void sh_cmt_write_cmstr(struct sh_cmt_priv *p,
> >  				      unsigned long value)
> >  {
> > -	struct sh_timer_config *cfg = p->pdev->dev.platform_data;
> > -
> > -	p->write_control(p->mapbase - cfg->channel_offset, 0, value);
> > +	p->write_control(p->mapbase_str, 0, value);
> >  }
> >  
> >  static inline void sh_cmt_write_cmcsr(struct sh_cmt_priv *p,
> > @@ -676,7 +679,7 @@ static int sh_cmt_register(struct sh_cmt_priv *p, char *name,
> >  static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
> >  {
> >  	struct sh_timer_config *cfg = pdev->dev.platform_data;
> > -	struct resource *res;
> > +	struct resource *res, *res2;
> >  	int irq, ret;
> >  	ret = -ENXIO;
> >  
> > @@ -694,6 +697,9 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
> >  		goto err0;
> >  	}
> >  
> > +	/* optional resource for the shared timer start/stop register */
> > +	res2 = platform_get_resource(p->pdev, IORESOURCE_MEM, 1);
> > +
> >  	irq = platform_get_irq(p->pdev, 0);
> >  	if (irq < 0) {
> >  		dev_err(&p->pdev->dev, "failed to get irq\n");
> > @@ -707,6 +713,15 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
> >  		goto err0;
> >  	}
> >  
> > +	/* map second resource for CMSTR */
> > +	p->mapbase_str = ioremap_nocache(res2 ? res2->start :
> > +					 res->start - cfg->channel_offset,
> > +					 res2 ? resource_size(res2) : 2);
> > +	if (p->mapbase_str == NULL) {
> > +		dev_err(&p->pdev->dev, "failed to remap I/O second memory\n");
> > +		goto err1;
> > +	}
> > +
> >  	/* request irq using setup_irq() (too early for request_irq()) */
> >  	p->irqaction.name = dev_name(&p->pdev->dev);
> >  	p->irqaction.handler = sh_cmt_interrupt;
> > @@ -719,11 +734,17 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
> >  	if (IS_ERR(p->clk)) {
> >  		dev_err(&p->pdev->dev, "cannot get clock\n");
> >  		ret = PTR_ERR(p->clk);
> > -		goto err1;
> > +		goto err2;
> >  	}
> >  
> > -	p->read_control = sh_cmt_read16;
> > -	p->write_control = sh_cmt_write16;
> > +	if (res2 && (resource_size(res2) == 4)) {
> > +		/* assume both CMSTR and CMCSR to be 32-bit */
> > +		p->read_control = sh_cmt_read32;
> > +		p->write_control = sh_cmt_write32;
> > +	} else {
> > +		p->read_control = sh_cmt_read16;
> > +		p->write_control = sh_cmt_write16;
> > +	}
> >  
> >  	if (resource_size(res) == 6) {
> >  		p->width = 16;
> > @@ -752,22 +773,23 @@ static int sh_cmt_setup(struct sh_cmt_priv *p, struct platform_device *pdev)
> >  			      cfg->clocksource_rating);
> >  	if (ret) {
> >  		dev_err(&p->pdev->dev, "registration failed\n");
> > -		goto err2;
> > +		goto err3;
> >  	}
> >  	p->cs_enabled = false;
> >  
> >  	ret = setup_irq(irq, &p->irqaction);
> >  	if (ret) {
> >  		dev_err(&p->pdev->dev, "failed to request irq %d\n", irq);
> > -		goto err2;
> > +		goto err3;
> >  	}
> >  
> >  	platform_set_drvdata(pdev, p);
> >  
> >  	return 0;
> > -err2:
> > +err3:
> >  	clk_put(p->clk);
> > -
> > +err2:
> > +	iounmap(p->mapbase_str);
> >  err1:
> >  	iounmap(p->mapbase);
> >  err0:
> > 
> 
> 
> -- 
>  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
> 
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From horms+renesas at verge.net.au  Tue Jul 23 20:32:14 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:14 +0900
Subject: [GIT 00/19 v2] Renesas ARM based SoC pinmux updates for v3.12
Message-ID: <cover.1374625203.git.horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

please consider the following pinmux updates for v3.12.

Difference with v1 of this pull-request:
* Remove bogus i2c portions of the first patch of the series.
* Correct addressing mode used in dts of the first patch of the series.
* Removal of egg from face: wip

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-pinmux-for-v3.12

for you to fetch changes up to 1469273960de45275f33276c7254456edcba9da2:

  ARM: shmobile: kzm9g-reference: Add LED1-LED4 to the device tree (2013-07-22 10:12:41 +0900)

----------------------------------------------------------------
Renesas ARM based SoC pinmux updates for v3.12

SH Mobile pinctrl DT support

----------------------------------------------------------------
Laurent Pinchart (19):
      ARM: shmobile: r8a73a4: Add pin control device to device tree
      ARM: shmobile: r8a7740: Add pin control device to device tree
      ARM: shmobile: r8a7778: Add pin control device to device tree
      ARM: shmobile: r8a7778: Add GPIO controller devices to device tree
      ARM: shmobile: r8a7779: Add pin control device to device tree
      ARM: shmobile: r8a7779: Add GPIO controller devices to device tree
      ARM: shmobile: r8a7790: Add pin control device to device tree
      ARM: shmobile: r8a7790: Add GPIO controller devices to device tree
      ARM: shmobile: sh7372: Add pin control device to device tree
      ARM: shmobile: sh73a0: Add pin control device to device tree
      ARM: shmobile: armadillo-reference: Move pinctrl mappings to device tree
      ARM: shmobile: armadillo-reference: Add st1232 pin mappings
      ARM: shmobile: armadillo-reference: Move st1232 reset GPIO to DT
      ARM: shmobile: armadillo-reference: Add LED1-LED4 to the device tree
      ARM: shmobile: marzen-reference: Move pinctrl mappings to device tree
      ARM: shmobile: marzen-reference: Add LED2-LED4 to the device tree
      ARM: shmobile: kzm9g-reference: Move pinctrl mappings to device tree
      ARM: shmobile: kzm9g-reference: Move SDHI regulators to DT
      ARM: shmobile: kzm9g-reference: Add LED1-LED4 to the device tree

 arch/arm/boot/dts/r8a73a4.dtsi                     |  7 ++
 .../boot/dts/r8a7740-armadillo800eva-reference.dts | 34 ++++++++
 arch/arm/boot/dts/r8a7740.dtsi                     |  8 ++
 arch/arm/boot/dts/r8a7778.dtsi                     | 66 ++++++++++++++++
 arch/arm/boot/dts/r8a7779-marzen-reference.dts     | 49 ++++++++++++
 arch/arm/boot/dts/r8a7779.dtsi                     | 90 ++++++++++++++++++++++
 arch/arm/boot/dts/r8a7790.dtsi                     | 78 +++++++++++++++++++
 arch/arm/boot/dts/sh7372.dtsi                      |  8 ++
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts       | 90 +++++++++++++++++++++-
 arch/arm/boot/dts/sh73a0.dtsi                      |  8 ++
 .../board-armadillo800eva-reference.c              | 18 +----
 arch/arm/mach-shmobile/board-kzm9g-reference.c     | 47 -----------
 arch/arm/mach-shmobile/board-marzen-reference.c    | 28 -------
 13 files changed, 437 insertions(+), 94 deletions(-)


From horms+renesas at verge.net.au  Tue Jul 23 20:32:28 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:28 +0900
Subject: [PATCH 01/19] ARM: shmobile: r8a73a4: Add pin control device to
 device tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <803d319cb2fb41e646669061b45701f3ea78e611.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add a pfc node to the r8a73a4 device tree.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
[g.liakhovetski+renesas at gmail.com use 2 nodes for address and size]
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a73a4.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 4ff2019..b886afd 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -85,4 +85,11 @@
 		interrupt-parent = <&gic>;
 		interrupts = <0 69 4>;
 	};
+
+	pfc: pfc at e6050000 {
+		compatible = "renesas,pfc-r8a73a4";
+		reg = <0 0xe6050000 0 0x9000>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
 };
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:30 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:30 +0900
Subject: [PATCH 03/19] ARM: shmobile: r8a7778: Add pin control device to
 device tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <0697ccc05473083cb9e1cdf16cd1f425f0f9395f.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add a pfc node to the r8a7778 device tree.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7778.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index 4743735..c8dbf14 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -32,4 +32,9 @@
 		reg = <0xfe438000 0x1000>,
 		      <0xfe430000 0x100>;
 	};
+
+	pfc: pfc at fffc0000 {
+		compatible = "renesas,pfc-r8a7778";
+		reg = <0xfffc000 0x118>;
+	};
 };
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:31 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:31 +0900
Subject: [PATCH 04/19] ARM: shmobile: r8a7778: Add GPIO controller devices to
 device tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <aaf7eda80cb8371bbf26d7171241cfb94b787b0f.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add GPIO controller nodes to the r8a7778 core device tree.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7778.dtsi | 61 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 61 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index c8dbf14..45ac404 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -33,8 +33,69 @@
 		      <0xfe430000 0x100>;
 	};
 
+	gpio0: gpio at ffc40000 {
+		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
+		reg = <0xffc40000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 103 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 0 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio1: gpio at ffc41000 {
+		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
+		reg = <0xffc41000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 103 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 32 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio2: gpio at ffc42000 {
+		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
+		reg = <0xffc42000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 103 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 64 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio3: gpio at ffc43000 {
+		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
+		reg = <0xffc43000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 103 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 96 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio4: gpio at ffc44000 {
+		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
+		reg = <0xffc44000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 103 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 128 27>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
 	pfc: pfc at fffc0000 {
 		compatible = "renesas,pfc-r8a7778";
 		reg = <0xfffc000 0x118>;
+		#gpio-range-cells = <3>;
 	};
 };
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:32 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:32 +0900
Subject: [PATCH 05/19] ARM: shmobile: r8a7779: Add pin control device to
 device tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <3ab03d01a989e4d77ed6ba0bc8c2efd9211df7c8.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add a pfc node to the r8a7779 device tree and remove manual pinmux
initialization from the corresponding board files.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779.dtsi                  |  5 +++++
 arch/arm/mach-shmobile/board-marzen-reference.c | 17 ++++++++---------
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 7f146c6..9dfc438 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -101,6 +101,11 @@
 		interrupts = <0 81 0x4>;
 	};
 
+	pfc: pfc at fffc0000 {
+		compatible = "renesas,pfc-r8a7779";
+		reg = <0xfffc0000 0x23c>;
+	};
+
 	thermal at ffc48000 {
 		compatible = "renesas,rcar-thermal";
 		reg = <0xffc48000 0x38>;
diff --git a/arch/arm/mach-shmobile/board-marzen-reference.c b/arch/arm/mach-shmobile/board-marzen-reference.c
index 480d882..94804f3 100644
--- a/arch/arm/mach-shmobile/board-marzen-reference.c
+++ b/arch/arm/mach-shmobile/board-marzen-reference.c
@@ -28,24 +28,24 @@
 
 static const struct pinctrl_map marzen_pinctrl_map[] = {
 	/* SCIF2 (CN18: DEBUG0) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.2", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.2", "fffc0000.pfc",
 				  "scif2_data_c", "scif2"),
 	/* SCIF4 (CN19: DEBUG1) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "fffc0000.pfc",
 				  "scif4_data", "scif4"),
 	/* SDHI0 */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
 				  "sdhi0_data4", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
 				  "sdhi0_ctrl", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
 				  "sdhi0_cd", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
 				  "sdhi0_wp", "sdhi0"),
 	/* SMSC */
-	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "fffc0000.pfc",
 				  "intc_irq1_b", "intc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "pfc-r8a7779",
+	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "fffc0000.pfc",
 				  "lbsc_ex_cs0", "lbsc"),
 };
 
@@ -53,7 +53,6 @@ static void __init marzen_init(void)
 {
 	pinctrl_register_mappings(marzen_pinctrl_map,
 				  ARRAY_SIZE(marzen_pinctrl_map));
-	r8a7779_pinmux_init();
 
 	r8a7779_add_standard_devices_dt();
 }
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:29 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:29 +0900
Subject: [PATCH 02/19] ARM: shmobile: r8a7740: Add pin control device to
 device tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <f36218d25f2388775a06b6091d881b7a45b7595f.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add a pfc node to the r8a7740 device tree and remove manual pinmux
initialization from the corresponding board files.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7740.dtsi                           |  8 ++++++++
 arch/arm/mach-shmobile/board-armadillo800eva-reference.c | 16 ++++++++--------
 2 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 24e9306..e18a195 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -139,4 +139,12 @@
 			      0 72 0x4
 			      0 73 0x4>;
 	};
+
+	pfc: pfc at e6050000 {
+		compatible = "renesas,pfc-r8a7740";
+		reg = <0xe6050000 0x8000>,
+		      <0xe605800c 0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
 };
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
index 03b85fe..f25b6aa 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
@@ -121,7 +121,7 @@
 
 static const struct pinctrl_map eva_pinctrl_map[] = {
 	/* SCIFA1 */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.1", "pfc-r8a7740",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.1", "e6050000.pfc",
 				  "scifa1_data", "scifa1"),
 };
 
@@ -170,22 +170,22 @@ static void __init eva_init(void)
 	eva_clock_init();
 
 	pinctrl_register_mappings(eva_pinctrl_map, ARRAY_SIZE(eva_pinctrl_map));
-	r8a7740_pinmux_init();
 
 	r8a7740_meram_workaround();
 
-	/*
-	 * Touchscreen
-	 * TODO: Move reset GPIO over to .dts when we can reference it
-	 */
-	gpio_request_one(166, GPIOF_OUT_INIT_HIGH, NULL); /* TP_RST_B */
-
 #ifdef CONFIG_CACHE_L2X0
 	/* Early BRESP enable, Shared attribute override enable, 32K*8way */
 	l2x0_init(IOMEM(0xf0002000), 0x40440000, 0x82000fff);
 #endif
 
 	r8a7740_add_standard_devices_dt();
+
+	/*
+	 * Touchscreen
+	 * TODO: Move reset GPIO over to .dts when we can reference it
+	 */
+	gpio_request_one(166, GPIOF_OUT_INIT_HIGH, NULL); /* TP_RST_B */
+
 	r8a7740_pm_init();
 }
 
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:55 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:55 +0900
Subject: [PATCH 16/19] ARM: shmobile: marzen-reference: Add LED2-LED4 to the
 device tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <80d1126fae07fd4bd6a93ad626ad14e753f9d892.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

LED2 to LED4 are GPIO LEDs. Add corresponding DT nodes.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779-marzen-reference.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7779-marzen-reference.dts b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
index 6d20247..b64705b 100644
--- a/arch/arm/boot/dts/r8a7779-marzen-reference.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 /include/ "r8a7779.dtsi"
+#include <dt-bindings/gpio/gpio.h>
 
 / {
 	model = "marzen";
@@ -47,6 +48,19 @@
 		vddvario-supply = <&fixedregulator3v3>;
 		vdd33a-supply = <&fixedregulator3v3>;
 	};
+
+	leds {
+		compatible = "gpio-leds";
+		led2 {
+			gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+		};
+		led3 {
+			gpios = <&gpio4 30 GPIO_ACTIVE_HIGH>;
+		};
+		led4 {
+			gpios = <&gpio4 31 GPIO_ACTIVE_HIGH>;
+		};
+	};
 };
 
 &pfc {
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:51 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:51 +0900
Subject: [PATCH 12/19] ARM: shmobile: armadillo-reference: Add st1232 pin
 mappings
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <f46a6b0f6a54e80ebf1003134f2e6f4258e53688.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add pin mappings for the st1232 device to the device tree and reference
them as the default state for the device.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index 4a7ae32..a6c6606 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -41,6 +41,8 @@
 		reg = <0x55>;
 		interrupt-parent = <&irqpin1>;
 		interrupts = <2 0>; /* IRQ10: hwirq 2 on irqpin1 */
+		pinctrl-0 = <&st1232_pins>;
+		pinctrl-names = "default";
 	};
 };
 
@@ -52,4 +54,9 @@
 		renesas,groups = "scifa1_data";
 		renesas,function = "scifa1";
 	};
+
+	st1232_pins: st1232 {
+		renesas,groups = "intc_irq10";
+		renesas,function = "intc";
+	};
 };
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:34 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:34 +0900
Subject: [PATCH 07/19] ARM: shmobile: r8a7790: Add pin control device to
 device tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <9694c778048e006604c3fbade6b0aefa5dd0b516.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add a pfc node to the r8a7790 device tree.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 339d9b1..13caf12 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -54,4 +54,9 @@
 		interrupt-parent = <&gic>;
 		interrupts = <0 0 4>, <0 1 4>, <0 2 4>,	<0 3 4>;
 	};
+
+	pfc: pfc at e6060000 {
+		compatible = "renesas,pfc-r8a7790";
+		reg = <0 0xe6060000 0 0x250>;
+	};
 };
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:36 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:36 +0900
Subject: [PATCH 09/19] ARM: shmobile: sh7372: Add pin control device to device
 tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <871e4b3e9e437b48287c635c5e66ba80b5cd365a.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add a pfc node to the sh7372 device tree.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh7372.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sh7372.dtsi b/arch/arm/boot/dts/sh7372.dtsi
index 7bf020e..249f65be2 100644
--- a/arch/arm/boot/dts/sh7372.dtsi
+++ b/arch/arm/boot/dts/sh7372.dtsi
@@ -23,4 +23,12 @@
 			reg = <0x0>;
 		};
 	};
+
+	pfc: pfc at e6050000 {
+		compatible = "renesas,pfc-sh7372";
+		reg = <0xe6050000 0x8000>,
+		      <0xe605801c 0x1c>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
 };
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:53 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:53 +0900
Subject: [PATCH 14/19] ARM: shmobile: armadillo-reference: Add LED1-LED4 to
 the device tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <0a4f788961f196baa3e8ffd840a2c5931434854e.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

LED1 to LED4 are GPIO LEDs. Add corresponding DT nodes.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index 8ec4cd1..366f729 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -34,6 +34,21 @@
 		regulator-boot-on;
 	};
 
+	leds {
+		compatible = "gpio-leds";
+		led1 {
+			gpios = <&pfc 102 GPIO_ACTIVE_HIGH>;
+		};
+		led2 {
+			gpios = <&pfc 111 GPIO_ACTIVE_HIGH>;
+		};
+		led3 {
+			gpios = <&pfc 110 GPIO_ACTIVE_HIGH>;
+		};
+		led4 {
+			gpios = <&pfc 177 GPIO_ACTIVE_HIGH>;
+		};
+	};
 };
 
 &i2c0 {
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:52 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:52 +0900
Subject: [PATCH 13/19] ARM: shmobile: armadillo-reference: Move st1232 reset
 GPIO to DT
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <14d0a2b79623e4773e5fc78950dadac213a30400.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Reference the st1232 reset GPIO from the device tree and remove it from
board code.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts  | 2 ++
 arch/arm/mach-shmobile/board-armadillo800eva-reference.c | 7 -------
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index a6c6606..8ec4cd1 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -10,6 +10,7 @@
 
 /dts-v1/;
 /include/ "r8a7740.dtsi"
+#include <dt-bindings/gpio/gpio.h>
 
 / {
 	model = "armadillo 800 eva reference";
@@ -43,6 +44,7 @@
 		interrupts = <2 0>; /* IRQ10: hwirq 2 on irqpin1 */
 		pinctrl-0 = <&st1232_pins>;
 		pinctrl-names = "default";
+		gpios = <&pfc 166 GPIO_ACTIVE_LOW>;
 	};
 };
 
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
index 4ddd299..002d8d3 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
@@ -158,7 +158,6 @@ clock_error:
  */
 static void __init eva_init(void)
 {
-
 	r8a7740_clock_init(MD_CK0 | MD_CK2);
 	eva_clock_init();
 
@@ -171,12 +170,6 @@ static void __init eva_init(void)
 
 	r8a7740_add_standard_devices_dt();
 
-	/*
-	 * Touchscreen
-	 * TODO: Move reset GPIO over to .dts when we can reference it
-	 */
-	gpio_request_one(166, GPIOF_OUT_INIT_HIGH, NULL); /* TP_RST_B */
-
 	r8a7740_pm_init();
 }
 
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:50 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:50 +0900
Subject: [PATCH 11/19] ARM: shmobile: armadillo-reference: Move pinctrl
 mappings to device tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <5d244563da5326d66ca839b06dbc6f632d2f24df.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Replace the pinctrl mappings in board code by device tree mappings.
For devices that are still instantiated from board code reference the
mappings as the default pin controller state to apply them at boot time.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts  | 10 ++++++++++
 arch/arm/mach-shmobile/board-armadillo800eva-reference.c |  9 ---------
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index 09ea22c..4a7ae32 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -43,3 +43,13 @@
 		interrupts = <2 0>; /* IRQ10: hwirq 2 on irqpin1 */
 	};
 };
+
+&pfc {
+	pinctrl-0 = <&scifa1_pins>;
+	pinctrl-names = "default";
+
+	scifa1_pins: scifa1 {
+		renesas,groups = "scifa1_data";
+		renesas,function = "scifa1";
+	};
+};
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
index f25b6aa..4ddd299 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
@@ -24,7 +24,6 @@
 #include <linux/kernel.h>
 #include <linux/gpio.h>
 #include <linux/io.h>
-#include <linux/pinctrl/machine.h>
 #include <mach/common.h>
 #include <mach/r8a7740.h>
 #include <asm/mach/arch.h>
@@ -119,12 +118,6 @@
  *	usbhsf_power_ctrl()
  */
 
-static const struct pinctrl_map eva_pinctrl_map[] = {
-	/* SCIFA1 */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.1", "e6050000.pfc",
-				  "scifa1_data", "scifa1"),
-};
-
 static void __init eva_clock_init(void)
 {
 	struct clk *system	= clk_get(NULL, "system_clk");
@@ -169,8 +162,6 @@ static void __init eva_init(void)
 	r8a7740_clock_init(MD_CK0 | MD_CK2);
 	eva_clock_init();
 
-	pinctrl_register_mappings(eva_pinctrl_map, ARRAY_SIZE(eva_pinctrl_map));
-
 	r8a7740_meram_workaround();
 
 #ifdef CONFIG_CACHE_L2X0
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:35 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:35 +0900
Subject: [PATCH 08/19] ARM: shmobile: r8a7790: Add GPIO controller devices to
 device tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <f98e10c88aa95bf7d37cce6dbacec0820dd6ecc2.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add GPIO controller nodes to the r8a7790 core device tree.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 73 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 13caf12..9465cfc 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -38,6 +38,78 @@
 		interrupts = <1 9 0xf04>;
 	};
 
+	gpio0: gpio at ffc40000 {
+		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+		reg = <0 0xffc40000 0 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 4 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 0 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio1: gpio at ffc41000 {
+		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+		reg = <0 0xffc41000 0 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 5 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 32 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio2: gpio at ffc42000 {
+		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+		reg = <0 0xffc42000 0 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 6 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 64 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio3: gpio at ffc43000 {
+		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+		reg = <0 0xffc43000 0 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 7 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 96 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio4: gpio at ffc44000 {
+		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+		reg = <0 0xffc44000 0 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 8 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 128 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio5: gpio at ffc45000 {
+		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
+		reg = <0 0xffc45000 0 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 9 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 160 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
 	timer {
 		compatible = "arm,armv7-timer";
 		interrupts = <1 13 0xf08>,
@@ -58,5 +130,6 @@
 	pfc: pfc at e6060000 {
 		compatible = "renesas,pfc-r8a7790";
 		reg = <0 0xe6060000 0 0x250>;
+		#gpio-range-cells = <3>;
 	};
 };
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:33 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:33 +0900
Subject: [PATCH 06/19] ARM: shmobile: r8a7779: Add GPIO controller devices to
 device tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <f5c771b5610b4c0d4daf9729aa03539ef1779a92.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add GPIO controller nodes to the r8a7779 core device tree.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779.dtsi | 85 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 85 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 9dfc438..e9fbe3d 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -48,6 +48,90 @@
                       <0xf0000100 0x100>;
         };
 
+	gpio0: gpio at ffc40000 {
+		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+		reg = <0xffc40000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 141 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 0 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio1: gpio at ffc41000 {
+		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+		reg = <0xffc41000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 142 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 32 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio2: gpio at ffc42000 {
+		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+		reg = <0xffc42000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 143 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 64 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio3: gpio at ffc43000 {
+		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+		reg = <0xffc43000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 144 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 96 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio4: gpio at ffc44000 {
+		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+		reg = <0xffc44000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 145 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 128 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio5: gpio at ffc45000 {
+		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+		reg = <0xffc45000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 146 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 160 32>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
+	gpio6: gpio at ffc46000 {
+		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+		reg = <0xffc46000 0x2c>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 147 0x4>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		gpio-ranges = <&pfc 0 192 9>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+	};
+
 	irqpin0: irqpin at fe780010 {
 		compatible = "renesas,intc-irqpin";
 		#interrupt-cells = <2>;
@@ -104,6 +188,7 @@
 	pfc: pfc at fffc0000 {
 		compatible = "renesas,pfc-r8a7779";
 		reg = <0xfffc0000 0x23c>;
+		#gpio-range-cells = <3>;
 	};
 
 	thermal at ffc48000 {
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:49 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:49 +0900
Subject: [PATCH 10/19] ARM: shmobile: sh73a0: Add pin control device to device
 tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <3f59007e8efc29bb6cce08329bf010bcd9b19101.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Add a pfc node to the sh73a0 device tree and remove manual pinmux
initialization from the corresponding board files.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh73a0.dtsi                  |  8 ++++++++
 arch/arm/mach-shmobile/board-kzm9g-reference.c | 27 +++++++++++++-------------
 2 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index b977502..86e79fe 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -222,4 +222,12 @@
 		cap-sd-highspeed;
 		status = "disabled";
 	};
+
+	pfc: pfc at e6050000 {
+		compatible = "renesas,pfc-sh73a0";
+		reg = <0xe6050000 0x8000>,
+		      <0xe605801c 0x1c>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
 };
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index 44055fe..6ff6ca2 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -40,35 +40,35 @@ static unsigned long pin_pullup_conf[] = {
 };
 
 static const struct pinctrl_map kzm_pinctrl_map[] = {
-	PIN_MAP_MUX_GROUP_DEFAULT("e6826000.i2c", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("e6826000.i2c", "e6050000.pfc",
 				  "i2c3_1", "i2c3"),
 	/* MMCIF */
-	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.mmcif", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
 				  "mmc0_data8_0", "mmc0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.mmcif", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
 				  "mmc0_ctrl_0", "mmc0"),
-	PIN_MAP_CONFIGS_PIN_DEFAULT("e6bd0000.mmcif", "pfc-sh73a0",
+	PIN_MAP_CONFIGS_PIN_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
 				    "PORT279", pin_pullup_conf),
-	PIN_MAP_CONFIGS_GROUP_DEFAULT("e6bd0000.mmcif", "pfc-sh73a0",
+	PIN_MAP_CONFIGS_GROUP_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
 				      "mmc0_data8_0", pin_pullup_conf),
 	/* SCIFA4 */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "e6050000.pfc",
 				  "scifa4_data", "scifa4"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "e6050000.pfc",
 				  "scifa4_ctrl", "scifa4"),
 	/* SDHI0 */
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
 				  "sdhi0_data4", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
 				  "sdhi0_ctrl", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
 				  "sdhi0_cd", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
 				  "sdhi0_wp", "sdhi0"),
 	/* SDHI2 */
-	PIN_MAP_MUX_GROUP_DEFAULT("ee140000.sdhi", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("ee140000.sdhi", "e6050000.pfc",
 				  "sdhi2_data4", "sdhi2"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee140000.sdhi", "pfc-sh73a0",
+	PIN_MAP_MUX_GROUP_DEFAULT("ee140000.sdhi", "e6050000.pfc",
 				  "sdhi2_ctrl", "sdhi2"),
 };
 
@@ -76,7 +76,6 @@ static void __init kzm_init(void)
 {
 	sh73a0_add_standard_devices_dt();
 	pinctrl_register_mappings(kzm_pinctrl_map, ARRAY_SIZE(kzm_pinctrl_map));
-	sh73a0_pinmux_init();
 
 	/* enable SD */
 	gpio_request_one(15, GPIOF_OUT_INIT_HIGH, NULL); /* power */
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:57 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:57 +0900
Subject: [PATCH 18/19] ARM: shmobile: kzm9g-reference: Move SDHI regulators to
 DT
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <f8f77ce940b84c17378db432a05186476bd8dd04.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Create two GPIO-controlled fixed-voltage regulators in the
kzm9g-reference DT and remove manual configuration of the corresponding
GPIOs from board code.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts   | 23 +++++++++++++++++++++--
 arch/arm/mach-shmobile/board-kzm9g-reference.c |  6 ------
 2 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
index 11ae9ad..d2b2c9f 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -13,6 +13,7 @@
 
 /dts-v1/;
 /include/ "sh73a0.dtsi"
+#include <dt-bindings/gpio/gpio.h>
 
 / {
 	model = "KZM-A9-GT";
@@ -58,6 +59,24 @@
 		regulator-boot-on;
 	};
 
+	vmmc_sdhi0: regulator at 2 {
+	        compatible = "regulator-fixed";
+		regulator-name = "SDHI0 Vcc";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&pfc 15 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vmmc_sdhi2: regulator at 3 {
+	        compatible = "regulator-fixed";
+		regulator-name = "SDHI2 Vcc";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&pfc 14 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
 	lan9220 at 10000000 {
 		compatible = "smsc,lan9220", "smsc,lan9115";
 		reg = <0x10000000 0x100>;
@@ -200,7 +219,7 @@
 	pinctrl-0 = <&sdhi0_pins>;
 	pinctrl-names = "default";
 
-	vmmc-supply = <&reg_3p3v>;
+	vmmc-supply = <&vmmc_sdhi0>;
 	bus-width = <4>;
 	status = "okay";
 };
@@ -209,7 +228,7 @@
 	pinctrl-0 = <&sdhi2_pins>;
 	pinctrl-names = "default";
 
-	vmmc-supply = <&reg_3p3v>;
+	vmmc-supply = <&vmmc_sdhi2>;
 	bus-width = <4>;
 	broken-cd;
 	status = "okay";
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index fc2bb37..1847b4d 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -21,7 +21,6 @@
  */
 
 #include <linux/delay.h>
-#include <linux/gpio.h>
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/irqchip.h>
@@ -37,11 +36,6 @@ static void __init kzm_init(void)
 {
 	sh73a0_add_standard_devices_dt();
 
-	/* enable SD */
-	gpio_request_one(15, GPIOF_OUT_INIT_HIGH, NULL); /* power */
-
-	gpio_request_one(14, GPIOF_OUT_INIT_HIGH, NULL); /* power */
-
 #ifdef CONFIG_CACHE_L2X0
 	/* Early BRESP enable, Shared attribute override enable, 64K*8way */
 	l2x0_init(IOMEM(0xf0100000), 0x40460000, 0x82000fff);
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:33:56 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:33:56 +0900
Subject: [PATCH 02/16] ARM: shmobile: r8a7790: add thermal driver support
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <0b8eeba45143030e29ec39c43daa1383146581e6.1374624383.git.horms+renesas@verge.net.au>

The current temperature may be read using:
cat /sys/class/thermal/thermal_zone0/temp

Based on similar work for the r8a73a4 by Kuninori Morimoto.

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7790.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index b7e78b9..bc40a44 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -148,6 +148,17 @@ static struct resource irqc0_resources[] __initdata = {
 					  &irqc##idx##_data,		\
 					  sizeof(struct renesas_irqc_config))
 
+static struct resource thermal_resources[] __initdata = {
+	DEFINE_RES_MEM(0xe61f0000, 0x14),
+	DEFINE_RES_MEM(0xe61f0100, 0x38),
+	DEFINE_RES_IRQ(gic_spi(69)),
+};
+
+#define r8a7790_register_thermal()					\
+	platform_device_register_simple("rcar_thermal", -1,		\
+					thermal_resources,		\
+					ARRAY_SIZE(thermal_resources))
+
 void __init r8a7790_add_standard_devices(void)
 {
 	r8a7790_register_scif(SCIFA0);
@@ -161,6 +172,7 @@ void __init r8a7790_add_standard_devices(void)
 	r8a7790_register_scif(HSCIF0);
 	r8a7790_register_scif(HSCIF1);
 	r8a7790_register_irqc(0);
+	r8a7790_register_thermal();
 }
 
 void __init r8a7790_timer_init(void)
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:33:55 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:33:55 +0900
Subject: [PATCH 01/16] ARM: shmobile: r8a7790: add clocks for thermal
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <a4b91be0b607ffecf6cf9dacdefcaa0797340e3c.1374624383.git.horms+renesas@verge.net.au>

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7790.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c b/arch/arm/mach-shmobile/clock-r8a7790.c
index 5d71313..28eccd1 100644
--- a/arch/arm/mach-shmobile/clock-r8a7790.c
+++ b/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -49,6 +49,7 @@
 
 #define SMSTPCR2 0xe6150138
 #define SMSTPCR3 0xe615013c
+#define SMSTPCR5 0xe6150144
 #define SMSTPCR7 0xe615014c
 
 #define MODEMR		0xE6160060
@@ -182,6 +183,7 @@ static struct clk div6_clks[DIV6_NR] = {
 enum {
 	MSTP721, MSTP720,
 	MSTP717, MSTP716,
+	MSTP522,
 	MSTP315, MSTP314, MSTP313, MSTP312, MSTP311, MSTP305, MSTP304,
 	MSTP216, MSTP207, MSTP206, MSTP204, MSTP203, MSTP202,
 	MSTP_NR
@@ -203,6 +205,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP204] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 4, 0), /* SCIFA0 */
 	[MSTP203] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 3, 0), /* SCIFA1 */
 	[MSTP202] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 2, 0), /* SCIFA2 */
+	[MSTP522] = SH_CLK_MSTP32(&extal_clk, SMSTPCR5, 22, 0), /* Thermal */
 	[MSTP717] = SH_CLK_MSTP32(&zs_clk, SMSTPCR7, 17, 0), /* HSCIF0 */
 	[MSTP716] = SH_CLK_MSTP32(&zs_clk, SMSTPCR7, 16, 0), /* HSCIF1 */
 };
@@ -254,6 +257,7 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh-sci.7", &mstp_clks[MSTP720]),
 	CLKDEV_DEV_ID("sh-sci.8", &mstp_clks[MSTP717]),
 	CLKDEV_DEV_ID("sh-sci.9", &mstp_clks[MSTP716]),
+	CLKDEV_DEV_ID("rcar_thermal", &mstp_clks[MSTP522]),
 	CLKDEV_DEV_ID("ee200000.mmcif", &mstp_clks[MSTP315]),
 	CLKDEV_DEV_ID("sh_mmcif.0", &mstp_clks[MSTP315]),
 	CLKDEV_DEV_ID("ee100000.sdhi", &mstp_clks[MSTP314]),
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:33:59 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:33:59 +0900
Subject: [PATCH 05/16] ARM: shmobile: r8a73a4: safeguard against wrong
 clk_set_rate() uses
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <d1c3c959f2206dad0582876af2510aded4f9eac5.1374624383.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

clk_set_rate() should only be called with exact rates, returned by
clk_round_rate(). However, it is still good to verify, that the value,
passed to clock's .set_rate() method is at least valid. This patch adds
such a check for the Z-clock on r8a73a4.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a73a4.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a73a4.c b/arch/arm/mach-shmobile/clock-r8a73a4.c
index 824789c..22f10ff 100644
--- a/arch/arm/mach-shmobile/clock-r8a73a4.c
+++ b/arch/arm/mach-shmobile/clock-r8a73a4.c
@@ -225,16 +225,28 @@ static int zclk_set_rate(struct clk *clk, unsigned long rate)
 		goto done;
 	}
 
-	frqcrc = clk->mapped_reg + (FRQCRC - (u32)clk->enable_reg);
+	/*
+	 * Users are supposed to first call clk_set_rate() only with
+	 * clk_round_rate() results. So, we don't fix wrong rates here, but
+	 * guard against them anyway
+	 */
 
 	p_rate = clk_get_rate(clk->parent);
 	if (rate == p_rate) {
 		val = 0;
 	} else {
 		step = DIV_ROUND_CLOSEST(p_rate, 32);
+
+		if (rate > p_rate || rate < step) {
+			ret = -EINVAL;
+			goto done;
+		}
+
 		val = 32 - rate / step;
 	}
 
+	frqcrc = clk->mapped_reg + (FRQCRC - (u32)clk->enable_reg);
+
 	iowrite32((ioread32(frqcrc) & ~(clk->div_mask << clk->enable_bit)) |
 		  (val << clk->enable_bit), frqcrc);
 
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:33:57 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:33:57 +0900
Subject: [PATCH 03/16] ARM: shmobile: r8a73a4: wait for completion when
 kicking the clock
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <8d27657286a1e9e6ee7adaf4d0638cefd708a6fa.1374624383.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

To reconfigure clocks, controlled by FRQCRA and FRQCRB, a kick bit has to
be set and to make sure the setting has taken effect, it has to be read
back repeatedly until it is cleared by the hardware. This patch adds the
waiting part, that was missing until now.

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a73a4.c | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a73a4.c b/arch/arm/mach-shmobile/clock-r8a73a4.c
index 5f7fe62..d5176d0 100644
--- a/arch/arm/mach-shmobile/clock-r8a73a4.c
+++ b/arch/arm/mach-shmobile/clock-r8a73a4.c
@@ -184,6 +184,21 @@ PLL_CLOCK(pll2h_clk, &main_div2_clk, pll_parent_main_extal, 3, 5, PLL2HCR, 5);
 
 SH_FIXED_RATIO_CLK(pll1_div2_clk,	pll1_clk,	div2);
 
+static int frqcr_kick_do(struct clk *clk)
+{
+	int i;
+
+	/* set KICK bit in FRQCRB to update hardware setting, check success */
+	iowrite32(ioread32(CPG_MAP(FRQCRB)) | BIT(31), CPG_MAP(FRQCRB));
+	for (i = 1000; i; i--)
+		if (ioread32(CPG_MAP(FRQCRB)) & BIT(31))
+			cpu_relax();
+		else
+			return 0;
+
+	return -ETIMEDOUT;
+}
+
 static struct clk *main_clks[] = {
 	&extalr_clk,
 	&extal1_clk,
@@ -205,12 +220,7 @@ static struct clk *main_clks[] = {
 /* DIV4 */
 static void div4_kick(struct clk *clk)
 {
-	unsigned long value;
-
-	/* set KICK bit in FRQCRB to update hardware setting */
-	value = ioread32(CPG_MAP(FRQCRB));
-	value |= (1 << 31);
-	iowrite32(value, CPG_MAP(FRQCRB));
+	frqcr_kick_do(clk);
 }
 
 static int divisors[] = { 2, 3, 4, 6, 8, 12, 16, 18, 24, 0, 36, 48, 10};
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:33:58 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:33:58 +0900
Subject: [PATCH 04/16] ARM: shmobile: r8a73a4: implement CPU clock scaling for
 CPUFreq
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <181135e0b7f58735969619c89548f6a37cd0ee36.1374624383.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

This patch adds support for the Z-clock on r8a73a4 SoCs, which is driving
the Cortex A15 core, and a "cpufreq-cpu0" platform device. Adding an
"operating-points" property to the CPU0 DT node and a regulator, this
patch allows platforms to use the generic cpufreq-cpu0 driver to use
SoC's DVFS capabilities.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig         |   2 +
 arch/arm/mach-shmobile/clock-r8a73a4.c | 123 ++++++++++++++++++++++++++++++++-
 arch/arm/mach-shmobile/setup-r8a73a4.c |   1 +
 3 files changed, 125 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 7c5034a..734b3ee 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -26,6 +26,8 @@ config ARCH_R8A73A4
 	select HAVE_ARM_ARCH_TIMER
 	select SH_CLK_CPG
 	select RENESAS_IRQC
+	select ARCH_HAS_CPUFREQ
+	select ARCH_HAS_OPP
 
 config ARCH_R8A7740
 	bool "R-Mobile A1 (R8A77400)"
diff --git a/arch/arm/mach-shmobile/clock-r8a73a4.c b/arch/arm/mach-shmobile/clock-r8a73a4.c
index d5176d0..824789c 100644
--- a/arch/arm/mach-shmobile/clock-r8a73a4.c
+++ b/arch/arm/mach-shmobile/clock-r8a73a4.c
@@ -34,6 +34,7 @@
 
 #define FRQCRA		0xE6150000
 #define FRQCRB		0xE6150004
+#define FRQCRC		0xE61500E0
 #define VCLKCR1		0xE6150008
 #define VCLKCR2		0xE615000C
 #define VCLKCR3		0xE615001C
@@ -52,6 +53,7 @@
 #define HSICKCR		0xE615026C
 #define M4CKCR		0xE6150098
 #define PLLECR		0xE61500D0
+#define PLL0CR		0xE61500D8
 #define PLL1CR		0xE6150028
 #define PLL2CR		0xE615002C
 #define PLL2SCR		0xE61501F4
@@ -177,6 +179,7 @@ static struct sh_clk_ops pll_clk_ops = {
 		.mapping	= &cpg_mapping,		\
 	}
 
+PLL_CLOCK(pll0_clk,  &main_clk,      pll_parent_main,      1, 20, PLL0CR,  0);
 PLL_CLOCK(pll1_clk,  &main_clk,      pll_parent_main,       1, 7, PLL1CR,  1);
 PLL_CLOCK(pll2_clk,  &main_div2_clk, pll_parent_main_extal, 3, 5, PLL2CR,  2);
 PLL_CLOCK(pll2s_clk, &main_div2_clk, pll_parent_main_extal, 3, 5, PLL2SCR, 4);
@@ -184,6 +187,14 @@ PLL_CLOCK(pll2h_clk, &main_div2_clk, pll_parent_main_extal, 3, 5, PLL2HCR, 5);
 
 SH_FIXED_RATIO_CLK(pll1_div2_clk,	pll1_clk,	div2);
 
+static atomic_t frqcr_lock;
+
+/* Several clocks need to access FRQCRB, have to lock */
+static bool frqcr_kick_check(struct clk *clk)
+{
+	return !(ioread32(CPG_MAP(FRQCRB)) & BIT(31));
+}
+
 static int frqcr_kick_do(struct clk *clk)
 {
 	int i;
@@ -199,6 +210,107 @@ static int frqcr_kick_do(struct clk *clk)
 	return -ETIMEDOUT;
 }
 
+static int zclk_set_rate(struct clk *clk, unsigned long rate)
+{
+	void __iomem *frqcrc;
+	int ret;
+	unsigned long step, p_rate;
+	u32 val;
+
+	if (!clk->parent || !__clk_get(clk->parent))
+		return -ENODEV;
+
+	if (!atomic_inc_and_test(&frqcr_lock) || !frqcr_kick_check(clk)) {
+		ret = -EBUSY;
+		goto done;
+	}
+
+	frqcrc = clk->mapped_reg + (FRQCRC - (u32)clk->enable_reg);
+
+	p_rate = clk_get_rate(clk->parent);
+	if (rate == p_rate) {
+		val = 0;
+	} else {
+		step = DIV_ROUND_CLOSEST(p_rate, 32);
+		val = 32 - rate / step;
+	}
+
+	iowrite32((ioread32(frqcrc) & ~(clk->div_mask << clk->enable_bit)) |
+		  (val << clk->enable_bit), frqcrc);
+
+	ret = frqcr_kick_do(clk);
+
+done:
+	atomic_dec(&frqcr_lock);
+	__clk_put(clk->parent);
+	return ret;
+}
+
+static long zclk_round_rate(struct clk *clk, unsigned long rate)
+{
+	/*
+	 * theoretical rate = parent rate * multiplier / 32,
+	 * where 1 <= multiplier <= 32. Therefore we should do
+	 * multiplier = rate * 32 / parent rate
+	 * rounded rate = parent rate * multiplier / 32.
+	 * However, multiplication before division won't fit in 32 bits, so
+	 * we sacrifice some precision by first dividing and then multiplying.
+	 * To find the nearest divisor we calculate both and pick up the best
+	 * one. This avoids 64-bit arithmetics.
+	 */
+	unsigned long step, mul_min, mul_max, rate_min, rate_max;
+
+	rate_max = clk_get_rate(clk->parent);
+
+	/* output freq <= parent */
+	if (rate >= rate_max)
+		return rate_max;
+
+	step = DIV_ROUND_CLOSEST(rate_max, 32);
+	/* output freq >= parent / 32 */
+	if (step >= rate)
+		return step;
+
+	mul_min = rate / step;
+	mul_max = DIV_ROUND_UP(rate, step);
+	rate_min = step * mul_min;
+	if (mul_max == mul_min)
+		return rate_min;
+
+	rate_max = step * mul_max;
+
+	if (rate_max - rate <  rate - rate_min)
+		return rate_max;
+
+	return rate_min;
+}
+
+static unsigned long zclk_recalc(struct clk *clk)
+{
+	void __iomem *frqcrc = FRQCRC - (u32)clk->enable_reg + clk->mapped_reg;
+	unsigned int max = clk->div_mask + 1;
+	unsigned long val = ((ioread32(frqcrc) >> clk->enable_bit) &
+			     clk->div_mask);
+
+	return DIV_ROUND_CLOSEST(clk_get_rate(clk->parent), max) *
+		(max - val);
+}
+
+static struct sh_clk_ops zclk_ops = {
+	.recalc = zclk_recalc,
+	.set_rate = zclk_set_rate,
+	.round_rate = zclk_round_rate,
+};
+
+static struct clk z_clk = {
+	.parent = &pll0_clk,
+	.div_mask = 0x1f,
+	.enable_bit = 8,
+	/* We'll need to access FRQCRB and FRQCRC */
+	.enable_reg = (void __iomem *)FRQCRB,
+	.ops = &zclk_ops,
+};
+
 static struct clk *main_clks[] = {
 	&extalr_clk,
 	&extal1_clk,
@@ -210,17 +322,21 @@ static struct clk *main_clks[] = {
 	&main_div2_clk,
 	&fsiack_clk,
 	&fsibck_clk,
+	&pll0_clk,
 	&pll1_clk,
 	&pll1_div2_clk,
 	&pll2_clk,
 	&pll2s_clk,
 	&pll2h_clk,
+	&z_clk,
 };
 
 /* DIV4 */
 static void div4_kick(struct clk *clk)
 {
-	frqcr_kick_do(clk);
+	if (!WARN(!atomic_inc_and_test(&frqcr_lock), "FRQCR* lock broken!\n"))
+		frqcr_kick_do(clk);
+	atomic_dec(&frqcr_lock);
 }
 
 static int divisors[] = { 2, 3, 4, 6, 8, 12, 16, 18, 24, 0, 36, 48, 10};
@@ -396,6 +512,9 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_CON_ID("pll2s",			&pll2s_clk),
 	CLKDEV_CON_ID("pll2h",			&pll2h_clk),
 
+	/* CPU clock */
+	CLKDEV_DEV_ID("cpufreq-cpu0",		&z_clk),
+
 	/* DIV6 */
 	CLKDEV_CON_ID("zb",			&div6_clks[DIV6_ZB]),
 	CLKDEV_CON_ID("vck1",			&div6_clks[DIV6_VCK1]),
@@ -439,6 +558,8 @@ void __init r8a73a4_clock_init(void)
 	int k, ret = 0;
 	u32 ckscr;
 
+	atomic_set(&frqcr_lock, -1);
+
 	reg = ioremap_nocache(CKSCR, PAGE_SIZE);
 	BUG_ON(!reg);
 	ckscr = ioread32(reg);
diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c b/arch/arm/mach-shmobile/setup-r8a73a4.c
index a8c4e41..9c52096 100644
--- a/arch/arm/mach-shmobile/setup-r8a73a4.c
+++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
@@ -184,6 +184,7 @@ void __init r8a73a4_add_standard_devices(void)
 #ifdef CONFIG_USE_OF
 void __init r8a73a4_add_standard_devices_dt(void)
 {
+	platform_device_register_simple("cpufreq-cpu0", -1, NULL, 0);
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:02 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:02 +0900
Subject: [PATCH 08/16] ARM: shmobile: Sort r8a7790 MSTP entries
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <29eb2ba89c63c6f57dc3a8b1a89241c7a877a3c8.1374624383.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

The r8a7790 MSTP bits should be kept sorted in the same way
as on other mach-shmobile SoCs. Move the HSCIF and thermal
bits to clean up the current state.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7790.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c b/arch/arm/mach-shmobile/clock-r8a7790.c
index 28eccd1..10d99b3 100644
--- a/arch/arm/mach-shmobile/clock-r8a7790.c
+++ b/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -192,6 +192,9 @@ enum {
 static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP721] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 21, 0), /* SCIF0 */
 	[MSTP720] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 20, 0), /* SCIF1 */
+	[MSTP717] = SH_CLK_MSTP32(&zs_clk, SMSTPCR7, 17, 0), /* HSCIF0 */
+	[MSTP716] = SH_CLK_MSTP32(&zs_clk, SMSTPCR7, 16, 0), /* HSCIF1 */
+	[MSTP522] = SH_CLK_MSTP32(&extal_clk, SMSTPCR5, 22, 0), /* Thermal */
 	[MSTP315] = SH_CLK_MSTP32(&div6_clks[DIV6_MMC0], SMSTPCR3, 15, 0), /* MMC0 */
 	[MSTP314] = SH_CLK_MSTP32(&div4_clks[DIV4_SD0], SMSTPCR3, 14, 0), /* SDHI0 */
 	[MSTP313] = SH_CLK_MSTP32(&div4_clks[DIV4_SD1], SMSTPCR3, 13, 0), /* SDHI1 */
@@ -205,9 +208,6 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP204] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 4, 0), /* SCIFA0 */
 	[MSTP203] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 3, 0), /* SCIFA1 */
 	[MSTP202] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 2, 0), /* SCIFA2 */
-	[MSTP522] = SH_CLK_MSTP32(&extal_clk, SMSTPCR5, 22, 0), /* Thermal */
-	[MSTP717] = SH_CLK_MSTP32(&zs_clk, SMSTPCR7, 17, 0), /* HSCIF0 */
-	[MSTP716] = SH_CLK_MSTP32(&zs_clk, SMSTPCR7, 16, 0), /* HSCIF1 */
 };
 
 static struct clk_lookup lookups[] = {
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:07 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:07 +0900
Subject: [PATCH 14/16] ARM: shmobile: r8a7740: add MMCIF DMA definitions
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <9a1456242c7c644d0032032ba80e8538b8322d3c.1374624383.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Add DMA channel slave IDs and configuration entries for the r8a7740
MMCIF controller.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/r8a7740.h |  2 ++
 arch/arm/mach-shmobile/setup-r8a7740.c        | 10 ++++++++++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/mach-shmobile/include/mach/r8a7740.h b/arch/arm/mach-shmobile/include/mach/r8a7740.h
index b34d19b..56f3750 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7740.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7740.h
@@ -42,6 +42,8 @@ enum {
 	SHDMA_SLAVE_FSIB_TX,
 	SHDMA_SLAVE_USBHS_TX,
 	SHDMA_SLAVE_USBHS_RX,
+	SHDMA_SLAVE_MMCIF_TX,
+	SHDMA_SLAVE_MMCIF_RX,
 };
 
 extern void r8a7740_meram_workaround(void);
diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index ac29c2e..84c5bb6 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -588,6 +588,16 @@ static const struct sh_dmae_slave_config r8a7740_dmae_slaves[] = {
 		.addr		= 0xfe1f0064,
 		.chcr		= CHCR_TX(XMIT_SZ_32BIT),
 		.mid_rid	= 0xb5,
+	}, {
+		.slave_id	= SHDMA_SLAVE_MMCIF_TX,
+		.addr		= 0xe6bd0034,
+		.chcr		= CHCR_TX(XMIT_SZ_32BIT),
+		.mid_rid	= 0xd1,
+	}, {
+		.slave_id	= SHDMA_SLAVE_MMCIF_RX,
+		.addr		= 0xe6bd0034,
+		.chcr		= CHCR_RX(XMIT_SZ_32BIT),
+		.mid_rid	= 0xd2,
 	},
 };
 
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:00 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:00 +0900
Subject: [PATCH 06/16] ARM: shmobile: r8a73a4: add Z2 clock support
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <a040f22d2c2e82347f978b52e7402a7387e5dee5.1374624383.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

The Z2 clock on r8a73a4 is used to clock the 4 Cortex A7 cores on the SoC.
Add a definition for this clock to later use it from the arm_big_little
CPUFreq driver.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a73a4.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/mach-shmobile/clock-r8a73a4.c b/arch/arm/mach-shmobile/clock-r8a73a4.c
index 22f10ff..27ff58c 100644
--- a/arch/arm/mach-shmobile/clock-r8a73a4.c
+++ b/arch/arm/mach-shmobile/clock-r8a73a4.c
@@ -323,6 +323,21 @@ static struct clk z_clk = {
 	.ops = &zclk_ops,
 };
 
+/*
+ * It seems only 1/2 divider is usable in manual mode. 1/2 / 2/3
+ * switching is only available in auto-DVFS mode
+ */
+SH_FIXED_RATIO_CLK(pll0_div2_clk,	pll0_clk,		div2);
+
+static struct clk z2_clk = {
+	.parent = &pll0_div2_clk,
+	.div_mask = 0x1f,
+	.enable_bit = 0,
+	/* We'll need to access FRQCRB and FRQCRC */
+	.enable_reg = (void __iomem *)FRQCRB,
+	.ops = &zclk_ops,
+};
+
 static struct clk *main_clks[] = {
 	&extalr_clk,
 	&extal1_clk,
@@ -341,6 +356,8 @@ static struct clk *main_clks[] = {
 	&pll2s_clk,
 	&pll2h_clk,
 	&z_clk,
+	&pll0_div2_clk,
+	&z2_clk,
 };
 
 /* DIV4 */
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:05 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:05 +0900
Subject: [PATCH 12/16] ARM: shmobile: Make r8a73a4 Arch timer optional
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <b9a30ef1d354c0bc0cc6d973bbe7ede9f00716ee.1374624383.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Update the r8a73a4 code to allow using other
timers than Arch timer for clock event

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig                | 1 -
 arch/arm/mach-shmobile/board-ape6evm.c        | 1 +
 arch/arm/mach-shmobile/include/mach/r8a73a4.h | 1 +
 arch/arm/mach-shmobile/setup-r8a73a4.c        | 8 ++++++++
 4 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 406077c..dd80f21 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -23,7 +23,6 @@ config ARCH_R8A73A4
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_GIC
 	select CPU_V7
-	select HAVE_ARM_ARCH_TIMER
 	select SH_CLK_CPG
 	select RENESAS_IRQC
 	select ARCH_HAS_CPUFREQ
diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
index 1fbc39a..af6dd39 100644
--- a/arch/arm/mach-shmobile/board-ape6evm.c
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -101,6 +101,7 @@ static const char *ape6evm_boards_compat_dt[] __initdata = {
 };
 
 DT_MACHINE_START(APE6EVM_DT, "ape6evm")
+	.init_early	= r8a73a4_init_delay,
 	.init_time	= shmobile_timer_init,
 	.init_machine	= ape6evm_add_standard_devices,
 	.dt_compat	= ape6evm_boards_compat_dt,
diff --git a/arch/arm/mach-shmobile/include/mach/r8a73a4.h b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
index f043103..144a85e 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a73a4.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a73a4.h
@@ -4,5 +4,6 @@
 void r8a73a4_add_standard_devices(void);
 void r8a73a4_clock_init(void);
 void r8a73a4_pinmux_init(void);
+void r8a73a4_init_delay(void);
 
 #endif /* __ASM_R8A73A4_H__ */
diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c b/arch/arm/mach-shmobile/setup-r8a73a4.c
index b8dddf4..d533bd2 100644
--- a/arch/arm/mach-shmobile/setup-r8a73a4.c
+++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
@@ -202,6 +202,13 @@ void __init r8a73a4_add_standard_devices(void)
 	r8a7790_register_cmt(10);
 }
 
+void __init r8a73a4_init_delay(void)
+{
+#ifndef CONFIG_ARM_ARCH_TIMER
+	shmobile_setup_delay(1500, 2, 4); /* Cortex-A15 @ 1500MHz */
+#endif
+}
+
 #ifdef CONFIG_USE_OF
 void __init r8a73a4_add_standard_devices_dt(void)
 {
@@ -215,6 +222,7 @@ static const char *r8a73a4_boards_compat_dt[] __initdata = {
 };
 
 DT_MACHINE_START(R8A73A4_DT, "Generic R8A73A4 (Flattened Device Tree)")
+	.init_early	= r8a73a4_init_delay,
 	.init_machine	= r8a73a4_add_standard_devices_dt,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a73a4_boards_compat_dt,
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:58 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:58 +0900
Subject: [PATCH 19/19] ARM: shmobile: kzm9g-reference: Add LED1-LED4 to the
 device tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <1469273960de45275f33276c7254456edcba9da2.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

LED1 to LED4 are GPIO LEDs. Add corresponding DT nodes.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
index d2b2c9f..b99e890 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -89,6 +89,22 @@
 		vddvario-supply = <&reg_1p8v>;
 		vdd33a-supply = <&reg_3p3v>;
 	};
+
+	leds {
+		compatible = "gpio-leds";
+		led1 {
+			gpios = <&pfc 20 GPIO_ACTIVE_LOW>;
+		};
+		led2 {
+			gpios = <&pfc 21 GPIO_ACTIVE_LOW>;
+		};
+		led3 {
+			gpios = <&pfc 22 GPIO_ACTIVE_LOW>;
+		};
+		led4 {
+			gpios = <&pfc 23 GPIO_ACTIVE_LOW>;
+		};
+	};
 };
 
 &i2c0 {
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:32:54 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:54 +0900
Subject: [PATCH 15/19] ARM: shmobile: marzen-reference: Move pinctrl mappings
 to device tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <c4a003f6075c8e3e4e5a0d8958518882d779ef74.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Replace the pinctrl mappings in board code by device tree mappings.
For devices that are still instantiated from board code reference the
mappings as the default pin controller state to apply them at boot time.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779-marzen-reference.dts  | 35 +++++++++++++++++++++++++
 arch/arm/mach-shmobile/board-marzen-reference.c | 27 -------------------
 2 files changed, 35 insertions(+), 27 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779-marzen-reference.dts b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
index 72be4c8..6d20247 100644
--- a/arch/arm/boot/dts/r8a7779-marzen-reference.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen-reference.dts
@@ -37,6 +37,9 @@
 	lan0 at 18000000 {
 		compatible = "smsc,lan9220", "smsc,lan9115";
 		reg = <0x18000000 0x100>;
+		pinctrl-0 = <&lan0_pins>;
+		pinctrl-names = "default";
+
 		phy-mode = "mii";
 		interrupt-parent = <&gic>;
 		interrupts = <0 28 0x4>;
@@ -45,3 +48,35 @@
 		vdd33a-supply = <&fixedregulator3v3>;
 	};
 };
+
+&pfc {
+	pinctrl-0 = <&scif2_pins &scif4_pins &sdhi0_pins>;
+	pinctrl-names = "default";
+
+	lan0_pins: lan0 {
+		intc {
+			renesas,groups = "intc_irq1_b";
+			renesas,function = "intc";
+		};
+		lbsc {
+			renesas,groups = "lbsc_ex_cs0";
+			renesas,function = "lbsc";
+		};
+	};
+
+	scif2_pins: scif2 {
+		renesas,groups = "scif2_data_c";
+		renesas,function = "scif2";
+	};
+
+	scif4_pins: scif4 {
+		renesas,groups = "scif4_data";
+		renesas,function = "scif4";
+	};
+
+	sdhi0_pins: sdhi0 {
+		renesas,groups = "sdhi0_data4", "sdhi0_ctrl", "sdhi0_cd",
+				 "sdhi0_wp";
+		renesas,function = "sdhi0";
+	};
+};
diff --git a/arch/arm/mach-shmobile/board-marzen-reference.c b/arch/arm/mach-shmobile/board-marzen-reference.c
index 94804f3..3d1c439 100644
--- a/arch/arm/mach-shmobile/board-marzen-reference.c
+++ b/arch/arm/mach-shmobile/board-marzen-reference.c
@@ -19,41 +19,14 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  */
 
-#include <linux/pinctrl/machine.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <asm/irq.h>
 #include <asm/mach/arch.h>
 
-static const struct pinctrl_map marzen_pinctrl_map[] = {
-	/* SCIF2 (CN18: DEBUG0) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.2", "fffc0000.pfc",
-				  "scif2_data_c", "scif2"),
-	/* SCIF4 (CN19: DEBUG1) */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "fffc0000.pfc",
-				  "scif4_data", "scif4"),
-	/* SDHI0 */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
-				  "sdhi0_data4", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
-				  "sdhi0_ctrl", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
-				  "sdhi0_cd", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "fffc0000.pfc",
-				  "sdhi0_wp", "sdhi0"),
-	/* SMSC */
-	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "fffc0000.pfc",
-				  "intc_irq1_b", "intc"),
-	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "fffc0000.pfc",
-				  "lbsc_ex_cs0", "lbsc"),
-};
-
 static void __init marzen_init(void)
 {
-	pinctrl_register_mappings(marzen_pinctrl_map,
-				  ARRAY_SIZE(marzen_pinctrl_map));
-
 	r8a7779_add_standard_devices_dt();
 }
 
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:33:45 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:33:45 +0900
Subject: [GIT 00/16] Renesas ARM based SoC updates for v3.12
Message-ID: <cover.1374624383.git.horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

please consider the following Renesas ARM based SoC updates for v3.12.

This pull request is based on renesas-dt-for-v3.12 which I have
previously sent a pull request for.

The following changes since commit 66a5cab04d339d02b93a4671eadf8e251dbfdc2c:

  ARM: shmobile: Add SMSC ethernet chip to KZM9D DT reference (2013-07-17 10:06:47 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-for-v3.12

for you to fetch changes up to 81b9d5351fa96caad4accc6711bc1b9342927d4a:

  ARM: shmobile: Setup r8a7790 arch timer based on MD pins (2013-07-17 14:26:56 +0900)

----------------------------------------------------------------
Renesas ARM based SoC updates for v3.12

* Setup arch timer based on MD pins on r8a7790 SoC
* Thermal driver support for r8a7790 SoC
* Make arch timer optional for r8a7790 and r8a73a4 SoCs
* CMT10 clock event for r8a7790 and r8a73a4 SoCs
* Increased clock coverage for r8a73a4 SoC
* MMCIF DMA definitions for r8a7740 SoC
* Disconnect SMP code from clocks on emev2 SoC

----------------------------------------------------------------
Guennadi Liakhovetski (6):
      ARM: shmobile: r8a73a4: wait for completion when kicking the clock
      ARM: shmobile: r8a73a4: implement CPU clock scaling for CPUFreq
      ARM: shmobile: r8a73a4: safeguard against wrong clk_set_rate() uses
      ARM: shmobile: r8a73a4: add Z2 clock support
      ARM: shmobile: r8a73a4: add clocks for I2C controllers
      ARM: shmobile: r8a7740: add MMCIF DMA definitions

Magnus Damm (8):
      ARM: shmobile: Sort r8a7790 MSTP entries
      ARM: shmobile: Add r8a7790 CMT00 clock event
      ARM: shmobile: Make r8a7790 Arch timer optional
      ARM: shmobile: Add r8a73a4 CMT10 clock event
      ARM: shmobile: Make r8a73a4 Arch timer optional
      ARM: shmobile: Disconnect EMEV2 SMP code from clocks
      ARM: shmobile: Introduce r8a7790_read_mode_pins()
      ARM: shmobile: Setup r8a7790 arch timer based on MD pins

Simon Horman (2):
      ARM: shmobile: r8a7790: add clocks for thermal
      ARM: shmobile: r8a7790: add thermal driver support

 arch/arm/mach-shmobile/Kconfig                |   4 +-
 arch/arm/mach-shmobile/board-ape6evm.c        |   1 +
 arch/arm/mach-shmobile/board-lager.c          |   1 +
 arch/arm/mach-shmobile/clock-emev2.c          |  18 ---
 arch/arm/mach-shmobile/clock-r8a73a4.c        | 199 ++++++++++++++++++++++++--
 arch/arm/mach-shmobile/clock-r8a7790.c        |  23 +--
 arch/arm/mach-shmobile/include/mach/emev2.h   |   1 -
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |   1 +
 arch/arm/mach-shmobile/include/mach/r8a7740.h |   2 +
 arch/arm/mach-shmobile/include/mach/r8a7790.h |   4 +
 arch/arm/mach-shmobile/setup-r8a73a4.c        |  30 ++++
 arch/arm/mach-shmobile/setup-r8a7740.c        |  10 ++
 arch/arm/mach-shmobile/setup-r8a7790.c        | 106 +++++++++++++-
 arch/arm/mach-shmobile/smp-emev2.c            |  11 +-
 14 files changed, 363 insertions(+), 48 deletions(-)


From horms+renesas at verge.net.au  Tue Jul 23 20:32:56 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:32:56 +0900
Subject: [PATCH 17/19] ARM: shmobile: kzm9g-reference: Move pinctrl mappings
 to device tree
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <ec028600f4a4bd1b272465caea3e2ff066e40377.1374625203.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Replace the pinctrl mappings in board code by device tree mappings.
For devices that are still instantiated from board code reference the
mappings as the default pin controller state to apply them at boot time.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts   | 51 ++++++++++++++++++++++++++
 arch/arm/mach-shmobile/board-kzm9g-reference.c | 40 --------------------
 2 files changed, 51 insertions(+), 40 deletions(-)

diff --git a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
index b6f759e..11ae9ad 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
@@ -145,19 +145,70 @@
 	};
 };
 
+&i2c3 {
+	pinctrl-0 = <&i2c3_pins>;
+	pinctrl-names = "default";
+};
+
 &mmcif {
+	pinctrl-0 = <&mmcif_pins>;
+	pinctrl-names = "default";
+
 	bus-width = <8>;
 	vmmc-supply = <&reg_1p8v>;
 	status = "okay";
 };
 
+&pfc {
+	pinctrl-0 = <&scifa4_pins>;
+	pinctrl-names = "default";
+
+	i2c3_pins: i2c3 {
+		renesas,groups = "i2c3_1";
+		renesas,function = "i2c3";
+	};
+
+	mmcif_pins: mmcif {
+		mux {
+			renesas,groups = "mmc0_data8_0", "mmc0_ctrl_0";
+			renesas,function = "mmc0";
+		};
+		cfg {
+			renesas,groups = "mmc0_data8_0";
+			renesas,pins = "PORT279";
+			bias-pull-up;
+		};
+	};
+
+	scifa4_pins: scifa4 {
+		renesas,groups = "scifa4_data", "scifa4_ctrl";
+		renesas,function = "scifa4";
+	};
+
+	sdhi0_pins: sdhi0 {
+		renesas,groups = "sdhi0_data4", "sdhi0_ctrl", "sdhi0_cd", "sdhi0_wp";
+		renesas,function = "sdhi0";
+	};
+
+	sdhi2_pins: sdhi2 {
+		renesas,groups = "sdhi2_data4", "sdhi2_ctrl";
+		renesas,function = "sdhi2";
+	};
+};
+
 &sdhi0 {
+	pinctrl-0 = <&sdhi0_pins>;
+	pinctrl-names = "default";
+
 	vmmc-supply = <&reg_3p3v>;
 	bus-width = <4>;
 	status = "okay";
 };
 
 &sdhi2 {
+	pinctrl-0 = <&sdhi2_pins>;
+	pinctrl-names = "default";
+
 	vmmc-supply = <&reg_3p3v>;
 	bus-width = <4>;
 	broken-cd;
diff --git a/arch/arm/mach-shmobile/board-kzm9g-reference.c b/arch/arm/mach-shmobile/board-kzm9g-reference.c
index 6ff6ca2..fc2bb37 100644
--- a/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9g-reference.c
@@ -27,55 +27,15 @@
 #include <linux/irqchip.h>
 #include <linux/input.h>
 #include <linux/of_platform.h>
-#include <linux/pinctrl/machine.h>
-#include <linux/pinctrl/pinconf-generic.h>
 #include <mach/sh73a0.h>
 #include <mach/common.h>
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
-static unsigned long pin_pullup_conf[] = {
-	PIN_CONF_PACKED(PIN_CONFIG_BIAS_PULL_UP, 0),
-};
-
-static const struct pinctrl_map kzm_pinctrl_map[] = {
-	PIN_MAP_MUX_GROUP_DEFAULT("e6826000.i2c", "e6050000.pfc",
-				  "i2c3_1", "i2c3"),
-	/* MMCIF */
-	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
-				  "mmc0_data8_0", "mmc0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
-				  "mmc0_ctrl_0", "mmc0"),
-	PIN_MAP_CONFIGS_PIN_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
-				    "PORT279", pin_pullup_conf),
-	PIN_MAP_CONFIGS_GROUP_DEFAULT("e6bd0000.mmcif", "e6050000.pfc",
-				      "mmc0_data8_0", pin_pullup_conf),
-	/* SCIFA4 */
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "e6050000.pfc",
-				  "scifa4_data", "scifa4"),
-	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.4", "e6050000.pfc",
-				  "scifa4_ctrl", "scifa4"),
-	/* SDHI0 */
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
-				  "sdhi0_data4", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
-				  "sdhi0_ctrl", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
-				  "sdhi0_cd", "sdhi0"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee100000.sdhi", "e6050000.pfc",
-				  "sdhi0_wp", "sdhi0"),
-	/* SDHI2 */
-	PIN_MAP_MUX_GROUP_DEFAULT("ee140000.sdhi", "e6050000.pfc",
-				  "sdhi2_data4", "sdhi2"),
-	PIN_MAP_MUX_GROUP_DEFAULT("ee140000.sdhi", "e6050000.pfc",
-				  "sdhi2_ctrl", "sdhi2"),
-};
-
 static void __init kzm_init(void)
 {
 	sh73a0_add_standard_devices_dt();
-	pinctrl_register_mappings(kzm_pinctrl_map, ARRAY_SIZE(kzm_pinctrl_map));
 
 	/* enable SD */
 	gpio_request_one(15, GPIOF_OUT_INIT_HIGH, NULL); /* power */
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:34 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:34 +0900
Subject: [PATCH 4/4] leds: Remove leds-renesas-tpu driver
In-Reply-To: <cover.1374624997.git.horms+renesas@verge.net.au>
References: <cover.1374624997.git.horms+renesas@verge.net.au>
Message-ID: <ae3e4c277669e16093f0e71ca927cf33e7dde053.1374624997.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The driver is superseded by the generic pwm-renesas-tpu driver used with
leds-pwm.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Bryan Wu <cooloney at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/leds/Kconfig                           |  12 -
 drivers/leds/Makefile                          |   1 -
 drivers/leds/leds-renesas-tpu.c                | 337 -------------------------
 include/linux/platform_data/leds-renesas-tpu.h |  14 -
 4 files changed, 364 deletions(-)
 delete mode 100644 drivers/leds/leds-renesas-tpu.c
 delete mode 100644 include/linux/platform_data/leds-renesas-tpu.h

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index e43402d..074bcb3 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -429,18 +429,6 @@ config LEDS_ASIC3
 	  cannot be used. This driver supports hardware blinking with an on+off
 	  period from 62ms to 125s. Say Y to enable LEDs on the HP iPAQ hx4700.
 
-config LEDS_RENESAS_TPU
-	bool "LED support for Renesas TPU"
-	depends on LEDS_CLASS=y && HAVE_CLK && GPIOLIB
-	help
-	  This option enables build of the LED TPU platform driver,
-	  suitable to drive any TPU channel on newer Renesas SoCs.
-	  The driver controls the GPIO pin connected to the LED via
-	  the GPIO framework and expects the LED to be connected to
-	  a pin that can be driven in both GPIO mode and using TPU
-	  pin function. The latter to support brightness control.
-	  Brightness control is supported but hardware blinking is not.
-
 config LEDS_TCA6507
 	tristate "LED Support for TCA6507 I2C chip"
 	depends on LEDS_CLASS && I2C
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index ac28977..ae4b613 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -49,7 +49,6 @@ obj-$(CONFIG_LEDS_MC13783)		+= leds-mc13783.o
 obj-$(CONFIG_LEDS_NS2)			+= leds-ns2.o
 obj-$(CONFIG_LEDS_NETXBIG)		+= leds-netxbig.o
 obj-$(CONFIG_LEDS_ASIC3)		+= leds-asic3.o
-obj-$(CONFIG_LEDS_RENESAS_TPU)		+= leds-renesas-tpu.o
 obj-$(CONFIG_LEDS_MAX8997)		+= leds-max8997.o
 obj-$(CONFIG_LEDS_LM355x)		+= leds-lm355x.o
 obj-$(CONFIG_LEDS_BLINKM)		+= leds-blinkm.o
diff --git a/drivers/leds/leds-renesas-tpu.c b/drivers/leds/leds-renesas-tpu.c
deleted file mode 100644
index adebf49..0000000
--- a/drivers/leds/leds-renesas-tpu.c
+++ /dev/null
@@ -1,337 +0,0 @@
-/*
- * LED control using Renesas TPU
- *
- *  Copyright (C) 2011 Magnus Damm
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/spinlock.h>
-#include <linux/printk.h>
-#include <linux/ioport.h>
-#include <linux/io.h>
-#include <linux/clk.h>
-#include <linux/leds.h>
-#include <linux/platform_data/leds-renesas-tpu.h>
-#include <linux/gpio.h>
-#include <linux/err.h>
-#include <linux/slab.h>
-#include <linux/pm_runtime.h>
-#include <linux/workqueue.h>
-
-enum r_tpu_pin { R_TPU_PIN_UNUSED, R_TPU_PIN_GPIO, R_TPU_PIN_GPIO_FN };
-enum r_tpu_timer { R_TPU_TIMER_UNUSED, R_TPU_TIMER_ON };
-
-struct r_tpu_priv {
-	struct led_classdev ldev;
-	void __iomem *mapbase;
-	struct clk *clk;
-	struct platform_device *pdev;
-	enum r_tpu_pin pin_state;
-	enum r_tpu_timer timer_state;
-	unsigned long min_rate;
-	unsigned int refresh_rate;
-	struct work_struct work;
-	enum led_brightness new_brightness;
-};
-
-static DEFINE_SPINLOCK(r_tpu_lock);
-
-#define TSTR -1 /* Timer start register (shared register) */
-#define TCR  0 /* Timer control register (+0x00) */
-#define TMDR 1 /* Timer mode register (+0x04) */
-#define TIOR 2 /* Timer I/O control register (+0x08) */
-#define TIER 3 /* Timer interrupt enable register (+0x0c) */
-#define TSR  4 /* Timer status register (+0x10) */
-#define TCNT 5 /* Timer counter (+0x14) */
-#define TGRA 6 /* Timer general register A (+0x18) */
-#define TGRB 7 /* Timer general register B (+0x1c) */
-#define TGRC 8 /* Timer general register C (+0x20) */
-#define TGRD 9 /* Timer general register D (+0x24) */
-
-static inline u16 r_tpu_read(struct r_tpu_priv *p, int reg_nr)
-{
-	struct led_renesas_tpu_config *cfg = p->pdev->dev.platform_data;
-	void __iomem *base = p->mapbase;
-	unsigned long offs = reg_nr << 2;
-
-	if (reg_nr == TSTR)
-		return ioread16(base - cfg->channel_offset);
-
-	return ioread16(base + offs);
-}
-
-static inline void r_tpu_write(struct r_tpu_priv *p, int reg_nr, u16 value)
-{
-	struct led_renesas_tpu_config *cfg = p->pdev->dev.platform_data;
-	void __iomem *base = p->mapbase;
-	unsigned long offs = reg_nr << 2;
-
-	if (reg_nr == TSTR) {
-		iowrite16(value, base - cfg->channel_offset);
-		return;
-	}
-
-	iowrite16(value, base + offs);
-}
-
-static void r_tpu_start_stop_ch(struct r_tpu_priv *p, int start)
-{
-	struct led_renesas_tpu_config *cfg = p->pdev->dev.platform_data;
-	unsigned long flags;
-	u16 value;
-
-	/* start stop register shared by multiple timer channels */
-	spin_lock_irqsave(&r_tpu_lock, flags);
-	value = r_tpu_read(p, TSTR);
-
-	if (start)
-		value |= 1 << cfg->timer_bit;
-	else
-		value &= ~(1 << cfg->timer_bit);
-
-	r_tpu_write(p, TSTR, value);
-	spin_unlock_irqrestore(&r_tpu_lock, flags);
-}
-
-static int r_tpu_enable(struct r_tpu_priv *p, enum led_brightness brightness)
-{
-	struct led_renesas_tpu_config *cfg = p->pdev->dev.platform_data;
-	int prescaler[] = { 1, 4, 16, 64 };
-	int k, ret;
-	unsigned long rate, tmp;
-
-	if (p->timer_state == R_TPU_TIMER_ON)
-		return 0;
-
-	/* wake up device and enable clock */
-	pm_runtime_get_sync(&p->pdev->dev);
-	ret = clk_enable(p->clk);
-	if (ret) {
-		dev_err(&p->pdev->dev, "cannot enable clock\n");
-		return ret;
-	}
-
-	/* make sure channel is disabled */
-	r_tpu_start_stop_ch(p, 0);
-
-	/* get clock rate after enabling it */
-	rate = clk_get_rate(p->clk);
-
-	/* pick the lowest acceptable rate */
-	for (k = ARRAY_SIZE(prescaler) - 1; k >= 0; k--)
-		if ((rate / prescaler[k]) >= p->min_rate)
-			break;
-
-	if (k < 0) {
-		dev_err(&p->pdev->dev, "clock rate mismatch\n");
-		goto err0;
-	}
-	dev_dbg(&p->pdev->dev, "rate = %lu, prescaler %u\n",
-		rate, prescaler[k]);
-
-	/* clear TCNT on TGRB match, count on rising edge, set prescaler */
-	r_tpu_write(p, TCR, 0x0040 | k);
-
-	/* output 0 until TGRA, output 1 until TGRB */
-	r_tpu_write(p, TIOR, 0x0002);
-
-	rate /= prescaler[k] * p->refresh_rate;
-	r_tpu_write(p, TGRB, rate);
-	dev_dbg(&p->pdev->dev, "TRGB = 0x%04lx\n", rate);
-
-	tmp = (cfg->max_brightness - brightness) * rate;
-	r_tpu_write(p, TGRA, tmp / cfg->max_brightness);
-	dev_dbg(&p->pdev->dev, "TRGA = 0x%04lx\n", tmp / cfg->max_brightness);
-
-	/* PWM mode */
-	r_tpu_write(p, TMDR, 0x0002);
-
-	/* enable channel */
-	r_tpu_start_stop_ch(p, 1);
-
-	p->timer_state = R_TPU_TIMER_ON;
-	return 0;
- err0:
-	clk_disable(p->clk);
-	pm_runtime_put_sync(&p->pdev->dev);
-	return -ENOTSUPP;
-}
-
-static void r_tpu_disable(struct r_tpu_priv *p)
-{
-	if (p->timer_state == R_TPU_TIMER_UNUSED)
-		return;
-
-	/* disable channel */
-	r_tpu_start_stop_ch(p, 0);
-
-	/* stop clock and mark device as idle */
-	clk_disable(p->clk);
-	pm_runtime_put_sync(&p->pdev->dev);
-
-	p->timer_state = R_TPU_TIMER_UNUSED;
-}
-
-static void r_tpu_set_pin(struct r_tpu_priv *p, enum r_tpu_pin new_state,
-			  enum led_brightness brightness)
-{
-	struct led_renesas_tpu_config *cfg = p->pdev->dev.platform_data;
-
-	if (p->pin_state == new_state) {
-		if (p->pin_state == R_TPU_PIN_GPIO)
-			gpio_set_value(cfg->pin_gpio, brightness);
-		return;
-	}
-
-	if (p->pin_state == R_TPU_PIN_GPIO)
-		gpio_free(cfg->pin_gpio);
-
-	if (p->pin_state == R_TPU_PIN_GPIO_FN)
-		gpio_free(cfg->pin_gpio_fn);
-
-	if (new_state == R_TPU_PIN_GPIO)
-		gpio_request_one(cfg->pin_gpio, !!brightness ?
-				GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
-				cfg->name);
-
-	if (new_state == R_TPU_PIN_GPIO_FN)
-		gpio_request(cfg->pin_gpio_fn, cfg->name);
-
-	p->pin_state = new_state;
-}
-
-static void r_tpu_work(struct work_struct *work)
-{
-	struct r_tpu_priv *p = container_of(work, struct r_tpu_priv, work);
-	enum led_brightness brightness = p->new_brightness;
-
-	r_tpu_disable(p);
-
-	/* off and maximum are handled as GPIO pins, in between PWM */
-	if ((brightness == 0) || (brightness == p->ldev.max_brightness))
-		r_tpu_set_pin(p, R_TPU_PIN_GPIO, brightness);
-	else {
-		r_tpu_set_pin(p, R_TPU_PIN_GPIO_FN, 0);
-		r_tpu_enable(p, brightness);
-	}
-}
-
-static void r_tpu_set_brightness(struct led_classdev *ldev,
-				 enum led_brightness brightness)
-{
-	struct r_tpu_priv *p = container_of(ldev, struct r_tpu_priv, ldev);
-	p->new_brightness = brightness;
-	schedule_work(&p->work);
-}
-
-static int r_tpu_probe(struct platform_device *pdev)
-{
-	struct led_renesas_tpu_config *cfg = pdev->dev.platform_data;
-	struct r_tpu_priv *p;
-	struct resource *res;
-	int ret;
-
-	if (!cfg) {
-		dev_err(&pdev->dev, "missing platform data\n");
-		return -ENODEV;
-	}
-
-	p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
-	if (p == NULL) {
-		dev_err(&pdev->dev, "failed to allocate driver data\n");
-		return -ENOMEM;
-	}
-
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (!res) {
-		dev_err(&pdev->dev, "failed to get I/O memory\n");
-		return -ENXIO;
-	}
-
-	/* map memory, let mapbase point to our channel */
-	p->mapbase = devm_ioremap_nocache(&pdev->dev, res->start,
-					resource_size(res));
-	if (p->mapbase == NULL) {
-		dev_err(&pdev->dev, "failed to remap I/O memory\n");
-		return -ENXIO;
-	}
-
-	/* get hold of clock */
-	p->clk = devm_clk_get(&pdev->dev, NULL);
-	if (IS_ERR(p->clk)) {
-		dev_err(&pdev->dev, "cannot get clock\n");
-		return PTR_ERR(p->clk);
-	}
-
-	p->pdev = pdev;
-	p->pin_state = R_TPU_PIN_UNUSED;
-	p->timer_state = R_TPU_TIMER_UNUSED;
-	p->refresh_rate = cfg->refresh_rate ? cfg->refresh_rate : 100;
-	r_tpu_set_pin(p, R_TPU_PIN_GPIO, LED_OFF);
-	platform_set_drvdata(pdev, p);
-
-	INIT_WORK(&p->work, r_tpu_work);
-
-	p->ldev.name = cfg->name;
-	p->ldev.brightness = LED_OFF;
-	p->ldev.max_brightness = cfg->max_brightness;
-	p->ldev.brightness_set = r_tpu_set_brightness;
-	p->ldev.flags |= LED_CORE_SUSPENDRESUME;
-	ret = led_classdev_register(&pdev->dev, &p->ldev);
-	if (ret < 0)
-		goto err0;
-
-	/* max_brightness may be updated by the LED core code */
-	p->min_rate = p->ldev.max_brightness * p->refresh_rate;
-
-	pm_runtime_enable(&pdev->dev);
-	return 0;
-
- err0:
-	r_tpu_set_pin(p, R_TPU_PIN_UNUSED, LED_OFF);
-	return ret;
-}
-
-static int r_tpu_remove(struct platform_device *pdev)
-{
-	struct r_tpu_priv *p = platform_get_drvdata(pdev);
-
-	r_tpu_set_brightness(&p->ldev, LED_OFF);
-	led_classdev_unregister(&p->ldev);
-	cancel_work_sync(&p->work);
-	r_tpu_disable(p);
-	r_tpu_set_pin(p, R_TPU_PIN_UNUSED, LED_OFF);
-
-	pm_runtime_disable(&pdev->dev);
-
-	return 0;
-}
-
-static struct platform_driver r_tpu_device_driver = {
-	.probe		= r_tpu_probe,
-	.remove		= r_tpu_remove,
-	.driver		= {
-		.name	= "leds-renesas-tpu",
-	}
-};
-
-module_platform_driver(r_tpu_device_driver);
-
-MODULE_AUTHOR("Magnus Damm");
-MODULE_DESCRIPTION("Renesas TPU LED Driver");
-MODULE_LICENSE("GPL v2");
diff --git a/include/linux/platform_data/leds-renesas-tpu.h b/include/linux/platform_data/leds-renesas-tpu.h
deleted file mode 100644
index 0553870..0000000
--- a/include/linux/platform_data/leds-renesas-tpu.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef __LEDS_RENESAS_TPU_H__
-#define __LEDS_RENESAS_TPU_H__
-
-struct led_renesas_tpu_config {
-	char *name;
-	unsigned pin_gpio_fn;
-	unsigned pin_gpio;
-	unsigned int channel_offset;
-	unsigned int timer_bit;
-	unsigned int max_brightness;
-	unsigned int refresh_rate;
-};
-
-#endif /* __LEDS_RENESAS_TPU_H__ */
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:20 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:20 +0900
Subject: [GIT 0/4] Renesas TPU PWM support for v3.12
Message-ID: <cover.1374624997.git.horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

please consider this pull request, which adds support for
the renesas TPU PWM unit, for v3.12.

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-tpu-pwm-for-v3.12

for you to fetch changes up to ae3e4c277669e16093f0e71ca927cf33e7dde053:

  leds: Remove leds-renesas-tpu driver (2013-07-22 10:16:54 +0900)

----------------------------------------------------------------
Renesas TPU PWM support for v3.12

Add Renesas TPU PWM unit support

----------------------------------------------------------------
Laurent Pinchart (4):
      ARM: shmobile: armadillo800eva: Add backlight support
      ARM: shmobile: kota2: Use leds-pwm + pwm-rmob
      ARM: shmobile: sh73a0: Remove all GPIOs
      leds: Remove leds-renesas-tpu driver

 arch/arm/mach-shmobile/board-armadillo800eva.c |  54 +++-
 arch/arm/mach-shmobile/board-kota2.c           | 169 ++++++-----
 arch/arm/mach-shmobile/clock-sh73a0.c          |  12 +-
 arch/arm/mach-shmobile/include/mach/sh73a0.h   | 373 +------------------------
 drivers/leds/Kconfig                           |  12 -
 drivers/leds/Makefile                          |   1 -
 drivers/leds/leds-renesas-tpu.c                | 337 ----------------------
 include/linux/platform_data/leds-renesas-tpu.h |  14 -
 8 files changed, 143 insertions(+), 829 deletions(-)
 delete mode 100644 drivers/leds/leds-renesas-tpu.c
 delete mode 100644 include/linux/platform_data/leds-renesas-tpu.h


From horms+renesas at verge.net.au  Tue Jul 23 20:34:32 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:32 +0900
Subject: [PATCH 2/4] ARM: shmobile: kota2: Use leds-pwm + pwm-rmob
In-Reply-To: <cover.1374624997.git.horms+renesas@verge.net.au>
References: <cover.1374624997.git.horms+renesas@verge.net.au>
Message-ID: <b885966f61b349baccf5c8c266f03407cfcea5ea.1374624997.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Instead of using the LED-specific TPU PWM driver, switch to the generic
TPU PWM driver with leds-pwm.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-kota2.c  | 169 +++++++++++++++++-----------------
 arch/arm/mach-shmobile/clock-sh73a0.c |  12 ++-
 2 files changed, 90 insertions(+), 91 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-kota2.c b/arch/arm/mach-shmobile/board-kota2.c
index ef5ca0e..6af20d9 100644
--- a/arch/arm/mach-shmobile/board-kota2.c
+++ b/arch/arm/mach-shmobile/board-kota2.c
@@ -26,6 +26,7 @@
 #include <linux/irq.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/pinctrl/pinconf-generic.h>
+#include <linux/platform_data/pwm-renesas-tpu.h>
 #include <linux/platform_device.h>
 #include <linux/delay.h>
 #include <linux/io.h>
@@ -37,8 +38,8 @@
 #include <linux/input/sh_keysc.h>
 #include <linux/gpio_keys.h>
 #include <linux/leds.h>
+#include <linux/leds_pwm.h>
 #include <linux/irqchip/arm-gic.h>
-#include <linux/platform_data/leds-renesas-tpu.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/sh_mmcif.h>
 #include <linux/mfd/tmio.h>
@@ -186,116 +187,100 @@ static struct platform_device gpio_leds_device = {
 };
 
 /* TPU LED */
-static struct led_renesas_tpu_config led_renesas_tpu12_pdata = {
-	.name		= "V2513",
-	.pin_gpio_fn	= GPIO_FN_TPU1TO2,
-	.pin_gpio	= 153,
-	.channel_offset = 0x90,
-	.timer_bit = 2,
-	.max_brightness = 1000,
-};
-
-static struct resource tpu12_resources[] = {
+static struct resource tpu1_pwm_resources[] = {
 	[0] = {
-		.name	= "TPU12",
-		.start	= 0xe6610090,
-		.end	= 0xe66100b5,
+		.start	= 0xe6610000,
+		.end	= 0xe66100ff,
 		.flags	= IORESOURCE_MEM,
 	},
 };
 
-static struct platform_device leds_tpu12_device = {
-	.name = "leds-renesas-tpu",
-	.id = 12,
-	.dev = {
-		.platform_data  = &led_renesas_tpu12_pdata,
-	},
-	.num_resources	= ARRAY_SIZE(tpu12_resources),
-	.resource	= tpu12_resources,
+static struct platform_device tpu1_pwm_device = {
+	.name = "renesas-tpu-pwm",
+	.id = 1,
+	.num_resources	= ARRAY_SIZE(tpu1_pwm_resources),
+	.resource	= tpu1_pwm_resources,
 };
 
-static struct led_renesas_tpu_config led_renesas_tpu41_pdata = {
-	.name		= "V2514",
-	.pin_gpio_fn	= GPIO_FN_TPU4TO1,
-	.pin_gpio	= 199,
-	.channel_offset = 0x50,
-	.timer_bit = 1,
-	.max_brightness = 1000,
-};
-
-static struct resource tpu41_resources[] = {
+static struct resource tpu2_pwm_resources[] = {
 	[0] = {
-		.name	= "TPU41",
-		.start	= 0xe6640050,
-		.end	= 0xe6640075,
+		.start	= 0xe6620000,
+		.end	= 0xe66200ff,
 		.flags	= IORESOURCE_MEM,
 	},
 };
 
-static struct platform_device leds_tpu41_device = {
-	.name = "leds-renesas-tpu",
-	.id = 41,
-	.dev = {
-		.platform_data  = &led_renesas_tpu41_pdata,
+static struct platform_device tpu2_pwm_device = {
+	.name = "renesas-tpu-pwm",
+	.id = 2,
+	.num_resources	= ARRAY_SIZE(tpu2_pwm_resources),
+	.resource	= tpu2_pwm_resources,
+};
+
+static struct resource tpu3_pwm_resources[] = {
+	[0] = {
+		.start	= 0xe6630000,
+		.end	= 0xe66300ff,
+		.flags	= IORESOURCE_MEM,
 	},
-	.num_resources	= ARRAY_SIZE(tpu41_resources),
-	.resource	= tpu41_resources,
 };
 
-static struct led_renesas_tpu_config led_renesas_tpu21_pdata = {
-	.name		= "V2515",
-	.pin_gpio_fn	= GPIO_FN_TPU2TO1,
-	.pin_gpio	= 197,
-	.channel_offset = 0x50,
-	.timer_bit = 1,
-	.max_brightness = 1000,
+static struct platform_device tpu3_pwm_device = {
+	.name = "renesas-tpu-pwm",
+	.id = 3,
+	.num_resources	= ARRAY_SIZE(tpu3_pwm_resources),
+	.resource	= tpu3_pwm_resources,
 };
 
-static struct resource tpu21_resources[] = {
+static struct resource tpu4_pwm_resources[] = {
 	[0] = {
-		.name	= "TPU21",
-		.start	= 0xe6620050,
-		.end	= 0xe6620075,
+		.start	= 0xe6640000,
+		.end	= 0xe66400ff,
 		.flags	= IORESOURCE_MEM,
 	},
 };
 
-static struct platform_device leds_tpu21_device = {
-	.name = "leds-renesas-tpu",
-	.id = 21,
-	.dev = {
-		.platform_data  = &led_renesas_tpu21_pdata,
+static struct platform_device tpu4_pwm_device = {
+	.name = "renesas-tpu-pwm",
+	.id = 4,
+	.num_resources	= ARRAY_SIZE(tpu4_pwm_resources),
+	.resource	= tpu4_pwm_resources,
+};
+
+static struct pwm_lookup pwm_lookup[] = {
+	PWM_LOOKUP("renesas-tpu-pwm.1", 2, "leds-pwm.0", "V2513"),
+	PWM_LOOKUP("renesas-tpu-pwm.2", 1, "leds-pwm.0", "V2515"),
+	PWM_LOOKUP("renesas-tpu-pwm.3", 0, "leds-pwm.0", "KEYLED"),
+	PWM_LOOKUP("renesas-tpu-pwm.4", 1, "leds-pwm.0", "V2514"),
+};
+
+static struct led_pwm tpu_pwm_leds[] = {
+	{
+		.name		= "V2513",
+		.max_brightness	= 1000,
+	}, {
+		.name		= "V2515",
+		.max_brightness	= 1000,
+	}, {
+		.name		= "KEYLED",
+		.max_brightness	= 1000,
+	}, {
+		.name		= "V2514",
+		.max_brightness	= 1000,
 	},
-	.num_resources	= ARRAY_SIZE(tpu21_resources),
-	.resource	= tpu21_resources,
 };
 
-static struct led_renesas_tpu_config led_renesas_tpu30_pdata = {
-	.name		= "KEYLED",
-	.pin_gpio_fn	= GPIO_FN_TPU3TO0,
-	.pin_gpio	= 163,
-	.channel_offset = 0x10,
-	.timer_bit = 0,
-	.max_brightness = 1000,
+static struct led_pwm_platform_data leds_pwm_pdata = {
+	.num_leds = ARRAY_SIZE(tpu_pwm_leds),
+	.leds = tpu_pwm_leds,
 };
 
-static struct resource tpu30_resources[] = {
-	[0] = {
-		.name	= "TPU30",
-		.start	= 0xe6630010,
-		.end	= 0xe6630035,
-		.flags	= IORESOURCE_MEM,
-	},
-};
-
-static struct platform_device leds_tpu30_device = {
-	.name = "leds-renesas-tpu",
-	.id = 30,
+static struct platform_device leds_pwm_device = {
+	.name = "leds-pwm",
+	.id = 0,
 	.dev = {
-		.platform_data  = &led_renesas_tpu30_pdata,
+		.platform_data = &leds_pwm_pdata,
 	},
-	.num_resources	= ARRAY_SIZE(tpu30_resources),
-	.resource	= tpu30_resources,
 };
 
 /* Fixed 1.8V regulator to be used by MMCIF */
@@ -426,10 +411,11 @@ static struct platform_device *kota2_devices[] __initdata = {
 	&keysc_device,
 	&gpio_keys_device,
 	&gpio_leds_device,
-	&leds_tpu12_device,
-	&leds_tpu41_device,
-	&leds_tpu21_device,
-	&leds_tpu30_device,
+	&tpu1_pwm_device,
+	&tpu2_pwm_device,
+	&tpu3_pwm_device,
+	&tpu4_pwm_device,
+	&leds_pwm_device,
 	&mmcif_device,
 	&sdhi0_device,
 	&sdhi1_device,
@@ -512,6 +498,15 @@ static const struct pinctrl_map kota2_pinctrl_map[] = {
 				  "bsc_cs5_a", "bsc"),
 	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x.0", "pfc-sh73a0",
 				  "bsc_we0", "bsc"),
+	/* TPU */
+	PIN_MAP_MUX_GROUP_DEFAULT("renesas-tpu-pwm.1", "pfc-sh73a0",
+				  "tpu1_to2", "tpu1"),
+	PIN_MAP_MUX_GROUP_DEFAULT("renesas-tpu-pwm.2", "pfc-sh73a0",
+				  "tpu2_to1", "tpu2"),
+	PIN_MAP_MUX_GROUP_DEFAULT("renesas-tpu-pwm.3", "pfc-sh73a0",
+				  "tpu3_to0", "tpu3"),
+	PIN_MAP_MUX_GROUP_DEFAULT("renesas-tpu-pwm.4", "pfc-sh73a0",
+				  "tpu4_to1", "tpu4"),
 };
 
 static void __init kota2_init(void)
@@ -524,6 +519,8 @@ static void __init kota2_init(void)
 
 	pinctrl_register_mappings(kota2_pinctrl_map,
 				  ARRAY_SIZE(kota2_pinctrl_map));
+	pwm_add_table(pwm_lookup, ARRAY_SIZE(pwm_lookup));
+
 	sh73a0_pinmux_init();
 
 	/* SMSC911X */
diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c b/arch/arm/mach-shmobile/clock-sh73a0.c
index d9fd033..1942eae 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -555,7 +555,7 @@ enum { MSTP001,
 	MSTP207, MSTP206, MSTP204, MSTP203, MSTP202, MSTP201, MSTP200,
 	MSTP331, MSTP329, MSTP328, MSTP325, MSTP323, MSTP322,
 	MSTP314, MSTP313, MSTP312, MSTP311,
-	MSTP303, MSTP302, MSTP301, MSTP300,
+	MSTP304, MSTP303, MSTP302, MSTP301, MSTP300,
 	MSTP411, MSTP410, MSTP403,
 	MSTP_NR };
 
@@ -593,6 +593,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP313] = MSTP(&div6_clks[DIV6_SDHI1], SMSTPCR3, 13, 0), /* SDHI1 */
 	[MSTP312] = MSTP(&div4_clks[DIV4_HP], SMSTPCR3, 12, 0), /* MMCIF0 */
 	[MSTP311] = MSTP(&div6_clks[DIV6_SDHI2], SMSTPCR3, 11, 0), /* SDHI2 */
+	[MSTP304] = MSTP(&main_div2_clk, SMSTPCR3, 4, 0), /* TPU0 */
 	[MSTP303] = MSTP(&main_div2_clk, SMSTPCR3, 3, 0), /* TPU1 */
 	[MSTP302] = MSTP(&main_div2_clk, SMSTPCR3, 2, 0), /* TPU2 */
 	[MSTP301] = MSTP(&main_div2_clk, SMSTPCR3, 1, 0), /* TPU3 */
@@ -669,10 +670,11 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("e6bd0000.mmcif", &mstp_clks[MSTP312]), /* MMCIF0 */
 	CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP311]), /* SDHI2 */
 	CLKDEV_DEV_ID("ee140000.sdhi", &mstp_clks[MSTP311]), /* SDHI2 */
-	CLKDEV_DEV_ID("leds-renesas-tpu.12", &mstp_clks[MSTP303]), /* TPU1 */
-	CLKDEV_DEV_ID("leds-renesas-tpu.21", &mstp_clks[MSTP302]), /* TPU2 */
-	CLKDEV_DEV_ID("leds-renesas-tpu.30", &mstp_clks[MSTP301]), /* TPU3 */
-	CLKDEV_DEV_ID("leds-renesas-tpu.41", &mstp_clks[MSTP300]), /* TPU4 */
+	CLKDEV_DEV_ID("renesas-tpu-pwm.0", &mstp_clks[MSTP304]), /* TPU0 */
+	CLKDEV_DEV_ID("renesas-tpu-pwm.1", &mstp_clks[MSTP303]), /* TPU1 */
+	CLKDEV_DEV_ID("renesas-tpu-pwm.2", &mstp_clks[MSTP302]), /* TPU2 */
+	CLKDEV_DEV_ID("renesas-tpu-pwm.3", &mstp_clks[MSTP301]), /* TPU3 */
+	CLKDEV_DEV_ID("renesas-tpu-pwm.4", &mstp_clks[MSTP300]), /* TPU4 */
 	CLKDEV_DEV_ID("i2c-sh_mobile.3", &mstp_clks[MSTP411]), /* I2C3 */
 	CLKDEV_DEV_ID("e6826000.i2c", &mstp_clks[MSTP411]), /* I2C3 */
 	CLKDEV_DEV_ID("i2c-sh_mobile.4", &mstp_clks[MSTP410]), /* I2C4 */
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:33 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:33 +0900
Subject: [PATCH 3/4] ARM: shmobile: sh73a0: Remove all GPIOs
In-Reply-To: <cover.1374624997.git.horms+renesas@verge.net.au>
References: <cover.1374624997.git.horms+renesas@verge.net.au>
Message-ID: <e6909dcedb55b8790f5b79599987d84eea5888b1.1374624997.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Function GPIOs are not used anymore, and all code use the GPIO numbers
directly. Remove the GPIOs enumeration.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/sh73a0.h | 373 +--------------------------
 1 file changed, 1 insertion(+), 372 deletions(-)

diff --git a/arch/arm/mach-shmobile/include/mach/sh73a0.h b/arch/arm/mach-shmobile/include/mach/sh73a0.h
index eb7a432..680dc5f 100644
--- a/arch/arm/mach-shmobile/include/mach/sh73a0.h
+++ b/arch/arm/mach-shmobile/include/mach/sh73a0.h
@@ -1,378 +1,7 @@
 #ifndef __ASM_SH73A0_H__
 #define __ASM_SH73A0_H__
 
-/* Pin Function Controller:
- * GPIO_FN_xx - GPIO used to select pin function and MSEL switch
- * GPIO_PORTxx - GPIO mapped to real I/O pin on CPU
- */
-enum {
-	/* Hardware manual Table 25-1 (GPIO) */
-	GPIO_PORT0, GPIO_PORT1, GPIO_PORT2, GPIO_PORT3, GPIO_PORT4,
-	GPIO_PORT5, GPIO_PORT6, GPIO_PORT7, GPIO_PORT8, GPIO_PORT9,
-
-	GPIO_PORT10, GPIO_PORT11, GPIO_PORT12, GPIO_PORT13, GPIO_PORT14,
-	GPIO_PORT15, GPIO_PORT16, GPIO_PORT17, GPIO_PORT18, GPIO_PORT19,
-
-	GPIO_PORT20, GPIO_PORT21, GPIO_PORT22, GPIO_PORT23, GPIO_PORT24,
-	GPIO_PORT25, GPIO_PORT26, GPIO_PORT27, GPIO_PORT28, GPIO_PORT29,
-
-	GPIO_PORT30, GPIO_PORT31, GPIO_PORT32, GPIO_PORT33, GPIO_PORT34,
-	GPIO_PORT35, GPIO_PORT36, GPIO_PORT37, GPIO_PORT38, GPIO_PORT39,
-
-	GPIO_PORT40, GPIO_PORT41, GPIO_PORT42, GPIO_PORT43, GPIO_PORT44,
-	GPIO_PORT45, GPIO_PORT46, GPIO_PORT47, GPIO_PORT48, GPIO_PORT49,
-
-	GPIO_PORT50, GPIO_PORT51, GPIO_PORT52, GPIO_PORT53, GPIO_PORT54,
-	GPIO_PORT55, GPIO_PORT56, GPIO_PORT57, GPIO_PORT58, GPIO_PORT59,
-
-	GPIO_PORT60, GPIO_PORT61, GPIO_PORT62, GPIO_PORT63, GPIO_PORT64,
-	GPIO_PORT65, GPIO_PORT66, GPIO_PORT67, GPIO_PORT68, GPIO_PORT69,
-
-	GPIO_PORT70, GPIO_PORT71, GPIO_PORT72, GPIO_PORT73, GPIO_PORT74,
-	GPIO_PORT75, GPIO_PORT76, GPIO_PORT77, GPIO_PORT78, GPIO_PORT79,
-
-	GPIO_PORT80, GPIO_PORT81, GPIO_PORT82, GPIO_PORT83, GPIO_PORT84,
-	GPIO_PORT85, GPIO_PORT86, GPIO_PORT87, GPIO_PORT88, GPIO_PORT89,
-
-	GPIO_PORT90, GPIO_PORT91, GPIO_PORT92, GPIO_PORT93, GPIO_PORT94,
-	GPIO_PORT95, GPIO_PORT96, GPIO_PORT97, GPIO_PORT98, GPIO_PORT99,
-
-	GPIO_PORT100, GPIO_PORT101, GPIO_PORT102, GPIO_PORT103, GPIO_PORT104,
-	GPIO_PORT105, GPIO_PORT106, GPIO_PORT107, GPIO_PORT108, GPIO_PORT109,
-
-	GPIO_PORT110, GPIO_PORT111, GPIO_PORT112, GPIO_PORT113, GPIO_PORT114,
-	GPIO_PORT115, GPIO_PORT116, GPIO_PORT117, GPIO_PORT118,
-
-	GPIO_PORT128, GPIO_PORT129,
-
-	GPIO_PORT130, GPIO_PORT131, GPIO_PORT132, GPIO_PORT133, GPIO_PORT134,
-	GPIO_PORT135, GPIO_PORT136, GPIO_PORT137, GPIO_PORT138, GPIO_PORT139,
-
-	GPIO_PORT140, GPIO_PORT141, GPIO_PORT142, GPIO_PORT143, GPIO_PORT144,
-	GPIO_PORT145, GPIO_PORT146, GPIO_PORT147, GPIO_PORT148, GPIO_PORT149,
-
-	GPIO_PORT150, GPIO_PORT151, GPIO_PORT152, GPIO_PORT153, GPIO_PORT154,
-	GPIO_PORT155, GPIO_PORT156, GPIO_PORT157, GPIO_PORT158, GPIO_PORT159,
-
-	GPIO_PORT160, GPIO_PORT161, GPIO_PORT162, GPIO_PORT163, GPIO_PORT164,
-
-	GPIO_PORT192, GPIO_PORT193, GPIO_PORT194,
-	GPIO_PORT195, GPIO_PORT196, GPIO_PORT197, GPIO_PORT198, GPIO_PORT199,
-
-	GPIO_PORT200, GPIO_PORT201, GPIO_PORT202, GPIO_PORT203, GPIO_PORT204,
-	GPIO_PORT205, GPIO_PORT206, GPIO_PORT207, GPIO_PORT208, GPIO_PORT209,
-
-	GPIO_PORT210, GPIO_PORT211, GPIO_PORT212, GPIO_PORT213, GPIO_PORT214,
-	GPIO_PORT215, GPIO_PORT216, GPIO_PORT217, GPIO_PORT218, GPIO_PORT219,
-
-	GPIO_PORT220, GPIO_PORT221, GPIO_PORT222, GPIO_PORT223, GPIO_PORT224,
-	GPIO_PORT225, GPIO_PORT226, GPIO_PORT227, GPIO_PORT228, GPIO_PORT229,
-
-	GPIO_PORT230, GPIO_PORT231, GPIO_PORT232, GPIO_PORT233, GPIO_PORT234,
-	GPIO_PORT235, GPIO_PORT236, GPIO_PORT237, GPIO_PORT238, GPIO_PORT239,
-
-	GPIO_PORT240, GPIO_PORT241, GPIO_PORT242, GPIO_PORT243, GPIO_PORT244,
-	GPIO_PORT245, GPIO_PORT246, GPIO_PORT247, GPIO_PORT248, GPIO_PORT249,
-
-	GPIO_PORT250, GPIO_PORT251, GPIO_PORT252, GPIO_PORT253, GPIO_PORT254,
-	GPIO_PORT255, GPIO_PORT256, GPIO_PORT257, GPIO_PORT258, GPIO_PORT259,
-
-	GPIO_PORT260, GPIO_PORT261, GPIO_PORT262, GPIO_PORT263, GPIO_PORT264,
-	GPIO_PORT265, GPIO_PORT266, GPIO_PORT267, GPIO_PORT268, GPIO_PORT269,
-
-	GPIO_PORT270, GPIO_PORT271, GPIO_PORT272, GPIO_PORT273, GPIO_PORT274,
-	GPIO_PORT275, GPIO_PORT276, GPIO_PORT277, GPIO_PORT278, GPIO_PORT279,
-
-	GPIO_PORT280, GPIO_PORT281, GPIO_PORT282,
-
-	GPIO_PORT288, GPIO_PORT289,
-
-	GPIO_PORT290, GPIO_PORT291, GPIO_PORT292, GPIO_PORT293, GPIO_PORT294,
-	GPIO_PORT295, GPIO_PORT296, GPIO_PORT297, GPIO_PORT298, GPIO_PORT299,
-
-	GPIO_PORT300, GPIO_PORT301, GPIO_PORT302, GPIO_PORT303, GPIO_PORT304,
-	GPIO_PORT305, GPIO_PORT306, GPIO_PORT307, GPIO_PORT308, GPIO_PORT309,
-
-	/* Table 25-1 (Function 0-7) */
-	GPIO_FN_GPI0 = 310,
-	GPIO_FN_GPI1,
-	GPIO_FN_GPI2,
-	GPIO_FN_GPI3,
-	GPIO_FN_GPI4,
-	GPIO_FN_GPI5,
-	GPIO_FN_GPI6,
-	GPIO_FN_GPI7,
-	GPIO_FN_GPO7, GPIO_FN_MFG0_OUT2,
-	GPIO_FN_GPO6, GPIO_FN_MFG1_OUT2,
-	GPIO_FN_GPO5,
-	GPIO_FN_PORT16_VIO_CKOR,
-	GPIO_FN_PORT19_VIO_CKO2,
-	GPIO_FN_GPO0,
-	GPIO_FN_GPO1,
-	GPIO_FN_GPO2, GPIO_FN_STATUS0,
-	GPIO_FN_GPO3, GPIO_FN_STATUS1,
-	GPIO_FN_GPO4, GPIO_FN_STATUS2,
-	GPIO_FN_VINT,
-	GPIO_FN_TCKON,
-	GPIO_FN_XDVFS1,
-	GPIO_FN_MFG0_OUT1, GPIO_FN_PORT27_IROUT,
-	GPIO_FN_XDVFS2,
-	GPIO_FN_PORT28_TPU1TO1,
-	GPIO_FN_SIM_RST, GPIO_FN_PORT29_TPU1TO1,
-	GPIO_FN_SIM_CLK, GPIO_FN_PORT30_VIO_CKOR,
-	GPIO_FN_SIM_D, GPIO_FN_PORT31_IROUT,
-	GPIO_FN_XWUP,
-	GPIO_FN_VACK,
-	GPIO_FN_XTAL1L,
-	GPIO_FN_PORT49_IROUT,
-	GPIO_FN_BBIF2_TSYNC2, GPIO_FN_TPU2TO2,
-
-	GPIO_FN_BBIF2_TSCK2, GPIO_FN_TPU2TO3,
-	GPIO_FN_BBIF2_TXD2,
-	GPIO_FN_TPU3TO3,
-	GPIO_FN_TPU3TO2,
-	GPIO_FN_TPU0TO0,
-	GPIO_FN_A0, GPIO_FN_BS_,
-	GPIO_FN_A12, GPIO_FN_TPU4TO2,
-	GPIO_FN_A13, GPIO_FN_TPU0TO1,
-	GPIO_FN_A14,
-	GPIO_FN_A15,
-	GPIO_FN_A16, GPIO_FN_MSIOF0_SS1,
-	GPIO_FN_A17, GPIO_FN_MSIOF0_TSYNC,
-	GPIO_FN_A18, GPIO_FN_MSIOF0_TSCK,
-	GPIO_FN_A19, GPIO_FN_MSIOF0_TXD,
-	GPIO_FN_A20, GPIO_FN_MSIOF0_RSCK,
-	GPIO_FN_A21, GPIO_FN_MSIOF0_RSYNC,
-	GPIO_FN_A22, GPIO_FN_MSIOF0_MCK0,
-	GPIO_FN_A23, GPIO_FN_MSIOF0_MCK1,
-	GPIO_FN_A24, GPIO_FN_MSIOF0_RXD,
-	GPIO_FN_A25, GPIO_FN_MSIOF0_SS2,
-	GPIO_FN_A26,
-	GPIO_FN_FCE1_,
-	GPIO_FN_DACK0,
-	GPIO_FN_FCE0_,
-	GPIO_FN_WAIT_, GPIO_FN_DREQ0,
-	GPIO_FN_FRB,
-	GPIO_FN_CKO,
-	GPIO_FN_NBRSTOUT_,
-	GPIO_FN_NBRST_,
-	GPIO_FN_BBIF2_TXD,
-	GPIO_FN_BBIF2_RXD,
-	GPIO_FN_BBIF2_SYNC,
-	GPIO_FN_BBIF2_SCK,
-	GPIO_FN_MFG3_IN2,
-	GPIO_FN_MFG3_IN1,
-	GPIO_FN_BBIF1_SS2, GPIO_FN_MFG3_OUT1,
-	GPIO_FN_HSI_RX_DATA, GPIO_FN_BBIF1_RXD,
-	GPIO_FN_HSI_TX_WAKE, GPIO_FN_BBIF1_TSCK,
-	GPIO_FN_HSI_TX_DATA, GPIO_FN_BBIF1_TSYNC,
-	GPIO_FN_HSI_TX_READY, GPIO_FN_BBIF1_TXD,
-	GPIO_FN_HSI_RX_READY, GPIO_FN_BBIF1_RSCK,
-	GPIO_FN_HSI_RX_WAKE, GPIO_FN_BBIF1_RSYNC,
-	GPIO_FN_HSI_RX_FLAG, GPIO_FN_BBIF1_SS1, GPIO_FN_BBIF1_FLOW,
-	GPIO_FN_HSI_TX_FLAG,
-	GPIO_FN_VIO_VD, GPIO_FN_VIO2_VD,
-
-	GPIO_FN_VIO_HD,
-	GPIO_FN_VIO2_HD,
-	GPIO_FN_VIO_D0, GPIO_FN_PORT130_MSIOF2_RXD,
-	GPIO_FN_VIO_D1, GPIO_FN_PORT131_MSIOF2_SS1,
-	GPIO_FN_VIO_D2, GPIO_FN_PORT132_MSIOF2_SS2,
-	GPIO_FN_VIO_D3, GPIO_FN_MSIOF2_TSYNC,
-	GPIO_FN_VIO_D4, GPIO_FN_MSIOF2_TXD,
-	GPIO_FN_VIO_D5, GPIO_FN_MSIOF2_TSCK,
-	GPIO_FN_VIO_D6,
-	GPIO_FN_VIO_D7,
-	GPIO_FN_VIO_D8, GPIO_FN_VIO2_D0,
-	GPIO_FN_VIO_D9, GPIO_FN_VIO2_D1,
-	GPIO_FN_VIO_D10, GPIO_FN_TPU0TO2, GPIO_FN_VIO2_D2,
-	GPIO_FN_VIO_D11, GPIO_FN_TPU0TO3, GPIO_FN_VIO2_D3,
-	GPIO_FN_VIO_D12, GPIO_FN_VIO2_D4,
-	GPIO_FN_VIO_D13,
-	GPIO_FN_VIO2_D5,
-	GPIO_FN_VIO_D14, GPIO_FN_VIO2_D6,
-	GPIO_FN_VIO_D15, GPIO_FN_TPU1TO3,
-	GPIO_FN_VIO2_D7,
-	GPIO_FN_VIO_CLK,
-	GPIO_FN_VIO2_CLK,
-	GPIO_FN_VIO_FIELD, GPIO_FN_VIO2_FIELD,
-	GPIO_FN_VIO_CKO,
-	GPIO_FN_A27, GPIO_FN_MFG0_IN1,
-	GPIO_FN_MFG0_IN2,
-	GPIO_FN_TS_SPSYNC3, GPIO_FN_MSIOF2_RSCK,
-	GPIO_FN_TS_SDAT3, GPIO_FN_MSIOF2_RSYNC,
-	GPIO_FN_TPU1TO2, GPIO_FN_TS_SDEN3, GPIO_FN_PORT153_MSIOF2_SS1,
-	GPIO_FN_MSIOF2_MCK0,
-	GPIO_FN_MSIOF2_MCK1,
-	GPIO_FN_PORT156_MSIOF2_SS2,
-	GPIO_FN_PORT157_MSIOF2_RXD,
-	GPIO_FN_DINT_, GPIO_FN_TS_SCK3,
-	GPIO_FN_NMI,
-	GPIO_FN_TPU3TO0,
-	GPIO_FN_BBIF2_TSYNC1,
-	GPIO_FN_BBIF2_TSCK1,
-	GPIO_FN_BBIF2_TXD1,
-	GPIO_FN_MFG2_OUT2,
-	GPIO_FN_TPU2TO1,
-	GPIO_FN_TPU4TO1, GPIO_FN_MFG4_OUT2,
-	GPIO_FN_D16,
-	GPIO_FN_D17,
-	GPIO_FN_D18,
-	GPIO_FN_D19,
-	GPIO_FN_D20,
-	GPIO_FN_D21,
-	GPIO_FN_D22,
-	GPIO_FN_PORT207_MSIOF0L_SS1, GPIO_FN_D23,
-	GPIO_FN_PORT208_MSIOF0L_SS2, GPIO_FN_D24,
-	GPIO_FN_D25,
-	GPIO_FN_DREQ2, GPIO_FN_PORT210_MSIOF0L_SS1, GPIO_FN_D26,
-	GPIO_FN_PORT211_MSIOF0L_SS2, GPIO_FN_D27,
-	GPIO_FN_TS_SPSYNC1, GPIO_FN_MSIOF0L_MCK0, GPIO_FN_D28,
-	GPIO_FN_TS_SDAT1, GPIO_FN_MSIOF0L_MCK1, GPIO_FN_D29,
-	GPIO_FN_TS_SDEN1, GPIO_FN_MSIOF0L_RSCK, GPIO_FN_D30,
-	GPIO_FN_TS_SCK1, GPIO_FN_MSIOF0L_RSYNC, GPIO_FN_D31,
-	GPIO_FN_DACK2,
-	GPIO_FN_MSIOF0L_TSYNC, GPIO_FN_VIO2_FIELD3,
-	GPIO_FN_DACK3,
-	GPIO_FN_PORT218_VIO_CKOR,
-	GPIO_FN_DREQ3, GPIO_FN_MSIOF0L_TSCK, GPIO_FN_VIO2_CLK3, \
-	GPIO_FN_DREQ1,
-	GPIO_FN_PWEN, GPIO_FN_MSIOF0L_RXD, GPIO_FN_VIO2_HD3, \
-	GPIO_FN_DACK1, GPIO_FN_OVCN,
-	GPIO_FN_MSIOF0L_TXD, GPIO_FN_VIO2_VD3,
-
-	GPIO_FN_OVCN2,
-	GPIO_FN_EXTLP, GPIO_FN_PORT226_VIO_CKO2,
-	GPIO_FN_IDIN,
-	GPIO_FN_MFG1_IN1,
-	GPIO_FN_MSIOF1_TXD,
-	GPIO_FN_MSIOF1_TSYNC,
-	GPIO_FN_MSIOF1_TSCK,
-	GPIO_FN_MSIOF1_RXD,
-	GPIO_FN_MSIOF1_RSCK, GPIO_FN_VIO2_CLK2,
-	GPIO_FN_MSIOF1_RSYNC, GPIO_FN_MFG1_IN2, GPIO_FN_VIO2_VD2, \
-	GPIO_FN_MSIOF1_MCK0,
-	GPIO_FN_MSIOF1_MCK1,
-	GPIO_FN_MSIOF1_SS1, GPIO_FN_VIO2_FIELD2,
-	GPIO_FN_MSIOF1_SS2, GPIO_FN_VIO2_HD2,
-	GPIO_FN_PORT241_IROUT, GPIO_FN_MFG4_OUT1, \
-	GPIO_FN_TPU4TO0,
-	GPIO_FN_MFG4_IN2,
-	GPIO_FN_PORT243_VIO_CKO2,
-	GPIO_FN_MFG2_IN1,
-	GPIO_FN_MSIOF2R_RXD,
-	GPIO_FN_MFG2_IN2,
-	GPIO_FN_MSIOF2R_TXD,
-	GPIO_FN_MFG1_OUT1,
-	GPIO_FN_TPU1TO0,
-	GPIO_FN_MFG3_OUT2,
-	GPIO_FN_TPU3TO1,
-	GPIO_FN_MFG2_OUT1,
-	GPIO_FN_TPU2TO0,
-	GPIO_FN_MSIOF2R_TSCK,
-	GPIO_FN_PORT249_IROUT, GPIO_FN_MFG4_IN1, \
-	GPIO_FN_MSIOF2R_TSYNC,
-	GPIO_FN_SDHICLK0,
-	GPIO_FN_SDHICD0,
-	GPIO_FN_SDHID0_0,
-	GPIO_FN_SDHID0_1,
-	GPIO_FN_SDHID0_2,
-	GPIO_FN_SDHID0_3,
-	GPIO_FN_SDHICMD0,
-	GPIO_FN_SDHIWP0,
-	GPIO_FN_SDHICLK1,
-	GPIO_FN_SDHID1_0, GPIO_FN_TS_SPSYNC2,
-	GPIO_FN_SDHID1_1, GPIO_FN_TS_SDAT2,
-	GPIO_FN_SDHID1_2, GPIO_FN_TS_SDEN2,
-	GPIO_FN_SDHID1_3, GPIO_FN_TS_SCK2,
-	GPIO_FN_SDHICMD1,
-	GPIO_FN_SDHICLK2,
-	GPIO_FN_SDHID2_0, GPIO_FN_TS_SPSYNC4,
-	GPIO_FN_SDHID2_1, GPIO_FN_TS_SDAT4,
-	GPIO_FN_SDHID2_2, GPIO_FN_TS_SDEN4,
-	GPIO_FN_SDHID2_3, GPIO_FN_TS_SCK4,
-	GPIO_FN_SDHICMD2,
-	GPIO_FN_MMCCLK0,
-	GPIO_FN_MMCD0_0,
-	GPIO_FN_MMCD0_1,
-	GPIO_FN_MMCD0_2,
-	GPIO_FN_MMCD0_3,
-	GPIO_FN_MMCD0_4, GPIO_FN_TS_SPSYNC5,
-	GPIO_FN_MMCD0_5, GPIO_FN_TS_SDAT5,
-	GPIO_FN_MMCD0_6, GPIO_FN_TS_SDEN5,
-	GPIO_FN_MMCD0_7, GPIO_FN_TS_SCK5,
-	GPIO_FN_MMCCMD0,
-	GPIO_FN_RESETOUTS_, GPIO_FN_EXTAL2OUT,
-	GPIO_FN_MCP_WAIT__MCP_FRB,
-	GPIO_FN_MCP_CKO, GPIO_FN_MMCCLK1,
-	GPIO_FN_MCP_D15_MCP_NAF15,
-	GPIO_FN_MCP_D14_MCP_NAF14,
-	GPIO_FN_MCP_D13_MCP_NAF13,
-	GPIO_FN_MCP_D12_MCP_NAF12,
-	GPIO_FN_MCP_D11_MCP_NAF11,
-	GPIO_FN_MCP_D10_MCP_NAF10,
-	GPIO_FN_MCP_D9_MCP_NAF9,
-	GPIO_FN_MCP_D8_MCP_NAF8, GPIO_FN_MMCCMD1,
-	GPIO_FN_MCP_D7_MCP_NAF7, GPIO_FN_MMCD1_7,
-
-	GPIO_FN_MCP_D6_MCP_NAF6, GPIO_FN_MMCD1_6,
-	GPIO_FN_MCP_D5_MCP_NAF5, GPIO_FN_MMCD1_5,
-	GPIO_FN_MCP_D4_MCP_NAF4, GPIO_FN_MMCD1_4,
-	GPIO_FN_MCP_D3_MCP_NAF3, GPIO_FN_MMCD1_3,
-	GPIO_FN_MCP_D2_MCP_NAF2, GPIO_FN_MMCD1_2,
-	GPIO_FN_MCP_D1_MCP_NAF1, GPIO_FN_MMCD1_1,
-	GPIO_FN_MCP_D0_MCP_NAF0, GPIO_FN_MMCD1_0,
-	GPIO_FN_MCP_NBRSTOUT_,
-	GPIO_FN_MCP_WE0__MCP_FWE, GPIO_FN_MCP_RDWR_MCP_FWE,
-
-	/* MSEL2 special case */
-	GPIO_FN_TSIF2_TS_XX1,
-	GPIO_FN_TSIF2_TS_XX2,
-	GPIO_FN_TSIF2_TS_XX3,
-	GPIO_FN_TSIF2_TS_XX4,
-	GPIO_FN_TSIF2_TS_XX5,
-	GPIO_FN_TSIF1_TS_XX1,
-	GPIO_FN_TSIF1_TS_XX2,
-	GPIO_FN_TSIF1_TS_XX3,
-	GPIO_FN_TSIF1_TS_XX4,
-	GPIO_FN_TSIF1_TS_XX5,
-	GPIO_FN_TSIF0_TS_XX1,
-	GPIO_FN_TSIF0_TS_XX2,
-	GPIO_FN_TSIF0_TS_XX3,
-	GPIO_FN_TSIF0_TS_XX4,
-	GPIO_FN_TSIF0_TS_XX5,
-	GPIO_FN_MST1_TS_XX1,
-	GPIO_FN_MST1_TS_XX2,
-	GPIO_FN_MST1_TS_XX3,
-	GPIO_FN_MST1_TS_XX4,
-	GPIO_FN_MST1_TS_XX5,
-	GPIO_FN_MST0_TS_XX1,
-	GPIO_FN_MST0_TS_XX2,
-	GPIO_FN_MST0_TS_XX3,
-	GPIO_FN_MST0_TS_XX4,
-	GPIO_FN_MST0_TS_XX5,
-
-	/* MSEL3 special cases */
-	GPIO_FN_SDHI0_VCCQ_MC0_ON,
-	GPIO_FN_SDHI0_VCCQ_MC0_OFF,
-	GPIO_FN_DEBUG_MON_VIO,
-	GPIO_FN_DEBUG_MON_LCDD,
-	GPIO_FN_LCDC_LCDC0,
-	GPIO_FN_LCDC_LCDC1,
-
-	/* MSEL4 special cases */
-	GPIO_FN_IRQ9_MEM_INT,
-	GPIO_FN_IRQ9_MCP_INT,
-	GPIO_FN_A11,
-	GPIO_FN_TPU4TO3,
-	GPIO_FN_RESETA_N_PU_ON,
-	GPIO_FN_RESETA_N_PU_OFF,
-	GPIO_FN_EDBGREQ_PD,
-	GPIO_FN_EDBGREQ_PU,
-
-	/* end of GPIO */
-	GPIO_NR,
-};
+#define GPIO_NR			310
 
 /* DMA slave IDs */
 enum {
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:03 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:03 +0900
Subject: [PATCH 10/16] ARM: shmobile: Make r8a7790 Arch timer optional
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <8333d8c995169e489a81241bd632a4b9370ed7c3.1374624383.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Update the r8a7790 code to allow using other
timers than Arch timer for clock events.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig                | 1 -
 arch/arm/mach-shmobile/board-lager.c          | 1 +
 arch/arm/mach-shmobile/include/mach/r8a7790.h | 1 +
 arch/arm/mach-shmobile/setup-r8a7790.c        | 8 ++++++++
 4 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 734b3ee..406077c 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -61,7 +61,6 @@ config ARCH_R8A7790
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_GIC
 	select CPU_V7
-	select HAVE_ARM_ARCH_TIMER
 	select SH_CLK_CPG
 	select RENESAS_IRQC
 
diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index 1e99b17..d0da052 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -102,6 +102,7 @@ static const char *lager_boards_compat_dt[] __initdata = {
 };
 
 DT_MACHINE_START(LAGER_DT, "lager")
+	.init_early	= r8a7790_init_delay,
 	.init_time	= r8a7790_timer_init,
 	.init_machine	= lager_add_standard_devices,
 	.dt_compat	= lager_boards_compat_dt,
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h b/arch/arm/mach-shmobile/include/mach/r8a7790.h
index 2e919e6..7851cc1 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7790.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7790.h
@@ -4,6 +4,7 @@
 void r8a7790_add_standard_devices(void);
 void r8a7790_clock_init(void);
 void r8a7790_pinmux_init(void);
+void r8a7790_init_delay(void);
 void r8a7790_timer_init(void);
 
 #endif /* __ASM_R8A7790_H__ */
diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index ece60c6..f01542e 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -208,6 +208,13 @@ void __init r8a7790_timer_init(void)
 	shmobile_timer_init();
 }
 
+void __init r8a7790_init_delay(void)
+{
+#ifndef CONFIG_ARM_ARCH_TIMER
+	shmobile_setup_delay(1300, 2, 4); /* Cortex-A15 @ 1300MHz */
+#endif
+}
+
 #ifdef CONFIG_USE_OF
 
 static const char *r8a7790_boards_compat_dt[] __initdata = {
@@ -216,6 +223,7 @@ static const char *r8a7790_boards_compat_dt[] __initdata = {
 };
 
 DT_MACHINE_START(R8A7790_DT, "Generic R8A7790 (Flattened Device Tree)")
+	.init_early	= r8a7790_init_delay,
 	.init_time	= r8a7790_timer_init,
 	.dt_compat	= r8a7790_boards_compat_dt,
 MACHINE_END
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:03 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:03 +0900
Subject: [PATCH 09/16] ARM: shmobile: Add r8a7790 CMT00 clock event
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <99ade1a0f02e086248874d9908def3e8e4539418.1374624383.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add clock event support for CMT0 timer channel 0
to the r8a7790 SoC code. On most ARM mach-shmobile
the CMT is hooked up to a 32KHz clock but on r8a7790
a 31.7KHz clock is instead used.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7790.c |  4 ++++
 arch/arm/mach-shmobile/setup-r8a7790.c | 23 ++++++++++++++++++++++-
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c b/arch/arm/mach-shmobile/clock-r8a7790.c
index 10d99b3..62d8162 100644
--- a/arch/arm/mach-shmobile/clock-r8a7790.c
+++ b/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -47,6 +47,7 @@
 #define CPG_BASE 0xe6150000
 #define CPG_LEN 0x1000
 
+#define SMSTPCR1 0xe6150134
 #define SMSTPCR2 0xe6150138
 #define SMSTPCR3 0xe615013c
 #define SMSTPCR5 0xe6150144
@@ -186,6 +187,7 @@ enum {
 	MSTP522,
 	MSTP315, MSTP314, MSTP313, MSTP312, MSTP311, MSTP305, MSTP304,
 	MSTP216, MSTP207, MSTP206, MSTP204, MSTP203, MSTP202,
+	MSTP124,
 	MSTP_NR
 };
 
@@ -208,6 +210,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP204] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 4, 0), /* SCIFA0 */
 	[MSTP203] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 3, 0), /* SCIFA1 */
 	[MSTP202] = SH_CLK_MSTP32(&mp_clk, SMSTPCR2, 2, 0), /* SCIFA2 */
+	[MSTP124] = SH_CLK_MSTP32(&rclk_clk, SMSTPCR1, 24, 0), /* CMT0 */
 };
 
 static struct clk_lookup lookups[] = {
@@ -270,6 +273,7 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh_mobile_sdhi.3", &mstp_clks[MSTP311]),
 	CLKDEV_DEV_ID("ee220000.mmcif", &mstp_clks[MSTP305]),
 	CLKDEV_DEV_ID("sh_mmcif.1", &mstp_clks[MSTP305]),
+	CLKDEV_DEV_ID("sh_cmt.0", &mstp_clks[MSTP124]),
 };
 
 #define R8A7790_CLOCK_ROOT(e, m, p0, p1, p30, p31)		\
diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index bc40a44..ece60c6 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -21,9 +21,10 @@
 #include <linux/irq.h>
 #include <linux/kernel.h>
 #include <linux/of_platform.h>
-#include <linux/serial_sci.h>
 #include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_data/irq-renesas-irqc.h>
+#include <linux/serial_sci.h>
+#include <linux/sh_timer.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a7790.h>
@@ -159,6 +160,25 @@ static struct resource thermal_resources[] __initdata = {
 					thermal_resources,		\
 					ARRAY_SIZE(thermal_resources))
 
+static struct sh_timer_config cmt00_platform_data = {
+	.name = "CMT00",
+	.timer_bit = 0,
+	.clockevent_rating = 80,
+};
+
+static struct resource cmt00_resources[] = {
+	DEFINE_RES_MEM(0xffca0510, 0x0c),
+	DEFINE_RES_MEM(0xffca0500, 0x04),
+	DEFINE_RES_IRQ(gic_spi(142)), /* CMT0_0 */
+};
+
+#define r8a7790_register_cmt(idx)					\
+	platform_device_register_resndata(&platform_bus, "sh_cmt",	\
+					  idx, cmt##idx##_resources,	\
+					  ARRAY_SIZE(cmt##idx##_resources), \
+					  &cmt##idx##_platform_data,	\
+					  sizeof(struct sh_timer_config))
+
 void __init r8a7790_add_standard_devices(void)
 {
 	r8a7790_register_scif(SCIFA0);
@@ -173,6 +193,7 @@ void __init r8a7790_add_standard_devices(void)
 	r8a7790_register_scif(HSCIF1);
 	r8a7790_register_irqc(0);
 	r8a7790_register_thermal();
+	r8a7790_register_cmt(00);
 }
 
 void __init r8a7790_timer_init(void)
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:01 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:01 +0900
Subject: [PATCH 07/16] ARM: shmobile: r8a73a4: add clocks for I2C controllers
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <1e453df90047f052cdce2041a572830c8eb32084.1374624383.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

r8a73a4 SoCs have numerous I2C controllers, of which 9 are compatible with
the i2c-sh_mobile.c driver. This patch adds clock definitions for them.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a73a4.c | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a73a4.c b/arch/arm/mach-shmobile/clock-r8a73a4.c
index 27ff58c..f831b3b 100644
--- a/arch/arm/mach-shmobile/clock-r8a73a4.c
+++ b/arch/arm/mach-shmobile/clock-r8a73a4.c
@@ -30,6 +30,7 @@
 
 #define SMSTPCR2 0xe6150138
 #define SMSTPCR3 0xe615013c
+#define SMSTPCR4 0xe6150140
 #define SMSTPCR5 0xe6150144
 
 #define FRQCRA		0xE6150000
@@ -504,8 +505,10 @@ static struct clk div6_clks[DIV6_NR] = {
 /* MSTP */
 enum {
 	MSTP217, MSTP216, MSTP207, MSTP206, MSTP204, MSTP203,
-	MSTP315, MSTP314, MSTP313, MSTP312, MSTP305,
-	MSTP522,
+	MSTP323, MSTP318, MSTP317, MSTP316,
+	MSTP315, MSTP314, MSTP313, MSTP312, MSTP305, MSTP300,
+	MSTP411, MSTP410, MSTP409,
+	MSTP522, MSTP515,
 	MSTP_NR
 };
 
@@ -516,12 +519,21 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP207] = SH_CLK_MSTP32(&div6_clks[DIV6_MP],	SMSTPCR2, 7, 0), /* SCIFB1 */
 	[MSTP216] = SH_CLK_MSTP32(&div6_clks[DIV6_MP],	SMSTPCR2, 16, 0), /* SCIFB2 */
 	[MSTP217] = SH_CLK_MSTP32(&div6_clks[DIV6_MP],	SMSTPCR2, 17, 0), /* SCIFB3 */
+	[MSTP300] = SH_CLK_MSTP32(&div4_clks[DIV4_HP],	SMSTPCR3, 0, 0), /* IIC2 */
 	[MSTP305] = SH_CLK_MSTP32(&div6_clks[DIV6_MMC1],SMSTPCR3, 5, 0), /* MMCIF1 */
 	[MSTP312] = SH_CLK_MSTP32(&div6_clks[DIV6_SDHI2],SMSTPCR3, 12, 0), /* SDHI2 */
 	[MSTP313] = SH_CLK_MSTP32(&div6_clks[DIV6_SDHI1],SMSTPCR3, 13, 0), /* SDHI1 */
 	[MSTP314] = SH_CLK_MSTP32(&div6_clks[DIV6_SDHI0],SMSTPCR3, 14, 0), /* SDHI0 */
 	[MSTP315] = SH_CLK_MSTP32(&div6_clks[DIV6_MMC0],SMSTPCR3, 15, 0), /* MMCIF0 */
+	[MSTP316] = SH_CLK_MSTP32(&div4_clks[DIV4_HP],	SMSTPCR3, 16, 0), /* IIC6 */
+	[MSTP317] = SH_CLK_MSTP32(&div4_clks[DIV4_HP],	SMSTPCR3, 17, 0), /* IIC7 */
+	[MSTP318] = SH_CLK_MSTP32(&div4_clks[DIV4_HP],	SMSTPCR3, 18, 0), /* IIC0 */
+	[MSTP323] = SH_CLK_MSTP32(&div4_clks[DIV4_HP],	SMSTPCR3, 23, 0), /* IIC1 */
+	[MSTP409] = SH_CLK_MSTP32(&main_div2_clk,	SMSTPCR4, 9, 0), /* IIC5 */
+	[MSTP410] = SH_CLK_MSTP32(&div4_clks[DIV4_HP],	SMSTPCR4, 10, 0), /* IIC4 */
+	[MSTP411] = SH_CLK_MSTP32(&div4_clks[DIV4_HP],	SMSTPCR4, 11, 0), /* IIC3 */
 	[MSTP522] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR5, 22, 0), /* Thermal */
+	[MSTP515] = SH_CLK_MSTP32(&div4_clks[DIV4_HP],	SMSTPCR5, 15, 0), /* IIC8 */
 };
 
 static struct clk_lookup lookups[] = {
@@ -566,6 +578,7 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh-sci.4", &mstp_clks[MSTP216]),
 	CLKDEV_DEV_ID("sh-sci.5", &mstp_clks[MSTP217]),
 	CLKDEV_DEV_ID("rcar_thermal", &mstp_clks[MSTP522]),
+	CLKDEV_DEV_ID("e6520000.i2c", &mstp_clks[MSTP300]),
 	CLKDEV_DEV_ID("sh_mmcif.1", &mstp_clks[MSTP305]),
 	CLKDEV_DEV_ID("ee220000.mmcif", &mstp_clks[MSTP305]),
 	CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP312]),
@@ -576,6 +589,14 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("ee100000.sdhi", &mstp_clks[MSTP314]),
 	CLKDEV_DEV_ID("sh_mmcif.0", &mstp_clks[MSTP315]),
 	CLKDEV_DEV_ID("ee200000.mmcif", &mstp_clks[MSTP315]),
+	CLKDEV_DEV_ID("e6550000.i2c", &mstp_clks[MSTP316]),
+	CLKDEV_DEV_ID("e6560000.i2c", &mstp_clks[MSTP317]),
+	CLKDEV_DEV_ID("e6500000.i2c", &mstp_clks[MSTP318]),
+	CLKDEV_DEV_ID("e6510000.i2c", &mstp_clks[MSTP323]),
+	CLKDEV_DEV_ID("e60b0000.i2c", &mstp_clks[MSTP409]),
+	CLKDEV_DEV_ID("e6540000.i2c", &mstp_clks[MSTP410]),
+	CLKDEV_DEV_ID("e6530000.i2c", &mstp_clks[MSTP411]),
+	CLKDEV_DEV_ID("e6570000.i2c", &mstp_clks[MSTP515]),
 
 	/* for DT */
 	CLKDEV_DEV_ID("e61f0000.thermal", &mstp_clks[MSTP522]),
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:06 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:06 +0900
Subject: [PATCH 13/16] ARM: shmobile: Disconnect EMEV2 SMP code from clocks
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <8d7217e5d74966e1016dad1f48fdaebb85deb685.1374624383.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Update the EMEV2 SMP code to access the SMU directly
instead of relying on help from the legacy clock code.

This change moves us one step closer to common clocks.

Signed-off-by: Magnus Damm <damm at opensource.se>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-emev2.c        | 18 ------------------
 arch/arm/mach-shmobile/include/mach/emev2.h |  1 -
 arch/arm/mach-shmobile/smp-emev2.c          | 11 +++++++++--
 3 files changed, 9 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-emev2.c b/arch/arm/mach-shmobile/clock-emev2.c
index 56dd0cf..5ac13ba 100644
--- a/arch/arm/mach-shmobile/clock-emev2.c
+++ b/arch/arm/mach-shmobile/clock-emev2.c
@@ -40,7 +40,6 @@
 #define USIB2SCLKDIV 0x65c
 #define USIB3SCLKDIV 0x660
 #define STI_CLKSEL 0x688
-#define SMU_GENERAL_REG0 0x7c0
 
 /* not pretty, but hey */
 static void __iomem *smu_base;
@@ -51,11 +50,6 @@ static void emev2_smu_write(unsigned long value, int offs)
 	iowrite32(value, smu_base + offs);
 }
 
-void emev2_set_boot_vector(unsigned long value)
-{
-	emev2_smu_write(value, SMU_GENERAL_REG0);
-}
-
 static struct clk_mapping smu_mapping = {
 	.phys	= EMEV2_SMU_BASE,
 	.len	= PAGE_SIZE,
@@ -205,18 +199,6 @@ static struct clk_lookup lookups[] = {
 void __init emev2_clock_init(void)
 {
 	int k, ret = 0;
-	static int is_setup;
-
-	/* yuck, this is ugly as hell, but the non-smp case of clocks
-	 * code is now designed to rely on ioremap() instead of static
-	 * entity maps. in the case of smp we need access to the SMU
-	 * register earlier than ioremap() is actually working without
-	 * any static maps. to enable SMP in ugly but with dynamic
-	 * mappings we have to call emev2_clock_init() from different
-	 * places depending on UP and SMP...
-	 */
-	if (is_setup++)
-		return;
 
 	smu_base = ioremap(EMEV2_SMU_BASE, PAGE_SIZE);
 	BUG_ON(!smu_base);
diff --git a/arch/arm/mach-shmobile/include/mach/emev2.h b/arch/arm/mach-shmobile/include/mach/emev2.h
index b0ab4b7..c2eb756 100644
--- a/arch/arm/mach-shmobile/include/mach/emev2.h
+++ b/arch/arm/mach-shmobile/include/mach/emev2.h
@@ -5,7 +5,6 @@ extern void emev2_map_io(void);
 extern void emev2_init_delay(void);
 extern void emev2_add_standard_devices(void);
 extern void emev2_clock_init(void);
-extern void emev2_set_boot_vector(unsigned long value);
 
 #define EMEV2_GPIO_BASE 200
 #define EMEV2_GPIO_IRQ(n) (EMEV2_GPIO_BASE + (n))
diff --git a/arch/arm/mach-shmobile/smp-emev2.c b/arch/arm/mach-shmobile/smp-emev2.c
index 9787165..1bf8bc7 100644
--- a/arch/arm/mach-shmobile/smp-emev2.c
+++ b/arch/arm/mach-shmobile/smp-emev2.c
@@ -29,6 +29,8 @@
 #include <asm/smp_scu.h>
 
 #define EMEV2_SCU_BASE 0x1e000000
+#define EMEV2_SMU_BASE 0xe0110000
+#define SMU_GENERAL_REG0 0x7c0
 
 static int __cpuinit emev2_boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
@@ -38,13 +40,18 @@ static int __cpuinit emev2_boot_secondary(unsigned int cpu, struct task_struct *
 
 static void __init emev2_smp_prepare_cpus(unsigned int max_cpus)
 {
+	void __iomem *smu;
+
 	/* setup EMEV2 specific SCU base, enable */
 	shmobile_scu_base = ioremap(EMEV2_SCU_BASE, PAGE_SIZE);
 	scu_enable(shmobile_scu_base);
 
 	/* Tell ROM loader about our vector (in headsmp-scu.S, headsmp.S) */
-	emev2_clock_init(); /* need ioremapped SMU */
-	emev2_set_boot_vector(__pa(shmobile_boot_vector));
+	smu = ioremap(EMEV2_SMU_BASE, PAGE_SIZE);
+	if (smu) {
+		iowrite32(__pa(shmobile_boot_vector), smu + SMU_GENERAL_REG0);
+		iounmap(smu);
+	}
 	shmobile_boot_fn = virt_to_phys(shmobile_boot_scu);
 	shmobile_boot_arg = (unsigned long)shmobile_scu_base;
 
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:04 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:04 +0900
Subject: [PATCH 11/16] ARM: shmobile: Add r8a73a4 CMT10 clock event
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <a7b99f27a260a25f856ea37090cea997d50fe112.1374624383.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add clock event support for CMT1 timer channel 0
to the r8a73a4 SoC code. The CMT is used together
with a 32KHz clock in this case.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a73a4.c |  4 +++-
 arch/arm/mach-shmobile/setup-r8a73a4.c | 21 +++++++++++++++++++++
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a73a4.c b/arch/arm/mach-shmobile/clock-r8a73a4.c
index f831b3b..8ea5ef6 100644
--- a/arch/arm/mach-shmobile/clock-r8a73a4.c
+++ b/arch/arm/mach-shmobile/clock-r8a73a4.c
@@ -505,7 +505,7 @@ static struct clk div6_clks[DIV6_NR] = {
 /* MSTP */
 enum {
 	MSTP217, MSTP216, MSTP207, MSTP206, MSTP204, MSTP203,
-	MSTP323, MSTP318, MSTP317, MSTP316,
+	MSTP329, MSTP323, MSTP318, MSTP317, MSTP316,
 	MSTP315, MSTP314, MSTP313, MSTP312, MSTP305, MSTP300,
 	MSTP411, MSTP410, MSTP409,
 	MSTP522, MSTP515,
@@ -529,6 +529,7 @@ static struct clk mstp_clks[MSTP_NR] = {
 	[MSTP317] = SH_CLK_MSTP32(&div4_clks[DIV4_HP],	SMSTPCR3, 17, 0), /* IIC7 */
 	[MSTP318] = SH_CLK_MSTP32(&div4_clks[DIV4_HP],	SMSTPCR3, 18, 0), /* IIC0 */
 	[MSTP323] = SH_CLK_MSTP32(&div4_clks[DIV4_HP],	SMSTPCR3, 23, 0), /* IIC1 */
+	[MSTP329] = SH_CLK_MSTP32(&extalr_clk, SMSTPCR3, 29, 0), /* CMT10 */
 	[MSTP409] = SH_CLK_MSTP32(&main_div2_clk,	SMSTPCR4, 9, 0), /* IIC5 */
 	[MSTP410] = SH_CLK_MSTP32(&div4_clks[DIV4_HP],	SMSTPCR4, 10, 0), /* IIC4 */
 	[MSTP411] = SH_CLK_MSTP32(&div4_clks[DIV4_HP],	SMSTPCR4, 11, 0), /* IIC3 */
@@ -593,6 +594,7 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("e6560000.i2c", &mstp_clks[MSTP317]),
 	CLKDEV_DEV_ID("e6500000.i2c", &mstp_clks[MSTP318]),
 	CLKDEV_DEV_ID("e6510000.i2c", &mstp_clks[MSTP323]),
+	CLKDEV_DEV_ID("sh_cmt.10", &mstp_clks[MSTP329]),
 	CLKDEV_DEV_ID("e60b0000.i2c", &mstp_clks[MSTP409]),
 	CLKDEV_DEV_ID("e6540000.i2c", &mstp_clks[MSTP410]),
 	CLKDEV_DEV_ID("e6530000.i2c", &mstp_clks[MSTP411]),
diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c b/arch/arm/mach-shmobile/setup-r8a73a4.c
index 9c52096..b8dddf4 100644
--- a/arch/arm/mach-shmobile/setup-r8a73a4.c
+++ b/arch/arm/mach-shmobile/setup-r8a73a4.c
@@ -22,6 +22,7 @@
 #include <linux/of_platform.h>
 #include <linux/platform_data/irq-renesas-irqc.h>
 #include <linux/serial_sci.h>
+#include <linux/sh_timer.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a73a4.h>
@@ -168,6 +169,25 @@ static const struct resource thermal0_resources[] = {
 					thermal0_resources,		\
 					ARRAY_SIZE(thermal0_resources))
 
+static struct sh_timer_config cmt10_platform_data = {
+	.name = "CMT10",
+	.timer_bit = 0,
+	.clockevent_rating = 80,
+};
+
+static struct resource cmt10_resources[] = {
+	DEFINE_RES_MEM(0xe6130010, 0x0c),
+	DEFINE_RES_MEM(0xe6130000, 0x04),
+	DEFINE_RES_IRQ(gic_spi(120)), /* CMT1_0 */
+};
+
+#define r8a7790_register_cmt(idx)					\
+	platform_device_register_resndata(&platform_bus, "sh_cmt",	\
+					  idx, cmt##idx##_resources,	\
+					  ARRAY_SIZE(cmt##idx##_resources), \
+					  &cmt##idx##_platform_data,	\
+					  sizeof(struct sh_timer_config))
+
 void __init r8a73a4_add_standard_devices(void)
 {
 	r8a73a4_register_scif(SCIFA0);
@@ -179,6 +199,7 @@ void __init r8a73a4_add_standard_devices(void)
 	r8a73a4_register_irqc(0);
 	r8a73a4_register_irqc(1);
 	r8a73a4_register_thermal();
+	r8a7790_register_cmt(10);
 }
 
 #ifdef CONFIG_USE_OF
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:08 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:08 +0900
Subject: [PATCH 15/16] ARM: shmobile: Introduce r8a7790_read_mode_pins()
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <512e53bc7f0088e3adfd89b3fea3447495fc8423.1374624383.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Break out the r8a7790 boot mode code into a separate
function so it can be shared by multiple users.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/clock-r8a7790.c        | 11 ++---------
 arch/arm/mach-shmobile/include/mach/r8a7790.h |  3 +++
 arch/arm/mach-shmobile/setup-r8a7790.c        | 14 ++++++++++++++
 3 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c b/arch/arm/mach-shmobile/clock-r8a7790.c
index 62d8162..50d96f9 100644
--- a/arch/arm/mach-shmobile/clock-r8a7790.c
+++ b/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -24,6 +24,7 @@
 #include <linux/clkdev.h>
 #include <mach/clock.h>
 #include <mach/common.h>
+#include <mach/r8a7790.h>
 
 /*
  *   MD		EXTAL		PLL0	PLL1	PLL3
@@ -42,8 +43,6 @@
  *	see "p1 / 2" on R8A7790_CLOCK_ROOT() below
  */
 
-#define MD(nr)	(1 << nr)
-
 #define CPG_BASE 0xe6150000
 #define CPG_LEN 0x1000
 
@@ -53,7 +52,6 @@
 #define SMSTPCR5 0xe6150144
 #define SMSTPCR7 0xe615014c
 
-#define MODEMR		0xE6160060
 #define SDCKCR		0xE6150074
 #define SD2CKCR		0xE6150078
 #define SD3CKCR		0xE615007C
@@ -288,14 +286,9 @@ static struct clk_lookup lookups[] = {
 
 void __init r8a7790_clock_init(void)
 {
-	void __iomem *modemr = ioremap_nocache(MODEMR, PAGE_SIZE);
-	u32 mode;
+	u32 mode = r8a7790_read_mode_pins();
 	int k, ret = 0;
 
-	BUG_ON(!modemr);
-	mode = ioread32(modemr);
-	iounmap(modemr);
-
 	switch (mode & (MD(14) | MD(13))) {
 	case 0:
 		R8A7790_CLOCK_ROOT(15, &extal_clk, 172, 208, 106, 88);
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h b/arch/arm/mach-shmobile/include/mach/r8a7790.h
index 7851cc1..7aaef40 100644
--- a/arch/arm/mach-shmobile/include/mach/r8a7790.h
+++ b/arch/arm/mach-shmobile/include/mach/r8a7790.h
@@ -7,4 +7,7 @@ void r8a7790_pinmux_init(void);
 void r8a7790_init_delay(void);
 void r8a7790_timer_init(void);
 
+#define MD(nr) BIT(nr)
+u32 r8a7790_read_mode_pins(void);
+
 #endif /* __ASM_R8A7790_H__ */
diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index f01542e..6acddc1 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -196,6 +196,20 @@ void __init r8a7790_add_standard_devices(void)
 	r8a7790_register_cmt(00);
 }
 
+#define MODEMR 0xe6160060
+
+u32 __init r8a7790_read_mode_pins(void)
+{
+	void __iomem *modemr = ioremap_nocache(MODEMR, 4);
+	u32 mode;
+
+	BUG_ON(!modemr);
+	mode = ioread32(modemr);
+	iounmap(modemr);
+
+	return mode;
+}
+
 void __init r8a7790_timer_init(void)
 {
 	void __iomem *cntcr;
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:31 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:31 +0900
Subject: [PATCH 1/4] ARM: shmobile: armadillo800eva: Add backlight support
In-Reply-To: <cover.1374624997.git.horms+renesas@verge.net.au>
References: <cover.1374624997.git.horms+renesas@verge.net.au>
Message-ID: <d58226a21a7b84a3f82265821f24ce2aad267f1c.1374624997.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The flat panel backlight on the Armadillo 800 EVA board is driven by the
TPU PWM output.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Tested-by: Simon Horman <horms at verge.net.au>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-armadillo800eva.c | 54 +++++++++++++++++++++++++-
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index e115f67..9457c76 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -31,6 +31,8 @@
 #include <linux/gpio_keys.h>
 #include <linux/regulator/driver.h>
 #include <linux/pinctrl/machine.h>
+#include <linux/platform_data/pwm-renesas-tpu.h>
+#include <linux/pwm_backlight.h>
 #include <linux/regulator/fixed.h>
 #include <linux/regulator/gpio-regulator.h>
 #include <linux/regulator/machine.h>
@@ -387,7 +389,50 @@ static struct platform_device sh_eth_device = {
 	.num_resources = ARRAY_SIZE(sh_eth_resources),
 };
 
-/* LCDC */
+/* PWM */
+static struct resource pwm_resources[] = {
+	[0] = {
+		.start = 0xe6600000,
+		.end = 0xe66000ff,
+		.flags = IORESOURCE_MEM,
+	},
+};
+
+static struct tpu_pwm_platform_data pwm_device_data = {
+	.channels[2] = {
+		.polarity = PWM_POLARITY_INVERSED,
+	}
+};
+
+static struct platform_device pwm_device = {
+	.name = "renesas-tpu-pwm",
+	.id = -1,
+	.dev = {
+		.platform_data = &pwm_device_data,
+	},
+	.num_resources = ARRAY_SIZE(pwm_resources),
+	.resource = pwm_resources,
+};
+
+static struct pwm_lookup pwm_lookup[] = {
+	PWM_LOOKUP("renesas-tpu-pwm", 2, "pwm-backlight.0", NULL),
+};
+
+/* LCDC and backlight */
+static struct platform_pwm_backlight_data pwm_backlight_data = {
+	.lth_brightness = 50,
+	.max_brightness = 255,
+	.dft_brightness = 255,
+	.pwm_period_ns = 33333, /* 30kHz */
+};
+
+static struct platform_device pwm_backlight_device = {
+	.name = "pwm-backlight",
+	.dev = {
+		.platform_data = &pwm_backlight_data,
+	},
+};
+
 static struct fb_videomode lcdc0_mode = {
 	.name		= "AMPIER/AM-800480",
 	.xres		= 800,
@@ -1030,6 +1075,8 @@ static struct i2c_board_info i2c2_devices[] = {
  */
 static struct platform_device *eva_devices[] __initdata = {
 	&lcdc0_device,
+	&pwm_device,
+	&pwm_backlight_device,
 	&gpio_keys_device,
 	&sh_eth_device,
 	&vcc_sdhi0,
@@ -1101,6 +1148,9 @@ static const struct pinctrl_map eva_pinctrl_map[] = {
 	/* ST1232 */
 	PIN_MAP_MUX_GROUP_DEFAULT("0-0055", "pfc-r8a7740",
 				  "intc_irq10", "intc"),
+	/* TPU0 */
+	PIN_MAP_MUX_GROUP_DEFAULT("renesas-tpu-pwm", "pfc-r8a7740",
+				  "tpu0_to2_1", "tpu0"),
 	/* USBHS */
 	PIN_MAP_MUX_GROUP_DEFAULT("renesas_usbhs", "pfc-r8a7740",
 				  "intc_irq7_1", "intc"),
@@ -1154,13 +1204,13 @@ static void __init eva_init(void)
 				     ARRAY_SIZE(fixed3v3_power_consumers), 3300000);
 
 	pinctrl_register_mappings(eva_pinctrl_map, ARRAY_SIZE(eva_pinctrl_map));
+	pwm_add_table(pwm_lookup, ARRAY_SIZE(pwm_lookup));
 
 	r8a7740_pinmux_init();
 	r8a7740_meram_workaround();
 
 	/* LCDC0 */
 	gpio_request_one(61, GPIOF_OUT_INIT_HIGH, NULL); /* LCDDON */
-	gpio_request_one(202, GPIOF_OUT_INIT_LOW, NULL); /* LCD0_LED_CONT */
 
 	/* Touchscreen */
 	gpio_request_one(166, GPIOF_OUT_INIT_HIGH, NULL); /* TP_RST_B */
-- 
1.8.2.1



From horms+renesas at verge.net.au  Tue Jul 23 20:34:09 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 09:34:09 +0900
Subject: [PATCH 16/16] ARM: shmobile: Setup r8a7790 arch timer based on MD pins
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <81b9d5351fa96caad4accc6711bc1b9342927d4a.1374624383.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Update the r8a7790 arch timer setup code to configure the
frequency dynamically at boot time. This means that the arch
timer driver will be able to detect a timer frequency that
has been calculated based on the MD pins instead of a fixed
and potentially incorrect 13 MHz.

With this patch applied the Linux kernel will correctly
support the r8a7790 Lager board that uses a 20 Mhz EXTAL.
The arch timer will operate on 10 MHz and the Linux arch
timer driver will be correctly configured to use 10 MHz.

Without this patch the 20 MHz EXTAL will be used to drive
the arch timer at 10 MHz, but the Linux arch timer driver
will believe it is counting at 13 Mhz.

Reported-by: Ulrich Hecht <ulrich.hecht at gmail.com>
Signed-off-by: Magnus Damm <damm at opensource.se>
Tested-by: Ulrich Hecht <ulrich.hecht at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7790.c | 51 ++++++++++++++++++++++++++++++----
 1 file changed, 45 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c
index 6acddc1..4c96dad 100644
--- a/arch/arm/mach-shmobile/setup-r8a7790.c
+++ b/arch/arm/mach-shmobile/setup-r8a7790.c
@@ -210,14 +210,53 @@ u32 __init r8a7790_read_mode_pins(void)
 	return mode;
 }
 
+#define CNTCR 0
+#define CNTFID0 0x20
+
 void __init r8a7790_timer_init(void)
 {
-	void __iomem *cntcr;
-
-	/* make sure arch timer is started by setting bit 0 of CNTCT */
-	cntcr = ioremap(0xe6080000, PAGE_SIZE);
-	iowrite32(1, cntcr);
-	iounmap(cntcr);
+#ifdef CONFIG_ARM_ARCH_TIMER
+	u32 mode = r8a7790_read_mode_pins();
+	void __iomem *base;
+	int extal_mhz = 0;
+	u32 freq;
+
+	/* At Linux boot time the r8a7790 arch timer comes up
+	 * with the counter disabled. Moreover, it may also report
+	 * a potentially incorrect fixed 13 MHz frequency. To be
+	 * correct these registers need to be updated to use the
+	 * frequency EXTAL / 2 which can be determined by the MD pins.
+	 */
+
+	switch (mode & (MD(14) | MD(13))) {
+	case 0:
+		extal_mhz = 15;
+		break;
+	case MD(13):
+		extal_mhz = 20;
+		break;
+	case MD(14):
+		extal_mhz = 26;
+		break;
+	case MD(13) | MD(14):
+		extal_mhz = 30;
+		break;
+	}
+
+	/* The arch timer frequency equals EXTAL / 2 */
+	freq = extal_mhz * (1000000 / 2);
+
+	/* Remap "armgcnt address map" space */
+	base = ioremap(0xe6080000, PAGE_SIZE);
+
+	/* Update registers with correct frequency */
+	iowrite32(freq, base + CNTFID0);
+	asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
+
+	/* make sure arch timer is started by setting bit 0 of CNTCR */
+	iowrite32(1, base + CNTCR);
+	iounmap(base);
+#endif /* CONFIG_ARM_ARCH_TIMER */
 
 	shmobile_timer_init();
 }
-- 
1.8.2.1



From victor.kamensky at linaro.org  Tue Jul 23 21:06:05 2013
From: victor.kamensky at linaro.org (Victor Kamensky)
Date: Tue, 23 Jul 2013 18:06:05 -0700
Subject: updates for be8 patch series
In-Reply-To: <51EECBBD.20000@codethink.co.uk>
References: <CAA3XUr3h5C0oJVrN5iXsM=NFkLMz_Tssp28CysZfwMNS5KvO-Q@mail.gmail.com>
 <51EEC002.9070808@codethink.co.uk>
 <CAA3XUr2oDEDD6LFjnZ_N0JGTFUMDZG6O9b3JoeJ8AELrK2KDiw@mail.gmail.com>
 <CAA3XUr1BJD-ypfJiEsp079qHDERjGp-xFxc_ke_Ep9z3N=UPaA@mail.gmail.com>
 <51EECBBD.20000@codethink.co.uk>
Message-ID: <CAA3XUr31LAJ3+iWq5gXb+JZO-1G96waOFy-RBVZQEW-djj3dYA@mail.gmail.com>

Hi Ben,

Let me split off atomic64 from other issues, so we have focused topic here.

Please see atomic64 issue test case below. Please try it in your setup. I've
run on Pandaboard ES with my set of patches, but I believe it should be the
same in your case.

<snip>

>> Index: linux-linaro-tracking/arch/arm/include/asm/atomic.h
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/include/asm/atomic.h
>> +++ linux-linaro-tracking/arch/arm/include/asm/atomic.h
>> @@ -301,8 +301,13 @@ static inline void atomic64_add(u64 i, a
>>
>>       __asm__ __volatile__("@ atomic64_add\n"
>>   "1:    ldrexd    %0, %H0, [%3]\n"
>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>   "    adds    %0, %0, %4\n"
>>   "    adc    %H0, %H0, %H4\n"
>> +#else
>> +"    adds    %H0, %H0, %H4\n"
>> +"    adc    %0, %0, %4\n"
>> +#endif
>>   "    strexd    %1, %0, %H0, [%3]\n"
>>   "    teq    %1, #0\n"
>>   "    bne    1b"
>> @@ -320,8 +325,13 @@ static inline u64 atomic64_add_return(u6
>>
>>       __asm__ __volatile__("@ atomic64_add_return\n"
>>   "1:    ldrexd    %0, %H0, [%3]\n"
>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>   "    adds    %0, %0, %4\n"
>>   "    adc    %H0, %H0, %H4\n"
>> +#else
>> +"    adds    %H0, %H0, %H4\n"
>> +"    adc    %0, %0, %4\n"
>> +#endif
>>   "    strexd    %1, %0, %H0, [%3]\n"
>>   "    teq    %1, #0\n"
>>   "    bne    1b"
>> @@ -341,8 +351,13 @@ static inline void atomic64_sub(u64 i, a
>>
>>       __asm__ __volatile__("@ atomic64_sub\n"
>>   "1:    ldrexd    %0, %H0, [%3]\n"
>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>   "    subs    %0, %0, %4\n"
>>   "    sbc    %H0, %H0, %H4\n"
>> +#else
>> +"    subs    %H0, %H0, %H4\n"
>> +"    sbc    %0, %0, %4\n"
>> +#endif
>>   "    strexd    %1, %0, %H0, [%3]\n"
>>   "    teq    %1, #0\n"
>>   "    bne    1b"
>> @@ -360,8 +375,13 @@ static inline u64 atomic64_sub_return(u6
>>
>>       __asm__ __volatile__("@ atomic64_sub_return\n"
>>   "1:    ldrexd    %0, %H0, [%3]\n"
>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>   "    subs    %0, %0, %4\n"
>>   "    sbc    %H0, %H0, %H4\n"
>> +#else
>> +"    subs    %H0, %H0, %H4\n"
>> +"    sbc    %0, %0, %4\n"
>> +#endif
>>   "    strexd    %1, %0, %H0, [%3]\n"
>>   "    teq    %1, #0\n"
>>   "    bne    1b"
>> @@ -428,9 +448,15 @@ static inline u64 atomic64_dec_if_positi
>>
>>       __asm__ __volatile__("@ atomic64_dec_if_positive\n"
>>   "1:    ldrexd    %0, %H0, [%3]\n"
>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>   "    subs    %0, %0, #1\n"
>>   "    sbc    %H0, %H0, #0\n"
>>   "    teq    %H0, #0\n"
>> +#else
>> +"    subs    %H0, %H0, #1\n"
>> +"    sbc    %0, %0, #0\n"
>> +"    teq    %0, #0\n"
>> +#endif
>>   "    bmi    2f\n"
>>   "    strexd    %1, %0, %H0, [%3]\n"
>>   "    teq    %1, #0\n"
>> @@ -459,8 +485,13 @@ static inline int atomic64_add_unless(at
>>   "    teqeq    %H0, %H5\n"
>>   "    moveq    %1, #0\n"
>>   "    beq    2f\n"
>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>   "    adds    %0, %0, %6\n"
>>   "    adc    %H0, %H0, %H6\n"
>> +#else
>> +"    adds    %H0, %H0, %H6\n"
>> +"    adc    %0, %0, %6\n"
>> +#endif
>>   "    strexd    %2, %0, %H0, [%4]\n"
>>   "    teq    %2, #0\n"
>>   "    bne    1b\n"
>
>
> I still believe that you're doing the wrong thing here
> and that these can be left well enough alone. Please give
> a concrete piece of code that can show they're actually
> doing the wrong thing.

Disable CONFIG_GENERIC_ATOMIC64
-------------------------------

Make sure that CONFIG_GENERIC_ATOMIC64 is not set. Otherwise atomic64_add from
lib/atomic64.c will be used and that one works correctly but this case does
not use atomic64_XXX inline functions from arch/arm/include/asm/atomic.h

Personally with my current kernel close to 3.10 I failed to do that and manage
to get live kernel, so to illustrate the issue I will use my own copy of
inline atomic64_add function. But effectively it will show the same problem
that I tried to report.

Compiler used
-------------

gcc-linaro-arm-linux-gnueabihf-4.7-2013.01-20130125_linux

Test module source
------------------

#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/atomic.h>

static inline void my_atomic64_add_original(u64 i, atomic64_t *v)
{
    u64 result;
    unsigned long tmp;

    __asm__ __volatile__("@ atomic64_add\n"
"1:    ldrexd    %0, %H0, [%3]\n"
"    adds    %0, %0, %4\n"
"    adc    %H0, %H0, %H4\n"
"    strexd    %1, %0, %H0, [%3]\n"
"    teq    %1, #0\n"
"    bne    1b"
    : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
    : "r" (&v->counter), "r" (i)
    : "cc");
}

static inline void my_atomic64_add_fixed(u64 i, atomic64_t *v)
{
    u64 result;
    unsigned long tmp;

    __asm__ __volatile__("@ atomic64_add\n"
"1:    ldrexd    %0, %H0, [%3]\n"
#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
"    adds    %0, %0, %4\n"
"    adc    %H0, %H0, %H4\n"
#else
"    adds    %H0, %H0, %H4\n"
"    adc    %0, %0, %4\n"
#endif
"    strexd    %1, %0, %H0, [%3]\n"
"    teq    %1, #0\n"
"    bne    1b"
    : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
    : "r" (&v->counter), "r" (i)
    : "cc");
}


atomic64_t a = {0};

#define INCREMENT 0x40000000

void atomic_update_original (void)
{
    my_atomic64_add_original(INCREMENT, &a);
}

void atomic_update_fixed (void)
{
    my_atomic64_add_fixed(INCREMENT, &a);
}

void test_atomic64_original(void)
{
    int i;

    printk("original atomic64_add\n");

    atomic64_set(&a, 0);

    printk("a = %llx\n", a.counter);

    for (i = 0; i < 10; i++) {
        atomic_update_original();
        printk("i = %2d: a =  %llx\n", i, a.counter);
    }
}

void test_atomic64_fixed(void)
{
    int i;

    printk("fixed atomic64_add\n");

    atomic64_set(&a, 0);

    printk("a = %llx\n", a.counter);

    for (i = 0; i < 10; i++) {
        atomic_update_fixed();
        printk("i = %2d: a =  %llx\n", i, a.counter);
    }
}

int
init_module (void)
{
    test_atomic64_original();
    test_atomic64_fixed();
    return 0;
}

void
cleanup_module(void)
{
}

MODULE_LICENSE("GPL");


Test run
--------

Compile and run module, observe in original code counter is not incremented
correctly.

root at genericarmv7ab:~# insmod atomic64.ko
[   73.041107] original atomic64_add
[   73.044647] a = 0
[   73.046691] i =  0: a =  40000000
[   73.050659] i =  1: a =  80000000
[   73.054199] i =  2: a =  c0000000
[   73.057983] i =  3: a =  0
[   73.060852] i =  4: a =  40000000
[   73.064361] i =  5: a =  80000000
[   73.067932] i =  6: a =  c0000000
[   73.071441] i =  7: a =  0
[   73.074310] i =  8: a =  40000000
[   73.077850] i =  9: a =  80000000
[   73.081390] fixed atomic64_add
[   73.084625] a = 0
[   73.086669] i =  0: a =  40000000
[   73.090209] i =  1: a =  80000000
[   73.093749] i =  2: a =  c0000000
[   73.097290] i =  3: a =  100000000
[   73.100891] i =  4: a =  140000000
[   73.104522] i =  5: a =  180000000
[   73.108154] i =  6: a =  1c0000000
[   73.111755] i =  7: a =  200000000
[   73.115386] i =  8: a =  240000000
[   73.119018] i =  9: a =  280000000


Disassemble of original code
----------------------------

(gdb) disassemble atomic_update_original
Dump of assembler code for function atomic_update_original:
   0x00000000 <+0>:    push    {r4}        ; (str r4, [sp, #-4]!)
   0x00000004 <+4>:    mov    r3, #1073741824    ; 0x40000000
   0x00000008 <+8>:    ldr    r12, [pc, #32]    ; 0x30
<atomic_update_original+48>
   0x0000000c <+12>:    mov    r2, #0
   0x00000010 <+16>:    ldrexd    r0, [r12]
   0x00000014 <+20>:    adds    r0, r0, r2
   0x00000018 <+24>:    adc    r1, r1, r3
   0x0000001c <+28>:    strexd    r4, r0, [r12]
   0x00000020 <+32>:    teq    r4, #0
   0x00000024 <+36>:    bne    0x10 <atomic_update_original+16>
   0x00000028 <+40>:    ldmfd    sp!, {r4}
   0x0000002c <+44>:    bx    lr
   0x00000030 <+48>:    andeq    r0, r0, r0
End of assembler dump.

Disassemble of fixed code
-------------------------

(gdb) disassemble atomic_update_fixed
Dump of assembler code for function atomic_update_fixed:
   0x00000034 <+0>:    push    {r4}        ; (str r4, [sp, #-4]!)
   0x00000038 <+4>:    mov    r3, #1073741824    ; 0x40000000
   0x0000003c <+8>:    ldr    r12, [pc, #32]    ; 0x64 <atomic_update_fixed+48>
   0x00000040 <+12>:    mov    r2, #0
   0x00000044 <+16>:    ldrexd    r0, [r12]
   0x00000048 <+20>:    adds    r1, r1, r3
   0x0000004c <+24>:    adc    r0, r0, r2
   0x00000050 <+28>:    strexd    r4, r0, [r12]
   0x00000054 <+32>:    teq    r4, #0
   0x00000058 <+36>:    bne    0x44 <atomic_update_fixed+16>
   0x0000005c <+40>:    ldmfd    sp!, {r4}
   0x00000060 <+44>:    bx    lr
   0x00000064 <+48>:    andeq    r0, r0, r0
End of assembler dump.

Fixed code explanation
----------------------

- $r2 has 4 most significant bytes of increement (0)
- $r3 has 4 least significant bytes of increement (0x40000000)

- Load from address at $r12 'long long' into r0 and r1
  $r0 will get 4 most significant bytes (i.e 4 bytes at $r12)
  $r1 will get 4 least significan bytes (i.e 4 bytes at $r12+4)
  loads are big endian, so $r0 and $r0 will be read with proper be swap

   0x00000044 <+16>:    ldrexd    r0, [r12]

- add $r3 to $r1 store result into $r1, carry flag could be set
- adding 4 least sginificant bytes of 'long long'

   0x00000048 <+20>:    adds    r1, r1, r3

- adding with carry most siginificant parts of increment and counter

   0x0000004c <+24>:    adc    r0, r0, r2

- Store result back
  $r0 will to $r12 address
  $r1 will to $r12+4 address

   0x00000050 <+28>:    strexd    r4, r0, [r12]

Ldrd/strd
---------

Issue boils down to the fact that ldrexd/ldrd and strexd/strd instrucitons
in big endian mode will do byteswap only within 4 bytes boundary, but it will
not swap registers numbers itself. I.e ldrexd rN, <addr> puts swapped 4 bytes
at <addr> address into rN, and it puts swapped 4 bytes at <addr+4> into rN+1

Compiler?
---------

One may thing whether we have compiler bug here. And after all, what is the
meaning of %0 vs %H0? I asked my local gcc expert for the help. Here what
I got. Please look at

https://github.com/mirrors/gcc/blob/master/gcc/config/arm/arm.c

and search for >'Q', 'R' and 'H'<

according to this page '%HN' is always reg+1 operand regardless whether it is
big endian system or not. It is opposite to 'Q'.

Better fix
----------

In fact now I believe correct fix should use 'Q' for least siginificant 4
bytes, 'R' for most siginificant 4 bytes and 'H' is used in load/store
instructions.

It should look something like this:

static inline void my_atomic64_add_fixed1(u64 i, atomic64_t *v)
{
    u64 result;
    unsigned long tmp;

    __asm__ __volatile__("@ atomic64_add\n"
"1:    ldrexd    %0, %H0, [%3]\n"
"    adds    %Q0, %Q0, %Q4\n"
"    adc    %R0, %R0, %R4\n"
"    strexd    %1, %0, %H0, [%3]\n"
"    teq    %1, #0\n"
"    bne    1b"
    : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
    : "r" (&v->counter), "r" (i)
    : "cc");
}

It is better that my original fix because it does not have conditional
compilation. I've tested it in the module, it works on both LE and BE kernel
variants.

Thanks,
Victor


From nicolas.pitre at linaro.org  Tue Jul 23 21:10:18 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Jul 2013 21:10:18 -0400 (EDT)
Subject: [PATCH 6/8] ARM: mm: LPAE: Correct virt_to_phys patching for 64
 bit physical addresses
In-Reply-To: <1371858502-10083-7-git-send-email-santosh.shilimkar@ti.com>
References: <1371858502-10083-1-git-send-email-santosh.shilimkar@ti.com>
 <1371858502-10083-7-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <alpine.LFD.2.03.1307231850350.15022@syhkavp.arg>

On Fri, 21 Jun 2013, Santosh Shilimkar wrote:

> From: Sricharan R <r.sricharan at ti.com>
> 
> The current phys_to_virt patching mechanism does not work
> for 64 bit physical addressesp. Note that constant used in add/sub
> instructions is encoded in to the last 8 bits of the opcode. So shift
> the _pv_offset constant by 24 to get it in to the correct place.
> 
> The v2p patching mechanism patches the higher 32bits of physical
> address with a constant. While this is correct, in those platforms
> where the lowmem addressable physical memory spawns across 4GB boundary,
> a carry bit can be produced as a result of addition of lower 32bits.
> This has to be taken in to account and added in to the upper. The patched
> __pv_offset and va are added in lower 32bits, where __pv_offset can be
> in two's complement form when PA_START < VA_START and that can result
> in a false carry bit.
> 
> e.g PA = 0x80000000 VA = 0xC0000000
> __pv_offset = PA - VA = 0xC0000000 (2's complement)
> 
> So adding __pv_offset + VA should never result in a true overflow. So in
> order to differentiate between a true carry, a extra flag __pv_sign_flag
> is introduced.

I'm still wondering if this is worth bothering about.

If PA = 0x80000000 and VA = 0xC0000000 there will never be a real carry 
to propagate to the high word of the physical address as the VA space 
cannot be larger than 0x40000000.

So is there really a case where:

1) physical memory is crossing the 4GB mark, and ...

2) physical memory start address is higher than virtual memory start 
   address needing a carry due to the 32-bit add overflow?

It is easy to create (2) just by having a different user:kernel address 
space split.  However I wonder if (1) is likely.  Sure you need a memory 
alias in physical space to be able to boot, however you shouldn't need 
to address that memory alias via virtual addresses for any 
significant amount of time.  In fact, as soon as the MMU is turned on, 
there shouldn't be any issue simply using the final physical memory 
addresses right away.

What am I missing?


Nicolas


From xvzhaobin at gmail.com  Tue Jul 23 21:12:30 2013
From: xvzhaobin at gmail.com (zhaobin xv)
Date: Wed, 24 Jul 2013 09:12:30 +0800
Subject: linux setup
In-Reply-To: <alpine.LFD.2.03.1307231530080.15022@syhkavp.arg>
References: <CANEcUBXMPhTjgVYbRN7NY+EUjh7DDGpKnZ8_LXY-ZLcfbH65Ug@mail.gmail.com>
 <20130723102554.GD3748@MacBook-Pro.local>
 <alpine.LFD.2.03.1307231530080.15022@syhkavp.arg>
Message-ID: <CANEcUBVaVBCfaE1iY-cHzYfxhmOQdN80ttqHrGrwD7esNtn=DA@mail.gmail.com>

thank you for your answer,

2013/7/24 Nicolas Pitre <nico at fluxnic.net>:
> On Tue, 23 Jul 2013, Catalin Marinas wrote:
>
>> On Mon, Jul 22, 2013 at 02:28:50PM +0100, zhaobin xv wrote:
>> > I recently read lernel source .
>> > I have a question:In
>> > folder:linux/arch/arm/boot/compressed/head.S(linux2.6.22.6):
>> >
>> >
>> > start:
>> >         .type    start,#function
>> >         .rept    8
>> >         mov    r0, r0
>> >         .endr
>> >
>> >         b    1f
>> >         .word    0x016f2818        @ Magic numbers to help the loader
>> >         .word    start            @ absolute load/run zImage address
>> >         .word    _edata            @ zImage end address
>> > 1:        mov    r7, r1            @ save architecture ID
>> >         mov    r8, r2            @ save atags pointer
>> >
>> >
>> > I don't kown why the ?mov r0 r0 ? repeated  emergence 8 times.
>>
>> I think some people used that in the past to be able to modify the
>> zImage binary directly and work around wrong register values passed by
>> the boot loader. I've never used it myself but I saw it mentioned once.
>
> The whole reason for this is because in a distant past the kernel image
> was an a.out binary containing a 32-bytes header.  Those nops are simply
> padding so to be compatible with those bootloaders expecting the kernel
> code to start at an offset of 32.
>
>
> Nicolas


From kgene at kernel.org  Tue Jul 23 21:50:38 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 24 Jul 2013 10:50:38 +0900
Subject: [PATCH 3/3] ARM: dts: Add WM1811A audio CODEC to Arndale bindings
In-Reply-To: <20130702092507.GV27646@sirena.org.uk>
References: <1372714599-17588-1-git-send-email-broonie@kernel.org>
 <1372714599-17588-3-git-send-email-broonie@kernel.org>
 <51D26360.2080708@linaro.org> <20130702092507.GV27646@sirena.org.uk>
Message-ID: <0deb01ce8810$3295b790$97c126b0$@org>

Mark Brown wrote:
> 
> On Tue, Jul 02, 2013 at 10:51:36AM +0530, Tushar Behera wrote:
> 
> > Arndale board also comes with two other audio codec boards - ALC5631Q
> > and AK4678. Different audio codec boards came with different shipments.
> 
> This is the default though and since they didn't bother providing any
> way of identifying the modules we just have to put them all in the
> device tree and hope that the individual CODEC drivers can do runtime
> identification (the WM1811A can but I don't know about the other two,
> nobody supported them upstream).

Basically, I agree with Mark Brown's opinion, at this moment would be better
if upstreamed WM1811A could be supported on Arndale and if further
supporting of two codecs is required, we could discuss again next time. And
they should be identified in the kernel at runtime.

- Kukjin



From santosh.shilimkar at ti.com  Tue Jul 23 22:01:17 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Tue, 23 Jul 2013 22:01:17 -0400
Subject: [PATCH 6/8] ARM: mm: LPAE: Correct virt_to_phys patching for
 64 bit physical addresses
In-Reply-To: <alpine.LFD.2.03.1307231850350.15022@syhkavp.arg>
References: <1371858502-10083-1-git-send-email-santosh.shilimkar@ti.com>
 <1371858502-10083-7-git-send-email-santosh.shilimkar@ti.com>
 <alpine.LFD.2.03.1307231850350.15022@syhkavp.arg>
Message-ID: <51EF356D.2050902@ti.com>

On Tuesday 23 July 2013 09:10 PM, Nicolas Pitre wrote:
> On Fri, 21 Jun 2013, Santosh Shilimkar wrote:
> 
>> From: Sricharan R <r.sricharan at ti.com>
>>
>> The current phys_to_virt patching mechanism does not work
>> for 64 bit physical addressesp. Note that constant used in add/sub
>> instructions is encoded in to the last 8 bits of the opcode. So shift
>> the _pv_offset constant by 24 to get it in to the correct place.
>>
>> The v2p patching mechanism patches the higher 32bits of physical
>> address with a constant. While this is correct, in those platforms
>> where the lowmem addressable physical memory spawns across 4GB boundary,
>> a carry bit can be produced as a result of addition of lower 32bits.
>> This has to be taken in to account and added in to the upper. The patched
>> __pv_offset and va are added in lower 32bits, where __pv_offset can be
>> in two's complement form when PA_START < VA_START and that can result
>> in a false carry bit.
>>
>> e.g PA = 0x80000000 VA = 0xC0000000
>> __pv_offset = PA - VA = 0xC0000000 (2's complement)
>>
>> So adding __pv_offset + VA should never result in a true overflow. So in
>> order to differentiate between a true carry, a extra flag __pv_sign_flag
>> is introduced.
>
First of all thanks for the review.
 
> I'm still wondering if this is worth bothering about.
> 
> If PA = 0x80000000 and VA = 0xC0000000 there will never be a real carry 
> to propagate to the high word of the physical address as the VA space 
> cannot be larger than 0x40000000.
> 
Agreed.

> So is there really a case where:
> 
> 1) physical memory is crossing the 4GB mark, and ...
> 
> 2) physical memory start address is higher than virtual memory start 
>    address needing a carry due to the 32-bit add overflow?
> 
Consider below two cases of memory layout apart from one mentioned
above where the carry is bit irrelevant as you rightly said.

1) PA = 0x8_0000_0000, VA= 0xC000_0000, absolute pv_offset = 0x7_4000_0000
2) PA = 0x2_8000_0000, VA= 0xC000_000, absolute pv_offset = 0x1_C000_0000

In both of these cases there a true carry which needs to be
considered.

> It is easy to create (2) just by having a different user:kernel address 
> space split.  However I wonder if (1) is likely.  Sure you need a memory 
> alias in physical space to be able to boot, however you shouldn't need 
> to address that memory alias via virtual addresses for any 
> significant amount of time.  In fact, as soon as the MMU is turned on, 
> there shouldn't be any issue simply using the final physical memory 
> addresses right away.
> 
> What am I missing?
> 
I thought about switching to the final address space along with
MMU enable at startup but then based on the discussion earlier
(RMK suggested), to have such a patching support in least disruptive
manner, we could patch once at boot, and then re-patch at switch  
over. This also gives flexibility to be able to patch code post
machine init. Hopefully I haven't missed your point here.

regards,
Santosh






From kgene at kernel.org  Tue Jul 23 22:20:33 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 24 Jul 2013 11:20:33 +0900
Subject: [PATCH 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <CAK9yfHyNqDJKuC8urpyrKR564jVJVfsJRRF0Z9a3p52iLWLZ8A@mail.gmail.com>
References: <1372054438-15693-1-git-send-email-sachin.kamat@linaro.org>
 <CAK9yfHzmF_oxc3DsuT5wtXX2C5O+wLxz4C2Ps3cVPnKLb8jOEw@mail.gmail.com>
 <0ad601ce868c$d88bff40$89a3fdc0$@org> <3136364.6D0qu7zGk3@amdc1227>
 <51ED89CA.2040908@gmail.com>
 <CAK9yfHyNqDJKuC8urpyrKR564jVJVfsJRRF0Z9a3p52iLWLZ8A@mail.gmail.com>
Message-ID: <0df901ce8814$601ab6d0$20502470$@org>

Sachin Kamat wrote:

[...]

> >>>>> Hmm, BTW, I'm wondering why it is 288 not 285 or other specific
> >>>
> >>>
> >>> number...
> >>>
> >>>> I wasn't really sure if we can have any number there. I chose the
> >>>> closest one (288) which was already used by other platform.
> >>>> If there is no problem to use 285 itself then I can resend with that
> >>>> number. Please let me know.
> >>>
> >>>
> >>> If there is no reason, please don't use bigger value than necessary
> one.
> >>
> >>
> >> Hmm, what about some GPIO expanders that would require bigger GPIO
> address
> >> space? I would reserve some space just in case, i.e. define this value
> to
> >> be
> >> the highest number of GPIOs on all Exynos SoCs + some extra, like 32 or
> >> 64.
> >
> >
> > That sounds like a good idea. IIRC I once had to increase ARCH_NR_GPIO
> to
> > make the wm8994 GPIO controller working. The wm8994 driver also handles
> > WM1811 audio codec that some Exynos development boards are shipped with.
> 
> Looks like a valid point.
> 
> Kukjin,
> Let me know your opinion about this before I respin the patch.
> 
Agreed, let's use 512 including some extras, I'm not sure what value for
some GPIO expanders is reasonable at this moment, though. It should be fine
on current EXYNOS platforms.

Thanks,
Kukjin



From r65037 at freescale.com  Tue Jul 23 22:21:18 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Wed, 24 Jul 2013 02:21:18 +0000
Subject: [v3 3/3] sata: imx: add ahci sata support on imx platforms
In-Reply-To: <20130723162623.GD21100@mtj.dyndns.org>
References: <1373017942-12583-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1373017942-12583-4-git-send-email-Hong-Xing.Zhu@freescale.com>
 <20130705174305.GA28088@mtj.dyndns.org>
 <0E83723C55F66F43A6041464FE31119D31432D@039-SN2MPN1-012.039d.mgd.msft.net>
 <20130706020737.GA9029@mtj.dyndns.org>
 <0E83723C55F66F43A6041464FE31119D3441A3@039-SN2MPN1-011.039d.mgd.msft.net>
 <20130723162623.GD21100@mtj.dyndns.org>
Message-ID: <0E83723C55F66F43A6041464FE31119D34517C@039-SN2MPN1-011.039d.mgd.msft.net>

Hi Tejun:
Thanks a lot.

No problem, I can rename the driver from sata_imx to ahci_imx.

Best Regards
Richard Zhu


-----Original Message-----
From: Tejun Heo [mailto:htejun at gmail.com] On Behalf Of Tejun Heo
Sent: Wednesday, July 24, 2013 12:26 AM
To: Zhu Richard-R65037
Cc: Richard Zhu; shawn.guo at linaro.org; linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; avorontsov at ru.mvista.com; rob.herring at calxeda.com; s.hauer at pengutronix.de; linux-ide at vger.kernel.org
Subject: Re: [v3 3/3] sata: imx: add ahci sata support on imx platforms

Hello,

On Mon, Jul 22, 2013 at 07:02:56AM +0000, Zhu Richard-R65037 wrote:
> Re-send this email to you and community.
> I'm afraid that you may be missed or don't receive it.

Sorry about the delay.  I was on the road.

> BTW, can you help to pick up the #2 and #3(reviewed and acked by Shawn) of the v7 patch-set of this serial?
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Just one thing, can you please rename the driver to ahci_imx?  I'd like to keep all ahci drivers with ahci prefix (yeah, there's already an exception, I know).

Thanks.

--
tejun




From nicolas.pitre at linaro.org  Tue Jul 23 22:49:03 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 23 Jul 2013 22:49:03 -0400 (EDT)
Subject: [PATCH 6/8] ARM: mm: LPAE: Correct virt_to_phys patching for 64
 bit physical addresses
In-Reply-To: <51EF356D.2050902@ti.com>
References: <1371858502-10083-1-git-send-email-santosh.shilimkar@ti.com>
 <1371858502-10083-7-git-send-email-santosh.shilimkar@ti.com>
 <alpine.LFD.2.03.1307231850350.15022@syhkavp.arg> <51EF356D.2050902@ti.com>
Message-ID: <alpine.LFD.2.03.1307232222200.15022@syhkavp.arg>

On Tue, 23 Jul 2013, Santosh Shilimkar wrote:

> On Tuesday 23 July 2013 09:10 PM, Nicolas Pitre wrote:
> > On Fri, 21 Jun 2013, Santosh Shilimkar wrote:
> > 
> >> From: Sricharan R <r.sricharan at ti.com>
> >>
> >> The current phys_to_virt patching mechanism does not work
> >> for 64 bit physical addressesp. Note that constant used in add/sub
> >> instructions is encoded in to the last 8 bits of the opcode. So shift
> >> the _pv_offset constant by 24 to get it in to the correct place.
> >>
> >> The v2p patching mechanism patches the higher 32bits of physical
> >> address with a constant. While this is correct, in those platforms
> >> where the lowmem addressable physical memory spawns across 4GB boundary,
> >> a carry bit can be produced as a result of addition of lower 32bits.
> >> This has to be taken in to account and added in to the upper. The patched
> >> __pv_offset and va are added in lower 32bits, where __pv_offset can be
> >> in two's complement form when PA_START < VA_START and that can result
> >> in a false carry bit.
> >>
> >> e.g PA = 0x80000000 VA = 0xC0000000
> >> __pv_offset = PA - VA = 0xC0000000 (2's complement)
> >>
> >> So adding __pv_offset + VA should never result in a true overflow. So in
> >> order to differentiate between a true carry, a extra flag __pv_sign_flag
> >> is introduced.
> >
> First of all thanks for the review.
>  
> > I'm still wondering if this is worth bothering about.
> > 
> > If PA = 0x80000000 and VA = 0xC0000000 there will never be a real carry 
> > to propagate to the high word of the physical address as the VA space 
> > cannot be larger than 0x40000000.
> > 
> Agreed.
> 
> > So is there really a case where:
> > 
> > 1) physical memory is crossing the 4GB mark, and ...
> > 
> > 2) physical memory start address is higher than virtual memory start 
> >    address needing a carry due to the 32-bit add overflow?
> > 
> Consider below two cases of memory layout apart from one mentioned
> above where the carry is bit irrelevant as you rightly said.
> 
> 1) PA = 0x8_0000_0000, VA= 0xC000_0000, absolute pv_offset = 0x7_4000_0000

This can be patched as:

	mov	phys_hi, #0x8
	add	phys_lo, virt, #0x40000000  @ carry ignored

> 2) PA = 0x2_8000_0000, VA= 0xC000_000, absolute pv_offset = 0x1_C000_0000

	mov	phys_hi, #0x2
	add	phys_lo, virt, #0xc0000000  @ carry ignored

> In both of these cases there a true carry which needs to be
> considered.

Well, not really.  However, if you have:

3) PA = 0x2_8000_0000, VA = 0x4000-0000, pv_offset = 0x2-4000-0000

... then you need:

	mov	phys_hi, #0x2
	adds	phys_lo, virt, #0x40000000
	adc	phys_hi, phys_hi, #0

My question is: how likely is this?

What is your actual physical memory start address?

If we really need to cope with the carry, then the __pv_sign_flag should 
instead be represented in pv_offset directly:

Taking example #2 above, that would be:

	mov	phys_hi, #0x1
	adds	phys_lo, virt, #0xc0000000
	adc	phys_hi, phys_hi, #0

If PA = 0x8000-0000 and VA = 0xc000-0000 then pv_offset is 
0xffff-ffff-c000-0000, meaning:

	mvn	phys_hi, #0
	add	phys_lo, virt, #0xc0000000
	adc	phys_hi, phys_hi, #0

So that would require a special case in the patching code where a mvn 
with 0 is used if the high part of pv_offset is 0xffffffff.


Nicolas


From magnus.damm at gmail.com  Tue Jul 23 23:36:23 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 24 Jul 2013 12:36:23 +0900
Subject: [PATCH 0/2] ARCH: ARM: shmobile: Remove kota2 and ag5evm board
 support
In-Reply-To: <1374465895-8372-1-git-send-email-horms+renesas@verge.net.au>
References: <1374465895-8372-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <CANqRtoRZnsv_qF9qJJRz_K27TbO4DGTc-0i=4WgbnvMufTsT6A@mail.gmail.com>

On Mon, Jul 22, 2013 at 1:04 PM, Simon Horman
<horms+renesas at verge.net.au> wrote:
> Remove support for the sh73a0 based kota2 and ag5evm boards.
> Support for the sh72a0 SoC is continued using the kzm9g board.

Looking good, thanks!

Acked-by: Magnus Damm <damm at opensource.se>


From magnus.damm at gmail.com  Tue Jul 23 23:37:15 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 24 Jul 2013 12:37:15 +0900
Subject: [PATCH 00/08] ARM: shmobile: Get rid of <mach/hardware.h>
Message-ID: <20130724033715.30567.82782.sendpatchset@w520>

ARM: shmobile: Get rid of <mach/hardware.h>

[PATCH 01/08] ARM: shmobile: Remove sh73a0 use of <mach/hardware.h>
[PATCH 02/08] ARM: shmobile: Remove sh7372 use of <mach/hardware.h>
[PATCH 03/08] ARM: shmobile: Remove EMEV2 use of <mach/hardware.h>
[PATCH 04/08] ARM: shmobile: Remove r8a7779 use of <mach/hardware.h>
[PATCH 05/08] ARM: shmobile: Remove AG5EVM use of <mach/hardware.h>
[PATCH 06/08] ARM: shmobile: Remove Kota2 use of <mach/hardware.h>
[PATCH 07/08] ARM: shmobile: Remove Marzen use of <mach/hardware.h>
[PATCH 08/08] ARM: shmobile: Remove include <mach/hardware.h>

The <mach/hardware.h> file is empty anyway, so let's stop using it.

Feel free to drop Kota2 or AG5EVM patches in case those boards get
removed before this series is applied.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Built on top of renesas-devel-20130723

 arch/arm/mach-shmobile/board-ag5evm.c          |    1 -
 arch/arm/mach-shmobile/board-kota2.c           |    1 -
 arch/arm/mach-shmobile/board-marzen.c          |    1 -
 arch/arm/mach-shmobile/include/mach/hardware.h |    4 ----
 arch/arm/mach-shmobile/setup-emev2.c           |    1 -
 arch/arm/mach-shmobile/setup-r8a7779.c         |    1 -
 arch/arm/mach-shmobile/setup-sh7372.c          |    1 -
 arch/arm/mach-shmobile/setup-sh73a0.c          |    1 -
 8 files changed, 11 deletions(-)


From magnus.damm at gmail.com  Tue Jul 23 23:37:24 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 24 Jul 2013 12:37:24 +0900
Subject: [PATCH 01/08] ARM: shmobile: Remove sh73a0 use of <mach/hardware.h>
In-Reply-To: <20130724033715.30567.82782.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
Message-ID: <20130724033724.30567.31754.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove unused <mach/hardware.h> on sh73a0.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-sh73a0.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/setup-sh73a0.c
+++ work/arch/arm/mach-shmobile/setup-sh73a0.c	2013-07-23 16:00:03.000000000 +0900
@@ -34,7 +34,6 @@
 #include <linux/platform_data/sh_ipmmu.h>
 #include <linux/platform_data/irq-renesas-intc-irqpin.h>
 #include <mach/dma-register.h>
-#include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <mach/sh73a0.h>
 #include <mach/common.h>


From magnus.damm at gmail.com  Tue Jul 23 23:37:34 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 24 Jul 2013 12:37:34 +0900
Subject: [PATCH 02/08] ARM: shmobile: Remove sh7372 use of <mach/hardware.h>
In-Reply-To: <20130724033715.30567.82782.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
Message-ID: <20130724033734.30567.25082.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove unused <mach/hardware.h> on sh7372.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-sh7372.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/setup-sh7372.c
+++ work/arch/arm/mach-shmobile/setup-sh7372.c	2013-07-23 16:00:52.000000000 +0900
@@ -35,7 +35,6 @@
 #include <linux/dma-mapping.h>
 #include <linux/platform_data/sh_ipmmu.h>
 #include <mach/dma-register.h>
-#include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <mach/sh7372.h>
 #include <mach/common.h>


From magnus.damm at gmail.com  Tue Jul 23 23:37:43 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 24 Jul 2013 12:37:43 +0900
Subject: [PATCH 03/08] ARM: shmobile: Remove EMEV2 use of <mach/hardware.h>
In-Reply-To: <20130724033715.30567.82782.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
Message-ID: <20130724033743.30567.57468.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove unused <mach/hardware.h> on EMEV2.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-emev2.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/setup-emev2.c
+++ work/arch/arm/mach-shmobile/setup-emev2.c	2013-07-23 16:01:44.000000000 +0900
@@ -27,7 +27,6 @@
 #include <linux/input.h>
 #include <linux/io.h>
 #include <linux/irqchip/arm-gic.h>
-#include <mach/hardware.h>
 #include <mach/common.h>
 #include <mach/emev2.h>
 #include <mach/irqs.h>


From magnus.damm at gmail.com  Tue Jul 23 23:37:52 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 24 Jul 2013 12:37:52 +0900
Subject: [PATCH 04/08] ARM: shmobile: Remove r8a7779 use of <mach/hardware.h>
In-Reply-To: <20130724033715.30567.82782.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
Message-ID: <20130724033752.30567.70305.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove unused <mach/hardware.h> on r8a7779.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-r8a7779.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/setup-r8a7779.c
+++ work/arch/arm/mach-shmobile/setup-r8a7779.c	2013-07-23 16:02:42.000000000 +0900
@@ -36,7 +36,6 @@
 #include <linux/usb/ehci_pdriver.h>
 #include <linux/usb/ohci_pdriver.h>
 #include <linux/pm_runtime.h>
-#include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>


From magnus.damm at gmail.com  Tue Jul 23 23:38:01 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 24 Jul 2013 12:38:01 +0900
Subject: [PATCH 05/08] ARM: shmobile: Remove AG5EVM use of <mach/hardware.h>
In-Reply-To: <20130724033715.30567.82782.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
Message-ID: <20130724033801.30567.89261.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove unused <mach/hardware.h> on AG5EVM.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-ag5evm.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/board-ag5evm.c
+++ work/arch/arm/mach-shmobile/board-ag5evm.c	2013-07-23 16:03:31.000000000 +0900
@@ -47,7 +47,6 @@
 #include <video/sh_mobile_lcdc.h>
 #include <video/sh_mipi_dsi.h>
 #include <sound/sh_fsi.h>
-#include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <mach/sh73a0.h>
 #include <mach/common.h>


From magnus.damm at gmail.com  Tue Jul 23 23:38:11 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 24 Jul 2013 12:38:11 +0900
Subject: [PATCH 06/08] ARM: shmobile: Remove Kota2 use of <mach/hardware.h>
In-Reply-To: <20130724033715.30567.82782.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
Message-ID: <20130724033811.30567.3910.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove unused <mach/hardware.h> on Kota2.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-kota2.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/board-kota2.c
+++ work/arch/arm/mach-shmobile/board-kota2.c	2013-07-23 16:04:07.000000000 +0900
@@ -44,7 +44,6 @@
 #include <linux/mmc/sh_mmcif.h>
 #include <linux/mfd/tmio.h>
 #include <linux/mmc/sh_mobile_sdhi.h>
-#include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <mach/sh73a0.h>
 #include <mach/common.h>


From magnus.damm at gmail.com  Tue Jul 23 23:38:20 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 24 Jul 2013 12:38:20 +0900
Subject: [PATCH 07/08] ARM: shmobile: Remove Marzen use of <mach/hardware.h>
In-Reply-To: <20130724033715.30567.82782.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
Message-ID: <20130724033820.30567.27069.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove unused <mach/hardware.h> on Marzen.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-marzen.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/board-marzen.c
+++ work/arch/arm/mach-shmobile/board-marzen.c	2013-07-23 16:05:06.000000000 +0900
@@ -37,7 +37,6 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/mfd/tmio.h>
-#include <mach/hardware.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>
 #include <mach/irqs.h>


From magnus.damm at gmail.com  Tue Jul 23 23:38:29 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 24 Jul 2013 12:38:29 +0900
Subject: [PATCH 08/08] ARM: shmobile: Remove include <mach/hardware.h>
In-Reply-To: <20130724033715.30567.82782.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
Message-ID: <20130724033829.30567.27355.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Now when no one is using this file, remove <mach/hardware.h>.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/include/mach/hardware.h |    4 ----
 1 file changed, 4 deletions(-)

--- 0001/arch/arm/mach-shmobile/include/mach/hardware.h
+++ /dev/null	2013-06-03 21:41:10.638032047 +0900
@@ -1,4 +0,0 @@
-#ifndef __ASM_MACH_HARDWARE_H
-#define __ASM_MACH_HARDWARE_H
-
-#endif /* __ASM_MACH_HARDWARE_H */


From sachin.kamat at linaro.org  Tue Jul 23 23:38:41 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Wed, 24 Jul 2013 09:08:41 +0530
Subject: [PATCH] ARM: dts: Add USB host node for Exynos4
In-Reply-To: <1374600763-19466-1-git-send-email-tobetter@gmail.com>
References: <1374600763-19466-1-git-send-email-tobetter@gmail.com>
Message-ID: <CAK9yfHz10ao32Y4VRsvjNLe+zaq+hYk4KVgtwFgSLDsN-9Pfpw@mail.gmail.com>

On 23 July 2013 23:02, Dongjin Kim <tobetter at gmail.com> wrote:
> This patch adds EHCI and OHCI host device nodes for Exynos4.
>
> Signed-off-by: Dongjin Kim <tobetter at gmail.com>
> ---
>  arch/arm/boot/dts/exynos4.dtsi |   20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index 3f94fe8..1cdbf89 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -155,6 +155,26 @@
>                 status = "disabled";
>         };
>
> +       ehci at 12580000 {
> +               compatible = "samsung,exynos4210-ehci";
> +               reg = <0x12580000 0x100>;
> +               interrupts = <0 70 0>;
> +               status = "disabled";
> +
> +               clocks = <&clock 304>;
> +               clock-names = "usbhost";
> +       };
> +
> +       ohci at 12590000 {
> +               compatible = "samsung,exynos4210-ohci";
> +               reg = <0x12580000 0x100>;

Register value and node name do not match. Typo?


> +               interrupts = <0 70 0>;
> +               status = "disabled";
> +
> +               clocks = <&clock 304>;
> +               clock-names = "usbhost";
> +       };
> +
>         mfc: codec at 13400000 {
>                 compatible = "samsung,mfc-v5";
>                 reg = <0x13400000 0x10000>;
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
With warm regards,
Sachin


From sachin.kamat at linaro.org  Tue Jul 23 23:31:33 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Wed, 24 Jul 2013 09:01:33 +0530
Subject: [PATCH v3 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
Message-ID: <1374636693-32336-1-git-send-email-sachin.kamat@linaro.org>

With the recent cleanup in Exynos platform code notably commits
17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
Exynos4412 which have more than the default number of GPIOs. Thus define
this number in KConfig file which takes care of current SoC requirements
and provides scope for GPIO expanders. Without this patch we get the following
errors during boot:

gpiochip_add: gpios 251..258 (gpv0) failed to register
samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
error code: -22
samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
Cc: Tomasz Figa <t.figa at samsung.com>
---
Changes since v2:
Changed the default number to 512 to accomodate GPIO exapnders.
---
 arch/arm/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ccc388d..b3c4fa4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1601,6 +1601,7 @@ config ARCH_NR_GPIO
 	int
 	default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
 	default 512 if SOC_OMAP5
+	default 512 if ARCH_EXYNOS
 	default 512 if ARCH_KEYSTONE
 	default 392 if ARCH_U8500
 	default 352 if ARCH_VT8500
-- 
1.7.9.5



From rizhao at nvidia.com  Wed Jul 24 00:09:53 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Wed, 24 Jul 2013 12:09:53 +0800
Subject: [PATCH 0/9] ARM: tegra: move to generic DMA DT binding
Message-ID: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>

The patch series aim to move apbdma to generic DT binding.

Changes:
- It add dmas/dma-names properties while leave
  nvidia,dma-request-selector to be compatible.
- update apbdma driver and dma client drivers
- ASoC tegra adds a new struct to pass device and dma-name.
- at last, remove legacy nvidia,dma-request-selector

Richard Zhao (9):
  ARM: dts: add generic DMA DT binding for tegra apbdma
  dma: tegra20-apbdma: move to generic device tree bindings
  spi: tegra114: move to generic dma DT binding
  spi: tegra20-slink: move to generic dma DT binding
  spi: tegra20-sflash: move to generic dma DT binding
  serial: tegra: move to generic dma DT binding
  ASoC: tegra: move to generic DMA DT binding
  ARM: dts: tegra: remove legacy nvidia,dma-request-selector properties
  dma: tegra20-apbdma: remove legacy nvidia,dma-request-selector support

 .../devicetree/bindings/dma/tegra20-apbdma.txt     |  1 +
 .../bindings/serial/nvidia,tegra20-hsuart.txt      |  8 ++--
 .../bindings/sound/nvidia,tegra20-ac97.txt         |  8 ++--
 .../bindings/sound/nvidia,tegra20-i2s.txt          |  8 ++--
 .../bindings/sound/nvidia,tegra30-ahub.txt         | 12 +++---
 .../bindings/spi/nvidia,tegra114-spi.txt           | 10 +++--
 .../bindings/spi/nvidia,tegra20-sflash.txt         | 10 +++--
 .../bindings/spi/nvidia,tegra20-slink.txt          | 10 +++--
 arch/arm/boot/dts/tegra114.dtsi                    | 41 +++++++++++++-------
 arch/arm/boot/dts/tegra20.dtsi                     | 40 +++++++++++++-------
 arch/arm/boot/dts/tegra30.dtsi                     | 37 ++++++++++++------
 drivers/dma/tegra20-apb-dma.c                      | 38 ++++++++++++++++++-
 drivers/spi/spi-tegra114.c                         | 16 +++-----
 drivers/spi/spi-tegra20-slink.c                    | 16 +++-----
 drivers/tty/serial/serial-tegra.c                  | 16 +-------
 sound/soc/tegra/tegra20_ac97.c                     | 17 +++------
 sound/soc/tegra/tegra20_ac97.h                     |  2 +
 sound/soc/tegra/tegra20_i2s.c                      | 26 ++++---------
 sound/soc/tegra/tegra20_i2s.h                      |  2 +
 sound/soc/tegra/tegra30_ahub.c                     | 25 +++++-------
 sound/soc/tegra/tegra30_ahub.h                     | 11 +++---
 sound/soc/tegra/tegra30_i2s.c                      | 44 +++++++++++++++-------
 sound/soc/tegra/tegra30_i2s.h                      |  2 +
 sound/soc/tegra/tegra_pcm.c                        | 14 +++++++
 sound/soc/tegra/tegra_pcm.h                        | 13 +++++++
 25 files changed, 260 insertions(+), 167 deletions(-)

-- 
1.8.1.5



From rizhao at nvidia.com  Wed Jul 24 00:09:55 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Wed, 24 Jul 2013 12:09:55 +0800
Subject: [PATCH 2/9] dma: tegra20-apbdma: move to generic device tree bindings
In-Reply-To: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
Message-ID: <1374639002-16753-3-git-send-email-rizhao@nvidia.com>

Update tegra20-apbdma driver to adopt generic DMA device tree bindings.
It calls of_dma_controller_register() with of_dma_simple_xlate to get
the generic DMA device tree helper support. The #dma-cells for apbdma
must be 1, which is slave ID.

The existing nvidia,dma-request-selector still works there, and the
support will be removed after all clients get converted to generic DMA
device tree helper.

Signed-off-by: Richard Zhao <rizhao at nvidia.com>
---
 drivers/dma/tegra20-apb-dma.c | 46 +++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 44 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index f137914..0e12f78 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -29,6 +29,7 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
+#include <linux/of_dma.h>
 #include <linux/platform_device.h>
 #include <linux/pm.h>
 #include <linux/pm_runtime.h>
@@ -199,6 +200,7 @@ struct tegra_dma_channel {
 	void			*callback_param;
 
 	/* Channel-slave specific configuration */
+	int slave_id;
 	struct dma_slave_config dma_sconfig;
 	struct tegra_dma_channel_regs	channel_reg;
 };
@@ -219,6 +221,8 @@ struct tegra_dma {
 	struct tegra_dma_channel channels[0];
 };
 
+static struct platform_driver tegra_dmac_driver;
+
 static inline void tdma_write(struct tegra_dma *tdma, u32 reg, u32 val)
 {
 	writel(val, tdma->base_addr + reg);
@@ -339,6 +343,14 @@ static int tegra_dma_slave_config(struct dma_chan *dc,
 	}
 
 	memcpy(&tdc->dma_sconfig, sconfig, sizeof(*sconfig));
+
+	/* If we didn't get slave_id from DT when request channel, use the one
+	 * passed here.
+	 * It makes compatible with legacy nvidia,dma-request-selector.
+	 */
+	if (tdc->slave_id == -EINVAL)
+		tdc->slave_id = sconfig->slave_id;
+
 	tdc->config_init = true;
 	return 0;
 }
@@ -943,7 +955,7 @@ static struct dma_async_tx_descriptor *tegra_dma_prep_slave_sg(
 	ahb_seq |= TEGRA_APBDMA_AHBSEQ_BUS_WIDTH_32;
 
 	csr |= TEGRA_APBDMA_CSR_ONCE | TEGRA_APBDMA_CSR_FLOW;
-	csr |= tdc->dma_sconfig.slave_id << TEGRA_APBDMA_CSR_REQ_SEL_SHIFT;
+	csr |= tdc->slave_id << TEGRA_APBDMA_CSR_REQ_SEL_SHIFT;
 	if (flags & DMA_PREP_INTERRUPT)
 		csr |= TEGRA_APBDMA_CSR_IE_EOC;
 
@@ -1087,7 +1099,7 @@ struct dma_async_tx_descriptor *tegra_dma_prep_dma_cyclic(
 	csr |= TEGRA_APBDMA_CSR_FLOW;
 	if (flags & DMA_PREP_INTERRUPT)
 		csr |= TEGRA_APBDMA_CSR_IE_EOC;
-	csr |= tdc->dma_sconfig.slave_id << TEGRA_APBDMA_CSR_REQ_SEL_SHIFT;
+	csr |= tdc->slave_id << TEGRA_APBDMA_CSR_REQ_SEL_SHIFT;
 
 	apb_seq |= TEGRA_APBDMA_APBSEQ_WRAP_WORD_1;
 
@@ -1209,6 +1221,23 @@ static void tegra_dma_free_chan_resources(struct dma_chan *dc)
 	clk_disable_unprepare(tdma->dma_clk);
 }
 
+static bool tegra_dma_filter_fn(struct dma_chan *dc, void *param)
+{
+	if (dc->device->dev->driver == &tegra_dmac_driver.driver) {
+		struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
+		unsigned req = *(unsigned *)param;
+
+		tdc->slave_id = req;
+
+		return true;
+	}
+	return false;
+}
+
+static struct of_dma_filter_info tegra_dma_info = {
+	.filter_fn = tegra_dma_filter_fn,
+};
+
 /* Tegra20 specific DMA controller information */
 static const struct tegra_dma_chip_data tegra20_dma_chip_data = {
 	.nr_channels		= 16,
@@ -1345,6 +1374,7 @@ static int tegra_dma_probe(struct platform_device *pdev)
 				&tdma->dma_dev.channels);
 		tdc->tdma = tdma;
 		tdc->id = i;
+		tdc->slave_id = -EINVAL;
 
 		tasklet_init(&tdc->tasklet, tegra_dma_tasklet,
 				(unsigned long)tdc);
@@ -1378,10 +1408,21 @@ static int tegra_dma_probe(struct platform_device *pdev)
 		goto err_irq;
 	}
 
+	ret = of_dma_controller_register(pdev->dev.of_node,
+					of_dma_simple_xlate, &tegra_dma_info);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"Tegra20 APB DMA controller registration failed %d\n",
+			ret);
+		goto err_of_dma;
+	}
+
 	dev_info(&pdev->dev, "Tegra20 APB DMA driver register %d channels\n",
 			cdata->nr_channels);
 	return 0;
 
+err_of_dma:
+	dma_async_device_unregister(&tdma->dma_dev);
 err_irq:
 	while (--i >= 0) {
 		struct tegra_dma_channel *tdc = &tdma->channels[i];
@@ -1401,6 +1442,7 @@ static int tegra_dma_remove(struct platform_device *pdev)
 	int i;
 	struct tegra_dma_channel *tdc;
 
+	of_dma_controller_free(pdev->dev.of_node);
 	dma_async_device_unregister(&tdma->dma_dev);
 
 	for (i = 0; i < tdma->chip_data->nr_channels; ++i) {
-- 
1.8.1.5



From rizhao at nvidia.com  Wed Jul 24 00:09:54 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Wed, 24 Jul 2013 12:09:54 +0800
Subject: [PATCH 1/9] ARM: dts: add generic DMA DT binding for tegra apbdma
In-Reply-To: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
Message-ID: <1374639002-16753-2-git-send-email-rizhao@nvidia.com>

All Tegra device drivers will soon move to generic DMA device tree bindings.
Add the required properties to the Tegra DT files to support that. The legacy
property nvidia,dma-request-selector will be removed after all drivers have
been converted, in order to maintain bisectability.

Changes:
 - Add '#dma-cells' for apbdma nodes
 - And properties 'dmas' and 'dma-names' for apbdma client nodes
 - update apbdma DT binding doc

Signed-off-by: Richard Zhao <rizhao at nvidia.com>
---
 .../devicetree/bindings/dma/tegra20-apbdma.txt     |  1 +
 arch/arm/boot/dts/tegra114.dtsi                    | 27 ++++++++++++++++++++++
 arch/arm/boot/dts/tegra20.dtsi                     | 27 ++++++++++++++++++++++
 arch/arm/boot/dts/tegra30.dtsi                     | 25 ++++++++++++++++++++
 4 files changed, 80 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt b/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
index 90fa7da..e4fc695 100644
--- a/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
+++ b/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
@@ -5,6 +5,7 @@ Required properties:
 - reg: Should contain DMA registers location and length. This shuld include
   all of the per-channel registers.
 - interrupts: Should contain all of the per-channel DMA interrupts.
+- #dma-cells: Must be <1>, which specifies the dma request.
 
 Examples:
 
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index abf6c40..b133c62 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -81,6 +81,7 @@
 			     <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&tegra_car TEGRA114_CLK_APBDMA>;
+		#dma-cells = <1>;
 	};
 
 	ahb: ahb {
@@ -125,6 +126,8 @@
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 8>;
+		dmas = <&apbdma 8>;
+		dma-names = "rx-tx";
 		status = "disabled";
 		clocks = <&tegra_car TEGRA114_CLK_UARTA>;
 	};
@@ -135,6 +138,8 @@
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 9>;
+		dmas = <&apbdma 9>;
+		dma-names = "rx-tx";
 		status = "disabled";
 		clocks = <&tegra_car TEGRA114_CLK_UARTB>;
 	};
@@ -145,6 +150,8 @@
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 10>;
+		dmas = <&apbdma 10>;
+		dma-names = "rx-tx";
 		status = "disabled";
 		clocks = <&tegra_car TEGRA114_CLK_UARTC>;
 	};
@@ -155,6 +162,8 @@
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 19>;
+		dmas = <&apbdma 19>;
+		dma-names = "rx-tx";
 		status = "disabled";
 		clocks = <&tegra_car TEGRA114_CLK_UARTD>;
 	};
@@ -227,6 +236,8 @@
 		reg = <0x7000d400 0x200>;
 		interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 15>;
+		dmas = <&apbdma 15>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA114_CLK_SBC1>;
@@ -239,6 +250,8 @@
 		reg = <0x7000d600 0x200>;
 		interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 16>;
+		dmas = <&apbdma 16>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA114_CLK_SBC2>;
@@ -251,6 +264,8 @@
 		reg = <0x7000d800 0x200>;
 		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 17>;
+		dmas = <&apbdma 17>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA114_CLK_SBC3>;
@@ -263,6 +278,8 @@
 		reg = <0x7000da00 0x200>;
 		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 18>;
+		dmas = <&apbdma 18>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA114_CLK_SBC4>;
@@ -275,6 +292,8 @@
 		reg = <0x7000dc00 0x200>;
 		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 27>;
+		dmas = <&apbdma 27>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA114_CLK_SBC5>;
@@ -287,6 +306,8 @@
 		reg = <0x7000de00 0x200>;
 		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 28>;
+		dmas = <&apbdma 28>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA114_CLK_SBC6>;
@@ -337,6 +358,12 @@
 			<&apbdma 3>, <&apbdma 4>, <&apbdma 6>, <&apbdma 7>,
 			<&apbdma 12>, <&apbdma 13>, <&apbdma 14>,
 			<&apbdma 29>;
+		dmas = <&apbdma 1>, <&apbdma 2>, <&apbdma 3>, <&apbdma 4>,
+			<&apbdma 6>, <&apbdma 7>, <&apbdma 12>, <&apbdma 13>,
+			<&apbdma 14>, <&apbdma 29>;
+		dma-names = "channel0", "channel1", "channel2", "channel3",
+			"channel4", "channel5", "channel6", "channel7",
+			"channel8", "channel9";
 		clocks = <&tegra_car TEGRA114_CLK_D_AUDIO>,
 			 <&tegra_car TEGRA114_CLK_APBIF>,
 			 <&tegra_car TEGRA114_CLK_I2S0>,
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 9653fd8..0fe7f37 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -182,6 +182,7 @@
 			     <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&tegra_car TEGRA20_CLK_APBDMA>;
+		#dma-cells = <1>;
 	};
 
 	ahb {
@@ -223,6 +224,8 @@
 		reg = <0x70002000 0x200>;
 		interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 12>;
+		dmas = <&apbdma 12>;
+		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_AC97>;
 		status = "disabled";
 	};
@@ -232,6 +235,8 @@
 		reg = <0x70002800 0x200>;
 		interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 2>;
+		dmas = <&apbdma 2>;
+		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_I2S1>;
 		status = "disabled";
 	};
@@ -241,6 +246,8 @@
 		reg = <0x70002a00 0x200>;
 		interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 1>;
+		dmas = <&apbdma 1>;
+		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_I2S2>;
 		status = "disabled";
 	};
@@ -258,6 +265,8 @@
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 8>;
+		dmas = <&apbdma 8>;
+		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_UARTA>;
 		status = "disabled";
 	};
@@ -268,6 +277,8 @@
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 9>;
+		dmas = <&apbdma 9>;
+		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_UARTB>;
 		status = "disabled";
 	};
@@ -278,6 +289,8 @@
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 10>;
+		dmas = <&apbdma 10>;
+		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_UARTC>;
 		status = "disabled";
 	};
@@ -288,6 +301,8 @@
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 19>;
+		dmas = <&apbdma 19>;
+		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_UARTD>;
 		status = "disabled";
 	};
@@ -298,6 +313,8 @@
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 20>;
+		dmas = <&apbdma 20>;
+		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_UARTE>;
 		status = "disabled";
 	};
@@ -334,6 +351,8 @@
 		reg = <0x7000c380 0x80>;
 		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 11>;
+		dmas = <&apbdma 11>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA20_CLK_SPI>;
@@ -381,6 +400,8 @@
 		reg = <0x7000d400 0x200>;
 		interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 15>;
+		dmas = <&apbdma 15>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA20_CLK_SBC1>;
@@ -392,6 +413,8 @@
 		reg = <0x7000d600 0x200>;
 		interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 16>;
+		dmas = <&apbdma 16>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA20_CLK_SBC2>;
@@ -403,6 +426,8 @@
 		reg = <0x7000d800 0x200>;
 		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 17>;
+		dmas = <&apbdma 17>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA20_CLK_SBC3>;
@@ -414,6 +439,8 @@
 		reg = <0x7000da00 0x200>;
 		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 18>;
+		dmas = <&apbdma 18>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA20_CLK_SBC4>;
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index d8783f0..c266316 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -201,6 +201,7 @@
 			     <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&tegra_car TEGRA30_CLK_APBDMA>;
+		#dma-cells = <1>;
 	};
 
 	ahb: ahb {
@@ -245,6 +246,8 @@
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 8>;
+		dmas = <&apbdma 8>;
+		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA30_CLK_UARTA>;
 		status = "disabled";
 	};
@@ -255,6 +258,8 @@
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 9>;
+		dmas = <&apbdma 9>;
+		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA30_CLK_UARTB>;
 		status = "disabled";
 	};
@@ -265,6 +270,8 @@
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 10>;
+		dmas = <&apbdma 10>;
+		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA30_CLK_UARTC>;
 		status = "disabled";
 	};
@@ -275,6 +282,8 @@
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 19>;
+		dmas = <&apbdma 19>;
+		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA30_CLK_UARTD>;
 		status = "disabled";
 	};
@@ -285,6 +294,8 @@
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 20>;
+		dmas = <&apbdma 20>;
+		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA30_CLK_UARTE>;
 		status = "disabled";
 	};
@@ -369,6 +380,8 @@
 		reg = <0x7000d400 0x200>;
 		interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 15>;
+		dmas = <&apbdma 15>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA30_CLK_SBC1>;
@@ -380,6 +393,8 @@
 		reg = <0x7000d600 0x200>;
 		interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 16>;
+		dmas = <&apbdma 16>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA30_CLK_SBC2>;
@@ -391,6 +406,8 @@
 		reg = <0x7000d800 0x200>;
 		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 17>;
+		dmas = <&apbdma 17>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA30_CLK_SBC3>;
@@ -402,6 +419,8 @@
 		reg = <0x7000da00 0x200>;
 		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 18>;
+		dmas = <&apbdma 18>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA30_CLK_SBC4>;
@@ -413,6 +432,8 @@
 		reg = <0x7000dc00 0x200>;
 		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 27>;
+		dmas = <&apbdma 27>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA30_CLK_SBC5>;
@@ -424,6 +445,8 @@
 		reg = <0x7000de00 0x200>;
 		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 28>;
+		dmas = <&apbdma 28>;
+		dma-names = "rx-tx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&tegra_car TEGRA30_CLK_SBC6>;
@@ -470,6 +493,8 @@
 		       0x70080200 0x100>;
 		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		nvidia,dma-request-selector = <&apbdma 1>;
+		dmas = <&apbdma 1>, <&apbdma 2>, <&apbdma 3>, <&apbdma 4>;
+		dma-names = "channel0", "channel1", "channel2", "channel3";
 		clocks = <&tegra_car TEGRA30_CLK_D_AUDIO>,
 			 <&tegra_car TEGRA30_CLK_APBIF>,
 			 <&tegra_car TEGRA30_CLK_I2S0>,
-- 
1.8.1.5



From rizhao at nvidia.com  Wed Jul 24 00:09:56 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Wed, 24 Jul 2013 12:09:56 +0800
Subject: [PATCH 3/9] spi: tegra114: move to generic dma DT binding
In-Reply-To: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
Message-ID: <1374639002-16753-4-git-send-email-rizhao@nvidia.com>

- driver: remove use of nvidia,dma-request-selector
	  use dma_request_slave_channel to request channel
- if dmas/dma-names are missing, it still supports cpu based transfer
- update binding doc and specify dmas/dma-names properties as optional

Signed-off-by: Richard Zhao <rizhao at nvidia.com>
---
 .../devicetree/bindings/spi/nvidia,tegra114-spi.txt      | 10 +++++++---
 drivers/spi/spi-tegra114.c                               | 16 +++++-----------
 2 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
index 91ff771..92e1a9a 100644
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
@@ -4,11 +4,14 @@ Required properties:
 - compatible : should be "nvidia,tegra114-spi".
 - reg: Should contain SPI registers location and length.
 - interrupts: Should contain SPI interrupts.
-- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
-  request selector for this SPI controller.
 - This is also require clock named "spi" as per binding document
   Documentation/devicetree/bindings/clock/clock-bindings.txt
 
+Optional properties:
+- dmas : The Tegra DMA controller's phandle and request selector for
+  this SPI controller.
+- dma-names : Should be "rx-tx".
+
 Recommended properties:
 - spi-max-frequency: Definition as per
                      Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -18,7 +21,8 @@ spi at 7000d600 {
 	compatible = "nvidia,tegra114-spi";
 	reg = <0x7000d600 0x200>;
 	interrupts = <0 82 0x04>;
-	nvidia,dma-request-selector = <&apbdma 16>;
+	dmas = <&apbdma 16>;
+	dma-names = "rx-tx";
 	spi-max-frequency = <25000000>;
 	#address-cells = <1>;
 	#size-cells = <0>;
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index e8f542a..baff559 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -177,7 +177,7 @@ struct tegra_spi_data {
 	void __iomem				*base;
 	phys_addr_t				phys;
 	unsigned				irq;
-	int					dma_req_sel;
+	bool					use_dma;
 	u32					spi_max_frequency;
 	u32					cur_speed;
 
@@ -599,11 +599,8 @@ static int tegra_spi_init_dma_param(struct tegra_spi_data *tspi,
 	dma_addr_t dma_phys;
 	int ret;
 	struct dma_slave_config dma_sconfig;
-	dma_cap_mask_t mask;
 
-	dma_cap_zero(mask);
-	dma_cap_set(DMA_SLAVE, mask);
-	dma_chan = dma_request_channel(mask, NULL, NULL);
+	dma_chan = dma_request_slave_channel(tspi->dev, "rx-tx");
 	if (!dma_chan) {
 		dev_err(tspi->dev,
 			"Dma channel is not available, will try later\n");
@@ -618,7 +615,6 @@ static int tegra_spi_init_dma_param(struct tegra_spi_data *tspi,
 		return -ENOMEM;
 	}
 
-	dma_sconfig.slave_id = tspi->dma_req_sel;
 	if (dma_to_memory) {
 		dma_sconfig.src_addr = tspi->phys + SPI_RX_FIFO;
 		dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
@@ -1012,11 +1008,9 @@ static void tegra_spi_parse_dt(struct platform_device *pdev,
 	struct tegra_spi_data *tspi)
 {
 	struct device_node *np = pdev->dev.of_node;
-	u32 of_dma[2];
 
-	if (of_property_read_u32_array(np, "nvidia,dma-request-selector",
-				of_dma, 2) >= 0)
-		tspi->dma_req_sel = of_dma[1];
+	if (of_find_property(np, "dmas", NULL))
+		tspi->use_dma = true;
 
 	if (of_property_read_u32(np, "spi-max-frequency",
 				&tspi->spi_max_frequency))
@@ -1093,7 +1087,7 @@ static int tegra_spi_probe(struct platform_device *pdev)
 	tspi->max_buf_size = SPI_FIFO_DEPTH << 2;
 	tspi->dma_buf_size = DEFAULT_SPI_DMA_BUF_LEN;
 
-	if (tspi->dma_req_sel) {
+	if (tspi->use_dma) {
 		ret = tegra_spi_init_dma_param(tspi, true);
 		if (ret < 0) {
 			dev_err(&pdev->dev, "RxDma Init failed, err %d\n", ret);
-- 
1.8.1.5



From rizhao at nvidia.com  Wed Jul 24 00:09:58 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Wed, 24 Jul 2013 12:09:58 +0800
Subject: [PATCH 5/9] spi: tegra20-sflash: move to generic dma DT binding
In-Reply-To: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
Message-ID: <1374639002-16753-6-git-send-email-rizhao@nvidia.com>

update binding doc.

Signed-off-by: Richard Zhao <rizhao at nvidia.com>
---
 .../devicetree/bindings/spi/nvidia,tegra20-sflash.txt          | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
index 7b53da5..fa22d1b 100644
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
@@ -4,8 +4,11 @@ Required properties:
 - compatible : should be "nvidia,tegra20-sflash".
 - reg: Should contain SFLASH registers location and length.
 - interrupts: Should contain SFLASH interrupts.
-- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
-  request selector for this SFLASH controller.
+
+Optional properties:
+- dmas : The Tegra DMA controller's phandle and request selector for
+  this SFLASH controller.
+- dma-names : Should be "rx-tx".
 
 Recommended properties:
 - spi-max-frequency: Definition as per
@@ -17,7 +20,8 @@ spi at 7000c380 {
 	compatible = "nvidia,tegra20-sflash";
 	reg = <0x7000c380 0x80>;
 	interrupts = <0 39 0x04>;
-	nvidia,dma-request-selector = <&apbdma 16>;
+	dmas = <&apbdma 16>;
+	dma-names = "rx-tx";
 	spi-max-frequency = <25000000>;
 	#address-cells = <1>;
 	#size-cells = <0>;
-- 
1.8.1.5



From rizhao at nvidia.com  Wed Jul 24 00:09:57 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Wed, 24 Jul 2013 12:09:57 +0800
Subject: [PATCH 4/9] spi: tegra20-slink: move to generic dma DT binding
In-Reply-To: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
Message-ID: <1374639002-16753-5-git-send-email-rizhao@nvidia.com>

- driver: remove use of nvidia,dma-request-selector
	  use dma_request_slave_channel to request channel
- if dmas/dma-names are missing, it still supports cpu based transfer
- update binding doc and specify dmas/dma-names properties as optional

Signed-off-by: Richard Zhao <rizhao at nvidia.com>
---
 .../devicetree/bindings/spi/nvidia,tegra20-slink.txt     | 10 +++++++---
 drivers/spi/spi-tegra20-slink.c                          | 16 +++++-----------
 2 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
index eefe15e..ae43bd1 100644
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
@@ -4,8 +4,11 @@ Required properties:
 - compatible : should be "nvidia,tegra20-slink", "nvidia,tegra30-slink".
 - reg: Should contain SLINK registers location and length.
 - interrupts: Should contain SLINK interrupts.
-- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
-  request selector for this SLINK controller.
+
+Optional properties:
+- dmas : The Tegra DMA controller's phandle and request selector for
+  this SLINK controller.
+- dma-names : Should be "rx-tx".
 
 Recommended properties:
 - spi-max-frequency: Definition as per
@@ -17,7 +20,8 @@ spi at 7000d600 {
 	compatible = "nvidia,tegra20-slink";
 	reg = <0x7000d600 0x200>;
 	interrupts = <0 82 0x04>;
-	nvidia,dma-request-selector = <&apbdma 16>;
+	dmas = <&apbdma 16>;
+	dma-names = "rx-tx";
 	spi-max-frequency = <25000000>;
 	#address-cells = <1>;
 	#size-cells = <0>;
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index 80490cc..278fb04 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -170,7 +170,7 @@ struct tegra_slink_data {
 	void __iomem				*base;
 	phys_addr_t				phys;
 	unsigned				irq;
-	int					dma_req_sel;
+	bool					use_dma;
 	u32					spi_max_frequency;
 	u32					cur_speed;
 
@@ -629,11 +629,8 @@ static int tegra_slink_init_dma_param(struct tegra_slink_data *tspi,
 	dma_addr_t dma_phys;
 	int ret;
 	struct dma_slave_config dma_sconfig;
-	dma_cap_mask_t mask;
 
-	dma_cap_zero(mask);
-	dma_cap_set(DMA_SLAVE, mask);
-	dma_chan = dma_request_channel(mask, NULL, NULL);
+	dma_chan = dma_request_slave_channel(tspi->dev, "rx-tx");
 	if (!dma_chan) {
 		dev_err(tspi->dev,
 			"Dma channel is not available, will try later\n");
@@ -648,7 +645,6 @@ static int tegra_slink_init_dma_param(struct tegra_slink_data *tspi,
 		return -ENOMEM;
 	}
 
-	dma_sconfig.slave_id = tspi->dma_req_sel;
 	if (dma_to_memory) {
 		dma_sconfig.src_addr = tspi->phys + SLINK_RX_FIFO;
 		dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
@@ -1034,11 +1030,9 @@ static irqreturn_t tegra_slink_isr(int irq, void *context_data)
 static void tegra_slink_parse_dt(struct tegra_slink_data *tspi)
 {
 	struct device_node *np = tspi->dev->of_node;
-	u32 of_dma[2];
 
-	if (of_property_read_u32_array(np, "nvidia,dma-request-selector",
-				of_dma, 2) >= 0)
-		tspi->dma_req_sel = of_dma[1];
+	if (of_find_property(np, "dmas", NULL))
+		tspi->use_dma = true;
 
 	if (of_property_read_u32(np, "spi-max-frequency",
 					&tspi->spi_max_frequency))
@@ -1132,7 +1126,7 @@ static int tegra_slink_probe(struct platform_device *pdev)
 	tspi->max_buf_size = SLINK_FIFO_DEPTH << 2;
 	tspi->dma_buf_size = DEFAULT_SPI_DMA_BUF_LEN;
 
-	if (tspi->dma_req_sel) {
+	if (tspi->use_dma) {
 		ret = tegra_slink_init_dma_param(tspi, true);
 		if (ret < 0) {
 			dev_err(&pdev->dev, "RxDma Init failed, err %d\n", ret);
-- 
1.8.1.5



From rizhao at nvidia.com  Wed Jul 24 00:09:59 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Wed, 24 Jul 2013 12:09:59 +0800
Subject: [PATCH 6/9] serial: tegra: move to generic dma DT binding
In-Reply-To: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
Message-ID: <1374639002-16753-7-git-send-email-rizhao@nvidia.com>

- driver: remove use of nvidia,dma-request-selector
	  use dma_request_slave_channel to request channel
- update binding doc

Signed-off-by: Richard Zhao <rizhao at nvidia.com>
---
 .../devicetree/bindings/serial/nvidia,tegra20-hsuart.txt |  8 +++++---
 drivers/tty/serial/serial-tegra.c                        | 16 +---------------
 2 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
index 392a449..1ed2f48 100644
--- a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
+++ b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
@@ -4,8 +4,9 @@ Required properties:
 - compatible : should be "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart".
 - reg: Should contain UART controller registers location and length.
 - interrupts: Should contain UART controller interrupts.
-- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
-  request selector for this UART controller.
+- dmas : The Tegra DMA controller's phandle and request selector for
+  this UART controller.
+- dma-names : Should be "rx-tx";
 
 Optional properties:
 - nvidia,enable-modem-interrupt: Enable modem interrupts. Should be enable
@@ -18,7 +19,8 @@ serial at 70006000 {
 	reg = <0x70006000 0x40>;
 	reg-shift = <2>;
 	interrupts = <0 36 0x04>;
-	nvidia,dma-request-selector = <&apbdma 8>;
+	dmas = <&apbdma 8>;
+	dma-names = "rx-tx";
 	nvidia,enable-modem-interrupt;
 	status = "disabled";
 };
diff --git a/drivers/tty/serial/serial-tegra.c b/drivers/tty/serial/serial-tegra.c
index ee7c812..c8a7828 100644
--- a/drivers/tty/serial/serial-tegra.c
+++ b/drivers/tty/serial/serial-tegra.c
@@ -120,7 +120,6 @@ struct tegra_uart_port {
 	bool					rx_timeout;
 	int					rx_in_progress;
 	int					symb_bit;
-	int					dma_req_sel;
 
 	struct dma_chan				*rx_dma_chan;
 	struct dma_chan				*tx_dma_chan;
@@ -902,11 +901,8 @@ static int tegra_uart_dma_channel_allocate(struct tegra_uart_port *tup,
 	dma_addr_t dma_phys;
 	int ret;
 	struct dma_slave_config dma_sconfig;
-	dma_cap_mask_t mask;
 
-	dma_cap_zero(mask);
-	dma_cap_set(DMA_SLAVE, mask);
-	dma_chan = dma_request_channel(mask, NULL, NULL);
+	dma_chan = dma_request_slave_channel(tup->uport.dev, "rx-tx");
 	if (!dma_chan) {
 		dev_err(tup->uport.dev,
 			"Dma channel is not available, will try later\n");
@@ -930,7 +926,6 @@ static int tegra_uart_dma_channel_allocate(struct tegra_uart_port *tup,
 		dma_buf = tup->uport.state->xmit.buf;
 	}
 
-	dma_sconfig.slave_id = tup->dma_req_sel;
 	if (dma_to_memory) {
 		dma_sconfig.src_addr = tup->uport.mapbase;
 		dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
@@ -1214,17 +1209,8 @@ static int tegra_uart_parse_dt(struct platform_device *pdev,
 	struct tegra_uart_port *tup)
 {
 	struct device_node *np = pdev->dev.of_node;
-	u32 of_dma[2];
 	int port;
 
-	if (of_property_read_u32_array(np, "nvidia,dma-request-selector",
-				of_dma, 2) >= 0) {
-		tup->dma_req_sel = of_dma[1];
-	} else {
-		dev_err(&pdev->dev, "missing dma requestor in device tree\n");
-		return -EINVAL;
-	}
-
 	port = of_alias_get_id(np, "serial");
 	if (port < 0) {
 		dev_err(&pdev->dev, "failed to get alias id, errno %d\n", port);
-- 
1.8.1.5



From rizhao at nvidia.com  Wed Jul 24 00:10:00 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Wed, 24 Jul 2013 12:10:00 +0800
Subject: [PATCH 7/9] ASoC: tegra: move to generic DMA DT binding
In-Reply-To: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
Message-ID: <1374639002-16753-8-git-send-email-rizhao@nvidia.com>

- add tegra_dma_filter_data to specify dma info
  DMA DT binding needs the device that raise dma request and dma name
  to request a dma channel. tegra30_i2s is a special case. It should be ahub
  device and it also has dma name that cannot handled by ASoC dmaengine code.
  So we pass the info using filter data in snd_dmaengine_dai_dma_data.
- change i2s/ac97 drivers to use generic DT binding
- tegra30_i2s: alloc ahub tx/rx fifo at driver probe time

Signed-off-by: Richard Zhao <rizhao at nvidia.com>
---
 .../bindings/sound/nvidia,tegra20-ac97.txt         |  8 ++--
 .../bindings/sound/nvidia,tegra20-i2s.txt          |  8 ++--
 .../bindings/sound/nvidia,tegra30-ahub.txt         | 12 +++---
 sound/soc/tegra/tegra20_ac97.c                     | 17 +++------
 sound/soc/tegra/tegra20_ac97.h                     |  2 +
 sound/soc/tegra/tegra20_i2s.c                      | 26 ++++---------
 sound/soc/tegra/tegra20_i2s.h                      |  2 +
 sound/soc/tegra/tegra30_ahub.c                     | 25 +++++-------
 sound/soc/tegra/tegra30_ahub.h                     | 11 +++---
 sound/soc/tegra/tegra30_i2s.c                      | 44 +++++++++++++++-------
 sound/soc/tegra/tegra30_i2s.h                      |  2 +
 sound/soc/tegra/tegra_pcm.c                        | 14 +++++++
 sound/soc/tegra/tegra_pcm.h                        | 13 +++++++
 13 files changed, 107 insertions(+), 77 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt
index c145497..972f444 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt
@@ -4,8 +4,9 @@ Required properties:
 - compatible : "nvidia,tegra20-ac97"
 - reg : Should contain AC97 controller registers location and length
 - interrupts : Should contain AC97 interrupt
-- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
-  request selector for the AC97 controller
+- dmas : The Tegra DMA controller's phandle and request selector for
+  the AC97 controller
+- dma-names : Should be "rx-tx"
 - nvidia,codec-reset-gpio : The Tegra GPIO controller's phandle and the number
   of the GPIO used to reset the external AC97 codec
 - nvidia,codec-sync-gpio : The Tegra GPIO controller's phandle and the number
@@ -16,7 +17,8 @@ ac97 at 70002000 {
 	compatible = "nvidia,tegra20-ac97";
 	reg = <0x70002000 0x200>;
 	interrupts = <0 81 0x04>;
-	nvidia,dma-request-selector = <&apbdma 12>;
+	dmas = <&apbdma 12>;
+	dma-names = "rx-tx";
 	nvidia,codec-reset-gpio = <&gpio 170 0>;
 	nvidia,codec-sync-gpio = <&gpio 120 0>;
 };
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt
index 0df2b5c..61a6c8d 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt
@@ -4,8 +4,9 @@ Required properties:
 - compatible : "nvidia,tegra20-i2s"
 - reg : Should contain I2S registers location and length
 - interrupts : Should contain I2S interrupt
-- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
-  request selector for this I2S controller
+- dmas : The Tegra DMA controller's phandle and request selector
+  for this I2S controller
+- dma-names : Should be "rx-tx"
 
 Example:
 
@@ -13,5 +14,6 @@ i2s at 70002800 {
 	compatible = "nvidia,tegra20-i2s";
 	reg = <0x70002800 0x200>;
 	interrupts = < 45 >;
-	nvidia,dma-request-selector = < &apbdma 2 >;
+	dmas = < &apbdma 2 >;
+	dma-names = "rx-tx";
 };
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
index 0e5c12c..0ac563b 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
@@ -7,11 +7,10 @@ Required properties:
   - Tegra30 requires 2 entries, for the APBIF and AHUB/AUDIO register blocks.
   - Tegra114 requires an additional entry, for the APBIF2 register block.
 - interrupts : Should contain AHUB interrupt
-- nvidia,dma-request-selector : A list of the DMA channel specifiers. Each
-  entry contains the Tegra DMA controller's phandle and request selector.
-  If a single entry is present, the request selectors for the channels are
-  assumed to be contiguous, and increment from this value.
-  If multiple values are given, one value must be given per channel.
+- dmas : A list of the DMA channel specifiers. Each entry contains the Tegra
+  DMA controller's phandle and request selector.
+- dma-names : Should be a list of "channelx", in which x is 0, 1, 2, ...
+  One entry is required for each RX/TX FIFO pair that exists in hardware.
 - clocks : Must contain an entry for each required entry in clock-names.
 - clock-names : Must include the following entries:
   - Tegra30: Requires d_audio, apbif, i2s0, i2s1, i2s2, i2s3, i2s4, dam0,
@@ -34,7 +33,8 @@ ahub at 70080000 {
 	compatible = "nvidia,tegra30-ahub";
 	reg = <0x70080000 0x200 0x70080200 0x100>;
 	interrupts = < 0 103 0x04 >;
-	nvidia,dma-request-selector = <&apbdma 1>;
+	dmas = <&apbdma 1>, <&apbdma 2>, <&apbdma 3>, <&apbdma 4>;
+	dma-names = "channel0", "channel1", "channel2", "channel3";
 	clocks = <&tegra_car 106>, <&tegra_car 107>, <&tegra_car 30>,
 		<&tegra_car 11>, <&tegra_car 18>, <&tegra_car 101>,
 		<&tegra_car 102>, <&tegra_car 108>, <&tegra_car 109>,
diff --git a/sound/soc/tegra/tegra20_ac97.c b/sound/soc/tegra/tegra20_ac97.c
index 6c48662..935900a 100644
--- a/sound/soc/tegra/tegra20_ac97.c
+++ b/sound/soc/tegra/tegra20_ac97.c
@@ -313,7 +313,6 @@ static int tegra20_ac97_platform_probe(struct platform_device *pdev)
 {
 	struct tegra20_ac97 *ac97;
 	struct resource *mem;
-	u32 of_dma[2];
 	void __iomem *regs;
 	int ret = 0;
 
@@ -354,14 +353,6 @@ static int tegra20_ac97_platform_probe(struct platform_device *pdev)
 		goto err_clk_put;
 	}
 
-	if (of_property_read_u32_array(pdev->dev.of_node,
-				       "nvidia,dma-request-selector",
-				       of_dma, 2) < 0) {
-		dev_err(&pdev->dev, "No DMA resource\n");
-		ret = -ENODEV;
-		goto err_clk_put;
-	}
-
 	ac97->reset_gpio = of_get_named_gpio(pdev->dev.of_node,
 					     "nvidia,codec-reset-gpio", 0);
 	if (gpio_is_valid(ac97->reset_gpio)) {
@@ -386,12 +377,16 @@ static int tegra20_ac97_platform_probe(struct platform_device *pdev)
 	ac97->capture_dma_data.addr = mem->start + TEGRA20_AC97_FIFO_RX1;
 	ac97->capture_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
 	ac97->capture_dma_data.maxburst = 4;
-	ac97->capture_dma_data.slave_id = of_dma[1];
+	ac97->filter_data_rx.dma_dev = &pdev->dev;
+	sprintf(ac97->filter_data_rx.dma_name, "rx-tx");
+	ac97->capture_dma_data.filter_data = &ac97->filter_data_rx;
 
 	ac97->playback_dma_data.addr = mem->start + TEGRA20_AC97_FIFO_TX1;
 	ac97->playback_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
 	ac97->playback_dma_data.maxburst = 4;
-	ac97->playback_dma_data.slave_id = of_dma[1];
+	ac97->filter_data_tx.dma_dev = &pdev->dev;
+	sprintf(ac97->filter_data_tx.dma_name, "rx-tx");
+	ac97->playback_dma_data.filter_data = &ac97->filter_data_tx;
 
 	ret = tegra_asoc_utils_init(&ac97->util_data, &pdev->dev);
 	if (ret)
diff --git a/sound/soc/tegra/tegra20_ac97.h b/sound/soc/tegra/tegra20_ac97.h
index 4acb3aa..ac09d34 100644
--- a/sound/soc/tegra/tegra20_ac97.h
+++ b/sound/soc/tegra/tegra20_ac97.h
@@ -86,7 +86,9 @@
 struct tegra20_ac97 {
 	struct clk *clk_ac97;
 	struct snd_dmaengine_dai_dma_data capture_dma_data;
+	struct tegra_dma_filter_data filter_data_rx;
 	struct snd_dmaengine_dai_dma_data playback_dma_data;
+	struct tegra_dma_filter_data filter_data_tx;
 	struct regmap *regmap;
 	int reset_gpio;
 	int sync_gpio;
diff --git a/sound/soc/tegra/tegra20_i2s.c b/sound/soc/tegra/tegra20_i2s.c
index 52af7f6..af98338 100644
--- a/sound/soc/tegra/tegra20_i2s.c
+++ b/sound/soc/tegra/tegra20_i2s.c
@@ -339,9 +339,7 @@ static const struct regmap_config tegra20_i2s_regmap_config = {
 static int tegra20_i2s_platform_probe(struct platform_device *pdev)
 {
 	struct tegra20_i2s *i2s;
-	struct resource *mem, *memregion, *dmareq;
-	u32 of_dma[2];
-	u32 dma_ch;
+	struct resource *mem, *memregion;
 	void __iomem *regs;
 	int ret;
 
@@ -370,20 +368,6 @@ static int tegra20_i2s_platform_probe(struct platform_device *pdev)
 		goto err_clk_put;
 	}
 
-	dmareq = platform_get_resource(pdev, IORESOURCE_DMA, 0);
-	if (!dmareq) {
-		if (of_property_read_u32_array(pdev->dev.of_node,
-					"nvidia,dma-request-selector",
-					of_dma, 2) < 0) {
-			dev_err(&pdev->dev, "No DMA resource\n");
-			ret = -ENODEV;
-			goto err_clk_put;
-		}
-		dma_ch = of_dma[1];
-	} else {
-		dma_ch = dmareq->start;
-	}
-
 	memregion = devm_request_mem_region(&pdev->dev, mem->start,
 					    resource_size(mem), DRV_NAME);
 	if (!memregion) {
@@ -410,12 +394,16 @@ static int tegra20_i2s_platform_probe(struct platform_device *pdev)
 	i2s->capture_dma_data.addr = mem->start + TEGRA20_I2S_FIFO2;
 	i2s->capture_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
 	i2s->capture_dma_data.maxburst = 4;
-	i2s->capture_dma_data.slave_id = dma_ch;
+	i2s->filter_data_rx.dma_dev = &pdev->dev;
+	sprintf(i2s->filter_data_rx.dma_name, "rx-tx");
+	i2s->capture_dma_data.filter_data = &i2s->filter_data_rx;
 
 	i2s->playback_dma_data.addr = mem->start + TEGRA20_I2S_FIFO1;
 	i2s->playback_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
 	i2s->playback_dma_data.maxburst = 4;
-	i2s->playback_dma_data.slave_id = dma_ch;
+	i2s->filter_data_tx.dma_dev = &pdev->dev;
+	sprintf(i2s->filter_data_tx.dma_name, "rx-tx");
+	i2s->playback_dma_data.filter_data = &i2s->filter_data_tx;
 
 	pm_runtime_enable(&pdev->dev);
 	if (!pm_runtime_enabled(&pdev->dev)) {
diff --git a/sound/soc/tegra/tegra20_i2s.h b/sound/soc/tegra/tegra20_i2s.h
index fa6c29c..794d487 100644
--- a/sound/soc/tegra/tegra20_i2s.h
+++ b/sound/soc/tegra/tegra20_i2s.h
@@ -156,7 +156,9 @@ struct tegra20_i2s {
 	struct snd_soc_dai_driver dai;
 	struct clk *clk_i2s;
 	struct snd_dmaengine_dai_dma_data capture_dma_data;
+	struct tegra_dma_filter_data filter_data_rx;
 	struct snd_dmaengine_dai_dma_data playback_dma_data;
+	struct tegra_dma_filter_data filter_data_tx;
 	struct regmap *regmap;
 };
 
diff --git a/sound/soc/tegra/tegra30_ahub.c b/sound/soc/tegra/tegra30_ahub.c
index d554d46..afa8a0b 100644
--- a/sound/soc/tegra/tegra30_ahub.c
+++ b/sound/soc/tegra/tegra30_ahub.c
@@ -96,7 +96,7 @@ static int tegra30_ahub_runtime_resume(struct device *dev)
 
 int tegra30_ahub_allocate_rx_fifo(enum tegra30_ahub_rxcif *rxcif,
 				  dma_addr_t *fiforeg,
-				  unsigned int *reqsel)
+				 struct tegra_dma_filter_data *filter_data)
 {
 	int channel;
 	u32 reg, val;
@@ -111,7 +111,9 @@ int tegra30_ahub_allocate_rx_fifo(enum tegra30_ahub_rxcif *rxcif,
 	*rxcif = TEGRA30_AHUB_RXCIF_APBIF_RX0 + channel;
 	*fiforeg = ahub->apbif_addr + TEGRA30_AHUB_CHANNEL_RXFIFO +
 		   (channel * TEGRA30_AHUB_CHANNEL_RXFIFO_STRIDE);
-	*reqsel = ahub->dma_sel + channel;
+
+	filter_data->dma_dev = ahub->dev;
+	sprintf(filter_data->dma_name, "channel%d", channel);
 
 	reg = TEGRA30_AHUB_CHANNEL_CTRL +
 	      (channel * TEGRA30_AHUB_CHANNEL_CTRL_STRIDE);
@@ -178,8 +180,8 @@ int tegra30_ahub_free_rx_fifo(enum tegra30_ahub_rxcif rxcif)
 EXPORT_SYMBOL_GPL(tegra30_ahub_free_rx_fifo);
 
 int tegra30_ahub_allocate_tx_fifo(enum tegra30_ahub_txcif *txcif,
-				  dma_addr_t *fiforeg,
-				  unsigned int *reqsel)
+				dma_addr_t *fiforeg,
+				struct tegra_dma_filter_data *filter_data)
 {
 	int channel;
 	u32 reg, val;
@@ -194,7 +196,9 @@ int tegra30_ahub_allocate_tx_fifo(enum tegra30_ahub_txcif *txcif,
 	*txcif = TEGRA30_AHUB_TXCIF_APBIF_TX0 + channel;
 	*fiforeg = ahub->apbif_addr + TEGRA30_AHUB_CHANNEL_TXFIFO +
 		   (channel * TEGRA30_AHUB_CHANNEL_TXFIFO_STRIDE);
-	*reqsel = ahub->dma_sel + channel;
+
+	filter_data->dma_dev = ahub->dev;
+	sprintf(filter_data->dma_name, "channel%d", channel);
 
 	reg = TEGRA30_AHUB_CHANNEL_CTRL +
 	      (channel * TEGRA30_AHUB_CHANNEL_CTRL_STRIDE);
@@ -456,7 +460,6 @@ static int tegra30_ahub_probe(struct platform_device *pdev)
 	struct clk *clk;
 	int i;
 	struct resource *res0, *res1, *region;
-	u32 of_dma[2];
 	void __iomem *regs_apbif, *regs_ahub;
 	int ret = 0;
 
@@ -513,16 +516,6 @@ static int tegra30_ahub_probe(struct platform_device *pdev)
 		goto err_clk_put_d_audio;
 	}
 
-	if (of_property_read_u32_array(pdev->dev.of_node,
-				"nvidia,dma-request-selector",
-				of_dma, 2) < 0) {
-		dev_err(&pdev->dev,
-			"Missing property nvidia,dma-request-selector\n");
-		ret = -ENODEV;
-		goto err_clk_put_d_audio;
-	}
-	ahub->dma_sel = of_dma[1];
-
 	res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (!res0) {
 		dev_err(&pdev->dev, "No apbif memory resource\n");
diff --git a/sound/soc/tegra/tegra30_ahub.h b/sound/soc/tegra/tegra30_ahub.h
index 09766cd..3eae224 100644
--- a/sound/soc/tegra/tegra30_ahub.h
+++ b/sound/soc/tegra/tegra30_ahub.h
@@ -19,6 +19,8 @@
 #ifndef __TEGRA30_AHUB_H__
 #define __TEGRA30_AHUB_H__
 
+#include "tegra_pcm.h"
+
 /* Fields in *_CIF_RX/TX_CTRL; used by AHUB FIFOs, and all other audio modules */
 
 #define TEGRA30_AUDIOCIF_CTRL_FIFO_THRESHOLD_SHIFT	28
@@ -451,15 +453,15 @@ enum tegra30_ahub_rxcif {
 };
 
 extern int tegra30_ahub_allocate_rx_fifo(enum tegra30_ahub_rxcif *rxcif,
-					 dma_addr_t *fiforeg,
-					 unsigned int *reqsel);
+				 dma_addr_t *fiforeg,
+				 struct tegra_dma_filter_data *filter_data);
 extern int tegra30_ahub_enable_rx_fifo(enum tegra30_ahub_rxcif rxcif);
 extern int tegra30_ahub_disable_rx_fifo(enum tegra30_ahub_rxcif rxcif);
 extern int tegra30_ahub_free_rx_fifo(enum tegra30_ahub_rxcif rxcif);
 
 extern int tegra30_ahub_allocate_tx_fifo(enum tegra30_ahub_txcif *txcif,
-					 dma_addr_t *fiforeg,
-					 unsigned int *reqsel);
+				 dma_addr_t *fiforeg,
+				 struct tegra_dma_filter_data *filter_data);
 extern int tegra30_ahub_enable_tx_fifo(enum tegra30_ahub_txcif txcif);
 extern int tegra30_ahub_disable_tx_fifo(enum tegra30_ahub_txcif txcif);
 extern int tegra30_ahub_free_tx_fifo(enum tegra30_ahub_txcif txcif);
@@ -488,7 +490,6 @@ struct tegra30_ahub {
 	struct device *dev;
 	struct clk *clk_d_audio;
 	struct clk *clk_apbif;
-	int dma_sel;
 	resource_size_t apbif_addr;
 	struct regmap *regmap_apbif;
 	struct regmap *regmap_ahub;
diff --git a/sound/soc/tegra/tegra30_i2s.c b/sound/soc/tegra/tegra30_i2s.c
index d04146c..e1672c0 100644
--- a/sound/soc/tegra/tegra30_i2s.c
+++ b/sound/soc/tegra/tegra30_i2s.c
@@ -76,27 +76,16 @@ static int tegra30_i2s_startup(struct snd_pcm_substream *substream,
 			struct snd_soc_dai *dai)
 {
 	struct tegra30_i2s *i2s = snd_soc_dai_get_drvdata(dai);
-	int ret;
 
 	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-		ret = tegra30_ahub_allocate_tx_fifo(&i2s->playback_fifo_cif,
-					&i2s->playback_dma_data.addr,
-					&i2s->playback_dma_data.slave_id);
-		i2s->playback_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-		i2s->playback_dma_data.maxburst = 4;
 		tegra30_ahub_set_rx_cif_source(i2s->playback_i2s_cif,
 					       i2s->playback_fifo_cif);
 	} else {
-		ret = tegra30_ahub_allocate_rx_fifo(&i2s->capture_fifo_cif,
-					&i2s->capture_dma_data.addr,
-					&i2s->capture_dma_data.slave_id);
-		i2s->capture_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-		i2s->capture_dma_data.maxburst = 4;
 		tegra30_ahub_set_rx_cif_source(i2s->capture_fifo_cif,
 					       i2s->capture_i2s_cif);
 	}
 
-	return ret;
+	return 0;
 }
 
 static void tegra30_i2s_shutdown(struct snd_pcm_substream *substream,
@@ -106,10 +95,8 @@ static void tegra30_i2s_shutdown(struct snd_pcm_substream *substream,
 
 	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
 		tegra30_ahub_unset_rx_cif_source(i2s->playback_i2s_cif);
-		tegra30_ahub_free_tx_fifo(i2s->playback_fifo_cif);
 	} else {
 		tegra30_ahub_unset_rx_cif_source(i2s->capture_fifo_cif);
-		tegra30_ahub_free_rx_fifo(i2s->capture_fifo_cif);
 	}
 }
 
@@ -412,6 +399,9 @@ static int tegra30_i2s_platform_probe(struct platform_device *pdev)
 	}
 	dev_set_drvdata(&pdev->dev, i2s);
 
+	i2s->capture_dma_data.filter_data = &i2s->filter_data_rx;
+	i2s->playback_dma_data.filter_data = &i2s->filter_data_tx;
+
 	i2s->dai = tegra30_i2s_dai_template;
 	i2s->dai.name = dev_name(&pdev->dev);
 
@@ -462,6 +452,26 @@ static int tegra30_i2s_platform_probe(struct platform_device *pdev)
 	}
 	regcache_cache_only(i2s->regmap, true);
 
+	ret = tegra30_ahub_allocate_tx_fifo(&i2s->playback_fifo_cif,
+					&i2s->playback_dma_data.addr,
+					&i2s->filter_data_tx);
+	if (ret) {
+		dev_err(&pdev->dev, "ahub allocate tx fifo failed\n");
+		goto err_clk_put;
+	}
+	ret = tegra30_ahub_allocate_rx_fifo(&i2s->capture_fifo_cif,
+					&i2s->capture_dma_data.addr,
+					&i2s->filter_data_rx);
+	if (ret) {
+		dev_err(&pdev->dev, "ahub allocate rx fifo failed\n");
+		goto err_ahub_free_tx;
+	}
+
+	i2s->playback_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+	i2s->playback_dma_data.maxburst = 4;
+	i2s->capture_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+	i2s->capture_dma_data.maxburst = 4;
+
 	pm_runtime_enable(&pdev->dev);
 	if (!pm_runtime_enabled(&pdev->dev)) {
 		ret = tegra30_i2s_runtime_resume(&pdev->dev);
@@ -492,6 +502,9 @@ err_suspend:
 		tegra30_i2s_runtime_suspend(&pdev->dev);
 err_pm_disable:
 	pm_runtime_disable(&pdev->dev);
+	tegra30_ahub_free_rx_fifo(i2s->capture_fifo_cif);
+err_ahub_free_tx:
+	tegra30_ahub_free_tx_fifo(i2s->playback_fifo_cif);
 err_clk_put:
 	clk_put(i2s->clk_i2s);
 err:
@@ -506,6 +519,9 @@ static int tegra30_i2s_platform_remove(struct platform_device *pdev)
 	if (!pm_runtime_status_suspended(&pdev->dev))
 		tegra30_i2s_runtime_suspend(&pdev->dev);
 
+	tegra30_ahub_free_rx_fifo(i2s->capture_fifo_cif);
+	tegra30_ahub_free_tx_fifo(i2s->playback_fifo_cif);
+
 	tegra_pcm_platform_unregister(&pdev->dev);
 	snd_soc_unregister_component(&pdev->dev);
 
diff --git a/sound/soc/tegra/tegra30_i2s.h b/sound/soc/tegra/tegra30_i2s.h
index bea23af..73f5650 100644
--- a/sound/soc/tegra/tegra30_i2s.h
+++ b/sound/soc/tegra/tegra30_i2s.h
@@ -232,9 +232,11 @@ struct tegra30_i2s {
 	enum tegra30_ahub_txcif capture_i2s_cif;
 	enum tegra30_ahub_rxcif capture_fifo_cif;
 	struct snd_dmaengine_dai_dma_data capture_dma_data;
+	struct tegra_dma_filter_data filter_data_rx;
 	enum tegra30_ahub_rxcif playback_i2s_cif;
 	enum tegra30_ahub_txcif playback_fifo_cif;
 	struct snd_dmaengine_dai_dma_data playback_dma_data;
+	struct tegra_dma_filter_data filter_data_tx;
 	struct regmap *regmap;
 };
 
diff --git a/sound/soc/tegra/tegra_pcm.c b/sound/soc/tegra/tegra_pcm.c
index f056f63..3baea16 100644
--- a/sound/soc/tegra/tegra_pcm.c
+++ b/sound/soc/tegra/tegra_pcm.c
@@ -53,8 +53,22 @@ static const struct snd_pcm_hardware tegra_pcm_hardware = {
 	.fifo_size		= 4,
 };
 
+static struct dma_chan *tegra_pcm_request_chan(struct snd_soc_pcm_runtime *rtd,
+	struct snd_pcm_substream *substream)
+{
+	struct snd_dmaengine_dai_dma_data *dma_data;
+	struct tegra_dma_filter_data *filter_data;
+
+	dma_data = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
+	filter_data = dma_data->filter_data;
+
+	return dma_request_slave_channel(filter_data->dma_dev,
+					filter_data->dma_name);
+}
+
 static const struct snd_dmaengine_pcm_config tegra_dmaengine_pcm_config = {
 	.pcm_hardware = &tegra_pcm_hardware,
+	.compat_request_channel = tegra_pcm_request_chan,
 	.prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
 	.compat_filter_fn = NULL,
 	.prealloc_buffer_size = PAGE_SIZE * 8,
diff --git a/sound/soc/tegra/tegra_pcm.h b/sound/soc/tegra/tegra_pcm.h
index 68ad901..8c0b1eb 100644
--- a/sound/soc/tegra/tegra_pcm.h
+++ b/sound/soc/tegra/tegra_pcm.h
@@ -31,6 +31,19 @@
 #ifndef __TEGRA_PCM_H__
 #define __TEGRA_PCM_H__
 
+#define TEGRA_DMA_NAME_MAX_LEN	10
+
+/*
+ * Generic DMA DT binding needs the device that raise dma request and dma name
+ * to request a dma channel. tegra30_i2s is a special case. It should be ahub
+ * device and it also has dma name that cannot handled by ASoC dmaengine code.
+ * So we pass the info using filter data in snd_dmaengine_dai_dma_data.
+ */
+struct tegra_dma_filter_data {
+	struct device *dma_dev;
+	char dma_name[TEGRA_DMA_NAME_MAX_LEN];
+};
+
 int tegra_pcm_platform_register(struct device *dev);
 void tegra_pcm_platform_unregister(struct device *dev);
 
-- 
1.8.1.5



From rizhao at nvidia.com  Wed Jul 24 00:10:01 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Wed, 24 Jul 2013 12:10:01 +0800
Subject: [PATCH 8/9] ARM: dts: tegra: remove legacy nvidia,
 dma-request-selector properties
In-Reply-To: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
Message-ID: <1374639002-16753-9-git-send-email-rizhao@nvidia.com>

All tegra dma client drivers have moved to generic dma binding.

Signed-off-by: Richard Zhao <rizhao at nvidia.com>
---
 arch/arm/boot/dts/tegra114.dtsi | 14 --------------
 arch/arm/boot/dts/tegra20.dtsi  | 13 -------------
 arch/arm/boot/dts/tegra30.dtsi  | 12 ------------
 3 files changed, 39 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index b133c62..e696cbce 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -125,7 +125,6 @@
 		reg = <0x70006000 0x40>;
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 8>;
 		dmas = <&apbdma 8>;
 		dma-names = "rx-tx";
 		status = "disabled";
@@ -137,7 +136,6 @@
 		reg = <0x70006040 0x40>;
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 9>;
 		dmas = <&apbdma 9>;
 		dma-names = "rx-tx";
 		status = "disabled";
@@ -149,7 +147,6 @@
 		reg = <0x70006200 0x100>;
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 10>;
 		dmas = <&apbdma 10>;
 		dma-names = "rx-tx";
 		status = "disabled";
@@ -161,7 +158,6 @@
 		reg = <0x70006300 0x100>;
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 19>;
 		dmas = <&apbdma 19>;
 		dma-names = "rx-tx";
 		status = "disabled";
@@ -235,7 +231,6 @@
 		compatible = "nvidia,tegra114-spi";
 		reg = <0x7000d400 0x200>;
 		interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 15>;
 		dmas = <&apbdma 15>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -249,7 +244,6 @@
 		compatible = "nvidia,tegra114-spi";
 		reg = <0x7000d600 0x200>;
 		interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 16>;
 		dmas = <&apbdma 16>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -263,7 +257,6 @@
 		compatible = "nvidia,tegra114-spi";
 		reg = <0x7000d800 0x200>;
 		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 17>;
 		dmas = <&apbdma 17>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -277,7 +270,6 @@
 		compatible = "nvidia,tegra114-spi";
 		reg = <0x7000da00 0x200>;
 		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 18>;
 		dmas = <&apbdma 18>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -291,7 +283,6 @@
 		compatible = "nvidia,tegra114-spi";
 		reg = <0x7000dc00 0x200>;
 		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 27>;
 		dmas = <&apbdma 27>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -305,7 +296,6 @@
 		compatible = "nvidia,tegra114-spi";
 		reg = <0x7000de00 0x200>;
 		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 28>;
 		dmas = <&apbdma 28>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -354,10 +344,6 @@
 		      <0x70080200 0x100>,
 		      <0x70081000 0x200>;
 		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 1>, <&apbdma 2>,
-			<&apbdma 3>, <&apbdma 4>, <&apbdma 6>, <&apbdma 7>,
-			<&apbdma 12>, <&apbdma 13>, <&apbdma 14>,
-			<&apbdma 29>;
 		dmas = <&apbdma 1>, <&apbdma 2>, <&apbdma 3>, <&apbdma 4>,
 			<&apbdma 6>, <&apbdma 7>, <&apbdma 12>, <&apbdma 13>,
 			<&apbdma 14>, <&apbdma 29>;
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 0fe7f37..7ca0ccb 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -223,7 +223,6 @@
 		compatible = "nvidia,tegra20-ac97";
 		reg = <0x70002000 0x200>;
 		interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 12>;
 		dmas = <&apbdma 12>;
 		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_AC97>;
@@ -234,7 +233,6 @@
 		compatible = "nvidia,tegra20-i2s";
 		reg = <0x70002800 0x200>;
 		interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 2>;
 		dmas = <&apbdma 2>;
 		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_I2S1>;
@@ -245,7 +243,6 @@
 		compatible = "nvidia,tegra20-i2s";
 		reg = <0x70002a00 0x200>;
 		interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 1>;
 		dmas = <&apbdma 1>;
 		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_I2S2>;
@@ -264,7 +261,6 @@
 		reg = <0x70006000 0x40>;
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 8>;
 		dmas = <&apbdma 8>;
 		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_UARTA>;
@@ -276,7 +272,6 @@
 		reg = <0x70006040 0x40>;
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 9>;
 		dmas = <&apbdma 9>;
 		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_UARTB>;
@@ -288,7 +283,6 @@
 		reg = <0x70006200 0x100>;
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 10>;
 		dmas = <&apbdma 10>;
 		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_UARTC>;
@@ -300,7 +294,6 @@
 		reg = <0x70006300 0x100>;
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 19>;
 		dmas = <&apbdma 19>;
 		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_UARTD>;
@@ -312,7 +305,6 @@
 		reg = <0x70006400 0x100>;
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 20>;
 		dmas = <&apbdma 20>;
 		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA20_CLK_UARTE>;
@@ -350,7 +342,6 @@
 		compatible = "nvidia,tegra20-sflash";
 		reg = <0x7000c380 0x80>;
 		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 11>;
 		dmas = <&apbdma 11>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -399,7 +390,6 @@
 		compatible = "nvidia,tegra20-slink";
 		reg = <0x7000d400 0x200>;
 		interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 15>;
 		dmas = <&apbdma 15>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -412,7 +402,6 @@
 		compatible = "nvidia,tegra20-slink";
 		reg = <0x7000d600 0x200>;
 		interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 16>;
 		dmas = <&apbdma 16>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -425,7 +414,6 @@
 		compatible = "nvidia,tegra20-slink";
 		reg = <0x7000d800 0x200>;
 		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 17>;
 		dmas = <&apbdma 17>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -438,7 +426,6 @@
 		compatible = "nvidia,tegra20-slink";
 		reg = <0x7000da00 0x200>;
 		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 18>;
 		dmas = <&apbdma 18>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index c266316..729c853 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -245,7 +245,6 @@
 		reg = <0x70006000 0x40>;
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 8>;
 		dmas = <&apbdma 8>;
 		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA30_CLK_UARTA>;
@@ -257,7 +256,6 @@
 		reg = <0x70006040 0x40>;
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 9>;
 		dmas = <&apbdma 9>;
 		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA30_CLK_UARTB>;
@@ -269,7 +267,6 @@
 		reg = <0x70006200 0x100>;
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 10>;
 		dmas = <&apbdma 10>;
 		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA30_CLK_UARTC>;
@@ -281,7 +278,6 @@
 		reg = <0x70006300 0x100>;
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 19>;
 		dmas = <&apbdma 19>;
 		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA30_CLK_UARTD>;
@@ -293,7 +289,6 @@
 		reg = <0x70006400 0x100>;
 		reg-shift = <2>;
 		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 20>;
 		dmas = <&apbdma 20>;
 		dma-names = "rx-tx";
 		clocks = <&tegra_car TEGRA30_CLK_UARTE>;
@@ -379,7 +374,6 @@
 		compatible = "nvidia,tegra30-slink", "nvidia,tegra20-slink";
 		reg = <0x7000d400 0x200>;
 		interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 15>;
 		dmas = <&apbdma 15>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -392,7 +386,6 @@
 		compatible = "nvidia,tegra30-slink", "nvidia,tegra20-slink";
 		reg = <0x7000d600 0x200>;
 		interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 16>;
 		dmas = <&apbdma 16>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -405,7 +398,6 @@
 		compatible = "nvidia,tegra30-slink", "nvidia,tegra20-slink";
 		reg = <0x7000d800 0x200>;
 		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 17>;
 		dmas = <&apbdma 17>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -418,7 +410,6 @@
 		compatible = "nvidia,tegra30-slink", "nvidia,tegra20-slink";
 		reg = <0x7000da00 0x200>;
 		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 18>;
 		dmas = <&apbdma 18>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -431,7 +422,6 @@
 		compatible = "nvidia,tegra30-slink", "nvidia,tegra20-slink";
 		reg = <0x7000dc00 0x200>;
 		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 27>;
 		dmas = <&apbdma 27>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -444,7 +434,6 @@
 		compatible = "nvidia,tegra30-slink", "nvidia,tegra20-slink";
 		reg = <0x7000de00 0x200>;
 		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 28>;
 		dmas = <&apbdma 28>;
 		dma-names = "rx-tx";
 		#address-cells = <1>;
@@ -492,7 +481,6 @@
 		reg = <0x70080000 0x200
 		       0x70080200 0x100>;
 		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
-		nvidia,dma-request-selector = <&apbdma 1>;
 		dmas = <&apbdma 1>, <&apbdma 2>, <&apbdma 3>, <&apbdma 4>;
 		dma-names = "channel0", "channel1", "channel2", "channel3";
 		clocks = <&tegra_car TEGRA30_CLK_D_AUDIO>,
-- 
1.8.1.5



From rizhao at nvidia.com  Wed Jul 24 00:10:02 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Wed, 24 Jul 2013 12:10:02 +0800
Subject: [PATCH 9/9] dma: tegra20-apbdma: remove legacy nvidia,
 dma-request-selector support
In-Reply-To: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
Message-ID: <1374639002-16753-10-git-send-email-rizhao@nvidia.com>

All tegra dma client drivers have moved to generic dma binding.

Signed-off-by: Richard Zhao <rizhao at nvidia.com>
---
 drivers/dma/tegra20-apb-dma.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index 0e12f78..a67d159 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -344,13 +344,6 @@ static int tegra_dma_slave_config(struct dma_chan *dc,
 
 	memcpy(&tdc->dma_sconfig, sconfig, sizeof(*sconfig));
 
-	/* If we didn't get slave_id from DT when request channel, use the one
-	 * passed here.
-	 * It makes compatible with legacy nvidia,dma-request-selector.
-	 */
-	if (tdc->slave_id == -EINVAL)
-		tdc->slave_id = sconfig->slave_id;
-
 	tdc->config_init = true;
 	return 0;
 }
@@ -1374,7 +1367,6 @@ static int tegra_dma_probe(struct platform_device *pdev)
 				&tdma->dma_dev.channels);
 		tdc->tdma = tdma;
 		tdc->id = i;
-		tdc->slave_id = -EINVAL;
 
 		tasklet_init(&tdc->tasklet, tegra_dma_tasklet,
 				(unsigned long)tdc);
-- 
1.8.1.5



From kgene.kim at samsung.com  Wed Jul 24 00:36:47 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 24 Jul 2013 13:36:47 +0900
Subject: [PATCH] ARM: dts: re-ordering exynos dtbs in Makefile
Message-ID: <0e0c01ce8827$6850a220$38f1e660$%kim@samsung.com>


Re-ordering in alphabetical.

Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
---
 arch/arm/boot/dts/Makefile |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..ad340e4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -53,13 +53,13 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
 	exynos4210-trats.dtb \
 	exynos4210-universal_c210.dtb \
 	exynos4412-odroidx.dtb \
-	exynos4412-smdk4412.dtb \
 	exynos4412-origen.dtb \
+	exynos4412-smdk4412.dtb \
 	exynos5250-arndale.dtb \
-	exynos5440-sd5v1.dtb \
 	exynos5250-smdk5250.dtb \
 	exynos5250-snow.dtb \
 	exynos5420-smdk5420.dtb \
+	exynos5440-sd5v1.dtb \
 	exynos5440-ssdk5440.dtb
 dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
 	ecx-2000.dtb
-- 
1.7.10.4



From kgene.kim at samsung.com  Wed Jul 24 00:38:23 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 24 Jul 2013 13:38:23 +0900
Subject: [PATCH] ARM: dts: Add basic dts for Exynos4412-based Trats 2 board
In-Reply-To: <1371653357-1389-1-git-send-email-t.figa@samsung.com>
References: <1371653357-1389-1-git-send-email-t.figa@samsung.com>
Message-ID: <0e0d01ce8827$a155f430$e401dc90$%kim@samsung.com>

Tomasz Figa wrote:
> 
> This patch introduces device tree sources for Samsung Trats 2 board
> based on Exynos4412 SoC.
> 
> Currently support includes:
>  - eMMC,
>  - main PMIC (max77686),
>  - serial ports,
>  - GPIO keys,
>  - touchscreen.
> 
> Signed-off-by: Tomasz Figa <t.figa at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> ---
>  arch/arm/boot/dts/Makefile              |   1 +
>  arch/arm/boot/dts/exynos4412-trats2.dts | 456
> ++++++++++++++++++++++++++++++++
>  2 files changed, 457 insertions(+)
>  create mode 100644 arch/arm/boot/dts/exynos4412-trats2.dts
> 
Looks good to me, applied.

> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 1357510..8cdc7cc 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -53,6 +53,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
>  	exynos4412-odroidx.dtb \
>  	exynos4412-smdk4412.dtb \
>  	exynos4412-origen.dtb \
> +	exynos4412-trats2.dtb \
>  	exynos5250-arndale.dtb \
>  	exynos5440-sd5v1.dtb \
>  	exynos5250-smdk5250.dtb \

BTW, I put some dtbs in wrong order :( I need to sort out...

Thanks,
Kukjin



From kgene at kernel.org  Wed Jul 24 00:54:01 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 24 Jul 2013 13:54:01 +0900
Subject: [PATCH V2 1/2] ARM: SAMSUNG: Add SAMSUNG_PM config option to
 select pm
In-Reply-To: <1371036526-16589-2-git-send-email-amit.daniel@samsung.com>
References: <1371036526-16589-1-git-send-email-amit.daniel@samsung.com>
 <1371036526-16589-2-git-send-email-amit.daniel@samsung.com>
Message-ID: <0e2201ce8829$d178e1c0$746aa540$@org>

Amit Daniel Kachhap wrote:
> 
> This patch enables the selection of samsung pm related stuffs
> when SAMSUNG_PM config is enabled and not just when generic PM
> config is enabled. Power management for s3c64XX and s3c24XX
> is enabled by default and for other platform depends on S5P_PM.
> This patch also fixes the following compilation error's when compiling
> a platform like exynos5440 which does not select pm stuffs.
> 
> arch/arm/mach-exynos/built-in.o: In function `__virt_to_phys':
> linux/arch/arm/include/asm/memory.h:175: undefined reference to
> `s3c_cpu_resume'
> linux/arch/arm/include/asm/memory.h:175: undefined reference to
> `s3c_cpu_resume'
> linux/arch/arm/include/asm/memory.h:175: undefined reference to
> `s3c_cpu_resume'
> linux/arch/arm/include/asm/memory.h:175: undefined reference to
> `s3c_cpu_resume'
> arch/arm/mach-exynos/built-in.o: In function `exynos5_init_irq':
> linux/arch/arm/mach-exynos/common.c:492: undefined reference to
> `s3c_irq_wake'
> linux/arch/arm/mach-exynos/common.c:492: undefined reference to
> `s3c_irq_wake'
> arch/arm/mach-exynos/built-in.o: In function `exynos4_init_irq':
> linux/arch/arm/mach-exynos/common.c:476: undefined reference to
> `s3c_irq_wake'
> linux/arch/arm/mach-exynos/common.c:476: undefined reference to
> `s3c_irq_wake'
> arch/arm/plat-samsung/built-in.o: In function `s3c_irqext_wake':
> linux/arch/arm/plat-samsung/pm.c:144: undefined reference to
> `s3c_irqwake_eintallow'
> linux/arch/arm/plat-samsung/pm.c:144: undefined reference to
> `s3c_irqwake_eintallow'
> arch/arm/plat-samsung/built-in.o: In function `s3c_pm_enter':
> linux/arch/arm/plat-samsung/pm.c:263: undefined reference to
> `s3c_irqwake_intallow'
> linux/arch/arm/plat-samsung/pm.c:263: undefined reference to
> `s3c_irqwake_intallow'
> linux/arch/arm/plat-samsung/pm.c:264: undefined reference to
> `s3c_irqwake_eintallow'
> linux/arch/arm/plat-samsung/pm.c:264: undefined reference to
> `s3c_irqwake_eintallow'
> linux/arch/arm/plat-samsung/pm.c:275: undefined reference to
> `s3c_pm_save_core'
> linux/arch/arm/plat-samsung/pm.c:279: undefined reference to
> `s3c_pm_configure_extint'
> linux/arch/arm/plat-samsung/pm.c:310: undefined reference to
> `s3c_pm_restore_core'
> make: *** [vmlinux] Error 1
> 
> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
> ---
>  arch/arm/mach-exynos/Makefile           |    2 +-
>  arch/arm/mach-exynos/common.c           |    2 +-
>  arch/arm/mach-exynos/common.h           |    1 -
>  arch/arm/mach-exynos/cpuidle.c          |    1 +
>  arch/arm/plat-samsung/Kconfig           |    7 +++++++
>  arch/arm/plat-samsung/Makefile          |    3 +--
>  arch/arm/plat-samsung/include/plat/pm.h |    8 ++++----
>  7 files changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
> index 9811f87..3fa277a 100644
> --- a/arch/arm/mach-exynos/Makefile
> +++ b/arch/arm/mach-exynos/Makefile
> @@ -14,7 +14,7 @@ obj-				:=
> 
>  obj-$(CONFIG_ARCH_EXYNOS)	+= common.o
> 
> -obj-$(CONFIG_PM)		+= pm.o
> +obj-$(CONFIG_S5P_PM)		+= pm.o
>  obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
>  obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
> 
> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
> index 9834357..d2b4f54 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -799,7 +799,7 @@ static struct irq_chip exynos_irq_eint = {
>  	.irq_mask_ack	= exynos_irq_eint_maskack,
>  	.irq_ack	= exynos_irq_eint_ack,
>  	.irq_set_type	= exynos_irq_eint_set_type,
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_S5P_PM
>  	.irq_set_wake	= s3c_irqext_wake,
>  #endif
>  };
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index 11fc1e2..f2b2e23 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -98,6 +98,5 @@ struct exynos_pmu_conf {
>  };
> 
>  extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
> -extern void s3c_cpu_resume(void);
> 
>  #endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
> exynos/cpuidle.c
> index 4667907..2d071c6 100644
> --- a/arch/arm/mach-exynos/cpuidle.c
> +++ b/arch/arm/mach-exynos/cpuidle.c
> @@ -25,6 +25,7 @@
>  #include <mach/regs-pmu.h>
> 
>  #include <plat/cpu.h>
> +#include <plat/pm.h>
> 
>  #include "common.h"
> 
> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
> index f8ed2de..6c25aa6 100644
> --- a/arch/arm/plat-samsung/Kconfig
> +++ b/arch/arm/plat-samsung/Kconfig
> @@ -31,6 +31,13 @@ config PLAT_S5P
>  	help
>  	  Base platform code for Samsung's S5P series SoC.
> 
> +config SAMSUNG_PM
> +	bool
> +	depends on PM && (PLAT_S3C24XX || ARCH_S3C64XX || S5P_PM)

As we discussed before, this should be:

+	depends on PM && (PLAT_S3C24XX || ARCH_S3C64XX || ARCH_S5P64X0 ||
S5P_PM)

If not, build error happens with s5p64x0_defconfig. So I fixed.

> +	default y
> +	help
> +	  Base platform power management code for samsung code
> +
>  if PLAT_SAMSUNG
> 
>  # boot configurations
> diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-
> samsung/Makefile
> index a23c460..1c406b3 100644
> --- a/arch/arm/plat-samsung/Makefile
> +++ b/arch/arm/plat-samsung/Makefile
> @@ -51,8 +51,7 @@ obj-$(CONFIG_SAMSUNG_DMADEV)	+= dma-ops.o
> 
>  # PM support
> 
> -obj-$(CONFIG_PM)		+= pm.o
> -obj-$(CONFIG_PM)		+= pm-gpio.o
> +obj-$(CONFIG_SAMSUNG_PM)	+= pm.o pm-gpio.o
>  obj-$(CONFIG_SAMSUNG_PM_CHECK)	+= pm-check.o
> 
>  obj-$(CONFIG_SAMSUNG_WAKEMASK)	+= wakeup-mask.o
> diff --git a/arch/arm/plat-samsung/include/plat/pm.h b/arch/arm/plat-
> samsung/include/plat/pm.h
> index f6fcade..46e2c82 100644
> --- a/arch/arm/plat-samsung/include/plat/pm.h
> +++ b/arch/arm/plat-samsung/include/plat/pm.h
> @@ -19,7 +19,7 @@
> 
>  struct device;
> 
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_SAMSUNG_PM
> 
>  extern __init int s3c_pm_init(void);
>  extern __init int s3c64xx_pm_init(void);
> @@ -58,8 +58,6 @@ extern unsigned char pm_uart_udivslot;  /* true to save
> UART UDIVSLOT */
> 
>  /* from sleep.S */
> 
> -extern void s3c_cpu_resume(void);
> -
>  extern int s3c2410_cpu_suspend(unsigned long);
> 
>  /* sleep save info */
> @@ -106,12 +104,14 @@ extern void s3c_pm_do_save(struct sleep_save *ptr,
> int count);
>  extern void s3c_pm_do_restore(struct sleep_save *ptr, int count);
>  extern void s3c_pm_do_restore_core(struct sleep_save *ptr, int count);
> 
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_SAMSUNG_PM
>  extern int s3c_irq_wake(struct irq_data *data, unsigned int state);
>  extern int s3c_irqext_wake(struct irq_data *data, unsigned int state);
> +extern void s3c_cpu_resume(void);
>  #else
>  #define s3c_irq_wake NULL
>  #define s3c_irqext_wake NULL
> +#define s3c_cpu_resume NULL
>  #endif
> 
>  /* PM debug functions */
> --
> 1.7.1

Applied into -fixes, thanks.

- Kukjin



From sachin.kamat at linaro.org  Wed Jul 24 01:12:51 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Wed, 24 Jul 2013 10:42:51 +0530
Subject: [PATCH] ARM: dts: Add USBPHY nodes to Exynos4x12
In-Reply-To: <1374600682-19376-1-git-send-email-tobetter@gmail.com>
References: <1374600682-19376-1-git-send-email-tobetter@gmail.com>
Message-ID: <CAK9yfHw98L-FUtX7v32FyE4UN308uYpJXx8oxDuYgYZk1uUp_A@mail.gmail.com>

Hi Dongjin,

On 23 July 2013 23:01, Dongjin Kim <tobetter at gmail.com> wrote:
> This patch adds device nodes for USBPHY to Exynos4x12.
>
> Signed-off-by: Dongjin Kim <tobetter at gmail.com>
> ---
>  arch/arm/boot/dts/exynos4x12.dtsi |   18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
> index 01da194..9c3335b 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -73,4 +73,22 @@
>                 clock-names = "sclk_fimg2d", "fimg2d";
>                 status = "disabled";
>         };
> +
> +       usbphy at 125B00000 {

Extra 0 above.

> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               compatible = "samsung,exynos4x12-usb2phy";
> +               reg = <0x125B0000 0x100>;
> +               ranges;
> +
> +               clocks = <&clock 2>, <&clock 305>;
> +               clock-names = "xusbxti", "otg";
> +               status = "disabled";
> +
> +               usbphy-sys {
> +                       /* USB device and host PHY_CONTROL registers */
> +                       reg = <0x10020704 0xc>,
> +                             <0x1001021c 0x4>;
> +               };
> +       };
>  };

Please add this node after tmu node (satisfies alphabetical order as
well as increasing address value)


-- 
With warm regards,
Sachin


From kgene at kernel.org  Wed Jul 24 01:15:34 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 24 Jul 2013 14:15:34 +0900
Subject: [PATCH V2 2/2] ARM: EXYNOS: cpuidle: Allow C1 state only in
 supported SOC's.
In-Reply-To: <1371036526-16589-3-git-send-email-amit.daniel@samsung.com>
References: <1371036526-16589-1-git-send-email-amit.daniel@samsung.com>
 <1371036526-16589-3-git-send-email-amit.daniel@samsung.com>
Message-ID: <0e2301ce882c$d39021a0$7ab064e0$@org>

Amit Daniel Kachhap wrote:
> 
> This patch registers the basic C0 state for all exynos SOC's but
> limits the C1(AFTR -Arm off top running) state in only the supported
> SOC's(ie. EXYNOS 4210, 4212, 4412 and 5250).
> 
> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
> ---
>  arch/arm/mach-exynos/cpuidle.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
> exynos/cpuidle.c
> index 2d071c6..ccb2b48 100644
> --- a/arch/arm/mach-exynos/cpuidle.c
> +++ b/arch/arm/mach-exynos/cpuidle.c
> @@ -176,7 +176,9 @@ static int __init exynos4_init_cpuidle(void)
>  		device->cpu = cpu_id;
> 
>  		/* Support IDLE only */
> -		if (cpu_id != 0)
> +		if (!(soc_is_exynos4210() || soc_is_exynos4212() ||
> +			soc_is_exynos4412() || soc_is_exynos5250()) ||
> +			cpu_id != 0)

How about exynos5420?

So...

+		if (soc_is_exynos5440() || cpu_id !=0) ?

>  			device->state_count = 1;
> 
>  		ret = cpuidle_register_device(device);
> --
> 1.7.1

- Kukjin



From amit.daniel at samsung.com  Wed Jul 24 01:58:23 2013
From: amit.daniel at samsung.com (amit daniel kachhap)
Date: Wed, 24 Jul 2013 11:28:23 +0530
Subject: [PATCH V2 1/2] ARM: SAMSUNG: Add SAMSUNG_PM config option to
 select pm
In-Reply-To: <0e2201ce8829$d178e1c0$746aa540$@org>
References: <1371036526-16589-1-git-send-email-amit.daniel@samsung.com>
 <1371036526-16589-2-git-send-email-amit.daniel@samsung.com>
 <0e2201ce8829$d178e1c0$746aa540$@org>
Message-ID: <CADGdYn5njnLrFYrWPvogz2sP=gMFKNLvYSt+6+gkW2T5FDDbAA@mail.gmail.com>

On Wed, Jul 24, 2013 at 10:24 AM, Kukjin Kim <kgene at kernel.org> wrote:
> Amit Daniel Kachhap wrote:
>>
>> This patch enables the selection of samsung pm related stuffs
>> when SAMSUNG_PM config is enabled and not just when generic PM
>> config is enabled. Power management for s3c64XX and s3c24XX
>> is enabled by default and for other platform depends on S5P_PM.
>> This patch also fixes the following compilation error's when compiling
>> a platform like exynos5440 which does not select pm stuffs.
>>
>> arch/arm/mach-exynos/built-in.o: In function `__virt_to_phys':
>> linux/arch/arm/include/asm/memory.h:175: undefined reference to
>> `s3c_cpu_resume'
>> linux/arch/arm/include/asm/memory.h:175: undefined reference to
>> `s3c_cpu_resume'
>> linux/arch/arm/include/asm/memory.h:175: undefined reference to
>> `s3c_cpu_resume'
>> linux/arch/arm/include/asm/memory.h:175: undefined reference to
>> `s3c_cpu_resume'
>> arch/arm/mach-exynos/built-in.o: In function `exynos5_init_irq':
>> linux/arch/arm/mach-exynos/common.c:492: undefined reference to
>> `s3c_irq_wake'
>> linux/arch/arm/mach-exynos/common.c:492: undefined reference to
>> `s3c_irq_wake'
>> arch/arm/mach-exynos/built-in.o: In function `exynos4_init_irq':
>> linux/arch/arm/mach-exynos/common.c:476: undefined reference to
>> `s3c_irq_wake'
>> linux/arch/arm/mach-exynos/common.c:476: undefined reference to
>> `s3c_irq_wake'
>> arch/arm/plat-samsung/built-in.o: In function `s3c_irqext_wake':
>> linux/arch/arm/plat-samsung/pm.c:144: undefined reference to
>> `s3c_irqwake_eintallow'
>> linux/arch/arm/plat-samsung/pm.c:144: undefined reference to
>> `s3c_irqwake_eintallow'
>> arch/arm/plat-samsung/built-in.o: In function `s3c_pm_enter':
>> linux/arch/arm/plat-samsung/pm.c:263: undefined reference to
>> `s3c_irqwake_intallow'
>> linux/arch/arm/plat-samsung/pm.c:263: undefined reference to
>> `s3c_irqwake_intallow'
>> linux/arch/arm/plat-samsung/pm.c:264: undefined reference to
>> `s3c_irqwake_eintallow'
>> linux/arch/arm/plat-samsung/pm.c:264: undefined reference to
>> `s3c_irqwake_eintallow'
>> linux/arch/arm/plat-samsung/pm.c:275: undefined reference to
>> `s3c_pm_save_core'
>> linux/arch/arm/plat-samsung/pm.c:279: undefined reference to
>> `s3c_pm_configure_extint'
>> linux/arch/arm/plat-samsung/pm.c:310: undefined reference to
>> `s3c_pm_restore_core'
>> make: *** [vmlinux] Error 1
>>
>> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
>> ---
>>  arch/arm/mach-exynos/Makefile           |    2 +-
>>  arch/arm/mach-exynos/common.c           |    2 +-
>>  arch/arm/mach-exynos/common.h           |    1 -
>>  arch/arm/mach-exynos/cpuidle.c          |    1 +
>>  arch/arm/plat-samsung/Kconfig           |    7 +++++++
>>  arch/arm/plat-samsung/Makefile          |    3 +--
>>  arch/arm/plat-samsung/include/plat/pm.h |    8 ++++----
>>  7 files changed, 15 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
>> index 9811f87..3fa277a 100644
>> --- a/arch/arm/mach-exynos/Makefile
>> +++ b/arch/arm/mach-exynos/Makefile
>> @@ -14,7 +14,7 @@ obj-                                :=
>>
>>  obj-$(CONFIG_ARCH_EXYNOS)    += common.o
>>
>> -obj-$(CONFIG_PM)             += pm.o
>> +obj-$(CONFIG_S5P_PM)         += pm.o
>>  obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
>>  obj-$(CONFIG_CPU_IDLE)               += cpuidle.o
>>
>> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
>> index 9834357..d2b4f54 100644
>> --- a/arch/arm/mach-exynos/common.c
>> +++ b/arch/arm/mach-exynos/common.c
>> @@ -799,7 +799,7 @@ static struct irq_chip exynos_irq_eint = {
>>       .irq_mask_ack   = exynos_irq_eint_maskack,
>>       .irq_ack        = exynos_irq_eint_ack,
>>       .irq_set_type   = exynos_irq_eint_set_type,
>> -#ifdef CONFIG_PM
>> +#ifdef CONFIG_S5P_PM
>>       .irq_set_wake   = s3c_irqext_wake,
>>  #endif
>>  };
>> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
>> index 11fc1e2..f2b2e23 100644
>> --- a/arch/arm/mach-exynos/common.h
>> +++ b/arch/arm/mach-exynos/common.h
>> @@ -98,6 +98,5 @@ struct exynos_pmu_conf {
>>  };
>>
>>  extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
>> -extern void s3c_cpu_resume(void);
>>
>>  #endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
>> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
>> exynos/cpuidle.c
>> index 4667907..2d071c6 100644
>> --- a/arch/arm/mach-exynos/cpuidle.c
>> +++ b/arch/arm/mach-exynos/cpuidle.c
>> @@ -25,6 +25,7 @@
>>  #include <mach/regs-pmu.h>
>>
>>  #include <plat/cpu.h>
>> +#include <plat/pm.h>
>>
>>  #include "common.h"
>>
>> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
>> index f8ed2de..6c25aa6 100644
>> --- a/arch/arm/plat-samsung/Kconfig
>> +++ b/arch/arm/plat-samsung/Kconfig
>> @@ -31,6 +31,13 @@ config PLAT_S5P
>>       help
>>         Base platform code for Samsung's S5P series SoC.
>>
>> +config SAMSUNG_PM
>> +     bool
>> +     depends on PM && (PLAT_S3C24XX || ARCH_S3C64XX || S5P_PM)
>
> As we discussed before, this should be:
>
> +       depends on PM && (PLAT_S3C24XX || ARCH_S3C64XX || ARCH_S5P64X0 ||
> S5P_PM)
>
> If not, build error happens with s5p64x0_defconfig. So I fixed.
Ok, Thanks
>
>> +     default y
>> +     help
>> +       Base platform power management code for samsung code
>> +
>>  if PLAT_SAMSUNG
>>
>>  # boot configurations
>> diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-
>> samsung/Makefile
>> index a23c460..1c406b3 100644
>> --- a/arch/arm/plat-samsung/Makefile
>> +++ b/arch/arm/plat-samsung/Makefile
>> @@ -51,8 +51,7 @@ obj-$(CONFIG_SAMSUNG_DMADEV)        += dma-ops.o
>>
>>  # PM support
>>
>> -obj-$(CONFIG_PM)             += pm.o
>> -obj-$(CONFIG_PM)             += pm-gpio.o
>> +obj-$(CONFIG_SAMSUNG_PM)     += pm.o pm-gpio.o
>>  obj-$(CONFIG_SAMSUNG_PM_CHECK)       += pm-check.o
>>
>>  obj-$(CONFIG_SAMSUNG_WAKEMASK)       += wakeup-mask.o
>> diff --git a/arch/arm/plat-samsung/include/plat/pm.h b/arch/arm/plat-
>> samsung/include/plat/pm.h
>> index f6fcade..46e2c82 100644
>> --- a/arch/arm/plat-samsung/include/plat/pm.h
>> +++ b/arch/arm/plat-samsung/include/plat/pm.h
>> @@ -19,7 +19,7 @@
>>
>>  struct device;
>>
>> -#ifdef CONFIG_PM
>> +#ifdef CONFIG_SAMSUNG_PM
>>
>>  extern __init int s3c_pm_init(void);
>>  extern __init int s3c64xx_pm_init(void);
>> @@ -58,8 +58,6 @@ extern unsigned char pm_uart_udivslot;  /* true to save
>> UART UDIVSLOT */
>>
>>  /* from sleep.S */
>>
>> -extern void s3c_cpu_resume(void);
>> -
>>  extern int s3c2410_cpu_suspend(unsigned long);
>>
>>  /* sleep save info */
>> @@ -106,12 +104,14 @@ extern void s3c_pm_do_save(struct sleep_save *ptr,
>> int count);
>>  extern void s3c_pm_do_restore(struct sleep_save *ptr, int count);
>>  extern void s3c_pm_do_restore_core(struct sleep_save *ptr, int count);
>>
>> -#ifdef CONFIG_PM
>> +#ifdef CONFIG_SAMSUNG_PM
>>  extern int s3c_irq_wake(struct irq_data *data, unsigned int state);
>>  extern int s3c_irqext_wake(struct irq_data *data, unsigned int state);
>> +extern void s3c_cpu_resume(void);
>>  #else
>>  #define s3c_irq_wake NULL
>>  #define s3c_irqext_wake NULL
>> +#define s3c_cpu_resume NULL
>>  #endif
>>
>>  /* PM debug functions */
>> --
>> 1.7.1
>
> Applied into -fixes, thanks.
>
> - Kukjin
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From tobetter at gmail.com  Wed Jul 24 01:59:21 2013
From: tobetter at gmail.com (Dongjin Kim)
Date: Wed, 24 Jul 2013 14:59:21 +0900
Subject: [PATCH] ARM: dts: Add USBPHY nodes to Exynos4x12
In-Reply-To: <CAK9yfHw98L-FUtX7v32FyE4UN308uYpJXx8oxDuYgYZk1uUp_A@mail.gmail.com>
References: <1374600682-19376-1-git-send-email-tobetter@gmail.com>
 <CAK9yfHw98L-FUtX7v32FyE4UN308uYpJXx8oxDuYgYZk1uUp_A@mail.gmail.com>
Message-ID: <CADoNuNe1t8KENvdwZXzg8tZAVNuqobV7gXAaVVuSVZX8LEc2xg@mail.gmail.com>

Thanks Sachin,

On Wed, Jul 24, 2013 at 2:12 PM, Sachin Kamat <sachin.kamat at linaro.org> wrote:
> Hi Dongjin,
>
> On 23 July 2013 23:01, Dongjin Kim <tobetter at gmail.com> wrote:
>> This patch adds device nodes for USBPHY to Exynos4x12.
>>
>> Signed-off-by: Dongjin Kim <tobetter at gmail.com>
>> ---
>>  arch/arm/boot/dts/exynos4x12.dtsi |   18 ++++++++++++++++++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
>> index 01da194..9c3335b 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -73,4 +73,22 @@
>>                 clock-names = "sclk_fimg2d", "fimg2d";
>>                 status = "disabled";
>>         };
>> +
>> +       usbphy at 125B00000 {
>
> Extra 0 above.
>
This is my bad, I will fix.

>> +               #address-cells = <1>;
>> +               #size-cells = <1>;
>> +               compatible = "samsung,exynos4x12-usb2phy";
>> +               reg = <0x125B0000 0x100>;
>> +               ranges;
>> +
>> +               clocks = <&clock 2>, <&clock 305>;
>> +               clock-names = "xusbxti", "otg";
>> +               status = "disabled";
>> +
>> +               usbphy-sys {
>> +                       /* USB device and host PHY_CONTROL registers */
>> +                       reg = <0x10020704 0xc>,
>> +                             <0x1001021c 0x4>;
>> +               };
>> +       };
>>  };
>
> Please add this node after tmu node (satisfies alphabetical order as
> well as increasing address value)
No tmu node in exynos4x12.dtsi in mainline v3.11-rc2 yet, even in
Kukjin's branch.

>
>
> --
> With warm regards,
> Sachin


From amit.daniel at samsung.com  Wed Jul 24 01:59:51 2013
From: amit.daniel at samsung.com (amit daniel kachhap)
Date: Wed, 24 Jul 2013 11:29:51 +0530
Subject: [PATCH V2 2/2] ARM: EXYNOS: cpuidle: Allow C1 state only in
 supported SOC's.
In-Reply-To: <0e2301ce882c$d39021a0$7ab064e0$@org>
References: <1371036526-16589-1-git-send-email-amit.daniel@samsung.com>
 <1371036526-16589-3-git-send-email-amit.daniel@samsung.com>
 <0e2301ce882c$d39021a0$7ab064e0$@org>
Message-ID: <CADGdYn5uY7A9OB=xGi_oKS3DX6+wRhbKBnTfxjkFY5OtUX3hXg@mail.gmail.com>

Hi,

On Wed, Jul 24, 2013 at 10:45 AM, Kukjin Kim <kgene at kernel.org> wrote:
> Amit Daniel Kachhap wrote:
>>
>> This patch registers the basic C0 state for all exynos SOC's but
>> limits the C1(AFTR -Arm off top running) state in only the supported
>> SOC's(ie. EXYNOS 4210, 4212, 4412 and 5250).
>>
>> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
>> ---
>>  arch/arm/mach-exynos/cpuidle.c |    4 +++-
>>  1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
>> exynos/cpuidle.c
>> index 2d071c6..ccb2b48 100644
>> --- a/arch/arm/mach-exynos/cpuidle.c
>> +++ b/arch/arm/mach-exynos/cpuidle.c
>> @@ -176,7 +176,9 @@ static int __init exynos4_init_cpuidle(void)
>>               device->cpu = cpu_id;
>>
>>               /* Support IDLE only */
>> -             if (cpu_id != 0)
>> +             if (!(soc_is_exynos4210() || soc_is_exynos4212() ||
>> +                     soc_is_exynos4412() || soc_is_exynos5250()) ||
>> +                     cpu_id != 0)
>
> How about exynos5420?
>
> So...
>
> +               if (soc_is_exynos5440() || cpu_id !=0) ?
This is fine.

Thanks,
Amit
>
>>                       device->state_count = 1;
>>
>>               ret = cpuidle_register_device(device);
>> --
>> 1.7.1
>
> - Kukjin
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From g.liakhovetski at gmx.de  Wed Jul 24 02:11:33 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Wed, 24 Jul 2013 08:11:33 +0200 (CEST)
Subject: [PATCH 01/19] ARM: shmobile: r8a73a4: Add pin control device to
 device tree
In-Reply-To: <803d319cb2fb41e646669061b45701f3ea78e611.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
 <803d319cb2fb41e646669061b45701f3ea78e611.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <Pine.LNX.4.64.1307240811080.30777@axis700.grange>

Hi Simon

On Wed, 24 Jul 2013, Simon Horman wrote:

> From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> 
> Add a pfc node to the r8a73a4 device tree.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> [g.liakhovetski+renesas at gmail.com use 2 nodes for address and size]

it's actually "cells," not "nodes."

Thanks
Guennadi

> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> ---
>  arch/arm/boot/dts/r8a73a4.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
> index 4ff2019..b886afd 100644
> --- a/arch/arm/boot/dts/r8a73a4.dtsi
> +++ b/arch/arm/boot/dts/r8a73a4.dtsi
> @@ -85,4 +85,11 @@
>  		interrupt-parent = <&gic>;
>  		interrupts = <0 69 4>;
>  	};
> +
> +	pfc: pfc at e6050000 {
> +		compatible = "renesas,pfc-r8a73a4";
> +		reg = <0 0xe6050000 0 0x9000>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +	};
>  };
> -- 
> 1.8.2.1
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From richard.zhuhongxing at gmail.com  Wed Jul 24 02:15:26 2013
From: richard.zhuhongxing at gmail.com (Richard Zhu)
Date: Wed, 24 Jul 2013 14:15:26 +0800
Subject: [PATCH v8 0/3] ahci: enable ahci sata support on imx6q
Message-ID: <1374646529-24432-1-git-send-email-Hong-Xing.Zhu@freescale.com>

v8: add imx6q specific ahci sata support
  - Regarding to Tejun's comments, rename the sata_imx driver
  to be ahci_imx
  - Add Shawn's ack and review signoff.
  - 

v7: http://www.spinics.net/lists/linux-ide/msg45738.html
  Thanks to Sergei Shtylyow and Shawn.
  - According to ePAPR [1] section 2.2.2, re-name
  the node from 'ahci' to 'sata'
  - Move the initialization of the ahb clock of the private
  data to the probe function.
  - Remove the platform_set_drvdata(..., NULL), and devm_clk_put
  (..., ...).
  - 

v6: http://www.spinics.net/lists/linux-ide/msg45719.html
  Thanks for Shawn's comments.
  - Speicify the ahb clock in the sata related dts changes.
  - Move the initialization of the sata PHY clock of the private
  data to the probe function.
  - Remove the empty device release function.
  - In order to be more readable, rename the imx_dev/imx_ahci_pdev
  to be ahci_dev/ahci_pdev, and do some other changes, such as typo
  error, more readable name of the variable.
  - 

v5: http://www.spinics.net/lists/linux-ide/msg45712.html
  - Fix the wrong referrence usage of the private data.
  - Use the private data to contain the poninter of the PHY
  signals adjustment window(gpr)
  - Tested on imx6q sd board.
  - 

v4: http://www.spinics.net/lists/linux-ide/msg45699.html
  Thanks for the review comments provided by Sascha, and Alexander.
  - Use the private data and keep a pointer to the PHY clock.
  - Don't use the global platform device variable, because that
  it would make the driver broken for mutiple instances.
  - Don't do the "writel" with assignment.
  - Other minor changes, such as print the error code when printing
  error message, use a u32 type to store readl results, and so on.

v3: http://www.spinics.net/lists/linux-ide/msg45688.html
  - Keep arch/arm and ahci_platform driver clean.
  - Add the sata_imx standalone driver contained all the
  specific setup
  - Add the release function, support the loadable module
  driver.
  - Tested on imx6q sd board.

v2: http://www.spinics.net/lists/linux-ide/msg45666.html 
 - Setup standalone imx ahci sata driver, because of
 the misalignments of the bits definition of the HBA register.
 - Replace the node by the label in the board dts.
 - 

v1: http://www.spinics.net/lists/linux-ide/msg45581.html
 - add imx6q specific ahci sata support to arch/arm/mach-imx/mach-imx6q.c

These patches is based on imx/dt branch of
"http://git.linaro.org/git-ro/people/shawnguo/linux-2.6.git"

[v8 1/3] ARM: dtsi: enable ahci sata on imx6q platforms
[v8 2/3] ARM: imx6q: update the sata bits definitions of gpr13
[v8 3/3] ahci_imx: add ahci sata support on imx platforms

arch/arm/boot/dts/imx6q-sabreauto.dts       |    4 +
arch/arm/boot/dts/imx6q-sabrelite.dts       |    4 +
arch/arm/boot/dts/imx6q-sabresd.dts         |    4 +
arch/arm/boot/dts/imx6q.dtsi                |    9 +
drivers/ata/Kconfig                         |    9 +
drivers/ata/Makefile                        |    1 +
drivers/ata/ahci_imx.c                      |  236 +++++++++++++++++++++++++++
include/linux/mfd/syscon/imx6q-iomuxc-gpr.h |  121 ++++++++++----
8 files changed, 351 insertions(+), 37 deletions(-)


From sachin.kamat at linaro.org  Wed Jul 24 02:16:39 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Wed, 24 Jul 2013 11:46:39 +0530
Subject: [PATCH] ARM: dts: Add USBPHY nodes to Exynos4x12
In-Reply-To: <CADoNuNe1t8KENvdwZXzg8tZAVNuqobV7gXAaVVuSVZX8LEc2xg@mail.gmail.com>
References: <1374600682-19376-1-git-send-email-tobetter@gmail.com>
 <CAK9yfHw98L-FUtX7v32FyE4UN308uYpJXx8oxDuYgYZk1uUp_A@mail.gmail.com>
 <CADoNuNe1t8KENvdwZXzg8tZAVNuqobV7gXAaVVuSVZX8LEc2xg@mail.gmail.com>
Message-ID: <CAK9yfHzXg_U=dgkJ=vqmme+VxXCw=WcRdCU-7V1_hPzRrgTyPQ@mail.gmail.com>

On 24 July 2013 11:29, Dongjin Kim <tobetter at gmail.com> wrote:
> Thanks Sachin,
>
> On Wed, Jul 24, 2013 at 2:12 PM, Sachin Kamat <sachin.kamat at linaro.org> wrote:
>> Hi Dongjin,
>>
>> On 23 July 2013 23:01, Dongjin Kim <tobetter at gmail.com> wrote:
>>> This patch adds device nodes for USBPHY to Exynos4x12.
>>>
>>> Signed-off-by: Dongjin Kim <tobetter at gmail.com>
>>> ---
>>>  arch/arm/boot/dts/exynos4x12.dtsi |   18 ++++++++++++++++++
>>>  1 file changed, 18 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
>>> index 01da194..9c3335b 100644
>>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>>> @@ -73,4 +73,22 @@
>>>                 clock-names = "sclk_fimg2d", "fimg2d";
>>>                 status = "disabled";
>>>         };
>>> +
>>> +       usbphy at 125B00000 {
>>
>> Extra 0 above.
>>
> This is my bad, I will fix.
>
>>> +               #address-cells = <1>;
>>> +               #size-cells = <1>;
>>> +               compatible = "samsung,exynos4x12-usb2phy";
>>> +               reg = <0x125B0000 0x100>;
>>> +               ranges;
>>> +
>>> +               clocks = <&clock 2>, <&clock 305>;
>>> +               clock-names = "xusbxti", "otg";
>>> +               status = "disabled";
>>> +
>>> +               usbphy-sys {
>>> +                       /* USB device and host PHY_CONTROL registers */
>>> +                       reg = <0x10020704 0xc>,
>>> +                             <0x1001021c 0x4>;
>>> +               };
>>> +       };
>>>  };
>>
>> Please add this node after tmu node (satisfies alphabetical order as
>> well as increasing address value)
> No tmu node in exynos4x12.dtsi in mainline v3.11-rc2 yet, even in
> Kukjin's branch.

Sorry, that patch is not yet applied to for-next. I will re-send
again. You may ignore this comment for now.

-- 
With warm regards,
Sachin


From kgene at kernel.org  Wed Jul 24 02:20:57 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 24 Jul 2013 15:20:57 +0900
Subject: [PATCH v3 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <1374636693-32336-1-git-send-email-sachin.kamat@linaro.org>
References: <1374636693-32336-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <0e4301ce8835$f5bef5e0$e13ce1a0$@org>

Sachin Kamat wrote:
> 
> With the recent cleanup in Exynos platform code notably commits
> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
> more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
> Exynos4412 which have more than the default number of GPIOs. Thus define
> this number in KConfig file which takes care of current SoC requirements
> and provides scope for GPIO expanders. Without this patch we get the
> following
> errors during boot:
> 
> gpiochip_add: gpios 251..258 (gpv0) failed to register
> samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
> error code: -22
> samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
> 
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> Cc: Tomasz Figa <t.figa at samsung.com>
> ---
> Changes since v2:
> Changed the default number to 512 to accomodate GPIO exapnders.
> ---
>  arch/arm/Kconfig |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index ccc388d..b3c4fa4 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1601,6 +1601,7 @@ config ARCH_NR_GPIO
>  	int
>  	default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
>  	default 512 if SOC_OMAP5
> +	default 512 if ARCH_EXYNOS
>  	default 512 if ARCH_KEYSTONE

+	default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 ?

Thanks,
Kukjin

>  	default 392 if ARCH_U8500
>  	default 352 if ARCH_VT8500
> --
> 1.7.9.5



From sachin.kamat at linaro.org  Wed Jul 24 02:22:40 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Wed, 24 Jul 2013 11:52:40 +0530
Subject: [PATCH v3 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <0e4301ce8835$f5bef5e0$e13ce1a0$@org>
References: <1374636693-32336-1-git-send-email-sachin.kamat@linaro.org>
 <0e4301ce8835$f5bef5e0$e13ce1a0$@org>
Message-ID: <CAK9yfHz-UcA0--Md0YfrTkPvqzZncTcu-6a-AaHbiWx2tJZczw@mail.gmail.com>

On 24 July 2013 11:50, Kukjin Kim <kgene at kernel.org> wrote:
> Sachin Kamat wrote:
>>
>> With the recent cleanup in Exynos platform code notably commits
>> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
>> more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
>> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
>> Exynos4412 which have more than the default number of GPIOs. Thus define
>> this number in KConfig file which takes care of current SoC requirements
>> and provides scope for GPIO expanders. Without this patch we get the
>> following
>> errors during boot:
>>
>> gpiochip_add: gpios 251..258 (gpv0) failed to register
>> samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
>> error code: -22
>> samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
>> Cc: Tomasz Figa <t.figa at samsung.com>
>> ---
>> Changes since v2:
>> Changed the default number to 512 to accomodate GPIO exapnders.
>> ---
>>  arch/arm/Kconfig |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index ccc388d..b3c4fa4 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1601,6 +1601,7 @@ config ARCH_NR_GPIO
>>       int
>>       default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
>>       default 512 if SOC_OMAP5
>> +     default 512 if ARCH_EXYNOS
>>       default 512 if ARCH_KEYSTONE
>
> +       default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 ?

Looks good. Do you want me to re-send this?



-- 
With warm regards,
Sachin


From b44548 at freescale.com  Wed Jul 24 01:32:19 2013
From: b44548 at freescale.com (Chao Fu)
Date: Wed, 24 Jul 2013 13:32:19 +0800
Subject: [PATCH v2 0/4]Add Freescale DSPI driver for Vybrid VF610 platform 
Message-ID: <1374643943-3324-1-git-send-email-b44548@freescale.com>

This driver is the SPI master mode driver and has been tested on Vybrid VF610TWR board.
Changes in v2:
- Add a document for DSPI driver under Documentation/devicetree/bindings/spi/.
- Move spi-num-chipselects info dtsi nodes.





From b44548 at freescale.com  Wed Jul 24 01:32:20 2013
From: b44548 at freescale.com (Chao Fu)
Date: Wed, 24 Jul 2013 13:32:20 +0800
Subject: [PATCH v2 1/4] ARM:dts: vf610: Add DSPI nodes
In-Reply-To: <1374643943-3324-1-git-send-email-b44548@freescale.com>
References: <1374643943-3324-1-git-send-email-b44548@freescale.com>
Message-ID: <1374643943-3324-2-git-send-email-b44548@freescale.com>

From: Chao Fu <B44548 at freescale.com>

Add Freescale DSPI node into vf610 dts.

Signed-off-by: Chao Fu <b44548 at freescale.com>
---
Changes in v2: 
Add spi-num-chipselects info soc property.

 arch/arm/boot/dts/vf610.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index e1eb7da..ac78e3a 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -87,6 +87,18 @@
 				arm,tag-latency = <2 2 2>;
 			};
 
+			dspi0: dspi0 at 4002c000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "fsl,vf610-dspi";
+				reg = <0x4002c000 0x1000>;
+				interrupts = <0 67 0x04>;
+				clocks = <&clks VF610_CLK_DSPI0>;
+				clock-names = "dspi";
+				spi-num-chipselects = <5>;
+				status = "disabled";
+			};
+
 			uart0: serial at 40027000 {
 				compatible = "fsl,vf610-lpuart";
 				reg = <0x40027000 0x1000>;
-- 
1.8.0




From b44548 at freescale.com  Wed Jul 24 01:32:21 2013
From: b44548 at freescale.com (Chao Fu)
Date: Wed, 24 Jul 2013 13:32:21 +0800
Subject: [PATCH v2 2/4] ARM:dts:vf610-twr:Enable DSPI0 devices and Flash
 at26df081a
In-Reply-To: <1374643943-3324-1-git-send-email-b44548@freescale.com>
References: <1374643943-3324-1-git-send-email-b44548@freescale.com>
Message-ID: <1374643943-3324-3-git-send-email-b44548@freescale.com>

From: Chao Fu <B44548 at freescale.com>

This patch enables DSPI0 and at26df081a flash device for Vybrid VF610 TOWER board.

Signed-off-by: Chao Fu <b44548 at freescale.com>
---
Changes in v2: 
Remove item spi-num-chipselects. 

 arch/arm/boot/dts/vf610-twr.dts | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index b3905f5..ff943fc 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -36,6 +36,27 @@
 
 };
 
+&dspi0 {
+	bus-num = <0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_dspi0_1>;
+	status = "okay";
+
+	sflash: at26df081a at 0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "atmel,at26df081a";
+		spi-max-frequency = <16000000>;
+		spi-cpol;
+		spi-cpha;
+		dspi,ctar-dbr = <0>;
+		dspi,ctar-pbr = <0>;
+		reg = <0>;
+		linux,modalias = "m25p80";
+		modal = "at26df081a";
+	};
+};
+
 &fec0 {
 	phy-mode = "rmii";
 	pinctrl-names = "default";
-- 
1.8.0




From b44548 at freescale.com  Wed Jul 24 01:32:22 2013
From: b44548 at freescale.com (Chao Fu)
Date: Wed, 24 Jul 2013 13:32:22 +0800
Subject: [PATCH v2 3/4] Documentation: DT: Add DSPI driver
In-Reply-To: <1374643943-3324-1-git-send-email-b44548@freescale.com>
References: <1374643943-3324-1-git-send-email-b44548@freescale.com>
Message-ID: <1374643943-3324-4-git-send-email-b44548@freescale.com>

From: Chao Fu <B44548 at freescale.com>

This patch adds the document for DSPI driver
under Documentation/devicetree/bindings/spi/.

Signed-off-by: Chao Fu <b44548 at freescale.com>
---
Changes in v2: New
- Add this document for DSPI driver.

.../devicetree/bindings/spi/spi-fsl-dspi.txt       | 73 ++++++++++++++++++++++
 1 file changed, 73 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt

diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
new file mode 100644
index 0000000..8911348
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
@@ -0,0 +1,73 @@
+ARM Freescale DSPI controller
+
+Required properties:
+- compatible : "fsl,vf610-dspi"
+- reg : Offset and length of the register set for the device
+- interrupts : Should contain SPI controller interrupt
+- clocks: from common clock binding: handle to dspi clock.
+- clock-names: from common clock binding: Shall be "dspi".
+- pinctrl-0: pin control group to be used for this controller.
+- pinctrl-names: must contain a "default" entry.
+- spi-num-chipselects : the number of the chipselect signals.
+- bus-num : the slave chip chipselect signal number.
+
+SPI slave nodes must be children of the SPI master node and can
+contain the following properties.
+
+-dspi,ctar-dbr : Double baud rate
+Doubles the effective baud rate of the Serial Communications Clock (SCK). This field is used only in
+master mode. It effectively halves the Baud Rate division ratio, supporting faster frequencies, and odd
+division ratios for the Serial Communications Clock (SCK). When the DBR bit is set, the duty cycle of the
+Serial Communications Clock (SCK) depends on the value in the Baud Rate Prescaler and the Clock
+Phase bit as listed in the following table.
+	DBR CPHA PBR SCK Duty Cycle
+	0   any  any 50/50
+	1   0    00  50/50
+	1   0    01  33/66
+	1   0    10  40/60
+	1   0    11  43/57
+	1   1    00  50/50
+	1   1    01  66/33
+	1   1    10  60/40
+	1   1    11  57/43
+0: The baud rate is computed normally with a 50/50 duty cycle.
+1: The baud rate is doubled with the duty cycle depending on the Baud Rate Prescaler.
+
+-dspi,ctar-pbr : Baud Rate Prescaler
+	0: Baud Rate Prescaler value is 2.
+	1: Baud Rate Prescaler value is 3.
+	2: Baud Rate Prescaler value is 5.
+	3: Baud Rate Prescaler value is 7.
+
+Example:
+
+dspi0 at 4002c000 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	compatible = "fsl,vf610-dspi";
+	reg = <0x4002c000 0x1000>;
+	interrupts = <0 67 0x04>;
+	clocks = <&clks VF610_CLK_DSPI0>;
+	clock-names = "dspi";
+	spi-num-chipselects = <5>;
+	bus-num = <0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_dspi0_1>;
+	status = "okay";
+
+	sflash: at26df081a at 0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "atmel,at26df081a";
+		spi-max-frequency = <16000000>;
+		spi-cpol;
+		spi-cpha;
+		dspi,ctar-dbr = <0>;
+		dspi,ctar-pbr = <0>;
+		reg = <0>;
+		linux,modalias = "m25p80";
+		modal = "at26df081a";
+	};
+};
+
+
-- 
1.8.0




From b44548 at freescale.com  Wed Jul 24 01:32:23 2013
From: b44548 at freescale.com (Chao Fu)
Date: Wed, 24 Jul 2013 13:32:23 +0800
Subject: [PATCH v2 4/4] spi:Add Freescale DSPI driver for Vybrid VF610 platform
In-Reply-To: <1374643943-3324-1-git-send-email-b44548@freescale.com>
References: <1374643943-3324-1-git-send-email-b44548@freescale.com>
Message-ID: <1374643943-3324-5-git-send-email-b44548@freescale.com>

From: Chao Fu <B44548 at freescale.com>

The serial peripheral interface (SPI) module implemented
on Freescale Vybrid platform provides a synchronous serial
bus for communication between Vybrid and the external
peripheral device.
The SPI supports full-duplex, three-wire synchronous transfer,
has TX/RX FIFO with depth of four entries.

This driver is the SPI master mode driver and has been tested on Vybrid VF610TWR board.

Signed-off-by: Alison Wang <b18965 at freescale.com>
Signed-off-by: Chao Fu  <b44548 at freescale.com>
---
Changes in v2: None

 drivers/spi/Kconfig        |   6 +
 drivers/spi/Makefile       |   1 +
 drivers/spi/spi-fsl-dspi.c | 673 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 680 insertions(+)
 create mode 100644 drivers/spi/spi-fsl-dspi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 89cbbab..068715d 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -248,6 +248,12 @@ config SPI_FSL_SPI
 	  This also enables using the Aeroflex Gaisler GRLIB SPI controller in
 	  master mode.
 
+config SPI_FSL_DSPI
+         tristate "Freescale DSPI controller"
+         help
+         This enables support for the Freescale DSPI controller in master
+         mode.
+
 config SPI_FSL_ESPI
 	bool "Freescale eSPI controller"
 	depends on FSL_SOC
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 33f9c09..78416fd 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_SPI_EP93XX)		+= spi-ep93xx.o
 obj-$(CONFIG_SPI_FALCON)		+= spi-falcon.o
 obj-$(CONFIG_SPI_FSL_CPM)		+= spi-fsl-cpm.o
 obj-$(CONFIG_SPI_FSL_LIB)		+= spi-fsl-lib.o
+obj-$(CONFIG_SPI_FSL_DSPI)		+= spi-fsl-dspi.o
 obj-$(CONFIG_SPI_FSL_ESPI)		+= spi-fsl-espi.o
 obj-$(CONFIG_SPI_FSL_SPI)		+= spi-fsl-spi.o
 obj-$(CONFIG_SPI_GPIO)			+= spi-gpio.o
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
new file mode 100644
index 0000000..a187b6f
--- /dev/null
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -0,0 +1,673 @@
+/*
+ * drivers/spi/spi-fsl-dspi.c
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Freescale DSPI driver
+ * This file contains a driver for the Freescale DSPI
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/errno.h>
+#include <linux/platform_device.h>
+#include <linux/sched.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/spi/spi.h>
+#include <linux/pm_runtime.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+
+#define DRIVER_NAME "fsl-dspi"
+
+#define TRAN_STATE_RX_VOID		0x01
+#define TRAN_STATE_TX_VOID		0x02
+#define TRAN_STATE_WORD_ODD_NUM		0x04
+
+#define DSPI_FIFO_SIZE			4
+
+#define SPI_MCR			0x00
+#define SPI_TCR			0x08
+
+#define SPI_CTAR(x)		(0x0c + (x * 4))
+#define SPI_CTAR_FMSZ(x)	(((x) & 0x0000000f) << 27)
+#define SPI_CTAR_CPOL(x)	((x) << 26)
+#define SPI_CTAR_CPHA(x)	((x) << 25)
+#define SPI_CTAR_PCSSCR(x)	(((x) & 0x00000003) << 22)
+#define SPI_CTAR_PASC(x)	(((x) & 0x00000003) << 20)
+#define SPI_CTAR_PDT(x)		(((x) & 0x00000003) << 18)
+#define SPI_CTAR_PBR(x)		(((x) & 0x00000003) << 16)
+#define SPI_CTAR_CSSCK(x)	(((x) & 0x0000000f) << 12)
+#define SPI_CTAR_ASC(x)		(((x) & 0x0000000f) << 8)
+#define SPI_CTAR_DT(x)		(((x) & 0x0000000f) << 4)
+#define SPI_CTAR_BR(x)		((x) & 0x0000000f)
+
+#define SPI_CTAR0_SLAVE		0x0c
+
+#define SPI_SR			0x2c
+#define SPI_SR_EOQF		0x10000000
+
+#define SPI_RSER		0x30
+#define SPI_RSER_EOQFE		0x10000000
+
+#define SPI_PUSHR		0x34
+#define SPI_PUSHR_CONT		(1 << 31)
+#define SPI_PUSHR_CTAS(x)	(((x) & 0x00000007) << 28)
+#define SPI_PUSHR_EOQ		(1 << 27)
+#define SPI_PUSHR_CTCNT		(1 << 26)
+#define SPI_PUSHR_PCS(x)	(((1 << x) & 0x0000003f) << 16)
+#define SPI_PUSHR_TXDATA(x)	((x) & 0x0000ffff)
+
+#define SPI_PUSHR_SLAVE		0x34
+
+#define SPI_POPR		0x38
+#define SPI_POPR_RXDATA(x)	((x) & 0x0000ffff)
+
+#define SPI_TXFR0		0x3c
+#define SPI_TXFR1		0x40
+#define SPI_TXFR2		0x44
+#define SPI_TXFR3		0x48
+#define SPI_RXFR0		0x7c
+#define SPI_RXFR1		0x80
+#define SPI_RXFR2		0x84
+#define SPI_RXFR3		0x88
+
+#define SPI_FRAME_BITS		SPI_CTAR_FMSZ(0xf)
+#define SPI_FRAME_BITS_16	SPI_CTAR_FMSZ(0xf)
+#define SPI_FRAME_BITS_8	SPI_CTAR_FMSZ(0x7)
+
+#define SPI_CS_INIT		0x01
+#define SPI_CS_ASSERT		0x02
+#define SPI_CS_DROP		0x04
+
+struct DSPI_MCR {
+	unsigned halt:1;
+	unsigned reserved71:7;
+	unsigned smpl_pt:2;
+	unsigned clr_rxf:1;
+	unsigned clr_tx:1;
+	unsigned dis_rxf:1;
+	unsigned dis_tx:1;
+	unsigned mdis:1;
+	unsigned reserved15:1;
+	unsigned pcsis:8;
+	unsigned rooe:1;
+	unsigned pcsse:1;
+	unsigned mtfe:1;
+	unsigned frz:1;
+	unsigned dconf:2;
+	unsigned cont_scke:1;
+	unsigned master:1;
+};
+
+struct DSPI_CTAR {
+	unsigned br:4;
+	unsigned dt:4;
+	unsigned asc:4;
+	unsigned cssck:4;
+	unsigned pbr:2;
+	unsigned pdt:2;
+	unsigned pasc:2;
+	unsigned pcssck:2;
+	unsigned lsbfe:1;
+	unsigned cpha:1;
+	unsigned cpol:1;
+	unsigned fmsz:4;
+	unsigned dbr:1;
+};
+
+struct chip_data {
+	/* dspi data */
+	union {
+		u32 mcr_val;
+		struct DSPI_MCR mcr;
+	};
+	union {
+		u32 ctar_val;
+		struct DSPI_CTAR ctar;
+	};
+	u16 void_write_data;
+};
+
+struct fsl_dspi {
+	struct platform_device *pdev;
+	struct spi_master *master;
+
+	void *base;
+	int irq;
+	struct clk *clk;
+
+	struct spi_message *cur_msg;
+	struct spi_transfer *cur_transfer;
+	struct chip_data *cur_chip;
+	size_t len;
+	void *tx;
+	void *tx_end;
+	void *rx;
+	void *rx_end;
+	char dataflags;
+	u8 cs;
+	u16 void_write_data;
+	unsigned	cs_change:1;
+
+	wait_queue_head_t waitq;
+	u32 waitflags;
+};
+
+/* SPI local functions */
+static inline int is_word_transfer(struct fsl_dspi *dspi)
+{
+	return ((readl(dspi->base + SPI_CTAR(dspi->cs)) & SPI_FRAME_BITS)
+			== SPI_FRAME_BITS_8) ? 0 : 1;
+}
+
+static void set_8bit_transfer_mode(struct fsl_dspi *dspi)
+{
+	u32 temp;
+
+	temp = readl(dspi->base + SPI_CTAR(dspi->cs));
+	temp &= ~SPI_FRAME_BITS;
+	temp |= SPI_FRAME_BITS_8;
+	writel(temp, dspi->base + SPI_CTAR(dspi->cs));
+}
+
+static void set_16bit_transfer_mode(struct fsl_dspi *dspi)
+{
+	u32 temp;
+
+	temp = readl(dspi->base + SPI_CTAR(dspi->cs));
+	temp &= ~SPI_FRAME_BITS;
+	temp |= SPI_FRAME_BITS_16;
+	writel(temp, dspi->base + SPI_CTAR(dspi->cs));
+}
+
+static unsigned char hz_to_spi_baud(int pbr, int dbr, int speed_hz,
+		unsigned long clkrate)
+{
+	/* Valid baud rate pre-scaler values */
+	int pbr_tbl[4] = {2, 3, 5, 7};
+	int brs[16] = {	2,	4,	6,	8,
+		16,	32,	64,	128,
+		256,	512,	1024,	2048,
+		4096,	8192,	16384,	32768 };
+	int temp, index = 0;
+
+	/* table indexes out of range, go slow */
+	if ((pbr < 0) || (pbr > 3) || (dbr < 0) || (dbr > 1))
+		return 15;
+
+	/* cpu core clk need to check */
+	temp = ((((clkrate / 2) / pbr_tbl[pbr]) * (1 + dbr)) / speed_hz);
+
+	while (temp > brs[index])
+		if (index++ >= 15)
+			break;
+
+	return index;
+}
+
+static void dspi_setup_chip(struct fsl_dspi *dspi)
+{
+	struct chip_data *chip = dspi->cur_chip;
+
+	writel(chip->mcr_val, dspi->base + SPI_MCR);
+	writel(chip->ctar_val, dspi->base + SPI_CTAR(dspi->cs));
+	writel(SPI_RSER_EOQFE, dspi->base + SPI_RSER);
+}
+
+static int dspi_transfer_write(struct fsl_dspi *dspi)
+{
+	int tx_count = 0;
+	int tx_word;
+	u16 d16;
+	u8  d8;
+	u32 dspi_pushr = 0;
+	int first = 1;
+
+	tx_word = is_word_transfer(dspi);
+	/* If we are in word mode, but only have a single byte to transfer
+	 * then switch to byte mode temporarily.  Will switch back at the
+	 * end of the transfer. */
+	if (tx_word && (dspi->len == 1)) {
+		dspi->dataflags |= TRAN_STATE_WORD_ODD_NUM;
+		set_8bit_transfer_mode(dspi);
+		tx_word = 0;
+	}
+	while (dspi->len && (tx_count < DSPI_FIFO_SIZE)) {
+		if (tx_word) {
+			if (dspi->len == 1)
+				break;
+
+			if (!(dspi->dataflags & TRAN_STATE_TX_VOID)) {
+				d16 = *(u16 *)dspi->tx;
+				dspi->tx += 2;
+			} else {
+				d16 = dspi->void_write_data;
+			}
+
+			dspi_pushr = SPI_PUSHR_TXDATA(d16) |
+				SPI_PUSHR_PCS(dspi->cs) |
+				SPI_PUSHR_CTAS(dspi->cs) |
+				SPI_PUSHR_CONT;
+
+			dspi->len -= 2;
+		} else {
+			if (!(dspi->dataflags & TRAN_STATE_TX_VOID)) {
+
+				d8 = *(u8 *)dspi->tx;
+				dspi->tx++;
+			} else {
+				d8 = (u8)dspi->void_write_data;
+			}
+
+			dspi_pushr = SPI_PUSHR_TXDATA(d8) |
+				SPI_PUSHR_PCS(dspi->cs) |
+				SPI_PUSHR_CTAS(dspi->cs) |
+				SPI_PUSHR_CONT;
+
+			dspi->len--;
+		}
+
+		if (dspi->len == 0
+				|| tx_count == DSPI_FIFO_SIZE - 1) {
+			/* last transfer in the queue */
+			dspi_pushr |= SPI_PUSHR_EOQ;
+			if ((dspi->cs_change)
+					&& (!dspi->len))
+				dspi_pushr &= ~SPI_PUSHR_CONT;
+		} else if (tx_word && (dspi->len == 1))
+			dspi_pushr |= SPI_PUSHR_EOQ;
+
+		if (first) {
+			first = 0;
+			dspi_pushr |= SPI_PUSHR_CTCNT; /* clear counter */
+		}
+
+		writel(dspi_pushr, dspi->base + SPI_PUSHR);
+		tx_count++;
+	}
+
+	return tx_count * (tx_word + 1);
+}
+static int dspi_transfer_read(struct fsl_dspi *dspi)
+{
+	int rx_count = 0;
+	int rx_word = is_word_transfer(dspi);
+	u16 d;
+	while ((dspi->rx < dspi->rx_end)
+			&& (rx_count < DSPI_FIFO_SIZE)) {
+		if (rx_word) {
+			if ((dspi->rx_end - dspi->rx) == 1)
+				break;
+
+			d = SPI_POPR_RXDATA(readl(dspi->base + SPI_POPR));
+
+			if (!(dspi->dataflags & TRAN_STATE_RX_VOID))
+				*(u16 *)dspi->rx = d;
+			dspi->rx += 2;
+
+		} else {
+			d = SPI_POPR_RXDATA(readl(dspi->base + SPI_POPR));
+			if (!(dspi->dataflags & TRAN_STATE_RX_VOID))
+				*(u8 *)dspi->rx = d;
+			dspi->rx++;
+		}
+		rx_count++;
+	}
+
+	return rx_count;
+}
+
+static int dspi_transfer_one_message(struct spi_master *master,
+		struct spi_message *message)
+{
+	struct fsl_dspi *dspi = spi_master_get_devdata(master);
+	struct spi_device *spi = message->spi;
+	struct spi_transfer *transfer;
+	int status = 0;
+	message->actual_length = 0;
+
+	list_for_each_entry(transfer, &message->transfers, transfer_list) {
+		dspi->cur_msg = message;
+		dspi->cur_transfer = transfer;
+		dspi->cur_chip = spi_get_ctldata(spi);
+		dspi->cs = spi->chip_select;
+		if (dspi->cur_transfer->transfer_list.next
+				== &dspi->cur_msg->transfers)
+			transfer->cs_change = 1;
+		dspi->cs_change = transfer->cs_change;
+		dspi->void_write_data = dspi->cur_chip->void_write_data;
+
+		dspi_setup_chip(dspi);
+
+		dspi->dataflags = 0;
+		dspi->tx = (void *)transfer->tx_buf;
+		dspi->tx_end = dspi->tx + transfer->len;
+		dspi->rx = transfer->rx_buf;
+		dspi->rx_end = dspi->rx + transfer->len;
+		dspi->len = transfer->len;
+
+		if (!dspi->rx)
+			dspi->dataflags |= TRAN_STATE_RX_VOID;
+
+		if (!dspi->tx)
+			dspi->dataflags |= TRAN_STATE_TX_VOID;
+
+		if (transfer->speed_hz)
+			writel((dspi->cur_chip->ctar_val & ~0xf) |
+				hz_to_spi_baud(dspi->cur_chip->ctar.pbr,
+					dspi->cur_chip->ctar.dbr,
+					transfer->speed_hz,
+					clk_get_rate(dspi->clk)),
+					dspi->base + SPI_CTAR(dspi->cs));
+
+		message->actual_length += dspi_transfer_write(dspi);
+
+		wait_event_interruptible(dspi->waitq, dspi->waitflags);
+		dspi->waitflags = 0;
+
+		if (transfer->delay_usecs)
+			udelay(transfer->delay_usecs);
+	}
+	message->status = status;
+	spi_finalize_current_message(master);
+
+	return status;
+}
+
+static int dspi_prepare_transfer_hw(struct spi_master *master)
+{
+	struct fsl_dspi *dspi = spi_master_get_devdata(master);
+
+	pm_runtime_get_sync(&dspi->pdev->dev);
+
+	return 0;
+}
+
+static int dspi_unprepare_transfer_hw(struct spi_master *master)
+{
+	struct fsl_dspi *dspi = spi_master_get_devdata(master);
+
+	pm_runtime_put_sync(&dspi->pdev->dev);
+
+	return 0;
+}
+
+static int dspi_setup(struct spi_device *spi)
+{
+	struct chip_data *chip;
+	struct fsl_dspi *dspi = spi_master_get_devdata(spi->master);
+	struct device_node *np = spi->dev.of_node;
+	unsigned char br = 0;
+	unsigned int dbr = 0 , pbr = 0;
+
+	/* Only alloc on first setup */
+	chip = spi_get_ctldata(spi);
+	if (chip == NULL) {
+		chip = kcalloc(1, sizeof(struct chip_data), GFP_KERNEL);
+		if (!chip)
+			return -ENOMEM;
+	}
+
+	chip->mcr.master = 1;
+	chip->mcr.cont_scke = 0;
+	chip->mcr.dconf = 0;
+	chip->mcr.frz = 0;
+	chip->mcr.mtfe = 0;
+	chip->mcr.pcsse = 0;
+	chip->mcr.rooe = 0;
+	chip->mcr.pcsis = 0xFF;
+	chip->mcr.reserved15 = 0;
+	chip->mcr.mdis = 0;
+	chip->mcr.dis_tx = 0;
+	chip->mcr.dis_rxf = 0;
+	chip->mcr.clr_tx = 1;
+	chip->mcr.clr_rxf = 1;
+	chip->mcr.smpl_pt = 0;
+	chip->mcr.reserved71 = 0;
+	chip->mcr.halt = 0;
+
+	if ((spi->bits_per_word >= 4) && (spi->bits_per_word <= 16)) {
+		chip->ctar.fmsz = spi->bits_per_word - 1;
+	} else {
+		printk(KERN_ERR "Invalid wordsize\n");
+		kfree(chip);
+		return -ENODEV;
+	}
+
+	chip->void_write_data = 0;
+	chip->ctar.cpha = (spi->mode & SPI_CPHA) ? 1 : 0;
+	chip->ctar.cpol = (spi->mode & SPI_CPOL) ? 1 : 0;
+	chip->ctar.lsbfe = (spi->mode & SPI_LSB_FIRST) ? 1 : 0;
+	of_property_read_u32(np, "dspi,ctar-dbr", &dbr);
+	of_property_read_u32(np, "dspi,ctar-pbr", &pbr);
+	chip->ctar.dbr = dbr;
+	chip->ctar.pbr = pbr;
+	if (spi->max_speed_hz == 0)
+		return -ENODEV;
+	br = hz_to_spi_baud(chip->ctar.pbr, chip->ctar.dbr,
+			spi->max_speed_hz, clk_get_rate(dspi->clk));
+	chip->ctar.br = br;
+	chip->ctar.pcssck = 0;
+	chip->ctar.pasc = 0;
+	chip->ctar.pdt = 0;
+	chip->ctar.cssck = 0;
+	chip->ctar.asc = 0;
+	chip->ctar.dt = 0;
+
+	spi_set_ctldata(spi, chip);
+
+	return 0;
+}
+
+static void dspi_cleanup(struct spi_device *spi)
+{
+	struct chip_data *chip = spi_get_ctldata((struct spi_device *)spi);
+
+	dev_dbg(&spi->dev, "spi_device %u.%u cleanup\n",
+			spi->master->bus_num, spi->chip_select);
+
+	kfree(chip);
+}
+
+static irqreturn_t dspi_interrupt(int irq, void *dev_id)
+{
+	struct fsl_dspi *dspi = (struct fsl_dspi *)dev_id;
+	struct spi_message *msg = dspi->cur_msg;
+
+	writel(SPI_SR_EOQF, dspi->base + SPI_SR);
+
+	if (!dspi->cur_msg) {
+		u32 irq_status = readl(dspi->base + SPI_SR);
+		printk(KERN_ERR "Bad message or transfer state handler. "
+				"IRQ status = %x\n", irq_status);
+		return IRQ_HANDLED;
+	}
+
+	dspi_transfer_read(dspi);
+
+	if (!dspi->len) {
+		/*
+		 * Finished now - fall through and schedule next
+		 * transfer tasklet
+		 */
+		if (dspi->dataflags & TRAN_STATE_WORD_ODD_NUM)
+			set_16bit_transfer_mode(dspi);
+		dspi->waitflags = 1;
+		wake_up_interruptible(&dspi->waitq);
+
+	} else {
+		/* not finished yet - keep going */
+		msg->actual_length += dspi_transfer_write(dspi);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static struct of_device_id fsl_dspi_dt_ids[] = {
+	{ .compatible = "fsl,vf610-dspi", .data = NULL, },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, fsl_dspi_dt_ids);
+
+#ifdef CONFIG_PM_SLEEP
+static int dspi_suspend(struct device *dev)
+{
+	struct spi_master *master = dev_get_drvdata(dev);
+	struct fsl_dspi *dspi = spi_master_get_devdata(master);
+
+	spi_master_suspend(master);
+	clk_disable_unprepare(dspi->clk);
+
+	return 0;
+}
+
+static int dspi_resume(struct device *dev)
+{
+
+	struct spi_master *master = dev_get_drvdata(dev);
+	struct fsl_dspi *dspi = spi_master_get_devdata(master);
+
+	clk_prepare_enable(dspi->clk);
+	spi_master_resume(master);
+
+	return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops dspi_pm = {
+	SET_SYSTEM_SLEEP_PM_OPS(dspi_suspend, dspi_resume)
+};
+
+static int dspi_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct spi_master *master;
+	struct fsl_dspi *dspi;
+	struct resource *res;
+	int ret = 0, cs_num, bus_num;
+
+	master = spi_alloc_master(&pdev->dev, sizeof(struct fsl_dspi));
+	if (!master)
+		return -ENOMEM;
+
+	dspi = spi_master_get_devdata(master);
+	dspi->master = master;
+
+	master->cleanup = dspi_cleanup;
+	master->setup = dspi_setup;
+	master->transfer = NULL;
+	master->transfer_one_message = dspi_transfer_one_message;
+	master->prepare_transfer_hardware = dspi_prepare_transfer_hw;
+	master->unprepare_transfer_hardware = dspi_unprepare_transfer_hw;
+	master->mode_bits = SPI_CPOL | SPI_CPHA;
+	master->bits_per_word_mask = SPI_BPW_MASK(4) | SPI_BPW_MASK(8) |
+					SPI_BPW_MASK(16);
+	master->dev.of_node = pdev->dev.of_node;
+
+	ret = of_property_read_u32(np, "spi-num-chipselects", &cs_num);
+	if (ret < 0)
+		goto fail;
+	master->num_chipselect = cs_num;
+
+	ret = of_property_read_u32(np, "bus-num", &bus_num);
+	if (ret < 0)
+		goto fail;
+	master->bus_num = bus_num;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(&pdev->dev, "can't get platform resource\n");
+		ret = -ENOMEM;
+		goto fail;
+	}
+
+	dspi->base = devm_ioremap_resource(&pdev->dev, res);
+	if (!dspi->base) {
+		ret = EINVAL;
+		goto fail;
+	}
+
+	dspi->irq = platform_get_irq(pdev, 0);
+	if (dspi->irq < 0) {
+		dev_err(&pdev->dev, "can't get platform irq\n");
+		ret = -ENOMEM;
+		goto fail;
+	}
+
+	ret = devm_request_irq(&pdev->dev, dspi->irq, dspi_interrupt, 0,
+			pdev->name, dspi);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Unable to attach DSPI interrupt\n");
+		goto fail;
+	}
+
+	dspi->clk = devm_clk_get(&pdev->dev, "dspi");
+	if (IS_ERR(dspi->clk)) {
+		dev_err(&pdev->dev, "unable to get clock\n");
+		goto fail;
+	}
+	clk_prepare_enable(dspi->clk);
+
+	init_waitqueue_head(&dspi->waitq);
+
+	/* Register with the SPI framework */
+	platform_set_drvdata(pdev, dspi);
+	ret = spi_register_master(master);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Problem registering DSPI master\n");
+		ret = -EINVAL;
+		goto fail;
+	}
+
+	printk(KERN_INFO "Freescale DSPI master initialized\n");
+	return ret;
+
+fail:
+	spi_master_put(master);
+	return ret;
+}
+
+static int dspi_remove(struct platform_device *pdev)
+{
+	struct fsl_dspi *dspi = platform_get_drvdata(pdev);
+
+	if (!dspi)
+		return 0;
+
+	clk_disable_unprepare(dspi->clk);
+	clk_put(dspi->clk);
+
+	/* Disconnect from the SPI framework */
+	spi_unregister_master(dspi->master);
+	spi_master_put(dspi->master);
+
+	/* Prevent double remove */
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static struct platform_driver fsl_dspi_driver = {
+	.driver.name    = DRIVER_NAME,
+	.driver.of_match_table = fsl_dspi_dt_ids,
+	.driver.owner   = THIS_MODULE,
+	.driver.pm = &dspi_pm,
+	.probe          = dspi_probe,
+	.remove		= dspi_remove,
+};
+module_platform_driver(fsl_dspi_driver);
+
+MODULE_DESCRIPTION("Freescale DSPI Controller Driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:" DRIVER_NAME);
-- 
1.8.0




From tobetter at gmail.com  Wed Jul 24 02:29:03 2013
From: tobetter at gmail.com (Dongjin Kim)
Date: Wed, 24 Jul 2013 15:29:03 +0900
Subject: [PATCH] ARM: dts: Add USB host node for Exynos4
In-Reply-To: <CAK9yfHz10ao32Y4VRsvjNLe+zaq+hYk4KVgtwFgSLDsN-9Pfpw@mail.gmail.com>
References: <1374600763-19466-1-git-send-email-tobetter@gmail.com>
 <CAK9yfHz10ao32Y4VRsvjNLe+zaq+hYk4KVgtwFgSLDsN-9Pfpw@mail.gmail.com>
Message-ID: <CADoNuNdqF0Y=3pdBCE26AQgkv6uqZQ4uE+BfPSSNxAvuuR+kvg@mail.gmail.com>

+Jingoo Han

Sorry, its my bad. Typo problem.

I found another patch same with mine,
https://patchwork.kernel.org/patch/2628451, submitted by Jingoo Han
and tested on Exynos4210. Mine is tested on Exynos4412. Both SoC have
same USB host address space, so I think USB host device nodes can be
placed in exynos4.dtsi.

Regards,
Dongjin.

On Wed, Jul 24, 2013 at 12:38 PM, Sachin Kamat <sachin.kamat at linaro.org> wrote:
> On 23 July 2013 23:02, Dongjin Kim <tobetter at gmail.com> wrote:
>> This patch adds EHCI and OHCI host device nodes for Exynos4.
>>
>> Signed-off-by: Dongjin Kim <tobetter at gmail.com>
>> ---
>>  arch/arm/boot/dts/exynos4.dtsi |   20 ++++++++++++++++++++
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
>> index 3f94fe8..1cdbf89 100644
>> --- a/arch/arm/boot/dts/exynos4.dtsi
>> +++ b/arch/arm/boot/dts/exynos4.dtsi
>> @@ -155,6 +155,26 @@
>>                 status = "disabled";
>>         };
>>
>> +       ehci at 12580000 {
>> +               compatible = "samsung,exynos4210-ehci";
>> +               reg = <0x12580000 0x100>;
>> +               interrupts = <0 70 0>;
>> +               status = "disabled";
>> +
>> +               clocks = <&clock 304>;
>> +               clock-names = "usbhost";
>> +       };
>> +
>> +       ohci at 12590000 {
>> +               compatible = "samsung,exynos4210-ohci";
>> +               reg = <0x12580000 0x100>;
>
> Register value and node name do not match. Typo?
>
>
>> +               interrupts = <0 70 0>;
>> +               status = "disabled";
>> +
>> +               clocks = <&clock 304>;
>> +               clock-names = "usbhost";
>> +       };
>> +
>>         mfc: codec at 13400000 {
>>                 compatible = "samsung,mfc-v5";
>>                 reg = <0x13400000 0x10000>;
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> With warm regards,
> Sachin


From jg1.han at samsung.com  Wed Jul 24 02:49:41 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Wed, 24 Jul 2013 15:49:41 +0900
Subject: [PATCH] ARM: dts: Add USB host node for Exynos4
In-Reply-To: <CADoNuNdqF0Y=3pdBCE26AQgkv6uqZQ4uE+BfPSSNxAvuuR+kvg@mail.gmail.com>
References: <1374600763-19466-1-git-send-email-tobetter@gmail.com>
 <CAK9yfHz10ao32Y4VRsvjNLe+zaq+hYk4KVgtwFgSLDsN-9Pfpw@mail.gmail.com>
 <CADoNuNdqF0Y=3pdBCE26AQgkv6uqZQ4uE+BfPSSNxAvuuR+kvg@mail.gmail.com>
Message-ID: <000001ce8839$f97faa90$ec7effb0$@samsung.com>

On Wednesday, July 24, 2013 3:29 PM, Dongjin Kim wrote:
> 
> +Jingoo Han
> 
> Sorry, its my bad. Typo problem.
> 
> I found another patch same with mine,
> https://patchwork.kernel.org/patch/2628451, submitted by Jingoo Han
> and tested on Exynos4210. Mine is tested on Exynos4412. Both SoC have
> same USB host address space, so I think USB host device nodes can be
> placed in exynos4.dtsi.

OK, USB host device nodes can be placed in exynos4.dtsi.

However, next time, please leave comment on earlier patch.
The patch for Exynos4210 USB was already submitted 2 months ago.


> 
> Regards,
> Dongjin.
> 
> On Wed, Jul 24, 2013 at 12:38 PM, Sachin Kamat <sachin.kamat at linaro.org> wrote:
> > On 23 July 2013 23:02, Dongjin Kim <tobetter at gmail.com> wrote:
> >> This patch adds EHCI and OHCI host device nodes for Exynos4.
> >>
> >> Signed-off-by: Dongjin Kim <tobetter at gmail.com>
> >> ---
> >>  arch/arm/boot/dts/exynos4.dtsi |   20 ++++++++++++++++++++
> >>  1 file changed, 20 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> >> index 3f94fe8..1cdbf89 100644
> >> --- a/arch/arm/boot/dts/exynos4.dtsi
> >> +++ b/arch/arm/boot/dts/exynos4.dtsi
> >> @@ -155,6 +155,26 @@
> >>                 status = "disabled";
> >>         };
> >>
> >> +       ehci at 12580000 {
> >> +               compatible = "samsung,exynos4210-ehci";
> >> +               reg = <0x12580000 0x100>;
> >> +               interrupts = <0 70 0>;
> >> +               status = "disabled";
> >> +
> >> +               clocks = <&clock 304>;
> >> +               clock-names = "usbhost";
> >> +       };
> >> +
> >> +       ohci at 12590000 {
> >> +               compatible = "samsung,exynos4210-ohci";
> >> +               reg = <0x12580000 0x100>;
> >
> > Register value and node name do not match. Typo?
> >
> >
> >> +               interrupts = <0 70 0>;
> >> +               status = "disabled";
> >> +
> >> +               clocks = <&clock 304>;
> >> +               clock-names = "usbhost";
> >> +       };
> >> +
> >>         mfc: codec at 13400000 {
> >>                 compatible = "samsung,mfc-v5";
> >>                 reg = <0x13400000 0x10000>;
> >> --
> >> 1.7.9.5



From josephl at nvidia.com  Wed Jul 24 02:56:38 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 24 Jul 2013 14:56:38 +0800
Subject: [PATCH] ARM: dts: tegra114: dalmore: fix the irq trigger type
 of Palmas MFD device
In-Reply-To: <51EE968B.1050103@nvidia.com>
References: <1374574191-24396-1-git-send-email-josephl@nvidia.com>
 <51EE968B.1050103@nvidia.com>
Message-ID: <1374648998.23756.13.camel@jlo-ubuntu-64.nvidia.com>

On Tue, 2013-07-23 at 22:43 +0800, Laxman Dewangan wrote:
> On Tuesday 23 July 2013 03:39 PM, Joseph Lo wrote:
> > The IRQ trigger type of Palmas MFD device (tps65913) is low-level
> > sensitive. The wrong configuration would cause an interrupt storm
> > when booting the system. Fixing it in DT with appropriate interrupt
> > type.
> >
> > Cc: Laxman Dewangan <ldewangan at nvidia.com>
> > Signed-off-by: Joseph Lo <josephl at nvidia.com>
> > ---
> >   arch/arm/boot/dts/tegra114-dalmore.dts | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
> > index 76529e4..70b9d0c 100644
> > --- a/arch/arm/boot/dts/tegra114-dalmore.dts
> > +++ b/arch/arm/boot/dts/tegra114-dalmore.dts
> > @@ -840,7 +840,7 @@
> >   		palmas: tps65913 {
> >   			compatible = "ti,palmas";
> >   			reg = <0x58>;
> > -			interrupts = <0 86 0x4>;
> > +			interrupts = <0 86 0x8>;
> >   
> 
> This fails as GIC does not support the interrupt flag of 8.
> 
Yes, I knew this. But everything works as expected, the IRQ storm
disappears and the IRQ of Palmas RTC is working and can be used as a
wake up signal.

> [   13.007755] genirq: Setting trigger mode 8 for irq 118 failed 
> (gic_set_type+0x0/0xf0)
> [   13.009152] palmas 1-0058: Irq flag is 0x00000000
> 
> I did not get the interrupt storm and even interrupt is not working on tot.
> Two ways to resolve this:
> - Change the interrupt flag to 0 from 4. Or
Actually I fixed this issue two months ago, I had tried to use 0x0 as
the IRQ flag before. It's not working. But I still tried it today, it's
OK now(!!!). The function is what I expect. Maybe something wrong in my
test two months ago. Will fix this in V2.

> - Remove the nvidia,invert-interrupt; for PMC node.
This can avoid IRQ storm but introduce a new issue. The system suspend
would be woken up automatically by Palmas RTC all the time.

Thanks,
Joseph




From lars at metafoo.de  Wed Jul 24 02:58:27 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Wed, 24 Jul 2013 08:58:27 +0200
Subject: [PATCH 7/9] ASoC: tegra: move to generic DMA DT binding
In-Reply-To: <1374639002-16753-8-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-8-git-send-email-rizhao@nvidia.com>
Message-ID: <51EF7B13.4050207@metafoo.de>

On 07/24/2013 06:10 AM, Richard Zhao wrote:
> - add tegra_dma_filter_data to specify dma info
>    DMA DT binding needs the device that raise dma request and dma name
>    to request a dma channel. tegra30_i2s is a special case. It should be ahub
>    device and it also has dma name that cannot handled by ASoC dmaengine code.
>    So we pass the info using filter data in snd_dmaengine_dai_dma_data.

How about extending the generic dmaengine PCM driver so that it is possible to 
specify the the DMA channel names? I think that will make the code a bit 
simpler and also allow you to remove tegra_pcm.c completely eventually.

- Lars


From maxime.ripard at free-electrons.com  Wed Jul 24 03:06:28 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 09:06:28 +0200
Subject: [PATCH] ARM: sunxi: make the leds' names conform to the current
 naming convention
In-Reply-To: <1374542341-3429-1-git-send-email-emilio@elopez.com.ar>
References: <1374542341-3429-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <20130724070628.GH10389@lukather>

On Mon, Jul 22, 2013 at 10:19:01PM -0300, Emilio L?pez wrote:
> Quoting from Documentation/leds/leds-class.txt:
> 
>     LED Device Naming
>     =================
> 
>     Is currently of the form:
> 
>     "devicename:colour:function"
> 
> Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>

Applied to my sunxi/dt-for-3.12 branch.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130724/665711c3/attachment.sig>

From maxime.ripard at free-electrons.com  Wed Jul 24 03:12:52 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 09:12:52 +0200
Subject: [PATCH] ARM: sunxi: Remove Makefile.boot file
Message-ID: <1374649972-26088-1-git-send-email-maxime.ripard@free-electrons.com>

Since we've been a multi-platform enabled kernel from the beginning,
Makefile.boot has always been dead code.

Remove it.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/mach-sunxi/Makefile.boot | 1 -
 1 file changed, 1 deletion(-)
 delete mode 100644 arch/arm/mach-sunxi/Makefile.boot

diff --git a/arch/arm/mach-sunxi/Makefile.boot b/arch/arm/mach-sunxi/Makefile.boot
deleted file mode 100644
index 46d4cf0..0000000
--- a/arch/arm/mach-sunxi/Makefile.boot
+++ /dev/null
@@ -1 +0,0 @@
-zreladdr-$(CONFIG_ARCH_SUNXI)	+= 0x40008000
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Wed Jul 24 03:14:35 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Jul 2013 09:14:35 +0200
Subject: [PATCH] i2c: mv64xxx: Document the newly introduced allwinner
 compatible
Message-ID: <1374650075-26190-1-git-send-email-maxime.ripard@free-electrons.com>

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
index a1ee681..6113f92 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
@@ -4,7 +4,7 @@
 Required properties :
 
  - reg             : Offset and length of the register set for the device
- - compatible      : Should be "marvell,mv64xxx-i2c"
+ - compatible      : Should be "marvell,mv64xxx-i2c" or "allwinner,sun4i-i2c"
  - interrupts      : The interrupt number
 
 Optional properties :
-- 
1.8.3.2



From horms at verge.net.au  Wed Jul 24 03:23:58 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 16:23:58 +0900
Subject: [PATCH 01/19] ARM: shmobile: r8a73a4: Add pin control device to
 device tree
In-Reply-To: <Pine.LNX.4.64.1307240811080.30777@axis700.grange>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
 <803d319cb2fb41e646669061b45701f3ea78e611.1374625203.git.horms+renesas@verge.net.au>
 <Pine.LNX.4.64.1307240811080.30777@axis700.grange>
Message-ID: <20130724072358.GB17045@verge.net.au>

On Wed, Jul 24, 2013 at 08:11:33AM +0200, Guennadi Liakhovetski wrote:
> Hi Simon
> 
> On Wed, 24 Jul 2013, Simon Horman wrote:
> 
> > From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> > 
> > Add a pfc node to the r8a73a4 device tree.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> > [g.liakhovetski+renesas at gmail.com use 2 nodes for address and size]
> 
> it's actually "cells," not "nodes."

Thanks. I'd like to leave the comment as is unless there
is a more compelling reason to re-base the pull-request.

> Thanks
> Guennadi
> 
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> > ---
> >  arch/arm/boot/dts/r8a73a4.dtsi | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
> > index 4ff2019..b886afd 100644
> > --- a/arch/arm/boot/dts/r8a73a4.dtsi
> > +++ b/arch/arm/boot/dts/r8a73a4.dtsi
> > @@ -85,4 +85,11 @@
> >  		interrupt-parent = <&gic>;
> >  		interrupts = <0 69 4>;
> >  	};
> > +
> > +	pfc: pfc at e6050000 {
> > +		compatible = "renesas,pfc-r8a73a4";
> > +		reg = <0 0xe6050000 0 0x9000>;
> > +		gpio-controller;
> > +		#gpio-cells = <2>;
> > +	};
> >  };
> > -- 
> > 1.8.2.1
> > 
> 
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From magnus.damm at gmail.com  Wed Jul 24 03:27:39 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 24 Jul 2013 16:27:39 +0900
Subject: [PATCH] ARM: shmobile: sh73a0: Rely on DT for SMP CPU info
Message-ID: <20130724072739.28333.44251.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove sh73a0 specific ->smp_init_cpus() callback and
instead of relying on shmobile_smp_init_cpus() simply
use DT for CPU core information.

This assumes that DT_MACHINE_START is used which is
the case when AG5EVM and Kota2 are removed.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/smp-sh73a0.c |   11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

--- 0001/arch/arm/mach-shmobile/smp-sh73a0.c
+++ work/arch/arm/mach-shmobile/smp-sh73a0.c	2013-07-24 15:59:16.000000000 +0900
@@ -62,6 +62,8 @@ static int sh73a0_boot_secondary(unsigne
 
 static void __init sh73a0_smp_prepare_cpus(unsigned int max_cpus)
 {
+	/* setup sh73a0 specific SCU base */
+	shmobile_scu_base = IOMEM(SH73A0_SCU_BASE);
 	scu_enable(shmobile_scu_base);
 
 	/* Map the reset vector (in headsmp-scu.S, headsmp.S) */
@@ -74,14 +76,6 @@ static void __init sh73a0_smp_prepare_cp
 	scu_power_mode(shmobile_scu_base, SCU_PM_NORMAL);
 }
 
-static void __init sh73a0_smp_init_cpus(void)
-{
-	/* setup sh73a0 specific SCU base */
-	shmobile_scu_base = IOMEM(SH73A0_SCU_BASE);
-
-	shmobile_smp_init_cpus(scu_get_core_count(shmobile_scu_base));
-}
-
 #ifdef CONFIG_HOTPLUG_CPU
 static int sh73a0_cpu_kill(unsigned int cpu)
 {
@@ -120,7 +114,6 @@ static int sh73a0_cpu_disable(unsigned i
 #endif /* CONFIG_HOTPLUG_CPU */
 
 struct smp_operations sh73a0_smp_ops __initdata = {
-	.smp_init_cpus		= sh73a0_smp_init_cpus,
 	.smp_prepare_cpus	= sh73a0_smp_prepare_cpus,
 	.smp_boot_secondary	= sh73a0_boot_secondary,
 #ifdef CONFIG_HOTPLUG_CPU


From magnus.damm at gmail.com  Wed Jul 24 03:30:42 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 24 Jul 2013 16:30:42 +0900
Subject: [PATCH] ARM: shmobile: marzen: Switch to DT_MACHINE_START
Message-ID: <20130724073042.28351.33041.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Convert the marzen board to use DT_MACHINE_START. With this in
place all mach-shmobile boards use DT_MACHINE_START. Also, this
makes it possible for the r8a7779 SMP code to use DT for CPUs.

So appended DTB is the way forward on this board.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Written on top of renesas-devel-20130724

 arch/arm/mach-shmobile/board-marzen.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/board-marzen.c
+++ work/arch/arm/mach-shmobile/board-marzen.c	2013-07-24 15:45:39.000000000 +0900
@@ -238,7 +238,7 @@ static void __init marzen_init(void)
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 
-MACHINE_START(MARZEN, "marzen")
+DT_MACHINE_START(MARZEN, "marzen")
 	.smp		= smp_ops(r8a7779_smp_ops),
 	.map_io		= r8a7779_map_io,
 	.init_early	= r8a7779_add_early_devices,


From victor.kamensky at linaro.org  Wed Jul 24 03:31:36 2013
From: victor.kamensky at linaro.org (Victor Kamensky)
Date: Wed, 24 Jul 2013 00:31:36 -0700
Subject: updates for be8 patch series
In-Reply-To: <51EECBBD.20000@codethink.co.uk>
References: <CAA3XUr3h5C0oJVrN5iXsM=NFkLMz_Tssp28CysZfwMNS5KvO-Q@mail.gmail.com>
 <51EEC002.9070808@codethink.co.uk>
 <CAA3XUr2oDEDD6LFjnZ_N0JGTFUMDZG6O9b3JoeJ8AELrK2KDiw@mail.gmail.com>
 <CAA3XUr1BJD-ypfJiEsp079qHDERjGp-xFxc_ke_Ep9z3N=UPaA@mail.gmail.com>
 <51EECBBD.20000@codethink.co.uk>
Message-ID: <CAA3XUr1zHQbh+baVzQfgEebqYsEzUVp6wGOMe2PE6PUamAnbbw@mail.gmail.com>

Hi Ben,

Please see inline

On 23 July 2013 11:30, Ben Dooks <ben.dooks at codethink.co.uk> wrote:
> On 23/07/13 19:03, Victor Kamensky wrote:
>>
>> Hi Ben,
>>
>> Sorry for multiple post. I am new to this, and I could not get mailing
>> list to accept my original email.
>> For sake of others so people can see discussed patch, here it goes
>> again with patch file inlined
>> now. Hope it will this time
>>
>> Wrt BE8 little endian instructions you will need to fix couple more
>> places:
>>      ftrace arch/arm/kernel/ftrace.c
>>      kprobes arch/arm/kernel/kprobes.c
>> Also in big endian mode atomic64_xxx function will need fixes, otherwise
>> perf
>> counters will be truncated on max of 32bit values
>>      atomic64 arch/arm/include/asm/atomic.h
>>
>> I've attached board independent (core) patch from my work that made
>> Pandaboard ES
>> kernel run in BE mode. You can check my version of fixes for above issues
>> in the
>> patch. Look for corresponding files changes. Please rework them
>> according to style
>> and rules of your patch series. Note the patch itself contains fixes
>> for few other
>> issues that already fixed in your series. I'll cross check and compare
>> individual
>> areas latter. I think you may find attached patch interesting as well,
>> it was developed
>> independent from yours but matches its very well.
>>
>> Wrt of testing: ftrace was tested on Pandaboard ES, krprobes changes were
>> tested
>> with SystemTap at some point of patch version on Pandaboard ES (not
>> thumb mode though),
>> also it may deteriorated while ported across different kernel version,
>> good idea to
>> rested last patch. atomic64 were tested on Pandaboard ES and Marvell
>> Armada XP.
>>
>> Thanks,
>> Victor
>
>
> First notes, please always format your emails (where possible) to
> under 80 characters per line so that they do not get mangled when
> viewed on limited screens (for example, I often read email via a
> 24x80 terminal)

Yes, I understand. Sorry about this. Please bear with me a bit. I am new to
Linaro .. just my second week started. Still learning tools used here, and
still struggling with default email client.

> Second note, when producing patches, it is better to try and split
> them into a series of patches to reach a goal than just one large
> patch. It keeps a lot of useful information (see patch comments)
> and it means that if there is a problem, then bits can be lifted
> out to check.

Yes, I understand. Indeed multiple patches is best from. But I did not really
mean try to contribute these patches, but rather throw patch over the wall for
reference.

I believe largely your series covers the same things, in more accurate way,
and should be continued. I plan to review your series and will try to
integrate it and run on Pandaboard ES. Note for this testing I would use big
patch of TI OMAP4 drivers to be endian neutral. It will take me several days.
If I find anything I will let you know accross these days.

Note my original experiment was done against TI 3.1 kernel and after that
was carried forward without great care, so it may explain few descrepencies
below and my blunder with ftrace comment.

>
>
>> Index: linux-linaro-tracking/arch/arm/Makefile
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/Makefile
>> +++ linux-linaro-tracking/arch/arm/Makefile
>> @@ -16,6 +16,7 @@ LDFLAGS        :=
>>   LDFLAGS_vmlinux    :=-p --no-undefined -X
>>   ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
>>   LDFLAGS_vmlinux    += --be8
>> +KBUILD_LDFLAGS_MODULE += --be8
>>   endif
>>
>>   OBJCOPYFLAGS    :=-O binary -R .comment -S
>> @@ -43,12 +44,19 @@ ifeq ($(CONFIG_CC_STACKPROTECTOR),y)
>>   KBUILD_CFLAGS    +=-fstack-protector
>>   endif
>>
>> +# Passing endian compilation flag in both CPPFLAGS ad CFLAGS. There are
>> +# places where CFLAGS alone are used (cmd_record_mcount). And it has to
>> +# be in CPPFLAGS because it affects what macros (__ARMEB__,
>> __BYTE_ORDER__,
>> +# __FLOAT_WORD_ORDER__) are defined. So replication of flag seems to be
>> +# good compromise
>>   ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
>>   KBUILD_CPPFLAGS    += -mbig-endian
>> +KBUILD_CFLAGS    += -mbig-endian
>>   AS        += -EB
>>   LD        += -EB
>>   else
>>   KBUILD_CPPFLAGS    += -mlittle-endian
>> +KBUILD_CFLAGS    += -mlittle-endian
>>   AS        += -EL
>>   LD        += -EL
>>   endif
>
>
> See the comment below.
>
>
>> Index: linux-linaro-tracking/arch/arm/boot/compressed/Makefile
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/boot/compressed/Makefile
>> +++ linux-linaro-tracking/arch/arm/boot/compressed/Makefile
>> @@ -138,6 +138,24 @@ endif
>>   ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
>>   LDFLAGS_vmlinux += --be8
>>   endif
>> +
>> +# Passing endian compilation flag in both CPPFLAGS ad CFLAGS. There are
>> +# places where CFLAGS alone are used (cmd_record_mcount). And it has to
>> +# be in CPPFLAGS because it affects what macros (__ARMEB__,
>> __BYTE_ORDER__,
>> +# __FLOAT_WORD_ORDER__) are defined. So replication of flag seems to be
>> +# good compromise
>> +ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
>> +KBUILD_CPPFLAGS    += -mbig-endian
>> +KBUILD_CFLAGS    += -mbig-endian
>> +AS        += -EB
>> +LD        += -EB
>> +else
>> +KBUILD_CPPFLAGS    += -mlittle-endian
>> +KBUILD_CFLAGS    += -mlittle-endian
>> +AS        += -EL
>> +LD        += -EL
>> +endif
>> +
>>   # ?
>>   LDFLAGS_vmlinux += -p
>>   # Report unresolved symbol references
>
>
> I've not been bitten by this one. Is there anyone else who can comment
> on KBUILD_CFLAGS vs KBUILD_CPPFLAGS?
>
> I had assumed that arch/arm/boot/compressed/Makefile would have
> inherited the flags from the arch/arm/Makefile. Someone else would
> be better qualified to comment on this.

Let's ignore this. I don't think it is relevant now. There was probably some
odd situation in old kernel.

>
>> Index: linux-linaro-tracking/arch/arm/boot/compressed/head.S
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/boot/compressed/head.S
>> +++ linux-linaro-tracking/arch/arm/boot/compressed/head.S
>> @@ -141,6 +141,12 @@ start:
>>   #endif
>>           mov    r7, r1            @ save architecture ID
>>           mov    r8, r2            @ save atags pointer
>> +#ifdef CONFIG_LITTLE_ENDIAN_LOADER
>> +                /*
>> +                 * Switch to bigendian mode
>> +                 */
>> +                setend  be
>> +#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
>>
>>   #ifndef __ARM_ARCH_2__
>>           /*
>> Index: linux-linaro-tracking/arch/arm/include/asm/setup.h
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/include/asm/setup.h
>> +++ linux-linaro-tracking/arch/arm/include/asm/setup.h
>> @@ -53,4 +53,8 @@ extern int arm_add_memory(phys_addr_t st
>>   extern void early_print(const char *str, ...);
>>   extern void dump_machine_table(void);
>>
>> +#ifdef CONFIG_LITTLE_ENDIAN_LOADER
>> +void byteswap_tags(struct tag *t);
>> +#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
>> +
>>   #endif
>
>
> You could have done
>
> #ifdef CONFIG_LITTLE_ENDIAN_LOADER
> void byteswap_tags(struct tag *t);
> #else
> static inline void byteswap_tags(struct tag *t) { }
> #endif /* CONFIG_LITTLE_ENDIAN_LOADER */
>
>
>
>> Index: linux-linaro-tracking/arch/arm/kernel/Makefile
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/kernel/Makefile
>> +++ linux-linaro-tracking/arch/arm/kernel/Makefile
>> @@ -22,6 +22,7 @@ obj-y        := elf.o entry-armv.o entry-commo
>>   obj-$(CONFIG_ATAGS)        += atags_parse.o
>>   obj-$(CONFIG_ATAGS_PROC)    += atags_proc.o
>>   obj-$(CONFIG_DEPRECATED_PARAM_STRUCT) += atags_compat.o
>> +obj-$(CONFIG_LITTLE_ENDIAN_LOADER) += atags_byteswap.o
>>
>>   obj-$(CONFIG_OC_ETM)        += etm.o
>>   obj-$(CONFIG_CPU_IDLE)        += cpuidle.o
>> Index: linux-linaro-tracking/arch/arm/kernel/atags_byteswap.c
>> ===================================================================
>> --- /dev/null
>> +++ linux-linaro-tracking/arch/arm/kernel/atags_byteswap.c
>> @@ -0,0 +1,119 @@
>> +#include<linux/slab.h>
>> +#include<linux/proc_fs.h>
>> +#include<linux/swab.h>
>> +#include<asm/setup.h>
>> +#include<asm/types.h>
>> +#include<asm/page.h>
>> +
>> +#define byteswap32(x) (x) = __swab32((x))
>> +#define byteswap16(x) (x) = __swab16((x))
>> +
>> +static void __init byteswap_tag_core(struct tag *tag)
>> +{
>> +  byteswap32(tag->u.core.flags);
>> +  byteswap32(tag->u.core.pagesize);
>> +  byteswap32(tag->u.core.rootdev);
>> +}
>> +
>> +static void __init byteswap_tag_mem32(struct tag *tag)
>> +{
>> +  byteswap32(tag->u.mem.size);
>> +  byteswap32(tag->u.mem.start);
>> +}
>> +
>> +static void __init byteswap_tag_videotext(struct tag *tag)
>> +{
>> +  byteswap16(tag->u.videotext.video_page);
>> +  byteswap16(tag->u.videotext.video_ega_bx);
>> +  byteswap16(tag->u.videotext.video_points);
>> +}
>> +
>> +static void __init byteswap_tag_ramdisk(struct tag *tag)
>> +{
>> +  byteswap32(tag->u.ramdisk.flags);
>> +  byteswap32(tag->u.ramdisk.size);
>> +  byteswap32(tag->u.ramdisk.start);
>> +}
>> +
>> +static void __init byteswap_tag_initrd(struct tag *tag)
>> +{
>> +  byteswap32(tag->u.initrd.start);
>> +  byteswap32(tag->u.initrd.size);
>> +}
>> +
>> +static void __init byteswap_tag_serialnr(struct tag *tag)
>> +{
>> +  byteswap32(tag->u.serialnr.low);
>> +  byteswap32(tag->u.serialnr.high);
>> +}
>> +
>> +static void __init byteswap_tag_revision(struct tag *tag)
>> +{
>> +    byteswap32(tag->u.revision.rev);
>> +}
>> +
>> +static void __init byteswap_tag_videolfb(struct tag *tag)
>> +{
>> +    byteswap16(tag->u.videolfb.lfb_width);
>> +    byteswap16(tag->u.videolfb.lfb_height);
>> +    byteswap16(tag->u.videolfb.lfb_depth);
>> +    byteswap16(tag->u.videolfb.lfb_linelength);
>> +    byteswap32(tag->u.videolfb.lfb_base);
>> +    byteswap32(tag->u.videolfb.lfb_size);
>> +}
>> +
>> +static void __init byteswap_tag_acorn(struct tag *tag)
>> +{
>> +    byteswap32(tag->u.acorn.memc_control_reg);
>> +    byteswap32(tag->u.acorn.vram_pages);
>> +}
>> +
>> +static void __init byteswap_tag_memclk(struct tag *tag)
>> +{
>> +    byteswap32(tag->u.memclk.fmemclk);
>> +}
>> +
>> +void __init byteswap_tags(struct tag *t)
>> +{
>> +  for (; t->hdr.size; t = tag_next(t)) {
>> +    byteswap32(t->hdr.size);
>> +    byteswap32(t->hdr.tag);
>> +    switch(t->hdr.tag) {
>> +    case ATAG_CORE:
>> +      byteswap_tag_core(t);
>> +      break;
>> +    case ATAG_MEM:
>> +      byteswap_tag_mem32(t);
>> +      break;
>> +    case ATAG_VIDEOTEXT:
>> +      byteswap_tag_videotext(t);
>> +      break;
>> +    case ATAG_RAMDISK:
>> +      byteswap_tag_ramdisk(t);
>> +      break;
>> +    case ATAG_INITRD2:
>> +      byteswap_tag_initrd(t);
>> +      break;
>> +    case ATAG_SERIAL:
>> +      byteswap_tag_serialnr(t);
>> +      break;
>> +    case ATAG_REVISION:
>> +      byteswap_tag_revision(t);
>> +      break;
>> +    case ATAG_VIDEOLFB:
>> +      byteswap_tag_videolfb(t);
>> +      break;
>> +    case ATAG_CMDLINE:
>> +      break;
>> +    case ATAG_ACORN:
>> +      byteswap_tag_acorn(t);
>> +      break;
>> +    case ATAG_MEMCLK:
>> +      byteswap_tag_memclk(t);
>> +      break;
>> +    default:
>> +      /* Need to complain? */
>> +      break;
>> +    }
>> +  }
>> +}
>
>
> I think swapping on read is a better idea, as it leaves
> these in their original format.
>
> PS, looks like you either have a formatting issue with
> your email client or your code. Did this pass checkpatch?
>
>
>> Index: linux-linaro-tracking/arch/arm/kernel/head-common.S
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/kernel/head-common.S
>> +++ linux-linaro-tracking/arch/arm/kernel/head-common.S
>> @@ -48,6 +48,9 @@ __vet_atags:
>>       bne    1f
>>
>>       ldr    r5, [r2, #0]
>> +#ifdef CONFIG_LITTLE_ENDIAN_LOADER
>> +        rev     r5, r5
>> +#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
>>   #ifdef CONFIG_OF_FLATTREE
>>       ldr    r6, =OF_DT_MAGIC        @ is it a DTB?
>>       cmp    r5, r6
>> @@ -57,6 +60,9 @@ __vet_atags:
>>       cmpne    r5, #ATAG_CORE_SIZE_EMPTY
>>       bne    1f
>>       ldr    r5, [r2, #4]
>> +#ifdef CONFIG_LITTLE_ENDIAN_LOADER
>> +        rev     r5, r5
>> +#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
>>       ldr    r6, =ATAG_CORE
>>       cmp    r5, r6
>>       bne    1f
>
>
> bit-untidy. also, does OF_DT_MAGIC get changed by the
> endian-ness, or is that somewhere else in the head code?
>
>> Index: linux-linaro-tracking/arch/arm/kernel/module.c
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/kernel/module.c
>> +++ linux-linaro-tracking/arch/arm/kernel/module.c
>> @@ -45,6 +45,65 @@ void *module_alloc(unsigned long size)
>>   }
>>   #endif
>>
>> +/*
>> + * For relocations in exectuable sections if we configured with
>> + * CONFIG_CPU_ENDIAN_BE8 we assume that code is in little endian byteswap
>> + * form already and we need to byteswap value when we read and when we
>> + * write. If relocaton R_ARM_ABS32 type we assume that it is relocation
>> for
>> + * data piece and we do not perform byteswaps when such relocation
>> applied.
>> + * This herustic based approach may break in future.
>> + *
>> + * It seems that more correct way to handle be8 in kernel module is
>> + * to build module without --be8 option, but perform instruction byteswap
>> + * when module sections are loaded, after all relocation are applied.
>> + * In order to do such byteswap we need to read all mappings symbols ($a,
>> + * $d, $t), sort them, and apply byteswaps for $a and $t entries.
>> + */
>> +static inline u32 read_section_u32(Elf32_Shdr *dstsec, unsigned long loc)
>> +{
>> +       u32 retval = *(u32 *)loc;
>> +
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +        if (dstsec->sh_flags&  SHF_EXECINSTR) {
>>
>> +                retval = __swab32(retval);
>> +        }
>> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
>> +        return retval;
>> +}
>> +
>> +static inline void write_section_u32(Elf32_Shdr *dstsec, unsigned
>> long loc, u32 value)
>> +{
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +        if (dstsec->sh_flags&  SHF_EXECINSTR) {
>>
>> +                value = __swab32(value);
>> +        }
>> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
>> +        *(u32 *) loc = value;
>> +}
>> +
>> +#ifdef CONFIG_THUMB2_KERNEL
>> +static inline u16 read_section_u16(Elf32_Shdr *dstsec, unsigned long loc)
>> +{
>> +        u16 retval = *(u16 *) loc;
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +        if (dstsec->sh_flags&  SHF_EXECINSTR) {
>>
>> +                retval = __swab16(retval);
>> +        }
>> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
>> +        return retval;
>> +}
>> +
>> +static inline void write_section_u16(Elf32_Shdr *dstsec, unsigned
>> long loc, u16 value)
>> +{
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +        if (dstsec->sh_flags&  SHF_EXECINSTR) {
>>
>> +                value = __swab16(value);
>> +        }
>> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
>> +        *(u16 *) loc = value;
>> +}
>> +#endif /* CONFIG_THUMB2_KERNEL */
>> +
>>   int
>>   apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int
>> symindex,
>>              unsigned int relindex, struct module *module)
>> @@ -60,6 +119,7 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
>>           Elf32_Sym *sym;
>>           const char *symname;
>>           s32 offset;
>> +                u32 loc_u32;
>>   #ifdef CONFIG_THUMB2_KERNEL
>>           u32 upper, lower, sign, j1, j2;
>>   #endif
>> @@ -95,7 +155,8 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
>>           case R_ARM_PC24:
>>           case R_ARM_CALL:
>>           case R_ARM_JUMP24:
>> -            offset = (*(u32 *)loc&  0x00ffffff)<<  2;
>>
>> +                        loc_u32 = read_section_u32(dstsec, loc);
>> +            offset = (loc_u32&  0x00ffffff)<<  2;
>>               if (offset&  0x02000000)
>>
>>                   offset -= 0x04000000;
>>
>> @@ -112,27 +173,33 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
>>
>>               offset>>= 2;
>>
>> -            *(u32 *)loc&= 0xff000000;
>>
>> -            *(u32 *)loc |= offset&  0x00ffffff;
>> +            loc_u32&= 0xff000000;
>> +            loc_u32 |= offset&  0x00ffffff;
>>
>> +                        write_section_u32(dstsec, loc, loc_u32);
>>               break;
>>
>> -           case R_ARM_V4BX:
>> +                case R_ARM_V4BX:
>> +                        loc_u32 = read_section_u32(dstsec, loc);
>>                  /* Preserve Rm and the condition code. Alter
>>               * other bits to re-code instruction as
>>               * MOV PC,Rm.
>>               */
>> -               *(u32 *)loc&= 0xf000000f;
>>
>> -               *(u32 *)loc |= 0x01a0f000;
>> +               loc_u32&= 0xf000000f;
>>
>> +               loc_u32 |= 0x01a0f000;
>> +                       write_section_u32(dstsec, loc, loc_u32);
>>                  break;
>>
>>           case R_ARM_PREL31:
>> -            offset = *(u32 *)loc + sym->st_value - loc;
>> -            *(u32 *)loc = offset&  0x7fffffff;
>>
>> +                        loc_u32 = read_section_u32(dstsec, loc);
>> +            offset = loc_u32 + sym->st_value - loc;
>> +            loc_u32 = offset&  0x7fffffff;
>>
>> +                        write_section_u32(dstsec, loc, loc_u32);
>>               break;
>>
>>           case R_ARM_MOVW_ABS_NC:
>>           case R_ARM_MOVT_ABS:
>> -            offset = *(u32 *)loc;
>> +                        loc_u32 = read_section_u32(dstsec, loc);
>> +            offset = loc_u32;
>>               offset = ((offset&  0xf0000)>>  4) | (offset&  0xfff);
>>
>>               offset = (offset ^ 0x8000) - 0x8000;
>>
>> @@ -140,16 +207,17 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
>>               if (ELF32_R_TYPE(rel->r_info) == R_ARM_MOVT_ABS)
>>                   offset>>= 16;
>>
>> -            *(u32 *)loc&= 0xfff0f000;
>>
>> -            *(u32 *)loc |= ((offset&  0xf000)<<  4) |
>> -                    (offset&  0x0fff);
>> +            loc_u32&= 0xfff0f000;
>> +            loc_u32 |= ((offset&  0xf000)<<  4) |
>> +                                   (offset&  0x0fff);
>>
>> +                        write_section_u32(dstsec, loc, loc_u32);
>>               break;
>>
>>   #ifdef CONFIG_THUMB2_KERNEL
>>           case R_ARM_THM_CALL:
>>           case R_ARM_THM_JUMP24:
>> -            upper = *(u16 *)loc;
>> -            lower = *(u16 *)(loc + 2);
>> +                        upper = read_section_u16(dstsec, loc);
>> +            lower = read_section_u16(dstsec, loc + 2);
>>
>>               /*
>>                * 25 bit signed address range (Thumb-2 BL and B.W
>> @@ -198,17 +266,19 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
>>               sign = (offset>>  24)&  1;
>>               j1 = sign ^ (~(offset>>  23)&  1);
>>               j2 = sign ^ (~(offset>>  22)&  1);
>> -            *(u16 *)loc = (u16)((upper&  0xf800) | (sign<<  10) |
>> -                        ((offset>>  12)&  0x03ff));
>> -            *(u16 *)(loc + 2) = (u16)((lower&  0xd000) |
>>
>> -                          (j1<<  13) | (j2<<  11) |
>> -                          ((offset>>  1)&  0x07ff));
>> +                        write_section_u16(dstsec, loc,
>> +                                          (u16)((upper&  0xf800) |
>> (sign<<  10) |
>> +                                                ((offset>>  12)&
>> 0x03ff)));
>>
>> +                        write_section_u16(dstsec, loc + 2,
>> +                                          (u16)((lower&  0xd000) |
>>
>> +                                                (j1<<  13) | (j2<<  11) |
>> +                                                ((offset>>  1)&
>> 0x07ff)));
>>
>>               break;
>>
>>           case R_ARM_THM_MOVW_ABS_NC:
>>           case R_ARM_THM_MOVT_ABS:
>> -            upper = *(u16 *)loc;
>> -            lower = *(u16 *)(loc + 2);
>> +                        upper = read_section_u16(dstsec, loc);
>> +            lower = read_section_u16(dstsec, loc + 2);
>>
>>               /*
>>                * MOVT/MOVW instructions encoding in Thumb-2:
>> @@ -229,12 +299,14 @@ apply_relocate(Elf32_Shdr *sechdrs, cons
>>               if (ELF32_R_TYPE(rel->r_info) == R_ARM_THM_MOVT_ABS)
>>                   offset>>= 16;
>>
>> -            *(u16 *)loc = (u16)((upper&  0xfbf0) |
>> -                        ((offset&  0xf000)>>  12) |
>> -                        ((offset&  0x0800)>>  1));
>>
>> -            *(u16 *)(loc + 2) = (u16)((lower&  0x8f00) |
>> -                          ((offset&  0x0700)<<  4) |
>> -                          (offset&  0x00ff));
>>
>> +                        write_section_u16(dstsec, loc,
>> +                                          (u16)((upper&  0xfbf0) |
>> +                                                ((offset&  0xf000)>>  12)
>> |
>> +                                                ((offset&  0x0800)>>
>> 1)));
>>
>> +                        write_section_u16(dstsec, loc + 2,
>> +                                          (u16)((lower&  0x8f00) |
>> +                                                ((offset&  0x0700)<<  4)
>> |
>> +                                                (offset&  0x00ff)));
>>               break;
>>   #endif
>>
>
> I'm still not sure about this, I think the use of <asm/opcodes.h>
> is better here. Not sure if there's much point in checking the flags
> on the sections as I think the relocations pretty much define which
> endian they will be in.

Wrt asm/opcodes.h, yes, agree it should be used now.

I'll need to check why I used section attributes to guide byteswaps. I think it
was done for a reason. We tested it with bigger system on top with quite a bit
of different KMLs, I think I run into problem with some of them. Will need dig
back. As my comment says ideally it would be better to use $a, $d, $t, symbols;
that is what ld does with --be8 option, but it maybe too hard as
starting point.

>> Index: linux-linaro-tracking/arch/arm/mm/Kconfig
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/mm/Kconfig
>> +++ linux-linaro-tracking/arch/arm/mm/Kconfig
>> @@ -695,6 +695,15 @@ config CPU_ENDIAN_BE32
>>       help
>>         Support for the BE-32 (big-endian) mode on pre-ARMv6 processors.
>>
>> +config LITTLE_ENDIAN_LOADER
>> +        bool
>> +        depends on CPU_BIG_ENDIAN
>> +        default y
>> +        help
>> +          If Linux should operate in big-endian mode, but bootloader
>> (i.e u-boot)
>> +          is still in little endian mode and passes boot information in
>> little
>> +          endian form set this flag
>> +
>>   config CPU_HIGH_VECTOR
>>       depends on !MMU&&  CPU_CP15&&  !CPU_ARM740T
>>
>>       bool "Select the High exception vector"
>
>
>
>> Index: linux-linaro-tracking/arch/arm/mm/alignment.c
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/mm/alignment.c
>> +++ linux-linaro-tracking/arch/arm/mm/alignment.c
>> @@ -792,6 +792,10 @@ do_alignment(unsigned long addr, unsigne
>>
>>       regs->ARM_pc += isize;
>>
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +        instr = __swab32(instr); /* little endian instruction */
>> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
>> +
>>       switch (CODING_BITS(instr)) {
>>       case 0x00000000:    /* 3.13.4 load/store instruction extensions */
>>           if (LDSTHD_I_BIT(instr))
>
>
> See comments on <asm/opcodes.h>
>
>
>> Index: linux-linaro-tracking/arch/arm/kernel/head.S
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/kernel/head.S
>> +++ linux-linaro-tracking/arch/arm/kernel/head.S
>> @@ -89,6 +89,12 @@ ENTRY(stext)
>>       @ ensure svc mode and all interrupts masked
>>       safe_svcmode_maskall r9
>>
>> +#ifdef CONFIG_LITTLE_ENDIAN_LOADER
>> +    /*
>> +    * Switch to bigendian mode
>> +    */
>> +    setend    be
>> +#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
>>       mrc    p15, 0, r9, c0, c0        @ get processor id
>>       bl    __lookup_processor_type        @ r5=procinfo r9=cpuid
>>       movs    r10, r5                @ invalid processor (r5=0)?
>> @@ -356,6 +362,12 @@ ENTRY(secondary_startup)
>>   #endif
>>       safe_svcmode_maskall r9
>>
>> +#ifdef CONFIG_LITTLE_ENDIAN_LOADER
>> +    /*
>> +    * Switch to bigendian mode
>> +    */
>> +    setend    be
>> +#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
>>       mrc    p15, 0, r9, c0, c0        @ get processor id
>>       bl    __lookup_processor_type
>>       movs    r10, r5                @ invalid processor?
>> @@ -427,6 +439,9 @@ __enable_mmu:
>>   #ifdef CONFIG_CPU_ICACHE_DISABLE
>>       bic    r0, r0, #CR_I
>>   #endif
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +    orr    r0, r0, #CR_EE    @ big-endian page tables
>> +#endif
>>   #ifdef CONFIG_ARM_LPAE
>>       mov    r5, #0
>>       mcrr    p15, 0, r4, r5, c2        @ load TTBR0
>> @@ -592,8 +607,14 @@ __fixup_a_pv_table:
>>       b    2f
>>   1:    add     r7, r3
>>       ldrh    ip, [r7, #2]
>> +#ifdef __ARMEB__
>> +        rev     ip, ip   @ byteswap instruction
>> +#endif /* __ARMEB__ */
>>       and    ip, 0x8f00
>>       orr    ip, r6    @ mask in offset bits 31-24
>> +#ifdef __ARMEB__
>> +        rev     ip, ip   @ byteswap instruction
>> +#endif /* __ARMEB__ */
>>       strh    ip, [r7, #2]
>>   2:    cmp    r4, r5
>>       ldrcc    r7, [r4], #4    @ use branch for delay slot
>> @@ -602,8 +623,14 @@ __fixup_a_pv_table:
>>   #else
>>       b    2f
>>   1:    ldr    ip, [r7, r3]
>> +#ifdef __ARMEB__
>> +        rev     ip, ip   @ byteswap instruction
>> +#endif /* __ARMEB__ */
>>       bic    ip, ip, #0x000000ff
>>       orr    ip, ip, r6    @ mask in offset bits 31-24
>> +#ifdef __ARMEB__
>> +        rev     ip, ip   @ byteswap instruction
>> +#endif /* __ARMEB__ */
>>       str    ip, [r7, r3]
>>   2:    cmp    r4, r5
>>       ldrcc    r7, [r4], #4    @ use branch for delay slot
>
>
> Yeah, prefer my macros for doing this.
>
>
>> Index: linux-linaro-tracking/arch/arm/kernel/kprobes.c
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/kernel/kprobes.c
>> +++ linux-linaro-tracking/arch/arm/kernel/kprobes.c
>> @@ -66,14 +66,24 @@ int __kprobes arch_prepare_kprobe(struct
>>       if (is_wide_instruction(insn)) {
>>           insn<<= 16;
>>           insn |= ((u16 *)addr)[1];
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +                insn = __swab32(insn); /* little endian instruction */
>> +#endif
>>           decode_insn = thumb32_kprobe_decode_insn;
>> -    } else
>> -        decode_insn = thumb16_kprobe_decode_insn;
>> +    } else {
>> +                decode_insn = thumb16_kprobe_decode_insn;
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +                insn = __swab16(insn); /* little endian instruction */
>> +#endif
>> +        }
>>   #else /* !CONFIG_THUMB2_KERNEL */
>>       thumb = false;
>>       if (addr&  0x3)
>>
>>           return -EINVAL;
>>       insn = *p->addr;
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +        insn = __swab32(insn); /* little endian instruction */
>> +#endif
>>       decode_insn = arm_kprobe_decode_insn;
>>   #endif
>>
>> @@ -89,7 +99,11 @@ int __kprobes arch_prepare_kprobe(struct
>>           if (!p->ainsn.insn)
>>               return -ENOMEM;
>>           for (is = 0; is<  MAX_INSN_SIZE; ++is)
>> +#ifndef CONFIG_CPU_ENDIAN_BE8
>>               p->ainsn.insn[is] = tmp_insn[is];
>> +#else
>> +                        p->ainsn.insn[is] = __swab32(tmp_insn[is]);
>> /* little endian instruction */
>> +#endif
>>           flush_insns(p->ainsn.insn,
>>                   sizeof(p->ainsn.insn[0]) * MAX_INSN_SIZE);
>>           p->ainsn.insn_fn = (kprobe_insn_fn_t *)
>> @@ -113,10 +127,17 @@ void __kprobes arch_arm_kprobe(struct kp
>>           /* Remove any Thumb flag */
>>           addr = (void *)((uintptr_t)p->addr&  ~1);
>>
>>
>> -        if (is_wide_instruction(p->opcode))
>> +        if (is_wide_instruction(p->opcode)) {
>>               brkp = KPROBE_THUMB32_BREAKPOINT_INSTRUCTION;
>> -        else
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +                brkp = __swab32(brkp);
>> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
>> +        } else {
>>               brkp = KPROBE_THUMB16_BREAKPOINT_INSTRUCTION;
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +                brkp = __swab16(brkp);
>> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
>> +            }
>>       } else {
>>           kprobe_opcode_t insn = p->opcode;
>>
>> @@ -127,6 +148,10 @@ void __kprobes arch_arm_kprobe(struct kp
>>               brkp |= 0xe0000000;  /* Unconditional instruction */
>>           else
>>               brkp |= insn&  0xf0000000;  /* Copy condition from insn */
>>
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +        brkp = __swab32(brkp);
>> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
>> +
>>       }
>>
>>       patch_text(addr, brkp);
>> @@ -144,8 +169,12 @@ int __kprobes __arch_disarm_kprobe(void
>>   {
>>       struct kprobe *kp = p;
>>       void *addr = (void *)((uintptr_t)kp->addr&  ~1);
>>
>> +    kprobe_opcode_t insn = kp->opcode;
>>
>> -    __patch_text(addr, kp->opcode);
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +        insn = __swab32(insn); /* little endian instruction */
>> +#endif
>> +    __patch_text(addr, insn);
>>
>>       return 0;
>>
>
> __patch_text already does swapping, so a little concerned that it
> is being done twice in some places.
>
>
>
>> Index: linux-linaro-tracking/arch/arm/kernel/traps.c
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/kernel/traps.c
>> +++ linux-linaro-tracking/arch/arm/kernel/traps.c
>> @@ -426,6 +426,10 @@ asmlinkage void __exception do_undefinst
>>           goto die_sig;
>>       }
>>
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +        instr = __swab32(instr); /* little endian instruction */
>> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
>> +
>>       if (call_undef_hook(regs, instr) == 0)
>>           return;
>
>
> already fixed.
>
>
>> Index: linux-linaro-tracking/arch/arm/kernel/ftrace.c
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/kernel/ftrace.c
>> +++ linux-linaro-tracking/arch/arm/kernel/ftrace.c
>> @@ -100,10 +100,18 @@ static int ftrace_modify_code(unsigned l
>>           if (probe_kernel_read(&replaced, (void *)pc, MCOUNT_INSN_SIZE))
>>               return -EFAULT;
>>
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +        replaced = __swab32(replaced); /* little endian instruction */
>> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
>> +
>>           if (replaced != old)
>>               return -EINVAL;
>>       }
>>
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +        new = __swab32(new); /* little endian instruction */
>> +#endif /* CONFIG_CPU_ENDIAN_BE8 */
>> +
>>       if (probe_kernel_write((void *)pc,&new, MCOUNT_INSN_SIZE))
>>           return -EPERM;
>
>
> Please see <asm/opcodes.h> for dealing with the op-codes like this.

Yes, agree. It is not needed any more. In kernel 3.1/3.2 there was no
asm/opcodes.h, __opcode_to_mem_arm, etc macros. So that was added. It is
incorrect now.

>
>> Index: linux-linaro-tracking/arch/arm/kernel/atags_parse.c
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/kernel/atags_parse.c
>> +++ linux-linaro-tracking/arch/arm/kernel/atags_parse.c
>> @@ -216,6 +216,10 @@ struct machine_desc * __init setup_machi
>>       if (tags->hdr.tag != ATAG_CORE)
>>           convert_to_tag_list(tags);
>>   #endif
>> +#ifdef CONFIG_LITTLE_ENDIAN_LOADER
>> +    byteswap_tags(tags);
>> +#endif /* CONFIG_LITTLE_ENDIAN_LOADER */
>> +
>>       if (tags->hdr.tag != ATAG_CORE) {
>>           early_print("Warning: Neither atags nor dtb found\n");
>>           tags = (struct tag *)&default_tags;
>> Index: linux-linaro-tracking/arch/arm/kernel/sleep.S
>
>
> I really don't like this way, it makes it difficult to deal with
> if you export this data to user-space to then do things like md5sum
> it. Also, if you're going to kexec() a new kernel, would you have
> to re-swap it back before this?

Agree that swap in place could be problematic.
I will look at this, starting with patches you've done. Will get back to you.

>> Index: linux-linaro-tracking/arch/arm/include/asm/atomic.h
>> ===================================================================
>> --- linux-linaro-tracking.orig/arch/arm/include/asm/atomic.h
>> +++ linux-linaro-tracking/arch/arm/include/asm/atomic.h
>> @@ -301,8 +301,13 @@ static inline void atomic64_add(u64 i, a
>>
>>       __asm__ __volatile__("@ atomic64_add\n"
>>   "1:    ldrexd    %0, %H0, [%3]\n"
>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>   "    adds    %0, %0, %4\n"
>>   "    adc    %H0, %H0, %H4\n"
>> +#else
>> +"    adds    %H0, %H0, %H4\n"
>> +"    adc    %0, %0, %4\n"
>> +#endif
>>   "    strexd    %1, %0, %H0, [%3]\n"
>>   "    teq    %1, #0\n"
>>   "    bne    1b"
>> @@ -320,8 +325,13 @@ static inline u64 atomic64_add_return(u6
>>
>>       __asm__ __volatile__("@ atomic64_add_return\n"
>>   "1:    ldrexd    %0, %H0, [%3]\n"
>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>   "    adds    %0, %0, %4\n"
>>   "    adc    %H0, %H0, %H4\n"
>> +#else
>> +"    adds    %H0, %H0, %H4\n"
>> +"    adc    %0, %0, %4\n"
>> +#endif
>>   "    strexd    %1, %0, %H0, [%3]\n"
>>   "    teq    %1, #0\n"
>>   "    bne    1b"
>> @@ -341,8 +351,13 @@ static inline void atomic64_sub(u64 i, a
>>
>>       __asm__ __volatile__("@ atomic64_sub\n"
>>   "1:    ldrexd    %0, %H0, [%3]\n"
>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>   "    subs    %0, %0, %4\n"
>>   "    sbc    %H0, %H0, %H4\n"
>> +#else
>> +"    subs    %H0, %H0, %H4\n"
>> +"    sbc    %0, %0, %4\n"
>> +#endif
>>   "    strexd    %1, %0, %H0, [%3]\n"
>>   "    teq    %1, #0\n"
>>   "    bne    1b"
>> @@ -360,8 +375,13 @@ static inline u64 atomic64_sub_return(u6
>>
>>       __asm__ __volatile__("@ atomic64_sub_return\n"
>>   "1:    ldrexd    %0, %H0, [%3]\n"
>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>   "    subs    %0, %0, %4\n"
>>   "    sbc    %H0, %H0, %H4\n"
>> +#else
>> +"    subs    %H0, %H0, %H4\n"
>> +"    sbc    %0, %0, %4\n"
>> +#endif
>>   "    strexd    %1, %0, %H0, [%3]\n"
>>   "    teq    %1, #0\n"
>>   "    bne    1b"
>> @@ -428,9 +448,15 @@ static inline u64 atomic64_dec_if_positi
>>
>>       __asm__ __volatile__("@ atomic64_dec_if_positive\n"
>>   "1:    ldrexd    %0, %H0, [%3]\n"
>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>   "    subs    %0, %0, #1\n"
>>   "    sbc    %H0, %H0, #0\n"
>>   "    teq    %H0, #0\n"
>> +#else
>> +"    subs    %H0, %H0, #1\n"
>> +"    sbc    %0, %0, #0\n"
>> +"    teq    %0, #0\n"
>> +#endif
>>   "    bmi    2f\n"
>>   "    strexd    %1, %0, %H0, [%3]\n"
>>   "    teq    %1, #0\n"
>> @@ -459,8 +485,13 @@ static inline int atomic64_add_unless(at
>>   "    teqeq    %H0, %H5\n"
>>   "    moveq    %1, #0\n"
>>   "    beq    2f\n"
>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>   "    adds    %0, %0, %6\n"
>>   "    adc    %H0, %H0, %H6\n"
>> +#else
>> +"    adds    %H0, %H0, %H6\n"
>> +"    adc    %0, %0, %6\n"
>> +#endif
>>   "    strexd    %2, %0, %H0, [%4]\n"
>>   "    teq    %2, #0\n"
>>   "    bne    1b\n"
>
>
> I still believe that you're doing the wrong thing here
> and that these can be left well enough alone. Please give
> a concrete piece of code that can show they're actually
> doing the wrong thing.

That one is addressed in separate email.

Thanks,
Victor

>
>
>
> --
> Ben Dooks                               http://www.codethink.co.uk/
> Senior Engineer                         Codethink - Providing Genius


From kgene at kernel.org  Wed Jul 24 03:36:29 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 24 Jul 2013 16:36:29 +0900
Subject: [PATCH V2 2/2] ARM: EXYNOS: cpuidle: Allow C1 state only in
 supported SOC's.
In-Reply-To: <CADGdYn5uY7A9OB=xGi_oKS3DX6+wRhbKBnTfxjkFY5OtUX3hXg@mail.gmail.com>
References: <1371036526-16589-1-git-send-email-amit.daniel@samsung.com>
 <1371036526-16589-3-git-send-email-amit.daniel@samsung.com>
 <0e2301ce882c$d39021a0$7ab064e0$@org>
 <CADGdYn5uY7A9OB=xGi_oKS3DX6+wRhbKBnTfxjkFY5OtUX3hXg@mail.gmail.com>
Message-ID: <0e7d01ce8840$82f79070$88e6b150$@org>

amit daniel kachhap wrote:

[...]

> >>               /* Support IDLE only */
> >> -             if (cpu_id != 0)
> >> +             if (!(soc_is_exynos4210() || soc_is_exynos4212() ||
> >> +                     soc_is_exynos4412() || soc_is_exynos5250()) ||
> >> +                     cpu_id != 0)
> >
> > How about exynos5420?
> >
> > So...
> >
> > +               if (soc_is_exynos5440() || cpu_id !=0) ?
> This is fine.
> 
So, you will re-send?

- Kukjin



From horms at verge.net.au  Wed Jul 24 03:39:53 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 16:39:53 +0900
Subject: [PATCH] ARM: shmobile: marzen: Switch to DT_MACHINE_START
In-Reply-To: <20130724073042.28351.33041.sendpatchset@w520>
References: <20130724073042.28351.33041.sendpatchset@w520>
Message-ID: <20130724073952.GD17045@verge.net.au>

On Wed, Jul 24, 2013 at 04:30:42PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Convert the marzen board to use DT_MACHINE_START. With this in
> place all mach-shmobile boards use DT_MACHINE_START. Also, this
> makes it possible for the r8a7779 SMP code to use DT for CPUs.
> 
> So appended DTB is the way forward on this board.

Please supply a patch to update the defconfig accordingly.

> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  Written on top of renesas-devel-20130724
> 
>  arch/arm/mach-shmobile/board-marzen.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- 0001/arch/arm/mach-shmobile/board-marzen.c
> +++ work/arch/arm/mach-shmobile/board-marzen.c	2013-07-24 15:45:39.000000000 +0900
> @@ -238,7 +238,7 @@ static void __init marzen_init(void)
>  	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
>  }
>  
> -MACHINE_START(MARZEN, "marzen")
> +DT_MACHINE_START(MARZEN, "marzen")
>  	.smp		= smp_ops(r8a7779_smp_ops),
>  	.map_io		= r8a7779_map_io,
>  	.init_early	= r8a7779_add_early_devices,
> 


From kgene at kernel.org  Wed Jul 24 03:55:16 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 24 Jul 2013 16:55:16 +0900
Subject: [PATCH v3 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <CAK9yfHz-UcA0--Md0YfrTkPvqzZncTcu-6a-AaHbiWx2tJZczw@mail.gmail.com>
References: <1374636693-32336-1-git-send-email-sachin.kamat@linaro.org>
 <0e4301ce8835$f5bef5e0$e13ce1a0$@org>
 <CAK9yfHz-UcA0--Md0YfrTkPvqzZncTcu-6a-AaHbiWx2tJZczw@mail.gmail.com>
Message-ID: <0e8401ce8843$22817960$67846c20$@org>

Sachin Kamat wrote:
> 
> On 24 July 2013 11:50, Kukjin Kim <kgene at kernel.org> wrote:
> > Sachin Kamat wrote:
> >>
> >> With the recent cleanup in Exynos platform code notably commits
> >> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
> >> more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
> >> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs
> like
> >> Exynos4412 which have more than the default number of GPIOs. Thus
> define
> >> this number in KConfig file which takes care of current SoC
> requirements
> >> and provides scope for GPIO expanders. Without this patch we get the
> >> following
> >> errors during boot:
> >>
> >> gpiochip_add: gpios 251..258 (gpv0) failed to register
> >> samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
> >> error code: -22
> >> samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
> >>
> >> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> >> Cc: Tomasz Figa <t.figa at samsung.com>
> >> ---
> >> Changes since v2:
> >> Changed the default number to 512 to accomodate GPIO exapnders.
> >> ---
> >>  arch/arm/Kconfig |    1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> index ccc388d..b3c4fa4 100644
> >> --- a/arch/arm/Kconfig
> >> +++ b/arch/arm/Kconfig
> >> @@ -1601,6 +1601,7 @@ config ARCH_NR_GPIO
> >>       int
> >>       default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
> >>       default 512 if SOC_OMAP5
> >> +     default 512 if ARCH_EXYNOS
> >>       default 512 if ARCH_KEYSTONE
> >
> > +       default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 ?
> 
> Looks good. Do you want me to re-send this?
> 
Yes, please.

- Kukjin



From lars at metafoo.de  Wed Jul 24 04:03:30 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Wed, 24 Jul 2013 10:03:30 +0200
Subject: [PATCH] dma: edma: add device_slave_caps() support
In-Reply-To: <1374597804-3961-1-git-send-email-joelf@ti.com>
References: <1374597804-3961-1-git-send-email-joelf@ti.com>
Message-ID: <51EF8A52.90902@metafoo.de>

On 07/23/2013 06:43 PM, Joel Fernandes wrote:
> Implement device_slave_caps(). EDMA has a limited number of slots.
> Slave drivers such as omap_hsmmc will query the driver to make
> sure they don't pass in more than these many scatter segments.
> 
> Signed-off-by: Joel Fernandes <joelf at ti.com>
> ---
> Vinod, or Dan- If this patch looks ok, can you please merge in for
> -rc cycle? This patch is required to fix MMC support on AM33xx. This
> patch is blocking 3 other patches which fix various MMC things. Thanks!
> 
> Notes:
> (1) this approach is temporary and only for -rc cycle to fix MMC on
> AM335x. It will be replace by the RFC series in future kernels:
> http://www.spinics.net/lists/arm-kernel/msg260094.html
> 
> (2) Patch depends Vinod's patch at:
> http://permalink.gmane.org/gmane.linux.kernel/1525112
> 
>  drivers/dma/edma.c |    9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 7222cbe..81d5429 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -517,6 +517,14 @@ static void edma_issue_pending(struct dma_chan *chan)
>  	spin_unlock_irqrestore(&echan->vchan.lock, flags);
>  }
>  
> +static inline int edma_slave_caps(struct dma_chan *chan,
> +	struct dma_slave_caps *caps)
> +{
> +	caps->max_sg_nr = MAX_NR_SG;

Hm, what about the other fields?

- Lars



From horms at verge.net.au  Wed Jul 24 04:05:32 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 17:05:32 +0900
Subject: [GIT 00/19 v2] Renesas ARM based SoC pinmux updates for v3.12
In-Reply-To: <cover.1374625203.git.horms+renesas@verge.net.au>
References: <cover.1374625203.git.horms+renesas@verge.net.au>
Message-ID: <20130724080532.GA9276@verge.net.au>

On Wed, Jul 24, 2013 at 09:32:14AM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> please consider the following pinmux updates for v3.12.
> 
> Difference with v1 of this pull-request:
> * Remove bogus i2c portions of the first patch of the series.
> * Correct addressing mode used in dts of the first patch of the series.
> * Removal of egg from face: wip

This pull request has conflicts with renesas-soc-for-v3.12, which I also
sent a pull request for earlier today. I have a provided an example
resolution as part of the renesas-devel-20130724v2 tag in the renesas tree.

In words: take both sides.

The conflicting files are:
	arch/arm/boot/dts/r8a73a4.dtsi
	arch/arm/boot/dts/r8a7790.dtsi

> 
> The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:
> 
>   Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-pinmux-for-v3.12
> 
> for you to fetch changes up to 1469273960de45275f33276c7254456edcba9da2:
> 
>   ARM: shmobile: kzm9g-reference: Add LED1-LED4 to the device tree (2013-07-22 10:12:41 +0900)
> 
> ----------------------------------------------------------------
> Renesas ARM based SoC pinmux updates for v3.12
> 
> SH Mobile pinctrl DT support
> 
> ----------------------------------------------------------------
> Laurent Pinchart (19):
>       ARM: shmobile: r8a73a4: Add pin control device to device tree
>       ARM: shmobile: r8a7740: Add pin control device to device tree
>       ARM: shmobile: r8a7778: Add pin control device to device tree
>       ARM: shmobile: r8a7778: Add GPIO controller devices to device tree
>       ARM: shmobile: r8a7779: Add pin control device to device tree
>       ARM: shmobile: r8a7779: Add GPIO controller devices to device tree
>       ARM: shmobile: r8a7790: Add pin control device to device tree
>       ARM: shmobile: r8a7790: Add GPIO controller devices to device tree
>       ARM: shmobile: sh7372: Add pin control device to device tree
>       ARM: shmobile: sh73a0: Add pin control device to device tree
>       ARM: shmobile: armadillo-reference: Move pinctrl mappings to device tree
>       ARM: shmobile: armadillo-reference: Add st1232 pin mappings
>       ARM: shmobile: armadillo-reference: Move st1232 reset GPIO to DT
>       ARM: shmobile: armadillo-reference: Add LED1-LED4 to the device tree
>       ARM: shmobile: marzen-reference: Move pinctrl mappings to device tree
>       ARM: shmobile: marzen-reference: Add LED2-LED4 to the device tree
>       ARM: shmobile: kzm9g-reference: Move pinctrl mappings to device tree
>       ARM: shmobile: kzm9g-reference: Move SDHI regulators to DT
>       ARM: shmobile: kzm9g-reference: Add LED1-LED4 to the device tree
> 
>  arch/arm/boot/dts/r8a73a4.dtsi                     |  7 ++
>  .../boot/dts/r8a7740-armadillo800eva-reference.dts | 34 ++++++++
>  arch/arm/boot/dts/r8a7740.dtsi                     |  8 ++
>  arch/arm/boot/dts/r8a7778.dtsi                     | 66 ++++++++++++++++
>  arch/arm/boot/dts/r8a7779-marzen-reference.dts     | 49 ++++++++++++
>  arch/arm/boot/dts/r8a7779.dtsi                     | 90 ++++++++++++++++++++++
>  arch/arm/boot/dts/r8a7790.dtsi                     | 78 +++++++++++++++++++
>  arch/arm/boot/dts/sh7372.dtsi                      |  8 ++
>  arch/arm/boot/dts/sh73a0-kzm9g-reference.dts       | 90 +++++++++++++++++++++-
>  arch/arm/boot/dts/sh73a0.dtsi                      |  8 ++
>  .../board-armadillo800eva-reference.c              | 18 +----
>  arch/arm/mach-shmobile/board-kzm9g-reference.c     | 47 -----------
>  arch/arm/mach-shmobile/board-marzen-reference.c    | 28 -------
>  13 files changed, 437 insertions(+), 94 deletions(-)
> 


From horms at verge.net.au  Wed Jul 24 04:06:01 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 17:06:01 +0900
Subject: [GIT 00/16] Renesas ARM based SoC updates for v3.12
In-Reply-To: <cover.1374624383.git.horms+renesas@verge.net.au>
References: <cover.1374624383.git.horms+renesas@verge.net.au>
Message-ID: <20130724080600.GB9276@verge.net.au>

On Wed, Jul 24, 2013 at 09:33:45AM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> please consider the following Renesas ARM based SoC updates for v3.12.
> 
> This pull request is based on renesas-dt-for-v3.12 which I have
> previously sent a pull request for.

This pull request has conflicts with renesas-pinmux-for-v3.12, which I also
sent a pull request for earlier today. I have a provided an example
resolution as part of the renesas-devel-20130724v2 tag in the renesas tree.

In words: take both sides.

The conflicting files are:
        arch/arm/boot/dts/r8a73a4.dtsi
        arch/arm/boot/dts/r8a7790.dtsi

> 
> The following changes since commit 66a5cab04d339d02b93a4671eadf8e251dbfdc2c:
> 
>   ARM: shmobile: Add SMSC ethernet chip to KZM9D DT reference (2013-07-17 10:06:47 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-for-v3.12
> 
> for you to fetch changes up to 81b9d5351fa96caad4accc6711bc1b9342927d4a:
> 
>   ARM: shmobile: Setup r8a7790 arch timer based on MD pins (2013-07-17 14:26:56 +0900)
> 
> ----------------------------------------------------------------
> Renesas ARM based SoC updates for v3.12
> 
> * Setup arch timer based on MD pins on r8a7790 SoC
> * Thermal driver support for r8a7790 SoC
> * Make arch timer optional for r8a7790 and r8a73a4 SoCs
> * CMT10 clock event for r8a7790 and r8a73a4 SoCs
> * Increased clock coverage for r8a73a4 SoC
> * MMCIF DMA definitions for r8a7740 SoC
> * Disconnect SMP code from clocks on emev2 SoC
> 
> ----------------------------------------------------------------
> Guennadi Liakhovetski (6):
>       ARM: shmobile: r8a73a4: wait for completion when kicking the clock
>       ARM: shmobile: r8a73a4: implement CPU clock scaling for CPUFreq
>       ARM: shmobile: r8a73a4: safeguard against wrong clk_set_rate() uses
>       ARM: shmobile: r8a73a4: add Z2 clock support
>       ARM: shmobile: r8a73a4: add clocks for I2C controllers
>       ARM: shmobile: r8a7740: add MMCIF DMA definitions
> 
> Magnus Damm (8):
>       ARM: shmobile: Sort r8a7790 MSTP entries
>       ARM: shmobile: Add r8a7790 CMT00 clock event
>       ARM: shmobile: Make r8a7790 Arch timer optional
>       ARM: shmobile: Add r8a73a4 CMT10 clock event
>       ARM: shmobile: Make r8a73a4 Arch timer optional
>       ARM: shmobile: Disconnect EMEV2 SMP code from clocks
>       ARM: shmobile: Introduce r8a7790_read_mode_pins()
>       ARM: shmobile: Setup r8a7790 arch timer based on MD pins
> 
> Simon Horman (2):
>       ARM: shmobile: r8a7790: add clocks for thermal
>       ARM: shmobile: r8a7790: add thermal driver support
> 
>  arch/arm/mach-shmobile/Kconfig                |   4 +-
>  arch/arm/mach-shmobile/board-ape6evm.c        |   1 +
>  arch/arm/mach-shmobile/board-lager.c          |   1 +
>  arch/arm/mach-shmobile/clock-emev2.c          |  18 ---
>  arch/arm/mach-shmobile/clock-r8a73a4.c        | 199 ++++++++++++++++++++++++--
>  arch/arm/mach-shmobile/clock-r8a7790.c        |  23 +--
>  arch/arm/mach-shmobile/include/mach/emev2.h   |   1 -
>  arch/arm/mach-shmobile/include/mach/r8a73a4.h |   1 +
>  arch/arm/mach-shmobile/include/mach/r8a7740.h |   2 +
>  arch/arm/mach-shmobile/include/mach/r8a7790.h |   4 +
>  arch/arm/mach-shmobile/setup-r8a73a4.c        |  30 ++++
>  arch/arm/mach-shmobile/setup-r8a7740.c        |  10 ++
>  arch/arm/mach-shmobile/setup-r8a7790.c        | 106 +++++++++++++-
>  arch/arm/mach-shmobile/smp-emev2.c            |  11 +-
>  14 files changed, 363 insertions(+), 48 deletions(-)
> 


From horms at verge.net.au  Wed Jul 24 04:06:16 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 17:06:16 +0900
Subject: [PATCH 19/22] ARM: shmobile: r8a7779: Remove '0x's from R8A7779
 DTS file
In-Reply-To: <20130723075232.GD26801@laptop>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-19-git-send-email-lee.jones@linaro.org>
 <20130723013343.GG16481@verge.net.au>
 <20130723075232.GD26801@laptop>
Message-ID: <20130724080616.GB10027@verge.net.au>

On Tue, Jul 23, 2013 at 08:52:32AM +0100, Lee Jones wrote:
> On Tue, 23 Jul 2013, Simon Horman wrote:
> 
> > On Mon, Jul 22, 2013 at 11:52:38AM +0100, Lee Jones wrote:
> > > Cc: Simon Horman <horms+renesas at verge.net.au>
> > > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > 
> > Acked-by: Simon Horman <horms+renesas at verge.net.au>
> > 
> > Let me know if you want me to take this through the renesas tree.
> 
> Thanks Simon. To save on conflicts, I think that's best.
> 
> I will take all orphaned patches or ones without maintainers associated
> with them through ARM SoC, but if you can take it, please do.

Understood.

I have queued this up for v3.12 in the fixes2-for-v3.12 branch
of my renesas tree on kernel.org.


From horms at verge.net.au  Wed Jul 24 04:06:19 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 17:06:19 +0900
Subject: [PATCH 1/2] ARCH: ARM: shmobile: Remove kota2 board support
In-Reply-To: <1374465895-8372-2-git-send-email-horms+renesas@verge.net.au>
References: <1374465895-8372-1-git-send-email-horms+renesas@verge.net.au>
 <1374465895-8372-2-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130724080619.GC10027@verge.net.au>

On Mon, Jul 22, 2013 at 01:04:54PM +0900, Simon Horman wrote:
> Remove support for the sh73a0 based kota2 board.
> 
> The sh73a0 SoC is continued to be supported using
> the kzm9g board.
> 
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

I have queued this up for v3.12 in the cleanup2 branch of my renesas
tree on kernel.org.


From horms at verge.net.au  Wed Jul 24 04:06:25 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 17:06:25 +0900
Subject: [PATCH 2/2] ARCH: ARM: shmobile: Remove ag5evm board support
In-Reply-To: <1374465895-8372-3-git-send-email-horms+renesas@verge.net.au>
References: <1374465895-8372-1-git-send-email-horms+renesas@verge.net.au>
 <1374465895-8372-3-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130724080625.GD10027@verge.net.au>

On Mon, Jul 22, 2013 at 01:04:55PM +0900, Simon Horman wrote:
> Remove support for the sh73a0 based ag5evm board.
> 
> The sh73a0 SoC is continued to be supported using
> the kzm9g board.
> 
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

I have queued this up for v3.12 in the cleanup2 branch of my renesas
tree on kernel.org.  


From horms at verge.net.au  Wed Jul 24 04:06:29 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 17:06:29 +0900
Subject: [PATCH 01/08] ARM: shmobile: Remove sh73a0 use of
 <mach/hardware.h>
In-Reply-To: <20130724033724.30567.31754.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
 <20130724033724.30567.31754.sendpatchset@w520>
Message-ID: <20130724080628.GE10027@verge.net.au>

On Wed, Jul 24, 2013 at 12:37:24PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Remove unused <mach/hardware.h> on sh73a0.

Thanks, I have queued this up for v3.12 in the cleanup2 branch.


From horms at verge.net.au  Wed Jul 24 04:06:37 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 17:06:37 +0900
Subject: [PATCH 02/08] ARM: shmobile: Remove sh7372 use of
 <mach/hardware.h>
In-Reply-To: <20130724033734.30567.25082.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
 <20130724033734.30567.25082.sendpatchset@w520>
Message-ID: <20130724080636.GF10027@verge.net.au>

On Wed, Jul 24, 2013 at 12:37:34PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Remove unused <mach/hardware.h> on sh7372.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

Thanks, I have queued this up for v3.12 in the cleanup2 branch.


From horms at verge.net.au  Wed Jul 24 04:06:41 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 17:06:41 +0900
Subject: [PATCH 03/08] ARM: shmobile: Remove EMEV2 use of <mach/hardware.h>
In-Reply-To: <20130724033743.30567.57468.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
 <20130724033743.30567.57468.sendpatchset@w520>
Message-ID: <20130724080640.GG10027@verge.net.au>

On Wed, Jul 24, 2013 at 12:37:43PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Remove unused <mach/hardware.h> on EMEV2.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

Thanks, I have queued this up for v3.12 in the cleanup2 branch.


From horms at verge.net.au  Wed Jul 24 04:06:47 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 17:06:47 +0900
Subject: [PATCH 04/08] ARM: shmobile: Remove r8a7779 use of
 <mach/hardware.h>
In-Reply-To: <20130724033752.30567.70305.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
 <20130724033752.30567.70305.sendpatchset@w520>
Message-ID: <20130724080646.GH10027@verge.net.au>

On Wed, Jul 24, 2013 at 12:37:52PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Remove unused <mach/hardware.h> on r8a7779.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

Thanks, I have queued this up for v3.12 in the cleanup2 branch.


From horms at verge.net.au  Wed Jul 24 04:06:51 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 17:06:51 +0900
Subject: [PATCH 07/08] ARM: shmobile: Remove Marzen use of
 <mach/hardware.h>
In-Reply-To: <20130724033820.30567.27069.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
 <20130724033820.30567.27069.sendpatchset@w520>
Message-ID: <20130724080650.GI10027@verge.net.au>

On Wed, Jul 24, 2013 at 12:38:20PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Remove unused <mach/hardware.h> on Marzen.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

Thanks, I have queued this up for v3.12 in the cleanup2 branch.


From horms at verge.net.au  Wed Jul 24 04:06:56 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 17:06:56 +0900
Subject: [PATCH 08/08] ARM: shmobile: Remove include <mach/hardware.h>
In-Reply-To: <20130724033829.30567.27355.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
 <20130724033829.30567.27355.sendpatchset@w520>
Message-ID: <20130724080655.GJ10027@verge.net.au>

On Wed, Jul 24, 2013 at 12:38:29PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Now when no one is using this file, remove <mach/hardware.h>.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

Thanks, I have queued this up for v3.12 in the cleanup2 branch.


From horms at verge.net.au  Wed Jul 24 04:07:00 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 17:07:00 +0900
Subject: [PATCH 05/08] ARM: shmobile: Remove AG5EVM use of
 <mach/hardware.h>
In-Reply-To: <20130724033801.30567.89261.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
 <20130724033801.30567.89261.sendpatchset@w520>
Message-ID: <20130724080659.GK10027@verge.net.au>

On Wed, Jul 24, 2013 at 12:38:01PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Remove unused <mach/hardware.h> on AG5EVM.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

I have skipped this patch as the cleanup2 branch, where I am applying
other patches in this series, includes a patch to remove AG5EVM.


From horms at verge.net.au  Wed Jul 24 04:07:06 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 17:07:06 +0900
Subject: [PATCH 06/08] ARM: shmobile: Remove Kota2 use of <mach/hardware.h>
In-Reply-To: <20130724033811.30567.3910.sendpatchset@w520>
References: <20130724033715.30567.82782.sendpatchset@w520>
 <20130724033811.30567.3910.sendpatchset@w520>
Message-ID: <20130724080705.GL10027@verge.net.au>

On Wed, Jul 24, 2013 at 12:38:11PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Remove unused <mach/hardware.h> on Kota2.
> 
> Signed-off-by: Magnus Damm <damm at opensource.se>

I have skipped this patch as the cleanup2 branch, where I am applying
other patches in this series, includes a patch to remove Kota2.


From joelf at ti.com  Wed Jul 24 04:11:23 2013
From: joelf at ti.com (Joel Fernandes)
Date: Wed, 24 Jul 2013 03:11:23 -0500
Subject: [PATCH] dma: edma: add device_slave_caps() support
In-Reply-To: <51EF8A52.90902@metafoo.de>
References: <1374597804-3961-1-git-send-email-joelf@ti.com>
 <51EF8A52.90902@metafoo.de>
Message-ID: <51EF8C2B.2030409@ti.com>

On 07/24/2013 03:03 AM, Lars-Peter Clausen wrote:
> On 07/23/2013 06:43 PM, Joel Fernandes wrote:
>> Implement device_slave_caps(). EDMA has a limited number of slots.
>> Slave drivers such as omap_hsmmc will query the driver to make
>> sure they don't pass in more than these many scatter segments.
>>
>> Signed-off-by: Joel Fernandes <joelf at ti.com>
>> ---
>> Vinod, or Dan- If this patch looks ok, can you please merge in for
>> -rc cycle? This patch is required to fix MMC support on AM33xx. This
>> patch is blocking 3 other patches which fix various MMC things. Thanks!
>>
>> Notes:
>> (1) this approach is temporary and only for -rc cycle to fix MMC on
>> AM335x. It will be replace by the RFC series in future kernels:
>> http://www.spinics.net/lists/arm-kernel/msg260094.html
>>
>> (2) Patch depends Vinod's patch at:
>> http://permalink.gmane.org/gmane.linux.kernel/1525112
>>
>>  drivers/dma/edma.c |    9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
>> index 7222cbe..81d5429 100644
>> --- a/drivers/dma/edma.c
>> +++ b/drivers/dma/edma.c
>> @@ -517,6 +517,14 @@ static void edma_issue_pending(struct dma_chan *chan)
>>  	spin_unlock_irqrestore(&echan->vchan.lock, flags);
>>  }
>>  
>> +static inline int edma_slave_caps(struct dma_chan *chan,
>> +	struct dma_slave_caps *caps)
>> +{
>> +	caps->max_sg_nr = MAX_NR_SG;
> 
> Hm, what about the other fields?
> 

Other fields are unused, the max segment size is supposed to be
calculated "given" the address width and burst size. Since these
can't be provided to get_caps, I have left it out for now.
See: https://lkml.org/lkml/2013/3/6/464

Even if it did, the "segment size" itself is unused in the MMC driver
that this is supposed to fix, unlike the "number of segments" which I'm
populating above.

If you know of a better way to populate max segment size, let me know.

Thanks,

-Joel



From lars at metafoo.de  Wed Jul 24 04:24:46 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Wed, 24 Jul 2013 10:24:46 +0200
Subject: [PATCH] dma: edma: add device_slave_caps() support
In-Reply-To: <51EF8C2B.2030409@ti.com>
References: <1374597804-3961-1-git-send-email-joelf@ti.com>
 <51EF8A52.90902@metafoo.de> <51EF8C2B.2030409@ti.com>
Message-ID: <51EF8F4E.8080806@metafoo.de>

On 07/24/2013 10:11 AM, Joel Fernandes wrote:
> On 07/24/2013 03:03 AM, Lars-Peter Clausen wrote:
>> On 07/23/2013 06:43 PM, Joel Fernandes wrote:
>>> Implement device_slave_caps(). EDMA has a limited number of slots.
>>> Slave drivers such as omap_hsmmc will query the driver to make
>>> sure they don't pass in more than these many scatter segments.
>>>
>>> Signed-off-by: Joel Fernandes <joelf at ti.com>
>>> ---
>>> Vinod, or Dan- If this patch looks ok, can you please merge in for
>>> -rc cycle? This patch is required to fix MMC support on AM33xx. This
>>> patch is blocking 3 other patches which fix various MMC things. Thanks!
>>>
>>> Notes:
>>> (1) this approach is temporary and only for -rc cycle to fix MMC on
>>> AM335x. It will be replace by the RFC series in future kernels:
>>> http://www.spinics.net/lists/arm-kernel/msg260094.html
>>>
>>> (2) Patch depends Vinod's patch at:
>>> http://permalink.gmane.org/gmane.linux.kernel/1525112
>>>
>>>  drivers/dma/edma.c |    9 +++++++++
>>>  1 file changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
>>> index 7222cbe..81d5429 100644
>>> --- a/drivers/dma/edma.c
>>> +++ b/drivers/dma/edma.c
>>> @@ -517,6 +517,14 @@ static void edma_issue_pending(struct dma_chan *chan)
>>>  	spin_unlock_irqrestore(&echan->vchan.lock, flags);
>>>  }
>>>  
>>> +static inline int edma_slave_caps(struct dma_chan *chan,
>>> +	struct dma_slave_caps *caps)
>>> +{
>>> +	caps->max_sg_nr = MAX_NR_SG;
>>
>> Hm, what about the other fields?
>>
> 
> Other fields are unused, the max segment size is supposed to be
> calculated "given" the address width and burst size. Since these
> can't be provided to get_caps, I have left it out for now.
> See: https://lkml.org/lkml/2013/3/6/464

The PL330 driver is similar in this regard, the maximum segment size also
depends on address width and burst width. What I did for the get_slave_caps
implementation is to set it to the minimum maximum size. E.g. in you case
that should be SZ_64K - 1 (burstsize and addrwidth both set to 1).

> 
> Even if it did, the "segment size" itself is unused in the MMC driver
> that this is supposed to fix, unlike the "number of segments" which I'm
> populating above.
> 

E.g. for ALSA we'll need to know the max segment size, so I think it doesn't
hurt add this in this patch as well.

And you should also initialize all the other fields, even though if there
are no users yet. It will be really painful to write generic drivers using
the dmaengine API if none of the dmaengine drivers actually initializes the
caps struct properly.

- Lars


From joelf at ti.com  Wed Jul 24 04:28:32 2013
From: joelf at ti.com (Fernandes, Joel)
Date: Wed, 24 Jul 2013 08:28:32 +0000
Subject: [PATCH] dma: edma: add device_slave_caps() support
In-Reply-To: <51EF8F4E.8080806@metafoo.de>
References: <1374597804-3961-1-git-send-email-joelf@ti.com>
 <51EF8A52.90902@metafoo.de>
 <51EF8C2B.2030409@ti.com>,<51EF8F4E.8080806@metafoo.de>
Message-ID: <FB20353E-4890-4462-A671-3587A3841B4A@ti.com>


On Jul 24, 2013, at 3:23 AM, "Lars-Peter Clausen" <lars at metafoo.de> wrote:

> On 07/24/2013 10:11 AM, Joel Fernandes wrote:
>> On 07/24/2013 03:03 AM, Lars-Peter Clausen wrote:
>>> On 07/23/2013 06:43 PM, Joel Fernandes wrote:
>>>> Implement device_slave_caps(). EDMA has a limited number of slots.
>>>> Slave drivers such as omap_hsmmc will query the driver to make
>>>> sure they don't pass in more than these many scatter segments.
>>>> 
>>>> Signed-off-by: Joel Fernandes <joelf at ti.com>
>>>> ---
>>>> Vinod, or Dan- If this patch looks ok, can you please merge in for
>>>> -rc cycle? This patch is required to fix MMC support on AM33xx. This
>>>> patch is blocking 3 other patches which fix various MMC things. Thanks!
>>>> 
>>>> Notes:
>>>> (1) this approach is temporary and only for -rc cycle to fix MMC on
>>>> AM335x. It will be replace by the RFC series in future kernels:
>>>> http://www.spinics.net/lists/arm-kernel/msg260094.html
>>>> 
>>>> (2) Patch depends Vinod's patch at:
>>>> http://permalink.gmane.org/gmane.linux.kernel/1525112
>>>> 
>>>> drivers/dma/edma.c |    9 +++++++++
>>>> 1 file changed, 9 insertions(+)
>>>> 
>>>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
>>>> index 7222cbe..81d5429 100644
>>>> --- a/drivers/dma/edma.c
>>>> +++ b/drivers/dma/edma.c
>>>> @@ -517,6 +517,14 @@ static void edma_issue_pending(struct dma_chan *chan)
>>>>    spin_unlock_irqrestore(&echan->vchan.lock, flags);
>>>> }
>>>> 
>>>> +static inline int edma_slave_caps(struct dma_chan *chan,
>>>> +    struct dma_slave_caps *caps)
>>>> +{
>>>> +    caps->max_sg_nr = MAX_NR_SG;
>>> 
>>> Hm, what about the other fields?
>> 
>> Other fields are unused, the max segment size is supposed to be
>> calculated "given" the address width and burst size. Since these
>> can't be provided to get_caps, I have left it out for now.
>> See: https://lkml.org/lkml/2013/3/6/464
> 
> The PL330 driver is similar in this regard, the maximum segment size also
> depends on address width and burst width. What I did for the get_slave_caps
> implementation is to set it to the minimum maximum size. E.g. in you case
> that should be SZ_64K - 1 (burstsize and addrwidth both set to 1).

So you're setting max to minimum maximum size? Isn't that like telling the driver that its segments can't be bigger than this... Unless I'm missing something..

> 
>> 
>> Even if it did, the "segment size" itself is unused in the MMC driver
>> that this is supposed to fix, unlike the "number of segments" which I'm
>> populating above.
> 
> E.g. for ALSA we'll need to know the max segment size, so I think it doesn't
> hurt add this in this patch as well.

For alsa it would dma only the minimum max size even if the dma controller could do more?

> 
> And you should also initialize all the other fields, even though if there
> are no users yet. It will be really painful to write generic drivers using
> the dmaengine API if none of the dmaengine drivers actually initializes the
> caps struct properly.

Ok sure.

Thanks,

-Joel

> 
> - Lars


From tomasz.figa at gmail.com  Wed Jul 24 04:32:47 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 24 Jul 2013 10:32:47 +0200
Subject: [PATCH 1/4] ARM: exynos: cpuidle: Fallback to WFI,
 when AFTR is selected
In-Reply-To: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
References: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1566146.MINY8cDBRi@flatron>

Hi Daniel,

On Thursday 18 of July 2013 14:54:27 Daniel Lezcano wrote:
> When there are several cpus online, the AFTR state does not work.
> 
> The AFTR must be selected only when there is one cpu online.
> 
> The previous code was already handling this case.
> 
> Simplified the code, especially the init routine to have the same init
> pattern than the other drivers.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  arch/arm/mach-exynos/cpuidle.c |   13 ++-----------
>  1 file changed, 2 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/cpuidle.c
> b/arch/arm/mach-exynos/cpuidle.c index 17a18ff..cc4b097 100644
> --- a/arch/arm/mach-exynos/cpuidle.c
> +++ b/arch/arm/mach-exynos/cpuidle.c
> @@ -147,16 +147,11 @@ static int exynos4_enter_lowpower(struct
> cpuidle_device *dev, struct cpuidle_driver *drv,
>  				int index)
>  {
> -	int new_index = index;
> -
>  	/* This mode only can be entered when other core's are offline */
>  	if (num_online_cpus() > 1)
> -		new_index = drv->safe_state_index;
> +		return drv->states[0].enter(dev, drv, 0);
> 
> -	if (new_index == 0)
> -		return arm_cpuidle_simple_enter(dev, drv, new_index);
> -	else
> -		return exynos4_enter_core0_aftr(dev, drv, new_index);
> +	return exynos4_enter_core0_aftr(dev, drv, index);
>  }
> 
>  static void __init exynos5_core_down_clk(void)
> @@ -209,10 +204,6 @@ static int __init exynos4_init_cpuidle(void)
>  		device = &per_cpu(exynos4_cpuidle_device, cpu_id);
>  		device->cpu = cpu_id;
> 
> -		/* Support IDLE only */
> -		if (cpu_id != 0)
> -			device->state_count = 1;
> -

Are you sure that this is okay? It means, assuming that you have CPU0 
hotplug enabled, that you can enter the AFTR state if _any_ single core 
remains plugged in, which is technically possible, but then wake-up will 
occur on CPU0, which is not what cpuidle and hotplug code expect.

P.S. Please keep linux-samsung-soc at vger.kernel.org mailing list on Cc for 
patches related to Samsung SoCs.

Best regards,
Tomasz



From tomasz.figa at gmail.com  Wed Jul 24 04:34:36 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 24 Jul 2013 10:34:36 +0200
Subject: [PATCH 3/4] ARM: exynos: cpuidle: Move exynos4_idle_driver
 declaration below in the code
In-Reply-To: <1374152070-21008-3-git-send-email-daniel.lezcano@linaro.org>
References: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
 <1374152070-21008-3-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1870758.9skEtZxYsB@flatron>

On Thursday 18 of July 2013 14:54:29 Daniel Lezcano wrote:
> In order to prevent a pointless forward declaration, move the driver
> declation after the idle function callback, right before the init
> function.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  arch/arm/mach-exynos/cpuidle.c |   40
> ++++++++++++++++++---------------------- 1 file changed, 18
> insertions(+), 22 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/cpuidle.c
> b/arch/arm/mach-exynos/cpuidle.c index d8fc1a2..8d06128 100644
> --- a/arch/arm/mach-exynos/cpuidle.c
> +++ b/arch/arm/mach-exynos/cpuidle.c
> @@ -37,28 +37,6 @@
> 
>  #define S5P_CHECK_AFTR		0xFCBA0D10
> 
> -static int exynos4_enter_lowpower(struct cpuidle_device *dev,
> -				struct cpuidle_driver *drv,
> -				int index);
> -
> -static struct cpuidle_driver exynos4_idle_driver = {
> -	.name			= "exynos4_idle",
> -	.owner			= THIS_MODULE,
> -	.states = {
> -		[0] = ARM_CPUIDLE_WFI_STATE,
> -		[1] = {
> -			.enter			= exynos4_enter_lowpower,
> -			.exit_latency		= 300,
> -			.target_residency	= 100000,
> -			.flags			= CPUIDLE_FLAG_TIME_VALID,
> -			.name			= "C1",
> -			.desc			= "ARM power down",
> -		},
> -	},
> -	.state_count = 2,
> -	.safe_state_index = 0,
> -};
> -
>  /* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
>  static void exynos4_set_wakeupmask(void)
>  {
> @@ -184,6 +162,24 @@ static void __init exynos5_core_down_clk(void)
>  	__raw_writel(tmp, EXYNOS5_PWR_CTRL2);
>  }
> 
> +static struct cpuidle_driver exynos4_idle_driver = {
> +	.name			= "exynos4_idle",
> +	.owner			= THIS_MODULE,
> +	.states = {
> +		[0] = ARM_CPUIDLE_WFI_STATE,
> +		[1] = {
> +			.enter			= exynos4_enter_lowpower,
> +			.exit_latency		= 300,
> +			.target_residency	= 100000,
> +			.flags			= CPUIDLE_FLAG_TIME_VALID,
> +			.name			= "C1",
> +			.desc			= "ARM power down",
> +		},
> +	},
> +	.state_count = 2,
> +	.safe_state_index = 0,
> +};
> +
>  static int __init exynos4_init_cpuidle(void)
>  {
>  	if (soc_is_exynos5250())

Makes sense.

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From tomasz.figa at gmail.com  Wed Jul 24 04:35:01 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 24 Jul 2013 10:35:01 +0200
Subject: [PATCH 4/4] ARM: exynos: cpuidle: Remove useless headers
In-Reply-To: <1374152070-21008-4-git-send-email-daniel.lezcano@linaro.org>
References: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
 <1374152070-21008-4-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <4079574.R74GCppML0@flatron>

On Thursday 18 of July 2013 14:54:30 Daniel Lezcano wrote:
> The headers:
> 
> #include <linux/kernel.h>
> #include <linux/export.h>
> #include <linux/time.h>
> #include <asm/unified.h>
> 
> are not needed. Removed them.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  arch/arm/mach-exynos/cpuidle.c |    4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/cpuidle.c
> b/arch/arm/mach-exynos/cpuidle.c index 8d06128..027f5e7 100644
> --- a/arch/arm/mach-exynos/cpuidle.c
> +++ b/arch/arm/mach-exynos/cpuidle.c
> @@ -8,18 +8,14 @@
>   * published by the Free Software Foundation.
>  */
> 
> -#include <linux/kernel.h>
>  #include <linux/init.h>
>  #include <linux/cpuidle.h>
>  #include <linux/cpu_pm.h>
>  #include <linux/io.h>
> -#include <linux/export.h>
> -#include <linux/time.h>
> 
>  #include <asm/proc-fns.h>
>  #include <asm/smp_scu.h>
>  #include <asm/suspend.h>
> -#include <asm/unified.h>
>  #include <asm/cpuidle.h>
>  #include <mach/regs-clock.h>
>  #include <mach/regs-pmu.h>

Reviewed-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From tomasz.figa at gmail.com  Wed Jul 24 04:36:25 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 24 Jul 2013 10:36:25 +0200
Subject: [PATCH 2/4] ARM: exynos: cpuidle: Use the common cpuidle register
 routine
In-Reply-To: <1374152070-21008-2-git-send-email-daniel.lezcano@linaro.org>
References: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
 <1374152070-21008-2-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <2654254.OiFdVYSdL0@flatron>

On Thursday 18 of July 2013 14:54:28 Daniel Lezcano wrote:
> Now we have the same routine than the one handled by the cpuidle
> framework.
> 
> Let's use it.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  arch/arm/mach-exynos/cpuidle.c |   24 +-----------------------
>  1 file changed, 1 insertion(+), 23 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/cpuidle.c
> b/arch/arm/mach-exynos/cpuidle.c index cc4b097..d8fc1a2 100644
> --- a/arch/arm/mach-exynos/cpuidle.c
> +++ b/arch/arm/mach-exynos/cpuidle.c
> @@ -41,8 +41,6 @@ static int exynos4_enter_lowpower(struct
> cpuidle_device *dev, struct cpuidle_driver *drv,
>  				int index);
> 
> -static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
> -
>  static struct cpuidle_driver exynos4_idle_driver = {
>  	.name			= "exynos4_idle",
>  	.owner			= THIS_MODULE,
> @@ -188,29 +186,9 @@ static void __init exynos5_core_down_clk(void)
> 
>  static int __init exynos4_init_cpuidle(void)
>  {
> -	int cpu_id, ret;
> -	struct cpuidle_device *device;
> -
>  	if (soc_is_exynos5250())
>  		exynos5_core_down_clk();
> 
> -	ret = cpuidle_register_driver(&exynos4_idle_driver);
> -	if (ret) {
> -		printk(KERN_ERR "CPUidle failed to register driver\n");
> -		return ret;
> -	}
> -
> -	for_each_online_cpu(cpu_id) {
> -		device = &per_cpu(exynos4_cpuidle_device, cpu_id);
> -		device->cpu = cpu_id;
> -
> -		ret = cpuidle_register_device(device);
> -		if (ret) {
> -			printk(KERN_ERR "CPUidle register device 
failed\n");
> -			return ret;
> -		}
> -	}
> -
> -	return 0;
> +	return cpuidle_register(&exynos4_idle_driver, NULL);
>  }
>  device_initcall(exynos4_init_cpuidle);

This is nice, but I would like to see clarification for my question posted 
to patch 1/4.

Best regards,
Tomasz



From lars at metafoo.de  Wed Jul 24 04:40:18 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Wed, 24 Jul 2013 10:40:18 +0200
Subject: [PATCH] dma: edma: add device_slave_caps() support
In-Reply-To: <FB20353E-4890-4462-A671-3587A3841B4A@ti.com>
References: <1374597804-3961-1-git-send-email-joelf@ti.com>
 <51EF8A52.90902@metafoo.de> <51EF8C2B.2030409@ti.com>,
 <51EF8F4E.8080806@metafoo.de> <FB20353E-4890-4462-A671-3587A3841B4A@ti.com>
Message-ID: <51EF92F2.3030405@metafoo.de>

On 07/24/2013 10:28 AM, Fernandes, Joel wrote:
> 
> On Jul 24, 2013, at 3:23 AM, "Lars-Peter Clausen" <lars at metafoo.de> wrote:
> 
>> On 07/24/2013 10:11 AM, Joel Fernandes wrote:
>>> On 07/24/2013 03:03 AM, Lars-Peter Clausen wrote:
>>>> On 07/23/2013 06:43 PM, Joel Fernandes wrote:
>>>>> Implement device_slave_caps(). EDMA has a limited number of slots.
>>>>> Slave drivers such as omap_hsmmc will query the driver to make
>>>>> sure they don't pass in more than these many scatter segments.
>>>>>
>>>>> Signed-off-by: Joel Fernandes <joelf at ti.com>
>>>>> ---
>>>>> Vinod, or Dan- If this patch looks ok, can you please merge in for
>>>>> -rc cycle? This patch is required to fix MMC support on AM33xx. This
>>>>> patch is blocking 3 other patches which fix various MMC things. Thanks!
>>>>>
>>>>> Notes:
>>>>> (1) this approach is temporary and only for -rc cycle to fix MMC on
>>>>> AM335x. It will be replace by the RFC series in future kernels:
>>>>> http://www.spinics.net/lists/arm-kernel/msg260094.html
>>>>>
>>>>> (2) Patch depends Vinod's patch at:
>>>>> http://permalink.gmane.org/gmane.linux.kernel/1525112
>>>>>
>>>>> drivers/dma/edma.c |    9 +++++++++
>>>>> 1 file changed, 9 insertions(+)
>>>>>
>>>>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
>>>>> index 7222cbe..81d5429 100644
>>>>> --- a/drivers/dma/edma.c
>>>>> +++ b/drivers/dma/edma.c
>>>>> @@ -517,6 +517,14 @@ static void edma_issue_pending(struct dma_chan *chan)
>>>>>    spin_unlock_irqrestore(&echan->vchan.lock, flags);
>>>>> }
>>>>>
>>>>> +static inline int edma_slave_caps(struct dma_chan *chan,
>>>>> +    struct dma_slave_caps *caps)
>>>>> +{
>>>>> +    caps->max_sg_nr = MAX_NR_SG;
>>>>
>>>> Hm, what about the other fields?
>>>
>>> Other fields are unused, the max segment size is supposed to be
>>> calculated "given" the address width and burst size. Since these
>>> can't be provided to get_caps, I have left it out for now.
>>> See: https://lkml.org/lkml/2013/3/6/464
>>
>> The PL330 driver is similar in this regard, the maximum segment size also
>> depends on address width and burst width. What I did for the get_slave_caps
>> implementation is to set it to the minimum maximum size. E.g. in you case
>> that should be SZ_64K - 1 (burstsize and addrwidth both set to 1).
> 
> So you're setting max to minimum maximum size? Isn't that like telling the driver that its segments can't be bigger than this... Unless I'm missing something..

Yes. This is a limitation of the current slave_caps API. The maximum needs
to be the maximum for all possible configurations. A specific configuration
may allow a larger maximum. So we maybe have to extend the API to be able to
query the limits for a certain configuration. Not sure what the best way
would be to do that, either adding a config parameter to get_slave_caps or
to break it into two functions like you proposed one for the static
capabilities and one for the sg limits.

> 
>>
>>>
>>> Even if it did, the "segment size" itself is unused in the MMC driver
>>> that this is supposed to fix, unlike the "number of segments" which I'm
>>> populating above.
>>
>> E.g. for ALSA we'll need to know the max segment size, so I think it doesn't
>> hurt add this in this patch as well.
> 
> For alsa it would dma only the minimum max size even if the dma controller could do more?
> 

Yes, but I think 64k is still plenty enough for the max period size. The
current davinci PCM driver even claims to only support up to 8k.

- Lars


From horms at verge.net.au  Wed Jul 24 04:46:38 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Jul 2013 17:46:38 +0900
Subject: [PATCH] ARM: shmobile: marzen: Switch to DT_MACHINE_START
In-Reply-To: <20130724073952.GD17045@verge.net.au>
References: <20130724073042.28351.33041.sendpatchset@w520>
 <20130724073952.GD17045@verge.net.au>
Message-ID: <20130724084637.GA5774@verge.net.au>

On Wed, Jul 24, 2013 at 04:39:53PM +0900, Simon Horman wrote:
> On Wed, Jul 24, 2013 at 04:30:42PM +0900, Magnus Damm wrote:
> > From: Magnus Damm <damm at opensource.se>
> > 
> > Convert the marzen board to use DT_MACHINE_START. With this in
> > place all mach-shmobile boards use DT_MACHINE_START. Also, this
> > makes it possible for the r8a7779 SMP code to use DT for CPUs.
> > 
> > So appended DTB is the way forward on this board.
> 
> Please supply a patch to update the defconfig accordingly.

In the course of testing this patch I created
a patch to update the defconfig. I will post it with
a patch to use DT for SMP but I have some questions about this patch.

It seems to me that the following is also needed:

* Select USE_OF in Kconfig
* Provide dt_compat in DT_MACHINE_START
* Provide r8a7779-marzen dts

I have a revised version of this patch which does the above.
But I wanted to check with you that I am on the right track
before posting it.


Also, I think that once sh73a0 and r8a7779 uses DT for SMP we can remove
shmobile_smp_init_cpus(). As you have posted a patch for sh73a0 I have
prepated a patch for r8a7779 I have also prepared a patch to remove
shmobile_smp_init_cpus().

My plan is to post all relevant patches as a series once
my questions above are resolved.

> > Signed-off-by: Magnus Damm <damm at opensource.se>
> > ---
> > 
> >  Written on top of renesas-devel-20130724
> > 
> >  arch/arm/mach-shmobile/board-marzen.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > --- 0001/arch/arm/mach-shmobile/board-marzen.c
> > +++ work/arch/arm/mach-shmobile/board-marzen.c	2013-07-24 15:45:39.000000000 +0900
> > @@ -238,7 +238,7 @@ static void __init marzen_init(void)
> >  	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
> >  }
> >  
> > -MACHINE_START(MARZEN, "marzen")
> > +DT_MACHINE_START(MARZEN, "marzen")
> >  	.smp		= smp_ops(r8a7779_smp_ops),
> >  	.map_io		= r8a7779_map_io,
> >  	.init_early	= r8a7779_add_early_devices,
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From sachin.kamat at linaro.org  Wed Jul 24 04:43:25 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Wed, 24 Jul 2013 14:13:25 +0530
Subject: [PATCH v4 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
Message-ID: <1374655405-22998-1-git-send-email-sachin.kamat@linaro.org>

With the recent cleanup in Exynos platform code notably commits
17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
Exynos4412 which have more than the default number of GPIOs. Thus define
this number in KConfig file which takes care of current SoC requirements
and provides scope for GPIO expanders. Without this patch we get the
following errors during boot:

gpiochip_add: gpios 251..258 (gpv0) failed to register
samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
error code: -22
samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
Cc: Tomasz Figa <t.figa at samsung.com>
---
Changes since v3:
Rearranged different default values in single line.
---
 arch/arm/Kconfig |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f8fb910..ac9fa38 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1590,8 +1590,7 @@ config ARM_PSCI
 config ARCH_NR_GPIO
 	int
 	default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
-	default 512 if SOC_OMAP5
-	default 512 if ARCH_KEYSTONE
+	default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5
 	default 392 if ARCH_U8500
 	default 352 if ARCH_VT8500
 	default 288 if ARCH_SUNXI
-- 
1.7.9.5



From will.deacon at arm.com  Wed Jul 24 05:36:22 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 10:36:22 +0100
Subject: updates for be8 patch series
In-Reply-To: <CAA3XUr31LAJ3+iWq5gXb+JZO-1G96waOFy-RBVZQEW-djj3dYA@mail.gmail.com>
References: <CAA3XUr3h5C0oJVrN5iXsM=NFkLMz_Tssp28CysZfwMNS5KvO-Q@mail.gmail.com>
 <51EEC002.9070808@codethink.co.uk>
 <CAA3XUr2oDEDD6LFjnZ_N0JGTFUMDZG6O9b3JoeJ8AELrK2KDiw@mail.gmail.com>
 <CAA3XUr1BJD-ypfJiEsp079qHDERjGp-xFxc_ke_Ep9z3N=UPaA@mail.gmail.com>
 <51EECBBD.20000@codethink.co.uk>
 <CAA3XUr31LAJ3+iWq5gXb+JZO-1G96waOFy-RBVZQEW-djj3dYA@mail.gmail.com>
Message-ID: <20130724093622.GC9629@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 02:06:05AM +0100, Victor Kamensky wrote:
> Hi Ben,
> 
> Let me split off atomic64 from other issues, so we have focused topic here.
> 
> Please see atomic64 issue test case below. Please try it in your setup. I've
> run on Pandaboard ES with my set of patches, but I believe it should be the
> same in your case.

[...]


> <snip>
> 
> >> Index: linux-linaro-tracking/arch/arm/include/asm/atomic.h
> >> ===================================================================
> >> --- linux-linaro-tracking.orig/arch/arm/include/asm/atomic.h
> >> +++ linux-linaro-tracking/arch/arm/include/asm/atomic.h
> >> @@ -301,8 +301,13 @@ static inline void atomic64_add(u64 i, a
> >>
> >>       __asm__ __volatile__("@ atomic64_add\n"
> >>   "1:    ldrexd    %0, %H0, [%3]\n"
> >> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
> >>   "    adds    %0, %0, %4\n"
> >>   "    adc    %H0, %H0, %H4\n"
> >> +#else
> >> +"    adds    %H0, %H0, %H4\n"
> >> +"    adc    %0, %0, %4\n"
> >> +#endif

I thought you could just use the %Q and %R output modifiers to get the
appropriate halves of the 64-bit operand, then you can avoid the #ifdef.

Will


From amit.daniel at samsung.com  Wed Jul 24 05:53:35 2013
From: amit.daniel at samsung.com (Amit Daniel Kachhap)
Date: Wed, 24 Jul 2013 15:23:35 +0530
Subject: [PATCH] ARM: EXYNOS: cpuidle: Skip C1 cpuidle state for exynos5440
In-Reply-To: <0e7d01ce8840$82f79070$88e6b150$@org>
References: <0e7d01ce8840$82f79070$88e6b150$@org>
Message-ID: <1374659615-29447-1-git-send-email-amit.daniel@samsung.com>

This patch skips the deep C1(AFTR -Arm off top running) state for exynos5440
soc as this soc does not support this state. All the cpu's only allows the basic
C0 state.

Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
---
 arch/arm/mach-exynos/cpuidle.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index 17a18ff..9a776a1 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void)
 		device->cpu = cpu_id;
 
 		/* Support IDLE only */
-		if (cpu_id != 0)
+		if (soc_is_exynos5440() || cpu_id != 0)
 			device->state_count = 1;
 
 		ret = cpuidle_register_device(device);
-- 
1.7.1



From amit.daniel at samsung.com  Wed Jul 24 05:55:48 2013
From: amit.daniel at samsung.com (amit daniel kachhap)
Date: Wed, 24 Jul 2013 15:25:48 +0530
Subject: [PATCH V2 2/2] ARM: EXYNOS: cpuidle: Allow C1 state only in
 supported SOC's.
In-Reply-To: <0e7d01ce8840$82f79070$88e6b150$@org>
References: <1371036526-16589-1-git-send-email-amit.daniel@samsung.com>
 <1371036526-16589-3-git-send-email-amit.daniel@samsung.com>
 <0e2301ce882c$d39021a0$7ab064e0$@org>
 <CADGdYn5uY7A9OB=xGi_oKS3DX6+wRhbKBnTfxjkFY5OtUX3hXg@mail.gmail.com>
 <0e7d01ce8840$82f79070$88e6b150$@org>
Message-ID: <CADGdYn7yOvwr_v5bj9G+iXr_kkqFGXhYPdmcasTPmqh=ROcvnw@mail.gmail.com>

On Wed, Jul 24, 2013 at 1:06 PM, Kukjin Kim <kgene at kernel.org> wrote:
> amit daniel kachhap wrote:
>
> [...]
>
>> >>               /* Support IDLE only */
>> >> -             if (cpu_id != 0)
>> >> +             if (!(soc_is_exynos4210() || soc_is_exynos4212() ||
>> >> +                     soc_is_exynos4412() || soc_is_exynos5250()) ||
>> >> +                     cpu_id != 0)
>> >
>> > How about exynos5420?
>> >
>> > So...
>> >
>> > +               if (soc_is_exynos5440() || cpu_id !=0) ?
>> This is fine.
>>
> So, you will re-send?
Just submitted the patch with this change.

Thanks,
Amit
>
> - Kukjin
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From magnus.damm at gmail.com  Wed Jul 24 06:00:05 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 24 Jul 2013 19:00:05 +0900
Subject: [PATCH] ARM: shmobile: marzen: Switch to DT_MACHINE_START
In-Reply-To: <20130724084637.GA5774@verge.net.au>
References: <20130724073042.28351.33041.sendpatchset@w520>
 <20130724073952.GD17045@verge.net.au>
 <20130724084637.GA5774@verge.net.au>
Message-ID: <CANqRtoT46LimTXt4mihFJS-DDpXOu5wONVX3yWwt=sr9SDvnsg@mail.gmail.com>

Hi Simon,

On Wed, Jul 24, 2013 at 5:46 PM, Simon Horman <horms at verge.net.au> wrote:
> On Wed, Jul 24, 2013 at 04:39:53PM +0900, Simon Horman wrote:
>> On Wed, Jul 24, 2013 at 04:30:42PM +0900, Magnus Damm wrote:
>> > From: Magnus Damm <damm at opensource.se>
>> >
>> > Convert the marzen board to use DT_MACHINE_START. With this in
>> > place all mach-shmobile boards use DT_MACHINE_START. Also, this
>> > makes it possible for the r8a7779 SMP code to use DT for CPUs.
>> >
>> > So appended DTB is the way forward on this board.
>>
>> Please supply a patch to update the defconfig accordingly.
>
> In the course of testing this patch I created
> a patch to update the defconfig. I will post it with
> a patch to use DT for SMP but I have some questions about this patch.
>
> It seems to me that the following is also needed:
>
> * Select USE_OF in Kconfig
> * Provide dt_compat in DT_MACHINE_START
> * Provide r8a7779-marzen dts
>
> I have a revised version of this patch which does the above.
> But I wanted to check with you that I am on the right track
> before posting it.

Yes, you are correct. It seems that I was (am) too trigger happy.
Thanks for fixing these.

> Also, I think that once sh73a0 and r8a7779 uses DT for SMP we can remove
> shmobile_smp_init_cpus(). As you have posted a patch for sh73a0 I have
> prepated a patch for r8a7779 I have also prepared a patch to remove
> shmobile_smp_init_cpus().

I think we should remove that function, but I'd like to put some
shared code in the same file. So I don't want to remove the file.
Perhaps the easiest is to leave it as-is for now and let me deal with
that in an upcoming series.

> My plan is to post all relevant patches as a series once
> my questions above are resolved.

Sounds good, thanks for your help!

Thanks,

/ magnus


From will.deacon at arm.com  Wed Jul 24 06:19:51 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 11:19:51 +0100
Subject: [PATCH 1/6] ARM: prefetch: remove redundant "cc" clobber
In-Reply-To: <alpine.LFD.2.03.1307231547010.15022@syhkavp.arg>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-2-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231547010.15022@syhkavp.arg>
Message-ID: <20130724101950.GG9629@mudshark.cambridge.arm.com>

Hi Nicolas,

On Tue, Jul 23, 2013 at 08:48:11PM +0100, Nicolas Pitre wrote:
> On Tue, 23 Jul 2013, Will Deacon wrote:
> 
> > The pld instruction does not affect the condition flags, so don't bother
> > clobbering them.
> > 
> > Signed-off-by: Will Deacon <will.deacon at arm.com>
> 
> Acked-by: Nicolas Pitre <nico at linaro.org>

Thanks for reviewing the series, much appreciated.

> You know the legacy reason why the cc clobber was there, right?
> It certainly doesn't apply anymore.

I was under the impression that it was due to ancient GCC behaviour and the "cc"
was there to prevent re-ordering. For interest, what are the specifics?

Cheers,

Will


From broonie at kernel.org  Wed Jul 24 06:20:34 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 24 Jul 2013 11:20:34 +0100
Subject: [PATCH v2 3/4] Documentation: DT: Add DSPI driver
In-Reply-To: <1374643943-3324-4-git-send-email-b44548@freescale.com>
References: <1374643943-3324-1-git-send-email-b44548@freescale.com>
 <1374643943-3324-4-git-send-email-b44548@freescale.com>
Message-ID: <20130724102034.GA9858@sirena.org.uk>

On Wed, Jul 24, 2013 at 01:32:22PM +0800, Chao Fu wrote:

Please make sure this document is word wrapped to less than 80 columns.

> +-dspi,ctar-dbr : Double baud rate
> +Doubles the effective baud rate of the Serial Communications Clock (SCK). This field is used only in

> +-dspi,ctar-pbr : Baud Rate Prescaler
> +	0: Baud Rate Prescaler value is 2.
> +	1: Baud Rate Prescaler value is 3.
> +	2: Baud Rate Prescaler value is 5.
> +	3: Baud Rate Prescaler value is 7.

Why do these properties need to be set in DT?  They appears to be just
setting the clock rate for the bus so I'd expect them to be configured
based on that rather than manually specified.
-------------- 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/20130724/6eda3df5/attachment.sig>

From sachin.kamat at linaro.org  Wed Jul 24 06:09:15 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Wed, 24 Jul 2013 15:39:15 +0530
Subject: [PATCH Resend 1/1] clk: exynos4: Add clock entries for TMU
Message-ID: <1374660555-17429-1-git-send-email-sachin.kamat@linaro.org>

Added clock entries for thermal management unit (TMU) for
Exynos4 SoCs.

Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
---
Resending this (after rebasing) based on the below discussion:
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/19933

Previous version:
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/18081
---
 .../devicetree/bindings/clock/exynos4-clock.txt    |    1 +
 drivers/clk/samsung/clk-exynos4.c                  |    4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
index 14d5c2a..c6bf8a6 100644
--- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
@@ -236,6 +236,7 @@ Exynos4 SoC and this is specified where applicable.
   spi0_isp_sclk       380     Exynos4x12
   spi1_isp_sclk       381     Exynos4x12
   uart_isp_sclk       382     Exynos4x12
+  tmu_apbif           383
 
 		[Mux Clocks]
 
diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index 75635eb..cee297d 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -169,7 +169,7 @@ enum exynos4_clks {
 	gicisp, smmu_isp, smmu_drc, smmu_fd, smmu_lite0, smmu_lite1, mcuctl_isp,
 	mpwm_isp, i2c0_isp, i2c1_isp, mtcadc_isp, pwm_isp, wdt_isp, uart_isp,
 	asyncaxim, smmu_ispcx, spi0_isp, spi1_isp, pwm_isp_sclk, spi0_isp_sclk,
-	spi1_isp_sclk, uart_isp_sclk,
+	spi1_isp_sclk, uart_isp_sclk, tmu_apbif,
 
 	/* mux clocks */
 	mout_fimc0 = 384, mout_fimc1, mout_fimc2, mout_fimc3, mout_cam0,
@@ -814,6 +814,7 @@ static struct samsung_gate_clock exynos4210_gate_clks[] __initdata = {
 	GATE_A(keyif, "keyif", "aclk100", E4210_GATE_IP_PERIR, 16, 0, 0, "keypad"),
 	GATE_DA(sclk_fimd1, "exynos4-fb.1", "sclk_fimd1", "div_fimd1",
 			E4210_SRC_MASK_LCD1, 0, CLK_SET_RATE_PARENT, 0, "sclk_fimd"),
+	GATE(tmu_apbif, "tmu_apbif", "aclk100", E4210_GATE_IP_PERIR, 17, 0, 0),
 };
 
 /* list of gate clocks supported in exynos4x12 soc */
@@ -915,6 +916,7 @@ static struct samsung_gate_clock exynos4x12_gate_clks[] __initdata = {
 	GATE(spi1_isp, "spi1_isp", "aclk200", E4X12_GATE_ISP1, 13,
 			CLK_IGNORE_UNUSED, 0),
 	GATE(g2d, "g2d", "aclk200", GATE_IP_DMC, 23, 0, 0),
+	GATE(tmu_apbif, "tmu_apbif", "aclk100", E4X12_GATE_IP_PERIR, 17, 0, 0),
 };
 
 /*
-- 
1.7.9.5



From stigge at antcom.de  Wed Jul 24 06:19:05 2013
From: stigge at antcom.de (Roland Stigge)
Date: Wed, 24 Jul 2013 12:19:05 +0200
Subject: MAX7301 GPIO: Do not force SPI speed when using OF Platform
Message-ID: <51EFAA19.4020905@antcom.de>

Hi,

commit 047b93a35961f7a6561e6f5dcb040738f822b892 introduced the following
to gpio-max7301.c:

	/* bits_per_word cannot be configured in platform data */
-	spi->bits_per_word = 16;
+	if (spi->dev.platform_data)
+		spi->bits_per_word = 16;
 	ret = spi_setup(spi);

Comment is: "The bit_per_word can be set in the OF Device tree, so no
need to force it as with the platform_data when using OF Platform"

Can you please point me to the respective OF option? I couldn't find it
under drivers/spi/spi* or Documentation/devicetree/bindings/spi/*.

Thanks in advance,

Roland


From ben.dooks at codethink.co.uk  Wed Jul 24 06:27:48 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:27:48 +0100
Subject: [repost] ARM big-endian support
Message-ID: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>

A repost (as requested) of the current big-endian core work for review.



From ben.dooks at codethink.co.uk  Wed Jul 24 06:27:51 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:27:51 +0100
Subject: [PATCH 03/14] ARM: fixup_pv_table bug when CPU_ENDIAN_BE8
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374661682-9349-4-git-send-email-ben.dooks@codethink.co.uk>

The fixup_pv_table assumes that the instructions are in the same
endian configuration as the data, but when the CPU is running in
BE8 the instructions stay in little-endian format.

Make sure if CONFIG_CPU_ENDIAN_BE8 is set that we do all the
alterations to the instructions taking in to account the LDR/STR
will be swapping the data endian-ness.

Since the code is only modifying a byte, we avoid dual-swapping
the data, and just change the bits we clear and ORR in (in the
case where the code is not thumb2).

For thumb2, we add the necessary rev16 instructions to ensure that
the instructions are processed in the correct format, as it was
easier than re-writing the code to contain a mask and shift.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/kernel/head.S |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 8bac553..e40c0b3b 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -584,8 +584,10 @@ __fixup_a_pv_table:
 	b	2f
 1:	add     r7, r3
 	ldrh	ip, [r7, #2]
+ARM_BE8(rev16	ip, ip)
 	and	ip, 0x8f00
 	orr	ip, r6	@ mask in offset bits 31-24
+ARM_BE8(rev16	ip, ip)
 	strh	ip, [r7, #2]
 2:	cmp	r4, r5
 	ldrcc	r7, [r4], #4	@ use branch for delay slot
@@ -594,8 +596,14 @@ __fixup_a_pv_table:
 #else
 	b	2f
 1:	ldr	ip, [r7, r3]
+#ifdef CONFIG_CPU_ENDIAN_BE8
+	@ in BE8, we load data in BE, but instructions still in LE
+	bic	ip, ip, #0xff000000
+	orr	ip, ip, r6, lsl#24
+#else
 	bic	ip, ip, #0x000000ff
 	orr	ip, ip, r6	@ mask in offset bits 31-24
+#endif
 	str	ip, [r7, r3]
 2:	cmp	r4, r5
 	ldrcc	r7, [r4], #4	@ use branch for delay slot
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Wed Jul 24 06:27:49 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:27:49 +0100
Subject: [PATCH 01/14] ARM: fix ARCH_IXP4xx usage of ARCH_SUPPORTS_BIG_ENDIAN
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374661682-9349-2-git-send-email-ben.dooks@codethink.co.uk>

The Kconfig for arch/arm/mach-ixp4xx has a local definition
of ARCH_SUPPORTS_BIG_ENDIAN which could be used elsewhere.
This means that if IXP4xx is selected and this symbol is
selected eleswhere then an warning is produced.

Clean the following error up by making the symbol be
selected by the main ARCH_IXP4XX definition and have a
common definition in arch/arm/mm/Kconfig

warning: (ARCH_xxx) selects ARCH_SUPPORTS_BIG_ENDIAN which has unmet direct dependencies (ARCH_IXP4XX)
warning: (ARCH_xxx) selects ARCH_SUPPORTS_BIG_ENDIAN which has unmet direct dependencies (ARCH_IXP4XX)

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/Kconfig             |    1 +
 arch/arm/mach-ixp4xx/Kconfig |    4 ----
 arch/arm/mm/Kconfig          |    6 ++++++
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 136f263..0e60b0e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -474,6 +474,7 @@ config ARCH_IXP4XX
 	bool "IXP4xx-based"
 	depends on MMU
 	select ARCH_HAS_DMA_SET_COHERENT_MASK
+	select ARCH_SUPPORTS_BIG_ENDIAN
 	select ARCH_REQUIRE_GPIOLIB
 	select CLKSRC_MMIO
 	select CPU_XSCALE
diff --git a/arch/arm/mach-ixp4xx/Kconfig b/arch/arm/mach-ixp4xx/Kconfig
index 73a2d90..72de05f 100644
--- a/arch/arm/mach-ixp4xx/Kconfig
+++ b/arch/arm/mach-ixp4xx/Kconfig
@@ -1,9 +1,5 @@
 if ARCH_IXP4XX
 
-config ARCH_SUPPORTS_BIG_ENDIAN
-	bool
-	default y
-
 menu "Intel IXP4xx Implementation Options"
 
 comment "IXP4xx Platforms"
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 35955b5..b83782e 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -895,3 +895,9 @@ config ARCH_HAS_BARRIERS
 	help
 	  This option allows the use of custom mandatory barriers
 	  included via the mach/barriers.h file.
+
+config ARCH_SUPPORTS_BIG_ENDIAN
+	bool
+	help
+	  This option specifies the architecture can support big endian
+	  operation.
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Wed Jul 24 06:27:50 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:27:50 +0100
Subject: [PATCH 02/14] ARM: asm: Add ARM_BE8() assembly helper
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374661682-9349-3-git-send-email-ben.dooks@codethink.co.uk>

Add ARM_BE8() helper to wrap any code conditional on being
compile when CONFIG_ARM_ENDIAN_BE8 is selected and convert
existing places where this is to use it.

Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/boot/compressed/head.S  |    8 ++------
 arch/arm/include/asm/assembler.h |    7 +++++++
 arch/arm/kernel/entry-armv.S     |    5 ++---
 arch/arm/kernel/entry-common.S   |    4 +---
 arch/arm/mm/abort-ev6.S          |    5 ++---
 arch/arm/mm/proc-v6.S            |    4 +---
 arch/arm/mm/proc-v7.S            |    4 +---
 7 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 032a8d9..4eb8364 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -679,9 +679,7 @@ __armv4_mmu_cache_on:
 		mrc	p15, 0, r0, c1, c0, 0	@ read control reg
 		orr	r0, r0, #0x5000		@ I-cache enable, RR cache replacement
 		orr	r0, r0, #0x0030
-#ifdef CONFIG_CPU_ENDIAN_BE8
-		orr	r0, r0, #1 << 25	@ big-endian page tables
-#endif
+ ARM_BE8(	orr	r0, r0, #1 << 25 )	@ big-endian page tables
 		bl	__common_mmu_cache_on
 		mov	r0, #0
 		mcr	p15, 0, r0, c8, c7, 0	@ flush I,D TLBs
@@ -708,9 +706,7 @@ __armv7_mmu_cache_on:
 		orr	r0, r0, #1 << 22	@ U (v6 unaligned access model)
 						@ (needed for ARM1176)
 #ifdef CONFIG_MMU
-#ifdef CONFIG_CPU_ENDIAN_BE8
-		orr	r0, r0, #1 << 25	@ big-endian page tables
-#endif
+ ARM_BE8(	orr	r0, r0, #1 << 25 )	@ big-endian page tables
 		mrcne   p15, 0, r6, c2, c0, 2   @ read ttb control reg
 		orrne	r0, r0, #1		@ MMU enabled
 		movne	r1, #0xfffffffd		@ domain 0 = client
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 05ee9ee..e780afb 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -53,6 +53,13 @@
 #define put_byte_3      lsl #0
 #endif
 
+/* Select code for any configuration running in BE8 mode */
+#ifdef CONFIG_CPU_ENDIAN_BE8
+#define ARM_BE8(code...) code
+#else
+#define ARM_BE8(code...)
+#endif
+
 /*
  * Data preload for architectures that support it
  */
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 582b405..09130e2 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -415,9 +415,8 @@ __und_usr:
 	bne	__und_usr_thumb
 	sub	r4, r2, #4			@ ARM instr at LR - 4
 1:	ldrt	r0, [r4]
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	rev	r0, r0				@ little endian instruction
-#endif
+ ARM_BE8(rev	r0, r0)				@ little endian instruction
+
 	@ r0 = 32-bit ARM instruction which caused the exception
 	@ r2 = PC value for the following instruction (:= regs->ARM_pc)
 	@ r4 = PC value for the faulting instruction
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index bc5bc0a..8c79344 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -379,9 +379,7 @@ ENTRY(vector_swi)
 #else
 	ldr	r10, [lr, #-4]			@ get SWI instruction
 #endif
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	rev	r10, r10			@ little endian instruction
-#endif
+ ARM_BE8(rev	r10, r10)			@ little endian instruction
 
 #elif defined(CONFIG_AEABI)
 
diff --git a/arch/arm/mm/abort-ev6.S b/arch/arm/mm/abort-ev6.S
index 8074199..3815a82 100644
--- a/arch/arm/mm/abort-ev6.S
+++ b/arch/arm/mm/abort-ev6.S
@@ -38,9 +38,8 @@ ENTRY(v6_early_abort)
 	bne	do_DataAbort
 	bic	r1, r1, #1 << 11		@ clear bit 11 of FSR
 	ldr	r3, [r4]			@ read aborted ARM instruction
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	rev	r3, r3
-#endif
+ ARM_BE8(rev	r3, r3)
+
 	do_ldrd_abort tmp=ip, insn=r3
 	tst	r3, #1 << 20			@ L = 0 -> write
 	orreq	r1, r1, #1 << 11		@ yes.
diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
index 919405e..f2e43e8 100644
--- a/arch/arm/mm/proc-v6.S
+++ b/arch/arm/mm/proc-v6.S
@@ -218,9 +218,7 @@ __v6_setup:
 #endif /* CONFIG_MMU */
 	adr	r5, v6_crval
 	ldmia	r5, {r5, r6}
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	orr	r6, r6, #1 << 25		@ big-endian page tables
-#endif
+ ARM_BE8(orr	r6, r6, #1 << 25)		@ big-endian page tables
 	mrc	p15, 0, r0, c1, c0, 0		@ read control register
 	bic	r0, r0, r5			@ clear bits them
 	orr	r0, r0, r6			@ set them
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index e35fec3..8338ba4 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -351,9 +351,7 @@ __v7_setup:
 #endif
 	adr	r5, v7_crval
 	ldmia	r5, {r5, r6}
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	orr	r6, r6, #1 << 25		@ big-endian page tables
-#endif
+ ARM_BE8(orr	r6, r6, #1 << 25)		@ big-endian page tables
 #ifdef CONFIG_SWP_EMULATE
 	orr     r5, r5, #(1 << 10)              @ set SW bit in "clear"
 	bic     r6, r6, #(1 << 10)              @ clear it in "mmuset"
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Wed Jul 24 06:27:56 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:27:56 +0100
Subject: [PATCH 08/14] highbank: enable big-endian
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374661682-9349-9-git-send-email-ben.dooks@codethink.co.uk>

Apart from a xgmac driver issue, the highbank seems to work correctly in
big-endian mode. Allow the selection of big-endian in the system.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/mach-highbank/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
index cd9fcb1..4f57554 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -18,3 +18,4 @@ config ARCH_HIGHBANK
 	select PL320_MBOX
 	select SPARSE_IRQ
 	select USE_OF
+	select ARCH_SUPPORTS_BIG_ENDIAN
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Wed Jul 24 06:27:53 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:27:53 +0100
Subject: [PATCH 05/14] ARM: pl01x debug code endian fix
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374661682-9349-6-git-send-email-ben.dooks@codethink.co.uk>

The PL01X debug code needs to take into account which endian mode the
processor is running in. If it is big-endian, ensure the data is swapped
appropriately.

Note, we could do this slightly more efficiently if we have an macro to
do the necessary swap for the bits used by test.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/include/asm/hardware/debug-pl01x.S |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/hardware/debug-pl01x.S b/arch/arm/include/asm/hardware/debug-pl01x.S
index f9fd083..6489d1f 100644
--- a/arch/arm/include/asm/hardware/debug-pl01x.S
+++ b/arch/arm/include/asm/hardware/debug-pl01x.S
@@ -18,12 +18,14 @@
 
 		.macro	waituart,rd,rx
 1001:		ldr	\rd, [\rx, #UART01x_FR]
+ ARM_BE8(	rev	\rd, \rd )
 		tst	\rd, #UART01x_FR_TXFF
 		bne	1001b
 		.endm
 
 		.macro	busyuart,rd,rx
 1001:		ldr	\rd, [\rx, #UART01x_FR]
+ ARM_BE8(	rev	\rd, \rd )
 		tst	\rd, #UART01x_FR_BUSY
 		bne	1001b
 		.endm
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Wed Jul 24 06:27:52 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:27:52 +0100
Subject: [PATCH 04/14] ARM: set BE8 if LE in head code
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374661682-9349-5-git-send-email-ben.dooks@codethink.co.uk>

If we are booting in LE and compiled for BE8, then add code to
set the state to bE8. Since the instruction stream is always LE,
we do not need to do anything special to the instruction.

Also ensure that the secondary processors are started in the same mode.

Note, we do add about 20 bytes to the kernel image, but it seems easier
to do this than adding another configuration to change.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/boot/compressed/head.S |    1 +
 arch/arm/kernel/head.S          |    4 ++++
 arch/arm/kernel/sleep.S         |    1 +
 3 files changed, 6 insertions(+)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 4eb8364..4d83bfd 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -135,6 +135,7 @@ start:
 		.word	_edata			@ zImage end address
  THUMB(		.thumb			)
 1:
+ ARM_BE8(	setend	be )			@ go BE8 if LE, no-op if BE8
 		mrs	r9, cpsr
 #ifdef CONFIG_ARM_VIRT_EXT
 		bl	__hyp_stub_install	@ get into SVC mode, reversibly
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index e40c0b3b..706c441 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -77,6 +77,7 @@
 
 	__HEAD
 ENTRY(stext)
+ ARM_BE8(setend	be )			@ ensure we are in BE8 mode
 
  THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is always entered in ARM.
  THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
@@ -351,6 +352,9 @@ ENTRY(secondary_startup)
 	 * the processor type - there is no need to check the machine type
 	 * as it has already been validated by the primary processor.
 	 */
+
+ ARM_BE8(setend	be)				@ if system starts LE, go BE8
+
 #ifdef CONFIG_ARM_VIRT_EXT
 	bl	__hyp_stub_install_secondary
 #endif
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 987dcf3..954c28a 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -81,6 +81,7 @@ ENDPROC(cpu_resume_after_mmu)
 	.data
 	.align
 ENTRY(cpu_resume)
+ARM_BE8(setend be)			@ ensure we are in BE mode
 #ifdef CONFIG_SMP
 	adr	r0, sleep_save_sp
 	ALT_SMP(mrc p15, 0, r1, c0, c0, 5)
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Wed Jul 24 06:27:55 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:27:55 +0100
Subject: [PATCH 07/14] ARM: smp_scu: data endian fixes
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374661682-9349-8-git-send-email-ben.dooks@codethink.co.uk>

The smp_scu driver needs to use the relaxed readl/write accessors
to avoid any issues with the endian mode the processor core is in.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/kernel/smp_scu.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
index 5bc1a63..1aafa0d 100644
--- a/arch/arm/kernel/smp_scu.c
+++ b/arch/arm/kernel/smp_scu.c
@@ -28,7 +28,7 @@
  */
 unsigned int __init scu_get_core_count(void __iomem *scu_base)
 {
-	unsigned int ncores = __raw_readl(scu_base + SCU_CONFIG);
+	unsigned int ncores = readl_relaxed(scu_base + SCU_CONFIG);
 	return (ncores & 0x03) + 1;
 }
 
@@ -42,19 +42,19 @@ void scu_enable(void __iomem *scu_base)
 #ifdef CONFIG_ARM_ERRATA_764369
 	/* Cortex-A9 only */
 	if ((read_cpuid_id() & 0xff0ffff0) == 0x410fc090) {
-		scu_ctrl = __raw_readl(scu_base + 0x30);
+		scu_ctrl = readl_relaxed(scu_base + 0x30);
 		if (!(scu_ctrl & 1))
-			__raw_writel(scu_ctrl | 0x1, scu_base + 0x30);
+			writel_relaxed(scu_ctrl | 0x1, scu_base + 0x30);
 	}
 #endif
 
-	scu_ctrl = __raw_readl(scu_base + SCU_CTRL);
+	scu_ctrl = readl_relaxed(scu_base + SCU_CTRL);
 	/* already enabled? */
 	if (scu_ctrl & 1)
 		return;
 
 	scu_ctrl |= 1;
-	__raw_writel(scu_ctrl, scu_base + SCU_CTRL);
+	writel_relaxed(scu_ctrl, scu_base + SCU_CTRL);
 
 	/*
 	 * Ensure that the data accessed by CPU0 before the SCU was
@@ -80,9 +80,9 @@ int scu_power_mode(void __iomem *scu_base, unsigned int mode)
 	if (mode > 3 || mode == 1 || cpu > 3)
 		return -EINVAL;
 
-	val = __raw_readb(scu_base + SCU_CPU_STATUS + cpu) & ~0x03;
+	val = readb_relaxed(scu_base + SCU_CPU_STATUS + cpu) & ~0x03;
 	val |= mode;
-	__raw_writeb(val, scu_base + SCU_CPU_STATUS + cpu);
+	writeb_relaxed(val, scu_base + SCU_CPU_STATUS + cpu);
 
 	return 0;
 }
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Wed Jul 24 06:27:54 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:27:54 +0100
Subject: [PATCH 06/14] ARM: twd: data endian fix
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374661682-9349-7-git-send-email-ben.dooks@codethink.co.uk>

Ensure the twd driver uses the correct calls to access the hardware
to ensure that we do not end up with data in the wrong endian format.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/kernel/smp_twd.c |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 90525d9..804d3f8 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -45,7 +45,7 @@ static void twd_set_mode(enum clock_event_mode mode,
 	case CLOCK_EVT_MODE_PERIODIC:
 		ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE
 			| TWD_TIMER_CONTROL_PERIODIC;
-		__raw_writel(DIV_ROUND_CLOSEST(twd_timer_rate, HZ),
+		writel_relaxed(DIV_ROUND_CLOSEST(twd_timer_rate, HZ),
 			twd_base + TWD_TIMER_LOAD);
 		break;
 	case CLOCK_EVT_MODE_ONESHOT:
@@ -58,18 +58,18 @@ static void twd_set_mode(enum clock_event_mode mode,
 		ctrl = 0;
 	}
 
-	__raw_writel(ctrl, twd_base + TWD_TIMER_CONTROL);
+	writel_relaxed(ctrl, twd_base + TWD_TIMER_CONTROL);
 }
 
 static int twd_set_next_event(unsigned long evt,
 			struct clock_event_device *unused)
 {
-	unsigned long ctrl = __raw_readl(twd_base + TWD_TIMER_CONTROL);
+	unsigned long ctrl = readl_relaxed(twd_base + TWD_TIMER_CONTROL);
 
 	ctrl |= TWD_TIMER_CONTROL_ENABLE;
 
-	__raw_writel(evt, twd_base + TWD_TIMER_COUNTER);
-	__raw_writel(ctrl, twd_base + TWD_TIMER_CONTROL);
+	writel_relaxed(evt, twd_base + TWD_TIMER_COUNTER);
+	writel_relaxed(ctrl, twd_base + TWD_TIMER_CONTROL);
 
 	return 0;
 }
@@ -82,8 +82,8 @@ static int twd_set_next_event(unsigned long evt,
  */
 static int twd_timer_ack(void)
 {
-	if (__raw_readl(twd_base + TWD_TIMER_INTSTAT)) {
-		__raw_writel(1, twd_base + TWD_TIMER_INTSTAT);
+	if (readl_relaxed(twd_base + TWD_TIMER_INTSTAT)) {
+		writel_relaxed(1, twd_base + TWD_TIMER_INTSTAT);
 		return 1;
 	}
 
@@ -209,15 +209,15 @@ static void __cpuinit twd_calibrate_rate(void)
 		waitjiffies += 5;
 
 				 /* enable, no interrupt or reload */
-		__raw_writel(0x1, twd_base + TWD_TIMER_CONTROL);
+		writel_relaxed(0x1, twd_base + TWD_TIMER_CONTROL);
 
 				 /* maximum value */
-		__raw_writel(0xFFFFFFFFU, twd_base + TWD_TIMER_COUNTER);
+		writel_relaxed(0xFFFFFFFFU, twd_base + TWD_TIMER_COUNTER);
 
 		while (get_jiffies_64() < waitjiffies)
 			udelay(10);
 
-		count = __raw_readl(twd_base + TWD_TIMER_COUNTER);
+		count = readl_relaxed(twd_base + TWD_TIMER_COUNTER);
 
 		twd_timer_rate = (0xFFFFFFFFU - count) * (HZ / 5);
 
@@ -275,7 +275,7 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
 	 * bother with the below.
 	 */
 	if (per_cpu(percpu_setup_called, cpu)) {
-		__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
+		writel_relaxed(0, twd_base + TWD_TIMER_CONTROL);
 		clockevents_register_device(*__this_cpu_ptr(twd_evt));
 		enable_percpu_irq(clk->irq, 0);
 		return 0;
@@ -288,7 +288,7 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
 	 * The following is done once per CPU the first time .setup() is
 	 * called.
 	 */
-	__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
+	writel_relaxed(0, twd_base + TWD_TIMER_CONTROL);
 
 	clk->name = "local_timer";
 	clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT |
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Wed Jul 24 06:27:58 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:27:58 +0100
Subject: [PATCH 10/14] vexpress: add big endian support
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374661682-9349-11-git-send-email-ben.dooks@codethink.co.uk>

Add support for the versatile express systems to boot big-endian.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/mach-vexpress/Kconfig    |    1 +
 arch/arm/plat-versatile/headsmp.S |    2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 5907e10..fa69d4e 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -1,6 +1,7 @@
 config ARCH_VEXPRESS
 	bool "ARM Ltd. Versatile Express family" if ARCH_MULTI_V7
 	select ARCH_REQUIRE_GPIOLIB
+	select ARCH_SUPPORTS_BIG_ENDIAN
 	select ARM_AMBA
 	select ARM_GIC
 	select ARM_TIMER_SP804
diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S
index b178d44..4c5c8ca 100644
--- a/arch/arm/plat-versatile/headsmp.S
+++ b/arch/arm/plat-versatile/headsmp.S
@@ -10,6 +10,7 @@
  */
 #include <linux/linkage.h>
 #include <linux/init.h>
+#include <asm/assembler.h>
 
 	__INIT
 
@@ -19,6 +20,7 @@
  * until we're ready for them to initialise.
  */
 ENTRY(versatile_secondary_startup)
+ ARM_BE8(setend	be)
 	mrc	p15, 0, r0, c0, c0, 5
 	bic	r0, #0xff000000
 	adr	r4, 1f
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Wed Jul 24 06:28:02 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:28:02 +0100
Subject: [PATCH 14/14] ARM: set --be8 when linking modules
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374661682-9349-15-git-send-email-ben.dooks@codethink.co.uk>

To avoid having to make every text section swap the instruction order
of all instructions, make sure modules are built also built with --be8
(as is the current kernel final link).

If we do not do this, we would end up having to swap all instructions
when loading a module, instead of just the instructions that we are
applying ELF relocations to.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/Makefile |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 1ba358b..70bc19e 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -16,6 +16,7 @@ LDFLAGS		:=
 LDFLAGS_vmlinux	:=-p --no-undefined -X
 ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
 LDFLAGS_vmlinux	+= --be8
+LDFLAGS_MODULE	+= --be8
 endif
 
 OBJCOPYFLAGS	:=-O binary -R .comment -S
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Wed Jul 24 06:28:01 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:28:01 +0100
Subject: [PATCH 13/14] ARM: module: correctly relocate instructions in BE8
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374661682-9349-14-git-send-email-ben.dooks@codethink.co.uk>

When in BE8 mode, our instructions are not in the same ordering as the
data, so use <asm/opcodes.h> to take this into account.

Note, also requires modules to be built --be8

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/kernel/module.c |   57 +++++++++++++++++++++++++++-------------------
 1 file changed, 34 insertions(+), 23 deletions(-)

diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 1e9be5d..7e13787 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -24,6 +24,7 @@
 #include <asm/sections.h>
 #include <asm/smp_plat.h>
 #include <asm/unwind.h>
+#include <asm/opcodes.h>
 
 #ifdef CONFIG_XIP_KERNEL
 /*
@@ -60,6 +61,7 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 		Elf32_Sym *sym;
 		const char *symname;
 		s32 offset;
+		u32 tmp;
 #ifdef CONFIG_THUMB2_KERNEL
 		u32 upper, lower, sign, j1, j2;
 #endif
@@ -95,7 +97,8 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 		case R_ARM_PC24:
 		case R_ARM_CALL:
 		case R_ARM_JUMP24:
-			offset = (*(u32 *)loc & 0x00ffffff) << 2;
+			offset = __mem_to_opcode_arm(*(u32 *)loc);
+			offset = (offset & 0x00ffffff) << 2;
 			if (offset & 0x02000000)
 				offset -= 0x04000000;
 
@@ -111,9 +114,10 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 			}
 
 			offset >>= 2;
+			offset &= 0x00ffffff;
 
-			*(u32 *)loc &= 0xff000000;
-			*(u32 *)loc |= offset & 0x00ffffff;
+			*(u32 *)loc &= __opcode_to_mem_arm(0xff000000);
+			*(u32 *)loc |= __opcode_to_mem_arm(offset);
 			break;
 
 	       case R_ARM_V4BX:
@@ -121,8 +125,8 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 			* other bits to re-code instruction as
 			* MOV PC,Rm.
 			*/
-		       *(u32 *)loc &= 0xf000000f;
-		       *(u32 *)loc |= 0x01a0f000;
+		       *(u32 *)loc &= __opcode_to_mem_arm(0xf000000f);
+		       *(u32 *)loc |= __opcode_to_mem_arm(0x01a0f000);
 		       break;
 
 		case R_ARM_PREL31:
@@ -132,7 +136,7 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 
 		case R_ARM_MOVW_ABS_NC:
 		case R_ARM_MOVT_ABS:
-			offset = *(u32 *)loc;
+			offset = tmp = __mem_to_opcode_arm(*(u32 *)loc);
 			offset = ((offset & 0xf0000) >> 4) | (offset & 0xfff);
 			offset = (offset ^ 0x8000) - 0x8000;
 
@@ -140,16 +144,18 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 			if (ELF32_R_TYPE(rel->r_info) == R_ARM_MOVT_ABS)
 				offset >>= 16;
 
-			*(u32 *)loc &= 0xfff0f000;
-			*(u32 *)loc |= ((offset & 0xf000) << 4) |
-					(offset & 0x0fff);
+			tmp &= 0xfff0f000;
+			tmp |= ((offset & 0xf000) << 4) |
+				(offset & 0x0fff);
+
+			*(u32 *)loc = __opcode_to_mem_arm(tmp);
 			break;
 
 #ifdef CONFIG_THUMB2_KERNEL
 		case R_ARM_THM_CALL:
 		case R_ARM_THM_JUMP24:
-			upper = *(u16 *)loc;
-			lower = *(u16 *)(loc + 2);
+			upper = __mem_to_opcode_thumb16(*(u16 *)loc);
+			lower = __mem_to_opcode_thumb16(*(u16 *)(loc + 2));
 
 			/*
 			 * 25 bit signed address range (Thumb-2 BL and B.W
@@ -198,17 +204,20 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 			sign = (offset >> 24) & 1;
 			j1 = sign ^ (~(offset >> 23) & 1);
 			j2 = sign ^ (~(offset >> 22) & 1);
-			*(u16 *)loc = (u16)((upper & 0xf800) | (sign << 10) |
+			upper = (u16)((upper & 0xf800) | (sign << 10) |
 					    ((offset >> 12) & 0x03ff));
-			*(u16 *)(loc + 2) = (u16)((lower & 0xd000) |
-						  (j1 << 13) | (j2 << 11) |
-						  ((offset >> 1) & 0x07ff));
+			lower = (u16)((lower & 0xd000) |
+				      (j1 << 13) | (j2 << 11) |
+				      ((offset >> 1) & 0x07ff));
+
+			*(u16 *)loc = __opcode_to_mem_thumb16(upper);
+			*(u16 *)(loc + 2) = __opcode_to_mem_thumb16(lower);
 			break;
 
 		case R_ARM_THM_MOVW_ABS_NC:
 		case R_ARM_THM_MOVT_ABS:
-			upper = *(u16 *)loc;
-			lower = *(u16 *)(loc + 2);
+			upper = __mem_to_opcode_thumb16(*(u16 *)loc);
+			lower = __mem_to_opcode_thumb16(*(u16 *)(loc + 2));
 
 			/*
 			 * MOVT/MOVW instructions encoding in Thumb-2:
@@ -229,12 +238,14 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
 			if (ELF32_R_TYPE(rel->r_info) == R_ARM_THM_MOVT_ABS)
 				offset >>= 16;
 
-			*(u16 *)loc = (u16)((upper & 0xfbf0) |
-					    ((offset & 0xf000) >> 12) |
-					    ((offset & 0x0800) >> 1));
-			*(u16 *)(loc + 2) = (u16)((lower & 0x8f00) |
-						  ((offset & 0x0700) << 4) |
-						  (offset & 0x00ff));
+			upper = (u16)((upper & 0xfbf0) |
+				      ((offset & 0xf000) >> 12) |
+				      ((offset & 0x0800) >> 1));
+			lower = (u16)((lower & 0x8f00) |
+				      ((offset & 0x0700) << 4) |
+				      (offset & 0x00ff));
+			*(u16 *)loc = __opcode_to_mem_thumb16(upper);
+			*(u16 *)(loc + 2) = __opcode_to_mem_thumb16(lower);
 			break;
 #endif
 
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Wed Jul 24 06:27:57 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:27:57 +0100
Subject: [PATCH 09/14] mvebu: support running big-endian
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374661682-9349-10-git-send-email-ben.dooks@codethink.co.uk>

Add indication we can run these cores in BE mode, and ensure that the
secondary CPU is set to big-endian mode in the initialisation code as
the initial code runs little-endian.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/mach-mvebu/Kconfig        |    1 +
 arch/arm/mach-mvebu/coherency_ll.S |    3 +++
 arch/arm/mach-mvebu/headsmp.S      |    4 ++++
 3 files changed, 8 insertions(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 80a8bca..317cdb8 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -1,5 +1,6 @@
 config ARCH_MVEBU
 	bool "Marvell SOCs with Device Tree support" if ARCH_MULTI_V7
+	select ARCH_SUPPORTS_BIG_ENDIAN
 	select CLKSRC_MMIO
 	select COMMON_CLK
 	select GENERIC_CLOCKEVENTS
diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
index 5476669..ee7598f 100644
--- a/arch/arm/mach-mvebu/coherency_ll.S
+++ b/arch/arm/mach-mvebu/coherency_ll.S
@@ -20,6 +20,8 @@
 #define ARMADA_XP_CFB_CTL_REG_OFFSET 0x0
 #define ARMADA_XP_CFB_CFG_REG_OFFSET 0x4
 
+#include <asm/assembler.h>
+
 	.text
 /*
  * r0: Coherency fabric base register address
@@ -29,6 +31,7 @@ ENTRY(ll_set_cpu_coherent)
 	/* Create bit by cpu index */
 	mov	r3, #(1 << 24)
 	lsl	r1, r3, r1
+ARM_BE8(rev	r1, r1)
 
 	/* Add CPU to SMP group - Atomic */
 	add	r3, r0, #ARMADA_XP_CFB_CTL_REG_OFFSET
diff --git a/arch/arm/mach-mvebu/headsmp.S b/arch/arm/mach-mvebu/headsmp.S
index a06e0ed..a4f995d 100644
--- a/arch/arm/mach-mvebu/headsmp.S
+++ b/arch/arm/mach-mvebu/headsmp.S
@@ -21,6 +21,8 @@
 #include <linux/linkage.h>
 #include <linux/init.h>
 
+#include <asm/assembler.h>
+
 /*
  * At this stage the secondary CPUs don't have acces yet to the MMU, so
  * we have to provide physical addresses
@@ -36,6 +38,8 @@
  */
 ENTRY(armada_xp_secondary_startup)
 
+ ARM_BE8(setend	be )			@ go BE8 if booted LE
+
 	/* Read CPU id */
 	mrc     p15, 0, r1, c0, c0, 5
 	and     r1, r1, #0xF
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Wed Jul 24 06:27:59 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:27:59 +0100
Subject: [PATCH 11/14] ARM: alignment: correctly decode instructions in BE8
 mode.
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374661682-9349-12-git-send-email-ben.dooks@codethink.co.uk>

If we are in BE8 mode, we must deal with the instruction stream being
in LE order when data is being loaded in BE order. Ensure the data is
swapped before processing to avoid thre following:

Change to using <asm/opcodes.h> to provide the necessary conversion
functions to change the byte ordering.

Alignment trap: not handling instruction 030091e8 at [<80333e8c>]
Unhandled fault: alignment exception (0x001) at 0xbfa09567

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/mm/alignment.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index 6f4585b..f38145a 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -25,6 +25,7 @@
 #include <asm/cp15.h>
 #include <asm/system_info.h>
 #include <asm/unaligned.h>
+#include <asm/opcodes.h>
 
 #include "fault.h"
 
@@ -762,21 +763,24 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
 	if (thumb_mode(regs)) {
 		u16 *ptr = (u16 *)(instrptr & ~1);
 		fault = probe_kernel_address(ptr, tinstr);
+		tinstr = __mem_to_opcode_thumb16(tinstr);
 		if (!fault) {
 			if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
 			    IS_T32(tinstr)) {
 				/* Thumb-2 32-bit */
 				u16 tinst2 = 0;
 				fault = probe_kernel_address(ptr + 1, tinst2);
+				tinst2 = __mem_to_opcode_thumb16(tinst2);
 				instr = (tinstr << 16) | tinst2;
 				thumb2_32b = 1;
 			} else {
 				isize = 2;
-				instr = thumb2arm(tinstr);
 			}
 		}
-	} else
+	} else {
 		fault = probe_kernel_address(instrptr, instr);
+		instr = __mem_to_opcode_arm(instr);
+	}
 
 	if (fault) {
 		type = TYPE_FAULT;
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Wed Jul 24 06:28:00 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:28:00 +0100
Subject: [PATCH 12/14] ARM: traps: use <asm/opcodes.h> to get correct
 instruction order
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374661682-9349-13-git-send-email-ben.dooks@codethink.co.uk>

The trap handler needs to take into account the endian configuration of
the system when loading instructions. Use <asm/opcodes.h> to provide the
necessary conversion functions.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/kernel/traps.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 18b32e8..c300e51 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -34,6 +34,7 @@
 #include <asm/unwind.h>
 #include <asm/tls.h>
 #include <asm/system_misc.h>
+#include <asm/opcodes.h>
 
 #include "signal.h"
 
@@ -404,23 +405,24 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
 	if (processor_mode(regs) == SVC_MODE) {
 #ifdef CONFIG_THUMB2_KERNEL
 		if (thumb_mode(regs)) {
-			instr = ((u16 *)pc)[0];
+			instr = __mem_to_opcode_thumb16(((u16 *)pc)[0]);
 			if (is_wide_instruction(instr)) {
 				instr <<= 16;
-				instr |= ((u16 *)pc)[1];
+				instr |= __mem_to_opcode_thumb16(((u16 *)pc)[1]);
 			}
 		} else
 #endif
-			instr = *(u32 *) pc;
+			instr = __mem_to_opcode_arm(*(u32 *) pc);
 	} else if (thumb_mode(regs)) {
 		if (get_user(instr, (u16 __user *)pc))
 			goto die_sig;
+		instr = __mem_to_opcode_thumb16(instr);
 		if (is_wide_instruction(instr)) {
 			unsigned int instr2;
 			if (get_user(instr2, (u16 __user *)pc+1))
 				goto die_sig;
 			instr <<= 16;
-			instr |= instr2;
+			instr |= __mem_to_opcode_thumb16(instr2);
 		}
 	} else if (get_user(instr, (u32 __user *)pc)) {
 		goto die_sig;
-- 
1.7.10.4



From will.deacon at arm.com  Wed Jul 24 06:42:19 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 11:42:19 +0100
Subject: [PATCH 3/6] ARM: prefetch: add support for prefetchw using pldw
 on SMP ARMv7+ CPUs
In-Reply-To: <alpine.LFD.2.03.1307231559120.15022@syhkavp.arg>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-4-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231559120.15022@syhkavp.arg>
Message-ID: <20130724104218.GB11072@mudshark.cambridge.arm.com>

On Tue, Jul 23, 2013 at 09:05:58PM +0100, Nicolas Pitre wrote:
> On Tue, 23 Jul 2013, Will Deacon wrote:
> 
> > SMP ARMv7 CPUs implement the pldw instruction, which allows them to
> > prefetch data cachelines in an exclusive state.
> > 
> > This patch defines the prefetchw macro using pldw for CPUs that support
> > it.
> > 
> > Signed-off-by: Will Deacon <will.deacon at arm.com>
> 
> Minor nit below.  Otherwise:
> 
> Acked-by: Nicolas Pitre <nico at linaro.org>
> 
> > ---
> >  arch/arm/include/asm/processor.h | 17 ++++++++++++-----
> >  1 file changed, 12 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
> > index cbdb130..d571697 100644
> > --- a/arch/arm/include/asm/processor.h
> > +++ b/arch/arm/include/asm/processor.h
> > @@ -116,12 +116,19 @@ static inline void prefetch(const void *ptr)
> >  		:: "p" (ptr));
> >  }
> >  
> > +#if __LINUX_ARM_ARCH__ >= 7 && defined(CONFIG_SMP)
> >  #define ARCH_HAS_PREFETCHW
> > -#define prefetchw(ptr)	prefetch(ptr)
> > -
> > -#define ARCH_HAS_SPINLOCK_PREFETCH
> > -#define spin_lock_prefetch(x) do { } while (0)
> > -
> 
> What about keeping the above definitions when __LINUX_ARM_ARCH__ >= 7
> && defined(CONFIG_SMP) is not true?

In the case that we don't have prefetchw, then spin_lock_prefetch would end
up being defined as __builtin_prefetch(x,1) by linux/prefetch.h. GCC will
almost certainly spit out `pld' for that (it currently ignores the second
argument...), which should be better than doing nothing. The cacheline may not
be in the ideal state (shared rather than exclusive), but at least it's likely
to be in the cache rather than sitting out in memory.

Unfortunately, spin_lock_prefetch is only used in one place, so changes to
its implementation don't have any measurable difference on kernel
performance.

> > +static inline void prefetchw(const void *ptr)
> > +{
> > +	__asm__ __volatile__(
> > +		".arch_extension	mp\n"
> > +	__ALT_SMP_ASM(
> > +		WASM(pldw)		"\t%a0",
> > +		WASM(pld)		"\t%a0"
> > +	)
> 
> The paren indentation looks odd.  If you shift the whole __ALT_SMP_ASM 
> block right then it is also less likely to look like a sequential 
> execution of pldw followed by pld to the casual reader.

Sure, I'll fix that up.

Thanks again for your feedback,

Will


From s.nawrocki at samsung.com  Wed Jul 24 06:44:51 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 12:44:51 +0200
Subject: [PATCH v4 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <1374655405-22998-1-git-send-email-sachin.kamat@linaro.org>
References: <1374655405-22998-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <51EFB023.6090804@samsung.com>

Hi Sachin,

On 07/24/2013 10:43 AM, Sachin Kamat wrote:
> With the recent cleanup in Exynos platform code notably commits
> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
> more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
> Exynos4412 which have more than the default number of GPIOs. Thus define
> this number in KConfig file which takes care of current SoC requirements
> and provides scope for GPIO expanders. Without this patch we get the
> following errors during boot:
> 
> gpiochip_add: gpios 251..258 (gpv0) failed to register
> samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
> error code: -22
> samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
> 
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> Cc: Tomasz Figa <t.figa at samsung.com>
> ---
> Changes since v3:
> Rearranged different default values in single line.
> ---
>  arch/arm/Kconfig |    3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f8fb910..ac9fa38 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1590,8 +1590,7 @@ config ARM_PSCI
>  config ARCH_NR_GPIO
>  	int
>  	default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
> -	default 512 if SOC_OMAP5
> -	default 512 if ARCH_KEYSTONE
> +	default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5

Sorry, 512 seems a bit too generous to me. Also I would rather
leave each SOC/ARCH on a separate line.

Almost half of those 512 entries would have been unused in most
cases. How about, e.g. 352 ? If anyone finds this value too low
they could always submit a patch like this one. IMHO with 352 or
392 there would be sufficient margin.

--
Regards,
Sylwester


From ben.dooks at codethink.co.uk  Wed Jul 24 06:46:44 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 11:46:44 +0100
Subject: updates for be8 patch series
In-Reply-To: <CAA3XUr31LAJ3+iWq5gXb+JZO-1G96waOFy-RBVZQEW-djj3dYA@mail.gmail.com>
References: <CAA3XUr3h5C0oJVrN5iXsM=NFkLMz_Tssp28CysZfwMNS5KvO-Q@mail.gmail.com>
 <51EEC002.9070808@codethink.co.uk>
 <CAA3XUr2oDEDD6LFjnZ_N0JGTFUMDZG6O9b3JoeJ8AELrK2KDiw@mail.gmail.com>
 <CAA3XUr1BJD-ypfJiEsp079qHDERjGp-xFxc_ke_Ep9z3N=UPaA@mail.gmail.com>
 <51EECBBD.20000@codethink.co.uk>
 <CAA3XUr31LAJ3+iWq5gXb+JZO-1G96waOFy-RBVZQEW-djj3dYA@mail.gmail.com>
Message-ID: <51EFB094.3050002@codethink.co.uk>

On 24/07/13 02:06, Victor Kamensky wrote:
> Hi Ben,
>
> Let me split off atomic64 from other issues, so we have focused topic here.
>
> Please see atomic64 issue test case below. Please try it in your setup. I've
> run on Pandaboard ES with my set of patches, but I believe it should be the
> same in your case.
>
> <snip>
>
>>> Index: linux-linaro-tracking/arch/arm/include/asm/atomic.h
>>> ===================================================================
>>> --- linux-linaro-tracking.orig/arch/arm/include/asm/atomic.h
>>> +++ linux-linaro-tracking/arch/arm/include/asm/atomic.h
>>> @@ -301,8 +301,13 @@ static inline void atomic64_add(u64 i, a
>>>
>>>        __asm__ __volatile__("@ atomic64_add\n"
>>>    "1:    ldrexd    %0, %H0, [%3]\n"
>>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>>    "    adds    %0, %0, %4\n"
>>>    "    adc    %H0, %H0, %H4\n"
>>> +#else
>>> +"    adds    %H0, %H0, %H4\n"
>>> +"    adc    %0, %0, %4\n"
>>> +#endif
>>>    "    strexd    %1, %0, %H0, [%3]\n"
>>>    "    teq    %1, #0\n"
>>>    "    bne    1b"
>>> @@ -320,8 +325,13 @@ static inline u64 atomic64_add_return(u6
>>>
>>>        __asm__ __volatile__("@ atomic64_add_return\n"
>>>    "1:    ldrexd    %0, %H0, [%3]\n"
>>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>>    "    adds    %0, %0, %4\n"
>>>    "    adc    %H0, %H0, %H4\n"
>>> +#else
>>> +"    adds    %H0, %H0, %H4\n"
>>> +"    adc    %0, %0, %4\n"
>>> +#endif
>>>    "    strexd    %1, %0, %H0, [%3]\n"
>>>    "    teq    %1, #0\n"
>>>    "    bne    1b"
>>> @@ -341,8 +351,13 @@ static inline void atomic64_sub(u64 i, a
>>>
>>>        __asm__ __volatile__("@ atomic64_sub\n"
>>>    "1:    ldrexd    %0, %H0, [%3]\n"
>>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>>    "    subs    %0, %0, %4\n"
>>>    "    sbc    %H0, %H0, %H4\n"
>>> +#else
>>> +"    subs    %H0, %H0, %H4\n"
>>> +"    sbc    %0, %0, %4\n"
>>> +#endif
>>>    "    strexd    %1, %0, %H0, [%3]\n"
>>>    "    teq    %1, #0\n"
>>>    "    bne    1b"
>>> @@ -360,8 +375,13 @@ static inline u64 atomic64_sub_return(u6
>>>
>>>        __asm__ __volatile__("@ atomic64_sub_return\n"
>>>    "1:    ldrexd    %0, %H0, [%3]\n"
>>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>>    "    subs    %0, %0, %4\n"
>>>    "    sbc    %H0, %H0, %H4\n"
>>> +#else
>>> +"    subs    %H0, %H0, %H4\n"
>>> +"    sbc    %0, %0, %4\n"
>>> +#endif
>>>    "    strexd    %1, %0, %H0, [%3]\n"
>>>    "    teq    %1, #0\n"
>>>    "    bne    1b"
>>> @@ -428,9 +448,15 @@ static inline u64 atomic64_dec_if_positi
>>>
>>>        __asm__ __volatile__("@ atomic64_dec_if_positive\n"
>>>    "1:    ldrexd    %0, %H0, [%3]\n"
>>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>>    "    subs    %0, %0, #1\n"
>>>    "    sbc    %H0, %H0, #0\n"
>>>    "    teq    %H0, #0\n"
>>> +#else
>>> +"    subs    %H0, %H0, #1\n"
>>> +"    sbc    %0, %0, #0\n"
>>> +"    teq    %0, #0\n"
>>> +#endif
>>>    "    bmi    2f\n"
>>>    "    strexd    %1, %0, %H0, [%3]\n"
>>>    "    teq    %1, #0\n"
>>> @@ -459,8 +485,13 @@ static inline int atomic64_add_unless(at
>>>    "    teqeq    %H0, %H5\n"
>>>    "    moveq    %1, #0\n"
>>>    "    beq    2f\n"
>>> +#ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
>>>    "    adds    %0, %0, %6\n"
>>>    "    adc    %H0, %H0, %H6\n"
>>> +#else
>>> +"    adds    %H0, %H0, %H6\n"
>>> +"    adc    %0, %0, %6\n"
>>> +#endif
>>>    "    strexd    %2, %0, %H0, [%4]\n"
>>>    "    teq    %2, #0\n"
>>>    "    bne    1b\n"
>>
>>
>> I still believe that you're doing the wrong thing here
>> and that these can be left well enough alone. Please give
>> a concrete piece of code that can show they're actually
>> doing the wrong thing.
>
> Disable CONFIG_GENERIC_ATOMIC64
> -------------------------------
>
> Make sure that CONFIG_GENERIC_ATOMIC64 is not set. Otherwise atomic64_add from
> lib/atomic64.c will be used and that one works correctly but this case does
> not use atomic64_XXX inline functions from arch/arm/include/asm/atomic.h
>
> Personally with my current kernel close to 3.10 I failed to do that and manage
> to get live kernel, so to illustrate the issue I will use my own copy of
> inline atomic64_add function. But effectively it will show the same problem
> that I tried to report.

the kconfig has:
select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)

which means that it is possible that the generic one is being used.


> Compiler used
> -------------
>
> gcc-linaro-arm-linux-gnueabihf-4.7-2013.01-20130125_linux
>
> Test module source
> ------------------
>
> #include<linux/module.h>
> #include<linux/moduleparam.h>
> #include<linux/atomic.h>
>
> static inline void my_atomic64_add_original(u64 i, atomic64_t *v)
> {
>      u64 result;
>      unsigned long tmp;
>
>      __asm__ __volatile__("@ atomic64_add\n"
> "1:    ldrexd    %0, %H0, [%3]\n"
> "    adds    %0, %0, %4\n"
> "    adc    %H0, %H0, %H4\n"
> "    strexd    %1, %0, %H0, [%3]\n"
> "    teq    %1, #0\n"
> "    bne    1b"
>      : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
>      : "r" (&v->counter), "r" (i)
>      : "cc");
> }
>
> static inline void my_atomic64_add_fixed(u64 i, atomic64_t *v)
> {
>      u64 result;
>      unsigned long tmp;
>
>      __asm__ __volatile__("@ atomic64_add\n"
> "1:    ldrexd    %0, %H0, [%3]\n"
> #ifndef CONFIG_CPU_BIG_ENDIAN /* little endian */
> "    adds    %0, %0, %4\n"
> "    adc    %H0, %H0, %H4\n"
> #else
> "    adds    %H0, %H0, %H4\n"
> "    adc    %0, %0, %4\n"
> #endif
> "    strexd    %1, %0, %H0, [%3]\n"
> "    teq    %1, #0\n"
> "    bne    1b"
>      : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
>      : "r" (&v->counter), "r" (i)
>      : "cc");
> }
>
>
> atomic64_t a = {0};
>
> #define INCREMENT 0x40000000
>
> void atomic_update_original (void)
> {
>      my_atomic64_add_original(INCREMENT,&a);
> }
>
> void atomic_update_fixed (void)
> {
>      my_atomic64_add_fixed(INCREMENT,&a);
> }
>
> void test_atomic64_original(void)
> {
>      int i;
>
>      printk("original atomic64_add\n");
>
>      atomic64_set(&a, 0);
>
>      printk("a = %llx\n", a.counter);
>
>      for (i = 0; i<  10; i++) {
>          atomic_update_original();
>          printk("i = %2d: a =  %llx\n", i, a.counter);
>      }
> }
>
> void test_atomic64_fixed(void)
> {
>      int i;
>
>      printk("fixed atomic64_add\n");
>
>      atomic64_set(&a, 0);
>
>      printk("a = %llx\n", a.counter);
>
>      for (i = 0; i<  10; i++) {
>          atomic_update_fixed();
>          printk("i = %2d: a =  %llx\n", i, a.counter);
>      }
> }
>
> int
> init_module (void)
> {
>      test_atomic64_original();
>      test_atomic64_fixed();
>      return 0;
> }
>
> void
> cleanup_module(void)
> {
> }
>
> MODULE_LICENSE("GPL");
>
>
> Test run
> --------
>
> Compile and run module, observe in original code counter is not incremented
> correctly.
>
> root at genericarmv7ab:~# insmod atomic64.ko
> [   73.041107] original atomic64_add
> [   73.044647] a = 0
> [   73.046691] i =  0: a =  40000000
> [   73.050659] i =  1: a =  80000000
> [   73.054199] i =  2: a =  c0000000
> [   73.057983] i =  3: a =  0
> [   73.060852] i =  4: a =  40000000
> [   73.064361] i =  5: a =  80000000
> [   73.067932] i =  6: a =  c0000000
> [   73.071441] i =  7: a =  0
> [   73.074310] i =  8: a =  40000000
> [   73.077850] i =  9: a =  80000000
> [   73.081390] fixed atomic64_add
> [   73.084625] a = 0
> [   73.086669] i =  0: a =  40000000
> [   73.090209] i =  1: a =  80000000
> [   73.093749] i =  2: a =  c0000000
> [   73.097290] i =  3: a =  100000000
> [   73.100891] i =  4: a =  140000000
> [   73.104522] i =  5: a =  180000000
> [   73.108154] i =  6: a =  1c0000000
> [   73.111755] i =  7: a =  200000000
> [   73.115386] i =  8: a =  240000000
> [   73.119018] i =  9: a =  280000000
>
>
> Disassemble of original code
> ----------------------------
>
> (gdb) disassemble atomic_update_original
> Dump of assembler code for function atomic_update_original:
>     0x00000000<+0>:    push    {r4}        ; (str r4, [sp, #-4]!)
>     0x00000004<+4>:    mov    r3, #1073741824    ; 0x40000000
>     0x00000008<+8>:    ldr    r12, [pc, #32]    ; 0x30
> <atomic_update_original+48>
>     0x0000000c<+12>:    mov    r2, #0
>     0x00000010<+16>:    ldrexd    r0, [r12]
>     0x00000014<+20>:    adds    r0, r0, r2
>     0x00000018<+24>:    adc    r1, r1, r3
>     0x0000001c<+28>:    strexd    r4, r0, [r12]
>     0x00000020<+32>:    teq    r4, #0
>     0x00000024<+36>:    bne    0x10<atomic_update_original+16>
>     0x00000028<+40>:    ldmfd    sp!, {r4}
>     0x0000002c<+44>:    bx    lr
>     0x00000030<+48>:    andeq    r0, r0, r0
> End of assembler dump.
>
> Disassemble of fixed code
> -------------------------
>
> (gdb) disassemble atomic_update_fixed
> Dump of assembler code for function atomic_update_fixed:
>     0x00000034<+0>:    push    {r4}        ; (str r4, [sp, #-4]!)
>     0x00000038<+4>:    mov    r3, #1073741824    ; 0x40000000
>     0x0000003c<+8>:    ldr    r12, [pc, #32]    ; 0x64<atomic_update_fixed+48>
>     0x00000040<+12>:    mov    r2, #0
>     0x00000044<+16>:    ldrexd    r0, [r12]
>     0x00000048<+20>:    adds    r1, r1, r3
>     0x0000004c<+24>:    adc    r0, r0, r2
>     0x00000050<+28>:    strexd    r4, r0, [r12]
>     0x00000054<+32>:    teq    r4, #0
>     0x00000058<+36>:    bne    0x44<atomic_update_fixed+16>
>     0x0000005c<+40>:    ldmfd    sp!, {r4}
>     0x00000060<+44>:    bx    lr
>     0x00000064<+48>:    andeq    r0, r0, r0
> End of assembler dump.
>
> Fixed code explanation
> ----------------------
>
> - $r2 has 4 most significant bytes of increement (0)
> - $r3 has 4 least significant bytes of increement (0x40000000)
>
> - Load from address at $r12 'long long' into r0 and r1
>    $r0 will get 4 most significant bytes (i.e 4 bytes at $r12)
>    $r1 will get 4 least significan bytes (i.e 4 bytes at $r12+4)
>    loads are big endian, so $r0 and $r0 will be read with proper be swap
>
>     0x00000044<+16>:    ldrexd    r0, [r12]
>
> - add $r3 to $r1 store result into $r1, carry flag could be set
> - adding 4 least sginificant bytes of 'long long'
>
>     0x00000048<+20>:    adds    r1, r1, r3
>
> - adding with carry most siginificant parts of increment and counter
>
>     0x0000004c<+24>:    adc    r0, r0, r2
>
> - Store result back
>    $r0 will to $r12 address
>    $r1 will to $r12+4 address
>
>     0x00000050<+28>:    strexd    r4, r0, [r12]
>
> Ldrd/strd
> ---------
>
> Issue boils down to the fact that ldrexd/ldrd and strexd/strd instrucitons
> in big endian mode will do byteswap only within 4 bytes boundary, but it will
> not swap registers numbers itself. I.e ldrexd rN,<addr>  puts swapped 4 bytes
> at<addr>  address into rN, and it puts swapped 4 bytes at<addr+4>  into rN+1

Looking at the ARM ARM, the following is LDRD.

if ConditionPassed() then
     EncodingSpecificOperations(); NullCheckIfThumbEE(15);
     address = if add then (Align(PC,4) + imm32) else (Align(PC,4) - imm32);
     if HaveLPAE() && address<2:0> == '000' then
         data = MemA[Address,8];
         if BigEndian() then
              R[t] = data<63:32>;
              R[t2] = data<31:0>;
         else
              R[t] = data<31:0>;
              R[t2] = data<63:32>;
     else
         R[t] = MemA[address,4];
         R[t2] = MemA[address+4,4];

I thought it always had R[t] as lowest and R[t2] as the highest.

> Compiler?
> ---------
>
> One may thing whether we have compiler bug here. And after all, what is the
> meaning of %0 vs %H0? I asked my local gcc expert for the help. Here what
> I got. Please look at
>
> https://github.com/mirrors/gcc/blob/master/gcc/config/arm/arm.c
>
> and search for>'Q', 'R' and 'H'<
>
> according to this page '%HN' is always reg+1 operand regardless whether it is
> big endian system or not. It is opposite to 'Q'.
>
> Better fix
> ----------
>
> In fact now I believe correct fix should use 'Q' for least siginificant 4
> bytes, 'R' for most siginificant 4 bytes and 'H' is used in load/store
> instructions.
>
> It should look something like this:
>
> static inline void my_atomic64_add_fixed1(u64 i, atomic64_t *v)
> {
>      u64 result;
>      unsigned long tmp;
>
>      __asm__ __volatile__("@ atomic64_add\n"
> "1:    ldrexd    %0, %H0, [%3]\n"
> "    adds    %Q0, %Q0, %Q4\n"
> "    adc    %R0, %R0, %R4\n"
> "    strexd    %1, %0, %H0, [%3]\n"
> "    teq    %1, #0\n"
> "    bne    1b"
>      : "=&r" (result), "=&r" (tmp), "+Qo" (v->counter)
>      : "r" (&v->counter), "r" (i)
>      : "cc");
> }
>
> It is better that my original fix because it does not have conditional
> compilation. I've tested it in the module, it works on both LE and BE kernel
> variants.

If you want to make a patch with this in, I can add it to my series
ready to get merged.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From Sudeep.KarkadaNagesha at arm.com  Wed Jul 24 06:48:30 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Wed, 24 Jul 2013 11:48:30 +0100
Subject: [PATCH 0/5] ARM: DT: remove redundant DT related code
In-Reply-To: <alpine.LFD.2.03.1307231543480.15022@syhkavp.arg>
References: <1374579164-30255-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <alpine.LFD.2.03.1307231543480.15022@syhkavp.arg>
Message-ID: <51EFB0FE.8080503@arm.com>

On 23/07/13 20:45, Nicolas Pitre wrote:
> On Tue, 23 Jul 2013, Sudeep KarkadaNagesha wrote:
> 
>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>>
>> Hi,
>>
>> As part of my changes to remove duplicate code for parsing cpu nodes
>> in the device tree, I found few unnecessary code mostly around smp_init_cpus.
>> Most of the ARM Cortex A9 based platforms use SCU to get the number of cpus
>> while many others depend on the device tree.
>>
>> Even on DT based platforms using SCU, they can be made to depend on DT
>> to cpu count simplifying smp_init_cpus. In fact arm_dt_init_cpu_maps called
>> before smp_init_cpus, already does the device tree parsing, validating
>> nr_cpu_ids and setting the cpu_possible_mask appropriately. 
>>
>> However this series targets only the platforms using DT for cpu count
>> (i.e. not using SCU)
>>
>> Regards,
>> Sudeep
> For the whole series:
> 
> Acked-by: Nicolas Pitre <nico at linaro.org>
> 
Thanks for the review.

Regards,
Sudeep




From sachin.kamat at linaro.org  Wed Jul 24 06:49:49 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Wed, 24 Jul 2013 16:19:49 +0530
Subject: [PATCH v4 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <51EFB023.6090804@samsung.com>
References: <1374655405-22998-1-git-send-email-sachin.kamat@linaro.org>
 <51EFB023.6090804@samsung.com>
Message-ID: <CAK9yfHyMcyWJh6Jv0ZK1t=+hMhD44qE3WccaLnwFM=tK8ab6GQ@mail.gmail.com>

Hi Sylwester,

On 24 July 2013 16:14, Sylwester Nawrocki <s.nawrocki at samsung.com> wrote:
> Hi Sachin,
>
> On 07/24/2013 10:43 AM, Sachin Kamat wrote:
>> With the recent cleanup in Exynos platform code notably commits
>> 17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
>> more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
>> of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
>> Exynos4412 which have more than the default number of GPIOs. Thus define
>> this number in KConfig file which takes care of current SoC requirements
>> and provides scope for GPIO expanders. Without this patch we get the
>> following errors during boot:
>>
>> gpiochip_add: gpios 251..258 (gpv0) failed to register
>> samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0,
>> error code: -22
>> samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
>> Cc: Tomasz Figa <t.figa at samsung.com>
>> ---
>> Changes since v3:
>> Rearranged different default values in single line.
>> ---
>>  arch/arm/Kconfig |    3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index f8fb910..ac9fa38 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -1590,8 +1590,7 @@ config ARM_PSCI
>>  config ARCH_NR_GPIO
>>       int
>>       default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
>> -     default 512 if SOC_OMAP5
>> -     default 512 if ARCH_KEYSTONE
>> +     default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5
>
> Sorry, 512 seems a bit too generous to me. Also I would rather
> leave each SOC/ARCH on a separate line.

Even I had left it that way earlier. However Kukjin suggested the
above (single line).
I feel it is more of individual preference.

>
> Almost half of those 512 entries would have been unused in most
> cases. How about, e.g. 352 ? If anyone finds this value too low
> they could always submit a patch like this one. IMHO with 352 or
> 392 there would be sufficient margin.

I agree. Again, I do not have any reservations here. I just went with
maintainer's choice which was a superset of your and Tomasz's
suggestions :)

-- 
With warm regards,
Sachin


From josephl at nvidia.com  Wed Jul 24 06:54:32 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 24 Jul 2013 18:54:32 +0800
Subject: [PATCH V2] ARM: dts: tegra114: dalmore: fix the irq trigger type of
 Palmas MFD device
Message-ID: <1374663272-9937-1-git-send-email-josephl@nvidia.com>

The IRQ trigger type of Palmas MFD device (tps65913) is edge trigger. The
wrong configuration would cause an interrupt storm when booting the
system. Fixing it in DT with appropriate interrupt type.

Cc: Laxman Dewangan <ldewangan at nvidia.com>
Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/boot/dts/tegra114-dalmore.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index 76529e4..a2a1b5f 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -840,7 +840,7 @@
 		palmas: tps65913 {
 			compatible = "ti,palmas";
 			reg = <0x58>;
-			interrupts = <0 86 0x4>;
+			interrupts = <0 86 0x0>;
 
 			#interrupt-cells = <2>;
 			interrupt-controller;
-- 
1.8.3.2



From ldewangan at nvidia.com  Wed Jul 24 07:10:54 2013
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Jul 2013 16:40:54 +0530
Subject: [PATCH V2] ARM: dts: tegra114: dalmore: fix the irq trigger type
 of Palmas MFD device
In-Reply-To: <1374663272-9937-1-git-send-email-josephl@nvidia.com>
References: <1374663272-9937-1-git-send-email-josephl@nvidia.com>
Message-ID: <51EFB63E.30003@nvidia.com>

On Wednesday 24 July 2013 04:24 PM, Joseph Lo wrote:
> The IRQ trigger type of Palmas MFD device (tps65913) is edge trigger. The
> wrong configuration would cause an interrupt storm when booting the
> system. Fixing it in DT with appropriate interrupt type.
>
> Cc: Laxman Dewangan <ldewangan at nvidia.com>
> Signed-off-by: Joseph Lo <josephl at nvidia.com>
> ---
>   
Tested by: Laxman Dewangan <ldewangan at nvidia.com>


From kgene at kernel.org  Wed Jul 24 07:01:12 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 24 Jul 2013 20:01:12 +0900
Subject: [PATCH v4 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <CAK9yfHyMcyWJh6Jv0ZK1t=+hMhD44qE3WccaLnwFM=tK8ab6GQ@mail.gmail.com>
References: <1374655405-22998-1-git-send-email-sachin.kamat@linaro.org>
 <51EFB023.6090804@samsung.com>
 <CAK9yfHyMcyWJh6Jv0ZK1t=+hMhD44qE3WccaLnwFM=tK8ab6GQ@mail.gmail.com>
Message-ID: <0ea801ce885d$1c560aa0$55021fe0$@org>

Sachin Kamat wrote:
> 
> Hi Sylwester,
> 
Hi all,

[...]

> >> @@ -1590,8 +1590,7 @@ config ARM_PSCI
> >>  config ARCH_NR_GPIO
> >>       int
> >>       default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
> >> -     default 512 if SOC_OMAP5
> >> -     default 512 if ARCH_KEYSTONE
> >> +     default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5
> >
> > Sorry, 512 seems a bit too generous to me. Also I would rather
> > leave each SOC/ARCH on a separate line.
> 
> Even I had left it that way earlier. However Kukjin suggested the
> above (single line).
> I feel it is more of individual preference.
> 
I know it is quite big but I think if we want to use the large number, I'd
preferred to use enough the large number so that we don't need to update it
soon. If so, multiple line is useless...

Note, according to git log, for omap5, 256 is the accurately right number.

> >
> > Almost half of those 512 entries would have been unused in most
> > cases. How about, e.g. 352 ? If anyone finds this value too low
> > they could always submit a patch like this one. IMHO with 352 or
> > 392 there would be sufficient margin.
> 
Hmm...

> I agree. Again, I do not have any reservations here. I just went with
> maintainer's choice which was a superset of your and Tomasz's
> suggestions :)
> 
- Kukjin



From will.deacon at arm.com  Wed Jul 24 07:18:41 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 12:18:41 +0100
Subject: [PATCH 4/6] ARM: locks: prefetch the destination word for write
 prior to strex
In-Reply-To: <alpine.LFD.2.03.1307231609170.15022@syhkavp.arg>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-5-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231609170.15022@syhkavp.arg>
Message-ID: <20130724111841.GD11072@mudshark.cambridge.arm.com>

On Tue, Jul 23, 2013 at 09:10:33PM +0100, Nicolas Pitre wrote:
> On Tue, 23 Jul 2013, Will Deacon wrote:
> 
> > The cost of changing a cacheline from shared to exclusive state can be
> > significant, especially when this is triggered by an exclusive store,
> > since it may result in having to retry the transaction.
> > 
> > This patch prefixes our {spin,read,write}_[try]lock implementations with
> > pldw instructions (on CPUs which support them) to try and grab the line
> > in exclusive state from the start.
> > 
> > Signed-off-by: Will Deacon <will.deacon at arm.com>
> > ---
> >  arch/arm/include/asm/spinlock.h | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
> > index 0de7bec..3e1cc9d 100644
> > --- a/arch/arm/include/asm/spinlock.h
> > +++ b/arch/arm/include/asm/spinlock.h
> > @@ -5,7 +5,7 @@
> >  #error SMP not supported on pre-ARMv6 CPUs
> >  #endif
> >  
> > -#include <asm/processor.h>
> > +#include <linux/prefetch.h>
> >  
> >  /*
> >   * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
> > @@ -70,6 +70,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
> >  	u32 newval;
> >  	arch_spinlock_t lockval;
> >  
> > +	prefetchw((const void *)&lock->slock);
> 
> Couldn't that cast be carried in the definition of prefetchw() instead?

I think that would mean implementing prefetchw as a macro rather than an
inline function, since the core code expects to pass a const pointer and GCC
gets angry if the type signatures don't match.

I'll have a go at doing that for v2.

Cheers,

Will


From sebastian.hesselbarth at gmail.com  Wed Jul 24 07:20:33 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Wed, 24 Jul 2013 13:20:33 +0200
Subject: [PATCH v8 06/28] ARM: dove: Move to ID based window creation
In-Reply-To: <1374586292-4941-7-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1374586292-4941-7-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <51EFB881.4030901@gmail.com>

On 07/23/13 15:31, Ezequiel Garcia wrote:
> From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>
> With the introduction of the ID based MBus API, it's better
> to switch to use it instead of the current name based scheme.
>
> This will allow to deprecate the name based API, once every
> user is removed.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>   arch/arm/mach-dove/common.c | 68 ++++++++++++++++++++++++++++++---------------
>   1 file changed, 45 insertions(+), 23 deletions(-)

Ezequiel,

for the whole patch series on Dove DT:

Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>

Sebastian


From catalin.marinas at arm.com  Wed Jul 24 07:41:15 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 24 Jul 2013 12:41:15 +0100
Subject: [PATCH] arm64: Change kernel stack size to 16K.
In-Reply-To: <1374601951-4091-1-git-send-email-fkan@apm.com>
References: <1374601951-4091-1-git-send-email-fkan@apm.com>
Message-ID: <20130724114114.GD6238@MacBook-Pro.local>

On Tue, Jul 23, 2013 at 06:52:31PM +0100, Feng Kan wrote:
> Written by Catalin Marinas, tested by APM on storm platform. This is needed 
> because of the failures encountered when running SpecWeb benchmark test.
> 
> Signed-off-by: Feng Kan <fkan at apm.com>
> Acked-by: Kumar Sankaran <ksankaran at apm.com>

Thanks.

-- 
Catalin


From josephl at nvidia.com  Wed Jul 24 07:46:58 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 24 Jul 2013 19:46:58 +0800
Subject: [PATCH V4 2/4] ARM: tegra114: Reprogram GIC CPU interface to
 bypass IRQ on CPU PM entry
In-Reply-To: <20130723154438.GA2864@dhcp-172-17-186-34.nvidia.com>
References: <1374225926-26832-1-git-send-email-josephl@nvidia.com>
 <1374225926-26832-3-git-send-email-josephl@nvidia.com>
 <20130723154438.GA2864@dhcp-172-17-186-34.nvidia.com>
Message-ID: <1374666419.23756.55.camel@jlo-ubuntu-64.nvidia.com>

On Tue, 2013-07-23 at 23:44 +0800, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Fri, Jul 19, 2013 at 05:25:24PM +0800, Joseph Lo wrote:
> > There is a difference between GICv1 and v2 when CPU in power management
> > mode (aka CPU power down on Tegra). For GICv1, IRQ/FIQ interrupt lines
> > going to CPU are same lines which are also used for wake-interrupt.
> > Therefore, we cannot disable the GIC CPU interface if we need to use same
> > interrupts for CPU wake purpose. This creates a race condition for CPU
> > power off entry. Also, in GICv1, disabling GICv1 CPU interface puts GICv1
> > into bypass mode such that incoming legacy IRQ/FIQ are sent to CPU, which
> > means disabling GIC CPU interface doesn't really disable IRQ/FIQ to CPU.
> > 
> > GICv2 provides a wake IRQ/FIQ (for wake-event purpose), which are not
> > disabled by GIC CPU interface. This is done by adding a bypass override
> > capability when the interrupts are disabled at the CPU interface. To
> > support this, there are four bits about IRQ/FIQ BypassDisable in CPU
> > interface Control Register. When the IRQ/FIQ not being driver by the
> > CPU interface, each interrupt output signal can be deasserted rather
> > than being driven by the legacy interrupt input.
> > 
> > So the wake-event can be used as wakeup signals to SoC (system power
> > controller).
> > 
> > To prevent race conditions and ensure proper interrupt routing on
> > Cortex-A15 CPUs when they are power-gated, add a CPU PM notifier
> > call-back to reprogram the GIC CPU interface on PM entry. The
> > GIC CPU interface will be reset back to its normal state by
> > the common GIC CPU PM exit callback when the CPU wakes up.
> > 
> > Based on the work by: Scott Williams <scwilliams at nvidia.com>
> > 
> > Signed-off-by: Joseph Lo <josephl at nvidia.com>
> 
> Hi Joseph,
> 
> We've had a rather long-standing issue with PCIe and MSI related to LP2
> on Tegra20. I wonder if that's somehow related to this. Given that this
> is marked as Tegra114 patch explicitly I suppose not, but it certainly
> sounds very similar to the description above.
> 
For LP2 + PCIe + MSI, I believe it need some other SW support if the HW
really support MSI and runtime power down CPU domain that include SCU
and BIU. According to TRM, the PCIe pass data through the unit to
memory. I have no idea does the HW really support this function. I also
need more information about this. 





From kgene at kernel.org  Wed Jul 24 07:47:13 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 24 Jul 2013 20:47:13 +0900
Subject: [PATCH] ARM: EXYNOS: cpuidle: Skip C1 cpuidle state for exynos5440
In-Reply-To: <1374659615-29447-1-git-send-email-amit.daniel@samsung.com>
References: <0e7d01ce8840$82f79070$88e6b150$@org>
 <1374659615-29447-1-git-send-email-amit.daniel@samsung.com>
Message-ID: <0eaf01ce8863$89d3c4e0$9d7b4ea0$@org>

Amit Daniel Kachhap wrote:
> 
> This patch skips the deep C1(AFTR -Arm off top running) state for
> exynos5440
> soc as this soc does not support this state. All the cpu's only allows the
> basic
> C0 state.
> 
> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
> ---
>  arch/arm/mach-exynos/cpuidle.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
> exynos/cpuidle.c
> index 17a18ff..9a776a1 100644
> --- a/arch/arm/mach-exynos/cpuidle.c
> +++ b/arch/arm/mach-exynos/cpuidle.c
> @@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void)
>  		device->cpu = cpu_id;
> 
>  		/* Support IDLE only */
> -		if (cpu_id != 0)
> +		if (soc_is_exynos5440() || cpu_id != 0)
>  			device->state_count = 1;
> 
>  		ret = cpuidle_register_device(device);
> --
> 1.7.1

Applied, thanks.
- Kukjin



From r.sricharan at ti.com  Wed Jul 24 07:50:39 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Wed, 24 Jul 2013 17:20:39 +0530
Subject: [PATCH 6/8] ARM: mm: LPAE: Correct virt_to_phys patching for
 64 bit physical addresses
In-Reply-To: <alpine.LFD.2.03.1307232222200.15022@syhkavp.arg>
References: <1371858502-10083-1-git-send-email-santosh.shilimkar@ti.com>
 <1371858502-10083-7-git-send-email-santosh.shilimkar@ti.com>
 <alpine.LFD.2.03.1307231850350.15022@syhkavp.arg> <51EF356D.2050902@ti.com>
 <alpine.LFD.2.03.1307232222200.15022@syhkavp.arg>
Message-ID: <51EFBF8F.4010201@ti.com>

On Wednesday 24 July 2013 08:19 AM, Nicolas Pitre wrote:
> On Tue, 23 Jul 2013, Santosh Shilimkar wrote:
>
>> On Tuesday 23 July 2013 09:10 PM, Nicolas Pitre wrote:
>>> On Fri, 21 Jun 2013, Santosh Shilimkar wrote:
>>>
>>>> From: Sricharan R <r.sricharan at ti.com>
>>>>
>>>> The current phys_to_virt patching mechanism does not work
>>>> for 64 bit physical addressesp. Note that constant used in add/sub
>>>> instructions is encoded in to the last 8 bits of the opcode. So shift
>>>> the _pv_offset constant by 24 to get it in to the correct place.
>>>>
>>>> The v2p patching mechanism patches the higher 32bits of physical
>>>> address with a constant. While this is correct, in those platforms
>>>> where the lowmem addressable physical memory spawns across 4GB boundary,
>>>> a carry bit can be produced as a result of addition of lower 32bits.
>>>> This has to be taken in to account and added in to the upper. The patched
>>>> __pv_offset and va are added in lower 32bits, where __pv_offset can be
>>>> in two's complement form when PA_START < VA_START and that can result
>>>> in a false carry bit.
>>>>
>>>> e.g PA = 0x80000000 VA = 0xC0000000
>>>> __pv_offset = PA - VA = 0xC0000000 (2's complement)
>>>>
>>>> So adding __pv_offset + VA should never result in a true overflow. So in
>>>> order to differentiate between a true carry, a extra flag __pv_sign_flag
>>>> is introduced.
>> First of all thanks for the review.
>>  
>>> I'm still wondering if this is worth bothering about.
>>>
>>> If PA = 0x80000000 and VA = 0xC0000000 there will never be a real carry 
>>> to propagate to the high word of the physical address as the VA space 
>>> cannot be larger than 0x40000000.
>>>
>> Agreed.
>>
>>> So is there really a case where:
>>>
>>> 1) physical memory is crossing the 4GB mark, and ...
>>>
>>> 2) physical memory start address is higher than virtual memory start 
>>>    address needing a carry due to the 32-bit add overflow?
>>>
>> Consider below two cases of memory layout apart from one mentioned
>> above where the carry is bit irrelevant as you rightly said.
>>
>> 1) PA = 0x8_0000_0000, VA= 0xC000_0000, absolute pv_offset = 0x7_4000_0000
> This can be patched as:
>
> 	mov	phys_hi, #0x8
> 	add	phys_lo, virt, #0x40000000  @ carry ignored
>
>> 2) PA = 0x2_8000_0000, VA= 0xC000_000, absolute pv_offset = 0x1_C000_0000
> 	mov	phys_hi, #0x2
> 	add	phys_lo, virt, #0xc0000000  @ carry ignored
>
>> In both of these cases there a true carry which needs to be
>> considered.
> Well, not really.  However, if you have:
>
> 3) PA = 0x2_8000_0000, VA = 0x4000-0000, pv_offset = 0x2-4000-0000
>
> ... then you need:
>
> 	mov	phys_hi, #0x2
> 	adds	phys_lo, virt, #0x40000000
> 	adc	phys_hi, phys_hi, #0
>
> My question is: how likely is this?
>
> What is your actual physical memory start address?

 Agreed.  In our case we do not have the Physical address crossing across
  4GB. So ignoring the carry would have be been OK. But we are
 also addressing the other case where it would really crossover.

> If we really need to cope with the carry, then the __pv_sign_flag should 
> instead be represented in pv_offset directly:
>
> Taking example #2 above, that would be:
>
> 	mov	phys_hi, #0x1
> 	adds	phys_lo, virt, #0xc0000000
> 	adc	phys_hi, phys_hi, #0
>
> If PA = 0x8000-0000 and VA = 0xc000-0000 then pv_offset is 
> 0xffff-ffff-c000-0000, meaning:
>
> 	mvn	phys_hi, #0
> 	add	phys_lo, virt, #0xc0000000
> 	adc	phys_hi, phys_hi, #0
>
> So that would require a special case in the patching code where a mvn 
> with 0 is used if the high part of pv_offset is 0xffffffff.
>
>
> Nicolas
Extending pv_offset to 64bit is really neat way. When PA > VA, then pv_offset
is going to be actual value and not 2's complement. Fine here.
When running from higher physical address space, we will always fall here.

So for the second case where pv_offset is 0xffffffff .., (PA < VA)
is a problem only when we run from lower physical address. So we can safely
assume that the higher 32bits of PA are '0' and stub it initially. In this way we
can avoid the special case.

Regards,
 Sricharan


From kgene at kernel.org  Wed Jul 24 08:00:23 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 24 Jul 2013 21:00:23 +0900
Subject: [PATCH v4 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
References: <1374655405-22998-1-git-send-email-sachin.kamat@linaro.org>
 <51EFB023.6090804@samsung.com>
 <CAK9yfHyMcyWJh6Jv0ZK1t=+hMhD44qE3WccaLnwFM=tK8ab6GQ@mail.gmail.com>
Message-ID: <0eb101ce8865$60f1d920$22d58b60$@org>

Kukjin Kim wrote:
> 
> Sachin Kamat wrote:
> >
> > Hi Sylwester,
> >
> Hi all,
> 
> [...]
> 
> > >> @@ -1590,8 +1590,7 @@ config ARM_PSCI
> > >>  config ARCH_NR_GPIO
> > >>       int
> > >>       default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
> > >> -     default 512 if SOC_OMAP5
> > >> -     default 512 if ARCH_KEYSTONE
> > >> +     default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5
> > >
> > > Sorry, 512 seems a bit too generous to me. Also I would rather
> > > leave each SOC/ARCH on a separate line.
> >
> > Even I had left it that way earlier. However Kukjin suggested the
> > above (single line).
> > I feel it is more of individual preference.
> >
> I know it is quite big but I think if we want to use the large number, I'd
> preferred to use enough the large number so that we don't need to update
> it soon. If so, multiple line is useless...
> 
> Note, according to git log, for omap5, 256 is the accurately right number.
> 
> > >
> > > Almost half of those 512 entries would have been unused in most
> > > cases. How about, e.g. 352 ? If anyone finds this value too low
> > > they could always submit a patch like this one. IMHO with 352 or
> > > 392 there would be sufficient margin.
> >
> Hmm...
> 
> > I agree. Again, I do not have any reservations here. I just went with
> > maintainer's choice which was a superset of your and Tomasz's
> > suggestions :)
> >
If you have another opinion on this, please let me know before sending fixes
for 3.11 probably tomorrow morning in my time.

Thanks,
Kukjin



From kgene at kernel.org  Wed Jul 24 08:05:46 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 24 Jul 2013 21:05:46 +0900
Subject: [PATCH Resend 1/1] clk: exynos4: Add clock entries for TMU
In-Reply-To: <1374660555-17429-1-git-send-email-sachin.kamat@linaro.org>
References: <1374660555-17429-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <0eb201ce8866$212e3080$638a9180$@org>

Sachin Kamat wrote:
> 
> Added clock entries for thermal management unit (TMU) for
> Exynos4 SoCs.
> 
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>

Acked-by: Kukjin Kim <kgene.kim at samsung.com>

Mike, I remember you're ok this for v3.12 so if you do not apply this in
clk-next yet, please go ahead :)

Thanks,
Kukjin

> ---
> Resending this (after rebasing) based on the below discussion:
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/19933
> 
> Previous version:
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/18081
> ---
>  .../devicetree/bindings/clock/exynos4-clock.txt    |    1 +
>  drivers/clk/samsung/clk-exynos4.c                  |    4 +++-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> index 14d5c2a..c6bf8a6 100644
> --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> @@ -236,6 +236,7 @@ Exynos4 SoC and this is specified where applicable.
>    spi0_isp_sclk       380     Exynos4x12
>    spi1_isp_sclk       381     Exynos4x12
>    uart_isp_sclk       382     Exynos4x12
> +  tmu_apbif           383
> 
>  		[Mux Clocks]
> 
> diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-
> exynos4.c
> index 75635eb..cee297d 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -169,7 +169,7 @@ enum exynos4_clks {
>  	gicisp, smmu_isp, smmu_drc, smmu_fd, smmu_lite0, smmu_lite1,
> mcuctl_isp,
>  	mpwm_isp, i2c0_isp, i2c1_isp, mtcadc_isp, pwm_isp, wdt_isp,
> uart_isp,
>  	asyncaxim, smmu_ispcx, spi0_isp, spi1_isp, pwm_isp_sclk,
> spi0_isp_sclk,
> -	spi1_isp_sclk, uart_isp_sclk,
> +	spi1_isp_sclk, uart_isp_sclk, tmu_apbif,
> 
>  	/* mux clocks */
>  	mout_fimc0 = 384, mout_fimc1, mout_fimc2, mout_fimc3, mout_cam0,
> @@ -814,6 +814,7 @@ static struct samsung_gate_clock
exynos4210_gate_clks[]
> __initdata = {
>  	GATE_A(keyif, "keyif", "aclk100", E4210_GATE_IP_PERIR, 16, 0, 0,
> "keypad"),
>  	GATE_DA(sclk_fimd1, "exynos4-fb.1", "sclk_fimd1", "div_fimd1",
>  			E4210_SRC_MASK_LCD1, 0, CLK_SET_RATE_PARENT, 0,
> "sclk_fimd"),
> +	GATE(tmu_apbif, "tmu_apbif", "aclk100", E4210_GATE_IP_PERIR, 17, 0,
> 0),
>  };
> 
>  /* list of gate clocks supported in exynos4x12 soc */
> @@ -915,6 +916,7 @@ static struct samsung_gate_clock
exynos4x12_gate_clks[]
> __initdata = {
>  	GATE(spi1_isp, "spi1_isp", "aclk200", E4X12_GATE_ISP1, 13,
>  			CLK_IGNORE_UNUSED, 0),
>  	GATE(g2d, "g2d", "aclk200", GATE_IP_DMC, 23, 0, 0),
> +	GATE(tmu_apbif, "tmu_apbif", "aclk100", E4X12_GATE_IP_PERIR, 17, 0,
> 0),
>  };
> 
>  /*
> --
> 1.7.9.5



From r.sricharan at ti.com  Wed Jul 24 08:07:23 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Wed, 24 Jul 2013 17:37:23 +0530
Subject: [PATCH 6/8] ARM: mm: LPAE: Correct virt_to_phys patching for
 64 bit physical addresses
In-Reply-To: <51EFBF8F.4010201@ti.com>
References: <1371858502-10083-1-git-send-email-santosh.shilimkar@ti.com>
 <1371858502-10083-7-git-send-email-santosh.shilimkar@ti.com>
 <alpine.LFD.2.03.1307231850350.15022@syhkavp.arg> <51EF356D.2050902@ti.com>
 <alpine.LFD.2.03.1307232222200.15022@syhkavp.arg> <51EFBF8F.4010201@ti.com>
Message-ID: <51EFC37B.80906@ti.com>

On Wednesday 24 July 2013 05:20 PM, Sricharan R wrote:
> On Wednesday 24 July 2013 08:19 AM, Nicolas Pitre wrote:
>> On Tue, 23 Jul 2013, Santosh Shilimkar wrote:
>>
>>> On Tuesday 23 July 2013 09:10 PM, Nicolas Pitre wrote:
>>>> On Fri, 21 Jun 2013, Santosh Shilimkar wrote:
>>>>
>>>>> From: Sricharan R <r.sricharan at ti.com>
>>>>>
>>>>> The current phys_to_virt patching mechanism does not work
>>>>> for 64 bit physical addressesp. Note that constant used in add/sub
>>>>> instructions is encoded in to the last 8 bits of the opcode. So shift
>>>>> the _pv_offset constant by 24 to get it in to the correct place.
>>>>>
>>>>> The v2p patching mechanism patches the higher 32bits of physical
>>>>> address with a constant. While this is correct, in those platforms
>>>>> where the lowmem addressable physical memory spawns across 4GB boundary,
>>>>> a carry bit can be produced as a result of addition of lower 32bits.
>>>>> This has to be taken in to account and added in to the upper. The patched
>>>>> __pv_offset and va are added in lower 32bits, where __pv_offset can be
>>>>> in two's complement form when PA_START < VA_START and that can result
>>>>> in a false carry bit.
>>>>>
>>>>> e.g PA = 0x80000000 VA = 0xC0000000
>>>>> __pv_offset = PA - VA = 0xC0000000 (2's complement)
>>>>>
>>>>> So adding __pv_offset + VA should never result in a true overflow. So in
>>>>> order to differentiate between a true carry, a extra flag __pv_sign_flag
>>>>> is introduced.
>>> First of all thanks for the review.
>>>  
>>>> I'm still wondering if this is worth bothering about.
>>>>
>>>> If PA = 0x80000000 and VA = 0xC0000000 there will never be a real carry 
>>>> to propagate to the high word of the physical address as the VA space 
>>>> cannot be larger than 0x40000000.
>>>>
>>> Agreed.
>>>
>>>> So is there really a case where:
>>>>
>>>> 1) physical memory is crossing the 4GB mark, and ...
>>>>
>>>> 2) physical memory start address is higher than virtual memory start 
>>>>    address needing a carry due to the 32-bit add overflow?
>>>>
>>> Consider below two cases of memory layout apart from one mentioned
>>> above where the carry is bit irrelevant as you rightly said.
>>>
>>> 1) PA = 0x8_0000_0000, VA= 0xC000_0000, absolute pv_offset = 0x7_4000_0000
>> This can be patched as:
>>
>> 	mov	phys_hi, #0x8
>> 	add	phys_lo, virt, #0x40000000  @ carry ignored
>>
>>> 2) PA = 0x2_8000_0000, VA= 0xC000_000, absolute pv_offset = 0x1_C000_0000
>> 	mov	phys_hi, #0x2
>> 	add	phys_lo, virt, #0xc0000000  @ carry ignored
>>
>>> In both of these cases there a true carry which needs to be
>>> considered.
>> Well, not really.  However, if you have:
>>
>> 3) PA = 0x2_8000_0000, VA = 0x4000-0000, pv_offset = 0x2-4000-0000
>>
>> ... then you need:
>>
>> 	mov	phys_hi, #0x2
>> 	adds	phys_lo, virt, #0x40000000
>> 	adc	phys_hi, phys_hi, #0
>>
>> My question is: how likely is this?
>>
>> What is your actual physical memory start address?
>  Agreed.  In our case we do not have the Physical address crossing across
>   4GB. So ignoring the carry would have be been OK. But we are
>  also addressing the other case where it would really crossover.
>
>> If we really need to cope with the carry, then the __pv_sign_flag should 
>> instead be represented in pv_offset directly:
>>
>> Taking example #2 above, that would be:
>>
>> 	mov	phys_hi, #0x1
>> 	adds	phys_lo, virt, #0xc0000000
>> 	adc	phys_hi, phys_hi, #0
>>
>> If PA = 0x8000-0000 and VA = 0xc000-0000 then pv_offset is 
>> 0xffff-ffff-c000-0000, meaning:
>>
>> 	mvn	phys_hi, #0
>> 	add	phys_lo, virt, #0xc0000000
>> 	adc	phys_hi, phys_hi, #0
>>
>> So that would require a special case in the patching code where a mvn 
>> with 0 is used if the high part of pv_offset is 0xffffffff.
>>
>>
>> Nicolas
> Extending pv_offset to 64bit is really neat way. When PA > VA, then pv_offset
> is going to be actual value and not 2's complement. Fine here.
> When running from higher physical address space, we will always fall here.
>
> So for the second case where pv_offset is 0xffffffff .., (PA < VA)
> is a problem only when we run from lower physical address. So we can safely
> assume that the higher 32bits of PA are '0' and stub it initially. In this way we
> can avoid the special case.
   Sorry, I missed one more point here. In the second case,we should patch it with
   0x0 when (PA > VA) and with 0xffffffff when (PA < VA).

Regards,
 Sricharan


From kgene at kernel.org  Wed Jul 24 08:13:38 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 24 Jul 2013 21:13:38 +0900
Subject: [RESEND PATCH 1/3] ARM: EXYNOS: Move arm core power down clock to
 exynos5250 common clock
In-Reply-To: <CADGdYn5owUyCMzJSJQgzR6N0inLpm5Te09BvX0rvBZ1bx=bv=Q@mail.gmail.com>
References: <1363240979-1939-2-git-send-email-amit.daniel@samsung.com>
 <1370501833-9196-1-git-send-email-amit.daniel@samsung.com>
 <CADGdYn5owUyCMzJSJQgzR6N0inLpm5Te09BvX0rvBZ1bx=bv=Q@mail.gmail.com>
Message-ID: <0eb301ce8867$3b12f430$b138dc90$@org>

amit daniel kachhap wrote:
> 
> Hi Mike,
> 
> If possible please ack this patch or merge this via your tree.
> 
> Thanks,
> Amit Daniel
> 
> On Thu, Jun 6, 2013 at 12:27 PM, Amit Daniel Kachhap
> <amit.daniel at samsung.com> wrote:
> > Now with common clock support added for exynos5250 it is necessary to
> move
> > this code to exynos5250 common clock driver as clock registers should be
> > handled there. This change is tested in exynos5250 based arndale
> platform.
> >
> > Cc: Abhilash Kesavan <a.kesavan at samsung.com>
> > Cc: Thomas Abraham <thomas.abraham at linaro.org>
> > Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>

Acked-by: Kukjin Kim <kgene.kim at samsung.com>

Mike, if you have any concerns on this, please let me know.

Thanks,
Kukjin

> > ---
> > Re-based against linux for-next branch.
> >
> >  arch/arm/mach-exynos/cpuidle.c       |   35
----------------------------
> >  drivers/clk/samsung/clk-exynos5250.c |   42
> ++++++++++++++++++++++++++++++++++
> >  2 files changed, 42 insertions(+), 35 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
> exynos/cpuidle.c
> > index 17a18ff..4667907 100644
> > --- a/arch/arm/mach-exynos/cpuidle.c
> > +++ b/arch/arm/mach-exynos/cpuidle.c
> > @@ -159,46 +159,11 @@ static int exynos4_enter_lowpower(struct
> cpuidle_device *dev,
> >                 return exynos4_enter_core0_aftr(dev, drv, new_index);
> >  }
> >
> > -static void __init exynos5_core_down_clk(void)
> > -{
> > -       unsigned int tmp;
> > -
> > -       /*
> > -        * Enable arm clock down (in idle) and set arm divider
> > -        * ratios in WFI/WFE state.
> > -        */
> > -       tmp = PWR_CTRL1_CORE2_DOWN_RATIO | \
> > -             PWR_CTRL1_CORE1_DOWN_RATIO | \
> > -             PWR_CTRL1_DIV2_DOWN_EN     | \
> > -             PWR_CTRL1_DIV1_DOWN_EN     | \
> > -             PWR_CTRL1_USE_CORE1_WFE    | \
> > -             PWR_CTRL1_USE_CORE0_WFE    | \
> > -             PWR_CTRL1_USE_CORE1_WFI    | \
> > -             PWR_CTRL1_USE_CORE0_WFI;
> > -       __raw_writel(tmp, EXYNOS5_PWR_CTRL1);
> > -
> > -       /*
> > -        * Enable arm clock up (on exiting idle). Set arm divider
> > -        * ratios when not in idle along with the standby duration
> > -        * ratios.
> > -        */
> > -       tmp = PWR_CTRL2_DIV2_UP_EN       | \
> > -             PWR_CTRL2_DIV1_UP_EN       | \
> > -             PWR_CTRL2_DUR_STANDBY2_VAL | \
> > -             PWR_CTRL2_DUR_STANDBY1_VAL | \
> > -             PWR_CTRL2_CORE2_UP_RATIO   | \
> > -             PWR_CTRL2_CORE1_UP_RATIO;
> > -       __raw_writel(tmp, EXYNOS5_PWR_CTRL2);
> > -}
> > -
> >  static int __init exynos4_init_cpuidle(void)
> >  {
> >         int cpu_id, ret;
> >         struct cpuidle_device *device;
> >
> > -       if (soc_is_exynos5250())
> > -               exynos5_core_down_clk();
> > -
> >         ret = cpuidle_register_driver(&exynos4_idle_driver);
> >         if (ret) {
> >                 printk(KERN_ERR "CPUidle failed to register driver\n");
> > diff --git a/drivers/clk/samsung/clk-exynos5250.c
> b/drivers/clk/samsung/clk-exynos5250.c
> > index 5c97e75..89f51e9 100644
> > --- a/drivers/clk/samsung/clk-exynos5250.c
> > +++ b/drivers/clk/samsung/clk-exynos5250.c
> > @@ -21,6 +21,8 @@
> >
> >  #define SRC_CPU                        0x200
> >  #define DIV_CPU0               0x500
> > +#define PWR_CTRL1              0x1020
> > +#define PWR_CTRL2              0x1024
> >  #define SRC_CORE1              0x4204
> >  #define SRC_TOP0               0x10210
> >  #define SRC_TOP2               0x10218
> > @@ -63,6 +65,23 @@
> >  #define PLL_DIV2_SEL           0x20a24
> >  #define GATE_IP_DISP1          0x10928
> >
> > +/*Below definitions are used for PWR_CTRL settings*/
> > +#define PWR_CTRL1_CORE2_DOWN_RATIO             (7 << 28)
> > +#define PWR_CTRL1_CORE1_DOWN_RATIO             (7 << 16)
> > +#define PWR_CTRL1_DIV2_DOWN_EN                 (1 << 9)
> > +#define PWR_CTRL1_DIV1_DOWN_EN                 (1 << 8)
> > +#define PWR_CTRL1_USE_CORE1_WFE                        (1 << 5)
> > +#define PWR_CTRL1_USE_CORE0_WFE                        (1 << 4)
> > +#define PWR_CTRL1_USE_CORE1_WFI                        (1 << 1)
> > +#define PWR_CTRL1_USE_CORE0_WFI                        (1 << 0)
> > +
> > +#define PWR_CTRL2_DIV2_UP_EN                   (1 << 25)
> > +#define PWR_CTRL2_DIV1_UP_EN                   (1 << 24)
> > +#define PWR_CTRL2_DUR_STANDBY2_VAL             (1 << 16)
> > +#define PWR_CTRL2_DUR_STANDBY1_VAL             (1 << 8)
> > +#define PWR_CTRL2_CORE2_UP_RATIO               (1 << 4)
> > +#define PWR_CTRL2_CORE1_UP_RATIO               (1 << 0)
> > +
> >  /*
> >   * Let each supported clock get a unique id. This id is used to lookup
> the clock
> >   * for device tree based platforms. The clocks are categorized into
> three
> > @@ -110,6 +129,8 @@ enum exynos5250_clks {
> >  static __initdata unsigned long exynos5250_clk_regs[] = {
> >         SRC_CPU,
> >         DIV_CPU0,
> > +       PWR_CTRL1,
> > +       PWR_CTRL2,
> >         SRC_CORE1,
> >         SRC_TOP0,
> >         SRC_TOP2,
> > @@ -474,6 +495,7 @@ void __init exynos5250_clk_init(struct device_node
> *np)
> >  {
> >         void __iomem *reg_base;
> >         struct clk *apll, *mpll, *epll, *vpll, *bpll, *gpll, *cpll;
> > +       unsigned int tmp;
> >
> >         if (np) {
> >                 reg_base = of_iomap(np, 0);
> > @@ -516,6 +538,26 @@ void __init exynos5250_clk_init(struct device_node
> *np)
> >         samsung_clk_register_gate(exynos5250_gate_clks,
> >                         ARRAY_SIZE(exynos5250_gate_clks));
> >
> > +       /*
> > +        * Enable arm clock down (in idle) and set arm divider
> > +        * ratios in WFI/WFE state.
> > +        */
> > +       tmp = (PWR_CTRL1_CORE2_DOWN_RATIO | PWR_CTRL1_CORE1_DOWN_RATIO |
> > +               PWR_CTRL1_DIV2_DOWN_EN | PWR_CTRL1_DIV1_DOWN_EN |
> > +               PWR_CTRL1_USE_CORE1_WFE | PWR_CTRL1_USE_CORE0_WFE |
> > +               PWR_CTRL1_USE_CORE1_WFI | PWR_CTRL1_USE_CORE0_WFI);
> > +       __raw_writel(tmp, reg_base + PWR_CTRL1);
> > +
> > +       /*
> > +        * Enable arm clock up (on exiting idle). Set arm divider
> > +        * ratios when not in idle along with the standby duration
> > +        * ratios.
> > +        */
> > +       tmp = (PWR_CTRL2_DIV2_UP_EN | PWR_CTRL2_DIV1_UP_EN |
> > +               PWR_CTRL2_DUR_STANDBY2_VAL | PWR_CTRL2_DUR_STANDBY1_VAL
|
> > +               PWR_CTRL2_CORE2_UP_RATIO | PWR_CTRL2_CORE1_UP_RATIO);
> > +       __raw_writel(tmp, reg_base + PWR_CTRL2);
> > +
> >         pr_info("Exynos5250: clock setup completed, armclk=%ld\n",
> >                         _get_rate("armclk"));
> >  }
> > --
> > 1.7.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html



From kgene at kernel.org  Wed Jul 24 08:20:40 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 24 Jul 2013 21:20:40 +0900
Subject: [PATCH v2 0/8] Common Clock Framework support for Samsung S3C64xx
In-Reply-To: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <0eb401ce8868$36bc27c0$a4347740$@org>

Tomasz Figa wrote:
> 
> This series is an attempt to move clock support on Samsung S3C64xx SoCs
> to Common Clock Framework.
> 
> First, support for PLL types present on S3C64xx SoCs is added to Samsung
> Common Clock Framework driver. Then the main clock driver for mentioned
> SoCs is introduced. Further patches contain fixes for drivers to make them
> compliant with CCF semantics, migration of platform code to use the new
> clock driver and removal of old clock management code.
> 
> Depends on:
>  - [PATCH v4 00/20] Samsung PWM support cleanup
>    http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20856
> 
> On S3C6410-based Tiny6410 board (Mini6410-compatible):
> 
> Tested-by: Tomasz Figa <tomasz.figa at gmail.com>
> 
> For v1:
> 
> Acked-by: Mike Turquette <mturquette at linaro.org>
> 
> Changes since v1:
>  - added patch for read-only muxes,
>  - exported configurable muxes and dividers,
>  - defined mout_syncmux as read-only mux,
>  - in DT-enabled case fixed-clock binding is used to define external
> clocks.
> 
> Tomasz Figa (8):
>   clk: mux: Add support for read-only muxes.
>   clk: samsung: pll: Add support for PLL6552 and PLL6553
>   clk: samsung: Add clock driver for S3C64xx SoCs
>   ARM: SAMSUNG: Add soc_is_s3c6400/s3c6410 macros
>   ARM: s3c64xx: dma: Use clk_prepare_enable/clk_disable_unprepare
>   usb: host: ohci-s3c2410 Use clk_prepare_enable/clk_disable_unprepare
>   ARM: s3c64xx: Migrate clock handling to Common Clock Framework
>   ARM: s3c64xx: Remove old clock management code
> 
>  .../bindings/clock/samsung,s3c64xx-clock.txt       |   77 ++
>  arch/arm/Kconfig                                   |    2 +-
>  arch/arm/mach-s3c64xx/Makefile                     |    2 +-
>  arch/arm/mach-s3c64xx/clock.c                      | 1007 --------------------
>  arch/arm/mach-s3c64xx/common.c                     |   21 +-
>  arch/arm/mach-s3c64xx/common.h                     |   12 +-
>  arch/arm/mach-s3c64xx/dma.c                        |    4 +-
>  arch/arm/mach-s3c64xx/include/mach/regs-clock.h    |  132 +--
>  arch/arm/mach-s3c64xx/mach-anw6410.c               |    2 +-
>  arch/arm/mach-s3c64xx/mach-crag6410.c              |    2 +-
>  arch/arm/mach-s3c64xx/mach-hmt.c                   |    2 +-
>  arch/arm/mach-s3c64xx/mach-mini6410.c              |    2 +-
>  arch/arm/mach-s3c64xx/mach-ncp.c                   |    2 +-
>  arch/arm/mach-s3c64xx/mach-smartq.c                |   11 +-
>  arch/arm/mach-s3c64xx/mach-smdk6400.c              |    2 +-
>  arch/arm/mach-s3c64xx/mach-smdk6410.c              |    2 +-
>  arch/arm/mach-s3c64xx/pm.c                         |   21 -
>  arch/arm/mach-s3c64xx/s3c6400.c                    |    6 -
>  arch/arm/mach-s3c64xx/s3c6410.c                    |    7 -
>  arch/arm/plat-samsung/include/plat/cpu.h           |    4 +
>  drivers/clk/clk-mux.c                              |   10 +-
>  drivers/clk/samsung/Makefile                       |    1 +
>  drivers/clk/samsung/clk-pll.c                      |  160 ++++
>  drivers/clk/samsung/clk-pll.h                      |    4 +
>  drivers/clk/samsung/clk-s3c64xx.c                  |  465 +++++++++
>  drivers/usb/host/ohci-s3c2410.c                    |    8 +-
>  include/dt-bindings/clock/samsung,s3c64xx-clock.h  |  178 ++++
>  include/linux/clk-provider.h                       |    2 +
>  28 files changed, 943 insertions(+), 1205 deletions(-)
>  create mode 100644
> Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
>  delete mode 100644 arch/arm/mach-s3c64xx/clock.c
>  create mode 100644 drivers/clk/samsung/clk-s3c64xx.c
>  create mode 100644 include/dt-bindings/clock/samsung,s3c64xx-clock.h
> 
> --
> 1.8.3.2

Looks nice series, thanks.

I've applied this whole series including updated v3 2nd and 3rd patches on top of PWM cleanup series. BTW, if I could get ack on 1st and 6th patches, would be helpful :-)

Regards,
Kukjin



From balbi at ti.com  Wed Jul 24 08:23:09 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 24 Jul 2013 15:23:09 +0300
Subject: [PATCH 1/7] usb: phy: msm: Move mach dependent code to platform
 data
In-Reply-To: <1372087664-26396-2-git-send-email-iivanov@mm-sol.com>
References: <1372087664-26396-1-git-send-email-iivanov@mm-sol.com>
 <1372087664-26396-2-git-send-email-iivanov@mm-sol.com>
Message-ID: <20130724122309.GD17962@radagast>

On Mon, Jun 24, 2013 at 06:27:38PM +0300, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov" <iivanov at mm-sol.com>
> 
> This patch fix compilation error and is an intermediate step
> before the addition of DeviceTree support for newer targets.
> Fix suggested here: https://lkml.org/lkml/2013/6/19/381
> 
> Cc: David Brown <davidb at codeaurora.org>
> Cc: Daniel Walker <dwalker at fifo99.com>
> Cc: Bryan Huntsman <bryanh at codeaurora.org>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: Stephen Boyd <sboyd at codeaurora.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> 
> Signed-off-by: Ivan T. Ivanov <iivanov at mm-sol.com>

I need Acks

-- 
balbi
-------------- 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/20130724/e731fbea/attachment.sig>

From s.nawrocki at samsung.com  Wed Jul 24 08:23:39 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 14:23:39 +0200
Subject: [PATCH v4 1/1] ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
In-Reply-To: <0eb101ce8865$60f1d920$22d58b60$@org>
References: <1374655405-22998-1-git-send-email-sachin.kamat@linaro.org>
 <51EFB023.6090804@samsung.com>
 <CAK9yfHyMcyWJh6Jv0ZK1t=+hMhD44qE3WccaLnwFM=tK8ab6GQ@mail.gmail.com>
 <0eb101ce8865$60f1d920$22d58b60$@org>
Message-ID: <51EFC74B.8000403@samsung.com>

On 07/24/2013 02:00 PM, Kukjin Kim wrote:
> Kukjin Kim wrote:
>> Sachin Kamat wrote:
[...]
>>>>> @@ -1590,8 +1590,7 @@ config ARM_PSCI
>>>>>  config ARCH_NR_GPIO
>>>>>       int
>>>>>       default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
>>>>> -     default 512 if SOC_OMAP5
>>>>> -     default 512 if ARCH_KEYSTONE
>>>>> +     default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5
>>>>
>>>> Sorry, 512 seems a bit too generous to me. Also I would rather
>>>> leave each SOC/ARCH on a separate line.
>>>
>>> Even I had left it that way earlier. However Kukjin suggested the
>>> above (single line).
>>> I feel it is more of individual preference.
>>>
>> I know it is quite big but I think if we want to use the large number, I'd
>> preferred to use enough the large number so that we don't need to update
>> it soon. If so, multiple line is useless...
>>
>> Note, according to git log, for omap5, 256 is the accurately right number.

If it's done similarly for other SoCs then I'm fine with change as above.
256 entries is only about 3 kB anyway, it shouldn't be a big deal for
systems using those SoCs.

>>>> Almost half of those 512 entries would have been unused in most
>>>> cases. How about, e.g. 352 ? If anyone finds this value too low
>>>> they could always submit a patch like this one. IMHO with 352 or
>>>> 392 there would be sufficient margin.
>>>
>> Hmm...
>>
>>> I agree. Again, I do not have any reservations here. I just went with
>>> maintainer's choice which was a superset of your and Tomasz's
>>> suggestions :)
>
> If you have another opinion on this, please let me know before sending fixes
> for 3.11 probably tomorrow morning in my time.

I'm OK with that change. Sorry for the trouble.

--
Thanks,
Sylwester


From lee.jones at linaro.org  Wed Jul 24 08:39:31 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Jul 2013 13:39:31 +0100
Subject: [PATCH v2 07/22] ARM: Exynos4210: Remove '0x's from Exynos4110 DTSI
 file
In-Reply-To: <1374490361-25769-7-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-7-git-send-email-lee.jones@linaro.org>
Message-ID: <20130724123931.GL26801@laptop>

... for the sake of consistency and assumed convention.
    
Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index b7f358a..53e2527 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -72,7 +72,7 @@
                };
        };
 
-       clock: clock-controller at 0x10030000 {
+       clock: clock-controller at 10030000 {
                compatible = "samsung,exynos4210-clock";
                reg = <0x10030000 0x20000>;
                #clock-cells = <1>;


From kgene at kernel.org  Wed Jul 24 08:59:45 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 24 Jul 2013 21:59:45 +0900
Subject: [PATCH v2 6/6] ARM: S3C24XX: Convert s3c2416 and s3c2443 to common
 clock framework
In-Reply-To: <2236509.stVfXyPhpt@amdc1227>
References: <201307100057.06061.heiko@sntech.de>
 <201307100100.28992.heiko@sntech.de>
 <02cf01ce81f3$6777e5f0$3667b1d0$%kim@samsung.com>
 <2236509.stVfXyPhpt@amdc1227>
Message-ID: <0ee601ce886d$abb6a690$0323f3b0$@org>

Tomasz Figa wrote:

[...]

> > > +	timer at 51000000 {
> > > +		clocks = <&clocks PCLK_PWM>;
> >
> > +		clocks = <&clock PCLK_PWM>;
> >
> > And I'm not sure using definition PCLK_PWM is better here...
> 
> Care to explain your doubts about it? I think this is fine.
> 
I mean I don't know why someone use a hard value(number) and someone use the
definition...

- Kukjin



From kgene.kim at samsung.com  Wed Jul 24 09:00:05 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Wed, 24 Jul 2013 22:00:05 +0900
Subject: [PATCH v3 00/13] ARM: dts: Add camera and magnetometer support for
 TRATS(2) board
In-Reply-To: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <0ee701ce886d$b7bc5930$27350b90$%kim@samsung.com>

Sylwester Nawrocki wrote:
> 
> This patch series includes some fixes and extensions to the Exynos dts
> files to add the camera and magnetometer sensor support for the TRATS
> and TRATS2 board. It depends on a patch from Tomasz adding initial
> TRATS2 board dts file [1].
> 
Already it is in my tree :)

> Comparing to the previous version of this patch set I've added a few
> more patches, for the Exynos4210 based TRATS board and a patch adding
> MIPI CSIS/DSIM PHY provider nodes and related properties to the PHY
> consumer nodes.
> 
> This series has been tested with the S5K6A3/FIMC-IS and S5K5BAFX
> (front facing) cameras on top of next-20130627 tag. It can be found
> also at:
> http://git.linuxtv.org/snawrocki/samsung.git/next-20130627-dts-trats-v3
> 
> Detailed changes since v2 are listed in each patch.
> 
> Changes since v1:
>  - enabled pull down in cam-port-{a, b}-clk-idle nodes (1/8)
>  - added node alias for i2c-gpio at 0 I2C controller node (7/8).
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg253184.html
> 
> Andrzej Hajda (2):
>   ARM: dts: Add Exynos4210 SoC camera port pinctrl nodes
>   ARM: dts: Add S5K5BA sensor regulator definitions for Trats board
> 
> Jacek Anaszewski (1):
>   ARM: dts: Add AK8975 device node for Exynos4412 TRATS2 board
> 
> Sylwester Nawrocki (10):
>   ARM: dts: Correct camera pinctrl nodes for Exynos4x12 SoCs
>   ARM: dts: Add pinctrl entries for Exynos4x12 FIMC-IS peripherals
>   ARM: dts: Add ISP power domain node for Exynos4x12
>   ARM: dts: Use generic DMA bindings for Exynos4 SPI devices
>   ARM: dts: Add camera subsystem device nodes to exynos4.dtsi
>   ARM: dts: Add camera subsystem nodes to exynos4x12.dtsi
>   ARM: dts: Add camera device nodes for Exynos4412 TRATS2 board
>   ARM: dts: Add camera device nodes for Exynos4210 SoCs
>   ARM: dts: Add FIMC nodes for Exynos4210 Trats board
>   ARM: dts: Add MIPI PHY node to exynos4.dtsi
> 
>  arch/arm/boot/dts/exynos4.dtsi            |  102
++++++++++++++++++++++++--
>  arch/arm/boot/dts/exynos4210-pinctrl.dtsi |   23 ++++++
>  arch/arm/boot/dts/exynos4210-trats.dts    |  103
++++++++++++++++++++++---
> --
>  arch/arm/boot/dts/exynos4210.dtsi         |   30 ++++++++
>  arch/arm/boot/dts/exynos4412-trats2.dts   |  110
> +++++++++++++++++++++++++++++
>  arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |   61 ++++++++++++++--
>  arch/arm/boot/dts/exynos4x12.dtsi         |  103
+++++++++++++++++++++++++++
>  7 files changed, 503 insertions(+), 29 deletions(-)
> 
> --
> 1.7.9.5

Basically, I'm fine on this series but you said, you will address comments
on some patches :)

Thanks,
Kukjin



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:09:26 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:09:26 +0200
Subject: [PATCH 1/3] sh-pfc: Remove unneeded mach/<soc>.h includes
In-Reply-To: <1374671368-4681-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671368-4681-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671368-4681-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The SoC-specific mach/<soc>.h headers are included needlesly. Don't
include them.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c | 1 -
 drivers/pinctrl/sh-pfc/pfc-r8a7740.c | 1 -
 drivers/pinctrl/sh-pfc/pfc-sh7372.c  | 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index 82bf6ab..2b9c0b3 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -21,7 +21,6 @@
 #include <linux/kernel.h>
 #include <linux/pinctrl/pinconf-generic.h>
 #include <mach/irqs.h>
-#include <mach/r8a73a4.h>
 
 #include "core.h"
 #include "sh_pfc.h"
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7740.c b/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
index f6ea47c..6a7d382 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
@@ -22,7 +22,6 @@
 #include <linux/kernel.h>
 #include <linux/pinctrl/pinconf-generic.h>
 
-#include <mach/r8a7740.h>
 #include <mach/irqs.h>
 
 #include "core.h"
diff --git a/drivers/pinctrl/sh-pfc/pfc-sh7372.c b/drivers/pinctrl/sh-pfc/pfc-sh7372.c
index 6dfb187..1528693 100644
--- a/drivers/pinctrl/sh-pfc/pfc-sh7372.c
+++ b/drivers/pinctrl/sh-pfc/pfc-sh7372.c
@@ -25,7 +25,6 @@
 #include <linux/pinctrl/pinconf-generic.h>
 
 #include <mach/irqs.h>
-#include <mach/sh7372.h>
 
 #include "core.h"
 #include "sh_pfc.h"
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:09:25 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:09:25 +0200
Subject: [PATCH 0/3] sh-pfc: Don't include mach/*.h headers were not required
Message-ID: <1374671368-4681-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Hello,

The (long) road to multiplatform kernels requires getting rid of mach/*.h
headers in device drivers. This patch set removes some of the included mach
headers from the sh-pfc driver. The only remaining one is mach/irqs.h, to get
the irq_pin() macro. This will require more work, see [1] for a discussion of
the issue.

The patches are based on v3.11-rc2. Linus, do you usually pick pinctrl patches
from the list, or should I send you a pull request ?

[1] http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg473450.html

Laurent Pinchart (3):
  sh-pfc: Remove unneeded mach/<soc>.h includes
  sh-pfc: sh7372: Replace <mach/irqs.h> with <linux/sh_intc.h>
  sh-pfc: sh73a0: Remove EXT_IRQ16L and EXT_IRQ16H macros

 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |  1 -
 drivers/pinctrl/sh-pfc/pfc-r8a7740.c |  1 -
 drivers/pinctrl/sh-pfc/pfc-sh7372.c  |  4 +--
 drivers/pinctrl/sh-pfc/pfc-sh73a0.c  | 68 +++++++++++++++++-------------------
 4 files changed, 33 insertions(+), 41 deletions(-)

-- 
Regards,

Laurent Pinchart



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:09:27 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:09:27 +0200
Subject: [PATCH 2/3] sh-pfc: sh7372: Replace <mach/irqs.h> with
 <linux/sh_intc.h>
In-Reply-To: <1374671368-4681-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671368-4681-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671368-4681-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The mach/irqs.h header is included only to get the evt2irq macro
definition. The macro is defined in linux/sh_intc.h, include it directly
instead of the mach-specific header.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-sh7372.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-sh7372.c b/drivers/pinctrl/sh-pfc/pfc-sh7372.c
index 1528693..5a0b445 100644
--- a/drivers/pinctrl/sh-pfc/pfc-sh7372.c
+++ b/drivers/pinctrl/sh-pfc/pfc-sh7372.c
@@ -23,8 +23,7 @@
 #include <linux/io.h>
 #include <linux/kernel.h>
 #include <linux/pinctrl/pinconf-generic.h>
-
-#include <mach/irqs.h>
+#include <linux/sh_intc.h>
 
 #include "core.h"
 #include "sh_pfc.h"
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:09:28 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:09:28 +0200
Subject: [PATCH 3/3] sh-pfc: sh73a0: Remove EXT_IRQ16L and EXT_IRQ16H macros
In-Reply-To: <1374671368-4681-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671368-4681-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671368-4681-4-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The macros expand to irq_pin() calls and where most probably introduced
from a copy&paste of the sh7372 PFC data. Replace them with irq_pin().

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-sh73a0.c | 68 +++++++++++++++++--------------------
 1 file changed, 32 insertions(+), 36 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-sh73a0.c b/drivers/pinctrl/sh-pfc/pfc-sh73a0.c
index 7956df5..d2e8168 100644
--- a/drivers/pinctrl/sh-pfc/pfc-sh73a0.c
+++ b/drivers/pinctrl/sh-pfc/pfc-sh73a0.c
@@ -3674,43 +3674,39 @@ static const struct pinmux_data_reg pinmux_data_regs[] = {
 	{ },
 };
 
-/* External IRQ pins mapped at IRQPIN_BASE */
-#define EXT_IRQ16L(n) irq_pin(n)
-#define EXT_IRQ16H(n) irq_pin(n)
-
 static const struct pinmux_irq pinmux_irqs[] = {
-	PINMUX_IRQ(EXT_IRQ16H(19), 9),
-	PINMUX_IRQ(EXT_IRQ16L(1), 10),
-	PINMUX_IRQ(EXT_IRQ16L(0), 11),
-	PINMUX_IRQ(EXT_IRQ16H(18), 13),
-	PINMUX_IRQ(EXT_IRQ16H(20), 14),
-	PINMUX_IRQ(EXT_IRQ16H(21), 15),
-	PINMUX_IRQ(EXT_IRQ16H(31), 26),
-	PINMUX_IRQ(EXT_IRQ16H(30), 27),
-	PINMUX_IRQ(EXT_IRQ16H(29), 28),
-	PINMUX_IRQ(EXT_IRQ16H(22), 40),
-	PINMUX_IRQ(EXT_IRQ16H(23), 53),
-	PINMUX_IRQ(EXT_IRQ16L(10), 54),
-	PINMUX_IRQ(EXT_IRQ16L(9), 56),
-	PINMUX_IRQ(EXT_IRQ16H(26), 115),
-	PINMUX_IRQ(EXT_IRQ16H(27), 116),
-	PINMUX_IRQ(EXT_IRQ16H(28), 117),
-	PINMUX_IRQ(EXT_IRQ16H(24), 118),
-	PINMUX_IRQ(EXT_IRQ16L(6), 147),
-	PINMUX_IRQ(EXT_IRQ16L(2), 149),
-	PINMUX_IRQ(EXT_IRQ16L(7), 150),
-	PINMUX_IRQ(EXT_IRQ16L(12), 156),
-	PINMUX_IRQ(EXT_IRQ16L(4), 159),
-	PINMUX_IRQ(EXT_IRQ16H(25), 164),
-	PINMUX_IRQ(EXT_IRQ16L(8), 223),
-	PINMUX_IRQ(EXT_IRQ16L(3), 224),
-	PINMUX_IRQ(EXT_IRQ16L(5), 227),
-	PINMUX_IRQ(EXT_IRQ16H(17), 234),
-	PINMUX_IRQ(EXT_IRQ16L(11), 238),
-	PINMUX_IRQ(EXT_IRQ16L(13), 239),
-	PINMUX_IRQ(EXT_IRQ16H(16), 249),
-	PINMUX_IRQ(EXT_IRQ16L(14), 251),
-	PINMUX_IRQ(EXT_IRQ16L(9), 308),
+	PINMUX_IRQ(irq_pin(19), 9),
+	PINMUX_IRQ(irq_pin(1), 10),
+	PINMUX_IRQ(irq_pin(0), 11),
+	PINMUX_IRQ(irq_pin(18), 13),
+	PINMUX_IRQ(irq_pin(20), 14),
+	PINMUX_IRQ(irq_pin(21), 15),
+	PINMUX_IRQ(irq_pin(31), 26),
+	PINMUX_IRQ(irq_pin(30), 27),
+	PINMUX_IRQ(irq_pin(29), 28),
+	PINMUX_IRQ(irq_pin(22), 40),
+	PINMUX_IRQ(irq_pin(23), 53),
+	PINMUX_IRQ(irq_pin(10), 54),
+	PINMUX_IRQ(irq_pin(9), 56),
+	PINMUX_IRQ(irq_pin(26), 115),
+	PINMUX_IRQ(irq_pin(27), 116),
+	PINMUX_IRQ(irq_pin(28), 117),
+	PINMUX_IRQ(irq_pin(24), 118),
+	PINMUX_IRQ(irq_pin(6), 147),
+	PINMUX_IRQ(irq_pin(2), 149),
+	PINMUX_IRQ(irq_pin(7), 150),
+	PINMUX_IRQ(irq_pin(12), 156),
+	PINMUX_IRQ(irq_pin(4), 159),
+	PINMUX_IRQ(irq_pin(25), 164),
+	PINMUX_IRQ(irq_pin(8), 223),
+	PINMUX_IRQ(irq_pin(3), 224),
+	PINMUX_IRQ(irq_pin(5), 227),
+	PINMUX_IRQ(irq_pin(17), 234),
+	PINMUX_IRQ(irq_pin(11), 238),
+	PINMUX_IRQ(irq_pin(13), 239),
+	PINMUX_IRQ(irq_pin(16), 249),
+	PINMUX_IRQ(irq_pin(14), 251),
+	PINMUX_IRQ(irq_pin(9), 308),
 };
 
 /* -----------------------------------------------------------------------------
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:06 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:06 +0200
Subject: [PATCH 00/14] sh-pfc: r8a7790: Various fixes and improvements
Message-ID: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Hello,

Here's a set of 14 assorted sh-pfc fixes, cleanups and improvements for the
r8a7790 platform. There's not much more to tell, the individual patches are
pretty self-descriptive.

Kunihito Higashiyama (1):
  sh-pfc: r8a7790: Add MSIOF pin groups and functions

Laurent Pinchart (2):
  sh-pfc: r8a7790: Sort pin groups and functions alphabetically
  sh-pfc: r8a7790: Add SCIF2 pin groups and functions

Shinobu Uehara (2):
  sh-pfc: r8a7790: Add USB pin groups and functions
  sh-pfc: r8a7790: Add VIN pin groups and functions

Shinya Kuribayashi (9):
  sh-pfc: r8a7790: Rename I2C SDA/SCL pins
  sh-pfc: r8a7790: Remove trailing '_TANS' string from RTS/CTS pins
  sh-pfc: r8a7790: Remove deprecated Ethernet MII/RMII pins
  sh-pfc: r8a7790: Remove deprecated RDS pins
  sh-pfc: r8a7790: Remove deprecated SPV_EVEN pin
  sh-pfc: r8a7790: Swap SCIFA2_RXD_B and HRX0_C configurations
  sh-pfc: r8a7790: Add TCLK1 pin configuration support
  sh-pfc: r8a7790: Add SCIF2 pins configuration support
  sh-pfc: r8a7790: Fix miscellaneous pinmux configuration tables
    mistakes

 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 1621 +++++++++++++++++++++-------------
 1 file changed, 994 insertions(+), 627 deletions(-)

-- 
Regards,

Laurent Pinchart



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:07 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:07 +0200
Subject: [PATCH 01/14] sh-pfc: r8a7790: Rename I2C SDA/SCL pins
In-Reply-To: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671720-8794-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

From: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>

The I2C pins have been renamed in the datasheet, rename them here as
well.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 208 +++++++++++++++++------------------
 1 file changed, 104 insertions(+), 104 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index 14f3ec2..46b3fdf 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -168,9 +168,9 @@ enum {
 	FN_VI0_R0, FN_VI0_R0_B, FN_RX0_B, FN_D5,
 	FN_SCIFB1_TXD_F, FN_SCIFB0_TXD_C, FN_VI3_DATA5,
 	FN_VI0_R1, FN_VI0_R1_B, FN_TX0_B, FN_D6,
-	FN_SCL2_C, FN_VI3_DATA6, FN_VI0_R2, FN_VI0_R2_B,
-	FN_SCL2_CIS_C, FN_D7, FN_AD_DI_B, FN_SDA2_C,
-	FN_VI3_DATA7, FN_VI0_R3, FN_VI0_R3_B, FN_SDA2_CIS_C,
+	FN_IIC2_SCL_C, FN_VI3_DATA6, FN_VI0_R2, FN_VI0_R2_B,
+	FN_I2C2_SCL_C, FN_D7, FN_AD_DI_B, FN_IIC2_SDA_C,
+	FN_VI3_DATA7, FN_VI0_R3, FN_VI0_R3_B, FN_I2C2_SDA_C,
 	FN_D8, FN_SCIFA1_SCK_C, FN_AVB_TXD0, FN_MII_TXD0,
 	FN_VI0_G0, FN_VI0_G0_B, FN_VI2_DATA0_VI2_B0,
 
@@ -239,11 +239,11 @@ enum {
 	/* IPSR5 */
 	FN_EX_CS3_N, FN_GPS_MAG, FN_VI3_FIELD, FN_VI1_G1, FN_VI1_G1_B,
 	FN_VI2_R3, FN_EX_CS4_N, FN_MSIOF1_SCK_B, FN_VI3_HSYNC_N,
-	FN_VI2_HSYNC_N, FN_SCL1, FN_VI2_HSYNC_N_B,
-	FN_INTC_EN0_N, FN_SCL1_CIS, FN_EX_CS5_N, FN_CAN0_RX,
+	FN_VI2_HSYNC_N, FN_IIC1_SCL, FN_VI2_HSYNC_N_B,
+	FN_INTC_EN0_N, FN_I2C1_SCL, FN_EX_CS5_N, FN_CAN0_RX,
 	FN_MSIOF1_RXD_B, FN_VI3_VSYNC_N, FN_VI1_G2,
-	FN_VI1_G2_B, FN_VI2_R4, FN_SDA1, FN_INTC_EN1_N,
-	FN_SDA1_CIS, FN_BS_N, FN_IETX, FN_HTX1_B,
+	FN_VI1_G2_B, FN_VI2_R4, FN_IIC1_SDA, FN_INTC_EN1_N,
+	FN_I2C1_SDA, FN_BS_N, FN_IETX, FN_HTX1_B,
 	FN_CAN1_TX, FN_DRACK0, FN_IETX_C, FN_RD_N,
 	FN_CAN0_TX, FN_SCIFA0_SCK_B, FN_RD_WR_N, FN_VI1_G3,
 	FN_VI1_G3_B, FN_VI2_R5, FN_SCIFA0_RXD_B,
@@ -267,10 +267,10 @@ enum {
 	FN_MSIOF0_TXD_B, FN_DACK2, FN_IRQ2, FN_INTC_IRQ2_N,
 	FN_SSI_SDATA6_B, FN_HRTS0_N_B, FN_MSIOF0_RXD_B,
 	FN_ETH_CRS_DV, FN_RMII_CRS_DV, FN_STP_ISCLK_0_B,
-	FN_TS_SDEN0_D, FN_GLO_Q0_C, FN_SCL2_E,
-	FN_SCL2_CIS_E, FN_ETH_RX_ER, FN_RMII_RX_ER,
+	FN_TS_SDEN0_D, FN_GLO_Q0_C, FN_IIC2_SCL_E,
+	FN_I2C2_SCL_E, FN_ETH_RX_ER, FN_RMII_RX_ER,
 	FN_STP_ISD_0_B, FN_TS_SPSYNC0_D, FN_GLO_Q1_C,
-	FN_SDA2_E, FN_SDA2_CIS_E, FN_ETH_RXD0, FN_RMII_RXD0,
+	FN_IIC2_SDA_E, FN_I2C2_SDA_E, FN_ETH_RXD0, FN_RMII_RXD0,
 	FN_STP_ISEN_0_B, FN_TS_SDAT0_D, FN_GLO_I0_C,
 	FN_SCIFB1_SCK_G, FN_SCK1_E, FN_ETH_RXD1,
 	FN_RMII_RXD1, FN_HRX0_E, FN_STP_ISSYNC_0_B,
@@ -326,11 +326,11 @@ enum {
 	FN_SD0_DAT2, FN_SCIFB1_CTS_N_B, FN_VI1_DATA4_VI1_B4_B,
 	FN_SD0_DAT3, FN_SCIFB1_RTS_N_B, FN_VI1_DATA5_VI1_B5_B,
 	FN_SD0_CD, FN_MMC0_D6, FN_TS_SDEN0_B, FN_USB0_EXTP,
-	FN_GLO_SCLK, FN_VI1_DATA6_VI1_B6_B, FN_SCL1_B,
-	FN_SCL1_CIS_B, FN_VI2_DATA6_VI2_B6_B, FN_SD0_WP,
+	FN_GLO_SCLK, FN_VI1_DATA6_VI1_B6_B, FN_IIC1_SCL_B,
+	FN_I2C1_SCL_B, FN_VI2_DATA6_VI2_B6_B, FN_SD0_WP,
 	FN_MMC0_D7, FN_TS_SPSYNC0_B, FN_USB0_IDIN,
-	FN_GLO_SDATA, FN_VI1_DATA7_VI1_B7_B, FN_SDA1_B,
-	FN_SDA1_CIS_B, FN_VI2_DATA7_VI2_B7_B, FN_SD1_CLK,
+	FN_GLO_SDATA, FN_VI1_DATA7_VI1_B7_B, FN_IIC1_SDA_B,
+	FN_I2C1_SDA_B, FN_VI2_DATA7_VI2_B7_B, FN_SD1_CLK,
 	FN_AVB_TX_EN, FN_MII_TX_EN, FN_SD1_CMD,
 	FN_AVB_TX_ER, FN_MII_TX_ER, FN_SCIFB0_SCK_B,
 	FN_SD1_DAT0, FN_AVB_TX_CLK, FN_MII_TX_CLK,
@@ -340,12 +340,12 @@ enum {
 	FN_SD1_DAT3, FN_AVB_RXD0, FN_MII_RXD0,
 	FN_SCIFB0_RTS_N_B, FN_SD1_CD, FN_MMC1_D6,
 	FN_TS_SDEN1, FN_USB1_EXTP, FN_GLO_SS, FN_VI0_CLK_B,
-	FN_SCL2_D, FN_SCL2_CIS_D, FN_SIM0_CLK_B,
+	FN_IIC2_SCL_D, FN_I2C2_SCL_D, FN_SIM0_CLK_B,
 	FN_VI3_CLK_B,
 
 	/* IPSR10 */
 	FN_SD1_WP, FN_MMC1_D7, FN_TS_SPSYNC1, FN_USB1_IDIN,
-	FN_GLO_RFON, FN_VI1_CLK_B, FN_SDA2_D, FN_SDA2_CIS_D,
+	FN_GLO_RFON, FN_VI1_CLK_B, FN_IIC2_SDA_D, FN_I2C2_SDA_D,
 	FN_SIM0_D_B, FN_SD2_CLK, FN_MMC0_CLK, FN_SIM0_CLK,
 	FN_VI0_DATA0_VI0_B0_B, FN_TS_SDEN0_C, FN_GLO_SCLK_B,
 	FN_VI3_DATA0_B, FN_SD2_CMD, FN_MMC0_CMD, FN_SIM0_D,
@@ -379,9 +379,9 @@ enum {
 	FN_VSP, FN_GLO_Q0, FN_SIM0_RST_B, FN_SD3_WP,
 	FN_MMC1_D5, FN_TS_SCK1, FN_GLO_Q1, FN_FMIN_C,
 	FN_RDS_DATA_B, FN_FMIN_E, FN_RDS_DATA_D, FN_FMIN_F,
-	FN_RDS_DATA_E, FN_MLB_CLK, FN_SCL2_B, FN_SCL2_CIS_B,
-	FN_MLB_SIG, FN_SCIFB1_RXD_D, FN_RX1_C, FN_SDA2_B,
-	FN_SDA2_CIS_B, FN_MLB_DAT, FN_SPV_EVEN,
+	FN_RDS_DATA_E, FN_MLB_CLK, FN_IIC2_SCL_B, FN_I2C2_SCL_B,
+	FN_MLB_SIG, FN_SCIFB1_RXD_D, FN_RX1_C, FN_IIC2_SDA_B,
+	FN_I2C2_SDA_B, FN_MLB_DAT, FN_SPV_EVEN,
 	FN_SCIFB1_TXD_D, FN_TX1_C, FN_BPFCLK_C,
 	FN_RDS_CLK_B, FN_SSI_SCK0129, FN_CAN_CLK_B,
 	FN_MOUT0,
@@ -435,12 +435,12 @@ enum {
 	FN_AUDIO_CLKB, FN_SCIF_CLK, FN_CAN0_RX_D,
 	FN_DVC_MUTE, FN_CAN0_RX_C, FN_CAN_DEBUGOUT15,
 	FN_REMOCON, FN_SCIFA0_SCK, FN_HSCK1, FN_SCK0,
-	FN_MSIOF3_SS2, FN_DU2_DG2, FN_LCDOUT10, FN_SDA1_C,
-	FN_SDA1_CIS_C, FN_SCIFA0_RXD, FN_HRX1, FN_RX0,
+	FN_MSIOF3_SS2, FN_DU2_DG2, FN_LCDOUT10, FN_IIC1_SDA_C,
+	FN_I2C1_SDA_C, FN_SCIFA0_RXD, FN_HRX1, FN_RX0,
 	FN_DU2_DR0, FN_LCDOUT0, FN_SCIFA0_TXD, FN_HTX1,
 	FN_TX0, FN_DU2_DR1, FN_LCDOUT1, FN_SCIFA0_CTS_N,
 	FN_HCTS1_N, FN_CTS0_N, FN_MSIOF3_SYNC, FN_DU2_DG3,
-	FN_LCDOUT11, FN_PWM0_B, FN_SCL1_C, FN_SCL1_CIS_C,
+	FN_LCDOUT11, FN_PWM0_B, FN_IIC1_SCL_C, FN_I2C1_SCL_C,
 	FN_SCIFA0_RTS_N, FN_HRTS1_N, FN_RTS0_N_TANS,
 	FN_MSIOF3_SS1, FN_DU2_DG0, FN_LCDOUT8, FN_PWM1_B,
 	FN_SCIFA1_RXD, FN_AD_DI, FN_RX1,
@@ -455,9 +455,9 @@ enum {
 	/* IPSR15 */
 	FN_SCIFA2_SCK, FN_FMCLK, FN_MSIOF3_SCK, FN_DU2_DG7,
 	FN_LCDOUT15, FN_SCIF_CLK_B, FN_SCIFA2_RXD, FN_FMIN,
-	FN_DU2_DB0, FN_LCDOUT16, FN_SCL2, FN_SCL2_CIS,
+	FN_DU2_DB0, FN_LCDOUT16, FN_IIC2_SCL, FN_I2C2_SCL,
 	FN_SCIFA2_TXD, FN_BPFCLK, FN_DU2_DB1, FN_LCDOUT17,
-	FN_SDA2, FN_SDA2_CIS, FN_HSCK0, FN_TS_SDEN0,
+	FN_IIC2_SDA, FN_I2C2_SDA, FN_HSCK0, FN_TS_SDEN0,
 	FN_DU2_DG4, FN_LCDOUT12, FN_HCTS0_N_C, FN_HRX0,
 	FN_DU2_DB2, FN_LCDOUT18, FN_HTX0, FN_DU2_DB3,
 	FN_LCDOUT19, FN_HCTS0_N, FN_SSI_SCK9, FN_DU2_DB4,
@@ -548,9 +548,9 @@ enum {
 	VI0_R0_MARK, VI0_R0_B_MARK, RX0_B_MARK, D5_MARK,
 	SCIFB1_TXD_F_MARK, SCIFB0_TXD_C_MARK, VI3_DATA5_MARK,
 	VI0_R1_MARK, VI0_R1_B_MARK, TX0_B_MARK, D6_MARK,
-	SCL2_C_MARK, VI3_DATA6_MARK, VI0_R2_MARK, VI0_R2_B_MARK,
-	SCL2_CIS_C_MARK, D7_MARK, AD_DI_B_MARK, SDA2_C_MARK,
-	VI3_DATA7_MARK, VI0_R3_MARK, VI0_R3_B_MARK, SDA2_CIS_C_MARK,
+	IIC2_SCL_C_MARK, VI3_DATA6_MARK, VI0_R2_MARK, VI0_R2_B_MARK,
+	I2C2_SCL_C_MARK, D7_MARK, AD_DI_B_MARK, IIC2_SDA_C_MARK,
+	VI3_DATA7_MARK, VI0_R3_MARK, VI0_R3_B_MARK, I2C2_SDA_C_MARK,
 	D8_MARK, SCIFA1_SCK_C_MARK, AVB_TXD0_MARK, MII_TXD0_MARK,
 	VI0_G0_MARK, VI0_G0_B_MARK, VI2_DATA0_VI2_B0_MARK,
 
@@ -615,11 +615,11 @@ enum {
 	EX_CS3_N_MARK, GPS_MAG_MARK, VI3_FIELD_MARK,
 	VI1_G1_MARK, VI1_G1_B_MARK, VI2_R3_MARK,
 	EX_CS4_N_MARK, MSIOF1_SCK_B_MARK, VI3_HSYNC_N_MARK,
-	VI2_HSYNC_N_MARK, SCL1_MARK, VI2_HSYNC_N_B_MARK,
-	INTC_EN0_N_MARK, SCL1_CIS_MARK, EX_CS5_N_MARK, CAN0_RX_MARK,
+	VI2_HSYNC_N_MARK, IIC1_SCL_MARK, VI2_HSYNC_N_B_MARK,
+	INTC_EN0_N_MARK, I2C1_SCL_MARK, EX_CS5_N_MARK, CAN0_RX_MARK,
 	MSIOF1_RXD_B_MARK, VI3_VSYNC_N_MARK, VI1_G2_MARK,
-	VI1_G2_B_MARK, VI2_R4_MARK, SDA1_MARK, INTC_EN1_N_MARK,
-	SDA1_CIS_MARK, BS_N_MARK, IETX_MARK, HTX1_B_MARK,
+	VI1_G2_B_MARK, VI2_R4_MARK, IIC1_SDA_MARK, INTC_EN1_N_MARK,
+	I2C1_SDA_MARK, BS_N_MARK, IETX_MARK, HTX1_B_MARK,
 	CAN1_TX_MARK, DRACK0_MARK, IETX_C_MARK, RD_N_MARK,
 	CAN0_TX_MARK, SCIFA0_SCK_B_MARK, RD_WR_N_MARK, VI1_G3_MARK,
 	VI1_G3_B_MARK, VI2_R5_MARK, SCIFA0_RXD_B_MARK,
@@ -642,10 +642,10 @@ enum {
 	MSIOF0_TXD_B_MARK, DACK2_MARK, IRQ2_MARK, INTC_IRQ2_N_MARK,
 	SSI_SDATA6_B_MARK, HRTS0_N_B_MARK, MSIOF0_RXD_B_MARK,
 	ETH_CRS_DV_MARK, RMII_CRS_DV_MARK, STP_ISCLK_0_B_MARK,
-	TS_SDEN0_D_MARK, GLO_Q0_C_MARK, SCL2_E_MARK,
-	SCL2_CIS_E_MARK, ETH_RX_ER_MARK, RMII_RX_ER_MARK,
+	TS_SDEN0_D_MARK, GLO_Q0_C_MARK, IIC2_SCL_E_MARK,
+	I2C2_SCL_E_MARK, ETH_RX_ER_MARK, RMII_RX_ER_MARK,
 	STP_ISD_0_B_MARK, TS_SPSYNC0_D_MARK, GLO_Q1_C_MARK,
-	SDA2_E_MARK, SDA2_CIS_E_MARK, ETH_RXD0_MARK, RMII_RXD0_MARK,
+	IIC2_SDA_E_MARK, I2C2_SDA_E_MARK, ETH_RXD0_MARK, RMII_RXD0_MARK,
 	STP_ISEN_0_B_MARK, TS_SDAT0_D_MARK, GLO_I0_C_MARK,
 	SCIFB1_SCK_G_MARK, SCK1_E_MARK, ETH_RXD1_MARK,
 	RMII_RXD1_MARK, HRX0_E_MARK, STP_ISSYNC_0_B_MARK,
@@ -698,11 +698,11 @@ enum {
 	SD0_DAT2_MARK, SCIFB1_CTS_N_B_MARK, VI1_DATA4_VI1_B4_B_MARK,
 	SD0_DAT3_MARK, SCIFB1_RTS_N_B_MARK, VI1_DATA5_VI1_B5_B_MARK,
 	SD0_CD_MARK, MMC0_D6_MARK, TS_SDEN0_B_MARK, USB0_EXTP_MARK,
-	GLO_SCLK_MARK, VI1_DATA6_VI1_B6_B_MARK, SCL1_B_MARK,
-	SCL1_CIS_B_MARK, VI2_DATA6_VI2_B6_B_MARK, SD0_WP_MARK,
+	GLO_SCLK_MARK, VI1_DATA6_VI1_B6_B_MARK, IIC1_SCL_B_MARK,
+	I2C1_SCL_B_MARK, VI2_DATA6_VI2_B6_B_MARK, SD0_WP_MARK,
 	MMC0_D7_MARK, TS_SPSYNC0_B_MARK, USB0_IDIN_MARK,
-	GLO_SDATA_MARK, VI1_DATA7_VI1_B7_B_MARK, SDA1_B_MARK,
-	SDA1_CIS_B_MARK, VI2_DATA7_VI2_B7_B_MARK, SD1_CLK_MARK,
+	GLO_SDATA_MARK, VI1_DATA7_VI1_B7_B_MARK, IIC1_SDA_B_MARK,
+	I2C1_SDA_B_MARK, VI2_DATA7_VI2_B7_B_MARK, SD1_CLK_MARK,
 	AVB_TX_EN_MARK, MII_TX_EN_MARK, SD1_CMD_MARK,
 	AVB_TX_ER_MARK, MII_TX_ER_MARK, SCIFB0_SCK_B_MARK,
 	SD1_DAT0_MARK, AVB_TX_CLK_MARK, MII_TX_CLK_MARK,
@@ -712,11 +712,11 @@ enum {
 	SD1_DAT3_MARK, AVB_RXD0_MARK, MII_RXD0_MARK,
 	SCIFB0_RTS_N_B_MARK, SD1_CD_MARK, MMC1_D6_MARK,
 	TS_SDEN1_MARK, USB1_EXTP_MARK, GLO_SS_MARK, VI0_CLK_B_MARK,
-	SCL2_D_MARK, SCL2_CIS_D_MARK, SIM0_CLK_B_MARK,
+	IIC2_SCL_D_MARK, I2C2_SCL_D_MARK, SIM0_CLK_B_MARK,
 	VI3_CLK_B_MARK,
 
 	SD1_WP_MARK, MMC1_D7_MARK, TS_SPSYNC1_MARK, USB1_IDIN_MARK,
-	GLO_RFON_MARK, VI1_CLK_B_MARK, SDA2_D_MARK, SDA2_CIS_D_MARK,
+	GLO_RFON_MARK, VI1_CLK_B_MARK, IIC2_SDA_D_MARK, I2C2_SDA_D_MARK,
 	SIM0_D_B_MARK, SD2_CLK_MARK, MMC0_CLK_MARK, SIM0_CLK_MARK,
 	VI0_DATA0_VI0_B0_B_MARK, TS_SDEN0_C_MARK, GLO_SCLK_B_MARK,
 	VI3_DATA0_B_MARK, SD2_CMD_MARK, MMC0_CMD_MARK, SIM0_D_MARK,
@@ -749,9 +749,9 @@ enum {
 	VSP_MARK, GLO_Q0_MARK, SIM0_RST_B_MARK, SD3_WP_MARK,
 	MMC1_D5_MARK, TS_SCK1_MARK, GLO_Q1_MARK, FMIN_C_MARK,
 	RDS_DATA_B_MARK, FMIN_E_MARK, RDS_DATA_D_MARK, FMIN_F_MARK,
-	RDS_DATA_E_MARK, MLB_CLK_MARK, SCL2_B_MARK, SCL2_CIS_B_MARK,
-	MLB_SIG_MARK, SCIFB1_RXD_D_MARK, RX1_C_MARK, SDA2_B_MARK,
-	SDA2_CIS_B_MARK, MLB_DAT_MARK, SPV_EVEN_MARK,
+	RDS_DATA_E_MARK, MLB_CLK_MARK, IIC2_SCL_B_MARK, I2C2_SCL_B_MARK,
+	MLB_SIG_MARK, SCIFB1_RXD_D_MARK, RX1_C_MARK, IIC2_SDA_B_MARK,
+	I2C2_SDA_B_MARK, MLB_DAT_MARK, SPV_EVEN_MARK,
 	SCIFB1_TXD_D_MARK, TX1_C_MARK, BPFCLK_C_MARK,
 	RDS_CLK_B_MARK, SSI_SCK0129_MARK, CAN_CLK_B_MARK,
 	MOUT0_MARK,
@@ -802,12 +802,12 @@ enum {
 	AUDIO_CLKB_MARK, SCIF_CLK_MARK, CAN0_RX_D_MARK,
 	DVC_MUTE_MARK, CAN0_RX_C_MARK, CAN_DEBUGOUT15_MARK,
 	REMOCON_MARK, SCIFA0_SCK_MARK, HSCK1_MARK, SCK0_MARK,
-	MSIOF3_SS2_MARK, DU2_DG2_MARK, LCDOUT10_MARK, SDA1_C_MARK,
-	SDA1_CIS_C_MARK, SCIFA0_RXD_MARK, HRX1_MARK, RX0_MARK,
+	MSIOF3_SS2_MARK, DU2_DG2_MARK, LCDOUT10_MARK, IIC1_SDA_C_MARK,
+	I2C1_SDA_C_MARK, SCIFA0_RXD_MARK, HRX1_MARK, RX0_MARK,
 	DU2_DR0_MARK, LCDOUT0_MARK, SCIFA0_TXD_MARK, HTX1_MARK,
 	TX0_MARK, DU2_DR1_MARK, LCDOUT1_MARK, SCIFA0_CTS_N_MARK,
 	HCTS1_N_MARK, CTS0_N_MARK, MSIOF3_SYNC_MARK, DU2_DG3_MARK,
-	LCDOUT11_MARK, PWM0_B_MARK, SCL1_C_MARK, SCL1_CIS_C_MARK,
+	LCDOUT11_MARK, PWM0_B_MARK, IIC1_SCL_C_MARK, I2C1_SCL_C_MARK,
 	SCIFA0_RTS_N_MARK, HRTS1_N_MARK, RTS0_N_TANS_MARK,
 	MSIOF3_SS1_MARK, DU2_DG0_MARK, LCDOUT8_MARK, PWM1_B_MARK,
 	SCIFA1_RXD_MARK, AD_DI_MARK, RX1_MARK,
@@ -821,9 +821,9 @@ enum {
 
 	SCIFA2_SCK_MARK, FMCLK_MARK, MSIOF3_SCK_MARK, DU2_DG7_MARK,
 	LCDOUT15_MARK, SCIF_CLK_B_MARK, SCIFA2_RXD_MARK, FMIN_MARK,
-	DU2_DB0_MARK, LCDOUT16_MARK, SCL2_MARK, SCL2_CIS_MARK,
+	DU2_DB0_MARK, LCDOUT16_MARK, IIC2_SCL_MARK, I2C2_SCL_MARK,
 	SCIFA2_TXD_MARK, BPFCLK_MARK, DU2_DB1_MARK, LCDOUT17_MARK,
-	SDA2_MARK, SDA2_CIS_MARK, HSCK0_MARK, TS_SDEN0_MARK,
+	IIC2_SDA_MARK, I2C2_SDA_MARK, HSCK0_MARK, TS_SDEN0_MARK,
 	DU2_DG4_MARK, LCDOUT12_MARK, HCTS0_N_C_MARK, HRX0_MARK,
 	DU2_DB2_MARK, LCDOUT18_MARK, HTX0_MARK, DU2_DB3_MARK,
 	LCDOUT19_MARK, HCTS0_N_MARK, SSI_SCK9_MARK, DU2_DB4_MARK,
@@ -892,18 +892,18 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP0_19_16, VI0_R1_B, SEL_VI0_1),
 	PINMUX_IPSR_MODSEL_DATA(IP0_19_16, TX0_B, SEL_SCIF0_1),
 	PINMUX_IPSR_DATA(IP0_22_20, D6),
-	PINMUX_IPSR_MODSEL_DATA(IP0_22_20, SCL2_C, SEL_IIC2_2),
+	PINMUX_IPSR_MODSEL_DATA(IP0_22_20, IIC2_SCL_C, SEL_IIC2_2),
 	PINMUX_IPSR_MODSEL_DATA(IP0_22_20, VI3_DATA6, SEL_VI3_0),
 	PINMUX_IPSR_MODSEL_DATA(IP0_22_20, VI0_R2, SEL_VI0_0),
 	PINMUX_IPSR_MODSEL_DATA(IP0_22_20, VI0_R2_B, SEL_VI0_1),
-	PINMUX_IPSR_MODSEL_DATA(IP0_22_20, SCL2_CIS_C, SEL_I2C2_2),
+	PINMUX_IPSR_MODSEL_DATA(IP0_22_20, I2C2_SCL_C, SEL_I2C2_2),
 	PINMUX_IPSR_DATA(IP0_26_23, D7),
 	PINMUX_IPSR_MODSEL_DATA(IP0_26_23, AD_DI_B, SEL_ADI_1),
-	PINMUX_IPSR_MODSEL_DATA(IP0_26_23, SDA2_C, SEL_IIC2_2),
+	PINMUX_IPSR_MODSEL_DATA(IP0_26_23, IIC2_SDA_C, SEL_IIC2_2),
 	PINMUX_IPSR_MODSEL_DATA(IP0_26_23, VI3_DATA7, SEL_VI3_0),
 	PINMUX_IPSR_MODSEL_DATA(IP0_26_23, VI0_R3, SEL_VI0_0),
 	PINMUX_IPSR_MODSEL_DATA(IP0_26_23, VI0_R3_B, SEL_VI0_1),
-	PINMUX_IPSR_MODSEL_DATA(IP0_26_23, SDA2_CIS_C, SEL_I2C2_2),
+	PINMUX_IPSR_MODSEL_DATA(IP0_26_23, I2C2_SDA_C, SEL_I2C2_2),
 	PINMUX_IPSR_DATA(IP0_30_27, D8),
 	PINMUX_IPSR_MODSEL_DATA(IP0_30_27, SCIFA1_SCK_C, SEL_SCIFA1_2),
 	PINMUX_IPSR_DATA(IP0_30_27, AVB_TXD0),
@@ -1120,10 +1120,10 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP5_5_3, MSIOF1_SCK_B, SEL_SOF1_1),
 	PINMUX_IPSR_DATA(IP5_5_3, VI3_HSYNC_N),
 	PINMUX_IPSR_MODSEL_DATA(IP5_5_3, VI2_HSYNC_N, SEL_VI2_0),
-	PINMUX_IPSR_MODSEL_DATA(IP5_5_3, SCL1, SEL_IIC1_0),
+	PINMUX_IPSR_MODSEL_DATA(IP5_5_3, IIC1_SCL, SEL_IIC1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP5_5_3, VI2_HSYNC_N_B, SEL_VI2_1),
 	PINMUX_IPSR_DATA(IP5_5_3, INTC_EN0_N),
-	PINMUX_IPSR_MODSEL_DATA(IP5_5_3, SCL1_CIS, SEL_I2C1_0),
+	PINMUX_IPSR_MODSEL_DATA(IP5_5_3, I2C1_SCL, SEL_I2C1_0),
 	PINMUX_IPSR_DATA(IP5_9_6, EX_CS5_N),
 	PINMUX_IPSR_MODSEL_DATA(IP5_9_6, CAN0_RX, SEL_CAN0_0),
 	PINMUX_IPSR_MODSEL_DATA(IP5_9_6, MSIOF1_RXD_B, SEL_SOF1_1),
@@ -1131,9 +1131,9 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP5_9_6, VI1_G2, SEL_VI1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP5_9_6, VI1_G2_B, SEL_VI1_1),
 	PINMUX_IPSR_DATA(IP5_9_6, VI2_R4),
-	PINMUX_IPSR_MODSEL_DATA(IP5_9_6, SDA1, SEL_IIC1_0),
+	PINMUX_IPSR_MODSEL_DATA(IP5_9_6, IIC1_SDA, SEL_IIC1_0),
 	PINMUX_IPSR_DATA(IP5_9_6, INTC_EN1_N),
-	PINMUX_IPSR_MODSEL_DATA(IP5_9_6, SDA1_CIS, SEL_I2C1_0),
+	PINMUX_IPSR_MODSEL_DATA(IP5_9_6, I2C1_SDA, SEL_I2C1_0),
 	PINMUX_IPSR_DATA(IP5_12_10, BS_N),
 	PINMUX_IPSR_MODSEL_DATA(IP5_12_10, IETX, SEL_IEB_0),
 	PINMUX_IPSR_MODSEL_DATA(IP5_12_10, HTX1_B, SEL_HSCIF1_1),
@@ -1209,15 +1209,15 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP6_16_14, STP_ISCLK_0_B, SEL_SSP_1),
 	PINMUX_IPSR_MODSEL_DATA(IP6_16_14, TS_SDEN0_D, SEL_TSIF0_3),
 	PINMUX_IPSR_MODSEL_DATA(IP6_16_14, GLO_Q0_C, SEL_GPS_2),
-	PINMUX_IPSR_MODSEL_DATA(IP6_16_14, SCL2_E, SEL_IIC2_4),
-	PINMUX_IPSR_MODSEL_DATA(IP6_16_14, SCL2_CIS_E, SEL_I2C2_4),
+	PINMUX_IPSR_MODSEL_DATA(IP6_16_14, IIC2_SCL_E, SEL_IIC2_4),
+	PINMUX_IPSR_MODSEL_DATA(IP6_16_14, I2C2_SCL_E, SEL_I2C2_4),
 	PINMUX_IPSR_DATA(IP6_19_17, ETH_RX_ER),
 	PINMUX_IPSR_DATA(IP6_19_17, RMII_RX_ER),
 	PINMUX_IPSR_MODSEL_DATA(IP6_19_17, STP_ISD_0_B, SEL_SSP_1),
 	PINMUX_IPSR_MODSEL_DATA(IP6_19_17, TS_SPSYNC0_D, SEL_TSIF0_3),
 	PINMUX_IPSR_MODSEL_DATA(IP6_19_17, GLO_Q1_C, SEL_GPS_2),
-	PINMUX_IPSR_MODSEL_DATA(IP6_19_17, SDA2_E, SEL_IIC2_4),
-	PINMUX_IPSR_MODSEL_DATA(IP6_19_17, SDA2_CIS_E, SEL_I2C2_4),
+	PINMUX_IPSR_MODSEL_DATA(IP6_19_17, IIC2_SDA_E, SEL_IIC2_4),
+	PINMUX_IPSR_MODSEL_DATA(IP6_19_17, I2C2_SDA_E, SEL_I2C2_4),
 	PINMUX_IPSR_DATA(IP6_22_20, ETH_RXD0),
 	PINMUX_IPSR_DATA(IP6_22_20, RMII_RXD0),
 	PINMUX_IPSR_MODSEL_DATA(IP6_22_20, STP_ISEN_0_B, SEL_SSP_1),
@@ -1372,8 +1372,8 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP9_11_8, USB0_EXTP),
 	PINMUX_IPSR_MODSEL_DATA(IP9_11_8, GLO_SCLK, SEL_GPS_0),
 	PINMUX_IPSR_MODSEL_DATA(IP9_11_8, VI1_DATA6_VI1_B6_B, SEL_VI1_1),
-	PINMUX_IPSR_MODSEL_DATA(IP9_11_8, SCL1_B, SEL_IIC1_1),
-	PINMUX_IPSR_MODSEL_DATA(IP9_11_8, SCL1_CIS_B, SEL_I2C1_1),
+	PINMUX_IPSR_MODSEL_DATA(IP9_11_8, IIC1_SCL_B, SEL_IIC1_1),
+	PINMUX_IPSR_MODSEL_DATA(IP9_11_8, I2C1_SCL_B, SEL_I2C1_1),
 	PINMUX_IPSR_MODSEL_DATA(IP9_11_8, VI2_DATA6_VI2_B6_B, SEL_VI2_1),
 	PINMUX_IPSR_DATA(IP9_15_12, SD0_WP),
 	PINMUX_IPSR_DATA(IP9_15_12, MMC0_D7),
@@ -1381,8 +1381,8 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP9_15_12, USB0_IDIN),
 	PINMUX_IPSR_MODSEL_DATA(IP9_15_12, GLO_SDATA, SEL_GPS_0),
 	PINMUX_IPSR_MODSEL_DATA(IP9_15_12, VI1_DATA7_VI1_B7_B, SEL_VI1_1),
-	PINMUX_IPSR_MODSEL_DATA(IP9_15_12, SDA1_B, SEL_IIC1_1),
-	PINMUX_IPSR_MODSEL_DATA(IP9_15_12, SDA1_CIS_B, SEL_I2C1_1),
+	PINMUX_IPSR_MODSEL_DATA(IP9_15_12, IIC1_SDA_B, SEL_IIC1_1),
+	PINMUX_IPSR_MODSEL_DATA(IP9_15_12, I2C1_SDA_B, SEL_I2C1_1),
 	PINMUX_IPSR_MODSEL_DATA(IP9_15_12, VI2_DATA7_VI2_B7_B, SEL_VI2_1),
 	PINMUX_IPSR_DATA(IP9_17_16, SD1_CLK),
 	PINMUX_IPSR_DATA(IP9_17_16, AVB_TX_EN),
@@ -1413,8 +1413,8 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP9_31_28, USB1_EXTP),
 	PINMUX_IPSR_MODSEL_DATA(IP9_31_28, GLO_SS, SEL_GPS_0),
 	PINMUX_IPSR_MODSEL_DATA(IP9_31_28, VI0_CLK_B, SEL_VI0_1),
-	PINMUX_IPSR_MODSEL_DATA(IP9_31_28, SCL2_D, SEL_IIC2_3),
-	PINMUX_IPSR_MODSEL_DATA(IP9_31_28, SCL2_CIS_D, SEL_I2C2_3),
+	PINMUX_IPSR_MODSEL_DATA(IP9_31_28, IIC2_SCL_D, SEL_IIC2_3),
+	PINMUX_IPSR_MODSEL_DATA(IP9_31_28, I2C2_SCL_D, SEL_I2C2_3),
 	PINMUX_IPSR_MODSEL_DATA(IP9_31_28, SIM0_CLK_B, SEL_SIM_1),
 	PINMUX_IPSR_MODSEL_DATA(IP9_31_28, VI3_CLK_B, SEL_VI3_1),
 
@@ -1424,8 +1424,8 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP10_3_0, USB1_IDIN),
 	PINMUX_IPSR_MODSEL_DATA(IP10_3_0, GLO_RFON, SEL_GPS_0),
 	PINMUX_IPSR_MODSEL_DATA(IP10_3_0, VI1_CLK_B, SEL_VI1_1),
-	PINMUX_IPSR_MODSEL_DATA(IP10_3_0, SDA2_D, SEL_IIC2_3),
-	PINMUX_IPSR_MODSEL_DATA(IP10_3_0, SDA2_CIS_D, SEL_I2C2_3),
+	PINMUX_IPSR_MODSEL_DATA(IP10_3_0, IIC2_SDA_D, SEL_IIC2_3),
+	PINMUX_IPSR_MODSEL_DATA(IP10_3_0, I2C2_SDA_D, SEL_I2C2_3),
 	PINMUX_IPSR_MODSEL_DATA(IP10_3_0, SIM0_D_B, SEL_SIM_1),
 	PINMUX_IPSR_DATA(IP10_6_4, SD2_CLK),
 	PINMUX_IPSR_DATA(IP10_6_4, MMC0_CLK),
@@ -1534,13 +1534,13 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP11_21_18, FMIN_F, SEL_FM_5),
 	PINMUX_IPSR_MODSEL_DATA(IP11_21_18, RDS_DATA_E, SEL_RDS_4),
 	PINMUX_IPSR_DATA(IP11_23_22, MLB_CLK),
-	PINMUX_IPSR_MODSEL_DATA(IP11_23_22, SCL2_B, SEL_IIC2_1),
-	PINMUX_IPSR_MODSEL_DATA(IP11_23_22, SCL2_CIS_B, SEL_I2C2_1),
+	PINMUX_IPSR_MODSEL_DATA(IP11_23_22, IIC2_SCL_B, SEL_IIC2_1),
+	PINMUX_IPSR_MODSEL_DATA(IP11_23_22, I2C2_SCL_B, SEL_I2C2_1),
 	PINMUX_IPSR_DATA(IP11_26_24, MLB_SIG),
 	PINMUX_IPSR_MODSEL_DATA(IP11_26_24, SCIFB1_RXD_D, SEL_SCIFB1_3),
 	PINMUX_IPSR_MODSEL_DATA(IP11_26_24, RX1_C, SEL_SCIF1_2),
-	PINMUX_IPSR_MODSEL_DATA(IP11_26_24, SDA2_B, SEL_IIC2_1),
-	PINMUX_IPSR_MODSEL_DATA(IP11_26_24, SDA2_CIS_B, SEL_I2C2_1),
+	PINMUX_IPSR_MODSEL_DATA(IP11_26_24, IIC2_SDA_B, SEL_IIC2_1),
+	PINMUX_IPSR_MODSEL_DATA(IP11_26_24, I2C2_SDA_B, SEL_I2C2_1),
 	PINMUX_IPSR_DATA(IP11_29_27, MLB_DAT),
 	PINMUX_IPSR_DATA(IP11_29_27, SPV_EVEN),
 	PINMUX_IPSR_MODSEL_DATA(IP11_29_27, SCIFB1_TXD_D, SEL_SCIFB1_3),
@@ -1690,8 +1690,8 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP14_5_3, MSIOF3_SS2),
 	PINMUX_IPSR_DATA(IP14_5_3, DU2_DG2),
 	PINMUX_IPSR_DATA(IP14_5_3, LCDOUT10),
-	PINMUX_IPSR_MODSEL_DATA(IP14_5_3, SDA1_C, SEL_IIC1_2),
-	PINMUX_IPSR_MODSEL_DATA(IP14_5_3, SDA1_CIS_C, SEL_I2C1_2),
+	PINMUX_IPSR_MODSEL_DATA(IP14_5_3, IIC1_SDA_C, SEL_IIC1_2),
+	PINMUX_IPSR_MODSEL_DATA(IP14_5_3, I2C1_SDA_C, SEL_I2C1_2),
 	PINMUX_IPSR_MODSEL_DATA(IP14_8_6, SCIFA0_RXD, SEL_SCFA_0),
 	PINMUX_IPSR_MODSEL_DATA(IP14_8_6, HRX1, SEL_HSCIF1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP14_8_6, RX0, SEL_SCIF0_0),
@@ -1709,8 +1709,8 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP14_15_12, DU2_DG3),
 	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, LCDOUT11, SEL_HSCIF1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, PWM0_B, SEL_SCIF0_0),
-	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, SCL1_C, SEL_IIC1_2),
-	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, SCL1_CIS_C, SEL_I2C1_2),
+	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, IIC1_SCL_C, SEL_IIC1_2),
+	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, I2C1_SCL_C, SEL_I2C1_2),
 	PINMUX_IPSR_MODSEL_DATA(IP14_18_16, SCIFA0_RTS_N, SEL_SCFA_0),
 	PINMUX_IPSR_MODSEL_DATA(IP14_18_16, HRTS1_N, SEL_HSCIF1_0),
 	PINMUX_IPSR_DATA(IP14_18_16, RTS0_N_TANS),
@@ -1752,20 +1752,20 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP15_5_3, FMIN, SEL_FM_0),
 	PINMUX_IPSR_DATA(IP15_5_3, DU2_DB0),
 	PINMUX_IPSR_DATA(IP15_5_3, LCDOUT16),
-	PINMUX_IPSR_MODSEL_DATA(IP15_5_3, SCL2, SEL_IIC2_0),
-	PINMUX_IPSR_MODSEL_DATA(IP15_5_3, SCL2_CIS, SEL_I2C2_0),
+	PINMUX_IPSR_MODSEL_DATA(IP15_5_3, IIC2_SCL, SEL_IIC2_0),
+	PINMUX_IPSR_MODSEL_DATA(IP15_5_3, I2C2_SCL, SEL_I2C2_0),
 	PINMUX_IPSR_MODSEL_DATA(IP15_8_6, SCIFA2_TXD, SEL_SCIFA2_0),
 	PINMUX_IPSR_MODSEL_DATA(IP15_8_6, BPFCLK, SEL_FM_0),
 	PINMUX_IPSR_DATA(IP15_8_6, DU2_DB1),
 	PINMUX_IPSR_DATA(IP15_8_6, LCDOUT17),
-	PINMUX_IPSR_MODSEL_DATA(IP15_8_6, SDA2, SEL_IIC2_0),
-	PINMUX_IPSR_MODSEL_DATA(IP15_8_6, SDA2_CIS, SEL_I2C2_0),
+	PINMUX_IPSR_MODSEL_DATA(IP15_8_6, IIC2_SDA, SEL_IIC2_0),
+	PINMUX_IPSR_MODSEL_DATA(IP15_8_6, I2C2_SDA, SEL_I2C2_0),
 	PINMUX_IPSR_DATA(IP15_11_9, HSCK0),
 	PINMUX_IPSR_MODSEL_DATA(IP15_11_9, TS_SDEN0, SEL_TSIF0_0),
 	PINMUX_IPSR_DATA(IP15_11_9, DU2_DG4),
 	PINMUX_IPSR_DATA(IP15_11_9, LCDOUT12),
 	PINMUX_IPSR_MODSEL_DATA(IP15_11_9, HCTS0_N_C, SEL_IIC2_0),
-	PINMUX_IPSR_MODSEL_DATA(IP15_11_9, SDA2_CIS, SEL_I2C2_0),
+	PINMUX_IPSR_MODSEL_DATA(IP15_11_9, I2C2_SDA, SEL_I2C2_0),
 	PINMUX_IPSR_MODSEL_DATA(IP15_13_12, HRX0, SEL_HSCIF0_0),
 	PINMUX_IPSR_DATA(IP15_13_12, DU2_DB2),
 	PINMUX_IPSR_DATA(IP15_13_12, LCDOUT18),
@@ -3261,12 +3261,12 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_VI0_G0, FN_VI0_G0_B, FN_VI2_DATA0_VI2_B0,
 		0, 0, 0, 0, 0, 0, 0, 0, 0,
 		/* IP0_26_23 [4] */
-		FN_D7, FN_AD_DI_B, FN_SDA2_C,
-		FN_VI3_DATA7, FN_VI0_R3, FN_VI0_R3_B, FN_SDA2_CIS_C,
+		FN_D7, FN_AD_DI_B, FN_IIC2_SDA_C,
+		FN_VI3_DATA7, FN_VI0_R3, FN_VI0_R3_B, FN_I2C2_SDA_C,
 		0, 0, 0, 0, 0, 0, 0, 0, 0,
 		/* IP0_22_20 [3] */
-		FN_D6, FN_SCL2_C, FN_VI3_DATA6, FN_VI0_R2, FN_VI0_R2_B,
-		FN_SCL2_CIS_C, 0, 0,
+		FN_D6, FN_IIC2_SCL_C, FN_VI3_DATA6, FN_VI0_R2, FN_VI0_R2_B,
+		FN_I2C2_SCL_C, 0, 0,
 		/* IP0_19_16 [4] */
 		FN_D5, FN_SCIFB1_TXD_F, FN_SCIFB0_TXD_C, FN_VI3_DATA5,
 		FN_VI0_R1, FN_VI0_R1_B, FN_TX0_B,
@@ -3448,12 +3448,12 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		0, 0,
 		/* IP5_9_6 [4] */
 		FN_EX_CS5_N, FN_CAN0_RX, FN_MSIOF1_RXD_B, FN_VI3_VSYNC_N,
-		FN_VI1_G2, FN_VI1_G2_B, FN_VI2_R4, FN_SDA1, FN_INTC_EN1_N,
-		FN_SDA1_CIS, 0, 0, 0, 0, 0, 0,
+		FN_VI1_G2, FN_VI1_G2_B, FN_VI2_R4, FN_IIC1_SDA, FN_INTC_EN1_N,
+		FN_I2C1_SDA, 0, 0, 0, 0, 0, 0,
 		/* IP5_5_3 [3] */
 		FN_EX_CS4_N, FN_MSIOF1_SCK_B, FN_VI3_HSYNC_N,
-		FN_VI2_HSYNC_N, FN_SCL1, FN_VI2_HSYNC_N_B,
-		FN_INTC_EN0_N, FN_SCL1_CIS,
+		FN_VI2_HSYNC_N, FN_IIC1_SCL, FN_VI2_HSYNC_N_B,
+		FN_INTC_EN0_N, FN_I2C1_SCL,
 		/* IP5_2_0 [3] */
 		FN_EX_CS3_N, FN_GPS_MAG, FN_VI3_FIELD, FN_VI1_G1, FN_VI1_G1_B,
 		FN_VI2_R3, 0, 0, }
@@ -3474,11 +3474,11 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_GLO_I0_C, FN_SCIFB1_SCK_G, FN_SCK1_E, 0,
 		/* IP6_19_17 [3] */
 		FN_ETH_RX_ER, FN_RMII_RX_ER, FN_STP_ISD_0_B,
-		FN_TS_SPSYNC0_D, FN_GLO_Q1_C, FN_SDA2_E, FN_SDA2_CIS_E, 0,
+		FN_TS_SPSYNC0_D, FN_GLO_Q1_C, FN_IIC2_SDA_E, FN_I2C2_SDA_E, 0,
 		/* IP6_16_14 [3] */
 		FN_ETH_CRS_DV, FN_RMII_CRS_DV, FN_STP_ISCLK_0_B,
-		FN_TS_SDEN0_D, FN_GLO_Q0_C, FN_SCL2_E,
-		FN_SCL2_CIS_E, 0,
+		FN_TS_SDEN0_D, FN_GLO_Q0_C, FN_IIC2_SCL_E,
+		FN_I2C2_SCL_E, 0,
 		/* IP6_13_11 [3] */
 		FN_DACK2, FN_IRQ2, FN_INTC_IRQ2_N,
 		FN_SSI_SDATA6_B, FN_HRTS0_N_B, FN_MSIOF0_RXD_B, 0, 0,
@@ -3577,7 +3577,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 			     4, 2, 2, 2, 2, 2, 2, 4, 4, 2, 2, 2, 2) {
 		/* IP9_31_28 [4] */
 		FN_SD1_CD, FN_MMC1_D6, FN_TS_SDEN1, FN_USB1_EXTP,
-		FN_GLO_SS, FN_VI0_CLK_B, FN_SCL2_D, FN_SCL2_CIS_D,
+		FN_GLO_SS, FN_VI0_CLK_B, FN_IIC2_SCL_D, FN_I2C2_SCL_D,
 		FN_SIM0_CLK_B, FN_VI3_CLK_B, 0, 0, 0, 0, 0, 0,
 		/* IP9_27_26 [2] */
 		FN_SD1_DAT3, FN_AVB_RXD0, FN_MII_RXD0, FN_SCIFB0_RTS_N_B,
@@ -3593,12 +3593,12 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_SD1_CLK, FN_AVB_TX_EN, FN_MII_TX_EN, 0,
 		/* IP9_15_12 [4] */
 		FN_SD0_WP, FN_MMC0_D7, FN_TS_SPSYNC0_B, FN_USB0_IDIN,
-		FN_GLO_SDATA, FN_VI1_DATA7_VI1_B7_B, FN_SDA1_B,
-		FN_SDA1_CIS_B, FN_VI2_DATA7_VI2_B7_B, 0, 0, 0, 0, 0, 0, 0,
+		FN_GLO_SDATA, FN_VI1_DATA7_VI1_B7_B, FN_IIC1_SDA_B,
+		FN_I2C1_SDA_B, FN_VI2_DATA7_VI2_B7_B, 0, 0, 0, 0, 0, 0, 0,
 		/* IP9_11_8 [4] */
 		FN_SD0_CD, FN_MMC0_D6, FN_TS_SDEN0_B, FN_USB0_EXTP,
-		FN_GLO_SCLK, FN_VI1_DATA6_VI1_B6_B, FN_SCL1_B,
-		FN_SCL1_CIS_B, FN_VI2_DATA6_VI2_B6_B, 0, 0, 0, 0, 0, 0, 0,
+		FN_GLO_SCLK, FN_VI1_DATA6_VI1_B6_B, FN_IIC1_SCL_B,
+		FN_I2C1_SCL_B, FN_VI2_DATA6_VI2_B6_B, 0, 0, 0, 0, 0, 0, 0,
 		/* IP9_7_6 [2] */
 		FN_SD0_DAT3, FN_SCIFB1_RTS_N_B, FN_VI1_DATA5_VI1_B5_B, 0,
 		/* IP9_5_4 [2] */
@@ -3644,7 +3644,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_VI3_DATA0_B, 0,
 		/* IP10_3_0 [4] */
 		FN_SD1_WP, FN_MMC1_D7, FN_TS_SPSYNC1, FN_USB1_IDIN,
-		FN_GLO_RFON, FN_VI1_CLK_B, FN_SDA2_D, FN_SDA2_CIS_D,
+		FN_GLO_RFON, FN_VI1_CLK_B, FN_IIC2_SDA_D, FN_I2C2_SDA_D,
 		FN_SIM0_D_B, 0, 0, 0, 0, 0, 0, 0, }
 	},
 	{ PINMUX_CFG_REG_VAR("IPSR11", 0xE606004C, 32,
@@ -3655,10 +3655,10 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_MLB_DAT, FN_SPV_EVEN, FN_SCIFB1_TXD_D, FN_TX1_C, FN_BPFCLK_C,
 		FN_RDS_CLK_B, 0, 0,
 		/* IP11_26_24 [3] */
-		FN_MLB_SIG, FN_SCIFB1_RXD_D, FN_RX1_C, FN_SDA2_B, FN_SDA2_CIS_B,
+		FN_MLB_SIG, FN_SCIFB1_RXD_D, FN_RX1_C, FN_IIC2_SDA_B, FN_I2C2_SDA_B,
 		0, 0, 0,
 		/* IP11_23_22 [2] */
-		FN_MLB_CLK, FN_SCL2_B, FN_SCL2_CIS_B, 0,
+		FN_MLB_CLK, FN_IIC2_SCL_B, FN_I2C2_SCL_B, 0,
 		/* IP11_21_18 [4] */
 		FN_SD3_WP, FN_MMC1_D5, FN_TS_SCK1, FN_GLO_Q1, FN_FMIN_C,
 		FN_RDS_DATA_B, FN_FMIN_E, FN_RDS_DATA_D, FN_FMIN_F,
@@ -3781,7 +3781,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_MSIOF3_SS1, FN_DU2_DG0, FN_LCDOUT8, FN_PWM1_B, 0,
 		/* IP14_15_12 [4] */
 		FN_SCIFA0_CTS_N, FN_HCTS1_N, FN_CTS0_N, FN_MSIOF3_SYNC,
-		FN_DU2_DG3, FN_LCDOUT11, FN_PWM0_B, FN_SCL1_C, FN_SCL1_CIS_C,
+		FN_DU2_DG3, FN_LCDOUT11, FN_PWM0_B, FN_IIC1_SCL_C, FN_I2C1_SCL_C,
 		0, 0, 0, 0, 0, 0, 0,
 		/* IP14_11_9 [3] */
 		FN_SCIFA0_TXD, FN_HTX1, FN_TX0, FN_DU2_DR1, FN_LCDOUT1,
@@ -3791,7 +3791,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		0, 0, 0,
 		/* IP14_5_3 [3] */
 		FN_SCIFA0_SCK, FN_HSCK1, FN_SCK0, FN_MSIOF3_SS2, FN_DU2_DG2,
-		FN_LCDOUT10, FN_SDA1_C, FN_SDA1_CIS_C,
+		FN_LCDOUT10, FN_IIC1_SDA_C, FN_I2C1_SDA_C,
 		/* IP14_2_0 [3] */
 		FN_AUDIO_CLKB, FN_SCIF_CLK, FN_CAN0_RX_D,
 		FN_DVC_MUTE, FN_CAN0_RX_C, FN_CAN_DEBUGOUT15,
@@ -3824,10 +3824,10 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		0, 0, 0,
 		/* IP15_8_6 [3] */
 		FN_SCIFA2_TXD, FN_BPFCLK, 0, FN_DU2_DB1, FN_LCDOUT17,
-		FN_SDA2, FN_SDA2_CIS, 0,
+		FN_IIC2_SDA, FN_I2C2_SDA, 0,
 		/* IP15_5_3 [3] */
 		FN_SCIFA2_RXD, FN_FMIN, 0, FN_DU2_DB0, FN_LCDOUT16,
-		FN_SCL2, FN_SCL2_CIS, 0,
+		FN_IIC2_SCL, FN_I2C2_SCL, 0,
 		/* IP15_2_0 [3] */
 		FN_SCIFA2_SCK, FN_FMCLK, 0, FN_MSIOF3_SCK, FN_DU2_DG7,
 		FN_LCDOUT15, FN_SCIF_CLK_B, 0, }
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:08 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:08 +0200
Subject: [PATCH 02/14] sh-pfc: r8a7790: Remove trailing '_TANS' string from
 RTS/CTS pins
In-Reply-To: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671720-8794-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

From: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>

The RTS/CTS pins have been renamed in the datasheet, rename them here as
well.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index 46b3fdf..6adaa85 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -441,14 +441,14 @@ enum {
 	FN_TX0, FN_DU2_DR1, FN_LCDOUT1, FN_SCIFA0_CTS_N,
 	FN_HCTS1_N, FN_CTS0_N, FN_MSIOF3_SYNC, FN_DU2_DG3,
 	FN_LCDOUT11, FN_PWM0_B, FN_IIC1_SCL_C, FN_I2C1_SCL_C,
-	FN_SCIFA0_RTS_N, FN_HRTS1_N, FN_RTS0_N_TANS,
+	FN_SCIFA0_RTS_N, FN_HRTS1_N, FN_RTS0_N,
 	FN_MSIOF3_SS1, FN_DU2_DG0, FN_LCDOUT8, FN_PWM1_B,
 	FN_SCIFA1_RXD, FN_AD_DI, FN_RX1,
 	FN_DU2_EXODDF_DU2_ODDF_DISP_CDE, FN_QCPV_QDE,
 	FN_SCIFA1_TXD, FN_AD_DO, FN_TX1, FN_DU2_DG1,
 	FN_LCDOUT9, FN_SCIFA1_CTS_N, FN_AD_CLK,
 	FN_CTS1_N, FN_MSIOF3_RXD, FN_DU0_DOTCLKOUT, FN_QCLK,
-	FN_SCIFA1_RTS_N, FN_AD_NCS_N, FN_RTS1_N_TANS,
+	FN_SCIFA1_RTS_N, FN_AD_NCS_N, FN_RTS1_N,
 	FN_MSIOF3_TXD, FN_DU1_DOTCLKOUT, FN_QSTVB_QVE,
 	FN_HRTS0_N_C,
 
@@ -808,14 +808,14 @@ enum {
 	TX0_MARK, DU2_DR1_MARK, LCDOUT1_MARK, SCIFA0_CTS_N_MARK,
 	HCTS1_N_MARK, CTS0_N_MARK, MSIOF3_SYNC_MARK, DU2_DG3_MARK,
 	LCDOUT11_MARK, PWM0_B_MARK, IIC1_SCL_C_MARK, I2C1_SCL_C_MARK,
-	SCIFA0_RTS_N_MARK, HRTS1_N_MARK, RTS0_N_TANS_MARK,
+	SCIFA0_RTS_N_MARK, HRTS1_N_MARK, RTS0_N_MARK,
 	MSIOF3_SS1_MARK, DU2_DG0_MARK, LCDOUT8_MARK, PWM1_B_MARK,
 	SCIFA1_RXD_MARK, AD_DI_MARK, RX1_MARK,
 	DU2_EXODDF_DU2_ODDF_DISP_CDE_MARK, QCPV_QDE_MARK,
 	SCIFA1_TXD_MARK, AD_DO_MARK, TX1_MARK, DU2_DG1_MARK,
 	LCDOUT9_MARK, SCIFA1_CTS_N_MARK, AD_CLK_MARK,
 	CTS1_N_MARK, MSIOF3_RXD_MARK, DU0_DOTCLKOUT_MARK, QCLK_MARK,
-	SCIFA1_RTS_N_MARK, AD_NCS_N_MARK, RTS1_N_TANS_MARK,
+	SCIFA1_RTS_N_MARK, AD_NCS_N_MARK, RTS1_N_MARK,
 	MSIOF3_TXD_MARK, DU1_DOTCLKOUT_MARK, QSTVB_QVE_MARK,
 	HRTS0_N_C_MARK,
 
@@ -1713,7 +1713,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, I2C1_SCL_C, SEL_I2C1_2),
 	PINMUX_IPSR_MODSEL_DATA(IP14_18_16, SCIFA0_RTS_N, SEL_SCFA_0),
 	PINMUX_IPSR_MODSEL_DATA(IP14_18_16, HRTS1_N, SEL_HSCIF1_0),
-	PINMUX_IPSR_DATA(IP14_18_16, RTS0_N_TANS),
+	PINMUX_IPSR_DATA(IP14_18_16, RTS0_N),
 	PINMUX_IPSR_DATA(IP14_18_16, MSIOF3_SS1),
 	PINMUX_IPSR_DATA(IP14_18_16, DU2_DG0),
 	PINMUX_IPSR_DATA(IP14_18_16, LCDOUT8),
@@ -1736,7 +1736,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP14_27_25, QCLK),
 	PINMUX_IPSR_MODSEL_DATA(IP14_30_28, SCIFA1_RTS_N, SEL_SCIFA1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP14_30_28, AD_NCS_N, SEL_ADI_0),
-	PINMUX_IPSR_DATA(IP14_30_28, RTS1_N_TANS),
+	PINMUX_IPSR_DATA(IP14_30_28, RTS1_N),
 	PINMUX_IPSR_MODSEL_DATA(IP14_30_28, MSIOF3_TXD, SEL_SOF3_0),
 	PINMUX_IPSR_DATA(IP14_30_28, DU1_DOTCLKOUT),
 	PINMUX_IPSR_DATA(IP14_30_28, QSTVB_QVE),
@@ -1906,7 +1906,7 @@ static const unsigned int scif0_ctrl_pins[] = {
 	RCAR_GP_PIN(4, 31), RCAR_GP_PIN(4, 30),
 };
 static const unsigned int scif0_ctrl_mux[] = {
-	RTS0_N_TANS_MARK, CTS0_N_MARK,
+	RTS0_N_MARK, CTS0_N_MARK,
 };
 static const unsigned int scif0_data_b_pins[] = {
 	/* RX, TX */
@@ -1935,7 +1935,7 @@ static const unsigned int scif1_ctrl_pins[] = {
 	RCAR_GP_PIN(5, 3), RCAR_GP_PIN(5, 2),
 };
 static const unsigned int scif1_ctrl_mux[] = {
-	RTS1_N_TANS_MARK, CTS1_N_MARK,
+	RTS1_N_MARK, CTS1_N_MARK,
 };
 static const unsigned int scif1_data_b_pins[] = {
 	/* RX, TX */
@@ -3764,7 +3764,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		/* IP14_30 [1] */
 		0, 0,
 		/* IP14_30_28 [3] */
-		FN_SCIFA1_RTS_N, FN_AD_NCS_N, FN_RTS1_N_TANS,
+		FN_SCIFA1_RTS_N, FN_AD_NCS_N, FN_RTS1_N,
 		FN_MSIOF3_TXD, FN_DU1_DOTCLKOUT, FN_QSTVB_QVE,
 		FN_HRTS0_N_C, 0,
 		/* IP14_27_25 [3] */
@@ -3777,7 +3777,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_SCIFA1_RXD, FN_AD_DI, FN_RX1,
 		FN_DU2_EXODDF_DU2_ODDF_DISP_CDE, FN_QCPV_QDE, 0, 0, 0,
 		/* IP14_18_16 [3] */
-		FN_SCIFA0_RTS_N, FN_HRTS1_N, FN_RTS0_N_TANS,
+		FN_SCIFA0_RTS_N, FN_HRTS1_N, FN_RTS0_N,
 		FN_MSIOF3_SS1, FN_DU2_DG0, FN_LCDOUT8, FN_PWM1_B, 0,
 		/* IP14_15_12 [4] */
 		FN_SCIFA0_CTS_N, FN_HCTS1_N, FN_CTS0_N, FN_MSIOF3_SYNC,
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:09 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:09 +0200
Subject: [PATCH 03/14] sh-pfc: r8a7790: Remove deprecated Ethernet MII/RMII
 pins
In-Reply-To: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671720-8794-4-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

From: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>

The pins have been removed from the datasheet, remove them here as well.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 224 +++++++++++++++--------------------
 1 file changed, 94 insertions(+), 130 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index 6adaa85..5fdb715 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -171,15 +171,15 @@ enum {
 	FN_IIC2_SCL_C, FN_VI3_DATA6, FN_VI0_R2, FN_VI0_R2_B,
 	FN_I2C2_SCL_C, FN_D7, FN_AD_DI_B, FN_IIC2_SDA_C,
 	FN_VI3_DATA7, FN_VI0_R3, FN_VI0_R3_B, FN_I2C2_SDA_C,
-	FN_D8, FN_SCIFA1_SCK_C, FN_AVB_TXD0, FN_MII_TXD0,
+	FN_D8, FN_SCIFA1_SCK_C, FN_AVB_TXD0,
 	FN_VI0_G0, FN_VI0_G0_B, FN_VI2_DATA0_VI2_B0,
 
 	/* IPSR1 */
-	FN_D9, FN_SCIFA1_RXD_C, FN_AVB_TXD1, FN_MII_TXD1,
+	FN_D9, FN_SCIFA1_RXD_C, FN_AVB_TXD1,
 	FN_VI0_G1, FN_VI0_G1_B, FN_VI2_DATA1_VI2_B1, FN_D10,
-	FN_SCIFA1_TXD_C, FN_AVB_TXD2, FN_MII_TXD2,
+	FN_SCIFA1_TXD_C, FN_AVB_TXD2,
 	FN_VI0_G2, FN_VI0_G2_B, FN_VI2_DATA2_VI2_B2, FN_D11,
-	FN_SCIFA1_CTS_N_C, FN_AVB_TXD3, FN_MII_TXD3,
+	FN_SCIFA1_CTS_N_C, FN_AVB_TXD3,
 	FN_VI0_G3, FN_VI0_G3_B, FN_VI2_DATA3_VI2_B3,
 	FN_D12, FN_SCIFA1_RTS_N_C, FN_AVB_TXD4,
 	FN_VI0_HSYNC_N, FN_VI0_HSYNC_N_B, FN_VI2_DATA4_VI2_B4,
@@ -266,29 +266,29 @@ enum {
 	FN_DREQ2_N, FN_HSCK1_B, FN_HCTS0_N_B,
 	FN_MSIOF0_TXD_B, FN_DACK2, FN_IRQ2, FN_INTC_IRQ2_N,
 	FN_SSI_SDATA6_B, FN_HRTS0_N_B, FN_MSIOF0_RXD_B,
-	FN_ETH_CRS_DV, FN_RMII_CRS_DV, FN_STP_ISCLK_0_B,
+	FN_ETH_CRS_DV, FN_STP_ISCLK_0_B,
 	FN_TS_SDEN0_D, FN_GLO_Q0_C, FN_IIC2_SCL_E,
-	FN_I2C2_SCL_E, FN_ETH_RX_ER, FN_RMII_RX_ER,
+	FN_I2C2_SCL_E, FN_ETH_RX_ER,
 	FN_STP_ISD_0_B, FN_TS_SPSYNC0_D, FN_GLO_Q1_C,
-	FN_IIC2_SDA_E, FN_I2C2_SDA_E, FN_ETH_RXD0, FN_RMII_RXD0,
+	FN_IIC2_SDA_E, FN_I2C2_SDA_E, FN_ETH_RXD0,
 	FN_STP_ISEN_0_B, FN_TS_SDAT0_D, FN_GLO_I0_C,
 	FN_SCIFB1_SCK_G, FN_SCK1_E, FN_ETH_RXD1,
-	FN_RMII_RXD1, FN_HRX0_E, FN_STP_ISSYNC_0_B,
+	FN_HRX0_E, FN_STP_ISSYNC_0_B,
 	FN_TS_SCK0_D, FN_GLO_I1_C, FN_SCIFB1_RXD_G,
-	FN_RX1_E, FN_ETH_LINK, FN_RMII_LINK, FN_HTX0_E,
+	FN_RX1_E, FN_ETH_LINK, FN_HTX0_E,
 	FN_STP_IVCXO27_0_B, FN_SCIFB1_TXD_G, FN_TX1_E,
-	FN_ETH_REF_CLK, FN_RMII_REF_CLK, FN_HCTS0_N_E,
+	FN_ETH_REF_CLK, FN_HCTS0_N_E,
 	FN_STP_IVCXO27_1_B, FN_HRX0_F,
 
 	/* IPSR7 */
-	FN_ETH_MDIO, FN_RMII_MDIO, FN_HRTS0_N_E,
+	FN_ETH_MDIO, FN_HRTS0_N_E,
 	FN_SIM0_D_C, FN_HCTS0_N_F, FN_ETH_TXD1,
-	FN_RMII_TXD1, FN_HTX0_F, FN_BPFCLK_G, FN_RDS_CLK_F,
-	FN_ETH_TX_EN, FN_RMII_TX_EN, FN_SIM0_CLK_C,
-	FN_HRTS0_N_F, FN_ETH_MAGIC, FN_RMII_MAGIC,
-	FN_SIM0_RST_C, FN_ETH_TXD0, FN_RMII_TXD0,
+	FN_HTX0_F, FN_BPFCLK_G, FN_RDS_CLK_F,
+	FN_ETH_TX_EN, FN_SIM0_CLK_C,
+	FN_HRTS0_N_F, FN_ETH_MAGIC,
+	FN_SIM0_RST_C, FN_ETH_TXD0,
 	FN_STP_ISCLK_1_B, FN_TS_SDEN1_C, FN_GLO_SCLK_C,
-	FN_ETH_MDC, FN_RMII_MDC, FN_STP_ISD_1_B,
+	FN_ETH_MDC, FN_STP_ISD_1_B,
 	FN_TS_SPSYNC1_C, FN_GLO_SDATA_C, FN_PWM0,
 	FN_SCIFA2_SCK_C, FN_STP_ISEN_1_B, FN_TS_SDAT1_C,
 	FN_GLO_SS_C, FN_PWM1, FN_SCIFA2_TXD_C,
@@ -296,26 +296,25 @@ enum {
 	FN_PCMOE_N, FN_PWM2, FN_PWMFSW0, FN_SCIFA2_RXD_C,
 	FN_PCMWE_N, FN_IECLK_C, FN_DU1_DOTCLKIN,
 	FN_AUDIO_CLKC, FN_AUDIO_CLKOUT_C, FN_VI0_CLK,
-	FN_ATACS00_N, FN_AVB_RXD1, FN_MII_RXD1,
+	FN_ATACS00_N, FN_AVB_RXD1,
 	FN_VI0_DATA0_VI0_B0, FN_ATACS10_N, FN_AVB_RXD2,
-	FN_MII_RXD2,
 
 	/* IPSR8 */
 	FN_VI0_DATA1_VI0_B1, FN_ATARD0_N, FN_AVB_RXD3,
-	FN_MII_RXD3, FN_VI0_DATA2_VI0_B2, FN_ATAWR0_N,
+	FN_VI0_DATA2_VI0_B2, FN_ATAWR0_N,
 	FN_AVB_RXD4, FN_VI0_DATA3_VI0_B3, FN_ATADIR0_N,
 	FN_AVB_RXD5, FN_VI0_DATA4_VI0_B4, FN_ATAG0_N,
 	FN_AVB_RXD6, FN_VI0_DATA5_VI0_B5, FN_EX_WAIT1,
 	FN_AVB_RXD7, FN_VI0_DATA6_VI0_B6, FN_AVB_RX_ER,
-	FN_MII_RX_ER, FN_VI0_DATA7_VI0_B7, FN_AVB_RX_CLK,
-	FN_MII_RX_CLK, FN_VI1_CLK, FN_AVB_RX_DV,
-	FN_MII_RX_DV, FN_VI1_DATA0_VI1_B0, FN_SCIFA1_SCK_D,
-	FN_AVB_CRS, FN_MII_CRS, FN_VI1_DATA1_VI1_B1,
-	FN_SCIFA1_RXD_D, FN_AVB_MDC, FN_MII_MDC,
+	FN_VI0_DATA7_VI0_B7, FN_AVB_RX_CLK,
+	FN_VI1_CLK, FN_AVB_RX_DV,
+	FN_VI1_DATA0_VI1_B0, FN_SCIFA1_SCK_D,
+	FN_AVB_CRS, FN_VI1_DATA1_VI1_B1,
+	FN_SCIFA1_RXD_D, FN_AVB_MDC,
 	FN_VI1_DATA2_VI1_B2, FN_SCIFA1_TXD_D, FN_AVB_MDIO,
-	FN_MII_MDIO, FN_VI1_DATA3_VI1_B3, FN_SCIFA1_CTS_N_D,
+	FN_VI1_DATA3_VI1_B3, FN_SCIFA1_CTS_N_D,
 	FN_AVB_GTX_CLK, FN_VI1_DATA4_VI1_B4, FN_SCIFA1_RTS_N_D,
-	FN_AVB_MAGIC, FN_MII_MAGIC, FN_VI1_DATA5_VI1_B5,
+	FN_AVB_MAGIC, FN_VI1_DATA5_VI1_B5,
 	FN_AVB_PHY_INT, FN_VI1_DATA6_VI1_B6, FN_AVB_GTXREFCLK,
 	FN_SD0_CLK, FN_VI1_DATA0_VI1_B0_B, FN_SD0_CMD,
 	FN_SCIFB1_SCK_B, FN_VI1_DATA1_VI1_B1_B,
@@ -331,13 +330,13 @@ enum {
 	FN_MMC0_D7, FN_TS_SPSYNC0_B, FN_USB0_IDIN,
 	FN_GLO_SDATA, FN_VI1_DATA7_VI1_B7_B, FN_IIC1_SDA_B,
 	FN_I2C1_SDA_B, FN_VI2_DATA7_VI2_B7_B, FN_SD1_CLK,
-	FN_AVB_TX_EN, FN_MII_TX_EN, FN_SD1_CMD,
-	FN_AVB_TX_ER, FN_MII_TX_ER, FN_SCIFB0_SCK_B,
-	FN_SD1_DAT0, FN_AVB_TX_CLK, FN_MII_TX_CLK,
+	FN_AVB_TX_EN, FN_SD1_CMD,
+	FN_AVB_TX_ER, FN_SCIFB0_SCK_B,
+	FN_SD1_DAT0, FN_AVB_TX_CLK,
 	FN_SCIFB0_RXD_B, FN_SD1_DAT1, FN_AVB_LINK,
-	FN_MII_LINK, FN_SCIFB0_TXD_B, FN_SD1_DAT2,
-	FN_AVB_COL, FN_MII_COL, FN_SCIFB0_CTS_N_B,
-	FN_SD1_DAT3, FN_AVB_RXD0, FN_MII_RXD0,
+	FN_SCIFB0_TXD_B, FN_SD1_DAT2,
+	FN_AVB_COL, FN_SCIFB0_CTS_N_B,
+	FN_SD1_DAT3, FN_AVB_RXD0,
 	FN_SCIFB0_RTS_N_B, FN_SD1_CD, FN_MMC1_D6,
 	FN_TS_SDEN1, FN_USB1_EXTP, FN_GLO_SS, FN_VI0_CLK_B,
 	FN_IIC2_SCL_D, FN_I2C2_SCL_D, FN_SIM0_CLK_B,
@@ -551,14 +550,14 @@ enum {
 	IIC2_SCL_C_MARK, VI3_DATA6_MARK, VI0_R2_MARK, VI0_R2_B_MARK,
 	I2C2_SCL_C_MARK, D7_MARK, AD_DI_B_MARK, IIC2_SDA_C_MARK,
 	VI3_DATA7_MARK, VI0_R3_MARK, VI0_R3_B_MARK, I2C2_SDA_C_MARK,
-	D8_MARK, SCIFA1_SCK_C_MARK, AVB_TXD0_MARK, MII_TXD0_MARK,
+	D8_MARK, SCIFA1_SCK_C_MARK, AVB_TXD0_MARK,
 	VI0_G0_MARK, VI0_G0_B_MARK, VI2_DATA0_VI2_B0_MARK,
 
-	D9_MARK, SCIFA1_RXD_C_MARK, AVB_TXD1_MARK, MII_TXD1_MARK,
+	D9_MARK, SCIFA1_RXD_C_MARK, AVB_TXD1_MARK,
 	VI0_G1_MARK, VI0_G1_B_MARK, VI2_DATA1_VI2_B1_MARK, D10_MARK,
-	SCIFA1_TXD_C_MARK, AVB_TXD2_MARK, MII_TXD2_MARK,
+	SCIFA1_TXD_C_MARK, AVB_TXD2_MARK,
 	VI0_G2_MARK, VI0_G2_B_MARK, VI2_DATA2_VI2_B2_MARK, D11_MARK,
-	SCIFA1_CTS_N_C_MARK, AVB_TXD3_MARK, MII_TXD3_MARK,
+	SCIFA1_CTS_N_C_MARK, AVB_TXD3_MARK,
 	VI0_G3_MARK, VI0_G3_B_MARK, VI2_DATA3_VI2_B3_MARK,
 	D12_MARK, SCIFA1_RTS_N_C_MARK, AVB_TXD4_MARK,
 	VI0_HSYNC_N_MARK, VI0_HSYNC_N_B_MARK, VI2_DATA4_VI2_B4_MARK,
@@ -641,28 +640,28 @@ enum {
 	DREQ2_N_MARK, HSCK1_B_MARK, HCTS0_N_B_MARK,
 	MSIOF0_TXD_B_MARK, DACK2_MARK, IRQ2_MARK, INTC_IRQ2_N_MARK,
 	SSI_SDATA6_B_MARK, HRTS0_N_B_MARK, MSIOF0_RXD_B_MARK,
-	ETH_CRS_DV_MARK, RMII_CRS_DV_MARK, STP_ISCLK_0_B_MARK,
+	ETH_CRS_DV_MARK, STP_ISCLK_0_B_MARK,
 	TS_SDEN0_D_MARK, GLO_Q0_C_MARK, IIC2_SCL_E_MARK,
-	I2C2_SCL_E_MARK, ETH_RX_ER_MARK, RMII_RX_ER_MARK,
+	I2C2_SCL_E_MARK, ETH_RX_ER_MARK,
 	STP_ISD_0_B_MARK, TS_SPSYNC0_D_MARK, GLO_Q1_C_MARK,
-	IIC2_SDA_E_MARK, I2C2_SDA_E_MARK, ETH_RXD0_MARK, RMII_RXD0_MARK,
+	IIC2_SDA_E_MARK, I2C2_SDA_E_MARK, ETH_RXD0_MARK,
 	STP_ISEN_0_B_MARK, TS_SDAT0_D_MARK, GLO_I0_C_MARK,
 	SCIFB1_SCK_G_MARK, SCK1_E_MARK, ETH_RXD1_MARK,
-	RMII_RXD1_MARK, HRX0_E_MARK, STP_ISSYNC_0_B_MARK,
+	HRX0_E_MARK, STP_ISSYNC_0_B_MARK,
 	TS_SCK0_D_MARK, GLO_I1_C_MARK, SCIFB1_RXD_G_MARK,
-	RX1_E_MARK, ETH_LINK_MARK, RMII_LINK_MARK, HTX0_E_MARK,
+	RX1_E_MARK, ETH_LINK_MARK, HTX0_E_MARK,
 	STP_IVCXO27_0_B_MARK, SCIFB1_TXD_G_MARK, TX1_E_MARK,
-	ETH_REF_CLK_MARK, RMII_REF_CLK_MARK, HCTS0_N_E_MARK,
+	ETH_REF_CLK_MARK, HCTS0_N_E_MARK,
 	STP_IVCXO27_1_B_MARK, HRX0_F_MARK,
 
-	ETH_MDIO_MARK, RMII_MDIO_MARK, HRTS0_N_E_MARK,
+	ETH_MDIO_MARK, HRTS0_N_E_MARK,
 	SIM0_D_C_MARK, HCTS0_N_F_MARK, ETH_TXD1_MARK,
-	RMII_TXD1_MARK, HTX0_F_MARK, BPFCLK_G_MARK, RDS_CLK_F_MARK,
-	ETH_TX_EN_MARK, RMII_TX_EN_MARK, SIM0_CLK_C_MARK,
-	HRTS0_N_F_MARK, ETH_MAGIC_MARK, RMII_MAGIC_MARK,
-	SIM0_RST_C_MARK, ETH_TXD0_MARK, RMII_TXD0_MARK,
+	HTX0_F_MARK, BPFCLK_G_MARK, RDS_CLK_F_MARK,
+	ETH_TX_EN_MARK, SIM0_CLK_C_MARK,
+	HRTS0_N_F_MARK, ETH_MAGIC_MARK,
+	SIM0_RST_C_MARK, ETH_TXD0_MARK,
 	STP_ISCLK_1_B_MARK, TS_SDEN1_C_MARK, GLO_SCLK_C_MARK,
-	ETH_MDC_MARK, RMII_MDC_MARK, STP_ISD_1_B_MARK,
+	ETH_MDC_MARK, STP_ISD_1_B_MARK,
 	TS_SPSYNC1_C_MARK, GLO_SDATA_C_MARK, PWM0_MARK,
 	SCIFA2_SCK_C_MARK, STP_ISEN_1_B_MARK, TS_SDAT1_C_MARK,
 	GLO_SS_C_MARK, PWM1_MARK, SCIFA2_TXD_C_MARK,
@@ -670,25 +669,24 @@ enum {
 	PCMOE_N_MARK, PWM2_MARK, PWMFSW0_MARK, SCIFA2_RXD_C_MARK,
 	PCMWE_N_MARK, IECLK_C_MARK, DU1_DOTCLKIN_MARK,
 	AUDIO_CLKC_MARK, AUDIO_CLKOUT_C_MARK, VI0_CLK_MARK,
-	ATACS00_N_MARK, AVB_RXD1_MARK, MII_RXD1_MARK,
+	ATACS00_N_MARK, AVB_RXD1_MARK,
 	VI0_DATA0_VI0_B0_MARK, ATACS10_N_MARK, AVB_RXD2_MARK,
-	MII_RXD2_MARK,
 
 	VI0_DATA1_VI0_B1_MARK, ATARD0_N_MARK, AVB_RXD3_MARK,
-	MII_RXD3_MARK, VI0_DATA2_VI0_B2_MARK, ATAWR0_N_MARK,
+	VI0_DATA2_VI0_B2_MARK, ATAWR0_N_MARK,
 	AVB_RXD4_MARK, VI0_DATA3_VI0_B3_MARK, ATADIR0_N_MARK,
 	AVB_RXD5_MARK, VI0_DATA4_VI0_B4_MARK, ATAG0_N_MARK,
 	AVB_RXD6_MARK, VI0_DATA5_VI0_B5_MARK, EX_WAIT1_MARK,
 	AVB_RXD7_MARK, VI0_DATA6_VI0_B6_MARK, AVB_RX_ER_MARK,
-	MII_RX_ER_MARK, VI0_DATA7_VI0_B7_MARK, AVB_RX_CLK_MARK,
-	MII_RX_CLK_MARK, VI1_CLK_MARK, AVB_RX_DV_MARK,
-	MII_RX_DV_MARK, VI1_DATA0_VI1_B0_MARK, SCIFA1_SCK_D_MARK,
-	AVB_CRS_MARK, MII_CRS_MARK, VI1_DATA1_VI1_B1_MARK,
-	SCIFA1_RXD_D_MARK, AVB_MDC_MARK, MII_MDC_MARK,
+	VI0_DATA7_VI0_B7_MARK, AVB_RX_CLK_MARK,
+	VI1_CLK_MARK, AVB_RX_DV_MARK,
+	VI1_DATA0_VI1_B0_MARK, SCIFA1_SCK_D_MARK,
+	AVB_CRS_MARK, VI1_DATA1_VI1_B1_MARK,
+	SCIFA1_RXD_D_MARK, AVB_MDC_MARK,
 	VI1_DATA2_VI1_B2_MARK, SCIFA1_TXD_D_MARK, AVB_MDIO_MARK,
-	MII_MDIO_MARK, VI1_DATA3_VI1_B3_MARK, SCIFA1_CTS_N_D_MARK,
+	VI1_DATA3_VI1_B3_MARK, SCIFA1_CTS_N_D_MARK,
 	AVB_GTX_CLK_MARK, VI1_DATA4_VI1_B4_MARK, SCIFA1_RTS_N_D_MARK,
-	AVB_MAGIC_MARK, MII_MAGIC_MARK, VI1_DATA5_VI1_B5_MARK,
+	AVB_MAGIC_MARK, VI1_DATA5_VI1_B5_MARK,
 	AVB_PHY_INT_MARK, VI1_DATA6_VI1_B6_MARK, AVB_GTXREFCLK_MARK,
 	SD0_CLK_MARK, VI1_DATA0_VI1_B0_B_MARK, SD0_CMD_MARK,
 	SCIFB1_SCK_B_MARK, VI1_DATA1_VI1_B1_B_MARK,
@@ -703,13 +701,13 @@ enum {
 	MMC0_D7_MARK, TS_SPSYNC0_B_MARK, USB0_IDIN_MARK,
 	GLO_SDATA_MARK, VI1_DATA7_VI1_B7_B_MARK, IIC1_SDA_B_MARK,
 	I2C1_SDA_B_MARK, VI2_DATA7_VI2_B7_B_MARK, SD1_CLK_MARK,
-	AVB_TX_EN_MARK, MII_TX_EN_MARK, SD1_CMD_MARK,
-	AVB_TX_ER_MARK, MII_TX_ER_MARK, SCIFB0_SCK_B_MARK,
-	SD1_DAT0_MARK, AVB_TX_CLK_MARK, MII_TX_CLK_MARK,
+	AVB_TX_EN_MARK, SD1_CMD_MARK,
+	AVB_TX_ER_MARK, SCIFB0_SCK_B_MARK,
+	SD1_DAT0_MARK, AVB_TX_CLK_MARK,
 	SCIFB0_RXD_B_MARK, SD1_DAT1_MARK, AVB_LINK_MARK,
-	MII_LINK_MARK, SCIFB0_TXD_B_MARK, SD1_DAT2_MARK,
-	AVB_COL_MARK, MII_COL_MARK, SCIFB0_CTS_N_B_MARK,
-	SD1_DAT3_MARK, AVB_RXD0_MARK, MII_RXD0_MARK,
+	SCIFB0_TXD_B_MARK, SD1_DAT2_MARK,
+	AVB_COL_MARK, SCIFB0_CTS_N_B_MARK,
+	SD1_DAT3_MARK, AVB_RXD0_MARK,
 	SCIFB0_RTS_N_B_MARK, SD1_CD_MARK, MMC1_D6_MARK,
 	TS_SDEN1_MARK, USB1_EXTP_MARK, GLO_SS_MARK, VI0_CLK_B_MARK,
 	IIC2_SCL_D_MARK, I2C2_SCL_D_MARK, SIM0_CLK_B_MARK,
@@ -907,7 +905,6 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP0_30_27, D8),
 	PINMUX_IPSR_MODSEL_DATA(IP0_30_27, SCIFA1_SCK_C, SEL_SCIFA1_2),
 	PINMUX_IPSR_DATA(IP0_30_27, AVB_TXD0),
-	PINMUX_IPSR_DATA(IP0_30_27, MII_TXD0),
 	PINMUX_IPSR_MODSEL_DATA(IP0_30_27, VI0_G0, SEL_VI0_0),
 	PINMUX_IPSR_MODSEL_DATA(IP0_30_27, VI0_G0_B, SEL_VI0_1),
 	PINMUX_IPSR_MODSEL_DATA(IP0_30_27, VI2_DATA0_VI2_B0, SEL_VI2_0),
@@ -915,21 +912,18 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP1_3_0, D9),
 	PINMUX_IPSR_MODSEL_DATA(IP1_3_0, SCIFA1_RXD_C, SEL_SCIFA1_2),
 	PINMUX_IPSR_DATA(IP1_3_0, AVB_TXD1),
-	PINMUX_IPSR_DATA(IP1_3_0, MII_TXD1),
 	PINMUX_IPSR_MODSEL_DATA(IP1_3_0, VI0_G1, SEL_VI0_0),
 	PINMUX_IPSR_MODSEL_DATA(IP1_3_0, VI0_G1_B, SEL_VI0_1),
 	PINMUX_IPSR_MODSEL_DATA(IP1_3_0, VI2_DATA1_VI2_B1, SEL_VI2_0),
 	PINMUX_IPSR_DATA(IP1_7_4, D10),
 	PINMUX_IPSR_MODSEL_DATA(IP1_7_4, SCIFA1_TXD_C, SEL_SCIFA1_2),
 	PINMUX_IPSR_DATA(IP1_7_4, AVB_TXD2),
-	PINMUX_IPSR_DATA(IP1_7_4, MII_TXD2),
 	PINMUX_IPSR_MODSEL_DATA(IP1_7_4, VI0_G2, SEL_VI0_0),
 	PINMUX_IPSR_MODSEL_DATA(IP1_7_4, VI0_G2_B, SEL_VI0_1),
 	PINMUX_IPSR_MODSEL_DATA(IP1_7_4, VI2_DATA2_VI2_B2, SEL_VI2_0),
 	PINMUX_IPSR_DATA(IP1_11_8, D11),
 	PINMUX_IPSR_MODSEL_DATA(IP1_11_8, SCIFA1_CTS_N_C, SEL_SCIFA1_2),
 	PINMUX_IPSR_DATA(IP1_11_8, AVB_TXD3),
-	PINMUX_IPSR_DATA(IP1_11_8, MII_TXD3),
 	PINMUX_IPSR_MODSEL_DATA(IP1_11_8, VI0_G3, SEL_VI0_0),
 	PINMUX_IPSR_MODSEL_DATA(IP1_11_8, VI0_G3_B, SEL_VI0_1),
 	PINMUX_IPSR_MODSEL_DATA(IP1_11_8, VI2_DATA3_VI2_B3, SEL_VI2_0),
@@ -1205,28 +1199,24 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP6_13_11, HRTS0_N_B, SEL_HSCIF0_1),
 	PINMUX_IPSR_MODSEL_DATA(IP6_13_11, MSIOF0_RXD_B, SEL_SOF0_1),
 	PINMUX_IPSR_DATA(IP6_16_14, ETH_CRS_DV),
-	PINMUX_IPSR_DATA(IP6_16_14, RMII_CRS_DV),
 	PINMUX_IPSR_MODSEL_DATA(IP6_16_14, STP_ISCLK_0_B, SEL_SSP_1),
 	PINMUX_IPSR_MODSEL_DATA(IP6_16_14, TS_SDEN0_D, SEL_TSIF0_3),
 	PINMUX_IPSR_MODSEL_DATA(IP6_16_14, GLO_Q0_C, SEL_GPS_2),
 	PINMUX_IPSR_MODSEL_DATA(IP6_16_14, IIC2_SCL_E, SEL_IIC2_4),
 	PINMUX_IPSR_MODSEL_DATA(IP6_16_14, I2C2_SCL_E, SEL_I2C2_4),
 	PINMUX_IPSR_DATA(IP6_19_17, ETH_RX_ER),
-	PINMUX_IPSR_DATA(IP6_19_17, RMII_RX_ER),
 	PINMUX_IPSR_MODSEL_DATA(IP6_19_17, STP_ISD_0_B, SEL_SSP_1),
 	PINMUX_IPSR_MODSEL_DATA(IP6_19_17, TS_SPSYNC0_D, SEL_TSIF0_3),
 	PINMUX_IPSR_MODSEL_DATA(IP6_19_17, GLO_Q1_C, SEL_GPS_2),
 	PINMUX_IPSR_MODSEL_DATA(IP6_19_17, IIC2_SDA_E, SEL_IIC2_4),
 	PINMUX_IPSR_MODSEL_DATA(IP6_19_17, I2C2_SDA_E, SEL_I2C2_4),
 	PINMUX_IPSR_DATA(IP6_22_20, ETH_RXD0),
-	PINMUX_IPSR_DATA(IP6_22_20, RMII_RXD0),
 	PINMUX_IPSR_MODSEL_DATA(IP6_22_20, STP_ISEN_0_B, SEL_SSP_1),
 	PINMUX_IPSR_MODSEL_DATA(IP6_22_20, TS_SDAT0_D, SEL_TSIF0_3),
 	PINMUX_IPSR_MODSEL_DATA(IP6_22_20, GLO_I0_C, SEL_GPS_2),
 	PINMUX_IPSR_MODSEL_DATA(IP6_22_20, SCIFB1_SCK_G, SEL_SCIFB1_6),
 	PINMUX_IPSR_MODSEL_DATA(IP6_22_20, SCK1_E, SEL_SCIF1_4),
 	PINMUX_IPSR_DATA(IP6_25_23, ETH_RXD1),
-	PINMUX_IPSR_DATA(IP6_25_23, RMII_RXD1),
 	PINMUX_IPSR_MODSEL_DATA(IP6_25_23, HRX0_E, SEL_HSCIF0_4),
 	PINMUX_IPSR_MODSEL_DATA(IP6_25_23, STP_ISSYNC_0_B, SEL_SSP_1),
 	PINMUX_IPSR_MODSEL_DATA(IP6_25_23, TS_SCK0_D, SEL_TSIF0_3),
@@ -1234,41 +1224,33 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP6_25_23, SCIFB1_RXD_G, SEL_SCIFB1_6),
 	PINMUX_IPSR_MODSEL_DATA(IP6_25_23, RX1_E, SEL_SCIF1_4),
 	PINMUX_IPSR_DATA(IP6_28_26, ETH_LINK),
-	PINMUX_IPSR_DATA(IP6_28_26, RMII_LINK),
 	PINMUX_IPSR_MODSEL_DATA(IP6_28_26, HTX0_E, SEL_HSCIF0_4),
 	PINMUX_IPSR_MODSEL_DATA(IP6_28_26, STP_IVCXO27_0_B, SEL_SSP_1),
 	PINMUX_IPSR_MODSEL_DATA(IP6_28_26, SCIFB1_TXD_G, SEL_SCIFB1_6),
 	PINMUX_IPSR_MODSEL_DATA(IP6_28_26, TX1_E, SEL_SCIF1_4),
 	PINMUX_IPSR_DATA(IP6_31_29, ETH_REF_CLK),
-	PINMUX_IPSR_DATA(IP6_31_29, RMII_REF_CLK),
 	PINMUX_IPSR_MODSEL_DATA(IP6_31_29, HCTS0_N_E, SEL_HSCIF0_4),
 	PINMUX_IPSR_MODSEL_DATA(IP6_31_29, STP_IVCXO27_1_B, SEL_SSP_1),
 	PINMUX_IPSR_MODSEL_DATA(IP6_31_29, HRX0_F, SEL_HSCIF0_5),
 
 	PINMUX_IPSR_DATA(IP7_2_0, ETH_MDIO),
-	PINMUX_IPSR_DATA(IP7_2_0, RMII_MDIO),
 	PINMUX_IPSR_MODSEL_DATA(IP7_2_0, HRTS0_N_E, SEL_HSCIF0_4),
 	PINMUX_IPSR_MODSEL_DATA(IP7_2_0, SIM0_D_C, SEL_SIM_2),
 	PINMUX_IPSR_MODSEL_DATA(IP7_2_0, HCTS0_N_F, SEL_HSCIF0_5),
 	PINMUX_IPSR_DATA(IP7_5_3, ETH_TXD1),
-	PINMUX_IPSR_DATA(IP7_5_3, RMII_TXD1),
 	PINMUX_IPSR_MODSEL_DATA(IP7_5_3, HTX0_F, SEL_HSCIF0_4),
 	PINMUX_IPSR_MODSEL_DATA(IP7_5_3, BPFCLK_G, SEL_SIM_2),
 	PINMUX_IPSR_MODSEL_DATA(IP7_5_3, RDS_CLK_F, SEL_HSCIF0_5),
 	PINMUX_IPSR_DATA(IP7_7_6, ETH_TX_EN),
-	PINMUX_IPSR_DATA(IP7_7_6, RMII_TX_EN),
 	PINMUX_IPSR_MODSEL_DATA(IP7_7_6, SIM0_CLK_C, SEL_SIM_2),
 	PINMUX_IPSR_MODSEL_DATA(IP7_7_6, HRTS0_N_F, SEL_HSCIF0_5),
 	PINMUX_IPSR_DATA(IP7_9_8, ETH_MAGIC),
-	PINMUX_IPSR_DATA(IP7_9_8, RMII_MAGIC),
 	PINMUX_IPSR_MODSEL_DATA(IP7_9_8, SIM0_RST_C, SEL_SIM_2),
 	PINMUX_IPSR_DATA(IP7_12_10, ETH_TXD0),
-	PINMUX_IPSR_DATA(IP7_12_10, RMII_TXD0),
 	PINMUX_IPSR_MODSEL_DATA(IP7_12_10, STP_ISCLK_1_B, SEL_SSP_1),
 	PINMUX_IPSR_MODSEL_DATA(IP7_12_10, TS_SDEN1_C, SEL_TSIF1_2),
 	PINMUX_IPSR_MODSEL_DATA(IP7_12_10, GLO_SCLK_C, SEL_GPS_2),
 	PINMUX_IPSR_DATA(IP7_15_13, ETH_MDC),
-	PINMUX_IPSR_DATA(IP7_15_13, RMII_MDC),
 	PINMUX_IPSR_MODSEL_DATA(IP7_15_13, STP_ISD_1_B, SEL_SSP_1),
 	PINMUX_IPSR_MODSEL_DATA(IP7_15_13, TS_SPSYNC1_C, SEL_TSIF1_2),
 	PINMUX_IPSR_MODSEL_DATA(IP7_15_13, GLO_SDATA_C, SEL_GPS_2),
@@ -1294,16 +1276,13 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP7_28_27, VI0_CLK, SEL_VI0_0),
 	PINMUX_IPSR_DATA(IP7_28_27, ATACS00_N),
 	PINMUX_IPSR_DATA(IP7_28_27, AVB_RXD1),
-	PINMUX_IPSR_DATA(IP7_28_27, MII_RXD1),
 	PINMUX_IPSR_MODSEL_DATA(IP7_30_29, VI0_DATA0_VI0_B0, SEL_VI0_0),
 	PINMUX_IPSR_DATA(IP7_30_29, ATACS10_N),
 	PINMUX_IPSR_DATA(IP7_30_29, AVB_RXD2),
-	PINMUX_IPSR_DATA(IP7_30_29, MII_RXD2),
 
 	PINMUX_IPSR_MODSEL_DATA(IP8_1_0, VI0_DATA1_VI0_B1, SEL_VI0_0),
 	PINMUX_IPSR_DATA(IP8_1_0, ATARD0_N),
 	PINMUX_IPSR_DATA(IP8_1_0, AVB_RXD3),
-	PINMUX_IPSR_DATA(IP8_1_0, MII_RXD3),
 	PINMUX_IPSR_MODSEL_DATA(IP8_3_2, VI0_DATA2_VI0_B2, SEL_VI0_0),
 	PINMUX_IPSR_DATA(IP8_3_2, ATAWR0_N),
 	PINMUX_IPSR_DATA(IP8_3_2, AVB_RXD4),
@@ -1318,32 +1297,25 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP8_9_8, AVB_RXD7),
 	PINMUX_IPSR_MODSEL_DATA(IP8_11_10, VI0_DATA6_VI0_B6, SEL_VI0_0),
 	PINMUX_IPSR_DATA(IP8_11_10, AVB_RX_ER),
-	PINMUX_IPSR_DATA(IP8_11_10, MII_RX_ER),
 	PINMUX_IPSR_MODSEL_DATA(IP8_13_12, VI0_DATA7_VI0_B7, SEL_VI0_0),
 	PINMUX_IPSR_DATA(IP8_13_12, AVB_RX_CLK),
-	PINMUX_IPSR_DATA(IP8_13_12, MII_RX_CLK),
 	PINMUX_IPSR_MODSEL_DATA(IP8_15_14, VI1_CLK, SEL_VI1_0),
 	PINMUX_IPSR_DATA(IP8_15_14, AVB_RX_DV),
-	PINMUX_IPSR_DATA(IP8_15_14, MII_RX_DV),
 	PINMUX_IPSR_MODSEL_DATA(IP8_17_16, VI1_DATA0_VI1_B0, SEL_VI1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP8_17_16, SCIFA1_SCK_D, SEL_SCIFA1_3),
 	PINMUX_IPSR_DATA(IP8_17_16, AVB_CRS),
-	PINMUX_IPSR_DATA(IP8_17_16, MII_CRS),
 	PINMUX_IPSR_MODSEL_DATA(IP8_19_18, VI1_DATA1_VI1_B1, SEL_VI1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP8_19_18, SCIFA1_RXD_D, SEL_SCIFA1_3),
 	PINMUX_IPSR_DATA(IP8_19_18, AVB_MDC),
-	PINMUX_IPSR_DATA(IP8_19_18, MII_MDC),
 	PINMUX_IPSR_MODSEL_DATA(IP8_21_20, VI1_DATA2_VI1_B2, SEL_VI1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP8_21_20, SCIFA1_TXD_D, SEL_SCIFA1_3),
 	PINMUX_IPSR_DATA(IP8_21_20, AVB_MDIO),
-	PINMUX_IPSR_DATA(IP8_21_20, MII_MDIO),
 	PINMUX_IPSR_MODSEL_DATA(IP8_23_22, VI1_DATA3_VI1_B3, SEL_VI1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP8_23_22, SCIFA1_CTS_N_D, SEL_SCIFA1_3),
 	PINMUX_IPSR_DATA(IP8_23_22, AVB_GTX_CLK),
 	PINMUX_IPSR_MODSEL_DATA(IP8_25_24, VI1_DATA4_VI1_B4, SEL_VI1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP8_25_24, SCIFA1_RTS_N_D, SEL_SCIFA1_3),
 	PINMUX_IPSR_DATA(IP8_25_24, AVB_MAGIC),
-	PINMUX_IPSR_DATA(IP8_25_24, MII_MAGIC),
 	PINMUX_IPSR_MODSEL_DATA(IP8_26, VI1_DATA5_VI1_B5, SEL_VI1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP8_26, AVB_PHY_INT, SEL_SCIFA1_3),
 	PINMUX_IPSR_MODSEL_DATA(IP8_27, VI1_DATA6_VI1_B6, SEL_VI1_0),
@@ -1386,26 +1358,20 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP9_15_12, VI2_DATA7_VI2_B7_B, SEL_VI2_1),
 	PINMUX_IPSR_DATA(IP9_17_16, SD1_CLK),
 	PINMUX_IPSR_DATA(IP9_17_16, AVB_TX_EN),
-	PINMUX_IPSR_DATA(IP9_17_16, MII_TX_EN),
 	PINMUX_IPSR_DATA(IP9_19_18, SD1_CMD),
 	PINMUX_IPSR_DATA(IP9_19_18, AVB_TX_ER),
-	PINMUX_IPSR_DATA(IP9_19_18, MII_TX_ER),
 	PINMUX_IPSR_MODSEL_DATA(IP9_19_18, SCIFB0_SCK_B, SEL_SCIFB_1),
 	PINMUX_IPSR_DATA(IP9_21_20, SD1_DAT0),
 	PINMUX_IPSR_DATA(IP9_21_20, AVB_TX_CLK),
-	PINMUX_IPSR_DATA(IP9_21_20, MII_TX_CLK),
 	PINMUX_IPSR_MODSEL_DATA(IP9_21_20, SCIFB0_RXD_B, SEL_SCIFB_1),
 	PINMUX_IPSR_DATA(IP9_23_22, SD1_DAT1),
 	PINMUX_IPSR_DATA(IP9_23_22, AVB_LINK),
-	PINMUX_IPSR_DATA(IP9_23_22, MII_LINK),
 	PINMUX_IPSR_MODSEL_DATA(IP9_23_22, SCIFB0_TXD_B, SEL_SCIFB_1),
 	PINMUX_IPSR_DATA(IP9_25_24, SD1_DAT2),
 	PINMUX_IPSR_DATA(IP9_25_24, AVB_COL),
-	PINMUX_IPSR_DATA(IP9_25_24, MII_COL),
 	PINMUX_IPSR_MODSEL_DATA(IP9_25_24, SCIFB0_CTS_N_B, SEL_SCIFB_1),
 	PINMUX_IPSR_DATA(IP9_27_26, SD1_DAT3),
 	PINMUX_IPSR_DATA(IP9_27_26, AVB_RXD0),
-	PINMUX_IPSR_DATA(IP9_27_26, MII_RXD0),
 	PINMUX_IPSR_MODSEL_DATA(IP9_27_26, SCIFB0_RTS_N_B, SEL_SCIFB_1),
 	PINMUX_IPSR_DATA(IP9_31_28, SD1_CD),
 	PINMUX_IPSR_DATA(IP9_31_28, MMC1_D6),
@@ -3257,7 +3223,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		/* IP0_31 [1] */
 		0, 0,
 		/* IP0_30_27 [4] */
-		FN_D8, FN_SCIFA1_SCK_C, FN_AVB_TXD0, FN_MII_TXD0,
+		FN_D8, FN_SCIFA1_SCK_C, FN_AVB_TXD0, 0,
 		FN_VI0_G0, FN_VI0_G0_B, FN_VI2_DATA0_VI2_B0,
 		0, 0, 0, 0, 0, 0, 0, 0, 0,
 		/* IP0_26_23 [4] */
@@ -3313,15 +3279,15 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_VI0_HSYNC_N, FN_VI0_HSYNC_N_B, FN_VI2_DATA4_VI2_B4,
 		0, 0,
 		/* IP1_11_8 [4] */
-		FN_D11, FN_SCIFA1_CTS_N_C, FN_AVB_TXD3, FN_MII_TXD3,
+		FN_D11, FN_SCIFA1_CTS_N_C, FN_AVB_TXD3, 0,
 		FN_VI0_G3, FN_VI0_G3_B, FN_VI2_DATA3_VI2_B3,
 		0, 0, 0, 0, 0, 0, 0, 0, 0,
 		/* IP1_7_4 [4] */
-		FN_D10, FN_SCIFA1_TXD_C, FN_AVB_TXD2, FN_MII_TXD2,
+		FN_D10, FN_SCIFA1_TXD_C, FN_AVB_TXD2, 0,
 		FN_VI0_G2, FN_VI0_G2_B, FN_VI2_DATA2_VI2_B2,
 		0, 0, 0, 0, 0, 0, 0, 0, 0,
 		/* IP1_3_0 [4] */
-		FN_D9, FN_SCIFA1_RXD_C, FN_AVB_TXD1, FN_MII_TXD1,
+		FN_D9, FN_SCIFA1_RXD_C, FN_AVB_TXD1, 0,
 		FN_VI0_G1, FN_VI0_G1_B, FN_VI2_DATA1_VI2_B1,
 		0, 0, 0, 0, 0, 0, 0, 0, 0, }
 	},
@@ -3461,22 +3427,22 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 	{ PINMUX_CFG_REG_VAR("IPSR6", 0xE6060038, 32,
 			     3, 3, 3, 3, 3, 3, 3, 2, 3, 3, 3) {
 		/* IP6_31_29 [3] */
-		FN_ETH_REF_CLK, FN_RMII_REF_CLK, FN_HCTS0_N_E,
+		FN_ETH_REF_CLK, 0, FN_HCTS0_N_E,
 		FN_STP_IVCXO27_1_B, FN_HRX0_F, 0, 0, 0,
 		/* IP6_28_26 [3] */
-		FN_ETH_LINK, FN_RMII_LINK, FN_HTX0_E,
+		FN_ETH_LINK, 0, FN_HTX0_E,
 		FN_STP_IVCXO27_0_B, FN_SCIFB1_TXD_G, FN_TX1_E, 0, 0,
 		/* IP6_25_23 [3] */
-		FN_ETH_RXD1, FN_RMII_RXD1, FN_HRX0_E, FN_STP_ISSYNC_0_B,
+		FN_ETH_RXD1, 0, FN_HRX0_E, FN_STP_ISSYNC_0_B,
 		FN_TS_SCK0_D, FN_GLO_I1_C, FN_SCIFB1_RXD_G, FN_RX1_E,
 		/* IP6_22_20 [3] */
-		FN_ETH_RXD0, FN_RMII_RXD0, FN_STP_ISEN_0_B, FN_TS_SDAT0_D,
+		FN_ETH_RXD0, 0, FN_STP_ISEN_0_B, FN_TS_SDAT0_D,
 		FN_GLO_I0_C, FN_SCIFB1_SCK_G, FN_SCK1_E, 0,
 		/* IP6_19_17 [3] */
-		FN_ETH_RX_ER, FN_RMII_RX_ER, FN_STP_ISD_0_B,
+		FN_ETH_RX_ER, 0, FN_STP_ISD_0_B,
 		FN_TS_SPSYNC0_D, FN_GLO_Q1_C, FN_IIC2_SDA_E, FN_I2C2_SDA_E, 0,
 		/* IP6_16_14 [3] */
-		FN_ETH_CRS_DV, FN_RMII_CRS_DV, FN_STP_ISCLK_0_B,
+		FN_ETH_CRS_DV, 0, FN_STP_ISCLK_0_B,
 		FN_TS_SDEN0_D, FN_GLO_Q0_C, FN_IIC2_SCL_E,
 		FN_I2C2_SCL_E, 0,
 		/* IP6_13_11 [3] */
@@ -3499,10 +3465,9 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		/* IP7_31 [1] */
 		0, 0,
 		/* IP7_30_29 [2] */
-		FN_VI0_DATA0_VI0_B0, FN_ATACS10_N, FN_AVB_RXD2,
-		FN_MII_RXD2,
+		FN_VI0_DATA0_VI0_B0, FN_ATACS10_N, FN_AVB_RXD2, 0,
 		/* IP7_28_27 [2] */
-		FN_VI0_CLK, FN_ATACS00_N, FN_AVB_RXD1, FN_MII_RXD1,
+		FN_VI0_CLK, FN_ATACS00_N, FN_AVB_RXD1, 0,
 		/* IP7_26_25 [2] */
 		FN_DU1_DOTCLKIN, FN_AUDIO_CLKC, FN_AUDIO_CLKOUT_C, 0,
 		/* IP7_24_22 [3] */
@@ -3515,20 +3480,20 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_PWM0, FN_SCIFA2_SCK_C, FN_STP_ISEN_1_B, FN_TS_SDAT1_C,
 		FN_GLO_SS_C, 0, 0, 0,
 		/* IP7_15_13 [3] */
-		FN_ETH_MDC, FN_RMII_MDC, FN_STP_ISD_1_B,
+		FN_ETH_MDC, 0, FN_STP_ISD_1_B,
 		FN_TS_SPSYNC1_C, FN_GLO_SDATA_C, 0, 0, 0,
 		/* IP7_12_10 [3] */
-		FN_ETH_TXD0, FN_RMII_TXD0, FN_STP_ISCLK_1_B, FN_TS_SDEN1_C,
+		FN_ETH_TXD0, 0, FN_STP_ISCLK_1_B, FN_TS_SDEN1_C,
 		FN_GLO_SCLK_C, 0, 0, 0,
 		/* IP7_9_8 [2] */
-		FN_ETH_MAGIC, FN_RMII_MAGIC, FN_SIM0_RST_C, 0,
+		FN_ETH_MAGIC, 0, FN_SIM0_RST_C, 0,
 		/* IP7_7_6 [2] */
-		FN_ETH_TX_EN, FN_RMII_TX_EN, FN_SIM0_CLK_C, FN_HRTS0_N_F,
+		FN_ETH_TX_EN, 0, FN_SIM0_CLK_C, FN_HRTS0_N_F,
 		/* IP7_5_3 [3] */
-		FN_ETH_TXD1, FN_RMII_TXD1, FN_HTX0_F, FN_BPFCLK_G, FN_RDS_CLK_F,
+		FN_ETH_TXD1, 0, FN_HTX0_F, FN_BPFCLK_G, FN_RDS_CLK_F,
 		0, 0, 0,
 		/* IP7_2_0 [3] */
-		FN_ETH_MDIO, FN_RMII_MDIO, FN_HRTS0_N_E,
+		FN_ETH_MDIO, 0, FN_HRTS0_N_E,
 		FN_SIM0_D_C, FN_HCTS0_N_F, 0, 0, 0, }
 	},
 	{ PINMUX_CFG_REG_VAR("IPSR8", 0xE6060040, 32,
@@ -3546,22 +3511,21 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_VI1_DATA5_VI1_B5, FN_AVB_PHY_INT,
 		/* IP8_25_24 [2] */
 		FN_VI1_DATA4_VI1_B4, FN_SCIFA1_RTS_N_D,
-		FN_AVB_MAGIC, FN_MII_MAGIC,
+		FN_AVB_MAGIC, 0,
 		/* IP8_23_22 [2] */
 		FN_VI1_DATA3_VI1_B3, FN_SCIFA1_CTS_N_D, FN_AVB_GTX_CLK, 0,
 		/* IP8_21_20 [2] */
-		FN_VI1_DATA2_VI1_B2, FN_SCIFA1_TXD_D, FN_AVB_MDIO,
-		FN_MII_MDIO,
+		FN_VI1_DATA2_VI1_B2, FN_SCIFA1_TXD_D, FN_AVB_MDIO, 0,
 		/* IP8_19_18 [2] */
-		FN_VI1_DATA1_VI1_B1, FN_SCIFA1_RXD_D, FN_AVB_MDC, FN_MII_MDC,
+		FN_VI1_DATA1_VI1_B1, FN_SCIFA1_RXD_D, FN_AVB_MDC, 0,
 		/* IP8_17_16 [2] */
-		FN_VI1_DATA0_VI1_B0, FN_SCIFA1_SCK_D, FN_AVB_CRS, FN_MII_CRS,
+		FN_VI1_DATA0_VI1_B0, FN_SCIFA1_SCK_D, FN_AVB_CRS, 0,
 		/* IP8_15_14 [2] */
-		FN_VI1_CLK, FN_AVB_RX_DV, FN_MII_RX_DV, 0,
+		FN_VI1_CLK, FN_AVB_RX_DV, 0, 0,
 		/* IP8_13_12 [2] */
-		FN_VI0_DATA7_VI0_B7, FN_AVB_RX_CLK, FN_MII_RX_CLK, 0,
+		FN_VI0_DATA7_VI0_B7, FN_AVB_RX_CLK, 0, 0,
 		/* IP8_11_10 [2] */
-		FN_VI0_DATA6_VI0_B6, FN_AVB_RX_ER, FN_MII_RX_ER, 0,
+		FN_VI0_DATA6_VI0_B6, FN_AVB_RX_ER, 0, 0,
 		/* IP8_9_8 [2] */
 		FN_VI0_DATA5_VI0_B5, FN_EX_WAIT1, FN_AVB_RXD7, 0,
 		/* IP8_7_6 [2] */
@@ -3571,7 +3535,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		/* IP8_3_2 [2] */
 		FN_VI0_DATA2_VI0_B2, FN_ATAWR0_N, FN_AVB_RXD4, 0,
 		/* IP8_1_0 [2] */
-		FN_VI0_DATA1_VI0_B1, FN_ATARD0_N, FN_AVB_RXD3, FN_MII_RXD3, }
+		FN_VI0_DATA1_VI0_B1, FN_ATARD0_N, FN_AVB_RXD3, 0, }
 	},
 	{ PINMUX_CFG_REG_VAR("IPSR9", 0xE6060044, 32,
 			     4, 2, 2, 2, 2, 2, 2, 4, 4, 2, 2, 2, 2) {
@@ -3580,17 +3544,17 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_GLO_SS, FN_VI0_CLK_B, FN_IIC2_SCL_D, FN_I2C2_SCL_D,
 		FN_SIM0_CLK_B, FN_VI3_CLK_B, 0, 0, 0, 0, 0, 0,
 		/* IP9_27_26 [2] */
-		FN_SD1_DAT3, FN_AVB_RXD0, FN_MII_RXD0, FN_SCIFB0_RTS_N_B,
+		FN_SD1_DAT3, FN_AVB_RXD0, 0, FN_SCIFB0_RTS_N_B,
 		/* IP9_25_24 [2] */
-		FN_SD1_DAT2, FN_AVB_COL, FN_MII_COL, FN_SCIFB0_CTS_N_B,
+		FN_SD1_DAT2, FN_AVB_COL, 0, FN_SCIFB0_CTS_N_B,
 		/* IP9_23_22 [2] */
-		FN_SD1_DAT1, FN_AVB_LINK, FN_MII_LINK, FN_SCIFB0_TXD_B,
+		FN_SD1_DAT1, FN_AVB_LINK, 0, FN_SCIFB0_TXD_B,
 		/* IP9_21_20 [2] */
-		FN_SD1_DAT0, FN_AVB_TX_CLK, FN_MII_TX_CLK, FN_SCIFB0_RXD_B,
+		FN_SD1_DAT0, FN_AVB_TX_CLK, 0, FN_SCIFB0_RXD_B,
 		/* IP9_19_18 [2] */
-		FN_SD1_CMD, FN_AVB_TX_ER, FN_MII_TX_ER, FN_SCIFB0_SCK_B,
+		FN_SD1_CMD, FN_AVB_TX_ER, 0, FN_SCIFB0_SCK_B,
 		/* IP9_17_16 [2] */
-		FN_SD1_CLK, FN_AVB_TX_EN, FN_MII_TX_EN, 0,
+		FN_SD1_CLK, FN_AVB_TX_EN, 0, 0,
 		/* IP9_15_12 [4] */
 		FN_SD0_WP, FN_MMC0_D7, FN_TS_SPSYNC0_B, FN_USB0_IDIN,
 		FN_GLO_SDATA, FN_VI1_DATA7_VI1_B7_B, FN_IIC1_SDA_B,
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:11 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:11 +0200
Subject: [PATCH 05/14] sh-pfc: r8a7790: Remove deprecated SPV_EVEN pin
In-Reply-To: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671720-8794-6-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

From: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>

The pins have been removed from the datasheet, remove them here as well.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index aec961b..350b076 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -380,7 +380,7 @@ enum {
 	FN_FMIN_E, FN_FMIN_F,
 	FN_MLB_CLK, FN_IIC2_SCL_B, FN_I2C2_SCL_B,
 	FN_MLB_SIG, FN_SCIFB1_RXD_D, FN_RX1_C, FN_IIC2_SDA_B,
-	FN_I2C2_SDA_B, FN_MLB_DAT, FN_SPV_EVEN,
+	FN_I2C2_SDA_B, FN_MLB_DAT,
 	FN_SCIFB1_TXD_D, FN_TX1_C, FN_BPFCLK_C,
 	FN_SSI_SCK0129, FN_CAN_CLK_B,
 	FN_MOUT0,
@@ -747,7 +747,7 @@ enum {
 	FMIN_E_MARK, FMIN_F_MARK,
 	MLB_CLK_MARK, IIC2_SCL_B_MARK, I2C2_SCL_B_MARK,
 	MLB_SIG_MARK, SCIFB1_RXD_D_MARK, RX1_C_MARK, IIC2_SDA_B_MARK,
-	I2C2_SDA_B_MARK, MLB_DAT_MARK, SPV_EVEN_MARK,
+	I2C2_SDA_B_MARK, MLB_DAT_MARK,
 	SCIFB1_TXD_D_MARK, TX1_C_MARK, BPFCLK_C_MARK,
 	SSI_SCK0129_MARK, CAN_CLK_B_MARK,
 	MOUT0_MARK,
@@ -1500,7 +1500,6 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP11_26_24, IIC2_SDA_B, SEL_IIC2_1),
 	PINMUX_IPSR_MODSEL_DATA(IP11_26_24, I2C2_SDA_B, SEL_I2C2_1),
 	PINMUX_IPSR_DATA(IP11_29_27, MLB_DAT),
-	PINMUX_IPSR_DATA(IP11_29_27, SPV_EVEN),
 	PINMUX_IPSR_MODSEL_DATA(IP11_29_27, SCIFB1_TXD_D, SEL_SCIFB1_3),
 	PINMUX_IPSR_MODSEL_DATA(IP11_29_27, TX1_C, SEL_SCIF1_2),
 	PINMUX_IPSR_MODSEL_DATA(IP11_29_27, BPFCLK_C, SEL_FM_2),
@@ -3601,7 +3600,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		/* IP11_31_30 [2] */
 		FN_SSI_SCK0129, FN_CAN_CLK_B, FN_MOUT0, 0,
 		/* IP11_29_27 [3] */
-		FN_MLB_DAT, FN_SPV_EVEN, FN_SCIFB1_TXD_D, FN_TX1_C, FN_BPFCLK_C,
+		FN_MLB_DAT, 0, FN_SCIFB1_TXD_D, FN_TX1_C, FN_BPFCLK_C,
 		0, 0, 0,
 		/* IP11_26_24 [3] */
 		FN_MLB_SIG, FN_SCIFB1_RXD_D, FN_RX1_C, FN_IIC2_SDA_B, FN_I2C2_SDA_B,
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:10 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:10 +0200
Subject: [PATCH 04/14] sh-pfc: r8a7790: Remove deprecated RDS pins
In-Reply-To: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671720-8794-5-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

From: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>

The pins have been removed from the datasheet, remove them here as well.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 84 ++++++++++++++----------------------
 1 file changed, 33 insertions(+), 51 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index 5fdb715..aec961b 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -283,7 +283,7 @@ enum {
 	/* IPSR7 */
 	FN_ETH_MDIO, FN_HRTS0_N_E,
 	FN_SIM0_D_C, FN_HCTS0_N_F, FN_ETH_TXD1,
-	FN_HTX0_F, FN_BPFCLK_G, FN_RDS_CLK_F,
+	FN_HTX0_F, FN_BPFCLK_G,
 	FN_ETH_TX_EN, FN_SIM0_CLK_C,
 	FN_HRTS0_N_F, FN_ETH_MAGIC,
 	FN_SIM0_RST_C, FN_ETH_TXD0,
@@ -353,10 +353,10 @@ enum {
 	FN_SD2_DAT0, FN_MMC0_D0, FN_FMCLK_B,
 	FN_VI0_DATA2_VI0_B2_B, FN_SCIFB1_RXD_E, FN_RX1_D,
 	FN_TS_SDAT0_C, FN_GLO_SS_B, FN_VI3_DATA2_B,
-	FN_SD2_DAT1, FN_MMC0_D1, FN_FMIN_B, FN_RDS_DATA,
+	FN_SD2_DAT1, FN_MMC0_D1, FN_FMIN_B,
 	FN_VI0_DATA3_VI0_B3_B, FN_SCIFB1_TXD_E, FN_TX1_D,
 	FN_TS_SCK0_C, FN_GLO_RFON_B, FN_VI3_DATA3_B,
-	FN_SD2_DAT2, FN_MMC0_D2, FN_BPFCLK_B, FN_RDS_CLK,
+	FN_SD2_DAT2, FN_MMC0_D2, FN_BPFCLK_B,
 	FN_VI0_DATA4_VI0_B4_B, FN_HRX0_D, FN_TS_SDEN1_B,
 	FN_GLO_Q0_B, FN_VI3_DATA4_B, FN_SD2_DAT3,
 	FN_MMC0_D3, FN_SIM0_RST, FN_VI0_DATA5_VI0_B5_B,
@@ -377,12 +377,12 @@ enum {
 	FN_SCKZ, FN_SD3_CD, FN_MMC1_D4, FN_TS_SDAT1,
 	FN_VSP, FN_GLO_Q0, FN_SIM0_RST_B, FN_SD3_WP,
 	FN_MMC1_D5, FN_TS_SCK1, FN_GLO_Q1, FN_FMIN_C,
-	FN_RDS_DATA_B, FN_FMIN_E, FN_RDS_DATA_D, FN_FMIN_F,
-	FN_RDS_DATA_E, FN_MLB_CLK, FN_IIC2_SCL_B, FN_I2C2_SCL_B,
+	FN_FMIN_E, FN_FMIN_F,
+	FN_MLB_CLK, FN_IIC2_SCL_B, FN_I2C2_SCL_B,
 	FN_MLB_SIG, FN_SCIFB1_RXD_D, FN_RX1_C, FN_IIC2_SDA_B,
 	FN_I2C2_SDA_B, FN_MLB_DAT, FN_SPV_EVEN,
 	FN_SCIFB1_TXD_D, FN_TX1_C, FN_BPFCLK_C,
-	FN_RDS_CLK_B, FN_SSI_SCK0129, FN_CAN_CLK_B,
+	FN_SSI_SCK0129, FN_CAN_CLK_B,
 	FN_MOUT0,
 
 	/* IPSR12 */
@@ -409,12 +409,12 @@ enum {
 	/* IPSR13 */
 	FN_SSI_SDATA5, FN_SCIFB1_TXD, FN_IETX_B, FN_DU2_DR2,
 	FN_LCDOUT2, FN_CAN_DEBUGOUT5, FN_SSI_SCK6,
-	FN_SCIFB1_CTS_N, FN_BPFCLK_D, FN_RDS_CLK_C,
+	FN_SCIFB1_CTS_N, FN_BPFCLK_D,
 	FN_DU2_DR3, FN_LCDOUT3, FN_CAN_DEBUGOUT6,
-	FN_BPFCLK_F, FN_RDS_CLK_E, FN_SSI_WS6,
+	FN_BPFCLK_F, FN_SSI_WS6,
 	FN_SCIFB1_RTS_N, FN_CAN0_TX_D, FN_DU2_DR4,
 	FN_LCDOUT4, FN_CAN_DEBUGOUT7, FN_SSI_SDATA6,
-	FN_FMIN_D, FN_RDS_DATA_C, FN_DU2_DR5, FN_LCDOUT5,
+	FN_FMIN_D, FN_DU2_DR5, FN_LCDOUT5,
 	FN_CAN_DEBUGOUT8, FN_SSI_SCK78, FN_STP_IVCXO27_1,
 	FN_SCK1, FN_SCIFA1_SCK, FN_DU2_DR6, FN_LCDOUT6,
 	FN_CAN_DEBUGOUT9, FN_SSI_WS78, FN_STP_ISCLK_1,
@@ -422,8 +422,8 @@ enum {
 	FN_LCDOUT7, FN_CAN_DEBUGOUT10, FN_SSI_SDATA7,
 	FN_STP_ISD_1, FN_SCIFB2_RXD, FN_SCIFA2_RTS_N,
 	FN_TCLK2, FN_QSTVA_QVS, FN_CAN_DEBUGOUT11,
-	FN_BPFCLK_E, FN_RDS_CLK_D, FN_SSI_SDATA7_B,
-	FN_FMIN_G, FN_RDS_DATA_F, FN_SSI_SDATA8,
+	FN_BPFCLK_E, FN_SSI_SDATA7_B,
+	FN_FMIN_G, FN_SSI_SDATA8,
 	FN_STP_ISEN_1, FN_SCIFB2_TXD, FN_CAN0_TX_C,
 	FN_CAN_DEBUGOUT12, FN_SSI_SDATA8_B, FN_SSI_SDATA9,
 	FN_STP_ISSYNC_1, FN_SCIFB2_CTS_N, FN_SSI_WS1,
@@ -514,8 +514,6 @@ enum {
 	FN_SEL_HSCIF0_0, FN_SEL_HSCIF0_1, FN_SEL_HSCIF0_2, FN_SEL_HSCIF0_3,
 	FN_SEL_HSCIF0_4, FN_SEL_HSCIF0_5,
 	FN_SEL_GPS_0, FN_SEL_GPS_1, FN_SEL_GPS_2,
-	FN_SEL_RDS_0, FN_SEL_RDS_1, FN_SEL_RDS_2,
-	FN_SEL_RDS_3, FN_SEL_RDS_4, FN_SEL_RDS_5,
 	FN_SEL_SIM_0, FN_SEL_SIM_1, FN_SEL_SIM_2,
 	FN_SEL_SSI8_0, FN_SEL_SSI8_1, FN_SEL_SSI8_2,
 
@@ -656,7 +654,7 @@ enum {
 
 	ETH_MDIO_MARK, HRTS0_N_E_MARK,
 	SIM0_D_C_MARK, HCTS0_N_F_MARK, ETH_TXD1_MARK,
-	HTX0_F_MARK, BPFCLK_G_MARK, RDS_CLK_F_MARK,
+	HTX0_F_MARK, BPFCLK_G_MARK,
 	ETH_TX_EN_MARK, SIM0_CLK_C_MARK,
 	HRTS0_N_F_MARK, ETH_MAGIC_MARK,
 	SIM0_RST_C_MARK, ETH_TXD0_MARK,
@@ -723,10 +721,10 @@ enum {
 	SD2_DAT0_MARK, MMC0_D0_MARK, FMCLK_B_MARK,
 	VI0_DATA2_VI0_B2_B_MARK, SCIFB1_RXD_E_MARK, RX1_D_MARK,
 	TS_SDAT0_C_MARK, GLO_SS_B_MARK, VI3_DATA2_B_MARK,
-	SD2_DAT1_MARK, MMC0_D1_MARK, FMIN_B_MARK, RDS_DATA_MARK,
+	SD2_DAT1_MARK, MMC0_D1_MARK, FMIN_B_MARK,
 	VI0_DATA3_VI0_B3_B_MARK, SCIFB1_TXD_E_MARK, TX1_D_MARK,
 	TS_SCK0_C_MARK, GLO_RFON_B_MARK, VI3_DATA3_B_MARK,
-	SD2_DAT2_MARK, MMC0_D2_MARK, BPFCLK_B_MARK, RDS_CLK_MARK,
+	SD2_DAT2_MARK, MMC0_D2_MARK, BPFCLK_B_MARK,
 	VI0_DATA4_VI0_B4_B_MARK, HRX0_D_MARK, TS_SDEN1_B_MARK,
 	GLO_Q0_B_MARK, VI3_DATA4_B_MARK, SD2_DAT3_MARK,
 	MMC0_D3_MARK, SIM0_RST_MARK, VI0_DATA5_VI0_B5_B_MARK,
@@ -746,12 +744,12 @@ enum {
 	SCKZ_MARK, SD3_CD_MARK, MMC1_D4_MARK, TS_SDAT1_MARK,
 	VSP_MARK, GLO_Q0_MARK, SIM0_RST_B_MARK, SD3_WP_MARK,
 	MMC1_D5_MARK, TS_SCK1_MARK, GLO_Q1_MARK, FMIN_C_MARK,
-	RDS_DATA_B_MARK, FMIN_E_MARK, RDS_DATA_D_MARK, FMIN_F_MARK,
-	RDS_DATA_E_MARK, MLB_CLK_MARK, IIC2_SCL_B_MARK, I2C2_SCL_B_MARK,
+	FMIN_E_MARK, FMIN_F_MARK,
+	MLB_CLK_MARK, IIC2_SCL_B_MARK, I2C2_SCL_B_MARK,
 	MLB_SIG_MARK, SCIFB1_RXD_D_MARK, RX1_C_MARK, IIC2_SDA_B_MARK,
 	I2C2_SDA_B_MARK, MLB_DAT_MARK, SPV_EVEN_MARK,
 	SCIFB1_TXD_D_MARK, TX1_C_MARK, BPFCLK_C_MARK,
-	RDS_CLK_B_MARK, SSI_SCK0129_MARK, CAN_CLK_B_MARK,
+	SSI_SCK0129_MARK, CAN_CLK_B_MARK,
 	MOUT0_MARK,
 
 	SSI_WS0129_MARK, CAN0_TX_B_MARK, MOUT1_MARK,
@@ -776,12 +774,12 @@ enum {
 
 	SSI_SDATA5_MARK, SCIFB1_TXD_MARK, IETX_B_MARK, DU2_DR2_MARK,
 	LCDOUT2_MARK, CAN_DEBUGOUT5_MARK, SSI_SCK6_MARK,
-	SCIFB1_CTS_N_MARK, BPFCLK_D_MARK, RDS_CLK_C_MARK,
+	SCIFB1_CTS_N_MARK, BPFCLK_D_MARK,
 	DU2_DR3_MARK, LCDOUT3_MARK, CAN_DEBUGOUT6_MARK,
-	BPFCLK_F_MARK, RDS_CLK_E_MARK, SSI_WS6_MARK,
+	BPFCLK_F_MARK, SSI_WS6_MARK,
 	SCIFB1_RTS_N_MARK, CAN0_TX_D_MARK, DU2_DR4_MARK,
 	LCDOUT4_MARK, CAN_DEBUGOUT7_MARK, SSI_SDATA6_MARK,
-	FMIN_D_MARK, RDS_DATA_C_MARK, DU2_DR5_MARK, LCDOUT5_MARK,
+	FMIN_D_MARK, DU2_DR5_MARK, LCDOUT5_MARK,
 	CAN_DEBUGOUT8_MARK, SSI_SCK78_MARK, STP_IVCXO27_1_MARK,
 	SCK1_MARK, SCIFA1_SCK_MARK, DU2_DR6_MARK, LCDOUT6_MARK,
 	CAN_DEBUGOUT9_MARK, SSI_WS78_MARK, STP_ISCLK_1_MARK,
@@ -789,8 +787,8 @@ enum {
 	LCDOUT7_MARK, CAN_DEBUGOUT10_MARK, SSI_SDATA7_MARK,
 	STP_ISD_1_MARK, SCIFB2_RXD_MARK, SCIFA2_RTS_N_MARK,
 	TCLK2_MARK, QSTVA_QVS_MARK, CAN_DEBUGOUT11_MARK,
-	BPFCLK_E_MARK, RDS_CLK_D_MARK, SSI_SDATA7_B_MARK,
-	FMIN_G_MARK, RDS_DATA_F_MARK, SSI_SDATA8_MARK,
+	BPFCLK_E_MARK, SSI_SDATA7_B_MARK,
+	FMIN_G_MARK, SSI_SDATA8_MARK,
 	STP_ISEN_1_MARK, SCIFB2_TXD_MARK, CAN0_TX_C_MARK,
 	CAN_DEBUGOUT12_MARK, SSI_SDATA8_B_MARK, SSI_SDATA9_MARK,
 	STP_ISSYNC_1_MARK, SCIFB2_CTS_N_MARK, SSI_WS1_MARK,
@@ -1240,7 +1238,6 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP7_5_3, ETH_TXD1),
 	PINMUX_IPSR_MODSEL_DATA(IP7_5_3, HTX0_F, SEL_HSCIF0_4),
 	PINMUX_IPSR_MODSEL_DATA(IP7_5_3, BPFCLK_G, SEL_SIM_2),
-	PINMUX_IPSR_MODSEL_DATA(IP7_5_3, RDS_CLK_F, SEL_HSCIF0_5),
 	PINMUX_IPSR_DATA(IP7_7_6, ETH_TX_EN),
 	PINMUX_IPSR_MODSEL_DATA(IP7_7_6, SIM0_CLK_C, SEL_SIM_2),
 	PINMUX_IPSR_MODSEL_DATA(IP7_7_6, HRTS0_N_F, SEL_HSCIF0_5),
@@ -1421,7 +1418,6 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP10_18_15, SD2_DAT1),
 	PINMUX_IPSR_DATA(IP10_18_15, MMC0_D1),
 	PINMUX_IPSR_MODSEL_DATA(IP10_18_15, FMIN_B, SEL_FM_1),
-	PINMUX_IPSR_MODSEL_DATA(IP10_18_15, RDS_DATA, SEL_RDS_0),
 	PINMUX_IPSR_MODSEL_DATA(IP10_18_15, VI0_DATA3_VI0_B3_B, SEL_VI0_1),
 	PINMUX_IPSR_MODSEL_DATA(IP10_18_15, SCIFB1_TXD_E, SEL_SCIFB1_4),
 	PINMUX_IPSR_MODSEL_DATA(IP10_18_15, TX1_D, SEL_SCIF1_3),
@@ -1431,7 +1427,6 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP10_22_19, SD2_DAT2),
 	PINMUX_IPSR_DATA(IP10_22_19, MMC0_D2),
 	PINMUX_IPSR_MODSEL_DATA(IP10_22_19, BPFCLK_B, SEL_FM_1),
-	PINMUX_IPSR_MODSEL_DATA(IP10_22_19, RDS_CLK, SEL_RDS_0),
 	PINMUX_IPSR_MODSEL_DATA(IP10_22_19, VI0_DATA4_VI0_B4_B, SEL_VI0_1),
 	PINMUX_IPSR_MODSEL_DATA(IP10_22_19, HRX0_D, SEL_HSCIF0_3),
 	PINMUX_IPSR_MODSEL_DATA(IP10_22_19, TS_SDEN1_B, SEL_TSIF1_1),
@@ -1494,11 +1489,8 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP11_21_18, TS_SCK1, SEL_TSIF1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP11_21_18, GLO_Q1, SEL_GPS_0),
 	PINMUX_IPSR_MODSEL_DATA(IP11_21_18, FMIN_C, SEL_FM_2),
-	PINMUX_IPSR_MODSEL_DATA(IP11_21_18, RDS_DATA_B, SEL_RDS_1),
 	PINMUX_IPSR_MODSEL_DATA(IP11_21_18, FMIN_E, SEL_FM_4),
-	PINMUX_IPSR_MODSEL_DATA(IP11_21_18, RDS_DATA_D, SEL_RDS_3),
 	PINMUX_IPSR_MODSEL_DATA(IP11_21_18, FMIN_F, SEL_FM_5),
-	PINMUX_IPSR_MODSEL_DATA(IP11_21_18, RDS_DATA_E, SEL_RDS_4),
 	PINMUX_IPSR_DATA(IP11_23_22, MLB_CLK),
 	PINMUX_IPSR_MODSEL_DATA(IP11_23_22, IIC2_SCL_B, SEL_IIC2_1),
 	PINMUX_IPSR_MODSEL_DATA(IP11_23_22, I2C2_SCL_B, SEL_I2C2_1),
@@ -1512,7 +1504,6 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP11_29_27, SCIFB1_TXD_D, SEL_SCIFB1_3),
 	PINMUX_IPSR_MODSEL_DATA(IP11_29_27, TX1_C, SEL_SCIF1_2),
 	PINMUX_IPSR_MODSEL_DATA(IP11_29_27, BPFCLK_C, SEL_FM_2),
-	PINMUX_IPSR_MODSEL_DATA(IP11_29_27, RDS_CLK_B, SEL_RDS_1),
 	PINMUX_IPSR_DATA(IP11_31_30, SSI_SCK0129),
 	PINMUX_IPSR_MODSEL_DATA(IP11_31_30, CAN_CLK_B, SEL_CANCLK_1),
 	PINMUX_IPSR_DATA(IP11_31_30, MOUT0),
@@ -1583,12 +1574,10 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP13_6_3, SSI_SCK6, SEL_SSI6_0),
 	PINMUX_IPSR_MODSEL_DATA(IP13_6_3, SCIFB1_CTS_N, SEL_SCIFB1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP13_6_3, BPFCLK_D, SEL_FM_3),
-	PINMUX_IPSR_MODSEL_DATA(IP13_6_3, RDS_CLK_C, SEL_RDS_2),
 	PINMUX_IPSR_DATA(IP13_6_3, DU2_DR3),
 	PINMUX_IPSR_DATA(IP13_6_3, LCDOUT3),
 	PINMUX_IPSR_DATA(IP13_6_3, CAN_DEBUGOUT6),
 	PINMUX_IPSR_MODSEL_DATA(IP13_6_3, BPFCLK_F, SEL_FM_5),
-	PINMUX_IPSR_MODSEL_DATA(IP13_6_3, RDS_CLK_E, SEL_RDS_4),
 	PINMUX_IPSR_MODSEL_DATA(IP13_9_7, SSI_WS6, SEL_SSI6_0),
 	PINMUX_IPSR_MODSEL_DATA(IP13_9_7, SCIFB1_RTS_N, SEL_SCIFB1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP13_9_7, CAN0_TX_D, SEL_CAN0_3),
@@ -1597,7 +1586,6 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP13_9_7, CAN_DEBUGOUT7),
 	PINMUX_IPSR_MODSEL_DATA(IP13_12_10, SSI_SDATA6, SEL_SSI6_0),
 	PINMUX_IPSR_MODSEL_DATA(IP13_12_10, FMIN_D, SEL_FM_3),
-	PINMUX_IPSR_MODSEL_DATA(IP13_12_10, RDS_DATA_C, SEL_RDS_2),
 	PINMUX_IPSR_DATA(IP13_12_10, DU2_DR5),
 	PINMUX_IPSR_DATA(IP13_12_10, LCDOUT5),
 	PINMUX_IPSR_DATA(IP13_12_10, CAN_DEBUGOUT8),
@@ -1623,10 +1611,8 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP13_22_19, QSTVA_QVS),
 	PINMUX_IPSR_DATA(IP13_22_19, CAN_DEBUGOUT11),
 	PINMUX_IPSR_MODSEL_DATA(IP13_22_19, BPFCLK_E, SEL_FM_4),
-	PINMUX_IPSR_MODSEL_DATA(IP13_22_19, RDS_CLK_D, SEL_RDS_3),
 	PINMUX_IPSR_MODSEL_DATA(IP13_22_19, SSI_SDATA7_B, SEL_SSI7_1),
 	PINMUX_IPSR_MODSEL_DATA(IP13_22_19, FMIN_G, SEL_FM_6),
-	PINMUX_IPSR_MODSEL_DATA(IP13_22_19, RDS_DATA_F, SEL_RDS_5),
 	PINMUX_IPSR_MODSEL_DATA(IP13_25_23, SSI_SDATA8, SEL_SSI8_0),
 	PINMUX_IPSR_MODSEL_DATA(IP13_25_23, STP_ISEN_1, SEL_SSP_0),
 	PINMUX_IPSR_MODSEL_DATA(IP13_25_23, SCIFB2_TXD, SEL_SCIFB2_0),
@@ -3490,8 +3476,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		/* IP7_7_6 [2] */
 		FN_ETH_TX_EN, 0, FN_SIM0_CLK_C, FN_HRTS0_N_F,
 		/* IP7_5_3 [3] */
-		FN_ETH_TXD1, 0, FN_HTX0_F, FN_BPFCLK_G, FN_RDS_CLK_F,
-		0, 0, 0,
+		FN_ETH_TXD1, 0, FN_HTX0_F, FN_BPFCLK_G, 0, 0, 0, 0,
 		/* IP7_2_0 [3] */
 		FN_ETH_MDIO, 0, FN_HRTS0_N_E,
 		FN_SIM0_D_C, FN_HCTS0_N_F, 0, 0, 0, }
@@ -3584,11 +3569,11 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_SD2_DAT3, FN_MMC0_D3, FN_SIM0_RST, FN_VI0_DATA5_VI0_B5_B,
 		FN_HTX0_D, FN_TS_SPSYNC1_B, FN_GLO_Q1_B, FN_VI3_DATA5_B,
 		/* IP10_22_19 [4] */
-		FN_SD2_DAT2, FN_MMC0_D2, FN_BPFCLK_B, FN_RDS_CLK,
+		FN_SD2_DAT2, FN_MMC0_D2, FN_BPFCLK_B, 0,
 		FN_VI0_DATA4_VI0_B4_B, FN_HRX0_D, FN_TS_SDEN1_B,
 		FN_GLO_Q0_B, FN_VI3_DATA4_B, 0, 0, 0, 0, 0, 0, 0,
 		/* IP10_18_15 [4] */
-		FN_SD2_DAT1, FN_MMC0_D1, FN_FMIN_B, FN_RDS_DATA,
+		FN_SD2_DAT1, FN_MMC0_D1, FN_FMIN_B, 0,
 		FN_VI0_DATA3_VI0_B3_B, FN_SCIFB1_TXD_E, FN_TX1_D,
 		FN_TS_SCK0_C, FN_GLO_RFON_B, FN_VI3_DATA3_B,
 		0, 0, 0, 0, 0, 0,
@@ -3617,7 +3602,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_SSI_SCK0129, FN_CAN_CLK_B, FN_MOUT0, 0,
 		/* IP11_29_27 [3] */
 		FN_MLB_DAT, FN_SPV_EVEN, FN_SCIFB1_TXD_D, FN_TX1_C, FN_BPFCLK_C,
-		FN_RDS_CLK_B, 0, 0,
+		0, 0, 0,
 		/* IP11_26_24 [3] */
 		FN_MLB_SIG, FN_SCIFB1_RXD_D, FN_RX1_C, FN_IIC2_SDA_B, FN_I2C2_SDA_B,
 		0, 0, 0,
@@ -3625,8 +3610,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_MLB_CLK, FN_IIC2_SCL_B, FN_I2C2_SCL_B, 0,
 		/* IP11_21_18 [4] */
 		FN_SD3_WP, FN_MMC1_D5, FN_TS_SCK1, FN_GLO_Q1, FN_FMIN_C,
-		FN_RDS_DATA_B, FN_FMIN_E, FN_RDS_DATA_D, FN_FMIN_F,
-		FN_RDS_DATA_E, 0, 0, 0, 0, 0, 0,
+		0, FN_FMIN_E, 0, FN_FMIN_F, 0, 0, 0, 0, 0, 0, 0,
 		/* IP11_17_15 [3] */
 		FN_SD3_CD, FN_MMC1_D4, FN_TS_SDAT1,
 		FN_VSP, FN_GLO_Q0, FN_SIM0_RST_B, 0, 0,
@@ -3701,8 +3685,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		/* IP13_22_19 [4] */
 		FN_SSI_SDATA7, FN_STP_ISD_1, FN_SCIFB2_RXD, FN_SCIFA2_RTS_N,
 		FN_TCLK2, FN_QSTVA_QVS, FN_CAN_DEBUGOUT11, FN_BPFCLK_E,
-		FN_RDS_CLK_D, FN_SSI_SDATA7_B, FN_FMIN_G, FN_RDS_DATA_F,
-		0, 0, 0, 0,
+		0, FN_SSI_SDATA7_B, FN_FMIN_G, 0, 0, 0, 0, 0,
 		/* IP13_18_16 [3] */
 		FN_SSI_WS78, FN_STP_ISCLK_1, FN_SCIFB2_SCK, FN_SCIFA2_CTS_N,
 		FN_DU2_DR7, FN_LCDOUT7, FN_CAN_DEBUGOUT10, 0,
@@ -3710,15 +3693,15 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_SSI_SCK78, FN_STP_IVCXO27_1, FN_SCK1, FN_SCIFA1_SCK,
 		FN_DU2_DR6, FN_LCDOUT6, FN_CAN_DEBUGOUT9, 0,
 		/* IP13_12_10 [3] */
-		FN_SSI_SDATA6, FN_FMIN_D, FN_RDS_DATA_C, FN_DU2_DR5, FN_LCDOUT5,
+		FN_SSI_SDATA6, FN_FMIN_D, 0, FN_DU2_DR5, FN_LCDOUT5,
 		FN_CAN_DEBUGOUT8, 0, 0,
 		/* IP13_9_7 [3] */
 		FN_SSI_WS6, FN_SCIFB1_RTS_N, FN_CAN0_TX_D, FN_DU2_DR4,
 		FN_LCDOUT4, FN_CAN_DEBUGOUT7, 0, 0,
 		/* IP13_6_3 [4] */
-		FN_SSI_SCK6, FN_SCIFB1_CTS_N, FN_BPFCLK_D, FN_RDS_CLK_C,
+		FN_SSI_SCK6, FN_SCIFB1_CTS_N, FN_BPFCLK_D, 0,
 		FN_DU2_DR3, FN_LCDOUT3, FN_CAN_DEBUGOUT6,
-		FN_BPFCLK_F, FN_RDS_CLK_E, 0, 0, 0, 0, 0, 0, 0,
+		FN_BPFCLK_F, 0, 0, 0, 0, 0, 0, 0, 0,
 		/* IP13_2_0 [3] */
 		FN_SSI_SDATA5, FN_SCIFB1_TXD, FN_IETX_B, FN_DU2_DR2,
 		FN_LCDOUT2, FN_CAN_DEBUGOUT5, 0, 0, }
@@ -3912,9 +3895,8 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_SEL_HSCIF0_3, FN_SEL_HSCIF0_4, FN_SEL_HSCIF0_5, 0, 0,
 		/* SEL_GPS [2] */
 		FN_SEL_GPS_0, FN_SEL_GPS_1, FN_SEL_GPS_2, 0,
-		/* SEL_RDS [3] */
-		FN_SEL_RDS_0, FN_SEL_RDS_1, FN_SEL_RDS_2,
-		FN_SEL_RDS_3, FN_SEL_RDS_4, FN_SEL_RDS_5, 0, 0,
+		/* RESERVED [3] */
+		0, 0, 0, 0, 0, 0, 0, 0,
 		/* SEL_SIM [2] */
 		FN_SEL_SIM_0, FN_SEL_SIM_1, FN_SEL_SIM_2, 0,
 		/* SEL_SSI8 [2] */
-- 
1.8.1.5



From gururaja.hebbar at ti.com  Wed Jul 24 09:14:56 2013
From: gururaja.hebbar at ti.com (Gururaja Hebbar)
Date: Wed, 24 Jul 2013 18:44:56 +0530
Subject: [Patch V2 3/4] rtc: omap: add rtc wakeup support to alarm events
In-Reply-To: <1372841225-18813-4-git-send-email-gururaja.hebbar@ti.com>
References: <1372841225-18813-1-git-send-email-gururaja.hebbar@ti.com>
 <1372841225-18813-4-git-send-email-gururaja.hebbar@ti.com>
Message-ID: <51EFD350.4030500@ti.com>

Hi Andrew,

On 7/3/2013 2:17 PM, Hebbar Gururaja wrote:
> On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
> is available to enable Alarm Wakeup feature. This register needs to be
> properly handled for the rtcwake to work properly.
>
> Platforms using such IP should set "ti,am3352-rtc" in rtc device dt
> compatibility node.

I just checked that the 1st patch in this series is pulled in and this
patch [3/4] is not pulled . If you do not have any comments, can you 
pull this one also. I have already got Acks from Sekhar & Kevin for the 
same.

Thanks & regards
Gururaja

>
> Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> Acked-by: Kevin Hilman <khilman at linaro.org>
> Acked-by: Sekhar Nori <nsekhar at ti.com>
> Cc: Grant Likely <grant.likely at linaro.org>
> Cc: Rob Herring <rob.herring at calxeda.com>
> Cc: Rob Landley <rob at landley.net>
> Cc: Alessandro Zummo <a.zummo at towertech.it>
> Cc: rtc-linux at googlegroups.com
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: linux-doc at vger.kernel.org
> ---
> Changes in V2:
> 	- Coding style corrections (use lower case for hex numbers)
> 	- use "[AM/am]3352" instead of "[AM/am]335x" to keep the all
> 	  usages in sync.
> 	- Use index defined for struct members so they remain in sync
>
> :100644 100644 b47aa41... 5a0f02d... M	Documentation/devicetree/bindings/rtc/rtc-omap.txt
> :100644 100644 761919d... c2e18fe... M	drivers/rtc/rtc-omap.c
>   Documentation/devicetree/bindings/rtc/rtc-omap.txt |    6 +-
>   drivers/rtc/rtc-omap.c                             |   60 +++++++++++++++++---
>   2 files changed, 57 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> index b47aa41..5a0f02d 100644
> --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> @@ -1,7 +1,11 @@
>   TI Real Time Clock
>
>   Required properties:
> -- compatible: "ti,da830-rtc"
> +- compatible:
> +	- "ti,da830-rtc"  - for RTC IP used similar to that on DA8xx SoC family.
> +	- "ti,am3352-rtc" - for RTC IP used similar to that on AM335x SoC family.
> +			    This RTC IP has special WAKE-EN Register to enable
> +			    Wakeup generation for event Alarm.
>   - reg: Address range of rtc register set
>   - interrupts: rtc timer, alarm interrupts in order
>   - interrupt-parent: phandle for the interrupt controller
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 761919d..c2e18fe 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -72,6 +72,8 @@
>   #define OMAP_RTC_KICK0_REG		0x6c
>   #define OMAP_RTC_KICK1_REG		0x70
>
> +#define OMAP_RTC_IRQWAKEEN		0x7c
> +
>   /* OMAP_RTC_CTRL_REG bit fields: */
>   #define OMAP_RTC_CTRL_SPLIT		(1<<7)
>   #define OMAP_RTC_CTRL_DISABLE		(1<<6)
> @@ -96,12 +98,21 @@
>   #define OMAP_RTC_INTERRUPTS_IT_ALARM    (1<<3)
>   #define OMAP_RTC_INTERRUPTS_IT_TIMER    (1<<2)
>
> +/* OMAP_RTC_IRQWAKEEN bit fields: */
> +#define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN    (1<<1)
> +
>   /* OMAP_RTC_KICKER values */
>   #define	KICK0_VALUE			0x83e70b13
>   #define	KICK1_VALUE			0x95a4f1e0
>
>   #define	OMAP_RTC_HAS_KICKER		0x1
>
> +/*
> + * Few RTC IP revisions has special WAKE-EN Register to enable Wakeup
> + * generation for event Alarm.
> + */
> +#define	OMAP_RTC_HAS_IRQWAKEEN		0x2
> +
>   static void __iomem	*rtc_base;
>
>   #define rtc_read(addr)		readb(rtc_base + (addr))
> @@ -301,12 +312,18 @@ static struct rtc_class_ops omap_rtc_ops = {
>   static int omap_rtc_alarm;
>   static int omap_rtc_timer;
>
> -#define	OMAP_RTC_DATA_DA830_IDX	1
> +#define	OMAP_RTC_DATA_AM3352_IDX	1
> +#define	OMAP_RTC_DATA_DA830_IDX		2
>
>   static struct platform_device_id omap_rtc_devtype[] = {
>   	{
>   		.name	= DRIVER_NAME,
> -	}, {
> +	},
> +	[OMAP_RTC_DATA_AM3352_IDX] = {
> +		.name	= "am3352-rtc",
> +		.driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
> +	},
> +	[OMAP_RTC_DATA_DA830_IDX] = {
>   		.name	= "da830-rtc",
>   		.driver_data = OMAP_RTC_HAS_KICKER,
>   	},
> @@ -318,6 +335,9 @@ static const struct of_device_id omap_rtc_of_match[] = {
>   	{	.compatible	= "ti,da830-rtc",
>   		.data		= &omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
>   	},
> +	{	.compatible	= "ti,am3352-rtc",
> +		.data		= &omap_rtc_devtype[OMAP_RTC_DATA_AM3352_IDX],
> +	},
>   	{},
>   };
>   MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
> @@ -466,16 +486,28 @@ static u8 irqstat;
>
>   static int omap_rtc_suspend(struct device *dev)
>   {
> +	u8 irqwake_stat;
> +	struct platform_device *pdev = to_platform_device(dev);
> +	const struct platform_device_id *id_entry =
> +					platform_get_device_id(pdev);
> +
>   	irqstat = rtc_read(OMAP_RTC_INTERRUPTS_REG);
>
>   	/* FIXME the RTC alarm is not currently acting as a wakeup event
> -	 * source, and in fact this enable() call is just saving a flag
> -	 * that's never used...
> +	 * source on some platforms, and in fact this enable() call is just
> +	 * saving a flag that's never used...
>   	 */
> -	if (device_may_wakeup(dev))
> +	if (device_may_wakeup(dev)) {
>   		enable_irq_wake(omap_rtc_alarm);
> -	else
> +
> +		if (id_entry->driver_data & OMAP_RTC_HAS_IRQWAKEEN) {
> +			irqwake_stat = rtc_read(OMAP_RTC_IRQWAKEEN);
> +			irqwake_stat |= OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN;
> +			rtc_write(irqwake_stat, OMAP_RTC_IRQWAKEEN);
> +		}
> +	} else {
>   		rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
> +	}
>
>   	/* Disable the clock/module */
>   	pm_runtime_put_sync(dev);
> @@ -485,13 +517,25 @@ static int omap_rtc_suspend(struct device *dev)
>
>   static int omap_rtc_resume(struct device *dev)
>   {
> +	u8 irqwake_stat;
> +	struct platform_device *pdev = to_platform_device(dev);
> +	const struct platform_device_id *id_entry =
> +				platform_get_device_id(pdev);
> +
>   	/* Enable the clock/module so that we can access the registers */
>   	pm_runtime_get_sync(dev);
>
> -	if (device_may_wakeup(dev))
> +	if (device_may_wakeup(dev)) {
>   		disable_irq_wake(omap_rtc_alarm);
> -	else
> +
> +		if (id_entry->driver_data & OMAP_RTC_HAS_IRQWAKEEN) {
> +			irqwake_stat = rtc_read(OMAP_RTC_IRQWAKEEN);
> +			irqwake_stat &= ~OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN;
> +			rtc_write(irqwake_stat, OMAP_RTC_IRQWAKEEN);
> +		}
> +	} else {
>   		rtc_write(irqstat, OMAP_RTC_INTERRUPTS_REG);
> +	}
>   	return 0;
>   }
>   #endif
>



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:12 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:12 +0200
Subject: [PATCH 06/14] sh-pfc: r8a7790: Swap SCIFA2_RXD_B and HRX0_C
 configurations
In-Reply-To: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671720-8794-7-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

From: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>

The SCIFA2 RXD_B and HRX0_C pins have their pinmux configuration data
swapped, fix it.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index 350b076..b06d36c 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -464,7 +464,7 @@ enum {
 	FN_LCDOUT21, FN_MSIOF0_SCK, FN_TS_SDAT0, FN_ADICLK,
 	FN_DU2_DB6, FN_LCDOUT22, FN_MSIOF0_SYNC, FN_TS_SCK0,
 	FN_SSI_SCK2, FN_ADIDATA, FN_DU2_DB7, FN_LCDOUT23,
-	FN_SCIFA2_RXD_B, FN_MSIOF0_SS1, FN_ADICHS0,
+	FN_HRX0_C, FN_MSIOF0_SS1, FN_ADICHS0,
 	FN_DU2_DG5, FN_LCDOUT13, FN_MSIOF0_TXD, FN_ADICHS1,
 	FN_DU2_DG6, FN_LCDOUT14,
 
@@ -472,7 +472,7 @@ enum {
 	FN_MSIOF0_SS2, FN_AUDIO_CLKOUT, FN_ADICHS2,
 	FN_DU2_DISP, FN_QPOLA, FN_HTX0_C, FN_SCIFA2_TXD_B,
 	FN_MSIOF0_RXD, FN_TS_SPSYNC0, FN_SSI_WS2,
-	FN_ADICS_SAMP, FN_DU2_CDE, FN_QPOLB, FN_HRX0_C,
+	FN_ADICS_SAMP, FN_DU2_CDE, FN_QPOLB, FN_SCIFA2_RXD_B,
 	FN_USB1_PWEN, FN_AUDIO_CLKOUT_D, FN_USB1_OVC,
 	FN_TCLK1_B,
 
@@ -827,14 +827,14 @@ enum {
 	LCDOUT21_MARK, MSIOF0_SCK_MARK, TS_SDAT0_MARK, ADICLK_MARK,
 	DU2_DB6_MARK, LCDOUT22_MARK, MSIOF0_SYNC_MARK, TS_SCK0_MARK,
 	SSI_SCK2_MARK, ADIDATA_MARK, DU2_DB7_MARK, LCDOUT23_MARK,
-	SCIFA2_RXD_B_MARK, MSIOF0_SS1_MARK, ADICHS0_MARK,
+	HRX0_C_MARK, MSIOF0_SS1_MARK, ADICHS0_MARK,
 	DU2_DG5_MARK, LCDOUT13_MARK, MSIOF0_TXD_MARK, ADICHS1_MARK,
 	DU2_DG6_MARK, LCDOUT14_MARK,
 
 	MSIOF0_SS2_MARK, AUDIO_CLKOUT_MARK, ADICHS2_MARK,
 	DU2_DISP_MARK, QPOLA_MARK, HTX0_C_MARK, SCIFA2_TXD_B_MARK,
 	MSIOF0_RXD_MARK, TS_SPSYNC0_MARK, SSI_WS2_MARK,
-	ADICS_SAMP_MARK, DU2_CDE_MARK, QPOLB_MARK, HRX0_C_MARK,
+	ADICS_SAMP_MARK, DU2_CDE_MARK, QPOLB_MARK, SCIFA2_RXD_B_MARK,
 	USB1_PWEN_MARK, AUDIO_CLKOUT_D_MARK, USB1_OVC_MARK,
 	TCLK1_B_MARK,
 	PINMUX_MARK_END,
@@ -1742,7 +1742,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP15_25_23, ADIDATA),
 	PINMUX_IPSR_DATA(IP15_25_23, DU2_DB7),
 	PINMUX_IPSR_DATA(IP15_25_23, LCDOUT23),
-	PINMUX_IPSR_MODSEL_DATA(IP15_25_23, SCIFA2_RXD_B, SEL_SCIFA2_1),
+	PINMUX_IPSR_MODSEL_DATA(IP15_25_23, HRX0_C, SEL_SCIFA2_1),
 	PINMUX_IPSR_MODSEL_DATA(IP15_27_26, MSIOF0_SS1, SEL_SOF0_0),
 	PINMUX_IPSR_DATA(IP15_27_26, ADICHS0),
 	PINMUX_IPSR_DATA(IP15_27_26, DU2_DG5),
@@ -1765,7 +1765,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP16_5_3, ADICS_SAMP),
 	PINMUX_IPSR_DATA(IP16_5_3, DU2_CDE),
 	PINMUX_IPSR_DATA(IP16_5_3, QPOLB),
-	PINMUX_IPSR_MODSEL_DATA(IP16_5_3, HRX0_C, SEL_HSCIF0_2),
+	PINMUX_IPSR_MODSEL_DATA(IP16_5_3, SCIFA2_RXD_B, SEL_HSCIF0_2),
 	PINMUX_IPSR_DATA(IP16_6, USB1_PWEN),
 	PINMUX_IPSR_DATA(IP16_6, AUDIO_CLKOUT_D),
 	PINMUX_IPSR_DATA(IP16_7, USB1_OVC),
@@ -3753,7 +3753,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_MSIOF0_SS1, FN_ADICHS0, FN_DU2_DG5, FN_LCDOUT13,
 		/* IP15_25_23 [3] */
 		FN_MSIOF0_SYNC, FN_TS_SCK0, FN_SSI_SCK2, FN_ADIDATA,
-		FN_DU2_DB7, FN_LCDOUT23, FN_SCIFA2_RXD_B, 0,
+		FN_DU2_DB7, FN_LCDOUT23, FN_HRX0_C, 0,
 		/* IP15_22_20 [3] */
 		FN_MSIOF0_SCK, FN_TS_SDAT0, FN_ADICLK,
 		FN_DU2_DB6, FN_LCDOUT22, 0, 0, 0,
@@ -3804,7 +3804,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_USB1_PWEN, FN_AUDIO_CLKOUT_D,
 		/* IP16_5_3 [3] */
 		FN_MSIOF0_RXD, FN_TS_SPSYNC0, FN_SSI_WS2,
-		FN_ADICS_SAMP, FN_DU2_CDE, FN_QPOLB, FN_HRX0_C, 0,
+		FN_ADICS_SAMP, FN_DU2_CDE, FN_QPOLB, FN_SCIFA2_RXD_B, 0,
 		/* IP16_2_0 [3] */
 		FN_MSIOF0_SS2, FN_AUDIO_CLKOUT, FN_ADICHS2,
 		FN_DU2_DISP, FN_QPOLA, FN_HTX0_C, FN_SCIFA2_TXD_B, 0, }
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:13 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:13 +0200
Subject: [PATCH 07/14] sh-pfc: r8a7790: Add TCLK1 pin configuration support
In-Reply-To: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671720-8794-8-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

From: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>

Update the pinmux configuration tables to support the TCLK1 pin.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index b06d36c..51e590b 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -170,7 +170,7 @@ enum {
 	FN_VI0_R1, FN_VI0_R1_B, FN_TX0_B, FN_D6,
 	FN_IIC2_SCL_C, FN_VI3_DATA6, FN_VI0_R2, FN_VI0_R2_B,
 	FN_I2C2_SCL_C, FN_D7, FN_AD_DI_B, FN_IIC2_SDA_C,
-	FN_VI3_DATA7, FN_VI0_R3, FN_VI0_R3_B, FN_I2C2_SDA_C,
+	FN_VI3_DATA7, FN_VI0_R3, FN_VI0_R3_B, FN_I2C2_SDA_C, FN_TCLK1,
 	FN_D8, FN_SCIFA1_SCK_C, FN_AVB_TXD0,
 	FN_VI0_G0, FN_VI0_G0_B, FN_VI2_DATA0_VI2_B0,
 
@@ -547,7 +547,7 @@ enum {
 	VI0_R1_MARK, VI0_R1_B_MARK, TX0_B_MARK, D6_MARK,
 	IIC2_SCL_C_MARK, VI3_DATA6_MARK, VI0_R2_MARK, VI0_R2_B_MARK,
 	I2C2_SCL_C_MARK, D7_MARK, AD_DI_B_MARK, IIC2_SDA_C_MARK,
-	VI3_DATA7_MARK, VI0_R3_MARK, VI0_R3_B_MARK, I2C2_SDA_C_MARK,
+	VI3_DATA7_MARK, VI0_R3_MARK, VI0_R3_B_MARK, I2C2_SDA_C_MARK, TCLK1_MARK,
 	D8_MARK, SCIFA1_SCK_C_MARK, AVB_TXD0_MARK,
 	VI0_G0_MARK, VI0_G0_B_MARK, VI2_DATA0_VI2_B0_MARK,
 
@@ -900,6 +900,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP0_26_23, VI0_R3, SEL_VI0_0),
 	PINMUX_IPSR_MODSEL_DATA(IP0_26_23, VI0_R3_B, SEL_VI0_1),
 	PINMUX_IPSR_MODSEL_DATA(IP0_26_23, I2C2_SDA_C, SEL_I2C2_2),
+	PINMUX_IPSR_MODSEL_DATA(IP0_26_23, TCLK1, SEL_TMU1_0),
 	PINMUX_IPSR_DATA(IP0_30_27, D8),
 	PINMUX_IPSR_MODSEL_DATA(IP0_30_27, SCIFA1_SCK_C, SEL_SCIFA1_2),
 	PINMUX_IPSR_DATA(IP0_30_27, AVB_TXD0),
@@ -3214,7 +3215,7 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		/* IP0_26_23 [4] */
 		FN_D7, FN_AD_DI_B, FN_IIC2_SDA_C,
 		FN_VI3_DATA7, FN_VI0_R3, FN_VI0_R3_B, FN_I2C2_SDA_C,
-		0, 0, 0, 0, 0, 0, 0, 0, 0,
+		FN_TCLK1, 0, 0, 0, 0, 0, 0, 0, 0,
 		/* IP0_22_20 [3] */
 		FN_D6, FN_IIC2_SCL_C, FN_VI3_DATA6, FN_VI0_R2, FN_VI0_R2_B,
 		FN_I2C2_SCL_C, 0, 0,
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:15 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:15 +0200
Subject: [PATCH 09/14] sh-pfc: r8a7790: Fix miscellaneous pinmux configuration
 tables mistakes
In-Reply-To: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671720-8794-10-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

From: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>

Fix erroneous entries in the pinmux configuration tables that affect
HSCIF, I2C, LBSC, SCIF, SSI and VIN operation.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 31 +++++++++++++++----------------
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index 9a63063..62ac0d2 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -934,7 +934,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP1_14_12, VI0_HSYNC_N_B, SEL_VI0_1),
 	PINMUX_IPSR_MODSEL_DATA(IP1_14_12, VI2_DATA4_VI2_B4, SEL_VI2_0),
 	PINMUX_IPSR_DATA(IP1_17_15, D13),
-	PINMUX_IPSR_MODSEL_DATA(IP1_17_15, AVB_TXD5, SEL_SCIFA1_2),
+	PINMUX_IPSR_DATA(IP1_17_15, AVB_TXD5),
 	PINMUX_IPSR_MODSEL_DATA(IP1_17_15, VI0_VSYNC_N, SEL_VI0_0),
 	PINMUX_IPSR_MODSEL_DATA(IP1_17_15, VI0_VSYNC_N_B, SEL_VI0_1),
 	PINMUX_IPSR_MODSEL_DATA(IP1_17_15, VI2_DATA5_VI2_B5, SEL_VI2_0),
@@ -1005,14 +1005,14 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP3_3_0, VI1_R0, SEL_VI1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP3_3_0, VI1_R0_B, SEL_VI1_1),
 	PINMUX_IPSR_DATA(IP3_3_0, VI2_G0),
-	PINMUX_IPSR_DATA(IP3_3_0, VI2_DATA3_VI2_B3_B),
+	PINMUX_IPSR_MODSEL_DATA(IP3_3_0, VI2_DATA3_VI2_B3_B, SEL_VI2_1),
 	PINMUX_IPSR_DATA(IP3_7_4, A12),
 	PINMUX_IPSR_MODSEL_DATA(IP3_7_4, SCIFB2_RXD_B, SEL_SCIFB2_1),
 	PINMUX_IPSR_DATA(IP3_7_4, MSIOF2_TXD),
 	PINMUX_IPSR_MODSEL_DATA(IP3_7_4, VI1_R1, SEL_VI1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP3_7_4, VI1_R1_B, SEL_VI1_1),
 	PINMUX_IPSR_DATA(IP3_7_4, VI2_G1),
-	PINMUX_IPSR_DATA(IP3_7_4, VI2_DATA4_VI2_B4_B),
+	PINMUX_IPSR_MODSEL_DATA(IP3_7_4, VI2_DATA4_VI2_B4_B, SEL_VI2_1),
 	PINMUX_IPSR_DATA(IP3_11_8, A13),
 	PINMUX_IPSR_MODSEL_DATA(IP3_11_8, SCIFB2_RTS_N_B, SEL_SCIFB2_1),
 	PINMUX_IPSR_DATA(IP3_11_8, EX_WAIT2),
@@ -1020,7 +1020,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP3_11_8, VI1_R2, SEL_VI1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP3_11_8, VI1_R2_B, SEL_VI1_1),
 	PINMUX_IPSR_DATA(IP3_11_8, VI2_G2),
-	PINMUX_IPSR_MODSEL_DATA(IP3_11_8, VI2_DATA5_VI2_B5_B, SEL_VI2_0),
+	PINMUX_IPSR_MODSEL_DATA(IP3_11_8, VI2_DATA5_VI2_B5_B, SEL_VI2_1),
 	PINMUX_IPSR_DATA(IP3_14_12, A14),
 	PINMUX_IPSR_MODSEL_DATA(IP3_14_12, SCIFB2_TXD_B, SEL_SCIFB2_1),
 	PINMUX_IPSR_DATA(IP3_14_12, ATACS11_N),
@@ -1112,7 +1112,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP5_2_0, VI1_G1, SEL_VI1_0),
 	PINMUX_IPSR_MODSEL_DATA(IP5_2_0, VI1_G1_B, SEL_VI1_1),
 	PINMUX_IPSR_DATA(IP5_2_0, VI2_R3),
-	PINMUX_IPSR_MODSEL_DATA(IP5_5_3, EX_CS4_N, SEL_I2C1_0),
+	PINMUX_IPSR_DATA(IP5_5_3, EX_CS4_N),
 	PINMUX_IPSR_MODSEL_DATA(IP5_5_3, MSIOF1_SCK_B, SEL_SOF1_1),
 	PINMUX_IPSR_DATA(IP5_5_3, VI3_HSYNC_N),
 	PINMUX_IPSR_MODSEL_DATA(IP5_5_3, VI2_HSYNC_N, SEL_VI2_0),
@@ -1159,7 +1159,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP5_23_21, VI2_R6),
 	PINMUX_IPSR_MODSEL_DATA(IP5_23_21, SCIFA0_CTS_N_B, SEL_SCFA_1),
 	PINMUX_IPSR_MODSEL_DATA(IP5_23_21, IERX_C, SEL_IEB_2),
-	PINMUX_IPSR_DATA(IP5_26_24, EX_WAIT0),
+	PINMUX_IPSR_MODSEL_DATA(IP5_26_24, EX_WAIT0, SEL_LBS_0),
 	PINMUX_IPSR_DATA(IP5_26_24, IRQ3),
 	PINMUX_IPSR_DATA(IP5_26_24, INTC_IRQ3_N),
 	PINMUX_IPSR_MODSEL_DATA(IP5_26_24, VI3_CLK, SEL_VI3_0),
@@ -1240,8 +1240,8 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP7_2_0, SIM0_D_C, SEL_SIM_2),
 	PINMUX_IPSR_MODSEL_DATA(IP7_2_0, HCTS0_N_F, SEL_HSCIF0_5),
 	PINMUX_IPSR_DATA(IP7_5_3, ETH_TXD1),
-	PINMUX_IPSR_MODSEL_DATA(IP7_5_3, HTX0_F, SEL_HSCIF0_4),
-	PINMUX_IPSR_MODSEL_DATA(IP7_5_3, BPFCLK_G, SEL_SIM_2),
+	PINMUX_IPSR_MODSEL_DATA(IP7_5_3, HTX0_F, SEL_HSCIF0_5),
+	PINMUX_IPSR_MODSEL_DATA(IP7_5_3, BPFCLK_G, SEL_FM_6),
 	PINMUX_IPSR_DATA(IP7_7_6, ETH_TX_EN),
 	PINMUX_IPSR_MODSEL_DATA(IP7_7_6, SIM0_CLK_C, SEL_SIM_2),
 	PINMUX_IPSR_MODSEL_DATA(IP7_7_6, HRTS0_N_F, SEL_HSCIF0_5),
@@ -1318,7 +1318,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP8_25_24, SCIFA1_RTS_N_D, SEL_SCIFA1_3),
 	PINMUX_IPSR_DATA(IP8_25_24, AVB_MAGIC),
 	PINMUX_IPSR_MODSEL_DATA(IP8_26, VI1_DATA5_VI1_B5, SEL_VI1_0),
-	PINMUX_IPSR_MODSEL_DATA(IP8_26, AVB_PHY_INT, SEL_SCIFA1_3),
+	PINMUX_IPSR_DATA(IP8_26, AVB_PHY_INT),
 	PINMUX_IPSR_MODSEL_DATA(IP8_27, VI1_DATA6_VI1_B6, SEL_VI1_0),
 	PINMUX_IPSR_DATA(IP8_27, AVB_GTXREFCLK),
 	PINMUX_IPSR_DATA(IP8_28, SD0_CLK),
@@ -1522,7 +1522,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP12_5_4, MOUT5),
 	PINMUX_IPSR_DATA(IP12_7_6, SSI_SDATA2),
 	PINMUX_IPSR_MODSEL_DATA(IP12_7_6, CAN1_RX_B, SEL_CAN1_1),
-	PINMUX_IPSR_MODSEL_DATA(IP12_7_6, CAN1_TX_B, SEL_CAN1_1),
+	PINMUX_IPSR_DATA(IP12_7_6, SSI_SCK1),
 	PINMUX_IPSR_DATA(IP12_7_6, MOUT6),
 	PINMUX_IPSR_DATA(IP12_10_8, SSI_SCK34),
 	PINMUX_IPSR_DATA(IP12_10_8, STP_OPWM_0),
@@ -1659,11 +1659,11 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_DATA(IP14_11_9, LCDOUT1),
 	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, SCIFA0_CTS_N, SEL_SCFA_0),
 	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, HCTS1_N, SEL_HSCIF1_0),
-	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, CTS0_N, SEL_SCIF0_0),
+	PINMUX_IPSR_DATA(IP14_15_12, CTS0_N),
 	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, MSIOF3_SYNC, SEL_SOF3_0),
 	PINMUX_IPSR_DATA(IP14_15_12, DU2_DG3),
-	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, LCDOUT11, SEL_HSCIF1_0),
-	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, PWM0_B, SEL_SCIF0_0),
+	PINMUX_IPSR_DATA(IP14_15_12, LCDOUT11),
+	PINMUX_IPSR_DATA(IP14_15_12, PWM0_B),
 	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, IIC1_SCL_C, SEL_IIC1_2),
 	PINMUX_IPSR_MODSEL_DATA(IP14_15_12, I2C1_SCL_C, SEL_I2C1_2),
 	PINMUX_IPSR_MODSEL_DATA(IP14_18_16, SCIFA0_RTS_N, SEL_SCFA_0),
@@ -1703,7 +1703,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP15_2_0, MSIOF3_SCK, SEL_SOF3_0),
 	PINMUX_IPSR_DATA(IP15_2_0, DU2_DG7),
 	PINMUX_IPSR_DATA(IP15_2_0, LCDOUT15),
-	PINMUX_IPSR_MODSEL_DATA(IP15_2_0, SCIF_CLK_B, SEL_SCIFCLK_0),
+	PINMUX_IPSR_MODSEL_DATA(IP15_2_0, SCIF_CLK_B, SEL_SCIFCLK_1),
 	PINMUX_IPSR_MODSEL_DATA(IP15_5_3, SCIFA2_RXD, SEL_SCIFA2_0),
 	PINMUX_IPSR_MODSEL_DATA(IP15_5_3, FMIN, SEL_FM_0),
 	PINMUX_IPSR_MODSEL_DATA(IP15_5_3, TX2, SEL_SCIF2_0),
@@ -1722,8 +1722,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP15_11_9, TS_SDEN0, SEL_TSIF0_0),
 	PINMUX_IPSR_DATA(IP15_11_9, DU2_DG4),
 	PINMUX_IPSR_DATA(IP15_11_9, LCDOUT12),
-	PINMUX_IPSR_MODSEL_DATA(IP15_11_9, HCTS0_N_C, SEL_IIC2_0),
-	PINMUX_IPSR_MODSEL_DATA(IP15_11_9, I2C2_SDA, SEL_I2C2_0),
+	PINMUX_IPSR_MODSEL_DATA(IP15_11_9, HCTS0_N_C, SEL_HSCIF0_2),
 	PINMUX_IPSR_MODSEL_DATA(IP15_13_12, HRX0, SEL_HSCIF0_0),
 	PINMUX_IPSR_DATA(IP15_13_12, DU2_DB2),
 	PINMUX_IPSR_DATA(IP15_13_12, LCDOUT18),
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:14 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:14 +0200
Subject: [PATCH 08/14] sh-pfc: r8a7790: Add SCIF2 pins configuration support
In-Reply-To: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671720-8794-9-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

From: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>

Update the pinmux configuration tables to support the SCIF2 pins
(TX2/TX2_B, RX2/RX2_B, SCK2).

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 40 +++++++++++++++++++++---------------
 1 file changed, 23 insertions(+), 17 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index 51e590b..9a63063 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -198,9 +198,9 @@ enum {
 	FN_A6, FN_SCIFA1_RTS_N_B, FN_TPU0TO2, FN_A7,
 	FN_SCIFA1_SCK_B, FN_AUDIO_CLKOUT_B, FN_TPU0TO3,
 	FN_A8, FN_SCIFA1_RXD_B, FN_SSI_SCK5_B, FN_VI0_R4,
-	FN_VI0_R4_B, FN_SCIFB2_RXD_C, FN_VI2_DATA0_VI2_B0_B,
+	FN_VI0_R4_B, FN_SCIFB2_RXD_C, FN_RX2_B, FN_VI2_DATA0_VI2_B0_B,
 	FN_A9, FN_SCIFA1_CTS_N_B, FN_SSI_WS5_B, FN_VI0_R5,
-	FN_VI0_R5_B, FN_SCIFB2_TXD_C, FN_VI2_DATA1_VI2_B1_B,
+	FN_VI0_R5_B, FN_SCIFB2_TXD_C, FN_TX2_B, FN_VI2_DATA1_VI2_B1_B,
 	FN_A10, FN_SSI_SDATA5_B, FN_MSIOF2_SYNC, FN_VI0_R6,
 	FN_VI0_R6_B, FN_VI2_DATA2_VI2_B2_B,
 
@@ -452,10 +452,10 @@ enum {
 	FN_HRTS0_N_C,
 
 	/* IPSR15 */
-	FN_SCIFA2_SCK, FN_FMCLK, FN_MSIOF3_SCK, FN_DU2_DG7,
+	FN_SCIFA2_SCK, FN_FMCLK, FN_SCK2, FN_MSIOF3_SCK, FN_DU2_DG7,
 	FN_LCDOUT15, FN_SCIF_CLK_B, FN_SCIFA2_RXD, FN_FMIN,
-	FN_DU2_DB0, FN_LCDOUT16, FN_IIC2_SCL, FN_I2C2_SCL,
-	FN_SCIFA2_TXD, FN_BPFCLK, FN_DU2_DB1, FN_LCDOUT17,
+	FN_TX2, FN_DU2_DB0, FN_LCDOUT16, FN_IIC2_SCL, FN_I2C2_SCL,
+	FN_SCIFA2_TXD, FN_BPFCLK, FN_RX2, FN_DU2_DB1, FN_LCDOUT17,
 	FN_IIC2_SDA, FN_I2C2_SDA, FN_HSCK0, FN_TS_SDEN0,
 	FN_DU2_DG4, FN_LCDOUT12, FN_HCTS0_N_C, FN_HRX0,
 	FN_DU2_DB2, FN_LCDOUT18, FN_HTX0, FN_DU2_DB3,
@@ -507,6 +507,7 @@ enum {
 	FN_SEL_CANCLK_0, FN_SEL_CANCLK_1,
 	FN_SEL_SCIFA2_0, FN_SEL_SCIFA2_1, FN_SEL_SCIFA2_2,
 	FN_SEL_CAN1_0, FN_SEL_CAN1_1,
+	FN_SEL_SCIF2_0, FN_SEL_SCIF2_1,
 	FN_SEL_ADI_0, FN_SEL_ADI_1,
 	FN_SEL_SSP_0, FN_SEL_SSP_1,
 	FN_SEL_FM_0, FN_SEL_FM_1, FN_SEL_FM_2, FN_SEL_FM_3,
@@ -573,9 +574,9 @@ enum {
 	A6_MARK, SCIFA1_RTS_N_B_MARK, TPU0TO2_MARK, A7_MARK,
 	SCIFA1_SCK_B_MARK, AUDIO_CLKOUT_B_MARK, TPU0TO3_MARK,
 	A8_MARK, SCIFA1_RXD_B_MARK, SSI_SCK5_B_MARK, VI0_R4_MARK,
-	VI0_R4_B_MARK, SCIFB2_RXD_C_MARK, VI2_DATA0_VI2_B0_B_MARK,
+	VI0_R4_B_MARK, SCIFB2_RXD_C_MARK, RX2_B_MARK, VI2_DATA0_VI2_B0_B_MARK,
 	A9_MARK, SCIFA1_CTS_N_B_MARK, SSI_WS5_B_MARK, VI0_R5_MARK,
-	VI0_R5_B_MARK, SCIFB2_TXD_C_MARK, VI2_DATA1_VI2_B1_B_MARK,
+	VI0_R5_B_MARK, SCIFB2_TXD_C_MARK, TX2_B_MARK, VI2_DATA1_VI2_B1_B_MARK,
 	A10_MARK, SSI_SDATA5_B_MARK, MSIOF2_SYNC_MARK, VI0_R6_MARK,
 	VI0_R6_B_MARK, VI2_DATA2_VI2_B2_B_MARK,
 
@@ -815,10 +816,10 @@ enum {
 	MSIOF3_TXD_MARK, DU1_DOTCLKOUT_MARK, QSTVB_QVE_MARK,
 	HRTS0_N_C_MARK,
 
-	SCIFA2_SCK_MARK, FMCLK_MARK, MSIOF3_SCK_MARK, DU2_DG7_MARK,
+	SCIFA2_SCK_MARK, FMCLK_MARK, SCK2_MARK, MSIOF3_SCK_MARK, DU2_DG7_MARK,
 	LCDOUT15_MARK, SCIF_CLK_B_MARK, SCIFA2_RXD_MARK, FMIN_MARK,
-	DU2_DB0_MARK, LCDOUT16_MARK, IIC2_SCL_MARK, I2C2_SCL_MARK,
-	SCIFA2_TXD_MARK, BPFCLK_MARK, DU2_DB1_MARK, LCDOUT17_MARK,
+	TX2_MARK, DU2_DB0_MARK, LCDOUT16_MARK, IIC2_SCL_MARK, I2C2_SCL_MARK,
+	SCIFA2_TXD_MARK, BPFCLK_MARK, RX2_MARK, DU2_DB1_MARK, LCDOUT17_MARK,
 	IIC2_SDA_MARK, I2C2_SDA_MARK, HSCK0_MARK, TS_SDEN0_MARK,
 	DU2_DG4_MARK, LCDOUT12_MARK, HCTS0_N_C_MARK, HRX0_MARK,
 	DU2_DB2_MARK, LCDOUT18_MARK, HTX0_MARK, DU2_DB3_MARK,
@@ -981,6 +982,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP2_21_18, VI0_R4, SEL_VI0_0),
 	PINMUX_IPSR_MODSEL_DATA(IP2_21_18, VI0_R4_B, SEL_VI0_1),
 	PINMUX_IPSR_MODSEL_DATA(IP2_21_18, SCIFB2_RXD_C, SEL_SCIFB2_2),
+	PINMUX_IPSR_MODSEL_DATA(IP2_21_18, RX2_B, SEL_SCIF2_1),
 	PINMUX_IPSR_MODSEL_DATA(IP2_21_18, VI2_DATA0_VI2_B0_B, SEL_VI2_1),
 	PINMUX_IPSR_DATA(IP2_25_22, A9),
 	PINMUX_IPSR_MODSEL_DATA(IP2_25_22, SCIFA1_CTS_N_B, SEL_SCIFA1_1),
@@ -988,6 +990,7 @@ static const pinmux_enum_t pinmux_data[] = {
 	PINMUX_IPSR_MODSEL_DATA(IP2_25_22, VI0_R5, SEL_VI0_0),
 	PINMUX_IPSR_MODSEL_DATA(IP2_25_22, VI0_R5_B, SEL_VI0_1),
 	PINMUX_IPSR_MODSEL_DATA(IP2_25_22, SCIFB2_TXD_C, SEL_SCIFB2_2),
+	PINMUX_IPSR_MODSEL_DATA(IP2_25_22, TX2_B, SEL_SCIF2_1),
 	PINMUX_IPSR_MODSEL_DATA(IP2_25_22, VI2_DATA1_VI2_B1_B, SEL_VI2_1),
 	PINMUX_IPSR_DATA(IP2_28_26, A10),
 	PINMUX_IPSR_MODSEL_DATA(IP2_28_26, SSI_SDATA5_B, SEL_SSI5_1),
@@ -1696,18 +1699,21 @@ static const pinmux_enum_t pinmux_data[] = {
 
 	PINMUX_IPSR_MODSEL_DATA(IP15_2_0, SCIFA2_SCK, SEL_SCIFA2_0),
 	PINMUX_IPSR_MODSEL_DATA(IP15_2_0, FMCLK, SEL_FM_0),
+	PINMUX_IPSR_DATA(IP15_2_0, SCK2),
 	PINMUX_IPSR_MODSEL_DATA(IP15_2_0, MSIOF3_SCK, SEL_SOF3_0),
 	PINMUX_IPSR_DATA(IP15_2_0, DU2_DG7),
 	PINMUX_IPSR_DATA(IP15_2_0, LCDOUT15),
 	PINMUX_IPSR_MODSEL_DATA(IP15_2_0, SCIF_CLK_B, SEL_SCIFCLK_0),
 	PINMUX_IPSR_MODSEL_DATA(IP15_5_3, SCIFA2_RXD, SEL_SCIFA2_0),
 	PINMUX_IPSR_MODSEL_DATA(IP15_5_3, FMIN, SEL_FM_0),
+	PINMUX_IPSR_MODSEL_DATA(IP15_5_3, TX2, SEL_SCIF2_0),
 	PINMUX_IPSR_DATA(IP15_5_3, DU2_DB0),
 	PINMUX_IPSR_DATA(IP15_5_3, LCDOUT16),
 	PINMUX_IPSR_MODSEL_DATA(IP15_5_3, IIC2_SCL, SEL_IIC2_0),
 	PINMUX_IPSR_MODSEL_DATA(IP15_5_3, I2C2_SCL, SEL_I2C2_0),
 	PINMUX_IPSR_MODSEL_DATA(IP15_8_6, SCIFA2_TXD, SEL_SCIFA2_0),
 	PINMUX_IPSR_MODSEL_DATA(IP15_8_6, BPFCLK, SEL_FM_0),
+	PINMUX_IPSR_MODSEL_DATA(IP15_8_6, RX2, SEL_SCIF2_0),
 	PINMUX_IPSR_DATA(IP15_8_6, DU2_DB1),
 	PINMUX_IPSR_DATA(IP15_8_6, LCDOUT17),
 	PINMUX_IPSR_MODSEL_DATA(IP15_8_6, IIC2_SDA, SEL_IIC2_0),
@@ -3286,11 +3292,11 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_VI0_R6_B, FN_VI2_DATA2_VI2_B2_B, 0, 0,
 		/* IP2_25_22 [4] */
 		FN_A9, FN_SCIFA1_CTS_N_B, FN_SSI_WS5_B, FN_VI0_R5,
-		FN_VI0_R5_B, FN_SCIFB2_TXD_C, 0, FN_VI2_DATA1_VI2_B1_B,
+		FN_VI0_R5_B, FN_SCIFB2_TXD_C, FN_TX2_B, FN_VI2_DATA1_VI2_B1_B,
 		0, 0, 0, 0, 0, 0, 0, 0,
 		/* IP2_21_18 [4] */
 		FN_A8, FN_SCIFA1_RXD_B, FN_SSI_SCK5_B, FN_VI0_R4,
-		FN_VI0_R4_B, FN_SCIFB2_RXD_C, 0, FN_VI2_DATA0_VI2_B0_B,
+		FN_VI0_R4_B, FN_SCIFB2_RXD_C, FN_RX2_B, FN_VI2_DATA0_VI2_B0_B,
 		0, 0, 0, 0, 0, 0, 0, 0,
 		/* IP2_17_15 [3] */
 		FN_A7, FN_SCIFA1_SCK_B, FN_AUDIO_CLKOUT_B, FN_TPU0TO3,
@@ -3770,13 +3776,13 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_HSCK0, FN_TS_SDEN0, FN_DU2_DG4, FN_LCDOUT12, FN_HCTS0_N_C,
 		0, 0, 0,
 		/* IP15_8_6 [3] */
-		FN_SCIFA2_TXD, FN_BPFCLK, 0, FN_DU2_DB1, FN_LCDOUT17,
+		FN_SCIFA2_TXD, FN_BPFCLK, FN_RX2, FN_DU2_DB1, FN_LCDOUT17,
 		FN_IIC2_SDA, FN_I2C2_SDA, 0,
 		/* IP15_5_3 [3] */
-		FN_SCIFA2_RXD, FN_FMIN, 0, FN_DU2_DB0, FN_LCDOUT16,
+		FN_SCIFA2_RXD, FN_FMIN, FN_TX2, FN_DU2_DB0, FN_LCDOUT16,
 		FN_IIC2_SCL, FN_I2C2_SCL, 0,
 		/* IP15_2_0 [3] */
-		FN_SCIFA2_SCK, FN_FMCLK, 0, FN_MSIOF3_SCK, FN_DU2_DG7,
+		FN_SCIFA2_SCK, FN_FMCLK, FN_SCK2, FN_MSIOF3_SCK, FN_DU2_DG7,
 		FN_LCDOUT15, FN_SCIF_CLK_B, 0, }
 	},
 	{ PINMUX_CFG_REG_VAR("IPSR16", 0xE6060160, 32,
@@ -3881,8 +3887,8 @@ static struct pinmux_cfg_reg pinmux_config_regs[] = {
 		FN_SEL_CAN1_0, FN_SEL_CAN1_1,
 		/* RESERVED [2] */
 		0, 0, 0, 0,
-		/* RESERVED [1] (actually TX2, RX2 vs. TX2_B, RX2_B of SCIF2) */
-		0, 0,
+		/* SEL_SCIF2 [1] */
+		FN_SEL_SCIF2_0, FN_SEL_SCIF2_1,
 		/* SEL_ADI [1] */
 		FN_SEL_ADI_0, FN_SEL_ADI_1,
 		/* SEL_SSP [1] */
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:16 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:16 +0200
Subject: [PATCH 10/14] sh-pfc: r8a7790: Sort pin groups and functions
 alphabetically
In-Reply-To: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671720-8794-11-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Navigating through the source code is hard enough without having to
manually search for groups and functions.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 560 +++++++++++++++++------------------
 1 file changed, 280 insertions(+), 280 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index 62ac0d2..7f7b2bd 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -1814,128 +1814,6 @@ static const unsigned int eth_rmii_mux[] = {
 	ETH_RXD0_MARK, ETH_RXD1_MARK, ETH_RX_ER_MARK, ETH_CRS_DV_MARK,
 	ETH_TXD0_MARK, ETH_TXD1_MARK, ETH_TX_EN_MARK, ETH_REF_CLK_MARK,
 };
-/* - INTC ------------------------------------------------------------------- */
-static const unsigned int intc_irq0_pins[] = {
-	/* IRQ */
-	RCAR_GP_PIN(1, 25),
-};
-static const unsigned int intc_irq0_mux[] = {
-	IRQ0_MARK,
-};
-static const unsigned int intc_irq1_pins[] = {
-	/* IRQ */
-	RCAR_GP_PIN(1, 27),
-};
-static const unsigned int intc_irq1_mux[] = {
-	IRQ1_MARK,
-};
-static const unsigned int intc_irq2_pins[] = {
-	/* IRQ */
-	RCAR_GP_PIN(1, 29),
-};
-static const unsigned int intc_irq2_mux[] = {
-	IRQ2_MARK,
-};
-static const unsigned int intc_irq3_pins[] = {
-	/* IRQ */
-	RCAR_GP_PIN(1, 23),
-};
-static const unsigned int intc_irq3_mux[] = {
-	IRQ3_MARK,
-};
-/* - SCIF0 ----------------------------------------------------------------- */
-static const unsigned int scif0_data_pins[] = {
-	/* RX, TX */
-	RCAR_GP_PIN(4, 28), RCAR_GP_PIN(4, 29),
-};
-static const unsigned int scif0_data_mux[] = {
-	RX0_MARK, TX0_MARK,
-};
-static const unsigned int scif0_clk_pins[] = {
-	/* SCK */
-	RCAR_GP_PIN(4, 27),
-};
-static const unsigned int scif0_clk_mux[] = {
-	SCK0_MARK,
-};
-static const unsigned int scif0_ctrl_pins[] = {
-	/* RTS, CTS */
-	RCAR_GP_PIN(4, 31), RCAR_GP_PIN(4, 30),
-};
-static const unsigned int scif0_ctrl_mux[] = {
-	RTS0_N_MARK, CTS0_N_MARK,
-};
-static const unsigned int scif0_data_b_pins[] = {
-	/* RX, TX */
-	RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
-};
-static const unsigned int scif0_data_b_mux[] = {
-	RX0_B_MARK, TX0_B_MARK,
-};
-/* - SCIF1 ----------------------------------------------------------------- */
-static const unsigned int scif1_data_pins[] = {
-	/* RX, TX */
-	RCAR_GP_PIN(5, 0), RCAR_GP_PIN(5, 1),
-};
-static const unsigned int scif1_data_mux[] = {
-	RX1_MARK, TX1_MARK,
-};
-static const unsigned int scif1_clk_pins[] = {
-	/* SCK */
-	RCAR_GP_PIN(4, 20),
-};
-static const unsigned int scif1_clk_mux[] = {
-	SCK1_MARK,
-};
-static const unsigned int scif1_ctrl_pins[] = {
-	/* RTS, CTS */
-	RCAR_GP_PIN(5, 3), RCAR_GP_PIN(5, 2),
-};
-static const unsigned int scif1_ctrl_mux[] = {
-	RTS1_N_MARK, CTS1_N_MARK,
-};
-static const unsigned int scif1_data_b_pins[] = {
-	/* RX, TX */
-	RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15),
-};
-static const unsigned int scif1_data_b_mux[] = {
-	RX1_B_MARK, TX1_B_MARK,
-};
-static const unsigned int scif1_data_c_pins[] = {
-	/* RX, TX */
-	RCAR_GP_PIN(4, 1), RCAR_GP_PIN(4, 2),
-};
-static const unsigned int scif1_data_c_mux[] = {
-	RX1_C_MARK, TX1_C_MARK,
-};
-static const unsigned int scif1_data_d_pins[] = {
-	/* RX, TX */
-	RCAR_GP_PIN(3, 18), RCAR_GP_PIN(3, 19),
-};
-static const unsigned int scif1_data_d_mux[] = {
-	RX1_D_MARK, TX1_D_MARK,
-};
-static const unsigned int scif1_clk_d_pins[] = {
-	/* SCK */
-	RCAR_GP_PIN(3, 17),
-};
-static const unsigned int scif1_clk_d_mux[] = {
-	SCK1_D_MARK,
-};
-static const unsigned int scif1_data_e_pins[] = {
-	/* RX, TX */
-	RCAR_GP_PIN(2, 21), RCAR_GP_PIN(2, 22),
-};
-static const unsigned int scif1_data_e_mux[] = {
-	RX1_E_MARK, TX1_E_MARK,
-};
-static const unsigned int scif1_clk_e_pins[] = {
-	/* SCK */
-	RCAR_GP_PIN(2, 20),
-};
-static const unsigned int scif1_clk_e_mux[] = {
-	SCK1_E_MARK,
-};
 /* - HSCIF0 ----------------------------------------------------------------- */
 static const unsigned int hscif0_data_pins[] = {
 	/* RX, TX */
@@ -2047,29 +1925,219 @@ static const unsigned int hscif1_ctrl_pins[] = {
 	/* RTS, CTS */
 	RCAR_GP_PIN(4, 31), RCAR_GP_PIN(4, 30),
 };
-static const unsigned int hscif1_ctrl_mux[] = {
-	HRTS1_N_MARK, HCTS1_N_MARK,
+static const unsigned int hscif1_ctrl_mux[] = {
+	HRTS1_N_MARK, HCTS1_N_MARK,
+};
+static const unsigned int hscif1_data_b_pins[] = {
+	/* RX, TX */
+	RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 18),
+};
+static const unsigned int hscif1_data_b_mux[] = {
+	HRX1_B_MARK, HTX1_B_MARK,
+};
+static const unsigned int hscif1_clk_b_pins[] = {
+	/* SCK */
+	RCAR_GP_PIN(1, 28),
+};
+static const unsigned int hscif1_clk_b_mux[] = {
+	HSCK1_B_MARK,
+};
+static const unsigned int hscif1_ctrl_b_pins[] = {
+	/* RTS, CTS */
+	RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 13),
+};
+static const unsigned int hscif1_ctrl_b_mux[] = {
+	HRTS1_N_B_MARK, HCTS1_N_B_MARK,
+};
+/* - INTC ------------------------------------------------------------------- */
+static const unsigned int intc_irq0_pins[] = {
+	/* IRQ */
+	RCAR_GP_PIN(1, 25),
+};
+static const unsigned int intc_irq0_mux[] = {
+	IRQ0_MARK,
+};
+static const unsigned int intc_irq1_pins[] = {
+	/* IRQ */
+	RCAR_GP_PIN(1, 27),
+};
+static const unsigned int intc_irq1_mux[] = {
+	IRQ1_MARK,
+};
+static const unsigned int intc_irq2_pins[] = {
+	/* IRQ */
+	RCAR_GP_PIN(1, 29),
+};
+static const unsigned int intc_irq2_mux[] = {
+	IRQ2_MARK,
+};
+static const unsigned int intc_irq3_pins[] = {
+	/* IRQ */
+	RCAR_GP_PIN(1, 23),
+};
+static const unsigned int intc_irq3_mux[] = {
+	IRQ3_MARK,
+};
+/* - MMCIF0 ----------------------------------------------------------------- */
+static const unsigned int mmc0_data1_pins[] = {
+	/* D[0] */
+	RCAR_GP_PIN(3, 18),
+};
+static const unsigned int mmc0_data1_mux[] = {
+	MMC0_D0_MARK,
+};
+static const unsigned int mmc0_data4_pins[] = {
+	/* D[0:3] */
+	RCAR_GP_PIN(3, 18), RCAR_GP_PIN(3, 19),
+	RCAR_GP_PIN(3, 20), RCAR_GP_PIN(3, 21),
+};
+static const unsigned int mmc0_data4_mux[] = {
+	MMC0_D0_MARK, MMC0_D1_MARK, MMC0_D2_MARK, MMC0_D3_MARK,
+};
+static const unsigned int mmc0_data8_pins[] = {
+	/* D[0:7] */
+	RCAR_GP_PIN(3, 18), RCAR_GP_PIN(3, 19),
+	RCAR_GP_PIN(3, 20), RCAR_GP_PIN(3, 21),
+	RCAR_GP_PIN(3, 22), RCAR_GP_PIN(3, 23),
+	RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
+};
+static const unsigned int mmc0_data8_mux[] = {
+	MMC0_D0_MARK, MMC0_D1_MARK, MMC0_D2_MARK, MMC0_D3_MARK,
+	MMC0_D4_MARK, MMC0_D5_MARK, MMC0_D6_MARK, MMC0_D7_MARK,
+};
+static const unsigned int mmc0_ctrl_pins[] = {
+	/* CLK, CMD */
+	RCAR_GP_PIN(3, 16), RCAR_GP_PIN(3, 17),
+};
+static const unsigned int mmc0_ctrl_mux[] = {
+	MMC0_CLK_MARK, MMC0_CMD_MARK,
+};
+/* - MMCIF1 ----------------------------------------------------------------- */
+static const unsigned int mmc1_data1_pins[] = {
+	/* D[0] */
+	RCAR_GP_PIN(3, 26),
+};
+static const unsigned int mmc1_data1_mux[] = {
+	MMC1_D0_MARK,
+};
+static const unsigned int mmc1_data4_pins[] = {
+	/* D[0:3] */
+	RCAR_GP_PIN(3, 26), RCAR_GP_PIN(3, 27),
+	RCAR_GP_PIN(3, 28), RCAR_GP_PIN(3, 29),
+};
+static const unsigned int mmc1_data4_mux[] = {
+	MMC1_D0_MARK, MMC1_D1_MARK, MMC1_D2_MARK, MMC1_D3_MARK,
+};
+static const unsigned int mmc1_data8_pins[] = {
+	/* D[0:7] */
+	RCAR_GP_PIN(3, 26), RCAR_GP_PIN(3, 27),
+	RCAR_GP_PIN(3, 28), RCAR_GP_PIN(3, 29),
+	RCAR_GP_PIN(3, 30), RCAR_GP_PIN(3, 31),
+	RCAR_GP_PIN(3, 14), RCAR_GP_PIN(3, 15),
+};
+static const unsigned int mmc1_data8_mux[] = {
+	MMC1_D0_MARK, MMC1_D1_MARK, MMC1_D2_MARK, MMC1_D3_MARK,
+	MMC1_D4_MARK, MMC1_D5_MARK, MMC1_D6_MARK, MMC1_D7_MARK,
+};
+static const unsigned int mmc1_ctrl_pins[] = {
+	/* CLK, CMD */
+	RCAR_GP_PIN(3, 24), RCAR_GP_PIN(3, 25),
+};
+static const unsigned int mmc1_ctrl_mux[] = {
+	MMC1_CLK_MARK, MMC1_CMD_MARK,
+};
+/* - SCIF0 ------------------------------------------------------------------ */
+static const unsigned int scif0_data_pins[] = {
+	/* RX, TX */
+	RCAR_GP_PIN(4, 28), RCAR_GP_PIN(4, 29),
+};
+static const unsigned int scif0_data_mux[] = {
+	RX0_MARK, TX0_MARK,
+};
+static const unsigned int scif0_clk_pins[] = {
+	/* SCK */
+	RCAR_GP_PIN(4, 27),
+};
+static const unsigned int scif0_clk_mux[] = {
+	SCK0_MARK,
+};
+static const unsigned int scif0_ctrl_pins[] = {
+	/* RTS, CTS */
+	RCAR_GP_PIN(4, 31), RCAR_GP_PIN(4, 30),
+};
+static const unsigned int scif0_ctrl_mux[] = {
+	RTS0_N_MARK, CTS0_N_MARK,
+};
+static const unsigned int scif0_data_b_pins[] = {
+	/* RX, TX */
+	RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
+};
+static const unsigned int scif0_data_b_mux[] = {
+	RX0_B_MARK, TX0_B_MARK,
+};
+/* - SCIF1 ------------------------------------------------------------------ */
+static const unsigned int scif1_data_pins[] = {
+	/* RX, TX */
+	RCAR_GP_PIN(5, 0), RCAR_GP_PIN(5, 1),
+};
+static const unsigned int scif1_data_mux[] = {
+	RX1_MARK, TX1_MARK,
+};
+static const unsigned int scif1_clk_pins[] = {
+	/* SCK */
+	RCAR_GP_PIN(4, 20),
+};
+static const unsigned int scif1_clk_mux[] = {
+	SCK1_MARK,
+};
+static const unsigned int scif1_ctrl_pins[] = {
+	/* RTS, CTS */
+	RCAR_GP_PIN(5, 3), RCAR_GP_PIN(5, 2),
+};
+static const unsigned int scif1_ctrl_mux[] = {
+	RTS1_N_MARK, CTS1_N_MARK,
+};
+static const unsigned int scif1_data_b_pins[] = {
+	/* RX, TX */
+	RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15),
+};
+static const unsigned int scif1_data_b_mux[] = {
+	RX1_B_MARK, TX1_B_MARK,
+};
+static const unsigned int scif1_data_c_pins[] = {
+	/* RX, TX */
+	RCAR_GP_PIN(4, 1), RCAR_GP_PIN(4, 2),
+};
+static const unsigned int scif1_data_c_mux[] = {
+	RX1_C_MARK, TX1_C_MARK,
 };
-static const unsigned int hscif1_data_b_pins[] = {
+static const unsigned int scif1_data_d_pins[] = {
 	/* RX, TX */
-	RCAR_GP_PIN(1, 12), RCAR_GP_PIN(1, 18),
+	RCAR_GP_PIN(3, 18), RCAR_GP_PIN(3, 19),
 };
-static const unsigned int hscif1_data_b_mux[] = {
-	HRX1_B_MARK, HTX1_B_MARK,
+static const unsigned int scif1_data_d_mux[] = {
+	RX1_D_MARK, TX1_D_MARK,
 };
-static const unsigned int hscif1_clk_b_pins[] = {
+static const unsigned int scif1_clk_d_pins[] = {
 	/* SCK */
-	RCAR_GP_PIN(1, 28),
+	RCAR_GP_PIN(3, 17),
 };
-static const unsigned int hscif1_clk_b_mux[] = {
-	HSCK1_B_MARK,
+static const unsigned int scif1_clk_d_mux[] = {
+	SCK1_D_MARK,
 };
-static const unsigned int hscif1_ctrl_b_pins[] = {
-	/* RTS, CTS */
-	RCAR_GP_PIN(1, 14), RCAR_GP_PIN(1, 13),
+static const unsigned int scif1_data_e_pins[] = {
+	/* RX, TX */
+	RCAR_GP_PIN(2, 21), RCAR_GP_PIN(2, 22),
 };
-static const unsigned int hscif1_ctrl_b_mux[] = {
-	HRTS1_N_B_MARK, HCTS1_N_B_MARK,
+static const unsigned int scif1_data_e_mux[] = {
+	RX1_E_MARK, TX1_E_MARK,
+};
+static const unsigned int scif1_clk_e_pins[] = {
+	/* SCK */
+	RCAR_GP_PIN(2, 20),
+};
+static const unsigned int scif1_clk_e_mux[] = {
+	SCK1_E_MARK,
 };
 /* - SCIFA0 ----------------------------------------------------------------- */
 static const unsigned int scifa0_data_pins[] = {
@@ -2434,103 +2502,6 @@ static const unsigned int scifb2_data_c_pins[] = {
 static const unsigned int scifb2_data_c_mux[] = {
 	SCIFB2_RXD_C_MARK, SCIFB2_TXD_C_MARK,
 };
-/* - TPU0 ------------------------------------------------------------------- */
-static const unsigned int tpu0_to0_pins[] = {
-	/* TO */
-	RCAR_GP_PIN(0, 20),
-};
-static const unsigned int tpu0_to0_mux[] = {
-	TPU0TO0_MARK,
-};
-static const unsigned int tpu0_to1_pins[] = {
-	/* TO */
-	RCAR_GP_PIN(0, 21),
-};
-static const unsigned int tpu0_to1_mux[] = {
-	TPU0TO1_MARK,
-};
-static const unsigned int tpu0_to2_pins[] = {
-	/* TO */
-	RCAR_GP_PIN(0, 22),
-};
-static const unsigned int tpu0_to2_mux[] = {
-	TPU0TO2_MARK,
-};
-static const unsigned int tpu0_to3_pins[] = {
-	/* TO */
-	RCAR_GP_PIN(0, 23),
-};
-static const unsigned int tpu0_to3_mux[] = {
-	TPU0TO3_MARK,
-};
-/* - MMCIF0 ----------------------------------------------------------------- */
-static const unsigned int mmc0_data1_pins[] = {
-	/* D[0] */
-	RCAR_GP_PIN(3, 18),
-};
-static const unsigned int mmc0_data1_mux[] = {
-	MMC0_D0_MARK,
-};
-static const unsigned int mmc0_data4_pins[] = {
-	/* D[0:3] */
-	RCAR_GP_PIN(3, 18), RCAR_GP_PIN(3, 19),
-	RCAR_GP_PIN(3, 20), RCAR_GP_PIN(3, 21),
-};
-static const unsigned int mmc0_data4_mux[] = {
-	MMC0_D0_MARK, MMC0_D1_MARK, MMC0_D2_MARK, MMC0_D3_MARK,
-};
-static const unsigned int mmc0_data8_pins[] = {
-	/* D[0:7] */
-	RCAR_GP_PIN(3, 18), RCAR_GP_PIN(3, 19),
-	RCAR_GP_PIN(3, 20), RCAR_GP_PIN(3, 21),
-	RCAR_GP_PIN(3, 22), RCAR_GP_PIN(3, 23),
-	RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
-};
-static const unsigned int mmc0_data8_mux[] = {
-	MMC0_D0_MARK, MMC0_D1_MARK, MMC0_D2_MARK, MMC0_D3_MARK,
-	MMC0_D4_MARK, MMC0_D5_MARK, MMC0_D6_MARK, MMC0_D7_MARK,
-};
-static const unsigned int mmc0_ctrl_pins[] = {
-	/* CLK, CMD */
-	RCAR_GP_PIN(3, 16), RCAR_GP_PIN(3, 17),
-};
-static const unsigned int mmc0_ctrl_mux[] = {
-	MMC0_CLK_MARK, MMC0_CMD_MARK,
-};
-/* - MMCIF1 ----------------------------------------------------------------- */
-static const unsigned int mmc1_data1_pins[] = {
-	/* D[0] */
-	RCAR_GP_PIN(3, 26),
-};
-static const unsigned int mmc1_data1_mux[] = {
-	MMC1_D0_MARK,
-};
-static const unsigned int mmc1_data4_pins[] = {
-	/* D[0:3] */
-	RCAR_GP_PIN(3, 26), RCAR_GP_PIN(3, 27),
-	RCAR_GP_PIN(3, 28), RCAR_GP_PIN(3, 29),
-};
-static const unsigned int mmc1_data4_mux[] = {
-	MMC1_D0_MARK, MMC1_D1_MARK, MMC1_D2_MARK, MMC1_D3_MARK,
-};
-static const unsigned int mmc1_data8_pins[] = {
-	/* D[0:7] */
-	RCAR_GP_PIN(3, 26), RCAR_GP_PIN(3, 27),
-	RCAR_GP_PIN(3, 28), RCAR_GP_PIN(3, 29),
-	RCAR_GP_PIN(3, 30), RCAR_GP_PIN(3, 31),
-	RCAR_GP_PIN(3, 14), RCAR_GP_PIN(3, 15),
-};
-static const unsigned int mmc1_data8_mux[] = {
-	MMC1_D0_MARK, MMC1_D1_MARK, MMC1_D2_MARK, MMC1_D3_MARK,
-	MMC1_D4_MARK, MMC1_D5_MARK, MMC1_D6_MARK, MMC1_D7_MARK,
-};
-static const unsigned int mmc1_ctrl_pins[] = {
-	/* CLK, CMD */
-	RCAR_GP_PIN(3, 24), RCAR_GP_PIN(3, 25),
-};
-static const unsigned int mmc1_ctrl_mux[] = {
-	MMC1_CLK_MARK, MMC1_CMD_MARK,
-};
 /* - SDHI0 ------------------------------------------------------------------ */
 static const unsigned int sdhi0_data1_pins[] = {
 	/* D0 */
@@ -2675,6 +2646,35 @@ static const unsigned int sdhi3_wp_pins[] = {
 static const unsigned int sdhi3_wp_mux[] = {
 	SD3_WP_MARK,
 };
+/* - TPU0 ------------------------------------------------------------------- */
+static const unsigned int tpu0_to0_pins[] = {
+	/* TO */
+	RCAR_GP_PIN(0, 20),
+};
+static const unsigned int tpu0_to0_mux[] = {
+	TPU0TO0_MARK,
+};
+static const unsigned int tpu0_to1_pins[] = {
+	/* TO */
+	RCAR_GP_PIN(0, 21),
+};
+static const unsigned int tpu0_to1_mux[] = {
+	TPU0TO1_MARK,
+};
+static const unsigned int tpu0_to2_pins[] = {
+	/* TO */
+	RCAR_GP_PIN(0, 22),
+};
+static const unsigned int tpu0_to2_mux[] = {
+	TPU0TO2_MARK,
+};
+static const unsigned int tpu0_to3_pins[] = {
+	/* TO */
+	RCAR_GP_PIN(0, 23),
+};
+static const unsigned int tpu0_to3_mux[] = {
+	TPU0TO3_MARK,
+};
 
 static const struct sh_pfc_pin_group pinmux_groups[] = {
 	SH_PFC_PIN_GROUP(eth_link),
@@ -2809,6 +2809,31 @@ static const char * const eth_groups[] = {
 	"eth_rmii",
 };
 
+static const char * const hscif0_groups[] = {
+	"hscif0_data",
+	"hscif0_clk",
+	"hscif0_ctrl",
+	"hscif0_data_b",
+	"hscif0_ctrl_b",
+	"hscif0_data_c",
+	"hscif0_ctrl_c",
+	"hscif0_data_d",
+	"hscif0_ctrl_d",
+	"hscif0_data_e",
+	"hscif0_ctrl_e",
+	"hscif0_data_f",
+	"hscif0_ctrl_f",
+};
+
+static const char * const hscif1_groups[] = {
+	"hscif1_data",
+	"hscif1_clk",
+	"hscif1_ctrl",
+	"hscif1_data_b",
+	"hscif1_clk_b",
+	"hscif1_ctrl_b",
+};
+
 static const char * const intc_groups[] = {
 	"intc_irq0",
 	"intc_irq1",
@@ -2816,6 +2841,20 @@ static const char * const intc_groups[] = {
 	"intc_irq3",
 };
 
+static const char * const mmc0_groups[] = {
+	"mmc0_data1",
+	"mmc0_data4",
+	"mmc0_data8",
+	"mmc0_ctrl",
+};
+
+static const char * const mmc1_groups[] = {
+	"mmc1_data1",
+	"mmc1_data4",
+	"mmc1_data8",
+	"mmc1_ctrl",
+};
+
 static const char * const scif0_groups[] = {
 	"scif0_data",
 	"scif0_clk",
@@ -2835,31 +2874,6 @@ static const char * const scif1_groups[] = {
 	"scif1_clk_e",
 };
 
-static const char * const hscif0_groups[] = {
-	"hscif0_data",
-	"hscif0_clk",
-	"hscif0_ctrl",
-	"hscif0_data_b",
-	"hscif0_ctrl_b",
-	"hscif0_data_c",
-	"hscif0_ctrl_c",
-	"hscif0_data_d",
-	"hscif0_ctrl_d",
-	"hscif0_data_e",
-	"hscif0_ctrl_e",
-	"hscif0_data_f",
-	"hscif0_ctrl_f",
-};
-
-static const char * const hscif1_groups[] = {
-	"hscif1_data",
-	"hscif1_clk",
-	"hscif1_ctrl",
-	"hscif1_data_b",
-	"hscif1_clk_b",
-	"hscif1_ctrl_b",
-};
-
 static const char * const scifa0_groups[] = {
 	"scifa0_data",
 	"scifa0_clk",
@@ -2929,27 +2943,6 @@ static const char * const scifb2_groups[] = {
 	"scifb2_data_c",
 };
 
-static const char * const tpu0_groups[] = {
-	"tpu0_to0",
-	"tpu0_to1",
-	"tpu0_to2",
-	"tpu0_to3",
-};
-
-static const char * const mmc0_groups[] = {
-	"mmc0_data1",
-	"mmc0_data4",
-	"mmc0_data8",
-	"mmc0_ctrl",
-};
-
-static const char * const mmc1_groups[] = {
-	"mmc1_data1",
-	"mmc1_data4",
-	"mmc1_data8",
-	"mmc1_ctrl",
-};
-
 static const char * const sdhi0_groups[] = {
 	"sdhi0_data1",
 	"sdhi0_data4",
@@ -2982,6 +2975,13 @@ static const char * const sdhi3_groups[] = {
 	"sdhi3_wp",
 };
 
+static const char * const tpu0_groups[] = {
+	"tpu0_to0",
+	"tpu0_to1",
+	"tpu0_to2",
+	"tpu0_to3",
+};
+
 static const struct sh_pfc_function pinmux_functions[] = {
 	SH_PFC_FUNCTION(eth),
 	SH_PFC_FUNCTION(hscif0),
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:17 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:17 +0200
Subject: [PATCH 11/14] sh-pfc: r8a7790: Add MSIOF pin groups and functions
In-Reply-To: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671720-8794-12-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

From: Kunihito Higashiyama <kunihito.higashiyama.ur at renesas.com>

Signed-off-by: Kunihito Higashiyama <kunihito.higashiyama.ur at renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 236 +++++++++++++++++++++++++++++++++++
 1 file changed, 236 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index 7f7b2bd..9acb0e5 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -2046,6 +2046,178 @@ static const unsigned int mmc1_ctrl_pins[] = {
 static const unsigned int mmc1_ctrl_mux[] = {
 	MMC1_CLK_MARK, MMC1_CMD_MARK,
 };
+/* - MSIOF0 ----------------------------------------------------------------- */
+static const unsigned int msiof0_clk_pins[] = {
+	/* SCK */
+	RCAR_GP_PIN(5, 12),
+};
+static const unsigned int msiof0_clk_mux[] = {
+	MSIOF0_SCK_MARK,
+};
+static const unsigned int msiof0_sync_pins[] = {
+	/* SYNC */
+	RCAR_GP_PIN(5, 13),
+};
+static const unsigned int msiof0_sync_mux[] = {
+	MSIOF0_SYNC_MARK,
+};
+static const unsigned int msiof0_ss1_pins[] = {
+	/* SS1 */
+	RCAR_GP_PIN(5, 14),
+};
+static const unsigned int msiof0_ss1_mux[] = {
+	MSIOF0_SS1_MARK,
+};
+static const unsigned int msiof0_ss2_pins[] = {
+	/* SS2 */
+	RCAR_GP_PIN(5, 16),
+};
+static const unsigned int msiof0_ss2_mux[] = {
+	MSIOF0_SS2_MARK,
+};
+static const unsigned int msiof0_rx_pins[] = {
+	/* RXD */
+	RCAR_GP_PIN(5, 17),
+};
+static const unsigned int msiof0_rx_mux[] = {
+	MSIOF0_RXD_MARK,
+};
+static const unsigned int msiof0_tx_pins[] = {
+	/* TXD */
+	RCAR_GP_PIN(5, 15),
+};
+static const unsigned int msiof0_tx_mux[] = {
+	MSIOF0_TXD_MARK,
+};
+/* - MSIOF1 ----------------------------------------------------------------- */
+static const unsigned int msiof1_clk_pins[] = {
+	/* SCK */
+	RCAR_GP_PIN(4, 8),
+};
+static const unsigned int msiof1_clk_mux[] = {
+	MSIOF1_SCK_MARK,
+};
+static const unsigned int msiof1_sync_pins[] = {
+	/* SYNC */
+	RCAR_GP_PIN(4, 9),
+};
+static const unsigned int msiof1_sync_mux[] = {
+	MSIOF1_SYNC_MARK,
+};
+static const unsigned int msiof1_ss1_pins[] = {
+	/* SS1 */
+	RCAR_GP_PIN(4, 10),
+};
+static const unsigned int msiof1_ss1_mux[] = {
+	MSIOF1_SS1_MARK,
+};
+static const unsigned int msiof1_ss2_pins[] = {
+	/* SS2 */
+	RCAR_GP_PIN(4, 11),
+};
+static const unsigned int msiof1_ss2_mux[] = {
+	MSIOF1_SS2_MARK,
+};
+static const unsigned int msiof1_rx_pins[] = {
+	/* RXD */
+	RCAR_GP_PIN(4, 13),
+};
+static const unsigned int msiof1_rx_mux[] = {
+	MSIOF1_RXD_MARK,
+};
+static const unsigned int msiof1_tx_pins[] = {
+	/* TXD */
+	RCAR_GP_PIN(4, 12),
+};
+static const unsigned int msiof1_tx_mux[] = {
+	MSIOF1_TXD_MARK,
+};
+/* - MSIOF2 ----------------------------------------------------------------- */
+static const unsigned int msiof2_clk_pins[] = {
+	/* SCK */
+	RCAR_GP_PIN(0, 27),
+};
+static const unsigned int msiof2_clk_mux[] = {
+	MSIOF2_SCK_MARK,
+};
+static const unsigned int msiof2_sync_pins[] = {
+	/* SYNC */
+	RCAR_GP_PIN(0, 26),
+};
+static const unsigned int msiof2_sync_mux[] = {
+	MSIOF2_SYNC_MARK,
+};
+static const unsigned int msiof2_ss1_pins[] = {
+	/* SS1 */
+	RCAR_GP_PIN(0, 30),
+};
+static const unsigned int msiof2_ss1_mux[] = {
+	MSIOF2_SS1_MARK,
+};
+static const unsigned int msiof2_ss2_pins[] = {
+	/* SS2 */
+	RCAR_GP_PIN(0, 31),
+};
+static const unsigned int msiof2_ss2_mux[] = {
+	MSIOF2_SS2_MARK,
+};
+static const unsigned int msiof2_rx_pins[] = {
+	/* RXD */
+	RCAR_GP_PIN(0, 29),
+};
+static const unsigned int msiof2_rx_mux[] = {
+	MSIOF2_RXD_MARK,
+};
+static const unsigned int msiof2_tx_pins[] = {
+	/* TXD */
+	RCAR_GP_PIN(0, 28),
+};
+static const unsigned int msiof2_tx_mux[] = {
+	MSIOF2_TXD_MARK,
+};
+/* - MSIOF3 ----------------------------------------------------------------- */
+static const unsigned int msiof3_clk_pins[] = {
+	/* SCK */
+	RCAR_GP_PIN(5, 4),
+};
+static const unsigned int msiof3_clk_mux[] = {
+	MSIOF3_SCK_MARK,
+};
+static const unsigned int msiof3_sync_pins[] = {
+	/* SYNC */
+	RCAR_GP_PIN(4, 30),
+};
+static const unsigned int msiof3_sync_mux[] = {
+	MSIOF3_SYNC_MARK,
+};
+static const unsigned int msiof3_ss1_pins[] = {
+	/* SS1 */
+	RCAR_GP_PIN(4, 31),
+};
+static const unsigned int msiof3_ss1_mux[] = {
+	MSIOF3_SS1_MARK,
+};
+static const unsigned int msiof3_ss2_pins[] = {
+	/* SS2 */
+	RCAR_GP_PIN(4, 27),
+};
+static const unsigned int msiof3_ss2_mux[] = {
+	MSIOF3_SS2_MARK,
+};
+static const unsigned int msiof3_rx_pins[] = {
+	/* RXD */
+	RCAR_GP_PIN(5, 2),
+};
+static const unsigned int msiof3_rx_mux[] = {
+	MSIOF3_RXD_MARK,
+};
+static const unsigned int msiof3_tx_pins[] = {
+	/* TXD */
+	RCAR_GP_PIN(5, 3),
+};
+static const unsigned int msiof3_tx_mux[] = {
+	MSIOF3_TXD_MARK,
+};
 /* - SCIF0 ------------------------------------------------------------------ */
 static const unsigned int scif0_data_pins[] = {
 	/* RX, TX */
@@ -2712,6 +2884,30 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
 	SH_PFC_PIN_GROUP(mmc1_data4),
 	SH_PFC_PIN_GROUP(mmc1_data8),
 	SH_PFC_PIN_GROUP(mmc1_ctrl),
+	SH_PFC_PIN_GROUP(msiof0_clk),
+	SH_PFC_PIN_GROUP(msiof0_sync),
+	SH_PFC_PIN_GROUP(msiof0_ss1),
+	SH_PFC_PIN_GROUP(msiof0_ss2),
+	SH_PFC_PIN_GROUP(msiof0_rx),
+	SH_PFC_PIN_GROUP(msiof0_tx),
+	SH_PFC_PIN_GROUP(msiof1_clk),
+	SH_PFC_PIN_GROUP(msiof1_sync),
+	SH_PFC_PIN_GROUP(msiof1_ss1),
+	SH_PFC_PIN_GROUP(msiof1_ss2),
+	SH_PFC_PIN_GROUP(msiof1_rx),
+	SH_PFC_PIN_GROUP(msiof1_tx),
+	SH_PFC_PIN_GROUP(msiof2_clk),
+	SH_PFC_PIN_GROUP(msiof2_sync),
+	SH_PFC_PIN_GROUP(msiof2_ss1),
+	SH_PFC_PIN_GROUP(msiof2_ss2),
+	SH_PFC_PIN_GROUP(msiof2_rx),
+	SH_PFC_PIN_GROUP(msiof2_tx),
+	SH_PFC_PIN_GROUP(msiof3_clk),
+	SH_PFC_PIN_GROUP(msiof3_sync),
+	SH_PFC_PIN_GROUP(msiof3_ss1),
+	SH_PFC_PIN_GROUP(msiof3_ss2),
+	SH_PFC_PIN_GROUP(msiof3_rx),
+	SH_PFC_PIN_GROUP(msiof3_tx),
 	SH_PFC_PIN_GROUP(scif0_data),
 	SH_PFC_PIN_GROUP(scif0_clk),
 	SH_PFC_PIN_GROUP(scif0_ctrl),
@@ -2855,6 +3051,42 @@ static const char * const mmc1_groups[] = {
 	"mmc1_ctrl",
 };
 
+static const char * const msiof0_groups[] = {
+	"msiof0_clk",
+	"msiof0_sync",
+	"msiof0_ss1",
+	"msiof0_ss2",
+	"msiof0_rx",
+	"msiof0_tx",
+};
+
+static const char * const msiof1_groups[] = {
+	"msiof1_clk",
+	"msiof1_sync",
+	"msiof1_ss1",
+	"msiof1_ss2",
+	"msiof1_rx",
+	"msiof1_tx",
+};
+
+static const char * const msiof2_groups[] = {
+	"msiof2_clk",
+	"msiof2_sync",
+	"msiof2_ss1",
+	"msiof2_ss2",
+	"msiof2_rx",
+	"msiof2_tx",
+};
+
+static const char * const msiof3_groups[] = {
+	"msiof3_clk",
+	"msiof3_sync",
+	"msiof3_ss1",
+	"msiof3_ss2",
+	"msiof3_rx",
+	"msiof3_tx",
+};
+
 static const char * const scif0_groups[] = {
 	"scif0_data",
 	"scif0_clk",
@@ -2989,6 +3221,10 @@ static const struct sh_pfc_function pinmux_functions[] = {
 	SH_PFC_FUNCTION(intc),
 	SH_PFC_FUNCTION(mmc0),
 	SH_PFC_FUNCTION(mmc1),
+	SH_PFC_FUNCTION(msiof0),
+	SH_PFC_FUNCTION(msiof1),
+	SH_PFC_FUNCTION(msiof2),
+	SH_PFC_FUNCTION(msiof3),
 	SH_PFC_FUNCTION(scif0),
 	SH_PFC_FUNCTION(scif1),
 	SH_PFC_FUNCTION(scifa0),
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:18 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:18 +0200
Subject: [PATCH 12/14] sh-pfc: r8a7790: Add SCIF2 pin groups and functions
In-Reply-To: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671720-8794-13-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index 9acb0e5..2fd904f 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -2311,6 +2311,28 @@ static const unsigned int scif1_clk_e_pins[] = {
 static const unsigned int scif1_clk_e_mux[] = {
 	SCK1_E_MARK,
 };
+/* - SCIF2 ------------------------------------------------------------------ */
+static const unsigned int scif2_data_pins[] = {
+	/* RX, TX */
+	RCAR_GP_PIN(5, 6), RCAR_GP_PIN(5, 5),
+};
+static const unsigned int scif2_data_mux[] = {
+	RX2_MARK, TX2_MARK,
+};
+static const unsigned int scif2_clk_pins[] = {
+	/* SCK */
+	RCAR_GP_PIN(5, 4),
+};
+static const unsigned int scif2_clk_mux[] = {
+	SCK2_MARK,
+};
+static const unsigned int scif2_data_b_pins[] = {
+	/* RX, TX */
+	RCAR_GP_PIN(0, 24), RCAR_GP_PIN(0, 25),
+};
+static const unsigned int scif2_data_b_mux[] = {
+	RX2_B_MARK, TX2_B_MARK,
+};
 /* - SCIFA0 ----------------------------------------------------------------- */
 static const unsigned int scifa0_data_pins[] = {
 	/* RXD, TXD */
@@ -2921,6 +2943,9 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
 	SH_PFC_PIN_GROUP(scif1_clk_d),
 	SH_PFC_PIN_GROUP(scif1_data_e),
 	SH_PFC_PIN_GROUP(scif1_clk_e),
+	SH_PFC_PIN_GROUP(scif2_data),
+	SH_PFC_PIN_GROUP(scif2_clk),
+	SH_PFC_PIN_GROUP(scif2_data_b),
 	SH_PFC_PIN_GROUP(scifa0_data),
 	SH_PFC_PIN_GROUP(scifa0_clk),
 	SH_PFC_PIN_GROUP(scifa0_ctrl),
@@ -3106,6 +3131,12 @@ static const char * const scif1_groups[] = {
 	"scif1_clk_e",
 };
 
+static const char * const scif2_groups[] = {
+	"scif2_data",
+	"scif2_clk",
+	"scif2_data_b",
+};
+
 static const char * const scifa0_groups[] = {
 	"scifa0_data",
 	"scifa0_clk",
@@ -3227,6 +3258,7 @@ static const struct sh_pfc_function pinmux_functions[] = {
 	SH_PFC_FUNCTION(msiof3),
 	SH_PFC_FUNCTION(scif0),
 	SH_PFC_FUNCTION(scif1),
+	SH_PFC_FUNCTION(scif2),
 	SH_PFC_FUNCTION(scifa0),
 	SH_PFC_FUNCTION(scifa1),
 	SH_PFC_FUNCTION(scifa2),
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:19 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:19 +0200
Subject: [PATCH 13/14] sh-pfc: r8a7790: Add USB pin groups and functions
In-Reply-To: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671720-8794-14-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

From: Shinobu Uehara <shinobu.uehara.xc at renesas.com>

Signed-off-by: Shinobu Uehara <shinobu.uehara.xc at renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px at renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 42 ++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index 2fd904f..fa501ef 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -2869,6 +2869,30 @@ static const unsigned int tpu0_to3_pins[] = {
 static const unsigned int tpu0_to3_mux[] = {
 	TPU0TO3_MARK,
 };
+/* - USB0 ------------------------------------------------------------------- */
+static const unsigned int usb0_pins[] = {
+	/* PWEN, OVC/VBUS */
+	RCAR_GP_PIN(5, 18), RCAR_GP_PIN(5, 19),
+};
+static const unsigned int usb0_mux[] = {
+	USB0_PWEN_MARK, USB0_OVC_VBUS_MARK,
+};
+/* - USB1 ------------------------------------------------------------------- */
+static const unsigned int usb1_pins[] = {
+	/* PWEN, OVC */
+	RCAR_GP_PIN(5, 20), RCAR_GP_PIN(5, 21),
+};
+static const unsigned int usb1_mux[] = {
+	USB1_PWEN_MARK, USB1_OVC_MARK,
+};
+/* - USB2 ------------------------------------------------------------------- */
+static const unsigned int usb2_pins[] = {
+	/* PWEN, OVC */
+	RCAR_GP_PIN(5, 22), RCAR_GP_PIN(5, 23),
+};
+static const unsigned int usb2_mux[] = {
+	USB2_PWEN_MARK, USB2_OVC_MARK,
+};
 
 static const struct sh_pfc_pin_group pinmux_groups[] = {
 	SH_PFC_PIN_GROUP(eth_link),
@@ -3021,6 +3045,9 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
 	SH_PFC_PIN_GROUP(tpu0_to1),
 	SH_PFC_PIN_GROUP(tpu0_to2),
 	SH_PFC_PIN_GROUP(tpu0_to3),
+	SH_PFC_PIN_GROUP(usb0),
+	SH_PFC_PIN_GROUP(usb1),
+	SH_PFC_PIN_GROUP(usb2),
 };
 
 static const char * const eth_groups[] = {
@@ -3245,6 +3272,18 @@ static const char * const tpu0_groups[] = {
 	"tpu0_to3",
 };
 
+static const char * const usb0_groups[] = {
+	"usb0",
+};
+
+static const char * const usb1_groups[] = {
+	"usb1",
+};
+
+static const char * const usb2_groups[] = {
+	"usb2",
+};
+
 static const struct sh_pfc_function pinmux_functions[] = {
 	SH_PFC_FUNCTION(eth),
 	SH_PFC_FUNCTION(hscif0),
@@ -3270,6 +3309,9 @@ static const struct sh_pfc_function pinmux_functions[] = {
 	SH_PFC_FUNCTION(sdhi2),
 	SH_PFC_FUNCTION(sdhi3),
 	SH_PFC_FUNCTION(tpu0),
+	SH_PFC_FUNCTION(usb0),
+	SH_PFC_FUNCTION(usb1),
+	SH_PFC_FUNCTION(usb2),
 };
 
 static struct pinmux_cfg_reg pinmux_config_regs[] = {
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Wed Jul 24 09:15:20 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 15:15:20 +0200
Subject: [PATCH 14/14] sh-pfc: r8a7790: Add VIN pin groups and functions
In-Reply-To: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671720-8794-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374671720-8794-15-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

From: Shinobu Uehara <shinobu.uehara.xc at renesas.com>

Signed-off-by: Shinobu Uehara <shinobu.uehara.xc at renesas.com>
Signed-off-by: Ryo Kataoka <ryo.kataoka.wt at renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 106 +++++++++++++++++++++++++++++++++++
 1 file changed, 106 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index fa501ef..846ffcc 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -2893,6 +2893,84 @@ static const unsigned int usb2_pins[] = {
 static const unsigned int usb2_mux[] = {
 	USB2_PWEN_MARK, USB2_OVC_MARK,
 };
+/* - VIN0 ------------------------------------------------------------------- */
+static const unsigned int vin0_data_g_pins[] = {
+	RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 9), RCAR_GP_PIN(0, 10),
+	RCAR_GP_PIN(0, 11), RCAR_GP_PIN(0, 0), RCAR_GP_PIN(0, 1),
+	RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
+};
+static const unsigned int vin0_data_g_mux[] = {
+	VI0_G0_MARK, VI0_G1_MARK, VI0_G2_MARK,
+	VI0_G3_MARK, VI0_G4_MARK, VI0_G5_MARK,
+	VI0_G6_MARK, VI0_G7_MARK,
+};
+static const unsigned int vin0_data_r_pins[] = {
+	RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
+	RCAR_GP_PIN(0, 7), RCAR_GP_PIN(0, 24), RCAR_GP_PIN(0, 25),
+	RCAR_GP_PIN(0, 26), RCAR_GP_PIN(1, 11),
+};
+static const unsigned int vin0_data_r_mux[] = {
+	VI0_R0_MARK, VI0_R1_MARK, VI0_R2_MARK,
+	VI0_R3_MARK, VI0_R4_MARK, VI0_R5_MARK,
+	VI0_R6_MARK, VI0_R7_MARK,
+};
+static const unsigned int vin0_data_b_pins[] = {
+	RCAR_GP_PIN(2, 1), RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3),
+	RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 5), RCAR_GP_PIN(2, 6),
+	RCAR_GP_PIN(2, 7), RCAR_GP_PIN(2, 8),
+};
+static const unsigned int vin0_data_b_mux[] = {
+	VI0_DATA0_VI0_B0_MARK, VI0_DATA1_VI0_B1_MARK, VI0_DATA2_VI0_B2_MARK,
+	VI0_DATA3_VI0_B3_MARK, VI0_DATA4_VI0_B4_MARK, VI0_DATA5_VI0_B5_MARK,
+	VI0_DATA6_VI0_B6_MARK, VI0_DATA7_VI0_B7_MARK,
+};
+static const unsigned int vin0_hsync_signal_pins[] = {
+	RCAR_GP_PIN(0, 12),
+};
+static const unsigned int vin0_hsync_signal_mux[] = {
+	VI0_HSYNC_N_MARK,
+};
+static const unsigned int vin0_vsync_signal_pins[] = {
+	RCAR_GP_PIN(0, 13),
+};
+static const unsigned int vin0_vsync_signal_mux[] = {
+	VI0_VSYNC_N_MARK,
+};
+static const unsigned int vin0_field_signal_pins[] = {
+	RCAR_GP_PIN(0, 15),
+};
+static const unsigned int vin0_field_signal_mux[] = {
+	VI0_FIELD_MARK,
+};
+static const unsigned int vin0_data_enable_pins[] = {
+	RCAR_GP_PIN(0, 14),
+};
+static const unsigned int vin0_data_enable_mux[] = {
+	VI0_CLKENB_MARK,
+};
+static const unsigned int vin0_clk_pins[] = {
+	RCAR_GP_PIN(2, 0),
+};
+static const unsigned int vin0_clk_mux[] = {
+	VI0_CLK_MARK,
+};
+/* - VIN1 ------------------------------------------------------------------- */
+static const unsigned int vin1_data_pins[] = {
+	RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11), RCAR_GP_PIN(2, 12),
+	RCAR_GP_PIN(2, 13), RCAR_GP_PIN(2, 14), RCAR_GP_PIN(2, 15),
+	RCAR_GP_PIN(2, 16), RCAR_GP_PIN(2, 17),
+};
+static const unsigned int vin1_data_mux[] = {
+	VI1_DATA0_VI1_B0_MARK, VI1_DATA1_VI1_B1_MARK, VI1_DATA2_VI1_B2_MARK,
+	VI1_DATA3_VI1_B3_MARK, VI1_DATA4_VI1_B4_MARK, VI1_DATA5_VI1_B5_MARK,
+	VI1_DATA6_VI1_B6_MARK, VI1_DATA7_VI1_B7_MARK,
+};
+static const unsigned int vin1_clk_pins[] = {
+	RCAR_GP_PIN(2, 9),
+};
+static const unsigned int vin1_clk_mux[] = {
+	VI1_CLK_MARK,
+};
 
 static const struct sh_pfc_pin_group pinmux_groups[] = {
 	SH_PFC_PIN_GROUP(eth_link),
@@ -3048,6 +3126,16 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
 	SH_PFC_PIN_GROUP(usb0),
 	SH_PFC_PIN_GROUP(usb1),
 	SH_PFC_PIN_GROUP(usb2),
+	SH_PFC_PIN_GROUP(vin0_data_g),
+	SH_PFC_PIN_GROUP(vin0_data_r),
+	SH_PFC_PIN_GROUP(vin0_data_b),
+	SH_PFC_PIN_GROUP(vin0_hsync_signal),
+	SH_PFC_PIN_GROUP(vin0_vsync_signal),
+	SH_PFC_PIN_GROUP(vin0_field_signal),
+	SH_PFC_PIN_GROUP(vin0_data_enable),
+	SH_PFC_PIN_GROUP(vin0_clk),
+	SH_PFC_PIN_GROUP(vin1_data),
+	SH_PFC_PIN_GROUP(vin1_clk),
 };
 
 static const char * const eth_groups[] = {
@@ -3284,6 +3372,22 @@ static const char * const usb2_groups[] = {
 	"usb2",
 };
 
+static const char * const vin0_groups[] = {
+	"vin0_data_g",
+	"vin0_data_r",
+	"vin0_data_b",
+	"vin0_hsync_signal",
+	"vin0_vsync_signal",
+	"vin0_field_signal",
+	"vin0_data_enable",
+	"vin0_clk",
+};
+
+static const char * const vin1_groups[] = {
+	"vin1_data",
+	"vin1_clk",
+};
+
 static const struct sh_pfc_function pinmux_functions[] = {
 	SH_PFC_FUNCTION(eth),
 	SH_PFC_FUNCTION(hscif0),
@@ -3312,6 +3416,8 @@ static const struct sh_pfc_function pinmux_functions[] = {
 	SH_PFC_FUNCTION(usb0),
 	SH_PFC_FUNCTION(usb1),
 	SH_PFC_FUNCTION(usb2),
+	SH_PFC_FUNCTION(vin0),
+	SH_PFC_FUNCTION(vin1),
 };
 
 static struct pinmux_cfg_reg pinmux_config_regs[] = {
-- 
1.8.1.5



From s.nawrocki at samsung.com  Wed Jul 24 09:17:12 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:17:12 +0200
Subject: [PATCH v4 00/13] ARM: dts: Add camera and magnetometer support for
 TRATS(2) board
Message-ID: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>

This patch series includes some fixes and extensions to the Exynos dts
files to add the camera and magnetometer sensor support for the TRATS
and TRATS2 board. It depends on a patch from Tomasz adding initial
TRATS2 board dts file [1].

Changes since v3 include:
 - removed patch adding MIPI PHY node (although it is unlikely the DT
   binding will change the PHY driver is still in review phase),
 - added one more patch for SPI and s5c73m3 camera.

Detailed changes are listed in each patch.

This series has been tested with the S5K6A3/FIMC-IS, S5C73M3 and
S5K5BAFX cameras on top of v3.11-rc2.

I have a couple more similar patches that actually enable remaining
devices I intend to submit for v3.12, once corresponding driver
patches are reviewed and queued.

[1] http://www.spinics.net/lists/arm-kernel/msg253184.html

Andrzej Hajda (3):
  ARM: dts: Add SPI1 controller and s5c73m3 sensor node for TRATS2
  ARM: dts: Add Exynos4210 SoC camera port pinctrl nodes
  ARM: dts: Add S5K5BA sensor regulator definitions for Trats board

Jacek Anaszewski (1):
  ARM: dts: Add AK8975 device node for Exynos4412 TRATS2 board

Sylwester Nawrocki (9):
  ARM: dts: Correct camera pinctrl nodes for Exynos4x12 SoCs
  ARM: dts: Add pinctrl entries for Exynos4x12 FIMC-IS peripherals
  ARM: dts: Add ISP power domain node for Exynos4x12
  ARM: dts: Use generic DMA bindings for Exynos4 SPI devices
  ARM: dts: Add camera subsystem device nodes to exynos4.dtsi
  ARM: dts: Add camera subsystem nodes to exynos4x12.dtsi
  ARM: dts: Add camera device nodes for Exynos4412 TRATS2 board
  ARM: dts: Add camera device nodes for Exynos4210 SoCs
  ARM: dts: Add FIMC nodes for Exynos4210 Trats board

 arch/arm/boot/dts/exynos4.dtsi            |  100 +++++++++++++++++++++--
 arch/arm/boot/dts/exynos4210-pinctrl.dtsi |   23 ++++++
 arch/arm/boot/dts/exynos4210-trats.dts    |  100 +++++++++++++++++++----
 arch/arm/boot/dts/exynos4210.dtsi         |   30 +++++++
 arch/arm/boot/dts/exynos4412-trats2.dts   |  123 +++++++++++++++++++++++++++++
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |   61 ++++++++++++--
 arch/arm/boot/dts/exynos4x12.dtsi         |  103 ++++++++++++++++++++++++
 7 files changed, 511 insertions(+), 29 deletions(-)

--
1.7.9.5



From s.nawrocki at samsung.com  Wed Jul 24 09:17:13 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:17:13 +0200
Subject: [PATCH v4 01/13] ARM: dts: Correct camera pinctrl nodes for Exynos4x12
 SoCs
In-Reply-To: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
References: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1374671845-30373-2-git-send-email-s.nawrocki@samsung.com>

Add separate nodes for the CAMCLK pin and turn off pull-up on camera
ports A, B. The video bus pins and the clock output (CAMCLK) pin need
separate nodes since full camera port is not used in some configurations,
e.g. for MIPI CSI-2 bus only CAMCLK is required and data/clock signal
use separate dedicated pins.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |   40 ++++++++++++++++++++++++-----
 1 file changed, 33 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index 704290f..55ff73b 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -401,13 +401,26 @@
 			samsung,pin-drv = <0>;
 		};
 
-		cam_port_a: cam-port-a {
+		cam_port_a_io: cam-port-a-io {
 			samsung,pins = "gpj0-0", "gpj0-1", "gpj0-2", "gpj0-3",
 					"gpj0-4", "gpj0-5", "gpj0-6", "gpj0-7",
-					"gpj1-0", "gpj1-1", "gpj1-2", "gpj1-3",
-					"gpj1-4";
+					"gpj1-0", "gpj1-1", "gpj1-2", "gpj1-4";
 			samsung,pin-function = <2>;
-			samsung,pin-pud = <3>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <0>;
+		};
+
+		cam_port_a_clk_active: cam-port-a-clk-active {
+			samsung,pins = "gpj1-3";
+			samsung,pin-function = <2>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <3>;
+		};
+
+		cam_port_a_clk_idle: cam-port-a-clk-idle {
+			samsung,pins = "gpj1-3";
+			samsung,pin-function = <0>;
+			samsung,pin-pud = <1>;
 			samsung,pin-drv = <0>;
 		};
 	};
@@ -778,16 +791,29 @@
 			samsung,pin-drv = <3>;
 		};
 
-		cam_port_b: cam-port-b {
+		cam_port_b_io: cam-port-b-io {
 			samsung,pins = "gpm0-0", "gpm0-1", "gpm0-2", "gpm0-3",
 					"gpm0-4", "gpm0-5", "gpm0-6", "gpm0-7",
-					"gpm1-0", "gpm1-1", "gpm2-0", "gpm2-1",
-					"gpm2-2";
+					"gpm1-0", "gpm1-1", "gpm2-0", "gpm2-1";
 			samsung,pin-function = <3>;
 			samsung,pin-pud = <3>;
 			samsung,pin-drv = <0>;
 		};
 
+		cam_port_b_clk_active: cam-port-b-clk-active {
+			samsung,pins = "gpm2-2";
+			samsung,pin-function = <3>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <3>;
+		};
+
+		cam_port_b_clk_idle: cam-port-b-clk-idle {
+			samsung,pins = "gpm2-2";
+			samsung,pin-function = <0>;
+			samsung,pin-pud = <1>;
+			samsung,pin-drv = <0>;
+		};
+
 		eint0: ext-int0 {
 			samsung,pins = "gpx0-0";
 			samsung,pin-function = <0xf>;
-- 
1.7.9.5



From s.nawrocki at samsung.com  Wed Jul 24 09:17:14 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:17:14 +0200
Subject: [PATCH v4 02/13] ARM: dts: Add pinctrl entries for Exynos4x12 FIMC-IS
 peripherals
In-Reply-To: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
References: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1374671845-30373-3-git-send-email-s.nawrocki@samsung.com>

Add pinctrl nodes for the ISP I2C0, ISP I2C1 and ISP UART devices.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index 55ff73b..99b26df 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -848,6 +848,27 @@
 			samsung,pin-pud = <0>;
 			samsung,pin-drv = <0>;
 		};
+
+		fimc_is_i2c0: fimc-is-i2c0 {
+			samsung,pins = "gpm4-0", "gpm4-1";
+			samsung,pin-function = <2>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <0>;
+		};
+
+		fimc_is_i2c1: fimc-is-i2c1 {
+			samsung,pins = "gpm4-2", "gpm4-3";
+			samsung,pin-function = <2>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <0>;
+		};
+
+		fimc_is_uart: fimc-is-uart {
+			samsung,pins = "gpm3-5", "gpm3-7";
+			samsung,pin-function = <3>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <0>;
+		};
 	};
 
 	pinctrl at 03860000 {
-- 
1.7.9.5



From s.nawrocki at samsung.com  Wed Jul 24 09:17:16 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:17:16 +0200
Subject: [PATCH v4 04/13] ARM: dts: Use generic DMA bindings for Exynos4 SPI
 devices
In-Reply-To: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
References: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1374671845-30373-5-git-send-email-s.nawrocki@samsung.com>

The Exynos4 SPI controller has migrated to the generic DMA bindings
since commit b5be04d35dbb2e00
"spi: s3c64xx: Modify SPI driver to use generic DMA DT support".
Use the generic bindings to specify the corresponding DMA to make
the SPI usable again on Exynos4x12 SoCs.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---
 arch/arm/boot/dts/exynos4.dtsi |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 3f94fe8..bce2254 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -297,8 +297,8 @@
 		compatible = "samsung,exynos4210-spi";
 		reg = <0x13920000 0x100>;
 		interrupts = <0 66 0>;
-		tx-dma-channel = <&pdma0 7>; /* preliminary */
-		rx-dma-channel = <&pdma0 6>; /* preliminary */
+		dmas = <&pdma0 7>, <&pdma0 6>;
+		dma-names = "tx", "rx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&clock 327>, <&clock 159>;
@@ -312,8 +312,8 @@
 		compatible = "samsung,exynos4210-spi";
 		reg = <0x13930000 0x100>;
 		interrupts = <0 67 0>;
-		tx-dma-channel = <&pdma1 7>; /* preliminary */
-		rx-dma-channel = <&pdma1 6>; /* preliminary */
+		dmas = <&pdma1 7>, <&pdma1 6>;
+		dma-names = "tx", "rx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&clock 328>, <&clock 160>;
@@ -327,8 +327,8 @@
 		compatible = "samsung,exynos4210-spi";
 		reg = <0x13940000 0x100>;
 		interrupts = <0 68 0>;
-		tx-dma-channel = <&pdma0 9>; /* preliminary */
-		rx-dma-channel = <&pdma0 8>; /* preliminary */
+		dmas = <&pdma0 9>, <&pdma0 8>;
+		dma-names = "tx", "rx";
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&clock 329>, <&clock 161>;
-- 
1.7.9.5



From s.nawrocki at samsung.com  Wed Jul 24 09:17:17 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:17:17 +0200
Subject: [PATCH v4 05/13] ARM: dts: Add camera subsystem device nodes to
 exynos4.dtsi
In-Reply-To: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
References: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1374671845-30373-6-git-send-email-s.nawrocki@samsung.com>

This patch adds common Exynos4 SoC series FIMC and MIPI CSIS
device nodes.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---

Changes since v3:
 - added #address-cells/#size-cells properties to csis nodes,
 - added clock provider node to the camera node.
---
 arch/arm/boot/dts/exynos4.dtsi |   88 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index bce2254..597cfcf 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -36,6 +36,12 @@
 		i2c5 = &i2c_5;
 		i2c6 = &i2c_6;
 		i2c7 = &i2c_7;
+		csis0 = &csis_0;
+		csis1 = &csis_1;
+		fimc0 = &fimc_0;
+		fimc1 = &fimc_1;
+		fimc2 = &fimc_2;
+		fimc3 = &fimc_3;
 	};
 
 	chipid at 10000000 {
@@ -92,6 +98,88 @@
 		reg = <0x10010000 0x400>;
 	};
 
+	camera {
+		compatible = "samsung,fimc", "simple-bus";
+		status = "disabled";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		clock_cam: clock-controller {
+			 #clock-cells = <1>;
+		};
+
+		fimc_0: fimc at 11800000 {
+			compatible = "samsung,exynos4210-fimc";
+			reg = <0x11800000 0x1000>;
+			interrupts = <0 84 0>;
+			clocks = <&clock 256>, <&clock 128>;
+			clock-names = "fimc", "sclk_fimc";
+			samsung,power-domain = <&pd_cam>;
+			samsung,sysreg = <&sys_reg>;
+			status = "disabled";
+		};
+
+		fimc_1: fimc at 11810000 {
+			compatible = "samsung,exynos4210-fimc";
+			reg = <0x11810000 0x1000>;
+			interrupts = <0 85 0>;
+			clocks = <&clock 257>, <&clock 129>;
+			clock-names = "fimc", "sclk_fimc";
+			samsung,power-domain = <&pd_cam>;
+			samsung,sysreg = <&sys_reg>;
+			status = "disabled";
+		};
+
+		fimc_2: fimc at 11820000 {
+			compatible = "samsung,exynos4210-fimc";
+			reg = <0x11820000 0x1000>;
+			interrupts = <0 86 0>;
+			clocks = <&clock 258>, <&clock 130>;
+			clock-names = "fimc", "sclk_fimc";
+			samsung,power-domain = <&pd_cam>;
+			samsung,sysreg = <&sys_reg>;
+			status = "disabled";
+		};
+
+		fimc_3: fimc at 11830000 {
+			compatible = "samsung,exynos4210-fimc";
+			reg = <0x11830000 0x1000>;
+			interrupts = <0 87 0>;
+			clocks = <&clock 259>, <&clock 131>;
+			clock-names = "fimc", "sclk_fimc";
+			samsung,power-domain = <&pd_cam>;
+			samsung,sysreg = <&sys_reg>;
+			status = "disabled";
+		};
+
+		csis_0: csis at 11880000 {
+			compatible = "samsung,exynos4210-csis";
+			reg = <0x11880000 0x4000>;
+			interrupts = <0 78 0>;
+			clocks = <&clock 260>, <&clock 134>;
+			clock-names = "csis", "sclk_csis";
+			bus-width = <4>;
+			samsung,power-domain = <&pd_cam>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		csis_1: csis at 11890000 {
+			compatible = "samsung,exynos4210-csis";
+			reg = <0x11890000 0x4000>;
+			interrupts = <0 80 0>;
+			clocks = <&clock 261>, <&clock 135>;
+			clock-names = "csis", "sclk_csis";
+			bus-width = <2>;
+			samsung,power-domain = <&pd_cam>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
 	watchdog at 10060000 {
 		compatible = "samsung,s3c2410-wdt";
 		reg = <0x10060000 0x100>;
-- 
1.7.9.5



From s.nawrocki at samsung.com  Wed Jul 24 09:17:18 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:17:18 +0200
Subject: [PATCH v4 06/13] ARM: dts: Add camera subsystem nodes to
 exynos4x12.dtsi
In-Reply-To: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
References: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1374671845-30373-7-git-send-email-s.nawrocki@samsung.com>

Add common camera node and Exynos4212/4412 specific nodes for
FIMC, MIPI-CSIS, FIMC-LITE and FIMC-IS devices.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---
Changes since v3:
 - fixed typo in exynos4x12 i2c_isp node reg property,
 - removed the clock properties which are now moved to exynos4.dtsi,
   "mux" and "parent" clock entries are dropped.
---
 arch/arm/boot/dts/exynos4x12.dtsi |   98 +++++++++++++++++++++++++++++++++++++
 1 file changed, 98 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index 0e24d85..954628c 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -26,6 +26,8 @@
 		pinctrl1 = &pinctrl_1;
 		pinctrl2 = &pinctrl_2;
 		pinctrl3 = &pinctrl_3;
+		fimc-lite0 = &fimc_lite_0;
+		fimc-lite1 = &fimc_lite_1;
 	};
 
 	pd_isp: isp-power-domain at 10023CA0 {
@@ -78,4 +80,100 @@
 		clock-names = "sclk_fimg2d", "fimg2d";
 		status = "disabled";
 	};
+
+	camera {
+		clocks = <&clock 132>, <&clock 133>, <&clock 351>, <&clock 352>;
+		clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0", "pxl_async1";
+
+		fimc_0: fimc at 11800000 {
+			compatible = "samsung,exynos4212-fimc";
+			samsung,pix-limits = <4224 8192 1920 4224>;
+			samsung,mainscaler-ext;
+			samsung,isp-wb;
+			samsung,cam-if;
+		};
+
+		fimc_1: fimc at 11810000 {
+			compatible = "samsung,exynos4212-fimc";
+			samsung,pix-limits = <4224 8192 1920 4224>;
+			samsung,mainscaler-ext;
+			samsung,isp-wb;
+			samsung,cam-if;
+		};
+
+		fimc_2: fimc at 11820000 {
+			compatible = "samsung,exynos4212-fimc";
+			samsung,pix-limits = <4224 8192 1920 4224>;
+			samsung,mainscaler-ext;
+			samsung,isp-wb;
+			samsung,lcd-wb;
+			samsung,cam-if;
+		};
+
+		fimc_3: fimc at 11830000 {
+			compatible = "samsung,exynos4212-fimc";
+			samsung,pix-limits = <1920 8192 1366 1920>;
+			samsung,rotators = <0>;
+			samsung,mainscaler-ext;
+			samsung,isp-wb;
+			samsung,lcd-wb;
+		};
+
+		fimc_lite_0: fimc-lite at 12390000 {
+			compatible = "samsung,exynos4212-fimc-lite";
+			reg = <0x12390000 0x1000>;
+			interrupts = <0 105 0>;
+			samsung,power-domain = <&pd_isp>;
+			clocks = <&clock 353>;
+			clock-names = "flite";
+			status = "disabled";
+		};
+
+		fimc_lite_1: fimc-lite at 123A0000 {
+			compatible = "samsung,exynos4212-fimc-lite";
+			reg = <0x123A0000 0x1000>;
+			interrupts = <0 106 0>;
+			samsung,power-domain = <&pd_isp>;
+			clocks = <&clock 354>;
+			clock-names = "flite";
+			status = "disabled";
+		};
+
+		fimc_is: fimc-is at 12000000 {
+			compatible = "samsung,exynos4212-fimc-is", "simple-bus";
+			reg = <0x12000000 0x260000>;
+			interrupts = <0 90 0>, <0 95 0>;
+			samsung,power-domain = <&pd_isp>;
+			clocks = <&clock 353>, <&clock 354>, <&clock 355>,
+				<&clock 356>, <&clock 17>, <&clock 357>,
+				<&clock 358>, <&clock 359>, <&clock 360>,
+				<&clock 450>,<&clock 451>, <&clock 452>,
+				<&clock 453>, <&clock 176>, <&clock 13>,
+				<&clock 454>, <&clock 395>, <&clock 455>;
+			clock-names = "lite0", "lite1", "ppmuispx",
+				      "ppmuispmx", "mpll", "isp",
+				      "drc", "fd", "mcuisp",
+				      "ispdiv0", "ispdiv1", "mcuispdiv0",
+				      "mcuispdiv1", "uart", "aclk200",
+				      "div_aclk200", "aclk400mcuisp",
+				      "div_aclk400mcuisp";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+			status = "disabled";
+
+			pmu {
+				reg = <0x10020000 0x3000>;
+			};
+
+			i2c1_isp: i2c-isp at 12140000 {
+				compatible = "samsung,exynos4212-i2c-isp";
+				reg = <0x12140000 0x100>;
+				clocks = <&clock 370>;
+				clock-names = "i2c_isp";
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
+		};
+	};
 };
-- 
1.7.9.5



From s.nawrocki at samsung.com  Wed Jul 24 09:17:19 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:17:19 +0200
Subject: [PATCH v4 07/13] ARM: dts: Add AK8975 device node for Exynos4412
 TRATS2 board
In-Reply-To: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
References: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1374671845-30373-8-git-send-email-s.nawrocki@samsung.com>

From: Jacek Anaszewski <j.anaszewski at samsung.com>

This patch adds AK8975 magnetometer node and corresponding
i2c-gpio bus node for TRATS2 board.

Signed-off-by: Jacek Anaszewski <j.anaszewski at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---
Changes since v3:
 - s/i2c-gpio at 0/i2c-gpio-0, changed compatible string to "ak,ak8975".
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
index 056b835..cab4c0e 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -19,6 +19,10 @@
 	model = "Samsung Trats 2 based on Exynos4412";
 	compatible = "samsung,trats2", "samsung,exynos4412";
 
+	aliases {
+		i2c8 = &i2c_ak8975;
+	};
+
 	memory {
 		reg =  <0x40000000 0x40000000>;
 	};
@@ -453,4 +457,19 @@
 	serial at 13830000 {
 		status = "okay";
 	};
+
+	i2c_ak8975: i2c-gpio-0 {
+		compatible = "i2c-gpio";
+		gpios = <&gpy2 4 0>, <&gpy2 5 0>;
+		i2c-gpio,delay-us = <2>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "okay";
+
+		ak8975 at 0c {
+			compatible = "ak,ak8975";
+			reg = <0x0c>;
+			gpios = <&gpj0 7 0>;
+		};
+	};
 };
-- 
1.7.9.5



From s.nawrocki at samsung.com  Wed Jul 24 09:17:20 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:17:20 +0200
Subject: [PATCH v4 08/13] ARM: dts: Add camera device nodes for Exynos4412
 TRATS2 board
In-Reply-To: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
References: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1374671845-30373-9-git-send-email-s.nawrocki@samsung.com>

This patch enables the front camera using the internal
camera ISP (FIMC-IS).

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---

Changes since v3:
 - #address-cells/#size-cells properties in csis nodes
    moved to exynos4.dtsi,
 - added clock properties to s5k6a3 sensor node,
 - s/voltage-regulator at 3/voltage-regulator-1.
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   88 +++++++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
index cab4c0e..5558e5a 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -62,6 +62,15 @@
 			enable-active-high;
 		};
 
+		cam_io_reg: voltage-regulator-1 {
+			compatible = "regulator-fixed";
+			regulator-name = "CAM_SENSOR_A";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			gpio = <&gpm0 2 0>;
+			enable-active-high;
+		};
+
 		/* More to come */
 	};
 
@@ -472,4 +481,83 @@
 			gpios = <&gpj0 7 0>;
 		};
 	};
+
+	camera {
+		pinctrl-0 = <&cam_port_b_clk_active>;
+		pinctrl-names = "default";
+		status = "okay";
+
+		fimc_0: fimc at 11800000 {
+			status = "okay";
+		};
+
+		fimc_1: fimc at 11810000 {
+			status = "okay";
+		};
+
+		fimc_2: fimc at 11820000 {
+			status = "okay";
+		};
+
+		fimc_3: fimc at 11830000 {
+			status = "okay";
+		};
+
+		csis_1: csis at 11890000 {
+			vddcore-supply = <&ldo8_reg>;
+			vddio-supply = <&ldo10_reg>;
+			clock-frequency = <160000000>;
+			status = "okay";
+
+			/* Camera D (4) MIPI CSI-2 (CSIS1) */
+			port at 4 {
+				reg = <4>;
+				csis1_ep: endpoint {
+					remote-endpoint = <&is_s5k6a3_ep>;
+					data-lanes = <1>;
+					samsung,csis-hs-settle = <18>;
+					samsung,csis-wclk;
+				};
+			};
+		};
+
+		fimc_lite_0: fimc-lite at 12390000 {
+			status = "okay";
+		};
+
+		fimc_lite_1: fimc-lite at 123A0000 {
+			status = "okay";
+		};
+
+		fimc-is at 12000000 {
+			pinctrl-0 = <&fimc_is_uart>;
+			pinctrl-names = "default";
+			status = "okay";
+
+			i2c1_isp: i2c-isp at 12140000 {
+				pinctrl-0 = <&fimc_is_i2c1>;
+				pinctrl-names = "default";
+
+				s5k6a3 at 10 {
+					compatible = "samsung,s5k6a3";
+					reg = <0x10>;
+					svdda-supply = <&cam_io_reg>;
+					svddio-supply = <&ldo19_reg>;
+					clock-frequency = <24000000>;
+					/* CAM_B_CLKOUT */
+					clocks = <&clock_cam 1>;
+					clock-names = "mclk";
+					samsung,camclk-out = <1>;
+					gpios = <&gpm1 6 0>;
+
+					port {
+						is_s5k6a3_ep: endpoint {
+							remote-endpoint = <&csis1_ep>;
+							data-lanes = <1>;
+						};
+					};
+				};
+			};
+		};
+	};
 };
-- 
1.7.9.5



From s.nawrocki at samsung.com  Wed Jul 24 09:17:15 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:17:15 +0200
Subject: [PATCH v4 03/13] ARM: dts: Add ISP power domain node for Exynos4x12
In-Reply-To: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
References: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1374671845-30373-4-git-send-email-s.nawrocki@samsung.com>

The ISP power domain is a common power domain for FIMC-LITE
and FIMC-IS (camera ISP) devices.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---
 arch/arm/boot/dts/exynos4x12.dtsi |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index 01da194..0e24d85 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -28,6 +28,11 @@
 		pinctrl3 = &pinctrl_3;
 	};
 
+	pd_isp: isp-power-domain at 10023CA0 {
+		compatible = "samsung,exynos4210-pd";
+		reg = <0x10023CA0 0x20>;
+	};
+
 	clock: clock-controller at 0x10030000 {
 		compatible = "samsung,exynos4412-clock";
 		reg = <0x10030000 0x20000>;
-- 
1.7.9.5



From s.nawrocki at samsung.com  Wed Jul 24 09:17:21 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:17:21 +0200
Subject: [PATCH v4 09/13] ARM: dts: Add SPI1 controller and s5c73m3 sensor node
 for TRATS2
In-Reply-To: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
References: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1374671845-30373-10-git-send-email-s.nawrocki@samsung.com>

From: Andrzej Hajda <a.hajda at samsung.com>

This patch add dts entries required for the SPI bus used for
firware upload by the S5C73M3 camera.

Signed-off-by: Andrzej Hajda <a.hajda at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
index 5558e5a..fb7b9ae 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -482,6 +482,22 @@
 		};
 	};
 
+	spi_1: spi at 13930000 {
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi1_bus>;
+		status = "okay";
+
+		s5c73m3_spi: s5c73m3 {
+			compatible = "samsung,s5c73m3";
+			spi-max-frequency = <50000000>;
+			reg = <0>;
+			controller-data {
+				cs-gpio = <&gpb 5 0>;
+				samsung,spi-feedback-delay = <2>;
+			};
+		};
+	};
+
 	camera {
 		pinctrl-0 = <&cam_port_b_clk_active>;
 		pinctrl-names = "default";
-- 
1.7.9.5



From s.nawrocki at samsung.com  Wed Jul 24 09:17:22 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:17:22 +0200
Subject: [PATCH v4 10/13] ARM: dts: Add camera device nodes for Exynos4210 SoCs
In-Reply-To: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
References: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1374671845-30373-11-git-send-email-s.nawrocki@samsung.com>

Add common camera node and detailed properties for
the Exynos4210 FIMC devices.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---
 arch/arm/boot/dts/exynos4210.dtsi |   30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index b7f358a..ef8c2a5 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -125,4 +125,34 @@
 		clock-names = "sclk_fimg2d", "fimg2d";
 		status = "disabled";
 	};
+
+	camera {
+		clocks = <&clock 132>, <&clock 133>, <&clock 351>, <&clock 352>;
+		clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0", "pxl_async1";
+
+		fimc_0: fimc at 11800000 {
+			samsung,pix-limits = <4224 8192 1920 4224>;
+			samsung,mainscaler-ext;
+			samsung,cam-if;
+		};
+
+		fimc_1: fimc at 11810000 {
+			samsung,pix-limits = <4224 8192 1920 4224>;
+			samsung,mainscaler-ext;
+			samsung,cam-if;
+		};
+
+		fimc_2: fimc at 11820000 {
+			samsung,pix-limits = <4224 8192 1920 4224>;
+			samsung,mainscaler-ext;
+			samsung,lcd-wb;
+		};
+
+		fimc_3: fimc at 11830000 {
+			samsung,pix-limits = <1920 8192 1366 1920>;
+			samsung,rotators = <0>;
+			samsung,mainscaler-ext;
+			samsung,lcd-wb;
+		};
+	};
 };
-- 
1.7.9.5



From s.nawrocki at samsung.com  Wed Jul 24 09:17:23 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:17:23 +0200
Subject: [PATCH v4 11/13] ARM: dts: Add FIMC nodes for Exynos4210 Trats board
In-Reply-To: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
References: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1374671845-30373-12-git-send-email-s.nawrocki@samsung.com>

Enable FIMC devices on the Trats board. This allows using the
device in memory-to-memory mode only. The camera port pinctrl
property is now empty and will be updated while support for the
camera sensors is added.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---
 arch/arm/boot/dts/exynos4210-trats.dts |   22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts
index 94eebff..199ff1e 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -301,4 +301,26 @@
 			clock-frequency = <24000000>;
 		};
 	};
+
+	camera {
+		pinctrl-names = "default";
+		pinctrl-0 = <>;
+		status = "okay";
+
+		fimc_0: fimc at 11800000 {
+			status = "okay";
+		};
+
+		fimc_1: fimc at 11810000 {
+			status = "okay";
+		};
+
+		fimc_2: fimc at 11820000 {
+			status = "okay";
+		};
+
+		fimc_3: fimc at 11830000 {
+			status = "okay";
+		};
+	};
 };
-- 
1.7.9.5



From s.nawrocki at samsung.com  Wed Jul 24 09:17:24 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:17:24 +0200
Subject: [PATCH v4 12/13] ARM: dts: Add Exynos4210 SoC camera port pinctrl
 nodes
In-Reply-To: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
References: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1374671845-30373-13-git-send-email-s.nawrocki@samsung.com>

From: Andrzej Hajda <a.hajda at samsung.com>

Add pinctrl nodes for the camera parallel port CAM_A data bus
and the CAM_A_CLKOUT clock output pin.

Signed-off-by: Andrzej Hajda <a.hajda at samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---
 arch/arm/boot/dts/exynos4210-pinctrl.dtsi |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
index 553bcea..a7c2128 100644
--- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
@@ -797,6 +797,29 @@
 			samsung,pin-pud = <0>;
 			samsung,pin-drv = <0>;
 		};
+
+		cam_port_a_io: cam-port-a-io {
+			samsung,pins = "gpj0-0", "gpj0-1", "gpj0-2", "gpj0-3",
+					"gpj0-4", "gpj0-5", "gpj0-6", "gpj0-7",
+					"gpj1-0", "gpj1-1", "gpj1-2", "gpj1-4";
+			samsung,pin-function = <2>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <0>;
+		};
+
+		cam_port_a_clk_active: cam-port-a-clk-active {
+			samsung,pins = "gpj1-3";
+			samsung,pin-function = <2>;
+			samsung,pin-pud = <0>;
+			samsung,pin-drv = <3>;
+		};
+
+		cam_port_a_clk_idle: cam-port-a-clk-idle {
+			samsung,pins = "gpj1-3";
+			samsung,pin-function = <0>;
+			samsung,pin-pud = <1>;
+			samsung,pin-drv = <0>;
+		};
 	};
 
 	pinctrl at 03860000 {
-- 
1.7.9.5



From s.nawrocki at samsung.com  Wed Jul 24 09:17:25 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:17:25 +0200
Subject: [PATCH v4 13/13] ARM: dts: Add S5K5BA sensor regulator definitions for
 Trats board
In-Reply-To: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
References: <1374671845-30373-1-git-send-email-s.nawrocki@samsung.com>
Message-ID: <1374671845-30373-14-git-send-email-s.nawrocki@samsung.com>

From: Andrzej Hajda <a.hajda at samsung.com>

Add MAX8998 LDO12 and fixed voltage regulator nodes. While at it,
all fixed voltage regulator nodes are grouped in a 'regulators' node.

Signed-off-by: Andrzej Hajda <a.hajda at samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
Reviewed-by: Tomasz Figa <t.figa at samsung.com>
---
Changes since v3:
 - removed #address-cells/#size-cells properties from 'regulators'
   node and the individual regulator node naming changed to regulator-<N>
---
 arch/arm/boot/dts/exynos4210-trats.dts |   78 +++++++++++++++++++++++++-------
 1 file changed, 62 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts
index 199ff1e..1c164f2 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -30,13 +30,62 @@
 		bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rootwait earlyprintk panic=5";
 	};
 
-	vemmc_reg: voltage-regulator at 0 {
-	        compatible = "regulator-fixed";
-		regulator-name = "VMEM_VDD_2.8V";
-		regulator-min-microvolt = <2800000>;
-		regulator-max-microvolt = <2800000>;
-		gpio = <&gpk0 2 0>;
-		enable-active-high;
+	regulators {
+		compatible = "simple-bus";
+
+		vemmc_reg: regulator-0 {
+			compatible = "regulator-fixed";
+			regulator-name = "VMEM_VDD_2.8V";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			gpio = <&gpk0 2 0>;
+			enable-active-high;
+		};
+
+		tsp_reg: regulator-1 {
+			compatible = "regulator-fixed";
+			regulator-name = "TSP_FIXED_VOLTAGES";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			gpio = <&gpl0 3 0>;
+			enable-active-high;
+		};
+
+		cam_af_28v_reg: regulator-2 {
+			compatible = "regulator-fixed";
+			regulator-name = "8M_AF_2.8V_EN";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			gpio = <&gpk1 1 0>;
+			enable-active-high;
+		};
+
+		cam_io_en_reg: regulator-3 {
+			compatible = "regulator-fixed";
+			regulator-name = "CAM_IO_EN";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			gpio = <&gpe2 1 0>;
+			enable-active-high;
+		};
+
+		cam_io_12v_reg: regulator-4 {
+			compatible = "regulator-fixed";
+			regulator-name = "8M_1.2V_EN";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			gpio = <&gpe2 5 0>;
+			enable-active-high;
+		};
+
+		vt_core_15v_reg: regulator-5 {
+			compatible = "regulator-fixed";
+			regulator-name = "VT_CORE_1.5V";
+			regulator-min-microvolt = <1500000>;
+			regulator-max-microvolt = <1500000>;
+			gpio = <&gpe2 2 0>;
+			enable-active-high;
+		};
 	};
 
 	sdhci_emmc: sdhci at 12510000 {
@@ -97,15 +146,6 @@
 		};
 	};
 
-	tsp_reg: voltage-regulator {
-		compatible = "regulator-fixed";
-		regulator-name = "TSP_FIXED_VOLTAGES";
-		regulator-min-microvolt = <2800000>;
-		regulator-max-microvolt = <2800000>;
-		gpio = <&gpl0 3 0>;
-		enable-active-high;
-	};
-
 	i2c at 13890000 {
 		samsung,i2c-sda-delay = <100>;
 		samsung,i2c-slave-addr = <0x10>;
@@ -218,6 +258,12 @@
 				     regulator-always-on;
 				};
 
+				vtcam_reg: LDO12 {
+				     regulator-name = "VT_CAM_1.8V";
+				     regulator-min-microvolt = <1800000>;
+				     regulator-max-microvolt = <1800000>;
+				};
+
 				vcclcd_reg: LDO13 {
 				     regulator-name = "VCC_3.3V_LCD";
 				     regulator-min-microvolt = <3300000>;
-- 
1.7.9.5



From s.nawrocki at samsung.com  Wed Jul 24 09:29:09 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 24 Jul 2013 15:29:09 +0200
Subject: [PATCH v3 00/13] ARM: dts: Add camera and magnetometer support for
 TRATS(2) board
In-Reply-To: <0ee701ce886d$b7bc5930$27350b90$%kim@samsung.com>
References: <1372692155-17653-1-git-send-email-s.nawrocki@samsung.com>
 <0ee701ce886d$b7bc5930$27350b90$%kim@samsung.com>
Message-ID: <51EFD6A5.9020006@samsung.com>

On 07/24/2013 03:00 PM, Kukjin Kim wrote:
> Sylwester Nawrocki wrote:
>>
>> This patch series includes some fixes and extensions to the Exynos dts
>> files to add the camera and magnetometer sensor support for the TRATS
>> and TRATS2 board. It depends on a patch from Tomasz adding initial
>> TRATS2 board dts file [1].
>>
> Already it is in my tree :)

Great, I guess some time is needed until it shows up in the public
git tree.

>> Comparing to the previous version of this patch set I've added a few
>> more patches, for the Exynos4210 based TRATS board and a patch adding
>> MIPI CSIS/DSIM PHY provider nodes and related properties to the PHY
>> consumer nodes.
>>
>> This series has been tested with the S5K6A3/FIMC-IS and S5K5BAFX
>> (front facing) cameras on top of next-20130627 tag. It can be found
>> also at:
>> http://git.linuxtv.org/snawrocki/samsung.git/next-20130627-dts-trats-v3
>>
>> Detailed changes since v2 are listed in each patch.
>>
>> Changes since v1:
>>  - enabled pull down in cam-port-{a, b}-clk-idle nodes (1/8)
>>  - added node alias for i2c-gpio at 0 I2C controller node (7/8).
>>
>> [1] http://www.spinics.net/lists/arm-kernel/msg253184.html
>>
>> Andrzej Hajda (2):
>>   ARM: dts: Add Exynos4210 SoC camera port pinctrl nodes
>>   ARM: dts: Add S5K5BA sensor regulator definitions for Trats board
>>
>> Jacek Anaszewski (1):
>>   ARM: dts: Add AK8975 device node for Exynos4412 TRATS2 board
>>
>> Sylwester Nawrocki (10):
>>   ARM: dts: Correct camera pinctrl nodes for Exynos4x12 SoCs
>>   ARM: dts: Add pinctrl entries for Exynos4x12 FIMC-IS peripherals
>>   ARM: dts: Add ISP power domain node for Exynos4x12
>>   ARM: dts: Use generic DMA bindings for Exynos4 SPI devices
>>   ARM: dts: Add camera subsystem device nodes to exynos4.dtsi
>>   ARM: dts: Add camera subsystem nodes to exynos4x12.dtsi
>>   ARM: dts: Add camera device nodes for Exynos4412 TRATS2 board
>>   ARM: dts: Add camera device nodes for Exynos4210 SoCs
>>   ARM: dts: Add FIMC nodes for Exynos4210 Trats board
>>   ARM: dts: Add MIPI PHY node to exynos4.dtsi
>>
>>  arch/arm/boot/dts/exynos4.dtsi            |  102
> ++++++++++++++++++++++++--
>>  arch/arm/boot/dts/exynos4210-pinctrl.dtsi |   23 ++++++
>>  arch/arm/boot/dts/exynos4210-trats.dts    |  103
> ++++++++++++++++++++++---
>> --
>>  arch/arm/boot/dts/exynos4210.dtsi         |   30 ++++++++
>>  arch/arm/boot/dts/exynos4412-trats2.dts   |  110
>> +++++++++++++++++++++++++++++
>>  arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |   61 ++++++++++++++--
>>  arch/arm/boot/dts/exynos4x12.dtsi         |  103
> +++++++++++++++++++++++++++
>>  7 files changed, 503 insertions(+), 29 deletions(-)
>>
>> --
>> 1.7.9.5
> 
> Basically, I'm fine on this series but you said, you will address comments
> on some patches :)

Thanks, I've just sent an updated series. Would be good to finally
merge it if it looks OK. I have a few more patches on top of it but
that likely could be merged only in a week or two, after related
driver changes are finally reviewed and queued for 3.12.

--
Thanks,
Sylwester


From afzal at ti.com  Wed Jul 24 09:38:13 2013
From: afzal at ti.com (Afzal Mohammed)
Date: Wed, 24 Jul 2013 19:08:13 +0530
Subject: [PATCH 1/2] ARM: OMAP2+: hwmod: rt address space index for DT
In-Reply-To: <4bb04ee7bcb8ca73d5fc43049ba029471b9cdda3.1373036932.git.afzal@ti.com>
References: <4bb04ee7bcb8ca73d5fc43049ba029471b9cdda3.1373036932.git.afzal@ti.com>
Message-ID: <51EFD8C5.8030505@ti.com>

Hi Paul, Benoit,

On 7/5/2013 8:43 PM, Afzal Mohammed wrote:

> Address space is being removed from hwmod database and DT information
> in <reg> property is being used. Currently the 0th index of device
> address space is used to map for register target address. This is not
> always true, eg. cpgmac has it's sysconfig in second address space.
>
> Handle it by specifying index of device address space to be used for
> register target. As default value of this field would be zero with
> static initialization, existing behaviour of using first address space
> for register target while using DT would be kept as such.

This series is required to fix the wrong register target address being 
picked up by hwmod for cpgmac on am335x.

Issue happened during last merge window cleanup, where address space was 
removed from hwmod, and in turn DTS was relied upon for address 
space(Earlier having the address space in hwmod did not cause any issue 
as 'ADDR_TYPE_RT' was used to specify proper address space index).

Please help this series reach mainline for v3.11

Regards
Afzal



From rahul.sharma at samsung.com  Wed Jul 24 10:13:30 2013
From: rahul.sharma at samsung.com (Rahul Sharma)
Date: Wed, 24 Jul 2013 19:43:30 +0530
Subject: [PATCH v3 0/5] clk/exynos5250: add clocks for hdmi subsystem
Message-ID: <1374675215-27862-1-git-send-email-rahul.sharma@samsung.com>

Add clock changes for hdmi subsystem for exynos5250 SoC. These
include addition of new clocks like mout_hdmi and smmu_tv, associating
ID to clk_hdmiphy and some essential corrections.

This set is based on kukjin's for-next branch at
http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.

V3:
1) Rebase to kgene for-next based on 3.11-rc1.
2) Added Tushar's patch in the series.

V2:
1) Dropped "clk/exynos5250: Fix HDMI clock number in documentation" as
it already get merged.

Rahul Sharma (4):
  clk/exynos5250: add mout_hdmi mux clock for hdmi
  clk/exynos5250: add sclk_hdmiphy in the list of special clocks
  clk/exynos5250: add clock for mixer sysmmu
  clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem

Tushar Behera (1):
  Documentation: exynos5250-clock: Add div_i2s1 and div_i2s2

 .../devicetree/bindings/clock/exynos5250-clock.txt |   12 ++++++++++++
 drivers/clk/samsung/clk-exynos5250.c               |   20 ++++++++++++++------
 2 files changed, 26 insertions(+), 6 deletions(-)

-- 
1.7.10.4



From rahul.sharma at samsung.com  Wed Jul 24 10:13:31 2013
From: rahul.sharma at samsung.com (Rahul Sharma)
Date: Wed, 24 Jul 2013 19:43:31 +0530
Subject: [PATCH v3 1/5] Documentation: exynos5250-clock: Add div_i2s1 and
 div_i2s2
In-Reply-To: <1374675215-27862-1-git-send-email-rahul.sharma@samsung.com>
References: <1374675215-27862-1-git-send-email-rahul.sharma@samsung.com>
Message-ID: <1374675215-27862-2-git-send-email-rahul.sharma@samsung.com>

From: Tushar Behera <tushar.behera at linaro.org>

commit 79d743c177f9 ("clk: exynos5250: Add enum entries for divider
clock of i2s1 and i2s2") added two new clock entries. Add the clock
entry enum numbers to documentation.

Signed-off-by: Tushar Behera <tushar.behera at linaro.org>
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 781a627..6772971 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -59,6 +59,8 @@ clock which they consume.
   sclk_spi0		154
   sclk_spi1		155
   sclk_spi2		156
+  div_i2s1		157
+  div_i2s2		158
 
 
    [Peripheral Clock Gates]
-- 
1.7.10.4



From rahul.sharma at samsung.com  Wed Jul 24 10:13:32 2013
From: rahul.sharma at samsung.com (Rahul Sharma)
Date: Wed, 24 Jul 2013 19:43:32 +0530
Subject: [PATCH v3 2/5] clk/exynos5250: add mout_hdmi mux clock for hdmi
In-Reply-To: <1374675215-27862-1-git-send-email-rahul.sharma@samsung.com>
References: <1374675215-27862-1-git-send-email-rahul.sharma@samsung.com>
Message-ID: <1374675215-27862-3-git-send-email-rahul.sharma@samsung.com>

hdmi driver needs to change the parent of hdmi clock
frequently between pixel clock and hdmiphy clock. hdmiphy is
not stable after power on and for a short interval while changing
the phy configuration. For this duration pixel clock is used to
clock hdmi.

This patch is exposing the mux for changing parent.

Signed-off-by: Rahul Sharma <rahul.sharma at samsung.com>
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |    8 ++++++++
 drivers/clk/samsung/clk-exynos5250.c                         |    5 ++++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 6772971..488fbb2 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -158,6 +158,14 @@ clock which they consume.
   mixer			343
   hdmi			345
 
+
+   [Clock Muxes]
+
+  Clock			ID
+  ----------------------------
+  mout_hdmi		1024
+
+
 Example 1: An example of a clock controller node is listed below.
 
 	clock: clock-controller at 0x10010000 {
diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index 6f767c5..df44419 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -101,6 +101,9 @@ enum exynos5250_clks {
 	tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
 	wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
 
+	/* mux clocks */
+	mout_hdmi = 1024,
+
 	nr_clks,
 };
 
@@ -232,7 +235,7 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata = {
 	MUX(none, "mout_fimd1", mout_group1_p, SRC_DISP1_0, 0, 4),
 	MUX(none, "mout_mipi1", mout_group1_p, SRC_DISP1_0, 12, 4),
 	MUX(none, "mout_dp", mout_group1_p, SRC_DISP1_0, 16, 4),
-	MUX(none, "mout_hdmi", mout_hdmi_p, SRC_DISP1_0, 20, 1),
+	MUX(mout_hdmi, "mout_hdmi", mout_hdmi_p, SRC_DISP1_0, 20, 1),
 	MUX(none, "mout_audio0", mout_audio0_p, SRC_MAU, 0, 4),
 	MUX(none, "mout_mmc0", mout_group1_p, SRC_FSYS, 0, 4),
 	MUX(none, "mout_mmc1", mout_group1_p, SRC_FSYS, 4, 4),
-- 
1.7.10.4



From rahul.sharma at samsung.com  Wed Jul 24 10:13:33 2013
From: rahul.sharma at samsung.com (Rahul Sharma)
Date: Wed, 24 Jul 2013 19:43:33 +0530
Subject: [PATCH v3 3/5] clk/exynos5250: add sclk_hdmiphy in the list of special
 clocks
In-Reply-To: <1374675215-27862-1-git-send-email-rahul.sharma@samsung.com>
References: <1374675215-27862-1-git-send-email-rahul.sharma@samsung.com>
Message-ID: <1374675215-27862-4-git-send-email-rahul.sharma@samsung.com>

hdmi driver needs hdmiphy clock which is one of the parent
for hdmi mux clock. This is required while changing the parent
of mux clock.

Signed-off-by: Rahul Sharma <rahul.sharma at samsung.com>

Conflicts:
	drivers/clk/samsung/clk-exynos5250.c
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |    1 +
 drivers/clk/samsung/clk-exynos5250.c                         |    4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 488fbb2..10b9f2a 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -61,6 +61,7 @@ clock which they consume.
   sclk_spi2		156
   div_i2s1		157
   div_i2s2		158
+  sclk_hdmiphy		159
 
 
    [Peripheral Clock Gates]
diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index df44419..9579cfe 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -87,7 +87,7 @@ enum exynos5250_clks {
 	sclk_mmc0, sclk_mmc1, sclk_mmc2, sclk_mmc3, sclk_sata, sclk_usb3,
 	sclk_jpeg, sclk_uart0, sclk_uart1, sclk_uart2, sclk_uart3, sclk_pwm,
 	sclk_audio1, sclk_audio2, sclk_spdif, sclk_spi0, sclk_spi1, sclk_spi2,
-	div_i2s1, div_i2s2,
+	div_i2s1, div_i2s2, sclk_hdmiphy,
 
 	/* gate clocks */
 	gscl0 = 256, gscl1, gscl2, gscl3, gscl_wa, gscl_wb, smmu_gscl0,
@@ -200,7 +200,7 @@ struct samsung_fixed_rate_clock exynos5250_fixed_rate_ext_clks[] __initdata = {
 
 /* fixed rate clocks generated inside the soc */
 struct samsung_fixed_rate_clock exynos5250_fixed_rate_clks[] __initdata = {
-	FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 24000000),
+	FRATE(sclk_hdmiphy, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 24000000),
 	FRATE(none, "sclk_hdmi27m", NULL, CLK_IS_ROOT, 27000000),
 	FRATE(none, "sclk_dptxphy", NULL, CLK_IS_ROOT, 24000000),
 	FRATE(none, "sclk_uhostphy", NULL, CLK_IS_ROOT, 48000000),
-- 
1.7.10.4



From rahul.sharma at samsung.com  Wed Jul 24 10:13:34 2013
From: rahul.sharma at samsung.com (Rahul Sharma)
Date: Wed, 24 Jul 2013 19:43:34 +0530
Subject: [PATCH v3 4/5] clk/exynos5250: add clock for mixer sysmmu
In-Reply-To: <1374675215-27862-1-git-send-email-rahul.sharma@samsung.com>
References: <1374675215-27862-1-git-send-email-rahul.sharma@samsung.com>
Message-ID: <1374675215-27862-5-git-send-email-rahul.sharma@samsung.com>

Adding sysmmu clock for mixer for exynos5250 SoC. It also
adds aclk200_disp1 mux which is the real parent of the
disp1 block (contains hdmi, mixer, sysmmu_mixer).

Signed-off-by: Rahul Sharma <rahul.sharma at samsung.com>
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |    1 +
 drivers/clk/samsung/clk-exynos5250.c                         |    7 ++++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 10b9f2a..d4eefcf 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -158,6 +158,7 @@ clock which they consume.
   dp			342
   mixer			343
   hdmi			345
+  smmu_mixer		346
 
 
    [Clock Muxes]
diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index 9579cfe..c727d9e 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -24,6 +24,7 @@
 #define SRC_CORE1		0x4204
 #define SRC_TOP0		0x10210
 #define SRC_TOP2		0x10218
+#define SRC_TOP3		0x1021C
 #define SRC_GSCL		0x10220
 #define SRC_DISP1_0		0x1022c
 #define SRC_MAU			0x10240
@@ -99,7 +100,7 @@ enum exynos5250_clks {
 	spi2, i2s1, i2s2, pcm1, pcm2, pwm, spdif, ac97, hsi2c0, hsi2c1, hsi2c2,
 	hsi2c3, chipid, sysreg, pmu, cmu_top, cmu_core, cmu_mem, tzpc0, tzpc1,
 	tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
-	wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
+	wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, smmu_mixer,
 
 	/* mux clocks */
 	mout_hdmi = 1024,
@@ -172,6 +173,7 @@ PNAME(mout_mpll_user_p)	= { "fin_pll", "sclk_mpll" };
 PNAME(mout_bpll_user_p)	= { "fin_pll", "sclk_bpll" };
 PNAME(mout_aclk166_p)	= { "sclk_cpll", "sclk_mpll_user" };
 PNAME(mout_aclk200_p)	= { "sclk_mpll_user", "sclk_bpll_user" };
+PNAME(mout_aclk200_disp1_sub_p) = { "fin_pll", "aclk200" };
 PNAME(mout_hdmi_p)	= { "div_hdmi_pixel", "sclk_hdmiphy" };
 PNAME(mout_usb3_p)	= { "sclk_mpll_user", "sclk_cpll" };
 PNAME(mout_group1_p)	= { "fin_pll", "fin_pll", "sclk_hdmi27m",
@@ -227,6 +229,8 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata = {
 	MUX(none, "mout_aclk166", mout_aclk166_p, SRC_TOP0, 8, 1),
 	MUX(none, "mout_aclk333", mout_aclk166_p, SRC_TOP0, 16, 1),
 	MUX(none, "mout_aclk200", mout_aclk200_p, SRC_TOP0, 12, 1),
+	MUX(none, "mout_aclk200_disp1", mout_aclk200_disp1_sub_p,
+			SRC_TOP3, 4, 1),
 	MUX(none, "mout_cam_bayer", mout_group1_p, SRC_GSCL, 12, 4),
 	MUX(none, "mout_cam0", mout_group1_p, SRC_GSCL, 16, 4),
 	MUX(none, "mout_cam1", mout_group1_p, SRC_GSCL, 20, 4),
@@ -328,6 +332,7 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
 	GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
 	GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
 	GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
+	GATE(smmu_mixer, "smmu_mixer", "mout_aclk200_disp1", GATE_IP_DISP1, 9, 0, 0),
 	GATE(mfc, "mfc", "aclk333", GATE_IP_MFC, 0, 0, 0),
 	GATE(smmu_mfcl, "smmu_mfcl", "aclk333", GATE_IP_MFC, 1, 0, 0),
 	GATE(smmu_mfcr, "smmu_mfcr", "aclk333", GATE_IP_MFC, 2, 0, 0),
-- 
1.7.10.4



From rahul.sharma at samsung.com  Wed Jul 24 10:13:35 2013
From: rahul.sharma at samsung.com (Rahul Sharma)
Date: Wed, 24 Jul 2013 19:43:35 +0530
Subject: [PATCH v3 5/5] clk/exynos5250: change parent to aclk200_disp1 for hdmi
 subsystem
In-Reply-To: <1374675215-27862-1-git-send-email-rahul.sharma@samsung.com>
References: <1374675215-27862-1-git-send-email-rahul.sharma@samsung.com>
Message-ID: <1374675215-27862-6-git-send-email-rahul.sharma@samsung.com>

parent of hdmi and mixer block is mentioned as aclk200 which is
not correct. It is clocked by the ouput of aclk200_disp1. Hence
parent for mixer and hdmi clocks is changed to aclk200_disp1.

Signed-off-by: Rahul Sharma <rahul.sharma at samsung.com>
---
 drivers/clk/samsung/clk-exynos5250.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index c727d9e..24a66b3 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -469,8 +469,8 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
 	GATE(mie1, "mie1", "aclk200", GATE_IP_DISP1, 1, 0, 0),
 	GATE(dsim0, "dsim0", "aclk200", GATE_IP_DISP1, 3, 0, 0),
 	GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
-	GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
-	GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
+	GATE(mixer, "mixer", "mout_aclk200_disp1", GATE_IP_DISP1, 5, 0, 0),
+	GATE(hdmi, "hdmi", "mout_aclk200_disp1", GATE_IP_DISP1, 6, 0, 0),
 };
 
 static __initdata struct of_device_id ext_clk_match[] = {
-- 
1.7.10.4



From will.deacon at arm.com  Wed Jul 24 09:56:17 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 14:56:17 +0100
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <51EE474D.5070804@ti.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com>
Message-ID: <20130724135617.GI11072@mudshark.cambridge.arm.com>

On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote:
> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:
> > Hi Rajendra,
> > 
> > On Tue, 23 Jul 2013, Rajendra Nayak wrote:
> > 
> >> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
> >>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
> >>>
> >>>> Bear in mind that I'm almost at the point of not boot-testing anything
> >>>> I sent to Linus because of the uselessness of the SDP4430 board now
> >>>> that it's DT only - the only platform which boot-tests anything I send
> >>>> is the 3430LDP board now.  If people care about that, maybe they can
> >>>> assist with sorting out the issues I've raised on these lists about
> >>>> the SDP4430 - and why the SDP4430 build remains disabled in my build
> >>>> and boot system.
> >>>
> >>> I understand completely...
> >>>
> >>>> Looking at the boot log, it just stops after uboot hands over control.
> >>>> With the lack of output from the decompressor, it's not possible to
> >>>> tell whether it's a decompressor problem or a kernel problem.
> >>>>
> >>>> I think you need to turn on the LL_DEBUG option, select the appropriate
> >>>> output option, and also get the decompressor to use the kernel's debug
> >>>> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
> >>>
> >>> OK, will dig deeper here at the next opportunity.
> >>
> >> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
> >> 2430sdp as the subject says, or was that a typo?
> > 
> > Thanks for the offer.  The issue that I'm seeing is on the 2430SDP in my 
> > testbed.
> > 
> > I don't have a 4430SDP, so you might consider touching base with rmk for 
> > that one.
> 
> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
> the below errors. (I am using the mainline bootloaders which do not lock any
> additional DPLLs like USB)

Any update on this? If it's an issue introduced by architectural changes,
I'd really like to bisect it down but I don't have a board.

Will


From t.figa at samsung.com  Wed Jul 24 10:01:18 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Wed, 24 Jul 2013 16:01:18 +0200
Subject: [PATCH v2 6/6] ARM: S3C24XX: Convert s3c2416 and s3c2443 to common
 clock framework
In-Reply-To: <0ee601ce886d$abb6a690$0323f3b0$@org>
References: <201307100057.06061.heiko@sntech.de> <2236509.stVfXyPhpt@amdc1227>
 <0ee601ce886d$abb6a690$0323f3b0$@org>
Message-ID: <2889437.fCIi7koiPh@amdc1227>

On Wednesday 24 of July 2013 21:59:45 Kukjin Kim wrote:
> Tomasz Figa wrote:
> 
> [...]
> 
> > > > +	timer at 51000000 {
> > > > +		clocks = <&clocks PCLK_PWM>;
> > > 
> > > +		clocks = <&clock PCLK_PWM>;
> > > 
> > > And I'm not sure using definition PCLK_PWM is better here...
> > 
> > Care to explain your doubts about it? I think this is fine.
> 
> I mean I don't know why someone use a hard value(number) and someone use
> the definition...

Since preprocessor support for dts files was introduced, definitions are 
preferred, wherever possible to specify constants.

Best regards,
Tomasz



From t.figa at samsung.com  Wed Jul 24 10:03:55 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Wed, 24 Jul 2013 16:03:55 +0200
Subject: [PATCH v2 07/22] ARM: Exynos4210: Remove '0x's from Exynos4110
 DTSI file
In-Reply-To: <20130724123931.GL26801@laptop>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-7-git-send-email-lee.jones@linaro.org>
 <20130724123931.GL26801@laptop>
Message-ID: <6156493.tCYrm4xD5A@amdc1227>

On Wednesday 24 of July 2013 13:39:31 Lee Jones wrote:
> ... for the sake of consistency and assumed convention.
> 
> Cc: Kukjin Kim <kgene.kim at samsung.com>
> Cc: linux-samsung-soc at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> b/arch/arm/boot/dts/exynos4210.dtsi index b7f358a..53e2527 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -72,7 +72,7 @@
>                 };
>         };
> 
> -       clock: clock-controller at 0x10030000 {
> +       clock: clock-controller at 10030000 {
>                 compatible = "samsung,exynos4210-clock";
>                 reg = <0x10030000 0x20000>;
>                 #clock-cells = <1>;

Looks good to me, except the subject which is still wrong - 
s/Exynos4110/Exynos4210/.

I guess it might be fixed when applying, though.

Best regards,
Tomasz



From santosh.shilimkar at ti.com  Wed Jul 24 10:04:24 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 24 Jul 2013 10:04:24 -0400
Subject: [PATCH 6/8] ARM: mm: LPAE: Correct virt_to_phys patching for
 64 bit physical addresses
In-Reply-To: <51EFC37B.80906@ti.com>
References: <1371858502-10083-1-git-send-email-santosh.shilimkar@ti.com>
 <1371858502-10083-7-git-send-email-santosh.shilimkar@ti.com>
 <alpine.LFD.2.03.1307231850350.15022@syhkavp.arg> <51EF356D.2050902@ti.com>
 <alpine.LFD.2.03.1307232222200.15022@syhkavp.arg> <51EFBF8F.4010201@ti.com>
 <51EFC37B.80906@ti.com>
Message-ID: <51EFDEE8.5050205@ti.com>

On Wednesday 24 July 2013 08:07 AM, Sricharan R wrote:
> On Wednesday 24 July 2013 05:20 PM, Sricharan R wrote:
>> On Wednesday 24 July 2013 08:19 AM, Nicolas Pitre wrote:
>>> On Tue, 23 Jul 2013, Santosh Shilimkar wrote:
>>>
>>>> On Tuesday 23 July 2013 09:10 PM, Nicolas Pitre wrote:
>>>>> On Fri, 21 Jun 2013, Santosh Shilimkar wrote:
>>>>>
>>>>>> From: Sricharan R <r.sricharan at ti.com>
>>>>>>
>>>>>> The current phys_to_virt patching mechanism does not work
>>>>>> for 64 bit physical addressesp. Note that constant used in add/sub
>>>>>> instructions is encoded in to the last 8 bits of the opcode. So shift
>>>>>> the _pv_offset constant by 24 to get it in to the correct place.
>>>>>>
>>>>>> The v2p patching mechanism patches the higher 32bits of physical
>>>>>> address with a constant. While this is correct, in those platforms
>>>>>> where the lowmem addressable physical memory spawns across 4GB boundary,
>>>>>> a carry bit can be produced as a result of addition of lower 32bits.
>>>>>> This has to be taken in to account and added in to the upper. The patched
>>>>>> __pv_offset and va are added in lower 32bits, where __pv_offset can be
>>>>>> in two's complement form when PA_START < VA_START and that can result
>>>>>> in a false carry bit.
>>>>>>
>>>>>> e.g PA = 0x80000000 VA = 0xC0000000
>>>>>> __pv_offset = PA - VA = 0xC0000000 (2's complement)
>>>>>>
>>>>>> So adding __pv_offset + VA should never result in a true overflow. So in
>>>>>> order to differentiate between a true carry, a extra flag __pv_sign_flag
>>>>>> is introduced.
>>>> First of all thanks for the review.
>>>>  
>>>>> I'm still wondering if this is worth bothering about.
>>>>>
>>>>> If PA = 0x80000000 and VA = 0xC0000000 there will never be a real carry 
>>>>> to propagate to the high word of the physical address as the VA space 
>>>>> cannot be larger than 0x40000000.
>>>>>
>>>> Agreed.
>>>>
>>>>> So is there really a case where:
>>>>>
>>>>> 1) physical memory is crossing the 4GB mark, and ...
>>>>>
>>>>> 2) physical memory start address is higher than virtual memory start 
>>>>>    address needing a carry due to the 32-bit add overflow?
>>>>>
>>>> Consider below two cases of memory layout apart from one mentioned
>>>> above where the carry is bit irrelevant as you rightly said.
>>>>
>>>> 1) PA = 0x8_0000_0000, VA= 0xC000_0000, absolute pv_offset = 0x7_4000_0000
>>> This can be patched as:
>>>
>>> 	mov	phys_hi, #0x8
>>> 	add	phys_lo, virt, #0x40000000  @ carry ignored
>>>
>>>> 2) PA = 0x2_8000_0000, VA= 0xC000_000, absolute pv_offset = 0x1_C000_0000
>>> 	mov	phys_hi, #0x2
>>> 	add	phys_lo, virt, #0xc0000000  @ carry ignored
>>>
>>>> In both of these cases there a true carry which needs to be
>>>> considered.
>>> Well, not really.  However, if you have:
>>>
>>> 3) PA = 0x2_8000_0000, VA = 0x4000-0000, pv_offset = 0x2-4000-0000
>>>
>>> ... then you need:
>>>
>>> 	mov	phys_hi, #0x2
>>> 	adds	phys_lo, virt, #0x40000000
>>> 	adc	phys_hi, phys_hi, #0
>>>
>>> My question is: how likely is this?
>>>
>>> What is your actual physical memory start address?
>>  Agreed.  In our case we do not have the Physical address crossing across
>>   4GB. So ignoring the carry would have be been OK. But we are
>>  also addressing the other case where it would really crossover.
>>
Yes. We don't need to worry this case. We can get to this with kernel:user
split but nobody uses that case so we can safely ignore this case.

>>> If we really need to cope with the carry, then the __pv_sign_flag should 
>>> instead be represented in pv_offset directly:
>>>
>>> Taking example #2 above, that would be:
>>>
>>> 	mov	phys_hi, #0x1
>>> 	adds	phys_lo, virt, #0xc0000000
>>> 	adc	phys_hi, phys_hi, #0
>>>
>>> If PA = 0x8000-0000 and VA = 0xc000-0000 then pv_offset is 
>>> 0xffff-ffff-c000-0000, meaning:
>>>
>>> 	mvn	phys_hi, #0
>>> 	add	phys_lo, virt, #0xc0000000
>>> 	adc	phys_hi, phys_hi, #0
>>>
>>> So that would require a special case in the patching code where a mvn 
>>> with 0 is used if the high part of pv_offset is 0xffffffff.
>>>
>>>
>>> Nicolas
>> Extending pv_offset to 64bit is really neat way. When PA > VA, then pv_offset
>> is going to be actual value and not 2's complement. Fine here.
>> When running from higher physical address space, we will always fall here.
>>
>> So for the second case where pv_offset is 0xffffffff .., (PA < VA)
>> is a problem only when we run from lower physical address. So we can safely
>> assume that the higher 32bits of PA are '0' and stub it initially. In this way we
>> can avoid the special case.
>    Sorry, I missed one more point here. In the second case,we should patch it with
>    0x0 when (PA > VA) and with 0xffffffff when (PA < VA).
> 
As Sricharan said, we agree with your suggestion for the special case patching. It
will be either 0x0 or 0xffffffff so easy to take care. We will try out the
suggested changes.

Thanks a lot again.

Regards,
Santosh



From tobetter at gmail.com  Wed Jul 24 10:10:24 2013
From: tobetter at gmail.com (Dongjin Kim)
Date: Wed, 24 Jul 2013 23:10:24 +0900
Subject: [PATCH v2] ARM: dts: Add USB host node for Exynos4
In-Reply-To: <1374600763-19466-1-git-send-email-tobetter@gmail.com>
References: <1374600763-19466-1-git-send-email-tobetter@gmail.com>
Message-ID: <1374675026-21798-1-git-send-email-tobetter@gmail.com>

This patch adds EHCI and OHCI host device nodes for Exynos4.

Signed-off-by: Dongjin Kim <tobetter at gmail.com>
---
 arch/arm/boot/dts/exynos4.dtsi |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 3f94fe8..cbe5219 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -155,6 +155,24 @@
 		status = "disabled";
 	};
 
+	ehci at 12580000 {
+		compatible = "samsung,exynos4210-ehci";
+		reg = <0x12580000 0x100>;
+		interrupts = <0 70 0>;
+		clocks = <&clock 304>;
+		clock-names = "usbhost";
+		status = "disabled";
+	};
+
+	ohci at 12590000 {
+		compatible = "samsung,exynos4210-ohci";
+		reg = <0x12590000 0x100>;
+		interrupts = <0 70 0>;
+		clocks = <&clock 304>;
+		clock-names = "usbhost";
+		status = "disabled";
+	};
+
 	mfc: codec at 13400000 {
 		compatible = "samsung,mfc-v5";
 		reg = <0x13400000 0x10000>;
-- 
1.7.9.5



From rogerq at ti.com  Wed Jul 24 10:16:52 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 24 Jul 2013 17:16:52 +0300
Subject: [PATCHv4 00/33] ARM: OMAP: clock conversion to DT
In-Reply-To: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
Message-ID: <51EFE1D4.8090307@ti.com>

On 07/23/2013 10:19 AM, Tero Kristo wrote:
> Hi,
> 
> Changes compared to previous version:
> 
> - Clock init files moved from mach-omap2/ to drivers/clk/omap/
> - AM33xx support added [patches 15-20]
> - OMAP3 support added [patches 21-29]
> - DRA7 APLL support added (thanks Keerthy) [patches 30-33]
> 
> Test branch on top of 3.11-rc1 available here:
> 
> git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
> branch: mainline-3.11-rc1-omap-dt-clks
> 
> Testing done:
> 
> - boot + suspend tested on OMAP3 beagle C4 (omap3530)
> - boot + suspend tested on OMAP4 panda ES (omap4460)
> - boot tested on beagle bone (am335x)
> 
> A boot test was also executed for DRA7 and OMAP5 on a separate branch
> (mainline does not have OMAP5 / DRA7 support so far.)

Thanks to your hints, I was able to get this to work with 3.11-rc1 on omap5 uevm
using the following 3 patches. Please include them in your series. Thanks.

cheers,
-roger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-dts-OMAP5-Provide-clock-tree-data.patch
Type: text/x-patch
Size: 802 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130724/2dbc50ae/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-CLK-omap5-Call-clock-init-function-at-boot.patch
Type: text/x-patch
Size: 1311 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130724/2dbc50ae/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-CLK-omap5-Initialize-USB_DPLL-at-boot.patch
Type: text/x-patch
Size: 1552 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130724/2dbc50ae/attachment-0005.bin>

From santosh.shilimkar at ti.com  Wed Jul 24 10:17:01 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 24 Jul 2013 10:17:01 -0400
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <20130724135617.GI11072@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
Message-ID: <51EFE1DD.8070801@ti.com>

On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote:
> On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote:
>> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:
>>> Hi Rajendra,
>>>
>>> On Tue, 23 Jul 2013, Rajendra Nayak wrote:
>>>
>>>> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
>>>>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
>>>>>
>>>>>> Bear in mind that I'm almost at the point of not boot-testing anything
>>>>>> I sent to Linus because of the uselessness of the SDP4430 board now
>>>>>> that it's DT only - the only platform which boot-tests anything I send
>>>>>> is the 3430LDP board now.  If people care about that, maybe they can
>>>>>> assist with sorting out the issues I've raised on these lists about
>>>>>> the SDP4430 - and why the SDP4430 build remains disabled in my build
>>>>>> and boot system.
>>>>>
>>>>> I understand completely...
>>>>>
>>>>>> Looking at the boot log, it just stops after uboot hands over control.
>>>>>> With the lack of output from the decompressor, it's not possible to
>>>>>> tell whether it's a decompressor problem or a kernel problem.
>>>>>>
>>>>>> I think you need to turn on the LL_DEBUG option, select the appropriate
>>>>>> output option, and also get the decompressor to use the kernel's debug
>>>>>> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
>>>>>
>>>>> OK, will dig deeper here at the next opportunity.
>>>>
>>>> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
>>>> 2430sdp as the subject says, or was that a typo?
>>>
>>> Thanks for the offer.  The issue that I'm seeing is on the 2430SDP in my 
>>> testbed.
>>>
>>> I don't have a 4430SDP, so you might consider touching base with rmk for 
>>> that one.
>>
>> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
>> the below errors. (I am using the mainline bootloaders which do not lock any
>> additional DPLLs like USB)
> 
> Any update on this? If it's an issue introduced by architectural changes,
> I'd really like to bisect it down but I don't have a board.
> 
>From the other thread, RMK did manage to get the board booting finally
(uImage related issues, low level debug problem) but with DT only supported
build, the audio and DSS was not at same state as before(non-DT build).
And then Tony pointed the issues to Peter and Tomy to address it further.

Russell,
Is above right or I am missing something ?

Regards,
Santosh



From tobetter at gmail.com  Wed Jul 24 10:17:23 2013
From: tobetter at gmail.com (Dongjin Kim)
Date: Wed, 24 Jul 2013 23:17:23 +0900
Subject: [PATCH 1/2] ARM: dts: Add USB Host nodes to Exynos4210
In-Reply-To: <000101ce5c51$887309f0$99591dd0$@samsung.com>
References: <000101ce5c51$887309f0$99591dd0$@samsung.com>
Message-ID: <CADoNuNeax8N1TNRN66-k1fnxxpZCPRUH4Me2VehSDfJzfyq+Zg@mail.gmail.com>

Hi Jingoo,

I had submitted another patch almost similar contents, but my patch
contains both EHCI and OHCI USB host devices node in exynos4.dtsi
since I had tested on Exynos4412 and their register map are same with
Exynos4210.

[1] https://patchwork.kernel.org/patch/2832779

On Wed, May 29, 2013 at 6:47 PM, Jingoo Han <jg1.han at samsung.com> wrote:
> Add device nodes for USB Host EHCI and OHCI controllers to Exynos4210.
>
> Signed-off-by: Jingoo Han <jg1.han at samsung.com>
> ---
> Tested on Exynos4210.
>
>  arch/arm/boot/dts/exynos4210.dtsi |   18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
> index 366795a..3c173c7 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -117,6 +117,24 @@
>                 status = "disabled";
>         };
>
> +       usb at 12580000 {
> +               compatible = "samsung,exynos4210-ehci";
> +               reg = <0x12580000 0x100>;
> +               interrupts = <0 70 0>;
> +
> +               clocks = <&clock 304>;
> +               clock-names = "usbhost";
> +       };
> +
> +       usb at 12590000 {
> +               compatible = "samsung,exynos4210-ohci";
> +               reg = <0x12590000 0x100>;
> +               interrupts = <0 70 0>;
> +
> +               clocks = <&clock 304>;
> +               clock-names = "usbhost";
> +       };
> +
>         g2d at 12800000 {
>                 compatible = "samsung,s5pv210-g2d";
>                 reg = <0x12800000 0x1000>;
> --
> 1.7.10.4
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From will.deacon at arm.com  Wed Jul 24 10:20:59 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 15:20:59 +0100
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <51EFE1DD.8070801@ti.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com>
 <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com>
Message-ID: <20130724142059.GJ11072@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 03:17:01PM +0100, Santosh Shilimkar wrote:
> On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote:
> > On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote:
> >> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:
> >>> Hi Rajendra,
> >>>
> >>> On Tue, 23 Jul 2013, Rajendra Nayak wrote:
> >>>
> >>>> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
> >>>>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
> >>>>>
> >>>>>> Bear in mind that I'm almost at the point of not boot-testing anything
> >>>>>> I sent to Linus because of the uselessness of the SDP4430 board now
> >>>>>> that it's DT only - the only platform which boot-tests anything I send
> >>>>>> is the 3430LDP board now.  If people care about that, maybe they can
> >>>>>> assist with sorting out the issues I've raised on these lists about
> >>>>>> the SDP4430 - and why the SDP4430 build remains disabled in my build
> >>>>>> and boot system.
> >>>>>
> >>>>> I understand completely...
> >>>>>
> >>>>>> Looking at the boot log, it just stops after uboot hands over control.
> >>>>>> With the lack of output from the decompressor, it's not possible to
> >>>>>> tell whether it's a decompressor problem or a kernel problem.
> >>>>>>
> >>>>>> I think you need to turn on the LL_DEBUG option, select the appropriate
> >>>>>> output option, and also get the decompressor to use the kernel's debug
> >>>>>> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
> >>>>>
> >>>>> OK, will dig deeper here at the next opportunity.
> >>>>
> >>>> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
> >>>> 2430sdp as the subject says, or was that a typo?
> >>>
> >>> Thanks for the offer.  The issue that I'm seeing is on the 2430SDP in my 
> >>> testbed.
> >>>
> >>> I don't have a 4430SDP, so you might consider touching base with rmk for 
> >>> that one.
> >>
> >> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
> >> the below errors. (I am using the mainline bootloaders which do not lock any
> >> additional DPLLs like USB)
> > 
> > Any update on this? If it's an issue introduced by architectural changes,
> > I'd really like to bisect it down but I don't have a board.
> > 
> From the other thread, RMK did manage to get the board booting finally
> (uImage related issues, low level debug problem) but with DT only supported
> build, the audio and DSS was not at same state as before(non-DT build).
> And then Tony pointed the issues to Peter and Tomy to address it further.
> 
> Russell,
> Is above right or I am missing something ?

I thought that was the 4430 from before the merge window. Ths issue here is
the 2430 running mainline, as reported by Paul

Will


From will.deacon at arm.com  Wed Jul 24 10:28:26 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 15:28:26 +0100
Subject: [PATCH 02/14] ARM: asm: Add ARM_BE8() assembly helper
In-Reply-To: <1374661682-9349-3-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-3-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130724142825.GK11072@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 11:27:50AM +0100, Ben Dooks wrote:
> Add ARM_BE8() helper to wrap any code conditional on being
> compile when CONFIG_ARM_ENDIAN_BE8 is selected and convert
> existing places where this is to use it.
> 
> Acked-by: Nicolas Pitre <nico at linaro.org>
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>

Reviewed-by: Will Deacon <will.deacon at arm.com>

We could probably add a similar ARM_LE helper to clean up the
__LITTLE_ENDIAN definitions in arch/arm/net/bpf_jit_32.c too.

Will


From t-kristo at ti.com  Wed Jul 24 10:29:43 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 24 Jul 2013 17:29:43 +0300
Subject: [PATCHv4 00/33] ARM: OMAP: clock conversion to DT
In-Reply-To: <51EFE1D4.8090307@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <51EFE1D4.8090307@ti.com>
Message-ID: <51EFE4D7.10800@ti.com>

On 07/24/2013 05:16 PM, Roger Quadros wrote:
> On 07/23/2013 10:19 AM, Tero Kristo wrote:
>> Hi,
>>
>> Changes compared to previous version:
>>
>> - Clock init files moved from mach-omap2/ to drivers/clk/omap/
>> - AM33xx support added [patches 15-20]
>> - OMAP3 support added [patches 21-29]
>> - DRA7 APLL support added (thanks Keerthy) [patches 30-33]
>>
>> Test branch on top of 3.11-rc1 available here:
>>
>> git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
>> branch: mainline-3.11-rc1-omap-dt-clks
>>
>> Testing done:
>>
>> - boot + suspend tested on OMAP3 beagle C4 (omap3530)
>> - boot + suspend tested on OMAP4 panda ES (omap4460)
>> - boot tested on beagle bone (am335x)
>>
>> A boot test was also executed for DRA7 and OMAP5 on a separate branch
>> (mainline does not have OMAP5 / DRA7 support so far.)
>
> Thanks to your hints, I was able to get this to work with 3.11-rc1 on omap5 uevm
> using the following 3 patches. Please include them in your series. Thanks.

Your patches don't apply cleanly to mainline currently, as the omap5 
base support is still not merged. I deliberately left out the full omap5 
integration because of that. Lets see how and when the integration 
proceeds, but I can track your patches meanwhile.

-Tero


From rogerq at ti.com  Wed Jul 24 10:32:32 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 24 Jul 2013 17:32:32 +0300
Subject: [PATCH 0/4] Add USB Host support for OMAP5 uevm
Message-ID: <1374676356-31286-1-git-send-email-rogerq@ti.com>

Hi,

These patches provide USB host support for the OMAP5 uEVM board.

They depend on the OMAP clock tree DT data series by Tero Kristo [1]

In patch 3 we also provide USB PHY clock for Panda. This should make
the clock alias patch [2] redundant and it should be reverted when
this series gets in.

[1] - http://thread.gmane.org/gmane.linux.ports.arm.omap/101582

[2] - ARM: OMAP2+: Provide alias to USB PHY clock
http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/commit/?h=omap-for-v3.11/fixes&id=741532c4a995be11815cb72d4d7a48f442a22fea

cheers,
-roger

---
Roger Quadros (4):
  ARM: OMAP5: hwmod data: Add USB Host and TLL modules
  ARM: dts: OMAP5: Add 60MHz clock reference to USB Host module
  ARM: dts: omap4-panda: Provide USB PHY clock
  ARM: dts: omap5-uevm: Provide USB PHY clock

 arch/arm/boot/dts/omap4-panda-common.dtsi  |    8 +-
 arch/arm/boot/dts/omap5-uevm.dts           |    8 +-
 arch/arm/boot/dts/omap5.dtsi               |    2 +
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  157 ++++++++++++++++++++++++++++
 4 files changed, 163 insertions(+), 12 deletions(-)

-- 
1.7.4.1



From rogerq at ti.com  Wed Jul 24 10:32:34 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 24 Jul 2013 17:32:34 +0300
Subject: [PATCH 2/4] ARM: dts: OMAP5: Add 60MHz clock reference to USB Host
 module
In-Reply-To: <1374676356-31286-1-git-send-email-rogerq@ti.com>
References: <1374676356-31286-1-git-send-email-rogerq@ti.com>
Message-ID: <1374676356-31286-3-git-send-email-rogerq@ti.com>

USB Host driver (drivers/mfd/omap-usb-host.c) expects the 60MHz
reference clock to be named "init_60m_fclk". Provide this
information.

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/boot/dts/omap5.dtsi |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index bc31022..f9f7f74 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -695,6 +695,8 @@
 			#address-cells = <1>;
 			#size-cells = <1>;
 			ranges;
+			clocks = <&l3init_60m_fclk>;
+			clock-names = "init_60m_fclk";
 
 			usbhsohci: ohci at 4a064800 {
 				compatible = "ti,ohci-omap3", "usb-ohci";
-- 
1.7.4.1



From rogerq at ti.com  Wed Jul 24 10:32:33 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 24 Jul 2013 17:32:33 +0300
Subject: [PATCH 1/4] ARM: OMAP5: hwmod data: Add USB Host and TLL modules
In-Reply-To: <1374676356-31286-1-git-send-email-rogerq@ti.com>
References: <1374676356-31286-1-git-send-email-rogerq@ti.com>
Message-ID: <1374676356-31286-2-git-send-email-rogerq@ti.com>

Add hwmod data for High Speed USB host and TLL modules

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  157 ++++++++++++++++++++++++++++
 1 files changed, 157 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 3c70f5c..07b2b8b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1433,6 +1433,145 @@ static struct omap_hwmod omap54xx_uart6_hwmod = {
 };
 
 /*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_usb_host_hs_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.sysc_flags	= (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
+			   SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+			   MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_usb_host_hs_hwmod_class = {
+	.name	= "usb_host_hs",
+	.sysc	= &omap54xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_opt_clk usb_host_hs_opt_clks[] = {
+	{ .role = "hsic60m_p2_clk", .clk = "usb_host_hs_hsic60m_p2_clk" },
+	{ .role = "hsic60m_p3_clk", .clk = "usb_host_hs_hsic60m_p3_clk" },
+	{ .role = "utmi_p1_clk", .clk = "usb_host_hs_utmi_p1_clk" },
+	{ .role = "utmi_p2_clk", .clk = "usb_host_hs_utmi_p2_clk" },
+	{ .role = "utmi_p3_clk", .clk = "usb_host_hs_utmi_p3_clk" },
+	{ .role = "hsic480m_p1_clk", .clk = "usb_host_hs_hsic480m_p1_clk" },
+	{ .role = "hsic60m_p1_clk", .clk = "usb_host_hs_hsic60m_p1_clk" },
+	{ .role = "hsic480m_p3_clk", .clk = "usb_host_hs_hsic480m_p3_clk" },
+	{ .role = "hsic480m_p2_clk", .clk = "usb_host_hs_hsic480m_p2_clk" },
+};
+
+static struct omap_hwmod omap54xx_usb_host_hs_hwmod = {
+	.name		= "usb_host_hs",
+	.class		= &omap54xx_usb_host_hs_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	/*
+	 * Errata: USBHOST Configured In Smart-Idle Can Lead To a Deadlock
+	 * id: i660
+	 *
+	 * Description:
+	 * In the following configuration :
+	 * - USBHOST module is set to smart-idle mode
+	 * - PRCM asserts idle_req to the USBHOST module ( This typically
+	 *   happens when the system is going to a low power mode : all ports
+	 *   have been suspended, the master part of the USBHOST module has
+	 *   entered the standby state, and SW has cut the functional clocks)
+	 * - an USBHOST interrupt occurs before the module is able to answer
+	 *   idle_ack, typically a remote wakeup IRQ.
+	 * Then the USB HOST module will enter a deadlock situation where it
+	 * is no more accessible nor functional.
+	 *
+	 * Workaround:
+	 * Don't use smart idle; use only force idle, hence HWMOD_SWSUP_SIDLE
+	 */
+
+	/*
+	 * Errata: USB host EHCI may stall when entering smart-standby mode
+	 * Id: i571
+	 *
+	 * Description:
+	 * When the USBHOST module is set to smart-standby mode, and when it is
+	 * ready to enter the standby state (i.e. all ports are suspended and
+	 * all attached devices are in suspend mode), then it can wrongly assert
+	 * the Mstandby signal too early while there are still some residual OCP
+	 * transactions ongoing. If this condition occurs, the internal state
+	 * machine may go to an undefined state and the USB link may be stuck
+	 * upon the next resume.
+	 *
+	 * Workaround:
+	 * Don't use smart standby; use only force standby,
+	 * hence HWMOD_SWSUP_MSTANDBY
+	 */
+
+	/*
+	 * During system boot; If the hwmod framework resets the module
+	 * the module will have smart idle settings; which can lead to deadlock
+	 * (above Errata Id:i660); so, dont reset the module during boot;
+	 * Use HWMOD_INIT_NO_RESET.
+	 */
+
+	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+			  HWMOD_INIT_NO_RESET,
+	.main_clk	= "l3init_60m_fclk",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L3INIT_USB_HOST_HS_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L3INIT_USB_HOST_HS_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= usb_host_hs_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(usb_host_hs_opt_clks),
+};
+
+/*
+ * 'usb_tll_hs' class
+ * usb_tll_hs module is the adapter on the usb_host_hs ports
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_usb_tll_hs_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+			   SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_usb_tll_hs_hwmod_class = {
+	.name	= "usb_tll_hs",
+	.sysc	= &omap54xx_usb_tll_hs_sysc,
+};
+
+static struct omap_hwmod_opt_clk usb_tll_hs_opt_clks[] = {
+	{ .role = "usb_ch2_clk", .clk = "usb_tll_hs_usb_ch2_clk" },
+	{ .role = "usb_ch0_clk", .clk = "usb_tll_hs_usb_ch0_clk" },
+	{ .role = "usb_ch1_clk", .clk = "usb_tll_hs_usb_ch1_clk" },
+};
+
+static struct omap_hwmod omap54xx_usb_tll_hs_hwmod = {
+	.name		= "usb_tll_hs",
+	.class		= &omap54xx_usb_tll_hs_hwmod_class,
+	.clkdm_name	= "l3init_clkdm",
+	.main_clk	= "l4_root_clk_div",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP54XX_CM_L3INIT_USB_TLL_HS_CLKCTRL_OFFSET,
+			.context_offs = OMAP54XX_RM_L3INIT_USB_TLL_HS_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.opt_clks	= usb_tll_hs_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(usb_tll_hs_opt_clks),
+};
+
+/*
  * 'usb_otg_ss' class
  * 2.0 super speed (usb_otg_ss) controller
  */
@@ -2056,6 +2195,22 @@ static struct omap_hwmod_ocp_if omap54xx_l4_per__uart6 = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_cfg -> usb_host_hs */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__usb_host_hs = {
+	.master		= &omap54xx_l4_cfg_hwmod,
+	.slave		= &omap54xx_usb_host_hs_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg -> usb_tll_hs */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__usb_tll_hs = {
+	.master		= &omap54xx_l4_cfg_hwmod,
+	.slave		= &omap54xx_usb_tll_hs_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_cfg -> usb_otg_ss */
 static struct omap_hwmod_ocp_if omap54xx_l4_cfg__usb_otg_ss = {
 	.master		= &omap54xx_l4_cfg_hwmod,
@@ -2139,6 +2294,8 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] __initdata = {
 	&omap54xx_l4_per__uart4,
 	&omap54xx_l4_per__uart5,
 	&omap54xx_l4_per__uart6,
+	&omap54xx_l4_cfg__usb_host_hs,
+	&omap54xx_l4_cfg__usb_tll_hs,
 	&omap54xx_l4_cfg__usb_otg_ss,
 	&omap54xx_l4_wkup__wd_timer2,
 	NULL,
-- 
1.7.4.1



From rogerq at ti.com  Wed Jul 24 10:32:35 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 24 Jul 2013 17:32:35 +0300
Subject: [PATCH 3/4] ARM: dts: omap4-panda: Provide USB PHY clock
In-Reply-To: <1374676356-31286-1-git-send-email-rogerq@ti.com>
References: <1374676356-31286-1-git-send-email-rogerq@ti.com>
Message-ID: <1374676356-31286-4-git-send-email-rogerq@ti.com>

The USB PHY gets its clock from AUXCLK3. Provide this
information.

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/boot/dts/omap4-panda-common.dtsi |    8 ++------
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..dd793ca 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -99,12 +99,8 @@
 		compatible = "usb-nop-xceiv";
 		reset-supply = <&hsusb1_reset>;
 		vcc-supply = <&hsusb1_power>;
-	/**
-	 * FIXME:
-	 * put the right clock phandle here when available
-	 *	clocks = <&auxclk3>;
-	 *	clock-names = "main_clk";
-	 */
+		clocks = <&auxclk3_ck>;
+		clock-names = "main_clk";
 		clock-frequency = <19200000>;
 	};
 };
-- 
1.7.4.1



From rogerq at ti.com  Wed Jul 24 10:32:36 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 24 Jul 2013 17:32:36 +0300
Subject: [PATCH 4/4] ARM: dts: omap5-uevm: Provide USB PHY clock
In-Reply-To: <1374676356-31286-1-git-send-email-rogerq@ti.com>
References: <1374676356-31286-1-git-send-email-rogerq@ti.com>
Message-ID: <1374676356-31286-5-git-send-email-rogerq@ti.com>

The HS USB 2 PHY gets its clock from AUXCLK1. Provide this
information.

Signed-off-by: Roger Quadros <rogerq at ti.com>
---
 arch/arm/boot/dts/omap5-uevm.dts |    8 ++------
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..a366cde 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -42,12 +42,8 @@
 	hsusb2_phy: hsusb2_phy {
 		compatible = "usb-nop-xceiv";
 		reset-supply = <&hsusb2_reset>;
-	/**
-	  * FIXME
-	  * Put the right clock phandle here when available
-	  *	clocks = <&auxclk1>;
-	  *	clock-names = "main_clk";
-	  */
+		clocks = <&auxclk1_ck>;
+		clock-names = "main_clk";
 		clock-frequency = <19200000>;
 	};
 
-- 
1.7.4.1



From will.deacon at arm.com  Wed Jul 24 10:33:35 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 15:33:35 +0100
Subject: [PATCH 03/14] ARM: fixup_pv_table bug when CPU_ENDIAN_BE8
In-Reply-To: <1374661682-9349-4-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-4-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130724143335.GL11072@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 11:27:51AM +0100, Ben Dooks wrote:
> The fixup_pv_table assumes that the instructions are in the same
> endian configuration as the data, but when the CPU is running in
> BE8 the instructions stay in little-endian format.
> 
> Make sure if CONFIG_CPU_ENDIAN_BE8 is set that we do all the
> alterations to the instructions taking in to account the LDR/STR
> will be swapping the data endian-ness.
> 
> Since the code is only modifying a byte, we avoid dual-swapping
> the data, and just change the bits we clear and ORR in (in the
> case where the code is not thumb2).
> 
> For thumb2, we add the necessary rev16 instructions to ensure that
> the instructions are processed in the correct format, as it was
> easier than re-writing the code to contain a mask and shift.
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---
>  arch/arm/kernel/head.S |    8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 8bac553..e40c0b3b 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -584,8 +584,10 @@ __fixup_a_pv_table:
>  	b	2f
>  1:	add     r7, r3
>  	ldrh	ip, [r7, #2]
> +ARM_BE8(rev16	ip, ip)
>  	and	ip, 0x8f00
>  	orr	ip, r6	@ mask in offset bits 31-24
> +ARM_BE8(rev16	ip, ip)

I'm not sure I follow you when you say this is easier than a mask and a
shift? As far as I can tell, it's two extra instructions and makes the LE
and BE cases look different.

>  	strh	ip, [r7, #2]
>  2:	cmp	r4, r5
>  	ldrcc	r7, [r4], #4	@ use branch for delay slot
> @@ -594,8 +596,14 @@ __fixup_a_pv_table:
>  #else
>  	b	2f
>  1:	ldr	ip, [r7, r3]
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +	@ in BE8, we load data in BE, but instructions still in LE
> +	bic	ip, ip, #0xff000000
> +	orr	ip, ip, r6, lsl#24

Pedantry: you could add a space between lsl and #24.

Will


From rogerq at ti.com  Wed Jul 24 10:34:15 2013
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 24 Jul 2013 17:34:15 +0300
Subject: [PATCHv4 00/33] ARM: OMAP: clock conversion to DT
In-Reply-To: <51EFE4D7.10800@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <51EFE1D4.8090307@ti.com> <51EFE4D7.10800@ti.com>
Message-ID: <51EFE5E7.4090506@ti.com>

On 07/24/2013 05:29 PM, Tero Kristo wrote:
> On 07/24/2013 05:16 PM, Roger Quadros wrote:
>> On 07/23/2013 10:19 AM, Tero Kristo wrote:
>>> Hi,
>>>
>>> Changes compared to previous version:
>>>
>>> - Clock init files moved from mach-omap2/ to drivers/clk/omap/
>>> - AM33xx support added [patches 15-20]
>>> - OMAP3 support added [patches 21-29]
>>> - DRA7 APLL support added (thanks Keerthy) [patches 30-33]
>>>
>>> Test branch on top of 3.11-rc1 available here:
>>>
>>> git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
>>> branch: mainline-3.11-rc1-omap-dt-clks
>>>
>>> Testing done:
>>>
>>> - boot + suspend tested on OMAP3 beagle C4 (omap3530)
>>> - boot + suspend tested on OMAP4 panda ES (omap4460)
>>> - boot tested on beagle bone (am335x)
>>>
>>> A boot test was also executed for DRA7 and OMAP5 on a separate branch
>>> (mainline does not have OMAP5 / DRA7 support so far.)
>>
>> Thanks to your hints, I was able to get this to work with 3.11-rc1 on omap5 uevm
>> using the following 3 patches. Please include them in your series. Thanks.
> 
> Your patches don't apply cleanly to mainline currently, as the omap5 base support is still not merged. I deliberately left out the full omap5 integration because of that. Lets see how and when the integration proceeds, but I can track your patches meanwhile.
>

Strange, I didn't use any out of tree patch. Just 3.11-rc1 with your 33 patches on top.

Are you on 3.11-rc2?

cheers,
-roger


From broonie at kernel.org  Wed Jul 24 10:35:11 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 24 Jul 2013 15:35:11 +0100
Subject: [PATCH 24/27] sound/soc/pxa: don't check resource with
 devm_ioremap_resource
In-Reply-To: <1374602524-3398-25-git-send-email-wsa@the-dreams.de>
References: <1374602524-3398-1-git-send-email-wsa@the-dreams.de>
 <1374602524-3398-25-git-send-email-wsa@the-dreams.de>
Message-ID: <20130724143511.GG9858@sirena.org.uk>

On Tue, Jul 23, 2013 at 08:01:57PM +0200, Wolfram Sang wrote:
> devm_ioremap_resource does sanity checks on the given resource. No need to
> duplicate this in the driver.

Applied, thanks.
-------------- 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/20130724/721b0383/attachment-0001.sig>

From ben.dooks at codethink.co.uk  Wed Jul 24 10:38:51 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 15:38:51 +0100
Subject: [PATCH 02/14] ARM: asm: Add ARM_BE8() assembly helper
In-Reply-To: <20130724142825.GK11072@mudshark.cambridge.arm.com>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-3-git-send-email-ben.dooks@codethink.co.uk>
 <20130724142825.GK11072@mudshark.cambridge.arm.com>
Message-ID: <51EFE6FB.5020104@codethink.co.uk>

On 24/07/13 15:28, Will Deacon wrote:
> On Wed, Jul 24, 2013 at 11:27:50AM +0100, Ben Dooks wrote:
>> Add ARM_BE8() helper to wrap any code conditional on being
>> compile when CONFIG_ARM_ENDIAN_BE8 is selected and convert
>> existing places where this is to use it.
>>
>> Acked-by: Nicolas Pitre<nico at linaro.org>
>> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
>
> Reviewed-by: Will Deacon<will.deacon at arm.com>
>
> We could probably add a similar ARM_LE helper to clean up the
> __LITTLE_ENDIAN definitions in arch/arm/net/bpf_jit_32.c too.

Ok, but I would like to get to the point where this series is
just fixes now. I would like to try and get it merged and then
go back and look at these issues.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From will.deacon at arm.com  Wed Jul 24 10:41:19 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 15:41:19 +0100
Subject: [PATCH 04/14] ARM: set BE8 if LE in head code
In-Reply-To: <1374661682-9349-5-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-5-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130724144118.GM11072@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 11:27:52AM +0100, Ben Dooks wrote:
> If we are booting in LE and compiled for BE8, then add code to
> set the state to bE8. Since the instruction stream is always LE,
> we do not need to do anything special to the instruction.
> 
> Also ensure that the secondary processors are started in the same mode.
> 
> Note, we do add about 20 bytes to the kernel image, but it seems easier
> to do this than adding another configuration to change.
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---
>  arch/arm/boot/compressed/head.S |    1 +
>  arch/arm/kernel/head.S          |    4 ++++
>  arch/arm/kernel/sleep.S         |    1 +
>  3 files changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 4eb8364..4d83bfd 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -135,6 +135,7 @@ start:
>  		.word	_edata			@ zImage end address
>   THUMB(		.thumb			)
>  1:
> + ARM_BE8(	setend	be )			@ go BE8 if LE, no-op if BE8

I find the comment here slightly confusing as it makes it sound like the
macro expands to nothing if we're BE8 (which is clearly not the case).

>  		mrs	r9, cpsr
>  #ifdef CONFIG_ARM_VIRT_EXT
>  		bl	__hyp_stub_install	@ get into SVC mode, reversibly
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index e40c0b3b..706c441 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -77,6 +77,7 @@
>  
>  	__HEAD
>  ENTRY(stext)
> + ARM_BE8(setend	be )			@ ensure we are in BE8 mode

Alignment issue here -- please try to align the instruction with the
instructions below (it's awkward to read with all the brackets).

>  
>   THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is always entered in ARM.
>   THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
> @@ -351,6 +352,9 @@ ENTRY(secondary_startup)
>  	 * the processor type - there is no need to check the machine type
>  	 * as it has already been validated by the primary processor.
>  	 */
> +
> + ARM_BE8(setend	be)				@ if system starts LE, go BE8
> +
>  #ifdef CONFIG_ARM_VIRT_EXT
>  	bl	__hyp_stub_install_secondary
>  #endif
> diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
> index 987dcf3..954c28a 100644
> --- a/arch/arm/kernel/sleep.S
> +++ b/arch/arm/kernel/sleep.S
> @@ -81,6 +81,7 @@ ENDPROC(cpu_resume_after_mmu)
>  	.data
>  	.align
>  ENTRY(cpu_resume)
> +ARM_BE8(setend be)			@ ensure we are in BE mode

Any reason to have three different comments for the same thing? I think you
probably just need to comment the one in head.S.

Will


From t-kristo at ti.com  Wed Jul 24 10:43:24 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 24 Jul 2013 17:43:24 +0300
Subject: [PATCHv4 00/33] ARM: OMAP: clock conversion to DT
In-Reply-To: <51EFE5E7.4090506@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <51EFE1D4.8090307@ti.com> <51EFE4D7.10800@ti.com> <51EFE5E7.4090506@ti.com>
Message-ID: <51EFE80C.7020805@ti.com>

On 07/24/2013 05:34 PM, Roger Quadros wrote:
> On 07/24/2013 05:29 PM, Tero Kristo wrote:
>> On 07/24/2013 05:16 PM, Roger Quadros wrote:
>>> On 07/23/2013 10:19 AM, Tero Kristo wrote:
>>>> Hi,
>>>>
>>>> Changes compared to previous version:
>>>>
>>>> - Clock init files moved from mach-omap2/ to drivers/clk/omap/
>>>> - AM33xx support added [patches 15-20]
>>>> - OMAP3 support added [patches 21-29]
>>>> - DRA7 APLL support added (thanks Keerthy) [patches 30-33]
>>>>
>>>> Test branch on top of 3.11-rc1 available here:
>>>>
>>>> git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
>>>> branch: mainline-3.11-rc1-omap-dt-clks
>>>>
>>>> Testing done:
>>>>
>>>> - boot + suspend tested on OMAP3 beagle C4 (omap3530)
>>>> - boot + suspend tested on OMAP4 panda ES (omap4460)
>>>> - boot tested on beagle bone (am335x)
>>>>
>>>> A boot test was also executed for DRA7 and OMAP5 on a separate branch
>>>> (mainline does not have OMAP5 / DRA7 support so far.)
>>>
>>> Thanks to your hints, I was able to get this to work with 3.11-rc1 on omap5 uevm
>>> using the following 3 patches. Please include them in your series. Thanks.
>>
>> Your patches don't apply cleanly to mainline currently, as the omap5 base support is still not merged. I deliberately left out the full omap5 integration because of that. Lets see how and when the integration proceeds, but I can track your patches meanwhile.
>>
>
> Strange, I didn't use any out of tree patch. Just 3.11-rc1 with your 33 patches on top.
>
> Are you on 3.11-rc2?

Oh, so OMAP5 hwmod data was actually merged now, cool. Sorry about the 
fuss. I can include your patches to the next rev if one is made.

-Tero


From magnus.damm at gmail.com  Wed Jul 24 10:44:05 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 24 Jul 2013 23:44:05 +0900
Subject: [PATCH 0/3] sh-pfc: Don't include mach/*.h headers were not
 required
In-Reply-To: <1374671368-4681-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374671368-4681-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <CANqRtoQHD9bk4uyAE9GAPvz_ZTLx1EtohFjaYhnetmwQ1Te1qg@mail.gmail.com>

Hi Laurent,

On Wed, Jul 24, 2013 at 10:09 PM, Laurent Pinchart
<laurent.pinchart+renesas at ideasonboard.com> wrote:
> Hello,
>
> The (long) road to multiplatform kernels requires getting rid of mach/*.h
> headers in device drivers. This patch set removes some of the included mach
> headers from the sh-pfc driver. The only remaining one is mach/irqs.h, to get
> the irq_pin() macro. This will require more work, see [1] for a discussion of
> the issue.

That's a blocker for some of the SoCs, right? I suppose the ones using
a separate GPIO controller are OK as-is?

> The patches are based on v3.11-rc2. Linus, do you usually pick pinctrl patches
> from the list, or should I send you a pull request ?
>
> [1] http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg473450.html
>
> Laurent Pinchart (3):
>   sh-pfc: Remove unneeded mach/<soc>.h includes
>   sh-pfc: sh7372: Replace <mach/irqs.h> with <linux/sh_intc.h>
>   sh-pfc: sh73a0: Remove EXT_IRQ16L and EXT_IRQ16H macros

These are fine with me. Thanks for your help!

Acked-by: Magnus Damm <damm at opensource.se>


From cov at codeaurora.org  Wed Jul 24 10:44:21 2013
From: cov at codeaurora.org (Christopher Covington)
Date: Wed, 24 Jul 2013 10:44:21 -0400
Subject: [PATCH v4 00/17] 64-bit friendly generic sched_clock()
In-Reply-To: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <51EFE845.6010805@codeaurora.org>

On 07/18/2013 07:21 PM, Stephen Boyd wrote:
> This patchset adds support for 64 bit counters in the generic
> sched_clock code and converts drivers over to use it. Based
> on v3.11-rc1.
> 
> Changes since v3:
>  * Move to use seqcount to fix issues with 64-bit cyc counters
>  * Move to hrtimer to fix underflow/overflow errors in wraparound
>    calculation
>  * Use of 1 hour in clocks_calc_mult_shift
>  * Converted over drivers in drivers/clocksource
> 
> Stephen Boyd (17):
>   clocksource: Extract max nsec calculation into separate function
>   sched_clock: Use seqcount instead of rolling our own
>   sched_clock: Use an hrtimer instead of timer
>   sched_clock: Add support for >32 bit sched_clock
>   arch_timer: Move to generic sched_clock framework
>   sched_clock: Remove sched_clock_func() hook
>   clocksource: bcm2835: Switch to sched_clock_register()
>   ocksource: dbx500-prcmu: Switch to sched_clock_register()
>   clocksource: dw_apb_timer_of: Switch to sched_clock_register()
>   clocksource: mxs_timer: Switch to sched_clock_register()
>   clocksource: nomadik: Switch to sched_clock_register()
>   clocksource: samsung_pwm_timer: Switch to sched_clock_register()
>   clocksource: tegra: Switch to sched_clock_register()
>   clocksource: time-armada-370-xp: Switch to sched_clock_register()
>   clocksource: sirf: Switch to sched_clock_register() and use 64 bits
>   clocksource: vf_pit_timer: Switch to sched_clock_register()
>   sched_clock: Deprecate setup_sched_clock()
> 
>  arch/arm/kernel/arch_timer.c              |  14 ----
>  arch/arm64/Kconfig                        |   1 +
>  arch/arm64/kernel/time.c                  |  10 ---
>  drivers/clocksource/arm_arch_timer.c      |   4 ++
>  drivers/clocksource/bcm2835_timer.c       |   4 +-
>  drivers/clocksource/clksrc-dbx500-prcmu.c |   5 +-
>  drivers/clocksource/dw_apb_timer_of.c     |   4 +-
>  drivers/clocksource/mxs_timer.c           |   4 +-
>  drivers/clocksource/nomadik-mtu.c         |   4 +-
>  drivers/clocksource/samsung_pwm_timer.c   |   4 +-
>  drivers/clocksource/tegra20_timer.c       |   4 +-
>  drivers/clocksource/time-armada-370-xp.c  |   4 +-
>  drivers/clocksource/timer-prima2.c        |   6 +-
>  drivers/clocksource/vf_pit_timer.c        |   4 +-
>  include/linux/clocksource.h               |   2 +
>  include/linux/sched_clock.h               |   7 +-
>  kernel/time/clocksource.c                 |  45 ++++++++-----
>  kernel/time/sched_clock.c                 | 105 +++++++++++++++---------------
>  18 files changed, 116 insertions(+), 115 deletions(-)
> 

I ran 32-bit and 64-bit kernels with these patches on the Versatile Express
software model and things looked fine, so for the applicable patches,

Tested-by: Christopher Covington <cov at codeaurora.org>

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.


From will.deacon at arm.com  Wed Jul 24 10:44:20 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 15:44:20 +0100
Subject: [PATCH 05/14] ARM: pl01x debug code endian fix
In-Reply-To: <1374661682-9349-6-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-6-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130724144420.GN11072@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 11:27:53AM +0100, Ben Dooks wrote:
> The PL01X debug code needs to take into account which endian mode the
> processor is running in. If it is big-endian, ensure the data is swapped
> appropriately.
> 
> Note, we could do this slightly more efficiently if we have an macro to
> do the necessary swap for the bits used by test.
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---

Reviewed-by: Will Deacon <will.deacon at arm.com>

Will


From santosh.shilimkar at ti.com  Wed Jul 24 10:45:20 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 24 Jul 2013 10:45:20 -0400
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <20130724142059.GJ11072@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724142059.GJ11072@mudshark.cambridge.arm.com>
Message-ID: <51EFE880.8080309@ti.com>

On Wednesday 24 July 2013 10:20 AM, Will Deacon wrote:
> On Wed, Jul 24, 2013 at 03:17:01PM +0100, Santosh Shilimkar wrote:
>> On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote:
>>> On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote:
>>>> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:
>>>>> Hi Rajendra,
>>>>>
>>>>> On Tue, 23 Jul 2013, Rajendra Nayak wrote:
>>>>>
>>>>>> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
>>>>>>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
>>>>>>>
>>>>>>>> Bear in mind that I'm almost at the point of not boot-testing anything
>>>>>>>> I sent to Linus because of the uselessness of the SDP4430 board now
>>>>>>>> that it's DT only - the only platform which boot-tests anything I send
>>>>>>>> is the 3430LDP board now.  If people care about that, maybe they can
>>>>>>>> assist with sorting out the issues I've raised on these lists about
>>>>>>>> the SDP4430 - and why the SDP4430 build remains disabled in my build
>>>>>>>> and boot system.
>>>>>>>
>>>>>>> I understand completely...
>>>>>>>
>>>>>>>> Looking at the boot log, it just stops after uboot hands over control.
>>>>>>>> With the lack of output from the decompressor, it's not possible to
>>>>>>>> tell whether it's a decompressor problem or a kernel problem.
>>>>>>>>
>>>>>>>> I think you need to turn on the LL_DEBUG option, select the appropriate
>>>>>>>> output option, and also get the decompressor to use the kernel's debug
>>>>>>>> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
>>>>>>>
>>>>>>> OK, will dig deeper here at the next opportunity.
>>>>>>
>>>>>> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
>>>>>> 2430sdp as the subject says, or was that a typo?
>>>>>
>>>>> Thanks for the offer.  The issue that I'm seeing is on the 2430SDP in my 
>>>>> testbed.
>>>>>
>>>>> I don't have a 4430SDP, so you might consider touching base with rmk for 
>>>>> that one.
>>>>
>>>> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
>>>> the below errors. (I am using the mainline bootloaders which do not lock any
>>>> additional DPLLs like USB)
>>>
>>> Any update on this? If it's an issue introduced by architectural changes,
>>> I'd really like to bisect it down but I don't have a board.
>>>
>> From the other thread, RMK did manage to get the board booting finally
>> (uImage related issues, low level debug problem) but with DT only supported
>> build, the audio and DSS was not at same state as before(non-DT build).
>> And then Tony pointed the issues to Peter and Tomy to address it further.
>>
>> Russell,
>> Is above right or I am missing something ?
> 
> I thought that was the 4430 from before the merge window. Ths issue here is
> the 2430 running mainline, as reported by Paul
> 
Actually thread got hijacked a bit when Rajendra replied the OMAP4430
results. I then replied on top of that. Sorry about that

Regards,
Santosh



From ben.dooks at codethink.co.uk  Wed Jul 24 10:48:08 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 15:48:08 +0100
Subject: [PATCH 02/14] ARM: asm: Add ARM_BE8() assembly helper
In-Reply-To: <20130724142825.GK11072@mudshark.cambridge.arm.com>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-3-git-send-email-ben.dooks@codethink.co.uk>
 <20130724142825.GK11072@mudshark.cambridge.arm.com>
Message-ID: <51EFE928.2070907@codethink.co.uk>

On 24/07/13 15:28, Will Deacon wrote:
> On Wed, Jul 24, 2013 at 11:27:50AM +0100, Ben Dooks wrote:
>> Add ARM_BE8() helper to wrap any code conditional on being
>> compile when CONFIG_ARM_ENDIAN_BE8 is selected and convert
>> existing places where this is to use it.
>>
>> Acked-by: Nicolas Pitre<nico at linaro.org>
>> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
>
> Reviewed-by: Will Deacon<will.deacon at arm.com>
>
> We could probably add a similar ARM_LE helper to clean up the
> __LITTLE_ENDIAN definitions in arch/arm/net/bpf_jit_32.c too.
>
> Will

I did however realise we need to fix the instruction storage
so changed _emit to fix this as follows:

     ARM: net: fix arm instruction endian-ness in bpf_jit_32.c

     Use <asm/opcodes.h> to correctly transform instruction byte ordering
     into in-memory ordering.

     Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>

diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index 1a643ee..95b43b6 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -19,6 +19,7 @@
  #include <linux/if_vlan.h>
  #include <asm/cacheflush.h>
  #include <asm/hwcap.h>
+#include <asm/opcodes.h>

  #include "bpf_jit_32.h"

@@ -113,8 +114,11 @@ static u32 jit_udiv(u32 dividend, u32 divisor)

  static inline void _emit(int cond, u32 inst, struct jit_ctx *ctx)
  {
+       inst |= (cond << 28);
+       inst = __opcode_to_mem_arm(inst);
+
         if (ctx->target != NULL)
-               ctx->target[ctx->idx] = inst | (cond << 28);
+               ctx->target[ctx->idx] = inst;

         ctx->idx++;
  }

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From laurent.pinchart at ideasonboard.com  Wed Jul 24 10:49:45 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Wed, 24 Jul 2013 16:49:45 +0200
Subject: [PATCH 0/3] sh-pfc: Don't include mach/*.h headers were not
 required
In-Reply-To: <CANqRtoQHD9bk4uyAE9GAPvz_ZTLx1EtohFjaYhnetmwQ1Te1qg@mail.gmail.com>
References: <1374671368-4681-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <CANqRtoQHD9bk4uyAE9GAPvz_ZTLx1EtohFjaYhnetmwQ1Te1qg@mail.gmail.com>
Message-ID: <2297366.cgFF8sJl8f@avalon>

Hi Magnus,

On Wednesday 24 July 2013 23:44:05 Magnus Damm wrote:
> On Wed, Jul 24, 2013 at 10:09 PM, Laurent Pinchart wrote:
> > Hello,
> > 
> > The (long) road to multiplatform kernels requires getting rid of mach/*.h
> > headers in device drivers. This patch set removes some of the included
> > mach headers from the sh-pfc driver. The only remaining one is
> > mach/irqs.h, to get the irq_pin() macro. This will require more work, see
> > [1] for a discussion of the issue.
> 
> That's a blocker for some of the SoCs, right? I suppose the ones using a
> separate GPIO controller are OK as-is?

Yes. It's a multiplatform blocker for r8a73a4, r8a7740 and sh73a0. SoCs using 
a separate GPIO controller are fine (although the same problem might pop up 
for future SoCs with a separate GPIO controller if the GPIO IRQs are handled 
by a device separate from the GPIO controller).

> > The patches are based on v3.11-rc2. Linus, do you usually pick pinctrl
> > patches from the list, or should I send you a pull request ?
> > 
> > [1]
> > http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg473450.html
> > 
> > Laurent Pinchart (3):
> >   sh-pfc: Remove unneeded mach/<soc>.h includes
> >   sh-pfc: sh7372: Replace <mach/irqs.h> with <linux/sh_intc.h>
> >   sh-pfc: sh73a0: Remove EXT_IRQ16L and EXT_IRQ16H macros
> 
> These are fine with me. Thanks for your help!
> 
> Acked-by: Magnus Damm <damm at opensource.se>

Thank you.

-- 
Regards,

Laurent Pinchart



From will.deacon at arm.com  Wed Jul 24 10:49:24 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 15:49:24 +0100
Subject: [PATCH 06/14] ARM: twd: data endian fix
In-Reply-To: <1374661682-9349-7-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-7-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130724144923.GO11072@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 11:27:54AM +0100, Ben Dooks wrote:
> Ensure the twd driver uses the correct calls to access the hardware
> to ensure that we do not end up with data in the wrong endian format.
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>

Reviewed-by: Will Deacon <will.deacon at arm.com>

There are a bunch of other __raw_* users under arch/arm/, but I suppose we
can let other people move those over as they see fit. It wouldn't hurt to
fix arch/arm/include/asm/{cti,hardware/coresight.h} though.

Will


From linux at arm.linux.org.uk  Wed Jul 24 10:52:38 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 24 Jul 2013 15:52:38 +0100
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <51EFE1DD.8070801@ti.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com>
Message-ID: <20130724145237.GB21614@n2100.arm.linux.org.uk>

On Wed, Jul 24, 2013 at 10:17:01AM -0400, Santosh Shilimkar wrote:
> On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote:
> > On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote:
> >> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:
> >>> Hi Rajendra,
> >>>
> >>> On Tue, 23 Jul 2013, Rajendra Nayak wrote:
> >>>
> >>>> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote:
> >>>>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote:
> >>>>>
> >>>>>> Bear in mind that I'm almost at the point of not boot-testing anything
> >>>>>> I sent to Linus because of the uselessness of the SDP4430 board now
> >>>>>> that it's DT only - the only platform which boot-tests anything I send
> >>>>>> is the 3430LDP board now.  If people care about that, maybe they can
> >>>>>> assist with sorting out the issues I've raised on these lists about
> >>>>>> the SDP4430 - and why the SDP4430 build remains disabled in my build
> >>>>>> and boot system.
> >>>>>
> >>>>> I understand completely...
> >>>>>
> >>>>>> Looking at the boot log, it just stops after uboot hands over control.
> >>>>>> With the lack of output from the decompressor, it's not possible to
> >>>>>> tell whether it's a decompressor problem or a kernel problem.
> >>>>>>
> >>>>>> I think you need to turn on the LL_DEBUG option, select the appropriate
> >>>>>> output option, and also get the decompressor to use the kernel's debug
> >>>>>> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
> >>>>>
> >>>>> OK, will dig deeper here at the next opportunity.
> >>>>
> >>>> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on
> >>>> 2430sdp as the subject says, or was that a typo?
> >>>
> >>> Thanks for the offer.  The issue that I'm seeing is on the 2430SDP in my 
> >>> testbed.
> >>>
> >>> I don't have a 4430SDP, so you might consider touching base with rmk for 
> >>> that one.
> >>
> >> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
> >> the below errors. (I am using the mainline bootloaders which do not lock any
> >> additional DPLLs like USB)
> > 
> > Any update on this? If it's an issue introduced by architectural changes,
> > I'd really like to bisect it down but I don't have a board.
> > 
> >From the other thread, RMK did manage to get the board booting finally
> (uImage related issues, low level debug problem) but with DT only supported
> build, the audio and DSS was not at same state as before(non-DT build).
> And then Tony pointed the issues to Peter and Tomy to address it further.
> 
> Russell,
> Is above right or I am missing something ?

Will is referring to the 2430 issues I think; the original topic of this
thread.

I've not enabled the 4430 again in the build system because I see no point
to it - it can't find its rootfs because the device numbering for the MMC/SD
cards has reversed itself.  Not only does that need the kernel command line
changed, but it also needs fixing in the fstab on the SD card rootfs, and
quite frankly I really can't be bothered at the moment with this kind of
pointless boot breaking churn.

I also continue to be disappointed by the lack of things working on the
4430 - it's been a number of years now and _still_ the on-board LCDs do
not work.  People have tried to blame that on hardware faults and the
like, but they're just being idiotic when they say stuff like that.  It
can't be hardware faults when the kernel supplied with the board is able
to make them work to the extent that userspace can play back video on all
three output devices simultaneously, without hiccup or any imperfection.
I don't know whether it's just that the backlight support isn't working
or what - because any information on the 4430 seems to be a tightly
controlled secret that only a few select people are permitted to know
about.  As far as I'm concerned, much of the hardware is a black box to
me.

And yes, my 4430 has the projector module on it.  Never ever seen that
work, and no idea how to make it work because there's no information
available on the hardware.

It's a bit like the useless 3430LDP - though there's information available
there's no way to work out which of the many different designs of 3430LDP
the one I have ties up with, and I'm pretty sure that all the published
revisions of the circuits for the 3430LDP do not match the version I have
here - which means when things go wrong, there's no way for me to look
at stuff.

And no, I don't want another Beagle board or Panda board or whatever, I
have those (I think I have one of each), and they've never been powered up
because they have no ethernet on them, and I have no USB to ethernet still,
partly because I don't really do USB here *at* *all*, so I don't know what
works well and what doesn't with Linux.  Even if I did provide them with a
USB ethernet, I doubt they'd be able to boot a kernel via the network.

My experience of USB is hellishly poor - I have an icybox eSATA enclosure
which also provides USB.  The USB interface on that regularly drops out
with errors, timeouts, and even isn't recognised on many occasions.  I
see slow serial comms with USB serial devices on platforms like the
4430SDP and Dove Cubox - the speed is very much like a 4800baud modem, even
though the serial runs at 115200 baud.  No, don't even _think_ about blaming
the host, because this happens whether it be a Thinkpad, or the USB hosts
in a Thecus N2100.

I can believe why this all happens, when you see USB interrupts taking
upwards of 3ms to complete:

Longest time: 3247506ns
Longest irq: 24
Longest handler: usb_hcd_irq+0x0/0x68

is it hardly surprising that USB is soo crap?  And the above 3ms is just
for handling a USB keyboard - what takes 3ms over servicing a USB keyboard?
I mean, what crap USB really is when it behaves like that... and is it
no wonder I hate the bloody thing.

Anyway, this is getting off topic. :)


From ian.campbell at citrix.com  Wed Jul 24 10:58:43 2013
From: ian.campbell at citrix.com (Ian Campbell)
Date: Wed, 24 Jul 2013 15:58:43 +0100
Subject: Requirements for FDT load address on ARM
Message-ID: <1374677923.6623.194.camel@hastur.hellion.org.uk>

[apologies if this is a repeat, I don't see it in the archives and at
least one CC'd recipient (Julien) didn't receive it either. Beasties in
our email server I expect...]

Are there any requirements about where the FDT may be loaded by the
bootloader?

I'm finding that if I load it "too high" I get a fault (the specifics
aren't that relevant but details are below). FWIW with RAM from
0x8000000-0xffffffff and a kernel loaded at 0x80008000 "too high" means
above somewhere around 0xaf800000.

I expect this is because the kernel doesn't use an explicit mapping of
the fdt but expects it to be within the RAM directly mapped by the
lowmem area (i.e. it uses phys_to_virt, since day one aka 93c02ab40ae6
"arm/dt: probe for platforms via the device tree"). This effectively
limits the FDT to being within the first ~700MB (give or take based
on .config etc, I suppose <500MB is a pretty safe rule of thumb). Is
this expected or is it actually not intentional and the kernel should
really be using an explicit mapping here? Should I send a patch against
Documentation/arm/Booting?

Ian.

        Unable to handle kernel paging request at virtual address ffe00000
        pgd = c0004000
        [ffe00000] *pgd=af7fe821, *pte=00000000, *ppte=00000000
        Internal error: Oops: 17 [#1] ARM
        CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.0-rc1-arm-native+ #136
        task: c045e500 ti: c0454000 task.ti: c0454000
        PC is at __unflatten_device_tree+0x18/0x11c
        LR is at unflatten_device_tree+0x1c/0x34
        pc : [<c027fb38>]    lr : [<c0445bec>]    psr: a00001d3
        sp : c0455f70  ip : 80454000  fp : 00000000
        r10: c0ca10c0  r9 : 410fd0f0  r8 : c045f380
        r7 : c0434340  r6 : c045f380  r5 : ffe00000  r4 : c0434340
        r3 : d00dfeed  r2 : c0434340  r1 : c0497608  r0 : ffe00000
        Flags: NzCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
        Control: 10c5383d  Table: 80004059  DAC: 00000015
        Process swapper (pid: 0, stack limit = 0xc0454230)
        Stack: (0xc0455f70 to 0xc0456000)
        5f60:                                     ffe00000 c0497608 c0434340 c0497608
        5f80: c0434340 c044cb90 c045f380 c04649b0 c045f380 c0445bec c044b958 c0433970
        5fa0: 00000000 10c53c7d c046184c 00000001 ffffffff c044cba0 c045f4a0 80004059
        5fc0: 00000000 c04304f8 00000000 00000000 00000000 00000000 00000000 c044cba4
        5fe0: 00000000 10c53c7d c045c024 c044cba0 c045f4a0 80008070 00000000 00000000
        [<c027fb38>] (__unflatten_device_tree+0x18/0x11c) from [<c0445bec>] (unflatten_device_tree+0x1c/0x34)
        [<c0445bec>] (unflatten_device_tree+0x1c/0x34) from [<c0433970>] (setup_arch+0x5ac/0x72c)
        [<c0433970>] (setup_arch+0x5ac/0x72c) from [<c04304f8>] (start_kernel+0x68/0x2d8)
        [<c04304f8>] (start_kernel+0x68/0x2d8) from [<80008070>] (0x80008070)
        Code: e1a07002 e58d100c 0a00003a e59f30e8 (e5952000) 
        ---[ end trace 1b75b31a2719ed1c ]---
        Kernel panic - not syncing: Attempted to kill the idle task!
        




From ben.dooks at codethink.co.uk  Wed Jul 24 11:00:25 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 16:00:25 +0100
Subject: [PATCH 06/14] ARM: twd: data endian fix
In-Reply-To: <20130724144923.GO11072@mudshark.cambridge.arm.com>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-7-git-send-email-ben.dooks@codethink.co.uk>
 <20130724144923.GO11072@mudshark.cambridge.arm.com>
Message-ID: <51EFEC09.4060803@codethink.co.uk>

On 24/07/13 15:49, Will Deacon wrote:
> On Wed, Jul 24, 2013 at 11:27:54AM +0100, Ben Dooks wrote:
>> Ensure the twd driver uses the correct calls to access the hardware
>> to ensure that we do not end up with data in the wrong endian format.
>>
>> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
>
> Reviewed-by: Will Deacon<will.deacon at arm.com>
>
> There are a bunch of other __raw_* users under arch/arm/, but I suppose we
> can let other people move those over as they see fit. It wouldn't hurt to
> fix arch/arm/include/asm/{cti,hardware/coresight.h} though.

I will have a look at these.

Quite a lot of the machine specific stuff I decided to leave alone as
fixing everything was out of my remit, and is best left to a later
effort.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From lee.jones at linaro.org  Wed Jul 24 11:05:00 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Jul 2013 16:05:00 +0100
Subject: [PATCH v2 07/22] ARM: Exynos4210: Remove '0x's from Exynos4110
 DTSI file
In-Reply-To: <6156493.tCYrm4xD5A@amdc1227>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-7-git-send-email-lee.jones@linaro.org>
 <20130724123931.GL26801@laptop> <6156493.tCYrm4xD5A@amdc1227>
Message-ID: <20130724150500.GN26801@laptop>

On Wed, 24 Jul 2013, Tomasz Figa wrote:

> On Wednesday 24 of July 2013 13:39:31 Lee Jones wrote:
> > ... for the sake of consistency and assumed convention.
> > 
> > Cc: Kukjin Kim <kgene.kim at samsung.com>
> > Cc: linux-samsung-soc at vger.kernel.org
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > 
> > diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> > b/arch/arm/boot/dts/exynos4210.dtsi index b7f358a..53e2527 100644
> > --- a/arch/arm/boot/dts/exynos4210.dtsi
> > +++ b/arch/arm/boot/dts/exynos4210.dtsi
> > @@ -72,7 +72,7 @@
> >                 };
> >         };
> > 
> > -       clock: clock-controller at 0x10030000 {
> > +       clock: clock-controller at 10030000 {
> >                 compatible = "samsung,exynos4210-clock";
> >                 reg = <0x10030000 0x20000>;
> >                 #clock-cells = <1>;
> 
> Looks good to me, except the subject which is still wrong - 
> s/Exynos4110/Exynos4210/.

Ah, I get you know. My bad, will fix.

> I guess it might be fixed when applying, though.


-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From will.deacon at arm.com  Wed Jul 24 11:05:43 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 16:05:43 +0100
Subject: [PATCH 07/14] ARM: smp_scu: data endian fixes
In-Reply-To: <1374661682-9349-8-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-8-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130724150543.GP11072@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 11:27:55AM +0100, Ben Dooks wrote:
> The smp_scu driver needs to use the relaxed readl/write accessors
> to avoid any issues with the endian mode the processor core is in.
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---

Reviewed-by: Will Deacon <will.deacon at arm.com>

Will


From ben.dooks at codethink.co.uk  Wed Jul 24 11:06:58 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 16:06:58 +0100
Subject: [PATCH 06/14] ARM: twd: data endian fix
In-Reply-To: <20130724144923.GO11072@mudshark.cambridge.arm.com>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-7-git-send-email-ben.dooks@codethink.co.uk>
 <20130724144923.GO11072@mudshark.cambridge.arm.com>
Message-ID: <51EFED92.2050408@codethink.co.uk>

On 24/07/13 15:49, Will Deacon wrote:
> On Wed, Jul 24, 2013 at 11:27:54AM +0100, Ben Dooks wrote:
>> Ensure the twd driver uses the correct calls to access the hardware
>> to ensure that we do not end up with data in the wrong endian format.
>>
>> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
>
> Reviewed-by: Will Deacon<will.deacon at arm.com>
>
> There are a bunch of other __raw_* users under arch/arm/, but I suppose we
> can let other people move those over as they see fit. It wouldn't hurt to
> fix arch/arm/include/asm/{cti,hardware/coresight.h} though.

I didn't think to look for things under there.

Do people think it would be worth just changing __raw_read/__raw_write
functions to also take into account endian-ness?

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From lee.jones at linaro.org  Wed Jul 24 11:09:37 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 24 Jul 2013 16:09:37 +0100
Subject: [PATCH v3 07/22] ARM: dts: Remove '0x's from Exynos4210 DTSI file
In-Reply-To: <1374490361-25769-7-git-send-email-lee.jones@linaro.org>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-7-git-send-email-lee.jones@linaro.org>
Message-ID: <20130724150937.GO26801@laptop>

... for the sake of consistency and assumed convention.

Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>

diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index b7f358a..53e2527 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -72,7 +72,7 @@
                };
        };
 
-       clock: clock-controller at 0x10030000 {
+       clock: clock-controller at 10030000 {
                compatible = "samsung,exynos4210-clock";
                reg = <0x10030000 0x20000>;
                #clock-cells = <1>;


From magnus.damm at gmail.com  Wed Jul 24 11:15:49 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 25 Jul 2013 00:15:49 +0900
Subject: ARM CPU Hotplug breakage on mach-shmobile and KZM9D
Message-ID: <CANqRtoRx7voEVwJG8UNNy_Jiixo=uRJCvxTD0bZdzVohoryBUA@mail.gmail.com>

Hi everyone,

Bad news: CPU Hotplug on KZM9D seems broken on recent kernels.

On renesas-next-20130710 or earlier I can perform the following:

# echo 0 > /sys/devices/system/cpu/cpu1/online
CPU1: shutdown
# echo 1 > /sys/devices/system/cpu/cpu1/online
CPU1: Booted secondary processor
#

While on more recent kernels the hotplug boot fails. This may be
related to the move to v3.11-rc. The tag renesas-next-20130710
surprisingly seems to be the final kernel based on v3.10-rc before
jumping to v3.11-rc.

I wonder, do other ARM platforms have working CPU Hotplug in v3.11-rc?

Cheers,

/ magnus


From b.zolnierkie at samsung.com  Wed Jul 24 11:16:39 2013
From: b.zolnierkie at samsung.com (Bartlomiej Zolnierkiewicz)
Date: Wed, 24 Jul 2013 17:16:39 +0200
Subject: [PATCH 1/4] ARM: exynos: cpuidle: Fallback to WFI,
 when AFTR is selected
In-Reply-To: <1566146.MINY8cDBRi@flatron>
References: <1374152070-21008-1-git-send-email-daniel.lezcano@linaro.org>
 <1566146.MINY8cDBRi@flatron>
Message-ID: <2640946.7q3KRPlDWo@amdc1032>


On Wednesday, July 24, 2013 10:32:47 AM Tomasz Figa wrote:
> Hi Daniel,
> 
> On Thursday 18 of July 2013 14:54:27 Daniel Lezcano wrote:
> > When there are several cpus online, the AFTR state does not work.
> > 
> > The AFTR must be selected only when there is one cpu online.
> > 
> > The previous code was already handling this case.
> > 
> > Simplified the code, especially the init routine to have the same init
> > pattern than the other drivers.
> > 
> > Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> > ---
> >  arch/arm/mach-exynos/cpuidle.c |   13 ++-----------
> >  1 file changed, 2 insertions(+), 11 deletions(-)
> > 
> > diff --git a/arch/arm/mach-exynos/cpuidle.c
> > b/arch/arm/mach-exynos/cpuidle.c index 17a18ff..cc4b097 100644
> > --- a/arch/arm/mach-exynos/cpuidle.c
> > +++ b/arch/arm/mach-exynos/cpuidle.c
> > @@ -147,16 +147,11 @@ static int exynos4_enter_lowpower(struct
> > cpuidle_device *dev, struct cpuidle_driver *drv,
> >  				int index)
> >  {
> > -	int new_index = index;
> > -
> >  	/* This mode only can be entered when other core's are offline */
> >  	if (num_online_cpus() > 1)
> > -		new_index = drv->safe_state_index;
> > +		return drv->states[0].enter(dev, drv, 0);
> > 
> > -	if (new_index == 0)
> > -		return arm_cpuidle_simple_enter(dev, drv, new_index);
> > -	else
> > -		return exynos4_enter_core0_aftr(dev, drv, new_index);
> > +	return exynos4_enter_core0_aftr(dev, drv, index);
> >  }
> > 
> >  static void __init exynos5_core_down_clk(void)
> > @@ -209,10 +204,6 @@ static int __init exynos4_init_cpuidle(void)
> >  		device = &per_cpu(exynos4_cpuidle_device, cpu_id);
> >  		device->cpu = cpu_id;
> > 
> > -		/* Support IDLE only */
> > -		if (cpu_id != 0)
> > -			device->state_count = 1;
> > -
> 
> Are you sure that this is okay? It means, assuming that you have CPU0 
> hotplug enabled, that you can enter the AFTR state if _any_ single core 
> remains plugged in, which is technically possible, but then wake-up will 
> occur on CPU0, which is not what cpuidle and hotplug code expect.

I worry that the current code is already broken in this respect as cpuidle
core is using driver->state_count for everything except creating/destroying
sysfs state entries. This is probably something that needs to be fixed in
the cpuidle core (I suspect that governors should use device->state_count
instead of driver->state_count but it would need confirmation from someone
that knows this code better) but in the meantime it could be fixed by adding
CPU0 check to exynos4_enter_lowpower() (if the last CPU != 0 then don't go
into AFTR mode).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> P.S. Please keep linux-samsung-soc at vger.kernel.org mailing list on Cc for 
> patches related to Samsung SoCs.
> 
> Best regards,
> Tomasz



From t.figa at samsung.com  Wed Jul 24 11:24:12 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Wed, 24 Jul 2013 17:24:12 +0200
Subject: [PATCH v3 07/22] ARM: dts: Remove '0x's from Exynos4210 DTSI file
In-Reply-To: <20130724150937.GO26801@laptop>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-7-git-send-email-lee.jones@linaro.org>
 <20130724150937.GO26801@laptop>
Message-ID: <5075798.2aqxtybhC8@amdc1227>

On Wednesday 24 of July 2013 16:09:37 Lee Jones wrote:
> ... for the sake of consistency and assumed convention.
> 
> Cc: Kukjin Kim <kgene.kim at samsung.com>
> Cc: linux-samsung-soc at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> b/arch/arm/boot/dts/exynos4210.dtsi index b7f358a..53e2527 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -72,7 +72,7 @@
>                 };
>         };
> 
> -       clock: clock-controller at 0x10030000 {
> +       clock: clock-controller at 10030000 {
>                 compatible = "samsung,exynos4210-clock";
>                 reg = <0x10030000 0x20000>;
>                 #clock-cells = <1>;

Acked-by: Tomasz Figa <t.figa at samsung.com>

Best regards,
Tomasz



From ben.dooks at codethink.co.uk  Wed Jul 24 11:24:34 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 16:24:34 +0100
Subject: [PATCH 03/14] ARM: fixup_pv_table bug when CPU_ENDIAN_BE8
In-Reply-To: <20130724143335.GL11072@mudshark.cambridge.arm.com>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-4-git-send-email-ben.dooks@codethink.co.uk>
 <20130724143335.GL11072@mudshark.cambridge.arm.com>
Message-ID: <51EFF1B2.4050609@codethink.co.uk>

On 24/07/13 15:33, Will Deacon wrote:
> On Wed, Jul 24, 2013 at 11:27:51AM +0100, Ben Dooks wrote:
>> The fixup_pv_table assumes that the instructions are in the same
>> endian configuration as the data, but when the CPU is running in
>> BE8 the instructions stay in little-endian format.
>>
>> Make sure if CONFIG_CPU_ENDIAN_BE8 is set that we do all the
>> alterations to the instructions taking in to account the LDR/STR
>> will be swapping the data endian-ness.
>>
>> Since the code is only modifying a byte, we avoid dual-swapping
>> the data, and just change the bits we clear and ORR in (in the
>> case where the code is not thumb2).
>>
>> For thumb2, we add the necessary rev16 instructions to ensure that
>> the instructions are processed in the correct format, as it was
>> easier than re-writing the code to contain a mask and shift.
>>
>> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
>> ---
>>   arch/arm/kernel/head.S |    8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
>> index 8bac553..e40c0b3b 100644
>> --- a/arch/arm/kernel/head.S
>> +++ b/arch/arm/kernel/head.S
>> @@ -584,8 +584,10 @@ __fixup_a_pv_table:
>>   	b	2f
>>   1:	add     r7, r3
>>   	ldrh	ip, [r7, #2]
>> +ARM_BE8(rev16	ip, ip)
>>   	and	ip, 0x8f00
>>   	orr	ip, r6	@ mask in offset bits 31-24
>> +ARM_BE8(rev16	ip, ip)
>
> I'm not sure I follow you when you say this is easier than a mask and a
> shift? As far as I can tell, it's two extra instructions and makes the LE
> and BE cases look different.

I am not as familiar with THUMB2 as the ARM, so it was easier
to do this than see if there where any spare registers to hold the
mask and shift values, and use them.

>>   	strh	ip, [r7, #2]
>>   2:	cmp	r4, r5
>>   	ldrcc	r7, [r4], #4	@ use branch for delay slot
>> @@ -594,8 +596,14 @@ __fixup_a_pv_table:
>>   #else
>>   	b	2f
>>   1:	ldr	ip, [r7, r3]
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +	@ in BE8, we load data in BE, but instructions still in LE
>> +	bic	ip, ip, #0xff000000
>> +	orr	ip, ip, r6, lsl#24
>
> Pedantry: you could add a space between lsl and #24.
>
> Will


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From nicolas.pitre at linaro.org  Wed Jul 24 11:24:48 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 24 Jul 2013 11:24:48 -0400 (EDT)
Subject: Requirements for FDT load address on ARM
In-Reply-To: <1374677923.6623.194.camel@hastur.hellion.org.uk>
References: <1374677923.6623.194.camel@hastur.hellion.org.uk>
Message-ID: <alpine.LFD.2.03.1307241116200.15022@syhkavp.arg>

On Wed, 24 Jul 2013, Ian Campbell wrote:

> [apologies if this is a repeat, I don't see it in the archives and at
> least one CC'd recipient (Julien) didn't receive it either. Beasties in
> our email server I expect...]
> 
> Are there any requirements about where the FDT may be loaded by the
> bootloader?

It must be located where it is unlikely to be overwritten by the zImage 
decompressor relocating itself.  Same goes for the initrd.

> I'm finding that if I load it "too high" I get a fault (the specifics
> aren't that relevant but details are below).

Do you have commit 6f16f4998f98 in your kernel tree?

> FWIW with RAM from 0x8000000-0xffffffff and a kernel loaded at 
> 0x80008000 "too high" means above somewhere around 0xaf800000.

Sorry, I don't understand the above sentence.

Is RAM actually starting at 0x08000000 ?  Note that the kernel must be 
loaded in the first 128MB of RAM.

> I expect this is because the kernel doesn't use an explicit mapping of
> the fdt but expects it to be within the RAM directly mapped by the
> lowmem area (i.e. it uses phys_to_virt, since day one aka 93c02ab40ae6
> "arm/dt: probe for platforms via the device tree").

The fdt is expected to be located in lowmem.  So yes, that's actually a 
restriction.


> This effectively
> limits the FDT to being within the first ~700MB (give or take based
> on .config etc, I suppose <500MB is a pretty safe rule of thumb). Is
> this expected or is it actually not intentional and the kernel should
> really be using an explicit mapping here? Should I send a patch against
> Documentation/arm/Booting?

Yes please.


Nicolas


From olof at lixom.net  Wed Jul 24 11:27:13 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Jul 2013 08:27:13 -0700
Subject: Do we have people interested in device tree janitoring / cleanup?
Message-ID: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>

Every now and then I come across a binding that's just done Wrong(tm),
merged through a submaintainer tree and hasn't seen proper review --
if it had, it wouldn't look the way it does. It's something we're
starting to address now since there's more people stepping up to be
maintainers, but there's a backlog of bad bindings already merged.

Often they are produced by translating the platform_data structures
directly over into device-tree properties without consideration to
describing the hardware or usual conventions, using key/value pairs
instead of boolean properties, etc.

Getting involved in cleaning up these kind of bindings is a great way
to learn "the ways of device tree" for someone that has interest in
that.

Latest find in this area is the Maxim 8925 bindings, that I came
across since they caused a compile warning on some defconfig. I'll
post a patch to address the warning but if someone else feels like
fixing the bindings on top of it that would be appreciated!


-Olof


From will.deacon at arm.com  Wed Jul 24 11:28:37 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 16:28:37 +0100
Subject: [PATCH 11/14] ARM: alignment: correctly decode instructions in
 BE8 mode.
In-Reply-To: <1374661682-9349-12-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-12-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130724152837.GQ11072@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 11:27:59AM +0100, Ben Dooks wrote:
> If we are in BE8 mode, we must deal with the instruction stream being
> in LE order when data is being loaded in BE order. Ensure the data is
> swapped before processing to avoid thre following:
> 
> Change to using <asm/opcodes.h> to provide the necessary conversion
> functions to change the byte ordering.
> 
> Alignment trap: not handling instruction 030091e8 at [<80333e8c>]
> Unhandled fault: alignment exception (0x001) at 0xbfa09567
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---
>  arch/arm/mm/alignment.c |    8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
> index 6f4585b..f38145a 100644
> --- a/arch/arm/mm/alignment.c
> +++ b/arch/arm/mm/alignment.c
> @@ -25,6 +25,7 @@
>  #include <asm/cp15.h>
>  #include <asm/system_info.h>
>  #include <asm/unaligned.h>
> +#include <asm/opcodes.h>
>  
>  #include "fault.h"
>  
> @@ -762,21 +763,24 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
>  	if (thumb_mode(regs)) {
>  		u16 *ptr = (u16 *)(instrptr & ~1);
>  		fault = probe_kernel_address(ptr, tinstr);
> +		tinstr = __mem_to_opcode_thumb16(tinstr);
>  		if (!fault) {
>  			if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
>  			    IS_T32(tinstr)) {
>  				/* Thumb-2 32-bit */
>  				u16 tinst2 = 0;
>  				fault = probe_kernel_address(ptr + 1, tinst2);
> +				tinst2 = __mem_to_opcode_thumb16(tinst2);
>  				instr = (tinstr << 16) | tinst2;

Took me a while to convince myself, but looks right to me:

Reviewed-by: Will Deacon <will.deacon at arm.com>

Will


From santosh.shilimkar at ti.com  Wed Jul 24 11:40:33 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 24 Jul 2013 11:40:33 -0400
Subject: OMAP4430 SDP boot issues.. (Was Re: OMAP2430 SDP boot broken after
 Linus' rmk merge)
In-Reply-To: <20130724145237.GB21614@n2100.arm.linux.org.uk>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724145237.GB21614@n2100.arm.linux.org.uk>
Message-ID: <51EFF571.3070106@ti.com>

On Wednesday 24 July 2013 10:52 AM, Russell King - ARM Linux wrote:
> On Wed, Jul 24, 2013 at 10:17:01AM -0400, Santosh Shilimkar wrote:
>> On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote:
>>> On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote:
>>>> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote:

[..]

>>>>> I don't have a 4430SDP, so you might consider touching base with rmk for 
>>>>> that one.
>>>>
>>>> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see
>>>> the below errors. (I am using the mainline bootloaders which do not lock any
>>>> additional DPLLs like USB)
>>>
>>> Any update on this? If it's an issue introduced by architectural changes,
>>> I'd really like to bisect it down but I don't have a board.
>>>
>> >From the other thread, RMK did manage to get the board booting finally
>> (uImage related issues, low level debug problem) but with DT only supported
>> build, the audio and DSS was not at same state as before(non-DT build).
>> And then Tony pointed the issues to Peter and Tomy to address it further.
>>
>> Russell,
>> Is above right or I am missing something ?
> 
> Will is referring to the 2430 issues I think; the original topic of this
> thread.
>
We crossed the emails. Am just renaming the thread since below summary is
still important for OMAP4430SDP.
 
> I've not enabled the 4430 again in the build system because I see no point
> to it - it can't find its rootfs because the device numbering for the MMC/SD
> cards has reversed itself.  Not only does that need the kernel command line
> changed, but it also needs fixing in the fstab on the SD card rootfs, and
> quite frankly I really can't be bothered at the moment with this kind of
> pointless boot breaking churn.
>
The MMC slot change has also troubled us in past in downstream kernel. Am
looping Balaji to see if he can fix it to restore the original ordering.
 
> I also continue to be disappointed by the lack of things working on the
> 4430 - it's been a number of years now and _still_ the on-board LCDs do
> not work.  People have tried to blame that on hardware faults and the
> like, but they're just being idiotic when they say stuff like that.  It
> can't be hardware faults when the kernel supplied with the board is able
> to make them work to the extent that userspace can play back video on all
> three output devices simultaneously, without hiccup or any imperfection.
> I don't know whether it's just that the backlight support isn't working
> or what - because any information on the 4430 seems to be a tightly
> controlled secret that only a few select people are permitted to know
> about.  As far as I'm concerned, much of the hardware is a black box to
> me.
> 
On the display related issues, Tomi and Archit have been sorting out
issue but am not sure about the current state. If the pre-built binaries
video playback works means your hardware seems to be fine.

> And yes, my 4430 has the projector module on it.  Never ever seen that
> work, and no idea how to make it work because there's no information
> available on the hardware.
> 
I think you mean the Pico DLP module. There was a downstream driver but
am not sure about the state. Archit, Tomi should be able to comment.

> It's a bit like the useless 3430LDP - though there's information available
> there's no way to work out which of the many different designs of 3430LDP
> the one I have ties up with, and I'm pretty sure that all the published
> revisions of the circuits for the 3430LDP do not match the version I have
> here - which means when things go wrong, there's no way for me to look
> at stuff.
> 
> And no, I don't want another Beagle board or Panda board or whatever, I
> have those (I think I have one of each), and they've never been powered up
> because they have no ethernet on them, and I have no USB to ethernet still,
> partly because I don't really do USB here *at* *all*, so I don't know what
> works well and what doesn't with Linux.  Even if I did provide them with a
> USB ethernet, I doubt they'd be able to boot a kernel via the network.
>
We discussed the LDP issue in past. That board is almost dead since almost
no one from TI is using/having it anymore.
 
> My experience of USB is hellishly poor - I have an icybox eSATA enclosure
> which also provides USB.  The USB interface on that regularly drops out
> with errors, timeouts, and even isn't recognised on many occasions.  I
> see slow serial comms with USB serial devices on platforms like the
> 4430SDP and Dove Cubox - the speed is very much like a 4800baud modem, even
> though the serial runs at 115200 baud.  No, don't even _think_ about blaming
> the host, because this happens whether it be a Thinkpad, or the USB hosts
> in a Thecus N2100.
> 
> I can believe why this all happens, when you see USB interrupts taking
> upwards of 3ms to complete:
> 
> Longest time: 3247506ns
> Longest irq: 24
> Longest handler: usb_hcd_irq+0x0/0x68
> 
> is it hardly surprising that USB is soo crap?  And the above 3ms is just
> for handling a USB keyboard - what takes 3ms over servicing a USB keyboard?
> I mean, what crap USB really is when it behaves like that... and is it
> no wonder I hate the bloody thing.
> 
Felipe might be able to comment better on the above USB topic.

Regards,
Santosh




From olof at lixom.net  Wed Jul 24 11:42:27 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Jul 2013 08:42:27 -0700
Subject: [PATCH] mfd: max8925: fix dt code for backlight
Message-ID: <1374680547-5336-1-git-send-email-olof@lixom.net>

The device-tree enablement for max8925 has several problems, but besides
the bindings being wrong (and not having seen review) there's also some
bad coding practices on how to fill in the platform_data from device tree.

I came across this since it causes a warning when compiling
mmp2_defconfig, and instead of doing the minimal fix to silence the
warning, I restructured the code a bit.

This silences the warning:
drivers/video/backlight/max8925_bl.c: In function 'max8925_backlight_probe':
drivers/video/backlight/max8925_bl.c:177:3: warning: statement with no effect [-Wunused-value]

Note that the bindings themselves need to be revisited too, but that will
affect more than just the backlight driver and is best done separately;
this just fixes the bad code for the backlight driver.

Signed-off-by: Olof Johansson <olof at lixom.net>
---

Richard, Jingoo, this would be good to see go into 3.11 if you're
comfortable with it.


-Olof

 drivers/video/backlight/max8925_bl.c |   41 +++++++++++++++++-----------------
 1 file changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/video/backlight/max8925_bl.c b/drivers/video/backlight/max8925_bl.c
index 5ca11b0..886e797 100644
--- a/drivers/video/backlight/max8925_bl.c
+++ b/drivers/video/backlight/max8925_bl.c
@@ -101,33 +101,37 @@ static const struct backlight_ops max8925_backlight_ops = {
 	.get_brightness	= max8925_backlight_get_brightness,
 };
 
-#ifdef CONFIG_OF
-static int max8925_backlight_dt_init(struct platform_device *pdev,
-			      struct max8925_backlight_pdata *pdata)
+static void max8925_backlight_dt_init(struct platform_device *pdev)
 {
 	struct device_node *nproot = pdev->dev.parent->of_node, *np;
-	int dual_string;
+	struct max8925_backlight_pdata *pdata;
+	u32 val;
+
+	if (!nproot || !IS_ENABLED(CONFIG_OF))
+		return;
+
+	pdata = devm_kzalloc(&pdev->dev,
+			     sizeof(struct max8925_backlight_pdata),
+			     GFP_KERNEL);
+	if (!pdata)
+		return;
 
-	if (!nproot)
-		return -ENODEV;
 	np = of_find_node_by_name(nproot, "backlight");
 	if (!np) {
 		dev_err(&pdev->dev, "failed to find backlight node\n");
-		return -ENODEV;
+		return;
 	}
 
-	of_property_read_u32(np, "maxim,max8925-dual-string", &dual_string);
-	pdata->dual_string = dual_string;
-	return 0;
+	if (!of_property_read_u32(np, "maxim,max8925-dual-string", &val))
+		pdata->dual_string = val;
+
+	pdev->dev.platform_data = pdata;
 }
-#else
-#define max8925_backlight_dt_init(x, y)	(-1)
-#endif
 
 static int max8925_backlight_probe(struct platform_device *pdev)
 {
 	struct max8925_chip *chip = dev_get_drvdata(pdev->dev.parent);
-	struct max8925_backlight_pdata *pdata = pdev->dev.platform_data;
+	struct max8925_backlight_pdata *pdata;
 	struct max8925_backlight_data *data;
 	struct backlight_device *bl;
 	struct backlight_properties props;
@@ -170,13 +174,10 @@ static int max8925_backlight_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, bl);
 
 	value = 0;
-	if (pdev->dev.parent->of_node && !pdata) {
-		pdata = devm_kzalloc(&pdev->dev,
-				     sizeof(struct max8925_backlight_pdata),
-				     GFP_KERNEL);
-		max8925_backlight_dt_init(pdev, pdata);
-	}
+	if (!pdev->dev.platform_data)
+		max8925_backlight_dt_init(pdev);
 
+	pdata = pdev->dev.platform_data;
 	if (pdata) {
 		if (pdata->lxw_scl)
 			value |= (1 << 7);
-- 
1.7.10.4



From jason at lakedaemon.net  Wed Jul 24 11:52:18 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 24 Jul 2013 11:52:18 -0400
Subject: [PATCH v8 00/28] MBus DT binding for Armada 370/XP and Kirkwood
In-Reply-To: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374586292-4941-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130724155218.GG19736@titan.lakedaemon.net>

Ezequiel,

fyi: devicetree bindings have a new mailinglist since Grant stepped down,
devicetree at vger.kernel.org.

thx,

Jason.

On Tue, Jul 23, 2013 at 10:31:04AM -0300, Ezequiel Garcia wrote:
> After Andrew Lunn reported [1] this work need to take account of Kirkwood
> to prevent breaking PCIe on such platform, here's a new version adding
> MBus DT binding for Kirkwood and in particular using it to declare PCIe
> properly.
> 
> I've chosen a PCIe memory and I/O aperture size following the legacy PCIe
> initialization in implemented arch/arm/mach-kirkwood/pcie.c.
> Namely 0xe0000000-0xf0000000 for memory space, and 0xf200000-0xf2100000 for
> I/O space. Keep in mind, this is just a particular choice and can be overriden
> in per-board DT files.
> 
> This patchset is tested on several Armada 370/XP and on
> Plathome Openblocks A6 Kirkwood board.
> 
> Due to lack of more Kirkwood boards, I'd like to have Tested-by's for
> legacy (non-DT) initialized Kirkwood boards, and PCIe-capable Kirkwood boards.
> 
> To make it easier for these testings, there's a public branch:
> 
>   https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v8
> 
> Last but not least, I'd like to have formal Acked-by from DT maintainers
> to the DT binding itself (notice this is independent of the recently
> found kirkwood breakage).
> 
> This is based on v3.11-rc2.
> 
> [1] http://www.mail-archive.com/devicetree-discuss at lists.ozlabs.org/msg37059.html
> 
> Changelog
> ---------
> 
> v8:
> 
>  * Introduce Kirkwood MBus DT binding and use it to relocate
>    the PCIe nodes *only*.
> 
>  * Allow MBus to initialize when the node has no ranges property.
> 
>  * Add a sanity check for PCIe port base address to prevent a kernel
>    panic when this address has not been obtained. Instead of panic,
>    the PCIe won't work in such cases.
> 
> v7:
> 
>  * Add two optional properties pcie-{mem,io}-aperture to the MBus node
>    defining the PCIe mem and IO region apertures.
> 
>  * Encode the PCIe port in the second cell of the ranges entries, using
>    the PCIe slot; and remove such encoding from the first cell, since it
>    was violating the specification.
> 
>    Quoting Jason Gunthorpe:
>    """ [...] the OF spec says that the phys.hi fields of the child address
>    spaces in the "ranges" property for PCI does not contain the same
>    information as "reg" property entries within PCI nodes. The only information
>    that is present in "ranges" phys.hi entries are the non-relocatable,
>    prefetchable and the PCI address space bits for which the entry applies.
>    I.e., only the n, p and ss bits are present; the bbbbbbbb, ddddd, fff and
>    rrrrrrrr fields are 0."""
> 
> v6:
> 
>  * Change the PCIe ranges translations encoding, removing the big fake
>    window encoded as MBUS_ID(0xf0, 0x02) by an array of entries representing
>    the PCIe real windows with full 4 GiB size.
> 
>  * The corresponding PCIe port is selected by encoding the bus in the first cell
>    of the PCIe controller node ranges entry.
> 
>  * Remove the name-based MBus window allocation API, replacing it by an
>    ID-based API.
> 
> v5:
> 
>  * Add a required a 'controller' property to specify a phandle containing
>    the MBus controller MMIO registers.
> 
> v4:
> 
>  * Fixed the pcie-controller to mbus address space translations, to match
>    a 1:1 mapping between the PCI and CPU busses.
> 
>  * Fixed the binding documentation with suggestions from Arnd Bergmann.
> 
>  * Added a BootROM sanity check on AXP SMP initialization, as suggested
>    by Jason Gunthorpe. This also implied changing slightly the bootrom
>    node.
> 
>  * Changed the first cell format for the MBus address space.
> 
> v3:
> 
>  * Replaced the PCIe mapping with 0xffff0002, to avoid using a representation
>    that might correspond to a possible window id.
> 
>  * Remove every mbus-node 'ranges' property from the dtsi files. Having them
>    on the per-board dts files only makes maintaince less painful.
> 
>  * Declare children window size, in the children 'ranges' property, as large
>    as possible (4 GiB size) and move the property to the dtsi files.
>    The per-board dts, does not need to declare that property now.
> 
>  * The MBus driver now creates the decoding window using the base address and
>    size specified in the mbus-node, instead of using the children entries.
> 
> v2:
> 
>  * Use the preprocessor on the DT and define a macro for the window ID.
> 
>  * Changed the way the address spaces were declared: the window's base
>    addresses are only present in the mbus-node ranges property.
>    This makes sense since that information belongs only to the MBus
>    address space.
> 
>  * Drop the ranges dynamic update, since now the DT translations are complete.
> 
>  * Replaced the internal register first cell mapping with 0xffff0001, to avoid
>    clashing when using 0x00000000.
> 
>  * Replaced the PCIe mapping with 0xffff0000.
> 
> v1:
> 
>   * Initial proposal
> 
> Example
> -------
> 
> Here's an example showing how the MBus DT binding looks now:
> 
> soc {
> 	compatible = "marvell,armadaxp-mbus", "simple-bus";
> 	controller = <&mbusc>;
> 	pcie-mem-aperture = <0xe0000000 0x8000000>;
> 	pcie-io-aperture  = <0xe8000000 0x100000>;
> 
> 	ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
> 		  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
> 		  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
> 
> 	bootrom {
> 		compatible = "marvell,bootrom";
> 		reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
> 	};
> 
> 	devbus-bootcs {
> 		status = "okay";
> 		ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;
> 
> 		/* NOR */
> 		nor {
> 			compatible = "cfi-flash";
> 			reg = <0 0x8000000>;
> 			bank-width = <2>;
> 		};
> 	};
> 
> 	pcie-controller {
> 		compatible = "marvell,armada-xp-pcie";
> 		status = "okay";
> 		device_type = "pci";
> 		#address-cells = <3>;
> 		#size-cells = <2>;
> 
> 		ranges =
> 			<0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
> 			0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
> 			0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
> 			0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
> 			0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
> 			0x82000000 0x1 0       MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
> 			0x81000000 0x1 0       MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */
> 			0x82000000 0x2 0       MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
> 			0x81000000 0x2 0       MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */>;
> 
> 
> 		pcie at 1,0 {
> 			device_type = "pci";
> 			assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
> 			reg = <0x0800 0 0 0 0>;
> 			#address-cells = <3>;
> 			#size-cells = <2>;
> 			#interrupt-cells = <1>;
> 			ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
> 				  0x81000000 0 0 0x81000000 0x1 0 1 0>;
> 			interrupt-map-mask = <0 0 0 0>;
> 			interrupt-map = <0 0 0 0 &mpic 58>;
> 			marvell,pcie-port = <0>;
> 			marvell,pcie-lane = <0>;
> 			clocks = <&gateclk 5>;
> 			status = "disabled";
> 		};
> 
> 		pcie at 2,0 {
> 			device_type = "pci";
> 			assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
> 			reg = <0x1000 0 0 0 0>;
> 			#address-cells = <3>;
> 			#size-cells = <2>;
> 			#interrupt-cells = <1>;
> 			ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
> 				  0x81000000 0 0 0x81000000 0x2 0 1 0>;
> 			interrupt-map-mask = <0 0 0 0>;
> 			interrupt-map = <0 0 0 0 &mpic 62>;
> 			marvell,pcie-port = <1>;
> 			marvell,pcie-lane = <0>;
> 			clocks = <&gateclk 9>;
> 			status = "disabled";
> 		};
> 	};
> 
> 	internal-regs {
> 		compatible = "simple-bus";
> 		#address-cells = <1>;
> 		#size-cells = <1>;
> 		ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
> 
> 		mbusc: mbus-controller at 20000 {
> 			reg = <0x20000 0x100>, <0x20180 0x20>;
> 		};
> 
> 		interrupt-controller at 20000 {
> 			reg = <0x20a00 0x2d0>, <0x21070 0x58>;
> 		};
> 	};
> };
> 
> 
> Ezequiel Garcia (18):
>   memory: mvebu-devbus: Remove address decoding window workaround
>   bus: mvebu-mbus: Factor out initialization details
>   bus: mvebu-mbus: Introduce device tree binding
>   bus: mvebu-mbus: Add static window allocation to the DT binding
>   bus: mvebu-mbus: Add new API for the PCIe memory and IO aperture
>   PCI: mvebu: Check valid base address before port setup
>   ARM: mvebu: Remove the harcoded BootROM window allocation
>   ARM: mvebu: Initialize MBus using the DT binding
>   ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
>   ARM: mvebu: Add MBus to Armada 370/XP device tree
>   ARM: mvebu: Add BootROM to Armada 370/XP device tree
>   ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
>   ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes
>   ARM: kirkwood: Split DT and legacy MBus initialization
>   ARM: kirkwood: Use the preprocessor on device tree files
>   ARM: kirkwood: Introduce MBus DT node
>   ARM: kirkwood: Introduce MBUS_ID
>   ARM: kirkwood: Relocate PCIe device tree nodes
> 
> Thomas Petazzoni (10):
>   bus: mvebu-mbus: Add new API for window creation
>   ARM: kirkwood: Move to ID based MBus window creation
>   ARM: mv78xx0: Move to ID based window creation
>   ARM: orion5x: Move to ID based window creation
>   ARM: dove: Move to ID based window creation
>   PCI: mvebu: Adapt to the new device tree layout
>   bus: mvebu-mbus: Remove the no longer used name-based API
>   bus: mvebu-mbus: Remove name -> target, attribute mapping tables
>   bus: mvebu-mbus: Update main description
>   bus: mvebu-mbus: Factorize Armada 370/XP data structures
> 
>  .../devicetree/bindings/bus/mvebu-mbus.txt         | 267 +++++++++++++
>  .../devicetree/bindings/pci/mvebu-pci.txt          | 145 +++++--
>  arch/arm/boot/dts/armada-370-db.dts                |   5 +-
>  arch/arm/boot/dts/armada-370-mirabox.dts           |  37 +-
>  arch/arm/boot/dts/armada-370-rd.dts                |   5 +-
>  arch/arm/boot/dts/armada-370-xp.dtsi               | 111 +++---
>  arch/arm/boot/dts/armada-370.dtsi                  | 112 +++---
>  arch/arm/boot/dts/armada-xp-db.dts                 | 131 +++---
>  arch/arm/boot/dts/armada-xp-gp.dts                 | 107 +++--
>  arch/arm/boot/dts/armada-xp-mv78230.dtsi           | 222 ++++++-----
>  arch/arm/boot/dts/armada-xp-mv78260.dtsi           | 263 ++++++------
>  arch/arm/boot/dts/armada-xp-mv78460.dtsi           | 411 ++++++++++---------
>  arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |  88 ++--
>  arch/arm/boot/dts/armada-xp.dtsi                   |   9 +-
>  arch/arm/boot/dts/kirkwood-6281.dtsi               |  66 +--
>  arch/arm/boot/dts/kirkwood-6282.dtsi               | 102 ++---
>  arch/arm/boot/dts/kirkwood-cloudbox.dts            |   4 +-
>  arch/arm/boot/dts/kirkwood-db-88f6281.dts          |   7 +-
>  arch/arm/boot/dts/kirkwood-db-88f6282.dts          |   7 +-
>  arch/arm/boot/dts/kirkwood-db.dtsi                 |  10 +-
>  arch/arm/boot/dts/kirkwood-dns320.dts              |   2 +-
>  arch/arm/boot/dts/kirkwood-dns325.dts              |   2 +-
>  arch/arm/boot/dts/kirkwood-dnskw.dtsi              |   4 +-
>  arch/arm/boot/dts/kirkwood-dockstar.dts            |   4 +-
>  arch/arm/boot/dts/kirkwood-dreamplug.dts           |   4 +-
>  arch/arm/boot/dts/kirkwood-goflexnet.dts           |   4 +-
>  .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |   4 +-
>  arch/arm/boot/dts/kirkwood-ib62x0.dts              |   4 +-
>  arch/arm/boot/dts/kirkwood-iconnect.dts            |  23 +-
>  arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts      |   4 +-
>  arch/arm/boot/dts/kirkwood-is2.dts                 |   2 +-
>  arch/arm/boot/dts/kirkwood-km_kirkwood.dts         |   4 +-
>  arch/arm/boot/dts/kirkwood-lschlv2.dts             |   2 +-
>  arch/arm/boot/dts/kirkwood-lsxhl.dts               |   2 +-
>  arch/arm/boot/dts/kirkwood-lsxl.dtsi               |   4 +-
>  arch/arm/boot/dts/kirkwood-mplcec4.dts             |  23 +-
>  .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  |  23 +-
>  arch/arm/boot/dts/kirkwood-ns2-common.dtsi         |   4 +-
>  arch/arm/boot/dts/kirkwood-ns2.dts                 |   2 +-
>  arch/arm/boot/dts/kirkwood-ns2lite.dts             |   2 +-
>  arch/arm/boot/dts/kirkwood-ns2max.dts              |   2 +-
>  arch/arm/boot/dts/kirkwood-ns2mini.dts             |   2 +-
>  arch/arm/boot/dts/kirkwood-nsa310.dts              |  23 +-
>  arch/arm/boot/dts/kirkwood-openblocks_a6.dts       |   4 +-
>  arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi  |   4 +-
>  arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts    |   2 +-
>  arch/arm/boot/dts/kirkwood-sheevaplug.dts          |   2 +-
>  arch/arm/boot/dts/kirkwood-topkick.dts             |   4 +-
>  arch/arm/boot/dts/kirkwood-ts219-6281.dts          |   6 +-
>  arch/arm/boot/dts/kirkwood-ts219-6282.dts          |  25 +-
>  arch/arm/boot/dts/kirkwood-ts219.dtsi              |  17 +-
>  arch/arm/boot/dts/kirkwood.dtsi                    |  17 +-
>  arch/arm/mach-dove/common.c                        |  68 ++--
>  arch/arm/mach-kirkwood/board-dt.c                  |   1 +
>  arch/arm/mach-kirkwood/common.c                    |  26 +-
>  arch/arm/mach-kirkwood/pcie.c                      |  40 +-
>  arch/arm/mach-mv78xx0/pcie.c                       |  23 +-
>  arch/arm/mach-mvebu/armada-370-xp.c                |  34 +-
>  arch/arm/mach-mvebu/platsmp.c                      |  25 +-
>  arch/arm/mach-orion5x/common.c                     |  36 +-
>  arch/arm/mach-orion5x/common.h                     |  17 +
>  arch/arm/mach-orion5x/d2net-setup.c                |   6 +-
>  arch/arm/mach-orion5x/db88f5281-setup.c            |  24 +-
>  arch/arm/mach-orion5x/dns323-setup.c               |   6 +-
>  arch/arm/mach-orion5x/edmini_v2-setup.c            |   6 +-
>  arch/arm/mach-orion5x/kurobox_pro-setup.c          |  12 +-
>  arch/arm/mach-orion5x/ls-chl-setup.c               |   6 +-
>  arch/arm/mach-orion5x/ls_hgl-setup.c               |   6 +-
>  arch/arm/mach-orion5x/lsmini-setup.c               |   6 +-
>  arch/arm/mach-orion5x/mss2-setup.c                 |   6 +-
>  arch/arm/mach-orion5x/mv2120-setup.c               |   6 +-
>  arch/arm/mach-orion5x/net2big-setup.c              |   6 +-
>  arch/arm/mach-orion5x/pci.c                        |   9 +-
>  arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c       |   6 +-
>  arch/arm/mach-orion5x/rd88f5181l-ge-setup.c        |   6 +-
>  arch/arm/mach-orion5x/rd88f5182-setup.c            |  13 +-
>  arch/arm/mach-orion5x/terastation_pro2-setup.c     |   6 +-
>  arch/arm/mach-orion5x/ts209-setup.c                |   6 +-
>  arch/arm/mach-orion5x/ts409-setup.c                |   6 +-
>  arch/arm/mach-orion5x/wnr854t-setup.c              |   6 +-
>  arch/arm/mach-orion5x/wrt350n-v2-setup.c           |   6 +-
>  drivers/bus/mvebu-mbus.c                           | 441 ++++++++++++---------
>  drivers/memory/mvebu-devbus.c                      |  64 +--
>  drivers/pci/host/pci-mvebu.c                       | 115 ++++--
>  include/linux/mbus.h                               |  16 +-
>  85 files changed, 2021 insertions(+), 1379 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt
> 
> -- 
> 1.8.1.5
> 


From davidb at codeaurora.org  Wed Jul 24 11:55:05 2013
From: davidb at codeaurora.org (David Brown)
Date: Wed, 24 Jul 2013 08:55:05 -0700
Subject: [PATCH 1/7] usb: phy: msm: Move mach dependent code to platform
 data
In-Reply-To: <1372087664-26396-2-git-send-email-iivanov@mm-sol.com>
References: <1372087664-26396-1-git-send-email-iivanov@mm-sol.com>
 <1372087664-26396-2-git-send-email-iivanov@mm-sol.com>
Message-ID: <20130724155505.GA26371@codeaurora.org>

On Mon, Jun 24, 2013 at 06:27:38PM +0300, Ivan T. Ivanov wrote:
>From: "Ivan T. Ivanov" <iivanov at mm-sol.com>
>
>This patch fix compilation error and is an intermediate step
>before the addition of DeviceTree support for newer targets.
>Fix suggested here: https://lkml.org/lkml/2013/6/19/381
>
>Cc: David Brown <davidb at codeaurora.org>
>Cc: Daniel Walker <dwalker at fifo99.com>
>Cc: Bryan Huntsman <bryanh at codeaurora.org>
>Cc: Russell King <linux at arm.linux.org.uk>
>Cc: Felipe Balbi <balbi at ti.com>
>Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
>Cc: Stephen Boyd <sboyd at codeaurora.org>
>Cc: linux-arm-kernel at lists.infradead.org
>Cc: linux-kernel at vger.kernel.org
>
>Signed-off-by: Ivan T. Ivanov <iivanov at mm-sol.com>
>---
> arch/arm/mach-msm/board-msm7x30.c |   35 +++++++++++++++++++++++
> arch/arm/mach-msm/board-qsd8x50.c |   34 +++++++++++++++++++++++
> drivers/usb/phy/phy-msm-usb.c     |   55 ++++++++++---------------------------
> include/linux/usb/msm_hsusb.h     |    2 ++
> 4 files changed, 85 insertions(+), 41 deletions(-)

Acked-by: David Brown <davidb at codeaurora.org>

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From ben.dooks at codethink.co.uk  Wed Jul 24 11:55:05 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 16:55:05 +0100
Subject: [PATCH 04/14] ARM: set BE8 if LE in head code
In-Reply-To: <20130724144118.GM11072@mudshark.cambridge.arm.com>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-5-git-send-email-ben.dooks@codethink.co.uk>
 <20130724144118.GM11072@mudshark.cambridge.arm.com>
Message-ID: <51EFF8D9.6010802@codethink.co.uk>

On 24/07/13 15:41, Will Deacon wrote:
> On Wed, Jul 24, 2013 at 11:27:52AM +0100, Ben Dooks wrote:
>> If we are booting in LE and compiled for BE8, then add code to
>> set the state to bE8. Since the instruction stream is always LE,
>> we do not need to do anything special to the instruction.
>>
>> Also ensure that the secondary processors are started in the same mode.
>>
>> Note, we do add about 20 bytes to the kernel image, but it seems easier
>> to do this than adding another configuration to change.
>>
>> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
>> ---
>>   arch/arm/boot/compressed/head.S |    1 +
>>   arch/arm/kernel/head.S          |    4 ++++
>>   arch/arm/kernel/sleep.S         |    1 +
>>   3 files changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>> index 4eb8364..4d83bfd 100644
>> --- a/arch/arm/boot/compressed/head.S
>> +++ b/arch/arm/boot/compressed/head.S
>> @@ -135,6 +135,7 @@ start:
>>   		.word	_edata			@ zImage end address
>>    THUMB(		.thumb			)
>>   1:
>> + ARM_BE8(	setend	be )			@ go BE8 if LE, no-op if BE8
 >
> I find the comment here slightly confusing as it makes it sound like the
> macro expands to nothing if we're BE8 (which is clearly not the case).

I've changed it to "go BE8 if compiled for BE8"

>>   		mrs	r9, cpsr
>>   #ifdef CONFIG_ARM_VIRT_EXT
>>   		bl	__hyp_stub_install	@ get into SVC mode, reversibly
>> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
>> index e40c0b3b..706c441 100644
>> --- a/arch/arm/kernel/head.S
>> +++ b/arch/arm/kernel/head.S
>> @@ -77,6 +77,7 @@
>>
>>   	__HEAD
>>   ENTRY(stext)
>> + ARM_BE8(setend	be )			@ ensure we are in BE8 mode
>
> Alignment issue here -- please try to align the instruction with the
> instructions below (it's awkward to read with all the brackets).

If I move it one to the left, then it gets coloured blue by
my editor, as it is the first thing on the line like the
ENTRY() macro.

>>
>>    THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is always entered in ARM.
>>    THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
>> @@ -351,6 +352,9 @@ ENTRY(secondary_startup)
>>   	 * the processor type - there is no need to check the machine type
>>   	 * as it has already been validated by the primary processor.
>>   	 */
>> +
>> + ARM_BE8(setend	be)				@ if system starts LE, go BE8
>> +
>>   #ifdef CONFIG_ARM_VIRT_EXT
>>   	bl	__hyp_stub_install_secondary
>>   #endif
>> diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
>> index 987dcf3..954c28a 100644
>> --- a/arch/arm/kernel/sleep.S
>> +++ b/arch/arm/kernel/sleep.S
>> @@ -81,6 +81,7 @@ ENDPROC(cpu_resume_after_mmu)
>>   	.data
>>   	.align
>>   ENTRY(cpu_resume)
>> +ARM_BE8(setend be)			@ ensure we are in BE mode
>
> Any reason to have three different comments for the same thing? I think you
> probably just need to comment the one in head.S.

I've changed the comments to match in.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From stern at rowland.harvard.edu  Wed Jul 24 11:58:29 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Wed, 24 Jul 2013 11:58:29 -0400 (EDT)
Subject: [PATCH 2/6] USB: OHCI: make ohci-omap a separate driver
In-Reply-To: <CAJFYCKGEKNLmy4o6KRMmxjuSYMXaXdbNxodcyXtOSReONa0hLg@mail.gmail.com>
Message-ID: <Pine.LNX.4.44L0.1307241157230.1313-100000@iolanthe.rowland.org>

On Wed, 24 Jul 2013, Manjunath Goudar wrote:

> > I suspect there's a mistake here, and the omap_ohci_clock_power() call
> > perhaps should be moved after the "err3:" label.  But that mistake (if
> > it is a mistake) was present in the original code, and this patch
> > shouldn't change it.
> >
> 
>  Before omap_ohci_clock_power(0) was calling dependence on host_enabled
>  value was set or not. We rid the of host_enabled.

I know.  I was the person who told you to do that.

> Now my approach is as below, to avoid the omap_ohci_clock_power(0) issue:
> 
>     retval = usb_add_hcd(hcd, irq, 0);
>  +       if (retval == 0)
>     +            return retval;
> 
> /* I thought  here clock disable is required before any of
> errX statement execute
>     please comment on this*/
>    + omap_ohci_clock_power(0);
> err3:
>        iounmap(hcd->regs);
> 
> What about your suggestion?

I don't know.  You should ask the person who wrote this driver 
originally.

Alan Stern



From ben.dooks at codethink.co.uk  Wed Jul 24 12:05:39 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 24 Jul 2013 17:05:39 +0100
Subject: [repost] ARM big-endian support
In-Reply-To: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <51EFFB53.5060003@codethink.co.uk>

On 24/07/13 11:27, Ben Dooks wrote:
> A repost (as requested) of the current big-endian core work for review.

New branches at git.baserock.org/delta/linux.git
	311/be/atags-v4
  	311/be/core-v4

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From nm at ti.com  Wed Jul 24 12:08:01 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 24 Jul 2013 11:08:01 -0500
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <51ED5C66.1010407@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <51E83A4F.5080904@ti.com>
 <CACRpkdY3nQaWimTwB-Zt-8+Q_KZr8a0rpB1SUQq=AuoG4bAYnQ@mail.gmail.com>
 <51ED2385.60108@ti.com> <51ED5C66.1010407@ti.com>
Message-ID: <51EFFBE1.4090505@ti.com>

On 07/22/2013 11:23 AM, Santosh Shilimkar wrote:
> To summaries it again, what I understood from Sricharan's proposal,
>
> - Setup all the routing at cross-bar probe so that kernel continue to
> work like normal IRQ controller with cross-bar scope vanishes once
> the routing is done. Cross-bar does this before any of the devices
> are created.
> - Something similar needs to happen for DMA lines as well or for any
> other event routing in future.
> - Cross-bar callbacks for device drivers for error paths.
> (Sricharan, you have to drop these because it doesn't bring any
> functionality and rather can create a side effects of drivers
> getting polluted.)
Ack.

>
> The concern raised on above was instead of fixing the routing at DT
> statically, doing at the driver probes where the loop-up for IRQ or DMA
> lines should happen in background transparently on drivers call of
> request_irq/request_dma_channel etc with cross-bar number as
> an input to it. Though it will be nice to have
> such feature, it doesn't bring anything special and brings the
> notion of these APIs which expect that you know what IRQ and DMA
> lines you want while calling these.
Unfortunately, we do have a constraint without allocating dynamic IRQs - 
what IP instances should hwmod and dts contain?

If we go with current series of patches[1] [2] for DRA7 dts which 
assumes default mapping, hence, uart7-10, GPTimers12-16 dont have 
default irq - hence they dont exist in dts etc.

How would we like to support those with pinctrl approach?

>
> Note that mux inputs are pretty much fixed. Its his connection
> to IRQ controller or DMA controller is what needs to be programmed.
> So scope is pretty much limited. I felt this requirement is pretty
> similar to pin-mux and hence thought of it as a viable option.
>
> Having said all of above, if there is a better alternative than
> enhanced pin-mux we surely can do that.
We could look at it as a signal mux problem as this thread suggests OR 
look at it as interrupt distribution problem (which is how it looks like 
at the face of it). That said, maybe a intermediate pinctrl approach 
might be more pragmatic and less theoretically flexible.
an option might be to "statically allocate" default number of interrupts 
to a domain - example:
* GIC IRQ 72->78 allotted to UARTs
* pinctrl mapping provided for those but only 6 can be used (rest are 
marked status="disabled" as default) at any given time (choice of 
pinctrl option determines GIC interrupt line to use)
* All modules will have a pinctrl definition to have a mapping - to 
avoid bootloader overriding default cross bar setting in ways 
un-expected by kernel.

Does that sound fair trade off?

[1] http://marc.info/?l=linux-omap&m=137335524702155&w=2
[2] http://marc.info/?l=linux-omap&m=137335522802144&w=2
-- 
Regards,
Nishanth Menon


From nico at fluxnic.net  Wed Jul 24 12:16:59 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Wed, 24 Jul 2013 12:16:59 -0400 (EDT)
Subject: [PATCH 1/6] ARM: prefetch: remove redundant "cc" clobber
In-Reply-To: <20130724101950.GG9629@mudshark.cambridge.arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-2-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231547010.15022@syhkavp.arg>
 <20130724101950.GG9629@mudshark.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1307241205050.15022@syhkavp.arg>

On Wed, 24 Jul 2013, Will Deacon wrote:

> Hi Nicolas,
> 
> On Tue, Jul 23, 2013 at 08:48:11PM +0100, Nicolas Pitre wrote:
> > On Tue, 23 Jul 2013, Will Deacon wrote:
> > 
> > > The pld instruction does not affect the condition flags, so don't bother
> > > clobbering them.
> > > 
> > > Signed-off-by: Will Deacon <will.deacon at arm.com>
> > 
> > Acked-by: Nicolas Pitre <nico at linaro.org>
> 
> Thanks for reviewing the series, much appreciated.
> 
> > You know the legacy reason why the cc clobber was there, right?
> > It certainly doesn't apply anymore.
> 
> I was under the impression that it was due to ancient GCC behaviour and the "cc"
> was there to prevent re-ordering. For interest, what are the specifics?

In the old days, you had to take care of the predicate for conditional 
instructions in your inline asm code.  So for example, if you had:

	if (foo)
		inline asm ("mov %0, #1" : "=r" (bar));

That wouldn't work most of the time because even if the if condition was 
false, gcc would not branch over the inline asm code but expect you to 
take care of the condition code.  That means the above needed to be 
written as:

	if (foo)
		inline asm ("mov%? %0, #1" : "=r" (bar));

Because having %? added all over the place was cumbersome, the 
alternative was to add "cc" to the clobber list so gcc would then branch 
across the inline asm when the condition is false.

But of course many people forgot about those subtle details quite often, 
and then gcc was changed so inline asm was made non predicated.


Nicolas


From jonathan.austin at arm.com  Wed Jul 24 12:18:50 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Wed, 24 Jul 2013 17:18:50 +0100
Subject: [PATCH 0/3] trivial fixes relating to !CONFIG_OF
Message-ID: <1374682733-7416-1-git-send-email-jonathan.austin@arm.com>

This series contains 3 trivial fixes picked up along the path of building
kernels without CONFIG_OF enabled. They're things likely to break randconfig
builds, etc, if not fixed up.

Jonathan Austin (3):
  PSCI: add missing dependency on CONFIG_OF for PSCI.
  clocksource: Add missing dependency on CONFIG_OF for ARM_ARCH_TIMER
  ARM: arch_timer: Add missing include for of_* functions

 arch/arm/Kconfig                     |    1 +
 drivers/clocksource/Kconfig          |    3 ++-
 drivers/clocksource/arm_arch_timer.c |    1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

-- 
1.7.9.5




From jonathan.austin at arm.com  Wed Jul 24 12:18:52 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Wed, 24 Jul 2013 17:18:52 +0100
Subject: [PATCH 2/3] clocksource: Add missing dependency on CONFIG_OF for
 ARM_ARCH_TIMER
In-Reply-To: <1374682733-7416-1-git-send-email-jonathan.austin@arm.com>
References: <1374682733-7416-1-git-send-email-jonathan.austin@arm.com>
Message-ID: <1374682733-7416-3-git-send-email-jonathan.austin@arm.com>

Initialisation of the ARM Arch timer requires data from the DT. There is no
fallback initialisation method and hence selecting ARM_ARCH_TIMER without OF
makes little sense.

Furthermore, doing so causes a build error because the of_* stubs for
!CONFIG_OF do not extend to all of the functions being used by this driver,
and will not be extended unless there are valid use-cases for them to be
(this is not a valid case).

Signed-off-by: Jonathan Austin <jonathan.austin at arm.com>
---
 drivers/clocksource/Kconfig |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index b7b9b04..4348902 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -72,7 +72,8 @@ config CLKSRC_DBX500_PRCMU_SCHED_CLOCK
 
 config ARM_ARCH_TIMER
 	bool
-	select CLKSRC_OF if OF
+	depends on OF
+	select CLKSRC_OF
 
 config ARM_GLOBAL_TIMER
 	bool
-- 
1.7.9.5




From jonathan.austin at arm.com  Wed Jul 24 12:18:53 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Wed, 24 Jul 2013 17:18:53 +0100
Subject: [PATCH 3/3] ARM: arch_timer: Add missing include for of_* functions
In-Reply-To: <1374682733-7416-1-git-send-email-jonathan.austin@arm.com>
References: <1374682733-7416-1-git-send-email-jonathan.austin@arm.com>
Message-ID: <1374682733-7416-4-git-send-email-jonathan.austin@arm.com>

The arch timer code uses a bunch of of_* functions that are defined in
linux/of.h. Currently this header is not included but the functions are
available elsewise.

Signed-off-by: Jonathan Austin <jonathan.austin at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
---
 drivers/clocksource/arm_arch_timer.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index ffadd83..857a196 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -15,6 +15,7 @@
 #include <linux/cpu.h>
 #include <linux/clockchips.h>
 #include <linux/interrupt.h>
+#include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/io.h>
 
-- 
1.7.9.5




From jonathan.austin at arm.com  Wed Jul 24 12:18:51 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Wed, 24 Jul 2013 17:18:51 +0100
Subject: [PATCH 1/3] PSCI: add missing dependency on CONFIG_OF for PSCI.
In-Reply-To: <1374682733-7416-1-git-send-email-jonathan.austin@arm.com>
References: <1374682733-7416-1-git-send-email-jonathan.austin@arm.com>
Message-ID: <1374682733-7416-2-git-send-email-jonathan.austin@arm.com>

The PSCI initialisation depends on data found in the DT. Without this the
including PSCI support makes little sense, and furthermore the of_* stub
functions aren't broad enough to ensure that this builds without CONFIG_OF.

As there is little enthusiasm for extending these stubs without useful use-cases
(of which this is *not* an example) this patch prevents building of PSCI
without CONFIG_OF.

Signed-off-by: Jonathan Austin <jonathan.austin at arm.com>
---
 arch/arm/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..972ec25 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1577,6 +1577,7 @@ config HOTPLUG_CPU
 config ARM_PSCI
 	bool "Support for the ARM Power State Coordination Interface (PSCI)"
 	depends on CPU_V7
+	depends on CONFIG_OF
 	help
 	  Say Y here if you want Linux to communicate with system firmware
 	  implementing the PSCI specification for CPU-centric power
-- 
1.7.9.5




From will.deacon at arm.com  Wed Jul 24 12:20:37 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 17:20:37 +0100
Subject: [PATCH 12/14] ARM: traps: use <asm/opcodes.h> to get correct
 instruction order
In-Reply-To: <1374661682-9349-13-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-13-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130724162036.GS11072@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 11:28:00AM +0100, Ben Dooks wrote:
> The trap handler needs to take into account the endian configuration of
> the system when loading instructions. Use <asm/opcodes.h> to provide the
> necessary conversion functions.
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---
>  arch/arm/kernel/traps.c |   10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index 18b32e8..c300e51 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -34,6 +34,7 @@
>  #include <asm/unwind.h>
>  #include <asm/tls.h>
>  #include <asm/system_misc.h>
> +#include <asm/opcodes.h>
>  
>  #include "signal.h"
>  
> @@ -404,23 +405,24 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
>  	if (processor_mode(regs) == SVC_MODE) {
>  #ifdef CONFIG_THUMB2_KERNEL
>  		if (thumb_mode(regs)) {
> -			instr = ((u16 *)pc)[0];
> +			instr = __mem_to_opcode_thumb16(((u16 *)pc)[0]);
>  			if (is_wide_instruction(instr)) {
>  				instr <<= 16;
> -				instr |= ((u16 *)pc)[1];
> +				instr |= __mem_to_opcode_thumb16(((u16 *)pc)[1]);
>  			}
>  		} else
>  #endif
> -			instr = *(u32 *) pc;
> +			instr = __mem_to_opcode_arm(*(u32 *) pc);
>  	} else if (thumb_mode(regs)) {
>  		if (get_user(instr, (u16 __user *)pc))
>  			goto die_sig;
> +		instr = __mem_to_opcode_thumb16(instr);
>  		if (is_wide_instruction(instr)) {
>  			unsigned int instr2;
>  			if (get_user(instr2, (u16 __user *)pc+1))
>  				goto die_sig;
>  			instr <<= 16;
> -			instr |= instr2;
> +			instr |= __mem_to_opcode_thumb16(instr2);
>  		}
>  	} else if (get_user(instr, (u32 __user *)pc)) {
>  		goto die_sig;

Maybe it's also worth updating dump_instr, so that we don't confuse people
by printing the faulting instruction in the wrong endianness.

Will


From will.deacon at arm.com  Wed Jul 24 12:25:30 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 17:25:30 +0100
Subject: [PATCH 14/14] ARM: set --be8 when linking modules
In-Reply-To: <1374661682-9349-15-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-15-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130724162530.GT11072@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 11:28:02AM +0100, Ben Dooks wrote:
> To avoid having to make every text section swap the instruction order
> of all instructions, make sure modules are built also built with --be8
> (as is the current kernel final link).
> 
> If we do not do this, we would end up having to swap all instructions
> when loading a module, instead of just the instructions that we are
> applying ELF relocations to.
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>

Reviewed-by: Will Deacon <will.deacon at arm.com>

Will


From will.deacon at arm.com  Wed Jul 24 12:29:58 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 17:29:58 +0100
Subject: [PATCH 06/14] ARM: twd: data endian fix
In-Reply-To: <51EFED92.2050408@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-7-git-send-email-ben.dooks@codethink.co.uk>
 <20130724144923.GO11072@mudshark.cambridge.arm.com>
 <51EFED92.2050408@codethink.co.uk>
Message-ID: <20130724162958.GU11072@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 04:06:58PM +0100, Ben Dooks wrote:
> On 24/07/13 15:49, Will Deacon wrote:
> > On Wed, Jul 24, 2013 at 11:27:54AM +0100, Ben Dooks wrote:
> >> Ensure the twd driver uses the correct calls to access the hardware
> >> to ensure that we do not end up with data in the wrong endian format.
> >>
> >> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
> >
> > Reviewed-by: Will Deacon<will.deacon at arm.com>
> >
> > There are a bunch of other __raw_* users under arch/arm/, but I suppose we
> > can let other people move those over as they see fit. It wouldn't hurt to
> > fix arch/arm/include/asm/{cti,hardware/coresight.h} though.
> 
> I didn't think to look for things under there.
> 
> Do people think it would be worth just changing __raw_read/__raw_write
> functions to also take into account endian-ness?

That's probably a bit too far and will likely break some of the many drivers
which use these accessors. It also puts us at odds with other architectures
offering these accessors, so we're better off just fixing the callsites as
appropriate.

Will


From shuahkhan at gmail.com  Wed Jul 24 12:30:33 2013
From: shuahkhan at gmail.com (Shuah Khan)
Date: Wed, 24 Jul 2013 10:30:33 -0600
Subject: Linux Plumbers ACPI/PM, PCI Microconference
In-Reply-To: <CAErSpo7TexM5-7Z=8H+B5=49-GzoKd_prn=LbMFZWV9rpdn__A@mail.gmail.com>
References: <CAL-B5D03ki8NHsM6EuESTH2K-Eh+XyFHNXPDYwgDq+oagDjtMQ@mail.gmail.com>
 <CAErSpo7TexM5-7Z=8H+B5=49-GzoKd_prn=LbMFZWV9rpdn__A@mail.gmail.com>
Message-ID: <CAKocOOOW6+eqb6GTsWLgonQQ7uy5R10t6L_T3jaTN9qSbetVeQ@mail.gmail.com>

On Tue, Jul 23, 2013 at 10:06 AM, Bjorn Helgaas <bhelgaas at google.com> wrote:
> On Tue, Jul 16, 2013 at 8:21 PM, Myron Stowe <myron.stowe at gmail.com> wrote:
>> Linux Plumbers has approved an ACPI/PM, PCI microconference. The
>> overview page is here:
>>
>> http://wiki.linuxplumbersconf.org/2013:pci_subsystem
>>
>> We would like to start receiving volunteers for presenting topics of
>> interest.  There is a lot of activity in these subsystems so please
>> respond by submitting presentation or discussion proposals that you
>> would be willing to cover for consideration.  You should also feel
>> free to submit ideas as proposals that others could cover.
>
> Somebody else privately suggested these ARM/PCI topics:
>
>> -> how it's been cleaned up to be more common across arm-32 machines
>> -> dependencies on dtb
>> -> future use/dependency(s) on ACPI
>> -> hotplug support issues (if any; acpi (host-bridge) vs <whatever ARM uses> ?)
>
> and I'm interested in those as well.  There seems to be a lot of
> activity in that area.  In addition, I'm interested in ARM IOMMU
> support.  I see drivers/iommu/arm-smmu.c, but it's brand-new and I
> haven't looked at it at all.
>

I second this topic. I am interested in ARM/iommu space also.

thanks,
-- Shuah


From tj at kernel.org  Wed Jul 24 12:30:38 2013
From: tj at kernel.org (Tejun Heo)
Date: Wed, 24 Jul 2013 12:30:38 -0400
Subject: [v8 3/3] ahci_imx: add ahci sata support on imx platforms
In-Reply-To: <1374646529-24432-4-git-send-email-Hong-Xing.Zhu@freescale.com>
References: <1374646529-24432-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1374646529-24432-4-git-send-email-Hong-Xing.Zhu@freescale.com>
Message-ID: <20130724163038.GF20377@mtj.dyndns.org>

On Wed, Jul 24, 2013 at 02:15:29PM +0800, Richard Zhu wrote:
> From: Richard Zhu <r65037 at freescale.com>
> 
> imx6q contains one Synopsys AHCI SATA controller,
> But it can't share ahci_platform driver with other
> controllers.
> Because there are some misalignments of the generic
> AHCI controller.
> The bits definitions of the HBA registers, the Vendor
> Specific registers, the AHCI PHY clock and the AHCI
> signals adjustment window(GPR13 register).
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default
>  value is '0', should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the
>  HOST_PORTS_IMPL should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)
>  should be configured regarding to the frequency of AHB
>  bus clock.
>  - Configurations of the AHCI PHY clock, and the signal
>  parameters of the GPR13
> 
> Setup its own ahci sata driver, contained the imx6q specific
> initialized codes, re-use the generic ahci_platform driver, and
> keep the generic ahci_platform driver clean as much as possible.
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> Reviewed-by: Shawn Guo <shawn.guo at linaro.org>

Applied 2-3 to libata/for-3.11-fixes with minor adjustments.

Thanks.

-- 
tejun


From will.deacon at arm.com  Wed Jul 24 12:35:31 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 17:35:31 +0100
Subject: [PATCH 1/6] ARM: prefetch: remove redundant "cc" clobber
In-Reply-To: <alpine.LFD.2.03.1307241205050.15022@syhkavp.arg>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-2-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231547010.15022@syhkavp.arg>
 <20130724101950.GG9629@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1307241205050.15022@syhkavp.arg>
Message-ID: <20130724163530.GV11072@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 05:16:59PM +0100, Nicolas Pitre wrote:
> On Wed, 24 Jul 2013, Will Deacon wrote:
> > On Tue, Jul 23, 2013 at 08:48:11PM +0100, Nicolas Pitre wrote:
> > > You know the legacy reason why the cc clobber was there, right?
> > > It certainly doesn't apply anymore.
> > 
> > I was under the impression that it was due to ancient GCC behaviour and the "cc"
> > was there to prevent re-ordering. For interest, what are the specifics?
> 
> In the old days, you had to take care of the predicate for conditional 
> instructions in your inline asm code.  So for example, if you had:
> 
> 	if (foo)
> 		inline asm ("mov %0, #1" : "=r" (bar));
> 
> That wouldn't work most of the time because even if the if condition was 
> false, gcc would not branch over the inline asm code but expect you to 
> take care of the condition code.  That means the above needed to be 
> written as:
> 
> 	if (foo)
> 		inline asm ("mov%? %0, #1" : "=r" (bar));
> 
> Because having %? added all over the place was cumbersome, the 
> alternative was to add "cc" to the clobber list so gcc would then branch 
> across the inline asm when the condition is false.
> 
> But of course many people forgot about those subtle details quite often, 
> and then gcc was changed so inline asm was made non predicated.

Holy sh*t....

Next time I complain to the tools guys about inline asm, I'll count my
blessings so they don't try and resurrect anything as horrendous as what
you've just described.

Thanks for the insight!

Will


From p.zabel at pengutronix.de  Wed Jul 24 12:35:28 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Wed, 24 Jul 2013 18:35:28 +0200
Subject: [PATCH 1/2] ARM i.MX6Q: dts: Enable SPI NOR flash on Phytec
 phyFLEX-i.MX6 Ouad module
Message-ID: <1374683729-13438-1-git-send-email-p.zabel@pengutronix.de>

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
index f5e1981..5113d29 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
@@ -20,6 +20,20 @@
 	};
 };
 
+&ecspi3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi3_1>;
+	status = "okay";
+	fsl,spi-num-chipselects = <1>;
+	cs-gpios = <&gpio4 24 0>;
+
+	flash: m25p80 at 0 {
+		compatible = "m25p80";
+		spi-max-frequency = <20000000>;
+		reg = <0>;
+	};
+};
+
 &iomuxc {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_hog>;
@@ -28,6 +42,7 @@
 		pinctrl_hog: hoggrp {
 			fsl,pins = <
 				MX6Q_PAD_EIM_D23__GPIO3_IO23    0x80000000
+				MX6Q_PAD_DISP0_DAT3__GPIO4_IO24	0x80000000 /* SPI NOR chipselect */
 			>;
 		};
 	};
-- 
1.8.3.2



From p.zabel at pengutronix.de  Wed Jul 24 12:35:29 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Wed, 24 Jul 2013 18:35:29 +0200
Subject: [PATCH 2/2] ARM i.MX6Q: dts: Enable I2C1 with EEPROM and PMIC on
 Phytec phyFLEX-i.MX6 Ouad module
In-Reply-To: <1374683729-13438-1-git-send-email-p.zabel@pengutronix.de>
References: <1374683729-13438-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1374683729-13438-2-git-send-email-p.zabel@pengutronix.de>

This patch enables I2C1 and adds device tree nodes for the EEPROM and the
DA9063 PMIC connected to this I2C bus.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 91 ++++++++++++++++++++++++++++++
 1 file changed, 91 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
index 5113d29..8d1a548 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
@@ -34,6 +34,96 @@
 	};
 };
 
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1_1>;
+	status = "okay";
+
+	eeprom at 50 {
+		compatible = "atmel,24c32";
+		reg = <0x50>;
+	};
+
+	pmic at 58 {
+		compatible = "dialog,da9063";
+		reg = <0x58>;
+		interrupt-parent = <&gpio4>;
+		interrupts = <17 0x8>; /* active-low GPIO4_17 */
+
+		regulators {
+			vddcore_reg: bcore1 {
+				regulator-min-microvolt = <730000>;
+				regulator-max-microvolt = <1380000>;
+				regulator-always-on;
+			};
+
+			vddsoc_reg: bcore2 {
+				regulator-min-microvolt = <730000>;
+				regulator-max-microvolt = <1380000>;
+				regulator-always-on;
+			};
+
+			vdd_ddr3_reg: bpro {
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-always-on;
+			};
+
+			vdd_3v3_reg: bperi {
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vdd_buckmem_reg: bmem {
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vdd_eth_reg: bio {
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-always-on;
+			};
+
+			vdd_eth_io_reg: ldo4 {
+				regulator-min-microvolt = <2500000>;
+				regulator-max-microvolt = <2500000>;
+				regulator-always-on;
+			};
+
+			vdd_mx6_snvs_reg: ldo5 {
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-always-on;
+			};
+
+			vdd_3v3_pmic_io_reg: ldo6 {
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vdd_sd0_reg: ldo9 {
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+			};
+
+			vdd_sd1_reg: ldo10 {
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+			};
+
+			vdd_mx6_high_reg: ldo11 {
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-always-on;
+			};
+		};
+	};
+};
+
 &iomuxc {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_hog>;
@@ -43,6 +133,7 @@
 			fsl,pins = <
 				MX6Q_PAD_EIM_D23__GPIO3_IO23    0x80000000
 				MX6Q_PAD_DISP0_DAT3__GPIO4_IO24	0x80000000 /* SPI NOR chipselect */
+				MX6Q_PAD_DI0_PIN15__GPIO4_IO17  0x80000000 /* PMIC interrupt */
 			>;
 		};
 	};
-- 
1.8.3.2



From santosh.shilimkar at ti.com  Wed Jul 24 12:38:51 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 24 Jul 2013 12:38:51 -0400
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <51EFFBE1.4090505@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <51E83A4F.5080904@ti.com>
 <CACRpkdY3nQaWimTwB-Zt-8+Q_KZr8a0rpB1SUQq=AuoG4bAYnQ@mail.gmail.com>
 <51ED2385.60108@ti.com> <51ED5C66.1010407@ti.com> <51EFFBE1.4090505@ti.com>
Message-ID: <51F0031B.1050307@ti.com>

On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote:
> On 07/22/2013 11:23 AM, Santosh Shilimkar wrote:
>> To summaries it again, what I understood from Sricharan's proposal,
>>
>> - Setup all the routing at cross-bar probe so that kernel continue to
>> work like normal IRQ controller with cross-bar scope vanishes once
>> the routing is done. Cross-bar does this before any of the devices
>> are created.
>> - Something similar needs to happen for DMA lines as well or for any
>> other event routing in future.
>> - Cross-bar callbacks for device drivers for error paths.
>> (Sricharan, you have to drop these because it doesn't bring any
>> functionality and rather can create a side effects of drivers
>> getting polluted.)
> Ack.
> 
>>
>> The concern raised on above was instead of fixing the routing at DT
>> statically, doing at the driver probes where the loop-up for IRQ or DMA
>> lines should happen in background transparently on drivers call of
>> request_irq/request_dma_channel etc with cross-bar number as
>> an input to it. Though it will be nice to have
>> such feature, it doesn't bring anything special and brings the
>> notion of these APIs which expect that you know what IRQ and DMA
>> lines you want while calling these.
> Unfortunately, we do have a constraint without allocating dynamic IRQs - what IP instances should hwmod and dts contain?
> 
> If we go with current series of patches[1] [2] for DRA7 dts which assumes default mapping, hence, uart7-10, GPTimers12-16 dont have default irq - hence they dont exist in dts etc.
> 
> How would we like to support those with pinctrl approach?
>
The whole reason the cross-bar being there because all the peripherals
IRQs can not me routed to the IRQ controller. So You pick up a configuration
would like to support and stick to it. It will be good to specify all the
peripheral devices but tsome of them might not have the IRQ/DMA lines
associated with them because of limited slots on IRQ/DMA controller.

>>
>> Note that mux inputs are pretty much fixed. Its his connection
>> to IRQ controller or DMA controller is what needs to be programmed.
>> So scope is pretty much limited. I felt this requirement is pretty
>> similar to pin-mux and hence thought of it as a viable option.
>>
>> Having said all of above, if there is a better alternative than
>> enhanced pin-mux we surely can do that.
> We could look at it as a signal mux problem as this thread suggests OR look at it as interrupt distribution problem (which is how it looks like at the face of it).
Its not interrupt distribution problem but rather setting up the signal
routing which otherwise generally hardwired in SOC. Hence the pin-control analogy.
Pinmux also lets you set many possible combinations but we pick one for a board design.

> That said, maybe a intermediate pinctrl approach might be more pragmatic andless theoretically flexible.
> an option might be to "statically allocate" default number of interrupts to a domain - example:
> * GIC IRQ 72->78 allotted to UARTs
> * pinctrl mapping provided for those but only 6 can be used (rest are marked status="disabled" as default) at any given time (choice of pinctrl option determines GIC interrupt line to use)
> * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel.
> 
> Does that sound fair trade off?
This sounds better. That way we can get all the devices in the DT at least.

Regards,
Santosh



From Dave.Martin at arm.com  Wed Jul 24 12:47:22 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Wed, 24 Jul 2013 17:47:22 +0100
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value to
 index into save array
In-Reply-To: <1374550289-25305-2-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-2-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130724164717.GA4610@localhost.localdomain>

On Mon, Jul 22, 2013 at 11:31:17PM -0400, Nicolas Pitre wrote:
> Currently we hash the MPIDR of the CPU being suspended to determine which
> entry in the sleep_save_sp array to use. In some situations, such as when
> we want to resume on another physical CPU, the MPIDR of another CPU should
> be used instead.
> 
> So let's use the value of cpu_logical_map(smp_processor_id()) in place
> of the MPIDR in the suspend path.  This will result in the same index
> being used as with the previous code unless the caller has modified
> cpu_logical_map() beforehand.

This only works because we happen to swap MPIDRs in cpu_logical_map
before we get here, so that cpu_logical_map(smp_processor_id())
described the post-resume situation for this logical CPU, not the
current situation.

We have to swizzle cpu_logical_map() somewhere, and the suspend path is
just as good as the resume path for that.  But this patch commits us to
requiring that on the suspend path specifically -- I think that ought to
be mentioned somewhere.  A comment in the preamble for __cpu_suspend
would be enough, I think.

Looks like the patch should work though, and it does remove the need to
read the MPIDR, which is slightly nicer for the non-switcher case.

Cheers
---Dave

> 
> The register allocation in __cpu_suspend is reworked in order to better
> accommodate the additional argument.
> 
> Signed-off-by: Nicolas Pitre <nico at linaro.org>
> ---
>  arch/arm/kernel/sleep.S   | 25 +++++++++++--------------
>  arch/arm/kernel/suspend.c |  8 +++++---
>  2 files changed, 16 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
> index db1536b8b3..836d10e698 100644
> --- a/arch/arm/kernel/sleep.S
> +++ b/arch/arm/kernel/sleep.S
> @@ -55,6 +55,7 @@
>   * specific registers and some other data for resume.
>   *  r0 = suspend function arg0
>   *  r1 = suspend function
> + *  r2 = MPIDR value used to index into sleep_save_sp
>   */
>  ENTRY(__cpu_suspend)
>  	stmfd	sp!, {r4 - r11, lr}
> @@ -67,23 +68,19 @@ ENTRY(__cpu_suspend)
>  	mov	r5, sp			@ current virtual SP
>  	add	r4, r4, #12		@ Space for pgd, virt sp, phys resume fn
>  	sub	sp, sp, r4		@ allocate CPU state on stack
> -	stmfd	sp!, {r0, r1}		@ save suspend func arg and pointer
> -	add	r0, sp, #8		@ save pointer to save block
> -	mov	r1, r4			@ size of save block
> -	mov	r2, r5			@ virtual SP
>  	ldr	r3, =sleep_save_sp
> +	stmfd	sp!, {r0, r1}		@ save suspend func arg and pointer
>  	ldr	r3, [r3, #SLEEP_SAVE_SP_VIRT]
> -	ALT_SMP(mrc p15, 0, r9, c0, c0, 5)
> -        ALT_UP_B(1f)
> -	ldr	r8, =mpidr_hash
> -	/*
> -	 * This ldmia relies on the memory layout of the mpidr_hash
> -	 * struct mpidr_hash.
> -	 */
> -	ldmia	r8, {r4-r7}	@ r4 = mpidr mask (r5,r6,r7) = l[0,1,2] shifts
> -	compute_mpidr_hash	lr, r5, r6, r7, r9, r4
> -	add	r3, r3, lr, lsl #2
> +	ALT_SMP(ldr r0, =mpidr_hash)
> +       ALT_UP_B(1f)
> +	/* This ldmia relies on the memory layout of the mpidr_hash struct */
> +	ldmia	r0, {r1, r6-r8}	@ r1 = mpidr mask (r6,r7,r8) = l[0,1,2] shifts
> +	compute_mpidr_hash	r0, r6, r7, r8, r2, r1
> +	add	r3, r3, r0, lsl #2
>  1:
> +	mov	r2, r5			@ virtual SP
> +	mov	r1, r4			@ size of save block
> +	add	r0, sp, #8		@ pointer to save block
>  	bl	__cpu_suspend_save
>  	adr	lr, BSYM(cpu_suspend_abort)
>  	ldmfd	sp!, {r0, pc}		@ call suspend fn
> diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
> index 41cf3cbf75..2835d35234 100644
> --- a/arch/arm/kernel/suspend.c
> +++ b/arch/arm/kernel/suspend.c
> @@ -10,7 +10,7 @@
>  #include <asm/suspend.h>
>  #include <asm/tlbflush.h>
>  
> -extern int __cpu_suspend(unsigned long, int (*)(unsigned long));
> +extern int __cpu_suspend(unsigned long, int (*)(unsigned long), u32 cpuid);
>  extern void cpu_resume_mmu(void);
>  
>  #ifdef CONFIG_MMU
> @@ -21,6 +21,7 @@ extern void cpu_resume_mmu(void);
>  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
>  {
>  	struct mm_struct *mm = current->active_mm;
> +	u32 __mpidr = cpu_logical_map(smp_processor_id());
>  	int ret;
>  
>  	if (!idmap_pgd)
> @@ -32,7 +33,7 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
>  	 * resume (indicated by a zero return code), we need to switch
>  	 * back to the correct page tables.
>  	 */
> -	ret = __cpu_suspend(arg, fn);
> +	ret = __cpu_suspend(arg, fn, __mpidr);
>  	if (ret == 0) {
>  		cpu_switch_mm(mm->pgd, mm);
>  		local_flush_bp_all();
> @@ -44,7 +45,8 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
>  #else
>  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
>  {
> -	return __cpu_suspend(arg, fn);
> +	u32 __mpidr = cpu_logical_map(smp_processor_id());
> +	return __cpu_suspend(arg, fn, __mpidr);
>  }
>  #define	idmap_pgd	NULL
>  #endif
> -- 
> 1.8.1.2
> 


From nm at ti.com  Wed Jul 24 12:47:44 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 24 Jul 2013 11:47:44 -0500
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <51F0031B.1050307@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <51E83A4F.5080904@ti.com>
 <CACRpkdY3nQaWimTwB-Zt-8+Q_KZr8a0rpB1SUQq=AuoG4bAYnQ@mail.gmail.com>
 <51ED2385.60108@ti.com> <51ED5C66.1010407@ti.com> <51EFFBE1.4090505@ti.com>
 <51F0031B.1050307@ti.com>
Message-ID: <51F00530.9090703@ti.com>

On 07/24/2013 11:38 AM, Santosh Shilimkar wrote:
> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote:
>> That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible.
>> an option might be to "statically allocate" default number of interrupts to a domain - example:
>> * GIC IRQ 72->78 allotted to UARTs
>> * pinctrl mapping provided for those but only 6 can be used (rest are marked status="disabled" as default) at any given time (choice of pinctrl option determines GIC interrupt line to use)
>> * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel.
>>
>> Does that sound fair trade off?
> This sounds better. That way we can get all the devices in the DT at least.

Fair enough - if Linus and Tony are still ok with this approach to the 
problem, seeing a patch series with the effect would be beneficial.

-- 
Regards,
Nishanth Menon


From linux at arm.linux.org.uk  Wed Jul 24 12:58:21 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 24 Jul 2013 17:58:21 +0100
Subject: [PATCH 1/6] ARM: prefetch: remove redundant "cc" clobber
In-Reply-To: <20130724163530.GV11072@mudshark.cambridge.arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-2-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231547010.15022@syhkavp.arg>
 <20130724101950.GG9629@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1307241205050.15022@syhkavp.arg>
 <20130724163530.GV11072@mudshark.cambridge.arm.com>
Message-ID: <20130724165820.GZ24642@n2100.arm.linux.org.uk>

On Wed, Jul 24, 2013 at 05:35:31PM +0100, Will Deacon wrote:
> On Wed, Jul 24, 2013 at 05:16:59PM +0100, Nicolas Pitre wrote:
> > On Wed, 24 Jul 2013, Will Deacon wrote:
> > > On Tue, Jul 23, 2013 at 08:48:11PM +0100, Nicolas Pitre wrote:
> > > > You know the legacy reason why the cc clobber was there, right?
> > > > It certainly doesn't apply anymore.
> > > 
> > > I was under the impression that it was due to ancient GCC behaviour and the "cc"
> > > was there to prevent re-ordering. For interest, what are the specifics?
> > 
> > In the old days, you had to take care of the predicate for conditional 
> > instructions in your inline asm code.  So for example, if you had:
> > 
> > 	if (foo)
> > 		inline asm ("mov %0, #1" : "=r" (bar));
> > 
> > That wouldn't work most of the time because even if the if condition was 
> > false, gcc would not branch over the inline asm code but expect you to 
> > take care of the condition code.  That means the above needed to be 
> > written as:
> > 
> > 	if (foo)
> > 		inline asm ("mov%? %0, #1" : "=r" (bar));
> > 
> > Because having %? added all over the place was cumbersome, the 
> > alternative was to add "cc" to the clobber list so gcc would then branch 
> > across the inline asm when the condition is false.
> > 
> > But of course many people forgot about those subtle details quite often, 
> > and then gcc was changed so inline asm was made non predicated.
> 
> Holy sh*t....
> 
> Next time I complain to the tools guys about inline asm, I'll count my
> blessings so they don't try and resurrect anything as horrendous as what
> you've just described.

And the result of its removal is all the horrid macro crap in asm/tlbflush.h
to work around the lack of this feature - otherwise we end up with seven
instances of:

	tst
	bne	1f
	mcr
1:

for every call to a TLB function.  GCC _could_ have detected the lack of
%? and the lack of "cc" clobber and either warned or implicitly branched
around the block.  There was no need to completely remove the facility.

So now, instead, we have to do lots of preprocessor junk to work out what
instructions are always executed, which are never executed, and which
might be executed.  All that additional complexity thanks to the removal
of this brilliant feature.

That was a truely sad day when that happened.


From paul at pwsan.com  Wed Jul 24 13:00:28 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 24 Jul 2013 17:00:28 +0000 (UTC)
Subject: [PATCH v2] ARM: Do not run dummy_flush_tlb_a15_erratum() on
 non-Cortex-A15
In-Reply-To: <1374581199-8277-1-git-send-email-festevam@gmail.com>
References: <1374581199-8277-1-git-send-email-festevam@gmail.com>
Message-ID: <alpine.DEB.2.02.1307241700010.13653@utopia.booyaka.com>

On Tue, 23 Jul 2013, Fabio Estevam wrote:

> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Commit 93dc688 (ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 
> (TLBI/DSB operations)) causes the following undefined instruction error on a
> mx53 (Cortex-A8):
> 
> Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> CPU: 0 PID: 275 Comm: modprobe Not tainted 3.11.0-rc2-next-20130722-00009-g9b0f371 #881
> task: df46cc00 ti: df48e000 task.ti: df48e000
> PC is at check_and_switch_context+0x17c/0x4d0
> LR is at check_and_switch_context+0xdc/0x4d0
> 
> This problem happens because check_and_switch_context() calls 
> dummy_flush_tlb_a15_erratum() without checking if we are really running on a 
> Cortex-A15 or not. 
> 
> To avoid this issue, only call dummy_flush_tlb_a15_erratum() inside 
> check_and_switch_context() if erratum_a15_798181() returns true, which means
> that we are really running on a Cortex-A15.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Tested-by: Paul Walmsley <paul at pwsan.com> # for OMAP2,3,4,AM33xx

Fixes the v3.11-rc boot regression that broke multiple boards.

- Paul


From kgene.kim at samsung.com  Wed Jul 24 13:00:37 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Thu, 25 Jul 2013 02:00:37 +0900
Subject: [GIT PULL] Samsung-fixes-1 for v3.11
Message-ID: <51F00835.9040202@samsung.com>

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

   Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
tags/samsung-fixes-1

for you to fetch changes up to 53302bf60d2c95ee42118008499a5f5de544fcc1:

   ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos (2013-07-24 
18:55:27 +0900)

----------------------------------------------------------------
Samsung fixes for v3.11
- fix kernel booting on exynos5440
   skip pm which is not supported
   update regarding LPAE features
- fix s3c2440 uart with adding clkdev entries
- fix compilatioin for Samsung SoCs with selecting pm
- update ARCH_NR_GPIO to support exynos4412 has more gpios

----------------------------------------------------------------
Amit Daniel Kachhap (1):
       ARM: SAMSUNG: Add SAMSUNG_PM config option to select pm

Kukjin Kim (1):
       ARM: EXYNOS: skip pm support on exynos5440

Sachin Kamat (1):
       ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos

Subash Patel (1):
       ARM: EXYNOS: change the PHYSMEM_BITS and SECTION_SIZE

Sylwester Nawrocki (1):
       ARM: S3C24XX: Add missing clkdev entries for s3c2440 UART

Thomas Abraham (1):
       ARM: EXYNOS: Enable 64-bit DMA for EXYNOS5440 if LPAE is enabled

Yadwinder Singh Brar (2):
       ARM: SAMSUNG: Save/restore only selected uart's registers
       ARM: EXYNOS: Fix low level debug support

  arch/arm/Kconfig                           |   3 +-
  arch/arm/mach-exynos/Kconfig               |   1 +
  arch/arm/mach-exynos/Makefile              |   2 +-
  arch/arm/mach-exynos/common.c              |  26 -----
  arch/arm/mach-exynos/common.h              |   1 -
  arch/arm/mach-exynos/cpuidle.c             |   1 +
  arch/arm/mach-exynos/include/mach/memory.h |   5 +
  arch/arm/mach-exynos/pm.c                  |   6 ++
  arch/arm/mach-s3c24xx/clock-s3c2410.c      | 161 
++++++++++++++++++-----------
  arch/arm/mach-s3c24xx/clock-s3c2440.c      |   3 +
  arch/arm/plat-samsung/Kconfig              |   7 ++
  arch/arm/plat-samsung/Makefile             |   2 +-
  arch/arm/plat-samsung/include/plat/clock.h |   5 +
  arch/arm/plat-samsung/include/plat/pm.h    |   8 +-
  arch/arm/plat-samsung/pm.c                 |  14 +--
  15 files changed, 136 insertions(+), 109 deletions(-)



From swarren at wwwdotorg.org  Wed Jul 24 13:02:34 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 24 Jul 2013 10:02:34 -0700
Subject: [PATCH V4 2/4] ARM: tegra114: Reprogram GIC CPU interface to
 bypass IRQ on CPU PM entry
In-Reply-To: <1374666419.23756.55.camel@jlo-ubuntu-64.nvidia.com>
References: <1374225926-26832-1-git-send-email-josephl@nvidia.com>
 <1374225926-26832-3-git-send-email-josephl@nvidia.com>
 <20130723154438.GA2864@dhcp-172-17-186-34.nvidia.com>
 <1374666419.23756.55.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <51F008AA.2030101@wwwdotorg.org>

On 07/24/2013 04:46 AM, Joseph Lo wrote:
> On Tue, 2013-07-23 at 23:44 +0800, Thierry Reding wrote:
>> * PGP Signed by an unknown key
>>
>> On Fri, Jul 19, 2013 at 05:25:24PM +0800, Joseph Lo wrote:
>>> There is a difference between GICv1 and v2 when CPU in power management
>>> mode (aka CPU power down on Tegra). For GICv1, IRQ/FIQ interrupt lines
>>> going to CPU are same lines which are also used for wake-interrupt.
>>> Therefore, we cannot disable the GIC CPU interface if we need to use same
>>> interrupts for CPU wake purpose. This creates a race condition for CPU
>>> power off entry. Also, in GICv1, disabling GICv1 CPU interface puts GICv1
>>> into bypass mode such that incoming legacy IRQ/FIQ are sent to CPU, which
>>> means disabling GIC CPU interface doesn't really disable IRQ/FIQ to CPU.
>>>
>>> GICv2 provides a wake IRQ/FIQ (for wake-event purpose), which are not
>>> disabled by GIC CPU interface. This is done by adding a bypass override
>>> capability when the interrupts are disabled at the CPU interface. To
>>> support this, there are four bits about IRQ/FIQ BypassDisable in CPU
>>> interface Control Register. When the IRQ/FIQ not being driver by the
>>> CPU interface, each interrupt output signal can be deasserted rather
>>> than being driven by the legacy interrupt input.
>>>
>>> So the wake-event can be used as wakeup signals to SoC (system power
>>> controller).
>>>
>>> To prevent race conditions and ensure proper interrupt routing on
>>> Cortex-A15 CPUs when they are power-gated, add a CPU PM notifier
>>> call-back to reprogram the GIC CPU interface on PM entry. The
>>> GIC CPU interface will be reset back to its normal state by
>>> the common GIC CPU PM exit callback when the CPU wakes up.
>>>
>>> Based on the work by: Scott Williams <scwilliams at nvidia.com>
>>>
>>> Signed-off-by: Joseph Lo <josephl at nvidia.com>
>>
>> Hi Joseph,
>>
>> We've had a rather long-standing issue with PCIe and MSI related to LP2
>> on Tegra20. I wonder if that's somehow related to this. Given that this
>> is marked as Tegra114 patch explicitly I suppose not, but it certainly
>> sounds very similar to the description above.
>>
> For LP2 + PCIe + MSI, I believe it need some other SW support if the HW
> really support MSI and runtime power down CPU domain that include SCU
> and BIU. According to TRM, the PCIe pass data through the unit to
> memory. I have no idea does the HW really support this function. I also
> need more information about this. 

Joseph, this is NVIDIA bug 1268311. Let's continue any discussion on
this topic internally (i.e. debug the problem) in that bug, until we
have something useful to report back upstream?


From robertcnelson at gmail.com  Wed Jul 24 13:05:16 2013
From: robertcnelson at gmail.com (Robert Nelson)
Date: Wed, 24 Jul 2013 12:05:16 -0500
Subject: ARM: dts: omap3-beagle-xm: fix compatible property
Message-ID: <CAOCHtYhN4oO=xq9LcjZHCAUbSwQgTs2zEUJND1G7EbPNJ1njpA@mail.gmail.com>

Hey Guys,

While working on the device tree for the xM i noticed this little
error on the compatible property...

Thoughts?

>From af8e3119ae2ee29bcf739d56168d6aaa3a2c8306 Mon Sep 17 00:00:00 2001
From: Robert Nelson <robertcnelson at gmail.com>
Date: Wed, 24 Jul 2013 12:02:11 -0500
Subject: [PATCH] ARM: dts: omap3-beagle-xm: fix compatible property

Signed-off-by: Robert Nelson <robertcnelson at gmail.com>
---
 arch/arm/boot/dts/omap3-beagle-xm.dts |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..0c514dc 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -11,7 +11,7 @@

 / {
 	model = "TI OMAP3 BeagleBoard xM";
-	compatible = "ti,omap3-beagle-xm, ti,omap3-beagle", "ti,omap3";
+	compatible = "ti,omap3-beagle-xm", "ti,omap3-beagle", "ti,omap3";

 	cpus {
 		cpu at 0 {
-- 
1.7.10.4


-- 
Robert Nelson
http://www.rcn-ee.com/


From festevam at gmail.com  Wed Jul 24 13:07:50 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 24 Jul 2013 14:07:50 -0300
Subject: [PATCH 1/2] ARM: dts: imx6qdl-sabresd: Add touchscreen support
In-Reply-To: <1374615677-18437-1-git-send-email-festevam@gmail.com>
References: <1374615677-18437-1-git-send-email-festevam@gmail.com>
Message-ID: <CAOMZO5Abj46xhabJGwm9C9EcsCSrPWs-FSFb4R+bwvKGKjx-Yw@mail.gmail.com>

On Tue, Jul 23, 2013 at 6:41 PM, Fabio Estevam <festevam at gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
>
> mx6 sabresd boards have a egalax touchscreen controller connected via i2c2.
>
> Add support for it.
>
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
> Hi Shawn,
>
> I don't have access to a sabresd board at the moment, so could not test this.

Ok, I got a sabresd now and I realized that max11801 driver is also
needed, so will work on it when time permits.

Regards,

Fabio Estevam


From Dave.Martin at arm.com  Wed Jul 24 13:16:14 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Wed, 24 Jul 2013 18:16:14 +0100
Subject: [PATCH 1/4] ARM: alignment: correctly decode instructions in BE8
 mode.
In-Reply-To: <1374510833-25716-2-git-send-email-ben.dooks@codethink.co.uk>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374510833-25716-2-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130724171613.GB4610@localhost.localdomain>

On Wed, Jul 24, 2013 at 11:27:59AM +0100, Ben Dooks wrote:
> If we are in BE8 mode, we must deal with the instruction stream being
> in LE order when data is being loaded in BE order. Ensure the data is
> swapped before processing to avoid thre following:
> 
> Change to using <asm/opcodes.h> to provide the necessary conversion
> functions to change the byte ordering.
> 
> Alignment trap: not handling instruction 030091e8 at [<80333e8c>]
> Unhandled fault: alignment exception (0x001) at 0xbfa09567
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---
>  arch/arm/mm/alignment.c |    8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
> index 6f4585b..f38145a 100644
> --- a/arch/arm/mm/alignment.c
> +++ b/arch/arm/mm/alignment.c
> @@ -25,6 +25,7 @@
>  #include <asm/cp15.h>
>  #include <asm/system_info.h>
>  #include <asm/unaligned.h>
> +#include <asm/opcodes.h>
>  
>  #include "fault.h"
>  
> @@ -762,21 +763,24 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
>  	if (thumb_mode(regs)) {
>  		u16 *ptr = (u16 *)(instrptr & ~1);
>  		fault = probe_kernel_address(ptr, tinstr);
> +		tinstr = __mem_to_opcode_thumb16(tinstr);
>  		if (!fault) {
>  			if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
>  			    IS_T32(tinstr)) {

If patching this file anyway, we could take the opportunity to retire
the local IS_T32() macro and use !__opcode_is_thumb16() instead.

>  				/* Thumb-2 32-bit */
>  				u16 tinst2 = 0;
>  				fault = probe_kernel_address(ptr + 1, tinst2);
> +				tinst2 = __mem_to_opcode_thumb16(tinst2);
>  				instr = (tinstr << 16) | tinst2;

Similarly, this could be __opcode_thumb32_compose(tinstr, tinst2).

>  				thumb2_32b = 1;
>  			} else {
>  				isize = 2;
> -				instr = thumb2arm(tinstr);

eh?  Is this is mis-edit?

Cheers
---Dave

>  			}
>  		}
> -	} else
> +	} else {
>  		fault = probe_kernel_address(instrptr, instr);
> +		instr = __mem_to_opcode_arm(instr);
> +	}
>  
>  	if (fault) {
>  		type = TYPE_FAULT;
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From will.deacon at arm.com  Wed Jul 24 13:18:26 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Jul 2013 18:18:26 +0100
Subject: Requirements for FDT load address on ARM
In-Reply-To: <alpine.LFD.2.03.1307241116200.15022@syhkavp.arg>
References: <1374677923.6623.194.camel@hastur.hellion.org.uk>
 <alpine.LFD.2.03.1307241116200.15022@syhkavp.arg>
Message-ID: <20130724171826.GX11072@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 04:24:48PM +0100, Nicolas Pitre wrote:
> On Wed, 24 Jul 2013, Ian Campbell wrote:
> 
> > [apologies if this is a repeat, I don't see it in the archives and at
> > least one CC'd recipient (Julien) didn't receive it either. Beasties in
> > our email server I expect...]
> > 
> > Are there any requirements about where the FDT may be loaded by the
> > bootloader?
> 
> It must be located where it is unlikely to be overwritten by the zImage 
> decompressor relocating itself.  Same goes for the initrd.
> 
> > I'm finding that if I load it "too high" I get a fault (the specifics
> > aren't that relevant but details are below).
> 
> Do you have commit 6f16f4998f98 in your kernel tree?
> 
> > FWIW with RAM from 0x8000000-0xffffffff and a kernel loaded at 
> > 0x80008000 "too high" means above somewhere around 0xaf800000.
> 
> Sorry, I don't understand the above sentence.
> 
> Is RAM actually starting at 0x08000000 ?  Note that the kernel must be 
> loaded in the first 128MB of RAM.
> 
> > I expect this is because the kernel doesn't use an explicit mapping of
> > the fdt but expects it to be within the RAM directly mapped by the
> > lowmem area (i.e. it uses phys_to_virt, since day one aka 93c02ab40ae6
> > "arm/dt: probe for platforms via the device tree").
> 
> The fdt is expected to be located in lowmem.  So yes, that's actually a 
> restriction.

FWIW, you could have a look at what I do in kvmtool. It's not perfect, but
I couldn't come up with anything better:

https://git.kernel.org/cgit/linux/kernel/git/will/kvmtool.git/tree/tools/kvm/arm/fdt.c?h=kvmtool/master

(see the load_flat_binary function)

Will


From nico at fluxnic.net  Wed Jul 24 13:22:46 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Wed, 24 Jul 2013 13:22:46 -0400 (EDT)
Subject: [PATCH 1/6] ARM: prefetch: remove redundant "cc" clobber
In-Reply-To: <20130724165820.GZ24642@n2100.arm.linux.org.uk>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-2-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231547010.15022@syhkavp.arg>
 <20130724101950.GG9629@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1307241205050.15022@syhkavp.arg>
 <20130724163530.GV11072@mudshark.cambridge.arm.com>
 <20130724165820.GZ24642@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1307241319410.15022@syhkavp.arg>

On Wed, 24 Jul 2013, Russell King - ARM Linux wrote:

> On Wed, Jul 24, 2013 at 05:35:31PM +0100, Will Deacon wrote:
> > On Wed, Jul 24, 2013 at 05:16:59PM +0100, Nicolas Pitre wrote:
> > > On Wed, 24 Jul 2013, Will Deacon wrote:
> > > > On Tue, Jul 23, 2013 at 08:48:11PM +0100, Nicolas Pitre wrote:
> > > > > You know the legacy reason why the cc clobber was there, right?
> > > > > It certainly doesn't apply anymore.
> > > > 
> > > > I was under the impression that it was due to ancient GCC behaviour and the "cc"
> > > > was there to prevent re-ordering. For interest, what are the specifics?
> > > 
> > > In the old days, you had to take care of the predicate for conditional 
> > > instructions in your inline asm code.  So for example, if you had:
> > > 
> > > 	if (foo)
> > > 		inline asm ("mov %0, #1" : "=r" (bar));
> > > 
> > > That wouldn't work most of the time because even if the if condition was 
> > > false, gcc would not branch over the inline asm code but expect you to 
> > > take care of the condition code.  That means the above needed to be 
> > > written as:
> > > 
> > > 	if (foo)
> > > 		inline asm ("mov%? %0, #1" : "=r" (bar));
> > > 
> > > Because having %? added all over the place was cumbersome, the 
> > > alternative was to add "cc" to the clobber list so gcc would then branch 
> > > across the inline asm when the condition is false.
> > > 
> > > But of course many people forgot about those subtle details quite often, 
> > > and then gcc was changed so inline asm was made non predicated.
> > 
> > Holy sh*t....
> > 
> > Next time I complain to the tools guys about inline asm, I'll count my
> > blessings so they don't try and resurrect anything as horrendous as what
> > you've just described.
> 
> And the result of its removal is all the horrid macro crap in asm/tlbflush.h
> to work around the lack of this feature - otherwise we end up with seven
> instances of:
> 
> 	tst
> 	bne	1f
> 	mcr
> 1:
> 
> for every call to a TLB function.  GCC _could_ have detected the lack of
> %? and the lack of "cc" clobber and either warned or implicitly branched
> around the block.  There was no need to completely remove the facility.

I agree.  gcc could have considered an inline asm block predicate safe 
whenever it contains a %?.  I even suggested this at the time.


Nicolas


From linux at arm.linux.org.uk  Wed Jul 24 13:23:22 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 24 Jul 2013 18:23:22 +0100
Subject: OMAP4430 SDP boot issues.. (Was Re: OMAP2430 SDP boot broken
 after Linus' rmk merge)
In-Reply-To: <51EFF571.3070106@ti.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724145237.GB21614@n2100.arm.linux.org.uk>
 <51EFF571.3070106@ti.com>
Message-ID: <20130724172321.GC21614@n2100.arm.linux.org.uk>

On Wed, Jul 24, 2013 at 11:40:33AM -0400, Santosh Shilimkar wrote:
> On Wednesday 24 July 2013 10:52 AM, Russell King - ARM Linux wrote:
> > I also continue to be disappointed by the lack of things working on the
> > 4430 - it's been a number of years now and _still_ the on-board LCDs do
> > not work.  People have tried to blame that on hardware faults and the
> > like, but they're just being idiotic when they say stuff like that.  It
> > can't be hardware faults when the kernel supplied with the board is able
> > to make them work to the extent that userspace can play back video on all
> > three output devices simultaneously, without hiccup or any imperfection.
> > I don't know whether it's just that the backlight support isn't working
> > or what - because any information on the 4430 seems to be a tightly
> > controlled secret that only a few select people are permitted to know
> > about.  As far as I'm concerned, much of the hardware is a black box to
> > me.
> > 
> On the display related issues, Tomi and Archit have been sorting out
> issue but am not sure about the current state. If the pre-built binaries
> video playback works means your hardware seems to be fine.

Just let me be absolutely crystal clear about this: the on-board LCDs
have _never_ worked with a mainline kernel, but they did work with the
kernel which originally came with the board with the original 4430 SoC.
I can right now put the original 4430 SoC back on the board and boot
using the kernel which is still on the SD card and they will work.

Even with the original 4430 SoC and mainline kernels, they have never
worked.

I tried it back and forth several times, but even with this, the
explanation was always "your hardware must be faulty".  And then the wrong
voltage levels was found which was preventing the LCD modules from even
being recognised... but still, no sign of life on the LCD panels.

It may be that there's some error in the kernel configuration I'm building.
I don't know, because I have _no_ idea what hardware is involved in
bringing the LCDs online.  Like I said above, the 4430SDP board is just
a black box.  I am totally reliant on others telling me what the right
config options are supposed to be and fixing problems when things don't
work.

With the lack of information on this board, all I can do when things don't
work is whinge and moan at people.  I am powerless to debug the problems
myself, even if they're a simple misconfiguration.

Is there information available on the 4430SDP?  Is there any reason I
can't have access to it?


From Dave.Martin at arm.com  Wed Jul 24 13:34:35 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Wed, 24 Jul 2013 18:34:35 +0100
Subject: [PATCH 2/4] ARM: traps: use <asm/opcodes.h> to get correct
 instruction order
In-Reply-To: <1374510833-25716-3-git-send-email-ben.dooks@codethink.co.uk>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374510833-25716-3-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130724173435.GC4610@localhost.localdomain>

On Mon, Jul 22, 2013 at 05:33:51PM +0100, Ben Dooks wrote:
> The trap handler needs to take into account the endian configuration of
> the system when loading instructions. Use <asm/opcodes.h> to provide the
> necessary conversion functions.
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---
>  arch/arm/kernel/traps.c |   10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index 1c08911..0a56e13 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -34,6 +34,7 @@
>  #include <asm/unwind.h>
>  #include <asm/tls.h>
>  #include <asm/system_misc.h>
> +#include <asm/opcodes.h>
>  
>  #include "signal.h"

Looks like is_valid_bugaddr() might need fixing too?

That will need __mem_to_opcode_thumb16() or __mem_to_opcode_arm()
depending on CONFIG_THUMB2_KERNEL.

>  
> @@ -411,23 +412,24 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
>  	if (processor_mode(regs) == SVC_MODE) {
>  #ifdef CONFIG_THUMB2_KERNEL
>  		if (thumb_mode(regs)) {
> -			instr = ((u16 *)pc)[0];
> +			instr = __mem_to_opcode_thumb16(((u16 *)pc)[0]);
>  			if (is_wide_instruction(instr)) {
>  				instr <<= 16;
> -				instr |= ((u16 *)pc)[1];
> +				instr |= __mem_to_opcode_thumb16(((u16 *)pc)[1]);

Could use __opcode_thumb32_compose(), in which case it might look like

			if (is_wide_instruction(instr)) {
				unsigned int instr2 = __mem_to_opcode_thumb16(
					((u16 *)pc)[1]);
				instr = __opcode_thumb32_compose(instr, instr2);

(Hmmm, I just noticed that is_wide_instruction and __opcode_is_thumb16()
kinda duplicate each other.  Could change that too, but it would look
more like pointless churn...  is_wide_instruction() is used in a fair
few places already.)

>  			}
>  		} else
>  #endif
> -			instr = *(u32 *) pc;
> +			instr = __mem_to_opcode_arm(*(u32 *) pc);
>  	} else if (thumb_mode(regs)) {
>  		if (get_user(instr, (u16 __user *)pc))
>  			goto die_sig;
> +		instr = __mem_to_opcode_thumb16(instr);
>  		if (is_wide_instruction(instr)) {
>  			unsigned int instr2;
>  			if (get_user(instr2, (u16 __user *)pc+1))
>  				goto die_sig;
>  			instr <<= 16;
> -			instr |= instr2;
> +			instr |= __mem_to_opcode_thumb16(instr2);
>  		}
>  	} else if (get_user(instr, (u32 __user *)pc)) {

This also needs mem-to-opcode'ing.

Cheers
---Dave


From Dave.Martin at arm.com  Wed Jul 24 13:52:21 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Wed, 24 Jul 2013 18:52:21 +0100
Subject: [PATCH 3/4] ARM: module: correctly relocate instructions in BE8
In-Reply-To: <1374510833-25716-4-git-send-email-ben.dooks@codethink.co.uk>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374510833-25716-4-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130724175221.GD4610@localhost.localdomain>

On Mon, Jul 22, 2013 at 05:33:52PM +0100, Ben Dooks wrote:
> When in BE8 mode, our instructions are not in the same ordering as the
> data, so use <asm/opcodes.h> to take this into account.
> 
> Note, also requires modules to be built --be8
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---
>  arch/arm/kernel/module.c |   57 +++++++++++++++++++++++++++-------------------
>  1 file changed, 34 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
> index 1e9be5d..7e13787 100644
> --- a/arch/arm/kernel/module.c
> +++ b/arch/arm/kernel/module.c
> @@ -24,6 +24,7 @@
>  #include <asm/sections.h>
>  #include <asm/smp_plat.h>
>  #include <asm/unwind.h>
> +#include <asm/opcodes.h>
>  
>  #ifdef CONFIG_XIP_KERNEL
>  /*
> @@ -60,6 +61,7 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
>  		Elf32_Sym *sym;
>  		const char *symname;
>  		s32 offset;
> +		u32 tmp;
>  #ifdef CONFIG_THUMB2_KERNEL
>  		u32 upper, lower, sign, j1, j2;
>  #endif
> @@ -95,7 +97,8 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
>  		case R_ARM_PC24:
>  		case R_ARM_CALL:
>  		case R_ARM_JUMP24:
> -			offset = (*(u32 *)loc & 0x00ffffff) << 2;
> +			offset = __mem_to_opcode_arm(*(u32 *)loc);
> +			offset = (offset & 0x00ffffff) << 2;
>  			if (offset & 0x02000000)
>  				offset -= 0x04000000;
>  
> @@ -111,9 +114,10 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
>  			}
>  
>  			offset >>= 2;
> +			offset &= 0x00ffffff;
>  
> -			*(u32 *)loc &= 0xff000000;
> -			*(u32 *)loc |= offset & 0x00ffffff;
> +			*(u32 *)loc &= __opcode_to_mem_arm(0xff000000);
> +			*(u32 *)loc |= __opcode_to_mem_arm(offset);

Here it's assumed that

__opcode_to_mem_arm(x | y) == __opcode_to_mem_arm(x) | __opcode_to_mem_arm(x)

(and related rules)

Since the macros really do just shuffle bits, that does work, but it may
be a bit cleaner to build on the instruction in canonical representation
and use __opcode_to_mem_arm() just once to avoid such subtleties.

Then we can simply treat instructions in memory as opaque data, which all
flows into the code through __mem_to_opcode*() and back out through
__opcode_to_mem*().

(analogous to ntohs() ... do something useful ... htons() etc.)


So:
			tmp = __mem_to_opcode_arm(*(u32 *)loc);
			tmp = (tmp & 0xff000000) | offset;
			*(u32 *)loc = __opcode_to_mem_arm(tmp);

I think that's cleaner, but it's open to debate.  GCC might generate
slightly inferior code, depending on how clever it is ... but this
isn't a fast path.


The same style could be applied to all the relocations here.  It
could help to avoid confusion about which byte order a particular
vairable or literal uses -- i.e., ARM ARM order is used for
everything except the contents of memory.


I have to abort this review now ... I'll try to look at the rest
tomorrow.

Cheers
---Dave

>  			break;
>  
>  	       case R_ARM_V4BX:
> @@ -121,8 +125,8 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
>  			* other bits to re-code instruction as
>  			* MOV PC,Rm.
>  			*/
> -		       *(u32 *)loc &= 0xf000000f;
> -		       *(u32 *)loc |= 0x01a0f000;
> +		       *(u32 *)loc &= __opcode_to_mem_arm(0xf000000f);
> +		       *(u32 *)loc |= __opcode_to_mem_arm(0x01a0f000);
>  		       break;
>  
>  		case R_ARM_PREL31:
> @@ -132,7 +136,7 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
>  
>  		case R_ARM_MOVW_ABS_NC:
>  		case R_ARM_MOVT_ABS:
> -			offset = *(u32 *)loc;
> +			offset = tmp = __mem_to_opcode_arm(*(u32 *)loc);
>  			offset = ((offset & 0xf0000) >> 4) | (offset & 0xfff);
>  			offset = (offset ^ 0x8000) - 0x8000;
>  
> @@ -140,16 +144,18 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
>  			if (ELF32_R_TYPE(rel->r_info) == R_ARM_MOVT_ABS)
>  				offset >>= 16;
>  
> -			*(u32 *)loc &= 0xfff0f000;
> -			*(u32 *)loc |= ((offset & 0xf000) << 4) |
> -					(offset & 0x0fff);
> +			tmp &= 0xfff0f000;
> +			tmp |= ((offset & 0xf000) << 4) |
> +				(offset & 0x0fff);
> +
> +			*(u32 *)loc = __opcode_to_mem_arm(tmp);
>  			break;
>  
>  #ifdef CONFIG_THUMB2_KERNEL
>  		case R_ARM_THM_CALL:
>  		case R_ARM_THM_JUMP24:
> -			upper = *(u16 *)loc;
> -			lower = *(u16 *)(loc + 2);
> +			upper = __mem_to_opcode_thumb16(*(u16 *)loc);
> +			lower = __mem_to_opcode_thumb16(*(u16 *)(loc + 2));
>  
>  			/*
>  			 * 25 bit signed address range (Thumb-2 BL and B.W
> @@ -198,17 +204,20 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
>  			sign = (offset >> 24) & 1;
>  			j1 = sign ^ (~(offset >> 23) & 1);
>  			j2 = sign ^ (~(offset >> 22) & 1);
> -			*(u16 *)loc = (u16)((upper & 0xf800) | (sign << 10) |
> +			upper = (u16)((upper & 0xf800) | (sign << 10) |
>  					    ((offset >> 12) & 0x03ff));
> -			*(u16 *)(loc + 2) = (u16)((lower & 0xd000) |
> -						  (j1 << 13) | (j2 << 11) |
> -						  ((offset >> 1) & 0x07ff));
> +			lower = (u16)((lower & 0xd000) |
> +				      (j1 << 13) | (j2 << 11) |
> +				      ((offset >> 1) & 0x07ff));
> +
> +			*(u16 *)loc = __opcode_to_mem_thumb16(upper);
> +			*(u16 *)(loc + 2) = __opcode_to_mem_thumb16(lower);
>  			break;
>  
>  		case R_ARM_THM_MOVW_ABS_NC:
>  		case R_ARM_THM_MOVT_ABS:
> -			upper = *(u16 *)loc;
> -			lower = *(u16 *)(loc + 2);
> +			upper = __mem_to_opcode_thumb16(*(u16 *)loc);
> +			lower = __mem_to_opcode_thumb16(*(u16 *)(loc + 2));
>  
>  			/*
>  			 * MOVT/MOVW instructions encoding in Thumb-2:
> @@ -229,12 +238,14 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
>  			if (ELF32_R_TYPE(rel->r_info) == R_ARM_THM_MOVT_ABS)
>  				offset >>= 16;
>  
> -			*(u16 *)loc = (u16)((upper & 0xfbf0) |
> -					    ((offset & 0xf000) >> 12) |
> -					    ((offset & 0x0800) >> 1));
> -			*(u16 *)(loc + 2) = (u16)((lower & 0x8f00) |
> -						  ((offset & 0x0700) << 4) |
> -						  (offset & 0x00ff));
> +			upper = (u16)((upper & 0xfbf0) |
> +				      ((offset & 0xf000) >> 12) |
> +				      ((offset & 0x0800) >> 1));
> +			lower = (u16)((lower & 0x8f00) |
> +				      ((offset & 0x0700) << 4) |
> +				      (offset & 0x00ff));
> +			*(u16 *)loc = __opcode_to_mem_thumb16(upper);
> +			*(u16 *)(loc + 2) = __opcode_to_mem_thumb16(lower);
>  			break;
>  #endif
>  
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From santosh.shilimkar at ti.com  Wed Jul 24 14:17:07 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 24 Jul 2013 14:17:07 -0400
Subject: OMAP4430 SDP boot issues.. (Was Re: OMAP2430 SDP boot broken
 after Linus' rmk merge)
In-Reply-To: <20130724172321.GC21614@n2100.arm.linux.org.uk>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724145237.GB21614@n2100.arm.linux.org.uk>
 <51EFF571.3070106@ti.com> <20130724172321.GC21614@n2100.arm.linux.org.uk>
Message-ID: <51F01A23.2060502@ti.com>

On Wednesday 24 July 2013 01:23 PM, Russell King - ARM Linux wrote:
> On Wed, Jul 24, 2013 at 11:40:33AM -0400, Santosh Shilimkar wrote:
>> On Wednesday 24 July 2013 10:52 AM, Russell King - ARM Linux wrote:
>>> I also continue to be disappointed by the lack of things working on the
>>> 4430 - it's been a number of years now and _still_ the on-board LCDs do
>>> not work.  People have tried to blame that on hardware faults and the
>>> like, but they're just being idiotic when they say stuff like that.  It
>>> can't be hardware faults when the kernel supplied with the board is able
>>> to make them work to the extent that userspace can play back video on all
>>> three output devices simultaneously, without hiccup or any imperfection.
>>> I don't know whether it's just that the backlight support isn't working
>>> or what - because any information on the 4430 seems to be a tightly
>>> controlled secret that only a few select people are permitted to know
>>> about.  As far as I'm concerned, much of the hardware is a black box to
>>> me.
>>>
>> On the display related issues, Tomi and Archit have been sorting out
>> issue but am not sure about the current state. If the pre-built binaries
>> video playback works means your hardware seems to be fine.
> 
> Just let me be absolutely crystal clear about this: the on-board LCDs
> have _never_ worked with a mainline kernel, but they did work with the
> kernel which originally came with the board with the original 4430 SoC.
> I can right now put the original 4430 SoC back on the board and boot
> using the kernel which is still on the SD card and they will work.
> 
> Even with the original 4430 SoC and mainline kernels, they have never
> worked.
> 
> I tried it back and forth several times, but even with this, the
> explanation was always "your hardware must be faulty".  And then the wrong
> voltage levels was found which was preventing the LCD modules from even
> being recognised... but still, no sign of life on the LCD panels.
> 
> It may be that there's some error in the kernel configuration I'm building.
> I don't know, because I have _no_ idea what hardware is involved in
> bringing the LCDs online.  Like I said above, the 4430SDP board is just
> a black box.  I am totally reliant on others telling me what the right
> config options are supposed to be and fixing problems when things don't
> work.
> 
> With the lack of information on this board, all I can do when things don't
> work is whinge and moan at people.  I am powerless to debug the problems
> myself, even if they're a simple misconfiguration.
> 
> Is there information available on the 4430SDP?  Is there any reason I
> can't have access to it?
> 
I haven't come across the information which is available on the web.
Let me check if there are schematics which i can send across to
you.

Regards,
Santosh





From jason at lakedaemon.net  Wed Jul 24 14:19:24 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 24 Jul 2013 14:19:24 -0400
Subject: Location for a kind of GPIO bus driver
In-Reply-To: <20130723151834.GJ9916@kw.sim.vm.gnt>
References: <20130723151834.GJ9916@kw.sim.vm.gnt>
Message-ID: <20130724181924.GI19736@titan.lakedaemon.net>

On Tue, Jul 23, 2013 at 05:18:34PM +0200, Simon Guinot wrote:
> Hi,
> 
> I am currently working on converting the LED driver leds-netxbig to DT.
> Doing so, I am also considering to move the GPIO extension bus functions
> (which are currently parts of leds-netxbig) into a separate driver.
> 
> On the LaCie "Big Network" board family (netxbig), the LEDs are
> controlled by a CPLD. In turn, the CPLD can be configured (mostly the
> LEDs modes) through a kind of parallel GPIO bus, called GPIO extension
> bus. Two registers (address and data) are exposed. Each of them is made
> up of several GPIOs. An extra GPIO is used to notify the CPLD that the
> registers have been updated. The leds-netxbig driver uses some dedicated
> functions (prefixed by "gpio_ext_") to handle the GPIO bus extension.
> 
> On the latest "Big Network" boards, this bus is also used to enable the
> PM wakeup sources: the CPLD can be asked to keep powered some devices
> (as the RTC or the Ethernet PHY) while the board is down. I think it
> could be nice to expose this feature to the userland. That's why I am
> thinking about moving the GPIO extension bus support into a separate
> driver. The problem is that I can't find a proper location for a such
> driver. AFAIK, it doesn't fit with anything existing supported by Linux.
> Maybe I should consider drivers/bus ? Or even drivers/misc ?

iiuc, the CPLD is more of gpio multiplexer/expander.  Have you seen

  66bcb58 arm: mvebu: enable gpio expander over i2c on Mirabox platform

?  And the corresponding driver, drivers/gpio/gpio-pca953x.c?

I would try drivers/gpio.  If there are complaints, it should be trivial
to move it in a new version of the series.

Is there any reason why the new capabilities in the "Big Network" boards
couldn't be covered by gpio-regulator?

thx,

Jason.


From robherring2 at gmail.com  Wed Jul 24 14:31:00 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 24 Jul 2013 13:31:00 -0500
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
Message-ID: <51F01D64.9060609@gmail.com>

On 07/24/2013 10:27 AM, Olof Johansson wrote:
> Every now and then I come across a binding that's just done Wrong(tm),
> merged through a submaintainer tree and hasn't seen proper review --
> if it had, it wouldn't look the way it does. It's something we're
> starting to address now since there's more people stepping up to be
> maintainers, but there's a backlog of bad bindings already merged.
> 
> Often they are produced by translating the platform_data structures
> directly over into device-tree properties without consideration to
> describing the hardware or usual conventions, using key/value pairs
> instead of boolean properties, etc.
> 
> Getting involved in cleaning up these kind of bindings is a great way
> to learn "the ways of device tree" for someone that has interest in
> that.
> 
> Latest find in this area is the Maxim 8925 bindings, that I came
> across since they caused a compile warning on some defconfig. I'll
> post a patch to address the warning but if someone else feels like
> fixing the bindings on top of it that would be appreciated!

Are they documented typically? Can we at a minimum update the
documentation with a big fat warning to not use or propagate the crap.
Or move the binding doc file to a fixme directory.

Rob



From ian.campbell at citrix.com  Wed Jul 24 14:31:45 2013
From: ian.campbell at citrix.com (Ian Campbell)
Date: Wed, 24 Jul 2013 19:31:45 +0100
Subject: Requirements for FDT load address on ARM
In-Reply-To: <alpine.LFD.2.03.1307241116200.15022@syhkavp.arg>
References: <1374677923.6623.194.camel@hastur.hellion.org.uk>
 <alpine.LFD.2.03.1307241116200.15022@syhkavp.arg>
Message-ID: <1374690705.30195.18.camel@hastur.hellion.org.uk>

On Wed, 2013-07-24 at 11:24 -0400, Nicolas Pitre wrote:
> On Wed, 24 Jul 2013, Ian Campbell wrote:
> 
> > [apologies if this is a repeat, I don't see it in the archives and at
> > least one CC'd recipient (Julien) didn't receive it either. Beasties in
> > our email server I expect...]
> > 
> > Are there any requirements about where the FDT may be loaded by the
> > bootloader?
> 
> It must be located where it is unlikely to be overwritten by the zImage 
> decompressor relocating itself.  Same goes for the initrd.

Right. That's a bit hard to determine programmaticaly from a bootloader
though :-(

> > I'm finding that if I load it "too high" I get a fault (the specifics
> > aren't that relevant but details are below).
> 
> Do you have commit 6f16f4998f98 in your kernel tree?

It doesn't look like I do. The symptoms I'm seeing could well be
explained by that lack.

> > FWIW with RAM from 0x8000000-0xffffffff and a kernel loaded at 
> > 0x80008000 "too high" means above somewhere around 0xaf800000.
> 
> Sorry, I don't understand the above sentence.
> 
> Is RAM actually starting at 0x08000000 ?

Sorry, missed a zero, RAM starts at 0x80000000.

What I was trying to say that in my empirical experience loading the fdt
"too high" meant above 0xaf800000. Not actually terribly useful data
TBH.

>   Note that the kernel must be 
> loaded in the first 128MB of RAM.

> > I expect this is because the kernel doesn't use an explicit mapping of
> > the fdt but expects it to be within the RAM directly mapped by the
> > lowmem area (i.e. it uses phys_to_virt, since day one aka 93c02ab40ae6
> > "arm/dt: probe for platforms via the device tree").
> 
> The fdt is expected to be located in lowmem.  So yes, that's actually a 
> restriction.

OK, that's good to know.

> > This effectively
> > limits the FDT to being within the first ~700MB (give or take based
> > on .config etc, I suppose <500MB is a pretty safe rule of thumb). Is
> > this expected or is it actually not intentional and the kernel should
> > really be using an explicit mapping here? Should I send a patch against
> > Documentation/arm/Booting?
> 
> Yes please.

OK I'll try and put something together which I hope won't be too
drastically wrong.

Ian.



From ian.campbell at citrix.com  Wed Jul 24 14:32:09 2013
From: ian.campbell at citrix.com (Ian Campbell)
Date: Wed, 24 Jul 2013 19:32:09 +0100
Subject: Requirements for FDT load address on ARM
In-Reply-To: <20130724171826.GX11072@mudshark.cambridge.arm.com>
References: <1374677923.6623.194.camel@hastur.hellion.org.uk>
 <alpine.LFD.2.03.1307241116200.15022@syhkavp.arg>
 <20130724171826.GX11072@mudshark.cambridge.arm.com>
Message-ID: <1374690729.30195.21.camel@hastur.hellion.org.uk>

On Wed, 2013-07-24 at 18:18 +0100, Will Deacon wrote:
> FWIW, you could have a look at what I do in kvmtool. It's not perfect, but
> I couldn't come up with anything better:
> 
> https://git.kernel.org/cgit/linux/kernel/git/will/kvmtool.git/tree/tools/kvm/arm/fdt.c?h=kvmtool/master
> 
> (see the load_flat_binary function)

Thanks, it's most probably a good idea for us to do the same thing.

Ian.



From arnd at arndb.de  Wed Jul 24 14:32:03 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Jul 2013 20:32:03 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <5977067.8rykRgjgre@flatron>
References: <Pine.LNX.4.44L0.1307231708020.1304-100000@iolanthe.rowland.org>
 <5977067.8rykRgjgre@flatron>
Message-ID: <201307242032.03597.arnd@arndb.de>

On Tuesday 23 July 2013, Tomasz Figa wrote:
> On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
> > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > > Where would you want to have those phy_address arrays stored? There
> > > are no board files when booting with DT. Not even saying that you
> > > don't need to use any hacky schemes like this when you have DT that
> > > nicely specifies relations between devices.
> > 
> > If everybody agrees DT has a nice scheme for specifying relations
> > between devices, why not use that same scheme in the PHY core?
> 
> It is already used, for cases when consumer device has a DT node attached. 
> In non-DT case this kind lookup translates loosely to something that is 
> being done in regulator framework - you can't bind devices by pointers, 
> because you don't have those pointers, so you need to use device names.
> 

Sorry for jumping in to the middle of the discussion, but why does a *new*
framework even bother defining an interface for board files?

Can't we just drop any interfaces for platform data passing in the phy
framework and put the burden of adding those to anyone who actually needs
them? All the platforms we are concerned with here (exynos and omap,
plus new platforms) can be booted using DT anyway.

	Arnd


From sergei.shtylyov at cogentembedded.com  Wed Jul 24 14:33:20 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 24 Jul 2013 22:33:20 +0400
Subject: [PATCH 1/2] ARM i.MX6Q: dts: Enable SPI NOR flash on Phytec
 phyFLEX-i.MX6 Ouad module
In-Reply-To: <1374683729-13438-1-git-send-email-p.zabel@pengutronix.de>
References: <1374683729-13438-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <51F01DF0.3030207@cogentembedded.com>

Hello.

On 07/24/2013 08:35 PM, Philipp Zabel wrote:

> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> ---
>   arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)

> diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
> index f5e1981..5113d29 100644
> --- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
> +++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
> @@ -20,6 +20,20 @@
>   	};
>   };
>
> +&ecspi3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_ecspi3_1>;
> +	status = "okay";
> +	fsl,spi-num-chipselects = <1>;
> +	cs-gpios = <&gpio4 24 0>;
> +
> +	flash: m25p80 at 0 {

    Quoting the EPAPR spec [1]: "The name of a node should be somewhat 
generic, reflecting the function of the device and not its precise programming 
model. If appropriate, the name should be one of the following choices:
[...]
    - flash
[...]
"

[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei



From sboyd at codeaurora.org  Wed Jul 24 14:37:27 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 11:37:27 -0700
Subject: [PATCH 0/4] msm_serial fixes and improvements
Message-ID: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>

Here are a couple fixes and improvements to the msm_serial
driver. The first two patches fix a bug on UARTDM devices and
silence sparse warnings. The last two patches improve the baud
code detection and increase the throughput on UARTDM devices.

After this it is rather trivial to add support for newer UARTDM
devices via new compatible fields.

Stephen Boyd (4):
  msm_serial: Fix NUL byte output on UARTDM
  msm_serial: Fix sparse warnings
  msm_serial: Make baud_code detection more dynamic
  msm_serial: Send more than 1 character at a time on UARTDM

 drivers/tty/serial/msm_serial.c | 180 ++++++++++++++++++++--------------------
 drivers/tty/serial/msm_serial.h |  19 ++---
 2 files changed, 97 insertions(+), 102 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 14:37:28 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 11:37:28 -0700
Subject: [PATCH 1/4] msm_serial: Fix NUL byte output on UARTDM
In-Reply-To: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
References: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374691051-28544-2-git-send-email-sboyd@codeaurora.org>

UARTDM serial devices require us to wait for the entire TX fifo
to drain before we can change the contents of the NCF_TX
register. Furthermore, if we write any characters to the TX fifo
within the same clock cycle of changing the NCF_TX register the
NCF_TX register won't latch properly.

To fix these issues we should read back the NCF_TX register to
delay any TX fifo accesses by a clock cycle and we should wait
for the TX fifo to drain (instead of just waiting for the fifo to
be ready to receive more characters). Failure to do so leads to
random NUL bytes interspersed in the output.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/tty/serial/msm_serial.c | 14 +++++++++-----
 drivers/tty/serial/msm_serial.h |  1 +
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index 2c6cfb3..fa3fc67 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -50,11 +50,14 @@ struct msm_port {
 	unsigned int		old_snap_state;
 };
 
-static inline void wait_for_xmitr(struct uart_port *port, int bits)
+static inline void wait_for_xmitr(struct uart_port *port)
 {
-	if (!(msm_read(port, UART_SR) & UART_SR_TX_EMPTY))
-		while ((msm_read(port, UART_ISR) & bits) != bits)
-			cpu_relax();
+	while (!(msm_read(port, UART_SR) & UART_SR_TX_EMPTY)) {
+		if (msm_read(port, UART_ISR) & UART_ISR_TX_READY)
+			break;
+		udelay(1);
+	}
+	msm_write(port, UART_CR_CMD_RESET_TX_READY, UART_CR);
 }
 
 static void msm_stop_tx(struct uart_port *port)
@@ -194,8 +197,9 @@ static void handle_rx(struct uart_port *port)
 
 static void reset_dm_count(struct uart_port *port)
 {
-	wait_for_xmitr(port, UART_ISR_TX_READY);
+	wait_for_xmitr(port);
 	msm_write(port, 1, UARTDM_NCF_TX);
+	msm_read(port, UARTDM_NCF_TX);
 }
 
 static void handle_tx(struct uart_port *port)
diff --git a/drivers/tty/serial/msm_serial.h b/drivers/tty/serial/msm_serial.h
index e4acef5..15c186e 100644
--- a/drivers/tty/serial/msm_serial.h
+++ b/drivers/tty/serial/msm_serial.h
@@ -71,6 +71,7 @@
 #define UART_CR_CMD_RESET_RFR		(14 << 4)
 #define UART_CR_CMD_PROTECTION_EN	(16 << 4)
 #define UART_CR_CMD_STALE_EVENT_ENABLE	(80 << 4)
+#define UART_CR_CMD_RESET_TX_READY	(3 << 8)
 #define UART_CR_TX_DISABLE		(1 << 3)
 #define UART_CR_TX_ENABLE		(1 << 2)
 #define UART_CR_RX_DISABLE		(1 << 1)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 14:37:29 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 11:37:29 -0700
Subject: [PATCH 2/4] msm_serial: Fix sparse warnings
In-Reply-To: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
References: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374691051-28544-3-git-send-email-sboyd@codeaurora.org>

drivers/tty/serial/msm_serial.c:302:6: warning: symbol 'msm_set_mctrl' was
not declared. Should it be static?
drivers/tty/serial/msm_serial.c:597:17: warning: incorrect type in argument 2
(different address spaces)
drivers/tty/serial/msm_serial.c:597:17: expected void volatile [noderef] <asn:2>*addr
drivers/tty/serial/msm_serial.c:597:17: got unsigned int *
drivers/tty/serial/msm_serial.c:608:33: warning: incorrect type in argument 1
(different address spaces)
drivers/tty/serial/msm_serial.c:608:33: expected void volatile [noderef] <asn:2>*addr
drivers/tty/serial/msm_serial.c:608:33: got unsigned int *gsbi_base
drivers/tty/serial/msm_serial.c:648:37: warning: incorrect type in assignment
(different address spaces)
drivers/tty/serial/msm_serial.c:648:37: expected unsigned int *gsbi_base
drivers/tty/serial/msm_serial.c:648:37: got void [noderef] <asn:2>*

Mark the ioremapped memory as __iomem and use writel instead of
iowrite because we're not dealing with PCI devices. Also, mark
msm_set_mctrl() static because it isn't used outside this file.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/tty/serial/msm_serial.c | 17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index fa3fc67..cab4105 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -45,7 +45,7 @@ struct msm_port {
 	struct clk		*clk;
 	struct clk		*pclk;
 	unsigned int		imr;
-	unsigned int            *gsbi_base;
+	void __iomem		*gsbi_base;
 	int			is_uartdm;
 	unsigned int		old_snap_state;
 };
@@ -299,7 +299,7 @@ static void msm_reset(struct uart_port *port)
 	msm_write(port, UART_CR_CMD_SET_RFR, UART_CR);
 }
 
-void msm_set_mctrl(struct uart_port *port, unsigned int mctrl)
+static void msm_set_mctrl(struct uart_port *port, unsigned int mctrl)
 {
 	unsigned int mr;
 	mr = msm_read(port, UART_MR1);
@@ -593,12 +593,10 @@ static void msm_release_port(struct uart_port *port)
 	port->membase = NULL;
 
 	if (msm_port->gsbi_base) {
-		iowrite32(GSBI_PROTOCOL_IDLE, msm_port->gsbi_base +
-			  GSBI_CONTROL);
-
-		gsbi_resource = platform_get_resource(pdev,
-							IORESOURCE_MEM, 1);
+		writel_relaxed(GSBI_PROTOCOL_IDLE,
+				msm_port->gsbi_base + GSBI_CONTROL);
 
+		gsbi_resource = platform_get_resource(pdev, IORESOURCE_MEM, 1);
 		if (unlikely(!gsbi_resource))
 			return;
 
@@ -670,10 +668,9 @@ static void msm_config_port(struct uart_port *port, int flags)
 		if (ret)
 			return;
 	}
-
 	if (msm_port->is_uartdm)
-		iowrite32(GSBI_PROTOCOL_UART, msm_port->gsbi_base +
-			  GSBI_CONTROL);
+		writel_relaxed(GSBI_PROTOCOL_UART,
+				msm_port->gsbi_base + GSBI_CONTROL);
 }
 
 static int msm_verify_port(struct uart_port *port, struct serial_struct *ser)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 14:37:31 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 11:37:31 -0700
Subject: [PATCH 4/4] msm_serial: Send more than 1 character at a time on UARTDM
In-Reply-To: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
References: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374691051-28544-5-git-send-email-sboyd@codeaurora.org>

UARTDM cores have a TX fifo that can accept more than one
character per register write, but the msm_serial driver currently
only supports 1 character mode. Add support for this mode of operation
to speed up the transmit path on DM devices.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/tty/serial/msm_serial.c | 51 ++++++++++++++++++++++++++---------------
 1 file changed, 32 insertions(+), 19 deletions(-)

diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index cef8f40..97642ec 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -195,10 +195,10 @@ static void handle_rx(struct uart_port *port)
 	tty_flip_buffer_push(tport);
 }
 
-static void reset_dm_count(struct uart_port *port)
+static void reset_dm_count(struct uart_port *port, int count)
 {
 	wait_for_xmitr(port);
-	msm_write(port, 1, UARTDM_NCF_TX);
+	msm_write(port, count, UARTDM_NCF_TX);
 	msm_read(port, UARTDM_NCF_TX);
 }
 
@@ -206,39 +206,52 @@ static void handle_tx(struct uart_port *port)
 {
 	struct circ_buf *xmit = &port->state->xmit;
 	struct msm_port *msm_port = UART_TO_MSM(port);
-	int sent_tx;
+	unsigned int tx_count, num_chars;
+	unsigned int tf_pointer = 0;
+
+	tx_count = uart_circ_chars_pending(xmit);
+	tx_count = min3(tx_count, (unsigned int)UART_XMIT_SIZE - xmit->tail,
+			port->fifosize);
 
 	if (port->x_char) {
 		if (msm_port->is_uartdm)
-			reset_dm_count(port);
+			reset_dm_count(port, tx_count + 1);
 
 		msm_write(port, port->x_char,
 			  msm_port->is_uartdm ? UARTDM_TF : UART_TF);
 		port->icount.tx++;
 		port->x_char = 0;
+	} else if (tx_count && msm_port->is_uartdm) {
+		reset_dm_count(port, tx_count);
 	}
 
-	if (msm_port->is_uartdm)
-		reset_dm_count(port);
+	while (tf_pointer < tx_count) {
+		int i;
+		char buf[4] = { 0 };
+		unsigned int *bf = (unsigned int *)&buf;
 
-	while (msm_read(port, UART_SR) & UART_SR_TX_READY) {
-		if (uart_circ_empty(xmit)) {
-			/* disable tx interrupts */
-			msm_port->imr &= ~UART_IMR_TXLEV;
-			msm_write(port, msm_port->imr, UART_IMR);
+		if (!(msm_read(port, UART_SR) & UART_SR_TX_READY))
 			break;
-		}
-		msm_write(port, xmit->buf[xmit->tail],
-			  msm_port->is_uartdm ? UARTDM_TF : UART_TF);
 
 		if (msm_port->is_uartdm)
-			reset_dm_count(port);
+			num_chars = min(tx_count - tf_pointer, sizeof(buf));
+		else
+			num_chars = 1;
 
-		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
-		port->icount.tx++;
-		sent_tx = 1;
+		for (i = 0; i < num_chars; i++) {
+			buf[i] = xmit->buf[xmit->tail + i];
+			port->icount.tx++;
+		}
+
+		msm_write(port, *bf, msm_port->is_uartdm ? UARTDM_TF : UART_TF);
+		xmit->tail = (xmit->tail + num_chars) & (UART_XMIT_SIZE - 1);
+		tf_pointer += num_chars;
 	}
 
+	/* disable tx interrupts if nothing more to send */
+	if (uart_circ_empty(xmit))
+		msm_stop_tx(port);
+
 	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
 		uart_write_wakeup(port);
 }
@@ -757,7 +770,7 @@ static void msm_console_putchar(struct uart_port *port, int c)
 	struct msm_port *msm_port = UART_TO_MSM(port);
 
 	if (msm_port->is_uartdm)
-		reset_dm_count(port);
+		reset_dm_count(port, 1);
 
 	while (!(msm_read(port, UART_SR) & UART_SR_TX_READY))
 		;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 14:37:30 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 11:37:30 -0700
Subject: [PATCH 3/4] msm_serial: Make baud_code detection more dynamic
In-Reply-To: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
References: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374691051-28544-4-git-send-email-sboyd@codeaurora.org>

Currently msm_set_baud_rate() assumes the uart clock rate is
1.8432 MHz. This is not always true, and limits our options to
program the baud rate. Instead of assuming the rate and
hard-coding the baud_code based on it, calculate the divider that
we want and try to find the closest baud_code that matches. This
allows us to support uarts with faster clock speeds.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/tty/serial/msm_serial.c | 98 ++++++++++++++++++-----------------------
 drivers/tty/serial/msm_serial.h | 18 ++------
 2 files changed, 48 insertions(+), 68 deletions(-)

diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index cab4105..cef8f40 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -322,70 +322,60 @@ static void msm_break_ctl(struct uart_port *port, int break_ctl)
 		msm_write(port, UART_CR_CMD_STOP_BREAK, UART_CR);
 }
 
+struct msm_baud_map {
+	u16	divisor;
+	u8	code;
+	u8	rxstale;
+};
+
+static const struct msm_baud_map *
+msm_find_best_baud(struct uart_port *port, unsigned int baud)
+{
+	unsigned int i, divisor;
+	const struct msm_baud_map *entry;
+	static const struct msm_baud_map table[] = {
+		{ 1536, 0x00,  1 },
+		{  768, 0x11,  1 },
+		{  384, 0x22,  1 },
+		{  192, 0x33,  1 },
+		{   96, 0x44,  1 },
+		{   48, 0x55,  1 },
+		{   32, 0x66,  1 },
+		{   24, 0x77,  1 },
+		{   16, 0x88,  1 },
+		{   12, 0x99,  6 },
+		{    8, 0xaa,  6 },
+		{    6, 0xbb,  6 },
+		{    4, 0xcc,  6 },
+		{    3, 0xdd,  8 },
+		{    2, 0xee, 16 },
+		{    1, 0xff, 31 },
+	};
+
+	divisor = uart_get_divisor(port, baud);
+
+	for (i = 0, entry = table; i < ARRAY_SIZE(table); i++, entry++)
+		if (entry->divisor <= divisor)
+			break;
+
+	return entry; /* Default to smallest divider */
+}
+
 static int msm_set_baud_rate(struct uart_port *port, unsigned int baud)
 {
-	unsigned int baud_code, rxstale, watermark;
+	unsigned int rxstale, watermark;
 	struct msm_port *msm_port = UART_TO_MSM(port);
+	const struct msm_baud_map *entry;
 
-	switch (baud) {
-	case 300:
-		baud_code = UART_CSR_300;
-		rxstale = 1;
-		break;
-	case 600:
-		baud_code = UART_CSR_600;
-		rxstale = 1;
-		break;
-	case 1200:
-		baud_code = UART_CSR_1200;
-		rxstale = 1;
-		break;
-	case 2400:
-		baud_code = UART_CSR_2400;
-		rxstale = 1;
-		break;
-	case 4800:
-		baud_code = UART_CSR_4800;
-		rxstale = 1;
-		break;
-	case 9600:
-		baud_code = UART_CSR_9600;
-		rxstale = 2;
-		break;
-	case 14400:
-		baud_code = UART_CSR_14400;
-		rxstale = 3;
-		break;
-	case 19200:
-		baud_code = UART_CSR_19200;
-		rxstale = 4;
-		break;
-	case 28800:
-		baud_code = UART_CSR_28800;
-		rxstale = 6;
-		break;
-	case 38400:
-		baud_code = UART_CSR_38400;
-		rxstale = 8;
-		break;
-	case 57600:
-		baud_code = UART_CSR_57600;
-		rxstale = 16;
-		break;
-	case 115200:
-	default:
-		baud_code = UART_CSR_115200;
-		baud = 115200;
-		rxstale = 31;
-		break;
-	}
+	entry = msm_find_best_baud(port, baud);
 
 	if (msm_port->is_uartdm)
 		msm_write(port, UART_CR_CMD_RESET_RX, UART_CR);
 
-	msm_write(port, baud_code, UART_CSR);
+	msm_write(port, entry->code, UART_CSR);
 
 	/* RX stale watermark */
+	rxstale = entry->rxstale;
 	watermark = UART_IPR_STALE_LSB & rxstale;
 	watermark |= UART_IPR_RXSTALE_LAST;
 	watermark |= UART_IPR_STALE_TIMEOUT_MSB & (rxstale << 2);
diff --git a/drivers/tty/serial/msm_serial.h b/drivers/tty/serial/msm_serial.h
index 15c186e..469fda5 100644
--- a/drivers/tty/serial/msm_serial.h
+++ b/drivers/tty/serial/msm_serial.h
@@ -38,19 +38,7 @@
 #define UART_MR2_PARITY_MODE_SPACE	0x3
 #define UART_MR2_PARITY_MODE		0x3
 
-#define UART_CSR	0x0008
-#define UART_CSR_115200	0xFF
-#define UART_CSR_57600	0xEE
-#define UART_CSR_38400	0xDD
-#define UART_CSR_28800	0xCC
-#define UART_CSR_19200	0xBB
-#define UART_CSR_14400	0xAA
-#define UART_CSR_9600	0x99
-#define UART_CSR_4800	0x77
-#define UART_CSR_2400	0x55
-#define UART_CSR_1200	0x44
-#define UART_CSR_600	0x33
-#define UART_CSR_300	0x22
+#define UART_CSR			0x0008
 
 #define UART_TF		0x000C
 #define UARTDM_TF	0x0070
@@ -152,6 +140,7 @@ static inline void msm_serial_set_mnd_regs_tcxo(struct uart_port *port)
 	msm_write(port, 0xF1, UART_NREG);
 	msm_write(port, 0x0F, UART_DREG);
 	msm_write(port, 0x1A, UART_MNDREG);
+	port->uartclk = 1843200;
 }
 
 /*
@@ -163,6 +152,7 @@ static inline void msm_serial_set_mnd_regs_tcxoby4(struct uart_port *port)
 	msm_write(port, 0xF6, UART_NREG);
 	msm_write(port, 0x0F, UART_DREG);
 	msm_write(port, 0x0A, UART_MNDREG);
+	port->uartclk = 1843200;
 }
 
 static inline
@@ -170,7 +160,7 @@ void msm_serial_set_mnd_regs_from_uartclk(struct uart_port *port)
 {
 	if (port->uartclk == 19200000)
 		msm_serial_set_mnd_regs_tcxo(port);
-	else
+	else if (port->uartclk == 4800000)
 		msm_serial_set_mnd_regs_tcxoby4(port);
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 14:39:12 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 11:39:12 -0700
Subject: [PATCH v5 0/5] clk: implement remuxing during set_rate
In-Reply-To: <CAAG0J9-F0P67=oaE5UHhmgd3Wz4k4XjsRjWShxmKOqicAyrhfw@mail.gmail.com>
References: <1371139562-305-1-git-send-email-james.hogan@imgtec.com>
 <20130621170407.20448.35605@quantum>
 <CAAG0J9-F0P67=oaE5UHhmgd3Wz4k4XjsRjWShxmKOqicAyrhfw@mail.gmail.com>
Message-ID: <20130724183912.GC27761@codeaurora.org>

On 06/21, James Hogan wrote:
> On 21 June 2013 18:04, Mike Turquette <mturquette at linaro.org> wrote:
> > Quoting James Hogan (2013-06-13 09:05:57)
> >> This patchset adds support for automatic selection of the best parent
> >> for a clock mux, i.e. the one which can provide the closest clock rate
> >> to that requested. It can be disabled by a new CLK_SET_RATE_NO_REPARENT
> >> flag (which is set for all uses of clk_register_mux().
> >>
> >> This works by way of adding a new op, determine_rate, similar to
> >> round_rate but with an extra parameter to allow the clock driver to
> >> optionally select a different parent clock. This is used in
> >> clk_calc_new_rates to decide whether to initiate a set_parent operation.
> >
> > Hi James,
> >
> > I'm going to hold off on this one for 3.11. I'll revisit it after the
> > next merge window.
> 
> Okay, no worries.
> 

Has a new patchset been sent out? I'd like to see this merge in
3.12.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From ian.campbell at citrix.com  Wed Jul 24 14:42:44 2013
From: ian.campbell at citrix.com (Ian Campbell)
Date: Wed, 24 Jul 2013 19:42:44 +0100
Subject: Requirements for FDT load address on ARM
In-Reply-To: <alpine.LFD.2.03.1307241116200.15022@syhkavp.arg>
References: <1374677923.6623.194.camel@hastur.hellion.org.uk>
 <alpine.LFD.2.03.1307241116200.15022@syhkavp.arg>
Message-ID: <1374691364.32286.13.camel@hastur.hellion.org.uk>

On Wed, 2013-07-24 at 11:24 -0400, Nicolas Pitre wrote:
> On Wed, 24 Jul 2013, Ian Campbell wrote:
> 
> > [apologies if this is a repeat, I don't see it in the archives and at
> > least one CC'd recipient (Julien) didn't receive it either. Beasties in
> > our email server I expect...]
> > 
> > Are there any requirements about where the FDT may be loaded by the
> > bootloader?
> 
> It must be located where it is unlikely to be overwritten by the zImage 
> decompressor relocating itself.  Same goes for the initrd.

Right. That's a bit hard to determine programmaticaly from a bootloader
though :-(

> > I'm finding that if I load it "too high" I get a fault (the specifics
> > aren't that relevant but details are below).
> 
> Do you have commit 6f16f4998f98 in your kernel tree?

It doesn't look like I do. The symptoms I'm seeing could well be
explained by that lack.

> > FWIW with RAM from 0x8000000-0xffffffff and a kernel loaded at 
> > 0x80008000 "too high" means above somewhere around 0xaf800000.
> 
> Sorry, I don't understand the above sentence.
> 
> Is RAM actually starting at 0x08000000 ?

Sorry, missed a zero, RAM starts at 0x80000000.

What I was trying to say that in my empirical experience loading the fdt
"too high" meant above 0xaf800000. Not actually terribly useful data
TBH.

>   Note that the kernel must be 
> loaded in the first 128MB of RAM.

> > I expect this is because the kernel doesn't use an explicit mapping of
> > the fdt but expects it to be within the RAM directly mapped by the
> > lowmem area (i.e. it uses phys_to_virt, since day one aka 93c02ab40ae6
> > "arm/dt: probe for platforms via the device tree").
> 
> The fdt is expected to be located in lowmem.  So yes, that's actually a 
> restriction.

OK, that's good to know, although the fuzziness about what is "lowmem"
for a given kernel config makes it a bit trickier.

> > This effectively
> > limits the FDT to being within the first ~700MB (give or take based
> > on .config etc, I suppose <500MB is a pretty safe rule of thumb). Is
> > this expected or is it actually not intentional and the kernel should
> > really be using an explicit mapping here? Should I send a patch against
> > Documentation/arm/Booting?
> 
> Yes please.

OK I'll try and put something together which I hope isn't too wildly wrong...

Ian




From ian.campbell at citrix.com  Wed Jul 24 14:42:58 2013
From: ian.campbell at citrix.com (Ian Campbell)
Date: Wed, 24 Jul 2013 19:42:58 +0100
Subject: Requirements for FDT load address on ARM
In-Reply-To: <20130724171826.GX11072@mudshark.cambridge.arm.com>
References: <1374677923.6623.194.camel@hastur.hellion.org.uk>
 <alpine.LFD.2.03.1307241116200.15022@syhkavp.arg>
 <20130724171826.GX11072@mudshark.cambridge.arm.com>
Message-ID: <1374691378.32286.17.camel@hastur.hellion.org.uk>

On Wed, 2013-07-24 at 18:18 +0100, Will Deacon wrote:
> FWIW, you could have a look at what I do in kvmtool. It's not perfect, but
> I couldn't come up with anything better:
> 
> https://git.kernel.org/cgit/linux/kernel/git/will/kvmtool.git/tree/tools/kvm/arm/fdt.c?h=kvmtool/master
> 
> (see the load_flat_binary function)

Thanks, it's most probably a good idea for us to do the same thing.

Ian.




From r.sricharan at ti.com  Wed Jul 24 14:43:53 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Thu, 25 Jul 2013 00:13:53 +0530
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <51F00530.9090703@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <51E83A4F.5080904@ti.com>
 <CACRpkdY3nQaWimTwB-Zt-8+Q_KZr8a0rpB1SUQq=AuoG4bAYnQ@mail.gmail.com>
 <51ED2385.60108@ti.com> <51ED5C66.1010407@ti.com> <51EFFBE1.4090505@ti.com>
 <51F0031B.1050307@ti.com> <51F00530.9090703@ti.com>
Message-ID: <51F02069.3050207@ti.com>

On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote:
> On 07/24/2013 11:38 AM, Santosh Shilimkar wrote:
>> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: 
>>> That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible.
>>> an option might be to "statically allocate" default number of interrupts to a domain - example:
>>> * GIC IRQ 72->78 allotted to UARTs
>>> * pinctrl mapping provided for those but only 6 can be used (rest are marked status="disabled" as default) at any given time (choice of pinctrl option determines GIC interrupt line to use)
>>> * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel.
>>>
>>> Does that sound fair trade off?
>> This sounds better. That way we can get all the devices in the DT at least.
>
> Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial.
>
 Ok, i will use this idea of certain number interrupts to groups.
Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it.
1:2 and fully arbitrary.  But will we be really exhausting them ?

Regards,
 Sricharan


From nm at ti.com  Wed Jul 24 14:51:42 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 24 Jul 2013 13:51:42 -0500
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <51F02069.3050207@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <51E83A4F.5080904@ti.com>
 <CACRpkdY3nQaWimTwB-Zt-8+Q_KZr8a0rpB1SUQq=AuoG4bAYnQ@mail.gmail.com>
 <51ED2385.60108@ti.com> <51ED5C66.1010407@ti.com> <51EFFBE1.4090505@ti.com>
 <51F0031B.1050307@ti.com> <51F00530.9090703@ti.com> <51F02069.3050207@ti.com>
Message-ID: <51F0223E.4050008@ti.com>

On 07/24/2013 01:43 PM, Sricharan R wrote:
> On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote:
>> On 07/24/2013 11:38 AM, Santosh Shilimkar wrote:
>>> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote:
>>>> That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible.
>>>> an option might be to "statically allocate" default number of interrupts to a domain - example:
>>>> * GIC IRQ 72->78 allotted to UARTs
>>>> * pinctrl mapping provided for those but only 6 can be used (rest are marked status="disabled" as default) at any given time (choice of pinctrl option determines GIC interrupt line to use)
>>>> * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel.
>>>>
>>>> Does that sound fair trade off?
>>> This sounds better. That way we can get all the devices in the DT at least.
>>
>> Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial.
>>
>   Ok, i will use this idea of certain number interrupts to groups.
> Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it.
> 1:2 and fully arbitrary.  But will we be really exhausting them ?
>
Depends on how we allocate :). The default arbitary allocation can be 
made more logical in your series ofcourse :).


-- 
Regards,
Nishanth Menon


From nicolas.pitre at linaro.org  Wed Jul 24 14:55:00 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 24 Jul 2013 14:55:00 -0400 (EDT)
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value
 to index into save array
In-Reply-To: <20130724164717.GA4610@localhost.localdomain>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-2-git-send-email-nicolas.pitre@linaro.org>
 <20130724164717.GA4610@localhost.localdomain>
Message-ID: <alpine.LFD.2.03.1307241437460.15022@syhkavp.arg>

On Wed, 24 Jul 2013, Dave Martin wrote:

> On Mon, Jul 22, 2013 at 11:31:17PM -0400, Nicolas Pitre wrote:
> > Currently we hash the MPIDR of the CPU being suspended to determine which
> > entry in the sleep_save_sp array to use. In some situations, such as when
> > we want to resume on another physical CPU, the MPIDR of another CPU should
> > be used instead.
> > 
> > So let's use the value of cpu_logical_map(smp_processor_id()) in place
> > of the MPIDR in the suspend path.  This will result in the same index
> > being used as with the previous code unless the caller has modified
> > cpu_logical_map() beforehand.
> 
> This only works because we happen to swap MPIDRs in cpu_logical_map
> before we get here, so that cpu_logical_map(smp_processor_id())
> described the post-resume situation for this logical CPU, not the
> current situation.

Yes, that's more or less what I said above.  Maybe that should be 
clarified further?

> We have to swizzle cpu_logical_map() somewhere, and the suspend path is
> just as good as the resume path for that.

Not quite.  On the resume path, we have to get to the context save array 
while having no mmu active and no stack.  There is no way we could take 
over another CPU's context in those conditions without making it 
extremely painful on ourselves.  It is therefore way easier to swizzle 
cpu_logical_map() on the suspend path and keep the suspend/resume logic 
unmodified.

> But this patch commits us to requiring that on the suspend path 
> specifically -- I think that ought to be mentioned somewhere. A 
> comment in the preamble for __cpu_suspend would be enough, I think.

What comment would you suggest?  I want to make sure the possible 
confusion you see is properly addressed.

> Looks like the patch should work though, and it does remove the need to
> read the MPIDR, which is slightly nicer for the non-switcher case.

This patch works fine here, and I'd expect rather catastrophic results 
if it didn't.  ;-)


Nicolas


From joelf at ti.com  Wed Jul 24 14:55:24 2013
From: joelf at ti.com (Joel Fernandes)
Date: Wed, 24 Jul 2013 13:55:24 -0500
Subject: [PATCH] dma: edma: add device_slave_caps() support
In-Reply-To: <51EF92F2.3030405@metafoo.de>
References: <1374597804-3961-1-git-send-email-joelf@ti.com>
 <51EF8A52.90902@metafoo.de> <51EF8C2B.2030409@ti.com>,
 <51EF8F4E.8080806@metafoo.de> <FB20353E-4890-4462-A671-3587A3841B4A@ti.com>
 <51EF92F2.3030405@metafoo.de>
Message-ID: <51F0231C.7000401@ti.com>

On 07/24/2013 03:40 AM, Lars-Peter Clausen wrote:
> On 07/24/2013 10:28 AM, Fernandes, Joel wrote:
>>
>> On Jul 24, 2013, at 3:23 AM, "Lars-Peter Clausen" <lars at metafoo.de> wrote:
>>
>>> On 07/24/2013 10:11 AM, Joel Fernandes wrote:
>>>> On 07/24/2013 03:03 AM, Lars-Peter Clausen wrote:
>>>>> On 07/23/2013 06:43 PM, Joel Fernandes wrote:
>>>>>> Implement device_slave_caps(). EDMA has a limited number of slots.
>>>>>> Slave drivers such as omap_hsmmc will query the driver to make
>>>>>> sure they don't pass in more than these many scatter segments.
>>>>>>
>>>>>> Signed-off-by: Joel Fernandes <joelf at ti.com>
>>>>>> ---
>>>>>> Vinod, or Dan- If this patch looks ok, can you please merge in for
>>>>>> -rc cycle? This patch is required to fix MMC support on AM33xx. This
>>>>>> patch is blocking 3 other patches which fix various MMC things. Thanks!
>>>>>>
>>>>>> Notes:
>>>>>> (1) this approach is temporary and only for -rc cycle to fix MMC on
>>>>>> AM335x. It will be replace by the RFC series in future kernels:
>>>>>> http://www.spinics.net/lists/arm-kernel/msg260094.html
>>>>>>
>>>>>> (2) Patch depends Vinod's patch at:
>>>>>> http://permalink.gmane.org/gmane.linux.kernel/1525112
>>>>>>
>>>>>> drivers/dma/edma.c |    9 +++++++++
>>>>>> 1 file changed, 9 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
>>>>>> index 7222cbe..81d5429 100644
>>>>>> --- a/drivers/dma/edma.c
>>>>>> +++ b/drivers/dma/edma.c
>>>>>> @@ -517,6 +517,14 @@ static void edma_issue_pending(struct dma_chan *chan)
>>>>>>    spin_unlock_irqrestore(&echan->vchan.lock, flags);
>>>>>> }
>>>>>>
>>>>>> +static inline int edma_slave_caps(struct dma_chan *chan,
>>>>>> +    struct dma_slave_caps *caps)
>>>>>> +{
>>>>>> +    caps->max_sg_nr = MAX_NR_SG;
>>>>>
>>>>> Hm, what about the other fields?
>>>>
>>>> Other fields are unused, the max segment size is supposed to be
>>>> calculated "given" the address width and burst size. Since these
>>>> can't be provided to get_caps, I have left it out for now.
>>>> See: https://lkml.org/lkml/2013/3/6/464
>>>
>>> The PL330 driver is similar in this regard, the maximum segment size also
>>> depends on address width and burst width. What I did for the get_slave_caps
>>> implementation is to set it to the minimum maximum size. E.g. in you case
>>> that should be SZ_64K - 1 (burstsize and addrwidth both set to 1).
>>
>> So you're setting max to minimum maximum size? Isn't that like telling the driver that its segments can't be bigger than this... Unless I'm missing something..
> 
> Yes. This is a limitation of the current slave_caps API. The maximum needs
> to be the maximum for all possible configurations. A specific configuration
> may allow a larger maximum. So we maybe have to extend the API to be able to
> query the limits for a certain configuration. Not sure what the best way
> would be to do that, either adding a config parameter to get_slave_caps or
> to break it into two functions like you proposed one for the static
> capabilities and one for the sg limits.

I am OK with either approach as long as a decision can be made quickly
by maintainers. Right now lot of back and forth has happened and 3
different versions of the same thing have been posted since January.
Since this is such a trivial change, it doesn't make sense to spend so
much time on it IMO.... The sad part is though this change is trivial,
other drivers such as MMC are broken and cannot be enabled due to this.
We cannot afford to leave them broken.

If Vinod is not available, can Dan please respond on how to proceed on
this? We really need this trivial change to go into this -rc cycle and
not delay it by another kernel release. Thank you.

-Joel



From sboyd at codeaurora.org  Wed Jul 24 14:56:18 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 11:56:18 -0700
Subject: [PATCH] ARM: Fix deadlock scenario with smp_send_stop()
In-Reply-To: <1373384217-26307-1-git-send-email-sboyd@codeaurora.org>
References: <1373384217-26307-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130724185618.GD27761@codeaurora.org>

On 07/09, Stephen Boyd wrote:
> If one process calls sys_reboot and that process then stops other
> CPUs while those CPUs are within a spin_lock() region we can
> potentially encounter a deadlock scenario like below.
> 
> CPU 0                   CPU 1
> -----                   -----
>                         spin_lock(my_lock)
> smp_send_stop()
>  <send IPI>             handle_IPI()
>                          disable_preemption/irqs
>                           while(1);
>  <PREEMPT>
> spin_lock(my_lock) <--- Waits forever
> 
> We shouldn't attempt to run any other tasks after we send a stop
> IPI to a CPU so disable preemption so that this task runs to
> completion.
> 
> Reported-by: Sundarajan Srinivasan <sundaraj at codeaurora.com>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
> 
> Resending this patch now that the context has changed.

Ping? Shall I put this in the patch tracker?

> 
>  arch/arm/kernel/process.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index 7f1efcd..8bc12d7 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -206,6 +206,7 @@ void machine_shutdown(void)
>   */
>  void machine_halt(void)
>  {
> +	preempt_disable();
>  	smp_send_stop();
>  
>  	local_irq_disable();
> @@ -220,6 +221,7 @@ void machine_halt(void)
>   */
>  void machine_power_off(void)
>  {
> +	preempt_disable();
>  	smp_send_stop();
>  
>  	if (pm_power_off)
> @@ -239,6 +241,7 @@ void machine_power_off(void)
>   */
>  void machine_restart(char *cmd)
>  {
> +	preempt_disable();
>  	smp_send_stop();
>  
>  	arm_pm_restart(reboot_mode, cmd);

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From santosh.shilimkar at ti.com  Wed Jul 24 14:59:27 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 24 Jul 2013 14:59:27 -0400
Subject: [PATCH 1/3] misc: Add crossbar driver
In-Reply-To: <51F0223E.4050008@ti.com>
References: <1374165830-6367-1-git-send-email-r.sricharan@ti.com>
 <1374165830-6367-2-git-send-email-r.sricharan@ti.com>
 <51E83A4F.5080904@ti.com>
 <CACRpkdY3nQaWimTwB-Zt-8+Q_KZr8a0rpB1SUQq=AuoG4bAYnQ@mail.gmail.com>
 <51ED2385.60108@ti.com> <51ED5C66.1010407@ti.com> <51EFFBE1.4090505@ti.com>
 <51F0031B.1050307@ti.com> <51F00530.9090703@ti.com> <51F02069.3050207@ti.com>
 <51F0223E.4050008@ti.com>
Message-ID: <51F0240F.3050507@ti.com>

On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote:
> On 07/24/2013 01:43 PM, Sricharan R wrote:
>> On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote:
>>> On 07/24/2013 11:38 AM, Santosh Shilimkar wrote:
>>>> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote:
>>>>> That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible.
>>>>> an option might be to "statically allocate" default number of interrupts to a domain - example:
>>>>> * GIC IRQ 72->78 allotted to UARTs
>>>>> * pinctrl mapping provided for those but only 6 can be used (rest are marked status="disabled" as default) at any given time (choice of pinctrl option determines GIC interrupt line to use)
>>>>> * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel.
>>>>>
>>>>> Does that sound fair trade off?
>>>> This sounds better. That way we can get all the devices in the DT at least.
>>>
>>> Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial.
>>>
>>   Ok, i will use this idea of certain number interrupts to groups.
>> Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it.
>> 1:2 and fully arbitrary.  But will we be really exhausting them ?
>>
> Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :).
> 
I would just most logical peripherals rather than providing every single
IP connected to cross bar. Otherwise we will end up wth hwmod like
scenario where now started removing the unused stuff because of
maintenance and loc issues ;-)



From jason at lakedaemon.net  Wed Jul 24 15:03:15 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 24 Jul 2013 15:03:15 -0400
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <51F01D64.9060609@gmail.com>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
 <51F01D64.9060609@gmail.com>
Message-ID: <20130724190315.GC23879@titan.lakedaemon.net>

On Wed, Jul 24, 2013 at 01:31:00PM -0500, Rob Herring wrote:
> On 07/24/2013 10:27 AM, Olof Johansson wrote:
> > Every now and then I come across a binding that's just done Wrong(tm),
> > merged through a submaintainer tree and hasn't seen proper review --
> > if it had, it wouldn't look the way it does. It's something we're
> > starting to address now since there's more people stepping up to be
> > maintainers, but there's a backlog of bad bindings already merged.
> > 
> > Often they are produced by translating the platform_data structures
> > directly over into device-tree properties without consideration to
> > describing the hardware or usual conventions, using key/value pairs
> > instead of boolean properties, etc.
> > 
> > Getting involved in cleaning up these kind of bindings is a great way
> > to learn "the ways of device tree" for someone that has interest in
> > that.
> > 
> > Latest find in this area is the Maxim 8925 bindings, that I came
> > across since they caused a compile warning on some defconfig. I'll
> > post a patch to address the warning but if someone else feels like
> > fixing the bindings on top of it that would be appreciated!
> 
> Are they documented typically? Can we at a minimum update the
> documentation with a big fat warning to not use or propagate the crap.
> Or move the binding doc file to a fixme directory.

I agree, in order to do the janitorial work (which I'm not opposed to
helping with), we need a way to mark stable bindings.

fwiw, we could do a separate commit (like the kernel version commit)
where the only change is marking a binding as stable, and is obvious
from a 'git log --oneline'. eg:

---->8------

>From 65c069678cdbd5aaa6aca0d4062dab6eb9f9904c Mon Sep 17 00:00:00 2001
From: Jason Cooper <jason at lakedaemon.net>
Date: Wed, 24 Jul 2013 18:49:28 +0000
Subject: [PATCH] DT: binding: stable: gpio-regulator

A whole bunch of folks reviewed this and think it kicks ass.

List-of-people-responsible-for-this-travesty: ...
Signed-off-by: Jason Cooper <jason at lakedaemon.net>
---
 Documentation/devicetree/bindings/regulator/gpio-regulator.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
index 63c6598..35ec635 100644
--- a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
@@ -1,3 +1,5 @@
+Binding status: Stable
+
 GPIO controlled regulators
 
 Required properties:
-- 
1.8.3.2



From vinod.koul at intel.com  Wed Jul 24 14:33:29 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Thu, 25 Jul 2013 00:03:29 +0530
Subject: [PATCH] dma: edma: add device_slave_caps() support
In-Reply-To: <51F0231C.7000401@ti.com>
References: <1374597804-3961-1-git-send-email-joelf@ti.com>
 <51EF8A52.90902@metafoo.de> <51EF8C2B.2030409@ti.com>
 <51EF8F4E.8080806@metafoo.de>
 <FB20353E-4890-4462-A671-3587A3841B4A@ti.com>
 <51EF92F2.3030405@metafoo.de> <51F0231C.7000401@ti.com>
Message-ID: <20130724183329.GH18642@intel.com>

On Wed, Jul 24, 2013 at 01:55:24PM -0500, Joel Fernandes wrote:
> On 07/24/2013 03:40 AM, Lars-Peter Clausen wrote:
> > On 07/24/2013 10:28 AM, Fernandes, Joel wrote:
> >>>>>> Vinod, or Dan- If this patch looks ok, can you please merge in for
> >>>>>> -rc cycle? This patch is required to fix MMC support on AM33xx. This
> >>>>>> patch is blocking 3 other patches which fix various MMC things. Thanks!
Sorry I was travelling so not realy on top of email for last few days...

Now I am not sure we can send this to -rc.
If it were just this one, we could have pushed but it also depends on a new API
which is sitting in my -next. I am not super comfortable to send that to Linus
for the -rcs. Sure, he would scream at me!

Also another point worth considering is the approach Russell suggested, I havent
gotten a chance to dig deeper but if I understood it correctly then programming
the device_dma_parameters should be the right thing to do. Again I need to look
deeper and esp wrt edma

~Vinod


From lars at metafoo.de  Wed Jul 24 15:15:23 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Wed, 24 Jul 2013 21:15:23 +0200
Subject: [PATCH] dma: edma: add device_slave_caps() support
In-Reply-To: <51F0231C.7000401@ti.com>
References: <1374597804-3961-1-git-send-email-joelf@ti.com>
 <51EF8A52.90902@metafoo.de> <51EF8C2B.2030409@ti.com>,
 <51EF8F4E.8080806@metafoo.de> <FB20353E-4890-4462-A671-3587A3841B4A@ti.com>
 <51EF92F2.3030405@metafoo.de> <51F0231C.7000401@ti.com>
Message-ID: <51F027CB.2050608@metafoo.de>

On 07/24/2013 08:55 PM, Joel Fernandes wrote:
> On 07/24/2013 03:40 AM, Lars-Peter Clausen wrote:
>> On 07/24/2013 10:28 AM, Fernandes, Joel wrote:
>>>
>>> On Jul 24, 2013, at 3:23 AM, "Lars-Peter Clausen" <lars at metafoo.de> wrote:
>>>
>>>> On 07/24/2013 10:11 AM, Joel Fernandes wrote:
>>>>> On 07/24/2013 03:03 AM, Lars-Peter Clausen wrote:
>>>>>> On 07/23/2013 06:43 PM, Joel Fernandes wrote:
>>>>>>> Implement device_slave_caps(). EDMA has a limited number of slots.
>>>>>>> Slave drivers such as omap_hsmmc will query the driver to make
>>>>>>> sure they don't pass in more than these many scatter segments.
>>>>>>>
>>>>>>> Signed-off-by: Joel Fernandes <joelf at ti.com>
>>>>>>> ---
>>>>>>> Vinod, or Dan- If this patch looks ok, can you please merge in for
>>>>>>> -rc cycle? This patch is required to fix MMC support on AM33xx. This
>>>>>>> patch is blocking 3 other patches which fix various MMC things. Thanks!
>>>>>>>
>>>>>>> Notes:
>>>>>>> (1) this approach is temporary and only for -rc cycle to fix MMC on
>>>>>>> AM335x. It will be replace by the RFC series in future kernels:
>>>>>>> http://www.spinics.net/lists/arm-kernel/msg260094.html
>>>>>>>
>>>>>>> (2) Patch depends Vinod's patch at:
>>>>>>> http://permalink.gmane.org/gmane.linux.kernel/1525112
>>>>>>>
>>>>>>> drivers/dma/edma.c |    9 +++++++++
>>>>>>> 1 file changed, 9 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
>>>>>>> index 7222cbe..81d5429 100644
>>>>>>> --- a/drivers/dma/edma.c
>>>>>>> +++ b/drivers/dma/edma.c
>>>>>>> @@ -517,6 +517,14 @@ static void edma_issue_pending(struct dma_chan *chan)
>>>>>>>     spin_unlock_irqrestore(&echan->vchan.lock, flags);
>>>>>>> }
>>>>>>>
>>>>>>> +static inline int edma_slave_caps(struct dma_chan *chan,
>>>>>>> +    struct dma_slave_caps *caps)
>>>>>>> +{
>>>>>>> +    caps->max_sg_nr = MAX_NR_SG;
>>>>>>
>>>>>> Hm, what about the other fields?
>>>>>
>>>>> Other fields are unused, the max segment size is supposed to be
>>>>> calculated "given" the address width and burst size. Since these
>>>>> can't be provided to get_caps, I have left it out for now.
>>>>> See: https://lkml.org/lkml/2013/3/6/464
>>>>
>>>> The PL330 driver is similar in this regard, the maximum segment size also
>>>> depends on address width and burst width. What I did for the get_slave_caps
>>>> implementation is to set it to the minimum maximum size. E.g. in you case
>>>> that should be SZ_64K - 1 (burstsize and addrwidth both set to 1).
>>>
>>> So you're setting max to minimum maximum size? Isn't that like telling the driver that its segments can't be bigger than this... Unless I'm missing something..
>>
>> Yes. This is a limitation of the current slave_caps API. The maximum needs
>> to be the maximum for all possible configurations. A specific configuration
>> may allow a larger maximum. So we maybe have to extend the API to be able to
>> query the limits for a certain configuration. Not sure what the best way
>> would be to do that, either adding a config parameter to get_slave_caps or
>> to break it into two functions like you proposed one for the static
>> capabilities and one for the sg limits.
>
> I am OK with either approach as long as a decision can be made quickly
> by maintainers. Right now lot of back and forth has happened and 3
> different versions of the same thing have been posted since January.
> Since this is such a trivial change, it doesn't make sense to spend so
> much time on it IMO.... The sad part is though this change is trivial,
> other drivers such as MMC are broken and cannot be enabled due to this.
> We cannot afford to leave them broken.

Well this is a new API, so it is kind of expected that there is some back and 
forth and that there will be a few revisions.

>
> If Vinod is not available, can Dan please respond on how to proceed on
> this? We really need this trivial change to go into this -rc cycle and
> not delay it by another kernel release. Thank you.

This is not something you'd merge for rc3 or even later. If the MMC driver does 
not work without this I guess it never worked, so strictly speaking there is no 
regression and it is just a new feature.

- Lars



From hauke at hauke-m.de  Wed Jul 24 15:21:43 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Wed, 24 Jul 2013 21:21:43 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <CADjby3WGW6f=1Vdm2kx+Re0KrjFRaC3dQOumpnS6_sp2yb5NfQ@mail.gmail.com>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130723184907.GA6811@ohporter.com>
 <CAGVrzcbA72AYu6J3JXBirQQeTiDH9cJThdBdH=Q=gJtOnqz-AA@mail.gmail.com>
 <20130723192203.GC6811@ohporter.com> <51EF1B8C.9020304@broadcom.com>
 <CADjby3WGW6f=1Vdm2kx+Re0KrjFRaC3dQOumpnS6_sp2yb5NfQ@mail.gmail.com>
Message-ID: <51F02947.7020301@hauke-m.de>

On 07/24/2013 02:44 AM, Domenico Andreoli wrote:
> On Wednesday, July 24, 2013, Hauke Mehrtens <hauke at hauke-m.de
> <mailto:hauke at hauke-m.de>> wrote:
>> On 07/19/2013 03:36 AM, Domenico Andreoli wrote:
>>> On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote:
>>>> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote:
>>>>>
>>>>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig
> b/arch/arm/mach-bcm53xx/Kconfig
>>>>>> new file mode 100644
>>>>>> index 0000000..1e16e87
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm/mach-bcm53xx/Kconfig
>>>>>> @@ -0,0 +1,10 @@
>>>>>> +config ARCH_BCM53XX
>>>>>> +  bool "Broadcom BCM47XX / BCM53XX ARM SoC"
>>>>>
>>>>> So the directory is named mach-bcm53xx, but you also handle BCM47xx
>>>>> SoCs. This doesn't sound really easy to follow.
>>>
>>> At the time of the BCM281XX merge we considered that such directories
> would
>>> mostly contain board files only, being these new entries DT based. Hence
>>> the choice of mach-bcm to collect all of them.
>>>
>>> I think you should then put this stuff there.
>>
>> So you think I should move the file from
>> arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?
> 
> yes
> 
> this looks more comsistent with the actual soc name:
> arch/arm/mach-bcm/bcm530xx.c
> 
> but I find also acceptable the complete name of the "parent" soc (as I'm
> doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c

I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351)
have more in common than the vendor name, so I do not think it is a good
idea to place them all at mach-bcm.

>> Most (All?) of the Router SoCs in the BCM53XX and BCM47XX line are from
>> the same family and they should be supported by the same code, so there
>> is no reason to have a bcm47xx.c and a bcm53xx.c.
>>
>>>> Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I
>>>> do not know why there are two different names, probably marketing.
>>>>
>>>> Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a
>>>> MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to
>>>> not conflict with the MIPS part now. I know this could still cause
>>>> problems and people will get confused, but I do not know a better name.
>>>
>>> I'll throw also BCM476x (bcm4760 and bcm4761) on the table. These are
> ARM11,
>>> single-core SoCs.
>>>
>>> Can we agree on a nice naming so that we actually clarify this silliness?
>>
>> We could name it BCM5301X like it is named the the vendor source code.
>> Currently there are the following SoCs of this family available:
>> BCM53010, BCM53011, BCM53012, BCM53014, BCM53015, BCM53016, BCM53017,
>> BCM53018, BCM4707, BCM4708 and BCM4709.
> 
> There is not a clear single pattern here, whatever choice won't be 100%
> right. Users will need to read some help to pick the right choice.
> BCM53010? But mine is not a strong opinion.
> 
>> Internal there are two different
>> chip IDs available 53010 (BCM4707) and 53018 (BCM53018).
> 
> what do you mean with "internal" here?

There is some register in the chip where the chipid is stored, according
to the vendor code these two values are currently possible. This was
changed for every generation with the MIPS SoCs, while one generation
had some SoCs.

Hauke


From joelf at ti.com  Wed Jul 24 15:36:26 2013
From: joelf at ti.com (Joel Fernandes)
Date: Wed, 24 Jul 2013 14:36:26 -0500
Subject: [PATCH] dma: edma: add device_slave_caps() support
In-Reply-To: <20130724183329.GH18642@intel.com>
References: <1374597804-3961-1-git-send-email-joelf@ti.com>
 <51EF8A52.90902@metafoo.de> <51EF8C2B.2030409@ti.com>
 <51EF8F4E.8080806@metafoo.de> <FB20353E-4890-4462-A671-3587A3841B4A@ti.com>
 <51EF92F2.3030405@metafoo.de> <51F0231C.7000401@ti.com>
 <20130724183329.GH18642@intel.com>
Message-ID: <51F02CBA.5060704@ti.com>

On 07/24/2013 01:33 PM, Vinod Koul wrote:
> On Wed, Jul 24, 2013 at 01:55:24PM -0500, Joel Fernandes wrote:
>> On 07/24/2013 03:40 AM, Lars-Peter Clausen wrote:
>>> On 07/24/2013 10:28 AM, Fernandes, Joel wrote:
>>>>>>>> Vinod, or Dan- If this patch looks ok, can you please merge in for
>>>>>>>> -rc cycle? This patch is required to fix MMC support on AM33xx. This
>>>>>>>> patch is blocking 3 other patches which fix various MMC things. Thanks!
> Sorry I was travelling so not realy on top of email for last few days...
> 
> Now I am not sure we can send this to -rc.

OK.

> If it were just this one, we could have pushed but it also depends on a new API
> which is sitting in my -next. I am not super comfortable to send that to Linus
> for the -rcs. Sure, he would scream at me!

OK.

> Also another point worth considering is the approach Russell suggested, I havent
> gotten a chance to dig deeper but if I understood it correctly then programming
> the device_dma_parameters should be the right thing to do. Again I need to look
> deeper and esp wrt edma

OK. I have some patches sitting in my tree too that I'm working on. With
that I don't need to know about maximum number of allowed segments and
can send along any number of segment. I will rework them and post them.
fwiw, I will also implement caps API incase like Lars did populating the
other fields though these will not be unused.

For segment size, at this time I don't know any driver that uses it
other than davinci-pcm. For this reason the calculations can be done as
Lars suggested (for minimum of maximum). Do you know in advance if
you're going to amend to drop segment size if we go with what Russell
suggested, or are you going to leave the seg-size in the caps API anyway.

Thanks,

-Joel



From linus.walleij at linaro.org  Wed Jul 24 15:32:54 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 24 Jul 2013 21:32:54 +0200
Subject: [PATCH 2/2] clk: fixup argument order when setting VCO parameters
In-Reply-To: <1374594138-17080-3-git-send-email-jonathan.austin@arm.com>
References: <1374594138-17080-1-git-send-email-jonathan.austin@arm.com>
 <1374594138-17080-3-git-send-email-jonathan.austin@arm.com>
Message-ID: <CACRpkdbEiNPG0b89zXKpvNgXtAbsKeV9A9ibgEJCBgNa6vQvCw@mail.gmail.com>

On Tue, Jul 23, 2013 at 5:42 PM, Jonathan Austin
<jonathan.austin at arm.com> wrote:

> The order of arguments in the call to vco_set() for the ICST clocks appears to
> have been switched in error, which results in the VCO not being initialised
> correctly. This in turn stops the integrated LCD on things like Integrator/CP
> from working correctly.
>
> This patch fixes the order and restores the expected functionality.
>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Mike Turquette <mturquette at linaro.org>
> Signed-off-by: Jonathan Austin <jonathan.austin at arm.com>

Good catch! Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
You should probably mark this for stable as well.

What I don't understand is why my CLCD VGA output has
been working all the time :-(

I thought this VCO was necessary for that as well,  but apparently
it works with the defaults.

Yours,
Linus Walleij


From jason at lakedaemon.net  Wed Jul 24 15:49:40 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 24 Jul 2013 15:49:40 -0400
Subject: [GIT PULL] clockevents/clocksource: Add Marvell Orion SoC timer
In-Reply-To: <51E56CFD.9050508@linaro.org>
References: <51B8D310.4050404@linaro.org> <51D9548B.9040907@gmail.com>
 <alpine.DEB.2.02.1307071508030.32106@ionos.tec.linutronix.de>
 <20130707144645.GA11908@titan.lakedaemon.net>
 <alpine.DEB.2.02.1307071723220.32106@ionos.tec.linutronix.de>
 <20130707235819.GB11908@titan.lakedaemon.net>
 <alpine.DEB.2.02.1307081041290.32106@ionos.tec.linutronix.de>
 <51E56CFD.9050508@linaro.org>
Message-ID: <20130724194940.GD23879@titan.lakedaemon.net>

On Tue, Jul 16, 2013 at 05:55:41PM +0200, Daniel Lezcano wrote:
> On 07/08/2013 10:45 AM, Thomas Gleixner wrote:
> > On Sun, 7 Jul 2013, Jason Cooper wrote:
> >> On Sun, Jul 07, 2013 at 05:30:31PM +0200, Thomas Gleixner wrote:
> >> I don't mind delaying half of a series so the drivers/ portion can land
> >> in mainline, and the rest can land in the next cycle.  But when things
> >> don't go according to that plan, I'd like a little consideration /
> >> flexibility about solving the problem.  Especially considering I'm
> >> *trying* to do the right thing by pushing to appropriate maintainers
> >> first.
> >>
> >> Of course, this is a moot point since, as you clarified above, this
> >> dependency doesn't have the hazards typically associated with
> >> out-of-tree dependencies.
> > 
> > There is a very simple procedure for stuff like this.
> > 
> > Series has parts which go through tree A and B and another larger part
> > for tree C which depends on the A and B parts.
> > 
> > So ask the maintainers of A and B to apply this to separate branches,
> > which are based on some commit in Linus tree. These branches can be
> > pulled into C and C can apply the depending stuff on top.
> > 
> > Now the maintainers of A and B merge these branches into their main
> > devel branch, can do further fixups and stuff on top. And the whole
> > thing just works without glitches during the merge window.
> > 
> > We do this all the time.
> 
> Ok, I was about to send to both of you a PR with a common ancestor [1]
> for this patch but finally this patch has been taken for timers/urgent.
> 
> I don't have to send the PR, right ?
> 
> timers/urgent will be merged into timers/core, correct ?

Sorry for the late reply.  I'm crawling out from under my backlog.  It
appears

  0c1dcfd clocksource: Add Marvell Orion SoC timer

has made it into Linus' tree.  Ezequiel, you should be able to base your
series on v3.11-rc[12] to pick this up.

thx,

Jason.


From fabio.estevam at freescale.com  Wed Jul 24 16:20:03 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Wed, 24 Jul 2013 17:20:03 -0300
Subject: [PATCH v2 1/2] ARM: dts: imx6qdl-sabresd: Add touchscreen support
Message-ID: <1374697204-18474-1-git-send-email-fabio.estevam@freescale.com>

mx6 sabresd boards have a egalax touchscreen controller connected via I2C3.

Add support for it.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- Fix the i2c bus and irq line as per the production sabresd board
- Tested via evtest

 arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 1d2dcef..bca6c2b 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -131,6 +131,21 @@
        };
 };
 
+&i2c3 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3_2>;
+	status = "okay";
+
+	egalax_ts at 04 {
+		compatible = "eeti,egalax_ts";
+		reg = <0x04>;
+		interrupt-parent = <&gpio6>;
+		interrupts = <7 2>;
+		wakeup-gpios = <&gpio6 7 0>;
+	};
+};
+
 &iomuxc {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_hog>;
@@ -145,6 +160,7 @@
 				MX6QDL_PAD_NANDF_D2__GPIO2_IO02 0x80000000
 				MX6QDL_PAD_NANDF_D3__GPIO2_IO03 0x80000000
 				MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x130b0
+				MX6QDL_PAD_NANDF_CLE__GPIO6_IO07 0x80000000
 			>;
 		};
 	};
-- 
1.8.1.2




From fabio.estevam at freescale.com  Wed Jul 24 16:20:04 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Wed, 24 Jul 2013 17:20:04 -0300
Subject: [PATCH v2 2/2] ARM: imx_v6_v7_defconfig: Select
 CONFIG_TOUCHSCREEN_EGALAX
In-Reply-To: <1374697204-18474-1-git-send-email-fabio.estevam@freescale.com>
References: <1374697204-18474-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <1374697204-18474-2-git-send-email-fabio.estevam@freescale.com>

egalax touchscren controller is present on mx6 sabresd/sabrelite, so let's 
enable it by default.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- None

 arch/arm/configs/imx_v6_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f1662d3..9e15992 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -127,6 +127,7 @@ CONFIG_KEYBOARD_IMX=y
 CONFIG_MOUSE_PS2=m
 CONFIG_MOUSE_PS2_ELANTECH=y
 CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_TOUCHSCREEN_EGALAX=y
 CONFIG_TOUCHSCREEN_MC13783=y
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_MMA8450=y
-- 
1.8.1.2




From nicolas.pitre at linaro.org  Wed Jul 24 16:21:34 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 24 Jul 2013 16:21:34 -0400 (EDT)
Subject: [PATCH 6/8] ARM: mm: LPAE: Correct virt_to_phys patching for 64
 bit physical addresses
In-Reply-To: <51EFC37B.80906@ti.com>
References: <1371858502-10083-1-git-send-email-santosh.shilimkar@ti.com>
 <1371858502-10083-7-git-send-email-santosh.shilimkar@ti.com>
 <alpine.LFD.2.03.1307231850350.15022@syhkavp.arg> <51EF356D.2050902@ti.com>
 <alpine.LFD.2.03.1307232222200.15022@syhkavp.arg>
 <51EFBF8F.4010201@ti.com> <51EFC37B.80906@ti.com>
Message-ID: <alpine.LFD.2.03.1307241456260.15022@syhkavp.arg>

On Wed, 24 Jul 2013, Sricharan R wrote:

> On Wednesday 24 July 2013 05:20 PM, Sricharan R wrote:
> > On Wednesday 24 July 2013 08:19 AM, Nicolas Pitre wrote:
> >> On Tue, 23 Jul 2013, Santosh Shilimkar wrote:
> >>
> >>> On Tuesday 23 July 2013 09:10 PM, Nicolas Pitre wrote:
> >>>> On Fri, 21 Jun 2013, Santosh Shilimkar wrote:
> >>>>
> >>>>> From: Sricharan R <r.sricharan at ti.com>
> >>>>>
> >>>>> The current phys_to_virt patching mechanism does not work
> >>>>> for 64 bit physical addressesp. Note that constant used in add/sub
> >>>>> instructions is encoded in to the last 8 bits of the opcode. So shift
> >>>>> the _pv_offset constant by 24 to get it in to the correct place.
> >>>>>
> >>>>> The v2p patching mechanism patches the higher 32bits of physical
> >>>>> address with a constant. While this is correct, in those platforms
> >>>>> where the lowmem addressable physical memory spawns across 4GB boundary,
> >>>>> a carry bit can be produced as a result of addition of lower 32bits.
> >>>>> This has to be taken in to account and added in to the upper. The patched
> >>>>> __pv_offset and va are added in lower 32bits, where __pv_offset can be
> >>>>> in two's complement form when PA_START < VA_START and that can result
> >>>>> in a false carry bit.
> >>>>>
> >>>>> e.g PA = 0x80000000 VA = 0xC0000000
> >>>>> __pv_offset = PA - VA = 0xC0000000 (2's complement)
> >>>>>
> >>>>> So adding __pv_offset + VA should never result in a true overflow. So in
> >>>>> order to differentiate between a true carry, a extra flag __pv_sign_flag
> >>>>> is introduced.
> >>> First of all thanks for the review.
> >>>  
> >>>> I'm still wondering if this is worth bothering about.
> >>>>
> >>>> If PA = 0x80000000 and VA = 0xC0000000 there will never be a real carry 
> >>>> to propagate to the high word of the physical address as the VA space 
> >>>> cannot be larger than 0x40000000.
> >>>>
> >>> Agreed.
> >>>
> >>>> So is there really a case where:
> >>>>
> >>>> 1) physical memory is crossing the 4GB mark, and ...
> >>>>
> >>>> 2) physical memory start address is higher than virtual memory start 
> >>>>    address needing a carry due to the 32-bit add overflow?
> >>>>
> >>> Consider below two cases of memory layout apart from one mentioned
> >>> above where the carry is bit irrelevant as you rightly said.
> >>>
> >>> 1) PA = 0x8_0000_0000, VA= 0xC000_0000, absolute pv_offset = 0x7_4000_0000
> >> This can be patched as:
> >>
> >> 	mov	phys_hi, #0x8
> >> 	add	phys_lo, virt, #0x40000000  @ carry ignored
> >>
> >>> 2) PA = 0x2_8000_0000, VA= 0xC000_000, absolute pv_offset = 0x1_C000_0000
> >> 	mov	phys_hi, #0x2
> >> 	add	phys_lo, virt, #0xc0000000  @ carry ignored
> >>
> >>> In both of these cases there a true carry which needs to be
> >>> considered.
> >> Well, not really.  However, if you have:
> >>
> >> 3) PA = 0x2_8000_0000, VA = 0x4000-0000, pv_offset = 0x2-4000-0000
> >>
> >> ... then you need:
> >>
> >> 	mov	phys_hi, #0x2
> >> 	adds	phys_lo, virt, #0x40000000
> >> 	adc	phys_hi, phys_hi, #0
> >>
> >> My question is: how likely is this?
> >>
> >> What is your actual physical memory start address?
> >  Agreed.  In our case we do not have the Physical address crossing across
> >   4GB. So ignoring the carry would have be been OK. But we are
> >  also addressing the other case where it would really crossover.
> >
> >> If we really need to cope with the carry, then the __pv_sign_flag should 
> >> instead be represented in pv_offset directly:
> >>
> >> Taking example #2 above, that would be:
> >>
> >> 	mov	phys_hi, #0x1
> >> 	adds	phys_lo, virt, #0xc0000000
> >> 	adc	phys_hi, phys_hi, #0
> >>
> >> If PA = 0x8000-0000 and VA = 0xc000-0000 then pv_offset is 
> >> 0xffff-ffff-c000-0000, meaning:
> >>
> >> 	mvn	phys_hi, #0
> >> 	add	phys_lo, virt, #0xc0000000
> >> 	adc	phys_hi, phys_hi, #0
> >>
> >> So that would require a special case in the patching code where a mvn 
> >> with 0 is used if the high part of pv_offset is 0xffffffff.
> >>
> >>
> >> Nicolas
> > Extending pv_offset to 64bit is really neat way. When PA > VA, then pv_offset
> > is going to be actual value and not 2's complement. Fine here.
> > When running from higher physical address space, we will always fall here.
> >
> > So for the second case where pv_offset is 0xffffffff .., (PA < VA)
> > is a problem only when we run from lower physical address. So we can safely
> > assume that the higher 32bits of PA are '0' and stub it initially. In this way we
> > can avoid the special case.
>    Sorry, I missed one more point here. In the second case,we should patch it with
>    0x0 when (PA > VA) and with 0xffffffff when (PA < VA).

I don't think I follow you here.

Let's assume:

phys_addr_t __pv_offset = PHYS_START - VIRT_START;

If PA = 0x0-8000-0000 and VA = 0xc000-0000 then
__pv_offset = 0xffff-ffff-c000-0000.

If PA = 0x2-8000-0000 and VA = 0xc000-0000 then
__pv_offset = 0x1-c000-0000.

So the __virt_to_phys() assembly stub could look like:

static inline phys_addr_t __virt_to_phys(unsigned long x)
{
	phys_addr_t t;

	if if (sizeof(phys_addr_t) == 4) {
		__pv_stub(x, t, "add", __PV_BITS_31_24);
	} else {
		__pv_movhi_stub(t);
		__pv_add_carry_stub(x, t);
	}

	return t;
}

And...

#define __pv_movhi_stub(y) \
	__asm__("@ __pv_movhi_stub\n" \
	"1:	mov	%R0, %1\n" \
	"	.pushsection .pv_table,\"a\"\n" \
	"	.long	1b\n" \
	"	.popsection\n" \
	: "=r" (y) \
	: "I" (__PV_BITS_8_0))

#define __pv_add_carry_stub(x, y) \
	__asm__("@ __pv_add_carry_stub\n" \
	"1:	adds	%Q0, %1, %2\n" \
	"	adc	%R0, %R0, #0\n" \
	"	.pushsection .pv_table,\"a\"\n" \
	"	.long	1b\n" \
	"	.popsection\n" \
	: "+r" (y) \
	: "r" (x), "I" (__PV_BITS_31_24) \
	: "cc")

The stub bits such as __PV_BITS_8_0 can be augmented with more bits in 
the middle to determine the type of fixup needed.  The fixup code would 
determine the shift needed on the value, and whether or not the low or 
high word of __pv_offset should be used according to those bits.

Then, in the case where a mov is patched, you need to check if the high 
word of __pv_offset is 0xffffffff and if so the mov should be turned 
into a "mvn rn, #0".

And there you are with all possible cases handled.


Nicolas


From linux at arm.linux.org.uk  Wed Jul 24 16:21:48 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 24 Jul 2013 21:21:48 +0100
Subject: [PATCH] ARM: Fix deadlock scenario with smp_send_stop()
In-Reply-To: <20130724185618.GD27761@codeaurora.org>
References: <1373384217-26307-1-git-send-email-sboyd@codeaurora.org>
 <20130724185618.GD27761@codeaurora.org>
Message-ID: <20130724202148.GA24642@n2100.arm.linux.org.uk>

On Wed, Jul 24, 2013 at 11:56:18AM -0700, Stephen Boyd wrote:
> On 07/09, Stephen Boyd wrote:
> > If one process calls sys_reboot and that process then stops other
> > CPUs while those CPUs are within a spin_lock() region we can
> > potentially encounter a deadlock scenario like below.
> > 
> > CPU 0                   CPU 1
> > -----                   -----
> >                         spin_lock(my_lock)
> > smp_send_stop()
> >  <send IPI>             handle_IPI()
> >                          disable_preemption/irqs
> >                           while(1);
> >  <PREEMPT>
> > spin_lock(my_lock) <--- Waits forever
> > 
> > We shouldn't attempt to run any other tasks after we send a stop
> > IPI to a CPU so disable preemption so that this task runs to
> > completion.
> > 
> > Reported-by: Sundarajan Srinivasan <sundaraj at codeaurora.com>
> > Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> > ---
> > 
> > Resending this patch now that the context has changed.
> 
> Ping? Shall I put this in the patch tracker?

Well, looking at x86, they use local_irq_disable() before sending the
stop, so I think we should do the same for cross-arch consistency.


From sboyd at codeaurora.org  Wed Jul 24 16:29:00 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 13:29:00 -0700
Subject: [PATCH] ARM: Fix deadlock scenario with smp_send_stop()
In-Reply-To: <20130724202148.GA24642@n2100.arm.linux.org.uk>
References: <1373384217-26307-1-git-send-email-sboyd@codeaurora.org>
 <20130724185618.GD27761@codeaurora.org>
 <20130724202148.GA24642@n2100.arm.linux.org.uk>
Message-ID: <51F0390C.7090501@codeaurora.org>

On 07/24/13 13:21, Russell King - ARM Linux wrote:
> On Wed, Jul 24, 2013 at 11:56:18AM -0700, Stephen Boyd wrote:
>> On 07/09, Stephen Boyd wrote:
>>> If one process calls sys_reboot and that process then stops other
>>> CPUs while those CPUs are within a spin_lock() region we can
>>> potentially encounter a deadlock scenario like below.
>>>
>>> CPU 0                   CPU 1
>>> -----                   -----
>>>                         spin_lock(my_lock)
>>> smp_send_stop()
>>>  <send IPI>             handle_IPI()
>>>                          disable_preemption/irqs
>>>                           while(1);
>>>  <PREEMPT>
>>> spin_lock(my_lock) <--- Waits forever
>>>
>>> We shouldn't attempt to run any other tasks after we send a stop
>>> IPI to a CPU so disable preemption so that this task runs to
>>> completion.
>>>
>>> Reported-by: Sundarajan Srinivasan <sundaraj at codeaurora.com>
>>> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>>> ---
>>>
>>> Resending this patch now that the context has changed.
>> Ping? Shall I put this in the patch tracker?
> Well, looking at x86, they use local_irq_disable() before sending the
> stop, so I think we should do the same for cross-arch consistency.

Fair enough. I'll send v2 with that.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From davidb at codeaurora.org  Wed Jul 24 16:29:44 2013
From: davidb at codeaurora.org (David Brown)
Date: Wed, 24 Jul 2013 13:29:44 -0700
Subject: [PATCH 1/4] msm_serial: Fix NUL byte output on UARTDM
In-Reply-To: <1374691051-28544-2-git-send-email-sboyd@codeaurora.org>
References: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
 <1374691051-28544-2-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130724202944.GB10926@codeaurora.org>

On Wed, Jul 24, 2013 at 11:37:28AM -0700, Stephen Boyd wrote:
>UARTDM serial devices require us to wait for the entire TX fifo
>to drain before we can change the contents of the NCF_TX
>register. Furthermore, if we write any characters to the TX fifo
>within the same clock cycle of changing the NCF_TX register the
>NCF_TX register won't latch properly.
>
>To fix these issues we should read back the NCF_TX register to
>delay any TX fifo accesses by a clock cycle and we should wait
>for the TX fifo to drain (instead of just waiting for the fifo to
>be ready to receive more characters). Failure to do so leads to
>random NUL bytes interspersed in the output.
>
>Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>---
> drivers/tty/serial/msm_serial.c | 14 +++++++++-----
> drivers/tty/serial/msm_serial.h |  1 +
> 2 files changed, 10 insertions(+), 5 deletions(-)

Acked-by: David Brown <davidb at codeaurora.org>

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From davidb at codeaurora.org  Wed Jul 24 16:30:03 2013
From: davidb at codeaurora.org (David Brown)
Date: Wed, 24 Jul 2013 13:30:03 -0700
Subject: [PATCH 2/4] msm_serial: Fix sparse warnings
In-Reply-To: <1374691051-28544-3-git-send-email-sboyd@codeaurora.org>
References: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
 <1374691051-28544-3-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130724203003.GC10926@codeaurora.org>

On Wed, Jul 24, 2013 at 11:37:29AM -0700, Stephen Boyd wrote:
>drivers/tty/serial/msm_serial.c:302:6: warning: symbol 'msm_set_mctrl' was
>not declared. Should it be static?
>drivers/tty/serial/msm_serial.c:597:17: warning: incorrect type in argument 2
>(different address spaces)
>drivers/tty/serial/msm_serial.c:597:17: expected void volatile [noderef] <asn:2>*addr
>drivers/tty/serial/msm_serial.c:597:17: got unsigned int *
>drivers/tty/serial/msm_serial.c:608:33: warning: incorrect type in argument 1
>(different address spaces)
>drivers/tty/serial/msm_serial.c:608:33: expected void volatile [noderef] <asn:2>*addr
>drivers/tty/serial/msm_serial.c:608:33: got unsigned int *gsbi_base
>drivers/tty/serial/msm_serial.c:648:37: warning: incorrect type in assignment
>(different address spaces)
>drivers/tty/serial/msm_serial.c:648:37: expected unsigned int *gsbi_base
>drivers/tty/serial/msm_serial.c:648:37: got void [noderef] <asn:2>*
>
>Mark the ioremapped memory as __iomem and use writel instead of
>iowrite because we're not dealing with PCI devices. Also, mark
>msm_set_mctrl() static because it isn't used outside this file.
>
>Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>---
> drivers/tty/serial/msm_serial.c | 17 +++++++----------
> 1 file changed, 7 insertions(+), 10 deletions(-)

Acked-by: David Brown <davidb at codeaurora.org>

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From davidb at codeaurora.org  Wed Jul 24 16:30:26 2013
From: davidb at codeaurora.org (David Brown)
Date: Wed, 24 Jul 2013 13:30:26 -0700
Subject: [PATCH 3/4] msm_serial: Make baud_code detection more dynamic
In-Reply-To: <1374691051-28544-4-git-send-email-sboyd@codeaurora.org>
References: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
 <1374691051-28544-4-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130724203026.GD10926@codeaurora.org>

On Wed, Jul 24, 2013 at 11:37:30AM -0700, Stephen Boyd wrote:
>Currently msm_set_baud_rate() assumes the uart clock rate is
>1.8432 MHz. This is not always true, and limits our options to
>program the baud rate. Instead of assuming the rate and
>hard-coding the baud_code based on it, calculate the divider that
>we want and try to find the closest baud_code that matches. This
>allows us to support uarts with faster clock speeds.
>
>Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>---
> drivers/tty/serial/msm_serial.c | 98 ++++++++++++++++++-----------------------
> drivers/tty/serial/msm_serial.h | 18 ++------
> 2 files changed, 48 insertions(+), 68 deletions(-)

Acked-by: David Brown <davidb at codeaurora.org>

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From davidb at codeaurora.org  Wed Jul 24 16:31:07 2013
From: davidb at codeaurora.org (David Brown)
Date: Wed, 24 Jul 2013 13:31:07 -0700
Subject: [PATCH 4/4] msm_serial: Send more than 1 character at a time on
 UARTDM
In-Reply-To: <1374691051-28544-5-git-send-email-sboyd@codeaurora.org>
References: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
 <1374691051-28544-5-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130724203106.GE10926@codeaurora.org>

On Wed, Jul 24, 2013 at 11:37:31AM -0700, Stephen Boyd wrote:
>UARTDM cores have a TX fifo that can accept more than one
>character per register write, but the msm_serial driver currently
>only supports 1 character mode. Add support for this mode of operation
>to speed up the transmit path on DM devices.
>
>Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>---
> drivers/tty/serial/msm_serial.c | 51 ++++++++++++++++++++++++++---------------
> 1 file changed, 32 insertions(+), 19 deletions(-)

Acked-by: David Brown <davidb at codeaurora.org>

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From davidb at codeaurora.org  Wed Jul 24 16:31:51 2013
From: davidb at codeaurora.org (David Brown)
Date: Wed, 24 Jul 2013 13:31:51 -0700
Subject: [PATCH 0/4] msm_serial fixes and improvements
In-Reply-To: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
References: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130724203151.GF10926@codeaurora.org>

On Wed, Jul 24, 2013 at 11:37:27AM -0700, Stephen Boyd wrote:
>Here are a couple fixes and improvements to the msm_serial
>driver. The first two patches fix a bug on UARTDM devices and
>silence sparse warnings. The last two patches improve the baud
>code detection and increase the throughput on UARTDM devices.
>
>After this it is rather trivial to add support for newer UARTDM
>devices via new compatible fields.
>
>Stephen Boyd (4):
>  msm_serial: Fix NUL byte output on UARTDM
>  msm_serial: Fix sparse warnings
>  msm_serial: Make baud_code detection more dynamic
>  msm_serial: Send more than 1 character at a time on UARTDM
>
> drivers/tty/serial/msm_serial.c | 180 ++++++++++++++++++++--------------------
> drivers/tty/serial/msm_serial.h |  19 ++---
> 2 files changed, 97 insertions(+), 102 deletions(-)

Thanks for these patches.  I'm glad to finally see these issues fixed.

David

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From sboyd at codeaurora.org  Wed Jul 24 16:32:53 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 13:32:53 -0700
Subject: [PATCH v4 0/5] Memory mapped architected timers
In-Reply-To: <20130722170817.GB4833@e106331-lin.cambridge.arm.com>
References: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
 <20130722170817.GB4833@e106331-lin.cambridge.arm.com>
Message-ID: <20130724203253.GE27761@codeaurora.org>

On 07/22, Mark Rutland wrote:
> Hi Stephen,
> 
> On Fri, Jul 19, 2013 at 12:59:27AM +0100, Stephen Boyd wrote:
> > This patchset adds support for memory mapped architected timers. We
> > don't have any other global broadcast timer in our system, so we use the
> > mmio timer during low power modes. The first patch changes the register
> > accessor to an enum per Thomas' request. The second patch is the binding.
> > The next two patches lay some groundwork so that the last patch is simpler.
> > The final patch adds support for mmio timers.
> > 
> > Patches are based on v3.11-rc1.
> 
> Be aware that as of v3.11-rc2 this doesn't cleanly apply, as the
> __cpuinit removal broke the final patch's context in a couple of places.
> It would be nice to get rid of the new cpuinit additions too...
> 
> With that cleaned up locally, I've gave this a spin on tc2 and a
> Foundation model to test the cp15/system timers, hotplugging CPUs and
> running a basic test (`time sleep 5`). That all seems to work.
> 
> Unfortunately I have no way of testing the memory-mapped timer support,
> but I trust you've tested that locally.
> 
> For the series:
> 
> Acked-by: Mark Rutland <mark.rutland at arm.com>
> 

Thanks Mark.

Daniel, can you pick up these patches please?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From sboyd at codeaurora.org  Wed Jul 24 16:36:10 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 13:36:10 -0700
Subject: [PATCH v2] ARM: Fix deadlock scenario with smp_send_stop()
In-Reply-To: <20130724202148.GA24642@n2100.arm.linux.org.uk>
Message-ID: <1374698170-26605-1-git-send-email-sboyd@codeaurora.org>

If one process calls sys_reboot and that process then stops other
CPUs while those CPUs are within a spin_lock() region we can
potentially encounter a deadlock scenario like below.

CPU 0                   CPU 1
-----                   -----
                        spin_lock(my_lock)
smp_send_stop()
 <send IPI>             handle_IPI()
                         disable_preemption/irqs
                          while(1);
 <PREEMPT>
spin_lock(my_lock) <--- Waits forever

We shouldn't attempt to run any other tasks after we send a stop
IPI to a CPU so disable preemption so that this task runs to
completion. We use local_irq_disable() here for cross-arch
consistency with x86.

Reported-by: Sundarajan Srinivasan <sundaraj at codeaurora.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---

Changes since v1:
 - Use local_irq_disable() instead of preempt_disable()

 arch/arm/kernel/process.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index d3ca4f6..08b47eb 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -197,6 +197,7 @@ void machine_shutdown(void)
  */
 void machine_halt(void)
 {
+	local_irq_disable();
 	smp_send_stop();
 
 	local_irq_disable();
@@ -211,6 +212,7 @@ void machine_halt(void)
  */
 void machine_power_off(void)
 {
+	local_irq_disable();
 	smp_send_stop();
 
 	if (pm_power_off)
@@ -230,6 +232,7 @@ void machine_power_off(void)
  */
 void machine_restart(char *cmd)
 {
+	local_irq_disable();
 	smp_send_stop();
 
 	arm_pm_restart(reboot_mode, cmd);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 16:54:27 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 13:54:27 -0700
Subject: [PATCH v2 2/9] ARM: msm: Don't compile __msm_ioremap_caller() unless
 used
In-Reply-To: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374699274-18388-3-git-send-email-sboyd@codeaurora.org>

This function is only used on MSM7x00A so only compile the
function if the build includes support for that platform.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-msm/io.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-msm/io.c b/arch/arm/mach-msm/io.c
index 3dc04cc..4a1a222 100644
--- a/arch/arm/mach-msm/io.c
+++ b/arch/arm/mach-msm/io.c
@@ -168,6 +168,7 @@ void __init msm_map_msm7x30_io(void)
 }
 #endif /* CONFIG_ARCH_MSM7X30 */
 
+#ifdef CONFIG_ARCH_MSM7X00A
 void __iomem *__msm_ioremap_caller(phys_addr_t phys_addr, size_t size,
 				   unsigned int mtype, void *caller)
 {
@@ -182,3 +183,4 @@ void __iomem *__msm_ioremap_caller(phys_addr_t phys_addr, size_t size,
 
 	return __arm_ioremap_caller(phys_addr, size, mtype, caller);
 }
+#endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 16:54:26 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 13:54:26 -0700
Subject: [PATCH v2 1/9] ARM: msm: Remove unused and unmapped MSM_TLMM_BASE for
 8x60
In-Reply-To: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374699274-18388-2-git-send-email-sboyd@codeaurora.org>

From: Rohit Vaswani <rvaswani at codeaurora.org>

MSM_TLMM_BASE is currently not mapped by 8x60. Remove it.

Signed-off-by: Rohit Vaswani <rvaswani at codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-msm/include/mach/msm_iomap-8x60.h | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h b/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h
index 75a7b62..4f57b43 100644
--- a/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h
+++ b/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h
@@ -35,10 +35,6 @@
  *
  */
 
-#define MSM_TLMM_BASE		IOMEM(0xF0004000)
-#define MSM_TLMM_PHYS		0x00800000
-#define MSM_TLMM_SIZE		SZ_16K
-
 #define MSM8X60_TMR_PHYS	0x02000000
 #define MSM8X60_TMR_SIZE	SZ_4K
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 16:54:25 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 13:54:25 -0700
Subject: [PATCH v2 0/9] Move MSM closer to multi-platform
Message-ID: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>

These are a set of patches that move MSM closer to multi-platform
but still keep everything compiling. We still have to tackle
reset and dma, but these patches shouldn't be controversial.

Rohit Vaswani (1):
  ARM: msm: Remove unused and unmapped MSM_TLMM_BASE for 8x60

Stephen Boyd (8):
  ARM: msm: Don't compile __msm_ioremap_caller() unless used
  ARM: msm: Move debug-macro.S to include/debug
  ARM: msm: Remove TMR and TMR0 static mappings
  ARM: msm: Migrate msm_timer to CLOCKSOURCE_OF_DECLARE
  ARM: msm: Move mach/board.h contents to common.h
  ARM: msm: Remove devices-iommu.c
  iommu/msm: Move mach includes to iommu directory
  ARM: msm: Only compile io.c on platforms that use it

 arch/arm/Kconfig                                   |   1 +
 arch/arm/Kconfig.debug                             |   9 +-
 .../mach/debug-macro.S => include/debug/msm.S}     |  32 +-
 arch/arm/mach-msm/Makefile                         |   9 +-
 arch/arm/mach-msm/board-dt-8660.c                  |   4 +-
 arch/arm/mach-msm/board-dt-8960.c                  |   3 +-
 arch/arm/mach-msm/board-halibut.c                  |   1 -
 arch/arm/mach-msm/board-mahimahi.c                 |   2 +-
 arch/arm/mach-msm/board-msm7x30.c                  |   1 -
 arch/arm/mach-msm/board-qsd8x50.c                  |   1 -
 arch/arm/mach-msm/board-sapphire.c                 |   2 +-
 arch/arm/mach-msm/board-trout.c                    |   1 -
 arch/arm/mach-msm/board-trout.h                    |   2 +-
 arch/arm/mach-msm/common.h                         |  18 +-
 arch/arm/mach-msm/devices-iommu.c                  | 912 ---------------------
 arch/arm/mach-msm/devices-msm7x30.c                |   2 +-
 arch/arm/mach-msm/devices-qsd8x50.c                |   2 +-
 arch/arm/mach-msm/include/mach/board.h             |  38 -
 arch/arm/mach-msm/include/mach/msm_iomap-8960.h    |  46 --
 arch/arm/mach-msm/include/mach/msm_iomap-8x60.h    |  53 --
 arch/arm/mach-msm/include/mach/msm_iomap.h         |  17 -
 arch/arm/mach-msm/include/mach/uncompress.h        |  63 --
 arch/arm/mach-msm/io.c                             |  67 +-
 arch/arm/mach-msm/timer.c                          |  17 +-
 drivers/iommu/msm_iommu.c                          |   4 +-
 .../mach/iommu.h => drivers/iommu/msm_iommu.h      |   0
 drivers/iommu/msm_iommu_dev.c                      |   4 +-
 .../iommu/msm_iommu_hw-8xxx.h                      |   0
 drivers/video/msm/msm_fb.c                         |   1 -
 29 files changed, 93 insertions(+), 1219 deletions(-)
 rename arch/arm/{mach-msm/include/mach/debug-macro.S => include/debug/msm.S} (61%)
 delete mode 100644 arch/arm/mach-msm/devices-iommu.c
 delete mode 100644 arch/arm/mach-msm/include/mach/board.h
 delete mode 100644 arch/arm/mach-msm/include/mach/msm_iomap-8960.h
 delete mode 100644 arch/arm/mach-msm/include/mach/msm_iomap-8x60.h
 delete mode 100644 arch/arm/mach-msm/include/mach/uncompress.h
 rename arch/arm/mach-msm/include/mach/iommu.h => drivers/iommu/msm_iommu.h (100%)
 rename arch/arm/mach-msm/include/mach/iommu_hw-8xxx.h => drivers/iommu/msm_iommu_hw-8xxx.h (100%)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 16:54:29 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 13:54:29 -0700
Subject: [PATCH v2 4/9] ARM: msm: Remove TMR and TMR0 static mappings
In-Reply-To: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374699274-18388-5-git-send-email-sboyd@codeaurora.org>

Nobody is using these mappings so just drop them. of_iomap() in
the timer driver will take care of it for us. Doing this allows
us to remove the 8x60 and 8960 iomap files completely.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-msm/board-dt-8660.c               |  2 +-
 arch/arm/mach-msm/board-dt-8960.c               |  2 +-
 arch/arm/mach-msm/common.h                      |  2 --
 arch/arm/mach-msm/include/mach/msm_iomap-8960.h | 41 -----------------------
 arch/arm/mach-msm/include/mach/msm_iomap-8x60.h | 44 -------------------------
 arch/arm/mach-msm/include/mach/msm_iomap.h      |  5 ---
 arch/arm/mach-msm/io.c                          | 26 ---------------
 7 files changed, 2 insertions(+), 120 deletions(-)
 delete mode 100644 arch/arm/mach-msm/include/mach/msm_iomap-8960.h
 delete mode 100644 arch/arm/mach-msm/include/mach/msm_iomap-8x60.h

diff --git a/arch/arm/mach-msm/board-dt-8660.c b/arch/arm/mach-msm/board-dt-8660.c
index 492f5cd..f1d9c82 100644
--- a/arch/arm/mach-msm/board-dt-8660.c
+++ b/arch/arm/mach-msm/board-dt-8660.c
@@ -15,6 +15,7 @@
 #include <linux/of_platform.h>
 
 #include <asm/mach/arch.h>
+#include <asm/mach/map.h>
 
 #include <mach/board.h>
 #include "common.h"
@@ -42,7 +43,6 @@ static const char *msm8x60_fluid_match[] __initdata = {
 
 DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
 	.smp = smp_ops(msm_smp_ops),
-	.map_io = msm_map_msm8x60_io,
 	.init_machine = msm8x60_dt_init,
 	.init_late = msm8x60_init_late,
 	.init_time	= msm_dt_timer_init,
diff --git a/arch/arm/mach-msm/board-dt-8960.c b/arch/arm/mach-msm/board-dt-8960.c
index bb55309..f930eaf 100644
--- a/arch/arm/mach-msm/board-dt-8960.c
+++ b/arch/arm/mach-msm/board-dt-8960.c
@@ -14,6 +14,7 @@
 #include <linux/of_platform.h>
 
 #include <asm/mach/arch.h>
+#include <asm/mach/map.h>
 
 #include "common.h"
 
@@ -29,7 +30,6 @@ static const char * const msm8960_dt_match[] __initconst = {
 
 DT_MACHINE_START(MSM8960_DT, "Qualcomm MSM (Flattened Device Tree)")
 	.smp = smp_ops(msm_smp_ops),
-	.map_io = msm_map_msm8960_io,
 	.init_time	= msm_dt_timer_init,
 	.init_machine = msm_dt_init,
 	.dt_compat = msm8960_dt_match,
diff --git a/arch/arm/mach-msm/common.h b/arch/arm/mach-msm/common.h
index 421cf77..569bd16 100644
--- a/arch/arm/mach-msm/common.h
+++ b/arch/arm/mach-msm/common.h
@@ -19,8 +19,6 @@ extern void qsd8x50_timer_init(void);
 
 extern void msm_map_common_io(void);
 extern void msm_map_msm7x30_io(void);
-extern void msm_map_msm8x60_io(void);
-extern void msm_map_msm8960_io(void);
 extern void msm_map_qsd8x50_io(void);
 
 extern void __iomem *__msm_ioremap_caller(phys_addr_t phys_addr, size_t size,
diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-8960.h b/arch/arm/mach-msm/include/mach/msm_iomap-8960.h
deleted file mode 100644
index 396958b..0000000
--- a/arch/arm/mach-msm/include/mach/msm_iomap-8960.h
+++ /dev/null
@@ -1,41 +0,0 @@
-/*
- * Copyright (C) 2007 Google, Inc.
- * Copyright (c) 2008-2011, Code Aurora Forum. All rights reserved.
- * Author: Brian Swetland <swetland at google.com>
- *
- * 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.
- *
- *
- * The MSM peripherals are spread all over across 768MB of physical
- * space, which makes just having a simple IO_ADDRESS macro to slide
- * them into the right virtual location rough.  Instead, we will
- * provide a master phys->virt mapping for peripherals here.
- *
- */
-
-#ifndef __ASM_ARCH_MSM_IOMAP_8960_H
-#define __ASM_ARCH_MSM_IOMAP_8960_H
-
-/* Physical base address and size of peripherals.
- * Ordered by the virtual base addresses they will be mapped at.
- *
- * If you add or remove entries here, you'll want to edit the
- * msm_io_desc array in arch/arm/mach-msm/io.c to reflect your
- * changes.
- *
- */
-
-#define MSM8960_TMR_PHYS	0x0200A000
-#define MSM8960_TMR_SIZE	SZ_4K
-
-#define MSM8960_TMR0_PHYS	0x0208A000
-#define MSM8960_TMR0_SIZE	SZ_4K
-
-#endif
diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h b/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h
deleted file mode 100644
index dede6aa..0000000
--- a/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * Copyright (C) 2007 Google, Inc.
- * Copyright (c) 2008-2011, Code Aurora Forum. All rights reserved.
- * Author: Brian Swetland <swetland at google.com>
- *
- * 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.
- *
- *
- * The MSM peripherals are spread all over across 768MB of physical
- * space, which makes just having a simple IO_ADDRESS macro to slide
- * them into the right virtual location rough.  Instead, we will
- * provide a master phys->virt mapping for peripherals here.
- *
- */
-
-#ifndef __ASM_ARCH_MSM_IOMAP_8X60_H
-#define __ASM_ARCH_MSM_IOMAP_8X60_H
-
-/* Physical base address and size of peripherals.
- * Ordered by the virtual base addresses they will be mapped at.
- *
- * MSM_VIC_BASE must be an value that can be loaded via a "mov"
- * instruction, otherwise entry-macro.S will not compile.
- *
- * If you add or remove entries here, you'll want to edit the
- * msm_io_desc array in arch/arm/mach-msm/io.c to reflect your
- * changes.
- *
- */
-
-#define MSM8X60_TMR_PHYS	0x02000000
-#define MSM8X60_TMR_SIZE	SZ_4K
-
-#define MSM8X60_TMR0_PHYS	0x02040000
-#define MSM8X60_TMR0_SIZE	SZ_4K
-
-#endif
diff --git a/arch/arm/mach-msm/include/mach/msm_iomap.h b/arch/arm/mach-msm/include/mach/msm_iomap.h
index 0b36c42..0e4f491 100644
--- a/arch/arm/mach-msm/include/mach/msm_iomap.h
+++ b/arch/arm/mach-msm/include/mach/msm_iomap.h
@@ -45,13 +45,8 @@
 #include "msm_iomap-7x00.h"
 #endif
 
-#include "msm_iomap-8x60.h"
-#include "msm_iomap-8960.h"
-
 /* Virtual addresses shared across all MSM targets. */
 #define MSM_CSR_BASE		IOMEM(0xE0001000)
-#define MSM_TMR_BASE		IOMEM(0xF0200000)
-#define MSM_TMR0_BASE		IOMEM(0xF0201000)
 #define MSM_GPIO1_BASE		IOMEM(0xE0003000)
 #define MSM_GPIO2_BASE		IOMEM(0xE0004000)
 
diff --git a/arch/arm/mach-msm/io.c b/arch/arm/mach-msm/io.c
index 66acb98..c632c87 100644
--- a/arch/arm/mach-msm/io.c
+++ b/arch/arm/mach-msm/io.c
@@ -114,32 +114,6 @@ void __init msm_map_qsd8x50_io(void)
 }
 #endif /* CONFIG_ARCH_QSD8X50 */
 
-#ifdef CONFIG_ARCH_MSM8X60
-static struct map_desc msm8x60_io_desc[] __initdata = {
-	MSM_CHIP_DEVICE(TMR, MSM8X60),
-	MSM_CHIP_DEVICE(TMR0, MSM8X60),
-};
-
-void __init msm_map_msm8x60_io(void)
-{
-	debug_ll_io_init();
-	iotable_init(msm8x60_io_desc, ARRAY_SIZE(msm8x60_io_desc));
-}
-#endif /* CONFIG_ARCH_MSM8X60 */
-
-#ifdef CONFIG_ARCH_MSM8960
-static struct map_desc msm8960_io_desc[] __initdata = {
-	MSM_CHIP_DEVICE(TMR, MSM8960),
-	MSM_CHIP_DEVICE(TMR0, MSM8960),
-};
-
-void __init msm_map_msm8960_io(void)
-{
-	debug_ll_io_init();
-	iotable_init(msm8960_io_desc, ARRAY_SIZE(msm8960_io_desc));
-}
-#endif /* CONFIG_ARCH_MSM8960 */
-
 #ifdef CONFIG_ARCH_MSM7X30
 static struct map_desc msm7x30_io_desc[] __initdata = {
 	MSM_DEVICE(VIC),
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 16:54:28 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 13:54:28 -0700
Subject: [PATCH v2 3/9] ARM: msm: Move debug-macro.S to include/debug
In-Reply-To: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374699274-18388-4-git-send-email-sboyd@codeaurora.org>

One more step to allowing MSM to participate in the
multi-platform defconfig.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/Kconfig.debug                             |  9 +++-
 .../mach/debug-macro.S => include/debug/msm.S}     | 32 ++++++++++-
 arch/arm/mach-msm/include/mach/msm_iomap-8960.h    |  5 --
 arch/arm/mach-msm/include/mach/msm_iomap-8x60.h    |  5 --
 arch/arm/mach-msm/include/mach/msm_iomap.h         | 12 -----
 arch/arm/mach-msm/include/mach/uncompress.h        | 63 ----------------------
 arch/arm/mach-msm/io.c                             | 40 +++++++-------
 7 files changed, 58 insertions(+), 108 deletions(-)
 rename arch/arm/{mach-msm/include/mach/debug-macro.S => include/debug/msm.S} (61%)
 delete mode 100644 arch/arm/mach-msm/include/mach/uncompress.h

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e401a76..4a62a8d 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -777,6 +777,11 @@ config DEBUG_LL_INCLUDE
 				 DEBUG_IMX6SL_UART
 	default "debug/keystone.S" if DEBUG_KEYSTONE_UART0 || \
 				      DEBUG_KEYSTONE_UART1
+	default "debug/msm.S" if DEBUG_MSM_UART1 || \
+				 DEBUG_MSM_UART2 || \
+				 DEBUG_MSM_UART3 || \
+				 DEBUG_MSM8660_UART || \
+				 DEBUG_MSM8960_UART
 	default "debug/mvebu.S" if DEBUG_MVEBU_UART || \
 				   DEBUG_MVEBU_UART_ALTERNATE
 	default "debug/mxs.S" if DEBUG_IMX23_UART || DEBUG_IMX28_UART
@@ -804,13 +809,13 @@ config DEBUG_LL_INCLUDE
 
 config DEBUG_UNCOMPRESS
 	bool
-	default y if ARCH_MULTIPLATFORM && DEBUG_LL && \
+	default y if (ARCH_MULTIPLATFORM || ARCH_MSM) && DEBUG_LL && \
 		     !DEBUG_OMAP2PLUS_UART && \
 		     !DEBUG_TEGRA_UART
 
 config UNCOMPRESS_INCLUDE
 	string
-	default "debug/uncompress.h" if ARCH_MULTIPLATFORM
+	default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM
 	default "mach/uncompress.h"
 
 config EARLY_PRINTK
diff --git a/arch/arm/mach-msm/include/mach/debug-macro.S b/arch/arm/include/debug/msm.S
similarity index 61%
rename from arch/arm/mach-msm/include/mach/debug-macro.S
rename to arch/arm/include/debug/msm.S
index 0e05f88..9166e1b 100644
--- a/arch/arm/mach-msm/include/mach/debug-macro.S
+++ b/arch/arm/include/debug/msm.S
@@ -15,8 +15,36 @@
  *
  */
 
-#include <mach/hardware.h>
-#include <mach/msm_iomap.h>
+#if defined(CONFIG_ARCH_MSM7X00A) || defined(CONFIG_ARCH_QSD8X50)
+#define MSM_UART1_PHYS        0xA9A00000
+#define MSM_UART2_PHYS        0xA9B00000
+#define MSM_UART3_PHYS        0xA9C00000
+#elif defined(CONFIG_ARCH_MSM7X30)
+#define MSM_UART1_PHYS        0xACA00000
+#define MSM_UART2_PHYS        0xACB00000
+#define MSM_UART3_PHYS        0xACC00000
+#endif
+
+#if defined(CONFIG_DEBUG_MSM_UART1)
+#define MSM_DEBUG_UART_BASE	0xE1000000
+#define MSM_DEBUG_UART_PHYS	MSM_UART1_PHYS
+#elif defined(CONFIG_DEBUG_MSM_UART2)
+#define MSM_DEBUG_UART_BASE	0xE1000000
+#define MSM_DEBUG_UART_PHYS	MSM_UART2_PHYS
+#elif defined(CONFIG_DEBUG_MSM_UART3)
+#define MSM_DEBUG_UART_BASE	0xE1000000
+#define MSM_DEBUG_UART_PHYS	MSM_UART3_PHYS
+#endif
+
+#ifdef CONFIG_DEBUG_MSM8660_UART
+#define MSM_DEBUG_UART_BASE	0xF0040000
+#define MSM_DEBUG_UART_PHYS	0x19C40000
+#endif
+
+#ifdef CONFIG_DEBUG_MSM8960_UART
+#define MSM_DEBUG_UART_BASE	0xF0040000
+#define MSM_DEBUG_UART_PHYS	0x16440000
+#endif
 
 	.macro	addruart, rp, rv, tmp
 #ifdef MSM_DEBUG_UART_PHYS
diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-8960.h b/arch/arm/mach-msm/include/mach/msm_iomap-8960.h
index 7bca8d7..396958b 100644
--- a/arch/arm/mach-msm/include/mach/msm_iomap-8960.h
+++ b/arch/arm/mach-msm/include/mach/msm_iomap-8960.h
@@ -38,9 +38,4 @@
 #define MSM8960_TMR0_PHYS	0x0208A000
 #define MSM8960_TMR0_SIZE	SZ_4K
 
-#ifdef CONFIG_DEBUG_MSM8960_UART
-#define MSM_DEBUG_UART_BASE	0xF0040000
-#define MSM_DEBUG_UART_PHYS	0x16440000
-#endif
-
 #endif
diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h b/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h
index 4f57b43..dede6aa 100644
--- a/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h
+++ b/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h
@@ -41,9 +41,4 @@
 #define MSM8X60_TMR0_PHYS	0x02040000
 #define MSM8X60_TMR0_SIZE	SZ_4K
 
-#ifdef CONFIG_DEBUG_MSM8660_UART
-#define MSM_DEBUG_UART_BASE	0xF0040000
-#define MSM_DEBUG_UART_PHYS	0x19C40000
-#endif
-
 #endif
diff --git a/arch/arm/mach-msm/include/mach/msm_iomap.h b/arch/arm/mach-msm/include/mach/msm_iomap.h
index c56e81f..0b36c42 100644
--- a/arch/arm/mach-msm/include/mach/msm_iomap.h
+++ b/arch/arm/mach-msm/include/mach/msm_iomap.h
@@ -48,18 +48,6 @@
 #include "msm_iomap-8x60.h"
 #include "msm_iomap-8960.h"
 
-#define MSM_DEBUG_UART_SIZE	SZ_4K
-#if defined(CONFIG_DEBUG_MSM_UART1)
-#define MSM_DEBUG_UART_BASE	0xE1000000
-#define MSM_DEBUG_UART_PHYS	MSM_UART1_PHYS
-#elif defined(CONFIG_DEBUG_MSM_UART2)
-#define MSM_DEBUG_UART_BASE	0xE1000000
-#define MSM_DEBUG_UART_PHYS	MSM_UART2_PHYS
-#elif defined(CONFIG_DEBUG_MSM_UART3)
-#define MSM_DEBUG_UART_BASE	0xE1000000
-#define MSM_DEBUG_UART_PHYS	MSM_UART3_PHYS
-#endif
-
 /* Virtual addresses shared across all MSM targets. */
 #define MSM_CSR_BASE		IOMEM(0xE0001000)
 #define MSM_TMR_BASE		IOMEM(0xF0200000)
diff --git a/arch/arm/mach-msm/include/mach/uncompress.h b/arch/arm/mach-msm/include/mach/uncompress.h
deleted file mode 100644
index 9432487..0000000
--- a/arch/arm/mach-msm/include/mach/uncompress.h
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
- * Copyright (C) 2007 Google, Inc.
- * Copyright (c) 2011, Code Aurora Forum. All rights reserved.
- *
- * 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 __ASM_ARCH_MSM_UNCOMPRESS_H
-#define __ASM_ARCH_MSM_UNCOMPRESS_H
-
-#include <asm/barrier.h>
-#include <asm/processor.h>
-#include <mach/msm_iomap.h>
-
-#define UART_CSR      (*(volatile uint32_t *)(MSM_DEBUG_UART_PHYS + 0x08))
-#define UART_TF       (*(volatile uint32_t *)(MSM_DEBUG_UART_PHYS + 0x0c))
-
-#define UART_DM_SR    (*((volatile uint32_t *)(MSM_DEBUG_UART_PHYS + 0x08)))
-#define UART_DM_CR    (*((volatile uint32_t *)(MSM_DEBUG_UART_PHYS + 0x10)))
-#define UART_DM_ISR   (*((volatile uint32_t *)(MSM_DEBUG_UART_PHYS + 0x14)))
-#define UART_DM_NCHAR (*((volatile uint32_t *)(MSM_DEBUG_UART_PHYS + 0x40)))
-#define UART_DM_TF    (*((volatile uint32_t *)(MSM_DEBUG_UART_PHYS + 0x70)))
-
-static void putc(int c)
-{
-#if defined(MSM_DEBUG_UART_PHYS)
-#ifdef CONFIG_MSM_HAS_DEBUG_UART_HS
-	/*
-	 * Wait for TX_READY to be set; but skip it if we have a
-	 * TX underrun.
-	 */
-	if (!(UART_DM_SR & 0x08))
-		while (!(UART_DM_ISR & 0x80))
-			cpu_relax();
-
-	UART_DM_CR = 0x300;
-	UART_DM_NCHAR = 0x1;
-	UART_DM_TF = c;
-#else
-	while (!(UART_CSR & 0x04))
-		cpu_relax();
-	UART_TF = c;
-#endif
-#endif
-}
-
-static inline void flush(void)
-{
-}
-
-static inline void arch_decomp_setup(void)
-{
-}
-
-#endif
diff --git a/arch/arm/mach-msm/io.c b/arch/arm/mach-msm/io.c
index 4a1a222..66acb98 100644
--- a/arch/arm/mach-msm/io.c
+++ b/arch/arm/mach-msm/io.c
@@ -52,26 +52,38 @@ static struct map_desc msm_io_desc[] __initdata = {
 	MSM_CHIP_DEVICE_TYPE(GPIO1, MSM7X00, MT_DEVICE_NONSHARED),
 	MSM_CHIP_DEVICE_TYPE(GPIO2, MSM7X00, MT_DEVICE_NONSHARED),
 	MSM_DEVICE_TYPE(CLK_CTL, MT_DEVICE_NONSHARED),
-#if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
-	defined(CONFIG_DEBUG_MSM_UART3)
-	MSM_DEVICE_TYPE(DEBUG_UART, MT_DEVICE_NONSHARED),
-#endif
 	{
 		.virtual =  (unsigned long) MSM_SHARED_RAM_BASE,
 		.pfn = __phys_to_pfn(MSM_SHARED_RAM_PHYS),
 		.length =   MSM_SHARED_RAM_SIZE,
 		.type =     MT_DEVICE,
 	},
+#if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
+		defined(CONFIG_DEBUG_MSM_UART3)
+	{
+		/* virtual and pfn filled in by debug_ll_addr() */
+		.length = SZ_4K,
+		.type = MT_DEVICE_NONSHARED,
+	}
+#endif
 };
 
 void __init msm_map_common_io(void)
 {
+	size_t size = ARRAY_SIZE(msm_io_desc);
+
 	/* Make sure the peripheral register window is closed, since
 	 * we will use PTE flags (TEX[1]=1,B=0,C=1) to determine which
 	 * pages are peripheral interface or not.
 	 */
 	asm("mcr p15, 0, %0, c15, c2, 4" : : "r" (0));
-	iotable_init(msm_io_desc, ARRAY_SIZE(msm_io_desc));
+#if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
+		defined(CONFIG_DEBUG_MSM_UART3)
+	debug_ll_addr(&msm_io_desc[size - 1].pfn,
+		      &msm_io_desc[size - 1].virtual);
+	msm_io_desc[size - 1].pfn = __phys_to_pfn(msm_io_desc[size - 1].pfn);
+#endif
+	iotable_init(msm_io_desc, size);
 }
 #endif
 
@@ -87,10 +99,6 @@ static struct map_desc qsd8x50_io_desc[] __initdata = {
 	MSM_DEVICE(SCPLL),
 	MSM_DEVICE(AD5),
 	MSM_DEVICE(MDC),
-#if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
-	defined(CONFIG_DEBUG_MSM_UART3)
-	MSM_DEVICE(DEBUG_UART),
-#endif
 	{
 		.virtual =  (unsigned long) MSM_SHARED_RAM_BASE,
 		.pfn = __phys_to_pfn(MSM_SHARED_RAM_PHYS),
@@ -101,6 +109,7 @@ static struct map_desc qsd8x50_io_desc[] __initdata = {
 
 void __init msm_map_qsd8x50_io(void)
 {
+	debug_ll_io_init();
 	iotable_init(qsd8x50_io_desc, ARRAY_SIZE(qsd8x50_io_desc));
 }
 #endif /* CONFIG_ARCH_QSD8X50 */
@@ -109,13 +118,11 @@ void __init msm_map_qsd8x50_io(void)
 static struct map_desc msm8x60_io_desc[] __initdata = {
 	MSM_CHIP_DEVICE(TMR, MSM8X60),
 	MSM_CHIP_DEVICE(TMR0, MSM8X60),
-#ifdef CONFIG_DEBUG_MSM8660_UART
-	MSM_DEVICE(DEBUG_UART),
-#endif
 };
 
 void __init msm_map_msm8x60_io(void)
 {
+	debug_ll_io_init();
 	iotable_init(msm8x60_io_desc, ARRAY_SIZE(msm8x60_io_desc));
 }
 #endif /* CONFIG_ARCH_MSM8X60 */
@@ -124,13 +131,11 @@ void __init msm_map_msm8x60_io(void)
 static struct map_desc msm8960_io_desc[] __initdata = {
 	MSM_CHIP_DEVICE(TMR, MSM8960),
 	MSM_CHIP_DEVICE(TMR0, MSM8960),
-#ifdef CONFIG_DEBUG_MSM8960_UART
-	MSM_DEVICE(DEBUG_UART),
-#endif
 };
 
 void __init msm_map_msm8960_io(void)
 {
+	debug_ll_io_init();
 	iotable_init(msm8960_io_desc, ARRAY_SIZE(msm8960_io_desc));
 }
 #endif /* CONFIG_ARCH_MSM8960 */
@@ -150,10 +155,6 @@ static struct map_desc msm7x30_io_desc[] __initdata = {
 	MSM_DEVICE(SAW),
 	MSM_DEVICE(GCC),
 	MSM_DEVICE(TCSR),
-#if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
-	defined(CONFIG_DEBUG_MSM_UART3)
-	MSM_DEVICE(DEBUG_UART),
-#endif
 	{
 		.virtual =  (unsigned long) MSM_SHARED_RAM_BASE,
 		.pfn = __phys_to_pfn(MSM_SHARED_RAM_PHYS),
@@ -164,6 +165,7 @@ static struct map_desc msm7x30_io_desc[] __initdata = {
 
 void __init msm_map_msm7x30_io(void)
 {
+	debug_ll_io_init();
 	iotable_init(msm7x30_io_desc, ARRAY_SIZE(msm7x30_io_desc));
 }
 #endif /* CONFIG_ARCH_MSM7X30 */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 16:54:34 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 13:54:34 -0700
Subject: [PATCH v2 9/9] ARM: msm: Only compile io.c on platforms that use it
In-Reply-To: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374699274-18388-10-git-send-email-sboyd@codeaurora.org>

Only the non-dt based MSM platforms need to map memory from their
machine descriptor. Unfortunately it is always compiled if
ARCH_MSM=y and the file also has mach/ includes in it. Since
dt-based MSM platforms aren't actually using anything in this
file just compile io.c on the non-dt based MSM platforms. This
allows the dt-based platforms to participate in the
multi-platform kernel.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-msm/Makefile | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index 4c248ba..d872634c 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -1,4 +1,4 @@
-obj-y += io.o timer.o
+obj-y += timer.o
 obj-y += clock.o
 
 obj-$(CONFIG_MSM_VIC) += irq-vic.o
@@ -8,9 +8,9 @@ obj-$(CONFIG_ARCH_QSD8X50) += sirc.o
 
 obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o
 
-obj-$(CONFIG_ARCH_MSM7X00A) += dma.o
-obj-$(CONFIG_ARCH_MSM7X30) += dma.o
-obj-$(CONFIG_ARCH_QSD8X50) += dma.o
+obj-$(CONFIG_ARCH_MSM7X00A) += dma.o io.o
+obj-$(CONFIG_ARCH_MSM7X30) += dma.o io.o
+obj-$(CONFIG_ARCH_QSD8X50) += dma.o io.o
 
 obj-$(CONFIG_MSM_SMD) += smd.o smd_debug.o
 obj-$(CONFIG_MSM_SMD) += last_radio_log.o
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 16:54:30 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 13:54:30 -0700
Subject: [PATCH v2 5/9] ARM: msm: Migrate msm_timer to CLOCKSOURCE_OF_DECLARE
In-Reply-To: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374699274-18388-6-git-send-email-sboyd@codeaurora.org>

This allows us to remove the init_time callback in the DT machine
descriptors, shrinking the code.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/Kconfig                  |  1 +
 arch/arm/mach-msm/board-dt-8660.c |  1 -
 arch/arm/mach-msm/board-dt-8960.c |  1 -
 arch/arm/mach-msm/common.h        |  1 -
 arch/arm/mach-msm/timer.c         | 17 +++--------------
 5 files changed, 4 insertions(+), 17 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..36dfd06 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -630,6 +630,7 @@ config ARCH_MSM
 	bool "Qualcomm MSM"
 	select ARCH_REQUIRE_GPIOLIB
 	select CLKDEV_LOOKUP
+	select CLKSRC_OF if OF
 	select COMMON_CLK
 	select GENERIC_CLOCKEVENTS
 	help
diff --git a/arch/arm/mach-msm/board-dt-8660.c b/arch/arm/mach-msm/board-dt-8660.c
index f1d9c82..95f9cae 100644
--- a/arch/arm/mach-msm/board-dt-8660.c
+++ b/arch/arm/mach-msm/board-dt-8660.c
@@ -45,6 +45,5 @@ DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
 	.smp = smp_ops(msm_smp_ops),
 	.init_machine = msm8x60_dt_init,
 	.init_late = msm8x60_init_late,
-	.init_time	= msm_dt_timer_init,
 	.dt_compat = msm8x60_fluid_match,
 MACHINE_END
diff --git a/arch/arm/mach-msm/board-dt-8960.c b/arch/arm/mach-msm/board-dt-8960.c
index f930eaf..d4ca52c 100644
--- a/arch/arm/mach-msm/board-dt-8960.c
+++ b/arch/arm/mach-msm/board-dt-8960.c
@@ -30,7 +30,6 @@ static const char * const msm8960_dt_match[] __initconst = {
 
 DT_MACHINE_START(MSM8960_DT, "Qualcomm MSM (Flattened Device Tree)")
 	.smp = smp_ops(msm_smp_ops),
-	.init_time	= msm_dt_timer_init,
 	.init_machine = msm_dt_init,
 	.dt_compat = msm8960_dt_match,
 MACHINE_END
diff --git a/arch/arm/mach-msm/common.h b/arch/arm/mach-msm/common.h
index 569bd16..20ebf87 100644
--- a/arch/arm/mach-msm/common.h
+++ b/arch/arm/mach-msm/common.h
@@ -14,7 +14,6 @@
 
 extern void msm7x01_timer_init(void);
 extern void msm7x30_timer_init(void);
-extern void msm_dt_timer_init(void);
 extern void qsd8x50_timer_init(void);
 
 extern void msm_map_common_io(void);
diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 8697cfc..57a9aec 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -219,15 +219,8 @@ err:
 }
 
 #ifdef CONFIG_OF
-static const struct of_device_id msm_timer_match[] __initconst = {
-	{ .compatible = "qcom,kpss-timer" },
-	{ .compatible = "qcom,scss-timer" },
-	{ },
-};
-
-void __init msm_dt_timer_init(void)
+static void __init msm_dt_timer_init(struct device_node *np)
 {
-	struct device_node *np;
 	u32 freq;
 	int irq;
 	struct resource res;
@@ -235,12 +228,6 @@ void __init msm_dt_timer_init(void)
 	void __iomem *base;
 	void __iomem *cpu0_base;
 
-	np = of_find_matching_node(NULL, msm_timer_match);
-	if (!np) {
-		pr_err("Can't find msm timer DT node\n");
-		return;
-	}
-
 	base = of_iomap(np, 0);
 	if (!base) {
 		pr_err("Failed to map event base\n");
@@ -283,6 +270,8 @@ void __init msm_dt_timer_init(void)
 
 	msm_timer_init(freq, 32, irq, !!percpu_offset);
 }
+CLOCKSOURCE_OF_DECLARE(kpss_timer, "qcom,kpss-timer", msm_dt_timer_init);
+CLOCKSOURCE_OF_DECLARE(scss_timer, "qcom,scss-timer", msm_dt_timer_init);
 #endif
 
 static int __init msm_timer_map(phys_addr_t addr, u32 event, u32 source,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 16:54:33 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 13:54:33 -0700
Subject: [PATCH v2 8/9] iommu/msm: Move mach includes to iommu directory
In-Reply-To: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374699274-18388-9-git-send-email-sboyd@codeaurora.org>

Two header files exist in mach-msm's include/mach directory that
are only used by the MSM iommu driver. Move these files to the
iommu driver directory and prefix them with "msm_". This allows
us to compile the MSM iommu driver on multi-platform kernels.

Acked-by: Joerg Roedel <joro at 8bytes.org>
Cc: Stepan Moskovchenko <stepanm at codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/iommu/msm_iommu.c                                             | 4 ++--
 arch/arm/mach-msm/include/mach/iommu.h => drivers/iommu/msm_iommu.h   | 0
 drivers/iommu/msm_iommu_dev.c                                         | 4 ++--
 .../include/mach/iommu_hw-8xxx.h => drivers/iommu/msm_iommu_hw-8xxx.h | 0
 4 files changed, 4 insertions(+), 4 deletions(-)
 rename arch/arm/mach-msm/include/mach/iommu.h => drivers/iommu/msm_iommu.h (100%)
 rename arch/arm/mach-msm/include/mach/iommu_hw-8xxx.h => drivers/iommu/msm_iommu_hw-8xxx.h (100%)

diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 8ab4f41..f5ff657 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -31,8 +31,8 @@
 #include <asm/cacheflush.h>
 #include <asm/sizes.h>
 
-#include <mach/iommu_hw-8xxx.h>
-#include <mach/iommu.h>
+#include "msm_iommu_hw-8xxx.h"
+#include "msm_iommu.h"
 
 #define MRC(reg, processor, op1, crn, crm, op2)				\
 __asm__ __volatile__ (							\
diff --git a/arch/arm/mach-msm/include/mach/iommu.h b/drivers/iommu/msm_iommu.h
similarity index 100%
rename from arch/arm/mach-msm/include/mach/iommu.h
rename to drivers/iommu/msm_iommu.h
diff --git a/drivers/iommu/msm_iommu_dev.c b/drivers/iommu/msm_iommu_dev.c
index 6ba3514..0a1c962 100644
--- a/drivers/iommu/msm_iommu_dev.c
+++ b/drivers/iommu/msm_iommu_dev.c
@@ -27,8 +27,8 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 
-#include <mach/iommu_hw-8xxx.h>
-#include <mach/iommu.h>
+#include "msm_iommu_hw-8xxx.h"
+#include "msm_iommu.h"
 
 struct iommu_ctx_iter_data {
 	/* input */
diff --git a/arch/arm/mach-msm/include/mach/iommu_hw-8xxx.h b/drivers/iommu/msm_iommu_hw-8xxx.h
similarity index 100%
rename from arch/arm/mach-msm/include/mach/iommu_hw-8xxx.h
rename to drivers/iommu/msm_iommu_hw-8xxx.h
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 16:54:31 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 13:54:31 -0700
Subject: [PATCH v2 6/9] ARM: msm: Move mach/board.h contents to common.h
In-Reply-To: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374699274-18388-7-git-send-email-sboyd@codeaurora.org>

The contents of mach/board.h are only used by files within
mach-msm so there is no need to export this file outside of the
mach-msm directory. Move the contents of the file to common.h to
allow us to compile MSM in the multi-platform kernel.

Cc: Florian Tobias Schandinat <FlorianSchandinat at gmx.de>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-msm/board-dt-8660.c      |  1 -
 arch/arm/mach-msm/board-halibut.c      |  1 -
 arch/arm/mach-msm/board-mahimahi.c     |  2 +-
 arch/arm/mach-msm/board-msm7x30.c      |  1 -
 arch/arm/mach-msm/board-qsd8x50.c      |  1 -
 arch/arm/mach-msm/board-sapphire.c     |  2 +-
 arch/arm/mach-msm/board-trout.c        |  1 -
 arch/arm/mach-msm/board-trout.h        |  2 +-
 arch/arm/mach-msm/common.h             | 15 ++++++++++++++
 arch/arm/mach-msm/devices-msm7x30.c    |  2 +-
 arch/arm/mach-msm/devices-qsd8x50.c    |  2 +-
 arch/arm/mach-msm/include/mach/board.h | 38 ----------------------------------
 arch/arm/mach-msm/io.c                 |  3 +--
 drivers/video/msm/msm_fb.c             |  1 -
 14 files changed, 21 insertions(+), 51 deletions(-)
 delete mode 100644 arch/arm/mach-msm/include/mach/board.h

diff --git a/arch/arm/mach-msm/board-dt-8660.c b/arch/arm/mach-msm/board-dt-8660.c
index 95f9cae..c294689 100644
--- a/arch/arm/mach-msm/board-dt-8660.c
+++ b/arch/arm/mach-msm/board-dt-8660.c
@@ -17,7 +17,6 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 
-#include <mach/board.h>
 #include "common.h"
 
 static void __init msm8x60_init_late(void)
diff --git a/arch/arm/mach-msm/board-halibut.c b/arch/arm/mach-msm/board-halibut.c
index 803651a..a775298 100644
--- a/arch/arm/mach-msm/board-halibut.c
+++ b/arch/arm/mach-msm/board-halibut.c
@@ -29,7 +29,6 @@
 #include <asm/setup.h>
 
 #include <mach/irqs.h>
-#include <mach/board.h>
 #include <mach/msm_iomap.h>
 
 #include <linux/mtd/nand.h>
diff --git a/arch/arm/mach-msm/board-mahimahi.c b/arch/arm/mach-msm/board-mahimahi.c
index 30c3496..7d9981c 100644
--- a/arch/arm/mach-msm/board-mahimahi.c
+++ b/arch/arm/mach-msm/board-mahimahi.c
@@ -28,12 +28,12 @@
 #include <asm/mach/map.h>
 #include <asm/setup.h>
 
-#include <mach/board.h>
 #include <mach/hardware.h>
 
 #include "board-mahimahi.h"
 #include "devices.h"
 #include "proc_comm.h"
+#include "common.h"
 
 static uint debug_uart;
 
diff --git a/arch/arm/mach-msm/board-msm7x30.c b/arch/arm/mach-msm/board-msm7x30.c
index db3d8c0..f9af5a4 100644
--- a/arch/arm/mach-msm/board-msm7x30.c
+++ b/arch/arm/mach-msm/board-msm7x30.c
@@ -30,7 +30,6 @@
 #include <asm/memory.h>
 #include <asm/setup.h>
 
-#include <mach/board.h>
 #include <mach/msm_iomap.h>
 #include <mach/dma.h>
 
diff --git a/arch/arm/mach-msm/board-qsd8x50.c b/arch/arm/mach-msm/board-qsd8x50.c
index f14a73d..5f933bc 100644
--- a/arch/arm/mach-msm/board-qsd8x50.c
+++ b/arch/arm/mach-msm/board-qsd8x50.c
@@ -28,7 +28,6 @@
 #include <asm/io.h>
 #include <asm/setup.h>
 
-#include <mach/board.h>
 #include <mach/irqs.h>
 #include <mach/sirc.h>
 #include <mach/vreg.h>
diff --git a/arch/arm/mach-msm/board-sapphire.c b/arch/arm/mach-msm/board-sapphire.c
index 7073011..3276051 100644
--- a/arch/arm/mach-msm/board-sapphire.c
+++ b/arch/arm/mach-msm/board-sapphire.c
@@ -28,7 +28,6 @@
 #include <asm/mach/map.h>
 #include <asm/mach/flash.h>
 #include <mach/vreg.h>
-#include <mach/board.h>
 
 #include <asm/io.h>
 #include <asm/delay.h>
@@ -41,6 +40,7 @@
 #include "board-sapphire.h"
 #include "proc_comm.h"
 #include "devices.h"
+#include "common.h"
 
 void msm_init_irq(void);
 void msm_init_gpio(void);
diff --git a/arch/arm/mach-msm/board-trout.c b/arch/arm/mach-msm/board-trout.c
index 64a46eb..ccf6621 100644
--- a/arch/arm/mach-msm/board-trout.c
+++ b/arch/arm/mach-msm/board-trout.c
@@ -25,7 +25,6 @@
 #include <asm/mach/map.h>
 #include <asm/setup.h>
 
-#include <mach/board.h>
 #include <mach/hardware.h>
 #include <mach/msm_iomap.h>
 
diff --git a/arch/arm/mach-msm/board-trout.h b/arch/arm/mach-msm/board-trout.h
index 651851c..b2379ed 100644
--- a/arch/arm/mach-msm/board-trout.h
+++ b/arch/arm/mach-msm/board-trout.h
@@ -4,7 +4,7 @@
 #ifndef __ARCH_ARM_MACH_MSM_BOARD_TROUT_H
 #define __ARCH_ARM_MACH_MSM_BOARD_TROUT_H
 
-#include <mach/board.h>
+#include "common.h"
 
 #define MSM_SMI_BASE		0x00000000
 #define MSM_SMI_SIZE		0x00800000
diff --git a/arch/arm/mach-msm/common.h b/arch/arm/mach-msm/common.h
index 20ebf87..33c7725 100644
--- a/arch/arm/mach-msm/common.h
+++ b/arch/arm/mach-msm/common.h
@@ -26,4 +26,19 @@ extern void __iomem *__msm_ioremap_caller(phys_addr_t phys_addr, size_t size,
 extern struct smp_operations msm_smp_ops;
 extern void msm_cpu_die(unsigned int cpu);
 
+struct msm_mmc_platform_data;
+
+extern void msm_add_devices(void);
+extern void msm_init_irq(void);
+extern void msm_init_gpio(void);
+extern int msm_add_sdcc(unsigned int controller,
+			struct msm_mmc_platform_data *plat,
+			unsigned int stat_irq, unsigned long stat_irq_flags);
+
+#if defined(CONFIG_MSM_SMD) && defined(CONFIG_DEBUG_FS)
+extern int smd_debugfs_init(void);
+#else
+static inline int smd_debugfs_init(void) { return 0; }
+#endif
+
 #endif
diff --git a/arch/arm/mach-msm/devices-msm7x30.c b/arch/arm/mach-msm/devices-msm7x30.c
index d4db75a..6b0e984 100644
--- a/arch/arm/mach-msm/devices-msm7x30.c
+++ b/arch/arm/mach-msm/devices-msm7x30.c
@@ -21,10 +21,10 @@
 #include <mach/irqs.h>
 #include <mach/msm_iomap.h>
 #include <mach/dma.h>
-#include <mach/board.h>
 
 #include "devices.h"
 #include "smd_private.h"
+#include "common.h"
 
 #include <asm/mach/flash.h>
 
diff --git a/arch/arm/mach-msm/devices-qsd8x50.c b/arch/arm/mach-msm/devices-qsd8x50.c
index f551811..c1c45ad 100644
--- a/arch/arm/mach-msm/devices-qsd8x50.c
+++ b/arch/arm/mach-msm/devices-qsd8x50.c
@@ -21,9 +21,9 @@
 #include <mach/irqs.h>
 #include <mach/msm_iomap.h>
 #include <mach/dma.h>
-#include <mach/board.h>
 
 #include "devices.h"
+#include "common.h"
 
 #include <asm/mach/flash.h>
 
diff --git a/arch/arm/mach-msm/include/mach/board.h b/arch/arm/mach-msm/include/mach/board.h
deleted file mode 100644
index c34e246..0000000
--- a/arch/arm/mach-msm/include/mach/board.h
+++ /dev/null
@@ -1,38 +0,0 @@
-/* arch/arm/mach-msm/include/mach/board.h
- *
- * Copyright (C) 2007 Google, Inc.
- * Author: Brian Swetland <swetland at google.com>
- *
- * 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 __ASM_ARCH_MSM_BOARD_H
-#define __ASM_ARCH_MSM_BOARD_H
-
-#include <linux/types.h>
-#include <linux/platform_data/mmc-msm_sdcc.h>
-
-/* common init routines for use by arch/arm/mach-msm/board-*.c */
-
-void __init msm_add_devices(void);
-void __init msm_init_irq(void);
-void __init msm_init_gpio(void);
-int __init msm_add_sdcc(unsigned int controller,
-			struct msm_mmc_platform_data *plat,
-			unsigned int stat_irq, unsigned long stat_irq_flags);
-
-#if defined(CONFIG_MSM_SMD) && defined(CONFIG_DEBUG_FS)
-int smd_debugfs_init(void);
-#else
-static inline int smd_debugfs_init(void) { return 0; }
-#endif
-
-#endif
diff --git a/arch/arm/mach-msm/io.c b/arch/arm/mach-msm/io.c
index c632c87..5f1b0aa 100644
--- a/arch/arm/mach-msm/io.c
+++ b/arch/arm/mach-msm/io.c
@@ -18,6 +18,7 @@
  */
 
 #include <linux/kernel.h>
+#include <linux/bug.h>
 #include <linux/init.h>
 #include <linux/io.h>
 #include <linux/export.h>
@@ -27,8 +28,6 @@
 #include <mach/msm_iomap.h>
 #include <asm/mach/map.h>
 
-#include <mach/board.h>
-
 #include "common.h"
 
 #define MSM_CHIP_DEVICE_TYPE(name, chip, mem_type) {			      \
diff --git a/drivers/video/msm/msm_fb.c b/drivers/video/msm/msm_fb.c
index ec08a9e..1374803 100644
--- a/drivers/video/msm/msm_fb.c
+++ b/drivers/video/msm/msm_fb.c
@@ -26,7 +26,6 @@
 #include <linux/io.h>
 #include <linux/uaccess.h>
 #include <linux/platform_data/video-msm_fb.h>
-#include <mach/board.h>
 #include <linux/workqueue.h>
 #include <linux/clk.h>
 #include <linux/debugfs.h>
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 16:54:32 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 13:54:32 -0700
Subject: [PATCH v2 7/9] ARM: msm: Remove devices-iommu.c
In-Reply-To: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374699274-18388-8-git-send-email-sboyd@codeaurora.org>

The iommu devices are registered in software, when they should
really be part of the DT. Since we don't currently have DT
bindings in place for the MSM iommu driver just remove this file
for the time being. This is not removing any functionality anyway
because these devices aren't probing today due to missing clocks.

Cc: Stepan Moskovchenko <stepanm at codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-msm/Makefile        |   1 -
 arch/arm/mach-msm/devices-iommu.c | 912 --------------------------------------
 2 files changed, 913 deletions(-)
 delete mode 100644 arch/arm/mach-msm/devices-iommu.c

diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index d257ff4..4c248ba 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -2,7 +2,6 @@ obj-y += io.o timer.o
 obj-y += clock.o
 
 obj-$(CONFIG_MSM_VIC) += irq-vic.o
-obj-$(CONFIG_MSM_IOMMU) += devices-iommu.o
 
 obj-$(CONFIG_ARCH_MSM7X00A) += irq.o
 obj-$(CONFIG_ARCH_QSD8X50) += sirc.o
diff --git a/arch/arm/mach-msm/devices-iommu.c b/arch/arm/mach-msm/devices-iommu.c
deleted file mode 100644
index 0fb7a17..0000000
--- a/arch/arm/mach-msm/devices-iommu.c
+++ /dev/null
@@ -1,912 +0,0 @@
-/* Copyright (c) 2010-2011, Code Aurora Forum. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
- */
-
-#include <linux/kernel.h>
-#include <linux/platform_device.h>
-#include <linux/bootmem.h>
-#include <linux/module.h>
-#include <mach/irqs.h>
-#include <mach/iommu.h>
-
-static struct resource msm_iommu_jpegd_resources[] = {
-	{
-		.start = 0x07300000,
-		.end   = 0x07300000 + SZ_1M - 1,
-		.name  = "physbase",
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name = "nonsecure_irq",
-		.start = SMMU_JPEGD_CB_SC_NON_SECURE_IRQ,
-		.end   = SMMU_JPEGD_CB_SC_NON_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name = "secure_irq",
-		.start = SMMU_JPEGD_CB_SC_SECURE_IRQ,
-		.end   = SMMU_JPEGD_CB_SC_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct resource msm_iommu_vpe_resources[] = {
-	{
-		.start = 0x07400000,
-		.end   = 0x07400000 + SZ_1M - 1,
-		.name  = "physbase",
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name = "nonsecure_irq",
-		.start = SMMU_VPE_CB_SC_NON_SECURE_IRQ,
-		.end   = SMMU_VPE_CB_SC_NON_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name = "secure_irq",
-		.start = SMMU_VPE_CB_SC_SECURE_IRQ,
-		.end   = SMMU_VPE_CB_SC_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct resource msm_iommu_mdp0_resources[] = {
-	{
-		.start = 0x07500000,
-		.end   = 0x07500000 + SZ_1M - 1,
-		.name  = "physbase",
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name = "nonsecure_irq",
-		.start = SMMU_MDP0_CB_SC_NON_SECURE_IRQ,
-		.end   = SMMU_MDP0_CB_SC_NON_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name = "secure_irq",
-		.start = SMMU_MDP0_CB_SC_SECURE_IRQ,
-		.end   = SMMU_MDP0_CB_SC_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct resource msm_iommu_mdp1_resources[] = {
-	{
-		.start = 0x07600000,
-		.end   = 0x07600000 + SZ_1M - 1,
-		.name  = "physbase",
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name = "nonsecure_irq",
-		.start = SMMU_MDP1_CB_SC_NON_SECURE_IRQ,
-		.end   = SMMU_MDP1_CB_SC_NON_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name = "secure_irq",
-		.start = SMMU_MDP1_CB_SC_SECURE_IRQ,
-		.end   = SMMU_MDP1_CB_SC_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct resource msm_iommu_rot_resources[] = {
-	{
-		.start = 0x07700000,
-		.end   = 0x07700000 + SZ_1M - 1,
-		.name  = "physbase",
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name = "nonsecure_irq",
-		.start = SMMU_ROT_CB_SC_NON_SECURE_IRQ,
-		.end   = SMMU_ROT_CB_SC_NON_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name = "secure_irq",
-		.start = SMMU_ROT_CB_SC_SECURE_IRQ,
-		.end   = SMMU_ROT_CB_SC_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct resource msm_iommu_ijpeg_resources[] = {
-	{
-		.start = 0x07800000,
-		.end   = 0x07800000 + SZ_1M - 1,
-		.name  = "physbase",
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name = "nonsecure_irq",
-		.start = SMMU_IJPEG_CB_SC_NON_SECURE_IRQ,
-		.end   = SMMU_IJPEG_CB_SC_NON_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name = "secure_irq",
-		.start = SMMU_IJPEG_CB_SC_SECURE_IRQ,
-		.end   = SMMU_IJPEG_CB_SC_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct resource msm_iommu_vfe_resources[] = {
-	{
-		.start = 0x07900000,
-		.end   = 0x07900000 + SZ_1M - 1,
-		.name  = "physbase",
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name = "nonsecure_irq",
-		.start = SMMU_VFE_CB_SC_NON_SECURE_IRQ,
-		.end   = SMMU_VFE_CB_SC_NON_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name = "secure_irq",
-		.start = SMMU_VFE_CB_SC_SECURE_IRQ,
-		.end   = SMMU_VFE_CB_SC_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct resource msm_iommu_vcodec_a_resources[] = {
-	{
-		.start = 0x07A00000,
-		.end   = 0x07A00000 + SZ_1M - 1,
-		.name  = "physbase",
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name = "nonsecure_irq",
-		.start = SMMU_VCODEC_A_CB_SC_NON_SECURE_IRQ,
-		.end   = SMMU_VCODEC_A_CB_SC_NON_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name = "secure_irq",
-		.start = SMMU_VCODEC_A_CB_SC_SECURE_IRQ,
-		.end   = SMMU_VCODEC_A_CB_SC_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct resource msm_iommu_vcodec_b_resources[] = {
-	{
-		.start = 0x07B00000,
-		.end   = 0x07B00000 + SZ_1M - 1,
-		.name  = "physbase",
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name = "nonsecure_irq",
-		.start = SMMU_VCODEC_B_CB_SC_NON_SECURE_IRQ,
-		.end   = SMMU_VCODEC_B_CB_SC_NON_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name = "secure_irq",
-		.start = SMMU_VCODEC_B_CB_SC_SECURE_IRQ,
-		.end   = SMMU_VCODEC_B_CB_SC_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct resource msm_iommu_gfx3d_resources[] = {
-	{
-		.start = 0x07C00000,
-		.end   = 0x07C00000 + SZ_1M - 1,
-		.name  = "physbase",
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name = "nonsecure_irq",
-		.start = SMMU_GFX3D_CB_SC_NON_SECURE_IRQ,
-		.end   = SMMU_GFX3D_CB_SC_NON_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name = "secure_irq",
-		.start = SMMU_GFX3D_CB_SC_SECURE_IRQ,
-		.end   = SMMU_GFX3D_CB_SC_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct resource msm_iommu_gfx2d0_resources[] = {
-	{
-		.start = 0x07D00000,
-		.end   = 0x07D00000 + SZ_1M - 1,
-		.name  = "physbase",
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name = "nonsecure_irq",
-		.start = SMMU_GFX2D0_CB_SC_NON_SECURE_IRQ,
-		.end   = SMMU_GFX2D0_CB_SC_NON_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name = "secure_irq",
-		.start = SMMU_GFX2D0_CB_SC_SECURE_IRQ,
-		.end   = SMMU_GFX2D0_CB_SC_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct resource msm_iommu_gfx2d1_resources[] = {
-	{
-		.start = 0x07E00000,
-		.end   = 0x07E00000 + SZ_1M - 1,
-		.name  = "physbase",
-		.flags = IORESOURCE_MEM,
-	},
-	{
-		.name = "nonsecure_irq",
-		.start = SMMU_GFX2D1_CB_SC_NON_SECURE_IRQ,
-		.end   = SMMU_GFX2D1_CB_SC_NON_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-	{
-		.name = "secure_irq",
-		.start = SMMU_GFX2D1_CB_SC_SECURE_IRQ,
-		.end   = SMMU_GFX2D1_CB_SC_SECURE_IRQ,
-		.flags = IORESOURCE_IRQ,
-	},
-};
-
-static struct platform_device msm_root_iommu_dev = {
-	.name = "msm_iommu",
-	.id = -1,
-};
-
-static struct msm_iommu_dev jpegd_iommu = {
-	.name = "jpegd",
-	.ncb = 2,
-};
-
-static struct msm_iommu_dev vpe_iommu = {
-	.name = "vpe",
-	.ncb = 2,
-};
-
-static struct msm_iommu_dev mdp0_iommu = {
-	.name = "mdp0",
-	.ncb = 2,
-};
-
-static struct msm_iommu_dev mdp1_iommu = {
-	.name = "mdp1",
-	.ncb = 2,
-};
-
-static struct msm_iommu_dev rot_iommu = {
-	.name = "rot",
-	.ncb = 2,
-};
-
-static struct msm_iommu_dev ijpeg_iommu = {
-	.name = "ijpeg",
-	.ncb = 2,
-};
-
-static struct msm_iommu_dev vfe_iommu = {
-	.name = "vfe",
-	.ncb = 2,
-};
-
-static struct msm_iommu_dev vcodec_a_iommu = {
-	.name = "vcodec_a",
-	.ncb = 2,
-};
-
-static struct msm_iommu_dev vcodec_b_iommu = {
-	.name = "vcodec_b",
-	.ncb = 2,
-};
-
-static struct msm_iommu_dev gfx3d_iommu = {
-	.name = "gfx3d",
-	.ncb = 3,
-};
-
-static struct msm_iommu_dev gfx2d0_iommu = {
-	.name = "gfx2d0",
-	.ncb = 2,
-};
-
-static struct msm_iommu_dev gfx2d1_iommu = {
-	.name = "gfx2d1",
-	.ncb = 2,
-};
-
-static struct platform_device msm_device_iommu_jpegd = {
-	.name = "msm_iommu",
-	.id = 0,
-	.dev = {
-		.parent = &msm_root_iommu_dev.dev,
-	},
-	.num_resources = ARRAY_SIZE(msm_iommu_jpegd_resources),
-	.resource = msm_iommu_jpegd_resources,
-};
-
-static struct platform_device msm_device_iommu_vpe = {
-	.name = "msm_iommu",
-	.id = 1,
-	.dev = {
-		.parent = &msm_root_iommu_dev.dev,
-	},
-	.num_resources = ARRAY_SIZE(msm_iommu_vpe_resources),
-	.resource = msm_iommu_vpe_resources,
-};
-
-static struct platform_device msm_device_iommu_mdp0 = {
-	.name = "msm_iommu",
-	.id = 2,
-	.dev = {
-		.parent = &msm_root_iommu_dev.dev,
-	},
-	.num_resources = ARRAY_SIZE(msm_iommu_mdp0_resources),
-	.resource = msm_iommu_mdp0_resources,
-};
-
-static struct platform_device msm_device_iommu_mdp1 = {
-	.name = "msm_iommu",
-	.id = 3,
-	.dev = {
-		.parent = &msm_root_iommu_dev.dev,
-	},
-	.num_resources = ARRAY_SIZE(msm_iommu_mdp1_resources),
-	.resource = msm_iommu_mdp1_resources,
-};
-
-static struct platform_device msm_device_iommu_rot = {
-	.name = "msm_iommu",
-	.id = 4,
-	.dev = {
-		.parent = &msm_root_iommu_dev.dev,
-	},
-	.num_resources = ARRAY_SIZE(msm_iommu_rot_resources),
-	.resource = msm_iommu_rot_resources,
-};
-
-static struct platform_device msm_device_iommu_ijpeg = {
-	.name = "msm_iommu",
-	.id = 5,
-	.dev = {
-		.parent = &msm_root_iommu_dev.dev,
-	},
-	.num_resources = ARRAY_SIZE(msm_iommu_ijpeg_resources),
-	.resource = msm_iommu_ijpeg_resources,
-};
-
-static struct platform_device msm_device_iommu_vfe = {
-	.name = "msm_iommu",
-	.id = 6,
-	.dev = {
-		.parent = &msm_root_iommu_dev.dev,
-	},
-	.num_resources = ARRAY_SIZE(msm_iommu_vfe_resources),
-	.resource = msm_iommu_vfe_resources,
-};
-
-static struct platform_device msm_device_iommu_vcodec_a = {
-	.name = "msm_iommu",
-	.id = 7,
-	.dev = {
-		.parent = &msm_root_iommu_dev.dev,
-	},
-	.num_resources = ARRAY_SIZE(msm_iommu_vcodec_a_resources),
-	.resource = msm_iommu_vcodec_a_resources,
-};
-
-static struct platform_device msm_device_iommu_vcodec_b = {
-	.name = "msm_iommu",
-	.id = 8,
-	.dev = {
-		.parent = &msm_root_iommu_dev.dev,
-	},
-	.num_resources = ARRAY_SIZE(msm_iommu_vcodec_b_resources),
-	.resource = msm_iommu_vcodec_b_resources,
-};
-
-static struct platform_device msm_device_iommu_gfx3d = {
-	.name = "msm_iommu",
-	.id = 9,
-	.dev = {
-		.parent = &msm_root_iommu_dev.dev,
-	},
-	.num_resources = ARRAY_SIZE(msm_iommu_gfx3d_resources),
-	.resource = msm_iommu_gfx3d_resources,
-};
-
-static struct platform_device msm_device_iommu_gfx2d0 = {
-	.name = "msm_iommu",
-	.id = 10,
-	.dev = {
-		.parent = &msm_root_iommu_dev.dev,
-	},
-	.num_resources = ARRAY_SIZE(msm_iommu_gfx2d0_resources),
-	.resource = msm_iommu_gfx2d0_resources,
-};
-
-struct platform_device msm_device_iommu_gfx2d1 = {
-	.name = "msm_iommu",
-	.id = 11,
-	.dev = {
-		.parent = &msm_root_iommu_dev.dev,
-	},
-	.num_resources = ARRAY_SIZE(msm_iommu_gfx2d1_resources),
-	.resource = msm_iommu_gfx2d1_resources,
-};
-
-static struct msm_iommu_ctx_dev jpegd_src_ctx = {
-	.name = "jpegd_src",
-	.num = 0,
-	.mids = {0, -1}
-};
-
-static struct msm_iommu_ctx_dev jpegd_dst_ctx = {
-	.name = "jpegd_dst",
-	.num = 1,
-	.mids = {1, -1}
-};
-
-static struct msm_iommu_ctx_dev vpe_src_ctx = {
-	.name = "vpe_src",
-	.num = 0,
-	.mids = {0, -1}
-};
-
-static struct msm_iommu_ctx_dev vpe_dst_ctx = {
-	.name = "vpe_dst",
-	.num = 1,
-	.mids = {1, -1}
-};
-
-static struct msm_iommu_ctx_dev mdp_vg1_ctx = {
-	.name = "mdp_vg1",
-	.num = 0,
-	.mids = {0, 2, -1}
-};
-
-static struct msm_iommu_ctx_dev mdp_rgb1_ctx = {
-	.name = "mdp_rgb1",
-	.num = 1,
-	.mids = {1, 3, 4, 5, 6, 7, 8, 9, 10, -1}
-};
-
-static struct msm_iommu_ctx_dev mdp_vg2_ctx = {
-	.name = "mdp_vg2",
-	.num = 0,
-	.mids = {0, 2, -1}
-};
-
-static struct msm_iommu_ctx_dev mdp_rgb2_ctx = {
-	.name = "mdp_rgb2",
-	.num = 1,
-	.mids = {1, 3, 4, 5, 6, 7, 8, 9, 10, -1}
-};
-
-static struct msm_iommu_ctx_dev rot_src_ctx = {
-	.name = "rot_src",
-	.num = 0,
-	.mids = {0, -1}
-};
-
-static struct msm_iommu_ctx_dev rot_dst_ctx = {
-	.name = "rot_dst",
-	.num = 1,
-	.mids = {1, -1}
-};
-
-static struct msm_iommu_ctx_dev ijpeg_src_ctx = {
-	.name = "ijpeg_src",
-	.num = 0,
-	.mids = {0, -1}
-};
-
-static struct msm_iommu_ctx_dev ijpeg_dst_ctx = {
-	.name = "ijpeg_dst",
-	.num = 1,
-	.mids = {1, -1}
-};
-
-static struct msm_iommu_ctx_dev vfe_imgwr_ctx = {
-	.name = "vfe_imgwr",
-	.num = 0,
-	.mids = {2, 3, 4, 5, 6, 7, 8, -1}
-};
-
-static struct msm_iommu_ctx_dev vfe_misc_ctx = {
-	.name = "vfe_misc",
-	.num = 1,
-	.mids = {0, 1, 9, -1}
-};
-
-static struct msm_iommu_ctx_dev vcodec_a_stream_ctx = {
-	.name = "vcodec_a_stream",
-	.num = 0,
-	.mids = {2, 5, -1}
-};
-
-static struct msm_iommu_ctx_dev vcodec_a_mm1_ctx = {
-	.name = "vcodec_a_mm1",
-	.num = 1,
-	.mids = {0, 1, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, -1}
-};
-
-static struct msm_iommu_ctx_dev vcodec_b_mm2_ctx = {
-	.name = "vcodec_b_mm2",
-	.num = 0,
-	.mids = {0, 1, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, -1}
-};
-
-static struct msm_iommu_ctx_dev gfx3d_user_ctx = {
-	.name = "gfx3d_user",
-	.num = 0,
-	.mids = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, -1}
-};
-
-static struct msm_iommu_ctx_dev gfx3d_priv_ctx = {
-	.name = "gfx3d_priv",
-	.num = 1,
-	.mids = {16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
-		 31, -1}
-};
-
-static struct msm_iommu_ctx_dev gfx2d0_2d0_ctx = {
-	.name = "gfx2d0_2d0",
-	.num = 0,
-	.mids = {0, 1, 2, 3, 4, 5, 6, 7, -1}
-};
-
-static struct msm_iommu_ctx_dev gfx2d1_2d1_ctx = {
-	.name = "gfx2d1_2d1",
-	.num = 0,
-	.mids = {0, 1, 2, 3, 4, 5, 6, 7, -1}
-};
-
-static struct platform_device msm_device_jpegd_src_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 0,
-	.dev = {
-		.parent = &msm_device_iommu_jpegd.dev,
-	},
-};
-
-static struct platform_device msm_device_jpegd_dst_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 1,
-	.dev = {
-		.parent = &msm_device_iommu_jpegd.dev,
-	},
-};
-
-static struct platform_device msm_device_vpe_src_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 2,
-	.dev = {
-		.parent = &msm_device_iommu_vpe.dev,
-	},
-};
-
-static struct platform_device msm_device_vpe_dst_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 3,
-	.dev = {
-		.parent = &msm_device_iommu_vpe.dev,
-	},
-};
-
-static struct platform_device msm_device_mdp_vg1_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 4,
-	.dev = {
-		.parent = &msm_device_iommu_mdp0.dev,
-	},
-};
-
-static struct platform_device msm_device_mdp_rgb1_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 5,
-	.dev = {
-		.parent = &msm_device_iommu_mdp0.dev,
-	},
-};
-
-static struct platform_device msm_device_mdp_vg2_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 6,
-	.dev = {
-		.parent = &msm_device_iommu_mdp1.dev,
-	},
-};
-
-static struct platform_device msm_device_mdp_rgb2_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 7,
-	.dev = {
-		.parent = &msm_device_iommu_mdp1.dev,
-	},
-};
-
-static struct platform_device msm_device_rot_src_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 8,
-	.dev = {
-		.parent = &msm_device_iommu_rot.dev,
-	},
-};
-
-static struct platform_device msm_device_rot_dst_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 9,
-	.dev = {
-		.parent = &msm_device_iommu_rot.dev,
-	},
-};
-
-static struct platform_device msm_device_ijpeg_src_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 10,
-	.dev = {
-		.parent = &msm_device_iommu_ijpeg.dev,
-	},
-};
-
-static struct platform_device msm_device_ijpeg_dst_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 11,
-	.dev = {
-		.parent = &msm_device_iommu_ijpeg.dev,
-	},
-};
-
-static struct platform_device msm_device_vfe_imgwr_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 12,
-	.dev = {
-		.parent = &msm_device_iommu_vfe.dev,
-	},
-};
-
-static struct platform_device msm_device_vfe_misc_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 13,
-	.dev = {
-		.parent = &msm_device_iommu_vfe.dev,
-	},
-};
-
-static struct platform_device msm_device_vcodec_a_stream_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 14,
-	.dev = {
-		.parent = &msm_device_iommu_vcodec_a.dev,
-	},
-};
-
-static struct platform_device msm_device_vcodec_a_mm1_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 15,
-	.dev = {
-		.parent = &msm_device_iommu_vcodec_a.dev,
-	},
-};
-
-static struct platform_device msm_device_vcodec_b_mm2_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 16,
-	.dev = {
-		.parent = &msm_device_iommu_vcodec_b.dev,
-	},
-};
-
-static struct platform_device msm_device_gfx3d_user_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 17,
-	.dev = {
-		.parent = &msm_device_iommu_gfx3d.dev,
-	},
-};
-
-static struct platform_device msm_device_gfx3d_priv_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 18,
-	.dev = {
-		.parent = &msm_device_iommu_gfx3d.dev,
-	},
-};
-
-static struct platform_device msm_device_gfx2d0_2d0_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 19,
-	.dev = {
-		.parent = &msm_device_iommu_gfx2d0.dev,
-	},
-};
-
-static struct platform_device msm_device_gfx2d1_2d1_ctx = {
-	.name = "msm_iommu_ctx",
-	.id = 20,
-	.dev = {
-		.parent = &msm_device_iommu_gfx2d1.dev,
-	},
-};
-
-static struct platform_device *msm_iommu_devs[] = {
-	&msm_device_iommu_jpegd,
-	&msm_device_iommu_vpe,
-	&msm_device_iommu_mdp0,
-	&msm_device_iommu_mdp1,
-	&msm_device_iommu_rot,
-	&msm_device_iommu_ijpeg,
-	&msm_device_iommu_vfe,
-	&msm_device_iommu_vcodec_a,
-	&msm_device_iommu_vcodec_b,
-	&msm_device_iommu_gfx3d,
-	&msm_device_iommu_gfx2d0,
-	&msm_device_iommu_gfx2d1,
-};
-
-static struct msm_iommu_dev *msm_iommu_data[] = {
-	&jpegd_iommu,
-	&vpe_iommu,
-	&mdp0_iommu,
-	&mdp1_iommu,
-	&rot_iommu,
-	&ijpeg_iommu,
-	&vfe_iommu,
-	&vcodec_a_iommu,
-	&vcodec_b_iommu,
-	&gfx3d_iommu,
-	&gfx2d0_iommu,
-	&gfx2d1_iommu,
-};
-
-static struct platform_device *msm_iommu_ctx_devs[] = {
-	&msm_device_jpegd_src_ctx,
-	&msm_device_jpegd_dst_ctx,
-	&msm_device_vpe_src_ctx,
-	&msm_device_vpe_dst_ctx,
-	&msm_device_mdp_vg1_ctx,
-	&msm_device_mdp_rgb1_ctx,
-	&msm_device_mdp_vg2_ctx,
-	&msm_device_mdp_rgb2_ctx,
-	&msm_device_rot_src_ctx,
-	&msm_device_rot_dst_ctx,
-	&msm_device_ijpeg_src_ctx,
-	&msm_device_ijpeg_dst_ctx,
-	&msm_device_vfe_imgwr_ctx,
-	&msm_device_vfe_misc_ctx,
-	&msm_device_vcodec_a_stream_ctx,
-	&msm_device_vcodec_a_mm1_ctx,
-	&msm_device_vcodec_b_mm2_ctx,
-	&msm_device_gfx3d_user_ctx,
-	&msm_device_gfx3d_priv_ctx,
-	&msm_device_gfx2d0_2d0_ctx,
-	&msm_device_gfx2d1_2d1_ctx,
-};
-
-static struct msm_iommu_ctx_dev *msm_iommu_ctx_data[] = {
-	&jpegd_src_ctx,
-	&jpegd_dst_ctx,
-	&vpe_src_ctx,
-	&vpe_dst_ctx,
-	&mdp_vg1_ctx,
-	&mdp_rgb1_ctx,
-	&mdp_vg2_ctx,
-	&mdp_rgb2_ctx,
-	&rot_src_ctx,
-	&rot_dst_ctx,
-	&ijpeg_src_ctx,
-	&ijpeg_dst_ctx,
-	&vfe_imgwr_ctx,
-	&vfe_misc_ctx,
-	&vcodec_a_stream_ctx,
-	&vcodec_a_mm1_ctx,
-	&vcodec_b_mm2_ctx,
-	&gfx3d_user_ctx,
-	&gfx3d_priv_ctx,
-	&gfx2d0_2d0_ctx,
-	&gfx2d1_2d1_ctx,
-};
-
-static int __init msm8x60_iommu_init(void)
-{
-	int ret, i;
-
-	ret = platform_device_register(&msm_root_iommu_dev);
-	if (ret != 0) {
-		pr_err("Failed to register root IOMMU device!\n");
-		goto failure;
-	}
-
-	for (i = 0; i < ARRAY_SIZE(msm_iommu_devs); i++) {
-		ret = platform_device_add_data(msm_iommu_devs[i],
-					       msm_iommu_data[i],
-					       sizeof(struct msm_iommu_dev));
-		if (ret != 0) {
-			pr_err("platform_device_add_data failed, "
-			       "i = %d\n", i);
-			goto failure_unwind;
-		}
-
-		ret = platform_device_register(msm_iommu_devs[i]);
-
-		if (ret != 0) {
-			pr_err("platform_device_register iommu failed, "
-			       "i = %d\n", i);
-			goto failure_unwind;
-		}
-	}
-
-	for (i = 0; i < ARRAY_SIZE(msm_iommu_ctx_devs); i++) {
-		ret = platform_device_add_data(msm_iommu_ctx_devs[i],
-					       msm_iommu_ctx_data[i],
-					       sizeof(*msm_iommu_ctx_devs[i]));
-		if (ret != 0) {
-			pr_err("platform_device_add_data iommu failed, "
-			       "i = %d\n", i);
-			goto failure_unwind2;
-		}
-
-		ret = platform_device_register(msm_iommu_ctx_devs[i]);
-		if (ret != 0) {
-			pr_err("platform_device_register ctx failed, "
-			       "i = %d\n", i);
-			goto failure_unwind2;
-		}
-	}
-	return 0;
-
-failure_unwind2:
-	while (--i >= 0)
-		platform_device_unregister(msm_iommu_ctx_devs[i]);
-failure_unwind:
-	while (--i >= 0)
-		platform_device_unregister(msm_iommu_devs[i]);
-
-	platform_device_unregister(&msm_root_iommu_dev);
-failure:
-	return ret;
-}
-
-static void __exit msm8x60_iommu_exit(void)
-{
-	int i;
-
-	for (i = 0; i < ARRAY_SIZE(msm_iommu_ctx_devs); i++)
-		platform_device_unregister(msm_iommu_ctx_devs[i]);
-
-	for (i = 0; i < ARRAY_SIZE(msm_iommu_devs); ++i)
-		platform_device_unregister(msm_iommu_devs[i]);
-
-	platform_device_unregister(&msm_root_iommu_dev);
-}
-
-subsys_initcall(msm8x60_iommu_init);
-module_exit(msm8x60_iommu_exit);
-
-MODULE_LICENSE("GPL v2");
-MODULE_AUTHOR("Stepan Moskovchenko <stepanm at codeaurora.org>");
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From fabio.estevam at freescale.com  Wed Jul 24 17:02:28 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Wed, 24 Jul 2013 18:02:28 -0300
Subject: [PATCH] ARM: mm: cache-l2x0: Print the cache size in kB
Message-ID: <1374699748-28393-1-git-send-email-fabio.estevam@freescale.com>

Currently we have the following output from cache-l2x0:
 
l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x32070000, Cache size: 1048576 B

Using kB for the cache size can improve readability a bit:

l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x32070000, Cache size: 1024 kB

While at it use pr_info.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/mm/cache-l2x0.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index e3d8f7b..ad4e882 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -417,9 +417,9 @@ void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask)
 		outer_cache.disable = l2x0_disable;
 	}
 
-	printk(KERN_INFO "%s cache controller enabled\n", type);
-	printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x, Cache size: %d kB\n",
-			ways, cache_id, aux, l2x0_size >> 10);
+	pr_info("%s cache controller enabled\n", type);
+	pr_info("l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x, Cache size: %d kB\n",
+		ways, cache_id, aux, l2x0_size >> 10);
 }
 
 #ifdef CONFIG_OF
-- 
1.8.1.2




From fabio.estevam at freescale.com  Wed Jul 24 17:10:03 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Wed, 24 Jul 2013 18:10:03 -0300
Subject: [PATCH v2] ARM: mm: cache-l2x0: Print the cache size in kB
Message-ID: <1374700203-29684-1-git-send-email-fabio.estevam@freescale.com>

Currently we have the following output from cache-l2x0:
 
l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x32070000, Cache size: 1048576 B

Using kB for the cache size can improve readability a bit:

l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x32070000, Cache size: 1024 kB

While at it use pr_info.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- Fix rebase issue

 arch/arm/mm/cache-l2x0.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index d70e0ab..ad4e882 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -417,9 +417,9 @@ void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask)
 		outer_cache.disable = l2x0_disable;
 	}
 
-	printk(KERN_INFO "%s cache controller enabled\n", type);
-	printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x, Cache size: %d B\n",
-			ways, cache_id, aux, l2x0_size);
+	pr_info("%s cache controller enabled\n", type);
+	pr_info("l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x, Cache size: %d kB\n",
+		ways, cache_id, aux, l2x0_size >> 10);
 }
 
 #ifdef CONFIG_OF
-- 
1.8.1.2




From victor.kamensky at linaro.org  Wed Jul 24 17:24:29 2013
From: victor.kamensky at linaro.org (Victor Kamensky)
Date: Wed, 24 Jul 2013 14:24:29 -0700
Subject: updates for be8 patch series
In-Reply-To: <CAA3XUr1zHQbh+baVzQfgEebqYsEzUVp6wGOMe2PE6PUamAnbbw@mail.gmail.com>
References: <CAA3XUr3h5C0oJVrN5iXsM=NFkLMz_Tssp28CysZfwMNS5KvO-Q@mail.gmail.com>
 <51EEC002.9070808@codethink.co.uk>
 <CAA3XUr2oDEDD6LFjnZ_N0JGTFUMDZG6O9b3JoeJ8AELrK2KDiw@mail.gmail.com>
 <CAA3XUr1BJD-ypfJiEsp079qHDERjGp-xFxc_ke_Ep9z3N=UPaA@mail.gmail.com>
 <51EECBBD.20000@codethink.co.uk>
 <CAA3XUr1zHQbh+baVzQfgEebqYsEzUVp6wGOMe2PE6PUamAnbbw@mail.gmail.com>
Message-ID: <CAA3XUr0rYPB2X_p36ovouKmCF0EsOrWPcXEE859X7dT2d2+WLg@mail.gmail.com>

Hi Ben,

> I believe largely your series covers the same things, in more accurate way,
> and should be continued. I plan to review your series and will try to
> integrate it and run on Pandaboard ES. Note for this testing I would use big
> patch of TI OMAP4 drivers to be endian neutral. It will take me several days.
> If I find anything I will let you know accross these days.

Here is what I got so far:

setend be under ARM_BE8 or CPU_ENDIAN_BE8 usage
-----------------------------------------------

In many places I see 'setend be' instruction under ARM_BE8

ARM_BE8(    setend    be )

and ARM_BE8 defined as

+/* Select code for any configuration running in BE8 mode */
+#ifdef CONFIG_CPU_ENDIAN_BE8
+#define ARM_BE8(code...) code
+#else
+#define ARM_BE8(code...)
+#endif

but strictly speaking you need to do that only if CPU_BE8_BOOT_LE config set.
I.e if loader is not in little endian mode, you do not need those commands. CPU
will be already in BE mode.

IMHO ARM_BE8 should be used only if it is really be8 specific issue. There
could be just big endian issues, those should be done under CPU_BIG_ENDIAN
config. There could be ARM CPU_BIG_ENDIAN system, but not CPU_ENDIAN_BE8.
I.e ARCH_IXP4xx is example of that.

For example 'ARM: pl01x debug code endian fix' patch IMHO should
use CPU_BIG_ENDIAN rather than CONFIG_CPU_ENDIAN_BE8 (as it is now through
ARM_BE8). I.e if the same serial console output function will run on
CPU_BIG_ENDIAN but not CONFIG_CPU_ENDIAN_BE8 it would need such byteswap. I
understand that it is a bit contrived example where code is really BSP
specific and this BSP would never have CONFIG_CPU_ENDIAN_BE8 missing, but I am
concerned that meaning of configs got blured if it is used like this.

Note you do have BE8_LE defined in latter patch ...

Few places miss atags swaps on the read
---------------------------------------

I've tried to compare your atags reading changes vs my byteswap in place code. I
agree that byte swap on reading is better. It seems to me that you've missed
few places when conversion should happen (unless I am missing something). Also I
think you  need to add atag16_to_cpu, and cpu_to_atag16 so short atag values
could be handled.

1) arch/arm/kernel/atags_parse.c <global>
            87 __tagtable(ATAG_VIDEOTEXT, parse_tag_videotext);

It needs to swap (only relevant fields listed)

struct tag_videotext {
    __u16        video_page;
    __u16        video_ega_bx;
    __u16        video_points;
};


2) arch/arm/kernel/atags_parse.c <global>
            140 __tagtable(ATAG_CMDLINE, parse_tag_cmdline);

It needs to swap cmdline, as far as I read the code it is a pointer ...
wondering what is going on in 64bit case ...

struct tag_cmdline {
    char    cmdline[1];    /* this is the minimum size */
};

3) arch/arm/mach-footbridge/common.c <global>
            51 __tagtable(ATAG_MEMCLK, parse_tag_memclk);

For consistency sake it is good idea to convert this too. It needs to swap
fmemclk on the read

struct tag_memclk {
    __u32 fmemclk;
};

4) arch/arm/mach-rpc/riscpc.c <global>
            65 __tagtable(ATAG_ACORN, parse_tag_acorn);

For consistency sake it is good idea to convert this too. It needs to swap
when reading the following fields

struct tag_acorn {
    __u32 memc_control_reg;
    __u32 vram_pages;
};

5) arch/arm/mm/init.c <global>
            68 __tagtable(ATAG_INITRD, parse_tag_initrd);
6) arch/arm/mm/init.c <global>
            77 __tagtable(ATAG_INITRD2, parse_tag_initrd2);

Need to swap

struct tag_initrd {
    __u32 start;    /* physical start address */
    __u32 size;    /* size of compressed ramdisk image in bytes */
};

Other than these notes, it looks very very good!

Thanks,
Victor


From nicolas.pitre at linaro.org  Wed Jul 24 17:27:38 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 24 Jul 2013 17:27:38 -0400 (EDT)
Subject: Requirements for FDT load address on ARM
In-Reply-To: <1374690705.30195.18.camel@hastur.hellion.org.uk>
References: <1374677923.6623.194.camel@hastur.hellion.org.uk>
 <alpine.LFD.2.03.1307241116200.15022@syhkavp.arg>
 <1374690705.30195.18.camel@hastur.hellion.org.uk>
Message-ID: <alpine.LFD.2.03.1307241625190.15022@syhkavp.arg>

On Wed, 24 Jul 2013, Ian Campbell wrote:

> On Wed, 2013-07-24 at 11:24 -0400, Nicolas Pitre wrote:
> > On Wed, 24 Jul 2013, Ian Campbell wrote:
> > 
> > > [apologies if this is a repeat, I don't see it in the archives and at
> > > least one CC'd recipient (Julien) didn't receive it either. Beasties in
> > > our email server I expect...]
> > > 
> > > Are there any requirements about where the FDT may be loaded by the
> > > bootloader?
> > 
> > It must be located where it is unlikely to be overwritten by the zImage 
> > decompressor relocating itself.  Same goes for the initrd.
> 
> Right. That's a bit hard to determine programmaticaly from a bootloader
> though :-(

Well... The kernel has to be loaded in the first 128MB of RAM for the 
automatic RAM location to work.  So you simply have to load the ftd and 
initrd sequentially above the 128MB mark.  The kernel cannot grow above 
16MB in size or we lose the ability to link modules without far calls, 
or 32MB for the kernel itself after wich the kernel itself doesn't link.  
This means the decompressor will never relocate anything above the 128MB 
mark in any case.

In practice this limit can even be lowered to 64MB.


Nicolas


From davidb at codeaurora.org  Wed Jul 24 18:41:26 2013
From: davidb at codeaurora.org (David Brown)
Date: Wed, 24 Jul 2013 15:41:26 -0700
Subject: [PATCH 0/3] MSM gpio fixes
In-Reply-To: <CACRpkdbOO8fFEx+PxsdJ9F1dqD6V4_RPZThvTufo9+XhhyuHOg@mail.gmail.com>
References: <1374178035-19943-1-git-send-email-davidb@codeaurora.org>
 <CACRpkdbOO8fFEx+PxsdJ9F1dqD6V4_RPZThvTufo9+XhhyuHOg@mail.gmail.com>
Message-ID: <20130724224126.GA27678@codeaurora.org>

On Sat, Jul 20, 2013 at 10:54:42PM +0200, Linus Walleij wrote:
>On Thu, Jul 18, 2013 at 10:07 PM, David Brown <davidb at codeaurora.org> wrote:
>
>> Rohit sent these three fixes out on June 18.  I still need a
>> devicetree ack for the first patch, and would like these to get pulled
>> in for v3.11
>>
>> Rohit Vaswani (3):
>>   ARM: msm: dts: Fix the gpio register address for msm8960
>>   drivers: gpio: msm: Fix the error condition for reading ngpio
>
>OK for these two...
>
>>   ARM: msm: Consolidate gpiomux for older architectures
>
>This does not look like a fix? Surely this can wait for v3.12?

It fixes compilation.  But, it could also wait for v3.12.

David

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From cavokz at gmail.com  Wed Jul 24 18:54:43 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Thu, 25 Jul 2013 00:54:43 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <51F02947.7020301@hauke-m.de>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130723184907.GA6811@ohporter.com>
 <CAGVrzcbA72AYu6J3JXBirQQeTiDH9cJThdBdH=Q=gJtOnqz-AA@mail.gmail.com>
 <20130723192203.GC6811@ohporter.com>
 <51EF1B8C.9020304@broadcom.com>
 <CADjby3WGW6f=1Vdm2kx+Re0KrjFRaC3dQOumpnS6_sp2yb5NfQ@mail.gmail.com>
 <51F02947.7020301@hauke-m.de>
Message-ID: <20130724225443.GA29801@glitch>

On Wed, Jul 24, 2013 at 09:21:43PM +0200, Hauke Mehrtens wrote:
> On 07/24/2013 02:44 AM, Domenico Andreoli wrote:
> > On Wednesday, July 24, 2013, Hauke Mehrtens <hauke at hauke-m.de
> > <mailto:hauke at hauke-m.de>> wrote:
> >> On 07/19/2013 03:36 AM, Domenico Andreoli wrote:
> >>> On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote:
> >>>> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote:
> >>>>>
> >>>>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig
> > b/arch/arm/mach-bcm53xx/Kconfig
> >>>>>> new file mode 100644
> >>>>>> index 0000000..1e16e87
> >>>>>> --- /dev/null
> >>>>>> +++ b/arch/arm/mach-bcm53xx/Kconfig
> >>>>>> @@ -0,0 +1,10 @@
> >>>>>> +config ARCH_BCM53XX
> >>>>>> +  bool "Broadcom BCM47XX / BCM53XX ARM SoC"
> >>>>>
> >>>>> So the directory is named mach-bcm53xx, but you also handle BCM47xx
> >>>>> SoCs. This doesn't sound really easy to follow.
> >>>
> >>> At the time of the BCM281XX merge we considered that such directories
> > would
> >>> mostly contain board files only, being these new entries DT based. Hence
> >>> the choice of mach-bcm to collect all of them.
> >>>
> >>> I think you should then put this stuff there.
> >>
> >> So you think I should move the file from
> >> arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?
> > 
> > yes
> > 
> > this looks more comsistent with the actual soc name:
> > arch/arm/mach-bcm/bcm530xx.c
> > 
> > but I find also acceptable the complete name of the "parent" soc (as I'm
> > doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c
> 
> I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351)
> have more in common than the vendor name, so I do not think it is a good
> idea to place them all at mach-bcm.

In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever
two or more SoCs share can hopefully modelled in a driver and as such
would go in the drivers/ subtree. What's left is really SoC specific and,
again hopefully, very minimal.

There should not be any SoC so weird to require a whole subdirectory full
of that SoC specific stuff. So grouping everything by vendor name looks
quite appealing to me.

Sharing the same subdir requires people working in it to talk and find
agreements some more than the sparsely populated subdir did (because there
is not a single maintainer who owns it). I think this is a big advantage
Broadcomers can start with right now.

> 
> >> Most (All?) of the Router SoCs in the BCM53XX and BCM47XX line are from
> >> the same family and they should be supported by the same code, so there
> >> is no reason to have a bcm47xx.c and a bcm53xx.c.
> >>
> >>>> Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I
> >>>> do not know why there are two different names, probably marketing.
> >>>>
> >>>> Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a
> >>>> MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to
> >>>> not conflict with the MIPS part now. I know this could still cause
> >>>> problems and people will get confused, but I do not know a better name.
> >>>
> >>> I'll throw also BCM476x (bcm4760 and bcm4761) on the table. These are
> > ARM11,
> >>> single-core SoCs.
> >>>
> >>> Can we agree on a nice naming so that we actually clarify this silliness?
> >>
> >> We could name it BCM5301X like it is named the the vendor source code.
> >> Currently there are the following SoCs of this family available:
> >> BCM53010, BCM53011, BCM53012, BCM53014, BCM53015, BCM53016, BCM53017,
> >> BCM53018, BCM4707, BCM4708 and BCM4709.
> > 
> > There is not a clear single pattern here, whatever choice won't be 100%
> > right. Users will need to read some help to pick the right choice.
> > BCM53010? But mine is not a strong opinion.
> > 
> >> Internal there are two different
> >> chip IDs available 53010 (BCM4707) and 53018 (BCM53018).
> > 
> > what do you mean with "internal" here?
> 
> There is some register in the chip where the chipid is stored, according
> to the vendor code these two values are currently possible. This was
> changed for every generation with the MIPS SoCs, while one generation
> had some SoCs.

Only two chipids for all these SoCs? Not that changes anything to me,
I'm only trying to understand the beast.

> 
> Hauke


From cavokz at gmail.com  Wed Jul 24 19:11:06 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Thu, 25 Jul 2013 01:11:06 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <CAGVrzcYnoN9NnJGvubS7=bVJDk37xSt4BimtvDWghe7OHEWALQ@mail.gmail.com>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130719020611.GA4941@glitch> <20130723185733.GB6811@ohporter.com>
 <CAGVrzcYnoN9NnJGvubS7=bVJDk37xSt4BimtvDWghe7OHEWALQ@mail.gmail.com>
Message-ID: <20130724231106.GB29801@glitch>

On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote:
> 2013/7/23 Matt Porter <matt.porter at linaro.org>:
> > On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
> >> On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote:
> >> > Hello,
> >> >
> >> > Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :
> >> > > > +       compatible = "brcm,bcm5301x";
> >> > >
> >> > > Ok, this was nagging at me before I went on my very long vacation. I see
> >> > > the "brcm" vendor prefix as a real consistency problem. I noticed on the
> >> > > bcm281xx/kona family, we have been using "bcm" which is not logged in
> >> > > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
> >> > > already established use of "brcm" before any of the bcm281xx support
> >> > > came in. Ideally, the vendor prefix should change to "bcm" since every
> >> > > reference in the family names is BCM. However, if others want the least
> >> > > amount of churn in making this consistent, we might have to go with
> >> > > "brcm" across the board.
> >> >
> >> > I would like to keep "brcm" here because that is what has been defined as a
> >> > vendor prefix, and is used beyond the scope of the ARM Linux kernel support
> >> > even within Broadcom. Maybe it was an oversight, or rather a mistake to let
> >>
> >> brcm is the stock ticker. As far as I can search, this is the convention
> >> for the vendor prefixes.
> >
> > No, correlation does not equal causation. The fact that some vendor
> > prefixes in DT match the stock symbol is by chance of 3-4 character name
> > being the same...nothing more.
> 
> That was a bad argument as was later explained to me, I won't use that
> reason again.

I cited the stock ticker only because IIRC it's the reason my initial
proposal for bcm has been ditched in favour of brcm when bcm2835 was
initially proposed.

> > It's pretty easy to see that the "ti" vendor prefix has no relation at
> > all to their TXN symbol so that blows that convention out of the water.
> > Rather, the prefix is based on somebody's notion of how that vendor's
> > part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
> > never TXN OMAP. :)
> >
> > For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.
> 
> It was appropriate before being the "wrong" vendor prefix was
> allocated, now that "brcm" has been allocated we should stick to it
> because otherwise we will break existing and on-going DT work.

I still prefer bcm to brcm and I find enough evidence that bcm would be
better in the long term.

So if Broadcomers can agree on bcm, now it's still the cheapest time to
fix in that direction, later will not be better.

my 2c
dom


From tomasz.figa at gmail.com  Wed Jul 24 19:15:54 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 25 Jul 2013 01:15:54 +0200
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
Message-ID: <1619688.mith7vb7oh@flatron>

Hi Olof,

On Wednesday 24 of July 2013 08:27:13 Olof Johansson wrote:
> Every now and then I come across a binding that's just done Wrong(tm),
> merged through a submaintainer tree and hasn't seen proper review --
> if it had, it wouldn't look the way it does. It's something we're
> starting to address now since there's more people stepping up to be
> maintainers, but there's a backlog of bad bindings already merged.
> 
> Often they are produced by translating the platform_data structures
> directly over into device-tree properties without consideration to
> describing the hardware or usual conventions, using key/value pairs
> instead of boolean properties, etc.
> 
> Getting involved in cleaning up these kind of bindings is a great way
> to learn "the ways of device tree" for someone that has interest in
> that.
> 
> Latest find in this area is the Maxim 8925 bindings, that I came
> across since they caused a compile warning on some defconfig. I'll
> post a patch to address the warning but if someone else feels like
> fixing the bindings on top of it that would be appreciated!

Care to explain your doubts about max8952 bindings? As far as I remember 
it's just a standard single voltage regulator (= generic regulator 
bindings) + some device specific properties.

Looking at Documentation/devicetree/bindings/regulator/max8952.txt I don't 
really see anything worrying...

Best regards,
Tomasz



From cavokz at gmail.com  Wed Jul 24 19:17:55 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Thu, 25 Jul 2013 01:17:55 +0200
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
Message-ID: <20130724231755.GC29801@glitch>

On Wed, Jul 24, 2013 at 08:27:13AM -0700, Olof Johansson wrote:
> Every now and then I come across a binding that's just done Wrong(tm),
> merged through a submaintainer tree and hasn't seen proper review --
> if it had, it wouldn't look the way it does. It's something we're
> starting to address now since there's more people stepping up to be
> maintainers, but there's a backlog of bad bindings already merged.

Where is this backlog?

> 
> Often they are produced by translating the platform_data structures
> directly over into device-tree properties without consideration to
> describing the hardware or usual conventions, using key/value pairs
> instead of boolean properties, etc.
> 
> Getting involved in cleaning up these kind of bindings is a great way
> to learn "the ways of device tree" for someone that has interest in
> that.
> 
> Latest find in this area is the Maxim 8925 bindings, that I came
> across since they caused a compile warning on some defconfig. I'll
> post a patch to address the warning but if someone else feels like
> fixing the bindings on top of it that would be appreciated!
> 
> 
> -Olof
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From olof at lixom.net  Wed Jul 24 19:20:02 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Jul 2013 16:20:02 -0700
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <1619688.mith7vb7oh@flatron>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
 <1619688.mith7vb7oh@flatron>
Message-ID: <CAOesGMj5eyRdE++hJgFV3AJKUGWZEoE7P9_pr_5QBHpJWFCzmQ@mail.gmail.com>

Hi,

On Wed, Jul 24, 2013 at 4:15 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> Hi Olof,
>
> On Wednesday 24 of July 2013 08:27:13 Olof Johansson wrote:
>> Every now and then I come across a binding that's just done Wrong(tm),
>> merged through a submaintainer tree and hasn't seen proper review --
>> if it had, it wouldn't look the way it does. It's something we're
>> starting to address now since there's more people stepping up to be
>> maintainers, but there's a backlog of bad bindings already merged.
>>
>> Often they are produced by translating the platform_data structures
>> directly over into device-tree properties without consideration to
>> describing the hardware or usual conventions, using key/value pairs
>> instead of boolean properties, etc.
>>
>> Getting involved in cleaning up these kind of bindings is a great way
>> to learn "the ways of device tree" for someone that has interest in
>> that.
>>
>> Latest find in this area is the Maxim 8925 bindings, that I came
>> across since they caused a compile warning on some defconfig. I'll
>> post a patch to address the warning but if someone else feels like
>> fixing the bindings on top of it that would be appreciated!
>
> Care to explain your doubts about max8952 bindings? As far as I remember
> it's just a standard single voltage regulator (= generic regulator
> bindings) + some device specific properties.
>
> Looking at Documentation/devicetree/bindings/regulator/max8952.txt I don't
> really see anything worrying...

Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt

But yes, the regulator one looks normal.


-Olof


From olof at lixom.net  Wed Jul 24 19:20:48 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Jul 2013 16:20:48 -0700
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <20130724231755.GC29801@glitch>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
 <20130724231755.GC29801@glitch>
Message-ID: <CAOesGMh9UMOXMENPe5pndHu7_OkEhdcj47q3fTasJS-dOtQssQ@mail.gmail.com>

On Wed, Jul 24, 2013 at 4:17 PM, Domenico Andreoli <cavokz at gmail.com> wrote:
> On Wed, Jul 24, 2013 at 08:27:13AM -0700, Olof Johansson wrote:
>> Every now and then I come across a binding that's just done Wrong(tm),
>> merged through a submaintainer tree and hasn't seen proper review --
>> if it had, it wouldn't look the way it does. It's something we're
>> starting to address now since there's more people stepping up to be
>> maintainers, but there's a backlog of bad bindings already merged.
>
> Where is this backlog?

There is no list of them, if that is what you are asking for. If
people are interested in cleaning them up one could be started. Which
is why I was gauging interest.


-Olof


From tomasz.figa at gmail.com  Wed Jul 24 19:22:44 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 25 Jul 2013 01:22:44 +0200
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <CAOesGMj5eyRdE++hJgFV3AJKUGWZEoE7P9_pr_5QBHpJWFCzmQ@mail.gmail.com>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
 <1619688.mith7vb7oh@flatron>
 <CAOesGMj5eyRdE++hJgFV3AJKUGWZEoE7P9_pr_5QBHpJWFCzmQ@mail.gmail.com>
Message-ID: <2077078.hRKZxaEG2D@flatron>

On Wednesday 24 of July 2013 16:20:02 Olof Johansson wrote:
> Hi,
> 
> On Wed, Jul 24, 2013 at 4:15 PM, Tomasz Figa <tomasz.figa at gmail.com> 
wrote:
> > Hi Olof,
> > 
> > On Wednesday 24 of July 2013 08:27:13 Olof Johansson wrote:
> >> Every now and then I come across a binding that's just done
> >> Wrong(tm),
> >> merged through a submaintainer tree and hasn't seen proper review --
> >> if it had, it wouldn't look the way it does. It's something we're
> >> starting to address now since there's more people stepping up to be
> >> maintainers, but there's a backlog of bad bindings already merged.
> >> 
> >> Often they are produced by translating the platform_data structures
> >> directly over into device-tree properties without consideration to
> >> describing the hardware or usual conventions, using key/value pairs
> >> instead of boolean properties, etc.
> >> 
> >> Getting involved in cleaning up these kind of bindings is a great way
> >> to learn "the ways of device tree" for someone that has interest in
> >> that.
> >> 
> >> Latest find in this area is the Maxim 8925 bindings, that I came
> >> across since they caused a compile warning on some defconfig. I'll
> >> post a patch to address the warning but if someone else feels like
> >> fixing the bindings on top of it that would be appreciated!
> > 
> > Care to explain your doubts about max8952 bindings? As far as I
> > remember it's just a standard single voltage regulator (= generic
> > regulator bindings) + some device specific properties.
> > 
> > Looking at Documentation/devicetree/bindings/regulator/max8952.txt I
> > don't really see anything worrying...
> 
> Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt
> 
> But yes, the regulator one looks normal.

Oh gosh, it's time to sleep. I confused 8925 with 8952... Sorry for the 
noise and thanks for quick reply. (I'm writing separate reply about 
janitoring/cleanup itself.)

Best regards,
Tomasz



From mturquette at linaro.org  Wed Jul 24 19:26:00 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 24 Jul 2013 16:26:00 -0700
Subject: [PATCH 2/2] clk: fixup argument order when setting VCO parameters
In-Reply-To: <1374594138-17080-3-git-send-email-jonathan.austin@arm.com>
References: <1374594138-17080-1-git-send-email-jonathan.austin@arm.com>
 <1374594138-17080-3-git-send-email-jonathan.austin@arm.com>
Message-ID: <20130724232600.7598.95231@quantum>

Quoting Jonathan Austin (2013-07-23 08:42:18)
> The order of arguments in the call to vco_set() for the ICST clocks appears to
> have been switched in error, which results in the VCO not being initialised
> correctly. This in turn stops the integrated LCD on things like Integrator/CP
> from working correctly.
> 
> This patch fixes the order and restores the expected functionality.
> 
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Mike Turquette <mturquette at linaro.org>
> Signed-off-by: Jonathan Austin <jonathan.austin at arm.com>

Thanks for the fix. Will send out with the next batch.

Regards,
Mike

> ---
>  drivers/clk/versatile/clk-icst.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/versatile/clk-icst.c b/drivers/clk/versatile/clk-icst.c
> index 67ccf4a..f5e4c21 100644
> --- a/drivers/clk/versatile/clk-icst.c
> +++ b/drivers/clk/versatile/clk-icst.c
> @@ -107,7 +107,7 @@ static int icst_set_rate(struct clk_hw *hw, unsigned long rate,
>  
>         vco = icst_hz_to_vco(icst->params, rate);
>         icst->rate = icst_hz(icst->params, vco);
> -       vco_set(icst->vcoreg, icst->lockreg, vco);
> +       vco_set(icst->lockreg, icst->vcoreg, vco);
>         return 0;
>  }
>  
> -- 
> 1.7.9.5


From tomasz.figa at gmail.com  Wed Jul 24 19:29:28 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 25 Jul 2013 01:29:28 +0200
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <20130724190315.GC23879@titan.lakedaemon.net>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
 <51F01D64.9060609@gmail.com> <20130724190315.GC23879@titan.lakedaemon.net>
Message-ID: <3403223.vsyjiUcZ9s@flatron>

On Wednesday 24 of July 2013 15:03:15 Jason Cooper wrote:
> On Wed, Jul 24, 2013 at 01:31:00PM -0500, Rob Herring wrote:
> > On 07/24/2013 10:27 AM, Olof Johansson wrote:
> > > Every now and then I come across a binding that's just done
> > > Wrong(tm),
> > > merged through a submaintainer tree and hasn't seen proper review --
> > > if it had, it wouldn't look the way it does. It's something we're
> > > starting to address now since there's more people stepping up to be
> > > maintainers, but there's a backlog of bad bindings already merged.
> > > 
> > > Often they are produced by translating the platform_data structures
> > > directly over into device-tree properties without consideration to
> > > describing the hardware or usual conventions, using key/value pairs
> > > instead of boolean properties, etc.
> > > 
> > > Getting involved in cleaning up these kind of bindings is a great
> > > way
> > > to learn "the ways of device tree" for someone that has interest in
> > > that.
> > > 
> > > Latest find in this area is the Maxim 8925 bindings, that I came
> > > across since they caused a compile warning on some defconfig. I'll
> > > post a patch to address the warning but if someone else feels like
> > > fixing the bindings on top of it that would be appreciated!
> > 
> > Are they documented typically? Can we at a minimum update the
> > documentation with a big fat warning to not use or propagate the crap.
> > Or move the binding doc file to a fixme directory.
> 
> I agree, in order to do the janitorial work (which I'm not opposed to
> helping with), we need a way to mark stable bindings.
> 
> fwiw, we could do a separate commit (like the kernel version commit)
> where the only change is marking a binding as stable, and is obvious
> from a 'git log --oneline'. eg:
> 
> ---->8------
> 
> From 65c069678cdbd5aaa6aca0d4062dab6eb9f9904c Mon Sep 17 00:00:00 2001
> From: Jason Cooper <jason at lakedaemon.net>
> Date: Wed, 24 Jul 2013 18:49:28 +0000
> Subject: [PATCH] DT: binding: stable: gpio-regulator
> 
> A whole bunch of folks reviewed this and think it kicks ass.
> 
> List-of-people-responsible-for-this-travesty: ...
> Signed-off-by: Jason Cooper <jason at lakedaemon.net>
> ---
>  Documentation/devicetree/bindings/regulator/gpio-regulator.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git
> a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
> b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt index
> 63c6598..35ec635 100644
> --- a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
> @@ -1,3 +1,5 @@
> +Binding status: Stable
> +
>  GPIO controlled regulators
> 
>  Required properties:

This looks fine for me, but what about adopting the scheme used for 
drivers and having a staging subdirectory inside bindings/ directory where 
a whole tree of staging bindings would be located? Then marking a binding 
as stable would mean moving it out of this directory.

As for janitoring/cleanup itself, we should start some witch^Wbinding-hunt 
to check all the existing binding for sanity and probably make a list of 
bindings that are not acceptable and possibly contact people responsible 
for them as they are primary candidates to work on fixing bindings they 
introduced.

I also think we should start the periodic binding review meetings and get 
some bindings stabilized, so they could be used as good examples for 
people working on new bindings or fixing existing ones.

Best regards,
Tomasz

P.S. Is it just me or something is wrong with devicetree at vger.kernel.org 
mailing list? I don't receive any messages from it.



From markus.mayer at linaro.org  Wed Jul 24 19:35:21 2013
From: markus.mayer at linaro.org (Markus Mayer)
Date: Wed, 24 Jul 2013 16:35:21 -0700
Subject: [PATCH v2 0/2] ARM: bcm281xx: Board specific reboot code
Message-ID: <1374708923-11956-1-git-send-email-markus.mayer@linaro.org>

This is a slightly reworked version of the reboot code posted earlier.
It has been rebased on 3.11-rc1.

The original patches are here:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/180814.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/180817.html

Changes since v1 include:
  - change vendor prefix for watchdog from "bcm," to "brcm,"
  - change bcm_kona_restart() to use enum reboot_mode as first parameter
  - error checking to catch unmapped watchdog or missing DT entry
  - removal of unused #define
  - formatting changes
  - additional comments in code


Markus Mayer (2):
  ARM: bcm281xx: Board specific reboot code
  ARM: bcm281xx: DT changes for reboot code

 .../devicetree/bindings/arm/bcm/bcm,kona-wdt.txt   |   15 +++++
 arch/arm/boot/dts/bcm11351.dtsi                    |    7 ++-
 arch/arm/mach-bcm/Makefile                         |    4 +-
 arch/arm/mach-bcm/board_bcm.c                      |   20 +++++-
 arch/arm/mach-bcm/kona.c                           |   65 ++++++++++++++++++++
 arch/arm/mach-bcm/kona.h                           |   17 +++++
 6 files changed, 122 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/bcm,kona-wdt.txt
 create mode 100644 arch/arm/mach-bcm/kona.c
 create mode 100644 arch/arm/mach-bcm/kona.h

-- 
1.7.9.5




From markus.mayer at linaro.org  Wed Jul 24 19:35:22 2013
From: markus.mayer at linaro.org (Markus Mayer)
Date: Wed, 24 Jul 2013 16:35:22 -0700
Subject: [PATCH v2 1/2] ARM: bcm281xx: Board specific reboot code
In-Reply-To: <1374708923-11956-1-git-send-email-markus.mayer@linaro.org>
References: <1374708923-11956-1-git-send-email-markus.mayer@linaro.org>
Message-ID: <1374708923-11956-2-git-send-email-markus.mayer@linaro.org>

This patch adds the code needed to trigger a reboot on the bcm281xx
family.

Signed-off-by: Markus Mayer <markus.mayer at linaro.org>
Reviewed-by: Tim Kryger <tim.kryger at linaro.org>
Reviewed-by: Matt Porter <matt.porter at linaro.org>
Reviewed-by: Alex Elder <alex.elder at linaro.org>
Acked-by: Christian Daudt <csd at broadcom.com>
---
 arch/arm/mach-bcm/Makefile    |    4 +--
 arch/arm/mach-bcm/board_bcm.c |   20 +++++++++++--
 arch/arm/mach-bcm/kona.c      |   65 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-bcm/kona.h      |   17 +++++++++++
 4 files changed, 101 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-bcm/kona.c
 create mode 100644 arch/arm/mach-bcm/kona.h

diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 6adb6aec..7e5ca0a 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2012 Broadcom Corporation
+# Copyright (C) 2012-2013 Broadcom Corporation
 #
 # This program is free software; you can redistribute it and/or
 # modify it under the terms of the GNU General Public License as
@@ -10,6 +10,6 @@
 # of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 # GNU General Public License for more details.
 
-obj-$(CONFIG_ARCH_BCM)		:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
+obj-$(CONFIG_ARCH_BCM)	:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o kona.o
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_bcm_kona_smc_asm.o	:=-Wa,-march=armv7-a$(plus_sec)
diff --git a/arch/arm/mach-bcm/board_bcm.c b/arch/arm/mach-bcm/board_bcm.c
index 2859932..1e49ec0 100644
--- a/arch/arm/mach-bcm/board_bcm.c
+++ b/arch/arm/mach-bcm/board_bcm.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2012 Broadcom Corporation
+ * Copyright (C) 2012-2013 Broadcom Corporation
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
@@ -21,8 +21,8 @@
 #include <asm/mach/time.h>
 #include <asm/hardware/cache-l2x0.h>
 
-
 #include "bcm_kona_smc.h"
+#include "kona.h"
 
 static int __init kona_l2_cache_init(void)
 {
@@ -40,13 +40,26 @@ static int __init kona_l2_cache_init(void)
 	return 0;
 }
 
+static void bcm_board_setup_restart(void)
+{
+	struct device_node *np;
+
+	np = of_find_compatible_node(NULL, NULL, "bcm,bcm11351");
+	if (np) {
+		if (of_device_is_available(np))
+			bcm_kona_setup_restart();
+		of_node_put(np);
+	}
+	/* Restart setup for other boards goes here */
+}
+
 static void __init board_init(void)
 {
 	of_platform_populate(NULL, of_default_bus_match_table, NULL,
 		&platform_bus);
 
 	bcm_kona_smc_init();
-
+	bcm_board_setup_restart();
 	kona_l2_cache_init();
 }
 
@@ -55,5 +68,6 @@ static const char * const bcm11351_dt_compat[] = { "bcm,bcm11351", NULL, };
 DT_MACHINE_START(BCM11351_DT, "Broadcom Application Processor")
 	.init_time = clocksource_of_init,
 	.init_machine = board_init,
+	.restart = bcm_kona_restart,
 	.dt_compat = bcm11351_dt_compat,
 MACHINE_END
diff --git a/arch/arm/mach-bcm/kona.c b/arch/arm/mach-bcm/kona.c
new file mode 100644
index 0000000..6939d90
--- /dev/null
+++ b/arch/arm/mach-bcm/kona.c
@@ -0,0 +1,65 @@
+/*
+ * Copyright (C) 2013 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/of_address.h>
+#include <asm/io.h>
+
+#include "kona.h"
+
+static void __iomem *watchdog_base;
+
+void bcm_kona_setup_restart(void)
+{
+	struct device_node *np_wdog;
+
+	/*
+	 * The assumption is that whoever calls bcm_kona_setup_restart()
+	 * also needs a Kona Watchdog Timer entry in Device Tree, i.e. we
+	 * report an error if the DT entry is missing.
+	 */
+	np_wdog = of_find_compatible_node(NULL, NULL, "brcm,kona-wdt");
+	if (!np_wdog) {
+		pr_err("brcm,kona-wdt not found in DT, reboot disabled\n");
+		return;
+	}
+	watchdog_base = of_iomap(np_wdog, 0);
+	WARN(!watchdog_base, "failed to map watchdog base");
+	of_node_put(np_wdog);
+}
+
+#define SECWDOG_OFFSET			0x00000000
+#define SECWDOG_RESERVED_MASK		0xE2000000
+#define SECWDOG_WD_LOAD_FLAG_MASK	0x10000000
+#define SECWDOG_EN_MASK			0x08000000
+#define SECWDOG_SRSTEN_MASK		0x04000000
+#define SECWDOG_CLKS_SHIFT		20
+#define SECWDOG_LOCK_SHIFT		0
+
+void bcm_kona_restart(enum reboot_mode mode, const char *cmd)
+{
+	uint32_t val;
+
+	if (!watchdog_base)
+		panic("Watchdog not mapped. Reboot failed.\n");
+
+	/* Enable watchdog2 with very short timeout. */
+	val = readl(watchdog_base + SECWDOG_OFFSET);
+	val &= SECWDOG_RESERVED_MASK | SECWDOG_WD_LOAD_FLAG_MASK;
+	val |= SECWDOG_EN_MASK | SECWDOG_SRSTEN_MASK |
+		(0x8 << SECWDOG_CLKS_SHIFT) |
+		(0x8 << SECWDOG_LOCK_SHIFT);
+	writel(val, watchdog_base + SECWDOG_OFFSET);
+
+	while (1)
+		;
+}
diff --git a/arch/arm/mach-bcm/kona.h b/arch/arm/mach-bcm/kona.h
new file mode 100644
index 0000000..291eca3
--- /dev/null
+++ b/arch/arm/mach-bcm/kona.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2013 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/reboot.h>
+
+void bcm_kona_setup_restart(void);
+void bcm_kona_restart(enum reboot_mode mode, const char *cmd);
-- 
1.7.9.5




From markus.mayer at linaro.org  Wed Jul 24 19:35:23 2013
From: markus.mayer at linaro.org (Markus Mayer)
Date: Wed, 24 Jul 2013 16:35:23 -0700
Subject: [PATCH v2 2/2] ARM: bcm281xx: DT changes for reboot code
In-Reply-To: <1374708923-11956-1-git-send-email-markus.mayer@linaro.org>
References: <1374708923-11956-1-git-send-email-markus.mayer@linaro.org>
Message-ID: <1374708923-11956-3-git-send-email-markus.mayer@linaro.org>

This patch adds the device tree bindings for the bcm281xx reboot code.

Signed-off-by: Markus Mayer <markus.mayer at linaro.org>
Reviewed-by: Tim Kryger <tim.kryger at linaro.org>
Acked-by: Christian Daudt <csd at broadcom.com>
---
 .../devicetree/bindings/arm/bcm/bcm,kona-wdt.txt   |   15 +++++++++++++++
 arch/arm/boot/dts/bcm11351.dtsi                    |    7 ++++++-
 2 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/bcm,kona-wdt.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm,kona-wdt.txt b/Documentation/devicetree/bindings/arm/bcm/bcm,kona-wdt.txt
new file mode 100644
index 0000000..bb7be64
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/bcm,kona-wdt.txt
@@ -0,0 +1,15 @@
+Broadcom Kona Family Watchdog Timer
+-----------------------------------
+
+This watchdog timer is used in the following Broadcom SoCs:
+  BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
+
+Required properties:
+  - compatible = "brcm,kona-wdt";
+  - reg: memory range
+
+Example:
+	watchdog at 35002f40 {
+		compatible = "brcm,kona-wdt";
+		reg = <0x35002f40 0x6c>;
+	};
diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index c0cdf66..a1c1881 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2012 Broadcom Corporation
+ * Copyright (C) 2012-2013 Broadcom Corporation
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
@@ -56,6 +56,11 @@
 		cache-level = <2>;
 	};
 
+	watchdog at 35002f40 {
+		compatible = "bcm,kona-wdt";
+		reg = <0x35002f40 0x6c>;
+	};
+
 	timer at 35006000 {
 		compatible = "bcm,kona-timer";
 		reg = <0x35006000 0x1000>;
-- 
1.7.9.5




From nico at fluxnic.net  Wed Jul 24 19:41:10 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Wed, 24 Jul 2013 19:41:10 -0400 (EDT)
Subject: [PATCH 14/14] ARM: set --be8 when linking modules
In-Reply-To: <1374661682-9349-15-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-15-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <alpine.LFD.2.03.1307241930550.15022@syhkavp.arg>

On Wed, 24 Jul 2013, Ben Dooks wrote:

> To avoid having to make every text section swap the instruction order
> of all instructions, make sure modules are built also built with --be8
> (as is the current kernel final link).
> 
> If we do not do this, we would end up having to swap all instructions
> when loading a module, instead of just the instructions that we are
> applying ELF relocations to.

That wouldn't work anyway as you'd also swap constants embedded in the 
instruction stream such as literal pools which are most certainly in BE 
mode already.

> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>

Please make sure the kernel will reject modules if they're not compiled 
appropriately.  Either by looking at the ELF record or by altering 
MODULE_ARCH_VERMAGIC.


Nicolas


From jason at lakedaemon.net  Wed Jul 24 19:52:21 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 24 Jul 2013 19:52:21 -0400
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <3403223.vsyjiUcZ9s@flatron>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
 <51F01D64.9060609@gmail.com>
 <20130724190315.GC23879@titan.lakedaemon.net>
 <3403223.vsyjiUcZ9s@flatron>
Message-ID: <20130724235221.GF23879@titan.lakedaemon.net>

On Thu, Jul 25, 2013 at 01:29:28AM +0200, Tomasz Figa wrote:
> On Wednesday 24 of July 2013 15:03:15 Jason Cooper wrote:
> > On Wed, Jul 24, 2013 at 01:31:00PM -0500, Rob Herring wrote:
> > > On 07/24/2013 10:27 AM, Olof Johansson wrote:
> > > > Every now and then I come across a binding that's just done
> > > > Wrong(tm),
> > > > merged through a submaintainer tree and hasn't seen proper review --
> > > > if it had, it wouldn't look the way it does. It's something we're
> > > > starting to address now since there's more people stepping up to be
> > > > maintainers, but there's a backlog of bad bindings already merged.
> > > > 
> > > > Often they are produced by translating the platform_data structures
> > > > directly over into device-tree properties without consideration to
> > > > describing the hardware or usual conventions, using key/value pairs
> > > > instead of boolean properties, etc.
> > > > 
> > > > Getting involved in cleaning up these kind of bindings is a great
> > > > way
> > > > to learn "the ways of device tree" for someone that has interest in
> > > > that.
> > > > 
> > > > Latest find in this area is the Maxim 8925 bindings, that I came
> > > > across since they caused a compile warning on some defconfig. I'll
> > > > post a patch to address the warning but if someone else feels like
> > > > fixing the bindings on top of it that would be appreciated!
> > > 
> > > Are they documented typically? Can we at a minimum update the
> > > documentation with a big fat warning to not use or propagate the crap.
> > > Or move the binding doc file to a fixme directory.
> > 
> > I agree, in order to do the janitorial work (which I'm not opposed to
> > helping with), we need a way to mark stable bindings.
> > 
> > fwiw, we could do a separate commit (like the kernel version commit)
> > where the only change is marking a binding as stable, and is obvious
> > from a 'git log --oneline'. eg:
> > 
> > ---->8------
> > 
> > From 65c069678cdbd5aaa6aca0d4062dab6eb9f9904c Mon Sep 17 00:00:00 2001
> > From: Jason Cooper <jason at lakedaemon.net>
> > Date: Wed, 24 Jul 2013 18:49:28 +0000
> > Subject: [PATCH] DT: binding: stable: gpio-regulator
> > 
> > A whole bunch of folks reviewed this and think it kicks ass.
> > 
> > List-of-people-responsible-for-this-travesty: ...
> > Signed-off-by: Jason Cooper <jason at lakedaemon.net>
> > ---
> >  Documentation/devicetree/bindings/regulator/gpio-regulator.txt | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
> > b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt index
> > 63c6598..35ec635 100644
> > --- a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
> > +++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
> > @@ -1,3 +1,5 @@
> > +Binding status: Stable
> > +
> >  GPIO controlled regulators
> > 
> >  Required properties:
> 
> This looks fine for me, but what about adopting the scheme used for 
> drivers and having a staging subdirectory inside bindings/ directory where 
> a whole tree of staging bindings would be located? Then marking a binding 
> as stable would mean moving it out of this directory.

I'm not opposed to the concept of a staging directory per-se, I just
don't see a need for it.  We aren't coaxing horrible code into workable
form suitable for mainline.  I doubt the fixes to any given binding will
be a large patch series, much less span multiple merge windows.  It just
seems like churn to me to move stuff to 'staging', apply one patch, and
move it back.

The only advantage I see is that users would need to type 'staging' to
get to it, thus cluing them in to the tenuous state of the binding.
That is a definite advantage.  I'm at a loss to find a better
clue-hammer than this to make it clear as to the state of the binding.
To that end, I'd prefer 'unstable'.

Of course, the key question to ask is, how long will this take?  If we
think it will span multiple merge windows, then we should probably do
it.

> As for janitoring/cleanup itself, we should start some witch^Wbinding-hunt 
> to check all the existing binding for sanity and probably make a list of 
> bindings that are not acceptable and possibly contact people responsible 
> for them as they are primary candidates to work on fixing bindings they 
> introduced.
> 
> I also think we should start the periodic binding review meetings and get 
> some bindings stabilized, so they could be used as good examples for 
> people working on new bindings or fixing existing ones.

Once the witch-hunt is completed, there shouldn't be a need to do periodic
review.  It should be reviewed *before* merging.  That'll be easier once
it's a separate tree.

thx,

Jason.


From olof at lixom.net  Wed Jul 24 19:58:44 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Jul 2013 16:58:44 -0700
Subject: [PATCH] ARM: omap2: Only select errata 798181 if SMP
Message-ID: <1374710324-24347-1-git-send-email-olof@lixom.net>

Avoids the following warning when SMP is off:

warning: (ARCH_KEYSTONE && SOC_OMAP5) selects ARM_ERRATA_798181 which
has unmet direct dependencies (CPU_V7 && SMP)

Cc: Tony Lindgren <tony at atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar at ti.com>
Signed-off-by: Olof Johansson <olof at lixom.net>
---

Since this is trivial I've already applied it to fixes on arm-soc.

 arch/arm/mach-omap2/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 627fa7e..3eed000 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -62,7 +62,7 @@ config SOC_OMAP5
 	select HAVE_SMP
 	select COMMON_CLK
 	select HAVE_ARM_ARCH_TIMER
-	select ARM_ERRATA_798181
+	select ARM_ERRATA_798181 if SMP
 
 config SOC_AM33XX
 	bool "AM33XX support"
-- 
1.8.1.192.gc4361b8



From santosh.shilimkar at ti.com  Wed Jul 24 19:59:57 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 24 Jul 2013 19:59:57 -0400
Subject: [PATCH] ARM: omap2: Only select errata 798181 if SMP
In-Reply-To: <1374710324-24347-1-git-send-email-olof@lixom.net>
References: <1374710324-24347-1-git-send-email-olof@lixom.net>
Message-ID: <51F06A7D.4020201@ti.com>

On Wednesday 24 July 2013 07:58 PM, Olof Johansson wrote:
> Avoids the following warning when SMP is off:
> 
> warning: (ARCH_KEYSTONE && SOC_OMAP5) selects ARM_ERRATA_798181 which
> has unmet direct dependencies (CPU_V7 && SMP)
> 
> Cc: Tony Lindgren <tony at atomide.com>
> Cc: Santosh Shilimkar <santosh.shilimkar at ti.com>
> Signed-off-by: Olof Johansson <olof at lixom.net>
> ---
> 
> Since this is trivial I've already applied it to fixes on arm-soc.
> 
yep.

Regards,
Santosh



From markus.mayer at linaro.org  Wed Jul 24 19:46:05 2013
From: markus.mayer at linaro.org (Markus Mayer)
Date: Wed, 24 Jul 2013 16:46:05 -0700
Subject: [PATCH v2 2/2] ARM: bcm281xx: DT changes for reboot code
In-Reply-To: <1374708923-11956-3-git-send-email-markus.mayer@linaro.org>
References: <1374708923-11956-1-git-send-email-markus.mayer@linaro.org>
 <1374708923-11956-3-git-send-email-markus.mayer@linaro.org>
Message-ID: <CAPdLdqmKt-KfzWKHw1qA6pgUjGBgsnhf8YkQtOyySWOLvHt74Q@mail.gmail.com>

On 24 July 2013 16:35, Markus Mayer <markus.mayer at linaro.org> wrote:
> This patch adds the device tree bindings for the bcm281xx reboot code.
>
> Signed-off-by: Markus Mayer <markus.mayer at linaro.org>
> Reviewed-by: Tim Kryger <tim.kryger at linaro.org>
> Acked-by: Christian Daudt <csd at broadcom.com>
> ---
>  .../devicetree/bindings/arm/bcm/bcm,kona-wdt.txt   |   15 +++++++++++++++
>  arch/arm/boot/dts/bcm11351.dtsi                    |    7 ++++++-
>  2 files changed, 21 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/bcm/bcm,kona-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm,kona-wdt.txt b/Documentation/devicetree/bindings/arm/bcm/bcm,kona-wdt.txt
> new file mode 100644
> index 0000000..bb7be64
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/bcm/bcm,kona-wdt.txt
> @@ -0,0 +1,15 @@
> +Broadcom Kona Family Watchdog Timer
> +-----------------------------------
> +
> +This watchdog timer is used in the following Broadcom SoCs:
> +  BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
> +
> +Required properties:
> +  - compatible = "brcm,kona-wdt";
> +  - reg: memory range
> +
> +Example:
> +       watchdog at 35002f40 {
> +               compatible = "brcm,kona-wdt";
> +               reg = <0x35002f40 0x6c>;
> +       };
> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> index c0cdf66..a1c1881 100644
> --- a/arch/arm/boot/dts/bcm11351.dtsi
> +++ b/arch/arm/boot/dts/bcm11351.dtsi
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (C) 2012 Broadcom Corporation
> + * Copyright (C) 2012-2013 Broadcom Corporation
>   *
>   * This program is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU General Public License as
> @@ -56,6 +56,11 @@
>                 cache-level = <2>;
>         };
>
> +       watchdog at 35002f40 {
> +               compatible = "bcm,kona-wdt";

This oversight in the compatible string has been fixed.

> +               reg = <0x35002f40 0x6c>;
> +       };
> +
>         timer at 35006000 {
>                 compatible = "bcm,kona-timer";
>                 reg = <0x35006000 0x1000>;
> --
> 1.7.9.5
>
>

-- 
Markus Mayer
Broadcom Landing Team


From nicolas.pitre at linaro.org  Wed Jul 24 20:27:21 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 24 Jul 2013 20:27:21 -0400 (EDT)
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <20130723163319.GA781@e102568-lin.cambridge.arm.com>
References: <1374118116-16836-2-git-send-email-nicolas.pitre@linaro.org>
 <20130718150408.GB2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181231510.14924@syhkavp.arg>
 <20130718180323.GC2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181452480.14924@syhkavp.arg>
 <20130719102844.GA3746@localhost.localdomain>
 <20130719105907.GB27389@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307221353360.15022@syhkavp.arg>
 <20130723104352.GA3023@localhost.localdomain>
 <alpine.LFD.2.03.1307230821270.15022@syhkavp.arg>
 <20130723163319.GA781@e102568-lin.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1307242010580.15022@syhkavp.arg>

On Tue, 23 Jul 2013, Lorenzo Pieralisi wrote:

> On Tue, Jul 23, 2013 at 01:28:16PM +0100, Nicolas Pitre wrote:
> 
> [...]
> 
> > > > + * - The CPU is obviously no longer coherent with the other CPUs.
> > > > + *
> > > > + * Further considerations:
> > > > + *
> > > > + * - This relies on the presence and behavior of the AUXCR.SMP bit as
> > > > + *   documented in the ARMv7 TRM.  Vendor implementations that deviate from
> > > 
> > > Sorry to be pedantic here, but there is no "ARMv7 TRM".  The SMP bit is
> > > not part of ARMv7 at all.
> > 
> > Well, I just copied Lorenzo's words here, trusting he knew more about it 
> > than I do.
> > 
> > > Also, it seems that A9 isn't precisely the
> > > same: two ACTLR bits need to be twiddled.  R-class CPUs are generally
> > > not the same either.
> 
> If you mean the ACTLR.FW bit in A9, A5, and R7, then, IIRC, we do not need to
> clear it, clearing the SMP bit is enough.
> 
> See, Dave has a point, there is no explicit "unified v7 TRM disable
> clean and exit coherency procedure" even though the designers end goal is to
> have one and that's the one you wrote. The code you posted is perfectly ok on
> all v7 implementations in the kernel I am aware of, I stand to be corrected
> but to the best of my knowledge that's the case.

OK, I'm removing allusion to an ARMv7 TRM from the comment.

> > > This is why I preferred to treat the whole sequence as specific to a
> > > particular CPU implementation.  The similarity between A7 and A15
> > > might be viewed as a happy coincidence (it also makes life easier in
> > > big.LITTLE land).
> > 
> > Fair enough.
> 
> I disagree on the happy coincidence but the point is taken. I am not
> sure about what we should do, but I reiterate my point, the sequence as
> it stands is OK on all NS v7 implementations I am aware of. We can add
> macros to differentiate processors when we need them, but again that's
> just my opinion, as correct as it can be.

I tend to prefer that as well.

"In theory, practice and theory are equivalent, but in practice they're not"

So if in _practice_ all the ARMv7 implementations we care about are OK 
with the above, then I don't see why we couldn't call it v7_*.

Here's the portion of the patch that I just changed.  All the rest 
stayed the same.  What do you think?

--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -436,4 +436,38 @@ static inline void __sync_cache_range_r(volatile void *p, size_t size)
 #define sync_cache_w(ptr) __sync_cache_range_w(ptr, sizeof *(ptr))
 #define sync_cache_r(ptr) __sync_cache_range_r(ptr, sizeof *(ptr))
 
+/*
+ * Disabling cache access for one CPU in an ARMv7 SMP system is tricky.
+ * To do so we must:
+ *
+ * - Clear the SCTLR.C bit to prevent further cache allocations
+ * - Flush the desired level of cache
+ * - Clear the ACTLR "SMP" bit to disable local coherency
+ *
+ * ... and so without any intervening memory access in between those steps,
+ * not even to the stack.
+ *
+ * WARNING -- After this has been called:
+ *
+ * - No ldrex/strex (and similar) instructions must be used.
+ * - The CPU is obviously no longer coherent with the other CPUs.
+ * - This is unlikely to work as expected if Linux is running non-secure.
+ */
+#define v7_exit_coherency_flush(level) \
+	asm volatile( \
+	"mrc	p15, 0, r0, c1, c0, 0	@ get SCTLR \n\t" \
+	"bic	r0, r0, #"__stringify(CR_C)" \n\t" \
+	"mcr	p15, 0, r0, c1, c0, 0	@ set SCTLR \n\t" \
+	"isb	\n\t" \
+	"bl	v7_flush_dcache_"__stringify(level)" \n\t" \
+	"clrex	\n\t" \
+	"mrc	p15, 0, r0, c1, c0, 1	@ get ACTLR \n\t" \
+	"bic	r0, r0, #(1 << 6)	@ disable local coherency \n\t" \
+	"mcr	p15, 0, r0, c1, c0, 1	@ set ACTLR \n\t" \
+	"isb	\n\t" \
+	"dsb	" \
+	/* The clobber list is dictated by the call to v7_flush_dcache_* */ \
+	: : : "r0","r1","r2","r3","r4","r5","r6","r7", \
+	      "r9","r10","r11","lr","memory" )
+
 #endif


Nicolas



From santosh.shilimkar at ti.com  Wed Jul 24 20:28:19 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 24 Jul 2013 20:28:19 -0400
Subject: [PATCH 2/2] i2c: davinci: Allow i2c driver available for keystone
 platforms
In-Reply-To: <1374712099-32095-1-git-send-email-santosh.shilimkar@ti.com>
References: <1374712099-32095-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1374712099-32095-3-git-send-email-santosh.shilimkar@ti.com>

Keystone SOCs uses the same I2C IP as available on DaVinci SOCs.
Update the config so that ARCH_KEYSTONE can use it.

Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Wolfram Sang <wsa at the-dreams.de>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 drivers/i2c/busses/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index dc6dea6..fcdd321 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -385,7 +385,7 @@ config I2C_CPM
 
 config I2C_DAVINCI
 	tristate "DaVinci I2C driver"
-	depends on ARCH_DAVINCI
+	depends on ARCH_DAVINCI || ARCH_KEYSTONE
 	help
 	  Support for TI DaVinci I2C controller driver.
 
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Wed Jul 24 20:28:18 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 24 Jul 2013 20:28:18 -0400
Subject: [PATCH 1/2] i2c: davinci: remove useless mach/hardware include
In-Reply-To: <1374712099-32095-1-git-send-email-santosh.shilimkar@ti.com>
References: <1374712099-32095-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1374712099-32095-2-git-send-email-santosh.shilimkar@ti.com>

This driver no longer uses definitions from mach/hardware.h.
On the other hand, including this header breaks this driver
on non-davinci platforms which don't have such a header.

Fix it.

Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Wolfram Sang <wsa at the-dreams.de>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 drivers/i2c/busses/i2c-davinci.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index fa55605..ddaa2a3 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -41,7 +41,6 @@
 #include <linux/of_i2c.h>
 #include <linux/of_device.h>
 
-#include <mach/hardware.h>
 #include <linux/platform_data/i2c-davinci.h>
 
 /* ----- global defines ----------------------------------------------- */
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Wed Jul 24 20:28:17 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 24 Jul 2013 20:28:17 -0400
Subject: [PATCH 0/2] i2c: davinci: Couple of patches to make i2c usable on
 Keystone SOCs
Message-ID: <1374712099-32095-1-git-send-email-santosh.shilimkar@ti.com>

Keystone SOCs uses the same I2C IP as available on DaVinci SOCs. These
couple of patches makes it possible to select the I2C_DAVINCI on
Keystone SOCs.

Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Wolfram Sang <wsa at the-dreams.de>

Santosh Shilimkar (2):
  i2c: davinci: remove useless mach/hardware include
  i2c: davinci: Allow i2c driver available for keystone platforms

 drivers/i2c/busses/Kconfig       |    2 +-
 drivers/i2c/busses/i2c-davinci.c |    1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

-- 
1.7.9.5



From santosh.shilimkar at ti.com  Wed Jul 24 20:31:37 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 24 Jul 2013 20:31:37 -0400
Subject: [PATCH] spi: davinci: Update configs to make it selectable on Keystone
Message-ID: <1374712297-32187-1-git-send-email-santosh.shilimkar@ti.com>

Keystone2 SOCs share the SPI IP block with DaVinci based SOCs. Update
the config bits so that its usable on Keystone2 based SOCs.

Cc: Mark Brown <broonie at kernel.org>
Cc: Grant Likely <grant.likely at linaro.org>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 drivers/spi/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 89cbbab..3858d66 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -151,7 +151,7 @@ config SPI_COLDFIRE_QSPI
 
 config SPI_DAVINCI
 	tristate "Texas Instruments DaVinci/DA8x/OMAP-L/AM1x SoC SPI controller"
-	depends on ARCH_DAVINCI
+	depends on ARCH_DAVINCI || ARCH_KEYSTONE
 	select SPI_BITBANG
 	select TI_EDMA
 	help
-- 
1.7.9.5



From cavokz at gmail.com  Wed Jul 24 20:36:51 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Thu, 25 Jul 2013 02:36:51 +0200
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <CAOesGMh9UMOXMENPe5pndHu7_OkEhdcj47q3fTasJS-dOtQssQ@mail.gmail.com>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
 <20130724231755.GC29801@glitch>
 <CAOesGMh9UMOXMENPe5pndHu7_OkEhdcj47q3fTasJS-dOtQssQ@mail.gmail.com>
Message-ID: <20130725003651.GD29801@glitch>

On Wed, Jul 24, 2013 at 04:20:48PM -0700, Olof Johansson wrote:
> On Wed, Jul 24, 2013 at 4:17 PM, Domenico Andreoli <cavokz at gmail.com> wrote:
> > On Wed, Jul 24, 2013 at 08:27:13AM -0700, Olof Johansson wrote:
> >> Every now and then I come across a binding that's just done Wrong(tm),
> >> merged through a submaintainer tree and hasn't seen proper review --
> >> if it had, it wouldn't look the way it does. It's something we're
> >> starting to address now since there's more people stepping up to be
> >> maintainers, but there's a backlog of bad bindings already merged.
> >
> > Where is this backlog?
> 
> There is no list of them, if that is what you are asking for. If
> people are interested in cleaning them up one could be started. Which
> is why I was gauging interest.

Wanted to see the kind of issues and find something to start with. I expect
some hints because I clearly cannot find what/where is wrong on my own.

> 
> -Olof

Domenico


From nicolas.pitre at linaro.org  Wed Jul 24 20:39:21 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 24 Jul 2013 20:39:21 -0400 (EDT)
Subject: [GIT PULL] MCPM backends update
In-Reply-To: <alpine.LFD.2.03.1307221521200.15022@syhkavp.arg>
References: <alpine.LFD.2.03.1307221521200.15022@syhkavp.arg>
Message-ID: <alpine.LFD.2.03.1307242035340.15022@syhkavp.arg>


FYI: the ARMv7 cache disable consolidation patch currently being 
discussed is _not_ part of this pull request.


On Mon, 22 Jul 2013, Nicolas Pitre wrote:

> Hello gents,
> 
> Would you please pull the following into ARM-SOC:
> 
> 	git://git.linaro.org/people/nico/linux mcpm+tc2
> 
> This contains
> 
> - Fixes to the existing Vexpress DCSCB backend.
> 
> - Lorenzo's minimal SPC driver required by the TC2 MCPM backend.
>   As discussed on the list, this is not considered to be a MFD driver.
>   This hardly qualify as a bus driver either.  Conceptually, this is
>   a very platform specific register multiplex driver allowing subsystem
>   drivers to hook into.  I therefore moved it to 
>   drivers/platform/vexpress/ which seems to please everyone.
> 
> - The MCPM backend enabling SMP secondary boot and CPU hotplug
>   on the VExpress TC2 big.LITTLE platform.
> 
> - MCPM suspend method to the TC2 backend allowing basic CPU 
>   idle/suspend.  The cpuidle driver that hooks into this will be 
>   submitted separately.
> 
> This is based on v3.11-rc2.  The diffstat follows:
> 
>  .../devicetree/bindings/arm/vexpress-spc.txt       |  36 +++
>  arch/arm/mach-vexpress/Kconfig                     |   9 +
>  arch/arm/mach-vexpress/Makefile                    |   1 +
>  arch/arm/mach-vexpress/dcscb.c                     |  58 ++--
>  arch/arm/mach-vexpress/tc2_pm.c                    | 304 +++++++++++++++++++++
>  drivers/platform/Kconfig                           |   4 +-
>  drivers/platform/Makefile                          |   1 +
>  drivers/platform/vexpress/Kconfig                  |   9 +
>  drivers/platform/vexpress/Makefile                 |   1 +
>  drivers/platform/vexpress/spc.c                    | 253 +++++++++++++++++
>  include/linux/vexpress.h                           |  17 ++
>  11 files changed, 671 insertions(+), 22 deletions(-)
> 
> 
> Nicolas
> 


From sboyd at codeaurora.org  Wed Jul 24 20:43:29 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:29 -0700
Subject: [PATCH v1 01/14] clk: fixed-rate: Export clk_fixed_rate_register()
In-Reply-To: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374713022-6049-2-git-send-email-sboyd@codeaurora.org>

Export this symbol so that modules can register fixed rate
clocks.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clk-fixed-rate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index dc58fbd..1ed591a 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -80,6 +80,7 @@ struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
 
 	return clk;
 }
+EXPORT_SYMBOL_GPL(clk_register_fixed_rate);
 
 #ifdef CONFIG_OF
 /**
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 20:43:31 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:31 -0700
Subject: [PATCH v1 03/14] clk: Add of_clk_match() for device drivers
In-Reply-To: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374713022-6049-4-git-send-email-sboyd@codeaurora.org>

In similar fashion as of_regulator_match() add an of_clk_match()
function that finds an initializes clock init_data structs from
devicetree. Drivers should use this API to find clocks that their
device is providing and then iterate over their match table
registering the clocks with the init data parsed.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clk.c            | 64 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/clk-provider.h | 16 +++++++++++
 2 files changed, 80 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index ea8e951b..1e3e0db 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2289,4 +2289,68 @@ err:
 	return -ENOMEM;
 }
 EXPORT_SYMBOL_GPL(of_init_clk_data);
+
+/**
+ * of_clk_match() - Scan and match clock providers from the DT node of a device
+ * @dev: device initializing clock providers
+ * @matches: match table of clocks
+ * @num_matches: number of entries in @matches
+ *
+ * This function uses a match table specified by the clock driver to parse
+ * clock init data from the device tree. @dev is expected to be a device with
+ * a 'clocks' child node containing a set of child nodes, each providing the
+ * init data for one clock. The data parsed from a child node will be matched
+ * to a clock based on the child node's name. Note that the match table is
+ * modified in place.
+ *
+ * Returns the number of matches found or a negative error code on failure.
+ */
+int of_clk_match(struct device *dev, struct of_clk_match *matches,
+		 int num_matches)
+{
+	int count = 0;
+	int err, i;
+	struct device_node *np, *clocks;
+	struct clk_init_data *init;
+
+	clocks = of_find_node_by_name(dev->of_node, "clocks");
+	if (!clocks)
+		return -EINVAL;
+
+	for (i = 0; i < num_matches; i++) {
+		struct of_clk_match *match = &matches[i];
+		match->init_data = NULL;
+		match->of_node = NULL;
+	}
+
+	for_each_available_child_of_node(clocks, np) {
+		for (i = 0; i < num_matches; i++) {
+			struct of_clk_match *match = &matches[i];
+			if (match->of_node)
+				continue;
+
+			if (strcmp(match->name, np->name))
+				continue;
+
+			init = devm_kzalloc(dev, sizeof(*init), GFP_KERNEL);
+			if (!init)
+				return -ENOMEM;
+
+			err = of_init_clk_data(np, init);
+			if (err) {
+				dev_err(dev,
+					"failed to parse DT for clock %s\n",
+					np->name);
+				return err;
+			}
+			match->of_node = np;
+			match->init_data = init;
+			count++;
+			break;
+		}
+	}
+
+	return count;
+}
+EXPORT_SYMBOL_GPL(of_clk_match);
 #endif
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 18d6362..484f8ad 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -461,6 +461,13 @@ struct clk_onecell_data {
 		__used __section(__clk_of_table)		\
 		= { .compatible = compat, .data = fn };
 
+struct of_clk_match {
+	const char *name;
+	void *driver_data;
+	struct clk_init_data *init_data;
+	struct device_node *of_node;
+};
+
 #ifdef CONFIG_OF
 int of_clk_add_provider(struct device_node *np,
 			struct clk *(*clk_src_get)(struct of_phandle_args *args,
@@ -475,6 +482,9 @@ const char *of_clk_get_parent_name(struct device_node *np, int index);
 void of_clk_init(const struct of_device_id *matches);
 int of_init_clk_data(struct device_node *np, struct clk_init_data *init);
 
+int of_clk_match(struct device *dev, struct of_clk_match *matches,
+		 int num_matches);
+
 #else /* !CONFIG_OF */
 
 static inline int of_clk_add_provider(struct device_node *np,
@@ -508,6 +518,12 @@ of_init_clk_data(struct device_node *np, struct clk_init_data *init)
 {
 	return 0;
 }
+static inline int
+of_clk_match(struct device *dev, struct of_clk_match *matches, int num_matches)
+{
+
+	return 0;
+}
 #endif /* CONFIG_OF */
 #endif /* CONFIG_COMMON_CLK */
 #endif /* CLK_PROVIDER_H */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 20:43:28 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:28 -0700
Subject: [PATCH v1 00/14] Add support for MSM's mmio clocks
Message-ID: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>

Reposting this RFC due to conflicts with v3.11-rc1 and because I haven't
gone through and generated all the data needed yet. This is just a few
clocks for now to give a general idea until I get some comments from DT
reviewers.

The first 4 patches are generic clock framework patches. They add support
for finding clocks in DT and parsing them generically. They also add support
for setting the rate and the parent at the same time based on patches from
James Hogan's remuxing set_rate series [1].

After that we add MSM clock hardware support and then fill in the DT and
data to actually register clocks. This is sufficient enough to get the UART
going on my msm8960 device.

If DT reviewers are ok I'll go ahead and generate the rest of the data
and post v2.

Stephen Boyd (14):
  clk: fixed-rate: Export clk_fixed_rate_register()
  clk: Add of_init_clk_data() to parse common clock bindings
  clk: Add of_clk_match() for device drivers
  clk: Add set_rate_and_parent() op
  clk: msm: Add support for phase locked loops (PLLs)
  clk: msm: Add support for root clock generators (RCGs)
  clk: msm: Add support for branches/gate clocks
  clk: msm: Add MSM clock driver
  clk: msm: Add support for MSM8960's global clock controller (GCC)
  clk: msm: Add support for MSM8960's multimedia clock controller (MMCC)
  ARM: dts: msm: Add MSM8960 GCC DT nodes
  ARM: dts: msm: Add MSM8960 MMCC DT nodes
  clk: msm: Add MSM8974 GCC data
  ARM: dts: msm: Add clock entries for MSM8960 uart device

 Documentation/clk.txt                              |   3 +
 Documentation/devicetree/bindings/clock/msm.txt    |  99 +++
 .../devicetree/bindings/clock/qcom,gcc.txt         |  56 ++
 .../devicetree/bindings/clock/qcom,mmcc.txt        |  38 ++
 arch/arm/boot/dts/msm8960-cdp.dts                  | 111 +++
 drivers/clk/Kconfig                                |   2 +
 drivers/clk/Makefile                               |   1 +
 drivers/clk/clk-fixed-rate.c                       |   1 +
 drivers/clk/clk.c                                  | 201 +++++-
 drivers/clk/msm/Kconfig                            |  29 +
 drivers/clk/msm/Makefile                           |  12 +
 drivers/clk/msm/clk-branch.c                       | 190 ++++++
 drivers/clk/msm/clk-branch.h                       |  48 ++
 drivers/clk/msm/clk-pll.c                          | 233 +++++++
 drivers/clk/msm/clk-pll.h                          |  43 ++
 drivers/clk/msm/clk-rcg.c                          | 754 +++++++++++++++++++++
 drivers/clk/msm/clk-rcg.h                          | 114 ++++
 drivers/clk/msm/clk-rcg2.c                         | 320 +++++++++
 drivers/clk/msm/core.c                             | 274 ++++++++
 drivers/clk/msm/gcc-8960.c                         | 174 +++++
 drivers/clk/msm/gcc-8974.c                         | 107 +++
 drivers/clk/msm/internal.h                         |  28 +
 drivers/clk/msm/mmcc-8960.c                        | 142 ++++
 include/linux/clk-provider.h                       |  38 ++
 24 files changed, 2998 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/msm.txt
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,gcc.txt
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,mmcc.txt
 create mode 100644 drivers/clk/msm/Kconfig
 create mode 100644 drivers/clk/msm/Makefile
 create mode 100644 drivers/clk/msm/clk-branch.c
 create mode 100644 drivers/clk/msm/clk-branch.h
 create mode 100644 drivers/clk/msm/clk-pll.c
 create mode 100644 drivers/clk/msm/clk-pll.h
 create mode 100644 drivers/clk/msm/clk-rcg.c
 create mode 100644 drivers/clk/msm/clk-rcg.h
 create mode 100644 drivers/clk/msm/clk-rcg2.c
 create mode 100644 drivers/clk/msm/core.c
 create mode 100644 drivers/clk/msm/gcc-8960.c
 create mode 100644 drivers/clk/msm/gcc-8974.c
 create mode 100644 drivers/clk/msm/internal.h
 create mode 100644 drivers/clk/msm/mmcc-8960.c

[1] Subject: [PATCH v5 0/5] clk: implement remuxing during set_rate                 Message-ID: <1371139562-305-1-git-send-email-james.hogan at imgtec.com>  

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 20:43:32 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:32 -0700
Subject: [PATCH v1 04/14] clk: Add set_rate_and_parent() op
In-Reply-To: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374713022-6049-5-git-send-email-sboyd@codeaurora.org>

Some of Qualcomm's clocks can change their parent and rate at the
same time with a single register write. Add support for this
hardware to the common clock framework by adding a new
set_rate_and_parent() op. When the clock framework determines
that both the parent and the rate are going to change during
clk_set_rate() it will call the .set_rate_and_parent() op if
available and fall back to calling .set_parent() followed by
.set_rate() otherwise.

Cc: James Hogan <james.hogan at imgtec.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 Documentation/clk.txt        |  3 ++
 drivers/clk/clk.c            | 78 +++++++++++++++++++++++++++++++++-----------
 include/linux/clk-provider.h | 15 +++++++++
 3 files changed, 77 insertions(+), 19 deletions(-)

diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index 3aeb5c4..79700ea 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -77,6 +77,9 @@ the operations defined in clk.h:
 		int		(*set_parent)(struct clk_hw *hw, u8 index);
 		u8		(*get_parent)(struct clk_hw *hw);
 		int		(*set_rate)(struct clk_hw *hw, unsigned long);
+		int		(*set_rate_and_parent)(struct clk_hw *hw,
+					    unsigned long rate,
+					    unsigned long parent_rate, u8 index);
 		void		(*init)(struct clk_hw *hw);
 	};
 
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 1e3e0db..73de07c 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1121,10 +1121,9 @@ static void clk_reparent(struct clk *clk, struct clk *new_parent)
 	clk->parent = new_parent;
 }
 
-static int __clk_set_parent(struct clk *clk, struct clk *parent, u8 p_index)
+static struct clk *__clk_set_parent_before(struct clk *clk, struct clk *parent)
 {
 	unsigned long flags;
-	int ret = 0;
 	struct clk *old_parent = clk->parent;
 
 	/*
@@ -1155,6 +1154,34 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent, u8 p_index)
 	clk_reparent(clk, parent);
 	clk_enable_unlock(flags);
 
+	return old_parent;
+}
+
+static void __clk_set_parent_after(struct clk *clk, struct clk *parent,
+		struct clk *old_parent)
+{
+	/*
+	 * Finish the migration of prepare state and undo the changes done
+	 * for preventing a race with clk_enable().
+	 */
+	if (clk->prepare_count) {
+		clk_disable(clk);
+		clk_disable(old_parent);
+		__clk_unprepare(old_parent);
+	}
+
+	/* update debugfs with new clk tree topology */
+	clk_debug_reparent(clk, parent);
+}
+
+static int __clk_set_parent(struct clk *clk, struct clk *parent, u8 p_index)
+{
+	unsigned long flags;
+	int ret = 0;
+	struct clk *old_parent;
+
+	old_parent = __clk_set_parent_before(clk, parent);
+
 	/* change clock input source */
 	if (parent && clk->ops->set_parent)
 		ret = clk->ops->set_parent(clk->hw, p_index);
@@ -1172,18 +1199,8 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent, u8 p_index)
 		return ret;
 	}
 
-	/*
-	 * Finish the migration of prepare state and undo the changes done
-	 * for preventing a race with clk_enable().
-	 */
-	if (clk->prepare_count) {
-		clk_disable(clk);
-		clk_disable(old_parent);
-		__clk_unprepare(old_parent);
-	}
+	__clk_set_parent_after(clk, parent, old_parent);
 
-	/* update debugfs with new clk tree topology */
-	clk_debug_reparent(clk, parent);
 	return 0;
 }
 
@@ -1368,17 +1385,32 @@ static void clk_change_rate(struct clk *clk)
 	struct clk *child;
 	unsigned long old_rate;
 	unsigned long best_parent_rate = 0;
+	bool skip_set_rate = false;
+	struct clk *old_parent;
 
 	old_rate = clk->rate;
 
-	/* set parent */
-	if (clk->new_parent && clk->new_parent != clk->parent)
-		__clk_set_parent(clk, clk->new_parent, clk->new_parent_index);
-
-	if (clk->parent)
+	if (clk->new_parent)
+		best_parent_rate = clk->new_parent->rate;
+	else if (clk->parent)
 		best_parent_rate = clk->parent->rate;
 
-	if (clk->ops->set_rate)
+	if (clk->new_parent && clk->new_parent != clk->parent) {
+		old_parent = __clk_set_parent_before(clk, clk->new_parent);
+
+		if (clk->ops->set_rate_and_parent) {
+			skip_set_rate = true;
+			clk->ops->set_rate_and_parent(clk->hw, clk->new_rate,
+					best_parent_rate,
+					clk->new_parent_index);
+		} else if (clk->ops->set_parent) {
+			clk->ops->set_parent(clk->hw, clk->new_parent_index);
+		}
+
+		__clk_set_parent_after(clk, clk->new_parent, old_parent);
+	}
+
+	if (!skip_set_rate && clk->ops->set_rate)
 		clk->ops->set_rate(clk->hw, clk->new_rate, best_parent_rate);
 
 	if (clk->ops->recalc_rate)
@@ -1664,6 +1696,14 @@ int __clk_init(struct device *dev, struct clk *clk)
 		goto out;
 	}
 
+	if (clk->ops->set_rate_and_parent &&
+			!(clk->ops->set_parent && clk->ops->set_rate)) {
+		pr_warning("%s: %s must implement .set_parent & .set_rate\n",
+				__func__, clk->name);
+		ret = -EINVAL;
+		goto out;
+	}
+
 	/* throw a WARN if any entries in parent_names are NULL */
 	for (i = 0; i < clk->num_parents; i++)
 		WARN(!clk->parent_names[i],
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 484f8ad..1f7eabb 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -108,6 +108,18 @@ struct clk_hw;
  *		which is likely helpful for most .set_rate implementation.
  *		Returns 0 on success, -EERROR otherwise.
  *
+ * @set_rate_and_parent: Change the rate and the parent of this clock. The
+ *		requested rate is specified by the second argument, which
+ *		should typically be the return of .round_rate call.  The
+ *		third argument gives the parent rate which is likely helpful
+ *		for most .set_rate_and_parent implementation. The fourth
+ *		argument gives the parent index. It is optional (and
+ *		unnecessary) for clocks with 0 or 1 parents as well as
+ *		for clocks that can tolerate switching the rate and the parent
+ *		separately via calls to .set_parent and .set_rate.
+ *		Returns 0 on success, -EERROR otherwise.
+ *
+ *
  * The clk_enable/clk_disable and clk_prepare/clk_unprepare pairs allow
  * implementations to split any work between atomic (enable) and sleepable
  * (prepare) contexts.  If enabling a clock requires code that might sleep,
@@ -139,6 +151,9 @@ struct clk_ops {
 	u8		(*get_parent)(struct clk_hw *hw);
 	int		(*set_rate)(struct clk_hw *hw, unsigned long,
 				    unsigned long);
+	int		(*set_rate_and_parent)(struct clk_hw *hw,
+				    unsigned long rate,
+				    unsigned long parent_rate, u8 index);
 	void		(*init)(struct clk_hw *hw);
 };
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 20:43:33 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:33 -0700
Subject: [PATCH v1 05/14] clk: msm: Add support for phase locked loops (PLLs)
In-Reply-To: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374713022-6049-6-git-send-email-sboyd@codeaurora.org>

Add support for MSM's PLLs (phase locked loops). This is
sufficient enough to be able to determine the rate the PLL is
running at. We can add rate setting support later when it's
needed.

Cc: devicetree at vger.kernel.org
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 Documentation/devicetree/bindings/clock/msm.txt |  40 ++++
 drivers/clk/Kconfig                             |   2 +
 drivers/clk/Makefile                            |   1 +
 drivers/clk/msm/Kconfig                         |   4 +
 drivers/clk/msm/Makefile                        |   3 +
 drivers/clk/msm/clk-pll.c                       | 233 ++++++++++++++++++++++++
 drivers/clk/msm/clk-pll.h                       |  43 +++++
 7 files changed, 326 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/msm.txt
 create mode 100644 drivers/clk/msm/Kconfig
 create mode 100644 drivers/clk/msm/Makefile
 create mode 100644 drivers/clk/msm/clk-pll.c
 create mode 100644 drivers/clk/msm/clk-pll.h

diff --git a/Documentation/devicetree/bindings/clock/msm.txt b/Documentation/devicetree/bindings/clock/msm.txt
new file mode 100644
index 0000000..2192621
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/msm.txt
@@ -0,0 +1,40 @@
+Bindings for Qualcomm's clock controllers
+
+These bindings use the common clock binding
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+PLL Binding
+-----------
+
+Required properties:
+- compatible : shall be "qcom,pll".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : from common clock binding; shall be set to the reference clock
+
+Example:
+	pll8: pll8 {
+		#clock-cells = <0>;
+		compatible = "qcom,pll";
+		clocks = <&pxo>;
+	};
+
+Voteable PLL Binding
+--------------------
+
+Voteable PLLs are PLLs surrounded by a voting wrapper that aggregates
+votes from multiple masters in the system and enables or disables the
+PLL according to the current vote.
+
+Required properties:
+- compatible: shall be "qcom,pll-vote"
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : from common clock binding; shall be set to the pll that is wrapped
+  in voting logic
+
+Example:
+	vpll8: vpll8 {
+		#clock-cells = <0>;
+		compatible = "qcom,pll-vote";
+		clocks = <&pll8>;
+	};
+
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 51380d6..fad596b8 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -87,6 +87,8 @@ config CLK_PPC_CORENET
 	  This adds the clock driver support for Freescale PowerPC corenet
 	  platforms using common clock framework.
 
+source "drivers/clk/msm/Kconfig"
+
 endmenu
 
 source "drivers/clk/mvebu/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4038c2b..67df66f 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PLAT_SPEAR)	+= spear/
 obj-$(CONFIG_ARCH_U300)		+= clk-u300.o
 obj-$(CONFIG_COMMON_CLK_VERSATILE) += versatile/
 obj-$(CONFIG_ARCH_SIRF)		+= clk-prima2.o
+obj-$(CONFIG_COMMON_CLK_MSM)	+= msm/
 obj-$(CONFIG_PLAT_ORION)	+= mvebu/
 ifeq ($(CONFIG_COMMON_CLK), y)
 obj-$(CONFIG_ARCH_MMP)		+= mmp/
diff --git a/drivers/clk/msm/Kconfig b/drivers/clk/msm/Kconfig
new file mode 100644
index 0000000..bf7e3d2
--- /dev/null
+++ b/drivers/clk/msm/Kconfig
@@ -0,0 +1,4 @@
+menuconfig COMMON_CLK_MSM
+	tristate "Support for Qualcomm's MSM designs"
+	depends on OF
+
diff --git a/drivers/clk/msm/Makefile b/drivers/clk/msm/Makefile
new file mode 100644
index 0000000..16b750f
--- /dev/null
+++ b/drivers/clk/msm/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_COMMON_CLK_MSM) += clk-msm.o
+
+clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-pll.o
diff --git a/drivers/clk/msm/clk-pll.c b/drivers/clk/msm/clk-pll.c
new file mode 100644
index 0000000..03c2c41
--- /dev/null
+++ b/drivers/clk/msm/clk-pll.c
@@ -0,0 +1,233 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * 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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/clk-provider.h>
+#include <linux/slab.h>
+#include <linux/device.h>
+
+#include <asm/div64.h>
+
+#include "clk-pll.h"
+
+/**
+ * struct clk_pll - phase locked loop (PLL)
+ * @l_reg: L register
+ * @m_reg: M register
+ * @n_reg: N register
+ * @config_reg: config register
+ * @mode_reg: mode register
+ * @status_reg: status register
+ * @status_bit: ANDed with @status_reg to determine if PLL is enabled
+ * @hw: handle between common and hardware-specific interfaces
+ */
+struct clk_pll {
+	void __iomem *l_reg;
+	void __iomem *m_reg;
+	void __iomem *n_reg;
+	void __iomem *config_reg;
+	void __iomem *mode_reg;
+	void __iomem *status_reg;
+	u8 status_bit;
+
+	struct clk_hw	hw;
+};
+
+#define to_clk_pll(_hw) container_of(_hw, struct clk_pll, hw)
+
+#define PLL_OUTCTRL	BIT(0)
+#define PLL_BYPASSNL	BIT(1)
+#define PLL_RESET_N	BIT(2)
+
+static int clk_pll_enable(struct clk_hw *hw)
+{
+	struct clk_pll *pll = to_clk_pll(hw);
+	u32 mode;
+
+	mode = readl_relaxed(pll->mode_reg);
+	/* Disable PLL bypass mode. */
+	mode |= PLL_BYPASSNL;
+	writel(mode, pll->mode_reg);
+
+	/*
+	 * H/W requires a 5us delay between disabling the bypass and
+	 * de-asserting the reset. Delay 10us just to be safe.
+	 */
+	udelay(10);
+
+	/* De-assert active-low PLL reset. */
+	mode |= PLL_RESET_N;
+	writel(mode, pll->mode_reg);
+
+	/* Wait until PLL is locked. */
+	udelay(50);
+
+	/* Enable PLL output. */
+	mode |= PLL_OUTCTRL;
+	writel(mode, pll->mode_reg);
+
+	return 0;
+}
+
+static void clk_pll_disable(struct clk_hw *hw)
+{
+	struct clk_pll *pll = to_clk_pll(hw);
+	u32 mode;
+
+	mode = readl_relaxed(pll->mode_reg);
+	mode &= ~(PLL_OUTCTRL | PLL_RESET_N | PLL_BYPASSNL);
+	writel_relaxed(mode, pll->mode_reg);
+}
+
+static unsigned long
+clk_pll_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
+{
+	struct clk_pll *pll = to_clk_pll(hw);
+	u32 l, m, n;
+	unsigned long rate;
+	u64 tmp;
+
+	l = readl_relaxed(pll->l_reg) & 0x3ff;
+	m = readl_relaxed(pll->m_reg) & 0x7ffff;
+	n = readl_relaxed(pll->n_reg) & 0x7ffff;
+
+	rate = parent_rate * l;
+	if (n) {
+		tmp = parent_rate;
+		tmp *= m;
+		do_div(tmp, n);
+		rate += tmp;
+	}
+	return rate;
+}
+
+static const struct clk_ops clk_pll_ops = {
+	.enable = clk_pll_enable,
+	.disable = clk_pll_disable,
+	.recalc_rate = clk_pll_recalc_rate,
+};
+
+struct clk *pll_clk_register(struct device *dev, struct pll_desc *desc,
+		struct clk_init_data *init)
+{
+	struct clk_pll *p;
+
+	p = devm_kzalloc(dev, sizeof(*p), GFP_KERNEL);
+	if (!p)
+		return ERR_PTR(-ENOMEM);
+
+	p->l_reg = desc->base + desc->l_reg;
+	p->m_reg = desc->base + desc->m_reg;
+	p->n_reg = desc->base + desc->n_reg;
+	p->config_reg = desc->base + desc->config_reg;
+	p->mode_reg = desc->base + desc->mode_reg;
+	p->status_reg = desc->base + desc->status_reg;
+	p->status_bit = desc->status_bit;
+
+	init->ops = &clk_pll_ops;
+	p->hw.init = init;
+
+	return devm_clk_register(dev, &p->hw);
+}
+
+/**
+ * struct clk_pll_vote - phase locked loop (PLL) with hardware voting wrapper
+ * @vote_reg: Voting register
+ * @vote_bit: ORed into @vote_reg to enable PLL
+ * @hw: handle between common and hardware-specific interfaces
+ */
+struct clk_pll_vote {
+	void __iomem	*vote_reg;
+	u8		vote_bit;
+	struct clk_hw	hw;
+};
+
+#define to_clk_pll_vote(_hw) container_of(_hw, struct clk_pll_vote, hw)
+
+static DEFINE_SPINLOCK(pll_vote_lock);
+
+static int wait_for_pll(struct clk_pll *pll)
+{
+	int count;
+	const char *name = __clk_get_name(pll->hw.clk);
+
+	/* Wait for pll to enable. */
+	for (count = 200; count > 0; count--) {
+		if (readl_relaxed(pll->status_reg) & BIT(pll->status_bit))
+			return 0;
+		udelay(1);
+	}
+
+	WARN("%s didn't enable after voting for it!\n", name);
+	return -ETIMEDOUT;
+}
+
+static int clk_pll_vote_enable(struct clk_hw *hw)
+{
+	u32 val;
+	unsigned long flags;
+	struct clk_pll_vote *pll = to_clk_pll_vote(hw);
+	struct clk_pll *p = to_clk_pll(__clk_get_hw(__clk_get_parent(hw->clk)));
+
+	spin_lock_irqsave(&pll_vote_lock, flags);
+
+	val = readl_relaxed(pll->vote_reg);
+	val |= BIT(pll->vote_bit);
+	writel(val, pll->vote_reg);
+
+	spin_unlock_irqrestore(&pll_vote_lock, flags);
+
+	return wait_for_pll(p);
+}
+
+static void clk_pll_vote_disable(struct clk_hw *hw)
+{
+	u32 val;
+	unsigned long flags;
+	struct clk_pll_vote *pll = to_clk_pll_vote(hw);
+
+	spin_lock_irqsave(&pll_vote_lock, flags);
+
+	val = readl_relaxed(pll->vote_reg);
+	val &= ~BIT(pll->vote_bit);
+	writel_relaxed(val, pll->vote_reg);
+
+	spin_unlock_irqrestore(&pll_vote_lock, flags);
+}
+
+static const struct clk_ops clk_pll_vote_ops = {
+	.enable = clk_pll_vote_enable,
+	.disable = clk_pll_vote_disable,
+};
+
+struct clk *pll_vote_clk_register(struct device *dev,
+		struct pll_vote_desc *desc, struct clk_init_data *init)
+{
+	struct clk_pll_vote *p;
+
+	p = devm_kzalloc(dev, sizeof(*p), GFP_KERNEL);
+	if (!p)
+		return ERR_PTR(-ENOMEM);
+
+	p->vote_reg = desc->base + desc->vote_reg;
+	p->vote_bit = desc->vote_bit;
+
+	init->ops = &clk_pll_vote_ops;
+	p->hw.init = init;
+
+	return devm_clk_register(dev, &p->hw);
+}
diff --git a/drivers/clk/msm/clk-pll.h b/drivers/clk/msm/clk-pll.h
new file mode 100644
index 0000000..4e63a5e
--- /dev/null
+++ b/drivers/clk/msm/clk-pll.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * 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 __MSM_CLK_PLL_H__
+#define __MSM_CLK_PLL_H__
+
+struct device;
+struct clk;
+struct clk_init_data;
+
+struct pll_desc {
+	void __iomem *base;
+	u16 l_reg;
+	u16 m_reg;
+	u16 n_reg;
+	u16 config_reg;
+	u16 mode_reg;
+	u16 status_reg;
+	u8 status_bit;
+};
+
+struct pll_vote_desc {
+	void __iomem *base;
+	u16 vote_reg;
+	u8 vote_bit;
+};
+
+extern struct clk *pll_clk_register(struct device *dev, struct pll_desc *desc,
+		struct clk_init_data *init);
+extern struct clk *pll_vote_clk_register(struct device *dev,
+		struct pll_vote_desc *desc, struct clk_init_data *init);
+
+#endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 20:43:42 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:42 -0700
Subject: [PATCH v1 14/14] ARM: dts: msm: Add clock entries for MSM8960 uart
 device
In-Reply-To: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374713022-6049-15-git-send-email-sboyd@codeaurora.org>

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/boot/dts/msm8960-cdp.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/msm8960-cdp.dts b/arch/arm/boot/dts/msm8960-cdp.dts
index be8d947..e10fba6 100644
--- a/arch/arm/boot/dts/msm8960-cdp.dts
+++ b/arch/arm/boot/dts/msm8960-cdp.dts
@@ -151,6 +151,8 @@
 		reg = <0x16440000 0x1000>,
 		      <0x16400000 0x1000>;
 		interrupts = <0 154 0x0>;
+		clocks = <&gsbi5_uart_clk>, <&gsbi5_uart_ahb>;
+		clock-names = "gsbi_uart_clk", "gsbi_pclk";
 	};
 
 	qcom,ssbi at 500000 {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 20:43:39 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:39 -0700
Subject: [PATCH v1 11/14] ARM: dts: msm: Add MSM8960 GCC DT nodes
In-Reply-To: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374713022-6049-12-git-send-email-sboyd@codeaurora.org>

Add the necessary DT data to probe the global clock controller
on MSM8960 devices.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/boot/dts/msm8960-cdp.dts | 72 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

diff --git a/arch/arm/boot/dts/msm8960-cdp.dts b/arch/arm/boot/dts/msm8960-cdp.dts
index db2060c..76a1817 100644
--- a/arch/arm/boot/dts/msm8960-cdp.dts
+++ b/arch/arm/boot/dts/msm8960-cdp.dts
@@ -37,6 +37,78 @@
 		reg = <0xfd510000 0x4000>;
 	};
 
+	clock-controller at 900000 {
+		compatible = "qcom,gcc-8960", "qcom,gcc";
+		reg = <0x900000 0x4000>;
+
+		clocks {
+			cxo: cxo {
+				#clock-cells = <0>;
+				compatible = "fixed-clock";
+				clock-frequency = <19200000>;
+			};
+
+			pxo: pxo {
+				#clock-cells = <0>;
+				compatible = "fixed-clock";
+				clock-frequency = <27000000>;
+			};
+
+			pll8: pll8 {
+				#clock-cells = <0>;
+				compatible = "qcom,pll";
+				clocks = <&pxo>;
+			};
+
+			vpll8: vpll8 {
+				#clock-cells = <0>;
+				compatible = "qcom,pll-vote";
+				clocks = <&pll8>;
+			};
+
+			gsbi5_uart_rcg: gsbi5_uart_rcg {
+				#clock-cells = <0>;
+				compatible = "qcom,p2-mn16-clock";
+				clocks = <&pxo>, <&vpll8>;
+			};
+
+			gsbi5_uart_clk: gsbi5_uart_cxc {
+				#clock-cells = <0>;
+				compatible = "qcom,cxc-clock";
+				clocks = <&gsbi5_uart_rcg>;
+			};
+
+			gsbi6_uart_rcg: gsbi6_uart_rcg {
+				#clock-cells = <0>;
+				compatible = "qcom,p2-mn16-clock";
+				clocks = <&pxo>, <&vpll8>;
+			};
+
+			gsbi6_uart_clk: gsbi6_uart_cxc {
+				#clock-cells = <0>;
+				compatible = "qcom,cxc-clock";
+				clocks = <&gsbi6_uart_rcg>;
+			};
+
+			gsbi5_uart_ahb: gsbi5_uart_ahb {
+				#clock-cells = <0>;
+				compatible = "qcom,cxc-hg-clock";
+			};
+
+			gsbi5_qup_rcg: gsbi5_qup_rcg {
+				#clock-cells = <0>;
+				compatible = "qcom,p2-mn8-clock";
+				clocks = <&pxo>, <&vpll8>;
+			};
+
+			gsbi5_qup_clk: gsbi5_qup_cxc {
+				#clock-cells = <0>;
+				compatible = "qcom,cxc-clock";
+				clocks = <&gsbi5_qup_rcg>;
+			};
+		};
+	};
+
 	serial at 16440000 {
 		compatible = "qcom,msm-hsuart", "qcom,msm-uart";
 		reg = <0x16440000 0x1000>,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 20:43:40 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:40 -0700
Subject: [PATCH v1 12/14] ARM: dts: msm: Add MSM8960 MMCC DT nodes
In-Reply-To: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374713022-6049-13-git-send-email-sboyd@codeaurora.org>

Add the necessary DT data to probe the multimedia clock controller
on MSM8960 devices.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/boot/dts/msm8960-cdp.dts | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/boot/dts/msm8960-cdp.dts b/arch/arm/boot/dts/msm8960-cdp.dts
index 76a1817..be8d947 100644
--- a/arch/arm/boot/dts/msm8960-cdp.dts
+++ b/arch/arm/boot/dts/msm8960-cdp.dts
@@ -109,6 +109,43 @@
 		};
 	};
 
+	clock-controller at 4000000 {
+		compatible = "qcom,mmcc-8960", "qcom,mmcc";
+		reg = <0x4000000 0x1000>;
+
+		clocks {
+			pll2: pll2 {
+				#clock-cells = <0>;
+				compatible = "qcom,pll";
+				clocks = <&pxo>;
+			};
+
+			mdp_rcg: mdp_rcg {
+				#clock-cells = <0>;
+				compatible = "qcom,mn8-dyn-clock";
+				clocks = <&pxo>, <&pll2>, <&vpll8>;
+			};
+
+			mdp_cxc: mdp_cxc {
+				#clock-cells = <0>;
+				compatible = "qcom,cxc-clock";
+				clocks = <&mdp_rcg>;
+			};
+
+			rot_rcg: rot_rcg {
+				#clock-cells = <0>;
+				compatible = "qcom,p4-dyn-clock";
+				clocks = <&pxo>, <&pll2>, <&vpll8>;
+			};
+
+			rot_cxc: rot_cxc {
+				#clock-cells = <0>;
+				compatible = "qcom,cxc-clock";
+				clocks = <&rot_rcg>;
+			};
+		};
+	};
+
 	serial at 16440000 {
 		compatible = "qcom,msm-hsuart", "qcom,msm-uart";
 		reg = <0x16440000 0x1000>,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 20:43:30 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:30 -0700
Subject: [PATCH v1 02/14] clk: Add of_init_clk_data() to parse common clock
 bindings
In-Reply-To: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374713022-6049-3-git-send-email-sboyd@codeaurora.org>

Consolidate DT parsing for the common bits of a clock binding in
one place to simplify clock drivers. This also has the added
benefit of standardizing how the clock names used by the common
clock framework are generated from the DT bindings. We always use
the first clock-output-names string if it exists, otherwise we
fall back to the node name.

To be slightly more efficient and make the caller's life easier,
we introduce a shallow copy flag so that the clock core knows to
just copy the pointers to the strings and not the string
contents. Otherwise the callers of this function would have to
free the strings allocated here which could be cumbersome.

Cc: Rob Herring <rob.herring at calxeda.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clk.c            | 59 +++++++++++++++++++++++++++++++++++++++++++-
 include/linux/clk-provider.h |  7 ++++++
 2 files changed, 65 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 1ed9bdd..ea8e951b 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1809,6 +1809,10 @@ static int _clk_register(struct device *dev, struct clk_hw *hw, struct clk *clk)
 {
 	int i, ret;
 
+	hw->clk = clk;
+	if (hw->init->flags & CLK_SHALLOW_COPY)
+		return PTR_RET(__clk_register(dev, hw));
+
 	clk->name = kstrdup(hw->init->name, GFP_KERNEL);
 	if (!clk->name) {
 		pr_err("%s: could not allocate clk->name\n", __func__);
@@ -1819,7 +1823,6 @@ static int _clk_register(struct device *dev, struct clk_hw *hw, struct clk *clk)
 	clk->hw = hw;
 	clk->flags = hw->init->flags;
 	clk->num_parents = hw->init->num_parents;
-	hw->clk = clk;
 
 	/* allocate local copy in case parent_names is __initdata */
 	clk->parent_names = kzalloc((sizeof(char*) * clk->num_parents),
@@ -2232,4 +2235,58 @@ void __init of_clk_init(const struct of_device_id *matches)
 		clk_init_cb(np);
 	}
 }
+
+/**
+ * of_init_clk_data() - Initialize a clk_init_data struct from a DT node
+ * @np: node to initialize struct from
+ * @init: struct to initialize
+ *
+ * Populates the clk_init_data struct by parsing the device node for
+ * properties matching the common clock binding. Returns 0 on success
+ * and a negative error code on failure.
+ */
+int of_init_clk_data(struct device_node *np, struct clk_init_data *init)
+{
+	struct of_phandle_args s;
+	const char **names = NULL, **p;
+	const char *name;
+	int i;
+
+	if (of_property_read_string(np, "clock-output-names", &name) < 0)
+		name = np->name;
+	init->name = kstrdup(name, GFP_KERNEL);
+	if (!init->name)
+		return -ENOMEM;
+
+	for (i = 0; of_parse_phandle_with_args(np, "clocks", "#clock-cells",
+				i, &s) == 0; i++) {
+		p = krealloc(names, sizeof(*names) * (i + 1), GFP_KERNEL);
+		if (!p)
+			goto err;
+		names = p;
+
+		if (of_property_read_string(s.np, "clock-output-names",
+					&name) < 0)
+			name = s.np->name;
+		names[i] = kstrdup(name, GFP_KERNEL);
+		if (!names[i])
+			goto err;
+		of_node_put(s.np);
+	}
+
+	init->parent_names = names;
+	init->num_parents = i;
+	init->flags = init->num_parents ? 0 : CLK_IS_ROOT;
+	init->flags |= CLK_SHALLOW_COPY;
+
+	return 0;
+err:
+	of_node_put(s.np);
+	while (--i >= 0)
+		kfree(names[i]);
+	kfree(names);
+	kfree(init->name);
+	return -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(of_init_clk_data);
 #endif
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 9861cee..18d6362 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -28,6 +28,7 @@
 #define CLK_IS_BASIC		BIT(5) /* Basic clk, can't do a to_clk_foo() */
 #define CLK_GET_RATE_NOCACHE	BIT(6) /* do not use the cached clk rate */
 #define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate change */
+#define CLK_SHALLOW_COPY	BIT(8) /* don't copy the initdata strings */
 
 struct clk_hw;
 
@@ -472,6 +473,7 @@ struct clk *of_clk_src_onecell_get(struct of_phandle_args *clkspec, void *data);
 const char *of_clk_get_parent_name(struct device_node *np, int index);
 
 void of_clk_init(const struct of_device_id *matches);
+int of_init_clk_data(struct device_node *np, struct clk_init_data *init);
 
 #else /* !CONFIG_OF */
 
@@ -501,6 +503,11 @@ static inline const char *of_clk_get_parent_name(struct device_node *np,
 }
 #define of_clk_init(matches) \
 	{ while (0); }
+static inline int
+of_init_clk_data(struct device_node *np, struct clk_init_data *init)
+{
+	return 0;
+}
 #endif /* CONFIG_OF */
 #endif /* CONFIG_COMMON_CLK */
 #endif /* CLK_PROVIDER_H */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 20:43:41 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:41 -0700
Subject: [PATCH v1 13/14] clk: msm: Add MSM8974 GCC data
In-Reply-To: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374713022-6049-14-git-send-email-sboyd@codeaurora.org>

Add the necessary data to probe an 8974 gcc device.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 .../devicetree/bindings/clock/qcom,gcc.txt         |   1 +
 drivers/clk/msm/Kconfig                            |   7 ++
 drivers/clk/msm/Makefile                           |   1 +
 drivers/clk/msm/core.c                             |   3 +
 drivers/clk/msm/gcc-8974.c                         | 107 +++++++++++++++++++++
 drivers/clk/msm/internal.h                         |   1 +
 6 files changed, 120 insertions(+)
 create mode 100644 drivers/clk/msm/gcc-8974.c

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 2311e1a..5c7ebcf 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -7,6 +7,7 @@ Required properties :
 
 			"qcom,gcc-8660"
 			"qcom,gcc-8960"
+			"qcom,gcc-8974"
 
 - reg : shall contain base register location and length
 - clocks : shall contain clocks supplied by the clock controller
diff --git a/drivers/clk/msm/Kconfig b/drivers/clk/msm/Kconfig
index 6147380..b200554 100644
--- a/drivers/clk/msm/Kconfig
+++ b/drivers/clk/msm/Kconfig
@@ -19,4 +19,11 @@ config MSM_MMCC_8960
 	  Say Y if you want to support multimedia devices such as display,
 	  graphics, video encode/decode, camera, etc.
 
+config MSM_GCC_8974
+	bool "MSM8974 Global Clock Controller"
+	help
+	  Support for the global clock controller on msm8974 devices.
+	  Say Y if you want to use peripheral devices such as UART, SPI,
+	  i2c, USB, SD/eMMC, SATA, PCIe, etc.
+
 endif
diff --git a/drivers/clk/msm/Makefile b/drivers/clk/msm/Makefile
index ae199f5..6cd9f73 100644
--- a/drivers/clk/msm/Makefile
+++ b/drivers/clk/msm/Makefile
@@ -8,4 +8,5 @@ clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-branch.o
 clk-msm-$(CONFIG_COMMON_CLK_MSM) += core.o
 
 clk-msm-$(CONFIG_MSM_GCC_8960) += gcc-8960.o
+clk-msm-$(CONFIG_MSM_GCC_8974) += gcc-8974.o
 clk-msm-$(CONFIG_MSM_MMCC_8960) += mmcc-8960.o
diff --git a/drivers/clk/msm/core.c b/drivers/clk/msm/core.c
index 4e8b8d0..f2d0c0d 100644
--- a/drivers/clk/msm/core.c
+++ b/drivers/clk/msm/core.c
@@ -176,6 +176,9 @@ static const struct of_device_id msm_cc_match_table[] = {
 #ifdef CONFIG_MSM_GCC_8960
 	{ .compatible = "qcom,gcc-8960", .data = &msm_gcc_8960_matches },
 #endif
+#ifdef CONFIG_MSM_GCC_8974
+	{ .compatible = "qcom,gcc-8974", .data = &msm_gcc_8974_matches },
+#endif
 #ifdef CONFIG_MSM_MMCC_8960
 	{ .compatible = "qcom,mmcc-8960", .data = &msm_mmcc_8960_matches },
 #endif
diff --git a/drivers/clk/msm/gcc-8974.c b/drivers/clk/msm/gcc-8974.c
new file mode 100644
index 0000000..e88f6ad
--- /dev/null
+++ b/drivers/clk/msm/gcc-8974.c
@@ -0,0 +1,107 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * 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.
+ */
+
+#include <linux/clk-provider.h>
+
+#include "internal.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+
+static struct pll_desc gpll0 = {
+	.l_reg = 0x4,
+	.m_reg = 0x8,
+	.n_reg = 0xc,
+	.config_reg = 0x14,
+	.mode_reg = 0x0,
+	.status_reg = 0x1c,
+	.status_bit = 17,
+};
+
+static struct pll_vote_desc vgpll0 = {
+	.vote_reg = 0x1480,
+	.vote_bit = 0,
+};
+
+#define CXO	0
+#define GPLL0	1
+#define GPLL1	2
+
+static u8 gcc_cxo_gpll0_gpll1_map[] = {
+	[CXO]	= 0,
+	[GPLL0]	= 1,
+	[GPLL1]	= 2,
+};
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
+static struct freq_tbl ftbl_gcc_blsp1_2_uart1_6_apps_clk[] = {
+	F( 3686400,  GPLL0,    1,  96,  15625),
+	F( 7372800,  GPLL0,    1, 192,  15625),
+	F(14745600,  GPLL0,    1, 384,  15625),
+	F(16000000,  GPLL0,    5,   2,     15),
+	F(19200000,    CXO,    1,   0,      0),
+	F(24000000,  GPLL0,    5,   1,      5),
+	F(32000000,  GPLL0,    1,   4,     75),
+	F(40000000,  GPLL0,   15,   0,      0),
+	F(46400000,  GPLL0,    1,  29,    375),
+	F(48000000,  GPLL0, 12.5,   0,      0),
+	F(51200000,  GPLL0,    1,  32,    375),
+	F(56000000,  GPLL0,    1,   7,     75),
+	F(58982400,  GPLL0,    1, 1536, 15625),
+	F(60000000,  GPLL0,   10,   0,      0),
+	F(63160000,  GPLL0,  9.5,   0,      0),
+	{ }
+};
+
+static struct rcg2_desc blsp1_uart2_apps_rcg = {
+	.cmd_rcgr = 0x070c,
+	.parent_map = gcc_cxo_gpll0_gpll1_map,
+	.freq_tbl = ftbl_gcc_blsp1_2_uart1_6_apps_clk,
+};
+
+static struct branch_desc blsp1_uart2_apps_cxc = {
+	.ctl_reg = 0x704,
+	.halt_reg = 0x704,
+	.ctl_bit = 0,
+	.halt_bit = 31,
+	.halt_check = BRANCH_HALT,
+};
+
+static struct branch_desc blsp1_ahb_cxc = {
+	.ctl_reg = 0x1484,
+	.halt_reg = 0x5c4,
+	.ctl_bit = 17,
+	.halt_bit = 31,
+	.halt_check = BRANCH_HALT_VOTED,
+};
+
+static struct of_clk_match msm_gcc_8974_match[] = {
+	{ .name = "cxo" },
+	{ .name = "gpll0", .driver_data = &gpll0 },
+	{ .name = "vgpll0", .driver_data = &vgpll0 },
+	{
+		.name = "blsp1_uart2_apps_rcg",
+		.driver_data = &blsp1_uart2_apps_rcg,
+	},
+	{
+		.name = "blsp1_uart2_apps_cxc",
+		.driver_data = &blsp1_uart2_apps_cxc,
+	},
+	{ .name = "blsp1_ahb_cxc", .driver_data = &blsp1_ahb_cxc },
+};
+
+const struct msm_clk_match msm_gcc_8974_matches = {
+	.matches = msm_gcc_8974_match,
+	.size = ARRAY_SIZE(msm_gcc_8974_match)
+};
diff --git a/drivers/clk/msm/internal.h b/drivers/clk/msm/internal.h
index 45435a8..ae252ec 100644
--- a/drivers/clk/msm/internal.h
+++ b/drivers/clk/msm/internal.h
@@ -22,6 +22,7 @@ struct msm_clk_match {
 };
 
 extern const struct msm_clk_match msm_gcc_8960_matches;
+extern const struct msm_clk_match msm_gcc_8974_matches;
 extern const struct msm_clk_match msm_mmcc_8960_matches;
 
 #endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 20:43:38 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:38 -0700
Subject: [PATCH v1 10/14] clk: msm: Add support for MSM8960's multimedia clock
 controller (MMCC)
In-Reply-To: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374713022-6049-11-git-send-email-sboyd@codeaurora.org>

Fill in the data and wire up the multimedia clock controller to
the MSM clock driver. This should allow multimedia device drivers
to control their clocks on 8960 based platforms.

Cc: devicetree at vger.kernel.org
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 .../devicetree/bindings/clock/qcom,mmcc.txt        |  38 ++++++
 drivers/clk/msm/Kconfig                            |   8 ++
 drivers/clk/msm/Makefile                           |   1 +
 drivers/clk/msm/core.c                             |   3 +
 drivers/clk/msm/internal.h                         |   1 +
 drivers/clk/msm/mmcc-8960.c                        | 142 +++++++++++++++++++++
 6 files changed, 193 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,mmcc.txt
 create mode 100644 drivers/clk/msm/mmcc-8960.c

diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
new file mode 100644
index 0000000..e06577e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
@@ -0,0 +1,38 @@
+MSM Multimedia Clock Controller Binding
+-----------------------------------------
+
+Required properties :
+- compatible : shall contain at least "qcom,mmcc" and only one of the
+	       following:
+
+			"qcom,mmcc-8660"
+			"qcom,mmcc-8960"
+
+- reg : shall contain base register location and length
+- clocks : shall contain clocks supplied by the clock controller
+
+Example:
+	clock-controller at 4000000 {
+		compatible = "qcom,mmcc-8960", "qcom,mmcc";
+		reg = <0x4000000 0x1000>;
+
+		clocks {
+			pll2: pll2 {
+				#clock-cells = <0>;
+				compatible = "qcom,pll";
+				clocks = <&pxo>;
+			};
+
+			mdp_rcg: mdp_rcg {
+				#clock-cells = <0>;
+				compatible = "qcom,mn8-dyn-clock";
+				clocks = <&pxo>, <&pll2>, <&vpll8>;
+			};
+
+			mdp_cxc: mdp_cxc {
+				#clock-cells = <0>;
+				compatible = "qcom,cxc-clock";
+				clocks = <&mdp_rcg>;
+			};
+		};
+	};
diff --git a/drivers/clk/msm/Kconfig b/drivers/clk/msm/Kconfig
index 3eaffb6..6147380 100644
--- a/drivers/clk/msm/Kconfig
+++ b/drivers/clk/msm/Kconfig
@@ -11,4 +11,12 @@ config MSM_GCC_8960
 	  Say Y if you want to use peripheral devices such as UART, SPI,
 	  i2c, USB, SD/eMMC, SATA, PCIe, etc.
 
+config MSM_MMCC_8960
+	bool "MSM8960 Multimedia Clock Controller"
+	select MSM_GCC_8960
+	help
+	  Support for the multimedia clock controller on msm8960 devices.
+	  Say Y if you want to support multimedia devices such as display,
+	  graphics, video encode/decode, camera, etc.
+
 endif
diff --git a/drivers/clk/msm/Makefile b/drivers/clk/msm/Makefile
index c785943..ae199f5 100644
--- a/drivers/clk/msm/Makefile
+++ b/drivers/clk/msm/Makefile
@@ -8,3 +8,4 @@ clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-branch.o
 clk-msm-$(CONFIG_COMMON_CLK_MSM) += core.o
 
 clk-msm-$(CONFIG_MSM_GCC_8960) += gcc-8960.o
+clk-msm-$(CONFIG_MSM_MMCC_8960) += mmcc-8960.o
diff --git a/drivers/clk/msm/core.c b/drivers/clk/msm/core.c
index b8e702b..4e8b8d0 100644
--- a/drivers/clk/msm/core.c
+++ b/drivers/clk/msm/core.c
@@ -176,6 +176,9 @@ static const struct of_device_id msm_cc_match_table[] = {
 #ifdef CONFIG_MSM_GCC_8960
 	{ .compatible = "qcom,gcc-8960", .data = &msm_gcc_8960_matches },
 #endif
+#ifdef CONFIG_MSM_MMCC_8960
+	{ .compatible = "qcom,mmcc-8960", .data = &msm_mmcc_8960_matches },
+#endif
 	{ }
 };
 MODULE_DEVICE_TABLE(of, msm_cc_match_table);
diff --git a/drivers/clk/msm/internal.h b/drivers/clk/msm/internal.h
index b0ffda7..45435a8 100644
--- a/drivers/clk/msm/internal.h
+++ b/drivers/clk/msm/internal.h
@@ -22,5 +22,6 @@ struct msm_clk_match {
 };
 
 extern const struct msm_clk_match msm_gcc_8960_matches;
+extern const struct msm_clk_match msm_mmcc_8960_matches;
 
 #endif
diff --git a/drivers/clk/msm/mmcc-8960.c b/drivers/clk/msm/mmcc-8960.c
new file mode 100644
index 0000000..e7b7867
--- /dev/null
+++ b/drivers/clk/msm/mmcc-8960.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * 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.
+ */
+
+#include <linux/clk-provider.h>
+
+#include "internal.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+
+static struct pll_desc pll2_desc = {
+	.l_reg = 0x320,
+	.m_reg = 0x324,
+	.n_reg = 0x328,
+	.config_reg = 0x32c,
+	.mode_reg = 0x31c,
+	.status_reg = 0x334,
+	.status_bit = 16,
+};
+
+#define PXO	0
+#define PLL2	1
+#define PLL8	2
+
+static u8 mmcc_pxo_pll2_pll8_map[] = {
+	[PXO]	= 0,
+	[PLL2]	= 1,
+	[PLL8]	= 2,
+};
+
+static struct freq_tbl clk_tbl_mdp[] = {
+	{   9600000, PLL8, 0, 1, 40 },
+	{  13710000, PLL8, 0, 1, 28 },
+	{  27000000, PXO,  0, 0,  0 },
+	{  29540000, PLL8, 0, 1, 13 },
+	{  34910000, PLL8, 0, 1, 11 },
+	{  38400000, PLL8, 0, 1, 10 },
+	{  59080000, PLL8, 0, 2, 13 },
+	{  76800000, PLL8, 0, 1,  5 },
+	{  85330000, PLL8, 0, 2,  9 },
+	{  96000000, PLL8, 0, 1,  4 },
+	{ 128000000, PLL8, 0, 1,  3 },
+	{ 160000000, PLL2, 0, 1,  5 },
+	{ 177780000, PLL2, 0, 2,  9 },
+	{ 200000000, PLL2, 0, 1,  4 },
+	{ 228571000, PLL2, 0, 2,  7 },
+	{ 266667000, PLL2, 0, 1,  3 },
+	{ }
+};
+
+static struct rcg_dyn_desc mdp_rcg = {
+	.ctl_reg = 0xc0,
+	.ns_reg = 0xd0,
+	.md0_reg = 0xc4,
+	.md1_reg = 0xc8,
+	.ctl_bit = 2,
+	.mnctr0_en_bit = 8,
+	.mnctr1_en_bit = 5,
+	.mnctr0_reset_bit = 31,
+	.mnctr1_reset_bit = 30,
+	.mnctr0_mode_shift = 9,
+	.mnctr1_mode_shift = 6,
+	.src0_sel_shift = 3,
+	.src1_sel_shift = 0,
+	.n0_val_shift = 22,
+	.n1_val_shift = 14,
+	.m0_val_shift = 8,
+	.m1_val_shift = 8,
+	.mux_sel_bit = 11,
+	.parent_map = mmcc_pxo_pll2_pll8_map,
+	.freq_tbl = clk_tbl_mdp,
+};
+
+static struct branch_desc mdp_cxc = {
+	.ctl_reg = 0xc0,
+	.halt_reg = 0x1d0,
+	.ctl_bit = 0,
+	.halt_bit = 10,
+	.halt_check = BRANCH_HALT,
+};
+
+static struct freq_tbl clk_tbl_rot[] = {
+	{  27000000, PXO,   1 },
+	{  29540000, PLL8, 13 },
+	{  32000000, PLL8, 12 },
+	{  38400000, PLL8, 10 },
+	{  48000000, PLL8,  8 },
+	{  54860000, PLL8,  7 },
+	{  64000000, PLL8,  6 },
+	{  76800000, PLL8,  5 },
+	{  96000000, PLL8,  4 },
+	{ 100000000, PLL2,  8 },
+	{ 114290000, PLL2,  7 },
+	{ 133330000, PLL2,  6 },
+	{ 160000000, PLL2,  5 },
+	{ 200000000, PLL2,  4 },
+	{ }
+};
+
+static struct rcg_dyn_desc rot_rcg = {
+	.ctl_reg = 0xe0,
+	.ns_reg = 0xe8,
+	.ctl_bit = 2,
+	.pre_div0_shift = 22,
+	.pre_div1_shift = 26,
+	.src0_sel_shift = 16,
+	.src1_sel_shift = 19,
+	.mux_sel_bit = 30,
+	.parent_map = mmcc_pxo_pll2_pll8_map,
+	.freq_tbl = clk_tbl_rot,
+};
+
+static struct branch_desc rot_cxc = {
+	.ctl_reg = 0xe0,
+	.halt_reg = 0x1d0,
+	.ctl_bit = 0,
+	.halt_bit = 15,
+	.halt_check = BRANCH_HALT,
+};
+
+static struct of_clk_match msm_mmcc_clk_match[] = {
+	{ .name = "pll2", .driver_data = &pll2_desc },
+	{ .name = "mdp_rcg", .driver_data = &mdp_rcg },
+	{ .name = "mdp_cxc", .driver_data = &mdp_cxc },
+	{ .name = "rot_rcg", .driver_data = &rot_rcg },
+	{ .name = "rot_cxc", .driver_data = &rot_cxc },
+};
+
+const struct msm_clk_match msm_mmcc_8960_matches = {
+	.matches = msm_mmcc_clk_match,
+	.size = ARRAY_SIZE(msm_mmcc_clk_match)
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 20:43:35 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:35 -0700
Subject: [PATCH v1 07/14] clk: msm: Add support for branches/gate clocks
In-Reply-To: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374713022-6049-8-git-send-email-sboyd@codeaurora.org>

Cc: devicetree at vger.kernel.org
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 Documentation/devicetree/bindings/clock/msm.txt |  28 ++++
 drivers/clk/msm/Makefile                        |   1 +
 drivers/clk/msm/clk-branch.c                    | 190 ++++++++++++++++++++++++
 drivers/clk/msm/clk-branch.h                    |  48 ++++++
 4 files changed, 267 insertions(+)
 create mode 100644 drivers/clk/msm/clk-branch.c
 create mode 100644 drivers/clk/msm/clk-branch.h

diff --git a/Documentation/devicetree/bindings/clock/msm.txt b/Documentation/devicetree/bindings/clock/msm.txt
index f4595fa..6840398 100644
--- a/Documentation/devicetree/bindings/clock/msm.txt
+++ b/Documentation/devicetree/bindings/clock/msm.txt
@@ -69,3 +69,31 @@ Example:
 		clocks = <&pxo>, <&pll2>, <&pll8>;
 	};
 
+CXC Binding
+-----------
+
+Required properties:
+- compatible : shall be "qcom,cxc-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : from common clock binding; shall be set to the source being gated
+
+Example:
+	gsbi5_uart_clk: gsbi5_uart_cxc {
+		#clock-cells = <0>;
+		compatible = "qcom,cxc-clock";
+		clocks = <&gsbi5_uart_rcg>;
+	};
+
+CXC With Hardware Gating Binding
+--------------------------------
+
+Required properties:
+- compatible : shall be "qcom,cxc-hg-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : from common clock binding; shall be set to the source being gated
+
+	gsbi5_uart_ahb: gsbi5_uart_ahb {
+		#clock-cells = <0>;
+		compatible = "qcom,cxc-hg-clock";
+		clocks = <&cfpb_clk>;
+	};
diff --git a/drivers/clk/msm/Makefile b/drivers/clk/msm/Makefile
index fb78ac9..e1cee29 100644
--- a/drivers/clk/msm/Makefile
+++ b/drivers/clk/msm/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_COMMON_CLK_MSM) += clk-msm.o
 clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-pll.o
 clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-rcg.o
 clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-rcg2.o
+clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-branch.o
diff --git a/drivers/clk/msm/clk-branch.c b/drivers/clk/msm/clk-branch.c
new file mode 100644
index 0000000..ff2e599
--- /dev/null
+++ b/drivers/clk/msm/clk-branch.c
@@ -0,0 +1,190 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * 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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/clk-provider.h>
+#include <linux/slab.h>
+#include <linux/device.h>
+
+#include "clk-branch.h"
+
+/**
+ * struct clk_branch - gating clock with status bit and dynamic hardware gating
+ *
+ * @ctl_reg: clock control register
+ * @ctl_bit: ORed with @ctl_reg to enable the clock
+ * @hwcg_reg: dynamic hardware clock gating register
+ * @hwcg_bit: ORed with @hwcg_reg to enable dynamic hardware clock gating
+ * @halt_reg: halt register
+ * @halt_bit: ANDed with @halt_reg to test for clock halted
+ * @halt_check: type of halt checking to perform
+ * @hw: handle between common and hardware-specific interfaces
+ * @lock: register lock
+ *
+ * Clock which can gate its output.
+ */
+struct clk_branch {
+	void __iomem	*ctl_reg;
+	void __iomem	*hwcg_reg;
+	void __iomem	*halt_reg;
+
+	u8		ctl_bit;
+	u8		hwcg_bit;
+	u8		halt_bit;
+	u8		halt_check;
+
+	struct clk_hw	hw;
+	spinlock_t	*lock;
+};
+
+#define to_clk_branch(_hw) container_of(_hw, struct clk_branch, hw)
+
+static bool clk_branch_is_halted(const struct clk_branch *br)
+{
+	bool invert = (br->halt_check == BRANCH_HALT_ENABLE);
+	u32 status_bit = readl_relaxed(br->halt_reg) & BIT(br->halt_bit);
+	return invert ? !status_bit : status_bit;
+}
+
+static bool clk_branch_in_hwcg_mode(const struct clk_branch *br)
+{
+	if (!br->hwcg_reg)
+		return 0;
+
+	return !!(readl_relaxed(br->hwcg_reg) & BIT(br->hwcg_bit));
+}
+
+static int clk_branch_wait(const struct clk_branch *br, bool enabling)
+{
+	bool voted = br->halt_check & BRANCH_VOTED;
+	const char *name = __clk_get_name(br->hw.clk);
+
+	/* Skip checking halt bit if the clock is in hardware gated mode */
+	if (clk_branch_in_hwcg_mode(br))
+		return 0;
+
+	if (br->halt_check == BRANCH_HALT_DELAY || (!enabling && voted)) {
+		udelay(10);
+	} else if (br->halt_check == BRANCH_HALT_ENABLE ||
+		   br->halt_check == BRANCH_HALT ||
+		   (enabling && voted)) {
+		int count = 200;
+
+		while (count-- > 0) {
+			if (clk_branch_is_halted(br) == !enabling)
+				return 0;
+			udelay(1);
+		}
+		WARN("%s status stuck at 'o%s'", name, enabling ? "ff" : "n");
+		return -EBUSY;
+	}
+	return 0;
+}
+
+static int clk_branch_toggle(const struct clk_hw *hw, bool en)
+{
+	struct clk_branch *br = to_clk_branch(hw);
+	unsigned long flags;
+	u32 val;
+
+	spin_lock_irqsave(br->lock, flags);
+
+	val = readl_relaxed(br->ctl_reg);
+	if (en)
+		val |= BIT(br->ctl_bit);
+	else
+		val &= ~BIT(br->ctl_bit);
+	writel(val, br->ctl_reg);
+
+	spin_unlock_irqrestore(br->lock, flags);
+
+	return clk_branch_wait(br, en);
+}
+
+static int clk_branch_enable(struct clk_hw *hw)
+{
+	return clk_branch_toggle(hw, true);
+}
+
+static void clk_branch_disable(struct clk_hw *hw)
+{
+	clk_branch_toggle(hw, false);
+}
+
+static int clk_branch_is_enabled(struct clk_hw *hw)
+{
+	struct clk_branch *br = to_clk_branch(hw);
+	u32 val;
+
+	val = readl_relaxed(br->ctl_reg);
+	val &= BIT(br->ctl_bit);
+
+	return val ? 1 : 0;
+}
+
+static const struct clk_ops clk_branch_ops = {
+	.enable = clk_branch_enable,
+	.is_enabled = clk_branch_is_enabled,
+	.disable = clk_branch_disable,
+};
+
+struct clk *branch_clk_register(struct device *dev, struct branch_desc *desc,
+		spinlock_t *lock, struct clk_init_data *init)
+{
+	struct clk_branch *b;
+
+	b = devm_kzalloc(dev, sizeof(*b), GFP_KERNEL);
+	if (!b)
+		return ERR_PTR(-ENOMEM);
+
+	b->ctl_reg = desc->base + desc->ctl_reg;
+	b->halt_reg = desc->base + desc->halt_reg;
+	b->ctl_bit = desc->ctl_bit;
+	b->halt_bit = desc->halt_bit;
+	b->halt_check = desc->halt_check;
+	b->lock = lock;
+
+	init->ops = &clk_branch_ops;
+	init->flags |= CLK_SET_RATE_PARENT;
+	b->hw.init = init;
+
+	return devm_clk_register(dev, &b->hw);
+}
+
+struct clk *branch_hg_clk_register(struct device *dev, struct branch_desc *desc,
+		spinlock_t *lock, struct clk_init_data *init)
+{
+	struct clk_branch *b;
+
+	b = devm_kzalloc(dev, sizeof(*b), GFP_KERNEL);
+	if (!b)
+		return ERR_PTR(-ENOMEM);
+
+	b->ctl_reg = desc->base + desc->ctl_reg;
+	b->halt_reg = desc->base + desc->halt_reg;
+	b->hwcg_reg = desc->base + desc->hwcg_reg;
+	b->ctl_bit = desc->ctl_bit;
+	b->halt_bit = desc->halt_bit;
+	b->halt_check = desc->halt_check;
+	b->lock = lock;
+
+	init->ops = &clk_branch_ops;
+	init->flags |= CLK_SET_RATE_PARENT;
+	b->hw.init = init;
+
+	return devm_clk_register(dev, &b->hw);
+}
diff --git a/drivers/clk/msm/clk-branch.h b/drivers/clk/msm/clk-branch.h
new file mode 100644
index 0000000..bcb7345
--- /dev/null
+++ b/drivers/clk/msm/clk-branch.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * 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 __MSM_CLK_BRANCH_H__
+#define __MSM_CLK_BRANCH_H__
+
+#include <linux/spinlock.h>
+
+struct device;
+struct clk;
+struct clk_init_data;
+
+struct branch_desc {
+	void __iomem *base;
+	u32 ctl_reg;
+	u32 hwcg_reg;
+	u32 halt_reg;
+
+	u8 ctl_bit;
+	u8 hwcg_bit;
+	u8 halt_bit;
+	u8 halt_check;
+#define BRANCH_VOTED			BIT(7) /* Delay on disable */
+#define BRANCH_HALT			0 /* pol: 1 = halt */
+#define BRANCH_HALT_VOTED		(BRANCH_HALT | BRANCH_VOTED)
+#define BRANCH_HALT_ENABLE		1 /* pol: 0 = halt */
+#define BRANCH_HALT_ENABLE_VOTED	(BRANCH_HALT_ENABLE | BRANCH_VOTED)
+#define BRANCH_HALT_DELAY		2 /* No bit to check; just delay */
+};
+
+extern struct clk *branch_clk_register(struct device *dev,
+		struct branch_desc *desc, spinlock_t *lock,
+		struct clk_init_data *init);
+extern struct clk *branch_hg_clk_register(struct device *dev,
+		struct branch_desc *desc, spinlock_t *lock,
+		struct clk_init_data *init);
+
+#endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 20:43:36 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:36 -0700
Subject: [PATCH v1 08/14] clk: msm: Add MSM clock driver
In-Reply-To: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374713022-6049-9-git-send-email-sboyd@codeaurora.org>

Add a clock driver that registers clocks from a DT node's
'clocks' child. Each new SoC will add a file describing the
software interface and frequency plan to drivers/clk/msm/ and
then hook that into the msm_cc_match_table by means of a
compatible string and an msm_clk_match table.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/msm/Makefile   |   2 +
 drivers/clk/msm/core.c     | 265 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/clk/msm/internal.h |  24 ++++
 3 files changed, 291 insertions(+)
 create mode 100644 drivers/clk/msm/core.c
 create mode 100644 drivers/clk/msm/internal.h

diff --git a/drivers/clk/msm/Makefile b/drivers/clk/msm/Makefile
index e1cee29..9cfd0d7 100644
--- a/drivers/clk/msm/Makefile
+++ b/drivers/clk/msm/Makefile
@@ -4,3 +4,5 @@ clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-pll.o
 clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-rcg.o
 clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-rcg2.o
 clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-branch.o
+
+clk-msm-$(CONFIG_COMMON_CLK_MSM) += core.o
diff --git a/drivers/clk/msm/core.c b/drivers/clk/msm/core.c
new file mode 100644
index 0000000..b1904c0
--- /dev/null
+++ b/drivers/clk/msm/core.c
@@ -0,0 +1,265 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * 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.
+ */
+
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/spinlock.h>
+
+#include "internal.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+
+struct cc_data {
+	void __iomem *base;
+	spinlock_t lock;
+};
+
+static struct clk *
+dispatch_fixed_clk(struct of_clk_match *m, struct device *dev,
+		struct cc_data *cc)
+{
+	u32 rate;
+	const char *name = m->init_data->name;
+
+	if (of_property_read_u32(m->of_node, "clock-frequency", &rate))
+		return ERR_PTR(-EINVAL);
+
+	return clk_register_fixed_rate(dev, name, NULL, CLK_IS_ROOT, rate);
+}
+
+static struct clk *
+dispatch_pll_clk(struct of_clk_match *m, struct device *dev,
+		struct cc_data *cc)
+{
+	struct pll_desc *desc = m->driver_data;
+
+	desc->base = cc->base;
+
+	return pll_clk_register(dev, desc, m->init_data);
+}
+
+static struct clk *
+dispatch_pll_vote_clk(struct of_clk_match *m, struct device *dev,
+		struct cc_data *cc)
+{
+	struct pll_vote_desc *desc = m->driver_data;
+
+	desc->base = cc->base;
+
+	return pll_vote_clk_register(dev, desc, m->init_data);
+}
+
+static struct clk *
+dispatch_rcg_p2mn16_clk(struct of_clk_match *m, struct device *dev,
+		struct cc_data *cc)
+{
+	struct rcg_desc *desc = m->driver_data;
+
+	desc->base = cc->base;
+
+	return rcg_p2mn16_clk_register(dev, desc, &cc->lock, m->init_data);
+}
+
+static struct clk *
+dispatch_rcg_p2mn8_clk(struct of_clk_match *m, struct device *dev,
+		struct cc_data *cc)
+{
+	struct rcg_desc *desc = m->driver_data;
+
+	desc->base = cc->base;
+
+	return rcg_p2mn8_clk_register(dev, desc, &cc->lock, m->init_data);
+}
+
+static struct clk *
+dispatch_rcg_mn8_dyn_clk(struct of_clk_match *match, struct device *dev,
+		struct cc_data *cc)
+{
+	struct rcg_dyn_desc *desc = match->driver_data;
+
+	desc->base = cc->base;
+
+	return rcg_mn8_dyn_clk_register(dev, desc, &cc->lock,
+			match->init_data);
+}
+
+static struct clk *
+dispatch_rcg_p4_dyn_clk(struct of_clk_match *match, struct device *dev,
+		struct cc_data *cc)
+{
+	struct rcg_dyn_desc *desc = match->driver_data;
+
+	desc->base = cc->base;
+
+	return rcg_p4_dyn_clk_register(dev, desc, &cc->lock,
+			match->init_data);
+}
+
+static struct clk *
+dispatch_rcg_h5mn8_clk(struct of_clk_match *match, struct device *dev,
+		struct cc_data *cc)
+{
+	struct rcg2_desc *desc = match->driver_data;
+
+	desc->base = cc->base;
+
+	return rcg_h5mn8_clk_register(dev, desc, &cc->lock, match->init_data);
+}
+
+static struct clk *
+dispatch_rcg_h5mn16_clk(struct of_clk_match *match, struct device *dev,
+		struct cc_data *cc)
+{
+	struct rcg2_desc *desc = match->driver_data;
+
+	desc->base = cc->base;
+
+	return rcg_h5mn16_clk_register(dev, desc, &cc->lock, match->init_data);
+}
+
+static struct clk *
+dispatch_branch_clk(struct of_clk_match *m, struct device *dev,
+		struct cc_data *cc)
+{
+	struct branch_desc *desc = m->driver_data;
+
+	desc->base = cc->base;
+
+	return branch_clk_register(dev, desc, &cc->lock, m->init_data);
+}
+
+static struct clk *
+dispatch_branch_hg_clk(struct of_clk_match *m, struct device *dev,
+		struct cc_data *cc)
+{
+	struct branch_desc *desc = m->driver_data;
+
+	desc->base = cc->base;
+
+	return branch_hg_clk_register(dev, desc, &cc->lock, m->init_data);
+}
+
+static const struct of_device_id dispatch_table[] = {
+	{ .compatible = "fixed-clock", .data = dispatch_fixed_clk },
+	{ .compatible = "qcom,pll", .data = dispatch_pll_clk },
+	{ .compatible = "qcom,pll-vote", .data = dispatch_pll_vote_clk },
+	{ .compatible = "qcom,p2-mn8-clock", .data = dispatch_rcg_p2mn8_clk },
+	{ .compatible = "qcom,p2-mn16-clock", .data = dispatch_rcg_p2mn16_clk },
+	{ .compatible = "qcom,mn8-dyn-clock", .data = dispatch_rcg_mn8_dyn_clk },
+	{ .compatible = "qcom,p4-dyn-clock", .data = dispatch_rcg_p4_dyn_clk },
+	{ .compatible = "qcom,h5-mn8-clock", .data = dispatch_rcg_h5mn8_clk },
+	{ .compatible = "qcom,h5-mn16-clock", .data = dispatch_rcg_h5mn16_clk },
+	{ .compatible = "qcom,cxc-clock", .data = dispatch_branch_clk },
+	{ .compatible = "qcom,cxc-hg-clock", .data = dispatch_branch_hg_clk },
+};
+
+typedef struct clk *
+(*clk_dispatch_fn)(struct of_clk_match *m, struct device *dev,
+		struct cc_data *cc);
+
+static const struct of_device_id msm_cc_match_table[] = {
+	{ }
+};
+MODULE_DEVICE_TABLE(of, msm_cc_match_table);
+
+static int msm_cc_probe(struct platform_device *pdev)
+{
+	struct cc_data *cc;
+	void __iomem *base;
+	struct resource *res;
+	int count, i;
+	const struct of_device_id *id_entry;
+	const struct msm_clk_match *m;
+	struct of_clk_match *matches;
+	size_t size;
+
+	id_entry = of_match_device(msm_cc_match_table, &pdev->dev);
+	m = id_entry->data;
+	matches = m->matches;
+	size = m->size;
+
+	cc = devm_kzalloc(&pdev->dev, sizeof(*cc), GFP_KERNEL);
+	if (!cc)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	cc->base = base;
+	spin_lock_init(&cc->lock);
+
+	count = of_clk_match(&pdev->dev, matches, size);
+	if (count < 0)
+		return count;
+
+	for (i = 0; i < size; i++) {
+		struct of_clk_match *match;
+		const struct of_device_id *id;
+		struct device_node *np;
+		clk_dispatch_fn fn;
+		struct clk *clk;
+		int err;
+
+		match = &matches[i];
+		np = match->of_node;
+		if (!np)
+			continue;
+
+		id = of_match_node(dispatch_table, match->of_node);
+		if (!id)
+			continue;
+
+		fn = id->data;
+		clk = fn(match, &pdev->dev, cc);
+		if (IS_ERR(clk))
+			return PTR_ERR(clk);
+
+		err = of_clk_add_provider(np, of_clk_src_simple_get, clk);
+		if (err)
+			return err;
+	}
+
+	return 0;
+}
+
+static struct platform_driver msm_cc_driver = {
+	.probe		= msm_cc_probe,
+	.driver		= {
+		.name	= "msm-clock",
+		.owner	= THIS_MODULE,
+		.of_match_table = msm_cc_match_table,
+	},
+};
+
+static int __init msm_cc_init(void)
+{
+	return platform_driver_register(&msm_cc_driver);
+}
+core_initcall(msm_cc_init);
+
+static void __exit msm_cc_exit(void)
+{
+	platform_driver_unregister(&msm_cc_driver);
+}
+module_exit(msm_cc_exit);
+
+MODULE_DESCRIPTION("MSM Clock Driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:msm-cc");
diff --git a/drivers/clk/msm/internal.h b/drivers/clk/msm/internal.h
new file mode 100644
index 0000000..177bd3b
--- /dev/null
+++ b/drivers/clk/msm/internal.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * 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 __MSM_CLK_INTERNAL_H__
+#define __MSM_CLK_INTERNAL_H__
+
+struct of_clk_match;
+
+struct msm_clk_match {
+	struct of_clk_match *matches;
+	size_t size;
+};
+
+#endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 20:43:37 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:37 -0700
Subject: [PATCH v1 09/14] clk: msm: Add support for MSM8960's global clock
 controller (GCC)
In-Reply-To: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374713022-6049-10-git-send-email-sboyd@codeaurora.org>

Fill in the data and wire up the global clock controller to the
MSM clock driver. This should allow most non-multimedia device
drivers to control their clocks on 8960 based platforms.

Cc: devicetree at vger.kernel.org
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 .../devicetree/bindings/clock/qcom,gcc.txt         |  55 +++++++
 drivers/clk/msm/Kconfig                            |  10 ++
 drivers/clk/msm/Makefile                           |   2 +
 drivers/clk/msm/core.c                             |   3 +
 drivers/clk/msm/gcc-8960.c                         | 174 +++++++++++++++++++++
 drivers/clk/msm/internal.h                         |   2 +
 6 files changed, 246 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/qcom,gcc.txt
 create mode 100644 drivers/clk/msm/gcc-8960.c

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
new file mode 100644
index 0000000..2311e1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -0,0 +1,55 @@
+MSM Global Clock Controller Binding
+-----------------------------------
+
+Required properties :
+- compatible : shall contain at least "qcom,gcc" and only one of the
+	       following:
+
+			"qcom,gcc-8660"
+			"qcom,gcc-8960"
+
+- reg : shall contain base register location and length
+- clocks : shall contain clocks supplied by the clock controller
+
+Example:
+	clock-controller at 900000 {
+		compatible = "qcom,gcc-8960", "qcom,gcc";
+		reg = <0x900000 0x4000>;
+
+		clocks {
+			pxo: pxo {
+				#clock-cells = <0>;
+				compatible = "fixed-clock";
+				clock-frequency = <27000000>;
+			};
+
+			pll8: pll8 {
+				#clock-cells = <0>;
+				compatible = "qcom,pll";
+				clocks = <&pxo>;
+			};
+
+			vpll8: vpll8 {
+				#clock-cells = <0>;
+				compatible = "qcom,pll-vote";
+				clocks = <&pll8>;
+			};
+
+			gsbi5_uart_rcg: gsbi5_uart_rcg {
+				#clock-cells = <0>;
+				compatible = "qcom,p2-mn16-clock";
+				clocks = <&pxo>, <&vpll8>;
+			};
+
+			gsbi5_uart_clk: gsbi5_uart_cxc {
+				#clock-cells = <0>;
+				compatible = "qcom,cxc-clock";
+				clocks = <&gsbi5_uart_rcg>;
+			};
+
+			gsbi5_uart_ahb: gsbi5_uart_ahb {
+				#clock-cells = <0>;
+				compatible = "qcom,cxc-hg-clock";
+			};
+		};
+	};
diff --git a/drivers/clk/msm/Kconfig b/drivers/clk/msm/Kconfig
index bf7e3d2..3eaffb6 100644
--- a/drivers/clk/msm/Kconfig
+++ b/drivers/clk/msm/Kconfig
@@ -2,3 +2,13 @@ menuconfig COMMON_CLK_MSM
 	tristate "Support for Qualcomm's MSM designs"
 	depends on OF
 
+if COMMON_CLK_MSM
+
+config MSM_GCC_8960
+	bool "MSM8960 Global Clock Controller"
+	help
+	  Support for the global clock controller on msm8960 devices.
+	  Say Y if you want to use peripheral devices such as UART, SPI,
+	  i2c, USB, SD/eMMC, SATA, PCIe, etc.
+
+endif
diff --git a/drivers/clk/msm/Makefile b/drivers/clk/msm/Makefile
index 9cfd0d7..c785943 100644
--- a/drivers/clk/msm/Makefile
+++ b/drivers/clk/msm/Makefile
@@ -6,3 +6,5 @@ clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-rcg2.o
 clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-branch.o
 
 clk-msm-$(CONFIG_COMMON_CLK_MSM) += core.o
+
+clk-msm-$(CONFIG_MSM_GCC_8960) += gcc-8960.o
diff --git a/drivers/clk/msm/core.c b/drivers/clk/msm/core.c
index b1904c0..b8e702b 100644
--- a/drivers/clk/msm/core.c
+++ b/drivers/clk/msm/core.c
@@ -173,6 +173,9 @@ typedef struct clk *
 		struct cc_data *cc);
 
 static const struct of_device_id msm_cc_match_table[] = {
+#ifdef CONFIG_MSM_GCC_8960
+	{ .compatible = "qcom,gcc-8960", .data = &msm_gcc_8960_matches },
+#endif
 	{ }
 };
 MODULE_DEVICE_TABLE(of, msm_cc_match_table);
diff --git a/drivers/clk/msm/gcc-8960.c b/drivers/clk/msm/gcc-8960.c
new file mode 100644
index 0000000..b57d2dd
--- /dev/null
+++ b/drivers/clk/msm/gcc-8960.c
@@ -0,0 +1,174 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * 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.
+ */
+
+#include <linux/clk-provider.h>
+
+#include "internal.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+
+static struct pll_desc pll8_desc = {
+	.l_reg = 0x3144,
+	.m_reg = 0x3148,
+	.n_reg = 0x314c,
+	.config_reg = 0x3154,
+	.mode_reg = 0x3140,
+	.status_reg = 0x3158,
+	.status_bit = 16,
+};
+
+static struct pll_vote_desc pll8_vote_desc = {
+	.vote_reg = 0x34c0,
+	.vote_bit = 8,
+};
+
+#define PXO	0
+#define PLL8	1
+
+static u8 gcc_pxo_pll8_map[] = {
+	[PXO]	= 0,
+	[PLL8]	= 3,
+};
+
+static struct freq_tbl clk_tbl_gsbi_uart[] = {
+	{  1843200, PLL8, 2,  6, 625 },
+	{  3686400, PLL8, 2, 12, 625 },
+	{  7372800, PLL8, 2, 24, 625 },
+	{ 14745600, PLL8, 2, 48, 625 },
+	{ 16000000, PLL8, 4,  1,   6 },
+	{ 24000000, PLL8, 4,  1,   4 },
+	{ 32000000, PLL8, 4,  1,   3 },
+	{ 40000000, PLL8, 1,  5,  48 },
+	{ 46400000, PLL8, 1, 29, 240 },
+	{ 48000000, PLL8, 4,  1,   2 },
+	{ 51200000, PLL8, 1,  2,  15 },
+	{ 56000000, PLL8, 1,  7,  48 },
+	{ 58982400, PLL8, 1, 96, 625 },
+	{ 64000000, PLL8, 2,  1,   3 },
+	{ }
+};
+
+static struct rcg_desc gsbi5_uart_rcg = {
+	.ctl_reg = 0x2a54,
+	.ns_reg = 0x2a54,
+	.md_reg = 0x2a50,
+	.ctl_bit = 11,
+	.mnctr_en_bit = 8,
+	.mnctr_reset_bit = 7,
+	.mnctr_mode_shift = 5,
+	.pre_div_shift = 3,
+	.src_sel_shift = 0,
+	.n_val_shift = 16,
+	.m_val_shift = 16,
+	.parent_map = gcc_pxo_pll8_map,
+	.freq_tbl = clk_tbl_gsbi_uart,
+};
+
+static struct branch_desc gsbi5_uart_cxc = {
+	.ctl_reg = 0x2a54,
+	.halt_reg = 0x2fd0,
+	.ctl_bit = 9,
+	.halt_bit = 22,
+	.halt_check = BRANCH_HALT,
+};
+
+static struct rcg_desc gsbi6_uart_rcg = {
+	.ctl_reg = 0x2a74,
+	.ns_reg = 0x2a74,
+	.md_reg = 0x2a70,
+	.ctl_bit = 11,
+	.mnctr_en_bit = 8,
+	.mnctr_reset_bit = 7,
+	.mnctr_mode_shift = 5,
+	.pre_div_shift = 3,
+	.src_sel_shift = 0,
+	.n_val_shift = 16,
+	.m_val_shift = 16,
+	.parent_map = gcc_pxo_pll8_map,
+	.freq_tbl = clk_tbl_gsbi_uart,
+};
+
+static struct branch_desc gsbi6_uart_cxc = {
+	.ctl_reg = 0x2a74,
+	.halt_reg = 0x2fd0,
+	.ctl_bit = 9,
+	.halt_bit = 18,
+	.halt_check = BRANCH_HALT,
+};
+
+static struct branch_desc gsbi5_uart_ahb = {
+	.ctl_reg = 0x2a40,
+	.halt_reg = 0x2fd0,
+	.hwcg_reg = 0x2a40,
+	.ctl_bit = 4,
+	.hwcg_bit = 6,
+	.halt_bit = 23,
+	.halt_check = BRANCH_HALT,
+};
+
+static struct freq_tbl clk_tbl_gsbi_qup[] = {
+	{  1100000, PXO,  1, 2, 49 },
+	{  5400000, PXO,  1, 1,  5 },
+	{ 10800000, PXO,  1, 2,  5 },
+	{ 15060000, PLL8, 1, 2, 51 },
+	{ 24000000, PLL8, 4, 1,  4 },
+	{ 25600000, PLL8, 1, 1, 15 },
+	{ 27000000, PXO,  1, 0,  0 },
+	{ 48000000, PLL8, 4, 1,  2 },
+	{ 51200000, PLL8, 1, 2, 15 },
+	{ }
+};
+
+static struct rcg_desc gsbi5_qup_rcg = {
+	.ctl_reg = 0x2a4c,
+	.ns_reg = 0x2a4c,
+	.md_reg = 0x2a48,
+	.ctl_bit = 11,
+	.mnctr_en_bit = 8,
+	.mnctr_reset_bit = 7,
+	.mnctr_mode_shift = 5,
+	.pre_div_shift = 3,
+	.src_sel_shift = 0,
+	.n_val_shift = 16,
+	.m_val_shift = 16,
+	.parent_map = gcc_pxo_pll8_map,
+	.freq_tbl = clk_tbl_gsbi_qup,
+};
+
+static struct branch_desc gsbi5_qup_cxc = {
+	.ctl_reg = 0x2a4c,
+	.halt_reg = 0x2fd0,
+	.ctl_bit = 9,
+	.halt_bit = 20,
+	.halt_check = BRANCH_HALT,
+};
+
+static struct of_clk_match msm_gcc_clk_match[] = {
+	{ .name = "cxo" },
+	{ .name = "pxo" },
+	{ .name = "pll8", .driver_data = &pll8_desc },
+	{ .name = "vpll8", .driver_data = &pll8_vote_desc },
+	{ .name = "gsbi5_uart_rcg", .driver_data = &gsbi5_uart_rcg },
+	{ .name = "gsbi5_uart_cxc", .driver_data = &gsbi5_uart_cxc },
+	{ .name = "gsbi6_uart_rcg", .driver_data = &gsbi6_uart_rcg },
+	{ .name = "gsbi6_uart_cxc", .driver_data = &gsbi6_uart_cxc },
+	{ .name = "gsbi5_uart_ahb", .driver_data = &gsbi5_uart_ahb },
+	{ .name = "gsbi5_qup_rcg", .driver_data = &gsbi5_qup_rcg },
+	{ .name = "gsbi5_qup_cxc", .driver_data = &gsbi5_qup_cxc },
+};
+
+const struct msm_clk_match msm_gcc_8960_matches = {
+	.matches = msm_gcc_clk_match,
+	.size = ARRAY_SIZE(msm_gcc_clk_match)
+};
diff --git a/drivers/clk/msm/internal.h b/drivers/clk/msm/internal.h
index 177bd3b..b0ffda7 100644
--- a/drivers/clk/msm/internal.h
+++ b/drivers/clk/msm/internal.h
@@ -21,4 +21,6 @@ struct msm_clk_match {
 	size_t size;
 };
 
+extern const struct msm_clk_match msm_gcc_8960_matches;
+
 #endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 24 20:43:34 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Jul 2013 17:43:34 -0700
Subject: [PATCH v1 06/14] clk: msm: Add support for root clock generators
 (RCGs)
In-Reply-To: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1374713022-6049-7-git-send-email-sboyd@codeaurora.org>

Cc: devicetree at vger.kernel.org
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 Documentation/devicetree/bindings/clock/msm.txt |  31 +
 drivers/clk/msm/Makefile                        |   2 +
 drivers/clk/msm/clk-rcg.c                       | 754 ++++++++++++++++++++++++
 drivers/clk/msm/clk-rcg.h                       | 114 ++++
 drivers/clk/msm/clk-rcg2.c                      | 320 ++++++++++
 5 files changed, 1221 insertions(+)
 create mode 100644 drivers/clk/msm/clk-rcg.c
 create mode 100644 drivers/clk/msm/clk-rcg.h
 create mode 100644 drivers/clk/msm/clk-rcg2.c

diff --git a/Documentation/devicetree/bindings/clock/msm.txt b/Documentation/devicetree/bindings/clock/msm.txt
index 2192621..f4595fa 100644
--- a/Documentation/devicetree/bindings/clock/msm.txt
+++ b/Documentation/devicetree/bindings/clock/msm.txt
@@ -38,3 +38,34 @@ Example:
 		clocks = <&pll8>;
 	};
 
+M/N:D Binding
+-------------
+
+Required properties:
+- compatible : shall be one of "qcom,p2-mn16-clock" or "qcom,p2-mn8-clock"
+- #clock-cells : from common clock binding; shall be set to 0
+- clocks : from common clock binding; shall be set of muxed input sources
+
+Example:
+	gsbi5_uart_rcg: gsbi5_uart_rcg {
+		#clock-cells = <0>;
+		compatible = "qcom,p2-mn16-clock";
+		clocks = <&pxo>, <&pll8>;
+	};
+
+M/N:D Dynamic Binding
+---------------------
+
+Required properties:
+- compatible : shall be one of "qcom,mn4-dyn-clock", "qcom,mn8-dyn-clock" or
+	       "qcom,p4-dyn-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : from common clock binding; shall be set of muxed input sources
+
+Example:
+	gfx2d_rcg : gfx2d_rcg {
+		#clock-cells = <0>;
+		compatible = "qcom,mn4-dyn-clock";
+		clocks = <&pxo>, <&pll2>, <&pll8>;
+	};
+
diff --git a/drivers/clk/msm/Makefile b/drivers/clk/msm/Makefile
index 16b750f..fb78ac9 100644
--- a/drivers/clk/msm/Makefile
+++ b/drivers/clk/msm/Makefile
@@ -1,3 +1,5 @@
 obj-$(CONFIG_COMMON_CLK_MSM) += clk-msm.o
 
 clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-pll.o
+clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-rcg.o
+clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-rcg2.o
diff --git a/drivers/clk/msm/clk-rcg.c b/drivers/clk/msm/clk-rcg.c
new file mode 100644
index 0000000..3400fee
--- /dev/null
+++ b/drivers/clk/msm/clk-rcg.c
@@ -0,0 +1,754 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * 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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/clk-provider.h>
+#include <linux/slab.h>
+#include <linux/device.h>
+
+#include <asm/div64.h>
+
+#include "clk-rcg.h"
+
+/**
+ * struct mn - M/N:D counter
+ * @mnctr_en_bit: bit to enable mn counter
+ * @mnctr_reset_bit: bit to assert mn counter reset
+ * @mnctr_mode_shift: lowest bit of mn counter mode field
+ * @n_val_shift: lowest bit of n value field
+ * @m_val_shift: lowest bit of m value field
+ * @width: number of bits in m/n/d values
+ */
+struct mn {
+	u8		mnctr_en_bit;
+	u8		mnctr_reset_bit;
+	u8		mnctr_mode_shift;
+#define MNCTR_MODE_DUAL 0x2
+#define MNCTR_MODE_MASK 0x3
+	u8		n_val_shift;
+	u8		m_val_shift;
+	u8		width;
+};
+
+/**
+ * struct pre_div - pre-divider
+ * @pre_div_shift: lowest bit of pre divider field
+ * @pre_div_width: number of bits in predivider
+ */
+struct pre_div {
+	u8		pre_div_shift;
+	u8		pre_div_width;
+};
+
+/**
+ * struct src_sel - source selector
+ * @src_sel_shift: lowest bit of source selection field
+ * @parent_map: map from software's parent index to hardware's src_sel field
+ */
+struct src_sel {
+	u8		src_sel_shift;
+#define SRC_SEL_MASK	0x7
+	u8		*parent_map;
+};
+
+/**
+ * struct clk_rcg - root clock generator
+ *
+ * @ctl_reg: clock control register
+ * @ctl_bit: ORed with @ctl_reg to enable the clock
+ * @ns_reg: NS register
+ * @md_reg: MD register
+ * @mn: mn counter
+ * @p: pre divider
+ * @s: source selector
+ * @freq_tbl: Frequency table
+ * @hw: handle between common and hardware-specific interfaces
+ * @lock: register lock
+ *
+ */
+struct clk_rcg {
+	void __iomem	*ctl_reg;
+	void __iomem	*ns_reg;
+	void __iomem	*md_reg;
+
+	u8		ctl_bit;
+	struct mn	mn;
+	struct pre_div	p;
+	struct src_sel	s;
+
+	const struct freq_tbl	*freq_tbl;
+
+	struct clk_hw	hw;
+	spinlock_t	*lock;
+};
+
+#define to_clk_rcg(_hw) container_of(_hw, struct clk_rcg, hw)
+
+/**
+ * struct clk_dyn_rcg - root clock generator with glitch free mux
+ *
+ * @ctl_reg: clock control register
+ * @ctl_bit: ORed with @ctl_reg to enable the clock
+ * @mux_sel_bit: Bit to switch glitch free mux
+ * @ns_reg: NS register
+ * @md_reg: MD0 and MD1 register
+ * @mn: mn counter (banked)
+ * @s: source selector (banked)
+ * @freq_tbl: Frequency table
+ * @hw: handle between common and hardware-specific interfaces
+ * @lock: register lock
+ *
+ */
+struct clk_dyn_rcg {
+	void __iomem	*ctl_reg;
+	void __iomem	*ns_reg;
+	void __iomem	*md_reg[2];
+
+	u8		ctl_bit;
+	u8		mux_sel_bit;
+	struct mn	mn[2];
+	struct pre_div	p[2];
+	struct src_sel	s[2];
+
+	const struct freq_tbl	*freq_tbl;
+
+	struct clk_hw	hw;
+	spinlock_t	*lock;
+};
+
+#define to_clk_dyn_rcg(_hw) container_of(_hw, struct clk_dyn_rcg, hw)
+
+static int clk_rcg_toggle(void __iomem *ctl_reg, u8 ctl_bit,
+		spinlock_t *lock, bool en)
+{
+	unsigned long flags;
+	u32 val;
+
+	spin_lock_irqsave(lock, flags);
+
+	val = readl_relaxed(ctl_reg);
+	if (en)
+		val |= BIT(ctl_bit);
+	else
+		val &= ~BIT(ctl_bit);
+	writel(val, ctl_reg);
+
+	spin_unlock_irqrestore(lock, flags);
+
+	return 0;
+}
+
+static int clk_rcg_enable(struct clk_hw *hw)
+{
+	struct clk_rcg *rcg = to_clk_rcg(hw);
+
+	return clk_rcg_toggle(rcg->ctl_reg, rcg->ctl_bit, rcg->lock, true);
+}
+
+static void clk_rcg_disable(struct clk_hw *hw)
+{
+	struct clk_rcg *rcg = to_clk_rcg(hw);
+
+	clk_rcg_toggle(rcg->ctl_reg, rcg->ctl_bit, rcg->lock, false);
+}
+
+static int clk_dyn_rcg_enable(struct clk_hw *hw)
+{
+	struct clk_dyn_rcg *rcg = to_clk_dyn_rcg(hw);
+
+	return clk_rcg_toggle(rcg->ctl_reg, rcg->ctl_bit, rcg->lock, true);
+}
+
+static void clk_dyn_rcg_disable(struct clk_hw *hw)
+{
+	struct clk_dyn_rcg *rcg = to_clk_dyn_rcg(hw);
+
+	clk_rcg_toggle(rcg->ctl_reg, rcg->ctl_bit, rcg->lock, false);
+}
+
+static int clk_dyn_rcg_is_enabled(struct clk_hw *hw)
+{
+	struct clk_dyn_rcg *rcg = to_clk_dyn_rcg(hw);
+	u32 val;
+
+	val = readl_relaxed(rcg->ctl_reg);
+	val &= BIT(rcg->ctl_bit);
+
+	return val ? 1 : 0;
+}
+
+static u32 ns_to_src(struct src_sel *s, u32 ns)
+{
+	ns >>= s->src_sel_shift;
+	ns &= SRC_SEL_MASK;
+	return ns;
+}
+
+static u32 src_to_ns(struct src_sel *s, u8 src, u32 ns)
+{
+	u32 mask;
+
+	mask = SRC_SEL_MASK;
+	mask <<= s->src_sel_shift;
+	ns &= ~mask;
+
+	ns |= src << s->src_sel_shift;
+	return ns;
+}
+
+static u8 clk_rcg_get_parent(struct clk_hw *hw)
+{
+	struct clk_rcg *rcg = to_clk_rcg(hw);
+	int num_parents = __clk_get_num_parents(hw->clk);
+	u32 ns;
+	int i;
+
+	ns = readl_relaxed(rcg->ns_reg);
+	ns = ns_to_src(&rcg->s, ns);
+
+	for (i = 0; i < num_parents; i++)
+		if (ns == rcg->s.parent_map[i])
+			return i;
+
+	return -EINVAL;
+}
+
+static int reg_to_bank(struct clk_dyn_rcg *rcg, u32 bank)
+{
+	bank &= BIT(rcg->mux_sel_bit);
+	return !!bank;
+}
+
+static u8 clk_dyn_rcg_get_parent(struct clk_hw *hw)
+{
+	struct clk_dyn_rcg *rcg = to_clk_dyn_rcg(hw);
+	int num_parents = __clk_get_num_parents(hw->clk);
+	u32 ns, ctl;
+	int bank;
+	int i;
+	struct src_sel *s;
+
+	ctl = readl_relaxed(rcg->ctl_reg);
+	bank = reg_to_bank(rcg, ctl);
+	s = &rcg->s[bank];
+
+	ns = readl_relaxed(rcg->ns_reg);
+	ns = ns_to_src(s, ns);
+
+	for (i = 0; i < num_parents; i++)
+		if (ns == s->parent_map[i])
+			return i;
+
+	return -EINVAL;
+}
+
+static int clk_rcg_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct clk_rcg *rcg = to_clk_rcg(hw);
+	unsigned long flags;
+	u32 ns;
+
+	spin_lock_irqsave(rcg->lock, flags);
+
+	ns = readl_relaxed(rcg->ns_reg);
+	ns = src_to_ns(&rcg->s, rcg->s.parent_map[index], ns);
+	writel(ns, rcg->ns_reg);
+
+	spin_unlock_irqrestore(rcg->lock, flags);
+
+	return 0;
+}
+
+static u32 md_to_m(struct mn *mn, u32 md)
+{
+	md >>= mn->m_val_shift;
+	md &= BIT(mn->width) - 1;
+	return md;
+}
+
+static u32 ns_to_pre_div(struct pre_div *p, u32 ns)
+{
+	ns >>= p->pre_div_shift;
+	ns &= BIT(p->pre_div_width) - 1;
+	return ns;
+}
+
+static u32 pre_div_to_ns(struct pre_div *p, u8 pre_div, u32 ns)
+{
+	u32 mask;
+
+	mask = BIT(p->pre_div_width) - 1;
+	mask <<= p->pre_div_shift;
+	ns &= ~mask;
+
+	ns |= pre_div << p->pre_div_shift;
+	return ns;
+}
+
+static u32 mn_to_md(struct mn *mn, u32 m, u32 n, u32 md)
+{
+	u32 mask, mask_w;
+
+	mask_w = BIT(mn->width) - 1;
+	mask = (mask_w << mn->m_val_shift) | mask_w;
+	md &= ~mask;
+
+	if (n) {
+		m <<= mn->m_val_shift;
+		md |= m;
+		md |= ~n & mask_w;
+	}
+
+	return md;
+}
+
+static u32 ns_m_to_n(struct mn *mn, u32 ns, u32 m)
+{
+	ns = ~ns >> mn->n_val_shift;
+	ns &= BIT(mn->width) - 1;
+	return ns + m;
+}
+
+static u32 reg_to_mnctr_mode(struct mn *mn, u32 val)
+{
+	val >>= mn->mnctr_mode_shift;
+	val &= MNCTR_MODE_MASK;
+	return val;
+}
+
+static u32 mn_to_ns(struct mn *mn, u32 m, u32 n, u32 ns)
+{
+	u32 mask;
+
+	mask = BIT(mn->width) - 1;
+	mask <<= mn->n_val_shift;
+	ns &= ~mask;
+
+	if (n) {
+		n = n - m;
+		n = ~n;
+		n &= BIT(mn->width) - 1;
+		n <<= mn->n_val_shift;
+		ns |= n;
+	}
+
+	return ns;
+}
+
+static u32 mn_to_reg(struct mn *mn, u32 m, u32 n, u32 val)
+{
+	u32 mask;
+
+	mask = MNCTR_MODE_MASK << mn->mnctr_mode_shift;
+	mask |= BIT(mn->mnctr_en_bit);
+	val &= ~mask;
+
+	if (n) {
+		val |= BIT(mn->mnctr_en_bit);
+		val |= MNCTR_MODE_DUAL << mn->mnctr_mode_shift;
+	}
+
+	return val;
+}
+
+static void configure_bank(struct clk_dyn_rcg *rcg, const struct freq_tbl *f)
+{
+	unsigned long flags;
+	u32 ns, md, ctl, *regp;
+	int bank, new_bank;
+	struct mn *mn;
+	struct pre_div *p;
+	struct src_sel *s;
+	bool enabled;
+	void __iomem *md_reg;
+	void __iomem *bank_reg;
+	bool banked_mn = !!rcg->md_reg[0];
+
+	spin_lock_irqsave(rcg->lock, flags);
+
+	enabled = __clk_is_enabled(rcg->hw.clk);
+
+	ns = readl_relaxed(rcg->ns_reg);
+	ctl = readl_relaxed(rcg->ctl_reg);
+
+	if (banked_mn) {
+		regp = &ctl;
+		bank_reg = rcg->ctl_reg;
+	} else {
+		regp = &ns;
+		bank_reg = rcg->ns_reg;
+	}
+
+	bank = reg_to_bank(rcg, *regp);
+	new_bank = enabled ? !bank : bank;
+
+	if (banked_mn) {
+		mn = &rcg->mn[new_bank];
+		md_reg = rcg->md_reg[new_bank];
+
+		ns |= BIT(mn->mnctr_reset_bit);
+		writel_relaxed(ns, rcg->ns_reg);
+
+		md = readl_relaxed(md_reg);
+		md = mn_to_md(mn, f->m, f->n, md);
+		writel_relaxed(md, md_reg);
+
+		ns = mn_to_ns(mn, f->m, f->n, ns);
+		writel_relaxed(ns, rcg->ns_reg);
+
+		ctl = mn_to_reg(mn, f->m, f->n, ctl);
+		writel_relaxed(ctl, rcg->ctl_reg);
+
+		ns &= ~BIT(mn->mnctr_reset_bit);
+		writel_relaxed(ns, rcg->ns_reg);
+	} else {
+		p = &rcg->p[new_bank];
+		ns = pre_div_to_ns(p, f->pre_div - 1, ns);
+	}
+
+	s = &rcg->s[new_bank];
+	ns = src_to_ns(s, s->parent_map[f->src], ns);
+	writel_relaxed(ns, rcg->ns_reg);
+
+	if (enabled) {
+		*regp ^= BIT(rcg->mux_sel_bit);
+		writel_relaxed(*regp, bank_reg);
+	}
+
+	/* Ensure parent switch is completed */
+	mb();
+	spin_unlock_irqrestore(rcg->lock, flags);
+}
+
+static int clk_dyn_rcg_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct clk_dyn_rcg *rcg = to_clk_dyn_rcg(hw);
+	u32 ns, ctl, md, reg;
+	int bank;
+	struct freq_tbl f = { 0 };
+	bool banked_mn = !!rcg->md_reg[0];
+
+	ctl = readl_relaxed(rcg->ctl_reg);
+	ns = readl_relaxed(rcg->ns_reg);
+	reg = banked_mn ? ctl : ns;
+
+	bank = reg_to_bank(rcg, reg);
+
+	if (banked_mn) {
+		md = readl_relaxed(rcg->md_reg[bank]);
+		f.m = md_to_m(&rcg->mn[bank], md);
+		f.n = ns_m_to_n(&rcg->mn[bank], ns, f.m);
+	} else {
+		f.pre_div = ns_to_pre_div(&rcg->p[bank], ns) + 1;
+	}
+	f.src = index;
+
+	configure_bank(rcg, &f);
+
+	return 0;
+}
+
+/*
+ * Calculate m/n:d rate
+ *
+ *          parent_rate     m
+ *   rate = ----------- x  ---
+ *            pre_div       n
+ */
+static unsigned long
+calc_rate(unsigned long rate, u32 m, u32 n, u32 mode, u32 pre_div)
+{
+	if (pre_div)
+		rate /= pre_div + 1;
+
+	if (mode) {
+		u64 tmp = rate;
+		tmp *= m;
+		do_div(tmp, n);
+		rate = tmp;
+	}
+
+	return rate;
+}
+
+static unsigned long
+clk_rcg_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
+{
+	struct clk_rcg *rcg = to_clk_rcg(hw);
+	u32 pre_div, m, n, ns, md, mode;
+	struct mn *mn = &rcg->mn;
+
+	ns = readl_relaxed(rcg->ns_reg);
+	md = readl_relaxed(rcg->md_reg);
+
+	pre_div = ns_to_pre_div(&rcg->p, ns);
+	m = md_to_m(mn, md);
+	n = ns_m_to_n(mn, ns, m);
+	/* MN counter mode is in ctl_reg sometimes */
+	if (rcg->ctl_reg != rcg->ns_reg)
+		mode = readl_relaxed(rcg->ctl_reg);
+	else
+		mode = ns;
+	mode = reg_to_mnctr_mode(mn, mode);
+
+	return calc_rate(parent_rate, m, n, mode, pre_div);
+}
+
+static unsigned long
+clk_dyn_rcg_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
+{
+	struct clk_dyn_rcg *rcg = to_clk_dyn_rcg(hw);
+	u32 m, n, pre_div, ns, md, mode, reg;
+	int bank;
+	struct mn *mn;
+	bool banked_mn = !!rcg->md_reg[0];
+
+	ns = readl_relaxed(rcg->ns_reg);
+
+	if (banked_mn)
+		reg = readl_relaxed(rcg->ctl_reg);
+	else
+		reg = ns;
+
+	bank = reg_to_bank(rcg, reg);
+
+	if (banked_mn) {
+		mn = &rcg->mn[bank];
+		md = readl_relaxed(rcg->md_reg[bank]);
+		m = md_to_m(mn, md);
+		n = ns_m_to_n(mn, ns, m);
+		mode = reg_to_mnctr_mode(mn, reg);
+		return calc_rate(parent_rate, m, n, mode, 0);
+	} else {
+		pre_div = ns_to_pre_div(&rcg->p[bank], ns);
+		return calc_rate(parent_rate, 0, 0, 0, pre_div);
+	}
+}
+
+static const
+struct freq_tbl *find_freq(const struct freq_tbl *f, unsigned long rate)
+{
+	for (; f->freq; f++)
+		if (rate <= f->freq)
+			return f;
+
+	return NULL;
+}
+
+static long _freq_tbl_determine_rate(struct clk_hw *hw,
+		const struct freq_tbl *f, unsigned long rate,
+		unsigned long *p_rate, struct clk **p)
+{
+	f = find_freq(f, rate);
+	if (!f)
+		return -EINVAL;
+
+	*p = clk_get_parent_by_index(hw->clk, f->src);
+	*p_rate =  __clk_get_rate(*p);
+
+	return f->freq;
+}
+
+static long clk_rcg_determine_rate(struct clk_hw *hw, unsigned long rate,
+		unsigned long *p_rate, struct clk **p)
+{
+	struct clk_rcg *rcg = to_clk_rcg(hw);
+
+	return _freq_tbl_determine_rate(hw, rcg->freq_tbl, rate, p_rate, p);
+}
+
+static long clk_dyn_rcg_determine_rate(struct clk_hw *hw, unsigned long rate,
+		unsigned long *p_rate, struct clk **p)
+{
+	struct clk_dyn_rcg *rcg = to_clk_dyn_rcg(hw);
+
+	return _freq_tbl_determine_rate(hw, rcg->freq_tbl, rate, p_rate, p);
+}
+
+static int clk_rcg_set_rate(struct clk_hw *hw, unsigned long rate,
+			    unsigned long parent_rate)
+{
+	struct clk_rcg *rcg = to_clk_rcg(hw);
+	unsigned long flags;
+	const struct freq_tbl *f;
+	u32 ns, md, ctl;
+	struct mn *mn = &rcg->mn;
+
+	f = find_freq(rcg->freq_tbl, rate);
+	if (!f)
+		return -EINVAL;
+
+	spin_lock_irqsave(rcg->lock, flags);
+
+	ns = readl_relaxed(rcg->ns_reg);
+	ns |= BIT(mn->mnctr_reset_bit);
+	writel_relaxed(ns, rcg->ns_reg);
+
+	md = readl_relaxed(rcg->md_reg);
+	md = mn_to_md(mn, f->m, f->n, md);
+	writel_relaxed(md, rcg->md_reg);
+
+	/* MN counter mode is in ctl_reg sometimes */
+	if (rcg->ctl_reg != rcg->ns_reg) {
+		ctl = readl_relaxed(rcg->ctl_reg);
+		ctl = mn_to_reg(mn, f->m, f->n, ctl);
+		writel_relaxed(ctl, rcg->ctl_reg);
+	} else {
+		ns = mn_to_reg(mn, f->m, f->n, ns);
+	}
+	ns = mn_to_ns(mn, f->m, f->n, ns);
+	ns = pre_div_to_ns(&rcg->p, f->pre_div - 1, ns);
+	writel_relaxed(ns, rcg->ns_reg);
+
+	ns &= ~BIT(mn->mnctr_reset_bit);
+	writel(ns, rcg->ns_reg);
+
+	spin_unlock_irqrestore(rcg->lock, flags);
+
+	return 0;
+}
+
+static int __clk_dyn_rcg_set_rate(struct clk_hw *hw, unsigned long rate)
+{
+	struct clk_dyn_rcg *rcg = to_clk_dyn_rcg(hw);
+	const struct freq_tbl *f;
+
+	f = find_freq(rcg->freq_tbl, rate);
+	if (!f)
+		return -EINVAL;
+
+	configure_bank(rcg, f);
+
+	return 0;
+}
+
+static int clk_dyn_rcg_set_rate(struct clk_hw *hw, unsigned long rate,
+			    unsigned long parent_rate)
+{
+	return __clk_dyn_rcg_set_rate(hw, rate);
+}
+
+static int clk_dyn_rcg_set_rate_and_parent(struct clk_hw *hw,
+		unsigned long rate, unsigned long parent_rate, u8 index)
+{
+	return __clk_dyn_rcg_set_rate(hw, rate);
+}
+
+static const struct clk_ops clk_rcg_ops = {
+	.enable = clk_rcg_enable,
+	.disable = clk_rcg_disable,
+	.get_parent = clk_rcg_get_parent,
+	.set_parent = clk_rcg_set_parent,
+	.recalc_rate = clk_rcg_recalc_rate,
+	.determine_rate = clk_rcg_determine_rate,
+	.set_rate = clk_rcg_set_rate,
+};
+
+struct clk *rcg_clk_register(struct device *dev, struct rcg_desc *desc,
+		spinlock_t *lock, struct clk_init_data *init,
+		u8 pre_div_width, u8 mnd_width)
+{
+	struct clk_rcg *r;
+
+	r = devm_kzalloc(dev, sizeof(*r), GFP_KERNEL);
+	if (!r)
+		return ERR_PTR(-ENOMEM);
+
+	r->ctl_reg = desc->base + desc->ctl_reg;
+	r->ns_reg = desc->base + desc->ns_reg;
+	r->md_reg = desc->base + desc->md_reg;
+	r->ctl_bit = desc->ctl_bit;
+	r->mn.mnctr_en_bit = desc->mnctr_en_bit;
+	r->mn.mnctr_reset_bit = desc->mnctr_reset_bit;
+	r->mn.mnctr_mode_shift = desc->mnctr_mode_shift;
+	r->mn.n_val_shift = desc->n_val_shift;
+	r->mn.m_val_shift = desc->m_val_shift;
+	r->p.pre_div_shift = desc->pre_div_shift;
+	r->p.pre_div_width = pre_div_width;
+	r->s.src_sel_shift = desc->src_sel_shift;
+	r->s.parent_map = desc->parent_map;
+	r->freq_tbl = desc->freq_tbl;
+	r->lock = lock;
+	r->mn.width = mnd_width;
+
+	init->ops = &clk_rcg_ops;
+	init->flags |= CLK_SET_RATE_GATE;
+	r->hw.init = init;
+
+	return devm_clk_register(dev, &r->hw);
+}
+
+static const struct clk_ops clk_dyn_rcg_ops = {
+	.enable = clk_dyn_rcg_enable,
+	.is_enabled = clk_dyn_rcg_is_enabled,
+	.disable = clk_dyn_rcg_disable,
+	.get_parent = clk_dyn_rcg_get_parent,
+	.set_parent = clk_dyn_rcg_set_parent,
+	.recalc_rate = clk_dyn_rcg_recalc_rate,
+	.determine_rate = clk_dyn_rcg_determine_rate,
+	.set_rate = clk_dyn_rcg_set_rate,
+	.set_rate_and_parent = clk_dyn_rcg_set_rate_and_parent,
+};
+
+struct clk *
+rcg_dyn_clk_register(struct device *dev, struct rcg_dyn_desc *desc,
+		spinlock_t *lock, struct clk_init_data *init, u8 pre_div_width,
+		u8 mnd_width)
+{
+	struct clk_dyn_rcg *r;
+
+	r = devm_kzalloc(dev, sizeof(*r), GFP_KERNEL);
+	if (!r)
+		return ERR_PTR(-ENOMEM);
+
+	r->ctl_reg = desc->base + desc->ctl_reg;
+	r->ns_reg = desc->base + desc->ns_reg;
+	r->ctl_bit = desc->ctl_bit;
+	if (mnd_width) {
+		r->md_reg[0] = desc->base + desc->md0_reg;
+		r->md_reg[1] = desc->base + desc->md1_reg;
+		r->mn[0].mnctr_en_bit = desc->mnctr0_en_bit;
+		r->mn[0].mnctr_reset_bit = desc->mnctr0_reset_bit;
+		r->mn[0].mnctr_mode_shift = desc->mnctr0_mode_shift;
+		r->mn[0].n_val_shift = desc->n0_val_shift;
+		r->mn[0].m_val_shift = desc->m0_val_shift;
+		r->mn[0].width = mnd_width;
+		r->mn[1].mnctr_en_bit = desc->mnctr1_en_bit;
+		r->mn[1].mnctr_reset_bit = desc->mnctr1_reset_bit;
+		r->mn[1].mnctr_mode_shift = desc->mnctr1_mode_shift;
+		r->mn[1].n_val_shift = desc->n1_val_shift;
+		r->mn[1].m_val_shift = desc->m1_val_shift;
+		r->mn[1].width = mnd_width;
+	}
+	if (pre_div_width) {
+		r->p[0].pre_div_shift = desc->pre_div0_shift;
+		r->p[0].pre_div_width = pre_div_width;
+		r->p[1].pre_div_shift = desc->pre_div1_shift;
+		r->p[1].pre_div_width = pre_div_width;
+	}
+	r->s[0].src_sel_shift = desc->src0_sel_shift;
+	r->s[0].parent_map = desc->parent_map;
+	r->s[1].src_sel_shift = desc->src1_sel_shift;
+	r->s[1].parent_map = desc->parent_map;
+	r->mux_sel_bit = desc->mux_sel_bit;
+	r->freq_tbl = desc->freq_tbl;
+	r->lock = lock;
+
+	init->ops = &clk_dyn_rcg_ops;
+	r->hw.init = init;
+
+	return devm_clk_register(dev, &r->hw);
+}
diff --git a/drivers/clk/msm/clk-rcg.h b/drivers/clk/msm/clk-rcg.h
new file mode 100644
index 0000000..9cc572d
--- /dev/null
+++ b/drivers/clk/msm/clk-rcg.h
@@ -0,0 +1,114 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * 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 __MSM_CLK_RCG_H__
+#define __MSM_CLK_RCG_H__
+
+struct device;
+struct clk;
+struct clk_init_data;
+
+struct freq_tbl {
+	unsigned long freq;
+	u8 src;
+	u8 pre_div;
+	u16 m;
+	u16 n;
+};
+
+struct rcg_desc {
+	void __iomem *base;
+	u32 ctl_reg;
+	u32 ns_reg;
+	u32 md_reg;
+
+	u8 ctl_bit;
+	u8 mnctr_en_bit;
+	u8 mnctr_reset_bit;
+	u8 mnctr_mode_shift;
+	u8 pre_div_shift;
+	u8 src_sel_shift;
+	u8 n_val_shift;
+	u8 m_val_shift;
+
+	u8 *parent_map;
+	struct freq_tbl *freq_tbl;
+};
+
+extern struct clk *rcg_clk_register(struct device *dev, struct rcg_desc *desc,
+		spinlock_t *lock, struct clk_init_data *init,
+		u8 pre_div_width, u8 mnd_width);
+
+#define rcg_p2mn8_clk_register(dev, desc, lock, init) \
+	rcg_clk_register(dev, desc, lock, init, 2, 8)
+#define rcg_p2mn16_clk_register(dev, desc, lock, init) \
+	rcg_clk_register(dev, desc, lock, init, 2, 16)
+
+struct rcg_dyn_desc {
+	void __iomem *base;
+	u32 ctl_reg;
+	u32 ns_reg;
+	u32 md0_reg;
+	u32 md1_reg;
+
+	u8 ctl_bit;
+	u8 mnctr0_en_bit;
+	u8 mnctr1_en_bit;
+	u8 mnctr0_reset_bit;
+	u8 mnctr1_reset_bit;
+	u8 mnctr0_mode_shift;
+	u8 mnctr1_mode_shift;
+	u8 pre_div0_shift;
+	u8 pre_div1_shift;
+	u8 src0_sel_shift;
+	u8 src1_sel_shift;
+	u8 n0_val_shift;
+	u8 n1_val_shift;
+	u8 m0_val_shift;
+	u8 m1_val_shift;
+	u8 mux_sel_bit;
+
+	u8 *parent_map;
+	struct freq_tbl *freq_tbl;
+};
+
+struct clk *rcg_dyn_clk_register(struct device *dev,
+		struct rcg_dyn_desc *desc, spinlock_t *lock,
+		struct clk_init_data *init, u8 pre_div_width, u8 mnd_width);
+
+#define rcg_mn4_dyn_clk_register(dev, desc, lock, init) \
+	rcg_dyn_clk_register(dev, desc, lock, init, 0, 4)
+#define rcg_mn8_dyn_clk_register(dev, desc, lock, init) \
+	rcg_dyn_clk_register(dev, desc, lock, init, 0, 8)
+#define rcg_p4_dyn_clk_register(dev, desc, lock, init) \
+	rcg_dyn_clk_register(dev, desc, lock, init, 4, 0)
+
+struct rcg2_desc {
+	void __iomem *base;
+	u32 cmd_rcgr;
+	u8 *parent_map;
+	struct freq_tbl *freq_tbl;
+};
+
+extern struct clk *rcg2_clk_register(struct device *dev, struct rcg2_desc *desc,
+		spinlock_t *lock, struct clk_init_data *init,
+		u8 hid_width, u8 mnd_width);
+
+#define rcg_h5_clk_register(dev, desc, lock, init) \
+	rcg2_clk_register(dev, desc, lock, init, 5, 0)
+#define rcg_h5mn8_clk_register(dev, desc, lock, init) \
+	rcg2_clk_register(dev, desc, lock, init, 5, 8)
+#define rcg_h5mn16_clk_register(dev, desc, lock, init) \
+	rcg2_clk_register(dev, desc, lock, init, 5, 16)
+
+#endif
diff --git a/drivers/clk/msm/clk-rcg2.c b/drivers/clk/msm/clk-rcg2.c
new file mode 100644
index 0000000..b8daf87
--- /dev/null
+++ b/drivers/clk/msm/clk-rcg2.c
@@ -0,0 +1,320 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * 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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/clk-provider.h>
+#include <linux/slab.h>
+#include <linux/device.h>
+#include <linux/delay.h>
+
+#include <asm/div64.h>
+
+#include "clk-rcg.h"
+
+#define CMD_REG			0x0
+#define CMD_UPDATE		BIT(0)
+#define CMD_ROOT_EN		BIT(1)
+#define CMD_DIRTY_CFG		BIT(4)
+#define CMD_DIRTY_N		BIT(5)
+#define CMD_DIRTY_M		BIT(6)
+#define CMD_DIRTY_D		BIT(7)
+#define CMD_ROOT_OFF		BIT(31)
+
+#define CFG_REG			0x4
+#define CFG_SRC_DIV_SHIFT	0
+#define CFG_SRC_SEL_SHIFT	8
+#define CFG_SRC_SEL_MASK	(0x7 << CFG_SRC_SEL_SHIFT)
+#define CFG_MODE_SHIFT		12
+#define CFG_MODE_MASK		(0x3 << CFG_MODE_SHIFT)
+#define CFG_MODE_DUAL_EDGE	(0x2 << CFG_MODE_SHIFT)
+
+#define M_REG			0x8
+#define N_REG			0xc
+#define D_REG			0x10
+
+/**
+ * struct clk_rcg2 - root clock generator
+ *
+ * @base: corresponds to *_CMD_RCGR
+ * @mnd_width: number of bits in m/n/d values
+ * @hid_width: number of bits in half integer divider
+ * @parent_map: map from software's parent index to hardware's src_sel field
+ * @freq_tbl: Frequency table
+ * @hw: handle between common and hardware-specific interfaces
+ * @lock: register lock
+ *
+ */
+struct clk_rcg2 {
+	void __iomem		*base;
+	u8			mnd_width;
+	u8			hid_width;
+	u8			*parent_map;
+	const struct freq_tbl	*freq_tbl;
+	struct clk_hw		hw;
+	spinlock_t		*lock;
+};
+
+#define to_clk_rcg2(_hw) container_of(_hw, struct clk_rcg2, hw)
+
+static int clk_rcg2_is_enabled(struct clk_hw *hw)
+{
+	struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+	u32 cmd;
+
+	cmd = readl_relaxed(rcg->base + CMD_REG);
+	cmd &= CMD_ROOT_OFF;
+
+	return cmd ? 0 : 1;
+}
+
+static u8 clk_rcg2_get_parent(struct clk_hw *hw)
+{
+	struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+	int num_parents = __clk_get_num_parents(hw->clk);
+	u32 cfg;
+	int i;
+
+	cfg = readl_relaxed(rcg->base + CFG_REG);
+	cfg &= CFG_SRC_SEL_MASK;
+	cfg >>= CFG_SRC_SEL_SHIFT;
+
+	for (i = 0; i < num_parents; i++)
+		if (cfg == rcg->parent_map[i])
+			return i;
+
+	return -EINVAL;
+}
+
+static void update_config(struct clk_rcg2 *rcg)
+{
+	int count;
+	u32 cmd;
+	const char *name = __clk_get_name(rcg->hw.clk);
+
+	cmd = readl_relaxed(rcg->base + CMD_REG);
+	cmd |= CMD_UPDATE;
+	writel_relaxed(cmd, rcg->base + CMD_REG);
+
+	/* Wait for update to take effect */
+	for (count = 500; count > 0; count--) {
+		if (!(readl_relaxed(rcg->base + CMD_REG) & CMD_UPDATE))
+			return;
+		udelay(1);
+	}
+
+	WARN(1, "%s: rcg didn't update its configuration.", name);
+}
+
+static int clk_rcg2_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+	unsigned long flags;
+	u32 cfg;
+
+	spin_lock_irqsave(rcg->lock, flags);
+
+	cfg = readl_relaxed(rcg->base + CFG_REG);
+	cfg &= ~CFG_SRC_SEL_MASK;
+	cfg |= rcg->parent_map[index] << CFG_SRC_SEL_SHIFT;
+	writel(cfg, rcg->base + CFG_REG);
+
+	update_config(rcg);
+
+	spin_unlock_irqrestore(rcg->lock, flags);
+
+	return 0;
+}
+
+/*
+ * Calculate m/n:d rate
+ *
+ *          parent_rate     m
+ *   rate = ----------- x  ---
+ *            hid_div       n
+ */
+static unsigned long
+calc_rate(unsigned long rate, u32 m, u32 n, u32 mode, u32 hid_div)
+{
+	if (hid_div) {
+		rate *= 2;
+		rate /= hid_div + 1;
+	}
+
+	if (mode) {
+		u64 tmp = rate;
+		tmp *= m;
+		do_div(tmp, n);
+		rate = tmp;
+	}
+
+	return rate;
+}
+
+static unsigned long
+clk_rcg2_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
+{
+	struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+	u32 cfg, hid_div, m = 0, n = 0, mode = 0, mask;
+
+	cfg = readl_relaxed(rcg->base + CFG_REG);
+
+	if (rcg->mnd_width) {
+		mask = BIT(rcg->mnd_width) - 1;
+		m = readl_relaxed(rcg->base + M_REG);
+		m &= mask;
+		n = readl_relaxed(rcg->base + N_REG);
+		n =  ~n;
+		n &= mask;
+		n += m;
+		mode = cfg & CFG_MODE_MASK;
+		mode >>= CFG_MODE_SHIFT;
+	}
+
+	mask = BIT(rcg->hid_width) - 1;
+	hid_div = cfg >> CFG_SRC_DIV_SHIFT;
+	hid_div &= mask;
+
+	return calc_rate(parent_rate, m, n, mode, hid_div);
+}
+
+static const
+struct freq_tbl *find_freq(const struct freq_tbl *f, unsigned long rate)
+{
+	for (; f->freq; f++)
+		if (rate <= f->freq)
+			return f;
+
+	return NULL;
+}
+
+static long _freq_tbl_determine_rate(struct clk_hw *hw,
+		const struct freq_tbl *f, unsigned long rate,
+		unsigned long *p_rate, struct clk **p)
+{
+	f = find_freq(f, rate);
+	if (!f)
+		return -EINVAL;
+
+	*p = clk_get_parent_by_index(hw->clk, f->src);
+	*p_rate =  __clk_get_rate(*p);
+
+	return f->freq;
+}
+
+static long clk_rcg2_determine_rate(struct clk_hw *hw, unsigned long rate,
+		unsigned long *p_rate, struct clk **p)
+{
+	struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+
+	return _freq_tbl_determine_rate(hw, rcg->freq_tbl, rate, p_rate, p);
+}
+
+static int __clk_rcg2_set_rate(struct clk_hw *hw, unsigned long rate)
+{
+	struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+	unsigned long flags;
+	const struct freq_tbl *f;
+	u32 cfg, m, n, d, mask, val;
+
+	f = find_freq(rcg->freq_tbl, rate);
+	if (!f)
+		return -EINVAL;
+
+	spin_lock_irqsave(rcg->lock, flags);
+
+	cfg = readl_relaxed(rcg->base + CFG_REG);
+	mask = BIT(rcg->hid_width) - 1;
+	mask |= CFG_SRC_SEL_MASK | CFG_MODE_MASK;
+	cfg &= ~mask;
+
+	if (rcg->mnd_width && f->n) {
+		mask = BIT(rcg->mnd_width) - 1;
+		m = readl_relaxed(rcg->base + M_REG);
+		m &= ~mask;
+		m |= f->m;
+		writel_relaxed(m, rcg->base + M_REG);
+
+		val = readl_relaxed(rcg->base + M_REG);
+		val &= ~mask;
+		n = f->n - f->m;
+		n = ~n;
+		n &= mask;
+		val |= n;
+		writel_relaxed(val, rcg->base + N_REG);
+
+		d = readl_relaxed(rcg->base + D_REG);
+		d &= ~mask;
+		d |= ~f->n & mask;
+		writel_relaxed(d, rcg->base + D_REG);
+
+		cfg |= CFG_MODE_DUAL_EDGE;
+	}
+
+	cfg |= f->pre_div << CFG_SRC_DIV_SHIFT;
+	cfg |= rcg->parent_map[f->src] << CFG_SRC_SEL_SHIFT;
+	writel_relaxed(cfg, rcg->base + CFG_REG);
+
+	update_config(rcg);
+
+	spin_unlock_irqrestore(rcg->lock, flags);
+
+	return 0;
+}
+
+static int clk_rcg2_set_rate(struct clk_hw *hw, unsigned long rate,
+			    unsigned long parent_rate)
+{
+	return __clk_rcg2_set_rate(hw, rate);
+}
+
+static int clk_rcg2_set_rate_and_parent(struct clk_hw *hw,
+		unsigned long rate, unsigned long parent_rate, u8 index)
+{
+	return __clk_rcg2_set_rate(hw, rate);
+}
+
+static const struct clk_ops clk_rcg2_ops = {
+	.is_enabled = clk_rcg2_is_enabled,
+	.get_parent = clk_rcg2_get_parent,
+	.set_parent = clk_rcg2_set_parent,
+	.recalc_rate = clk_rcg2_recalc_rate,
+	.determine_rate = clk_rcg2_determine_rate,
+	.set_rate = clk_rcg2_set_rate,
+	.set_rate_and_parent = clk_rcg2_set_rate_and_parent,
+};
+
+struct clk *rcg2_clk_register(struct device *dev, struct rcg2_desc *desc,
+		spinlock_t *lock, struct clk_init_data *init,
+		u8 hid_width, u8 mnd_width)
+{
+	struct clk_rcg2 *r;
+
+	r = devm_kzalloc(dev, sizeof(*r), GFP_KERNEL);
+	if (!r)
+		return ERR_PTR(-ENOMEM);
+
+	r->base = desc->base + desc->cmd_rcgr;
+	r->parent_map = desc->parent_map;
+	r->freq_tbl = desc->freq_tbl;
+	r->lock = lock;
+	r->mnd_width = mnd_width;
+	r->hid_width = hid_width;
+
+	init->ops = &clk_rcg2_ops;
+	r->hw.init = init;
+
+	return devm_clk_register(dev, &r->hw);
+}
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From kspaans at csclub.uwaterloo.ca  Wed Jul 24 20:57:29 2013
From: kspaans at csclub.uwaterloo.ca (Kyle Spaans (CSC))
Date: Wed, 24 Jul 2013 20:57:29 -0400
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <CAOesGMh9UMOXMENPe5pndHu7_OkEhdcj47q3fTasJS-dOtQssQ@mail.gmail.com>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
 <20130724231755.GC29801@glitch>
 <CAOesGMh9UMOXMENPe5pndHu7_OkEhdcj47q3fTasJS-dOtQssQ@mail.gmail.com>
Message-ID: <CAJvAQ4+F7TCkeHmw2RP7wXv0mcK2CP3o3y_3adG+ie4a+5t65Q@mail.gmail.com>

2013/7/24 Olof Johansson <olof at lixom.net>:
> On Wed, Jul 24, 2013 at 4:17 PM, Domenico Andreoli <cavokz at gmail.com> wrote:
>> On Wed, Jul 24, 2013 at 08:27:13AM -0700, Olof Johansson wrote:
>>> Every now and then I come across a binding that's just done Wrong(tm),
>>> merged through a submaintainer tree and hasn't seen proper review --
>>> if it had, it wouldn't look the way it does. It's something we're
>>> starting to address now since there's more people stepping up to be
>>> maintainers, but there's a backlog of bad bindings already merged.
>>
>> Where is this backlog?
>
> There is no list of them, if that is what you are asking for. If
> people are interested in cleaning them up one could be started. Which
> is why I was gauging interest.

I'm a new contributor, but I'm interesting in helping with the
janitorial work. I need to learn more about device trees to help get
support for a board I'm working with (Freescale iMX6q SD) into
mainline.


From horms at verge.net.au  Wed Jul 24 21:06:08 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 25 Jul 2013 10:06:08 +0900
Subject: ARM CPU Hotplug breakage on mach-shmobile and KZM9D
In-Reply-To: <CANqRtoRx7voEVwJG8UNNy_Jiixo=uRJCvxTD0bZdzVohoryBUA@mail.gmail.com>
References: <CANqRtoRx7voEVwJG8UNNy_Jiixo=uRJCvxTD0bZdzVohoryBUA@mail.gmail.com>
Message-ID: <20130725010607.GB31464@verge.net.au>

On Thu, Jul 25, 2013 at 12:15:49AM +0900, Magnus Damm wrote:
> Hi everyone,
> 
> Bad news: CPU Hotplug on KZM9D seems broken on recent kernels.
> 
> On renesas-next-20130710 or earlier I can perform the following:
> 
> # echo 0 > /sys/devices/system/cpu/cpu1/online
> CPU1: shutdown
> # echo 1 > /sys/devices/system/cpu/cpu1/online
> CPU1: Booted secondary processor
> #
> 
> While on more recent kernels the hotplug boot fails. This may be
> related to the move to v3.11-rc. The tag renesas-next-20130710
> surprisingly seems to be the final kernel based on v3.10-rc before
> jumping to v3.11-rc.
> 
> I wonder, do other ARM platforms have working CPU Hotplug in v3.11-rc?

I have a snowball that I could test if you think it would be useful.


From jg1.han at samsung.com  Wed Jul 24 21:13:41 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Thu, 25 Jul 2013 10:13:41 +0900
Subject: [PATCH] mfd: max8925: fix dt code for backlight
In-Reply-To: <1374680547-5336-1-git-send-email-olof@lixom.net>
References: <1374680547-5336-1-git-send-email-olof@lixom.net>
Message-ID: <000401ce88d4$33773de0$9a65b9a0$@samsung.com>

On Thursday, July 25, 2013 12:42 AM, Olof Johansson wrote:
> 
> The device-tree enablement for max8925 has several problems, but besides
> the bindings being wrong (and not having seen review) there's also some
> bad coding practices on how to fill in the platform_data from device tree.
> 
> I came across this since it causes a warning when compiling
> mmp2_defconfig, and instead of doing the minimal fix to silence the
> warning, I restructured the code a bit.
> 
> This silences the warning:
> drivers/video/backlight/max8925_bl.c: In function 'max8925_backlight_probe':
> drivers/video/backlight/max8925_bl.c:177:3: warning: statement with no effect [-Wunused-value]
> 
> Note that the bindings themselves need to be revisited too, but that will
> affect more than just the backlight driver and is best done separately;
> this just fixes the bad code for the backlight driver.
> 
> Signed-off-by: Olof Johansson <olof at lixom.net>
> ---
> 
> Richard, Jingoo, this would be good to see go into 3.11 if you're
> comfortable with it.

CC'ed Andrew Morton


Hi Olof Johansson,

Currently, there is not git tree for Backlight subsystem.
I hope that this would go into 3.11 through one of other trees
with my Ack.

If not, it will go into 3.12-rc1 through mm-tree.

Acked-by: Jingoo Han <jg1.han at samsung.com>


Best regards,
Jingoo Han

> 
> 
> -Olof
> 
>  drivers/video/backlight/max8925_bl.c |   41 +++++++++++++++++-----------------
>  1 file changed, 21 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/video/backlight/max8925_bl.c b/drivers/video/backlight/max8925_bl.c
> index 5ca11b0..886e797 100644
> --- a/drivers/video/backlight/max8925_bl.c
> +++ b/drivers/video/backlight/max8925_bl.c
> @@ -101,33 +101,37 @@ static const struct backlight_ops max8925_backlight_ops = {
>  	.get_brightness	= max8925_backlight_get_brightness,
>  };
> 
> -#ifdef CONFIG_OF
> -static int max8925_backlight_dt_init(struct platform_device *pdev,
> -			      struct max8925_backlight_pdata *pdata)
> +static void max8925_backlight_dt_init(struct platform_device *pdev)
>  {
>  	struct device_node *nproot = pdev->dev.parent->of_node, *np;
> -	int dual_string;
> +	struct max8925_backlight_pdata *pdata;
> +	u32 val;
> +
> +	if (!nproot || !IS_ENABLED(CONFIG_OF))
> +		return;
> +
> +	pdata = devm_kzalloc(&pdev->dev,
> +			     sizeof(struct max8925_backlight_pdata),
> +			     GFP_KERNEL);
> +	if (!pdata)
> +		return;
> 
> -	if (!nproot)
> -		return -ENODEV;
>  	np = of_find_node_by_name(nproot, "backlight");
>  	if (!np) {
>  		dev_err(&pdev->dev, "failed to find backlight node\n");
> -		return -ENODEV;
> +		return;
>  	}
> 
> -	of_property_read_u32(np, "maxim,max8925-dual-string", &dual_string);
> -	pdata->dual_string = dual_string;
> -	return 0;
> +	if (!of_property_read_u32(np, "maxim,max8925-dual-string", &val))
> +		pdata->dual_string = val;
> +
> +	pdev->dev.platform_data = pdata;
>  }
> -#else
> -#define max8925_backlight_dt_init(x, y)	(-1)
> -#endif
> 
>  static int max8925_backlight_probe(struct platform_device *pdev)
>  {
>  	struct max8925_chip *chip = dev_get_drvdata(pdev->dev.parent);
> -	struct max8925_backlight_pdata *pdata = pdev->dev.platform_data;
> +	struct max8925_backlight_pdata *pdata;
>  	struct max8925_backlight_data *data;
>  	struct backlight_device *bl;
>  	struct backlight_properties props;
> @@ -170,13 +174,10 @@ static int max8925_backlight_probe(struct platform_device *pdev)
>  	platform_set_drvdata(pdev, bl);
> 
>  	value = 0;
> -	if (pdev->dev.parent->of_node && !pdata) {
> -		pdata = devm_kzalloc(&pdev->dev,
> -				     sizeof(struct max8925_backlight_pdata),
> -				     GFP_KERNEL);
> -		max8925_backlight_dt_init(pdev, pdata);
> -	}
> +	if (!pdev->dev.platform_data)
> +		max8925_backlight_dt_init(pdev);
> 
> +	pdata = pdev->dev.platform_data;
>  	if (pdata) {
>  		if (pdata->lxw_scl)
>  			value |= (1 << 7);
> --
> 1.7.10.4



From r65037 at freescale.com  Wed Jul 24 21:32:29 2013
From: r65037 at freescale.com (Zhu Richard-R65037)
Date: Thu, 25 Jul 2013 01:32:29 +0000
Subject: [v8 3/3] ahci_imx: add ahci sata support on imx platforms
In-Reply-To: <20130724163038.GF20377@mtj.dyndns.org>
References: <1374646529-24432-1-git-send-email-Hong-Xing.Zhu@freescale.com>
 <1374646529-24432-4-git-send-email-Hong-Xing.Zhu@freescale.com>
 <20130724163038.GF20377@mtj.dyndns.org>
Message-ID: <0E83723C55F66F43A6041464FE31119D346BC3@039-SN2MPN1-011.039d.mgd.msft.net>

Thanks a lot. :).

Best Regards
Richard Zhu


-----Original Message-----
From: Tejun Heo [mailto:htejun at gmail.com] On Behalf Of Tejun Heo
Sent: Thursday, July 25, 2013 12:31 AM
To: Richard Zhu
Cc: shawn.guo at linaro.org; linux-arm-kernel at lists.infradead.org; jgarzik at pobox.com; rob.herring at calxeda.com; s.hauer at pengutronix.de; linux-ide at vger.kernel.org; Zhu Richard-R65037
Subject: Re: [v8 3/3] ahci_imx: add ahci sata support on imx platforms

On Wed, Jul 24, 2013 at 02:15:29PM +0800, Richard Zhu wrote:
> From: Richard Zhu <r65037 at freescale.com>
> 
> imx6q contains one Synopsys AHCI SATA controller, But it can't share 
> ahci_platform driver with other controllers.
> Because there are some misalignments of the generic AHCI controller.
> The bits definitions of the HBA registers, the Vendor Specific 
> registers, the AHCI PHY clock and the AHCI signals adjustment 
> window(GPR13 register).
>  - CAP_SSS(bit20) of the HOST_CAP is writable, default  value is '0', 
> should be configured to be '1'
>  - bit0 (only one AHCI SATA port on imx6q) of the  HOST_PORTS_IMPL 
> should be set to be '1'.(default 0)
>  - One Vendor Specific register HOST_TIMER1MS(offset:0xe0)  should be 
> configured regarding to the frequency of AHB  bus clock.
>  - Configurations of the AHCI PHY clock, and the signal  parameters of 
> the GPR13
> 
> Setup its own ahci sata driver, contained the imx6q specific 
> initialized codes, re-use the generic ahci_platform driver, and keep 
> the generic ahci_platform driver clean as much as possible.
> 
> Signed-off-by: Richard Zhu <r65037 at freescale.com>
> Reviewed-by: Shawn Guo <shawn.guo at linaro.org>

Applied 2-3 to libata/for-3.11-fixes with minor adjustments.

Thanks.

--
tejun




From magnus.damm at gmail.com  Wed Jul 24 21:49:05 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 25 Jul 2013 10:49:05 +0900
Subject: ARM CPU Hotplug breakage on mach-shmobile and KZM9D
In-Reply-To: <20130725010607.GB31464@verge.net.au>
References: <CANqRtoRx7voEVwJG8UNNy_Jiixo=uRJCvxTD0bZdzVohoryBUA@mail.gmail.com>
 <20130725010607.GB31464@verge.net.au>
Message-ID: <CANqRtoR3XoTVpTTOG8OS_Am+qB35ACD_PtV3O8v2J+1zqTBtfA@mail.gmail.com>

Hi Simon,

On Thu, Jul 25, 2013 at 10:06 AM, Simon Horman <horms at verge.net.au> wrote:
> On Thu, Jul 25, 2013 at 12:15:49AM +0900, Magnus Damm wrote:
>> Hi everyone,
>>
>> Bad news: CPU Hotplug on KZM9D seems broken on recent kernels.
>>
>> On renesas-next-20130710 or earlier I can perform the following:
>>
>> # echo 0 > /sys/devices/system/cpu/cpu1/online
>> CPU1: shutdown
>> # echo 1 > /sys/devices/system/cpu/cpu1/online
>> CPU1: Booted secondary processor
>> #
>>
>> While on more recent kernels the hotplug boot fails. This may be
>> related to the move to v3.11-rc. The tag renesas-next-20130710
>> surprisingly seems to be the final kernel based on v3.10-rc before
>> jumping to v3.11-rc.
>>
>> I wonder, do other ARM platforms have working CPU Hotplug in v3.11-rc?
>
> I have a snowball that I could test if you think it would be useful.

That would be excellent, thanks!

/ magnus


From horms at verge.net.au  Wed Jul 24 22:03:18 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 25 Jul 2013 11:03:18 +0900
Subject: [PATCH] ARM: shmobile: marzen: Switch to DT_MACHINE_START
In-Reply-To: <CANqRtoT46LimTXt4mihFJS-DDpXOu5wONVX3yWwt=sr9SDvnsg@mail.gmail.com>
References: <20130724073042.28351.33041.sendpatchset@w520>
 <20130724073952.GD17045@verge.net.au>
 <20130724084637.GA5774@verge.net.au>
 <CANqRtoT46LimTXt4mihFJS-DDpXOu5wONVX3yWwt=sr9SDvnsg@mail.gmail.com>
Message-ID: <20130725020317.GA21110@verge.net.au>

On Wed, Jul 24, 2013 at 07:00:05PM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Wed, Jul 24, 2013 at 5:46 PM, Simon Horman <horms at verge.net.au> wrote:
> > On Wed, Jul 24, 2013 at 04:39:53PM +0900, Simon Horman wrote:
> >> On Wed, Jul 24, 2013 at 04:30:42PM +0900, Magnus Damm wrote:
> >> > From: Magnus Damm <damm at opensource.se>
> >> >
> >> > Convert the marzen board to use DT_MACHINE_START. With this in
> >> > place all mach-shmobile boards use DT_MACHINE_START. Also, this
> >> > makes it possible for the r8a7779 SMP code to use DT for CPUs.
> >> >
> >> > So appended DTB is the way forward on this board.
> >>
> >> Please supply a patch to update the defconfig accordingly.
> >
> > In the course of testing this patch I created
> > a patch to update the defconfig. I will post it with
> > a patch to use DT for SMP but I have some questions about this patch.
> >
> > It seems to me that the following is also needed:
> >
> > * Select USE_OF in Kconfig
> > * Provide dt_compat in DT_MACHINE_START
> > * Provide r8a7779-marzen dts
> >
> > I have a revised version of this patch which does the above.
> > But I wanted to check with you that I am on the right track
> > before posting it.
> 
> Yes, you are correct. It seems that I was (am) too trigger happy.
> Thanks for fixing these.

No problem, I'll post the patches.

> > Also, I think that once sh73a0 and r8a7779 uses DT for SMP we can remove
> > shmobile_smp_init_cpus(). As you have posted a patch for sh73a0 I have
> > prepated a patch for r8a7779 I have also prepared a patch to remove
> > shmobile_smp_init_cpus().
> 
> I think we should remove that function, but I'd like to put some
> shared code in the same file. So I don't want to remove the file.
> Perhaps the easiest is to leave it as-is for now and let me deal with
> that in an upcoming series.

Sure, if that is how you would like to roll.
Another option is to remove the file and then add it back again later.

> > My plan is to post all relevant patches as a series once
> > my questions above are resolved.
> 
> Sounds good, thanks for your help!
> 
> Thanks,
> 
> / magnus
> 


From horms+renesas at verge.net.au  Wed Jul 24 22:13:40 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 25 Jul 2013 11:13:40 +0900
Subject: [PATCH v2 0/3] ARM: shmobile: marzen: Switch to DT_MACHINE_START
Message-ID: <1374718423-24230-1-git-send-email-horms+renesas@verge.net.au>

A short series to use DT_MACHINE_START on the marzen board.

Changes since v1

* Add "ARM: shmobile: marzen: Enable ARM_APPENDED_DTB in defconfig" patch
* Add "ARM: shmobile: r8a7779: Rely on DT for SMP CPU info" patch
* Enhance "ARM: shmobile: marzen: Switch to DT_MACHINE_START" to:
  - Select USE_OF in Kconfig
  - Provide dt_compat in DT_MACHINE_START
  - Provide r8a7779-marzen dts

Magnus Damm (1):
  ARM: shmobile: marzen: Switch to DT_MACHINE_START

Simon Horman (2):
  ARM: shmobile: r8a7779: Rely on DT for SMP CPU info
  ARM: shmobile: marzen: Enable ARM_APPENDED_DTB in defconfig

 arch/arm/boot/dts/Makefile            |  1 +
 arch/arm/boot/dts/r8a7779-marzen.dts  | 27 +++++++++++++++++++++++++++
 arch/arm/configs/marzen_defconfig     |  1 +
 arch/arm/mach-shmobile/Kconfig        |  1 +
 arch/arm/mach-shmobile/board-marzen.c |  8 +++++++-
 arch/arm/mach-shmobile/smp-r8a7779.c  | 12 +++---------
 6 files changed, 40 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/boot/dts/r8a7779-marzen.dts

-- 
1.8.2.1



From horms+renesas at verge.net.au  Wed Jul 24 22:13:43 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 25 Jul 2013 11:13:43 +0900
Subject: [PATCH v2 3/3] ARM: shmobile: marzen: Enable ARM_APPENDED_DTB in
 defconfig
In-Reply-To: <1374718423-24230-1-git-send-email-horms+renesas@verge.net.au>
References: <1374718423-24230-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1374718423-24230-4-git-send-email-horms+renesas@verge.net.au>

"ARM: shmobile: marzen: Switch to DT_MACHINE_START" moves marzen
over to use DT_MACHINE_START, however, the prevelant boot loader
does not support booting with a separate dtb. Thus, it makes
sense to use ARM_APPENDED_DTB by default.

This is consistent with other shmobile defconfigs.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/marzen_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/marzen_defconfig b/arch/arm/configs/marzen_defconfig
index 494e70a..82e4040 100644
--- a/arch/arm/configs/marzen_defconfig
+++ b/arch/arm/configs/marzen_defconfig
@@ -29,6 +29,7 @@ CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
 CONFIG_CMDLINE="console=ttySC2,115200 earlyprintk=sh-sci.2,115200 ignore_loglevel root=/dev/nfs ip=on"
 CONFIG_CMDLINE_FORCE=y
 CONFIG_KEXEC=y
-- 
1.8.2.1



From horms+renesas at verge.net.au  Wed Jul 24 22:13:42 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 25 Jul 2013 11:13:42 +0900
Subject: [PATCH v2 2/3] ARM: shmobile: r8a7779: Rely on DT for SMP CPU info
In-Reply-To: <1374718423-24230-1-git-send-email-horms+renesas@verge.net.au>
References: <1374718423-24230-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1374718423-24230-3-git-send-email-horms+renesas@verge.net.au>

Remove r8a7779 specific ->smp_init_cpus() callback and
instead of relying on shmobile_smp_init_cpus() simply
use DT for CPU core information.

Based on work for the sh73a0 by Magnus Damm.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

--

Run-time dependency on "ARM: shmobile: marzen: Switch to DT_MACHINE_START".
---
 arch/arm/mach-shmobile/smp-r8a7779.c | 12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/smp-r8a7779.c b/arch/arm/mach-shmobile/smp-r8a7779.c
index 9bdf810..42170af 100644
--- a/arch/arm/mach-shmobile/smp-r8a7779.c
+++ b/arch/arm/mach-shmobile/smp-r8a7779.c
@@ -99,6 +99,9 @@ static int r8a7779_boot_secondary(unsigned int cpu, struct task_struct *idle)
 
 static void __init r8a7779_smp_prepare_cpus(unsigned int max_cpus)
 {
+
+	/* setup r8a7779 specific SCU base */
+	shmobile_scu_base = IOMEM(R8A7779_SCU_BASE);
 	scu_enable(shmobile_scu_base);
 
 	/* Map the reset vector (in headsmp-scu.S, headsmp.S) */
@@ -117,14 +120,6 @@ static void __init r8a7779_smp_prepare_cpus(unsigned int max_cpus)
 	r8a7779_platform_cpu_kill(3);
 }
 
-static void __init r8a7779_smp_init_cpus(void)
-{
-	/* setup r8a7779 specific SCU base */
-	shmobile_scu_base = IOMEM(R8A7779_SCU_BASE);
-
-	shmobile_smp_init_cpus(scu_get_core_count(shmobile_scu_base));
-}
-
 #ifdef CONFIG_HOTPLUG_CPU
 static int r8a7779_scu_psr_core_disabled(int cpu)
 {
@@ -175,7 +170,6 @@ static int r8a7779_cpu_disable(unsigned int cpu)
 #endif /* CONFIG_HOTPLUG_CPU */
 
 struct smp_operations r8a7779_smp_ops  __initdata = {
-	.smp_init_cpus		= r8a7779_smp_init_cpus,
 	.smp_prepare_cpus	= r8a7779_smp_prepare_cpus,
 	.smp_boot_secondary	= r8a7779_boot_secondary,
 #ifdef CONFIG_HOTPLUG_CPU
-- 
1.8.2.1



From horms+renesas at verge.net.au  Wed Jul 24 22:13:41 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu, 25 Jul 2013 11:13:41 +0900
Subject: [PATCH v2 1/3] ARM: shmobile: marzen: Switch to DT_MACHINE_START
In-Reply-To: <1374718423-24230-1-git-send-email-horms+renesas@verge.net.au>
References: <1374718423-24230-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1374718423-24230-2-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Convert the marzen board to use DT_MACHINE_START. With this in
place all mach-shmobile boards use DT_MACHINE_START. Also, this
makes it possible for the r8a7779 SMP code to use DT for CPUs.

So appended DTB is the way forward on this board.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

v2 [Simon Horman]
* Select USE_OF in Kconfig
* Provide dt_compat in DT_MACHINE_START
* Provide r8a7779-marzen dts

v1 [Magnus Damm]
---
 arch/arm/boot/dts/Makefile            |  1 +
 arch/arm/boot/dts/r8a7779-marzen.dts  | 27 +++++++++++++++++++++++++++
 arch/arm/mach-shmobile/Kconfig        |  1 +
 arch/arm/mach-shmobile/board-marzen.c |  8 +++++++-
 4 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/r8a7779-marzen.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0cfe54a..d19a5cf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -187,6 +187,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
 	r8a7740-armadillo800eva.dtb \
 	r8a7778-bockw.dtb \
 	r8a7740-armadillo800eva-reference.dtb \
+	r8a7779-marzen.dtb \
 	r8a7779-marzen-reference.dtb \
 	r8a7790-lager.dtb \
 	r8a7790-lager-reference.dtb \
diff --git a/arch/arm/boot/dts/r8a7779-marzen.dts b/arch/arm/boot/dts/r8a7779-marzen.dts
new file mode 100644
index 0000000..f3f7f79
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7779-marzen.dts
@@ -0,0 +1,27 @@
+/*
+ * Device Tree Source for the Marzen board
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Simon Horman
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "r8a7779.dtsi"
+
+/ {
+	model = "marzen";
+	compatible = "renesas,marzen", "renesas,r8a7779";
+
+	chosen {
+		bootargs = "console=ttySC2,115200 earlyprintk=sh-sci.2,115200 ignore_loglevel root=/dev/nfs ip=on";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x60000000 0x40000000>;
+	};
+};
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 6f71c94..35b11ce 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -168,6 +168,7 @@ config MACH_MARZEN
 	depends on ARCH_R8A7779
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	select USE_OF
 
 config MACH_MARZEN_REFERENCE
 	bool "MARZEN board - Reference Device Tree Implementation"
diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c
index 1f57865..91f8751 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c
@@ -237,7 +237,12 @@ static void __init marzen_init(void)
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 
-MACHINE_START(MARZEN, "marzen")
+static const char *marzen_boards_compat_dt[] __initdata = {
+        "renesas,marzen",
+        NULL,
+};
+
+DT_MACHINE_START(MARZEN, "marzen")
 	.smp		= smp_ops(r8a7779_smp_ops),
 	.map_io		= r8a7779_map_io,
 	.init_early	= r8a7779_add_early_devices,
@@ -245,5 +250,6 @@ MACHINE_START(MARZEN, "marzen")
 	.init_irq	= r8a7779_init_irq,
 	.init_machine	= marzen_init,
 	.init_late	= r8a7779_init_late,
+	.dt_compat	= marzen_boards_compat_dt,
 	.init_time	= r8a7779_earlytimer_init,
 MACHINE_END
-- 
1.8.2.1



From shawn.guo at linaro.org  Wed Jul 24 22:36:08 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 25 Jul 2013 10:36:08 +0800
Subject: [PATCH 1/2] ARM i.MX6Q: dts: Enable SPI NOR flash on Phytec
 phyFLEX-i.MX6 Ouad module
In-Reply-To: <51F01DF0.3030207@cogentembedded.com>
References: <1374683729-13438-1-git-send-email-p.zabel@pengutronix.de>
 <51F01DF0.3030207@cogentembedded.com>
Message-ID: <20130725023605.GA7492@S2101-09.ap.freescale.net>

On Wed, Jul 24, 2013 at 10:33:20PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 07/24/2013 08:35 PM, Philipp Zabel wrote:
> 
> >Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> >---
> >  arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 15 +++++++++++++++
> >  1 file changed, 15 insertions(+)
> 
> >diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
> >index f5e1981..5113d29 100644
> >--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
> >+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
> >@@ -20,6 +20,20 @@
> >  	};
> >  };
> >
> >+&ecspi3 {
> >+	pinctrl-names = "default";
> >+	pinctrl-0 = <&pinctrl_ecspi3_1>;
> >+	status = "okay";
> >+	fsl,spi-num-chipselects = <1>;
> >+	cs-gpios = <&gpio4 24 0>;
> >+
> >+	flash: m25p80 at 0 {
> 
>    Quoting the EPAPR spec [1]: "The name of a node should be
> somewhat generic, reflecting the function of the device and not its
> precise programming model. If appropriate, the name should be one of
> the following choices:
> [...]
>    - flash

I fixed it up and applied the series.

Shawn



From festevam at gmail.com  Wed Jul 24 22:59:35 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 24 Jul 2013 23:59:35 -0300
Subject: Enabling USBH1 on mx53qsb
Message-ID: <CAOMZO5CAdxzn-3Xc2DZDYEXwsEznRrcqPbCbTDc5ieBkQkA8=g@mail.gmail.com>

Hi,

I am trying to get USBH1 port to work on mx53qsb (with Dialog pmic)
with the following patch against linux-next-20130724:

--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@ -93,6 +93,15 @@
                        regulator-max-microvolt = <3200000>;
                        regulator-always-on;
                };
+
+               reg_usb_vbus: usb_vbus {
+                       compatible = "regulator-fixed";
+                       regulator-name = "usb_vbus";
+                       regulator-min-microvolt = <5000000>;
+                       regulator-max-microvolt = <5000000>;
+                       gpio = <&gpio7 8 0>;
+                       enable-active-high;
+               };
        };

        sound {
@@ -145,6 +154,7 @@
                                MX53_PAD_EIM_DA12__GPIO3_12       0x80000000
                                MX53_PAD_EIM_DA13__GPIO3_13       0x80000000
                                MX53_PAD_PATA_DA_0__GPIO7_6       0x80000000
+                               MX53_PAD_PATA_DA_2__GPIO7_8       0x80000000
                                MX53_PAD_GPIO_16__GPIO7_11        0x80000000
                        >;
                };
@@ -302,7 +312,8 @@
 };

 &usbh1 {
-       status = "okay";
+       vbus-supply = <&reg_usb_vbus>;
+       status = "okay";
 };

 &usbotg {


mx53qsb board has two USB host ports:

- The top port is USBH1
- The bottom port is OTG (also shared with J3 connector)

After applying the above patch the OTG port does work, but the USBH1 does not.

However, if I access USBH1 within U-boot prior to launching the
kernel, then I am able to use USBH1 in the kernel succesfully.

Any idea of something I am missing?

Thanks,

Fabio Estevam


From shawn.guo at linaro.org  Wed Jul 24 23:08:40 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Thu, 25 Jul 2013 11:08:40 +0800
Subject: [PATCH v2 1/2] ARM: dts: imx6qdl-sabresd: Add touchscreen support
In-Reply-To: <1374697204-18474-1-git-send-email-fabio.estevam@freescale.com>
References: <1374697204-18474-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <20130725030838.GB7492@S2101-09.ap.freescale.net>

On Wed, Jul 24, 2013 at 05:20:03PM -0300, Fabio Estevam wrote:
> mx6 sabresd boards have a egalax touchscreen controller connected via I2C3.
> 
> Add support for it.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Both applied, thanks.



From peter.chen at freescale.com  Wed Jul 24 23:13:16 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 25 Jul 2013 11:13:16 +0800
Subject: Enabling USBH1 on mx53qsb
In-Reply-To: <CAOMZO5CAdxzn-3Xc2DZDYEXwsEznRrcqPbCbTDc5ieBkQkA8=g@mail.gmail.com>
References: <CAOMZO5CAdxzn-3Xc2DZDYEXwsEznRrcqPbCbTDc5ieBkQkA8=g@mail.gmail.com>
Message-ID: <20130725031315.GA4489@nchen-desktop>

On Wed, Jul 24, 2013 at 11:59:35PM -0300, Fabio Estevam wrote:
> Hi,
> 
> I am trying to get USBH1 port to work on mx53qsb (with Dialog pmic)
> with the following patch against linux-next-20130724:
> 
> --- a/arch/arm/boot/dts/imx53-qsb.dts
> +++ b/arch/arm/boot/dts/imx53-qsb.dts
> @@ -93,6 +93,15 @@
>                         regulator-max-microvolt = <3200000>;
>                         regulator-always-on;
>                 };
> +
> +               reg_usb_vbus: usb_vbus {
> +                       compatible = "regulator-fixed";
> +                       regulator-name = "usb_vbus";
> +                       regulator-min-microvolt = <5000000>;
> +                       regulator-max-microvolt = <5000000>;
> +                       gpio = <&gpio7 8 0>;
> +                       enable-active-high;
> +               };
>         };
> 
>         sound {
> @@ -145,6 +154,7 @@
>                                 MX53_PAD_EIM_DA12__GPIO3_12       0x80000000
>                                 MX53_PAD_EIM_DA13__GPIO3_13       0x80000000
>                                 MX53_PAD_PATA_DA_0__GPIO7_6       0x80000000
> +                               MX53_PAD_PATA_DA_2__GPIO7_8       0x80000000
>                                 MX53_PAD_GPIO_16__GPIO7_11        0x80000000
>                         >;
>                 };
> @@ -302,7 +312,8 @@
>  };
> 
>  &usbh1 {
> -       status = "okay";
> +       vbus-supply = <&reg_usb_vbus>;
> +       status = "okay";
>  };
> 
>  &usbotg {
> 
> 
> mx53qsb board has two USB host ports:
> 
> - The top port is USBH1
> - The bottom port is OTG (also shared with J3 connector)
> 
> After applying the above patch the OTG port does work, but the USBH1 does not.

Would you enable CONFIG_USB_DEBUG to see where is the problem?

> 
> However, if I access USBH1 within U-boot prior to launching the
> kernel, then I am able to use USBH1 in the kernel succesfully.

access host 1 at u-boot, what do you mean, only register access
or let host 1 work?

If it is really true, that means the kernel may omit some init steps
for host 1, but u-boot has.


-- 

Best Regards,
Peter Chen



From joelf at ti.com  Wed Jul 24 23:21:18 2013
From: joelf at ti.com (Fernandes, Joel)
Date: Thu, 25 Jul 2013 03:21:18 +0000
Subject: [PATCH] dma: edma: add device_slave_caps() support
In-Reply-To: <51F027CB.2050608@metafoo.de>
References: <1374597804-3961-1-git-send-email-joelf@ti.com>
 <51EF8A52.90902@metafoo.de>
 <51EF8C2B.2030409@ti.com>,<51EF8F4E.8080806@metafoo.de>
 <FB20353E-4890-4462-A671-3587A3841B4A@ti.com> <51EF92F2.3030405@metafoo.de>
 <51F0231C.7000401@ti.com>,<51F027CB.2050608@metafoo.de>
Message-ID: <93497CC0-D756-4748-89E5-37F1C5F51EE4@ti.com>



Sent from my iPhone

On Jul 24, 2013, at 2:15 PM, "Lars-Peter Clausen" <lars at metafoo.de> wrote:

> On 07/24/2013 08:55 PM, Joel Fernandes wrote:
>> On 07/24/2013 03:40 AM, Lars-Peter Clausen wrote:
>>> On 07/24/2013 10:28 AM, Fernandes, Joel wrote:
>>>> 
>>>> On Jul 24, 2013, at 3:23 AM, "Lars-Peter Clausen" <lars at metafoo.de> wrote:
>>>> 
>>>>> On 07/24/2013 10:11 AM, Joel Fernandes wrote:
>>>>>> On 07/24/2013 03:03 AM, Lars-Peter Clausen wrote:
>>>>>>> On 07/23/2013 06:43 PM, Joel Fernandes wrote:
>>>>>>>> Implement device_slave_caps(). EDMA has a limited number of slots.
>>>>>>>> Slave drivers such as omap_hsmmc will query the driver to make
>>>>>>>> sure they don't pass in more than these many scatter segments.
>>>>>>>> 
>>>>>>>> Signed-off-by: Joel Fernandes <joelf at ti.com>
>>>>>>>> ---
>>>>>>>> Vinod, or Dan- If this patch looks ok, can you please merge in for
>>>>>>>> -rc cycle? This patch is required to fix MMC support on AM33xx. This
>>>>>>>> patch is blocking 3 other patches which fix various MMC things. Thanks!
>>>>>>>> 
>>>>>>>> Notes:
>>>>>>>> (1) this approach is temporary and only for -rc cycle to fix MMC on
>>>>>>>> AM335x. It will be replace by the RFC series in future kernels:
>>>>>>>> http://www.spinics.net/lists/arm-kernel/msg260094.html
>>>>>>>> 
>>>>>>>> (2) Patch depends Vinod's patch at:
>>>>>>>> http://permalink.gmane.org/gmane.linux.kernel/1525112
>>>>>>>> 
>>>>>>>> drivers/dma/edma.c |    9 +++++++++
>>>>>>>> 1 file changed, 9 insertions(+)
>>>>>>>> 
>>>>>>>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
>>>>>>>> index 7222cbe..81d5429 100644
>>>>>>>> --- a/drivers/dma/edma.c
>>>>>>>> +++ b/drivers/dma/edma.c
>>>>>>>> @@ -517,6 +517,14 @@ static void edma_issue_pending(struct dma_chan *chan)
>>>>>>>>    spin_unlock_irqrestore(&echan->vchan.lock, flags);
>>>>>>>> }
>>>>>>>> 
>>>>>>>> +static inline int edma_slave_caps(struct dma_chan *chan,
>>>>>>>> +    struct dma_slave_caps *caps)
>>>>>>>> +{
>>>>>>>> +    caps->max_sg_nr = MAX_NR_SG;
>>>>>>> 
>>>>>>> Hm, what about the other fields?
>>>>>> 
>>>>>> Other fields are unused, the max segment size is supposed to be
>>>>>> calculated "given" the address width and burst size. Since these
>>>>>> can't be provided to get_caps, I have left it out for now.
>>>>>> See: https://lkml.org/lkml/2013/3/6/464
>>>>> 
>>>>> The PL330 driver is similar in this regard, the maximum segment size also
>>>>> depends on address width and burst width. What I did for the get_slave_caps
>>>>> implementation is to set it to the minimum maximum size. E.g. in you case
>>>>> that should be SZ_64K - 1 (burstsize and addrwidth both set to 1).
>>>> 
>>>> So you're setting max to minimum maximum size? Isn't that like telling the driver that its segments can't be bigger than this... Unless I'm missing something..
>>> 
>>> Yes. This is a limitation of the current slave_caps API. The maximum needs
>>> to be the maximum for all possible configurations. A specific configuration
>>> may allow a larger maximum. So we maybe have to extend the API to be able to
>>> query the limits for a certain configuration. Not sure what the best way
>>> would be to do that, either adding a config parameter to get_slave_caps or
>>> to break it into two functions like you proposed one for the static
>>> capabilities and one for the sg limits.
>> 
>> I am OK with either approach as long as a decision can be made quickly
>> by maintainers. Right now lot of back and forth has happened and 3
>> different versions of the same thing have been posted since January.
>> Since this is such a trivial change, it doesn't make sense to spend so
>> much time on it IMO.... The sad part is though this change is trivial,
>> other drivers such as MMC are broken and cannot be enabled due to this.
>> We cannot afford to leave them broken.
> 
> Well this is a new API, so it is kind of expected that there is some back and forth and that there will be a few revisions.

Sure. Only thing bothered me is it is a few lines and is just API semantics, nothing functional really.

The MMC dt patches were posted but not applied. I said regression because the dt was agreed for -rc cycle but only thing missing is this trivial api stuff so possibly counting that as a regression fixes MMC altogether. 6 months for trivial change blocking an otherwise fully working driver is too much. I am speaking collectively for all of us, not me or anyone in particular. Anyway looks like MMC is not going anywhere till then.

> 
>> 
>> If Vinod is not available, can Dan please respond on how to proceed on
>> this? We really need this trivial change to go into this -rc cycle and
>> not delay it by another kernel release. Thank you.
> 
> This is not something you'd merge for rc3 or even later. If the MMC driver does not work without this I guess it never worked, so strictly speaking there is no regression and it is just a new feature.

Agreed.

-Joel

> 
> - Lars
> 


From festevam at gmail.com  Wed Jul 24 23:28:15 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 25 Jul 2013 00:28:15 -0300
Subject: Enabling USBH1 on mx53qsb
In-Reply-To: <20130725031315.GA4489@nchen-desktop>
References: <CAOMZO5CAdxzn-3Xc2DZDYEXwsEznRrcqPbCbTDc5ieBkQkA8=g@mail.gmail.com>
 <20130725031315.GA4489@nchen-desktop>
Message-ID: <CAOMZO5DB5Pxv50Yp2xUtp+yoJq6O+r=ZrGfJvsFNf1gcVOQUEA@mail.gmail.com>

Hi Peter,

On Thu, Jul 25, 2013 at 12:13 AM, Peter Chen <peter.chen at freescale.com> wrote:

> Would you enable CONFIG_USB_DEBUG to see where is the problem?

This is what I get:

ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: f5780100 op: f5780140
ci_hdrc ci_hdrc.0: doesn't support gadget
ci_hdrc ci_hdrc.0: EHCI Host Controller
ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: f5780300 op: f5780340
ci_hdrc ci_hdrc.1: doesn't support gadget
ci_hdrc ci_hdrc.1: EHCI Host Controller
ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 2
ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected

>
>>
>> However, if I access USBH1 within U-boot prior to launching the
>> kernel, then I am able to use USBH1 in the kernel succesfully.
>
> access host 1 at u-boot, what do you mean, only register access
> or let host 1 work?

This is what I do in U-boot:

MX53LOCO U-Boot > usb reset
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
       scanning usb for ethernet devices... 0 Ethernet Device(s) found
MX53LOCO U-Boot > run bootcmd

Then kernel is launched and I can use USBH1 succesfully.

Regards,

Fabio Estevam


From peter.chen at freescale.com  Wed Jul 24 23:37:17 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 25 Jul 2013 11:37:17 +0800
Subject: Enabling USBH1 on mx53qsb
In-Reply-To: <CAOMZO5DB5Pxv50Yp2xUtp+yoJq6O+r=ZrGfJvsFNf1gcVOQUEA@mail.gmail.com>
References: <CAOMZO5CAdxzn-3Xc2DZDYEXwsEznRrcqPbCbTDc5ieBkQkA8=g@mail.gmail.com>
 <20130725031315.GA4489@nchen-desktop>
 <CAOMZO5DB5Pxv50Yp2xUtp+yoJq6O+r=ZrGfJvsFNf1gcVOQUEA@mail.gmail.com>
Message-ID: <20130725033716.GB4489@nchen-desktop>

On Thu, Jul 25, 2013 at 12:28:15AM -0300, Fabio Estevam wrote:
> Hi Peter,
> 
> On Thu, Jul 25, 2013 at 12:13 AM, Peter Chen <peter.chen at freescale.com> wrote:
> 
> > Would you enable CONFIG_USB_DEBUG to see where is the problem?
> 
> This is what I get:
> 
> ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: f5780100 op: f5780140
> ci_hdrc ci_hdrc.0: doesn't support gadget
> ci_hdrc ci_hdrc.0: EHCI Host Controller
> ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
> ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: f5780300 op: f5780340
> ci_hdrc ci_hdrc.1: doesn't support gadget
> ci_hdrc ci_hdrc.1: EHCI Host Controller
> ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 2
> ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 1 port detected
> 
> >
> >>
> >> However, if I access USBH1 within U-boot prior to launching the
> >> kernel, then I am able to use USBH1 in the kernel succesfully.
> >
> > access host 1 at u-boot, what do you mean, only register access
> > or let host 1 work?
> 
> This is what I do in U-boot:
> 
> MX53LOCO U-Boot > usb reset
> (Re)start USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... 2 USB Device(s) found
>        scanning usb for storage devices... 1 Storage Device(s) found
>        scanning usb for ethernet devices... 0 Ethernet Device(s) found
> MX53LOCO U-Boot > run bootcmd
> 
> Then kernel is launched and I can use USBH1 succesfully.

seems u-boot already support mx53.

Can you measure the host 1 vbus pin? The vbus should be 5v to let
the host works normal.

-- 

Best Regards,
Peter Chen



From dinguyen at altera.com  Wed Jul 24 23:43:17 2013
From: dinguyen at altera.com (dinguyen at altera.com)
Date: Wed, 24 Jul 2013 22:43:17 -0500
Subject: [PATCH 2/2] clocksource: dw_apb_timer_of: Fix read_sched_clock
In-Reply-To: <1374723797-22169-1-git-send-email-dinguyen@altera.com>
References: <1374723797-22169-1-git-send-email-dinguyen@altera.com>
Message-ID: <1374723797-22169-2-git-send-email-dinguyen@altera.com>

From: Dinh Nguyen <dinguyen at altera.com>

The read_sched_clock should return the ~value because the clock is a
countdown implementation. read_sched_clock() should be the same as
__apbt_read_clocksource().

If a separate timer for the sched_clock exist, then read_sched_clock()
will return an incorrect value. The (sched_io_base + 0x4) needs to be in
the function for both cases.

Also, remove the use of "dw-apb-timer-sp" and "dw-apb-timer-osc" since
they are the same DW clock.

Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
Acked-by: Jamie Iles <jamie at jamieiles.com>
CC: Rob Herring <rob.herring at calxeda.com>
CC: Arnd Bergmann <arnd at arndb.de>
Cc: Olof Johansson <olof at lixom.net>
CC: Jamie Iles <jamie at jamieiles.com>
Cc: John Stultz <john.stultz at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Pavel Machek <pavel at denx.de>
Cc: Heiko Stuebner <heiko at sntech.de>
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/clocksource/dw_apb_timer_of.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
index 4cbae4f..8e00929 100644
--- a/drivers/clocksource/dw_apb_timer_of.c
+++ b/drivers/clocksource/dw_apb_timer_of.c
@@ -102,18 +102,17 @@ static void add_clocksource(struct device_node *source_timer)
 	 * timer is found. sched_io_base then points to the current_value
 	 * register of the clocksource timer.
 	 */
-	sched_io_base = iobase + 0x04;
+	sched_io_base = iobase;
 	sched_rate = rate;
 }
 
 static u32 read_sched_clock(void)
 {
-	return __raw_readl(sched_io_base);
+	return ~__raw_readl(sched_io_base + 0x4);
 }
 
 static const struct of_device_id sptimer_ids[] __initconst = {
 	{ .compatible = "picochip,pc3x2-rtc" },
-	{ .compatible = "snps,dw-apb-timer-sp" },
 	{ /* Sentinel */ },
 };
 
@@ -153,4 +152,4 @@ static void __init dw_apb_timer_init(struct device_node *timer)
 	num_called++;
 }
 CLOCKSOURCE_OF_DECLARE(pc3x2_timer, "picochip,pc3x2-timer", dw_apb_timer_init);
-CLOCKSOURCE_OF_DECLARE(apb_timer, "snps,dw-apb-timer-osc", dw_apb_timer_init);
+CLOCKSOURCE_OF_DECLARE(apb_timer, "snps,dw-apb-timer", dw_apb_timer_init);
-- 
1.7.9.5




From dinguyen at altera.com  Wed Jul 24 23:43:16 2013
From: dinguyen at altera.com (dinguyen at altera.com)
Date: Wed, 24 Jul 2013 22:43:16 -0500
Subject: [PATCH 1/2] ARM: dts: Change dw-apb-timer-osc and dw-apb-timer-sp to
 just dw-apb-timer
Message-ID: <1374723797-22169-1-git-send-email-dinguyen@altera.com>

From: Dinh Nguyen <dinguyen at altera.com>

"dw-apb-timer-osc" and "dw-apb-timer-sp" are the same implementation of the
DW APB timer, just fed by different clocks.

Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
CC: Rob Herring <rob.herring at calxeda.com>
Cc: Grant Likely <grant.likely at linaro.org>
CC: Arnd Bergmann <arnd at arndb.de>
Cc: Olof Johansson <olof at lixom.net>
CC: Jamie Iles <jamie at jamieiles.com>
Cc: John Stultz <john.stultz at linaro.org>
Cc: Heiko Stuebner <heiko at sntech.de>
Cc: Pavel Machek <pavel at denx.de>
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
---
 Documentation/devicetree/bindings/rtc/dw-apb.txt |   21 +++----------------
 arch/arm/boot/dts/rk3066a.dtsi                   |    6 +++---
 arch/arm/boot/dts/socfpga.dtsi                   |   24 +++++++++++-----------
 arch/arm/boot/dts/socfpga_cyclone5.dts           |    8 ++++----
 arch/arm/boot/dts/socfpga_vt.dts                 |    8 ++++----
 5 files changed, 26 insertions(+), 41 deletions(-)

diff --git a/Documentation/devicetree/bindings/rtc/dw-apb.txt b/Documentation/devicetree/bindings/rtc/dw-apb.txt
index eb2327b..0a1020e 100644
--- a/Documentation/devicetree/bindings/rtc/dw-apb.txt
+++ b/Documentation/devicetree/bindings/rtc/dw-apb.txt
@@ -1,7 +1,7 @@
 * Designware APB timer
 
 Required properties:
-- compatible: "snps,dw-apb-timer-sp" or "snps,dw-apb-timer-osc"
+- compatible: "snps,dw-apb-timer"
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: IRQ line for the timer.
@@ -20,23 +20,8 @@ systems may use one.
 
 
 Example:
-
-		timer1: timer at ffc09000 {
-				compatible = "snps,dw-apb-timer-sp";
-				interrupts = <0 168 4>;
-				clock-frequency = <200000000>;
-				reg = <0xffc09000 0x1000>;
-			};
-
-		timer2: timer at ffd00000 {
-				compatible = "snps,dw-apb-timer-osc";
-				interrupts = <0 169 4>;
-				clock-frequency = <200000000>;
-				reg = <0xffd00000 0x1000>;
-			};
-
-		timer3: timer at ffe00000 {
-				compatible = "snps,dw-apb-timer-osc";
+		timer1: timer at ffe00000 {
+				compatible = "snps,dw-apb-timer";
 				interrupts = <0 170 4>;
 				reg = <0xffe00000 0x1000>;
 				clocks = <&timer_clk>, <&timer_pclk>;
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 56bfac9..2dff468 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -71,7 +71,7 @@
 		};
 
 		timer at 20038000 {
-			compatible = "snps,dw-apb-timer-osc";
+			compatible = "snps,dw-apb-timer";
 			reg = <0x20038000 0x100>;
 			interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&clk_gates1 0>, <&clk_gates7 7>;
@@ -79,7 +79,7 @@
 		};
 
 		timer at 2003a000 {
-			compatible = "snps,dw-apb-timer-osc";
+			compatible = "snps,dw-apb-timer";
 			reg = <0x2003a000 0x100>;
 			interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&clk_gates1 1>, <&clk_gates7 8>;
@@ -87,7 +87,7 @@
 		};
 
 		timer at 2000e000 {
-			compatible = "snps,dw-apb-timer-osc";
+			compatible = "snps,dw-apb-timer";
 			reg = <0x2000e000 0x100>;
 			interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&clk_gates1 2>, <&clk_gates7 9>;
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 93ee655..4e8291b 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -26,10 +26,6 @@
 		ethernet1 = &gmac1;
 		serial0 = &uart0;
 		serial1 = &uart1;
-		timer0 = &timer0;
-		timer1 = &timer1;
-		timer2 = &timer2;
-		timer3 = &timer3;
 	};
 
 	cpus {
@@ -486,28 +482,32 @@
 			interrupts = <1 13 0xf04>;
 		};
 
-		timer0: timer0 at ffc08000 {
-			compatible = "snps,dw-apb-timer-sp";
+		timer0: timer at ffc08000 {
+			compatible = "snps,dw-apb-timer";
 			interrupts = <0 167 4>;
 			reg = <0xffc08000 0x1000>;
+			clocks = <&osc>;
 		};
 
-		timer1: timer1 at ffc09000 {
-			compatible = "snps,dw-apb-timer-sp";
+		timer1: timer at ffc09000 {
+			compatible = "snps,dw-apb-timer";
 			interrupts = <0 168 4>;
 			reg = <0xffc09000 0x1000>;
+			clocks = <&osc>;
 		};
 
-		timer2: timer2 at ffd00000 {
-			compatible = "snps,dw-apb-timer-osc";
+		timer2: timer at ffd00000 {
+			compatible = "snps,dw-apb-timer";
 			interrupts = <0 169 4>;
 			reg = <0xffd00000 0x1000>;
+			clocks = <&l4_sp_clk>;
 		};
 
-		timer3: timer3 at ffd01000 {
-			compatible = "snps,dw-apb-timer-osc";
+		timer3: timer at ffd01000 {
+			compatible = "snps,dw-apb-timer";
 			interrupts = <0 170 4>;
 			reg = <0xffd01000 0x1000>;
+			clocks = <&l4_sp_clk>;
 		};
 
 		uart0: serial0 at ffc02000 {
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dts b/arch/arm/boot/dts/socfpga_cyclone5.dts
index 102c4d8..54b8483 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dts
@@ -67,19 +67,19 @@
 			};
 		};
 
-		timer0 at ffc08000 {
+		timer at ffc08000 {
 			clock-frequency = <100000000>;
 		};
 
-		timer1 at ffc09000 {
+		timer at ffc09000 {
 			clock-frequency = <100000000>;
 		};
 
-		timer2 at ffd00000 {
+		timer at ffd00000 {
 			clock-frequency = <25000000>;
 		};
 
-		timer3 at ffd01000 {
+		timer at ffd01000 {
 			clock-frequency = <25000000>;
 		};
 
diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
index d93deb0..6a1d8b7 100644
--- a/arch/arm/boot/dts/socfpga_vt.dts
+++ b/arch/arm/boot/dts/socfpga_vt.dts
@@ -58,19 +58,19 @@
 			};
 		};
 
-		timer0 at ffc08000 {
+		timer at ffc08000 {
 			clock-frequency = <7000000>;
 		};
 
-		timer1 at ffc09000 {
+		timer at ffc09000 {
 			clock-frequency = <7000000>;
 		};
 
-		timer2 at ffd00000 {
+		timer at ffd00000 {
 			clock-frequency = <7000000>;
 		};
 
-		timer3 at ffd01000 {
+		timer at ffd01000 {
 			clock-frequency = <7000000>;
 		};
 
-- 
1.7.9.5




From festevam at gmail.com  Wed Jul 24 23:44:32 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 25 Jul 2013 00:44:32 -0300
Subject: Enabling USBH1 on mx53qsb
In-Reply-To: <20130725033716.GB4489@nchen-desktop>
References: <CAOMZO5CAdxzn-3Xc2DZDYEXwsEznRrcqPbCbTDc5ieBkQkA8=g@mail.gmail.com>
 <20130725031315.GA4489@nchen-desktop>
 <CAOMZO5DB5Pxv50Yp2xUtp+yoJq6O+r=ZrGfJvsFNf1gcVOQUEA@mail.gmail.com>
 <20130725033716.GB4489@nchen-desktop>
Message-ID: <CAOMZO5DYztMXpF33TLfGkvk3+SUa2_6oPNhupaAx6kxYwavStA@mail.gmail.com>

On Thu, Jul 25, 2013 at 12:37 AM, Peter Chen <peter.chen at freescale.com> wrote:

> seems u-boot already support mx53.
>
> Can you measure the host 1 vbus pin? The vbus should be 5v to let
> the host works normal.

The VBUS is the same for both USBH1 port and OTG ports and it is at
5V, since OTG port does work.


From r.sricharan at ti.com  Wed Jul 24 23:49:37 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Thu, 25 Jul 2013 09:19:37 +0530
Subject: [PATCH 6/8] ARM: mm: LPAE: Correct virt_to_phys patching for
 64 bit physical addresses
In-Reply-To: <alpine.LFD.2.03.1307241456260.15022@syhkavp.arg>
References: <1371858502-10083-1-git-send-email-santosh.shilimkar@ti.com>
 <1371858502-10083-7-git-send-email-santosh.shilimkar@ti.com>
 <alpine.LFD.2.03.1307231850350.15022@syhkavp.arg> <51EF356D.2050902@ti.com>
 <alpine.LFD.2.03.1307232222200.15022@syhkavp.arg> <51EFBF8F.4010201@ti.com>
 <51EFC37B.80906@ti.com> <alpine.LFD.2.03.1307241456260.15022@syhkavp.arg>
Message-ID: <51F0A051.20203@ti.com>

Hi Nicolas,

On Thursday 25 July 2013 01:51 AM, Nicolas Pitre wrote:
> On Wed, 24 Jul 2013, Sricharan R wrote:
>
>> On Wednesday 24 July 2013 05:20 PM, Sricharan R wrote:
>>> On Wednesday 24 July 2013 08:19 AM, Nicolas Pitre wrote:
>>>> On Tue, 23 Jul 2013, Santosh Shilimkar wrote:
>>>>
>>>>> On Tuesday 23 July 2013 09:10 PM, Nicolas Pitre wrote:
>>>>>> On Fri, 21 Jun 2013, Santosh Shilimkar wrote:
>>>>>>
>>>>>>> From: Sricharan R <r.sricharan at ti.com>
>>>>>>>
>>>>>>> The current phys_to_virt patching mechanism does not work
>>>>>>> for 64 bit physical addressesp. Note that constant used in add/sub
>>>>>>> instructions is encoded in to the last 8 bits of the opcode. So shift
>>>>>>> the _pv_offset constant by 24 to get it in to the correct place.
>>>>>>>
>>>>>>> The v2p patching mechanism patches the higher 32bits of physical
>>>>>>> address with a constant. While this is correct, in those platforms
>>>>>>> where the lowmem addressable physical memory spawns across 4GB boundary,
>>>>>>> a carry bit can be produced as a result of addition of lower 32bits.
>>>>>>> This has to be taken in to account and added in to the upper. The patched
>>>>>>> __pv_offset and va are added in lower 32bits, where __pv_offset can be
>>>>>>> in two's complement form when PA_START < VA_START and that can result
>>>>>>> in a false carry bit.
>>>>>>>
>>>>>>> e.g PA = 0x80000000 VA = 0xC0000000
>>>>>>> __pv_offset = PA - VA = 0xC0000000 (2's complement)
>>>>>>>
>>>>>>> So adding __pv_offset + VA should never result in a true overflow. So in
>>>>>>> order to differentiate between a true carry, a extra flag __pv_sign_flag
>>>>>>> is introduced.
>>>>> First of all thanks for the review.
>>>>>  
>>>>>> I'm still wondering if this is worth bothering about.
>>>>>>
>>>>>> If PA = 0x80000000 and VA = 0xC0000000 there will never be a real carry 
>>>>>> to propagate to the high word of the physical address as the VA space 
>>>>>> cannot be larger than 0x40000000.
>>>>>>
>>>>> Agreed.
>>>>>
>>>>>> So is there really a case where:
>>>>>>
>>>>>> 1) physical memory is crossing the 4GB mark, and ...
>>>>>>
>>>>>> 2) physical memory start address is higher than virtual memory start 
>>>>>>    address needing a carry due to the 32-bit add overflow?
>>>>>>
>>>>> Consider below two cases of memory layout apart from one mentioned
>>>>> above where the carry is bit irrelevant as you rightly said.
>>>>>
>>>>> 1) PA = 0x8_0000_0000, VA= 0xC000_0000, absolute pv_offset = 0x7_4000_0000
>>>> This can be patched as:
>>>>
>>>> 	mov	phys_hi, #0x8
>>>> 	add	phys_lo, virt, #0x40000000  @ carry ignored
>>>>
>>>>> 2) PA = 0x2_8000_0000, VA= 0xC000_000, absolute pv_offset = 0x1_C000_0000
>>>> 	mov	phys_hi, #0x2
>>>> 	add	phys_lo, virt, #0xc0000000  @ carry ignored
>>>>
>>>>> In both of these cases there a true carry which needs to be
>>>>> considered.
>>>> Well, not really.  However, if you have:
>>>>
>>>> 3) PA = 0x2_8000_0000, VA = 0x4000-0000, pv_offset = 0x2-4000-0000
>>>>
>>>> ... then you need:
>>>>
>>>> 	mov	phys_hi, #0x2
>>>> 	adds	phys_lo, virt, #0x40000000
>>>> 	adc	phys_hi, phys_hi, #0
>>>>
>>>> My question is: how likely is this?
>>>>
>>>> What is your actual physical memory start address?
>>>  Agreed.  In our case we do not have the Physical address crossing across
>>>   4GB. So ignoring the carry would have be been OK. But we are
>>>  also addressing the other case where it would really crossover.
>>>
>>>> If we really need to cope with the carry, then the __pv_sign_flag should 
>>>> instead be represented in pv_offset directly:
>>>>
>>>> Taking example #2 above, that would be:
>>>>
>>>> 	mov	phys_hi, #0x1
>>>> 	adds	phys_lo, virt, #0xc0000000
>>>> 	adc	phys_hi, phys_hi, #0
>>>>
>>>> If PA = 0x8000-0000 and VA = 0xc000-0000 then pv_offset is 
>>>> 0xffff-ffff-c000-0000, meaning:
>>>>
>>>> 	mvn	phys_hi, #0
>>>> 	add	phys_lo, virt, #0xc0000000
>>>> 	adc	phys_hi, phys_hi, #0
>>>>
>>>> So that would require a special case in the patching code where a mvn 
>>>> with 0 is used if the high part of pv_offset is 0xffffffff.
>>>>
>>>>
>>>> Nicolas
>>> Extending pv_offset to 64bit is really neat way. When PA > VA, then pv_offset
>>> is going to be actual value and not 2's complement. Fine here.
>>> When running from higher physical address space, we will always fall here.
>>>
>>> So for the second case where pv_offset is 0xffffffff .., (PA < VA)
>>> is a problem only when we run from lower physical address. So we can safely
>>> assume that the higher 32bits of PA are '0' and stub it initially. In this way we
>>> can avoid the special case.
>>    Sorry, I missed one more point here. In the second case,we should patch it with
>>    0x0 when (PA > VA) and with 0xffffffff when (PA < VA).
> I don't think I follow you here.
>
> Let's assume:
>
> phys_addr_t __pv_offset = PHYS_START - VIRT_START;
>
> If PA = 0x0-8000-0000 and VA = 0xc000-0000 then
> __pv_offset = 0xffff-ffff-c000-0000.
>
> If PA = 0x2-8000-0000 and VA = 0xc000-0000 then
> __pv_offset = 0x1-c000-0000.
>
> So the __virt_to_phys() assembly stub could look like:
>
> static inline phys_addr_t __virt_to_phys(unsigned long x)
> {
> 	phys_addr_t t;
>
> 	if if (sizeof(phys_addr_t) == 4) {
> 		__pv_stub(x, t, "add", __PV_BITS_31_24);
> 	} else {
> 		__pv_movhi_stub(t);
> 		__pv_add_carry_stub(x, t);
> 	}
>
> 	return t;
> }
>
> And...
>
> #define __pv_movhi_stub(y) \
> 	__asm__("@ __pv_movhi_stub\n" \
> 	"1:	mov	%R0, %1\n" \
> 	"	.pushsection .pv_table,\"a\"\n" \
> 	"	.long	1b\n" \
> 	"	.popsection\n" \
> 	: "=r" (y) \
> 	: "I" (__PV_BITS_8_0))
>
> #define __pv_add_carry_stub(x, y) \
> 	__asm__("@ __pv_add_carry_stub\n" \
> 	"1:	adds	%Q0, %1, %2\n" \
> 	"	adc	%R0, %R0, #0\n" \
> 	"	.pushsection .pv_table,\"a\"\n" \
> 	"	.long	1b\n" \
> 	"	.popsection\n" \
> 	: "+r" (y) \
> 	: "r" (x), "I" (__PV_BITS_31_24) \
> 	: "cc")
>
> The stub bits such as __PV_BITS_8_0 can be augmented with more bits in 
> the middle to determine the type of fixup needed.  The fixup code would 
> determine the shift needed on the value, and whether or not the low or 
> high word of __pv_offset should be used according to those bits.
>
> Then, in the case where a mov is patched, you need to check if the high 
> word of __pv_offset is 0xffffffff and if so the mov should be turned 
> into a "mvn rn, #0".
>
> And there you are with all possible cases handled.
>
>
> Nicolas
  Thanks and you have given the full details here.

  Sorry if i was not clear on my previous response.

 1)  When i said special case can be avoided, i meant that
      we need not differentiate the 0xfffffff case inside the
      __virt_to_phy macro, but can handle it at the time of patching.
      Your above code makes that clear.
 
 2) I would have ended creating separate tables for 'mov' and 'add'
      case. But again thanks to your above idea of augumenting the
      __PV_BITS, with which we can find out run time. And 'mvn' would
      be needed for moving '0xffffffff' . Now I can get rid
     of the separate section that i created for 'mov' in my previous
     version.

     I will make the above suggestions and come back.

Regards,
 Sricharan



From marex at denx.de  Wed Jul 24 23:57:44 2013
From: marex at denx.de (Marek Vasut)
Date: Thu, 25 Jul 2013 05:57:44 +0200
Subject: Enabling USBH1 on mx53qsb
In-Reply-To: <CAOMZO5DYztMXpF33TLfGkvk3+SUa2_6oPNhupaAx6kxYwavStA@mail.gmail.com>
References: <CAOMZO5CAdxzn-3Xc2DZDYEXwsEznRrcqPbCbTDc5ieBkQkA8=g@mail.gmail.com>
 <20130725033716.GB4489@nchen-desktop>
 <CAOMZO5DYztMXpF33TLfGkvk3+SUa2_6oPNhupaAx6kxYwavStA@mail.gmail.com>
Message-ID: <201307250557.44651.marex@denx.de>

Dear Fabio Estevam,

> On Thu, Jul 25, 2013 at 12:37 AM, Peter Chen <peter.chen at freescale.com> wrote:
> > seems u-boot already support mx53.
> > 
> > Can you measure the host 1 vbus pin? The vbus should be 5v to let
> > the host works normal.
> 
> The VBUS is the same for both USBH1 port and OTG ports and it is at
> 5V, since OTG port does work.

Check either VBUS or clock, it's one of those ;-)

Best regards,
Marek Vasut


From chander.kashyap at linaro.org  Thu Jul 25 00:09:00 2013
From: chander.kashyap at linaro.org (Chander Kashyap)
Date: Thu, 25 Jul 2013 09:39:00 +0530
Subject: [PATCH] arm: l2x0: add support for prefetch and pwr control
 register configuration
In-Reply-To: <20130723102212.GD4833@e106331-lin.cambridge.arm.com>
References: <1374572345-5763-1-git-send-email-chander.kashyap@linaro.org>
 <20130723102212.GD4833@e106331-lin.cambridge.arm.com>
Message-ID: <CANuQgHGAn9PjSMG37dP=QmzNHx3F=u-+Mmgmdv=sEVf9-e0beQ@mail.gmail.com>

On 23 July 2013 15:52, Mark Rutland <mark.rutland at arm.com> wrote:
> Hi,
>
> [adding Rob Herring to Cc]
>
> On Tue, Jul 23, 2013 at 10:39:05AM +0100, Chander Kashyap wrote:
>> This patch adds support to configure prefetch and pwr control registers
>> of pl310 cache controllor.
>>
>> Signed-off-by: Chander Kashyap <chander.kashyap at linaro.org>
>> ---
>>  Documentation/devicetree/bindings/arm/l2cc.txt |    6 ++++
>>  arch/arm/include/asm/hardware/cache-l2x0.h     |   23 +++++++++++++
>>  arch/arm/mm/cache-l2x0.c                       |   44 ++++++++++++++++++++++++
>>  3 files changed, 73 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
>> index cbef09b..66876b6 100644
>> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
>> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
>> @@ -34,6 +34,12 @@ Optional properties:
>>  - arm,filter-ranges : <start length> Starting address and length of window to
>>    filter. Addresses in the filter window are directed to the M1 port. Other
>>    addresses will go to the M0 port.
>> +- arm,prefetch-control : Prefetch related configurations. Specifies 8 cells of
>> +  prefetch-offset, not-same-ID-on-exclusive-sequence-en, incr-double-Linefill-en,
>> +  prefetch-drop-en, data-prefetch-en, instruction-prefetch-en and
>> +  double-linefill-en.
>
> This looks like configuration rather than hardware specification.
>
> Is there any reason we couldn't have Linux configure this itself? I'm
> not sure having a fixed configuration of these values makes sense - the
> configuration values could interact badly with future changes to Linux
> (e.g. performance improvements or errata workarounds), and then we'd
> have to ignore the described values and/or decide on more suitable ones
> dynamically anyway.
>
> I assume that these cells are meant to either be zero or one? If they're
> necessary, they should be separate boolean properties rather than
> grouped together by the register they're configured by (see the way
> arm,tag-latency and arm,data-latency are handled).
>

prefetch-offset is not boolean. Its configurable and can have different values.
I am extracting the values in same way data-latency and tag-latency
values are handled. Only extra thing i am doing is clubbing into
single variable before writing in order to preserve the reserved
values.

> Also, I'd prefer "-enable" to "-en".
ok
>
>> +- arm,pwr-control : Operting mode clock and power mode selection. Specifies two
>
> s/Operting/Operating/

Ok

>
> I'd prefer "power" to "pwr" (though there's precedent for both in
> bindings...).
>
>> +  cells of standby-mode-en and dynamic_clk_gating_en.
>
> More boolean properties.
>
>>  - interrupts : 1 combined interrupt.
>>  - cache-id-part: cache id part number to be used if it is not present
>>    on hardware
>
> No amendments to the example?

thanks for pointing. I will add the same.

>
>> diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
>> index 3b2c40b..188f4da 100644
>> --- a/arch/arm/include/asm/hardware/cache-l2x0.h
>> +++ b/arch/arm/include/asm/hardware/cache-l2x0.h
>> @@ -106,6 +106,29 @@
>>
>>  #define L2X0_WAY_SIZE_SHIFT          3
>>
>> +#define L2X0_PREFETCH_CTRL_OFFSET_SHIFT                      0
>> +#define L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT         21
>> +#define L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT 23
>> +#define L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT               24
>> +#define L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT  27
>> +#define L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT    28
>> +#define L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT   29
>> +#define L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT  30
>> +
>> +#define PREFETCH_R2P0_MASK   (~(1 << L2X0_PREFETCH_CTRL_OFFSET_SHIFT))
>> +#define PREFETCH_R3P0_MASK \
>> +             (~((1 << L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT) | \
>> +                (1 << L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT) | \
>> +                (1 << L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT) | \
>> +                (1 << L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT) | \
>> +                (1 << L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT) | \
>> +                (1 << L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT)))
>> +#define PREFETCH_R3P1_MASK \
>> +             (~(1 << L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT))
>> +
>> +#define L2X0_PWR_CTRL_STANDBY_MODE_EN_SHIFT  0
>> +#define L2X0_PWR_CTRL_DYNAMIC_CLK_GATE_EN_SHIFT      1
>> +
>>  #ifndef __ASSEMBLY__
>>  extern void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask);
>>  #if defined(CONFIG_CACHE_L2X0) && defined(CONFIG_OF)
>> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
>> index c465fac..490e182 100644
>> --- a/arch/arm/mm/cache-l2x0.c
>> +++ b/arch/arm/mm/cache-l2x0.c
>> @@ -563,6 +563,11 @@ static void __init pl310_of_setup(const struct device_node *np,
>>       u32 data[3] = { 0, 0, 0 };
>>       u32 tag[3] = { 0, 0, 0 };
>>       u32 filter[2] = { 0, 0 };
>> +     u32 prefetch[8] = { 0, 0, 0, 0, 0, 0, 0, 0 };
>> +     u32 prefetch_val;
>> +     u32 pwr[2] = { 0, 0 };
>> +     u32 l2x0_revision = readl_relaxed(l2x0_base + L2X0_CACHE_ID) &
>> +             L2X0_CACHE_ID_RTL_MASK;
>>
>>       of_property_read_u32_array(np, "arm,tag-latency", tag, ARRAY_SIZE(tag));
>>       if (tag[0] && tag[1] && tag[2])
>> @@ -589,6 +594,45 @@ static void __init pl310_of_setup(const struct device_node *np,
>>               writel_relaxed((filter[0] & ~(SZ_1M - 1)) | L2X0_ADDR_FILTER_EN,
>>                              l2x0_base + L2X0_ADDR_FILTER_START);
>>       }
>> +
>> +     if (l2x0_revision >= L2X0_CACHE_ID_RTL_R2P0) {
>
> You didn't describe that some properties were dependent on a particular
> revision.

I will add the description.

>
>> +             of_property_read_u32_array(np, "arm,prefetch-control",
>> +                                             prefetch, ARRAY_SIZE(prefetch));
>> +             prefetch_val = readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
>> +             prefetch_val &= PREFETCH_R2P0_MASK;
>> +             prefetch_val |= prefetch[0] << L2X0_PREFETCH_CTRL_OFFSET_SHIFT;
>> +             if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P0) {
>> +                     prefetch_val &= PREFETCH_R3P0_MASK;
>> +                     prefetch_val |=
>> +                      ((prefetch[1]) <<
>> +                        L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT) |
>> +                      ((prefetch[2]) <<
>> +                        L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT) |
>> +                      ((prefetch[3]) <<
>> +                        L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT) |
>> +                      ((prefetch[5]) <<
>> +                        L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT) |
>> +                      ((prefetch[6]) <<
>> +                        L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT) |
>> +                      ((prefetch[7]) <<
>> +                        L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT);
>
> You've not sanity checked these properties. What If I typo a value as
> something other than 0 or 1?

I was simply extending the driver, by keeping in mind the existing convention.

>
> Use boolean properties and of_property_read_bool (or even better,
> configure this dynamically based on revision rather than having a dt
> description).

As prefetch-offset is not boolean, hence gathered in array.

>
>> +                     if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P1) {
>> +                             prefetch_val &= PREFETCH_R3P1_MASK;
>> +                             prefetch_val |=
>> +                              ((prefetch[4]) <<
>> +                                L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT);
>> +                     }
>
> Another undocumented revision dependency.

Will add documentation.

>
>> +                     writel_relaxed(prefetch_val,
>> +                                     l2x0_base + L2X0_PREFETCH_CTRL);
>> +
>> +                     of_property_read_u32_array(np, "arm,pwr-control",
>> +                                             pwr, ARRAY_SIZE(pwr));
>> +                     writel_relaxed(
>> +                      ((pwr[0]) << L2X0_PWR_CTRL_STANDBY_MODE_EN_SHIFT) |
>> +                      ((pwr[1]) << L2X0_PWR_CTRL_DYNAMIC_CLK_GATE_EN_SHIFT),
>> +                        l2x0_base + L2X0_POWER_CTRL);
>
> Again, use boolean properties or do this dynamically.
>
> Do none of these values need to be saved for the resume callback?

They are already getting saved in "pl310_save" function and resumed in
pl310_resume function

> Thanks,
> Mark.
>
>> +             }
>> +     }
>>  }
>>
>>  static void __init pl310_save(void)
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>

Thanks for reviewing it.


-- 
with warm regards,
Chander Kashyap


From chander.kashyap at linaro.org  Thu Jul 25 00:11:53 2013
From: chander.kashyap at linaro.org (Chander Kashyap)
Date: Thu, 25 Jul 2013 09:41:53 +0530
Subject: [PATCH] arm: l2x0: add support for prefetch and pwr control
 register configuration
In-Reply-To: <51EE8183.9010703@gmail.com>
References: <1374572345-5763-1-git-send-email-chander.kashyap@linaro.org>
 <20130723102212.GD4833@e106331-lin.cambridge.arm.com>
 <51EE8183.9010703@gmail.com>
Message-ID: <CANuQgHE2rEDCwP8tHhUFF442Nqa9Gyqa6gii-jQDTEUVdEYwcA@mail.gmail.com>

On 23 July 2013 18:43, Rob Herring <robherring2 at gmail.com> wrote:
> On 07/23/2013 05:22 AM, Mark Rutland wrote:
>> Hi,
>>
>> [adding Rob Herring to Cc]
>
> Thanks.
>
>> On Tue, Jul 23, 2013 at 10:39:05AM +0100, Chander Kashyap wrote:
>>> This patch adds support to configure prefetch and pwr control registers
>>> of pl310 cache controllor.
>>>
>>> Signed-off-by: Chander Kashyap <chander.kashyap at linaro.org>
>>> ---
>>>  Documentation/devicetree/bindings/arm/l2cc.txt |    6 ++++
>>>  arch/arm/include/asm/hardware/cache-l2x0.h     |   23 +++++++++++++
>>>  arch/arm/mm/cache-l2x0.c                       |   44 ++++++++++++++++++++++++
>>>  3 files changed, 73 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
>>> index cbef09b..66876b6 100644
>>> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
>>> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
>>> @@ -34,6 +34,12 @@ Optional properties:
>>>  - arm,filter-ranges : <start length> Starting address and length of window to
>>>    filter. Addresses in the filter window are directed to the M1 port. Other
>>>    addresses will go to the M0 port.
>>> +- arm,prefetch-control : Prefetch related configurations. Specifies 8 cells of
>>> +  prefetch-offset, not-same-ID-on-exclusive-sequence-en, incr-double-Linefill-en,
>>> +  prefetch-drop-en, data-prefetch-en, instruction-prefetch-en and
>>> +  double-linefill-en.
>>
>> This looks like configuration rather than hardware specification.
>
> I think weigh whether this is configuration based on the h/w or just
> user preference. This would be the former, but...
>
>> Is there any reason we couldn't have Linux configure this itself? I'm
>> not sure having a fixed configuration of these values makes sense - the
>> configuration values could interact badly with future changes to Linux
>> (e.g. performance improvements or errata workarounds), and then we'd
>> have to ignore the described values and/or decide on more suitable ones
>> dynamically anyway.
>
> Does having a variable configuration for these make sense either? I mean
> other than an errata work-around, why would you ever turn off prefetch
> or double linefill?
>
> None of these fields can be set in NS world. We've already laid down the
> law in regards to setting secure only bits for errata work-arounds. I
> think this is no different and we should move towards the kernel doesn't
> touch aux ctrl at all. There might be an exception with the event bus
> enable, but you would still have the secure vs. non-secure issue and no
> way to detect that.

So what is the suggestion here. Not to touch the prefetch register at all.
But prefetch register values are saved and resumed in existing code,
how to take care for that.

>
> Rob
>
>>
>> I assume that these cells are meant to either be zero or one? If they're
>> necessary, they should be separate boolean properties rather than
>> grouped together by the register they're configured by (see the way
>> arm,tag-latency and arm,data-latency are handled).
>>
>> Also, I'd prefer "-enable" to "-en".
>>
>>> +- arm,pwr-control : Operting mode clock and power mode selection. Specifies two
>>
>> s/Operting/Operating/
>>
>> I'd prefer "power" to "pwr" (though there's precedent for both in
>> bindings...).
>>
>>> +  cells of standby-mode-en and dynamic_clk_gating_en.
>>
>> More boolean properties.
>>
>>>  - interrupts : 1 combined interrupt.
>>>  - cache-id-part: cache id part number to be used if it is not present
>>>    on hardware
>>
>> No amendments to the example?
>>
>>> diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
>>> index 3b2c40b..188f4da 100644
>>> --- a/arch/arm/include/asm/hardware/cache-l2x0.h
>>> +++ b/arch/arm/include/asm/hardware/cache-l2x0.h
>>> @@ -106,6 +106,29 @@
>>>
>>>  #define L2X0_WAY_SIZE_SHIFT         3
>>>
>>> +#define L2X0_PREFETCH_CTRL_OFFSET_SHIFT                     0
>>> +#define L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT                21
>>> +#define L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT        23
>>> +#define L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT              24
>>> +#define L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT 27
>>> +#define L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT   28
>>> +#define L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT  29
>>> +#define L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT 30
>>> +
>>> +#define PREFETCH_R2P0_MASK  (~(1 << L2X0_PREFETCH_CTRL_OFFSET_SHIFT))
>>> +#define PREFETCH_R3P0_MASK \
>>> +            (~((1 << L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT) | \
>>> +               (1 << L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT) | \
>>> +               (1 << L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT) | \
>>> +               (1 << L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT) | \
>>> +               (1 << L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT) | \
>>> +               (1 << L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT)))
>>> +#define PREFETCH_R3P1_MASK \
>>> +            (~(1 << L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT))
>>> +
>>> +#define L2X0_PWR_CTRL_STANDBY_MODE_EN_SHIFT 0
>>> +#define L2X0_PWR_CTRL_DYNAMIC_CLK_GATE_EN_SHIFT     1
>>> +
>>>  #ifndef __ASSEMBLY__
>>>  extern void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask);
>>>  #if defined(CONFIG_CACHE_L2X0) && defined(CONFIG_OF)
>>> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
>>> index c465fac..490e182 100644
>>> --- a/arch/arm/mm/cache-l2x0.c
>>> +++ b/arch/arm/mm/cache-l2x0.c
>>> @@ -563,6 +563,11 @@ static void __init pl310_of_setup(const struct device_node *np,
>>>      u32 data[3] = { 0, 0, 0 };
>>>      u32 tag[3] = { 0, 0, 0 };
>>>      u32 filter[2] = { 0, 0 };
>>> +    u32 prefetch[8] = { 0, 0, 0, 0, 0, 0, 0, 0 };
>>> +    u32 prefetch_val;
>>> +    u32 pwr[2] = { 0, 0 };
>>> +    u32 l2x0_revision = readl_relaxed(l2x0_base + L2X0_CACHE_ID) &
>>> +            L2X0_CACHE_ID_RTL_MASK;
>>>
>>>      of_property_read_u32_array(np, "arm,tag-latency", tag, ARRAY_SIZE(tag));
>>>      if (tag[0] && tag[1] && tag[2])
>>> @@ -589,6 +594,45 @@ static void __init pl310_of_setup(const struct device_node *np,
>>>              writel_relaxed((filter[0] & ~(SZ_1M - 1)) | L2X0_ADDR_FILTER_EN,
>>>                             l2x0_base + L2X0_ADDR_FILTER_START);
>>>      }
>>> +
>>> +    if (l2x0_revision >= L2X0_CACHE_ID_RTL_R2P0) {
>>
>> You didn't describe that some properties were dependent on a particular
>> revision.
>>
>>> +            of_property_read_u32_array(np, "arm,prefetch-control",
>>> +                                            prefetch, ARRAY_SIZE(prefetch));
>>> +            prefetch_val = readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
>>> +            prefetch_val &= PREFETCH_R2P0_MASK;
>>> +            prefetch_val |= prefetch[0] << L2X0_PREFETCH_CTRL_OFFSET_SHIFT;
>>> +            if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P0) {
>>> +                    prefetch_val &= PREFETCH_R3P0_MASK;
>>> +                    prefetch_val |=
>>> +                     ((prefetch[1]) <<
>>> +                       L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT) |
>>> +                     ((prefetch[2]) <<
>>> +                       L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT) |
>>> +                     ((prefetch[3]) <<
>>> +                       L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT) |
>>> +                     ((prefetch[5]) <<
>>> +                       L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT) |
>>> +                     ((prefetch[6]) <<
>>> +                       L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT) |
>>> +                     ((prefetch[7]) <<
>>> +                       L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT);
>>
>> You've not sanity checked these properties. What If I typo a value as
>> something other than 0 or 1?
>>
>> Use boolean properties and of_property_read_bool (or even better,
>> configure this dynamically based on revision rather than having a dt
>> description).
>>
>>> +                    if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P1) {
>>> +                            prefetch_val &= PREFETCH_R3P1_MASK;
>>> +                            prefetch_val |=
>>> +                             ((prefetch[4]) <<
>>> +                               L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT);
>>> +                    }
>>
>> Another undocumented revision dependency.
>>
>>> +                    writel_relaxed(prefetch_val,
>>> +                                    l2x0_base + L2X0_PREFETCH_CTRL);
>>> +
>>> +                    of_property_read_u32_array(np, "arm,pwr-control",
>>> +                                            pwr, ARRAY_SIZE(pwr));
>>> +                    writel_relaxed(
>>> +                     ((pwr[0]) << L2X0_PWR_CTRL_STANDBY_MODE_EN_SHIFT) |
>>> +                     ((pwr[1]) << L2X0_PWR_CTRL_DYNAMIC_CLK_GATE_EN_SHIFT),
>>> +                       l2x0_base + L2X0_POWER_CTRL);
>>
>> Again, use boolean properties or do this dynamically.
>>
>> Do none of these values need to be saved for the resume callback?
>>
>> Thanks,
>> Mark.
>>
>>> +            }
>>> +    }
>>>  }
>>>
>>>  static void __init pl310_save(void)
>>> --
>>> 1.7.9.5
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>

thanks for reviewing.

-- 
with warm regards,
Chander Kashyap


From grant.likely at linaro.org  Wed Jul 24 16:24:46 2013
From: grant.likely at linaro.org (Grant Likely)
Date: Wed, 24 Jul 2013 21:24:46 +0100
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <1624911.6TtmtVmU1T@avalon>
References: <1624911.6TtmtVmU1T@avalon>
Message-ID: <20130724202446.6CAF23E1313@localhost>

On Wed, 24 Jul 2013 01:21:44 +0200, Laurent Pinchart <laurent.pinchart at ideasonboard.com> wrote:
> Hello,
> 
> I'm running into an issue on several Renesas SoC with IRQ domains and GPIOs.
> 
> On sh73a0, r8a73a4 and r8a7740, GPIOs and external interrupts are handled by 
> two separate IP cores, namely the PFC (Pin Function Controller) and INTC 
> (Interrupt Controller). The former is handled by the sh-pfc driver 
> (drivers/pinctrl/sh-pfc) and the later by the irq-renesas-intc-irqpin driver 
> (drivers/irqchip), referred to below as the irqpin driver.
> 
> The sh73a0, for instance, has 32 external interrupt lines that are multiplexed 
> on pins usable as GPIOs. Both the GPIO and external interrupt functions are 
> usable at the same time, which allows reading the state of the interrupt 
> lines.
> 
> These external interrupts are for MMC/SD support, among other devices. In this 
> specific case the MMC/SD Card Detect signal is wired to one of the external 
> interrupt signals, and the corresponding GPIO is passed to the MMC/SD 
> controller driver. Depending on other configuration parameters the driver can 
> then either poll the Card Detect signal, or register an interrupt handler to 
> detect changes in the signal state. This features is implemented by the MMC/SD 
> core, which call gpio_to_irq() on the GPIO to retrieve the corresponding IRQ 
> number.
> 
> On non-DT systems the external IRQs are statically mapped at a known offset. 
> The sh-pfc driver, to implement the gpio_to_irq() function (through its 
> gpiochip .to_irq() handler), simply searches a SoC-specific lookup table for 
> the fixed IRQ number associated with a given GPIO.
> 
> However, on DT systems, IRQs are mapped dynamically on demand. The irqpin 
> driver registers a simple IRQ domain, and the irq_create_mapping() function 
> can then be used to map a given IRQ, specified as an offset in the domain. 
> This is where the problem appears, as the irqchip .to_irq() function is 
> implemented in the sh-pfc driver, which doesn't have access to the IRQ domain 
> registered by the irqpin driver.
> 
> I could hack around this by exporting a function in the irqpin driver that 
> would map an IRQ, and call that function from the sh-pfc driver. I'd rather 
> avoid that solution as it would add a direct dependency between the two 
> drivers.

Well, the gpio controller really does need to know what irq is
associated with a GPIO line. If the gpio controller driver doesn't have
direct access to that information, then it needs to have a hook to set
it up.

In the past, I've seen gpio controllers have an interrupts property
specifying which interrupts it is connected to and can use for GPIO
events. That seems like a resonable scenario in this regard, but if
GPIOS are 1:1 mapped to irqs, then it means a lot of interrupt entries
need to appear in the GPIO node. The other option is to add a hook
directly to the gpio driver so that it knows to use a specific irq
controller; but that feels wrong. Thought it may be a bit verbose, the
addition of an interrupts property to the GPIO controller node is
probably what is wanted.

There has also been a trend to make gpio controllers also interrupt
controllers if they support being used directly as irq inputs, but that
doesn't really help your problem.  :-)

g.


From rahul.sharma at samsung.com  Thu Jul 25 01:07:32 2013
From: rahul.sharma at samsung.com (Rahul Sharma)
Date: Thu, 25 Jul 2013 10:37:32 +0530
Subject: [PATCH v4 1/6] clk/exynos5250: Fix HDMI clock number in documentation
In-Reply-To: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
References: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
Message-ID: <1374728857-4208-2-git-send-email-rahul.sharma@samsung.com>

From: Arun Kumar K <arun.kk at samsung.com>

This patch corrects the HDMI clock number given wrongly
in the documentation.

Signed-off-by: Arun Kumar K <arun.kk at samsung.com>
Signed-off-by: Rahul Sharma <rahul.sharma at samsung.com>
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 781a627..1a05761 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -154,7 +154,7 @@ clock which they consume.
   dsim0			341
   dp			342
   mixer			343
-  hdmi			345
+  hdmi			344
 
 Example 1: An example of a clock controller node is listed below.
 
-- 
1.7.10.4



From rahul.sharma at samsung.com  Thu Jul 25 01:07:31 2013
From: rahul.sharma at samsung.com (Rahul Sharma)
Date: Thu, 25 Jul 2013 10:37:31 +0530
Subject: [PATCH v4 0/6] clk/exynos5250: add clocks for hdmi subsystem
Message-ID: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>

Add clock changes for hdmi subsystem for exynos5250 SoC. These
include addition of new clocks like mout_hdmi and smmu_tv, associating
ID to clk_hdmiphy and some essential corrections.

This set is based on kukjin's for-next branch at
http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.

V4:
1) Added Arun's patch hdmi clock number correction in this series.
2) Corrected clock number for smmu_mixer

V3:
1) Rebase to kgene for-next based on 3.11-rc1.
2) Added Tushar's patch in the series.

V2:
1) Dropped "clk/exynos5250: Fix HDMI clock number in documentation" as
it already get merged.

Arun Kumar K (1):
  clk/exynos5250: Fix HDMI clock number in documentation

Rahul Sharma (4):
  clk/exynos5250: add mout_hdmi mux clock for hdmi
  clk/exynos5250: add sclk_hdmiphy in the list of special clocks
  clk/exynos5250: add clock for mixer sysmmu
  clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem

Tushar Behera (1):
  Documentation: exynos5250-clock: Add div_i2s1 and div_i2s2

 .../devicetree/bindings/clock/exynos5250-clock.txt |   14 +++++++++++++-
 drivers/clk/samsung/clk-exynos5250.c               |   20 ++++++++++++++------
 2 files changed, 27 insertions(+), 7 deletions(-)

-- 
1.7.10.4



From rahul.sharma at samsung.com  Thu Jul 25 01:07:33 2013
From: rahul.sharma at samsung.com (Rahul Sharma)
Date: Thu, 25 Jul 2013 10:37:33 +0530
Subject: [PATCH v4 2/6] Documentation: exynos5250-clock: Add div_i2s1 and
 div_i2s2
In-Reply-To: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
References: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
Message-ID: <1374728857-4208-3-git-send-email-rahul.sharma@samsung.com>

From: Tushar Behera <tushar.behera at linaro.org>

commit 79d743c177f9 ("clk: exynos5250: Add enum entries for divider
clock of i2s1 and i2s2") added two new clock entries. Add the clock
entry enum numbers to documentation.

Signed-off-by: Tushar Behera <tushar.behera at linaro.org>
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 1a05761..bea503f 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -59,6 +59,8 @@ clock which they consume.
   sclk_spi0		154
   sclk_spi1		155
   sclk_spi2		156
+  div_i2s1		157
+  div_i2s2		158
 
 
    [Peripheral Clock Gates]
-- 
1.7.10.4



From rahul.sharma at samsung.com  Thu Jul 25 01:07:34 2013
From: rahul.sharma at samsung.com (Rahul Sharma)
Date: Thu, 25 Jul 2013 10:37:34 +0530
Subject: [PATCH v4 3/6] clk/exynos5250: add mout_hdmi mux clock for hdmi
In-Reply-To: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
References: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
Message-ID: <1374728857-4208-4-git-send-email-rahul.sharma@samsung.com>

hdmi driver needs to change the parent of hdmi clock
frequently between pixel clock and hdmiphy clock. hdmiphy is
not stable after power on and for a short interval while changing
the phy configuration. For this duration pixel clock is used to
clock hdmi.

This patch is exposing the mux for changing parent.

Signed-off-by: Rahul Sharma <rahul.sharma at samsung.com>
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |    8 ++++++++
 drivers/clk/samsung/clk-exynos5250.c                         |    5 ++++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index bea503f..b3dfcad 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -158,6 +158,14 @@ clock which they consume.
   mixer			343
   hdmi			344
 
+
+   [Clock Muxes]
+
+  Clock			ID
+  ----------------------------
+  mout_hdmi		1024
+
+
 Example 1: An example of a clock controller node is listed below.
 
 	clock: clock-controller at 0x10010000 {
diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index 6f767c5..df44419 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -101,6 +101,9 @@ enum exynos5250_clks {
 	tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
 	wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
 
+	/* mux clocks */
+	mout_hdmi = 1024,
+
 	nr_clks,
 };
 
@@ -232,7 +235,7 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata = {
 	MUX(none, "mout_fimd1", mout_group1_p, SRC_DISP1_0, 0, 4),
 	MUX(none, "mout_mipi1", mout_group1_p, SRC_DISP1_0, 12, 4),
 	MUX(none, "mout_dp", mout_group1_p, SRC_DISP1_0, 16, 4),
-	MUX(none, "mout_hdmi", mout_hdmi_p, SRC_DISP1_0, 20, 1),
+	MUX(mout_hdmi, "mout_hdmi", mout_hdmi_p, SRC_DISP1_0, 20, 1),
 	MUX(none, "mout_audio0", mout_audio0_p, SRC_MAU, 0, 4),
 	MUX(none, "mout_mmc0", mout_group1_p, SRC_FSYS, 0, 4),
 	MUX(none, "mout_mmc1", mout_group1_p, SRC_FSYS, 4, 4),
-- 
1.7.10.4



From rahul.sharma at samsung.com  Thu Jul 25 01:07:37 2013
From: rahul.sharma at samsung.com (Rahul Sharma)
Date: Thu, 25 Jul 2013 10:37:37 +0530
Subject: [PATCH v4 6/6] clk/exynos5250: change parent to aclk200_disp1 for hdmi
 subsystem
In-Reply-To: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
References: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
Message-ID: <1374728857-4208-7-git-send-email-rahul.sharma@samsung.com>

parent of hdmi and mixer block is mentioned as aclk200 which is
not correct. It is clocked by the ouput of aclk200_disp1. Hence
parent for mixer and hdmi clocks is changed to aclk200_disp1.

Signed-off-by: Rahul Sharma <rahul.sharma at samsung.com>
---
 drivers/clk/samsung/clk-exynos5250.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index c727d9e..24a66b3 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -469,8 +469,8 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
 	GATE(mie1, "mie1", "aclk200", GATE_IP_DISP1, 1, 0, 0),
 	GATE(dsim0, "dsim0", "aclk200", GATE_IP_DISP1, 3, 0, 0),
 	GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
-	GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
-	GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
+	GATE(mixer, "mixer", "mout_aclk200_disp1", GATE_IP_DISP1, 5, 0, 0),
+	GATE(hdmi, "hdmi", "mout_aclk200_disp1", GATE_IP_DISP1, 6, 0, 0),
 };
 
 static __initdata struct of_device_id ext_clk_match[] = {
-- 
1.7.10.4



From rahul.sharma at samsung.com  Thu Jul 25 01:07:35 2013
From: rahul.sharma at samsung.com (Rahul Sharma)
Date: Thu, 25 Jul 2013 10:37:35 +0530
Subject: [PATCH v4 4/6] clk/exynos5250: add sclk_hdmiphy in the list of special
 clocks
In-Reply-To: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
References: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
Message-ID: <1374728857-4208-5-git-send-email-rahul.sharma@samsung.com>

hdmi driver needs hdmiphy clock which is one of the parent
for hdmi mux clock. This is required while changing the parent
of mux clock.

Signed-off-by: Rahul Sharma <rahul.sharma at samsung.com>

Conflicts:
	drivers/clk/samsung/clk-exynos5250.c
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |    1 +
 drivers/clk/samsung/clk-exynos5250.c                         |    4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index b3dfcad..a489b5a 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -61,6 +61,7 @@ clock which they consume.
   sclk_spi2		156
   div_i2s1		157
   div_i2s2		158
+  sclk_hdmiphy		159
 
 
    [Peripheral Clock Gates]
diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index df44419..9579cfe 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -87,7 +87,7 @@ enum exynos5250_clks {
 	sclk_mmc0, sclk_mmc1, sclk_mmc2, sclk_mmc3, sclk_sata, sclk_usb3,
 	sclk_jpeg, sclk_uart0, sclk_uart1, sclk_uart2, sclk_uart3, sclk_pwm,
 	sclk_audio1, sclk_audio2, sclk_spdif, sclk_spi0, sclk_spi1, sclk_spi2,
-	div_i2s1, div_i2s2,
+	div_i2s1, div_i2s2, sclk_hdmiphy,
 
 	/* gate clocks */
 	gscl0 = 256, gscl1, gscl2, gscl3, gscl_wa, gscl_wb, smmu_gscl0,
@@ -200,7 +200,7 @@ struct samsung_fixed_rate_clock exynos5250_fixed_rate_ext_clks[] __initdata = {
 
 /* fixed rate clocks generated inside the soc */
 struct samsung_fixed_rate_clock exynos5250_fixed_rate_clks[] __initdata = {
-	FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 24000000),
+	FRATE(sclk_hdmiphy, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 24000000),
 	FRATE(none, "sclk_hdmi27m", NULL, CLK_IS_ROOT, 27000000),
 	FRATE(none, "sclk_dptxphy", NULL, CLK_IS_ROOT, 24000000),
 	FRATE(none, "sclk_uhostphy", NULL, CLK_IS_ROOT, 48000000),
-- 
1.7.10.4



From rahul.sharma at samsung.com  Thu Jul 25 01:07:36 2013
From: rahul.sharma at samsung.com (Rahul Sharma)
Date: Thu, 25 Jul 2013 10:37:36 +0530
Subject: [PATCH v4 5/6] clk/exynos5250: add clock for mixer sysmmu
In-Reply-To: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
References: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
Message-ID: <1374728857-4208-6-git-send-email-rahul.sharma@samsung.com>

Adding sysmmu clock for mixer for exynos5250 SoC. It also
adds aclk200_disp1 mux which is the real parent of the
disp1 block (contains hdmi, mixer, sysmmu_mixer).

Signed-off-by: Rahul Sharma <rahul.sharma at samsung.com>
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |    1 +
 drivers/clk/samsung/clk-exynos5250.c                         |    7 ++++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index a489b5a..84e098f 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -158,6 +158,7 @@ clock which they consume.
   dp			342
   mixer			343
   hdmi			344
+  smmu_mixer		345
 
 
    [Clock Muxes]
diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index 9579cfe..c727d9e 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -24,6 +24,7 @@
 #define SRC_CORE1		0x4204
 #define SRC_TOP0		0x10210
 #define SRC_TOP2		0x10218
+#define SRC_TOP3		0x1021C
 #define SRC_GSCL		0x10220
 #define SRC_DISP1_0		0x1022c
 #define SRC_MAU			0x10240
@@ -99,7 +100,7 @@ enum exynos5250_clks {
 	spi2, i2s1, i2s2, pcm1, pcm2, pwm, spdif, ac97, hsi2c0, hsi2c1, hsi2c2,
 	hsi2c3, chipid, sysreg, pmu, cmu_top, cmu_core, cmu_mem, tzpc0, tzpc1,
 	tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
-	wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
+	wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, smmu_mixer,
 
 	/* mux clocks */
 	mout_hdmi = 1024,
@@ -172,6 +173,7 @@ PNAME(mout_mpll_user_p)	= { "fin_pll", "sclk_mpll" };
 PNAME(mout_bpll_user_p)	= { "fin_pll", "sclk_bpll" };
 PNAME(mout_aclk166_p)	= { "sclk_cpll", "sclk_mpll_user" };
 PNAME(mout_aclk200_p)	= { "sclk_mpll_user", "sclk_bpll_user" };
+PNAME(mout_aclk200_disp1_sub_p) = { "fin_pll", "aclk200" };
 PNAME(mout_hdmi_p)	= { "div_hdmi_pixel", "sclk_hdmiphy" };
 PNAME(mout_usb3_p)	= { "sclk_mpll_user", "sclk_cpll" };
 PNAME(mout_group1_p)	= { "fin_pll", "fin_pll", "sclk_hdmi27m",
@@ -227,6 +229,8 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata = {
 	MUX(none, "mout_aclk166", mout_aclk166_p, SRC_TOP0, 8, 1),
 	MUX(none, "mout_aclk333", mout_aclk166_p, SRC_TOP0, 16, 1),
 	MUX(none, "mout_aclk200", mout_aclk200_p, SRC_TOP0, 12, 1),
+	MUX(none, "mout_aclk200_disp1", mout_aclk200_disp1_sub_p,
+			SRC_TOP3, 4, 1),
 	MUX(none, "mout_cam_bayer", mout_group1_p, SRC_GSCL, 12, 4),
 	MUX(none, "mout_cam0", mout_group1_p, SRC_GSCL, 16, 4),
 	MUX(none, "mout_cam1", mout_group1_p, SRC_GSCL, 20, 4),
@@ -328,6 +332,7 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
 	GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
 	GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
 	GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
+	GATE(smmu_mixer, "smmu_mixer", "mout_aclk200_disp1", GATE_IP_DISP1, 9, 0, 0),
 	GATE(mfc, "mfc", "aclk333", GATE_IP_MFC, 0, 0, 0),
 	GATE(smmu_mfcl, "smmu_mfcl", "aclk333", GATE_IP_MFC, 1, 0, 0),
 	GATE(smmu_mfcr, "smmu_mfcr", "aclk333", GATE_IP_MFC, 2, 0, 0),
-- 
1.7.10.4



From kishon at ti.com  Thu Jul 25 01:11:15 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 25 Jul 2013 10:41:15 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <201307242032.03597.arnd@arndb.de>
References: <Pine.LNX.4.44L0.1307231708020.1304-100000@iolanthe.rowland.org>
 <5977067.8rykRgjgre@flatron> <201307242032.03597.arnd@arndb.de>
Message-ID: <51F0B373.5050907@ti.com>

Hi,

On Thursday 25 July 2013 12:02 AM, Arnd Bergmann wrote:
> On Tuesday 23 July 2013, Tomasz Figa wrote:
>> On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
>>> On Tue, 23 Jul 2013, Tomasz Figa wrote:
>>>> Where would you want to have those phy_address arrays stored? There
>>>> are no board files when booting with DT. Not even saying that you
>>>> don't need to use any hacky schemes like this when you have DT that
>>>> nicely specifies relations between devices.
>>>
>>> If everybody agrees DT has a nice scheme for specifying relations
>>> between devices, why not use that same scheme in the PHY core?
>>
>> It is already used, for cases when consumer device has a DT node attached. 
>> In non-DT case this kind lookup translates loosely to something that is 
>> being done in regulator framework - you can't bind devices by pointers, 
>> because you don't have those pointers, so you need to use device names.
>>
> 
> Sorry for jumping in to the middle of the discussion, but why does a *new*
> framework even bother defining an interface for board files?
> 
> Can't we just drop any interfaces for platform data passing in the phy
> framework and put the burden of adding those to anyone who actually needs
> them? All the platforms we are concerned with here (exynos and omap,
> plus new platforms) can be booted using DT anyway.

The OMAP3 platforms still needs to be supported for non-dt :-s

Thanks
Kishon


From horms at verge.net.au  Thu Jul 25 01:23:17 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 25 Jul 2013 14:23:17 +0900
Subject: Mainline kernel on snowball
Message-ID: <20130725052317.GA25854@verge.net.au>

Hi,

I apologise for the na?ve nature of this question,
but I do not seem to be able to make any progress of my own accord.

I would like to boot the mainline kernel - ideally v3.10 and v3.11-rcX -
on snowball. The reason being to verify CPU hotplug which
seems to be broken on shmobile, though that is tangential to this post.

My procedure, which does not work, is as follows.
I have tried a number of different versions all with roughly
the same result.

1. Build kernel
# git checkout v3.10.2 # I have tried several over versions too.
# make u8500_defconfig
Edit .config to enable CONFIG_ARM_APPENDED_DTB
# LOADADDR=0x100000 make uImage dtbs

2. Append dtb to zImage and recreate uImage
mv arch/arm/boot/zImage arch/arm/boot/zImage.tmp
cat arch/arm/boot/zImage.tmp arch/arm/boot/dts/snowball.dtb
/bin/sh scripts/mkuboot.sh \
	-A arm -O linux -C none  -T kernel \
	-a 0x100000 -e 0x100000 -n 'Linux-3.10.2' \
	-d arch/arm/boot/zImage arch/arm/boot/uImage

3. Boot uImage from u-boot
Snowball $ setenv ethaddr 3e:c4:73:05:d1:a1
Snowball $ bootp;bootm
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 3e:c4:73:05:d1:a1
BOOTP broadcast 1
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 44
DHCP client bound to address 10.3.3.146
Using smc911x-0 device
TFTP from server 10.3.3.135; our IP address is 10.3.3.146
Filename 'snowball/uImage'.
Load address: 0x100000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##########################################################
done
Bytes transferred = 2540191 (26c29f hex)
## Booting kernel from Legacy Image at 00100000 ...
   Image Name:   'Linux-3.10.2'
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2540127 Bytes =  2.4 MB
   Load Address: 00100000
   Entry Point:  00100000
   XIP Kernel Image ... OK
OK

Starting kernel ...




This is as far as it gets.


From w at 1wt.eu  Thu Jul 25 01:40:36 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 25 Jul 2013 07:40:36 +0200
Subject: Mainline kernel on snowball
In-Reply-To: <20130725052317.GA25854@verge.net.au>
References: <20130725052317.GA25854@verge.net.au>
Message-ID: <20130725054036.GD31954@1wt.eu>

Hi Simon,

On Thu, Jul 25, 2013 at 02:23:17PM +0900, Simon Horman wrote:
> Hi,
> 
> I apologise for the na?ve nature of this question,
> but I do not seem to be able to make any progress of my own accord.
> 
> I would like to boot the mainline kernel - ideally v3.10 and v3.11-rcX -
> on snowball. The reason being to verify CPU hotplug which
> seems to be broken on shmobile, though that is tangential to this post.
> 
> My procedure, which does not work, is as follows.
> I have tried a number of different versions all with roughly
> the same result.
> 
> 1. Build kernel
> # git checkout v3.10.2 # I have tried several over versions too.
> # make u8500_defconfig
> Edit .config to enable CONFIG_ARM_APPENDED_DTB
> # LOADADDR=0x100000 make uImage dtbs
> 
> 2. Append dtb to zImage and recreate uImage
> mv arch/arm/boot/zImage arch/arm/boot/zImage.tmp
> cat arch/arm/boot/zImage.tmp arch/arm/boot/dts/snowball.dtb
> /bin/sh scripts/mkuboot.sh \
> 	-A arm -O linux -C none  -T kernel \
> 	-a 0x100000 -e 0x100000 -n 'Linux-3.10.2' \
> 	-d arch/arm/boot/zImage arch/arm/boot/uImage
> 
> 3. Boot uImage from u-boot
> Snowball $ setenv ethaddr 3e:c4:73:05:d1:a1
> Snowball $ bootp;bootm
> smc911x: detected LAN9221 controller
> smc911x: phy initialized
> smc911x: MAC 3e:c4:73:05:d1:a1
> BOOTP broadcast 1
> *** Unhandled DHCP Option in OFFER/ACK: 28
> *** Unhandled DHCP Option in OFFER/ACK: 44
> *** Unhandled DHCP Option in OFFER/ACK: 28
> *** Unhandled DHCP Option in OFFER/ACK: 44
> DHCP client bound to address 10.3.3.146
> Using smc911x-0 device
> TFTP from server 10.3.3.135; our IP address is 10.3.3.146
> Filename 'snowball/uImage'.
> Load address: 0x100000
> Loading: #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          ##########################################################
> done
> Bytes transferred = 2540191 (26c29f hex)
> ## Booting kernel from Legacy Image at 00100000 ...
>    Image Name:   'Linux-3.10.2'
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    2540127 Bytes =  2.4 MB
>    Load Address: 00100000
>    Entry Point:  00100000
>    XIP Kernel Image ... OK
> OK
> 
> Starting kernel ...
> 
> 
> This is as far as it gets.

Are you sure you have the correct bootargs by default ? It was a
pain for me to figure the correct ones, and I finally found them
in the boot scripts. Mine is booted with this :

# cat /proc/cmdline 
console=tty0 console=ttyAMA2,115200n8  root=UUID=018e1580-e7e9-460b-95c5-236f6b87b13d rootwait ro fixrtc nocompcache vmalloc=300M mem=128M at 0 mali.mali_mem=64M at 128M hwmem=168M at 192M mem=22M at 360M mem_issw=1M at 383M mem=640M at 384M

# uname -a
Linux snowball 3.10.0-rc5-snowball #2 SMP Fri Jun 14 09:19:28 CEST 2013 armv7l GNU/Linux

I don't have the CONFIG_ARM_APPENDED_DTB set, instead I have copied
the dtb on the flash since u-boot supports it (I find this boot
procedure quite annoying btw).

Hoping this helps,
Willy



From marex at denx.de  Thu Jul 25 01:55:23 2013
From: marex at denx.de (Marek Vasut)
Date: Thu, 25 Jul 2013 07:55:23 +0200
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <20130722015305.GB25817@nchen-desktop>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <201307220340.32263.marex@denx.de> <20130722015305.GB25817@nchen-desktop>
Message-ID: <201307250755.23403.marex@denx.de>

Hi Peter,

> On Mon, Jul 22, 2013 at 03:40:32AM +0200, Marek Vasut wrote:
> > Dear Peter Chen,
> > 
> > > On Mon, Jul 22, 2013 at 03:15:28AM +0200, Marek Vasut wrote:
> > > > Hi Peter,
> > > > 
> > > > > On Fri, Jul 12, 2013 at 03:18:31PM +0200, Marek Vasut wrote:
> > > > > > Hi Peter,
> > > > > > 
> > > > > > > On Fri, Jul 12, 2013 at 06:04:43AM +0200, Marek Vasut wrote:
> > > > > > > > Hi Peter,
> > > > > > > > 
> > > > > > > > > On Thu, Jul 11, 2013 at 07:57:19PM +0200, Marek Vasut wrote:
> > > > > > > > > > Hi Peter,
> > > > > > > > > > 
> > > > > > > > > > > This patchset adds tested otg id switch function and
> > > > > > > > > > > vbus connect and disconnect detection for chipidea
> > > > > > > > > > > driver. And fix kinds of bugs found at chipidea
> > > > > > > > > > > drivers after enabling id and vbus detection.
> > > > > > > > > > > 
> > > > > > > > > > > This patch is fully tested at imx6 sabresd platform.
> > > > > > > > > > > My chipidea repo:
> > > > > > > > > > > https://github.com/hzpeterchen/linux-usb.git
> > > > > > > > > > > 
> > > > > > > > > > > Changes for v12:
> > > > > > > > > > > - Rebased greg's usb-next tree (3.10.0-rc7+)
> > > > > > > > > > > - Split more small patches for single function and fix.
> > > > > > > > > > 
> > > > > > > > > > I tested the patchset. Here are the results:
> > > > > > > > > > 
> > > > > > > > > > - VBUS switching
> > > > > > > > > > 
> > > > > > > > > > I'm no longer getting any ID interrupts at all when I
> > > > > > > > > > apply the patch below. The board stays in HOST mode all
> > > > > > > > > > the time. If I configure it as peripheral, it works as
> > > > > > > > > > peripheral. Note with [1], I was able to switch from
> > > > > > > > > > Peripheral->Host , not the other way around.
> > > > > > > > > 
> > > > > > > > > Thanks for your testing. But first, can you have me check
> > > > > > > > > if your ID wakeup is enabled?
> > > > > > > > 
> > > > > > > > ID wakeup? How do I check?
> > > > > > > 
> > > > > > > See otgsc at controller register, the ID wakeup enable is bit
> > > > > > > 24.
> > > > > > 
> > > > > > Yes, ID interrupt (IDIE) is set.
> > > > > > 
> > > > > > I noticed this backtrace in the kernel bootlog, but this only
> > > > > > happens if the dr_mode="otg" , it comes from the host-mode irq
> > > > > > handler :
> > > > > > 
> > > > > > [    2.757563] irq 238: nobody cared (try booting with the
> > > > > > "irqpoll" option) [    2.764398] CPU: 0 PID: 1 Comm: swapper Not
> > > > > > tainted 3.10.0- next-20130711-00013-g011c4b3-dirty #703
> > > > > > [    2.773445] [<80013878>] (unwind_backtrace+0x0/0xe8) from
> > > > > > [<80011644>] (show_stack+0x10/0x14)
> > > > > > [    2.782027] [<80011644>] (show_stack+0x10/0x14) from
> > > > > > [<800659f4>] (__report_bad_irq.isra.6+0x20/0xe0)
> > > > > > [    2.791286] [<800659f4>] (__report_bad_irq.isra.6+0x20/0xe0)
> > > > > > from [<80065c98>] (note_interrupt+0x16c/0x230)
> > > > > > [    2.801063] [<80065c98>] (note_interrupt+0x16c/0x230) from
> > > > > > [<80064000>] (handle_irq_event_percpu+0x10c/0x1a4)
> > > > > > [    2.811010] [<80064000>] (handle_irq_event_percpu+0x10c/0x1a4)
> > > > > > from [<800640e8>] (handle_irq_event+0x50/0x78)
> > > > > > [    2.820958] [<800640e8>] (handle_irq_event+0x50/0x78) from
> > > > > > [<8006652c>] (handle_level_irq+0x88/0x10c)
> > > > > > [    2.830210] [<8006652c>] (handle_level_irq+0x88/0x10c) from
> > > > > > [<800638d0>] (generic_handle_irq+0x28/0x3c)
> > > > > > [    2.839637] [<800638d0>] (generic_handle_irq+0x28/0x3c) from
> > > > > > [<8000f84c>] (handle_IRQ+0x30/0x84)
> > > > > > [    2.848461] [<8000f84c>] (handle_IRQ+0x30/0x84) from
> > > > > > [<80012160>] (__irq_svc+0x40/0x6c)
> > > > > > [    2.856510] [<80012160>] (__irq_svc+0x40/0x6c) from
> > > > > > [<80022a44>] (__do_softirq+0x90/0x1d8)
> > > > > > [    2.864812] [<80022a44>] (__do_softirq+0x90/0x1d8) from
> > > > > > [<80022edc>] (irq_exit+0x98/0xd4)
> > > > > > [    2.873025] [<80022edc>] (irq_exit+0x98/0xd4) from
> > > > > > [<8000f850>] (handle_IRQ+0x34/0x84)
> > > > > > [    2.880980] [<8000f850>] (handle_IRQ+0x34/0x84) from
> > > > > > [<80012160>] (__irq_svc+0x40/0x6c)
> > > > > > [    2.889020] [<80012160>] (__irq_svc+0x40/0x6c) from
> > > > > > [<8001d724>] (vprintk_emit+0x1bc/0x524)
> > > > > > [    2.897411] [<8001d724>] (vprintk_emit+0x1bc/0x524) from
> > > > > > [<804da5a4>] (printk+0x30/0x40)
> > > > > > [    2.905551] [<804da5a4>] (printk+0x30/0x40) from [<80630138>]
> > > > > > (mousedev_init+0x4c/0x60)
> > > > > > [    2.913617] [<80630138>] (mousedev_init+0x4c/0x60) from
> > > > > > [<806178fc>] (do_one_initcall+0x94/0x14c)
> > > > > > [    2.922537] [<806178fc>] (do_one_initcall+0x94/0x14c) from
> > > > > > [<80617b20>] (kernel_init_freeable+0x16c/0x22c)
> > > > > > [    2.932230] [<80617b20>] (kernel_init_freeable+0x16c/0x22c)
> > > > > > from [<804d8cbc>] (kernel_init+0x8/0x150)
> > > > > > [    2.941486] [<804d8cbc>] (kernel_init+0x8/0x150) from
> > > > > > [<8000ea70>] (ret_from_fork+0x14/0x24)
> > > > > > [    2.949932] handlers:
> > > > > > [    2.952227] [<8033fc58>] ci_irq
> > > > > > [    2.955388] Disabling IRQ #238
> > > > > 
> > > > > Marek, I have a test at imx28evk (Freescale imx28evk) for this
> > > > > patchset, it works well for dual-role switch after adding below dts
> > > > > change. There is a kernel dump when works at udc mode(due to enable
> > > > > CONFIG_LOCKUP_DETECTOR), at the first connect, but it does not
> > > > > affect function, it should be a common chipidea problem, I will
> > > > > check later.
> > > > 
> > > > Sorry for the long delay. I finally got further with this, at least
> > > > now I can switch Periph->Host again, but if I do so the other way
> > > > around (unplug host adapter and plug computer cable) and dump the
> > > > controller registers, I still see the controller in "host"
> > > > (according to USBMODE register) mode. The controller stays in HOST
> > > > mode even if I force it to gadget mode by writing "gadget" into
> > > > debugfs "role" entry. I will keep poking.
> > > > 
> > > > In the meantime, I guess if it works on the EVK, it might be a
> > > > hardware error so I better stop stalling you. I'll drop you an email
> > > > if I find what this problem is.
> > > 
> > > No, the problem is you did not config the USB OTG ID pin.
> > > Do the same thing I have done at imx28evk, you probably will work
> > > if the ID pin is the same at your board.
> > 
> > That one I have configured, exactly the same way you did (except that
> > mine is MX28_PAD_PWM2__USB0_ID).
> > 
> > If it was the OTG ID pin issue, would the manual switching not work ?
> 
> I can't see at your imx28-m28evk.dts, besides, make sure this pin can be
> configed as USB OTG ID pin, and fsl,pull-up = <1>. Since you are still
> at host mode, I suspect it is the ID problem.
> You can check if there is ID INT when unplug out B-to-A cable.
> 
> I have not tried the manual switching, but first, you need to close your
> vbus supply.

I think we can close this issue, I will now be also getting MX28EVK. Thanks for 
all your help!



From peter.chen at freescale.com  Thu Jul 25 01:58:56 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 25 Jul 2013 13:58:56 +0800
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <201307250755.23403.marex@denx.de>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <201307220340.32263.marex@denx.de>
 <20130722015305.GB25817@nchen-desktop>
 <201307250755.23403.marex@denx.de>
Message-ID: <20130725055855.GA4924@nchen-desktop>

On Thu, Jul 25, 2013 at 07:55:23AM +0200, Marek Vasut wrote:
> Hi Peter,
> 
> > 
> > I have not tried the manual switching, but first, you need to close your
> > vbus supply.
> 
> I think we can close this issue, I will now be also getting MX28EVK. Thanks for 
> all your help!
> 
> 

Great. What's the problem? Any changes for this patchset?

-- 

Best Regards,
Peter Chen



From marex at denx.de  Thu Jul 25 02:05:41 2013
From: marex at denx.de (Marek Vasut)
Date: Thu, 25 Jul 2013 08:05:41 +0200
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
Message-ID: <201307250805.41238.marex@denx.de>

Dear Peter Chen,

> This patchset adds tested otg id switch function and
> vbus connect and disconnect detection for chipidea driver.
> And fix kinds of bugs found at chipidea drivers after enabling
> id and vbus detection.
> 
> This patch is fully tested at imx6 sabresd platform.
> My chipidea repo: https://github.com/hzpeterchen/linux-usb.git

Patchset:

Tested-by: Marek Vasut <marex at denx.de>

on two STMP3780-based boards (not yet mainline) and two MX28-based boards.

Best regards,
Marek Vasut


From 21cnbao at gmail.com  Thu Jul 25 02:06:56 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Thu, 25 Jul 2013 14:06:56 +0800
Subject: [PATCH] dmaengine: sirf: add PM entries for sleep and runtime
Message-ID: <1374732416-3870-1-git-send-email-Baohua.Song@csr.com>

this patch adds PM ops entries in sirf-dma drivers, so that this
driver can support suspend/resume, hibernation and runtime PM.

while suspending, sirf-dma will lose all registers, so we save
them at suspend and restore in resume for active channels.

Signed-off-by: Barry Song <Baohua.Song at csr.com>
Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
---
 drivers/dma/sirf-dma.c | 124 +++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 121 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
index 716b23e..b6cf509 100644
--- a/drivers/dma/sirf-dma.c
+++ b/drivers/dma/sirf-dma.c
@@ -9,6 +9,7 @@
 #include <linux/module.h>
 #include <linux/dmaengine.h>
 #include <linux/dma-mapping.h>
+#include <linux/pm_runtime.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/slab.h>
@@ -73,6 +74,11 @@ struct sirfsoc_dma_chan {
 	int				mode;
 };
 
+struct sirfsoc_dma_regs {
+	u32				ctrl[SIRFSOC_DMA_CHANNELS];
+	u32				interrupt_en;
+};
+
 struct sirfsoc_dma {
 	struct dma_device		dma;
 	struct tasklet_struct		tasklet;
@@ -81,10 +87,13 @@ struct sirfsoc_dma {
 	int				irq;
 	struct clk			*clk;
 	bool				is_marco;
+	struct sirfsoc_dma_regs		regs_save;
 };
 
 #define DRV_NAME	"sirfsoc_dma"
 
+static int sirfsoc_dma_runtime_suspend(struct device *dev);
+
 /* Convert struct dma_chan to struct sirfsoc_dma_chan */
 static inline
 struct sirfsoc_dma_chan *dma_chan_to_sirfsoc_dma_chan(struct dma_chan *c)
@@ -393,6 +402,8 @@ static int sirfsoc_dma_alloc_chan_resources(struct dma_chan *chan)
 	LIST_HEAD(descs);
 	int i;
 
+	pm_runtime_get_sync(sdma->dma.dev);
+
 	/* Alloc descriptors for this channel */
 	for (i = 0; i < SIRFSOC_DMA_DESCRIPTORS; i++) {
 		sdesc = kzalloc(sizeof(*sdesc), GFP_KERNEL);
@@ -425,6 +436,7 @@ static int sirfsoc_dma_alloc_chan_resources(struct dma_chan *chan)
 static void sirfsoc_dma_free_chan_resources(struct dma_chan *chan)
 {
 	struct sirfsoc_dma_chan *schan = dma_chan_to_sirfsoc_dma_chan(chan);
+	struct sirfsoc_dma *sdma = dma_chan_to_sirfsoc_dma(chan);
 	struct sirfsoc_dma_desc *sdesc, *tmp;
 	unsigned long flags;
 	LIST_HEAD(descs);
@@ -445,6 +457,8 @@ static void sirfsoc_dma_free_chan_resources(struct dma_chan *chan)
 	/* Free descriptors */
 	list_for_each_entry_safe(sdesc, tmp, &descs, node)
 		kfree(sdesc);
+
+	pm_runtime_put(sdma->dma.dev);
 }
 
 /* Send pending descriptor to hardware */
@@ -723,14 +737,14 @@ static int sirfsoc_dma_probe(struct platform_device *op)
 
 	tasklet_init(&sdma->tasklet, sirfsoc_dma_tasklet, (unsigned long)sdma);
 
-	clk_prepare_enable(sdma->clk);
-
 	/* Register DMA engine */
 	dev_set_drvdata(dev, sdma);
+
 	ret = dma_async_device_register(dma);
 	if (ret)
 		goto free_irq;
 
+	pm_runtime_enable(&op->dev);
 	dev_info(dev, "initialized SIRFSOC DMAC driver\n");
 
 	return 0;
@@ -747,13 +761,116 @@ static int sirfsoc_dma_remove(struct platform_device *op)
 	struct device *dev = &op->dev;
 	struct sirfsoc_dma *sdma = dev_get_drvdata(dev);
 
-	clk_disable_unprepare(sdma->clk);
 	dma_async_device_unregister(&sdma->dma);
 	free_irq(sdma->irq, sdma);
 	irq_dispose_mapping(sdma->irq);
+	pm_runtime_disable(&op->dev);
+	if (!pm_runtime_status_suspended(&op->dev))
+		sirfsoc_dma_runtime_suspend(&op->dev);
+
+	return 0;
+}
+
+static int sirfsoc_dma_runtime_suspend(struct device *dev)
+{
+	struct sirfsoc_dma *sdma = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(sdma->clk);
+	return 0;
+}
+
+static int sirfsoc_dma_runtime_resume(struct device *dev)
+{
+	struct sirfsoc_dma *sdma = dev_get_drvdata(dev);
+	int ret;
+
+	ret = clk_prepare_enable(sdma->clk);
+	if (ret < 0) {
+		dev_err(dev, "clk_enable failed: %d\n", ret);
+		return ret;
+	}
+	return 0;
+}
+
+static int sirfsoc_dma_pm_suspend(struct device *dev)
+{
+	struct sirfsoc_dma *sdma = dev_get_drvdata(dev);
+	struct sirfsoc_dma_regs *save = &sdma->regs_save;
+	struct sirfsoc_dma_desc *sdesc;
+	struct sirfsoc_dma_chan *schan;
+	int ch;
+	int ret;
+
+	/* Enable clock before accessing register */
+	if (pm_runtime_status_suspended(dev)) {
+		ret = sirfsoc_dma_runtime_resume(dev);
+		if (ret < 0)
+			return ret;
+	}
+
+	for (ch = 0; ch < SIRFSOC_DMA_CHANNELS; ch++) {
+		schan = &sdma->channels[ch];
+		if (list_empty(&schan->active))
+			continue;
+		sdesc = list_first_entry(&schan->active,
+			struct sirfsoc_dma_desc,
+			node);
+		save->ctrl[ch] = readl_relaxed(sdma->base +
+			ch * 0x10 + SIRFSOC_DMA_CH_CTRL);
+	}
+	save->interrupt_en = readl_relaxed(sdma->base + SIRFSOC_DMA_INT_EN);
+
+	/* Disable clock */
+	sirfsoc_dma_runtime_suspend(dev);
+
+	return 0;
+}
+
+static int sirfsoc_dma_pm_resume(struct device *dev)
+{
+	struct sirfsoc_dma *sdma = dev_get_drvdata(dev);
+	struct sirfsoc_dma_regs *save = &sdma->regs_save;
+	struct sirfsoc_dma_desc *sdesc;
+	struct sirfsoc_dma_chan *schan;
+	int ch;
+	int ret;
+
+	/* Enable clock before accessing register */
+	ret = sirfsoc_dma_runtime_resume(dev);
+	if (ret < 0)
+		return ret;
+
+	writel_relaxed(save->interrupt_en, sdma->base + SIRFSOC_DMA_INT_EN);
+	for (ch = 0; ch < SIRFSOC_DMA_CHANNELS; ch++) {
+		schan = &sdma->channels[ch];
+		if (list_empty(&schan->active))
+			continue;
+		sdesc = list_first_entry(&schan->active,
+			struct sirfsoc_dma_desc,
+			node);
+		writel_relaxed(sdesc->width,
+			sdma->base + SIRFSOC_DMA_WIDTH_0 + ch * 4);
+		writel_relaxed(sdesc->xlen,
+			sdma->base + ch * 0x10 + SIRFSOC_DMA_CH_XLEN);
+		writel_relaxed(sdesc->ylen,
+			sdma->base + ch * 0x10 + SIRFSOC_DMA_CH_YLEN);
+		writel_relaxed(save->ctrl[ch],
+			sdma->base + ch * 0x10 + SIRFSOC_DMA_CH_CTRL);
+		writel_relaxed(sdesc->addr >> 2,
+			sdma->base + ch * 0x10 + SIRFSOC_DMA_CH_ADDR);
+	}
+
+	/* Disable clock */
+	sirfsoc_dma_runtime_suspend(dev);
+
 	return 0;
 }
 
+static const struct dev_pm_ops sirfsoc_dma_pm_ops = {
+	SET_RUNTIME_PM_OPS(sirfsoc_dma_runtime_suspend, sirfsoc_dma_runtime_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(sirfsoc_dma_pm_suspend, sirfsoc_dma_pm_resume)
+};
+
 static struct of_device_id sirfsoc_dma_match[] = {
 	{ .compatible = "sirf,prima2-dmac", },
 	{ .compatible = "sirf,marco-dmac", },
@@ -766,6 +883,7 @@ static struct platform_driver sirfsoc_dma_driver = {
 	.driver = {
 		.name = DRV_NAME,
 		.owner = THIS_MODULE,
+		.pm = &sirfsoc_dma_pm_ops,
 		.of_match_table	= sirfsoc_dma_match,
 	},
 };
-- 
1.8.2.3



From oleksandr.kozaruk at ti.com  Thu Jul 25 02:08:48 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Thu, 25 Jul 2013 09:08:48 +0300
Subject: [PATCH v6 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <51EA69DE.4080908@kernel.org>
References: <1374226039-16943-1-git-send-email-oleksandr.kozaruk@ti.com>
 <1374226039-16943-3-git-send-email-oleksandr.kozaruk@ti.com>
 <51EA69DE.4080908@kernel.org>
Message-ID: <20130725060848.GA16521@uglx0158319>

On Sat, Jul 20, 2013 at 11:43:42AM +0100, Jonathan Cameron wrote:
> On 07/19/2013 10:27 AM, Oleksandr Kozaruk wrote:
> > The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
> > known also as Phoenix and PhoenixLite.
> >
> > The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
> > respectively. Some channels have current source and are used for
> > measuring voltage drop on resistive load for detecting battery ID
> > resistance, or measuring voltage drop on NTC resistors for external
> > temperature measurements. Some channels measure voltage, (i.e. battery
> > voltage), and have voltage dividers, thus, capable to scale voltage.
> > Some channels are dedicated for measuring die temperature.
> >
> > Some channels are calibrated in 2 points, having offsets from ideal
> > values kept in trim registers. This is used to correct measurements.
> >
> > The differences between GPADC in TWL6030 and TWL6032:
> > - 10 bit vs 12 bit ADC;
> > - 17 vs 19 channels;
> > - channels have different purpose(i.e. battery voltage
> >   channel 8 vs channel 18);
> > - trim values are interpreted differently.
> >
> > Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
> > Girish S Ghongdemath.
> >
> > Signed-off-by: Balaji T K <balajitk at ti.com>
> > Signed-off-by: Graeme Gregory <gg at slimlogic.co.uk>
> > Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
> A few little bits and bobs inline.
> 
> My only major query is about the lack of info for the temperature
> channels.  How do you convert these to useful real world units?

On blaze tablet platform(OMAP 4) temperature channels were used by
thermal framework and battery driver.
Thermal was using channel 4 [1]

Here is the comment from the driver:

* NTC termistor (NCP15WB473F) schematic connection for OMAP4460 board:
*
*          [Vref]
*            |
*            $ (Rpu)
*            |
*            +----+-----------[Vin]
*            |    |
*           [Rt]  $ (Rpd)
*            |    |
*           -------- (ground)
*
* NTC termistor resistanse (Rt, k) calculated from following formula:
*
* Rt = Rpd * Rpu * Vin / (Rpd * (Vref - Vin) - Rpu * Vin)
*
* where       Vref (GPADC_VREF4) - reference voltage, Vref = 1250 mV;
*                     Vin (GPADC_IN4) - measuring voltage, Vin = 0...1250 mV;
*                     Rpu (R1041) - pullup resistor, Rpu = 10 k;
*                     Rpd (R1043) - pulldown resistor, Rpd = 220 k;
*
* Pcb temp sensor temperature (t, C) calculated from following formula:
*
* t = 1 / (ln(Rt / Rt0) / B + 1 / T0) - 273
*
* where       Rt0 - NTC termistor resistance at 25 C, Rt0 = 47 k;
*                     B - specific constant, B = 4131 K;
*                     T0 - temperature, T0 = 298 K
[..]

And then there is a table for conversion:
/*
 * Temperature values in degrees celsius,
 * voltage values from 156 to 1191 milli volts
*/
static s8 mvolt_to_temp[] = {
               125, 125, 125, 124, 124, 124, 124, 123, 123, 123, 122, 122,
               122, 122, 121, 121, 121, 121, 120, 120, 120, 120, 119, 119,
[..]

The battery driver was using channel 1, dedicated for measuring battery
temperature.
static void twl6030_bci_battery_work(struct work_struct *work)
{
[..]
	for (temp = 0; temp < di->platform_data->tblsize; temp++) {
		if (adc_code >= di->platform_data->
				battery_tmp_tbl[temp])
			break;
	}

	/* first 2 values are for negative temperature */
	di->temp_C = (temp - 2) * 10; * /* in tenths of degree Celsius */
	[..]
}
static int omap4_batt_table[] = {
/* adc code for temperature in degree C */
	929, 925, /* -2 ,-1 */
	920, 917, 912, 908, 904, 899, 895, 890, 885, 880, /* 00 - 09 */
	875, 869, 864, 858, 853, 847, 841, 835, 829, 823, /* 10 - 19 */
[..]
	591, 583, 575, 567, 559, 551, 543, 535, 527, 519, /* 50 - 59 */
	511, 504, 496 /* 60 - 62 */
};

So, one driver was using millivolts and the other ADC code,
Though converting to millivolts and the to temperature, seems,
to be redundant, as code can be converted to temperature.
If I recollect correctly the previous driver version was using just
ADC code.

Regards,
Sasha.

[1] http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=drivers/staging/thermal_framework/sensor/thermistor_sensor.c;h=828d8010579b55ec4a122c49a2e5b547b1e41e63;hb=decb3fd22223ddf207e0118d0d558459acc7094e



From tomi.valkeinen at ti.com  Thu Jul 25 02:40:01 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Thu, 25 Jul 2013 09:40:01 +0300
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <20130724145237.GB21614@n2100.arm.linux.org.uk>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724145237.GB21614@n2100.arm.linux.org.uk>
Message-ID: <51F0C841.8000900@ti.com>

On 24/07/13 17:52, Russell King - ARM Linux wrote:

> I also continue to be disappointed by the lack of things working on the
> 4430 - it's been a number of years now and _still_ the on-board LCDs do
> not work.  People have tried to blame that on hardware faults and the
> like, but they're just being idiotic when they say stuff like that.  It
> can't be hardware faults when the kernel supplied with the board is able
> to make them work to the extent that userspace can play back video on all
> three output devices simultaneously, without hiccup or any imperfection.
> I don't know whether it's just that the backlight support isn't working
> or what - because any information on the 4430 seems to be a tightly
> controlled secret that only a few select people are permitted to know
> about.  As far as I'm concerned, much of the hardware is a black box to
> me.

The 4430SDP's backlight hasn't been working in the mainline due to
missing support from the TWL driver. But we finally did get that in for
3.10 (or maybe 3.9), and booting 3.10 non-DT kernel brings up the
backlights. However, the BL doesn't work yet with DT boot, so again with
3.11, with no board files, the BL is out... Sigh.

The panel driver itself have been working as long as it has been in the
mainline kernel (for me). I think there was a mixup at some point with
pinmuxing due to TRM having wrong information, but for some reason my
board works fine with both right and wrong muxing. If I recall right,
your board did not. But that's also solved some kernel versions ago.

But even with the above fixed, you could observe that your panel doesn't
work. The reason is that the panels in the 4430SDP board were chosen a
bit oddly: they are so called manual update panels, meant to be
explicitly updated by the software only when required. The phones that
have such panels (which, I guess, is what 4430SDP is designed to
resemble) have software doing that, but obviously the standard linux
software does not.

There's a hack to enable a non-optimal automatic update for testing
purposes:

echo 1 > /sys/class/graphics/fb0/update_mode

This makes omapfb update the display 20 times per second. Or via a
module parameter: omapfb.auto_update=y

We could implement a better auto-update system for manual-update panels,
but I have opted not to:

- It's not easy to implement efficiently and reliably (in fact, we did
have auto-update support at some point in the kernel, but it was removed
as it was rather troublesome to keep working).

- Manual-update panels are meant to be updated manually, only when
needed. That's the whole point of the manual-update feature. Doing
auto-update with a manual-update panel is inefficient. So such a feature
would only be useful for testing purposes.

- Manual-update panels are quite rare, and the trend to use them seems
to be coming even rarer.

> And yes, my 4430 has the projector module on it.  Never ever seen that
> work, and no idea how to make it work because there's no information
> available on the hardware.

I don't have that one. PicoDLP shares resources (DSS pins, at least, if
I recall right, and some power line) with the second LCD, and we don't
have support to manage sharing those resources. So the PicoDLP is left
disabled in the board file.

I don't have any clear idea how to implement management of those
resources, and no one has ever asked about PicoDLP from me, so it's
never been a very high priority.

So 4430SDP is a bit difficult on the display side: non-standard panels
and a pico projector that is mutually exclusive with the LCD2.

> And no, I don't want another Beagle board or Panda board or whatever, I
> have those (I think I have one of each), and they've never been powered up
> because they have no ethernet on them, and I have no USB to ethernet still,
> partly because I don't really do USB here *at* *all*, so I don't know what
> works well and what doesn't with Linux.  Even if I did provide them with a
> USB ethernet, I doubt they'd be able to boot a kernel via the network.

Beagle xM and Panda have ethernet. I boot Panda via the network (load
kernel and use nfsroot). But they don't have panels, so you need an
external display for those.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130725/b7d54168/attachment.sig>

From u.kleine-koenig at pengutronix.de  Thu Jul 25 02:41:08 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Thu, 25 Jul 2013 08:41:08 +0200
Subject: Mainline kernel on snowball
In-Reply-To: <20130725052317.GA25854@verge.net.au>
References: <20130725052317.GA25854@verge.net.au>
Message-ID: <20130725064108.GH1754@pengutronix.de>

Hello Simon,

On Thu, Jul 25, 2013 at 02:23:17PM +0900, Simon Horman wrote:
> I apologise for the na?ve nature of this question,
> but I do not seem to be able to make any progress of my own accord.
> 
> I would like to boot the mainline kernel - ideally v3.10 and v3.11-rcX -
> on snowball. The reason being to verify CPU hotplug which
> seems to be broken on shmobile, though that is tangential to this post.
> 
> My procedure, which does not work, is as follows.
> I have tried a number of different versions all with roughly
> the same result.
> 
> 1. Build kernel
> # git checkout v3.10.2 # I have tried several over versions too.
> # make u8500_defconfig
> Edit .config to enable CONFIG_ARM_APPENDED_DTB
> # LOADADDR=0x100000 make uImage dtbs
> 
> 2. Append dtb to zImage and recreate uImage
> mv arch/arm/boot/zImage arch/arm/boot/zImage.tmp
> cat arch/arm/boot/zImage.tmp arch/arm/boot/dts/snowball.dtb
There must be a redirection in the cat command, something like

	cat arch/arm/boot/zImage.tmp arch/arm/boot/dts/snowball.dtb > arch/arm/boot/zImage

(I guess you have that as otherwise the following command would fail.)

> /bin/sh scripts/mkuboot.sh \
> 	-A arm -O linux -C none  -T kernel \
> 	-a 0x100000 -e 0x100000 -n 'Linux-3.10.2' \
> 	-d arch/arm/boot/zImage arch/arm/boot/uImage
> 
> 3. Boot uImage from u-boot
> Snowball $ setenv ethaddr 3e:c4:73:05:d1:a1
> Snowball $ bootp;bootm
> smc911x: detected LAN9221 controller
> smc911x: phy initialized
> smc911x: MAC 3e:c4:73:05:d1:a1
> BOOTP broadcast 1
> *** Unhandled DHCP Option in OFFER/ACK: 28
> *** Unhandled DHCP Option in OFFER/ACK: 44
> *** Unhandled DHCP Option in OFFER/ACK: 28
> *** Unhandled DHCP Option in OFFER/ACK: 44
> DHCP client bound to address 10.3.3.146
> Using smc911x-0 device
> TFTP from server 10.3.3.135; our IP address is 10.3.3.146
> Filename 'snowball/uImage'.
> Load address: 0x100000
> Loading: #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          ##########################################################
> done
> Bytes transferred = 2540191 (26c29f hex)
> ## Booting kernel from Legacy Image at 00100000 ...
>    Image Name:   'Linux-3.10.2'
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    2540127 Bytes =  2.4 MB
>    Load Address: 00100000
>    Entry Point:  00100000
>    XIP Kernel Image ... OK
> OK
> 
> Starting kernel ...
Try enabling DEBUG_LL and EARLY_PRINTK and pass "earlyprintk" on the
kernel commandline. That might make the kernel more talkative.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From tomi.valkeinen at ti.com  Thu Jul 25 02:50:13 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Thu, 25 Jul 2013 09:50:13 +0300
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <51F0C841.8000900@ti.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724145237.GB21614@n2100.arm.linux.org.uk>
 <51F0C841.8000900@ti.com>
Message-ID: <51F0CAA5.8010108@ti.com>

On 25/07/13 09:40, Tomi Valkeinen wrote:
> On 24/07/13 17:52, Russell King - ARM Linux wrote:
> 
>> I also continue to be disappointed by the lack of things working on the
>> 4430 - it's been a number of years now and _still_ the on-board LCDs do
>> not work.  People have tried to blame that on hardware faults and the
>> like, but they're just being idiotic when they say stuff like that.  It
>> can't be hardware faults when the kernel supplied with the board is able
>> to make them work to the extent that userspace can play back video on all
>> three output devices simultaneously, without hiccup or any imperfection.
>> I don't know whether it's just that the backlight support isn't working
>> or what - because any information on the 4430 seems to be a tightly
>> controlled secret that only a few select people are permitted to know
>> about.  As far as I'm concerned, much of the hardware is a black box to
>> me.
> 
> The 4430SDP's backlight hasn't been working in the mainline due to
> missing support from the TWL driver. But we finally did get that in for
> 3.10 (or maybe 3.9), and booting 3.10 non-DT kernel brings up the
> backlights. However, the BL doesn't work yet with DT boot, so again with
> 3.11, with no board files, the BL is out... Sigh.

Ah, sorry, I take that back. Backlight seems to be working fine with 3.11.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130725/de5e0ef5/attachment.sig>

From horms at verge.net.au  Thu Jul 25 03:22:57 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 25 Jul 2013 16:22:57 +0900
Subject: Mainline kernel on snowball
In-Reply-To: <20130725064108.GH1754@pengutronix.de>
References: <20130725052317.GA25854@verge.net.au>
 <20130725064108.GH1754@pengutronix.de>
Message-ID: <20130725072257.GB7654@verge.net.au>

On Thu, Jul 25, 2013 at 08:41:08AM +0200, Uwe Kleine-K?nig wrote:
> Hello Simon,
> 
> On Thu, Jul 25, 2013 at 02:23:17PM +0900, Simon Horman wrote:
> > I apologise for the na?ve nature of this question,
> > but I do not seem to be able to make any progress of my own accord.
> > 
> > I would like to boot the mainline kernel - ideally v3.10 and v3.11-rcX -
> > on snowball. The reason being to verify CPU hotplug which
> > seems to be broken on shmobile, though that is tangential to this post.
> > 
> > My procedure, which does not work, is as follows.
> > I have tried a number of different versions all with roughly
> > the same result.
> > 
> > 1. Build kernel
> > # git checkout v3.10.2 # I have tried several over versions too.
> > # make u8500_defconfig
> > Edit .config to enable CONFIG_ARM_APPENDED_DTB
> > # LOADADDR=0x100000 make uImage dtbs
> > 
> > 2. Append dtb to zImage and recreate uImage
> > mv arch/arm/boot/zImage arch/arm/boot/zImage.tmp
> > cat arch/arm/boot/zImage.tmp arch/arm/boot/dts/snowball.dtb
> There must be a redirection in the cat command, something like
> 
> 	cat arch/arm/boot/zImage.tmp arch/arm/boot/dts/snowball.dtb > arch/arm/boot/zImage
> 
> (I guess you have that as otherwise the following command would fail.)

Sorry for missing that when I wrote my email. Yes, it is there.

> > /bin/sh scripts/mkuboot.sh \
> > 	-A arm -O linux -C none  -T kernel \
> > 	-a 0x100000 -e 0x100000 -n 'Linux-3.10.2' \
> > 	-d arch/arm/boot/zImage arch/arm/boot/uImage
> > 
> > 3. Boot uImage from u-boot
> > Snowball $ setenv ethaddr 3e:c4:73:05:d1:a1
> > Snowball $ bootp;bootm
> > smc911x: detected LAN9221 controller
> > smc911x: phy initialized
> > smc911x: MAC 3e:c4:73:05:d1:a1
> > BOOTP broadcast 1
> > *** Unhandled DHCP Option in OFFER/ACK: 28
> > *** Unhandled DHCP Option in OFFER/ACK: 44
> > *** Unhandled DHCP Option in OFFER/ACK: 28
> > *** Unhandled DHCP Option in OFFER/ACK: 44
> > DHCP client bound to address 10.3.3.146
> > Using smc911x-0 device
> > TFTP from server 10.3.3.135; our IP address is 10.3.3.146
> > Filename 'snowball/uImage'.
> > Load address: 0x100000
> > Loading: #################################################################
> >          #################################################################
> >          #################################################################
> >          #################################################################
> >          ##########################################################
> > done
> > Bytes transferred = 2540191 (26c29f hex)
> > ## Booting kernel from Legacy Image at 00100000 ...
> >    Image Name:   'Linux-3.10.2'
> >    Image Type:   ARM Linux Kernel Image (uncompressed)
> >    Data Size:    2540127 Bytes =  2.4 MB
> >    Load Address: 00100000
> >    Entry Point:  00100000
> >    XIP Kernel Image ... OK
> > OK
> > 
> > Starting kernel ...
> Try enabling DEBUG_LL and EARLY_PRINTK and pass "earlyprintk" on the
> kernel commandline. That might make the kernel more talkative.

Thanks. Unfortunately I don't seem to get any further.


From horms at verge.net.au  Thu Jul 25 03:25:25 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 25 Jul 2013 16:25:25 +0900
Subject: Mainline kernel on snowball
In-Reply-To: <20130725054036.GD31954@1wt.eu>
References: <20130725052317.GA25854@verge.net.au>
 <20130725054036.GD31954@1wt.eu>
Message-ID: <20130725072525.GC7654@verge.net.au>

On Thu, Jul 25, 2013 at 07:40:36AM +0200, Willy Tarreau wrote:
> Hi Simon,
> 
> On Thu, Jul 25, 2013 at 02:23:17PM +0900, Simon Horman wrote:
> > Hi,
> > 
> > I apologise for the na?ve nature of this question,
> > but I do not seem to be able to make any progress of my own accord.
> > 
> > I would like to boot the mainline kernel - ideally v3.10 and v3.11-rcX -
> > on snowball. The reason being to verify CPU hotplug which
> > seems to be broken on shmobile, though that is tangential to this post.
> > 
> > My procedure, which does not work, is as follows.
> > I have tried a number of different versions all with roughly
> > the same result.
> > 
> > 1. Build kernel
> > # git checkout v3.10.2 # I have tried several over versions too.
> > # make u8500_defconfig
> > Edit .config to enable CONFIG_ARM_APPENDED_DTB
> > # LOADADDR=0x100000 make uImage dtbs
> > 
> > 2. Append dtb to zImage and recreate uImage
> > mv arch/arm/boot/zImage arch/arm/boot/zImage.tmp
> > cat arch/arm/boot/zImage.tmp arch/arm/boot/dts/snowball.dtb
> > /bin/sh scripts/mkuboot.sh \
> > 	-A arm -O linux -C none  -T kernel \
> > 	-a 0x100000 -e 0x100000 -n 'Linux-3.10.2' \
> > 	-d arch/arm/boot/zImage arch/arm/boot/uImage
> > 
> > 3. Boot uImage from u-boot
> > Snowball $ setenv ethaddr 3e:c4:73:05:d1:a1
> > Snowball $ bootp;bootm
> > smc911x: detected LAN9221 controller
> > smc911x: phy initialized
> > smc911x: MAC 3e:c4:73:05:d1:a1
> > BOOTP broadcast 1
> > *** Unhandled DHCP Option in OFFER/ACK: 28
> > *** Unhandled DHCP Option in OFFER/ACK: 44
> > *** Unhandled DHCP Option in OFFER/ACK: 28
> > *** Unhandled DHCP Option in OFFER/ACK: 44
> > DHCP client bound to address 10.3.3.146
> > Using smc911x-0 device
> > TFTP from server 10.3.3.135; our IP address is 10.3.3.146
> > Filename 'snowball/uImage'.
> > Load address: 0x100000
> > Loading: #################################################################
> >          #################################################################
> >          #################################################################
> >          #################################################################
> >          ##########################################################
> > done
> > Bytes transferred = 2540191 (26c29f hex)
> > ## Booting kernel from Legacy Image at 00100000 ...
> >    Image Name:   'Linux-3.10.2'
> >    Image Type:   ARM Linux Kernel Image (uncompressed)
> >    Data Size:    2540127 Bytes =  2.4 MB
> >    Load Address: 00100000
> >    Entry Point:  00100000
> >    XIP Kernel Image ... OK
> > OK
> > 
> > Starting kernel ...
> > 
> > 
> > This is as far as it gets.
> 
> Are you sure you have the correct bootargs by default ? It was a
> pain for me to figure the correct ones, and I finally found them
> in the boot scripts. Mine is booted with this :
> 
> # cat /proc/cmdline 
> console=tty0 console=ttyAMA2,115200n8  root=UUID=018e1580-e7e9-460b-95c5-236f6b87b13d rootwait ro fixrtc nocompcache vmalloc=300M mem=128M at 0 mali.mali_mem=64M at 128M hwmem=168M at 192M mem=22M at 360M mem_issw=1M at 383M mem=640M at 384M

Thanks. Rummaging around in the environment present in uboot I came up with
the following:

bootargs=cachepolicy=writealloc noinitrd init=init board_id=1 crashkernel=crashkernel=1M at 0x5600000 logo.nologo startup_graphics=1 mpcore_wdt.mpcore_margin=359 loglevel=8 console=ttyAMA2,115200n8 mem=128M at 0 mali.mali_mem=64M at 128M
mem=24M at 192M hwmem=167M at 216M mem_issw=1M at 383M mem=640M at 384M vmalloc=256M

Unfortunately neither this, nor the boot args you are using seem
to get me any further.

> # uname -a
> Linux snowball 3.10.0-rc5-snowball #2 SMP Fri Jun 14 09:19:28 CEST 2013 armv7l GNU/Linux
> 
> I don't have the CONFIG_ARM_APPENDED_DTB set, instead I have copied
> the dtb on the flash since u-boot supports it (I find this boot
> procedure quite annoying btw).

Thanks.

I have now also tried the following without CONFIG_ARM_APPENDED_DTB set.

Snowball $ setenv ethaddr 3e:c4:73:05:d1:a1
Snowball $ bootp 
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 3e:c4:73:05:d1:a1
BOOTP broadcast 1
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 44
DHCP client bound to address 10.3.3.146
Using smc911x-0 device
TFTP from server 10.3.3.135; our IP address is 10.3.3.146
Filename 'snowball/uImage'.
Load address: 0x100000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##########################################################
done
Bytes transferred = 2540999 (26c5c7 hex)
Snowball $ tftp 0xf00000 snowball/snowball.dtb
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 3e:c4:73:05:d1:a1
Using smc911x-0 device
TFTP from server 10.3.3.135; our IP address is 10.3.3.146
Filename 'snowball/snowball.dtb'.
Load address: 0xf00000
Loading: ###
done
Bytes transferred = 16722 (4152 hex)
Snowball $ bootm 0x100000 - 0xf00000
## Booting kernel from Legacy Image at 00100000 ...
   Image Name:   'Linux-3.10.2'
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2540935 Bytes =  2.4 MB
   Load Address: 00100000
   Entry Point:  00100000
   XIP Kernel Image ... OK
OK

Starting kernel ...





From josh.wu at atmel.com  Thu Jul 25 03:29:07 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Thu, 25 Jul 2013 15:29:07 +0800
Subject: [PATCH 4/5] iio: at91: add an optional dt property for for adc
 clock hz.
In-Reply-To: <51E52B9B.5030407@metafoo.de>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-5-git-send-email-josh.wu@atmel.com>
 <20130715130610.GD2962@lukather> <51E4FC70.3050207@atmel.com>
 <20130716103014.GB3125@lukather> <51E52B9B.5030407@metafoo.de>
Message-ID: <51F0D3C3.5090201@atmel.com>

On 7/16/2013 7:16 PM, Lars-Peter Clausen wrote:
> On 07/16/2013 12:30 PM, Maxime Ripard wrote:
> [...]
>>> After a further thinking of this, maybe remove the adc_op_clk is
>>> better since it is a fake clock, and only used to specify the clock
>>> rate.
>>> To specify the clock rate use a dt property or platform data
>>> parameter is better.
>> No, to specify *any* clock, the common clock framework is the better
>> solution.
> Yep, this patch is not the right approach. It's trying to work around the
> limitations of the platforms clock API implementation. Please fix the at91
> clock implementation instead (e.g. by switching to the common clock framework).

Thank you and Maxime for the clarify. I will drop this patch in next 
version.
Just FYI. The at91 clock common framework is in implementation by Boris 
Brezillion.

>
> - Lars
>

Best Regards,
Josh Wu


From josh.wu at atmel.com  Thu Jul 25 03:35:56 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Thu, 25 Jul 2013 15:35:56 +0800
Subject: [PATCH 3/5] iio: at91: ADC start-up time calculation changed
 since at91sam9x5
In-Reply-To: <51EA5AC5.30400@kernel.org>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-4-git-send-email-josh.wu@atmel.com>
 <51EA5AC5.30400@kernel.org>
Message-ID: <51F0D55C.90709@atmel.com>

On 7/20/2013 5:39 PM, Jonathan Cameron wrote:
> On 07/14/2013 09:04 AM, Josh Wu wrote:
>> Since in at91sam9x5, sama5d3x chip. the start up time calucation is changed.
>> And these two chips also have TSMR, so we check whether ADC has TSMR, then
>> choose different start up time calculation formula.
> If this doesn't have anything directly to do with the TSMR and this is just
> coincidence, then do this separately with it's own flag as it will be
> easier to maintain in the long run.

Agreed. I will fix it in next version.

Best Regards,
Josh Wu

>
> Jonathan
>> Signed-off-by: Josh Wu <josh.wu at atmel.com>
>> ---
>>   drivers/iio/adc/at91_adc.c |   40 +++++++++++++++++++++++++++++++++-------
>>   1 file changed, 33 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
>> index 14e99ba..e93a075 100644
>> --- a/drivers/iio/adc/at91_adc.c
>> +++ b/drivers/iio/adc/at91_adc.c
>> @@ -733,13 +733,39 @@ static int at91_adc_probe(struct platform_device *pdev)
>>   		goto error_disable_adc_clk;
>>   	}
>>   
>> -	/*
>> -	 * Number of ticks needed to cover the startup time of the ADC as
>> -	 * defined in the electrical characteristics of the board, divided by 8.
>> -	 * The formula thus is : Startup Time = (ticks + 1) * 8 / ADC Clock
>> -	 */
>> -	ticks = round_up((st->startup_time * adc_clk_khz /
>> -			  1000) - 1, 8) / 8;
>> +	if (!st->caps.has_tsmr) {
>> +		/*
>> +		 * Number of ticks needed to cover the startup time of the ADC
>> +		 * as defined in the electrical characteristics of the board,
>> +		 * divided by 8. The formula thus is :
>> +		 *   Startup Time = (ticks + 1) * 8 / ADC Clock
>> +		 */
>> +		ticks = round_up((st->startup_time * adc_clk_khz /
>> +				  1000) - 1, 8) / 8;
>> +	} else {
>> +		/*
>> +		 * For sama5d3x and at91sam9x5, the formula changes to:
>> +		 * Startup Time = <lookup_table_value> / ADC Clock
>> +		 */
>> +		const int startup_lookup[] = {
>> +			0  , 8  , 16 , 24 ,
>> +			64 , 80 , 96 , 112,
>> +			512, 576, 640, 704,
>> +			768, 832, 896, 960
>> +			};
>> +
>> +		int i, size = ARRAY_SIZE(startup_lookup);
>> +		ticks = st->startup_time * adc_clk_khz / 1000;
>> +		for (i = 0; i < size; i++)
>> +			if (ticks < startup_lookup[i])
>> +				break;
>> +
>> +		ticks = i;
>> +		if (ticks == size)
>> +			/* Reach the end of lookup table */
>> +			ticks = size - 1;
>> +	}
>> +
>>   	/*
>>   	 * a minimal Sample and Hold Time is necessary for the ADC to guarantee
>>   	 * the best converted final value between two channels selection
>>



From lee.jones at linaro.org  Thu Jul 25 03:52:15 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 25 Jul 2013 08:52:15 +0100
Subject: [PATCH v3 07/22] ARM: dts: Remove '0x's from Exynos4210 DTSI file
In-Reply-To: <5075798.2aqxtybhC8@amdc1227>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-7-git-send-email-lee.jones@linaro.org>
 <20130724150937.GO26801@laptop> <5075798.2aqxtybhC8@amdc1227>
Message-ID: <20130725075215.GA3403@laptop>

On Wed, 24 Jul 2013, Tomasz Figa wrote:

> On Wednesday 24 of July 2013 16:09:37 Lee Jones wrote:
> > ... for the sake of consistency and assumed convention.
> > 
> > Cc: Kukjin Kim <kgene.kim at samsung.com>
> > Cc: linux-samsung-soc at vger.kernel.org
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > 
> > diff --git a/arch/arm/boot/dts/exynos4210.dtsi
> > b/arch/arm/boot/dts/exynos4210.dtsi index b7f358a..53e2527 100644
> > --- a/arch/arm/boot/dts/exynos4210.dtsi
> > +++ b/arch/arm/boot/dts/exynos4210.dtsi
> > @@ -72,7 +72,7 @@
> >                 };
> >         };
> > 
> > -       clock: clock-controller at 0x10030000 {
> > +       clock: clock-controller at 10030000 {
> >                 compatible = "samsung,exynos4210-clock";
> >                 reg = <0x10030000 0x20000>;
> >                 #clock-cells = <1>;
> 
> Acked-by: Tomasz Figa <t.figa at samsung.com>

Thanks Tomasz.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From w at 1wt.eu  Thu Jul 25 03:52:03 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 25 Jul 2013 09:52:03 +0200
Subject: Mainline kernel on snowball
In-Reply-To: <20130725072525.GC7654@verge.net.au>
References: <20130725052317.GA25854@verge.net.au>
 <20130725054036.GD31954@1wt.eu> <20130725072525.GC7654@verge.net.au>
Message-ID: <20130725075203.GE31954@1wt.eu>

On Thu, Jul 25, 2013 at 04:25:25PM +0900, Simon Horman wrote:
> > # cat /proc/cmdline 
> > console=tty0 console=ttyAMA2,115200n8  root=UUID=018e1580-e7e9-460b-95c5-236f6b87b13d rootwait ro fixrtc nocompcache vmalloc=300M mem=128M at 0 mali.mali_mem=64M at 128M hwmem=168M at 192M mem=22M at 360M mem_issw=1M at 383M mem=640M at 384M
> 
> Thanks. Rummaging around in the environment present in uboot I came up with
> the following:
> 
> bootargs=cachepolicy=writealloc noinitrd init=init board_id=1 crashkernel=crashkernel=1M at 0x5600000 logo.nologo startup_graphics=1 mpcore_wdt.mpcore_margin=359 loglevel=8 console=ttyAMA2,115200n8 mem=128M at 0 mali.mali_mem=64M at 128M
> mem=24M at 192M hwmem=167M at 216M mem_issw=1M at 383M mem=640M at 384M vmalloc=256M
> 
> Unfortunately neither this, nor the boot args you are using seem
> to get me any further.

OK, I'm attaching the config that works for me on 3.10-rc5 (not
tested a new one yet). It boots with the cmdline above and with
the DTB from the kernel.

Hoping this helps,
Willy

-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.10.0-rc5 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="snowball"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_SPARSE_IRQ=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
CONFIG_UIDGID_CONVERTED=y
# CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_HOTPLUG=y
CONFIG_EXPERT=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_COMPAT_BRK is not set
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_JUMP_LABEL=y
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBDAF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_EFI_PARTITION=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set

#
# Multiple platform selection
#

#
# CPU Core family selection
#
# CONFIG_ARCH_MULTI_V6 is not set
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_ARCH_BCM is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_MXC is not set
# CONFIG_ARCH_OMAP2PLUS is not set
# CONFIG_ARCH_SOCFPGA is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_SUNXI is not set
# CONFIG_ARCH_SIRF is not set
# CONFIG_ARCH_TEGRA is not set
CONFIG_ARCH_U8500=y
CONFIG_UX500_SOC_COMMON=y
CONFIG_UX500_SOC_DB8500=y

#
# Ux500 target platform (boards)
#
CONFIG_MACH_MOP500=y
CONFIG_MACH_HREFV60=y
CONFIG_MACH_SNOWBALL=y
CONFIG_UX500_AUTO_PLATFORM=y
CONFIG_MACH_UX500_DT=y
CONFIG_UX500_DEBUG_UART=2
# CONFIG_ARCH_VEXPRESS is not set
# CONFIG_ARCH_VIRT is not set
# CONFIG_ARCH_WM8850 is not set
# CONFIG_ARCH_ZYNQ is not set

#
# Processor Type
#
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_LPAE is not set
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
CONFIG_ARM_VIRT_EXT=y
CONFIG_SWP_EMULATE=y
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_CACHE_PL310=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_430973 is not set
# CONFIG_PL310_ERRATA_588369 is not set
# CONFIG_ARM_ERRATA_720789 is not set
# CONFIG_PL310_ERRATA_727915 is not set
CONFIG_PL310_ERRATA_753970=y
CONFIG_ARM_ERRATA_754322=y
# CONFIG_ARM_ERRATA_754327 is not set
CONFIG_ARM_ERRATA_764369=y
# CONFIG_PL310_ERRATA_769419 is not set
# CONFIG_ARM_ERRATA_775420 is not set
# CONFIG_ARM_ERRATA_798181 is not set

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_HAVE_SMP=y
CONFIG_SMP=y
CONFIG_SMP_ON_UP=y
CONFIG_ARM_CPU_TOPOLOGY=y
CONFIG_SCHED_MC=y
# CONFIG_SCHED_SMT is not set
CONFIG_HAVE_ARM_SCU=y
# CONFIG_HAVE_ARM_ARCH_TIMER is not set
CONFIG_HAVE_ARM_TWD=y
# CONFIG_MCPM is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_NR_CPUS=2
CONFIG_HOTPLUG_CPU=y
# CONFIG_ARM_PSCI is not set
CONFIG_LOCAL_TIMERS=y
CONFIG_ARCH_NR_GPIO=392
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
# CONFIG_HIGHMEM is not set
CONFIG_HW_PERF_EVENTS=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=32768
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_CLEANCACHE is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
CONFIG_SECCOMP=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_XEN is not set

#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0
CONFIG_ZBOOT_ROM_BSS=0
# CONFIG_ARM_APPENDED_DTB is not set
CONFIG_CMDLINE="root=/dev/ram0 console=ttyAMA2,115200n8"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_GOV_COMMON=y
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

#
# ARM CPU frequency scaling drivers
#
# CONFIG_ARM_EXYNOS4210_CPUFREQ is not set
# CONFIG_ARM_EXYNOS4X12_CPUFREQ is not set
# CONFIG_ARM_EXYNOS5250_CPUFREQ is not set
# CONFIG_ARM_KIRKWOOD_CPUFREQ is not set
CONFIG_CPU_IDLE=y
# CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
# CONFIG_FPE_NWFPE is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_COREDUMP=y

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
# CONFIG_XFRM_USER is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_FIB_TRIE_STATS is not set
CONFIG_IP_MULTIPLE_TABLES=y
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=y
# CONFIG_NET_IPGRE_DEMUX is not set
CONFIG_NET_IP_TUNNEL=y
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
CONFIG_NETWORK_SECMARK=y
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
CONFIG_VLAN_8021Q=y
# CONFIG_VLAN_8021Q_GVRP is not set
# CONFIG_VLAN_8021Q_MVRP is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_NETLINK_DIAG is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
CONFIG_BQL=y
# CONFIG_BPF_JIT is not set

#
# Network testing
#
CONFIG_NET_PKTGEN=y
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
CONFIG_BT=y
CONFIG_BT_RFCOMM=y
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=y
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=y

#
# Bluetooth device drivers
#
# CONFIG_BT_HCIBTUSB is not set
# CONFIG_BT_HCIBTSDIO is not set
CONFIG_BT_HCIUART=y
# CONFIG_BT_HCIUART_H4 is not set
# CONFIG_BT_HCIUART_BCSP is not set
# CONFIG_BT_HCIUART_ATH3K is not set
# CONFIG_BT_HCIUART_LL is not set
# CONFIG_BT_HCIUART_3WIRE is not set
# CONFIG_BT_HCIBCM203X is not set
# CONFIG_BT_HCIBPA10X is not set
# CONFIG_BT_HCIBFUSB is not set
# CONFIG_BT_HCIVHCI is not set
# CONFIG_BT_MRVL is not set
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_CFG80211=y
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
# CONFIG_CFG80211_CERTIFICATION_ONUS is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
CONFIG_CFG80211_WEXT=y
# CONFIG_LIB80211 is not set
CONFIG_MAC80211=y
CONFIG_MAC80211_HAS_RC=y
# CONFIG_MAC80211_RC_PID is not set
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel_ht"
# CONFIG_MAC80211_MESH is not set
# CONFIG_MAC80211_LEDS is not set
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_MESSAGE_TRACING is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
# CONFIG_RFKILL_INPUT is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_RFKILL_GPIO is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_SOC_BUS=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_SPI=y
# CONFIG_DMA_SHARED_BUFFER is not set
# CONFIG_CMA is not set

#
# Bus devices
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_MTD=y
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_OF_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
CONFIG_MTD_OOPS=y

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PHYSMAP_OF is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SST25L is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
CONFIG_MTD_NAND_ECC=y
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_ECC_BCH is not set
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_DENALI is not set
# CONFIG_MTD_NAND_GPIO is not set
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_DOCG4 is not set
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_ALAUDA is not set
# CONFIG_MTD_NAND_FSMC is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
# CONFIG_MTD_UBI is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
CONFIG_PROC_DEVICETREE=y
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
CONFIG_OF_MTD=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=2
CONFIG_BLK_DEV_RAM_SIZE=65536
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLK_DEV_RBD is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
CONFIG_SENSORS_BH1780=y
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_TI_DAC7512 is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_BMP085_SPI is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_LATTICE_ECP3_CONFIG is not set
# CONFIG_SRAM is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_AT25 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_EEPROM_93XX46 is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_ATA is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BCACHE is not set
# CONFIG_BLK_DEV_DM is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
# CONFIG_NET_VENDOR_CIRRUS is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
# CONFIG_NET_VENDOR_FARADAY is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_NET_VENDOR_MARVELL is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROCHIP is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_ETHOC is not set
# CONFIG_NET_VENDOR_SEEQ is not set
CONFIG_NET_VENDOR_SMSC=y
# CONFIG_SMC91X is not set
# CONFIG_SMC911X is not set
CONFIG_SMSC911X=y
# CONFIG_SMSC911X_ARCH_HOOKS is not set
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_WIZNET is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
CONFIG_SMSC_PHY=y
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_RTL8152 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_HSO is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
CONFIG_INPUT_MATRIXKMAP=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
# CONFIG_KEYBOARD_ATKBD is not set
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_KEYBOARD_NOMADIK=y
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
CONFIG_KEYBOARD_STMPE=y
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_ADS7846 is not set
# CONFIG_TOUCHSCREEN_AD7877 is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_EGALAX is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_ILI210X is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_WACOM_I2C is not set
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_PIXCIR is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
# CONFIG_TOUCHSCREEN_TSC2005 is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_W90X900 is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_STMPE is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_AB8500_PONKEY=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_MMA8450 is not set
# CONFIG_INPUT_MPU3050 is not set
# CONFIG_INPUT_GP2A is not set
# CONFIG_INPUT_GPIO_TILT_POLLED is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_KXTJ9 is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
CONFIG_INPUT_UINPUT=y
# CONFIG_INPUT_PCF8574 is not set
# CONFIG_INPUT_PWM_BEEPER is not set
# CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_IMS_PCU is not set
# CONFIG_INPUT_CMA3000 is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
# CONFIG_DEVKMEM is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_ATMEL is not set
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_GPIO is not set
CONFIG_I2C_NOMADIK=y
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
CONFIG_I2C_DEBUG_CORE=y
# CONFIG_I2C_DEBUG_ALGO is not set
CONFIG_I2C_DEBUG_BUS=y
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_GPIO is not set
# CONFIG_SPI_FSL_SPI is not set
# CONFIG_SPI_OC_TINY is not set
CONFIG_SPI_PL022=y
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_XCOMM is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set

#
# Qualcomm MSM SSBI bus support
#
# CONFIG_SSBI is not set
# CONFIG_HSI is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_PINCTRL=y

#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_GENERIC_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
CONFIG_PINCTRL_ABX500=y
CONFIG_PINCTRL_AB8500=y
CONFIG_PINCTRL_AB8540=y
CONFIG_PINCTRL_AB9540=y
CONFIG_PINCTRL_AB8505=y
CONFIG_PINCTRL_NOMADIK=y
CONFIG_PINCTRL_DB8500=y
CONFIG_PINCTRL_DB8540=y
# CONFIG_PINCTRL_SINGLE is not set
# CONFIG_PINCTRL_EXYNOS is not set
# CONFIG_PINCTRL_EXYNOS5440 is not set
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
# CONFIG_DEBUG_GPIO is not set
CONFIG_GPIO_SYSFS=y

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
# CONFIG_GPIO_PL061 is not set
# CONFIG_GPIO_RCAR is not set
# CONFIG_GPIO_TS5500 is not set
# CONFIG_GPIO_GRGPIO is not set

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
CONFIG_GPIO_STMPE=y
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_74X164 is not set

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#

#
# USB GPIO expanders:
#
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_GENERIC_ADC_BATTERY is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_GPIO is not set
# CONFIG_CHARGER_MANAGER is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_SMB347 is not set
CONFIG_AB8500_BM=y
# CONFIG_BATTERY_GOLDFISH is not set
# CONFIG_POWER_RESET is not set
# CONFIG_POWER_RESET_RESTART is not set
# CONFIG_POWER_AVS is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
CONFIG_SENSORS_AB8500=y
# CONFIG_SENSORS_AD7314 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADCXX is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7310 is not set
# CONFIG_SENSORS_ADT7410 is not set
# CONFIG_SENSORS_ADT7411 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS620 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_GPIO_FAN is not set
# CONFIG_SENSORS_HIH6130 is not set
CONFIG_SENSORS_IIO_HWMON=y
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_LINEAGE is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM70 is not set
# CONFIG_SENSORS_LM73 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4151 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_LM95234 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_MAX1111 is not set
# CONFIG_SENSORS_MAX16065 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX1668 is not set
# CONFIG_SENSORS_MAX197 is not set
# CONFIG_SENSORS_MAX6639 is not set
# CONFIG_SENSORS_MAX6642 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_MAX6697 is not set
# CONFIG_SENSORS_MCP3021 is not set
# CONFIG_SENSORS_NCT6775 is not set
# CONFIG_SENSORS_NTC_THERMISTOR is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_PMBUS is not set
# CONFIG_SENSORS_SHT15 is not set
# CONFIG_SENSORS_SHT21 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_EMC6W201 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SCH56XX_COMMON is not set
# CONFIG_SENSORS_SCH5627 is not set
# CONFIG_SENSORS_SCH5636 is not set
# CONFIG_SENSORS_ADS1015 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_ADS7871 is not set
# CONFIG_SENSORS_AMC6821 is not set
# CONFIG_SENSORS_INA209 is not set
# CONFIG_SENSORS_INA2XX is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP102 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83795 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
# CONFIG_THERMAL_GOV_FAIR_SHARE is not set
CONFIG_THERMAL_GOV_STEP_WISE=y
# CONFIG_THERMAL_GOV_USER_SPACE is not set
CONFIG_CPU_THERMAL=y
# CONFIG_THERMAL_EMULATION is not set
CONFIG_DB8500_THERMAL=y
CONFIG_DB8500_CPUFREQ_COOLING=y
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ARM_SP805_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_MPCORE_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
CONFIG_UX500_WATCHDOG=m

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SMSC is not set
CONFIG_ABX500_CORE=y
# CONFIG_AB3100_CORE is not set
CONFIG_AB8500_CORE=y
# CONFIG_AB8500_DEBUG is not set
CONFIG_AB8500_GPADC=y
CONFIG_MFD_DB8500_PRCMU=y
CONFIG_MFD_STMPE=y

#
# STMicroelectronics STMPE Interface Drivers
#
CONFIG_STMPE_I2C=y
CONFIG_STMPE_SPI=y
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
# CONFIG_REGULATOR_DUMMY is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_GPIO is not set
# CONFIG_REGULATOR_AD5398 is not set
# CONFIG_REGULATOR_FAN53555 is not set
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
# CONFIG_REGULATOR_MAX8973 is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_LP872X is not set
# CONFIG_REGULATOR_LP8755 is not set
CONFIG_REGULATOR_AB8500=y
CONFIG_REGULATOR_DBX500_PRCMU=y
CONFIG_REGULATOR_DB8500_PRCMU=y
# CONFIG_REGULATOR_TPS51632 is not set
# CONFIG_REGULATOR_TPS62360 is not set
# CONFIG_REGULATOR_TPS65023 is not set
# CONFIG_REGULATOR_TPS6507X is not set
# CONFIG_REGULATOR_TPS6524X is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_TEGRA_HOST1X is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_SOUND=y
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_COMPRESS_OFFLOAD=y
CONFIG_SND_JACK=y
# CONFIG_SND_SEQUENCER is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
# CONFIG_SND_HRTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
# CONFIG_SND_DRIVERS is not set
# CONFIG_SND_ARM is not set
# CONFIG_SND_SPI is not set
CONFIG_SND_USB=y
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_UA101 is not set
# CONFIG_SND_USB_CAIAQ is not set
# CONFIG_SND_USB_6FIRE is not set
CONFIG_SND_SOC=y
CONFIG_SND_SOC_DMAENGINE_PCM=y
CONFIG_SND_SOC_GENERIC_DMAENGINE_PCM=y
# CONFIG_SND_ATMEL_SOC is not set
# CONFIG_SND_DESIGNWARE_I2S is not set
CONFIG_SND_SOC_UX500=y
CONFIG_SND_SOC_UX500_PLAT_MSP_I2S=y
CONFIG_SND_SOC_UX500_PLAT_DMA=y
CONFIG_SND_SOC_UX500_MACH_MOP500=y
CONFIG_SND_SOC_I2C_AND_SPI=y
# CONFIG_SND_SOC_ALL_CODECS is not set
CONFIG_SND_SOC_AB8500_CODEC=y
# CONFIG_SND_SIMPLE_CARD is not set
# CONFIG_SOUND_PRIME is not set

#
# HID support
#
CONFIG_HID=y
# CONFIG_HID_BATTERY_STRENGTH is not set
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_APPLEIR is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_PRODIKEYS is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MAGICMOUSE is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_PS3REMOTE is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THINGM is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_WACOM is not set
# CONFIG_HID_WIIMOTE is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set

#
# USB HID support
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
# CONFIG_USB_ARCH_HAS_OHCI is not set
# CONFIG_USB_ARCH_HAS_EHCI is not set
# CONFIG_USB_ARCH_HAS_XHCI is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_OTG=y
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_MON is not set
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
CONFIG_USB_MUSB_HDRC=y
# CONFIG_USB_MUSB_TUSB6010 is not set
# CONFIG_USB_MUSB_DSPS is not set
CONFIG_USB_MUSB_UX500=m
CONFIG_USB_UX500_DMA=y
# CONFIG_MUSB_PIO_ONLY is not set
# CONFIG_USB_RENESAS_USBHS is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_DWC3 is not set
# CONFIG_USB_CHIPIDEA is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set
# CONFIG_USB_HSIC_USB3503 is not set
# CONFIG_USB_PHY is not set
CONFIG_USB_GADGET=y
# CONFIG_USB_GADGET_DEBUG is not set
# CONFIG_USB_GADGET_DEBUG_FILES is not set
# CONFIG_USB_GADGET_DEBUG_FS is not set
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2

#
# USB Peripheral Controller
#
# CONFIG_USB_FUSB300 is not set
# CONFIG_USB_R8A66597 is not set
# CONFIG_USB_PXA27X is not set
# CONFIG_USB_MV_UDC is not set
# CONFIG_USB_MV_U3D is not set
# CONFIG_USB_GADGET_MUSB_HDRC is not set
# CONFIG_USB_M66592 is not set
# CONFIG_USB_NET2272 is not set
# CONFIG_USB_DUMMY_HCD is not set
# CONFIG_USB_ZERO is not set
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_ETH is not set
# CONFIG_USB_G_NCM is not set
# CONFIG_USB_GADGETFS is not set
# CONFIG_USB_FUNCTIONFS is not set
# CONFIG_USB_MASS_STORAGE is not set
# CONFIG_USB_G_SERIAL is not set
# CONFIG_USB_MIDI_GADGET is not set
# CONFIG_USB_G_PRINTER is not set
# CONFIG_USB_CDC_COMPOSITE is not set
# CONFIG_USB_G_ACM_MS is not set
# CONFIG_USB_G_MULTI is not set
# CONFIG_USB_G_HID is not set
# CONFIG_USB_G_DBGP is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_ARMMMCI=y
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
# CONFIG_MMC_SPI is not set
# CONFIG_MMC_DW is not set
# CONFIG_MMC_VUB300 is not set
# CONFIG_MMC_USHC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
CONFIG_LEDS_LM3530=y
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
CONFIG_LEDS_GPIO=y
# CONFIG_LEDS_LP3944 is not set
CONFIG_LEDS_LP55XX_COMMON=y
CONFIG_LEDS_LP5521=y
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_LP5562 is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA9633 is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_PWM is not set
# CONFIG_LEDS_REGULATOR is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_LT3593 is not set
# CONFIG_LEDS_RENESAS_TPU is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_LM355x is not set
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set

#
# LED Triggers
#
# CONFIG_LEDS_TRIGGERS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
# CONFIG_RTC_DRV_RX4581 is not set

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# CONFIG_RTC_DRV_DS2404 is not set
CONFIG_RTC_DRV_AB8500=y

#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_PL030 is not set
CONFIG_RTC_DRV_PL031=y
# CONFIG_RTC_DRV_SNVS is not set

#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
# CONFIG_AMBA_PL08X is not set
# CONFIG_DW_DMAC is not set
CONFIG_STE_DMA40=y
# CONFIG_TIMB_DMA is not set
# CONFIG_PL330_DMA is not set
CONFIG_DMA_ENGINE=y
CONFIG_DMA_OF=y

#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VIRT_DRIVERS is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
CONFIG_STAGING=y
# CONFIG_USBIP_CORE is not set
# CONFIG_ECHO is not set
# CONFIG_COMEDI is not set
# CONFIG_ASUS_OLED is not set
# CONFIG_TRANZPORT is not set
# CONFIG_LINE6_USB is not set

#
# IIO staging drivers
#

#
# Accelerometers
#
# CONFIG_ADIS16201 is not set
# CONFIG_ADIS16203 is not set
# CONFIG_ADIS16204 is not set
# CONFIG_ADIS16209 is not set
# CONFIG_ADIS16220 is not set
# CONFIG_ADIS16240 is not set
# CONFIG_LIS3L02DQ is not set
# CONFIG_SCA3000 is not set

#
# Analog to digital converters
#
# CONFIG_AD7291 is not set
# CONFIG_AD7606 is not set
# CONFIG_AD799X is not set
# CONFIG_AD7780 is not set
# CONFIG_AD7816 is not set
# CONFIG_AD7192 is not set
# CONFIG_AD7280 is not set

#
# Analog digital bi-direction converters
#
# CONFIG_ADT7316 is not set

#
# Capacitance to digital converters
#
# CONFIG_AD7150 is not set
# CONFIG_AD7152 is not set
# CONFIG_AD7746 is not set

#
# Direct Digital Synthesis
#
# CONFIG_AD5930 is not set
# CONFIG_AD9832 is not set
# CONFIG_AD9834 is not set
# CONFIG_AD9850 is not set
# CONFIG_AD9852 is not set
# CONFIG_AD9910 is not set
# CONFIG_AD9951 is not set

#
# Digital gyroscope sensors
#
# CONFIG_ADIS16060 is not set
# CONFIG_ADIS16130 is not set
# CONFIG_ADIS16260 is not set

#
# Network Analyzer, Impedance Converters
#
# CONFIG_AD5933 is not set

#
# Light sensors
#
# CONFIG_SENSORS_ISL29018 is not set
# CONFIG_SENSORS_ISL29028 is not set
# CONFIG_TSL2583 is not set
# CONFIG_TSL2x7x is not set

#
# Magnetometer sensors
#
# CONFIG_SENSORS_HMC5843 is not set

#
# Active energy metering IC
#
# CONFIG_ADE7753 is not set
# CONFIG_ADE7754 is not set
# CONFIG_ADE7758 is not set
# CONFIG_ADE7759 is not set
# CONFIG_ADE7854 is not set

#
# Resolver to digital converters
#
# CONFIG_AD2S90 is not set
# CONFIG_AD2S1200 is not set
# CONFIG_AD2S1210 is not set

#
# Triggers - standalone
#
# CONFIG_IIO_PERIODIC_RTC_TRIGGER is not set
# CONFIG_IIO_GPIO_TRIGGER is not set
# CONFIG_IIO_SYSFS_TRIGGER is not set
# CONFIG_IIO_SIMPLE_DUMMY is not set
# CONFIG_ZSMALLOC is not set
# CONFIG_BCM_WIMAX is not set
# CONFIG_FT1000 is not set

#
# Speakup console speech
#
# CONFIG_SPEAKUP is not set
# CONFIG_TOUCHSCREEN_CLEARPAD_TM1217 is not set
# CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set
# CONFIG_STAGING_MEDIA is not set

#
# Android
#
# CONFIG_ANDROID is not set
# CONFIG_USB_WPAN_HCD is not set
# CONFIG_WIMAX_GDM72XX is not set
# CONFIG_CSR_WIFI is not set
# CONFIG_CED1401 is not set
# CONFIG_DGRP is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_DEBUG is not set
# CONFIG_COMMON_CLK_SI5351 is not set
CONFIG_HWSPINLOCK=y

#
# Hardware Spinlock drivers
#
CONFIG_HSEM_U8500=y
CONFIG_CLKSRC_OF=y
CONFIG_CLKSRC_MMIO=y
CONFIG_CLKSRC_NOMADIK_MTU=y
CONFIG_CLKSRC_DBX500_PRCMU=y
CONFIG_CLKSRC_DBX500_PRCMU_SCHED_CLOCK=y
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
CONFIG_IIO=y
CONFIG_IIO_BUFFER=y
# CONFIG_IIO_BUFFER_CB is not set
CONFIG_IIO_KFIFO_BUF=y
CONFIG_IIO_TRIGGERED_BUFFER=y
CONFIG_IIO_TRIGGER=y
CONFIG_IIO_CONSUMERS_PER_TRIGGER=2

#
# Accelerometers
#
# CONFIG_KXSD9 is not set
CONFIG_IIO_ST_ACCEL_3AXIS=y
CONFIG_IIO_ST_ACCEL_I2C_3AXIS=y
CONFIG_IIO_ST_ACCEL_SPI_3AXIS=y

#
# Analog to digital converters
#
# CONFIG_AD7266 is not set
# CONFIG_AD7298 is not set
# CONFIG_AD7923 is not set
# CONFIG_AD7791 is not set
# CONFIG_AD7793 is not set
# CONFIG_AD7476 is not set
# CONFIG_AD7887 is not set
# CONFIG_EXYNOS_ADC is not set
# CONFIG_MAX1363 is not set
# CONFIG_TI_ADC081C is not set

#
# Amplifiers
#
# CONFIG_AD8366 is not set

#
# Hid Sensor IIO Common
#
CONFIG_IIO_ST_SENSORS_I2C=y
CONFIG_IIO_ST_SENSORS_SPI=y
CONFIG_IIO_ST_SENSORS_CORE=y

#
# Digital to analog converters
#
# CONFIG_AD5064 is not set
# CONFIG_AD5360 is not set
# CONFIG_AD5380 is not set
# CONFIG_AD5421 is not set
# CONFIG_AD5624R_SPI is not set
# CONFIG_AD5446 is not set
# CONFIG_AD5449 is not set
# CONFIG_AD5504 is not set
# CONFIG_AD5755 is not set
# CONFIG_AD5764 is not set
# CONFIG_AD5791 is not set
# CONFIG_AD5686 is not set
# CONFIG_MAX517 is not set
# CONFIG_MCP4725 is not set

#
# Frequency Synthesizers DDS/PLL
#

#
# Clock Generator/Distribution
#
# CONFIG_AD9523 is not set

#
# Phase-Locked Loop (PLL) frequency synthesizers
#
# CONFIG_ADF4350 is not set

#
# Digital gyroscope sensors
#
# CONFIG_ADIS16080 is not set
# CONFIG_ADIS16136 is not set
# CONFIG_ADXRS450 is not set
CONFIG_IIO_ST_GYRO_3AXIS=y
CONFIG_IIO_ST_GYRO_I2C_3AXIS=y
CONFIG_IIO_ST_GYRO_SPI_3AXIS=y
# CONFIG_ITG3200 is not set

#
# Inertial measurement units
#
# CONFIG_ADIS16400 is not set
# CONFIG_ADIS16480 is not set
# CONFIG_INV_MPU6050_IIO is not set

#
# Light sensors
#
# CONFIG_ADJD_S311 is not set
# CONFIG_SENSORS_TSL2563 is not set
# CONFIG_VCNL4000 is not set

#
# Magnetometer sensors
#
# CONFIG_AK8975 is not set
CONFIG_IIO_ST_MAGN_3AXIS=y
CONFIG_IIO_ST_MAGN_I2C_3AXIS=y
CONFIG_IIO_ST_MAGN_SPI_3AXIS=y
CONFIG_PWM=y
CONFIG_PWM_AB8500=y
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_EXT4_FS=y
# CONFIG_EXT4_FS_POSIX_ACL is not set
# CONFIG_EXT4_FS_SECURITY is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_BTRFS_FS=y
# CONFIG_BTRFS_FS_POSIX_ACL is not set
# CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
# CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
# CONFIG_BTRFS_DEBUG is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
CONFIG_SQUASHFS=y
# CONFIG_SQUASHFS_XATTR is not set
CONFIG_SQUASHFS_ZLIB=y
# CONFIG_SQUASHFS_LZO is not set
# CONFIG_SQUASHFS_XZ is not set
# CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set
# CONFIG_SQUASHFS_EMBEDDED is not set
CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_SWAP is not set
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_NLS_UTF8 is not set
# CONFIG_DLM is not set

#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
# CONFIG_SCHED_DEBUG is not set
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set

#
# RCU Debugging
#
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
# CONFIG_RCU_CPU_STALL_INFO is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
CONFIG_STRICT_DEVMEM=y
CONFIG_ARM_UNWIND=y
CONFIG_DEBUG_USER=y
# CONFIG_DEBUG_LL is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
# CONFIG_OC_ETM is not set
# CONFIG_PID_IN_CONTEXTIDR is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_XOR_BLOCKS=y
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_PCRYPT is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA1_ARM is not set
CONFIG_CRYPTO_SHA256=y
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=y
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_UX500=y
CONFIG_CRYPTO_DEV_UX500_CRYP=y
CONFIG_CRYPTO_DEV_UX500_HASH=y
# CONFIG_CRYPTO_DEV_UX500_DEBUG is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_RAID6_PQ=y
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
CONFIG_CRC7=y
CONFIG_LIBCRC32C=y
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
# CONFIG_VIRTUALIZATION is not set

From arnd at arndb.de  Thu Jul 25 03:54:26 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Jul 2013 09:54:26 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51F0B373.5050907@ti.com>
References: <Pine.LNX.4.44L0.1307231708020.1304-100000@iolanthe.rowland.org>
 <201307242032.03597.arnd@arndb.de> <51F0B373.5050907@ti.com>
Message-ID: <201307250954.27190.arnd@arndb.de>

On Thursday 25 July 2013, Kishon Vijay Abraham I wrote:
> On Thursday 25 July 2013 12:02 AM, Arnd Bergmann wrote:
> > On Tuesday 23 July 2013, Tomasz Figa wrote:
> >> On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
> >>> On Tue, 23 Jul 2013, Tomasz Figa wrote:
> >>>> Where would you want to have those phy_address arrays stored? There
> >>>> are no board files when booting with DT. Not even saying that you
> >>>> don't need to use any hacky schemes like this when you have DT that
> >>>> nicely specifies relations between devices.
> >>>
> >>> If everybody agrees DT has a nice scheme for specifying relations
> >>> between devices, why not use that same scheme in the PHY core?
> >>
> >> It is already used, for cases when consumer device has a DT node attached. 
> >> In non-DT case this kind lookup translates loosely to something that is 
> >> being done in regulator framework - you can't bind devices by pointers, 
> >> because you don't have those pointers, so you need to use device names.
> >>
> > 
> > Sorry for jumping in to the middle of the discussion, but why does a new
> > framework even bother defining an interface for board files?
> > 
> > Can't we just drop any interfaces for platform data passing in the phy
> > framework and put the burden of adding those to anyone who actually needs
> > them? All the platforms we are concerned with here (exynos and omap,
> > plus new platforms) can be booted using DT anyway.
> 
> The OMAP3 platforms still needs to be supported for non-dt :-s

Can't you leave the existing PHY handling for legacy OMAP3 USB PHY
until they are all converted? I don't expect that to take a long time
now that the OMAP4 board files have been removed. Are there still
drivers without DT bindings that hold up the removal of the OMAP3
board files?

Otherwise I'd suggest delaying the phy subsystem by another merge window,
until that is resolved.

	Arnd


From josh.wu at atmel.com  Thu Jul 25 03:56:38 2013
From: josh.wu at atmel.com (Josh Wu)
Date: Thu, 25 Jul 2013 15:56:38 +0800
Subject: [PATCH 5/5] iio: at91: introduce touch screen support in iio
 adc driver
In-Reply-To: <20130722131747.GA32221@e106331-lin.cambridge.arm.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-6-git-send-email-josh.wu@atmel.com>
 <20130722131747.GA32221@e106331-lin.cambridge.arm.com>
Message-ID: <51F0DA36.3090608@atmel.com>

Hi, Dear Mark

On 7/22/2013 9:17 PM, Mark Rutland wrote:
> On Sun, Jul 14, 2013 at 09:04:29AM +0100, Josh Wu wrote:
>> AT91 ADC hardware integrate touch screen support. So this patch add touch
>> screen support for at91 adc iio driver.
>> To enable touch screen support in adc, you need to add the dt parameters:
>>    which type of touch are used? (4 or 5 wires), sample period time,
>>    pen detect debounce time, average samples and pen detect resistor.
>>
>> In the meantime, since touch screen will use a interal period trigger of adc,
>> so it is conflict to other hardware triggers. Driver will disable the hardware
>> trigger support if touch screen is enabled.
>>
>> This driver has been tested in AT91SAM9X5-EK and SAMA5D3x-EK.
>>
>> Signed-off-by: Josh Wu <josh.wu at atmel.com>
>> Cc: Dmitry Torokhov <dmitry.torokhov at gmail.com>
>> ---
>>   .../devicetree/bindings/arm/atmel-adc.txt          |   13 +
>>   arch/arm/mach-at91/include/mach/at91_adc.h         |   34 ++
>>   drivers/iio/adc/at91_adc.c                         |  389 ++++++++++++++++++--
>>   3 files changed, 412 insertions(+), 24 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> index 0db2945..925d656 100644
>> --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> @@ -29,6 +29,19 @@ Optional properties:
>>     - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
>>     - atmel,adc-clock-rate: ADC clock rate. If not specified, use the default
>>                            adc_op_clk.
>> +  - atmel,adc-touchscreen-wires: Number of touch screen wires. Only support
>> +                                4 and 5 wires touch screen.
> Are 4 and 5 wire configurations that can exist, or the only ones
> supported by the driver?

It can be set:

atmel,adc-touchscreen-wires = <4>;
or
atmel,adc-touchscreen-wires = <5>;

according to your touch screen.

>
>> +    NOTE: when adc touch screen enabled, the adc hardware trigger will be
>> +          disabled. Since touch screen will occupied the trigger register.
>> +  - atmel,adc-ts-pendet-debounce: Debounce time in microsecond for touch pen
>> +                                 detect.
> For consistency with the adc-touchscreen-wires property, and  other
> properties with timing information, how about
> atmel,adc-touchscreen-debounce-delay-us ?

sound nice to me.

>
>> +  - atmel,adc-ts-sample-period-time: Sample Period Time in microsecond for
>> +                                    touch screen
> Again, please be consistent with ts or touchscreen. It may also be good
> to have -us to make the units explicit (though it does leave the
> property name being quite a mothful):
>
> atmel,adc-touchscreen-sample-period-us ?

nice. I will use this one.

>
>> +  - atmel,adc-ts-filter-average: Numbers of sampling data will be averaged.
>> +    0 means no average. 1 means average two samples. 2 means average four
>> +    samples. 3 means average eight samples.
> Is this averaging done in the hardware, or the kernel driver?

It is done in the hardware.
But for some soc, like AT91SAM9G45, hardware doesn't support hardware 
average.
So I am wondering use it as for both hardware and softer average.

BTW, you mentioned the kernel driver, do you mean a filter algorithm is 
already implemented in kernel library?

>
> If it's the latter, this can be left for the kernel to decide.
>
>> +  - atmel,adc-ts-pendet-sensitivity: Pen Detection input pull-up resistor.
>> +    It can be 0, 1, 2, 3.
> I think "pendet" is a bit opaque. "pen-detect" may be better.

yes. I'll change this.

> What
> physical property does this represent (are these discrete values, or an
> enumeration)?

This property is supported by hardware, it can change the adc internal 
resistor value for better pen detection,
      * 0 = 200 kOhm, 1 = 150 kOhm, 2 = 100 kOhm, 3 = 50 kOhm
In general, we just use default value 2 for 100kOhm.

I think I need add more detail infomation in the dt document.

Thanks again,
Best Regards,
Josh Wu

>
> Thanks,
> Mark.
>
>>   Optional trigger Nodes:
>>     - Required properties:
>> diff --git a/arch/arm/mach-at91/include/mach/at91_adc.h b/arch/arm/mach-at91/include/mach/at91_adc.h
>> index ab273ee..6d6cc14 100644
>> --- a/arch/arm/mach-at91/include/mach/at91_adc.h
>> +++ b/arch/arm/mach-at91/include/mach/at91_adc.h
>> @@ -57,10 +57,44 @@
>>   #define AT91_ADC_IER           0x24            /* Interrupt Enable Register */
>>   #define AT91_ADC_IDR           0x28            /* Interrupt Disable Register */
>>   #define AT91_ADC_IMR           0x2C            /* Interrupt Mask Register */
>> +#define                AT91_ADC_IER_PEN        (1 << 29)
>> +#define                AT91_ADC_IER_NOPEN      (1 << 30)
>> +#define                AT91_ADC_IER_XRDY       (1 << 20)
>> +#define                AT91_ADC_IER_YRDY       (1 << 21)
>> +#define                AT91_ADC_IER_PRDY       (1 << 22)
>> +#define                AT91_ADC_ISR_PENS       (1 << 31)
>>
>>   #define AT91_ADC_CHR(n)                (0x30 + ((n) * 4))      /* Channel Data Register N */
>>   #define                AT91_ADC_DATA           (0x3ff)
>>
>> +#define AT91_ADC_ACR           0x94    /* Analog Control Register */
>> +#define                AT91_ADC_ACR_PENDETSENS (0x3 << 0)      /* pull-up resistor */
>> +
>> +#define AT91_ADC_TSMR          0xB0
>> +#define                AT91_ADC_TSMR_TSMODE    (3 << 0)        /* Touch Screen Mode */
>> +#define                        AT91_ADC_TSMR_TSMODE_NONE               (0 << 0)
>> +#define                        AT91_ADC_TSMR_TSMODE_4WIRE_NO_PRESS     (1 << 0)
>> +#define                        AT91_ADC_TSMR_TSMODE_4WIRE_PRESS        (2 << 0)
>> +#define                        AT91_ADC_TSMR_TSMODE_5WIRE              (3 << 0)
>> +#define                AT91_ADC_TSMR_TSAV      (3 << 4)        /* Averages samples */
>> +#define                        AT91_ADC_TSMR_TSAV_(x)          ((x) << 4)
>> +#define                AT91_ADC_TSMR_SCTIM     (0x0f << 16)    /* Switch closure time */
>> +#define                AT91_ADC_TSMR_PENDBC    (0x0f << 28)    /* Pen Debounce time */
>> +#define                        AT91_ADC_TSMR_PENDBC_(x)        ((x) << 28)
>> +#define                AT91_ADC_TSMR_NOTSDMA   (1 << 22)       /* No Touchscreen DMA */
>> +#define                AT91_ADC_TSMR_PENDET_DIS        (0 << 24)       /* Pen contact detection disable */
>> +#define                AT91_ADC_TSMR_PENDET_ENA        (1 << 24)       /* Pen contact detection enable */
>> +
>> +#define AT91_ADC_TSXPOSR       0xB4
>> +#define AT91_ADC_TSYPOSR       0xB8
>> +#define AT91_ADC_TSPRESSR      0xBC
>> +
>>   #define AT91_ADC_VERSION       0xFC
>>
>> +/* Trigger Register bit field */
>> +#define                AT91_ADC_TRGR_TRGPER    (0xffff << 16)
>> +#define                        AT91_ADC_TRGR_TRGPER_(x)        ((x) << 16)
>> +#define                AT91_ADC_TRGR_TRGMOD    (0x7 << 0)
>> +#define                        AT91_ADC_TRGR_MOD_PERIOD_TRIG   (5 << 0)
>> +
>>   #endif
>> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
>> index 8f1386f..ffc0e42 100644
>> --- a/drivers/iio/adc/at91_adc.c
>> +++ b/drivers/iio/adc/at91_adc.c
>> @@ -11,6 +11,7 @@
>>   #include <linux/clk.h>
>>   #include <linux/err.h>
>>   #include <linux/io.h>
>> +#include <linux/input.h>
>>   #include <linux/interrupt.h>
>>   #include <linux/jiffies.h>
>>   #include <linux/kernel.h>
>> @@ -39,12 +40,24 @@
>>   #define at91_adc_writel(st, reg, val) \
>>          (writel_relaxed(val, st->reg_base + reg))
>>
>> +#define DRIVER_NAME            "at91_adc"
>> +#define MAX_POS_BITS           12
>> +
>> +#define ZTHRESHOLD             9000
>> +
>>   struct at91_adc_caps {
>> +       bool    has_12bits_xy;  /* true means use 12 bits. Otherwise 10 bits */
>>          bool    has_tsmr;       /* only at91sam9x5, sama5d3 have TSMR reg */
>>          u32     mr_prescal_mask;
>>          u32     mr_startup_mask;
>>   };
>>
>> +enum atmel_adc_ts_type {
>> +       ATMEL_ADC_TOUCHSCREEN_NONE = 0,
>> +       ATMEL_ADC_TOUCHSCREEN_4WIRE,
>> +       ATMEL_ADC_TOUCHSCREEN_5WIRE,
>> +};
>> +
>>   struct at91_adc_state {
>>          struct clk              *adc_clk;
>>          u32                     adc_clk_rate;
>> @@ -70,6 +83,29 @@ struct at91_adc_state {
>>          bool                    low_res;        /* the resolution corresponds to the lowest one */
>>          wait_queue_head_t       wq_data_avail;
>>          struct at91_adc_caps    caps;
>> +
>> +       /*
>> +        * Following ADC channels are shared by touchscreen:
>> +        *
>> +        * CH0 -- Touch screen XP/UL
>> +        * CH1 -- Touch screen XM/UR
>> +        * CH2 -- Touch screen YP/LL
>> +        * CH3 -- Touch screen YM/Sense
>> +        * CH4 -- Touch screen LR(5-wire only)
>> +        *
>> +        * The bitfields below represents the reserved channel in the
>> +        * touchscreen mode.
>> +        */
>> +#define CHAN_MASK_TOUCHSCREEN_4WIRE    (0xf << 0)
>> +#define CHAN_MASK_TOUCHSCREEN_5WIRE    (0x1f << 0)
>> +       enum atmel_adc_ts_type  touchscreen_type;
>> +       struct input_dev                *ts_input;
>> +
>> +       u8                      ts_filter_average;
>> +       u16                     ts_pen_detect_debounce;
>> +       u8                      ts_pen_detect_sensitivity;
>> +       u16                     ts_sample_period_time;
>> +       u16                     ts_sample_period_val;
>>   };
>>
>>   static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
>> @@ -104,14 +140,10 @@ static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
>>          return IRQ_HANDLED;
>>   }
>>
>> -static irqreturn_t at91_adc_eoc_trigger(int irq, void *private)
>> +/* Handler for classic adc channel eoc trigger */
>> +void handle_adc_eoc_trigger(int irq, struct iio_dev *idev)
>>   {
>> -       struct iio_dev *idev = private;
>>          struct at91_adc_state *st = iio_priv(idev);
>> -       u32 status = at91_adc_readl(st, st->registers->status_register);
>> -
>> -       if (!(status & st->registers->drdy_mask))
>> -               return IRQ_HANDLED;
>>
>>          if (iio_buffer_enabled(idev)) {
>>                  disable_irq_nosync(irq);
>> @@ -121,6 +153,115 @@ static irqreturn_t at91_adc_eoc_trigger(int irq, void *private)
>>                  st->done = true;
>>                  wake_up_interruptible(&st->wq_data_avail);
>>          }
>> +}
>> +
>> +static int at91_ts_sample(struct at91_adc_state *st)
>> +{
>> +       unsigned int xscale, yscale, reg, z1, z2;
>> +       unsigned int x, y, pres, xpos, ypos;
>> +       unsigned int rxp = 1;
>> +       unsigned int factor = 1000;
>> +       struct iio_dev *idev = iio_priv_to_dev(st);
>> +
>> +       unsigned int xyz_mask_bits = st->caps.has_12bits_xy ? 12 : 10;
>> +       unsigned int xyz_mask = (1 << xyz_mask_bits) - 1;
>> +
>> +       /* calculate position */
>> +       /* x position = (x / xscale) * max, max = 2^MAX_POS_BITS - 1 */
>> +       reg = at91_adc_readl(st, AT91_ADC_TSXPOSR);
>> +       xpos = reg & xyz_mask;
>> +       x = (xpos << MAX_POS_BITS) - xpos;
>> +       xscale = (reg >> 16) & xyz_mask;
>> +       if (xscale != 0)
>> +               x /= xscale;
>> +       else
>> +               dev_err(&idev->dev, "xscale == 0!!!\n");
>> +
>> +       /* y position = (y / yscale) * max, max = 2^MAX_POS_BITS - 1 */
>> +       reg = at91_adc_readl(st, AT91_ADC_TSYPOSR);
>> +       ypos = reg & xyz_mask;
>> +       y = (ypos << MAX_POS_BITS) - ypos;
>> +       yscale = (reg >> 16) & xyz_mask;
>> +       if (yscale != 0)
>> +               y /= yscale;
>> +       else
>> +               dev_err(&idev->dev, "yscale == 0!!!\n");
>> +
>> +       /* calculate the pressure */
>> +       reg = at91_adc_readl(st, AT91_ADC_TSPRESSR);
>> +       z1 = reg & xyz_mask;
>> +       z2 = (reg >> 16) & xyz_mask;
>> +
>> +       if (z1 != 0)
>> +               pres = rxp * (x * factor / 1024) * (z2 * factor / z1 - factor)
>> +                       / factor;
>> +       else
>> +               pres = ZTHRESHOLD;      /* no pen contacted */
>> +
>> +       dev_dbg(&idev->dev, "xpos = %d, xscale = %d, ypos = %d, yscale = %d, z1 = %d, z2 = %d, press = %d\n",
>> +                               xpos, xscale, ypos, yscale, z1, z2, pres);
>> +
>> +       if (pres < ZTHRESHOLD) {
>> +               dev_dbg(&idev->dev, "x = %d, y = %d, pressure = %d\n",
>> +                                       x, y, pres / factor);
>> +               input_report_abs(st->ts_input, ABS_X, x);
>> +               input_report_abs(st->ts_input, ABS_Y, y);
>> +               input_report_abs(st->ts_input, ABS_PRESSURE, pres);
>> +               input_report_key(st->ts_input, BTN_TOUCH, 1);
>> +               input_sync(st->ts_input);
>> +       } else {
>> +               dev_dbg(&idev->dev,
>> +                               "pressure too low: not reporting\n");
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +
>> +static irqreturn_t at91_adc_interrupt(int irq, void *private)
>> +{
>> +       struct iio_dev *idev = private;
>> +       struct at91_adc_state *st = iio_priv(idev);
>> +       u32 status = at91_adc_readl(st, st->registers->status_register);
>> +       const uint32_t ts_data_irq_mask =
>> +               AT91_ADC_IER_XRDY |
>> +               AT91_ADC_IER_YRDY |
>> +               AT91_ADC_IER_PRDY;
>> +
>> +       if (status & st->registers->drdy_mask)
>> +               handle_adc_eoc_trigger(irq, idev);
>> +
>> +       if (status & AT91_ADC_IER_PEN) {
>> +               at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_PEN);
>> +               at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_NOPEN |
>> +                       ts_data_irq_mask);
>> +               /* Set up period trigger for sampling */
>> +               at91_adc_writel(st, st->registers->trigger_register,
>> +                       AT91_ADC_TRGR_MOD_PERIOD_TRIG |
>> +                       AT91_ADC_TRGR_TRGPER_(st->ts_sample_period_val));
>> +       } else if (status & AT91_ADC_IER_NOPEN) {
>> +               at91_adc_writel(st, st->registers->trigger_register, 0);
>> +               at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_NOPEN |
>> +                       ts_data_irq_mask);
>> +               at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_PEN);
>> +
>> +               input_report_key(st->ts_input, BTN_TOUCH, 0);
>> +               input_sync(st->ts_input);
>> +       } else if ((status & ts_data_irq_mask) == ts_data_irq_mask) {
>> +               /* Now all touchscreen data is ready */
>> +
>> +               if (status & AT91_ADC_ISR_PENS) {
>> +                       /* validate data by pen contact */
>> +                       at91_ts_sample(st);
>> +               } else {
>> +                       /* triggered by event that is no pen contact, just read
>> +                        * them to clean the interrupt and discard all.
>> +                        */
>> +                       at91_adc_readl(st, AT91_ADC_TSXPOSR);
>> +                       at91_adc_readl(st, AT91_ADC_TSYPOSR);
>> +                       at91_adc_readl(st, AT91_ADC_TSPRESSR);
>> +               }
>> +       }
>>
>>          return IRQ_HANDLED;
>>   }
>> @@ -130,6 +271,16 @@ static int at91_adc_channel_init(struct iio_dev *idev)
>>          struct at91_adc_state *st = iio_priv(idev);
>>          struct iio_chan_spec *chan_array, *timestamp;
>>          int bit, idx = 0;
>> +       unsigned long rsvd_mask = 0;
>> +
>> +       /* If touchscreen is enable, then reserve the adc channels */
>> +       if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_4WIRE)
>> +               rsvd_mask = CHAN_MASK_TOUCHSCREEN_4WIRE;
>> +       else if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_5WIRE)
>> +               rsvd_mask = CHAN_MASK_TOUCHSCREEN_5WIRE;
>> +
>> +       /* set up the channel mask to reserve touchscreen channels */
>> +       st->channels_mask &= ~rsvd_mask;
>>
>>          idev->num_channels = bitmap_weight(&st->channels_mask,
>>                                             st->num_channels) + 1;
>> @@ -561,6 +712,57 @@ static int at91_adc_probe_dt(struct at91_adc_state *st,
>>                  i++;
>>          }
>>
>> +       /* Check if touchscreen is enabled in DT. */
>> +       ret = of_property_read_u32(node, "atmel,adc-touchscreen-wires", &prop);
>> +       if (ret)
>> +               dev_info(&idev->dev, "Touchscreen not enabled.\n");
>> +       else if (prop == 4)
>> +               st->touchscreen_type = ATMEL_ADC_TOUCHSCREEN_4WIRE;
>> +       else if (prop == 5)
>> +               st->touchscreen_type = ATMEL_ADC_TOUCHSCREEN_5WIRE;
>> +       else
>> +               dev_warn(&idev->dev, "Unsupported number of touchscreen wires (%d)\n",
>> +                               prop);
>> +
>> +       if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_NONE)
>> +               return 0;
>> +
>> +       /* Touch screen is enabled, so check touch screen dt parameters */
>> +       if (of_property_read_u32(node, "atmel,adc-ts-filter-average", &prop)) {
>> +               dev_err(&idev->dev, "Missing atmel,adc-ts-filtering-average property in the DT.\n");
>> +               ret = -EINVAL;
>> +               goto error_ret;
>> +       }
>> +       st->ts_filter_average = prop;
>> +       if (st->ts_filter_average > 3) {
>> +               dev_err(&idev->dev, "Invalid atmel,adc-ts-filtering-average property in the DT.\n");
>> +               ret = -EINVAL;
>> +               goto error_ret;
>> +       }
>> +
>> +       prop = 0;
>> +       of_property_read_u32(node, "atmel,adc-ts-pendet-debounce", &prop);
>> +       st->ts_pen_detect_debounce = prop;
>> +
>> +       /* default sample period is 2ms. The real touch sample period should be
>> +        * this period * TSFREQ.
>> +        */
>> +       prop = 2000;
>> +       of_property_read_u32(node, "atmel,adc-ts-sample-period-time", &prop);
>> +       st->ts_sample_period_time = prop;
>> +
>> +       if (of_property_read_u32(node, "atmel,adc-ts-pendet-sensitivity", &prop)) {
>> +               dev_err(&idev->dev, "Missing atmel,adc-ts-pendet-sensitivity property in the DT.\n");
>> +               ret = -EINVAL;
>> +               goto error_ret;
>> +       }
>> +       st->ts_pen_detect_sensitivity = prop;
>> +       if (st->ts_pen_detect_sensitivity > 3) {
>> +               dev_err(&idev->dev, "Invalid atmel,adc-ts-pendet-sensitivity property in the DT.\n");
>> +               ret = -EINVAL;
>> +               goto error_ret;
>> +       }
>> +
>>          return 0;
>>
>>   error_ret:
>> @@ -592,6 +794,114 @@ static const struct iio_info at91_adc_info = {
>>          .read_raw = &at91_adc_read_raw,
>>   };
>>
>> +/* Touchscreen related functions */
>> +static int atmel_ts_open(struct input_dev *dev)
>> +{
>> +       struct at91_adc_state *st = input_get_drvdata(dev);
>> +
>> +       at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_PEN);
>> +       return 0;
>> +}
>> +
>> +static void atmel_ts_close(struct input_dev *dev)
>> +{
>> +       struct at91_adc_state *st = input_get_drvdata(dev);
>> +
>> +       at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_PEN);
>> +}
>> +
>> +static int at91_ts_hw_init(struct at91_adc_state *st, u32 adc_clk_khz)
>> +{
>> +       u32 reg = 0, pendbc;
>> +       int i = 0;
>> +
>> +       if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_4WIRE)
>> +               reg = AT91_ADC_TSMR_TSMODE_4WIRE_PRESS;
>> +       else
>> +               reg = AT91_ADC_TSMR_TSMODE_5WIRE;
>> +
>> +       /* a Pen Detect Debounce Time is necessary for the ADC Touch to avoid
>> +        * pen detect noise.
>> +        * The formula is : Pen Detect Debounce Time = (2 ^ pendbc) / ADCClock
>> +        */
>> +       pendbc = round_up(st->ts_pen_detect_debounce * adc_clk_khz / 1000, 1);
>> +
>> +       while (pendbc >> ++i)
>> +               ;       /* Empty! Find the shift offset */
>> +       if (abs(pendbc - (1 << i)) < abs(pendbc - (1 << (i - 1))))
>> +               pendbc = i;
>> +       else
>> +               pendbc = i - 1;
>> +
>> +       if (st->caps.has_tsmr) {
>> +               reg |= AT91_ADC_TSMR_TSAV_(st->ts_filter_average)
>> +                               & AT91_ADC_TSMR_TSAV;
>> +               reg |= AT91_ADC_TSMR_PENDBC_(pendbc) & AT91_ADC_TSMR_PENDBC;
>> +               reg |= AT91_ADC_TSMR_NOTSDMA;
>> +               reg |= AT91_ADC_TSMR_PENDET_ENA;
>> +               reg |= 0x03 << 8;       /* TSFREQ, need bigger than TSAV */
>> +
>> +               at91_adc_writel(st, AT91_ADC_TSMR, reg);
>> +       } else {
>> +               /* TODO: for 9g45 which has no TSMR */
>> +       }
>> +
>> +       /* Change adc internal resistor value for better pen detection,
>> +        * default value is 100 kOhm.
>> +        * 0 = 200 kOhm, 1 = 150 kOhm, 2 = 100 kOhm, 3 = 50 kOhm
>> +        * option only available on ES2 and higher
>> +        */
>> +       at91_adc_writel(st, AT91_ADC_ACR, st->ts_pen_detect_sensitivity
>> +                       & AT91_ADC_ACR_PENDETSENS);
>> +
>> +       /* Sample Peroid Time = (TRGPER + 1) / ADCClock */
>> +       st->ts_sample_period_val = round_up((st->ts_sample_period_time *
>> +                       adc_clk_khz / 1000) - 1, 1);
>> +
>> +       return 0;
>> +}
>> +
>> +static int at91_ts_register(struct at91_adc_state *st)
>> +{
>> +       struct input_dev *input;
>> +       struct iio_dev *idev = iio_priv_to_dev(st);
>> +       int ret;
>> +
>> +       input = input_allocate_device();
>> +       if (!input) {
>> +               dev_err(&idev->dev, "Failed to allocate TS device!\n");
>> +               return -ENOMEM;
>> +       }
>> +
>> +       input->name = DRIVER_NAME;
>> +       input->id.bustype = BUS_HOST;
>> +       input->dev.parent = idev->dev.parent;
>> +       input->open = atmel_ts_open;
>> +       input->close = atmel_ts_close;
>> +
>> +       __set_bit(EV_ABS, input->evbit);
>> +       __set_bit(EV_KEY, input->evbit);
>> +       __set_bit(BTN_TOUCH, input->keybit);
>> +       input_set_abs_params(input, ABS_X, 0, (1 << MAX_POS_BITS) - 1, 0, 0);
>> +       input_set_abs_params(input, ABS_Y, 0, (1 << MAX_POS_BITS) - 1, 0, 0);
>> +       input_set_abs_params(input, ABS_PRESSURE, 0, 0xffffff, 0, 0);
>> +
>> +       st->ts_input = input;
>> +       input_set_drvdata(input, st);
>> +
>> +       ret = input_register_device(input);
>> +       if (ret)
>> +               input_free_device(st->ts_input);
>> +
>> +       return ret;
>> +}
>> +
>> +static void at91_ts_unregister(struct at91_adc_state *st)
>> +{
>> +       input_unregister_device(st->ts_input);
>> +       input_free_device(st->ts_input);
>> +}
>> +
>>   /*
>>    * Since atmel adc support different ip for touchscreen mode. Through the
>>    * IP check, we will know the touchscreen capbilities.
>> @@ -610,6 +920,7 @@ static void atmel_adc_get_cap(struct at91_adc_state *st)
>>          /* keep only major version number */
>>          switch (version & 0xf00) {
>>          case 0x500:     /* SAMA5D3 */
>> +               st->caps.has_12bits_xy = 1;
>>          case 0x400:     /* AT91SAM9X5/9N12 */
>>                  st->caps.has_tsmr = 1;
>>                  st->caps.mr_startup_mask = AT91_ADC_STARTUP;
>> @@ -683,7 +994,7 @@ static int at91_adc_probe(struct platform_device *pdev)
>>          at91_adc_writel(st, AT91_ADC_CR, AT91_ADC_SWRST);
>>          at91_adc_writel(st, AT91_ADC_IDR, 0xFFFFFFFF);
>>          ret = request_irq(st->irq,
>> -                         at91_adc_eoc_trigger,
>> +                         at91_adc_interrupt,
>>                            0,
>>                            pdev->dev.driver->name,
>>                            idev);
>> @@ -731,6 +1042,10 @@ static int at91_adc_probe(struct platform_device *pdev)
>>          adc_clk = st->adc_clk_rate ?
>>                  st->adc_clk_rate : clk_get_rate(st->adc_clk);
>>          adc_clk_khz = adc_clk / 1000;
>> +
>> +       dev_dbg(&pdev->dev, "Master clock is set as: %d Hz, adc_clk should set as: %d Hz\n",
>> +               mstrclk, adc_clk);
>> +
>>          prsc = (mstrclk / (2 * adc_clk)) - 1;
>>
>>          if (!st->startup_time) {
>> @@ -799,30 +1114,52 @@ static int at91_adc_probe(struct platform_device *pdev)
>>          init_waitqueue_head(&st->wq_data_avail);
>>          mutex_init(&st->lock);
>>
>> -       ret = at91_adc_buffer_init(idev);
>> -       if (ret < 0) {
>> -               dev_err(&pdev->dev, "Couldn't initialize the buffer.\n");
>> -               goto error_disable_adc_clk;
>> -       }
>> +       /*
>> +        * Since touch screen will set trigger register as period trigger. So
>> +        * when touch screen is enabled, then we have to disable hardware
>> +        * trigger for classic adc.
>> +        */
>> +       if (!st->touchscreen_type) {
>> +               ret = at91_adc_buffer_init(idev);
>> +               if (ret < 0) {
>> +                       dev_err(&pdev->dev, "Couldn't initialize the buffer.\n");
>> +                       goto error_disable_adc_clk;
>> +               }
>>
>> -       ret = at91_adc_trigger_init(idev);
>> -       if (ret < 0) {
>> -               dev_err(&pdev->dev, "Couldn't setup the triggers.\n");
>> -               goto error_unregister_buffer;
>> +               ret = at91_adc_trigger_init(idev);
>> +               if (ret < 0) {
>> +                       dev_err(&pdev->dev, "Couldn't setup the triggers.\n");
>> +                       at91_adc_buffer_remove(idev);
>> +                       goto error_disable_adc_clk;
>> +               }
>> +       } else {
>> +               if (!st->caps.has_tsmr) {
>> +                       dev_err(&pdev->dev, "We don't support non-TSMR adc\n");
>> +                       goto error_disable_adc_clk;
>> +               }
>> +
>> +               ret = at91_ts_register(st);
>> +               if (ret)
>> +                       goto error_disable_adc_clk;
>> +
>> +               at91_ts_hw_init(st, adc_clk_khz);
>>          }
>>
>>          ret = iio_device_register(idev);
>>          if (ret < 0) {
>>                  dev_err(&pdev->dev, "Couldn't register the device.\n");
>> -               goto error_remove_triggers;
>> +               goto error_iio_device_register;
>>          }
>>
>>          return 0;
>>
>> -error_remove_triggers:
>> -       at91_adc_trigger_remove(idev);
>> -error_unregister_buffer:
>> -       at91_adc_buffer_remove(idev);
>> +error_iio_device_register:
>> +       if (!st->touchscreen_type) {
>> +               at91_adc_trigger_remove(idev);
>> +               at91_adc_buffer_remove(idev);
>> +       } else {
>> +               at91_ts_unregister(st);
>> +       }
>>   error_disable_adc_clk:
>>          clk_disable_unprepare(st->adc_clk);
>>   error_disable_clk:
>> @@ -841,8 +1178,12 @@ static int at91_adc_remove(struct platform_device *pdev)
>>          struct at91_adc_state *st = iio_priv(idev);
>>
>>          iio_device_unregister(idev);
>> -       at91_adc_trigger_remove(idev);
>> -       at91_adc_buffer_remove(idev);
>> +       if (!st->touchscreen_type) {
>> +               at91_adc_trigger_remove(idev);
>> +               at91_adc_buffer_remove(idev);
>> +       } else {
>> +               at91_ts_unregister(st);
>> +       }
>>          clk_disable_unprepare(st->adc_clk);
>>          clk_disable_unprepare(st->clk);
>>          free_irq(st->irq, idev);
>> @@ -861,7 +1202,7 @@ static struct platform_driver at91_adc_driver = {
>>          .probe = at91_adc_probe,
>>          .remove = at91_adc_remove,
>>          .driver = {
>> -                  .name = "at91_adc",
>> +                  .name = DRIVER_NAME,
>>                     .of_match_table = of_match_ptr(at91_adc_dt_ids),
>>          },
>>   };
>> --
>> 1.7.10
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>



From vinod.koul at intel.com  Thu Jul 25 03:23:51 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Thu, 25 Jul 2013 12:53:51 +0530
Subject: [PATCH] dma: edma: add device_slave_caps() support
In-Reply-To: <51F02CBA.5060704@ti.com>
References: <1374597804-3961-1-git-send-email-joelf@ti.com>
 <51EF8A52.90902@metafoo.de> <51EF8C2B.2030409@ti.com>
 <51EF8F4E.8080806@metafoo.de>
 <FB20353E-4890-4462-A671-3587A3841B4A@ti.com>
 <51EF92F2.3030405@metafoo.de> <51F0231C.7000401@ti.com>
 <20130724183329.GH18642@intel.com> <51F02CBA.5060704@ti.com>
Message-ID: <20130725072351.GJ18642@intel.com>

On Wed, Jul 24, 2013 at 02:36:26PM -0500, Joel Fernandes wrote:
> > Also another point worth considering is the approach Russell suggested, I havent
> > gotten a chance to dig deeper but if I understood it correctly then programming
> > the device_dma_parameters should be the right thing to do. Again I need to look
> > deeper and esp wrt edma
> 
> OK. I have some patches sitting in my tree too that I'm working on. With
> that I don't need to know about maximum number of allowed segments and
> can send along any number of segment. I will rework them and post them.
> fwiw, I will also implement caps API incase like Lars did populating the
> other fields though these will not be unused.
> 
> For segment size, at this time I don't know any driver that uses it
> other than davinci-pcm. For this reason the calculations can be done as
> Lars suggested (for minimum of maximum). Do you know in advance if
> you're going to amend to drop segment size if we go with what Russell
> suggested, or are you going to leave the seg-size in the caps API anyway.
I am just back and havent really done my work on this. Let me check and as I
said if my understanding is right I would be inclined to remove these fields...

~Vinod
-- 


From tomasz.figa at gmail.com  Thu Jul 25 04:12:12 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 25 Jul 2013 10:12:12 +0200
Subject: [PATCH v1 03/14] clk: Add of_clk_match() for device drivers
In-Reply-To: <1374713022-6049-4-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
 <1374713022-6049-4-git-send-email-sboyd@codeaurora.org>
Message-ID: <52875092.tEWeSbEJZC@flatron>

Hi Stephen,

On Wednesday 24 of July 2013 17:43:31 Stephen Boyd wrote:
> In similar fashion as of_regulator_match() add an of_clk_match()
> function that finds an initializes clock init_data structs from
> devicetree. Drivers should use this API to find clocks that their
> device is providing and then iterate over their match table
> registering the clocks with the init data parsed.

I think all you need here is declaring all your clock drivers using 
CLK_OF_DECLARE() macro. Then they will be automatically probed by 
of_clk_init(). See last lines of drivers/clk/clk-fixed-rate.c for an 
example.

Best regards,
Tomasz

> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  drivers/clk/clk.c            | 64
> ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/clk-provider.h | 16 +++++++++++
>  2 files changed, 80 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index ea8e951b..1e3e0db 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2289,4 +2289,68 @@ err:
>  	return -ENOMEM;
>  }
>  EXPORT_SYMBOL_GPL(of_init_clk_data);
> +
> +/**
> + * of_clk_match() - Scan and match clock providers from the DT node of
> a device + * @dev: device initializing clock providers
> + * @matches: match table of clocks
> + * @num_matches: number of entries in @matches
> + *
> + * This function uses a match table specified by the clock driver to
> parse + * clock init data from the device tree. @dev is expected to be
> a device with + * a 'clocks' child node containing a set of child
> nodes, each providing the + * init data for one clock. The data parsed
> from a child node will be matched + * to a clock based on the child
> node's name. Note that the match table is + * modified in place.
> + *
> + * Returns the number of matches found or a negative error code on
> failure. + */
> +int of_clk_match(struct device *dev, struct of_clk_match *matches,
> +		 int num_matches)
> +{
> +	int count = 0;
> +	int err, i;
> +	struct device_node *np, *clocks;
> +	struct clk_init_data *init;
> +
> +	clocks = of_find_node_by_name(dev->of_node, "clocks");
> +	if (!clocks)
> +		return -EINVAL;
> +
> +	for (i = 0; i < num_matches; i++) {
> +		struct of_clk_match *match = &matches[i];
> +		match->init_data = NULL;
> +		match->of_node = NULL;
> +	}
> +
> +	for_each_available_child_of_node(clocks, np) {
> +		for (i = 0; i < num_matches; i++) {
> +			struct of_clk_match *match = &matches[i];
> +			if (match->of_node)
> +				continue;
> +
> +			if (strcmp(match->name, np->name))
> +				continue;
> +
> +			init = devm_kzalloc(dev, sizeof(*init), 
GFP_KERNEL);
> +			if (!init)
> +				return -ENOMEM;
> +
> +			err = of_init_clk_data(np, init);
> +			if (err) {
> +				dev_err(dev,
> +					"failed to parse DT for clock 
%s\n",
> +					np->name);
> +				return err;
> +			}
> +			match->of_node = np;
> +			match->init_data = init;
> +			count++;
> +			break;
> +		}
> +	}
> +
> +	return count;
> +}
> +EXPORT_SYMBOL_GPL(of_clk_match);
>  #endif
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 18d6362..484f8ad 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -461,6 +461,13 @@ struct clk_onecell_data {
>  		__used __section(__clk_of_table)		\
>  		= { .compatible = compat, .data = fn };
> 
> +struct of_clk_match {
> +	const char *name;
> +	void *driver_data;
> +	struct clk_init_data *init_data;
> +	struct device_node *of_node;
> +};
> +
>  #ifdef CONFIG_OF
>  int of_clk_add_provider(struct device_node *np,
>  			struct clk *(*clk_src_get)(struct of_phandle_args 
*args,
> @@ -475,6 +482,9 @@ const char *of_clk_get_parent_name(struct
> device_node *np, int index); void of_clk_init(const struct of_device_id
> *matches);
>  int of_init_clk_data(struct device_node *np, struct clk_init_data
> *init);
> 
> +int of_clk_match(struct device *dev, struct of_clk_match *matches,
> +		 int num_matches);
> +
>  #else /* !CONFIG_OF */
> 
>  static inline int of_clk_add_provider(struct device_node *np,
> @@ -508,6 +518,12 @@ of_init_clk_data(struct device_node *np, struct
> clk_init_data *init) {
>  	return 0;
>  }
> +static inline int
> +of_clk_match(struct device *dev, struct of_clk_match *matches, int
> num_matches) +{
> +
> +	return 0;
> +}
>  #endif /* CONFIG_OF */
>  #endif /* CONFIG_COMMON_CLK */
>  #endif /* CLK_PROVIDER_H */


From tomasz.figa at gmail.com  Thu Jul 25 04:21:02 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 25 Jul 2013 10:21:02 +0200
Subject: [PATCH v1 02/14] clk: Add of_init_clk_data() to parse common
 clock bindings
In-Reply-To: <1374713022-6049-3-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
 <1374713022-6049-3-git-send-email-sboyd@codeaurora.org>
Message-ID: <1714620.Z8J8zTxIRB@flatron>

Hi Stephen,

Pretty good idea, but I have some comments inline.

On Wednesday 24 of July 2013 17:43:30 Stephen Boyd wrote:
> Consolidate DT parsing for the common bits of a clock binding in
> one place to simplify clock drivers. This also has the added
> benefit of standardizing how the clock names used by the common
> clock framework are generated from the DT bindings. We always use
> the first clock-output-names string if it exists, otherwise we
> fall back to the node name.
> 
> To be slightly more efficient and make the caller's life easier,
> we introduce a shallow copy flag so that the clock core knows to
> just copy the pointers to the strings and not the string
> contents. Otherwise the callers of this function would have to
> free the strings allocated here which could be cumbersome.
> 
> Cc: Rob Herring <rob.herring at calxeda.com>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  drivers/clk/clk.c            | 59
> +++++++++++++++++++++++++++++++++++++++++++-
> include/linux/clk-provider.h |  7 ++++++
>  2 files changed, 65 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 1ed9bdd..ea8e951b 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1809,6 +1809,10 @@ static int _clk_register(struct device *dev,
> struct clk_hw *hw, struct clk *clk) {
>  	int i, ret;
> 
> +	hw->clk = clk;
> +	if (hw->init->flags & CLK_SHALLOW_COPY)
> +		return PTR_RET(__clk_register(dev, hw));
> +
>  	clk->name = kstrdup(hw->init->name, GFP_KERNEL);
>  	if (!clk->name) {
>  		pr_err("%s: could not allocate clk->name\n", __func__);
> @@ -1819,7 +1823,6 @@ static int _clk_register(struct device *dev,
> struct clk_hw *hw, struct clk *clk) clk->hw = hw;
>  	clk->flags = hw->init->flags;
>  	clk->num_parents = hw->init->num_parents;
> -	hw->clk = clk;
> 
>  	/* allocate local copy in case parent_names is __initdata */
>  	clk->parent_names = kzalloc((sizeof(char*) * clk->num_parents),
> @@ -2232,4 +2235,58 @@ void __init of_clk_init(const struct of_device_id
> *matches) clk_init_cb(np);
>  	}
>  }
> +
> +/**
> + * of_init_clk_data() - Initialize a clk_init_data struct from a DT
> node + * @np: node to initialize struct from
> + * @init: struct to initialize
> + *
> + * Populates the clk_init_data struct by parsing the device node for
> + * properties matching the common clock binding. Returns 0 on success
> + * and a negative error code on failure.
> + */
> +int of_init_clk_data(struct device_node *np, struct clk_init_data
> *init) +{
> +	struct of_phandle_args s;
> +	const char **names = NULL, **p;
> +	const char *name;
> +	int i;
> +
> +	if (of_property_read_string(np, "clock-output-names", &name) < 0)
> +		name = np->name;
> +	init->name = kstrdup(name, GFP_KERNEL);
> +	if (!init->name)
> +		return -ENOMEM;
> +
> +	for (i = 0; of_parse_phandle_with_args(np, "clocks", "#clock-
cells",
> +				i, &s) == 0; i++) {
> +		p = krealloc(names, sizeof(*names) * (i + 1), GFP_KERNEL);
> +		if (!p)
> +			goto err;

What about using of_count_phandle_with_args() first to get the parent 
count?

> +		names = p;
> +
> +		if (of_property_read_string(s.np, "clock-output-names",
> +					&name) < 0)
> +			name = s.np->name;

You should be able to use of_clk_get_parent_name() here, instead of 
parsing the properties directly.

Best regards,
Tomasz



From tomasz.figa at gmail.com  Thu Jul 25 04:26:18 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 25 Jul 2013 10:26:18 +0200
Subject: [PATCH v1 04/14] clk: Add set_rate_and_parent() op
In-Reply-To: <1374713022-6049-5-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
 <1374713022-6049-5-git-send-email-sboyd@codeaurora.org>
Message-ID: <4582949.WCP5JfKYES@flatron>

On Wednesday 24 of July 2013 17:43:32 Stephen Boyd wrote:
> Some of Qualcomm's clocks can change their parent and rate at the
> same time with a single register write. Add support for this
> hardware to the common clock framework by adding a new
> set_rate_and_parent() op. When the clock framework determines
> that both the parent and the rate are going to change during
> clk_set_rate() it will call the .set_rate_and_parent() op if
> available and fall back to calling .set_parent() followed by
> .set_rate() otherwise.

This is strange. Does you hardware support switching parent and rate 
separately or you always need to set both and so all the fuss here?

If the latter is the case, then maybe you can simply keep parent index and 
rate cached inside driver data of your clock driver and use them on any 
.set_rate() or .set_parent() calls?

I'm not really sure if we want such oddities to be handled inside of 
common clock framework. Mike, what do you think?

Best regards,
Tomasz

> Cc: James Hogan <james.hogan at imgtec.com>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  Documentation/clk.txt        |  3 ++
>  drivers/clk/clk.c            | 78
> +++++++++++++++++++++++++++++++++-----------
> include/linux/clk-provider.h | 15 +++++++++
>  3 files changed, 77 insertions(+), 19 deletions(-)
> 
> diff --git a/Documentation/clk.txt b/Documentation/clk.txt
> index 3aeb5c4..79700ea 100644
> --- a/Documentation/clk.txt
> +++ b/Documentation/clk.txt
> @@ -77,6 +77,9 @@ the operations defined in clk.h:
>  		int		(*set_parent)(struct clk_hw *hw, u8 
index);
>  		u8		(*get_parent)(struct clk_hw *hw);
>  		int		(*set_rate)(struct clk_hw *hw, unsigned 
long);
> +		int		(*set_rate_and_parent)(struct clk_hw *hw,
> +					    unsigned long rate,
> +					    unsigned long parent_rate, u8 
index);
>  		void		(*init)(struct clk_hw *hw);
>  	};
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 1e3e0db..73de07c 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1121,10 +1121,9 @@ static void clk_reparent(struct clk *clk, struct
> clk *new_parent) clk->parent = new_parent;
>  }
> 
> -static int __clk_set_parent(struct clk *clk, struct clk *parent, u8
> p_index) +static struct clk *__clk_set_parent_before(struct clk *clk,
> struct clk *parent) {
>  	unsigned long flags;
> -	int ret = 0;
>  	struct clk *old_parent = clk->parent;
> 
>  	/*
> @@ -1155,6 +1154,34 @@ static int __clk_set_parent(struct clk *clk,
> struct clk *parent, u8 p_index) clk_reparent(clk, parent);
>  	clk_enable_unlock(flags);
> 
> +	return old_parent;
> +}
> +
> +static void __clk_set_parent_after(struct clk *clk, struct clk *parent,
> +		struct clk *old_parent)
> +{
> +	/*
> +	 * Finish the migration of prepare state and undo the changes done
> +	 * for preventing a race with clk_enable().
> +	 */
> +	if (clk->prepare_count) {
> +		clk_disable(clk);
> +		clk_disable(old_parent);
> +		__clk_unprepare(old_parent);
> +	}
> +
> +	/* update debugfs with new clk tree topology */
> +	clk_debug_reparent(clk, parent);
> +}
> +
> +static int __clk_set_parent(struct clk *clk, struct clk *parent, u8
> p_index) +{
> +	unsigned long flags;
> +	int ret = 0;
> +	struct clk *old_parent;
> +
> +	old_parent = __clk_set_parent_before(clk, parent);
> +
>  	/* change clock input source */
>  	if (parent && clk->ops->set_parent)
>  		ret = clk->ops->set_parent(clk->hw, p_index);
> @@ -1172,18 +1199,8 @@ static int __clk_set_parent(struct clk *clk,
> struct clk *parent, u8 p_index) return ret;
>  	}
> 
> -	/*
> -	 * Finish the migration of prepare state and undo the changes done
> -	 * for preventing a race with clk_enable().
> -	 */
> -	if (clk->prepare_count) {
> -		clk_disable(clk);
> -		clk_disable(old_parent);
> -		__clk_unprepare(old_parent);
> -	}
> +	__clk_set_parent_after(clk, parent, old_parent);
> 
> -	/* update debugfs with new clk tree topology */
> -	clk_debug_reparent(clk, parent);
>  	return 0;
>  }
> 
> @@ -1368,17 +1385,32 @@ static void clk_change_rate(struct clk *clk)
>  	struct clk *child;
>  	unsigned long old_rate;
>  	unsigned long best_parent_rate = 0;
> +	bool skip_set_rate = false;
> +	struct clk *old_parent;
> 
>  	old_rate = clk->rate;
> 
> -	/* set parent */
> -	if (clk->new_parent && clk->new_parent != clk->parent)
> -		__clk_set_parent(clk, clk->new_parent, clk-
>new_parent_index);
> -
> -	if (clk->parent)
> +	if (clk->new_parent)
> +		best_parent_rate = clk->new_parent->rate;
> +	else if (clk->parent)
>  		best_parent_rate = clk->parent->rate;
> 
> -	if (clk->ops->set_rate)
> +	if (clk->new_parent && clk->new_parent != clk->parent) {
> +		old_parent = __clk_set_parent_before(clk, clk-
>new_parent);
> +
> +		if (clk->ops->set_rate_and_parent) {
> +			skip_set_rate = true;
> +			clk->ops->set_rate_and_parent(clk->hw, clk-
>new_rate,
> +					best_parent_rate,
> +					clk->new_parent_index);
> +		} else if (clk->ops->set_parent) {
> +			clk->ops->set_parent(clk->hw, clk-
>new_parent_index);
> +		}
> +
> +		__clk_set_parent_after(clk, clk->new_parent, old_parent);
> +	}
> +
> +	if (!skip_set_rate && clk->ops->set_rate)
>  		clk->ops->set_rate(clk->hw, clk->new_rate, 
best_parent_rate);
> 
>  	if (clk->ops->recalc_rate)
> @@ -1664,6 +1696,14 @@ int __clk_init(struct device *dev, struct clk
> *clk) goto out;
>  	}
> 
> +	if (clk->ops->set_rate_and_parent &&
> +			!(clk->ops->set_parent && clk->ops->set_rate)) {
> +		pr_warning("%s: %s must implement .set_parent & 
.set_rate\n",
> +				__func__, clk->name);
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
>  	/* throw a WARN if any entries in parent_names are NULL */
>  	for (i = 0; i < clk->num_parents; i++)
>  		WARN(!clk->parent_names[i],
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 484f8ad..1f7eabb 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -108,6 +108,18 @@ struct clk_hw;
>   *		which is likely helpful for most .set_rate implementation.
>   *		Returns 0 on success, -EERROR otherwise.
>   *
> + * @set_rate_and_parent: Change the rate and the parent of this clock.
> The + *		requested rate is specified by the second 
argument, which +
> *		should typically be the return of .round_rate call.  The
> + *		third argument gives the parent rate which is likely 
helpful
> + *		for most .set_rate_and_parent implementation. The fourth
> + *		argument gives the parent index. It is optional (and
> + *		unnecessary) for clocks with 0 or 1 parents as well as
> + *		for clocks that can tolerate switching the rate and the 
parent
> + *		separately via calls to .set_parent and .set_rate.
> + *		Returns 0 on success, -EERROR otherwise.
> + *
> + *
>   * The clk_enable/clk_disable and clk_prepare/clk_unprepare pairs allow
> * implementations to split any work between atomic (enable) and
> sleepable * (prepare) contexts.  If enabling a clock requires code that
> might sleep, @@ -139,6 +151,9 @@ struct clk_ops {
>  	u8		(*get_parent)(struct clk_hw *hw);
>  	int		(*set_rate)(struct clk_hw *hw, unsigned long,
>  				    unsigned long);
> +	int		(*set_rate_and_parent)(struct clk_hw *hw,
> +				    unsigned long rate,
> +				    unsigned long parent_rate, u8 index);
>  	void		(*init)(struct clk_hw *hw);
>  };


From horms at verge.net.au  Thu Jul 25 04:26:39 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 25 Jul 2013 17:26:39 +0900
Subject: Mainline kernel on snowball
In-Reply-To: <20130725075203.GE31954@1wt.eu>
References: <20130725052317.GA25854@verge.net.au>
 <20130725054036.GD31954@1wt.eu>
 <20130725072525.GC7654@verge.net.au>
 <20130725075203.GE31954@1wt.eu>
Message-ID: <20130725082639.GA25311@verge.net.au>

On Thu, Jul 25, 2013 at 09:52:03AM +0200, Willy Tarreau wrote:
> On Thu, Jul 25, 2013 at 04:25:25PM +0900, Simon Horman wrote:
> > > # cat /proc/cmdline 
> > > console=tty0 console=ttyAMA2,115200n8  root=UUID=018e1580-e7e9-460b-95c5-236f6b87b13d rootwait ro fixrtc nocompcache vmalloc=300M mem=128M at 0 mali.mali_mem=64M at 128M hwmem=168M at 192M mem=22M at 360M mem_issw=1M at 383M mem=640M at 384M
> > 
> > Thanks. Rummaging around in the environment present in uboot I came up with
> > the following:
> > 
> > bootargs=cachepolicy=writealloc noinitrd init=init board_id=1 crashkernel=crashkernel=1M at 0x5600000 logo.nologo startup_graphics=1 mpcore_wdt.mpcore_margin=359 loglevel=8 console=ttyAMA2,115200n8 mem=128M at 0 mali.mali_mem=64M at 128M
> > mem=24M at 192M hwmem=167M at 216M mem_issw=1M at 383M mem=640M at 384M vmalloc=256M
> > 
> > Unfortunately neither this, nor the boot args you are using seem
> > to get me any further.
> 
> OK, I'm attaching the config that works for me on 3.10-rc5 (not
> tested a new one yet). It boots with the cmdline above and with
> the DTB from the kernel.
> 
> Hoping this helps,
> Willy
> 

Thanks! I have something working now.

It seems that part of my problem may have been the compiler that
I was using. But that is just speculation at this time.


From tomasz.figa at gmail.com  Thu Jul 25 04:29:13 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 25 Jul 2013 10:29:13 +0200
Subject: [PATCH v1 05/14] clk: msm: Add support for phase locked loops
 (PLLs)
In-Reply-To: <1374713022-6049-6-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
 <1374713022-6049-6-git-send-email-sboyd@codeaurora.org>
Message-ID: <6003715.TMZ71jDUbL@flatron>

Hi Stephen,

On Wednesday 24 of July 2013 17:43:33 Stephen Boyd wrote:
> Add support for MSM's PLLs (phase locked loops). This is
> sufficient enough to be able to determine the rate the PLL is
> running at. We can add rate setting support later when it's
> needed.
> 
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  Documentation/devicetree/bindings/clock/msm.txt |  40 ++++
>  drivers/clk/Kconfig                             |   2 +
>  drivers/clk/Makefile                            |   1 +
>  drivers/clk/msm/Kconfig                         |   4 +
>  drivers/clk/msm/Makefile                        |   3 +
>  drivers/clk/msm/clk-pll.c                       | 233
> ++++++++++++++++++++++++ drivers/clk/msm/clk-pll.h                     
>  |  43 +++++
>  7 files changed, 326 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/msm.txt
>  create mode 100644 drivers/clk/msm/Kconfig
>  create mode 100644 drivers/clk/msm/Makefile
>  create mode 100644 drivers/clk/msm/clk-pll.c
>  create mode 100644 drivers/clk/msm/clk-pll.h
[snip]
> diff --git a/drivers/clk/msm/clk-pll.h b/drivers/clk/msm/clk-pll.h
> new file mode 100644
> index 0000000..4e63a5e
> --- /dev/null
> +++ b/drivers/clk/msm/clk-pll.h
> @@ -0,0 +1,43 @@
> +/*
> + * Copyright (c) 2013, The Linux Foundation. All rights reserved.
> + *
> + * 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 __MSM_CLK_PLL_H__
> +#define __MSM_CLK_PLL_H__
> +
> +struct device;
> +struct clk;
> +struct clk_init_data;
> +
> +struct pll_desc {
> +	void __iomem *base;
> +	u16 l_reg;
> +	u16 m_reg;
> +	u16 n_reg;
> +	u16 config_reg;
> +	u16 mode_reg;
> +	u16 status_reg;
> +	u8 status_bit;
> +};
> +
> +struct pll_vote_desc {
> +	void __iomem *base;
> +	u16 vote_reg;
> +	u8 vote_bit;
> +};
> +
> +extern struct clk *pll_clk_register(struct device *dev, struct pll_desc
> *desc, +		struct clk_init_data *init);
> +extern struct clk *pll_vote_clk_register(struct device *dev,
> +		struct pll_vote_desc *desc, struct clk_init_data *init);

I don't think such generic name is good here. What about prefixing them 
with msm_ or qcom_ string?

Best regards,
Tomasz



From tomasz.figa at gmail.com  Thu Jul 25 04:32:09 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 25 Jul 2013 10:32:09 +0200
Subject: [PATCH v1 08/14] clk: msm: Add MSM clock driver
In-Reply-To: <1374713022-6049-9-git-send-email-sboyd@codeaurora.org>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
 <1374713022-6049-9-git-send-email-sboyd@codeaurora.org>
Message-ID: <2513717.VTXGvIpGv4@flatron>

Hi Stephen,

On Wednesday 24 of July 2013 17:43:36 Stephen Boyd wrote:
> Add a clock driver that registers clocks from a DT node's
> 'clocks' child. Each new SoC will add a file describing the
> software interface and frequency plan to drivers/clk/msm/ and
> then hook that into the msm_cc_match_table by means of a
> compatible string and an msm_clk_match table.
> 
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  drivers/clk/msm/Makefile   |   2 +
>  drivers/clk/msm/core.c     | 265
> +++++++++++++++++++++++++++++++++++++++++++++
> drivers/clk/msm/internal.h |  24 ++++
>  3 files changed, 291 insertions(+)
>  create mode 100644 drivers/clk/msm/core.c
>  create mode 100644 drivers/clk/msm/internal.h
> 
> diff --git a/drivers/clk/msm/Makefile b/drivers/clk/msm/Makefile
> index e1cee29..9cfd0d7 100644
> --- a/drivers/clk/msm/Makefile
> +++ b/drivers/clk/msm/Makefile
> @@ -4,3 +4,5 @@ clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-pll.o
>  clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-rcg.o
>  clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-rcg2.o
>  clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-branch.o
> +
> +clk-msm-$(CONFIG_COMMON_CLK_MSM) += core.o
> diff --git a/drivers/clk/msm/core.c b/drivers/clk/msm/core.c
> new file mode 100644
> index 0000000..b1904c0
> --- /dev/null
> +++ b/drivers/clk/msm/core.c
> @@ -0,0 +1,265 @@
> +/*
> + * Copyright (c) 2013, The Linux Foundation. All rights reserved.
> + *
> + * 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.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/platform_device.h>
> +#include <linux/module.h>
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/spinlock.h>
> +
> +#include "internal.h"
> +#include "clk-pll.h"
> +#include "clk-rcg.h"
> +#include "clk-branch.h"
> +
> +struct cc_data {
> +	void __iomem *base;
> +	spinlock_t lock;
> +};
> +
> +static struct clk *
> +dispatch_fixed_clk(struct of_clk_match *m, struct device *dev,
> +		struct cc_data *cc)
> +{
> +	u32 rate;
> +	const char *name = m->init_data->name;
> +
> +	if (of_property_read_u32(m->of_node, "clock-frequency", &rate))
> +		return ERR_PTR(-EINVAL);
> +
> +	return clk_register_fixed_rate(dev, name, NULL, CLK_IS_ROOT, 
rate);
> +}
> +
> +static struct clk *
> +dispatch_pll_clk(struct of_clk_match *m, struct device *dev,
> +		struct cc_data *cc)
> +{
> +	struct pll_desc *desc = m->driver_data;
> +
> +	desc->base = cc->base;
> +
> +	return pll_clk_register(dev, desc, m->init_data);
> +}
> +
> +static struct clk *
> +dispatch_pll_vote_clk(struct of_clk_match *m, struct device *dev,
> +		struct cc_data *cc)
> +{
> +	struct pll_vote_desc *desc = m->driver_data;
> +
> +	desc->base = cc->base;
> +
> +	return pll_vote_clk_register(dev, desc, m->init_data);
> +}
> +
> +static struct clk *
> +dispatch_rcg_p2mn16_clk(struct of_clk_match *m, struct device *dev,
> +		struct cc_data *cc)
> +{
> +	struct rcg_desc *desc = m->driver_data;
> +
> +	desc->base = cc->base;
> +
> +	return rcg_p2mn16_clk_register(dev, desc, &cc->lock, m-
>init_data);
> +}
> +
> +static struct clk *
> +dispatch_rcg_p2mn8_clk(struct of_clk_match *m, struct device *dev,
> +		struct cc_data *cc)
> +{
> +	struct rcg_desc *desc = m->driver_data;
> +
> +	desc->base = cc->base;
> +
> +	return rcg_p2mn8_clk_register(dev, desc, &cc->lock, m->init_data);
> +}
> +
> +static struct clk *
> +dispatch_rcg_mn8_dyn_clk(struct of_clk_match *match, struct device
> *dev, +		struct cc_data *cc)
> +{
> +	struct rcg_dyn_desc *desc = match->driver_data;
> +
> +	desc->base = cc->base;
> +
> +	return rcg_mn8_dyn_clk_register(dev, desc, &cc->lock,
> +			match->init_data);
> +}
> +
> +static struct clk *
> +dispatch_rcg_p4_dyn_clk(struct of_clk_match *match, struct device *dev,
> +		struct cc_data *cc)
> +{
> +	struct rcg_dyn_desc *desc = match->driver_data;
> +
> +	desc->base = cc->base;
> +
> +	return rcg_p4_dyn_clk_register(dev, desc, &cc->lock,
> +			match->init_data);
> +}
> +
> +static struct clk *
> +dispatch_rcg_h5mn8_clk(struct of_clk_match *match, struct device *dev,
> +		struct cc_data *cc)
> +{
> +	struct rcg2_desc *desc = match->driver_data;
> +
> +	desc->base = cc->base;
> +
> +	return rcg_h5mn8_clk_register(dev, desc, &cc->lock, match-
>init_data);
> +}
> +
> +static struct clk *
> +dispatch_rcg_h5mn16_clk(struct of_clk_match *match, struct device *dev,
> +		struct cc_data *cc)
> +{
> +	struct rcg2_desc *desc = match->driver_data;
> +
> +	desc->base = cc->base;
> +
> +	return rcg_h5mn16_clk_register(dev, desc, &cc->lock,
> match->init_data); +}
> +
> +static struct clk *
> +dispatch_branch_clk(struct of_clk_match *m, struct device *dev,
> +		struct cc_data *cc)
> +{
> +	struct branch_desc *desc = m->driver_data;
> +
> +	desc->base = cc->base;
> +
> +	return branch_clk_register(dev, desc, &cc->lock, m->init_data);
> +}
> +
> +static struct clk *
> +dispatch_branch_hg_clk(struct of_clk_match *m, struct device *dev,
> +		struct cc_data *cc)
> +{
> +	struct branch_desc *desc = m->driver_data;
> +
> +	desc->base = cc->base;
> +
> +	return branch_hg_clk_register(dev, desc, &cc->lock, m->init_data);
> +}
> +
> +static const struct of_device_id dispatch_table[] = {
> +	{ .compatible = "fixed-clock", .data = dispatch_fixed_clk },

This is already handled by the fixed-rate-clock driver and of_clk_init().

> +	{ .compatible = "qcom,pll", .data = dispatch_pll_clk },
> +	{ .compatible = "qcom,pll-vote", .data = dispatch_pll_vote_clk },
> +	{ .compatible = "qcom,p2-mn8-clock", .data = 
dispatch_rcg_p2mn8_clk },
> +	{ .compatible = "qcom,p2-mn16-clock", .data = 
dispatch_rcg_p2mn16_clk
> }, +	{ .compatible = "qcom,mn8-dyn-clock", .data =
> dispatch_rcg_mn8_dyn_clk }, +	{ .compatible = "qcom,p4-dyn-clock",
> .data = dispatch_rcg_p4_dyn_clk }, +	{ .compatible =
> "qcom,h5-mn8-clock", .data = dispatch_rcg_h5mn8_clk }, +	{ 
.compatible
> = "qcom,h5-mn16-clock", .data = dispatch_rcg_h5mn16_clk }, +	{
> .compatible = "qcom,cxc-clock", .data = dispatch_branch_clk }, +	{
> .compatible = "qcom,cxc-hg-clock", .data = dispatch_branch_hg_clk },
> +};

You can avoid all the code above by using OF_CLK_DECLARE() and 
of_clk_init().

> +typedef struct clk *
> +(*clk_dispatch_fn)(struct of_clk_match *m, struct device *dev,
> +		struct cc_data *cc);
> +
> +static const struct of_device_id msm_cc_match_table[] = {
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, msm_cc_match_table);
> +
> +static int msm_cc_probe(struct platform_device *pdev)
> +{
> +	struct cc_data *cc;
> +	void __iomem *base;
> +	struct resource *res;
> +	int count, i;
> +	const struct of_device_id *id_entry;
> +	const struct msm_clk_match *m;
> +	struct of_clk_match *matches;
> +	size_t size;
> +
> +	id_entry = of_match_device(msm_cc_match_table, &pdev->dev);
> +	m = id_entry->data;
> +	matches = m->matches;
> +	size = m->size;
> +
> +	cc = devm_kzalloc(&pdev->dev, sizeof(*cc), GFP_KERNEL);
> +	if (!cc)
> +		return -ENOMEM;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	base = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(base))
> +		return PTR_ERR(base);
> +
> +	cc->base = base;
> +	spin_lock_init(&cc->lock);
> +
> +	count = of_clk_match(&pdev->dev, matches, size);
> +	if (count < 0)
> +		return count;
> +
> +	for (i = 0; i < size; i++) {
> +		struct of_clk_match *match;
> +		const struct of_device_id *id;
> +		struct device_node *np;
> +		clk_dispatch_fn fn;
> +		struct clk *clk;
> +		int err;
> +
> +		match = &matches[i];
> +		np = match->of_node;
> +		if (!np)
> +			continue;
> +
> +		id = of_match_node(dispatch_table, match->of_node);
> +		if (!id)
> +			continue;
> +
> +		fn = id->data;
> +		clk = fn(match, &pdev->dev, cc);
> +		if (IS_ERR(clk))
> +			return PTR_ERR(clk);
> +
> +		err = of_clk_add_provider(np, of_clk_src_simple_get, clk);
> +		if (err)
> +			return err;
> +	}
> +
> +	return 0;
> +}
> +
> +static struct platform_driver msm_cc_driver = {
> +	.probe		= msm_cc_probe,
> +	.driver		= {
> +		.name	= "msm-clock",
> +		.owner	= THIS_MODULE,
> +		.of_match_table = msm_cc_match_table,
> +	},
> +};
> +
> +static int __init msm_cc_init(void)
> +{
> +	return platform_driver_register(&msm_cc_driver);
> +}
> +core_initcall(msm_cc_init);

I might be saying something stupid, but is it okay for a removable module 
to have a core_initcall?

Best regards,
Tomasz



From w at 1wt.eu  Thu Jul 25 04:36:18 2013
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 25 Jul 2013 10:36:18 +0200
Subject: Mainline kernel on snowball
In-Reply-To: <20130725082639.GA25311@verge.net.au>
References: <20130725052317.GA25854@verge.net.au>
 <20130725054036.GD31954@1wt.eu> <20130725072525.GC7654@verge.net.au>
 <20130725075203.GE31954@1wt.eu> <20130725082639.GA25311@verge.net.au>
Message-ID: <20130725083618.GA2346@1wt.eu>

On Thu, Jul 25, 2013 at 05:26:39PM +0900, Simon Horman wrote:
> On Thu, Jul 25, 2013 at 09:52:03AM +0200, Willy Tarreau wrote:
> > On Thu, Jul 25, 2013 at 04:25:25PM +0900, Simon Horman wrote:
> > > > # cat /proc/cmdline 
> > > > console=tty0 console=ttyAMA2,115200n8  root=UUID=018e1580-e7e9-460b-95c5-236f6b87b13d rootwait ro fixrtc nocompcache vmalloc=300M mem=128M at 0 mali.mali_mem=64M at 128M hwmem=168M at 192M mem=22M at 360M mem_issw=1M at 383M mem=640M at 384M
> > > 
> > > Thanks. Rummaging around in the environment present in uboot I came up with
> > > the following:
> > > 
> > > bootargs=cachepolicy=writealloc noinitrd init=init board_id=1 crashkernel=crashkernel=1M at 0x5600000 logo.nologo startup_graphics=1 mpcore_wdt.mpcore_margin=359 loglevel=8 console=ttyAMA2,115200n8 mem=128M at 0 mali.mali_mem=64M at 128M
> > > mem=24M at 192M hwmem=167M at 216M mem_issw=1M at 383M mem=640M at 384M vmalloc=256M
> > > 
> > > Unfortunately neither this, nor the boot args you are using seem
> > > to get me any further.
> > 
> > OK, I'm attaching the config that works for me on 3.10-rc5 (not
> > tested a new one yet). It boots with the cmdline above and with
> > the DTB from the kernel.
> > 
> > Hoping this helps,
> > Willy
> > 
> 
> Thanks! I have something working now.
> 
> It seems that part of my problem may have been the compiler that
> I was using. But that is just speculation at this time.

I have some vague memories about failures that I attributed to some
flavor of 4.5 but I don't remember if it was the real cause in the end
or not.

Willy



From 21cnbao at gmail.com  Thu Jul 25 04:57:22 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Thu, 25 Jul 2013 16:57:22 +0800
Subject: [PATCH 5/6] ASoC: sirf-inner: add mach driver for SiRFSoC
 internal codec
In-Reply-To: <20130719185101.GV9858@sirena.org.uk>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
 <1374232042-26088-6-git-send-email-Baohua.Song@csr.com>
 <20130719185101.GV9858@sirena.org.uk>
Message-ID: <CAGsJ_4w5G3ppgWdFYJ0-cMLbuvDMdy+dJneMshkeYz5MR6RW+Q@mail.gmail.com>

2013/7/20 Mark Brown <broonie at kernel.org>:
> On Fri, Jul 19, 2013 at 07:07:21PM +0800, Barry Song wrote:
>
>> +#ifndef CONFIG_ANDROID
>> +     unsigned int            gpio_hp_detect;
>> +     struct snd_soc_jack     hp_jack;
>> +#endif
>
> Not for mainline.  I'd suggest setting it up for extcon anyway
> especially if it's just a simple accessory, that should work for both
> Android and mainline.

sounds good as if CONFIG_ANDROID is enabled without
CONFIG_ANDROID_SWITCH, /sys/class/switch/* will be symbolically linked
to /sys/class/extcon/, so that they are still compatible with legacy
userspace processes.

>
>> +static int sirf_inner_speaker_out_put(struct snd_kcontrol *kcontrol,
>> +             struct snd_ctl_elem_value *ucontrol)
>> +{
>> +     int is_spk_out = ucontrol->value.integer.value[0];
>> +     struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
>> +     struct snd_soc_card *card = codec->card;
>> +     struct sirf_inner_card *sinner_card = snd_soc_card_get_drvdata(card);
>> +
>> +     if (gpio_is_valid(sinner_card->gpio_spk_pa))
>> +             gpio_direction_output(sinner_card->gpio_spk_pa, is_spk_out);
>> +     return 0;
>> +}
>
> Oh, right.  If this is doing what I think this is doing you want to use
> DAPM within the CODEC then this can just become a pin switch or you can
> hook in directly if you continue to use soc-jack - it has DAPM
> integration.

ok. here it is more of machine stuff than codec stuff, so i think we
move to snd_soc_jack_gpio.

-barry


From zonque at gmail.com  Thu Jul 25 05:00:30 2013
From: zonque at gmail.com (Daniel Mack)
Date: Thu, 25 Jul 2013 11:00:30 +0200
Subject: [PATCH 1/5] gpio: pxa: remove dead code
In-Reply-To: <CAD6h2NS0p-kMUGyhbr93vd_oLSNyaB572riFB8mHt1cu5f-bGw@mail.gmail.com>
References: <1373555877-29887-1-git-send-email-zonque@gmail.com>
 <1373555877-29887-2-git-send-email-zonque@gmail.com>
 <CACRpkdaB7JnWzoLKpQ1eLWAi7yFz9CanhbhwtiCnEtcNWzX3RQ@mail.gmail.com>
 <CAD6h2NS0p-kMUGyhbr93vd_oLSNyaB572riFB8mHt1cu5f-bGw@mail.gmail.com>
Message-ID: <51F0E92E.6060900@gmail.com>

On 22.07.2013 09:14, Haojian Zhuang wrote:
> On 22 July 2013 00:15, Linus Walleij <linus.walleij at linaro.org> wrote:
>> On Thu, Jul 11, 2013 at 5:17 PM, Daniel Mack <zonque at gmail.com> wrote:
>>
>>> Commit f87311743 ("ARM: mmp: add more compatible names in gpio driver")
>>> changed the driver logic to determine the number of available GPIOs from
>>> the compatible string, and hence obsoleted the (undocumented) child
>>> nodes that were previously necessary. However, it left some remainder
>>> which can be safely removed now.
>>>
>>> Also, this patch makes pxa_gpio_probe_dt() return the correct value in
>>> case irq_alloc_descs() fails.
>>>
>>> Signed-off-by: Daniel Mack <zonque at gmail.com>
>>> Cc: Haojian Zhuang <haojian.zhuang at linaro.org>
>>> Cc: Linus Walleij <linus.walleij at linaro.org>
>>> Cc: Arnd Bergmann <arnd at arndb.de>
>>
>> Tentatively applied, Haojian, does this look allright?
>>
>> Yours,
>> Linus Walleij
> 
> This patch is good.
> 
> Acked-by: Haojian Zhuang <haojian.zhuang at gmail.com>
> 

And what about the others? I think the first 3 patches of this series
can go through Linus W, and the other 2 should end up in the pxa tree,
right?


Thanks,
Daniel



From heiko at sntech.de  Thu Jul 25 05:02:22 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Thu, 25 Jul 2013 11:02:22 +0200
Subject: [PATCH 2/2] clocksource: dw_apb_timer_of: Fix read_sched_clock
In-Reply-To: <1374723797-22169-2-git-send-email-dinguyen@altera.com>
References: <1374723797-22169-1-git-send-email-dinguyen@altera.com>
 <1374723797-22169-2-git-send-email-dinguyen@altera.com>
Message-ID: <201307251102.23446.heiko@sntech.de>

Am Donnerstag, 25. Juli 2013, 05:43:17 schrieb dinguyen at altera.com:
> From: Dinh Nguyen <dinguyen at altera.com>
> 
> The read_sched_clock should return the ~value because the clock is a
> countdown implementation. read_sched_clock() should be the same as
> __apbt_read_clocksource().
> 
> If a separate timer for the sched_clock exist, then read_sched_clock()
> will return an incorrect value. The (sched_io_base + 0x4) needs to be in
> the function for both cases.
> 
> Also, remove the use of "dw-apb-timer-sp" and "dw-apb-timer-osc" since
> they are the same DW clock.
> 
> Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
> Acked-by: Jamie Iles <jamie at jamieiles.com>
> CC: Rob Herring <rob.herring at calxeda.com>
> CC: Arnd Bergmann <arnd at arndb.de>
> Cc: Olof Johansson <olof at lixom.net>
> CC: Jamie Iles <jamie at jamieiles.com>
> Cc: John Stultz <john.stultz at linaro.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Pavel Machek <pavel at denx.de>
> Cc: Heiko Stuebner <heiko at sntech.de>
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>  drivers/clocksource/dw_apb_timer_of.c |    7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clocksource/dw_apb_timer_of.c
> b/drivers/clocksource/dw_apb_timer_of.c index 4cbae4f..8e00929 100644
> --- a/drivers/clocksource/dw_apb_timer_of.c
> +++ b/drivers/clocksource/dw_apb_timer_of.c
> @@ -102,18 +102,17 @@ static void add_clocksource(struct device_node
> *source_timer) * timer is found. sched_io_base then points to the
> current_value * register of the clocksource timer.
>  	 */
> -	sched_io_base = iobase + 0x04;
> +	sched_io_base = iobase;
>  	sched_rate = rate;
>  }
> 
>  static u32 read_sched_clock(void)
>  {
> -	return __raw_readl(sched_io_base);
> +	return ~__raw_readl(sched_io_base + 0x4);
>  }
> 



>  static const struct of_device_id sptimer_ids[] __initconst = {
>  	{ .compatible = "picochip,pc3x2-rtc" },
> -	{ .compatible = "snps,dw-apb-timer-sp" },
>  	{ /* Sentinel */ },
>  };

I'm not 100% sure, but maybe the same explaination as below applies to this - 
with it better being part of the first patch.


> @@ -153,4 +152,4 @@ static void __init dw_apb_timer_init(struct device_node
> *timer) num_called++;
>  }
>  CLOCKSOURCE_OF_DECLARE(pc3x2_timer, "picochip,pc3x2-timer",
> dw_apb_timer_init); -CLOCKSOURCE_OF_DECLARE(apb_timer,
> "snps,dw-apb-timer-osc", dw_apb_timer_init);
> +CLOCKSOURCE_OF_DECLARE(apb_timer, "snps,dw-apb-timer",
> dw_apb_timer_init);

I think this hunk would better be part of the first patch, as you rename the 
devices in the dtsi files there and it has nothing to do with the sched_clock 
fix.

Changing the clocksource name here also breaks bisectability on the affected 
platforms because they wouldn't be able to add the clocksources when only the 
first patch is applied.


Heiko


From 21cnbao at gmail.com  Thu Jul 25 05:11:50 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Thu, 25 Jul 2013 17:11:50 +0800
Subject: [PATCH 4/6] ASoC: sirf-soc-inner: add drivers for both CPU and
 Codec DAIs
In-Reply-To: <20130719183503.GU9858@sirena.org.uk>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
 <1374232042-26088-5-git-send-email-Baohua.Song@csr.com>
 <20130719183503.GU9858@sirena.org.uk>
Message-ID: <CAGsJ_4xvGBj393rKPvDhumgDppe9k+K6Nbcef0KwGiYaHdhkxQ@mail.gmail.com>

2013/7/20 Mark Brown <broonie at kernel.org>:
> On Fri, Jul 19, 2013 at 07:07:20PM +0800, Barry Song wrote:
>
>> there is an internal codec embedded in the SiRF SoC. this is not
>> a typical user scenerios of ASoC. but we can still get benefit by
>> sharing platform DMA codes instead of implementing a pure ALSA
>> driver.
>> This driver adds DAI drivers for this internal codec.
>
> To be honest this shouldn't be too exciting from an ASoC point of view -
> just a normal CODEC driver with some stub DAIs.  It looks like it might
> benefit from regmap-mmio and DAPM.

the driver was a legacy pure alsa driver as it is not soc+external
codec+mach framework.
so it has many legacy codes. i agree we can move to regmap-mmio and asoc dapm.

>
>> +static int sirf_inner_control(struct snd_kcontrol *kcontrol,
>> +             struct snd_ctl_elem_value *ucontrol,
>> +             int get, char *name)
>> +{
>> +     struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
>> +     struct snd_soc_card *card = codec->card;
>> +     int i;
>> +     for (i = 0; i < card->num_controls; i++) {
>> +             if (!strcmp(card->controls[i].name, name)) {
>> +                     if (card->controls[i].get && get)
>> +                             return card->controls[i].get(kcontrol, ucontrol);
>> +                     else if (card->controls[i].put && !get)
>> +                             return card->controls[i].put(kcontrol, ucontrol);
>> +             }
>> +     }
>> +     return 0;
>> +}
>
> What is all this about?  I don't quite understand what the goal is and
> there's no comments.

it is a common kcontrol get/set function which will be called by all
of sirf_inner_snd_speaker_set, sirf_inner_snd_headphone_get,
sirf_inner_snd_headphone_set, sirf_inner_snd_speaker_get. after we
move to DAPM, it should be useless.

>
>> +static int sirf_inner_snd_speaker_set(struct snd_kcontrol *kcontrol,
>> +             struct snd_ctl_elem_value *ucontrol)
>> +{
>> +     struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
>> +     struct sirf_soc_inner_audio *sinner_audio = dev_get_drvdata(codec->dev);
>> +
>> +     spin_lock(&sinner_audio->lock);
>> +     sirf_inner_control(kcontrol, ucontrol, 0, "Speaker Out");
>> +
>> +     if (ucontrol->value.integer.value[0]) {
>> +             writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0)
>> +                             | IC_RDACEN | IC_SPSELR,
>> +                             sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
>> +
>> +             writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1) |
>> +                             (1 << sinner_audio->reg_bits->firdac_lout_en_bits),
>> +                             sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
>> +
>> +             writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) |
>> +                                     IC_SPEN), sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
>
> Is this possibly some supplies plus a power bit?
>
>> +static int sirf_inner_codec_startup(struct snd_pcm_substream *substream,
>> +             struct snd_soc_dai *dai)
>> +{
>> +     struct sirf_soc_inner_audio *sinner_audio = snd_soc_dai_get_drvdata(dai);
>> +     u32 adc_gain_mask = sinner_audio->reg_bits->adc_gain_mask;
>> +     u32 adc_left_gain_shift = sinner_audio->reg_bits->adc_left_gain_shift;
>> +     u32 adc_right_gain_shift = sinner_audio->reg_bits->adc_right_gain_shift;
>> +     u32 mic_max_gain = sinner_audio->reg_bits->mic_max_gain;
>
> Would regmap_field help here?
>
>> +             writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1) |
>> +                     (1 << sinner_audio->reg_bits->codec_clk_en_bits) |
>> +                     (1 << sinner_audio->reg_bits->por_bits),
>> +                     sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
>> +             msleep(50);
>> +
>> +             writel(readl(sinner_audio->base + AUDIO_IC_CODEC_PWR) |
>> +                     MICBIASEN, sinner_audio->base + AUDIO_IC_CODEC_PWR);
>> +             usleep_range(300, 1000);
>
> This all looks a lot like a normal CODEC power up sequence that's been
> open coded but could use DAPM?
>
>> +static void sirf_inner_codec_shutdown(struct snd_pcm_substream *substream,
>> +             struct snd_soc_dai *dai)
>> +{
>> +}
>> +
>> +static int sirf_inner_codec_hw_params(struct snd_pcm_substream *substream,
>> +             struct snd_pcm_hw_params *params,
>> +             struct snd_soc_dai *dai)
>> +{
>> +     return 0;
>> +}
>
> Remove empty functions.

ok.

>
>> +static int sirf_soc_inner_resume(struct platform_device *pdev)
>> +{
>> +     struct sirf_soc_inner_audio *sinner_audio = platform_get_drvdata(pdev);
>> +
>> +     clk_prepare_enable(sinner_audio->clk);
>> +
>> +     writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1)
>> +             | (1 << sinner_audio->reg_bits->codec_clk_en_bits)),
>> +             sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
>> +     writel((readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL1)
>> +             | (1 << sinner_audio->reg_bits->adc14b_12_bits)),
>> +             sinner_audio->base + AUDIO_IC_CODEC_CTRL1);
>> +     writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) | IC_CPFREQ,
>> +             sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
>> +     writel(readl(sinner_audio->base + AUDIO_IC_CODEC_CTRL0) | IC_CPEN,
>> +             sinner_audio->base + AUDIO_IC_CODEC_CTRL0);
>> +     return 0;
>> +}
>> +#else
>> +#define sirf_soc_inner_suspend NULL
>> +#define sirf_soc_inner_resume NULL
>> +#endif
>
> Standard runtime PM question and this definitely does look like
> regmap-mmio will help - you've essentially open coded some of it.

we can use runtime PM to handle clock disable/enable here. audio path
widgets, codec and speaker widgets will be handled by DAPM.

-barry


From broonie at kernel.org  Thu Jul 25 05:20:17 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 25 Jul 2013 10:20:17 +0100
Subject: [PATCH] spi: davinci: Update configs to make it selectable on
 Keystone
In-Reply-To: <1374712297-32187-1-git-send-email-santosh.shilimkar@ti.com>
References: <1374712297-32187-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <20130725092017.GU9858@sirena.org.uk>

On Wed, Jul 24, 2013 at 08:31:37PM -0400, Santosh Shilimkar wrote:
> Keystone2 SOCs share the SPI IP block with DaVinci based SOCs. Update
> the config bits so that its usable on Keystone2 based SOCs.

Applied, thanks.
-------------- 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/20130725/91548bdd/attachment.sig>

From linus.walleij at linaro.org  Thu Jul 25 05:20:54 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Jul 2013 11:20:54 +0200
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <1624911.6TtmtVmU1T@avalon>
References: <1624911.6TtmtVmU1T@avalon>
Message-ID: <CACRpkdazPX3EbVbLvXQZh0oRBpHoWPK+EkFO75v9zfAXSPCkHA@mail.gmail.com>

On Wed, Jul 24, 2013 at 1:21 AM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:

> Has anyone run into a similar issue ? My gut feeling is that the architecture
> isn't right somewhere, but I can't really pinpoint where.

We had a similar situation with the MFDs, where Mark, Lee and Sam
came up with the solution to include an irqdomain in the MFD cell
spawn function:

extern int mfd_add_devices(struct device *parent, int id,
                           struct mfd_cell *cells, int n_devs,
                           struct resource *mem_base,
                           int irq_base, struct irq_domain *irq_domain);

When each cell (i.e. a platform device) is created, the irq for that
cell will be translated with irq_create_mapping() so the cell/platform
device just get a Linux IRQ it can use and do not need to worry
about translating it.

Prior to this we had all sorts of exported translator functions
for the IRQs exported from each hub driver ---what a mess.

Can you think about a parent/child relationship making it possible
to pass the irqs readily translated in this case?

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Jul 25 05:27:41 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Jul 2013 11:27:41 +0200
Subject: Mainline kernel on snowball
In-Reply-To: <20130725052317.GA25854@verge.net.au>
References: <20130725052317.GA25854@verge.net.au>
Message-ID: <CACRpkdagoo965=8QMR-TwiD3GEwE4FjgdJv2ET1E4R0OWq+efw@mail.gmail.com>

On Thu, Jul 25, 2013 at 7:23 AM, Simon Horman <horms at verge.net.au> wrote:

> I would like to boot the mainline kernel - ideally v3.10 and v3.11-rcX -
> on snowball. The reason being to verify CPU hotplug which
> seems to be broken on shmobile, though that is tangential to this post.

I usually compile my kernel with this makefile:
http://www.df.lth.se/~triad/krad/makefiles/u8500.mak

It appends an initramfs and it appends a DTB (if you compile it
with config-dt and build-dt) and need nothing from any FS or
similar.

But the way it looks up compilers and initramfs etc is a bit
custom I gues ... you have a copy of my initramfs here:
http://www.df.lth.se/~triad/krad/ux00/rootfs-u8500.cpio

Yours,
Linus Walleij


From s.nawrocki at samsung.com  Thu Jul 25 05:29:46 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Thu, 25 Jul 2013 11:29:46 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <201307242032.03597.arnd@arndb.de>
References: <Pine.LNX.4.44L0.1307231708020.1304-100000@iolanthe.rowland.org>
 <5977067.8rykRgjgre@flatron> <201307242032.03597.arnd@arndb.de>
Message-ID: <51F0F00A.1040907@samsung.com>

On 07/24/2013 08:32 PM, Arnd Bergmann wrote:
> On Tuesday 23 July 2013, Tomasz Figa wrote:
>> On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
>>> On Tue, 23 Jul 2013, Tomasz Figa wrote:
>>>> Where would you want to have those phy_address arrays stored? There
>>>> are no board files when booting with DT. Not even saying that you
>>>> don't need to use any hacky schemes like this when you have DT that
>>>> nicely specifies relations between devices.
>>>
>>> If everybody agrees DT has a nice scheme for specifying relations
>>> between devices, why not use that same scheme in the PHY core?
>>
>> It is already used, for cases when consumer device has a DT node attached. 
>> In non-DT case this kind lookup translates loosely to something that is 
>> being done in regulator framework - you can't bind devices by pointers, 
>> because you don't have those pointers, so you need to use device names.
>>
> 
> Sorry for jumping in to the middle of the discussion, but why does a *new*
> framework even bother defining an interface for board files?
> 
> Can't we just drop any interfaces for platform data passing in the phy
> framework and put the burden of adding those to anyone who actually needs
> them? All the platforms we are concerned with here (exynos and omap,
> plus new platforms) can be booted using DT anyway.

Indeed, I was also a bit surprised we still need non-dt support, since
migration to this generic PHY framework in case of exynos was solely
part of migration of the whole platform to DT.

Two of the drivers that are being converted are also used on s5pv210,
but there is currently no boards in mainline that would use devices
covered by those drivers and s5pv210 will very likely get DT support
in v3.13 anyway.

But it seems omap still needs non-dt support in the PHY framework.

---
Thanks,
Sylwester


From broonie at kernel.org  Thu Jul 25 05:29:57 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 25 Jul 2013 10:29:57 +0100
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <201307242032.03597.arnd@arndb.de>
References: <Pine.LNX.4.44L0.1307231708020.1304-100000@iolanthe.rowland.org>
 <5977067.8rykRgjgre@flatron> <201307242032.03597.arnd@arndb.de>
Message-ID: <20130725092957.GV9858@sirena.org.uk>

On Wed, Jul 24, 2013 at 08:32:03PM +0200, Arnd Bergmann wrote:

> Sorry for jumping in to the middle of the discussion, but why does a *new*
> framework even bother defining an interface for board files?

> Can't we just drop any interfaces for platform data passing in the phy
> framework and put the burden of adding those to anyone who actually needs
> them? All the platforms we are concerned with here (exynos and omap,
> plus new platforms) can be booted using DT anyway.

There's a bunch of non-DT architectures that are in active use (blackfin
for example) and I'd really hope that this is useful for some of them.

The pushback here was about the fact that the subsystem was doing odd
things with selecting device names which is odd in itself, I don't know
if that had bled over into the DT bindings but it sounded like it
might've done so.
-------------- 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/20130725/51a7cbff/attachment.sig>

From linus.walleij at linaro.org  Thu Jul 25 05:30:28 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Jul 2013 11:30:28 +0200
Subject: [PATCH 1/5] gpio: pxa: remove dead code
In-Reply-To: <51F0E92E.6060900@gmail.com>
References: <1373555877-29887-1-git-send-email-zonque@gmail.com>
 <1373555877-29887-2-git-send-email-zonque@gmail.com>
 <CACRpkdaB7JnWzoLKpQ1eLWAi7yFz9CanhbhwtiCnEtcNWzX3RQ@mail.gmail.com>
 <CAD6h2NS0p-kMUGyhbr93vd_oLSNyaB572riFB8mHt1cu5f-bGw@mail.gmail.com>
 <51F0E92E.6060900@gmail.com>
Message-ID: <CACRpkdZT51uwW6z-BzmU2tv9-fX=UQN2ywCQwb-SDVHovo4BxA@mail.gmail.com>

On Thu, Jul 25, 2013 at 11:00 AM, Daniel Mack <zonque at gmail.com> wrote:

> And what about the others? I think the first 3 patches of this series
> can go through Linus W, and the other 2 should end up in the pxa tree,
> right?

Yes. They might need to build on top of the pinctrl tree.

Or, if there are no other things happening in the PXA tree for the
next merge window, I can take it into my tree, with the ACKs of
e.g. Eric and Olof Johansson.

Yours,
Linus Walleij


From jonathan.austin at arm.com  Thu Jul 25 05:30:29 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Thu, 25 Jul 2013 10:30:29 +0100
Subject: [PATCH 2/2] clk: fixup argument order when setting VCO parameters
In-Reply-To: <CACRpkdbEiNPG0b89zXKpvNgXtAbsKeV9A9ibgEJCBgNa6vQvCw@mail.gmail.com>
References: <1374594138-17080-1-git-send-email-jonathan.austin@arm.com>
 <1374594138-17080-3-git-send-email-jonathan.austin@arm.com>
 <CACRpkdbEiNPG0b89zXKpvNgXtAbsKeV9A9ibgEJCBgNa6vQvCw@mail.gmail.com>
Message-ID: <51F0F035.8010705@arm.com>

On 24/07/13 20:32, Linus Walleij wrote:
> On Tue, Jul 23, 2013 at 5:42 PM, Jonathan Austin
> <jonathan.austin at arm.com> wrote:
>
>> The order of arguments in the call to vco_set() for the ICST clocks appears to
>> have been switched in error, which results in the VCO not being initialised
>> correctly. This in turn stops the integrated LCD on things like Integrator/CP
>> from working correctly.
>>
>> This patch fixes the order and restores the expected functionality.
>>
>> Cc: Linus Walleij <linus.walleij at linaro.org>
>> Cc: Mike Turquette <mturquette at linaro.org>
>> Signed-off-by: Jonathan Austin <jonathan.austin at arm.com>
>
> Good catch! Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
> You should probably mark this for stable as well.
>

Mike, will you add Cc: stable when you take the fix or shall I resubmit 
the patch somehow else?

> What I don't understand is why my CLCD VGA output has
> been working all the time :-(
>

No, this confuses me too - perhaps the display you've got it plugged in 
to is really lenient about modes and just made the best of it?

> I thought this VCO was necessary for that as well,  but apparently
> it works with the defaults.

Certainly I can't get anything out of the display on my integrator or 
via the VGA port without this fix and the other one in the series.

Jonny
>
> Yours,
> Linus Walleij
>




From 21cnbao at gmail.com  Thu Jul 25 05:32:12 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Thu, 25 Jul 2013 17:32:12 +0800
Subject: [PATCH 3/6] ASoC: usp-pcm: add CPU DAI driver for PCM simulated
 from USP
In-Reply-To: <20130719181313.GT9858@sirena.org.uk>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
 <1374232042-26088-4-git-send-email-Baohua.Song@csr.com>
 <20130719181313.GT9858@sirena.org.uk>
Message-ID: <CAGsJ_4xNdxFWyN6NUEL36W9n+4Cj=01+QGi+xaeODm9u8pdP9A@mail.gmail.com>

2013/7/20 Mark Brown <broonie at kernel.org>:
> On Fri, Jul 19, 2013 at 07:07:19PM +0800, Barry Song wrote:
>
>> +static int sirf_usp_pcm_divider(struct snd_soc_dai *dai, int div_id, int rate)
>> +{
>> +     struct sirf_usp *susp = snd_soc_dai_get_drvdata(dai);
>> +
>> +     u32 clk_rate = clk_get_rate(susp->clk);
>> +     u32 clk_div = (clk_rate/(2*rate)) - 1;
>> +     u32 clk_div_hi = (clk_div & 0xC00)>>10;
>> +     u32 clk_div_lo = (clk_div & 0x3FF);
>> +
>> +     writel((clk_div_lo<<21) | readl(susp->base + USP_MODE2),
>> +             susp->base + USP_MODE2);
>> +     writel((clk_div_hi<<30) | readl(susp->base + USP_TX_FRAME_CTRL),
>> +             susp->base + USP_TX_FRAME_CTRL);
>> +
>> +     return 0;
>> +}
>
> I'd be happier if this did some validation on the supplied rate (for
> example, checking that it's less than the master rate) and had arguments
> specifying which clock was being affected (in case there's more in
> future revisions).

sounds good.

>
> Also what exactly is the rate being set - can the driver just figure
> this out automatically from the sample rate?

here it is generating the right pcm clock by an internal DIVISOR in USP module.

For USP_MODE2:
30:21 (R/W) USP_CLK_DIVISOR 10?h0 USP serial clock divider

For USP_TX_FRAME_CTRL:
31:30 (R/W) USP_CLK_DIVISOR 2?h0 This is the two bit [11:10] of
USP_CLK_DIVISOR in USP_MODE2

for figuring this out automatically from the sample rate, do you mean
a lookup table for common sample rate?

>
>> +#ifdef CONFIG_PM
>> +static int sirf_usp_pcm_suspend(struct platform_device *pdev,
>> +     pm_message_t state)
>> +{
>> +     struct sirf_usp *susp = platform_get_drvdata(pdev);
>> +
>> +     susp->mode1_reg = readl(susp->base + USP_MODE1);
>> +     susp->mode2_reg = readl(susp->base + USP_MODE2);
>> +     sirf_usp_controller_uninit(susp);
>> +     clk_disable_unprepare(susp->clk);
>> +
>> +     return 0;
>> +}
>
> Can this be done as runtime PM as well?  Seems like it'd save power.

agree.

>
>> +     susp->clk = clk_get(&pdev->dev, NULL);
>> +     if (IS_ERR(susp->clk)) {
>> +             dev_err(&pdev->dev, "Get clock failed.\n");
>> +             return PTR_ERR(susp->clk);
>> +     }
>
> devm_clk_get().

agree. missed this one.

-barry


From linus.walleij at linaro.org  Thu Jul 25 05:33:27 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Jul 2013 11:33:27 +0200
Subject: [PATCH 2/2] clk: fixup argument order when setting VCO parameters
In-Reply-To: <51F0F035.8010705@arm.com>
References: <1374594138-17080-1-git-send-email-jonathan.austin@arm.com>
 <1374594138-17080-3-git-send-email-jonathan.austin@arm.com>
 <CACRpkdbEiNPG0b89zXKpvNgXtAbsKeV9A9ibgEJCBgNa6vQvCw@mail.gmail.com>
 <51F0F035.8010705@arm.com>
Message-ID: <CACRpkdb7UGS8ysPv=LakbWouUdL9MpKvrgYKh_v9NqSYV3TStg@mail.gmail.com>

On Thu, Jul 25, 2013 at 11:30 AM, Jonathan Austin
<jonathan.austin at arm.com> wrote:

>> What I don't understand is why my CLCD VGA output has
>> been working all the time :-(
>>
>
> No, this confuses me too - perhaps the display you've got it plugged in to
> is really lenient about modes and just made the best of it?

I think it's because it is set up into some mode by the boot
monitor, as I get the boot monitor prompt on the VGA
display.

Then as the VCO params get written, it is never really unlocked
so the registers are untouched.

You may have a different boot monitor?

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Jul 25 05:35:10 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Jul 2013 11:35:10 +0200
Subject: [PATCH 0/3] MSM gpio fixes
In-Reply-To: <20130724224126.GA27678@codeaurora.org>
References: <1374178035-19943-1-git-send-email-davidb@codeaurora.org>
 <CACRpkdbOO8fFEx+PxsdJ9F1dqD6V4_RPZThvTufo9+XhhyuHOg@mail.gmail.com>
 <20130724224126.GA27678@codeaurora.org>
Message-ID: <CACRpkdb6N-i5cSTSmaB9XCLT6hoYwVRRTxZvuzPw6erCD5P4SQ@mail.gmail.com>

On Thu, Jul 25, 2013 at 12:41 AM, David Brown <davidb at codeaurora.org> wrote:
> On Sat, Jul 20, 2013 at 10:54:42PM +0200, Linus Walleij wrote:

>>>   ARM: msm: Consolidate gpiomux for older architectures
>>
>> This does not look like a fix? Surely this can wait for v3.12?
>
> It fixes compilation.  But, it could also wait for v3.12.

Well it's up to you. The GPIO patch is in Torvalds tree now, so the
rest goes through ARM SoC I guess...

Yours,
Linus Walleij


From jonathan.austin at arm.com  Thu Jul 25 05:36:25 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Thu, 25 Jul 2013 10:36:25 +0100
Subject: [PATCH 2/2] clk: fixup argument order when setting VCO parameters
In-Reply-To: <CACRpkdb7UGS8ysPv=LakbWouUdL9MpKvrgYKh_v9NqSYV3TStg@mail.gmail.com>
References: <1374594138-17080-1-git-send-email-jonathan.austin@arm.com>
 <1374594138-17080-3-git-send-email-jonathan.austin@arm.com>
 <CACRpkdbEiNPG0b89zXKpvNgXtAbsKeV9A9ibgEJCBgNa6vQvCw@mail.gmail.com>
 <51F0F035.8010705@arm.com>
 <CACRpkdb7UGS8ysPv=LakbWouUdL9MpKvrgYKh_v9NqSYV3TStg@mail.gmail.com>
Message-ID: <51F0F199.3040501@arm.com>

On 25/07/13 10:33, Linus Walleij wrote:
> On Thu, Jul 25, 2013 at 11:30 AM, Jonathan Austin
> <jonathan.austin at arm.com> wrote:
>
>>> What I don't understand is why my CLCD VGA output has
>>> been working all the time :-(
>>>
>>
>> No, this confuses me too - perhaps the display you've got it plugged in to
>> is really lenient about modes and just made the best of it?
>
> I think it's because it is set up into some mode by the boot
> monitor, as I get the boot monitor prompt on the VGA
> display.
>
> Then as the VCO params get written, it is never really unlocked
> so the registers are untouched.
>
> You may have a different boot monitor?
>

Ahh, that seems highly likely. I don't ever see boot-monitor (boot 
straight in to uboot) but I don't see anything on the display until the 
kernel boots, so I don't think BM is setting up the VCO for me.

Jonny




From linus.walleij at linaro.org  Thu Jul 25 05:37:52 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Jul 2013 11:37:52 +0200
Subject: Issue with gpio and pinmux
In-Reply-To: <51EB590A.4010600@wwwdotorg.org>
References: <51E667BC.3070804@parrot.com> <51E82FBB.1080905@wwwdotorg.org>
 <CACRpkdb1n07KoQZSme1EMJfV-9pHr-kd_1eJ6HsBV5gz7Dh3Ww@mail.gmail.com>
 <51EB590A.4010600@wwwdotorg.org>
Message-ID: <CACRpkdZdbxEt67+YBKif4-BKAToOmN0_c8HFOdjSG91dtJwJQw@mail.gmail.com>

On Sun, Jul 21, 2013 at 5:44 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:

> Actually, a better way to do (c) might be to just add an extra "op" to
> struct pinmux_ops; something like validate_gpio_mux(), passing in
> information such as whether a mux function is in effect on that pin,
> whether the pin is already claimed as a GPIO, and whether the function
> is being called to check a GPIO-claim or mux-claim operation . If the op
> is missing, no "dual claim" is allowed. If the op is present, the code
> in the op validates whether the particular GPIO is allowed to be claimed
> while the particular mux function is active.
>
> That way, I think any driver that doesn't want to allow dual-claim
> doesn't have to do anything, but the few drivers that do can code up
> whatever algorithm they want; for Tegra, I'd just allow everything for
> simplicity, but we could always enhance that later if we want.

You are right, this would be an elegant solution.

Christian, are you interested in coding this up?

Yours,
Linus Walleij


From nsekhar at ti.com  Thu Jul 25 05:40:19 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Thu, 25 Jul 2013 15:10:19 +0530
Subject: [PATCH 1/2] i2c: davinci: remove useless mach/hardware include
In-Reply-To: <1374712099-32095-2-git-send-email-santosh.shilimkar@ti.com>
References: <1374712099-32095-1-git-send-email-santosh.shilimkar@ti.com>
 <1374712099-32095-2-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <51F0F283.5080900@ti.com>

On Thursday 25 July 2013 05:58 AM, Santosh Shilimkar wrote:
> This driver no longer uses definitions from mach/hardware.h.
> On the other hand, including this header breaks this driver
> on non-davinci platforms which don't have such a header.
> 
> Fix it.
> 
> Cc: Sekhar Nori <nsekhar at ti.com>
> Cc: Wolfram Sang <wsa at the-dreams.de>
> 
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>

Acked-by: Sekhar Nori <nsekhar at ti.com>

One minor nit:

> ---
>  drivers/i2c/busses/i2c-davinci.c |    1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
> index fa55605..ddaa2a3 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -41,7 +41,6 @@
>  #include <linux/of_i2c.h>
>  #include <linux/of_device.h>
>  

You can now remove this empty line too.

Thanks,
Sekhar

> -#include <mach/hardware.h>
>  #include <linux/platform_data/i2c-davinci.h>
>  
>  /* ----- global defines ----------------------------------------------- */
> 



From laurent.pinchart at ideasonboard.com  Thu Jul 25 05:42:10 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 25 Jul 2013 11:42:10 +0200
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <20130724202446.6CAF23E1313@localhost>
References: <1624911.6TtmtVmU1T@avalon> <20130724202446.6CAF23E1313@localhost>
Message-ID: <1963628.LyVehxJcEL@avalon>

Hi Grant,

Thank you for your answer.

On Wednesday 24 July 2013 21:24:46 Grant Likely wrote:
> On Wed, 24 Jul 2013 01:21:44 +0200, Laurent Pinchart wrote:
> > Hello,
> > 
> > I'm running into an issue on several Renesas SoC with IRQ domains and
> > GPIOs.
> > 
> > On sh73a0, r8a73a4 and r8a7740, GPIOs and external interrupts are handled
> > by two separate IP cores, namely the PFC (Pin Function Controller) and
> > INTC (Interrupt Controller). The former is handled by the sh-pfc driver
> > (drivers/pinctrl/sh-pfc) and the later by the irq-renesas-intc-irqpin
> > driver (drivers/irqchip), referred to below as the irqpin driver.
> > 
> > The sh73a0, for instance, has 32 external interrupt lines that are
> > multiplexed on pins usable as GPIOs. Both the GPIO and external interrupt
> > functions are usable at the same time, which allows reading the state of
> > the interrupt lines.
> > 
> > These external interrupts are for MMC/SD support, among other devices. In
> > this specific case the MMC/SD Card Detect signal is wired to one of the
> > external interrupt signals, and the corresponding GPIO is passed to the
> > MMC/SD controller driver. Depending on other configuration parameters the
> > driver can then either poll the Card Detect signal, or register an
> > interrupt handler to detect changes in the signal state. This features is
> > implemented by the MMC/SD core, which call gpio_to_irq() on the GPIO to
> > retrieve the corresponding IRQ number.
> > 
> > On non-DT systems the external IRQs are statically mapped at a known
> > offset. The sh-pfc driver, to implement the gpio_to_irq() function
> > (through its gpiochip .to_irq() handler), simply searches a SoC-specific
> > lookup table for the fixed IRQ number associated with a given GPIO.
> > 
> > However, on DT systems, IRQs are mapped dynamically on demand. The irqpin
> > driver registers a simple IRQ domain, and the irq_create_mapping()
> > function can then be used to map a given IRQ, specified as an offset in
> > the domain. This is where the problem appears, as the irqchip .to_irq()
> > function is implemented in the sh-pfc driver, which doesn't have access to
> > the IRQ domain registered by the irqpin driver.
> > 
> > I could hack around this by exporting a function in the irqpin driver that
> > would map an IRQ, and call that function from the sh-pfc driver. I'd
> > rather avoid that solution as it would add a direct dependency between the
> > two drivers.
> 
> Well, the gpio controller really does need to know what irq is associated
> with a GPIO line. If the gpio controller driver doesn't have direct access
> to that information, then it needs to have a hook to set it up.

The GPIO controller knows what hardware IRQ is associated with a GPIO line. It 
can't however translate on its own that hardware IRQ number to a global IRQ 
number, as the global IRQ numbers are allocated dynamically through the IRQ 
mapping domain, which is local to the IRQ chip driver.

To summarize the issue, the GPIO API exports a GPIO to IRQ translation 
function, which requires two steps:

- translating from a GPIO number to an IRQ chip and an IRQ chip local hardware 
IRQ number

- translation from the hardware IRQ number to a global IRQ number

The second step currently requires information known to the IRQ chip driver 
only.

> In the past, I've seen gpio controllers have an interrupts property
> specifying which interrupts it is connected to and can use for GPIO events.
> That seems like a resonable scenario in this regard, but if GPIOS are 1:1
> mapped to irqs, then it means a lot of interrupt entries need to appear in
> the GPIO node. The other option is to add a hook directly to the gpio driver
> so that it knows to use a specific irq controller; but that feels wrong.
> Thought it may be a bit verbose, the addition of an interrupts property to
> the GPIO controller node is probably what is wanted.

That's a good idea. I don't actually need to specify all the interrupts 
associated with the GPIOs (there are 58 of them in the worst case), as the 
GPIO driver knows the hardware IRQ number of all interrupts associated with a 
GPIO. I could just specify the interrupt-parent in the GPIO DT node, and call 
irq_create_of_mapping() directly in my .to_irq() handler to translate the IRQ 
number using the interrupt-parent phandle as the controller argument. Would 
that be considered as an acceptable hack, or would it be preferred to specify 
the interrupts individually in the GPIO controller DT node ?

> There has also been a trend to make gpio controllers also interrupt
> controllers if they support being used directly as irq inputs, but that
> doesn't really help your problem.  :-)

Newer generations of the Renesas SoCs have a GPIO controller than also acts as 
an IRQ controller, but older generations unfortunately have two separate IP 
cores.

-- 
Regards,

Laurent Pinchart



From nsekhar at ti.com  Thu Jul 25 05:44:23 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Thu, 25 Jul 2013 15:14:23 +0530
Subject: [RFC] ARM: davinci: da850: add a few pinmux definitions
In-Reply-To: <1374610382-11204-1-git-send-email-vivien.didelot@savoirfairelinux.com>
References: <1374610382-11204-1-git-send-email-vivien.didelot@savoirfairelinux.com>
Message-ID: <51F0F377.1060204@ti.com>

Hi Vivien,

On Wednesday 24 July 2013 01:43 AM, Vivien Didelot wrote:
> This patch adds some pinmux definitions that we needed, such as SPI0,
> SPI1 and some GPIO.
> 
> Note: I sent the patch as an RFC because I would like a confirmation for the
> appropriate name for SPI*_SCS* and EMA_A_RW pinmuxes.
> 
> Signed-off-by: Vivien Didelot <vivien.didelot at savoirfairelinux.com>

Why do you need to add these definitions? If it is for a new platform
you are working on, then it should be supported using DT, in which case
we use the pinctrl-single driver and define the muxing needed in
.dts/.dtsi files.

Thanks,
Sekhar



From laurent.pinchart at ideasonboard.com  Thu Jul 25 05:45:33 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 25 Jul 2013 11:45:33 +0200
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <CACRpkdazPX3EbVbLvXQZh0oRBpHoWPK+EkFO75v9zfAXSPCkHA@mail.gmail.com>
References: <1624911.6TtmtVmU1T@avalon>
 <CACRpkdazPX3EbVbLvXQZh0oRBpHoWPK+EkFO75v9zfAXSPCkHA@mail.gmail.com>
Message-ID: <1408178.cxAUTUGJc5@avalon>

Hi Linus,

Thank you for your answer.

On Thursday 25 July 2013 11:20:54 Linus Walleij wrote:
> On Wed, Jul 24, 2013 at 1:21 AM, Laurent Pinchart wrote:
> > Has anyone run into a similar issue ? My gut feeling is that the
> > architecture isn't right somewhere, but I can't really pinpoint where.
> 
> We had a similar situation with the MFDs, where Mark, Lee and Sam came up
> with the solution to include an irqdomain in the MFD cell spawn function:
> 
> extern int mfd_add_devices(struct device *parent, int id,
>                            struct mfd_cell *cells, int n_devs,
>                            struct resource *mem_base,
>                            int irq_base, struct irq_domain *irq_domain);
> 
> When each cell (i.e. a platform device) is created, the irq for that cell
> will be translated with irq_create_mapping() so the cell/platform device
> just get a Linux IRQ it can use and do not need to worry about translating
> it.
> 
> Prior to this we had all sorts of exported translator functions for the IRQs
> exported from each hub driver ---what a mess.
> 
> Can you think about a parent/child relationship making it possible to pass
> the irqs readily translated in this case?

The two devices are independent, so there's no real parent/child relationship. 
However, as Grant proposed, I could list all the interrupts associated with 
GPIOs in the GPIO controller DT node. I would then just call 
irq_of_parse_and_map() in the .to_irq() handler to magically translate the 
GPIO number to a mapped IRQ number.

The number of interrupts can be pretty high (up to 58 in the worst case so 
far), so an alternative would be to specify the interrupt-parent only, and 
call irq_create_of_mapping() directly. What solution would you prefer ?

-- 
Regards,

Laurent Pinchart



From will.deacon at arm.com  Thu Jul 25 05:44:48 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 10:44:48 +0100
Subject: [PATCH 11/14] ARM: alignment: correctly decode instructions in
 BE8 mode.
In-Reply-To: <1374661682-9349-12-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-12-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130725094447.GE27613@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 11:27:59AM +0100, Ben Dooks wrote:
> If we are in BE8 mode, we must deal with the instruction stream being
> in LE order when data is being loaded in BE order. Ensure the data is
> swapped before processing to avoid thre following:
> 
> Change to using <asm/opcodes.h> to provide the necessary conversion
> functions to change the byte ordering.
> 
> Alignment trap: not handling instruction 030091e8 at [<80333e8c>]
> Unhandled fault: alignment exception (0x001) at 0xbfa09567
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---
>  arch/arm/mm/alignment.c |    8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
> index 6f4585b..f38145a 100644
> --- a/arch/arm/mm/alignment.c
> +++ b/arch/arm/mm/alignment.c
> @@ -25,6 +25,7 @@
>  #include <asm/cp15.h>
>  #include <asm/system_info.h>
>  #include <asm/unaligned.h>
> +#include <asm/opcodes.h>
>  
>  #include "fault.h"
>  
> @@ -762,21 +763,24 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
>  	if (thumb_mode(regs)) {
>  		u16 *ptr = (u16 *)(instrptr & ~1);
>  		fault = probe_kernel_address(ptr, tinstr);
> +		tinstr = __mem_to_opcode_thumb16(tinstr);
>  		if (!fault) {
>  			if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
>  			    IS_T32(tinstr)) {
>  				/* Thumb-2 32-bit */
>  				u16 tinst2 = 0;
>  				fault = probe_kernel_address(ptr + 1, tinst2);
> +				tinst2 = __mem_to_opcode_thumb16(tinst2);
>  				instr = (tinstr << 16) | tinst2;
>  				thumb2_32b = 1;
>  			} else {
>  				isize = 2;
> -				instr = thumb2arm(tinstr);

As Dave pointed out in the other thread, this looks like an erroneous
deletion.

Will


From Sudeep.KarkadaNagesha at arm.com  Thu Jul 25 05:45:37 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Thu, 25 Jul 2013 10:45:37 +0100
Subject: [PATCH v3 1/3] drivers: clocksource: configure event stream for ARM
 arch timer
In-Reply-To: <1374492082-13686-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374492082-13686-2-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <1374745537-30389-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>

From: Will Deacon <will.deacon at arm.com>

The ARM architected timer can generate events (used for waking up
CPUs executing the wfe instruction) at a frequency represented as a
power-of-2 divisor of the clock rate.

This patch configures the event stream, aiming for a period of 100us
between events. This can be used to implement wfe-based timeouts for
userspace locking implementations.

This patch also adds the hwcaps for the same, so that userspace can
detect this feature.

Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/arch_timer.h    | 6 ++++--
 arch/arm/include/uapi/asm/hwcap.h    | 1 +
 arch/arm/kernel/setup.c              | 1 +
 arch/arm64/include/asm/arch_timer.h  | 6 +++---
 drivers/clocksource/arm_arch_timer.c | 9 ++++++++-
 include/clocksource/arm_arch_timer.h | 2 ++
 6 files changed, 19 insertions(+), 6 deletions(-)

------------>8---------------------

Hi,

This version adds the hwcaps for publishing the event stream feature to the
userspace.

This patch is now rebased on rmk's fixes branch as it conflicts with ab8d46c0 
"ARM: 7788/1: elf: fix lpae hwcap feature reporting in proc/cpuinfo"

Regards,
Sudeep

diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h
index e406d57..8963877 100644
--- a/arch/arm/include/asm/arch_timer.h
+++ b/arch/arm/include/asm/arch_timer.h
@@ -89,16 +89,18 @@ static inline u64 arch_counter_get_cntvct(void)
 	return cval;
 }
 
-static inline void arch_counter_set_user_access(void)
+static inline void arch_counter_set_user_access(int divider)
 {
 	u32 cntkctl;
 
 	asm volatile("mrc p15, 0, %0, c14, c1, 0" : "=r" (cntkctl));
 
 	/* disable user access to everything */
-	cntkctl &= ~((3 << 8) | (7 << 0));
+	cntkctl &= ~((3 << 8) | (0xf << 4) | (3 << 0));
+	cntkctl |= (divider << 4) | (1 << 2);
 
 	asm volatile("mcr p15, 0, %0, c14, c1, 0" : : "r" (cntkctl));
+	elf_hwcap |= HWCAP_EVTSTRM;
 }
 #endif
 
diff --git a/arch/arm/include/uapi/asm/hwcap.h b/arch/arm/include/uapi/asm/hwcap.h
index 6d34d08..7dcc10d 100644
--- a/arch/arm/include/uapi/asm/hwcap.h
+++ b/arch/arm/include/uapi/asm/hwcap.h
@@ -26,5 +26,6 @@
 #define HWCAP_VFPD32	(1 << 19)	/* set if VFP has 32 regs (not 16) */
 #define HWCAP_IDIV	(HWCAP_IDIVA | HWCAP_IDIVT)
 #define HWCAP_LPAE	(1 << 20)
+#define HWCAP_EVTSTRM	(1 << 21)
 
 #endif /* _UAPI__ASMARM_HWCAP_H */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 96286cb..5191956 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -973,6 +973,7 @@ static const char *hwcap_str[] = {
 	"idivt",
 	"vfpd32",
 	"lpae",
+	"evtstrm",
 	NULL
 };
 
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index 98abd47..8c1e42f 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -97,16 +97,16 @@ static inline u32 arch_timer_get_cntfrq(void)
 	return val;
 }
 
-static inline void arch_counter_set_user_access(void)
+static inline void arch_counter_set_user_access(int divider)
 {
 	u32 cntkctl;
 
 	/* Disable user access to the timers and the physical counter. */
 	asm volatile("mrs	%0, cntkctl_el1" : "=r" (cntkctl));
-	cntkctl &= ~((3 << 8) | (1 << 0));
+	cntkctl &= ~((3 << 8) | (0xf << 4) | (1 << 0));
 
 	/* Enable user access to the virtual counter and frequency. */
-	cntkctl |= (1 << 1);
+	cntkctl |= (divider << 4) | (1 << 2) | (1 << 1);
 	asm volatile("msr	cntkctl_el1, %0" : : "r" (cntkctl));
 }
 
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index ffadd83..6301ee5 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -125,6 +125,8 @@ static int arch_timer_set_next_event_phys(unsigned long evt,
 
 static int arch_timer_setup(struct clock_event_device *clk)
 {
+	int evt_stream_div, pos;
+
 	clk->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP;
 	clk->name = "arch_sys_timer";
 	clk->rating = 450;
@@ -153,7 +155,12 @@ static int arch_timer_setup(struct clock_event_device *clk)
 			enable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI], 0);
 	}
 
-	arch_counter_set_user_access();
+	/* Find the closest power of two to the divisor */
+	evt_stream_div = arch_timer_rate / ARCH_TIMER_EVT_STREAM_FREQ;
+	pos = fls(evt_stream_div);
+	if (pos > 1 && !(evt_stream_div & (1 << (pos - 2))))
+		pos--;
+	arch_counter_set_user_access(min(pos, 15));
 
 	return 0;
 }
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index c463ce9..24dc140 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -29,6 +29,8 @@
 #define ARCH_TIMER_PHYS_ACCESS		0
 #define ARCH_TIMER_VIRT_ACCESS		1
 
+#define ARCH_TIMER_EVT_STREAM_FREQ	10000	/* 100us */
+
 #ifdef CONFIG_ARM_ARCH_TIMER
 
 extern u32 arch_timer_get_rate(void);
-- 
1.8.1.2




From will.deacon at arm.com  Thu Jul 25 05:54:26 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 10:54:26 +0100
Subject: [PATCH 13/14] ARM: module: correctly relocate instructions in BE8
In-Reply-To: <1374661682-9349-14-git-send-email-ben.dooks@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-14-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130725095425.GF27613@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 11:28:01AM +0100, Ben Dooks wrote:
> When in BE8 mode, our instructions are not in the same ordering as the
> data, so use <asm/opcodes.h> to take this into account.
> 
> Note, also requires modules to be built --be8

This seems fairly methodical to me.

> @@ -132,7 +136,7 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
>  
>  		case R_ARM_MOVW_ABS_NC:
>  		case R_ARM_MOVT_ABS:
> -			offset = *(u32 *)loc;
> +			offset = tmp = __mem_to_opcode_arm(*(u32 *)loc);
>  			offset = ((offset & 0xf0000) >> 4) | (offset & 0xfff);
>  			offset = (offset ^ 0x8000) - 0x8000;

I find the double assignment a bit gratuitous, but that's just a cosmetic
issue.

  Reviewed-by: Will Deacon <will.deacon at arm.com>

Will


From mugunthanvnm at ti.com  Thu Jul 25 06:00:40 2013
From: mugunthanvnm at ti.com (Mugunthan V N)
Date: Thu, 25 Jul 2013 15:30:40 +0530
Subject: [PATCH 1/2] ARM: OMAP2+: hwmod: rt address space index for DT
In-Reply-To: <4bb04ee7bcb8ca73d5fc43049ba029471b9cdda3.1373036932.git.afzal@ti.com>
References: <4bb04ee7bcb8ca73d5fc43049ba029471b9cdda3.1373036932.git.afzal@ti.com>
Message-ID: <51F0F748.9020904@ti.com>

On 7/5/2013 8:43 PM, Afzal Mohammed wrote:
> Address space is being removed from hwmod database and DT information
> in <reg> property is being used. Currently the 0th index of device
> address space is used to map for register target address. This is not
> always true, eg. cpgmac has it's sysconfig in second address space.
>
> Handle it by specifying index of device address space to be used for
> register target. As default value of this field would be zero with
> static initialization, existing behaviour of using first address space
> for register target while using DT would be kept as such.
>
> Signed-off-by: Afzal Mohammed <afzal at ti.com>
I have tested this patch and it's needed when we have CPSW Ethernet built-in to
go to low power state.

Tested-by: Mugunthan V N <mugunthanvnm at ti.com>

Regards
Mugunthan V N


From mugunthanvnm at ti.com  Thu Jul 25 06:01:43 2013
From: mugunthanvnm at ti.com (Mugunthan V N)
Date: Thu, 25 Jul 2013 15:31:43 +0530
Subject: [PATCH 2/2] ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space
In-Reply-To: <84d9a3ae9ab7a47924eb54934dcad91339543d63.1373036932.git.afzal@ti.com>
References: <4bb04ee7bcb8ca73d5fc43049ba029471b9cdda3.1373036932.git.afzal@ti.com>
 <84d9a3ae9ab7a47924eb54934dcad91339543d63.1373036932.git.afzal@ti.com>
Message-ID: <51F0F787.9030108@ti.com>

On 7/5/2013 8:43 PM, Afzal Mohammed wrote:
> Register target address to be used for cpgmac is the second device
> address space. By default, hwmod picks first address space (0th index)
> for register target.
>
> With removal of address space from hwmod and using DT instead, cpgmac
> is getting wrong address space for register target.
>
> Fix it by indicating the address space to be used for register target.
>
> Signed-off-by: Afzal Mohammed <afzal at ti.com>
I have tested this patch and it's needed when we have CPSW Ethernet built-in to
go to low power state.

Tested-by: Mugunthan V N <mugunthanvnm at ti.com>

Regards
Mugunthan V N


From kishon at ti.com  Thu Jul 25 06:11:21 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 25 Jul 2013 15:41:21 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130725092957.GV9858@sirena.org.uk>
References: <Pine.LNX.4.44L0.1307231708020.1304-100000@iolanthe.rowland.org>
 <5977067.8rykRgjgre@flatron> <201307242032.03597.arnd@arndb.de>
 <20130725092957.GV9858@sirena.org.uk>
Message-ID: <51F0F9C9.2020500@ti.com>

Hi,

On Thursday 25 July 2013 02:59 PM, Mark Brown wrote:
> On Wed, Jul 24, 2013 at 08:32:03PM +0200, Arnd Bergmann wrote:
> 
>> Sorry for jumping in to the middle of the discussion, but why does a *new*
>> framework even bother defining an interface for board files?
> 
>> Can't we just drop any interfaces for platform data passing in the phy
>> framework and put the burden of adding those to anyone who actually needs
>> them? All the platforms we are concerned with here (exynos and omap,
>> plus new platforms) can be booted using DT anyway.
> 
> There's a bunch of non-DT architectures that are in active use (blackfin
> for example) and I'd really hope that this is useful for some of them.
> 
> The pushback here was about the fact that the subsystem was doing odd
> things with selecting device names which is odd in itself, I don't know
> if that had bled over into the DT bindings but it sounded like it
> might've done so.

Not really. device names was specifically used for non-dt boot case. For dt, it
uses the phandle mechanism which is pretty much used in all other subsystems.
Anyway I'm fixing Greg's comments and will posting a new version soon.

Thanks
Kishon


From will.deacon at arm.com  Thu Jul 25 06:14:42 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 11:14:42 +0100
Subject: [PATCH 03/14] ARM: fixup_pv_table bug when CPU_ENDIAN_BE8
In-Reply-To: <51EFF1B2.4050609@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-4-git-send-email-ben.dooks@codethink.co.uk>
 <20130724143335.GL11072@mudshark.cambridge.arm.com>
 <51EFF1B2.4050609@codethink.co.uk>
Message-ID: <20130725101442.GA5609@mudshark.cambridge.arm.com>

On Wed, Jul 24, 2013 at 04:24:34PM +0100, Ben Dooks wrote:
> On 24/07/13 15:33, Will Deacon wrote:
> > On Wed, Jul 24, 2013 at 11:27:51AM +0100, Ben Dooks wrote:
> >> The fixup_pv_table assumes that the instructions are in the same
> >> endian configuration as the data, but when the CPU is running in
> >> BE8 the instructions stay in little-endian format.
> >>
> >> Make sure if CONFIG_CPU_ENDIAN_BE8 is set that we do all the
> >> alterations to the instructions taking in to account the LDR/STR
> >> will be swapping the data endian-ness.
> >>
> >> Since the code is only modifying a byte, we avoid dual-swapping
> >> the data, and just change the bits we clear and ORR in (in the
> >> case where the code is not thumb2).
> >>
> >> For thumb2, we add the necessary rev16 instructions to ensure that
> >> the instructions are processed in the correct format, as it was
> >> easier than re-writing the code to contain a mask and shift.
> >>
> >> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
> >> ---
> >>   arch/arm/kernel/head.S |    8 ++++++++
> >>   1 file changed, 8 insertions(+)
> >>
> >> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> >> index 8bac553..e40c0b3b 100644
> >> --- a/arch/arm/kernel/head.S
> >> +++ b/arch/arm/kernel/head.S
> >> @@ -584,8 +584,10 @@ __fixup_a_pv_table:
> >>   	b	2f
> >>   1:	add     r7, r3
> >>   	ldrh	ip, [r7, #2]
> >> +ARM_BE8(rev16	ip, ip)
> >>   	and	ip, 0x8f00
> >>   	orr	ip, r6	@ mask in offset bits 31-24
> >> +ARM_BE8(rev16	ip, ip)
> >
> > I'm not sure I follow you when you say this is easier than a mask and a
> > shift? As far as I can tell, it's two extra instructions and makes the LE
> > and BE cases look different.
> 
> I am not as familiar with THUMB2 as the ARM, so it was easier
> to do this than see if there where any spare registers to hold the
> mask and shift values, and use them.

What's wrong with the following?

Will

--->8

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 9cf6063..ee660c2 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -581,8 +581,13 @@ __fixup_a_pv_table:
        b       2f
 1:     add     r7, r3
        ldrh    ip, [r7, #2]
+#ifdef CONFIG_CPU_ENDIAN_BE8
+       and     ip, 0x008f
+       orr     ip, ip, r6, lsl #24
+#else
        and     ip, 0x8f00
        orr     ip, r6  @ mask in offset bits 31-24
+#endif
        strh    ip, [r7, #2]
 2:     cmp     r4, r5
        ldrcc   r7, [r4], #4    @ use branch for delay slot


From laurent.pinchart at ideasonboard.com  Thu Jul 25 06:16:30 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 25 Jul 2013 12:16:30 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <201307242032.03597.arnd@arndb.de>
References: <Pine.LNX.4.44L0.1307231708020.1304-100000@iolanthe.rowland.org>
 <5977067.8rykRgjgre@flatron> <201307242032.03597.arnd@arndb.de>
Message-ID: <2174304.5JlzJ583hP@avalon>

Hi Arnd,

On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote:
> On Tuesday 23 July 2013, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
> > > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > > > Where would you want to have those phy_address arrays stored? There
> > > > are no board files when booting with DT. Not even saying that you
> > > > don't need to use any hacky schemes like this when you have DT that
> > > > nicely specifies relations between devices.
> > > 
> > > If everybody agrees DT has a nice scheme for specifying relations
> > > between devices, why not use that same scheme in the PHY core?
> > 
> > It is already used, for cases when consumer device has a DT node attached.
> > In non-DT case this kind lookup translates loosely to something that is
> > being done in regulator framework - you can't bind devices by pointers,
> > because you don't have those pointers, so you need to use device names.
> 
> Sorry for jumping in to the middle of the discussion, but why does a *new*
> framework even bother defining an interface for board files?
> 
> Can't we just drop any interfaces for platform data passing in the phy
> framework and put the burden of adding those to anyone who actually needs
> them? All the platforms we are concerned with here (exynos and omap, plus
> new platforms) can be booted using DT anyway.

What about non-DT architectures such as MIPS (still widely used in consumer 
networking equipments from what I've heard) ?

-- 
Regards,

Laurent Pinchart



From ben.dooks at codethink.co.uk  Thu Jul 25 06:21:21 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 11:21:21 +0100
Subject: [PATCH 03/14] ARM: fixup_pv_table bug when CPU_ENDIAN_BE8
In-Reply-To: <20130725101442.GA5609@mudshark.cambridge.arm.com>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-4-git-send-email-ben.dooks@codethink.co.uk>
 <20130724143335.GL11072@mudshark.cambridge.arm.com>
 <51EFF1B2.4050609@codethink.co.uk>
 <20130725101442.GA5609@mudshark.cambridge.arm.com>
Message-ID: <51F0FC21.8050108@codethink.co.uk>

On 25/07/13 11:14, Will Deacon wrote:
> On Wed, Jul 24, 2013 at 04:24:34PM +0100, Ben Dooks wrote:
>> On 24/07/13 15:33, Will Deacon wrote:
>>> On Wed, Jul 24, 2013 at 11:27:51AM +0100, Ben Dooks wrote:
>>>> The fixup_pv_table assumes that the instructions are in the same
>>>> endian configuration as the data, but when the CPU is running in
>>>> BE8 the instructions stay in little-endian format.
>>>>
>>>> Make sure if CONFIG_CPU_ENDIAN_BE8 is set that we do all the
>>>> alterations to the instructions taking in to account the LDR/STR
>>>> will be swapping the data endian-ness.
>>>>
>>>> Since the code is only modifying a byte, we avoid dual-swapping
>>>> the data, and just change the bits we clear and ORR in (in the
>>>> case where the code is not thumb2).
>>>>
>>>> For thumb2, we add the necessary rev16 instructions to ensure that
>>>> the instructions are processed in the correct format, as it was
>>>> easier than re-writing the code to contain a mask and shift.
>>>>
>>>> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
>>>> ---
>>>>    arch/arm/kernel/head.S |    8 ++++++++
>>>>    1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
>>>> index 8bac553..e40c0b3b 100644
>>>> --- a/arch/arm/kernel/head.S
>>>> +++ b/arch/arm/kernel/head.S
>>>> @@ -584,8 +584,10 @@ __fixup_a_pv_table:
>>>>    	b	2f
>>>>    1:	add     r7, r3
>>>>    	ldrh	ip, [r7, #2]
>>>> +ARM_BE8(rev16	ip, ip)
>>>>    	and	ip, 0x8f00
>>>>    	orr	ip, r6	@ mask in offset bits 31-24
>>>> +ARM_BE8(rev16	ip, ip)
>>>
>>> I'm not sure I follow you when you say this is easier than a mask and a
>>> shift? As far as I can tell, it's two extra instructions and makes the LE
>>> and BE cases look different.
>>
>> I am not as familiar with THUMB2 as the ARM, so it was easier
>> to do this than see if there where any spare registers to hold the
>> mask and shift values, and use them.
>
> What's wrong with the following?
>
> Will
>
> --->8
>
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 9cf6063..ee660c2 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -581,8 +581,13 @@ __fixup_a_pv_table:
>          b       2f
>   1:     add     r7, r3
>          ldrh    ip, [r7, #2]
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +       and     ip, 0x008f
> +       orr     ip, ip, r6, lsl #24
> +#else
>          and     ip, 0x8f00
>          orr     ip, r6  @ mask in offset bits 31-24
> +#endif
>          strh    ip, [r7, #2]
>   2:     cmp     r4, r5
>          ldrcc   r7, [r4], #4    @ use branch for delay slot

If the offset bits are 8bits, then that would
be fine (apart from the lsl #8).

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From broonie at kernel.org  Thu Jul 25 06:24:53 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 25 Jul 2013 11:24:53 +0100
Subject: [PATCH 3/6] ASoC: usp-pcm: add CPU DAI driver for PCM simulated
 from USP
In-Reply-To: <CAGsJ_4xNdxFWyN6NUEL36W9n+4Cj=01+QGi+xaeODm9u8pdP9A@mail.gmail.com>
References: <1374232042-26088-1-git-send-email-Baohua.Song@csr.com>
 <1374232042-26088-4-git-send-email-Baohua.Song@csr.com>
 <20130719181313.GT9858@sirena.org.uk>
 <CAGsJ_4xNdxFWyN6NUEL36W9n+4Cj=01+QGi+xaeODm9u8pdP9A@mail.gmail.com>
Message-ID: <20130725102453.GZ9858@sirena.org.uk>

On Thu, Jul 25, 2013 at 05:32:12PM +0800, Barry Song wrote:
> 2013/7/20 Mark Brown <broonie at kernel.org>:

> > Also what exactly is the rate being set - can the driver just figure
> > this out automatically from the sample rate?

> here it is generating the right pcm clock by an internal DIVISOR in USP module.

> For USP_MODE2:
> 30:21 (R/W) USP_CLK_DIVISOR 10?h0 USP serial clock divider

> For USP_TX_FRAME_CTRL:
> 31:30 (R/W) USP_CLK_DIVISOR 2?h0 This is the two bit [11:10] of
> USP_CLK_DIVISOR in USP_MODE2

> for figuring this out automatically from the sample rate, do you mean
> a lookup table for common sample rate?

That or just calculating it - if you know the input rate and know the
output rate you need then for a simple divisor it should be possible to
calculate the required value.
-------------- 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/20130725/9d324ca6/attachment.sig>

From linux at arm.linux.org.uk  Thu Jul 25 06:25:41 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 25 Jul 2013 11:25:41 +0100
Subject: [PATCH 03/14] ARM: fixup_pv_table bug when CPU_ENDIAN_BE8
In-Reply-To: <20130725101442.GA5609@mudshark.cambridge.arm.com>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-4-git-send-email-ben.dooks@codethink.co.uk>
 <20130724143335.GL11072@mudshark.cambridge.arm.com>
 <51EFF1B2.4050609@codethink.co.uk>
 <20130725101442.GA5609@mudshark.cambridge.arm.com>
Message-ID: <20130725102541.GC24642@n2100.arm.linux.org.uk>

On Thu, Jul 25, 2013 at 11:14:42AM +0100, Will Deacon wrote:
> What's wrong with the following?

Is this like a challenge to find the silly mistake?

> @@ -581,8 +581,13 @@ __fixup_a_pv_table:
>         b       2f
>  1:     add     r7, r3
>         ldrh    ip, [r7, #2]
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +       and     ip, 0x008f
> +       orr     ip, ip, r6, lsl #24
> +#else
>         and     ip, 0x8f00
>         orr     ip, r6  @ mask in offset bits 31-24
> +#endif
>         strh    ip, [r7, #2]

Well, ip is being loaded/stored as 16bit, but you're putting r6 in to
ip's bits 31-24, which are going to be ignored by the following strh.

The comment "@ mask in offset bits 31-24" refers to the physical address
bits here, which are already pre-shifted to bits 7-0 in r6.


From f.fainelli at gmail.com  Thu Jul 25 06:26:41 2013
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 25 Jul 2013 11:26:41 +0100
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <2174304.5JlzJ583hP@avalon>
References: <Pine.LNX.4.44L0.1307231708020.1304-100000@iolanthe.rowland.org>
 <5977067.8rykRgjgre@flatron> <201307242032.03597.arnd@arndb.de>
 <2174304.5JlzJ583hP@avalon>
Message-ID: <CAGVrzcZqTNcu4Dxnr9p6JNBVzEBSBPuFSZLpiogDVX4zfw6kWw@mail.gmail.com>

2013/7/25 Laurent Pinchart <laurent.pinchart at ideasonboard.com>:
> Hi Arnd,
>
> On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote:
>> On Tuesday 23 July 2013, Tomasz Figa wrote:
>> > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
>> > > On Tue, 23 Jul 2013, Tomasz Figa wrote:
>> > > > Where would you want to have those phy_address arrays stored? There
>> > > > are no board files when booting with DT. Not even saying that you
>> > > > don't need to use any hacky schemes like this when you have DT that
>> > > > nicely specifies relations between devices.
>> > >
>> > > If everybody agrees DT has a nice scheme for specifying relations
>> > > between devices, why not use that same scheme in the PHY core?
>> >
>> > It is already used, for cases when consumer device has a DT node attached.
>> > In non-DT case this kind lookup translates loosely to something that is
>> > being done in regulator framework - you can't bind devices by pointers,
>> > because you don't have those pointers, so you need to use device names.
>>
>> Sorry for jumping in to the middle of the discussion, but why does a *new*
>> framework even bother defining an interface for board files?
>>
>> Can't we just drop any interfaces for platform data passing in the phy
>> framework and put the burden of adding those to anyone who actually needs
>> them? All the platforms we are concerned with here (exynos and omap, plus
>> new platforms) can be booted using DT anyway.
>
> What about non-DT architectures such as MIPS (still widely used in consumer
> networking equipments from what I've heard) ?

Is there any specific MIPS platform you are thinking about which could
benefit from this generic PHY framework? MIPS is also trying to make
DT the standard for passing such information now.

-- 
Florian


From mark.rutland at arm.com  Thu Jul 25 06:28:44 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 25 Jul 2013 11:28:44 +0100
Subject: [PATCH] arm: l2x0: add support for prefetch and pwr control
 register configuration
In-Reply-To: <51EE8183.9010703@gmail.com>
References: <1374572345-5763-1-git-send-email-chander.kashyap@linaro.org>
 <20130723102212.GD4833@e106331-lin.cambridge.arm.com>
 <51EE8183.9010703@gmail.com>
Message-ID: <20130725102844.GA29742@e106331-lin.cambridge.arm.com>

On Tue, Jul 23, 2013 at 02:13:39PM +0100, Rob Herring wrote:
> On 07/23/2013 05:22 AM, Mark Rutland wrote:
> > Hi,
> > 
> > [adding Rob Herring to Cc]
> 
> Thanks.
> 
> > On Tue, Jul 23, 2013 at 10:39:05AM +0100, Chander Kashyap wrote:
> >> This patch adds support to configure prefetch and pwr control registers
> >> of pl310 cache controllor.
> >>
> >> Signed-off-by: Chander Kashyap <chander.kashyap at linaro.org>
> >> ---
> >>  Documentation/devicetree/bindings/arm/l2cc.txt |    6 ++++
> >>  arch/arm/include/asm/hardware/cache-l2x0.h     |   23 +++++++++++++
> >>  arch/arm/mm/cache-l2x0.c                       |   44 ++++++++++++++++++++++++
> >>  3 files changed, 73 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
> >> index cbef09b..66876b6 100644
> >> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
> >> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
> >> @@ -34,6 +34,12 @@ Optional properties:
> >>  - arm,filter-ranges : <start length> Starting address and length of window to
> >>    filter. Addresses in the filter window are directed to the M1 port. Other
> >>    addresses will go to the M0 port.
> >> +- arm,prefetch-control : Prefetch related configurations. Specifies 8 cells of
> >> +  prefetch-offset, not-same-ID-on-exclusive-sequence-en, incr-double-Linefill-en,
> >> +  prefetch-drop-en, data-prefetch-en, instruction-prefetch-en and
> >> +  double-linefill-en.
> > 
> > This looks like configuration rather than hardware specification. 
> 
> I think weigh whether this is configuration based on the h/w or just
> user preference. This would be the former, but...
> 
> > Is there any reason we couldn't have Linux configure this itself? I'm
> > not sure having a fixed configuration of these values makes sense - the
> > configuration values could interact badly with future changes to Linux
> > (e.g. performance improvements or errata workarounds), and then we'd
> > have to ignore the described values and/or decide on more suitable ones
> > dynamically anyway.
> 
> Does having a variable configuration for these make sense either? I mean
> other than an errata work-around, why would you ever turn off prefetch
> or double linefill?

I guess not.

> 
> None of these fields can be set in NS world. We've already laid down the
> law in regards to setting secure only bits for errata work-arounds. I
> think this is no different and we should move towards the kernel doesn't
> touch aux ctrl at all. There might be an exception with the event bus
> enable, but you would still have the secure vs. non-secure issue and no
> way to detect that.

I would certainly be much happier if we didn't have to touch aux ctrl at
all in the kernel.

Thanks,
Mark.

> 
> Rob
> 
> > 
> > I assume that these cells are meant to either be zero or one? If they're
> > necessary, they should be separate boolean properties rather than
> > grouped together by the register they're configured by (see the way
> > arm,tag-latency and arm,data-latency are handled). 
> > 
> > Also, I'd prefer "-enable" to "-en".
> > 
> >> +- arm,pwr-control : Operting mode clock and power mode selection. Specifies two
> > 
> > s/Operting/Operating/
> > 
> > I'd prefer "power" to "pwr" (though there's precedent for both in
> > bindings...).
> > 
> >> +  cells of standby-mode-en and dynamic_clk_gating_en.
> > 
> > More boolean properties.
> > 
> >>  - interrupts : 1 combined interrupt.
> >>  - cache-id-part: cache id part number to be used if it is not present
> >>    on hardware
> > 
> > No amendments to the example?
> > 
> >> diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
> >> index 3b2c40b..188f4da 100644
> >> --- a/arch/arm/include/asm/hardware/cache-l2x0.h
> >> +++ b/arch/arm/include/asm/hardware/cache-l2x0.h
> >> @@ -106,6 +106,29 @@
> >>  
> >>  #define L2X0_WAY_SIZE_SHIFT		3
> >>  
> >> +#define L2X0_PREFETCH_CTRL_OFFSET_SHIFT			0
> >> +#define L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT		21
> >> +#define L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT	23
> >> +#define L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT		24
> >> +#define L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT	27
> >> +#define L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT	28
> >> +#define L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT	29
> >> +#define L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT	30
> >> +
> >> +#define PREFETCH_R2P0_MASK	(~(1 << L2X0_PREFETCH_CTRL_OFFSET_SHIFT))
> >> +#define PREFETCH_R3P0_MASK \
> >> +		(~((1 << L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT) | \
> >> +		   (1 << L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT) | \
> >> +		   (1 << L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT) | \
> >> +		   (1 << L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT) | \
> >> +		   (1 << L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT) | \
> >> +		   (1 << L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT)))
> >> +#define PREFETCH_R3P1_MASK \
> >> +		(~(1 << L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT))
> >> +
> >> +#define L2X0_PWR_CTRL_STANDBY_MODE_EN_SHIFT	0
> >> +#define L2X0_PWR_CTRL_DYNAMIC_CLK_GATE_EN_SHIFT	1
> >> +
> >>  #ifndef __ASSEMBLY__
> >>  extern void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask);
> >>  #if defined(CONFIG_CACHE_L2X0) && defined(CONFIG_OF)
> >> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> >> index c465fac..490e182 100644
> >> --- a/arch/arm/mm/cache-l2x0.c
> >> +++ b/arch/arm/mm/cache-l2x0.c
> >> @@ -563,6 +563,11 @@ static void __init pl310_of_setup(const struct device_node *np,
> >>  	u32 data[3] = { 0, 0, 0 };
> >>  	u32 tag[3] = { 0, 0, 0 };
> >>  	u32 filter[2] = { 0, 0 };
> >> +	u32 prefetch[8] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> >> +	u32 prefetch_val;
> >> +	u32 pwr[2] = { 0, 0 };
> >> +	u32 l2x0_revision = readl_relaxed(l2x0_base + L2X0_CACHE_ID) &
> >> +		L2X0_CACHE_ID_RTL_MASK;
> >>  
> >>  	of_property_read_u32_array(np, "arm,tag-latency", tag, ARRAY_SIZE(tag));
> >>  	if (tag[0] && tag[1] && tag[2])
> >> @@ -589,6 +594,45 @@ static void __init pl310_of_setup(const struct device_node *np,
> >>  		writel_relaxed((filter[0] & ~(SZ_1M - 1)) | L2X0_ADDR_FILTER_EN,
> >>  			       l2x0_base + L2X0_ADDR_FILTER_START);
> >>  	}
> >> +
> >> +	if (l2x0_revision >= L2X0_CACHE_ID_RTL_R2P0) {
> > 
> > You didn't describe that some properties were dependent on a particular
> > revision.
> > 
> >> +		of_property_read_u32_array(np, "arm,prefetch-control",
> >> +						prefetch, ARRAY_SIZE(prefetch));
> >> +		prefetch_val = readl_relaxed(l2x0_base + L2X0_PREFETCH_CTRL);
> >> +		prefetch_val &= PREFETCH_R2P0_MASK;
> >> +		prefetch_val |= prefetch[0] << L2X0_PREFETCH_CTRL_OFFSET_SHIFT;
> >> +		if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P0) {
> >> +			prefetch_val &= PREFETCH_R3P0_MASK;
> >> +			prefetch_val |=
> >> +			 ((prefetch[1]) <<
> >> +			   L2X0_PREFETCH_CTRL_NOT_SAME_ID_SHIFT) |
> >> +			 ((prefetch[2]) <<
> >> +			   L2X0_PREFETCH_CTRL_INC_DOUBLE_LINEFILL_SHIFT) |
> >> +			 ((prefetch[3]) <<
> >> +			   L2X0_PREFETCH_CTRL_PREFETCH_DROP_SHIFT) |
> >> +			 ((prefetch[5]) <<
> >> +			   L2X0_PREFETCH_CTRL_DATA_PREFETCH_EN_SHIFT) |
> >> +			 ((prefetch[6]) <<
> >> +			   L2X0_PREFETCH_CTRL_INSTR_PREFETCH_EN_SHIFT) |
> >> +			 ((prefetch[7]) <<
> >> +			   L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_EN_SHIFT);
> > 
> > You've not sanity checked these properties. What If I typo a value as
> > something other than 0 or 1?
> > 
> > Use boolean properties and of_property_read_bool (or even better,
> > configure this dynamically based on revision rather than having a dt
> > description).
> > 
> >> +			if (l2x0_revision >= L2X0_CACHE_ID_RTL_R3P1) {
> >> +				prefetch_val &= PREFETCH_R3P1_MASK;
> >> +				prefetch_val |=
> >> +				 ((prefetch[4]) <<
> >> +				   L2X0_PREFETCH_CTRL_DOUBLE_LINEFILL_WR_SHIFT);
> >> +			}
> > 
> > Another undocumented revision dependency.
> > 
> >> +			writel_relaxed(prefetch_val,
> >> +					l2x0_base + L2X0_PREFETCH_CTRL);
> >> +
> >> +			of_property_read_u32_array(np, "arm,pwr-control",
> >> +						pwr, ARRAY_SIZE(pwr));
> >> +			writel_relaxed(
> >> +			 ((pwr[0]) << L2X0_PWR_CTRL_STANDBY_MODE_EN_SHIFT) |
> >> +			 ((pwr[1]) << L2X0_PWR_CTRL_DYNAMIC_CLK_GATE_EN_SHIFT),
> >> +			   l2x0_base + L2X0_POWER_CTRL);
> > 
> > Again, use boolean properties or do this dynamically.
> > 
> > Do none of these values need to be saved for the resume callback?
> > 
> > Thanks,
> > Mark.
> > 
> >> +		}
> >> +	}
> >>  }
> >>  
> >>  static void __init pl310_save(void)
> >> -- 
> >> 1.7.9.5
> >>
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >>
> 
> 


From will.deacon at arm.com  Thu Jul 25 06:30:40 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 11:30:40 +0100
Subject: [PATCH 03/14] ARM: fixup_pv_table bug when CPU_ENDIAN_BE8
In-Reply-To: <51F0FC21.8050108@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-4-git-send-email-ben.dooks@codethink.co.uk>
 <20130724143335.GL11072@mudshark.cambridge.arm.com>
 <51EFF1B2.4050609@codethink.co.uk>
 <20130725101442.GA5609@mudshark.cambridge.arm.com>
 <51F0FC21.8050108@codethink.co.uk>
Message-ID: <20130725103039.GC5609@mudshark.cambridge.arm.com>

On Thu, Jul 25, 2013 at 11:21:21AM +0100, Ben Dooks wrote:
> On 25/07/13 11:14, Will Deacon wrote:
> > What's wrong with the following?
> >
> > --->8
> >
> > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> > index 9cf6063..ee660c2 100644
> > --- a/arch/arm/kernel/head.S
> > +++ b/arch/arm/kernel/head.S
> > @@ -581,8 +581,13 @@ __fixup_a_pv_table:
> >          b       2f
> >   1:     add     r7, r3
> >          ldrh    ip, [r7, #2]
> > +#ifdef CONFIG_CPU_ENDIAN_BE8
> > +       and     ip, 0x008f
> > +       orr     ip, ip, r6, lsl #24
> > +#else
> >          and     ip, 0x8f00
> >          orr     ip, r6  @ mask in offset bits 31-24
> > +#endif
> >          strh    ip, [r7, #2]
> >   2:     cmp     r4, r5
> >          ldrcc   r7, [r4], #4    @ use branch for delay slot
> 
> If the offset bits are 8bits, then that would
> be fine (apart from the lsl #8).

Ah yes, I see the problem now. Maybe it's easier to rev r6 for the
big-endian case and leave the orr alone.

Will


From ben.dooks at codethink.co.uk  Thu Jul 25 06:34:38 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 11:34:38 +0100
Subject: [PATCH 03/14] ARM: fixup_pv_table bug when CPU_ENDIAN_BE8
In-Reply-To: <20130725102541.GC24642@n2100.arm.linux.org.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-4-git-send-email-ben.dooks@codethink.co.uk>
 <20130724143335.GL11072@mudshark.cambridge.arm.com>
 <51EFF1B2.4050609@codethink.co.uk>
 <20130725101442.GA5609@mudshark.cambridge.arm.com>
 <20130725102541.GC24642@n2100.arm.linux.org.uk>
Message-ID: <51F0FF3E.3050206@codethink.co.uk>

On 25/07/13 11:25, Russell King - ARM Linux wrote:
> On Thu, Jul 25, 2013 at 11:14:42AM +0100, Will Deacon wrote:
>> What's wrong with the following?
>
> Is this like a challenge to find the silly mistake?
>
>> @@ -581,8 +581,13 @@ __fixup_a_pv_table:
>>          b       2f
>>   1:     add     r7, r3
>>          ldrh    ip, [r7, #2]
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +       and     ip, 0x008f
>> +       orr     ip, ip, r6, lsl #24
>> +#else
>>          and     ip, 0x8f00
>>          orr     ip, r6  @ mask in offset bits 31-24
>> +#endif
>>          strh    ip, [r7, #2]
>
> Well, ip is being loaded/stored as 16bit, but you're putting r6 in to
> ip's bits 31-24, which are going to be ignored by the following strh.
>
> The comment "@ mask in offset bits 31-24" refers to the physical address
> bits here, which are already pre-shifted to bits 7-0 in r6.

I looked into this, and the code before this loop does:

	clz	r7, r6
	lsr	r6, #24
	lsl	r6, r7
	bic	r6, #0x0080
	lsrs	r7, #1
	orrcs	r6, #0x0080
	orr	r6, r6, r7, lsl #12
	orr	r6, #0x4000
	b	2f

Note that r6 has bits that are not in the 0..7 range, which makes life
difficult when dealing with the loop. If we are going to change the
loop then we will have to pre rev16 r6 before going in to it.

IE:

	lsls	r6, #24
	beq	2f
	clz	r7, r6
	lsr	r6, #24
	lsl	r6, r7
	bic	r6, #0x0080
	lsrs	r7, #1
	orrcs	r6, #0x0080
	orr	r6, r6, r7, lsl #12
	orr	r6, #0x4000
  ARM_BE8(rev16	r6, r6)
	b	2f
1:	add     r7, r3
	ldrh	ip, [r7, #2]
#ifdef CONFIG_CPU_ENDIAN_BE8
	and	ip, 0x008f
#else
	and	ip, 0x8f00
#endif
	orr	ip, r6	@ mask in offset bits 31-24
	strh	ip, [r7, #2]
2:	cmp	r4, r5
	ldrcc	r7, [r4], #4	@ use branch for delay slot
	bcc	1b
	bx	lr




-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From james.hogan at imgtec.com  Thu Jul 25 05:07:52 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Thu, 25 Jul 2013 10:07:52 +0100
Subject: [PATCH v5 0/5] clk: implement remuxing during set_rate
In-Reply-To: <20130724183912.GC27761@codeaurora.org>
References: <1371139562-305-1-git-send-email-james.hogan@imgtec.com>
 <20130621170407.20448.35605@quantum>
 <CAAG0J9-F0P67=oaE5UHhmgd3Wz4k4XjsRjWShxmKOqicAyrhfw@mail.gmail.com>
 <20130724183912.GC27761@codeaurora.org>
Message-ID: <51F0EAE8.90303@imgtec.com>

On 24/07/13 19:39, Stephen Boyd wrote:
> On 06/21, James Hogan wrote:
>> On 21 June 2013 18:04, Mike Turquette <mturquette at linaro.org> wrote:
>>> Quoting James Hogan (2013-06-13 09:05:57)
>>>> This patchset adds support for automatic selection of the best parent
>>>> for a clock mux, i.e. the one which can provide the closest clock rate
>>>> to that requested. It can be disabled by a new CLK_SET_RATE_NO_REPARENT
>>>> flag (which is set for all uses of clk_register_mux().
>>>>
>>>> This works by way of adding a new op, determine_rate, similar to
>>>> round_rate but with an extra parameter to allow the clock driver to
>>>> optionally select a different parent clock. This is used in
>>>> clk_calc_new_rates to decide whether to initiate a set_parent operation.
>>>
>>> Hi James,
>>>
>>> I'm going to hold off on this one for 3.11. I'll revisit it after the
>>> next merge window.
>>
>> Okay, no worries.
>>
> 
> Has a new patchset been sent out? I'd like to see this merge in
> 3.12.

Not yet, but I'll try and get it updated and resent early next week.

Cheers
James



From will.deacon at arm.com  Thu Jul 25 06:40:44 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 11:40:44 +0100
Subject: [PATCH 03/14] ARM: fixup_pv_table bug when CPU_ENDIAN_BE8
In-Reply-To: <20130725102541.GC24642@n2100.arm.linux.org.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374661682-9349-4-git-send-email-ben.dooks@codethink.co.uk>
 <20130724143335.GL11072@mudshark.cambridge.arm.com>
 <51EFF1B2.4050609@codethink.co.uk>
 <20130725101442.GA5609@mudshark.cambridge.arm.com>
 <20130725102541.GC24642@n2100.arm.linux.org.uk>
Message-ID: <20130725104044.GD5609@mudshark.cambridge.arm.com>

On Thu, Jul 25, 2013 at 11:25:41AM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 25, 2013 at 11:14:42AM +0100, Will Deacon wrote:
> > What's wrong with the following?
> 
> Is this like a challenge to find the silly mistake?

Unfortunately, yes. I'm half asleep this morning...

> > @@ -581,8 +581,13 @@ __fixup_a_pv_table:
> >         b       2f
> >  1:     add     r7, r3
> >         ldrh    ip, [r7, #2]
> > +#ifdef CONFIG_CPU_ENDIAN_BE8
> > +       and     ip, 0x008f
> > +       orr     ip, ip, r6, lsl #24

That was supposed to be lsl #8 (I blindly copied from Ben's correct ARM
hunk), but I think that it's still broken with that change.

> > +#else
> >         and     ip, 0x8f00
> >         orr     ip, r6  @ mask in offset bits 31-24
> > +#endif
> >         strh    ip, [r7, #2]
> 
> Well, ip is being loaded/stored as 16bit, but you're putting r6 in to
> ip's bits 31-24, which are going to be ignored by the following strh.
> 
> The comment "@ mask in offset bits 31-24" refers to the physical address
> bits here, which are already pre-shifted to bits 7-0 in r6.

Yup. It's bits 15-8 that make life slightly fiddly.

Will


From maxime.ripard at free-electrons.com  Thu Jul 25 06:41:16 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Jul 2013 12:41:16 +0200
Subject: [PATCH] pinctrl: sunxi: Fix gpio_set behaviour
Message-ID: <1374748876-23461-1-git-send-email-maxime.ripard@free-electrons.com>

The current gpio_set function is ignoring the previous value set in the
GPIO value register, which leads in erasing the values already set for
the other GPIOs in the same bank when setting the value of a given GPIO.

Add the usual read/mask/write pattern to fix this brown paper bag bug.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/pinctrl/pinctrl-sunxi.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
index fc058b6..4f8bb18 100644
--- a/drivers/pinctrl/pinctrl-sunxi.c
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -464,8 +464,14 @@ static void sunxi_pinctrl_gpio_set(struct gpio_chip *chip,
 	struct sunxi_pinctrl *pctl = dev_get_drvdata(chip->dev);
 	u32 reg = sunxi_data_reg(offset);
 	u8 index = sunxi_data_offset(offset);
+	u32 regval = readl(pctl->membase + reg);
 
-	writel((value & DATA_PINS_MASK) << index, pctl->membase + reg);
+	if (value)
+		regval |= BIT(index);
+	else
+		regval &= ~(BIT(index));
+
+	writel(regval, pctl->membase + reg);
 }
 
 static int sunxi_pinctrl_gpio_of_xlate(struct gpio_chip *gc,
-- 
1.8.3.2



From Dave.Martin at arm.com  Thu Jul 25 06:55:34 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Thu, 25 Jul 2013 11:55:34 +0100
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value to
 index into save array
In-Reply-To: <alpine.LFD.2.03.1307241437460.15022@syhkavp.arg>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-2-git-send-email-nicolas.pitre@linaro.org>
 <20130724164717.GA4610@localhost.localdomain>
 <alpine.LFD.2.03.1307241437460.15022@syhkavp.arg>
Message-ID: <20130725105528.GA2546@localhost.localdomain>

On Wed, Jul 24, 2013 at 02:55:00PM -0400, Nicolas Pitre wrote:
> On Wed, 24 Jul 2013, Dave Martin wrote:
> 
> > On Mon, Jul 22, 2013 at 11:31:17PM -0400, Nicolas Pitre wrote:
> > > Currently we hash the MPIDR of the CPU being suspended to determine which
> > > entry in the sleep_save_sp array to use. In some situations, such as when
> > > we want to resume on another physical CPU, the MPIDR of another CPU should
> > > be used instead.
> > > 
> > > So let's use the value of cpu_logical_map(smp_processor_id()) in place
> > > of the MPIDR in the suspend path.  This will result in the same index
> > > being used as with the previous code unless the caller has modified
> > > cpu_logical_map() beforehand.
> > 
> > This only works because we happen to swap MPIDRs in cpu_logical_map
> > before we get here, so that cpu_logical_map(smp_processor_id())
> > described the post-resume situation for this logical CPU, not the
> > current situation.
> 
> Yes, that's more or less what I said above.  Maybe that should be 
> clarified further?
> 
> > We have to swizzle cpu_logical_map() somewhere, and the suspend path is
> > just as good as the resume path for that.
> 
> Not quite.  On the resume path, we have to get to the context save array 
> while having no mmu active and no stack.  There is no way we could take 
> over another CPU's context in those conditions without making it 
> extremely painful on ourselves.  It is therefore way easier to swizzle 
> cpu_logical_map() on the suspend path and keep the suspend/resume logic 
> unmodified.

For this implementation, that's correct, and it's a perfectly good way
of doing things.

My point is that the user of cpu_resume() does not necessarily realise
the nature of this dependency.

> > But this patch commits us to requiring that on the suspend path 
> > specifically -- I think that ought to be mentioned somewhere. A 
> > comment in the preamble for __cpu_suspend would be enough, I think.
> 
> What comment would you suggest?  I want to make sure the possible 
> confusion you see is properly addressed.

I think we just need to state that the value of
cpu_logical_map(smp_processor_id()) must be the MPIDR of the physical
CPU the suspending logical CPU will resume on.  Consequently, if doing a
migration, cpu_logical_map() must be updated appropriately somewhere
between cpu_pm_enter() and cpu_suspend().


This also means that the choice of destination CPU can't be made
dynamically at resume time.  But I'm not sure that's useful or even
makes sense, so I'm not worrying about it.

> > Looks like the patch should work though, and it does remove the need to
> > read the MPIDR, which is slightly nicer for the non-switcher case.
> 
> This patch works fine here, and I'd expect rather catastrophic results 
> if it didn't.  ;-)

Sure, I'm not doubting that the code works.

Cheers
---Dave


From p.zabel at pengutronix.de  Thu Jul 25 07:00:34 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 25 Jul 2013 13:00:34 +0200
Subject: [PATCH 1/2] ARM i.MX6Q: dts: Enable SPI NOR flash on Phytec
 phyFLEX-i.MX6 Ouad module
In-Reply-To: <20130725023605.GA7492@S2101-09.ap.freescale.net>
References: <1374683729-13438-1-git-send-email-p.zabel@pengutronix.de>
 <51F01DF0.3030207@cogentembedded.com>
 <20130725023605.GA7492@S2101-09.ap.freescale.net>
Message-ID: <1374750034.4297.29.camel@pizza.hi.pengutronix.de>

Am Donnerstag, den 25.07.2013, 10:36 +0800 schrieb Shawn Guo:
> On Wed, Jul 24, 2013 at 10:33:20PM +0400, Sergei Shtylyov wrote:
> > Hello.
> > 
> > On 07/24/2013 08:35 PM, Philipp Zabel wrote:
> > 
> > >Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> > >---
> > >  arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 15 +++++++++++++++
> > >  1 file changed, 15 insertions(+)
> > 
> > >diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
> > >index f5e1981..5113d29 100644
> > >--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
> > >+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
> > >@@ -20,6 +20,20 @@
> > >  	};
> > >  };
> > >
> > >+&ecspi3 {
> > >+	pinctrl-names = "default";
> > >+	pinctrl-0 = <&pinctrl_ecspi3_1>;
> > >+	status = "okay";
> > >+	fsl,spi-num-chipselects = <1>;
> > >+	cs-gpios = <&gpio4 24 0>;
> > >+
> > >+	flash: m25p80 at 0 {
> > 
> >    Quoting the EPAPR spec [1]: "The name of a node should be
> > somewhat generic, reflecting the function of the device and not its
> > precise programming model. If appropriate, the name should be one of
> > the following choices:
> > [...]
> >    - flash
> 
> I fixed it up and applied the series.

thanks
Philipp



From jett.zhou at gmail.com  Thu Jul 25 07:02:45 2013
From: jett.zhou at gmail.com (jett zhou)
Date: Thu, 25 Jul 2013 19:02:45 +0800
Subject: [V3 0/7] Enhance mmp display driver
In-Reply-To: <CACDDiy8OwYHbmYGwc0FV2NLVfu1BiUL9GYCmA2QEVVB5isFJGQ@mail.gmail.com>
References: <1372332473-6584-1-git-send-email-jtzhou@marvell.com>
 <20130709133918.GC18477@ns203013.ovh.net>
 <CACDDiy8OwYHbmYGwc0FV2NLVfu1BiUL9GYCmA2QEVVB5isFJGQ@mail.gmail.com>
Message-ID: <CACDDiy8wkW95zHCrzEP5u09DYbC2=PQGmb-6bjMsZCs8OmqNsw@mail.gmail.com>

Hi Jean
      Does apply patch1~patch3 and patch6~patch7 have issue on your side? :)
Thanks

2013/7/14 jett zhou <jett.zhou at gmail.com>:
> Hi Jean
>      As I checked the for-next branch, found patch4 and patch5 are
> already applied.
>      As checked on my side,  only apply patch1~patch3 and
> patch6~patch7 is ok, so think you can apply them except for patch4/5.
>      If there is still problem, please let me know, I will check it then.
> Thanks
>
> 2013/7/9 Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>:
>> HI,
>>
>>         please rebase on the for-next branch as it does not apply
>>
>> Best Regards,
>> J.
>> On 19:27 Thu 27 Jun     , Jett.Zhou wrote:
>>> Changelog:
>>> 1 Add more comments for the mmp_display rbswap usage
>>> according to Daniel's comments;
>>> 2 Add fix patch for ttc_dkb on rbswap;
>>> 3 Add more comments on the pitch usage and definition;
>>> 4 Combine the modification on pitch of graphic and video layer
>>> in one patch.
>>>
>>> Guoqing Li (2):
>>>   video: mmp: rb swap setting update for mmp display
>>>   video: mmp: optimize some register setting code
>>>
>>> Jett.Zhou (1):
>>>   ARM: mmp: remove the legacy rbswap setting for ttc_dkb platform
>>>
>>> Jing Xiang (4):
>>>   video: mmp: fix graphics/video layer enable/mask issue
>>>   video: mmp: fix memcpy wrong size for mmp_addr issue
>>>   video: mmp: calculate pitch value when fb set win
>>>   video: mmp: add pitch info in mmp_win structure
>>>
>>>  arch/arm/mach-mmp/ttc_dkb.c     |    4 +-
>>>  drivers/video/mmp/fb/mmpfb.c    |   34 +++++++++++------
>>>  drivers/video/mmp/hw/mmp_ctrl.c |   79 ++++++++++++++++++++++-----------------
>>>  drivers/video/mmp/hw/mmp_ctrl.h |    5 ++
>>>  include/video/mmp_disp.h        |    6 +++
>>>  5 files changed, 79 insertions(+), 49 deletions(-)
>>>
>
>
>
> --
>
> ----------------------------------
> Best Regards
> Jett Zhou



-- 

----------------------------------
Best Regards
Jett Zhou


From arnd at arndb.de  Thu Jul 25 07:00:49 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Jul 2013 13:00:49 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <2174304.5JlzJ583hP@avalon>
References: <Pine.LNX.4.44L0.1307231708020.1304-100000@iolanthe.rowland.org>
 <201307242032.03597.arnd@arndb.de> <2174304.5JlzJ583hP@avalon>
Message-ID: <201307251300.49282.arnd@arndb.de>

On Thursday 25 July 2013, Laurent Pinchart wrote:
> On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote:
> > On Tuesday 23 July 2013, Tomasz Figa wrote:
> > > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
> > > > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > > > > Where would you want to have those phy_address arrays stored? There
> > > > > are no board files when booting with DT. Not even saying that you
> > > > > don't need to use any hacky schemes like this when you have DT that
> > > > > nicely specifies relations between devices.
> > > > 
> > > > If everybody agrees DT has a nice scheme for specifying relations
> > > > between devices, why not use that same scheme in the PHY core?
> > > 
> > > It is already used, for cases when consumer device has a DT node attached.
> > > In non-DT case this kind lookup translates loosely to something that is
> > > being done in regulator framework - you can't bind devices by pointers,
> > > because you don't have those pointers, so you need to use device names.
> > 
> > Sorry for jumping in to the middle of the discussion, but why does a new
> > framework even bother defining an interface for board files?
> > 
> > Can't we just drop any interfaces for platform data passing in the phy
> > framework and put the burden of adding those to anyone who actually needs
> > them? All the platforms we are concerned with here (exynos and omap, plus
> > new platforms) can be booted using DT anyway.
> 
> What about non-DT architectures such as MIPS (still widely used in consumer 
> networking equipments from what I've heard) ?

* Vendors of such equipment have started moving on to ARM (e.g. Broadcom bcm47xx)
* Some of the modern MIPS platforms are now using DT
* Legacy platforms probably won't migrate to either DT or the generic PHY framework

I'm not saying that we can't support legacy board files with the common
PHY framework, but I'd expect things to be much easier if we focus on those
platforms that are actively being worked on for now, to bring an end to the
pointless API discussion.

	Arnd


From Dave.Martin at arm.com  Thu Jul 25 07:06:34 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Thu, 25 Jul 2013 12:06:34 +0100
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
Message-ID: <20130725110634.GB2546@localhost.localdomain>

On Wed, Jul 24, 2013 at 08:27:13AM -0700, Olof Johansson wrote:
> Every now and then I come across a binding that's just done Wrong(tm),
> merged through a submaintainer tree and hasn't seen proper review --
> if it had, it wouldn't look the way it does. It's something we're
> starting to address now since there's more people stepping up to be
> maintainers, but there's a backlog of bad bindings already merged.
> 
> Often they are produced by translating the platform_data structures
> directly over into device-tree properties without consideration to
> describing the hardware or usual conventions, using key/value pairs
> instead of boolean properties, etc.
> 
> Getting involved in cleaning up these kind of bindings is a great way
> to learn "the ways of device tree" for someone that has interest in
> that.
> 
> Latest find in this area is the Maxim 8925 bindings, that I came
> across since they caused a compile warning on some defconfig. I'll
> post a patch to address the warning but if someone else feels like
> fixing the bindings on top of it that would be appreciated!

DT bindings (even poorly conceived, ad-hoc and/or undocumented ones)
are ABI.

A review/merge process which _allows_ junk into an ABI is the real
problem we need to solve here, but once it's there we can't just magic
it away.

Do we plan on having a proper deprecation path for the junk, so that
the old, superseded bindings continue to work for a limited time,
preferably with a big fat warning somewhere?

Cheers
---Dave


From laurent.pinchart at ideasonboard.com  Thu Jul 25 07:10:10 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 25 Jul 2013 13:10:10 +0200
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <201307251300.49282.arnd@arndb.de>
References: <Pine.LNX.4.44L0.1307231708020.1304-100000@iolanthe.rowland.org>
 <2174304.5JlzJ583hP@avalon> <201307251300.49282.arnd@arndb.de>
Message-ID: <59774273.TEcrXvCTgs@avalon>

Hi Arnd,
On Thursday 25 July 2013 13:00:49 Arnd Bergmann wrote:
> On Thursday 25 July 2013, Laurent Pinchart wrote:
> > On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote:
> > > On Tuesday 23 July 2013, Tomasz Figa wrote:
> > > > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
> > > > > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > > > > > Where would you want to have those phy_address arrays stored?
> > > > > > There are no board files when booting with DT. Not even saying
> > > > > > that you don't need to use any hacky schemes like this when you
> > > > > > have DT that nicely specifies relations between devices.
> > > > > 
> > > > > If everybody agrees DT has a nice scheme for specifying relations
> > > > > between devices, why not use that same scheme in the PHY core?
> > > > 
> > > > It is already used, for cases when consumer device has a DT node
> > > > attached. In non-DT case this kind lookup translates loosely to
> > > > something that is being done in regulator framework - you can't bind
> > > > devices by pointers, because you don't have those pointers, so you
> > > > need to use device names.
> > > 
> > > Sorry for jumping in to the middle of the discussion, but why does a new
> > > framework even bother defining an interface for board files?
> > > 
> > > Can't we just drop any interfaces for platform data passing in the phy
> > > framework and put the burden of adding those to anyone who actually
> > > needs them? All the platforms we are concerned with here (exynos and
> > > omap, plus new platforms) can be booted using DT anyway.
> > 
> > What about non-DT architectures such as MIPS (still widely used in
> > consumer networking equipments from what I've heard) ?
> 
> * Vendors of such equipment have started moving on to ARM (e.g. Broadcom
> bcm47xx)
> * Some of the modern MIPS platforms are now using DT
> * Legacy platforms probably won't migrate to either DT or the generic PHY
> framework
> 
> I'm not saying that we can't support legacy board files with the common PHY
> framework, but I'd expect things to be much easier if we focus on those
> platforms that are actively being worked on for now, to bring an end to the
> pointless API discussion.

Fair enough :-)

-- 
Regards,

Laurent Pinchart



From sergei.shtylyov at cogentembedded.com  Thu Jul 25 11:14:16 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 25 Jul 2013 19:14:16 +0400
Subject: [PATCH v2 1/3] ARM: shmobile: marzen: Switch to DT_MACHINE_START
In-Reply-To: <1374718423-24230-2-git-send-email-horms+renesas@verge.net.au>
References: <1374718423-24230-1-git-send-email-horms+renesas@verge.net.au>
 <1374718423-24230-2-git-send-email-horms+renesas@verge.net.au>
Message-ID: <51F140C8.8070802@cogentembedded.com>

Hello.

On 25-07-2013 6:13, Simon Horman wrote:

> From: Magnus Damm <damm at opensource.se>

    Don't think it makes sense to keep Magnus as an author with so many of 
your added changes. But well, it's your decision...

> Convert the marzen board to use DT_MACHINE_START. With this in
> place all mach-shmobile boards use DT_MACHINE_START. Also, this
> makes it possible for the r8a7779 SMP code to use DT for CPUs.

> So appended DTB is the way forward on this board.

> Signed-off-by: Magnus Damm <damm at opensource.se>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

> v2 [Simon Horman]
> * Select USE_OF in Kconfig
> * Provide dt_compat in DT_MACHINE_START
> * Provide r8a7779-marzen dts

> v1 [Magnus Damm]
> ---
>   arch/arm/boot/dts/Makefile            |  1 +
>   arch/arm/boot/dts/r8a7779-marzen.dts  | 27 +++++++++++++++++++++++++++

    Perhaps arch/arm/boot/dts/ changes should be put into a separate patch?

WBR, Sergei



From lorenzo.pieralisi at arm.com  Thu Jul 25 07:14:25 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 25 Jul 2013 12:14:25 +0100
Subject: [RFC PATCH 2/3] ARM: vexpress: tc2: disable GIC CPU IF in
 tc2_pm_suspend
In-Reply-To: <1374750866-750-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1374750866-750-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1374750866-750-3-git-send-email-lorenzo.pieralisi@arm.com>

To prevent cores from exiting wfi when they are about to be shut down
the GIC CPU IF must be disabled so that the GIC CPU IF IRQ output line
is not asserted to the cores. wfi completion must be prevented since,
in absence of coordinating HW logic, if the power controller receives
a standbywfi signal but in the meantime the processor restarts executing
owing to a pending IRQ, the core might be reset when running in a
non-quiescent state (eg with pending load/store transactions)

Raw GIC distributor IRQ signals are routed to the power controller, that
is capable of taking core out of reset on pending IRQs even if their GIC
CPU IF is disabled, thus keeping the normal wfi behaviour.

GIC CPU IF is restored upon CPU wake-up by the respective MCPM API
consumers (ie CPU idle driver and suspend to RAM thread).

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm/mach-vexpress/tc2_pm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-vexpress/tc2_pm.c b/arch/arm/mach-vexpress/tc2_pm.c
index dfb55d4..3303ac6 100644
--- a/arch/arm/mach-vexpress/tc2_pm.c
+++ b/arch/arm/mach-vexpress/tc2_pm.c
@@ -16,6 +16,7 @@
 #include <linux/kernel.h>
 #include <linux/spinlock.h>
 #include <linux/errno.h>
+#include <linux/irqchip/arm-gic.h>
 
 #include <asm/mcpm.h>
 #include <asm/proc-fns.h>
@@ -211,6 +212,7 @@ static void tc2_pm_suspend(u64 residency)
 	cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
 	cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
 	ve_spc_set_resume_addr(cluster, cpu, virt_to_phys(mcpm_entry_point));
+	gic_cpu_if_down();
 	tc2_pm_down(residency);
 }
 
-- 
1.8.2.2




From lorenzo.pieralisi at arm.com  Thu Jul 25 07:14:24 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 25 Jul 2013 12:14:24 +0100
Subject: [RFC PATCH 1/3] drivers: irq-chip: irq-gic: introduce
 gic_cpu_if_down()
In-Reply-To: <1374750866-750-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1374750866-750-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1374750866-750-2-git-send-email-lorenzo.pieralisi@arm.com>

From: Nicolas Pitre <nicolas.pitre at linaro.org>

When processors are about to hit low power states, the assertion of
standbywfi signal, triggered by the wfi instruction, is essential to
entering low power modes. If an IRQ is pending on the processor at the
time wfi is issued, the wfi instruction completes and the processor
restarts execution without asserting the standbywfi signal. Depending
on the platform power controller HW this behaviour can be acceptable or
not; if this behaviour must be prevented software should be provided
with a way to disable the routing of interrupts to the core IRQ pins.

On systems where raw GIC distributor interrupts are connected to the power
controller as wake-up events (hence the power controller still senses
IRQs and can wake up cores upon IRQ pending), the GIC CPU interface can
be disabled on power down, so that the GIC CPU IF output is gated and wfi
cannot complete, thereby preventing the standbywfi issue.

This patch adds a simple function to the GIC driver that allows to
disable the GIC CPU IF from power down procedures.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
[rewrote commit log]
---
 drivers/irqchip/irq-gic.c       | 6 ++++++
 include/linux/irqchip/arm-gic.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index ee7c503..d0e9480 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -453,6 +453,12 @@ static void gic_cpu_init(struct gic_chip_data *gic)
 	writel_relaxed(1, base + GIC_CPU_CTRL);
 }
 
+void gic_cpu_if_down(void)
+{
+	void __iomem *cpu_base = gic_data_cpu_base(&gic_data[0]);
+	writel_relaxed(0, cpu_base + GIC_CPU_CTRL);
+}
+
 #ifdef CONFIG_CPU_PM
 /*
  * Saves the GIC distributor registers during suspend or idle.  Must be called
diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 3e203eb..0e5d9ec 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -66,6 +66,7 @@ extern struct irq_chip gic_arch_extn;
 void gic_init_bases(unsigned int, int, void __iomem *, void __iomem *,
 		    u32 offset, struct device_node *);
 void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
+void gic_cpu_if_down(void);
 
 static inline void gic_init(unsigned int nr, int start,
 			    void __iomem *dist , void __iomem *cpu)
-- 
1.8.2.2




From lorenzo.pieralisi at arm.com  Thu Jul 25 07:14:23 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 25 Jul 2013 12:14:23 +0100
Subject: [RFC PATCH 0/3] ARM: TC2 big.LITTLE CPU idle driver
Message-ID: <1374750866-750-1-git-send-email-lorenzo.pieralisi@arm.com>

This patch series provides the implementation of CPU idle driver for the TC2
ARM big.LITTLE SoC. It is based and dependent on Nico's branch

git://git.linaro.org/people/nico/linux mcpm+tc2

and relative pull request

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185411.html

First two patches in the series simply implement a method to disable the
GIC CPU IF and add the respective call in the MCPM TC2 back-end. Details
are explained in the commit logs.

Patch 3 implements the TC2 CPU idle driver, that paves the way for a
generic ARM idle driver, MCPM based (but PSCI can be easily integrated
as well) for all upcoming big.LITTLE systems.

The CPU idle driver is built upon the multiple drivers CPU idle infrastructure
to define different target residencies for different clusters.

Current driver matches the DT compatible string defining a TC2 testchip core
tile, but in the future will be augmented with a proper match table to
match against all machines that can rely on this driver to implement CPU
idle capabilities.

This CPU idle driver integrates all existing PM kernel concepts recently
implemented for ARM, MCPM, CPU PM notifiers and cpu_suspend and lays the
foundation for a reference implementation of a generic CPU idle driver, since
the driver as it stands is completely generic, C-states definition
notwithstanding.

C-state definition for the driver should be made dynamic so that the driver
can become completely generic and decoupled from static C-states definition.

The driver has been tested, obviously on the TC2 testchip, with different
Linux systems ranging from simple busybox to Android and Ubuntu rootfs,
through millions of C-state iterations randomly triggered by the
aforementioned root filesystem environments.

Comments and review very welcome.

With thanks,
Lorenzo

Lorenzo Pieralisi (2):
  ARM: vexpress: tc2: disable GIC CPU IF in tc2_pm_suspend
  cpuidle: big.LITTLE: vexpress-TC2 CPU idle driver

Nicolas Pitre (1):
  drivers: irq-chip: irq-gic: introduce gic_cpu_if_down()

 MAINTAINERS                          |   9 ++
 arch/arm/mach-vexpress/tc2_pm.c      |   2 +
 drivers/cpuidle/Kconfig              |  10 ++
 drivers/cpuidle/Makefile             |   1 +
 drivers/cpuidle/cpuidle-big_little.c | 187 +++++++++++++++++++++++++++++++++++
 drivers/irqchip/irq-gic.c            |   6 ++
 include/linux/irqchip/arm-gic.h      |   1 +
 7 files changed, 216 insertions(+)
 create mode 100644 drivers/cpuidle/cpuidle-big_little.c

-- 
1.8.2.2




From lorenzo.pieralisi at arm.com  Thu Jul 25 07:14:26 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 25 Jul 2013 12:14:26 +0100
Subject: [RFC PATCH 3/3] cpuidle: big.LITTLE: vexpress-TC2 CPU idle driver
In-Reply-To: <1374750866-750-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1374750866-750-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <1374750866-750-4-git-send-email-lorenzo.pieralisi@arm.com>

The big.LITTLE architecture is composed of two clusters of cpus. One cluster
contains less powerful but more energy efficient processors and the other
cluster groups the powerful but energy-intensive cpus.

The TC2 testchip implements two clusters of CPUs (A7 and A15 clusters in
a big.LITTLE configuration) connected through a CCI interconnect that manages
coherency of their respective L2 caches and intercluster distributed
virtual memory messages (DVM).

TC2 testchip integrates a power controller that manages cores resets, wake-up
IRQs and cluster low-power states. Power states are managed at cluster
level, which means that voltage is removed from a cluster iff all cores
in a cluster are in a wfi state. Single cores can enter a reset state
which is identical to wfi in terms of power consumption but simplifies the
way cluster states are entered.

This patch provides a multiple driver CPU idle implementation for TC2
which paves the way for a generic big.LITTLE idle driver for all
upcoming big.LITTLE based systems on chip.

The driver relies on the MCPM infrastructure to coordinate and manage
core power states; in particular MCPM allows to suspend specific cores
and hides the CPUs coordination required to shut-down clusters of CPUs.

Power down sequences for the respective clusters are implemented in the
MCPM TC2 backend, with all code needed to clean caches and exit coherency.

The multiple driver CPU idle infrastructure allows to define different
C-states for big and little cores, determined at boot by checking the
part id of the possible CPUs and initializing the respective logical
masks in the big and little drivers.

Current big.little systems are composed of A7 and A15 clusters, as
implemented in TC2, but in the future that may change and the driver
will have evolve to retrieve what is a 'big' cpu and what is a 'little'
cpu in order to build the correct topology.

Cc: Kevin Hilman <khilman at linaro.org>
Cc: Amit Kucheria <amit.kucheria at linaro.org>
Cc: Olof Johansson <olof at lixom.net>
Cc: Nicolas Pitre <nicolas.pitre at linaro.org>
Cc: Rafael J. Wysocki <rjw at sisk.pl>
Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 MAINTAINERS                          |   9 ++
 drivers/cpuidle/Kconfig              |  10 ++
 drivers/cpuidle/Makefile             |   1 +
 drivers/cpuidle/cpuidle-big_little.c | 187 +++++++++++++++++++++++++++++++++++
 4 files changed, 207 insertions(+)
 create mode 100644 drivers/cpuidle/cpuidle-big_little.c

diff --git a/MAINTAINERS b/MAINTAINERS
index bf61e04..01f1b3d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2263,6 +2263,15 @@ F:	drivers/cpufreq/arm_big_little.h
 F:	drivers/cpufreq/arm_big_little.c
 F:	drivers/cpufreq/arm_big_little_dt.c
 
+CPUIDLE DRIVER - ARM BIG LITTLE
+M:      Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
+M:      Daniel Lezcano <daniel.lezcano at linaro.org>
+L:      linux-pm at vger.kernel.org
+L:      linux-arm-kernel at lists.infradead.org
+T:      git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
+S:      Maintained
+F:      drivers/cpuidle/cpuidle-big_little.c
+
 CPUIDLE DRIVERS
 M:	Rafael J. Wysocki <rjw at sisk.pl>
 M:	Daniel Lezcano <daniel.lezcano at linaro.org>
diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index 0e2cd5c..0f86587 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
@@ -42,6 +42,16 @@ config CPU_IDLE_ZYNQ
 	help
 	  Select this to enable cpuidle on Xilinx Zynq processors.
 
+config CPU_IDLE_BIG_LITTLE
+	bool "Support for ARM big.LITTLE processors"
+	depends on ARCH_VEXPRESS_TC2_PM
+	select ARM_CPU_SUSPEND
+	select CPU_IDLE_MULTIPLE_DRIVERS
+	help
+	  Select this option to enable CPU idle driver for big.LITTLE based
+	  ARM systems. Driver manages CPUs coordination through MCPM and
+	  define different C-states for little and big cores through the
+	  multiple CPU idle drivers infrastructure.
 endif
 
 config ARCH_NEEDS_CPU_IDLE_COUPLED
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 8767a7b..3b6445c 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
 obj-$(CONFIG_CPU_IDLE_CALXEDA) += cpuidle-calxeda.o
 obj-$(CONFIG_ARCH_KIRKWOOD) += cpuidle-kirkwood.o
 obj-$(CONFIG_CPU_IDLE_ZYNQ) += cpuidle-zynq.o
+obj-$(CONFIG_CPU_IDLE_BIG_LITTLE) += cpuidle-big_little.o
diff --git a/drivers/cpuidle/cpuidle-big_little.c b/drivers/cpuidle/cpuidle-big_little.c
new file mode 100644
index 0000000..98cb375
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -0,0 +1,187 @@
+/*
+ * Copyright (c) 2013 ARM/Linaro
+ *
+ * Authors: Daniel Lezcano <daniel.lezcano at linaro.org>
+ *          Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
+ *          Nicolas Pitre <nicolas.pitre at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Maintainer: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
+ * Maintainer: Daniel Lezcano <daniel.lezcano at linaro.org>
+ */
+#include <linux/cpuidle.h>
+#include <linux/cpu_pm.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+
+#include <asm/cpu.h>
+#include <asm/cputype.h>
+#include <asm/cpuidle.h>
+#include <asm/mcpm.h>
+#include <asm/smp_plat.h>
+#include <asm/suspend.h>
+
+static int bl_enter_powerdown(struct cpuidle_device *dev,
+			      struct cpuidle_driver *drv, int idx);
+
+static struct cpuidle_driver bl_idle_little_driver = {
+	.name = "little_idle",
+	.owner = THIS_MODULE,
+	.states[0] = ARM_CPUIDLE_WFI_STATE,
+	.states[1] = {
+		.enter			= bl_enter_powerdown,
+		.exit_latency		= 1000,
+		.target_residency	= 3500,
+		.flags			= CPUIDLE_FLAG_TIME_VALID |
+					  CPUIDLE_FLAG_TIMER_STOP,
+		.name			= "C1",
+		.desc			= "ARM little-cluster power down",
+	},
+	.state_count = 2,
+};
+
+static struct cpuidle_driver bl_idle_big_driver = {
+	.name = "big_idle",
+	.owner = THIS_MODULE,
+	.states[0] = ARM_CPUIDLE_WFI_STATE,
+	.states[1] = {
+		.enter			= bl_enter_powerdown,
+		.exit_latency		= 1000,
+		.target_residency	= 3000,
+		.flags			= CPUIDLE_FLAG_TIME_VALID |
+					  CPUIDLE_FLAG_TIMER_STOP,
+		.name			= "C1",
+		.desc			= "ARM big-cluster power down",
+	},
+	.state_count = 2,
+};
+
+/*
+ * notrace prevents trace shims from getting inserted where they
+ * should not. Global jumps and ldrex/strex must not be inserted
+ * in power down sequences where caches and MMU may be turned off.
+ */
+static int notrace bl_powerdown_finisher(unsigned long arg)
+{
+	/* MCPM works with HW CPU identifiers */
+	unsigned int mpidr = read_cpuid_mpidr();
+	unsigned int cluster = (mpidr >> 8) & 0xf;
+	unsigned int cpu = mpidr & 0xf;
+
+	mcpm_set_entry_vector(cpu, cluster, cpu_resume);
+	/*
+	 * Residency value passed to mcpm_cpu_suspend back-end
+	 * has to be given clear semantics. Set to 0 as a
+	 * temporary value.
+	 */
+	mcpm_cpu_suspend(0);
+	/* return value != 0 means failure */
+	return 1;
+}
+
+/**
+ * bl_enter_powerdown - Programs CPU to enter the specified state
+ * @dev: cpuidle device
+ * @drv: The target state to be programmed
+ * @idx: state index
+ *
+ * Called from the CPUidle framework to program the device to the
+ * specified target state selected by the governor.
+ */
+static int bl_enter_powerdown(struct cpuidle_device *dev,
+				struct cpuidle_driver *drv, int idx)
+{
+	struct timespec ts_preidle, ts_postidle, ts_idle;
+	int ret;
+
+	/* Used to keep track of the total time in idle */
+	getnstimeofday(&ts_preidle);
+
+	cpu_pm_enter();
+
+	ret = cpu_suspend(0, bl_powerdown_finisher);
+	/* signals the MCPM core that CPU is out of low power state */
+	mcpm_cpu_powered_up();
+
+	cpu_pm_exit();
+
+	getnstimeofday(&ts_postidle);
+	ts_idle = timespec_sub(ts_postidle, ts_preidle);
+
+	dev->last_residency = ts_idle.tv_nsec / NSEC_PER_USEC +
+					ts_idle.tv_sec * USEC_PER_SEC;
+	local_irq_enable();
+	return idx;
+}
+
+static int __init bl_idle_driver_init(struct cpuidle_driver *drv, int cpu_id)
+{
+	struct cpuinfo_arm *cpu_info;
+	struct cpumask *cpumask;
+	unsigned long cpuid;
+	int cpu;
+
+	cpumask = kzalloc(cpumask_size(), GFP_KERNEL);
+	if (!cpumask)
+		return -ENOMEM;
+
+	for_each_possible_cpu(cpu) {
+		cpu_info = &per_cpu(cpu_data, cpu);
+		cpuid = is_smp() ? cpu_info->cpuid : read_cpuid_id();
+
+		/* read cpu id part number */
+		if ((cpuid & 0xFFF0) == cpu_id)
+			cpumask_set_cpu(cpu, cpumask);
+	}
+
+	drv->cpumask = cpumask;
+
+	return 0;
+}
+
+static int __init bl_idle_init(void)
+{
+	int ret;
+	/*
+	 * Initialize the driver just for a compliant set of machines
+	 */
+	if (!of_machine_is_compatible("arm,vexpress,v2p-ca15_a7"))
+		return -ENODEV;
+	/*
+	 * For now the differentiation between little and big cores
+	 * is based on the part number. A7 cores are considered little
+	 * cores, A15 are considered big cores. This distinction may
+	 * evolve in the future with a more generic matching approach.
+	 */
+	ret = bl_idle_driver_init(&bl_idle_little_driver,
+				  ARM_CPU_PART_CORTEX_A7);
+	if (ret)
+		return ret;
+
+	ret = bl_idle_driver_init(&bl_idle_big_driver, ARM_CPU_PART_CORTEX_A15);
+	if (ret)
+		goto out_uninit_little;
+
+	ret = cpuidle_register(&bl_idle_little_driver, NULL);
+	if (ret)
+		goto out_uninit_big;
+
+	ret = cpuidle_register(&bl_idle_big_driver, NULL);
+	if (ret)
+		goto out_unregister_little;
+
+	return 0;
+
+out_unregister_little:
+	cpuidle_unregister(&bl_idle_little_driver);
+out_uninit_big:
+	kfree(bl_idle_big_driver.cpumask);
+out_uninit_little:
+	kfree(bl_idle_little_driver.cpumask);
+
+	return ret;
+}
+device_initcall(bl_idle_init);
-- 
1.8.2.2




From ben.dooks at codethink.co.uk  Thu Jul 25 07:17:59 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 12:17:59 +0100
Subject: [PATCH 2/4] ARM: traps: use <asm/opcodes.h> to get correct
 instruction order
In-Reply-To: <20130724173435.GC4610@localhost.localdomain>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374510833-25716-3-git-send-email-ben.dooks@codethink.co.uk>
 <20130724173435.GC4610@localhost.localdomain>
Message-ID: <51F10967.1090302@codethink.co.uk>

On 24/07/13 18:34, Dave Martin wrote:
> On Mon, Jul 22, 2013 at 05:33:51PM +0100, Ben Dooks wrote:
>> The trap handler needs to take into account the endian configuration of
>> the system when loading instructions. Use<asm/opcodes.h>  to provide the
>> necessary conversion functions.
>>
>> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
>> ---
>>   arch/arm/kernel/traps.c |   10 ++++++----
>>   1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
>> index 1c08911..0a56e13 100644
>> --- a/arch/arm/kernel/traps.c
>> +++ b/arch/arm/kernel/traps.c
>> @@ -34,6 +34,7 @@
>>   #include<asm/unwind.h>
>>   #include<asm/tls.h>
>>   #include<asm/system_misc.h>
>> +#include<asm/opcodes.h>
>>
>>   #include "signal.h"
>
> Looks like is_valid_bugaddr() might need fixing too?
>
> That will need __mem_to_opcode_thumb16() or __mem_to_opcode_arm()
> depending on CONFIG_THUMB2_KERNEL.

I was looking at that, and was considering if this is the right
thing to do or to change the value of BUG_INSTR_VALUE depending
on this.

It is possible the linker may try and change the ordering of the
BUG() instruction as it is being placed in the output with either
a .hword or .word value. I will go and check this as soon as possible.

>> @@ -411,23 +412,24 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
>>   	if (processor_mode(regs) == SVC_MODE) {
>>   #ifdef CONFIG_THUMB2_KERNEL
>>   		if (thumb_mode(regs)) {
>> -			instr = ((u16 *)pc)[0];
>> +			instr = __mem_to_opcode_thumb16(((u16 *)pc)[0]);
>>   			if (is_wide_instruction(instr)) {
>>   				instr<<= 16;
>> -				instr |= ((u16 *)pc)[1];
>> +				instr |= __mem_to_opcode_thumb16(((u16 *)pc)[1]);
>
> Could use __opcode_thumb32_compose(), in which case it might look like
>
> 			if (is_wide_instruction(instr)) {
> 				unsigned int instr2 = __mem_to_opcode_thumb16(
> 					((u16 *)pc)[1]);
> 				instr = __opcode_thumb32_compose(instr, instr2);
>
> (Hmmm, I just noticed that is_wide_instruction and __opcode_is_thumb16()
> kinda duplicate each other.  Could change that too, but it would look
> more like pointless churn...  is_wide_instruction() is used in a fair
> few places already.)

It is possible that it could be changed, but I will avoid that for this
particular patch

>>   			}
>>   		} else
>>   #endif
>> -			instr = *(u32 *) pc;
>> +			instr = __mem_to_opcode_arm(*(u32 *) pc);
>>   	} else if (thumb_mode(regs)) {
>>   		if (get_user(instr, (u16 __user *)pc))
>>   			goto die_sig;
>> +		instr = __mem_to_opcode_thumb16(instr);
>>   		if (is_wide_instruction(instr)) {
>>   			unsigned int instr2;
>>   			if (get_user(instr2, (u16 __user *)pc+1))
>>   				goto die_sig;
>>   			instr<<= 16;
>> -			instr |= instr2;
>> +			instr |= __mem_to_opcode_thumb16(instr2);
>>   		}
>>   	} else if (get_user(instr, (u32 __user *)pc)) {
>
> This also needs mem-to-opcode'ing.

Thanks, will check.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From b.zolnierkie at samsung.com  Thu Jul 25 07:19:06 2013
From: b.zolnierkie at samsung.com (Bartlomiej Zolnierkiewicz)
Date: Thu, 25 Jul 2013 13:19:06 +0200
Subject: [PATCH] ARM: EXYNOS: cpuidle: Skip C1 cpuidle state for exynos5440
In-Reply-To: <1374659615-29447-1-git-send-email-amit.daniel@samsung.com>
References: <0e7d01ce8840$82f79070$88e6b150$@org>
 <1374659615-29447-1-git-send-email-amit.daniel@samsung.com>
Message-ID: <9315698.l6JrEAGWLQ@amdc1032>


[ added Daniel and linux-pm to cc: ]

Hi,

On Wednesday, July 24, 2013 03:23:35 PM Amit Daniel Kachhap wrote:
> This patch skips the deep C1(AFTR -Arm off top running) state for exynos5440
> soc as this soc does not support this state. All the cpu's only allows the basic
> C0 state.
> 
> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
> ---
>  arch/arm/mach-exynos/cpuidle.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
> index 17a18ff..9a776a1 100644
> --- a/arch/arm/mach-exynos/cpuidle.c
> +++ b/arch/arm/mach-exynos/cpuidle.c
> @@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void)
>  		device->cpu = cpu_id;
>  
>  		/* Support IDLE only */
> -		if (cpu_id != 0)
> +		if (soc_is_exynos5440() || cpu_id != 0)
>  			device->state_count = 1;
>  
>  		ret = cpuidle_register_device(device);

This may not achieve what you are intending to do and conflicts with
Daniel's patch (which removes code that you're modifying). Please see:

	http://marc.info/?l=linux-arm-kernel&m=137467935712513&w=2

How's about changing exynos4_idle_driver.state_count for EXYNOS5540
at the beginning of exynos4_init_cpuidle() instead?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics



From sergei.shtylyov at cogentembedded.com  Thu Jul 25 11:19:50 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 25 Jul 2013 19:19:50 +0400
Subject: [PATCH v2 3/3] ARM: shmobile: marzen: Enable ARM_APPENDED_DTB
 in defconfig
In-Reply-To: <1374718423-24230-4-git-send-email-horms+renesas@verge.net.au>
References: <1374718423-24230-1-git-send-email-horms+renesas@verge.net.au>
 <1374718423-24230-4-git-send-email-horms+renesas@verge.net.au>
Message-ID: <51F14216.1010606@cogentembedded.com>

Hello.

On 25-07-2013 6:13, Simon Horman wrote:

> "ARM: shmobile: marzen: Switch to DT_MACHINE_START" moves marzen
> over to use DT_MACHINE_START, however, the prevelant boot loader

    s/prevelant/prevalent/?

> does not support booting with a separate dtb. Thus, it makes
> sense to use ARM_APPENDED_DTB by default.

> This is consistent with other shmobile defconfigs.

> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

WBR, Sergei



From linux at arm.linux.org.uk  Thu Jul 25 07:25:58 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 25 Jul 2013 12:25:58 +0100
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <20130725110634.GB2546@localhost.localdomain>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
 <20130725110634.GB2546@localhost.localdomain>
Message-ID: <20130725112558.GD24642@n2100.arm.linux.org.uk>

On Thu, Jul 25, 2013 at 12:06:34PM +0100, Dave Martin wrote:
> On Wed, Jul 24, 2013 at 08:27:13AM -0700, Olof Johansson wrote:
> > Every now and then I come across a binding that's just done Wrong(tm),
> > merged through a submaintainer tree and hasn't seen proper review --
> > if it had, it wouldn't look the way it does. It's something we're
> > starting to address now since there's more people stepping up to be
> > maintainers, but there's a backlog of bad bindings already merged.
> > 
> > Often they are produced by translating the platform_data structures
> > directly over into device-tree properties without consideration to
> > describing the hardware or usual conventions, using key/value pairs
> > instead of boolean properties, etc.
> > 
> > Getting involved in cleaning up these kind of bindings is a great way
> > to learn "the ways of device tree" for someone that has interest in
> > that.
> > 
> > Latest find in this area is the Maxim 8925 bindings, that I came
> > across since they caused a compile warning on some defconfig. I'll
> > post a patch to address the warning but if someone else feels like
> > fixing the bindings on top of it that would be appreciated!
> 
> DT bindings (even poorly conceived, ad-hoc and/or undocumented ones)
> are ABI.
> 
> A review/merge process which _allows_ junk into an ABI is the real
> problem we need to solve here, but once it's there we can't just magic
> it away.
> 
> Do we plan on having a proper deprecation path for the junk, so that
> the old, superseded bindings continue to work for a limited time,
> preferably with a big fat warning somewhere?

This is the exact problem, and if you've seen how Linus rants about
the ARM ecosystem breaking ABI stuff all the time, you will start to
appreciate why ARM is not highly valued in the Linux communities.

We need to stop this crap getting in.

We need subsystem people to refuse to merge DT stuff if it hasn't been
reviewed by DT people - subsystem people are _not_ qualified to accept
those patches, even if they're responsible for the files which they're
being applied to. Yes, they can review them, but they should _not_
accept them without them having the bindings reviewed by folk who (a)
know the hardware and (b) know the implications of creating a DT binding.

That means whoever is doing the review of DT bindings probably needs to
have access to documentation on the hardware - or they need to be educated
by the submitter.  Or, we need submitters to individually justify why
each and every property is required in the description.

As for those already there, I don't think there's anything which can be
done about them in the short term (short = quite a few years) - we can't
go removing any properties that are already there, because that will
break the ABI.  We're basically stuck with that crap for ever now.

That's the point that people have to understand: if they accept a DT
description into the kernel, it's basically saying at that point that
the DT description is the official and definitive description for that
hardware.  It's just the same as adding a new syscall or something like
that which the entire world starts to use immediately.  You can't go
removing or changing it after the fact.

And this is also why a _hell_ of a lot of thought should go into each
and every property _before_ it is even proposed by the patch submitter.


From jonathan.austin at arm.com  Thu Jul 25 07:44:05 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Thu, 25 Jul 2013 12:44:05 +0100
Subject: [PATCH 02/13] ARM: gic: add CPU migration support
In-Reply-To: <1374550289-25305-3-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-3-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <51F10F85.7090508@arm.com>

Hi Nico,

I've got a couple of minor questions/comments about this one...

On 23/07/13 04:31, Nicolas Pitre wrote:
> This is required by the big.LITTLE switcher code.
>
> The gic_migrate_target() changes the CPU interface mapping for the
> current CPU to redirect SGIs to the specified interface, and it also
> updates the target CPU for each interrupts to that CPU interface
> if they were targeting the current interface.  Finally, pending
> SGIs for the current CPU are forwarded to the new interface.
>
> Because Linux does not use it, the SGI source information for the
> forwarded SGIs is not preserved.  Neither is the source information
> for the SGIs sent by the current CPU to other CPUs adjusted to match
> the new CPU interface mapping.  The required registers are banked so
> only the target CPU could do it.
>
> Signed-off-by: Nicolas Pitre <nico at linaro.org>
> ---
>   drivers/irqchip/irq-gic.c       | 81 +++++++++++++++++++++++++++++++++++++++--
>   include/linux/irqchip/arm-gic.h |  4 ++
>   2 files changed, 82 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index ee7c503120..6bd5a8c1aa 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -253,10 +253,9 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
>   	if (cpu >= NR_GIC_CPU_IF || cpu >= nr_cpu_ids)
>   		return -EINVAL;
>
> +	raw_spin_lock(&irq_controller_lock);
>   	mask = 0xff << shift;
>   	bit = gic_cpu_map[cpu] << shift;
> -
> -	raw_spin_lock(&irq_controller_lock);
>   	val = readl_relaxed(reg) & ~mask;
>   	writel_relaxed(val | bit, reg);
>   	raw_spin_unlock(&irq_controller_lock);
> @@ -646,7 +645,9 @@ static void __init gic_pm_init(struct gic_chip_data *gic)
>   void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
>   {
>   	int cpu;
> -	unsigned long map = 0;
> +	unsigned long flags, map = 0;
> +
> +	raw_spin_lock_irqsave(&irq_controller_lock, flags);
>
>   	/* Convert our logical CPU mask into a physical one. */
>   	for_each_cpu(cpu, mask)
> @@ -660,6 +661,80 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
>
>   	/* this always happens on GIC0 */
>   	writel_relaxed(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
> +
> +	raw_spin_unlock_irqrestore(&irq_controller_lock, flags);
> +}
> +#endif
> +
> +#ifdef CONFIG_BL_SWITCHER
> +/*
> + * gic_migrate_target - migrate IRQs to another PU interface

(nit) Should that be _C_PU?

> + *
> + * @new_cpu_id: the CPU target ID to migrate IRQs to
> + *
> + * Migrate all peripheral interrupts with a target matching the current CPU
> + * to the interface corresponding to @new_cpu_id.  The CPU interface mapping
> + * is also updated.  Targets to other CPU interfaces are unchanged.
> + * This must be called with IRQs locally disabled.
> + */
> +void gic_migrate_target(unsigned int new_cpu_id)
> +{
> +	unsigned int old_cpu_id, gic_irqs, gic_nr = 0;
> +	void __iomem *dist_base;
> +	int i, ror_val, cpu = smp_processor_id();
> +	u32 val, old_mask, active_mask;
> +
> +	if (gic_nr >= MAX_GIC_NR)
> +		BUG();
> +
> +	dist_base = gic_data_dist_base(&gic_data[gic_nr]);
> +	if (!dist_base)
> +		return;
> +	gic_irqs = gic_data[gic_nr].gic_irqs;
> +
> +	old_cpu_id = __ffs(gic_cpu_map[cpu]);
> +	old_mask = 0x01010101 << old_cpu_id;

I don't think this is very clear, though section 4.3.12 of the GIC spec 
helps a lot! A little pointer or some more self-evident name for the 
mask might be nice...

old_mask = GIC_ITARGETSR_MASK << old_cpu_id

or similar? This at least points one to the right bit of documentation?

> +	ror_val = (old_cpu_id - new_cpu_id) & 31;
> +
> +	raw_spin_lock(&irq_controller_lock);
> +
> +	gic_cpu_map[cpu] = 1 << new_cpu_id;
> +
> +	for (i = 8; i < DIV_ROUND_UP(gic_irqs, 4); i++) {

Does this '8' here warrant a #define? GIC_RO_INTR_REGS?

Perhaps everyone looking at the code will be familiar enough with the 
GIC to see immediately why the first 8 entries are being skipped...?

> +		val = readl_relaxed(dist_base + GIC_DIST_TARGET + i * 4);
> +		active_mask = val & old_mask;
> +		if (active_mask) {
> +			val &= ~active_mask;
> +			val |= ror32(active_mask, ror_val);
> +			writel_relaxed(val, dist_base + GIC_DIST_TARGET + i*4);
> +		}
> +	}
> +
> +	raw_spin_unlock(&irq_controller_lock);
> +
> +	/*
> +	 * Now let's migrate and clear any potential SGIs that might be
> +	 * pending for us (old_cpu_id).  Since GIC_DIST_SGI_PENDING_SET
> +	 * is a banked register, we can only forward the SGI using
> +	 * GIC_DIST_SOFTINT.  The original SGI source is lost but Linux
> +	 * doesn't use that information anyway.
> +	 *
> +	 * For the same reason we do not adjust SGI source information
> +	 * for previously sent SGIs by us to other CPUs either.
> +	 */
> +	for (i = 0; i < 16; i += 4) {
> +		int j;
> +		val = readl_relaxed(dist_base + GIC_DIST_SGI_PENDING_SET + i);
> +		if (!val)
> +			continue;
> +		writel_relaxed(val, dist_base + GIC_DIST_SGI_PENDING_CLEAR + i);
> +		for (j = i; j < i + 4; j++) {
> +			if (val & 0xff)
> +				writel_relaxed((1 << (new_cpu_id + 16)) | j,
> +						dist_base + GIC_DIST_SOFTINT);
> +			val >>= 8;
> +		}
> +	}

I'm curious as to why we don't need to do anything for PPIs here - could 
there be any pending PPIs that don't get handled (I guess retargetting 
doesn't make sense for these?)

>   }
>   #endif
>
> diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
> index 3e203eb23c..40bfcac959 100644
> --- a/include/linux/irqchip/arm-gic.h
> +++ b/include/linux/irqchip/arm-gic.h
> @@ -31,6 +31,8 @@
>   #define GIC_DIST_TARGET			0x800
>   #define GIC_DIST_CONFIG			0xc00
>   #define GIC_DIST_SOFTINT		0xf00
> +#define GIC_DIST_SGI_PENDING_CLEAR	0xf10
> +#define GIC_DIST_SGI_PENDING_SET	0xf20
>
>   #define GICH_HCR			0x0
>   #define GICH_VTR			0x4
> @@ -73,6 +75,8 @@ static inline void gic_init(unsigned int nr, int start,
>   	gic_init_bases(nr, start, dist, cpu, 0, NULL);
>   }
>
> +void gic_migrate_target(unsigned int new_cpu_id);
> +
>   #endif /* __ASSEMBLY */
>
>   #endif
>




From ben.dooks at codethink.co.uk  Thu Jul 25 07:48:18 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 12:48:18 +0100
Subject: [PATCH 1/4] ARM: alignment: correctly decode instructions in
 BE8 mode.
In-Reply-To: <20130724171613.GB4610@localhost.localdomain>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374510833-25716-2-git-send-email-ben.dooks@codethink.co.uk>
 <20130724171613.GB4610@localhost.localdomain>
Message-ID: <51F11082.6070708@codethink.co.uk>

On 24/07/13 18:16, Dave Martin wrote:
> instr = thumb2arm(tinstr);

oops, removed it by accident. thanks for spotting.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From b.brezillon at overkiz.com  Thu Jul 25 08:01:25 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Thu, 25 Jul 2013 14:01:25 +0200
Subject: [PATCH 4/5] iio: at91: add an optional dt property for for adc
 clock hz.
In-Reply-To: <1373789069-11604-5-git-send-email-josh.wu@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-5-git-send-email-josh.wu@atmel.com>
Message-ID: <51F11395.9040406@overkiz.com>

Hi Josh,

On 14/07/2013 10:04, Josh Wu wrote:
> Signed-off-by: Josh Wu <josh.wu at atmel.com>
> ---
>   Documentation/devicetree/bindings/arm/atmel-adc.txt |    2 ++
>   drivers/iio/adc/at91_adc.c                          |    8 +++++++-
>   2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> index 16769d9..0db2945 100644
> --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> @@ -27,6 +27,8 @@ Optional properties:
>   		       resolution will be used.
>     - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
>     - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
> +  - atmel,adc-clock-rate: ADC clock rate. If not specified, use the default
> +			  adc_op_clk.
>
>   Optional trigger Nodes:
>     - Required properties:
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index e93a075..8f1386f 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -47,6 +47,7 @@ struct at91_adc_caps {
>
>   struct at91_adc_state {
>   	struct clk		*adc_clk;
> +	u32			adc_clk_rate;
>   	u16			*buffer;
>   	unsigned long		channels_mask;
>   	struct clk		*clk;
> @@ -448,6 +449,10 @@ static int at91_adc_probe_dt(struct at91_adc_state *st,
>   	if (!node)
>   		return -EINVAL;
>
> +	prop = 0;
> +	of_property_read_u32(node, "atmel,adc-clock-rate", &prop);
> +	st->adc_clk_rate = prop;
> +
>   	st->use_external = of_property_read_bool(node, "atmel,adc-use-external-triggers");
>
>   	if (of_property_read_u32(node, "atmel,adc-channels-used", &prop)) {
> @@ -723,7 +728,8 @@ static int at91_adc_probe(struct platform_device *pdev)
>   	 * specified by the electrical characteristics of the board.
>   	 */
>   	mstrclk = clk_get_rate(st->clk);
> -	adc_clk = clk_get_rate(st->adc_clk);
> +	adc_clk = st->adc_clk_rate ?
> +		st->adc_clk_rate : clk_get_rate(st->adc_clk);
>   	adc_clk_khz = adc_clk / 1000;
>   	prsc = (mstrclk / (2 * adc_clk)) - 1;
>
>

As said by Maxime and Lars-Peter, I think this should be handled by a 
proper clock implementation (adc_clock ?) using common clock framework.

IMO the fake adc_op_clk should not exist. Instead the adc clock binding 
should define properties describing the adc clock characteristics (see 
pll implementation in at91 common clk series).
These characteristics can be found in 'ADC characteristics' chapter in 
atmel's datasheets.

The adc clock binding would look like this (based on sama5 datasheet):

adc_clk {
	compatible = "sama5d3-adc-clk";
	output = <1000000 20000000>; /* output clock frequency range */
};

It is up to the clk user (adc driver) to choose the appropriate 
frequency to use (maximum rate ?) and configure it with clk_set_rate 
function.
The adc clk implem will take care of PRESCAL field config in ADC_MR 
according to parent rate (mck rate) and requested rate. It will also 
check if the requested rate is in the output clk range.

These are just thought, feel free to comment it.

Best Regards,

Boris


From Dave.Martin at arm.com  Thu Jul 25 08:04:24 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Thu, 25 Jul 2013 13:04:24 +0100
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <20130723163319.GA781@e102568-lin.cambridge.arm.com>
References: <20130718150408.GB2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181231510.14924@syhkavp.arg>
 <20130718180323.GC2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181452480.14924@syhkavp.arg>
 <20130719102844.GA3746@localhost.localdomain>
 <20130719105907.GB27389@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307221353360.15022@syhkavp.arg>
 <20130723104352.GA3023@localhost.localdomain>
 <alpine.LFD.2.03.1307230821270.15022@syhkavp.arg>
 <20130723163319.GA781@e102568-lin.cambridge.arm.com>
Message-ID: <20130725120424.GC2546@localhost.localdomain>

On Tue, Jul 23, 2013 at 05:33:19PM +0100, Lorenzo Pieralisi wrote:
> On Tue, Jul 23, 2013 at 01:28:16PM +0100, Nicolas Pitre wrote:
> 
> [...]
> 
> > > > + * - The CPU is obviously no longer coherent with the other CPUs.
> > > > + *
> > > > + * Further considerations:
> > > > + *
> > > > + * - This relies on the presence and behavior of the AUXCR.SMP bit as
> > > > + *   documented in the ARMv7 TRM.  Vendor implementations that deviate from
> > > 
> > > Sorry to be pedantic here, but there is no "ARMv7 TRM".  The SMP bit is
> > > not part of ARMv7 at all.
> > 
> > Well, I just copied Lorenzo's words here, trusting he knew more about it 
> > than I do.
> > 
> > > Also, it seems that A9 isn't precisely the
> > > same: two ACTLR bits need to be twiddled.  R-class CPUs are generally
> > > not the same either.
> 
> If you mean the ACTLR.FW bit in A9, A5, and R7, then, IIRC, we do not need to
> clear it, clearing the SMP bit is enough.
> 
> See, Dave has a point, there is no explicit "unified v7 TRM disable
> clean and exit coherency procedure" even though the designers end goal is to
> have one and that's the one you wrote. The code you posted is perfectly ok on
> all v7 implementations in the kernel I am aware of, I stand to be corrected
> but to the best of my knowledge that's the case.

What I'm really concerned about here is not Cortex-*, but the vendors
who have their own CPU implementations.  I don't think I've ever seen
a TRM for one of those.

> 
> > > This is why I preferred to treat the whole sequence as specific to a
> > > particular CPU implementation.  The similarity between A7 and A15
> > > might be viewed as a happy coincidence (it also makes life easier in
> > > big.LITTLE land).
> > 
> > Fair enough.
> 
> I disagree on the happy coincidence but the point is taken. I am not

I confess to exaggeration!  There was obviously an effort to align A15
and A7, but we know there are differences at the system level, and there
is always the possibility of b.L pairings which differ on things like
the SMP bit, or b.L pairings of CPUs not originally designed to pair but
which are "similar enough" to be pairable.

> sure about what we should do, but I reiterate my point, the sequence as
> it stands is OK on all NS v7 implementations I am aware of. We can add
> macros to differentiate processors when we need them, but again that's
> just my opinion, as correct as it can be.

I still vote for naming them a15_* a7_* or similar.

For big.LITTLE pairings, I think we should assume that the big CPU's
macro is usable on the LITTLE CPU too.  Assuming sane CPU designs, that
will be true, and we know it works for A15+A7.

So we would use the a15 macro on TC2, but the a7 macro on an a7-only
platform.


The other way to abstract this stuff would be to add a new per-CPU
proc_fn, but that may be overkill, particularly since we know the whole
mcpm backend may tend to be platform-specific, not just the CPU coherency
exit part.

Cheers
---Dave


From broonie at kernel.org  Thu Jul 25 08:09:04 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 25 Jul 2013 13:09:04 +0100
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <201307251300.49282.arnd@arndb.de>
References: <Pine.LNX.4.44L0.1307231708020.1304-100000@iolanthe.rowland.org>
 <201307242032.03597.arnd@arndb.de> <2174304.5JlzJ583hP@avalon>
 <201307251300.49282.arnd@arndb.de>
Message-ID: <20130725120904.GB9858@sirena.org.uk>

On Thu, Jul 25, 2013 at 01:00:49PM +0200, Arnd Bergmann wrote:

> I'm not saying that we can't support legacy board files with the common
> PHY framework, but I'd expect things to be much easier if we focus on those
> platforms that are actively being worked on for now, to bring an end to the
> pointless API discussion.

Well, it seemed like Greg's concerns had already been addressed anyway.
-------------- 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/20130725/d6b5153b/attachment-0001.sig>

From b.brezillon at overkiz.com  Thu Jul 25 08:11:38 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Thu, 25 Jul 2013 14:11:38 +0200
Subject: [PATCH 4/5] iio: at91: add an optional dt property for for adc
 clock hz.
In-Reply-To: <51F11395.9040406@overkiz.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-5-git-send-email-josh.wu@atmel.com>
 <51F11395.9040406@overkiz.com>
Message-ID: <51F115FA.1040801@overkiz.com>

On 25/07/2013 14:01, boris brezillon wrote:
> Hi Josh,
>
> On 14/07/2013 10:04, Josh Wu wrote:
>> Signed-off-by: Josh Wu <josh.wu at atmel.com>
>> ---
>>   Documentation/devicetree/bindings/arm/atmel-adc.txt |    2 ++
>>   drivers/iio/adc/at91_adc.c                          |    8 +++++++-
>>   2 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> b/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> index 16769d9..0db2945 100644
>> --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
>> @@ -27,6 +27,8 @@ Optional properties:
>>                  resolution will be used.
>>     - atmel,adc-sleep-mode: Boolean to enable sleep mode when no
>> conversion
>>     - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
>> +  - atmel,adc-clock-rate: ADC clock rate. If not specified, use the
>> default
>> +              adc_op_clk.
>>
>>   Optional trigger Nodes:
>>     - Required properties:
>> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
>> index e93a075..8f1386f 100644
>> --- a/drivers/iio/adc/at91_adc.c
>> +++ b/drivers/iio/adc/at91_adc.c
>> @@ -47,6 +47,7 @@ struct at91_adc_caps {
>>
>>   struct at91_adc_state {
>>       struct clk        *adc_clk;
>> +    u32            adc_clk_rate;
>>       u16            *buffer;
>>       unsigned long        channels_mask;
>>       struct clk        *clk;
>> @@ -448,6 +449,10 @@ static int at91_adc_probe_dt(struct
>> at91_adc_state *st,
>>       if (!node)
>>           return -EINVAL;
>>
>> +    prop = 0;
>> +    of_property_read_u32(node, "atmel,adc-clock-rate", &prop);
>> +    st->adc_clk_rate = prop;
>> +
>>       st->use_external = of_property_read_bool(node,
>> "atmel,adc-use-external-triggers");
>>
>>       if (of_property_read_u32(node, "atmel,adc-channels-used", &prop)) {
>> @@ -723,7 +728,8 @@ static int at91_adc_probe(struct platform_device
>> *pdev)
>>        * specified by the electrical characteristics of the board.
>>        */
>>       mstrclk = clk_get_rate(st->clk);
>> -    adc_clk = clk_get_rate(st->adc_clk);
>> +    adc_clk = st->adc_clk_rate ?
>> +        st->adc_clk_rate : clk_get_rate(st->adc_clk);
>>       adc_clk_khz = adc_clk / 1000;
>>       prsc = (mstrclk / (2 * adc_clk)) - 1;
>>
>>
>
> As said by Maxime and Lars-Peter, I think this should be handled by a
> proper clock implementation (adc_clock ?) using common clock framework.
>
> IMO the fake adc_op_clk should not exist. Instead the adc clock binding
> should define properties describing the adc clock characteristics (see
> pll implementation in at91 common clk series).
> These characteristics can be found in 'ADC characteristics' chapter in
> atmel's datasheets.
>
> The adc clock binding would look like this (based on sama5 datasheet):
>
> adc_clk {
>      compatible = "sama5d3-adc-clk";
>      output = <1000000 20000000>; /* output clock frequency range */
> };

or more like this:

adc_clk {
	compatible = "xxx-adc-clk";
	#clock-cells = <0>;
	clocks = <&mck>;
	output = <1000000 20000000>; /* output clock frequency range */
};
>
> It is up to the clk user (adc driver) to choose the appropriate
> frequency to use (maximum rate ?) and configure it with clk_set_rate
> function.
> The adc clk implem will take care of PRESCAL field config in ADC_MR
> according to parent rate (mck rate) and requested rate. It will also
> check if the requested rate is in the output clk range.
>
> These are just thought, feel free to comment it.
>
> Best Regards,
>
> Boris
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From s.nawrocki at samsung.com  Thu Jul 25 08:34:14 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Thu, 25 Jul 2013 14:34:14 +0200
Subject: [PATCH v5 4/5] clk: add CLK_SET_RATE_NO_REPARENT flag
In-Reply-To: <1371139562-305-5-git-send-email-james.hogan@imgtec.com>
References: <1371139562-305-1-git-send-email-james.hogan@imgtec.com>
 <1371139562-305-5-git-send-email-james.hogan@imgtec.com>
Message-ID: <51F11B46.7010900@samsung.com>

Hi James,

On 06/13/2013 06:06 PM, James Hogan wrote:
> Add a CLK_SET_RATE_NO_REPARENT clock flag, which will prevent muxes
> being reparented during clk_set_rate.
> 
> To avoid breaking existing platforms, all callers of clk_register_mux()
> are adjusted to pass the new flag. Platform maintainers are encouraged
> to remove the flag if they wish to allow mux reparenting on set_rate.
[..]
> Changes in v3:
> 
> * rename/invert CLK_SET_RATE_REMUX to CLK_SET_RATE_NO_REPARENT and move
>   to this new patch.
> * patch 3: add CLK_SET_RATE_NO_REPARENT flag to all callers of
>   clk_register_mux. If you don't mind your clocks being reparented in
>   response to set_rate please let me know and I'll drop the relevant
>   portion of the patch.

Why is this better to change current behaviour of the clock core
and modify all drivers instead of having, e.g. CLK_SET_RATE_REPARENT
set in drivers of hardware that supports clock re-parenting while
setting clock rate ?

Is there intention to just have the automatic clock re-parenting
as a default feature in the common clock API ?
My apologies if this has already been answered, I haven't been
following this thread.

Thanks,
Sylwester

>  arch/arm/mach-imx/clk.h              |   5 +-
>  drivers/clk/mmp/clk-mmp2.c           |  39 +++++---
>  drivers/clk/mmp/clk-pxa168.c         |  40 +++++---
>  drivers/clk/mmp/clk-pxa910.c         |  31 +++---
>  drivers/clk/mxs/clk.h                |   4 +-
>  drivers/clk/samsung/clk.h            |   2 +-
>  drivers/clk/spear/spear1310_clock.c  | 179 ++++++++++++++++++-----------------
>  drivers/clk/spear/spear1340_clock.c  |  97 ++++++++++---------
>  drivers/clk/spear/spear3xx_clock.c   |  57 +++++++----
>  drivers/clk/spear/spear6xx_clock.c   |  35 +++----
>  drivers/clk/sunxi/clk-sunxi.c        |   3 +-
>  drivers/clk/tegra/clk-tegra114.c     |  36 ++++---
>  drivers/clk/tegra/clk-tegra20.c      |   6 +-
>  drivers/clk/tegra/clk-tegra30.c      |  33 ++++---
>  drivers/clk/versatile/clk-vexpress.c |   4 +-
>  include/linux/clk-provider.h         |   1 +
>  16 files changed, 334 insertions(+), 238 deletions(-)

-- 
Sylwester Nawrocki
Samsung R&D Institute Poland


From marex at denx.de  Thu Jul 25 08:36:26 2013
From: marex at denx.de (Marek Vasut)
Date: Thu, 25 Jul 2013 14:36:26 +0200
Subject: [PATCH v12 00/13] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <20130725055855.GA4924@nchen-desktop>
References: <1373524041-10482-1-git-send-email-peter.chen@freescale.com>
 <201307250755.23403.marex@denx.de> <20130725055855.GA4924@nchen-desktop>
Message-ID: <201307251436.27161.marex@denx.de>

Dear Peter Chen,

> On Thu, Jul 25, 2013 at 07:55:23AM +0200, Marek Vasut wrote:
> > Hi Peter,
> > 
> > > I have not tried the manual switching, but first, you need to close
> > > your vbus supply.
> > 
> > I think we can close this issue, I will now be also getting MX28EVK.
> > Thanks for all your help!
> 
> Great. What's the problem? Any changes for this patchset?

No changes needed, I had VDD5V constantly tied to 5V so I didn't get the VBUS 
interrupt.

Best regards,
Marek Vasut


From festevam at gmail.com  Thu Jul 25 08:42:21 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 25 Jul 2013 09:42:21 -0300
Subject: [patch 1/1] imx53-qsb: enable usb power
In-Reply-To: <20130620212939.018670789@rtp-net.org>
References: <20130620212939.018670789@rtp-net.org>
Message-ID: <CAOMZO5Bb7eUk9u0yhwo0+ektW6oj-WGVhE2pRYK6U4j=_G7Lag@mail.gmail.com>

On Thu, Jun 20, 2013 at 6:29 PM, Arnaud Patard
<arnaud.patard at rtp-net.org> wrote:
> Enable usb power pin by using a fixed regulator. With this and the usb clock
> patch is making usb working on my loco.

Which "usb clock patch" are you referring to?


From james.hogan at imgtec.com  Thu Jul 25 08:55:09 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Thu, 25 Jul 2013 13:55:09 +0100
Subject: [PATCH v5 4/5] clk: add CLK_SET_RATE_NO_REPARENT flag
In-Reply-To: <51F11B46.7010900@samsung.com>
References: <1371139562-305-1-git-send-email-james.hogan@imgtec.com>
 <1371139562-305-5-git-send-email-james.hogan@imgtec.com>
 <51F11B46.7010900@samsung.com>
Message-ID: <51F1202D.9060403@imgtec.com>

Hi Sylwester

On 25/07/13 13:34, Sylwester Nawrocki wrote:
> On 06/13/2013 06:06 PM, James Hogan wrote:
>> Add a CLK_SET_RATE_NO_REPARENT clock flag, which will prevent muxes
>> being reparented during clk_set_rate.
>>
>> To avoid breaking existing platforms, all callers of clk_register_mux()
>> are adjusted to pass the new flag. Platform maintainers are encouraged
>> to remove the flag if they wish to allow mux reparenting on set_rate.
> [..]
>> Changes in v3:
>>
>> * rename/invert CLK_SET_RATE_REMUX to CLK_SET_RATE_NO_REPARENT and move
>>   to this new patch.
>> * patch 3: add CLK_SET_RATE_NO_REPARENT flag to all callers of
>>   clk_register_mux. If you don't mind your clocks being reparented in
>>   response to set_rate please let me know and I'll drop the relevant
>>   portion of the patch.
> 
> Why is this better to change current behaviour of the clock core
> and modify all drivers instead of having, e.g. CLK_SET_RATE_REPARENT
> set in drivers of hardware that supports clock re-parenting while
> setting clock rate ?

See this message from Mike Turquette which first suggested it:

http://marc.info/?l=linux-kernel&m=136847508109344&w=2

> Is there intention to just have the automatic clock re-parenting
> as a default feature in the common clock API ?

Yes, that would be the result (except where explicitly disallowed).
Unfortunately where such policy should ideally be defined is still up in
the air.

It's not a property of the hardware, but then it is arguably a property
of the environment the bootloader has configured (like the stuff in the
/chosen device tree node).

Presuming that the usual reason not to reparent a mux is because other
important clocks depend on it, the kernel might know enough to work out
whether it's safe (unless of course there are other cores/threads in the
SoC using the clock that Linux isn't aware of, which brings us back to
it being a bootloader environment thing).

> My apologies if this has already been answered, I haven't been
> following this thread.

No problem :)

Cheers
James



From maxime.ripard at free-electrons.com  Thu Jul 25 09:05:10 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Jul 2013 15:05:10 +0200
Subject: [PATCHv2 0/3] Few ignored framebuffer fixes/additions
Message-ID: <1374757513-2253-1-git-send-email-maxime.ripard@free-electrons.com>

Hi,

This is the v2 of a set of patches that got forgotten.

These have been around for a while without any functionnal comments recently,
so I guess we should be pretty close to merge them.

It would be great if we could have comments from the maintainer on these
patches though.

Thanks,
Maxime

Changes from v1:
  - Fix line wrapping in patch 2
  - Added some comments on the msleep in patch 3

Alexandre Belloni (1):
  fb: backlight: HX8357: Add HX8369 support

Hector Palacios (1):
  video: mxsfb: fix color settings for 18bit data bus and 32bpp

Maxime Ripard (1):
  video: hx8357: Make IM pins optional

 drivers/video/backlight/hx8357.c | 272 +++++++++++++++++++++++++++++++++------
 drivers/video/mxsfb.c            |  26 ----
 2 files changed, 236 insertions(+), 62 deletions(-)

-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Thu Jul 25 09:05:11 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Jul 2013 15:05:11 +0200
Subject: [PATCHv2 1/3] video: mxsfb: fix color settings for 18bit data bus and
 32bpp
In-Reply-To: <1374757513-2253-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374757513-2253-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374757513-2253-2-git-send-email-maxime.ripard@free-electrons.com>

From: Hector Palacios <hector.palacios at digi.com>

For a combination of 18bit LCD data bus width and a color
mode of 32bpp, the driver was setting the color mapping to
rgb666, which is wrong, as the color in memory realy has an
rgb888 layout.

This patch also removes the setting of flag CTRL_DF24 that
makes the driver dimiss the upper 2 bits when handling 32/24bpp
colors in a diplay with 18bit data bus width. This flag made
true color images display wrong in such configurations.

Finally, the color mapping rgb666 has also been removed as nobody
is using it and high level applications like Qt5 cannot work
with it either.

Reference: https://lkml.org/lkml/2013/5/23/220
Signed-off-by: Hector Palacios <hector.palacios at digi.com>
Acked-by: Juergen Beisert <jbe at pengutronix.de>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/video/mxsfb.c | 26 --------------------------
 1 file changed, 26 deletions(-)

diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 3ba3771..dc09ebe 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -239,24 +239,6 @@ static const struct fb_bitfield def_rgb565[] = {
 	}
 };
 
-static const struct fb_bitfield def_rgb666[] = {
-	[RED] = {
-		.offset = 16,
-		.length = 6,
-	},
-	[GREEN] = {
-		.offset = 8,
-		.length = 6,
-	},
-	[BLUE] = {
-		.offset = 0,
-		.length = 6,
-	},
-	[TRANSP] = {	/* no support for transparency */
-		.length = 0,
-	}
-};
-
 static const struct fb_bitfield def_rgb888[] = {
 	[RED] = {
 		.offset = 16,
@@ -309,9 +291,6 @@ static int mxsfb_check_var(struct fb_var_screeninfo *var,
 			break;
 		case STMLCDIF_16BIT:
 		case STMLCDIF_18BIT:
-			/* 24 bit to 18 bit mapping */
-			rgb = def_rgb666;
-			break;
 		case STMLCDIF_24BIT:
 			/* real 24 bit */
 			rgb = def_rgb888;
@@ -453,11 +432,6 @@ static int mxsfb_set_par(struct fb_info *fb_info)
 			return -EINVAL;
 		case STMLCDIF_16BIT:
 		case STMLCDIF_18BIT:
-			/* 24 bit to 18 bit mapping */
-			ctrl |= CTRL_DF24; /* ignore the upper 2 bits in
-					    *  each colour component
-					    */
-			break;
 		case STMLCDIF_24BIT:
 			/* real 24 bit */
 			break;
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Thu Jul 25 09:05:12 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Jul 2013 15:05:12 +0200
Subject: [PATCHv2 2/3] video: hx8357: Make IM pins optional
In-Reply-To: <1374757513-2253-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374757513-2253-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374757513-2253-3-git-send-email-maxime.ripard@free-electrons.com>

The IM pins of the HX8357 controller are used to define the interface
used to feed pixel stream to the LCD panel.

Most of the time, these pins are directly routed to either the ground or
the VCC to set their values.

Remove the need to assign GPIOs to these pins when we are in such a case.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/video/backlight/hx8357.c | 53 +++++++++++++++++++++++-----------------
 1 file changed, 31 insertions(+), 22 deletions(-)

diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index a0482b5..00614ce 100644
--- a/drivers/video/backlight/hx8357.c
+++ b/drivers/video/backlight/hx8357.c
@@ -76,6 +76,7 @@ struct hx8357_data {
 	unsigned		reset;
 	struct spi_device	*spi;
 	int			state;
+	bool			use_im_pins;
 };
 
 static u8 hx8357_seq_power[] = {
@@ -250,9 +251,11 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
 	 * Set the interface selection pins to SPI mode, with three
 	 * wires
 	 */
-	gpio_set_value_cansleep(lcd->im_pins[0], 1);
-	gpio_set_value_cansleep(lcd->im_pins[1], 0);
-	gpio_set_value_cansleep(lcd->im_pins[2], 1);
+	if (lcd->use_im_pins) {
+		gpio_set_value_cansleep(lcd->im_pins[0], 1);
+		gpio_set_value_cansleep(lcd->im_pins[1], 0);
+		gpio_set_value_cansleep(lcd->im_pins[2], 1);
+	}
 
 	/* Reset the screen */
 	gpio_set_value(lcd->reset, 1);
@@ -424,26 +427,32 @@ static int hx8357_probe(struct spi_device *spi)
 		return -EINVAL;
 	}
 
-	for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
-		lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
-						"im-gpios", i);
-		if (lcd->im_pins[i] == -EPROBE_DEFER) {
-			dev_info(&spi->dev, "GPIO requested is not here yet, deferring the probe\n");
-			return -EPROBE_DEFER;
-		}
-		if (!gpio_is_valid(lcd->im_pins[i])) {
-			dev_err(&spi->dev, "Missing dt property: im-gpios\n");
-			return -EINVAL;
+	if (of_find_property(spi->dev.of_node, "im-gpios", NULL)) {
+		lcd->use_im_pins = 1;
+
+		for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
+			lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
+							    "im-gpios", i);
+			if (lcd->im_pins[i] == -EPROBE_DEFER) {
+				dev_info(&spi->dev, "GPIO requested is not here yet, deferring the probe\n");
+				return -EPROBE_DEFER;
+			}
+			if (!gpio_is_valid(lcd->im_pins[i])) {
+				dev_err(&spi->dev, "Missing dt property: im-gpios\n");
+				return -EINVAL;
+			}
+
+			ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
+						    GPIOF_OUT_INIT_LOW,
+						    "im_pins");
+			if (ret) {
+				dev_err(&spi->dev, "failed to request gpio %d: %d\n",
+					lcd->im_pins[i], ret);
+				return -EINVAL;
+			}
 		}
-
-		ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
-					GPIOF_OUT_INIT_LOW, "im_pins");
-		if (ret) {
-			dev_err(&spi->dev, "failed to request gpio %d: %d\n",
-				lcd->im_pins[i], ret);
-			return -EINVAL;
-		}
-	}
+	} else
+		lcd->use_im_pins = 0;
 
 	lcdev = lcd_device_register("mxsfb", &spi->dev, lcd, &hx8357_ops);
 	if (IS_ERR(lcdev)) {
-- 
1.8.3.2



From maxime.ripard at free-electrons.com  Thu Jul 25 09:05:13 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Jul 2013 15:05:13 +0200
Subject: [PATCHv2 3/3] fb: backlight: HX8357: Add HX8369 support
In-Reply-To: <1374757513-2253-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374757513-2253-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1374757513-2253-4-git-send-email-maxime.ripard@free-electrons.com>

From: Alexandre Belloni <alexandre.belloni at free-electrons.com>

Add support for the Himax HX8369 controller as it is quite similar to the
hx8357.

Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Acked-by: Jingoo Han <jg1.han at samsung.com>
---
 drivers/video/backlight/hx8357.c | 221 ++++++++++++++++++++++++++++++++++++---
 1 file changed, 206 insertions(+), 15 deletions(-)

diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index 00614ce..58ed4c1 100644
--- a/drivers/video/backlight/hx8357.c
+++ b/drivers/video/backlight/hx8357.c
@@ -71,6 +71,18 @@
 #define HX8357_SET_POWER_NORMAL		0xd2
 #define HX8357_SET_PANEL_RELATED	0xe9
 
+#define HX8369_SET_DISPLAY_BRIGHTNESS		0x51
+#define HX8369_WRITE_CABC_DISPLAY_VALUE		0x53
+#define HX8369_WRITE_CABC_BRIGHT_CTRL		0x55
+#define HX8369_WRITE_CABC_MIN_BRIGHTNESS	0x5e
+#define HX8369_SET_POWER			0xb1
+#define HX8369_SET_DISPLAY_MODE			0xb2
+#define HX8369_SET_DISPLAY_WAVEFORM_CYC		0xb4
+#define HX8369_SET_VCOM				0xb6
+#define HX8369_SET_EXTENSION_COMMAND		0xb9
+#define HX8369_SET_GIP				0xd5
+#define HX8369_SET_GAMMA_CURVE_RELATED		0xe0
+
 struct hx8357_data {
 	unsigned		im_pins[HX8357_NUM_IM_PINS];
 	unsigned		reset;
@@ -144,6 +156,61 @@ static u8 hx8357_seq_display_mode[] = {
 	HX8357_SET_DISPLAY_MODE_RGB_INTERFACE,
 };
 
+static u8 hx8369_seq_write_CABC_min_brightness[] = {
+	HX8369_WRITE_CABC_MIN_BRIGHTNESS, 0x00,
+};
+
+static u8 hx8369_seq_write_CABC_control[] = {
+	HX8369_WRITE_CABC_DISPLAY_VALUE, 0x24,
+};
+
+static u8 hx8369_seq_set_display_brightness[] = {
+	HX8369_SET_DISPLAY_BRIGHTNESS, 0xFF,
+};
+
+static u8 hx8369_seq_write_CABC_control_setting[] = {
+	HX8369_WRITE_CABC_BRIGHT_CTRL, 0x02,
+};
+
+static u8 hx8369_seq_extension_command[] = {
+	HX8369_SET_EXTENSION_COMMAND, 0xff, 0x83, 0x69,
+};
+
+static u8 hx8369_seq_display_related[] = {
+	HX8369_SET_DISPLAY_MODE, 0x00, 0x2b, 0x03, 0x03, 0x70, 0x00,
+	0xff, 0x00, 0x00, 0x00, 0x00, 0x03, 0x03, 0x00,	0x01,
+};
+
+static u8 hx8369_seq_panel_waveform_cycle[] = {
+	HX8369_SET_DISPLAY_WAVEFORM_CYC, 0x0a, 0x1d, 0x80, 0x06, 0x02,
+};
+
+static u8 hx8369_seq_set_address_mode[] = {
+	HX8357_SET_ADDRESS_MODE, 0x00,
+};
+
+static u8 hx8369_seq_vcom[] = {
+	HX8369_SET_VCOM, 0x3e, 0x3e,
+};
+
+static u8 hx8369_seq_gip[] = {
+	HX8369_SET_GIP, 0x00, 0x01, 0x03, 0x25, 0x01, 0x02, 0x28, 0x70,
+	0x11, 0x13, 0x00, 0x00, 0x40, 0x26, 0x51, 0x37, 0x00, 0x00, 0x71,
+	0x35, 0x60, 0x24, 0x07, 0x0f, 0x04, 0x04,
+};
+
+static u8 hx8369_seq_power[] = {
+	HX8369_SET_POWER, 0x01, 0x00, 0x34, 0x03, 0x00, 0x11, 0x11, 0x32,
+	0x2f, 0x3f, 0x3f, 0x01, 0x3a, 0x01, 0xe6, 0xe6, 0xe6, 0xe6, 0xe6,
+};
+
+static u8 hx8369_seq_gamma_curve_related[] = {
+	HX8369_SET_GAMMA_CURVE_RELATED, 0x00, 0x0d, 0x19, 0x2f, 0x3b, 0x3d,
+	0x2e, 0x4a, 0x08, 0x0e, 0x0f, 0x14, 0x16, 0x14, 0x14, 0x14, 0x1e,
+	0x00, 0x0d, 0x19, 0x2f, 0x3b, 0x3d, 0x2e, 0x4a, 0x08, 0x0e, 0x0f,
+	0x14, 0x16, 0x14, 0x14, 0x14, 0x1e,
+};
+
 static int hx8357_spi_write_then_read(struct lcd_device *lcdev,
 				u8 *txbuf, u16 txlen,
 				u8 *rxbuf, u16 rxlen)
@@ -220,6 +287,10 @@ static int hx8357_enter_standby(struct lcd_device *lcdev)
 	if (ret < 0)
 		return ret;
 
+	/*
+	 * The controller needs 120ms when entering in sleep mode before we can
+	 * send the command to go off sleep mode
+	 */
 	msleep(120);
 
 	return 0;
@@ -233,6 +304,10 @@ static int hx8357_exit_standby(struct lcd_device *lcdev)
 	if (ret < 0)
 		return ret;
 
+	/*
+	 * The controller needs 120ms when exiting from sleep mode before we
+	 * can send the command to enter in sleep mode
+	 */
 	msleep(120);
 
 	ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_ON);
@@ -242,6 +317,21 @@ static int hx8357_exit_standby(struct lcd_device *lcdev)
 	return 0;
 }
 
+static void hx8357_lcd_reset(struct lcd_device *lcdev)
+{
+	struct hx8357_data *lcd = lcd_get_data(lcdev);
+
+	/* Reset the screen */
+	gpio_set_value(lcd->reset, 1);
+	usleep_range(10000, 12000);
+	gpio_set_value(lcd->reset, 0);
+	usleep_range(10000, 12000);
+	gpio_set_value(lcd->reset, 1);
+
+	/* The controller needs 120ms to recover from reset */
+	msleep(120);
+}
+
 static int hx8357_lcd_init(struct lcd_device *lcdev)
 {
 	struct hx8357_data *lcd = lcd_get_data(lcdev);
@@ -257,14 +347,6 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
 		gpio_set_value_cansleep(lcd->im_pins[2], 1);
 	}
 
-	/* Reset the screen */
-	gpio_set_value(lcd->reset, 1);
-	usleep_range(10000, 12000);
-	gpio_set_value(lcd->reset, 0);
-	usleep_range(10000, 12000);
-	gpio_set_value(lcd->reset, 1);
-	msleep(120);
-
 	ret = hx8357_spi_write_array(lcdev, hx8357_seq_power,
 				ARRAY_SIZE(hx8357_seq_power));
 	if (ret < 0)
@@ -344,6 +426,9 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
 	if (ret < 0)
 		return ret;
 
+	/*
+	 * The controller needs 120ms to fully recover from exiting sleep mode
+	 */
 	msleep(120);
 
 	ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_ON);
@@ -359,6 +444,98 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
 	return 0;
 }
 
+static int hx8369_lcd_init(struct lcd_device *lcdev)
+{
+	int ret;
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_extension_command,
+				ARRAY_SIZE(hx8369_seq_extension_command));
+	if (ret < 0)
+		return ret;
+	usleep_range(10000, 12000);
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_display_related,
+				ARRAY_SIZE(hx8369_seq_display_related));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_panel_waveform_cycle,
+				ARRAY_SIZE(hx8369_seq_panel_waveform_cycle));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_set_address_mode,
+				ARRAY_SIZE(hx8369_seq_set_address_mode));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_vcom,
+				ARRAY_SIZE(hx8369_seq_vcom));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_gip,
+				ARRAY_SIZE(hx8369_seq_gip));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_power,
+				ARRAY_SIZE(hx8369_seq_power));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_byte(lcdev, HX8357_EXIT_SLEEP_MODE);
+	if (ret < 0)
+		return ret;
+
+	/*
+	 * The controller needs 120ms to fully recover from exiting sleep mode
+	 */
+	msleep(120);
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_gamma_curve_related,
+				ARRAY_SIZE(hx8369_seq_gamma_curve_related));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_byte(lcdev, HX8357_EXIT_SLEEP_MODE);
+	if (ret < 0)
+		return ret;
+	usleep_range(1000, 1200);
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_write_CABC_control,
+				ARRAY_SIZE(hx8369_seq_write_CABC_control));
+	if (ret < 0)
+		return ret;
+	usleep_range(10000, 12000);
+
+	ret = hx8357_spi_write_array(lcdev,
+			hx8369_seq_write_CABC_control_setting,
+			ARRAY_SIZE(hx8369_seq_write_CABC_control_setting));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_array(lcdev,
+			hx8369_seq_write_CABC_min_brightness,
+			ARRAY_SIZE(hx8369_seq_write_CABC_min_brightness));
+	if (ret < 0)
+		return ret;
+	usleep_range(10000, 12000);
+
+	ret = hx8357_spi_write_array(lcdev, hx8369_seq_set_display_brightness,
+				ARRAY_SIZE(hx8369_seq_set_display_brightness));
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_ON);
+	if (ret < 0)
+		return ret;
+
+	msleep(100);
+
+	return 0;
+}
+
 #define POWER_IS_ON(pwr)	((pwr) <= FB_BLANK_NORMAL)
 
 static int hx8357_set_power(struct lcd_device *lcdev, int power)
@@ -391,10 +568,24 @@ static struct lcd_ops hx8357_ops = {
 	.get_power	= hx8357_get_power,
 };
 
+static const struct of_device_id hx8357_dt_ids[] = {
+	{
+		.compatible = "himax,hx8357",
+		.data = hx8357_lcd_init,
+	},
+	{
+		.compatible = "himax,hx8369",
+		.data = hx8369_lcd_init,
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, hx8357_dt_ids);
+
 static int hx8357_probe(struct spi_device *spi)
 {
 	struct lcd_device *lcdev;
 	struct hx8357_data *lcd;
+	const struct of_device_id *match;
 	int i, ret;
 
 	lcd = devm_kzalloc(&spi->dev, sizeof(*lcd), GFP_KERNEL);
@@ -411,6 +602,10 @@ static int hx8357_probe(struct spi_device *spi)
 
 	lcd->spi = spi;
 
+	match = of_match_device(hx8357_dt_ids, &spi->dev);
+	if (!match || !match->data)
+		return -EINVAL;
+
 	lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0);
 	if (!gpio_is_valid(lcd->reset)) {
 		dev_err(&spi->dev, "Missing dt property: gpios-reset\n");
@@ -461,7 +656,9 @@ static int hx8357_probe(struct spi_device *spi)
 	}
 	spi_set_drvdata(spi, lcdev);
 
-	ret = hx8357_lcd_init(lcdev);
+	hx8357_lcd_reset(lcdev);
+
+	ret = ((int (*)(struct lcd_device *))match->data)(lcdev);
 	if (ret) {
 		dev_err(&spi->dev, "Couldn't initialize panel\n");
 		goto init_error;
@@ -484,12 +681,6 @@ static int hx8357_remove(struct spi_device *spi)
 	return 0;
 }
 
-static const struct of_device_id hx8357_dt_ids[] = {
-	{ .compatible = "himax,hx8357" },
-	{},
-};
-MODULE_DEVICE_TABLE(of, hx8357_dt_ids);
-
 static struct spi_driver hx8357_driver = {
 	.probe  = hx8357_probe,
 	.remove = hx8357_remove,
-- 
1.8.3.2



From broonie at kernel.org  Thu Jul 25 09:15:56 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 25 Jul 2013 14:15:56 +0100
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <1408178.cxAUTUGJc5@avalon>
References: <1624911.6TtmtVmU1T@avalon>
 <CACRpkdazPX3EbVbLvXQZh0oRBpHoWPK+EkFO75v9zfAXSPCkHA@mail.gmail.com>
 <1408178.cxAUTUGJc5@avalon>
Message-ID: <20130725131556.GD9858@sirena.org.uk>

On Thu, Jul 25, 2013 at 11:45:33AM +0200, Laurent Pinchart wrote:

> The two devices are independent, so there's no real parent/child relationship. 
> However, as Grant proposed, I could list all the interrupts associated with 
> GPIOs in the GPIO controller DT node. I would then just call 
> irq_of_parse_and_map() in the .to_irq() handler to magically translate the 
> GPIO number to a mapped IRQ number.

> The number of interrupts can be pretty high (up to 58 in the worst case so 
> far), so an alternative would be to specify the interrupt-parent only, and 
> call irq_create_of_mapping() directly. What solution would you prefer ?

Are the interrupts in a contiguous block in the controller so you can
just pass around the controller and a base number?
-------------- 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/20130725/7689d8e3/attachment.sig>

From linus.walleij at linaro.org  Thu Jul 25 09:19:32 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Jul 2013 15:19:32 +0200
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <1408178.cxAUTUGJc5@avalon>
References: <1624911.6TtmtVmU1T@avalon>
 <CACRpkdazPX3EbVbLvXQZh0oRBpHoWPK+EkFO75v9zfAXSPCkHA@mail.gmail.com>
 <1408178.cxAUTUGJc5@avalon>
Message-ID: <CACRpkdaNfFqzN0nYPrXd8ZVOFur6W2iEUSM_KErH6eKoiJ7vDQ@mail.gmail.com>

On Thu, Jul 25, 2013 at 11:45 AM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:

> The two devices are independent, so there's no real parent/child relationship.
> However, as Grant proposed, I could list all the interrupts associated with
> GPIOs in the GPIO controller DT node. I would then just call
> irq_of_parse_and_map() in the .to_irq() handler to magically translate the
> GPIO number to a mapped IRQ number.

That works even if the device tree will need a comment or two
to explain what is going on.

I suggested a similar solution for the OMAP crossbar mux
that is discussed in another thread, so I'm happy with this
approach.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Jul 25 09:21:35 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Jul 2013 15:21:35 +0200
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <20130725131556.GD9858@sirena.org.uk>
References: <1624911.6TtmtVmU1T@avalon>
 <CACRpkdazPX3EbVbLvXQZh0oRBpHoWPK+EkFO75v9zfAXSPCkHA@mail.gmail.com>
 <1408178.cxAUTUGJc5@avalon> <20130725131556.GD9858@sirena.org.uk>
Message-ID: <CACRpkdY-mdLbMY16aMqR9Jwu8qs9q4KNyxOxnwhXiGrAAxpKjg@mail.gmail.com>

On Thu, Jul 25, 2013 at 3:15 PM, Mark Brown <broonie at kernel.org> wrote:
> On Thu, Jul 25, 2013 at 11:45:33AM +0200, Laurent Pinchart wrote:
>
>> The number of interrupts can be pretty high (up to 58 in the worst case so
>> far), so an alternative would be to specify the interrupt-parent only, and
>> call irq_create_of_mapping() directly. What solution would you prefer ?
>
> Are the interrupts in a contiguous block in the controller so you can
> just pass around the controller and a base number?

That works with platform data and in-kernel structures, but AFAICT
device tree has no such "bulk" concept but expects you to list
each and every line individually in cases like this.

Yours,
Linus Walleij


From laurent.pinchart at ideasonboard.com  Thu Jul 25 09:22:29 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 25 Jul 2013 15:22:29 +0200
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <20130725131556.GD9858@sirena.org.uk>
References: <1624911.6TtmtVmU1T@avalon> <1408178.cxAUTUGJc5@avalon>
 <20130725131556.GD9858@sirena.org.uk>
Message-ID: <1681089.qGWOhLKTTo@avalon>

Hi Mark,

On Thursday 25 July 2013 14:15:56 Mark Brown wrote:
> On Thu, Jul 25, 2013 at 11:45:33AM +0200, Laurent Pinchart wrote:
> > The two devices are independent, so there's no real parent/child
> > relationship. However, as Grant proposed, I could list all the interrupts
> > associated with GPIOs in the GPIO controller DT node. I would then just
> > call irq_of_parse_and_map() in the .to_irq() handler to magically
> > translate the GPIO number to a mapped IRQ number.
> > 
> > The number of interrupts can be pretty high (up to 58 in the worst case so
> > far), so an alternative would be to specify the interrupt-parent only, and
> > call irq_create_of_mapping() directly. What solution would you prefer ?
> 
> Are the interrupts in a contiguous block in the controller so you can just
> pass around the controller and a base number?

In two of the three SoCs I need to fix they are. I've just realized that in 
the last one the interrupts are in two contiguous blocks in two different 
parents. I will thus need at least a list of <parent-phandle base count>. Our 
standard interrupt bindings don't seem to support multiple parents, is that 
something that we want to fix or should I go for custom bindings ?

-- 
Regards,

Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130725/be41a24f/attachment.sig>

From damien.riegel.ext at parrot.com  Thu Jul 25 09:20:41 2013
From: damien.riegel.ext at parrot.com (Damien Riegel)
Date: Thu, 25 Jul 2013 15:20:41 +0200
Subject: Issue with gpio and pinmux
In-Reply-To: <CACRpkdZdbxEt67+YBKif4-BKAToOmN0_c8HFOdjSG91dtJwJQw@mail.gmail.com>
References: <51E667BC.3070804@parrot.com>	<51E82FBB.1080905@wwwdotorg.org>
 <CACRpkdb1n07KoQZSme1EMJfV-9pHr-kd_1eJ6HsBV5gz7Dh3Ww@mail.gmail.com>
 <51EB590A.4010600@wwwdotorg.org>
 <CACRpkdZdbxEt67+YBKif4-BKAToOmN0_c8HFOdjSG91dtJwJQw@mail.gmail.com>
Message-ID: <51F12629.7090909@parrot.com>

I don't know about pinctrl background but I don't really get why there
is such a distinction between gpio and other functions in most cases.

I understand that on some arch a pin can be muxed and used as a gpio at
the same time. But on most arch, isn't gpio just another function that
can be muxed on a pin, and therefore we should check that a pin can be
requested as a gpio just by checking desc->mux_owner ?


From horms at verge.net.au  Thu Jul 25 09:23:19 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 25 Jul 2013 22:23:19 +0900
Subject: [PATCH v2 1/3] ARM: shmobile: marzen: Switch to DT_MACHINE_START
In-Reply-To: <51F140C8.8070802@cogentembedded.com>
References: <1374718423-24230-1-git-send-email-horms+renesas@verge.net.au>
 <1374718423-24230-2-git-send-email-horms+renesas@verge.net.au>
 <51F140C8.8070802@cogentembedded.com>
Message-ID: <20130725132319.GC30895@verge.net.au>

On Thu, Jul 25, 2013 at 07:14:16PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 25-07-2013 6:13, Simon Horman wrote:
> 
> >From: Magnus Damm <damm at opensource.se>
> 
>    Don't think it makes sense to keep Magnus as an author with so
> many of your added changes. But well, it's your decision...

I am comfortable with things the way they are so long as Magnus is too.

> >Convert the marzen board to use DT_MACHINE_START. With this in
> >place all mach-shmobile boards use DT_MACHINE_START. Also, this
> >makes it possible for the r8a7779 SMP code to use DT for CPUs.
> 
> >So appended DTB is the way forward on this board.
> 
> >Signed-off-by: Magnus Damm <damm at opensource.se>
> >Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> >v2 [Simon Horman]
> >* Select USE_OF in Kconfig
> >* Provide dt_compat in DT_MACHINE_START
> >* Provide r8a7779-marzen dts
> 
> >v1 [Magnus Damm]
> >---
> >  arch/arm/boot/dts/Makefile            |  1 +
> >  arch/arm/boot/dts/r8a7779-marzen.dts  | 27 +++++++++++++++++++++++++++
> 
>    Perhaps arch/arm/boot/dts/ changes should be put into a separate patch?

That sounds reasonable.


From horms at verge.net.au  Thu Jul 25 09:23:34 2013
From: horms at verge.net.au (Simon Horman)
Date: Thu, 25 Jul 2013 22:23:34 +0900
Subject: [PATCH v2 3/3] ARM: shmobile: marzen: Enable ARM_APPENDED_DTB in
 defconfig
In-Reply-To: <51F14216.1010606@cogentembedded.com>
References: <1374718423-24230-1-git-send-email-horms+renesas@verge.net.au>
 <1374718423-24230-4-git-send-email-horms+renesas@verge.net.au>
 <51F14216.1010606@cogentembedded.com>
Message-ID: <20130725132334.GD30895@verge.net.au>

On Thu, Jul 25, 2013 at 07:19:50PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 25-07-2013 6:13, Simon Horman wrote:
> 
> >"ARM: shmobile: marzen: Switch to DT_MACHINE_START" moves marzen
> >over to use DT_MACHINE_START, however, the prevelant boot loader
> 
>    s/prevelant/prevalent/?

Thanks, I will fix that.

> >does not support booting with a separate dtb. Thus, it makes
> >sense to use ARM_APPENDED_DTB by default.
> 
> >This is consistent with other shmobile defconfigs.
> 
> >Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> WBR, Sergei
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From linus.walleij at linaro.org  Thu Jul 25 09:24:08 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Jul 2013 15:24:08 +0200
Subject: Issue with gpio and pinmux
In-Reply-To: <51F12629.7090909@parrot.com>
References: <51E667BC.3070804@parrot.com> <51E82FBB.1080905@wwwdotorg.org>
 <CACRpkdb1n07KoQZSme1EMJfV-9pHr-kd_1eJ6HsBV5gz7Dh3Ww@mail.gmail.com>
 <51EB590A.4010600@wwwdotorg.org>
 <CACRpkdZdbxEt67+YBKif4-BKAToOmN0_c8HFOdjSG91dtJwJQw@mail.gmail.com>
 <51F12629.7090909@parrot.com>
Message-ID: <CACRpkdb-hVE1Jj69ttrn+zf5cEuMHhxNh2OyhfTtrG+yUiO+jg@mail.gmail.com>

On Thu, Jul 25, 2013 at 3:20 PM, Damien Riegel
<damien.riegel.ext at parrot.com> wrote:

> I don't know about pinctrl background but I don't really get why there
> is such a distinction between gpio and other functions in most cases.
>
> I understand that on some arch a pin can be muxed and used as a gpio at
> the same time. But on most arch, isn't gpio just another function that
> can be muxed on a pin, and therefore we should check that a pin can be
> requested as a gpio just by checking desc->mux_owner ?

Does this recently submitted documentation patch help in explaining
some of your questions?
http://marc.info/?l=linux-kernel&m=137442899829271&w=2

Yours,
Linus Walleij


From oleksandr.kozaruk at ti.com  Thu Jul 25 09:26:51 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Thu, 25 Jul 2013 16:26:51 +0300
Subject: [PATCH v8 0/2] TWL6030, TWL6032 GPADC driver
Message-ID: <1374758813-6539-1-git-send-email-oleksandr.kozaruk@ti.com>

Hello,

v8 - removed unused test channels completely, removed die
     temperature channels, as it is not known how to convert ADC code
     to temperature. There if formula for twl6030, but no formula
     for twl6032.
v7 - addressed clean up comments, removed test channels
v6 - addressed comments about trim bits, checkpatch clean up
v5 - gpadc DT node renamed from "gpadc" to generic "adc", added
     temperature channels; raw code is corracted with calibration
     data.
v4 - addressed comments: fixed style violation, bug in freeing memory,
     added comments explaining calibration method, removed test network
     channels from exposing to userspace, error handling for 
     wait_for_complition
v3 - fixed compiler warning
v2 - the driver put in drivers/iio, and
converted using iio facilities as suggested by Graeme.

TWL603[02] GPADC is used to measure battery voltage,
battery temperature, battery presence ID, and could
be used to measure twl603[02] die temperature.
This is used on TI blaze, blaze tablet platforms.

The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19
channels respectively. Some channels have current
source and are used for measuring voltage drop
on resistive load for detecting battery ID resistance,
or measuring voltage drop on NTC resistors for external
temperature measurements, other channels measure voltage,
(i.e. battery voltage), and have inbuilt voltage dividers,
thus, capable to scale voltage. Some channels are dedicated
for measuring die temperature.

Some channels could be calibrated in 2 points, having
offsets from ideal values in trim registers.

The difference between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i. e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

The driver is derived from git://git.omapzoom.org/kernel/omap.git
The original driver's authors and contributors are Balaji T K,
Graeme Gregory, Ambresh K, Girish S Ghongdemath.

The changes to the original driver:
- device tree adaptation;
- drop ioctl support - never been used;
- unified measurement method for both devices;
- get rid of "if (device == X)" code style to data driven;
- drop polling end of conversion and use interrupt instead;
- iio framework is used

Tested with on blaze tablet 2 with OMAP4430(twl6030), and
OMAP4470(twl6032) SOMs.

The patches were tested against 3.11-rc2


Oleksandr Kozaruk (2):
  ARM: dts: twl: Add GPADC data to device tree
  iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

 arch/arm/boot/dts/twl6030.dtsi  |    6 +
 drivers/iio/adc/Kconfig         |   14 +
 drivers/iio/adc/Makefile        |    1 +
 drivers/iio/adc/twl6030-gpadc.c | 1027 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 1048 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

-- 
1.8.1.2



From oleksandr.kozaruk at ti.com  Thu Jul 25 09:26:52 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Thu, 25 Jul 2013 16:26:52 +0300
Subject: [PATCH v8 1/2] ARM: dts: twl: Add GPADC data to device tree
In-Reply-To: <1374758813-6539-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1374758813-6539-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1374758813-6539-2-git-send-email-oleksandr.kozaruk@ti.com>

GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.

Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..b78e1d5 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
 		compatible = "ti,twl6030-pwmled";
 		#pwm-cells = <2>;
 	};
+
+	adc {
+		compatible = "ti,twl6030-gpadc";
+		interrupts = <3>;
+		#io-channel-cells = <1>;
+	};
 };
-- 
1.8.1.2



From oleksandr.kozaruk at ti.com  Thu Jul 25 09:26:53 2013
From: oleksandr.kozaruk at ti.com (Oleksandr Kozaruk)
Date: Thu, 25 Jul 2013 16:26:53 +0300
Subject: [PATCH v8 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
In-Reply-To: <1374758813-6539-1-git-send-email-oleksandr.kozaruk@ti.com>
References: <1374758813-6539-1-git-send-email-oleksandr.kozaruk@ti.com>
Message-ID: <1374758813-6539-3-git-send-email-oleksandr.kozaruk@ti.com>

The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
known also as Phoenix and PhoenixLite.

The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
respectively. Some channels have current source and are used for
measuring voltage drop on resistive load for detecting battery ID
resistance, or measuring voltage drop on NTC resistors for external
temperature measurements. Some channels measure voltage, (i.e. battery
voltage), and have voltage dividers, thus, capable to scale voltage.
Some channels are dedicated for measuring die temperature.

Some channels are calibrated in 2 points, having offsets from ideal
values kept in trim registers. This is used to correct measurements.

The differences between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i.e. battery voltage
  channel 8 vs channel 18);
- trim values are interpreted differently.

Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
Girish S Ghongdemath.

Signed-off-by: Balaji T K <balajitk at ti.com>
Signed-off-by: Graeme Gregory <gg at slimlogic.co.uk>
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk at ti.com>
---
 drivers/iio/adc/Kconfig         |   14 +
 drivers/iio/adc/Makefile        |    1 +
 drivers/iio/adc/twl6030-gpadc.c | 1027 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 1042 insertions(+)
 create mode 100644 drivers/iio/adc/twl6030-gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 93129ec..f8f9f18 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -160,6 +160,20 @@ config TI_AM335X_ADC
 	  Say yes here to build support for Texas Instruments ADC
 	  driver which is also a MFD client.
 
+config TWL6030_GPADC
+	tristate "TWL6030 GPADC (General Purpose A/D Converter) Support"
+	depends on TWL4030_CORE
+	default n
+	help
+	  Say yes here if you want support for the TWL6030/TWL6032 General
+	  Purpose A/D Converter. This will add support for battery type
+	  detection, battery voltage and temperature measurement, die
+	  temperature measurement, system supply voltage, audio accessory,
+	  USB ID detection.
+
+	  This driver can also be built as a module. If so, the module will be
+	  called twl6030-gpadc.
+
 config VIPERBOARD_ADC
 	tristate "Viperboard ADC support"
 	depends on MFD_VIPERBOARD && USB
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 8f475d3..db430bd 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -17,4 +17,5 @@ obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
 obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
+obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
 obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c
new file mode 100644
index 0000000..2b63083
--- /dev/null
+++ b/drivers/iio/adc/twl6030-gpadc.c
@@ -0,0 +1,1027 @@
+/*
+ * TWL6030 GPADC module driver
+ *
+ * Copyright (C) 2009-2013 Texas Instruments Inc.
+ * Nishant Kamat <nskamat at ti.com>
+ * Balaji T K <balajitk at ti.com>
+ * Graeme Gregory <gg at slimlogic.co.uk>
+ * Girish S Ghongdemath <girishsg at ti.com>
+ * Ambresh K <ambresh at ti.com>
+ * Oleksandr Kozaruk <oleksandr.kozaruk at ti.com
+ *
+ * Based on twl4030-madc.c
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen <mikko.k.ylinen at nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of_platform.h>
+#include <linux/i2c/twl.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define DRIVER_NAME		"twl6030_gpadc"
+
+/*
+ * twl6030 per TRM has 17 channels, and twl6032 has 19 channels
+ * 2 test network channels are not used,
+ * 2 die temperature channels are not used either, as it is not
+ * defined how to convert ADC value to temperature
+ */
+#define TWL6030_GPADC_USED_CHANNELS		13
+#define TWL6030_GPADC_MAX_CHANNELS		15
+#define TWL6032_GPADC_USED_CHANNELS		15
+#define TWL6032_GPADC_MAX_CHANNELS		19
+#define TWL6030_GPADC_NUM_TRIM_REGS		16
+
+#define TWL6030_GPADC_CTRL_P1			0x05
+
+#define TWL6032_GPADC_GPSELECT_ISB		0x07
+#define TWL6032_GPADC_CTRL_P1			0x08
+
+#define TWL6032_GPADC_GPCH0_LSB			0x0d
+#define TWL6032_GPADC_GPCH0_MSB			0x0e
+
+#define TWL6030_GPADC_CTRL_P1_SP1		BIT(3)
+
+#define TWL6030_GPADC_GPCH0_LSB			(0x29)
+
+#define TWL6030_GPADC_RT_SW1_EOC_MASK		BIT(5)
+
+#define TWL6030_GPADC_TRIM1			0xCD
+
+#define TWL6030_REG_TOGGLE1			0x90
+#define TWL6030_GPADCS				BIT(1)
+#define TWL6030_GPADCR				BIT(0)
+
+/**
+ * struct twl6030_chnl_calib - channel calibration
+ * @gain:		slope coefficient for ideal curve
+ * @gain_error:		gain error
+ * @offset_error:	offset of the real curve
+ */
+struct twl6030_chnl_calib {
+	s32 gain;
+	s32 gain_error;
+	s32 offset_error;
+};
+
+/**
+ * struct twl6030_ideal_code - GPADC calibration parameters
+ * GPADC is calibrated in two points: close to the beginning and
+ * to the and of the measurable input range
+ *
+ * @channel:	channel number
+ * @code1:	ideal code for the input at the beginning
+ * @code2:	ideal code for at the end of the range
+ * @volt1:	voltage input at the beginning(low voltage)
+ * @volt2:	voltage input at the end(high voltage)
+ */
+struct twl6030_ideal_code {
+	int channel;
+	u16 code1;
+	u16 code2;
+	u16 volt1;
+	u16 volt2;
+};
+
+struct twl6030_gpadc_data;
+
+/**
+ * struct twl6030_gpadc_platform_data - platform specific data
+ * @nchannels:		number of GPADC channels
+ * @iio_channels:	iio channels
+ * @twl6030_ideal:	pointer to calibration parameters
+ * @start_conversion:	pointer to ADC start conversion function
+ * @channel_to_reg	pointer to ADC function to convert channel to
+ *			register address for reading conversion result
+ * @calibrate:		pointer to calibration function
+ */
+struct twl6030_gpadc_platform_data {
+	const int nchannels;
+	const struct iio_chan_spec *iio_channels;
+	const struct twl6030_ideal_code *ideal;
+	int (*start_conversion)(int channel);
+	u8 (*channel_to_reg)(int channel);
+	int (*calibrate)(struct twl6030_gpadc_data *gpadc);
+};
+
+/**
+ * struct twl6030_gpadc_data - GPADC data
+ * @dev:		device pointer
+ * @lock:		mutual exclusion lock for the structure
+ * @irq_complete:	completion to signal end of conversion
+ * @twl6030_cal_tbl:	pointer to calibration data for each
+ *			channel with gain error and offset
+ * @pdata:		pointer to device specific data
+ */
+struct twl6030_gpadc_data {
+	struct device	*dev;
+	struct mutex	lock;
+	struct completion	irq_complete;
+	struct twl6030_chnl_calib	*twl6030_cal_tbl;
+	const struct twl6030_gpadc_platform_data *pdata;
+};
+
+/*
+ * channels 11, 12, 13, 15 and 16 have no calibration data
+ * calibration offset is same for channels 1, 3, 4, 5
+ *
+ * The data is taken from GPADC_TRIM registers description.
+ * GPADC_TRIM registers keep difference between the code measured
+ * at volt1 and volt2 input voltages and corresponding code1 and code2
+ */
+static const struct twl6030_ideal_code
+	twl6030_ideal[TWL6030_GPADC_USED_CHANNELS] = {
+	[0] = { /* ch 0, external, battery type, resistor value */
+		.channel = 0,
+		.code1 = 116,
+		.code2 = 745,
+		.volt1 = 141,
+		.volt2 = 910,
+	},
+	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
+		.channel = 1,
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[2] = { /* ch 2, external, audio accessory/general purpose */
+		.channel = 2,
+		.code1 = 55,
+		.code2 = 818,
+		.volt1 = 101,
+		.volt2 = 1499,
+	},
+	[3] = { /* ch 3, external, general purpose */
+		.channel = 3,
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[4] = { /* ch 4, external, temperature measurement/general purpose */
+		.channel = 4,
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[5] = { /* ch 5, external, general purpose */
+		.channel = 5,
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[6] = { /* ch 6, external, general purpose */
+		.channel = 6,
+		.code1 = 82,
+		.code2 = 900,
+		.volt1 = 100,
+		.volt2 = 1100,
+	},
+	[7] = { /* ch 7, internal, main battery */
+		.channel = 7,
+		.code1 = 614,
+		.code2 = 941,
+		.volt1 = 3001,
+		.volt2 = 4599,
+	},
+	[8] = { /* ch 8, internal, backup battery */
+		.channel = 8,
+		.code1 = 82,
+		.code2 = 688,
+		.volt1 = 501,
+		.volt2 = 4203,
+	},
+	[9] = { /* ch 9, internal, external charger input */
+		.channel = 9,
+		.code1 = 182,
+		.code2 = 818,
+		.volt1 = 2001,
+		.volt2 = 8996,
+	},
+	[10] = { /* ch 10, internal, VBUS */
+		.channel = 10,
+		.code1 = 149,
+		.code2 = 818,
+		.volt1 = 1001,
+		.volt2 = 5497,
+	},
+	[11] = { /* ch 11, internal, VBUS charging current */
+		.channel = 11,
+	},
+		/* ch 12, internal, Die temperature */
+		/* ch 13, internal, Die temperature */
+	[12] = { /* ch 14, internal, USB ID line */
+		.channel = 14,
+		.code1 = 48,
+		.code2 = 714,
+		.volt1 = 323,
+		.volt2 = 4800,
+	},
+};
+
+static const struct twl6030_ideal_code
+			twl6032_ideal[TWL6032_GPADC_USED_CHANNELS] = {
+	[0] = { /* ch 0, external, battery type, resistor value */
+		.channel = 0,
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[1] = { /* ch 1, external, battery temperature, NTC resistor value */
+		.channel = 1,
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[2] = { /* ch 2, external, audio accessory/general purpose */
+		.channel = 2,
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 660,
+		.volt2 = 1500,
+	},
+	[3] = { /* ch 3, external, temperature with external diode/general
+								purpose */
+		.channel = 3,
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[4] = { /* ch 4, external, temperature measurement/general purpose */
+		.channel = 4,
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[5] = { /* ch 5, external, general purpose */
+		.channel = 5,
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[6] = { /* ch 6, external, general purpose */
+		.channel = 6,
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 440,
+		.volt2 = 1000,
+	},
+	[7] = { /* ch7, internal, system supply */
+		.channel = 7,
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+	[8] = { /* ch8, internal, backup battery */
+		.channel = 8,
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+	[9] = { /* ch 9, internal, external charger input */
+		.channel = 9,
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 3960,
+		.volt2 = 9000,
+	},
+	[10] = { /* ch10, internal, VBUS */
+		.channel = 10,
+		.code1 = 150,
+		.code2 = 751,
+		.volt1 = 1000,
+		.volt2 = 5000,
+	},
+	[11] = { /* ch 11, internal, VBUS DC-DC output current */
+		.channel = 11,
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 660,
+		.volt2 = 1500,
+	},
+		/* ch 12, internal, Die temperature */
+		/* ch 13, internal, Die temperature */
+	[12] = { /* ch 14, internal, USB ID line */
+		.channel = 14,
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2420,
+		.volt2 = 5500,
+	},
+		/* ch 15, internal, test network */
+		/* ch 16, internal, test network */
+	[13] = { /* ch 17, internal, battery charging current */
+		.channel = 17,
+	},
+	[14] = { /* ch 18, internal, battery voltage */
+		.channel = 18,
+		.code1 = 1441,
+		.code2 = 3276,
+		.volt1 = 2200,
+		.volt2 = 5000,
+	},
+};
+
+static inline int twl6030_gpadc_write(u8 reg, u8 val)
+{
+	return twl_i2c_write_u8(TWL6030_MODULE_GPADC, val, reg);
+}
+
+static inline int twl6030_gpadc_read(u8 reg, u8 *val)
+{
+
+	return twl_i2c_read(TWL6030_MODULE_GPADC, val, reg, 2);
+}
+
+static int twl6030_gpadc_enable_irq(u8 mask)
+{
+	int ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_LINE_B);
+	if (ret < 0)
+		return ret;
+
+	ret = twl6030_interrupt_unmask(mask, REG_INT_MSK_STS_B);
+
+	return ret;
+}
+
+static void twl6030_gpadc_disable_irq(u8 mask)
+{
+	twl6030_interrupt_mask(mask, REG_INT_MSK_LINE_B);
+	twl6030_interrupt_mask(mask, REG_INT_MSK_STS_B);
+}
+
+static irqreturn_t twl6030_gpadc_irq_handler(int irq, void *indio_dev)
+{
+	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
+
+	complete(&gpadc->irq_complete);
+
+	return IRQ_HANDLED;
+}
+
+static int twl6030_start_conversion(int channel)
+{
+	return twl6030_gpadc_write(TWL6030_GPADC_CTRL_P1,
+					TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static int twl6032_start_conversion(int channel)
+{
+	int ret;
+
+	ret = twl6030_gpadc_write(TWL6032_GPADC_GPSELECT_ISB, channel);
+	if (ret)
+		return ret;
+
+	return twl6030_gpadc_write(TWL6032_GPADC_CTRL_P1,
+						TWL6030_GPADC_CTRL_P1_SP1);
+}
+
+static u8 twl6030_channel_to_reg(int channel)
+{
+	return TWL6030_GPADC_GPCH0_LSB + 2 * channel;
+}
+
+static u8 twl6032_channel_to_reg(int channel)
+{
+	/*
+	 * for any prior chosen channel, when the conversion is ready
+	 * the result is avalable in GPCH0_LSB, GPCH0_MSB.
+	 */
+
+	return TWL6032_GPADC_GPCH0_LSB;
+}
+
+static int twl6030_gpadc_lookup(const struct twl6030_ideal_code *ideal,
+		int channel, int size)
+{
+	int i;
+
+	for (i = 0; i < size; i++)
+		if (ideal[i].channel == channel)
+			break;
+
+	return i;
+}
+
+static int twl6030_channel_calibrated(const struct twl6030_gpadc_platform_data
+		*pdata, int channel)
+{
+	const struct twl6030_ideal_code *ideal = pdata->ideal;
+	int i;
+
+	i = twl6030_gpadc_lookup(ideal, channel, pdata->nchannels);
+	/* not calibrated channels have 0 in all structure members */
+	return pdata->ideal[i].code2;
+}
+
+static int twl6030_gpadc_make_correction(struct twl6030_gpadc_data *gpadc,
+		int channel, int raw_code)
+{
+	const struct twl6030_ideal_code *ideal = gpadc->pdata->ideal;
+	int corrected_code;
+	int i;
+
+	i = twl6030_gpadc_lookup(ideal, channel, gpadc->pdata->nchannels);
+	corrected_code = ((raw_code * 1000) -
+		gpadc->twl6030_cal_tbl[i].offset_error) /
+		gpadc->twl6030_cal_tbl[i].gain_error;
+
+	return corrected_code;
+}
+
+static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
+		int channel, int *res)
+{
+	u8 reg = gpadc->pdata->channel_to_reg(channel);
+	__le16 val;
+	int raw_code;
+	int ret;
+
+	ret = twl6030_gpadc_read(reg, (u8 *)&val);
+	if (ret) {
+		dev_dbg(gpadc->dev, "unable to read register 0x%X\n", reg);
+		return ret;
+	}
+
+	raw_code = le16_to_cpu(val);
+	dev_dbg(gpadc->dev, "GPADC raw code: %d", raw_code);
+
+	if (twl6030_channel_calibrated(gpadc->pdata, channel))
+		*res = twl6030_gpadc_make_correction(gpadc, channel, raw_code);
+	else
+		*res = raw_code;
+
+	return ret;
+}
+
+static int twl6030_gpadc_get_processed(struct twl6030_gpadc_data *gpadc,
+		int channel, int *val)
+{
+	const struct twl6030_ideal_code *ideal = gpadc->pdata->ideal;
+	int corrected_code;
+	int channel_value;
+	int i;
+	int ret;
+
+	ret = twl6030_gpadc_get_raw(gpadc, channel, &corrected_code);
+	if (ret)
+		return ret;
+
+	i = twl6030_gpadc_lookup(ideal, channel, gpadc->pdata->nchannels);
+	channel_value = corrected_code *
+			gpadc->twl6030_cal_tbl[i].gain;
+
+	/* Shift back into mV range */
+	channel_value /= 1000;
+
+	dev_dbg(gpadc->dev, "GPADC corrected code: %d", corrected_code);
+	dev_dbg(gpadc->dev, "GPADC value: %d", channel_value);
+
+	*val = channel_value;
+
+	return ret;
+}
+
+static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
+			     const struct iio_chan_spec *chan,
+			     int *val, int *val2, long mask)
+{
+	struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
+	int ret;
+	long timeout;
+
+	mutex_lock(&gpadc->lock);
+
+	ret = gpadc->pdata->start_conversion(chan->channel);
+	if (ret) {
+		dev_err(gpadc->dev, "failed to start conversion\n");
+		goto err;
+	}
+	/* wait for conversion to complete */
+	timeout = wait_for_completion_interruptible_timeout(
+				&gpadc->irq_complete, msecs_to_jiffies(5000));
+	if (timeout == 0) {
+		ret = -ETIMEDOUT;
+		goto err;
+	} else if (timeout < 0) {
+		goto err;
+		ret = -EINTR;
+	}
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		ret = twl6030_gpadc_get_raw(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	case IIO_CHAN_INFO_PROCESSED:
+		ret = twl6030_gpadc_get_processed(gpadc, chan->channel, val);
+		ret = ret ? -EIO : IIO_VAL_INT;
+		break;
+
+	default:
+		break;
+	}
+err:
+	mutex_unlock(&gpadc->lock);
+
+	return ret;
+}
+
+/*
+ * The GPADC channels are calibrated using a two point calibration method.
+ * The channels measured with two known values: volt1 and volt2, and
+ * ideal corresponding output codes are known: code1, code2.
+ * The difference(d1, d2) between ideal and measured codes stored in trim
+ * registers.
+ * The goal is to find offset and gain of the real curve for each calibrated
+ * channel.
+ * gain: k = 1 + ((d2 - d1) / (x2 - x1))
+ * offset: b = d1 + (k - 1) * x1
+ */
+static void twl6030_calibrate_channel(struct twl6030_gpadc_data *gpadc,
+		int channel, int d1, int d2)
+{
+	int b, k, gain, x1, x2, i;
+	const struct twl6030_ideal_code *ideal = gpadc->pdata->ideal;
+
+	i = twl6030_gpadc_lookup(ideal, channel, gpadc->pdata->nchannels);
+
+	/* Gain */
+	gain = ((ideal[i].volt2 - ideal[i].volt1) * 1000) /
+		(ideal[i].code2 - ideal[i].code1);
+
+	x1 = ideal[i].code1;
+	x2 = ideal[i].code2;
+
+	/* k - real curve gain */
+	k = 1000 + (((d2 - d1) * 1000) / (x2 - x1));
+
+	/* b - offset of the real curve gain */
+	b = (d1 * 1000) - (k - 1000) * x1;
+
+	gpadc->twl6030_cal_tbl[i].gain = gain;
+	gpadc->twl6030_cal_tbl[i].gain_error = k;
+	gpadc->twl6030_cal_tbl[i].offset_error = b;
+
+	dev_dbg(gpadc->dev, "GPADC d1   for Chn: %d = %d\n", channel, d1);
+	dev_dbg(gpadc->dev, "GPADC d2   for Chn: %d = %d\n", channel, d2);
+	dev_dbg(gpadc->dev, "GPADC x1   for Chn: %d = %d\n", channel, x1);
+	dev_dbg(gpadc->dev, "GPADC x2   for Chn: %d = %d\n", channel, x2);
+	dev_dbg(gpadc->dev, "GPADC Gain for Chn: %d = %d\n", channel, gain);
+	dev_dbg(gpadc->dev, "GPADC k    for Chn: %d = %d\n", channel, k);
+	dev_dbg(gpadc->dev, "GPADC b    for Chn: %d = %d\n", channel, b);
+}
+
+static inline int twl6030_gpadc_get_trim_offset(s8 d)
+{
+	/*
+	 * XXX NOTE!
+	 * bit 0 - sign, bit 7 - reserved, 6..1 - trim value
+	 * though, the documentation states that trim value
+	 * is absolute value, the correct conversion results are
+	 * obtained if the value is interpreted as 2's complement.
+	 */
+	__u32 temp = ((d & 0x7f) >> 1) | ((d & 1) << 6);
+
+	return sign_extend32(temp, 6);
+}
+
+static int twl6030_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int ret;
+	int chn;
+	u8 trim_regs[TWL6030_GPADC_NUM_TRIM_REGS];
+	s8 d1, d2;
+
+	/*
+	 * for calibration two measurements have been performed at
+	 * factory, for some channels, during the production test and
+	 * have been stored in registers. This two stored values are
+	 * used to correct the measurements. The values represent
+	 * offsets for the given input from the output on ideal curve.
+	 */
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs,
+			TWL6030_GPADC_TRIM1, TWL6030_GPADC_NUM_TRIM_REGS);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	for (chn = 0; chn < TWL6030_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+			d1 = trim_regs[0];
+			d2 = trim_regs[1];
+			break;
+		case 1:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+			d1 = trim_regs[4];
+			d2 = trim_regs[5];
+			break;
+		case 2:
+			d1 = trim_regs[12];
+			d2 = trim_regs[13];
+			break;
+		case 7:
+			d1 = trim_regs[6];
+			d2 = trim_regs[7];
+			break;
+		case 8:
+			d1 = trim_regs[2];
+			d2 = trim_regs[3];
+			break;
+		case 9:
+			d1 = trim_regs[8];
+			d2 = trim_regs[9];
+			break;
+		case 10:
+			d1 = trim_regs[10];
+			d2 = trim_regs[11];
+			break;
+		case 14:
+			d1 = trim_regs[14];
+			d2 = trim_regs[15];
+			break;
+		default:
+			continue;
+		}
+
+		d1 = twl6030_gpadc_get_trim_offset(d1);
+		d2 = twl6030_gpadc_get_trim_offset(d2);
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+static int twl6032_get_trim_value(u8 *trim_regs, unsigned int reg0,
+		unsigned int reg1, unsigned int mask0, unsigned int mask1,
+		unsigned int shift0)
+{
+	int val;
+
+	val = (trim_regs[reg0] & mask0) << shift0;
+	val |= (trim_regs[reg1] & mask1) >> 1;
+	if (trim_regs[reg1] & 0x01)
+		val = -val;
+
+	return val;
+}
+
+static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
+{
+	int chn, d1 = 0, d2 = 0, temp;
+	u8 trim_regs[TWL6030_GPADC_NUM_TRIM_REGS];
+	int ret;
+
+	ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs,
+			TWL6030_GPADC_TRIM1, TWL6030_GPADC_NUM_TRIM_REGS);
+	if (ret < 0) {
+		dev_err(gpadc->dev, "calibration failed\n");
+		return ret;
+	}
+
+	/*
+	 * Loop to calculate the value needed for returning voltages from
+	 * GPADC not values.
+	 *
+	 * gain is calculated to 3 decimal places fixed point.
+	 */
+	for (chn = 0; chn < TWL6032_GPADC_MAX_CHANNELS; chn++) {
+
+		switch (chn) {
+		case 0:
+		case 1:
+		case 2:
+		case 3:
+		case 4:
+		case 5:
+		case 6:
+		case 11:
+		case 14:
+			d1 = twl6032_get_trim_value(trim_regs, 2, 0, 0x1f,
+								0x06, 2);
+			d2 = twl6032_get_trim_value(trim_regs, 3, 1, 0x3f,
+								0x06, 2);
+			break;
+		case 8:
+			temp = twl6032_get_trim_value(trim_regs, 2, 0, 0x1f,
+								0x06, 2);
+			d1 = temp + twl6032_get_trim_value(trim_regs, 7, 6,
+								0x18, 0x1E, 1);
+
+			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x3F,
+								0x06, 2);
+			d2 = temp + twl6032_get_trim_value(trim_regs, 9, 7,
+								0x1F, 0x06, 2);
+			break;
+		case 9:
+			temp = twl6032_get_trim_value(trim_regs, 2, 0, 0x1f,
+								0x06, 2);
+			d1 = temp + twl6032_get_trim_value(trim_regs, 13, 11,
+								0x18, 0x1E, 1);
+
+			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x3f,
+								0x06, 2);
+			d2 = temp + twl6032_get_trim_value(trim_regs, 15, 13,
+								0x1F, 0x06, 1);
+			break;
+		case 10:
+			d1 = twl6032_get_trim_value(trim_regs, 10, 8, 0x0f,
+								0x0E, 3);
+			d2 = twl6032_get_trim_value(trim_regs, 14, 12, 0x0f,
+								0x0E, 3);
+			break;
+		case 7:
+		case 18:
+			temp = twl6032_get_trim_value(trim_regs, 2, 0, 0x1f,
+								0x06, 2);
+
+			d1 = (trim_regs[4] & 0x7E) >> 1;
+			if (trim_regs[4] & 0x01)
+				d1 = -d1;
+			d1 += temp;
+
+			temp = twl6032_get_trim_value(trim_regs, 3, 1, 0x3f,
+								0x06, 2);
+
+			d2 = (trim_regs[5] & 0xFE) >> 1;
+			if (trim_regs[5] & 0x01)
+				d2 = -d2;
+
+			d2 += temp;
+			break;
+		default:
+			/* No data for other channels */
+			continue;
+		}
+
+		twl6030_calibrate_channel(gpadc, chn, d1, d2);
+	}
+
+	return 0;
+}
+
+#define TWL6030_GPADC_CHAN(chn, _type, chan_info) {	\
+	.type = _type,					\
+	.channel = chn,					\
+	.info_mask_separate = BIT(chan_info),		\
+	.indexed = 1,					\
+}
+
+static const struct iio_chan_spec twl6030_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(2, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(5, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(14, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+};
+
+static const struct iio_chan_spec twl6032_gpadc_iio_channels[] = {
+	TWL6030_GPADC_CHAN(0, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(1, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(2, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(3, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(4, IIO_TEMP, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(5, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(6, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(7, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(8, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(9, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(10, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(11, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(14, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+	TWL6030_GPADC_CHAN(17, IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+	TWL6030_GPADC_CHAN(18, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
+};
+
+static const struct iio_info twl6030_gpadc_iio_info = {
+	.read_raw = &twl6030_gpadc_read_raw,
+	.driver_module = THIS_MODULE,
+};
+
+static const struct twl6030_gpadc_platform_data twl6030_pdata = {
+	.iio_channels = twl6030_gpadc_iio_channels,
+	.nchannels = TWL6030_GPADC_USED_CHANNELS,
+	.ideal = twl6030_ideal,
+	.start_conversion = twl6030_start_conversion,
+	.channel_to_reg = twl6030_channel_to_reg,
+	.calibrate = twl6030_calibration,
+};
+
+static const struct twl6030_gpadc_platform_data twl6032_pdata = {
+	.iio_channels = twl6032_gpadc_iio_channels,
+	.nchannels = TWL6032_GPADC_USED_CHANNELS,
+	.ideal = twl6032_ideal,
+	.start_conversion = twl6032_start_conversion,
+	.channel_to_reg = twl6032_channel_to_reg,
+	.calibrate = twl6032_calibration,
+};
+
+static const struct of_device_id of_twl6030_match_tbl[] = {
+	{
+		.compatible = "ti,twl6030-gpadc",
+		.data = &twl6030_pdata,
+	},
+	{
+		.compatible = "ti,twl6032-gpadc",
+		.data = &twl6032_pdata,
+	},
+	{ /* end */ }
+};
+
+static int twl6030_gpadc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct twl6030_gpadc_data *gpadc;
+	const struct twl6030_gpadc_platform_data *pdata;
+	const struct of_device_id *match;
+	struct iio_dev *indio_dev;
+	int irq;
+	int ret;
+
+	match = of_match_device(of_match_ptr(of_twl6030_match_tbl), dev);
+	if (!match)
+		return -EINVAL;
+
+	pdata = match->data;
+
+	indio_dev = iio_device_alloc(sizeof(*gpadc));
+	if (!indio_dev) {
+		dev_err(dev, "failed allocating iio device\n");
+		ret = -ENOMEM;
+	}
+
+	gpadc = iio_priv(indio_dev);
+
+	gpadc->twl6030_cal_tbl = devm_kzalloc(dev,
+					sizeof(*gpadc->twl6030_cal_tbl) *
+					pdata->nchannels, GFP_KERNEL);
+	if (!gpadc->twl6030_cal_tbl)
+		goto err_free_device;
+
+	gpadc->dev = dev;
+	gpadc->pdata = pdata;
+
+	platform_set_drvdata(pdev, indio_dev);
+	mutex_init(&gpadc->lock);
+	init_completion(&gpadc->irq_complete);
+
+	ret = pdata->calibrate(gpadc);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to read calibration registers\n");
+		goto err_free_device;
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "failed to get irq\n");
+		goto err_free_device;
+	}
+
+	ret = request_threaded_irq(irq, NULL, twl6030_gpadc_irq_handler,
+				IRQF_ONESHOT, "twl6030_gpadc", indio_dev);
+	if (ret) {
+		dev_dbg(&pdev->dev, "could not request irq\n");
+		goto err_free_device;
+	}
+
+	ret = twl6030_gpadc_enable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC interrupt\n");
+		goto err_free_irq;
+	}
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+					TWL6030_REG_TOGGLE1);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to enable GPADC module\n");
+		goto err_free_irq;
+	}
+
+	indio_dev->name = DRIVER_NAME;
+	indio_dev->dev.parent = dev;
+	indio_dev->info = &twl6030_gpadc_iio_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->channels = pdata->iio_channels;
+	indio_dev->num_channels = pdata->nchannels;
+
+	ret = iio_device_register(indio_dev);
+	if (ret)
+		goto err_free_irq;
+
+	return ret;
+
+err_free_irq:
+	free_irq(irq, indio_dev);
+err_free_device:
+	iio_device_free(indio_dev);
+
+	return ret;
+}
+
+static int twl6030_gpadc_remove(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+
+	twl6030_gpadc_disable_irq(TWL6030_GPADC_RT_SW1_EOC_MASK);
+	free_irq(platform_get_irq(pdev, 0), indio_dev);
+	iio_device_unregister(indio_dev);
+	iio_device_free(indio_dev);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int twl6030_gpadc_suspend(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCR,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error reseting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+
+static int twl6030_gpadc_resume(struct device *pdev)
+{
+	int ret;
+
+	ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, TWL6030_GPADCS,
+				TWL6030_REG_TOGGLE1);
+	if (ret)
+		dev_err(pdev, "error setting GPADC (%d)!\n", ret);
+
+	return 0;
+};
+#endif
+
+static SIMPLE_DEV_PM_OPS(twl6030_gpadc_pm_ops, twl6030_gpadc_suspend,
+					twl6030_gpadc_resume);
+
+static struct platform_driver twl6030_gpadc_driver = {
+	.probe		= twl6030_gpadc_probe,
+	.remove		= twl6030_gpadc_remove,
+	.driver		= {
+		.name	= DRIVER_NAME,
+		.owner	= THIS_MODULE,
+		.pm	= &twl6030_gpadc_pm_ops,
+		.of_match_table = of_twl6030_match_tbl,
+	},
+};
+
+module_platform_driver(twl6030_gpadc_driver);
+
+MODULE_ALIAS("platform: " DRIVER_NAME);
+MODULE_AUTHOR("Balaji T K <balajitk at ti.com>, Graeme Gregory <gg at slimlogic.co.uk>, Oleksandr Kozaruk <oleksandr.kozaruk at ti.com");
+MODULE_DESCRIPTION("twl6030 ADC driver");
+MODULE_LICENSE("GPL");
-- 
1.8.1.2



From broonie at kernel.org  Thu Jul 25 09:31:45 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 25 Jul 2013 14:31:45 +0100
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <20130725112558.GD24642@n2100.arm.linux.org.uk>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
 <20130725110634.GB2546@localhost.localdomain>
 <20130725112558.GD24642@n2100.arm.linux.org.uk>
Message-ID: <20130725133145.GE9858@sirena.org.uk>

On Thu, Jul 25, 2013 at 12:25:58PM +0100, Russell King - ARM Linux wrote:

> That means whoever is doing the review of DT bindings probably needs to
> have access to documentation on the hardware - or they need to be educated
> by the submitter.  Or, we need submitters to individually justify why
> each and every property is required in the description.

My general strategy on that is to complain about any binding which isn't
comprehensible just from the binding document, plus pushing back on
anything that the driver really ought to be able to work out
automatically at runtime.
-------------- 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/20130725/34e215b4/attachment.sig>

From mpa at pengutronix.de  Thu Jul 25 09:38:56 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Thu, 25 Jul 2013 15:38:56 +0200
Subject: [PATCH 2/2] video: imxfb: Add feature to setup PWM Contrast
 Control Register
In-Reply-To: <1374395709-20898-2-git-send-email-shc_work@mail.ru>
References: <1374395709-20898-1-git-send-email-shc_work@mail.ru>
 <1374395709-20898-2-git-send-email-shc_work@mail.ru>
Message-ID: <20130725133824.GD16871@s25.your-server.de>

Hi,

On Sun, Jul 21, 2013 at 12:35:09PM +0400, Alexander Shiyan wrote:
> This patch adds feature to setup PWM Contrast Control Register.
> This register is used to control the signal output at the contrast pin,
> which controls contrast of the LCD panel.

http://www.spinics.net/lists/linux-fbdev/msg10002.html

Regards,

Markus

> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  Documentation/devicetree/bindings/video/fsl,imx-fb.txt | 1 +
>  drivers/video/imxfb.c                                  | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> index 46da08d..be10c65 100644
> --- a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> @@ -18,6 +18,7 @@ Optional properties:
>  - fsl,dmacr: DMA Control Register value. This is optional. By default, the
>  	register is not modified as recommended by the datasheet.
>  - fsl,lscr1: LCDC Sharp Configuration Register value.
> +- fsl,pwmr: LCDC PWM Contrast Control Register value.
>  
>  Example:
>  
> diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> index 8e104c4..d98299a 100644
> --- a/drivers/video/imxfb.c
> +++ b/drivers/video/imxfb.c
> @@ -806,8 +806,8 @@ static int imxfb_init_fbinfo(struct platform_device *pdev,
>  
>  		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
>  		of_property_read_u32(np, "fsl,lscr1", &fbi->lscr1);
> -
>  		of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
> +		of_property_read_u32(np, "fsl,pwmr", &fbi->pwmr);
>  
>  		/* These two function pointers could be used by some specific
>  		 * platforms. */
> -- 
> 1.8.1.5
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From broonie at kernel.org  Thu Jul 25 09:53:19 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 25 Jul 2013 14:53:19 +0100
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <CACRpkdY-mdLbMY16aMqR9Jwu8qs9q4KNyxOxnwhXiGrAAxpKjg@mail.gmail.com>
References: <1624911.6TtmtVmU1T@avalon>
 <CACRpkdazPX3EbVbLvXQZh0oRBpHoWPK+EkFO75v9zfAXSPCkHA@mail.gmail.com>
 <1408178.cxAUTUGJc5@avalon> <20130725131556.GD9858@sirena.org.uk>
 <CACRpkdY-mdLbMY16aMqR9Jwu8qs9q4KNyxOxnwhXiGrAAxpKjg@mail.gmail.com>
Message-ID: <20130725135319.GF9858@sirena.org.uk>

On Thu, Jul 25, 2013 at 03:21:35PM +0200, Linus Walleij wrote:
> On Thu, Jul 25, 2013 at 3:15 PM, Mark Brown <broonie at kernel.org> wrote:

> > Are the interrupts in a contiguous block in the controller so you can
> > just pass around the controller and a base number?

> That works with platform data and in-kernel structures, but AFAICT
> device tree has no such "bulk" concept but expects you to list
> each and every line individually in cases like this.

It works fine with domains as well - the domains all have a hwirq number
which is local to the domain context and doesn't correspond to a Linux
interrupt number.  If you can say "the X interrupts in this domain
starting at Y correspond to these X GPIOs" then you should be able to
cope.  Hopefully.
-------------- 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/20130725/4d30ee7c/attachment.sig>

From broonie at kernel.org  Thu Jul 25 09:55:47 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 25 Jul 2013 14:55:47 +0100
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <1681089.qGWOhLKTTo@avalon>
References: <1624911.6TtmtVmU1T@avalon> <1408178.cxAUTUGJc5@avalon>
 <20130725131556.GD9858@sirena.org.uk> <1681089.qGWOhLKTTo@avalon>
Message-ID: <20130725135547.GG9858@sirena.org.uk>

On Thu, Jul 25, 2013 at 03:22:29PM +0200, Laurent Pinchart wrote:
> On Thursday 25 July 2013 14:15:56 Mark Brown wrote:

> > Are the interrupts in a contiguous block in the controller so you can just
> > pass around the controller and a base number?

> In two of the three SoCs I need to fix they are. I've just realized that in 
> the last one the interrupts are in two contiguous blocks in two different 
> parents. I will thus need at least a list of <parent-phandle base count>. Our 
> standard interrupt bindings don't seem to support multiple parents, is that 
> something that we want to fix or should I go for custom bindings ?

It seems reasonable to define the bindings in a generic way in case
other people have the same problem but it's possible I may be missing a
trick regarding how to do this in DT so don't take my word for it.
-------------- 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/20130725/1c948990/attachment.sig>

From cavokz at gmail.com  Thu Jul 25 09:56:45 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Thu, 25 Jul 2013 15:56:45 +0200
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <20130725112558.GD24642@n2100.arm.linux.org.uk>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
 <20130725110634.GB2546@localhost.localdomain>
 <20130725112558.GD24642@n2100.arm.linux.org.uk>
Message-ID: <20130725135645.GA17304@glitch>

On Thu, Jul 25, 2013 at 12:25:58PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 25, 2013 at 12:06:34PM +0100, Dave Martin wrote:
> > On Wed, Jul 24, 2013 at 08:27:13AM -0700, Olof Johansson wrote:
> > > Every now and then I come across a binding that's just done Wrong(tm),
> > > merged through a submaintainer tree and hasn't seen proper review --
> > > if it had, it wouldn't look the way it does. It's something we're
> > > starting to address now since there's more people stepping up to be
> > > maintainers, but there's a backlog of bad bindings already merged.
> > > 
> > > Often they are produced by translating the platform_data structures
> > > directly over into device-tree properties without consideration to
> > > describing the hardware or usual conventions, using key/value pairs
> > > instead of boolean properties, etc.
> > > 
> > > Getting involved in cleaning up these kind of bindings is a great way
> > > to learn "the ways of device tree" for someone that has interest in
> > > that.
> > > 
> > > Latest find in this area is the Maxim 8925 bindings, that I came
> > > across since they caused a compile warning on some defconfig. I'll
> > > post a patch to address the warning but if someone else feels like
> > > fixing the bindings on top of it that would be appreciated!
> > 
> > DT bindings (even poorly conceived, ad-hoc and/or undocumented ones)
> > are ABI.
> > 
> > A review/merge process which _allows_ junk into an ABI is the real
> > problem we need to solve here, but once it's there we can't just magic
> > it away.
> > 
> > Do we plan on having a proper deprecation path for the junk, so that
> > the old, superseded bindings continue to work for a limited time,
> > preferably with a big fat warning somewhere?
> 
> This is the exact problem, and if you've seen how Linus rants about
> the ARM ecosystem breaking ABI stuff all the time, you will start to
> appreciate why ARM is not highly valued in the Linux communities.
> 
> We need to stop this crap getting in.
> 
> We need subsystem people to refuse to merge DT stuff if it hasn't been
> reviewed by DT people - subsystem people are _not_ qualified to accept
> those patches, even if they're responsible for the files which they're
> being applied to. Yes, they can review them, but they should _not_
> accept them without them having the bindings reviewed by folk who (a)
> know the hardware and (b) know the implications of creating a DT binding.
> 
> That means whoever is doing the review of DT bindings probably needs to
> have access to documentation on the hardware - or they need to be educated
> by the submitter.  Or, we need submitters to individually justify why
> each and every property is required in the description.
> 
> As for those already there, I don't think there's anything which can be
> done about them in the short term (short = quite a few years) - we can't
> go removing any properties that are already there, because that will
> break the ABI.  We're basically stuck with that crap for ever now.
> 
> That's the point that people have to understand: if they accept a DT
> description into the kernel, it's basically saying at that point that
> the DT description is the official and definitive description for that
> hardware.  It's just the same as adding a new syscall or something like
> that which the entire world starts to use immediately.  You can't go
> removing or changing it after the fact.
> 
> And this is also why a _hell_ of a lot of thought should go into each
> and every property _before_ it is even proposed by the patch submitter.

So this is the true price for having a nice HW agnostic kernel. I'm seeing
the urgency for an impedence adapter.

Would it be anyhow different with ACPI?

Domenico


From linus.walleij at linaro.org  Thu Jul 25 10:01:22 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Jul 2013 16:01:22 +0200
Subject: [PATCH 2/2] clk: fixup argument order when setting VCO parameters
In-Reply-To: <51F0F199.3040501@arm.com>
References: <1374594138-17080-1-git-send-email-jonathan.austin@arm.com>
 <1374594138-17080-3-git-send-email-jonathan.austin@arm.com>
 <CACRpkdbEiNPG0b89zXKpvNgXtAbsKeV9A9ibgEJCBgNa6vQvCw@mail.gmail.com>
 <51F0F035.8010705@arm.com>
 <CACRpkdb7UGS8ysPv=LakbWouUdL9MpKvrgYKh_v9NqSYV3TStg@mail.gmail.com>
 <51F0F199.3040501@arm.com>
Message-ID: <CACRpkdbMxdzpjQrEkSxX-NZKVRNFVT44NDhuZ4pdua5Prvjmug@mail.gmail.com>

On Thu, Jul 25, 2013 at 11:36 AM, Jonathan Austin
<jonathan.austin at arm.com> wrote:
> On 25/07/13 10:33, Linus Walleij wrote:

>> Then as the VCO params get written, it is never really unlocked
>> so the registers are untouched.
>>
>> You may have a different boot monitor?
>>
>
> Ahh, that seems highly likely. I don't ever see boot-monitor (boot straight
> in to uboot) but I don't see anything on the display until the kernel boots,
> so I don't think BM is setting up the VCO for me.

True, if you boot directly into U-boot the boot monitor is
never executed and the mode is never set up.

Yours,
Linus Walleij


From arnaud.patard at rtp-net.org  Thu Jul 25 10:03:10 2013
From: arnaud.patard at rtp-net.org (Arnaud Patard (Rtp))
Date: Thu, 25 Jul 2013 16:03:10 +0200
Subject: Enabling USBH1 on mx53qsb
In-Reply-To: <CAOMZO5CAdxzn-3Xc2DZDYEXwsEznRrcqPbCbTDc5ieBkQkA8=g@mail.gmail.com>
 (Fabio Estevam's message of "Wed, 24 Jul 2013 23:59:35 -0300")
References: <CAOMZO5CAdxzn-3Xc2DZDYEXwsEznRrcqPbCbTDc5ieBkQkA8=g@mail.gmail.com>
Message-ID: <8738r2wxcx.fsf@lebrac.rtp-net.org>

Fabio Estevam <festevam at gmail.com> writes:

> Hi,

Hi,
>
> I am trying to get USBH1 port to work on mx53qsb (with Dialog pmic)
> with the following patch against linux-next-20130724:

I've been trying to reach the same goal for quite some time without
success (on the same version of the mx53qsb).
>
> --- a/arch/arm/boot/dts/imx53-qsb.dts
> +++ b/arch/arm/boot/dts/imx53-qsb.dts
> @@ -93,6 +93,15 @@
>                         regulator-max-microvolt = <3200000>;
>                         regulator-always-on;
>                 };
> +
> +               reg_usb_vbus: usb_vbus {
> +                       compatible = "regulator-fixed";
> +                       regulator-name = "usb_vbus";
> +                       regulator-min-microvolt = <5000000>;
> +                       regulator-max-microvolt = <5000000>;
> +                       gpio = <&gpio7 8 0>;
> +                       enable-active-high;
> +               };
>         };
>
>         sound {
> @@ -145,6 +154,7 @@
>                                 MX53_PAD_EIM_DA12__GPIO3_12       0x80000000
>                                 MX53_PAD_EIM_DA13__GPIO3_13       0x80000000
>                                 MX53_PAD_PATA_DA_0__GPIO7_6       0x80000000
> +                               MX53_PAD_PATA_DA_2__GPIO7_8       0x80000000
>                                 MX53_PAD_GPIO_16__GPIO7_11        0x80000000
>                         >;
>                 };
> @@ -302,7 +312,8 @@
>  };
>
>  &usbh1 {
> -       status = "okay";
> +       vbus-supply = <&reg_usb_vbus>;
> +       status = "okay";

I tried also with:
+       phy_type = "utmi_wide";
+       dr_mode = "host";

but nothing.

>  };
>
>  &usbotg {
>
>
> mx53qsb board has two USB host ports:
>
> - The top port is USBH1
> - The bottom port is OTG (also shared with J3 connector)
>
> After applying the above patch the OTG port does work, but the USBH1
> does not.

Given that the same gpio controls vbus for both ports, my current guess
is something on port configuration side (I guess the board would freeze
hard if a clock is not enabled).


Arnaud


From linux at arm.linux.org.uk  Thu Jul 25 10:27:02 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 25 Jul 2013 15:27:02 +0100
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <20130725135645.GA17304@glitch>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
 <20130725110634.GB2546@localhost.localdomain>
 <20130725112558.GD24642@n2100.arm.linux.org.uk>
 <20130725135645.GA17304@glitch>
Message-ID: <20130725142702.GE24642@n2100.arm.linux.org.uk>

On Thu, Jul 25, 2013 at 03:56:45PM +0200, Domenico Andreoli wrote:
> On Thu, Jul 25, 2013 at 12:25:58PM +0100, Russell King - ARM Linux wrote:
> > This is the exact problem, and if you've seen how Linus rants about
> > the ARM ecosystem breaking ABI stuff all the time, you will start to
> > appreciate why ARM is not highly valued in the Linux communities.
> > 
> > We need to stop this crap getting in.
> > 
> > We need subsystem people to refuse to merge DT stuff if it hasn't been
> > reviewed by DT people - subsystem people are _not_ qualified to accept
> > those patches, even if they're responsible for the files which they're
> > being applied to. Yes, they can review them, but they should _not_
> > accept them without them having the bindings reviewed by folk who (a)
> > know the hardware and (b) know the implications of creating a DT binding.
> > 
> > That means whoever is doing the review of DT bindings probably needs to
> > have access to documentation on the hardware - or they need to be educated
> > by the submitter.  Or, we need submitters to individually justify why
> > each and every property is required in the description.
> > 
> > As for those already there, I don't think there's anything which can be
> > done about them in the short term (short = quite a few years) - we can't
> > go removing any properties that are already there, because that will
> > break the ABI.  We're basically stuck with that crap for ever now.
> > 
> > That's the point that people have to understand: if they accept a DT
> > description into the kernel, it's basically saying at that point that
> > the DT description is the official and definitive description for that
> > hardware.  It's just the same as adding a new syscall or something like
> > that which the entire world starts to use immediately.  You can't go
> > removing or changing it after the fact.
> > 
> > And this is also why a _hell_ of a lot of thought should go into each
> > and every property _before_ it is even proposed by the patch submitter.
> 
> So this is the true price for having a nice HW agnostic kernel.

Of course it is, and if you thought otherwise, then you haven't thought
about the problem enough.

If anyone went walking into DT thinking that the DT bindings can be hacked
around any old way, then they went into DT with a blindfold on, and did
not *think*/have not thought about the consequences.

Don't go thinking that ACPI would be any different, because it isn't.
It's no different from any _other_ interface that the kernel may ever
use to the outside world, be that the boot loader interface or the user
interfaces.  All those interfaces are all part of "the ABI" to code
outside of the kernel, and those are all interfaces which must be
thought out REAL carefully, and any changes to them must be backed up
with a way for the existing interfaces to _continue_ working.

What that means is that any DT representation created for any device which
has ever appeared in a mainline kernel is part of the kernel ABI and must
remain working in that state.  You can supplement it with new ways of doing
things, but the original bindings must continue to work.

Remember the stated assertion when DT was first added to the kernel: the
DT descriptions _will_ become a separately maintained project which is
independent of the kernel.  They will _not_ be kernel version specific.

Linus wants the platform specific crap like clocks and the like _out_ of
the kernel tree.  He doesn't want the stuff merely transformed into a
different representation - he wants it out of the kernel tree and
entirely separate.

Think about that for a moment with regard to churn in DT descriptions
and you will soon realise that if you change the DT descriptions and
then have to update the kernel inline with those updates, you're on to
creating one hell of a mess.

DT done correctly with care and thought works fine.  DT done without that
is a disaster, one which I had hoped people had learnt from with the
problems that PPC has had with bad bindings.

ABI compatibility is VERY important.  If you disagree with that, send
Linus an email justifying why you think you can change the ABI with no
compatibility.


From dinguyen at altera.com  Thu Jul 25 10:29:28 2013
From: dinguyen at altera.com (Dinh Nguyen)
Date: Thu, 25 Jul 2013 09:29:28 -0500
Subject: [PATCH 2/2] clocksource: dw_apb_timer_of: Fix read_sched_clock
In-Reply-To: <201307251102.23446.heiko@sntech.de>
References: <1374723797-22169-1-git-send-email-dinguyen@altera.com>
 <1374723797-22169-2-git-send-email-dinguyen@altera.com>
 <201307251102.23446.heiko@sntech.de>
Message-ID: <1374762568.3139.7.camel@linux-builds1>

Hi Heiko,

On Thu, 2013-07-25 at 11:02 +0200, Heiko St?bner wrote:
> Am Donnerstag, 25. Juli 2013, 05:43:17 schrieb dinguyen at altera.com:
> > From: Dinh Nguyen <dinguyen at altera.com>
> > 
> > The read_sched_clock should return the ~value because the clock is a
> > countdown implementation. read_sched_clock() should be the same as
> > __apbt_read_clocksource().
> > 
> > If a separate timer for the sched_clock exist, then read_sched_clock()
> > will return an incorrect value. The (sched_io_base + 0x4) needs to be in
> > the function for both cases.
> > 
> > Also, remove the use of "dw-apb-timer-sp" and "dw-apb-timer-osc" since
> > they are the same DW clock.
> > 
> > Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
> > Acked-by: Jamie Iles <jamie at jamieiles.com>
> > CC: Rob Herring <rob.herring at calxeda.com>
> > CC: Arnd Bergmann <arnd at arndb.de>
> > Cc: Olof Johansson <olof at lixom.net>
> > CC: Jamie Iles <jamie at jamieiles.com>
> > Cc: John Stultz <john.stultz at linaro.org>
> > Cc: Thomas Gleixner <tglx at linutronix.de>
> > Cc: Linus Walleij <linus.walleij at linaro.org>
> > Cc: Pavel Machek <pavel at denx.de>
> > Cc: Heiko Stuebner <heiko at sntech.de>
> > Cc: linux-arm-kernel at lists.infradead.org
> > ---
> >  drivers/clocksource/dw_apb_timer_of.c |    7 +++----
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/clocksource/dw_apb_timer_of.c
> > b/drivers/clocksource/dw_apb_timer_of.c index 4cbae4f..8e00929 100644
> > --- a/drivers/clocksource/dw_apb_timer_of.c
> > +++ b/drivers/clocksource/dw_apb_timer_of.c
> > @@ -102,18 +102,17 @@ static void add_clocksource(struct device_node
> > *source_timer) * timer is found. sched_io_base then points to the
> > current_value * register of the clocksource timer.
> >  	 */
> > -	sched_io_base = iobase + 0x04;
> > +	sched_io_base = iobase;
> >  	sched_rate = rate;
> >  }
> > 
> >  static u32 read_sched_clock(void)
> >  {
> > -	return __raw_readl(sched_io_base);
> > +	return ~__raw_readl(sched_io_base + 0x4);
> >  }
> > 
> 
> 
> 
> >  static const struct of_device_id sptimer_ids[] __initconst = {
> >  	{ .compatible = "picochip,pc3x2-rtc" },
> > -	{ .compatible = "snps,dw-apb-timer-sp" },
> >  	{ /* Sentinel */ },
> >  };
> 
> I'm not 100% sure, but maybe the same explaination as below applies to this - 
> with it better being part of the first patch.
> 
> 
> > @@ -153,4 +152,4 @@ static void __init dw_apb_timer_init(struct device_node
> > *timer) num_called++;
> >  }
> >  CLOCKSOURCE_OF_DECLARE(pc3x2_timer, "picochip,pc3x2-timer",
> > dw_apb_timer_init); -CLOCKSOURCE_OF_DECLARE(apb_timer,
> > "snps,dw-apb-timer-osc", dw_apb_timer_init);
> > +CLOCKSOURCE_OF_DECLARE(apb_timer, "snps,dw-apb-timer",
> > dw_apb_timer_init);
> 
> I think this hunk would better be part of the first patch, as you rename the 
> devices in the dtsi files there and it has nothing to do with the sched_clock 
> fix.
> 
> Changing the clocksource name here also breaks bisectability on the affected 
> platforms because they wouldn't be able to add the clocksources when only the 
> first patch is applied.

I agree with you, but I was under the impression that Arnd wanted to
keep DTS changes in a separate commit.

Dinh
> 
> 
> Heiko
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 





From catalin.marinas at arm.com  Thu Jul 25 10:38:15 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 25 Jul 2013 15:38:15 +0100
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <20130725142702.GE24642@n2100.arm.linux.org.uk>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
 <20130725110634.GB2546@localhost.localdomain>
 <20130725112558.GD24642@n2100.arm.linux.org.uk>
 <20130725135645.GA17304@glitch>
 <20130725142702.GE24642@n2100.arm.linux.org.uk>
Message-ID: <20130725143815.GA5812@darko.cambridge.arm.com>

On Thu, Jul 25, 2013 at 03:27:02PM +0100, Russell King - ARM Linux wrote:
> Remember the stated assertion when DT was first added to the kernel: the
> DT descriptions _will_ become a separately maintained project which is
> independent of the kernel.  They will _not_ be kernel version specific.

I'm looking forward to this.

Question for the DT guys: what are the plans here? Are we going to get
rid of the .dts files inside the kernel tree?

-- 
Catalin


From ben.dooks at codethink.co.uk  Thu Jul 25 10:42:37 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 15:42:37 +0100
Subject: [PATCH 2/2] ARM: fix BUG() detection
In-Reply-To: <1374763357-4893-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374763357-4893-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374763357-4893-3-git-send-email-ben.dooks@codethink.co.uk>

The detection of the instruction used by BUG() did not take into account
the differences in endian-ness between instruction and data. Change the
code to use the relevant helpers in <asm/opcodes.h> to translate the
endian-ness of the instructions.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/kernel/traps.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index cb67b04..ae2d828 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -344,15 +344,17 @@ void arm_notify_die(const char *str, struct pt_regs *regs,
 int is_valid_bugaddr(unsigned long pc)
 {
 #ifdef CONFIG_THUMB2_KERNEL
-	unsigned short bkpt;
+	u16 bkpt;
+	u16 insn = __opcode_to_mem_thumb16(BUG_INSTR_VALUE);
 #else
-	unsigned long bkpt;
+	u32 bkpt;
+	u32 insn = __opcode_to_mem_arm(BUG_INSTR_VALUE);
 #endif
 
 	if (probe_kernel_address((unsigned *)pc, bkpt))
 		return 0;
 
-	return bkpt == BUG_INSTR_VALUE;
+	return bkpt == insn;
 }
 
 #endif
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Thu Jul 25 10:42:36 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 15:42:36 +0100
Subject: [PATCH 1/2] ARM: Correct BUG() assembly to ensure it is
 endian-agnostic
In-Reply-To: <1374763357-4893-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374763357-4893-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374763357-4893-2-git-send-email-ben.dooks@codethink.co.uk>

Currently BUG() uses .word or .hword to create the necessary illegal
instructions. However if we are building BE8 then these get swapped
by the linker into different illegal instructions in the text.

Change to using .inst and .inst.w to create the instructions and mark
them as instructions so that the linker acts correctly.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/include/asm/bug.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
index 7af5c6c..b95da52 100644
--- a/arch/arm/include/asm/bug.h
+++ b/arch/arm/include/asm/bug.h
@@ -12,10 +12,10 @@
  */
 #ifdef CONFIG_THUMB2_KERNEL
 #define BUG_INSTR_VALUE 0xde02
-#define BUG_INSTR_TYPE ".hword "
+#define BUG_INSTR_TYPE ".inst.w "
 #else
 #define BUG_INSTR_VALUE 0xe7f001f2
-#define BUG_INSTR_TYPE ".word "
+#define BUG_INSTR_TYPE ".inst "
 #endif
 
 
-- 
1.7.10.4



From damien.riegel.ext at parrot.com  Thu Jul 25 10:42:59 2013
From: damien.riegel.ext at parrot.com (Damien Riegel)
Date: Thu, 25 Jul 2013 16:42:59 +0200
Subject: Issue with gpio and pinmux
In-Reply-To: <CACRpkdb-hVE1Jj69ttrn+zf5cEuMHhxNh2OyhfTtrG+yUiO+jg@mail.gmail.com>
References: <51E667BC.3070804@parrot.com>	<51E82FBB.1080905@wwwdotorg.org>
 <CACRpkdb1n07KoQZSme1EMJfV-9pHr-kd_1eJ6HsBV5gz7Dh3Ww@mail.gmail.com>
 <51EB590A.4010600@wwwdotorg.org>
 <CACRpkdZdbxEt67+YBKif4-BKAToOmN0_c8HFOdjSG91dtJwJQw@mail.gmail.com>
 <51F12629.7090909@parrot.com>
 <CACRpkdb-hVE1Jj69ttrn+zf5cEuMHhxNh2OyhfTtrG+yUiO+jg@mail.gmail.com>
Message-ID: <51F13973.70806@parrot.com>


> Does this recently submitted documentation patch help in explaining
> some of your questions?
> http://marc.info/?l=linux-kernel&m=137442899829271&w=2
This is a very helpful addition to the existing documentation.

My reflection rather was: when gpio is not orthogonal, we could just
check mux_owner to see if pin is available; and when it is, use the
current implementation.

But well, we obviously need to way to tell if gpios are orthogonal or
not, and adding a function to struct pinmux_ops is an elegant solution
to do so since it even allows a pin granularity.

I guess I sent my previous mail a bit too quickly.


From ben.dooks at codethink.co.uk  Thu Jul 25 10:49:37 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 15:49:37 +0100
Subject: kdgb fix
Message-ID: <1374763778-5305-1-git-send-email-ben.dooks@codethink.co.uk>

Think this is correct, but do not have the time to test.



From broonie at kernel.org  Thu Jul 25 10:51:58 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 25 Jul 2013 15:51:58 +0100
Subject: XCLKOUT in exynos5250 clock driver
Message-ID: <20130725145158.GI9858@sirena.org.uk>

I appear to be missing something in the clock driver for the exynos5250.
I'm looking at the Arndale schematic and I see that the audio master
clock is connected to XCLKOUT on the SoC.  However I can't see any
reference to XCLKOUT or anything similar in the clock driver or any of
the DTS files - where is this clock exposed by the clock driver?

Unfortunately I haven't been able to get access to the datasheet for the
part so I can't check this myself.
-------------- 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/20130725/040fd358/attachment.sig>

From linus.walleij at linaro.org  Thu Jul 25 11:06:05 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Jul 2013 17:06:05 +0200
Subject: Issue with gpio and pinmux
In-Reply-To: <51F13973.70806@parrot.com>
References: <51E667BC.3070804@parrot.com> <51E82FBB.1080905@wwwdotorg.org>
 <CACRpkdb1n07KoQZSme1EMJfV-9pHr-kd_1eJ6HsBV5gz7Dh3Ww@mail.gmail.com>
 <51EB590A.4010600@wwwdotorg.org>
 <CACRpkdZdbxEt67+YBKif4-BKAToOmN0_c8HFOdjSG91dtJwJQw@mail.gmail.com>
 <51F12629.7090909@parrot.com>
 <CACRpkdb-hVE1Jj69ttrn+zf5cEuMHhxNh2OyhfTtrG+yUiO+jg@mail.gmail.com>
 <51F13973.70806@parrot.com>
Message-ID: <CACRpkdaxD9ShfciD2CJY-1X9hmRPFj+mnFxJXp7ddA0PAZh4wg@mail.gmail.com>

On Thu, Jul 25, 2013 at 4:42 PM, Damien Riegel
<damien.riegel.ext at parrot.com> wrote:

> My reflection rather was: when gpio is not orthogonal, we could just
> check mux_owner to see if pin is available; and when it is, use the
> current implementation.
>
> But well, we obviously need to way to tell if gpios are orthogonal or
> not, and adding a function to struct pinmux_ops is an elegant solution
> to do so since it even allows a pin granularity.

Yep, I'm just waiting for the patches now :-)

Yours,
Linus Walleij


From jason at lakedaemon.net  Thu Jul 25 11:25:38 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 11:25:38 -0400
Subject: [PATCH] ARM: dove: fix missing __init section of
 dove_mpp_gpio_mode
In-Reply-To: <1372690572-2184-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372690572-2184-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130725152538.GG23879@titan.lakedaemon.net>

On Mon, Jul 01, 2013 at 04:56:12PM +0200, Sebastian Hesselbarth wrote:
> Legacy dove_mpp_gpio_mode calls orion_gpio_set_valid which is in
> __init section. Offending function is not, so this causes a section
> mismatch. To fix the mismatch, also move dove_mpp_gpio_mode to
> __init section.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  arch/arm/mach-dove/mpp.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Applied to mvebu/fixes-non-critical

thx,

Jason.


From jason at lakedaemon.net  Thu Jul 25 11:31:04 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 11:31:04 -0400
Subject: [PATCH 1/2] ARM: remove dmacap,memset from Device tree binding
In-Reply-To: <1372762453-12018-2-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762453-12018-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1372762453-12018-2-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130725153104.GH23879@titan.lakedaemon.net>

On Tue, Jul 02, 2013 at 12:54:12PM +0200, Sebastian Hesselbarth wrote:
> DMA_MEMSET support has been removed, so update the device tree files
> and corresponding binding documentation for Marvell SoCs.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
> Cc: Russell King <linux at arm.linux.org.uk> 
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Andrew Lunn <andrew at lunn.ch>
> Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Cc: Gregory CLEMENT <gregory.clement at free-electrons.com> 
> Cc: devicetree-discuss at lists.ozlabs.org 
> Cc: linux-kernel at vger.kernel.org 
> Cc: linux-arm-kernel at lists.infradead.org 
> ---
>  Documentation/devicetree/bindings/dma/mv-xor.txt |    2 --
>  arch/arm/boot/dts/armada-370.dtsi                |    2 --
>  arch/arm/boot/dts/armada-xp.dtsi                 |    2 --
>  arch/arm/boot/dts/dove.dtsi                      |    2 --
>  arch/arm/boot/dts/kirkwood.dtsi                  |    2 --
>  arch/arm/boot/dts/orion5x.dtsi                   |    1 -
>  6 files changed, 0 insertions(+), 11 deletions(-)

Adding the new devicetree ml to the Cc:

I'm fine with the changes to the dts{i} files, but I think the binding
document should be handled differently.

thx,

Jason.

> 
> diff --git a/Documentation/devicetree/bindings/dma/mv-xor.txt b/Documentation/devicetree/bindings/dma/mv-xor.txt
> index 7c6cb7f..68f7004 100644
> --- a/Documentation/devicetree/bindings/dma/mv-xor.txt
> +++ b/Documentation/devicetree/bindings/dma/mv-xor.txt
> @@ -14,7 +14,6 @@ properties:
>  
>  And the following optional properties:
>  - dmacap,memcpy to indicate that the XOR channel is capable of memcpy operations
> -- dmacap,memset to indicate that the XOR channel is capable of memset operations
>  - dmacap,xor to indicate that the XOR channel is capable of xor operations
>  
>  Example:
> @@ -35,6 +34,5 @@ xor at d0060900 {
>  	      interrupts = <52>;
>  	      dmacap,memcpy;
>  	      dmacap,xor;
> -	      dmacap,memset;
>  	};
>  };
> diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
> index fa3dfc6..a315ad1 100644
> --- a/arch/arm/boot/dts/armada-370.dtsi
> +++ b/arch/arm/boot/dts/armada-370.dtsi
> @@ -132,7 +132,6 @@
>  					interrupts = <52>;
>  					dmacap,memcpy;
>  					dmacap,xor;
> -					dmacap,memset;
>  				};
>  			};
>  
> @@ -151,7 +150,6 @@
>  					interrupts = <95>;
>  					dmacap,memcpy;
>  					dmacap,xor;
> -					dmacap,memset;
>  				};
>  			};
>  
> diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
> index 416eb94..4b3dd56 100644
> --- a/arch/arm/boot/dts/armada-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-xp.dtsi
> @@ -114,7 +114,6 @@
>  					interrupts = <52>;
>  					dmacap,memcpy;
>  					dmacap,xor;
> -					dmacap,memset;
>  				};
>  			};
>  
> @@ -134,7 +133,6 @@
>  					interrupts = <95>;
>  					dmacap,memcpy;
>  					dmacap,xor;
> -					dmacap,memset;
>  				};
>  			};
>  
> diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
> index 6cab468..2cef34f 100644
> --- a/arch/arm/boot/dts/dove.dtsi
> +++ b/arch/arm/boot/dts/dove.dtsi
> @@ -232,7 +232,6 @@
>  
>  			channel1 {
>  				interrupts = <40>;
> -				dmacap,memset;
>  				dmacap,memcpy;
>  				dmacap,xor;
>  			};
> @@ -253,7 +252,6 @@
>  
>  			channel1 {
>  				interrupts = <43>;
> -				dmacap,memset;
>  				dmacap,memcpy;
>  				dmacap,xor;
>  			};
> diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
> index 9809fc1..078637c 100644
> --- a/arch/arm/boot/dts/kirkwood.dtsi
> +++ b/arch/arm/boot/dts/kirkwood.dtsi
> @@ -126,7 +126,6 @@
>  			      interrupts = <6>;
>  			      dmacap,memcpy;
>  			      dmacap,xor;
> -			      dmacap,memset;
>  			};
>  		};
>  
> @@ -146,7 +145,6 @@
>  			      interrupts = <8>;
>  			      dmacap,memcpy;
>  			      dmacap,xor;
> -			      dmacap,memset;
>  			};
>  		};
>  
> diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
> index 892c64e..f82ece7 100644
> --- a/arch/arm/boot/dts/orion5x.dtsi
> +++ b/arch/arm/boot/dts/orion5x.dtsi
> @@ -120,7 +120,6 @@
>  			      interrupts = <31>;
>  			      dmacap,memcpy;
>  			      dmacap,xor;
> -			      dmacap,memset;
>  			};
>  		};
>  
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From a.motakis at virtualopensystems.com  Thu Jul 25 11:34:59 2013
From: a.motakis at virtualopensystems.com (Antonios Motakis)
Date: Thu, 25 Jul 2013 17:34:59 +0200
Subject: [PATCHv2 1/2] iommu/exynos: add devices attached to the System MMU to
 an IOMMU group
Message-ID: <1374766502-14823-1-git-send-email-a.motakis@virtualopensystems.com>

IOMMU groups are expected by certain users of the IOMMU API,
e.g. VFIO. Since each device is behind its own System MMU, we
can allocate a new IOMMU group for each device.

This patch depends on Cho KyongHo's patch series titled "[PATCH v7 00/12]
iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
applied on a Linux 3.10.1 kernel. It has been tested on the Arndale board.

Changes since in v2:
- Removed possibility for minor memory leak in case of
  misbehaving platform drivers

Signed-off-by: Antonios Motakis <a.motakis at virtualopensystems.com>
---
 drivers/iommu/exynos-iommu.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 51d43bb..c7dd4b5 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1134,6 +1134,32 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct iommu_domain *domain,
 	return phys;
 }
 
+static int exynos_iommu_add_device(struct device *dev)
+{
+	struct iommu_group *group;
+	int ret;
+
+	group = iommu_group_get(dev);
+
+	if (!group) {
+		group = iommu_group_alloc();
+		if (IS_ERR(group)) {
+			dev_err(dev, "Failed to allocate IOMMU group\n");
+			return PTR_ERR(group);
+		}
+	}
+
+	ret = iommu_group_add_device(group, dev);
+	iommu_group_put(group);
+
+	return ret;
+}
+
+static void exynos_iommu_remove_device(struct device *dev)
+{
+	iommu_group_remove_device(dev);
+}
+
 static struct iommu_ops exynos_iommu_ops = {
 	.domain_init = &exynos_iommu_domain_init,
 	.domain_destroy = &exynos_iommu_domain_destroy,
@@ -1142,6 +1168,8 @@ static struct iommu_ops exynos_iommu_ops = {
 	.map = &exynos_iommu_map,
 	.unmap = &exynos_iommu_unmap,
 	.iova_to_phys = &exynos_iommu_iova_to_phys,
+	.add_device	= exynos_iommu_add_device,
+	.remove_device	= exynos_iommu_remove_device,
 	.pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
 };
 
-- 
1.8.1.2



From a.motakis at virtualopensystems.com  Thu Jul 25 11:35:00 2013
From: a.motakis at virtualopensystems.com (Antonios Motakis)
Date: Thu, 25 Jul 2013 17:35:00 +0200
Subject: [PATCH 2/2] iommu/exynos: Follow kernel coding style for
 __sysmmu_enable return type
In-Reply-To: <1374766502-14823-1-git-send-email-a.motakis@virtualopensystems.com>
References: <1374766502-14823-1-git-send-email-a.motakis@virtualopensystems.com>
Message-ID: <1374766502-14823-2-git-send-email-a.motakis@virtualopensystems.com>

On success, the __sysmmu_enable returns 1 instead of 0, which does not
respect the convention described in Chapter 16 of the Linux kernel coding
style.

In fact, this return value is propagated all the way up to
iommu_attach_device() and iommu_attach_device() in drivers/iommu.c,
which results into inconsistent behavior of the IOMMU API with Exynos
systems, compared to other IOMMUs.

This patch replaces the return value with 0, which makes the Exynos'
IOMMU driver behavior consistent with that of other IOMMUs.

Signed-off-by: Antonios Motakis <a.motakis at virtualopensystems.com>
---
 drivers/iommu/exynos-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index c7dd4b5..4ea3abb 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -504,7 +504,7 @@ static int __sysmmu_enable(struct sysmmu_drvdata *data,
 
 		dev_dbg(data->sysmmu, "Enabled\n");
 	} else {
-		ret = (pgtable == data->pgtable) ? 1 : -EBUSY;
+		ret = (pgtable == data->pgtable) ? 0 : -EBUSY;
 
 		dev_dbg(data->sysmmu, "already enabled\n");
 	}
-- 
1.8.1.2



From jason at lakedaemon.net  Thu Jul 25 11:38:56 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 11:38:56 -0400
Subject: [PATCH 2/2] ARM: orion5x: add missing mbus include
In-Reply-To: <1372762453-12018-3-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762453-12018-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1372762453-12018-3-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130725153856.GI23879@titan.lakedaemon.net>

On Tue, Jul 02, 2013 at 12:54:13PM +0200, Sebastian Hesselbarth wrote:
> edmini_v2-setup is missing an include of linux/mbus.h which causes
> compiler error because of missing reference to mvebu_mbus_add_window.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
> Cc: Russell King <linux at arm.linux.org.uk> 
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Andrew Lunn <andrew at lunn.ch>
> Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Cc: Gregory CLEMENT <gregory.clement at free-electrons.com> 
> Cc: devicetree-discuss at lists.ozlabs.org 
> Cc: linux-kernel at vger.kernel.org 
> Cc: linux-arm-kernel at lists.infradead.org 
> ---
>  arch/arm/mach-orion5x/edmini_v2-setup.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)

Applied to mvebu/stable-3.10

thx,

Jason.


From tim.kryger at linaro.org  Thu Jul 25 11:43:38 2013
From: tim.kryger at linaro.org (Tim Kryger)
Date: Thu, 25 Jul 2013 08:43:38 -0700
Subject: [PATCH 05/22] ARM: dts: bcm281xx: Remove '0x's from BCM11351 BRT
 DTS file
In-Reply-To: <51ED6486.3080700@broadcom.com>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-5-git-send-email-lee.jones@linaro.org>
 <51ED2D90.4020209@broadcom.com> <20130722133852.GA26801@laptop>
 <51ED3971.905@broadcom.com> <51ED6486.3080700@broadcom.com>
Message-ID: <CAAYSxhrf+WNz1+ojA1r_pOLWg4xf9Ko8OyUc4GfVEMUN776pfA@mail.gmail.com>

On Mon, Jul 22, 2013 at 9:57 AM, Christian Daudt <csd at broadcom.com> wrote:

> it'd be nice to have something to point
> people to as this being the best practice for kernel dev.

Power.org's ePAPR exclusively omits the 0x in the unit-address of node names.

https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf


From ben.dooks at codethink.co.uk  Thu Jul 25 10:42:35 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 15:42:35 +0100
Subject: BUG() issues with big-endian
Message-ID: <1374763357-4893-1-git-send-email-ben.dooks@codethink.co.uk>

Following Dave Martin's point over the is_valid_bugaddr() it was
found that both is_valid_bugaddr() is broken w.r.t to BE8 as well
as the BUG() macro creation. These two patches fix the problems.



From ben.dooks at codethink.co.uk  Thu Jul 25 10:49:38 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 15:49:38 +0100
Subject: [PATCH] ARM: kdgb: use .inst for data to be assembled as intruction
In-Reply-To: <1374763778-5305-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374763778-5305-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374763778-5305-2-git-send-email-ben.dooks@codethink.co.uk>

The arch_kgdb_breakpoint() function uses an inline assembly directive
to assemble a specific instruction using .word. This means the linker
will not treat is as an instruction, and therefore incorrectly swap
the endian-ness if running BE8.

Note, not tested, please comment if this is wrong.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/include/asm/kgdb.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/kgdb.h b/arch/arm/include/asm/kgdb.h
index 48066ce..76227c8 100644
--- a/arch/arm/include/asm/kgdb.h
+++ b/arch/arm/include/asm/kgdb.h
@@ -41,7 +41,7 @@
 
 static inline void arch_kgdb_breakpoint(void)
 {
-	asm(".word 0xe7ffdeff");
+	asm(".inst 0xe7ffdeff");
 }
 
 extern void kgdb_handle_bus_error(void);
-- 
1.7.10.4



From simon.guinot at sequanux.org  Thu Jul 25 11:49:32 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Thu, 25 Jul 2013 17:49:32 +0200
Subject: Location for a kind of GPIO bus driver
In-Reply-To: <20130724181924.GI19736@titan.lakedaemon.net>
References: <20130723151834.GJ9916@kw.sim.vm.gnt>
 <20130724181924.GI19736@titan.lakedaemon.net>
Message-ID: <20130725154932.GL9916@kw.sim.vm.gnt>

On Wed, Jul 24, 2013 at 02:19:24PM -0400, Jason Cooper wrote:
> On Tue, Jul 23, 2013 at 05:18:34PM +0200, Simon Guinot wrote:
> > Hi,
> > 
> > I am currently working on converting the LED driver leds-netxbig to DT.
> > Doing so, I am also considering to move the GPIO extension bus functions
> > (which are currently parts of leds-netxbig) into a separate driver.
> > 
> > On the LaCie "Big Network" board family (netxbig), the LEDs are
> > controlled by a CPLD. In turn, the CPLD can be configured (mostly the
> > LEDs modes) through a kind of parallel GPIO bus, called GPIO extension
> > bus. Two registers (address and data) are exposed. Each of them is made
> > up of several GPIOs. An extra GPIO is used to notify the CPLD that the
> > registers have been updated. The leds-netxbig driver uses some dedicated
> > functions (prefixed by "gpio_ext_") to handle the GPIO bus extension.
> > 
> > On the latest "Big Network" boards, this bus is also used to enable the
> > PM wakeup sources: the CPLD can be asked to keep powered some devices
> > (as the RTC or the Ethernet PHY) while the board is down. I think it
> > could be nice to expose this feature to the userland. That's why I am
> > thinking about moving the GPIO extension bus support into a separate
> > driver. The problem is that I can't find a proper location for a such
> > driver. AFAIK, it doesn't fit with anything existing supported by Linux.
> > Maybe I should consider drivers/bus ? Or even drivers/misc ?

Hi Jason,

Thanks for your answer.

> 
> iiuc, the CPLD is more of gpio multiplexer/expander.  Have you seen
> 
>   66bcb58 arm: mvebu: enable gpio expander over i2c on Mirabox platform
> 
> ?  And the corresponding driver, drivers/gpio/gpio-pca953x.c?

All the drivers under drivers/gpio are registering some GPIO chips.
It is a big difference with the LaCie "GPIO extension bus". This last
is more an extension mechanism on the top of GPIOs already existing
(eventually provided by a SoC or a Super-I/O on x86 boards). No new
GPIOs are added. I think that the name "extension" is quite confusing.

The idea behind this "bus" is to allow to configure a lot of LEDs (in
various modes) using only few GPIOs and a CPLD (which is already
available on the board for other purposes). This cheap solution allows
precisely to save the cost of a GPIO expander :)

As an example, you can see the "GPIO extension bus" configuration for
the Kirkwood "Big Network" boards in:
arch/arm/mach-kirkwood/netxbig_v2-setup.c:132.

> 
> I would try drivers/gpio.  If there are complaints, it should be trivial
> to move it in a new version of the series.

Why not, as long it is clear that the resulting driver will not provide
a GPIO chip but rather functions as a library.

> 
> Is there any reason why the new capabilities in the "Big Network" boards
> couldn't be covered by gpio-regulator?

I don't have looked at the details but I think that gpio-regulator
could be able to configure the PM modes through the GPIO extension bus.

But a problem remains. The same GPIOs would be used by two different
drivers: leds-netxbig and gpio-regulator. This would lead to some
conflicts. That's why I think that at some level a driver is needed to
handle the GPIO extension bus.

Regards,

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130725/c2ada4ec/attachment.sig>

From will.deacon at arm.com  Thu Jul 25 11:55:40 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 16:55:40 +0100
Subject: [PATCH v2 6/6] ARM: bitops: prefetch the destination word for write
 prior to strex
In-Reply-To: <1374767740-2068-1-git-send-email-will.deacon@arm.com>
References: <1374767740-2068-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374767740-2068-7-git-send-email-will.deacon@arm.com>

The cost of changing a cacheline from shared to exclusive state can be
significant, especially when this is triggered by an exclusive store,
since it may result in having to retry the transaction.

This patch prefixes our atomic bitops implementation with prefetchw,
to try and grab the line in exclusive state from the start. The testop
macro is left alone, since the barrier semantics limit the usefulness
of prefetching data.

Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/lib/bitops.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index d6408d1..e0c68d5 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h
@@ -10,6 +10,11 @@ UNWIND(	.fnstart	)
 	and	r3, r0, #31		@ Get bit offset
 	mov	r0, r0, lsr #5
 	add	r1, r1, r0, lsl #2	@ Get word offset
+#if __LINUX_ARM_ARCH__ >= 7
+	.arch_extension	mp
+	ALT_SMP(W(pldw)	[r1])
+	ALT_UP(W(nop))
+#endif
 	mov	r3, r2, lsl r3
 1:	ldrex	r2, [r1]
 	\instr	r2, r2, r3
-- 
1.8.2.2



From will.deacon at arm.com  Thu Jul 25 11:55:39 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 16:55:39 +0100
Subject: [PATCH v2 5/6] ARM: atomics: prefetch the destination word for write
 prior to strex
In-Reply-To: <1374767740-2068-1-git-send-email-will.deacon@arm.com>
References: <1374767740-2068-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374767740-2068-6-git-send-email-will.deacon@arm.com>

The cost of changing a cacheline from shared to exclusive state can be
significant, especially when this is triggered by an exclusive store,
since it may result in having to retry the transaction.

This patch prefixes our atomic access implementations with pldw
instructions (on CPUs which support them) to try and grab the line in
exclusive state from the start. Only the barrier-less functions are
updated, since memory barriers can limit the usefulness of prefetching
data.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/atomic.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index da1c77d..55ffc3b 100644
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h
@@ -12,6 +12,7 @@
 #define __ASM_ARM_ATOMIC_H
 
 #include <linux/compiler.h>
+#include <linux/prefetch.h>
 #include <linux/types.h>
 #include <linux/irqflags.h>
 #include <asm/barrier.h>
@@ -41,6 +42,7 @@ static inline void atomic_add(int i, atomic_t *v)
 	unsigned long tmp;
 	int result;
 
+	prefetchw(&v->counter);
 	__asm__ __volatile__("@ atomic_add\n"
 "1:	ldrex	%0, [%3]\n"
 "	add	%0, %0, %4\n"
@@ -79,6 +81,7 @@ static inline void atomic_sub(int i, atomic_t *v)
 	unsigned long tmp;
 	int result;
 
+	prefetchw(&v->counter);
 	__asm__ __volatile__("@ atomic_sub\n"
 "1:	ldrex	%0, [%3]\n"
 "	sub	%0, %0, %4\n"
@@ -138,6 +141,7 @@ static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
 {
 	unsigned long tmp, tmp2;
 
+	prefetchw(addr);
 	__asm__ __volatile__("@ atomic_clear_mask\n"
 "1:	ldrex	%0, [%3]\n"
 "	bic	%0, %0, %4\n"
@@ -283,6 +287,7 @@ static inline void atomic64_set(atomic64_t *v, u64 i)
 {
 	u64 tmp;
 
+	prefetchw(&v->counter);
 	__asm__ __volatile__("@ atomic64_set\n"
 "1:	ldrexd	%0, %H0, [%2]\n"
 "	strexd	%0, %3, %H3, [%2]\n"
@@ -299,6 +304,7 @@ static inline void atomic64_add(u64 i, atomic64_t *v)
 	u64 result;
 	unsigned long tmp;
 
+	prefetchw(&v->counter);
 	__asm__ __volatile__("@ atomic64_add\n"
 "1:	ldrexd	%0, %H0, [%3]\n"
 "	adds	%0, %0, %4\n"
@@ -339,6 +345,7 @@ static inline void atomic64_sub(u64 i, atomic64_t *v)
 	u64 result;
 	unsigned long tmp;
 
+	prefetchw(&v->counter);
 	__asm__ __volatile__("@ atomic64_sub\n"
 "1:	ldrexd	%0, %H0, [%3]\n"
 "	subs	%0, %0, %4\n"
-- 
1.8.2.2



From will.deacon at arm.com  Thu Jul 25 11:55:35 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 16:55:35 +0100
Subject: [PATCH v2 1/6] ARM: prefetch: remove redundant "cc" clobber
In-Reply-To: <1374767740-2068-1-git-send-email-will.deacon@arm.com>
References: <1374767740-2068-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374767740-2068-2-git-send-email-will.deacon@arm.com>

The pld instruction does not affect the condition flags, so don't bother
clobbering them.

Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/processor.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 06e7d50..91cfe08 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -101,9 +101,7 @@ static inline void prefetch(const void *ptr)
 {
 	__asm__ __volatile__(
 		"pld\t%a0"
-		:
-		: "p" (ptr)
-		: "cc");
+		:: "p" (ptr));
 }
 
 #define ARCH_HAS_PREFETCHW
-- 
1.8.2.2



From will.deacon at arm.com  Thu Jul 25 11:55:34 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 16:55:34 +0100
Subject: [PATCH v2 0/6] Add support for pldw instruction on v7 MP cores
Message-ID: <1374767740-2068-1-git-send-email-will.deacon@arm.com>

Hello all,

Thie is version two of that patches I posted the other day:

v1: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185663.html

Changes since v1 include:

	- Rewrite prefetch and prefetchw as macros, to avoid explicit
	  casting in the caller (also requires changing the type of
	  arch_rwlock_t to remove the volatile member).

	- Some cosmetic cleanups.

Thanks to Nicolas for the feedback received so far.

Will


Will Deacon (6):
  ARM: prefetch: remove redundant "cc" clobber
  ARM: smp_on_up: move inline asm ALT_SMP patching macro out of
    spinlock.h
  ARM: prefetch: add support for prefetchw using pldw on SMP ARMv7+ CPUs
  ARM: locks: prefetch the destination word for write prior to strex
  ARM: atomics: prefetch the destination word for write prior to strex
  ARM: bitops: prefetch the destination word for write prior to strex

 arch/arm/include/asm/atomic.h         |  7 ++++++
 arch/arm/include/asm/processor.h      | 43 ++++++++++++++++++++++++-----------
 arch/arm/include/asm/spinlock.h       | 28 +++++++++++------------
 arch/arm/include/asm/spinlock_types.h |  2 +-
 arch/arm/include/asm/unified.h        |  4 ++++
 arch/arm/lib/bitops.h                 |  5 ++++
 6 files changed, 61 insertions(+), 28 deletions(-)

-- 
1.8.2.2



From will.deacon at arm.com  Thu Jul 25 11:55:36 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 16:55:36 +0100
Subject: [PATCH v2 2/6] ARM: smp_on_up: move inline asm ALT_SMP patching macro
 out of spinlock.h
In-Reply-To: <1374767740-2068-1-git-send-email-will.deacon@arm.com>
References: <1374767740-2068-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374767740-2068-3-git-send-email-will.deacon@arm.com>

Patching UP/SMP alternatives inside inline assembly blocks is useful
outside of the spinlock implementation, where it is used for sev and wfe.

This patch lifts the macro into processor.h and gives it a scarier name
to (a) avoid conflicts in the global namespace and (b) to try and deter
its usage unless you "know what you're doing". The W macro for generating
wide instructions when targetting Thumb-2 is also made available under
the name WASM, to reduce the potential for conflicts with other headers.

Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/processor.h | 12 ++++++++++++
 arch/arm/include/asm/spinlock.h  | 15 ++++-----------
 arch/arm/include/asm/unified.h   |  4 ++++
 3 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 91cfe08..cbdb130 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -22,6 +22,7 @@
 #include <asm/hw_breakpoint.h>
 #include <asm/ptrace.h>
 #include <asm/types.h>
+#include <asm/unified.h>
 
 #ifdef __KERNEL__
 #define STACK_TOP	((current->personality & ADDR_LIMIT_32BIT) ? \
@@ -91,6 +92,17 @@ unsigned long get_wchan(struct task_struct *p);
 #define KSTK_EIP(tsk)	task_pt_regs(tsk)->ARM_pc
 #define KSTK_ESP(tsk)	task_pt_regs(tsk)->ARM_sp
 
+#ifdef CONFIG_SMP
+#define __ALT_SMP_ASM(smp, up)						\
+	"9998:	" smp "\n"						\
+	"	.pushsection \".alt.smp.init\", \"a\"\n"		\
+	"	.long	9998b\n"					\
+	"	" up "\n"						\
+	"	.popsection\n"
+#else
+#define __ALT_SMP_ASM(smp, up)	up
+#endif
+
 /*
  * Prefetching support - only ARMv5.
  */
diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index f8b8965..0de7bec 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -11,15 +11,7 @@
  * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
  * extensions, so when running on UP, we have to patch these instructions away.
  */
-#define ALT_SMP(smp, up)					\
-	"9998:	" smp "\n"					\
-	"	.pushsection \".alt.smp.init\", \"a\"\n"	\
-	"	.long	9998b\n"				\
-	"	" up "\n"					\
-	"	.popsection\n"
-
 #ifdef CONFIG_THUMB2_KERNEL
-#define SEV		ALT_SMP("sev.w", "nop.w")
 /*
  * For Thumb-2, special care is needed to ensure that the conditional WFE
  * instruction really does assemble to exactly 4 bytes (as required by
@@ -31,17 +23,18 @@
  * the assembler won't change IT instructions which are explicitly present
  * in the input.
  */
-#define WFE(cond)	ALT_SMP(		\
+#define WFE(cond)	__ALT_SMP_ASM(		\
 	"it " cond "\n\t"			\
 	"wfe" cond ".n",			\
 						\
 	"nop.w"					\
 )
 #else
-#define SEV		ALT_SMP("sev", "nop")
-#define WFE(cond)	ALT_SMP("wfe" cond, "nop")
+#define WFE(cond)	__ALT_SMP_ASM("wfe" cond, "nop")
 #endif
 
+#define SEV		__ALT_SMP_ASM(WASM(sev), WASM(nop))
+
 static inline void dsb_sev(void)
 {
 #if __LINUX_ARM_ARCH__ >= 7
diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
index f5989f4..b88beab 100644
--- a/arch/arm/include/asm/unified.h
+++ b/arch/arm/include/asm/unified.h
@@ -38,6 +38,8 @@
 #ifdef __ASSEMBLY__
 #define W(instr)	instr.w
 #define BSYM(sym)	sym + 1
+#else
+#define WASM(instr)	#instr ".w"
 #endif
 
 #else	/* !CONFIG_THUMB2_KERNEL */
@@ -50,6 +52,8 @@
 #ifdef __ASSEMBLY__
 #define W(instr)	instr
 #define BSYM(sym)	sym
+#else
+#define WASM(instr)	#instr
 #endif
 
 #endif	/* CONFIG_THUMB2_KERNEL */
-- 
1.8.2.2



From will.deacon at arm.com  Thu Jul 25 11:55:37 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 16:55:37 +0100
Subject: [PATCH v2 3/6] ARM: prefetch: add support for prefetchw using pldw on
 SMP ARMv7+ CPUs
In-Reply-To: <1374767740-2068-1-git-send-email-will.deacon@arm.com>
References: <1374767740-2068-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374767740-2068-4-git-send-email-will.deacon@arm.com>

SMP ARMv7 CPUs implement the pldw instruction, which allows them to
prefetch data cachelines in an exclusive state.

This patch defines the prefetchw macro using pldw for CPUs that support
it.

Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/processor.h | 29 ++++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index cbdb130..dde7ecc 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -109,19 +109,26 @@ unsigned long get_wchan(struct task_struct *p);
 #if __LINUX_ARM_ARCH__ >= 5
 
 #define ARCH_HAS_PREFETCH
-static inline void prefetch(const void *ptr)
-{
-	__asm__ __volatile__(
-		"pld\t%a0"
-		:: "p" (ptr));
-}
+#define prefetch(p)							\
+({									\
+	__asm__ __volatile__(						\
+		"pld\t%a0"						\
+		:: "p" (p));						\
+})
 
+#if __LINUX_ARM_ARCH__ >= 7 && defined(CONFIG_SMP)
 #define ARCH_HAS_PREFETCHW
-#define prefetchw(ptr)	prefetch(ptr)
-
-#define ARCH_HAS_SPINLOCK_PREFETCH
-#define spin_lock_prefetch(x) do { } while (0)
-
+#define prefetchw(p)							\
+({									\
+	__asm__ __volatile__(						\
+		".arch_extension	mp\n"				\
+		__ALT_SMP_ASM(						\
+			WASM(pldw)		"\t%a0",		\
+			WASM(pld)		"\t%a0"			\
+		)							\
+		:: "p" (p));						\
+})
+#endif
 #endif
 
 #define HAVE_ARCH_PICK_MMAP_LAYOUT
-- 
1.8.2.2



From will.deacon at arm.com  Thu Jul 25 11:55:38 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 16:55:38 +0100
Subject: [PATCH v2 4/6] ARM: locks: prefetch the destination word for write
 prior to strex
In-Reply-To: <1374767740-2068-1-git-send-email-will.deacon@arm.com>
References: <1374767740-2068-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374767740-2068-5-git-send-email-will.deacon@arm.com>

The cost of changing a cacheline from shared to exclusive state can be
significant, especially when this is triggered by an exclusive store,
since it may result in having to retry the transaction.

This patch prefixes our {spin,read,write}_[try]lock implementations with
pldw instructions (on CPUs which support them) to try and grab the line
in exclusive state from the start. arch_rwlock_t is changed to avoid
using a volatile member, since this generates compiler warnings when
falling back on the __builtin_prefetch intrinsic which expects a const
void * argument.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/spinlock.h       | 13 ++++++++++---
 arch/arm/include/asm/spinlock_types.h |  2 +-
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index 0de7bec..3c8c532 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -5,7 +5,7 @@
 #error SMP not supported on pre-ARMv6 CPUs
 #endif
 
-#include <asm/processor.h>
+#include <linux/prefetch.h>
 
 /*
  * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
@@ -70,6 +70,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
 	u32 newval;
 	arch_spinlock_t lockval;
 
+	prefetchw(&lock->slock);
 	__asm__ __volatile__(
 "1:	ldrex	%0, [%3]\n"
 "	add	%1, %0, %4\n"
@@ -93,6 +94,7 @@ static inline int arch_spin_trylock(arch_spinlock_t *lock)
 	unsigned long contended, res;
 	u32 slock;
 
+	prefetchw(&lock->slock);
 	do {
 		__asm__ __volatile__(
 		"	ldrex	%0, [%3]\n"
@@ -145,6 +147,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
 {
 	unsigned long tmp;
 
+	prefetchw(&rw->lock);
 	__asm__ __volatile__(
 "1:	ldrex	%0, [%1]\n"
 "	teq	%0, #0\n"
@@ -163,6 +166,7 @@ static inline int arch_write_trylock(arch_rwlock_t *rw)
 {
 	unsigned long tmp;
 
+	prefetchw(&rw->lock);
 	__asm__ __volatile__(
 "	ldrex	%0, [%1]\n"
 "	teq	%0, #0\n"
@@ -193,7 +197,7 @@ static inline void arch_write_unlock(arch_rwlock_t *rw)
 }
 
 /* write_can_lock - would write_trylock() succeed? */
-#define arch_write_can_lock(x)		((x)->lock == 0)
+#define arch_write_can_lock(x)		(ACCESS_ONCE((x)->lock) == 0)
 
 /*
  * Read locks are a bit more hairy:
@@ -211,6 +215,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
 {
 	unsigned long tmp, tmp2;
 
+	prefetchw(&rw->lock);
 	__asm__ __volatile__(
 "1:	ldrex	%0, [%2]\n"
 "	adds	%0, %0, #1\n"
@@ -231,6 +236,7 @@ static inline void arch_read_unlock(arch_rwlock_t *rw)
 
 	smp_mb();
 
+	prefetchw(&rw->lock);
 	__asm__ __volatile__(
 "1:	ldrex	%0, [%2]\n"
 "	sub	%0, %0, #1\n"
@@ -249,6 +255,7 @@ static inline int arch_read_trylock(arch_rwlock_t *rw)
 {
 	unsigned long tmp, tmp2 = 1;
 
+	prefetchw(&rw->lock);
 	__asm__ __volatile__(
 "	ldrex	%0, [%2]\n"
 "	adds	%0, %0, #1\n"
@@ -262,7 +269,7 @@ static inline int arch_read_trylock(arch_rwlock_t *rw)
 }
 
 /* read_can_lock - would read_trylock() succeed? */
-#define arch_read_can_lock(x)		((x)->lock < 0x80000000)
+#define arch_read_can_lock(x)		(ACCESS_ONCE((x)->lock) < 0x80000000)
 
 #define arch_read_lock_flags(lock, flags) arch_read_lock(lock)
 #define arch_write_lock_flags(lock, flags) arch_write_lock(lock)
diff --git a/arch/arm/include/asm/spinlock_types.h b/arch/arm/include/asm/spinlock_types.h
index b262d2f..47663fc 100644
--- a/arch/arm/include/asm/spinlock_types.h
+++ b/arch/arm/include/asm/spinlock_types.h
@@ -25,7 +25,7 @@ typedef struct {
 #define __ARCH_SPIN_LOCK_UNLOCKED	{ { 0 } }
 
 typedef struct {
-	volatile unsigned int lock;
+	u32 lock;
 } arch_rwlock_t;
 
 #define __ARCH_RW_LOCK_UNLOCKED		{ 0 }
-- 
1.8.2.2



From Dave.Martin at arm.com  Thu Jul 25 11:57:00 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Thu, 25 Jul 2013 16:57:00 +0100
Subject: [PATCH 1/2] ARM: Correct BUG() assembly to ensure it is
 endian-agnostic
In-Reply-To: <1374763357-4893-2-git-send-email-ben.dooks@codethink.co.uk>
References: <1374763357-4893-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374763357-4893-2-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130725155700.GD2546@localhost.localdomain>

On Thu, Jul 25, 2013 at 03:42:36PM +0100, Ben Dooks wrote:
> Currently BUG() uses .word or .hword to create the necessary illegal
> instructions. However if we are building BE8 then these get swapped
> by the linker into different illegal instructions in the text.

In the case of Thumb, the resulting instruction is actually not illegal,
which is even worse...

> Change to using .inst and .inst.w to create the instructions and mark
> them as instructions so that the linker acts correctly.
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---
>  arch/arm/include/asm/bug.h |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
> index 7af5c6c..b95da52 100644
> --- a/arch/arm/include/asm/bug.h
> +++ b/arch/arm/include/asm/bug.h
> @@ -12,10 +12,10 @@
>   */
>  #ifdef CONFIG_THUMB2_KERNEL
>  #define BUG_INSTR_VALUE 0xde02
> -#define BUG_INSTR_TYPE ".hword "
> +#define BUG_INSTR_TYPE ".inst.w "
>  #else
>  #define BUG_INSTR_VALUE 0xe7f001f2
> -#define BUG_INSTR_TYPE ".word "
> +#define BUG_INSTR_TYPE ".inst "
>  #endif

There was some uncertainty a while ago about precisely which versions of
gas support .inst.

<asm/opcodes.h> implements an abstracted workaround for this issue,
whereby you can emit instructions using the __inst*() macros, and
the swabbing and assembler directives should be generated for you.

The patch below ought to do this for BUG(), but I've only briefly
build-tested it.


Note that the disassembly of the injected instructions in .o files
can be a bit confusing, because they are marked as data, do ld --be8
doesn't swab them (unlike the instructions, which do get swabbed).
objdump may also do extra swabbing during disassembly.

You can sanity-check what is really in the image by dumping the text
section of vmlinux with objdump -s.


The change to <asm/opcodes.h> is due to a missing include which is
really required for correctness, but which didn't show up without
the <asm/bug.h> change (this causes opcodes.h to get included way
more often than is otherwise the case).

Cheers
---Dave


diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
index 7af5c6c..e36fe85 100644
--- a/arch/arm/include/asm/bug.h
+++ b/arch/arm/include/asm/bug.h
@@ -2,6 +2,7 @@
 #define _ASMARM_BUG_H
 
 #include <linux/linkage.h>
+#include <asm/opcodes.h>
 
 #ifdef CONFIG_BUG
 
@@ -12,15 +13,15 @@
  */
 #ifdef CONFIG_THUMB2_KERNEL
 #define BUG_INSTR_VALUE 0xde02
-#define BUG_INSTR_TYPE ".hword "
+#define __BUG_INSTR __inst_thumb16(BUG_INSTR_VALUE)
 #else
 #define BUG_INSTR_VALUE 0xe7f001f2
-#define BUG_INSTR_TYPE ".word "
+#define __BUG_INSTR __inst_arm(BUG_INSTR_VALUE)
 #endif
 
 
-#define BUG() _BUG(__FILE__, __LINE__, BUG_INSTR_VALUE)
-#define _BUG(file, line, value) __BUG(file, line, value)
+#define BUG() _BUG(__FILE__, __LINE__)
+#define _BUG(file, line) __BUG(file, line)
 
 #ifdef CONFIG_DEBUG_BUGVERBOSE
 
@@ -31,9 +32,9 @@
  * avoid multiple copies of the string appearing in the kernel image.
  */
 
-#define __BUG(__file, __line, __value)				\
+#define __BUG(__file, __line)					\
 do {								\
-	asm volatile("1:\t" BUG_INSTR_TYPE #__value "\n"	\
+	asm volatile("1:\t" __BUG_INSTR "\n"			\
 		".pushsection .rodata.str, \"aMS\", %progbits, 1\n" \
 		"2:\t.asciz " #__file "\n" 			\
 		".popsection\n" 				\
@@ -46,9 +47,9 @@ do {								\
 
 #else  /* not CONFIG_DEBUG_BUGVERBOSE */
 
-#define __BUG(__file, __line, __value)				\
+#define __BUG(__file, __line)					\
 do {								\
-	asm volatile(BUG_INSTR_TYPE #__value);			\
+	asm volatile(__BUG_INSTR)				\
 	unreachable();						\
 } while (0)
 #endif  /* CONFIG_DEBUG_BUGVERBOSE */
diff --git a/arch/arm/include/asm/opcodes.h b/arch/arm/include/asm/opcodes.h
index e796c59..e94ebfd 100644
--- a/arch/arm/include/asm/opcodes.h
+++ b/arch/arm/include/asm/opcodes.h
@@ -11,6 +11,8 @@
 
 #ifndef __ASSEMBLY__
 #include <linux/linkage.h>
+#include <linux/types.h>
+
 extern asmlinkage unsigned int arm_check_condition(u32 opcode, u32 psr);
 #endif
 


From will.deacon at arm.com  Thu Jul 25 12:02:08 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 17:02:08 +0100
Subject: [PATCH] ARM: kdgb: use .inst for data to be assembled as
 intruction
In-Reply-To: <1374763778-5305-2-git-send-email-ben.dooks@codethink.co.uk>
References: <1374763778-5305-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374763778-5305-2-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130725160208.GD12827@mudshark.cambridge.arm.com>

On Thu, Jul 25, 2013 at 03:49:38PM +0100, Ben Dooks wrote:
> The arch_kgdb_breakpoint() function uses an inline assembly directive
> to assemble a specific instruction using .word. This means the linker
> will not treat is as an instruction, and therefore incorrectly swap
> the endian-ness if running BE8.
> 
> Note, not tested, please comment if this is wrong.

Can't you just look at the vmlinux disassembly to confirm this is working
correctly?

Will

> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---
>  arch/arm/include/asm/kgdb.h |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/kgdb.h b/arch/arm/include/asm/kgdb.h
> index 48066ce..76227c8 100644
> --- a/arch/arm/include/asm/kgdb.h
> +++ b/arch/arm/include/asm/kgdb.h
> @@ -41,7 +41,7 @@
>  
>  static inline void arch_kgdb_breakpoint(void)
>  {
> -	asm(".word 0xe7ffdeff");
> +	asm(".inst 0xe7ffdeff");
>  }
>  
>  extern void kgdb_handle_bus_error(void);
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From jason at lakedaemon.net  Thu Jul 25 12:03:24 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 12:03:24 -0400
Subject: Location for a kind of GPIO bus driver
In-Reply-To: <20130725154932.GL9916@kw.sim.vm.gnt>
References: <20130723151834.GJ9916@kw.sim.vm.gnt>
 <20130724181924.GI19736@titan.lakedaemon.net>
 <20130725154932.GL9916@kw.sim.vm.gnt>
Message-ID: <20130725160324.GJ23879@titan.lakedaemon.net>

On Thu, Jul 25, 2013 at 05:49:32PM +0200, Simon Guinot wrote:
> On Wed, Jul 24, 2013 at 02:19:24PM -0400, Jason Cooper wrote:
> > On Tue, Jul 23, 2013 at 05:18:34PM +0200, Simon Guinot wrote:
> > > Hi,
> > > 
> > > I am currently working on converting the LED driver leds-netxbig to DT.
> > > Doing so, I am also considering to move the GPIO extension bus functions
> > > (which are currently parts of leds-netxbig) into a separate driver.
> > > 
> > > On the LaCie "Big Network" board family (netxbig), the LEDs are
> > > controlled by a CPLD. In turn, the CPLD can be configured (mostly the
> > > LEDs modes) through a kind of parallel GPIO bus, called GPIO extension
> > > bus. Two registers (address and data) are exposed. Each of them is made
> > > up of several GPIOs. An extra GPIO is used to notify the CPLD that the
> > > registers have been updated. The leds-netxbig driver uses some dedicated
> > > functions (prefixed by "gpio_ext_") to handle the GPIO bus extension.
> > > 
> > > On the latest "Big Network" boards, this bus is also used to enable the
> > > PM wakeup sources: the CPLD can be asked to keep powered some devices
> > > (as the RTC or the Ethernet PHY) while the board is down. I think it
> > > could be nice to expose this feature to the userland. That's why I am
> > > thinking about moving the GPIO extension bus support into a separate
> > > driver. The problem is that I can't find a proper location for a such
> > > driver. AFAIK, it doesn't fit with anything existing supported by Linux.
> > > Maybe I should consider drivers/bus ? Or even drivers/misc ?
> 
> Hi Jason,
> 
> Thanks for your answer.
> 
> > 
> > iiuc, the CPLD is more of gpio multiplexer/expander.  Have you seen
> > 
> >   66bcb58 arm: mvebu: enable gpio expander over i2c on Mirabox platform
> > 
> > ?  And the corresponding driver, drivers/gpio/gpio-pca953x.c?
> 
> All the drivers under drivers/gpio are registering some GPIO chips.
> It is a big difference with the LaCie "GPIO extension bus". This last
> is more an extension mechanism on the top of GPIOs already existing
> (eventually provided by a SoC or a Super-I/O on x86 boards). No new
> GPIOs are added. I think that the name "extension" is quite confusing.

Agreed.

> The idea behind this "bus" is to allow to configure a lot of LEDs (in
> various modes) using only few GPIOs and a CPLD (which is already
> available on the board for other purposes). This cheap solution allows
> precisely to save the cost of a GPIO expander :)
> 
> As an example, you can see the "GPIO extension bus" configuration for
> the Kirkwood "Big Network" boards in:
> arch/arm/mach-kirkwood/netxbig_v2-setup.c:132.
> 
> > 
> > I would try drivers/gpio.  If there are complaints, it should be trivial
> > to move it in a new version of the series.
> 
> Why not, as long it is clear that the resulting driver will not provide
> a GPIO chip but rather functions as a library.

right, but the end result of what the library would do is expose a
series of LEDs and PM 'virtual gpios'.  So, even though it's not a gpio
expander per-se, it's still filling that role.  Or am I still missing
something?

> > Is there any reason why the new capabilities in the "Big Network" boards
> > couldn't be covered by gpio-regulator?
> 
> I don't have looked at the details but I think that gpio-regulator
> could be able to configure the PM modes through the GPIO extension bus.
> 
> But a problem remains. The same GPIOs would be used by two different
> drivers: leds-netxbig and gpio-regulator. This would lead to some
> conflicts. That's why I think that at some level a driver is needed to
> handle the GPIO extension bus.

It may be simpler to combine it into one driver and place it under
drivers/mfd as it's certainly a multi-function device.  I don't think
anyone outside of Lacie is going to be adopting this 'bus'...

thx,

Jason.


From ben.dooks at codethink.co.uk  Thu Jul 25 12:05:03 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 17:05:03 +0100
Subject: [PATCH 1/2] ARM: Correct BUG() assembly to ensure it is
 endian-agnostic
In-Reply-To: <20130725155700.GD2546@localhost.localdomain>
References: <1374763357-4893-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374763357-4893-2-git-send-email-ben.dooks@codethink.co.uk>
 <20130725155700.GD2546@localhost.localdomain>
Message-ID: <51F14CAF.5010602@codethink.co.uk>

On 25/07/13 16:57, Dave Martin wrote:
> On Thu, Jul 25, 2013 at 03:42:36PM +0100, Ben Dooks wrote:
>> Currently BUG() uses .word or .hword to create the necessary illegal
>> instructions. However if we are building BE8 then these get swapped
>> by the linker into different illegal instructions in the text.
>
> In the case of Thumb, the resulting instruction is actually not illegal,
> which is even worse...
>
>> Change to using .inst and .inst.w to create the instructions and mark
>> them as instructions so that the linker acts correctly.
>>
>> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
>> ---
>>   arch/arm/include/asm/bug.h |    4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
>> index 7af5c6c..b95da52 100644
>> --- a/arch/arm/include/asm/bug.h
>> +++ b/arch/arm/include/asm/bug.h
>> @@ -12,10 +12,10 @@
>>    */
>>   #ifdef CONFIG_THUMB2_KERNEL
>>   #define BUG_INSTR_VALUE 0xde02
>> -#define BUG_INSTR_TYPE ".hword "
>> +#define BUG_INSTR_TYPE ".inst.w "
>>   #else
>>   #define BUG_INSTR_VALUE 0xe7f001f2
>> -#define BUG_INSTR_TYPE ".word "
>> +#define BUG_INSTR_TYPE ".inst "
>>   #endif
>
> There was some uncertainty a while ago about precisely which versions of
> gas support .inst.
>
> <asm/opcodes.h>  implements an abstracted workaround for this issue,
> whereby you can emit instructions using the __inst*() macros, and
> the swabbing and assembler directives should be generated for you.
>
> The patch below ought to do this for BUG(), but I've only briefly
> build-tested it.
>
>
> Note that the disassembly of the injected instructions in .o files
> can be a bit confusing, because they are marked as data, do ld --be8
> doesn't swab them (unlike the instructions, which do get swabbed).
> objdump may also do extra swabbing during disassembly.
>
> You can sanity-check what is really in the image by dumping the text
> section of vmlinux with objdump -s.
>
>
> The change to<asm/opcodes.h>  is due to a missing include which is
> really required for correctness, but which didn't show up without
> the<asm/bug.h>  change (this causes opcodes.h to get included way
> more often than is otherwise the case).
>
> Cheers
> ---Dave

Given it was added ~2006 according the mailing lists I have seen, then
it should be ok to use for building modern kernels with. I think the
use of .inst and .inst.w is a better solution than having the code
having bits of it marked as data.

>
> diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
> index 7af5c6c..e36fe85 100644
> --- a/arch/arm/include/asm/bug.h
> +++ b/arch/arm/include/asm/bug.h
> @@ -2,6 +2,7 @@
>   #define _ASMARM_BUG_H
>
>   #include<linux/linkage.h>
> +#include<asm/opcodes.h>
>
>   #ifdef CONFIG_BUG
>
> @@ -12,15 +13,15 @@
>    */
>   #ifdef CONFIG_THUMB2_KERNEL
>   #define BUG_INSTR_VALUE 0xde02
> -#define BUG_INSTR_TYPE ".hword "
> +#define __BUG_INSTR __inst_thumb16(BUG_INSTR_VALUE)
>   #else
>   #define BUG_INSTR_VALUE 0xe7f001f2
> -#define BUG_INSTR_TYPE ".word "
> +#define __BUG_INSTR __inst_arm(BUG_INSTR_VALUE)
>   #endif
>
>
> -#define BUG() _BUG(__FILE__, __LINE__, BUG_INSTR_VALUE)
> -#define _BUG(file, line, value) __BUG(file, line, value)
> +#define BUG() _BUG(__FILE__, __LINE__)
> +#define _BUG(file, line) __BUG(file, line)
>
>   #ifdef CONFIG_DEBUG_BUGVERBOSE
>
> @@ -31,9 +32,9 @@
>    * avoid multiple copies of the string appearing in the kernel image.
>    */
>
> -#define __BUG(__file, __line, __value)				\
> +#define __BUG(__file, __line)					\
>   do {								\
> -	asm volatile("1:\t" BUG_INSTR_TYPE #__value "\n"	\
> +	asm volatile("1:\t" __BUG_INSTR "\n"			\
>   		".pushsection .rodata.str, \"aMS\", %progbits, 1\n" \
>   		"2:\t.asciz " #__file "\n" 			\
>   		".popsection\n" 				\
> @@ -46,9 +47,9 @@ do {								\
>
>   #else  /* not CONFIG_DEBUG_BUGVERBOSE */
>
> -#define __BUG(__file, __line, __value)				\
> +#define __BUG(__file, __line)					\
>   do {								\
> -	asm volatile(BUG_INSTR_TYPE #__value);			\
> +	asm volatile(__BUG_INSTR)				\
>   	unreachable();						\
>   } while (0)
>   #endif  /* CONFIG_DEBUG_BUGVERBOSE */
> diff --git a/arch/arm/include/asm/opcodes.h b/arch/arm/include/asm/opcodes.h
> index e796c59..e94ebfd 100644
> --- a/arch/arm/include/asm/opcodes.h
> +++ b/arch/arm/include/asm/opcodes.h
> @@ -11,6 +11,8 @@
>
>   #ifndef __ASSEMBLY__
>   #include<linux/linkage.h>
> +#include<linux/types.h>
> +
>   extern asmlinkage unsigned int arm_check_condition(u32 opcode, u32 psr);
>   #endif
>


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From nicolas.pitre at linaro.org  Thu Jul 25 12:06:51 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 25 Jul 2013 12:06:51 -0400 (EDT)
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value
 to index into save array
In-Reply-To: <20130725105528.GA2546@localhost.localdomain>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-2-git-send-email-nicolas.pitre@linaro.org>
 <20130724164717.GA4610@localhost.localdomain>
 <alpine.LFD.2.03.1307241437460.15022@syhkavp.arg>
 <20130725105528.GA2546@localhost.localdomain>
Message-ID: <alpine.LFD.2.03.1307251203550.15022@syhkavp.arg>

On Thu, 25 Jul 2013, Dave Martin wrote:

> On Wed, Jul 24, 2013 at 02:55:00PM -0400, Nicolas Pitre wrote:
> > On Wed, 24 Jul 2013, Dave Martin wrote:
> > 
> > > But this patch commits us to requiring that on the suspend path 
> > > specifically -- I think that ought to be mentioned somewhere. A 
> > > comment in the preamble for __cpu_suspend would be enough, I think.
> > 
> > What comment would you suggest?  I want to make sure the possible 
> > confusion you see is properly addressed.
> 
> I think we just need to state that the value of
> cpu_logical_map(smp_processor_id()) must be the MPIDR of the physical
> CPU the suspending logical CPU will resume on.  Consequently, if doing a
> migration, cpu_logical_map() must be updated appropriately somewhere
> between cpu_pm_enter() and cpu_suspend().

Excellent.  I've amended the patch with this:

diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 2835d35234..caf938db62 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -17,6 +17,11 @@ extern void cpu_resume_mmu(void);
 /*
  * Hide the first two arguments to __cpu_suspend - these are an implementation
  * detail which platform code shouldn't have to know about.
+ *
+ * On SMP systems, the value of cpu_logical_map(smp_processor_id()) must be
+ * the MPIDR of the physical CPU the suspending logical CPU will resume on.
+ * Consequently, if doing a physical CPU migration, cpu_logical_map() must be
+ * updated appropriately somewhere between cpu_pm_enter() and cpu_suspend().
  */
 int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
 {

I've put it against cpu_suspend() rather than __cpu_suspend(() as this 
is what users should care about.

ACK?


Nicolas


From olof at lixom.net  Thu Jul 25 12:09:19 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 25 Jul 2013 09:09:19 -0700
Subject: DT bindings as ABI [was: Do we have people interested in device tree
 janitoring / cleanup?]
Message-ID: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>

[I'm adding LKML and ksummit-discuss to this thread, since the ACPI/DT
discussions have been covered there and this overlaps some with that]

On Thu, Jul 25, 2013 at 7:38 AM, Catalin Marinas
<catalin.marinas at arm.com> wrote:
> On Thu, Jul 25, 2013 at 03:27:02PM +0100, Russell King - ARM Linux wrote:
>> Remember the stated assertion when DT was first added to the kernel: the
>> DT descriptions _will_ become a separately maintained project which is
>> independent of the kernel.  They will _not_ be kernel version specific.
>
> I'm looking forward to this.
>
> Question for the DT guys: what are the plans here? Are we going to get
> rid of the .dts files inside the kernel tree?

In the discussions we had in Dublin, a couple of options on how to
lock in bindings were discussed. I'm a little surprised that Grant
didn't cover them in his initial emails on the new maintainership
model, but maybe he wanted the new group to handle it. And they didn't
bring it up yet either. So I am. :-)

Until now, we have been working under the assumption that the bindings
are _NOT LOCKED_. I.e. they can change as needed, and we _ARE_
assuming that the device tree has to match the kernel. That has been a
good choice as people get up to speed on what is a good binding and
not, and has given us much-needed room to adjust things as needed.
That obviously has to change, but doing so needs to be done carefully.

It's likely that we still want to have a period in which a binding is
tentative and can be changed. Sometimes we don't know what we really
want until after we've used it a while, and sometimes we, like
everybody else, make mistakes on what is a good idea and not. The
alternative is to grind most new binding proposals to a halt while we
spend mind-numbing hours and hours on polishing every single aspect of
the binding to a perfect shine, since we can't go back and fix it.

So, there really seems to be a need for a layered approach, one in
which a binding "graduates" from being tentative to being locked in.
I'm refraining from using the terms "staging" and "stable" here, since
they have overloaded meaning in the kernel world that doesn't apply
here.

One problem that needs to be solved is obviously how a binding
graduates from tentative to locked. This work isn't going to be very
interesting to most people, I suspect. Think standards committee type
work.

A possible way to handle this is to have exactly that: A group of
people that essentially constitute the "standards committee" that meet
on a regular basis to review and approve new bindings. They should be
people not just doing ARM Linux work, but other stakeholders in these
bindings too. One of the things they should probably do is sift
through our current in-kernel bindings and select those who seem ready
to be locked in, review/discuss/decide upon that and once the decision
is made, that specific binding does become part of the static,
never-ever-change ABI of firmware-to-kernel interfaces.   That might
also be the time that the binding is moved from the kernel to a
separate repo, but that's a technicality that we'll let the DT
maintainers decide among themselves, IMHO.

I think that captures most of what we discussed in person. Others
might have changed their opinions since then, so I'm definitely not
claiming that any of this was an official decision made by anybody.
It's just one proposal on how to handle these things moving forward.


-Olof


From sboyd at codeaurora.org  Thu Jul 25 12:13:37 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Jul 2013 09:13:37 -0700
Subject: [GIT PULL] Remove ARM local timer API
In-Reply-To: <CAOesGMiornt0twdQv=tYMtAX56Lc79MVyNrHaK1nWpOk189dDA@mail.gmail.com>
References: <20130625200211.GA11625@codeaurora.org>
 <CAOesGMj5AZcB7-kcS8_JqfKAg_RUKqTdDZf7bdwkebn3pwADAw@mail.gmail.com>
 <20130723234040.GB27761@codeaurora.org>
 <CAOesGMiornt0twdQv=tYMtAX56Lc79MVyNrHaK1nWpOk189dDA@mail.gmail.com>
Message-ID: <20130725161337.GA29694@codeaurora.org>

On 07/23, Olof Johansson wrote:
> On Tue, Jul 23, 2013 at 4:40 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
> > On 07/23, Olof Johansson wrote:
> 
> >> Merged in as localtimer/removal into next/cleanup.
> >>
> >> I had quite a few merge conflicts due to the __cpuinit removal, so
> >> please double-check my resolutions.
> >>
> >
> > A __cpuinit is leftover in smp_twd.c. Hopefully you can just
> > redo the merge?
> 
> Done, thanks for catching it. I thought I grepped for them but I
> somehow missed that one. Fixed now.
> 

Also I think a HAVE_CAN_FLEXCAN if CAN was dragged in to
arch/arm/mach-imx/Kconfig. Here's a patch.

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 21fa9fa..1303e33 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -794,7 +794,6 @@ config SOC_IMX6Q
 	select CPU_V7
 	select HAVE_ARM_SCU if SMP
 	select HAVE_ARM_TWD if SMP
-	select HAVE_CAN_FLEXCAN if CAN
 	select HAVE_IMX_ANATOP
 	select HAVE_IMX_GPC
 	select HAVE_IMX_MMDC

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From steve.capper at linaro.org  Thu Jul 25 12:20:47 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Thu, 25 Jul 2013 17:20:47 +0100
Subject: [RFC 0/2] ARM: mm: HugeTLB + THP support for non-LPAE
Message-ID: <1374769249-15908-1-git-send-email-steve.capper@linaro.org>

Hello,

The following patches bring both HugeTLB support and Transparent
HugePage (THP) support to ARM for 2 levels of paging (i.e. without
LPAE).

This code has been tested on an Arndale board (Exynos 5250), and
is based on 3.11-rc1, with the hugepage simplification patch:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/184117.html

HugeTLB and THP support for LPAE has already been merged in 3.11-rc1.

Hugepages can give nice performance boosts to workloads that put
pressure on the TLBs. I've observed uplifts of ~5% to some tasks
just by enabling hugepages via the libhugetlbfs tools. Other
people have observed decent performance boosts when huge pages
are enabled:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-February/148835.html

I would appreciate any discussion on these patches, as there are
people who have an interest in having huge page support in
non-LPAE kernels.

Cheers,
-- 
Steve

Steve Capper (2):
  ARM: mm: HugeTLB support for non-LPAE systems.
  ARM: mm: Transparent huge page support for non-LPAE systems.

 arch/arm/Kconfig                      |   4 +-
 arch/arm/include/asm/hugetlb-2level.h | 126 +++++++++++++++++++++++++
 arch/arm/include/asm/hugetlb.h        |   4 +
 arch/arm/include/asm/pgtable-2level.h | 170 ++++++++++++++++++++++++++++++++++
 arch/arm/include/asm/pgtable-3level.h |   6 ++
 arch/arm/include/asm/pgtable.h        |   7 +-
 arch/arm/include/asm/tlb.h            |  10 +-
 arch/arm/kernel/head.S                |  10 +-
 arch/arm/mm/fault.c                   |  13 ---
 arch/arm/mm/fsr-2level.c              |   4 +-
 arch/arm/mm/hugetlbpage.c             |   2 +-
 arch/arm/mm/mmu.c                     |  27 ++++++
 12 files changed, 360 insertions(+), 23 deletions(-)
 create mode 100644 arch/arm/include/asm/hugetlb-2level.h

-- 
1.8.1.4



From steve.capper at linaro.org  Thu Jul 25 12:25:06 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Thu, 25 Jul 2013 17:25:06 +0100
Subject: [RFC 1/2] ARM: mm: HugeTLB support for non-LPAE systems.
Message-ID: <1374769506-16005-1-git-send-email-steve.capper@linaro.org>

Based on Bill Carson's HugeTLB patch, with the big difference being
in the way PTEs are passed back to the memory manager. Rather than
store a "Linux Huge PTE" separately; we make one up on the fly in
huge_ptep_get. Also rather than consider 16M supersections, we focus
solely on 2x1M sections.

To construct a huge PTE on the fly we need additional information
(such as the accessed flag and dirty bit) which we choose to store
in the domain bits of the short section descriptor. In order to use
these domain bits for storage, we need to make ourselves a client
for all 16 domains and this is done in head.S.

Storing extra information in the domain bits also makes it a lot
easier to implement Transparent Huge Pages, and some of the code in
pgtable-2level.h is arranged to facilitate THP support in a later
patch.

Non-LPAE HugeTLB pages are incompatible with the huge page migration
code (enabled when CONFIG_MEMORY_FAILURE is selected) as that code
dereferences PTEs directly, rather than calling huge_ptep_get and
set_huge_pte_at.

Signed-off-by: Steve Capper <steve.capper at linaro.org>
---
 arch/arm/Kconfig                      |   2 +-
 arch/arm/include/asm/hugetlb-2level.h | 126 ++++++++++++++++++++++++++++++++++
 arch/arm/include/asm/hugetlb.h        |   4 ++
 arch/arm/include/asm/pgtable-2level.h | 123 +++++++++++++++++++++++++++++++++
 arch/arm/include/asm/pgtable-3level.h |   5 ++
 arch/arm/include/asm/pgtable.h        |   5 ++
 arch/arm/include/asm/tlb.h            |  10 ++-
 arch/arm/kernel/head.S                |  10 ++-
 arch/arm/mm/fault.c                   |  13 ----
 arch/arm/mm/fsr-2level.c              |   4 +-
 arch/arm/mm/hugetlbpage.c             |   2 +-
 arch/arm/mm/mmu.c                     |  27 ++++++++
 12 files changed, 311 insertions(+), 20 deletions(-)
 create mode 100644 arch/arm/include/asm/hugetlb-2level.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d0fd5bf..fe6eeae 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1751,7 +1751,7 @@ config HW_PERF_EVENTS
 
 config SYS_SUPPORTS_HUGETLBFS
        def_bool y
-       depends on ARM_LPAE
+       depends on ARM_LPAE || (!CPU_USE_DOMAINS && !MEMORY_FAILURE)
 
 config HAVE_ARCH_TRANSPARENT_HUGEPAGE
        def_bool y
diff --git a/arch/arm/include/asm/hugetlb-2level.h b/arch/arm/include/asm/hugetlb-2level.h
new file mode 100644
index 0000000..c00fbee
--- /dev/null
+++ b/arch/arm/include/asm/hugetlb-2level.h
@@ -0,0 +1,126 @@
+/*
+ * arch/arm/include/asm/hugetlb-2level.h
+ *
+ * Copyright (C) 2013 Linaro Ltd.
+ *
+ * Based on arch/x86/include/asm/hugetlb.h and Bill Carson's patches
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef _ASM_ARM_HUGETLB_2LEVEL_H
+#define _ASM_ARM_HUGETLB_2LEVEL_H
+
+
+static inline pte_t huge_ptep_get(pte_t *ptep)
+{
+	pmd_t pmd =  *((pmd_t *)ptep);
+	pte_t retval;
+
+	if (!pmd_val(pmd))
+		return __pte(0);
+
+	retval = __pte((pteval_t) (pmd_val(pmd) & HPAGE_MASK)
+			| arm_hugepteprotval);
+
+	if (pmd_exec(pmd))
+		retval = pte_mkexec(retval);
+	else
+		retval = pte_mknexec(retval);
+
+	if (pmd_young(pmd))
+		retval = pte_mkyoung(retval);
+	else
+		retval = pte_mkold(retval);
+
+	if (pmd_dirty(pmd))
+		retval = pte_mkdirty(retval);
+	else
+		retval = pte_mkclean(retval);
+
+	if (pmd_write(pmd))
+		retval = pte_mkwrite(retval);
+	else
+		retval = pte_wrprotect(retval);
+
+	if (pmd_protnone(pmd))
+		retval = pte_mkprotnone(retval);
+	else
+		retval = pte_rmprotnone(retval);
+
+	return retval;
+}
+
+static inline void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
+				   pte_t *ptep, pte_t pte)
+{
+	pmdval_t pmdval = (pmdval_t) pte_val(pte);
+	pmd_t *pmdp = (pmd_t *) ptep;
+
+	/* take the target address bits from the pte only */
+	pmdval &= HPAGE_MASK;
+
+	/*
+	 * now use pmd_modify to translate the permission bits from the pte
+	 * and set the memory type information.
+	 */
+	pmdval = pmd_val(pmd_modify(__pmd(pmdval), __pgprot(pte_val(pte))));
+
+	__sync_icache_dcache(pte);
+
+	set_pmd_at(mm, addr, pmdp, __pmd(pmdval));
+}
+
+static inline pte_t pte_mkhuge(pte_t pte) { return pte; }
+
+static inline void huge_ptep_clear_flush(struct vm_area_struct *vma,
+					 unsigned long addr, pte_t *ptep)
+{
+	pmd_t *pmdp = (pmd_t *)ptep;
+	pmd_clear(pmdp);
+	flush_tlb_range(vma, addr, addr + HPAGE_SIZE);
+}
+
+static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
+					   unsigned long addr, pte_t *ptep)
+{
+	pmd_t *pmdp = (pmd_t *) ptep;
+	set_pmd_at(mm, addr, pmdp, pmd_wrprotect(*pmdp));
+}
+
+
+static inline pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
+					    unsigned long addr, pte_t *ptep)
+{
+	pmd_t *pmdp = (pmd_t *)ptep;
+	pte_t pte = huge_ptep_get(ptep);
+	pmd_clear(pmdp);
+
+	return pte;
+}
+
+static inline int huge_ptep_set_access_flags(struct vm_area_struct *vma,
+					     unsigned long addr, pte_t *ptep,
+					     pte_t pte, int dirty)
+{
+	int changed = !pte_same(huge_ptep_get(ptep), pte);
+	if (changed) {
+		set_huge_pte_at(vma->vm_mm, addr, ptep, pte);
+		flush_tlb_range(vma, addr, addr + HPAGE_SIZE);
+	}
+
+	return changed;
+}
+
+#endif /* _ASM_ARM_HUGETLB_2LEVEL_H */
diff --git a/arch/arm/include/asm/hugetlb.h b/arch/arm/include/asm/hugetlb.h
index 1f1b1cd..6c0372a 100644
--- a/arch/arm/include/asm/hugetlb.h
+++ b/arch/arm/include/asm/hugetlb.h
@@ -25,7 +25,11 @@
 #include <asm/page.h>
 #include <asm-generic/hugetlb.h>
 
+#ifdef CONFIG_ARM_LPAE
 #include <asm/hugetlb-3level.h>
+#else
+#include <asm/hugetlb-2level.h>
+#endif
 
 static inline void hugetlb_free_pgd_range(struct mmu_gather *tlb,
 					  unsigned long addr, unsigned long end,
diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h
index f97ee02..29ace75 100644
--- a/arch/arm/include/asm/pgtable-2level.h
+++ b/arch/arm/include/asm/pgtable-2level.h
@@ -155,6 +155,20 @@
 #define pud_clear(pudp)		do { } while (0)
 #define set_pud(pud,pudp)	do { } while (0)
 
+static inline int pmd_large(pmd_t pmd)
+{
+	if ((pmd_val(pmd) & PMD_TYPE_MASK) == PMD_TYPE_FAULT)
+		return pmd_val(pmd);
+
+	return ((pmd_val(pmd) & PMD_TYPE_MASK) == PMD_TYPE_SECT);
+}
+
+static inline int pte_huge(pte_t pte)
+{
+	pmd_t pmd = (pmd_t)pte;
+	return pmd_large(pmd);
+}
+
 static inline pmd_t *pmd_offset(pud_t *pud, unsigned long addr)
 {
 	return (pmd_t *)pud;
@@ -181,6 +195,115 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long addr)
 
 #define set_pte_ext(ptep,pte,ext) cpu_set_pte_ext(ptep,pte,ext)
 
+/*
+ * now follows some of the definitions to allow huge page support, we can't put
+ * these in the hugetlb source files as they are also required for transparent
+ * hugepage support.
+ */
+
+#define HPAGE_SHIFT             PMD_SHIFT
+#define HPAGE_SIZE              (_AC(1, UL) << HPAGE_SHIFT)
+#define HPAGE_MASK              (~(HPAGE_SIZE - 1))
+#define HUGETLB_PAGE_ORDER      (HPAGE_SHIFT - PAGE_SHIFT)
+
+#define HUGE_LINUX_PTE_COUNT       (PAGE_OFFSET >> HPAGE_SHIFT)
+#define HUGE_LINUX_PTE_SIZE        (HUGE_LINUX_PTE_COUNT * sizeof(pte_t *))
+#define HUGE_LINUX_PTE_INDEX(addr) (addr >> HPAGE_SHIFT)
+
+/*
+ *  We re-purpose the following domain bits in the section descriptor
+ */
+#define PMD_DOMAIN_MASK		(_AT(pmdval_t, 0xF) << 5)
+#define PMD_DSECT_PROT_NONE	(_AT(pmdval_t, 1) << 5)
+#define PMD_DSECT_DIRTY		(_AT(pmdval_t, 1) << 6)
+#define PMD_DSECT_AF		(_AT(pmdval_t, 1) << 7)
+
+#define PMD_BIT_FUNC(fn,op) \
+static inline pmd_t pmd_##fn(pmd_t pmd) { pmd_val(pmd) op; return pmd; }
+
+extern pmdval_t arm_hugepmdprotval;
+extern pteval_t arm_hugepteprotval;
+
+#define pmd_mkhuge(pmd)		(__pmd((pmd_val(pmd) & ~PMD_TYPE_MASK) | PMD_TYPE_SECT))
+
+PMD_BIT_FUNC(mkold, &= ~PMD_DSECT_AF);
+PMD_BIT_FUNC(mkdirty, |= PMD_DSECT_DIRTY);
+PMD_BIT_FUNC(mkclean, &= ~PMD_DSECT_DIRTY);
+PMD_BIT_FUNC(mkyoung, |= PMD_DSECT_AF);
+PMD_BIT_FUNC(mkwrite, |= PMD_SECT_AP_WRITE);
+PMD_BIT_FUNC(wrprotect,	&= ~PMD_SECT_AP_WRITE);
+PMD_BIT_FUNC(mknotpresent, &= ~PMD_TYPE_MASK);
+PMD_BIT_FUNC(mkexec,	&= ~PMD_SECT_XN);
+PMD_BIT_FUNC(mknexec,	|= PMD_SECT_XN);
+PMD_BIT_FUNC(mkprotnone, |= PMD_DSECT_PROT_NONE);
+PMD_BIT_FUNC(rmprotnone, &= ~PMD_DSECT_PROT_NONE);
+
+#define pmd_protnone(pmd)		(pmd_val(pmd) & PMD_DSECT_PROT_NONE)
+#define pmd_young(pmd)			(pmd_val(pmd) & PMD_DSECT_AF)
+#define pmd_write(pmd)			(pmd_val(pmd) & PMD_SECT_AP_WRITE)
+#define pmd_exec(pmd)			(!(pmd_val(pmd) & PMD_SECT_XN))
+#define pmd_dirty(pmd)			(pmd_val(pmd) & PMD_DSECT_DIRTY)
+
+#define __HAVE_ARCH_PMD_WRITE
+
+static inline void set_pmd_at(struct mm_struct *mm, unsigned long addr,
+				pmd_t *pmdp, pmd_t pmd)
+{
+	/*
+	 * we can sometimes be passed a pmd pointing to a level 2 descriptor
+	 * from collapse_huge_page.
+	 */
+	if ((pmd_val(pmd) & PMD_TYPE_MASK) == PMD_TYPE_TABLE) {
+		pmdp[0] = __pmd(pmd_val(pmd));
+		pmdp[1] = __pmd(pmd_val(pmd) + 256 * sizeof(pte_t));
+	} else {
+		if (pmd_protnone(pmd))
+			pmd_val(pmd) &= ~PMD_TYPE_MASK;
+		else
+			pmd_val(pmd) |= PMD_TYPE_SECT;
+
+		pmdp[0] = __pmd(pmd_val(pmd));
+		pmdp[1] = __pmd(pmd_val(pmd) + SECTION_SIZE);
+	}
+
+	flush_pmd_entry(pmdp);
+}
+
+#define pmd_modify(pmd, prot)							\
+({										\
+	pmd_t pmdret = __pmd((pmd_val(pmd) & (PMD_MASK | PMD_DOMAIN_MASK)) 	\
+		| arm_hugepmdprotval);						\
+	pgprot_t inprot = prot;							\
+	pte_t newprot = __pte(pgprot_val(inprot));				\
+										\
+	if (pte_dirty(newprot))							\
+		pmdret = pmd_mkdirty(pmdret);					\
+	else									\
+		pmdret = pmd_mkclean(pmdret);					\
+										\
+	if (pte_exec(newprot))							\
+		pmdret = pmd_mkexec(pmdret);					\
+	else									\
+		pmdret = pmd_mknexec(pmdret);					\
+										\
+	if (pte_write(newprot))							\
+		pmdret = pmd_mkwrite(pmdret);					\
+	else									\
+		pmdret = pmd_wrprotect(pmdret);					\
+										\
+	if (pte_young(newprot))							\
+		pmdret = pmd_mkyoung(pmdret);					\
+	else									\
+		pmdret = pmd_mkold(pmdret);					\
+										\
+	if (pte_protnone(newprot))						\
+		pmdret = pmd_mkprotnone(pmdret);				\
+	else									\
+		pmdret = pmd_rmprotnone(pmdret);				\
+										\
+	pmdret;									\
+})
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_PGTABLE_2LEVEL_H */
diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
index 5689c18..67a0e06 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -153,6 +153,11 @@
 		flush_pmd_entry(pudp);	\
 	} while (0)
 
+static inline int pmd_large(pmd_t pmd)
+{
+	return pmd_val(pmd) && !(pmd_val(pmd) & PMD_TABLE_BIT);
+}
+
 static inline pmd_t *pud_page_vaddr(pud_t pud)
 {
 	return __va(pud_val(pud) & PHYS_MASK & (s32)PAGE_MASK);
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 04aeb02..cf77a59 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -220,6 +220,7 @@ static inline pte_t *pmd_page_vaddr(pmd_t pmd)
 #define pte_dirty(pte)		(pte_val(pte) & L_PTE_DIRTY)
 #define pte_young(pte)		(pte_val(pte) & L_PTE_YOUNG)
 #define pte_exec(pte)		(!(pte_val(pte) & L_PTE_XN))
+#define pte_protnone(pte)	(pte_val(pte) & L_PTE_NONE)
 #define pte_special(pte)	(0)
 
 #define pte_present_user(pte)  (pte_present(pte) && (pte_val(pte) & L_PTE_USER))
@@ -254,6 +255,10 @@ PTE_BIT_FUNC(mkclean,   &= ~L_PTE_DIRTY);
 PTE_BIT_FUNC(mkdirty,   |= L_PTE_DIRTY);
 PTE_BIT_FUNC(mkold,     &= ~L_PTE_YOUNG);
 PTE_BIT_FUNC(mkyoung,   |= L_PTE_YOUNG);
+PTE_BIT_FUNC(mkexec,	&= ~L_PTE_XN);
+PTE_BIT_FUNC(mknexec,	|= L_PTE_XN);
+PTE_BIT_FUNC(mkprotnone,|= L_PTE_NONE);
+PTE_BIT_FUNC(rmprotnone,&= ~L_PTE_NONE);
 
 static inline pte_t pte_mkspecial(pte_t pte) { return pte; }
 
diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h
index 46e7cfb..ddb77e5 100644
--- a/arch/arm/include/asm/tlb.h
+++ b/arch/arm/include/asm/tlb.h
@@ -80,10 +80,16 @@ static inline void tlb_flush(struct mmu_gather *tlb)
 static inline void tlb_add_flush(struct mmu_gather *tlb, unsigned long addr)
 {
 	if (!tlb->fullmm) {
+		unsigned long size = PAGE_SIZE;
+
 		if (addr < tlb->range_start)
 			tlb->range_start = addr;
-		if (addr + PAGE_SIZE > tlb->range_end)
-			tlb->range_end = addr + PAGE_SIZE;
+
+		if (tlb->vma && is_vm_hugetlb_page(tlb->vma))
+			size = HPAGE_SIZE;
+
+		if (addr + size > tlb->range_end)
+			tlb->range_end = addr + size;
 	}
 }
 
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 45e8935..fb1df2f 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -429,13 +429,21 @@ __enable_mmu:
 	bic	r0, r0, #CR_I
 #endif
 #ifndef CONFIG_ARM_LPAE
+#ifndef	CONFIG_SYS_SUPPORTS_HUGETLBFS
 	mov	r5, #(domain_val(DOMAIN_USER, DOMAIN_MANAGER) | \
 		      domain_val(DOMAIN_KERNEL, DOMAIN_MANAGER) | \
 		      domain_val(DOMAIN_TABLE, DOMAIN_MANAGER) | \
 		      domain_val(DOMAIN_IO, DOMAIN_CLIENT))
+#else
+	@ set ourselves as the client in all domains
+	@ this allows us to then use the 4 domain bits in the
+	@ section descriptors in our transparent huge pages
+	ldr	r5, =0x55555555
+#endif /* CONFIG_SYS_SUPPORTS_HUGETLBFS */
+
 	mcr	p15, 0, r5, c3, c0, 0		@ load domain access register
 	mcr	p15, 0, r4, c2, c0, 0		@ load page table pointer
-#endif
+#endif /* CONFIG_ARM_LPAE */
 	b	__turn_mmu_on
 ENDPROC(__enable_mmu)
 
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index c97f794..95d53f9 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -488,19 +488,6 @@ do_translation_fault(unsigned long addr, unsigned int fsr,
 #endif					/* CONFIG_MMU */
 
 /*
- * Some section permission faults need to be handled gracefully.
- * They can happen due to a __{get,put}_user during an oops.
- */
-#ifndef CONFIG_ARM_LPAE
-static int
-do_sect_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
-{
-	do_bad_area(addr, fsr, regs);
-	return 0;
-}
-#endif /* CONFIG_ARM_LPAE */
-
-/*
  * This abort handler always returns "fault".
  */
 static int
diff --git a/arch/arm/mm/fsr-2level.c b/arch/arm/mm/fsr-2level.c
index 18ca74c..c1a2afc 100644
--- a/arch/arm/mm/fsr-2level.c
+++ b/arch/arm/mm/fsr-2level.c
@@ -16,7 +16,7 @@ static struct fsr_info fsr_info[] = {
 	{ do_bad,		SIGBUS,	 0,		"external abort on non-linefetch"  },
 	{ do_bad,		SIGSEGV, SEGV_ACCERR,	"page domain fault"		   },
 	{ do_bad,		SIGBUS,	 0,		"external abort on translation"	   },
-	{ do_sect_fault,	SIGSEGV, SEGV_ACCERR,	"section permission fault"	   },
+	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"section permission fault"	   },
 	{ do_bad,		SIGBUS,	 0,		"external abort on translation"	   },
 	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"page permission fault"		   },
 	/*
@@ -56,7 +56,7 @@ static struct fsr_info ifsr_info[] = {
 	{ do_bad,		SIGBUS,  0,		"unknown 10"			   },
 	{ do_bad,		SIGSEGV, SEGV_ACCERR,	"page domain fault"		   },
 	{ do_bad,		SIGBUS,	 0,		"external abort on translation"	   },
-	{ do_sect_fault,	SIGSEGV, SEGV_ACCERR,	"section permission fault"	   },
+	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"section permission fault"	   },
 	{ do_bad,		SIGBUS,	 0,		"external abort on translation"	   },
 	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"page permission fault"		   },
 	{ do_bad,		SIGBUS,  0,		"unknown 16"			   },
diff --git a/arch/arm/mm/hugetlbpage.c b/arch/arm/mm/hugetlbpage.c
index 66781bf..5b63ec6 100644
--- a/arch/arm/mm/hugetlbpage.c
+++ b/arch/arm/mm/hugetlbpage.c
@@ -54,5 +54,5 @@ int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep)
 
 int pmd_huge(pmd_t pmd)
 {
-	return pmd_val(pmd) && !(pmd_val(pmd) & PMD_TABLE_BIT);
+	return pmd_large(pmd);
 }
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 4f56617..e39dc0b 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -336,6 +336,21 @@ const struct mem_type *get_mem_type(unsigned int type)
 EXPORT_SYMBOL(get_mem_type);
 
 /*
+ * If the system supports huge pages and we are running with short descriptors,
+ * then compute the pmd and linux pte prot values for a huge page.
+ *
+ * These values are used by both the HugeTLB and THP code.
+ */
+#if defined(CONFIG_SYS_SUPPORTS_HUGETLBFS) && !defined(CONFIG_ARM_LPAE)
+pmdval_t arm_hugepmdprotval;
+EXPORT_SYMBOL(arm_hugepmdprotval);
+
+pteval_t arm_hugepteprotval;
+EXPORT_SYMBOL(arm_hugepteprotval);
+#endif
+
+
+/*
  * Adjust the PMD section entries according to the CPU in use.
  */
 static void __init build_mem_type_table(void)
@@ -566,6 +581,18 @@ static void __init build_mem_type_table(void)
 		if (t->prot_sect)
 			t->prot_sect |= PMD_DOMAIN(t->domain);
 	}
+
+#if defined(CONFIG_SYS_SUPPORTS_HUGETLBFS) && !defined(CONFIG_ARM_LPAE)
+	/*
+	 * we assume all huge pages are user pages and that hardware access
+	 * flag updates are disabled (i.e. SCTLR.AFE == 0b).
+	 */
+	arm_hugepteprotval = mem_types[MT_MEMORY].prot_pte | L_PTE_USER | L_PTE_VALID;
+
+	arm_hugepmdprotval = mem_types[MT_MEMORY].prot_sect | PMD_SECT_AP_READ
+				| PMD_SECT_nG;
+#endif
+
 }
 
 #ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
-- 
1.8.1.4



From steve.capper at linaro.org  Thu Jul 25 12:26:35 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Thu, 25 Jul 2013 17:26:35 +0100
Subject: [RFC 2/2] ARM: mm: Transparent huge page support for non-LPAE systems.
Message-ID: <1374769595-16043-1-git-send-email-steve.capper@linaro.org>

Much of the required code for THP has been implemented in the
earlier non-LPAE HugeTLB patch.

One more domain bit is used (to store whether or not the THP is
splitting).

Some THP helper functions are defined; and we have to re-define
pmd_page such that it distinguishes between page tables and
sections.

Signed-off-by: Steve Capper <steve.capper at linaro.org>
---
 arch/arm/Kconfig                      |  2 +-
 arch/arm/include/asm/pgtable-2level.h | 47 +++++++++++++++++++++++++++++++++++
 arch/arm/include/asm/pgtable-3level.h |  1 +
 arch/arm/include/asm/pgtable.h        |  2 --
 4 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fe6eeae..6b53969 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1755,7 +1755,7 @@ config SYS_SUPPORTS_HUGETLBFS
 
 config HAVE_ARCH_TRANSPARENT_HUGEPAGE
        def_bool y
-       depends on ARM_LPAE
+       depends on SYS_SUPPORTS_HUGETLBFS
 
 config ARCH_WANT_GENERAL_HUGETLB
 	def_bool y
diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h
index 29ace75..a48eddc 100644
--- a/arch/arm/include/asm/pgtable-2level.h
+++ b/arch/arm/include/asm/pgtable-2level.h
@@ -217,6 +217,7 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long addr)
 #define PMD_DSECT_PROT_NONE	(_AT(pmdval_t, 1) << 5)
 #define PMD_DSECT_DIRTY		(_AT(pmdval_t, 1) << 6)
 #define PMD_DSECT_AF		(_AT(pmdval_t, 1) << 7)
+#define PMD_DSECT_SPLITTING	(_AT(pmdval_t, 1) << 8)
 
 #define PMD_BIT_FUNC(fn,op) \
 static inline pmd_t pmd_##fn(pmd_t pmd) { pmd_val(pmd) op; return pmd; }
@@ -304,6 +305,52 @@ static inline void set_pmd_at(struct mm_struct *mm, unsigned long addr,
 	pmdret;									\
 })
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+#define pmd_trans_splitting(pmd)	(pmd_val(pmd) & PMD_DSECT_SPLITTING)
+#define pmd_trans_huge(pmd)		(pmd_large(pmd))
+#else
+static inline int pmd_trans_huge(pmd_t pmd);
+#endif
+
+PMD_BIT_FUNC(mksplitting, |= PMD_DSECT_SPLITTING);
+#define pmd_mkhuge(pmd)		(__pmd((pmd_val(pmd) & ~PMD_TYPE_MASK) | PMD_TYPE_SECT))
+
+static inline unsigned long pmd_pfn(pmd_t pmd)
+{
+	/*
+	 * for a section, we need to mask off more of the pmd
+	 * before looking up the pfn.
+	 *
+	 * pmd_pfn only gets sections from the thp code.
+	 */
+	if (pmd_trans_huge(pmd))
+		return __phys_to_pfn(pmd_val(pmd) & HPAGE_MASK);
+	else
+		return __phys_to_pfn(pmd_val(pmd) & PHYS_MASK);
+}
+
+#define pfn_pmd(pfn,prot) pmd_modify(__pmd(__pfn_to_phys(pfn)),prot);
+#define mk_pmd(page,prot) pfn_pmd(page_to_pfn(page),prot);
+
+static inline int has_transparent_hugepage(void)
+{
+	return 1;
+}
+
+static inline struct page *pmd_page(pmd_t pmd)
+{
+	/*
+	 * for a section, we need to mask off more of the pmd
+	 * before looking up the page as it is a section descriptor.
+	 *
+	 * pmd_page only gets sections from the thp code.
+	 */
+	if (pmd_trans_huge(pmd))
+		return (phys_to_page(pmd_val(pmd) & HPAGE_MASK));
+
+	return phys_to_page(pmd_val(pmd) & PHYS_MASK);
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_PGTABLE_2LEVEL_H */
diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
index 67a0e06..9c38f29 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -234,6 +234,7 @@ PMD_BIT_FUNC(mkyoung,   |= PMD_SECT_AF);
 
 /* represent a notpresent pmd by zero, this is used by pmdp_invalidate */
 #define pmd_mknotpresent(pmd)	(__pmd(0))
+#define pmd_page(pmd)           pfn_to_page(__phys_to_pfn(pmd_val(pmd) & PHYS_MASK))
 
 static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
 {
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index cf77a59..66a1417 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -189,8 +189,6 @@ static inline pte_t *pmd_page_vaddr(pmd_t pmd)
 	return __va(pmd_val(pmd) & PHYS_MASK & (s32)PAGE_MASK);
 }
 
-#define pmd_page(pmd)		pfn_to_page(__phys_to_pfn(pmd_val(pmd) & PHYS_MASK))
-
 #ifndef CONFIG_HIGHPTE
 #define __pte_map(pmd)		pmd_page_vaddr(*(pmd))
 #define __pte_unmap(pte)	do { } while (0)
-- 
1.8.1.4



From jason at lakedaemon.net  Thu Jul 25 12:33:20 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 12:33:20 -0400
Subject: [PATCH, RESEND] arm: kirkwood: readynas duo v2: Add GMT G762
 Fan Controller
In-Reply-To: <874nceui0h.fsf@natisbad.org>
References: <874nceui0h.fsf@natisbad.org>
Message-ID: <20130725163320.GL23879@titan.lakedaemon.net>

On Mon, Jul 01, 2013 at 10:45:02PM +0200, Arnaud Ebalard wrote:
> 
> Now that GMT G762 PWM Fan Controller is available upstream, let's add
> missing bindings in Netgear ReadyNAS Duo v2 .dts file.
> 
> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
> ---
> Hi Jason and Andrew,
> 
> This one applies and has been tested against Stephen Rothwell tree.
> Can you make it flow to Linus tree during the merge window?
> 
> Following Thomas feedback, this is a resend of previous version, this
> time w/o fixes for bad spaces at the end of the file. Just tell me if
> I should send a separate one for that purpose.
> 
> Thanks in advance.
> 
> Cheers,
> 
> a+
> 
>  .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts    | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)

Applied to mvebu/dt

thx,

Jason.


From sboyd at codeaurora.org  Thu Jul 25 12:36:02 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Jul 2013 09:36:02 -0700
Subject: [PATCH v1 03/14] clk: Add of_clk_match() for device drivers
In-Reply-To: <52875092.tEWeSbEJZC@flatron>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
 <1374713022-6049-4-git-send-email-sboyd@codeaurora.org>
 <52875092.tEWeSbEJZC@flatron>
Message-ID: <20130725163602.GB29694@codeaurora.org>

On 07/25, Tomasz Figa wrote:
> Hi Stephen,
> 
> On Wednesday 24 of July 2013 17:43:31 Stephen Boyd wrote:
> > In similar fashion as of_regulator_match() add an of_clk_match()
> > function that finds an initializes clock init_data structs from
> > devicetree. Drivers should use this API to find clocks that their
> > device is providing and then iterate over their match table
> > registering the clocks with the init data parsed.
> 
> I think all you need here is declaring all your clock drivers using 
> CLK_OF_DECLARE() macro. Then they will be automatically probed by 
> of_clk_init(). See last lines of drivers/clk/clk-fixed-rate.c for an 
> example.
> 

CLK_OF_DECLARE() will not work because it doesn't give the
caller a struct device. I want that struct device to use managed
allocations and clk registrations.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From arend at broadcom.com  Thu Jul 25 12:36:02 2013
From: arend at broadcom.com (Arend van Spriel)
Date: Thu, 25 Jul 2013 18:36:02 +0200
Subject: [PATCH 05/22] ARM: dts: bcm281xx: Remove '0x's from
 BCM11351 BRT DTS file
In-Reply-To: <CAAYSxhrf+WNz1+ojA1r_pOLWg4xf9Ko8OyUc4GfVEMUN776pfA@mail.gmail.com>
References: <1374490361-25769-1-git-send-email-lee.jones@linaro.org>
 <1374490361-25769-5-git-send-email-lee.jones@linaro.org>
 <51ED2D90.4020209@broadcom.com> <20130722133852.GA26801@laptop>
 <51ED3971.905@broadcom.com> <51ED6486.3080700@broadcom.com>
 <CAAYSxhrf+WNz1+ojA1r_pOLWg4xf9Ko8OyUc4GfVEMUN776pfA@mail.gmail.com>
Message-ID: <51F153F2.4080107@broadcom.com>

On 07/25/2013 05:43 PM, Tim Kryger wrote:
> On Mon, Jul 22, 2013 at 9:57 AM, Christian Daudt <csd at broadcom.com> wrote:
>
>> it'd be nice to have something to point
>> people to as this being the best practice for kernel dev.
>
> Power.org's ePAPR exclusively omits the 0x in the unit-address of node names.
>
> https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf
>

Thanks for the link. While browsing on power.org I got the impression 
that I needed to have a membership to get it.

Regards,
Arend



From sboyd at codeaurora.org  Thu Jul 25 12:36:56 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Jul 2013 09:36:56 -0700
Subject: [PATCH v1 02/14] clk: Add of_init_clk_data() to parse common
 clock bindings
In-Reply-To: <1714620.Z8J8zTxIRB@flatron>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
 <1374713022-6049-3-git-send-email-sboyd@codeaurora.org>
 <1714620.Z8J8zTxIRB@flatron>
Message-ID: <20130725163656.GC29694@codeaurora.org>

On 07/25, Tomasz Figa wrote:
> On Wednesday 24 of July 2013 17:43:30 Stephen Boyd wrote:
> > Consolidate DT parsing for the common bits of a clock binding in
> > one place to simplify clock drivers. This also has the added
> > benefit of standardizing how the clock names used by the common
> > clock framework are generated from the DT bindings. We always use
> > the first clock-output-names string if it exists, otherwise we
> > fall back to the node name.
> > 
> > To be slightly more efficient and make the caller's life easier,
> > we introduce a shallow copy flag so that the clock core knows to
> > just copy the pointers to the strings and not the string
> > contents. Otherwise the callers of this function would have to
> > free the strings allocated here which could be cumbersome.
> > 
> > Cc: Rob Herring <rob.herring at calxeda.com>
> > Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> > ---
> >  drivers/clk/clk.c            | 59
> > +++++++++++++++++++++++++++++++++++++++++++-
> > include/linux/clk-provider.h |  7 ++++++
> >  2 files changed, 65 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 1ed9bdd..ea8e951b 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -1809,6 +1809,10 @@ static int _clk_register(struct device *dev,
> > struct clk_hw *hw, struct clk *clk) {
> >  	int i, ret;
> > 
> > +	hw->clk = clk;
> > +	if (hw->init->flags & CLK_SHALLOW_COPY)
> > +		return PTR_RET(__clk_register(dev, hw));
> > +
> >  	clk->name = kstrdup(hw->init->name, GFP_KERNEL);
> >  	if (!clk->name) {
> >  		pr_err("%s: could not allocate clk->name\n", __func__);
> > @@ -1819,7 +1823,6 @@ static int _clk_register(struct device *dev,
> > struct clk_hw *hw, struct clk *clk) clk->hw = hw;
> >  	clk->flags = hw->init->flags;
> >  	clk->num_parents = hw->init->num_parents;
> > -	hw->clk = clk;
> > 
> >  	/* allocate local copy in case parent_names is __initdata */
> >  	clk->parent_names = kzalloc((sizeof(char*) * clk->num_parents),
> > @@ -2232,4 +2235,58 @@ void __init of_clk_init(const struct of_device_id
> > *matches) clk_init_cb(np);
> >  	}
> >  }
> > +
> > +/**
> > + * of_init_clk_data() - Initialize a clk_init_data struct from a DT
> > node + * @np: node to initialize struct from
> > + * @init: struct to initialize
> > + *
> > + * Populates the clk_init_data struct by parsing the device node for
> > + * properties matching the common clock binding. Returns 0 on success
> > + * and a negative error code on failure.
> > + */
> > +int of_init_clk_data(struct device_node *np, struct clk_init_data
> > *init) +{
> > +	struct of_phandle_args s;
> > +	const char **names = NULL, **p;
> > +	const char *name;
> > +	int i;
> > +
> > +	if (of_property_read_string(np, "clock-output-names", &name) < 0)
> > +		name = np->name;
> > +	init->name = kstrdup(name, GFP_KERNEL);
> > +	if (!init->name)
> > +		return -ENOMEM;
> > +
> > +	for (i = 0; of_parse_phandle_with_args(np, "clocks", "#clock-
> cells",
> > +				i, &s) == 0; i++) {
> > +		p = krealloc(names, sizeof(*names) * (i + 1), GFP_KERNEL);
> > +		if (!p)
> > +			goto err;
> 
> What about using of_count_phandle_with_args() first to get the parent 
> count?

Sure that simplifies things.

> 
> > +		names = p;
> > +
> > +		if (of_property_read_string(s.np, "clock-output-names",
> > +					&name) < 0)
> > +			name = s.np->name;
> 
> You should be able to use of_clk_get_parent_name() here, instead of 
> parsing the properties directly.

This must be new too. Will do in v2.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From sboyd at codeaurora.org  Thu Jul 25 12:37:19 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Jul 2013 09:37:19 -0700
Subject: [PATCH v1 05/14] clk: msm: Add support for phase locked loops
 (PLLs)
In-Reply-To: <6003715.TMZ71jDUbL@flatron>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
 <1374713022-6049-6-git-send-email-sboyd@codeaurora.org>
 <6003715.TMZ71jDUbL@flatron>
Message-ID: <20130725163719.GD29694@codeaurora.org>

On 07/25, Tomasz Figa wrote:
> On Wednesday 24 of July 2013 17:43:33 Stephen Boyd wrote:
> > +extern struct clk *pll_clk_register(struct device *dev, struct pll_desc
> > *desc, +		struct clk_init_data *init);
> > +extern struct clk *pll_vote_clk_register(struct device *dev,
> > +		struct pll_vote_desc *desc, struct clk_init_data *init);
> 
> I don't think such generic name is good here. What about prefixing them 
> with msm_ or qcom_ string?
> 

Sure.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From sboyd at codeaurora.org  Thu Jul 25 12:40:05 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Jul 2013 09:40:05 -0700
Subject: [PATCH v1 08/14] clk: msm: Add MSM clock driver
In-Reply-To: <2513717.VTXGvIpGv4@flatron>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
 <1374713022-6049-9-git-send-email-sboyd@codeaurora.org>
 <2513717.VTXGvIpGv4@flatron>
Message-ID: <20130725164005.GE29694@codeaurora.org>

On 07/25, Tomasz Figa wrote:
> On Wednesday 24 of July 2013 17:43:36 Stephen Boyd wrote:
> > Add a clock driver that registers clocks from a DT node's
> > 'clocks' child. Each new SoC will add a file describing the
> > software interface and frequency plan to drivers/clk/msm/ and
> > then hook that into the msm_cc_match_table by means of a
> > compatible string and an msm_clk_match table.
> > 
> > Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> > ---
> >  drivers/clk/msm/Makefile   |   2 +
> >  drivers/clk/msm/core.c     | 265
> > +++++++++++++++++++++++++++++++++++++++++++++
> > drivers/clk/msm/internal.h |  24 ++++
> >  3 files changed, 291 insertions(+)
> >  create mode 100644 drivers/clk/msm/core.c
> >  create mode 100644 drivers/clk/msm/internal.h
> > 
> > diff --git a/drivers/clk/msm/Makefile b/drivers/clk/msm/Makefile
> > index e1cee29..9cfd0d7 100644
> > --- a/drivers/clk/msm/Makefile
> > +++ b/drivers/clk/msm/Makefile
> > @@ -4,3 +4,5 @@ clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-pll.o
> >  clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-rcg.o
> >  clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-rcg2.o
> >  clk-msm-$(CONFIG_COMMON_CLK_MSM) += clk-branch.o
> > +
> > +clk-msm-$(CONFIG_COMMON_CLK_MSM) += core.o
> > diff --git a/drivers/clk/msm/core.c b/drivers/clk/msm/core.c
> > new file mode 100644
> > index 0000000..b1904c0
> > --- /dev/null
> > +++ b/drivers/clk/msm/core.c
> > @@ -0,0 +1,265 @@
> > +/*
> > + * Copyright (c) 2013, The Linux Foundation. All rights reserved.
> > + *
> > + * 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.
> > + */
> > +
> > +#include <linux/err.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/module.h>
> > +#include <linux/clk-provider.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +#include <linux/spinlock.h>
> > +
> > +#include "internal.h"
> > +#include "clk-pll.h"
> > +#include "clk-rcg.h"
> > +#include "clk-branch.h"
> > +
> > +struct cc_data {
> > +	void __iomem *base;
> > +	spinlock_t lock;
> > +};
> > +
> > +static struct clk *
> > +dispatch_fixed_clk(struct of_clk_match *m, struct device *dev,
> > +		struct cc_data *cc)
> > +{
> > +	u32 rate;
> > +	const char *name = m->init_data->name;
> > +
> > +	if (of_property_read_u32(m->of_node, "clock-frequency", &rate))
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	return clk_register_fixed_rate(dev, name, NULL, CLK_IS_ROOT, 
> rate);
> > +}
> > +
> > +static struct clk *
> > +dispatch_pll_clk(struct of_clk_match *m, struct device *dev,
> > +		struct cc_data *cc)
> > +{
> > +	struct pll_desc *desc = m->driver_data;
> > +
> > +	desc->base = cc->base;
> > +
> > +	return pll_clk_register(dev, desc, m->init_data);
> > +}
> > +
> > +static struct clk *
> > +dispatch_pll_vote_clk(struct of_clk_match *m, struct device *dev,
> > +		struct cc_data *cc)
> > +{
> > +	struct pll_vote_desc *desc = m->driver_data;
> > +
> > +	desc->base = cc->base;
> > +
> > +	return pll_vote_clk_register(dev, desc, m->init_data);
> > +}
> > +
> > +static struct clk *
> > +dispatch_rcg_p2mn16_clk(struct of_clk_match *m, struct device *dev,
> > +		struct cc_data *cc)
> > +{
> > +	struct rcg_desc *desc = m->driver_data;
> > +
> > +	desc->base = cc->base;
> > +
> > +	return rcg_p2mn16_clk_register(dev, desc, &cc->lock, m-
> >init_data);
> > +}
> > +
> > +static struct clk *
> > +dispatch_rcg_p2mn8_clk(struct of_clk_match *m, struct device *dev,
> > +		struct cc_data *cc)
> > +{
> > +	struct rcg_desc *desc = m->driver_data;
> > +
> > +	desc->base = cc->base;
> > +
> > +	return rcg_p2mn8_clk_register(dev, desc, &cc->lock, m->init_data);
> > +}
> > +
> > +static struct clk *
> > +dispatch_rcg_mn8_dyn_clk(struct of_clk_match *match, struct device
> > *dev, +		struct cc_data *cc)
> > +{
> > +	struct rcg_dyn_desc *desc = match->driver_data;
> > +
> > +	desc->base = cc->base;
> > +
> > +	return rcg_mn8_dyn_clk_register(dev, desc, &cc->lock,
> > +			match->init_data);
> > +}
> > +
> > +static struct clk *
> > +dispatch_rcg_p4_dyn_clk(struct of_clk_match *match, struct device *dev,
> > +		struct cc_data *cc)
> > +{
> > +	struct rcg_dyn_desc *desc = match->driver_data;
> > +
> > +	desc->base = cc->base;
> > +
> > +	return rcg_p4_dyn_clk_register(dev, desc, &cc->lock,
> > +			match->init_data);
> > +}
> > +
> > +static struct clk *
> > +dispatch_rcg_h5mn8_clk(struct of_clk_match *match, struct device *dev,
> > +		struct cc_data *cc)
> > +{
> > +	struct rcg2_desc *desc = match->driver_data;
> > +
> > +	desc->base = cc->base;
> > +
> > +	return rcg_h5mn8_clk_register(dev, desc, &cc->lock, match-
> >init_data);
> > +}
> > +
> > +static struct clk *
> > +dispatch_rcg_h5mn16_clk(struct of_clk_match *match, struct device *dev,
> > +		struct cc_data *cc)
> > +{
> > +	struct rcg2_desc *desc = match->driver_data;
> > +
> > +	desc->base = cc->base;
> > +
> > +	return rcg_h5mn16_clk_register(dev, desc, &cc->lock,
> > match->init_data); +}
> > +
> > +static struct clk *
> > +dispatch_branch_clk(struct of_clk_match *m, struct device *dev,
> > +		struct cc_data *cc)
> > +{
> > +	struct branch_desc *desc = m->driver_data;
> > +
> > +	desc->base = cc->base;
> > +
> > +	return branch_clk_register(dev, desc, &cc->lock, m->init_data);
> > +}
> > +
> > +static struct clk *
> > +dispatch_branch_hg_clk(struct of_clk_match *m, struct device *dev,
> > +		struct cc_data *cc)
> > +{
> > +	struct branch_desc *desc = m->driver_data;
> > +
> > +	desc->base = cc->base;
> > +
> > +	return branch_hg_clk_register(dev, desc, &cc->lock, m->init_data);
> > +}
> > +
> > +static const struct of_device_id dispatch_table[] = {
> > +	{ .compatible = "fixed-clock", .data = dispatch_fixed_clk },
> 
> This is already handled by the fixed-rate-clock driver and of_clk_init().

I don't plan to use of_clk_init() because I have actual device
drivers.

> 
> > +	{ .compatible = "qcom,pll", .data = dispatch_pll_clk },
> > +	{ .compatible = "qcom,pll-vote", .data = dispatch_pll_vote_clk },
> > +	{ .compatible = "qcom,p2-mn8-clock", .data = 
> dispatch_rcg_p2mn8_clk },
> > +	{ .compatible = "qcom,p2-mn16-clock", .data = 
> dispatch_rcg_p2mn16_clk
> > }, +	{ .compatible = "qcom,mn8-dyn-clock", .data =
> > dispatch_rcg_mn8_dyn_clk }, +	{ .compatible = "qcom,p4-dyn-clock",
> > .data = dispatch_rcg_p4_dyn_clk }, +	{ .compatible =
> > "qcom,h5-mn8-clock", .data = dispatch_rcg_h5mn8_clk }, +	{ 
> .compatible
> > = "qcom,h5-mn16-clock", .data = dispatch_rcg_h5mn16_clk }, +	{
> > .compatible = "qcom,cxc-clock", .data = dispatch_branch_clk }, +	{
> > .compatible = "qcom,cxc-hg-clock", .data = dispatch_branch_hg_clk },
> > +};
> 
> You can avoid all the code above by using OF_CLK_DECLARE() and 
> of_clk_init().

As stated earlier that won't work because I want a struct device.

> > +
> > +static int __init msm_cc_init(void)
> > +{
> > +	return platform_driver_register(&msm_cc_driver);
> > +}
> > +core_initcall(msm_cc_init);
> 
> I might be saying something stupid, but is it okay for a removable module 
> to have a core_initcall?
> 

If its compiled as a module the core_initcall becomes a
module_initcall(). It's here because I need the clocks before the
serial driver probes. If clocks supported deferred probing this
wouldn't be necessary and we could use module_platform_driver().

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From mark.rutland at arm.com  Thu Jul 25 12:45:03 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 25 Jul 2013 17:45:03 +0100
Subject: [PATCH 5/5] iio: at91: introduce touch screen support in iio
 adc driver
In-Reply-To: <51F0DA36.3090608@atmel.com>
References: <1373789069-11604-1-git-send-email-josh.wu@atmel.com>
 <1373789069-11604-6-git-send-email-josh.wu@atmel.com>
 <20130722131747.GA32221@e106331-lin.cambridge.arm.com>
 <51F0DA36.3090608@atmel.com>
Message-ID: <20130725164503.GB22291@e106331-lin.cambridge.arm.com>

On Thu, Jul 25, 2013 at 08:56:38AM +0100, Josh Wu wrote:
> Hi, Dear Mark
> 
> On 7/22/2013 9:17 PM, Mark Rutland wrote:
> > On Sun, Jul 14, 2013 at 09:04:29AM +0100, Josh Wu wrote:
> >> AT91 ADC hardware integrate touch screen support. So this patch add touch
> >> screen support for at91 adc iio driver.
> >> To enable touch screen support in adc, you need to add the dt parameters:
> >>    which type of touch are used? (4 or 5 wires), sample period time,
> >>    pen detect debounce time, average samples and pen detect resistor.
> >>
> >> In the meantime, since touch screen will use a interal period trigger of adc,
> >> so it is conflict to other hardware triggers. Driver will disable the hardware
> >> trigger support if touch screen is enabled.
> >>
> >> This driver has been tested in AT91SAM9X5-EK and SAMA5D3x-EK.
> >>
> >> Signed-off-by: Josh Wu <josh.wu at atmel.com>
> >> Cc: Dmitry Torokhov <dmitry.torokhov at gmail.com>
> >> ---
> >>   .../devicetree/bindings/arm/atmel-adc.txt          |   13 +
> >>   arch/arm/mach-at91/include/mach/at91_adc.h         |   34 ++
> >>   drivers/iio/adc/at91_adc.c                         |  389 ++++++++++++++++++--
> >>   3 files changed, 412 insertions(+), 24 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> >> index 0db2945..925d656 100644
> >> --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
> >> +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
> >> @@ -29,6 +29,19 @@ Optional properties:
> >>     - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
> >>     - atmel,adc-clock-rate: ADC clock rate. If not specified, use the default
> >>                            adc_op_clk.
> >> +  - atmel,adc-touchscreen-wires: Number of touch screen wires. Only support
> >> +                                4 and 5 wires touch screen.
> > Are 4 and 5 wire configurations that can exist, or the only ones
> > supported by the driver?
> 
> It can be set:
> 
> atmel,adc-touchscreen-wires = <4>;
> or
> atmel,adc-touchscreen-wires = <5>;
> 
> according to your touch screen.

That doesn't answer my question.

Is it possible that 3 or 6 wire configurations might exist, for example,
even if not supported by this driver? Or does the design of the adc
prevent this?

Is there any documentation that might make this clearer?

> 
> >
> >> +    NOTE: when adc touch screen enabled, the adc hardware trigger will be
> >> +          disabled. Since touch screen will occupied the trigger register.
> >> +  - atmel,adc-ts-pendet-debounce: Debounce time in microsecond for touch pen
> >> +                                 detect.
> > For consistency with the adc-touchscreen-wires property, and  other
> > properties with timing information, how about
> > atmel,adc-touchscreen-debounce-delay-us ?
> 
> sound nice to me.

Additionally, is this likely to vary from board to board? This feels
like configuration that could be done based on the compatible string...

> 
> >
> >> +  - atmel,adc-ts-sample-period-time: Sample Period Time in microsecond for
> >> +                                    touch screen
> > Again, please be consistent with ts or touchscreen. It may also be good
> > to have -us to make the units explicit (though it does leave the
> > property name being quite a mothful):
> >
> > atmel,adc-touchscreen-sample-period-us ?
> 
> nice. I will use this one.

Looking again at the driver code, it looks like a value derived from
this eventually gets written to the hardware. Is this a fixed value at
integration time, or is this a configuration value? If it's the latter,
can the driver not derive a good value for this itself?

> 
> >
> >> +  - atmel,adc-ts-filter-average: Numbers of sampling data will be averaged.
> >> +    0 means no average. 1 means average two samples. 2 means average four
> >> +    samples. 3 means average eight samples.
> > Is this averaging done in the hardware, or the kernel driver?
> 
> It is done in the hardware.

Similarly, this seems to eventually get written to hardware, and thus
seems more like configuration than hardware description. Why does this
need to be in the DT?

As an aside, in general it's nicer to describe a property as a logical
value rather than the raw value that gets programmed into hardware (e.g.
this property could by 2, 4, or 8 rather than 1, 2, or 4).

> But for some soc, like AT91SAM9G45, hardware doesn't support hardware
> average.
> So I am wondering use it as for both hardware and softer average.
> 
> BTW, you mentioned the kernel driver, do you mean a filter algorithm is
> already implemented in kernel library?

I do not know of any such filter algorithm in the kernel, though there
may be one. I was simply confused as to what this was used for.

> 
> >
> > If it's the latter, this can be left for the kernel to decide.
> >
> >> +  - atmel,adc-ts-pendet-sensitivity: Pen Detection input pull-up resistor.
> >> +    It can be 0, 1, 2, 3.
> > I think "pendet" is a bit opaque. "pen-detect" may be better.
> 
> yes. I'll change this.
> 
> > What
> > physical property does this represent (are these discrete values, or an
> > enumeration)?
> 
> This property is supported by hardware, it can change the adc internal
> resistor value for better pen detection,
>       * 0 = 200 kOhm, 1 = 150 kOhm, 2 = 100 kOhm, 3 = 50 kOhm
> In general, we just use default value 2 for 100kOhm.

This value eventually gets written to hardware, and seems more like
configuration than hardware description. Why does this need to be in the
DT?

Thanks,
Mark.

> I think I need add more detail infomation in the dt document.
> 
> Thanks again,
> Best Regards,
> Josh Wu
> 
> >
> > Thanks,
> > Mark.
> >
> >>   Optional trigger Nodes:
> >>     - Required properties:
> >> diff --git a/arch/arm/mach-at91/include/mach/at91_adc.h b/arch/arm/mach-at91/include/mach/at91_adc.h
> >> index ab273ee..6d6cc14 100644
> >> --- a/arch/arm/mach-at91/include/mach/at91_adc.h
> >> +++ b/arch/arm/mach-at91/include/mach/at91_adc.h
> >> @@ -57,10 +57,44 @@
> >>   #define AT91_ADC_IER           0x24            /* Interrupt Enable Register */
> >>   #define AT91_ADC_IDR           0x28            /* Interrupt Disable Register */
> >>   #define AT91_ADC_IMR           0x2C            /* Interrupt Mask Register */
> >> +#define                AT91_ADC_IER_PEN        (1 << 29)
> >> +#define                AT91_ADC_IER_NOPEN      (1 << 30)
> >> +#define                AT91_ADC_IER_XRDY       (1 << 20)
> >> +#define                AT91_ADC_IER_YRDY       (1 << 21)
> >> +#define                AT91_ADC_IER_PRDY       (1 << 22)
> >> +#define                AT91_ADC_ISR_PENS       (1 << 31)
> >>
> >>   #define AT91_ADC_CHR(n)                (0x30 + ((n) * 4))      /* Channel Data Register N */
> >>   #define                AT91_ADC_DATA           (0x3ff)
> >>
> >> +#define AT91_ADC_ACR           0x94    /* Analog Control Register */
> >> +#define                AT91_ADC_ACR_PENDETSENS (0x3 << 0)      /* pull-up resistor */
> >> +
> >> +#define AT91_ADC_TSMR          0xB0
> >> +#define                AT91_ADC_TSMR_TSMODE    (3 << 0)        /* Touch Screen Mode */
> >> +#define                        AT91_ADC_TSMR_TSMODE_NONE               (0 << 0)
> >> +#define                        AT91_ADC_TSMR_TSMODE_4WIRE_NO_PRESS     (1 << 0)
> >> +#define                        AT91_ADC_TSMR_TSMODE_4WIRE_PRESS        (2 << 0)
> >> +#define                        AT91_ADC_TSMR_TSMODE_5WIRE              (3 << 0)
> >> +#define                AT91_ADC_TSMR_TSAV      (3 << 4)        /* Averages samples */
> >> +#define                        AT91_ADC_TSMR_TSAV_(x)          ((x) << 4)
> >> +#define                AT91_ADC_TSMR_SCTIM     (0x0f << 16)    /* Switch closure time */
> >> +#define                AT91_ADC_TSMR_PENDBC    (0x0f << 28)    /* Pen Debounce time */
> >> +#define                        AT91_ADC_TSMR_PENDBC_(x)        ((x) << 28)
> >> +#define                AT91_ADC_TSMR_NOTSDMA   (1 << 22)       /* No Touchscreen DMA */
> >> +#define                AT91_ADC_TSMR_PENDET_DIS        (0 << 24)       /* Pen contact detection disable */
> >> +#define                AT91_ADC_TSMR_PENDET_ENA        (1 << 24)       /* Pen contact detection enable */
> >> +
> >> +#define AT91_ADC_TSXPOSR       0xB4
> >> +#define AT91_ADC_TSYPOSR       0xB8
> >> +#define AT91_ADC_TSPRESSR      0xBC
> >> +
> >>   #define AT91_ADC_VERSION       0xFC
> >>
> >> +/* Trigger Register bit field */
> >> +#define                AT91_ADC_TRGR_TRGPER    (0xffff << 16)
> >> +#define                        AT91_ADC_TRGR_TRGPER_(x)        ((x) << 16)
> >> +#define                AT91_ADC_TRGR_TRGMOD    (0x7 << 0)
> >> +#define                        AT91_ADC_TRGR_MOD_PERIOD_TRIG   (5 << 0)
> >> +
> >>   #endif
> >> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> >> index 8f1386f..ffc0e42 100644
> >> --- a/drivers/iio/adc/at91_adc.c
> >> +++ b/drivers/iio/adc/at91_adc.c
> >> @@ -11,6 +11,7 @@
> >>   #include <linux/clk.h>
> >>   #include <linux/err.h>
> >>   #include <linux/io.h>
> >> +#include <linux/input.h>
> >>   #include <linux/interrupt.h>
> >>   #include <linux/jiffies.h>
> >>   #include <linux/kernel.h>
> >> @@ -39,12 +40,24 @@
> >>   #define at91_adc_writel(st, reg, val) \
> >>          (writel_relaxed(val, st->reg_base + reg))
> >>
> >> +#define DRIVER_NAME            "at91_adc"
> >> +#define MAX_POS_BITS           12
> >> +
> >> +#define ZTHRESHOLD             9000
> >> +
> >>   struct at91_adc_caps {
> >> +       bool    has_12bits_xy;  /* true means use 12 bits. Otherwise 10 bits */
> >>          bool    has_tsmr;       /* only at91sam9x5, sama5d3 have TSMR reg */
> >>          u32     mr_prescal_mask;
> >>          u32     mr_startup_mask;
> >>   };
> >>
> >> +enum atmel_adc_ts_type {
> >> +       ATMEL_ADC_TOUCHSCREEN_NONE = 0,
> >> +       ATMEL_ADC_TOUCHSCREEN_4WIRE,
> >> +       ATMEL_ADC_TOUCHSCREEN_5WIRE,
> >> +};
> >> +
> >>   struct at91_adc_state {
> >>          struct clk              *adc_clk;
> >>          u32                     adc_clk_rate;
> >> @@ -70,6 +83,29 @@ struct at91_adc_state {
> >>          bool                    low_res;        /* the resolution corresponds to the lowest one */
> >>          wait_queue_head_t       wq_data_avail;
> >>          struct at91_adc_caps    caps;
> >> +
> >> +       /*
> >> +        * Following ADC channels are shared by touchscreen:
> >> +        *
> >> +        * CH0 -- Touch screen XP/UL
> >> +        * CH1 -- Touch screen XM/UR
> >> +        * CH2 -- Touch screen YP/LL
> >> +        * CH3 -- Touch screen YM/Sense
> >> +        * CH4 -- Touch screen LR(5-wire only)
> >> +        *
> >> +        * The bitfields below represents the reserved channel in the
> >> +        * touchscreen mode.
> >> +        */
> >> +#define CHAN_MASK_TOUCHSCREEN_4WIRE    (0xf << 0)
> >> +#define CHAN_MASK_TOUCHSCREEN_5WIRE    (0x1f << 0)
> >> +       enum atmel_adc_ts_type  touchscreen_type;
> >> +       struct input_dev                *ts_input;
> >> +
> >> +       u8                      ts_filter_average;
> >> +       u16                     ts_pen_detect_debounce;
> >> +       u8                      ts_pen_detect_sensitivity;
> >> +       u16                     ts_sample_period_time;
> >> +       u16                     ts_sample_period_val;
> >>   };
> >>
> >>   static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
> >> @@ -104,14 +140,10 @@ static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
> >>          return IRQ_HANDLED;
> >>   }
> >>
> >> -static irqreturn_t at91_adc_eoc_trigger(int irq, void *private)
> >> +/* Handler for classic adc channel eoc trigger */
> >> +void handle_adc_eoc_trigger(int irq, struct iio_dev *idev)
> >>   {
> >> -       struct iio_dev *idev = private;
> >>          struct at91_adc_state *st = iio_priv(idev);
> >> -       u32 status = at91_adc_readl(st, st->registers->status_register);
> >> -
> >> -       if (!(status & st->registers->drdy_mask))
> >> -               return IRQ_HANDLED;
> >>
> >>          if (iio_buffer_enabled(idev)) {
> >>                  disable_irq_nosync(irq);
> >> @@ -121,6 +153,115 @@ static irqreturn_t at91_adc_eoc_trigger(int irq, void *private)
> >>                  st->done = true;
> >>                  wake_up_interruptible(&st->wq_data_avail);
> >>          }
> >> +}
> >> +
> >> +static int at91_ts_sample(struct at91_adc_state *st)
> >> +{
> >> +       unsigned int xscale, yscale, reg, z1, z2;
> >> +       unsigned int x, y, pres, xpos, ypos;
> >> +       unsigned int rxp = 1;
> >> +       unsigned int factor = 1000;
> >> +       struct iio_dev *idev = iio_priv_to_dev(st);
> >> +
> >> +       unsigned int xyz_mask_bits = st->caps.has_12bits_xy ? 12 : 10;
> >> +       unsigned int xyz_mask = (1 << xyz_mask_bits) - 1;
> >> +
> >> +       /* calculate position */
> >> +       /* x position = (x / xscale) * max, max = 2^MAX_POS_BITS - 1 */
> >> +       reg = at91_adc_readl(st, AT91_ADC_TSXPOSR);
> >> +       xpos = reg & xyz_mask;
> >> +       x = (xpos << MAX_POS_BITS) - xpos;
> >> +       xscale = (reg >> 16) & xyz_mask;
> >> +       if (xscale != 0)
> >> +               x /= xscale;
> >> +       else
> >> +               dev_err(&idev->dev, "xscale == 0!!!\n");
> >> +
> >> +       /* y position = (y / yscale) * max, max = 2^MAX_POS_BITS - 1 */
> >> +       reg = at91_adc_readl(st, AT91_ADC_TSYPOSR);
> >> +       ypos = reg & xyz_mask;
> >> +       y = (ypos << MAX_POS_BITS) - ypos;
> >> +       yscale = (reg >> 16) & xyz_mask;
> >> +       if (yscale != 0)
> >> +               y /= yscale;
> >> +       else
> >> +               dev_err(&idev->dev, "yscale == 0!!!\n");
> >> +
> >> +       /* calculate the pressure */
> >> +       reg = at91_adc_readl(st, AT91_ADC_TSPRESSR);
> >> +       z1 = reg & xyz_mask;
> >> +       z2 = (reg >> 16) & xyz_mask;
> >> +
> >> +       if (z1 != 0)
> >> +               pres = rxp * (x * factor / 1024) * (z2 * factor / z1 - factor)
> >> +                       / factor;
> >> +       else
> >> +               pres = ZTHRESHOLD;      /* no pen contacted */
> >> +
> >> +       dev_dbg(&idev->dev, "xpos = %d, xscale = %d, ypos = %d, yscale = %d, z1 = %d, z2 = %d, press = %d\n",
> >> +                               xpos, xscale, ypos, yscale, z1, z2, pres);
> >> +
> >> +       if (pres < ZTHRESHOLD) {
> >> +               dev_dbg(&idev->dev, "x = %d, y = %d, pressure = %d\n",
> >> +                                       x, y, pres / factor);
> >> +               input_report_abs(st->ts_input, ABS_X, x);
> >> +               input_report_abs(st->ts_input, ABS_Y, y);
> >> +               input_report_abs(st->ts_input, ABS_PRESSURE, pres);
> >> +               input_report_key(st->ts_input, BTN_TOUCH, 1);
> >> +               input_sync(st->ts_input);
> >> +       } else {
> >> +               dev_dbg(&idev->dev,
> >> +                               "pressure too low: not reporting\n");
> >> +       }
> >> +
> >> +       return 0;
> >> +}
> >> +
> >> +
> >> +static irqreturn_t at91_adc_interrupt(int irq, void *private)
> >> +{
> >> +       struct iio_dev *idev = private;
> >> +       struct at91_adc_state *st = iio_priv(idev);
> >> +       u32 status = at91_adc_readl(st, st->registers->status_register);
> >> +       const uint32_t ts_data_irq_mask =
> >> +               AT91_ADC_IER_XRDY |
> >> +               AT91_ADC_IER_YRDY |
> >> +               AT91_ADC_IER_PRDY;
> >> +
> >> +       if (status & st->registers->drdy_mask)
> >> +               handle_adc_eoc_trigger(irq, idev);
> >> +
> >> +       if (status & AT91_ADC_IER_PEN) {
> >> +               at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_PEN);
> >> +               at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_NOPEN |
> >> +                       ts_data_irq_mask);
> >> +               /* Set up period trigger for sampling */
> >> +               at91_adc_writel(st, st->registers->trigger_register,
> >> +                       AT91_ADC_TRGR_MOD_PERIOD_TRIG |
> >> +                       AT91_ADC_TRGR_TRGPER_(st->ts_sample_period_val));
> >> +       } else if (status & AT91_ADC_IER_NOPEN) {
> >> +               at91_adc_writel(st, st->registers->trigger_register, 0);
> >> +               at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_NOPEN |
> >> +                       ts_data_irq_mask);
> >> +               at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_PEN);
> >> +
> >> +               input_report_key(st->ts_input, BTN_TOUCH, 0);
> >> +               input_sync(st->ts_input);
> >> +       } else if ((status & ts_data_irq_mask) == ts_data_irq_mask) {
> >> +               /* Now all touchscreen data is ready */
> >> +
> >> +               if (status & AT91_ADC_ISR_PENS) {
> >> +                       /* validate data by pen contact */
> >> +                       at91_ts_sample(st);
> >> +               } else {
> >> +                       /* triggered by event that is no pen contact, just read
> >> +                        * them to clean the interrupt and discard all.
> >> +                        */
> >> +                       at91_adc_readl(st, AT91_ADC_TSXPOSR);
> >> +                       at91_adc_readl(st, AT91_ADC_TSYPOSR);
> >> +                       at91_adc_readl(st, AT91_ADC_TSPRESSR);
> >> +               }
> >> +       }
> >>
> >>          return IRQ_HANDLED;
> >>   }
> >> @@ -130,6 +271,16 @@ static int at91_adc_channel_init(struct iio_dev *idev)
> >>          struct at91_adc_state *st = iio_priv(idev);
> >>          struct iio_chan_spec *chan_array, *timestamp;
> >>          int bit, idx = 0;
> >> +       unsigned long rsvd_mask = 0;
> >> +
> >> +       /* If touchscreen is enable, then reserve the adc channels */
> >> +       if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_4WIRE)
> >> +               rsvd_mask = CHAN_MASK_TOUCHSCREEN_4WIRE;
> >> +       else if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_5WIRE)
> >> +               rsvd_mask = CHAN_MASK_TOUCHSCREEN_5WIRE;
> >> +
> >> +       /* set up the channel mask to reserve touchscreen channels */
> >> +       st->channels_mask &= ~rsvd_mask;
> >>
> >>          idev->num_channels = bitmap_weight(&st->channels_mask,
> >>                                             st->num_channels) + 1;
> >> @@ -561,6 +712,57 @@ static int at91_adc_probe_dt(struct at91_adc_state *st,
> >>                  i++;
> >>          }
> >>
> >> +       /* Check if touchscreen is enabled in DT. */
> >> +       ret = of_property_read_u32(node, "atmel,adc-touchscreen-wires", &prop);
> >> +       if (ret)
> >> +               dev_info(&idev->dev, "Touchscreen not enabled.\n");
> >> +       else if (prop == 4)
> >> +               st->touchscreen_type = ATMEL_ADC_TOUCHSCREEN_4WIRE;
> >> +       else if (prop == 5)
> >> +               st->touchscreen_type = ATMEL_ADC_TOUCHSCREEN_5WIRE;
> >> +       else
> >> +               dev_warn(&idev->dev, "Unsupported number of touchscreen wires (%d)\n",
> >> +                               prop);
> >> +
> >> +       if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_NONE)
> >> +               return 0;
> >> +
> >> +       /* Touch screen is enabled, so check touch screen dt parameters */
> >> +       if (of_property_read_u32(node, "atmel,adc-ts-filter-average", &prop)) {
> >> +               dev_err(&idev->dev, "Missing atmel,adc-ts-filtering-average property in the DT.\n");
> >> +               ret = -EINVAL;
> >> +               goto error_ret;
> >> +       }
> >> +       st->ts_filter_average = prop;
> >> +       if (st->ts_filter_average > 3) {
> >> +               dev_err(&idev->dev, "Invalid atmel,adc-ts-filtering-average property in the DT.\n");
> >> +               ret = -EINVAL;
> >> +               goto error_ret;
> >> +       }
> >> +
> >> +       prop = 0;
> >> +       of_property_read_u32(node, "atmel,adc-ts-pendet-debounce", &prop);
> >> +       st->ts_pen_detect_debounce = prop;
> >> +
> >> +       /* default sample period is 2ms. The real touch sample period should be
> >> +        * this period * TSFREQ.
> >> +        */
> >> +       prop = 2000;
> >> +       of_property_read_u32(node, "atmel,adc-ts-sample-period-time", &prop);
> >> +       st->ts_sample_period_time = prop;
> >> +
> >> +       if (of_property_read_u32(node, "atmel,adc-ts-pendet-sensitivity", &prop)) {
> >> +               dev_err(&idev->dev, "Missing atmel,adc-ts-pendet-sensitivity property in the DT.\n");
> >> +               ret = -EINVAL;
> >> +               goto error_ret;
> >> +       }
> >> +       st->ts_pen_detect_sensitivity = prop;
> >> +       if (st->ts_pen_detect_sensitivity > 3) {
> >> +               dev_err(&idev->dev, "Invalid atmel,adc-ts-pendet-sensitivity property in the DT.\n");
> >> +               ret = -EINVAL;
> >> +               goto error_ret;
> >> +       }
> >> +
> >>          return 0;
> >>
> >>   error_ret:
> >> @@ -592,6 +794,114 @@ static const struct iio_info at91_adc_info = {
> >>          .read_raw = &at91_adc_read_raw,
> >>   };
> >>
> >> +/* Touchscreen related functions */
> >> +static int atmel_ts_open(struct input_dev *dev)
> >> +{
> >> +       struct at91_adc_state *st = input_get_drvdata(dev);
> >> +
> >> +       at91_adc_writel(st, AT91_ADC_IER, AT91_ADC_IER_PEN);
> >> +       return 0;
> >> +}
> >> +
> >> +static void atmel_ts_close(struct input_dev *dev)
> >> +{
> >> +       struct at91_adc_state *st = input_get_drvdata(dev);
> >> +
> >> +       at91_adc_writel(st, AT91_ADC_IDR, AT91_ADC_IER_PEN);
> >> +}
> >> +
> >> +static int at91_ts_hw_init(struct at91_adc_state *st, u32 adc_clk_khz)
> >> +{
> >> +       u32 reg = 0, pendbc;
> >> +       int i = 0;
> >> +
> >> +       if (st->touchscreen_type == ATMEL_ADC_TOUCHSCREEN_4WIRE)
> >> +               reg = AT91_ADC_TSMR_TSMODE_4WIRE_PRESS;
> >> +       else
> >> +               reg = AT91_ADC_TSMR_TSMODE_5WIRE;
> >> +
> >> +       /* a Pen Detect Debounce Time is necessary for the ADC Touch to avoid
> >> +        * pen detect noise.
> >> +        * The formula is : Pen Detect Debounce Time = (2 ^ pendbc) / ADCClock
> >> +        */
> >> +       pendbc = round_up(st->ts_pen_detect_debounce * adc_clk_khz / 1000, 1);
> >> +
> >> +       while (pendbc >> ++i)
> >> +               ;       /* Empty! Find the shift offset */
> >> +       if (abs(pendbc - (1 << i)) < abs(pendbc - (1 << (i - 1))))
> >> +               pendbc = i;
> >> +       else
> >> +               pendbc = i - 1;
> >> +
> >> +       if (st->caps.has_tsmr) {
> >> +               reg |= AT91_ADC_TSMR_TSAV_(st->ts_filter_average)
> >> +                               & AT91_ADC_TSMR_TSAV;
> >> +               reg |= AT91_ADC_TSMR_PENDBC_(pendbc) & AT91_ADC_TSMR_PENDBC;
> >> +               reg |= AT91_ADC_TSMR_NOTSDMA;
> >> +               reg |= AT91_ADC_TSMR_PENDET_ENA;
> >> +               reg |= 0x03 << 8;       /* TSFREQ, need bigger than TSAV */
> >> +
> >> +               at91_adc_writel(st, AT91_ADC_TSMR, reg);
> >> +       } else {
> >> +               /* TODO: for 9g45 which has no TSMR */
> >> +       }
> >> +
> >> +       /* Change adc internal resistor value for better pen detection,
> >> +        * default value is 100 kOhm.
> >> +        * 0 = 200 kOhm, 1 = 150 kOhm, 2 = 100 kOhm, 3 = 50 kOhm
> >> +        * option only available on ES2 and higher
> >> +        */
> >> +       at91_adc_writel(st, AT91_ADC_ACR, st->ts_pen_detect_sensitivity
> >> +                       & AT91_ADC_ACR_PENDETSENS);
> >> +
> >> +       /* Sample Peroid Time = (TRGPER + 1) / ADCClock */
> >> +       st->ts_sample_period_val = round_up((st->ts_sample_period_time *
> >> +                       adc_clk_khz / 1000) - 1, 1);
> >> +
> >> +       return 0;
> >> +}
> >> +
> >> +static int at91_ts_register(struct at91_adc_state *st)
> >> +{
> >> +       struct input_dev *input;
> >> +       struct iio_dev *idev = iio_priv_to_dev(st);
> >> +       int ret;
> >> +
> >> +       input = input_allocate_device();
> >> +       if (!input) {
> >> +               dev_err(&idev->dev, "Failed to allocate TS device!\n");
> >> +               return -ENOMEM;
> >> +       }
> >> +
> >> +       input->name = DRIVER_NAME;
> >> +       input->id.bustype = BUS_HOST;
> >> +       input->dev.parent = idev->dev.parent;
> >> +       input->open = atmel_ts_open;
> >> +       input->close = atmel_ts_close;
> >> +
> >> +       __set_bit(EV_ABS, input->evbit);
> >> +       __set_bit(EV_KEY, input->evbit);
> >> +       __set_bit(BTN_TOUCH, input->keybit);
> >> +       input_set_abs_params(input, ABS_X, 0, (1 << MAX_POS_BITS) - 1, 0, 0);
> >> +       input_set_abs_params(input, ABS_Y, 0, (1 << MAX_POS_BITS) - 1, 0, 0);
> >> +       input_set_abs_params(input, ABS_PRESSURE, 0, 0xffffff, 0, 0);
> >> +
> >> +       st->ts_input = input;
> >> +       input_set_drvdata(input, st);
> >> +
> >> +       ret = input_register_device(input);
> >> +       if (ret)
> >> +               input_free_device(st->ts_input);
> >> +
> >> +       return ret;
> >> +}
> >> +
> >> +static void at91_ts_unregister(struct at91_adc_state *st)
> >> +{
> >> +       input_unregister_device(st->ts_input);
> >> +       input_free_device(st->ts_input);
> >> +}
> >> +
> >>   /*
> >>    * Since atmel adc support different ip for touchscreen mode. Through the
> >>    * IP check, we will know the touchscreen capbilities.
> >> @@ -610,6 +920,7 @@ static void atmel_adc_get_cap(struct at91_adc_state *st)
> >>          /* keep only major version number */
> >>          switch (version & 0xf00) {
> >>          case 0x500:     /* SAMA5D3 */
> >> +               st->caps.has_12bits_xy = 1;
> >>          case 0x400:     /* AT91SAM9X5/9N12 */
> >>                  st->caps.has_tsmr = 1;
> >>                  st->caps.mr_startup_mask = AT91_ADC_STARTUP;
> >> @@ -683,7 +994,7 @@ static int at91_adc_probe(struct platform_device *pdev)
> >>          at91_adc_writel(st, AT91_ADC_CR, AT91_ADC_SWRST);
> >>          at91_adc_writel(st, AT91_ADC_IDR, 0xFFFFFFFF);
> >>          ret = request_irq(st->irq,
> >> -                         at91_adc_eoc_trigger,
> >> +                         at91_adc_interrupt,
> >>                            0,
> >>                            pdev->dev.driver->name,
> >>                            idev);
> >> @@ -731,6 +1042,10 @@ static int at91_adc_probe(struct platform_device *pdev)
> >>          adc_clk = st->adc_clk_rate ?
> >>                  st->adc_clk_rate : clk_get_rate(st->adc_clk);
> >>          adc_clk_khz = adc_clk / 1000;
> >> +
> >> +       dev_dbg(&pdev->dev, "Master clock is set as: %d Hz, adc_clk should set as: %d Hz\n",
> >> +               mstrclk, adc_clk);
> >> +
> >>          prsc = (mstrclk / (2 * adc_clk)) - 1;
> >>
> >>          if (!st->startup_time) {
> >> @@ -799,30 +1114,52 @@ static int at91_adc_probe(struct platform_device *pdev)
> >>          init_waitqueue_head(&st->wq_data_avail);
> >>          mutex_init(&st->lock);
> >>
> >> -       ret = at91_adc_buffer_init(idev);
> >> -       if (ret < 0) {
> >> -               dev_err(&pdev->dev, "Couldn't initialize the buffer.\n");
> >> -               goto error_disable_adc_clk;
> >> -       }
> >> +       /*
> >> +        * Since touch screen will set trigger register as period trigger. So
> >> +        * when touch screen is enabled, then we have to disable hardware
> >> +        * trigger for classic adc.
> >> +        */
> >> +       if (!st->touchscreen_type) {
> >> +               ret = at91_adc_buffer_init(idev);
> >> +               if (ret < 0) {
> >> +                       dev_err(&pdev->dev, "Couldn't initialize the buffer.\n");
> >> +                       goto error_disable_adc_clk;
> >> +               }
> >>
> >> -       ret = at91_adc_trigger_init(idev);
> >> -       if (ret < 0) {
> >> -               dev_err(&pdev->dev, "Couldn't setup the triggers.\n");
> >> -               goto error_unregister_buffer;
> >> +               ret = at91_adc_trigger_init(idev);
> >> +               if (ret < 0) {
> >> +                       dev_err(&pdev->dev, "Couldn't setup the triggers.\n");
> >> +                       at91_adc_buffer_remove(idev);
> >> +                       goto error_disable_adc_clk;
> >> +               }
> >> +       } else {
> >> +               if (!st->caps.has_tsmr) {
> >> +                       dev_err(&pdev->dev, "We don't support non-TSMR adc\n");
> >> +                       goto error_disable_adc_clk;
> >> +               }
> >> +
> >> +               ret = at91_ts_register(st);
> >> +               if (ret)
> >> +                       goto error_disable_adc_clk;
> >> +
> >> +               at91_ts_hw_init(st, adc_clk_khz);
> >>          }
> >>
> >>          ret = iio_device_register(idev);
> >>          if (ret < 0) {
> >>                  dev_err(&pdev->dev, "Couldn't register the device.\n");
> >> -               goto error_remove_triggers;
> >> +               goto error_iio_device_register;
> >>          }
> >>
> >>          return 0;
> >>
> >> -error_remove_triggers:
> >> -       at91_adc_trigger_remove(idev);
> >> -error_unregister_buffer:
> >> -       at91_adc_buffer_remove(idev);
> >> +error_iio_device_register:
> >> +       if (!st->touchscreen_type) {
> >> +               at91_adc_trigger_remove(idev);
> >> +               at91_adc_buffer_remove(idev);
> >> +       } else {
> >> +               at91_ts_unregister(st);
> >> +       }
> >>   error_disable_adc_clk:
> >>          clk_disable_unprepare(st->adc_clk);
> >>   error_disable_clk:
> >> @@ -841,8 +1178,12 @@ static int at91_adc_remove(struct platform_device *pdev)
> >>          struct at91_adc_state *st = iio_priv(idev);
> >>
> >>          iio_device_unregister(idev);
> >> -       at91_adc_trigger_remove(idev);
> >> -       at91_adc_buffer_remove(idev);
> >> +       if (!st->touchscreen_type) {
> >> +               at91_adc_trigger_remove(idev);
> >> +               at91_adc_buffer_remove(idev);
> >> +       } else {
> >> +               at91_ts_unregister(st);
> >> +       }
> >>          clk_disable_unprepare(st->adc_clk);
> >>          clk_disable_unprepare(st->clk);
> >>          free_irq(st->irq, idev);
> >> @@ -861,7 +1202,7 @@ static struct platform_driver at91_adc_driver = {
> >>          .probe = at91_adc_probe,
> >>          .remove = at91_adc_remove,
> >>          .driver = {
> >> -                  .name = "at91_adc",
> >> +                  .name = DRIVER_NAME,
> >>                     .of_match_table = of_match_ptr(at91_adc_dt_ids),
> >>          },
> >>   };
> >> --
> >> 1.7.10
> >>
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >>
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From sboyd at codeaurora.org  Thu Jul 25 12:45:42 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Jul 2013 09:45:42 -0700
Subject: [PATCH v1 04/14] clk: Add set_rate_and_parent() op
In-Reply-To: <4582949.WCP5JfKYES@flatron>
References: <1374713022-6049-1-git-send-email-sboyd@codeaurora.org>
 <1374713022-6049-5-git-send-email-sboyd@codeaurora.org>
 <4582949.WCP5JfKYES@flatron>
Message-ID: <20130725164542.GF29694@codeaurora.org>

On 07/25, Tomasz Figa wrote:
> On Wednesday 24 of July 2013 17:43:32 Stephen Boyd wrote:
> > Some of Qualcomm's clocks can change their parent and rate at the
> > same time with a single register write. Add support for this
> > hardware to the common clock framework by adding a new
> > set_rate_and_parent() op. When the clock framework determines
> > that both the parent and the rate are going to change during
> > clk_set_rate() it will call the .set_rate_and_parent() op if
> > available and fall back to calling .set_parent() followed by
> > .set_rate() otherwise.
> 
> This is strange. Does you hardware support switching parent and rate 
> separately or you always need to set both and so all the fuss here?

It supports setting the parent or setting the rate, or setting
both at the same time.

> 
> If the latter is the case, then maybe you can simply keep parent index and 
> rate cached inside driver data of your clock driver and use them on any 
> .set_rate() or .set_parent() calls?

This will not work. In fact, doing that would cause us to
overclock hardware for a short time between switching the parent
and the rate.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From thierry.reding at gmail.com  Thu Jul 25 12:53:03 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 09:53:03 -0700
Subject: [PATCHv5 08/11] ARM: pci: add ->add_bus() and ->remove_bus()
 hooks to hw_pci
In-Reply-To: <1373889167-27878-9-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-9-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130725165302.GA27802@dhcp-172-17-186-34.nvidia.com>

On Mon, Jul 15, 2013 at 01:52:44PM +0200, Thomas Petazzoni wrote:
[...]

Hi Thomas,

I just noticed two minor issues, see below.

> diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
[...]
> @@ -36,6 +36,8 @@ struct hw_pci {
>  					  resource_size_t start,
>  					  resource_size_t size,
>  					  resource_size_t align);
> +	void            (*add_bus)(struct pci_bus *bus);
> +	void            (*remove_bus)(struct pci_bus *bus);

This hunk...

> @@ -63,6 +65,8 @@ struct pci_sys_data {
>  					  resource_size_t start,
>  					  resource_size_t size,
>  					  resource_size_t align);
> +	void            (*add_bus)(struct pci_bus *bus);
> +	void            (*remove_bus)(struct pci_bus *bus);
>  	void		*private_data;	/* platform controller private data	*/
>  };

and this one use inconsistent indentation (spaces instead of tabs).

> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
[...]
> @@ -464,6 +478,8 @@ static void pcibios_init_hw(struct device *parent, struct hw_pci *hw,
>  		sys->swizzle = hw->swizzle;
>  		sys->map_irq = hw->map_irq;
>  		sys->align_resource = hw->align_resource;
> +		sys->add_bus        = hw->add_bus;
> +		sys->remove_bus     = hw->remove_bus;

And this one aligns the '=' sign, whereas none of the other assignments
do.

Might be nice to fix those up before sending them to Russell's patch
tracker.

Thierry
-------------- 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/20130725/6f6205d2/attachment.sig>

From thierry.reding at gmail.com  Thu Jul 25 12:57:00 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 09:57:00 -0700
Subject: [PATCHv5 08/11] ARM: pci: add ->add_bus() and ->remove_bus()
 hooks to hw_pci
In-Reply-To: <1373889167-27878-9-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-9-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130725165659.GB27802@dhcp-172-17-186-34.nvidia.com>

On Mon, Jul 15, 2013 at 01:52:44PM +0200, Thomas Petazzoni wrote:
> Some PCI drivers may need to adjust the pci_bus structure after it has
> been allocated by the Linux PCI core. The PCI core allows
> architectures to implement the pcibios_add_bus() and
> pcibios_remove_bus() for this purpose. This commit therefore extends
> the hw_pci and pci_sys_data structures of the ARM PCI core to allow
> PCI drivers to register ->add_bus() and ->remove_bus() in hw_pci,
> which will get called when a bus is added or removed from the system.
> 
> This will be used for example by the Marvell PCIe driver to connect a
> particular PCI bus with its corresponding MSI chip to handle Message
> Signaled Interrupts.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Reviewed-by: Thierry Reding <thierry.reding at gmail.com>
> ---
>  arch/arm/include/asm/mach/pci.h |  4 ++++
>  arch/arm/kernel/bios32.c        | 16 ++++++++++++++++
>  2 files changed, 20 insertions(+)

Hi Russell,

Can we have your Acked-by on this patch so that it can be moved to a
stable branch along with some of the other patches in this branch that
both Marvell and Tegra PCIe drivers need?

Thanks,
Thierry

> 
> diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
> index a1c90d7..487155c 100644
> --- a/arch/arm/include/asm/mach/pci.h
> +++ b/arch/arm/include/asm/mach/pci.h
> @@ -36,6 +36,8 @@ struct hw_pci {
>  					  resource_size_t start,
>  					  resource_size_t size,
>  					  resource_size_t align);
> +	void            (*add_bus)(struct pci_bus *bus);
> +	void            (*remove_bus)(struct pci_bus *bus);
>  };
>  
>  /*
> @@ -63,6 +65,8 @@ struct pci_sys_data {
>  					  resource_size_t start,
>  					  resource_size_t size,
>  					  resource_size_t align);
> +	void            (*add_bus)(struct pci_bus *bus);
> +	void            (*remove_bus)(struct pci_bus *bus);
>  	void		*private_data;	/* platform controller private data	*/
>  };
>  
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index 261fcc8..530e59d 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -363,6 +363,20 @@ void pcibios_fixup_bus(struct pci_bus *bus)
>  }
>  EXPORT_SYMBOL(pcibios_fixup_bus);
>  
> +void pcibios_add_bus(struct pci_bus *bus)
> +{
> +	struct pci_sys_data *sys = bus->sysdata;
> +	if (sys->add_bus)
> +		sys->add_bus(bus);
> +}
> +
> +void pcibios_remove_bus(struct pci_bus *bus)
> +{
> +	struct pci_sys_data *sys = bus->sysdata;
> +	if (sys->remove_bus)
> +		sys->remove_bus(bus);
> +}
> +
>  /*
>   * Swizzle the device pin each time we cross a bridge.  If a platform does
>   * not provide a swizzle function, we perform the standard PCI swizzling.
> @@ -464,6 +478,8 @@ static void pcibios_init_hw(struct device *parent, struct hw_pci *hw,
>  		sys->swizzle = hw->swizzle;
>  		sys->map_irq = hw->map_irq;
>  		sys->align_resource = hw->align_resource;
> +		sys->add_bus        = hw->add_bus;
> +		sys->remove_bus     = hw->remove_bus;
>  		INIT_LIST_HEAD(&sys->resources);
>  
>  		if (hw->private_data)
> -- 
> 1.8.1.2
> 
-------------- 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/20130725/28eff599/attachment.sig>

From will.deacon at arm.com  Thu Jul 25 13:01:47 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 18:01:47 +0100
Subject: [PATCH v3 4/4] ARM: cacheflush: don't bother rounding to nearest vma
In-Reply-To: <1374771707-2619-1-git-send-email-will.deacon@arm.com>
References: <1374771707-2619-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374771707-2619-5-git-send-email-will.deacon@arm.com>

do_cache_op finds the lowest VMA contained in the specified address
range and rounds the range to cover only the mapped addresses.

Since commit 4542b6a0fa6b ("ARM: 7365/1: drop unused parameter from
flush_cache_user_range") the VMA is not used for anything else in this
code and seeing as the low-level cache flushing routines return -EFAULT
if the address is not valid, there is no need for this range truncation.

This patch removes the VMA handling code from the cacheflushing syscall.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/kernel/traps.c | 17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 4fd8ef5..9e60563 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -548,24 +548,11 @@ static long do_cache_op_restart(struct restart_block *unused)
 static inline int
 do_cache_op(unsigned long start, unsigned long end, int flags)
 {
-	struct mm_struct *mm = current->active_mm;
-	struct vm_area_struct *vma;
-
 	if (end < start || flags)
 		return -EINVAL;
 
-	down_read(&mm->mmap_sem);
-	vma = find_vma(mm, start);
-	if (!vma || vma->vm_start >= end) {
-		up_read(&mm->mmap_sem);
-		return -EINVAL;
-	}
-
-	if (start < vma->vm_start)
-		start = vma->vm_start;
-	if (end > vma->vm_end)
-		end = vma->vm_end;
-	up_read(&mm->mmap_sem);
+	if (!access_ok(VERIFY_READ, start, end - start))
+		return -EFAULT;
 
 	return __do_cache_op(start, end);
 }
-- 
1.8.2.2



From will.deacon at arm.com  Thu Jul 25 13:01:43 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 18:01:43 +0100
Subject: [PATCH v3 0/4] Optimise cache-flushing system call
Message-ID: <1374771707-2619-1-git-send-email-will.deacon@arm.com>

Hi guys,

This is a refresh of the patches I originally posted here:

v1: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/157810.html
v2: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/170601.html

This is just a rebase onto 3.11-rc2, there are no functional changes to
the series.

Cheers,

Will


Will Deacon (4):
  ARM: entry: allow ARM-private syscalls to be restarted
  ARM: cacheflush: split user cache-flushing into interruptible chunks
  ARM: cacheflush: don't round address range up to nearest page
  ARM: cacheflush: don't bother rounding to nearest vma

 arch/arm/include/asm/cacheflush.h  |  3 +-
 arch/arm/include/asm/thread_info.h | 11 +++++++
 arch/arm/kernel/entry-common.S     |  4 +--
 arch/arm/kernel/traps.c            | 64 +++++++++++++++++++++++++++++---------
 4 files changed, 63 insertions(+), 19 deletions(-)

-- 
1.8.2.2



From will.deacon at arm.com  Thu Jul 25 13:01:45 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 18:01:45 +0100
Subject: [PATCH v3 2/4] ARM: cacheflush: split user cache-flushing into
 interruptible chunks
In-Reply-To: <1374771707-2619-1-git-send-email-will.deacon@arm.com>
References: <1374771707-2619-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374771707-2619-3-git-send-email-will.deacon@arm.com>

Flushing a large, non-faulting VMA from userspace can potentially result
in a long time spent flushing the cache line-by-line without preemption
occurring (in the case of CONFIG_PREEMPT=n).

Whilst this doesn't affect the stability of the system, it can certainly
affect the responsiveness and CPU availability for other tasks.

This patch splits up the user cacheflush code so that it flushes in
chunks of a page. After each chunk has been flushed, we may reschedule
if appropriate and, before processing the next chunk, we allow any
pending signals to be handled before resuming from where we left off.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/thread_info.h | 11 +++++++
 arch/arm/kernel/traps.c            | 63 +++++++++++++++++++++++++++++++++-----
 2 files changed, 66 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
index 214d415..7d77645 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -43,6 +43,16 @@ struct cpu_context_save {
 	__u32	extra[2];		/* Xscale 'acc' register, etc */
 };
 
+struct arm_restart_block {
+	union {
+		/* For user cache flushing */
+		struct {
+			unsigned long start;
+			unsigned long end;
+		} cache;
+	};
+};
+
 /*
  * low level task data that entry.S needs immediate access to.
  * __switch_to() assumes cpu_context follows immediately after cpu_domain.
@@ -68,6 +78,7 @@ struct thread_info {
 	unsigned long		thumbee_state;	/* ThumbEE Handler Base register */
 #endif
 	struct restart_block	restart_block;
+	struct arm_restart_block	arm_restart_block;
 };
 
 #define INIT_THREAD_INFO(tsk)						\
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index cab094c..4fd8ef5 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -499,6 +499,52 @@ static int bad_syscall(int n, struct pt_regs *regs)
 	return regs->ARM_r0;
 }
 
+static long do_cache_op_restart(struct restart_block *);
+
+static inline int
+__do_cache_op(unsigned long start, unsigned long end)
+{
+	int ret;
+	unsigned long chunk = PAGE_SIZE;
+
+	do {
+		if (signal_pending(current)) {
+			struct thread_info *ti = current_thread_info();
+
+			ti->restart_block = (struct restart_block) {
+				.fn	= do_cache_op_restart,
+			};
+
+			ti->arm_restart_block = (struct arm_restart_block) {
+				.cache = {
+					.start	= start,
+					.end	= end,
+				},
+			};
+
+			return -ERESTART_RESTARTBLOCK;
+		}
+
+		ret = flush_cache_user_range(start, start + chunk);
+		if (ret)
+			return ret;
+
+		cond_resched();
+		start += chunk;
+	} while (start < end);
+
+	return 0;
+}
+
+static long do_cache_op_restart(struct restart_block *unused)
+{
+	struct arm_restart_block *restart_block;
+
+	restart_block = &current_thread_info()->arm_restart_block;
+	return __do_cache_op(restart_block->cache.start,
+			     restart_block->cache.end);
+}
+
 static inline int
 do_cache_op(unsigned long start, unsigned long end, int flags)
 {
@@ -510,17 +556,18 @@ do_cache_op(unsigned long start, unsigned long end, int flags)
 
 	down_read(&mm->mmap_sem);
 	vma = find_vma(mm, start);
-	if (vma && vma->vm_start < end) {
-		if (start < vma->vm_start)
-			start = vma->vm_start;
-		if (end > vma->vm_end)
-			end = vma->vm_end;
-
+	if (!vma || vma->vm_start >= end) {
 		up_read(&mm->mmap_sem);
-		return flush_cache_user_range(start, end);
+		return -EINVAL;
 	}
+
+	if (start < vma->vm_start)
+		start = vma->vm_start;
+	if (end > vma->vm_end)
+		end = vma->vm_end;
 	up_read(&mm->mmap_sem);
-	return -EINVAL;
+
+	return __do_cache_op(start, end);
 }
 
 /*
-- 
1.8.2.2



From will.deacon at arm.com  Thu Jul 25 13:01:44 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 18:01:44 +0100
Subject: [PATCH v3 1/4] ARM: entry: allow ARM-private syscalls to be restarted
In-Reply-To: <1374771707-2619-1-git-send-email-will.deacon@arm.com>
References: <1374771707-2619-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374771707-2619-2-git-send-email-will.deacon@arm.com>

System calls will only be restarted after signal handling if they (a)
return an error code indicating that a restart is required and (b) have
`why' set to a non-zero value, to indicate that the signal interrupted
them.

This patch leaves `why' set to a non-zero value for ARM-private syscalls
, and only zeroes it for syscalls that are not implemented.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/kernel/entry-common.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 94104bf..74ad15d1 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -442,10 +442,10 @@ local_restart:
 	ldrcc	pc, [tbl, scno, lsl #2]		@ call sys_* routine
 
 	add	r1, sp, #S_OFF
-2:	mov	why, #0				@ no longer a real syscall
 	cmp	scno, #(__ARM_NR_BASE - __NR_SYSCALL_BASE)
 	eor	r0, scno, #__NR_SYSCALL_BASE	@ put OS number back
-	bcs	arm_syscall	
+	bcs	arm_syscall
+2:	mov	why, #0				@ no longer a real syscall
 	b	sys_ni_syscall			@ not private func
 
 #if defined(CONFIG_OABI_COMPAT) || !defined(CONFIG_AEABI)
-- 
1.8.2.2



From will.deacon at arm.com  Thu Jul 25 13:01:46 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 18:01:46 +0100
Subject: [PATCH v3 3/4] ARM: cacheflush: don't round address range up to
 nearest page
In-Reply-To: <1374771707-2619-1-git-send-email-will.deacon@arm.com>
References: <1374771707-2619-1-git-send-email-will.deacon@arm.com>
Message-ID: <1374771707-2619-4-git-send-email-will.deacon@arm.com>

The flush_cache_user_range macro takes a pair of addresses describing
the start and end of the virtual address range to flush. Due to an
accidental oversight when flush_cache_range_user was introduced, the
address range was rounded up so that the start and end addresses were
page-aligned.

For historical reference, the interesting commits in history.git are:

10eacf1775e1 ("[ARM] Clean up ARM cache handling interfaces (part 1)")
71432e79b76b ("[ARM] Add flush_cache_user_page() for sys_cacheflush()")

This patch removes the alignment code, reducing the amount of flushing
required for ranges that are not an exact multiple of PAGE_SIZE.

Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
Reported-by: Jonathan Austin <jonathan.austin at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/cacheflush.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
index 17d0ae8..bfd37e5 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -268,8 +268,7 @@ extern void flush_cache_page(struct vm_area_struct *vma, unsigned long user_addr
  * Harvard caches are synchronised for the user space address range.
  * This is used for the ARM private sys_cacheflush system call.
  */
-#define flush_cache_user_range(start,end) \
-	__cpuc_coherent_user_range((start) & PAGE_MASK, PAGE_ALIGN(end))
+#define flush_cache_user_range(s,e)	__cpuc_coherent_user_range(s,e)
 
 /*
  * Perform necessary cache operations to ensure that data previously
-- 
1.8.2.2



From jason at lakedaemon.net  Thu Jul 25 13:11:06 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 13:11:06 -0400
Subject: [PATCH v6 0/7] ARM: mvebu: switch to DT probed mv643xx_eth
In-Reply-To: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372762824-12202-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130725171106.GM23879@titan.lakedaemon.net>

On Tue, Jul 02, 2013 at 01:00:17PM +0200, Sebastian Hesselbarth wrote:
> This patch set converts Marvell Dove, Kirkwood, and Orion5x DT enabled
> boards to probe mv643xx_eth by DT. The corresponding DT support patches
> for mv643xx_eth driver have already been taked by David Miller and are
> available in next-20130701. This only contains the ARM part of
> mv643xx_eth DT support patches and therefore patch counting is
> continued as v6 with respect to the combined patch set.
> 
> The first three patches add nodes for ethernet-controller, mdio-bus,
> and ethernet PHYs found on the three SoCs and their boards.
> 
> The last four patches convert DT boards for each SoC from platform_device
> registration to DT based probing by removing the corresponding calls.
> For Kirkwood this makes almost all DT board setup (except board-dnskw)
> obsolete. Therefore, patch 5 removes board setup files, Kconfig, Makefile,
> and defconfig entries for those boards.
> 
> This patch set has been tested on Marvell Dove, and compile-tested for
> Kirkwood and Orion5x defconfig on top of next-20130701 with some fixes
> sent earlier applied (DMA_MEMSET fixes and missing include on edmini_v2).
> 
> netdev is added on Cc for completeness, this is all Marvell related and
> should go through Jason Cooper's branch if there are no objections.
> 
> Sebastian Hesselbarth (7):
>   ARM: dove: add gigabit ethernet and mvmdio device tree nodes
>   ARM: kirkwood: add gigabit ethernet and mvmdio device tree nodes
>   ARM: orion5x: add gigabit ethernet and mvmdio device tree nodes
>   ARM: dove: remove legacy mv643xx_eth setup
>   ARM: kirkwood: remove redundant DT board files
>   ARM: kirkwood: remove legacy clk alias for mv643xx_eth
>   ARM: orion5x: remove legacy mv643xx_eth board setup
> 
>  arch/arm/boot/dts/dove-cubox.dts                   |    7 +
>  arch/arm/boot/dts/dove.dtsi                        |   35 +++++
>  arch/arm/boot/dts/kirkwood-cloudbox.dts            |   16 ++
>  arch/arm/boot/dts/kirkwood-db.dtsi                 |   16 ++
>  arch/arm/boot/dts/kirkwood-dnskw.dtsi              |   16 ++
>  arch/arm/boot/dts/kirkwood-dockstar.dts            |   17 ++
>  arch/arm/boot/dts/kirkwood-dreamplug.dts           |   28 ++++
>  arch/arm/boot/dts/kirkwood-goflexnet.dts           |   16 ++
>  .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |   30 ++++
>  arch/arm/boot/dts/kirkwood-ib62x0.dts              |   16 ++
>  arch/arm/boot/dts/kirkwood-iconnect.dts            |   16 ++
>  arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts      |   24 +++
>  arch/arm/boot/dts/kirkwood-is2.dts                 |    2 +
>  arch/arm/boot/dts/kirkwood-km_kirkwood.dts         |   16 ++
>  arch/arm/boot/dts/kirkwood-lsxl.dtsi               |   28 ++++
>  arch/arm/boot/dts/kirkwood-mplcec4.dts             |   27 ++++
>  .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  |   16 ++
>  arch/arm/boot/dts/kirkwood-ns2-common.dtsi         |   16 ++
>  arch/arm/boot/dts/kirkwood-ns2.dts                 |    2 +
>  arch/arm/boot/dts/kirkwood-ns2lite.dts             |    2 +
>  arch/arm/boot/dts/kirkwood-ns2max.dts              |    2 +
>  arch/arm/boot/dts/kirkwood-ns2mini.dts             |    2 +
>  arch/arm/boot/dts/kirkwood-openblocks_a6.dts       |   16 ++
>  arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi  |   16 ++
>  arch/arm/boot/dts/kirkwood-topkick.dts             |   16 ++
>  arch/arm/boot/dts/kirkwood-ts219-6281.dts          |    4 +-
>  arch/arm/boot/dts/kirkwood-ts219-6282.dts          |    4 +-
>  arch/arm/boot/dts/kirkwood-ts219.dtsi              |   16 ++
>  arch/arm/boot/dts/kirkwood.dtsi                    |   52 +++++++
>  .../dts/orion5x-lacie-ethernet-disk-mini-v2.dts    |   17 ++
>  arch/arm/boot/dts/orion5x.dtsi                     |   29 ++++
>  arch/arm/configs/kirkwood_defconfig                |   22 ---
>  arch/arm/mach-dove/board-dt.c                      |    9 -
>  arch/arm/mach-kirkwood/Kconfig                     |  156 --------------------
>  arch/arm/mach-kirkwood/Makefile                    |   23 +---
>  arch/arm/mach-kirkwood/board-db88f628x-bp.c        |   24 ---
>  arch/arm/mach-kirkwood/board-dnskw.c               |    7 -
>  arch/arm/mach-kirkwood/board-dockstar.c            |   32 ----
>  arch/arm/mach-kirkwood/board-dreamplug.c           |   35 -----
>  arch/arm/mach-kirkwood/board-dt.c                  |   86 +-----------
>  arch/arm/mach-kirkwood/board-goflexnet.c           |   34 -----
>  arch/arm/mach-kirkwood/board-guruplug.c            |   33 ----
>  arch/arm/mach-kirkwood/board-ib62x0.c              |   29 ----
>  arch/arm/mach-kirkwood/board-iconnect.c            |   24 ---
>  arch/arm/mach-kirkwood/board-iomega_ix2_200.c      |   34 -----
>  arch/arm/mach-kirkwood/board-km_kirkwood.c         |   44 ------
>  arch/arm/mach-kirkwood/board-lsxl.c                |   36 -----
>  arch/arm/mach-kirkwood/board-mplcec4.c             |   35 -----
>  arch/arm/mach-kirkwood/board-ns2.c                 |   35 -----
>  arch/arm/mach-kirkwood/board-openblocks_a6.c       |   26 ----
>  arch/arm/mach-kirkwood/board-readynas.c            |   27 ----
>  arch/arm/mach-kirkwood/board-sheevaplug.c          |   27 ----
>  arch/arm/mach-kirkwood/board-ts219.c               |   40 -----
>  arch/arm/mach-kirkwood/board-usi_topkick.c         |   29 ----
>  arch/arm/mach-orion5x/edmini_v2-setup.c            |   10 --
>  55 files changed, 520 insertions(+), 857 deletions(-)
>  delete mode 100644 arch/arm/mach-kirkwood/board-db88f628x-bp.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-dockstar.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-dreamplug.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-goflexnet.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-guruplug.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-ib62x0.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-iconnect.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-iomega_ix2_200.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-km_kirkwood.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-lsxl.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-mplcec4.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-ns2.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-openblocks_a6.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-readynas.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-sheevaplug.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-ts219.c
>  delete mode 100644 arch/arm/mach-kirkwood/board-usi_topkick.c

Applied whole series to mvebu/boards (v7 of #2 and #5)

thx,

Jason.


From Dave.Martin at arm.com  Thu Jul 25 13:11:30 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Thu, 25 Jul 2013 18:11:30 +0100
Subject: [PATCH] ARM: kdgb: use .inst for data to be assembled as
 intruction
In-Reply-To: <1374763778-5305-2-git-send-email-ben.dooks@codethink.co.uk>
References: <1374763778-5305-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374763778-5305-2-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130725171130.GE2546@localhost.localdomain>

On Thu, Jul 25, 2013 at 03:49:38PM +0100, Ben Dooks wrote:
> The arch_kgdb_breakpoint() function uses an inline assembly directive
> to assemble a specific instruction using .word. This means the linker
> will not treat is as an instruction, and therefore incorrectly swap
> the endian-ness if running BE8.
> 
> Note, not tested, please comment if this is wrong.
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---
>  arch/arm/include/asm/kgdb.h |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/kgdb.h b/arch/arm/include/asm/kgdb.h
> index 48066ce..76227c8 100644
> --- a/arch/arm/include/asm/kgdb.h
> +++ b/arch/arm/include/asm/kgdb.h
> @@ -41,7 +41,7 @@
>  
>  static inline void arch_kgdb_breakpoint(void)
>  {
> -	asm(".word 0xe7ffdeff");
> +	asm(".inst 0xe7ffdeff");

Yikes, this isn't going to work in a Thumb kernel.

We should make HAVE_ARCH_KGDB depend on !THUMB2_KERNEL until/unless that
gets fixed...  It looks like the incompatibilities may be more extensive
than just this one instruction.


For the ARM case, similarly to the other patches, please use the __inst
macros from <asm/opcodes.h> instead of emitting the opcode explicitly.

Cheers
---Dave


From ben.dooks at codethink.co.uk  Thu Jul 25 13:13:18 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 18:13:18 +0100
Subject: [PATCH] ARM: kdgb: use .inst for data to be assembled as
 intruction
In-Reply-To: <20130725171130.GE2546@localhost.localdomain>
References: <1374763778-5305-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374763778-5305-2-git-send-email-ben.dooks@codethink.co.uk>
 <20130725171130.GE2546@localhost.localdomain>
Message-ID: <51F15CAE.7020008@codethink.co.uk>

On 25/07/13 18:11, Dave Martin wrote:
> On Thu, Jul 25, 2013 at 03:49:38PM +0100, Ben Dooks wrote:
>> The arch_kgdb_breakpoint() function uses an inline assembly directive
>> to assemble a specific instruction using .word. This means the linker
>> will not treat is as an instruction, and therefore incorrectly swap
>> the endian-ness if running BE8.
>>
>> Note, not tested, please comment if this is wrong.
>>
>> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
>> ---
>>   arch/arm/include/asm/kgdb.h |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/include/asm/kgdb.h b/arch/arm/include/asm/kgdb.h
>> index 48066ce..76227c8 100644
>> --- a/arch/arm/include/asm/kgdb.h
>> +++ b/arch/arm/include/asm/kgdb.h
>> @@ -41,7 +41,7 @@
>>
>>   static inline void arch_kgdb_breakpoint(void)
>>   {
>> -	asm(".word 0xe7ffdeff");
>> +	asm(".inst 0xe7ffdeff");
>
> Yikes, this isn't going to work in a Thumb kernel.
>
> We should make HAVE_ARCH_KGDB depend on !THUMB2_KERNEL until/unless that
> gets fixed...  It looks like the incompatibilities may be more extensive
> than just this one instruction.
>
>
> For the ARM case, similarly to the other patches, please use the __inst
> macros from<asm/opcodes.h>  instead of emitting the opcode explicitly.

See previous objections to that, plus they're marked for internal use
only!

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From jonathan.austin at arm.com  Thu Jul 25 13:15:10 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Thu, 25 Jul 2013 18:15:10 +0100
Subject: [PATCH 03/13] ARM: b.L: core switcher code
In-Reply-To: <1374550289-25305-4-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-4-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <51F15D1E.20309@arm.com>

Hi Nico,

I've got a few more questions here...

On 23/07/13 04:31, Nicolas Pitre wrote:
> This is the core code implementing big.LITTLE switcher functionality.
> Rational for this code is available here:
>
> http://lwn.net/Articles/481055/
>
> The main entry point for a switch request is:
>
> void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
>
> If the calling CPU is not the wanted one, this wrapper takes care of
> sending the request to the appropriate CPU with schedule_work_on().
>
> At the moment the core switch operation is handled by bL_switch_to()
> which must be called on the CPU for which a switch is requested.
>
> What this code does:
>
>    * Return early if the current cluster is the wanted one.
>
>    * Close the gate in the kernel entry vector for both the inbound
>      and outbound CPUs.
>
>    * Wake up the inbound CPU so it can perform its reset sequence in
>      parallel up to the kernel entry vector gate.
>
>    * Migrate all interrupts in the GIC targeting the outbound CPU
>      interface to the inbound CPU interface, including SGIs. This is
>      performed by gic_migrate_target() in drivers/irqchip/irq-gic.c.
>
>    * Call cpu_pm_enter() which takes care of flushing the VFP state to
>      RAM and save the CPU interface config from the GIC to RAM.
>
>    * Modify the cpu_logical_map to refer to the inbound physical CPU.
>
>    * Call cpu_suspend() which saves the CPU state (general purpose
>      registers, page table address) onto the stack and store the
>      resulting stack pointer in an array indexed by the updated
>      cpu_logical_map, then call the provided shutdown function.
>      This happens in arch/arm/kernel/sleep.S.
>
> At this point, the provided shutdown function executed by the outbound
> CPU ungates the inbound CPU. Therefore the inbound CPU:
>
>    * Picks up the saved stack pointer in the array indexed by its MPIDR
>      in arch/arm/kernel/sleep.S.
>
>    * The MMU and caches are re-enabled using the saved state on the
>      provided stack, just like if this was a resume operation from a
>      suspended state.
>
>    * Then cpu_suspend() returns, although this is on the inbound CPU
>      rather than the outbound CPU which called it initially.
>
>    * The function cpu_pm_exit() is called which effect is to restore the
>      CPU interface state in the GIC using the state previously saved by
>      the outbound CPU.
>
>    * Exit of bL_switch_to() to resume normal kernel execution on the
>      new CPU.
>
> However, the outbound CPU is potentially still running in parallel while
> the inbound CPU is resuming normal kernel execution, hence we need
> per CPU stack isolation to execute bL_do_switch().  After the outbound
> CPU has ungated the inbound CPU, it calls mcpm_cpu_power_down() to:
>
>    * Clean its L1 cache.
>
>    * If it is the last CPU still alive in its cluster (last man standing),
>      it also cleans its L2 cache and disables cache snooping from the other
>      cluster.
>
>    * Power down the CPU (or whole cluster).
>
> Code called from bL_do_switch() might end up referencing 'current' for
> some reasons.  However, 'current' is derived from the stack pointer.
> With any arbitrary stack, the returned value for 'current' and any
> dereferenced values through it are just random garbage which may lead to
> segmentation faults.
>
> The active page table during the execution of bL_do_switch() is also a
> problem.  There is no guarantee that the inbound CPU won't destroy the
> corresponding task which would free the attached page table while the
> outbound CPU is still running and relying on it.
>
> To solve both issues, we borrow some of the task space belonging to
> the init/idle task which, by its nature, is lightly used and therefore
> is unlikely to clash with our usage.  The init task is also never going
> away.

I had written a comment here about this looking hairy, and asking 
whether you'd considered using dedicated threads for this.

As I hit the later patches in the series I see that's exactly what 
you've done. Is it really worth keeping the historical solution in here? 
Could build/bisectability be maintained by moving the Kconfig options 
later in the series, but without requiring the weird init/idle hack to 
be kept around?

>
> Right now the logical CPU number is assumed to be equivalent to the
> physical CPU number within each cluster. The kernel should also be
> booted with only one cluster active.  These limitations will be lifted
> eventually.
>

I just read this aloud in the office and Dave Martin mentioned that the 
MPIDR hashing schemes make this obselete now?

> Signed-off-by: Nicolas Pitre <nico at linaro.org>
> ---
>   arch/arm/Kconfig                   |  17 +++
>   arch/arm/common/Makefile           |   1 +
>   arch/arm/common/bL_switcher.c      | 247 +++++++++++++++++++++++++++++++++++++
>   arch/arm/include/asm/bL_switcher.h |  17 +++
>   4 files changed, 282 insertions(+)
>   create mode 100644 arch/arm/common/bL_switcher.c
>   create mode 100644 arch/arm/include/asm/bL_switcher.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index ba412e02ec..2c9e5bf734 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1538,6 +1538,23 @@ config MCPM
>            for (multi-)cluster based systems, such as big.LITTLE based
>            systems.
>
> +config BIG_LITTLE
> +       bool "big.LITTLE support (Experimental)"
> +       depends on CPU_V7 && SMP
> +       select MCPM
> +       help
> +         This option enables support for the big.LITTLE architecture.

I'm not sure we should describe this as an architecture?

"This option enables support for big.LITTLE processing"?

What are the plans for/implications of having CONFIG_BIG_LITTLE and 
!CONFIG_BL_SWITCHER?

> +
> +config BL_SWITCHER
> +       bool "big.LITTLE switcher support"
> +       depends on BIG_LITTLE && MCPM && HOTPLUG_CPU
> +       select CPU_PM
> +       select ARM_CPU_SUSPEND
> +       help
> +         The big.LITTLE "switcher" provides the core functionality to
> +         transparently handle transition between a cluster of A15's
> +         and a cluster of A7's in a big.LITTLE system.
> +
>   choice
>          prompt "Memory split"
>          default VMSPLIT_3G
> diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
> index 8c60f473e9..2586240d5a 100644
> --- a/arch/arm/common/Makefile
> +++ b/arch/arm/common/Makefile
> @@ -17,3 +17,4 @@ obj-$(CONFIG_MCPM)            += mcpm_head.o mcpm_entry.o mcpm_platsmp.o vlock.o
>   AFLAGS_mcpm_head.o             := -march=armv7-a
>   AFLAGS_vlock.o                 := -march=armv7-a
>   obj-$(CONFIG_TI_PRIV_EDMA)     += edma.o
> +obj-$(CONFIG_BL_SWITCHER)      += bL_switcher.o
> diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> new file mode 100644
> index 0000000000..e63881b430
> --- /dev/null
> +++ b/arch/arm/common/bL_switcher.c
> @@ -0,0 +1,247 @@
> +/*
> + * arch/arm/common/bL_switcher.c -- big.LITTLE cluster switcher core driver
> + *
> + * Created by: Nicolas Pitre, March 2012
> + * Copyright:  (C) 2012-2013  Linaro Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/sched.h>
> +#include <linux/interrupt.h>
> +#include <linux/cpu_pm.h>
> +#include <linux/workqueue.h>
> +#include <linux/mm.h>
> +#include <linux/string.h>
> +#include <linux/irqchip/arm-gic.h>
> +
> +#include <asm/smp_plat.h>
> +#include <asm/cacheflush.h>
> +#include <asm/suspend.h>
> +#include <asm/mcpm.h>
> +#include <asm/bL_switcher.h>
> +
> +
> +/*
> + * Use our own MPIDR accessors as the generic ones in asm/cputype.h have
> + * __attribute_const__ and we don't want the compiler to assume any
> + * constness here as the value _does_ change along some code paths.
> + */
> +
> +static int read_mpidr(void)
> +{
> +       unsigned int id;
> +       asm volatile ("mrc\tp15, 0, %0, c0, c0, 5" : "=r" (id));

Is the \t in here an artefact of our mail servers? I notice that in 
other places, for example arch/arm/include/asm/cp15.h, we don't have 
that formatting.

> +       return id & MPIDR_HWID_BITMASK;
> +}
> +
> +/*
> + * bL switcher core code.
> + */
> +
> +static void bL_do_switch(void *_unused)
> +{
> +       unsigned mpidr, cpuid, clusterid, ob_cluster, ib_cluster;
> +
> +       /*
> +        * We now have a piece of stack borrowed from the init task's.
> +        * Let's also switch to init_mm right away to match it.
> +        */
> +       cpu_switch_mm(init_mm.pgd, &init_mm);
> +
> +       pr_debug("%s\n", __func__);

This looks like fairly uninformative debug - is it left here 
intentionally? If so, isn't there a better message to print than just 
the function name?
> +
> +       mpidr = read_mpidr();
> +       cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +       clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> +       ob_cluster = clusterid;
> +       ib_cluster = clusterid ^ 1;
> +
> +       /*
> +        * Our state has been saved at this point.  Let's release our
> +        * inbound CPU.
> +        */
> +       mcpm_set_entry_vector(cpuid, ib_cluster, cpu_resume);
> +       sev();
> +
> +       /*
> +        * From this point, we must assume that our counterpart CPU might
> +        * have taken over in its parallel world already, as if execution
> +        * just returned from cpu_suspend().  It is therefore important to
> +        * be very careful not to make any change the other guy is not
> +        * expecting.  This is why we need stack isolation.
> +        *
> +        * Fancy under cover tasks could be performed here.  For now
> +        * we have none.
> +        */
> +
> +       /* Let's put ourself down. */
> +       mcpm_cpu_power_down();
> +
> +       /* should never get here */
> +       BUG();
> +}
> +
> +/*
> + * Stack isolation.  To ensure 'current' remains valid, we just borrow
> + * a slice of the init/idle task which should be fairly lightly used.
> + * The borrowed area starts just above the thread_info structure located
> + * at the very bottom of the stack, aligned to a cache line.
> + */
> +#define STACK_SIZE 256
> +extern void call_with_stack(void (*fn)(void *), void *arg, void *sp);
> +static int bL_switchpoint(unsigned long _arg)
> +{
> +       unsigned int mpidr = read_mpidr();
> +       unsigned int cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +       unsigned int clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> +       unsigned int cpu_index = cpuid + clusterid * MAX_CPUS_PER_CLUSTER;
> +       void *stack = &init_thread_info + 1;
> +       stack = PTR_ALIGN(stack, L1_CACHE_BYTES);

Are there any implications if there were big.LITTLE cores with different 
cache line sizes? The LWN article that you reference mentions different 
cache topologies...

> +       stack += cpu_index * STACK_SIZE + STACK_SIZE;
> +       call_with_stack(bL_do_switch, (void *)_arg, stack);
> +       BUG();
> +}
> +
> +/*
> + * Generic switcher interface
> + */
> +
> +/*
> + * bL_switch_to - Switch to a specific cluster for the current CPU
> + * @new_cluster_id: the ID of the cluster to switch to.
> + *
> + * This function must be called on the CPU to be switched.
> + * Returns 0 on success, else a negative status code.
> + */
> +static int bL_switch_to(unsigned int new_cluster_id)
> +{
> +       unsigned int mpidr, cpuid, clusterid, ob_cluster, ib_cluster, this_cpu;
> +       int ret;
> +
> +       mpidr = read_mpidr();
> +       cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +       clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> +       ob_cluster = clusterid;
> +       ib_cluster = clusterid ^ 1;
> +
> +       if (new_cluster_id == clusterid)
> +               return 0;
> +
> +       pr_debug("before switch: CPU %d in cluster %d\n", cpuid, clusterid);
> +
> +       /* Close the gate for our entry vectors */
> +       mcpm_set_entry_vector(cpuid, ob_cluster, NULL);
> +       mcpm_set_entry_vector(cpuid, ib_cluster, NULL);
> +
> +       /*
> +        * Let's wake up the inbound CPU now in case it requires some delay
> +        * to come online, but leave it gated in our entry vector code.
> +        */
> +       ret = mcpm_cpu_power_up(cpuid, ib_cluster);
> +       if (ret) {
> +               pr_err("%s: mcpm_cpu_power_up() returned %d\n", __func__, ret);
> +               return ret;
> +       }
> +
> +       /*
> +        * From this point we are entering the switch critical zone
> +        * and can't sleep/schedule anymore.
> +        */

Will this function ever be called from anywhere other than 
bL_switch_request? As far as I could see, bl_switch_request uses two 
different methods of ensuring that we will still be on the same CPU 
throughout this function (if called directly the get_cpu and put_cpu 
dis/enbale pre-emption and via the work queue we're guaranteed the same 
logical cpu). The different approaches somewhat obfuscate the need for 
something to have been done even before this point to stop us getting 
migrated to another CPU, I think...

> +       local_irq_disable();
> +       local_fiq_disable();
> +
> +       this_cpu = smp_processor_id();
> +
> +       /* redirect GIC's SGIs to our counterpart */
> +       gic_migrate_target(cpuid + ib_cluster*4);
> +
> +       /*
> +        * Raise a SGI on the inbound CPU to make sure it doesn't stall
> +        * in a possible WFI, such as in mcpm_power_down().
> +        */
> +       arch_send_wakeup_ipi_mask(cpumask_of(this_cpu));
> +
> +       ret = cpu_pm_enter();
> +
> +       /* we can not tolerate errors at this point */
> +       if (ret)
> +               panic("%s: cpu_pm_enter() returned %d\n", __func__, ret);
> +
> +       /*
> +        * Flip the cluster in the CPU logical map for this CPU.
> +        * This must be flushed to RAM as the resume code
> +        * needs to access it while the caches are still disabled.
> +        */
> +       cpu_logical_map(this_cpu) ^= (1 << 8);
> +       sync_cache_w(&cpu_logical_map(this_cpu));
> +
> +       /* Let's do the actual CPU switch. */
> +       ret = cpu_suspend(0, bL_switchpoint);
> +       if (ret > 0)
> +               panic("%s: cpu_suspend() returned %d\n", __func__, ret);
> +
> +       /* We are executing on the inbound CPU at this point */

Very cool :)

> +       mpidr = read_mpidr();
> +       cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +       clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> +       pr_debug("after switch: CPU %d in cluster %d\n", cpuid, clusterid);

Do we want a 'switcher' prefix on these? "bL_switcher: after switch..." etc?

> +       BUG_ON(clusterid != ib_cluster);
> +
> +       mcpm_cpu_powered_up();
> +
> +       ret = cpu_pm_exit();
> +
> +       local_fiq_enable();
> +       local_irq_enable();
> +
> +       if (ret)
> +               pr_err("%s exiting with error %d\n", __func__, ret);
> +       return ret;
> +}
> +
> +struct switch_args {
> +       unsigned int cluster;
> +       struct work_struct work;
> +};
> +
> +static void __bL_switch_to(struct work_struct *work)
> +{
> +       struct switch_args *args = container_of(work, struct switch_args, work);
> +       bL_switch_to(args->cluster);
> +}
> +
> +/*
> + * bL_switch_request - Switch to a specific cluster for the given CPU
> + *
> + * @cpu: the CPU to switch
> + * @new_cluster_id: the ID of the cluster to switch to.
> + *
> + * This function causes a cluster switch on the given CPU.  If the given
> + * CPU is the same as the calling CPU then the switch happens right away.
> + * Otherwise the request is put on a work queue to be scheduled on the
> + * remote CPU.
> + */
> +void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
> +{
> +       unsigned int this_cpu = get_cpu();
> +       struct switch_args args;
> +
> +       if (cpu == this_cpu) {
> +               bL_switch_to(new_cluster_id);
> +               put_cpu();
> +               return;
> +       }
> +       put_cpu();
> +
> +       args.cluster = new_cluster_id;
> +       INIT_WORK_ONSTACK(&args.work, __bL_switch_to);
> +       schedule_work_on(cpu, &args.work);

The comment at the top of schedule_work_on() says:
  [...]
  * We queue the work to a specific CPU, the caller must ensure it
  * can't go away.
  [...]

I see we don't disable cpu hotplug requests until later in the series - 
does that matter? Until that patch, it seems that we could hotplug off 
the core that we'd scheduled the work onto?


> +       flush_work(&args.work);
> +}
> +EXPORT_SYMBOL_GPL(bL_switch_request);
> diff --git a/arch/arm/include/asm/bL_switcher.h b/arch/arm/include/asm/bL_switcher.h
> new file mode 100644
> index 0000000000..72efe3f349
> --- /dev/null
> +++ b/arch/arm/include/asm/bL_switcher.h
> @@ -0,0 +1,17 @@
> +/*
> + * arch/arm/include/asm/bL_switcher.h
> + *
> + * Created by:  Nicolas Pitre, April 2012
> + * Copyright:   (C) 2012-2013  Linaro Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef ASM_BL_SWITCHER_H
> +#define ASM_BL_SWITCHER_H
> +
> +void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id);
> +
> +#endif
> --
> 1.8.1.2
>
Hope some of those questions are helpful,

Jonny





From tom.cooksey at arm.com  Thu Jul 25 13:17:27 2013
From: tom.cooksey at arm.com (tom.cooksey at arm.com)
Date: Thu, 25 Jul 2013 18:17:27 +0100
Subject: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
Message-ID: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com>

From: Tom Cooksey <tom.cooksey at arm.com>

Please find below the current state of our pl111 DRM/KMS driver. This
is lightly tested on a Versatile Express using X running the
xf86-video-armsoc DDX driver[i] with the patches applied to drm-next
as of ~last week. To actually see anything on the DVI output, you
must also apply Pawel Moll's VExpress DVI mux driver[ii] to select
the video signal from the ca9x4 core tile.

[i] <https://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git;a=summary>
[ii] <https://patchwork.kernel.org/patch/1765981/>


Known issues:
 * It uses KDS. We intend to switch to whatever implicit per-buffer
   synchronisation mechanism gets merged, once something is merged.
 * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
   allocate buffers for the GPU. Still not sure how to resolve this
   as we don't use DRM for our GPU driver.
 * Doesn't handle page flip event sequence numbers and timestamps
 * The v_sync handling needs work in general - a work queue is a
   little overkill
 * Doesn't support the import half of PRIME properly, only export
 * Need to validate src rectangle size in
   pl111_drm_cursor_plane_update()
 * Only supports 640x480 mode, which is hard-coded. We intend to
   rebase on top of CDF once it is merged, which hopefully will
   handle a lot of the EDID parsing & mode setting for us (once
   Pawel's CDF patches for VExpress also land).

I appreciate that's a fairly hefty list of known issues already!
However, we're waiting for both CDF & dma_buf sync mechanisms to land
before we can address some of those. So in the mean-time, I thought
someone might be interested in taking a look at what we have so far,
which is why I'm posting this now. Needless to say the code will need
to be refactored a fair bit, however I'm keen to get and additional
feedback anyone cares to give.


Cheers,

Tom

Tom Cooksey (1):
  drm/pl111: Initial drm/kms driver for pl111 display controller

 drivers/gpu/drm/Kconfig                     |    2 +
 drivers/gpu/drm/Makefile                    |    1 +
 drivers/gpu/drm/pl111/Kbuild                |   14 +
 drivers/gpu/drm/pl111/Kconfig               |    9 +
 drivers/gpu/drm/pl111/pl111_clcd_ext.h      |   78 ++++
 drivers/gpu/drm/pl111/pl111_drm.h           |  227 ++++++++++++
 drivers/gpu/drm/pl111/pl111_drm_connector.c |  166 +++++++++
 drivers/gpu/drm/pl111/pl111_drm_crtc.c      |  432 ++++++++++++++++++++++
 drivers/gpu/drm/pl111/pl111_drm_cursor.c    |   97 +++++
 drivers/gpu/drm/pl111/pl111_drm_device.c    |  319 +++++++++++++++++
 drivers/gpu/drm/pl111/pl111_drm_dma_buf.c   |  339 ++++++++++++++++++
 drivers/gpu/drm/pl111/pl111_drm_encoder.c   |  106 ++++++
 drivers/gpu/drm/pl111/pl111_drm_fb.c        |  152 ++++++++
 drivers/gpu/drm/pl111/pl111_drm_funcs.h     |  127 +++++++
 drivers/gpu/drm/pl111/pl111_drm_gem.c       |  287 +++++++++++++++
 drivers/gpu/drm/pl111/pl111_drm_pl111.c     |  513 +++++++++++++++++++++++++++
 drivers/gpu/drm/pl111/pl111_drm_platform.c  |  150 ++++++++
 drivers/gpu/drm/pl111/pl111_drm_suspend.c   |   35 ++
 drivers/gpu/drm/pl111/pl111_drm_vma.c       |  214 +++++++++++
 19 files changed, 3268 insertions(+)
 create mode 100644 drivers/gpu/drm/pl111/Kbuild
 create mode 100644 drivers/gpu/drm/pl111/Kconfig
 create mode 100644 drivers/gpu/drm/pl111/pl111_clcd_ext.h
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm.h
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_connector.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_crtc.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_cursor.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_device.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_dma_buf.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_encoder.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_fb.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_funcs.h
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_gem.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_pl111.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_platform.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_suspend.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_vma.c

-- 
1.7.9.5




From shc_work at mail.ru  Thu Jul 25 13:20:53 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Thu, 25 Jul 2013 21:20:53 +0400
Subject: [PATCH 2/2] video: imxfb: Add feature to setup PWM Contrast
 Control Register
In-Reply-To: <20130725133824.GD16871@s25.your-server.de>
References: <1374395709-20898-1-git-send-email-shc_work@mail.ru>
 <1374395709-20898-2-git-send-email-shc_work@mail.ru>
 <20130725133824.GD16871@s25.your-server.de>
Message-ID: <20130725212053.b39198a8610efc157a91b7be@mail.ru>

On Thu, 25 Jul 2013 15:38:56 +0200
Markus Pargmann <mpa at pengutronix.de> wrote:

> Hi,
> 
> On Sun, Jul 21, 2013 at 12:35:09PM +0400, Alexander Shiyan wrote:
> > This patch adds feature to setup PWM Contrast Control Register.
> > This register is used to control the signal output at the contrast pin,
> > which controls contrast of the LCD panel.
> 
> http://www.spinics.net/lists/linux-fbdev/msg10002.html

PWM? I can not understand how the PWM driver will be connected to the
framebuffer driver. It is not backlight, this is contrast.
Even if we imagine that the driver will be connected through phandle,
then we will need to have at least 4! additional parameters in the framebuffer
driver: freq source, frequency and active pulse period + phandle to PWM.
Is it worth it, given that these parameters should not be adjustable?
On my opinion, the only one additional parameter in framebuffer is enough.
Thanks.

[...]
> > ---
> >  Documentation/devicetree/bindings/video/fsl,imx-fb.txt | 1 +
> >  drivers/video/imxfb.c                                  | 2 +-
> >  2 files changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > index 46da08d..be10c65 100644
> > --- a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > @@ -18,6 +18,7 @@ Optional properties:
> >  - fsl,dmacr: DMA Control Register value. This is optional. By default, the
> >  	register is not modified as recommended by the datasheet.
> >  - fsl,lscr1: LCDC Sharp Configuration Register value.
> > +- fsl,pwmr: LCDC PWM Contrast Control Register value.
> >  
> >  Example:
> >  
> > diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> > index 8e104c4..d98299a 100644
> > --- a/drivers/video/imxfb.c
> > +++ b/drivers/video/imxfb.c
> > @@ -806,8 +806,8 @@ static int imxfb_init_fbinfo(struct platform_device *pdev,
> >  
> >  		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
> >  		of_property_read_u32(np, "fsl,lscr1", &fbi->lscr1);
> > -
> >  		of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
> > +		of_property_read_u32(np, "fsl,pwmr", &fbi->pwmr);
> >  
> >  		/* These two function pointers could be used by some specific
> >  		 * platforms. */
> > -- 

-- 
Alexander Shiyan <shc_work at mail.ru>


From balbi at ti.com  Thu Jul 25 13:28:55 2013
From: balbi at ti.com (Felipe Balbi)
Date: Thu, 25 Jul 2013 20:28:55 +0300
Subject: [PATCH 1/6] usb: phy-nop: Use RESET Controller for managing the
 reset line
In-Reply-To: <1374137590-17865-2-git-send-email-rogerq@ti.com>
References: <1374137590-17865-1-git-send-email-rogerq@ti.com>
 <1374137590-17865-2-git-send-email-rogerq@ti.com>
Message-ID: <20130725172855.GJ25415@radagast>

On Thu, Jul 18, 2013 at 11:53:05AM +0300, Roger Quadros wrote:
> Till now we were modelling the RESET line as a voltage regulator and
> using the regulator framework to manage it.
> 
> [1] introduces a GPIO based reset controller driver. We use that
> to manage the PHY reset line, at least for DT boots. For legacy boots,
> will still need to use the regulator framework for reset lines.
> 
> [1] - http://thread.gmane.org/gmane.linux.drivers.devicetree/41348
> 
> Signed-off-by: Roger Quadros <rogerq at ti.com>

that's not in mainline yet, right ? Is it guaranteed that it will hit
v3.12 merge window ?

-- 
balbi
-------------- 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/20130725/fa2fd658/attachment.sig>

From sboyd at codeaurora.org  Thu Jul 25 13:31:22 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Jul 2013 10:31:22 -0700
Subject: [PATCH 4/6] ARM: locks: prefetch the destination word for write
 prior to strex
In-Reply-To: <20130724111841.GD11072@mudshark.cambridge.arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-5-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231609170.15022@syhkavp.arg>
 <20130724111841.GD11072@mudshark.cambridge.arm.com>
Message-ID: <51F160EA.6030800@codeaurora.org>

On 07/24/13 04:18, Will Deacon wrote:
> On Tue, Jul 23, 2013 at 09:10:33PM +0100, Nicolas Pitre wrote:
>> On Tue, 23 Jul 2013, Will Deacon wrote:
>>
>>> The cost of changing a cacheline from shared to exclusive state can be
>>> significant, especially when this is triggered by an exclusive store,
>>> since it may result in having to retry the transaction.
>>>
>>> This patch prefixes our {spin,read,write}_[try]lock implementations with
>>> pldw instructions (on CPUs which support them) to try and grab the line
>>> in exclusive state from the start.
>>>
>>> Signed-off-by: Will Deacon <will.deacon at arm.com>
>>> ---
>>>  arch/arm/include/asm/spinlock.h | 9 ++++++++-
>>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
>>> index 0de7bec..3e1cc9d 100644
>>> --- a/arch/arm/include/asm/spinlock.h
>>> +++ b/arch/arm/include/asm/spinlock.h
>>> @@ -5,7 +5,7 @@
>>>  #error SMP not supported on pre-ARMv6 CPUs
>>>  #endif
>>>  
>>> -#include <asm/processor.h>
>>> +#include <linux/prefetch.h>
>>>  
>>>  /*
>>>   * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
>>> @@ -70,6 +70,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
>>>  	u32 newval;
>>>  	arch_spinlock_t lockval;
>>>  
>>> +	prefetchw((const void *)&lock->slock);
>> Couldn't that cast be carried in the definition of prefetchw() instead?
> I think that would mean implementing prefetchw as a macro rather than an
> inline function, since the core code expects to pass a const pointer and GCC
> gets angry if the type signatures don't match.

Maybe I'm wrong, but can't you just remove the casts and leave the
function as static inline? const void * is pretty much telling the
compiler to turn off type checking.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From jason at lakedaemon.net  Thu Jul 25 13:33:57 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 13:33:57 -0400
Subject: [GIT PULL] ARM: mvebu: stable fix for v3.10
Message-ID: <20130725173357.GN23879@titan.lakedaemon.net>

Arnd, Olof,

I'm trying something new.  I've based this branch off of the common
ancestor to the v3.10.x tree (v3.10).  If you could handle it just like
a normal mvebu/fixes branch (ie merge it in for v3.11-rcX), once it hits
mainline, I'll send a PR to the stable folks for the branch.

The advantage of this is that you get the same commit id in both trees
and it's less work for the stable maintainers.

Also, please note the URL change.  I'll post an announcement about that
shortly.

As usual, please tell me if I'm all fouled up. :)

thx,

Jason.


The following changes since commit 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376:

  Linux 3.10 (2013-06-30 15:13:29 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-mvebu.git tags/stable-3.10

for you to fetch changes up to 449a7d428f46f8bfab68cd15afe7e2eca4c71edb:

  ARM: orion5x: add missing mbus include (2013-07-25 17:01:24 +0000)

----------------------------------------------------------------
mvebu stable changes for v3.10

 - fix build failure for orion5x_defconfig

----------------------------------------------------------------
Sebastian Hesselbarth (1):
      ARM: orion5x: add missing mbus include

 arch/arm/mach-orion5x/edmini_v2-setup.c | 1 +
 1 file changed, 1 insertion(+)


From sboyd at codeaurora.org  Thu Jul 25 13:37:48 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Jul 2013 10:37:48 -0700
Subject: [PATCH 4/6] ARM: locks: prefetch the destination word for write
 prior to strex
In-Reply-To: <51F160EA.6030800@codeaurora.org>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-5-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231609170.15022@syhkavp.arg>
 <20130724111841.GD11072@mudshark.cambridge.arm.com>
 <51F160EA.6030800@codeaurora.org>
Message-ID: <51F1626C.3050008@codeaurora.org>

On 07/25/13 10:31, Stephen Boyd wrote:
> On 07/24/13 04:18, Will Deacon wrote:
>> On Tue, Jul 23, 2013 at 09:10:33PM +0100, Nicolas Pitre wrote:
>>> On Tue, 23 Jul 2013, Will Deacon wrote:
>>>
>>>> The cost of changing a cacheline from shared to exclusive state can be
>>>> significant, especially when this is triggered by an exclusive store,
>>>> since it may result in having to retry the transaction.
>>>>
>>>> This patch prefixes our {spin,read,write}_[try]lock implementations with
>>>> pldw instructions (on CPUs which support them) to try and grab the line
>>>> in exclusive state from the start.
>>>>
>>>> Signed-off-by: Will Deacon <will.deacon at arm.com>
>>>> ---
>>>>  arch/arm/include/asm/spinlock.h | 9 ++++++++-
>>>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
>>>> index 0de7bec..3e1cc9d 100644
>>>> --- a/arch/arm/include/asm/spinlock.h
>>>> +++ b/arch/arm/include/asm/spinlock.h
>>>> @@ -5,7 +5,7 @@
>>>>  #error SMP not supported on pre-ARMv6 CPUs
>>>>  #endif
>>>>  
>>>> -#include <asm/processor.h>
>>>> +#include <linux/prefetch.h>
>>>>  
>>>>  /*
>>>>   * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
>>>> @@ -70,6 +70,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
>>>>  	u32 newval;
>>>>  	arch_spinlock_t lockval;
>>>>  
>>>> +	prefetchw((const void *)&lock->slock);
>>> Couldn't that cast be carried in the definition of prefetchw() instead?
>> I think that would mean implementing prefetchw as a macro rather than an
>> inline function, since the core code expects to pass a const pointer and GCC
>> gets angry if the type signatures don't match.
> Maybe I'm wrong, but can't you just remove the casts and leave the
> function as static inline? const void * is pretty much telling the
> compiler to turn off type checking.
>

Oh joy. Why is rwlock's lock member marked volatile?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From jason at lakedaemon.net  Thu Jul 25 13:41:32 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 13:41:32 -0400
Subject: [GIT PULL] ARM: mvebu: fixes-non-critical for v3.12
Message-ID: <20130725174132.GO23879@titan.lakedaemon.net>


The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b:

  Linux 3.11-rc2 (2013-07-21 12:05:29 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-mvebu.git tags/fixes-non-3.12

for you to fetch changes up to 2746a7c272a3242f919fa2fd5a5f2d9f8a41173a:

  ARM: dove: fix missing __init section of dove_mpp_gpio_mode (2013-07-25 15:22:17 +0000)

----------------------------------------------------------------
mvebu fixes-non-critical for v3.12

 - dove
    - fix section mismatch (all callers are already _init, so it's just a space
      issue)

----------------------------------------------------------------
Sebastian Hesselbarth (1):
      ARM: dove: fix missing __init section of dove_mpp_gpio_mode

 arch/arm/mach-dove/mpp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


From mturquette at linaro.org  Thu Jul 25 13:44:16 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 25 Jul 2013 10:44:16 -0700
Subject: [PATCH 2/2] clk: fixup argument order when setting VCO parameters
In-Reply-To: <51F0F035.8010705@arm.com>
References: <1374594138-17080-1-git-send-email-jonathan.austin@arm.com>
 <1374594138-17080-3-git-send-email-jonathan.austin@arm.com>
 <CACRpkdbEiNPG0b89zXKpvNgXtAbsKeV9A9ibgEJCBgNa6vQvCw@mail.gmail.com>
 <51F0F035.8010705@arm.com>
Message-ID: <20130725174416.7598.73819@quantum>

Quoting Jonathan Austin (2013-07-25 02:30:29)
> On 24/07/13 20:32, Linus Walleij wrote:
> > On Tue, Jul 23, 2013 at 5:42 PM, Jonathan Austin
> > <jonathan.austin at arm.com> wrote:
> >
> >> The order of arguments in the call to vco_set() for the ICST clocks appears to
> >> have been switched in error, which results in the VCO not being initialised
> >> correctly. This in turn stops the integrated LCD on things like Integrator/CP
> >> from working correctly.
> >>
> >> This patch fixes the order and restores the expected functionality.
> >>
> >> Cc: Linus Walleij <linus.walleij at linaro.org>
> >> Cc: Mike Turquette <mturquette at linaro.org>
> >> Signed-off-by: Jonathan Austin <jonathan.austin at arm.com>
> >
> > Good catch! Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
> > You should probably mark this for stable as well.
> >
> 
> Mike, will you add Cc: stable when you take the fix or shall I resubmit 
> the patch somehow else?

I'll add it.

Regards,
Mike


From will.deacon at arm.com  Thu Jul 25 13:45:55 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 18:45:55 +0100
Subject: [PATCH 4/6] ARM: locks: prefetch the destination word for write
 prior to strex
In-Reply-To: <51F1626C.3050008@codeaurora.org>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-5-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231609170.15022@syhkavp.arg>
 <20130724111841.GD11072@mudshark.cambridge.arm.com>
 <51F160EA.6030800@codeaurora.org> <51F1626C.3050008@codeaurora.org>
Message-ID: <20130725174555.GK12827@mudshark.cambridge.arm.com>

On Thu, Jul 25, 2013 at 06:37:48PM +0100, Stephen Boyd wrote:
> On 07/25/13 10:31, Stephen Boyd wrote:
> > On 07/24/13 04:18, Will Deacon wrote:
> >> On Tue, Jul 23, 2013 at 09:10:33PM +0100, Nicolas Pitre wrote:
> >>> On Tue, 23 Jul 2013, Will Deacon wrote:
> >>>
> >>>> The cost of changing a cacheline from shared to exclusive state can be
> >>>> significant, especially when this is triggered by an exclusive store,
> >>>> since it may result in having to retry the transaction.
> >>>>
> >>>> This patch prefixes our {spin,read,write}_[try]lock implementations with
> >>>> pldw instructions (on CPUs which support them) to try and grab the line
> >>>> in exclusive state from the start.
> >>>>
> >>>> Signed-off-by: Will Deacon <will.deacon at arm.com>
> >>>> ---
> >>>>  arch/arm/include/asm/spinlock.h | 9 ++++++++-
> >>>>  1 file changed, 8 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
> >>>> index 0de7bec..3e1cc9d 100644
> >>>> --- a/arch/arm/include/asm/spinlock.h
> >>>> +++ b/arch/arm/include/asm/spinlock.h
> >>>> @@ -5,7 +5,7 @@
> >>>>  #error SMP not supported on pre-ARMv6 CPUs
> >>>>  #endif
> >>>>  
> >>>> -#include <asm/processor.h>
> >>>> +#include <linux/prefetch.h>
> >>>>  
> >>>>  /*
> >>>>   * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
> >>>> @@ -70,6 +70,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
> >>>>  	u32 newval;
> >>>>  	arch_spinlock_t lockval;
> >>>>  
> >>>> +	prefetchw((const void *)&lock->slock);
> >>> Couldn't that cast be carried in the definition of prefetchw() instead?
> >> I think that would mean implementing prefetchw as a macro rather than an
> >> inline function, since the core code expects to pass a const pointer and GCC
> >> gets angry if the type signatures don't match.
> > Maybe I'm wrong, but can't you just remove the casts and leave the
> > function as static inline? const void * is pretty much telling the
> > compiler to turn off type checking.
> >
> 
> Oh joy. Why is rwlock's lock member marked volatile?

Yeah, that was the problematic guy. However, I had to fix that anyway in
this patch because otherwise the definition for prefetchw when
!ARCH_HAS_PREFETCHW (which expands to __builtin_prefetch(x,1)) will explode.

So, given that I've fixed the rwlocks, I think I could put prefetch and
prefetchw back to static inline functions. What do you reckon?

Will


From will.deacon at arm.com  Thu Jul 25 13:48:46 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 18:48:46 +0100
Subject: [PATCH 4/6] ARM: locks: prefetch the destination word for write
 prior to strex
In-Reply-To: <20130725174555.GK12827@mudshark.cambridge.arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-5-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231609170.15022@syhkavp.arg>
 <20130724111841.GD11072@mudshark.cambridge.arm.com>
 <51F160EA.6030800@codeaurora.org> <51F1626C.3050008@codeaurora.org>
 <20130725174555.GK12827@mudshark.cambridge.arm.com>
Message-ID: <20130725174846.GL12827@mudshark.cambridge.arm.com>

On Thu, Jul 25, 2013 at 06:45:55PM +0100, Will Deacon wrote:
> On Thu, Jul 25, 2013 at 06:37:48PM +0100, Stephen Boyd wrote:
> > Oh joy. Why is rwlock's lock member marked volatile?
> 
> Yeah, that was the problematic guy. However, I had to fix that anyway in
> this patch because otherwise the definition for prefetchw when
> !ARCH_HAS_PREFETCHW (which expands to __builtin_prefetch(x,1)) will explode.

Just realised you're still looking at v1, which doesn't have any changes to
the rwlocks. I posted v2 here:

  http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/186411.html

Enjoy.

Will


From thierry.reding at gmail.com  Thu Jul 25 13:53:14 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:14 -0700
Subject: [PATCH v5 00/16] Rewrite Tegra PCIe driver
Message-ID: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

This patch series contains an almost complete rewrite of the Tegra PCIe
driver. The code is moved to the drivers/pci/host directory and turned
into a proper platform driver, adding MSI and DT support while at it.

Patches 1 and 2 move some of the Tegra specific code around to allow it
to be used from outside the arch/arm/mach-tegra directory.

Patch 3 moves the Tegra PCIe controller driver to the drivers/pci/host
directory and turns it into a proper platform driver while adding MSI
(based on patches from NVIDIA) and DT support.

Patches 4 to 7 add Tegra20 board support for PCIe via DT.

Patch 8 adds Tegra30 PCIe support to the driver, which is fixed up by
patch 9. These haven't been squashed to keep the history since most of
this work has been done over several months.

Patch 10 adds DT support for Tegra30 and patches 11 to 13 enable PCIe
support on Tegra30-based Cardhu and Beaver boards.

Patch 14 enables PCI in the Tegra default configuration. Patch 15
increases the prefetchable memory size to accomodate more use-cases and
patch 16 finally adds me as the maintainer of the Tegra PCIe driver in
the MAINTAINERS file.

Note that this patch series depends on patches posted by Thomas
Petazzoni for Marvell PCIe support. They can be found here:

  - [PATCHv5 02/11] PCI: use weak functions for MSI arch-specific functions
    http://www.spinics.net/lists/linux-pci/msg23802.html

  - [PATCHv5 04/11] PCI: Introduce new MSI chip infrastructure
    http://www.spinics.net/lists/linux-pci/msg23797.html

  - [PATCHv5 08/11] ARM: pci: add ->add_bus() and ->remove_bus() hooks to hw_pci
    http://www.spinics.net/lists/linux-pci/msg23801.html

So it would be great if we could set up a stable branch that contains
those three, which could then be pulled into the Marvell and Tegra
branches.

For this series, patches 3, 8 and 9 will require Bjorn's Acked-by so
that Stephen can take them through the Tegra tree, which I think both of
them already agreed on to being the best solution.

Thierry

Jay Agarwal (3):
  PCI: tegra: Add Tegra 30 PCIe support
  ARM: tegra: Enable PCIe controller on Cardhu
  ARM: dts: tegra: Increase prefetchable PCI memory space

Stephen Warren (2):
  PCI: tegra: set up PADS_REFCLK_CFG1
  ARM: tegra: Fix Beaver's PCIe lane configuration

Thierry Reding (11):
  ARM: tegra: Move tegra_pcie_xclk_clamp() to PMC
  ARM: tegra: Move pmc.h to include/linux/tegra-pmc.h
  PCI: tegra: Move PCIe driver to drivers/pci/host
  ARM: tegra: tamonten: Add PCIe support
  ARM: tegra: tec: Add PCIe support
  ARM: tegra: harmony: Initialize PCIe from DT
  ARM: tegra: trimslice: Initialize PCIe from DT
  ARM: tegra: Add Tegra30 PCIe support
  ARM: tegra: Enable PCIe controller on Beaver
  ARM: tegra: Update default configuration (PCIe)
  MAINTAINERS: Add myself as Tegra PCIe maintainer

 .../bindings/pci/nvidia,tegra20-pcie.txt           |  163 ++
 MAINTAINERS                                        |    7 +
 arch/arm/boot/dts/tegra20-harmony.dts              |   20 +-
 arch/arm/boot/dts/tegra20-tamonten.dtsi            |   17 +-
 arch/arm/boot/dts/tegra20-tec.dts                  |    8 +
 arch/arm/boot/dts/tegra20-trimslice.dts            |   28 +
 arch/arm/boot/dts/tegra20.dtsi                     |   55 +
 arch/arm/boot/dts/tegra30-beaver.dts               |   21 +
 arch/arm/boot/dts/tegra30-cardhu.dtsi              |   20 +
 arch/arm/boot/dts/tegra30.dtsi                     |   70 +
 arch/arm/configs/tegra_defconfig                   |    5 +-
 arch/arm/mach-tegra/Kconfig                        |    7 +-
 arch/arm/mach-tegra/Makefile                       |    3 -
 arch/arm/mach-tegra/board-harmony-pcie.c           |   89 -
 arch/arm/mach-tegra/board.h                        |    8 -
 arch/arm/mach-tegra/iomap.h                        |    3 -
 arch/arm/mach-tegra/pcie.c                         |  886 ----------
 arch/arm/mach-tegra/pmc.c                          |   16 +
 arch/arm/mach-tegra/tegra.c                        |   24 -
 drivers/pci/host/Kconfig                           |    4 +
 drivers/pci/host/Makefile                          |    1 +
 drivers/pci/host/pci-tegra.c                       | 1702 ++++++++++++++++++++
 include/linux/tegra-pmc.h                          |   23 +
 23 files changed, 2156 insertions(+), 1024 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
 delete mode 100644 arch/arm/mach-tegra/board-harmony-pcie.c
 delete mode 100644 arch/arm/mach-tegra/pcie.c
 create mode 100644 drivers/pci/host/pci-tegra.c
 create mode 100644 include/linux/tegra-pmc.h

-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:15 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:15 -0700
Subject: [PATCH v5 01/16] ARM: tegra: Move tegra_pcie_xclk_clamp() to PMC
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-2-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <thierry.reding at avionic-design.de>

The PMC code already accesses to PMC registers so it makes sense to
move this function there as well. While at it, rename the function to
tegra_pmc_pcie_xclk_clamp() for consistency.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
Acked-by: Stephen Warren <swarren at wwwdotorg.org>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 arch/arm/mach-tegra/pcie.c | 30 ++++--------------------------
 arch/arm/mach-tegra/pmc.c  | 16 ++++++++++++++++
 arch/arm/mach-tegra/pmc.h  |  1 +
 3 files changed, 21 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-tegra/pcie.c b/arch/arm/mach-tegra/pcie.c
index 46144a1..6c1989b 100644
--- a/arch/arm/mach-tegra/pcie.c
+++ b/arch/arm/mach-tegra/pcie.c
@@ -41,6 +41,7 @@
 
 #include "board.h"
 #include "iomap.h"
+#include "pmc.h"
 
 /* Hack - need to parse this from DT */
 #define INT_PCIE_INTR 130
@@ -147,17 +148,6 @@
 #define  PADS_PLL_CTL_TXCLKREF_DIV10		(0 << 20)
 #define  PADS_PLL_CTL_TXCLKREF_DIV5		(1 << 20)
 
-/* PMC access is required for PCIE xclk (un)clamping */
-#define PMC_SCRATCH42		0x144
-#define PMC_SCRATCH42_PCX_CLAMP	(1 << 0)
-
-static void __iomem *reg_pmc_base = IO_ADDRESS(TEGRA_PMC_BASE);
-
-#define pmc_writel(value, reg) \
-	__raw_writel(value, reg_pmc_base + (reg))
-#define pmc_readl(reg) \
-	__raw_readl(reg_pmc_base + (reg))
-
 /*
  * Tegra2 defines 1GB in the AXI address map for PCIe.
  *
@@ -639,18 +629,6 @@ static int tegra_pcie_enable_controller(void)
 	return 0;
 }
 
-static void tegra_pcie_xclk_clamp(bool clamp)
-{
-	u32 reg;
-
-	reg = pmc_readl(PMC_SCRATCH42) & ~PMC_SCRATCH42_PCX_CLAMP;
-
-	if (clamp)
-		reg |= PMC_SCRATCH42_PCX_CLAMP;
-
-	pmc_writel(reg, PMC_SCRATCH42);
-}
-
 static void tegra_pcie_power_off(void)
 {
 	tegra_periph_reset_assert(tegra_pcie.pcie_xclk);
@@ -658,7 +636,7 @@ static void tegra_pcie_power_off(void)
 	tegra_periph_reset_assert(tegra_pcie.pex_clk);
 
 	tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
-	tegra_pcie_xclk_clamp(true);
+	tegra_pmc_pcie_xclk_clamp(true);
 }
 
 static int tegra_pcie_power_regate(void)
@@ -667,7 +645,7 @@ static int tegra_pcie_power_regate(void)
 
 	tegra_pcie_power_off();
 
-	tegra_pcie_xclk_clamp(true);
+	tegra_pmc_pcie_xclk_clamp(true);
 
 	tegra_periph_reset_assert(tegra_pcie.pcie_xclk);
 	tegra_periph_reset_assert(tegra_pcie.afi_clk);
@@ -681,7 +659,7 @@ static int tegra_pcie_power_regate(void)
 
 	tegra_periph_reset_deassert(tegra_pcie.afi_clk);
 
-	tegra_pcie_xclk_clamp(false);
+	tegra_pmc_pcie_xclk_clamp(false);
 
 	clk_prepare_enable(tegra_pcie.afi_clk);
 	clk_prepare_enable(tegra_pcie.pex_clk);
diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
index 8345fcd..db72297 100644
--- a/arch/arm/mach-tegra/pmc.c
+++ b/arch/arm/mach-tegra/pmc.c
@@ -75,6 +75,10 @@ struct pmc_pm_data {
 };
 static struct pmc_pm_data pmc_pm_data;
 
+/* PMC access is required for PCIE xclk (un)clamping */
+#define PMC_SCRATCH42		0x144
+#define PMC_SCRATCH42_PCX_CLAMP	(1 << 0)
+
 static inline u32 tegra_pmc_readl(u32 reg)
 {
 	return readl(tegra_pmc_base + reg);
@@ -342,3 +346,15 @@ void __init tegra_pmc_init(void)
 		val &= ~PMC_CTRL_INTR_LOW;
 	tegra_pmc_writel(val, PMC_CTRL);
 }
+
+void tegra_pmc_pcie_xclk_clamp(bool clamp)
+{
+	u32 reg;
+
+	reg = tegra_pmc_readl(PMC_SCRATCH42) & ~PMC_SCRATCH42_PCX_CLAMP;
+
+	if (clamp)
+		reg |= PMC_SCRATCH42_PCX_CLAMP;
+
+	tegra_pmc_writel(reg, PMC_SCRATCH42);
+}
diff --git a/arch/arm/mach-tegra/pmc.h b/arch/arm/mach-tegra/pmc.h
index e1c2df2..cdb08a1 100644
--- a/arch/arm/mach-tegra/pmc.h
+++ b/arch/arm/mach-tegra/pmc.h
@@ -37,5 +37,6 @@ int tegra_pmc_cpu_power_on(int cpuid);
 int tegra_pmc_cpu_remove_clamping(int cpuid);
 
 void tegra_pmc_init(void);
+void tegra_pmc_pcie_xclk_clamp(bool clamp);
 
 #endif
-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:16 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:16 -0700
Subject: [PATCH v5 02/16] ARM: tegra: Move pmc.h to include/linux/tegra-pmc.h
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-3-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <thierry.reding at avionic-design.de>

In preparation for moving the PCIe driver into the drivers/pci/host
directory, this header, which contains prototypes that are required by
the PCIe driver, needs to be moved to a globally visible location.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
Changes in v2:
- keep tegra_pmc_init() prototype in arch/arm/mach-tegra/pmc.h
- move pmc.h to includex/linux/tegra-pmc.h

Changes in v3:
- update subject to match new location

 arch/arm/mach-tegra/pmc.h |  1 -
 include/linux/tegra-pmc.h | 23 +++++++++++++++++++++++
 2 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/tegra-pmc.h

diff --git a/arch/arm/mach-tegra/pmc.h b/arch/arm/mach-tegra/pmc.h
index cdb08a1..e1c2df2 100644
--- a/arch/arm/mach-tegra/pmc.h
+++ b/arch/arm/mach-tegra/pmc.h
@@ -37,6 +37,5 @@ int tegra_pmc_cpu_power_on(int cpuid);
 int tegra_pmc_cpu_remove_clamping(int cpuid);
 
 void tegra_pmc_init(void);
-void tegra_pmc_pcie_xclk_clamp(bool clamp);
 
 #endif
diff --git a/include/linux/tegra-pmc.h b/include/linux/tegra-pmc.h
new file mode 100644
index 0000000..b6296bf
--- /dev/null
+++ b/include/linux/tegra-pmc.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2012 NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#ifndef __LINUX_TEGRA_PMC_H
+#define __LINUX_TEGRA_PMC_H
+
+void tegra_pmc_pcie_xclk_clamp(bool clamp);
+
+#endif
-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:18 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:18 -0700
Subject: [PATCH v5 04/16] ARM: tegra: tamonten: Add PCIe support
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-5-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <thierry.reding at avionic-design.de>

Add properties common to all Tamonten-derived boards to the Tamonten
DTSI and add the fixed 1.05 V regulator.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
Changes in v2:
- add properties common to all Tamonten boards
- add fixed 1.05 V regulator

 arch/arm/boot/dts/tegra20-tamonten.dtsi | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index c54faae..5ee674b 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -366,7 +366,7 @@
 					regulator-always-on;
 				};
 
-				ldo0 {
+				pci_clk_reg: ldo0 {
 					regulator-name = "vdd_ldo0,vddio_pex_clk";
 					regulator-min-microvolt = <3300000>;
 					regulator-max-microvolt = <3300000>;
@@ -467,6 +467,11 @@
 		nvidia,sys-clock-req-active-high;
 	};
 
+	pcie-controller {
+		pex-clk-supply = <&pci_clk_reg>;
+		vdd-supply = <&pci_vdd_reg>;
+	};
+
 	usb at c5008000 {
 		status = "okay";
 	};
@@ -509,5 +514,15 @@
 			regulator-max-microvolt = <5000000>;
 			regulator-always-on;
 		};
+
+		pci_vdd_reg: regulator at 1 {
+			compatible = "regulator-fixed";
+			reg = <1>;
+			regulator-name = "vdd_1v05";
+			regulator-min-microvolt = <1050000>;
+			regulator-max-microvolt = <1050000>;
+			gpio = <&pmic 2 0>;
+			enable-active-high;
+		};
 	};
 };
-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:19 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:19 -0700
Subject: [PATCH v5 05/16] ARM: tegra: tec: Add PCIe support
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-6-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <thierry.reding at avionic-design.de>

Enable the first PCIe root port which is connected to an FPGA on the
Tamonten Evaluation Carrier and add device nodes for each of the PCI
endpoints available in the standard configuration.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
Changes in v2:
- remove duplicate nodes and properties defined in tegra20-tamonten.dtsi

Changes in v3:
- remove PCIe endpoint device tree nodes, all devices can be discovered
  via standard PCI enumeration

 arch/arm/boot/dts/tegra20-tec.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20-tec.dts b/arch/arm/boot/dts/tegra20-tec.dts
index c572c43..3ada3cb 100644
--- a/arch/arm/boot/dts/tegra20-tec.dts
+++ b/arch/arm/boot/dts/tegra20-tec.dts
@@ -32,6 +32,14 @@
 		};
 	};
 
+	pcie-controller {
+		status = "okay";
+
+		pci at 1,0 {
+			status = "okay";
+		};
+	};
+
 	sound {
 		compatible = "ad,tegra-audio-wm8903-tec",
 			     "nvidia,tegra-audio-wm8903";
-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:20 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:20 -0700
Subject: [PATCH v5 06/16] ARM: tegra: harmony: Initialize PCIe from DT
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-7-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <thierry.reding at avionic-design.de>

With the device tree support in place, probe the PCIe controller from
the device tree and remove the corresponding workaround in the board
file.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 arch/arm/boot/dts/tegra20-harmony.dts | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index d9f89cd..8724dc7 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -335,7 +335,7 @@
 					regulator-always-on;
 				};
 
-				ldo0 {
+				pci_clk_reg: ldo0 {
 					regulator-name = "vdd_ldo0,vddio_pex_clk";
 					regulator-min-microvolt = <3300000>;
 					regulator-max-microvolt = <3300000>;
@@ -425,6 +425,20 @@
 		nvidia,sys-clock-req-active-high;
 	};
 
+	pcie-controller {
+		pex-clk-supply = <&pci_clk_reg>;
+		vdd-supply = <&pci_vdd_reg>;
+		status = "okay";
+
+		pci at 1,0 {
+			status = "okay";
+		};
+
+		pci at 2,0 {
+			status = "okay";
+		};
+	};
+
 	usb at c5000000 {
 		status = "okay";
 	};
@@ -643,7 +657,7 @@
 			enable-active-high;
 		};
 
-		regulator at 3 {
+		pci_vdd_reg: regulator at 3 {
 			compatible = "regulator-fixed";
 			reg = <3>;
 			regulator-name = "vdd_1v05";
@@ -651,8 +665,6 @@
 			regulator-max-microvolt = <1050000>;
 			gpio = <&pmic 2 GPIO_ACTIVE_HIGH>;
 			enable-active-high;
-			/* Hack until board-harmony-pcie.c is removed */
-			status = "disabled";
 		};
 
 		regulator at 4 {
-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:17 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:17 -0700
Subject: [PATCH v5 03/16] PCI: tegra: Move PCIe driver to drivers/pci/host
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-4-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <thierry.reding at avionic-design.de>

Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host
directory. The motivation is to collect various host controller drivers
in the same location in order to facilitate refactoring.

The Tegra PCIe driver has been largely rewritten, both in order to turn
it into a proper platform driver and to add MSI (based on code by
Krishna Kishore <kthota at nvidia.com>) as well as device tree support.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
Changes in v2:
- remove Harmony and TrimSlice leftovers
- use symbolic names for interrupt codes
- fix root port reset sequence
- depend on ARCH_TEGRA
- only enable configured root ports
- make regulators mandatory
- fix build with !PCI_MSI
- derive XBAR configuration from nvidia,num-lanes property
- remap configuration space on a per-bus basis

Changes in v3:
- move Tegra30 specific bits into a follow-up patch
- update DT binding to be more spec-conformant
- update for recent OF ranges parser changes
- use new MSI chip infrastructure

Changes in v4:
- update binding documentation as per Stephen's comments

Changes in v5:
- update for latest OF ranges parsing API
- use pci_common_init_dev() instead of pci_common_init()
- add hw_pci.add_bus implementation to attach MSI chip
- fixup any remaining checkpatch warnings
- use define for link active status bit
- move msi_chip structure to the beginning of struct tegra_msi to maybe
  save some bytes when upcasting
- refactor common code from tegra_pcie_{read,write}_conf()
- don't use potentially dangerous devm_request_irq()
- return IRQ_NONE if the MSI handler doesn't detect any pending
  interrupts
- don't read AFI_MSI_AXI_BAR_ST when setting up MSI messages (the same
  data is available in msi->pages)
- request a single page (instead of 8) for the MSI BAR
- return an error when detecting an invalid lane configuration
- remove driver's .remove() function and set .suppress_bind_attrs to
  prevent the driver from being unbound from the device via sysfs
- add MODULE_AUTHOR, MODULE_DESCRIPTION, MODULE_LICENSE
- export OF device table
- use symbolic constants for interrupts and clocks

 .../bindings/pci/nvidia,tegra20-pcie.txt           |  161 ++
 arch/arm/boot/dts/tegra20.dtsi                     |   55 +
 arch/arm/mach-tegra/Kconfig                        |    7 +-
 arch/arm/mach-tegra/Makefile                       |    3 -
 arch/arm/mach-tegra/board-harmony-pcie.c           |   89 --
 arch/arm/mach-tegra/board.h                        |    8 -
 arch/arm/mach-tegra/iomap.h                        |    3 -
 arch/arm/mach-tegra/pcie.c                         |  864 -----------
 arch/arm/mach-tegra/tegra.c                        |   24 -
 drivers/pci/host/Kconfig                           |    4 +
 drivers/pci/host/Makefile                          |    1 +
 drivers/pci/host/pci-tegra.c                       | 1540 ++++++++++++++++++++
 12 files changed, 1763 insertions(+), 996 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
 delete mode 100644 arch/arm/mach-tegra/board-harmony-pcie.c
 delete mode 100644 arch/arm/mach-tegra/pcie.c
 create mode 100644 drivers/pci/host/pci-tegra.c

diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
new file mode 100644
index 0000000..90c112f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
@@ -0,0 +1,161 @@
+NVIDIA Tegra PCIe controller
+
+Required properties:
+- compatible: "nvidia,tegra20-pcie"
+- device_type: Must be "pci"
+- reg: A list of physical base address and length for each set of controller
+  registers. Must contain an entry for each entry in the reg-names property.
+- reg-names: Must include the following entries:
+  "pads": PADS registers
+  "afi": AFI registers
+  "cs": configuration space region
+- interrupts: A list of interrupt outputs of the controller. Must contain an
+  entry for each entry in the interrupt-names property.
+- interrupt-names: Must include the following entries:
+  "intr": The Tegra interrupt that is asserted for controller interrupts
+  "msi": The Tegra interrupt that is asserted when an MSI is received
+- pex-clk-supply: Supply voltage for internal reference clock
+- vdd-supply: Power supply for controller (1.05V)
+- bus-range: Range of bus numbers associated with this controller
+- #address-cells: Address representation for root ports (must be 3)
+  - cell 0 specifies the bus and device numbers of the root port:
+    [23:16]: bus number
+    [15:11]: device number
+  - cell 1 denotes the upper 32 address bits and should be 0
+  - cell 2 contains the lower 32 address bits and is used to translate to the
+    CPU address space
+- #size-cells: Size representation for root ports (must be 2)
+- ranges: Describes the translation of addresses for root ports and standard
+  PCI regions. The entries must be 6 cells each, where the first three cells
+  correspond to the address as described for the #address-cells property
+  above, the fourth cell is the physical CPU address to translate to and the
+  fifth and six cells are as described for the #size-cells property above.
+  - The first two entries are expected to translate the addresses for the root
+    port registers, which are referenced by the assigned-addresses property of
+    the root port nodes (see below).
+  - The remaining entries setup the mapping for the standard I/O, memory and
+    prefetchable PCI regions. The first cell determines the type of region
+    that is setup:
+    - 0x81000000: I/O memory region
+    - 0x82000000: non-prefetchable memory region
+    - 0xc2000000: prefetchable memory region
+  Please refer to the standard PCI bus binding document for a more detailed
+  explanation.
+- clocks: List of clock inputs of the controller. Must contain an entry for
+  each entry in the clock-names property.
+- clock-names: Must include the following entries:
+  "pex": The Tegra clock of that name
+  "afi": The Tegra clock of that name
+  "pcie_xclk": The Tegra clock of that name
+  "pll_e": The Tegra clock of that name
+
+Root ports are defined as subnodes of the PCIe controller node.
+
+Required properties:
+- device_type: Must be "pci"
+- assigned-addresses: Address and size of the port configuration registers
+- reg: PCI bus address of the root port
+- #address-cells: Must be 3
+- #size-cells: Must be 2
+- ranges: Sub-ranges distributed from the PCIe controller node. An empty
+  property is sufficient.
+- nvidia,num-lanes: Number of lanes to use for this port. Valid combinations
+  are:
+  - Root port 0 uses 4 lanes, root port 1 is unused.
+  - Both root ports use 2 lanes.
+
+Example:
+
+SoC DTSI:
+
+	pcie-controller {
+		compatible = "nvidia,tegra20-pcie";
+		device_type = "pci";
+		reg = <0x80003000 0x00000800   /* PADS registers */
+		       0x80003800 0x00000200   /* AFI registers */
+		       0x90000000 0x10000000>; /* configuration space */
+		reg-names = "pads", "afi", "cs";
+		interrupts = <0 98 0x04   /* controller interrupt */
+		              0 99 0x04>; /* MSI interrupt */
+		interrupt-names = "intr", "msi";
+
+		bus-range = <0x00 0xff>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+
+		ranges = <0x82000000 0 0x80000000 0x80000000 0 0x00001000   /* port 0 registers */
+			  0x82000000 0 0x80001000 0x80001000 0 0x00001000   /* port 1 registers */
+			  0x81000000 0 0          0x82000000 0 0x00010000   /* downstream I/O */
+			  0x82000000 0 0xa0000000 0xa0000000 0 0x10000000   /* non-prefetchable memory */
+			  0xc2000000 0 0xb0000000 0xb0000000 0 0x10000000>; /* prefetchable memory */
+
+		clocks = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 74>,
+			 <&tegra_car 118>;
+		clock-names = "pex", "afi", "pcie_xclk", "pll_e";
+		status = "disabled";
+
+		pci at 1,0 {
+			device_type = "pci";
+			assigned-addresses = <0x82000800 0 0x80000000 0 0x1000>;
+			reg = <0x000800 0 0 0 0>;
+			status = "disabled";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			ranges;
+
+			nvidia,num-lanes = <2>;
+		};
+
+		pci at 2,0 {
+			device_type = "pci";
+			assigned-addresses = <0x82001000 0 0x80001000 0 0x1000>;
+			reg = <0x001000 0 0 0 0>;
+			status = "disabled";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			ranges;
+
+			nvidia,num-lanes = <2>;
+		};
+	};
+
+
+Board DTS:
+
+	pcie-controller {
+		status = "okay";
+
+		vdd-supply = <&pci_vdd_reg>;
+		pex-clk-supply = <&pci_clk_reg>;
+
+		/* root port 00:01.0 */
+		pci at 1,0 {
+			status = "okay";
+
+			/* bridge 01:00.0 (optional) */
+			pci at 0,0 {
+				reg = <0x010000 0 0 0 0>;
+
+				#address-cells = <3>;
+				#size-cells = <2>;
+
+				device_type = "pci";
+
+				/* endpoint 02:00.0 */
+				pci at 0,0 {
+					reg = <0x020000 0 0 0 0>;
+				};
+			};
+		};
+	};
+
+Note that devices on the PCI bus are dynamically discovered using PCI's bus
+enumeration and therefore don't need corresponding device nodes in DT. However
+if a device on the PCI bus provides a non-probeable bus such as I2C or SPI,
+device nodes need to be added in order to allow the bus' children to be
+instantiated at the proper location in the operating system's device tree (as
+illustrated by the optional nodes in the example above).
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 9653fd8..ecd016a 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -455,6 +455,61 @@
 		#size-cells = <0>;
 	};
 
+	pcie-controller {
+		compatible = "nvidia,tegra20-pcie";
+		device_type = "pci";
+		reg = <0x80003000 0x00000800   /* PADS registers */
+		       0x80003800 0x00000200   /* AFI registers */
+		       0x90000000 0x10000000>; /* configuration space */
+		reg-names = "pads", "afi", "cs";
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH   /* controller interrupt */
+			      GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */
+		interrupt-names = "intr", "msi";
+
+		bus-range = <0x00 0xff>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+
+		ranges = <0x82000000 0 0x80000000 0x80000000 0 0x00001000   /* port 0 registers */
+			  0x82000000 0 0x80001000 0x80001000 0 0x00001000   /* port 1 registers */
+			  0x81000000 0 0          0x82000000 0 0x00010000   /* downstream I/O */
+			  0x82000000 0 0xa0000000 0xa0000000 0 0x10000000   /* non-prefetchable memory */
+			  0xc2000000 0 0xb0000000 0xb0000000 0 0x10000000>; /* prefetchable memory */
+
+		clocks = <&tegra_car TEGRA20_CLK_PEX>,
+			 <&tegra_car TEGRA20_CLK_AFI>,
+			 <&tegra_car TEGRA20_CLK_PCIE_XCLK>,
+			 <&tegra_car TEGRA20_CLK_PLL_E>;
+		clock-names = "pex", "afi", "pcie_xclk", "pll_e";
+		status = "disabled";
+
+		pci at 1,0 {
+			device_type = "pci";
+			assigned-addresses = <0x82000800 0 0x80000000 0 0x1000>;
+			reg = <0x000800 0 0 0 0>;
+			status = "disabled";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+			ranges;
+
+			nvidia,num-lanes = <2>;
+		};
+
+		pci at 2,0 {
+			device_type = "pci";
+			assigned-addresses = <0x82001000 0 0x80001000 0 0x1000>;
+			reg = <0x001000 0 0 0 0>;
+			status = "disabled";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+			ranges;
+
+			nvidia,num-lanes = <2>;
+		};
+	};
+
 	usb at c5000000 {
 		compatible = "nvidia,tegra20-ehci", "usb-ehci";
 		reg = <0xc5000000 0x4000>;
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 80d3b82..f3ba4c6 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -15,6 +15,8 @@ config ARCH_TEGRA
 	select SOC_BUS
 	select SPARSE_IRQ
 	select USE_OF
+	select MIGHT_HAVE_PCI
+	select ARCH_SUPPORTS_MSI
 	help
 	  This enables support for NVIDIA Tegra based systems.
 
@@ -69,11 +71,6 @@ config ARCH_TEGRA_114_SOC
 	  Support for NVIDIA Tegra T114 processor family, based on the
 	  ARM CortexA15MP CPU
 
-config TEGRA_PCI
-	bool "PCI Express support"
-	depends on ARCH_TEGRA_2x_SOC
-	select PCI
-
 config TEGRA_AHB
 	bool "Enable AHB driver for NVIDIA Tegra SoCs"
 	default y
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 98b184e..01a0e6f 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -27,7 +27,6 @@ obj-$(CONFIG_ARCH_TEGRA_3x_SOC)		+= cpuidle-tegra30.o
 endif
 obj-$(CONFIG_SMP)			+= platsmp.o headsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)               += hotplug.o
-obj-$(CONFIG_TEGRA_PCI)			+= pcie.o
 
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)	+= tegra114_speedo.o
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)	+= sleep-tegra30.o
@@ -35,6 +34,4 @@ ifeq ($(CONFIG_CPU_IDLE),y)
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)	+= cpuidle-tegra114.o
 endif
 
-obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= board-harmony-pcie.o
-
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= board-paz00.o
diff --git a/arch/arm/mach-tegra/board-harmony-pcie.c b/arch/arm/mach-tegra/board-harmony-pcie.c
deleted file mode 100644
index 035b240..0000000
--- a/arch/arm/mach-tegra/board-harmony-pcie.c
+++ /dev/null
@@ -1,89 +0,0 @@
-/*
- * arch/arm/mach-tegra/board-harmony-pcie.c
- *
- * Copyright (C) 2010 CompuLab, Ltd.
- * Mike Rapoport <mike at compulab.co.il>
- *
- * 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.
- *
- */
-
-#include <linux/kernel.h>
-#include <linux/gpio.h>
-#include <linux/err.h>
-#include <linux/of_gpio.h>
-#include <linux/regulator/consumer.h>
-
-#include <asm/mach-types.h>
-
-#include "board.h"
-
-#ifdef CONFIG_TEGRA_PCI
-
-int __init harmony_pcie_init(void)
-{
-	struct device_node *np;
-	int en_vdd_1v05;
-	struct regulator *regulator = NULL;
-	int err;
-
-	np = of_find_node_by_path("/regulators/regulator at 3");
-	if (!np) {
-		pr_err("%s: of_find_node_by_path failed\n", __func__);
-		return -ENODEV;
-	}
-
-	en_vdd_1v05 = of_get_named_gpio(np, "gpio", 0);
-	if (en_vdd_1v05 < 0) {
-		pr_err("%s: of_get_named_gpio failed: %d\n", __func__,
-		       en_vdd_1v05);
-		return en_vdd_1v05;
-	}
-
-	err = gpio_request(en_vdd_1v05, "EN_VDD_1V05");
-	if (err) {
-		pr_err("%s: gpio_request failed: %d\n", __func__, err);
-		return err;
-	}
-
-	gpio_direction_output(en_vdd_1v05, 1);
-
-	regulator = regulator_get(NULL, "vdd_ldo0,vddio_pex_clk");
-	if (IS_ERR(regulator)) {
-		err = PTR_ERR(regulator);
-		pr_err("%s: regulator_get failed: %d\n", __func__, err);
-		goto err_reg;
-	}
-
-	err = regulator_enable(regulator);
-	if (err) {
-		pr_err("%s: regulator_enable failed: %d\n", __func__, err);
-		goto err_en;
-	}
-
-	err = tegra_pcie_init(true, true);
-	if (err) {
-		pr_err("%s: tegra_pcie_init failed: %d\n", __func__, err);
-		goto err_pcie;
-	}
-
-	return 0;
-
-err_pcie:
-	regulator_disable(regulator);
-err_en:
-	regulator_put(regulator);
-err_reg:
-	gpio_free(en_vdd_1v05);
-
-	return err;
-}
-
-#endif
diff --git a/arch/arm/mach-tegra/board.h b/arch/arm/mach-tegra/board.h
index 9a6659f..db6810d 100644
--- a/arch/arm/mach-tegra/board.h
+++ b/arch/arm/mach-tegra/board.h
@@ -31,7 +31,6 @@ void __init tegra_init_early(void);
 void __init tegra_map_common_io(void);
 void __init tegra_init_irq(void);
 void __init tegra_dt_init_irq(void);
-int __init tegra_pcie_init(bool init_port0, bool init_port1);
 
 void tegra_init_late(void);
 
@@ -48,13 +47,6 @@ int __init tegra_powergate_debugfs_init(void);
 static inline int tegra_powergate_debugfs_init(void) { return 0; }
 #endif
 
-int __init harmony_regulator_init(void);
-#ifdef CONFIG_TEGRA_PCI
-int __init harmony_pcie_init(void);
-#else
-static inline int harmony_pcie_init(void) { return 0; }
-#endif
-
 void __init tegra_paz00_wifikill_init(void);
 
 #endif
diff --git a/arch/arm/mach-tegra/iomap.h b/arch/arm/mach-tegra/iomap.h
index 399fbca..d228421 100644
--- a/arch/arm/mach-tegra/iomap.h
+++ b/arch/arm/mach-tegra/iomap.h
@@ -278,9 +278,6 @@
 #define IO_APB_VIRT	IOMEM(0xFE300000)
 #define IO_APB_SIZE	SZ_1M
 
-#define TEGRA_PCIE_BASE		0x80000000
-#define TEGRA_PCIE_IO_BASE	(TEGRA_PCIE_BASE + SZ_4M)
-
 #define IO_TO_VIRT_BETWEEN(p, st, sz)	((p) >= (st) && (p) < ((st) + (sz)))
 #define IO_TO_VIRT_XLATE(p, pst, vst)	(((p) - (pst) + (vst)))
 
diff --git a/arch/arm/mach-tegra/pcie.c b/arch/arm/mach-tegra/pcie.c
deleted file mode 100644
index 6c1989b..0000000
--- a/arch/arm/mach-tegra/pcie.c
+++ /dev/null
@@ -1,864 +0,0 @@
-/*
- * arch/arm/mach-tegra/pci.c
- *
- * PCIe host controller driver for TEGRA(2) SOCs
- *
- * Copyright (c) 2010, CompuLab, Ltd.
- * Author: Mike Rapoport <mike at compulab.co.il>
- *
- * Based on NVIDIA PCIe driver
- * Copyright (c) 2008-2009, NVIDIA Corporation.
- *
- * Bits taken from arch/arm/mach-dove/pcie.c
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This 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.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
- */
-
-#include <linux/kernel.h>
-#include <linux/pci.h>
-#include <linux/interrupt.h>
-#include <linux/irq.h>
-#include <linux/clk.h>
-#include <linux/delay.h>
-#include <linux/export.h>
-#include <linux/clk/tegra.h>
-#include <linux/tegra-powergate.h>
-
-#include <asm/sizes.h>
-#include <asm/mach/pci.h>
-
-#include "board.h"
-#include "iomap.h"
-#include "pmc.h"
-
-/* Hack - need to parse this from DT */
-#define INT_PCIE_INTR 130
-
-/* register definitions */
-#define AFI_OFFSET	0x3800
-#define PADS_OFFSET	0x3000
-#define RP0_OFFSET	0x0000
-#define RP1_OFFSET	0x1000
-
-#define AFI_AXI_BAR0_SZ	0x00
-#define AFI_AXI_BAR1_SZ	0x04
-#define AFI_AXI_BAR2_SZ	0x08
-#define AFI_AXI_BAR3_SZ	0x0c
-#define AFI_AXI_BAR4_SZ	0x10
-#define AFI_AXI_BAR5_SZ	0x14
-
-#define AFI_AXI_BAR0_START	0x18
-#define AFI_AXI_BAR1_START	0x1c
-#define AFI_AXI_BAR2_START	0x20
-#define AFI_AXI_BAR3_START	0x24
-#define AFI_AXI_BAR4_START	0x28
-#define AFI_AXI_BAR5_START	0x2c
-
-#define AFI_FPCI_BAR0	0x30
-#define AFI_FPCI_BAR1	0x34
-#define AFI_FPCI_BAR2	0x38
-#define AFI_FPCI_BAR3	0x3c
-#define AFI_FPCI_BAR4	0x40
-#define AFI_FPCI_BAR5	0x44
-
-#define AFI_CACHE_BAR0_SZ	0x48
-#define AFI_CACHE_BAR0_ST	0x4c
-#define AFI_CACHE_BAR1_SZ	0x50
-#define AFI_CACHE_BAR1_ST	0x54
-
-#define AFI_MSI_BAR_SZ		0x60
-#define AFI_MSI_FPCI_BAR_ST	0x64
-#define AFI_MSI_AXI_BAR_ST	0x68
-
-#define AFI_CONFIGURATION		0xac
-#define  AFI_CONFIGURATION_EN_FPCI	(1 << 0)
-
-#define AFI_FPCI_ERROR_MASKS	0xb0
-
-#define AFI_INTR_MASK		0xb4
-#define  AFI_INTR_MASK_INT_MASK	(1 << 0)
-#define  AFI_INTR_MASK_MSI_MASK	(1 << 8)
-
-#define AFI_INTR_CODE		0xb8
-#define  AFI_INTR_CODE_MASK	0xf
-#define  AFI_INTR_MASTER_ABORT	4
-#define  AFI_INTR_LEGACY	6
-
-#define AFI_INTR_SIGNATURE	0xbc
-#define AFI_SM_INTR_ENABLE	0xc4
-
-#define AFI_AFI_INTR_ENABLE		0xc8
-#define  AFI_INTR_EN_INI_SLVERR		(1 << 0)
-#define  AFI_INTR_EN_INI_DECERR		(1 << 1)
-#define  AFI_INTR_EN_TGT_SLVERR		(1 << 2)
-#define  AFI_INTR_EN_TGT_DECERR		(1 << 3)
-#define  AFI_INTR_EN_TGT_WRERR		(1 << 4)
-#define  AFI_INTR_EN_DFPCI_DECERR	(1 << 5)
-#define  AFI_INTR_EN_AXI_DECERR		(1 << 6)
-#define  AFI_INTR_EN_FPCI_TIMEOUT	(1 << 7)
-
-#define AFI_PCIE_CONFIG					0x0f8
-#define  AFI_PCIE_CONFIG_PCIEC0_DISABLE_DEVICE		(1 << 1)
-#define  AFI_PCIE_CONFIG_PCIEC1_DISABLE_DEVICE		(1 << 2)
-#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK	(0xf << 20)
-#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE	(0x0 << 20)
-#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL	(0x1 << 20)
-
-#define AFI_FUSE			0x104
-#define  AFI_FUSE_PCIE_T0_GEN2_DIS	(1 << 2)
-
-#define AFI_PEX0_CTRL			0x110
-#define AFI_PEX1_CTRL			0x118
-#define  AFI_PEX_CTRL_RST		(1 << 0)
-#define  AFI_PEX_CTRL_REFCLK_EN		(1 << 3)
-
-#define RP_VEND_XP	0x00000F00
-#define  RP_VEND_XP_DL_UP	(1 << 30)
-
-#define RP_LINK_CONTROL_STATUS			0x00000090
-#define  RP_LINK_CONTROL_STATUS_LINKSTAT_MASK	0x3fff0000
-
-#define PADS_CTL_SEL		0x0000009C
-
-#define PADS_CTL		0x000000A0
-#define  PADS_CTL_IDDQ_1L	(1 << 0)
-#define  PADS_CTL_TX_DATA_EN_1L	(1 << 6)
-#define  PADS_CTL_RX_DATA_EN_1L	(1 << 10)
-
-#define PADS_PLL_CTL				0x000000B8
-#define  PADS_PLL_CTL_RST_B4SM			(1 << 1)
-#define  PADS_PLL_CTL_LOCKDET			(1 << 8)
-#define  PADS_PLL_CTL_REFCLK_MASK		(0x3 << 16)
-#define  PADS_PLL_CTL_REFCLK_INTERNAL_CML	(0 << 16)
-#define  PADS_PLL_CTL_REFCLK_INTERNAL_CMOS	(1 << 16)
-#define  PADS_PLL_CTL_REFCLK_EXTERNAL		(2 << 16)
-#define  PADS_PLL_CTL_TXCLKREF_MASK		(0x1 << 20)
-#define  PADS_PLL_CTL_TXCLKREF_DIV10		(0 << 20)
-#define  PADS_PLL_CTL_TXCLKREF_DIV5		(1 << 20)
-
-/*
- * Tegra2 defines 1GB in the AXI address map for PCIe.
- *
- * That address space is split into different regions, with sizes and
- * offsets as follows:
- *
- * 0x80000000 - 0x80003fff - PCI controller registers
- * 0x80004000 - 0x80103fff - PCI configuration space
- * 0x80104000 - 0x80203fff - PCI extended configuration space
- * 0x80203fff - 0x803fffff - unused
- * 0x80400000 - 0x8040ffff - downstream IO
- * 0x80410000 - 0x8fffffff - unused
- * 0x90000000 - 0x9fffffff - non-prefetchable memory
- * 0xa0000000 - 0xbfffffff - prefetchable memory
- */
-#define PCIE_REGS_SZ		SZ_16K
-#define PCIE_CFG_OFF		PCIE_REGS_SZ
-#define PCIE_CFG_SZ		SZ_1M
-#define PCIE_EXT_CFG_OFF	(PCIE_CFG_SZ + PCIE_CFG_OFF)
-#define PCIE_EXT_CFG_SZ		SZ_1M
-#define PCIE_IOMAP_SZ		(PCIE_REGS_SZ + PCIE_CFG_SZ + PCIE_EXT_CFG_SZ)
-
-#define MEM_BASE_0		(TEGRA_PCIE_BASE + SZ_256M)
-#define MEM_SIZE_0		SZ_128M
-#define MEM_BASE_1		(MEM_BASE_0 + MEM_SIZE_0)
-#define MEM_SIZE_1		SZ_128M
-#define PREFETCH_MEM_BASE_0	(MEM_BASE_1 + MEM_SIZE_1)
-#define PREFETCH_MEM_SIZE_0	SZ_128M
-#define PREFETCH_MEM_BASE_1	(PREFETCH_MEM_BASE_0 + PREFETCH_MEM_SIZE_0)
-#define PREFETCH_MEM_SIZE_1	SZ_128M
-
-#define  PCIE_CONF_BUS(b)	((b) << 16)
-#define  PCIE_CONF_DEV(d)	((d) << 11)
-#define  PCIE_CONF_FUNC(f)	((f) << 8)
-#define  PCIE_CONF_REG(r)	\
-	(((r) & ~0x3) | (((r) < 256) ? PCIE_CFG_OFF : PCIE_EXT_CFG_OFF))
-
-struct tegra_pcie_port {
-	int			index;
-	u8			root_bus_nr;
-	void __iomem		*base;
-
-	bool			link_up;
-
-	char			mem_space_name[16];
-	char			prefetch_space_name[20];
-	struct resource		res[2];
-};
-
-struct tegra_pcie_info {
-	struct tegra_pcie_port	port[2];
-	int			num_ports;
-
-	void __iomem		*regs;
-	struct resource		res_mmio;
-
-	struct clk		*pex_clk;
-	struct clk		*afi_clk;
-	struct clk		*pcie_xclk;
-	struct clk		*pll_e;
-};
-
-static struct tegra_pcie_info tegra_pcie;
-
-static inline void afi_writel(u32 value, unsigned long offset)
-{
-	writel(value, offset + AFI_OFFSET + tegra_pcie.regs);
-}
-
-static inline u32 afi_readl(unsigned long offset)
-{
-	return readl(offset + AFI_OFFSET + tegra_pcie.regs);
-}
-
-static inline void pads_writel(u32 value, unsigned long offset)
-{
-	writel(value, offset + PADS_OFFSET + tegra_pcie.regs);
-}
-
-static inline u32 pads_readl(unsigned long offset)
-{
-	return readl(offset + PADS_OFFSET + tegra_pcie.regs);
-}
-
-static struct tegra_pcie_port *bus_to_port(int bus)
-{
-	int i;
-
-	for (i = tegra_pcie.num_ports - 1; i >= 0; i--) {
-		int rbus = tegra_pcie.port[i].root_bus_nr;
-		if (rbus != -1 && rbus == bus)
-			break;
-	}
-
-	return i >= 0 ? tegra_pcie.port + i : NULL;
-}
-
-static int tegra_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
-				int where, int size, u32 *val)
-{
-	struct tegra_pcie_port *pp = bus_to_port(bus->number);
-	void __iomem *addr;
-
-	if (pp) {
-		if (devfn != 0) {
-			*val = 0xffffffff;
-			return PCIBIOS_DEVICE_NOT_FOUND;
-		}
-
-		addr = pp->base + (where & ~0x3);
-	} else {
-		addr = tegra_pcie.regs + (PCIE_CONF_BUS(bus->number) +
-					  PCIE_CONF_DEV(PCI_SLOT(devfn)) +
-					  PCIE_CONF_FUNC(PCI_FUNC(devfn)) +
-					  PCIE_CONF_REG(where));
-	}
-
-	*val = readl(addr);
-
-	if (size == 1)
-		*val = (*val >> (8 * (where & 3))) & 0xff;
-	else if (size == 2)
-		*val = (*val >> (8 * (where & 3))) & 0xffff;
-
-	return PCIBIOS_SUCCESSFUL;
-}
-
-static int tegra_pcie_write_conf(struct pci_bus *bus, unsigned int devfn,
-				 int where, int size, u32 val)
-{
-	struct tegra_pcie_port *pp = bus_to_port(bus->number);
-	void __iomem *addr;
-
-	u32 mask;
-	u32 tmp;
-
-	if (pp) {
-		if (devfn != 0)
-			return PCIBIOS_DEVICE_NOT_FOUND;
-
-		addr = pp->base + (where & ~0x3);
-	} else {
-		addr = tegra_pcie.regs + (PCIE_CONF_BUS(bus->number) +
-					  PCIE_CONF_DEV(PCI_SLOT(devfn)) +
-					  PCIE_CONF_FUNC(PCI_FUNC(devfn)) +
-					  PCIE_CONF_REG(where));
-	}
-
-	if (size == 4) {
-		writel(val, addr);
-		return PCIBIOS_SUCCESSFUL;
-	}
-
-	if (size == 2)
-		mask = ~(0xffff << ((where & 0x3) * 8));
-	else if (size == 1)
-		mask = ~(0xff << ((where & 0x3) * 8));
-	else
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	tmp = readl(addr) & mask;
-	tmp |= val << ((where & 0x3) * 8);
-	writel(tmp, addr);
-
-	return PCIBIOS_SUCCESSFUL;
-}
-
-static struct pci_ops tegra_pcie_ops = {
-	.read	= tegra_pcie_read_conf,
-	.write	= tegra_pcie_write_conf,
-};
-
-static void tegra_pcie_fixup_bridge(struct pci_dev *dev)
-{
-	u16 reg;
-
-	if ((dev->class >> 16) == PCI_BASE_CLASS_BRIDGE) {
-		pci_read_config_word(dev, PCI_COMMAND, &reg);
-		reg |= (PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
-			PCI_COMMAND_MASTER | PCI_COMMAND_SERR);
-		pci_write_config_word(dev, PCI_COMMAND, reg);
-	}
-}
-DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, tegra_pcie_fixup_bridge);
-
-/* Tegra PCIE root complex wrongly reports device class */
-static void tegra_pcie_fixup_class(struct pci_dev *dev)
-{
-	dev->class = PCI_CLASS_BRIDGE_PCI << 8;
-}
-DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf0, tegra_pcie_fixup_class);
-DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf1, tegra_pcie_fixup_class);
-
-/* Tegra PCIE requires relaxed ordering */
-static void tegra_pcie_relax_enable(struct pci_dev *dev)
-{
-	pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN);
-}
-DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, tegra_pcie_relax_enable);
-
-static int tegra_pcie_setup(int nr, struct pci_sys_data *sys)
-{
-	struct tegra_pcie_port *pp;
-
-	if (nr >= tegra_pcie.num_ports)
-		return 0;
-
-	pp = tegra_pcie.port + nr;
-	pp->root_bus_nr = sys->busnr;
-
-	pci_ioremap_io(nr * SZ_64K, TEGRA_PCIE_IO_BASE);
-
-	/*
-	 * IORESOURCE_MEM
-	 */
-	snprintf(pp->mem_space_name, sizeof(pp->mem_space_name),
-		 "PCIe %d MEM", pp->index);
-	pp->mem_space_name[sizeof(pp->mem_space_name) - 1] = 0;
-	pp->res[0].name = pp->mem_space_name;
-	if (pp->index == 0) {
-		pp->res[0].start = MEM_BASE_0;
-		pp->res[0].end = pp->res[0].start + MEM_SIZE_0 - 1;
-	} else {
-		pp->res[0].start = MEM_BASE_1;
-		pp->res[0].end = pp->res[0].start + MEM_SIZE_1 - 1;
-	}
-	pp->res[0].flags = IORESOURCE_MEM;
-	if (request_resource(&iomem_resource, &pp->res[0]))
-		panic("Request PCIe Memory resource failed\n");
-	pci_add_resource_offset(&sys->resources, &pp->res[0], sys->mem_offset);
-
-	/*
-	 * IORESOURCE_MEM | IORESOURCE_PREFETCH
-	 */
-	snprintf(pp->prefetch_space_name, sizeof(pp->prefetch_space_name),
-		 "PCIe %d PREFETCH MEM", pp->index);
-	pp->prefetch_space_name[sizeof(pp->prefetch_space_name) - 1] = 0;
-	pp->res[1].name = pp->prefetch_space_name;
-	if (pp->index == 0) {
-		pp->res[1].start = PREFETCH_MEM_BASE_0;
-		pp->res[1].end = pp->res[1].start + PREFETCH_MEM_SIZE_0 - 1;
-	} else {
-		pp->res[1].start = PREFETCH_MEM_BASE_1;
-		pp->res[1].end = pp->res[1].start + PREFETCH_MEM_SIZE_1 - 1;
-	}
-	pp->res[1].flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
-	if (request_resource(&iomem_resource, &pp->res[1]))
-		panic("Request PCIe Prefetch Memory resource failed\n");
-	pci_add_resource_offset(&sys->resources, &pp->res[1], sys->mem_offset);
-
-	return 1;
-}
-
-static int tegra_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
-{
-	return INT_PCIE_INTR;
-}
-
-static struct pci_bus __init *tegra_pcie_scan_bus(int nr,
-						  struct pci_sys_data *sys)
-{
-	struct tegra_pcie_port *pp;
-
-	if (nr >= tegra_pcie.num_ports)
-		return NULL;
-
-	pp = tegra_pcie.port + nr;
-	pp->root_bus_nr = sys->busnr;
-
-	return pci_scan_root_bus(NULL, sys->busnr, &tegra_pcie_ops, sys,
-				 &sys->resources);
-}
-
-static struct hw_pci tegra_pcie_hw __initdata = {
-	.nr_controllers	= 2,
-	.setup		= tegra_pcie_setup,
-	.scan		= tegra_pcie_scan_bus,
-	.map_irq	= tegra_pcie_map_irq,
-};
-
-
-static irqreturn_t tegra_pcie_isr(int irq, void *arg)
-{
-	const char *err_msg[] = {
-		"Unknown",
-		"AXI slave error",
-		"AXI decode error",
-		"Target abort",
-		"Master abort",
-		"Invalid write",
-		"Response decoding error",
-		"AXI response decoding error",
-		"Transcation timeout",
-	};
-
-	u32 code, signature;
-
-	code = afi_readl(AFI_INTR_CODE) & AFI_INTR_CODE_MASK;
-	signature = afi_readl(AFI_INTR_SIGNATURE);
-	afi_writel(0, AFI_INTR_CODE);
-
-	if (code == AFI_INTR_LEGACY)
-		return IRQ_NONE;
-
-	if (code >= ARRAY_SIZE(err_msg))
-		code = 0;
-
-	/*
-	 * do not pollute kernel log with master abort reports since they
-	 * happen a lot during enumeration
-	 */
-	if (code == AFI_INTR_MASTER_ABORT)
-		pr_debug("PCIE: %s, signature: %08x\n", err_msg[code], signature);
-	else
-		pr_err("PCIE: %s, signature: %08x\n", err_msg[code], signature);
-
-	return IRQ_HANDLED;
-}
-
-static void tegra_pcie_setup_translations(void)
-{
-	u32 fpci_bar;
-	u32 size;
-	u32 axi_address;
-
-	/* Bar 0: config Bar */
-	fpci_bar = ((u32)0xfdff << 16);
-	size = PCIE_CFG_SZ;
-	axi_address = TEGRA_PCIE_BASE + PCIE_CFG_OFF;
-	afi_writel(axi_address, AFI_AXI_BAR0_START);
-	afi_writel(size >> 12, AFI_AXI_BAR0_SZ);
-	afi_writel(fpci_bar, AFI_FPCI_BAR0);
-
-	/* Bar 1: extended config Bar */
-	fpci_bar = ((u32)0xfe1 << 20);
-	size = PCIE_EXT_CFG_SZ;
-	axi_address = TEGRA_PCIE_BASE + PCIE_EXT_CFG_OFF;
-	afi_writel(axi_address, AFI_AXI_BAR1_START);
-	afi_writel(size >> 12, AFI_AXI_BAR1_SZ);
-	afi_writel(fpci_bar, AFI_FPCI_BAR1);
-
-	/* Bar 2: downstream IO bar */
-	fpci_bar = ((__u32)0xfdfc << 16);
-	size = SZ_128K;
-	axi_address = TEGRA_PCIE_IO_BASE;
-	afi_writel(axi_address, AFI_AXI_BAR2_START);
-	afi_writel(size >> 12, AFI_AXI_BAR2_SZ);
-	afi_writel(fpci_bar, AFI_FPCI_BAR2);
-
-	/* Bar 3: prefetchable memory BAR */
-	fpci_bar = (((PREFETCH_MEM_BASE_0 >> 12) & 0x0fffffff) << 4) | 0x1;
-	size =  PREFETCH_MEM_SIZE_0 +  PREFETCH_MEM_SIZE_1;
-	axi_address = PREFETCH_MEM_BASE_0;
-	afi_writel(axi_address, AFI_AXI_BAR3_START);
-	afi_writel(size >> 12, AFI_AXI_BAR3_SZ);
-	afi_writel(fpci_bar, AFI_FPCI_BAR3);
-
-	/* Bar 4: non prefetchable memory BAR */
-	fpci_bar = (((MEM_BASE_0 >> 12)	& 0x0FFFFFFF) << 4) | 0x1;
-	size = MEM_SIZE_0 + MEM_SIZE_1;
-	axi_address = MEM_BASE_0;
-	afi_writel(axi_address, AFI_AXI_BAR4_START);
-	afi_writel(size >> 12, AFI_AXI_BAR4_SZ);
-	afi_writel(fpci_bar, AFI_FPCI_BAR4);
-
-	/* Bar 5: NULL out the remaining BAR as it is not used */
-	fpci_bar = 0;
-	size = 0;
-	axi_address = 0;
-	afi_writel(axi_address, AFI_AXI_BAR5_START);
-	afi_writel(size >> 12, AFI_AXI_BAR5_SZ);
-	afi_writel(fpci_bar, AFI_FPCI_BAR5);
-
-	/* map all upstream transactions as uncached */
-	afi_writel(PHYS_OFFSET, AFI_CACHE_BAR0_ST);
-	afi_writel(0, AFI_CACHE_BAR0_SZ);
-	afi_writel(0, AFI_CACHE_BAR1_ST);
-	afi_writel(0, AFI_CACHE_BAR1_SZ);
-
-	/* No MSI */
-	afi_writel(0, AFI_MSI_FPCI_BAR_ST);
-	afi_writel(0, AFI_MSI_BAR_SZ);
-	afi_writel(0, AFI_MSI_AXI_BAR_ST);
-	afi_writel(0, AFI_MSI_BAR_SZ);
-}
-
-static int tegra_pcie_enable_controller(void)
-{
-	u32 val, reg;
-	int i, timeout;
-
-	/* Enable slot clock and pulse the reset signals */
-	for (i = 0, reg = AFI_PEX0_CTRL; i < 2; i++, reg += 0x8) {
-		val = afi_readl(reg) |  AFI_PEX_CTRL_REFCLK_EN;
-		afi_writel(val, reg);
-		val &= ~AFI_PEX_CTRL_RST;
-		afi_writel(val, reg);
-
-		val = afi_readl(reg) | AFI_PEX_CTRL_RST;
-		afi_writel(val, reg);
-	}
-
-	/* Enable dual controller and both ports */
-	val = afi_readl(AFI_PCIE_CONFIG);
-	val &= ~(AFI_PCIE_CONFIG_PCIEC0_DISABLE_DEVICE |
-		 AFI_PCIE_CONFIG_PCIEC1_DISABLE_DEVICE |
-		 AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK);
-	val |= AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL;
-	afi_writel(val, AFI_PCIE_CONFIG);
-
-	val = afi_readl(AFI_FUSE) & ~AFI_FUSE_PCIE_T0_GEN2_DIS;
-	afi_writel(val, AFI_FUSE);
-
-	/* Initialze internal PHY, enable up to 16 PCIE lanes */
-	pads_writel(0x0, PADS_CTL_SEL);
-
-	/* override IDDQ to 1 on all 4 lanes */
-	val = pads_readl(PADS_CTL) | PADS_CTL_IDDQ_1L;
-	pads_writel(val, PADS_CTL);
-
-	/*
-	 * set up PHY PLL inputs select PLLE output as refclock,
-	 * set TX ref sel to div10 (not div5)
-	 */
-	val = pads_readl(PADS_PLL_CTL);
-	val &= ~(PADS_PLL_CTL_REFCLK_MASK | PADS_PLL_CTL_TXCLKREF_MASK);
-	val |= (PADS_PLL_CTL_REFCLK_INTERNAL_CML | PADS_PLL_CTL_TXCLKREF_DIV10);
-	pads_writel(val, PADS_PLL_CTL);
-
-	/* take PLL out of reset  */
-	val = pads_readl(PADS_PLL_CTL) | PADS_PLL_CTL_RST_B4SM;
-	pads_writel(val, PADS_PLL_CTL);
-
-	/*
-	 * Hack, set the clock voltage to the DEFAULT provided by hw folks.
-	 * This doesn't exist in the documentation
-	 */
-	pads_writel(0xfa5cfa5c, 0xc8);
-
-	/* Wait for the PLL to lock */
-	timeout = 300;
-	do {
-		val = pads_readl(PADS_PLL_CTL);
-		usleep_range(1000, 1000);
-		if (--timeout == 0) {
-			pr_err("Tegra PCIe error: timeout waiting for PLL\n");
-			return -EBUSY;
-		}
-	} while (!(val & PADS_PLL_CTL_LOCKDET));
-
-	/* turn off IDDQ override */
-	val = pads_readl(PADS_CTL) & ~PADS_CTL_IDDQ_1L;
-	pads_writel(val, PADS_CTL);
-
-	/* enable TX/RX data */
-	val = pads_readl(PADS_CTL);
-	val |= (PADS_CTL_TX_DATA_EN_1L | PADS_CTL_RX_DATA_EN_1L);
-	pads_writel(val, PADS_CTL);
-
-	/* Take the PCIe interface module out of reset */
-	tegra_periph_reset_deassert(tegra_pcie.pcie_xclk);
-
-	/* Finally enable PCIe */
-	val = afi_readl(AFI_CONFIGURATION) | AFI_CONFIGURATION_EN_FPCI;
-	afi_writel(val, AFI_CONFIGURATION);
-
-	val = (AFI_INTR_EN_INI_SLVERR | AFI_INTR_EN_INI_DECERR |
-	       AFI_INTR_EN_TGT_SLVERR | AFI_INTR_EN_TGT_DECERR |
-	       AFI_INTR_EN_TGT_WRERR | AFI_INTR_EN_DFPCI_DECERR);
-	afi_writel(val, AFI_AFI_INTR_ENABLE);
-	afi_writel(0xffffffff, AFI_SM_INTR_ENABLE);
-
-	/* FIXME: No MSI for now, only INT */
-	afi_writel(AFI_INTR_MASK_INT_MASK, AFI_INTR_MASK);
-
-	/* Disable all execptions */
-	afi_writel(0, AFI_FPCI_ERROR_MASKS);
-
-	return 0;
-}
-
-static void tegra_pcie_power_off(void)
-{
-	tegra_periph_reset_assert(tegra_pcie.pcie_xclk);
-	tegra_periph_reset_assert(tegra_pcie.afi_clk);
-	tegra_periph_reset_assert(tegra_pcie.pex_clk);
-
-	tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
-	tegra_pmc_pcie_xclk_clamp(true);
-}
-
-static int tegra_pcie_power_regate(void)
-{
-	int err;
-
-	tegra_pcie_power_off();
-
-	tegra_pmc_pcie_xclk_clamp(true);
-
-	tegra_periph_reset_assert(tegra_pcie.pcie_xclk);
-	tegra_periph_reset_assert(tegra_pcie.afi_clk);
-
-	err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_PCIE,
-						tegra_pcie.pex_clk);
-	if (err) {
-		pr_err("PCIE: powerup sequence failed: %d\n", err);
-		return err;
-	}
-
-	tegra_periph_reset_deassert(tegra_pcie.afi_clk);
-
-	tegra_pmc_pcie_xclk_clamp(false);
-
-	clk_prepare_enable(tegra_pcie.afi_clk);
-	clk_prepare_enable(tegra_pcie.pex_clk);
-	return clk_prepare_enable(tegra_pcie.pll_e);
-}
-
-static int tegra_pcie_clocks_get(void)
-{
-	int err;
-
-	tegra_pcie.pex_clk = clk_get(NULL, "pex");
-	if (IS_ERR(tegra_pcie.pex_clk))
-		return PTR_ERR(tegra_pcie.pex_clk);
-
-	tegra_pcie.afi_clk = clk_get(NULL, "afi");
-	if (IS_ERR(tegra_pcie.afi_clk)) {
-		err = PTR_ERR(tegra_pcie.afi_clk);
-		goto err_afi_clk;
-	}
-
-	tegra_pcie.pcie_xclk = clk_get(NULL, "pcie_xclk");
-	if (IS_ERR(tegra_pcie.pcie_xclk)) {
-		err =  PTR_ERR(tegra_pcie.pcie_xclk);
-		goto err_pcie_xclk;
-	}
-
-	tegra_pcie.pll_e = clk_get_sys(NULL, "pll_e");
-	if (IS_ERR(tegra_pcie.pll_e)) {
-		err = PTR_ERR(tegra_pcie.pll_e);
-		goto err_pll_e;
-	}
-
-	return 0;
-
-err_pll_e:
-	clk_put(tegra_pcie.pcie_xclk);
-err_pcie_xclk:
-	clk_put(tegra_pcie.afi_clk);
-err_afi_clk:
-	clk_put(tegra_pcie.pex_clk);
-
-	return err;
-}
-
-static void tegra_pcie_clocks_put(void)
-{
-	clk_put(tegra_pcie.pll_e);
-	clk_put(tegra_pcie.pcie_xclk);
-	clk_put(tegra_pcie.afi_clk);
-	clk_put(tegra_pcie.pex_clk);
-}
-
-static int __init tegra_pcie_get_resources(void)
-{
-	int err;
-
-	err = tegra_pcie_clocks_get();
-	if (err) {
-		pr_err("PCIE: failed to get clocks: %d\n", err);
-		return err;
-	}
-
-	err = tegra_pcie_power_regate();
-	if (err) {
-		pr_err("PCIE: failed to power up: %d\n", err);
-		goto err_pwr_on;
-	}
-
-	tegra_pcie.regs = ioremap_nocache(TEGRA_PCIE_BASE, PCIE_IOMAP_SZ);
-	if (tegra_pcie.regs == NULL) {
-		pr_err("PCIE: Failed to map PCI/AFI registers\n");
-		err = -ENOMEM;
-		goto err_map_reg;
-	}
-
-	err = request_irq(INT_PCIE_INTR, tegra_pcie_isr,
-			  IRQF_SHARED, "PCIE", &tegra_pcie);
-	if (err) {
-		pr_err("PCIE: Failed to register IRQ: %d\n", err);
-		goto err_req_io;
-	}
-	set_irq_flags(INT_PCIE_INTR, IRQF_VALID);
-
-	return 0;
-
-err_req_io:
-	iounmap(tegra_pcie.regs);
-err_map_reg:
-	tegra_pcie_power_off();
-err_pwr_on:
-	tegra_pcie_clocks_put();
-
-	return err;
-}
-
-/*
- * FIXME: If there are no PCIe cards attached, then calling this function
- * can result in the increase of the bootup time as there are big timeout
- * loops.
- */
-#define TEGRA_PCIE_LINKUP_TIMEOUT	200	/* up to 1.2 seconds */
-static bool tegra_pcie_check_link(struct tegra_pcie_port *pp, int idx,
-				  u32 reset_reg)
-{
-	u32 reg;
-	int retries = 3;
-	int timeout;
-
-	do {
-		timeout = TEGRA_PCIE_LINKUP_TIMEOUT;
-		while (timeout) {
-			reg = readl(pp->base + RP_VEND_XP);
-
-			if (reg & RP_VEND_XP_DL_UP)
-				break;
-
-			mdelay(1);
-			timeout--;
-		}
-
-		if (!timeout)  {
-			pr_err("PCIE: port %d: link down, retrying\n", idx);
-			goto retry;
-		}
-
-		timeout = TEGRA_PCIE_LINKUP_TIMEOUT;
-		while (timeout) {
-			reg = readl(pp->base + RP_LINK_CONTROL_STATUS);
-
-			if (reg & 0x20000000)
-				return true;
-
-			mdelay(1);
-			timeout--;
-		}
-
-retry:
-		/* Pulse the PEX reset */
-		reg = afi_readl(reset_reg) | AFI_PEX_CTRL_RST;
-		afi_writel(reg, reset_reg);
-		mdelay(1);
-		reg = afi_readl(reset_reg) & ~AFI_PEX_CTRL_RST;
-		afi_writel(reg, reset_reg);
-
-		retries--;
-	} while (retries);
-
-	return false;
-}
-
-static void __init tegra_pcie_add_port(int index, u32 offset, u32 reset_reg)
-{
-	struct tegra_pcie_port *pp;
-
-	pp = tegra_pcie.port + tegra_pcie.num_ports;
-
-	pp->index = -1;
-	pp->base = tegra_pcie.regs + offset;
-	pp->link_up = tegra_pcie_check_link(pp, index, reset_reg);
-
-	if (!pp->link_up) {
-		pp->base = NULL;
-		printk(KERN_INFO "PCIE: port %d: link down, ignoring\n", index);
-		return;
-	}
-
-	tegra_pcie.num_ports++;
-	pp->index = index;
-	pp->root_bus_nr = -1;
-	memset(pp->res, 0, sizeof(pp->res));
-}
-
-int __init tegra_pcie_init(bool init_port0, bool init_port1)
-{
-	int err;
-
-	if (!(init_port0 || init_port1))
-		return -ENODEV;
-
-	pcibios_min_mem = 0;
-
-	err = tegra_pcie_get_resources();
-	if (err)
-		return err;
-
-	err = tegra_pcie_enable_controller();
-	if (err)
-		return err;
-
-	/* setup the AFI address translations */
-	tegra_pcie_setup_translations();
-
-	if (init_port0)
-		tegra_pcie_add_port(0, RP0_OFFSET, AFI_PEX0_CTRL);
-
-	if (init_port1)
-		tegra_pcie_add_port(1, RP1_OFFSET, AFI_PEX1_CTRL);
-
-	pci_common_init(&tegra_pcie_hw);
-
-	return 0;
-}
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index 0d1e412..fe56fca 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -116,28 +116,6 @@ out:
 				tegra20_auxdata_lookup, parent);
 }
 
-static void __init trimslice_init(void)
-{
-#ifdef CONFIG_TEGRA_PCI
-	int ret;
-
-	ret = tegra_pcie_init(true, true);
-	if (ret)
-		pr_err("tegra_pci_init() failed: %d\n", ret);
-#endif
-}
-
-static void __init harmony_init(void)
-{
-#ifdef CONFIG_TEGRA_PCI
-	int ret;
-
-	ret = harmony_pcie_init();
-	if (ret)
-		pr_err("harmony_pcie_init() failed: %d\n", ret);
-#endif
-}
-
 static void __init paz00_init(void)
 {
 	if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC))
@@ -148,8 +126,6 @@ static struct {
 	char *machine;
 	void (*init)(void);
 } board_init_funcs[] = {
-	{ "compulab,trimslice", trimslice_init },
-	{ "nvidia,harmony", harmony_init },
 	{ "compal,paz00", paz00_init },
 };
 
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 1184ff6..5f33746 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -14,4 +14,8 @@ config PCI_EXYNOS
 	select PCIEPORTBUS
 	select PCIE_DW
 
+config PCI_TEGRA
+	bool "NVIDIA Tegra PCIe controller"
+	depends on ARCH_TEGRA
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 086d850..a733fb0 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
 obj-$(CONFIG_PCIE_DW) += pcie-designware.o
+obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
new file mode 100644
index 0000000..223069a
--- /dev/null
+++ b/drivers/pci/host/pci-tegra.c
@@ -0,0 +1,1540 @@
+/*
+ * PCIe host controller driver for TEGRA(2) SOCs
+ *
+ * Copyright (c) 2010, CompuLab, Ltd.
+ * Author: Mike Rapoport <mike at compulab.co.il>
+ *
+ * Based on NVIDIA PCIe driver
+ * Copyright (c) 2008-2009, NVIDIA Corporation.
+ *
+ * Bits taken from arch/arm/mach-dove/pcie.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk/tegra.h>
+#include <linux/delay.h>
+#include <linux/export.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/msi.h>
+#include <linux/of_address.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/sizes.h>
+#include <linux/slab.h>
+#include <linux/tegra-pmc.h>
+#include <linux/tegra-powergate.h>
+#include <linux/vmalloc.h>
+#include <linux/regulator/consumer.h>
+
+#include <asm/mach/irq.h>
+#include <asm/mach/map.h>
+#include <asm/mach/pci.h>
+
+#define INT_PCI_MSI_NR (8 * 32)
+#define TEGRA_MAX_PORTS 2
+
+/* register definitions */
+
+#define AFI_AXI_BAR0_SZ	0x00
+#define AFI_AXI_BAR1_SZ	0x04
+#define AFI_AXI_BAR2_SZ	0x08
+#define AFI_AXI_BAR3_SZ	0x0c
+#define AFI_AXI_BAR4_SZ	0x10
+#define AFI_AXI_BAR5_SZ	0x14
+
+#define AFI_AXI_BAR0_START	0x18
+#define AFI_AXI_BAR1_START	0x1c
+#define AFI_AXI_BAR2_START	0x20
+#define AFI_AXI_BAR3_START	0x24
+#define AFI_AXI_BAR4_START	0x28
+#define AFI_AXI_BAR5_START	0x2c
+
+#define AFI_FPCI_BAR0	0x30
+#define AFI_FPCI_BAR1	0x34
+#define AFI_FPCI_BAR2	0x38
+#define AFI_FPCI_BAR3	0x3c
+#define AFI_FPCI_BAR4	0x40
+#define AFI_FPCI_BAR5	0x44
+
+#define AFI_CACHE_BAR0_SZ	0x48
+#define AFI_CACHE_BAR0_ST	0x4c
+#define AFI_CACHE_BAR1_SZ	0x50
+#define AFI_CACHE_BAR1_ST	0x54
+
+#define AFI_MSI_BAR_SZ		0x60
+#define AFI_MSI_FPCI_BAR_ST	0x64
+#define AFI_MSI_AXI_BAR_ST	0x68
+
+#define AFI_MSI_VEC0		0x6c
+#define AFI_MSI_VEC1		0x70
+#define AFI_MSI_VEC2		0x74
+#define AFI_MSI_VEC3		0x78
+#define AFI_MSI_VEC4		0x7c
+#define AFI_MSI_VEC5		0x80
+#define AFI_MSI_VEC6		0x84
+#define AFI_MSI_VEC7		0x88
+
+#define AFI_MSI_EN_VEC0		0x8c
+#define AFI_MSI_EN_VEC1		0x90
+#define AFI_MSI_EN_VEC2		0x94
+#define AFI_MSI_EN_VEC3		0x98
+#define AFI_MSI_EN_VEC4		0x9c
+#define AFI_MSI_EN_VEC5		0xa0
+#define AFI_MSI_EN_VEC6		0xa4
+#define AFI_MSI_EN_VEC7		0xa8
+
+#define AFI_CONFIGURATION		0xac
+#define  AFI_CONFIGURATION_EN_FPCI	(1 << 0)
+
+#define AFI_FPCI_ERROR_MASKS	0xb0
+
+#define AFI_INTR_MASK		0xb4
+#define  AFI_INTR_MASK_INT_MASK	(1 << 0)
+#define  AFI_INTR_MASK_MSI_MASK	(1 << 8)
+
+#define AFI_INTR_CODE			0xb8
+#define  AFI_INTR_CODE_MASK		0xf
+#define  AFI_INTR_AXI_SLAVE_ERROR	1
+#define  AFI_INTR_AXI_DECODE_ERROR	2
+#define  AFI_INTR_TARGET_ABORT		3
+#define  AFI_INTR_MASTER_ABORT		4
+#define  AFI_INTR_INVALID_WRITE		5
+#define  AFI_INTR_LEGACY		6
+#define  AFI_INTR_FPCI_DECODE_ERROR	7
+
+#define AFI_INTR_SIGNATURE	0xbc
+#define AFI_UPPER_FPCI_ADDRESS	0xc0
+#define AFI_SM_INTR_ENABLE	0xc4
+#define  AFI_SM_INTR_INTA_ASSERT	(1 << 0)
+#define  AFI_SM_INTR_INTB_ASSERT	(1 << 1)
+#define  AFI_SM_INTR_INTC_ASSERT	(1 << 2)
+#define  AFI_SM_INTR_INTD_ASSERT	(1 << 3)
+#define  AFI_SM_INTR_INTA_DEASSERT	(1 << 4)
+#define  AFI_SM_INTR_INTB_DEASSERT	(1 << 5)
+#define  AFI_SM_INTR_INTC_DEASSERT	(1 << 6)
+#define  AFI_SM_INTR_INTD_DEASSERT	(1 << 7)
+
+#define AFI_AFI_INTR_ENABLE		0xc8
+#define  AFI_INTR_EN_INI_SLVERR		(1 << 0)
+#define  AFI_INTR_EN_INI_DECERR		(1 << 1)
+#define  AFI_INTR_EN_TGT_SLVERR		(1 << 2)
+#define  AFI_INTR_EN_TGT_DECERR		(1 << 3)
+#define  AFI_INTR_EN_TGT_WRERR		(1 << 4)
+#define  AFI_INTR_EN_DFPCI_DECERR	(1 << 5)
+#define  AFI_INTR_EN_AXI_DECERR		(1 << 6)
+#define  AFI_INTR_EN_FPCI_TIMEOUT	(1 << 7)
+
+#define AFI_PCIE_CONFIG					0x0f8
+#define  AFI_PCIE_CONFIG_PCIE_DISABLE(x)		(1 << ((x) + 1))
+#define  AFI_PCIE_CONFIG_PCIE_DISABLE_ALL		0xe
+#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK	(0xf << 20)
+#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE	(0x0 << 20)
+#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL	(0x1 << 20)
+
+#define AFI_FUSE			0x104
+#define  AFI_FUSE_PCIE_T0_GEN2_DIS	(1 << 2)
+
+#define AFI_PEX0_CTRL			0x110
+#define AFI_PEX1_CTRL			0x118
+#define  AFI_PEX_CTRL_RST		(1 << 0)
+#define  AFI_PEX_CTRL_REFCLK_EN		(1 << 3)
+
+#define RP_VEND_XP	0x00000F00
+#define  RP_VEND_XP_DL_UP	(1 << 30)
+
+#define RP_LINK_CONTROL_STATUS			0x00000090
+#define  RP_LINK_CONTROL_STATUS_DL_LINK_ACTIVE	0x20000000
+#define  RP_LINK_CONTROL_STATUS_LINKSTAT_MASK	0x3fff0000
+
+#define PADS_CTL_SEL		0x0000009C
+
+#define PADS_CTL		0x000000A0
+#define  PADS_CTL_IDDQ_1L	(1 << 0)
+#define  PADS_CTL_TX_DATA_EN_1L	(1 << 6)
+#define  PADS_CTL_RX_DATA_EN_1L	(1 << 10)
+
+#define PADS_PLL_CTL				0x000000B8
+#define  PADS_PLL_CTL_RST_B4SM			(1 << 1)
+#define  PADS_PLL_CTL_LOCKDET			(1 << 8)
+#define  PADS_PLL_CTL_REFCLK_MASK		(0x3 << 16)
+#define  PADS_PLL_CTL_REFCLK_INTERNAL_CML	(0 << 16)
+#define  PADS_PLL_CTL_REFCLK_INTERNAL_CMOS	(1 << 16)
+#define  PADS_PLL_CTL_REFCLK_EXTERNAL		(2 << 16)
+#define  PADS_PLL_CTL_TXCLKREF_MASK		(0x1 << 20)
+#define  PADS_PLL_CTL_TXCLKREF_DIV10		(0 << 20)
+#define  PADS_PLL_CTL_TXCLKREF_DIV5		(1 << 20)
+
+struct tegra_msi {
+	struct msi_chip chip;
+	DECLARE_BITMAP(used, INT_PCI_MSI_NR);
+	struct irq_domain *domain;
+	unsigned long pages;
+	struct mutex lock;
+	int irq;
+};
+
+static inline struct tegra_msi *to_tegra_msi(struct msi_chip *chip)
+{
+	return container_of(chip, struct tegra_msi, chip);
+}
+
+struct tegra_pcie {
+	struct device *dev;
+
+	void __iomem *pads;
+	void __iomem *afi;
+	int irq;
+
+	struct list_head busses;
+	struct resource *cs;
+
+	struct resource io;
+	struct resource mem;
+	struct resource prefetch;
+	struct resource busn;
+
+	struct clk *pex_clk;
+	struct clk *afi_clk;
+	struct clk *pcie_xclk;
+	struct clk *pll_e;
+
+	struct tegra_msi msi;
+
+	struct list_head ports;
+	unsigned int num_ports;
+	u32 xbar_config;
+
+	struct regulator *pex_clk_supply;
+	struct regulator *vdd_supply;
+};
+
+struct tegra_pcie_port {
+	struct tegra_pcie *pcie;
+	struct list_head list;
+	struct resource regs;
+	void __iomem *base;
+	unsigned int index;
+	unsigned int lanes;
+};
+
+struct tegra_pcie_bus {
+	struct vm_struct *area;
+	struct list_head list;
+	unsigned int nr;
+};
+
+static inline struct tegra_pcie *sys_to_pcie(struct pci_sys_data *sys)
+{
+	return sys->private_data;
+}
+
+static inline void afi_writel(struct tegra_pcie *pcie, u32 value,
+			      unsigned long offset)
+{
+	writel(value, pcie->afi + offset);
+}
+
+static inline u32 afi_readl(struct tegra_pcie *pcie, unsigned long offset)
+{
+	return readl(pcie->afi + offset);
+}
+
+static inline void pads_writel(struct tegra_pcie *pcie, u32 value,
+			       unsigned long offset)
+{
+	writel(value, pcie->pads + offset);
+}
+
+static inline u32 pads_readl(struct tegra_pcie *pcie, unsigned long offset)
+{
+	return readl(pcie->pads + offset);
+}
+
+/*
+ * The configuration space mapping on Tegra is somewhat similar to the ECAM
+ * defined by PCIe. However it deviates a bit in how the 4 bits for extended
+ * register accesses are mapped:
+ *
+ *    [27:24] extended register number
+ *    [23:16] bus number
+ *    [15:11] device number
+ *    [10: 8] function number
+ *    [ 7: 0] register number
+ *
+ * Mapping the whole extended configuration space would require 256 MiB of
+ * virtual address space, only a small part of which will actually be used.
+ * To work around this, a 1 MiB of virtual addresses are allocated per bus
+ * when the bus is first accessed. When the physical range is mapped, the
+ * the bus number bits are hidden so that the extended register number bits
+ * appear as bits [19:16]. Therefore the virtual mapping looks like this:
+ *
+ *    [19:16] extended register number
+ *    [15:11] device number
+ *    [10: 8] function number
+ *    [ 7: 0] register number
+ *
+ * This is achieved by stitching together 16 chunks of 64 KiB of physical
+ * address space via the MMU.
+ */
+static unsigned long tegra_pcie_conf_offset(unsigned int devfn, int where)
+{
+	return ((where & 0xf00) << 8) | (PCI_SLOT(devfn) << 11) |
+	       (PCI_FUNC(devfn) << 8) | (where & 0xfc);
+}
+
+static struct tegra_pcie_bus *tegra_pcie_bus_alloc(struct tegra_pcie *pcie,
+						   unsigned int busnr)
+{
+	pgprot_t prot = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY | L_PTE_XN |
+			L_PTE_MT_DEV_SHARED | L_PTE_SHARED;
+	phys_addr_t cs = pcie->cs->start;
+	struct tegra_pcie_bus *bus;
+	unsigned int i;
+	int err;
+
+	bus = kzalloc(sizeof(*bus), GFP_KERNEL);
+	if (!bus)
+		return ERR_PTR(-ENOMEM);
+
+	INIT_LIST_HEAD(&bus->list);
+	bus->nr = busnr;
+
+	/* allocate 1 MiB of virtual addresses */
+	bus->area = get_vm_area(SZ_1M, VM_IOREMAP);
+	if (!bus->area) {
+		err = -ENOMEM;
+		goto free;
+	}
+
+	/* map each of the 16 chunks of 64 KiB each */
+	for (i = 0; i < 16; i++) {
+		unsigned long virt = (unsigned long)bus->area->addr +
+				     i * SZ_64K;
+		phys_addr_t phys = cs + i * SZ_1M + busnr * SZ_64K;
+
+		err = ioremap_page_range(virt, virt + SZ_64K, phys, prot);
+		if (err < 0) {
+			dev_err(pcie->dev, "ioremap_page_range() failed: %d\n",
+				err);
+			goto unmap;
+		}
+	}
+
+	return bus;
+
+unmap:
+	vunmap(bus->area->addr);
+free:
+	kfree(bus);
+	return ERR_PTR(err);
+}
+
+/*
+ * Look up a virtual address mapping for the specified bus number. If no such
+ * mapping existis, try to create one.
+ */
+static void __iomem *tegra_pcie_bus_map(struct tegra_pcie *pcie,
+					unsigned int busnr)
+{
+	struct tegra_pcie_bus *bus;
+
+	list_for_each_entry(bus, &pcie->busses, list)
+		if (bus->nr == busnr)
+			return bus->area->addr;
+
+	bus = tegra_pcie_bus_alloc(pcie, busnr);
+	if (IS_ERR(bus))
+		return NULL;
+
+	list_add_tail(&bus->list, &pcie->busses);
+
+	return bus->area->addr;
+}
+
+static void __iomem *tegra_pcie_conf_address(struct pci_bus *bus,
+					     unsigned int devfn,
+					     int where)
+{
+	struct tegra_pcie *pcie = sys_to_pcie(bus->sysdata);
+	void __iomem *addr = NULL;
+
+	if (bus->number == 0) {
+		unsigned int slot = PCI_SLOT(devfn);
+		struct tegra_pcie_port *port;
+
+		list_for_each_entry(port, &pcie->ports, list) {
+			if (port->index + 1 == slot) {
+				addr = port->base + (where & ~3);
+				break;
+			}
+		}
+	} else {
+		addr = tegra_pcie_bus_map(pcie, bus->number);
+		if (!addr) {
+			dev_err(pcie->dev,
+				"failed to map cfg. space for bus %u\n",
+				bus->number);
+			return NULL;
+		}
+
+		addr += tegra_pcie_conf_offset(devfn, where);
+	}
+
+	return addr;
+}
+
+static int tegra_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
+				int where, int size, u32 *value)
+{
+	void __iomem *addr;
+
+	addr = tegra_pcie_conf_address(bus, devfn, where);
+	if (!addr) {
+		*value = 0xffffffff;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	*value = readl(addr);
+
+	if (size == 1)
+		*value = (*value >> (8 * (where & 3))) & 0xff;
+	else if (size == 2)
+		*value = (*value >> (8 * (where & 3))) & 0xffff;
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static int tegra_pcie_write_conf(struct pci_bus *bus, unsigned int devfn,
+				 int where, int size, u32 value)
+{
+	void __iomem *addr;
+	u32 mask, tmp;
+
+	addr = tegra_pcie_conf_address(bus, devfn, where);
+	if (!addr)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	if (size == 4) {
+		writel(value, addr);
+		return PCIBIOS_SUCCESSFUL;
+	}
+
+	if (size == 2)
+		mask = ~(0xffff << ((where & 0x3) * 8));
+	else if (size == 1)
+		mask = ~(0xff << ((where & 0x3) * 8));
+	else
+		return PCIBIOS_BAD_REGISTER_NUMBER;
+
+	tmp = readl(addr) & mask;
+	tmp |= value << ((where & 0x3) * 8);
+	writel(tmp, addr);
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static struct pci_ops tegra_pcie_ops = {
+	.read = tegra_pcie_read_conf,
+	.write = tegra_pcie_write_conf,
+};
+
+static unsigned long tegra_pcie_port_get_pex_ctrl(struct tegra_pcie_port *port)
+{
+	unsigned long ret = 0;
+
+	switch (port->index) {
+	case 0:
+		ret = AFI_PEX0_CTRL;
+		break;
+
+	case 1:
+		ret = AFI_PEX1_CTRL;
+		break;
+	}
+
+	return ret;
+}
+
+static void tegra_pcie_port_reset(struct tegra_pcie_port *port)
+{
+	unsigned long ctrl = tegra_pcie_port_get_pex_ctrl(port);
+	unsigned long value;
+
+	/* pulse reset signal */
+	value = afi_readl(port->pcie, ctrl);
+	value &= ~AFI_PEX_CTRL_RST;
+	afi_writel(port->pcie, value, ctrl);
+
+	usleep_range(1000, 2000);
+
+	value = afi_readl(port->pcie, ctrl);
+	value |= AFI_PEX_CTRL_RST;
+	afi_writel(port->pcie, value, ctrl);
+}
+
+static void tegra_pcie_port_enable(struct tegra_pcie_port *port)
+{
+	unsigned long ctrl = tegra_pcie_port_get_pex_ctrl(port);
+	unsigned long value;
+
+	/* enable reference clock */
+	value = afi_readl(port->pcie, ctrl);
+	value |= AFI_PEX_CTRL_REFCLK_EN;
+	afi_writel(port->pcie, value, ctrl);
+
+	tegra_pcie_port_reset(port);
+}
+
+static void tegra_pcie_port_disable(struct tegra_pcie_port *port)
+{
+	unsigned long ctrl = tegra_pcie_port_get_pex_ctrl(port);
+	unsigned long value;
+
+	/* assert port reset */
+	value = afi_readl(port->pcie, ctrl);
+	value &= ~AFI_PEX_CTRL_RST;
+	afi_writel(port->pcie, value, ctrl);
+
+	/* disable reference clock */
+	value = afi_readl(port->pcie, ctrl);
+	value &= ~AFI_PEX_CTRL_REFCLK_EN;
+	afi_writel(port->pcie, value, ctrl);
+}
+
+static void tegra_pcie_port_free(struct tegra_pcie_port *port)
+{
+	struct tegra_pcie *pcie = port->pcie;
+
+	devm_iounmap(pcie->dev, port->base);
+	devm_release_mem_region(pcie->dev, port->regs.start,
+				resource_size(&port->regs));
+	list_del(&port->list);
+	devm_kfree(pcie->dev, port);
+}
+
+static void tegra_pcie_fixup_bridge(struct pci_dev *dev)
+{
+	u16 reg;
+
+	if ((dev->class >> 16) == PCI_BASE_CLASS_BRIDGE) {
+		pci_read_config_word(dev, PCI_COMMAND, &reg);
+		reg |= (PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
+			PCI_COMMAND_MASTER | PCI_COMMAND_SERR);
+		pci_write_config_word(dev, PCI_COMMAND, reg);
+	}
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, tegra_pcie_fixup_bridge);
+
+/* Tegra PCIE root complex wrongly reports device class */
+static void tegra_pcie_fixup_class(struct pci_dev *dev)
+{
+	dev->class = PCI_CLASS_BRIDGE_PCI << 8;
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf0, tegra_pcie_fixup_class);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf1, tegra_pcie_fixup_class);
+
+/* Tegra PCIE requires relaxed ordering */
+static void tegra_pcie_relax_enable(struct pci_dev *dev)
+{
+	pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, tegra_pcie_relax_enable);
+
+static int tegra_pcie_setup(int nr, struct pci_sys_data *sys)
+{
+	struct tegra_pcie *pcie = sys_to_pcie(sys);
+
+	pci_add_resource_offset(&sys->resources, &pcie->mem, sys->mem_offset);
+	pci_add_resource_offset(&sys->resources, &pcie->prefetch,
+				sys->mem_offset);
+	pci_add_resource(&sys->resources, &pcie->busn);
+
+	pci_ioremap_io(nr * SZ_64K, pcie->io.start);
+
+	return 1;
+}
+
+static int tegra_pcie_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
+{
+	struct tegra_pcie *pcie = sys_to_pcie(pdev->bus->sysdata);
+
+	return pcie->irq;
+}
+
+static void tegra_pcie_add_bus(struct pci_bus *bus)
+{
+	if (IS_ENABLED(CONFIG_PCI_MSI)) {
+		struct tegra_pcie *pcie = sys_to_pcie(bus->sysdata);
+
+		bus->msi = &pcie->msi.chip;
+	}
+}
+
+static struct pci_bus *tegra_pcie_scan_bus(int nr, struct pci_sys_data *sys)
+{
+	struct tegra_pcie *pcie = sys_to_pcie(sys);
+	struct pci_bus *bus;
+
+	bus = pci_create_root_bus(pcie->dev, sys->busnr, &tegra_pcie_ops, sys,
+				  &sys->resources);
+	if (!bus)
+		return NULL;
+
+	pci_scan_child_bus(bus);
+
+	return bus;
+}
+
+static irqreturn_t tegra_pcie_isr(int irq, void *arg)
+{
+	const char *err_msg[] = {
+		"Unknown",
+		"AXI slave error",
+		"AXI decode error",
+		"Target abort",
+		"Master abort",
+		"Invalid write",
+		"Response decoding error",
+		"AXI response decoding error",
+		"Transaction timeout",
+	};
+	struct tegra_pcie *pcie = arg;
+	u32 code, signature;
+
+	code = afi_readl(pcie, AFI_INTR_CODE) & AFI_INTR_CODE_MASK;
+	signature = afi_readl(pcie, AFI_INTR_SIGNATURE);
+	afi_writel(pcie, 0, AFI_INTR_CODE);
+
+	if (code == AFI_INTR_LEGACY)
+		return IRQ_NONE;
+
+	if (code >= ARRAY_SIZE(err_msg))
+		code = 0;
+
+	/*
+	 * do not pollute kernel log with master abort reports since they
+	 * happen a lot during enumeration
+	 */
+	if (code == AFI_INTR_MASTER_ABORT)
+		dev_dbg(pcie->dev, "%s, signature: %08x\n", err_msg[code],
+			signature);
+	else
+		dev_err(pcie->dev, "%s, signature: %08x\n", err_msg[code],
+			signature);
+
+	if (code == AFI_INTR_TARGET_ABORT || code == AFI_INTR_MASTER_ABORT ||
+	    code == AFI_INTR_FPCI_DECODE_ERROR) {
+		u32 fpci = afi_readl(pcie, AFI_UPPER_FPCI_ADDRESS) & 0xff;
+		u64 address = (u64)fpci << 32 | (signature & 0xfffffffc);
+
+		if (code == AFI_INTR_MASTER_ABORT)
+			dev_dbg(pcie->dev, "  FPCI address: %10llx\n", address);
+		else
+			dev_err(pcie->dev, "  FPCI address: %10llx\n", address);
+	}
+
+	return IRQ_HANDLED;
+}
+
+/*
+ * FPCI map is as follows:
+ * - 0xfdfc000000: I/O space
+ * - 0xfdfe000000: type 0 configuration space
+ * - 0xfdff000000: type 1 configuration space
+ * - 0xfe00000000: type 0 extended configuration space
+ * - 0xfe10000000: type 1 extended configuration space
+ */
+static void tegra_pcie_setup_translations(struct tegra_pcie *pcie)
+{
+	u32 fpci_bar, size, axi_address;
+
+	/* Bar 0: type 1 extended configuration space */
+	fpci_bar = 0xfe100000;
+	size = resource_size(pcie->cs);
+	axi_address = pcie->cs->start;
+	afi_writel(pcie, axi_address, AFI_AXI_BAR0_START);
+	afi_writel(pcie, size >> 12, AFI_AXI_BAR0_SZ);
+	afi_writel(pcie, fpci_bar, AFI_FPCI_BAR0);
+
+	/* Bar 1: downstream IO bar */
+	fpci_bar = 0xfdfc0000;
+	size = resource_size(&pcie->io);
+	axi_address = pcie->io.start;
+	afi_writel(pcie, axi_address, AFI_AXI_BAR1_START);
+	afi_writel(pcie, size >> 12, AFI_AXI_BAR1_SZ);
+	afi_writel(pcie, fpci_bar, AFI_FPCI_BAR1);
+
+	/* Bar 2: prefetchable memory BAR */
+	fpci_bar = (((pcie->prefetch.start >> 12) & 0x0fffffff) << 4) | 0x1;
+	size = resource_size(&pcie->prefetch);
+	axi_address = pcie->prefetch.start;
+	afi_writel(pcie, axi_address, AFI_AXI_BAR2_START);
+	afi_writel(pcie, size >> 12, AFI_AXI_BAR2_SZ);
+	afi_writel(pcie, fpci_bar, AFI_FPCI_BAR2);
+
+	/* Bar 3: non prefetchable memory BAR */
+	fpci_bar = (((pcie->mem.start >> 12) & 0x0fffffff) << 4) | 0x1;
+	size = resource_size(&pcie->mem);
+	axi_address = pcie->mem.start;
+	afi_writel(pcie, axi_address, AFI_AXI_BAR3_START);
+	afi_writel(pcie, size >> 12, AFI_AXI_BAR3_SZ);
+	afi_writel(pcie, fpci_bar, AFI_FPCI_BAR3);
+
+	/* NULL out the remaining BARs as they are not used */
+	afi_writel(pcie, 0, AFI_AXI_BAR4_START);
+	afi_writel(pcie, 0, AFI_AXI_BAR4_SZ);
+	afi_writel(pcie, 0, AFI_FPCI_BAR4);
+
+	afi_writel(pcie, 0, AFI_AXI_BAR5_START);
+	afi_writel(pcie, 0, AFI_AXI_BAR5_SZ);
+	afi_writel(pcie, 0, AFI_FPCI_BAR5);
+
+	/* map all upstream transactions as uncached */
+	afi_writel(pcie, PHYS_OFFSET, AFI_CACHE_BAR0_ST);
+	afi_writel(pcie, 0, AFI_CACHE_BAR0_SZ);
+	afi_writel(pcie, 0, AFI_CACHE_BAR1_ST);
+	afi_writel(pcie, 0, AFI_CACHE_BAR1_SZ);
+
+	/* MSI translations are setup only when needed */
+	afi_writel(pcie, 0, AFI_MSI_FPCI_BAR_ST);
+	afi_writel(pcie, 0, AFI_MSI_BAR_SZ);
+	afi_writel(pcie, 0, AFI_MSI_AXI_BAR_ST);
+	afi_writel(pcie, 0, AFI_MSI_BAR_SZ);
+}
+
+static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
+{
+	struct tegra_pcie_port *port;
+	unsigned int timeout;
+	unsigned long value;
+
+	/* configure mode and disable all ports */
+	value = afi_readl(pcie, AFI_PCIE_CONFIG);
+	value &= ~AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK;
+	value |= AFI_PCIE_CONFIG_PCIE_DISABLE_ALL | pcie->xbar_config;
+
+	list_for_each_entry(port, &pcie->ports, list)
+		value &= ~AFI_PCIE_CONFIG_PCIE_DISABLE(port->index);
+
+	afi_writel(pcie, value, AFI_PCIE_CONFIG);
+
+	value = afi_readl(pcie, AFI_FUSE);
+	value &= ~AFI_FUSE_PCIE_T0_GEN2_DIS;
+	afi_writel(pcie, value, AFI_FUSE);
+
+	/* initialze internal PHY, enable up to 16 PCIE lanes */
+	pads_writel(pcie, 0x0, PADS_CTL_SEL);
+
+	/* override IDDQ to 1 on all 4 lanes */
+	value = pads_readl(pcie, PADS_CTL);
+	value |= PADS_CTL_IDDQ_1L;
+	pads_writel(pcie, value, PADS_CTL);
+
+	/*
+	 * Set up PHY PLL inputs select PLLE output as refclock,
+	 * set TX ref sel to div10 (not div5).
+	 */
+	value = pads_readl(pcie, PADS_PLL_CTL);
+	value &= ~(PADS_PLL_CTL_REFCLK_MASK | PADS_PLL_CTL_TXCLKREF_MASK);
+	value |= PADS_PLL_CTL_REFCLK_INTERNAL_CML |
+		 PADS_PLL_CTL_TXCLKREF_DIV10;
+	pads_writel(pcie, value, PADS_PLL_CTL);
+
+	/* take PLL out of reset  */
+	value = pads_readl(pcie, PADS_PLL_CTL);
+	value |= PADS_PLL_CTL_RST_B4SM;
+	pads_writel(pcie, value, PADS_PLL_CTL);
+
+	/*
+	 * Hack, set the clock voltage to the DEFAULT provided by hw folks.
+	 * This doesn't exist in the documentation.
+	 */
+	pads_writel(pcie, 0xfa5cfa5c, 0xc8);
+
+	/* wait for the PLL to lock */
+	timeout = 300;
+	do {
+		value = pads_readl(pcie, PADS_PLL_CTL);
+		usleep_range(1000, 2000);
+		if (--timeout == 0) {
+			pr_err("Tegra PCIe error: timeout waiting for PLL\n");
+			return -EBUSY;
+		}
+	} while (!(value & PADS_PLL_CTL_LOCKDET));
+
+	/* turn off IDDQ override */
+	value = pads_readl(pcie, PADS_CTL);
+	value &= ~PADS_CTL_IDDQ_1L;
+	pads_writel(pcie, value, PADS_CTL);
+
+	/* enable TX/RX data */
+	value = pads_readl(pcie, PADS_CTL);
+	value |= PADS_CTL_TX_DATA_EN_1L | PADS_CTL_RX_DATA_EN_1L;
+	pads_writel(pcie, value, PADS_CTL);
+
+	/* take the PCIe interface module out of reset */
+	tegra_periph_reset_deassert(pcie->pcie_xclk);
+
+	/* finally enable PCIe */
+	value = afi_readl(pcie, AFI_CONFIGURATION);
+	value |= AFI_CONFIGURATION_EN_FPCI;
+	afi_writel(pcie, value, AFI_CONFIGURATION);
+
+	value = AFI_INTR_EN_INI_SLVERR | AFI_INTR_EN_INI_DECERR |
+		AFI_INTR_EN_TGT_SLVERR | AFI_INTR_EN_TGT_DECERR |
+		AFI_INTR_EN_TGT_WRERR | AFI_INTR_EN_DFPCI_DECERR;
+	afi_writel(pcie, value, AFI_AFI_INTR_ENABLE);
+	afi_writel(pcie, 0xffffffff, AFI_SM_INTR_ENABLE);
+
+	/* don't enable MSI for now, only when needed */
+	afi_writel(pcie, AFI_INTR_MASK_INT_MASK, AFI_INTR_MASK);
+
+	/* disable all exceptions */
+	afi_writel(pcie, 0, AFI_FPCI_ERROR_MASKS);
+
+	return 0;
+}
+
+static void tegra_pcie_power_off(struct tegra_pcie *pcie)
+{
+	int err;
+
+	/* TODO: disable and unprepare clocks? */
+
+	tegra_periph_reset_assert(pcie->pcie_xclk);
+	tegra_periph_reset_assert(pcie->afi_clk);
+	tegra_periph_reset_assert(pcie->pex_clk);
+
+	tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
+	tegra_pmc_pcie_xclk_clamp(true);
+
+	err = regulator_disable(pcie->pex_clk_supply);
+	if (err < 0)
+		dev_err(pcie->dev, "failed to disable pex-clk regulator: %d\n",
+			err);
+
+	err = regulator_disable(pcie->vdd_supply);
+	if (err < 0)
+		dev_err(pcie->dev, "failed to disable VDD regulator: %d\n",
+			err);
+}
+
+static int tegra_pcie_power_on(struct tegra_pcie *pcie)
+{
+	int err;
+
+	tegra_periph_reset_assert(pcie->pcie_xclk);
+	tegra_periph_reset_assert(pcie->afi_clk);
+	tegra_periph_reset_assert(pcie->pex_clk);
+
+	tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
+	tegra_pmc_pcie_xclk_clamp(true);
+
+	/* enable regulators */
+	err = regulator_enable(pcie->vdd_supply);
+	if (err < 0) {
+		dev_err(pcie->dev, "failed to enable VDD regulator: %d\n", err);
+		return err;
+	}
+
+	err = regulator_enable(pcie->pex_clk_supply);
+	if (err < 0) {
+		dev_err(pcie->dev, "failed to enable pex-clk regulator: %d\n",
+			err);
+		return err;
+	}
+
+	err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_PCIE,
+						pcie->pex_clk);
+	if (err) {
+		dev_err(pcie->dev, "powerup sequence failed: %d\n", err);
+		return err;
+	}
+
+	tegra_periph_reset_deassert(pcie->afi_clk);
+
+	tegra_pmc_pcie_xclk_clamp(false);
+
+	err = clk_prepare_enable(pcie->afi_clk);
+	if (err < 0) {
+		dev_err(pcie->dev, "failed to enable AFI clock: %d\n", err);
+		return err;
+	}
+
+	err = clk_prepare_enable(pcie->pll_e);
+	if (err < 0) {
+		dev_err(pcie->dev, "failed to enable PLLE clock: %d\n", err);
+		return err;
+	}
+
+	return 0;
+}
+
+static int tegra_pcie_clocks_get(struct tegra_pcie *pcie)
+{
+	pcie->pex_clk = devm_clk_get(pcie->dev, "pex");
+	if (IS_ERR(pcie->pex_clk))
+		return PTR_ERR(pcie->pex_clk);
+
+	pcie->afi_clk = devm_clk_get(pcie->dev, "afi");
+	if (IS_ERR(pcie->afi_clk))
+		return PTR_ERR(pcie->afi_clk);
+
+	pcie->pcie_xclk = devm_clk_get(pcie->dev, "pcie_xclk");
+	if (IS_ERR(pcie->pcie_xclk))
+		return PTR_ERR(pcie->pcie_xclk);
+
+	pcie->pll_e = devm_clk_get(pcie->dev, "pll_e");
+	if (IS_ERR(pcie->pll_e))
+		return PTR_ERR(pcie->pll_e);
+
+	return 0;
+}
+
+static int tegra_pcie_get_resources(struct tegra_pcie *pcie)
+{
+	struct platform_device *pdev = to_platform_device(pcie->dev);
+	struct resource *pads, *afi, *res;
+	int err;
+
+	err = tegra_pcie_clocks_get(pcie);
+	if (err) {
+		dev_err(&pdev->dev, "failed to get clocks: %d\n", err);
+		return err;
+	}
+
+	err = tegra_pcie_power_on(pcie);
+	if (err) {
+		dev_err(&pdev->dev, "failed to power up: %d\n", err);
+		return err;
+	}
+
+	/* request and remap controller registers */
+	pads = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pads");
+	if (!pads) {
+		err = -EADDRNOTAVAIL;
+		goto poweroff;
+	}
+
+	afi = platform_get_resource_byname(pdev, IORESOURCE_MEM, "afi");
+	if (!afi) {
+		err = -EADDRNOTAVAIL;
+		goto poweroff;
+	}
+
+	pcie->pads = devm_request_and_ioremap(&pdev->dev, pads);
+	if (!pcie->pads) {
+		err = -EADDRNOTAVAIL;
+		goto poweroff;
+	}
+
+	pcie->afi = devm_request_and_ioremap(&pdev->dev, afi);
+	if (!pcie->afi) {
+		err = -EADDRNOTAVAIL;
+		goto poweroff;
+	}
+
+	/* request and remap configuration space */
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cs");
+	if (!res) {
+		err = -EADDRNOTAVAIL;
+		goto poweroff;
+	}
+
+	pcie->cs = devm_request_mem_region(pcie->dev, res->start,
+					   resource_size(res), res->name);
+	if (!pcie->cs) {
+		err = -EADDRNOTAVAIL;
+		goto poweroff;
+	}
+
+	/* request interrupt */
+	err = platform_get_irq_byname(pdev, "intr");
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to get IRQ: %d\n", err);
+		goto poweroff;
+	}
+
+	pcie->irq = err;
+
+	err = request_irq(pcie->irq, tegra_pcie_isr, IRQF_SHARED, "PCIE", pcie);
+	if (err) {
+		dev_err(&pdev->dev, "failed to register IRQ: %d\n", err);
+		goto poweroff;
+	}
+
+	return 0;
+
+poweroff:
+	tegra_pcie_power_off(pcie);
+	return err;
+}
+
+static int tegra_pcie_put_resources(struct tegra_pcie *pcie)
+{
+	if (pcie->irq > 0)
+		free_irq(pcie->irq, pcie);
+
+	tegra_pcie_power_off(pcie);
+	return 0;
+}
+
+static int tegra_msi_alloc(struct tegra_msi *chip)
+{
+	int msi;
+
+	mutex_lock(&chip->lock);
+
+	msi = find_first_zero_bit(chip->used, INT_PCI_MSI_NR);
+	if (msi < INT_PCI_MSI_NR)
+		set_bit(msi, chip->used);
+	else
+		msi = -ENOSPC;
+
+	mutex_unlock(&chip->lock);
+
+	return msi;
+}
+
+static void tegra_msi_free(struct tegra_msi *chip, unsigned long irq)
+{
+	struct device *dev = chip->chip.dev;
+
+	mutex_lock(&chip->lock);
+
+	if (!test_bit(irq, chip->used))
+		dev_err(dev, "trying to free unused MSI#%lu\n", irq);
+	else
+		clear_bit(irq, chip->used);
+
+	mutex_unlock(&chip->lock);
+}
+
+static irqreturn_t tegra_pcie_msi_irq(int irq, void *data)
+{
+	struct tegra_pcie *pcie = data;
+	struct tegra_msi *msi = &pcie->msi;
+	unsigned int i, processed = 0;
+
+	for (i = 0; i < 8; i++) {
+		unsigned long reg = afi_readl(pcie, AFI_MSI_VEC0 + i * 4);
+
+		while (reg) {
+			unsigned int offset = find_first_bit(&reg, 32);
+			unsigned int index = i * 32 + offset;
+			unsigned int irq;
+
+			/* clear the interrupt */
+			afi_writel(pcie, 1 << offset, AFI_MSI_VEC0 + i * 4);
+
+			irq = irq_find_mapping(msi->domain, index);
+			if (irq) {
+				if (test_bit(index, msi->used))
+					generic_handle_irq(irq);
+				else
+					dev_info(pcie->dev, "unhandled MSI\n");
+			} else {
+				/*
+				 * that's weird who triggered this?
+				 * just clear it
+				 */
+				dev_info(pcie->dev, "unexpected MSI\n");
+			}
+
+			/* see if there's any more pending in this vector */
+			reg = afi_readl(pcie, AFI_MSI_VEC0 + i * 4);
+
+			processed++;
+		}
+	}
+
+	return processed > 0 ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static int tegra_msi_setup_irq(struct msi_chip *chip, struct pci_dev *pdev,
+			       struct msi_desc *desc)
+{
+	struct tegra_msi *msi = to_tegra_msi(chip);
+	struct msi_msg msg;
+	unsigned int irq;
+	int hwirq;
+
+	hwirq = tegra_msi_alloc(msi);
+	if (hwirq < 0)
+		return hwirq;
+
+	irq = irq_create_mapping(msi->domain, hwirq);
+	if (!irq)
+		return -EINVAL;
+
+	irq_set_msi_desc(irq, desc);
+
+	msg.address_lo = virt_to_phys((void *)msi->pages);
+	/* 32 bit address only */
+	msg.address_hi = 0;
+	msg.data = hwirq;
+
+	write_msi_msg(irq, &msg);
+
+	return 0;
+}
+
+static void tegra_msi_teardown_irq(struct msi_chip *chip, unsigned int irq)
+{
+	struct tegra_msi *msi = to_tegra_msi(chip);
+	struct irq_data *d = irq_get_irq_data(irq);
+
+	tegra_msi_free(msi, d->hwirq);
+}
+
+static struct irq_chip tegra_msi_irq_chip = {
+	.name = "Tegra PCIe MSI",
+	.irq_enable = unmask_msi_irq,
+	.irq_disable = mask_msi_irq,
+	.irq_mask = mask_msi_irq,
+	.irq_unmask = unmask_msi_irq,
+};
+
+static int tegra_msi_map(struct irq_domain *domain, unsigned int irq,
+			 irq_hw_number_t hwirq)
+{
+	irq_set_chip_and_handler(irq, &tegra_msi_irq_chip, handle_simple_irq);
+	irq_set_chip_data(irq, domain->host_data);
+	set_irq_flags(irq, IRQF_VALID);
+
+	return 0;
+}
+
+static const struct irq_domain_ops msi_domain_ops = {
+	.map = tegra_msi_map,
+};
+
+static int tegra_pcie_enable_msi(struct tegra_pcie *pcie)
+{
+	struct platform_device *pdev = to_platform_device(pcie->dev);
+	struct tegra_msi *msi = &pcie->msi;
+	unsigned long base;
+	int err;
+	u32 reg;
+
+	mutex_init(&msi->lock);
+
+	msi->chip.dev = pcie->dev;
+	msi->chip.setup_irq = tegra_msi_setup_irq;
+	msi->chip.teardown_irq = tegra_msi_teardown_irq;
+
+	msi->domain = irq_domain_add_linear(pcie->dev->of_node, INT_PCI_MSI_NR,
+					    &msi_domain_ops, &msi->chip);
+	if (!msi->domain) {
+		dev_err(&pdev->dev, "failed to create IRQ domain\n");
+		return -ENOMEM;
+	}
+
+	err = platform_get_irq_byname(pdev, "msi");
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to get IRQ: %d\n", err);
+		goto err;
+	}
+
+	msi->irq = err;
+
+	err = request_irq(msi->irq, tegra_pcie_msi_irq, 0,
+			  tegra_msi_irq_chip.name, pcie);
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to request IRQ: %d\n", err);
+		goto err;
+	}
+
+	/* setup AFI/FPCI range */
+	msi->pages = __get_free_pages(GFP_KERNEL, 0);
+	base = virt_to_phys((void *)msi->pages);
+
+	afi_writel(pcie, base, AFI_MSI_FPCI_BAR_ST);
+	afi_writel(pcie, base, AFI_MSI_AXI_BAR_ST);
+	/* this register is in 4K increments */
+	afi_writel(pcie, 1, AFI_MSI_BAR_SZ);
+
+	/* enable all MSI vectors */
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC0);
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC1);
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC2);
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC3);
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC4);
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC5);
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC6);
+	afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC7);
+
+	/* and unmask the MSI interrupt */
+	reg = afi_readl(pcie, AFI_INTR_MASK);
+	reg |= AFI_INTR_MASK_MSI_MASK;
+	afi_writel(pcie, reg, AFI_INTR_MASK);
+
+	return 0;
+
+err:
+	irq_domain_remove(msi->domain);
+	return err;
+}
+
+static int tegra_pcie_disable_msi(struct tegra_pcie *pcie)
+{
+	struct tegra_msi *msi = &pcie->msi;
+	unsigned int i, irq;
+	u32 value;
+
+	/* mask the MSI interrupt */
+	value = afi_readl(pcie, AFI_INTR_MASK);
+	value &= ~AFI_INTR_MASK_MSI_MASK;
+	afi_writel(pcie, value, AFI_INTR_MASK);
+
+	/* disable all MSI vectors */
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC0);
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC1);
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC2);
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC3);
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC4);
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC5);
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC6);
+	afi_writel(pcie, 0, AFI_MSI_EN_VEC7);
+
+	free_pages(msi->pages, 0);
+
+	if (msi->irq > 0)
+		free_irq(msi->irq, pcie);
+
+	for (i = 0; i < INT_PCI_MSI_NR; i++) {
+		irq = irq_find_mapping(msi->domain, i);
+		if (irq > 0)
+			irq_dispose_mapping(irq);
+	}
+
+	irq_domain_remove(msi->domain);
+
+	return 0;
+}
+
+static int tegra_pcie_get_xbar_config(struct tegra_pcie *pcie, u32 lanes,
+				      u32 *xbar)
+{
+	struct device_node *np = pcie->dev->of_node;
+
+	switch (lanes) {
+	case 0x00000004:
+		dev_info(pcie->dev, "single-mode configuration\n");
+		*xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE;
+		return 0;
+
+	case 0x00000202:
+		dev_info(pcie->dev, "dual-mode configuration\n");
+		*xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL;
+		return 0;
+	}
+
+	return -EINVAL;
+}
+
+static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
+{
+	struct device_node *np = pcie->dev->of_node, *port;
+	struct of_pci_range_parser parser;
+	struct of_pci_range range;
+	struct resource res;
+	u32 lanes = 0;
+	int err;
+
+	if (of_pci_range_parser_init(&parser, np)) {
+		dev_err(pcie->dev, "missing \"ranges\" property\n");
+		return -EINVAL;
+	}
+
+	pcie->vdd_supply = devm_regulator_get(pcie->dev, "vdd");
+	if (IS_ERR(pcie->vdd_supply))
+		return PTR_ERR(pcie->vdd_supply);
+
+	pcie->pex_clk_supply = devm_regulator_get(pcie->dev, "pex-clk");
+	if (IS_ERR(pcie->pex_clk_supply))
+		return PTR_ERR(pcie->pex_clk_supply);
+
+	for_each_of_pci_range(&parser, &range) {
+		of_pci_range_to_resource(&range, np, &res);
+
+		switch (res.flags & IORESOURCE_TYPE_BITS) {
+		case IORESOURCE_IO:
+			memcpy(&pcie->io, &res, sizeof(res));
+			pcie->io.name = "I/O";
+			break;
+
+		case IORESOURCE_MEM:
+			if (res.flags & IORESOURCE_PREFETCH) {
+				memcpy(&pcie->prefetch, &res, sizeof(res));
+				pcie->prefetch.name = "PREFETCH";
+			} else {
+				memcpy(&pcie->mem, &res, sizeof(res));
+				pcie->mem.name = "MEM";
+			}
+			break;
+		}
+	}
+
+	err = of_pci_parse_bus_range(np, &pcie->busn);
+	if (err < 0) {
+		dev_err(pcie->dev, "failed to parse ranges property: %d\n",
+			err);
+		pcie->busn.name = np->name;
+		pcie->busn.start = 0;
+		pcie->busn.end = 0xff;
+		pcie->busn.flags = IORESOURCE_BUS;
+	}
+
+	/* parse root ports */
+	for_each_child_of_node(np, port) {
+		struct tegra_pcie_port *rp;
+		unsigned int index;
+		u32 value;
+
+		err = of_pci_get_devfn(port);
+		if (err < 0) {
+			dev_err(pcie->dev, "failed to parse address: %d\n",
+				err);
+			return err;
+		}
+
+		index = PCI_SLOT(err);
+
+		if (index < 1 || index > TEGRA_MAX_PORTS) {
+			dev_err(pcie->dev, "invalid port number: %d\n", index);
+			return -EINVAL;
+		}
+
+		index--;
+
+		err = of_property_read_u32(port, "nvidia,num-lanes", &value);
+		if (err < 0) {
+			dev_err(pcie->dev, "failed to parse # of lanes: %d\n",
+				err);
+			return err;
+		}
+
+		if (value > 16) {
+			dev_err(pcie->dev, "invalid # of lanes: %u\n", value);
+			return -EINVAL;
+		}
+
+		lanes |= value << (index << 3);
+
+		if (!of_device_is_available(port))
+			continue;
+
+		rp = devm_kzalloc(pcie->dev, sizeof(*rp), GFP_KERNEL);
+		if (!rp)
+			return -ENOMEM;
+
+		err = of_address_to_resource(port, 0, &rp->regs);
+		if (err < 0) {
+			dev_err(pcie->dev, "failed to parse address: %d\n",
+				err);
+			return err;
+		}
+
+		INIT_LIST_HEAD(&rp->list);
+		rp->index = index;
+		rp->lanes = value;
+		rp->pcie = pcie;
+
+		rp->base = devm_request_and_ioremap(pcie->dev, &rp->regs);
+		if (!rp->base)
+			return -EADDRNOTAVAIL;
+
+		list_add_tail(&rp->list, &pcie->ports);
+	}
+
+	err = tegra_pcie_get_xbar_config(pcie, lanes, &pcie->xbar_config);
+	if (err < 0) {
+		dev_err(pcie->dev, "invalid lane configuration\n");
+		return err;
+	}
+
+	return 0;
+}
+
+/*
+ * FIXME: If there are no PCIe cards attached, then calling this function
+ * can result in the increase of the bootup time as there are big timeout
+ * loops.
+ */
+#define TEGRA_PCIE_LINKUP_TIMEOUT	200	/* up to 1.2 seconds */
+static bool tegra_pcie_port_check_link(struct tegra_pcie_port *port)
+{
+	unsigned int retries = 3;
+	unsigned long value;
+
+	do {
+		unsigned int timeout = TEGRA_PCIE_LINKUP_TIMEOUT;
+
+		do {
+			value = readl(port->base + RP_VEND_XP);
+
+			if (value & RP_VEND_XP_DL_UP)
+				break;
+
+			usleep_range(1000, 2000);
+		} while (--timeout);
+
+		if (!timeout) {
+			dev_err(port->pcie->dev, "link %u down, retrying\n",
+				port->index);
+			goto retry;
+		}
+
+		timeout = TEGRA_PCIE_LINKUP_TIMEOUT;
+
+		do {
+			value = readl(port->base + RP_LINK_CONTROL_STATUS);
+
+			if (value & RP_LINK_CONTROL_STATUS_DL_LINK_ACTIVE)
+				return true;
+
+			usleep_range(1000, 2000);
+		} while (--timeout);
+
+retry:
+		tegra_pcie_port_reset(port);
+	} while (--retries);
+
+	return false;
+}
+
+static int tegra_pcie_enable(struct tegra_pcie *pcie)
+{
+	struct tegra_pcie_port *port, *tmp;
+	struct hw_pci hw;
+
+	list_for_each_entry_safe(port, tmp, &pcie->ports, list) {
+		dev_info(pcie->dev, "probing port %u, using %u lanes\n",
+			 port->index, port->lanes);
+
+		tegra_pcie_port_enable(port);
+
+		if (tegra_pcie_port_check_link(port))
+			continue;
+
+		dev_info(pcie->dev, "link %u down, ignoring\n", port->index);
+
+		tegra_pcie_port_disable(port);
+		tegra_pcie_port_free(port);
+	}
+
+	memset(&hw, 0, sizeof(hw));
+
+	hw.nr_controllers = 1;
+	hw.private_data = (void **)&pcie;
+	hw.setup = tegra_pcie_setup;
+	hw.map_irq = tegra_pcie_map_irq;
+	hw.add_bus = tegra_pcie_add_bus;
+	hw.scan = tegra_pcie_scan_bus;
+	hw.ops = &tegra_pcie_ops;
+
+	pci_common_init_dev(pcie->dev, &hw);
+
+	return 0;
+}
+
+static int tegra_pcie_probe(struct platform_device *pdev)
+{
+	struct tegra_pcie *pcie;
+	int err;
+
+	pcie = devm_kzalloc(&pdev->dev, sizeof(*pcie), GFP_KERNEL);
+	if (!pcie)
+		return -ENOMEM;
+
+	INIT_LIST_HEAD(&pcie->busses);
+	INIT_LIST_HEAD(&pcie->ports);
+	pcie->dev = &pdev->dev;
+
+	err = tegra_pcie_parse_dt(pcie);
+	if (err < 0)
+		return err;
+
+	pcibios_min_mem = 0;
+
+	err = tegra_pcie_get_resources(pcie);
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to request resources: %d\n", err);
+		return err;
+	}
+
+	err = tegra_pcie_enable_controller(pcie);
+	if (err)
+		goto put_resources;
+
+	/* setup the AFI address translations */
+	tegra_pcie_setup_translations(pcie);
+
+	if (IS_ENABLED(CONFIG_PCI_MSI)) {
+		err = tegra_pcie_enable_msi(pcie);
+		if (err < 0) {
+			dev_err(&pdev->dev,
+				"failed to enable MSI support: %d\n",
+				err);
+			goto put_resources;
+		}
+	}
+
+	err = tegra_pcie_enable(pcie);
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to enable PCIe ports: %d\n", err);
+		goto disable_msi;
+	}
+
+	platform_set_drvdata(pdev, pcie);
+	return 0;
+
+disable_msi:
+	if (IS_ENABLED(CONFIG_PCI_MSI))
+		tegra_pcie_disable_msi(pcie);
+put_resources:
+	tegra_pcie_put_resources(pcie);
+	return err;
+}
+
+static const struct of_device_id tegra_pcie_of_match[] = {
+	{ .compatible = "nvidia,tegra20-pcie", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, tegra_pcie_of_match);
+
+static struct platform_driver tegra_pcie_driver = {
+	.driver = {
+		.name = "tegra-pcie",
+		.owner = THIS_MODULE,
+		.of_match_table = tegra_pcie_of_match,
+		.suppress_bind_attrs = true,
+	},
+	.probe = tegra_pcie_probe,
+};
+module_platform_driver(tegra_pcie_driver);
+
+MODULE_AUTHOR("Thierry Reding <treding at nvidia.com>");
+MODULE_DESCRIPTION("NVIDIA Tegra PCIe driver");
+MODULE_LICENSE("GPLv2");
-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:21 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:21 -0700
Subject: [PATCH v5 07/16] ARM: tegra: trimslice: Initialize PCIe from DT
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-8-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <thierry.reding at avionic-design.de>

With the device tree support in place, probe the PCIe controller from
the device tree and remove the corresponding workaround in the board
file.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
Changes in v2:
- add missing dummy regulator nodes by Stephen Warren
- rename port 0 DT node and disable unused port 1

 arch/arm/boot/dts/tegra20-trimslice.dts | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index ed4b901..9f1b237 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -310,6 +310,16 @@
 		nvidia,sys-clock-req-active-high;
 	};
 
+	pcie-controller {
+		status = "okay";
+		pex-clk-supply = <&pci_clk_reg>;
+		vdd-supply = <&pci_vdd_reg>;
+
+		pci at 1,0 {
+			status = "okay";
+		};
+	};
+
 	usb at c5000000 {
 		status = "okay";
 		nvidia,vbus-gpio = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH>;
@@ -413,6 +423,24 @@
 			enable-active-high;
 			gpio = <&gpio 170 0>; /* PV2 */
 		};
+
+		pci_clk_reg: regulator at 3 {
+			compatible = "regulator-fixed";
+			reg = <3>;
+			regulator-name = "pci_clk";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
+
+		pci_vdd_reg: regulator at 4 {
+			compatible = "regulator-fixed";
+			reg = <4>;
+			regulator-name = "pci_vdd";
+			regulator-min-microvolt = <1050000>;
+			regulator-max-microvolt = <1050000>;
+			regulator-always-on;
+		};
 	};
 
 	sound {
-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:22 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:22 -0700
Subject: [PATCH v5 08/16] PCI: tegra: Add Tegra 30 PCIe support
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-9-git-send-email-thierry.reding@gmail.com>

From: Jay Agarwal <jagarwal at nvidia.com>

Introduce a data structure to parameterize the driver according to SoC
generation, add Tegra30 specific code and update the device tree binding
document for Tegra30 support.

Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 .../bindings/pci/nvidia,tegra20-pcie.txt           |   4 +-
 drivers/pci/host/pci-tegra.c                       | 209 +++++++++++++++++----
 2 files changed, 179 insertions(+), 34 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
index 90c112f..6b75107 100644
--- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
@@ -1,7 +1,7 @@
 NVIDIA Tegra PCIe controller
 
 Required properties:
-- compatible: "nvidia,tegra20-pcie"
+- compatible: "nvidia,tegra20-pcie" or "nvidia,tegra30-pcie"
 - device_type: Must be "pci"
 - reg: A list of physical base address and length for each set of controller
   registers. Must contain an entry for each entry in the reg-names property.
@@ -16,6 +16,7 @@ Required properties:
   "msi": The Tegra interrupt that is asserted when an MSI is received
 - pex-clk-supply: Supply voltage for internal reference clock
 - vdd-supply: Power supply for controller (1.05V)
+- avdd-supply: Power supply for controller (1.05V) (not required for Tegra20)
 - bus-range: Range of bus numbers associated with this controller
 - #address-cells: Address representation for root ports (must be 3)
   - cell 0 specifies the bus and device numbers of the root port:
@@ -48,6 +49,7 @@ Required properties:
   "afi": The Tegra clock of that name
   "pcie_xclk": The Tegra clock of that name
   "pll_e": The Tegra clock of that name
+  "cml": The Tegra clock of that name (not required for Tegra20)
 
 Root ports are defined as subnodes of the PCIe controller node.
 
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 223069a..5347d7d 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -1,5 +1,5 @@
 /*
- * PCIe host controller driver for TEGRA(2) SOCs
+ * PCIe host controller driver for Tegra SoCs
  *
  * Copyright (c) 2010, CompuLab, Ltd.
  * Author: Mike Rapoport <mike at compulab.co.il>
@@ -51,7 +51,6 @@
 #include <asm/mach/pci.h>
 
 #define INT_PCI_MSI_NR (8 * 32)
-#define TEGRA_MAX_PORTS 2
 
 /* register definitions */
 
@@ -143,22 +142,30 @@
 #define  AFI_INTR_EN_DFPCI_DECERR	(1 << 5)
 #define  AFI_INTR_EN_AXI_DECERR		(1 << 6)
 #define  AFI_INTR_EN_FPCI_TIMEOUT	(1 << 7)
+#define  AFI_INTR_EN_PRSNT_SENSE	(1 << 8)
 
 #define AFI_PCIE_CONFIG					0x0f8
 #define  AFI_PCIE_CONFIG_PCIE_DISABLE(x)		(1 << ((x) + 1))
 #define  AFI_PCIE_CONFIG_PCIE_DISABLE_ALL		0xe
 #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK	(0xf << 20)
 #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE	(0x0 << 20)
+#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_420	(0x0 << 20)
 #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL	(0x1 << 20)
+#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_222	(0x1 << 20)
+#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_411	(0x2 << 20)
 
 #define AFI_FUSE			0x104
 #define  AFI_FUSE_PCIE_T0_GEN2_DIS	(1 << 2)
 
 #define AFI_PEX0_CTRL			0x110
 #define AFI_PEX1_CTRL			0x118
+#define AFI_PEX2_CTRL			0x128
 #define  AFI_PEX_CTRL_RST		(1 << 0)
+#define  AFI_PEX_CTRL_CLKREQ_EN		(1 << 1)
 #define  AFI_PEX_CTRL_REFCLK_EN		(1 << 3)
 
+#define AFI_PEXBIAS_CTRL_0		0x168
+
 #define RP_VEND_XP	0x00000F00
 #define  RP_VEND_XP_DL_UP	(1 << 30)
 
@@ -173,7 +180,8 @@
 #define  PADS_CTL_TX_DATA_EN_1L	(1 << 6)
 #define  PADS_CTL_RX_DATA_EN_1L	(1 << 10)
 
-#define PADS_PLL_CTL				0x000000B8
+#define PADS_PLL_CTL_TEGRA20			0x000000B8
+#define PADS_PLL_CTL_TEGRA30			0x000000B4
 #define  PADS_PLL_CTL_RST_B4SM			(1 << 1)
 #define  PADS_PLL_CTL_LOCKDET			(1 << 8)
 #define  PADS_PLL_CTL_REFCLK_MASK		(0x3 << 16)
@@ -183,6 +191,10 @@
 #define  PADS_PLL_CTL_TXCLKREF_MASK		(0x1 << 20)
 #define  PADS_PLL_CTL_TXCLKREF_DIV10		(0 << 20)
 #define  PADS_PLL_CTL_TXCLKREF_DIV5		(1 << 20)
+#define  PADS_PLL_CTL_TXCLKREF_BUF_EN		(1 << 22)
+
+#define PADS_REFCLK_CFG0			0x000000C8
+#define PADS_REFCLK_CFG1			0x000000CC
 
 struct tegra_msi {
 	struct msi_chip chip;
@@ -193,6 +205,19 @@ struct tegra_msi {
 	int irq;
 };
 
+/* used to differentiate between Tegra SoC generations */
+struct tegra_pcie_soc_data {
+	unsigned int num_ports;
+	unsigned int msi_base_shift;
+	u32 pads_pll_ctl;
+	u32 tx_ref_sel;
+	bool has_pex_clkreq_en;
+	bool has_pex_bias_ctrl;
+	bool has_intr_prsnt_sense;
+	bool has_avdd_supply;
+	bool has_cml_clk;
+};
+
 static inline struct tegra_msi *to_tegra_msi(struct msi_chip *chip)
 {
 	return container_of(chip, struct tegra_msi, chip);
@@ -217,6 +242,7 @@ struct tegra_pcie {
 	struct clk *afi_clk;
 	struct clk *pcie_xclk;
 	struct clk *pll_e;
+	struct clk *cml_clk;
 
 	struct tegra_msi msi;
 
@@ -226,6 +252,9 @@ struct tegra_pcie {
 
 	struct regulator *pex_clk_supply;
 	struct regulator *vdd_supply;
+	struct regulator *avdd_supply;
+
+	const struct tegra_pcie_soc_data *soc_data;
 };
 
 struct tegra_pcie_port {
@@ -470,6 +499,10 @@ static unsigned long tegra_pcie_port_get_pex_ctrl(struct tegra_pcie_port *port)
 	case 1:
 		ret = AFI_PEX1_CTRL;
 		break;
+
+	case 2:
+		ret = AFI_PEX2_CTRL;
+		break;
 	}
 
 	return ret;
@@ -494,12 +527,17 @@ static void tegra_pcie_port_reset(struct tegra_pcie_port *port)
 
 static void tegra_pcie_port_enable(struct tegra_pcie_port *port)
 {
+	const struct tegra_pcie_soc_data *soc = port->pcie->soc_data;
 	unsigned long ctrl = tegra_pcie_port_get_pex_ctrl(port);
 	unsigned long value;
 
 	/* enable reference clock */
 	value = afi_readl(port->pcie, ctrl);
 	value |= AFI_PEX_CTRL_REFCLK_EN;
+
+	if (soc->has_pex_clkreq_en)
+		value |= AFI_PEX_CTRL_CLKREQ_EN;
+
 	afi_writel(port->pcie, value, ctrl);
 
 	tegra_pcie_port_reset(port);
@@ -552,6 +590,8 @@ static void tegra_pcie_fixup_class(struct pci_dev *dev)
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf0, tegra_pcie_fixup_class);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf1, tegra_pcie_fixup_class);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0e1c, tegra_pcie_fixup_class);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0e1d, tegra_pcie_fixup_class);
 
 /* Tegra PCIE requires relaxed ordering */
 static void tegra_pcie_relax_enable(struct pci_dev *dev)
@@ -724,10 +764,15 @@ static void tegra_pcie_setup_translations(struct tegra_pcie *pcie)
 
 static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
 {
+	const struct tegra_pcie_soc_data *soc = pcie->soc_data;
 	struct tegra_pcie_port *port;
 	unsigned int timeout;
 	unsigned long value;
 
+	/* power down PCIe slot clock bias pad */
+	if (soc->has_pex_bias_ctrl)
+		afi_writel(pcie, 0, AFI_PEXBIAS_CTRL_0);
+
 	/* configure mode and disable all ports */
 	value = afi_readl(pcie, AFI_PCIE_CONFIG);
 	value &= ~AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK;
@@ -754,27 +799,26 @@ static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
 	 * Set up PHY PLL inputs select PLLE output as refclock,
 	 * set TX ref sel to div10 (not div5).
 	 */
-	value = pads_readl(pcie, PADS_PLL_CTL);
+	value = pads_readl(pcie, soc->pads_pll_ctl);
 	value &= ~(PADS_PLL_CTL_REFCLK_MASK | PADS_PLL_CTL_TXCLKREF_MASK);
-	value |= PADS_PLL_CTL_REFCLK_INTERNAL_CML |
-		 PADS_PLL_CTL_TXCLKREF_DIV10;
-	pads_writel(pcie, value, PADS_PLL_CTL);
+	value |= PADS_PLL_CTL_REFCLK_INTERNAL_CML | soc->tx_ref_sel;
+	pads_writel(pcie, value, soc->pads_pll_ctl);
 
 	/* take PLL out of reset  */
-	value = pads_readl(pcie, PADS_PLL_CTL);
+	value = pads_readl(pcie, soc->pads_pll_ctl);
 	value |= PADS_PLL_CTL_RST_B4SM;
-	pads_writel(pcie, value, PADS_PLL_CTL);
+	pads_writel(pcie, value, soc->pads_pll_ctl);
 
 	/*
 	 * Hack, set the clock voltage to the DEFAULT provided by hw folks.
 	 * This doesn't exist in the documentation.
 	 */
-	pads_writel(pcie, 0xfa5cfa5c, 0xc8);
+	pads_writel(pcie, 0xfa5cfa5c, PADS_REFCLK_CFG0);
 
 	/* wait for the PLL to lock */
 	timeout = 300;
 	do {
-		value = pads_readl(pcie, PADS_PLL_CTL);
+		value = pads_readl(pcie, soc->pads_pll_ctl);
 		usleep_range(1000, 2000);
 		if (--timeout == 0) {
 			pr_err("Tegra PCIe error: timeout waiting for PLL\n");
@@ -803,6 +847,10 @@ static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
 	value = AFI_INTR_EN_INI_SLVERR | AFI_INTR_EN_INI_DECERR |
 		AFI_INTR_EN_TGT_SLVERR | AFI_INTR_EN_TGT_DECERR |
 		AFI_INTR_EN_TGT_WRERR | AFI_INTR_EN_DFPCI_DECERR;
+
+	if (soc->has_intr_prsnt_sense)
+		value |= AFI_INTR_EN_PRSNT_SENSE;
+
 	afi_writel(pcie, value, AFI_AFI_INTR_ENABLE);
 	afi_writel(pcie, 0xffffffff, AFI_SM_INTR_ENABLE);
 
@@ -817,6 +865,7 @@ static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
 
 static void tegra_pcie_power_off(struct tegra_pcie *pcie)
 {
+	const struct tegra_pcie_soc_data *soc = pcie->soc_data;
 	int err;
 
 	/* TODO: disable and unprepare clocks? */
@@ -828,19 +877,28 @@ static void tegra_pcie_power_off(struct tegra_pcie *pcie)
 	tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
 	tegra_pmc_pcie_xclk_clamp(true);
 
+	if (soc->has_avdd_supply) {
+		err = regulator_disable(pcie->avdd_supply);
+		if (err < 0)
+			dev_warn(pcie->dev,
+				 "failed to disable AVDD regulator: %d\n",
+				 err);
+	}
+
 	err = regulator_disable(pcie->pex_clk_supply);
 	if (err < 0)
-		dev_err(pcie->dev, "failed to disable pex-clk regulator: %d\n",
-			err);
+		dev_warn(pcie->dev, "failed to disable pex-clk regulator: %d\n",
+			 err);
 
 	err = regulator_disable(pcie->vdd_supply);
 	if (err < 0)
-		dev_err(pcie->dev, "failed to disable VDD regulator: %d\n",
-			err);
+		dev_warn(pcie->dev, "failed to disable VDD regulator: %d\n",
+			 err);
 }
 
 static int tegra_pcie_power_on(struct tegra_pcie *pcie)
 {
+	const struct tegra_pcie_soc_data *soc = pcie->soc_data;
 	int err;
 
 	tegra_periph_reset_assert(pcie->pcie_xclk);
@@ -864,6 +922,16 @@ static int tegra_pcie_power_on(struct tegra_pcie *pcie)
 		return err;
 	}
 
+	if (soc->has_avdd_supply) {
+		err = regulator_enable(pcie->avdd_supply);
+		if (err < 0) {
+			dev_err(pcie->dev,
+				"failed to enable AVDD regulator: %d\n",
+				err);
+			return err;
+		}
+	}
+
 	err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_PCIE,
 						pcie->pex_clk);
 	if (err) {
@@ -881,6 +949,15 @@ static int tegra_pcie_power_on(struct tegra_pcie *pcie)
 		return err;
 	}
 
+	if (soc->has_cml_clk) {
+		err = clk_prepare_enable(pcie->cml_clk);
+		if (err < 0) {
+			dev_err(pcie->dev, "failed to enable CML clock: %d\n",
+				err);
+			return err;
+		}
+	}
+
 	err = clk_prepare_enable(pcie->pll_e);
 	if (err < 0) {
 		dev_err(pcie->dev, "failed to enable PLLE clock: %d\n", err);
@@ -892,6 +969,8 @@ static int tegra_pcie_power_on(struct tegra_pcie *pcie)
 
 static int tegra_pcie_clocks_get(struct tegra_pcie *pcie)
 {
+	const struct tegra_pcie_soc_data *soc = pcie->soc_data;
+
 	pcie->pex_clk = devm_clk_get(pcie->dev, "pex");
 	if (IS_ERR(pcie->pex_clk))
 		return PTR_ERR(pcie->pex_clk);
@@ -908,6 +987,12 @@ static int tegra_pcie_clocks_get(struct tegra_pcie *pcie)
 	if (IS_ERR(pcie->pll_e))
 		return PTR_ERR(pcie->pll_e);
 
+	if (soc->has_cml_clk) {
+		pcie->cml_clk = devm_clk_get(pcie->dev, "cml");
+		if (IS_ERR(pcie->cml_clk))
+			return PTR_ERR(pcie->cml_clk);
+	}
+
 	return 0;
 }
 
@@ -1132,6 +1217,7 @@ static const struct irq_domain_ops msi_domain_ops = {
 static int tegra_pcie_enable_msi(struct tegra_pcie *pcie)
 {
 	struct platform_device *pdev = to_platform_device(pcie->dev);
+	const struct tegra_pcie_soc_data *soc = pcie->soc_data;
 	struct tegra_msi *msi = &pcie->msi;
 	unsigned long base;
 	int err;
@@ -1169,7 +1255,7 @@ static int tegra_pcie_enable_msi(struct tegra_pcie *pcie)
 	msi->pages = __get_free_pages(GFP_KERNEL, 0);
 	base = virt_to_phys((void *)msi->pages);
 
-	afi_writel(pcie, base, AFI_MSI_FPCI_BAR_ST);
+	afi_writel(pcie, base >> soc->msi_base_shift, AFI_MSI_FPCI_BAR_ST);
 	afi_writel(pcie, base, AFI_MSI_AXI_BAR_ST);
 	/* this register is in 4K increments */
 	afi_writel(pcie, 1, AFI_MSI_BAR_SZ);
@@ -1238,16 +1324,35 @@ static int tegra_pcie_get_xbar_config(struct tegra_pcie *pcie, u32 lanes,
 {
 	struct device_node *np = pcie->dev->of_node;
 
-	switch (lanes) {
-	case 0x00000004:
-		dev_info(pcie->dev, "single-mode configuration\n");
-		*xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE;
-		return 0;
-
-	case 0x00000202:
-		dev_info(pcie->dev, "dual-mode configuration\n");
-		*xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL;
-		return 0;
+	if (of_device_is_compatible(np, "nvidia,tegra30-pcie")) {
+		switch (lanes) {
+		case 0x00000204:
+			dev_info(pcie->dev, "4x1, 2x1 configuration\n");
+			*xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_420;
+			return 0;
+
+		case 0x00020202:
+			dev_info(pcie->dev, "2x3 configuration\n");
+			*xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_222;
+			return 0;
+
+		case 0x00010104:
+			dev_info(pcie->dev, "4x1, 1x2 configuration\n");
+			*xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_411;
+			return 0;
+		}
+	} else if (of_device_is_compatible(np, "nvidia,tegra20-pcie")) {
+		switch (lanes) {
+		case 0x00000004:
+			dev_info(pcie->dev, "single-mode configuration\n");
+			*xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE;
+			return 0;
+
+		case 0x00000202:
+			dev_info(pcie->dev, "dual-mode configuration\n");
+			*xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL;
+			return 0;
+		}
 	}
 
 	return -EINVAL;
@@ -1255,6 +1360,7 @@ static int tegra_pcie_get_xbar_config(struct tegra_pcie *pcie, u32 lanes,
 
 static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
 {
+	const struct tegra_pcie_soc_data *soc = pcie->soc_data;
 	struct device_node *np = pcie->dev->of_node, *port;
 	struct of_pci_range_parser parser;
 	struct of_pci_range range;
@@ -1275,6 +1381,12 @@ static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
 	if (IS_ERR(pcie->pex_clk_supply))
 		return PTR_ERR(pcie->pex_clk_supply);
 
+	if (soc->has_avdd_supply) {
+		pcie->avdd_supply = devm_regulator_get(pcie->dev, "avdd");
+		if (IS_ERR(pcie->avdd_supply))
+			return PTR_ERR(pcie->avdd_supply);
+	}
+
 	for_each_of_pci_range(&parser, &range) {
 		of_pci_range_to_resource(&range, np, &res);
 
@@ -1321,7 +1433,7 @@ static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
 
 		index = PCI_SLOT(err);
 
-		if (index < 1 || index > TEGRA_MAX_PORTS) {
+		if (index < 1 || index > soc->num_ports) {
 			dev_err(pcie->dev, "invalid port number: %d\n", index);
 			return -EINVAL;
 		}
@@ -1459,17 +1571,54 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
 	return 0;
 }
 
+static const struct tegra_pcie_soc_data tegra20_pcie_data = {
+	.num_ports = 2,
+	.msi_base_shift = 0,
+	.pads_pll_ctl = PADS_PLL_CTL_TEGRA20,
+	.tx_ref_sel = PADS_PLL_CTL_TXCLKREF_DIV10,
+	.has_pex_clkreq_en = false,
+	.has_pex_bias_ctrl = false,
+	.has_intr_prsnt_sense = false,
+	.has_avdd_supply = false,
+	.has_cml_clk = false,
+};
+
+static const struct tegra_pcie_soc_data tegra30_pcie_data = {
+	.num_ports = 3,
+	.msi_base_shift = 8,
+	.pads_pll_ctl = PADS_PLL_CTL_TEGRA30,
+	.tx_ref_sel = PADS_PLL_CTL_TXCLKREF_BUF_EN,
+	.has_pex_clkreq_en = true,
+	.has_pex_bias_ctrl = true,
+	.has_intr_prsnt_sense = true,
+	.has_avdd_supply = true,
+	.has_cml_clk = true,
+};
+
+static const struct of_device_id tegra_pcie_of_match[] = {
+	{ .compatible = "nvidia,tegra30-pcie", .data = &tegra30_pcie_data },
+	{ .compatible = "nvidia,tegra20-pcie", .data = &tegra20_pcie_data },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, tegra_pcie_of_match);
+
 static int tegra_pcie_probe(struct platform_device *pdev)
 {
+	const struct of_device_id *match;
 	struct tegra_pcie *pcie;
 	int err;
 
+	match = of_match_device(tegra_pcie_of_match, &pdev->dev);
+	if (!match)
+		return -ENODEV;
+
 	pcie = devm_kzalloc(&pdev->dev, sizeof(*pcie), GFP_KERNEL);
 	if (!pcie)
 		return -ENOMEM;
 
 	INIT_LIST_HEAD(&pcie->busses);
 	INIT_LIST_HEAD(&pcie->ports);
+	pcie->soc_data = match->data;
 	pcie->dev = &pdev->dev;
 
 	err = tegra_pcie_parse_dt(pcie);
@@ -1518,12 +1667,6 @@ put_resources:
 	return err;
 }
 
-static const struct of_device_id tegra_pcie_of_match[] = {
-	{ .compatible = "nvidia,tegra20-pcie", },
-	{ },
-};
-MODULE_DEVICE_TABLE(of, tegra_pcie_of_match);
-
 static struct platform_driver tegra_pcie_driver = {
 	.driver = {
 		.name = "tegra-pcie",
-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:23 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:23 -0700
Subject: [PATCH v5 09/16] PCI: tegra: set up PADS_REFCLK_CFG1
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-10-git-send-email-thierry.reding@gmail.com>

From: Stephen Warren <swarren at nvidia.com>

The registers PADS_REFCLK_CFG are an array of 16-bit data, one entry per
PCIe root port. For Tegra30, we therefore need to write a 3rd entry in
this array. Doing so mays the mini-PCIe slot on Beaver operate correctly.

While we're at it, add some #defines to partially document the fields
within these 16-bit values.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 drivers/pci/host/pci-tegra.c | 29 ++++++++++++++++++++++++-----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 5347d7d..0c84c67 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -196,6 +196,25 @@
 #define PADS_REFCLK_CFG0			0x000000C8
 #define PADS_REFCLK_CFG1			0x000000CC
 
+/*
+ * Fields in PADS_REFCLK_CFG*. Those registers form an array of 16-bit
+ * entries, one entry per PCIe port. These field definitions and desired
+ * values aren't in the TRM, but do come from NVIDIA.
+ */
+#define PADS_REFCLK_CFG_TERM_SHIFT		2  /* 6:2 */
+#define PADS_REFCLK_CFG_E_TERM_SHIFT		7
+#define PADS_REFCLK_CFG_PREDI_SHIFT		8  /* 11:8 */
+#define PADS_REFCLK_CFG_DRVI_SHIFT		12 /* 15:12 */
+
+/* Default value provided by HW engineering is 0xfa5c */
+#define PADS_REFCLK_CFG_VALUE \
+	( \
+		(0x17 << PADS_REFCLK_CFG_TERM_SHIFT)   | \
+		(0    << PADS_REFCLK_CFG_E_TERM_SHIFT) | \
+		(0xa  << PADS_REFCLK_CFG_PREDI_SHIFT)  | \
+		(0xf  << PADS_REFCLK_CFG_DRVI_SHIFT)     \
+	)
+
 struct tegra_msi {
 	struct msi_chip chip;
 	DECLARE_BITMAP(used, INT_PCI_MSI_NR);
@@ -809,11 +828,11 @@ static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
 	value |= PADS_PLL_CTL_RST_B4SM;
 	pads_writel(pcie, value, soc->pads_pll_ctl);
 
-	/*
-	 * Hack, set the clock voltage to the DEFAULT provided by hw folks.
-	 * This doesn't exist in the documentation.
-	 */
-	pads_writel(pcie, 0xfa5cfa5c, PADS_REFCLK_CFG0);
+	/* Configure the reference clock driver */
+	value = PADS_REFCLK_CFG_VALUE | (PADS_REFCLK_CFG_VALUE << 16);
+	pads_writel(pcie, value, PADS_REFCLK_CFG0);
+	if (soc->num_ports > 2)
+		pads_writel(pcie, PADS_REFCLK_CFG_VALUE, PADS_REFCLK_CFG1);
 
 	/* wait for the PLL to lock */
 	timeout = 300;
-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:24 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:24 -0700
Subject: [PATCH v5 10/16] ARM: tegra: Add Tegra30 PCIe support
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-11-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Add the top-level pcie-controller node for the Tegra30 SoC. Tegra30 has
three root ports that can use different lane layouts.

Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
Changes in v5:
- use symbolic constants for interrupts and clocks

 arch/arm/boot/dts/tegra30.dtsi | 70 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index d8783f0..c8facca 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -16,6 +16,76 @@
 		serial4 = &uarte;
 	};
 
+	pcie-controller {
+		compatible = "nvidia,tegra30-pcie";
+		device_type = "pci";
+		reg = <0x00003000 0x00000800   /* PADS registers */
+		       0x00003800 0x00000200   /* AFI registers */
+		       0x10000000 0x10000000>; /* configuration space */
+		reg-names = "pads", "afi", "cs";
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH   /* controller interrupt */
+			      GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */
+		interrupt-names = "intr", "msi";
+
+		bus-range = <0x00 0xff>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+
+		ranges = <0x82000000 0 0x00000000 0x00000000 0 0x00001000   /* port 0 configuration space */
+			  0x82000000 0 0x00001000 0x00001000 0 0x00001000   /* port 1 configuration space */
+			  0x82000000 0 0x00004000 0x00004000 0 0x00001000   /* port 2 configuration space */
+			  0x81000000 0 0          0x02000000 0 0x00010000   /* downstream I/O */
+			  0x82000000 0 0x20000000 0x20000000 0 0x10000000   /* non-prefetchable memory */
+			  0xc2000000 0 0x30000000 0x30000000 0 0x10000000>; /* prefetchable memory */
+
+		clocks = <&tegra_car TEGRA30_CLK_PCIE>,
+			 <&tegra_car TEGRA30_CLK_AFI>,
+			 <&tegra_car TEGRA30_CLK_PCIEX>,
+			 <&tegra_car TEGRA30_CLK_PLL_E>,
+			 <&tegra_car TEGRA30_CLK_CML0>;
+		clock-names = "pex", "afi", "pcie_xclk", "pll_e", "cml";
+		status = "disabled";
+
+		pci at 1,0 {
+			device_type = "pci";
+			assigned-addresses = <0x82000800 0 0x00000000 0 0x1000>;
+			reg = <0x000800 0 0 0 0>;
+			status = "disabled";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+			ranges;
+
+			nvidia,num-lanes = <2>;
+		};
+
+		pci at 2,0 {
+			device_type = "pci";
+			assigned-addresses = <0x82001000 0 0x00001000 0 0x1000>;
+			reg = <0x001000 0 0 0 0>;
+			status = "disabled";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+			ranges;
+
+			nvidia,num-lanes = <2>;
+		};
+
+		pci at 3,0 {
+			device_type = "pci";
+			assigned-addresses = <0x82001800 0 0x00004000 0 0x1000>;
+			reg = <0x001800 0 0 0 0>;
+			status = "disabled";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+			ranges;
+
+			nvidia,num-lanes = <2>;
+		};
+	};
+
 	host1x {
 		compatible = "nvidia,tegra30-host1x", "simple-bus";
 		reg = <0x50000000 0x00024000>;
-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:25 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:25 -0700
Subject: [PATCH v5 11/16] ARM: tegra: Enable PCIe controller on Cardhu
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-12-git-send-email-thierry.reding@gmail.com>

From: Jay Agarwal <jagarwal at nvidia.com>

Root port 2 is routed to the bottom connector on Cardhu and is used by
the development dock to provide gigabit ethernet and USB functionality.

Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 arch/arm/boot/dts/tegra30-cardhu.dtsi | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index c011b67..ee8fff8 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -31,6 +31,26 @@
 		reg = <0x80000000 0x40000000>;
 	};
 
+	pcie-controller {
+		status = "okay";
+		pex-clk-supply = <&pex_hvdd_3v3_reg>;
+		vdd-supply = <&ldo1_reg>;
+		avdd-supply = <&ldo2_reg>;
+
+		pci at 1,0 {
+			nvidia,num-lanes = <4>;
+		};
+
+		pci at 2,0 {
+			nvidia,num-lanes = <1>;
+		};
+
+		pci at 3,0 {
+			status = "okay";
+			nvidia,num-lanes = <1>;
+		};
+	};
+
 	pinmux {
 		pinctrl-names = "default";
 		pinctrl-0 = <&state_default>;
-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:26 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:26 -0700
Subject: [PATCH v5 12/16] ARM: tegra: Enable PCIe controller on Beaver
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-13-git-send-email-thierry.reding@gmail.com>

PCIe lane 0 is connected to an onboard Gigabit Ethernet (RTL8168evl) and
lane 4 is routed to the board's miniPCIe slot.

Signed-off-by: Thierry Reding <thierry.reding at gmail.com>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 arch/arm/boot/dts/tegra30-beaver.dts | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index 87c5f7b..4d9fa31 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -10,6 +10,27 @@
 		reg = <0x80000000 0x7ff00000>;
 	};
 
+	pcie-controller {
+		status = "okay";
+		pex-clk-supply = <&sys_3v3_pexs_reg>;
+		vdd-supply = <&ldo1_reg>;
+		avdd-supply = <&ldo2_reg>;
+
+		pci at 1,0 {
+			status = "okay";
+			nvidia,num-lanes = <4>;
+		};
+
+		pci at 2,0 {
+			status = "okay";
+			nvidia,num-lanes = <1>;
+		};
+
+		pci at 3,0 {
+			nvidia,num-lanes = <1>;
+		};
+	};
+
 	pinmux {
 		pinctrl-names = "default";
 		pinctrl-0 = <&state_default>;
-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:27 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:27 -0700
Subject: [PATCH v5 13/16] ARM: tegra: Fix Beaver's PCIe lane configuration
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-14-git-send-email-thierry.reding@gmail.com>

From: Stephen Warren <swarren at nvidia.com>

Beaver's PCIe lane configuration most closely matches x2 x2 x2 rather
than x4 x1 x1, since clocks 0 and 2 are used, and lanes 0 and 5 are used,
and the only way those align is with a x2 x2 x2 configuration.

Also, disable root port 1; there's nothing connected to it. Root port 0
is the on-board PCIe Ethernet, and port 2 is the mini-PCIe slot.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 arch/arm/boot/dts/tegra30-beaver.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index 4d9fa31..e1dd644 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -18,16 +18,16 @@
 
 		pci at 1,0 {
 			status = "okay";
-			nvidia,num-lanes = <4>;
+			nvidia,num-lanes = <2>;
 		};
 
 		pci at 2,0 {
-			status = "okay";
-			nvidia,num-lanes = <1>;
+			nvidia,num-lanes = <2>;
 		};
 
 		pci at 3,0 {
-			nvidia,num-lanes = <1>;
+			status = "okay";
+			nvidia,num-lanes = <2>;
 		};
 	};
 
-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:28 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:28 -0700
Subject: [PATCH v5 14/16] ARM: tegra: Update default configuration (PCIe)
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-15-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Enable PCI and MSI support as well as the new Tegra PCIe controller
driver.

Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
Changes in v5:
- enable PCI Express support (CONFIG_PCIEPORTBUS)

 arch/arm/configs/tegra_defconfig | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 36ad70c..1586dda 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -27,8 +27,11 @@ CONFIG_ARCH_TEGRA=y
 CONFIG_ARCH_TEGRA_2x_SOC=y
 CONFIG_ARCH_TEGRA_3x_SOC=y
 CONFIG_ARCH_TEGRA_114_SOC=y
-CONFIG_TEGRA_PCI=y
 CONFIG_TEGRA_EMC_SCALING_ENABLE=y
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_PCI_TEGRA=y
+CONFIG_PCIEPORTBUS=y
 CONFIG_SMP=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
-- 
1.8.1.5



From Dave.Martin at arm.com  Thu Jul 25 13:54:56 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Thu, 25 Jul 2013 18:54:56 +0100
Subject: [PATCH 1/2] ARM: Correct BUG() assembly to ensure it is
 endian-agnostic
In-Reply-To: <51F14CAF.5010602@codethink.co.uk>
References: <1374763357-4893-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374763357-4893-2-git-send-email-ben.dooks@codethink.co.uk>
 <20130725155700.GD2546@localhost.localdomain>
 <51F14CAF.5010602@codethink.co.uk>
Message-ID: <20130725175456.GF2546@localhost.localdomain>

On Thu, Jul 25, 2013 at 05:05:03PM +0100, Ben Dooks wrote:
> On 25/07/13 16:57, Dave Martin wrote:
> >On Thu, Jul 25, 2013 at 03:42:36PM +0100, Ben Dooks wrote:
> >>Currently BUG() uses .word or .hword to create the necessary illegal
> >>instructions. However if we are building BE8 then these get swapped
> >>by the linker into different illegal instructions in the text.
> >
> >In the case of Thumb, the resulting instruction is actually not illegal,
> >which is even worse...
> >
> >>Change to using .inst and .inst.w to create the instructions and mark
> >>them as instructions so that the linker acts correctly.
> >>
> >>Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
> >>---
> >>  arch/arm/include/asm/bug.h |    4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
> >>index 7af5c6c..b95da52 100644
> >>--- a/arch/arm/include/asm/bug.h
> >>+++ b/arch/arm/include/asm/bug.h
> >>@@ -12,10 +12,10 @@
> >>   */
> >>  #ifdef CONFIG_THUMB2_KERNEL
> >>  #define BUG_INSTR_VALUE 0xde02
> >>-#define BUG_INSTR_TYPE ".hword "
> >>+#define BUG_INSTR_TYPE ".inst.w "
> >>  #else
> >>  #define BUG_INSTR_VALUE 0xe7f001f2
> >>-#define BUG_INSTR_TYPE ".word "
> >>+#define BUG_INSTR_TYPE ".inst "
> >>  #endif
> >
> >There was some uncertainty a while ago about precisely which versions of
> >gas support .inst.
> >
> ><asm/opcodes.h>  implements an abstracted workaround for this issue,
> >whereby you can emit instructions using the __inst*() macros, and
> >the swabbing and assembler directives should be generated for you.
> >
> >The patch below ought to do this for BUG(), but I've only briefly
> >build-tested it.
> >
> >
> >Note that the disassembly of the injected instructions in .o files
> >can be a bit confusing, because they are marked as data, do ld --be8
> >doesn't swab them (unlike the instructions, which do get swabbed).
> >objdump may also do extra swabbing during disassembly.
> >
> >You can sanity-check what is really in the image by dumping the text
> >section of vmlinux with objdump -s.
> >
> >
> >The change to<asm/opcodes.h>  is due to a missing include which is
> >really required for correctness, but which didn't show up without
> >the<asm/bug.h>  change (this causes opcodes.h to get included way
> >more often than is otherwise the case).
> >
> >Cheers
> >---Dave
> 
> Given it was added ~2006 according the mailing lists I have seen, then
> it should be ok to use for building modern kernels with. I think the
> use of .inst and .inst.w is a better solution than having the code
> having bits of it marked as data.

Of course it is.  But this discussion can be decoupled from bug.h:
if we decide to migrate to .inst, we can do that in one place in
opcodes.h, no?

Otherwise, we have multiple fixes to apply when we decide to make
that change.

Cheers
---Dave


From thierry.reding at gmail.com  Thu Jul 25 13:53:29 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:29 -0700
Subject: [PATCH v5 15/16] ARM: dts: tegra: Increase prefetchable PCI memory
 space
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-16-git-send-email-thierry.reding@gmail.com>

From: Jay Agarwal <jagarwal at nvidia.com>

Instead of evenly splitting the 512 MiB area between prefetchable and
non-prefetchable memory spaces, increase the prefetchable memory space
to 384 MiB while at the same time decreasing the non-prefetchable memory
space to 128 MiB. This is a more useful default as most PCIe devices
require more prefetchable than non-prefetchable memory.

Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
Tested-by: Stephen Warren <swarren at nvidia.com>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 arch/arm/boot/dts/tegra20.dtsi | 4 ++--
 arch/arm/boot/dts/tegra30.dtsi | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index ecd016a..3add9ac2 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -473,8 +473,8 @@
 		ranges = <0x82000000 0 0x80000000 0x80000000 0 0x00001000   /* port 0 registers */
 			  0x82000000 0 0x80001000 0x80001000 0 0x00001000   /* port 1 registers */
 			  0x81000000 0 0          0x82000000 0 0x00010000   /* downstream I/O */
-			  0x82000000 0 0xa0000000 0xa0000000 0 0x10000000   /* non-prefetchable memory */
-			  0xc2000000 0 0xb0000000 0xb0000000 0 0x10000000>; /* prefetchable memory */
+			  0x82000000 0 0xa0000000 0xa0000000 0 0x08000000   /* non-prefetchable memory */
+			  0xc2000000 0 0xa8000000 0xa8000000 0 0x18000000>; /* prefetchable memory */
 
 		clocks = <&tegra_car TEGRA20_CLK_PEX>,
 			 <&tegra_car TEGRA20_CLK_AFI>,
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index c8facca..d81c52e 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -35,8 +35,8 @@
 			  0x82000000 0 0x00001000 0x00001000 0 0x00001000   /* port 1 configuration space */
 			  0x82000000 0 0x00004000 0x00004000 0 0x00001000   /* port 2 configuration space */
 			  0x81000000 0 0          0x02000000 0 0x00010000   /* downstream I/O */
-			  0x82000000 0 0x20000000 0x20000000 0 0x10000000   /* non-prefetchable memory */
-			  0xc2000000 0 0x30000000 0x30000000 0 0x10000000>; /* prefetchable memory */
+			  0x82000000 0 0x20000000 0x20000000 0 0x08000000   /* non-prefetchable memory */
+			  0xc2000000 0 0x28000000 0x28000000 0 0x18000000>; /* prefetchable memory */
 
 		clocks = <&tegra_car TEGRA30_CLK_PCIE>,
 			 <&tegra_car TEGRA30_CLK_AFI>,
-- 
1.8.1.5



From thierry.reding at gmail.com  Thu Jul 25 13:53:30 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 10:53:30 -0700
Subject: [PATCH v5 16/16] MAINTAINERS: Add myself as Tegra PCIe maintainer
In-Reply-To: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1374774810-18459-17-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

I'll be taking on maintainership of the Tegra PCIe driver since it's now
moved out of arch/arm/mach-tegra.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1dd9bf0..e32db7d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6271,6 +6271,13 @@ F:	Documentation/PCI/
 F:	drivers/pci/
 F:	include/linux/pci*
 
+PCI DRIVER FOR NVIDIA TEGRA
+M:	Thierry Reding <thierry.reding at gmail.com>
+L:	linux-tegra at vger.kernel.org
+S:	Supported
+F:	Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
+F:	drivers/pci/host/pci-tegra.c
+
 PCMCIA SUBSYSTEM
 P:	Linux PCMCIA Team
 L:	linux-pcmcia at lists.infradead.org
-- 
1.8.1.5



From sboyd at codeaurora.org  Thu Jul 25 13:55:44 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Jul 2013 10:55:44 -0700
Subject: [PATCH 4/6] ARM: locks: prefetch the destination word for write
 prior to strex
In-Reply-To: <20130725174555.GK12827@mudshark.cambridge.arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-5-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231609170.15022@syhkavp.arg>
 <20130724111841.GD11072@mudshark.cambridge.arm.com>
 <51F160EA.6030800@codeaurora.org> <51F1626C.3050008@codeaurora.org>
 <20130725174555.GK12827@mudshark.cambridge.arm.com>
Message-ID: <51F166A0.7030203@codeaurora.org>

On 07/25/13 10:45, Will Deacon wrote:
> On Thu, Jul 25, 2013 at 06:37:48PM +0100, Stephen Boyd wrote:
>> On 07/25/13 10:31, Stephen Boyd wrote:
>>> On 07/24/13 04:18, Will Deacon wrote:
>>>> On Tue, Jul 23, 2013 at 09:10:33PM +0100, Nicolas Pitre wrote:
>>>>> On Tue, 23 Jul 2013, Will Deacon wrote:
>>>>>
>>>>>> The cost of changing a cacheline from shared to exclusive state can be
>>>>>> significant, especially when this is triggered by an exclusive store,
>>>>>> since it may result in having to retry the transaction.
>>>>>>
>>>>>> This patch prefixes our {spin,read,write}_[try]lock implementations with
>>>>>> pldw instructions (on CPUs which support them) to try and grab the line
>>>>>> in exclusive state from the start.
>>>>>>
>>>>>> Signed-off-by: Will Deacon <will.deacon at arm.com>
>>>>>> ---
>>>>>>  arch/arm/include/asm/spinlock.h | 9 ++++++++-
>>>>>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
>>>>>> index 0de7bec..3e1cc9d 100644
>>>>>> --- a/arch/arm/include/asm/spinlock.h
>>>>>> +++ b/arch/arm/include/asm/spinlock.h
>>>>>> @@ -5,7 +5,7 @@
>>>>>>  #error SMP not supported on pre-ARMv6 CPUs
>>>>>>  #endif
>>>>>>  
>>>>>> -#include <asm/processor.h>
>>>>>> +#include <linux/prefetch.h>
>>>>>>  
>>>>>>  /*
>>>>>>   * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
>>>>>> @@ -70,6 +70,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
>>>>>>  	u32 newval;
>>>>>>  	arch_spinlock_t lockval;
>>>>>>  
>>>>>> +	prefetchw((const void *)&lock->slock);
>>>>> Couldn't that cast be carried in the definition of prefetchw() instead?
>>>> I think that would mean implementing prefetchw as a macro rather than an
>>>> inline function, since the core code expects to pass a const pointer and GCC
>>>> gets angry if the type signatures don't match.
>>> Maybe I'm wrong, but can't you just remove the casts and leave the
>>> function as static inline? const void * is pretty much telling the
>>> compiler to turn off type checking.
>>>
>> Oh joy. Why is rwlock's lock member marked volatile?
> Yeah, that was the problematic guy. However, I had to fix that anyway in
> this patch because otherwise the definition for prefetchw when
> !ARCH_HAS_PREFETCHW (which expands to __builtin_prefetch(x,1)) will explode.
>
> So, given that I've fixed the rwlocks, I think I could put prefetch and
> prefetchw back to static inline functions. What do you reckon?

It would be good to match the builtin function's signature so that we
don't explode in the future on ARCH_HAS_PREFETCHW configs.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From mark.rutland at arm.com  Thu Jul 25 13:57:02 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 25 Jul 2013 18:57:02 +0100
Subject: DT bindings as ABI [was: Do we have people interested in
 device tree janitoring / cleanup?]
In-Reply-To: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
Message-ID: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>

Hi Olof,

[Adding the other new dt bindings maintainers to Cc]

On Thu, Jul 25, 2013 at 05:09:19PM +0100, Olof Johansson wrote:
> [I'm adding LKML and ksummit-discuss to this thread, since the ACPI/DT
> discussions have been covered there and this overlaps some with that]
> 
> On Thu, Jul 25, 2013 at 7:38 AM, Catalin Marinas
> <catalin.marinas at arm.com> wrote:
> > On Thu, Jul 25, 2013 at 03:27:02PM +0100, Russell King - ARM Linux wrote:
> >> Remember the stated assertion when DT was first added to the kernel: the
> >> DT descriptions _will_ become a separately maintained project which is
> >> independent of the kernel.  They will _not_ be kernel version specific.
> >
> > I'm looking forward to this.
> >
> > Question for the DT guys: what are the plans here? Are we going to get
> > rid of the .dts files inside the kernel tree?
> 
> In the discussions we had in Dublin, a couple of options on how to
> lock in bindings were discussed. I'm a little surprised that Grant
> didn't cover them in his initial emails on the new maintainership
> model, but maybe he wanted the new group to handle it. And they didn't
> bring it up yet either. So I am. :-)

Apologies for the delay on this, thanks for bringing it up. We certainly
need a kick regarding this.

> 
> Until now, we have been working under the assumption that the bindings
> are _NOT LOCKED_. I.e. they can change as needed, and we _ARE_
> assuming that the device tree has to match the kernel. That has been a
> good choice as people get up to speed on what is a good binding and
> not, and has given us much-needed room to adjust things as needed.
> That obviously has to change, but doing so needs to be done carefully.

While it's been the most natural way for us kernel folk to build the
necessary infrastructure and adapt to the new way of doing things, as
Dave and Russell pointed out in the original thread [1], we've blindly
walked into building a horrible ABI for ourselves. With KVM we've also
exposed this ABI to userspace...

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/186114.html

> 
> It's likely that we still want to have a period in which a binding is
> tentative and can be changed. Sometimes we don't know what we really
> want until after we've used it a while, and sometimes we, like
> everybody else, make mistakes on what is a good idea and not. The
> alternative is to grind most new binding proposals to a halt while we
> spend mind-numbing hours and hours on polishing every single aspect of
> the binding to a perfect shine, since we can't go back and fix it.
> 
> So, there really seems to be a need for a layered approach, one in
> which a binding "graduates" from being tentative to being locked in.
> I'm refraining from using the terms "staging" and "stable" here, since
> they have overloaded meaning in the kernel world that doesn't apply
> here.

I'm not sure how realistic it is to have drivers in the kernel using
unstable bindings, and expect people to not rely on them, but I don't
have a better option to give. We need a big fat warning that an unstable
binding is in use.

> 
> One problem that needs to be solved is obviously how a binding
> graduates from tentative to locked. This work isn't going to be very
> interesting to most people, I suspect. Think standards committee type
> work.
> 
> A possible way to handle this is to have exactly that: A group of
> people that essentially constitute the "standards committee" that meet
> on a regular basis to review and approve new bindings. They should be
> people not just doing ARM Linux work, but other stakeholders in these
> bindings too. One of the things they should probably do is sift
> through our current in-kernel bindings and select those who seem ready
> to be locked in, review/discuss/decide upon that and once the decision
> is made, that specific binding does become part of the static,
> never-ever-change ABI of firmware-to-kernel interfaces.   That might
> also be the time that the binding is moved from the kernel to a
> separate repo, but that's a technicality that we'll let the DT
> maintainers decide among themselves, IMHO.

We're going to need input from other OSs too, or the bindings will
remain Linux-specific regardless of how far away the bindings and dts
repo(s) is/are.

I'd be happy with a Linux-specific unstable binding and an accepted,
stable binding documented externally, that gives people the most freedom
to prototype while keeping stable and unstable bindings clearly
separated.

> 
> I think that captures most of what we discussed in person. Others
> might have changed their opinions since then, so I'm definitely not
> claiming that any of this was an official decision made by anybody.
> It's just one proposal on how to handle these things moving forward.

I think you've got the gist of it. 

How about the following:

* We reach out to other users of devicetree, and attempt to form the
  standards/review commitee.

* At v3.11, we pull (a copy of?) all binding documents out of the
  kernel, into an 'unstable/linux bindings' repo. 

* The minimal set of 'stable' bindings (e.g. those having been used for
  years without modification by powerpc) will be moved to a stable repo
  after consensus from the committee, and developers outside of the
  committee using said bindings. Hopefully there will be no showstoppers
  here. These should contain no Linux-specific information.

  Those bindings that have been modified recently or are in areas where
  there is currently heavy churn will not be marked stable.

* We attempt to graduate bindings to stable, once the appropriate
  infrastructure is in place to prove the concept, preferably with
  bindings for similar devices from different vendors.

Thoughts?

Thanks,
Mark.


From swarren at wwwdotorg.org  Thu Jul 25 13:59:08 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 25 Jul 2013 10:59:08 -0700
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
Message-ID: <51F1676C.5050408@wwwdotorg.org>

On 07/25/2013 09:09 AM, Olof Johansson wrote:
...
> One problem that needs to be solved is obviously how a binding
> graduates from tentative to locked. This work isn't going to be very
> interesting to most people, I suspect. Think standards committee type
> work.

I assume that's part of what being a maintainer of the DT bindings tree
means?

+1 on everything else you said. I've been traveling this week so haven't
had much time for email, but if I hadn't, I hope I would have said
something similar:-)


From bhelgaas at google.com  Thu Jul 25 14:00:42 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Thu, 25 Jul 2013 12:00:42 -0600
Subject: [PATCH v5 08/16] PCI: tegra: Add Tegra 30 PCIe support
In-Reply-To: <1374774810-18459-9-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
 <1374774810-18459-9-git-send-email-thierry.reding@gmail.com>
Message-ID: <CAErSpo7hcuqGcaYZCLa72Kavq-LVUP=HOPkWXDDj=cgP+LfT9g@mail.gmail.com>

On Thu, Jul 25, 2013 at 11:53 AM, Thierry Reding
<thierry.reding at gmail.com> wrote:
> From: Jay Agarwal <jagarwal at nvidia.com>
>
> Introduce a data structure to parameterize the driver according to SoC
> generation, add Tegra30 specific code and update the device tree binding
> document for Tegra30 support.
>
> Signed-off-by: Jay Agarwal <jagarwal at nvidia.com>
> Signed-off-by: Thierry Reding <treding at nvidia.com>

Acked-by: Bjorn Helgaas <bhelgaas at google.com>

> ---
>  .../bindings/pci/nvidia,tegra20-pcie.txt           |   4 +-
>  drivers/pci/host/pci-tegra.c                       | 209 +++++++++++++++++----
>  2 files changed, 179 insertions(+), 34 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
> index 90c112f..6b75107 100644
> --- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
> @@ -1,7 +1,7 @@
>  NVIDIA Tegra PCIe controller
>
>  Required properties:
> -- compatible: "nvidia,tegra20-pcie"
> +- compatible: "nvidia,tegra20-pcie" or "nvidia,tegra30-pcie"
>  - device_type: Must be "pci"
>  - reg: A list of physical base address and length for each set of controller
>    registers. Must contain an entry for each entry in the reg-names property.
> @@ -16,6 +16,7 @@ Required properties:
>    "msi": The Tegra interrupt that is asserted when an MSI is received
>  - pex-clk-supply: Supply voltage for internal reference clock
>  - vdd-supply: Power supply for controller (1.05V)
> +- avdd-supply: Power supply for controller (1.05V) (not required for Tegra20)
>  - bus-range: Range of bus numbers associated with this controller
>  - #address-cells: Address representation for root ports (must be 3)
>    - cell 0 specifies the bus and device numbers of the root port:
> @@ -48,6 +49,7 @@ Required properties:
>    "afi": The Tegra clock of that name
>    "pcie_xclk": The Tegra clock of that name
>    "pll_e": The Tegra clock of that name
> +  "cml": The Tegra clock of that name (not required for Tegra20)
>
>  Root ports are defined as subnodes of the PCIe controller node.
>
> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> index 223069a..5347d7d 100644
> --- a/drivers/pci/host/pci-tegra.c
> +++ b/drivers/pci/host/pci-tegra.c
> @@ -1,5 +1,5 @@
>  /*
> - * PCIe host controller driver for TEGRA(2) SOCs
> + * PCIe host controller driver for Tegra SoCs
>   *
>   * Copyright (c) 2010, CompuLab, Ltd.
>   * Author: Mike Rapoport <mike at compulab.co.il>
> @@ -51,7 +51,6 @@
>  #include <asm/mach/pci.h>
>
>  #define INT_PCI_MSI_NR (8 * 32)
> -#define TEGRA_MAX_PORTS 2
>
>  /* register definitions */
>
> @@ -143,22 +142,30 @@
>  #define  AFI_INTR_EN_DFPCI_DECERR      (1 << 5)
>  #define  AFI_INTR_EN_AXI_DECERR                (1 << 6)
>  #define  AFI_INTR_EN_FPCI_TIMEOUT      (1 << 7)
> +#define  AFI_INTR_EN_PRSNT_SENSE       (1 << 8)
>
>  #define AFI_PCIE_CONFIG                                        0x0f8
>  #define  AFI_PCIE_CONFIG_PCIE_DISABLE(x)               (1 << ((x) + 1))
>  #define  AFI_PCIE_CONFIG_PCIE_DISABLE_ALL              0xe
>  #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK      (0xf << 20)
>  #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE    (0x0 << 20)
> +#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_420       (0x0 << 20)
>  #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL      (0x1 << 20)
> +#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_222       (0x1 << 20)
> +#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_411       (0x2 << 20)
>
>  #define AFI_FUSE                       0x104
>  #define  AFI_FUSE_PCIE_T0_GEN2_DIS     (1 << 2)
>
>  #define AFI_PEX0_CTRL                  0x110
>  #define AFI_PEX1_CTRL                  0x118
> +#define AFI_PEX2_CTRL                  0x128
>  #define  AFI_PEX_CTRL_RST              (1 << 0)
> +#define  AFI_PEX_CTRL_CLKREQ_EN                (1 << 1)
>  #define  AFI_PEX_CTRL_REFCLK_EN                (1 << 3)
>
> +#define AFI_PEXBIAS_CTRL_0             0x168
> +
>  #define RP_VEND_XP     0x00000F00
>  #define  RP_VEND_XP_DL_UP      (1 << 30)
>
> @@ -173,7 +180,8 @@
>  #define  PADS_CTL_TX_DATA_EN_1L        (1 << 6)
>  #define  PADS_CTL_RX_DATA_EN_1L        (1 << 10)
>
> -#define PADS_PLL_CTL                           0x000000B8
> +#define PADS_PLL_CTL_TEGRA20                   0x000000B8
> +#define PADS_PLL_CTL_TEGRA30                   0x000000B4
>  #define  PADS_PLL_CTL_RST_B4SM                 (1 << 1)
>  #define  PADS_PLL_CTL_LOCKDET                  (1 << 8)
>  #define  PADS_PLL_CTL_REFCLK_MASK              (0x3 << 16)
> @@ -183,6 +191,10 @@
>  #define  PADS_PLL_CTL_TXCLKREF_MASK            (0x1 << 20)
>  #define  PADS_PLL_CTL_TXCLKREF_DIV10           (0 << 20)
>  #define  PADS_PLL_CTL_TXCLKREF_DIV5            (1 << 20)
> +#define  PADS_PLL_CTL_TXCLKREF_BUF_EN          (1 << 22)
> +
> +#define PADS_REFCLK_CFG0                       0x000000C8
> +#define PADS_REFCLK_CFG1                       0x000000CC
>
>  struct tegra_msi {
>         struct msi_chip chip;
> @@ -193,6 +205,19 @@ struct tegra_msi {
>         int irq;
>  };
>
> +/* used to differentiate between Tegra SoC generations */
> +struct tegra_pcie_soc_data {
> +       unsigned int num_ports;
> +       unsigned int msi_base_shift;
> +       u32 pads_pll_ctl;
> +       u32 tx_ref_sel;
> +       bool has_pex_clkreq_en;
> +       bool has_pex_bias_ctrl;
> +       bool has_intr_prsnt_sense;
> +       bool has_avdd_supply;
> +       bool has_cml_clk;
> +};
> +
>  static inline struct tegra_msi *to_tegra_msi(struct msi_chip *chip)
>  {
>         return container_of(chip, struct tegra_msi, chip);
> @@ -217,6 +242,7 @@ struct tegra_pcie {
>         struct clk *afi_clk;
>         struct clk *pcie_xclk;
>         struct clk *pll_e;
> +       struct clk *cml_clk;
>
>         struct tegra_msi msi;
>
> @@ -226,6 +252,9 @@ struct tegra_pcie {
>
>         struct regulator *pex_clk_supply;
>         struct regulator *vdd_supply;
> +       struct regulator *avdd_supply;
> +
> +       const struct tegra_pcie_soc_data *soc_data;
>  };
>
>  struct tegra_pcie_port {
> @@ -470,6 +499,10 @@ static unsigned long tegra_pcie_port_get_pex_ctrl(struct tegra_pcie_port *port)
>         case 1:
>                 ret = AFI_PEX1_CTRL;
>                 break;
> +
> +       case 2:
> +               ret = AFI_PEX2_CTRL;
> +               break;
>         }
>
>         return ret;
> @@ -494,12 +527,17 @@ static void tegra_pcie_port_reset(struct tegra_pcie_port *port)
>
>  static void tegra_pcie_port_enable(struct tegra_pcie_port *port)
>  {
> +       const struct tegra_pcie_soc_data *soc = port->pcie->soc_data;
>         unsigned long ctrl = tegra_pcie_port_get_pex_ctrl(port);
>         unsigned long value;
>
>         /* enable reference clock */
>         value = afi_readl(port->pcie, ctrl);
>         value |= AFI_PEX_CTRL_REFCLK_EN;
> +
> +       if (soc->has_pex_clkreq_en)
> +               value |= AFI_PEX_CTRL_CLKREQ_EN;
> +
>         afi_writel(port->pcie, value, ctrl);
>
>         tegra_pcie_port_reset(port);
> @@ -552,6 +590,8 @@ static void tegra_pcie_fixup_class(struct pci_dev *dev)
>  }
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf0, tegra_pcie_fixup_class);
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf1, tegra_pcie_fixup_class);
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0e1c, tegra_pcie_fixup_class);
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0e1d, tegra_pcie_fixup_class);
>
>  /* Tegra PCIE requires relaxed ordering */
>  static void tegra_pcie_relax_enable(struct pci_dev *dev)
> @@ -724,10 +764,15 @@ static void tegra_pcie_setup_translations(struct tegra_pcie *pcie)
>
>  static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
>  {
> +       const struct tegra_pcie_soc_data *soc = pcie->soc_data;
>         struct tegra_pcie_port *port;
>         unsigned int timeout;
>         unsigned long value;
>
> +       /* power down PCIe slot clock bias pad */
> +       if (soc->has_pex_bias_ctrl)
> +               afi_writel(pcie, 0, AFI_PEXBIAS_CTRL_0);
> +
>         /* configure mode and disable all ports */
>         value = afi_readl(pcie, AFI_PCIE_CONFIG);
>         value &= ~AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_MASK;
> @@ -754,27 +799,26 @@ static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
>          * Set up PHY PLL inputs select PLLE output as refclock,
>          * set TX ref sel to div10 (not div5).
>          */
> -       value = pads_readl(pcie, PADS_PLL_CTL);
> +       value = pads_readl(pcie, soc->pads_pll_ctl);
>         value &= ~(PADS_PLL_CTL_REFCLK_MASK | PADS_PLL_CTL_TXCLKREF_MASK);
> -       value |= PADS_PLL_CTL_REFCLK_INTERNAL_CML |
> -                PADS_PLL_CTL_TXCLKREF_DIV10;
> -       pads_writel(pcie, value, PADS_PLL_CTL);
> +       value |= PADS_PLL_CTL_REFCLK_INTERNAL_CML | soc->tx_ref_sel;
> +       pads_writel(pcie, value, soc->pads_pll_ctl);
>
>         /* take PLL out of reset  */
> -       value = pads_readl(pcie, PADS_PLL_CTL);
> +       value = pads_readl(pcie, soc->pads_pll_ctl);
>         value |= PADS_PLL_CTL_RST_B4SM;
> -       pads_writel(pcie, value, PADS_PLL_CTL);
> +       pads_writel(pcie, value, soc->pads_pll_ctl);
>
>         /*
>          * Hack, set the clock voltage to the DEFAULT provided by hw folks.
>          * This doesn't exist in the documentation.
>          */
> -       pads_writel(pcie, 0xfa5cfa5c, 0xc8);
> +       pads_writel(pcie, 0xfa5cfa5c, PADS_REFCLK_CFG0);
>
>         /* wait for the PLL to lock */
>         timeout = 300;
>         do {
> -               value = pads_readl(pcie, PADS_PLL_CTL);
> +               value = pads_readl(pcie, soc->pads_pll_ctl);
>                 usleep_range(1000, 2000);
>                 if (--timeout == 0) {
>                         pr_err("Tegra PCIe error: timeout waiting for PLL\n");
> @@ -803,6 +847,10 @@ static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
>         value = AFI_INTR_EN_INI_SLVERR | AFI_INTR_EN_INI_DECERR |
>                 AFI_INTR_EN_TGT_SLVERR | AFI_INTR_EN_TGT_DECERR |
>                 AFI_INTR_EN_TGT_WRERR | AFI_INTR_EN_DFPCI_DECERR;
> +
> +       if (soc->has_intr_prsnt_sense)
> +               value |= AFI_INTR_EN_PRSNT_SENSE;
> +
>         afi_writel(pcie, value, AFI_AFI_INTR_ENABLE);
>         afi_writel(pcie, 0xffffffff, AFI_SM_INTR_ENABLE);
>
> @@ -817,6 +865,7 @@ static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
>
>  static void tegra_pcie_power_off(struct tegra_pcie *pcie)
>  {
> +       const struct tegra_pcie_soc_data *soc = pcie->soc_data;
>         int err;
>
>         /* TODO: disable and unprepare clocks? */
> @@ -828,19 +877,28 @@ static void tegra_pcie_power_off(struct tegra_pcie *pcie)
>         tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
>         tegra_pmc_pcie_xclk_clamp(true);
>
> +       if (soc->has_avdd_supply) {
> +               err = regulator_disable(pcie->avdd_supply);
> +               if (err < 0)
> +                       dev_warn(pcie->dev,
> +                                "failed to disable AVDD regulator: %d\n",
> +                                err);
> +       }
> +
>         err = regulator_disable(pcie->pex_clk_supply);
>         if (err < 0)
> -               dev_err(pcie->dev, "failed to disable pex-clk regulator: %d\n",
> -                       err);
> +               dev_warn(pcie->dev, "failed to disable pex-clk regulator: %d\n",
> +                        err);
>
>         err = regulator_disable(pcie->vdd_supply);
>         if (err < 0)
> -               dev_err(pcie->dev, "failed to disable VDD regulator: %d\n",
> -                       err);
> +               dev_warn(pcie->dev, "failed to disable VDD regulator: %d\n",
> +                        err);
>  }
>
>  static int tegra_pcie_power_on(struct tegra_pcie *pcie)
>  {
> +       const struct tegra_pcie_soc_data *soc = pcie->soc_data;
>         int err;
>
>         tegra_periph_reset_assert(pcie->pcie_xclk);
> @@ -864,6 +922,16 @@ static int tegra_pcie_power_on(struct tegra_pcie *pcie)
>                 return err;
>         }
>
> +       if (soc->has_avdd_supply) {
> +               err = regulator_enable(pcie->avdd_supply);
> +               if (err < 0) {
> +                       dev_err(pcie->dev,
> +                               "failed to enable AVDD regulator: %d\n",
> +                               err);
> +                       return err;
> +               }
> +       }
> +
>         err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_PCIE,
>                                                 pcie->pex_clk);
>         if (err) {
> @@ -881,6 +949,15 @@ static int tegra_pcie_power_on(struct tegra_pcie *pcie)
>                 return err;
>         }
>
> +       if (soc->has_cml_clk) {
> +               err = clk_prepare_enable(pcie->cml_clk);
> +               if (err < 0) {
> +                       dev_err(pcie->dev, "failed to enable CML clock: %d\n",
> +                               err);
> +                       return err;
> +               }
> +       }
> +
>         err = clk_prepare_enable(pcie->pll_e);
>         if (err < 0) {
>                 dev_err(pcie->dev, "failed to enable PLLE clock: %d\n", err);
> @@ -892,6 +969,8 @@ static int tegra_pcie_power_on(struct tegra_pcie *pcie)
>
>  static int tegra_pcie_clocks_get(struct tegra_pcie *pcie)
>  {
> +       const struct tegra_pcie_soc_data *soc = pcie->soc_data;
> +
>         pcie->pex_clk = devm_clk_get(pcie->dev, "pex");
>         if (IS_ERR(pcie->pex_clk))
>                 return PTR_ERR(pcie->pex_clk);
> @@ -908,6 +987,12 @@ static int tegra_pcie_clocks_get(struct tegra_pcie *pcie)
>         if (IS_ERR(pcie->pll_e))
>                 return PTR_ERR(pcie->pll_e);
>
> +       if (soc->has_cml_clk) {
> +               pcie->cml_clk = devm_clk_get(pcie->dev, "cml");
> +               if (IS_ERR(pcie->cml_clk))
> +                       return PTR_ERR(pcie->cml_clk);
> +       }
> +
>         return 0;
>  }
>
> @@ -1132,6 +1217,7 @@ static const struct irq_domain_ops msi_domain_ops = {
>  static int tegra_pcie_enable_msi(struct tegra_pcie *pcie)
>  {
>         struct platform_device *pdev = to_platform_device(pcie->dev);
> +       const struct tegra_pcie_soc_data *soc = pcie->soc_data;
>         struct tegra_msi *msi = &pcie->msi;
>         unsigned long base;
>         int err;
> @@ -1169,7 +1255,7 @@ static int tegra_pcie_enable_msi(struct tegra_pcie *pcie)
>         msi->pages = __get_free_pages(GFP_KERNEL, 0);
>         base = virt_to_phys((void *)msi->pages);
>
> -       afi_writel(pcie, base, AFI_MSI_FPCI_BAR_ST);
> +       afi_writel(pcie, base >> soc->msi_base_shift, AFI_MSI_FPCI_BAR_ST);
>         afi_writel(pcie, base, AFI_MSI_AXI_BAR_ST);
>         /* this register is in 4K increments */
>         afi_writel(pcie, 1, AFI_MSI_BAR_SZ);
> @@ -1238,16 +1324,35 @@ static int tegra_pcie_get_xbar_config(struct tegra_pcie *pcie, u32 lanes,
>  {
>         struct device_node *np = pcie->dev->of_node;
>
> -       switch (lanes) {
> -       case 0x00000004:
> -               dev_info(pcie->dev, "single-mode configuration\n");
> -               *xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE;
> -               return 0;
> -
> -       case 0x00000202:
> -               dev_info(pcie->dev, "dual-mode configuration\n");
> -               *xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL;
> -               return 0;
> +       if (of_device_is_compatible(np, "nvidia,tegra30-pcie")) {
> +               switch (lanes) {
> +               case 0x00000204:
> +                       dev_info(pcie->dev, "4x1, 2x1 configuration\n");
> +                       *xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_420;
> +                       return 0;
> +
> +               case 0x00020202:
> +                       dev_info(pcie->dev, "2x3 configuration\n");
> +                       *xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_222;
> +                       return 0;
> +
> +               case 0x00010104:
> +                       dev_info(pcie->dev, "4x1, 1x2 configuration\n");
> +                       *xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_411;
> +                       return 0;
> +               }
> +       } else if (of_device_is_compatible(np, "nvidia,tegra20-pcie")) {
> +               switch (lanes) {
> +               case 0x00000004:
> +                       dev_info(pcie->dev, "single-mode configuration\n");
> +                       *xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_SINGLE;
> +                       return 0;
> +
> +               case 0x00000202:
> +                       dev_info(pcie->dev, "dual-mode configuration\n");
> +                       *xbar = AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_DUAL;
> +                       return 0;
> +               }
>         }
>
>         return -EINVAL;
> @@ -1255,6 +1360,7 @@ static int tegra_pcie_get_xbar_config(struct tegra_pcie *pcie, u32 lanes,
>
>  static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
>  {
> +       const struct tegra_pcie_soc_data *soc = pcie->soc_data;
>         struct device_node *np = pcie->dev->of_node, *port;
>         struct of_pci_range_parser parser;
>         struct of_pci_range range;
> @@ -1275,6 +1381,12 @@ static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
>         if (IS_ERR(pcie->pex_clk_supply))
>                 return PTR_ERR(pcie->pex_clk_supply);
>
> +       if (soc->has_avdd_supply) {
> +               pcie->avdd_supply = devm_regulator_get(pcie->dev, "avdd");
> +               if (IS_ERR(pcie->avdd_supply))
> +                       return PTR_ERR(pcie->avdd_supply);
> +       }
> +
>         for_each_of_pci_range(&parser, &range) {
>                 of_pci_range_to_resource(&range, np, &res);
>
> @@ -1321,7 +1433,7 @@ static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
>
>                 index = PCI_SLOT(err);
>
> -               if (index < 1 || index > TEGRA_MAX_PORTS) {
> +               if (index < 1 || index > soc->num_ports) {
>                         dev_err(pcie->dev, "invalid port number: %d\n", index);
>                         return -EINVAL;
>                 }
> @@ -1459,17 +1571,54 @@ static int tegra_pcie_enable(struct tegra_pcie *pcie)
>         return 0;
>  }
>
> +static const struct tegra_pcie_soc_data tegra20_pcie_data = {
> +       .num_ports = 2,
> +       .msi_base_shift = 0,
> +       .pads_pll_ctl = PADS_PLL_CTL_TEGRA20,
> +       .tx_ref_sel = PADS_PLL_CTL_TXCLKREF_DIV10,
> +       .has_pex_clkreq_en = false,
> +       .has_pex_bias_ctrl = false,
> +       .has_intr_prsnt_sense = false,
> +       .has_avdd_supply = false,
> +       .has_cml_clk = false,
> +};
> +
> +static const struct tegra_pcie_soc_data tegra30_pcie_data = {
> +       .num_ports = 3,
> +       .msi_base_shift = 8,
> +       .pads_pll_ctl = PADS_PLL_CTL_TEGRA30,
> +       .tx_ref_sel = PADS_PLL_CTL_TXCLKREF_BUF_EN,
> +       .has_pex_clkreq_en = true,
> +       .has_pex_bias_ctrl = true,
> +       .has_intr_prsnt_sense = true,
> +       .has_avdd_supply = true,
> +       .has_cml_clk = true,
> +};
> +
> +static const struct of_device_id tegra_pcie_of_match[] = {
> +       { .compatible = "nvidia,tegra30-pcie", .data = &tegra30_pcie_data },
> +       { .compatible = "nvidia,tegra20-pcie", .data = &tegra20_pcie_data },
> +       { },
> +};
> +MODULE_DEVICE_TABLE(of, tegra_pcie_of_match);
> +
>  static int tegra_pcie_probe(struct platform_device *pdev)
>  {
> +       const struct of_device_id *match;
>         struct tegra_pcie *pcie;
>         int err;
>
> +       match = of_match_device(tegra_pcie_of_match, &pdev->dev);
> +       if (!match)
> +               return -ENODEV;
> +
>         pcie = devm_kzalloc(&pdev->dev, sizeof(*pcie), GFP_KERNEL);
>         if (!pcie)
>                 return -ENOMEM;
>
>         INIT_LIST_HEAD(&pcie->busses);
>         INIT_LIST_HEAD(&pcie->ports);
> +       pcie->soc_data = match->data;
>         pcie->dev = &pdev->dev;
>
>         err = tegra_pcie_parse_dt(pcie);
> @@ -1518,12 +1667,6 @@ put_resources:
>         return err;
>  }
>
> -static const struct of_device_id tegra_pcie_of_match[] = {
> -       { .compatible = "nvidia,tegra20-pcie", },
> -       { },
> -};
> -MODULE_DEVICE_TABLE(of, tegra_pcie_of_match);
> -
>  static struct platform_driver tegra_pcie_driver = {
>         .driver = {
>                 .name = "tegra-pcie",
> --
> 1.8.1.5
>


From bhelgaas at google.com  Thu Jul 25 14:01:05 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Thu, 25 Jul 2013 12:01:05 -0600
Subject: [PATCH v5 09/16] PCI: tegra: set up PADS_REFCLK_CFG1
In-Reply-To: <1374774810-18459-10-git-send-email-thierry.reding@gmail.com>
References: <1374774810-18459-1-git-send-email-thierry.reding@gmail.com>
 <1374774810-18459-10-git-send-email-thierry.reding@gmail.com>
Message-ID: <CAErSpo5v0ajACxAZnUQtL5LbY=JW1Xdw+cRf=wtqvJuQDxfAow@mail.gmail.com>

On Thu, Jul 25, 2013 at 11:53 AM, Thierry Reding
<thierry.reding at gmail.com> wrote:
> From: Stephen Warren <swarren at nvidia.com>
>
> The registers PADS_REFCLK_CFG are an array of 16-bit data, one entry per
> PCIe root port. For Tegra30, we therefore need to write a 3rd entry in
> this array. Doing so mays the mini-PCIe slot on Beaver operate correctly.
>
> While we're at it, add some #defines to partially document the fields
> within these 16-bit values.
>
> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> Signed-off-by: Thierry Reding <treding at nvidia.com>

Acked-by: Bjorn Helgaas <bhelgaas at google.com>

> ---
>  drivers/pci/host/pci-tegra.c | 29 ++++++++++++++++++++++++-----
>  1 file changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> index 5347d7d..0c84c67 100644
> --- a/drivers/pci/host/pci-tegra.c
> +++ b/drivers/pci/host/pci-tegra.c
> @@ -196,6 +196,25 @@
>  #define PADS_REFCLK_CFG0                       0x000000C8
>  #define PADS_REFCLK_CFG1                       0x000000CC
>
> +/*
> + * Fields in PADS_REFCLK_CFG*. Those registers form an array of 16-bit
> + * entries, one entry per PCIe port. These field definitions and desired
> + * values aren't in the TRM, but do come from NVIDIA.
> + */
> +#define PADS_REFCLK_CFG_TERM_SHIFT             2  /* 6:2 */
> +#define PADS_REFCLK_CFG_E_TERM_SHIFT           7
> +#define PADS_REFCLK_CFG_PREDI_SHIFT            8  /* 11:8 */
> +#define PADS_REFCLK_CFG_DRVI_SHIFT             12 /* 15:12 */
> +
> +/* Default value provided by HW engineering is 0xfa5c */
> +#define PADS_REFCLK_CFG_VALUE \
> +       ( \
> +               (0x17 << PADS_REFCLK_CFG_TERM_SHIFT)   | \
> +               (0    << PADS_REFCLK_CFG_E_TERM_SHIFT) | \
> +               (0xa  << PADS_REFCLK_CFG_PREDI_SHIFT)  | \
> +               (0xf  << PADS_REFCLK_CFG_DRVI_SHIFT)     \
> +       )
> +
>  struct tegra_msi {
>         struct msi_chip chip;
>         DECLARE_BITMAP(used, INT_PCI_MSI_NR);
> @@ -809,11 +828,11 @@ static int tegra_pcie_enable_controller(struct tegra_pcie *pcie)
>         value |= PADS_PLL_CTL_RST_B4SM;
>         pads_writel(pcie, value, soc->pads_pll_ctl);
>
> -       /*
> -        * Hack, set the clock voltage to the DEFAULT provided by hw folks.
> -        * This doesn't exist in the documentation.
> -        */
> -       pads_writel(pcie, 0xfa5cfa5c, PADS_REFCLK_CFG0);
> +       /* Configure the reference clock driver */
> +       value = PADS_REFCLK_CFG_VALUE | (PADS_REFCLK_CFG_VALUE << 16);
> +       pads_writel(pcie, value, PADS_REFCLK_CFG0);
> +       if (soc->num_ports > 2)
> +               pads_writel(pcie, PADS_REFCLK_CFG_VALUE, PADS_REFCLK_CFG1);
>
>         /* wait for the PLL to lock */
>         timeout = 300;
> --
> 1.8.1.5
>


From will.deacon at arm.com  Thu Jul 25 14:05:18 2013
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Jul 2013 19:05:18 +0100
Subject: [PATCH 4/6] ARM: locks: prefetch the destination word for write
 prior to strex
In-Reply-To: <51F166A0.7030203@codeaurora.org>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-5-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231609170.15022@syhkavp.arg>
 <20130724111841.GD11072@mudshark.cambridge.arm.com>
 <51F160EA.6030800@codeaurora.org> <51F1626C.3050008@codeaurora.org>
 <20130725174555.GK12827@mudshark.cambridge.arm.com>
 <51F166A0.7030203@codeaurora.org>
Message-ID: <20130725180518.GM12827@mudshark.cambridge.arm.com>

On Thu, Jul 25, 2013 at 06:55:44PM +0100, Stephen Boyd wrote:
> On 07/25/13 10:45, Will Deacon wrote:
> > On Thu, Jul 25, 2013 at 06:37:48PM +0100, Stephen Boyd wrote:
> >> On 07/25/13 10:31, Stephen Boyd wrote:
> >>> Maybe I'm wrong, but can't you just remove the casts and leave the
> >>> function as static inline? const void * is pretty much telling the
> >>> compiler to turn off type checking.
> >>>
> >> Oh joy. Why is rwlock's lock member marked volatile?
> > Yeah, that was the problematic guy. However, I had to fix that anyway in
> > this patch because otherwise the definition for prefetchw when
> > !ARCH_HAS_PREFETCHW (which expands to __builtin_prefetch(x,1)) will explode.
> >
> > So, given that I've fixed the rwlocks, I think I could put prefetch and
> > prefetchw back to static inline functions. What do you reckon?
> 
> It would be good to match the builtin function's signature so that we
> don't explode in the future on ARCH_HAS_PREFETCHW configs.

Ok, so that's basically just undoing the macroisation on top of v2 (fixup
below).

Will

--->8

diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index dde7ecc..dac9429 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -109,25 +109,25 @@ unsigned long get_wchan(struct task_struct *p);
 #if __LINUX_ARM_ARCH__ >= 5
 
 #define ARCH_HAS_PREFETCH
-#define prefetch(p)                                                    \
-({                                                                     \
-       __asm__ __volatile__(                                           \
-               "pld\t%a0"                                              \
-               :: "p" (p));                                            \
-})
+static inline void prefetch(const void *ptr)
+{
+       __asm__ __volatile__(
+               "pld\t%a0"
+               :: "p" (ptr));
+}
 
 #if __LINUX_ARM_ARCH__ >= 7 && defined(CONFIG_SMP)
 #define ARCH_HAS_PREFETCHW
-#define prefetchw(p)                                                   \
-({                                                                     \
-       __asm__ __volatile__(                                           \
-               ".arch_extension        mp\n"                           \
-               __ALT_SMP_ASM(                                          \
-                       WASM(pldw)              "\t%a0",                \
-                       WASM(pld)               "\t%a0"                 \
-               )                                                       \
-               :: "p" (p));                                            \
-})
+static inline void prefetchw(const void *ptr)
+{
+       __asm__ __volatile__(
+               ".arch_extension        mp\n"
+               __ALT_SMP_ASM(
+                       WASM(pldw)              "\t%a0",
+                       WASM(pld)               "\t%a0"
+               )
+               :: "p" (ptr));
+}
 #endif
 #endif



From swarren at wwwdotorg.org  Thu Jul 25 14:05:48 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 25 Jul 2013 11:05:48 -0700
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
Message-ID: <51F168FC.9070906@wwwdotorg.org>

On 07/25/2013 10:57 AM, Mark Rutland wrote:
> On Thu, Jul 25, 2013 at 05:09:19PM +0100, Olof Johansson wrote:
...
>> So, there really seems to be a need for a layered approach, one in
>> which a binding "graduates" from being tentative to being locked in.
>> I'm refraining from using the terms "staging" and "stable" here, since
>> they have overloaded meaning in the kernel world that doesn't apply
>> here.
> 
> I'm not sure how realistic it is to have drivers in the kernel using
> unstable bindings, and expect people to not rely on them, but I don't
> have a better option to give. We need a big fat warning that an unstable
> binding is in use.

I don't think having people "rely" on the bindings is the issue so much
as the awareness that if they do, there will be compatibility issues for
unstable bindings.

>> One problem that needs to be solved is obviously how a binding
>> graduates from tentative to locked. This work isn't going to be very
>> interesting to most people, I suspect. Think standards committee type
>> work.
>>
>> A possible way to handle this is to have exactly that: A group of
>> people that essentially constitute the "standards committee" that meet
>> on a regular basis to review and approve new bindings. They should be
>> people not just doing ARM Linux work, but other stakeholders in these
>> bindings too. One of the things they should probably do is sift
>> through our current in-kernel bindings and select those who seem ready
>> to be locked in, review/discuss/decide upon that and once the decision
>> is made, that specific binding does become part of the static,
>> never-ever-change ABI of firmware-to-kernel interfaces.   That might
>> also be the time that the binding is moved from the kernel to a
>> separate repo, but that's a technicality that we'll let the DT
>> maintainers decide among themselves, IMHO.
> 
> We're going to need input from other OSs too, or the bindings will
> remain Linux-specific regardless of how far away the bindings and dts
> repo(s) is/are.

And bootloaders too. Some U-Boot platforms are starting to use DT for
exactly the same reason that the kernel does; to allow a single
bootloader binary to run on a variety of different boards, with all
configuration coming from DT.

On another related topic, something that may be useful for the DT
bindings reviewer team is a basic checklist for new DT bindings.
Something similar to Fedora's package review checklist. Perhaps also
(yet another?) document on a bit of DT philosophy. If this sounds
useful, I could try and take a stab at some basic initial version.

We also need to decide (or just document) exactly what "describes the
HW" means; see the thread on thermal limits, and consider the extension
of describing hard/absolute thermal limits to describing use-cased base
thermal profiles using the same schema, or not allowing that.


From mturquette at linaro.org  Thu Jul 25 14:05:57 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 25 Jul 2013 11:05:57 -0700
Subject: [PATCH v5 4/5] clk: add CLK_SET_RATE_NO_REPARENT flag
In-Reply-To: <51F1202D.9060403@imgtec.com>
References: <1371139562-305-1-git-send-email-james.hogan@imgtec.com>
 <1371139562-305-5-git-send-email-james.hogan@imgtec.com>
 <51F11B46.7010900@samsung.com> <51F1202D.9060403@imgtec.com>
Message-ID: <20130725180557.7598.20285@quantum>

Quoting James Hogan (2013-07-25 05:55:09)
> Hi Sylwester
> 
> On 25/07/13 13:34, Sylwester Nawrocki wrote:
> > On 06/13/2013 06:06 PM, James Hogan wrote:
> >> Add a CLK_SET_RATE_NO_REPARENT clock flag, which will prevent muxes
> >> being reparented during clk_set_rate.
> >>
> >> To avoid breaking existing platforms, all callers of clk_register_mux()
> >> are adjusted to pass the new flag. Platform maintainers are encouraged
> >> to remove the flag if they wish to allow mux reparenting on set_rate.
> > [..]
> >> Changes in v3:
> >>
> >> * rename/invert CLK_SET_RATE_REMUX to CLK_SET_RATE_NO_REPARENT and move
> >>   to this new patch.
> >> * patch 3: add CLK_SET_RATE_NO_REPARENT flag to all callers of
> >>   clk_register_mux. If you don't mind your clocks being reparented in
> >>   response to set_rate please let me know and I'll drop the relevant
> >>   portion of the patch.
> > 
> > Why is this better to change current behaviour of the clock core
> > and modify all drivers instead of having, e.g. CLK_SET_RATE_REPARENT
> > set in drivers of hardware that supports clock re-parenting while
> > setting clock rate ?
> 
> See this message from Mike Turquette which first suggested it:
> 
> http://marc.info/?l=linux-kernel&m=136847508109344&w=2
> 
> > Is there intention to just have the automatic clock re-parenting
> > as a default feature in the common clock API ?
> 
> Yes, that would be the result (except where explicitly disallowed).
> Unfortunately where such policy should ideally be defined is still up in
> the air.
> 
> It's not a property of the hardware, but then it is arguably a property
> of the environment the bootloader has configured (like the stuff in the
> /chosen device tree node).

I'm happy to get feedback on this decision. Looking back on
CLK_SET_RATE_PARENT flag I wish I had made that behavior the default.
Instead there would only be a flag for the case where you explicitly do
not wish to propagate the rate change request up the tree.

Another thing to consider here is that only users of .determine_rate are
affected. If your mux clock implements .set_parent and .round_rate, but
not .determine_rate then you are not affected by this change.

The whole thing gets messy because we're pushing policy into the clock
framework, but there is no way to avoid that if we're going to achieve
the goal of having drivers know only about the leaf clocks they consume
and not requiring those drivers to understand the greater clock tree
topology.

Regards,
Mike

> 
> Presuming that the usual reason not to reparent a mux is because other
> important clocks depend on it, the kernel might know enough to work out
> whether it's safe (unless of course there are other cores/threads in the
> SoC using the clock that Linux isn't aware of, which brings us back to
> it being a bootloader environment thing).
> 
> > My apologies if this has already been answered, I haven't been
> > following this thread.
> 
> No problem :)
> 
> Cheers
> James


From Dave.Martin at arm.com  Thu Jul 25 14:09:12 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Thu, 25 Jul 2013 19:09:12 +0100
Subject: [PATCH] ARM: kdgb: use .inst for data to be assembled as
 intruction
In-Reply-To: <51F15CAE.7020008@codethink.co.uk>
References: <1374763778-5305-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374763778-5305-2-git-send-email-ben.dooks@codethink.co.uk>
 <20130725171130.GE2546@localhost.localdomain>
 <51F15CAE.7020008@codethink.co.uk>
Message-ID: <20130725180912.GG2546@localhost.localdomain>

On Thu, Jul 25, 2013 at 06:13:18PM +0100, Ben Dooks wrote:
> On 25/07/13 18:11, Dave Martin wrote:
> >On Thu, Jul 25, 2013 at 03:49:38PM +0100, Ben Dooks wrote:
> >>The arch_kgdb_breakpoint() function uses an inline assembly directive
> >>to assemble a specific instruction using .word. This means the linker
> >>will not treat is as an instruction, and therefore incorrectly swap
> >>the endian-ness if running BE8.
> >>
> >>Note, not tested, please comment if this is wrong.
> >>
> >>Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
> >>---
> >>  arch/arm/include/asm/kgdb.h |    2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >>diff --git a/arch/arm/include/asm/kgdb.h b/arch/arm/include/asm/kgdb.h
> >>index 48066ce..76227c8 100644
> >>--- a/arch/arm/include/asm/kgdb.h
> >>+++ b/arch/arm/include/asm/kgdb.h
> >>@@ -41,7 +41,7 @@
> >>
> >>  static inline void arch_kgdb_breakpoint(void)
> >>  {
> >>-	asm(".word 0xe7ffdeff");
> >>+	asm(".inst 0xe7ffdeff");
> >
> >Yikes, this isn't going to work in a Thumb kernel.
> >
> >We should make HAVE_ARCH_KGDB depend on !THUMB2_KERNEL until/unless that
> >gets fixed...  It looks like the incompatibilities may be more extensive
> >than just this one instruction.
> >
> >
> >For the ARM case, similarly to the other patches, please use the __inst
> >macros from<asm/opcodes.h>  instead of emitting the opcode explicitly.
> 
> See previous objections to that, plus they're marked for internal use
> only!

Ditto my counterarguments.  I'm not emotionally attached to __inst*(), but
we should use one or the other: either .inst or __inst(), not a mixture.
However, the __inst macros work for inline asm and .S, and do more than
just emitting a single opcode; see opcodes-virt.h for example, so while
removing them isn't rocket science, it would involve churn in a few places.


Note, the "Don't use these directly" comment only applies to the triple-
underscored helpers.

The broader "using these macros directly is poor practice" comment was
an attempt to engourage people to write the likes of

#define __KGDB_BKPT_INSTR __inst_arm(0xxe7ffdeff)

static inline void arch_kgdb_breakpoint(void)
{
	asm(__KGDB_BKPT_INSTR);
}

...on the basis that this ought to be more readable.

But this is a bit moot in a situation like this where the opcode is
only used in one place, by itself, in a wrapper whose name makes the
intent clear anyway.

Cheers
---Dave


From aaro.koskinen at iki.fi  Thu Jul 25 14:15:02 2013
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Thu, 25 Jul 2013 21:15:02 +0300
Subject: [PATCH] ARM: OMAP: rx51: change musb mode to OTG
Message-ID: <1374776102-12120-1-git-send-email-aaro.koskinen@iki.fi>

Peripheral-only mode got broken in v3.11-rc1 because of unknown reasons.
Change the mode to OTG, in practice that should work equally well even
when/if the regression gets fixed.

Signed-off-by: Aaro Koskinen <aaro.koskinen at iki.fi>
---
 arch/arm/mach-omap2/board-rx51.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index d2ea68e..773510556 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -85,7 +85,7 @@ static struct omap_board_mux board_mux[] __initdata = {
 
 static struct omap_musb_board_data musb_board_data = {
 	.interface_type		= MUSB_INTERFACE_ULPI,
-	.mode			= MUSB_PERIPHERAL,
+	.mode			= MUSB_OTG,
 	.power			= 0,
 };
 
-- 
1.8.3.2



From robherring2 at gmail.com  Thu Jul 25 14:15:57 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 25 Jul 2013 13:15:57 -0500
Subject: [PATCH] arm: l2x0: add support for prefetch and pwr control
 register configuration
In-Reply-To: <CANuQgHE2rEDCwP8tHhUFF442Nqa9Gyqa6gii-jQDTEUVdEYwcA@mail.gmail.com>
References: <1374572345-5763-1-git-send-email-chander.kashyap@linaro.org>
 <20130723102212.GD4833@e106331-lin.cambridge.arm.com>
 <51EE8183.9010703@gmail.com>
 <CANuQgHE2rEDCwP8tHhUFF442Nqa9Gyqa6gii-jQDTEUVdEYwcA@mail.gmail.com>
Message-ID: <51F16B5D.7050707@gmail.com>

On 07/24/2013 11:11 PM, Chander Kashyap wrote:
> On 23 July 2013 18:43, Rob Herring <robherring2 at gmail.com> wrote:
>> On 07/23/2013 05:22 AM, Mark Rutland wrote:
>>> Hi,
>>>
>>> [adding Rob Herring to Cc]
>>
>> Thanks.
>>
>>> On Tue, Jul 23, 2013 at 10:39:05AM +0100, Chander Kashyap wrote:
>>>> This patch adds support to configure prefetch and pwr control registers
>>>> of pl310 cache controllor.
>>>>
>>>> Signed-off-by: Chander Kashyap <chander.kashyap at linaro.org>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/l2cc.txt |    6 ++++
>>>>  arch/arm/include/asm/hardware/cache-l2x0.h     |   23 +++++++++++++
>>>>  arch/arm/mm/cache-l2x0.c                       |   44 ++++++++++++++++++++++++
>>>>  3 files changed, 73 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
>>>> index cbef09b..66876b6 100644
>>>> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
>>>> @@ -34,6 +34,12 @@ Optional properties:
>>>>  - arm,filter-ranges : <start length> Starting address and length of window to
>>>>    filter. Addresses in the filter window are directed to the M1 port. Other
>>>>    addresses will go to the M0 port.
>>>> +- arm,prefetch-control : Prefetch related configurations. Specifies 8 cells of
>>>> +  prefetch-offset, not-same-ID-on-exclusive-sequence-en, incr-double-Linefill-en,
>>>> +  prefetch-drop-en, data-prefetch-en, instruction-prefetch-en and
>>>> +  double-linefill-en.
>>>
>>> This looks like configuration rather than hardware specification.
>>
>> I think weigh whether this is configuration based on the h/w or just
>> user preference. This would be the former, but...
>>
>>> Is there any reason we couldn't have Linux configure this itself? I'm
>>> not sure having a fixed configuration of these values makes sense - the
>>> configuration values could interact badly with future changes to Linux
>>> (e.g. performance improvements or errata workarounds), and then we'd
>>> have to ignore the described values and/or decide on more suitable ones
>>> dynamically anyway.
>>
>> Does having a variable configuration for these make sense either? I mean
>> other than an errata work-around, why would you ever turn off prefetch
>> or double linefill?
>>
>> None of these fields can be set in NS world. We've already laid down the
>> law in regards to setting secure only bits for errata work-arounds. I
>> think this is no different and we should move towards the kernel doesn't
>> touch aux ctrl at all. There might be an exception with the event bus
>> enable, but you would still have the secure vs. non-secure issue and no
>> way to detect that.
> 
> So what is the suggestion here. Not to touch the prefetch register at all.
> But prefetch register values are saved and resumed in existing code,
> how to take care for that.

As I said, I think all aux ctrl setup should be in the bootloader and
out of the kernel.

If you need to do platform specific things like save and restore then
fine, but let's not encourage it since it can't work universally.

Rob



From jason at lakedaemon.net  Thu Jul 25 14:19:03 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 14:19:03 -0400
Subject: [PATCH v4 0/7] ARM: mvebu: switch to DT probed irqchip and
 clocksource
In-Reply-To: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1372763023-12374-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130725181903.GP23879@titan.lakedaemon.net>

On Tue, Jul 02, 2013 at 01:03:36PM +0200, Sebastian Hesselbarth wrote:
> This patch set converts Marvell Dove and Kirkwood DT enabled boards
> to probe irqchip and clocksource by DT. The corresponding irqchip and
> clocksource drivers have been taken by Thomas Gleixner and Daniel Lezcano
> respectively. This patch set is based on next-20130701 plus tip/core and
> timers/clockevents. Also, mv643xx_eth DT patches sent earlier are applied.
> 
> Unfortunately, the same compatible string is used by irqchip driver and
> irq DT stub in plat-orion/irq.c while reg layout is different. This patch
> set should be applied as a whole only, as device tree conversion breaks
> kernel boot until the corresponding second patch is applied. As this set
> is Marvell SoC related only, I suggest to take it all through Jason
> Cooper's branch.
> 
> Patch set version has been bumped to v4, but this only contains the
> remaining Marvell related patches. irqchip and clocksource drivers from
> v3 have already been taken by the respective maintainers.
> 
> The first three patches convert Dove, Kirkwood, and Orion5x DT files to
> the new reg layout. Patch 4 and 5 add the new clocksource and irqchip
> nodes. Patch 6 also removes an obsolete clock gate workaround from
> Kirkwood DT board setup. Patch 7 then updates the irq driver DT stub in
> plat-orion/irq to reflect the changed reg layout. The irq driver DT stub
> is still used on Orion5x until proper DT clk provider is available.
> 
> The patch set has been tested on Dove, and compile-tested on Kirkwood
> and Orion5x defconfig.
> 
> Sebastian Hesselbarth (7):
>   ARM: dove: move device tree nodes to DT irqchip and clocksource
>   ARM: kirkwood: move device tree nodes to DT irqchip and clocksource
>   ARM: orion5x: update intc device tree node to new reg layout
>   ARM: dove: convert to DT irqchip and clocksource
>   ARM: kirkwood: convert to DT irqchip and clocksource
>   ARM: kirkwood: remove obsolete SDIO clock gate workaround
>   ARM: plat-orion: add reg offset to DT irq driver stub
> 
>  arch/arm/boot/dts/dove.dtsi       |   21 +++++++++++++++++++--
>  arch/arm/boot/dts/kirkwood.dtsi   |   35 +++++++++++++++++++++++++++--------
>  arch/arm/boot/dts/orion5x.dtsi    |    5 +++--
>  arch/arm/mach-dove/Kconfig        |    2 ++
>  arch/arm/mach-dove/Makefile       |    4 ++--
>  arch/arm/mach-dove/board-dt.c     |   23 ++++++++++++++++-------
>  arch/arm/mach-kirkwood/Kconfig    |   22 ++++++++++++++++++++++
>  arch/arm/mach-kirkwood/Makefile   |    4 ++--
>  arch/arm/mach-kirkwood/board-dt.c |   28 +++++++++++++++++-----------
>  arch/arm/plat-orion/irq.c         |    2 +-
>  10 files changed, 111 insertions(+), 35 deletions(-)

Whole series (with v5 of #5) applied to mvebu/boards

thx,

Jason.


From robdclark at gmail.com  Thu Jul 25 14:21:59 2013
From: robdclark at gmail.com (Rob Clark)
Date: Thu, 25 Jul 2013 14:21:59 -0400
Subject: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
In-Reply-To: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com>
References: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com>
Message-ID: <CAF6AEGtspnhSGNM4_QQubVfOkZ1Gh1-Z3iyHOLBPVWuqRy81ew@mail.gmail.com>

On Thu, Jul 25, 2013 at 1:17 PM,  <tom.cooksey at arm.com> wrote:
> From: Tom Cooksey <tom.cooksey at arm.com>
>
> Please find below the current state of our pl111 DRM/KMS driver. This
> is lightly tested on a Versatile Express using X running the
> xf86-video-armsoc DDX driver[i] with the patches applied to drm-next
> as of ~last week. To actually see anything on the DVI output, you
> must also apply Pawel Moll's VExpress DVI mux driver[ii] to select
> the video signal from the ca9x4 core tile.
>
> [i] <https://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git;a=summary>
> [ii] <https://patchwork.kernel.org/patch/1765981/>
>
>
> Known issues:
>  * It uses KDS. We intend to switch to whatever implicit per-buffer
>    synchronisation mechanism gets merged, once something is merged.
>  * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>    allocate buffers for the GPU. Still not sure how to resolve this
>    as we don't use DRM for our GPU driver.

any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
once the dma-fence stuff is in place), we'd have gpu-specific drm
(gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
using prime/dmabuf to share between the two.

>  * Doesn't handle page flip event sequence numbers and timestamps
>  * The v_sync handling needs work in general - a work queue is a
>    little overkill
>  * Doesn't support the import half of PRIME properly, only export
>  * Need to validate src rectangle size in
>    pl111_drm_cursor_plane_update()
>  * Only supports 640x480 mode, which is hard-coded. We intend to
>    rebase on top of CDF once it is merged, which hopefully will
>    handle a lot of the EDID parsing & mode setting for us (once
>    Pawel's CDF patches for VExpress also land).

note that drm core already handles EDID parsing quite nicely.. I'm not
entirely sure why CDF would be needed for this?

>
> I appreciate that's a fairly hefty list of known issues already!
> However, we're waiting for both CDF & dma_buf sync mechanisms to land
> before we can address some of those. So in the mean-time, I thought
> someone might be interested in taking a look at what we have so far,
> which is why I'm posting this now. Needless to say the code will need
> to be refactored a fair bit, however I'm keen to get and additional
> feedback anyone cares to give.
>

What is the dependency on CDF?  Is there an external encoder/bridge
that could be shared between platforms?

btw, I think that having some share-able KMS objects is a good idea.
I'm not entirely sure that the directions that the current CDF
proposals are headed is necessarily the right way forward.  I'd prefer
to see small/incremental evolution of KMS (ie. add drm_bridge and
drm_panel, and refactor the existing encoder-slave).  Keeping it
inside drm means that we can evolve it more easily, and avoid layers
of glue code for no good reason.

BR,
-R


>
> Cheers,
>
> Tom
>
> Tom Cooksey (1):
>   drm/pl111: Initial drm/kms driver for pl111 display controller
>
>  drivers/gpu/drm/Kconfig                     |    2 +
>  drivers/gpu/drm/Makefile                    |    1 +
>  drivers/gpu/drm/pl111/Kbuild                |   14 +
>  drivers/gpu/drm/pl111/Kconfig               |    9 +
>  drivers/gpu/drm/pl111/pl111_clcd_ext.h      |   78 ++++
>  drivers/gpu/drm/pl111/pl111_drm.h           |  227 ++++++++++++
>  drivers/gpu/drm/pl111/pl111_drm_connector.c |  166 +++++++++
>  drivers/gpu/drm/pl111/pl111_drm_crtc.c      |  432 ++++++++++++++++++++++
>  drivers/gpu/drm/pl111/pl111_drm_cursor.c    |   97 +++++
>  drivers/gpu/drm/pl111/pl111_drm_device.c    |  319 +++++++++++++++++
>  drivers/gpu/drm/pl111/pl111_drm_dma_buf.c   |  339 ++++++++++++++++++
>  drivers/gpu/drm/pl111/pl111_drm_encoder.c   |  106 ++++++
>  drivers/gpu/drm/pl111/pl111_drm_fb.c        |  152 ++++++++
>  drivers/gpu/drm/pl111/pl111_drm_funcs.h     |  127 +++++++
>  drivers/gpu/drm/pl111/pl111_drm_gem.c       |  287 +++++++++++++++
>  drivers/gpu/drm/pl111/pl111_drm_pl111.c     |  513 +++++++++++++++++++++++++++
>  drivers/gpu/drm/pl111/pl111_drm_platform.c  |  150 ++++++++
>  drivers/gpu/drm/pl111/pl111_drm_suspend.c   |   35 ++
>  drivers/gpu/drm/pl111/pl111_drm_vma.c       |  214 +++++++++++
>  19 files changed, 3268 insertions(+)
>  create mode 100644 drivers/gpu/drm/pl111/Kbuild
>  create mode 100644 drivers/gpu/drm/pl111/Kconfig
>  create mode 100644 drivers/gpu/drm/pl111/pl111_clcd_ext.h
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm.h
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_connector.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_crtc.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_cursor.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_device.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_dma_buf.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_encoder.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_fb.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_funcs.h
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_gem.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_pl111.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_platform.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_suspend.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_vma.c
>
> --
> 1.7.9.5
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From sboyd at codeaurora.org  Thu Jul 25 14:22:47 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Jul 2013 11:22:47 -0700
Subject: [PATCH 4/6] ARM: locks: prefetch the destination word for write
 prior to strex
In-Reply-To: <20130725180518.GM12827@mudshark.cambridge.arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-5-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231609170.15022@syhkavp.arg>
 <20130724111841.GD11072@mudshark.cambridge.arm.com>
 <51F160EA.6030800@codeaurora.org> <51F1626C.3050008@codeaurora.org>
 <20130725174555.GK12827@mudshark.cambridge.arm.com>
 <51F166A0.7030203@codeaurora.org>
 <20130725180518.GM12827@mudshark.cambridge.arm.com>
Message-ID: <51F16CF7.5080604@codeaurora.org>

On 07/25/13 11:05, Will Deacon wrote:
> On Thu, Jul 25, 2013 at 06:55:44PM +0100, Stephen Boyd wrote:
>> On 07/25/13 10:45, Will Deacon wrote:
>>> On Thu, Jul 25, 2013 at 06:37:48PM +0100, Stephen Boyd wrote:
>>>> On 07/25/13 10:31, Stephen Boyd wrote:
>>>>> Maybe I'm wrong, but can't you just remove the casts and leave the
>>>>> function as static inline? const void * is pretty much telling the
>>>>> compiler to turn off type checking.
>>>>>
>>>> Oh joy. Why is rwlock's lock member marked volatile?
>>> Yeah, that was the problematic guy. However, I had to fix that anyway in
>>> this patch because otherwise the definition for prefetchw when
>>> !ARCH_HAS_PREFETCHW (which expands to __builtin_prefetch(x,1)) will explode.
>>>
>>> So, given that I've fixed the rwlocks, I think I could put prefetch and
>>> prefetchw back to static inline functions. What do you reckon?
>> It would be good to match the builtin function's signature so that we
>> don't explode in the future on ARCH_HAS_PREFETCHW configs.
> Ok, so that's basically just undoing the macroisation on top of v2 (fixup
> below).
>
> Will

Looks good to me. Thanks.

>
> --->8
>
> diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
> index dde7ecc..dac9429 100644
> --- a/arch/arm/include/asm/processor.h
> +++ b/arch/arm/include/asm/processor.h
> @@ -109,25 +109,25 @@ unsigned long get_wchan(struct task_struct *p);
>  #if __LINUX_ARM_ARCH__ >= 5
>  
>  #define ARCH_HAS_PREFETCH
> -#define prefetch(p)                                                    \
> -({                                                                     \
> -       __asm__ __volatile__(                                           \
> -               "pld\t%a0"                                              \
> -               :: "p" (p));                                            \
> -})
> +static inline void prefetch(const void *ptr)
> +{
> +       __asm__ __volatile__(
> +               "pld\t%a0"
> +               :: "p" (ptr));
> +}
>  
>  #if __LINUX_ARM_ARCH__ >= 7 && defined(CONFIG_SMP)
>  #define ARCH_HAS_PREFETCHW
> -#define prefetchw(p)                                                   \
> -({                                                                     \
> -       __asm__ __volatile__(                                           \
> -               ".arch_extension        mp\n"                           \
> -               __ALT_SMP_ASM(                                          \
> -                       WASM(pldw)              "\t%a0",                \
> -                       WASM(pld)               "\t%a0"                 \
> -               )                                                       \
> -               :: "p" (p));                                            \
> -})
> +static inline void prefetchw(const void *ptr)
> +{
> +       __asm__ __volatile__(
> +               ".arch_extension        mp\n"
> +               __ALT_SMP_ASM(
> +                       WASM(pldw)              "\t%a0",
> +                       WASM(pld)               "\t%a0"
> +               )
> +               :: "p" (ptr));
> +}
>  #endif
>  #endif
>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From olof at lixom.net  Thu Jul 25 14:25:30 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 25 Jul 2013 11:25:30 -0700
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <51F168FC.9070906@wwwdotorg.org>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
Message-ID: <CAOesGMiLKysW2JG1jbef76Ves=-DAYEiE9d+s8YXWRXUJ+XhaQ@mail.gmail.com>

On Thu, Jul 25, 2013 at 11:05 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/25/2013 10:57 AM, Mark Rutland wrote:
>> On Thu, Jul 25, 2013 at 05:09:19PM +0100, Olof Johansson wrote:
> ...
>>> So, there really seems to be a need for a layered approach, one in
>>> which a binding "graduates" from being tentative to being locked in.
>>> I'm refraining from using the terms "staging" and "stable" here, since
>>> they have overloaded meaning in the kernel world that doesn't apply
>>> here.
>>
>> I'm not sure how realistic it is to have drivers in the kernel using
>> unstable bindings, and expect people to not rely on them, but I don't
>> have a better option to give. We need a big fat warning that an unstable
>> binding is in use.
>
> I don't think having people "rely" on the bindings is the issue so much
> as the awareness that if they do, there will be compatibility issues for
> unstable bindings.

If we continue doing what we do today, where we have (at least part
of) the device trees hosted with the kernel sources, then we can
introduce tentative changes to the device trees at the same time as
the code, so having the drivers rely on that seems appropriate.

Of course, things should not be static in that state, and have to move
out of it reasonably quickly.

>>> One problem that needs to be solved is obviously how a binding
>>> graduates from tentative to locked. This work isn't going to be very
>>> interesting to most people, I suspect. Think standards committee type
>>> work.
>>>
>>> A possible way to handle this is to have exactly that: A group of
>>> people that essentially constitute the "standards committee" that meet
>>> on a regular basis to review and approve new bindings. They should be
>>> people not just doing ARM Linux work, but other stakeholders in these
>>> bindings too. One of the things they should probably do is sift
>>> through our current in-kernel bindings and select those who seem ready
>>> to be locked in, review/discuss/decide upon that and once the decision
>>> is made, that specific binding does become part of the static,
>>> never-ever-change ABI of firmware-to-kernel interfaces.   That might
>>> also be the time that the binding is moved from the kernel to a
>>> separate repo, but that's a technicality that we'll let the DT
>>> maintainers decide among themselves, IMHO.
>>
>> We're going to need input from other OSs too, or the bindings will
>> remain Linux-specific regardless of how far away the bindings and dts
>> repo(s) is/are.
>
> And bootloaders too. Some U-Boot platforms are starting to use DT for
> exactly the same reason that the kernel does; to allow a single
> bootloader binary to run on a variety of different boards, with all
> configuration coming from DT.

Not only that, but in some cases u-boot might want to reach into the
device-tree of the launching kernel and tweak settings based on board
information. It already does this for things like memory and command
line, but there could be other cases where it wants to do so as well.
If things move around, or bindings change, this will obviously cause
problems. (I've already seen this with the Chrome OS u-boot vs
upstream kernels, partly due to a bug in the local fork of u-boot, but
still).

> On another related topic, something that may be useful for the DT
> bindings reviewer team is a basic checklist for new DT bindings.
> Something similar to Fedora's package review checklist. Perhaps also
> (yet another?) document on a bit of DT philosophy. If this sounds
> useful, I could try and take a stab at some basic initial version.

Sounds reasonable. Starting with one of the existing ones instead of
from scratch is a reasonable approach. A checklist and a best
practices doc would come a long way.

> We also need to decide (or just document) exactly what "describes the
> HW" means; see the thread on thermal limits, and consider the extension
> of describing hard/absolute thermal limits to describing use-cased base
> thermal profiles using the same schema, or not allowing that.

Yes indeed. A basic binding need just specify what the specific
hardware IP is, if the rest of the configuration of the IP can be
determined at runtime through other means (i.e. by autoprobing). It's
stuff beyond that that gets very complicated.

To talk semi-specifics: What about USB PHY tunings for a specific
board, where each of the three USB ports and their registers have
slightly different layout? Sure, we can take 10 properties to describe
each tunable field in each register, but at the end it will just be
used to craft the contents blindly, so we might just stuff the 32-bit
register value as a property instead. And in other cases we might
indeed want to describe each property independently. Determining what
is appropriate when is one of the most difficult parts of the review
workflow.


-Olof


From mark.rutland at arm.com  Thu Jul 25 14:29:20 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 25 Jul 2013 19:29:20 +0100
Subject: DT bindings as ABI [was: Do we have people interested in
 device tree janitoring / cleanup?]
In-Reply-To: <51F168FC.9070906@wwwdotorg.org>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
Message-ID: <20130725182920.GA24955@e106331-lin.cambridge.arm.com>

On Thu, Jul 25, 2013 at 07:05:48PM +0100, Stephen Warren wrote:
> On 07/25/2013 10:57 AM, Mark Rutland wrote:
> > On Thu, Jul 25, 2013 at 05:09:19PM +0100, Olof Johansson wrote:
> ...
> >> So, there really seems to be a need for a layered approach, one in
> >> which a binding "graduates" from being tentative to being locked in.
> >> I'm refraining from using the terms "staging" and "stable" here, since
> >> they have overloaded meaning in the kernel world that doesn't apply
> >> here.
> > 
> > I'm not sure how realistic it is to have drivers in the kernel using
> > unstable bindings, and expect people to not rely on them, but I don't
> > have a better option to give. We need a big fat warning that an unstable
> > binding is in use.
> 
> I don't think having people "rely" on the bindings is the issue so much
> as the awareness that if they do, there will be compatibility issues for
> unstable bindings.

As long as we can make sufficiently clear that trying to use an unstable
binding is going to be *very* painful, and not necessarily supported.

> 
> >> One problem that needs to be solved is obviously how a binding
> >> graduates from tentative to locked. This work isn't going to be very
> >> interesting to most people, I suspect. Think standards committee type
> >> work.
> >>
> >> A possible way to handle this is to have exactly that: A group of
> >> people that essentially constitute the "standards committee" that meet
> >> on a regular basis to review and approve new bindings. They should be
> >> people not just doing ARM Linux work, but other stakeholders in these
> >> bindings too. One of the things they should probably do is sift
> >> through our current in-kernel bindings and select those who seem ready
> >> to be locked in, review/discuss/decide upon that and once the decision
> >> is made, that specific binding does become part of the static,
> >> never-ever-change ABI of firmware-to-kernel interfaces.   That might
> >> also be the time that the binding is moved from the kernel to a
> >> separate repo, but that's a technicality that we'll let the DT
> >> maintainers decide among themselves, IMHO.
> > 
> > We're going to need input from other OSs too, or the bindings will
> > remain Linux-specific regardless of how far away the bindings and dts
> > repo(s) is/are.
> 
> And bootloaders too. Some U-Boot platforms are starting to use DT for
> exactly the same reason that the kernel does; to allow a single
> bootloader binary to run on a variety of different boards, with all
> configuration coming from DT.

Ah, I'd not considered that. We certainly need to include them in the
discussion.

> 
> On another related topic, something that may be useful for the DT
> bindings reviewer team is a basic checklist for new DT bindings.
> Something similar to Fedora's package review checklist. Perhaps also
> (yet another?) document on a bit of DT philosophy. If this sounds
> useful, I could try and take a stab at some basic initial version.

That does indeed sound useful. Please do :)

> 
> We also need to decide (or just document) exactly what "describes the
> HW" means; see the thread on thermal limits, and consider the extension
> of describing hard/absolute thermal limits to describing use-cased base
> thermal profiles using the same schema, or not allowing that.
> 

Certainly. This is an unfortunate gray area.

Thanks,
Mark.


From thierry.reding at gmail.com  Thu Jul 25 14:37:54 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 11:37:54 -0700
Subject: [PATCHv5 02/11] PCI: use weak functions for MSI arch-specific
 functions
In-Reply-To: <1373889167-27878-3-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-3-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130725183752.GA18584@dhcp-172-17-186-34.nvidia.com>

On Mon, Jul 15, 2013 at 01:52:38PM +0200, Thomas Petazzoni wrote:
> Until now, the MSI architecture-specific functions could be overloaded
> using a fairly complex set of #define and compile-time
> conditionals. In order to prepare for the introduction of the msi_chip
> infrastructure, it is desirable to switch all those functions to use
> the 'weak' mechanism. This commit converts all the architectures that
> were overidding those MSI functions to use the new strategy.
> 
> Note that we keep a separate, non-weak, function
> default_teardown_msi_irqs() for the default behavior of the
> arch_teardown_msi_irqs(), as the default behavior is needed by the Xen
> x86 PCI code.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> Cc: Paul Mackerras <paulus at samba.org>
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: Martin Schwidefsky <schwidefsky at de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens at de.ibm.com>
> Cc: linux390 at de.ibm.com
> Cc: linux-s390 at vger.kernel.org
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Ingo Molnar <mingo at redhat.com>
> Cc: H. Peter Anvin <hpa at zytor.com>
> Cc: x86 at kernel.org
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Tony Luck <tony.luck at intel.com>
> Cc: Fenghua Yu <fenghua.yu at intel.com>
> Cc: linux-ia64 at vger.kernel.org
> Cc: Ralf Baechle <ralf at linux-mips.org>
> Cc: linux-mips at linux-mips.org
> Cc: David S. Miller <davem at davemloft.net>
> Cc: sparclinux at vger.kernel.org
> Cc: Chris Metcalf <cmetcalf at tilera.com>
> ---
>  arch/mips/include/asm/pci.h    |  5 -----
>  arch/powerpc/include/asm/pci.h |  5 -----
>  arch/s390/include/asm/pci.h    |  4 ----
>  arch/x86/include/asm/pci.h     | 28 --------------------------
>  arch/x86/kernel/x86_init.c     | 21 ++++++++++++++++++++
>  drivers/pci/msi.c              | 45 +++++++++++++++++++-----------------------
>  include/linux/msi.h            |  7 ++++++-
>  7 files changed, 47 insertions(+), 68 deletions(-)

Bjorn,

any chance that we can get your Acked-by on this?

Thierry

> 
> diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
> index fa8e0aa..f194c08 100644
> --- a/arch/mips/include/asm/pci.h
> +++ b/arch/mips/include/asm/pci.h
> @@ -136,11 +136,6 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
>  	return channel ? 15 : 14;
>  }
>  
> -#ifdef CONFIG_CPU_CAVIUM_OCTEON
> -/* MSI arch hook for OCTEON */
> -#define arch_setup_msi_irqs arch_setup_msi_irqs
> -#endif
> -
>  extern char * (*pcibios_plat_setup)(char *str);
>  
>  #ifdef CONFIG_OF
> diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
> index 6653f27..95145a1 100644
> --- a/arch/powerpc/include/asm/pci.h
> +++ b/arch/powerpc/include/asm/pci.h
> @@ -113,11 +113,6 @@ extern int pci_domain_nr(struct pci_bus *bus);
>  /* Decide whether to display the domain number in /proc */
>  extern int pci_proc_domain(struct pci_bus *bus);
>  
> -/* MSI arch hooks */
> -#define arch_setup_msi_irqs arch_setup_msi_irqs
> -#define arch_teardown_msi_irqs arch_teardown_msi_irqs
> -#define arch_msi_check_device arch_msi_check_device
> -
>  struct vm_area_struct;
>  /* Map a range of PCI memory or I/O space for a device into user space */
>  int pci_mmap_page_range(struct pci_dev *pdev, struct vm_area_struct *vma,
> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
> index 6e577ba..262b91b 100644
> --- a/arch/s390/include/asm/pci.h
> +++ b/arch/s390/include/asm/pci.h
> @@ -21,10 +21,6 @@ void pci_iounmap(struct pci_dev *, void __iomem *);
>  int pci_domain_nr(struct pci_bus *);
>  int pci_proc_domain(struct pci_bus *);
>  
> -/* MSI arch hooks */
> -#define arch_setup_msi_irqs	arch_setup_msi_irqs
> -#define arch_teardown_msi_irqs	arch_teardown_msi_irqs
> -
>  #define ZPCI_BUS_NR			0	/* default bus number */
>  #define ZPCI_DEVFN			0	/* default device number */
>  
> diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
> index d9e9e6c..8c61de0 100644
> --- a/arch/x86/include/asm/pci.h
> +++ b/arch/x86/include/asm/pci.h
> @@ -100,29 +100,6 @@ static inline void early_quirks(void) { }
>  extern void pci_iommu_alloc(void);
>  
>  #ifdef CONFIG_PCI_MSI
> -/* MSI arch specific hooks */
> -static inline int x86_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> -{
> -	return x86_msi.setup_msi_irqs(dev, nvec, type);
> -}
> -
> -static inline void x86_teardown_msi_irqs(struct pci_dev *dev)
> -{
> -	x86_msi.teardown_msi_irqs(dev);
> -}
> -
> -static inline void x86_teardown_msi_irq(unsigned int irq)
> -{
> -	x86_msi.teardown_msi_irq(irq);
> -}
> -static inline void x86_restore_msi_irqs(struct pci_dev *dev, int irq)
> -{
> -	x86_msi.restore_msi_irqs(dev, irq);
> -}
> -#define arch_setup_msi_irqs x86_setup_msi_irqs
> -#define arch_teardown_msi_irqs x86_teardown_msi_irqs
> -#define arch_teardown_msi_irq x86_teardown_msi_irq
> -#define arch_restore_msi_irqs x86_restore_msi_irqs
>  /* implemented in arch/x86/kernel/apic/io_apic. */
>  struct msi_desc;
>  int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
> @@ -130,11 +107,6 @@ void native_teardown_msi_irq(unsigned int irq);
>  void native_restore_msi_irqs(struct pci_dev *dev, int irq);
>  int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
>  		  unsigned int irq_base, unsigned int irq_offset);
> -/* default to the implementation in drivers/lib/msi.c */
> -#define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
> -#define HAVE_DEFAULT_MSI_RESTORE_IRQS
> -void default_teardown_msi_irqs(struct pci_dev *dev);
> -void default_restore_msi_irqs(struct pci_dev *dev, int irq);
>  #else
>  #define native_setup_msi_irqs		NULL
>  #define native_teardown_msi_irq		NULL
> diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
> index 45a14db..a2b189c 100644
> --- a/arch/x86/kernel/x86_init.c
> +++ b/arch/x86/kernel/x86_init.c
> @@ -116,6 +116,27 @@ struct x86_msi_ops x86_msi = {
>  	.setup_hpet_msi		= default_setup_hpet_msi,
>  };
>  
> +/* MSI arch specific hooks */
> +int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +{
> +	return x86_msi.setup_msi_irqs(dev, nvec, type);
> +}
> +
> +void arch_teardown_msi_irqs(struct pci_dev *dev)
> +{
> +	x86_msi.teardown_msi_irqs(dev);
> +}
> +
> +void arch_teardown_msi_irq(unsigned int irq)
> +{
> +	x86_msi.teardown_msi_irq(irq);
> +}
> +
> +void arch_restore_msi_irqs(struct pci_dev *dev, int irq)
> +{
> +	x86_msi.restore_msi_irqs(dev, irq);
> +}
> +
>  struct x86_io_apic_ops x86_io_apic_ops = {
>  	.init			= native_io_apic_init_mappings,
>  	.read			= native_io_apic_read,
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index aca7578..aa2f697 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -30,20 +30,21 @@ static int pci_msi_enable = 1;
>  
>  /* Arch hooks */
>  
> -#ifndef arch_msi_check_device
> -int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> +int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
>  {
> -	return 0;
> +	return -EINVAL;
>  }
> -#endif
>  
> -#ifndef arch_setup_msi_irqs
> -# define arch_setup_msi_irqs default_setup_msi_irqs
> -# define HAVE_DEFAULT_MSI_SETUP_IRQS
> -#endif
> +void __weak arch_teardown_msi_irq(unsigned int irq)
> +{
> +}
>  
> -#ifdef HAVE_DEFAULT_MSI_SETUP_IRQS
> -int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> +{
> +	return 0;
> +}
> +
> +int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>  {
>  	struct msi_desc *entry;
>  	int ret;
> @@ -65,14 +66,11 @@ int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>  
>  	return 0;
>  }
> -#endif
>  
> -#ifndef arch_teardown_msi_irqs
> -# define arch_teardown_msi_irqs default_teardown_msi_irqs
> -# define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
> -#endif
> -
> -#ifdef HAVE_DEFAULT_MSI_TEARDOWN_IRQS
> +/*
> + * We have a default implementation available as a separate non-weak
> + * function, as it is used by the Xen x86 PCI code
> + */
>  void default_teardown_msi_irqs(struct pci_dev *dev)
>  {
>  	struct msi_desc *entry;
> @@ -89,15 +87,13 @@ void default_teardown_msi_irqs(struct pci_dev *dev)
>  			arch_teardown_msi_irq(entry->irq + i);
>  	}
>  }
> -#endif
>  
> -#ifndef arch_restore_msi_irqs
> -# define arch_restore_msi_irqs default_restore_msi_irqs
> -# define HAVE_DEFAULT_MSI_RESTORE_IRQS
> -#endif
> +void __weak arch_teardown_msi_irqs(struct pci_dev *dev)
> +{
> +	return default_teardown_msi_irqs(dev);
> +}
>  
> -#ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS
> -void default_restore_msi_irqs(struct pci_dev *dev, int irq)
> +void __weak arch_restore_msi_irqs(struct pci_dev *dev, int irq)
>  {
>  	struct msi_desc *entry;
>  
> @@ -114,7 +110,6 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)
>  	if (entry)
>  		write_msi_msg(irq, &entry->msg);
>  }
> -#endif
>  
>  static void msi_set_enable(struct pci_dev *dev, int enable)
>  {
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index ee66f3a..18870b0 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -51,12 +51,17 @@ struct msi_desc {
>  };
>  
>  /*
> - * The arch hook for setup up msi irqs
> + * The arch hooks to setup up msi irqs. Those functions are
> + * implemented as weak symbols so that they /can/ be overriden by
> + * architecture specific code if needed.
>   */
>  int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc);
>  void arch_teardown_msi_irq(unsigned int irq);
>  int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
>  void arch_teardown_msi_irqs(struct pci_dev *dev);
>  int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
> +void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
> +
> +void default_teardown_msi_irqs(struct pci_dev *dev);
>  
>  #endif /* LINUX_MSI_H */
> -- 
> 1.8.1.2
> 
-------------- 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/20130725/ea958105/attachment-0001.sig>

From thierry.reding at gmail.com  Thu Jul 25 14:40:44 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 11:40:44 -0700
Subject: [PATCHv5 04/11] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <1373889167-27878-5-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-5-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130725184043.GB18584@dhcp-172-17-186-34.nvidia.com>

On Mon, Jul 15, 2013 at 01:52:40PM +0200, Thomas Petazzoni wrote:
> From: Thierry Reding <thierry.reding at avionic-design.de>
> 
> The new struct msi_chip is used to associated an MSI controller with a
> PCI bus. It is automatically handed down from the root to its children
> during bus enumeration.
> 
> This patch provides default (weak) implementations for the architecture-
> specific MSI functions (arch_setup_msi_irq(), arch_teardown_msi_irq()
> and arch_msi_check_device()) which check if a PCI device's bus has an
> attached MSI chip and forward the call appropriately.
> 
> Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  drivers/pci/msi.c   | 27 +++++++++++++++++++++++++--
>  drivers/pci/probe.c |  1 +
>  include/linux/msi.h | 11 +++++++++++
>  include/linux/pci.h |  1 +
>  4 files changed, 38 insertions(+), 2 deletions(-)

Bjorn,

We'll need this as part of a stable branch as well, so any chance you
could ack it?

Thierry

> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index aa2f697..d5b6378 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -32,16 +32,39 @@ static int pci_msi_enable = 1;
>  
>  int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
>  {
> -	return -EINVAL;
> +	struct msi_chip *chip = dev->bus->msi;
> +	int err;
> +
> +	if (!chip || !chip->setup_irq)
> +		return -EINVAL;
> +
> +	err = chip->setup_irq(chip, dev, desc);
> +	if (err < 0)
> +		return err;
> +
> +	irq_set_chip_data(desc->irq, chip);
> +
> +	return 0;
>  }
>  
>  void __weak arch_teardown_msi_irq(unsigned int irq)
>  {
> +	struct msi_chip *chip = irq_get_chip_data(irq);
> +
> +	if (!chip || !chip->teardown_irq)
> +		return;
> +
> +	chip->teardown_irq(chip, irq);
>  }
>  
>  int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
>  {
> -	return 0;
> +	struct msi_chip *chip = dev->bus->msi;
> +
> +	if (!chip || !chip->check_device)
> +		return 0;
> +
> +	return chip->check_device(chip, dev, nvec, type);
>  }
>  
>  int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 46ada5c..b8eaa81 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -666,6 +666,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
>  
>  	child->parent = parent;
>  	child->ops = parent->ops;
> +	child->msi = parent->msi;
>  	child->sysdata = parent->sysdata;
>  	child->bus_flags = parent->bus_flags;
>  
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index 18870b0..cbf5d05 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -64,4 +64,15 @@ void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
>  
>  void default_teardown_msi_irqs(struct pci_dev *dev);
>  
> +struct msi_chip {
> +	struct module *owner;
> +	struct device *dev;
> +
> +	int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
> +			 struct msi_desc *desc);
> +	void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
> +	int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
> +			    int nvec, int type);
> +};
> +
>  #endif /* LINUX_MSI_H */
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 0fd1f15..4044e3c 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -433,6 +433,7 @@ struct pci_bus {
>  	struct resource busn_res;	/* bus numbers routed to this bus */
>  
>  	struct pci_ops	*ops;		/* configuration access functions */
> +	struct msi_chip	*msi;		/* MSI controller */
>  	void		*sysdata;	/* hook for sys-specific extension */
>  	struct proc_dir_entry *procdir;	/* directory entry in /proc/bus/pci */
>  
> -- 
> 1.8.1.2
> 
-------------- 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/20130725/6ec029e2/attachment.sig>

From jason at lakedaemon.net  Thu Jul 25 14:41:00 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 14:41:00 -0400
Subject: [PATCHv1] arm: armada: Add .dts file for Netgear ReadyNAS 102
In-Reply-To: <878v1mgh4x.fsf@natisbad.org>
References: <878v1mgh4x.fsf@natisbad.org>
Message-ID: <20130725184100.GQ23879@titan.lakedaemon.net>

On Thu, Jul 04, 2013 at 11:16:46PM +0200, Arnaud Ebalard wrote:
> 
> All hardware parts of the (Armada 370 based) NETGEAR ReadyNAS 102 are
> supported by mainline kernel (USB 3.0 rear ports, USB 2.0 front port,
> Gigabit controller and PHY, serial port, leds, buttons, SATA ports,
> G762 fan controller) except for:
> 
>  - the Intersil ISL12057 I2C RTC Chip,
>  - the Armada NAND controller.
> 
> Support for both of those is currently work in progress and does not
> prevent boot.
> 
> Signed-off-by: Arnaud Ebalard <arno at natisbad.org>
> ---
> Hi Jason and Andrew,
> 
> As requested
> 
>  - this version is tested against current head of linus tree (+ I2C
>    fixes for a race condition; for details, see message #94 of
>    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622325).
>  - nand layout entry and ISL12057 entry have been removed until support
>    is available in mainline kernel for eahc of those
>  - clock, gpio led and keys have been made siblings of soc, memory and
>    chosen (reported by Sebastian).
> 
> Is it still acceptable for current merge window or am I too late?

Well, for v3.12... ;-)

> Cheers,
> 
> a+
> 
>  arch/arm/boot/dts/Makefile                     |   1 +
>  arch/arm/boot/dts/armada-370-netgear-rn102.dts | 176 +++++++++++++++++++++++++
>  2 files changed, 177 insertions(+)
>  create mode 100644 arch/arm/boot/dts/armada-370-netgear-rn102.dts

Applied to mvebu/dt

thx,

Jason.


From richardcochran at gmail.com  Thu Jul 25 14:48:34 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Thu, 25 Jul 2013 20:48:34 +0200
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
Message-ID: <20130725184834.GA8296@netboy>

On Thu, Jul 25, 2013 at 07:29:20PM +0100, Mark Rutland wrote:
> On Thu, Jul 25, 2013 at 07:05:48PM +0100, Stephen Warren wrote:
> > 
> > I don't think having people "rely" on the bindings is the issue so much
> > as the awareness that if they do, there will be compatibility issues for
> > unstable bindings.
> 
> As long as we can make sufficiently clear that trying to use an unstable
> binding is going to be *very* painful, and not necessarily supported.

Oh, man.

The introduction of DT into ARM Linux was supposed to make everyone's
life sooo much easier. Of course, based on experience with powerpc, I
never believed it*, but still I would expect to hear that the DT
bindings are, well, a *binding* contract between the board developer,
boot loader, and the kernel.

Once it is working with a particular kernel, a DT board description
file should continue to work indefinitely with newer kernels. Anything
less is a regression, pure and simple.

If you go around changing the bindings willy nilly, then what is point
of having DT at all?

Thanks,
Richard

* http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/046963.html
  http://lists.infradead.org/pipermail/linux-arm-kernel/2011-May/050255.html
  http://lists.infradead.org/pipermail/linux-arm-kernel/2011-May/050256.html
  http://lists.infradead.org/pipermail/linux-arm-kernel/2011-May/050264.html


From thierry.reding at gmail.com  Thu Jul 25 14:49:21 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 25 Jul 2013 11:49:21 -0700
Subject: [PATCHv5 00/11] MSI support for Marvell EBU PCIe driver
In-Reply-To: <20130716153911.423cc408@skate>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E4167B.4000208@wwwdotorg.org> <20130716104347.045a612a@skate>
 <20130716131547.GC12062@titan.lakedaemon.net>
 <20130716153911.423cc408@skate>
Message-ID: <20130725184920.GC18584@dhcp-172-17-186-34.nvidia.com>

On Tue, Jul 16, 2013 at 03:39:11PM +0200, Thomas Petazzoni wrote:
> Dear Jason Cooper,
> 
> On Tue, 16 Jul 2013 09:15:47 -0400, Jason Cooper wrote:
> 
> > > A quick diagram of the dependencies, best viewed with a fixed-size font
> > > mailer.
> > > 
> > > kernel/irq/irqdomain    drivers/pci        arch/arm/kernel
> > >      patch 1           patch 2, 3, 4           patch 8
> > >         ||                  ||                   ||
> > >         ||                  \/                   \/
> > >         ||               drivers/of   ==> drivers/pci/host
> > >         ||                patch 5           patch 10
> > >         ||                  ||
> > >         \\__________________//
> > >                   ||
> > >                   \/
> > >             drivers/irqchip
> > >               patch 6, 7
> > 
> > Well, that got more complicated.  :(  No cookie for you.
> 
> Yeah, sorry about this. I'm not sure how to handle that differently.
> 
> > > Patches 9 and 11 are DT patches, so they are not mentioned in this
> > > diagram.
> > > 
> > > Normally tegra would require 1, 2, 3, 4, 5 and 8, so ideally, with
> > > the respective maintainers ACKs, Jason Cooper could take them in a
> > > specific topic stable branch that would not be rebased, on top of which
> > > both the Marvell work and Tegra work could be done.
> > 
> > After my recent discussions with tglx, here's my proposal:
> > 
> > - rmk creates a dedicated topic branch with patch 8
> > 
> > - Bjorn creates a dedicated topic branch based on rmk's with 2, 3, 4, 5,
> >   and 10
> > 
> > - tglx creates a dedicated topic branch based on Bjorn's with 1, 6, 7
> 
> I am wondering if this merge strategy isn't too complicated to work
> nicely. Would it be easier if one person took all of those patches in a
> stable topic branch, with the ACKs from the proper maintainers?
> 
> But anyway, as long as things get merged, I don't really mind what
> merge strategy is used, so I'll trust on what will be the best option
> on this.
> 
> Thanks a lot for taking care of this!

Hi Thomas, Jason,

I've talked this over with Stephen and he'd be willing to create the
stable branch with patches 2, 4 and 8. That could serve as the basis
for both Tegra and Marvell.

Given that there are no cross-dependencies for any of the other patches
(that I'm aware of) it would probably be easier to take them through the
Marvell tree if Bjorn and Thomas (tglx) agree to Ack the patches.

Thierry
-------------- 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/20130725/a1eb8ff1/attachment.sig>

From swarren at wwwdotorg.org  Thu Jul 25 14:53:49 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 25 Jul 2013 11:53:49 -0700
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130725184834.GA8296@netboy>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
Message-ID: <51F1743D.7050007@wwwdotorg.org>

On 07/25/2013 11:48 AM, Richard Cochran wrote:
> On Thu, Jul 25, 2013 at 07:29:20PM +0100, Mark Rutland wrote:
>> On Thu, Jul 25, 2013 at 07:05:48PM +0100, Stephen Warren wrote:
>>>
>>> I don't think having people "rely" on the bindings is the issue so much
>>> as the awareness that if they do, there will be compatibility issues for
>>> unstable bindings.
>>
>> As long as we can make sufficiently clear that trying to use an unstable
>> binding is going to be *very* painful, and not necessarily supported.
> 
> Oh, man.
> 
> The introduction of DT into ARM Linux was supposed to make everyone's
> life sooo much easier. Of course, based on experience with powerpc, I
> never believed it*, but still I would expect to hear that the DT
> bindings are, well, a *binding* contract between the board developer,
> boot loader, and the kernel.
> 
> Once it is working with a particular kernel, a DT board description
> file should continue to work indefinitely with newer kernels. Anything
> less is a regression, pure and simple.
> 
> If you go around changing the bindings willy nilly, then what is point
> of having DT at all?

That's exactly why we're starting to think about which bindings should
be considered stable and immutable, and when that should happen. As Olof
pointed out, we haven't fully enforced that yet. Preferably bindings
will be marked stable very fast, but mistakes are always going to happen
in early development. ABIs are very hard.


From santosh.shilimkar at ti.com  Thu Jul 25 14:53:53 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 25 Jul 2013 14:53:53 -0400
Subject: [PATCH 6/8] ARM: mm: LPAE: Correct virt_to_phys patching for
 64 bit physical addresses
In-Reply-To: <51F0A051.20203@ti.com>
References: <1371858502-10083-1-git-send-email-santosh.shilimkar@ti.com>
 <1371858502-10083-7-git-send-email-santosh.shilimkar@ti.com>
 <alpine.LFD.2.03.1307231850350.15022@syhkavp.arg> <51EF356D.2050902@ti.com>
 <alpine.LFD.2.03.1307232222200.15022@syhkavp.arg> <51EFBF8F.4010201@ti.com>
 <51EFC37B.80906@ti.com> <alpine.LFD.2.03.1307241456260.15022@syhkavp.arg>
 <51F0A051.20203@ti.com>
Message-ID: <51F17441.3000503@ti.com>

On Wednesday 24 July 2013 11:49 PM, Sricharan R wrote:
> Hi Nicolas,
> 
> On Thursday 25 July 2013 01:51 AM, Nicolas Pitre wrote:

[..]

>> I don't think I follow you here.
>>
>> Let's assume:
>>
>> phys_addr_t __pv_offset = PHYS_START - VIRT_START;
>>
>> If PA = 0x0-8000-0000 and VA = 0xc000-0000 then
>> __pv_offset = 0xffff-ffff-c000-0000.
>>
>> If PA = 0x2-8000-0000 and VA = 0xc000-0000 then
>> __pv_offset = 0x1-c000-0000.
>>
>> So the __virt_to_phys() assembly stub could look like:
>>
>> static inline phys_addr_t __virt_to_phys(unsigned long x)
>> {
>> 	phys_addr_t t;
>>
>> 	if if (sizeof(phys_addr_t) == 4) {
>> 		__pv_stub(x, t, "add", __PV_BITS_31_24);
>> 	} else {
>> 		__pv_movhi_stub(t);
>> 		__pv_add_carry_stub(x, t);
>> 	}
>>
>> 	return t;
>> }
>>
>> And...
>>
>> #define __pv_movhi_stub(y) \
>> 	__asm__("@ __pv_movhi_stub\n" \
>> 	"1:	mov	%R0, %1\n" \
>> 	"	.pushsection .pv_table,\"a\"\n" \
>> 	"	.long	1b\n" \
>> 	"	.popsection\n" \
>> 	: "=r" (y) \
>> 	: "I" (__PV_BITS_8_0))
>>
>> #define __pv_add_carry_stub(x, y) \
>> 	__asm__("@ __pv_add_carry_stub\n" \
>> 	"1:	adds	%Q0, %1, %2\n" \
>> 	"	adc	%R0, %R0, #0\n" \
>> 	"	.pushsection .pv_table,\"a\"\n" \
>> 	"	.long	1b\n" \
>> 	"	.popsection\n" \
>> 	: "+r" (y) \
>> 	: "r" (x), "I" (__PV_BITS_31_24) \
>> 	: "cc")
>>
>> The stub bits such as __PV_BITS_8_0 can be augmented with more bits in 
>> the middle to determine the type of fixup needed.  The fixup code would 
>> determine the shift needed on the value, and whether or not the low or 
>> high word of __pv_offset should be used according to those bits.
>>
>> Then, in the case where a mov is patched, you need to check if the high 
>> word of __pv_offset is 0xffffffff and if so the mov should be turned 
>> into a "mvn rn, #0".
>>
>> And there you are with all possible cases handled.
>>
Brilliant !!
We knew you will have some tricks and better way. We were
not convinced with the extra stub for 'mov' but also didn't
have idea to avoid it.

>   Thanks and you have given the full details here.
> 
>   Sorry if i was not clear on my previous response.
> 
>  1)  When i said special case can be avoided, i meant that
>       we need not differentiate the 0xfffffff case inside the
>       __virt_to_phy macro, but can handle it at the time of patching.
>       Your above code makes that clear.
>  
>  2) I would have ended creating separate tables for 'mov' and 'add'
>       case. But again thanks to your above idea of augumenting the
>       __PV_BITS, with which we can find out run time. And 'mvn' would
>       be needed for moving '0xffffffff' . Now I can get rid
>      of the separate section that i created for 'mov' in my previous
>      version.
> 
We also get rid of calling separate patching for modules as well
as late patching. Overall the patch-set becomes smaller and
simpler. Thanks for help.

Regards,
Santosh


From swarren at wwwdotorg.org  Thu Jul 25 14:50:34 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 25 Jul 2013 11:50:34 -0700
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <CAOesGMiLKysW2JG1jbef76Ves=-DAYEiE9d+s8YXWRXUJ+XhaQ@mail.gmail.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <CAOesGMiLKysW2JG1jbef76Ves=-DAYEiE9d+s8YXWRXUJ+XhaQ@mail.gmail.com>
Message-ID: <51F1737A.9020205@wwwdotorg.org>

On 07/25/2013 11:25 AM, Olof Johansson wrote:
> On Thu, Jul 25, 2013 at 11:05 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
...
>> On another related topic, something that may be useful for the DT
>> bindings reviewer team is a basic checklist for new DT bindings.
>> Something similar to Fedora's package review checklist. Perhaps also
>> (yet another?) document on a bit of DT philosophy. If this sounds
>> useful, I could try and take a stab at some basic initial version.
> 
> Sounds reasonable. Starting with one of the existing ones instead of
> from scratch is a reasonable approach. A checklist and a best
> practices doc would come a long way.

Do you have a link to an existing check-list? I know there's plenty of
best practices information out there to build on.

>> We also need to decide (or just document) exactly what "describes the
>> HW" means; see the thread on thermal limits, and consider the extension
>> of describing hard/absolute thermal limits to describing use-cased base
>> thermal profiles using the same schema, or not allowing that.
> 
> Yes indeed. A basic binding need just specify what the specific
> hardware IP is, if the rest of the configuration of the IP can be
> determined at runtime through other means (i.e. by autoprobing). It's
> stuff beyond that that gets very complicated.
> 
> To talk semi-specifics: What about USB PHY tunings for a specific
> board,

I was thinking more about the slightly blurry line between representing
HW and representing policy, but the example you gave certainly needs
consideration too.


From jason at lakedaemon.net  Thu Jul 25 15:02:46 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 15:02:46 -0400
Subject: [PATCHv5 00/11] MSI support for Marvell EBU PCIe driver
In-Reply-To: <20130725184920.GC18584@dhcp-172-17-186-34.nvidia.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E4167B.4000208@wwwdotorg.org> <20130716104347.045a612a@skate>
 <20130716131547.GC12062@titan.lakedaemon.net>
 <20130716153911.423cc408@skate>
 <20130725184920.GC18584@dhcp-172-17-186-34.nvidia.com>
Message-ID: <20130725190246.GR23879@titan.lakedaemon.net>

Thomas (tglx), Russell (rmk),

Please see my request below.

On Thu, Jul 25, 2013 at 11:49:21AM -0700, Thierry Reding wrote:
> On Tue, Jul 16, 2013 at 03:39:11PM +0200, Thomas Petazzoni wrote:
> > Dear Jason Cooper,
> > 
> > On Tue, 16 Jul 2013 09:15:47 -0400, Jason Cooper wrote:
> > 
> > > > A quick diagram of the dependencies, best viewed with a fixed-size font
> > > > mailer.
> > > > 
> > > > kernel/irq/irqdomain    drivers/pci        arch/arm/kernel
> > > >      patch 1           patch 2, 3, 4           patch 8
> > > >         ||                  ||                   ||
> > > >         ||                  \/                   \/
> > > >         ||               drivers/of   ==> drivers/pci/host
> > > >         ||                patch 5           patch 10
> > > >         ||                  ||
> > > >         \\__________________//
> > > >                   ||
> > > >                   \/
> > > >             drivers/irqchip
> > > >               patch 6, 7
> > > 
> > > Well, that got more complicated.  :(  No cookie for you.
> > 
> > Yeah, sorry about this. I'm not sure how to handle that differently.
> > 
> > > > Patches 9 and 11 are DT patches, so they are not mentioned in this
> > > > diagram.
> > > > 
> > > > Normally tegra would require 1, 2, 3, 4, 5 and 8, so ideally, with
> > > > the respective maintainers ACKs, Jason Cooper could take them in a
> > > > specific topic stable branch that would not be rebased, on top of which
> > > > both the Marvell work and Tegra work could be done.
> > > 
> > > After my recent discussions with tglx, here's my proposal:
> > > 
> > > - rmk creates a dedicated topic branch with patch 8
> > > 
> > > - Bjorn creates a dedicated topic branch based on rmk's with 2, 3, 4, 5,
> > >   and 10
> > > 
> > > - tglx creates a dedicated topic branch based on Bjorn's with 1, 6, 7
> > 
> > I am wondering if this merge strategy isn't too complicated to work
> > nicely. Would it be easier if one person took all of those patches in a
> > stable topic branch, with the ACKs from the proper maintainers?
> > 
> > But anyway, as long as things get merged, I don't really mind what
> > merge strategy is used, so I'll trust on what will be the best option
> > on this.
> > 
> > Thanks a lot for taking care of this!
> 
> Hi Thomas, Jason,
> 
> I've talked this over with Stephen and he'd be willing to create the
> stable branch with patches 2, 4 and 8. That could serve as the basis
> for both Tegra and Marvell.
> 
> Given that there are no cross-dependencies for any of the other patches
> (that I'm aware of) it would probably be easier to take them through the
> Marvell tree if Bjorn and Thomas (tglx) agree to Ack the patches.

Ok, this is getting complicated again. :(  I'm all for adhering to
Thomas' (tglx) request that all clocksource and irqchip patches go
through his tree.  However, this series is just a hot-dependency mess.

Thomas, Russell, can you please cut me a little slack on this series and
Ack your respective patches (tglx: #1, #6, #7; rmk: #8) for going
through arm-soc?

I know it's not the proper way, but I could have this series in -next
tomorrow with a public branch for Thierry.  The alternative is turning
into a Rube Goldberg machine [1].

thx,

Jason.

[1] https://en.wikipedia.org/wiki/Rube_Goldberg_machine


From nicolas.pitre at linaro.org  Thu Jul 25 15:11:06 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 25 Jul 2013 15:11:06 -0400 (EDT)
Subject: [PATCH 02/13] ARM: gic: add CPU migration support
In-Reply-To: <51F10F85.7090508@arm.com>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-3-git-send-email-nicolas.pitre@linaro.org>
 <51F10F85.7090508@arm.com>
Message-ID: <alpine.LFD.2.03.1307251207110.15022@syhkavp.arg>

On Thu, 25 Jul 2013, Jonathan Austin wrote:

> Hi Nico,
> 
> I've got a couple of minor questions/comments about this one...
> 
> On 23/07/13 04:31, Nicolas Pitre wrote:
> > This is required by the big.LITTLE switcher code.
> > 
> > The gic_migrate_target() changes the CPU interface mapping for the
> > current CPU to redirect SGIs to the specified interface, and it also
> > updates the target CPU for each interrupts to that CPU interface
> > if they were targeting the current interface.  Finally, pending
> > SGIs for the current CPU are forwarded to the new interface.
> > 
> > Because Linux does not use it, the SGI source information for the
> > forwarded SGIs is not preserved.  Neither is the source information
> > for the SGIs sent by the current CPU to other CPUs adjusted to match
> > the new CPU interface mapping.  The required registers are banked so
> > only the target CPU could do it.
> > 
> > Signed-off-by: Nicolas Pitre <nico at linaro.org>
> > ---
> >   drivers/irqchip/irq-gic.c       | 81
> > +++++++++++++++++++++++++++++++++++++++--
> >   include/linux/irqchip/arm-gic.h |  4 ++
> >   2 files changed, 82 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> > index ee7c503120..6bd5a8c1aa 100644
> > --- a/drivers/irqchip/irq-gic.c
> > +++ b/drivers/irqchip/irq-gic.c
> > @@ -253,10 +253,9 @@ static int gic_set_affinity(struct irq_data *d, const
> > struct cpumask *mask_val,
> >   	if (cpu >= NR_GIC_CPU_IF || cpu >= nr_cpu_ids)
> >   		return -EINVAL;
> > 
> > +	raw_spin_lock(&irq_controller_lock);
> >   	mask = 0xff << shift;
> >   	bit = gic_cpu_map[cpu] << shift;
> > -
> > -	raw_spin_lock(&irq_controller_lock);
> >   	val = readl_relaxed(reg) & ~mask;
> >   	writel_relaxed(val | bit, reg);
> >   	raw_spin_unlock(&irq_controller_lock);
> > @@ -646,7 +645,9 @@ static void __init gic_pm_init(struct gic_chip_data
> > *gic)
> >   void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> >   {
> >   	int cpu;
> > -	unsigned long map = 0;
> > +	unsigned long flags, map = 0;
> > +
> > +	raw_spin_lock_irqsave(&irq_controller_lock, flags);
> > 
> >   	/* Convert our logical CPU mask into a physical one. */
> >   	for_each_cpu(cpu, mask)
> > @@ -660,6 +661,80 @@ void gic_raise_softirq(const struct cpumask *mask,
> > unsigned int irq)
> > 
> >   	/* this always happens on GIC0 */
> >   	writel_relaxed(map << 16 | irq, gic_data_dist_base(&gic_data[0]) +
> > GIC_DIST_SOFTINT);
> > +
> > +	raw_spin_unlock_irqrestore(&irq_controller_lock, flags);
> > +}
> > +#endif
> > +
> > +#ifdef CONFIG_BL_SWITCHER
> > +/*
> > + * gic_migrate_target - migrate IRQs to another PU interface
> 
> (nit) Should that be _C_PU?

Obviously.

> > + *
> > + * @new_cpu_id: the CPU target ID to migrate IRQs to
> > + *
> > + * Migrate all peripheral interrupts with a target matching the current CPU
> > + * to the interface corresponding to @new_cpu_id.  The CPU interface
> > mapping
> > + * is also updated.  Targets to other CPU interfaces are unchanged.
> > + * This must be called with IRQs locally disabled.
> > + */
> > +void gic_migrate_target(unsigned int new_cpu_id)
> > +{
> > +	unsigned int old_cpu_id, gic_irqs, gic_nr = 0;
> > +	void __iomem *dist_base;
> > +	int i, ror_val, cpu = smp_processor_id();
> > +	u32 val, old_mask, active_mask;
> > +
> > +	if (gic_nr >= MAX_GIC_NR)
> > +		BUG();
> > +
> > +	dist_base = gic_data_dist_base(&gic_data[gic_nr]);
> > +	if (!dist_base)
> > +		return;
> > +	gic_irqs = gic_data[gic_nr].gic_irqs;
> > +
> > +	old_cpu_id = __ffs(gic_cpu_map[cpu]);
> > +	old_mask = 0x01010101 << old_cpu_id;
> 
> I don't think this is very clear, though section 4.3.12 of the GIC spec helps
> a lot! A little pointer or some more self-evident name for the mask might be
> nice...
> 
> old_mask = GIC_ITARGETSR_MASK << old_cpu_id
> 
> or similar? This at least points one to the right bit of documentation?

I've renamed old_cpu_id to cur_cpu_id and old_mask to cur_target_mask.
Also added a comment later on.

> > +	ror_val = (old_cpu_id - new_cpu_id) & 31;
> > +
> > +	raw_spin_lock(&irq_controller_lock);
> > +
> > +	gic_cpu_map[cpu] = 1 << new_cpu_id;
> > +
> > +	for (i = 8; i < DIV_ROUND_UP(gic_irqs, 4); i++) {
> 
> Does this '8' here warrant a #define? GIC_RO_INTR_REGS?
> 
> Perhaps everyone looking at the code will be familiar enough with the GIC to
> see immediately why the first 8 entries are being skipped...?

I've added a comment right before this loop explaining what is being 
done, mentioning why it starts at 8.

> I'm curious as to why we don't need to do anything for PPIs here - could there
> be any pending PPIs that don't get handled (I guess retargetting doesn't make
> sense for these?)

PPIs are strictly processor private and I don't think there is any way 
for one processor to set them on another processor.  So the only way to 
cope with those is for the outbound CPU to save and disable its PPI 
state, and let the inbound CPU enable them.  That should be up to each 
PPI-using driver to do via the cpu_pm_enter()/cpu_pm_exit() notifiers.

I've amended the patch with the following:

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 6bd5a8c1aa..268874ac75 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -668,7 +668,7 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
 
 #ifdef CONFIG_BL_SWITCHER
 /*
- * gic_migrate_target - migrate IRQs to another PU interface
+ * gic_migrate_target - migrate IRQs to another CPU interface
  *
  * @new_cpu_id: the CPU target ID to migrate IRQs to
  *
@@ -679,10 +679,10 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
  */
 void gic_migrate_target(unsigned int new_cpu_id)
 {
-	unsigned int old_cpu_id, gic_irqs, gic_nr = 0;
+	unsigned int cur_cpu_id, gic_irqs, gic_nr = 0;
 	void __iomem *dist_base;
 	int i, ror_val, cpu = smp_processor_id();
-	u32 val, old_mask, active_mask;
+	u32 val, cur_target_mask, active_mask;
 
 	if (gic_nr >= MAX_GIC_NR)
 		BUG();
@@ -692,17 +692,23 @@ void gic_migrate_target(unsigned int new_cpu_id)
 		return;
 	gic_irqs = gic_data[gic_nr].gic_irqs;
 
-	old_cpu_id = __ffs(gic_cpu_map[cpu]);
-	old_mask = 0x01010101 << old_cpu_id;
-	ror_val = (old_cpu_id - new_cpu_id) & 31;
+	cur_cpu_id = __ffs(gic_cpu_map[cpu]);
+	cur_target_mask = 0x01010101 << cur_cpu_id;
+	ror_val = (cur_cpu_id - new_cpu_id) & 31;
 
 	raw_spin_lock(&irq_controller_lock);
 
+	/* Update the target interface for this logical CPU */
 	gic_cpu_map[cpu] = 1 << new_cpu_id;
 
+	/*
+	 * Find all the peripheral interrupts targetting the current
+	 * CPU interface and migrate them to the new CPU interface.
+	 * We skip DIST_TARGET 0 to 7 as they are read-only.
+	 */
 	for (i = 8; i < DIV_ROUND_UP(gic_irqs, 4); i++) {
 		val = readl_relaxed(dist_base + GIC_DIST_TARGET + i * 4);
-		active_mask = val & old_mask;
+		active_mask = val & cur_target_mask;
 		if (active_mask) {
 			val &= ~active_mask;
 			val |= ror32(active_mask, ror_val);
@@ -714,7 +720,7 @@ void gic_migrate_target(unsigned int new_cpu_id)
 
 	/*
 	 * Now let's migrate and clear any potential SGIs that might be
-	 * pending for us (old_cpu_id).  Since GIC_DIST_SGI_PENDING_SET
+	 * pending for us (cur_cpu_id).  Since GIC_DIST_SGI_PENDING_SET
 	 * is a banked register, we can only forward the SGI using
 	 * GIC_DIST_SOFTINT.  The original SGI source is lost but Linux
 	 * doesn't use that information anyway.


From robherring2 at gmail.com  Thu Jul 25 15:11:31 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 25 Jul 2013 14:11:31 -0500
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
Message-ID: <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>

On Thu, Jul 25, 2013 at 11:09 AM, Olof Johansson <olof at lixom.net> wrote:
> [I'm adding LKML and ksummit-discuss to this thread, since the ACPI/DT
> discussions have been covered there and this overlaps some with that]
>
> On Thu, Jul 25, 2013 at 7:38 AM, Catalin Marinas
> <catalin.marinas at arm.com> wrote:
>> On Thu, Jul 25, 2013 at 03:27:02PM +0100, Russell King - ARM Linux wrote:
>>> Remember the stated assertion when DT was first added to the kernel: the
>>> DT descriptions _will_ become a separately maintained project which is
>>> independent of the kernel.  They will _not_ be kernel version specific.
>>
>> I'm looking forward to this.
>>
>> Question for the DT guys: what are the plans here? Are we going to get
>> rid of the .dts files inside the kernel tree?
>
> In the discussions we had in Dublin, a couple of options on how to
> lock in bindings were discussed. I'm a little surprised that Grant
> didn't cover them in his initial emails on the new maintainership
> model, but maybe he wanted the new group to handle it. And they didn't
> bring it up yet either. So I am. :-)
>
> Until now, we have been working under the assumption that the bindings
> are _NOT LOCKED_. I.e. they can change as needed, and we _ARE_
> assuming that the device tree has to match the kernel. That has been a
> good choice as people get up to speed on what is a good binding and
> not, and has given us much-needed room to adjust things as needed.
> That obviously has to change, but doing so needs to be done carefully.

I would argue that little has gone in (if reviewed) with the
expectation that the binding will change. Many of the common bindings
have had many rounds of review and they have not changed. My position
any time I see an incompatible change has been that it require anyone
affected to be okay with the change. This has pretty much been limited
to specific platforms from what I've seen.

One area we've gotten into trouble is using ePAPR based bindings and
then deciding those aren't sufficient. For cpu bindings, we've gone
from the cores are describable we don't need them in DT to following
ePAPR to some level to more fully describing cpu info including
topology.

> It's likely that we still want to have a period in which a binding is
> tentative and can be changed. Sometimes we don't know what we really
> want until after we've used it a while, and sometimes we, like
> everybody else, make mistakes on what is a good idea and not. The
> alternative is to grind most new binding proposals to a halt while we
> spend mind-numbing hours and hours on polishing every single aspect of
> the binding to a perfect shine, since we can't go back and fix it.
>
> So, there really seems to be a need for a layered approach, one in
> which a binding "graduates" from being tentative to being locked in.
> I'm refraining from using the terms "staging" and "stable" here, since
> they have overloaded meaning in the kernel world that doesn't apply
> here.

+1

Tentative must still be reviewed to the same level bindings which have
been reviewed up to now were.

> One problem that needs to be solved is obviously how a binding
> graduates from tentative to locked. This work isn't going to be very
> interesting to most people, I suspect. Think standards committee type
> work.

I think a time based stabilization period would be better than a
separate directory to apply bindings too. Or time plus periodic review
perhaps.

> A possible way to handle this is to have exactly that: A group of
> people that essentially constitute the "standards committee" that meet
> on a regular basis to review and approve new bindings. They should be
> people not just doing ARM Linux work, but other stakeholders in these
> bindings too. One of the things they should probably do is sift
> through our current in-kernel bindings and select those who seem ready
> to be locked in, review/discuss/decide upon that and once the decision
> is made, that specific binding does become part of the static,
> never-ever-change ABI of firmware-to-kernel interfaces.   That might
> also be the time that the binding is moved from the kernel to a
> separate repo, but that's a technicality that we'll let the DT
> maintainers decide among themselves, IMHO.

Seems like a good plan.

Rob

>
> I think that captures most of what we discussed in person. Others
> might have changed their opinions since then, so I'm definitely not
> claiming that any of this was an official decision made by anybody.
> It's just one proposal on how to handle these things moving forward.
>
>
> -Olof
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From nicolas.pitre at linaro.org  Thu Jul 25 15:22:16 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 25 Jul 2013 15:22:16 -0400 (EDT)
Subject: [PATCH v2 4/6] ARM: locks: prefetch the destination word for
 write prior to strex
In-Reply-To: <1374767740-2068-5-git-send-email-will.deacon@arm.com>
References: <1374767740-2068-1-git-send-email-will.deacon@arm.com>
 <1374767740-2068-5-git-send-email-will.deacon@arm.com>
Message-ID: <alpine.LFD.2.03.1307251521490.15022@syhkavp.arg>

On Thu, 25 Jul 2013, Will Deacon wrote:

> The cost of changing a cacheline from shared to exclusive state can be
> significant, especially when this is triggered by an exclusive store,
> since it may result in having to retry the transaction.
> 
> This patch prefixes our {spin,read,write}_[try]lock implementations with
> pldw instructions (on CPUs which support them) to try and grab the line
> in exclusive state from the start. arch_rwlock_t is changed to avoid
> using a volatile member, since this generates compiler warnings when
> falling back on the __builtin_prefetch intrinsic which expects a const
> void * argument.
> 
> Signed-off-by: Will Deacon <will.deacon at arm.com>

Acked-by: Nicolas Pitre <nico at linaro.org>

> ---
>  arch/arm/include/asm/spinlock.h       | 13 ++++++++++---
>  arch/arm/include/asm/spinlock_types.h |  2 +-
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
> index 0de7bec..3c8c532 100644
> --- a/arch/arm/include/asm/spinlock.h
> +++ b/arch/arm/include/asm/spinlock.h
> @@ -5,7 +5,7 @@
>  #error SMP not supported on pre-ARMv6 CPUs
>  #endif
>  
> -#include <asm/processor.h>
> +#include <linux/prefetch.h>
>  
>  /*
>   * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
> @@ -70,6 +70,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
>  	u32 newval;
>  	arch_spinlock_t lockval;
>  
> +	prefetchw(&lock->slock);
>  	__asm__ __volatile__(
>  "1:	ldrex	%0, [%3]\n"
>  "	add	%1, %0, %4\n"
> @@ -93,6 +94,7 @@ static inline int arch_spin_trylock(arch_spinlock_t *lock)
>  	unsigned long contended, res;
>  	u32 slock;
>  
> +	prefetchw(&lock->slock);
>  	do {
>  		__asm__ __volatile__(
>  		"	ldrex	%0, [%3]\n"
> @@ -145,6 +147,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
>  {
>  	unsigned long tmp;
>  
> +	prefetchw(&rw->lock);
>  	__asm__ __volatile__(
>  "1:	ldrex	%0, [%1]\n"
>  "	teq	%0, #0\n"
> @@ -163,6 +166,7 @@ static inline int arch_write_trylock(arch_rwlock_t *rw)
>  {
>  	unsigned long tmp;
>  
> +	prefetchw(&rw->lock);
>  	__asm__ __volatile__(
>  "	ldrex	%0, [%1]\n"
>  "	teq	%0, #0\n"
> @@ -193,7 +197,7 @@ static inline void arch_write_unlock(arch_rwlock_t *rw)
>  }
>  
>  /* write_can_lock - would write_trylock() succeed? */
> -#define arch_write_can_lock(x)		((x)->lock == 0)
> +#define arch_write_can_lock(x)		(ACCESS_ONCE((x)->lock) == 0)
>  
>  /*
>   * Read locks are a bit more hairy:
> @@ -211,6 +215,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
>  {
>  	unsigned long tmp, tmp2;
>  
> +	prefetchw(&rw->lock);
>  	__asm__ __volatile__(
>  "1:	ldrex	%0, [%2]\n"
>  "	adds	%0, %0, #1\n"
> @@ -231,6 +236,7 @@ static inline void arch_read_unlock(arch_rwlock_t *rw)
>  
>  	smp_mb();
>  
> +	prefetchw(&rw->lock);
>  	__asm__ __volatile__(
>  "1:	ldrex	%0, [%2]\n"
>  "	sub	%0, %0, #1\n"
> @@ -249,6 +255,7 @@ static inline int arch_read_trylock(arch_rwlock_t *rw)
>  {
>  	unsigned long tmp, tmp2 = 1;
>  
> +	prefetchw(&rw->lock);
>  	__asm__ __volatile__(
>  "	ldrex	%0, [%2]\n"
>  "	adds	%0, %0, #1\n"
> @@ -262,7 +269,7 @@ static inline int arch_read_trylock(arch_rwlock_t *rw)
>  }
>  
>  /* read_can_lock - would read_trylock() succeed? */
> -#define arch_read_can_lock(x)		((x)->lock < 0x80000000)
> +#define arch_read_can_lock(x)		(ACCESS_ONCE((x)->lock) < 0x80000000)
>  
>  #define arch_read_lock_flags(lock, flags) arch_read_lock(lock)
>  #define arch_write_lock_flags(lock, flags) arch_write_lock(lock)
> diff --git a/arch/arm/include/asm/spinlock_types.h b/arch/arm/include/asm/spinlock_types.h
> index b262d2f..47663fc 100644
> --- a/arch/arm/include/asm/spinlock_types.h
> +++ b/arch/arm/include/asm/spinlock_types.h
> @@ -25,7 +25,7 @@ typedef struct {
>  #define __ARCH_SPIN_LOCK_UNLOCKED	{ { 0 } }
>  
>  typedef struct {
> -	volatile unsigned int lock;
> +	u32 lock;
>  } arch_rwlock_t;
>  
>  #define __ARCH_RW_LOCK_UNLOCKED		{ 0 }
> -- 
> 1.8.2.2
> 


From jason at lakedaemon.net  Thu Jul 25 15:24:14 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 15:24:14 -0400
Subject: [ANNOUNCE] mvebu tree move
Message-ID: <20130725192414.GS23879@titan.lakedaemon.net>

All,

We have set up a group tree for the mvebu maintainers to collaboratively
break. ;-)  The new tree can be found at:

  git://git.infradead.org/linux-mvebu.git

The old tree has been cleaned up a bit and will not be used for mainlining
work.

While I have your attention, here's a quick breakdown of the branch
layout:

# patches for -stable trees, branches are based on a common ancestor, eg
# v3.10 for stable-3.10.x

  mvebu/stable-*

# patches for the current merge window (currently, v3.11-rcX)

  mvebu/fixes

# patches the next merge window (currently v3.12)

  mvebu/fixes-non-critical
  mvebu/cleanup
  mvebu/drivers
  mvebu/soc
  mvebu/boards
  mvebu/defconfig
  mvebu/dt

# a merge of all mvebu/* branches for pulling into linux-next for
# testing.  ** rebased frequently **

  for-next

wrt to stability of branches, mvebu/* branches can be considered stable
up to *signed* tags we have sent PRs for.  Once a branch is pulled into
arm-soc it *can't* be changed because that will cause heartache and
discontent in linux-next between mvebu and arm-soc.

Thanks to David Woodhouse for setting this up on git.infradead.org for
us.

thx,

Jason.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130725/8ee3d578/attachment.sig>

From broonie at kernel.org  Thu Jul 25 15:30:42 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 25 Jul 2013 20:30:42 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <CAOesGMiLKysW2JG1jbef76Ves=-DAYEiE9d+s8YXWRXUJ+XhaQ@mail.gmail.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <CAOesGMiLKysW2JG1jbef76Ves=-DAYEiE9d+s8YXWRXUJ+XhaQ@mail.gmail.com>
Message-ID: <20130725193042.GS9858@sirena.org.uk>

On Thu, Jul 25, 2013 at 11:25:30AM -0700, Olof Johansson wrote:

> To talk semi-specifics: What about USB PHY tunings for a specific
> board, where each of the three USB ports and their registers have
> slightly different layout? Sure, we can take 10 properties to describe
> each tunable field in each register, but at the end it will just be
> used to craft the contents blindly, so we might just stuff the 32-bit
> register value as a property instead. And in other cases we might
> indeed want to describe each property independently. Determining what
> is appropriate when is one of the most difficult parts of the review
> workflow.

There's also my constant question about why the driver can't just work
out the right value or decide to use the feature autonomously at runtime
- I'd say that the overwhelming proportion of properties I push back on
end up just getting removed and worked out automatically.
-------------- 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/20130725/506c2a35/attachment.sig>

From jason at lakedaemon.net  Thu Jul 25 15:31:35 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 15:31:35 -0400
Subject: DT bindings as ABI [was: Do we have people interested in
 device tree janitoring / cleanup?]
In-Reply-To: <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
Message-ID: <20130725193135.GT23879@titan.lakedaemon.net>

On Thu, Jul 25, 2013 at 02:11:31PM -0500, Rob Herring wrote:
> On Thu, Jul 25, 2013 at 11:09 AM, Olof Johansson <olof at lixom.net> wrote:

> > One problem that needs to be solved is obviously how a binding
> > graduates from tentative to locked. This work isn't going to be very
> > interesting to most people, I suspect. Think standards committee type
> > work.
> 
> I think a time based stabilization period would be better than a
> separate directory to apply bindings too. Or time plus periodic review
> perhaps.

The only problem with a time-based versus separate directory is how do
users who've downloaded the tree determine which bindings are stable?
If they pull a tarball, or receive an SDK, there is most likely no git
history attached.

I think the idea of a 'tentative' directory (or 'locked') is churnish,
but necessary.  If I DL'd a tarball and had to type 'tentative' to get
to the binding doc I wanted, that would be a pretty clear clue to be
delicate about how I trust/use/plan with that binding.

thx,

Jason.


From jason at lakedaemon.net  Thu Jul 25 16:04:16 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 16:04:16 -0400
Subject: [PATCH 1/2] ARM: Kirkwood: Add support for another ZyXEL
 NSA310 variant
In-Reply-To: <1374079910-24345-2-git-send-email-andrew@lunn.ch>
References: <1374079910-24345-1-git-send-email-andrew@lunn.ch>
 <1374079910-24345-2-git-send-email-andrew@lunn.ch>
Message-ID: <20130725200416.GU23879@titan.lakedaemon.net>

On Wed, Jul 17, 2013 at 06:51:49PM +0200, Andrew Lunn wrote:
> There are a number of variants of the ZyXEL NSA310, with slightly
> different LEDs, buttons and i2c devices. Add a DTS file to support one
> more of these variants.
> 
> Signed-off-by: Andrew Lunn <andrew at lunn.ch>
> ---
>  arch/arm/boot/dts/Makefile                    |    1 +
>  arch/arm/boot/dts/kirkwood-nsa310-common.dtsi |  107 ++++++++++++++++
>  arch/arm/boot/dts/kirkwood-nsa310.dts         |  100 +--------------
>  arch/arm/boot/dts/kirkwood-nsa310a.dts        |  165 +++++++++++++++++++++++++
>  4 files changed, 274 insertions(+), 99 deletions(-)
>  create mode 100644 arch/arm/boot/dts/kirkwood-nsa310-common.dtsi
>  create mode 100644 arch/arm/boot/dts/kirkwood-nsa310a.dts

Applied to mvebu/dt

thx,

Jason.


From broonie at kernel.org  Thu Jul 25 16:04:35 2013
From: broonie at kernel.org (Mark Brown)
Date: Thu, 25 Jul 2013 21:04:35 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130725193135.GT23879@titan.lakedaemon.net>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
 <20130725193135.GT23879@titan.lakedaemon.net>
Message-ID: <20130725200435.GW9858@sirena.org.uk>

On Thu, Jul 25, 2013 at 03:31:35PM -0400, Jason Cooper wrote:

> I think the idea of a 'tentative' directory (or 'locked') is churnish,
> but necessary.  If I DL'd a tarball and had to type 'tentative' to get
> to the binding doc I wanted, that would be a pretty clear clue to be
> delicate about how I trust/use/plan with that binding.

Another option for this is to annotate within the document itself.
-------------- 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/20130725/8a18c880/attachment-0001.sig>

From jason at lakedaemon.net  Thu Jul 25 16:08:13 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 16:08:13 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130725200435.GW9858@sirena.org.uk>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
 <20130725193135.GT23879@titan.lakedaemon.net>
 <20130725200435.GW9858@sirena.org.uk>
Message-ID: <20130725200813.GV23879@titan.lakedaemon.net>

On Thu, Jul 25, 2013 at 09:04:35PM +0100, Mark Brown wrote:
> On Thu, Jul 25, 2013 at 03:31:35PM -0400, Jason Cooper wrote:
> 
> > I think the idea of a 'tentative' directory (or 'locked') is churnish,
> > but necessary.  If I DL'd a tarball and had to type 'tentative' to get
> > to the binding doc I wanted, that would be a pretty clear clue to be
> > delicate about how I trust/use/plan with that binding.
> 
> Another option for this is to annotate within the document itself.

True, and this would make it easier to mark reg, interrupts, etc as
stable, and eg 'ti,hwmods' as unstable.  However, it could get pretty
messy.  Perhaps moving to a schema would help with that.

thx,

Jason.


From jason at lakedaemon.net  Thu Jul 25 16:09:03 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 16:09:03 -0400
Subject: [PATCH 2/2] ARM: Kirkwood: update defconfig for used i2c
 devices, EXT4 FS, r8169
In-Reply-To: <1374079910-24345-3-git-send-email-andrew@lunn.ch>
References: <1374079910-24345-1-git-send-email-andrew@lunn.ch>
 <1374079910-24345-3-git-send-email-andrew@lunn.ch>
Message-ID: <20130725200903.GW23879@titan.lakedaemon.net>

On Wed, Jul 17, 2013 at 06:51:50PM +0200, Andrew Lunn wrote:
> Various kirkwood boards make use of i2c devices. Ensure the defconfig
> builds them. Also, EXT4 FS is also common on NAS boxes, so include it
> as well. And lastly, NSA310 has a RealTek 8169 onboard.
> 
> Signed-off-by: Andrew Lunn <andrew at lunn.ch>
> ---
>  arch/arm/configs/kirkwood_defconfig |   10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)

Applied to mvebu/defconfig

thx,

Jason.


From robherring2 at gmail.com  Thu Jul 25 16:16:14 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Thu, 25 Jul 2013 15:16:14 -0500
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130725193135.GT23879@titan.lakedaemon.net>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
 <20130725193135.GT23879@titan.lakedaemon.net>
Message-ID: <CAL_Jsq+vWbTb8wNEDCR2c_M6sBnKW6e5HGk48QzmXSujQUdddA@mail.gmail.com>

On Thu, Jul 25, 2013 at 2:31 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> On Thu, Jul 25, 2013 at 02:11:31PM -0500, Rob Herring wrote:
>> On Thu, Jul 25, 2013 at 11:09 AM, Olof Johansson <olof at lixom.net> wrote:
>
>> > One problem that needs to be solved is obviously how a binding
>> > graduates from tentative to locked. This work isn't going to be very
>> > interesting to most people, I suspect. Think standards committee type
>> > work.
>>
>> I think a time based stabilization period would be better than a
>> separate directory to apply bindings too. Or time plus periodic review
>> perhaps.
>
> The only problem with a time-based versus separate directory is how do
> users who've downloaded the tree determine which bindings are stable?
> If they pull a tarball, or receive an SDK, there is most likely no git
> history attached.

Well, if time based includes moving the binding out of the kernel,
then that is what defines it as stable or not. I guess that is a form
of a separate directory. I don't think we want to be moving bindings
twice: tentative -> stable and kernel -> DT repo.

The policy could be as simple as an binding without change in at least
N kernel releases is moved out and stable.

Rob


From nicolas.pitre at linaro.org  Thu Jul 25 16:20:47 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 25 Jul 2013 16:20:47 -0400 (EDT)
Subject: [PATCH 03/13] ARM: b.L: core switcher code
In-Reply-To: <51F15D1E.20309@arm.com>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-4-git-send-email-nicolas.pitre@linaro.org>
 <51F15D1E.20309@arm.com>
Message-ID: <alpine.LFD.2.03.1307251523040.15022@syhkavp.arg>

On Thu, 25 Jul 2013, Jonathan Austin wrote:

> Hi Nico,
> 
> I've got a few more questions here...
> 
> On 23/07/13 04:31, Nicolas Pitre wrote:
> > This is the core code implementing big.LITTLE switcher functionality.
> > Rational for this code is available here:
> > 
> > http://lwn.net/Articles/481055/
> > 
> > The main entry point for a switch request is:
> > 
> > void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
> > 
> > If the calling CPU is not the wanted one, this wrapper takes care of
> > sending the request to the appropriate CPU with schedule_work_on().
> > 
> > At the moment the core switch operation is handled by bL_switch_to()
> > which must be called on the CPU for which a switch is requested.
> > 
> > What this code does:
> > 
> >    * Return early if the current cluster is the wanted one.
> > 
> >    * Close the gate in the kernel entry vector for both the inbound
> >      and outbound CPUs.
> > 
> >    * Wake up the inbound CPU so it can perform its reset sequence in
> >      parallel up to the kernel entry vector gate.
> > 
> >    * Migrate all interrupts in the GIC targeting the outbound CPU
> >      interface to the inbound CPU interface, including SGIs. This is
> >      performed by gic_migrate_target() in drivers/irqchip/irq-gic.c.
> > 
> >    * Call cpu_pm_enter() which takes care of flushing the VFP state to
> >      RAM and save the CPU interface config from the GIC to RAM.
> > 
> >    * Modify the cpu_logical_map to refer to the inbound physical CPU.
> > 
> >    * Call cpu_suspend() which saves the CPU state (general purpose
> >      registers, page table address) onto the stack and store the
> >      resulting stack pointer in an array indexed by the updated
> >      cpu_logical_map, then call the provided shutdown function.
> >      This happens in arch/arm/kernel/sleep.S.
> > 
> > At this point, the provided shutdown function executed by the outbound
> > CPU ungates the inbound CPU. Therefore the inbound CPU:
> > 
> >    * Picks up the saved stack pointer in the array indexed by its MPIDR
> >      in arch/arm/kernel/sleep.S.
> > 
> >    * The MMU and caches are re-enabled using the saved state on the
> >      provided stack, just like if this was a resume operation from a
> >      suspended state.
> > 
> >    * Then cpu_suspend() returns, although this is on the inbound CPU
> >      rather than the outbound CPU which called it initially.
> > 
> >    * The function cpu_pm_exit() is called which effect is to restore the
> >      CPU interface state in the GIC using the state previously saved by
> >      the outbound CPU.
> > 
> >    * Exit of bL_switch_to() to resume normal kernel execution on the
> >      new CPU.
> > 
> > However, the outbound CPU is potentially still running in parallel while
> > the inbound CPU is resuming normal kernel execution, hence we need
> > per CPU stack isolation to execute bL_do_switch().  After the outbound
> > CPU has ungated the inbound CPU, it calls mcpm_cpu_power_down() to:
> > 
> >    * Clean its L1 cache.
> > 
> >    * If it is the last CPU still alive in its cluster (last man standing),
> >      it also cleans its L2 cache and disables cache snooping from the other
> >      cluster.
> > 
> >    * Power down the CPU (or whole cluster).
> > 
> > Code called from bL_do_switch() might end up referencing 'current' for
> > some reasons.  However, 'current' is derived from the stack pointer.
> > With any arbitrary stack, the returned value for 'current' and any
> > dereferenced values through it are just random garbage which may lead to
> > segmentation faults.
> > 
> > The active page table during the execution of bL_do_switch() is also a
> > problem.  There is no guarantee that the inbound CPU won't destroy the
> > corresponding task which would free the attached page table while the
> > outbound CPU is still running and relying on it.
> > 
> > To solve both issues, we borrow some of the task space belonging to
> > the init/idle task which, by its nature, is lightly used and therefore
> > is unlikely to clash with our usage.  The init task is also never going
> > away.
> 
> I had written a comment here about this looking hairy, and asking whether
> you'd considered using dedicated threads for this.
> 
> As I hit the later patches in the series I see that's exactly what you've
> done. Is it really worth keeping the historical solution in here?

I think so.  First, because it is much less code if this is introduced 
without kernel threads while still being fully functional.  Next, even 
with dedicated threads, we do have to play some games with the stack 
nevertheless, although to a lesser extent.  And I'm sure some people 
would have argued that this would have been better without kernel 
threads if they didn't see how it was without them.

> Could build/bisectability be maintained by moving the Kconfig options 
> later in the series, but without requiring the weird init/idle hack to 
> be kept around?

I don't follow you here.

> > Right now the logical CPU number is assumed to be equivalent to the
> > physical CPU number within each cluster. The kernel should also be
> > booted with only one cluster active.  These limitations will be lifted
> > eventually.
> > 
> 
> I just read this aloud in the office and Dave Martin mentioned that the MPIDR
> hashing schemes make this obselete now?

Only in the suspend /resume code path, not in the switcher proper yet. 
That's yet another level of complexity that I prefer to see introduced 
later.

> > Signed-off-by: Nicolas Pitre <nico at linaro.org>
> > ---
> >   arch/arm/Kconfig                   |  17 +++
> >   arch/arm/common/Makefile           |   1 +
> >   arch/arm/common/bL_switcher.c      | 247
> > +++++++++++++++++++++++++++++++++++++
> >   arch/arm/include/asm/bL_switcher.h |  17 +++
> >   4 files changed, 282 insertions(+)
> >   create mode 100644 arch/arm/common/bL_switcher.c
> >   create mode 100644 arch/arm/include/asm/bL_switcher.h
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index ba412e02ec..2c9e5bf734 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1538,6 +1538,23 @@ config MCPM
> >            for (multi-)cluster based systems, such as big.LITTLE based
> >            systems.
> > 
> > +config BIG_LITTLE
> > +       bool "big.LITTLE support (Experimental)"
> > +       depends on CPU_V7 && SMP
> > +       select MCPM
> > +       help
> > +         This option enables support for the big.LITTLE architecture.
> 
> I'm not sure we should describe this as an architecture?
> 
> "This option enables support for big.LITTLE processing"?

Well, maybe "system architecture".  I've certainly seen that somewhere 
in the literature from ARM.

What about:

	  This option enables support selections for the big.LITTLE
	  system architecture.

> What are the plans for/implications of having CONFIG_BIG_LITTLE and
> !CONFIG_BL_SWITCHER?

There is a whole set of config options that should depend on 
CONFIG_BIG_LITTLE, such as the b.L cpufreq driver, or the b.L cpuidle 
driver just posted by Lorenzo (which is now depending on a TC2 config 
but that ought not to stay that way).  So you may decide to have 
big.LITTLE goodies like that but not the switcher.  The switcher is 
always optional, and it might become even more so when proper support 
for HMP scheduling is integrated into the scheduler. Hence the slightly 
different wording for the CONFIG_BIG_LITTLE option I,m suggesting above.

> > +config BL_SWITCHER
> > +       bool "big.LITTLE switcher support"
> > +       depends on BIG_LITTLE && MCPM && HOTPLUG_CPU
> > +       select CPU_PM
> > +       select ARM_CPU_SUSPEND
> > +       help
> > +         The big.LITTLE "switcher" provides the core functionality to
> > +         transparently handle transition between a cluster of A15's
> > +         and a cluster of A7's in a big.LITTLE system.
> > +
> >   choice
> >          prompt "Memory split"
> >          default VMSPLIT_3G
> > diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
> > index 8c60f473e9..2586240d5a 100644
> > --- a/arch/arm/common/Makefile
> > +++ b/arch/arm/common/Makefile
> > @@ -17,3 +17,4 @@ obj-$(CONFIG_MCPM)            += mcpm_head.o mcpm_entry.o
> > mcpm_platsmp.o vlock.o
> >   AFLAGS_mcpm_head.o             := -march=armv7-a
> >   AFLAGS_vlock.o                 := -march=armv7-a
> >   obj-$(CONFIG_TI_PRIV_EDMA)     += edma.o
> > +obj-$(CONFIG_BL_SWITCHER)      += bL_switcher.o
> > diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> > new file mode 100644
> > index 0000000000..e63881b430
> > --- /dev/null
> > +++ b/arch/arm/common/bL_switcher.c
> > @@ -0,0 +1,247 @@
> > +/*
> > + * arch/arm/common/bL_switcher.c -- big.LITTLE cluster switcher core driver
> > + *
> > + * Created by: Nicolas Pitre, March 2012
> > + * Copyright:  (C) 2012-2013  Linaro Limited
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/init.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/sched.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/cpu_pm.h>
> > +#include <linux/workqueue.h>
> > +#include <linux/mm.h>
> > +#include <linux/string.h>
> > +#include <linux/irqchip/arm-gic.h>
> > +
> > +#include <asm/smp_plat.h>
> > +#include <asm/cacheflush.h>
> > +#include <asm/suspend.h>
> > +#include <asm/mcpm.h>
> > +#include <asm/bL_switcher.h>
> > +
> > +
> > +/*
> > + * Use our own MPIDR accessors as the generic ones in asm/cputype.h have
> > + * __attribute_const__ and we don't want the compiler to assume any
> > + * constness here as the value _does_ change along some code paths.
> > + */
> > +
> > +static int read_mpidr(void)
> > +{
> > +       unsigned int id;
> > +       asm volatile ("mrc\tp15, 0, %0, c0, c0, 5" : "=r" (id));
> 
> Is the \t in here an artefact of our mail servers? I notice that in other
> places, for example arch/arm/include/asm/cp15.h, we don't have that
> formatting.

Well, if you have the inline asm statement on a single line, the 
traditional tab between the mnemonic and its argument might not fit well 
with its actual alignment on the screen.  You can find this "style" in 
arch/arm/include/barrier.h or arch/arm/include/bitops.h.

But I agree it is a little ugly.  I've replaced it with a simple space.

> > +       return id & MPIDR_HWID_BITMASK;
> > +}
> > +
> > +/*
> > + * bL switcher core code.
> > + */
> > +
> > +static void bL_do_switch(void *_unused)
> > +{
> > +       unsigned mpidr, cpuid, clusterid, ob_cluster, ib_cluster;
> > +
> > +       /*
> > +        * We now have a piece of stack borrowed from the init task's.
> > +        * Let's also switch to init_mm right away to match it.
> > +        */
> > +       cpu_switch_mm(init_mm.pgd, &init_mm);
> > +
> > +       pr_debug("%s\n", __func__);
> 
> This looks like fairly uninformative debug - is it left here intentionally? If
> so, isn't there a better message to print than just the function name?

My friend, when this function was only called for the first time, I was 
a happy camper.  So simply knowing that this is being called at all is 
already highly valuable debugging information.

> > +       mpidr = read_mpidr();
> > +       cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> > +       clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> > +       ob_cluster = clusterid;
> > +       ib_cluster = clusterid ^ 1;
> > +
> > +       /*
> > +        * Our state has been saved at this point.  Let's release our
> > +        * inbound CPU.
> > +        */
> > +       mcpm_set_entry_vector(cpuid, ib_cluster, cpu_resume);
> > +       sev();
> > +
> > +       /*
> > +        * From this point, we must assume that our counterpart CPU might
> > +        * have taken over in its parallel world already, as if execution
> > +        * just returned from cpu_suspend().  It is therefore important to
> > +        * be very careful not to make any change the other guy is not
> > +        * expecting.  This is why we need stack isolation.
> > +        *
> > +        * Fancy under cover tasks could be performed here.  For now
> > +        * we have none.
> > +        */
> > +
> > +       /* Let's put ourself down. */
> > +       mcpm_cpu_power_down();
> > +
> > +       /* should never get here */
> > +       BUG();
> > +}
> > +
> > +/*
> > + * Stack isolation.  To ensure 'current' remains valid, we just borrow
> > + * a slice of the init/idle task which should be fairly lightly used.
> > + * The borrowed area starts just above the thread_info structure located
> > + * at the very bottom of the stack, aligned to a cache line.
> > + */
> > +#define STACK_SIZE 256
> > +extern void call_with_stack(void (*fn)(void *), void *arg, void *sp);
> > +static int bL_switchpoint(unsigned long _arg)
> > +{
> > +       unsigned int mpidr = read_mpidr();
> > +       unsigned int cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> > +       unsigned int clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> > +       unsigned int cpu_index = cpuid + clusterid * MAX_CPUS_PER_CLUSTER;
> > +       void *stack = &init_thread_info + 1;
> > +       stack = PTR_ALIGN(stack, L1_CACHE_BYTES);
> 
> Are there any implications if there were big.LITTLE cores with different cache
> line sizes? The LWN article that you reference mentions different cache
> topologies...

This should always be the largest of all L1 cache line sizes in the 
system.  So that is fine here.

> > +       stack += cpu_index * STACK_SIZE + STACK_SIZE;
> > +       call_with_stack(bL_do_switch, (void *)_arg, stack);
> > +       BUG();
> > +}
> > +
> > +/*
> > + * Generic switcher interface
> > + */
> > +
> > +/*
> > + * bL_switch_to - Switch to a specific cluster for the current CPU
> > + * @new_cluster_id: the ID of the cluster to switch to.
> > + *
> > + * This function must be called on the CPU to be switched.
> > + * Returns 0 on success, else a negative status code.
> > + */
> > +static int bL_switch_to(unsigned int new_cluster_id)
> > +{
> > +       unsigned int mpidr, cpuid, clusterid, ob_cluster, ib_cluster,
> > this_cpu;
> > +       int ret;
> > +
> > +       mpidr = read_mpidr();
> > +       cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> > +       clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> > +       ob_cluster = clusterid;
> > +       ib_cluster = clusterid ^ 1;
> > +
> > +       if (new_cluster_id == clusterid)
> > +               return 0;
> > +
> > +       pr_debug("before switch: CPU %d in cluster %d\n", cpuid, clusterid);
> > +
> > +       /* Close the gate for our entry vectors */
> > +       mcpm_set_entry_vector(cpuid, ob_cluster, NULL);
> > +       mcpm_set_entry_vector(cpuid, ib_cluster, NULL);
> > +
> > +       /*
> > +        * Let's wake up the inbound CPU now in case it requires some delay
> > +        * to come online, but leave it gated in our entry vector code.
> > +        */
> > +       ret = mcpm_cpu_power_up(cpuid, ib_cluster);
> > +       if (ret) {
> > +               pr_err("%s: mcpm_cpu_power_up() returned %d\n", __func__,
> > ret);
> > +               return ret;
> > +       }
> > +
> > +       /*
> > +        * From this point we are entering the switch critical zone
> > +        * and can't sleep/schedule anymore.
> > +        */
> 
> Will this function ever be called from anywhere other than bL_switch_request?
> As far as I could see, bl_switch_request uses two different methods of
> ensuring that we will still be on the same CPU throughout this function (if
> called directly the get_cpu and put_cpu dis/enbale pre-emption and via the
> work queue we're guaranteed the same logical cpu). The different approaches
> somewhat obfuscate the need for something to have been done even before this
> point to stop us getting migrated to another CPU, I think...

True.  This comment is especially valid when moving to dedicated kernel 
threads but has no sense here..  It probably migrated to this patch by 
mistake during one of the cleanups.  Right here in this patch it should 
read "... and can't take any interrupts anymore."

> > +       local_irq_disable();
> > +       local_fiq_disable();
> > +
> > +       this_cpu = smp_processor_id();
> > +
> > +       /* redirect GIC's SGIs to our counterpart */
> > +       gic_migrate_target(cpuid + ib_cluster*4);
> > +
> > +       /*
> > +        * Raise a SGI on the inbound CPU to make sure it doesn't stall
> > +        * in a possible WFI, such as in mcpm_power_down().
> > +        */
> > +       arch_send_wakeup_ipi_mask(cpumask_of(this_cpu));
> > +
> > +       ret = cpu_pm_enter();
> > +
> > +       /* we can not tolerate errors at this point */
> > +       if (ret)
> > +               panic("%s: cpu_pm_enter() returned %d\n", __func__, ret);
> > +
> > +       /*
> > +        * Flip the cluster in the CPU logical map for this CPU.
> > +        * This must be flushed to RAM as the resume code
> > +        * needs to access it while the caches are still disabled.
> > +        */
> > +       cpu_logical_map(this_cpu) ^= (1 << 8);
> > +       sync_cache_w(&cpu_logical_map(this_cpu));
> > +
> > +       /* Let's do the actual CPU switch. */
> > +       ret = cpu_suspend(0, bL_switchpoint);
> > +       if (ret > 0)
> > +               panic("%s: cpu_suspend() returned %d\n", __func__, ret);
> > +
> > +       /* We are executing on the inbound CPU at this point */
> 
> Very cool :)
> 
> > +       mpidr = read_mpidr();
> > +       cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> > +       clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> > +       pr_debug("after switch: CPU %d in cluster %d\n", cpuid, clusterid);
> 
> Do we want a 'switcher' prefix on these? "bL_switcher: after switch..." etc?

I don't think busting the 80 column limit for this is worth it.
And when you turn on debugging you certainly know exactly what messages 
you're looking for.

> > +       BUG_ON(clusterid != ib_cluster);
> > +
> > +       mcpm_cpu_powered_up();
> > +
> > +       ret = cpu_pm_exit();
> > +
> > +       local_fiq_enable();
> > +       local_irq_enable();
> > +
> > +       if (ret)
> > +               pr_err("%s exiting with error %d\n", __func__, ret);
> > +       return ret;
> > +}
> > +
> > +struct switch_args {
> > +       unsigned int cluster;
> > +       struct work_struct work;
> > +};
> > +
> > +static void __bL_switch_to(struct work_struct *work)
> > +{
> > +       struct switch_args *args = container_of(work, struct switch_args,
> > work);
> > +       bL_switch_to(args->cluster);
> > +}
> > +
> > +/*
> > + * bL_switch_request - Switch to a specific cluster for the given CPU
> > + *
> > + * @cpu: the CPU to switch
> > + * @new_cluster_id: the ID of the cluster to switch to.
> > + *
> > + * This function causes a cluster switch on the given CPU.  If the given
> > + * CPU is the same as the calling CPU then the switch happens right away.
> > + * Otherwise the request is put on a work queue to be scheduled on the
> > + * remote CPU.
> > + */
> > +void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
> > +{
> > +       unsigned int this_cpu = get_cpu();
> > +       struct switch_args args;
> > +
> > +       if (cpu == this_cpu) {
> > +               bL_switch_to(new_cluster_id);
> > +               put_cpu();
> > +               return;
> > +       }
> > +       put_cpu();
> > +
> > +       args.cluster = new_cluster_id;
> > +       INIT_WORK_ONSTACK(&args.work, __bL_switch_to);
> > +       schedule_work_on(cpu, &args.work);
> 
> The comment at the top of schedule_work_on() says:
>  [...]
>  * We queue the work to a specific CPU, the caller must ensure it
>  * can't go away.
>  [...]
> 
> I see we don't disable cpu hotplug requests until later in the series - does
> that matter? Until that patch, it seems that we could hotplug off the core
> that we'd scheduled the work onto?

Much worse than that could happen if e.g. someone were to hotplug in a 
counterpart CPU here.  So really this is not something I'd worry about 
for this early patch in the series.

> Hope some of those questions are helpful,

Absolutely.


Nicolas


From mturquette at linaro.org  Thu Jul 25 16:23:37 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 25 Jul 2013 13:23:37 -0700
Subject: [PATCH] clk: exynos4: Add CLK_GET_RATE_NOCACHE flag for the
 Exynos4x12 ISP clocks
In-Reply-To: <51ED2230.8080100@samsung.com>
References: <1372099374-21008-1-git-send-email-s.nawrocki@samsung.com>
 <51ED2230.8080100@samsung.com>
Message-ID: <20130725202337.7598.20912@quantum>

Quoting Sylwester Nawrocki (2013-07-22 05:14:40)
> On 06/24/2013 08:42 PM, Sylwester Nawrocki wrote:
> > The ISP clock registers belong to the ISP power domain and may change
> > their values if this power domain is switched off/on. Add
> > CLK_GET_RATE_NOCACHE flags to ensure we do not rely on invalid cached
> > data when setting or getting frequency of those clocks.
> > 
> > Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> 
> Mike,
> 
> would you consider queueing that patch for current -rc cycle ?

Sylwester,

Can you rebase this onto -rc2? It does not apply cleanly onto my -fixes
branch.

Regards,
Mike

> 
> Thanks,
> Sylwester


From nicolas.pitre at linaro.org  Thu Jul 25 16:24:48 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 25 Jul 2013 16:24:48 -0400 (EDT)
Subject: [PATCH 4/6] ARM: locks: prefetch the destination word for write
 prior to strex
In-Reply-To: <20130725174555.GK12827@mudshark.cambridge.arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-5-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231609170.15022@syhkavp.arg>
 <20130724111841.GD11072@mudshark.cambridge.arm.com>
 <51F160EA.6030800@codeaurora.org> <51F1626C.3050008@codeaurora.org>
 <20130725174555.GK12827@mudshark.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1307251622320.15022@syhkavp.arg>

On Thu, 25 Jul 2013, Will Deacon wrote:

> On Thu, Jul 25, 2013 at 06:37:48PM +0100, Stephen Boyd wrote:
> > On 07/25/13 10:31, Stephen Boyd wrote:
> > > On 07/24/13 04:18, Will Deacon wrote:
> > >> On Tue, Jul 23, 2013 at 09:10:33PM +0100, Nicolas Pitre wrote:
> > >>> On Tue, 23 Jul 2013, Will Deacon wrote:
> > >>>
> > >>>> The cost of changing a cacheline from shared to exclusive state can be
> > >>>> significant, especially when this is triggered by an exclusive store,
> > >>>> since it may result in having to retry the transaction.
> > >>>>
> > >>>> This patch prefixes our {spin,read,write}_[try]lock implementations with
> > >>>> pldw instructions (on CPUs which support them) to try and grab the line
> > >>>> in exclusive state from the start.
> > >>>>
> > >>>> Signed-off-by: Will Deacon <will.deacon at arm.com>
> > >>>> ---
> > >>>>  arch/arm/include/asm/spinlock.h | 9 ++++++++-
> > >>>>  1 file changed, 8 insertions(+), 1 deletion(-)
> > >>>>
> > >>>> diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
> > >>>> index 0de7bec..3e1cc9d 100644
> > >>>> --- a/arch/arm/include/asm/spinlock.h
> > >>>> +++ b/arch/arm/include/asm/spinlock.h
> > >>>> @@ -5,7 +5,7 @@
> > >>>>  #error SMP not supported on pre-ARMv6 CPUs
> > >>>>  #endif
> > >>>>  
> > >>>> -#include <asm/processor.h>
> > >>>> +#include <linux/prefetch.h>
> > >>>>  
> > >>>>  /*
> > >>>>   * sev and wfe are ARMv6K extensions.  Uniprocessor ARMv6 may not have the K
> > >>>> @@ -70,6 +70,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
> > >>>>  	u32 newval;
> > >>>>  	arch_spinlock_t lockval;
> > >>>>  
> > >>>> +	prefetchw((const void *)&lock->slock);
> > >>> Couldn't that cast be carried in the definition of prefetchw() instead?
> > >> I think that would mean implementing prefetchw as a macro rather than an
> > >> inline function, since the core code expects to pass a const pointer and GCC
> > >> gets angry if the type signatures don't match.
> > > Maybe I'm wrong, but can't you just remove the casts and leave the
> > > function as static inline? const void * is pretty much telling the
> > > compiler to turn off type checking.
> > >
> > 
> > Oh joy. Why is rwlock's lock member marked volatile?
> 
> Yeah, that was the problematic guy. However, I had to fix that anyway in
> this patch because otherwise the definition for prefetchw when
> !ARCH_HAS_PREFETCHW (which expands to __builtin_prefetch(x,1)) will explode.

Why not always keep ARCH_HAS_PREFETCHW defined then, and have 
__builtin_prefetch([const volatile void *)x,1)) when we can't do better?

Or why not adding this cast to the generic definition?


Nicolas


From bhelgaas at google.com  Thu Jul 25 16:26:22 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Thu, 25 Jul 2013 14:26:22 -0600
Subject: [PATCHv5 04/11] PCI: Introduce new MSI chip infrastructure
In-Reply-To: <1373889167-27878-5-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-5-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAErSpo45xs-A8wCwVGtdn0NEUq1-j96=+h2jdKB8xdRoe0YAvg@mail.gmail.com>

On Mon, Jul 15, 2013 at 5:52 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> From: Thierry Reding <thierry.reding at avionic-design.de>
>
> The new struct msi_chip is used to associated an MSI controller with a
> PCI bus. It is automatically handed down from the root to its children
> during bus enumeration.
>
> This patch provides default (weak) implementations for the architecture-
> specific MSI functions (arch_setup_msi_irq(), arch_teardown_msi_irq()
> and arch_msi_check_device()) which check if a PCI device's bus has an
> attached MSI chip and forward the call appropriately.
>
> Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Acked-by: Bjorn Helgaas <bhelgaas at google.com>

> ---
>  drivers/pci/msi.c   | 27 +++++++++++++++++++++++++--
>  drivers/pci/probe.c |  1 +
>  include/linux/msi.h | 11 +++++++++++
>  include/linux/pci.h |  1 +
>  4 files changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index aa2f697..d5b6378 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -32,16 +32,39 @@ static int pci_msi_enable = 1;
>
>  int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
>  {
> -       return -EINVAL;
> +       struct msi_chip *chip = dev->bus->msi;
> +       int err;
> +
> +       if (!chip || !chip->setup_irq)
> +               return -EINVAL;
> +
> +       err = chip->setup_irq(chip, dev, desc);
> +       if (err < 0)
> +               return err;
> +
> +       irq_set_chip_data(desc->irq, chip);
> +
> +       return 0;
>  }
>
>  void __weak arch_teardown_msi_irq(unsigned int irq)
>  {
> +       struct msi_chip *chip = irq_get_chip_data(irq);
> +
> +       if (!chip || !chip->teardown_irq)
> +               return;
> +
> +       chip->teardown_irq(chip, irq);
>  }
>
>  int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
>  {
> -       return 0;
> +       struct msi_chip *chip = dev->bus->msi;
> +
> +       if (!chip || !chip->check_device)
> +               return 0;
> +
> +       return chip->check_device(chip, dev, nvec, type);
>  }
>
>  int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 46ada5c..b8eaa81 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -666,6 +666,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
>
>         child->parent = parent;
>         child->ops = parent->ops;
> +       child->msi = parent->msi;
>         child->sysdata = parent->sysdata;
>         child->bus_flags = parent->bus_flags;
>
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index 18870b0..cbf5d05 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -64,4 +64,15 @@ void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
>
>  void default_teardown_msi_irqs(struct pci_dev *dev);
>
> +struct msi_chip {
> +       struct module *owner;
> +       struct device *dev;
> +
> +       int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
> +                        struct msi_desc *desc);
> +       void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
> +       int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
> +                           int nvec, int type);
> +};
> +
>  #endif /* LINUX_MSI_H */
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 0fd1f15..4044e3c 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -433,6 +433,7 @@ struct pci_bus {
>         struct resource busn_res;       /* bus numbers routed to this bus */
>
>         struct pci_ops  *ops;           /* configuration access functions */
> +       struct msi_chip *msi;           /* MSI controller */
>         void            *sysdata;       /* hook for sys-specific extension */
>         struct proc_dir_entry *procdir; /* directory entry in /proc/bus/pci */
>
> --
> 1.8.1.2
>


From festevam at gmail.com  Thu Jul 25 16:26:48 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 25 Jul 2013 17:26:48 -0300
Subject: Enabling USBH1 on mx53qsb
In-Reply-To: <8738r2wxcx.fsf@lebrac.rtp-net.org>
References: <CAOMZO5CAdxzn-3Xc2DZDYEXwsEznRrcqPbCbTDc5ieBkQkA8=g@mail.gmail.com>
 <8738r2wxcx.fsf@lebrac.rtp-net.org>
Message-ID: <CAOMZO5CYNAKPFL1LgNGzwyZe9aCP9NHEXJFx+ymiqQf=QVx9YQ@mail.gmail.com>

Hi Arnaud,

On Thu, Jul 25, 2013 at 11:03 AM, Arnaud Patard
<arnaud.patard at rtp-net.org> wrote:

> Given that the same gpio controls vbus for both ports, my current guess
> is something on port configuration side (I guess the board would freeze
> hard if a clock is not enabled).

I agree.

Did a quick test: in U-boot I read the value of USB_UH1_PORTSC1, which
is 0xdc000000 right after reset.

If I only change the PTS field to 00 (write 1c000000), which
configures UTMI mode, then USBH1 can work in Linux.

So we have a bug in the chipidea driver not writing to USBH1 PORTSC
register even if I pass the "phy_type" via dt.


From bhelgaas at google.com  Thu Jul 25 16:27:15 2013
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Thu, 25 Jul 2013 14:27:15 -0600
Subject: [PATCHv5 02/11] PCI: use weak functions for MSI arch-specific
 functions
In-Reply-To: <1373889167-27878-3-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-3-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAErSpo48_xu+MbYefaACUNje26AWwPG5EEnNQ47-pPkqYiTN6A@mail.gmail.com>

On Mon, Jul 15, 2013 at 5:52 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Until now, the MSI architecture-specific functions could be overloaded
> using a fairly complex set of #define and compile-time
> conditionals. In order to prepare for the introduction of the msi_chip
> infrastructure, it is desirable to switch all those functions to use
> the 'weak' mechanism. This commit converts all the architectures that
> were overidding those MSI functions to use the new strategy.
>
> Note that we keep a separate, non-weak, function
> default_teardown_msi_irqs() for the default behavior of the
> arch_teardown_msi_irqs(), as the default behavior is needed by the Xen
> x86 PCI code.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> Cc: Paul Mackerras <paulus at samba.org>
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: Martin Schwidefsky <schwidefsky at de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens at de.ibm.com>
> Cc: linux390 at de.ibm.com
> Cc: linux-s390 at vger.kernel.org
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Ingo Molnar <mingo at redhat.com>
> Cc: H. Peter Anvin <hpa at zytor.com>
> Cc: x86 at kernel.org
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Tony Luck <tony.luck at intel.com>
> Cc: Fenghua Yu <fenghua.yu at intel.com>
> Cc: linux-ia64 at vger.kernel.org
> Cc: Ralf Baechle <ralf at linux-mips.org>
> Cc: linux-mips at linux-mips.org
> Cc: David S. Miller <davem at davemloft.net>
> Cc: sparclinux at vger.kernel.org
> Cc: Chris Metcalf <cmetcalf at tilera.com>

Acked-by: Bjorn Helgaas <bhelgaas at google.com>

> ---
>  arch/mips/include/asm/pci.h    |  5 -----
>  arch/powerpc/include/asm/pci.h |  5 -----
>  arch/s390/include/asm/pci.h    |  4 ----
>  arch/x86/include/asm/pci.h     | 28 --------------------------
>  arch/x86/kernel/x86_init.c     | 21 ++++++++++++++++++++
>  drivers/pci/msi.c              | 45 +++++++++++++++++++-----------------------
>  include/linux/msi.h            |  7 ++++++-
>  7 files changed, 47 insertions(+), 68 deletions(-)
>
> diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
> index fa8e0aa..f194c08 100644
> --- a/arch/mips/include/asm/pci.h
> +++ b/arch/mips/include/asm/pci.h
> @@ -136,11 +136,6 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
>         return channel ? 15 : 14;
>  }
>
> -#ifdef CONFIG_CPU_CAVIUM_OCTEON
> -/* MSI arch hook for OCTEON */
> -#define arch_setup_msi_irqs arch_setup_msi_irqs
> -#endif
> -
>  extern char * (*pcibios_plat_setup)(char *str);
>
>  #ifdef CONFIG_OF
> diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
> index 6653f27..95145a1 100644
> --- a/arch/powerpc/include/asm/pci.h
> +++ b/arch/powerpc/include/asm/pci.h
> @@ -113,11 +113,6 @@ extern int pci_domain_nr(struct pci_bus *bus);
>  /* Decide whether to display the domain number in /proc */
>  extern int pci_proc_domain(struct pci_bus *bus);
>
> -/* MSI arch hooks */
> -#define arch_setup_msi_irqs arch_setup_msi_irqs
> -#define arch_teardown_msi_irqs arch_teardown_msi_irqs
> -#define arch_msi_check_device arch_msi_check_device
> -
>  struct vm_area_struct;
>  /* Map a range of PCI memory or I/O space for a device into user space */
>  int pci_mmap_page_range(struct pci_dev *pdev, struct vm_area_struct *vma,
> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
> index 6e577ba..262b91b 100644
> --- a/arch/s390/include/asm/pci.h
> +++ b/arch/s390/include/asm/pci.h
> @@ -21,10 +21,6 @@ void pci_iounmap(struct pci_dev *, void __iomem *);
>  int pci_domain_nr(struct pci_bus *);
>  int pci_proc_domain(struct pci_bus *);
>
> -/* MSI arch hooks */
> -#define arch_setup_msi_irqs    arch_setup_msi_irqs
> -#define arch_teardown_msi_irqs arch_teardown_msi_irqs
> -
>  #define ZPCI_BUS_NR                    0       /* default bus number */
>  #define ZPCI_DEVFN                     0       /* default device number */
>
> diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
> index d9e9e6c..8c61de0 100644
> --- a/arch/x86/include/asm/pci.h
> +++ b/arch/x86/include/asm/pci.h
> @@ -100,29 +100,6 @@ static inline void early_quirks(void) { }
>  extern void pci_iommu_alloc(void);
>
>  #ifdef CONFIG_PCI_MSI
> -/* MSI arch specific hooks */
> -static inline int x86_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> -{
> -       return x86_msi.setup_msi_irqs(dev, nvec, type);
> -}
> -
> -static inline void x86_teardown_msi_irqs(struct pci_dev *dev)
> -{
> -       x86_msi.teardown_msi_irqs(dev);
> -}
> -
> -static inline void x86_teardown_msi_irq(unsigned int irq)
> -{
> -       x86_msi.teardown_msi_irq(irq);
> -}
> -static inline void x86_restore_msi_irqs(struct pci_dev *dev, int irq)
> -{
> -       x86_msi.restore_msi_irqs(dev, irq);
> -}
> -#define arch_setup_msi_irqs x86_setup_msi_irqs
> -#define arch_teardown_msi_irqs x86_teardown_msi_irqs
> -#define arch_teardown_msi_irq x86_teardown_msi_irq
> -#define arch_restore_msi_irqs x86_restore_msi_irqs
>  /* implemented in arch/x86/kernel/apic/io_apic. */
>  struct msi_desc;
>  int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
> @@ -130,11 +107,6 @@ void native_teardown_msi_irq(unsigned int irq);
>  void native_restore_msi_irqs(struct pci_dev *dev, int irq);
>  int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
>                   unsigned int irq_base, unsigned int irq_offset);
> -/* default to the implementation in drivers/lib/msi.c */
> -#define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
> -#define HAVE_DEFAULT_MSI_RESTORE_IRQS
> -void default_teardown_msi_irqs(struct pci_dev *dev);
> -void default_restore_msi_irqs(struct pci_dev *dev, int irq);
>  #else
>  #define native_setup_msi_irqs          NULL
>  #define native_teardown_msi_irq                NULL
> diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
> index 45a14db..a2b189c 100644
> --- a/arch/x86/kernel/x86_init.c
> +++ b/arch/x86/kernel/x86_init.c
> @@ -116,6 +116,27 @@ struct x86_msi_ops x86_msi = {
>         .setup_hpet_msi         = default_setup_hpet_msi,
>  };
>
> +/* MSI arch specific hooks */
> +int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +{
> +       return x86_msi.setup_msi_irqs(dev, nvec, type);
> +}
> +
> +void arch_teardown_msi_irqs(struct pci_dev *dev)
> +{
> +       x86_msi.teardown_msi_irqs(dev);
> +}
> +
> +void arch_teardown_msi_irq(unsigned int irq)
> +{
> +       x86_msi.teardown_msi_irq(irq);
> +}
> +
> +void arch_restore_msi_irqs(struct pci_dev *dev, int irq)
> +{
> +       x86_msi.restore_msi_irqs(dev, irq);
> +}
> +
>  struct x86_io_apic_ops x86_io_apic_ops = {
>         .init                   = native_io_apic_init_mappings,
>         .read                   = native_io_apic_read,
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index aca7578..aa2f697 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -30,20 +30,21 @@ static int pci_msi_enable = 1;
>
>  /* Arch hooks */
>
> -#ifndef arch_msi_check_device
> -int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> +int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
>  {
> -       return 0;
> +       return -EINVAL;
>  }
> -#endif
>
> -#ifndef arch_setup_msi_irqs
> -# define arch_setup_msi_irqs default_setup_msi_irqs
> -# define HAVE_DEFAULT_MSI_SETUP_IRQS
> -#endif
> +void __weak arch_teardown_msi_irq(unsigned int irq)
> +{
> +}
>
> -#ifdef HAVE_DEFAULT_MSI_SETUP_IRQS
> -int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> +{
> +       return 0;
> +}
> +
> +int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>  {
>         struct msi_desc *entry;
>         int ret;
> @@ -65,14 +66,11 @@ int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>
>         return 0;
>  }
> -#endif
>
> -#ifndef arch_teardown_msi_irqs
> -# define arch_teardown_msi_irqs default_teardown_msi_irqs
> -# define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
> -#endif
> -
> -#ifdef HAVE_DEFAULT_MSI_TEARDOWN_IRQS
> +/*
> + * We have a default implementation available as a separate non-weak
> + * function, as it is used by the Xen x86 PCI code
> + */
>  void default_teardown_msi_irqs(struct pci_dev *dev)
>  {
>         struct msi_desc *entry;
> @@ -89,15 +87,13 @@ void default_teardown_msi_irqs(struct pci_dev *dev)
>                         arch_teardown_msi_irq(entry->irq + i);
>         }
>  }
> -#endif
>
> -#ifndef arch_restore_msi_irqs
> -# define arch_restore_msi_irqs default_restore_msi_irqs
> -# define HAVE_DEFAULT_MSI_RESTORE_IRQS
> -#endif
> +void __weak arch_teardown_msi_irqs(struct pci_dev *dev)
> +{
> +       return default_teardown_msi_irqs(dev);
> +}
>
> -#ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS
> -void default_restore_msi_irqs(struct pci_dev *dev, int irq)
> +void __weak arch_restore_msi_irqs(struct pci_dev *dev, int irq)
>  {
>         struct msi_desc *entry;
>
> @@ -114,7 +110,6 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)
>         if (entry)
>                 write_msi_msg(irq, &entry->msg);
>  }
> -#endif
>
>  static void msi_set_enable(struct pci_dev *dev, int enable)
>  {
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index ee66f3a..18870b0 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -51,12 +51,17 @@ struct msi_desc {
>  };
>
>  /*
> - * The arch hook for setup up msi irqs
> + * The arch hooks to setup up msi irqs. Those functions are
> + * implemented as weak symbols so that they /can/ be overriden by
> + * architecture specific code if needed.
>   */
>  int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc);
>  void arch_teardown_msi_irq(unsigned int irq);
>  int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
>  void arch_teardown_msi_irqs(struct pci_dev *dev);
>  int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
> +void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
> +
> +void default_teardown_msi_irqs(struct pci_dev *dev);
>
>  #endif /* LINUX_MSI_H */
> --
> 1.8.1.2
>


From jason at lakedaemon.net  Thu Jul 25 16:32:28 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 16:32:28 -0400
Subject: DT bindings as ABI [was: Do we have people interested in
 device tree janitoring / cleanup?]
In-Reply-To: <CAL_Jsq+vWbTb8wNEDCR2c_M6sBnKW6e5HGk48QzmXSujQUdddA@mail.gmail.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
 <20130725193135.GT23879@titan.lakedaemon.net>
 <CAL_Jsq+vWbTb8wNEDCR2c_M6sBnKW6e5HGk48QzmXSujQUdddA@mail.gmail.com>
Message-ID: <20130725203228.GX23879@titan.lakedaemon.net>

On Thu, Jul 25, 2013 at 03:16:14PM -0500, Rob Herring wrote:
> On Thu, Jul 25, 2013 at 2:31 PM, Jason Cooper <jason at lakedaemon.net> wrote:
> > On Thu, Jul 25, 2013 at 02:11:31PM -0500, Rob Herring wrote:
> >> On Thu, Jul 25, 2013 at 11:09 AM, Olof Johansson <olof at lixom.net> wrote:
> >
> >> > One problem that needs to be solved is obviously how a binding
> >> > graduates from tentative to locked. This work isn't going to be very
> >> > interesting to most people, I suspect. Think standards committee type
> >> > work.
> >>
> >> I think a time based stabilization period would be better than a
> >> separate directory to apply bindings too. Or time plus periodic review
> >> perhaps.
> >
> > The only problem with a time-based versus separate directory is how do
> > users who've downloaded the tree determine which bindings are stable?
> > If they pull a tarball, or receive an SDK, there is most likely no git
> > history attached.
> 
> Well, if time based includes moving the binding out of the kernel,
> then that is what defines it as stable or not. I guess that is a form
> of a separate directory.

One of the things I've been trying to square up in my head is how to
retain the history of the binding when moving to the new tree.  My
current idea was to clone the kernel tree, add one patch deleting
everything but the bindings and dts files, and one more patch moving
things where we want them (arch/{powerpc,arm}/boot/dts -> dts).

Then, as needed, we could merge a kernel version tag and delete
everything we don't need (code) in the merge commit.

The downside of this is it would be messy, the upside is that we could
closely track the kernel tree (until the bindings and dts are moved
out), and retain the history of the bindings and dts files.

> I don't think we want to be moving bindings twice: tentative -> stable
> and kernel -> DT repo.

agreed.

> The policy could be as simple as an binding without change in at least
> N kernel releases is moved out and stable.

If the cloned tree idea works, we could just merge version tags that are
two or three behind the most recent version.

thx,

Jason.


From olof at lixom.net  Thu Jul 25 16:33:08 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 25 Jul 2013 13:33:08 -0700
Subject: [GIT PULL] ARM: mvebu: stable fix for v3.10
In-Reply-To: <20130725173357.GN23879@titan.lakedaemon.net>
References: <20130725173357.GN23879@titan.lakedaemon.net>
Message-ID: <CAOesGMjNh3u=GmckBHfTZtJSEzbwPHtkJkhC7kCwFQ+TeKtHAA@mail.gmail.com>

Hi,

On Thu, Jul 25, 2013 at 10:33 AM, Jason Cooper <jason at lakedaemon.net> wrote:
> Arnd, Olof,
>
> I'm trying something new.  I've based this branch off of the common
> ancestor to the v3.10.x tree (v3.10).  If you could handle it just like
> a normal mvebu/fixes branch (ie merge it in for v3.11-rcX), once it hits
> mainline, I'll send a PR to the stable folks for the branch.
>
> The advantage of this is that you get the same commit id in both trees
> and it's less work for the stable maintainers.
>
> Also, please note the URL change.  I'll post an announcement about that
> shortly.
>
> As usual, please tell me if I'm all fouled up. :)

I'm confused. Just to double-check, I just checked out v3.10 and built
orion5x_defconfig, without any kind of problem.


-Olof


From hauke at hauke-m.de  Thu Jul 25 16:33:46 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Thu, 25 Jul 2013 22:33:46 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <20130724225443.GA29801@glitch>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130723184907.GA6811@ohporter.com>
 <CAGVrzcbA72AYu6J3JXBirQQeTiDH9cJThdBdH=Q=gJtOnqz-AA@mail.gmail.com>
 <20130723192203.GC6811@ohporter.com> <51EF1B8C.9020304@broadcom.com>
 <CADjby3WGW6f=1Vdm2kx+Re0KrjFRaC3dQOumpnS6_sp2yb5NfQ@mail.gmail.com>
 <51F02947.7020301@hauke-m.de> <20130724225443.GA29801@glitch>
Message-ID: <51F18BAA.1050806@hauke-m.de>

On 07/25/2013 12:54 AM, Domenico Andreoli wrote:
> On Wed, Jul 24, 2013 at 09:21:43PM +0200, Hauke Mehrtens wrote:
>> On 07/24/2013 02:44 AM, Domenico Andreoli wrote:
>>> On Wednesday, July 24, 2013, Hauke Mehrtens <hauke at hauke-m.de
>>> <mailto:hauke at hauke-m.de>> wrote:
>>>> On 07/19/2013 03:36 AM, Domenico Andreoli wrote:
>>>>> On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote:
>>>>>> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote:
>>>>>>>
>>>>>>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig
>>> b/arch/arm/mach-bcm53xx/Kconfig
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..1e16e87
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/mach-bcm53xx/Kconfig
>>>>>>>> @@ -0,0 +1,10 @@
>>>>>>>> +config ARCH_BCM53XX
>>>>>>>> +  bool "Broadcom BCM47XX / BCM53XX ARM SoC"
>>>>>>>
>>>>>>> So the directory is named mach-bcm53xx, but you also handle BCM47xx
>>>>>>> SoCs. This doesn't sound really easy to follow.
>>>>>
>>>>> At the time of the BCM281XX merge we considered that such directories
>>> would
>>>>> mostly contain board files only, being these new entries DT based. Hence
>>>>> the choice of mach-bcm to collect all of them.
>>>>>
>>>>> I think you should then put this stuff there.
>>>>
>>>> So you think I should move the file from
>>>> arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?
>>>
>>> yes
>>>
>>> this looks more comsistent with the actual soc name:
>>> arch/arm/mach-bcm/bcm530xx.c
>>>
>>> but I find also acceptable the complete name of the "parent" soc (as I'm
>>> doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c
>>
>> I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351)
>> have more in common than the vendor name, so I do not think it is a good
>> idea to place them all at mach-bcm.
> 
> In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever
> two or more SoCs share can hopefully modelled in a driver and as such
> would go in the drivers/ subtree. What's left is really SoC specific and,
> again hopefully, very minimal.
> 
> There should not be any SoC so weird to require a whole subdirectory full
> of that SoC specific stuff. So grouping everything by vendor name looks
> quite appealing to me.
> 
> Sharing the same subdir requires people working in it to talk and find
> agreements some more than the sparsely populated subdir did (because there
> is not a single maintainer who owns it). I think this is a big advantage
> Broadcomers can start with right now.

I want to be able to build the BCM5301X SoC without building the current
CONFIG_ARCH_BCM, so what name do you suggest for board_bcm.o ?

My plan would be to make CONFIG_ARCH_BCM just activate the Broadcom
submenu, but not build any code. Then the list of Broadcom SoCs is
opened like CONFIG_ARCH_BCM5301X and the "old" CONFIG_ARCH_BCM.

Hauke


From jason at lakedaemon.net  Thu Jul 25 16:51:33 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 16:51:33 -0400
Subject: [GIT PULL] ARM: mvebu: stable fix for v3.10
In-Reply-To: <CAOesGMjNh3u=GmckBHfTZtJSEzbwPHtkJkhC7kCwFQ+TeKtHAA@mail.gmail.com>
References: <20130725173357.GN23879@titan.lakedaemon.net>
 <CAOesGMjNh3u=GmckBHfTZtJSEzbwPHtkJkhC7kCwFQ+TeKtHAA@mail.gmail.com>
Message-ID: <20130725205133.GY23879@titan.lakedaemon.net>

On Thu, Jul 25, 2013 at 01:33:08PM -0700, Olof Johansson wrote:
> Hi,
> 
> On Thu, Jul 25, 2013 at 10:33 AM, Jason Cooper <jason at lakedaemon.net> wrote:
> > Arnd, Olof,
> >
> > I'm trying something new.  I've based this branch off of the common
> > ancestor to the v3.10.x tree (v3.10).  If you could handle it just like
> > a normal mvebu/fixes branch (ie merge it in for v3.11-rcX), once it hits
> > mainline, I'll send a PR to the stable folks for the branch.
> >
> > The advantage of this is that you get the same commit id in both trees
> > and it's less work for the stable maintainers.
> >
> > Also, please note the URL change.  I'll post an announcement about that
> > shortly.
> >
> > As usual, please tell me if I'm all fouled up. :)
> 
> I'm confused. Just to double-check, I just checked out v3.10 and built
> orion5x_defconfig, without any kind of problem.

gah! you're right.  I did a git blame on the mbus call to see how far
back to go, but didn't look deep enough.  mv643xx_eth.h includes mbus.h.

The error occurs once mv643xx_eth.h is removed (in Sebastian's patch
series to convert mv643xx_eth init to DT).  I'll append this patch to
the series causing the build failure.  Please ignore this PR.

Sorry for the noise.

thx,

Jason.


From santosh.shilimkar at ti.com  Thu Jul 25 16:52:48 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 25 Jul 2013 16:52:48 -0400
Subject: [PATCH] spi: davinci: Update configs to make it selectable on
 Keystone
In-Reply-To: <20130725092017.GU9858@sirena.org.uk>
References: <1374712297-32187-1-git-send-email-santosh.shilimkar@ti.com>
 <20130725092017.GU9858@sirena.org.uk>
Message-ID: <51F19020.3010103@ti.com>

On Thursday 25 July 2013 05:20 AM, Mark Brown wrote:
> On Wed, Jul 24, 2013 at 08:31:37PM -0400, Santosh Shilimkar wrote:
>> Keystone2 SOCs share the SPI IP block with DaVinci based SOCs. Update
>> the config bits so that its usable on Keystone2 based SOCs.
> 
> Applied, thanks.
> 
thanks Mark


From santosh.shilimkar at ti.com  Thu Jul 25 16:59:25 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 25 Jul 2013 16:59:25 -0400
Subject: [PATCH 1/2] i2c: davinci: remove useless mach/hardware include
In-Reply-To: <51F0F283.5080900@ti.com>
References: <1374712099-32095-1-git-send-email-santosh.shilimkar@ti.com>
 <1374712099-32095-2-git-send-email-santosh.shilimkar@ti.com>
 <51F0F283.5080900@ti.com>
Message-ID: <51F191AD.9020108@ti.com>

On Thursday 25 July 2013 05:40 AM, Sekhar Nori wrote:
> On Thursday 25 July 2013 05:58 AM, Santosh Shilimkar wrote:
>> This driver no longer uses definitions from mach/hardware.h.
>> On the other hand, including this header breaks this driver
>> on non-davinci platforms which don't have such a header.
>>
>> Fix it.
>>
>> Cc: Sekhar Nori <nsekhar at ti.com>
>> Cc: Wolfram Sang <wsa at the-dreams.de>
>>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> 
> Acked-by: Sekhar Nori <nsekhar at ti.com>
> 
> One minor nit:
> 
>> ---
>>  drivers/i2c/busses/i2c-davinci.c |    1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
>> index fa55605..ddaa2a3 100644
>> --- a/drivers/i2c/busses/i2c-davinci.c
>> +++ b/drivers/i2c/busses/i2c-davinci.c
>> @@ -41,7 +41,6 @@
>>  #include <linux/of_i2c.h>
>>  #include <linux/of_device.h>
>>  
> 
> You can now remove this empty line too.
> 
Yes. Updated patch below with your ack added.

Regards,
Santosh

>From d7ae1c488ebae19028f33abff76c4d684271a7fb Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar at ti.com>
Date: Tue, 23 Jul 2013 15:40:46 -0400
Subject: [PATCH 1/2] i2c: davinci: remove useless mach/hardware include

This driver no longer uses definitions from mach/hardware.h.
On the other hand, including this header breaks this driver
on non-davinci platforms which don't have such a header.

Fix it.


Cc: Wolfram Sang <wsa at the-dreams.de>

Acked-by: Sekhar Nori <nsekhar at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 drivers/i2c/busses/i2c-davinci.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index fa55605..5898df3 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -40,8 +40,6 @@
 #include <linux/gpio.h>
 #include <linux/of_i2c.h>
 #include <linux/of_device.h>
-
-#include <mach/hardware.h>
 #include <linux/platform_data/i2c-davinci.h>
 
 /* ----- global defines ----------------------------------------------- */
-- 
1.7.9.5




From mturquette at linaro.org  Thu Jul 25 16:59:53 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 25 Jul 2013 13:59:53 -0700
Subject: [PATCH v5 3/3] Documentation: Add documentation for APM X-Gene
 clock binding
In-Reply-To: <1372269371-22992-4-git-send-email-lho@apm.com>
References: <1372269371-22992-1-git-send-email-lho@apm.com>
 <1372269371-22992-2-git-send-email-lho@apm.com>
 <1372269371-22992-3-git-send-email-lho@apm.com>
 <1372269371-22992-4-git-send-email-lho@apm.com>
Message-ID: <20130725205953.7598.15913@quantum>

Quoting Loc Ho (2013-06-26 10:56:11)
> Documentation: Add documentation for APM X-Gene clock binding with PLL and
> device clocks.
> 
> Signed-off-by: Loc Ho <lho at apm.com>
> Signed-off-by: Kumar Sankaran <ksankaran at apm.com>
> Signed-off-by: Vinayak Kale <vkale at apm.com>
> Signed-off-by: Feng Kan <fkan at apm.com>
> ---
>  Documentation/devicetree/bindings/clock/xgene.txt |  111 +++++++++++++++++++++
>  1 files changed, 111 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/xgene.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/xgene.txt b/Documentation/devicetree/bindings/clock/xgene.txt
> new file mode 100644
> index 0000000..1c4ef77
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/xgene.txt
> @@ -0,0 +1,111 @@
> +Device Tree Clock bindings for APM X-Gene
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible : shall be one of the following:
> +       "apm,xgene-socpll-clock" - for a X-Gene SoC PLL clock
> +       "apm,xgene-pcppll-clock" - for a X-Gene PCP PLL clock
> +       "apm,xgene-device-clock" - for a X-Gene device clock
> +
> +Required properties for SoC or PCP PLL clocks:
> +- reg : shall be the physical PLL register address for the pll clock.
> +- clocks : shall be the input parent clock phandle for the clock. This should
> +       be the reference clock.
> +- #clock-cells : shall be set to 1.
> +- clock-output-names : shall be the name of the PLL referenced by derive
> +  clock.
> +Optional properties for PLL clocks:
> +- clock-names : shall be the name of the PLL. If missing, use the device name.
> +
> +Required properties for device clocks:
> +- reg : shall be a list of address and length pairs describing the CSR
> +         reset and/or the divider. Either may be omitted, but at least
> +         one must be present.
> + - reg-names : shall be a string list describing the reg resource. This
> +               may include "csr-reg" and/or "div-reg". If this property
> +               is not present, the reg property is assumed to describe
> +               only "csr-reg".

Where is reg-names used? I see it used in your DTS but I don't see
clk-xgene.c doing anything with it.

> +- clocks : shall be the input parent clock phandle for the clock.
> +- #clock-cells : shall be set to 1.
> +- clock-output-names : shall be the name of the device referenced.
> +Optional properties for device clocks:
> +- clock-names : shall be the name of the device clock. If missing, use the
> +                device name.
> +- csr-offset : Offset to the CSR reset register from the reset address base.
> +               Default is 0.
> +- csr-mask : CSR reset mask bit. Default is 0xF.
> +- enable-offset : Offset to the enable register from the reset address base.
> +                  Default is 0x8.
> +- enable-mask : CSR enable mask bit. Default is 0xF.
> +- divider-offset : Offset to the divider CSR register from the divider base.
> +                   Default is 0x0.
> +- divider-width : Width of the divider register. Default is 0.
> +- divider-shift : Bit shift of the divider register. Default is 0.

There is a general push to not have register-level details in DT. How
many clocks do you think you'll end up defining in the future? If you
have a lot then this binding could grow fairly large.

Regards,
Mike

> +
> +For example:
> +
> +       pcppll: pcppll at 17000100 {
> +               compatible = "apm,xgene-pcppll-clock";
> +               #clock-cells = <1>;
> +               clocks = <&refclk 0>;
> +               clock-names = "pcppll";
> +               reg = <0x0 0x17000100 0x0 0x1000>;
> +               clock-output-names = "pcppll";
> +               type = <0>;
> +       };
> +
> +       socpll: socpll at 17000120 {
> +               compatible = "apm,xgene-socpll-clock";
> +               #clock-cells = <1>;
> +               clocks = <&refclk 0>;
> +               clock-names = "socpll";
> +               reg = <0x0 0x17000120 0x0 0x1000>;
> +               clock-output-names = "socpll";
> +               type = <1>;
> +       };
> +
> +       qmlclk: qmlclk {
> +               compatible = "apm,xgene-device-clock";
> +               #clock-cells = <1>;
> +               clocks = <&socplldiv2 0>;
> +               clock-names = "qmlclk";
> +               reg = <0x0 0x1703C000 0x0 0x1000>;
> +               reg-name = "csr-reg";
> +               clock-output-names = "qmlclk";
> +       };
> +
> +       ethclk: ethclk {
> +               compatible = "apm,xgene-device-clock";
> +               #clock-cells = <1>;
> +               clocks = <&socplldiv2 0>;
> +               clock-names = "ethclk";
> +               reg = <0x0 0x17000000 0x0 0x1000>;
> +               reg-names = "div-reg";
> +               divider-offset = <0x238>;
> +               divider-width = <0x9>;
> +               divider-shift = <0x0>;
> +               clock-output-names = "ethclk";
> +       };
> +
> +       apbclk: apbclk {
> +               compatible = "apm,xgene-device-clock";
> +               #clock-cells = <1>;
> +               clocks = <&ahbclk 0>;
> +               clock-names = "apbclk";
> +               reg = <0x0 0x1F2AC000 0x0 0x1000
> +                       0x0 0x1F2AC000 0x0 0x1000>;
> +               reg-names = "csr-reg", "div-reg";
> +               csr-offset = <0x0>;
> +               csr-mask = <0x200>;
> +               enable-offset = <0x8>;
> +               enable-mask = <0x200>;
> +               divider-offset = <0x10>;
> +               divider-width = <0x2>;
> +               divider-shift = <0x0>;
> +               flags = <0x8>;
> +               clock-output-names = "apbclk";
> +       };
> +
> -- 
> 1.5.5


From mturquette at linaro.org  Thu Jul 25 17:06:34 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Thu, 25 Jul 2013 14:06:34 -0700
Subject: [PATCH] clk: fix typos
In-Reply-To: <1372511659-26936-1-git-send-email-pmeerw@pmeerw.net>
References: <1372511659-26936-1-git-send-email-pmeerw@pmeerw.net>
Message-ID: <20130725210634.7598.2785@quantum>

Quoting Peter Meerwald (2013-06-29 06:14:19)
> Signed-off-by: Peter Meerwald <pmeerw at pmeerw.net>

Thanks for the corrections Peter. Taken into clk-next.

Regards,
Mike

> ---
>  drivers/clk/Kconfig |  2 +-
>  drivers/clk/clk.c   | 15 ++++++++-------
>  2 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 0357ac4..1ba18f9 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -27,7 +27,7 @@ config COMMON_CLK_DEBUG
>         bool "DebugFS representation of clock tree"
>         select DEBUG_FS
>         ---help---
> -         Creates a directory hierchy in debugfs for visualizing the clk
> +         Creates a directory hierarchy in debugfs for visualizing the clk
>           tree structure.  Each directory contains read-only members
>           that export information specific to that clk node: clk_rate,
>           clk_flags, clk_prepare_count, clk_enable_count &
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 1144e8c..d6b45b6 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -702,7 +702,7 @@ void __clk_unprepare(struct clk *clk)
>  
>  /**
>   * clk_unprepare - undo preparation of a clock source
> - * @clk: the clk being unprepare
> + * @clk: the clk being unprepared
>   *
>   * clk_unprepare may sleep, which differentiates it from clk_disable.  In a
>   * simple case, clk_unprepare can be used instead of clk_disable to gate a clk
> @@ -869,6 +869,7 @@ EXPORT_SYMBOL_GPL(clk_enable);
>  /**
>   * __clk_round_rate - round the given rate for a clk
>   * @clk: round the rate of this clock
> + * @rate: the rate which is to be rounded
>   *
>   * Caller must hold prepare_lock.  Useful for clk_ops such as .set_rate
>   */
> @@ -956,7 +957,7 @@ static int __clk_notify(struct clk *clk, unsigned long msg,
>   *
>   * Walks the subtree of clks starting with clk and recalculates rates as it
>   * goes.  Note that if a clk does not implement the .recalc_rate callback then
> - * it is assumed that the clock will take on the rate of it's parent.
> + * it is assumed that the clock will take on the rate of its parent.
>   *
>   * clk_recalc_rates also propagates the POST_RATE_CHANGE notification,
>   * if necessary.
> @@ -1026,7 +1027,7 @@ EXPORT_SYMBOL_GPL(clk_get_rate);
>   * pre-rate change notifications and returns early if no clks in the
>   * subtree have subscribed to the notifications.  Note that if a clk does not
>   * implement the .recalc_rate callback then it is assumed that the clock will
> - * take on the rate of it's parent.
> + * take on the rate of its parent.
>   *
>   * Caller must hold prepare_lock.
>   */
> @@ -1198,7 +1199,7 @@ static void clk_change_rate(struct clk *clk)
>   * outcome of clk's .round_rate implementation.  If *parent_rate is unchanged
>   * after calling .round_rate then upstream parent propagation is ignored.  If
>   * *parent_rate comes back with a new rate for clk's parent then we propagate
> - * up to clk's parent and set it's rate.  Upward propagation will continue
> + * up to clk's parent and set its rate.  Upward propagation will continue
>   * until either a clk does not support the CLK_SET_RATE_PARENT flag or
>   * .round_rate stops requesting changes to clk's parent_rate.
>   *
> @@ -1449,7 +1450,7 @@ static int __clk_set_parent(struct clk *clk, struct clk *parent, u8 p_index)
>   * @clk: the mux clk whose input we are switching
>   * @parent: the new input to clk
>   *
> - * Re-parent clk to use parent as it's new input source.  If clk has the
> + * Re-parent clk to use parent as its new input source.  If clk has the
>   * CLK_SET_PARENT_GATE flag set then clk must be gated for this
>   * operation to succeed.  After successfully changing clk's parent
>   * clk_set_parent will update the clk topology, sysfs topology and
> @@ -1650,7 +1651,7 @@ int __clk_init(struct device *dev, struct clk *clk)
>          * The .init callback is not used by any of the basic clock types, but
>          * exists for weird hardware that must perform initialization magic.
>          * Please consider other ways of solving initialization problems before
> -        * using this callback, as it's use is discouraged.
> +        * using this callback, as its use is discouraged.
>          */
>         if (clk->ops->init)
>                 clk->ops->init(clk->hw);
> @@ -1677,7 +1678,7 @@ out:
>   * very large numbers of clocks that need to be statically initialized.  It is
>   * a layering violation to include clk-private.h from any code which implements
>   * a clock's .ops; as such any statically initialized clock data MUST be in a
> - * separate C file from the logic that implements it's operations.  Returns 0
> + * separate C file from the logic that implements its operations.  Returns 0
>   * on success, otherwise an error code.
>   */
>  struct clk *__clk_register(struct device *dev, struct clk_hw *hw)
> -- 
> 1.8.3.1


From olof at lixom.net  Thu Jul 25 17:00:47 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 25 Jul 2013 14:00:47 -0700
Subject: [PATCH] mfd: max8925: fix dt code for backlight
In-Reply-To: <000401ce88d4$33773de0$9a65b9a0$@samsung.com>
References: <1374680547-5336-1-git-send-email-olof@lixom.net>
 <000401ce88d4$33773de0$9a65b9a0$@samsung.com>
Message-ID: <CAOesGMh5-aRR+eZVimNnZJ++f74tbURWOeri-46GNQfK_r3JuA@mail.gmail.com>

On Wed, Jul 24, 2013 at 6:13 PM, Jingoo Han <jg1.han at samsung.com> wrote:
> On Thursday, July 25, 2013 12:42 AM, Olof Johansson wrote:
>>
>> The device-tree enablement for max8925 has several problems, but besides
>> the bindings being wrong (and not having seen review) there's also some
>> bad coding practices on how to fill in the platform_data from device tree.
>>
>> I came across this since it causes a warning when compiling
>> mmp2_defconfig, and instead of doing the minimal fix to silence the
>> warning, I restructured the code a bit.
>>
>> This silences the warning:
>> drivers/video/backlight/max8925_bl.c: In function 'max8925_backlight_probe':
>> drivers/video/backlight/max8925_bl.c:177:3: warning: statement with no effect [-Wunused-value]
>>
>> Note that the bindings themselves need to be revisited too, but that will
>> affect more than just the backlight driver and is best done separately;
>> this just fixes the bad code for the backlight driver.
>>
>> Signed-off-by: Olof Johansson <olof at lixom.net>
>> ---
>>
>> Richard, Jingoo, this would be good to see go into 3.11 if you're
>> comfortable with it.
>
> CC'ed Andrew Morton
>
>
> Hi Olof Johansson,
>
> Currently, there is not git tree for Backlight subsystem.
> I hope that this would go into 3.11 through one of other trees
> with my Ack.
>
> If not, it will go into 3.12-rc1 through mm-tree.
>
> Acked-by: Jingoo Han <jg1.han at samsung.com>

Ok, if you don't mind I can take it through arm-soc for 3.11 with your ack then.

Thanks!

-Olof


From festevam at gmail.com  Thu Jul 25 17:06:51 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 25 Jul 2013 18:06:51 -0300
Subject: Enabling USBH1 on mx53qsb
In-Reply-To: <CAOMZO5CYNAKPFL1LgNGzwyZe9aCP9NHEXJFx+ymiqQf=QVx9YQ@mail.gmail.com>
References: <CAOMZO5CAdxzn-3Xc2DZDYEXwsEznRrcqPbCbTDc5ieBkQkA8=g@mail.gmail.com>
 <8738r2wxcx.fsf@lebrac.rtp-net.org>
 <CAOMZO5CYNAKPFL1LgNGzwyZe9aCP9NHEXJFx+ymiqQf=QVx9YQ@mail.gmail.com>
Message-ID: <CAOMZO5CYnj1nNYMe4aONFCQ+a3pgtiAxSWWP+h5XvOjLO308Bg@mail.gmail.com>

On Thu, Jul 25, 2013 at 5:26 PM, Fabio Estevam <festevam at gmail.com> wrote:

> So we have a bug in the chipidea driver not writing to USBH1 PORTSC
> register even if I pass the "phy_type" via dt.

I fixed the issue and will submit the patches shortly.


From sylvester.nawrocki at gmail.com  Thu Jul 25 17:07:05 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Thu, 25 Jul 2013 23:07:05 +0200
Subject: [PATCH v2] clk: exynos4: Add CLK_GET_RATE_NOCACHE flag for the
 Exynos4x12 ISP clocks
Message-ID: <1374786425-6697-1-git-send-email-sylvester.nawrocki@gmail.com>

From: Sylwester Nawrocki <s.nawrocki at samsung.com>

The ISP clock registers belong to the ISP power domain and may change
their values if this power domain is switched off/on. Add
CLK_GET_RATE_NOCACHE flags to ensure we do not rely on invalid cached
data when setting or getting frequency of those clocks.

Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
---

Rebased onto v3.11-rc2.

 drivers/clk/samsung/clk-exynos4.c |   64 +++++++++++++++++++-----------------
 1 files changed, 34 insertions(+), 30 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index 1bdb882..4e57397 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -581,11 +581,15 @@ struct samsung_div_clock exynos4x12_div_clks[] __initdata = {
 	DIV(none, "div_spi1_isp", "mout_spi1_isp", E4X12_DIV_ISP, 16, 4),
 	DIV(none, "div_spi1_isp_pre", "div_spi1_isp", E4X12_DIV_ISP, 20, 8),
 	DIV(none, "div_uart_isp", "mout_uart_isp", E4X12_DIV_ISP, 28, 4),
-	DIV(div_isp0, "div_isp0", "aclk200", E4X12_DIV_ISP0, 0, 3),
-	DIV(div_isp1, "div_isp1", "aclk200", E4X12_DIV_ISP0, 4, 3),
+	DIV_F(div_isp0, "div_isp0", "aclk200", E4X12_DIV_ISP0, 0, 3,
+						CLK_GET_RATE_NOCACHE, 0),
+	DIV_F(div_isp1, "div_isp1", "aclk200", E4X12_DIV_ISP0, 4, 3,
+						CLK_GET_RATE_NOCACHE, 0),
 	DIV(none, "div_mpwm", "div_isp1", E4X12_DIV_ISP1, 0, 3),
-	DIV(div_mcuisp0, "div_mcuisp0", "aclk400_mcuisp", E4X12_DIV_ISP1, 4, 3),
-	DIV(div_mcuisp1, "div_mcuisp1", "div_mcuisp0", E4X12_DIV_ISP1, 8, 3),
+	DIV_F(div_mcuisp0, "div_mcuisp0", "aclk400_mcuisp", E4X12_DIV_ISP1,
+						4, 3, CLK_GET_RATE_NOCACHE, 0),
+	DIV_F(div_mcuisp1, "div_mcuisp1", "div_mcuisp0", E4X12_DIV_ISP1,
+						8, 3, CLK_GET_RATE_NOCACHE, 0),
 	DIV(sclk_fimg2d, "sclk_fimg2d", "mout_g2d", DIV_DMC1, 0, 4),
 };

@@ -863,57 +867,57 @@ struct samsung_gate_clock exynos4x12_gate_clks[] __initdata = {
 	GATE_DA(i2s0, "samsung-i2s.0", "i2s0", "aclk100",
 			E4X12_GATE_IP_MAUDIO, 3, 0, 0, "iis"),
 	GATE(fimc_isp, "isp", "aclk200", E4X12_GATE_ISP0, 0,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(fimc_drc, "drc", "aclk200", E4X12_GATE_ISP0, 1,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(fimc_fd, "fd", "aclk200", E4X12_GATE_ISP0, 2,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(fimc_lite0, "lite0", "aclk200", E4X12_GATE_ISP0, 3,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(fimc_lite1, "lite1", "aclk200", E4X12_GATE_ISP0, 4,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(mcuisp, "mcuisp", "aclk200", E4X12_GATE_ISP0, 5,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(gicisp, "gicisp", "aclk200", E4X12_GATE_ISP0, 7,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(smmu_isp, "smmu_isp", "aclk200", E4X12_GATE_ISP0, 8,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(smmu_drc, "smmu_drc", "aclk200", E4X12_GATE_ISP0, 9,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(smmu_fd, "smmu_fd", "aclk200", E4X12_GATE_ISP0, 10,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(smmu_lite0, "smmu_lite0", "aclk200", E4X12_GATE_ISP0, 11,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(smmu_lite1, "smmu_lite1", "aclk200", E4X12_GATE_ISP0, 12,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(ppmuispmx, "ppmuispmx", "aclk200", E4X12_GATE_ISP0, 20,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(ppmuispx, "ppmuispx", "aclk200", E4X12_GATE_ISP0, 21,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(mcuctl_isp, "mcuctl_isp", "aclk200", E4X12_GATE_ISP0, 23,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(mpwm_isp, "mpwm_isp", "aclk200", E4X12_GATE_ISP0, 24,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(i2c0_isp, "i2c0_isp", "aclk200", E4X12_GATE_ISP0, 25,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(i2c1_isp, "i2c1_isp", "aclk200", E4X12_GATE_ISP0, 26,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(mtcadc_isp, "mtcadc_isp", "aclk200", E4X12_GATE_ISP0, 27,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(pwm_isp, "pwm_isp", "aclk200", E4X12_GATE_ISP0, 28,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(wdt_isp, "wdt_isp", "aclk200", E4X12_GATE_ISP0, 30,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(uart_isp, "uart_isp", "aclk200", E4X12_GATE_ISP0, 31,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(asyncaxim, "asyncaxim", "aclk200", E4X12_GATE_ISP1, 0,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(smmu_ispcx, "smmu_ispcx", "aclk200", E4X12_GATE_ISP1, 4,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(spi0_isp, "spi0_isp", "aclk200", E4X12_GATE_ISP1, 12,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(spi1_isp, "spi1_isp", "aclk200", E4X12_GATE_ISP1, 13,
-			CLK_IGNORE_UNUSED, 0),
+			CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
 	GATE(g2d, "g2d", "aclk200", GATE_IP_DMC, 23, 0, 0),
 };

--
1.7.4.1



From jason at lakedaemon.net  Thu Jul 25 17:07:55 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Jul 2013 17:07:55 -0400
Subject: [PATCH 2/2] ARM: orion5x: add missing mbus include
In-Reply-To: <20130725153856.GI23879@titan.lakedaemon.net>
References: <1372762453-12018-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1372762453-12018-3-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130725153856.GI23879@titan.lakedaemon.net>
Message-ID: <20130725210755.GZ23879@titan.lakedaemon.net>

On Thu, Jul 25, 2013 at 11:38:56AM -0400, Jason Cooper wrote:
> On Tue, Jul 02, 2013 at 12:54:13PM +0200, Sebastian Hesselbarth wrote:
> > edmini_v2-setup is missing an include of linux/mbus.h which causes
> > compiler error because of missing reference to mvebu_mbus_add_window.
> > 
> > Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> > ---
> > Cc: Russell King <linux at arm.linux.org.uk> 
> > Cc: Jason Cooper <jason at lakedaemon.net>
> > Cc: Andrew Lunn <andrew at lunn.ch>
> > Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > Cc: Gregory CLEMENT <gregory.clement at free-electrons.com> 
> > Cc: devicetree-discuss at lists.ozlabs.org 
> > Cc: linux-kernel at vger.kernel.org 
> > Cc: linux-arm-kernel at lists.infradead.org 
> > ---
> >  arch/arm/mach-orion5x/edmini_v2-setup.c |    1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> Applied to mvebu/stable-3.10

nevermind, Olof caught that v3.10 builds fine without this patch (I
should've checked).  The build error was introduced by

  ARM: orion5x: remove legacy mv643xx_eth board setup

which removed mv643xx_eth.h include, which had included the needed
mbus.h.  This patch is queued for v3.12.

I'll squash this patch into the above mentioned patch and call it a day.

thx,

Jason.


From ben.dooks at codethink.co.uk  Thu Jul 25 17:08:56 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 22:08:56 +0100
Subject: [PATCH 3/4] ARM: kprobes-test: use <asm/opcodes.h>
In-Reply-To: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374786537-10726-4-git-send-email-ben.dooks@codethink.co.uk>

Ensure we read instructions in the correct endian-ness by using
the <asm/opcodes.h> helper to transform them as necessary.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/kernel/kprobes-test.c |    9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/arm/kernel/kprobes-test.c b/arch/arm/kernel/kprobes-test.c
index 0cd63d0..6cfa04d 100644
--- a/arch/arm/kernel/kprobes-test.c
+++ b/arch/arm/kernel/kprobes-test.c
@@ -1374,13 +1374,13 @@ static uintptr_t __used kprobes_test_case_start(const char *title, void *stack)
 
 	if (test_case_is_thumb) {
 		u16 *p = (u16 *)(test_code & ~1);
-		current_instruction = p[0];
+		current_instruction = __mem_to_opcode_thumb16(p[0]);
 		if (is_wide_instruction(current_instruction)) {
-			current_instruction <<= 16;
-			current_instruction |= p[1];
+			u16 instr2 = __mem_to_opcode_thumb16(p[1]);
+			current_instruction = ___asm_opcode_thumb32_compose(current_instruction, instr2);
 		}
 	} else {
-		current_instruction = *(u32 *)test_code;
+		current_instruction = __mem_to_opcode_arm(*(u32 *)test_code);
 	}
 
 	if (current_title[0] == '.')
@@ -1593,7 +1593,6 @@ static int run_test_cases(void (*tests)(void), const union decode_item *table)
 	return 0;
 }
 
-
 static int __init run_all_tests(void)
 {
 	int ret = 0;
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Thu Jul 25 17:08:54 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 22:08:54 +0100
Subject: [PATCH 1/4] ARM: kprobes: fix instruction fetch order with
 <asm/opcodes.h>
In-Reply-To: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374786537-10726-2-git-send-email-ben.dooks@codethink.co.uk>

If we are running BE8, the data and instruction endian-ness do not
match, so use <asm/opcodes.h> to correctly translate memory accesses
into ARM instructions.

Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>y
---
 arch/arm/kernel/kprobes-common.c |   14 ++++++++------
 arch/arm/kernel/kprobes.c        |    9 +++++----
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/arch/arm/kernel/kprobes-common.c b/arch/arm/kernel/kprobes-common.c
index 18a7628..c0b202e 100644
--- a/arch/arm/kernel/kprobes-common.c
+++ b/arch/arm/kernel/kprobes-common.c
@@ -14,6 +14,7 @@
 #include <linux/kernel.h>
 #include <linux/kprobes.h>
 #include <asm/system_info.h>
+#include <asm/opcodes.h>
 
 #include "kprobes.h"
 
@@ -305,7 +306,8 @@ kprobe_decode_ldmstm(kprobe_opcode_t insn, struct arch_specific_insn *asi)
 
 	if (handler) {
 		/* We can emulate the instruction in (possibly) modified form */
-		asi->insn[0] = (insn & 0xfff00000) | (rn << 16) | reglist;
+		asi->insn[0] = __opcode_to_mem_arm((insn & 0xfff00000) |
+						   (rn << 16) | reglist);
 		asi->insn_handler = handler;
 		return INSN_GOOD;
 	}
@@ -338,9 +340,9 @@ prepare_emulated_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi,
 		thumb_insn[2] = 0x4770; /* Thumb bx lr */
 		return insn;
 	}
-	asi->insn[1] = 0xe12fff1e; /* ARM bx lr */
+	asi->insn[1] = __opcode_to_mem_arm(0xe12fff1e); /* ARM bx lr */
 #else
-	asi->insn[1] = 0xe1a0f00e; /* mov pc, lr */
+	asi->insn[1] = __opcode_to_mem_arm(0xe1a0f00e); /* mov pc, lr */
 #endif
 	/* Make an ARM instruction unconditional */
 	if (insn < 0xe0000000)
@@ -360,12 +362,12 @@ set_emulated_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi,
 	if (thumb) {
 		u16 *ip = (u16 *)asi->insn;
 		if (is_wide_instruction(insn))
-			*ip++ = insn >> 16;
-		*ip++ = insn;
+			*ip++ = ___asm_opcode_to_mem_thumb16(insn >> 16);
+		*ip++ = ___asm_opcode_to_mem_thumb16(insn);
 		return;
 	}
 #endif
-	asi->insn[0] = insn;
+	asi->insn[0] = __opcode_to_mem_arm(insn);
 }
 
 /*
diff --git a/arch/arm/kernel/kprobes.c b/arch/arm/kernel/kprobes.c
index 170e9f3..3775af1 100644
--- a/arch/arm/kernel/kprobes.c
+++ b/arch/arm/kernel/kprobes.c
@@ -26,6 +26,7 @@
 #include <linux/stop_machine.h>
 #include <linux/stringify.h>
 #include <asm/traps.h>
+#include <asm/opcodes.h>
 #include <asm/cacheflush.h>
 
 #include "kprobes.h"
@@ -62,10 +63,10 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
 #ifdef CONFIG_THUMB2_KERNEL
 	thumb = true;
 	addr &= ~1; /* Bit 0 would normally be set to indicate Thumb code */
-	insn = ((u16 *)addr)[0];
+	insn = __mem_to_opcode_thumb16(((u16 *)addr)[0]);
 	if (is_wide_instruction(insn)) {
-		insn <<= 16;
-		insn |= ((u16 *)addr)[1];
+		u16 inst2 = __mem_to_opcode_thumb16(((u16 *)addr)[1]);
+		insn = ___asm_opcode_thumb32_compose(insn, inst2);
 		decode_insn = thumb32_kprobe_decode_insn;
 	} else
 		decode_insn = thumb16_kprobe_decode_insn;
@@ -73,7 +74,7 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
 	thumb = false;
 	if (addr & 0x3)
 		return -EINVAL;
-	insn = *p->addr;
+	insn = __mem_to_opcode_arm(*p->addr);
 	decode_insn = arm_kprobe_decode_insn;
 #endif
 
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Thu Jul 25 17:08:57 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 22:08:57 +0100
Subject: [PATCH 4/4] ARM: kprobes-test: move to using a pointer to the title
 text
In-Reply-To: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374786537-10726-5-git-send-email-ben.dooks@codethink.co.uk>

When testing the kprobes test code with BE8, there is either an
issue with the linker or how the code is being built. The issue
is with embedding the title text as the first part of the test.

Change to placing a pointer to .rodata with the text title in it
for the test which seems to stop the issue of the alignment of
the data following it being changed arbitrarily by the linker.

The proper thing to do here is to fix the linker, however this
patch also makes the output much easier to read as there are no
variable length data items here any more.

CC: Jon Medhurst <tixy at yxit.co.uk>
Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
---
 arch/arm/kernel/kprobes-test.c |   12 +++++-------
 arch/arm/kernel/kprobes-test.h |    6 ++++--
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/kernel/kprobes-test.c b/arch/arm/kernel/kprobes-test.c
index 6cfa04d..a915ac3 100644
--- a/arch/arm/kernel/kprobes-test.c
+++ b/arch/arm/kernel/kprobes-test.c
@@ -111,9 +111,7 @@
  *	@ TESTCASE_START
  *	bl	__kprobes_test_case_start
  *	@ start of inline data...
- *	.ascii "mov r0, r7"	@ text title for test case
- *	.byte	0
- *	.align	2
+ *	.word	title_addr	 @ text title for test case
  *
  *	@ TEST_ARG_REG
  *	.byte	ARG_TYPE_REG
@@ -959,7 +957,7 @@ void __naked __kprobes_test_case_start(void)
 	__asm__ __volatile__ (
 		"stmdb	sp!, {r4-r11}				\n\t"
 		"sub	sp, sp, #"__stringify(TEST_MEMORY_SIZE)"\n\t"
-		"bic	r0, lr, #1  @ r0 = inline title string	\n\t"
+		"bic	r0, lr, #3  @ r0 = inline title block	\n\t"
 		"mov	r1, sp					\n\t"
 		"bl	kprobes_test_case_start			\n\t"
 		"bx	r0					\n\t"
@@ -1336,15 +1334,15 @@ static unsigned long next_instruction(unsigned long pc)
 	return pc + 4;
 }
 
-static uintptr_t __used kprobes_test_case_start(const char *title, void *stack)
+static uintptr_t __used kprobes_test_case_start(const char **title, void *stack)
 {
 	struct test_arg *args;
 	struct test_arg_end *end_arg;
 	unsigned long test_code;
 
-	args = (struct test_arg *)PTR_ALIGN(title + strlen(title) + 1, 4);
+	args = (struct test_arg *)(title + 1);
 
-	current_title = title;
+	current_title = *title;
 	current_args = args;
 	current_stack = stack;
 
diff --git a/arch/arm/kernel/kprobes-test.h b/arch/arm/kernel/kprobes-test.h
index e28a869..a71db09 100644
--- a/arch/arm/kernel/kprobes-test.h
+++ b/arch/arm/kernel/kprobes-test.h
@@ -113,9 +113,11 @@ struct test_arg_end {
 	"bl	__kprobes_test_case_start		\n\t"	\
 	/* don't use .asciz here as 'title' may be */		\
 	/* multiple strings to be concatenated.  */		\
-	".ascii "#title"				\n\t"	\
+	".pushsection .rodata				\n\t"	\
+	"9999: .ascii "#title"				\n\t"	\
 	".byte	0					\n\t"	\
-	".align	2					\n\t"
+	".popsection					\n\t"	\
+	".word	9999b					\n\t"
 
 #define	TEST_ARG_REG(reg, val)					\
 	".byte	"__stringify(ARG_TYPE_REG)"		\n\t"	\
-- 
1.7.10.4



From ben.dooks at codethink.co.uk  Thu Jul 25 17:08:53 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 22:08:53 +0100
Subject: fyi - kprobes testing patches
Message-ID: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>

I've been working on kprobes and the kprobes-test driver. It seems
there are more issues with the kprobes-test that need looking in to
so I am putting this series out to see if anyone has any comments



From ben.dooks at codethink.co.uk  Thu Jul 25 17:08:55 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Thu, 25 Jul 2013 22:08:55 +0100
Subject: [PATCH 2/4] ARM: kprobes, change arm test to .instr
In-Reply-To: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1374786537-10726-3-git-send-email-ben.dooks@codethink.co.uk>

use .instr for the moment, will need changing at a later date.
---
 arch/arm/kernel/kprobes-test-arm.c |  595 ++++++++++++++++++------------------
 1 file changed, 297 insertions(+), 298 deletions(-)

diff --git a/arch/arm/kernel/kprobes-test-arm.c b/arch/arm/kernel/kprobes-test-arm.c
index 8393129..52b0e2d 100644
--- a/arch/arm/kernel/kprobes-test-arm.c
+++ b/arch/arm/kernel/kprobes-test-arm.c
@@ -13,7 +13,6 @@
 
 #include "kprobes-test.h"
 
-
 #define TEST_ISA "32"
 
 #define TEST_ARM_TO_THUMB_INTERWORK_R(code1, reg, val, code2)	\
@@ -158,9 +157,9 @@ void kprobe_arm_test_cases(void)
 	TEST_SUPPORTED("cmp	sp, #0x1000");
 
 	/* Data-processing with PC as shift*/
-	TEST_UNSUPPORTED(".word 0xe15c0f1e	@ cmp	r12, r14, asl pc")
-	TEST_UNSUPPORTED(".word 0xe1a0cf1e	@ mov	r12, r14, asl pc")
-	TEST_UNSUPPORTED(".word 0xe08caf1e	@ add	r10, r12, r14, asl pc")
+	TEST_UNSUPPORTED(".inst 0xe15c0f1e	@ cmp	r12, r14, asl pc")
+	TEST_UNSUPPORTED(".inst 0xe1a0cf1e	@ mov	r12, r14, asl pc")
+	TEST_UNSUPPORTED(".inst 0xe08caf1e	@ add	r10, r12, r14, asl pc")
 
 	/* Data-processing with PC as shift*/
 	TEST_UNSUPPORTED("movs	pc, r1")
@@ -202,7 +201,7 @@ void kprobe_arm_test_cases(void)
 	TEST("mrs	r0, cpsr")
 	TEST("mrspl	r7, cpsr")
 	TEST("mrs	r14, cpsr")
-	TEST_UNSUPPORTED(".word 0xe10ff000	@ mrs r15, cpsr")
+	TEST_UNSUPPORTED(".inst 0xe10ff000	@ mrs r15, cpsr")
 	TEST_UNSUPPORTED("mrs	r0, spsr")
 	TEST_UNSUPPORTED("mrs	lr, spsr")
 
@@ -218,8 +217,8 @@ void kprobe_arm_test_cases(void)
 	TEST_R("clzeq	r7, r",14,0x1,"")
 	TEST_R("clz	lr, r",7, 0xffffffff,"")
 	TEST(  "clz	r4, sp")
-	TEST_UNSUPPORTED(".word 0x016fff10	@ clz pc, r0")
-	TEST_UNSUPPORTED(".word 0x016f0f1f	@ clz r0, pc")
+	TEST_UNSUPPORTED(".inst 0x016fff10	@ clz pc, r0")
+	TEST_UNSUPPORTED(".inst 0x016f0f1f	@ clz r0, pc")
 
 #if __LINUX_ARM_ARCH__ >= 6
 	TEST_UNSUPPORTED("bxj	r0")
@@ -228,7 +227,7 @@ void kprobe_arm_test_cases(void)
 	TEST_BF_R("blx	r",0,2f,"")
 	TEST_BB_R("blx	r",7,2f,"")
 	TEST_BF_R("blxeq	r",14,2f,"")
-	TEST_UNSUPPORTED(".word 0x0120003f	@ blx pc")
+	TEST_UNSUPPORTED(".inst 0x0120003f	@ blx pc")
 
 	TEST_RR(   "qadd	r0, r",1, VAL1,", r",2, VAL2,"")
 	TEST_RR(   "qaddvs	lr, r",9, VAL2,", r",8, VAL1,"")
@@ -242,190 +241,190 @@ void kprobe_arm_test_cases(void)
 	TEST_RR(   "qdsub	r0, r",1, VAL1,", r",2, VAL2,"")
 	TEST_RR(   "qdsubvs	lr, r",9, VAL2,", r",8, VAL1,"")
 	TEST_R(    "qdsub	lr, r",9, VAL2,", r13")
-	TEST_UNSUPPORTED(".word 0xe101f050	@ qadd pc, r0, r1")
-	TEST_UNSUPPORTED(".word 0xe121f050	@ qsub pc, r0, r1")
-	TEST_UNSUPPORTED(".word 0xe141f050	@ qdadd pc, r0, r1")
-	TEST_UNSUPPORTED(".word 0xe161f050	@ qdsub pc, r0, r1")
-	TEST_UNSUPPORTED(".word 0xe16f2050	@ qdsub r2, r0, pc")
-	TEST_UNSUPPORTED(".word 0xe161205f	@ qdsub r2, pc, r1")
+	TEST_UNSUPPORTED(".inst 0xe101f050	@ qadd pc, r0, r1")
+	TEST_UNSUPPORTED(".inst 0xe121f050	@ qsub pc, r0, r1")
+	TEST_UNSUPPORTED(".inst 0xe141f050	@ qdadd pc, r0, r1")
+	TEST_UNSUPPORTED(".inst 0xe161f050	@ qdsub pc, r0, r1")
+	TEST_UNSUPPORTED(".inst 0xe16f2050	@ qdsub r2, r0, pc")
+	TEST_UNSUPPORTED(".inst 0xe161205f	@ qdsub r2, pc, r1")
 
 	TEST_UNSUPPORTED("bkpt	0xffff")
 	TEST_UNSUPPORTED("bkpt	0x0000")
 
-	TEST_UNSUPPORTED(".word 0xe1600070 @ smc #0")
+	TEST_UNSUPPORTED(".inst 0xe1600070 @ smc #0")
 
 	TEST_GROUP("Halfword multiply and multiply-accumulate")
 
 	TEST_RRR(    "smlabb	r0, r",1, VAL1,", r",2, VAL2,", r",3,  VAL3,"")
 	TEST_RRR(    "smlabbge	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
 	TEST_RR(     "smlabb	lr, r",1, VAL2,", r",2, VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe10f3281 @ smlabb pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe10f3281 @ smlabb pc, r1, r2, r3")
 	TEST_RRR(    "smlatb	r0, r",1, VAL1,", r",2, VAL2,", r",3,  VAL3,"")
 	TEST_RRR(    "smlatbge	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
 	TEST_RR(     "smlatb	lr, r",1, VAL2,", r",2, VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe10f32a1 @ smlatb pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe10f32a1 @ smlatb pc, r1, r2, r3")
 	TEST_RRR(    "smlabt	r0, r",1, VAL1,", r",2, VAL2,", r",3,  VAL3,"")
 	TEST_RRR(    "smlabtge	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
 	TEST_RR(     "smlabt	lr, r",1, VAL2,", r",2, VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe10f32c1 @ smlabt pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe10f32c1 @ smlabt pc, r1, r2, r3")
 	TEST_RRR(    "smlatt	r0, r",1, VAL1,", r",2, VAL2,", r",3,  VAL3,"")
 	TEST_RRR(    "smlattge	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
 	TEST_RR(     "smlatt	lr, r",1, VAL2,", r",2, VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe10f32e1 @ smlatt pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe10f32e1 @ smlatt pc, r1, r2, r3")
 
 	TEST_RRR(    "smlawb	r0, r",1, VAL1,", r",2, VAL2,", r",3,  VAL3,"")
 	TEST_RRR(    "smlawbge	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
 	TEST_RR(     "smlawb	lr, r",1, VAL2,", r",2, VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe12f3281 @ smlawb pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe12f3281 @ smlawb pc, r1, r2, r3")
 	TEST_RRR(    "smlawt	r0, r",1, VAL1,", r",2, VAL2,", r",3,  VAL3,"")
 	TEST_RRR(    "smlawtge	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
 	TEST_RR(     "smlawt	lr, r",1, VAL2,", r",2, VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe12f32c1 @ smlawt pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe12032cf @ smlawt r0, pc, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe1203fc1 @ smlawt r0, r1, pc, r3")
-	TEST_UNSUPPORTED(".word 0xe120f2c1 @ smlawt r0, r1, r2, pc")
+	TEST_UNSUPPORTED(".inst 0xe12f32c1 @ smlawt pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe12032cf @ smlawt r0, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe1203fc1 @ smlawt r0, r1, pc, r3")
+	TEST_UNSUPPORTED(".inst 0xe120f2c1 @ smlawt r0, r1, r2, pc")
 
 	TEST_RR(    "smulwb	r0, r",1, VAL1,", r",2, VAL2,"")
 	TEST_RR(    "smulwbge	r7, r",8, VAL3,", r",9, VAL1,"")
 	TEST_R(     "smulwb	lr, r",1, VAL2,", r13")
-	TEST_UNSUPPORTED(".word 0xe12f02a1 @ smulwb pc, r1, r2")
+	TEST_UNSUPPORTED(".inst 0xe12f02a1 @ smulwb pc, r1, r2")
 	TEST_RR(    "smulwt	r0, r",1, VAL1,", r",2, VAL2,"")
 	TEST_RR(    "smulwtge	r7, r",8, VAL3,", r",9, VAL1,"")
 	TEST_R(     "smulwt	lr, r",1, VAL2,", r13")
-	TEST_UNSUPPORTED(".word 0xe12f02e1 @ smulwt pc, r1, r2")
+	TEST_UNSUPPORTED(".inst 0xe12f02e1 @ smulwt pc, r1, r2")
 
 	TEST_RRRR(  "smlalbb	r",0, VAL1,", r",1, VAL2,", r",2, VAL3,", r",3, VAL4)
 	TEST_RRRR(  "smlalbble	r",8, VAL4,", r",9, VAL1,", r",10,VAL2,", r",11,VAL3)
 	TEST_RRR(   "smlalbb	r",14,VAL3,", r",7, VAL4,", r",5, VAL1,", r13")
-	TEST_UNSUPPORTED(".word 0xe14f1382 @ smlalbb pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe141f382 @ smlalbb r1, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe14f1382 @ smlalbb pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe141f382 @ smlalbb r1, pc, r2, r3")
 	TEST_RRRR(  "smlaltb	r",0, VAL1,", r",1, VAL2,", r",2, VAL3,", r",3, VAL4)
 	TEST_RRRR(  "smlaltble	r",8, VAL4,", r",9, VAL1,", r",10,VAL2,", r",11,VAL3)
 	TEST_RRR(   "smlaltb	r",14,VAL3,", r",7, VAL4,", r",5, VAL1,", r13")
-	TEST_UNSUPPORTED(".word 0xe14f13a2 @ smlaltb pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe141f3a2 @ smlaltb r1, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe14f13a2 @ smlaltb pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe141f3a2 @ smlaltb r1, pc, r2, r3")
 	TEST_RRRR(  "smlalbt	r",0, VAL1,", r",1, VAL2,", r",2, VAL3,", r",3, VAL4)
 	TEST_RRRR(  "smlalbtle	r",8, VAL4,", r",9, VAL1,", r",10,VAL2,", r",11,VAL3)
 	TEST_RRR(   "smlalbt	r",14,VAL3,", r",7, VAL4,", r",5, VAL1,", r13")
-	TEST_UNSUPPORTED(".word 0xe14f13c2 @ smlalbt pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe141f3c2 @ smlalbt r1, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe14f13c2 @ smlalbt pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe141f3c2 @ smlalbt r1, pc, r2, r3")
 	TEST_RRRR(  "smlaltt	r",0, VAL1,", r",1, VAL2,", r",2, VAL3,", r",3, VAL4)
 	TEST_RRRR(  "smlalttle	r",8, VAL4,", r",9, VAL1,", r",10,VAL2,", r",11,VAL3)
 	TEST_RRR(   "smlaltt	r",14,VAL3,", r",7, VAL4,", r",5, VAL1,", r13")
-	TEST_UNSUPPORTED(".word 0xe14f13e2 @ smlalbb pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe140f3e2 @ smlalbb r0, pc, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe14013ef @ smlalbb r0, r1, pc, r3")
-	TEST_UNSUPPORTED(".word 0xe1401fe2 @ smlalbb r0, r1, r2, pc")
+	TEST_UNSUPPORTED(".inst 0xe14f13e2 @ smlalbb pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe140f3e2 @ smlalbb r0, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe14013ef @ smlalbb r0, r1, pc, r3")
+	TEST_UNSUPPORTED(".inst 0xe1401fe2 @ smlalbb r0, r1, r2, pc")
 
 	TEST_RR(    "smulbb	r0, r",1, VAL1,", r",2, VAL2,"")
 	TEST_RR(    "smulbbge	r7, r",8, VAL3,", r",9, VAL1,"")
 	TEST_R(     "smulbb	lr, r",1, VAL2,", r13")
-	TEST_UNSUPPORTED(".word 0xe16f0281 @ smulbb pc, r1, r2")
+	TEST_UNSUPPORTED(".inst 0xe16f0281 @ smulbb pc, r1, r2")
 	TEST_RR(    "smultb	r0, r",1, VAL1,", r",2, VAL2,"")
 	TEST_RR(    "smultbge	r7, r",8, VAL3,", r",9, VAL1,"")
 	TEST_R(     "smultb	lr, r",1, VAL2,", r13")
-	TEST_UNSUPPORTED(".word 0xe16f02a1 @ smultb pc, r1, r2")
+	TEST_UNSUPPORTED(".inst 0xe16f02a1 @ smultb pc, r1, r2")
 	TEST_RR(    "smulbt	r0, r",1, VAL1,", r",2, VAL2,"")
 	TEST_RR(    "smulbtge	r7, r",8, VAL3,", r",9, VAL1,"")
 	TEST_R(     "smulbt	lr, r",1, VAL2,", r13")
-	TEST_UNSUPPORTED(".word 0xe16f02c1 @ smultb pc, r1, r2")
+	TEST_UNSUPPORTED(".inst 0xe16f02c1 @ smultb pc, r1, r2")
 	TEST_RR(    "smultt	r0, r",1, VAL1,", r",2, VAL2,"")
 	TEST_RR(    "smulttge	r7, r",8, VAL3,", r",9, VAL1,"")
 	TEST_R(     "smultt	lr, r",1, VAL2,", r13")
-	TEST_UNSUPPORTED(".word 0xe16f02e1 @ smultt pc, r1, r2")
-	TEST_UNSUPPORTED(".word 0xe16002ef @ smultt r0, pc, r2")
-	TEST_UNSUPPORTED(".word 0xe1600fe1 @ smultt r0, r1, pc")
+	TEST_UNSUPPORTED(".inst 0xe16f02e1 @ smultt pc, r1, r2")
+	TEST_UNSUPPORTED(".inst 0xe16002ef @ smultt r0, pc, r2")
+	TEST_UNSUPPORTED(".inst 0xe1600fe1 @ smultt r0, r1, pc")
 
 	TEST_GROUP("Multiply and multiply-accumulate")
 
 	TEST_RR(    "mul	r0, r",1, VAL1,", r",2, VAL2,"")
 	TEST_RR(    "mulls	r7, r",8, VAL2,", r",9, VAL2,"")
 	TEST_R(     "mul	lr, r",4, VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe00f0291 @ mul pc, r1, r2")
-	TEST_UNSUPPORTED(".word 0xe000029f @ mul r0, pc, r2")
-	TEST_UNSUPPORTED(".word 0xe0000f91 @ mul r0, r1, pc")
+	TEST_UNSUPPORTED(".inst 0xe00f0291 @ mul pc, r1, r2")
+	TEST_UNSUPPORTED(".inst 0xe000029f @ mul r0, pc, r2")
+	TEST_UNSUPPORTED(".inst 0xe0000f91 @ mul r0, r1, pc")
 	TEST_RR(    "muls	r0, r",1, VAL1,", r",2, VAL2,"")
 	TEST_RR(    "mullss	r7, r",8, VAL2,", r",9, VAL2,"")
 	TEST_R(     "muls	lr, r",4, VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe01f0291 @ muls pc, r1, r2")
+	TEST_UNSUPPORTED(".inst 0xe01f0291 @ muls pc, r1, r2")
 
 	TEST_RRR(    "mla	r0, r",1, VAL1,", r",2, VAL2,", r",3,  VAL3,"")
 	TEST_RRR(    "mlahi	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
 	TEST_RR(     "mla	lr, r",1, VAL2,", r",2, VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe02f3291 @ mla pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe02f3291 @ mla pc, r1, r2, r3")
 	TEST_RRR(    "mlas	r0, r",1, VAL1,", r",2, VAL2,", r",3,  VAL3,"")
 	TEST_RRR(    "mlahis	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
 	TEST_RR(     "mlas	lr, r",1, VAL2,", r",2, VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe03f3291 @ mlas pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe03f3291 @ mlas pc, r1, r2, r3")
 
 #if __LINUX_ARM_ARCH__ >= 6
 	TEST_RR(  "umaal	r0, r1, r",2, VAL1,", r",3, VAL2,"")
 	TEST_RR(  "umaalls	r7, r8, r",9, VAL2,", r",10, VAL1,"")
 	TEST_R(   "umaal	lr, r12, r",11,VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe041f392 @ umaal pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe04f0392 @ umaal r0, pc, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe0500090 @ undef")
-	TEST_UNSUPPORTED(".word 0xe05fff9f @ undef")
+	TEST_UNSUPPORTED(".inst 0xe041f392 @ umaal pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe04f0392 @ umaal r0, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe0500090 @ undef")
+	TEST_UNSUPPORTED(".inst 0xe05fff9f @ undef")
 #endif
 
 #if __LINUX_ARM_ARCH__ >= 7
 	TEST_RRR(  "mls		r0, r",1, VAL1,", r",2, VAL2,", r",3,  VAL3,"")
 	TEST_RRR(  "mlshi	r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
 	TEST_RR(   "mls		lr, r",1, VAL2,", r",2, VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe06f3291 @ mls pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe060329f @ mls r0, pc, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe0603f91 @ mls r0, r1, pc, r3")
-	TEST_UNSUPPORTED(".word 0xe060f291 @ mls r0, r1, r2, pc")
+	TEST_UNSUPPORTED(".inst 0xe06f3291 @ mls pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe060329f @ mls r0, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe0603f91 @ mls r0, r1, pc, r3")
+	TEST_UNSUPPORTED(".inst 0xe060f291 @ mls r0, r1, r2, pc")
 #endif
 
-	TEST_UNSUPPORTED(".word 0xe0700090 @ undef")
-	TEST_UNSUPPORTED(".word 0xe07fff9f @ undef")
+	TEST_UNSUPPORTED(".inst 0xe0700090 @ undef")
+	TEST_UNSUPPORTED(".inst 0xe07fff9f @ undef")
 
 	TEST_RR(  "umull	r0, r1, r",2, VAL1,", r",3, VAL2,"")
 	TEST_RR(  "umullls	r7, r8, r",9, VAL2,", r",10, VAL1,"")
 	TEST_R(   "umull	lr, r12, r",11,VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe081f392 @ umull pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe08f1392 @ umull r1, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe081f392 @ umull pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe08f1392 @ umull r1, pc, r2, r3")
 	TEST_RR(  "umulls	r0, r1, r",2, VAL1,", r",3, VAL2,"")
 	TEST_RR(  "umulllss	r7, r8, r",9, VAL2,", r",10, VAL1,"")
 	TEST_R(   "umulls	lr, r12, r",11,VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe091f392 @ umulls pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe09f1392 @ umulls r1, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe091f392 @ umulls pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe09f1392 @ umulls r1, pc, r2, r3")
 
 	TEST_RRRR(  "umlal	r",0, VAL1,", r",1, VAL2,", r",2, VAL3,", r",3, VAL4)
 	TEST_RRRR(  "umlalle	r",8, VAL4,", r",9, VAL1,", r",10,VAL2,", r",11,VAL3)
 	TEST_RRR(   "umlal	r",14,VAL3,", r",7, VAL4,", r",5, VAL1,", r13")
-	TEST_UNSUPPORTED(".word 0xe0af1392 @ umlal pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe0a1f392 @ umlal r1, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe0af1392 @ umlal pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe0a1f392 @ umlal r1, pc, r2, r3")
 	TEST_RRRR(  "umlals	r",0, VAL1,", r",1, VAL2,", r",2, VAL3,", r",3, VAL4)
 	TEST_RRRR(  "umlalles	r",8, VAL4,", r",9, VAL1,", r",10,VAL2,", r",11,VAL3)
 	TEST_RRR(   "umlals	r",14,VAL3,", r",7, VAL4,", r",5, VAL1,", r13")
-	TEST_UNSUPPORTED(".word 0xe0bf1392 @ umlals pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe0b1f392 @ umlals r1, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe0bf1392 @ umlals pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe0b1f392 @ umlals r1, pc, r2, r3")
 
 	TEST_RR(  "smull	r0, r1, r",2, VAL1,", r",3, VAL2,"")
 	TEST_RR(  "smullls	r7, r8, r",9, VAL2,", r",10, VAL1,"")
 	TEST_R(   "smull	lr, r12, r",11,VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe0c1f392 @ smull pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe0cf1392 @ smull r1, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe0c1f392 @ smull pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe0cf1392 @ smull r1, pc, r2, r3")
 	TEST_RR(  "smulls	r0, r1, r",2, VAL1,", r",3, VAL2,"")
 	TEST_RR(  "smulllss	r7, r8, r",9, VAL2,", r",10, VAL1,"")
 	TEST_R(   "smulls	lr, r12, r",11,VAL3,", r13")
-	TEST_UNSUPPORTED(".word 0xe0d1f392 @ smulls pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe0df1392 @ smulls r1, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe0d1f392 @ smulls pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe0df1392 @ smulls r1, pc, r2, r3")
 
 	TEST_RRRR(  "smlal	r",0, VAL1,", r",1, VAL2,", r",2, VAL3,", r",3, VAL4)
 	TEST_RRRR(  "smlalle	r",8, VAL4,", r",9, VAL1,", r",10,VAL2,", r",11,VAL3)
 	TEST_RRR(   "smlal	r",14,VAL3,", r",7, VAL4,", r",5, VAL1,", r13")
-	TEST_UNSUPPORTED(".word 0xe0ef1392 @ smlal pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe0e1f392 @ smlal r1, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe0ef1392 @ smlal pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe0e1f392 @ smlal r1, pc, r2, r3")
 	TEST_RRRR(  "smlals	r",0, VAL1,", r",1, VAL2,", r",2, VAL3,", r",3, VAL4)
 	TEST_RRRR(  "smlalles	r",8, VAL4,", r",9, VAL1,", r",10,VAL2,", r",11,VAL3)
 	TEST_RRR(   "smlals	r",14,VAL3,", r",7, VAL4,", r",5, VAL1,", r13")
-	TEST_UNSUPPORTED(".word 0xe0ff1392 @ smlals pc, r1, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe0f0f392 @ smlals r0, pc, r2, r3")
-	TEST_UNSUPPORTED(".word 0xe0f0139f @ smlals r0, r1, pc, r3")
-	TEST_UNSUPPORTED(".word 0xe0f01f92 @ smlals r0, r1, r2, pc")
+	TEST_UNSUPPORTED(".inst 0xe0ff1392 @ smlals pc, r1, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe0f0f392 @ smlals r0, pc, r2, r3")
+	TEST_UNSUPPORTED(".inst 0xe0f0139f @ smlals r0, r1, pc, r3")
+	TEST_UNSUPPORTED(".inst 0xe0f01f92 @ smlals r0, r1, r2, pc")
 
 	TEST_GROUP("Synchronization primitives")
 
@@ -434,28 +433,28 @@ void kprobe_arm_test_cases(void)
 	TEST_R( "swpvs	r0, r",1,VAL1,", [sp]")
 	TEST_RP("swp	sp, r",14,VAL2,", [r",12,13*4,"]")
 #else
-	TEST_UNSUPPORTED(".word 0xe108e097 @ swp	lr, r7, [r8]")
-	TEST_UNSUPPORTED(".word 0x610d0091 @ swpvs	r0, r1, [sp]")
-	TEST_UNSUPPORTED(".word 0xe10cd09e @ swp	sp, r14 [r12]")
+	TEST_UNSUPPORTED(".inst 0xe108e097 @ swp	lr, r7, [r8]")
+	TEST_UNSUPPORTED(".inst 0x610d0091 @ swpvs	r0, r1, [sp]")
+	TEST_UNSUPPORTED(".inst 0xe10cd09e @ swp	sp, r14 [r12]")
 #endif
-	TEST_UNSUPPORTED(".word 0xe102f091 @ swp pc, r1, [r2]")
-	TEST_UNSUPPORTED(".word 0xe102009f @ swp r0, pc, [r2]")
-	TEST_UNSUPPORTED(".word 0xe10f0091 @ swp r0, r1, [pc]")
+	TEST_UNSUPPORTED(".inst 0xe102f091 @ swp pc, r1, [r2]")
+	TEST_UNSUPPORTED(".inst 0xe102009f @ swp r0, pc, [r2]")
+	TEST_UNSUPPORTED(".inst 0xe10f0091 @ swp r0, r1, [pc]")
 #if __LINUX_ARM_ARCH__ < 6
 	TEST_RP("swpb	lr, r",7,VAL2,", [r",8,0,"]")
 	TEST_R( "swpvsb	r0, r",1,VAL1,", [sp]")
 #else
-	TEST_UNSUPPORTED(".word 0xe148e097 @ swpb	lr, r7, [r8]")
-	TEST_UNSUPPORTED(".word 0x614d0091 @ swpvsb	r0, r1, [sp]")
+	TEST_UNSUPPORTED(".inst 0xe148e097 @ swpb	lr, r7, [r8]")
+	TEST_UNSUPPORTED(".inst 0x614d0091 @ swpvsb	r0, r1, [sp]")
 #endif
-	TEST_UNSUPPORTED(".word 0xe142f091 @ swpb pc, r1, [r2]")
-
-	TEST_UNSUPPORTED(".word	0xe1100090") /* Unallocated space */
-	TEST_UNSUPPORTED(".word	0xe1200090") /* Unallocated space */
-	TEST_UNSUPPORTED(".word	0xe1300090") /* Unallocated space */
-	TEST_UNSUPPORTED(".word	0xe1500090") /* Unallocated space */
-	TEST_UNSUPPORTED(".word	0xe1600090") /* Unallocated space */
-	TEST_UNSUPPORTED(".word	0xe1700090") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe142f091 @ swpb pc, r1, [r2]")
+
+	TEST_UNSUPPORTED(".inst	0xe1100090") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst	0xe1200090") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst	0xe1300090") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst	0xe1500090") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst	0xe1600090") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst	0xe1700090") /* Unallocated space */
 #if __LINUX_ARM_ARCH__ >= 6
 	TEST_UNSUPPORTED("ldrex	r2, [sp]")
 #endif
@@ -475,9 +474,9 @@ void kprobe_arm_test_cases(void)
 	TEST_RPR(  "strneh	r",12,VAL2,", [r",11,48,", -r",10,24,"]!")
 	TEST_RPR(  "strh	r",2, VAL1,", [r",3, 24,"], r",4, 48,"")
 	TEST_RPR(  "strh	r",10,VAL2,", [r",9, 48,"], -r",11,24,"")
-	TEST_UNSUPPORTED(".word 0xe1afc0ba	@ strh r12, [pc, r10]!")
-	TEST_UNSUPPORTED(".word 0xe089f0bb	@ strh pc, [r9], r11")
-	TEST_UNSUPPORTED(".word 0xe089a0bf	@ strh r10, [r9], pc")
+	TEST_UNSUPPORTED(".inst 0xe1afc0ba	@ strh r12, [pc, r10]!")
+	TEST_UNSUPPORTED(".inst 0xe089f0bb	@ strh pc, [r9], r11")
+	TEST_UNSUPPORTED(".inst 0xe089a0bf	@ strh r10, [r9], pc")
 
 	TEST_PR(   "ldrh	r0, [r",0,  48,", -r",2, 24,"]")
 	TEST_PR(   "ldrcsh	r14, [r",13,0, ", r",12, 48,"]")
@@ -485,9 +484,9 @@ void kprobe_arm_test_cases(void)
 	TEST_PR(   "ldrcch	r12, [r",11,48,", -r",10,24,"]!")
 	TEST_PR(   "ldrh	r2, [r",3,  24,"], r",4, 48,"")
 	TEST_PR(   "ldrh	r10, [r",9, 48,"], -r",11,24,"")
-	TEST_UNSUPPORTED(".word 0xe1bfc0ba	@ ldrh r12, [pc, r10]!")
-	TEST_UNSUPPORTED(".word 0xe099f0bb	@ ldrh pc, [r9], r11")
-	TEST_UNSUPPORTED(".word 0xe099a0bf	@ ldrh r10, [r9], pc")
+	TEST_UNSUPPORTED(".inst 0xe1bfc0ba	@ ldrh r12, [pc, r10]!")
+	TEST_UNSUPPORTED(".inst 0xe099f0bb	@ ldrh pc, [r9], r11")
+	TEST_UNSUPPORTED(".inst 0xe099a0bf	@ ldrh r10, [r9], pc")
 
 	TEST_RP(   "strh	r",0, VAL1,", [r",1, 24,", #-2]")
 	TEST_RP(   "strmih	r",14,VAL2,", [r",13,0, ", #2]")
@@ -495,8 +494,8 @@ void kprobe_arm_test_cases(void)
 	TEST_RP(   "strplh	r",12,VAL2,", [r",11,24,", #-4]!")
 	TEST_RP(   "strh	r",2, VAL1,", [r",3, 24,"], #48")
 	TEST_RP(   "strh	r",10,VAL2,", [r",9, 64,"], #-48")
-	TEST_UNSUPPORTED(".word 0xe1efc3b0	@ strh r12, [pc, #48]!")
-	TEST_UNSUPPORTED(".word 0xe0c9f3b0	@ strh pc, [r9], #48")
+	TEST_UNSUPPORTED(".inst 0xe1efc3b0	@ strh r12, [pc, #48]!")
+	TEST_UNSUPPORTED(".inst 0xe0c9f3b0	@ strh pc, [r9], #48")
 
 	TEST_P(	   "ldrh	r0, [r",0,  24,", #-2]")
 	TEST_P(	   "ldrvsh	r14, [r",13,0, ", #2]")
@@ -505,8 +504,8 @@ void kprobe_arm_test_cases(void)
 	TEST_P(	   "ldrh	r2, [r",3,  24,"], #48")
 	TEST_P(	   "ldrh	r10, [r",9, 64,"], #-48")
 	TEST(      "ldrh	r0, [pc, #0]")
-	TEST_UNSUPPORTED(".word 0xe1ffc3b0	@ ldrh r12, [pc, #48]!")
-	TEST_UNSUPPORTED(".word 0xe0d9f3b0	@ ldrh pc, [r9], #48")
+	TEST_UNSUPPORTED(".inst 0xe1ffc3b0	@ ldrh r12, [pc, #48]!")
+	TEST_UNSUPPORTED(".inst 0xe0d9f3b0	@ ldrh pc, [r9], #48")
 
 	TEST_PR(   "ldrsb	r0, [r",0,  48,", -r",2, 24,"]")
 	TEST_PR(   "ldrhisb	r14, [r",13,0,", r",12,  48,"]")
@@ -514,8 +513,8 @@ void kprobe_arm_test_cases(void)
 	TEST_PR(   "ldrlssb	r12, [r",11,48,", -r",10,24,"]!")
 	TEST_PR(   "ldrsb	r2, [r",3,  24,"], r",4, 48,"")
 	TEST_PR(   "ldrsb	r10, [r",9, 48,"], -r",11,24,"")
-	TEST_UNSUPPORTED(".word 0xe1bfc0da	@ ldrsb r12, [pc, r10]!")
-	TEST_UNSUPPORTED(".word 0xe099f0db	@ ldrsb pc, [r9], r11")
+	TEST_UNSUPPORTED(".inst 0xe1bfc0da	@ ldrsb r12, [pc, r10]!")
+	TEST_UNSUPPORTED(".inst 0xe099f0db	@ ldrsb pc, [r9], r11")
 
 	TEST_P(	   "ldrsb	r0, [r",0,  24,", #-1]")
 	TEST_P(	   "ldrgesb	r14, [r",13,0, ", #1]")
@@ -524,8 +523,8 @@ void kprobe_arm_test_cases(void)
 	TEST_P(	   "ldrsb	r2, [r",3,  24,"], #48")
 	TEST_P(	   "ldrsb	r10, [r",9, 64,"], #-48")
 	TEST(      "ldrsb	r0, [pc, #0]")
-	TEST_UNSUPPORTED(".word 0xe1ffc3d0	@ ldrsb r12, [pc, #48]!")
-	TEST_UNSUPPORTED(".word 0xe0d9f3d0	@ ldrsb pc, [r9], #48")
+	TEST_UNSUPPORTED(".inst 0xe1ffc3d0	@ ldrsb r12, [pc, #48]!")
+	TEST_UNSUPPORTED(".inst 0xe0d9f3d0	@ ldrsb pc, [r9], #48")
 
 	TEST_PR(   "ldrsh	r0, [r",0,  48,", -r",2, 24,"]")
 	TEST_PR(   "ldrgtsh	r14, [r",13,0, ", r",12, 48,"]")
@@ -533,8 +532,8 @@ void kprobe_arm_test_cases(void)
 	TEST_PR(   "ldrlesh	r12, [r",11,48,", -r",10,24,"]!")
 	TEST_PR(   "ldrsh	r2, [r",3,  24,"], r",4, 48,"")
 	TEST_PR(   "ldrsh	r10, [r",9, 48,"], -r",11,24,"")
-	TEST_UNSUPPORTED(".word 0xe1bfc0fa	@ ldrsh r12, [pc, r10]!")
-	TEST_UNSUPPORTED(".word 0xe099f0fb	@ ldrsh pc, [r9], r11")
+	TEST_UNSUPPORTED(".inst 0xe1bfc0fa	@ ldrsh r12, [pc, r10]!")
+	TEST_UNSUPPORTED(".inst 0xe099f0fb	@ ldrsh pc, [r9], r11")
 
 	TEST_P(	   "ldrsh	r0, [r",0,  24,", #-1]")
 	TEST_P(	   "ldreqsh	r14, [r",13,0 ,", #1]")
@@ -543,8 +542,8 @@ void kprobe_arm_test_cases(void)
 	TEST_P(	   "ldrsh	r2, [r",3,  24,"], #48")
 	TEST_P(	   "ldrsh	r10, [r",9, 64,"], #-48")
 	TEST(      "ldrsh	r0, [pc, #0]")
-	TEST_UNSUPPORTED(".word 0xe1ffc3f0	@ ldrsh r12, [pc, #48]!")
-	TEST_UNSUPPORTED(".word 0xe0d9f3f0	@ ldrsh pc, [r9], #48")
+	TEST_UNSUPPORTED(".inst 0xe1ffc3f0	@ ldrsh r12, [pc, #48]!")
+	TEST_UNSUPPORTED(".inst 0xe0d9f3f0	@ ldrsh pc, [r9], #48")
 
 #if __LINUX_ARM_ARCH__ >= 7
 	TEST_UNSUPPORTED("strht	r1, [r2], r3")
@@ -563,7 +562,7 @@ void kprobe_arm_test_cases(void)
 	TEST_RPR(  "strcsd	r",12,VAL2,", [r",11,48,", -r",10,24,"]!")
 	TEST_RPR(  "strd	r",2, VAL1,", [r",5, 24,"], r",4,48,"")
 	TEST_RPR(  "strd	r",10,VAL2,", [r",9, 48,"], -r",7,24,"")
-	TEST_UNSUPPORTED(".word 0xe1afc0fa	@ strd r12, [pc, r10]!")
+	TEST_UNSUPPORTED(".inst 0xe1afc0fa	@ strd r12, [pc, r10]!")
 
 	TEST_PR(   "ldrd	r0, [r",0, 48,", -r",2,24,"]")
 	TEST_PR(   "ldrmid	r8, [r",13,0, ", r",12,48,"]")
@@ -571,10 +570,10 @@ void kprobe_arm_test_cases(void)
 	TEST_PR(   "ldrpld	r6, [r",11,48,", -r",10,24,"]!")
 	TEST_PR(   "ldrd	r2, [r",5, 24,"], r",4,48,"")
 	TEST_PR(   "ldrd	r10, [r",9,48,"], -r",7,24,"")
-	TEST_UNSUPPORTED(".word 0xe1afc0da	@ ldrd r12, [pc, r10]!")
-	TEST_UNSUPPORTED(".word 0xe089f0db	@ ldrd pc, [r9], r11")
-	TEST_UNSUPPORTED(".word 0xe089e0db	@ ldrd lr, [r9], r11")
-	TEST_UNSUPPORTED(".word 0xe089c0df	@ ldrd r12, [r9], pc")
+	TEST_UNSUPPORTED(".inst 0xe1afc0da	@ ldrd r12, [pc, r10]!")
+	TEST_UNSUPPORTED(".inst 0xe089f0db	@ ldrd pc, [r9], r11")
+	TEST_UNSUPPORTED(".inst 0xe089e0db	@ ldrd lr, [r9], r11")
+	TEST_UNSUPPORTED(".inst 0xe089c0df	@ ldrd r12, [r9], pc")
 
 	TEST_RP(   "strd	r",0, VAL1,", [r",1, 24,", #-8]")
 	TEST_RP(   "strvsd	r",8, VAL2,", [r",13,0, ", #8]")
@@ -582,7 +581,7 @@ void kprobe_arm_test_cases(void)
 	TEST_RP(   "strvcd	r",12,VAL2,", [r",11,24,", #-16]!")
 	TEST_RP(   "strd	r",2, VAL1,", [r",4, 24,"], #48")
 	TEST_RP(   "strd	r",10,VAL2,", [r",9, 64,"], #-48")
-	TEST_UNSUPPORTED(".word 0xe1efc3f0	@ strd r12, [pc, #48]!")
+	TEST_UNSUPPORTED(".inst 0xe1efc3f0	@ strd r12, [pc, #48]!")
 
 	TEST_P(	   "ldrd	r0, [r",0, 24,", #-8]")
 	TEST_P(	   "ldrhid	r8, [r",13,0, ", #8]")
@@ -590,9 +589,9 @@ void kprobe_arm_test_cases(void)
 	TEST_P(	   "ldrlsd	r6, [r",11,24,", #-16]!")
 	TEST_P(	   "ldrd	r2, [r",5, 24,"], #48")
 	TEST_P(	   "ldrd	r10, [r",9,6,"], #-48")
-	TEST_UNSUPPORTED(".word 0xe1efc3d0	@ ldrd r12, [pc, #48]!")
-	TEST_UNSUPPORTED(".word 0xe0c9f3d0	@ ldrd pc, [r9], #48")
-	TEST_UNSUPPORTED(".word 0xe0c9e3d0	@ ldrd lr, [r9], #48")
+	TEST_UNSUPPORTED(".inst 0xe1efc3d0	@ ldrd r12, [pc, #48]!")
+	TEST_UNSUPPORTED(".inst 0xe0c9f3d0	@ ldrd pc, [r9], #48")
+	TEST_UNSUPPORTED(".inst 0xe0c9e3d0	@ ldrd lr, [r9], #48")
 
 	TEST_GROUP("Miscellaneous")
 
@@ -600,11 +599,11 @@ void kprobe_arm_test_cases(void)
 	TEST("movw	r0, #0")
 	TEST("movw	r0, #0xffff")
 	TEST("movw	lr, #0xffff")
-	TEST_UNSUPPORTED(".word 0xe300f000	@ movw pc, #0")
+	TEST_UNSUPPORTED(".inst 0xe300f000	@ movw pc, #0")
 	TEST_R("movt	r",0, VAL1,", #0")
 	TEST_R("movt	r",0, VAL2,", #0xffff")
 	TEST_R("movt	r",14,VAL1,", #0xffff")
-	TEST_UNSUPPORTED(".word 0xe340f000	@ movt pc, #0")
+	TEST_UNSUPPORTED(".inst 0xe340f000	@ movt pc, #0")
 #endif
 
 	TEST_UNSUPPORTED("msr	cpsr, 0x13")
@@ -672,20 +671,20 @@ void kprobe_arm_test_cases(void)
 #ifdef CONFIG_THUMB2_KERNEL
 	TEST_ARM_TO_THUMB_INTERWORK_P("ldr	pc, [r",0,0,", #15*4]")
 #endif
-	TEST_UNSUPPORTED(".word 0xe5af6008	@ str r6, [pc, #8]!")
-	TEST_UNSUPPORTED(".word 0xe7af6008	@ str r6, [pc, r8]!")
-	TEST_UNSUPPORTED(".word 0xe5bf6008	@ ldr r6, [pc, #8]!")
-	TEST_UNSUPPORTED(".word 0xe7bf6008	@ ldr r6, [pc, r8]!")
-	TEST_UNSUPPORTED(".word 0xe788600f	@ str r6, [r8, pc]")
-	TEST_UNSUPPORTED(".word 0xe798600f	@ ldr r6, [r8, pc]")
+	TEST_UNSUPPORTED(".inst 0xe5af6008	@ str r6, [pc, #8]!")
+	TEST_UNSUPPORTED(".inst 0xe7af6008	@ str r6, [pc, r8]!")
+	TEST_UNSUPPORTED(".inst 0xe5bf6008	@ ldr r6, [pc, #8]!")
+	TEST_UNSUPPORTED(".inst 0xe7bf6008	@ ldr r6, [pc, r8]!")
+	TEST_UNSUPPORTED(".inst 0xe788600f	@ str r6, [r8, pc]")
+	TEST_UNSUPPORTED(".inst 0xe798600f	@ ldr r6, [r8, pc]")
 
 	LOAD_STORE("b")
-	TEST_UNSUPPORTED(".word 0xe5f7f008	@ ldrb pc, [r7, #8]!")
-	TEST_UNSUPPORTED(".word 0xe7f7f008	@ ldrb pc, [r7, r8]!")
-	TEST_UNSUPPORTED(".word 0xe5ef6008	@ strb r6, [pc, #8]!")
-	TEST_UNSUPPORTED(".word 0xe7ef6008	@ strb r6, [pc, r3]!")
-	TEST_UNSUPPORTED(".word 0xe5ff6008	@ ldrb r6, [pc, #8]!")
-	TEST_UNSUPPORTED(".word 0xe7ff6008	@ ldrb r6, [pc, r3]!")
+	TEST_UNSUPPORTED(".inst 0xe5f7f008	@ ldrb pc, [r7, #8]!")
+	TEST_UNSUPPORTED(".inst 0xe7f7f008	@ ldrb pc, [r7, r8]!")
+	TEST_UNSUPPORTED(".inst 0xe5ef6008	@ strb r6, [pc, #8]!")
+	TEST_UNSUPPORTED(".inst 0xe7ef6008	@ strb r6, [pc, r3]!")
+	TEST_UNSUPPORTED(".inst 0xe5ff6008	@ ldrb r6, [pc, #8]!")
+	TEST_UNSUPPORTED(".inst 0xe7ff6008	@ ldrb r6, [pc, r3]!")
 
 	TEST_UNSUPPORTED("ldrt	r0, [r1], #4")
 	TEST_UNSUPPORTED("ldrt	r1, [r2], r3")
@@ -699,153 +698,153 @@ void kprobe_arm_test_cases(void)
 #if __LINUX_ARM_ARCH__ >= 7
 	TEST_GROUP("Parallel addition and subtraction, signed")
 
-	TEST_UNSUPPORTED(".word 0xe6000010") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe60fffff") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe6000010") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe60fffff") /* Unallocated space */
 
 	TEST_RR(    "sadd16	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "sadd16	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe61cff1a	@ sadd16	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe61cff1a	@ sadd16	pc, r12, r10")
 	TEST_RR(    "sasx	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "sasx	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe61cff3a	@ sasx	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe61cff3a	@ sasx	pc, r12, r10")
 	TEST_RR(    "ssax	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "ssax	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe61cff5a	@ ssax	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe61cff5a	@ ssax	pc, r12, r10")
 	TEST_RR(    "ssub16	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "ssub16	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe61cff7a	@ ssub16	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe61cff7a	@ ssub16	pc, r12, r10")
 	TEST_RR(    "sadd8	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "sadd8	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe61cff9a	@ sadd8	pc, r12, r10")
-	TEST_UNSUPPORTED(".word 0xe61000b0") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe61fffbf") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe61000d0") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe61fffdf") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe61cff9a	@ sadd8	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe61000b0") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe61fffbf") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe61000d0") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe61fffdf") /* Unallocated space */
 	TEST_RR(    "ssub8	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "ssub8	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe61cfffa	@ ssub8	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe61cfffa	@ ssub8	pc, r12, r10")
 
 	TEST_RR(    "qadd16	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "qadd16	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe62cff1a	@ qadd16	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe62cff1a	@ qadd16	pc, r12, r10")
 	TEST_RR(    "qasx	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "qasx	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe62cff3a	@ qasx	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe62cff3a	@ qasx	pc, r12, r10")
 	TEST_RR(    "qsax	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "qsax	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe62cff5a	@ qsax	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe62cff5a	@ qsax	pc, r12, r10")
 	TEST_RR(    "qsub16	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "qsub16	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe62cff7a	@ qsub16	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe62cff7a	@ qsub16	pc, r12, r10")
 	TEST_RR(    "qadd8	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "qadd8	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe62cff9a	@ qadd8	pc, r12, r10")
-	TEST_UNSUPPORTED(".word 0xe62000b0") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe62fffbf") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe62000d0") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe62fffdf") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe62cff9a	@ qadd8	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe62000b0") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe62fffbf") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe62000d0") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe62fffdf") /* Unallocated space */
 	TEST_RR(    "qsub8	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "qsub8	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe62cfffa	@ qsub8	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe62cfffa	@ qsub8	pc, r12, r10")
 
 	TEST_RR(    "shadd16	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "shadd16	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe63cff1a	@ shadd16	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe63cff1a	@ shadd16	pc, r12, r10")
 	TEST_RR(    "shasx	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "shasx	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe63cff3a	@ shasx	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe63cff3a	@ shasx	pc, r12, r10")
 	TEST_RR(    "shsax	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "shsax	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe63cff5a	@ shsax	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe63cff5a	@ shsax	pc, r12, r10")
 	TEST_RR(    "shsub16	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "shsub16	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe63cff7a	@ shsub16	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe63cff7a	@ shsub16	pc, r12, r10")
 	TEST_RR(    "shadd8	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "shadd8	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe63cff9a	@ shadd8	pc, r12, r10")
-	TEST_UNSUPPORTED(".word 0xe63000b0") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe63fffbf") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe63000d0") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe63fffdf") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe63cff9a	@ shadd8	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe63000b0") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe63fffbf") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe63000d0") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe63fffdf") /* Unallocated space */
 	TEST_RR(    "shsub8	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "shsub8	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe63cfffa	@ shsub8	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe63cfffa	@ shsub8	pc, r12, r10")
 
 	TEST_GROUP("Parallel addition and subtraction, unsigned")
 
-	TEST_UNSUPPORTED(".word 0xe6400010") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe64fffff") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe6400010") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe64fffff") /* Unallocated space */
 
 	TEST_RR(    "uadd16	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uadd16	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe65cff1a	@ uadd16	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe65cff1a	@ uadd16	pc, r12, r10")
 	TEST_RR(    "uasx	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uasx	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe65cff3a	@ uasx	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe65cff3a	@ uasx	pc, r12, r10")
 	TEST_RR(    "usax	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "usax	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe65cff5a	@ usax	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe65cff5a	@ usax	pc, r12, r10")
 	TEST_RR(    "usub16	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "usub16	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe65cff7a	@ usub16	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe65cff7a	@ usub16	pc, r12, r10")
 	TEST_RR(    "uadd8	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uadd8	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe65cff9a	@ uadd8	pc, r12, r10")
-	TEST_UNSUPPORTED(".word 0xe65000b0") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe65fffbf") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe65000d0") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe65fffdf") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe65cff9a	@ uadd8	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe65000b0") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe65fffbf") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe65000d0") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe65fffdf") /* Unallocated space */
 	TEST_RR(    "usub8	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "usub8	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe65cfffa	@ usub8	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe65cfffa	@ usub8	pc, r12, r10")
 
 	TEST_RR(    "uqadd16	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uqadd16	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe66cff1a	@ uqadd16	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe66cff1a	@ uqadd16	pc, r12, r10")
 	TEST_RR(    "uqasx	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uqasx	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe66cff3a	@ uqasx	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe66cff3a	@ uqasx	pc, r12, r10")
 	TEST_RR(    "uqsax	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uqsax	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe66cff5a	@ uqsax	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe66cff5a	@ uqsax	pc, r12, r10")
 	TEST_RR(    "uqsub16	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uqsub16	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe66cff7a	@ uqsub16	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe66cff7a	@ uqsub16	pc, r12, r10")
 	TEST_RR(    "uqadd8	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uqadd8	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe66cff9a	@ uqadd8	pc, r12, r10")
-	TEST_UNSUPPORTED(".word 0xe66000b0") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe66fffbf") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe66000d0") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe66fffdf") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe66cff9a	@ uqadd8	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe66000b0") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe66fffbf") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe66000d0") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe66fffdf") /* Unallocated space */
 	TEST_RR(    "uqsub8	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uqsub8	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe66cfffa	@ uqsub8	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe66cfffa	@ uqsub8	pc, r12, r10")
 
 	TEST_RR(    "uhadd16	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uhadd16	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe67cff1a	@ uhadd16	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe67cff1a	@ uhadd16	pc, r12, r10")
 	TEST_RR(    "uhasx	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uhasx	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe67cff3a	@ uhasx	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe67cff3a	@ uhasx	pc, r12, r10")
 	TEST_RR(    "uhsax	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uhsax	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe67cff5a	@ uhsax	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe67cff5a	@ uhsax	pc, r12, r10")
 	TEST_RR(    "uhsub16	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uhsub16	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe67cff7a	@ uhsub16	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe67cff7a	@ uhsub16	pc, r12, r10")
 	TEST_RR(    "uhadd8	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uhadd8	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe67cff9a	@ uhadd8	pc, r12, r10")
-	TEST_UNSUPPORTED(".word 0xe67000b0") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe67fffbf") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe67000d0") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe67fffdf") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe67cff9a	@ uhadd8	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe67000b0") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe67fffbf") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe67000d0") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe67fffdf") /* Unallocated space */
 	TEST_RR(    "uhsub8	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uhsub8	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe67cfffa	@ uhsub8	pc, r12, r10")
-	TEST_UNSUPPORTED(".word 0xe67feffa	@ uhsub8	r14, pc, r10")
-	TEST_UNSUPPORTED(".word 0xe67cefff	@ uhsub8	r14, r12, pc")
+	TEST_UNSUPPORTED(".inst 0xe67cfffa	@ uhsub8	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe67feffa	@ uhsub8	r14, pc, r10")
+	TEST_UNSUPPORTED(".inst 0xe67cefff	@ uhsub8	r14, r12, pc")
 #endif /* __LINUX_ARM_ARCH__ >= 7 */
 
 #if __LINUX_ARM_ARCH__ >= 6
@@ -853,99 +852,99 @@ void kprobe_arm_test_cases(void)
 
 	TEST_RR(    "pkhbt	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "pkhbt	r14,r",12, HH1,", r",10,HH2,", lsl #2")
-	TEST_UNSUPPORTED(".word 0xe68cf11a	@ pkhbt	pc, r12, r10, lsl #2")
+	TEST_UNSUPPORTED(".inst 0xe68cf11a	@ pkhbt	pc, r12, r10, lsl #2")
 	TEST_RR(    "pkhtb	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "pkhtb	r14,r",12, HH1,", r",10,HH2,", asr #2")
-	TEST_UNSUPPORTED(".word 0xe68cf15a	@ pkhtb	pc, r12, r10, asr #2")
-	TEST_UNSUPPORTED(".word 0xe68fe15a	@ pkhtb	r14, pc, r10, asr #2")
-	TEST_UNSUPPORTED(".word 0xe68ce15f	@ pkhtb	r14, r12, pc, asr #2")
-	TEST_UNSUPPORTED(".word 0xe6900010") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe69fffdf") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe68cf15a	@ pkhtb	pc, r12, r10, asr #2")
+	TEST_UNSUPPORTED(".inst 0xe68fe15a	@ pkhtb	r14, pc, r10, asr #2")
+	TEST_UNSUPPORTED(".inst 0xe68ce15f	@ pkhtb	r14, r12, pc, asr #2")
+	TEST_UNSUPPORTED(".inst 0xe6900010") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe69fffdf") /* Unallocated space */
 
 	TEST_R(     "ssat	r0, #24, r",0,   VAL1,"")
 	TEST_R(     "ssat	r14, #24, r",12, VAL2,"")
 	TEST_R(     "ssat	r0, #24, r",0,   VAL1,", lsl #8")
 	TEST_R(     "ssat	r14, #24, r",12, VAL2,", asr #8")
-	TEST_UNSUPPORTED(".word 0xe6b7f01c	@ ssat	pc, #24, r12")
+	TEST_UNSUPPORTED(".inst 0xe6b7f01c	@ ssat	pc, #24, r12")
 
 	TEST_R(     "usat	r0, #24, r",0,   VAL1,"")
 	TEST_R(     "usat	r14, #24, r",12, VAL2,"")
 	TEST_R(     "usat	r0, #24, r",0,   VAL1,", lsl #8")
 	TEST_R(     "usat	r14, #24, r",12, VAL2,", asr #8")
-	TEST_UNSUPPORTED(".word 0xe6f7f01c	@ usat	pc, #24, r12")
+	TEST_UNSUPPORTED(".inst 0xe6f7f01c	@ usat	pc, #24, r12")
 
 	TEST_RR(    "sxtab16	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "sxtab16	r14,r",12, HH2,", r",10,HH1,", ror #8")
 	TEST_R(     "sxtb16	r8, r",7,  HH1,"")
-	TEST_UNSUPPORTED(".word 0xe68cf47a	@ sxtab16	pc,r12, r10, ror #8")
+	TEST_UNSUPPORTED(".inst 0xe68cf47a	@ sxtab16	pc,r12, r10, ror #8")
 
 	TEST_RR(    "sel	r0, r",0,  VAL1,", r",1, VAL2,"")
 	TEST_RR(    "sel	r14, r",12,VAL1,", r",10, VAL2,"")
-	TEST_UNSUPPORTED(".word 0xe68cffba	@ sel	pc, r12, r10")
-	TEST_UNSUPPORTED(".word 0xe68fefba	@ sel	r14, pc, r10")
-	TEST_UNSUPPORTED(".word 0xe68cefbf	@ sel	r14, r12, pc")
+	TEST_UNSUPPORTED(".inst 0xe68cffba	@ sel	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe68fefba	@ sel	r14, pc, r10")
+	TEST_UNSUPPORTED(".inst 0xe68cefbf	@ sel	r14, r12, pc")
 
 	TEST_R(     "ssat16	r0, #12, r",0,   HH1,"")
 	TEST_R(     "ssat16	r14, #12, r",12, HH2,"")
-	TEST_UNSUPPORTED(".word 0xe6abff3c	@ ssat16	pc, #12, r12")
+	TEST_UNSUPPORTED(".inst 0xe6abff3c	@ ssat16	pc, #12, r12")
 
 	TEST_RR(    "sxtab	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "sxtab	r14,r",12, HH2,", r",10,HH1,", ror #8")
 	TEST_R(     "sxtb	r8, r",7,  HH1,"")
-	TEST_UNSUPPORTED(".word 0xe6acf47a	@ sxtab	pc,r12, r10, ror #8")
+	TEST_UNSUPPORTED(".inst 0xe6acf47a	@ sxtab	pc,r12, r10, ror #8")
 
 	TEST_R(     "rev	r0, r",0,   VAL1,"")
 	TEST_R(     "rev	r14, r",12, VAL2,"")
-	TEST_UNSUPPORTED(".word 0xe6bfff3c	@ rev	pc, r12")
+	TEST_UNSUPPORTED(".inst 0xe6bfff3c	@ rev	pc, r12")
 
 	TEST_RR(    "sxtah	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "sxtah	r14,r",12, HH2,", r",10,HH1,", ror #8")
 	TEST_R(     "sxth	r8, r",7,  HH1,"")
-	TEST_UNSUPPORTED(".word 0xe6bcf47a	@ sxtah	pc,r12, r10, ror #8")
+	TEST_UNSUPPORTED(".inst 0xe6bcf47a	@ sxtah	pc,r12, r10, ror #8")
 
 	TEST_R(     "rev16	r0, r",0,   VAL1,"")
 	TEST_R(     "rev16	r14, r",12, VAL2,"")
-	TEST_UNSUPPORTED(".word 0xe6bfffbc	@ rev16	pc, r12")
+	TEST_UNSUPPORTED(".inst 0xe6bfffbc	@ rev16	pc, r12")
 
 	TEST_RR(    "uxtab16	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uxtab16	r14,r",12, HH2,", r",10,HH1,", ror #8")
 	TEST_R(     "uxtb16	r8, r",7,  HH1,"")
-	TEST_UNSUPPORTED(".word 0xe6ccf47a	@ uxtab16	pc,r12, r10, ror #8")
+	TEST_UNSUPPORTED(".inst 0xe6ccf47a	@ uxtab16	pc,r12, r10, ror #8")
 
 	TEST_R(     "usat16	r0, #12, r",0,   HH1,"")
 	TEST_R(     "usat16	r14, #12, r",12, HH2,"")
-	TEST_UNSUPPORTED(".word 0xe6ecff3c	@ usat16	pc, #12, r12")
-	TEST_UNSUPPORTED(".word 0xe6ecef3f	@ usat16	r14, #12, pc")
+	TEST_UNSUPPORTED(".inst 0xe6ecff3c	@ usat16	pc, #12, r12")
+	TEST_UNSUPPORTED(".inst 0xe6ecef3f	@ usat16	r14, #12, pc")
 
 	TEST_RR(    "uxtab	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uxtab	r14,r",12, HH2,", r",10,HH1,", ror #8")
 	TEST_R(     "uxtb	r8, r",7,  HH1,"")
-	TEST_UNSUPPORTED(".word 0xe6ecf47a	@ uxtab	pc,r12, r10, ror #8")
+	TEST_UNSUPPORTED(".inst 0xe6ecf47a	@ uxtab	pc,r12, r10, ror #8")
 
 #if __LINUX_ARM_ARCH__ >= 7
 	TEST_R(     "rbit	r0, r",0,   VAL1,"")
 	TEST_R(     "rbit	r14, r",12, VAL2,"")
-	TEST_UNSUPPORTED(".word 0xe6ffff3c	@ rbit	pc, r12")
+	TEST_UNSUPPORTED(".inst 0xe6ffff3c	@ rbit	pc, r12")
 #endif
 
 	TEST_RR(    "uxtah	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(    "uxtah	r14,r",12, HH2,", r",10,HH1,", ror #8")
 	TEST_R(     "uxth	r8, r",7,  HH1,"")
-	TEST_UNSUPPORTED(".word 0xe6fff077	@ uxth	pc, r7")
-	TEST_UNSUPPORTED(".word 0xe6ff807f	@ uxth	r8, pc")
-	TEST_UNSUPPORTED(".word 0xe6fcf47a	@ uxtah	pc, r12, r10, ror #8")
-	TEST_UNSUPPORTED(".word 0xe6fce47f	@ uxtah	r14, r12, pc, ror #8")
+	TEST_UNSUPPORTED(".inst 0xe6fff077	@ uxth	pc, r7")
+	TEST_UNSUPPORTED(".inst 0xe6ff807f	@ uxth	r8, pc")
+	TEST_UNSUPPORTED(".inst 0xe6fcf47a	@ uxtah	pc, r12, r10, ror #8")
+	TEST_UNSUPPORTED(".inst 0xe6fce47f	@ uxtah	r14, r12, pc, ror #8")
 
 	TEST_R(     "revsh	r0, r",0,   VAL1,"")
 	TEST_R(     "revsh	r14, r",12, VAL2,"")
-	TEST_UNSUPPORTED(".word 0xe6ffff3c	@ revsh	pc, r12")
-	TEST_UNSUPPORTED(".word 0xe6ffef3f	@ revsh	r14, pc")
+	TEST_UNSUPPORTED(".inst 0xe6ffff3c	@ revsh	pc, r12")
+	TEST_UNSUPPORTED(".inst 0xe6ffef3f	@ revsh	r14, pc")
 
-	TEST_UNSUPPORTED(".word 0xe6900070") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe69fff7f") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe6900070") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe69fff7f") /* Unallocated space */
 
-	TEST_UNSUPPORTED(".word 0xe6d00070") /* Unallocated space */
-	TEST_UNSUPPORTED(".word 0xe6dfff7f") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe6d00070") /* Unallocated space */
+	TEST_UNSUPPORTED(".inst 0xe6dfff7f") /* Unallocated space */
 #endif /* __LINUX_ARM_ARCH__ >= 6 */
 
 #if __LINUX_ARM_ARCH__ >= 6
@@ -953,79 +952,79 @@ void kprobe_arm_test_cases(void)
 
 	TEST_RRR(   "smlad	r0, r",0,  HH1,", r",1, HH2,", r",2, VAL1,"")
 	TEST_RRR(   "smlad	r14, r",12,HH2,", r",10,HH1,", r",8, VAL2,"")
-	TEST_UNSUPPORTED(".word 0xe70f8a1c	@ smlad	pc, r12, r10, r8")
+	TEST_UNSUPPORTED(".inst 0xe70f8a1c	@ smlad	pc, r12, r10, r8")
 	TEST_RRR(   "smladx	r0, r",0,  HH1,", r",1, HH2,", r",2, VAL1,"")
 	TEST_RRR(   "smladx	r14, r",12,HH2,", r",10,HH1,", r",8, VAL2,"")
-	TEST_UNSUPPORTED(".word 0xe70f8a3c	@ smladx	pc, r12, r10, r8")
+	TEST_UNSUPPORTED(".inst 0xe70f8a3c	@ smladx	pc, r12, r10, r8")
 
 	TEST_RR(   "smuad	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(   "smuad	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe70ffa1c	@ smuad	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe70ffa1c	@ smuad	pc, r12, r10")
 	TEST_RR(   "smuadx	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(   "smuadx	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe70ffa3c	@ smuadx	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe70ffa3c	@ smuadx	pc, r12, r10")
 
 	TEST_RRR(   "smlsd	r0, r",0,  HH1,", r",1, HH2,", r",2, VAL1,"")
 	TEST_RRR(   "smlsd	r14, r",12,HH2,", r",10,HH1,", r",8, VAL2,"")
-	TEST_UNSUPPORTED(".word 0xe70f8a5c	@ smlsd	pc, r12, r10, r8")
+	TEST_UNSUPPORTED(".inst 0xe70f8a5c	@ smlsd	pc, r12, r10, r8")
 	TEST_RRR(   "smlsdx	r0, r",0,  HH1,", r",1, HH2,", r",2, VAL1,"")
 	TEST_RRR(   "smlsdx	r14, r",12,HH2,", r",10,HH1,", r",8, VAL2,"")
-	TEST_UNSUPPORTED(".word 0xe70f8a7c	@ smlsdx	pc, r12, r10, r8")
+	TEST_UNSUPPORTED(".inst 0xe70f8a7c	@ smlsdx	pc, r12, r10, r8")
 
 	TEST_RR(   "smusd	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(   "smusd	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe70ffa5c	@ smusd	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe70ffa5c	@ smusd	pc, r12, r10")
 	TEST_RR(   "smusdx	r0, r",0,  HH1,", r",1, HH2,"")
 	TEST_RR(   "smusdx	r14, r",12,HH2,", r",10,HH1,"")
-	TEST_UNSUPPORTED(".word 0xe70ffa7c	@ smusdx	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe70ffa7c	@ smusdx	pc, r12, r10")
 
 	TEST_RRRR( "smlald	r",0, VAL1,", r",1, VAL2, ", r",0, HH1,", r",1, HH2)
 	TEST_RRRR( "smlald	r",11,VAL2,", r",10,VAL1, ", r",9, HH2,", r",8, HH1)
-	TEST_UNSUPPORTED(".word 0xe74af819	@ smlald	pc, r10, r9, r8")
-	TEST_UNSUPPORTED(".word 0xe74fb819	@ smlald	r11, pc, r9, r8")
-	TEST_UNSUPPORTED(".word 0xe74ab81f	@ smlald	r11, r10, pc, r8")
-	TEST_UNSUPPORTED(".word 0xe74abf19	@ smlald	r11, r10, r9, pc")
+	TEST_UNSUPPORTED(".inst 0xe74af819	@ smlald	pc, r10, r9, r8")
+	TEST_UNSUPPORTED(".inst 0xe74fb819	@ smlald	r11, pc, r9, r8")
+	TEST_UNSUPPORTED(".inst 0xe74ab81f	@ smlald	r11, r10, pc, r8")
+	TEST_UNSUPPORTED(".inst 0xe74abf19	@ smlald	r11, r10, r9, pc")
 
 	TEST_RRRR( "smlaldx	r",0, VAL1,", r",1, VAL2, ", r",0, HH1,", r",1, HH2)
 	TEST_RRRR( "smlaldx	r",11,VAL2,", r",10,VAL1, ", r",9, HH2,", r",8, HH1)
-	TEST_UNSUPPORTED(".word 0xe74af839	@ smlaldx	pc, r10, r9, r8")
-	TEST_UNSUPPORTED(".word 0xe74fb839	@ smlaldx	r11, pc, r9, r8")
+	TEST_UNSUPPORTED(".inst 0xe74af839	@ smlaldx	pc, r10, r9, r8")
+	TEST_UNSUPPORTED(".inst 0xe74fb839	@ smlaldx	r11, pc, r9, r8")
 
 	TEST_RRR(  "smmla	r0, r",0,  VAL1,", r",1, VAL2,", r",2, VAL1,"")
 	TEST_RRR(  "smmla	r14, r",12,VAL2,", r",10,VAL1,", r",8, VAL2,"")
-	TEST_UNSUPPORTED(".word 0xe75f8a1c	@ smmla	pc, r12, r10, r8")
+	TEST_UNSUPPORTED(".inst 0xe75f8a1c	@ smmla	pc, r12, r10, r8")
 	TEST_RRR(  "smmlar	r0, r",0,  VAL1,", r",1, VAL2,", r",2, VAL1,"")
 	TEST_RRR(  "smmlar	r14, r",12,VAL2,", r",10,VAL1,", r",8, VAL2,"")
-	TEST_UNSUPPORTED(".word 0xe75f8a3c	@ smmlar	pc, r12, r10, r8")
+	TEST_UNSUPPORTED(".inst 0xe75f8a3c	@ smmlar	pc, r12, r10, r8")
 
 	TEST_RR(   "smmul	r0, r",0,  VAL1,", r",1, VAL2,"")
 	TEST_RR(   "smmul	r14, r",12,VAL2,", r",10,VAL1,"")
-	TEST_UNSUPPORTED(".word 0xe75ffa1c	@ smmul	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe75ffa1c	@ smmul	pc, r12, r10")
 	TEST_RR(   "smmulr	r0, r",0,  VAL1,", r",1, VAL2,"")
 	TEST_RR(   "smmulr	r14, r",12,VAL2,", r",10,VAL1,"")
-	TEST_UNSUPPORTED(".word 0xe75ffa3c	@ smmulr	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe75ffa3c	@ smmulr	pc, r12, r10")
 
 	TEST_RRR(  "smmls	r0, r",0,  VAL1,", r",1, VAL2,", r",2, VAL1,"")
 	TEST_RRR(  "smmls	r14, r",12,VAL2,", r",10,VAL1,", r",8, VAL2,"")
-	TEST_UNSUPPORTED(".word 0xe75f8adc	@ smmls	pc, r12, r10, r8")
+	TEST_UNSUPPORTED(".inst 0xe75f8adc	@ smmls	pc, r12, r10, r8")
 	TEST_RRR(  "smmlsr	r0, r",0,  VAL1,", r",1, VAL2,", r",2, VAL1,"")
 	TEST_RRR(  "smmlsr	r14, r",12,VAL2,", r",10,VAL1,", r",8, VAL2,"")
-	TEST_UNSUPPORTED(".word 0xe75f8afc	@ smmlsr	pc, r12, r10, r8")
-	TEST_UNSUPPORTED(".word 0xe75e8aff	@ smmlsr	r14, pc, r10, r8")
-	TEST_UNSUPPORTED(".word 0xe75e8ffc	@ smmlsr	r14, r12, pc, r8")
-	TEST_UNSUPPORTED(".word 0xe75efafc	@ smmlsr	r14, r12, r10, pc")
+	TEST_UNSUPPORTED(".inst 0xe75f8afc	@ smmlsr	pc, r12, r10, r8")
+	TEST_UNSUPPORTED(".inst 0xe75e8aff	@ smmlsr	r14, pc, r10, r8")
+	TEST_UNSUPPORTED(".inst 0xe75e8ffc	@ smmlsr	r14, r12, pc, r8")
+	TEST_UNSUPPORTED(".inst 0xe75efafc	@ smmlsr	r14, r12, r10, pc")
 
 	TEST_RR(   "usad8	r0, r",0,  VAL1,", r",1, VAL2,"")
 	TEST_RR(   "usad8	r14, r",12,VAL2,", r",10,VAL1,"")
-	TEST_UNSUPPORTED(".word 0xe75ffa1c	@ usad8	pc, r12, r10")
-	TEST_UNSUPPORTED(".word 0xe75efa1f	@ usad8	r14, pc, r10")
-	TEST_UNSUPPORTED(".word 0xe75eff1c	@ usad8	r14, r12, pc")
+	TEST_UNSUPPORTED(".inst 0xe75ffa1c	@ usad8	pc, r12, r10")
+	TEST_UNSUPPORTED(".inst 0xe75efa1f	@ usad8	r14, pc, r10")
+	TEST_UNSUPPORTED(".inst 0xe75eff1c	@ usad8	r14, r12, pc")
 
 	TEST_RRR(  "usada8	r0, r",0,  VAL1,", r",1, VAL2,", r",2, VAL3,"")
 	TEST_RRR(  "usada8	r14, r",12,VAL2,", r",10,VAL1,", r",8, VAL3,"")
-	TEST_UNSUPPORTED(".word 0xe78f8a1c	@ usada8	pc, r12, r10, r8")
-	TEST_UNSUPPORTED(".word 0xe78e8a1f	@ usada8	r14, pc, r10, r8")
-	TEST_UNSUPPORTED(".word 0xe78e8f1c	@ usada8	r14, r12, pc, r8")
+	TEST_UNSUPPORTED(".inst 0xe78f8a1c	@ usada8	pc, r12, r10, r8")
+	TEST_UNSUPPORTED(".inst 0xe78e8a1f	@ usada8	r14, pc, r10, r8")
+	TEST_UNSUPPORTED(".inst 0xe78e8f1c	@ usada8	r14, r12, pc, r8")
 #endif /* __LINUX_ARM_ARCH__ >= 6 */
 
 #if __LINUX_ARM_ARCH__ >= 7
@@ -1034,26 +1033,26 @@ void kprobe_arm_test_cases(void)
 	TEST_R(     "sbfx	r0, r",0  , VAL1,", #0, #31")
 	TEST_R(     "sbfxeq	r14, r",12, VAL2,", #8, #16")
 	TEST_R(     "sbfx	r4, r",10,  VAL1,", #16, #15")
-	TEST_UNSUPPORTED(".word 0xe7aff45c	@ sbfx	pc, r12, #8, #16")
+	TEST_UNSUPPORTED(".inst 0xe7aff45c	@ sbfx	pc, r12, #8, #16")
 
 	TEST_R(     "ubfx	r0, r",0  , VAL1,", #0, #31")
 	TEST_R(     "ubfxcs	r14, r",12, VAL2,", #8, #16")
 	TEST_R(     "ubfx	r4, r",10,  VAL1,", #16, #15")
-	TEST_UNSUPPORTED(".word 0xe7eff45c	@ ubfx	pc, r12, #8, #16")
-	TEST_UNSUPPORTED(".word 0xe7efc45f	@ ubfx	r12, pc, #8, #16")
+	TEST_UNSUPPORTED(".inst 0xe7eff45c	@ ubfx	pc, r12, #8, #16")
+	TEST_UNSUPPORTED(".inst 0xe7efc45f	@ ubfx	r12, pc, #8, #16")
 
 	TEST_R(     "bfc	r",0, VAL1,", #4, #20")
 	TEST_R(     "bfcvs	r",14,VAL2,", #4, #20")
 	TEST_R(     "bfc	r",7, VAL1,", #0, #31")
 	TEST_R(     "bfc	r",8, VAL2,", #0, #31")
-	TEST_UNSUPPORTED(".word 0xe7def01f	@ bfc	pc, #0, #31");
+	TEST_UNSUPPORTED(".inst 0xe7def01f	@ bfc	pc, #0, #31");
 
 	TEST_RR(    "bfi	r",0, VAL1,", r",0  , VAL2,", #0, #31")
 	TEST_RR(    "bfipl	r",12,VAL1,", r",14 , VAL2,", #4, #20")
-	TEST_UNSUPPORTED(".word 0xe7d7f21e	@ bfi	pc, r14, #4, #20")
+	TEST_UNSUPPORTED(".inst 0xe7d7f21e	@ bfi	pc, r14, #4, #20")
 
-	TEST_UNSUPPORTED(".word 0x07f000f0")  /* Permanently UNDEFINED */
-	TEST_UNSUPPORTED(".word 0x07ffffff")  /* Permanently UNDEFINED */
+	TEST_UNSUPPORTED(".inst 0x07f000f0")  /* Permanently UNDEFINED */
+	TEST_UNSUPPORTED(".inst 0x07ffffff")  /* Permanently UNDEFINED */
 #endif /* __LINUX_ARM_ARCH__ >= 6 */
 
 	TEST_GROUP("Branch, branch with link, and block data transfer")
@@ -1180,43 +1179,43 @@ void kprobe_arm_test_cases(void)
 										\
 	TEST_COPROCESSOR( "stc"two"	0, cr0, [r15, #4]")			\
 	TEST_COPROCESSOR( "stc"two"	0, cr0, [r15, #-4]")			\
-	TEST_UNSUPPORTED(".word 0x"cc"daf0001	@ stc"two"	0, cr0, [r15, #4]!")	\
-	TEST_UNSUPPORTED(".word 0x"cc"d2f0001	@ stc"two"	0, cr0, [r15, #-4]!")	\
-	TEST_UNSUPPORTED(".word 0x"cc"caf0001	@ stc"two"	0, cr0, [r15], #4")	\
-	TEST_UNSUPPORTED(".word 0x"cc"c2f0001	@ stc"two"	0, cr0, [r15], #-4")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"daf0001	@ stc"two"	0, cr0, [r15, #4]!")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"d2f0001	@ stc"two"	0, cr0, [r15, #-4]!")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"caf0001	@ stc"two"	0, cr0, [r15], #4")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"c2f0001	@ stc"two"	0, cr0, [r15], #-4")	\
 	TEST_COPROCESSOR( "stc"two"	0, cr0, [r15], {1}")			\
 	TEST_COPROCESSOR( "stc"two"l	0, cr0, [r15, #4]")			\
 	TEST_COPROCESSOR( "stc"two"l	0, cr0, [r15, #-4]")			\
-	TEST_UNSUPPORTED(".word 0x"cc"def0001	@ stc"two"l	0, cr0, [r15, #4]!")	\
-	TEST_UNSUPPORTED(".word 0x"cc"d6f0001	@ stc"two"l	0, cr0, [r15, #-4]!")	\
-	TEST_UNSUPPORTED(".word 0x"cc"cef0001	@ stc"two"l	0, cr0, [r15], #4")	\
-	TEST_UNSUPPORTED(".word 0x"cc"c6f0001	@ stc"two"l	0, cr0, [r15], #-4")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"def0001	@ stc"two"l	0, cr0, [r15, #4]!")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"d6f0001	@ stc"two"l	0, cr0, [r15, #-4]!")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"cef0001	@ stc"two"l	0, cr0, [r15], #4")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"c6f0001	@ stc"two"l	0, cr0, [r15], #-4")	\
 	TEST_COPROCESSOR( "stc"two"l	0, cr0, [r15], {1}")			\
 	TEST_COPROCESSOR( "ldc"two"	0, cr0, [r15, #4]")			\
 	TEST_COPROCESSOR( "ldc"two"	0, cr0, [r15, #-4]")			\
-	TEST_UNSUPPORTED(".word 0x"cc"dbf0001	@ ldc"two"	0, cr0, [r15, #4]!")	\
-	TEST_UNSUPPORTED(".word 0x"cc"d3f0001	@ ldc"two"	0, cr0, [r15, #-4]!")	\
-	TEST_UNSUPPORTED(".word 0x"cc"cbf0001	@ ldc"two"	0, cr0, [r15], #4")	\
-	TEST_UNSUPPORTED(".word 0x"cc"c3f0001	@ ldc"two"	0, cr0, [r15], #-4")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"dbf0001	@ ldc"two"	0, cr0, [r15, #4]!")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"d3f0001	@ ldc"two"	0, cr0, [r15, #-4]!")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"cbf0001	@ ldc"two"	0, cr0, [r15], #4")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"c3f0001	@ ldc"two"	0, cr0, [r15], #-4")	\
 	TEST_COPROCESSOR( "ldc"two"	0, cr0, [r15], {1}")			\
 	TEST_COPROCESSOR( "ldc"two"l	0, cr0, [r15, #4]")			\
 	TEST_COPROCESSOR( "ldc"two"l	0, cr0, [r15, #-4]")			\
-	TEST_UNSUPPORTED(".word 0x"cc"dff0001	@ ldc"two"l	0, cr0, [r15, #4]!")	\
-	TEST_UNSUPPORTED(".word 0x"cc"d7f0001	@ ldc"two"l	0, cr0, [r15, #-4]!")	\
-	TEST_UNSUPPORTED(".word 0x"cc"cff0001	@ ldc"two"l	0, cr0, [r15], #4")	\
-	TEST_UNSUPPORTED(".word 0x"cc"c7f0001	@ ldc"two"l	0, cr0, [r15], #-4")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"dff0001	@ ldc"two"l	0, cr0, [r15, #4]!")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"d7f0001	@ ldc"two"l	0, cr0, [r15, #-4]!")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"cff0001	@ ldc"two"l	0, cr0, [r15], #4")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"c7f0001	@ ldc"two"l	0, cr0, [r15], #-4")	\
 	TEST_COPROCESSOR( "ldc"two"l	0, cr0, [r15], {1}")
 
 #define COPROCESSOR_INSTRUCTIONS_MC_MR(two,cc)					\
 										\
 	TEST_COPROCESSOR( "mcrr"two"	0, 15, r0, r14, cr0")			\
 	TEST_COPROCESSOR( "mcrr"two"	15, 0, r14, r0, cr15")			\
-	TEST_UNSUPPORTED(".word 0x"cc"c4f00f0	@ mcrr"two"	0, 15, r0, r15, cr0")	\
-	TEST_UNSUPPORTED(".word 0x"cc"c40ff0f	@ mcrr"two"	15, 0, r15, r0, cr15")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"c4f00f0	@ mcrr"two"	0, 15, r0, r15, cr0")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"c40ff0f	@ mcrr"two"	15, 0, r15, r0, cr15")	\
 	TEST_COPROCESSOR( "mrrc"two"	0, 15, r0, r14, cr0")			\
 	TEST_COPROCESSOR( "mrrc"two"	15, 0, r14, r0, cr15")			\
-	TEST_UNSUPPORTED(".word 0x"cc"c5f00f0	@ mrrc"two"	0, 15, r0, r15, cr0")	\
-	TEST_UNSUPPORTED(".word 0x"cc"c50ff0f	@ mrrc"two"	15, 0, r15, r0, cr15")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"c5f00f0	@ mrrc"two"	0, 15, r0, r15, cr0")	\
+	TEST_UNSUPPORTED(".inst 0x"cc"c50ff0f	@ mrrc"two"	15, 0, r15, r0, cr15")	\
 	TEST_COPROCESSOR( "cdp"two"	15, 15, cr15, cr15, cr15, 7")		\
 	TEST_COPROCESSOR( "cdp"two"	0, 0, cr0, cr0, cr0, 0")		\
 	TEST_COPROCESSOR( "mcr"two"	15, 7, r15, cr15, cr15, 7")		\
@@ -1251,14 +1250,14 @@ void kprobe_arm_test_cases(void)
 	TEST_UNSUPPORTED("rfedb	sp!")
 	TEST_UNSUPPORTED("rfeia	sp!")
 	TEST_UNSUPPORTED("rfeib	sp!")
-	TEST_UNSUPPORTED(".word 0xf81d0a00	@ rfeda	pc")
-	TEST_UNSUPPORTED(".word 0xf91d0a00	@ rfedb	pc")
-	TEST_UNSUPPORTED(".word 0xf89d0a00	@ rfeia	pc")
-	TEST_UNSUPPORTED(".word 0xf99d0a00	@ rfeib	pc")
-	TEST_UNSUPPORTED(".word 0xf83d0a00	@ rfeda	pc!")
-	TEST_UNSUPPORTED(".word 0xf93d0a00	@ rfedb	pc!")
-	TEST_UNSUPPORTED(".word 0xf8bd0a00	@ rfeia	pc!")
-	TEST_UNSUPPORTED(".word 0xf9bd0a00	@ rfeib	pc!")
+	TEST_UNSUPPORTED(".inst 0xf81d0a00	@ rfeda	pc")
+	TEST_UNSUPPORTED(".inst 0xf91d0a00	@ rfedb	pc")
+	TEST_UNSUPPORTED(".inst 0xf89d0a00	@ rfeia	pc")
+	TEST_UNSUPPORTED(".inst 0xf99d0a00	@ rfeib	pc")
+	TEST_UNSUPPORTED(".inst 0xf83d0a00	@ rfeda	pc!")
+	TEST_UNSUPPORTED(".inst 0xf93d0a00	@ rfedb	pc!")
+	TEST_UNSUPPORTED(".inst 0xf8bd0a00	@ rfeia	pc!")
+	TEST_UNSUPPORTED(".inst 0xf9bd0a00	@ rfeib	pc!")
 #endif /* __LINUX_ARM_ARCH__ >= 6 */
 
 #if __LINUX_ARM_ARCH__ >= 6
@@ -1317,9 +1316,9 @@ void kprobe_arm_test_cases(void)
 #endif
 
 #if __LINUX_ARM_ARCH__ >= 7
-	TEST_SUPPORTED(  ".word 0xf590f000	@ pldw [r0, #0]")
-	TEST_SUPPORTED(  ".word 0xf797f000	@ pldw	[r7, r0]")
-	TEST_SUPPORTED(  ".word 0xf798f18c	@ pldw	[r8, r12, lsl #3]");
+	TEST_SUPPORTED(  ".inst 0xf590f000	@ pldw [r0, #0]")
+	TEST_SUPPORTED(  ".inst 0xf797f000	@ pldw	[r7, r0]")
+	TEST_SUPPORTED(  ".inst 0xf798f18c	@ pldw	[r8, r12, lsl #3]");
 #endif
 
 #if __LINUX_ARM_ARCH__ >= 7
-- 
1.7.10.4



From sylvester.nawrocki at gmail.com  Thu Jul 25 17:13:25 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Thu, 25 Jul 2013 23:13:25 +0200
Subject: [PATCH] clk: exynos4: Add CLK_GET_RATE_NOCACHE flag for the
 Exynos4x12 ISP clocks
In-Reply-To: <20130725202337.7598.20912@quantum>
References: <1372099374-21008-1-git-send-email-s.nawrocki@samsung.com>
 <51ED2230.8080100@samsung.com> <20130725202337.7598.20912@quantum>
Message-ID: <51F194F5.8040303@gmail.com>

On 07/25/2013 10:23 PM, Mike Turquette wrote:
> Quoting Sylwester Nawrocki (2013-07-22 05:14:40)
>> On 06/24/2013 08:42 PM, Sylwester Nawrocki wrote:
>>> The ISP clock registers belong to the ISP power domain and may change
>>> their values if this power domain is switched off/on. Add
>>> CLK_GET_RATE_NOCACHE flags to ensure we do not rely on invalid cached
>>> data when setting or getting frequency of those clocks.
>>>
>>> Signed-off-by: Sylwester Nawrocki<s.nawrocki at samsung.com>
>>> Signed-off-by: Kyungmin Park<kyungmin.park at samsung.com>
>>
>> Mike,
>>
>> would you consider queueing that patch for current -rc cycle ?
>
> Sylwester,
>
> Can you rebase this onto -rc2? It does not apply cleanly onto my -fixes
> branch.

Sure, I've just posted an updated version.

Thanks,
Sylwester


From fabio.estevam at freescale.com  Thu Jul 25 17:18:33 2013
From: fabio.estevam at freescale.com (Fabio Estevam)
Date: Thu, 25 Jul 2013 18:18:33 -0300
Subject: [PATCH] ARM: dts: imx53-qsb: Make USBH1 functional
Message-ID: <1374787113-6628-1-git-send-email-fabio.estevam@freescale.com>

mx53qsb uses GPIO7_8 to turn on VBUS, so add support for it.

Also specify the PHY type in the device tree.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
In order to test USBH1 the following patch is also needed:
"[PATCH] chipidea: core: Move hw_phymode_configure() into probe"

Just sent it to the linux-usb list.

 arch/arm/boot/dts/imx53-qsb.dts | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
index eedd27e..e97ddae 100644
--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@ -93,6 +93,15 @@
 			regulator-max-microvolt = <3200000>;
 			regulator-always-on;
 		};
+
+		reg_usb_vbus: usb_vbus {
+			compatible = "regulator-fixed";
+			regulator-name = "usb_vbus";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			gpio = <&gpio7 8 0>;
+			enable-active-high;
+		};
 	};
 
 	sound {
@@ -145,6 +154,7 @@
 				MX53_PAD_EIM_DA12__GPIO3_12       0x80000000
 				MX53_PAD_EIM_DA13__GPIO3_13       0x80000000
 				MX53_PAD_PATA_DA_0__GPIO7_6       0x80000000
+				MX53_PAD_PATA_DA_2__GPIO7_8	  0x80000000
 				MX53_PAD_GPIO_16__GPIO7_11        0x80000000
 			>;
 		};
@@ -302,7 +312,9 @@
 };
 
 &usbh1 {
-       status = "okay";
+	vbus-supply = <&reg_usb_vbus>;
+	phy_type = "utmi";
+	status = "okay";
 };
 
 &usbotg {
-- 
1.8.1.2




From csd at broadcom.com  Thu Jul 25 17:37:07 2013
From: csd at broadcom.com (Christian Daudt)
Date: Thu, 25 Jul 2013 14:37:07 -0700
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X
 SoC with ARM CPU
In-Reply-To: <51F18BAA.1050806@hauke-m.de>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130723184907.GA6811@ohporter.com>
 <CAGVrzcbA72AYu6J3JXBirQQeTiDH9cJThdBdH=Q=gJtOnqz-AA@mail.gmail.com>
 <20130723192203.GC6811@ohporter.com> <51EF1B8C.9020304@broadcom.com>
 <CADjby3WGW6f=1Vdm2kx+Re0KrjFRaC3dQOumpnS6_sp2yb5NfQ@mail.gmail.com>
 <51F02947.7020301@hauke-m.de> <20130724225443.GA29801@glitch>
 <51F18BAA.1050806@hauke-m.de>
Message-ID: <51F19A83.2090000@broadcom.com>

On 13-07-25 01:33 PM, Hauke Mehrtens wrote:
> On 07/25/2013 12:54 AM, Domenico Andreoli wrote:
>> On Wed, Jul 24, 2013 at 09:21:43PM +0200, Hauke Mehrtens wrote:
>>> On 07/24/2013 02:44 AM, Domenico Andreoli wrote:
>>>> On Wednesday, July 24, 2013, Hauke Mehrtens <hauke at hauke-m.de
>>>> <mailto:hauke at hauke-m.de>> wrote:
>>>>> On 07/19/2013 03:36 AM, Domenico Andreoli wrote:
>>>>>> On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote:
>>>>>>> On 07/16/2013 05:20 PM, Thomas Petazzoni wrote:
>>>>>>>>> diff --git a/arch/arm/mach-bcm53xx/Kconfig
>>>> b/arch/arm/mach-bcm53xx/Kconfig
>>>>>>>>> new file mode 100644
>>>>>>>>> index 0000000..1e16e87
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/arch/arm/mach-bcm53xx/Kconfig
>>>>>>>>> @@ -0,0 +1,10 @@
>>>>>>>>> +config ARCH_BCM53XX
>>>>>>>>> +  bool "Broadcom BCM47XX / BCM53XX ARM SoC"
>>>>>>>> So the directory is named mach-bcm53xx, but you also handle BCM47xx
>>>>>>>> SoCs. This doesn't sound really easy to follow.
>>>>>> At the time of the BCM281XX merge we considered that such directories
>>>> would
>>>>>> mostly contain board files only, being these new entries DT based. Hence
>>>>>> the choice of mach-bcm to collect all of them.
>>>>>>
>>>>>> I think you should then put this stuff there.
>>>>> So you think I should move the file from
>>>>> arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?
>>>> yes
>>>>
>>>> this looks more comsistent with the actual soc name:
>>>> arch/arm/mach-bcm/bcm530xx.c
>>>>
>>>> but I find also acceptable the complete name of the "parent" soc (as I'm
>>>> doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c
>>> I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351)
>>> have more in common than the vendor name, so I do not think it is a good
>>> idea to place them all at mach-bcm.
>> In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever
>> two or more SoCs share can hopefully modelled in a driver and as such
>> would go in the drivers/ subtree. What's left is really SoC specific and,
>> again hopefully, very minimal.
>>
>> There should not be any SoC so weird to require a whole subdirectory full
>> of that SoC specific stuff. So grouping everything by vendor name looks
>> quite appealing to me.
>>
>> Sharing the same subdir requires people working in it to talk and find
>> agreements some more than the sparsely populated subdir did (because there
>> is not a single maintainer who owns it). I think this is a big advantage
>> Broadcomers can start with right now.
> I want to be able to build the BCM5301X SoC without building the current
> CONFIG_ARCH_BCM, so what name do you suggest for board_bcm.o ?
> My plan would be to make CONFIG_ARCH_BCM just activate the Broadcom
> submenu, but not build any code. Then the list of Broadcom SoCs is
> opened like CONFIG_ARCH_BCM5301X and the "old" CONFIG_ARCH_BCM.
>
>
CONFIG_ARCH_BCM wasn't the best name, but it is there now. We intend to 
upstream the (mobile-team) ARM SoCs going forward, and have them be 
multiplatform and all buildable into a single zImage with the ARCH_BCM 
config option. Which is why this option does not have a chip name on it.
Take ARCH_BCM == Broadcom Mobile team SoCs (I think that's what the help 
on it says).

  thanks,
    csd




From jgunthorpe at obsidianresearch.com  Thu Jul 25 17:37:53 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Thu, 25 Jul 2013 15:37:53 -0600
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130725184834.GA8296@netboy>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
Message-ID: <20130725213753.GC17616@obsidianresearch.com>

On Thu, Jul 25, 2013 at 08:48:34PM +0200, Richard Cochran wrote:
> On Thu, Jul 25, 2013 at 07:29:20PM +0100, Mark Rutland wrote:
> > On Thu, Jul 25, 2013 at 07:05:48PM +0100, Stephen Warren wrote:
> > > 
> > > I don't think having people "rely" on the bindings is the issue so much
> > > as the awareness that if they do, there will be compatibility issues for
> > > unstable bindings.
> > 
> > As long as we can make sufficiently clear that trying to use an unstable
> > binding is going to be *very* painful, and not necessarily supported.
> 
> Oh, man.
> 
> The introduction of DT into ARM Linux was supposed to make everyone's
> life sooo much easier. Of course, based on experience with powerpc, I
> never believed it*, but still I would expect to hear that the DT
> bindings are, well, a *binding* contract between the board developer,
> boot loader, and the kernel.

To restate a perspective I've shared before (as someone shipping
embedded products with DT on PPC and ARM).

We use DT has a kernel configuration input. Our environment is
designed to guarantee 100% that the kernel and DT match exactly. DT
very deliberately isn't an ABI boundary in our systems.

We've been doing this for years and have a proven in the field track
record of upgrades from pre-2.6.16 to 3.7 and beyond with multiple
SOCs. The same bootloader that was shipped to support non-DT 2.6.16
boots DT 3.7 just fine.

For closed system embedded DT has proven *WONDERFUL*. It is a huge,
gigantic improvement over what we had before. The introduction of DT
carried with it an increase in generality and configurability that has
gone far beyond what was possible using just board.c files (back in
the 2.6.teens days).

This is where I see the value in DT. ABI stability is not something I
want/need from DT. As an ODM we have dramatically less board specific
code than ever before, and new code we need is upstreamable as DT
elements.

IMHO, this is a fine and very reasonable way to use DT in embedded.

To me, it is general purpose stuff (Chromebooks, ARM servers, etc)
where the main problem is. I think those cases need a different
solution: A subset of DT that is guarenteed ABI stable, firmware that
substantially sets up the entire machine, and the proper callback
hooks (eg through UEFI and AHCI) to let the firmware do low level
hardware specific work at runtime.

This is how x86 gets the kind of compatability it has. Trying to
describe and control every tiny detail (pin mux, regulator, clk) is
great for embedded, but fundamentally not future-proof enough for
general purpose.

Regards,
Jason


From cavokz at gmail.com  Thu Jul 25 17:41:39 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Thu, 25 Jul 2013 23:41:39 +0200
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <51F1743D.7050007@wwwdotorg.org>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy> <51F1743D.7050007@wwwdotorg.org>
Message-ID: <20130725214139.GA22296@glitch>

On Thu, Jul 25, 2013 at 11:53:49AM -0700, Stephen Warren wrote:
> On 07/25/2013 11:48 AM, Richard Cochran wrote:
> > On Thu, Jul 25, 2013 at 07:29:20PM +0100, Mark Rutland wrote:
> >> On Thu, Jul 25, 2013 at 07:05:48PM +0100, Stephen Warren wrote:
> >>>
> >>> I don't think having people "rely" on the bindings is the issue so much
> >>> as the awareness that if they do, there will be compatibility issues for
> >>> unstable bindings.
> >>
> >> As long as we can make sufficiently clear that trying to use an unstable
> >> binding is going to be *very* painful, and not necessarily supported.
> > 
> > Oh, man.
> > 
> > The introduction of DT into ARM Linux was supposed to make everyone's
> > life sooo much easier. Of course, based on experience with powerpc, I
> > never believed it*, but still I would expect to hear that the DT
> > bindings are, well, a *binding* contract between the board developer,
> > boot loader, and the kernel.
> > 
> > Once it is working with a particular kernel, a DT board description
> > file should continue to work indefinitely with newer kernels. Anything
> > less is a regression, pure and simple.
> > 
> > If you go around changing the bindings willy nilly, then what is point
> > of having DT at all?
> 
> That's exactly why we're starting to think about which bindings should
> be considered stable and immutable, and when that should happen. As Olof
> pointed out, we haven't fully enforced that yet. Preferably bindings
> will be marked stable very fast, but mistakes are always going to happen
> in early development. ABIs are very hard.

If it was possible to clearly distinguish stable and unstable bindings,
then the kernel could allow unstable bindings only from appended DTBs.

This would prevent unwanted DT ABIs while leaving plenty of room for
the developers.

2c


From linus.walleij at linaro.org  Thu Jul 25 17:46:42 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Jul 2013 23:46:42 +0200
Subject: Location for a kind of GPIO bus driver
In-Reply-To: <20130723151834.GJ9916@kw.sim.vm.gnt>
References: <20130723151834.GJ9916@kw.sim.vm.gnt>
Message-ID: <CACRpkdZWQQUCeHvgPPLmxL3O1sw55pc_KbzbnqTSFJx+0_QanQ@mail.gmail.com>

On Tue, Jul 23, 2013 at 5:18 PM, Simon Guinot <simon.guinot at sequanux.org> wrote:

> (...)  I am
> thinking about moving the GPIO extension bus support into a separate
> driver. The problem is that I can't find a proper location for a such
> driver. AFAIK, it doesn't fit with anything existing supported by Linux.
> Maybe I should consider drivers/bus ? Or even drivers/misc ?

This is a question to Greg, the device core maintainer.
AFAICT they go into drivers/base/foo-bus.c

In this case I would first consider using MFD though,
please make a case for why this is not simply a multi
function device with a few cells (== platform devices).

> Also from a DT point, it not clear to me how the resulting bus and LEDs
> driver are going to work together.

Buses are nodes in the device tree and subdevices are
subnodes.

Yours,
Linus Walleij


From ben at decadent.org.uk  Thu Jul 25 17:53:15 2013
From: ben at decadent.org.uk (Ben Hutchings)
Date: Thu, 25 Jul 2013 22:53:15 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130725203228.GX23879@titan.lakedaemon.net>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
 <20130725193135.GT23879@titan.lakedaemon.net>
 <CAL_Jsq+vWbTb8wNEDCR2c_M6sBnKW6e5HGk48QzmXSujQUdddA@mail.gmail.com>
 <20130725203228.GX23879@titan.lakedaemon.net>
Message-ID: <20130725215315.GV7729@decadent.org.uk>

On Thu, Jul 25, 2013 at 04:32:28PM -0400, Jason Cooper wrote:
[...]
> One of the things I've been trying to square up in my head is how to
> retain the history of the binding when moving to the new tree.  My
> current idea was to clone the kernel tree, add one patch deleting
> everything but the bindings and dts files, and one more patch moving
> things where we want them (arch/{powerpc,arm}/boot/dts -> dts).
> 
> Then, as needed, we could merge a kernel version tag and delete
> everything we don't need (code) in the merge commit.
> 
> The downside of this is it would be messy, the upside is that we could
> closely track the kernel tree (until the bindings and dts are moved
> out), and retain the history of the bindings and dts files.
[...]

It's *extremely* messy, but 'git filter-branch' might help to make a
clean tracking branch preserving history of just DT files.  David
Woodhouse did something like that for the linux-firmware repo
initially.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus


From cavokz at gmail.com  Thu Jul 25 17:58:03 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Thu, 25 Jul 2013 23:58:03 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <51F19A83.2090000@broadcom.com>
References: <2043662.BcW19XTTMG@lenovo> <20130723184907.GA6811@ohporter.com>
 <CAGVrzcbA72AYu6J3JXBirQQeTiDH9cJThdBdH=Q=gJtOnqz-AA@mail.gmail.com>
 <20130723192203.GC6811@ohporter.com>
 <51EF1B8C.9020304@broadcom.com>
 <CADjby3WGW6f=1Vdm2kx+Re0KrjFRaC3dQOumpnS6_sp2yb5NfQ@mail.gmail.com>
 <51F02947.7020301@hauke-m.de> <20130724225443.GA29801@glitch>
 <51F18BAA.1050806@hauke-m.de> <51F19A83.2090000@broadcom.com>
Message-ID: <20130725215803.GB22296@glitch>

On Thu, Jul 25, 2013 at 02:37:07PM -0700, Christian Daudt wrote:
> On 13-07-25 01:33 PM, Hauke Mehrtens wrote:
> >On 07/25/2013 12:54 AM, Domenico Andreoli wrote:
> >>On Wed, Jul 24, 2013 at 09:21:43PM +0200, Hauke Mehrtens wrote:
> >>>On 07/24/2013 02:44 AM, Domenico Andreoli wrote:
> >>>>On Wednesday, July 24, 2013, Hauke Mehrtens <hauke at hauke-m.de
> >>>><mailto:hauke at hauke-m.de>> wrote:
> >>>>>On 07/19/2013 03:36 AM, Domenico Andreoli wrote:
> >>>>>>On Tue, Jul 16, 2013 at 05:35:21PM +0200, Hauke Mehrtens wrote:
> >>>>>>>On 07/16/2013 05:20 PM, Thomas Petazzoni wrote:
> >>>>>>>>>diff --git a/arch/arm/mach-bcm53xx/Kconfig
> >>>>b/arch/arm/mach-bcm53xx/Kconfig
> >>>>>>>>>new file mode 100644
> >>>>>>>>>index 0000000..1e16e87
> >>>>>>>>>--- /dev/null
> >>>>>>>>>+++ b/arch/arm/mach-bcm53xx/Kconfig
> >>>>>>>>>@@ -0,0 +1,10 @@
> >>>>>>>>>+config ARCH_BCM53XX
> >>>>>>>>>+  bool "Broadcom BCM47XX / BCM53XX ARM SoC"
> >>>>>>>>So the directory is named mach-bcm53xx, but you also handle BCM47xx
> >>>>>>>>SoCs. This doesn't sound really easy to follow.
> >>>>>>At the time of the BCM281XX merge we considered that such directories
> >>>>would
> >>>>>>mostly contain board files only, being these new entries DT based. Hence
> >>>>>>the choice of mach-bcm to collect all of them.
> >>>>>>
> >>>>>>I think you should then put this stuff there.
> >>>>>So you think I should move the file from
> >>>>>arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?
> >>>>yes
> >>>>
> >>>>this looks more comsistent with the actual soc name:
> >>>>arch/arm/mach-bcm/bcm530xx.c
> >>>>
> >>>>but I find also acceptable the complete name of the "parent" soc (as I'm
> >>>>doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c
> >>>I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351)
> >>>have more in common than the vendor name, so I do not think it is a good
> >>>idea to place them all at mach-bcm.
> >>In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever
> >>two or more SoCs share can hopefully modelled in a driver and as such
> >>would go in the drivers/ subtree. What's left is really SoC specific and,
> >>again hopefully, very minimal.
> >>
> >>There should not be any SoC so weird to require a whole subdirectory full
> >>of that SoC specific stuff. So grouping everything by vendor name looks
> >>quite appealing to me.
> >>
> >>Sharing the same subdir requires people working in it to talk and find
> >>agreements some more than the sparsely populated subdir did (because there
> >>is not a single maintainer who owns it). I think this is a big advantage
> >>Broadcomers can start with right now.
> >I want to be able to build the BCM5301X SoC without building the current
> >CONFIG_ARCH_BCM, so what name do you suggest for board_bcm.o ?
> >My plan would be to make CONFIG_ARCH_BCM just activate the Broadcom
> >submenu, but not build any code. Then the list of Broadcom SoCs is
> >opened like CONFIG_ARCH_BCM5301X and the "old" CONFIG_ARCH_BCM.
> >
> >
> CONFIG_ARCH_BCM wasn't the best name, but it is there now. We intend
> to upstream the (mobile-team) ARM SoCs going forward, and have them
> be multiplatform and all buildable into a single zImage with the
> ARCH_BCM config option. Which is why this option does not have a
> chip name on it.
> Take ARCH_BCM == Broadcom Mobile team SoCs (I think that's what the
> help on it says).

This solves the double linking issue I had. No need to configure
CONFIG_ARCH_BCM if you are not interested in what it brings.

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c0ac0f5..230b5d7 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 # Machine directory name.  This list is sorted alphanumerically
 # by CONFIG_* macro name.
 machine-$(CONFIG_ARCH_AT91)            += at91
-machine-$(CONFIG_ARCH_BCM)             += bcm
+machine-y                              += bcm
 machine-$(CONFIG_ARCH_BCM2835)         += bcm2835
 machine-$(CONFIG_ARCH_CLPS711X)                += clps711x
 machine-$(CONFIG_ARCH_CNS3XXX)         += cns3xxx
 
Regards,
Domenico


From mingo at kernel.org  Thu Jul 25 18:05:02 2013
From: mingo at kernel.org (Ingo Molnar)
Date: Fri, 26 Jul 2013 00:05:02 +0200
Subject: [PATCH, re-send] Always trap on BUG()
In-Reply-To: <51EF1936.7090801@asianux.com>
References: <201307051738.35930.arnd@arndb.de>
 <20130715151612.9499c2b2ad40e88d183a4600@linux-foundation.org>
 <20130715222755.GY24642@n2100.arm.linux.org.uk>
 <51E47924.9030005@zytor.com> <20130723093628.GC19786@gmail.com>
 <51EF1936.7090801@asianux.com>
Message-ID: <20130725220502.GI18254@gmail.com>

* Chen Gang <gang.chen at asianux.com> wrote:

> On 07/23/2013 05:36 PM, Ingo Molnar wrote:
> > 
> > (the crazies can keep a separate patch to remove even more of BUG() to win 
> > a K or two.)
> > 
> 
> Excuse me, my English is not quite well, I do not quite understand your
> meaning, could you please repeat again in details or say more clearly ?

I meant: those people who'd like to have the tiny 
additional space savings offered by !CONFIG_BUG (and are 
crazy enough to live with non-determinism in exchange for a 
measly payment of 1 KB), can apply a separate, out of tree 
patch just fine and don't need upstream kernel support.

Thanks,

	Ingo


From dinguyen at altera.com  Thu Jul 25 18:04:41 2013
From: dinguyen at altera.com (dinguyen at altera.com)
Date: Thu, 25 Jul 2013 17:04:41 -0500
Subject: [PATCH] ARM: socfpga: dts: Add support for SD/MMC
Message-ID: <1374789881-20611-1-git-send-email-dinguyen@altera.com>

From: Dinh Nguyen <dinguyen at altera.com>

Add bindings for SD/MMC for SOCFPGA.
Add "syscon" to the "altr,sys-mgr" binding.

Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
Reviewed-by: Pavel Machek <pavel at denx.de>
Acked-by: Jaehoon Chung <jh80.chung at samsung.com>
Cc: Rob Herring <rob.herring at calxeda.com>
Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Cc: Ian Campbell <ian.campbell at citrix.com>
Cc: devicetree at vger.kernel.org
Cc: linux-mmc at vger.kernel.org
CC: linux-arm-kernel at lists.infradead.org

v4:
- Fixed grammar in documentation file

v3:
- Add Acked-by: Jaehoon Chung

v2:
- Fixed misspellings extentions->extensions

---
Re-send to updated device tree bindings maintainers.
---
 .../devicetree/bindings/mmc/socfpga-dw-mshc.txt    |   60 ++++++++++++++++++++
 arch/arm/boot/dts/socfpga.dtsi                     |   13 ++++-
 arch/arm/boot/dts/socfpga_cyclone5.dts             |   13 +++++
 arch/arm/boot/dts/socfpga_vt.dts                   |   12 ++++
 4 files changed, 97 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt

diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
new file mode 100644
index 0000000..420051c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
@@ -0,0 +1,60 @@
+* Altera SOCFPGA specific extensions to the Synopsis Designware Mobile
+  Storage Host Controller
+
+Required Properties:
+
+* compatible: should be
+	- "altr,socfpga-dw-mshc": for controllers with Altera SOCFPGA
+	  specific extensions.
+
+* altr,dw-mshc-ciu-div: Specifies the divider value for the card interface
+  unit (ciu) clock. The value should be (n-1). For Altera's SOCFPGA, the divider
+  value is fixed at 3, which means parent_clock/4.
+
+* altr,dw-mshc-sdr-timing: Specifies the value of CIU clock phase shift value
+  in transmit mode and CIU clock phase shift value in receive mode for single
+  data rate mode operation. Refer to notes below for the order of the cells and the
+  valid values.
+
+  Notes for the sdr-timing values:
+
+    The order of the cells should be
+      - First Cell: CIU clock phase shift value for RX mode, smplsel bits in
+	the system manager SDMMC control group.
+      - Second Cell: CIU clock phase shift value for TX mode, drvsel bits in
+	the system manager SDMMC control group.
+
+    Valid values for SDR CIU clock timing for SOCFPGA:
+      - valid value for tx phase shift and rx phase shift is 0 to 7.
+
+Required properties for a slot:
+
+* bus-width: Data width for card slot. 4-bit or 8-bit data.
+
+Example:
+
+  The MSHC controller node can be split into two portions, SoC specific and
+  board specific portions, as listed below.
+
+	dwmmc0 at ff704000 {
+		compatible = "altr,socfpga-dw-mshc";
+		reg = <0xff704000 0x1000>;
+		interrupts = <0 139 4>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+	dwmmc0 at ff704000 {
+		num-slots = <1>;
+		supports-highspeed;
+		broken-cd;
+		fifo-depth = <0x400>;
+		altr,dw-mshc-ciu-div = <3>;
+      		altr,dw-mshc-sdr-timing = <0 3>;
+
+		slot at 0 {
+			reg = <0>;
+			bus-width = <4>;
+		};
+	};
+
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index bee62a2..dbf7f22 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -468,6 +468,17 @@
 			cache-level = <2>;
 		};
 
+		mmc: dwmmc0 at ff704000 {
+			compatible = "altr,socfpga-dw-mshc";
+			reg = <0xff704000 0x1000>;
+			interrupts = <0 139 4>;
+			fifo-depth = <0x400>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			clocks = <&l4_mp_clk>, <&sdmmc_clk>;
+			clock-names = "biu", "ciu";
+		};
+
 		/* Local timer */
 		timer at fffec600 {
 			compatible = "arm,cortex-a9-twd-timer";
@@ -521,7 +532,7 @@
 			};
 
 		sysmgr at ffd08000 {
-				compatible = "altr,sys-mgr";
+				compatible = "altr,sys-mgr", "syscon";
 				reg = <0xffd08000 0x4000>;
 			};
 	};
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dts b/arch/arm/boot/dts/socfpga_cyclone5.dts
index 973999d..1853cb1 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dts
@@ -54,6 +54,19 @@
 			status = "okay";
 		};
 
+		dwmmc0 at ff704000 {
+			num-slots = <1>;
+			supports-highspeed;
+			broken-cd;
+			altr,dw-mshc-ciu-div = <3>;
+			altr,dw-mshc-sdr-timing = <0 3>;
+
+			slot at 0 {
+				reg = <0>;
+				bus-width = <4>;
+			};
+		};
+
 		timer0 at ffc08000 {
 			clock-frequency = <100000000>;
 		};
diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
index d1ec0ca..d93deb0 100644
--- a/arch/arm/boot/dts/socfpga_vt.dts
+++ b/arch/arm/boot/dts/socfpga_vt.dts
@@ -46,6 +46,18 @@
 			status = "okay";
 		};
 
+		dwmmc0 at ff704000 {
+			num-slots = <1>;
+			supports-highspeed;
+			broken-cd;
+			altr,dw-mshc-ciu-div = <3>;
+
+			slot at 0 {
+				reg = <0>;
+				bus-width = <4>;
+			};
+		};
+
 		timer0 at ffc08000 {
 			clock-frequency = <7000000>;
 		};
-- 
1.7.9.5




From gregkh at linuxfoundation.org  Thu Jul 25 18:16:15 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Thu, 25 Jul 2013 15:16:15 -0700
Subject: Location for a kind of GPIO bus driver
In-Reply-To: <CACRpkdZWQQUCeHvgPPLmxL3O1sw55pc_KbzbnqTSFJx+0_QanQ@mail.gmail.com>
References: <20130723151834.GJ9916@kw.sim.vm.gnt>
 <CACRpkdZWQQUCeHvgPPLmxL3O1sw55pc_KbzbnqTSFJx+0_QanQ@mail.gmail.com>
Message-ID: <20130725221615.GA30881@kroah.com>

On Thu, Jul 25, 2013 at 11:46:42PM +0200, Linus Walleij wrote:
> On Tue, Jul 23, 2013 at 5:18 PM, Simon Guinot <simon.guinot at sequanux.org> wrote:
> 
> > (...)  I am
> > thinking about moving the GPIO extension bus support into a separate
> > driver. The problem is that I can't find a proper location for a such
> > driver. AFAIK, it doesn't fit with anything existing supported by Linux.
> > Maybe I should consider drivers/bus ? Or even drivers/misc ?
> 
> This is a question to Greg, the device core maintainer.
> AFAICT they go into drivers/base/foo-bus.c

No, specific bus code does not go in drivers/base/ it goes where the
rest of the subsystem lives.

> In this case I would first consider using MFD though,
> please make a case for why this is not simply a multi
> function device with a few cells (== platform devices).

I agree with this as well.

thanks,

greg k-h


From rjw at rjwysocki.net  Thu Jul 25 18:29:08 2013
From: rjw at rjwysocki.net (Rafael J. Wysocki)
Date: Fri, 26 Jul 2013 00:29:08 +0200
Subject: [RESEND] cpuidle for ARM pull request
In-Reply-To: <51F1A187.5060408@linaro.org>
References: <51E536C5.1020609@linaro.org> <51F1A187.5060408@linaro.org>
Message-ID: <1766778.ZYeDKBOsjV@vostro.rjw.lan>

On Friday, July 26, 2013 12:07:03 AM Daniel Lezcano wrote:
> On 07/16/2013 02:04 PM, Daniel Lezcano wrote:
> > 
> > Hi,
> > 
> > The first PR was against the linux-pm-next tree including the patch:
> > 
> > "cpuidle: Add Kconfig.arm and move calxeda, kirkwood and zynq"
> > 
> > This patch has been dropped in the meantime.
> > 
> > Here is a new PR where my tree has been rebased against linux-pm-next
> > and adding the patch mentioned above.
> > 
> > As stated by Rafael, I will handle the ARM specific patches from now.
> > 
> > The following changes since commit 48f99d5a97d32d70c0738d6e314d9f4dbefd89bf:
> > 
> >   Merge branch 'pm-cpuidle-next' into linux-next (2013-07-16 02:41:06 +0200)
> > 
> > are available in the git repository at:
> > 
> > 
> >   git://git.linaro.org/people/dlezcano/linux.git cpuidle/arm-next
> > 
> > for you to fetch changes up to 2b7e79f4a75e803184f483985a25cc751a990f06:
> > 
> >   ARM: ux500: cpuidle: Move ux500 cpuidle driver to drivers/cpuidle
> > (2013-07-16 13:57:24 +0200)
> 
> ping ?

Sorry, something distracted me.  I'll pull it later today unless there are any
problems (in which case I'll let you know).

Thanks,
Rafael


> > ----------------------------------------------------------------
> > Daniel Lezcano (2):
> >       ARM: davinci: cpuidle: Fix target residency
> >       ARM: ux500: cpuidle: Move ux500 cpuidle driver to drivers/cpuidle
> > 
> > Linus Walleij (2):
> >       ARM: ux500: cpuidle: Instantiate the driver from platform device
> >       ARM: ux500: cpuidle: Remove pointless include
> > 
> > Sahara (1):
> >       cpuidle: Add Kconfig.arm and move calxeda, kirkwood and zynq
> > 
> >  arch/arm/mach-davinci/cpuidle.c                    |    2 +-
> >  arch/arm/mach-ux500/Makefile                       |    1 -
> >  drivers/cpuidle/Kconfig                            |   20 +++++---------
> >  drivers/cpuidle/Kconfig.arm                        |   29
> > ++++++++++++++++++++
> >  drivers/cpuidle/Makefile                           |    9 ++++--
> >  .../cpuidle.c => drivers/cpuidle/cpuidle-ux500.c   |   19 +++++++------
> >  drivers/mfd/db8500-prcmu.c                         |    4 +++
> >  7 files changed, 58 insertions(+), 26 deletions(-)
> >  create mode 100644 drivers/cpuidle/Kconfig.arm
> >  rename arch/arm/mach-ux500/cpuidle.c => drivers/cpuidle/cpuidle-ux500.c
> > (90%)
> > 
> > 
> 
> 
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From rjw at sisk.pl  Thu Jul 25 18:41:09 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Fri, 26 Jul 2013 00:41:09 +0200
Subject: [RESEND] cpuidle for ARM pull request
In-Reply-To: <1766778.ZYeDKBOsjV@vostro.rjw.lan>
References: <51E536C5.1020609@linaro.org> <51F1A187.5060408@linaro.org>
 <1766778.ZYeDKBOsjV@vostro.rjw.lan>
Message-ID: <2075555.RCmWLFAfjq@vostro.rjw.lan>

On Friday, July 26, 2013 12:29:08 AM Rafael J. Wysocki wrote:
> On Friday, July 26, 2013 12:07:03 AM Daniel Lezcano wrote:
> > On 07/16/2013 02:04 PM, Daniel Lezcano wrote:
> > > 
> > > Hi,
> > > 
> > > The first PR was against the linux-pm-next tree including the patch:
> > > 
> > > "cpuidle: Add Kconfig.arm and move calxeda, kirkwood and zynq"
> > > 
> > > This patch has been dropped in the meantime.
> > > 
> > > Here is a new PR where my tree has been rebased against linux-pm-next
> > > and adding the patch mentioned above.
> > > 
> > > As stated by Rafael, I will handle the ARM specific patches from now.
> > > 
> > > The following changes since commit 48f99d5a97d32d70c0738d6e314d9f4dbefd89bf:
> > > 
> > >   Merge branch 'pm-cpuidle-next' into linux-next (2013-07-16 02:41:06 +0200)
> > > 
> > > are available in the git repository at:
> > > 
> > > 
> > >   git://git.linaro.org/people/dlezcano/linux.git cpuidle/arm-next
> > > 
> > > for you to fetch changes up to 2b7e79f4a75e803184f483985a25cc751a990f06:
> > > 
> > >   ARM: ux500: cpuidle: Move ux500 cpuidle driver to drivers/cpuidle
> > > (2013-07-16 13:57:24 +0200)
> > 
> > ping ?
> 
> Sorry, something distracted me.  I'll pull it later today unless there are any
> problems (in which case I'll let you know).

Well, there are some.

It is based on my linux-next branch, but please rebase it on top of 3.11-rc2.

Generally, please send me pull requests based on -rc kernels only (or major
releases).

Thanks,
Rafael



From daniel.lezcano at linaro.org  Thu Jul 25 18:07:03 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 26 Jul 2013 00:07:03 +0200
Subject: [RESEND] cpuidle for ARM pull request
In-Reply-To: <51E536C5.1020609@linaro.org>
References: <51E536C5.1020609@linaro.org>
Message-ID: <51F1A187.5060408@linaro.org>

On 07/16/2013 02:04 PM, Daniel Lezcano wrote:
> 
> Hi,
> 
> The first PR was against the linux-pm-next tree including the patch:
> 
> "cpuidle: Add Kconfig.arm and move calxeda, kirkwood and zynq"
> 
> This patch has been dropped in the meantime.
> 
> Here is a new PR where my tree has been rebased against linux-pm-next
> and adding the patch mentioned above.
> 
> As stated by Rafael, I will handle the ARM specific patches from now.
> 
> The following changes since commit 48f99d5a97d32d70c0738d6e314d9f4dbefd89bf:
> 
>   Merge branch 'pm-cpuidle-next' into linux-next (2013-07-16 02:41:06 +0200)
> 
> are available in the git repository at:
> 
> 
>   git://git.linaro.org/people/dlezcano/linux.git cpuidle/arm-next
> 
> for you to fetch changes up to 2b7e79f4a75e803184f483985a25cc751a990f06:
> 
>   ARM: ux500: cpuidle: Move ux500 cpuidle driver to drivers/cpuidle
> (2013-07-16 13:57:24 +0200)

ping ?


> ----------------------------------------------------------------
> Daniel Lezcano (2):
>       ARM: davinci: cpuidle: Fix target residency
>       ARM: ux500: cpuidle: Move ux500 cpuidle driver to drivers/cpuidle
> 
> Linus Walleij (2):
>       ARM: ux500: cpuidle: Instantiate the driver from platform device
>       ARM: ux500: cpuidle: Remove pointless include
> 
> Sahara (1):
>       cpuidle: Add Kconfig.arm and move calxeda, kirkwood and zynq
> 
>  arch/arm/mach-davinci/cpuidle.c                    |    2 +-
>  arch/arm/mach-ux500/Makefile                       |    1 -
>  drivers/cpuidle/Kconfig                            |   20 +++++---------
>  drivers/cpuidle/Kconfig.arm                        |   29
> ++++++++++++++++++++
>  drivers/cpuidle/Makefile                           |    9 ++++--
>  .../cpuidle.c => drivers/cpuidle/cpuidle-ux500.c   |   19 +++++++------
>  drivers/mfd/db8500-prcmu.c                         |    4 +++
>  7 files changed, 58 insertions(+), 26 deletions(-)
>  create mode 100644 drivers/cpuidle/Kconfig.arm
>  rename arch/arm/mach-ux500/cpuidle.c => drivers/cpuidle/cpuidle-ux500.c
> (90%)
> 
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From santosh.shilimkar at ti.com  Thu Jul 25 18:33:14 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 25 Jul 2013 18:33:14 -0400
Subject: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM
In-Reply-To: <51D18DBA.6090608@ti.com>
References: <1372467663-31425-1-git-send-email-santosh.shilimkar@ti.com>
 <20130629152959.GB31339@mtj.dyndns.org>
 <20130629172123.GA3353@n2100.arm.linux.org.uk>
 <20130629175743.GA382@mtj.dyndns.org>
 <CAE9FiQXHuP-n0eZ9wN73V4nSvE+XEExDsx1t50_=YaW+V=LGLg@mail.gmail.com>
 <20130629195549.GE3353@n2100.arm.linux.org.uk>
 <CAE9FiQUoVNvWmmTV2+ZkU_nMxFToTHw6QLwp_Z_EjwMzqdLwuA@mail.gmail.com>
 <51D18DBA.6090608@ti.com>
Message-ID: <51F1A7AA.8080700@ti.com>

Tejun,

On Monday 01 July 2013 10:10 AM, Santosh Shilimkar wrote:
> On Saturday 29 June 2013 04:08 PM, Yinghai Lu wrote:
>> On Sat, Jun 29, 2013 at 12:55 PM, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>>> On Sat, Jun 29, 2013 at 12:29:55PM -0700, Yinghai Lu wrote:
>>>>>> On these SoCs which Santosh is working on, the main physical memory
>>>>>> mapping is above 4GB, with just a small alias below 4GB to allow the
>>>>>> system to boot without the MMU being on, as they may have more than
>>>>>> 4GB of RAM.  As I understand it, the small alias below 4GB is not
>>>>>> suitable for use as a "lowmem" mapping.
>>>>
>>>> is that 32bit ARM or 64bit ARM?
>>>
>>> Only 32-bit has LPAE.  Such things don't make sense on 64-bit CPUs.
>>
> Thanks Russell for clarifying the issue on the thread. Another major
> reason of not being to use 32 bit alias address space for lowmem
> is that address space isn't coherent on the SOC am dealing with.
> 
>> 32bit ARM does not support NO_BOOTMEM yet.
>>
>> arch/arc/Kconfig:       select NO_BOOTMEM
>> arch/arm64/Kconfig:     select NO_BOOTMEM
>> arch/sparc/Kconfig:     select NO_BOOTMEM
>> arch/x86/Kconfig:config NO_BOOTMEM
>>
>>
>> so may need to
>> 1. make 32bit ARM to use NO_BOOTMEM at first.
>>
> Sorry. I should have mentioned that in the change-log. 
> I have been carrying some WIP patches for ARM. Will post them
> on ARM list after finishing remainder of the testing.
> 
>> 2 .we can add alloc_memblock as MACRO or inline for bootmem arches,
>>
>> 3. NO_BOOTMEM arches will have alloc_memblock in nobootmem.c
>>
>> 4. replace alloc_bootmem calling with alloc_memblock calling in core code.
>>
> Great that we all agree to see back of nobootmem.c and have a direct
> memblock API. Will be happy to help in conversion to proposed new interfaces
> if I can get the alloc_memblock API and core related changes.
> 
> Will be good to know who is going to create proposed memblock API
> so that we all can collaborate in conversion.
> 
Any comments here. I would like to know your plan for the new
API. You might have seen on the ARM no-bootmem thread, we started to
move ARM to nobootmem with Russell's help.

Regards,
Santosh



From tj at kernel.org  Thu Jul 25 18:36:58 2013
From: tj at kernel.org (Tejun Heo)
Date: Thu, 25 Jul 2013 18:36:58 -0400
Subject: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM
In-Reply-To: <51F1A7AA.8080700@ti.com>
References: <1372467663-31425-1-git-send-email-santosh.shilimkar@ti.com>
 <20130629152959.GB31339@mtj.dyndns.org>
 <20130629172123.GA3353@n2100.arm.linux.org.uk>
 <20130629175743.GA382@mtj.dyndns.org>
 <CAE9FiQXHuP-n0eZ9wN73V4nSvE+XEExDsx1t50_=YaW+V=LGLg@mail.gmail.com>
 <20130629195549.GE3353@n2100.arm.linux.org.uk>
 <CAE9FiQUoVNvWmmTV2+ZkU_nMxFToTHw6QLwp_Z_EjwMzqdLwuA@mail.gmail.com>
 <51D18DBA.6090608@ti.com> <51F1A7AA.8080700@ti.com>
Message-ID: <20130725223658.GJ26107@mtj.dyndns.org>

Hello,

On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote:
> Any comments here. I would like to know your plan for the new
> API. You might have seen on the ARM no-bootmem thread, we started to
> move ARM to nobootmem with Russell's help.

Ooh, the plan sounds good to me and I was thinking you were gonna do
it?

Thanks.

-- 
tejun


From hauke at hauke-m.de  Thu Jul 25 18:42:14 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Fri, 26 Jul 2013 00:42:14 +0200
Subject: [PATCH v3 2/3] ARM: BCM5301X: add early debugging support
In-Reply-To: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
References: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
Message-ID: <1374792135-30343-3-git-send-email-hauke@hauke-m.de>

This adds support for early debugging of BCM5301X SoC.

Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
---
 arch/arm/Kconfig.debug            |    5 +++++
 arch/arm/include/debug/bcm5301x.S |   19 +++++++++++++++++++
 2 files changed, 24 insertions(+)
 create mode 100644 arch/arm/include/debug/bcm5301x.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e401a76..3a3c8fc 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -93,6 +93,10 @@ choice
 		bool "Kernel low-level debugging on BCM2835 PL011 UART"
 		depends on ARCH_BCM2835
 
+	config DEBUG_BCM5301X
+		bool "Kernel low-level debugging on BCM5301X UART1"
+		depends on ARCH_BCM5301X
+
 	config DEBUG_CLPS711X_UART1
 		bool "Kernel low-level debugging messages via UART1"
 		depends on ARCH_CLPS711X
@@ -762,6 +766,7 @@ endchoice
 config DEBUG_LL_INCLUDE
 	string
 	default "debug/bcm2835.S" if DEBUG_BCM2835
+	default "debug/bcm5301x.S" if DEBUG_BCM5301X
 	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
 	default "debug/exynos.S" if DEBUG_EXYNOS_UART
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
diff --git a/arch/arm/include/debug/bcm5301x.S b/arch/arm/include/debug/bcm5301x.S
new file mode 100644
index 0000000..be16945
--- /dev/null
+++ b/arch/arm/include/debug/bcm5301x.S
@@ -0,0 +1,19 @@
+/*
+ * Macros used for EARLY_PRINTK, in low-level UART debug console
+ *
+ * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#define BCM5301X_UART1_PHYS	0x18000300
+#define BCM5301X_UART1_VIRT	0xf1000300
+#define BCM5301X_UART1_SH	0
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =BCM5301X_UART1_PHYS 	@ MMU off, Physical
+	ldr	\rv, =BCM5301X_UART1_VIRT 	@ MMU on, Virtual
+	.endm
+
+#define UART_SHIFT	BCM5301X_UART1_SH
+#include <asm/hardware/debug-8250.S>
-- 
1.7.10.4



From hauke at hauke-m.de  Thu Jul 25 18:42:12 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Fri, 26 Jul 2013 00:42:12 +0200
Subject: [PATCH v3 0/3] ARM: BCM5301X: initial support for the
 BCM5301X/BCM470X SoCs with ARM CPU
Message-ID: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>

This adds initial support for Broadcom network SoC from the BCM5301X 
and BCM470X line.

The debug patch should be changed or later applied to conform with the 
new style.

If the vendor prefix should be changes to something else, I will change 
it to whatever name.

The vendor BSP also uses BCM5301X for this SoC, so I just toke that.

A bootlog can be found here:
http://pastebin.com/2FeBGCY5

Changes since v2:
 * use vendor prefix brcm
 * move code to arch/arm/mach-bcm/
 * cleanup arch/arm/mach-bcm/bcm5301x.c
 * rename to bcm5301x
 * split into more patches

Changes since v1:
 * add file Documentation/devicetree/bindings/arm/bcm4708.txt
 * rename bcm5301x to bcm4708 in dts files
 * use preprocessor includes in dts file
 * add CONFIG_ARCH_BCM53XX to multi_v7_defconfig
 * remove init_machine callback
 * rename vendor prefix from brcm to bcm
 * split into two patches


Hauke Mehrtens (3):
  ARM: BCM5301X: initial support for the BCM5301X/BCM470X SoCs with ARM
    CPU
  ARM: BCM5301X: add early debugging support
  ARM: BCM5301X: add dts files for BCM4708 SoC

 Documentation/devicetree/bindings/arm/bcm4708.txt |    8 +++
 MAINTAINERS                                       |    8 +++
 arch/arm/Kconfig.debug                            |    5 ++
 arch/arm/Makefile                                 |    2 +-
 arch/arm/boot/dts/Makefile                        |    1 +
 arch/arm/boot/dts/bcm4708-netgear-r6250.dts       |   20 ++++++
 arch/arm/boot/dts/bcm4708.dtsi                    |   74 +++++++++++++++++++++
 arch/arm/configs/multi_v7_defconfig               |    1 +
 arch/arm/include/debug/bcm5301x.S                 |   19 ++++++
 arch/arm/mach-bcm/Kconfig                         |   21 ++++++
 arch/arm/mach-bcm/Makefile                        |    1 +
 arch/arm/mach-bcm/bcm5301x.c                      |   59 ++++++++++++++++
 12 files changed, 218 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm4708.txt
 create mode 100644 arch/arm/boot/dts/bcm4708-netgear-r6250.dts
 create mode 100644 arch/arm/boot/dts/bcm4708.dtsi
 create mode 100644 arch/arm/include/debug/bcm5301x.S
 create mode 100644 arch/arm/mach-bcm/bcm5301x.c

-- 
1.7.10.4



From hauke at hauke-m.de  Thu Jul 25 18:42:13 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Fri, 26 Jul 2013 00:42:13 +0200
Subject: [PATCH v3 1/3] ARM: BCM5301X: initial support for the
 BCM5301X/BCM470X SoCs with ARM CPU
In-Reply-To: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
References: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
Message-ID: <1374792135-30343-2-git-send-email-hauke@hauke-m.de>

This patch adds support for the BCM5301X/BCM470X SoCs with an ARM CPUs.
Currently just booting to a shell is working and nothing else, no
Ethernet, wifi, flash, ...

This SoC is used in small office and home router with Broadcom SoCs.
This code should support the BCM4707, BCM4708, BCM4709, BCM53010,
BCM53011 and BCM53012 SoC. It uses one or two ARM Cortex A9
Cores, some highlights are 2 PCIe 2.0 controllers, 4 Gigabit Ethernet
MACs and a USB 3.0 host controller.

This SoC uses a dual core CPU, but this is currently not implemented.
More information about this SoC can be found here:
http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers

Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
---
 Documentation/devicetree/bindings/arm/bcm4708.txt |    8 +++
 MAINTAINERS                                       |    8 +++
 arch/arm/Makefile                                 |    2 +-
 arch/arm/configs/multi_v7_defconfig               |    1 +
 arch/arm/mach-bcm/Kconfig                         |   21 ++++++++
 arch/arm/mach-bcm/Makefile                        |    1 +
 arch/arm/mach-bcm/bcm5301x.c                      |   59 +++++++++++++++++++++
 7 files changed, 99 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm4708.txt
 create mode 100644 arch/arm/mach-bcm/bcm5301x.c

diff --git a/Documentation/devicetree/bindings/arm/bcm4708.txt b/Documentation/devicetree/bindings/arm/bcm4708.txt
new file mode 100644
index 0000000..6b0f49f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm4708.txt
@@ -0,0 +1,8 @@
+Broadcom BCM4708 device tree bindings
+-------------------------------------------
+
+Boards with the BCM4708 SoC shall have the following properties:
+
+Required root node property:
+
+compatible = "brcm,bcm4708";
diff --git a/MAINTAINERS b/MAINTAINERS
index bf61e04..b38f141 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1795,6 +1795,14 @@ F:	arch/arm/boot/dts/bcm2835*
 F:	arch/arm/configs/bcm2835_defconfig
 F:	drivers/*/*bcm2835*
 
+BROADCOM BCM5301X ARM ARCHICTURE
+M:	Hauke Mehrtens <hauke at hauke-m.de>
+L:	linux-arm-kernel at lists.infradead.org
+S:	Maintained
+F:	arch/arm/mach-bcm/bcm5301x.c
+F:	arch/arm/boot/dts/bcm5301*
+F:	arch/arm/boot/dts/bcm470*
+
 BROADCOM TG3 GIGABIT ETHERNET DRIVER
 M:	Nithin Nayak Sujir <nsujir at broadcom.com>
 M:	Michael Chan <mchan at broadcom.com>
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c0ac0f5..230b5d7 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 # Machine directory name.  This list is sorted alphanumerically
 # by CONFIG_* macro name.
 machine-$(CONFIG_ARCH_AT91)		+= at91
-machine-$(CONFIG_ARCH_BCM)		+= bcm
+machine-y				+= bcm
 machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
 machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
 machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index fe0bdc3..f449bd7 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -6,6 +6,7 @@ CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_XP=y
 CONFIG_ARCH_BCM=y
+CONFIG_ARCH_BCM5301X=y
 CONFIG_GPIO_PCA953X=y
 CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_KEYSTONE=y
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index f112895..979433b 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -17,3 +17,24 @@ config ARCH_BCM
 	  It currently supports the 'BCM281XX' family, which includes
 	  BCM11130, BCM11140, BCM11351, BCM28145 and
 	  BCM28155 variants.
+
+config ARCH_BCM5301X
+	bool "Broadcom BCM470X / BCM5301X ARM SoC"
+	select CPU_V7
+	select ARM_GIC
+	select HAVE_CLK
+	select GENERIC_CLOCKEVENTS
+	select GENERIC_TIME
+	select ARM_GLOBAL_TIMER
+	help
+	  Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores.
+
+	  This is a network SoC line mostly used in home routers and
+	  wifi access points.
+	  This inclused the following SoC: BCM53010, BCM53011, BCM53012,
+	  BCM53014, BCM53015, BCM53016, BCM53017, BCM53018, BCM4707,
+	  BCM4708 and BCM4709.
+
+	  Do not confuse this with the BCM4760 which is a totally
+	  different SoC or with the older BCM47XX and BCM53XX based
+	  network SoC using a MIPS CPU, they are supported by arch/mips/bcm47xx
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 6adb6aec..b5b8046 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -13,3 +13,4 @@
 obj-$(CONFIG_ARCH_BCM)		:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_bcm_kona_smc_asm.o	:=-Wa,-march=armv7-a$(plus_sec)
+obj-$(CONFIG_ARCH_BCM5301X)	+= bcm5301x.o
diff --git a/arch/arm/mach-bcm/bcm5301x.c b/arch/arm/mach-bcm/bcm5301x.c
new file mode 100644
index 0000000..5168f94
--- /dev/null
+++ b/arch/arm/mach-bcm/bcm5301x.c
@@ -0,0 +1,59 @@
+/*
+ * Broadcom BCM470X / BCM5301X ARM platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/irqchip.h>
+#include <linux/clocksource.h>
+#include <linux/clk-provider.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/signal.h>
+
+static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason, possibly left over from CFE
+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+
+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void __init bcm5301x_init_early(void)
+{
+	/* Install our hook */
+	hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, 0,
+			"imprecise external abort");
+}
+
+static void __init bcm5301x_map_io(void)
+{
+	debug_ll_io_init();
+}
+
+static void __init bcm5301x_timer_init(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+static const char const *bcm5301x_dt_compat[] = {
+	"brcm,bcm4708",
+	NULL,
+};
+
+DT_MACHINE_START(BCM5301X, "BCM5301X")
+	.init_early = bcm5301x_init_early,
+	.map_io = bcm5301x_map_io,
+	.init_time = bcm5301x_timer_init,
+	.dt_compat = bcm5301x_dt_compat,
+MACHINE_END
-- 
1.7.10.4



From hauke at hauke-m.de  Thu Jul 25 18:42:15 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Fri, 26 Jul 2013 00:42:15 +0200
Subject: [PATCH v3 3/3] ARM: BCM5301X: add dts files for BCM4708 SoC
In-Reply-To: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
References: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
Message-ID: <1374792135-30343-4-git-send-email-hauke@hauke-m.de>

This uses the newly added BCM5301X SoC code.

Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
---
 arch/arm/boot/dts/Makefile                  |    1 +
 arch/arm/boot/dts/bcm4708-netgear-r6250.dts |   20 ++++++++
 arch/arm/boot/dts/bcm4708.dtsi              |   74 +++++++++++++++++++++++++++
 3 files changed, 95 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm4708-netgear-r6250.dts
 create mode 100644 arch/arm/boot/dts/bcm4708.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..6329f2d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -43,6 +43,7 @@ dtb-$(CONFIG_ARCH_AT91)	+= sama5d35ek.dtb
 
 dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
 dtb-$(CONFIG_ARCH_BCM) += bcm11351-brt.dtb
+dtb-$(CONFIG_ARCH_BCM5301X) += bcm4708-netgear-r6250.dtb
 dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
 	da850-evm.dtb
 dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
new file mode 100644
index 0000000..34875f6
--- /dev/null
+++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
@@ -0,0 +1,20 @@
+/*
+ * Broadcom BCM470X / BCM5301X arm platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+/dts-v1/;
+
+#include "bcm4708.dtsi"
+
+/ {
+	compatible = "netgear,r6250v1", "brcm,bcm4708";
+	model = "Netgear R6250 V1 (BCM4708)";
+
+	memory {
+		reg = <0x00000000 0x08000000>;
+	};
+};
diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
new file mode 100644
index 0000000..fbf1dcf
--- /dev/null
+++ b/arch/arm/boot/dts/bcm4708.dtsi
@@ -0,0 +1,74 @@
+/*
+ * Broadcom BCM470X / BCM5301X ARM platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+#include "skeleton.dtsi"
+
+/ {
+	compatible = "brcm,bcm4708";
+	model = "Broadcom BCM4708";
+	interrupt-parent = <&gic>;
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk debug";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+		};
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk_periph: periph {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <400000000>;
+		};
+	};
+
+	uart at 18000300 {
+		compatible = "ns16550";
+		reg = <0x18000300 0x100>;
+		interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+		clock-frequency = <100000000>;
+	};
+
+	uart at 18000400 {
+		compatible = "ns16550";
+		reg = <0x18000400 0x100>;
+		interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+		clock-frequency = <100000000>;
+	};
+
+	gic: interrupt-controller at 19021000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x19021000 0x1000>,
+		      <0x19020100 0x100>;
+	};
+
+	timer at 19020200 {
+		compatible = "arm,cortex-a9-global-timer";
+		reg = <0x19020200 0x100>;
+		interrupts = <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&clk_periph>;
+	};
+};
-- 
1.7.10.4



From santosh.shilimkar at ti.com  Thu Jul 25 19:15:11 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Thu, 25 Jul 2013 19:15:11 -0400
Subject: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM
In-Reply-To: <20130725223658.GJ26107@mtj.dyndns.org>
References: <1372467663-31425-1-git-send-email-santosh.shilimkar@ti.com>
 <20130629152959.GB31339@mtj.dyndns.org>
 <20130629172123.GA3353@n2100.arm.linux.org.uk>
 <20130629175743.GA382@mtj.dyndns.org>
 <CAE9FiQXHuP-n0eZ9wN73V4nSvE+XEExDsx1t50_=YaW+V=LGLg@mail.gmail.com>
 <20130629195549.GE3353@n2100.arm.linux.org.uk>
 <CAE9FiQUoVNvWmmTV2+ZkU_nMxFToTHw6QLwp_Z_EjwMzqdLwuA@mail.gmail.com>
 <51D18DBA.6090608@ti.com> <51F1A7AA.8080700@ti.com>
 <20130725223658.GJ26107@mtj.dyndns.org>
Message-ID: <51F1B17F.30902@ti.com>

On Thursday 25 July 2013 06:36 PM, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 25, 2013 at 06:33:14PM -0400, Santosh Shilimkar wrote:
>> Any comments here. I would like to know your plan for the new
>> API. You might have seen on the ARM no-bootmem thread, we started to
>> move ARM to nobootmem with Russell's help.
> 
> Ooh, the plan sounds good to me and I was thinking you were gonna do
> it?
> 
Wooo..

Sorry if I wasn't clear before, but I need help to at least have new
memblock API support since I am not familiar with memblock code. 
I could help in adaptation to the new API for ARM arch and
core kernel code.

Let me know your thoughts.

Regards,
Santosh





From jg1.han at samsung.com  Thu Jul 25 19:17:58 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Fri, 26 Jul 2013 08:17:58 +0900
Subject: [PATCH] mfd: max8925: fix dt code for backlight
In-Reply-To: <CAOesGMh5-aRR+eZVimNnZJ++f74tbURWOeri-46GNQfK_r3JuA@mail.gmail.com>
References: <1374680547-5336-1-git-send-email-olof@lixom.net>
 <000401ce88d4$33773de0$9a65b9a0$@samsung.com>
 <CAOesGMh5-aRR+eZVimNnZJ++f74tbURWOeri-46GNQfK_r3JuA@mail.gmail.com>
Message-ID: <000f01ce898d$333a5ce0$99af16a0$@samsung.com>

On Friday, July 26, 2013 6:01 AM, Olof Johansson wrote:
> On Wed, Jul 24, 2013 at 6:13 PM, Jingoo Han <jg1.han at samsung.com> wrote:
> > On Thursday, July 25, 2013 12:42 AM, Olof Johansson wrote:
> >>
> >> The device-tree enablement for max8925 has several problems, but besides
> >> the bindings being wrong (and not having seen review) there's also some
> >> bad coding practices on how to fill in the platform_data from device tree.
> >>
> >> I came across this since it causes a warning when compiling
> >> mmp2_defconfig, and instead of doing the minimal fix to silence the
> >> warning, I restructured the code a bit.
> >>
> >> This silences the warning:
> >> drivers/video/backlight/max8925_bl.c: In function 'max8925_backlight_probe':
> >> drivers/video/backlight/max8925_bl.c:177:3: warning: statement with no effect [-Wunused-value]
> >>
> >> Note that the bindings themselves need to be revisited too, but that will
> >> affect more than just the backlight driver and is best done separately;
> >> this just fixes the bad code for the backlight driver.
> >>
> >> Signed-off-by: Olof Johansson <olof at lixom.net>
> >> ---
> >>
> >> Richard, Jingoo, this would be good to see go into 3.11 if you're
> >> comfortable with it.
> >
> > CC'ed Andrew Morton
> >
> >
> > Hi Olof Johansson,
> >
> > Currently, there is not git tree for Backlight subsystem.
> > I hope that this would go into 3.11 through one of other trees
> > with my Ack.
> >
> > If not, it will go into 3.12-rc1 through mm-tree.
> >
> > Acked-by: Jingoo Han <jg1.han at samsung.com>
> 
> Ok, if you don't mind I can take it through arm-soc for 3.11 with your ack then. 

Hi Olof Johansson,

Sure, no problem.
If you take it through arm-soc for 3.11 with my ACK, it will be good.
Thank you for caring this. :)

Best regards,
Jingoo Han




From linux at arm.linux.org.uk  Thu Jul 25 19:18:48 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 00:18:48 +0100
Subject: DT bindings as ABI [was: Do we have people interested in
 device tree janitoring / cleanup?]
In-Reply-To: <20130725193135.GT23879@titan.lakedaemon.net>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
 <20130725193135.GT23879@titan.lakedaemon.net>
Message-ID: <20130725231848.GJ24642@n2100.arm.linux.org.uk>

On Thu, Jul 25, 2013 at 03:31:35PM -0400, Jason Cooper wrote:
> On Thu, Jul 25, 2013 at 02:11:31PM -0500, Rob Herring wrote:
> > On Thu, Jul 25, 2013 at 11:09 AM, Olof Johansson <olof at lixom.net> wrote:
> 
> > > One problem that needs to be solved is obviously how a binding
> > > graduates from tentative to locked. This work isn't going to be very
> > > interesting to most people, I suspect. Think standards committee type
> > > work.
> > 
> > I think a time based stabilization period would be better than a
> > separate directory to apply bindings too. Or time plus periodic review
> > perhaps.
> 
> The only problem with a time-based versus separate directory is how do
> users who've downloaded the tree determine which bindings are stable?
> If they pull a tarball, or receive an SDK, there is most likely no git
> history attached.
> 
> I think the idea of a 'tentative' directory (or 'locked') is churnish,
> but necessary.  If I DL'd a tarball and had to type 'tentative' to get
> to the binding doc I wanted, that would be a pretty clear clue to be
> delicate about how I trust/use/plan with that binding.

It's actually extremely simple.  If the bindings are in development,
they must not appear in a -final released kernel.  Anything that appears
in a -final kernel becomes part of the ABI at that point.

That obviously does not mean you remove them in the last -rc and put
them back during the merge window!

That's how we handle every other ABI thing in the kernel tree, why should
DT files be any different?  (I've added Linus and Grant to this discussion.)

As I've already stated, it is intended to eventually remove the DT files
from the kernel tree and have them as a separately maintained project,
which means they will be independent of the kernel version.


From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 25 19:26:36 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 01:26:36 +0200
Subject: [PATCH 00/12] Remove platform callbacks from mmc_spi,
 sh_mmcif and sh_mobile_sdhi drivers
Message-ID: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Hello,

This patch set replaces callbacks to board code with regulators and GPIOs in
the mmc_spi, sh_mmcif and sh_mobile_sdhi MMC drivers.

Most of the required infrastructure is in place already on the drivers side,
except for CD/RO GPIOs support in the mmc_spi driver. The series thus starts
with patch 01/12 that adds this feature to the mmc_spi driver.

Patches 02/12 to 05/12 remove the board callbacks from the ecovec24 and
vision_ep9307 boards. The code has been compile-tested only as I don't have
access to those boards.

Patches 06/12 to 07/12 then proceed to remove the callbacks from the drivers
themselves and from the platform data structures.

This will be a bit messy to merge, as the series interleaves patches for
drivers and board files. Given that the mmc_spi driver is marked as orphan in
MAINTAINERS and that the vision_ep9307 hasn't seen any board-specific
modification in the last couple of kernel versions one option would be to
merge all patches (or at least patches 01/12 to 06/12) through Simon's tree if
all involved maintainers agree.

The series is based on tag renesas-devel-20130725 from
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git

Laurent Pinchart (12):
  mmc: mmc_spi: Support CD/RO GPIOs
  ARM: ep93xx: vision_ep9307: Use MMC CD and RO GPIO
  sh: ecovec24: Use MMC/SDHI CD and RO GPIO
  sh: ecovec24: Remove mmcif .down_pwr() callback
  sh: ecovec24: Remove MMCIF and SDHI .set_pwr() callbacks
  mmc: mmc_spi: Remove platform data .get_cd() and .get_ro() callbacks
  mmc: sh_mmcif: Remove .down_pwr() callback from platform data
  mmc: sh_mmcif: Remove .set_pwr() callback from platform data
  mmc: sh_mobile_sdhi: Remove .get_cd() callback from platform data
  mmc: sh_mobile_sdhi: Remove .set_pwr() callback from platform data
  mmc: tmio-mmc: Remove .get_cd() callback from platform data
  mmc: tmio-mmc: Remove .set_pwr() callback from platform data

 arch/arm/mach-ep93xx/vision_ep9307.c | 56 ++---------------------
 arch/sh/boards/mach-ecovec24/setup.c | 89 ++++--------------------------------
 drivers/mmc/host/mmc_spi.c           | 48 +++++++++----------
 drivers/mmc/host/of_mmc_spi.c        | 46 +++++--------------
 drivers/mmc/host/sh_mmcif.c          |  3 --
 drivers/mmc/host/sh_mobile_sdhi.c    | 18 --------
 drivers/mmc/host/tmio_mmc.h          |  1 -
 drivers/mmc/host/tmio_mmc_pio.c      | 23 +---------
 include/linux/mfd/tmio.h             |  2 -
 include/linux/mmc/sh_mmcif.h         |  2 -
 include/linux/mmc/sh_mobile_sdhi.h   |  2 -
 include/linux/spi/mmc_spi.h          | 18 ++++----
 12 files changed, 56 insertions(+), 252 deletions(-)

-- 
Regards,

Laurent Pinchart



From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 25 19:26:37 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 01:26:37 +0200
Subject: [PATCH 01/12] mmc: mmc_spi: Support CD/RO GPIOs
In-Reply-To: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374794808-21890-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Add support for passing CD/RO GPIO numbers directly to the mmc_spi
driver instead of relying solely on board code callbacks to retrieve the
CD/RO signals values.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/mmc/host/mmc_spi.c    | 32 +++++++++++++++++++++---------
 drivers/mmc/host/of_mmc_spi.c | 46 +++++++++++--------------------------------
 include/linux/spi/mmc_spi.h   | 11 +++++++++++
 3 files changed, 46 insertions(+), 43 deletions(-)

diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index 74145d1..4e83908 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -36,6 +36,7 @@
 
 #include <linux/mmc/host.h>
 #include <linux/mmc/mmc.h>		/* for R1_SPI_* bit values */
+#include <linux/mmc/slot-gpio.h>
 
 #include <linux/spi/spi.h>
 #include <linux/spi/mmc_spi.h>
@@ -1278,11 +1279,8 @@ static int mmc_spi_get_ro(struct mmc_host *mmc)
 
 	if (host->pdata && host->pdata->get_ro)
 		return !!host->pdata->get_ro(mmc->parent);
-	/*
-	 * Board doesn't support read only detection; let the mmc core
-	 * decide what to do.
-	 */
-	return -ENOSYS;
+	else
+		return mmc_gpio_get_ro(mmc);
 }
 
 static int mmc_spi_get_cd(struct mmc_host *mmc)
@@ -1291,7 +1289,8 @@ static int mmc_spi_get_cd(struct mmc_host *mmc)
 
 	if (host->pdata && host->pdata->get_cd)
 		return !!host->pdata->get_cd(mmc->parent);
-	return -ENOSYS;
+	else
+		return mmc_gpio_get_cd(mmc);
 }
 
 static const struct mmc_host_ops mmc_spi_ops = {
@@ -1324,6 +1323,7 @@ static int mmc_spi_probe(struct spi_device *spi)
 	struct mmc_host		*mmc;
 	struct mmc_spi_host	*host;
 	int			status;
+	bool			has_ro = false;
 
 	/* We rely on full duplex transfers, mostly to reduce
 	 * per-transfer overheads (by making fewer transfers).
@@ -1448,18 +1448,32 @@ static int mmc_spi_probe(struct spi_device *spi)
 	}
 
 	/* pass platform capabilities, if any */
-	if (host->pdata)
+	if (host->pdata) {
 		mmc->caps |= host->pdata->caps;
+		mmc->caps2 |= host->pdata->caps2;
+	}
 
 	status = mmc_add_host(mmc);
 	if (status != 0)
 		goto fail_add_host;
 
+	if (host->pdata && host->pdata->flags & MMC_SPI_USE_CD_GPIO) {
+		status = mmc_gpio_request_cd(mmc, host->pdata->cd_gpio);
+		if (status != 0)
+			goto fail_add_host;
+	}
+
+	if (host->pdata && host->pdata->flags & MMC_SPI_USE_RO_GPIO) {
+		has_ro = true;
+		status = mmc_gpio_request_ro(mmc, host->pdata->ro_gpio);
+		if (status != 0)
+			goto fail_add_host;
+	}
+
 	dev_info(&spi->dev, "SD/MMC host %s%s%s%s%s\n",
 			dev_name(&mmc->class_dev),
 			host->dma_dev ? "" : ", no DMA",
-			(host->pdata && host->pdata->get_ro)
-				? "" : ", no WP",
+			has_ro ? "" : ", no WP",
 			(host->pdata && host->pdata->setpower)
 				? "" : ", no poweroff",
 			(mmc->caps & MMC_CAP_NEEDS_POLL)
diff --git a/drivers/mmc/host/of_mmc_spi.c b/drivers/mmc/host/of_mmc_spi.c
index d720b5e..6e218fb 100644
--- a/drivers/mmc/host/of_mmc_spi.c
+++ b/drivers/mmc/host/of_mmc_spi.c
@@ -50,25 +50,6 @@ static struct of_mmc_spi *to_of_mmc_spi(struct device *dev)
 	return container_of(dev->platform_data, struct of_mmc_spi, pdata);
 }
 
-static int of_mmc_spi_read_gpio(struct device *dev, int gpio_num)
-{
-	struct of_mmc_spi *oms = to_of_mmc_spi(dev);
-	bool active_low = oms->alow_gpios[gpio_num];
-	bool value = gpio_get_value(oms->gpios[gpio_num]);
-
-	return active_low ^ value;
-}
-
-static int of_mmc_spi_get_cd(struct device *dev)
-{
-	return of_mmc_spi_read_gpio(dev, CD_GPIO);
-}
-
-static int of_mmc_spi_get_ro(struct device *dev)
-{
-	return of_mmc_spi_read_gpio(dev, WP_GPIO);
-}
-
 static int of_mmc_spi_init(struct device *dev,
 			   irqreturn_t (*irqhandler)(int, void *), void *mmc)
 {
@@ -130,20 +111,22 @@ struct mmc_spi_platform_data *mmc_spi_get_pdata(struct spi_device *spi)
 		if (!gpio_is_valid(oms->gpios[i]))
 			continue;
 
-		ret = gpio_request(oms->gpios[i], dev_name(dev));
-		if (ret < 0) {
-			oms->gpios[i] = -EINVAL;
-			continue;
-		}
-
 		if (gpio_flags & OF_GPIO_ACTIVE_LOW)
 			oms->alow_gpios[i] = true;
 	}
 
-	if (gpio_is_valid(oms->gpios[CD_GPIO]))
-		oms->pdata.get_cd = of_mmc_spi_get_cd;
-	if (gpio_is_valid(oms->gpios[WP_GPIO]))
-		oms->pdata.get_ro = of_mmc_spi_get_ro;
+	if (gpio_is_valid(oms->gpios[CD_GPIO])) {
+		oms->pdata.cd_gpio = oms->gpios[CD_GPIO];
+		oms->pdata.flags |= MMC_SPI_USE_CD_GPIO;
+		if (!oms->alow_gpios[CD_GPIO])
+			oms->pdata.caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
+	}
+	if (gpio_is_valid(oms->gpios[WP_GPIO])) {
+		oms->pdata.ro_gpio = oms->gpios[WP_GPIO];
+		oms->pdata.flags |= MMC_SPI_USE_RO_GPIO;
+		if (!oms->alow_gpios[WP_GPIO])
+			oms->pdata.caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
+	}
 
 	oms->detect_irq = irq_of_parse_and_map(np, 0);
 	if (oms->detect_irq != 0) {
@@ -166,15 +149,10 @@ void mmc_spi_put_pdata(struct spi_device *spi)
 	struct device *dev = &spi->dev;
 	struct device_node *np = dev->of_node;
 	struct of_mmc_spi *oms = to_of_mmc_spi(dev);
-	int i;
 
 	if (!dev->platform_data || !np)
 		return;
 
-	for (i = 0; i < ARRAY_SIZE(oms->gpios); i++) {
-		if (gpio_is_valid(oms->gpios[i]))
-			gpio_free(oms->gpios[i]);
-	}
 	kfree(oms);
 	dev->platform_data = NULL;
 }
diff --git a/include/linux/spi/mmc_spi.h b/include/linux/spi/mmc_spi.h
index 32be8db..a54da4a 100644
--- a/include/linux/spi/mmc_spi.h
+++ b/include/linux/spi/mmc_spi.h
@@ -7,6 +7,11 @@
 struct device;
 struct mmc_host;
 
+#define MMC_SPI_USE_CD_GPIO			(1 << 0)
+#define MMC_SPI_USE_RO_GPIO			(1 << 1)
+#define MMC_SPI_CD_GPIO_ACTIVE_LOW		(1 << 2)
+#define MMC_SPI_RO_GPIO_ACTIVE_LOW		(1 << 3)
+
 /* Put this in platform_data of a device being used to manage an MMC/SD
  * card slot.  (Modeled after PXA mmc glue; see that for usage examples.)
  *
@@ -30,8 +35,14 @@ struct mmc_spi_platform_data {
 	 */
 	int (*get_cd)(struct device *);
 
+	/* Card Detect and Read Only GPIOs */
+	unsigned int flags;
+	unsigned int cd_gpio;
+	unsigned int ro_gpio;
+
 	/* Capabilities to pass into mmc core (e.g. MMC_CAP_NEEDS_POLL). */
 	unsigned long caps;
+	unsigned long caps2;
 
 	/* how long to debounce card detect, in msecs */
 	u16 detect_delay;
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 25 19:26:38 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 01:26:38 +0200
Subject: [PATCH 02/12] ARM: ep93xx: vision_ep9307: Use MMC CD and RO GPIO
In-Reply-To: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374794808-21890-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Pass the CD and RO GPIO numbers to the MMC SPI driver and remove the
custom .get_cd() and .get_ro() callback functions.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 arch/arm/mach-ep93xx/vision_ep9307.c | 56 +++---------------------------------
 1 file changed, 4 insertions(+), 52 deletions(-)

diff --git a/arch/arm/mach-ep93xx/vision_ep9307.c b/arch/arm/mach-ep93xx/vision_ep9307.c
index 605956f..ab94dc5 100644
--- a/arch/arm/mach-ep93xx/vision_ep9307.c
+++ b/arch/arm/mach-ep93xx/vision_ep9307.c
@@ -224,62 +224,14 @@ static struct ep93xx_spi_chip_ops vision_spi_flash_hw = {
 #define VISION_SPI_MMC_WP	EP93XX_GPIO_LINE_F(0)
 #define VISION_SPI_MMC_CD	EP93XX_GPIO_LINE_EGPIO15
 
-static struct gpio vision_spi_mmc_gpios[] = {
-	{ VISION_SPI_MMC_WP, GPIOF_DIR_IN, "mmc_spi:wp" },
-	{ VISION_SPI_MMC_CD, GPIOF_DIR_IN, "mmc_spi:cd" },
-};
-
-static int vision_spi_mmc_init(struct device *pdev,
-			irqreturn_t (*func)(int, void *), void *pdata)
-{
-	int err;
-
-	err = gpio_request_array(vision_spi_mmc_gpios,
-				 ARRAY_SIZE(vision_spi_mmc_gpios));
-	if (err)
-		return err;
-
-	err = gpio_set_debounce(VISION_SPI_MMC_CD, 1);
-	if (err)
-		goto exit_err;
-
-	err = request_irq(gpio_to_irq(VISION_SPI_MMC_CD), func,
-			IRQ_TYPE_EDGE_BOTH, "mmc_spi:cd", pdata);
-	if (err)
-		goto exit_err;
-
-	return 0;
-
-exit_err:
-	gpio_free_array(vision_spi_mmc_gpios, ARRAY_SIZE(vision_spi_mmc_gpios));
-	return err;
-
-}
-
-static void vision_spi_mmc_exit(struct device *pdev, void *pdata)
-{
-	free_irq(gpio_to_irq(VISION_SPI_MMC_CD), pdata);
-	gpio_free_array(vision_spi_mmc_gpios, ARRAY_SIZE(vision_spi_mmc_gpios));
-}
-
-static int vision_spi_mmc_get_ro(struct device *pdev)
-{
-	return !!gpio_get_value(VISION_SPI_MMC_WP);
-}
-
-static int vision_spi_mmc_get_cd(struct device *pdev)
-{
-	return !gpio_get_value(VISION_SPI_MMC_CD);
-}
-
 static struct mmc_spi_platform_data vision_spi_mmc_data = {
-	.init		= vision_spi_mmc_init,
-	.exit		= vision_spi_mmc_exit,
-	.get_ro		= vision_spi_mmc_get_ro,
-	.get_cd		= vision_spi_mmc_get_cd,
 	.detect_delay	= 100,
 	.powerup_msecs	= 100,
 	.ocr_mask	= MMC_VDD_32_33 | MMC_VDD_33_34,
+	.flags		= MMC_SPI_USE_CD_GPIO | MMC_SPI_USE_RO_GPIO,
+	.cd_gpio	= VISION_SPI_MMC_CD,
+	.ro_gpio	= VISION_SPI_MMC_WP,
+	.caps2		= MMC_CAP2_RO_ACTIVE_HIGH,
 };
 
 static int vision_spi_mmc_hw_setup(struct spi_device *spi)
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 25 19:26:39 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 01:26:39 +0200
Subject: [PATCH 03/12] sh: ecovec24: Use MMC/SDHI CD and RO GPIO
In-Reply-To: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374794808-21890-4-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Pass the CD and RO GPIO numbers to the MMC SPI and SDHI drivers and
remove the custom .get_cd() and .get_ro() callback functions.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 arch/sh/boards/mach-ecovec24/setup.c | 42 +++++++-----------------------------
 1 file changed, 8 insertions(+), 34 deletions(-)

diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-ecovec24/setup.c
index bcbb86b..4d46700 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -620,18 +620,14 @@ static void sdhi0_set_pwr(struct platform_device *pdev, int state)
 	gpio_set_value(GPIO_PTB6, state);
 }
 
-static int sdhi0_get_cd(struct platform_device *pdev)
-{
-	return !gpio_get_value(GPIO_PTY7);
-}
-
 static struct sh_mobile_sdhi_info sdhi0_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI0_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI0_RX,
 	.set_pwr	= sdhi0_set_pwr,
 	.tmio_caps      = MMC_CAP_SDIO_IRQ | MMC_CAP_POWER_OFF_CARD |
 			  MMC_CAP_NEEDS_POLL,
-	.get_cd		= sdhi0_get_cd,
+	.tmio_flags	= TMIO_MMC_USE_GPIO_CD,
+	.cd_gpio	= GPIO_PTY7,
 };
 
 static struct resource sdhi0_resources[] = {
@@ -678,18 +674,14 @@ static void cn12_set_pwr(struct platform_device *pdev, int state)
 
 #if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
 /* SDHI1 */
-static int sdhi1_get_cd(struct platform_device *pdev)
-{
-	return !gpio_get_value(GPIO_PTW7);
-}
-
 static struct sh_mobile_sdhi_info sdhi1_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI1_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI1_RX,
 	.tmio_caps      = MMC_CAP_SDIO_IRQ | MMC_CAP_POWER_OFF_CARD |
 			  MMC_CAP_NEEDS_POLL,
+	.tmio_flags	= TMIO_MMC_USE_GPIO_CD,
+	.cd_gpio	= GPIO_PTW7,
 	.set_pwr	= cn12_set_pwr,
-	.get_cd		= sdhi1_get_cd,
 };
 
 static struct resource sdhi1_resources[] = {
@@ -719,27 +711,19 @@ static struct platform_device sdhi1_device = {
 #else
 
 /* MMC SPI */
-static int mmc_spi_get_ro(struct device *dev)
-{
-	return gpio_get_value(GPIO_PTY6);
-}
-
-static int mmc_spi_get_cd(struct device *dev)
-{
-	return !gpio_get_value(GPIO_PTY7);
-}
-
 static void mmc_spi_setpower(struct device *dev, unsigned int maskval)
 {
 	gpio_set_value(GPIO_PTB6, maskval ? 1 : 0);
 }
 
 static struct mmc_spi_platform_data mmc_spi_info = {
-	.get_ro = mmc_spi_get_ro,
-	.get_cd = mmc_spi_get_cd,
 	.caps = MMC_CAP_NEEDS_POLL,
+	.caps2 = MMC_CAP2_RO_ACTIVE_HIGH,
 	.ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34, /* 3.3V only */
 	.setpower = mmc_spi_setpower,
+	.flags = MMC_SPI_USE_CD_GPIO | MMC_SPI_USE_RO_GPIO,
+	.cd_gpio = GPIO_PTY7,
+	.ro_gpio = GPIO_PTY6,
 };
 
 static struct spi_board_info spi_bus[] = {
@@ -1342,10 +1326,6 @@ static int __init arch_setup(void)
 	gpio_direction_input(GPIO_PTR6);
 
 	/* SD-card slot CN11 */
-	/* Card-detect, used on CN11, either with SDHI0 or with SPI */
-	gpio_request(GPIO_PTY7, NULL);
-	gpio_direction_input(GPIO_PTY7);
-
 #if defined(CONFIG_MMC_SDHI) || defined(CONFIG_MMC_SDHI_MODULE)
 	/* enable SDHI0 on CN11 (needs DS2.4 set to ON) */
 	gpio_request(GPIO_FN_SDHI0WP,  NULL);
@@ -1364,8 +1344,6 @@ static int __init arch_setup(void)
 	gpio_direction_output(GPIO_PTM4, 1); /* active low CS */
 	gpio_request(GPIO_PTB6, NULL); /* 3.3V power control */
 	gpio_direction_output(GPIO_PTB6, 0); /* disable power by default */
-	gpio_request(GPIO_PTY6, NULL); /* write protect */
-	gpio_direction_input(GPIO_PTY6);
 
 	spi_register_board_info(spi_bus, ARRAY_SIZE(spi_bus));
 #endif
@@ -1395,10 +1373,6 @@ static int __init arch_setup(void)
 	gpio_request(GPIO_FN_SDHI1D1,  NULL);
 	gpio_request(GPIO_FN_SDHI1D0,  NULL);
 
-	/* Card-detect, used on CN12 with SDHI1 */
-	gpio_request(GPIO_PTW7, NULL);
-	gpio_direction_input(GPIO_PTW7);
-
 	cn12_enabled = true;
 #endif
 
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 25 19:26:40 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 01:26:40 +0200
Subject: [PATCH 04/12] sh: ecovec24: Remove mmcif .down_pwr() callback
In-Reply-To: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374794808-21890-5-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The callback isn't used by the mmcif driver, don't initialize it in
board code.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 arch/sh/boards/mach-ecovec24/setup.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-ecovec24/setup.c
index 4d46700..e1b6aa3 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -983,11 +983,6 @@ static struct platform_device vou_device = {
 
 #if defined(CONFIG_MMC_SH_MMCIF) || defined(CONFIG_MMC_SH_MMCIF_MODULE)
 /* SH_MMCIF */
-static void mmcif_down_pwr(struct platform_device *pdev)
-{
-	cn12_set_pwr(pdev, 0);
-}
-
 static struct resource sh_mmcif_resources[] = {
 	[0] = {
 		.name	= "SH_MMCIF",
@@ -1009,7 +1004,6 @@ static struct resource sh_mmcif_resources[] = {
 
 static struct sh_mmcif_plat_data sh_mmcif_plat = {
 	.set_pwr	= cn12_set_pwr,
-	.down_pwr	= mmcif_down_pwr,
 	.sup_pclk	= 0, /* SH7724: Max Pclk/2 */
 	.caps		= MMC_CAP_4_BIT_DATA |
 			  MMC_CAP_8_BIT_DATA |
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 25 19:26:41 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 01:26:41 +0200
Subject: [PATCH 05/12] sh: ecovec24: Remove MMCIF and SDHI .set_pwr() callbacks
In-Reply-To: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374794808-21890-6-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The MMCIF and SHDI platform data .set_pwr() callbacks are used to
control the vmmc/vqmmc power supplies. As the power supplies already
register control GPIOs there's no need to perform the operation
manually. Remove the callback functions.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 arch/sh/boards/mach-ecovec24/setup.c | 41 ------------------------------------
 1 file changed, 41 deletions(-)

diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-ecovec24/setup.c
index e1b6aa3..60bf82c 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -601,29 +601,9 @@ static struct platform_device sdhi0_power = {
 	},
 };
 
-static void sdhi0_set_pwr(struct platform_device *pdev, int state)
-{
-	static int power_gpio = -EINVAL;
-
-	if (power_gpio < 0) {
-		int ret = gpio_request(GPIO_PTB6, NULL);
-		if (!ret) {
-			power_gpio = GPIO_PTB6;
-			gpio_direction_output(power_gpio, 0);
-		}
-	}
-
-	/*
-	 * Toggle the GPIO regardless, whether we managed to grab it above or
-	 * the fixed regulator driver did.
-	 */
-	gpio_set_value(GPIO_PTB6, state);
-}
-
 static struct sh_mobile_sdhi_info sdhi0_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI0_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI0_RX,
-	.set_pwr	= sdhi0_set_pwr,
 	.tmio_caps      = MMC_CAP_SDIO_IRQ | MMC_CAP_POWER_OFF_CARD |
 			  MMC_CAP_NEEDS_POLL,
 	.tmio_flags	= TMIO_MMC_USE_GPIO_CD,
@@ -653,25 +633,6 @@ static struct platform_device sdhi0_device = {
 	},
 };
 
-static void cn12_set_pwr(struct platform_device *pdev, int state)
-{
-	static int power_gpio = -EINVAL;
-
-	if (power_gpio < 0) {
-		int ret = gpio_request(GPIO_PTB7, NULL);
-		if (!ret) {
-			power_gpio = GPIO_PTB7;
-			gpio_direction_output(power_gpio, 0);
-		}
-	}
-
-	/*
-	 * Toggle the GPIO regardless, whether we managed to grab it above or
-	 * the fixed regulator driver did.
-	 */
-	gpio_set_value(GPIO_PTB7, state);
-}
-
 #if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
 /* SDHI1 */
 static struct sh_mobile_sdhi_info sdhi1_info = {
@@ -681,7 +642,6 @@ static struct sh_mobile_sdhi_info sdhi1_info = {
 			  MMC_CAP_NEEDS_POLL,
 	.tmio_flags	= TMIO_MMC_USE_GPIO_CD,
 	.cd_gpio	= GPIO_PTW7,
-	.set_pwr	= cn12_set_pwr,
 };
 
 static struct resource sdhi1_resources[] = {
@@ -1003,7 +963,6 @@ static struct resource sh_mmcif_resources[] = {
 };
 
 static struct sh_mmcif_plat_data sh_mmcif_plat = {
-	.set_pwr	= cn12_set_pwr,
 	.sup_pclk	= 0, /* SH7724: Max Pclk/2 */
 	.caps		= MMC_CAP_4_BIT_DATA |
 			  MMC_CAP_8_BIT_DATA |
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 25 19:26:43 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 01:26:43 +0200
Subject: [PATCH 07/12] mmc: sh_mmcif: Remove .down_pwr() callback from
 platform data
In-Reply-To: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374794808-21890-8-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The callback isn't used by the driver and isn't initialized by board
code. Remove it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 include/linux/mmc/sh_mmcif.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/mmc/sh_mmcif.h b/include/linux/mmc/sh_mmcif.h
index e7d5dd6..39011eb 100644
--- a/include/linux/mmc/sh_mmcif.h
+++ b/include/linux/mmc/sh_mmcif.h
@@ -34,7 +34,6 @@
 
 struct sh_mmcif_plat_data {
 	void (*set_pwr)(struct platform_device *pdev, int state);
-	void (*down_pwr)(struct platform_device *pdev);
 	int (*get_cd)(struct platform_device *pdef);
 	unsigned int		slave_id_tx;	/* embedded slave_id_[tr]x */
 	unsigned int		slave_id_rx;
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 25 19:26:42 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 01:26:42 +0200
Subject: [PATCH 06/12] mmc: mmc_spi: Remove platform data .get_cd() and
 .get_ro() callbacks
In-Reply-To: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374794808-21890-7-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

All platforms now pass the CD and RO GPIOs to the MMC SPI driver, those
callbacks are not used anymore. Remove them.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/mmc/host/mmc_spi.c  | 24 ++----------------------
 include/linux/spi/mmc_spi.h |  9 ---------
 2 files changed, 2 insertions(+), 31 deletions(-)

diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index 4e83908..19aa660 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -1273,31 +1273,11 @@ static void mmc_spi_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 	}
 }
 
-static int mmc_spi_get_ro(struct mmc_host *mmc)
-{
-	struct mmc_spi_host *host = mmc_priv(mmc);
-
-	if (host->pdata && host->pdata->get_ro)
-		return !!host->pdata->get_ro(mmc->parent);
-	else
-		return mmc_gpio_get_ro(mmc);
-}
-
-static int mmc_spi_get_cd(struct mmc_host *mmc)
-{
-	struct mmc_spi_host *host = mmc_priv(mmc);
-
-	if (host->pdata && host->pdata->get_cd)
-		return !!host->pdata->get_cd(mmc->parent);
-	else
-		return mmc_gpio_get_cd(mmc);
-}
-
 static const struct mmc_host_ops mmc_spi_ops = {
 	.request	= mmc_spi_request,
 	.set_ios	= mmc_spi_set_ios,
-	.get_ro		= mmc_spi_get_ro,
-	.get_cd		= mmc_spi_get_cd,
+	.get_ro		= mmc_gpio_get_ro,
+	.get_cd		= mmc_gpio_get_cd,
 };
 
 
diff --git a/include/linux/spi/mmc_spi.h b/include/linux/spi/mmc_spi.h
index a54da4a..46cc2f8 100644
--- a/include/linux/spi/mmc_spi.h
+++ b/include/linux/spi/mmc_spi.h
@@ -26,15 +26,6 @@ struct mmc_spi_platform_data {
 		void *);
 	void (*exit)(struct device *, void *);
 
-	/* sense switch on sd cards */
-	int (*get_ro)(struct device *);
-
-	/*
-	 * If board does not use CD interrupts, driver can optimize polling
-	 * using this function.
-	 */
-	int (*get_cd)(struct device *);
-
 	/* Card Detect and Read Only GPIOs */
 	unsigned int flags;
 	unsigned int cd_gpio;
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 25 19:26:44 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 01:26:44 +0200
Subject: [PATCH 08/12] mmc: sh_mmcif: Remove .set_pwr() callback from platform
 data
In-Reply-To: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374794808-21890-9-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The .set_pwr() callback isn't used anymore as all platforms register
GPIO-controlled regulators. Remove it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/mmc/host/sh_mmcif.c  | 3 ---
 include/linux/mmc/sh_mmcif.h | 1 -
 2 files changed, 4 deletions(-)

diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 6706b5e..b827c58 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -956,11 +956,8 @@ static int sh_mmcif_clk_update(struct sh_mmcif_host *host)
 
 static void sh_mmcif_set_power(struct sh_mmcif_host *host, struct mmc_ios *ios)
 {
-	struct sh_mmcif_plat_data *pd = host->pd->dev.platform_data;
 	struct mmc_host *mmc = host->mmc;
 
-	if (pd && pd->set_pwr)
-		pd->set_pwr(host->pd, ios->power_mode != MMC_POWER_OFF);
 	if (!IS_ERR(mmc->supply.vmmc))
 		/* Errors ignored... */
 		mmc_regulator_set_ocr(mmc, mmc->supply.vmmc,
diff --git a/include/linux/mmc/sh_mmcif.h b/include/linux/mmc/sh_mmcif.h
index 39011eb..767fac5 100644
--- a/include/linux/mmc/sh_mmcif.h
+++ b/include/linux/mmc/sh_mmcif.h
@@ -33,7 +33,6 @@
  */
 
 struct sh_mmcif_plat_data {
-	void (*set_pwr)(struct platform_device *pdev, int state);
 	int (*get_cd)(struct platform_device *pdef);
 	unsigned int		slave_id_tx;	/* embedded slave_id_[tr]x */
 	unsigned int		slave_id_rx;
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 25 19:26:45 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 01:26:45 +0200
Subject: [PATCH 09/12] mmc: sh_mobile_sdhi: Remove .get_cd() callback from
 platform data
In-Reply-To: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374794808-21890-10-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

All platforms pass the CD GPIO number to the driver in the .cd_gpio
field. The .get_cd() callback isn't used anymore, remove it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/mmc/host/sh_mobile_sdhi.c  | 9 ---------
 include/linux/mmc/sh_mobile_sdhi.h | 1 -
 2 files changed, 10 deletions(-)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index ebea749..663a672 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -77,13 +77,6 @@ static void sh_mobile_sdhi_set_pwr(struct platform_device *pdev, int state)
 	p->set_pwr(pdev, state);
 }
 
-static int sh_mobile_sdhi_get_cd(struct platform_device *pdev)
-{
-	struct sh_mobile_sdhi_info *p = pdev->dev.platform_data;
-
-	return p->get_cd(pdev);
-}
-
 static int sh_mobile_sdhi_wait_idle(struct tmio_mmc_host *host)
 {
 	int timeout = 1000;
@@ -182,8 +175,6 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
 		mmc_data->cd_gpio = p->cd_gpio;
 		if (p->set_pwr)
 			mmc_data->set_pwr = sh_mobile_sdhi_set_pwr;
-		if (p->get_cd)
-			mmc_data->get_cd = sh_mobile_sdhi_get_cd;
 
 		if (p->dma_slave_tx > 0 && p->dma_slave_rx > 0) {
 			/*
diff --git a/include/linux/mmc/sh_mobile_sdhi.h b/include/linux/mmc/sh_mobile_sdhi.h
index b76bcf0..f31c692 100644
--- a/include/linux/mmc/sh_mobile_sdhi.h
+++ b/include/linux/mmc/sh_mobile_sdhi.h
@@ -26,7 +26,6 @@ struct sh_mobile_sdhi_info {
 	u32 tmio_ocr_mask;	/* available MMC voltages */
 	unsigned int cd_gpio;
 	void (*set_pwr)(struct platform_device *pdev, int state);
-	int (*get_cd)(struct platform_device *pdev);
 
 	/* callbacks for board specific setup code */
 	int (*init)(struct platform_device *pdev,
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 25 19:26:46 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 01:26:46 +0200
Subject: [PATCH 10/12] mmc: sh_mobile_sdhi: Remove .set_pwr() callback from
 platform data
In-Reply-To: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374794808-21890-11-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The .set_pwr() callback isn't used anymore as all platforms register
GPIO-controlled regulators. Remove it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/mmc/host/sh_mobile_sdhi.c  | 9 ---------
 include/linux/mmc/sh_mobile_sdhi.h | 1 -
 2 files changed, 10 deletions(-)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index 663a672..b3fd2c3 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -70,13 +70,6 @@ static void sh_mobile_sdhi_clk_disable(struct platform_device *pdev)
 	clk_disable(priv->clk);
 }
 
-static void sh_mobile_sdhi_set_pwr(struct platform_device *pdev, int state)
-{
-	struct sh_mobile_sdhi_info *p = pdev->dev.platform_data;
-
-	p->set_pwr(pdev, state);
-}
-
 static int sh_mobile_sdhi_wait_idle(struct tmio_mmc_host *host)
 {
 	int timeout = 1000;
@@ -173,8 +166,6 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
 		mmc_data->capabilities |= p->tmio_caps;
 		mmc_data->capabilities2 |= p->tmio_caps2;
 		mmc_data->cd_gpio = p->cd_gpio;
-		if (p->set_pwr)
-			mmc_data->set_pwr = sh_mobile_sdhi_set_pwr;
 
 		if (p->dma_slave_tx > 0 && p->dma_slave_rx > 0) {
 			/*
diff --git a/include/linux/mmc/sh_mobile_sdhi.h b/include/linux/mmc/sh_mobile_sdhi.h
index f31c692..68927ae 100644
--- a/include/linux/mmc/sh_mobile_sdhi.h
+++ b/include/linux/mmc/sh_mobile_sdhi.h
@@ -25,7 +25,6 @@ struct sh_mobile_sdhi_info {
 	unsigned long tmio_caps2;
 	u32 tmio_ocr_mask;	/* available MMC voltages */
 	unsigned int cd_gpio;
-	void (*set_pwr)(struct platform_device *pdev, int state);
 
 	/* callbacks for board specific setup code */
 	int (*init)(struct platform_device *pdev,
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 25 19:26:47 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 01:26:47 +0200
Subject: [PATCH 11/12] mmc: tmio-mmc: Remove .get_cd() callback from platform
 data
In-Reply-To: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374794808-21890-12-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

All platforms pass the CD GPIO number to the driver in the .cd_gpio
field. The .get_cd() callback isn't used anymore, remove it

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/mmc/host/tmio_mmc_pio.c | 16 +---------------
 include/linux/mfd/tmio.h        |  1 -
 2 files changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index b72edb7..a335fb8 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -932,25 +932,11 @@ static int tmio_mmc_get_ro(struct mmc_host *mmc)
 		 (sd_ctrl_read32(host, CTL_STATUS) & TMIO_STAT_WRPROTECT));
 }
 
-static int tmio_mmc_get_cd(struct mmc_host *mmc)
-{
-	struct tmio_mmc_host *host = mmc_priv(mmc);
-	struct tmio_mmc_data *pdata = host->pdata;
-	int ret = mmc_gpio_get_cd(mmc);
-	if (ret >= 0)
-		return ret;
-
-	if (!pdata->get_cd)
-		return -ENOSYS;
-	else
-		return pdata->get_cd(host->pdev);
-}
-
 static const struct mmc_host_ops tmio_mmc_ops = {
 	.request	= tmio_mmc_request,
 	.set_ios	= tmio_mmc_set_ios,
 	.get_ro         = tmio_mmc_get_ro,
-	.get_cd		= tmio_mmc_get_cd,
+	.get_cd		= mmc_gpio_get_cd,
 	.enable_sdio_irq = tmio_mmc_enable_sdio_irq,
 };
 
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index ce35113..b22883d 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -108,7 +108,6 @@ struct tmio_mmc_data {
 	unsigned int			cd_gpio;
 	void (*set_pwr)(struct platform_device *host, int state);
 	void (*set_clk_div)(struct platform_device *host, int state);
-	int (*get_cd)(struct platform_device *host);
 	int (*write16_hook)(struct tmio_mmc_host *host, int addr);
 	/* clock management callbacks */
 	int (*clk_enable)(struct platform_device *pdev, unsigned int *f);
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Thu Jul 25 19:26:48 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 01:26:48 +0200
Subject: [PATCH 12/12] mmc: tmio-mmc: Remove .set_pwr() callback from platform
 data
In-Reply-To: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1374794808-21890-13-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The .set_pwr() callback isn't used anymore as all platforms register
GPIO-controlled regulators. Remove it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/mmc/host/tmio_mmc.h     | 1 -
 drivers/mmc/host/tmio_mmc_pio.c | 7 -------
 include/linux/mfd/tmio.h        | 1 -
 3 files changed, 9 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 86fd21e..39c2f45 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -68,7 +68,6 @@ struct tmio_mmc_host {
 	enum tmio_mmc_power	power;
 
 	/* Callbacks for clock / power control */
-	void (*set_pwr)(struct platform_device *host, int state);
 	void (*set_clk_div)(struct platform_device *host, int state);
 
 	/* pio related stuff */
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index a335fb8..0cd37e2 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -777,9 +777,6 @@ static void tmio_mmc_power_on(struct tmio_mmc_host *host, unsigned short vdd)
 
 	/* .set_ios() is returning void, so, no chance to report an error */
 
-	if (host->set_pwr)
-		host->set_pwr(host->pdev, 1);
-
 	if (!IS_ERR(mmc->supply.vmmc)) {
 		ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
 		/*
@@ -809,9 +806,6 @@ static void tmio_mmc_power_off(struct tmio_mmc_host *host)
 
 	if (!IS_ERR(mmc->supply.vmmc))
 		mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
-
-	if (host->set_pwr)
-		host->set_pwr(host->pdev, 0);
 }
 
 /* Set MMC clock / power.
@@ -998,7 +992,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host,
 	_host->pdev = pdev;
 	platform_set_drvdata(pdev, mmc);
 
-	_host->set_pwr = pdata->set_pwr;
 	_host->set_clk_div = pdata->set_clk_div;
 
 	/* SD control register space size is 0x200, 0x400 for bus_shift=1 */
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index b22883d..baa2346 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -106,7 +106,6 @@ struct tmio_mmc_data {
 	struct tmio_mmc_dma		*dma;
 	struct device			*dev;
 	unsigned int			cd_gpio;
-	void (*set_pwr)(struct platform_device *host, int state);
 	void (*set_clk_div)(struct platform_device *host, int state);
 	int (*write16_hook)(struct tmio_mmc_host *host, int addr);
 	/* clock management callbacks */
-- 
1.8.1.5



From hartleys at visionengravers.com  Thu Jul 25 19:33:44 2013
From: hartleys at visionengravers.com (H Hartley Sweeten)
Date: Thu, 25 Jul 2013 18:33:44 -0500
Subject: [PATCH 02/12] ARM: ep93xx: vision_ep9307: Use MMC CD and RO GPIO
In-Reply-To: <1374794808-21890-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1374794808-21890-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <ADE657CA350FB648AAC2C43247A983F0021DAC5C20A6@AUSP01VMBX24.collaborationhost.net>

On Thursday, July 25, 2013 4:27 PM, Laurent Pinchart wrote:
>
> Pass the CD and RO GPIO numbers to the MMC SPI driver and remove the
> custom .get_cd() and .get_ro() callback functions.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> ---
>  arch/arm/mach-ep93xx/vision_ep9307.c | 56 +++---------------------------------
>  1 file changed, 4 insertions(+), 52 deletions(-)

I'll try testing this tomorrow.

Thanks,
Hartley



From rmallon at gmail.com  Thu Jul 25 19:37:17 2013
From: rmallon at gmail.com (Ryan Mallon)
Date: Fri, 26 Jul 2013 09:37:17 +1000
Subject: [PATCH 00/12] Remove platform callbacks from mmc_spi, sh_mmcif
 and sh_mobile_sdhi drivers
In-Reply-To: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <51F1B6AD.5060909@gmail.com>

On 26/07/13 09:26, Laurent Pinchart wrote:
> Hello,
> 
> This patch set replaces callbacks to board code with regulators and GPIOs in
> the mmc_spi, sh_mmcif and sh_mobile_sdhi MMC drivers.
> 
> Most of the required infrastructure is in place already on the drivers side,
> except for CD/RO GPIOs support in the mmc_spi driver. The series thus starts
> with patch 01/12 that adds this feature to the mmc_spi driver.
> 
> Patches 02/12 to 05/12 remove the board callbacks from the ecovec24 and
> vision_ep9307 boards. The code has been compile-tested only as I don't have
> access to those boards.
> 
> Patches 06/12 to 07/12 then proceed to remove the callbacks from the drivers
> themselves and from the platform data structures.
> 
> This will be a bit messy to merge, as the series interleaves patches for
> drivers and board files. Given that the mmc_spi driver is marked as orphan in
> MAINTAINERS and that the vision_ep9307 hasn't seen any board-specific
> modification in the last couple of kernel versions one option would be to
> merge all patches (or at least patches 01/12 to 06/12) through Simon's tree if
> all involved maintainers agree.

I'm fine with this. The ep93xx tree sees very few patches, so it would
be easier. As long as you get Ack's from Hartley, and please also check
with the arm-soc team (Arnd and Olof, Cc'ed) so that they are aware of
the patches.

> 
> The series is based on tag renesas-devel-20130725 from
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
> 
> Laurent Pinchart (12):
>   mmc: mmc_spi: Support CD/RO GPIOs
>   ARM: ep93xx: vision_ep9307: Use MMC CD and RO GPIO
>   sh: ecovec24: Use MMC/SDHI CD and RO GPIO
>   sh: ecovec24: Remove mmcif .down_pwr() callback
>   sh: ecovec24: Remove MMCIF and SDHI .set_pwr() callbacks
>   mmc: mmc_spi: Remove platform data .get_cd() and .get_ro() callbacks
>   mmc: sh_mmcif: Remove .down_pwr() callback from platform data
>   mmc: sh_mmcif: Remove .set_pwr() callback from platform data
>   mmc: sh_mobile_sdhi: Remove .get_cd() callback from platform data
>   mmc: sh_mobile_sdhi: Remove .set_pwr() callback from platform data
>   mmc: tmio-mmc: Remove .get_cd() callback from platform data
>   mmc: tmio-mmc: Remove .set_pwr() callback from platform data
> 
>  arch/arm/mach-ep93xx/vision_ep9307.c | 56 ++---------------------
>  arch/sh/boards/mach-ecovec24/setup.c | 89 ++++--------------------------------
>  drivers/mmc/host/mmc_spi.c           | 48 +++++++++----------
>  drivers/mmc/host/of_mmc_spi.c        | 46 +++++--------------
>  drivers/mmc/host/sh_mmcif.c          |  3 --
>  drivers/mmc/host/sh_mobile_sdhi.c    | 18 --------
>  drivers/mmc/host/tmio_mmc.h          |  1 -
>  drivers/mmc/host/tmio_mmc_pio.c      | 23 +---------
>  include/linux/mfd/tmio.h             |  2 -
>  include/linux/mmc/sh_mmcif.h         |  2 -
>  include/linux/mmc/sh_mobile_sdhi.h   |  2 -
>  include/linux/spi/mmc_spi.h          | 18 ++++----
>  12 files changed, 56 insertions(+), 252 deletions(-)
> 



From rmallon at gmail.com  Thu Jul 25 19:45:26 2013
From: rmallon at gmail.com (Ryan Mallon)
Date: Fri, 26 Jul 2013 09:45:26 +1000
Subject: [PATCH 01/12] mmc: mmc_spi: Support CD/RO GPIOs
In-Reply-To: <1374794808-21890-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1374794808-21890-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <51F1B896.8020005@gmail.com>

On 26/07/13 09:26, Laurent Pinchart wrote:
> Add support for passing CD/RO GPIO numbers directly to the mmc_spi
> driver instead of relying solely on board code callbacks to retrieve the
> CD/RO signals values.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> ---
>  drivers/mmc/host/mmc_spi.c    | 32 +++++++++++++++++++++---------
>  drivers/mmc/host/of_mmc_spi.c | 46 +++++++++++--------------------------------
>  include/linux/spi/mmc_spi.h   | 11 +++++++++++
>  3 files changed, 46 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
> index 74145d1..4e83908 100644
> --- a/drivers/mmc/host/mmc_spi.c
> +++ b/drivers/mmc/host/mmc_spi.c
> @@ -36,6 +36,7 @@
>  
>  #include <linux/mmc/host.h>
>  #include <linux/mmc/mmc.h>		/* for R1_SPI_* bit values */
> +#include <linux/mmc/slot-gpio.h>
>  
>  #include <linux/spi/spi.h>
>  #include <linux/spi/mmc_spi.h>
> @@ -1278,11 +1279,8 @@ static int mmc_spi_get_ro(struct mmc_host *mmc)
>  
>  	if (host->pdata && host->pdata->get_ro)
>  		return !!host->pdata->get_ro(mmc->parent);
> -	/*
> -	 * Board doesn't support read only detection; let the mmc core
> -	 * decide what to do.
> -	 */
> -	return -ENOSYS;
> +	else
> +		return mmc_gpio_get_ro(mmc);

Why not just have the board file assign mmc_gpio_get_ro as
host->pdata->get_ro? This would eliminate the need for the
MMC_SPI_USE_RO_GPIO flag.

Also, if host->pdata->get_ro is not set then this will assume
mmc_gpio_get_ro is valid, even if MMC_SPI_USE_RO_GPIO is not set. I'm
guessing it will end up returning -ENOSYS, but they way the code reads
is that if the host doesn't have get_ro function set, then it is must be
a gpio.

Same applies for the other callbacks.

~Ryan



From jg1.han at samsung.com  Thu Jul 25 19:47:36 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Fri, 26 Jul 2013 08:47:36 +0900
Subject: [PATCHv2 2/3] video: hx8357: Make IM pins optional
In-Reply-To: <1374757513-2253-3-git-send-email-maxime.ripard@free-electrons.com>
References: <1374757513-2253-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374757513-2253-3-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <002201ce8991$5785e8e0$0691baa0$@samsung.com>

On Thursday, July 25, 2013 10:05 PM, Maxime Ripard wrote:
> 
> The IM pins of the HX8357 controller are used to define the interface
> used to feed pixel stream to the LCD panel.
> 
> Most of the time, these pins are directly routed to either the ground or
> the VCC to set their values.
> 
> Remove the need to assign GPIOs to these pins when we are in such a case.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  drivers/video/backlight/hx8357.c | 53 +++++++++++++++++++++++-----------------
>  1 file changed, 31 insertions(+), 22 deletions(-)
> 

[.....]

> +	if (of_find_property(spi->dev.of_node, "im-gpios", NULL)) {
> +		lcd->use_im_pins = 1;
> +
> +		for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
> +			lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
> +							    "im-gpios", i);
> +			if (lcd->im_pins[i] == -EPROBE_DEFER) {
> +				dev_info(&spi->dev, "GPIO requested is not here yet, deferring the
> probe\n");
> +				return -EPROBE_DEFER;
> +			}
> +			if (!gpio_is_valid(lcd->im_pins[i])) {
> +				dev_err(&spi->dev, "Missing dt property: im-gpios\n");
> +				return -EINVAL;
> +			}
> +
> +			ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
> +						    GPIOF_OUT_INIT_LOW,
> +						    "im_pins");
> +			if (ret) {
> +				dev_err(&spi->dev, "failed to request gpio %d: %d\n",
> +					lcd->im_pins[i], ret);
> +				return -EINVAL;
> +			}
>  		}
> -
> -		ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
> -					GPIOF_OUT_INIT_LOW, "im_pins");
> -		if (ret) {
> -			dev_err(&spi->dev, "failed to request gpio %d: %d\n",
> -				lcd->im_pins[i], ret);
> -			return -EINVAL;
> -		}
> -	}
> +	} else
> +		lcd->use_im_pins = 0;

According to the 'Documentation/CodingStyle', braces are necessary as below.

	} else {
		lcd->use_im_pins = 0;
	}

Others look good.
Acked-by: Jingoo Han <jg1.han at samsung.com>

Best regards,
Jingoo Han




From jg1.han at samsung.com  Thu Jul 25 19:52:09 2013
From: jg1.han at samsung.com (Jingoo Han)
Date: Fri, 26 Jul 2013 08:52:09 +0900
Subject: [PATCHv2 3/3] fb: backlight: HX8357: Add HX8369 support
In-Reply-To: <1374757513-2253-4-git-send-email-maxime.ripard@free-electrons.com>
References: <1374757513-2253-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374757513-2253-4-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <002301ce8991$f9b82060$ed286120$@samsung.com>

On Thursday, July 25, 2013 10:05 PM, Maxime Ripard wrote:
> 
> From: Alexandre Belloni <alexandre.belloni at free-electrons.com>
> 
> Add support for the Himax HX8369 controller as it is quite similar to the
> hx8357.
> 
> Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> Acked-by: Jingoo Han <jg1.han at samsung.com>
> ---
>  drivers/video/backlight/hx8357.c | 221 ++++++++++++++++++++++++++++++++++++---
>  1 file changed, 206 insertions(+), 15 deletions(-)
> 

[....]

> +	ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_ON);
> +	if (ret < 0)
> +		return ret;
> +
> +	msleep(100);

Hi Maxime Ripard,

Could you add comment on this huge delay, too?

Best regards,
Jingoo Han




From rjw at sisk.pl  Thu Jul 25 20:07:06 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Fri, 26 Jul 2013 02:07:06 +0200
Subject: [RESEND] cpuidle for ARM pull request
In-Reply-To: <2075555.RCmWLFAfjq@vostro.rjw.lan>
References: <51E536C5.1020609@linaro.org> <1766778.ZYeDKBOsjV@vostro.rjw.lan>
 <2075555.RCmWLFAfjq@vostro.rjw.lan>
Message-ID: <1598661.FpX5cmjM1U@vostro.rjw.lan>

On Friday, July 26, 2013 12:41:09 AM Rafael J. Wysocki wrote:
> On Friday, July 26, 2013 12:29:08 AM Rafael J. Wysocki wrote:
> > On Friday, July 26, 2013 12:07:03 AM Daniel Lezcano wrote:
> > > On 07/16/2013 02:04 PM, Daniel Lezcano wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > The first PR was against the linux-pm-next tree including the patch:
> > > > 
> > > > "cpuidle: Add Kconfig.arm and move calxeda, kirkwood and zynq"
> > > > 
> > > > This patch has been dropped in the meantime.
> > > > 
> > > > Here is a new PR where my tree has been rebased against linux-pm-next
> > > > and adding the patch mentioned above.
> > > > 
> > > > As stated by Rafael, I will handle the ARM specific patches from now.
> > > > 
> > > > The following changes since commit 48f99d5a97d32d70c0738d6e314d9f4dbefd89bf:
> > > > 
> > > >   Merge branch 'pm-cpuidle-next' into linux-next (2013-07-16 02:41:06 +0200)
> > > > 
> > > > are available in the git repository at:
> > > > 
> > > > 
> > > >   git://git.linaro.org/people/dlezcano/linux.git cpuidle/arm-next
> > > > 
> > > > for you to fetch changes up to 2b7e79f4a75e803184f483985a25cc751a990f06:
> > > > 
> > > >   ARM: ux500: cpuidle: Move ux500 cpuidle driver to drivers/cpuidle
> > > > (2013-07-16 13:57:24 +0200)
> > > 
> > > ping ?
> > 
> > Sorry, something distracted me.  I'll pull it later today unless there are any
> > problems (in which case I'll let you know).
> 
> Well, there are some.
> 
> It is based on my linux-next branch, but please rebase it on top of 3.11-rc2.
> 
> Generally, please send me pull requests based on -rc kernels only (or major
> releases).

Unless your material depends on new things in my linux-next branch, in which
case please let me know and I'll set up a stable branch for you to base things
on.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From laurent.pinchart at ideasonboard.com  Thu Jul 25 20:04:34 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 02:04:34 +0200
Subject: [PATCH 01/12] mmc: mmc_spi: Support CD/RO GPIOs
In-Reply-To: <51F1B896.8020005@gmail.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1374794808-21890-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <51F1B896.8020005@gmail.com>
Message-ID: <3057612.zXvbbdByqU@avalon>

Hi Ryan,

On Friday 26 July 2013 09:45:26 Ryan Mallon wrote:
> On 26/07/13 09:26, Laurent Pinchart wrote:
> > Add support for passing CD/RO GPIO numbers directly to the mmc_spi
> > driver instead of relying solely on board code callbacks to retrieve the
> > CD/RO signals values.
> > 
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas at ideasonboard.com>
> > ---
> > 
> >  drivers/mmc/host/mmc_spi.c    | 32 +++++++++++++++++++++---------
> >  drivers/mmc/host/of_mmc_spi.c | 46 ++++++++++----------------------------
> >  include/linux/spi/mmc_spi.h   | 11 +++++++++++
> >  3 files changed, 46 insertions(+), 43 deletions(-)
> > 
> > diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
> > index 74145d1..4e83908 100644
> > --- a/drivers/mmc/host/mmc_spi.c
> > +++ b/drivers/mmc/host/mmc_spi.c
> > @@ -36,6 +36,7 @@
> > 
> >  #include <linux/mmc/host.h>
> >  #include <linux/mmc/mmc.h>		/* for R1_SPI_* bit values */
> > +#include <linux/mmc/slot-gpio.h>
> >  #include <linux/spi/spi.h>
> >  #include <linux/spi/mmc_spi.h>
> > 
> > @@ -1278,11 +1279,8 @@ static int mmc_spi_get_ro(struct mmc_host *mmc)
> >  	if (host->pdata && host->pdata->get_ro)
> >  		return !!host->pdata->get_ro(mmc->parent);
> > 
> > -	/*
> > -	 * Board doesn't support read only detection; let the mmc core
> > -	 * decide what to do.
> > -	 */
> > -	return -ENOSYS;
> > +	else
> > +		return mmc_gpio_get_ro(mmc);
> 
> Why not just have the board file assign mmc_gpio_get_ro as
> host->pdata->get_ro? This would eliminate the need for the
> MMC_SPI_USE_RO_GPIO flag.

Because the idea is to get rid of board callbacks and rely on proper kernel 
abstraction layers such as the GPIO subsystem. This will be especially 
important when adding device tree support to the mmc_spi driver.

> Also, if host->pdata->get_ro is not set then this will assume
> mmc_gpio_get_ro is valid, even if MMC_SPI_USE_RO_GPIO is not set. I'm
> guessing it will end up returning -ENOSYS, but they way the code reads is
> that if the host doesn't have get_ro function set, then it is must be a
> gpio.

mmc_gpio_get_ro() will indeed return -ENOSYS when the MMC_SPI_USE_RO_GPIO flag 
isn't set, as the mmc_spi driver will not call mmc_gpio_request_ro() in that 
case.

This patch hides the -ENOSYS value from the mmc_spi_get_ro() and 
mmc_spi_get_cd() functions, perhaps making them slightly confusing, but patch 
06/12 then gets rid of those functions, so I don't think it's a bit issue.

> Same applies for the other callbacks.

-- 
Regards,

Laurent Pinchart



From matt.porter at linaro.org  Thu Jul 25 20:04:13 2013
From: matt.porter at linaro.org (Matt Porter)
Date: Thu, 25 Jul 2013 20:04:13 -0400
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130719020611.GA4941@glitch> <20130723185733.GB6811@ohporter.com>
 <CAGVrzcYnoN9NnJGvubS7=bVJDk37xSt4BimtvDWghe7OHEWALQ@mail.gmail.com>
 <20130724231106.GB29801@glitch>
 <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
Message-ID: <20130726000412.GH5022@linaro.org>

On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote:
> 2013/7/25 Domenico Andreoli <cavokz at gmail.com>:
> > On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote:
> >> 2013/7/23 Matt Porter <matt.porter at linaro.org>:
> >> > On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
> >> >> On Wed, Jul 17, 2013 at 12:08:30AM +0100, Florian Fainelli wrote:
> >> >> > Hello,
> >> >> >
> >> >> > Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :
> >> >> > > > + compatible = "brcm,bcm5301x";
> >> >> > >
> >> >> > > Ok, this was nagging at me before I went on my very long
> vacation. I see
> >> >> > > the "brcm" vendor prefix as a real consistency problem. I noticed
> on the
> >> >> > > bcm281xx/kona family, we have been using "bcm" which is not
> logged in
> >> >> > > vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had
> >> >> > > already established use of "brcm" before any of the bcm281xx
> support
> >> >> > > came in. Ideally, the vendor prefix should change to "bcm" since
> every
> >> >> > > reference in the family names is BCM. However, if others want the
> least
> >> >> > > amount of churn in making this consistent, we might have to go
> with
> >> >> > > "brcm" across the board.
> >> >> >
> >> >> > I would like to keep "brcm" here because that is what has been
> defined as a
> >> >> > vendor prefix, and is used beyond the scope of the ARM Linux kernel
> support
> >> >> > even within Broadcom. Maybe it was an oversight, or rather a
> mistake to let
> >> >>
> >> >> brcm is the stock ticker. As far as I can search, this is the
> convention
> >> >> for the vendor prefixes.
> >> >
> >> > No, correlation does not equal causation. The fact that some vendor
> >> > prefixes in DT match the stock symbol is by chance of 3-4 character
> name
> >> > being the same...nothing more.
> >>
> >> That was a bad argument as was later explained to me, I won't use that
> >> reason again.
> >
> > I cited the stock ticker only because IIRC it's the reason my initial
> > proposal for bcm has been ditched in favour of brcm when bcm2835 was
> > initially proposed.
> >
> >> > It's pretty easy to see that the "ti" vendor prefix has no relation at
> >> > all to their TXN symbol so that blows that convention out of the water.
> >> > Rather, the prefix is based on somebody's notion of how that vendor's
> >> > part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
> >> > never TXN OMAP. :)
> >> >
> >> > For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.
> >>
> >> It was appropriate before being the "wrong" vendor prefix was
> >> allocated, now that "brcm" has been allocated we should stick to it
> >> because otherwise we will break existing and on-going DT work.
> >
> > I still prefer bcm to brcm and I find enough evidence that bcm would be
> > better in the long term.
> >
> > So if Broadcomers can agree on bcm, now it's still the cheapest time to
> > fix in that direction, later will not be better.
> 
> If we are to fix it in stone, once and for all, let's go for the full name
> which would avoid any kind of future confusion (this also seems to be the
> tendency with new vendor prefixes these days). That way we could make
> everyone happy with say: "broadcom,bcm2835". Would that work for everyone?

I really like that.

-Matt


From horms at verge.net.au  Thu Jul 25 20:10:53 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 26 Jul 2013 09:10:53 +0900
Subject: [PATCH v2 1/2] ARM: shmobile: r8a7778: add HPB-DMAC support
In-Reply-To: <201307230222.04763.sergei.shtylyov@cogentembedded.com>
References: <201307230218.01495.sergei.shtylyov@cogentembedded.com>
 <201307230222.04763.sergei.shtylyov@cogentembedded.com>
Message-ID: <20130726001052.GA28912@verge.net.au>

[ Cc Morimoto-san ]

On Tue, Jul 23, 2013 at 02:22:04AM +0400, Sergei Shtylyov wrote:
> From: Max Filippov <max.filippov at cogentembedded.com>
> 
> Add HPB-DMAC platform device on R8A7778 SoC along with its slave and channel
> configurations.
> 
> Signed-off-by: Max Filippov <max.filippov at cogentembedded.com>
> [Sergei: moved *enum* declaring HPB-DMAC slave IDs from now removed <mach/dma.h>
> to <mach/r8a7778.h>, removed #include <mach/dma.h> from setup-r8a7778.c, removed
> SSI-related *enum* values and SSI-related data from hpb_dmae_slaves[] and
> hpb_dmae_channels[].]
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---
> Changes in version 2:
> - moved *enum* declaring HPB-DMAC slave IDs from the separate header file to
>   <mach/r8a7778.h>, removed #include <mach/dma.h> from setup-r8a7778.c;
> - removed SSI-related *enum* values and SSI-related data from hpb_dmae_slaves[]
>   and hpb_dmae_channels[].
> 
>  arch/arm/mach-shmobile/include/mach/r8a7778.h |    8 ++
>  arch/arm/mach-shmobile/setup-r8a7778.c        |   80 ++++++++++++++++++++++++++
>  2 files changed, 88 insertions(+)

Morimoto-san, Magnus,

could you please review this?

> 
> Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
> +++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
> @@ -1,6 +1,7 @@
>  /*
>   * Copyright (C) 2013  Renesas Solutions Corp.
>   * Copyright (C) 2013  Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> + * Copyright (C) 2013  Cogent Embedded, Inc.
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License as published by
> @@ -23,6 +24,13 @@
>  #include <linux/sh_eth.h>
>  #include <linux/platform_data/usb-rcar-phy.h>
>  
> +/* HPB-DMA slave IDs */
> +enum {
> +	HPBDMA_SLAVE_DUMMY,
> +	HPBDMA_SLAVE_SDHI0_TX,
> +	HPBDMA_SLAVE_SDHI0_RX,
> +};
> +
>  extern void r8a7778_add_standard_devices(void);
>  extern void r8a7778_add_standard_devices_dt(void);
>  extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
> Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
> ===================================================================
> --- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
> +++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
> @@ -24,6 +24,7 @@
>  #include <linux/irqchip/arm-gic.h>
>  #include <linux/of.h>
>  #include <linux/of_platform.h>
> +#include <linux/platform_data/dma-rcar-hpbdma.h>
>  #include <linux/platform_data/gpio-rcar.h>
>  #include <linux/platform_data/irq-renesas-intc-irqpin.h>
>  #include <linux/platform_device.h>
> @@ -333,6 +334,84 @@ void __init r8a7778_add_mmc_device(struc
>  		info, sizeof(*info));
>  }
>  
> +/* HPB-DMA */
> +
> +/* Asynchronous mode register (ASYNCMDR) bits */
> +#define	ASYNCMDR_ASMD22_MASK	BIT(2)	/* SDHI0 */
> +#define	ASYNCMDR_ASMD22_SINGLE	BIT(2)	/* SDHI0 */
> +#define	ASYNCMDR_ASMD22_MULTI	0	/* SDHI0 */
> +#define	ASYNCMDR_ASMD21_MASK	BIT(1)	/* SDHI0 */
> +#define	ASYNCMDR_ASMD21_SINGLE	BIT(1)	/* SDHI0 */
> +#define	ASYNCMDR_ASMD21_MULTI	0	/* SDHI0 */
> +
> +static const struct hpb_dmae_slave_config hpb_dmae_slaves[] = {
> +	{
> +		.id	= HPBDMA_SLAVE_SDHI0_TX,
> +		.addr	= 0xffe4c000 + 0x30,
> +		.dcr	= DCR_SPDS_16BIT | DCR_DMDL | DCR_DPDS_16BIT,
> +		.rstr	= ASYNCRSTR_ASRST21 | ASYNCRSTR_ASRST22 |
> +			  ASYNCRSTR_ASRST23,
> +		.mdr	= ASYNCMDR_ASMD21_SINGLE,
> +		.mdm	= ASYNCMDR_ASMD21_MASK,
> +		.port	= 0x0D0C,
> +		.flags	= HPB_DMAE_SET_ASYNC_RESET | HPB_DMAE_SET_ASYNC_MODE,
> +		.dma_ch	= 21,
> +	}, {
> +		.id	= HPBDMA_SLAVE_SDHI0_RX,
> +		.addr	= 0xffe4c000 + 0x30,
> +		.dcr	= DCR_SMDL | DCR_SPDS_16BIT | DCR_DPDS_16BIT,
> +		.rstr	= ASYNCRSTR_ASRST21 | ASYNCRSTR_ASRST22 |
> +			  ASYNCRSTR_ASRST23,
> +		.mdr	= ASYNCMDR_ASMD22_SINGLE,
> +		.mdm	= ASYNCMDR_ASMD22_MASK,
> +		.port	= 0x0D0C,
> +		.flags	= HPB_DMAE_SET_ASYNC_RESET | HPB_DMAE_SET_ASYNC_MODE,
> +		.dma_ch	= 22,
> +	},
> +};
> +
> +static const struct hpb_dmae_channel hpb_dmae_channels[] = {
> +	/* ch. 21 SD0 */
> +	HPB_DMAE_CHANNEL(0x7e, HPBDMA_SLAVE_SDHI0_TX),
> +	/* ch. 22 SD0 */
> +	HPB_DMAE_CHANNEL(0x7e, HPBDMA_SLAVE_SDHI0_RX),
> +};
> +
> +static struct hpb_dmae_pdata dma_platform_data __initdata = {
> +	.slaves			= hpb_dmae_slaves,
> +	.num_slaves		= ARRAY_SIZE(hpb_dmae_slaves),
> +	.channels		= hpb_dmae_channels,
> +	.num_channels		= ARRAY_SIZE(hpb_dmae_channels),
> +	.ts_shift		= {
> +		[XMIT_SZ_8BIT]	= 0,
> +		[XMIT_SZ_16BIT]	= 1,
> +		[XMIT_SZ_32BIT]	= 2,
> +	},
> +	.num_hw_channels	= 39,
> +};
> +
> +static struct resource hpb_dmae_resources[] __initdata = {
> +	/* Channel registers */
> +	DEFINE_RES_MEM(0xffc08000, 0x1000),
> +	/* Common registers */
> +	DEFINE_RES_MEM(0xffc09000, 0x170),
> +	/* Asynchronous reset registers */
> +	DEFINE_RES_MEM(0xffc00300, 4),
> +	/* Asynchronous mode registers */
> +	DEFINE_RES_MEM(0xffc00400, 4),
> +	/* IRQ for DMA channels */
> +	DEFINE_RES_NAMED(gic_iid(0x7b), 5, NULL, IORESOURCE_IRQ),
> +};
> +
> +static void __init r8a7778_register_hpb_dmae(void)
> +{
> +	platform_device_register_resndata(&platform_bus, "hpb-dma-engine", -1,
> +					  hpb_dmae_resources,
> +					  ARRAY_SIZE(hpb_dmae_resources),
> +					  &dma_platform_data,
> +					  sizeof(dma_platform_data));
> +}
> +
>  void __init r8a7778_add_standard_devices(void)
>  {
>  	int i;
> @@ -355,6 +434,7 @@ void __init r8a7778_add_standard_devices
>  
>  	r8a7778_register_tmu(0);
>  	r8a7778_register_tmu(1);
> +	r8a7778_register_hpb_dmae();
>  }
>  
>  void __init r8a7778_init_late(void)
> 


From horms at verge.net.au  Thu Jul 25 20:11:26 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 26 Jul 2013 09:11:26 +0900
Subject: [PATCH v2] ARM: shmobile: Add lager defconfig
In-Reply-To: <1374566966-30345-1-git-send-email-horms+renesas@verge.net.au>
References: <1374566966-30345-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130726001125.GB28912@verge.net.au>

On Tue, Jul 23, 2013 at 05:09:26PM +0900, Simon Horman wrote:
> This is intended to be used until multi-arch is able to be
> used for the lager board at which time a more generic configuration
> will be used in place of this one.
> 
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

Magnus, could your review this?

> 
> ---
> 
> v2
> * Place defconfig in correct directory
> * Bump SERIAL_SH_SCI_NR_UARTS up to 10 to reflect the
>   number of devices present
> ---
>  arch/arm/configs/lager_defconfig | 121 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 121 insertions(+)
>  create mode 100644 arch/arm/configs/lager_defconfig
> 
> diff --git a/arch/arm/configs/lager_defconfig b/arch/arm/configs/lager_defconfig
> new file mode 100644
> index 0000000..f9efae1
> --- /dev/null
> +++ b/arch/arm/configs/lager_defconfig
> @@ -0,0 +1,121 @@
> +CONFIG_SYSVIPC=y
> +CONFIG_NO_HZ=y
> +CONFIG_IKCONFIG=y
> +CONFIG_IKCONFIG_PROC=y
> +CONFIG_LOG_BUF_SHIFT=16
> +CONFIG_CC_OPTIMIZE_FOR_SIZE=y
> +CONFIG_SYSCTL_SYSCALL=y
> +CONFIG_EMBEDDED=y
> +CONFIG_PERF_EVENTS=y
> +CONFIG_SLAB=y
> +# CONFIG_LBDAF is not set
> +# CONFIG_BLK_DEV_BSG is not set
> +# CONFIG_IOSCHED_DEADLINE is not set
> +# CONFIG_IOSCHED_CFQ is not set
> +CONFIG_ARCH_SHMOBILE=y
> +CONFIG_ARCH_R8A7790=y
> +CONFIG_MACH_LAGER=y
> +# CONFIG_SH_TIMER_TMU is not set
> +# CONFIG_EM_TIMER_STI is not set
> +# CONFIG_SWP_EMULATE is not set
> +CONFIG_ARM_ERRATA_430973=y
> +CONFIG_ARM_ERRATA_458693=y
> +CONFIG_ARM_ERRATA_460075=y
> +CONFIG_ARM_ERRATA_743622=y
> +CONFIG_ARM_ERRATA_754322=y
> +CONFIG_SMP=y
> +CONFIG_NR_CPUS=2
> +# CONFIG_LOCAL_TIMERS is not set
> +CONFIG_AEABI=y
> +# CONFIG_OABI_COMPAT is not set
> +CONFIG_FORCE_MAX_ZONEORDER=13
> +CONFIG_ZBOOT_ROM_TEXT=0x0
> +CONFIG_ZBOOT_ROM_BSS=0x0
> +CONFIG_ARM_APPENDED_DTB=y
> +CONFIG_KEXEC=y
> +CONFIG_AUTO_ZRELADDR=y
> +CONFIG_VFP=y
> +CONFIG_NEON=y
> +# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
> +CONFIG_PM_RUNTIME=y
> +CONFIG_NET=y
> +CONFIG_PACKET=y
> +CONFIG_UNIX=y
> +CONFIG_INET=y
> +CONFIG_IP_PNP=y
> +CONFIG_IP_PNP_DHCP=y
> +# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
> +# CONFIG_INET_XFRM_MODE_TUNNEL is not set
> +# CONFIG_INET_XFRM_MODE_BEET is not set
> +# CONFIG_INET_LRO is not set
> +# CONFIG_INET_DIAG is not set
> +# CONFIG_IPV6 is not set
> +# CONFIG_WIRELESS is not set
> +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
> +CONFIG_NETDEVICES=y
> +# CONFIG_NET_CORE is not set
> +# CONFIG_NET_VENDOR_ARC is not set
> +# CONFIG_NET_CADENCE is not set
> +# CONFIG_NET_VENDOR_BROADCOM is not set
> +# CONFIG_NET_VENDOR_CIRRUS is not set
> +# CONFIG_NET_VENDOR_FARADAY is not set
> +# CONFIG_NET_VENDOR_INTEL is not set
> +# CONFIG_NET_VENDOR_MARVELL is not set
> +# CONFIG_NET_VENDOR_MICREL is not set
> +# CONFIG_NET_VENDOR_NATSEMI is not set
> +CONFIG_SH_ETH=y
> +# CONFIG_NET_VENDOR_SEEQ is not set
> +# CONFIG_NET_VENDOR_SMSC is not set
> +# CONFIG_NET_VENDOR_STMICRO is not set
> +# CONFIG_NET_VENDOR_VIA is not set
> +# CONFIG_NET_VENDOR_WIZNET is not set
> +# CONFIG_WLAN is not set
> +# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
> +CONFIG_INPUT_EVDEV=y
> +# CONFIG_KEYBOARD_ATKBD is not set
> +CONFIG_KEYBOARD_GPIO=y
> +# CONFIG_INPUT_MOUSE is not set
> +# CONFIG_SERIO is not set
> +# CONFIG_LEGACY_PTYS is not set
> +CONFIG_SERIAL_SH_SCI=y
> +CONFIG_SERIAL_SH_SCI_NR_UARTS=10
> +CONFIG_SERIAL_SH_SCI_CONSOLE=y
> +# CONFIG_HW_RANDOM is not set
> +CONFIG_I2C=y
> +CONFIG_I2C_GPIO=y
> +CONFIG_I2C_SH_MOBILE=y
> +CONFIG_GPIO_SH_PFC=y
> +CONFIG_GPIOLIB=y
> +CONFIG_GPIO_RCAR=y
> +# CONFIG_HWMON is not set
> +CONFIG_REGULATOR=y
> +CONFIG_REGULATOR_FIXED_VOLTAGE=y
> +# CONFIG_USB_SUPPORT is not set
> +CONFIG_MMC=y
> +CONFIG_MMC_SDHI=y
> +CONFIG_MMC_SH_MMCIF=y
> +CONFIG_NEW_LEDS=y
> +CONFIG_LEDS_CLASS=y
> +CONFIG_LEDS_GPIO=y
> +CONFIG_RTC_CLASS=y
> +CONFIG_DMADEVICES=y
> +CONFIG_SH_DMAE=y
> +# CONFIG_IOMMU_SUPPORT is not set
> +# CONFIG_DNOTIFY is not set
> +CONFIG_MSDOS_FS=y
> +CONFIG_VFAT_FS=y
> +CONFIG_TMPFS=y
> +CONFIG_CONFIGFS_FS=y
> +# CONFIG_MISC_FILESYSTEMS is not set
> +CONFIG_NFS_FS=y
> +CONFIG_NFS_V3_ACL=y
> +CONFIG_NFS_V4=y
> +CONFIG_NFS_V4_1=y
> +CONFIG_ROOT_NFS=y
> +CONFIG_NLS_CODEPAGE_437=y
> +CONFIG_NLS_ISO8859_1=y
> +# CONFIG_ENABLE_WARN_DEPRECATED is not set
> +# CONFIG_ENABLE_MUST_CHECK is not set
> +# CONFIG_ARM_UNWIND is not set
> +# CONFIG_CRYPTO_ANSI_CPRNG is not set
> +# CONFIG_CRYPTO_HW is not set
> -- 
> 1.8.2.1
> 


From hartleys at visionengravers.com  Thu Jul 25 20:19:52 2013
From: hartleys at visionengravers.com (H Hartley Sweeten)
Date: Thu, 25 Jul 2013 19:19:52 -0500
Subject: [PATCH 02/12] ARM: ep93xx: vision_ep9307: Use MMC CD and RO GPIO
In-Reply-To: <1374794808-21890-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1374794808-21890-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <ADE657CA350FB648AAC2C43247A983F0021DAC5C20AC@AUSP01VMBX24.collaborationhost.net>

On Thursday, July 25, 2013 4:27 PM, Laurent Pinchart wrote:
>
> Pass the CD and RO GPIO numbers to the MMC SPI driver and remove the
> custom .get_cd() and .get_ro() callback functions.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> ---
>  arch/arm/mach-ep93xx/vision_ep9307.c | 56 +++---------------------------------
>  1 file changed, 4 insertions(+), 52 deletions(-)
>
> diff --git a/arch/arm/mach-ep93xx/vision_ep9307.c b/arch/arm/mach-ep93xx/vision_ep9307.c
> index 605956f..ab94dc5 100644
> --- a/arch/arm/mach-ep93xx/vision_ep9307.c
> +++ b/arch/arm/mach-ep93xx/vision_ep9307.c
> @@ -224,62 +224,14 @@ static struct ep93xx_spi_chip_ops vision_spi_flash_hw = {
>  #define VISION_SPI_MMC_WP	EP93XX_GPIO_LINE_F(0)
>  #define VISION_SPI_MMC_CD	EP93XX_GPIO_LINE_EGPIO15
>  
> -static struct gpio vision_spi_mmc_gpios[] = {
> -	{ VISION_SPI_MMC_WP, GPIOF_DIR_IN, "mmc_spi:wp" },
> -	{ VISION_SPI_MMC_CD, GPIOF_DIR_IN, "mmc_spi:cd" },
> -};
> -
> -static int vision_spi_mmc_init(struct device *pdev,
> -			irqreturn_t (*func)(int, void *), void *pdata)
> -{
> -	int err;
> -
> -	err = gpio_request_array(vision_spi_mmc_gpios,
> -				 ARRAY_SIZE(vision_spi_mmc_gpios));
> -	if (err)
> -		return err;
> -
> -	err = gpio_set_debounce(VISION_SPI_MMC_CD, 1);
> -	if (err)
> -		goto exit_err;

I tested this and it _kind_ of works.

The card detect is a bit flaky due to the gpio interrupt debounce not being enabled.

The only way I can see to fix this is add the following to this patch:

@@ -233,8 +233,31 @@ static struct mmc_spi_platform_data vision_spi_mmc_data = {
        .caps2          = MMC_CAP2_RO_ACTIVE_HIGH,
 };
 
+static int vision_spi_mmc_enable_cd_debounce(struct spi_device *spi)
+{
+       int ret;
+
+       ret = gpio_request_one(VISION_SPI_MMC_CD, GPIOF_DIR_IN, spi->modalias);
+       if (ret)
+               return ret;
+
+       ret = gpio_set_debounce(VISION_SPI_MMC_CD, 1);
+       if (ret)
+               return ret;
+
+       gpio_free(VISION_SPI_MMC_CD);
+
+       return 0;
+}
+
 static int vision_spi_mmc_hw_setup(struct spi_device *spi)
 {
+       int ret;
+
+       ret = vision_spi_mmc_enable_cd_debounce(spi);
+       if (ret)
+               return ret;
+
        return gpio_request_one(VISION_SPI_MMC_CS, GPIOF_INIT_HIGH,
                                spi->modalias);
 }

Regards,
Hartley



From rmallon at gmail.com  Thu Jul 25 20:23:01 2013
From: rmallon at gmail.com (Ryan Mallon)
Date: Fri, 26 Jul 2013 10:23:01 +1000
Subject: [PATCH 01/12] mmc: mmc_spi: Support CD/RO GPIOs
In-Reply-To: <3057612.zXvbbdByqU@avalon>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1374794808-21890-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <51F1B896.8020005@gmail.com> <3057612.zXvbbdByqU@avalon>
Message-ID: <51F1C165.6040600@gmail.com>

On 26/07/13 10:04, Laurent Pinchart wrote:
> Hi Ryan,
> 
> On Friday 26 July 2013 09:45:26 Ryan Mallon wrote:
>> On 26/07/13 09:26, Laurent Pinchart wrote:
>>> Add support for passing CD/RO GPIO numbers directly to the mmc_spi
>>> driver instead of relying solely on board code callbacks to retrieve the
>>> CD/RO signals values.
>>>
>>> Signed-off-by: Laurent Pinchart
>>> <laurent.pinchart+renesas at ideasonboard.com>
>>> ---
>>>
>>>  drivers/mmc/host/mmc_spi.c    | 32 +++++++++++++++++++++---------
>>>  drivers/mmc/host/of_mmc_spi.c | 46 ++++++++++----------------------------
>>>  include/linux/spi/mmc_spi.h   | 11 +++++++++++
>>>  3 files changed, 46 insertions(+), 43 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
>>> index 74145d1..4e83908 100644
>>> --- a/drivers/mmc/host/mmc_spi.c
>>> +++ b/drivers/mmc/host/mmc_spi.c
>>> @@ -36,6 +36,7 @@
>>>
>>>  #include <linux/mmc/host.h>
>>>  #include <linux/mmc/mmc.h>		/* for R1_SPI_* bit values */
>>> +#include <linux/mmc/slot-gpio.h>
>>>  #include <linux/spi/spi.h>
>>>  #include <linux/spi/mmc_spi.h>
>>>
>>> @@ -1278,11 +1279,8 @@ static int mmc_spi_get_ro(struct mmc_host *mmc)
>>>  	if (host->pdata && host->pdata->get_ro)
>>>  		return !!host->pdata->get_ro(mmc->parent);
>>>
>>> -	/*
>>> -	 * Board doesn't support read only detection; let the mmc core
>>> -	 * decide what to do.
>>> -	 */
>>> -	return -ENOSYS;
>>> +	else
>>> +		return mmc_gpio_get_ro(mmc);
>>
>> Why not just have the board file assign mmc_gpio_get_ro as
>> host->pdata->get_ro? This would eliminate the need for the
>> MMC_SPI_USE_RO_GPIO flag.
> 
> Because the idea is to get rid of board callbacks and rely on proper kernel 
> abstraction layers such as the GPIO subsystem. This will be especially 
> important when adding device tree support to the mmc_spi driver.
> 
>> Also, if host->pdata->get_ro is not set then this will assume
>> mmc_gpio_get_ro is valid, even if MMC_SPI_USE_RO_GPIO is not set. I'm
>> guessing it will end up returning -ENOSYS, but they way the code reads is
>> that if the host doesn't have get_ro function set, then it is must be a
>> gpio.
> 
> mmc_gpio_get_ro() will indeed return -ENOSYS when the MMC_SPI_USE_RO_GPIO flag 
> isn't set, as the mmc_spi driver will not call mmc_gpio_request_ro() in that 
> case.
> 
> This patch hides the -ENOSYS value from the mmc_spi_get_ro() and 
> mmc_spi_get_cd() functions, perhaps making them slightly confusing, but patch 
> 06/12 then gets rid of those functions, so I don't think it's a bit issue.

Ah, I didn't read far enough along in the patch series :-). So all mmc
spi ro/cd controls are now assumed to be gpios?

~Ryan






From jonsmirl at gmail.com  Thu Jul 25 20:27:15 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Thu, 25 Jul 2013 20:27:15 -0400
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130725231848.GJ24642@n2100.arm.linux.org.uk>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
 <20130725193135.GT23879@titan.lakedaemon.net>
 <20130725231848.GJ24642@n2100.arm.linux.org.uk>
Message-ID: <CAKON4OwwOnP9kbN0JqR5L+F1svTucAQvz0RDwqU+Gy9UAFwHog@mail.gmail.com>

On Thu, Jul 25, 2013 at 7:18 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Thu, Jul 25, 2013 at 03:31:35PM -0400, Jason Cooper wrote:
>> On Thu, Jul 25, 2013 at 02:11:31PM -0500, Rob Herring wrote:
>> > On Thu, Jul 25, 2013 at 11:09 AM, Olof Johansson <olof at lixom.net> wrote:
>>
>> > > One problem that needs to be solved is obviously how a binding
>> > > graduates from tentative to locked. This work isn't going to be very
>> > > interesting to most people, I suspect. Think standards committee type
>> > > work.
>> >
>> > I think a time based stabilization period would be better than a
>> > separate directory to apply bindings too. Or time plus periodic review
>> > perhaps.
>>
>> The only problem with a time-based versus separate directory is how do
>> users who've downloaded the tree determine which bindings are stable?
>> If they pull a tarball, or receive an SDK, there is most likely no git
>> history attached.
>>
>> I think the idea of a 'tentative' directory (or 'locked') is churnish,
>> but necessary.  If I DL'd a tarball and had to type 'tentative' to get
>> to the binding doc I wanted, that would be a pretty clear clue to be
>> delicate about how I trust/use/plan with that binding.
>
> It's actually extremely simple.  If the bindings are in development,
> they must not appear in a -final released kernel.  Anything that appears
> in a -final kernel becomes part of the ABI at that point.
>
> That obviously does not mean you remove them in the last -rc and put
> them back during the merge window!
>
> That's how we handle every other ABI thing in the kernel tree, why should
> DT files be any different?  (I've added Linus and Grant to this discussion.)
>
> As I've already stated, it is intended to eventually remove the DT files
> from the kernel tree and have them as a separately maintained project,
> which means they will be independent of the kernel version.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Having a schema system for the device trees is closely related to this
discussion.  In this case the schema would probably be equal to the
stable set of nodes. This has been discussed before on the device tree
mailing list. The dtc compiler would take this schema and validate the
trees it compiles against it issuing warnings for 'non-standard'
usage. Over time the schema would be updated to allow these usages
when everyone agrees to it. Note that there would be a single schema
describing all possible legal Linux device trees.

The scheme is also quite useful for new tree developers since it will
show them the universe of device tree attributes that have already
been standardized. By using comments, you could probably turn the
device tree documentation into the schema source files.

-- 
Jon Smirl
jonsmirl at gmail.com


From swarren at wwwdotorg.org  Thu Jul 25 20:36:28 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 25 Jul 2013 17:36:28 -0700
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130725215315.GV7729@decadent.org.uk>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
 <20130725193135.GT23879@titan.lakedaemon.net>
 <CAL_Jsq+vWbTb8wNEDCR2c_M6sBnKW6e5HGk48QzmXSujQUdddA@mail.gmail.com>
 <20130725203228.GX23879@titan.lakedaemon.net>
 <20130725215315.GV7729@decadent.org.uk>
Message-ID: <51F1C48C.7010408@wwwdotorg.org>

On 07/25/2013 02:53 PM, Ben Hutchings wrote:
> On Thu, Jul 25, 2013 at 04:32:28PM -0400, Jason Cooper wrote:
> [...]
>> One of the things I've been trying to square up in my head is how to
>> retain the history of the binding when moving to the new tree.  My
>> current idea was to clone the kernel tree, add one patch deleting
>> everything but the bindings and dts files, and one more patch moving
>> things where we want them (arch/{powerpc,arm}/boot/dts -> dts).
>>
>> Then, as needed, we could merge a kernel version tag and delete
>> everything we don't need (code) in the merge commit.
>>
>> The downside of this is it would be messy, the upside is that we could
>> closely track the kernel tree (until the bindings and dts are moved
>> out), and retain the history of the bindings and dts files.
> [...]
> 
> It's *extremely* messy, but 'git filter-branch' might help to make a
> clean tracking branch preserving history of just DT files.  David
> Woodhouse did something like that for the linux-firmware repo
> initially.

Ian Campbell is already working on exactly this solution:
https://lkml.org/lkml/2013/7/23/547



From swarren at wwwdotorg.org  Thu Jul 25 20:34:26 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Thu, 25 Jul 2013 17:34:26 -0700
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <CAL_Jsq+vWbTb8wNEDCR2c_M6sBnKW6e5HGk48QzmXSujQUdddA@mail.gmail.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
 <20130725193135.GT23879@titan.lakedaemon.net>
 <CAL_Jsq+vWbTb8wNEDCR2c_M6sBnKW6e5HGk48QzmXSujQUdddA@mail.gmail.com>
Message-ID: <51F1C412.1010602@wwwdotorg.org>

On 07/25/2013 01:16 PM, Rob Herring wrote:
> On Thu, Jul 25, 2013 at 2:31 PM, Jason Cooper <jason at lakedaemon.net> wrote:
>> On Thu, Jul 25, 2013 at 02:11:31PM -0500, Rob Herring wrote:
>>> On Thu, Jul 25, 2013 at 11:09 AM, Olof Johansson <olof at lixom.net> wrote:
>>
>>>> One problem that needs to be solved is obviously how a binding
>>>> graduates from tentative to locked. This work isn't going to be very
>>>> interesting to most people, I suspect. Think standards committee type
>>>> work.
>>>
>>> I think a time based stabilization period would be better than a
>>> separate directory to apply bindings too. Or time plus periodic review
>>> perhaps.
>>
>> The only problem with a time-based versus separate directory is how do
>> users who've downloaded the tree determine which bindings are stable?
>> If they pull a tarball, or receive an SDK, there is most likely no git
>> history attached.
> 
> Well, if time based includes moving the binding out of the kernel,
> then that is what defines it as stable or not. I guess that is a form
> of a separate directory. I don't think we want to be moving bindings
> twice: tentative -> stable and kernel -> DT repo.
> 
> The policy could be as simple as an binding without change in at least
> N kernel releases is moved out and stable.

That might not be quite the right criteria. Just because something
didn't change doesn't mean it's "correct" and that any problems in the
binding have been addressed. As one example, on Tegra, we have a few
bindings that haven't changed in a while, yet rely on custom properties
for describing which DMA channel to use, rather than using the
fairly-recently-introduced standard DMA DT properties (this particular
example is being rectified now, but I'm sure there are plenty of similar
examples)


From olof at lixom.net  Thu Jul 25 20:41:00 2013
From: olof at lixom.net (Olof Johansson)
Date: Thu, 25 Jul 2013 17:41:00 -0700
Subject: [GIT PULL] ARM: SoC fixes for 3.11-rc
Message-ID: <20130726004100.GA5131@quad.lixom.net>

Hi Linus,

The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b:

  Linux 3.11-rc2 (2013-07-21 12:05:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus

for you to fetch changes up to 515c0967205f2e6d0ca1602ce0de65f9aec1d215:

  mfd: max8925: fix dt code for backlight (2013-07-25 16:57:00 -0700)

----------------------------------------------------------------
ARM: SoC fixes for 3.11-rc

This is a largeish batch of fixes, mostly because I missed -rc2 due to
travel/vacation. So in number these are a bit more than ideal unless
you amortize them over two -rcs.

Quick breakdown:
 - Defconfig updates
   - Making multi_v7_defconfig useful on more hardware to encourage
     single-image usage
   - Davinci and nomadik updates due to new code merged this merge window
 - Fixes for UART on Samsung platforms, both PM and clock-related
 - A handful of warning fixes from defconfig builds, including for
   max8925 backlight and pxamci (both with appropriate acks)
 - Exynos5440 fixes for LPAE configuration, PM
 - ...plus a bunch of other smaller changes all over the place

I expect to switch to regressions-or-severe-bugs-only fixes from here
on out.

----------------------------------------------------------------
Alexander Shiyan (1):
      ARM: i.MX27: Typo fix

Amit Daniel Kachhap (1):
      ARM: SAMSUNG: Add SAMSUNG_PM config option to select pm

Arnd Bergmann (1):
      ARM: pxa: propagate errors from regulator_enable() to pxamci

Fabio Estevam (2):
      ARM: dts: imx51-babbage: Pass a real clock to the codec
      ARM: multi_v7_defconfig: Select USB chipidea driver

Guennadi Liakhovetski (1):
      dmaengine: shdma: fix a build failure on platforms with no DMA support

Kukjin Kim (1):
      ARM: EXYNOS: skip pm support on exynos5440

Laurent Pinchart (1):
      ARM i.MX53: mba53: Fix PWM backlight DT node

Linus Walleij (2):
      ARM: nomadik: update defconfig base
      ARM: nomadik: configure for NO_HZ and HRTIMERS

Liu Ying (1):
      ARM: i.MX6Q: correct emi_sel clock muxing

Markus Pargmann (1):
      ARM: imx27: Fix documentation for SPLL clock

Mike Frysinger (1):
      ARM: footbridge: fix overlapping PCI mappings

Olof Johansson (7):
      Merge tag 'davinci-fixes-for-v3.11-rc2' of git://git.kernel.org/.../nsekhar/linux-davinci into fixes
      Merge tag 'omap-for-v3.11/fixes-against-rc1' of git://git.kernel.org/.../tmlind/linux-omap into fixes
      Merge tag 'imx-fixes-3.11' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes
      Merge tag 'nomadik-defconfig-for-arm-soc' of git://git.kernel.org/.../linusw/linux-nomadik into fixes
      ARM: omap5: Only select errata 798181 if SMP
      Merge tag 'samsung-fixes-1' of git://git.kernel.org/.../kgene/linux-samsung into fixes
      mfd: max8925: fix dt code for backlight

Philipp Zabel (2):
      ARM i.MX53: Fix UART pad configuration
      ARM i.MX6Q: Fix IOMUXC GPR1 defines for ENET_CLK_SEL and IPU1/2_MUX

Rob Herring (1):
      ARM: highbank: Only touch common coherency control register fields

Roger Quadros (1):
      ARM: OMAP2+: Provide alias to USB PHY clock

Sachin Kamat (1):
      ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos

Sekhar Nori (2):
      ARM: davinci: make file local variables static
      ARM: davinci: defconfig: enable EDMA driver

Shawn Guo (2):
      ARM: mxs: saif0 is the clock provider to sgtl5000
      ARM: imx: fix vf610 enet module clock selection

Srinivas Kandagatla (2):
      ARM: dts: STi: Fix pinconf setup for STiH416 serial2
      ARM: STi: Set correct ARM ERRATAs.

Subash Patel (1):
      ARM: EXYNOS: change the PHYSMEM_BITS and SECTION_SIZE

Sylwester Nawrocki (1):
      ARM: S3C24XX: Add missing clkdev entries for s3c2440 UART

Thomas Abraham (1):
      ARM: EXYNOS: Enable 64-bit DMA for EXYNOS5440 if LPAE is enabled

Tony Lindgren (3):
      ARM: multi_v7: Enabled omap4430 sdp nfsroot
      ARM: dts: Add missing vmmc2 regulator for twl
      Merge branch 'omap-for-v3.11/dt-fixes' into omap-for-v3.11/fixes

Ulf Hansson (1):
      ARM: nomadik: Update MMC defconfigs

Vincent Stehl? (2):
      ARM: keystone: fix compilation warning
      ARM: zynq: fix compilation warning

Wei Yongjun (1):
      ARM: edma: remove duplicated include from edma.c

Yadwinder Singh Brar (2):
      ARM: SAMSUNG: Save/restore only selected uart's registers
      ARM: EXYNOS: Fix low level debug support

 .../devicetree/bindings/clock/imx27-clock.txt      |   1 +
 arch/arm/Kconfig                                   |   3 +-
 arch/arm/boot/dts/imx28-apx4devkit.dts             |   2 +-
 arch/arm/boot/dts/imx28-evk.dts                    |   2 +-
 arch/arm/boot/dts/imx28-m28evk.dts                 |   2 +-
 arch/arm/boot/dts/imx28.dtsi                       |   1 +
 arch/arm/boot/dts/imx51-babbage.dts                |  13 +-
 arch/arm/boot/dts/imx53-mba53.dts                  |   2 +-
 arch/arm/boot/dts/imx53.dtsi                       |  32 ++--
 arch/arm/boot/dts/stih416-pinctrl.dtsi             |  10 +-
 arch/arm/boot/dts/stih416.dtsi                     |   2 +-
 arch/arm/boot/dts/twl4030.dtsi                     |   6 +
 arch/arm/boot/dts/vf610.dtsi                       |   8 +-
 arch/arm/common/edma.c                             |   1 -
 arch/arm/configs/da8xx_omapl_defconfig             |   2 +
 arch/arm/configs/davinci_all_defconfig             |   2 +
 arch/arm/configs/multi_v7_defconfig                |   6 +-
 arch/arm/configs/nhk8815_defconfig                 |   7 +-
 arch/arm/mach-davinci/board-dm365-evm.c            |   2 +-
 arch/arm/mach-davinci/dm355.c                      |   2 +-
 arch/arm/mach-davinci/dm365.c                      |   2 +-
 arch/arm/mach-exynos/Kconfig                       |   1 +
 arch/arm/mach-exynos/Makefile                      |   2 +-
 arch/arm/mach-exynos/common.c                      |  26 ----
 arch/arm/mach-exynos/common.h                      |   1 -
 arch/arm/mach-exynos/cpuidle.c                     |   1 +
 arch/arm/mach-exynos/include/mach/memory.h         |   5 +
 arch/arm/mach-exynos/pm.c                          |   6 +
 arch/arm/mach-footbridge/dc21285.c                 |   2 -
 arch/arm/mach-highbank/highbank.c                  |   7 +-
 arch/arm/mach-imx/clk-imx6q.c                      |   5 +-
 arch/arm/mach-imx/clk-vf610.c                      |   2 +
 arch/arm/mach-imx/mx27.h                           |   2 +-
 arch/arm/mach-keystone/keystone.c                  |   2 +-
 arch/arm/mach-omap2/Kconfig                        |   2 +-
 arch/arm/mach-omap2/board-generic.c                |  23 ++-
 arch/arm/mach-pxa/em-x270.c                        |  17 ++-
 arch/arm/mach-pxa/mainstone.c                      |   3 +-
 arch/arm/mach-pxa/pcm990-baseboard.c               |   3 +-
 arch/arm/mach-pxa/poodle.c                         |   4 +-
 arch/arm/mach-pxa/spitz.c                          |   4 +-
 arch/arm/mach-pxa/stargate2.c                      |   3 +-
 arch/arm/mach-s3c24xx/clock-s3c2410.c              | 161 +++++++++++++--------
 arch/arm/mach-s3c24xx/clock-s3c2440.c              |   3 +
 arch/arm/mach-sti/Kconfig                          |   3 +-
 arch/arm/mach-zynq/common.c                        |   2 +-
 arch/arm/plat-samsung/Kconfig                      |   7 +
 arch/arm/plat-samsung/Makefile                     |   2 +-
 arch/arm/plat-samsung/include/plat/clock.h         |   5 +
 arch/arm/plat-samsung/include/plat/pm.h            |   8 +-
 arch/arm/plat-samsung/pm.c                         |  14 +-
 drivers/mmc/host/pxamci.c                          |   2 +-
 drivers/video/backlight/max8925_bl.c               |  41 +++---
 include/dt-bindings/clock/vf610-clock.h            |   4 +-
 include/linux/mfd/syscon/imx6q-iomuxc-gpr.h        |  16 +-
 include/linux/platform_data/mmc-pxamci.h           |   2 +-
 include/linux/shdma-base.h                         |   4 +
 57 files changed, 307 insertions(+), 196 deletions(-)


From horms+renesas at verge.net.au  Thu Jul 25 20:51:49 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Jul 2013 09:51:49 +0900
Subject: [PATCH v3 0/4] ARM: shmobile: marzen: Switch to DT_MACHINE_START
Message-ID: <1374799913-27461-1-git-send-email-horms+renesas@verge.net.au>

A short series to use DT_MACHINE_START on the marzen board.

Changes since v2
* Break dtb changes out of "ARM: shmobile: marzen: Switch to
  DT_MACHINE_START" and into their own patch "ARM: shmobile: marzen: Add
  r8a7779-marzen.dtb"
* Correct typo in changelog of "ARM: shmobile: marzen: Enable
  ARM_APPENDED_DTB in defconfig"

Changes since v1
* Add "ARM: shmobile: marzen: Enable ARM_APPENDED_DTB in defconfig" patch
* Add "ARM: shmobile: r8a7779: Rely on DT for SMP CPU info" patch
* Enhance "ARM: shmobile: marzen: Switch to DT_MACHINE_START" to:
  - Select USE_OF in Kconfig
  - Provide dt_compat in DT_MACHINE_START
  - Provide r8a7779-marzen dts

Magnus Damm (1):
  ARM: shmobile: marzen: Switch to DT_MACHINE_START

Simon Horman (3):
  ARM: shmobile: marzen: Add  r8a7779-marzen.dtb
  ARM: shmobile: r8a7779: Rely on DT for SMP CPU info
  ARM: shmobile: marzen: Enable ARM_APPENDED_DTB in defconfig

 arch/arm/boot/dts/Makefile            |  1 +
 arch/arm/boot/dts/r8a7779-marzen.dts  | 27 +++++++++++++++++++++++++++
 arch/arm/configs/marzen_defconfig     |  1 +
 arch/arm/mach-shmobile/Kconfig        |  1 +
 arch/arm/mach-shmobile/board-marzen.c |  8 +++++++-
 arch/arm/mach-shmobile/smp-r8a7779.c  | 12 +++---------
 6 files changed, 40 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/boot/dts/r8a7779-marzen.dts

-- 
1.8.2.1



From horms+renesas at verge.net.au  Thu Jul 25 20:51:53 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Jul 2013 09:51:53 +0900
Subject: [PATCH v3 4/4] ARM: shmobile: marzen: Enable ARM_APPENDED_DTB in
 defconfig
In-Reply-To: <1374799913-27461-1-git-send-email-horms+renesas@verge.net.au>
References: <1374799913-27461-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1374799913-27461-5-git-send-email-horms+renesas@verge.net.au>

"ARM: shmobile: marzen: Switch to DT_MACHINE_START" moves marzen
over to use DT_MACHINE_START, however, the prevalent boot loader
does not support booting with a separate dtb. Thus, it makes
sense to use ARM_APPENDED_DTB by default.

This is consistent with other shmobile defconfigs.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

v3
* Corrected typo in changelog

v2
* First post
---
 arch/arm/configs/marzen_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/marzen_defconfig b/arch/arm/configs/marzen_defconfig
index 494e70a..82e4040 100644
--- a/arch/arm/configs/marzen_defconfig
+++ b/arch/arm/configs/marzen_defconfig
@@ -29,6 +29,7 @@ CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
 CONFIG_CMDLINE="console=ttySC2,115200 earlyprintk=sh-sci.2,115200 ignore_loglevel root=/dev/nfs ip=on"
 CONFIG_CMDLINE_FORCE=y
 CONFIG_KEXEC=y
-- 
1.8.2.1



From horms+renesas at verge.net.au  Thu Jul 25 20:51:52 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Jul 2013 09:51:52 +0900
Subject: [PATCH v3 3/4] ARM: shmobile: r8a7779: Rely on DT for SMP CPU info
In-Reply-To: <1374799913-27461-1-git-send-email-horms+renesas@verge.net.au>
References: <1374799913-27461-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1374799913-27461-4-git-send-email-horms+renesas@verge.net.au>

Remove r8a7779 specific ->smp_init_cpus() callback and
instead of relying on shmobile_smp_init_cpus() simply
use DT for CPU core information.

Based on work for the sh73a0 by Magnus Damm.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

v2
* First post
---
 arch/arm/mach-shmobile/smp-r8a7779.c | 12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/smp-r8a7779.c b/arch/arm/mach-shmobile/smp-r8a7779.c
index 9bdf810..42170af 100644
--- a/arch/arm/mach-shmobile/smp-r8a7779.c
+++ b/arch/arm/mach-shmobile/smp-r8a7779.c
@@ -99,6 +99,9 @@ static int r8a7779_boot_secondary(unsigned int cpu, struct task_struct *idle)
 
 static void __init r8a7779_smp_prepare_cpus(unsigned int max_cpus)
 {
+
+	/* setup r8a7779 specific SCU base */
+	shmobile_scu_base = IOMEM(R8A7779_SCU_BASE);
 	scu_enable(shmobile_scu_base);
 
 	/* Map the reset vector (in headsmp-scu.S, headsmp.S) */
@@ -117,14 +120,6 @@ static void __init r8a7779_smp_prepare_cpus(unsigned int max_cpus)
 	r8a7779_platform_cpu_kill(3);
 }
 
-static void __init r8a7779_smp_init_cpus(void)
-{
-	/* setup r8a7779 specific SCU base */
-	shmobile_scu_base = IOMEM(R8A7779_SCU_BASE);
-
-	shmobile_smp_init_cpus(scu_get_core_count(shmobile_scu_base));
-}
-
 #ifdef CONFIG_HOTPLUG_CPU
 static int r8a7779_scu_psr_core_disabled(int cpu)
 {
@@ -175,7 +170,6 @@ static int r8a7779_cpu_disable(unsigned int cpu)
 #endif /* CONFIG_HOTPLUG_CPU */
 
 struct smp_operations r8a7779_smp_ops  __initdata = {
-	.smp_init_cpus		= r8a7779_smp_init_cpus,
 	.smp_prepare_cpus	= r8a7779_smp_prepare_cpus,
 	.smp_boot_secondary	= r8a7779_boot_secondary,
 #ifdef CONFIG_HOTPLUG_CPU
-- 
1.8.2.1



From horms+renesas at verge.net.au  Thu Jul 25 20:51:50 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Jul 2013 09:51:50 +0900
Subject: [PATCH v3 1/4] ARM: shmobile: marzen: Add  r8a7779-marzen.dtb
In-Reply-To: <1374799913-27461-1-git-send-email-horms+renesas@verge.net.au>
References: <1374799913-27461-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1374799913-27461-2-git-send-email-horms+renesas@verge.net.au>

This is in preparation for converting the marzen board to
use DT_MACHINE_START.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

v3
* First post
* Broke out of "ARM: shmobile: marzen: Switch to DT_MACHINE_START"
---
 arch/arm/boot/dts/Makefile           |  1 +
 arch/arm/boot/dts/r8a7779-marzen.dts | 27 +++++++++++++++++++++++++++
 2 files changed, 28 insertions(+)
 create mode 100644 arch/arm/boot/dts/r8a7779-marzen.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ae98d8f..ec4196d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -188,6 +188,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
 	r8a7778-bockw.dtb \
 	r8a7778-bockw-reference.dtb \
 	r8a7740-armadillo800eva-reference.dtb \
+	r8a7779-marzen.dtb \
 	r8a7779-marzen-reference.dtb \
 	r8a7790-lager.dtb \
 	r8a7790-lager-reference.dtb \
diff --git a/arch/arm/boot/dts/r8a7779-marzen.dts b/arch/arm/boot/dts/r8a7779-marzen.dts
new file mode 100644
index 0000000..f3f7f79
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7779-marzen.dts
@@ -0,0 +1,27 @@
+/*
+ * Device Tree Source for the Marzen board
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Simon Horman
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "r8a7779.dtsi"
+
+/ {
+	model = "marzen";
+	compatible = "renesas,marzen", "renesas,r8a7779";
+
+	chosen {
+		bootargs = "console=ttySC2,115200 earlyprintk=sh-sci.2,115200 ignore_loglevel root=/dev/nfs ip=on";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x60000000 0x40000000>;
+	};
+};
-- 
1.8.2.1



From horms+renesas at verge.net.au  Thu Jul 25 20:51:51 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Jul 2013 09:51:51 +0900
Subject: [PATCH v3 2/4] ARM: shmobile: marzen: Switch to DT_MACHINE_START
In-Reply-To: <1374799913-27461-1-git-send-email-horms+renesas@verge.net.au>
References: <1374799913-27461-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1374799913-27461-3-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Convert the marzen board to use DT_MACHINE_START. With this in
place all mach-shmobile boards use DT_MACHINE_START. Also, this
makes it possible for the r8a7779 SMP code to use DT for CPUs.

Signed-off-by: Magnus Damm <damm at opensource.se>
[horms+renesas at verge.net.au: Select USE_OF in Kconfig]
[horms+renesas at verge.net.au: Provide dt_compat in DT_MACHINE_START]
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

v3 [Simon Horman]
* Move r8a7779-marzen dts into a separate patch

v2 [Simon Horman]
* Select USE_OF in Kconfig
* Provide dt_compat in DT_MACHINE_START
* Provide r8a7779-marzen dts

v1 [Magnus Damm]
---
 arch/arm/mach-shmobile/Kconfig        | 1 +
 arch/arm/mach-shmobile/board-marzen.c | 8 +++++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 0130805..1f94c31 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -182,6 +182,7 @@ config MACH_MARZEN
 	depends on ARCH_R8A7779
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	select USE_OF
 
 config MACH_MARZEN_REFERENCE
 	bool "MARZEN board - Reference Device Tree Implementation"
diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c
index 1f57865..91f8751 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c
@@ -237,7 +237,12 @@ static void __init marzen_init(void)
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 
-MACHINE_START(MARZEN, "marzen")
+static const char *marzen_boards_compat_dt[] __initdata = {
+        "renesas,marzen",
+        NULL,
+};
+
+DT_MACHINE_START(MARZEN, "marzen")
 	.smp		= smp_ops(r8a7779_smp_ops),
 	.map_io		= r8a7779_map_io,
 	.init_early	= r8a7779_add_early_devices,
@@ -245,5 +250,6 @@ MACHINE_START(MARZEN, "marzen")
 	.init_irq	= r8a7779_init_irq,
 	.init_machine	= marzen_init,
 	.init_late	= r8a7779_init_late,
+	.dt_compat	= marzen_boards_compat_dt,
 	.init_time	= r8a7779_earlytimer_init,
 MACHINE_END
-- 
1.8.2.1



From cavokz at gmail.com  Thu Jul 25 21:00:19 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Fri, 26 Jul 2013 03:00:19 +0200
Subject: [PATCH v3 1/3] ARM: BCM5301X: initial support for the
 BCM5301X/BCM470X SoCs with ARM CPU
In-Reply-To: <1374792135-30343-2-git-send-email-hauke@hauke-m.de>
References: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
 <1374792135-30343-2-git-send-email-hauke@hauke-m.de>
Message-ID: <20130726010019.GC22296@glitch>

On Fri, Jul 26, 2013 at 12:42:13AM +0200, Hauke Mehrtens wrote:
> This patch adds support for the BCM5301X/BCM470X SoCs with an ARM CPUs.
> Currently just booting to a shell is working and nothing else, no
> Ethernet, wifi, flash, ...
> 
> This SoC is used in small office and home router with Broadcom SoCs.
> This code should support the BCM4707, BCM4708, BCM4709, BCM53010,
> BCM53011 and BCM53012 SoC. It uses one or two ARM Cortex A9
> Cores, some highlights are 2 PCIe 2.0 controllers, 4 Gigabit Ethernet
> MACs and a USB 3.0 host controller.
> 
> This SoC uses a dual core CPU, but this is currently not implemented.
> More information about this SoC can be found here:
> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers
> 
> Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
> ---
>  Documentation/devicetree/bindings/arm/bcm4708.txt |    8 +++
>  MAINTAINERS                                       |    8 +++
>  arch/arm/Makefile                                 |    2 +-
>  arch/arm/configs/multi_v7_defconfig               |    1 +
>  arch/arm/mach-bcm/Kconfig                         |   21 ++++++++
>  arch/arm/mach-bcm/Makefile                        |    1 +
>  arch/arm/mach-bcm/bcm5301x.c                      |   59 +++++++++++++++++++++
>  7 files changed, 99 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/bcm4708.txt
>  create mode 100644 arch/arm/mach-bcm/bcm5301x.c
> 
> diff --git a/Documentation/devicetree/bindings/arm/bcm4708.txt b/Documentation/devicetree/bindings/arm/bcm4708.txt
> new file mode 100644
> index 0000000..6b0f49f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/bcm4708.txt
> @@ -0,0 +1,8 @@
> +Broadcom BCM4708 device tree bindings
> +-------------------------------------------
> +
> +Boards with the BCM4708 SoC shall have the following properties:
> +
> +Required root node property:
> +
> +compatible = "brcm,bcm4708";
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bf61e04..b38f141 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1795,6 +1795,14 @@ F:	arch/arm/boot/dts/bcm2835*
>  F:	arch/arm/configs/bcm2835_defconfig
>  F:	drivers/*/*bcm2835*
>  
> +BROADCOM BCM5301X ARM ARCHICTURE
> +M:	Hauke Mehrtens <hauke at hauke-m.de>
> +L:	linux-arm-kernel at lists.infradead.org
> +S:	Maintained
> +F:	arch/arm/mach-bcm/bcm5301x.c
> +F:	arch/arm/boot/dts/bcm5301*
> +F:	arch/arm/boot/dts/bcm470*
> +
>  BROADCOM TG3 GIGABIT ETHERNET DRIVER
>  M:	Nithin Nayak Sujir <nsujir at broadcom.com>
>  M:	Michael Chan <mchan at broadcom.com>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index c0ac0f5..230b5d7 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
>  # Machine directory name.  This list is sorted alphanumerically
>  # by CONFIG_* macro name.
>  machine-$(CONFIG_ARCH_AT91)		+= at91
> -machine-$(CONFIG_ARCH_BCM)		+= bcm
> +machine-y				+= bcm
>  machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
>  machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
>  machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index fe0bdc3..f449bd7 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -6,6 +6,7 @@ CONFIG_ARCH_MVEBU=y
>  CONFIG_MACH_ARMADA_370=y
>  CONFIG_MACH_ARMADA_XP=y
>  CONFIG_ARCH_BCM=y
> +CONFIG_ARCH_BCM5301X=y
>  CONFIG_GPIO_PCA953X=y
>  CONFIG_ARCH_HIGHBANK=y
>  CONFIG_ARCH_KEYSTONE=y
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index f112895..979433b 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -17,3 +17,24 @@ config ARCH_BCM
>  	  It currently supports the 'BCM281XX' family, which includes
>  	  BCM11130, BCM11140, BCM11351, BCM28145 and
>  	  BCM28155 variants.
> +
> +config ARCH_BCM5301X
> +	bool "Broadcom BCM470X / BCM5301X ARM SoC"

should be

	bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7

or the entry will be visible also when no multi ARMv7 is wanted 

> +	select CPU_V7

not needed when ARCH_MULTI_V7 is configured and give issues if only
ARCH_MULTI_V6 is selected

> +	select ARM_GIC
> +	select HAVE_CLK
> +	select GENERIC_CLOCKEVENTS
> +	select GENERIC_TIME
> +	select ARM_GLOBAL_TIMER
> +	help
> +	  Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores.
> +
> +	  This is a network SoC line mostly used in home routers and
> +	  wifi access points.
> +	  This inclused the following SoC: BCM53010, BCM53011, BCM53012,
> +	  BCM53014, BCM53015, BCM53016, BCM53017, BCM53018, BCM4707,
> +	  BCM4708 and BCM4709.
> +
> +	  Do not confuse this with the BCM4760 which is a totally
> +	  different SoC or with the older BCM47XX and BCM53XX based
> +	  network SoC using a MIPS CPU, they are supported by arch/mips/bcm47xx
> diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> index 6adb6aec..b5b8046 100644
> --- a/arch/arm/mach-bcm/Makefile
> +++ b/arch/arm/mach-bcm/Makefile
> @@ -13,3 +13,4 @@
>  obj-$(CONFIG_ARCH_BCM)		:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
>  plus_sec := $(call as-instr,.arch_extension sec,+sec)
>  AFLAGS_bcm_kona_smc_asm.o	:=-Wa,-march=armv7-a$(plus_sec)
> +obj-$(CONFIG_ARCH_BCM5301X)	+= bcm5301x.o
> diff --git a/arch/arm/mach-bcm/bcm5301x.c b/arch/arm/mach-bcm/bcm5301x.c
> new file mode 100644
> index 0000000..5168f94
> --- /dev/null
> +++ b/arch/arm/mach-bcm/bcm5301x.c
> @@ -0,0 +1,59 @@
> +/*
> + * Broadcom BCM470X / BCM5301X ARM platform code.
> + *
> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> + *
> + * Licensed under the GNU/GPL. See COPYING for details.
> + */
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/irqchip.h>

not needed

> +#include <linux/clocksource.h>
> +#include <linux/clk-provider.h>
> +
> +#include <asm/mach/arch.h>
> +#include <asm/mach/map.h>
> +#include <asm/signal.h>
> +
> +static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
> +				 struct pt_regs *regs)
> +{
> +	/*
> +	 * These happen for no good reason, possibly left over from CFE
> +	 */
> +	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
> +		addr, fsr);
> +
> +	/* Returning non-zero causes fault display and panic */
> +	return 0;
> +}
> +
> +static void __init bcm5301x_init_early(void)
> +{
> +	/* Install our hook */
> +	hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, 0,
> +			"imprecise external abort");
> +}
> +
> +static void __init bcm5301x_map_io(void)
> +{
> +	debug_ll_io_init();
> +}

not needed, debug_ll_io_init() is already invoked when .map_io is not set
in the descriptor below.

> +
> +static void __init bcm5301x_timer_init(void)
> +{
> +	of_clk_init(NULL);
> +	clocksource_of_init();
> +}
> +
> +static const char const *bcm5301x_dt_compat[] = {

missing a __initconst

> +	"brcm,bcm4708",
> +	NULL,
> +};
> +
> +DT_MACHINE_START(BCM5301X, "BCM5301X")
> +	.init_early = bcm5301x_init_early,
> +	.map_io = bcm5301x_map_io,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^

> +	.init_time = bcm5301x_timer_init,
> +	.dt_compat = bcm5301x_dt_compat,
> +MACHINE_END
> -- 
> 1.7.10.4


From cavokz at gmail.com  Thu Jul 25 21:01:56 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Fri, 26 Jul 2013 03:01:56 +0200
Subject: [PATCH v3 3/3] ARM: BCM5301X: add dts files for BCM4708 SoC
In-Reply-To: <1374792135-30343-4-git-send-email-hauke@hauke-m.de>
References: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
 <1374792135-30343-4-git-send-email-hauke@hauke-m.de>
Message-ID: <20130726010156.GD22296@glitch>

On Fri, Jul 26, 2013 at 12:42:15AM +0200, Hauke Mehrtens wrote:
> This uses the newly added BCM5301X SoC code.
> 
> Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
> ---
>  arch/arm/boot/dts/Makefile                  |    1 +
>  arch/arm/boot/dts/bcm4708-netgear-r6250.dts |   20 ++++++++
>  arch/arm/boot/dts/bcm4708.dtsi              |   74 +++++++++++++++++++++++++++
>  3 files changed, 95 insertions(+)
>  create mode 100644 arch/arm/boot/dts/bcm4708-netgear-r6250.dts
>  create mode 100644 arch/arm/boot/dts/bcm4708.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 641b3c9..6329f2d 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -43,6 +43,7 @@ dtb-$(CONFIG_ARCH_AT91)	+= sama5d35ek.dtb
>  
>  dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
>  dtb-$(CONFIG_ARCH_BCM) += bcm11351-brt.dtb
> +dtb-$(CONFIG_ARCH_BCM5301X) += bcm4708-netgear-r6250.dtb
>  dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
>  	da850-evm.dtb
>  dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> new file mode 100644
> index 0000000..34875f6
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> @@ -0,0 +1,20 @@
> +/*
> + * Broadcom BCM470X / BCM5301X arm platform code.
> + *
> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> + *
> + * Licensed under the GNU/GPL. See COPYING for details.
> + */
> +
> +/dts-v1/;
> +
> +#include "bcm4708.dtsi"
> +
> +/ {
> +	compatible = "netgear,r6250v1", "brcm,bcm4708";
> +	model = "Netgear R6250 V1 (BCM4708)";
> +
> +	memory {
> +		reg = <0x00000000 0x08000000>;
> +	};
> +};
> diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
> new file mode 100644
> index 0000000..fbf1dcf
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm4708.dtsi
> @@ -0,0 +1,74 @@
> +/*
> + * Broadcom BCM470X / BCM5301X ARM platform code.
> + *
> + * Copyright 2013 Hauke Mehrtens <hauke at hauke-m.de>
> + *
> + * Licensed under the GNU/GPL. See COPYING for details.
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +#include "skeleton.dtsi"
> +
> +/ {
> +	compatible = "brcm,bcm4708";
> +	model = "Broadcom BCM4708";
> +	interrupt-parent = <&gic>;
> +
> +	chosen {
> +		bootargs = "console=ttyS0,115200 earlyprintk debug";

don't know if "earlyprintk debug" is appropriate here

> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a9";
> +			reg = <0>;
> +		};
> +	};
> +
> +	clocks {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		clk_periph: periph {
> +			compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-frequency = <400000000>;
> +		};
> +	};
> +
> +	uart at 18000300 {
> +		compatible = "ns16550";
> +		reg = <0x18000300 0x100>;
> +		interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
> +		clock-frequency = <100000000>;
> +	};
> +
> +	uart at 18000400 {
> +		compatible = "ns16550";
> +		reg = <0x18000400 0x100>;
> +		interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
> +		clock-frequency = <100000000>;
> +	};
> +
> +	gic: interrupt-controller at 19021000 {
> +		compatible = "arm,cortex-a9-gic";
> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +		interrupt-controller;
> +		reg = <0x19021000 0x1000>,
> +		      <0x19020100 0x100>;
> +	};
> +
> +	timer at 19020200 {
> +		compatible = "arm,cortex-a9-global-timer";
> +		reg = <0x19020200 0x100>;
> +		interrupts = <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&clk_periph>;
> +	};
> +};
> -- 
> 1.7.10.4


From gang.chen at asianux.com  Thu Jul 25 21:05:17 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Fri, 26 Jul 2013 09:05:17 +0800
Subject: [PATCH, re-send] Always trap on BUG()
In-Reply-To: <20130725220502.GI18254@gmail.com>
References: <201307051738.35930.arnd@arndb.de>
 <20130715151612.9499c2b2ad40e88d183a4600@linux-foundation.org>
 <20130715222755.GY24642@n2100.arm.linux.org.uk> <51E47924.9030005@zytor.com>
 <20130723093628.GC19786@gmail.com> <51EF1936.7090801@asianux.com>
 <20130725220502.GI18254@gmail.com>
Message-ID: <51F1CB4D.2020301@asianux.com>

On 07/26/2013 06:05 AM, Ingo Molnar wrote:
> * Chen Gang <gang.chen at asianux.com> wrote:
> 
>> On 07/23/2013 05:36 PM, Ingo Molnar wrote:
>>>
>>> (the crazies can keep a separate patch to remove even more of BUG() to win 
>>> a K or two.)
>>>
>>
>> Excuse me, my English is not quite well, I do not quite understand your
>> meaning, could you please repeat again in details or say more clearly ?
> 
> I meant: those people who'd like to have the tiny 
> additional space savings offered by !CONFIG_BUG (and are 
> crazy enough to live with non-determinism in exchange for a 
> measly payment of 1 KB), can apply a separate, out of tree 
> patch just fine and don't need upstream kernel support.
> 

Thank you for your reply in details.


Thanks
-- 
Chen Gang


From kuninori.morimoto.gx at renesas.com  Thu Jul 25 21:39:24 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Thu, 25 Jul 2013 18:39:24 -0700 (PDT)
Subject: [PATCH v2 1/2] ARM: shmobile: r8a7778: add HPB-DMAC support
In-Reply-To: <20130726001052.GA28912@verge.net.au>
References: <201307230218.01495.sergei.shtylyov@cogentembedded.com>
 <201307230222.04763.sergei.shtylyov@cogentembedded.com>
 <20130726001052.GA28912@verge.net.au>
Message-ID: <87a9lacd6o.wl%kuninori.morimoto.gx@renesas.com>


Hi

> > +static const struct hpb_dmae_slave_config hpb_dmae_slaves[] = {
> > +	{
> > +		.id	= HPBDMA_SLAVE_SDHI0_TX,
> > +		.addr	= 0xffe4c000 + 0x30,
> > +		.dcr	= DCR_SPDS_16BIT | DCR_DMDL | DCR_DPDS_16BIT,
> > +		.rstr	= ASYNCRSTR_ASRST21 | ASYNCRSTR_ASRST22 |
> > +			  ASYNCRSTR_ASRST23,
> > +		.mdr	= ASYNCMDR_ASMD21_SINGLE,
> > +		.mdm	= ASYNCMDR_ASMD21_MASK,
> > +		.port	= 0x0D0C,
> > +		.flags	= HPB_DMAE_SET_ASYNC_RESET | HPB_DMAE_SET_ASYNC_MODE,
> > +		.dma_ch	= 21,
> > +	}, {
> > +		.id	= HPBDMA_SLAVE_SDHI0_RX,
> > +		.addr	= 0xffe4c000 + 0x30,
> > +		.dcr	= DCR_SMDL | DCR_SPDS_16BIT | DCR_DPDS_16BIT,
> > +		.rstr	= ASYNCRSTR_ASRST21 | ASYNCRSTR_ASRST22 |
> > +			  ASYNCRSTR_ASRST23,
> > +		.mdr	= ASYNCMDR_ASMD22_SINGLE,
> > +		.mdm	= ASYNCMDR_ASMD22_MASK,
> > +		.port	= 0x0D0C,
> > +		.flags	= HPB_DMAE_SET_ASYNC_RESET | HPB_DMAE_SET_ASYNC_MODE,
> > +		.dma_ch	= 22,
> > +	},

I'm not sure detail of SDHI, but TX and RX are using same .port = 0x0D0C.
Is this correct ?
And what is 0x0C port ?
My datasheet doens't have it on Ch21 - Ch23

> > +static const struct hpb_dmae_channel hpb_dmae_channels[] = {
> > +	/* ch. 21 SD0 */
> > +	HPB_DMAE_CHANNEL(0x7e, HPBDMA_SLAVE_SDHI0_TX),
> > +	/* ch. 22 SD0 */
> > +	HPB_DMAE_CHANNEL(0x7e, HPBDMA_SLAVE_SDHI0_RX),
> > +};
> > +
> > +static struct hpb_dmae_pdata dma_platform_data __initdata = {
> > +	.slaves			= hpb_dmae_slaves,
> > +	.num_slaves		= ARRAY_SIZE(hpb_dmae_slaves),
> > +	.channels		= hpb_dmae_channels,
> > +	.num_channels		= ARRAY_SIZE(hpb_dmae_channels),
> > +	.ts_shift		= {
> > +		[XMIT_SZ_8BIT]	= 0,
> > +		[XMIT_SZ_16BIT]	= 1,
> > +		[XMIT_SZ_32BIT]	= 2,
> > +	},
> > +	.num_hw_channels	= 39,
> > +};

This is not a big deal, but according to .num_hw_channels,
we will have max 39 channels (or more over).

I want 1 line for 1 channels on hpb_dmae_channels.
like this

static const struct hpb_dmae_channel hpb_dmae_channels[] = {
	HPB_DMAE_CHANNEL(0x7e, HPBDMA_SLAVE_SDHI0_TX), /* ch21 */
	HPB_DMAE_CHANNEL(0x7e, HPBDMA_SLAVE_SDHI0_RX), /* ch22 */
}


Best regards
---
Kuninori Morimoto


From horms at verge.net.au  Thu Jul 25 22:38:39 2013
From: horms at verge.net.au (Simon Horman)
Date: Fri, 26 Jul 2013 11:38:39 +0900
Subject: [PATCH] ARM: shmobile: sh73a0: Rely on DT for SMP CPU info
In-Reply-To: <20130724072739.28333.44251.sendpatchset@w520>
References: <20130724072739.28333.44251.sendpatchset@w520>
Message-ID: <20130726023838.GC32490@verge.net.au>

On Wed, Jul 24, 2013 at 04:27:39PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> Remove sh73a0 specific ->smp_init_cpus() callback and
> instead of relying on shmobile_smp_init_cpus() simply
> use DT for CPU core information.
> 
> This assumes that DT_MACHINE_START is used which is
> the case when AG5EVM and Kota2 are removed.

And indeed they are queued-up for removal.

I have queued-up this patch for v3.12 in the dt2 branch.

> Signed-off-by: Magnus Damm <damm at opensource.se>
> ---
> 
>  arch/arm/mach-shmobile/smp-sh73a0.c |   11 ++---------
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> --- 0001/arch/arm/mach-shmobile/smp-sh73a0.c
> +++ work/arch/arm/mach-shmobile/smp-sh73a0.c	2013-07-24 15:59:16.000000000 +0900
> @@ -62,6 +62,8 @@ static int sh73a0_boot_secondary(unsigne
>  
>  static void __init sh73a0_smp_prepare_cpus(unsigned int max_cpus)
>  {
> +	/* setup sh73a0 specific SCU base */
> +	shmobile_scu_base = IOMEM(SH73A0_SCU_BASE);
>  	scu_enable(shmobile_scu_base);
>  
>  	/* Map the reset vector (in headsmp-scu.S, headsmp.S) */
> @@ -74,14 +76,6 @@ static void __init sh73a0_smp_prepare_cp
>  	scu_power_mode(shmobile_scu_base, SCU_PM_NORMAL);
>  }
>  
> -static void __init sh73a0_smp_init_cpus(void)
> -{
> -	/* setup sh73a0 specific SCU base */
> -	shmobile_scu_base = IOMEM(SH73A0_SCU_BASE);
> -
> -	shmobile_smp_init_cpus(scu_get_core_count(shmobile_scu_base));
> -}
> -
>  #ifdef CONFIG_HOTPLUG_CPU
>  static int sh73a0_cpu_kill(unsigned int cpu)
>  {
> @@ -120,7 +114,6 @@ static int sh73a0_cpu_disable(unsigned i
>  #endif /* CONFIG_HOTPLUG_CPU */
>  
>  struct smp_operations sh73a0_smp_ops __initdata = {
> -	.smp_init_cpus		= sh73a0_smp_init_cpus,
>  	.smp_prepare_cpus	= sh73a0_smp_prepare_cpus,
>  	.smp_boot_secondary	= sh73a0_boot_secondary,
>  #ifdef CONFIG_HOTPLUG_CPU
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From haojian.zhuang at gmail.com  Thu Jul 25 22:42:45 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 26 Jul 2013 10:42:45 +0800
Subject: [PATCH RESEND 1/2] clk: mmp: use global clock lock
In-Reply-To: <20130716181029.C08D8FAAF3@dev.laptop.org>
References: <20130716181029.C08D8FAAF3@dev.laptop.org>
Message-ID: <CAN1soZw7_3X5pdvp2M-Wp69=7Cr9bp4DDD0qMps4XT6u1s_9mQ@mail.gmail.com>

On Wed, Jul 17, 2013 at 2:10 AM, Daniel Drake <dsd at laptop.org> wrote:
> The mmp platform shares a lock between different clock types, and all
> clocks are currently initialized by static bindings.
>
> Move this static/private lock into global context so that it can
> easily be shared by clocks that will be defined by the device tree in
> followup patches.
>
> Signed-off-by: Daniel Drake <dsd at laptop.org>
> ---
>  drivers/clk/mmp/Makefile   |   2 +-
>  drivers/clk/mmp/clk-apbc.c |  38 +++++----------
>  drivers/clk/mmp/clk-apmu.c |  20 ++------
>  drivers/clk/mmp/clk-mmp2.c | 116 ++++++++++++++++++++++-----------------------
>  drivers/clk/mmp/clk.h      |   8 ++--
>  drivers/clk/mmp/common.c   |  13 +++++
>  6 files changed, 92 insertions(+), 105 deletions(-)
>  create mode 100644 drivers/clk/mmp/common.c
>
> Resending after a month without review.
>

Currently lock is defined in pxa910, pxa168 & mmp2 clock driver. Only
one of these driver
could be active in real system. So I can't see any benefit to use the
shared clock lock among
these three drivers.

Regards
Haojian


From tj at kernel.org  Thu Jul 25 23:08:12 2013
From: tj at kernel.org (Tejun Heo)
Date: Thu, 25 Jul 2013 23:08:12 -0400
Subject: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM
In-Reply-To: <51F1B17F.30902@ti.com>
References: <20130629152959.GB31339@mtj.dyndns.org>
 <20130629172123.GA3353@n2100.arm.linux.org.uk>
 <20130629175743.GA382@mtj.dyndns.org>
 <CAE9FiQXHuP-n0eZ9wN73V4nSvE+XEExDsx1t50_=YaW+V=LGLg@mail.gmail.com>
 <20130629195549.GE3353@n2100.arm.linux.org.uk>
 <CAE9FiQUoVNvWmmTV2+ZkU_nMxFToTHw6QLwp_Z_EjwMzqdLwuA@mail.gmail.com>
 <51D18DBA.6090608@ti.com> <51F1A7AA.8080700@ti.com>
 <20130725223658.GJ26107@mtj.dyndns.org> <51F1B17F.30902@ti.com>
Message-ID: <20130726030812.GB30195@mtj.dyndns.org>

Hello,

On Thu, Jul 25, 2013 at 07:15:11PM -0400, Santosh Shilimkar wrote:
> Sorry if I wasn't clear before, but I need help to at least have new
> memblock API support since I am not familiar with memblock code. 
> I could help in adaptation to the new API for ARM arch and
> core kernel code.
> 
> Let me know your thoughts.

Unfortunately, I'm currently a bit too occupied to work on it myself.
Any volunteers?

Thanks.

-- 
tejun


From festevam at gmail.com  Thu Jul 25 23:17:36 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 26 Jul 2013 00:17:36 -0300
Subject: [PATCH 2/2] ARM: mx53: Allow suspend/resume
In-Reply-To: <1374808656-28609-1-git-send-email-festevam@gmail.com>
References: <1374808656-28609-1-git-send-email-festevam@gmail.com>
Message-ID: <1374808656-28609-2-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Current imx53_pm_init() implementation is incomplete as it lacks calling
suspend_set_ops().

Use a single imx5_pm_init() function to handle both mx51 and mx53.

This allows mx53 to enter in low-power mode.

Tested on a mx53qsb:

root at freescale /$ echo mem > /sys/power/state 
PM: Syncing filesystems ... done.
mmc0: card e624 removed
Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Suspending console(s) (use no_console_suspend to debug)

... (Press Power button)

PM: suspend of devices complete after 17.067 msecs
PM: suspend devices took 0.020 seconds
PM: late suspend of devices complete after 0.954 msecs
PM: noirq suspend of devices complete after 1.288 msecs
Disabling non-boot CPUs ...
PM: noirq resume of devices complete after 0.680 msecs
PM: early resume of devices complete after 0.914 msecs
PM: resume of devices complete after 44.955 msecs
PM: resume devices took 0.050 seconds
Restarting tasks ... done.
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SDHC card at address e624
mmcblk0: mmc0:e624 SU04G 3.69 GiB 
 mmcblk0: p1 p2 p3
libphy: 63fec000.etherne:00 - Link is Down
libphy: 63fec000.etherne:00 - Link is Up - 100/Full
root at freescale /$ 

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/mach-imx/common.h  | 6 ++----
 arch/arm/mach-imx/mm-imx5.c | 4 ++--
 arch/arm/mach-imx/pm-imx5.c | 7 +------
 3 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index b96aff7..cdc9288 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -147,12 +147,10 @@ extern int imx_cpu_kill(unsigned int cpu);
 
 #ifdef CONFIG_PM
 extern void imx6q_pm_init(void);
-extern void imx51_pm_init(void);
-extern void imx53_pm_init(void);
+extern void imx5_pm_init(void);
 #else
 static inline void imx6q_pm_init(void) {}
-static inline void imx51_pm_init(void) {}
-static inline void imx53_pm_init(void) {}
+static inline void imx5_pm_init(void) {}
 #endif
 
 #ifdef CONFIG_NEON
diff --git a/arch/arm/mach-imx/mm-imx5.c b/arch/arm/mach-imx/mm-imx5.c
index cf193d8..a8229b7 100644
--- a/arch/arm/mach-imx/mm-imx5.c
+++ b/arch/arm/mach-imx/mm-imx5.c
@@ -153,10 +153,10 @@ void __init imx51_soc_init(void)
 void __init imx51_init_late(void)
 {
 	mx51_neon_fixup();
-	imx51_pm_init();
+	imx5_pm_init();
 }
 
 void __init imx53_init_late(void)
 {
-	imx53_pm_init();
+	imx5_pm_init();
 }
diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index 82e79c6..58aeaf5 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -169,14 +169,9 @@ static int __init imx5_pm_common_init(void)
 	return imx5_cpuidle_init();
 }
 
-void __init imx51_pm_init(void)
+void __init imx5_pm_init(void)
 {
 	int ret = imx5_pm_common_init();
 	if (!ret)
 		suspend_set_ops(&mx5_suspend_ops);
 }
-
-void __init imx53_pm_init(void)
-{
-	imx5_pm_common_init();
-}
-- 
1.8.1.2



From festevam at gmail.com  Thu Jul 25 23:17:35 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 26 Jul 2013 00:17:35 -0300
Subject: [PATCH 1/2] ARM: mach-imx: Select ARM_CPU_SUSPEND at ARCH_MXC level
Message-ID: <1374808656-28609-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Instead of selecting ARM_CPU_SUSPEND only for mx6, we can select it for 
all SoCs from the ARCH_MXC family.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/mach-imx/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index bb1cc9e..1cc219f 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -1,5 +1,6 @@
 config ARCH_MXC
 	bool "Freescale i.MX family" if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
+	select ARM_CPU_SUSPEND if PM
 	select ARCH_REQUIRE_GPIOLIB
 	select ARM_PATCH_PHYS_VIRT
 	select AUTO_ZRELADDR if !ZBOOT_ROM
@@ -786,7 +787,6 @@ config SOC_IMX6Q
 	bool "i.MX6 Quad/DualLite support"
 	select ARCH_HAS_CPUFREQ
 	select ARCH_HAS_OPP
-	select ARM_CPU_SUSPEND if PM
 	select ARM_ERRATA_754322
 	select ARM_ERRATA_764369 if SMP
 	select ARM_ERRATA_775420
-- 
1.8.1.2



From bjorn at kryo.se  Fri Jul 26 00:30:46 2013
From: bjorn at kryo.se (Bjorn Andersson)
Date: Thu, 25 Jul 2013 20:30:46 -0800
Subject: [PATCH 3/4] msm_serial: Make baud_code detection more dynamic
In-Reply-To: <1374691051-28544-4-git-send-email-sboyd@codeaurora.org>
References: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
 <1374691051-28544-4-git-send-email-sboyd@codeaurora.org>
Message-ID: <CAJAp7Og1jwyAn0sGbb_1Bk5_fvBWa1AuDNsRV1b17S0Tijk9kg@mail.gmail.com>

On Wed, Jul 24, 2013 at 10:37 AM, Stephen Boyd <sboyd at codeaurora.org> wrote:
> [snip]
> +       unsigned int i, divisor;
> +       const struct msm_baud_map *entry;
> +       static const struct msm_baud_map table[] = {
> +               { 1536, 0x00,  1 },
> +               {  768, 0x11,  1 },
> +               {  384, 0x22,  1 },
> +               {  192, 0x33,  1 },
> +               {   96, 0x44,  1 },
> +               {   48, 0x55,  1 },
> +               {   32, 0x66,  1 },
> +               {   24, 0x77,  1 },
> +               {   16, 0x88,  1 },
> +               {   12, 0x99,  6 },
> +               {    8, 0xaa,  6 },
> +               {    6, 0xbb,  6 },
> +               {    4, 0xcc,  6 },
> +               {    3, 0xdd,  8 },
> +               {    2, 0xee, 16 },
> +               {    1, 0xff, 31 },
> +       };
> +
> +       divisor = uart_get_divisor(port, baud);
> +
> +       for (i = 0, entry = table; i < ARRAY_SIZE(table); i++, entry++)
> +               if (entry->divisor <= divisor)
> +                       break;
> +
> +       return entry; /* Default to smallest divider */

Shouldn't matter, but you're not defaulting to the smallest divider.
Your are defaulting to an undefined value, as `entry` will be off the
array once i == ARRAY_SIZE().

Regards,
Bjorn


From haojian.zhuang at linaro.org  Fri Jul 26 00:32:11 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Fri, 26 Jul 2013 12:32:11 +0800
Subject: [PATCH v6 0/6] support Hisilicon SoC
Message-ID: <1374813135-16238-1-git-send-email-haojian.zhuang@linaro.org>

Changelog:
v6:
1. Remove hisilicon string from properties in clock driver.
2. Replace array by pointer in clock driver. Since only sctrl parent
   node exists at this time.

v5:
1. Remove HIWORD clk patches since they're merged into clk git tree.
2. Set hisilicon,clk-reset property of clkgate node is optional.
3. Update on commandline args in DTS file. Remove earlyprintk, mem, nfs.
4. Move gpio-keys out of amba node in DTS file.

v4:
1. Add clk gate with HIWORD mask for Rockchip.
2. Update comments and code of HIWORD flags for mux/divider.
3. Append a mux without HIWORD mask in Hisilicon 3620.
4. Fix the pinmux setting in Hi4511.

v3:
1. Use clk_register_mux_table().

v2:
1. Reuse mux & divider driver. So append CLK_MUX_HIWORD_MASK &
CLK_DIVIDER_HIWORD_MASK for Hi3620 SoC.
2. Fix system timer running too fast because wrong divider is choosen.
3. Remove .init_irq in DT machine descriptor.



From haojian.zhuang at linaro.org  Fri Jul 26 00:32:12 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Fri, 26 Jul 2013 12:32:12 +0800
Subject: [PATCH v6 1/4] clk: hi3xxx: add clock support
In-Reply-To: <1374813135-16238-1-git-send-email-haojian.zhuang@linaro.org>
References: <1374813135-16238-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <1374813135-16238-2-git-send-email-haojian.zhuang@linaro.org>

Add clock support with device tree on Hisilicon SoC.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
Cc: Mike Turquette <mturquette at linaro.org>
---
 .../devicetree/bindings/clock/hisilicon.txt        |  66 ++++
 drivers/clk/Makefile                               |   1 +
 drivers/clk/clk-hi3xxx.c                           | 398 +++++++++++++++++++++
 3 files changed, 465 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/hisilicon.txt
 create mode 100644 drivers/clk/clk-hi3xxx.c

diff --git a/Documentation/devicetree/bindings/clock/hisilicon.txt b/Documentation/devicetree/bindings/clock/hisilicon.txt
new file mode 100644
index 0000000..5d7a220
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hisilicon.txt
@@ -0,0 +1,66 @@
+Device Tree Clock bindings for arch-hi3xxx
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties for mux clocks:
+ - compatible : Shall be "hisilicon,hi3620-clk-mux".
+ - clocks : shall be the input parent clock phandle for the clock. This should
+	be the reference clock.
+ - clock-output-names : shall be reference name.
+ - #clock-cells : from common clock binding; shall be set to 0.
+ - clkmux-reg : array of mux register offset & mask bits
+ - clkmux-table : array of mux select bits
+
+Required properties for Hi3620 gate clocks:
+ - compatible : Shall be "hisilicon,hi3620-clk-gate".
+ - clocks : shall be the input parent clock phandle for the clock. This should
+	be the reference clock.
+ - clock-output-names : shall be reference name.
+ - #clock-cells : from common clock binding; shall be set to 0.
+ - hi3620-clkgate : array of enable register offset & enable bits
+ - hi3620-clkreset : array of reset register offset & enable bits
+
+Required properties for clock divider:
+ - compatible : Shall be "hisilicon,hi3620-clk-div".
+ - clocks : shall be the input parent clock phandle for the clock. This should
+	be the reference clock.
+ - clock-output-names : shall be reference name.
+ - #clock-cells : from common clock binding; shall be set to 0.
+ - #clkdiv-table-cells : the number of parameters after phandle in
+   clkdiv-table property.
+ - clkdiv-table : list of value that are used to configure clock
+   divider. They're value of phandle, index & divider value.
+ - clkdiv : array of divider register offset & mask bits.
+
+Required properties for gate clocks:
+ - compatible : Shall be "hisilicon,clk-gate".
+ - clocks : shall be the input parent clock phandle for the clock. This should
+	be the reference clock.
+ - clock-output-names : shall be reference name.
+ - #clock-cells : from common clock binding; shall be set to 0.
+ - clkgate-inverted : bool value. True means that set-to-disable.
+
+For example:
+	timclk1: clkgate at 38 {
+		compatible = "hisilicon,clk-gate";
+		#clock-cells = <0>;
+		clocks = <&refclk_timer1>;
+		clock-output-names = "timclk1";
+		clkgate-inverted;
+		clkgate = <0 18>;
+	};
+
+	dtable: clkdiv at 0 {
+		#clkdiv-table-cells = <2>;
+	};
+
+	div_cfgaxi: clkdiv at 2 {
+		compatible = "hisilicon,hi3620-clk-div";
+		#clock-cells = <0>;
+		clocks = <&div_shareaxi>;
+		clock-output-names = "cfgAXI_div";
+		clkdiv-table = <&dtable 0x01 2>;
+		clkdiv = <0x100 0x60>;
+	};
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4038c2b..21076ee 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK)	+= clk-composite.o
 # SoCs specific
 obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
 obj-$(CONFIG_ARCH_NOMADIK)	+= clk-nomadik.o
+obj-$(CONFIG_ARCH_HI3xxx)	+= clk-hi3xxx.o
 obj-$(CONFIG_ARCH_HIGHBANK)	+= clk-highbank.o
 obj-$(CONFIG_ARCH_NSPIRE)	+= clk-nspire.o
 obj-$(CONFIG_ARCH_MXS)		+= mxs/
diff --git a/drivers/clk/clk-hi3xxx.c b/drivers/clk/clk-hi3xxx.c
new file mode 100644
index 0000000..3b041fd
--- /dev/null
+++ b/drivers/clk/clk-hi3xxx.c
@@ -0,0 +1,398 @@
+/*
+ * Hisilicon clock driver
+ *
+ * Copyright (c) 2012-2013 Hisilicon Limited.
+ * Copyright (c) 2012-2013 Linaro Limited.
+ *
+ * Author: Haojian Zhuang <haojian.zhuang at linaro.org>
+ *	   Xin Li <li.xin at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/clk-provider.h>
+#include <linux/clk-private.h>
+#include <linux/clkdev.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/slab.h>
+#include <linux/clk.h>
+
+#define HI3620_DISABLE_OFF		0x4
+#define HI3620_STATUS_OFF		0x8
+
+struct hi3620_periclk {
+	struct clk_hw	hw;
+	void __iomem	*enable;	/* enable register */
+	void __iomem	*reset;		/* reset register */
+	u32		ebits;		/* bits in enable/disable register */
+	u32		rbits;		/* bits in reset/unreset register */
+	spinlock_t	*lock;
+};
+
+static void __iomem *hi3xxx_clk_base = NULL;
+
+static DEFINE_SPINLOCK(hi3xxx_clk_lock);
+
+static const struct of_device_id hi3xxx_of_match[] = {
+	{ .compatible = "hisilicon,sctrl" },
+};
+
+static void __iomem __init *hi3xxx_init_clocks(struct device_node *np)
+{
+	struct device_node *parent;
+	const struct of_device_id *match;
+	void __iomem *ret = NULL;
+
+	parent = of_get_parent(np);
+	if (!parent) {
+		pr_warn("Can't find parent node of these clocks\n");
+		goto out;
+	}
+	match = of_match_node(hi3xxx_of_match, parent);
+	if (!match) {
+		pr_warn("Can't find the right parent\n");
+		goto out;
+	}
+
+	if (!hi3xxx_clk_base) {
+		ret = of_iomap(parent, 0);
+		WARN_ON(!ret);
+		hi3xxx_clk_base = ret;
+	} else {
+		ret = hi3xxx_clk_base;
+	}
+out:
+	return ret;
+}
+
+static int hi3620_clkgate_prepare(struct clk_hw *hw)
+{
+	struct hi3620_periclk *pclk;
+	unsigned long flags = 0;
+
+	pclk = container_of(hw, struct hi3620_periclk, hw);
+
+	if (pclk->lock)
+		spin_lock_irqsave(pclk->lock, flags);
+	if (pclk->reset) {
+		writel_relaxed(pclk->rbits, pclk->reset + HI3620_DISABLE_OFF);
+		readl_relaxed(pclk->reset + HI3620_STATUS_OFF);
+	}
+	if (pclk->lock)
+		spin_unlock_irqrestore(pclk->lock, flags);
+	return 0;
+}
+
+static int hi3620_clkgate_enable(struct clk_hw *hw)
+{
+	struct hi3620_periclk *pclk;
+	unsigned long flags = 0;
+
+	pclk = container_of(hw, struct hi3620_periclk, hw);
+	if (pclk->lock)
+		spin_lock_irqsave(pclk->lock, flags);
+	writel_relaxed(pclk->ebits, pclk->enable);
+	readl_relaxed(pclk->enable + HI3620_STATUS_OFF);
+	if (pclk->lock)
+		spin_unlock_irqrestore(pclk->lock, flags);
+	return 0;
+}
+
+static void hi3620_clkgate_disable(struct clk_hw *hw)
+{
+	struct hi3620_periclk *pclk;
+	unsigned long flags = 0;
+
+	pclk = container_of(hw, struct hi3620_periclk, hw);
+	if (pclk->lock)
+		spin_lock_irqsave(pclk->lock, flags);
+	writel_relaxed(pclk->ebits, pclk->enable + HI3620_DISABLE_OFF);
+	readl_relaxed(pclk->enable + HI3620_STATUS_OFF);
+	if (pclk->lock)
+		spin_unlock_irqrestore(pclk->lock, flags);
+}
+
+static struct clk_ops hi3620_clkgate_ops = {
+	.prepare	= hi3620_clkgate_prepare,
+	.enable		= hi3620_clkgate_enable,
+	.disable	= hi3620_clkgate_disable,
+};
+
+static void __init hi3620_clkgate_setup(struct device_node *np)
+{
+	struct hi3620_periclk *pclk;
+	struct clk_init_data *init;
+	struct clk *clk;
+	const char *clk_name, *name, **parent_names;
+	u32 rdata[2], gdata[2];
+	void __iomem *base;
+
+	base = hi3xxx_init_clocks(np);
+	if (!base)
+		return;
+
+	if (of_property_read_string(np, "clock-output-names", &clk_name))
+		return;
+	if (of_property_read_u32_array(np, "hi3620-clkgate",
+				       &gdata[0], 2))
+		return;
+
+	/* gate only has the fixed parent */
+	parent_names = kzalloc(sizeof(char *), GFP_KERNEL);
+	if (!parent_names)
+		return;
+	parent_names[0] = of_clk_get_parent_name(np, 0);
+
+	pclk = kzalloc(sizeof(*pclk), GFP_KERNEL);
+	if (!pclk)
+		goto err_pclk;
+
+	init = kzalloc(sizeof(*init), GFP_KERNEL);
+	if (!init)
+		goto err_init;
+	init->name = kstrdup(clk_name, GFP_KERNEL);
+	init->ops = &hi3620_clkgate_ops;
+	init->flags = CLK_SET_RATE_PARENT;
+	init->parent_names = parent_names;
+	init->num_parents = 1;
+
+	if (!of_property_read_u32_array(np, "hi3620-clkreset",
+					&rdata[0], 2)) {
+		pclk->reset = base + rdata[0];
+		pclk->rbits = rdata[1];
+	}
+	pclk->enable = base + gdata[0];
+	pclk->ebits = gdata[1];
+	pclk->lock = &hi3xxx_clk_lock;
+	pclk->hw.init = init;
+
+	clk = clk_register(NULL, &pclk->hw);
+	if (IS_ERR(clk))
+		goto err_clk;
+	if (!of_property_read_string(np, "clock-names", &name))
+		clk_register_clkdev(clk, name, NULL);
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	return;
+err_clk:
+	kfree(init);
+err_init:
+	kfree(pclk);
+err_pclk:
+	kfree(parent_names);
+}
+CLK_OF_DECLARE(hi3620_gate, "hisilicon,hi3620-clk-gate", hi3620_clkgate_setup)
+
+static int __init hi3xxx_parse_mux(struct device_node *np,
+				   u8 *num_parents,
+				   u32 *table)
+{
+	int i, cnt, ret;
+
+	/* get the count of items in mux */
+	for (i = 0, cnt = 0; ; i++, cnt++) {
+		/* parent's #clock-cells property is always 0 */
+		if (!of_parse_phandle(np, "clocks", i))
+			break;
+	}
+
+	for (i = 0; i < cnt; i++) {
+		if (!of_clk_get_parent_name(np, i))
+			return -ENOENT;
+	}
+	*num_parents = cnt;
+	table = kzalloc(sizeof(u32 *) * cnt, GFP_KERNEL);
+	if (!table)
+		return -ENOMEM;
+	ret = of_property_read_u32_array(np, "clkmux-table",
+					 table, cnt);
+	if (ret)
+		goto err;
+	return 0;
+err:
+	kfree(table);
+	return ret;
+}
+
+static void __init clkmux_setup(struct device_node *np, int mode)
+{
+	struct clk *clk;
+	const char *clk_name, **parent_names = NULL;
+	u32 rdata[2], mask, *table = NULL;
+	u8 num_parents, shift, clk_mux_flags = 0;
+	void __iomem *reg, *base;
+	int i, ret;
+
+	base = hi3xxx_init_clocks(np);
+	if (!base)
+		return;
+
+	if (of_property_read_string(np, "clock-output-names", &clk_name))
+		return;
+	if (of_property_read_u32_array(np, "clkmux-reg",
+				       &rdata[0], 2))
+		return;
+	ret = hi3xxx_parse_mux(np, &num_parents, table);
+	if (ret)
+		return;
+
+	parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
+	if (!parent_names)
+		goto err;
+	for (i = 0; i < num_parents; i++)
+		parent_names[i] = of_clk_get_parent_name(np, i);
+
+	reg = base + rdata[0];
+	shift = ffs(rdata[1]) - 1;
+	mask = rdata[1] >> shift;
+	if (mode)
+		clk_mux_flags = CLK_MUX_HIWORD_MASK;
+	clk = clk_register_mux_table(NULL, clk_name, parent_names, num_parents,
+				     CLK_SET_RATE_PARENT, reg, shift, mask,
+				     clk_mux_flags, table, &hi3xxx_clk_lock);
+	if (IS_ERR(clk))
+		goto err_clk;
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+
+	return;
+err_clk:
+	kfree(parent_names);
+err:
+	kfree(table);
+}
+
+static void __init hi3620_clkmux_setup(struct device_node *np)
+{
+	clkmux_setup(np, 1);
+}
+CLK_OF_DECLARE(hi3620_mux, "hisilicon,hi3620-clk-mux", hi3620_clkmux_setup)
+
+static void __init hi3xxx_clkmux_setup(struct device_node *np)
+{
+	clkmux_setup(np, 0);
+}
+CLK_OF_DECLARE(hi3xxx_mux, "hisilicon,clk-mux", hi3xxx_clkmux_setup)
+
+static void __init hs_clkgate_setup(struct device_node *np)
+{
+	struct clk *clk;
+	const char *clk_name, **parent_names, *name;
+	unsigned long flags = 0;
+	u32 data[2];
+	void __iomem *base;
+
+	base = hi3xxx_init_clocks(np);
+	if (!base)
+		return;
+	if (of_property_read_string(np, "clock-output-names", &clk_name))
+		return;
+	if (of_property_read_u32_array(np, "clkgate",
+				       &data[0], 2))
+		return;
+	if (of_property_read_bool(np, "clkgate-inverted"))
+		flags = CLK_GATE_SET_TO_DISABLE;
+	/* gate only has the fixed parent */
+	parent_names = kzalloc(sizeof(char *), GFP_KERNEL);
+	if (!parent_names)
+		return;
+	parent_names[0] = of_clk_get_parent_name(np, 0);
+
+	clk = clk_register_gate(NULL, clk_name, parent_names[0], 0,
+				base + data[0], (u8)data[1], flags,
+				&hi3xxx_clk_lock);
+	if (IS_ERR(clk))
+		goto err;
+	if (!of_property_read_string(np, "clock-names", &name))
+		clk_register_clkdev(clk, name, NULL);
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	return;
+err:
+	kfree(parent_names);
+}
+CLK_OF_DECLARE(hs_gate, "hisilicon,clk-gate", hs_clkgate_setup)
+
+void __init hi3620_clkdiv_setup(struct device_node *np)
+{
+	struct clk *clk;
+	const char *clk_name, **parent_names;
+	struct clk_div_table *table;
+	unsigned int table_num;
+	int i;
+	u32 data[2];
+	u8 shift, width;
+	const char *propname = "clkdiv-table";
+	const char *cellname = "#clkdiv-table-cells";
+	struct of_phandle_args div_table;
+	void __iomem *reg, *base;
+
+	base = hi3xxx_init_clocks(np);
+	if (!base)
+		return;
+
+	if (of_property_read_string(np, "clock-output-names", &clk_name))
+		return;
+	if (of_property_read_u32_array(np, "clkdiv", &data[0], 2))
+		return;
+
+	/*process the div_table*/
+	for (i = 0; ; i++) {
+		if (of_parse_phandle_with_args(np, propname, cellname,
+					       i, &div_table))
+			break;
+	}
+
+	/*table ends with <0, 0>, so plus one to table_num*/
+	table_num = i + 1;
+
+	table = kzalloc(sizeof(struct clk_div_table) * table_num, GFP_KERNEL);
+	if (!table)
+		return ;
+
+	for (i = 0; ; i++) {
+		if (of_parse_phandle_with_args(np, propname, cellname,
+					       i, &div_table))
+			break;
+
+		table[i].val = div_table.args[0];
+		table[i].div = div_table.args[1];
+	}
+
+	/* gate only has the fixed parent */
+	parent_names = kzalloc(sizeof(char *), GFP_KERNEL);
+	if (!parent_names)
+		goto err_par;
+	parent_names[0] = of_clk_get_parent_name(np, 0);
+	reg = base + data[0];
+	shift = ffs(data[1]) - 1;
+	width = fls(data[1]) - ffs(data[1]) + 1;
+	clk = clk_register_divider_table(NULL, clk_name, parent_names[0], 0,
+					 reg, shift, width,
+					 CLK_DIVIDER_HIWORD_MASK,
+					 table, &hi3xxx_clk_lock);
+	if (IS_ERR(clk))
+		goto err_clk;
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	return;
+err_clk:
+	kfree(parent_names);
+err_par:
+	kfree(table);
+}
+CLK_OF_DECLARE(hi3620_div, "hisilicon,hi3620-clk-div", hi3620_clkdiv_setup)
-- 
1.8.1.2



From haojian.zhuang at linaro.org  Fri Jul 26 00:32:13 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Fri, 26 Jul 2013 12:32:13 +0800
Subject: [PATCH v6 2/4] ARM: debug: support debug ll on hisilicon soc
In-Reply-To: <1374813135-16238-1-git-send-email-haojian.zhuang@linaro.org>
References: <1374813135-16238-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <1374813135-16238-3-git-send-email-haojian.zhuang@linaro.org>

Support UART0 debug ll on hisilicon Hi3620 SoC.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 arch/arm/Kconfig.debug             | 15 +++++++++++++++
 arch/arm/include/debug/hisilicon.S | 30 ++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+)
 create mode 100644 arch/arm/include/debug/hisilicon.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e401a76..289a248 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -272,6 +272,20 @@ choice
 		  Say Y here if you want the debug print routines to direct
 		  their output to UART1 serial port on KEYSTONE2 devices.
 
+	config DEBUG_HI3620_UART
+		bool "Hisilicon HI3620 Debug UART"
+		depends on ARCH_HI3xxx
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on HI3620 UART.
+
+	config DEBUG_HI3716_UART
+		bool "Hisilicon Hi3716 Debug UART"
+		depends on ARCH_HI3xxx
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on HI3716 UART.
+
 	config DEBUG_MMP_UART2
 		bool "Kernel low-level debugging message via MMP UART2"
 		depends on ARCH_MMP
@@ -765,6 +779,7 @@ config DEBUG_LL_INCLUDE
 	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
 	default "debug/exynos.S" if DEBUG_EXYNOS_UART
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART
+	default "debug/hisilicon.S" if DEBUG_HI3620_UART || DEBUG_HI3716_UART
 	default "debug/icedcc.S" if DEBUG_ICEDCC
 	default "debug/imx.S" if DEBUG_IMX1_UART || \
 				 DEBUG_IMX25_UART || \
diff --git a/arch/arm/include/debug/hisilicon.S b/arch/arm/include/debug/hisilicon.S
new file mode 100644
index 0000000..47ad019
--- /dev/null
+++ b/arch/arm/include/debug/hisilicon.S
@@ -0,0 +1,30 @@
+/*
+ * Early serial output macro for Hisilicon SoC
+ *
+ * Copyright (C) 2012-2013 Hisilicon Technologies Co., Ltd.
+ * Copyright (C) 2012-2013 Linaro Ltd.
+ *
+ * Author: Haojian Zhuang <haojian.zhuang at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#if defined(CONFIG_DEBUG_HI3620_UART)
+#define HS_UART_PHYS_BASE	0xfcb00000
+#define HS_UART_VIRT_BASE	0xfeb00000
+#elif defined(CONFIG_DEBUG_HI3716_UART)
+#define HS_UART_PHYS_BASE	0xf8b00000
+#define HS_UART_VIRT_BASE	0xfeb00000
+#endif
+
+#if defined(CONFIG_DEBUG_HI3620_UART) || defined(CONFIG_DEBUG_HI3716_UART)
+		.macro	addruart,rp,rv,tmp
+		ldr	\rp, =HS_UART_PHYS_BASE
+		ldr	\rv, =HS_UART_VIRT_BASE
+		.endm
+
+#include <asm/hardware/debug-pl01x.S>
+
+#endif
-- 
1.8.1.2



From haojian.zhuang at linaro.org  Fri Jul 26 00:32:14 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Fri, 26 Jul 2013 12:32:14 +0800
Subject: [PATCH v6 3/4] ARM: hi3xxx: add board support with device tree
In-Reply-To: <1374813135-16238-1-git-send-email-haojian.zhuang@linaro.org>
References: <1374813135-16238-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <1374813135-16238-4-git-send-email-haojian.zhuang@linaro.org>

Add board support with device tree for Hisilicon Hi36xx/Hi37xx platform.

Changelog:
v3:
1. Remove .map_io() in DT machine descriptor. Since debug_ll_io_init()
is called by default.
2. Remove .init_machine() in DT machine descriptor. Since
of_platform_populate() is called by default in DT mode.

v2:
1. Remove .init_irq() in DT machine descriptor. Since irqchip_init()
is called by default in DT mode.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 .../bindings/arm/hisilicon/hisilicon.txt           | 10 ++++++
 arch/arm/Kconfig                                   |  2 ++
 arch/arm/Makefile                                  |  1 +
 arch/arm/mach-hi3xxx/Kconfig                       | 13 ++++++++
 arch/arm/mach-hi3xxx/Makefile                      |  5 +++
 arch/arm/mach-hi3xxx/hi3xxx.c                      | 36 ++++++++++++++++++++++
 6 files changed, 67 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
 create mode 100644 arch/arm/mach-hi3xxx/Kconfig
 create mode 100644 arch/arm/mach-hi3xxx/Makefile
 create mode 100644 arch/arm/mach-hi3xxx/hi3xxx.c

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
new file mode 100644
index 0000000..3be60c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -0,0 +1,10 @@
+Hisilicon Platforms Device Tree Bindings
+----------------------------------------------------
+
+Hi3716 Development Board
+Required root node properties:
+	- compatible = "hisilicon,hi3716-dkb";
+
+Hi4511 Board
+Required root node properties:
+	- compatible = "hisilicon,hi3620-hi4511";
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..29e119d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -944,6 +944,8 @@ source "arch/arm/mach-footbridge/Kconfig"
 
 source "arch/arm/mach-gemini/Kconfig"
 
+source "arch/arm/mach-hi3xxx/Kconfig"
+
 source "arch/arm/mach-highbank/Kconfig"
 
 source "arch/arm/mach-integrator/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c0ac0f5..bc69205 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -154,6 +154,7 @@ machine-$(CONFIG_ARCH_DOVE)		+= dove
 machine-$(CONFIG_ARCH_EBSA110)		+= ebsa110
 machine-$(CONFIG_ARCH_EP93XX)		+= ep93xx
 machine-$(CONFIG_ARCH_GEMINI)		+= gemini
+machine-$(CONFIG_ARCH_HI3xxx)		+= hi3xxx
 machine-$(CONFIG_ARCH_HIGHBANK)		+= highbank
 machine-$(CONFIG_ARCH_INTEGRATOR)	+= integrator
 machine-$(CONFIG_ARCH_IOP13XX)		+= iop13xx
diff --git a/arch/arm/mach-hi3xxx/Kconfig b/arch/arm/mach-hi3xxx/Kconfig
new file mode 100644
index 0000000..a991dee
--- /dev/null
+++ b/arch/arm/mach-hi3xxx/Kconfig
@@ -0,0 +1,13 @@
+config ARCH_HI3xxx
+	bool "Hisilicon Hi36xx/Hi37xx family" if ARCH_MULTI_V7
+	select ARM_AMBA
+	select ARM_GIC
+	select CACHE_L2X0
+	select CACHE_PL310
+	select CLKSRC_OF
+	select PINCTRL
+	select PINCTRL_SINGLE
+	select SERIAL_AMBA_PL011
+	select SERIAL_AMBA_PL011_CONSOLE
+	help
+	  Support for Hisilicon Hi36xx/Hi37xx processor family
diff --git a/arch/arm/mach-hi3xxx/Makefile b/arch/arm/mach-hi3xxx/Makefile
new file mode 100644
index 0000000..d68ebb3
--- /dev/null
+++ b/arch/arm/mach-hi3xxx/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for Hisilicon Hi36xx/Hi37xx processors line
+#
+
+obj-y	+= hi3xxx.o
diff --git a/arch/arm/mach-hi3xxx/hi3xxx.c b/arch/arm/mach-hi3xxx/hi3xxx.c
new file mode 100644
index 0000000..e7c54bc
--- /dev/null
+++ b/arch/arm/mach-hi3xxx/hi3xxx.c
@@ -0,0 +1,36 @@
+/*
+ * (Hisilicon's Hi36xx/Hi37xx SoC based) flattened device tree enabled machine
+ *
+ * Copyright (c) 2012-2013 Hisilicon Ltd.
+ * Copyright (c) 2012-2013 Linaro Ltd.
+ *
+ * Author: Haojian Zhuang <haojian.zhuang at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include <linux/clk-provider.h>
+#include <linux/clocksource.h>
+#include <linux/irqchip.h>
+#include <linux/of_platform.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+
+static void __init hi3xxx_timer_init(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+static const char *hs_compat[] __initdata = {
+	"hisilicon,hi3620-hi4511",
+	NULL,
+};
+
+DT_MACHINE_START(HI3xxx, "Hisilicon Hi36xx/Hi37xx (Flattened Device Tree)")
+	.init_time	= hi3xxx_timer_init,
+	.dt_compat	= hs_compat,
+MACHINE_END
-- 
1.8.1.2



From haojian.zhuang at linaro.org  Fri Jul 26 00:32:15 2013
From: haojian.zhuang at linaro.org (Haojian Zhuang)
Date: Fri, 26 Jul 2013 12:32:15 +0800
Subject: [PATCH v6 4/4] ARM: hi3xxx: enable hi4511 with device tree
In-Reply-To: <1374813135-16238-1-git-send-email-haojian.zhuang@linaro.org>
References: <1374813135-16238-1-git-send-email-haojian.zhuang@linaro.org>
Message-ID: <1374813135-16238-5-git-send-email-haojian.zhuang@linaro.org>

Enable Hisilicon Hi4511 development platform with device tree support.

Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
---
 arch/arm/boot/dts/Makefile          |    1 +
 arch/arm/boot/dts/hi3620.dtsi       | 1147 +++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/hi4511.dts        |  648 ++++++++++++++++++++
 arch/arm/configs/multi_v7_defconfig |    1 +
 4 files changed, 1797 insertions(+)
 create mode 100644 arch/arm/boot/dts/hi3620.dtsi
 create mode 100644 arch/arm/boot/dts/hi4511.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..6e7c1ca 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -61,6 +61,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
 	exynos5250-snow.dtb \
 	exynos5420-smdk5420.dtb \
 	exynos5440-ssdk5440.dtb
+dtb-$(CONFIG_ARCH_HI3xxx) += hi4511.dtb
 dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
 	ecx-2000.dtb
 dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \
diff --git a/arch/arm/boot/dts/hi3620.dtsi b/arch/arm/boot/dts/hi3620.dtsi
new file mode 100644
index 0000000..aca09ad
--- /dev/null
+++ b/arch/arm/boot/dts/hi3620.dtsi
@@ -0,0 +1,1147 @@
+/*
+ * Hisilicon Ltd. Hi3620 SoC
+ *
+ * Copyright (C) 2012-2013 Hisilicon Ltd.
+ * Copyright (C) 2012-2013 Linaro Ltd.
+ *
+ * Author: Haojian Zhuang <haojian.zhuang at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * publishhed by the Free Software Foundation.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+	};
+
+	osc32k: osc at 0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <32768>;
+		clock-output-names = "osc32khz";
+	};
+	osc26m: osc at 1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <26000000>;
+		clock-output-names = "osc26mhz";
+	};
+	pclk: clk at 0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <26000000>;
+		clock-output-names = "apb_pclk";
+	};
+	pll_arm0: clk at 1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1600000000>;
+		clock-output-names = "armpll0";
+	};
+	pll_arm1: clk at 2 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1600000000>;
+		clock-output-names = "armpll1";
+	};
+	pll_peri: clk at 3 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1440000000>;
+		clock-output-names = "armpll2";
+	};
+	pll_usb: clk at 4 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1440000000>;
+		clock-output-names = "armpll3";
+	};
+	pll_hdmi: clk at 5 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1188000000>;
+		clock-output-names = "armpll4";
+	};
+	pll_gpu: clk at 6 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1300000000>;
+		clock-output-names = "armpll5";
+	};
+
+	amba {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "arm,amba-bus";
+		interrupt-parent = <&intc>;
+		ranges;
+
+		pmctrl: pmctrl at fca08000 {
+			compatible = "hisilicon,pmctrl";
+			reg = <0xfca08000 0x1000>;
+		};
+
+		sctrl: sctrl at fc802000 {
+			compatible = "hisilicon,sctrl";
+			reg = <0xfc802000 0x1000>;
+
+			uart0_mux: uart0_mux {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &pclk>;
+				clock-output-names = "uart0_mux";
+				/* reg_offset, mask bits */
+				clkmux-reg = <0x100 0x80>;
+				/* each item value */
+				clkmux-table = <0 0x80>;
+			};
+			uart1_mux: uart1_mux {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &pclk>;
+				clock-output-names = "uart1_mux";
+				clkmux-reg = <0x100 0x100>;
+				clkmux-table = <0x0 0x100>;
+			};
+			uart2_mux: uart2_mux {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &pclk>;
+				clock-output-names = "uart2_mux";
+				clkmux-reg = <0x100 0x200>;
+				clkmux-table = <0 0x200>;
+			};
+			uart3_mux: uart3_mux {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &pclk>;
+				clock-output-names = "uart3_mux";
+				clkmux-reg = <0x100 0x400>;
+				clkmux-table = <0 0x400>;
+			};
+			uart4_mux: uart4_mux {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &pclk>;
+				clock-output-names = "uart4_mux";
+				clkmux-reg = <0x100 0x800>;
+				clkmux-table = <0 0x800>;
+			};
+			rclk_cfgaxi: rclk_cfgaxi {
+				compatible = "fixed-factor-clock";
+				#clock-cells = <0>;
+				clocks = <&pll_peri>;
+				clock-output-names = "rclk_cfgaxi";
+				clock-mult = <1>;
+				clock-div = <30>;
+			};
+			spi0_mux: spi0_mux {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &rclk_cfgaxi>;
+				clock-output-names = "spi0_mux";
+				clkmux-reg = <0x100 0x1000>;
+				clkmux-table = <0 0x1000>;
+			};
+			spi1_mux: spi1_mux {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &rclk_cfgaxi>;
+				clock-output-names = "spi1_mux";
+				clkmux-reg = <0x100 0x2000>;
+				clkmux-table = <0 0x2000>;
+			};
+			spi2_mux: spi2_mux {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc26m &rclk_cfgaxi>;
+				clock-output-names = "spi2_mux";
+				clkmux-reg = <0x100 0x4000>;
+				clkmux-table = <0 0x4000>;
+			};
+			pwm0_mux: pwm0_mux {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &osc26m>;
+				clock-output-names = "pwm0_mux";
+				clkmux-reg = <0x104 0x400>;
+				clkmux-table = <0 0x400>;
+			};
+			pwm1_mux: pwm1_mux {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &osc26m>;
+				clock-output-names = "pwm1_mux";
+				clkmux-reg = <0x104 0x800>;
+				clkmux-table = <0 0x800>;
+			};
+			timer0_mux: timer0_mux {
+				compatible = "hisilicon,clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk01>;
+				clock-output-names = "timer0_mux";
+				clkmux-reg = <0 0x8000>;
+				clkmux-table = <0 0x8000>;
+			};
+			timer1_mux: timer1_mux {
+				compatible = "hisilicon,clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk01>;
+				clock-output-names = "timer1_mux";
+				clkmux-reg = <0 0x20000>;
+				clkmux-table = <0 0x20000>;
+			};
+			timer2_mux: timer2_mux {
+				compatible = "hisilicon,clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk23>;
+				clock-output-names = "timer2_mux";
+				clkmux-reg = <0 0x80000>;
+				clkmux-table = <0 0x80000>;
+			};
+			timer3_mux: timer3_mux {
+				compatible = "hisilicon,clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk23>;
+				clock-output-names = "timer3_mux";
+				clkmux-reg = <0 0x200000>;
+				clkmux-table = <0 0x200000>;
+			};
+			timer4_mux: timer4_mux {
+				compatible = "hisilicon,clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk45>;
+				clock-output-names = "timer4_mux";
+				clkmux-reg = <0x18 0x1>;
+				clkmux-table = <0 0x1>;
+			};
+			timer5_mux: timer5_mux {
+				compatible = "hisilicon,clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk45>;
+				clock-output-names = "timer5_mux";
+				clkmux-reg = <0x18 0x4>;
+				clkmux-table = <0 0x4>;
+			};
+			timer6_mux: timer6_mux {
+				compatible = "hisilicon,clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk67>;
+				clock-output-names = "timer6_mux";
+				clkmux-reg = <0x18 0x10>;
+				clkmux-table = <0 0x10>;
+			};
+			timer7_mux: timer7_mux {
+				compatible = "hisilicon,clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk67>;
+				clock-output-names = "timer7_mux";
+				clkmux-reg = <0x18 0x40>;
+				clkmux-table = <0 0x40>;
+			};
+			timer8_mux: timer8_mux {
+				compatible = "hisilicon,clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk89>;
+				clock-output-names = "timer8_mux";
+				clkmux-reg = <0x18 0x100>;
+				clkmux-table = <0 0x100>;
+			};
+			timer9_mux: timer9_mux {
+				compatible = "hisilicon,clk-mux";
+				#clock-cells = <0>;
+				clocks = <&osc32k &timerclk89>;
+				clock-output-names = "timer9_mux";
+				clkmux-reg = <0x18 0x400>;
+				clkmux-table = <0 0x400>;
+			};
+			rclk_shareAXI: rclk_shareAXI {
+				compatible = "hisilicon,hi3620-clk-mux";
+				#clock-cells = <0>;
+				clocks = <&pll_usb &pll_peri>;
+				clock-output-names = "rclk_shareAXI";
+				clkmux-reg = <0x100 0x8000>;
+				clkmux-table = <0 0x8000>;
+			};
+			uartclk0: uartclk0 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&uart0_mux>;
+				clock-output-names = "uartclk0";
+				hi3620-clkreset = <0x98 0x10000>;
+				hi3620-clkgate = <0x40 0x10000>;
+			};
+			uartclk1: uartclk1 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&uart1_mux>;
+				clock-output-names = "uartclk1";
+				hi3620-clkreset = <0x98 0x20000>;
+				hi3620-clkgate = <0x40 0x20000>;
+			};
+			uartclk2: uartclk2 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&uart2_mux>;
+				clock-output-names = "uartclk2";
+				hi3620-clkreset = <0x98 0x40000>;
+				hi3620-clkgate = <0x40 0x40000>;
+			};
+			uartclk3: uartclk3 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&uart3_mux>;
+				clock-output-names = "uartclk3";
+				hi3620-clkreset = <0x98 0x80000>;
+				hi3620-clkgate = <0x40 0x80000>;
+			};
+			uartclk4: uartclk4 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&uart4_mux>;
+				clock-output-names = "uartclk4";
+				hi3620-clkreset = <0x98 0x100000>;
+				hi3620-clkgate = <0x40 0x100000>;
+			};
+			gpioclk0: gpioclk0 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk0";
+				hi3620-clkreset = <0x80 0x100>;
+				hi3620-clkgate = <0x20 0x100>;
+			};
+			gpioclk1: gpioclk1 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk1";
+				hi3620-clkreset = <0x80 0x200>;
+				hi3620-clkgate = <0x20 0x200>;
+			};
+			gpioclk2: gpioclk2 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk2";
+				hi3620-clkreset = <0x80 0x400>;
+				hi3620-clkgate = <0x20 0x400>;
+			};
+			gpioclk3: gpioclk3 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk3";
+				hi3620-clkreset = <0x80 0x800>;
+				hi3620-clkgate = <0x20 0x800>;
+			};
+			gpioclk4: gpioclk4 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk4";
+				hi3620-clkreset = <0x80 0x1000>;
+				hi3620-clkgate = <0x20 0x1000>;
+			};
+			gpioclk5: gpioclk5 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk5";
+				hi3620-clkreset = <0x80 0x2000>;
+				hi3620-clkgate = <0x20 0x2000>;
+			};
+			gpioclk6: gpioclk6 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk6";
+				hi3620-clkreset = <0x80 0x4000>;
+				hi3620-clkgate = <0x20 0x4000>;
+			};
+			gpioclk7: gpioclk7 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk7";
+				hi3620-clkreset = <0x80 0x8000>;
+				hi3620-clkgate = <0x20 0x8000>;
+			};
+			gpioclk8: gpioclk8 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk8";
+				hi3620-clkreset = <0x80 0x10000>;
+				hi3620-clkgate = <0x20 0x10000>;
+			};
+			gpioclk9: gpioclk9 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk9";
+				hi3620-clkreset = <0x80 0x20000>;
+				hi3620-clkgate = <0x20 0x20000>;
+			};
+			gpioclk10: gpioclk10 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk10";
+				hi3620-clkreset = <0x80 0x40000>;
+				hi3620-clkgate = <0x20 0x40000>;
+			};
+			gpioclk11: gpioclk11 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk11";
+				hi3620-clkreset = <0x80 0x80000>;
+				hi3620-clkgate = <0x20 0x80000>;
+			};
+			gpioclk12: gpioclk12 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk12";
+				hi3620-clkreset = <0x80 0x100000>;
+				hi3620-clkgate = <0x20 0x100000>;
+			};
+			gpioclk13: gpioclk13 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk13";
+				hi3620-clkreset = <0x80 0x200000>;
+				hi3620-clkgate = <0x20 0x200000>;
+			};
+			gpioclk14: gpioclk14 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk14";
+				hi3620-clkreset = <0x80 0x400000>;
+				hi3620-clkgate = <0x20 0x400000>;
+			};
+			gpioclk15: gpioclk15 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk15";
+				hi3620-clkreset = <0x80 0x800000>;
+				hi3620-clkgate = <0x20 0x800000>;
+			};
+			gpioclk16: gpioclk16 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk16";
+				hi3620-clkreset = <0x80 0x1000000>;
+				hi3620-clkgate = <0x20 0x1000000>;
+			};
+			gpioclk17: gpioclk17 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk17";
+				hi3620-clkreset = <0x80 0x2000000>;
+				hi3620-clkgate = <0x20 0x2000000>;
+			};
+			gpioclk18: gpioclk18 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk18";
+				hi3620-clkreset = <0x80 0x4000000>;
+				hi3620-clkgate = <0x20 0x4000000>;
+			};
+			gpioclk19: gpioclk19 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk19";
+				hi3620-clkreset = <0x80 0x8000000>;
+				hi3620-clkgate = <0x20 0x8000000>;
+			};
+			gpioclk20: gpioclk20 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk20";
+				hi3620-clkreset = <0x80 0x10000000>;
+				hi3620-clkgate = <0x20 0x10000000>;
+			};
+			gpioclk21: gpioclk21 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pclk>;
+				clock-output-names = "gpioclk21";
+				hi3620-clkreset = <0x80 0x20000000>;
+				hi3620-clkgate = <0x20 0x20000000>;
+			};
+			spiclk0: spiclk0 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&spi0_mux>;
+				clock-output-names = "spiclk0";
+				hi3620-clkreset = <0x98 0x200000>;
+				hi3620-clkgate = <0x40 0x200000>;
+			};
+			spiclk1: spiclk1 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&spi1_mux>;
+				clock-output-names = "spiclk1";
+				hi3620-clkreset = <0x98 0x400000>;
+				hi3620-clkgate = <0x40 0x400000>;
+			};
+			spiclk2: spiclk2 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&spi2_mux>;
+				clock-output-names = "spiclk2";
+				hi3620-clkreset = <0x98 0x800000>;
+				hi3620-clkgate = <0x40 0x800000>;
+			};
+			pwmclk0: pwmclk0 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pwm0_mux>;
+				clock-output-names = "pwmclk0";
+				hi3620-clkreset = <0x98 0x80>;
+				hi3620-clkgate = <0x40 0x80>;
+			};
+			pwmclk1: pwmclk1 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&pwm1_mux>;
+				clock-output-names = "pwmclk1";
+				hi3620-clkreset = <0x98 0x100>;
+				hi3620-clkgate = <0x40 0x100>;
+			};
+			timerclk01: timerclk01 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&osc26m>;
+				clock-output-names = "timerclk01";
+				hi3620-clkreset = <0x80 0x1>;
+				hi3620-clkgate = <0x20 0x3>;
+			};
+			timerclk23: timerclk23 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&osc26m>;
+				clock-output-names = "timerclk23";
+				hi3620-clkreset = <0x80 0x2>;
+				hi3620-clkgate = <0x20 0xc>;
+			};
+			timerclk45: timerclk45 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&osc26m>;
+				clock-output-names = "timerclk45";
+				hi3620-clkreset = <0x98 0x8>;
+				hi3620-clkgate = <0x40 0x8>;
+			};
+			timerclk67: timerclk67 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&osc26m>;
+				clock-output-names = "timerclk67";
+				hi3620-clkreset = <0x98 0x10>;
+				hi3620-clkgate = <0x40 0x10>;
+			};
+			timerclk89: timerclk89 {
+				compatible = "hisilicon,hi3620-clk-gate";
+				#clock-cells = <0>;
+				clocks = <&osc26m>;
+				clock-output-names = "timerclk89";
+				hi3620-clkreset = <0x98 0x20>;
+				hi3620-clkgate = <0x40 0x20>;
+			};
+			timclk0: timclk0 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&timer0_mux>;
+				clock-output-names = "timclk0";
+				clkgate-inverted;
+				clkgate = <0 16>;
+			};
+			timclk1: timclk1 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&timer1_mux>;
+				clock-output-names = "timclk1";
+				clkgate-inverted;
+				clkgate = <0 18>;
+			};
+			timclk2: timclk2 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&timer2_mux>;
+				clock-output-names = "timclk2";
+				clkgate-inverted;
+				clkgate = <0 20>;
+			};
+			timclk3: timclk3 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&timer3_mux>;
+				clock-output-names = "timclk3";
+				clkgate-inverted;
+				clkgate = <0 22>;
+			};
+			timclk4: timclk4 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&timer4_mux>;
+				clock-output-names = "timclk4";
+				clkgate-inverted;
+				clkgate = <0x18 0>;
+			};
+			timclk5: timclk5 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&timer5_mux>;
+				clock-output-names = "timclk5";
+				clkgate-inverted;
+				clkgate = <0x18 2>;
+			};
+			timclk6: timclk6 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&timer6_mux>;
+				clock-output-names = "timclk6";
+				clkgate-inverted;
+				clkgate = <0x18 4>;
+			};
+			timclk7: timclk7 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&timer7_mux>;
+				clock-output-names = "timclk7";
+				clkgate-inverted;
+				clkgate = <0x18 6>;
+			};
+			timclk8: timclk8 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&timer8_mux>;
+				clock-output-names = "timclk8";
+				clkgate-inverted;
+				clkgate = <0x18 8>;
+			};
+			timclk9: timclk9 {
+				compatible = "hisilicon,clk-gate";
+				#clock-cells = <0>;
+				clocks = <&timer9_mux>;
+				clock-output-names = "timclk9";
+				clkgate-inverted;
+				clkgate = <0x18 10>;
+			};
+			dtable: dtable {
+				#clkdiv-table-cells = <2>;
+			};
+			div_shareaxi: div_shareaxi {
+				compatible = "hisilicon,hi3620-clk-div";
+				#clock-cells = <0>;
+				clocks = <&rclk_shareAXI>;
+				clock-output-names = "shareAXI_div";
+				clkdiv-table = <
+					&dtable 0 1 &dtable 1 2 &dtable 2 3 &dtable 3 4
+					&dtable 4 5 &dtable 5 6 &dtable 6 7 &dtable 7 8
+					&dtable 8 9 &dtable 9 10 &dtable 10 11 &dtable 11 12
+					&dtable 12 13 &dtable 13 14 &dtable 14 15 &dtable 15 16
+					&dtable 16 17 &dtable 17 18 &dtable 18 19 &dtable 19 20
+					&dtable 20 21 &dtable 21 22 &dtable 22 23 &dtable 23 24
+					&dtable 24 25 &dtable 25 26 &dtable 26 27 &dtable 27 28
+					&dtable 28 29 &dtable 29 30 &dtable 30 31 &dtable 31 32>;
+				/* divider register offset, mask */
+				clkdiv = <0x100 0x1f>;
+			};
+			div_cfgaxi: div_cfgaxi {
+				compatible = "hisilicon,hi3620-clk-div";
+				#clock-cells = <0>;
+				clocks = <&div_shareaxi>;
+				clock-output-names = "cfgAXI_div";
+				clkdiv-table = <&dtable 0x01 2>;
+				clkdiv = <0x100 0x60>;
+			};
+		};
+
+		l2: l2-cache {
+			compatible = "arm,pl310-cache";
+			reg = <0xfc10000 0x100000>;
+			interrupts = <0 15 4>;
+			cache-unified;
+			cache-level = <2>;
+		};
+
+		intc: interrupt-controller at fc001000 {
+			compatible = "arm,cortex-a9-gic";
+			#interrupt-cells = <3>;
+			#address-cells = <0>;
+			interrupt-controller;
+			/* gic dist base, gic cpu base */
+			reg = <0xfc001000 0x1000>, <0xfc000100 0x100>;
+		};
+
+		timer0: timer at fc800000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0xfc800000 0x1000>;
+			/* timer00 & timer01 */
+			interrupts = <0 0 4>, <0 1 4>;
+			clocks = <&timclk0 &timclk1>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		timer1: timer at fc801000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0xfc801000 0x1000>;
+			/* timer10 & timer11 */
+			interrupts = <0 2 4>, <0 3 4>;
+			clocks = <&timclk2 &timclk3>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		timer2: timer at fca01000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0xfca01000 0x1000>;
+			/* timer20 & timer21 */
+			interrupts = <0 4 4>, <0 5 4>;
+			clocks = <&timclk4 &timclk5>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		timer3: timer at fca02000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0xfca02000 0x1000>;
+			/* timer30 & timer31 */
+			interrupts = <0 6 4>, <0 7 4>;
+			clocks = <&timclk6 &timclk7>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		timer4: timer at fca03000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0xfca03000 0x1000>;
+			/* timer40 & timer41 */
+			interrupts = <0 96 4>, <0 97 4>;
+			clocks = <&timclk8 &timclk9>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		uart0: uart at fcb00000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xfcb00000 0x1000>;
+			interrupts = <0 20 4>;
+			clocks = <&uartclk0>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		uart1: uart at fcb01000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xfcb01000 0x1000>;
+			interrupts = <0 21 4>;
+			clocks = <&uartclk1>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		uart2: uart at fcb02000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xfcb02000 0x1000>;
+			interrupts = <0 22 4>;
+			clocks = <&uartclk2>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		uart3: uart at fcb03000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xfcb03000 0x1000>;
+			interrupts = <0 23 4>;
+			clocks = <&uartclk3>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		uart4: uart at fcb04000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xfcb04000 0x1000>;
+			interrupts = <0 24 4>;
+			clocks = <&uartclk4>;
+			clock-names = "apb_pclk";
+			status = "disabled";
+		};
+
+		gpio0: gpio at fc806000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc806000 0x1000>;
+			interrupts = <0 64 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 2 0 1 &pmx0 3 0 1 &pmx0 4 0 1
+					&pmx0 5 0 1 &pmx0 6 1 1 &pmx0 7 2 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk0>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio1: gpio at fc807000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc807000 0x1000>;
+			interrupts = <0 65 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 3 1 &pmx0 1 3 1 &pmx0 2 3 1
+					&pmx0 3 3 1 &pmx0 4 3 1 &pmx0 5 4 1
+					&pmx0 6 5 1 &pmx0 7 6 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk1>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio2: gpio at fc808000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc808000 0x1000>;
+			interrupts = <0 66 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 7 1 &pmx0 1 8 1 &pmx0 2 9 1
+					&pmx0 3 10 1 &pmx0 4 3 1 &pmx0 5 3 1
+					&pmx0 6 3 1 &pmx0 7 3 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk2>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio3: gpio at fc809000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc809000 0x1000>;
+			interrupts = <0 67 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 3 1 &pmx0 1 3 1 &pmx0 2 3 1
+					&pmx0 3 3 1 &pmx0 4 11 1 &pmx0 5 11 1
+					&pmx0 6 11 1 &pmx0 7 11 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk3>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio4: gpio at fc80a000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc80a000 0x1000>;
+			interrupts = <0 68 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 11 1 &pmx0 1 11 1 &pmx0 2 11 1
+					&pmx0 3 11 1 &pmx0 4 12 1 &pmx0 5 12 1
+					&pmx0 6 13 1 &pmx0 7 13 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk4>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio5: gpio at fc80b000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc80b000 0x1000>;
+			interrupts = <0 69 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 14 1 &pmx0 1 15 1 &pmx0 2 16 1
+					&pmx0 3 16 1 &pmx0 4 16 1 &pmx0 5 16 1
+					&pmx0 6 16 1 &pmx0 7 16 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk5>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio6: gpio at fc80c000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc80c000 0x1000>;
+			interrupts = <0 70 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 16 1 &pmx0 1 16 1 &pmx0 2 17 1
+					&pmx0 3 17 1 &pmx0 4 18 1 &pmx0 5 18 1
+					&pmx0 6 18 1 &pmx0 7 19 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk6>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio7: gpio at fc80d000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc80d000 0x1000>;
+			interrupts = <0 71 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 19 1 &pmx0 1 20 1 &pmx0 2 21 1
+					&pmx0 3 22 1 &pmx0 4 23 1 &pmx0 5 24 1
+					&pmx0 6 25 1 &pmx0 7 26 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk7>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio8: gpio at fc80e000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc80e000 0x1000>;
+			interrupts = <0 72 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 27 1 &pmx0 1 28 1 &pmx0 2 29 1
+					&pmx0 3 30 1 &pmx0 4 31 1 &pmx0 5 32 1
+					&pmx0 6 33 1 &pmx0 7 34 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk8>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio9: gpio at fc80f000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc80f000 0x1000>;
+			interrupts = <0 73 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 35 1 &pmx0 1 36 1 &pmx0 2 37 1
+					&pmx0 3 38 1 &pmx0 4 39 1 &pmx0 5 40 1
+					&pmx0 6 41 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk9>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio10: gpio at fc810000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc810000 0x1000>;
+			interrupts = <0 74 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 2 43 1 &pmx0 3 44 1 &pmx0 4 45 1
+					&pmx0 5 45 1 &pmx0 6 46 1 &pmx0 7 46 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk10>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio11: gpio at fc811000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc811000 0x1000>;
+			interrupts = <0 75 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 47 1 &pmx0 1 47 1 &pmx0 2 47 1
+					&pmx0 3 47 1 &pmx0 4 47 1 &pmx0 5 48 1
+					&pmx0 6 49 1 &pmx0 7 49 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk11>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio12: gpio at fc812000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc812000 0x1000>;
+			interrupts = <0 76 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 49 1 &pmx0 1 50 1 &pmx0 2 49 1
+					&pmx0 3 49 1 &pmx0 4 51 1 &pmx0 5 51 1
+					&pmx0 6 51 1 &pmx0 7 52 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk12>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio13: gpio at fc813000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc813000 0x1000>;
+			interrupts = <0 77 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 51 1 &pmx0 1 51 1 &pmx0 2 53 1
+					&pmx0 3 53 1 &pmx0 4 53 1 &pmx0 5 54 1
+					&pmx0 6 55 1 &pmx0 7 56 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk13>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio14: gpio at fc814000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc814000 0x1000>;
+			interrupts = <0 78 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 57 1 &pmx0 1 97 1 &pmx0 2 97 1
+					&pmx0 3 58 1 &pmx0 4 59 1 &pmx0 5 60 1
+					&pmx0 6 60 1 &pmx0 7 61 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk14>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio15: gpio at fc815000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc815000 0x1000>;
+			interrupts = <0 79 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 61 1 &pmx0 1 62 1 &pmx0 2 62 1
+					&pmx0 3 63 1 &pmx0 4 63 1 &pmx0 5 64 1
+					&pmx0 6 64 1 &pmx0 7 65 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk15>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio16: gpio at fc816000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc816000 0x1000>;
+			interrupts = <0 80 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 66 1 &pmx0 1 67 1 &pmx0 2 68 1
+					&pmx0 3 69 1 &pmx0 4 70 1 &pmx0 5 71 1
+					&pmx0 6 72 1 &pmx0 7 73 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk16>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio17: gpio at fc817000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc817000 0x1000>;
+			interrupts = <0 81 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 74 1 &pmx0 1 75 1 &pmx0 2 76 1
+					&pmx0 3 77 1 &pmx0 4 78 1 &pmx0 5 79 1
+					&pmx0 6 80 1 &pmx0 7 81 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk17>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio18: gpio at fc818000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc818000 0x1000>;
+			interrupts = <0 82 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 82 1 &pmx0 1 83 1 &pmx0 2 83 1
+					&pmx0 3 84 1 &pmx0 4 84 1 &pmx0 5 85 1
+					&pmx0 6 86 1 &pmx0 7 87 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk18>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio19: gpio at fc819000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc819000 0x1000>;
+			interrupts = <0 83 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 87 1 &pmx0 1 87 1 &pmx0 2 88 1
+					&pmx0 3 88 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk19>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio20: gpio at fc81a000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc81a000 0x1000>;
+			interrupts = <0 84 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 0 89 1 &pmx0 1 89 1 &pmx0 2 90 1
+					&pmx0 3 90 1 &pmx0 4 91 1 &pmx0 5 92 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk20>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio21: gpio at fc81b000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0xfc81b000 0x1000>;
+			interrupts = <0 85 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <	&pmx0 3 94 1 &pmx0 7 96 1>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&gpioclk21>;
+			clock-names = "apb_pclk";
+		};
+
+		pmx0: pinmux at fc803000 {
+			compatible = "pinctrl-single";
+			reg = <0xfc803000 0x188>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			#gpio-range-cells = <3>;
+			ranges;
+
+			pinctrl-single,register-width = <32>;
+			pinctrl-single,function-mask = <7>;
+			/* pin base, nr pins & gpio function */
+			pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1
+						&range 12 1 0 &range 13 29 1
+						&range 43 1 0 &range 44 49 1
+						&range 94 1 1 &range 96 2 1>;
+
+			range: gpio-range {
+				#pinctrl-single,gpio-range-cells = <3>;
+			};
+		};
+
+		pmx1: pinmux at fc803800 {
+			compatible = "pinconf-single";
+			reg = <0xfc803800 0x2dc>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			pinctrl-single,register-width = <32>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/hi4511.dts b/arch/arm/boot/dts/hi4511.dts
new file mode 100644
index 0000000..66ac03a
--- /dev/null
+++ b/arch/arm/boot/dts/hi4511.dts
@@ -0,0 +1,648 @@
+/*
+ *  Copyright (C) 2012-2013 Linaro Ltd.
+ *  Author: Haojian Zhuang <haojian.zhuang at linaro.org>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  publishhed by the Free Software Foundation.
+ */
+
+/dts-v1/;
+/include/ "hi3620.dtsi"
+
+/ {
+	model = "Hisilicon Hi4511 Development Board";
+	compatible = "hisilicon,hi3620-hi4511";
+
+	chosen {
+		bootargs = "console=ttyAMA0,115200 root=/dev/ram0";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x40000000 0x20000000>;
+	};
+
+	amba {
+		timer0: timer at fc800000 {
+			status = "ok";
+		};
+
+		uart0: uart at fcb00000 {	/* console */
+			pinctrl-names = "default", "idle";
+			pinctrl-0 = <&uart0_pmx_func &uart0_cfg_func>;
+			pinctrl-1 = <&uart0_pmx_idle &uart0_cfg_idle>;
+			status = "ok";
+		};
+
+		uart1: uart at fcb01000 { /* modem */
+			pinctrl-names = "default", "idle";
+			pinctrl-0 = <&uart1_pmx_func &uart1_cfg_func>;
+			pinctrl-1 = <&uart1_pmx_idle &uart1_cfg_idle>;
+			status = "ok";
+		};
+
+		uart2: uart at fcb02000 { /* audience */
+			pinctrl-names = "default", "idle";
+			pinctrl-0 = <&uart2_pmx_func &uart2_cfg_func>;
+			pinctrl-1 = <&uart2_pmx_idle &uart2_cfg_idle>;
+			status = "ok";
+		};
+
+		uart3: uart at fcb03000 {
+			pinctrl-names = "default", "idle";
+			pinctrl-0 = <&uart3_pmx_func &uart3_cfg_func>;
+			pinctrl-1 = <&uart3_pmx_idle &uart3_cfg_idle>;
+			status = "ok";
+		};
+
+		uart4: uart at fcb04000 {
+			pinctrl-names = "default", "idle";
+			pinctrl-0 = <&uart4_pmx_func &uart4_cfg_func>;
+			pinctrl-1 = <&uart4_pmx_idle &uart4_cfg_func>;
+			status = "ok";
+		};
+
+		pmx0: pinmux at fc803000 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&board_pmx_pins>;
+
+			board_pmx_pins: board_pmx_pins {
+				pinctrl-single,pins = <
+					0x008 0x0	/* GPIO -- eFUSE_DOUT */
+					0x100 0x0	/* USIM_CLK & USIM_DATA (IOMG63) */
+				>;
+			};
+			uart0_pmx_func: uart0_pmx_func {
+				pinctrl-single,pins = <
+					0x0f0 0x0
+					0x0f4 0x0	/* UART0_RX & UART0_TX */
+				>;
+			};
+			uart0_pmx_idle: uart0_pmx_idle {
+				pinctrl-single,pins = <
+					/*0x0f0 0x1*/	/* UART0_CTS & UART0_RTS */
+					0x0f4 0x1	/* UART0_RX & UART0_TX */
+				>;
+			};
+			uart1_pmx_func: uart1_pmx_func {
+				pinctrl-single,pins = <
+					0x0f8 0x0	/* UART1_CTS & UART1_RTS (IOMG61) */
+					0x0fc 0x0	/* UART1_RX & UART1_TX (IOMG62) */
+				>;
+			};
+			uart1_pmx_idle: uart1_pmx_idle {
+				pinctrl-single,pins = <
+					0x0f8 0x1	/* GPIO (IOMG61) */
+					0x0fc 0x1	/* GPIO (IOMG62) */
+				>;
+			};
+			uart2_pmx_func: uart2_pmx_func {
+				pinctrl-single,pins = <
+					0x104 0x2	/* UART2_RXD (IOMG96) */
+					0x108 0x2	/* UART2_TXD (IOMG64) */
+				>;
+			};
+			uart2_pmx_idle: uart2_pmx_idle {
+				pinctrl-single,pins = <
+					0x104 0x1	/* GPIO (IOMG96) */
+					0x108 0x1	/* GPIO (IOMG64) */
+				>;
+			};
+			uart3_pmx_func: uart3_pmx_func {
+				pinctrl-single,pins = <
+					0x160 0x2	/* UART3_CTS & UART3_RTS (IOMG85) */
+					0x164 0x2	/* UART3_RXD & UART3_TXD (IOMG86) */
+				>;
+			};
+			uart3_pmx_idle: uart3_pmx_idle {
+				pinctrl-single,pins = <
+					0x160 0x1	/* GPIO (IOMG85) */
+					0x164 0x1	/* GPIO (IOMG86) */
+				>;
+			};
+			uart4_pmx_func: uart4_pmx_func {
+				pinctrl-single,pins = <
+					0x168 0x0	/* UART4_CTS & UART4_RTS (IOMG87) */
+					0x16c 0x0	/* UART4_RXD (IOMG88) */
+					0x170 0x0	/* UART4_TXD (IOMG93) */
+				>;
+			};
+			uart4_pmx_idle: uart4_pmx_idle {
+				pinctrl-single,pins = <
+					0x168 0x1	/* GPIO (IOMG87) */
+					0x16c 0x1	/* GPIO (IOMG88) */
+					0x170 0x1	/* GPIO (IOMG93) */
+				>;
+			};
+			i2c0_pmx_func: i2c0_pmx_func {
+				pinctrl-single,pins = <
+					0x0b4 0x0	/* I2C0_SCL & I2C0_SDA (IOMG45) */
+				>;
+			};
+			i2c0_pmx_idle: i2c0_pmx_idle {
+				pinctrl-single,pins = <
+					0x0b4 0x1	/* GPIO (IOMG45) */
+				>;
+			};
+			i2c1_pmx_func: i2c1_pmx_func {
+				pinctrl-single,pins = <
+					0x0b8 0x0	/* I2C1_SCL & I2C1_SDA (IOMG46) */
+				>;
+			};
+			i2c1_pmx_idle: i2c1_pmx_idle {
+				pinctrl-single,pins = <
+					0x0b8 0x1	/* GPIO (IOMG46) */
+				>;
+			};
+			i2c2_pmx_func: i2c2_pmx_func {
+				pinctrl-single,pins = <
+					0x068 0x0	/* I2C2_SCL (IOMG26) */
+					0x06c 0x0	/* I2C2_SDA (IOMG27) */
+				>;
+			};
+			i2c2_pmx_idle: i2c2_pmx_idle {
+				pinctrl-single,pins = <
+					0x068 0x1	/* GPIO (IOMG26) */
+					0x06c 0x1	/* GPIO (IOMG27) */
+				>;
+			};
+			i2c3_pmx_func: i2c3_pmx_func {
+				pinctrl-single,pins = <
+					0x050 0x2	/* I2C3_SCL (IOMG20) */
+					0x054 0x2	/* I2C3_SDA (IOMG21) */
+				>;
+			};
+			i2c3_pmx_idle: i2c3_pmx_idle {
+				pinctrl-single,pins = <
+					0x050 0x1	/* GPIO (IOMG20) */
+					0x054 0x1	/* GPIO (IOMG21) */
+				>;
+			};
+			spi0_pmx_func: spi0_pmx_func {
+				pinctrl-single,pins = <
+					0x0d4 0x0	/* SPI0_CLK/SPI0_DI/SPI0_DO (IOMG53) */
+					0x0d8 0x0	/* SPI0_CS0 (IOMG54) */
+					0x0dc 0x0	/* SPI0_CS1 (IOMG55) */
+					0x0e0 0x0	/* SPI0_CS2 (IOMG56) */
+					0x0e4 0x0	/* SPI0_CS3 (IOMG57) */
+				>;
+			};
+			spi0_pmx_idle: spi0_pmx_idle {
+				pinctrl-single,pins = <
+					0x0d4 0x1	/* GPIO (IOMG53) */
+					0x0d8 0x1	/* GPIO (IOMG54) */
+					0x0dc 0x1	/* GPIO (IOMG55) */
+					0x0e0 0x1	/* GPIO (IOMG56) */
+					0x0e4 0x1	/* GPIO (IOMG57) */
+				>;
+			};
+			spi1_pmx_func: spi1_pmx_func {
+				pinctrl-single,pins = <
+					0x184 0x0	/* SPI1_CLK/SPI1_DI (IOMG98) */
+					0x0e8 0x0	/* SPI1_DO (IOMG58) */
+					0x0ec 0x0	/* SPI1_CS (IOMG95) */
+				>;
+			};
+			spi1_pmx_idle: spi1_pmx_idle {
+				pinctrl-single,pins = <
+					0x184 0x1	/* GPIO (IOMG98) */
+					0x0e8 0x1	/* GPIO (IOMG58) */
+					0x0ec 0x1	/* GPIO (IOMG95) */
+				>;
+			};
+			kpc_pmx_func: kpc_pmx_func {
+				pinctrl-single,pins = <
+					0x12c 0x0	/* KEY_IN0 (IOMG73) */
+					0x130 0x0	/* KEY_IN1 (IOMG74) */
+					0x134 0x0	/* KEY_IN2 (IOMG75) */
+					0x10c 0x0	/* KEY_OUT0 (IOMG65) */
+					0x110 0x0	/* KEY_OUT1 (IOMG66) */
+					0x114 0x0	/* KEY_OUT2 (IOMG67) */
+				>;
+			};
+			kpc_pmx_idle: kpc_pmx_idle {
+				pinctrl-single,pins = <
+					0x12c 0x1	/* GPIO (IOMG73) */
+					0x130 0x1	/* GPIO (IOMG74) */
+					0x134 0x1	/* GPIO (IOMG75) */
+					0x10c 0x1	/* GPIO (IOMG65) */
+					0x110 0x1	/* GPIO (IOMG66) */
+					0x114 0x1	/* GPIO (IOMG67) */
+				>;
+			};
+			gpio_key_func: gpio_key_func {
+				pinctrl-single,pins = <
+					0x10c 0x1	/* KEY_OUT0/GPIO (IOMG65) */
+					0x130 0x1	/* KEY_IN1/GPIO (IOMG74) */
+				>;
+			};
+			emmc_pmx_func: emmc_pmx_func {
+				pinctrl-single,pins = <
+					0x030 0x2	/* eMMC_CMD/eMMC_CLK (IOMG12) */
+					0x018 0x0	/* NAND_CS3_N (IOMG6) */
+					0x024 0x0	/* NAND_BUSY2_N (IOMG8) */
+					0x028 0x0	/* NAND_BUSY3_N (IOMG9) */
+					0x02c 0x2	/* eMMC_DATA[0:7] (IOMG10) */
+				>;
+			};
+			emmc_pmx_idle: emmc_pmx_idle {
+				pinctrl-single,pins = <
+					0x030 0x0	/* GPIO (IOMG12) */
+					0x018 0x1	/* GPIO (IOMG6) */
+					0x024 0x1	/* GPIO (IOMG8) */
+					0x028 0x1	/* GPIO (IOMG9) */
+					0x02c 0x1	/* GPIO (IOMG10) */
+				>;
+			};
+			sd_pmx_func: sd_pmx_func {
+				pinctrl-single,pins = <
+					0x0bc 0x0	/* SD_CLK/SD_CMD/SD_DATA0/SD_DATA1/SD_DATA2 (IOMG47) */
+					0x0c0 0x0	/* SD_DATA3 (IOMG48) */
+				>;
+			};
+			sd_pmx_idle: sd_pmx_idle {
+				pinctrl-single,pins = <
+					0x0bc 0x1	/* GPIO (IOMG47) */
+					0x0c0 0x1	/* GPIO (IOMG48) */
+				>;
+			};
+			nand_pmx_func: nand_pmx_func {
+				pinctrl-single,pins = <
+					0x00c 0x0	/* NAND_ALE/NAND_CLE/.../NAND_DATA[0:7] (IOMG3) */
+					0x010 0x0	/* NAND_CS1_N (IOMG4) */
+					0x014 0x0	/* NAND_CS2_N (IOMG5) */
+					0x018 0x0	/* NAND_CS3_N (IOMG6) */
+					0x01c 0x0	/* NAND_BUSY0_N (IOMG94) */
+					0x020 0x0	/* NAND_BUSY1_N (IOMG7) */
+					0x024 0x0	/* NAND_BUSY2_N (IOMG8) */
+					0x028 0x0	/* NAND_BUSY3_N (IOMG9) */
+					0x02c 0x0	/* NAND_DATA[8:15] (IOMG10) */
+				>;
+			};
+			nand_pmx_idle: nand_pmx_idle {
+				pinctrl-single,pins = <
+					0x00c 0x1	/* GPIO (IOMG3) */
+					0x010 0x1	/* GPIO (IOMG4) */
+					0x014 0x1	/* GPIO (IOMG5) */
+					0x018 0x1	/* GPIO (IOMG6) */
+					0x01c 0x1	/* GPIO (IOMG94) */
+					0x020 0x1	/* GPIO (IOMG7) */
+					0x024 0x1	/* GPIO (IOMG8) */
+					0x028 0x1	/* GPIO (IOMG9) */
+					0x02c 0x1	/* GPIO (IOMG10) */
+				>;
+			};
+			sdio_pmx_func: sdio_pmx_func {
+				pinctrl-single,pins = <
+					0x0c4 0x0	/* SDIO_CLK/SDIO_CMD/SDIO_DATA[0:3] (IOMG49) */
+				>;
+			};
+			sdio_pmx_idle: sdio_pmx_idle {
+				pinctrl-single,pins = <
+					0x0c4 0x1	/* GPIO (IOMG49) */
+				>;
+			};
+			audio_out_pmx_func: audio_out_pmx_func {
+				pinctrl-single,pins = <
+					0x0f0 0x1	/* GPIO (IOMG59), audio spk & earphone */
+				>;
+			};
+		};
+
+		pmx1: pinmux at fc803800 {
+			pinctrl-names = "default";
+			pinctrl-0 = <	&board_pu_pins &board_pd_pins &board_pd_ps_pins
+					&board_np_pins &board_ps_pins &kpc_cfg_func
+					&audio_out_cfg_func>;
+			board_pu_pins: board_pu_pins {
+				pinctrl-single,pins = <
+					0x014 0		/* GPIO_158 (IOCFG2) */
+					0x018 0		/* GPIO_159 (IOCFG3) */
+					0x01c 0		/* BOOT_MODE0 (IOCFG4) */
+					0x020 0		/* BOOT_MODE1 (IOCFG5) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <1 1 0 1>;
+			};
+			board_pd_pins: board_pd_pins {
+				pinctrl-single,pins = <
+					0x038 0		/* eFUSE_DOUT (IOCFG11) */
+					0x150 0		/* ISP_GPIO8 (IOCFG93) */
+					0x154 0		/* ISP_GPIO9 (IOCFG94) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			board_pd_ps_pins: board_pd_ps_pins {
+				pinctrl-single,pins = <
+					0x2d8 0		/* CLK_OUT0 (IOCFG190) */
+					0x004 0		/* PMU_SPI_DATA (IOCFG192) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			board_np_pins: board_np_pins {
+				pinctrl-single,pins = <
+					0x24c 0		/* KEYPAD_OUT7 (IOCFG155) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			board_ps_pins: board_ps_pins {
+				pinctrl-single,pins = <
+					0x000 0		/* PMU_SPI_CLK (IOCFG191) */
+					0x008 0		/* PMU_SPI_CS_N (IOCFG193) */
+				>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			uart0_cfg_func: uart0_cfg_func {
+				pinctrl-single,pins = <
+					0x208 0		/* UART0_RXD (IOCFG138) */
+					0x20c 0		/* UART0_TXD (IOCFG139) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart0_cfg_idle: uart0_cfg_idle {
+				pinctrl-single,pins = <
+					0x208 0		/* UART0_RXD (IOCFG138) */
+					0x20c 0		/* UART0_TXD (IOCFG139) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart1_cfg_func: uart1_cfg_func {
+				pinctrl-single,pins = <
+					0x210 0		/* UART1_CTS (IOCFG140) */
+					0x214 0		/* UART1_RTS (IOCFG141) */
+					0x218 0		/* UART1_RXD (IOCFG142) */
+					0x21c 0		/* UART1_TXD (IOCFG143) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart1_cfg_idle: uart1_cfg_idle {
+				pinctrl-single,pins = <
+					0x210 0		/* UART1_CTS (IOCFG140) */
+					0x214 0		/* UART1_RTS (IOCFG141) */
+					0x218 0		/* UART1_RXD (IOCFG142) */
+					0x21c 0		/* UART1_TXD (IOCFG143) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart2_cfg_func: uart2_cfg_func {
+				pinctrl-single,pins = <
+					0x220 0		/* UART2_CTS (IOCFG144) */
+					0x224 0		/* UART2_RTS (IOCFG145) */
+					0x228 0		/* UART2_RXD (IOCFG146) */
+					0x22c 0		/* UART2_TXD (IOCFG147) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart2_cfg_idle: uart2_cfg_idle {
+				pinctrl-single,pins = <
+					0x220 0		/* GPIO (IOCFG144) */
+					0x224 0		/* GPIO (IOCFG145) */
+					0x228 0		/* GPIO (IOCFG146) */
+					0x22c 0		/* GPIO (IOCFG147) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart3_cfg_func: uart3_cfg_func {
+				pinctrl-single,pins = <
+					0x294 0		/* UART3_CTS (IOCFG173) */
+					0x298 0		/* UART3_RTS (IOCFG174) */
+					0x29c 0		/* UART3_RXD (IOCFG175) */
+					0x2a0 0		/* UART3_TXD (IOCFG176) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart3_cfg_idle: uart3_cfg_idle {
+				pinctrl-single,pins = <
+					0x294 0		/* UART3_CTS (IOCFG173) */
+					0x298 0		/* UART3_RTS (IOCFG174) */
+					0x29c 0		/* UART3_RXD (IOCFG175) */
+					0x2a0 0		/* UART3_TXD (IOCFG176) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			uart4_cfg_func: uart4_cfg_func {
+				pinctrl-single,pins = <
+					0x2a4 0		/* UART4_CTS (IOCFG177) */
+					0x2a8 0		/* UART4_RTS (IOCFG178) */
+					0x2ac 0		/* UART4_RXD (IOCFG179) */
+					0x2b0 0		/* UART4_TXD (IOCFG180) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			i2c0_cfg_func: i2c0_cfg_func {
+				pinctrl-single,pins = <
+					0x17c 0		/* I2C0_SCL (IOCFG103) */
+					0x180 0		/* I2C0_SDA (IOCFG104) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			i2c1_cfg_func: i2c1_cfg_func {
+				pinctrl-single,pins = <
+					0x184 0		/* I2C1_SCL (IOCFG105) */
+					0x188 0		/* I2C1_SDA (IOCFG106) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			i2c2_cfg_func: i2c2_cfg_func {
+				pinctrl-single,pins = <
+					0x118 0		/* I2C2_SCL (IOCFG79) */
+					0x11c 0		/* I2C2_SDA (IOCFG80) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			i2c3_cfg_func: i2c3_cfg_func {
+				pinctrl-single,pins = <
+					0x100 0		/* I2C3_SCL (IOCFG73) */
+					0x104 0		/* I2C3_SDA (IOCFG74) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			spi0_cfg_func1: spi0_cfg_func1 {
+				pinctrl-single,pins = <
+					0x1d4 0		/* SPI0_CLK (IOCFG125) */
+					0x1d8 0		/* SPI0_DI (IOCFG126) */
+					0x1dc 0		/* SPI0_DO (IOCFG127) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			spi0_cfg_func2: spi0_cfg_func2 {
+				pinctrl-single,pins = <
+					0x1e0 0		/* SPI0_CS0 (IOCFG128) */
+					0x1e4 0		/* SPI0_CS1 (IOCFG129) */
+					0x1e8 0		/* SPI0_CS2 (IOCFG130 */
+					0x1ec 0		/* SPI0_CS3 (IOCFG131) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <1 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			spi1_cfg_func1: spi1_cfg_func1 {
+				pinctrl-single,pins = <
+					0x1f0 0		/* SPI1_CLK (IOCFG132) */
+					0x1f4 0		/* SPI1_DI (IOCFG133) */
+					0x1f8 0		/* SPI1_DO (IOCFG134) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			spi1_cfg_func2: spi1_cfg_func2 {
+				pinctrl-single,pins = <
+					0x1fc 0		/* SPI1_CS (IOCFG135) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <1 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			kpc_cfg_func: kpc_cfg_func {
+				pinctrl-single,pins = <
+					0x250 0		/* KEY_IN0 (IOCFG156) */
+					0x254 0		/* KEY_IN1 (IOCFG157) */
+					0x258 0		/* KEY_IN2 (IOCFG158) */
+					0x230 0		/* KEY_OUT0 (IOCFG148) */
+					0x234 0		/* KEY_OUT1 (IOCFG149) */
+					0x238 0		/* KEY_OUT2 (IOCFG150) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+			emmc_cfg_func: emmc_cfg_func {
+				pinctrl-single,pins = <
+					0x0ac 0		/* eMMC_CMD (IOCFG40) */
+					0x0b0 0		/* eMMC_CLK (IOCFG41) */
+					0x058 0		/* NAND_CS3_N (IOCFG19) */
+					0x064 0		/* NAND_BUSY2_N (IOCFG22) */
+					0x068 0		/* NAND_BUSY3_N (IOCFG23) */
+					0x08c 0		/* NAND_DATA8 (IOCFG32) */
+					0x090 0		/* NAND_DATA9 (IOCFG33) */
+					0x094 0		/* NAND_DATA10 (IOCFG34) */
+					0x098 0		/* NAND_DATA11 (IOCFG35) */
+					0x09c 0		/* NAND_DATA12 (IOCFG36) */
+					0x0a0 0		/* NAND_DATA13 (IOCFG37) */
+					0x0a4 0		/* NAND_DATA14 (IOCFG38) */
+					0x0a8 0		/* NAND_DATA15 (IOCFG39) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <1 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			sd_cfg_func1: sd_cfg_func1 {
+				pinctrl-single,pins = <
+					0x18c 0		/* SD_CLK (IOCFG107) */
+					0x190 0		/* SD_CMD (IOCFG108) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			sd_cfg_func2: sd_cfg_func2 {
+				pinctrl-single,pins = <
+					0x194 0		/* SD_DATA0 (IOCFG109) */
+					0x198 0		/* SD_DATA1 (IOCFG110) */
+					0x19c 0		/* SD_DATA2 (IOCFG111) */
+					0x1a0 0		/* SD_DATA3 (IOCFG112) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x70 0xf0>;
+			};
+			nand_cfg_func1: nand_cfg_func1 {
+				pinctrl-single,pins = <
+					0x03c 0		/* NAND_ALE (IOCFG12) */
+					0x040 0		/* NAND_CLE (IOCFG13) */
+					0x06c 0		/* NAND_DATA0 (IOCFG24) */
+					0x070 0		/* NAND_DATA1 (IOCFG25) */
+					0x074 0		/* NAND_DATA2 (IOCFG26) */
+					0x078 0		/* NAND_DATA3 (IOCFG27) */
+					0x07c 0		/* NAND_DATA4 (IOCFG28) */
+					0x080 0		/* NAND_DATA5 (IOCFG29) */
+					0x084 0		/* NAND_DATA6 (IOCFG30) */
+					0x088 0		/* NAND_DATA7 (IOCFG31) */
+					0x08c 0		/* NAND_DATA8 (IOCFG32) */
+					0x090 0		/* NAND_DATA9 (IOCFG33) */
+					0x094 0		/* NAND_DATA10 (IOCFG34) */
+					0x098 0		/* NAND_DATA11 (IOCFG35) */
+					0x09c 0		/* NAND_DATA12 (IOCFG36) */
+					0x0a0 0		/* NAND_DATA13 (IOCFG37) */
+					0x0a4 0		/* NAND_DATA14 (IOCFG38) */
+					0x0a8 0		/* NAND_DATA15 (IOCFG39) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			nand_cfg_func2: nand_cfg_func2 {
+				pinctrl-single,pins = <
+					0x044 0		/* NAND_RE_N (IOCFG14) */
+					0x048 0		/* NAND_WE_N (IOCFG15) */
+					0x04c 0		/* NAND_CS0_N (IOCFG16) */
+					0x050 0		/* NAND_CS1_N (IOCFG17) */
+					0x054 0		/* NAND_CS2_N (IOCFG18) */
+					0x058 0		/* NAND_CS3_N (IOCFG19) */
+					0x05c 0		/* NAND_BUSY0_N (IOCFG20) */
+					0x060 0		/* NAND_BUSY1_N (IOCFG21) */
+					0x064 0		/* NAND_BUSY2_N (IOCFG22) */
+					0x068 0		/* NAND_BUSY3_N (IOCFG23) */
+				>;
+				pinctrl-single,bias-pulldown = <0 2 0 2>;
+				pinctrl-single,bias-pullup = <1 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			sdio_cfg_func: sdio_cfg_func {
+				pinctrl-single,pins = <
+					0x1a4 0		/* SDIO0_CLK (IOCG113) */
+					0x1a8 0		/* SDIO0_CMD (IOCG114) */
+					0x1ac 0		/* SDIO0_DATA0 (IOCG115) */
+					0x1b0 0		/* SDIO0_DATA1 (IOCG116) */
+					0x1b4 0		/* SDIO0_DATA2 (IOCG117) */
+					0x1b8 0		/* SDIO0_DATA3 (IOCG118) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+				pinctrl-single,drive-strength = <0x30 0xf0>;
+			};
+			audio_out_cfg_func: audio_out_cfg_func {
+				pinctrl-single,pins = <
+					0x200 0		/* GPIO (IOCFG136) */
+					0x204 0		/* GPIO (IOCFG137) */
+				>;
+				pinctrl-single,bias-pulldown = <2 2 0 2>;
+				pinctrl-single,bias-pullup = <0 1 0 1>;
+			};
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		call {
+			label = "call";
+			gpios = <&gpio17 2 0>;
+			linux,code = <169>;	/* KEY_PHONE */
+		};
+	};
+};
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index fe0bdc3..c7b5247 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -8,6 +8,7 @@ CONFIG_MACH_ARMADA_XP=y
 CONFIG_ARCH_BCM=y
 CONFIG_GPIO_PCA953X=y
 CONFIG_ARCH_HIGHBANK=y
+CONFIG_ARCH_HI3xxx=y
 CONFIG_ARCH_KEYSTONE=y
 CONFIG_ARCH_MXC=y
 CONFIG_MACH_IMX51_DT=y
-- 
1.8.1.2



From richardcochran at gmail.com  Fri Jul 26 00:43:03 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Fri, 26 Jul 2013 06:43:03 +0200
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <51F1743D.7050007@wwwdotorg.org>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy> <51F1743D.7050007@wwwdotorg.org>
Message-ID: <20130726044303.GA4100@netboy>

On Thu, Jul 25, 2013 at 11:53:49AM -0700, Stephen Warren wrote:
> On 07/25/2013 11:48 AM, Richard Cochran wrote:
> > On Thu, Jul 25, 2013 at 07:29:20PM +0100, Mark Rutland wrote:
> >>
> >> As long as we can make sufficiently clear that trying to use an unstable
> >> binding is going to be *very* painful, and not necessarily supported.

IOW, its okay to break DT setups with every release, as long as we
tell people first.

Well, at least you are being honest about it now.

> That's exactly why we're starting to think about which bindings should
> be considered stable and immutable, and when that should happen. As Olof
> pointed out, we haven't fully enforced that yet. Preferably bindings
> will be marked stable very fast, but mistakes are always going to happen
> in early development. ABIs are very hard.

They are even harder if you cannot decide what the ABI is in the first
place.

Thanks,
Richard


From sachin.kamat at linaro.org  Fri Jul 26 00:48:31 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Fri, 26 Jul 2013 10:18:31 +0530
Subject: [PATCHv2 1/2] iommu/exynos: add devices attached to the System
 MMU to an IOMMU group
In-Reply-To: <1374766502-14823-1-git-send-email-a.motakis@virtualopensystems.com>
References: <1374766502-14823-1-git-send-email-a.motakis@virtualopensystems.com>
Message-ID: <CAK9yfHw1Q9tmARR9W9WGaW5hhzcSQ5CV13Ct=7LT8pj85tBMBA@mail.gmail.com>

Hi Antonios,

On 25 July 2013 21:04, Antonios Motakis
<a.motakis at virtualopensystems.com> wrote:
> IOMMU groups are expected by certain users of the IOMMU API,
> e.g. VFIO. Since each device is behind its own System MMU, we
> can allocate a new IOMMU group for each device.
>
> This patch depends on Cho KyongHo's patch series titled "[PATCH v7 00/12]
> iommu/exynos: Fixes and Enhancements of System MMU driver with DT",
> applied on a Linux 3.10.1 kernel.

This kind of meta information should go after the "---" line below.

It has been tested on the Arndale board.
>
> Changes since in v2:
> - Removed possibility for minor memory leak in case of
>   misbehaving platform drivers
>
> Signed-off-by: Antonios Motakis <a.motakis at virtualopensystems.com>
> ---
>  drivers/iommu/exynos-iommu.c | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 51d43bb..c7dd4b5 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1134,6 +1134,32 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct iommu_domain *domain,
>         return phys;
>  }
>
> +static int exynos_iommu_add_device(struct device *dev)
> +{
> +       struct iommu_group *group;
> +       int ret;
> +
> +       group = iommu_group_get(dev);
> +
> +       if (!group) {
> +               group = iommu_group_alloc();
> +               if (IS_ERR(group)) {
> +                       dev_err(dev, "Failed to allocate IOMMU group\n");
> +                       return PTR_ERR(group);
> +               }
> +       }
> +
> +       ret = iommu_group_add_device(group, dev);
> +       iommu_group_put(group);
> +
> +       return ret;
> +}
> +
> +static void exynos_iommu_remove_device(struct device *dev)
> +{
> +       iommu_group_remove_device(dev);
> +}
> +
>  static struct iommu_ops exynos_iommu_ops = {
>         .domain_init = &exynos_iommu_domain_init,
>         .domain_destroy = &exynos_iommu_domain_destroy,
> @@ -1142,6 +1168,8 @@ static struct iommu_ops exynos_iommu_ops = {
>         .map = &exynos_iommu_map,
>         .unmap = &exynos_iommu_unmap,
>         .iova_to_phys = &exynos_iommu_iova_to_phys,
> +       .add_device     = exynos_iommu_add_device,
> +       .remove_device  = exynos_iommu_remove_device,
>         .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
>  };
>
> --
> 1.8.1.2
>



-- 
With warm regards,
Sachin


From richardcochran at gmail.com  Fri Jul 26 00:54:33 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Fri, 26 Jul 2013 06:54:33 +0200
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130725213753.GC17616@obsidianresearch.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
Message-ID: <20130726045433.GB4100@netboy>

On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:

> We use DT has a kernel configuration input. Our environment is
> designed to guarantee 100% that the kernel and DT match exactly. DT
> very deliberately isn't an ABI boundary in our systems.

It is nice that you use DT in that way, but that is not how DT is
supposed to work. If you must keep your DT in sync with the kernel,
then there is no advantage over the old platfrom device method. At
least that had the virtue of being a C language interface (ABI), and
some mistakes were be caught by the compiler.

> We've been doing this for years and have a proven in the field track
> record of upgrades from pre-2.6.16 to 3.7 and beyond with multiple
> SOCs. The same bootloader that was shipped to support non-DT 2.6.16
> boots DT 3.7 just fine.

Try that with Freescale PowerPCs.  Good luck.

Heck, even Paul's OMAP test reports have been spoiled by his not
deleting old dtb files. Of course, that is his fault (and not DT's, no
never).
 
> For closed system embedded DT has proven *WONDERFUL*.

I too work on commercial embedded systems, and DT has proven to be
one gigantic *PITA*.

Thanks,
Richard




From vijay.kilari at gmail.com  Fri Jul 26 01:41:27 2013
From: vijay.kilari at gmail.com (vijay.kilari at gmail.com)
Date: Fri, 26 Jul 2013 11:11:27 +0530
Subject: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
Message-ID: <1374817287-27952-1-git-send-email-vijay.kilari@gmail.com>

From: Vijaya Kumar K <Vijaya.Kumar at caviumnetworks.com>

In case of normal kexec kernel load, all cpu's are offlined
before calling machine_kexec() under kernel_kexec() function.
But in case crash panic cpus are relaxed in
machine_crash_nonpanic_core() SMP function but not offlined.

When crash kernel is loaded with kexec and on panic trigger
machine_kexec() checks for number of cpus online.
If more than one cpu is online machine_kexec() fails to load
with below error

kexec: error: multiple CPUs still online

In machine_crash_nonpanic_core() SMP function, offline CPU
before cpu_relax

Signed-off-by: Vijaya Kumar K <Vijaya.Kumar at caviumnetworks.com>
---
 arch/arm/kernel/machine_kexec.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index 4fb074c..163b160 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -73,6 +73,7 @@ void machine_crash_nonpanic_core(void *unused)
 	crash_save_cpu(&regs, smp_processor_id());
 	flush_cache_all();
 
+	set_cpu_online(smp_processor_id(), false);
 	atomic_dec(&waiting_for_crash_ipi);
 	while (1)
 		cpu_relax();
-- 
1.7.9.5



From richard.zhuhongxing at gmail.com  Fri Jul 26 02:38:06 2013
From: richard.zhuhongxing at gmail.com (Richard Zhu)
Date: Fri, 26 Jul 2013 14:38:06 +0800
Subject: [PATCH v9 0/3] ahci: enable ahci sata support on imx6q
Message-ID: <1374820689-12837-1-git-send-email-Hong-Xing.Zhu@freescale.com>

v9: add imx6q specific ahci sata support
  - Let ahci_imx depend on the MFD_SYSCON, to fix the build error
  reported by Randy.
  "
  on i386.
  # CONFIG_MFD_SYSCON is not set

  when ahci_imx.c is built as a loadable module:
  ERROR: "syscon_regmap_lookup_by_compatible" [drivers/ata/ahci_imx.ko] undefined!
  "
  -
v8: http://www.spinics.net/lists/linux-ide/msg45798.html
  - Regarding to Tejun's comments, rename the sata_imx driver
  to be ahci_imx
  - Add Shawn's ack and review signoff.
  - 

v7: http://www.spinics.net/lists/linux-ide/msg45738.html
  Thanks to Sergei Shtylyow and Shawn.
  - According to ePAPR [1] section 2.2.2, re-name
  the node from 'ahci' to 'sata'
  - Move the initialization of the ahb clock of the private
  data to the probe function.
  - Remove the platform_set_drvdata(..., NULL), and devm_clk_put
  (..., ...).
  - 

v6: http://www.spinics.net/lists/linux-ide/msg45719.html
  Thanks for Shawn's comments.
  - Speicify the ahb clock in the sata related dts changes.
  - Move the initialization of the sata PHY clock of the private
  data to the probe function.
  - Remove the empty device release function.
  - In order to be more readable, rename the imx_dev/imx_ahci_pdev
  to be ahci_dev/ahci_pdev, and do some other changes, such as typo
  error, more readable name of the variable.
  - 

v5: http://www.spinics.net/lists/linux-ide/msg45712.html
  - Fix the wrong referrence usage of the private data.
  - Use the private data to contain the poninter of the PHY
  signals adjustment window(gpr)
  - Tested on imx6q sd board.
  - 

v4: http://www.spinics.net/lists/linux-ide/msg45699.html
  Thanks for the review comments provided by Sascha, and Alexander.
  - Use the private data and keep a pointer to the PHY clock.
  - Don't use the global platform device variable, because that
  it would make the driver broken for mutiple instances.
  - Don't do the "writel" with assignment.
  - Other minor changes, such as print the error code when printing
  error message, use a u32 type to store readl results, and so on.

v3: http://www.spinics.net/lists/linux-ide/msg45688.html
  - Keep arch/arm and ahci_platform driver clean.
  - Add the sata_imx standalone driver contained all the
  specific setup
  - Add the release function, support the loadable module
  driver.
  - Tested on imx6q sd board.

v2: http://www.spinics.net/lists/linux-ide/msg45666.html 
 - Setup standalone imx ahci sata driver, because of
 the misalignments of the bits definition of the HBA register.
 - Replace the node by the label in the board dts.
 - 

v1: http://www.spinics.net/lists/linux-ide/msg45581.html
 - add imx6q specific ahci sata support to arch/arm/mach-imx/mach-imx6q.c

These patches is based on imx/dt branch of
"http://git.linaro.org/git-ro/people/shawnguo/linux-2.6.git"

[v9 1/3] ARM: dtsi: enable ahci sata on imx6q platforms
[v9 2/3] ARM: imx6q: update the sata bits definitions of gpr13
[v9 3/3] ahci_imx: add ahci sata support on imx platforms

arch/arm/boot/dts/imx6q-sabreauto.dts       |    4 +
arch/arm/boot/dts/imx6q-sabrelite.dts       |    4 +
arch/arm/boot/dts/imx6q-sabresd.dts         |    4 +
arch/arm/boot/dts/imx6q.dtsi                |    9 +
drivers/ata/Kconfig                         |    9 +
drivers/ata/Makefile                        |    1 +
drivers/ata/ahci_imx.c                      |  236 +++++++++++++++++++++++++++
include/linux/mfd/syscon/imx6q-iomuxc-gpr.h |  121 ++++++++++----
8 files changed, 351 insertions(+), 37 deletions(-)


From lokeshvutla at ti.com  Fri Jul 26 02:59:13 2013
From: lokeshvutla at ti.com (Lokesh Vutla)
Date: Fri, 26 Jul 2013 12:29:13 +0530
Subject: [PATCH 0/4] crypto: omap-sham: Add support for SHA384/SHA512 for
 OMAP5/AM43xx Soc's
Message-ID: <1374821957-30141-1-git-send-email-lokeshvutla@ti.com>

This patch series adds support for SHA348 and SHA512 in addition to MD5,
SHA1, SHA224 SHA256 that the omap sha module supports. Also adding the pdata
for OMAP5 and AM43xx Soc's.
And using devm_* calls to make cleanup paths simpler.

Lokesh Vutla (4):
  crypto: omap-sham: Add SHA384 and SHA512 Support
  crypto: omap-sham: Add OMAP5/AM43XX SHAM Support
  crypto: omap-sham: Convert to devm_request_irq()
  crypto: omap-sham: Convert to devm_kzalloc()

 drivers/crypto/Kconfig     |   11 +-
 drivers/crypto/omap-sham.c |  314 +++++++++++++++++++++++++++++++++++---------
 2 files changed, 262 insertions(+), 63 deletions(-)

-- 
1.7.9.5



From lokeshvutla at ti.com  Fri Jul 26 02:59:15 2013
From: lokeshvutla at ti.com (Lokesh Vutla)
Date: Fri, 26 Jul 2013 12:29:15 +0530
Subject: [PATCH 2/4] crypto: omap-sham: Add OMAP5/AM43XX SHAM Support
In-Reply-To: <1374821957-30141-1-git-send-email-lokeshvutla@ti.com>
References: <1374821957-30141-1-git-send-email-lokeshvutla@ti.com>
Message-ID: <1374821957-30141-3-git-send-email-lokeshvutla@ti.com>

Add support for the OMAP5 version of the SHAM module
that is present on OMAP5 and AM43xx SoCs.

This module is very simialar to OMAP4 version of SHAM module,
and adds SHA384 SHA512 hardware-accelerated hash functions to it.
To handle the higher digest size of SHA512, few SHA512_DIGEST_i
(i=1-16, and first 8 registers are duplicated from SHA_DIGEST_i
registers) registers are added at the end of register set.
So adding the above register offsets and module info in pdata.

Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
---
 drivers/crypto/omap-sham.c |   44 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index f73b1e0..a6eb6a8 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1718,6 +1718,46 @@ static const struct omap_sham_pdata omap_sham_pdata_omap4 = {
 	.minor_shift	= 0,
 };
 
+static struct omap_sham_algs_info omap_sham_algs_info_omap5[] = {
+	{
+		.algs_list	= algs_sha1_md5,
+		.size		= ARRAY_SIZE(algs_sha1_md5),
+	},
+	{
+		.algs_list	= algs_sha224_sha256,
+		.size		= ARRAY_SIZE(algs_sha224_sha256),
+	},
+	{
+		.algs_list	= algs_sha384_sha512,
+		.size		= ARRAY_SIZE(algs_sha384_sha512),
+	},
+};
+
+static const struct omap_sham_pdata omap_sham_pdata_omap5 = {
+	.algs_info	= omap_sham_algs_info_omap5,
+	.algs_info_size	= ARRAY_SIZE(omap_sham_algs_info_omap5),
+	.flags		= BIT(FLAGS_AUTO_XOR),
+	.digest_size	= SHA512_DIGEST_SIZE,
+	.copy_hash	= omap_sham_copy_hash_omap4,
+	.write_ctrl	= omap_sham_write_ctrl_omap4,
+	.trigger	= omap_sham_trigger_omap4,
+	.poll_irq	= omap_sham_poll_irq_omap4,
+	.intr_hdlr	= omap_sham_irq_omap4,
+	.idigest_ofs	= 0x240,
+	.odigest_ofs	= 0x200,
+	.din_ofs	= 0x080,
+	.digcnt_ofs	= 0x280,
+	.rev_ofs	= 0x100,
+	.mask_ofs	= 0x110,
+	.sysstatus_ofs	= 0x114,
+	.mode_ofs	= 0x284,
+	.length_ofs	= 0x288,
+	.major_mask	= 0x0700,
+	.major_shift	= 8,
+	.minor_mask	= 0x003f,
+	.minor_shift	= 0,
+};
+
 static const struct of_device_id omap_sham_of_match[] = {
 	{
 		.compatible	= "ti,omap2-sham",
@@ -1727,6 +1767,10 @@ static const struct of_device_id omap_sham_of_match[] = {
 		.compatible	= "ti,omap4-sham",
 		.data		= &omap_sham_pdata_omap4,
 	},
+	{
+		.compatible	= "ti,omap5-sham",
+		.data		= &omap_sham_pdata_omap5,
+	},
 	{},
 };
 MODULE_DEVICE_TABLE(of, omap_sham_of_match);
-- 
1.7.9.5



From lokeshvutla at ti.com  Fri Jul 26 02:59:14 2013
From: lokeshvutla at ti.com (Lokesh Vutla)
Date: Fri, 26 Jul 2013 12:29:14 +0530
Subject: [PATCH 1/4] crypto: omap-sham: Add SHA384 and SHA512 Support
In-Reply-To: <1374821957-30141-1-git-send-email-lokeshvutla@ti.com>
References: <1374821957-30141-1-git-send-email-lokeshvutla@ti.com>
Message-ID: <1374821957-30141-2-git-send-email-lokeshvutla@ti.com>

Adding support for SHA348 and SHA512 in addition to MD5, SHA1, SHA224
SHA256 that the omap sha module supports.

In order to add the support
- Removed hard coded register offsets and passing offsets from pdata
- Updating Flag offsets so that they can be used for SHA256 and SHA512
- Adding the algo info.

Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
---
 drivers/crypto/Kconfig     |   11 +-
 drivers/crypto/omap-sham.c |  245 ++++++++++++++++++++++++++++++++++++--------
 2 files changed, 209 insertions(+), 47 deletions(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 8ff7c23..62fb673 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -242,13 +242,16 @@ config CRYPTO_DEV_PPC4XX
 	  This option allows you to have support for AMCC crypto acceleration.
 
 config CRYPTO_DEV_OMAP_SHAM
-	tristate "Support for OMAP SHA1/MD5 hw accelerator"
-	depends on ARCH_OMAP2 || ARCH_OMAP3
+	tristate "Support for OMAP MD5/SHA1/SHA2 hw accelerator"
+	depends on ARCH_OMAP2PLUS
 	select CRYPTO_SHA1
 	select CRYPTO_MD5
+	select CRYPTO_SHA256
+	select CRYPTO_SHA512
+	select CRYPTO_HMAC
 	help
-	  OMAP processors have SHA1/MD5 hw accelerator. Select this if you
-	  want to use the OMAP module for SHA1/MD5 algorithms.
+	  OMAP processors have MD5/SHA1/SHA2 hw accelerator. Select this if you
+	  want to use the OMAP module for MD5/SHA1/SHA2 algorithms.
 
 config CRYPTO_DEV_OMAP_AES
 	tristate "Support for OMAP AES hw engine"
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 4bb6765..f73b1e0 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -44,7 +44,6 @@
 #include <crypto/hash.h>
 #include <crypto/internal/hash.h>
 
-#define SHA1_MD5_BLOCK_SIZE		SHA1_BLOCK_SIZE
 #define MD5_DIGEST_SIZE			16
 
 #define DST_MAXBURST			16
@@ -54,7 +53,7 @@
 #define SHA_REG_DIN(dd, x)		((dd)->pdata->din_ofs + ((x) * 0x04))
 #define SHA_REG_DIGCNT(dd)		((dd)->pdata->digcnt_ofs)
 
-#define SHA_REG_ODIGEST(x)		(0x00 + ((x) * 0x04))
+#define SHA_REG_ODIGEST(dd, x)		((dd)->pdata->odigest_ofs + (x * 0x04))
 
 #define SHA_REG_CTRL			0x18
 #define SHA_REG_CTRL_LENGTH		(0xFFFFFFFF << 5)
@@ -75,18 +74,21 @@
 #define SHA_REG_SYSSTATUS(dd)		((dd)->pdata->sysstatus_ofs)
 #define SHA_REG_SYSSTATUS_RESETDONE	(1 << 0)
 
-#define SHA_REG_MODE			0x44
+#define SHA_REG_MODE(dd)		((dd)->pdata->mode_ofs)
 #define SHA_REG_MODE_HMAC_OUTER_HASH	(1 << 7)
 #define SHA_REG_MODE_HMAC_KEY_PROC	(1 << 5)
 #define SHA_REG_MODE_CLOSE_HASH		(1 << 4)
 #define SHA_REG_MODE_ALGO_CONSTANT	(1 << 3)
-#define SHA_REG_MODE_ALGO_MASK		(3 << 1)
-#define		SHA_REG_MODE_ALGO_MD5_128	(0 << 1)
-#define		SHA_REG_MODE_ALGO_SHA1_160	(1 << 1)
-#define		SHA_REG_MODE_ALGO_SHA2_224	(2 << 1)
-#define		SHA_REG_MODE_ALGO_SHA2_256	(3 << 1)
 
-#define SHA_REG_LENGTH			0x48
+#define SHA_REG_MODE_ALGO_MASK		(7 << 0)
+#define SHA_REG_MODE_ALGO_MD5_128	(0 << 1)
+#define SHA_REG_MODE_ALGO_SHA1_160	(1 << 1)
+#define SHA_REG_MODE_ALGO_SHA2_224	(2 << 1)
+#define SHA_REG_MODE_ALGO_SHA2_256	(3 << 1)
+#define SHA_REG_MODE_ALGO_SHA2_384	(1 << 0)
+#define SHA_REG_MODE_ALGO_SHA2_512	(3 << 0)
+
+#define SHA_REG_LENGTH(dd)		((dd)->pdata->length_ofs)
 
 #define SHA_REG_IRQSTATUS		0x118
 #define SHA_REG_IRQSTATUS_CTX_RDY	(1 << 3)
@@ -117,18 +119,16 @@
 #define FLAGS_SG		17
 
 #define FLAGS_MODE_SHIFT	18
-#define FLAGS_MODE_MASK		(SHA_REG_MODE_ALGO_MASK			\
-					<< (FLAGS_MODE_SHIFT - 1))
-#define		FLAGS_MODE_MD5		(SHA_REG_MODE_ALGO_MD5_128	\
-						<< (FLAGS_MODE_SHIFT - 1))
-#define		FLAGS_MODE_SHA1		(SHA_REG_MODE_ALGO_SHA1_160	\
-						<< (FLAGS_MODE_SHIFT - 1))
-#define		FLAGS_MODE_SHA224	(SHA_REG_MODE_ALGO_SHA2_224	\
-						<< (FLAGS_MODE_SHIFT - 1))
-#define		FLAGS_MODE_SHA256	(SHA_REG_MODE_ALGO_SHA2_256	\
-						<< (FLAGS_MODE_SHIFT - 1))
-#define FLAGS_HMAC		20
-#define FLAGS_ERROR		21
+#define FLAGS_MODE_MASK		(SHA_REG_MODE_ALGO_MASK	<< FLAGS_MODE_SHIFT)
+#define FLAGS_MODE_MD5		(SHA_REG_MODE_ALGO_MD5_128 << FLAGS_MODE_SHIFT)
+#define FLAGS_MODE_SHA1		(SHA_REG_MODE_ALGO_SHA1_160 << FLAGS_MODE_SHIFT)
+#define FLAGS_MODE_SHA224	(SHA_REG_MODE_ALGO_SHA2_224 << FLAGS_MODE_SHIFT)
+#define FLAGS_MODE_SHA256	(SHA_REG_MODE_ALGO_SHA2_256 << FLAGS_MODE_SHIFT)
+#define FLAGS_MODE_SHA384	(SHA_REG_MODE_ALGO_SHA2_384 << FLAGS_MODE_SHIFT)
+#define FLAGS_MODE_SHA512	(SHA_REG_MODE_ALGO_SHA2_512 << FLAGS_MODE_SHIFT)
+
+#define FLAGS_HMAC		21
+#define FLAGS_ERROR		22
 
 #define OP_UPDATE		1
 #define OP_FINAL		2
@@ -145,7 +145,7 @@ struct omap_sham_reqctx {
 	unsigned long		flags;
 	unsigned long		op;
 
-	u8			digest[SHA256_DIGEST_SIZE] OMAP_ALIGNED;
+	u8			digest[SHA512_DIGEST_SIZE] OMAP_ALIGNED;
 	size_t			digcnt;
 	size_t			bufcnt;
 	size_t			buflen;
@@ -162,8 +162,8 @@ struct omap_sham_reqctx {
 
 struct omap_sham_hmac_ctx {
 	struct crypto_shash	*shash;
-	u8			ipad[SHA1_MD5_BLOCK_SIZE] OMAP_ALIGNED;
-	u8			opad[SHA1_MD5_BLOCK_SIZE] OMAP_ALIGNED;
+	u8			ipad[SHA512_BLOCK_SIZE] OMAP_ALIGNED;
+	u8			opad[SHA512_BLOCK_SIZE] OMAP_ALIGNED;
 };
 
 struct omap_sham_ctx {
@@ -205,6 +205,8 @@ struct omap_sham_pdata {
 	u32		rev_ofs;
 	u32		mask_ofs;
 	u32		sysstatus_ofs;
+	u32		mode_ofs;
+	u32		length_ofs;
 
 	u32		major_mask;
 	u32		major_shift;
@@ -306,9 +308,9 @@ static void omap_sham_copy_hash_omap4(struct ahash_request *req, int out)
 		for (i = 0; i < dd->pdata->digest_size / sizeof(u32); i++) {
 			if (out)
 				opad[i] = omap_sham_read(dd,
-						SHA_REG_ODIGEST(i));
+						SHA_REG_ODIGEST(dd, i));
 			else
-				omap_sham_write(dd, SHA_REG_ODIGEST(i),
+				omap_sham_write(dd, SHA_REG_ODIGEST(dd, i),
 						opad[i]);
 		}
 	}
@@ -342,6 +344,12 @@ static void omap_sham_copy_ready_hash(struct ahash_request *req)
 	case FLAGS_MODE_SHA256:
 		d = SHA256_DIGEST_SIZE / sizeof(u32);
 		break;
+	case FLAGS_MODE_SHA384:
+		d = SHA384_DIGEST_SIZE / sizeof(u32);
+		break;
+	case FLAGS_MODE_SHA512:
+		d = SHA512_DIGEST_SIZE / sizeof(u32);
+		break;
 	default:
 		d = 0;
 	}
@@ -404,6 +412,30 @@ static int omap_sham_poll_irq_omap2(struct omap_sham_dev *dd)
 	return omap_sham_wait(dd, SHA_REG_CTRL, SHA_REG_CTRL_INPUT_READY);
 }
 
+static int get_block_size(struct omap_sham_reqctx *ctx)
+{
+	int d;
+
+	switch (ctx->flags & FLAGS_MODE_MASK) {
+	case FLAGS_MODE_MD5:
+	case FLAGS_MODE_SHA1:
+		d = SHA1_BLOCK_SIZE;
+		break;
+	case FLAGS_MODE_SHA224:
+	case FLAGS_MODE_SHA256:
+		d = SHA256_BLOCK_SIZE;
+		break;
+	case FLAGS_MODE_SHA384:
+	case FLAGS_MODE_SHA512:
+		d = SHA512_BLOCK_SIZE;
+		break;
+	default:
+		d = 0;
+	}
+
+	return d;
+}
+
 static void omap_sham_write_n(struct omap_sham_dev *dd, u32 offset,
 				    u32 *value, int count)
 {
@@ -422,20 +454,24 @@ static void omap_sham_write_ctrl_omap4(struct omap_sham_dev *dd, size_t length,
 	 * CLOSE_HASH only for the last one. Note that flags mode bits
 	 * correspond to algorithm encoding in mode register.
 	 */
-	val = (ctx->flags & FLAGS_MODE_MASK) >> (FLAGS_MODE_SHIFT - 1);
+	val = (ctx->flags & FLAGS_MODE_MASK) >> (FLAGS_MODE_SHIFT);
 	if (!ctx->digcnt) {
 		struct crypto_ahash *tfm = crypto_ahash_reqtfm(dd->req);
 		struct omap_sham_ctx *tctx = crypto_ahash_ctx(tfm);
 		struct omap_sham_hmac_ctx *bctx = tctx->base;
+		int bs, nr_dr;
 
 		val |= SHA_REG_MODE_ALGO_CONSTANT;
 
 		if (ctx->flags & BIT(FLAGS_HMAC)) {
+			bs = get_block_size(ctx);
+			nr_dr = bs / (2 * sizeof(u32));
 			val |= SHA_REG_MODE_HMAC_KEY_PROC;
-			omap_sham_write_n(dd, SHA_REG_ODIGEST(0),
-					  (u32 *)bctx->ipad,
-					  SHA1_BLOCK_SIZE / sizeof(u32));
-			ctx->digcnt += SHA1_BLOCK_SIZE;
+			omap_sham_write_n(dd, SHA_REG_ODIGEST(dd, 0),
+					  (u32 *)bctx->ipad, nr_dr);
+			omap_sham_write_n(dd, SHA_REG_IDIGEST(dd, 0),
+					  (u32 *)bctx->ipad + nr_dr, nr_dr);
+			ctx->digcnt += bs;
 		}
 	}
 
@@ -451,7 +487,7 @@ static void omap_sham_write_ctrl_omap4(struct omap_sham_dev *dd, size_t length,
 	       SHA_REG_MODE_HMAC_KEY_PROC;
 
 	dev_dbg(dd->dev, "ctrl: %08x, flags: %08lx\n", val, ctx->flags);
-	omap_sham_write_mask(dd, SHA_REG_MODE, val, mask);
+	omap_sham_write_mask(dd, SHA_REG_MODE(dd), val, mask);
 	omap_sham_write(dd, SHA_REG_IRQENA, SHA_REG_IRQENA_OUTPUT_RDY);
 	omap_sham_write_mask(dd, SHA_REG_MASK(dd),
 			     SHA_REG_MASK_IT_EN |
@@ -461,7 +497,7 @@ static void omap_sham_write_ctrl_omap4(struct omap_sham_dev *dd, size_t length,
 
 static void omap_sham_trigger_omap4(struct omap_sham_dev *dd, size_t length)
 {
-	omap_sham_write(dd, SHA_REG_LENGTH, length);
+	omap_sham_write(dd, SHA_REG_LENGTH(dd), length);
 }
 
 static int omap_sham_poll_irq_omap4(struct omap_sham_dev *dd)
@@ -666,14 +702,14 @@ static int omap_sham_update_dma_slow(struct omap_sham_dev *dd)
 /* Start address alignment */
 #define SG_AA(sg)	(IS_ALIGNED(sg->offset, sizeof(u32)))
 /* SHA1 block size alignment */
-#define SG_SA(sg)	(IS_ALIGNED(sg->length, SHA1_MD5_BLOCK_SIZE))
+#define SG_SA(sg, bs)	(IS_ALIGNED(sg->length, bs))
 
 static int omap_sham_update_dma_start(struct omap_sham_dev *dd)
 {
 	struct omap_sham_reqctx *ctx = ahash_request_ctx(dd->req);
 	unsigned int length, final, tail;
 	struct scatterlist *sg;
-	int ret;
+	int ret, bs;
 
 	if (!ctx->total)
 		return 0;
@@ -694,23 +730,24 @@ static int omap_sham_update_dma_start(struct omap_sham_dev *dd)
 			ctx->digcnt, ctx->bufcnt, ctx->total);
 
 	sg = ctx->sg;
+	bs = get_block_size(ctx);
 
 	if (!SG_AA(sg))
 		return omap_sham_update_dma_slow(dd);
 
-	if (!sg_is_last(sg) && !SG_SA(sg))
-		/* size is not SHA1_BLOCK_SIZE aligned */
+	if (!sg_is_last(sg) && !SG_SA(sg, bs))
+		/* size is not BLOCK_SIZE aligned */
 		return omap_sham_update_dma_slow(dd);
 
 	length = min(ctx->total, sg->length);
 
 	if (sg_is_last(sg)) {
 		if (!(ctx->flags & BIT(FLAGS_FINUP))) {
-			/* not last sg must be SHA1_MD5_BLOCK_SIZE aligned */
-			tail = length & (SHA1_MD5_BLOCK_SIZE - 1);
+			/* not last sg must be BLOCK_SIZE aligned */
+			tail = length & (bs - 1);
 			/* without finup() we need one block to close hash */
 			if (!tail)
-				tail = SHA1_MD5_BLOCK_SIZE;
+				tail = bs;
 			length -= tail;
 		}
 	}
@@ -773,6 +810,7 @@ static int omap_sham_init(struct ahash_request *req)
 	struct omap_sham_ctx *tctx = crypto_ahash_ctx(tfm);
 	struct omap_sham_reqctx *ctx = ahash_request_ctx(req);
 	struct omap_sham_dev *dd = NULL, *tmp;
+	int bs = 0;
 
 	spin_lock_bh(&sham.lock);
 	if (!tctx->dd) {
@@ -796,15 +834,27 @@ static int omap_sham_init(struct ahash_request *req)
 	switch (crypto_ahash_digestsize(tfm)) {
 	case MD5_DIGEST_SIZE:
 		ctx->flags |= FLAGS_MODE_MD5;
+		bs = SHA1_BLOCK_SIZE;
 		break;
 	case SHA1_DIGEST_SIZE:
 		ctx->flags |= FLAGS_MODE_SHA1;
+		bs = SHA1_BLOCK_SIZE;
 		break;
 	case SHA224_DIGEST_SIZE:
 		ctx->flags |= FLAGS_MODE_SHA224;
+		bs = SHA224_BLOCK_SIZE;
 		break;
 	case SHA256_DIGEST_SIZE:
 		ctx->flags |= FLAGS_MODE_SHA256;
+		bs = SHA256_BLOCK_SIZE;
+		break;
+	case SHA384_DIGEST_SIZE:
+		ctx->flags |= FLAGS_MODE_SHA384;
+		bs = SHA384_BLOCK_SIZE;
+		break;
+	case SHA512_DIGEST_SIZE:
+		ctx->flags |= FLAGS_MODE_SHA512;
+		bs = SHA512_BLOCK_SIZE;
 		break;
 	}
 
@@ -816,8 +866,8 @@ static int omap_sham_init(struct ahash_request *req)
 		if (!test_bit(FLAGS_AUTO_XOR, &dd->flags)) {
 			struct omap_sham_hmac_ctx *bctx = tctx->base;
 
-			memcpy(ctx->buffer, bctx->ipad, SHA1_MD5_BLOCK_SIZE);
-			ctx->bufcnt = SHA1_MD5_BLOCK_SIZE;
+			memcpy(ctx->buffer, bctx->ipad, bs);
+			ctx->bufcnt = bs;
 		}
 
 		ctx->flags |= BIT(FLAGS_HMAC);
@@ -1006,6 +1056,7 @@ static int omap_sham_enqueue(struct ahash_request *req, unsigned int op)
 static int omap_sham_update(struct ahash_request *req)
 {
 	struct omap_sham_reqctx *ctx = ahash_request_ctx(req);
+	int bs = get_block_size(ctx);
 
 	if (!req->nbytes)
 		return 0;
@@ -1023,7 +1074,7 @@ static int omap_sham_update(struct ahash_request *req)
 			*/
 			omap_sham_append_sg(ctx);
 			return 0;
-		} else if (ctx->bufcnt + ctx->total <= SHA1_MD5_BLOCK_SIZE) {
+		} else if (ctx->bufcnt + ctx->total <= bs) {
 			/*
 			* faster to use CPU for short transfers
 			*/
@@ -1214,6 +1265,16 @@ static int omap_sham_cra_md5_init(struct crypto_tfm *tfm)
 	return omap_sham_cra_init_alg(tfm, "md5");
 }
 
+static int omap_sham_cra_sha384_init(struct crypto_tfm *tfm)
+{
+	return omap_sham_cra_init_alg(tfm, "sha384");
+}
+
+static int omap_sham_cra_sha512_init(struct crypto_tfm *tfm)
+{
+	return omap_sham_cra_init_alg(tfm, "sha512");
+}
+
 static void omap_sham_cra_exit(struct crypto_tfm *tfm)
 {
 	struct omap_sham_ctx *tctx = crypto_tfm_ctx(tfm);
@@ -1422,6 +1483,101 @@ static struct ahash_alg algs_sha224_sha256[] = {
 },
 };
 
+static struct ahash_alg algs_sha384_sha512[] = {
+{
+	.init		= omap_sham_init,
+	.update		= omap_sham_update,
+	.final		= omap_sham_final,
+	.finup		= omap_sham_finup,
+	.digest		= omap_sham_digest,
+	.halg.digestsize	= SHA384_DIGEST_SIZE,
+	.halg.base	= {
+		.cra_name		= "sha384",
+		.cra_driver_name	= "omap-sha384",
+		.cra_priority		= 100,
+		.cra_flags		= CRYPTO_ALG_TYPE_AHASH |
+						CRYPTO_ALG_ASYNC |
+						CRYPTO_ALG_NEED_FALLBACK,
+		.cra_blocksize		= SHA384_BLOCK_SIZE,
+		.cra_ctxsize		= sizeof(struct omap_sham_ctx),
+		.cra_alignmask		= 0,
+		.cra_module		= THIS_MODULE,
+		.cra_init		= omap_sham_cra_init,
+		.cra_exit		= omap_sham_cra_exit,
+	}
+},
+{
+	.init		= omap_sham_init,
+	.update		= omap_sham_update,
+	.final		= omap_sham_final,
+	.finup		= omap_sham_finup,
+	.digest		= omap_sham_digest,
+	.halg.digestsize	= SHA512_DIGEST_SIZE,
+	.halg.base	= {
+		.cra_name		= "sha512",
+		.cra_driver_name	= "omap-sha512",
+		.cra_priority		= 100,
+		.cra_flags		= CRYPTO_ALG_TYPE_AHASH |
+						CRYPTO_ALG_ASYNC |
+						CRYPTO_ALG_NEED_FALLBACK,
+		.cra_blocksize		= SHA512_BLOCK_SIZE,
+		.cra_ctxsize		= sizeof(struct omap_sham_ctx),
+		.cra_alignmask		= 0,
+		.cra_module		= THIS_MODULE,
+		.cra_init		= omap_sham_cra_init,
+		.cra_exit		= omap_sham_cra_exit,
+	}
+},
+{
+	.init		= omap_sham_init,
+	.update		= omap_sham_update,
+	.final		= omap_sham_final,
+	.finup		= omap_sham_finup,
+	.digest		= omap_sham_digest,
+	.setkey		= omap_sham_setkey,
+	.halg.digestsize	= SHA384_DIGEST_SIZE,
+	.halg.base	= {
+		.cra_name		= "hmac(sha384)",
+		.cra_driver_name	= "omap-hmac-sha384",
+		.cra_priority		= 100,
+		.cra_flags		= CRYPTO_ALG_TYPE_AHASH |
+						CRYPTO_ALG_ASYNC |
+						CRYPTO_ALG_NEED_FALLBACK,
+		.cra_blocksize		= SHA384_BLOCK_SIZE,
+		.cra_ctxsize		= sizeof(struct omap_sham_ctx) +
+					sizeof(struct omap_sham_hmac_ctx),
+		.cra_alignmask		= OMAP_ALIGN_MASK,
+		.cra_module		= THIS_MODULE,
+		.cra_init		= omap_sham_cra_sha384_init,
+		.cra_exit		= omap_sham_cra_exit,
+	}
+},
+{
+	.init		= omap_sham_init,
+	.update		= omap_sham_update,
+	.final		= omap_sham_final,
+	.finup		= omap_sham_finup,
+	.digest		= omap_sham_digest,
+	.setkey		= omap_sham_setkey,
+	.halg.digestsize	= SHA512_DIGEST_SIZE,
+	.halg.base	= {
+		.cra_name		= "hmac(sha512)",
+		.cra_driver_name	= "omap-hmac-sha512",
+		.cra_priority		= 100,
+		.cra_flags		= CRYPTO_ALG_TYPE_AHASH |
+						CRYPTO_ALG_ASYNC |
+						CRYPTO_ALG_NEED_FALLBACK,
+		.cra_blocksize		= SHA512_BLOCK_SIZE,
+		.cra_ctxsize		= sizeof(struct omap_sham_ctx) +
+					sizeof(struct omap_sham_hmac_ctx),
+		.cra_alignmask		= OMAP_ALIGN_MASK,
+		.cra_module		= THIS_MODULE,
+		.cra_init		= omap_sham_cra_sha512_init,
+		.cra_exit		= omap_sham_cra_exit,
+	}
+},
+};
+
 static void omap_sham_done_task(unsigned long data)
 {
 	struct omap_sham_dev *dd = (struct omap_sham_dev *)data;
@@ -1548,11 +1704,14 @@ static const struct omap_sham_pdata omap_sham_pdata_omap4 = {
 	.poll_irq	= omap_sham_poll_irq_omap4,
 	.intr_hdlr	= omap_sham_irq_omap4,
 	.idigest_ofs	= 0x020,
+	.odigest_ofs	= 0x0,
 	.din_ofs	= 0x080,
 	.digcnt_ofs	= 0x040,
 	.rev_ofs	= 0x100,
 	.mask_ofs	= 0x110,
 	.sysstatus_ofs	= 0x114,
+	.mode_ofs	= 0x44,
+	.length_ofs	= 0x48,
 	.major_mask	= 0x0700,
 	.major_shift	= 8,
 	.minor_mask	= 0x003f,
-- 
1.7.9.5



From lokeshvutla at ti.com  Fri Jul 26 02:59:16 2013
From: lokeshvutla at ti.com (Lokesh Vutla)
Date: Fri, 26 Jul 2013 12:29:16 +0530
Subject: [PATCH 3/4] crypto: omap-sham: Convert to devm_request_irq()
In-Reply-To: <1374821957-30141-1-git-send-email-lokeshvutla@ti.com>
References: <1374821957-30141-1-git-send-email-lokeshvutla@ti.com>
Message-ID: <1374821957-30141-4-git-send-email-lokeshvutla@ti.com>

Using devm_request_irq() rather than request_irq().
So removing free_irq() calls from the probe error
path and the remove handler.

Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
---
 drivers/crypto/omap-sham.c |   12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index a6eb6a8..b82b140 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1896,10 +1896,11 @@ static int omap_sham_probe(struct platform_device *pdev)
 	}
 	dd->phys_base = res.start;
 
-	err = request_irq(dd->irq, dd->pdata->intr_hdlr, IRQF_TRIGGER_LOW,
-			  dev_name(dev), dd);
+	err = devm_request_irq(dev, dd->irq, dd->pdata->intr_hdlr,
+			       IRQF_TRIGGER_NONE, dev_name(dev), dd);
 	if (err) {
-		dev_err(dev, "unable to request irq.\n");
+		dev_err(dev, "unable to request irq %d, err = %d\n",
+			dd->irq, err);
 		goto res_err;
 	}
 
@@ -1912,7 +1913,7 @@ static int omap_sham_probe(struct platform_device *pdev)
 		dev_err(dev, "unable to obtain RX DMA engine channel %u\n",
 			dd->dma);
 		err = -ENXIO;
-		goto dma_err;
+		goto res_err;
 	}
 
 	dd->flags |= dd->pdata->flags;
@@ -1950,8 +1951,6 @@ err_algs:
 					&dd->pdata->algs_info[i].algs_list[j]);
 	pm_runtime_disable(dev);
 	dma_release_channel(dd->dma_lch);
-dma_err:
-	free_irq(dd->irq, dd);
 res_err:
 	kfree(dd);
 	dd = NULL;
@@ -1979,7 +1978,6 @@ static int omap_sham_remove(struct platform_device *pdev)
 	tasklet_kill(&dd->done_task);
 	pm_runtime_disable(&pdev->dev);
 	dma_release_channel(dd->dma_lch);
-	free_irq(dd->irq, dd);
 	kfree(dd);
 	dd = NULL;
 
-- 
1.7.9.5



From lokeshvutla at ti.com  Fri Jul 26 02:59:17 2013
From: lokeshvutla at ti.com (Lokesh Vutla)
Date: Fri, 26 Jul 2013 12:29:17 +0530
Subject: [PATCH 4/4] crypto: omap-sham: Convert to devm_kzalloc()
In-Reply-To: <1374821957-30141-1-git-send-email-lokeshvutla@ti.com>
References: <1374821957-30141-1-git-send-email-lokeshvutla@ti.com>
Message-ID: <1374821957-30141-5-git-send-email-lokeshvutla@ti.com>

Use devm_kzalloc() to make cleanup paths simpler.

Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
---
 drivers/crypto/omap-sham.c |   15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index b82b140..ae1ca8b2 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1870,7 +1870,7 @@ static int omap_sham_probe(struct platform_device *pdev)
 	int err, i, j;
 	u32 rev;
 
-	dd = kzalloc(sizeof(struct omap_sham_dev), GFP_KERNEL);
+	dd = devm_kzalloc(dev, sizeof(struct omap_sham_dev), GFP_KERNEL);
 	if (dd == NULL) {
 		dev_err(dev, "unable to alloc data struct.\n");
 		err = -ENOMEM;
@@ -1887,12 +1887,12 @@ static int omap_sham_probe(struct platform_device *pdev)
 	err = (dev->of_node) ? omap_sham_get_res_of(dd, dev, &res) :
 			       omap_sham_get_res_pdev(dd, pdev, &res);
 	if (err)
-		goto res_err;
+		goto data_err;
 
 	dd->io_base = devm_ioremap_resource(dev, &res);
 	if (IS_ERR(dd->io_base)) {
 		err = PTR_ERR(dd->io_base);
-		goto res_err;
+		goto data_err;
 	}
 	dd->phys_base = res.start;
 
@@ -1901,7 +1901,7 @@ static int omap_sham_probe(struct platform_device *pdev)
 	if (err) {
 		dev_err(dev, "unable to request irq %d, err = %d\n",
 			dd->irq, err);
-		goto res_err;
+		goto data_err;
 	}
 
 	dma_cap_zero(mask);
@@ -1913,7 +1913,7 @@ static int omap_sham_probe(struct platform_device *pdev)
 		dev_err(dev, "unable to obtain RX DMA engine channel %u\n",
 			dd->dma);
 		err = -ENXIO;
-		goto res_err;
+		goto data_err;
 	}
 
 	dd->flags |= dd->pdata->flags;
@@ -1951,9 +1951,6 @@ err_algs:
 					&dd->pdata->algs_info[i].algs_list[j]);
 	pm_runtime_disable(dev);
 	dma_release_channel(dd->dma_lch);
-res_err:
-	kfree(dd);
-	dd = NULL;
 data_err:
 	dev_err(dev, "initialization failed.\n");
 
@@ -1978,8 +1975,6 @@ static int omap_sham_remove(struct platform_device *pdev)
 	tasklet_kill(&dd->done_task);
 	pm_runtime_disable(&pdev->dev);
 	dma_release_channel(dd->dma_lch);
-	kfree(dd);
-	dd = NULL;
 
 	return 0;
 }
-- 
1.7.9.5



From g.liakhovetski at gmx.de  Fri Jul 26 03:01:23 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri, 26 Jul 2013 09:01:23 +0200 (CEST)
Subject: [PATCH 00/12] Remove platform callbacks from mmc_spi, sh_mmcif
 and sh_mobile_sdhi drivers
In-Reply-To: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <Pine.LNX.4.64.1307260859410.20450@axis700.grange>

Hi Laurent

On Fri, 26 Jul 2013, Laurent Pinchart wrote:

> Hello,
> 
> This patch set replaces callbacks to board code with regulators and GPIOs in
> the mmc_spi, sh_mmcif and sh_mobile_sdhi MMC drivers.
> 
> Most of the required infrastructure is in place already on the drivers side,
> except for CD/RO GPIOs support in the mmc_spi driver. The series thus starts
> with patch 01/12 that adds this feature to the mmc_spi driver.
> 
> Patches 02/12 to 05/12 remove the board callbacks from the ecovec24 and
> vision_ep9307 boards. The code has been compile-tested only as I don't have
> access to those boards.
> 
> Patches 06/12 to 07/12 then proceed to remove the callbacks from the drivers
> themselves and from the platform data structures.
> 
> This will be a bit messy to merge, as the series interleaves patches for
> drivers and board files. Given that the mmc_spi driver is marked as orphan in
> MAINTAINERS and that the vision_ep9307 hasn't seen any board-specific
> modification in the last couple of kernel versions one option would be to
> merge all patches (or at least patches 01/12 to 06/12) through Simon's tree if
> all involved maintainers agree.
> 
> The series is based on tag renesas-devel-20130725 from
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
> 
> Laurent Pinchart (12):
>   mmc: mmc_spi: Support CD/RO GPIOs
>   ARM: ep93xx: vision_ep9307: Use MMC CD and RO GPIO
>   sh: ecovec24: Use MMC/SDHI CD and RO GPIO
>   sh: ecovec24: Remove mmcif .down_pwr() callback
>   sh: ecovec24: Remove MMCIF and SDHI .set_pwr() callbacks
>   mmc: mmc_spi: Remove platform data .get_cd() and .get_ro() callbacks
>   mmc: sh_mmcif: Remove .down_pwr() callback from platform data
>   mmc: sh_mmcif: Remove .set_pwr() callback from platform data
>   mmc: sh_mobile_sdhi: Remove .get_cd() callback from platform data
>   mmc: sh_mobile_sdhi: Remove .set_pwr() callback from platform data
>   mmc: tmio-mmc: Remove .get_cd() callback from platform data
>   mmc: tmio-mmc: Remove .set_pwr() callback from platform data

For #3-5, 7-12

Acked-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Thanks
Guennadi

>  arch/arm/mach-ep93xx/vision_ep9307.c | 56 ++---------------------
>  arch/sh/boards/mach-ecovec24/setup.c | 89 ++++--------------------------------
>  drivers/mmc/host/mmc_spi.c           | 48 +++++++++----------
>  drivers/mmc/host/of_mmc_spi.c        | 46 +++++--------------
>  drivers/mmc/host/sh_mmcif.c          |  3 --
>  drivers/mmc/host/sh_mobile_sdhi.c    | 18 --------
>  drivers/mmc/host/tmio_mmc.h          |  1 -
>  drivers/mmc/host/tmio_mmc_pio.c      | 23 +---------
>  include/linux/mfd/tmio.h             |  2 -
>  include/linux/mmc/sh_mmcif.h         |  2 -
>  include/linux/mmc/sh_mobile_sdhi.h   |  2 -
>  include/linux/spi/mmc_spi.h          | 18 ++++----
>  12 files changed, 56 insertions(+), 252 deletions(-)
> 
> -- 
> Regards,
> 
> Laurent Pinchart

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/


From tomi.valkeinen at ti.com  Fri Jul 26 03:08:03 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:03 +0300
Subject: [PATCH 00/21] ARM: OMAP2+: use new display drivers
Message-ID: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>

Hi,

The display drivers for new OMAP DSS driver model were merged in v3.11, but the
board files were not changed to use them. This series changes the board files
to take those new drivers into use.

There's mostly nothing special in the patches. One complication is with Overo
board file, which adds two panel devices, located in add-on boards, that use
the same GPIOs, meaning that the two panel devices cannot be probed at the same
time. The solution used here is to parse the kernel command line, and decide
the panel device to be added depending on the given default display.

The omap2plus_defconfig is changed to include a few most commonly used display
drivers as modules, and the old drivers are removed.

Note: The first patch in this series has been sent separately
(http://mid.gmane.org/1374570405-8301-2-git-send-email-tomi.valkeinen at ti.com),
and is a fix for v3.11. It's included here as an another patch in the series
depends on it.

Tested on 4430SDP, Panda, Beagle, Beagle xM, Overo.

 Tomi

Tomi Valkeinen (21):
  ARM: OMAP: dss-common: fix Panda's DVI DDC channel
  ARM: OMAP2+: Remove legacy DSS initialization for omap4
  ARM: OMAP2+: Add selected display drivers to omap2plus_defconfig
  ARM: OMAP: dss-common: use new display drivers
  ARM: OMAP: 4430SDP: remove picodlp device data
  ARM: OMAP: overo: use new display drivers
  ARM: OMAP: rx51: use new display drivers
  ARM: OMAP: beagle: use new display drivers
  ARM: OMAP: devkit8000: use new display drivers
  ARM: OMAP: 2430SDP: use new display drivers
  ARM: OMAP: LDP: use new display drivers
  ARM: OMAP: omap3stalker: use new display drivers
  ARM: OMAP: igep0020: use new display drivers
  ARM: OMAP: cm-t35: use new display drivers
  ARM: OMAP: H4: use new display drivers
  ARM: OMAP: 3430SDP: use new display drivers
  ARM: OMAP: OMAP3EVM: use new display drivers
  ARM: OMAP: Pandora: use new display drivers
  ARM: OMAP: Zoom: use new display drivers
  ARM: OMAP: AM3517EVM: use new display drivers
  ARM: OMAP2+: Remove old display drivers from omap2plus_defconfig

 arch/arm/configs/omap2plus_defconfig         |  12 +-
 arch/arm/mach-omap2/board-2430sdp.c          |  57 ++++---
 arch/arm/mach-omap2/board-3430sdp.c          |  83 +++++----
 arch/arm/mach-omap2/board-am3517evm.c        | 113 +++++++++----
 arch/arm/mach-omap2/board-cm-t35.c           | 100 +++++++----
 arch/arm/mach-omap2/board-devkit8000.c       |  96 +++++++----
 arch/arm/mach-omap2/board-h4.c               |  48 ++++--
 arch/arm/mach-omap2/board-igep0020.c         |  36 ++--
 arch/arm/mach-omap2/board-ldp.c              |  68 +++++---
 arch/arm/mach-omap2/board-omap3beagle.c      |  56 +++---
 arch/arm/mach-omap2/board-omap3evm.c         |  87 ++++++----
 arch/arm/mach-omap2/board-omap3pandora.c     |  48 +++---
 arch/arm/mach-omap2/board-omap3stalker.c     |  61 ++++---
 arch/arm/mach-omap2/board-overo.c            | 160 +++++++++++-------
 arch/arm/mach-omap2/board-rx51-peripherals.c |  12 ++
 arch/arm/mach-omap2/board-rx51-video.c       |  35 ++--
 arch/arm/mach-omap2/board-zoom-display.c     |  30 ++--
 arch/arm/mach-omap2/dss-common.c             | 244 ++++++++++++---------------
 arch/arm/mach-omap2/dss-common.h             |   2 -
 19 files changed, 787 insertions(+), 561 deletions(-)

-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:06 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:06 +0300
Subject: [PATCH 03/21] ARM: OMAP2+: Add selected display drivers to
 omap2plus_defconfig
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-4-git-send-email-tomi.valkeinen@ti.com>

Add some of the most common new display drivers to omap2plus_defconfig
to be built as modules.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/configs/omap2plus_defconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 5339e6a..7ce1c29 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -192,6 +192,11 @@ CONFIG_PANEL_NEC_NL8048HL11_01B=m
 CONFIG_PANEL_TAAL=m
 CONFIG_PANEL_TPO_TD043MTEA1=m
 CONFIG_PANEL_ACX565AKM=m
+CONFIG_DISPLAY_ENCODER_TFP410=m
+CONFIG_DISPLAY_ENCODER_TPD12S015=m
+CONFIG_DISPLAY_CONNECTOR_DVI=m
+CONFIG_DISPLAY_CONNECTOR_HDMI=m
+CONFIG_DISPLAY_PANEL_DPI=m
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_PLATFORM=y
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:04 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:04 +0300
Subject: [PATCH 01/21] ARM: OMAP: dss-common: fix Panda's DVI DDC channel
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-2-git-send-email-tomi.valkeinen@ti.com>

Panda's DVI connector's DDC pins are connected to OMAP's third i2c bus.
With non-DT, the bus number was 3, and that is what is used in the
dss-common.c which contains the platform data for Panda's DVI.

However, with DT, the bus number is 2. As we now only have DT boot for
Panda, we have to change the bus number to make DVI EDID read
operational.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/dss-common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 393aeef..043e570 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -42,7 +42,7 @@
 
 /* Using generic display panel */
 static struct tfp410_platform_data omap4_dvi_panel = {
-	.i2c_bus_num		= 3,
+	.i2c_bus_num		= 2,
 	.power_down_gpio	= PANDA_DVI_TFP410_POWER_DOWN_GPIO,
 };
 
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:05 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:05 +0300
Subject: [PATCH 02/21] ARM: OMAP2+: Remove legacy DSS initialization for omap4
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-3-git-send-email-tomi.valkeinen@ti.com>

This is no longer needed as omap4 is now booted using device tree.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/dss-common.c | 47 ----------------------------------------
 arch/arm/mach-omap2/dss-common.h |  2 --
 2 files changed, 49 deletions(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 043e570..00c0492 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -80,24 +80,6 @@ static struct omap_dss_board_info omap4_panda_dss_data = {
 	.default_device	= &omap4_panda_dvi_device,
 };
 
-void __init omap4_panda_display_init(void)
-{
-	omap_display_init(&omap4_panda_dss_data);
-
-	/*
-	 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
-	 * later have external pull up on the HDMI I2C lines
-	 */
-	if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
-		omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
-	else
-		omap_hdmi_init(0);
-
-	omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
-}
-
 void __init omap4_panda_display_init_of(void)
 {
 	omap_display_init(&omap4_panda_dss_data);
@@ -204,35 +186,6 @@ static struct omap_dss_board_info sdp4430_dss_data = {
  * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
  * selected by default
  */
-void __init omap_4430sdp_display_init(void)
-{
-	int r;
-
-	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
-			"display_sel");
-	if (r)
-		pr_err("%s: Could not get display_sel GPIO\n", __func__);
-
-	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
-		"DLP POWER ON");
-	if (r)
-		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
-
-	omap_display_init(&sdp4430_dss_data);
-	/*
-	 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
-	 * later have external pull up on the HDMI I2C lines
-	 */
-	if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
-		omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
-	else
-		omap_hdmi_init(0);
-
-	omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
-}
-
 void __init omap_4430sdp_display_init_of(void)
 {
 	int r;
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
index 915f6ff..c28fe3c 100644
--- a/arch/arm/mach-omap2/dss-common.h
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -6,9 +6,7 @@
  * This file will be removed when DSS supports DT.
  */
 
-void __init omap4_panda_display_init(void);
 void __init omap4_panda_display_init_of(void);
-void __init omap_4430sdp_display_init(void);
 void __init omap_4430sdp_display_init_of(void);
 
 #endif
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:07 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:07 +0300
Subject: [PATCH 04/21] ARM: OMAP: dss-common: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-5-git-send-email-tomi.valkeinen@ti.com>

Use the new display drivers for OMAP4 Panda and OMAP4 SDP boards.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/dss-common.c | 186 +++++++++++++++++++++++----------------
 1 file changed, 109 insertions(+), 77 deletions(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 00c0492..3215412 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -25,6 +25,7 @@
 
 #include <linux/kernel.h>
 #include <linux/gpio.h>
+#include <linux/platform_device.h>
 
 #include <video/omapdss.h>
 #include <video/omap-panel-data.h>
@@ -37,52 +38,76 @@
 #define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
 #define HDMI_GPIO_HPD  63 /* Hotplug detect */
 
-/* Display DVI */
 #define PANDA_DVI_TFP410_POWER_DOWN_GPIO	0
 
-/* Using generic display panel */
-static struct tfp410_platform_data omap4_dvi_panel = {
-	.i2c_bus_num		= 2,
-	.power_down_gpio	= PANDA_DVI_TFP410_POWER_DOWN_GPIO,
+/* DVI Connector */
+static struct connector_dvi_platform_data omap4_panda_dvi_connector_pdata = {
+	.name                   = "dvi",
+	.source                 = "tfp410.0",
+	.i2c_bus_num            = 2,
 };
 
-static struct omap_dss_device omap4_panda_dvi_device = {
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.name			= "dvi",
-	.driver_name		= "tfp410",
-	.data			= &omap4_dvi_panel,
-	.phy.dpi.data_lines	= 24,
-	.channel		= OMAP_DSS_CHANNEL_LCD2,
+static struct platform_device omap4_panda_dvi_connector_device = {
+	.name                   = "connector-dvi",
+	.id                     = 0,
+	.dev.platform_data      = &omap4_panda_dvi_connector_pdata,
+};
+
+/* TFP410 DPI-to-DVI chip */
+static struct encoder_tfp410_platform_data omap4_panda_tfp410_pdata = {
+	.name                   = "tfp410.0",
+	.source                 = "dpi.0",
+	.data_lines             = 24,
+	.power_down_gpio        = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
+};
+
+static struct platform_device omap4_panda_tfp410_device = {
+	.name                   = "tfp410",
+	.id                     = 0,
+	.dev.platform_data      = &omap4_panda_tfp410_pdata,
 };
 
-static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
+/* HDMI Connector */
+static struct connector_hdmi_platform_data omap4_panda_hdmi_connector_pdata = {
+	.name                   = "hdmi",
+	.source                 = "tpd12s015.0",
+};
+
+static struct platform_device omap4_panda_hdmi_connector_device = {
+	.name                   = "connector-hdmi",
+	.id                     = 0,
+	.dev.platform_data      = &omap4_panda_hdmi_connector_pdata,
+};
+
+/* TPD12S015 HDMI ESD protection & level shifter chip */
+static struct encoder_tpd12s015_platform_data omap4_panda_tpd_pdata = {
+	.name                   = "tpd12s015.0",
+	.source                 = "hdmi.0",
+
 	.ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
 	.ls_oe_gpio = HDMI_GPIO_LS_OE,
 	.hpd_gpio = HDMI_GPIO_HPD,
 };
 
-static struct omap_dss_device  omap4_panda_hdmi_device = {
-	.name = "hdmi",
-	.driver_name = "hdmi_panel",
-	.type = OMAP_DISPLAY_TYPE_HDMI,
-	.channel = OMAP_DSS_CHANNEL_DIGIT,
-	.data = &omap4_panda_hdmi_data,
-};
-
-static struct omap_dss_device *omap4_panda_dss_devices[] = {
-	&omap4_panda_dvi_device,
-	&omap4_panda_hdmi_device,
+static struct platform_device omap4_panda_tpd_device = {
+	.name                   = "tpd12s015",
+	.id                     = 0,
+	.dev.platform_data      = &omap4_panda_tpd_pdata,
 };
 
 static struct omap_dss_board_info omap4_panda_dss_data = {
-	.num_devices	= ARRAY_SIZE(omap4_panda_dss_devices),
-	.devices	= omap4_panda_dss_devices,
-	.default_device	= &omap4_panda_dvi_device,
+	.default_display_name = "dvi",
 };
 
 void __init omap4_panda_display_init_of(void)
 {
 	omap_display_init(&omap4_panda_dss_data);
+
+	platform_device_register(&omap4_panda_tfp410_device);
+	platform_device_register(&omap4_panda_dvi_connector_device);
+
+	platform_device_register(&omap4_panda_tpd_device);
+	platform_device_register(&omap4_panda_hdmi_connector_device);
 }
 
 
@@ -91,67 +116,71 @@ void __init omap4_panda_display_init_of(void)
 #define DISPLAY_SEL_GPIO	59	/* LCD2/PicoDLP switch */
 #define DLP_POWER_ON_GPIO	40
 
-static struct nokia_dsi_panel_data dsi1_panel = {
-		.name		= "taal",
-		.reset_gpio	= 102,
-		.use_ext_te	= false,
-		.ext_te_gpio	= 101,
-		.esd_interval	= 0,
-		.pin_config = {
-			.num_pins	= 6,
-			.pins		= { 0, 1, 2, 3, 4, 5 },
-		},
-};
-
-static struct omap_dss_device sdp4430_lcd_device = {
-	.name			= "lcd",
-	.driver_name		= "taal",
-	.type			= OMAP_DISPLAY_TYPE_DSI,
-	.data			= &dsi1_panel,
-	.phy.dsi		= {
-		.module		= 0,
+static struct panel_dsicm_platform_data dsi1_panel = {
+	.name		= "lcd",
+	.source		= "dsi.0",
+	.reset_gpio	= 102,
+	.use_ext_te	= false,
+	.ext_te_gpio	= 101,
+	.pin_config = {
+		.num_pins	= 6,
+		.pins		= { 0, 1, 2, 3, 4, 5 },
 	},
-	.channel		= OMAP_DSS_CHANNEL_LCD,
 };
 
-static struct nokia_dsi_panel_data dsi2_panel = {
-		.name		= "taal",
-		.reset_gpio	= 104,
-		.use_ext_te	= false,
-		.ext_te_gpio	= 103,
-		.esd_interval	= 0,
-		.pin_config = {
-			.num_pins	= 6,
-			.pins		= { 0, 1, 2, 3, 4, 5 },
-		},
+static struct platform_device sdp4430_lcd_device = {
+	.name                   = "panel-dsi-cm",
+	.id                     = 0,
+	.dev.platform_data	= &dsi1_panel,
 };
 
-static struct omap_dss_device sdp4430_lcd2_device = {
-	.name			= "lcd2",
-	.driver_name		= "taal",
-	.type			= OMAP_DISPLAY_TYPE_DSI,
-	.data			= &dsi2_panel,
-	.phy.dsi		= {
-
-		.module		= 1,
+static struct panel_dsicm_platform_data dsi2_panel = {
+	.name		= "lcd2",
+	.source		= "dsi.1",
+	.reset_gpio	= 104,
+	.use_ext_te	= false,
+	.ext_te_gpio	= 103,
+	.pin_config = {
+		.num_pins	= 6,
+		.pins		= { 0, 1, 2, 3, 4, 5 },
 	},
-	.channel		= OMAP_DSS_CHANNEL_LCD2,
 };
 
-static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
+static struct platform_device sdp4430_lcd2_device = {
+	.name                   = "panel-dsi-cm",
+	.id                     = 1,
+	.dev.platform_data	= &dsi2_panel,
+};
+
+/* HDMI Connector */
+static struct connector_hdmi_platform_data sdp4430_hdmi_connector_pdata = {
+	.name                   = "hdmi",
+	.source                 = "tpd12s015.0",
+};
+
+static struct platform_device sdp4430_hdmi_connector_device = {
+	.name                   = "connector-hdmi",
+	.id                     = 0,
+	.dev.platform_data      = &sdp4430_hdmi_connector_pdata,
+};
+
+/* TPD12S015 HDMI ESD protection & level shifter chip */
+static struct encoder_tpd12s015_platform_data sdp4430_tpd_pdata = {
+	.name                   = "tpd12s015.0",
+	.source                 = "hdmi.0",
+
 	.ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
 	.ls_oe_gpio = HDMI_GPIO_LS_OE,
 	.hpd_gpio = HDMI_GPIO_HPD,
 };
 
-static struct omap_dss_device sdp4430_hdmi_device = {
-	.name = "hdmi",
-	.driver_name = "hdmi_panel",
-	.type = OMAP_DISPLAY_TYPE_HDMI,
-	.channel = OMAP_DSS_CHANNEL_DIGIT,
-	.data = &sdp4430_hdmi_data,
+static struct platform_device sdp4430_tpd_device = {
+	.name                   = "tpd12s015",
+	.id                     = 0,
+	.dev.platform_data      = &sdp4430_tpd_pdata,
 };
 
+
 static struct picodlp_panel_data sdp4430_picodlp_pdata = {
 	.picodlp_adapter_id	= 2,
 	.emu_done_gpio		= 44,
@@ -168,16 +197,13 @@ static struct omap_dss_device sdp4430_picodlp_device = {
 };
 
 static struct omap_dss_device *sdp4430_dss_devices[] = {
-	&sdp4430_lcd_device,
-	&sdp4430_lcd2_device,
-	&sdp4430_hdmi_device,
 	&sdp4430_picodlp_device,
 };
 
 static struct omap_dss_board_info sdp4430_dss_data = {
 	.num_devices	= ARRAY_SIZE(sdp4430_dss_devices),
 	.devices	= sdp4430_dss_devices,
-	.default_device	= &sdp4430_lcd_device,
+	.default_display_name = "lcd",
 };
 
 /*
@@ -201,4 +227,10 @@ void __init omap_4430sdp_display_init_of(void)
 		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
 
 	omap_display_init(&sdp4430_dss_data);
+
+	platform_device_register(&sdp4430_lcd_device);
+	platform_device_register(&sdp4430_lcd2_device);
+
+	platform_device_register(&sdp4430_tpd_device);
+	platform_device_register(&sdp4430_hdmi_connector_device);
 }
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:09 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:09 +0300
Subject: [PATCH 06/21] ARM: OMAP: overo: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-7-git-send-email-tomi.valkeinen@ti.com>

Use the new display drivers for OMAP3 Overo board.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Note that the LCD add-on boards for lcd43 and lcd35 use the same GPIOs
for the panels. This means that both panel devices cannot be probed at
the same time.

DT will handle this correctly, i.e. the DT data will contain the panel
device only for the add-on board that is attached. However, for the
board file we need a hackish solution: We parse the kernel boot command
line, and see whether lcd43 or lcd35 is set as a default display, and
add the given one. Or, if neither is given, default to lcd43.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/board-overo.c | 160 ++++++++++++++++++++++++--------------
 1 file changed, 100 insertions(+), 60 deletions(-)

diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 5748b5d..f6d3841 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -72,6 +72,9 @@
 #define OVERO_SMSC911X2_CS     4
 #define OVERO_SMSC911X2_GPIO   65
 
+/* whether to register LCD35 instead of LCD43 */
+static bool overo_use_lcd35;
+
 #if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
 	defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
 
@@ -149,78 +152,94 @@ static inline void __init overo_init_smsc911x(void) { return; }
 #define OVERO_GPIO_LCD_EN 144
 #define OVERO_GPIO_LCD_BL 145
 
-static struct tfp410_platform_data dvi_panel = {
-	.i2c_bus_num		= 3,
-	.power_down_gpio	= -1,
+static struct connector_atv_platform_data overo_tv_pdata = {
+	.name = "tv",
+	.source = "venc.0",
+	.connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+	.invert_polarity = false,
 };
 
-static struct omap_dss_device overo_dvi_device = {
-	.name			= "dvi",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.driver_name		= "tfp410",
-	.data			= &dvi_panel,
-	.phy.dpi.data_lines	= 24,
+static struct platform_device overo_tv_connector_device = {
+	.name                   = "connector-analog-tv",
+	.id                     = 0,
+	.dev.platform_data      = &overo_tv_pdata,
 };
 
-static struct omap_dss_device overo_tv_device = {
-	.name = "tv",
-	.driver_name = "venc",
-	.type = OMAP_DISPLAY_TYPE_VENC,
-	.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+static const struct display_timing overo_lcd43_videomode = {
+	.pixelclock	= { 0, 9200000, 0 },
+
+	.hactive = { 0, 480, 0 },
+	.hfront_porch = { 0, 8, 0 },
+	.hback_porch = { 0, 4, 0 },
+	.hsync_len = { 0, 41, 0 },
+
+	.vactive = { 0, 272, 0 },
+	.vfront_porch = { 0, 4, 0 },
+	.vback_porch = { 0, 2, 0 },
+	.vsync_len = { 0, 10, 0 },
+
+	.flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+		DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
 };
 
-static struct panel_generic_dpi_data lcd43_panel = {
-	.name			= "samsung_lte430wq_f0c",
-	.num_gpios		= 2,
-	.gpios			= {
-		OVERO_GPIO_LCD_EN,
-		OVERO_GPIO_LCD_BL
-	},
+static struct panel_dpi_platform_data overo_lcd43_pdata = {
+	.name                   = "lcd43",
+	.source                 = "dpi.0",
+
+	.data_lines		= 24,
+
+	.display_timing		= &overo_lcd43_videomode,
+
+	.enable_gpio		= OVERO_GPIO_LCD_EN,
+	.backlight_gpio		= OVERO_GPIO_LCD_BL,
 };
 
-static struct omap_dss_device overo_lcd43_device = {
-	.name			= "lcd43",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.driver_name		= "generic_dpi_panel",
-	.data			= &lcd43_panel,
-	.phy.dpi.data_lines	= 24,
+static struct platform_device overo_lcd43_device = {
+	.name                   = "panel-dpi",
+	.id                     = 0,
+	.dev.platform_data      = &overo_lcd43_pdata,
 };
 
-#if defined(CONFIG_PANEL_LGPHILIPS_LB035Q02) || \
-	defined(CONFIG_PANEL_LGPHILIPS_LB035Q02_MODULE)
-static struct panel_generic_dpi_data lcd35_panel = {
-	.num_gpios		= 2,
-	.gpios			= {
-		OVERO_GPIO_LCD_EN,
-		OVERO_GPIO_LCD_BL
-	},
+static struct connector_dvi_platform_data overo_dvi_connector_pdata = {
+	.name                   = "dvi",
+	.source                 = "tfp410.0",
+	.i2c_bus_num            = 3,
 };
 
-static struct omap_dss_device overo_lcd35_device = {
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.name			= "lcd35",
-	.driver_name		= "lgphilips_lb035q02_panel",
-	.phy.dpi.data_lines	= 24,
-	.data			= &lcd35_panel,
+static struct platform_device overo_dvi_connector_device = {
+	.name                   = "connector-dvi",
+	.id                     = 0,
+	.dev.platform_data      = &overo_dvi_connector_pdata,
 };
-#endif
 
-static struct omap_dss_device *overo_dss_devices[] = {
-	&overo_dvi_device,
-	&overo_tv_device,
-#if defined(CONFIG_PANEL_LGPHILIPS_LB035Q02) || \
-	defined(CONFIG_PANEL_LGPHILIPS_LB035Q02_MODULE)
-	&overo_lcd35_device,
-#endif
-	&overo_lcd43_device,
+static struct encoder_tfp410_platform_data overo_tfp410_pdata = {
+	.name                   = "tfp410.0",
+	.source                 = "dpi.0",
+	.data_lines             = 24,
+	.power_down_gpio        = -1,
+};
+
+static struct platform_device overo_tfp410_device = {
+	.name                   = "tfp410",
+	.id                     = 0,
+	.dev.platform_data      = &overo_tfp410_pdata,
 };
 
 static struct omap_dss_board_info overo_dss_data = {
-	.num_devices	= ARRAY_SIZE(overo_dss_devices),
-	.devices	= overo_dss_devices,
-	.default_device	= &overo_dvi_device,
+	.default_display_name = "lcd43",
 };
 
+static void __init overo_display_init(void)
+{
+	omap_display_init(&overo_dss_data);
+
+	if (!overo_use_lcd35)
+		platform_device_register(&overo_lcd43_device);
+	platform_device_register(&overo_tfp410_device);
+	platform_device_register(&overo_dvi_connector_device);
+	platform_device_register(&overo_tv_connector_device);
+}
+
 static struct mtd_partition overo_nand_partitions[] = {
 	{
 		.name           = "xloader",
@@ -408,24 +427,41 @@ static int __init overo_i2c_init(void)
 	return 0;
 }
 
+static struct panel_lb035q02_platform_data overo_lcd35_pdata = {
+	.name                   = "lcd35",
+	.source                 = "dpi.0",
+
+	.data_lines		= 24,
+
+	.enable_gpio		= OVERO_GPIO_LCD_EN,
+	.backlight_gpio		= OVERO_GPIO_LCD_BL,
+};
+
+/*
+ * NOTE: We need to add either the lgphilips panel, or the lcd43 panel. The
+ * selection is done based on the overo_use_lcd35 field. If new SPI
+ * devices are added here, extra work is needed to make only the lgphilips panel
+ * affected by the overo_use_lcd35 field.
+ */
 static struct spi_board_info overo_spi_board_info[] __initdata = {
-#if defined(CONFIG_PANEL_LGPHILIPS_LB035Q02) || \
-	defined(CONFIG_PANEL_LGPHILIPS_LB035Q02_MODULE)
 	{
-		.modalias		= "lgphilips_lb035q02_panel-spi",
+		.modalias		= "panel_lgphilips_lb035q02",
 		.bus_num		= 1,
 		.chip_select		= 1,
 		.max_speed_hz		= 500000,
 		.mode			= SPI_MODE_3,
+		.platform_data		= &overo_lcd35_pdata,
 	},
-#endif
 };
 
 static int __init overo_spi_init(void)
 {
 	overo_ads7846_init();
-	spi_register_board_info(overo_spi_board_info,
-			ARRAY_SIZE(overo_spi_board_info));
+
+	if (overo_use_lcd35) {
+		spi_register_board_info(overo_spi_board_info,
+				ARRAY_SIZE(overo_spi_board_info));
+	}
 	return 0;
 }
 
@@ -463,11 +499,13 @@ static void __init overo_init(void)
 {
 	int ret;
 
+	if (strstr(boot_command_line, "omapdss.def_disp=lcd35"))
+		overo_use_lcd35 = true;
+
 	regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies));
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 	overo_i2c_init();
 	omap_hsmmc_init(mmc);
-	omap_display_init(&overo_dss_data);
 	omap_serial_init();
 	omap_sdrc_init(mt46h32m32lf6_sdrc_params,
 				  mt46h32m32lf6_sdrc_params);
@@ -484,6 +522,8 @@ static void __init overo_init(void)
 	overo_init_keys();
 	omap_twl4030_audio_init("overo", NULL);
 
+	overo_display_init();
+
 	/* 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);
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:08 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:08 +0300
Subject: [PATCH 05/21] ARM: OMAP: 4430SDP: remove picodlp device data
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-6-git-send-email-tomi.valkeinen@ti.com>

4430SDP board has an option for a PicoDLP mini-projector. PicoDLP cannot
be used at the same time as the second LCD, and there are GPIOs that
need to be set/unset when changing the used display.

Managing that kind of board specific setup is not simple without board
file callbacks. As only some 4430SDP boards actually have the PicoDLP
installed, and 4430SDP boards are not that common in the first place,
let's remove PicoDLP data from the board file.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/dss-common.c | 21 ---------------------
 1 file changed, 21 deletions(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 3215412..bf89eff 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -181,28 +181,7 @@ static struct platform_device sdp4430_tpd_device = {
 };
 
 
-static struct picodlp_panel_data sdp4430_picodlp_pdata = {
-	.picodlp_adapter_id	= 2,
-	.emu_done_gpio		= 44,
-	.pwrgood_gpio		= 45,
-};
-
-static struct omap_dss_device sdp4430_picodlp_device = {
-	.name			= "picodlp",
-	.driver_name		= "picodlp_panel",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.phy.dpi.data_lines	= 24,
-	.channel		= OMAP_DSS_CHANNEL_LCD2,
-	.data			= &sdp4430_picodlp_pdata,
-};
-
-static struct omap_dss_device *sdp4430_dss_devices[] = {
-	&sdp4430_picodlp_device,
-};
-
 static struct omap_dss_board_info sdp4430_dss_data = {
-	.num_devices	= ARRAY_SIZE(sdp4430_dss_devices),
-	.devices	= sdp4430_dss_devices,
 	.default_display_name = "lcd",
 };
 
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:10 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:10 +0300
Subject: [PATCH 07/21] ARM: OMAP: rx51: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-8-git-send-email-tomi.valkeinen@ti.com>

Use the new display drivers for RX51 board.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
Tested-by: Aaro Koskinen <aaro.koskinen at iki.fi>
---
 arch/arm/mach-omap2/board-rx51-peripherals.c | 12 ++++++++++
 arch/arm/mach-omap2/board-rx51-video.c       | 35 ++++++++++------------------
 2 files changed, 24 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9c2dd10..c3270c0 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -45,6 +45,8 @@
 #include <linux/platform_data/tsl2563.h>
 #include <linux/lis3lv02d.h>
 
+#include <video/omap-panel-data.h>
+
 #if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
 #include <media/ir-rx51.h>
 #endif
@@ -226,6 +228,15 @@ static struct lp55xx_platform_data rx51_lp5523_platform_data = {
 };
 #endif
 
+#define RX51_LCD_RESET_GPIO	90
+
+static struct panel_acx565akm_platform_data acx_pdata = {
+	.name		= "lcd",
+	.source		= "sdi.0",
+	.reset_gpio	= RX51_LCD_RESET_GPIO,
+	.datapairs	= 2,
+};
+
 static struct omap2_mcspi_device_config wl1251_mcspi_config = {
 	.turbo_mode	= 0,
 };
@@ -254,6 +265,7 @@ static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
 		.chip_select		= 2,
 		.max_speed_hz		= 6000000,
 		.controller_data	= &mipid_mcspi_config,
+		.platform_data		= &acx_pdata,
 	},
 	[RX51_SPI_TSC2005] = {
 		.modalias		= "tsc2005",
diff --git a/arch/arm/mach-omap2/board-rx51-video.c b/arch/arm/mach-omap2/board-rx51-video.c
index bdd1e3a..43a90c8 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -29,34 +29,21 @@
 
 #if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
 
-static struct panel_acx565akm_data lcd_data = {
-	.reset_gpio	= RX51_LCD_RESET_GPIO,
+static struct connector_atv_platform_data rx51_tv_pdata = {
+	.name = "tv",
+	.source = "venc.0",
+	.connector_type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+	.invert_polarity = false,
 };
 
-static struct omap_dss_device rx51_lcd_device = {
-	.name			= "lcd",
-	.driver_name		= "panel-acx565akm",
-	.type			= OMAP_DISPLAY_TYPE_SDI,
-	.phy.sdi.datapairs	= 2,
-	.data			= &lcd_data,
-};
-
-static struct omap_dss_device  rx51_tv_device = {
-	.name			= "tv",
-	.type			= OMAP_DISPLAY_TYPE_VENC,
-	.driver_name		= "venc",
-	.phy.venc.type	        = OMAP_DSS_VENC_TYPE_COMPOSITE,
-};
-
-static struct omap_dss_device *rx51_dss_devices[] = {
-	&rx51_lcd_device,
-	&rx51_tv_device,
+static struct platform_device rx51_tv_connector_device = {
+	.name                   = "connector-analog-tv",
+	.id                     = 0,
+	.dev.platform_data      = &rx51_tv_pdata,
 };
 
 static struct omap_dss_board_info rx51_dss_board_info = {
-	.num_devices	= ARRAY_SIZE(rx51_dss_devices),
-	.devices	= rx51_dss_devices,
-	.default_device	= &rx51_lcd_device,
+	.default_display_name = "lcd",
 };
 
 static int __init rx51_video_init(void)
@@ -71,6 +58,8 @@ static int __init rx51_video_init(void)
 
 	omap_display_init(&rx51_dss_board_info);
 
+	platform_device_register(&rx51_tv_connector_device);
+
 	return 0;
 }
 
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:13 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:13 +0300
Subject: [PATCH 10/21] ARM: OMAP: 2430SDP: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-11-git-send-email-tomi.valkeinen@ti.com>

Use new display drivers for 2430SDP board.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/board-2430sdp.c | 57 +++++++++++++++++++++++--------------
 1 file changed, 35 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
index 244d8a5..c711ad6 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -100,39 +100,52 @@ static struct platform_device sdp2430_flash_device = {
 	.resource	= &sdp2430_flash_resource,
 };
 
-static struct platform_device *sdp2430_devices[] __initdata = {
-	&sdp2430_flash_device,
-};
-
 /* LCD */
 #define SDP2430_LCD_PANEL_BACKLIGHT_GPIO	91
 #define SDP2430_LCD_PANEL_ENABLE_GPIO		154
 
-static struct panel_generic_dpi_data sdp2430_panel_data = {
-	.name			= "nec_nl2432dr22-11b",
-	.num_gpios		= 2,
-	.gpios			= {
-		SDP2430_LCD_PANEL_ENABLE_GPIO,
-		SDP2430_LCD_PANEL_BACKLIGHT_GPIO,
-	},
+static const struct display_timing sdp2430_lcd_videomode = {
+	.pixelclock	= { 0, 5400000, 0 },
+
+	.hactive = { 0, 240, 0 },
+	.hfront_porch = { 0, 3, 0 },
+	.hback_porch = { 0, 39, 0 },
+	.hsync_len = { 0, 3, 0 },
+
+	.vactive = { 0, 320, 0 },
+	.vfront_porch = { 0, 2, 0 },
+	.vback_porch = { 0, 7, 0 },
+	.vsync_len = { 0, 1, 0 },
+
+	.flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+		DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
 };
 
-static struct omap_dss_device sdp2430_lcd_device = {
-	.name			= "lcd",
-	.driver_name		= "generic_dpi_panel",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.phy.dpi.data_lines	= 16,
-	.data			= &sdp2430_panel_data,
+static struct panel_dpi_platform_data sdp2430_lcd_pdata = {
+	.name                   = "lcd",
+	.source                 = "dpi.0",
+
+	.data_lines		= 16,
+
+	.display_timing		= &sdp2430_lcd_videomode,
+
+	.enable_gpio		= SDP2430_LCD_PANEL_ENABLE_GPIO,
+	.backlight_gpio		= SDP2430_LCD_PANEL_BACKLIGHT_GPIO,
 };
 
-static struct omap_dss_device *sdp2430_dss_devices[] = {
-	&sdp2430_lcd_device,
+static struct platform_device sdp2430_lcd_device = {
+	.name                   = "panel-dpi",
+	.id                     = 0,
+	.dev.platform_data      = &sdp2430_lcd_pdata,
 };
 
 static struct omap_dss_board_info sdp2430_dss_data = {
-	.num_devices	= ARRAY_SIZE(sdp2430_dss_devices),
-	.devices	= sdp2430_dss_devices,
-	.default_device	= &sdp2430_lcd_device,
+	.default_display_name = "lcd",
+};
+
+static struct platform_device *sdp2430_devices[] __initdata = {
+	&sdp2430_flash_device,
+	&sdp2430_lcd_device,
 };
 
 #if IS_ENABLED(CONFIG_SMC91X)
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:11 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:11 +0300
Subject: [PATCH 08/21] ARM: OMAP: beagle: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-9-git-send-email-tomi.valkeinen@ti.com>

Use the new display drivers for Beagleboard.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/board-omap3beagle.c | 56 +++++++++++++++++++++------------
 1 file changed, 36 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 04c1165..f792805 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -225,35 +225,46 @@ static struct mtd_partition omap3beagle_nand_partitions[] = {
 
 /* DSS */
 
-static struct tfp410_platform_data dvi_panel = {
-	.i2c_bus_num = 3,
-	.power_down_gpio = -1,
+static struct connector_dvi_platform_data beagle_dvi_connector_pdata = {
+	.name                   = "dvi",
+	.source                 = "tfp410.0",
+	.i2c_bus_num            = 3,
 };
 
-static struct omap_dss_device beagle_dvi_device = {
-	.type = OMAP_DISPLAY_TYPE_DPI,
-	.name = "dvi",
-	.driver_name = "tfp410",
-	.data = &dvi_panel,
-	.phy.dpi.data_lines = 24,
+static struct platform_device beagle_dvi_connector_device = {
+	.name                   = "connector-dvi",
+	.id                     = 0,
+	.dev.platform_data      = &beagle_dvi_connector_pdata,
 };
 
-static struct omap_dss_device beagle_tv_device = {
+static struct encoder_tfp410_platform_data beagle_tfp410_pdata = {
+	.name                   = "tfp410.0",
+	.source                 = "dpi.0",
+	.data_lines             = 24,
+	.power_down_gpio        = -1,
+};
+
+static struct platform_device beagle_tfp410_device = {
+	.name                   = "tfp410",
+	.id                     = 0,
+	.dev.platform_data      = &beagle_tfp410_pdata,
+};
+
+static struct connector_atv_platform_data beagle_tv_pdata = {
 	.name = "tv",
-	.driver_name = "venc",
-	.type = OMAP_DISPLAY_TYPE_VENC,
-	.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+	.source = "venc.0",
+	.connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+	.invert_polarity = false,
 };
 
-static struct omap_dss_device *beagle_dss_devices[] = {
-	&beagle_dvi_device,
-	&beagle_tv_device,
+static struct platform_device beagle_tv_connector_device = {
+	.name                   = "connector-analog-tv",
+	.id                     = 0,
+	.dev.platform_data      = &beagle_tv_pdata,
 };
 
 static struct omap_dss_board_info beagle_dss_data = {
-	.num_devices = ARRAY_SIZE(beagle_dss_devices),
-	.devices = beagle_dss_devices,
-	.default_device = &beagle_dvi_device,
+	.default_display_name = "dvi",
 };
 
 #include "sdram-micron-mt46h32m32lf-6.h"
@@ -332,7 +343,11 @@ static int beagle_twl_gpio_setup(struct device *dev,
 		if (gpio_request_one(gpio + 1, GPIOF_IN, "EHCI_nOC"))
 			pr_err("%s: unable to configure EHCI_nOC\n", __func__);
 	}
-	dvi_panel.power_down_gpio = beagle_config.dvi_pd_gpio;
+	beagle_tfp410_pdata.power_down_gpio = beagle_config.dvi_pd_gpio;
+
+	platform_device_register(&beagle_tfp410_device);
+	platform_device_register(&beagle_dvi_connector_device);
+	platform_device_register(&beagle_tv_connector_device);
 
 	/* TWL4030_GPIO_MAX i.e. LED_GPO controls HS USB Port 2 power */
 	phy_data[0].vcc_gpio = gpio + TWL4030_GPIO_MAX;
@@ -547,6 +562,7 @@ static void __init omap3_beagle_init(void)
 	if (gpio_is_valid(beagle_config.dvi_pd_gpio))
 		omap_mux_init_gpio(beagle_config.dvi_pd_gpio, OMAP_PIN_OUTPUT);
 	omap_display_init(&beagle_dss_data);
+
 	omap_serial_init();
 	omap_sdrc_init(mt46h32m32lf6_sdrc_params,
 				  mt46h32m32lf6_sdrc_params);
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:15 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:15 +0300
Subject: [PATCH 12/21] ARM: OMAP: omap3stalker: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-13-git-send-email-tomi.valkeinen@ti.com>

Use new display drivers for OMAP3 Stalker board.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/board-omap3stalker.c | 61 +++++++++++++++++++-------------
 1 file changed, 37 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index d37e6b1..ba8342f 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -93,40 +93,50 @@ static void __init omap3_stalker_display_init(void)
 {
 	return;
 }
+static struct connector_dvi_platform_data omap3stalker_dvi_connector_pdata = {
+	.name                   = "dvi",
+	.source                 = "tfp410.0",
+	.i2c_bus_num            = -1,
+};
 
-static struct omap_dss_device omap3_stalker_tv_device = {
-	.name			= "tv",
-	.driver_name		= "venc",
-	.type			= OMAP_DISPLAY_TYPE_VENC,
-#if defined(CONFIG_OMAP2_VENC_OUT_TYPE_SVIDEO)
-	.phy.venc.type		= OMAP_DSS_VENC_TYPE_SVIDEO,
-#elif defined(CONFIG_OMAP2_VENC_OUT_TYPE_COMPOSITE)
-	.u.venc.type		= OMAP_DSS_VENC_TYPE_COMPOSITE,
-#endif
+static struct platform_device omap3stalker_dvi_connector_device = {
+	.name                   = "connector-dvi",
+	.id                     = 0,
+	.dev.platform_data      = &omap3stalker_dvi_connector_pdata,
 };
 
-static struct tfp410_platform_data dvi_panel = {
-	.power_down_gpio	= DSS_ENABLE_GPIO,
-	.i2c_bus_num		= -1,
+static struct encoder_tfp410_platform_data omap3stalker_tfp410_pdata = {
+	.name                   = "tfp410.0",
+	.source                 = "dpi.0",
+	.data_lines             = 24,
+	.power_down_gpio        = DSS_ENABLE_GPIO,
 };
 
-static struct omap_dss_device omap3_stalker_dvi_device = {
-	.name			= "dvi",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.driver_name		= "tfp410",
-	.data			= &dvi_panel,
-	.phy.dpi.data_lines	= 24,
+static struct platform_device omap3stalker_tfp410_device = {
+	.name                   = "tfp410",
+	.id                     = 0,
+	.dev.platform_data      = &omap3stalker_tfp410_pdata,
+};
+
+static struct connector_atv_platform_data omap3stalker_tv_pdata = {
+	.name = "tv",
+	.source = "venc.0",
+#if defined(CONFIG_OMAP2_VENC_OUT_TYPE_SVIDEO)
+	.connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+#elif defined(CONFIG_OMAP2_VENC_OUT_TYPE_COMPOSITE)
+	.connector_type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+#endif
+	.invert_polarity = false,
 };
 
-static struct omap_dss_device *omap3_stalker_dss_devices[] = {
-	&omap3_stalker_tv_device,
-	&omap3_stalker_dvi_device,
+static struct platform_device omap3stalker_tv_connector_device = {
+	.name                   = "connector-analog-tv",
+	.id                     = 0,
+	.dev.platform_data      = &omap3stalker_tv_pdata,
 };
 
 static struct omap_dss_board_info omap3_stalker_dss_data = {
-	.num_devices	= ARRAY_SIZE(omap3_stalker_dss_devices),
-	.devices	= omap3_stalker_dss_devices,
-	.default_device	= &omap3_stalker_dvi_device,
+	.default_display_name = "dvi",
 };
 
 static struct regulator_consumer_supply omap3stalker_vmmc1_supply[] = {
@@ -356,6 +366,9 @@ static struct usbhs_phy_data phy_data[] __initdata = {
 
 static struct platform_device *omap3_stalker_devices[] __initdata = {
 	&keys_gpio,
+	&omap3stalker_tfp410_device,
+	&omap3stalker_dvi_connector_device,
+	&omap3stalker_tv_connector_device,
 };
 
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:14 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:14 +0300
Subject: [PATCH 11/21] ARM: OMAP: LDP: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-12-git-send-email-tomi.valkeinen@ti.com>

Use new display drivers for LDP board.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/board-ldp.c | 68 ++++++++++++++++++++++++++++-------------
 1 file changed, 47 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 62e4f70..dd8da2c 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -184,45 +184,70 @@ static inline void __init ldp_init_smsc911x(void)
 #define LCD_PANEL_RESET_GPIO		55
 #define LCD_PANEL_QVGA_GPIO		56
 
-static struct panel_generic_dpi_data ldp_panel_data = {
-	.name			= "nec_nl2432dr22-11b",
-	.num_gpios		= 4,
-	/* gpios filled in code */
+static const struct display_timing ldp_lcd_videomode = {
+	.pixelclock	= { 0, 5400000, 0 },
+
+	.hactive = { 0, 240, 0 },
+	.hfront_porch = { 0, 3, 0 },
+	.hback_porch = { 0, 39, 0 },
+	.hsync_len = { 0, 3, 0 },
+
+	.vactive = { 0, 320, 0 },
+	.vfront_porch = { 0, 2, 0 },
+	.vback_porch = { 0, 7, 0 },
+	.vsync_len = { 0, 1, 0 },
+
+	.flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+		DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
 };
 
-static struct omap_dss_device ldp_lcd_device = {
-	.name			= "lcd",
-	.driver_name		= "generic_dpi_panel",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.phy.dpi.data_lines	= 18,
-	.data			= &ldp_panel_data,
+static struct panel_dpi_platform_data ldp_lcd_pdata = {
+	.name                   = "lcd",
+	.source                 = "dpi.0",
+
+	.data_lines		= 18,
+
+	.display_timing		= &ldp_lcd_videomode,
+
+	.enable_gpio		= -1,	/* filled in code */
+	.backlight_gpio		= -1,	/* filled in code */
 };
 
-static struct omap_dss_device *ldp_dss_devices[] = {
-	&ldp_lcd_device,
+static struct platform_device ldp_lcd_device = {
+	.name                   = "panel-dpi",
+	.id                     = 0,
+	.dev.platform_data      = &ldp_lcd_pdata,
 };
 
 static struct omap_dss_board_info ldp_dss_data = {
-	.num_devices	= ARRAY_SIZE(ldp_dss_devices),
-	.devices	= ldp_dss_devices,
-	.default_device	= &ldp_lcd_device,
+	.default_display_name = "lcd",
 };
 
 static void __init ldp_display_init(void)
 {
-	ldp_panel_data.gpios[2] = LCD_PANEL_RESET_GPIO;
-	ldp_panel_data.gpios[3] = LCD_PANEL_QVGA_GPIO;
+	int r;
+
+	static struct gpio gpios[] __initdata = {
+		{LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, "LCD RESET"},
+		{LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, "LCD QVGA"},
+	};
+
+	r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+	if (r) {
+		pr_err("Cannot request LCD GPIOs, error %d\n", r);
+		return;
+	}
 
 	omap_display_init(&ldp_dss_data);
 }
 
 static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
 {
-	ldp_panel_data.gpios[0] = gpio + 7;
-	ldp_panel_data.gpio_invert[0] = true;
+	/* LCD enable GPIO */
+	ldp_lcd_pdata.enable_gpio = gpio + 7;
 
-	ldp_panel_data.gpios[1] = gpio + 15;
-	ldp_panel_data.gpio_invert[1] = true;
+	/* Backlight enable GPIO */
+	ldp_lcd_pdata.backlight_gpio = gpio + 15;
 
 	return 0;
 }
@@ -322,6 +347,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
 
 static struct platform_device *ldp_devices[] __initdata = {
 	&ldp_gpio_keys_device,
+	&ldp_lcd_device,
 };
 
 #ifdef CONFIG_OMAP_MUX
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:16 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:16 +0300
Subject: [PATCH 13/21] ARM: OMAP: igep0020: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-14-git-send-email-tomi.valkeinen@ti.com>

Use new display drivers for igep0020 board.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/board-igep0020.c | 36 ++++++++++++++++++++++--------------
 1 file changed, 22 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index 87e65dd..06dbb2d 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -429,31 +429,39 @@ static struct twl4030_gpio_platform_data igep_twl4030_gpio_pdata = {
 	.setup		= igep_twl_gpio_setup,
 };
 
-static struct tfp410_platform_data dvi_panel = {
-	.i2c_bus_num		= 3,
-	.power_down_gpio	= IGEP2_GPIO_DVI_PUP,
+static struct connector_dvi_platform_data omap3stalker_dvi_connector_pdata = {
+	.name                   = "dvi",
+	.source                 = "tfp410.0",
+	.i2c_bus_num            = 3,
 };
 
-static struct omap_dss_device igep2_dvi_device = {
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.name			= "dvi",
-	.driver_name		= "tfp410",
-	.data			= &dvi_panel,
-	.phy.dpi.data_lines	= 24,
+static struct platform_device omap3stalker_dvi_connector_device = {
+	.name                   = "connector-dvi",
+	.id                     = 0,
+	.dev.platform_data      = &omap3stalker_dvi_connector_pdata,
 };
 
-static struct omap_dss_device *igep2_dss_devices[] = {
-	&igep2_dvi_device
+static struct encoder_tfp410_platform_data omap3stalker_tfp410_pdata = {
+	.name                   = "tfp410.0",
+	.source                 = "dpi.0",
+	.data_lines             = 24,
+	.power_down_gpio        = IGEP2_GPIO_DVI_PUP,
+};
+
+static struct platform_device omap3stalker_tfp410_device = {
+	.name                   = "tfp410",
+	.id                     = 0,
+	.dev.platform_data      = &omap3stalker_tfp410_pdata,
 };
 
 static struct omap_dss_board_info igep2_dss_data = {
-	.num_devices	= ARRAY_SIZE(igep2_dss_devices),
-	.devices	= igep2_dss_devices,
-	.default_device	= &igep2_dvi_device,
+	.default_display_name = "dvi",
 };
 
 static struct platform_device *igep_devices[] __initdata = {
 	&igep_vwlan_device,
+	&omap3stalker_tfp410_device,
+	&omap3stalker_dvi_connector_device,
 };
 
 static int igep2_keymap[] = {
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:12 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:12 +0300
Subject: [PATCH 09/21] ARM: OMAP: devkit8000: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-10-git-send-email-tomi.valkeinen@ti.com>

Use new display drivers for devkit8000 board.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/board-devkit8000.c | 96 +++++++++++++++++++++++-----------
 1 file changed, 65 insertions(+), 31 deletions(-)

diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index f1d91ba..cdc4fb9 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -112,50 +112,81 @@ static struct regulator_consumer_supply devkit8000_vio_supply[] = {
 	REGULATOR_SUPPLY("vcc", "spi2.0"),
 };
 
-static struct panel_generic_dpi_data lcd_panel = {
-	.name			= "innolux_at070tn83",
-	/* gpios filled in code */
+static const struct display_timing devkit8000_lcd_videomode = {
+	.pixelclock	= { 0, 40000000, 0 },
+
+	.hactive = { 0, 800, 0 },
+	.hfront_porch = { 0, 1, 0 },
+	.hback_porch = { 0, 1, 0 },
+	.hsync_len = { 0, 48, 0 },
+
+	.vactive = { 0, 480, 0 },
+	.vfront_porch = { 0, 12, 0 },
+	.vback_porch = { 0, 25, 0 },
+	.vsync_len = { 0, 3, 0 },
+
+	.flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+		DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
 };
 
-static struct omap_dss_device devkit8000_lcd_device = {
+static struct panel_dpi_platform_data devkit8000_lcd_pdata = {
 	.name                   = "lcd",
-	.type                   = OMAP_DISPLAY_TYPE_DPI,
-	.driver_name            = "generic_dpi_panel",
-	.data			= &lcd_panel,
-	.phy.dpi.data_lines     = 24,
+	.source                 = "dpi.0",
+
+	.data_lines		= 24,
+
+	.display_timing		= &devkit8000_lcd_videomode,
+
+	.enable_gpio		= -1,	/* filled in code */
+	.backlight_gpio		= -1,
 };
 
-static struct tfp410_platform_data dvi_panel = {
-	.power_down_gpio	= -1,
-	.i2c_bus_num		= 1,
+static struct platform_device devkit8000_lcd_device = {
+	.name                   = "panel-dpi",
+	.id                     = 0,
+	.dev.platform_data      = &devkit8000_lcd_pdata,
 };
 
-static struct omap_dss_device devkit8000_dvi_device = {
+static struct connector_dvi_platform_data devkit8000_dvi_connector_pdata = {
 	.name                   = "dvi",
-	.type                   = OMAP_DISPLAY_TYPE_DPI,
-	.driver_name            = "tfp410",
-	.data			= &dvi_panel,
-	.phy.dpi.data_lines     = 24,
+	.source                 = "tfp410.0",
+	.i2c_bus_num            = 1,
 };
 
-static struct omap_dss_device devkit8000_tv_device = {
-	.name                   = "tv",
-	.driver_name            = "venc",
-	.type                   = OMAP_DISPLAY_TYPE_VENC,
-	.phy.venc.type          = OMAP_DSS_VENC_TYPE_SVIDEO,
+static struct platform_device devkit8000_dvi_connector_device = {
+	.name                   = "connector-dvi",
+	.id                     = 0,
+	.dev.platform_data      = &devkit8000_dvi_connector_pdata,
 };
 
+static struct encoder_tfp410_platform_data devkit8000_tfp410_pdata = {
+	.name                   = "tfp410.0",
+	.source                 = "dpi.0",
+	.data_lines             = 24,
+	.power_down_gpio        = -1,	/* filled in code */
+};
 
-static struct omap_dss_device *devkit8000_dss_devices[] = {
-	&devkit8000_lcd_device,
-	&devkit8000_dvi_device,
-	&devkit8000_tv_device,
+static struct platform_device devkit8000_tfp410_device = {
+	.name                   = "tfp410",
+	.id                     = 0,
+	.dev.platform_data      = &devkit8000_tfp410_pdata,
+};
+
+static struct connector_atv_platform_data devkit8000_tv_pdata = {
+	.name = "tv",
+	.source = "venc.0",
+	.connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+	.invert_polarity = false,
+};
+
+static struct platform_device devkit8000_tv_connector_device = {
+	.name                   = "connector-analog-tv",
+	.id                     = 0,
+	.dev.platform_data      = &devkit8000_tv_pdata,
 };
 
 static struct omap_dss_board_info devkit8000_dss_data = {
-	.num_devices = ARRAY_SIZE(devkit8000_dss_devices),
-	.devices = devkit8000_dss_devices,
-	.default_device = &devkit8000_lcd_device,
+	.default_display_name = "lcd",
 };
 
 static uint32_t board_keymap[] = {
@@ -204,11 +235,10 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
 	gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
 
 	/* TWL4030_GPIO_MAX + 0 is "LCD_PWREN" (out, active high) */
-	lcd_panel.num_gpios = 1;
-	lcd_panel.gpios[0] = gpio + TWL4030_GPIO_MAX + 0;
+	devkit8000_lcd_pdata.enable_gpio = gpio + TWL4030_GPIO_MAX + 0;
 
 	/* gpio + 7 is "DVI_PD" (out, active low) */
-	dvi_panel.power_down_gpio = gpio + 7;
+	devkit8000_tfp410_pdata.power_down_gpio = gpio + 7;
 
 	return 0;
 }
@@ -413,6 +443,10 @@ static struct platform_device *devkit8000_devices[] __initdata = {
 	&leds_gpio,
 	&keys_gpio,
 	&omap_dm9000_dev,
+	&devkit8000_lcd_device,
+	&devkit8000_tfp410_device,
+	&devkit8000_dvi_connector_device,
+	&devkit8000_tv_connector_device,
 };
 
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:17 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:17 +0300
Subject: [PATCH 14/21] ARM: OMAP: cm-t35: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-15-git-send-email-tomi.valkeinen@ti.com>

Use new display drivers for cm-t35 board.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/board-cm-t35.c | 100 +++++++++++++++++++++++++------------
 1 file changed, 67 insertions(+), 33 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index d4622ed..33d159e 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -190,52 +190,81 @@ static inline void cm_t35_init_nand(void) {}
 #define CM_T35_LCD_BL_GPIO 58
 #define CM_T35_DVI_EN_GPIO 54
 
-static struct panel_generic_dpi_data lcd_panel = {
-	.name			= "toppoly_tdo35s",
-	.num_gpios		= 1,
-	.gpios			= {
-		CM_T35_LCD_BL_GPIO,
-	},
+static const struct display_timing cm_t35_lcd_videomode = {
+	.pixelclock	= { 0, 26000000, 0 },
+
+	.hactive = { 0, 480, 0 },
+	.hfront_porch = { 0, 104, 0 },
+	.hback_porch = { 0, 8, 0 },
+	.hsync_len = { 0, 8, 0 },
+
+	.vactive = { 0, 640, 0 },
+	.vfront_porch = { 0, 4, 0 },
+	.vback_porch = { 0, 2, 0 },
+	.vsync_len = { 0, 2, 0 },
+
+	.flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+		DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_NEGEDGE,
+};
+
+static struct panel_dpi_platform_data cm_t35_lcd_pdata = {
+	.name                   = "lcd",
+	.source                 = "dpi.0",
+
+	.data_lines		= 18,
+
+	.display_timing		= &cm_t35_lcd_videomode,
+
+	.enable_gpio		= -1,
+	.backlight_gpio		= CM_T35_LCD_BL_GPIO,
+};
+
+static struct platform_device cm_t35_lcd_device = {
+	.name                   = "panel-dpi",
+	.id                     = 0,
+	.dev.platform_data      = &cm_t35_lcd_pdata,
 };
 
-static struct omap_dss_device cm_t35_lcd_device = {
-	.name			= "lcd",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.driver_name		= "generic_dpi_panel",
-	.data			= &lcd_panel,
-	.phy.dpi.data_lines	= 18,
+static struct connector_dvi_platform_data cm_t35_dvi_connector_pdata = {
+	.name                   = "dvi",
+	.source                 = "tfp410.0",
+	.i2c_bus_num            = -1,
 };
 
-static struct tfp410_platform_data dvi_panel = {
-	.power_down_gpio	= CM_T35_DVI_EN_GPIO,
-	.i2c_bus_num		= -1,
+static struct platform_device cm_t35_dvi_connector_device = {
+	.name                   = "connector-dvi",
+	.id                     = 0,
+	.dev.platform_data      = &cm_t35_dvi_connector_pdata,
 };
 
-static struct omap_dss_device cm_t35_dvi_device = {
-	.name			= "dvi",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.driver_name		= "tfp410",
-	.data			= &dvi_panel,
-	.phy.dpi.data_lines	= 24,
+static struct encoder_tfp410_platform_data cm_t35_tfp410_pdata = {
+	.name                   = "tfp410.0",
+	.source                 = "dpi.0",
+	.data_lines             = 24,
+	.power_down_gpio        = CM_T35_DVI_EN_GPIO,
 };
 
-static struct omap_dss_device cm_t35_tv_device = {
-	.name			= "tv",
-	.driver_name		= "venc",
-	.type			= OMAP_DISPLAY_TYPE_VENC,
-	.phy.venc.type		= OMAP_DSS_VENC_TYPE_SVIDEO,
+static struct platform_device cm_t35_tfp410_device = {
+	.name                   = "tfp410",
+	.id                     = 0,
+	.dev.platform_data      = &cm_t35_tfp410_pdata,
 };
 
-static struct omap_dss_device *cm_t35_dss_devices[] = {
-	&cm_t35_lcd_device,
-	&cm_t35_dvi_device,
-	&cm_t35_tv_device,
+static struct connector_atv_platform_data cm_t35_tv_pdata = {
+	.name = "tv",
+	.source = "venc.0",
+	.connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+	.invert_polarity = false,
+};
+
+static struct platform_device cm_t35_tv_connector_device = {
+	.name                   = "connector-analog-tv",
+	.id                     = 0,
+	.dev.platform_data      = &cm_t35_tv_pdata,
 };
 
 static struct omap_dss_board_info cm_t35_dss_data = {
-	.num_devices	= ARRAY_SIZE(cm_t35_dss_devices),
-	.devices	= cm_t35_dss_devices,
-	.default_device	= &cm_t35_dvi_device,
+	.default_display_name = "dvi",
 };
 
 static struct omap2_mcspi_device_config tdo24m_mcspi_config = {
@@ -280,6 +309,11 @@ static void __init cm_t35_init_display(void)
 		pr_err("CM-T35: failed to register DSS device\n");
 		gpio_free(CM_T35_LCD_EN_GPIO);
 	}
+
+	platform_device_register(&cm_t35_tfp410_device);
+	platform_device_register(&cm_t35_dvi_connector_device);
+	platform_device_register(&cm_t35_lcd_device);
+	platform_device_register(&cm_t35_tv_connector_device);
 }
 
 static struct regulator_consumer_supply cm_t35_vmmc1_supply[] = {
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:18 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:18 +0300
Subject: [PATCH 15/21] ARM: OMAP: H4: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-16-git-send-email-tomi.valkeinen@ti.com>

Use new display drivers for H4 board.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/board-h4.c | 48 +++++++++++++++++++++++++++++-------------
 1 file changed, 33 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 69c0acf..87e41a8 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -194,30 +194,48 @@ static struct platform_device h4_flash_device = {
 	.resource	= &h4_flash_resource,
 };
 
-static struct platform_device *h4_devices[] __initdata = {
-	&h4_flash_device,
+static const struct display_timing cm_t35_lcd_videomode = {
+	.pixelclock	= { 0, 6250000, 0 },
+
+	.hactive = { 0, 240, 0 },
+	.hfront_porch = { 0, 15, 0 },
+	.hback_porch = { 0, 60, 0 },
+	.hsync_len = { 0, 15, 0 },
+
+	.vactive = { 0, 320, 0 },
+	.vfront_porch = { 0, 1, 0 },
+	.vback_porch = { 0, 1, 0 },
+	.vsync_len = { 0, 1, 0 },
+
+	.flags = DISPLAY_FLAGS_HSYNC_HIGH | DISPLAY_FLAGS_VSYNC_HIGH |
+		DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
 };
 
-static struct panel_generic_dpi_data h4_panel_data = {
-	.name			= "h4",
+static struct panel_dpi_platform_data cm_t35_lcd_pdata = {
+	.name                   = "lcd",
+	.source                 = "dpi.0",
+
+	.data_lines		= 16,
+
+	.display_timing		= &cm_t35_lcd_videomode,
+
+	.enable_gpio		= -1,
+	.backlight_gpio		= -1,
 };
 
-static struct omap_dss_device h4_lcd_device = {
-	.name			= "lcd",
-	.driver_name		= "generic_dpi_panel",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.phy.dpi.data_lines	= 16,
-	.data			= &h4_panel_data,
+static struct platform_device cm_t35_lcd_device = {
+	.name                   = "panel-dpi",
+	.id                     = 0,
+	.dev.platform_data      = &cm_t35_lcd_pdata,
 };
 
-static struct omap_dss_device *h4_dss_devices[] = {
-	&h4_lcd_device,
+static struct platform_device *h4_devices[] __initdata = {
+	&h4_flash_device,
+	&cm_t35_lcd_device,
 };
 
 static struct omap_dss_board_info h4_dss_data = {
-	.num_devices	= ARRAY_SIZE(h4_dss_devices),
-	.devices	= h4_dss_devices,
-	.default_device	= &h4_lcd_device,
+	.default_display_name = "lcd",
 };
 
 /* 2420 Sysboot setup (2430 is different) */
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:22 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:22 +0300
Subject: [PATCH 19/21] ARM: OMAP: Zoom: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-20-git-send-email-tomi.valkeinen@ti.com>

Use new display drivers for Zoom board.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/board-zoom-display.c | 30 +++++++++++-------------------
 1 file changed, 11 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-omap2/board-zoom-display.c b/arch/arm/mach-omap2/board-zoom-display.c
index c2a079c..3d8ecc1 100644
--- a/arch/arm/mach-omap2/board-zoom-display.c
+++ b/arch/arm/mach-omap2/board-zoom-display.c
@@ -25,32 +25,23 @@
 #define LCD_PANEL_RESET_GPIO_PILOT	55
 #define LCD_PANEL_QVGA_GPIO		56
 
-static struct panel_nec_nl8048_data zoom_lcd_data = {
-	/* res_gpio filled in code */
-	.qvga_gpio = LCD_PANEL_QVGA_GPIO,
-};
+static struct panel_nec_nl8048hl11_platform_data zoom_lcd_pdata = {
+	.name                   = "lcd",
+	.source                 = "dpi.0",
 
-static struct omap_dss_device zoom_lcd_device = {
-	.name			= "lcd",
-	.driver_name		= "NEC_8048_panel",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.phy.dpi.data_lines	= 24,
-	.data			= &zoom_lcd_data,
-};
+	.data_lines		= 24,
 
-static struct omap_dss_device *zoom_dss_devices[] = {
-	&zoom_lcd_device,
+	.res_gpio		= -1,	/* filled in code */
+	.qvga_gpio		= LCD_PANEL_QVGA_GPIO,
 };
 
 static struct omap_dss_board_info zoom_dss_data = {
-	.num_devices		= ARRAY_SIZE(zoom_dss_devices),
-	.devices		= zoom_dss_devices,
-	.default_device		= &zoom_lcd_device,
+	.default_display_name = "lcd",
 };
 
 static void __init zoom_lcd_panel_init(void)
 {
-	zoom_lcd_data.res_gpio = (omap_rev() > OMAP3430_REV_ES3_0) ?
+	zoom_lcd_pdata.res_gpio = (omap_rev() > OMAP3430_REV_ES3_0) ?
 			LCD_PANEL_RESET_GPIO_PROD :
 			LCD_PANEL_RESET_GPIO_PILOT;
 }
@@ -61,19 +52,20 @@ static struct omap2_mcspi_device_config dss_lcd_mcspi_config = {
 
 static struct spi_board_info nec_8048_spi_board_info[] __initdata = {
 	[0] = {
-		.modalias		= "nec_8048_spi",
+		.modalias		= "panel-nec-nl8048hl11",
 		.bus_num		= 1,
 		.chip_select		= 2,
 		.max_speed_hz		= 375000,
 		.controller_data	= &dss_lcd_mcspi_config,
+		.platform_data		= &zoom_lcd_pdata,
 	},
 };
 
 void __init zoom_display_init(void)
 {
 	omap_display_init(&zoom_dss_data);
+	zoom_lcd_panel_init();
 	spi_register_board_info(nec_8048_spi_board_info,
 				ARRAY_SIZE(nec_8048_spi_board_info));
-	zoom_lcd_panel_init();
 }
 
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:19 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:19 +0300
Subject: [PATCH 16/21] ARM: OMAP: 3430SDP: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-17-git-send-email-tomi.valkeinen@ti.com>

Use new display drivers for 3430SDP board.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/board-3430sdp.c | 83 ++++++++++++++++++++++---------------
 1 file changed, 50 insertions(+), 33 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index 23b004a..d95d0ef 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -126,53 +126,65 @@ static void __init sdp3430_display_init(void)
 
 }
 
-static struct panel_sharp_ls037v7dw01_data sdp3430_lcd_data = {
-	.resb_gpio = SDP3430_LCD_PANEL_ENABLE_GPIO,
-	.ini_gpio = -1,
-	.mo_gpio = -1,
-	.lr_gpio = -1,
-	.ud_gpio = -1,
+static struct panel_sharp_ls037v7dw01_platform_data sdp3430_lcd_pdata = {
+	.name                   = "lcd",
+	.source                 = "dpi.0",
+
+	.data_lines		= 16,
+
+	.resb_gpio		= SDP3430_LCD_PANEL_ENABLE_GPIO,
+	.ini_gpio		= -1,
+	.mo_gpio		= -1,
+	.lr_gpio		= -1,
+	.ud_gpio		= -1,
+};
+
+static struct platform_device sdp3430_lcd_device = {
+	.name                   = "panel-sharp-ls037v7dw01",
+	.id                     = 0,
+	.dev.platform_data      = &sdp3430_lcd_pdata,
 };
 
-static struct omap_dss_device sdp3430_lcd_device = {
-	.name			= "lcd",
-	.driver_name		= "sharp_ls_panel",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.phy.dpi.data_lines	= 16,
-	.data			= &sdp3430_lcd_data,
+static struct connector_dvi_platform_data sdp3430_dvi_connector_pdata = {
+	.name                   = "dvi",
+	.source                 = "tfp410.0",
+	.i2c_bus_num            = -1,
 };
 
-static struct tfp410_platform_data dvi_panel = {
-	.power_down_gpio	= -1,
-	.i2c_bus_num		= -1,
+static struct platform_device sdp3430_dvi_connector_device = {
+	.name                   = "connector-dvi",
+	.id                     = 0,
+	.dev.platform_data      = &sdp3430_dvi_connector_pdata,
 };
 
-static struct omap_dss_device sdp3430_dvi_device = {
-	.name			= "dvi",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.driver_name		= "tfp410",
-	.data			= &dvi_panel,
-	.phy.dpi.data_lines	= 24,
+static struct encoder_tfp410_platform_data sdp3430_tfp410_pdata = {
+	.name                   = "tfp410.0",
+	.source                 = "dpi.0",
+	.data_lines             = 24,
+	.power_down_gpio        = -1,
 };
 
-static struct omap_dss_device sdp3430_tv_device = {
-	.name			= "tv",
-	.driver_name		= "venc",
-	.type			= OMAP_DISPLAY_TYPE_VENC,
-	.phy.venc.type		= OMAP_DSS_VENC_TYPE_SVIDEO,
+static struct platform_device sdp3430_tfp410_device = {
+	.name                   = "tfp410",
+	.id                     = 0,
+	.dev.platform_data      = &sdp3430_tfp410_pdata,
 };
 
+static struct connector_atv_platform_data sdp3430_tv_pdata = {
+	.name = "tv",
+	.source = "venc.0",
+	.connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+	.invert_polarity = false,
+};
 
-static struct omap_dss_device *sdp3430_dss_devices[] = {
-	&sdp3430_lcd_device,
-	&sdp3430_dvi_device,
-	&sdp3430_tv_device,
+static struct platform_device sdp3430_tv_connector_device = {
+	.name                   = "connector-analog-tv",
+	.id                     = 0,
+	.dev.platform_data      = &sdp3430_tv_pdata,
 };
 
 static struct omap_dss_board_info sdp3430_dss_data = {
-	.num_devices	= ARRAY_SIZE(sdp3430_dss_devices),
-	.devices	= sdp3430_dss_devices,
-	.default_device	= &sdp3430_lcd_device,
+	.default_display_name = "lcd",
 };
 
 static struct omap2_hsmmc_info mmc[] = {
@@ -583,6 +595,11 @@ static void __init omap_3430sdp_init(void)
 	omap_hsmmc_init(mmc);
 	omap3430_i2c_init();
 	omap_display_init(&sdp3430_dss_data);
+	platform_device_register(&sdp3430_lcd_device);
+	platform_device_register(&sdp3430_tfp410_device);
+	platform_device_register(&sdp3430_dvi_connector_device);
+	platform_device_register(&sdp3430_tv_connector_device);
+
 	if (omap_rev() > OMAP3430_REV_ES1_0)
 		gpio_pendown = SDP3430_TS_GPIO_IRQ_SDPV2;
 	else
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:24 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:24 +0300
Subject: [PATCH 21/21] ARM: OMAP2+: Remove old display drivers from
 omap2plus_defconfig
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-22-git-send-email-tomi.valkeinen@ti.com>

The old display drivers are no longer used, and will be phased out. So
remove them from the omap2plus_defconfig.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/configs/omap2plus_defconfig | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 7ce1c29..92ba100 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -185,13 +185,6 @@ CONFIG_OMAP2_DSS_RFBI=y
 CONFIG_OMAP2_DSS_SDI=y
 CONFIG_OMAP2_DSS_DSI=y
 CONFIG_FB_OMAP2=m
-CONFIG_PANEL_GENERIC_DPI=m
-CONFIG_PANEL_TFP410=m
-CONFIG_PANEL_SHARP_LS037V7DW01=m
-CONFIG_PANEL_NEC_NL8048HL11_01B=m
-CONFIG_PANEL_TAAL=m
-CONFIG_PANEL_TPO_TD043MTEA1=m
-CONFIG_PANEL_ACX565AKM=m
 CONFIG_DISPLAY_ENCODER_TFP410=m
 CONFIG_DISPLAY_ENCODER_TPD12S015=m
 CONFIG_DISPLAY_CONNECTOR_DVI=m
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:23 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:23 +0300
Subject: [PATCH 20/21] ARM: OMAP: AM3517EVM: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-21-git-send-email-tomi.valkeinen@ti.com>

Use new display drivers for AM3517EVM board.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Note: the management of LCD GPIOs is unclear. They were originally muxed
as inputs, and LCD_PANEL_PWR was labelled as "dvi enable".

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/board-am3517evm.c | 113 +++++++++++++++++++++++-----------
 1 file changed, 77 insertions(+), 36 deletions(-)

diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index d63f14b..8cc2c9e 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -120,56 +120,95 @@ static int __init am3517_evm_i2c_init(void)
 	return 0;
 }
 
-static struct panel_generic_dpi_data lcd_panel = {
-	.name			= "sharp_lq",
-	.num_gpios		= 3,
-	.gpios			= {
-		LCD_PANEL_PWR,
-		LCD_PANEL_BKLIGHT_PWR,
-		LCD_PANEL_PWM,
-	},
+static const struct display_timing am3517_evm_lcd_videomode = {
+	.pixelclock	= { 0, 9000000, 0 },
+
+	.hactive = { 0, 480, 0 },
+	.hfront_porch = { 0, 3, 0 },
+	.hback_porch = { 0, 2, 0 },
+	.hsync_len = { 0, 42, 0 },
+
+	.vactive = { 0, 272, 0 },
+	.vfront_porch = { 0, 3, 0 },
+	.vback_porch = { 0, 2, 0 },
+	.vsync_len = { 0, 11, 0 },
+
+	.flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+		DISPLAY_FLAGS_DE_LOW | DISPLAY_FLAGS_PIXDATA_POSEDGE,
+};
+
+static struct panel_dpi_platform_data am3517_evm_lcd_pdata = {
+	.name                   = "lcd",
+	.source                 = "dpi.0",
+
+	.data_lines		= 16,
+
+	.display_timing		= &am3517_evm_lcd_videomode,
+
+	.enable_gpio		= LCD_PANEL_PWR,
+	.backlight_gpio		= LCD_PANEL_BKLIGHT_PWR,
+};
+
+static struct platform_device am3517_evm_lcd_device = {
+	.name                   = "panel-dpi",
+	.id                     = 0,
+	.dev.platform_data      = &am3517_evm_lcd_pdata,
 };
 
-static struct omap_dss_device am3517_evm_lcd_device = {
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.name			= "lcd",
-	.driver_name		= "generic_dpi_panel",
-	.data			= &lcd_panel,
-	.phy.dpi.data_lines 	= 16,
+static struct connector_dvi_platform_data am3517_evm_dvi_connector_pdata = {
+	.name                   = "dvi",
+	.source                 = "tfp410.0",
+	.i2c_bus_num            = -1,
 };
 
-static struct omap_dss_device am3517_evm_tv_device = {
-	.type 			= OMAP_DISPLAY_TYPE_VENC,
-	.name 			= "tv",
-	.driver_name		= "venc",
-	.phy.venc.type		= OMAP_DSS_VENC_TYPE_SVIDEO,
+static struct platform_device am3517_evm_dvi_connector_device = {
+	.name                   = "connector-dvi",
+	.id                     = 0,
+	.dev.platform_data      = &am3517_evm_dvi_connector_pdata,
 };
 
-static struct tfp410_platform_data dvi_panel = {
-	.power_down_gpio	= -1,
-	.i2c_bus_num		= -1,
+static struct encoder_tfp410_platform_data am3517_evm_tfp410_pdata = {
+	.name                   = "tfp410.0",
+	.source                 = "dpi.0",
+	.data_lines             = 24,
+	.power_down_gpio        = -1,
 };
 
-static struct omap_dss_device am3517_evm_dvi_device = {
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.name			= "dvi",
-	.driver_name		= "tfp410",
-	.data			= &dvi_panel,
-	.phy.dpi.data_lines	= 24,
+static struct platform_device am3517_evm_tfp410_device = {
+	.name                   = "tfp410",
+	.id                     = 0,
+	.dev.platform_data      = &am3517_evm_tfp410_pdata,
 };
 
-static struct omap_dss_device *am3517_evm_dss_devices[] = {
-	&am3517_evm_lcd_device,
-	&am3517_evm_tv_device,
-	&am3517_evm_dvi_device,
+static struct connector_atv_platform_data am3517_evm_tv_pdata = {
+	.name = "tv",
+	.source = "venc.0",
+	.connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+	.invert_polarity = false,
+};
+
+static struct platform_device am3517_evm_tv_connector_device = {
+	.name                   = "connector-analog-tv",
+	.id                     = 0,
+	.dev.platform_data      = &am3517_evm_tv_pdata,
 };
 
 static struct omap_dss_board_info am3517_evm_dss_data = {
-	.num_devices	= ARRAY_SIZE(am3517_evm_dss_devices),
-	.devices	= am3517_evm_dss_devices,
-	.default_device	= &am3517_evm_lcd_device,
+	.default_display_name = "lcd",
 };
 
+static void __init am3517_evm_display_init(void)
+{
+	gpio_request_one(LCD_PANEL_PWM, GPIOF_OUT_INIT_HIGH, "lcd panel pwm");
+
+	omap_display_init(&am3517_evm_dss_data);
+
+	platform_device_register(&am3517_evm_tfp410_device);
+	platform_device_register(&am3517_evm_dvi_connector_device);
+	platform_device_register(&am3517_evm_lcd_device);
+	platform_device_register(&am3517_evm_tv_connector_device);
+}
+
 /*
  * Board initialization
  */
@@ -295,7 +334,9 @@ static void __init am3517_evm_init(void)
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 
 	am3517_evm_i2c_init();
-	omap_display_init(&am3517_evm_dss_data);
+
+	am3517_evm_display_init();
+
 	omap_serial_init();
 	omap_sdrc_init(NULL, NULL);
 
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:21 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:21 +0300
Subject: [PATCH 18/21] ARM: OMAP: Pandora: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-19-git-send-email-tomi.valkeinen@ti.com>

Use new display drivers for OMAP3 Pandora board.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
Tested-by: Grazvydas Ignotas <notasas at gmail.com>
---
 arch/arm/mach-omap2/board-omap3pandora.c | 48 +++++++++++++++-----------------
 1 file changed, 22 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index b1547a0..9c2b180 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -231,34 +231,21 @@ static struct twl4030_keypad_data pandora_kp_data = {
 	.rep		= 1,
 };
 
-static struct panel_tpo_td043_data lcd_data = {
-	.nreset_gpio		= 157,
-};
-
-static struct omap_dss_device pandora_lcd_device = {
-	.name			= "lcd",
-	.driver_name		= "tpo_td043mtea1_panel",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.phy.dpi.data_lines	= 24,
-	.data			= &lcd_data,
-};
-
-static struct omap_dss_device pandora_tv_device = {
-	.name			= "tv",
-	.driver_name		= "venc",
-	.type			= OMAP_DISPLAY_TYPE_VENC,
-	.phy.venc.type		= OMAP_DSS_VENC_TYPE_SVIDEO,
+static struct connector_atv_platform_data pandora_tv_pdata = {
+	.name = "tv",
+	.source = "venc.0",
+	.connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+	.invert_polarity = false,
 };
 
-static struct omap_dss_device *pandora_dss_devices[] = {
-	&pandora_lcd_device,
-	&pandora_tv_device,
+static struct platform_device pandora_tv_connector_device = {
+	.name                   = "connector-analog-tv",
+	.id                     = 0,
+	.dev.platform_data      = &pandora_tv_pdata,
 };
 
 static struct omap_dss_board_info pandora_dss_data = {
-	.num_devices	= ARRAY_SIZE(pandora_dss_devices),
-	.devices	= pandora_dss_devices,
-	.default_device	= &pandora_lcd_device,
+	.default_display_name = "lcd",
 };
 
 static void pandora_wl1251_init_card(struct mmc_card *card)
@@ -348,7 +335,7 @@ static struct regulator_consumer_supply pandora_vdds_supplies[] = {
 };
 
 static struct regulator_consumer_supply pandora_vcc_lcd_supply[] = {
-	REGULATOR_SUPPLY("vcc", "display0"),
+	REGULATOR_SUPPLY("vcc", "spi1.1"),
 };
 
 static struct regulator_consumer_supply pandora_usb_phy_supply[] = {
@@ -529,13 +516,21 @@ static int __init omap3pandora_i2c_init(void)
 	return 0;
 }
 
+static struct panel_tpo_td043mtea1_platform_data pandora_lcd_pdata = {
+	.name                   = "lcd",
+	.source                 = "dpi.0",
+
+	.data_lines		= 24,
+	.nreset_gpio		= 157,
+};
+
 static struct spi_board_info omap3pandora_spi_board_info[] __initdata = {
 	{
-		.modalias		= "tpo_td043mtea1_panel_spi",
+		.modalias		= "panel-tpo-td043mtea1",
 		.bus_num		= 1,
 		.chip_select		= 1,
 		.max_speed_hz		= 375000,
-		.platform_data		= &pandora_lcd_device,
+		.platform_data		= &pandora_lcd_pdata,
 	}
 };
 
@@ -580,6 +575,7 @@ static struct platform_device *omap3pandora_devices[] __initdata = {
 	&pandora_keys_gpio,
 	&pandora_vwlan_device,
 	&pandora_backlight,
+	&pandora_tv_connector_device,
 };
 
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-- 
1.8.1.2



From tomi.valkeinen at ti.com  Fri Jul 26 03:08:20 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:08:20 +0300
Subject: [PATCH 17/21] ARM: OMAP: OMAP3EVM: use new display drivers
In-Reply-To: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <1374822504-28949-18-git-send-email-tomi.valkeinen@ti.com>

Use new display drivers for OMAP3EVM board.

The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
---
 arch/arm/mach-omap2/board-omap3evm.c | 87 +++++++++++++++++++++---------------
 1 file changed, 52 insertions(+), 35 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 8c02626..004c646 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -166,14 +166,6 @@ static inline void __init omap3evm_init_smsc911x(void) { return; }
  */
 #define OMAP3EVM_DVI_PANEL_EN_GPIO	199
 
-static struct panel_sharp_ls037v7dw01_data omap3_evm_lcd_data = {
-	.resb_gpio = OMAP3EVM_LCD_PANEL_RESB,
-	.ini_gpio = OMAP3EVM_LCD_PANEL_INI,
-	.mo_gpio = OMAP3EVM_LCD_PANEL_QVGA,
-	.lr_gpio = OMAP3EVM_LCD_PANEL_LR,
-	.ud_gpio = OMAP3EVM_LCD_PANEL_UD,
-};
-
 #ifdef CONFIG_BROKEN
 static void __init omap3_evm_display_init(void)
 {
@@ -196,44 +188,65 @@ static void __init omap3_evm_display_init(void)
 }
 #endif
 
-static struct omap_dss_device omap3_evm_lcd_device = {
-	.name			= "lcd",
-	.driver_name		= "sharp_ls_panel",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.phy.dpi.data_lines	= 18,
-	.data			= &omap3_evm_lcd_data,
+static struct panel_sharp_ls037v7dw01_platform_data omap3_evm_lcd_pdata = {
+	.name                   = "lcd",
+	.source                 = "dpi.0",
+
+	.data_lines		= 18,
+
+	.resb_gpio		= OMAP3EVM_LCD_PANEL_RESB,
+	.ini_gpio		= OMAP3EVM_LCD_PANEL_INI,
+	.mo_gpio		= OMAP3EVM_LCD_PANEL_QVGA,
+	.lr_gpio		= OMAP3EVM_LCD_PANEL_LR,
+	.ud_gpio		= OMAP3EVM_LCD_PANEL_UD,
+};
+
+static struct platform_device omap3_evm_lcd_device = {
+	.name                   = "panel-sharp-ls037v7dw01",
+	.id                     = 0,
+	.dev.platform_data      = &omap3_evm_lcd_pdata,
+};
+
+static struct connector_dvi_platform_data omap3_evm_dvi_connector_pdata = {
+	.name                   = "dvi",
+	.source                 = "tfp410.0",
+	.i2c_bus_num            = -1,
+};
+
+static struct platform_device omap3_evm_dvi_connector_device = {
+	.name                   = "connector-dvi",
+	.id                     = 0,
+	.dev.platform_data      = &omap3_evm_dvi_connector_pdata,
 };
 
-static struct omap_dss_device omap3_evm_tv_device = {
-	.name			= "tv",
-	.driver_name		= "venc",
-	.type			= OMAP_DISPLAY_TYPE_VENC,
-	.phy.venc.type		= OMAP_DSS_VENC_TYPE_SVIDEO,
+static struct encoder_tfp410_platform_data omap3_evm_tfp410_pdata = {
+	.name                   = "tfp410.0",
+	.source                 = "dpi.0",
+	.data_lines             = 24,
+	.power_down_gpio        = OMAP3EVM_DVI_PANEL_EN_GPIO,
 };
 
-static struct tfp410_platform_data dvi_panel = {
-	.power_down_gpio	= OMAP3EVM_DVI_PANEL_EN_GPIO,
-	.i2c_bus_num		= -1,
+static struct platform_device omap3_evm_tfp410_device = {
+	.name                   = "tfp410",
+	.id                     = 0,
+	.dev.platform_data      = &omap3_evm_tfp410_pdata,
 };
 
-static struct omap_dss_device omap3_evm_dvi_device = {
-	.name			= "dvi",
-	.type			= OMAP_DISPLAY_TYPE_DPI,
-	.driver_name		= "tfp410",
-	.data			= &dvi_panel,
-	.phy.dpi.data_lines	= 24,
+static struct connector_atv_platform_data omap3_evm_tv_pdata = {
+	.name = "tv",
+	.source = "venc.0",
+	.connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+	.invert_polarity = false,
 };
 
-static struct omap_dss_device *omap3_evm_dss_devices[] = {
-	&omap3_evm_lcd_device,
-	&omap3_evm_tv_device,
-	&omap3_evm_dvi_device,
+static struct platform_device omap3_evm_tv_connector_device = {
+	.name                   = "connector-analog-tv",
+	.id                     = 0,
+	.dev.platform_data      = &omap3_evm_tv_pdata,
 };
 
 static struct omap_dss_board_info omap3_evm_dss_data = {
-	.num_devices	= ARRAY_SIZE(omap3_evm_dss_devices),
-	.devices	= omap3_evm_dss_devices,
-	.default_device	= &omap3_evm_lcd_device,
+	.default_display_name = "lcd",
 };
 
 static struct regulator_consumer_supply omap3evm_vmmc1_supply[] = {
@@ -678,6 +691,10 @@ static void __init omap3_evm_init(void)
 	omap3_evm_i2c_init();
 
 	omap_display_init(&omap3_evm_dss_data);
+	platform_device_register(&omap3_evm_lcd_device);
+	platform_device_register(&omap3_evm_tfp410_device);
+	platform_device_register(&omap3_evm_dvi_connector_device);
+	platform_device_register(&omap3_evm_tv_connector_device);
 
 	omap_serial_init();
 	omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
-- 
1.8.1.2



From s.hauer at pengutronix.de  Fri Jul 26 03:21:30 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 26 Jul 2013 09:21:30 +0200
Subject: [PATCH v2 4/4] spi:Add Freescale DSPI driver for Vybrid VF610
 platform
In-Reply-To: <1374643943-3324-5-git-send-email-b44548@freescale.com>
References: <1374643943-3324-1-git-send-email-b44548@freescale.com>
 <1374643943-3324-5-git-send-email-b44548@freescale.com>
Message-ID: <20130726072130.GA3029@pengutronix.de>

On Wed, Jul 24, 2013 at 01:32:23PM +0800, Chao Fu wrote:
> From: Chao Fu <B44548 at freescale.com>
> 
> The serial peripheral interface (SPI) module implemented
> on Freescale Vybrid platform provides a synchronous serial
> bus for communication between Vybrid and the external
> peripheral device.
> The SPI supports full-duplex, three-wire synchronous transfer,
> has TX/RX FIFO with depth of four entries.
> 
> This driver is the SPI master mode driver and has been tested on Vybrid VF610TWR board.
> 
> Signed-off-by: Alison Wang <b18965 at freescale.com>
> Signed-off-by: Chao Fu  <b44548 at freescale.com>
> ---
> Changes in v2: None
> 
>  drivers/spi/Kconfig        |   6 +
>  drivers/spi/Makefile       |   1 +
>  drivers/spi/spi-fsl-dspi.c | 673 +++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 680 insertions(+)
>  create mode 100644 drivers/spi/spi-fsl-dspi.c
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 89cbbab..068715d 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -248,6 +248,12 @@ config SPI_FSL_SPI
>  	  This also enables using the Aeroflex Gaisler GRLIB SPI controller in
>  	  master mode.
>  
> +config SPI_FSL_DSPI
> +         tristate "Freescale DSPI controller"
> +         help
> +         This enables support for the Freescale DSPI controller in master
> +         mode.
> +
>  config SPI_FSL_ESPI
>  	bool "Freescale eSPI controller"
>  	depends on FSL_SOC
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 33f9c09..78416fd 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_SPI_EP93XX)		+= spi-ep93xx.o
>  obj-$(CONFIG_SPI_FALCON)		+= spi-falcon.o
>  obj-$(CONFIG_SPI_FSL_CPM)		+= spi-fsl-cpm.o
>  obj-$(CONFIG_SPI_FSL_LIB)		+= spi-fsl-lib.o
> +obj-$(CONFIG_SPI_FSL_DSPI)		+= spi-fsl-dspi.o
>  obj-$(CONFIG_SPI_FSL_ESPI)		+= spi-fsl-espi.o
>  obj-$(CONFIG_SPI_FSL_SPI)		+= spi-fsl-spi.o
>  obj-$(CONFIG_SPI_GPIO)			+= spi-gpio.o
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> new file mode 100644
> index 0000000..a187b6f
> --- /dev/null
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -0,0 +1,673 @@
> +/*
> + * drivers/spi/spi-fsl-dspi.c
> + *
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * Freescale DSPI driver
> + * This file contains a driver for the Freescale DSPI
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/interrupt.h>
> +#include <linux/errno.h>
> +#include <linux/platform_device.h>
> +#include <linux/sched.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/spi/spi.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +
> +#define DRIVER_NAME "fsl-dspi"
> +
> +#define TRAN_STATE_RX_VOID		0x01
> +#define TRAN_STATE_TX_VOID		0x02
> +#define TRAN_STATE_WORD_ODD_NUM		0x04
> +
> +#define DSPI_FIFO_SIZE			4
> +
> +#define SPI_MCR			0x00
> +#define SPI_TCR			0x08
> +
> +#define SPI_CTAR(x)		(0x0c + (x * 4))
> +#define SPI_CTAR_FMSZ(x)	(((x) & 0x0000000f) << 27)
> +#define SPI_CTAR_CPOL(x)	((x) << 26)
> +#define SPI_CTAR_CPHA(x)	((x) << 25)
> +#define SPI_CTAR_PCSSCR(x)	(((x) & 0x00000003) << 22)
> +#define SPI_CTAR_PASC(x)	(((x) & 0x00000003) << 20)
> +#define SPI_CTAR_PDT(x)		(((x) & 0x00000003) << 18)
> +#define SPI_CTAR_PBR(x)		(((x) & 0x00000003) << 16)
> +#define SPI_CTAR_CSSCK(x)	(((x) & 0x0000000f) << 12)
> +#define SPI_CTAR_ASC(x)		(((x) & 0x0000000f) << 8)
> +#define SPI_CTAR_DT(x)		(((x) & 0x0000000f) << 4)
> +#define SPI_CTAR_BR(x)		((x) & 0x0000000f)
> +
> +#define SPI_CTAR0_SLAVE		0x0c
> +
> +#define SPI_SR			0x2c
> +#define SPI_SR_EOQF		0x10000000
> +
> +#define SPI_RSER		0x30
> +#define SPI_RSER_EOQFE		0x10000000
> +
> +#define SPI_PUSHR		0x34
> +#define SPI_PUSHR_CONT		(1 << 31)
> +#define SPI_PUSHR_CTAS(x)	(((x) & 0x00000007) << 28)
> +#define SPI_PUSHR_EOQ		(1 << 27)
> +#define SPI_PUSHR_CTCNT		(1 << 26)
> +#define SPI_PUSHR_PCS(x)	(((1 << x) & 0x0000003f) << 16)
> +#define SPI_PUSHR_TXDATA(x)	((x) & 0x0000ffff)
> +
> +#define SPI_PUSHR_SLAVE		0x34
> +
> +#define SPI_POPR		0x38
> +#define SPI_POPR_RXDATA(x)	((x) & 0x0000ffff)
> +
> +#define SPI_TXFR0		0x3c
> +#define SPI_TXFR1		0x40
> +#define SPI_TXFR2		0x44
> +#define SPI_TXFR3		0x48
> +#define SPI_RXFR0		0x7c
> +#define SPI_RXFR1		0x80
> +#define SPI_RXFR2		0x84
> +#define SPI_RXFR3		0x88
> +
> +#define SPI_FRAME_BITS		SPI_CTAR_FMSZ(0xf)
> +#define SPI_FRAME_BITS_16	SPI_CTAR_FMSZ(0xf)
> +#define SPI_FRAME_BITS_8	SPI_CTAR_FMSZ(0x7)

Wouldn't a define

SPI_FRAME_BITS(bits) SPI_CTAR_FMSZ((bits) - 1)

make more sense?

> +
> +#define SPI_CS_INIT		0x01
> +#define SPI_CS_ASSERT		0x02
> +#define SPI_CS_DROP		0x04
> +
> +struct DSPI_MCR {
> +	unsigned halt:1;
> +	unsigned reserved71:7;
> +	unsigned smpl_pt:2;
> +	unsigned clr_rxf:1;
> +	unsigned clr_tx:1;
> +	unsigned dis_rxf:1;
> +	unsigned dis_tx:1;
> +	unsigned mdis:1;
> +	unsigned reserved15:1;
> +	unsigned pcsis:8;
> +	unsigned rooe:1;
> +	unsigned pcsse:1;
> +	unsigned mtfe:1;
> +	unsigned frz:1;
> +	unsigned dconf:2;
> +	unsigned cont_scke:1;
> +	unsigned master:1;
> +};
> +
> +struct DSPI_CTAR {
> +	unsigned br:4;
> +	unsigned dt:4;
> +	unsigned asc:4;
> +	unsigned cssck:4;
> +	unsigned pbr:2;
> +	unsigned pdt:2;
> +	unsigned pasc:2;
> +	unsigned pcssck:2;
> +	unsigned lsbfe:1;
> +	unsigned cpha:1;
> +	unsigned cpol:1;
> +	unsigned fmsz:4;
> +	unsigned dbr:1;
> +};
> +
> +struct chip_data {
> +	/* dspi data */
> +	union {
> +		u32 mcr_val;
> +		struct DSPI_MCR mcr;
> +	};
> +	union {
> +		u32 ctar_val;
> +		struct DSPI_CTAR ctar;
> +	};

No. Never ever use bitfields and lay them over registers. This may work
by accident, but the compiler is free to rearrange the fields.

> +	u16 void_write_data;
> +};
> +
> +struct fsl_dspi {
> +	struct platform_device *pdev;
> +	struct spi_master *master;
> +
> +	void *base;
> +	int irq;
> +	struct clk *clk;
> +
> +	struct spi_message *cur_msg;
> +	struct spi_transfer *cur_transfer;
> +	struct chip_data *cur_chip;
> +	size_t len;
> +	void *tx;
> +	void *tx_end;
> +	void *rx;
> +	void *rx_end;
> +	char dataflags;
> +	u8 cs;
> +	u16 void_write_data;
> +	unsigned	cs_change:1;
> +
> +	wait_queue_head_t waitq;
> +	u32 waitflags;
> +};
> +
> +/* SPI local functions */
> +static inline int is_word_transfer(struct fsl_dspi *dspi)
> +{
> +	return ((readl(dspi->base + SPI_CTAR(dspi->cs)) & SPI_FRAME_BITS)
> +			== SPI_FRAME_BITS_8) ? 0 : 1;
> +}
> +
> +static void set_8bit_transfer_mode(struct fsl_dspi *dspi)
> +{
> +	u32 temp;
> +
> +	temp = readl(dspi->base + SPI_CTAR(dspi->cs));
> +	temp &= ~SPI_FRAME_BITS;
> +	temp |= SPI_FRAME_BITS_8;
> +	writel(temp, dspi->base + SPI_CTAR(dspi->cs));
> +}
> +
> +static void set_16bit_transfer_mode(struct fsl_dspi *dspi)
> +{
> +	u32 temp;
> +
> +	temp = readl(dspi->base + SPI_CTAR(dspi->cs));
> +	temp &= ~SPI_FRAME_BITS;
> +	temp |= SPI_FRAME_BITS_16;
> +	writel(temp, dspi->base + SPI_CTAR(dspi->cs));
> +}

No need to make these separate functions. And I don't think there's need
to make this a read/modify/write operation. Just keep a local variable
'cs' where you need it and compose it as necessary.

> +
> +static unsigned char hz_to_spi_baud(int pbr, int dbr, int speed_hz,
> +		unsigned long clkrate)
> +{
> +	/* Valid baud rate pre-scaler values */
> +	int pbr_tbl[4] = {2, 3, 5, 7};
> +	int brs[16] = {	2,	4,	6,	8,
> +		16,	32,	64,	128,
> +		256,	512,	1024,	2048,
> +		4096,	8192,	16384,	32768 };
> +	int temp, index = 0;
> +
> +	/* table indexes out of range, go slow */
> +	if ((pbr < 0) || (pbr > 3) || (dbr < 0) || (dbr > 1))
> +		return 15;
> +
> +	/* cpu core clk need to check */
> +	temp = ((((clkrate / 2) / pbr_tbl[pbr]) * (1 + dbr)) / speed_hz);
> +
> +	while (temp > brs[index])
> +		if (index++ >= 15)

Use ARRAY_SIZE()

> +			break;
> +
> +	return index;
> +}
> +
> +static void dspi_setup_chip(struct fsl_dspi *dspi)
> +{
> +	struct chip_data *chip = dspi->cur_chip;
> +
> +	writel(chip->mcr_val, dspi->base + SPI_MCR);
> +	writel(chip->ctar_val, dspi->base + SPI_CTAR(dspi->cs));
> +	writel(SPI_RSER_EOQFE, dspi->base + SPI_RSER);
> +}

This is only called once. Make this code inline where you need it.

> +
> +static int dspi_transfer_write(struct fsl_dspi *dspi)
> +{
> +	int tx_count = 0;
> +	int tx_word;
> +	u16 d16;
> +	u8  d8;
> +	u32 dspi_pushr = 0;
> +	int first = 1;
> +
> +	tx_word = is_word_transfer(dspi);
> +	/* If we are in word mode, but only have a single byte to transfer
> +	 * then switch to byte mode temporarily.  Will switch back at the
> +	 * end of the transfer. */

Not sure if I understand this, but if you are in word mode then I would
consider it a bug when there's only one byte to transfer.

> +	if (tx_word && (dspi->len == 1)) {
> +		dspi->dataflags |= TRAN_STATE_WORD_ODD_NUM;
> +		set_8bit_transfer_mode(dspi);
> +		tx_word = 0;
> +	}
> +	while (dspi->len && (tx_count < DSPI_FIFO_SIZE)) {
> +		if (tx_word) {
> +			if (dspi->len == 1)
> +				break;
> +
> +			if (!(dspi->dataflags & TRAN_STATE_TX_VOID)) {
> +				d16 = *(u16 *)dspi->tx;
> +				dspi->tx += 2;
> +			} else {
> +				d16 = dspi->void_write_data;
> +			}
> +
> +			dspi_pushr = SPI_PUSHR_TXDATA(d16) |
> +				SPI_PUSHR_PCS(dspi->cs) |
> +				SPI_PUSHR_CTAS(dspi->cs) |
> +				SPI_PUSHR_CONT;
> +
> +			dspi->len -= 2;
> +		} else {
> +			if (!(dspi->dataflags & TRAN_STATE_TX_VOID)) {
> +
> +				d8 = *(u8 *)dspi->tx;
> +				dspi->tx++;
> +			} else {
> +				d8 = (u8)dspi->void_write_data;
> +			}
> +
> +			dspi_pushr = SPI_PUSHR_TXDATA(d8) |
> +				SPI_PUSHR_PCS(dspi->cs) |
> +				SPI_PUSHR_CTAS(dspi->cs) |
> +				SPI_PUSHR_CONT;
> +
> +			dspi->len--;
> +		}
> +
> +		if (dspi->len == 0
> +				|| tx_count == DSPI_FIFO_SIZE - 1) {
> +			/* last transfer in the queue */
> +			dspi_pushr |= SPI_PUSHR_EOQ;
> +			if ((dspi->cs_change)
> +					&& (!dspi->len))
> +				dspi_pushr &= ~SPI_PUSHR_CONT;
> +		} else if (tx_word && (dspi->len == 1))
> +			dspi_pushr |= SPI_PUSHR_EOQ;
> +
> +		if (first) {
> +			first = 0;
> +			dspi_pushr |= SPI_PUSHR_CTCNT; /* clear counter */
> +		}
> +
> +		writel(dspi_pushr, dspi->base + SPI_PUSHR);
> +		tx_count++;
> +	}
> +
> +	return tx_count * (tx_word + 1);
> +}
> +static int dspi_transfer_read(struct fsl_dspi *dspi)
> +{
> +	int rx_count = 0;
> +	int rx_word = is_word_transfer(dspi);
> +	u16 d;
> +	while ((dspi->rx < dspi->rx_end)
> +			&& (rx_count < DSPI_FIFO_SIZE)) {
> +		if (rx_word) {
> +			if ((dspi->rx_end - dspi->rx) == 1)
> +				break;
> +
> +			d = SPI_POPR_RXDATA(readl(dspi->base + SPI_POPR));
> +
> +			if (!(dspi->dataflags & TRAN_STATE_RX_VOID))
> +				*(u16 *)dspi->rx = d;
> +			dspi->rx += 2;
> +
> +		} else {
> +			d = SPI_POPR_RXDATA(readl(dspi->base + SPI_POPR));
> +			if (!(dspi->dataflags & TRAN_STATE_RX_VOID))
> +				*(u8 *)dspi->rx = d;
> +			dspi->rx++;
> +		}
> +		rx_count++;
> +	}
> +
> +	return rx_count;
> +}
> +
> +static int dspi_transfer_one_message(struct spi_master *master,
> +		struct spi_message *message)
> +{
> +	struct fsl_dspi *dspi = spi_master_get_devdata(master);
> +	struct spi_device *spi = message->spi;
> +	struct spi_transfer *transfer;
> +	int status = 0;
> +	message->actual_length = 0;
> +
> +	list_for_each_entry(transfer, &message->transfers, transfer_list) {

Since your hardware can't handle whole messages at once: Have you
considered using the bitbang driver?

> +		dspi->cur_msg = message;
> +		dspi->cur_transfer = transfer;
> +		dspi->cur_chip = spi_get_ctldata(spi);
> +		dspi->cs = spi->chip_select;
> +		if (dspi->cur_transfer->transfer_list.next
> +				== &dspi->cur_msg->transfers)
> +			transfer->cs_change = 1;
> +		dspi->cs_change = transfer->cs_change;
> +		dspi->void_write_data = dspi->cur_chip->void_write_data;
> +
> +		dspi_setup_chip(dspi);
> +
> +		dspi->dataflags = 0;
> +		dspi->tx = (void *)transfer->tx_buf;
> +		dspi->tx_end = dspi->tx + transfer->len;
> +		dspi->rx = transfer->rx_buf;
> +		dspi->rx_end = dspi->rx + transfer->len;
> +		dspi->len = transfer->len;
> +
> +		if (!dspi->rx)
> +			dspi->dataflags |= TRAN_STATE_RX_VOID;
> +
> +		if (!dspi->tx)
> +			dspi->dataflags |= TRAN_STATE_TX_VOID;
> +
> +		if (transfer->speed_hz)
> +			writel((dspi->cur_chip->ctar_val & ~0xf) |
> +				hz_to_spi_baud(dspi->cur_chip->ctar.pbr,
> +					dspi->cur_chip->ctar.dbr,
> +					transfer->speed_hz,
> +					clk_get_rate(dspi->clk)),
> +					dspi->base + SPI_CTAR(dspi->cs));
> +
> +		message->actual_length += dspi_transfer_write(dspi);
> +
> +		wait_event_interruptible(dspi->waitq, dspi->waitflags);

This function can fail.

> +		dspi->waitflags = 0;
> +
> +		if (transfer->delay_usecs)
> +			udelay(transfer->delay_usecs);
> +	}
> +	message->status = status;
> +	spi_finalize_current_message(master);
> +
> +	return status;
> +}
> +
> +static int dspi_prepare_transfer_hw(struct spi_master *master)
> +{
> +	struct fsl_dspi *dspi = spi_master_get_devdata(master);
> +
> +	pm_runtime_get_sync(&dspi->pdev->dev);
> +
> +	return 0;
> +}
> +
> +static int dspi_unprepare_transfer_hw(struct spi_master *master)
> +{
> +	struct fsl_dspi *dspi = spi_master_get_devdata(master);
> +
> +	pm_runtime_put_sync(&dspi->pdev->dev);
> +
> +	return 0;
> +}
> +
> +static int dspi_setup(struct spi_device *spi)
> +{
> +	struct chip_data *chip;
> +	struct fsl_dspi *dspi = spi_master_get_devdata(spi->master);
> +	struct device_node *np = spi->dev.of_node;
> +	unsigned char br = 0;
> +	unsigned int dbr = 0 , pbr = 0;
> +
> +	/* Only alloc on first setup */
> +	chip = spi_get_ctldata(spi);
> +	if (chip == NULL) {
> +		chip = kcalloc(1, sizeof(struct chip_data), GFP_KERNEL);
> +		if (!chip)
> +			return -ENOMEM;
> +	}
> +
> +	chip->mcr.master = 1;
> +	chip->mcr.cont_scke = 0;
> +	chip->mcr.dconf = 0;
> +	chip->mcr.frz = 0;
> +	chip->mcr.mtfe = 0;
> +	chip->mcr.pcsse = 0;
> +	chip->mcr.rooe = 0;
> +	chip->mcr.pcsis = 0xFF;
> +	chip->mcr.reserved15 = 0;
> +	chip->mcr.mdis = 0;
> +	chip->mcr.dis_tx = 0;
> +	chip->mcr.dis_rxf = 0;
> +	chip->mcr.clr_tx = 1;
> +	chip->mcr.clr_rxf = 1;
> +	chip->mcr.smpl_pt = 0;
> +	chip->mcr.reserved71 = 0;
> +	chip->mcr.halt = 0;
> +
> +	if ((spi->bits_per_word >= 4) && (spi->bits_per_word <= 16)) {
> +		chip->ctar.fmsz = spi->bits_per_word - 1;
> +	} else {
> +		printk(KERN_ERR "Invalid wordsize\n");

Use dev_* functions for printing messages in drivers.

> +		kfree(chip);
> +		return -ENODEV;
> +	}
> +
> +	chip->void_write_data = 0;
> +	chip->ctar.cpha = (spi->mode & SPI_CPHA) ? 1 : 0;
> +	chip->ctar.cpol = (spi->mode & SPI_CPOL) ? 1 : 0;
> +	chip->ctar.lsbfe = (spi->mode & SPI_LSB_FIRST) ? 1 : 0;
> +	of_property_read_u32(np, "dspi,ctar-dbr", &dbr);
> +	of_property_read_u32(np, "dspi,ctar-pbr", &pbr);

I doubt this is a valid binding. Even if it is you shouldn't read of
properties each time in setup()

> +	chip->ctar.dbr = dbr;
> +	chip->ctar.pbr = pbr;
> +	if (spi->max_speed_hz == 0)
> +		return -ENODEV;

This check is probably not necessary.

> +	br = hz_to_spi_baud(chip->ctar.pbr, chip->ctar.dbr,
> +			spi->max_speed_hz, clk_get_rate(dspi->clk));
> +	chip->ctar.br = br;
> +	chip->ctar.pcssck = 0;
> +	chip->ctar.pasc = 0;
> +	chip->ctar.pdt = 0;
> +	chip->ctar.cssck = 0;
> +	chip->ctar.asc = 0;
> +	chip->ctar.dt = 0;
> +
> +	spi_set_ctldata(spi, chip);
> +
> +	return 0;
> +}
> +
> +static void dspi_cleanup(struct spi_device *spi)
> +{
> +	struct chip_data *chip = spi_get_ctldata((struct spi_device *)spi);
> +
> +	dev_dbg(&spi->dev, "spi_device %u.%u cleanup\n",
> +			spi->master->bus_num, spi->chip_select);
> +
> +	kfree(chip);
> +}
> +
> +static irqreturn_t dspi_interrupt(int irq, void *dev_id)
> +{
> +	struct fsl_dspi *dspi = (struct fsl_dspi *)dev_id;
> +	struct spi_message *msg = dspi->cur_msg;
> +
> +	writel(SPI_SR_EOQF, dspi->base + SPI_SR);
> +
> +	if (!dspi->cur_msg) {
> +		u32 irq_status = readl(dspi->base + SPI_SR);
> +		printk(KERN_ERR "Bad message or transfer state handler. "
> +				"IRQ status = %x\n", irq_status);
> +		return IRQ_HANDLED;
> +	}
> +
> +	dspi_transfer_read(dspi);
> +
> +	if (!dspi->len) {
> +		/*
> +		 * Finished now - fall through and schedule next
> +		 * transfer tasklet
> +		 */
> +		if (dspi->dataflags & TRAN_STATE_WORD_ODD_NUM)
> +			set_16bit_transfer_mode(dspi);
> +		dspi->waitflags = 1;
> +		wake_up_interruptible(&dspi->waitq);
> +
> +	} else {
> +		/* not finished yet - keep going */
> +		msg->actual_length += dspi_transfer_write(dspi);
> +	}
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static struct of_device_id fsl_dspi_dt_ids[] = {
> +	{ .compatible = "fsl,vf610-dspi", .data = NULL, },
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, fsl_dspi_dt_ids);
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int dspi_suspend(struct device *dev)
> +{
> +	struct spi_master *master = dev_get_drvdata(dev);
> +	struct fsl_dspi *dspi = spi_master_get_devdata(master);
> +
> +	spi_master_suspend(master);
> +	clk_disable_unprepare(dspi->clk);
> +
> +	return 0;
> +}
> +
> +static int dspi_resume(struct device *dev)
> +{
> +
> +	struct spi_master *master = dev_get_drvdata(dev);
> +	struct fsl_dspi *dspi = spi_master_get_devdata(master);
> +
> +	clk_prepare_enable(dspi->clk);
> +	spi_master_resume(master);
> +
> +	return 0;
> +}
> +#endif /* CONFIG_PM_SLEEP */
> +
> +static const struct dev_pm_ops dspi_pm = {
> +	SET_SYSTEM_SLEEP_PM_OPS(dspi_suspend, dspi_resume)
> +};
> +
> +static int dspi_probe(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct spi_master *master;
> +	struct fsl_dspi *dspi;
> +	struct resource *res;
> +	int ret = 0, cs_num, bus_num;
> +
> +	master = spi_alloc_master(&pdev->dev, sizeof(struct fsl_dspi));
> +	if (!master)
> +		return -ENOMEM;
> +
> +	dspi = spi_master_get_devdata(master);
> +	dspi->master = master;
> +
> +	master->cleanup = dspi_cleanup;
> +	master->setup = dspi_setup;
> +	master->transfer = NULL;
> +	master->transfer_one_message = dspi_transfer_one_message;
> +	master->prepare_transfer_hardware = dspi_prepare_transfer_hw;
> +	master->unprepare_transfer_hardware = dspi_unprepare_transfer_hw;
> +	master->mode_bits = SPI_CPOL | SPI_CPHA;
> +	master->bits_per_word_mask = SPI_BPW_MASK(4) | SPI_BPW_MASK(8) |
> +					SPI_BPW_MASK(16);
> +	master->dev.of_node = pdev->dev.of_node;
> +
> +	ret = of_property_read_u32(np, "spi-num-chipselects", &cs_num);
> +	if (ret < 0)
> +		goto fail;
> +	master->num_chipselect = cs_num;
> +
> +	ret = of_property_read_u32(np, "bus-num", &bus_num);
> +	if (ret < 0)
> +		goto fail;
> +	master->bus_num = bus_num;

Drop this. It's not necessary.

> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res) {
> +		dev_err(&pdev->dev, "can't get platform resource\n");
> +		ret = -ENOMEM;
> +		goto fail;
> +	}
> +
> +	dspi->base = devm_ioremap_resource(&pdev->dev, res);
> +	if (!dspi->base) {
> +		ret = EINVAL;
> +		goto fail;
> +	}
> +
> +	dspi->irq = platform_get_irq(pdev, 0);
> +	if (dspi->irq < 0) {
> +		dev_err(&pdev->dev, "can't get platform irq\n");
> +		ret = -ENOMEM;
> +		goto fail;
> +	}
> +
> +	ret = devm_request_irq(&pdev->dev, dspi->irq, dspi_interrupt, 0,
> +			pdev->name, dspi);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "Unable to attach DSPI interrupt\n");
> +		goto fail;
> +	}
> +
> +	dspi->clk = devm_clk_get(&pdev->dev, "dspi");
> +	if (IS_ERR(dspi->clk)) {
> +		dev_err(&pdev->dev, "unable to get clock\n");
> +		goto fail;
> +	}
> +	clk_prepare_enable(dspi->clk);
> +
> +	init_waitqueue_head(&dspi->waitq);
> +
> +	/* Register with the SPI framework */
> +	platform_set_drvdata(pdev, dspi);
> +	ret = spi_register_master(master);
> +	if (ret != 0) {
> +		dev_err(&pdev->dev, "Problem registering DSPI master\n");
> +		ret = -EINVAL;

Propagate the error value instead of rewriting it.

> +		goto fail;
> +	}
> +
> +	printk(KERN_INFO "Freescale DSPI master initialized\n");
> +	return ret;
> +
> +fail:
> +	spi_master_put(master);
> +	return ret;
> +}
> +
> +static int dspi_remove(struct platform_device *pdev)
> +{
> +	struct fsl_dspi *dspi = platform_get_drvdata(pdev);
> +
> +	if (!dspi)
> +		return 0;

Unnecessary. Drop this.

> +
> +	clk_disable_unprepare(dspi->clk);
> +	clk_put(dspi->clk);

You can't drop resources allocated with devm_* with their non devm_
conterparts. Drop this.

> +
> +	/* Disconnect from the SPI framework */
> +	spi_unregister_master(dspi->master);
> +	spi_master_put(dspi->master);
> +
> +	/* Prevent double remove */
> +	platform_set_drvdata(pdev, NULL);

Unnecessary. Drop this.

> +
> +	return 0;
> +}
> +
> +static struct platform_driver fsl_dspi_driver = {
> +	.driver.name    = DRIVER_NAME,
> +	.driver.of_match_table = fsl_dspi_dt_ids,
> +	.driver.owner   = THIS_MODULE,
> +	.driver.pm = &dspi_pm,
> +	.probe          = dspi_probe,
> +	.remove		= dspi_remove,
> +};
> +module_platform_driver(fsl_dspi_driver);
> +
> +MODULE_DESCRIPTION("Freescale DSPI Controller Driver");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:" DRIVER_NAME);
> -- 
> 1.8.0
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From s.hauer at pengutronix.de  Fri Jul 26 03:38:48 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 26 Jul 2013 09:38:48 +0200
Subject: [PATCH 2/2] video: imxfb: Add feature to setup PWM Contrast
 Control Register
In-Reply-To: <20130725212053.b39198a8610efc157a91b7be@mail.ru>
References: <1374395709-20898-1-git-send-email-shc_work@mail.ru>
 <1374395709-20898-2-git-send-email-shc_work@mail.ru>
 <20130725133824.GD16871@s25.your-server.de>
 <20130725212053.b39198a8610efc157a91b7be@mail.ru>
Message-ID: <20130726073848.GF2737@pengutronix.de>

On Thu, Jul 25, 2013 at 09:20:53PM +0400, Alexander Shiyan wrote:
> On Thu, 25 Jul 2013 15:38:56 +0200
> Markus Pargmann <mpa at pengutronix.de> wrote:
> 
> > Hi,
> > 
> > On Sun, Jul 21, 2013 at 12:35:09PM +0400, Alexander Shiyan wrote:
> > > This patch adds feature to setup PWM Contrast Control Register.
> > > This register is used to control the signal output at the contrast pin,
> > > which controls contrast of the LCD panel.
> > 
> > http://www.spinics.net/lists/linux-fbdev/msg10002.html
> 
> PWM? I can not understand how the PWM driver will be connected to the
> framebuffer driver. It is not backlight, this is contrast.
> Even if we imagine that the driver will be connected through phandle,
> then we will need to have at least 4! additional parameters in the framebuffer
> driver: freq source, frequency and active pulse period + phandle to PWM.
> Is it worth it, given that these parameters should not be adjustable?
> On my opinion, the only one additional parameter in framebuffer is enough.
> Thanks.

Why should the contrast of a display not be adjustable?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From rogerq at ti.com  Fri Jul 26 03:50:08 2013
From: rogerq at ti.com (Roger Quadros)
Date: Fri, 26 Jul 2013 10:50:08 +0300
Subject: [PATCH 1/6] usb: phy-nop: Use RESET Controller for managing the
 reset line
In-Reply-To: <20130725172855.GJ25415@radagast>
References: <1374137590-17865-1-git-send-email-rogerq@ti.com>
 <1374137590-17865-2-git-send-email-rogerq@ti.com>
 <20130725172855.GJ25415@radagast>
Message-ID: <51F22A30.80507@ti.com>

On 07/25/2013 08:28 PM, Felipe Balbi wrote:
> On Thu, Jul 18, 2013 at 11:53:05AM +0300, Roger Quadros wrote:
>> Till now we were modelling the RESET line as a voltage regulator and
>> using the regulator framework to manage it.
>>
>> [1] introduces a GPIO based reset controller driver. We use that
>> to manage the PHY reset line, at least for DT boots. For legacy boots,
>> will still need to use the regulator framework for reset lines.
>>
>> [1] - http://thread.gmane.org/gmane.linux.drivers.devicetree/41348
>>
>> Signed-off-by: Roger Quadros <rogerq at ti.com>
> 
> that's not in mainline yet, right ? Is it guaranteed that it will hit
> v3.12 merge window ?
> 
Right. It isn't yet. I'm not sure about 3.12. Let's ask Philipp.

Philipp, is your GPIO Reset driver scheduled for 3.12?

cheers,
-roger


From tomi.valkeinen at ti.com  Fri Jul 26 03:57:12 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Jul 2013 10:57:12 +0300
Subject: [PATCH] video: nuc900fb: fix to pass correct device identity
 to request_irq()
In-Reply-To: <CAPgLHd9CZ=VponJTbTGKTXVTdvMQM6_T+-RWuPMrk0WYZPbW1Q@mail.gmail.com>
References: <CAPgLHd9CZ=VponJTbTGKTXVTdvMQM6_T+-RWuPMrk0WYZPbW1Q@mail.gmail.com>
Message-ID: <51F22BD8.8090604@ti.com>

On 16/07/13 03:07, Wei Yongjun wrote:
> The IRQ handler nuc900fb_irqhandler() use dev_id as a type of
> struct nuc900fb_info *, so we should pass fbi as the device
> identity to request_irq().
> 
> Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> ---
> Was 'video: nuc900fb: fix to pass correct device identity to free_irq()'
> ---
>  drivers/video/nuc900fb.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index 8c527e5..796e511 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -587,8 +587,7 @@ static int nuc900fb_probe(struct platform_device *pdev)
>  	fbinfo->flags			= FBINFO_FLAG_DEFAULT;
>  	fbinfo->pseudo_palette		= &fbi->pseudo_pal;
>  
> -	ret = request_irq(irq, nuc900fb_irqhandler, 0,
> -			  pdev->name, fbinfo);
> +	ret = request_irq(irq, nuc900fb_irqhandler, 0, pdev->name, fbi);
>  	if (ret) {
>  		dev_err(&pdev->dev, "cannot register irq handler %d -err %d\n",
>  			irq, ret);
> 

Thanks, I've applied this into my 3.11-fixes/fbdev branch.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/d6d5ff2b/attachment.sig>

From shc_work at mail.ru  Fri Jul 26 03:59:57 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Fri, 26 Jul 2013 11:59:57 +0400
Subject: =?UTF-8?B?UmU6IFtQQVRDSCAyLzJdIHZpZGVvOiBpbXhmYjogQWRkIGZlYXR1cmUgdG8g?=
 =?UTF-8?B?c2V0dXAgUFdNIENvbnRyYXN0IENvbnRyb2wgUmVnaXN0ZXI=?=
In-Reply-To: <20130726073848.GF2737@pengutronix.de>
References: <1374395709-20898-1-git-send-email-shc_work@mail.ru>
 <20130725212053.b39198a8610efc157a91b7be@mail.ru>
 <20130726073848.GF2737@pengutronix.de>
Message-ID: <1374825597.724071106@f170.mail.ru>

> On Thu, Jul 25, 2013 at 09:20:53PM +0400, Alexander Shiyan wrote:
> > On Thu, 25 Jul 2013 15:38:56 +0200
> > Markus Pargmann <mpa at pengutronix.de> wrote:
> > 
> > > Hi,
> > > 
> > > On Sun, Jul 21, 2013 at 12:35:09PM +0400, Alexander Shiyan wrote:
> > > > This patch adds feature to setup PWM Contrast Control Register.
> > > > This register is used to control the signal output at the contrast pin,
> > > > which controls contrast of the LCD panel.
> > > 
> > > http://www.spinics.net/lists/linux-fbdev/msg10002.html
> > 
> > PWM? I can not understand how the PWM driver will be connected to the
> > framebuffer driver. It is not backlight, this is contrast.
> > Even if we imagine that the driver will be connected through phandle,
> > then we will need to have at least 4! additional parameters in the framebuffer
> > driver: freq source, frequency and active pulse period + phandle to PWM.
> > Is it worth it, given that these parameters should not be adjustable?
> > On my opinion, the only one additional parameter in framebuffer is enough.
> > Thanks.
> 
> Why should the contrast of a display not be adjustable?

I still can not understand the interface through which it can be changed.
Same as how the default settings can be passed to the framebuffer driver.

---

From richardcochran at gmail.com  Fri Jul 26 04:01:15 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Fri, 26 Jul 2013 10:01:15 +0200
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130725213753.GC17616@obsidianresearch.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
Message-ID: <20130726080115.GA5436@netboy>

On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
> 
> We use DT has a kernel configuration input. Our environment is
> designed to guarantee 100% that the kernel and DT match exactly. DT
> very deliberately isn't an ABI boundary in our systems.

Think about what you just said.

The DT describes the *hardware* not the kernel. Why should you ever
need to update your DT at all?

(Hint: the answer is, because the DT system is broken.)

Thanks,
Richard


From thomas.petazzoni at free-electrons.com  Fri Jul 26 04:13:05 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 26 Jul 2013 10:13:05 +0200
Subject: [PATCHv5 08/11] ARM: pci: add ->add_bus() and ->remove_bus()
 hooks to hw_pci
In-Reply-To: <20130725165659.GB27802@dhcp-172-17-186-34.nvidia.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130725165659.GB27802@dhcp-172-17-186-34.nvidia.com>
Message-ID: <20130726101305.22a5c892@skate>

Dear Thierry Reding,

On Thu, 25 Jul 2013 09:57:00 -0700, Thierry Reding wrote:
> On Mon, Jul 15, 2013 at 01:52:44PM +0200, Thomas Petazzoni wrote:
> > Some PCI drivers may need to adjust the pci_bus structure after it has
> > been allocated by the Linux PCI core. The PCI core allows
> > architectures to implement the pcibios_add_bus() and
> > pcibios_remove_bus() for this purpose. This commit therefore extends
> > the hw_pci and pci_sys_data structures of the ARM PCI core to allow
> > PCI drivers to register ->add_bus() and ->remove_bus() in hw_pci,
> > which will get called when a bus is added or removed from the system.
> > 
> > This will be used for example by the Marvell PCIe driver to connect a
> > particular PCI bus with its corresponding MSI chip to handle Message
> > Signaled Interrupts.
> > 
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > Reviewed-by: Thierry Reding <thierry.reding at gmail.com>
> > ---
> >  arch/arm/include/asm/mach/pci.h |  4 ++++
> >  arch/arm/kernel/bios32.c        | 16 ++++++++++++++++
> >  2 files changed, 20 insertions(+)
> 
> Hi Russell,
> 
> Can we have your Acked-by on this patch so that it can be moved to a
> stable branch along with some of the other patches in this branch that
> both Marvell and Tegra PCIe drivers need?

I've pinged Russell a few times about this patch already, but haven't
received feedback from him. Do you think I can just go ahead and submit
the patch to Russell's patch system, after fixing the minor nits you
mentioned?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From sachin.kamat at linaro.org  Fri Jul 26 04:48:46 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Fri, 26 Jul 2013 14:18:46 +0530
Subject: [PATCH 1/3] clk: exynos5250: Add G2D gate clock
In-Reply-To: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
References: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <CAK9yfHwdte8XPey-uM=hy1z7ryFSOzEZspLBz7po3c2ktXvAyw@mail.gmail.com>

On 5 July 2013 14:12, Sachin Kamat <sachin.kamat at linaro.org> wrote:
> Adds gate clock for G2D IP for Exynos5250 SoC.
>
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> Cc: Mike Turquette <mturquette at linaro.org>
> ---
> This patch depends on the following patch:
> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20581
> ---
>  .../devicetree/bindings/clock/exynos5250-clock.txt |    1 +
>  drivers/clk/samsung/clk-exynos5250.c               |    5 ++++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> index 1a05761..7e88242 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> @@ -155,6 +155,7 @@ clock which they consume.
>    dp                   342
>    mixer                        343
>    hdmi                 344
> +  g2d                  345
>
>  Example 1: An example of a clock controller node is listed below.
>
> diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
> index 6f767c5..3da0bdf 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -62,6 +62,7 @@
>  #define SRC_CDREX              0x20200
>  #define PLL_DIV2_SEL           0x20a24
>  #define GATE_IP_DISP1          0x10928
> +#define GATE_IP_ACP            0x10000
>
>  /*
>   * Let each supported clock get a unique id. This id is used to lookup the clock
> @@ -99,7 +100,7 @@ enum exynos5250_clks {
>         spi2, i2s1, i2s2, pcm1, pcm2, pwm, spdif, ac97, hsi2c0, hsi2c1, hsi2c2,
>         hsi2c3, chipid, sysreg, pmu, cmu_top, cmu_core, cmu_mem, tzpc0, tzpc1,
>         tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
> -       wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
> +       wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, g2d,
>
>         nr_clks,
>  };
> @@ -152,6 +153,7 @@ static __initdata unsigned long exynos5250_clk_regs[] = {
>         SRC_CDREX,
>         PLL_DIV2_SEL,
>         GATE_IP_DISP1,
> +       GATE_IP_ACP,
>  };
>
>  /* list of all parent clock list */
> @@ -463,6 +465,7 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
>         GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
>         GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
>         GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
> +       GATE(g2d, "g2d", "aclk200", GATE_IP_ACP, 3, 0, 0),
>  };
>
>  static __initdata struct of_device_id ext_clk_match[] = {
> --
> 1.7.9.5
>

Ping Mike.

-- 
With warm regards,
Sachin


From will.deacon at arm.com  Fri Jul 26 04:55:42 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 26 Jul 2013 09:55:42 +0100
Subject: [PATCH v3 1/3] ARM: BCM5301X: initial support for the
 BCM5301X/BCM470X SoCs with ARM CPU
In-Reply-To: <1374792135-30343-2-git-send-email-hauke@hauke-m.de>
References: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
 <1374792135-30343-2-git-send-email-hauke@hauke-m.de>
Message-ID: <20130726085542.GA17886@mudshark.cambridge.arm.com>

On Thu, Jul 25, 2013 at 11:42:13PM +0100, Hauke Mehrtens wrote:
> This patch adds support for the BCM5301X/BCM470X SoCs with an ARM CPUs.
> Currently just booting to a shell is working and nothing else, no
> Ethernet, wifi, flash, ...
> 
> This SoC is used in small office and home router with Broadcom SoCs.
> This code should support the BCM4707, BCM4708, BCM4709, BCM53010,
> BCM53011 and BCM53012 SoC. It uses one or two ARM Cortex A9
> Cores, some highlights are 2 PCIe 2.0 controllers, 4 Gigabit Ethernet
> MACs and a USB 3.0 host controller.
> 
> This SoC uses a dual core CPU, but this is currently not implemented.
> More information about this SoC can be found here:
> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers

[...]

> +static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
> +				 struct pt_regs *regs)
> +{
> +	/*
> +	 * These happen for no good reason, possibly left over from CFE
> +	 */
> +	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
> +		addr, fsr);
> +
> +	/* Returning non-zero causes fault display and panic */
> +	return 0;
> +}
> +
> +static void __init bcm5301x_init_early(void)
> +{
> +	/* Install our hook */
> +	hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, 0,
> +			"imprecise external abort");
> +}

Surely you can't be serious?

At least, we need a pretty good explanation of what *exactly* is causing
these spurious aborts before we start ignoring them unconditionally like
this. You're effectively masking an extremely serious error indicator with
this change.

Cheers,

Will


From simon.guinot at sequanux.org  Fri Jul 26 04:56:23 2013
From: simon.guinot at sequanux.org (Simon Guinot)
Date: Fri, 26 Jul 2013 10:56:23 +0200
Subject: Location for a kind of GPIO bus driver
In-Reply-To: <20130725160324.GJ23879@titan.lakedaemon.net>
References: <20130723151834.GJ9916@kw.sim.vm.gnt>
 <20130724181924.GI19736@titan.lakedaemon.net>
 <20130725154932.GL9916@kw.sim.vm.gnt>
 <20130725160324.GJ23879@titan.lakedaemon.net>
Message-ID: <20130726085623.GM9916@kw.sim.vm.gnt>

On Thu, Jul 25, 2013 at 12:03:24PM -0400, Jason Cooper wrote:
> On Thu, Jul 25, 2013 at 05:49:32PM +0200, Simon Guinot wrote:
> > On Wed, Jul 24, 2013 at 02:19:24PM -0400, Jason Cooper wrote:
> > > On Tue, Jul 23, 2013 at 05:18:34PM +0200, Simon Guinot wrote:
> > > > Hi,
> > > > 
> > > > I am currently working on converting the LED driver leds-netxbig to DT.
> > > > Doing so, I am also considering to move the GPIO extension bus functions
> > > > (which are currently parts of leds-netxbig) into a separate driver.
> > > > 
> > > > On the LaCie "Big Network" board family (netxbig), the LEDs are
> > > > controlled by a CPLD. In turn, the CPLD can be configured (mostly the
> > > > LEDs modes) through a kind of parallel GPIO bus, called GPIO extension
> > > > bus. Two registers (address and data) are exposed. Each of them is made
> > > > up of several GPIOs. An extra GPIO is used to notify the CPLD that the
> > > > registers have been updated. The leds-netxbig driver uses some dedicated
> > > > functions (prefixed by "gpio_ext_") to handle the GPIO bus extension.
> > > > 
> > > > On the latest "Big Network" boards, this bus is also used to enable the
> > > > PM wakeup sources: the CPLD can be asked to keep powered some devices
> > > > (as the RTC or the Ethernet PHY) while the board is down. I think it
> > > > could be nice to expose this feature to the userland. That's why I am
> > > > thinking about moving the GPIO extension bus support into a separate
> > > > driver. The problem is that I can't find a proper location for a such
> > > > driver. AFAIK, it doesn't fit with anything existing supported by Linux.
> > > > Maybe I should consider drivers/bus ? Or even drivers/misc ?
> > 
> > Hi Jason,
> > 
> > Thanks for your answer.
> > 
> > > 
> > > iiuc, the CPLD is more of gpio multiplexer/expander.  Have you seen
> > > 
> > >   66bcb58 arm: mvebu: enable gpio expander over i2c on Mirabox platform
> > > 
> > > ?  And the corresponding driver, drivers/gpio/gpio-pca953x.c?
> > 
> > All the drivers under drivers/gpio are registering some GPIO chips.
> > It is a big difference with the LaCie "GPIO extension bus". This last
> > is more an extension mechanism on the top of GPIOs already existing
> > (eventually provided by a SoC or a Super-I/O on x86 boards). No new
> > GPIOs are added. I think that the name "extension" is quite confusing.
> 
> Agreed.
> 
> > The idea behind this "bus" is to allow to configure a lot of LEDs (in
> > various modes) using only few GPIOs and a CPLD (which is already
> > available on the board for other purposes). This cheap solution allows
> > precisely to save the cost of a GPIO expander :)
> > 
> > As an example, you can see the "GPIO extension bus" configuration for
> > the Kirkwood "Big Network" boards in:
> > arch/arm/mach-kirkwood/netxbig_v2-setup.c:132.
> > 
> > > 
> > > I would try drivers/gpio.  If there are complaints, it should be trivial
> > > to move it in a new version of the series.
> > 
> > Why not, as long it is clear that the resulting driver will not provide
> > a GPIO chip but rather functions as a library.
> 
> right, but the end result of what the library would do is expose a
> series of LEDs and PM 'virtual gpios'.  So, even though it's not a gpio
> expander per-se, it's still filling that role.  Or am I still missing
> something?

The library could expose a function allowing to set the address and data
registers: gpio_ext_set_value(int addr, int value).

Actually, it is how it works inside leds-netxbig. Simply this function
would be also accessible by other drivers.

> 
> > > Is there any reason why the new capabilities in the "Big Network" boards
> > > couldn't be covered by gpio-regulator?
> > 
> > I don't have looked at the details but I think that gpio-regulator
> > could be able to configure the PM modes through the GPIO extension bus.
> > 
> > But a problem remains. The same GPIOs would be used by two different
> > drivers: leds-netxbig and gpio-regulator. This would lead to some
> > conflicts. That's why I think that at some level a driver is needed to
> > handle the GPIO extension bus.
> 
> It may be simpler to combine it into one driver and place it under
> drivers/mfd as it's certainly a multi-function device.  I don't think
> anyone outside of Lacie is going to be adopting this 'bus'...

I will definitively have a closer look at mfd. But as I understand, mfd
is more oriented platform device and resources. Here, the device don't
expose some memory regions but rather methods to configure a CPLD
through GPIOs. I am not sure how it can work with the mfd framework.

Thanks,

Simon

> 
> thx,
> 
> Jason.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/e2ae24b0/attachment.sig>

From kishon at ti.com  Fri Jul 26 05:03:36 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 14:33:36 +0530
Subject: [PATCH 0/2] usb: fix controller-PHY binding for OMAP3 platform
Message-ID: <1374829418-27503-1-git-send-email-kishon@ti.com>

After the platform devices are created using PLATFORM_DEVID_AUTO, the
device names given in usb_bind_phy (in board file) does not match with
the actual device name causing the USB PHY library not to return the
PHY reference when the MUSB controller request for the PHY in the non-dt boot
case.
So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c.
This is also needed for the Generic PHY Framework [1] after it's redesigned
to address Greg's concerns [2]

*usb: musb: fix USB enumeration issue in OMAP3 platform* can be dropped since
this patch series should fix the same issue.

I've tested in beagle, but if any of you have any other OMAP3 boards, would be
great if you can test it too.

[1] -> https://git.kernel.org/cgit/linux/kernel/git/kishon/linux-phy.git/
[2] -> http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=101661

Kishon Vijay Abraham I (2):
  usb: musb: omap: remove using PLATFORM_DEVID_AUTO in omap2430.c
  arm: omap: remove *.auto* from device names given in usb_bind_phy

 arch/arm/mach-omap2/board-2430sdp.c          |    2 +-
 arch/arm/mach-omap2/board-3430sdp.c          |    2 +-
 arch/arm/mach-omap2/board-cm-t35.c           |    2 +-
 arch/arm/mach-omap2/board-devkit8000.c       |    2 +-
 arch/arm/mach-omap2/board-igep0020.c         |    2 +-
 arch/arm/mach-omap2/board-ldp.c              |    2 +-
 arch/arm/mach-omap2/board-omap3beagle.c      |    2 +-
 arch/arm/mach-omap2/board-omap3evm.c         |    2 +-
 arch/arm/mach-omap2/board-omap3logic.c       |    2 +-
 arch/arm/mach-omap2/board-omap3pandora.c     |    2 +-
 arch/arm/mach-omap2/board-omap3stalker.c     |    2 +-
 arch/arm/mach-omap2/board-omap3touchbook.c   |    2 +-
 arch/arm/mach-omap2/board-overo.c            |    2 +-
 arch/arm/mach-omap2/board-rm680.c            |    2 +-
 arch/arm/mach-omap2/board-rx51.c             |    2 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c |    2 +-
 drivers/usb/musb/musb_core.c                 |   31 +++++++++++++++++++++++++-
 drivers/usb/musb/musb_core.h                 |    2 ++
 drivers/usb/musb/omap2430.c                  |   16 +++++++++++--
 19 files changed, 62 insertions(+), 19 deletions(-)

-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 05:03:37 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 14:33:37 +0530
Subject: [PATCH 1/2] usb: musb: omap: remove using PLATFORM_DEVID_AUTO in
 omap2430.c
In-Reply-To: <1374829418-27503-1-git-send-email-kishon@ti.com>
References: <1374829418-27503-1-git-send-email-kishon@ti.com>
Message-ID: <1374829418-27503-2-git-send-email-kishon@ti.com>

After the platform devices are created using PLATFORM_DEVID_AUTO, the
device names given in usb_bind_phy (in board file) does not match with
the actual device name causing the USB PHY library not to return the
PHY reference when the MUSB controller request for the PHY in the non-dt boot
case.
So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c.
This is also needed for the Generic PHY Framework.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/usb/musb/musb_core.c |   31 ++++++++++++++++++++++++++++++-
 drivers/usb/musb/musb_core.h |    2 ++
 drivers/usb/musb/omap2430.c  |   16 ++++++++++++++--
 3 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 29a24ce..eb5d876 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -121,7 +121,7 @@ MODULE_DESCRIPTION(DRIVER_INFO);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:" MUSB_DRIVER_NAME);
-
+static DEFINE_IDA(musb_ida);
 
 /*-------------------------------------------------------------------------*/
 
@@ -132,6 +132,35 @@ static inline struct musb *dev_to_musb(struct device *dev)
 
 /*-------------------------------------------------------------------------*/
 
+int musb_get_id(struct device *dev, gfp_t gfp_mask)
+{
+	int ret;
+	int id;
+
+	ret = ida_pre_get(&musb_ida, gfp_mask);
+	if (!ret) {
+		dev_err(dev, "failed to reserve resource for id\n");
+		return -ENOMEM;
+	}
+
+	ret = ida_get_new(&musb_ida, &id);
+	if (ret < 0) {
+		dev_err(dev, "failed to allocate a new id\n");
+		return ret;
+		}
+
+	return id;
+}
+EXPORT_SYMBOL_GPL(musb_get_id);
+
+void musb_put_id(struct device *dev, int id)
+{
+
+	dev_dbg(dev, "removing id %d\n", id);
+	ida_remove(&musb_ida, id);
+}
+EXPORT_SYMBOL_GPL(musb_put_id);
+
 #ifndef CONFIG_BLACKFIN
 static int musb_ulpi_read(struct usb_phy *phy, u32 offset)
 {
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7d341c3..79545a4 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -511,6 +511,8 @@ static inline void musb_configure_ep0(struct musb *musb)
 extern const char musb_driver_name[];
 
 extern void musb_stop(struct musb *musb);
+extern int musb_get_id(struct device *dev, gfp_t gfp_mask);
+extern void musb_put_id(struct device *dev, int id);
 
 extern void musb_write_fifo(struct musb_hw_ep *ep, u16 len, const u8 *src);
 extern void musb_read_fifo(struct musb_hw_ep *ep, u16 len, u8 *dst);
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 6708a3b..812a7fc 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -489,6 +489,7 @@ static int omap2430_probe(struct platform_device *pdev)
 	struct device_node		*np = pdev->dev.of_node;
 	struct musb_hdrc_config		*config;
 	int				ret = -ENOMEM;
+	int				musbid;
 
 	glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);
 	if (!glue) {
@@ -496,10 +497,18 @@ static int omap2430_probe(struct platform_device *pdev)
 		goto err0;
 	}
 
-	musb = platform_device_alloc("musb-hdrc", PLATFORM_DEVID_AUTO);
+	/* get the musb id */
+	musbid = musb_get_id(&pdev->dev, GFP_KERNEL);
+	if (musbid < 0) {
+		dev_err(&pdev->dev, "failed to allocate musb id\n");
+		ret = -ENOMEM;
+		goto err0;
+	}
+
+	musb = platform_device_alloc("musb-hdrc", musbid);
 	if (!musb) {
 		dev_err(&pdev->dev, "failed to allocate musb device\n");
-		goto err0;
+		goto err1;
 	}
 
 	musb->dev.parent		= &pdev->dev;
@@ -607,6 +616,9 @@ static int omap2430_probe(struct platform_device *pdev)
 err2:
 	platform_device_put(musb);
 
+err1:
+	musb_put_id(&pdev->dev, musbid);
+
 err0:
 	return ret;
 }
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 05:03:38 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 14:33:38 +0530
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given in
 usb_bind_phy
In-Reply-To: <1374829418-27503-1-git-send-email-kishon@ti.com>
References: <1374829418-27503-1-git-send-email-kishon@ti.com>
Message-ID: <1374829418-27503-3-git-send-email-kishon@ti.com>

Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while creating
MUSB core device. So in usb_bind_phy (binds the controller with the PHY), the
device name of the controller had *.auto* in it. Since with using
PLATFORM_DEVID_AUTO, there is no way to know the exact device name in advance,
the data given in usb_bind_phy became obsolete and usb_get_phy was failing.
So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO. Corresponding
change is done in board file here.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 arch/arm/mach-omap2/board-2430sdp.c          |    2 +-
 arch/arm/mach-omap2/board-3430sdp.c          |    2 +-
 arch/arm/mach-omap2/board-cm-t35.c           |    2 +-
 arch/arm/mach-omap2/board-devkit8000.c       |    2 +-
 arch/arm/mach-omap2/board-igep0020.c         |    2 +-
 arch/arm/mach-omap2/board-ldp.c              |    2 +-
 arch/arm/mach-omap2/board-omap3beagle.c      |    2 +-
 arch/arm/mach-omap2/board-omap3evm.c         |    2 +-
 arch/arm/mach-omap2/board-omap3logic.c       |    2 +-
 arch/arm/mach-omap2/board-omap3pandora.c     |    2 +-
 arch/arm/mach-omap2/board-omap3stalker.c     |    2 +-
 arch/arm/mach-omap2/board-omap3touchbook.c   |    2 +-
 arch/arm/mach-omap2/board-overo.c            |    2 +-
 arch/arm/mach-omap2/board-rm680.c            |    2 +-
 arch/arm/mach-omap2/board-rx51.c             |    2 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c |    2 +-
 16 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
index 244d8a5..17bb076 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
 	omap_hsmmc_init(mmc);
 
 	omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 
 	board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index 23b004a..5f43fc4 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -590,7 +590,7 @@ static void __init omap_3430sdp_init(void)
 	omap_ads7846_init(1, gpio_pendown, 310, NULL);
 	omap_serial_init();
 	omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 	board_smc91x_init();
 	board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index d4622ed..1c3345d 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -691,7 +691,7 @@ static void __init cm_t3x_common_init(void)
 	cm_t35_init_display();
 	omap_twl4030_audio_init("cm-t3x", NULL);
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 	cm_t35_init_usbh();
 	cm_t35_init_camera();
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index f1d91ba..b4d57ec 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -594,7 +594,7 @@ static void __init devkit8000_init(void)
 
 	omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL);
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 	usbhs_init(&usbhs_bdata);
 	board_nand_init(devkit8000_nand_partitions,
diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index 87e65dd..b1cbbba 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -659,7 +659,7 @@ static void __init igep_init(void)
 	omap_serial_init();
 	omap_sdrc_init(m65kxxxxam_sdrc_params,
 				  m65kxxxxam_sdrc_params);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 
 	igep_flash_init();
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 62e4f70..02d7505 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -377,7 +377,7 @@ static void __init omap_ldp_init(void)
 	omap_ads7846_init(1, 54, 310, NULL);
 	omap_serial_init();
 	omap_sdrc_init(NULL, NULL);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 	board_nand_init(ldp_nand_partitions, ARRAY_SIZE(ldp_nand_partitions),
 			ZOOM_NAND_CS, 0, nand_default_timings);
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 04c1165..c9e6fc6 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -551,7 +551,7 @@ static void __init omap3_beagle_init(void)
 	omap_sdrc_init(mt46h32m32lf6_sdrc_params,
 				  mt46h32m32lf6_sdrc_params);
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 
 	usbhs_init(&usbhs_bdata);
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 8c02626..daabe0c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -706,7 +706,7 @@ static void __init omap3_evm_init(void)
 		omap_mux_init_gpio(135, OMAP_PIN_OUTPUT);
 		phy_data[0].reset_gpio = 135;
 	}
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(&musb_board_data);
 
 	usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
diff --git a/arch/arm/mach-omap2/board-omap3logic.c b/arch/arm/mach-omap2/board-omap3logic.c
index bab51e6..d9a6c38 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -216,7 +216,7 @@ static void __init omap3logic_init(void)
 	board_mmc_init();
 	board_smsc911x_init();
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 
 	/* Ensure SDRC pins are mux'd for self-refresh */
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index b1547a0..fc5c133 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -611,7 +611,7 @@ static void __init omap3pandora_init(void)
 	usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
 	usbhs_init(&usbhs_bdata);
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 	gpmc_nand_init(&pandora_nand_data, NULL);
 
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index d37e6b1..44a38d4 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -394,7 +394,7 @@ static void __init omap3_stalker_init(void)
 
 	omap_serial_init();
 	omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 
 	usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c b/arch/arm/mach-omap2/board-omap3touchbook.c
index 7da48bc..e8e053d 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -367,7 +367,7 @@ static void __init omap3_touchbook_init(void)
 
 	/* Touchscreen and accelerometer */
 	omap_ads7846_init(4, OMAP3_TS_GPIO, 310, &ads7846_pdata);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 
 	usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 5748b5d..1ea764d 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -473,7 +473,7 @@ static void __init overo_init(void)
 				  mt46h32m32lf6_sdrc_params);
 	board_nand_init(overo_nand_partitions,
 			ARRAY_SIZE(overo_nand_partitions), NAND_CS, 0, NULL);
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 
 	usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c
index 345e8c4..d95d219 100644
--- a/arch/arm/mach-omap2/board-rm680.c
+++ b/arch/arm/mach-omap2/board-rm680.c
@@ -135,7 +135,7 @@ static void __init rm680_init(void)
 	sdrc_params = nokia_get_sdram_timings();
 	omap_sdrc_init(sdrc_params, sdrc_params);
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 	rm680_peripherals_init();
 }
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index d2ea68e..4deacd5 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -99,7 +99,7 @@ static void __init rx51_init(void)
 	sdrc_params = nokia_get_sdram_timings();
 	omap_sdrc_init(sdrc_params, sdrc_params);
 
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(&musb_board_data);
 	rx51_peripherals_init();
 
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
index a90375d..474ad1c 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -353,7 +353,7 @@ void __init zoom_peripherals_init(void)
 	omap_i2c_init();
 	pwm_add_table(zoom_pwm_lookup, ARRAY_SIZE(zoom_pwm_lookup));
 	platform_add_devices(zoom_devices, ARRAY_SIZE(zoom_devices));
-	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
 	usb_musb_init(NULL);
 	enable_board_wakeup_source();
 	omap_serial_init();
-- 
1.7.10.4



From horms+renesas at verge.net.au  Fri Jul 26 05:09:32 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Jul 2013 18:09:32 +0900
Subject: [PATCH] ARM: shmobile: lager: do not annotate gpio_buttons as
 __initdata
Message-ID: <1374829772-10939-1-git-send-email-horms+renesas@verge.net.au>

When the gpio-keys device is registered using
platform_device_register_data() the platform data argument,
lager_keys_pdata is duplicated and thus should be marked as __initdata
to avoid wasting memory. However, this is not true of gpio_buttons,
a reference to it rather than its value is duplicated when lager_keys_pdata
is duplicated.

This avoids accessing freed memory if gpio-key events occur
after unused kernel memory is freed late in the kernel's boot.

This but was added when support for gpio-keys was added to lager
in c3842e4fcbb7664276443b79187b7808c2e80a35
("ARM: shmobile: lager: support GPIO switches") which was included
in v3.11-rc1.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

* Noticed when adding gpio-keys support to ape6evm
* Compile tested only
---
 arch/arm/mach-shmobile/board-lager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index 3c67b2a..3a1a6fd 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -63,7 +63,7 @@ static __initdata struct gpio_led_platform_data lager_leds_pdata = {
 #define GPIO_KEY(c, g, d, ...) \
 	{ .code = c, .gpio = g, .desc = d, .active_low = 1 }
 
-static __initdata struct gpio_keys_button gpio_buttons[] = {
+static struct gpio_keys_button gpio_buttons[] = {
 	GPIO_KEY(KEY_4,		RCAR_GP_PIN(1, 28),	"SW2-pin4"),
 	GPIO_KEY(KEY_3,		RCAR_GP_PIN(1, 26),	"SW2-pin3"),
 	GPIO_KEY(KEY_2,		RCAR_GP_PIN(1, 24),	"SW2-pin2"),
-- 
1.8.3.2



From iivanov at mm-sol.com  Fri Jul 26 05:11:35 2013
From: iivanov at mm-sol.com (Ivan T. Ivanov)
Date: Fri, 26 Jul 2013 12:11:35 +0300
Subject: [PATCH 1/7] usb: phy: msm: Move mach dependent code to platform
 data
In-Reply-To: <20130724155505.GA26371@codeaurora.org>
References: <1372087664-26396-1-git-send-email-iivanov@mm-sol.com>
 <1372087664-26396-2-git-send-email-iivanov@mm-sol.com>
 <20130724155505.GA26371@codeaurora.org>
Message-ID: <1374829895.1956.39.camel@iivanov-dev.int.mm-sol.com>

On Wed, 2013-07-24 at 08:55 -0700, David Brown wrote:
> On Mon, Jun 24, 2013 at 06:27:38PM +0300, Ivan T. Ivanov wrote:
> >From: "Ivan T. Ivanov" <iivanov at mm-sol.com>
> >
> >This patch fix compilation error and is an intermediate step
> >before the addition of DeviceTree support for newer targets.
> >Fix suggested here: https://lkml.org/lkml/2013/6/19/381
> >
> >Cc: David Brown <davidb at codeaurora.org>
> >Cc: Daniel Walker <dwalker at fifo99.com>
> >Cc: Bryan Huntsman <bryanh at codeaurora.org>
> >Cc: Russell King <linux at arm.linux.org.uk>
> >Cc: Felipe Balbi <balbi at ti.com>
> >Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> >Cc: Stephen Boyd <sboyd at codeaurora.org>
> >Cc: linux-arm-kernel at lists.infradead.org
> >Cc: linux-kernel at vger.kernel.org
> >
> >Signed-off-by: Ivan T. Ivanov <iivanov at mm-sol.com>
> >---
> > arch/arm/mach-msm/board-msm7x30.c |   35 +++++++++++++++++++++++
> > arch/arm/mach-msm/board-qsd8x50.c |   34 +++++++++++++++++++++++
> > drivers/usb/phy/phy-msm-usb.c     |   55 ++++++++++---------------------------
> > include/linux/usb/msm_hsusb.h     |    2 ++
> > 4 files changed, 85 insertions(+), 41 deletions(-)
> 
> Acked-by: David Brown <davidb at codeaurora.org>
> 

Thank you David, but I am afraid that I have screwup this patch. It
doesn't build fine. I will send second version.
Sorry. Ivan



From josephl at nvidia.com  Fri Jul 26 05:15:03 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 26 Jul 2013 17:15:03 +0800
Subject: [PATCH 1/8] ARM: tegra: add common resume handling code for LP1
 resuming
In-Reply-To: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
Message-ID: <1374830110-30685-2-git-send-email-josephl@nvidia.com>

The common LP1 resuming procedures of LP1 on Tegra was checking the LP1
mask first. The LP1 mask indicated that the Tegra device was in LP1 then
we need to resume the Tegra from the LP1 reset handler.

And the LP1 was putting the SDRAM to self-refresh mode, the SDRAM wasn't
accessible when resuming from LP1. We need to copy the LP1 reset handler
to IRAM before suspending. That's why you can see the address of LP1
reset handler was located in IRAM.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/mach-tegra/reset-handler.S | 13 +++++++++++++
 arch/arm/mach-tegra/reset.c         |  2 ++
 arch/arm/mach-tegra/sleep.h         |  2 ++
 3 files changed, 17 insertions(+)

diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
index 34614bd..492b10f 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -182,6 +182,19 @@ after_errata:
 1:
 #endif
 
+	/* Waking up from LP1? */
+	ldr	r8, [r12, #RESET_DATA(MASK_LP1)]
+	tst	r8, r11				@ if in_lp1
+	beq	__is_not_lp1
+	cmp	r10, #0
+	bne	__die				@ only CPU0 can be here
+	ldr	lr, [r12, #RESET_DATA(STARTUP_LP1)]
+ THUMB(	add	lr, lr, #1 )			@ switch to Thumb mode
+	cmp	lr, #0
+	bleq	__die				@ no LP1 startup handler
+	bx	lr
+__is_not_lp1:
+
 	/* Waking up from LP2? */
 	ldr	r9, [r12, #RESET_DATA(MASK_LP2)]
 	tst	r9, r11				@ if in_lp2
diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c
index 1ac434e..fd0bbf8 100644
--- a/arch/arm/mach-tegra/reset.c
+++ b/arch/arm/mach-tegra/reset.c
@@ -81,6 +81,8 @@ void __init tegra_cpu_reset_handler_init(void)
 #endif
 
 #ifdef CONFIG_PM_SLEEP
+	__tegra_cpu_reset_handler_data[TEGRA_RESET_STARTUP_LP1] =
+		TEGRA_IRAM_CODE_AREA;
 	__tegra_cpu_reset_handler_data[TEGRA_RESET_STARTUP_LP2] =
 		virt_to_phys((void *)tegra_resume);
 #endif
diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
index e907e40..e7f8b6f 100644
--- a/arch/arm/mach-tegra/sleep.h
+++ b/arch/arm/mach-tegra/sleep.h
@@ -29,6 +29,8 @@
 					+ IO_APB_VIRT)
 #define TEGRA_PMC_VIRT	(TEGRA_PMC_BASE - IO_APB_PHYS + IO_APB_VIRT)
 
+#define TEGRA_IRAM_CODE_AREA	(TEGRA_IRAM_BASE + SZ_4K)
+
 /* PMC_SCRATCH37-39 and 41 are used for tegra_pen_lock and idle */
 #define PMC_SCRATCH37	0x130
 #define PMC_SCRATCH38	0x134
-- 
1.8.3.4



From josephl at nvidia.com  Fri Jul 26 05:15:02 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 26 Jul 2013 17:15:02 +0800
Subject: [PATCH 0/8] ARM: tegra: support LP1 suspend mode
Message-ID: <1374830110-30685-1-git-send-email-josephl@nvidia.com>

This series adds the support of LP1 suspend mode for Tegra.

Verified on Seaboard, Cardhu and Dalmore.
And tested with THUMB2_KERNEL as well.

P.S.
A known issue on Dalmore, the LP1 resume may take 10 ~ 15 seconds due to
the 792MHz BCT. It can't be reproduced on Seaboard or Cardhu. And the
root cause of this is about the default settings of EMC registers that
cause the DRAM can't leave self-refresh mode immediately. If you want
to test with quick LP1 resume on Dalmore, I can provide another HACK for
this.

Joseph Lo (8):
  ARM: tegra: add common resume handling code for LP1 resuming
  ARM: tegra: config the polarity of the request of sys clock
  clk: tegra114: add LP1 suspend/resume support
  ARM: tegra: add common LP1 suspend support
  ARM: tegra30: add LP1 suspend support
  ARM: tegra20: add LP1 suspend support
  ARM: tegra114: add LP1 suspend support
  ARM: dts: tegra: enable LP1 suspend mode

 arch/arm/boot/dts/tegra114-dalmore.dts     |   2 +-
 arch/arm/boot/dts/tegra20-colibri-512.dtsi |   2 +-
 arch/arm/boot/dts/tegra20-harmony.dts      |   2 +-
 arch/arm/boot/dts/tegra20-paz00.dts        |   2 +-
 arch/arm/boot/dts/tegra20-seaboard.dts     |   2 +-
 arch/arm/boot/dts/tegra20-tamonten.dtsi    |   2 +-
 arch/arm/boot/dts/tegra20-trimslice.dts    |   2 +-
 arch/arm/boot/dts/tegra20-ventana.dts      |   2 +-
 arch/arm/boot/dts/tegra20-whistler.dts     |   2 +-
 arch/arm/boot/dts/tegra30-beaver.dts       |   2 +-
 arch/arm/boot/dts/tegra30-cardhu.dtsi      |   2 +-
 arch/arm/mach-tegra/Makefile               |   3 +
 arch/arm/mach-tegra/iomap.h                |   6 +
 arch/arm/mach-tegra/pm-tegra20.c           |  37 ++
 arch/arm/mach-tegra/pm-tegra30.c           |  37 ++
 arch/arm/mach-tegra/pm.c                   | 121 +++++-
 arch/arm/mach-tegra/pm.h                   |  23 ++
 arch/arm/mach-tegra/pmc.c                  |  36 +-
 arch/arm/mach-tegra/pmc.h                  |   3 +
 arch/arm/mach-tegra/reset-handler.S        |  13 +
 arch/arm/mach-tegra/reset.c                |   2 +
 arch/arm/mach-tegra/reset.h                |   4 +
 arch/arm/mach-tegra/sleep-tegra20.S        | 300 ++++++++++++++
 arch/arm/mach-tegra/sleep-tegra30.S        | 615 +++++++++++++++++++++++++++++
 arch/arm/mach-tegra/sleep.S                |   8 +-
 arch/arm/mach-tegra/sleep.h                |  18 +
 drivers/clk/tegra/clk-tegra114.c           |  32 ++
 27 files changed, 1259 insertions(+), 21 deletions(-)
 create mode 100644 arch/arm/mach-tegra/pm-tegra20.c
 create mode 100644 arch/arm/mach-tegra/pm-tegra30.c

-- 
1.8.3.4



From josephl at nvidia.com  Fri Jul 26 05:15:04 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 26 Jul 2013 17:15:04 +0800
Subject: [PATCH 2/8] ARM: tegra: config the polarity of the request of sys
 clock
In-Reply-To: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
Message-ID: <1374830110-30685-3-git-send-email-josephl@nvidia.com>

When suspending to LP1 mode, the SYSCLK will be clock gated. And different
board may have different polarity of the request of SYSCLK, this patch
configure the polarity from the DT for the board.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/mach-tegra/pmc.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
index 8345fcd..018bc87 100644
--- a/arch/arm/mach-tegra/pmc.c
+++ b/arch/arm/mach-tegra/pmc.c
@@ -27,6 +27,8 @@
 #include "pmc.h"
 #include "sleep.h"
 
+#define TEGRA_POWER_SYSCLK_POLARITY	(1 << 10)  /* sys clk polarity */
+#define TEGRA_POWER_SYSCLK_OE		(1 << 11)  /* system clock enable */
 #define TEGRA_POWER_EFFECT_LP0		(1 << 14)  /* LP0 when CPU pwr gated */
 #define TEGRA_POWER_CPU_PWRREQ_POLARITY	(1 << 15)  /* CPU pwr req polarity */
 #define TEGRA_POWER_CPU_PWRREQ_OE	(1 << 16)  /* CPU pwr req enable */
@@ -238,6 +240,20 @@ void tegra_pmc_suspend_init(void)
 	reg = tegra_pmc_readl(PMC_CTRL);
 	reg |= TEGRA_POWER_CPU_PWRREQ_OE;
 	tegra_pmc_writel(reg, PMC_CTRL);
+
+	reg = tegra_pmc_readl(PMC_CTRL);
+
+	if (!pmc_pm_data.sysclkreq_high)
+		reg |= TEGRA_POWER_SYSCLK_POLARITY;
+	else
+		reg &= ~TEGRA_POWER_SYSCLK_POLARITY;
+
+	/* configure the output inverts while the request is tristated */
+	tegra_pmc_writel(reg, PMC_CTRL);
+
+	/* now enable the request */
+	reg |= TEGRA_POWER_SYSCLK_OE;
+	tegra_pmc_writel(reg, PMC_CTRL);
 }
 #endif
 
-- 
1.8.3.4



From josephl at nvidia.com  Fri Jul 26 05:15:05 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 26 Jul 2013 17:15:05 +0800
Subject: [PATCH 3/8] clk: tegra114: add LP1 suspend/resume support
In-Reply-To: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
Message-ID: <1374830110-30685-4-git-send-email-josephl@nvidia.com>

When the system suspends to LP1, the clock of the CPU would be switched to
CLK_M (12MHz Oscillator) during suspend/resume flow. The clock driver
needs to restore the clock of CPU after LP1 resume.

Cc: Mike Turquette <mturquette at linaro.org>
Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 drivers/clk/tegra/clk-tegra114.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index f74ed19..b0e745a 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -22,6 +22,7 @@
 #include <linux/of_address.h>
 #include <linux/delay.h>
 #include <linux/export.h>
+#include <linux/syscore_ops.h>
 #include <linux/clk/tegra.h>
 
 #include "clk.h"
@@ -2332,6 +2333,33 @@ void tegra114_clock_deassert_dfll_dvco_reset(void)
 }
 EXPORT_SYMBOL(tegra114_clock_deassert_dfll_dvco_reset);
 
+#ifdef CONFIG_PM_SLEEP
+static u32 clk_rst_suspend[2];
+
+static int tegra114_clk_suspend(void)
+{
+	u32 *ctx = clk_rst_suspend;
+
+	*ctx++ = readl_relaxed(clk_base + CCLKG_BURST_POLICY);
+	*ctx++ = readl_relaxed(clk_base + CCLKG_BURST_POLICY + 4);
+
+	return 0;
+}
+
+static void tegra114_clk_resume(void)
+{
+	u32 *ctx = clk_rst_suspend;
+
+	writel_relaxed(*ctx++, clk_base + CCLKG_BURST_POLICY);
+	writel_relaxed(*ctx++, clk_base + CCLKG_BURST_POLICY + 4);
+}
+
+static struct syscore_ops tegra114_clk_syscore_ops = {
+	.suspend = tegra114_clk_suspend,
+	.resume = tegra114_clk_resume,
+};
+#endif
+
 static void __init tegra114_clock_init(struct device_node *np)
 {
 	struct device_node *node;
@@ -2384,5 +2412,9 @@ static void __init tegra114_clock_init(struct device_node *np)
 	tegra_clk_apply_init_table = tegra114_clock_apply_init_table;
 
 	tegra_cpu_car_ops = &tegra114_cpu_car_ops;
+
+#ifdef CONFIG_PM_SLEEP
+	register_syscore_ops(&tegra114_clk_syscore_ops);
+#endif
 }
 CLK_OF_DECLARE(tegra114, "nvidia,tegra114-car", tegra114_clock_init);
-- 
1.8.3.4



From josephl at nvidia.com  Fri Jul 26 05:15:06 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 26 Jul 2013 17:15:06 +0800
Subject: [PATCH 4/8] ARM: tegra: add common LP1 suspend support
In-Reply-To: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
Message-ID: <1374830110-30685-5-git-send-email-josephl@nvidia.com>

The LP1 suspending mode on Tegra means CPU rail off, devices and PLLs are
clock gated and SDRAM in self-refresh mode. That means the low level LP1
suspending and resuming code couldn't be run on DRAM and the CPU must
switch to the always on clock domain (a.k.a. CLK_M 12MHz oscillator). And
the system clock (SCLK) would be switched to CLK_S, a 32KHz oscillator.
The LP1 low level handling code need to be moved to IRAM area first. And
marking the LP1 mask for indicating the Tegra device is in LP1. The CPU
power timer needs to be re-calculated based on 32KHz that was originally
based on PCLK.

When resuming from LP1, the LP1 reset handler will resume PLLs and then
put DRAM to normal mode. Then jumping to the "tegra_resume" that will
restore full context before back to kernel. The "tegra_resume" handler
was expected to be found in PMC_SCRATCH41 register.

This is common LP1 procedures for Tegra, so we do these jobs mainly in
this patch:
* moving LP1 low level handling code to IRAM
* marking LP1 mask
* copying the physical address of "tegra_resume" to PMC_SCRATCH41
* re-calculate the CPU power timer based on 32KHz

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/mach-tegra/pm.c    | 97 ++++++++++++++++++++++++++++++++++++++++++---
 arch/arm/mach-tegra/pm.h    |  7 ++++
 arch/arm/mach-tegra/pmc.c   | 20 +++++++++-
 arch/arm/mach-tegra/pmc.h   |  3 ++
 arch/arm/mach-tegra/reset.h |  4 ++
 5 files changed, 125 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index 5792872..45c9516 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -37,12 +37,18 @@
 #include "reset.h"
 #include "flowctrl.h"
 #include "fuse.h"
+#include "pm.h"
 #include "pmc.h"
 #include "sleep.h"
 
 #ifdef CONFIG_PM_SLEEP
 static DEFINE_SPINLOCK(tegra_lp2_lock);
+static void __iomem *iram_code = IO_ADDRESS(TEGRA_IRAM_CODE_AREA);
+static u32 iram_save_size;
+static void *iram_save_addr;
+struct tegra_lp1_iram *tegra_lp1_iram;
 void (*tegra_tear_down_cpu)(void);
+void (*tegra_sleep_core_finish)(unsigned long v2p);
 
 static void tegra_tear_down_cpu_init(void)
 {
@@ -174,14 +180,75 @@ enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
 				enum tegra_suspend_mode mode)
 {
 	/*
-	 * The Tegra devices only support suspending to LP2 currently.
+	 * The Tegra devices only support suspending to LP1 currently.
 	 */
-	if (mode > TEGRA_SUSPEND_LP2)
-		return TEGRA_SUSPEND_LP2;
+	if (mode > TEGRA_SUSPEND_LP1)
+		return TEGRA_SUSPEND_LP1;
 
 	return mode;
 }
 
+static int tegra_sleep_core(unsigned long v2p)
+{
+	setup_mm_for_reboot();
+	tegra_sleep_core_finish(v2p);
+
+	/* should never here */
+	BUG();
+
+	return 0;
+}
+
+/*
+ * tegra_lp1_iram_hook
+ *
+ * Hooking the address of LP1 reset vector and SDRAM self-refresh code in
+ * SDRAM. These codes not be copied to IRAM in this fuction. We need to
+ * copy these code to IRAM before LP0/LP1 suspend and restore the content
+ * of IRAM after resume.
+ */
+static bool tegra_lp1_iram_hook(void)
+{
+	if (!tegra_lp1_iram)
+		return false;
+
+	iram_save_size = tegra_lp1_iram->end_addr - tegra_lp1_iram->start_addr;
+	iram_save_addr = kmalloc(iram_save_size, GFP_KERNEL);
+	if (!iram_save_addr)
+		return false;
+
+	return true;
+}
+
+static bool tegra_sleep_core_init(void)
+{
+	if (!tegra_sleep_core_finish)
+		return false;
+
+	return true;
+}
+
+static void tegra_suspend_enter_lp1(void)
+{
+	tegra_pmc_suspend();
+
+	/* copy the reset vector & SDRAM shutdown code into IRAM */
+	memcpy(iram_save_addr, iram_code, iram_save_size);
+	memcpy(iram_code, tegra_lp1_iram->start_addr, iram_save_size);
+
+	*((u32 *)tegra_cpu_lp1_mask) = 1;
+}
+
+static void tegra_suspend_exit_lp1(void)
+{
+	tegra_pmc_resume();
+
+	/* restore IRAM */
+	memcpy(iram_code, iram_save_addr, iram_save_size);
+
+	*(u32 *)tegra_cpu_lp1_mask = 0;
+}
+
 static const char *lp_state[TEGRA_MAX_SUSPEND_MODE] = {
 	[TEGRA_SUSPEND_NONE] = "none",
 	[TEGRA_SUSPEND_LP2] = "LP2",
@@ -205,6 +272,9 @@ static int tegra_suspend_enter(suspend_state_t state)
 
 	suspend_cpu_complex();
 	switch (mode) {
+	case TEGRA_SUSPEND_LP1:
+		tegra_suspend_enter_lp1();
+		break;
 	case TEGRA_SUSPEND_LP2:
 		tegra_set_cpu_in_lp2();
 		break;
@@ -212,9 +282,15 @@ static int tegra_suspend_enter(suspend_state_t state)
 		break;
 	}
 
-	cpu_suspend(PHYS_OFFSET - PAGE_OFFSET, &tegra_sleep_cpu);
+	if (mode == TEGRA_SUSPEND_LP2)
+		cpu_suspend(PHYS_OFFSET - PAGE_OFFSET, &tegra_sleep_cpu);
+	else
+		cpu_suspend(PHYS_OFFSET - PAGE_OFFSET, &tegra_sleep_core);
 
 	switch (mode) {
+	case TEGRA_SUSPEND_LP1:
+		tegra_suspend_exit_lp1();
+		break;
 	case TEGRA_SUSPEND_LP2:
 		tegra_clear_cpu_in_lp2();
 		break;
@@ -235,12 +311,23 @@ static const struct platform_suspend_ops tegra_suspend_ops = {
 
 void __init tegra_init_suspend(void)
 {
-	if (tegra_pmc_get_suspend_mode() == TEGRA_SUSPEND_NONE)
+	enum tegra_suspend_mode mode = tegra_pmc_get_suspend_mode();
+
+	if (mode == TEGRA_SUSPEND_NONE)
 		return;
 
 	tegra_tear_down_cpu_init();
 	tegra_pmc_suspend_init();
 
+	if (mode >= TEGRA_SUSPEND_LP1) {
+		if (!tegra_lp1_iram_hook() || !tegra_sleep_core_init()) {
+			pr_err("%s: unable to allocate memory for SDRAM"
+			       "self-refresh -- LP0/LP1 unavailable\n",
+			       __func__);
+			tegra_pmc_set_suspend_mode(TEGRA_SUSPEND_LP2);
+		}
+	}
+
 	suspend_set_ops(&tegra_suspend_ops);
 }
 #endif
diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
index 94c4b9d..3cb9309 100644
--- a/arch/arm/mach-tegra/pm.h
+++ b/arch/arm/mach-tegra/pm.h
@@ -23,6 +23,13 @@
 
 #include "pmc.h"
 
+struct tegra_lp1_iram {
+	void	*start_addr;
+	void	*end_addr;
+};
+extern struct tegra_lp1_iram *tegra_lp1_iram;
+extern void (*tegra_sleep_core_finish)(unsigned long v2p);
+
 extern unsigned long l2x0_saved_regs_addr;
 
 void save_cpu_arch_register(void);
diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
index 018bc87..dff239f 100644
--- a/arch/arm/mach-tegra/pmc.c
+++ b/arch/arm/mach-tegra/pmc.c
@@ -196,10 +196,28 @@ enum tegra_suspend_mode tegra_pmc_get_suspend_mode(void)
 	return pmc_pm_data.suspend_mode;
 }
 
+void tegra_pmc_set_suspend_mode(enum tegra_suspend_mode mode)
+{
+	if (mode < TEGRA_SUSPEND_NONE || mode >= TEGRA_MAX_SUSPEND_MODE)
+		return;
+
+	pmc_pm_data.suspend_mode = mode;
+}
+
+void tegra_pmc_suspend(void)
+{
+	tegra_pmc_writel(virt_to_phys(tegra_resume), PMC_SCRATCH41);
+}
+
+void tegra_pmc_resume(void)
+{
+	tegra_pmc_writel(0x0, PMC_SCRATCH41);
+}
+
 void tegra_pmc_pm_set(enum tegra_suspend_mode mode)
 {
 	u32 reg, csr_reg;
-	unsigned long rate = 0;
+	unsigned long rate = 32768;
 
 	reg = tegra_pmc_readl(PMC_CTRL);
 	reg |= TEGRA_POWER_CPU_PWRREQ_OE;
diff --git a/arch/arm/mach-tegra/pmc.h b/arch/arm/mach-tegra/pmc.h
index e1c2df2..549f8c7 100644
--- a/arch/arm/mach-tegra/pmc.h
+++ b/arch/arm/mach-tegra/pmc.h
@@ -28,6 +28,9 @@ enum tegra_suspend_mode {
 
 #ifdef CONFIG_PM_SLEEP
 enum tegra_suspend_mode tegra_pmc_get_suspend_mode(void);
+void tegra_pmc_set_suspend_mode(enum tegra_suspend_mode mode);
+void tegra_pmc_suspend(void);
+void tegra_pmc_resume(void);
 void tegra_pmc_pm_set(enum tegra_suspend_mode mode);
 void tegra_pmc_suspend_init(void);
 #endif
diff --git a/arch/arm/mach-tegra/reset.h b/arch/arm/mach-tegra/reset.h
index c90d8e9..76a9343 100644
--- a/arch/arm/mach-tegra/reset.h
+++ b/arch/arm/mach-tegra/reset.h
@@ -39,6 +39,10 @@ void __tegra_cpu_reset_handler_end(void);
 void tegra_secondary_startup(void);
 
 #ifdef CONFIG_PM_SLEEP
+#define tegra_cpu_lp1_mask \
+	(IO_ADDRESS(TEGRA_IRAM_BASE + TEGRA_IRAM_RESET_HANDLER_OFFSET + \
+	((u32)&__tegra_cpu_reset_handler_data[TEGRA_RESET_MASK_LP1] - \
+	 (u32)__tegra_cpu_reset_handler_start)))
 #define tegra_cpu_lp2_mask \
 	(IO_ADDRESS(TEGRA_IRAM_BASE + TEGRA_IRAM_RESET_HANDLER_OFFSET + \
 	((u32)&__tegra_cpu_reset_handler_data[TEGRA_RESET_MASK_LP2] - \
-- 
1.8.3.4



From josephl at nvidia.com  Fri Jul 26 05:15:08 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 26 Jul 2013 17:15:08 +0800
Subject: [PATCH 6/8] ARM: tegra20: add LP1 suspend support
In-Reply-To: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
Message-ID: <1374830110-30685-7-git-send-email-josephl@nvidia.com>

The LP1 suspend mode will power off the CPU, clock gated the PLLs and put
SDRAM to self-refresh mode. Any interrupt can wake up device from LP1. The
sequence when LP1 suspending:

* tunning off L1 data cache and the MMU
* putting SDRAM into self-refresh
* storing some EMC registers and SCLK burst policy
* switching CPU to CLK_M (12MHz OSC)
* switching SCLK to CLK_S (32KHz OSC)
* tunning off PLLM, PLLP and PLLC
* shutting off the CPU rail

The sequence of LP1 resuming:

* re-enabling PLLM, PLLP, and PLLC
* restoring some EMC registers and SCLK burst policy
* setting up CCLK burst policy to PLLP
* resuming SDRAM to normal mode
* jumping to the "tegra_resume" from PMC_SCRATCH41

Due to the SDRAM will be put into self-refresh mode, the low level
procedures of LP1 suspending and resuming should be copied to
TEGRA_IRAM_CODE_AREA (TEGRA_IRAM_BASE + SZ_4K) when suspending. Before
restoring the CPU context when resuming, the SDRAM needs to be switched
back to normal mode. And the PLLs need to be re-enabled, SCLK burst policy
be restored, CCLK burst policy be set in PLLP. Then jumping to
"tegra_resume" that was expected to be stored in PMC_SCRATCH41 to restore
CPU context and back to kernel.

Based on the work by:
Colin Cross <ccross at android.com>
Gary King <gking at nvidia.com>

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/mach-tegra/Makefile        |   1 +
 arch/arm/mach-tegra/pm-tegra20.c    |  37 +++++
 arch/arm/mach-tegra/pm.c            |   6 +
 arch/arm/mach-tegra/pm.h            |   8 +
 arch/arm/mach-tegra/sleep-tegra20.S | 300 ++++++++++++++++++++++++++++++++++++
 5 files changed, 352 insertions(+)
 create mode 100644 arch/arm/mach-tegra/pm-tegra20.c

diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index d341980..a3fe22d 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_CPU_IDLE)			+= cpuidle.o
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= tegra20_speedo.o
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= tegra2_emc.o
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= sleep-tegra20.o
+obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= pm-tegra20.o
 ifeq ($(CONFIG_CPU_IDLE),y)
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= cpuidle-tegra20.o
 endif
diff --git a/arch/arm/mach-tegra/pm-tegra20.c b/arch/arm/mach-tegra/pm-tegra20.c
new file mode 100644
index 0000000..47bc40b
--- /dev/null
+++ b/arch/arm/mach-tegra/pm-tegra20.c
@@ -0,0 +1,37 @@
+/*
+ * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+#include <linux/kernel.h>
+
+#include "pm.h"
+
+#ifdef CONFIG_PM_SLEEP
+static struct tegra_lp1_iram tegra20_lp1_iram;
+extern u32 tegra20_iram_start, tegra20_iram_end;
+extern void tegra20_sleep_core_finish(unsigned long);
+
+void tegra20_lp1_iram_hook(void)
+{
+	tegra20_lp1_iram.start_addr = &tegra20_iram_start;
+	tegra20_lp1_iram.end_addr = &tegra20_iram_end;
+
+	tegra_lp1_iram = &tegra20_lp1_iram;
+}
+
+void tegra20_sleep_core_init(void)
+{
+	tegra_sleep_core_finish = tegra20_sleep_core_finish;
+}
+#endif
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index 77dbb22..5ae7ee5 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -210,6 +210,9 @@ static int tegra_sleep_core(unsigned long v2p)
 static bool tegra_lp1_iram_hook(void)
 {
 	switch (tegra_chip_id) {
+	case TEGRA20:
+		tegra20_lp1_iram_hook();
+		break;
 	case TEGRA30:
 		tegra30_lp1_iram_hook();
 		break;
@@ -231,6 +234,9 @@ static bool tegra_lp1_iram_hook(void)
 static bool tegra_sleep_core_init(void)
 {
 	switch (tegra_chip_id) {
+	case TEGRA20:
+		tegra20_sleep_core_init();
+		break;
 	case TEGRA30:
 		tegra30_sleep_core_init();
 		break;
diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
index 32d2898..7aef651 100644
--- a/arch/arm/mach-tegra/pm.h
+++ b/arch/arm/mach-tegra/pm.h
@@ -30,6 +30,14 @@ struct tegra_lp1_iram {
 extern struct tegra_lp1_iram *tegra_lp1_iram;
 extern void (*tegra_sleep_core_finish)(unsigned long v2p);
 
+#ifdef CONFIG_ARCH_TEGRA_2x_SOC
+void tegra20_lp1_iram_hook(void);
+void tegra20_sleep_core_init(void);
+#else
+static inline void tegra20_lp1_iram_hook(void) {}
+static inline void void tegra20_sleep_core_init(void) {}
+#endif
+
 #ifdef CONFIG_ARCH_TEGRA_3x_SOC
 void tegra30_lp1_iram_hook(void);
 void tegra30_sleep_core_init(void);
diff --git a/arch/arm/mach-tegra/sleep-tegra20.S b/arch/arm/mach-tegra/sleep-tegra20.S
index f87721d..8972a8e 100644
--- a/arch/arm/mach-tegra/sleep-tegra20.S
+++ b/arch/arm/mach-tegra/sleep-tegra20.S
@@ -23,10 +23,49 @@
 #include <asm/assembler.h>
 #include <asm/proc-fns.h>
 #include <asm/cp15.h>
+#include <asm/cache.h>
 
 #include "sleep.h"
 #include "flowctrl.h"
 
+#define EMC_CFG				0xc
+#define EMC_ADR_CFG			0x10
+#define EMC_REFRESH			0x70
+#define EMC_NOP				0xdc
+#define EMC_SELF_REF			0xe0
+#define EMC_REQ_CTRL			0x2b0
+#define EMC_EMC_STATUS			0x2b4
+
+#define CLK_RESET_CCLK_BURST		0x20
+#define CLK_RESET_CCLK_DIVIDER		0x24
+#define CLK_RESET_SCLK_BURST		0x28
+#define CLK_RESET_SCLK_DIVIDER		0x2c
+#define CLK_RESET_PLLC_BASE		0x80
+#define CLK_RESET_PLLM_BASE		0x90
+#define CLK_RESET_PLLP_BASE		0xa0
+
+#define APB_MISC_XM2CFGCPADCTRL		0x8c8
+#define APB_MISC_XM2CFGDPADCTRL		0x8cc
+#define APB_MISC_XM2CLKCFGPADCTRL	0x8d0
+#define APB_MISC_XM2COMPPADCTRL		0x8d4
+#define APB_MISC_XM2VTTGENPADCTRL	0x8d8
+#define APB_MISC_XM2CFGCPADCTRL2	0x8e4
+#define APB_MISC_XM2CFGDPADCTRL2	0x8e8
+
+.macro pll_enable, rd, r_car_base, pll_base
+	ldr	\rd, [\r_car_base, #\pll_base]
+	tst	\rd, #(1 << 30)
+	orreq	\rd, \rd, #(1 << 30)
+	streq	\rd, [\r_car_base, #\pll_base]
+.endm
+
+.macro emc_device_mask, rd, base
+	ldr	\rd, [\base, #EMC_ADR_CFG]
+	tst	\rd, #(0x3 << 24)
+	moveq	\rd, #(0x1 << 8)		@ just 1 device
+	movne	\rd, #(0x3 << 8)		@ 2 devices
+.endm
+
 #if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_PM_SLEEP)
 /*
  * tegra20_hotplug_shutdown(void)
@@ -181,6 +220,28 @@ ENTRY(tegra20_cpu_is_resettable_soon)
 ENDPROC(tegra20_cpu_is_resettable_soon)
 
 /*
+ * tegra20_sleep_core_finish(unsigned long v2p)
+ *
+ * Enters suspend in LP0 or LP1 by turning off the mmu and jumping to
+ * tegra20_tear_down_core in IRAM
+ */
+ENTRY(tegra20_sleep_core_finish)
+	/* Flush, disable the L1 data cache and exit SMP */
+	bl	tegra_disable_clean_inv_dcache
+
+	mov32	r3, tegra_shut_off_mmu
+	add	r3, r3, r0
+
+	mov32	r0, tegra20_tear_down_core
+	mov32	r1, tegra20_iram_start
+	sub	r0, r0, r1
+	mov32	r1, TEGRA_IRAM_CODE_AREA
+	add	r0, r0, r1
+
+	mov	pc, r3
+ENDPROC(tegra20_sleep_core_finish)
+
+/*
  * tegra20_sleep_cpu_secondary_finish(unsigned long v2p)
  *
  * Enters WFI on secondary CPU by exiting coherency.
@@ -251,6 +312,150 @@ ENTRY(tegra20_tear_down_cpu)
 	b	tegra20_enter_sleep
 ENDPROC(tegra20_tear_down_cpu)
 
+/* START OF ROUTINES COPIED TO IRAM */
+	.align L1_CACHE_SHIFT
+	.globl tegra20_iram_start
+tegra20_iram_start:
+
+/*
+ * tegra20_lp1_reset
+ *
+ * reset vector for LP1 restore; copied into IRAM during suspend.
+ * Brings the system back up to a safe staring point (SDRAM out of
+ * self-refresh, PLLC, PLLM and PLLP reenabled, CPU running on PLLP,
+ * system clock running on the same PLL that it suspended at), and
+ * jumps to tegra_resume to restore virtual addressing and PLLX.
+ * The physical address of tegra_resume expected to be stored in
+ * PMC_SCRATCH41.
+ *
+ * NOTE: THIS *MUST* BE RELOCATED TO TEGRA_IRAM_CODE_AREA AND MUST BE FIRST.
+ */
+ENTRY(tegra20_lp1_reset)
+	/*
+	 * The CPU and system bus are running at 32KHz and executing from
+	 * IRAM when this code is executed; immediately switch to CLKM and
+	 * enable PLLM, PLLP, PLLC.
+	 */
+	mov32	r0, TEGRA_CLK_RESET_BASE
+
+	mov	r1, #(1 << 28)
+	str	r1, [r0, #CLK_RESET_SCLK_BURST]
+	str	r1, [r0, #CLK_RESET_CCLK_BURST]
+	mov	r1, #0
+	str	r1, [r0, #CLK_RESET_CCLK_DIVIDER]
+	str	r1, [r0, #CLK_RESET_SCLK_DIVIDER]
+
+	pll_enable r1, r0, CLK_RESET_PLLM_BASE
+	pll_enable r1, r0, CLK_RESET_PLLP_BASE
+	pll_enable r1, r0, CLK_RESET_PLLC_BASE
+
+	adr	r2, tegra20_sdram_pad_address
+	adr	r4, tegra20_sdram_pad_save
+	mov	r5, #0
+
+	ldr	r6, tegra20_sdram_pad_size
+padload:
+	ldr	r7, [r2, r5]		@ r7 is the addr in the pad_address
+
+	ldr	r1, [r4, r5]
+	str	r1, [r7]		@ restore the value in pad_save
+
+	add	r5, r5, #4
+	cmp	r6, r5
+	bne	padload
+
+padload_done:
+	/* 255uS delay for PLL stabilization */
+	mov32	r7, TEGRA_TMRUS_BASE
+	wait_for_us r1, r7, r9
+	add	r1, r1, #0xfe
+	wait_until r1, r7, r9
+
+	adr	r4, tegra20_sclk_save
+	ldr	r4, [r4]
+	str	r4, [r0, #CLK_RESET_SCLK_BURST]
+	mov32	r4, ((1 << 28) | (4))	@ burst policy is PLLP
+	str	r4, [r0, #CLK_RESET_CCLK_BURST]
+
+	mov32	r0, TEGRA_EMC_BASE
+	ldr	r1, [r0, #EMC_CFG]
+	bic	r1, r1, #(1 << 31)	@ disable DRAM_CLK_STOP
+	str	r1, [r0, #EMC_CFG]
+
+	mov	r1, #0
+	str	r1, [r0, #EMC_SELF_REF]	@ take DRAM out of self refresh
+	mov	r1, #1
+	str	r1, [r0, #EMC_NOP]
+	str	r1, [r0, #EMC_NOP]
+	str	r1, [r0, #EMC_REFRESH]
+
+	emc_device_mask r1, r0
+
+exit_selfrefresh_loop:
+	ldr	r2, [r0, #EMC_EMC_STATUS]
+	ands	r2, r2, r1
+	bne	exit_selfrefresh_loop
+
+	mov	r1, #0			@ unstall all transactions
+	str	r1, [r0, #EMC_REQ_CTRL]
+
+	mov32	r0, TEGRA_PMC_BASE
+	ldr	r0, [r0, #PMC_SCRATCH41]
+	mov	pc, r0			@ jump to tegra_resume
+ENDPROC(tegra20_lp1_reset)
+
+/*
+ * tegra20_tear_down_core
+ *
+ * copied into and executed from IRAM
+ * puts memory in self-refresh for LP0 and LP1
+ */
+tegra20_tear_down_core:
+	bl	tegra20_sdram_self_refresh
+	bl	tegra20_switch_cpu_to_clk32k
+	b	tegra20_enter_sleep
+
+/*
+ * tegra20_switch_cpu_to_clk32k
+ *
+ * In LP0 and LP1 all PLLs will be turned off. Switch the CPU and system clock
+ * to the 32KHz clock.
+ */
+tegra20_switch_cpu_to_clk32k:
+	/*
+	 * start by jumping to CLKM to safely disable PLLs, then jump to
+	 * CLKS.
+	 */
+	mov	r0, #(1 << 28)
+	str	r0, [r5, #CLK_RESET_SCLK_BURST]
+	str	r0, [r5, #CLK_RESET_CCLK_BURST]
+	mov	r0, #0
+	str	r0, [r5, #CLK_RESET_CCLK_DIVIDER]
+	str	r0, [r5, #CLK_RESET_SCLK_DIVIDER]
+
+	/* 2uS delay delay between changing SCLK and disabling PLLs */
+	mov32	r7, TEGRA_TMRUS_BASE
+	wait_for_us r1, r7, r9
+	add	r1, r1, #2
+	wait_until r1, r7, r9
+
+	/* switch to CLKS */
+	mov	r0, #0	/* brust policy = 32KHz */
+	str	r0, [r5, #CLK_RESET_SCLK_BURST]
+
+	/* disable PLLM, PLLP and PLLC */
+	ldr	r0, [r5, #CLK_RESET_PLLM_BASE]
+	bic	r0, r0, #(1 << 30)
+	str	r0, [r5, #CLK_RESET_PLLM_BASE]
+	ldr	r0, [r5, #CLK_RESET_PLLP_BASE]
+	bic	r0, r0, #(1 << 30)
+	str	r0, [r5, #CLK_RESET_PLLP_BASE]
+	ldr	r0, [r5, #CLK_RESET_PLLC_BASE]
+	bic	r0, r0, #(1 << 30)
+	str	r0, [r5, #CLK_RESET_PLLC_BASE]
+
+	mov	pc, lr
+
 /*
  * tegra20_enter_sleep
  *
@@ -275,4 +480,99 @@ halted:
 	isb
 	b	halted
 
+/*
+ * tegra20_sdram_self_refresh
+ *
+ * called with MMU off and caches disabled
+ * puts sdram in self refresh
+ * must be executed from IRAM
+ */
+tegra20_sdram_self_refresh:
+	mov32	r1, TEGRA_EMC_BASE	@ r1 reserved for emc base addr
+
+	mov	r2, #3
+	str	r2, [r1, #EMC_REQ_CTRL]	@ stall incoming DRAM requests
+
+emcidle:
+	ldr	r2, [r1, #EMC_EMC_STATUS]
+	tst	r2, #4
+	beq	emcidle
+
+	mov	r2, #1
+	str	r2, [r1, #EMC_SELF_REF]
+
+	emc_device_mask r2, r1
+
+emcself:
+	ldr	r3, [r1, #EMC_EMC_STATUS]
+	and	r3, r3, r2
+	cmp	r3, r2
+	bne	emcself			@ loop until DDR in self-refresh
+
+	adr	r2, tegra20_sdram_pad_address
+	adr	r3, tegra20_sdram_pad_safe
+	adr	r4, tegra20_sdram_pad_save
+	mov	r5, #0
+
+	ldr	r6, tegra20_sdram_pad_size
+padsave:
+	ldr	r0, [r2, r5]		@ r0 is the addr in the pad_address
+
+	ldr	r1, [r0]
+	str	r1, [r4, r5]		@ save the content of the addr
+
+	ldr	r1, [r3, r5]
+	str	r1, [r0]		@ set the save val to the addr
+
+	add	r5, r5, #4
+	cmp	r6, r5
+	bne	padsave
+padsave_done:
+
+	mov32	r5, TEGRA_CLK_RESET_BASE
+	ldr	r0, [r5, #CLK_RESET_SCLK_BURST]
+	adr	r2, tegra20_sclk_save
+	str	r0, [r2]
+	dsb
+	mov	pc, lr
+
+tegra20_sdram_pad_address:
+	.word	TEGRA_APB_MISC_BASE + APB_MISC_XM2CFGCPADCTRL
+	.word	TEGRA_APB_MISC_BASE + APB_MISC_XM2CFGDPADCTRL
+	.word	TEGRA_APB_MISC_BASE + APB_MISC_XM2CLKCFGPADCTRL
+	.word	TEGRA_APB_MISC_BASE + APB_MISC_XM2COMPPADCTRL
+	.word	TEGRA_APB_MISC_BASE + APB_MISC_XM2VTTGENPADCTRL
+	.word	TEGRA_APB_MISC_BASE + APB_MISC_XM2CFGCPADCTRL2
+	.word	TEGRA_APB_MISC_BASE + APB_MISC_XM2CFGDPADCTRL2
+
+tegra20_sdram_pad_size:
+	.word	tegra20_sdram_pad_size - tegra20_sdram_pad_address
+
+tegra20_sdram_pad_safe:
+	.word	0x8
+	.word	0x8
+	.word	0x0
+	.word	0x8
+	.word	0x5500
+	.word	0x08080040
+	.word	0x0
+
+tegra20_sclk_save:
+	.word	0x0
+
+tegra20_sdram_pad_save:
+	.word	0
+	.word	0
+	.word	0
+	.word	0
+	.word	0
+	.word	0
+	.word	0
+
+	.ltorg
+/* dummy symbol for end of IRAM */
+	.align L1_CACHE_SHIFT
+	.globl tegra20_iram_end
+tegra20_iram_end:
+	b	.
 #endif
-- 
1.8.3.4



From josephl at nvidia.com  Fri Jul 26 05:15:10 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 26 Jul 2013 17:15:10 +0800
Subject: [PATCH 8/8] ARM: dts: tegra: enable LP1 suspend mode
In-Reply-To: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
Message-ID: <1374830110-30685-9-git-send-email-josephl@nvidia.com>

Enabling the LP1 suspend mode for Tegra devices.

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/boot/dts/tegra114-dalmore.dts     | 2 +-
 arch/arm/boot/dts/tegra20-colibri-512.dtsi | 2 +-
 arch/arm/boot/dts/tegra20-harmony.dts      | 2 +-
 arch/arm/boot/dts/tegra20-paz00.dts        | 2 +-
 arch/arm/boot/dts/tegra20-seaboard.dts     | 2 +-
 arch/arm/boot/dts/tegra20-tamonten.dtsi    | 2 +-
 arch/arm/boot/dts/tegra20-trimslice.dts    | 2 +-
 arch/arm/boot/dts/tegra20-ventana.dts      | 2 +-
 arch/arm/boot/dts/tegra20-whistler.dts     | 2 +-
 arch/arm/boot/dts/tegra30-beaver.dts       | 2 +-
 arch/arm/boot/dts/tegra30-cardhu.dtsi      | 2 +-
 11 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index aeda147..a2a1b5f 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -1024,7 +1024,7 @@
 
 	pmc {
 		nvidia,invert-interrupt;
-		nvidia,suspend-mode = <2>;
+		nvidia,suspend-mode = <1>;
 		nvidia,cpu-pwr-good-time = <500>;
 		nvidia,cpu-pwr-off-time = <300>;
 		nvidia,core-pwr-good-time = <641 3845>;
diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
index 2fcb3f2..06c5fa0 100644
--- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
@@ -363,7 +363,7 @@
 	};
 
 	pmc {
-		nvidia,suspend-mode = <2>;
+		nvidia,suspend-mode = <1>;
 		nvidia,cpu-pwr-good-time = <5000>;
 		nvidia,cpu-pwr-off-time = <5000>;
 		nvidia,core-pwr-good-time = <3845 3845>;
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index d9f89cd..d44cf90 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -417,7 +417,7 @@
 
 	pmc {
 		nvidia,invert-interrupt;
-		nvidia,suspend-mode = <2>;
+		nvidia,suspend-mode = <1>;
 		nvidia,cpu-pwr-good-time = <5000>;
 		nvidia,cpu-pwr-off-time = <5000>;
 		nvidia,core-pwr-good-time = <3845 3845>;
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index cfd1276..8d71fc9 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -417,7 +417,7 @@
 
 	pmc {
 		nvidia,invert-interrupt;
-		nvidia,suspend-mode = <2>;
+		nvidia,suspend-mode = <1>;
 		nvidia,cpu-pwr-good-time = <2000>;
 		nvidia,cpu-pwr-off-time = <0>;
 		nvidia,core-pwr-good-time = <3845 3845>;
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index 365760b..152dfb7 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -518,7 +518,7 @@
 
 	pmc {
 		nvidia,invert-interrupt;
-		nvidia,suspend-mode = <2>;
+		nvidia,suspend-mode = <1>;
 		nvidia,cpu-pwr-good-time = <5000>;
 		nvidia,cpu-pwr-off-time = <5000>;
 		nvidia,core-pwr-good-time = <3845 3845>;
diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index c54faae..f00febe 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -459,7 +459,7 @@
 
 	pmc {
 		nvidia,invert-interrupt;
-		nvidia,suspend-mode = <2>;
+		nvidia,suspend-mode = <1>;
 		nvidia,cpu-pwr-good-time = <5000>;
 		nvidia,cpu-pwr-off-time = <5000>;
 		nvidia,core-pwr-good-time = <3845 3845>;
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index ed4b901..3e4eefb 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -302,7 +302,7 @@
 	};
 
 	pmc {
-		nvidia,suspend-mode = <2>;
+		nvidia,suspend-mode = <1>;
 		nvidia,cpu-pwr-good-time = <5000>;
 		nvidia,cpu-pwr-off-time = <5000>;
 		nvidia,core-pwr-good-time = <3845 3845>;
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 7f8c28d..aab872c 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -494,7 +494,7 @@
 
 	pmc {
 		nvidia,invert-interrupt;
-		nvidia,suspend-mode = <2>;
+		nvidia,suspend-mode = <1>;
 		nvidia,cpu-pwr-good-time = <2000>;
 		nvidia,cpu-pwr-off-time = <100>;
 		nvidia,core-pwr-good-time = <3845 3845>;
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index ab67c94..3899cae 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -497,7 +497,7 @@
 
 	pmc {
 		nvidia,invert-interrupt;
-		nvidia,suspend-mode = <2>;
+		nvidia,suspend-mode = <1>;
 		nvidia,cpu-pwr-good-time = <2000>;
 		nvidia,cpu-pwr-off-time = <1000>;
 		nvidia,core-pwr-good-time = <0 3845>;
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index 87c5f7b..7378927 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -262,7 +262,7 @@
 	pmc {
 		status = "okay";
 		nvidia,invert-interrupt;
-		nvidia,suspend-mode = <2>;
+		nvidia,suspend-mode = <1>;
 		nvidia,cpu-pwr-good-time = <2000>;
 		nvidia,cpu-pwr-off-time = <200>;
 		nvidia,core-pwr-good-time = <3845 3845>;
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index c011b67..d78c90c 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -314,7 +314,7 @@
 	pmc {
 		status = "okay";
 		nvidia,invert-interrupt;
-		nvidia,suspend-mode = <2>;
+		nvidia,suspend-mode = <1>;
 		nvidia,cpu-pwr-good-time = <2000>;
 		nvidia,cpu-pwr-off-time = <200>;
 		nvidia,core-pwr-good-time = <3845 3845>;
-- 
1.8.3.4



From josephl at nvidia.com  Fri Jul 26 05:15:07 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 26 Jul 2013 17:15:07 +0800
Subject: [PATCH 5/8] ARM: tegra30: add LP1 suspend support
In-Reply-To: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
Message-ID: <1374830110-30685-6-git-send-email-josephl@nvidia.com>

The LP1 suspend mode will power off the CPU, clock gated the PLLs and put
SDRAM to self-refresh mode. Any interrupt can wake up device from LP1. The
sequence when LP1 suspending:

* tunning off L1 data cache and the MMU
* storing some EMC registers, DPD (deep power down) status, clk source of
  mselect and SCLK burst policy
* putting SDRAM into self-refresh
* switching CPU to CLK_M (12MHz OSC)
* tunning off PLLM, PLLP, PLLA, PLLC and PLLX
* switching SCLK to CLK_S (32KHz OSC)
* shutting off the CPU rail

The sequence of LP1 resuming:

* re-enabling PLLM, PLLP, PLLA, PLLC and PLLX
* restoring the clk source of mselect and SCLK burst policy
* setting up CCLK burst policy to PLLX
* restoring DPD status and some EMC registers
* resuming SDRAM to normal mode
* jumping to the "tegra_resume" from PMC_SCRATCH41

Due to the SDRAM will be put into self-refresh mode, the low level
procedures of LP1 suspending and resuming should be copied to
TEGRA_IRAM_CODE_AREA (TEGRA_IRAM_BASE + SZ_4K) when suspending. Before
restoring the CPU context when resuming, the SDRAM needs to be switched
back to normal mode. And the PLLs need to be re-enabled, SCLK burst policy
be restored, CCLK burst policy be set in PLLX. Then jumping to
"tegra_resume" that was expected to be stored in PMC_SCRATCH41 to restore
CPU context and back to kernel.

Based on the work by: Scott Williams <scwilliams at nvidia.com>

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/mach-tegra/Makefile        |   1 +
 arch/arm/mach-tegra/pm-tegra30.c    |  37 +++
 arch/arm/mach-tegra/pm.c            |  16 ++
 arch/arm/mach-tegra/pm.h            |   8 +
 arch/arm/mach-tegra/sleep-tegra30.S | 491 ++++++++++++++++++++++++++++++++++++
 arch/arm/mach-tegra/sleep.S         |   8 +-
 arch/arm/mach-tegra/sleep.h         |  16 ++
 7 files changed, 573 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/mach-tegra/pm-tegra30.c

diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 98b184e..d341980 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_ARCH_TEGRA_2x_SOC)		+= cpuidle-tegra20.o
 endif
 obj-$(CONFIG_ARCH_TEGRA_3x_SOC)		+= tegra30_speedo.o
 obj-$(CONFIG_ARCH_TEGRA_3x_SOC)		+= sleep-tegra30.o
+obj-$(CONFIG_ARCH_TEGRA_3x_SOC)		+= pm-tegra30.o
 ifeq ($(CONFIG_CPU_IDLE),y)
 obj-$(CONFIG_ARCH_TEGRA_3x_SOC)		+= cpuidle-tegra30.o
 endif
diff --git a/arch/arm/mach-tegra/pm-tegra30.c b/arch/arm/mach-tegra/pm-tegra30.c
new file mode 100644
index 0000000..6786955
--- /dev/null
+++ b/arch/arm/mach-tegra/pm-tegra30.c
@@ -0,0 +1,37 @@
+/*
+ * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+#include <linux/kernel.h>
+
+#include "pm.h"
+
+#ifdef CONFIG_PM_SLEEP
+static struct tegra_lp1_iram tegra30_lp1_iram;
+extern u32 tegra30_iram_start, tegra30_iram_end;
+extern void tegra30_sleep_core_finish(unsigned long);
+
+void tegra30_lp1_iram_hook(void)
+{
+	tegra30_lp1_iram.start_addr = &tegra30_iram_start;
+	tegra30_lp1_iram.end_addr = &tegra30_iram_end;
+
+	tegra_lp1_iram = &tegra30_lp1_iram;
+}
+
+void tegra30_sleep_core_init(void)
+{
+	tegra_sleep_core_finish = tegra30_sleep_core_finish;
+}
+#endif
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index 45c9516..77dbb22 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -209,6 +209,14 @@ static int tegra_sleep_core(unsigned long v2p)
  */
 static bool tegra_lp1_iram_hook(void)
 {
+	switch (tegra_chip_id) {
+	case TEGRA30:
+		tegra30_lp1_iram_hook();
+		break;
+	default:
+		break;
+	}
+
 	if (!tegra_lp1_iram)
 		return false;
 
@@ -222,6 +230,14 @@ static bool tegra_lp1_iram_hook(void)
 
 static bool tegra_sleep_core_init(void)
 {
+	switch (tegra_chip_id) {
+	case TEGRA30:
+		tegra30_sleep_core_init();
+		break;
+	default:
+		break;
+	}
+
 	if (!tegra_sleep_core_finish)
 		return false;
 
diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
index 3cb9309..32d2898 100644
--- a/arch/arm/mach-tegra/pm.h
+++ b/arch/arm/mach-tegra/pm.h
@@ -30,6 +30,14 @@ struct tegra_lp1_iram {
 extern struct tegra_lp1_iram *tegra_lp1_iram;
 extern void (*tegra_sleep_core_finish)(unsigned long v2p);
 
+#ifdef CONFIG_ARCH_TEGRA_3x_SOC
+void tegra30_lp1_iram_hook(void);
+void tegra30_sleep_core_init(void);
+#else
+static inline void tegra30_lp1_iram_hook(void) {}
+static inline void void tegra30_sleep_core_init(void) {}
+#endif
+
 extern unsigned long l2x0_saved_regs_addr;
 
 void save_cpu_arch_register(void);
diff --git a/arch/arm/mach-tegra/sleep-tegra30.S b/arch/arm/mach-tegra/sleep-tegra30.S
index ecad4ea..5d2522a 100644
--- a/arch/arm/mach-tegra/sleep-tegra30.S
+++ b/arch/arm/mach-tegra/sleep-tegra30.S
@@ -18,13 +18,96 @@
 
 #include <asm/assembler.h>
 #include <asm/asm-offsets.h>
+#include <asm/cache.h>
 
 #include "fuse.h"
 #include "sleep.h"
 #include "flowctrl.h"
 
+#define EMC_CFG				0xc
+#define EMC_ADR_CFG			0x10
+#define EMC_TIMING_CONTROL		0x28
+#define EMC_REFRESH			0x70
+#define EMC_NOP				0xdc
+#define EMC_SELF_REF			0xe0
+#define EMC_MRW				0xe8
+#define EMC_FBIO_CFG5			0x104
+#define EMC_AUTO_CAL_CONFIG		0x2a4
+#define EMC_AUTO_CAL_INTERVAL		0x2a8
+#define EMC_AUTO_CAL_STATUS		0x2ac
+#define EMC_REQ_CTRL			0x2b0
+#define EMC_CFG_DIG_DLL			0x2bc
+#define EMC_EMC_STATUS			0x2b4
+#define EMC_ZCAL_INTERVAL		0x2e0
+#define EMC_ZQ_CAL			0x2ec
+#define EMC_XM2VTTGENPADCTRL		0x310
+#define EMC_XM2VTTGENPADCTRL2		0x314
+
+#define PMC_CTRL			0x0
+#define PMC_CTRL_SIDE_EFFECT_LP0 (1 << 14) /* enter LP0 when CPU pwr gated */
+
+#define PMC_PLLP_WB0_OVERRIDE		0xf8
+#define PMC_IO_DPD_REQ			0x1b8
+#define PMC_IO_DPD_STATUS		0x1bc
+
+#define CLK_RESET_CCLK_BURST		0x20
+#define CLK_RESET_CCLK_DIVIDER		0x24
+#define CLK_RESET_SCLK_BURST		0x28
+#define CLK_RESET_SCLK_DIVIDER		0x2c
+
+#define CLK_RESET_PLLC_BASE		0x80
+#define CLK_RESET_PLLC_MISC		0x8c
+#define CLK_RESET_PLLM_BASE		0x90
+#define CLK_RESET_PLLM_MISC		0x9c
+#define CLK_RESET_PLLP_BASE		0xa0
+#define CLK_RESET_PLLP_MISC		0xac
+#define CLK_RESET_PLLA_BASE		0xb0
+#define CLK_RESET_PLLA_MISC		0xbc
+#define CLK_RESET_PLLX_BASE		0xe0
+#define CLK_RESET_PLLX_MISC		0xe4
+
+#define CLK_RESET_CLK_SOURCE_MSELECT	0x3b4
+
+#define MSELECT_CLKM			(0x3 << 30)
+
+#define LOCK_DELAY 50 /* safety delay after lock is detected */
+
 #define TEGRA30_POWER_HOTPLUG_SHUTDOWN	(1 << 27) /* Hotplug shutdown */
 
+.macro emc_device_mask, rd, base
+	ldr	\rd, [\base, #EMC_ADR_CFG]
+	tst	\rd, #0x1
+	moveq	\rd, #(0x1 << 8)		@ just 1 device
+	movne	\rd, #(0x3 << 8)		@ 2 devices
+.endm
+
+.macro emc_timing_update, rd, base
+	mov	\rd, #1
+	str	\rd, [\base, #EMC_TIMING_CONTROL]
+1001:
+	ldr	\rd, [\base, #EMC_EMC_STATUS]
+	tst	\rd, #(0x1<<23)	@ wait EMC_STATUS_TIMING_UPDATE_STALLED is clear
+	bne	1001b
+.endm
+
+.macro pll_enable, rd, r_car_base, pll_base, pll_misc
+	ldr	\rd, [\r_car_base, #\pll_base]
+	tst	\rd, #(1 << 30)
+	orreq	\rd, \rd, #(1 << 30)
+	streq	\rd, [\r_car_base, #\pll_base]
+	/* Enable lock detector */
+	ldr	\rd, [\r_car_base, #\pll_misc]
+	orr	\rd, \rd, #(1 << 18)
+	str	\rd, [\r_car_base, #\pll_misc]
+.endm
+
+.macro pll_locked, rd, r_car_base, pll_base
+1:
+	ldr	\rd, [\r_car_base, #\pll_base]
+	tst	\rd, #(1 << 27)
+	beq	1b
+.endm
+
 #if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_PM_SLEEP)
 /*
  * tegra30_hotplug_shutdown(void)
@@ -129,6 +212,41 @@ ENDPROC(tegra30_cpu_shutdown)
 
 #ifdef CONFIG_PM_SLEEP
 /*
+ * tegra30_sleep_core_finish(unsigned long v2p)
+ *
+ * Enters suspend in LP0 or LP1 by turning off the MMU and jumping to
+ * tegra30_tear_down_core in IRAM
+ */
+ENTRY(tegra30_sleep_core_finish)
+	/* Flush, disable the L1 data cache and exit SMP */
+	bl	tegra_disable_clean_inv_dcache
+
+	/*
+	 * Preload all the address literals that are needed for the
+	 * CPU power-gating process, to avoid loading from SDRAM which
+	 * are not supported once SDRAM is put into self-refresh.
+	 * LP0 / LP1 use physical address, since the MMU needs to be
+	 * disalbed before putting SDRAM into self-refresh to avoid
+	 * memory access due to page table walks.
+	 */
+	mov32	r4, TEGRA_PMC_BASE
+	mov32	r5, TEGRA_CLK_RESET_BASE
+	mov32	r6, TEGRA_FLOW_CTRL_BASE
+	mov32	r7, TEGRA_TMRUS_BASE
+
+	mov32	r3, tegra_shut_off_mmu
+	add	r3, r3, r0
+
+	mov32	r0, tegra30_tear_down_core
+	mov32	r1, tegra30_iram_start
+	sub	r0, r0, r1
+	mov32	r1, TEGRA_IRAM_CODE_AREA
+	add	r0, r0, r1
+
+	mov	pc, r3
+ENDPROC(tegra30_sleep_core_finish)
+
+/*
  * tegra30_sleep_cpu_secondary_finish(unsigned long v2p)
  *
  * Enters LP2 on secondary CPU by exiting coherency and powergating the CPU.
@@ -158,6 +276,278 @@ ENTRY(tegra30_tear_down_cpu)
 	b	tegra30_enter_sleep
 ENDPROC(tegra30_tear_down_cpu)
 
+/* START OF ROUTINES COPIED TO IRAM */
+	.align L1_CACHE_SHIFT
+	.globl tegra30_iram_start
+tegra30_iram_start:
+
+/*
+ * tegra30_lp1_reset
+ *
+ * reset vector for LP1 restore; copied into IRAM during suspend.
+ * Brings the system back up to a safe staring point (SDRAM out of
+ * self-refresh, PLLC, PLLM and PLLP reenabled, CPU running on PLLX,
+ * system clock running on the same PLL that it suspended at), and
+ * jumps to tegra_resume to restore virtual addressing.
+ * The physical address of tegra_resume expected to be stored in
+ * PMC_SCRATCH41.
+ *
+ * NOTE: THIS *MUST* BE RELOCATED TO TEGRA_IRAM_CODE_AREA AND MUST BE FIRST.
+ */
+ENTRY(tegra30_lp1_reset)
+	/*
+	 * The CPU and system bus are running at 32KHz and executing from
+	 * IRAM when this code is executed; immediately switch to CLKM and
+	 * enable PLLP, PLLM, PLLC, PLLA and PLLX.
+	 */
+	mov32	r0, TEGRA_CLK_RESET_BASE
+
+	mov	r1, #(1 << 28)
+	str	r1, [r0, #CLK_RESET_SCLK_BURST]
+	str	r1, [r0, #CLK_RESET_CCLK_BURST]
+	mov	r1, #0
+	str	r1, [r0, #CLK_RESET_CCLK_DIVIDER]
+	str	r1, [r0, #CLK_RESET_SCLK_DIVIDER]
+
+	/* enable PLLM via PMC */
+	mov32	r2, TEGRA_PMC_BASE
+	ldr	r1, [r2, #PMC_PLLP_WB0_OVERRIDE]
+	orr	r1, r1, #(1 << 12)
+	str	r1, [r2, #PMC_PLLP_WB0_OVERRIDE]
+
+	pll_enable r1, r0, CLK_RESET_PLLM_BASE, CLK_RESET_PLLM_MISC
+	pll_enable r1, r0, CLK_RESET_PLLP_BASE, CLK_RESET_PLLP_MISC
+	pll_enable r1, r0, CLK_RESET_PLLA_BASE, CLK_RESET_PLLA_MISC
+	pll_enable r1, r0, CLK_RESET_PLLC_BASE, CLK_RESET_PLLC_MISC
+	pll_enable r1, r0, CLK_RESET_PLLX_BASE, CLK_RESET_PLLX_MISC
+
+	pll_locked r1, r0, CLK_RESET_PLLM_BASE
+	pll_locked r1, r0, CLK_RESET_PLLP_BASE
+	pll_locked r1, r0, CLK_RESET_PLLA_BASE
+	pll_locked r1, r0, CLK_RESET_PLLC_BASE
+	pll_locked r1, r0, CLK_RESET_PLLX_BASE
+
+	mov32	r7, TEGRA_TMRUS_BASE
+	ldr	r1, [r7]
+	add	r1, r1, #LOCK_DELAY
+	wait_until r1, r7, r3
+
+	adr	r5, tegra30_sdram_pad_save
+
+	ldr	r4, [r5, #0x18]		@ restore CLK_SOURCE_MSELECT
+	str	r4, [r0, #CLK_RESET_CLK_SOURCE_MSELECT]
+
+	ldr	r4, [r5, #0x1C]		@ restore SCLK_BURST
+	str	r4, [r0, #CLK_RESET_SCLK_BURST]
+
+	mov32	r4, ((1 << 28) | (0x8))	@ burst policy is PLLX
+	str	r4, [r0, #CLK_RESET_CCLK_BURST]
+
+	/* Restore pad power state to normal */
+	ldr	r1, [r5, #0x14]		@ PMC_IO_DPD_STATUS
+	mvn	r1, r1
+	bic	r1, r1, #(1 << 31)
+	orr	r1, r1, #(1 << 30)
+	str	r1, [r2, #PMC_IO_DPD_REQ]	@ DPD_OFF
+
+	mov32	r0, TEGRA_EMC_BASE	@ r0 reserved for emc base
+
+	ldr	r1, [r5, #0xC]		@ restore EMC_XM2VTTGENPADCTRL
+	str	r1, [r0, #EMC_XM2VTTGENPADCTRL]
+	ldr	r1, [r5, #0x10]		@ restore EMC_XM2VTTGENPADCTRL2
+	str	r1, [r0, #EMC_XM2VTTGENPADCTRL2]
+	ldr	r1, [r5, #0x8]		@ restore EMC_AUTO_CAL_INTERVAL
+	str	r1, [r0, #EMC_AUTO_CAL_INTERVAL]
+
+	/* Relock DLL */
+	ldr	r1, [r0, #EMC_CFG_DIG_DLL]
+	orr	r1, r1, #(1 << 30)	@ set DLL_RESET
+	str	r1, [r0, #EMC_CFG_DIG_DLL]
+
+	emc_timing_update r1, r0
+
+	ldr	r1, [r0, #EMC_AUTO_CAL_CONFIG]
+	orr	r1, r1, #(1 << 31)	@ set AUTO_CAL_ACTIVE
+	str	r1, [r0, #EMC_AUTO_CAL_CONFIG]
+
+emc_wait_auto_cal_onetime:
+	ldr	r1, [r0, #EMC_AUTO_CAL_STATUS]
+	tst	r1, #(1 << 31)		@ wait until AUTO_CAL_ACTIVE is cleared
+	bne	emc_wait_auto_cal_onetime
+
+	ldr	r1, [r0, #EMC_CFG]
+	bic	r1, r1, #(1 << 31)	@ disable DRAM_CLK_STOP_PD
+	str	r1, [r0, #EMC_CFG]
+
+	mov	r1, #0
+	str	r1, [r0, #EMC_SELF_REF]	@ take DRAM out of self refresh
+	mov	r1, #1
+	str	r1, [r0, #EMC_NOP]
+	str	r1, [r0, #EMC_NOP]
+	str	r1, [r0, #EMC_REFRESH]
+
+	emc_device_mask r1, r0
+
+exit_selfrefresh_loop:
+	ldr	r2, [r0, #EMC_EMC_STATUS]
+	ands	r2, r2, r1
+	bne	exit_selfrefresh_loop
+
+	lsr	r1, r1, #8		@ devSel, bit0:dev0, bit1:dev1
+
+	mov32	r7, TEGRA_TMRUS_BASE
+	ldr	r2, [r0, #EMC_FBIO_CFG5]
+
+	and	r2, r2,	#3		@ check DRAM_TYPE
+	cmp	r2, #2
+	beq	emc_lpddr2
+
+	/* Issue a ZQ_CAL for dev0 - DDR3 */
+	mov32	r2, 0x80000011		@ DEV_SELECTION=2, LENGTH=LONG, CMD=1
+	str	r2, [r0, #EMC_ZQ_CAL]
+	ldr	r2, [r7]
+	add	r2, r2, #10
+	wait_until r2, r7, r3
+
+	tst	r1, #2
+	beq	zcal_done
+
+	/* Issue a ZQ_CAL for dev1 - DDR3 */
+	mov32	r2, 0x40000011		@ DEV_SELECTION=1, LENGTH=LONG, CMD=1
+	str	r2, [r0, #EMC_ZQ_CAL]
+	ldr	r2, [r7]
+	add	r2, r2, #10
+	wait_until r2, r7, r3
+	b	zcal_done
+
+emc_lpddr2:
+	/* Issue a ZQ_CAL for dev0 - LPDDR2 */
+	mov32	r2, 0x800A00AB		@ DEV_SELECTION=2, MA=10, OP=0xAB
+	str	r2, [r0, #EMC_MRW]
+	ldr	r2, [r7]
+	add	r2, r2, #1
+	wait_until r2, r7, r3
+
+	tst	r1, #2
+	beq	zcal_done
+
+	/* Issue a ZQ_CAL for dev0 - LPDDR2 */
+	mov32	r2, 0x400A00AB		@ DEV_SELECTION=1, MA=10, OP=0xAB
+	str	r2, [r0, #EMC_MRW]
+	ldr	r2, [r7]
+	add	r2, r2, #1
+	wait_until r2, r7, r3
+
+zcal_done:
+	mov	r1, #0			@ unstall all transactions
+	str	r1, [r0, #EMC_REQ_CTRL]
+	ldr	r1, [r5, #0x4]		@ restore EMC_ZCAL_INTERVAL
+	str	r1, [r0, #EMC_ZCAL_INTERVAL]
+	ldr	r1, [r5, #0x0]		@ restore EMC_CFG
+	str	r1, [r0, #EMC_CFG]
+
+	mov32	r0, TEGRA_PMC_BASE
+	ldr	r0, [r0, #PMC_SCRATCH41]
+	mov	pc, r0			@ jump to tegra_resume
+ENDPROC(tegra30_lp1_reset)
+
+	.align	L1_CACHE_SHIFT
+	.type	tegra30_sdram_pad_save, %object
+tegra30_sdram_pad_save:
+	.word	0
+	.word	0
+	.word	0
+	.word	0
+	.word	0
+	.word	0
+	.word	0
+	.word	0
+
+tegra30_sdram_pad_address:
+	.word	TEGRA_EMC_BASE + EMC_CFG				@0x0
+	.word	TEGRA_EMC_BASE + EMC_ZCAL_INTERVAL			@0x4
+	.word	TEGRA_EMC_BASE + EMC_AUTO_CAL_INTERVAL			@0x8
+	.word	TEGRA_EMC_BASE + EMC_XM2VTTGENPADCTRL			@0xc
+	.word	TEGRA_EMC_BASE + EMC_XM2VTTGENPADCTRL2			@0x10
+	.word	TEGRA_PMC_BASE + PMC_IO_DPD_STATUS			@0x14
+	.word	TEGRA_CLK_RESET_BASE + CLK_RESET_CLK_SOURCE_MSELECT	@0x18
+	.word	TEGRA_CLK_RESET_BASE + CLK_RESET_SCLK_BURST		@0x1c
+
+tegra30_sdram_pad_size:
+	.word	tegra30_sdram_pad_address - tegra30_sdram_pad_save
+
+/*
+ * tegra30_tear_down_core
+ *
+ * copied into and executed from IRAM
+ * puts memory in self-refresh for LP0 and LP1
+ */
+tegra30_tear_down_core:
+	bl	tegra30_sdram_self_refresh
+	bl	tegra30_switch_cpu_to_clk32k
+	b	tegra30_enter_sleep
+
+/*
+ * tegra30_switch_cpu_to_clk32k
+ *
+ * In LP0 and LP1 all PLLs will be turned off. Switching the CPU and System CLK
+ * to the 32KHz clock.
+ * r4 = TEGRA_PMC_BASE
+ * r5 = TEGRA_CLK_RESET_BASE
+ * r6 = TEGRA_FLOW_CTRL_BASE
+ * r7 = TEGRA_TMRUS_BASE
+ */
+tegra30_switch_cpu_to_clk32k:
+	/*
+	 * start by jumping to CLKM to safely disable PLLs, then jump to
+	 * CLKS.
+	 */
+	mov	r0, #(1 << 28)
+	str	r0, [r5, #CLK_RESET_SCLK_BURST]
+	/* 2uS delay delay between changing SCLK and CCLK */
+	wait_for_us r1, r7, r9
+	add	r1, r1, #2
+	wait_until r1, r7, r9
+	str	r0, [r5, #CLK_RESET_CCLK_BURST]
+	mov	r0, #0
+	str	r0, [r5, #CLK_RESET_CCLK_DIVIDER]
+	str	r0, [r5, #CLK_RESET_SCLK_DIVIDER]
+
+	/* switch the clock source of mselect to be CLK_M */
+	ldr	r0, [r5, #CLK_RESET_CLK_SOURCE_MSELECT]
+	orr	r0, r0, #MSELECT_CLKM
+	str	r0, [r5, #CLK_RESET_CLK_SOURCE_MSELECT]
+
+	/* 2uS delay delay between changing SCLK and disabling PLLs */
+	wait_for_us r1, r7, r9
+	add	r1, r1, #2
+	wait_until r1, r7, r9
+
+	/* disable PLLM via PMC in LP1 */
+	ldr	r0, [r4, #PMC_PLLP_WB0_OVERRIDE]
+	bic	r0, r0, #(1 << 12)
+	str	r0, [r4, #PMC_PLLP_WB0_OVERRIDE]
+
+	/* disable PLLP, PLLA, PLLC and PLLX */
+	ldr	r0, [r5, #CLK_RESET_PLLP_BASE]
+	bic	r0, r0, #(1 << 30)
+	str	r0, [r5, #CLK_RESET_PLLP_BASE]
+	ldr	r0, [r5, #CLK_RESET_PLLA_BASE]
+	bic	r0, r0, #(1 << 30)
+	str	r0, [r5, #CLK_RESET_PLLA_BASE]
+	ldr	r0, [r5, #CLK_RESET_PLLC_BASE]
+	bic	r0, r0, #(1 << 30)
+	str	r0, [r5, #CLK_RESET_PLLC_BASE]
+	ldr	r0, [r5, #CLK_RESET_PLLX_BASE]
+	bic	r0, r0, #(1 << 30)
+	str	r0, [r5, #CLK_RESET_PLLX_BASE]
+
+	/* switch to CLKS */
+	mov	r0, #0	/* brust policy = 32KHz */
+	str	r0, [r5, #CLK_RESET_SCLK_BURST]
+
+	mov	pc, lr
+
 /*
  * tegra30_enter_sleep
  *
@@ -194,4 +584,105 @@ halted:
 	/* !!!FIXME!!! Implement halt failure handler */
 	b	halted
 
+/*
+ * tegra30_sdram_self_refresh
+ *
+ * called with MMU off and caches disabled
+ * must be executed from IRAM
+ * r4 = TEGRA_PMC_BASE
+ * r5 = TEGRA_CLK_RESET_BASE
+ * r6 = TEGRA_FLOW_CTRL_BASE
+ * r7 = TEGRA_TMRUS_BASE
+ */
+tegra30_sdram_self_refresh:
+
+	adr	r2, tegra30_sdram_pad_address
+	adr	r8, tegra30_sdram_pad_save
+	mov	r9, #0
+
+	ldr	r3, tegra30_sdram_pad_size
+padsave:
+	ldr	r0, [r2, r9]		@ r0 is the addr in the pad_address
+
+	ldr	r1, [r0]
+	str	r1, [r8, r9]		@ save the content of the addr
+
+	add	r9, r9, #4
+	cmp	r3, r9
+	bne	padsave
+padsave_done:
+
+	dsb
+
+	mov32	r0, TEGRA_EMC_BASE	@ r0 reserved for emc base addr
+
+	mov	r1, #0
+	str	r1, [r0, #EMC_ZCAL_INTERVAL]
+	str	r1, [r0, #EMC_AUTO_CAL_INTERVAL]
+	ldr	r1, [r0, #EMC_CFG]
+	bic	r1, r1, #(1 << 28)
+	str	r1, [r0, #EMC_CFG]	@ disable DYN_SELF_REF
+
+	emc_timing_update r1, r0
+
+	ldr	r1, [r7]
+	add	r1, r1, #5
+	wait_until r1, r7, r2
+
+emc_wait_auto_cal:
+	ldr	r1, [r0, #EMC_AUTO_CAL_STATUS]
+	tst	r1, #(1 << 31)		@ wait until AUTO_CAL_ACTIVE is cleared
+	bne	emc_wait_auto_cal
+
+	mov	r1, #3
+	str	r1, [r0, #EMC_REQ_CTRL]	@ stall incoming DRAM requests
+
+emcidle:
+	ldr	r1, [r0, #EMC_EMC_STATUS]
+	tst	r1, #4
+	beq	emcidle
+
+	mov	r1, #1
+	str	r1, [r0, #EMC_SELF_REF]
+
+	emc_device_mask r1, r0
+
+emcself:
+	ldr	r2, [r0, #EMC_EMC_STATUS]
+	and	r2, r2, r1
+	cmp	r2, r1
+	bne	emcself			@ loop until DDR in self-refresh
+
+	/* Put VTTGEN in the lowest power mode */
+	ldr	r1, [r0, #EMC_XM2VTTGENPADCTRL]
+	mov32	r2, 0xF8F8FFFF	@ clear XM2VTTGEN_DRVUP and XM2VTTGEN_DRVDN
+	and	r1, r1, r2
+	str	r1, [r0, #EMC_XM2VTTGENPADCTRL]
+	ldr	r1, [r0, #EMC_XM2VTTGENPADCTRL2]
+	orr	r1, r1, #7		@ set E_NO_VTTGEN
+	str	r1, [r0, #EMC_XM2VTTGENPADCTRL2]
+
+	emc_timing_update r1, r0
+
+	ldr	r1, [r4, #PMC_CTRL]
+	tst	r1, #PMC_CTRL_SIDE_EFFECT_LP0
+	bne	pmc_io_dpd_skip
+	/*
+	 * Put DDR_DATA, DISC_ADDR_CMD, DDR_ADDR_CMD, POP_ADDR_CMD, POP_CLK
+	 * and COMP in the lowest power mode when LP1.
+	 */
+	mov32	r1, 0x8EC00000
+	str	r1, [r4, #PMC_IO_DPD_REQ]
+pmc_io_dpd_skip:
+
+	dsb
+
+	mov	pc, lr
+
+	.ltorg
+/* dummy symbol for end of IRAM */
+	.align L1_CACHE_SHIFT
+	.global tegra30_iram_end
+tegra30_iram_end:
+	b	.
 #endif
diff --git a/arch/arm/mach-tegra/sleep.S b/arch/arm/mach-tegra/sleep.S
index 8388113..8d06213 100644
--- a/arch/arm/mach-tegra/sleep.S
+++ b/arch/arm/mach-tegra/sleep.S
@@ -134,10 +134,10 @@ ENTRY(tegra_shut_off_mmu)
 #ifdef CONFIG_CACHE_L2X0
 	/* Disable L2 cache */
 	check_cpu_part_num 0xc09, r9, r10
-	movweq	r4, #:lower16:(TEGRA_ARM_PERIF_BASE + 0x3000)
-	movteq	r4, #:upper16:(TEGRA_ARM_PERIF_BASE + 0x3000)
-	moveq	r5, #0
-	streq	r5, [r4, #L2X0_CTRL]
+	movweq	r2, #:lower16:(TEGRA_ARM_PERIF_BASE + 0x3000)
+	movteq	r2, #:upper16:(TEGRA_ARM_PERIF_BASE + 0x3000)
+	moveq	r3, #0
+	streq	r3, [r2, #L2X0_CTRL]
 #endif
 	mov	pc, r0
 ENDPROC(tegra_shut_off_mmu)
diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h
index e7f8b6f..cfce981 100644
--- a/arch/arm/mach-tegra/sleep.h
+++ b/arch/arm/mach-tegra/sleep.h
@@ -48,6 +48,22 @@
 #define TEGRA_FLUSH_CACHE_ALL	1
 
 #ifdef __ASSEMBLY__
+/* waits until the microsecond counter (base) ticks, for exact timing loops */
+.macro wait_for_us, rd, base, tmp
+	ldr	\rd, [\base]
+1001:	ldr	\tmp, [\base]
+	cmp	\rd, \tmp
+	beq	1001b
+.endm
+
+/* waits until the microsecond counter (base) is > rn */
+.macro wait_until, rn, base, tmp
+	add	\rn, \rn, #1
+1002:	ldr	\tmp, [\base]
+	cmp	\tmp, \rn
+	bmi	1002b
+.endm
+
 /* returns the offset of the flow controller halt register for a cpu */
 .macro cpu_to_halt_reg rd, rcpu
 	cmp	\rcpu, #0
-- 
1.8.3.4



From josephl at nvidia.com  Fri Jul 26 05:15:09 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Fri, 26 Jul 2013 17:15:09 +0800
Subject: [PATCH 7/8] ARM: tegra114: add LP1 suspend support
In-Reply-To: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
Message-ID: <1374830110-30685-8-git-send-email-josephl@nvidia.com>

The LP1 suspend mode will power off the CPU, clock gated the PLLs and put
SDRAM to self-refresh mode. Any interrupt can wake up device from LP1. The
sequence when LP1 suspending:

* tunning off L1 data cache and the MMU
* storing some EMC registers, DPD (deep power down) status, clk source of
  mselect and SCLK burst policy
* putting SDRAM into self-refresh
* switching CPU to CLK_M (12MHz OSC)
* tunning off PLLM, PLLP, PLLA, PLLC and PLLX
* switching SCLK to CLK_S (32KHz OSC)
* shutting off the CPU rail

The sequence of LP1 resuming:

* re-enabling PLLM, PLLP, PLLA, PLLC and PLLX
* restoring the clk source of mselect and SCLK burst policy
* restoring DPD status and some EMC registers
* resuming SDRAM to normal mode
* jumping to the "tegra_resume" from PMC_SCRATCH41

Due to the SDRAM will be put into self-refresh mode, the low level
procedures of LP1 suspending and resuming should be copied to
TEGRA_IRAM_CODE_AREA (TEGRA_IRAM_BASE + SZ_4K) when suspending. Before
restoring the CPU context when resuming, the SDRAM needs to be switched
back to normal mode. And the PLLs need to be re-enabled, SCLK burst policy
be restored. Then jumping to "tegra_resume" that was expected to be stored
in PMC_SCRATCH41 to restore CPU context and back to kernel.

Based on the work by: Bo Yan <byan at nvidia.com>

Signed-off-by: Joseph Lo <josephl at nvidia.com>
---
 arch/arm/mach-tegra/Makefile        |   1 +
 arch/arm/mach-tegra/iomap.h         |   6 ++
 arch/arm/mach-tegra/pm.c            |   2 +
 arch/arm/mach-tegra/pm.h            |   2 +-
 arch/arm/mach-tegra/sleep-tegra30.S | 150 ++++++++++++++++++++++++++++++++----
 5 files changed, 147 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index a3fe22d..f4e7063 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_TEGRA_PCI)			+= pcie.o
 
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)	+= tegra114_speedo.o
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)	+= sleep-tegra30.o
+obj-$(CONFIG_ARCH_TEGRA_114_SOC)	+= pm-tegra30.o
 ifeq ($(CONFIG_CPU_IDLE),y)
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)	+= cpuidle-tegra114.o
 endif
diff --git a/arch/arm/mach-tegra/iomap.h b/arch/arm/mach-tegra/iomap.h
index 399fbca..7f463d7 100644
--- a/arch/arm/mach-tegra/iomap.h
+++ b/arch/arm/mach-tegra/iomap.h
@@ -237,6 +237,12 @@
 #define TEGRA_KFUSE_BASE		0x7000FC00
 #define TEGRA_KFUSE_SIZE		SZ_1K
 
+#define TEGRA_EMC0_BASE			0x7001A000
+#define TEGRA_EMC0_SIZE			SZ_2K
+
+#define TEGRA_EMC1_BASE			0x7001A800
+#define TEGRA_EMC1_SIZE			SZ_2K
+
 #define TEGRA_CSITE_BASE		0x70040000
 #define TEGRA_CSITE_SIZE		SZ_256K
 
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index 5ae7ee5..36cadaa 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -214,6 +214,7 @@ static bool tegra_lp1_iram_hook(void)
 		tegra20_lp1_iram_hook();
 		break;
 	case TEGRA30:
+	case TEGRA114:
 		tegra30_lp1_iram_hook();
 		break;
 	default:
@@ -238,6 +239,7 @@ static bool tegra_sleep_core_init(void)
 		tegra20_sleep_core_init();
 		break;
 	case TEGRA30:
+	case TEGRA114:
 		tegra30_sleep_core_init();
 		break;
 	default:
diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h
index 7aef651..1ccc0df 100644
--- a/arch/arm/mach-tegra/pm.h
+++ b/arch/arm/mach-tegra/pm.h
@@ -38,7 +38,7 @@ static inline void tegra20_lp1_iram_hook(void) {}
 static inline void void tegra20_sleep_core_init(void) {}
 #endif
 
-#ifdef CONFIG_ARCH_TEGRA_3x_SOC
+#if defined(CONFIG_ARCH_TEGRA_3x_SOC) || defined(CONFIG_ARCH_TEGRA_114_SOC)
 void tegra30_lp1_iram_hook(void);
 void tegra30_sleep_core_init(void);
 #else
diff --git a/arch/arm/mach-tegra/sleep-tegra30.S b/arch/arm/mach-tegra/sleep-tegra30.S
index 5d2522a..e2f25f3 100644
--- a/arch/arm/mach-tegra/sleep-tegra30.S
+++ b/arch/arm/mach-tegra/sleep-tegra30.S
@@ -65,6 +65,10 @@
 #define CLK_RESET_PLLA_MISC		0xbc
 #define CLK_RESET_PLLX_BASE		0xe0
 #define CLK_RESET_PLLX_MISC		0xe4
+#define CLK_RESET_PLLX_MISC3		0x518
+#define CLK_RESET_PLLX_MISC3_IDDQ	3
+#define CLK_RESET_PLLM_MISC_IDDQ	5
+#define CLK_RESET_PLLC_MISC_IDDQ	26
 
 #define CLK_RESET_CLK_SOURCE_MSELECT	0x3b4
 
@@ -96,9 +100,15 @@
 	orreq	\rd, \rd, #(1 << 30)
 	streq	\rd, [\r_car_base, #\pll_base]
 	/* Enable lock detector */
+	.if	\pll_misc
+	ldr	\rd, [\r_car_base, #\pll_misc]
+	bic	\rd, \rd, #(1 << 18)
+	str	\rd, [\r_car_base, #\pll_misc]
+	ldr	\rd, [\r_car_base, #\pll_misc]
 	ldr	\rd, [\r_car_base, #\pll_misc]
 	orr	\rd, \rd, #(1 << 18)
 	str	\rd, [\r_car_base, #\pll_misc]
+	.endif
 .endm
 
 .macro pll_locked, rd, r_car_base, pll_base
@@ -108,6 +118,18 @@
 	beq	1b
 .endm
 
+.macro pll_iddq_exit, rd, car, iddq, iddq_bit
+	ldr	\rd, [\car, #\iddq]
+	bic	\rd, \rd, #(1<<\iddq_bit)
+	str	\rd, [\car, #\iddq]
+.endm
+
+.macro pll_iddq_entry, rd, car, iddq, iddq_bit
+	ldr	\rd, [\car, #\iddq]
+	orr	\rd, \rd, #(1<<\iddq_bit)
+	str	\rd, [\car, #\iddq]
+.endm
+
 #if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_PM_SLEEP)
 /*
  * tegra30_hotplug_shutdown(void)
@@ -309,6 +331,32 @@ ENTRY(tegra30_lp1_reset)
 	str	r1, [r0, #CLK_RESET_CCLK_DIVIDER]
 	str	r1, [r0, #CLK_RESET_SCLK_DIVIDER]
 
+	tegra_get_soc_id TEGRA_APB_MISC_BASE, r10
+	cmp	r10, #TEGRA30
+	beq	_no_pll_iddq_exit
+
+	pll_iddq_exit r1, r0, CLK_RESET_PLLM_MISC, CLK_RESET_PLLM_MISC_IDDQ
+	pll_iddq_exit r1, r0, CLK_RESET_PLLC_MISC, CLK_RESET_PLLC_MISC_IDDQ
+	pll_iddq_exit r1, r0, CLK_RESET_PLLX_MISC3, CLK_RESET_PLLX_MISC3_IDDQ
+
+	mov32	r7, TEGRA_TMRUS_BASE
+	ldr	r1, [r7]
+	add	r1, r1, #2
+	wait_until r1, r7, r3
+
+	/* enable PLLM via PMC */
+	mov32	r2, TEGRA_PMC_BASE
+	ldr	r1, [r2, #PMC_PLLP_WB0_OVERRIDE]
+	orr	r1, r1, #(1 << 12)
+	str	r1, [r2, #PMC_PLLP_WB0_OVERRIDE]
+
+	pll_enable r1, r0, CLK_RESET_PLLM_BASE, 0
+	pll_enable r1, r0, CLK_RESET_PLLC_BASE, 0
+	pll_enable r1, r0, CLK_RESET_PLLX_BASE, 0
+
+	b	_pll_m_c_x_done
+
+_no_pll_iddq_exit:
 	/* enable PLLM via PMC */
 	mov32	r2, TEGRA_PMC_BASE
 	ldr	r1, [r2, #PMC_PLLP_WB0_OVERRIDE]
@@ -316,11 +364,13 @@ ENTRY(tegra30_lp1_reset)
 	str	r1, [r2, #PMC_PLLP_WB0_OVERRIDE]
 
 	pll_enable r1, r0, CLK_RESET_PLLM_BASE, CLK_RESET_PLLM_MISC
-	pll_enable r1, r0, CLK_RESET_PLLP_BASE, CLK_RESET_PLLP_MISC
-	pll_enable r1, r0, CLK_RESET_PLLA_BASE, CLK_RESET_PLLA_MISC
 	pll_enable r1, r0, CLK_RESET_PLLC_BASE, CLK_RESET_PLLC_MISC
 	pll_enable r1, r0, CLK_RESET_PLLX_BASE, CLK_RESET_PLLX_MISC
 
+_pll_m_c_x_done:
+	pll_enable r1, r0, CLK_RESET_PLLP_BASE, CLK_RESET_PLLP_MISC
+	pll_enable r1, r0, CLK_RESET_PLLA_BASE, CLK_RESET_PLLA_MISC
+
 	pll_locked r1, r0, CLK_RESET_PLLM_BASE
 	pll_locked r1, r0, CLK_RESET_PLLP_BASE
 	pll_locked r1, r0, CLK_RESET_PLLA_BASE
@@ -340,8 +390,10 @@ ENTRY(tegra30_lp1_reset)
 	ldr	r4, [r5, #0x1C]		@ restore SCLK_BURST
 	str	r4, [r0, #CLK_RESET_SCLK_BURST]
 
-	mov32	r4, ((1 << 28) | (0x8))	@ burst policy is PLLX
-	str	r4, [r0, #CLK_RESET_CCLK_BURST]
+	cmp	r10, #TEGRA30
+	movweq	r4, #:lower16:((1 << 28) | (0x8))	@ burst policy is PLLX
+	movteq	r4, #:upper16:((1 << 28) | (0x8))
+	streq	r4, [r0, #CLK_RESET_CCLK_BURST]
 
 	/* Restore pad power state to normal */
 	ldr	r1, [r5, #0x14]		@ PMC_IO_DPD_STATUS
@@ -350,8 +402,13 @@ ENTRY(tegra30_lp1_reset)
 	orr	r1, r1, #(1 << 30)
 	str	r1, [r2, #PMC_IO_DPD_REQ]	@ DPD_OFF
 
-	mov32	r0, TEGRA_EMC_BASE	@ r0 reserved for emc base
+	cmp	r10, #TEGRA30
+	movweq	r0, #:lower16:TEGRA_EMC_BASE	@ r0 reserved for emc base
+	movteq	r0, #:upper16:TEGRA_EMC_BASE
+	movwne	r0, #:lower16:TEGRA_EMC0_BASE
+	movtne	r0, #:upper16:TEGRA_EMC0_BASE
 
+exit_self_refresh:
 	ldr	r1, [r5, #0xC]		@ restore EMC_XM2VTTGENPADCTRL
 	str	r1, [r0, #EMC_XM2VTTGENPADCTRL]
 	ldr	r1, [r5, #0x10]		@ restore EMC_XM2VTTGENPADCTRL2
@@ -366,8 +423,14 @@ ENTRY(tegra30_lp1_reset)
 
 	emc_timing_update r1, r0
 
+	cmp	r10, #TEGRA114
+	movweq	r1, #:lower16:TEGRA_EMC1_BASE
+	movteq	r1, #:upper16:TEGRA_EMC1_BASE
+	cmpeq	r0, r1
+
 	ldr	r1, [r0, #EMC_AUTO_CAL_CONFIG]
 	orr	r1, r1, #(1 << 31)	@ set AUTO_CAL_ACTIVE
+	orreq	r1, r1, #(1 << 27)	@ set slave mode for channel 1
 	str	r1, [r0, #EMC_AUTO_CAL_CONFIG]
 
 emc_wait_auto_cal_onetime:
@@ -382,9 +445,10 @@ emc_wait_auto_cal_onetime:
 	mov	r1, #0
 	str	r1, [r0, #EMC_SELF_REF]	@ take DRAM out of self refresh
 	mov	r1, #1
-	str	r1, [r0, #EMC_NOP]
-	str	r1, [r0, #EMC_NOP]
-	str	r1, [r0, #EMC_REFRESH]
+	cmp	r10, #TEGRA30
+	streq	r1, [r0, #EMC_NOP]
+	streq	r1, [r0, #EMC_NOP]
+	streq	r1, [r0, #EMC_REFRESH]
 
 	emc_device_mask r1, r0
 
@@ -446,6 +510,16 @@ zcal_done:
 	ldr	r1, [r5, #0x0]		@ restore EMC_CFG
 	str	r1, [r0, #EMC_CFG]
 
+	/* Tegra114 had dual EMC channel, now config the other one */
+	cmp	r10, #TEGRA114
+	bne	__no_dual_emc_chanl
+	mov32	r1, TEGRA_EMC1_BASE
+	cmp	r0, r1
+	movne	r0, r1
+	addne	r5, r5, #0x20
+	bne	exit_self_refresh
+__no_dual_emc_chanl:
+
 	mov32	r0, TEGRA_PMC_BASE
 	ldr	r0, [r0, #PMC_SCRATCH41]
 	mov	pc, r0			@ jump to tegra_resume
@@ -462,6 +536,11 @@ tegra30_sdram_pad_save:
 	.word	0
 	.word	0
 	.word	0
+	.word	0
+	.word	0
+	.word	0
+	.word	0
+	.word	0
 
 tegra30_sdram_pad_address:
 	.word	TEGRA_EMC_BASE + EMC_CFG				@0x0
@@ -473,8 +552,26 @@ tegra30_sdram_pad_address:
 	.word	TEGRA_CLK_RESET_BASE + CLK_RESET_CLK_SOURCE_MSELECT	@0x18
 	.word	TEGRA_CLK_RESET_BASE + CLK_RESET_SCLK_BURST		@0x1c
 
+tegra114_sdram_pad_address:
+	.word	TEGRA_EMC0_BASE + EMC_CFG				@0x0
+	.word	TEGRA_EMC0_BASE + EMC_ZCAL_INTERVAL			@0x4
+	.word	TEGRA_EMC0_BASE + EMC_AUTO_CAL_INTERVAL			@0x8
+	.word	TEGRA_EMC0_BASE + EMC_XM2VTTGENPADCTRL			@0xc
+	.word	TEGRA_EMC0_BASE + EMC_XM2VTTGENPADCTRL2			@0x10
+	.word	TEGRA_PMC_BASE + PMC_IO_DPD_STATUS			@0x14
+	.word	TEGRA_CLK_RESET_BASE + CLK_RESET_CLK_SOURCE_MSELECT	@0x18
+	.word	TEGRA_CLK_RESET_BASE + CLK_RESET_SCLK_BURST		@0x1c
+	.word	TEGRA_EMC1_BASE + EMC_CFG				@0x20
+	.word	TEGRA_EMC1_BASE + EMC_ZCAL_INTERVAL			@0x24
+	.word	TEGRA_EMC1_BASE + EMC_AUTO_CAL_INTERVAL			@0x28
+	.word	TEGRA_EMC1_BASE + EMC_XM2VTTGENPADCTRL			@0x2c
+	.word	TEGRA_EMC1_BASE + EMC_XM2VTTGENPADCTRL2			@0x30
+
 tegra30_sdram_pad_size:
-	.word	tegra30_sdram_pad_address - tegra30_sdram_pad_save
+	.word	tegra114_sdram_pad_address - tegra30_sdram_pad_address
+
+tegra114_sdram_pad_size:
+	.word	tegra30_sdram_pad_size - tegra114_sdram_pad_address
 
 /*
  * tegra30_tear_down_core
@@ -496,6 +593,7 @@ tegra30_tear_down_core:
  * r5 = TEGRA_CLK_RESET_BASE
  * r6 = TEGRA_FLOW_CTRL_BASE
  * r7 = TEGRA_TMRUS_BASE
+ * r10= SoC ID
  */
 tegra30_switch_cpu_to_clk32k:
 	/*
@@ -542,6 +640,11 @@ tegra30_switch_cpu_to_clk32k:
 	bic	r0, r0, #(1 << 30)
 	str	r0, [r5, #CLK_RESET_PLLX_BASE]
 
+	cmp	r10, #TEGRA30
+	beq	_no_pll_in_iddq
+	pll_iddq_entry r1, r5, CLK_RESET_PLLX_MISC3, CLK_RESET_PLLX_MISC3_IDDQ
+_no_pll_in_iddq:
+
 	/* switch to CLKS */
 	mov	r0, #0	/* brust policy = 32KHz */
 	str	r0, [r5, #CLK_RESET_SCLK_BURST]
@@ -593,14 +696,19 @@ halted:
  * r5 = TEGRA_CLK_RESET_BASE
  * r6 = TEGRA_FLOW_CTRL_BASE
  * r7 = TEGRA_TMRUS_BASE
+ * r10= SoC ID
  */
 tegra30_sdram_self_refresh:
 
-	adr	r2, tegra30_sdram_pad_address
 	adr	r8, tegra30_sdram_pad_save
+	tegra_get_soc_id TEGRA_APB_MISC_BASE, r10
+	cmp	r10, #TEGRA30
+	adreq	r2, tegra30_sdram_pad_address
+	ldreq	r3, tegra30_sdram_pad_size
+	adrne	r2, tegra114_sdram_pad_address
+	ldrne	r3, tegra114_sdram_pad_size
 	mov	r9, #0
 
-	ldr	r3, tegra30_sdram_pad_size
 padsave:
 	ldr	r0, [r2, r9]		@ r0 is the addr in the pad_address
 
@@ -614,13 +722,18 @@ padsave_done:
 
 	dsb
 
-	mov32	r0, TEGRA_EMC_BASE	@ r0 reserved for emc base addr
+	cmp	r10, #TEGRA30
+	ldreq	r0, =TEGRA_EMC_BASE	@ r0 reserved for emc base addr
+	ldrne	r0, =TEGRA_EMC0_BASE
 
+enter_self_refresh:
+	cmp	r10, #TEGRA30
 	mov	r1, #0
 	str	r1, [r0, #EMC_ZCAL_INTERVAL]
 	str	r1, [r0, #EMC_AUTO_CAL_INTERVAL]
 	ldr	r1, [r0, #EMC_CFG]
 	bic	r1, r1, #(1 << 28)
+	bicne	r1, r1, #(1 << 29)
 	str	r1, [r0, #EMC_CFG]	@ disable DYN_SELF_REF
 
 	emc_timing_update r1, r0
@@ -659,11 +772,22 @@ emcself:
 	and	r1, r1, r2
 	str	r1, [r0, #EMC_XM2VTTGENPADCTRL]
 	ldr	r1, [r0, #EMC_XM2VTTGENPADCTRL2]
-	orr	r1, r1, #7		@ set E_NO_VTTGEN
+	cmp	r10, #TEGRA30
+	orreq	r1, r1, #7		@ set E_NO_VTTGEN
+	orrne	r1, r1, #0x3f
 	str	r1, [r0, #EMC_XM2VTTGENPADCTRL2]
 
 	emc_timing_update r1, r0
 
+	/* Tegra114 had dual EMC channel, now config the other one */
+	cmp	r10, #TEGRA114
+	bne	no_dual_emc_chanl
+	mov32	r1, TEGRA_EMC1_BASE
+	cmp	r0, r1
+	movne	r0, r1
+	bne	enter_self_refresh
+no_dual_emc_chanl:
+
 	ldr	r1, [r4, #PMC_CTRL]
 	tst	r1, #PMC_CTRL_SIDE_EFFECT_LP0
 	bne	pmc_io_dpd_skip
-- 
1.8.3.4



From peter.chen at freescale.com  Fri Jul 26 05:18:24 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:24 +0800
Subject: [PATCH v13 08/14] usb: chipidea: disable all interrupts and clear all
 interrupts status
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1374830310-21765-9-git-send-email-peter.chen@freescale.com>

During the initialization, it needs to disable all interrupts
enable bit as well as clear all interrupts status bits to avoid
exceptional interrupt.

Tested-by: Marek Vasut <marex at denx.de>
Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/core.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 28983c3..8884af6 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -198,6 +198,12 @@ static int hw_device_init(struct ci_hdrc *ci, void __iomem *base)
 	if (ci->hw_ep_max > ENDPT_MAX)
 		return -ENODEV;
 
+	/* Disable all interrupts bits */
+	hw_write(ci, OP_USBINTR, 0xffffffff, 0);
+
+	/* Clear all interrupts status bits*/
+	hw_write(ci, OP_USBSTS, 0xffffffff, 0xffffffff);
+
 	dev_dbg(ci->dev, "ChipIdea HDRC found, lpm: %d; cap: %p op: %p\n",
 		ci->hw_bank.lpm, ci->hw_bank.cap, ci->hw_bank.op);
 
@@ -413,8 +419,11 @@ static void ci_get_otg_capable(struct ci_hdrc *ci)
 		ci->is_otg = (hw_read(ci, CAP_DCCPARAMS,
 				DCCPARAMS_DC | DCCPARAMS_HC)
 					== (DCCPARAMS_DC | DCCPARAMS_HC));
-	if (ci->is_otg)
+	if (ci->is_otg) {
 		dev_dbg(ci->dev, "It is OTG capable controller\n");
+		ci_disable_otg_interrupt(ci, OTGSC_INT_EN_BITS);
+		ci_clear_otg_interrupt(ci, OTGSC_INT_STATUS_BITS);
+	}
 }
 
 static int ci_hdrc_probe(struct platform_device *pdev)
-- 
1.7.0.4




From peter.chen at freescale.com  Fri Jul 26 05:18:28 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:28 +0800
Subject: [PATCH v13 12/14] usb: chipidea: udc: misuse flag CI_HDRC_REGS_SHARED
 and CI_HDRC_PULLUP_ON_VBUS
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1374830310-21765-13-git-send-email-peter.chen@freescale.com>

CI_HDRC_REGS_SHARED stands for the controller registers is shared
with other USB drivers, if all USB drivers are at chipidea/, it doesn't
needed to set.
CI_HDRC_PULLUP_ON_VBUS stands for pullup dp when the vbus is on. This
flag doesn't need to set if the vbus is always on for gadget
since dp has always pulled up after the gadget has initialized.

So, the current code seems to misuse this two flags.
- When the gadget initializes, the controller doesn't need to run if
it depends on vbus (CI_HDRC_PULLUP_ON_VBUS), it does not
relate to shared register.
- When the gadget starts (load one gadget module), the controller
can run if vbus is on (CI_HDRC_PULLUP_ON_VBUS), it also does not
relate to shared register.

Tested-by: Marek Vasut <marex at denx.de>
Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/udc.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index c70ce38..45abf4d 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1637,8 +1637,7 @@ static int ci_udc_start(struct usb_gadget *gadget,
 	pm_runtime_get_sync(&ci->gadget.dev);
 	if (ci->platdata->flags & CI_HDRC_PULLUP_ON_VBUS) {
 		if (ci->vbus_active) {
-			if (ci->platdata->flags & CI_HDRC_REGS_SHARED)
-				hw_device_reset(ci, USBMODE_CM_DC);
+			hw_device_reset(ci, USBMODE_CM_DC);
 		} else {
 			pm_runtime_put_sync(&ci->gadget.dev);
 			goto done;
@@ -1801,7 +1800,7 @@ static int udc_start(struct ci_hdrc *ci)
 		}
 	}
 
-	if (!(ci->platdata->flags & CI_HDRC_REGS_SHARED)) {
+	if (!(ci->platdata->flags & CI_HDRC_PULLUP_ON_VBUS)) {
 		retval = hw_device_reset(ci, USBMODE_CM_DC);
 		if (retval)
 			goto put_transceiver;
-- 
1.7.0.4




From peter.chen at freescale.com  Fri Jul 26 05:18:18 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:18 +0800
Subject: [PATCH v13 02/14] usb: chipidea: imx: remove vbus regulator operation
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1374830310-21765-3-git-send-email-peter.chen@freescale.com>

Since we have added vbus reguatlor operation at common
host file (chipidea/host.c), the glue layer vbus operation
isn't needed any more.

Tested-by: Marek Vasut <marex at denx.de>
Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/ci_hdrc_imx.c |   30 +++++++-----------------------
 1 files changed, 7 insertions(+), 23 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index 14362c0..d06355e 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -31,7 +31,6 @@ struct ci_hdrc_imx_data {
 	struct usb_phy *phy;
 	struct platform_device *ci_pdev;
 	struct clk *clk;
-	struct regulator *reg_vbus;
 };
 
 static const struct usbmisc_ops *usbmisc_ops;
@@ -141,22 +140,13 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 		goto err_clk;
 	}
 
-	/* we only support host now, so enable vbus here */
-	data->reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
-	if (!IS_ERR(data->reg_vbus)) {
-		ret = regulator_enable(data->reg_vbus);
-		if (ret) {
-			dev_err(&pdev->dev,
-				"Failed to enable vbus regulator, err=%d\n",
-				ret);
-			goto err_clk;
-		}
-	} else {
-		data->reg_vbus = NULL;
-	}
-
 	pdata.phy = data->phy;
 
+	/* Get the vbus regulator */
+	pdata.reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
+	if (IS_ERR(pdata.reg_vbus))
+		pdata.reg_vbus = NULL;
+
 	if (!pdev->dev.dma_mask)
 		pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
 	if (!pdev->dev.coherent_dma_mask)
@@ -167,7 +157,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 		if (ret) {
 			dev_err(&pdev->dev,
 				"usbmisc init failed, ret=%d\n", ret);
-			goto err;
+			goto err_clk;
 		}
 	}
 
@@ -179,7 +169,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev,
 			"Can't register ci_hdrc platform device, err=%d\n",
 			ret);
-		goto err;
+		goto err_clk;
 	}
 
 	if (usbmisc_ops && usbmisc_ops->post) {
@@ -200,9 +190,6 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 
 disable_device:
 	ci_hdrc_remove_device(data->ci_pdev);
-err:
-	if (data->reg_vbus)
-		regulator_disable(data->reg_vbus);
 err_clk:
 	clk_disable_unprepare(data->clk);
 	return ret;
@@ -215,9 +202,6 @@ static int ci_hdrc_imx_remove(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	ci_hdrc_remove_device(data->ci_pdev);
 
-	if (data->reg_vbus)
-		regulator_disable(data->reg_vbus);
-
 	if (data->phy) {
 		usb_phy_shutdown(data->phy);
 		module_put(data->phy->dev->driver->owner);
-- 
1.7.0.4




From peter.chen at freescale.com  Fri Jul 26 05:18:29 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:29 +0800
Subject: [PATCH v13 13/14] usb: chipidea: udc: .pullup is valid when vbus is
 on at CI_HDRC_PULLUP_ON_VBUS
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1374830310-21765-14-git-send-email-peter.chen@freescale.com>

When the flag CI_HDRC_PULLUP_ON_VBUS is set, .pullup should only be
called when the vbus is active. When the CI_HDRC_PULLUP_ON_VBUS
is set, the controller only begins to run when the vbus is on,
So, it is only meaningful software set pullup/pulldown after
the controller begins to run.

Tested-by: Marek Vasut <marex at denx.de>
Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/udc.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 45abf4d..b7ead5f 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1514,6 +1514,10 @@ static int ci_udc_pullup(struct usb_gadget *_gadget, int is_on)
 {
 	struct ci_hdrc *ci = container_of(_gadget, struct ci_hdrc, gadget);
 
+	if ((ci->platdata->flags & CI_HDRC_PULLUP_ON_VBUS)
+			&& !ci->vbus_active)
+		return -EOPNOTSUPP;
+
 	if (is_on)
 		hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
 	else
-- 
1.7.0.4




From peter.chen at freescale.com  Fri Jul 26 05:18:17 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:17 +0800
Subject: [PATCH v13 01/14] usb: chipidea: add vbus regulator control
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1374830310-21765-2-git-send-email-peter.chen@freescale.com>

For boards which have board level vbus control (eg, through gpio), we
need to vbus operation according to below rules:
- For host, we need open vbus before start hcd, and close it
after remove hcd.
- For otg, the vbus needs to be on/off when usb role switches.
When the host roles begins, it opens vbus; when the host role
finishes, it closes vbus.

We put vbus operation to host as host is the only vbus user,
When we are at host mode, the vbus is on, when we are not at
host mode, vbus should be off.

Tested-by: Marek Vasut <marex at denx.de>
Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/host.c  |   23 ++++++++++++++++++++++-
 include/linux/usb/chipidea.h |    1 +
 2 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 40d0fda..e94e52b 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -24,6 +24,7 @@
 #include <linux/usb.h>
 #include <linux/usb/hcd.h>
 #include <linux/usb/chipidea.h>
+#include <linux/regulator/consumer.h>
 
 #include "../host/ehci.h"
 
@@ -64,9 +65,19 @@ static int host_start(struct ci_hdrc *ci)
 	ehci->caps = ci->hw_bank.cap;
 	ehci->has_hostpc = ci->hw_bank.lpm;
 
+	if (ci->platdata->reg_vbus) {
+		ret = regulator_enable(ci->platdata->reg_vbus);
+		if (ret) {
+			dev_err(ci->dev,
+				"Failed to enable vbus regulator, ret=%d\n",
+				ret);
+			goto put_hcd;
+		}
+	}
+
 	ret = usb_add_hcd(hcd, 0, 0);
 	if (ret)
-		usb_put_hcd(hcd);
+		goto disable_reg;
 	else
 		ci->hcd = hcd;
 
@@ -74,6 +85,14 @@ static int host_start(struct ci_hdrc *ci)
 		hw_write(ci, OP_USBMODE, USBMODE_CI_SDIS, USBMODE_CI_SDIS);
 
 	return ret;
+
+disable_reg:
+	regulator_disable(ci->platdata->reg_vbus);
+
+put_hcd:
+	usb_put_hcd(hcd);
+
+	return ret;
 }
 
 static void host_stop(struct ci_hdrc *ci)
@@ -82,6 +101,8 @@ static void host_stop(struct ci_hdrc *ci)
 
 	usb_remove_hcd(hcd);
 	usb_put_hcd(hcd);
+	if (ci->platdata->reg_vbus)
+		regulator_disable(ci->platdata->reg_vbus);
 }
 
 int ci_hdrc_host_init(struct ci_hdrc *ci)
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 2562994..118bf66 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -24,6 +24,7 @@ struct ci_hdrc_platform_data {
 #define CI_HDRC_CONTROLLER_RESET_EVENT		0
 #define CI_HDRC_CONTROLLER_STOPPED_EVENT	1
 	void	(*notify_event) (struct ci_hdrc *ci, unsigned event);
+	struct regulator *reg_vbus;
 };
 
 /* Default offset of capability registers */
-- 
1.7.0.4




From peter.chen at freescale.com  Fri Jul 26 05:18:23 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:23 +0800
Subject: [PATCH v13 07/14] usb: chipidea: add flag CI_HDRC_DUAL_ROLE_NOT_OTG
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1374830310-21765-8-git-send-email-peter.chen@freescale.com>

Since we need otgsc to know vbus's status at some chipidea
controllers even it is peripheral-only mode. Besides, some
SoCs (eg, AR9331 SoC) don't have otgsc register even
the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS.

We inroduce flag CI_HDRC_DUAL_ROLE_NOT_OTG to indicate if the
controller is dual role, but not supports OTG. If this flag is
not set, we follow the rule that if DCCPARAMS_DC and DCCPARAMS_HC
are both 1 at CAP_DCCPARAMS, then this controller is otg capable.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/core.c  |   38 +++++++++++++++++++++++++++++++-------
 include/linux/usb/chipidea.h |    5 +++++
 2 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 93961ff..28983c3 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -405,6 +405,18 @@ static inline void ci_role_destroy(struct ci_hdrc *ci)
 	ci_hdrc_host_destroy(ci);
 }
 
+static void ci_get_otg_capable(struct ci_hdrc *ci)
+{
+	if (ci->platdata->flags & CI_HDRC_DUAL_ROLE_NOT_OTG)
+		ci->is_otg = false;
+	else
+		ci->is_otg = (hw_read(ci, CAP_DCCPARAMS,
+				DCCPARAMS_DC | DCCPARAMS_HC)
+					== (DCCPARAMS_DC | DCCPARAMS_HC));
+	if (ci->is_otg)
+		dev_dbg(ci->dev, "It is OTG capable controller\n");
+}
+
 static int ci_hdrc_probe(struct platform_device *pdev)
 {
 	struct device	*dev = &pdev->dev;
@@ -461,6 +473,9 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
+	/* To know if controller is OTG capable or not */
+	ci_get_otg_capable(ci);
+
 	if (!ci->platdata->phy_mode)
 		ci->platdata->phy_mode = of_usb_get_phy_mode(dev->of_node);
 
@@ -491,10 +506,22 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 	}
 
 	if (ci->roles[CI_ROLE_HOST] && ci->roles[CI_ROLE_GADGET]) {
-		ci->is_otg = true;
-		/* ID pin needs 1ms debouce time, we delay 2ms for safe */
-		mdelay(2);
-		ci->role = ci_otg_role(ci);
+		if (ci->is_otg) {
+			/*
+			 * ID pin needs 1ms debouce time,
+			 * we delay 2ms for safe.
+			 */
+			mdelay(2);
+			ci->role = ci_otg_role(ci);
+			ci_hdrc_otg_init(ci);
+		} else {
+			/*
+			 * If the controller is not OTG capable, but support
+			 * role switch, the defalt role is gadget, and the
+			 * user can switch it through debugfs (proc in future?)
+			 */
+			ci->role = CI_ROLE_GADGET;
+		}
 	} else {
 		ci->role = ci->roles[CI_ROLE_HOST]
 			? CI_ROLE_HOST
@@ -514,9 +541,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 	if (ret)
 		goto stop;
 
-	if (ci->is_otg)
-		ci_hdrc_otg_init(ci);
-
 	ret = dbg_create_files(ci);
 	if (!ret)
 		return 0;
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 118bf66..e94dc2e 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -20,6 +20,11 @@ struct ci_hdrc_platform_data {
 #define CI_HDRC_REQUIRE_TRANSCEIVER	BIT(1)
 #define CI_HDRC_PULLUP_ON_VBUS		BIT(2)
 #define CI_HDRC_DISABLE_STREAMING	BIT(3)
+	/*
+	 * Only set it when DCCPARAMS.DC==1 and DCCPARAMS.HC==1,
+	 * but otg is not supported (no register otgsc).
+	 */
+#define CI_HDRC_DUAL_ROLE_NOT_OTG	BIT(4)
 	enum usb_dr_mode	dr_mode;
 #define CI_HDRC_CONTROLLER_RESET_EVENT		0
 #define CI_HDRC_CONTROLLER_STOPPED_EVENT	1
-- 
1.7.0.4




From peter.chen at freescale.com  Fri Jul 26 05:18:26 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:26 +0800
Subject: [PATCH v13 10/14] usb: chipidea: add vbus interrupt handler
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1374830310-21765-11-git-send-email-peter.chen@freescale.com>

We add vbus interrupt handler at ci_otg_work, it uses OTGSC_BSV(at otgsc)
to know it is connect or disconnet event.
Meanwhile, we introduce two flags id_event and b_sess_valid_event to
indicate it is an id interrupt or a vbus interrupt.

Tested-by: Marek Vasut <marex at denx.de>
Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/ci.h   |    5 +++++
 drivers/usb/chipidea/core.c |   28 +++++++++++++++++++++++-----
 drivers/usb/chipidea/otg.c  |   42 +++++++++++++++++++++++++++++++++++-------
 drivers/usb/chipidea/otg.h  |    1 +
 drivers/usb/chipidea/udc.c  |    7 +++++++
 5 files changed, 71 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 33cb29f..3160363 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -132,6 +132,9 @@ struct hw_bank {
  * @transceiver: pointer to USB PHY, if any
  * @hcd: pointer to usb_hcd for ehci host driver
  * @debugfs: root dentry for this controller in debugfs
+ * @id_event: indicates there is an id event, and handled at ci_otg_work
+ * @b_sess_valid_event: indicates there is a vbus event, and handled
+ * at ci_otg_work
  */
 struct ci_hdrc {
 	struct device			*dev;
@@ -168,6 +171,8 @@ struct ci_hdrc {
 	struct usb_phy			*transceiver;
 	struct usb_hcd			*hcd;
 	struct dentry			*debugfs;
+	bool				id_event;
+	bool				b_sess_valid_event;
 };
 
 static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 78c4721..0fbeb45 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -304,16 +304,34 @@ static irqreturn_t ci_irq(int irq, void *data)
 	if (ci->is_otg)
 		otgsc = hw_read(ci, OP_OTGSC, ~0);
 
-	if (ci->role != CI_ROLE_END)
-		ret = ci_role(ci)->irq(ci);
+	/*
+	 * Handle id change interrupt, it indicates device/host function
+	 * switch.
+	 */
+	if (ci->is_otg && (otgsc & OTGSC_IDIE) && (otgsc & OTGSC_IDIS)) {
+		ci->id_event = true;
+		ci_clear_otg_interrupt(ci, OTGSC_IDIS);
+		disable_irq_nosync(ci->irq);
+		queue_work(ci->wq, &ci->work);
+		return IRQ_HANDLED;
+	}
 
-	if (ci->is_otg && (otgsc & OTGSC_IDIS)) {
-		hw_write(ci, OP_OTGSC, OTGSC_IDIS, OTGSC_IDIS);
+	/*
+	 * Handle vbus change interrupt, it indicates device connection
+	 * and disconnection events.
+	 */
+	if (ci->is_otg && (otgsc & OTGSC_BSVIE) && (otgsc & OTGSC_BSVIS)) {
+		ci->b_sess_valid_event = true;
+		ci_clear_otg_interrupt(ci, OTGSC_BSVIS);
 		disable_irq_nosync(ci->irq);
 		queue_work(ci->wq, &ci->work);
-		ret = IRQ_HANDLED;
+		return IRQ_HANDLED;
 	}
 
+	/* Handle device/host interrupt */
+	if (ci->role != CI_ROLE_END)
+		ret = ci_role(ci)->irq(ci);
+
 	return ret;
 }
 
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index 68f2faf..c74194d 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -52,13 +52,23 @@ enum ci_role ci_otg_role(struct ci_hdrc *ci)
 	return role;
 }
 
-/**
- * ci_role_work - perform role changing based on ID pin
- * @work: work struct
- */
-static void ci_role_work(struct work_struct *work)
+void ci_handle_vbus_change(struct ci_hdrc *ci)
+{
+	u32 otgsc;
+
+	if (!ci->is_otg)
+		return;
+
+	otgsc = hw_read(ci, OP_OTGSC, ~0);
+
+	if (otgsc & OTGSC_BSV)
+		usb_gadget_vbus_connect(&ci->gadget);
+	else
+		usb_gadget_vbus_disconnect(&ci->gadget);
+}
+
+static void ci_handle_id_switch(struct ci_hdrc *ci)
 {
-	struct ci_hdrc *ci = container_of(work, struct ci_hdrc, work);
 	enum ci_role role = ci_otg_role(ci);
 
 	if (role != ci->role) {
@@ -68,17 +78,35 @@ static void ci_role_work(struct work_struct *work)
 		ci_role_stop(ci);
 		ci_role_start(ci, role);
 	}
+}
+/**
+ * ci_otg_work - perform otg (vbus/id) event handle
+ * @work: work struct
+ */
+static void ci_otg_work(struct work_struct *work)
+{
+	struct ci_hdrc *ci = container_of(work, struct ci_hdrc, work);
+
+	if (ci->id_event) {
+		ci->id_event = false;
+		ci_handle_id_switch(ci);
+	} else if (ci->b_sess_valid_event) {
+		ci->b_sess_valid_event = false;
+		ci_handle_vbus_change(ci);
+	} else
+		dev_err(ci->dev, "unexpected event occurs at %s\n", __func__);
 
 	enable_irq(ci->irq);
 }
 
+
 /**
  * ci_hdrc_otg_init - initialize otg struct
  * ci: the controller
  */
 int ci_hdrc_otg_init(struct ci_hdrc *ci)
 {
-	INIT_WORK(&ci->work, ci_role_work);
+	INIT_WORK(&ci->work, ci_otg_work);
 	ci->wq = create_singlethread_workqueue("ci_otg");
 	if (!ci->wq) {
 		dev_err(ci->dev, "can't create workqueue\n");
diff --git a/drivers/usb/chipidea/otg.h b/drivers/usb/chipidea/otg.h
index 8913062..b8d5c05 100644
--- a/drivers/usb/chipidea/otg.h
+++ b/drivers/usb/chipidea/otg.h
@@ -17,5 +17,6 @@ void ci_enable_otg_interrupt(struct ci_hdrc *ci, u32 bits);
 void ci_disable_otg_interrupt(struct ci_hdrc *ci, u32 bits);
 void ci_hdrc_otg_destory(struct ci_hdrc *ci);
 enum ci_role ci_otg_role(struct ci_hdrc *ci);
+void ci_handle_vbus_change(struct ci_hdrc *ci);
 
 #endif /* __DRIVERS_USB_CHIPIDEA_OTG_H */
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 24a100d..c70ce38 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -85,8 +85,10 @@ static int hw_device_state(struct ci_hdrc *ci, u32 dma)
 		/* interrupt, error, port change, reset, sleep/suspend */
 		hw_write(ci, OP_USBINTR, ~0,
 			     USBi_UI|USBi_UEI|USBi_PCI|USBi_URI|USBi_SLI);
+		hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
 	} else {
 		hw_write(ci, OP_USBINTR, ~0, 0);
+		hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
 	}
 	return 0;
 }
@@ -1460,6 +1462,7 @@ static int ci_udc_vbus_session(struct usb_gadget *_gadget, int is_active)
 			pm_runtime_get_sync(&_gadget->dev);
 			hw_device_reset(ci, USBMODE_CM_DC);
 			hw_device_state(ci, ci->ep0out->qh.dma);
+			dev_dbg(ci->dev, "Connected to host\n");
 		} else {
 			hw_device_state(ci, 0);
 			if (ci->platdata->notify_event)
@@ -1467,6 +1470,7 @@ static int ci_udc_vbus_session(struct usb_gadget *_gadget, int is_active)
 				CI_HDRC_CONTROLLER_STOPPED_EVENT);
 			_gadget_stop_activity(&ci->gadget);
 			pm_runtime_put_sync(&_gadget->dev);
+			dev_dbg(ci->dev, "Disconnected from host\n");
 		}
 	}
 
@@ -1822,6 +1826,9 @@ static int udc_start(struct ci_hdrc *ci)
 	pm_runtime_no_callbacks(&ci->gadget.dev);
 	pm_runtime_enable(&ci->gadget.dev);
 
+	/* Update ci->vbus_active */
+	ci_handle_vbus_change(ci);
+
 	return retval;
 
 remove_trans:
-- 
1.7.0.4




From peter.chen at freescale.com  Fri Jul 26 05:18:27 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:27 +0800
Subject: [PATCH v13 11/14] usb: chipidea: add wait vbus lower than OTGSC_BSV
 before role starts
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1374830310-21765-12-git-send-email-peter.chen@freescale.com>

When the gadget role starts, we need to make sure the vbus is lower
than OTGSC_BSV, or there will be an vbus interrupt since we use
B_SESSION_VALID as vbus interrupt to indicate connect and disconnect.
When the host role starts, it may not be useful to wait vbus to lower
than OTGSC_BSV, but it can indicate some hardware problems like the
vbus is still higher than OTGSC_BSV after we disconnect to host some
time later (5000 milliseconds currently), which is obvious not correct.

Tested-by: Marek Vasut <marex at denx.de>
Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/ci.h   |    3 +++
 drivers/usb/chipidea/core.c |   32 ++++++++++++++++++++++++++++++++
 drivers/usb/chipidea/otg.c  |    4 ++++
 3 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 3160363..1c94fc5 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -308,4 +308,7 @@ int hw_port_test_set(struct ci_hdrc *ci, u8 mode);
 
 u8 hw_port_test_get(struct ci_hdrc *ci);
 
+int hw_wait_reg(struct ci_hdrc *ci, enum ci_hw_regs reg, u32 mask,
+				u32 value, unsigned int timeout_ms);
+
 #endif	/* __DRIVERS_USB_CHIPIDEA_CI_H */
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 0fbeb45..6f9e04d 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -295,6 +295,38 @@ int hw_device_reset(struct ci_hdrc *ci, u32 mode)
 	return 0;
 }
 
+/**
+ * hw_wait_reg: wait the register value
+ *
+ * Sometimes, it needs to wait register value before going on.
+ * Eg, when switch to device mode, the vbus value should be lower
+ * than OTGSC_BSV before connects to host.
+ *
+ * @ci: the controller
+ * @reg: register index
+ * @mask: mast bit
+ * @value: the bit value to wait
+ * @timeout_ms: timeout in millisecond
+ *
+ * This function returns an error code if timeout
+ */
+int hw_wait_reg(struct ci_hdrc *ci, enum ci_hw_regs reg, u32 mask,
+				u32 value, unsigned int timeout_ms)
+{
+	unsigned long elapse = jiffies + msecs_to_jiffies(timeout_ms);
+
+	while (hw_read(ci, reg, mask) != value) {
+		if (time_after(jiffies, elapse)) {
+			dev_err(ci->dev, "timeout waiting for %08x in %d\n",
+					mask, reg);
+			return -ETIMEDOUT;
+		}
+		msleep(20);
+	}
+
+	return 0;
+}
+
 static irqreturn_t ci_irq(int irq, void *data)
 {
 	struct ci_hdrc *ci = data;
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index c74194d..d39cce8 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -67,6 +67,7 @@ void ci_handle_vbus_change(struct ci_hdrc *ci)
 		usb_gadget_vbus_disconnect(&ci->gadget);
 }
 
+#define CI_VBUS_STABLE_TIMEOUT_MS 5000
 static void ci_handle_id_switch(struct ci_hdrc *ci)
 {
 	enum ci_role role = ci_otg_role(ci);
@@ -76,6 +77,9 @@ static void ci_handle_id_switch(struct ci_hdrc *ci)
 			ci_role(ci)->name, ci->roles[role]->name);
 
 		ci_role_stop(ci);
+		/* wait vbus lower than OTGSC_BSV */
+		hw_wait_reg(ci, OP_OTGSC, OTGSC_BSV, 0,
+				CI_VBUS_STABLE_TIMEOUT_MS);
 		ci_role_start(ci, role);
 	}
 }
-- 
1.7.0.4




From peter.chen at freescale.com  Fri Jul 26 05:18:20 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:20 +0800
Subject: [PATCH v13 04/14] usb: chipidea: udc: otg_set_peripheral is useless
 for some chipidea users
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1374830310-21765-5-git-send-email-peter.chen@freescale.com>

It is useless at below cases:
- If we implement both usb host and device at chipidea driver.
- If we don't need phy->otg.

Tested-by: Marek Vasut <marex at denx.de>
Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/udc.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index e475fcd..116c762 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1805,7 +1805,12 @@ static int udc_start(struct ci_hdrc *ci)
 	if (ci->transceiver) {
 		retval = otg_set_peripheral(ci->transceiver->otg,
 						&ci->gadget);
-		if (retval)
+		/*
+		 * If we implement all USB functions using chipidea drivers,
+		 * it doesn't need to call above API, meanwhile, if we only
+		 * use gadget function, calling above API is useless.
+		 */
+		if (retval && retval != -ENOTSUPP)
 			goto put_transceiver;
 	}
 
-- 
1.7.0.4




From peter.chen at freescale.com  Fri Jul 26 05:18:16 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:16 +0800
Subject: [PATCH v13 00/14] Add tested id switch and vbus connect detect
 support for Chipidea
Message-ID: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>

This patchset adds tested otg id switch function and vbus connect
and disconnect detection for chipidea driver. And fix kinds of 
bugs found at chipidea drivers after enabling id and vbus detection.

This patch are fully tested at imx6 sabresd and imx28evk platform by me.
Besides, marek tested it on two STMP3780-based boards (not yet mainline)
and two MX28-based boards.

My chipidea repo: https://github.com/hzpeterchen/linux-usb.git

Chagnes for v13:
- Add Tested-by: Marek Vasut <marex at denx.de>
- [Sascha's comments]: Add return value check for devm_regulator_get. [3/14]
- [Marc's comments]: Change timeout usage at hw_wait_reg. [11/14]
- [Alex's comments]: Using platdata flag to indicate dual role but not 
OTG controller. [7/14]

Changes for v12:
- Rebased greg's usb-next tree (3.10.0-rc7+)
- Split more small patches for single function and fix.

Changes for v11:
- mark ci_handle_vbus_change as static as it is only used at core.c
[3/9]
- Move the vbus operation for platform code to host code, as vbus
operation is common operation, and host is the only user for vbus.
When it is host mode, we need to open vbus, when it is out of host
mode, we need to close vbus. [6/9] [8/9]
- Delete the delayed work at core.c as it is not needed. [7/9]

Changes for v10:
- Delete [8/9] at v9, ci core's drvdata must be set for further operation.
[8/8]

Changes for v9:
- Some small comments from Alex like: variable comment for otg event
additional newline. [3/9]
- Import function tell show if the controller has otg capable, if
the controller supports both host and device, we think it is otg
capable, and can read OTGSC. [3/9]
- Merge two otg patches [v8 3/8] and [v8 4/8] to one [v9 3/9]. [3/9]
- Add inline to ci_hdrc_gadget_destroy if CONFIG_USB_CHIPIDEA_UDC
is not defined, it can fix one build warning "defined but not used"
[3/9]
- One comment from Felipe about changing calling gadget disconnect
API at chipidea's udc driver. I move calling ci->driver->disconnect
from _gadget_stop_activity to which calls _gadget_stop_activity except
ci13xxx_stop, as udc core will call disconnect when do rmmod gadget. [7/9]
- Add ci core probe's return value to ci's platform_data, we do this
for getting core's probe's result at platform layer, and quit it
if the core's probe fails. [8/9] [9/9]

Changes for v8:
- Add ci_supports_gadget helper to know if the controller
supports gadget, if the controller supports gadget, it
needs to read otgsc to know the vbus value, basically,
if the controller supports gadget, it will support host
as well [3/8]
- At ci_hdrc_probe, it needs to add free memory at error path
[3/8]
- Cosolidate ci->driver = NULL at ci13xxx_stop
[8/8]

Changes for v7:
For Patch 8/8, we only need to set ci->driver to NULL when usb cable
is not connected, for other changes, it will case some runtime pm
unmatch and un-align with udc-core & composite driver problems.

Changes for v6:
- Add Alex comments for init/destroy function [3/8] [4/8]
- Remove memset(&ci->gadget, 0, sizeof(ci->gadget)) at destory function [4/8]
- Add Kishon's comment: Change the format of struct usb_otg otg at drivers/usb/chipidea/ci.h
[1/8]
- Add comments for CI_VBUS_STABLE_TIMEOUT [3/8]
- Change the otg_set_peripheral return value check as the fully
chipidea driver users don't need it. [4/8]
- Fix one bug that the oops when re-plug in usb cable after
rmmod gadget [8/8]

Peter Chen (14):
  usb: chipidea: add vbus regulator control
  usb: chipidea: imx: remove vbus regulator operation
  usb: chipidea: imx: add return value check for devm_regulator_get
  usb: chipidea: udc: otg_set_peripheral is useless for some chipidea
    users
  usb: chipidea: otg: Add otg file used to access otgsc
  usb: chipidea: Add role init and destory APIs
  usb: chipidea: add flag CI_HDRC_DUAL_ROLE_NOT_OTG
  usb: chipidea: disable all interrupts and clear all interrupts status
  usb: chipidea: move otg relate things to otg file
  usb: chipidea: add vbus interrupt handler
  usb: chipidea: add wait vbus lower than OTGSC_BSV before role starts
  usb: chipidea: udc: misuse flag CI_HDRC_REGS_SHARED and
    CI_HDRC_PULLUP_ON_VBUS
  usb: chipidea: udc: .pullup is valid when vbus is on at
    CI_HDRC_PULLUP_ON_VBUS
  usb: chipidea: udc: fix the oops when plugs in usb cable after rmmod
    gadget

 drivers/usb/chipidea/Makefile      |    2 +-
 drivers/usb/chipidea/bits.h        |   10 ++
 drivers/usb/chipidea/ci.h          |    8 ++
 drivers/usb/chipidea/ci_hdrc_imx.c |   40 ++++-----
 drivers/usb/chipidea/core.c        |  161 ++++++++++++++++++++++++------------
 drivers/usb/chipidea/host.c        |   30 +++++++-
 drivers/usb/chipidea/host.h        |    6 ++
 drivers/usb/chipidea/otg.c         |  135 ++++++++++++++++++++++++++++++
 drivers/usb/chipidea/otg.h         |   22 +++++
 drivers/usb/chipidea/udc.c         |   72 ++++++++++++----
 drivers/usb/chipidea/udc.h         |    6 ++
 include/linux/usb/chipidea.h       |    6 ++
 12 files changed, 402 insertions(+), 96 deletions(-)
 create mode 100644 drivers/usb/chipidea/otg.c
 create mode 100644 drivers/usb/chipidea/otg.h




From peter.chen at freescale.com  Fri Jul 26 05:18:22 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:22 +0800
Subject: [PATCH v13 06/14] usb: chipidea: Add role init and destory APIs
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1374830310-21765-7-git-send-email-peter.chen@freescale.com>

- The role's init will be called at probe procedure.
- The role's destory will be called at fail patch
at probe and driver's removal.
- The role's start/stop will be called when specific
role has started.

Tested-by: Marek Vasut <marex at denx.de>
Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/core.c |   10 ++++++++--
 drivers/usb/chipidea/host.c |    7 +++++++
 drivers/usb/chipidea/host.h |    6 ++++++
 drivers/usb/chipidea/udc.c  |   36 +++++++++++++++++++++++++++---------
 drivers/usb/chipidea/udc.h  |    6 ++++++
 5 files changed, 54 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 761f7e8..93961ff 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -399,6 +399,12 @@ void ci_hdrc_remove_device(struct platform_device *pdev)
 }
 EXPORT_SYMBOL_GPL(ci_hdrc_remove_device);
 
+static inline void ci_role_destroy(struct ci_hdrc *ci)
+{
+	ci_hdrc_gadget_destroy(ci);
+	ci_hdrc_host_destroy(ci);
+}
+
 static int ci_hdrc_probe(struct platform_device *pdev)
 {
 	struct device	*dev = &pdev->dev;
@@ -517,7 +523,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 
 	free_irq(ci->irq, ci);
 stop:
-	ci_role_stop(ci);
+	ci_role_destroy(ci);
 rm_wq:
 	flush_workqueue(ci->wq);
 	destroy_workqueue(ci->wq);
@@ -533,7 +539,7 @@ static int ci_hdrc_remove(struct platform_device *pdev)
 	flush_workqueue(ci->wq);
 	destroy_workqueue(ci->wq);
 	free_irq(ci->irq, ci);
-	ci_role_stop(ci);
+	ci_role_destroy(ci);
 
 	return 0;
 }
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index e94e52b..382be5b 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -105,6 +105,13 @@ static void host_stop(struct ci_hdrc *ci)
 		regulator_disable(ci->platdata->reg_vbus);
 }
 
+
+void ci_hdrc_host_destroy(struct ci_hdrc *ci)
+{
+	if (ci->role == CI_ROLE_HOST)
+		host_stop(ci);
+}
+
 int ci_hdrc_host_init(struct ci_hdrc *ci)
 {
 	struct ci_role_driver *rdrv;
diff --git a/drivers/usb/chipidea/host.h b/drivers/usb/chipidea/host.h
index 058875c..5707bf3 100644
--- a/drivers/usb/chipidea/host.h
+++ b/drivers/usb/chipidea/host.h
@@ -4,6 +4,7 @@
 #ifdef CONFIG_USB_CHIPIDEA_HOST
 
 int ci_hdrc_host_init(struct ci_hdrc *ci);
+void ci_hdrc_host_destroy(struct ci_hdrc *ci);
 
 #else
 
@@ -12,6 +13,11 @@ static inline int ci_hdrc_host_init(struct ci_hdrc *ci)
 	return -ENXIO;
 }
 
+static inline void ci_hdrc_host_destroy(struct ci_hdrc *ci)
+{
+
+}
+
 #endif
 
 #endif /* __DRIVERS_USB_CHIPIDEA_HOST_H */
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 116c762..24a100d 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -27,6 +27,7 @@
 #include "udc.h"
 #include "bits.h"
 #include "debug.h"
+#include "otg.h"
 
 /* control endpoint description */
 static const struct usb_endpoint_descriptor
@@ -1844,13 +1845,13 @@ free_qh_pool:
 }
 
 /**
- * udc_remove: parent remove must call this to remove UDC
+ * ci_hdrc_gadget_destroy: parent remove must call this to remove UDC
  *
  * No interrupts active, the IRQ has been released
  */
-static void udc_stop(struct ci_hdrc *ci)
+void ci_hdrc_gadget_destroy(struct ci_hdrc *ci)
 {
-	if (ci == NULL)
+	if (!ci->roles[CI_ROLE_GADGET])
 		return;
 
 	usb_del_gadget_udc(&ci->gadget);
@@ -1865,15 +1866,32 @@ static void udc_stop(struct ci_hdrc *ci)
 		if (ci->global_phy)
 			usb_put_phy(ci->transceiver);
 	}
-	/* my kobject is dynamic, I swear! */
-	memset(&ci->gadget, 0, sizeof(ci->gadget));
+}
+
+static int udc_id_switch_for_device(struct ci_hdrc *ci)
+{
+	if (ci->is_otg) {
+		ci_clear_otg_interrupt(ci, OTGSC_BSVIS);
+		ci_enable_otg_interrupt(ci, OTGSC_BSVIE);
+	}
+
+	return 0;
+}
+
+static void udc_id_switch_for_host(struct ci_hdrc *ci)
+{
+	if (ci->is_otg) {
+		/* host doesn't care B_SESSION_VALID event */
+		ci_clear_otg_interrupt(ci, OTGSC_BSVIS);
+		ci_disable_otg_interrupt(ci, OTGSC_BSVIE);
+	}
 }
 
 /**
  * ci_hdrc_gadget_init - initialize device related bits
  * ci: the controller
  *
- * This function enables the gadget role, if the device is "device capable".
+ * This function initializes the gadget, if the device is "device capable".
  */
 int ci_hdrc_gadget_init(struct ci_hdrc *ci)
 {
@@ -1886,11 +1904,11 @@ int ci_hdrc_gadget_init(struct ci_hdrc *ci)
 	if (!rdrv)
 		return -ENOMEM;
 
-	rdrv->start	= udc_start;
-	rdrv->stop	= udc_stop;
+	rdrv->start	= udc_id_switch_for_device;
+	rdrv->stop	= udc_id_switch_for_host;
 	rdrv->irq	= udc_irq;
 	rdrv->name	= "gadget";
 	ci->roles[CI_ROLE_GADGET] = rdrv;
 
-	return 0;
+	return udc_start(ci);
 }
diff --git a/drivers/usb/chipidea/udc.h b/drivers/usb/chipidea/udc.h
index 455ac21..e66df00 100644
--- a/drivers/usb/chipidea/udc.h
+++ b/drivers/usb/chipidea/udc.h
@@ -84,6 +84,7 @@ struct ci_hw_req {
 #ifdef CONFIG_USB_CHIPIDEA_UDC
 
 int ci_hdrc_gadget_init(struct ci_hdrc *ci);
+void ci_hdrc_gadget_destroy(struct ci_hdrc *ci);
 
 #else
 
@@ -92,6 +93,11 @@ static inline int ci_hdrc_gadget_init(struct ci_hdrc *ci)
 	return -ENXIO;
 }
 
+static inline void ci_hdrc_gadget_destroy(struct ci_hdrc *ci)
+{
+
+}
+
 #endif
 
 #endif /* __DRIVERS_USB_CHIPIDEA_UDC_H */
-- 
1.7.0.4




From peter.chen at freescale.com  Fri Jul 26 05:18:19 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:19 +0800
Subject: [PATCH v13 03/14] usb: chipidea: imx: add return value check for
 devm_regulator_get
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1374830310-21765-4-git-send-email-peter.chen@freescale.com>

- If devm_regulator_get returns -EPROBE_DEFER, we also return
-EPROBE_DEFER to wait regulator being ready later.
- If devm_regulator_get returns -ENODEV, we think there is
no "vbus-supply" node at DT, it means this board doesn't need
vbus control.
- If devm_regulator_get returns other error values, it means
there are something wrong for getting this regulator.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/ci_hdrc_imx.c |   14 ++++++++++++--
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index d06355e..0ced8c1 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -144,8 +144,18 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 
 	/* Get the vbus regulator */
 	pdata.reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
-	if (IS_ERR(pdata.reg_vbus))
-		pdata.reg_vbus = NULL;
+	if (PTR_ERR(pdata.reg_vbus) == -EPROBE_DEFER) {
+		ret = -EPROBE_DEFER;
+		goto err_clk;
+	} else if (PTR_ERR(pdata.reg_vbus) == -ENODEV) {
+		pdata.reg_vbus = NULL; /* no vbus regualator is needed */
+	} else if (IS_ERR(pdata.reg_vbus)) {
+		dev_err(&pdev->dev,
+				"Getting regulator error: %ld\n",
+					PTR_ERR(pdata.reg_vbus));
+		ret = PTR_ERR(pdata.reg_vbus);
+		goto err_clk;
+	}
 
 	if (!pdev->dev.dma_mask)
 		pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
-- 
1.7.0.4




From peter.chen at freescale.com  Fri Jul 26 05:18:21 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:21 +0800
Subject: [PATCH v13 05/14] usb: chipidea: otg: Add otg file used to access
 otgsc
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1374830310-21765-6-git-send-email-peter.chen@freescale.com>

This file is mainly used to access otgsc currently, it may
add otg related things in the future.

Tested-by: Marek Vasut <marex at denx.de>
Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/Makefile |    2 +-
 drivers/usb/chipidea/bits.h   |   10 ++++++++
 drivers/usb/chipidea/core.c   |    3 +-
 drivers/usb/chipidea/otg.c    |   50 +++++++++++++++++++++++++++++++++++++++++
 drivers/usb/chipidea/otg.h    |   19 +++++++++++++++
 5 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 6cf5f68..a99d980 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -2,7 +2,7 @@ ccflags-$(CONFIG_USB_CHIPIDEA_DEBUG) := -DDEBUG
 
 obj-$(CONFIG_USB_CHIPIDEA)		+= ci_hdrc.o
 
-ci_hdrc-y				:= core.o
+ci_hdrc-y				:= core.o otg.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC)	+= udc.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST)	+= host.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_DEBUG)	+= debug.o
diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index aefa026..dd0cf9e 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -79,11 +79,21 @@
 #define OTGSC_ASVIS	      BIT(18)
 #define OTGSC_BSVIS	      BIT(19)
 #define OTGSC_BSEIS	      BIT(20)
+#define OTGSC_1MSIS	      BIT(21)
+#define OTGSC_DPIS	      BIT(22)
 #define OTGSC_IDIE	      BIT(24)
 #define OTGSC_AVVIE	      BIT(25)
 #define OTGSC_ASVIE	      BIT(26)
 #define OTGSC_BSVIE	      BIT(27)
 #define OTGSC_BSEIE	      BIT(28)
+#define OTGSC_1MSIE	      BIT(29)
+#define OTGSC_DPIE	      BIT(30)
+#define OTGSC_INT_EN_BITS	(OTGSC_IDIE | OTGSC_AVVIE | OTGSC_ASVIE \
+				| OTGSC_BSVIE | OTGSC_BSEIE | OTGSC_1MSIE \
+				| OTGSC_DPIE)
+#define OTGSC_INT_STATUS_BITS	(OTGSC_IDIS | OTGSC_AVVIS | OTGSC_ASVIS	\
+				| OTGSC_BSVIS | OTGSC_BSEIS | OTGSC_1MSIS \
+				| OTGSC_DPIS)
 
 /* USBMODE */
 #define USBMODE_CM            (0x03UL <<  0)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index a5df24c..761f7e8 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -71,6 +71,7 @@
 #include "bits.h"
 #include "host.h"
 #include "debug.h"
+#include "otg.h"
 
 /* Controller register map */
 static uintptr_t ci_regs_nolpm[] = {
@@ -508,7 +509,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 		goto stop;
 
 	if (ci->is_otg)
-		hw_write(ci, OP_OTGSC, OTGSC_IDIE, OTGSC_IDIE);
+		ci_hdrc_otg_init(ci);
 
 	ret = dbg_create_files(ci);
 	if (!ret)
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
new file mode 100644
index 0000000..abefb4d
--- /dev/null
+++ b/drivers/usb/chipidea/otg.c
@@ -0,0 +1,50 @@
+/*
+ * otg.c - ChipIdea USB IP core OTG driver
+ *
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Peter Chen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * This file mainly handles otgsc register, it may include OTG operation
+ * in the future.
+ */
+
+#include <linux/usb/otg.h>
+#include <linux/usb/gadget.h>
+#include <linux/usb/chipidea.h>
+
+#include "ci.h"
+#include "bits.h"
+
+void ci_clear_otg_interrupt(struct ci_hdrc *ci, u32 bits)
+{
+	/* Only clear request bits */
+	hw_write(ci, OP_OTGSC, OTGSC_INT_STATUS_BITS, bits);
+}
+
+void ci_enable_otg_interrupt(struct ci_hdrc *ci, u32 bits)
+{
+	hw_write(ci, OP_OTGSC, bits, bits);
+}
+
+void ci_disable_otg_interrupt(struct ci_hdrc *ci, u32 bits)
+{
+	hw_write(ci, OP_OTGSC, bits, 0);
+}
+
+/**
+ * ci_hdrc_otg_init - initialize otgsc bits
+ * ci: the controller
+ */
+int ci_hdrc_otg_init(struct ci_hdrc *ci)
+{
+	ci_enable_otg_interrupt(ci, OTGSC_IDIE);
+
+	return 0;
+}
diff --git a/drivers/usb/chipidea/otg.h b/drivers/usb/chipidea/otg.h
new file mode 100644
index 0000000..f24ec37
--- /dev/null
+++ b/drivers/usb/chipidea/otg.h
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Peter Chen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __DRIVERS_USB_CHIPIDEA_OTG_H
+#define __DRIVERS_USB_CHIPIDEA_OTG_H
+
+int ci_hdrc_otg_init(struct ci_hdrc *ci);
+void ci_clear_otg_interrupt(struct ci_hdrc *ci, u32 bits);
+void ci_enable_otg_interrupt(struct ci_hdrc *ci, u32 bits);
+void ci_disable_otg_interrupt(struct ci_hdrc *ci, u32 bits);
+
+#endif /* __DRIVERS_USB_CHIPIDEA_OTG_H */
-- 
1.7.0.4




From peter.chen at freescale.com  Fri Jul 26 05:18:30 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:30 +0800
Subject: [PATCH v13 14/14] usb: chipidea: udc: fix the oops when plugs in usb
 cable after rmmod gadget
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1374830310-21765-15-git-send-email-peter.chen@freescale.com>

When we rmmod gadget, the ci->driver needs to be cleared.
Otherwise, we plug in usb cable again, the driver will
consider gadget is there, in fact, it was removed.

Besides, consolidate the calling of ci->driver->disconnect, when
we do rmmod gadget, the gadget's disconnect should be called from
udc core.

Below is the oops this patch fixes.

root at freescale ~$ ci_hdrc ci_hdrc.0: Connected to host
Unable to handle kernel paging request at virtual address 7f01171c
pgd = 80004000
[7f01171c] *pgd=4fa1e811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] SMP ARM
Modules linked in: f_acm libcomposite u_serial [last unloaded: g_serial]
CPU: 0    Not tainted  (3.8.0-rc5+ #221)
PC is at _gadget_stop_activity+0xbc/0x128
LR is at ep_fifo_flush+0x68/0xa0
pc : [<803634cc>]    lr : [<80363938>]    psr: 20000193
sp : 806c7dc8  ip : 00000000  fp : 806c7de4
r10: 00000000  r9 : 80710ea4  r8 : 00000000
r7 : bf834094  r6 : bf834098  r5 : bf834010  r4 : bf8340a0
r3 : 7f011708  r2 : 01940194  r1 : a0000193  r0 : bf834014
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 4f06404a  DAC: 00000017
Process swapper/0 (pid: 0, stack limit = 0x806c6238)
Stack: (0x806c7dc8 to 0x806c8000)
7dc0:                   bf834010 bf809950 bf834010 0000004b 806c7e44 806c7de8
7de0: 80365400 8036341c 0000ec1c 00000000 0000ec1c 00000040 fff5ede0 bf834014
7e00: 000a1220 00000000 0000002e ffffd958 806c7e3c 806c7e20 8004e870 bf834010
7e20: bf809950 0000004b 0000004b 00000000 80710ea4 00000000 806c7e5c 806c7e48
7e40: 80362888 80365154 bfb35180 bf809950 806c7e9c 806c7e60 8008111c 803627f4
7e60: 00989680 00000000 bf809900 bf809964 812df8c0 bf809900 bf809950 806c3f2c
7e80: 0000004b 00000000 412fc09a 00000000 806c7eb4 806c7ea0 80081368 800810b8
7ea0: bf809900 bf809950 806c7ecc 806c7eb8 800843c8 8008130c 0000004b 806cf748
7ec0: 806c7ee4 806c7ed0 80081088 8008432c 806c6000 806cf748 806c7f0c 806c7ee8
7ee0: 8000fa44 8008105c f400010c 806ce974 806c7f30 f4000110 806d29e8 412fc09a
7f00: 806c7f2c 806c7f10 80008584 8000f9f4 8000fbd0 60000013 ffffffff 806c7f64
7f20: 806c7f84 806c7f30 8000eac0 80008554 00000000 00000000 0000000f 8001aea0
7f40: 806c6000 80712a48 804f0040 00000000 806d29e8 412fc09a 00000000 806c7f84
7f60: 806c7f88 806c7f78 8000fbcc 8000fbd0 60000013 ffffffff 806c7fac 806c7f88
7f80: 8001015c 8000fb9c 806cf5b0 80712980 806a4528 8fffffff 1000406a 412fc09a
7fa0: 806c7fbc 806c7fb0 804e5334 800100ac 806c7ff4 806c7fc0 80668940 804e52d4
7fc0: ffffffff ffffffff 806684bc 00000000 00000000 806a4528 10c53c7d 806ce94c
7fe0: 806a4524 806d29dc 00000000 806c7ff8 10008078 806686b0 00000000 00000000
Backtrace:
[<80363410>] (_gadget_stop_activity+0x0/0x128) from [<80365400>] (udc_irq+0x2b8/0xf38)
 r7:0000004b r6:bf834010 r5:bf809950 r4:bf834010
 [<80365148>] (udc_irq+0x0/0xf38) from [<80362888>] (ci_irq+0xa0/0xf4)
[<803627e8>] (ci_irq+0x0/0xf4) from [<8008111c>] (handle_irq_event_percpu+0x70/0x254)
 r5:bf809950 r4:bfb35180
 [<800810ac>] (handle_irq_event_percpu+0x0/0x254) from [<80081368>] (handle_irq_event+0x68/0x88)
[<80081300>] (handle_irq_event+0x0/0x88) from [<800843c8>] (handle_fasteoi_irq+0xa8/0x178)
 r5:bf809950 r4:bf809900
 [<80084320>] (handle_fasteoi_irq+0x0/0x178) from [<80081088>] (generic_handle_irq+0x38/0x40)
 r5:806cf748 r4:0000004b
 [<80081050>] (generic_handle_irq+0x0/0x40) from [<8000fa44>] (handle_IRQ+0x5c/0xbc)
 r5:806cf748 r4:806c6000
 [<8000f9e8>] (handle_IRQ+0x0/0xbc) from [<80008584>] (gic_handle_irq+0x3c/0x70)
 r9:412fc09a r8:806d29e8 r7:f4000110 r6:806c7f30 r5:806ce974
 r4:f400010c
 [<80008548>] (gic_handle_irq+0x0/0x70) from [<8000eac0>] (__irq_svc+0x40/0x54)
Exception stack(0x806c7f30 to 0x806c7f78)
7f20:                                     00000000 00000000 0000000f 8001aea0
7f40: 806c6000 80712a48 804f0040 00000000 806d29e8 412fc09a 00000000 806c7f84
7f60: 806c7f88 806c7f78 8000fbcc 8000fbd0 60000013 ffffffff
 r7:806c7f64 r6:ffffffff r5:60000013 r4:8000fbd0
 [<8000fb90>] (default_idle+0x0/0x4c) from [<8001015c>] (cpu_idle+0xbc/0xf8)
[<800100a0>] (cpu_idle+0x0/0xf8) from [<804e5334>] (rest_init+0x6c/0x84)
 r9:412fc09a r8:1000406a r7:8fffffff r6:806a4528 r5:80712980
 r4:806cf5b0
 [<804e52c8>] (rest_init+0x0/0x84) from [<80668940>] (start_kernel+0x29c/0x2ec)
[<806686a4>] (start_kernel+0x0/0x2ec) from [<10008078>] (0x10008078)
Code: e12fff33 e5953200 e3530000 0a000002 (e5933014)
---[ end trace aade28ad434062bd ]---
Kernel panic - not syncing: 0xbf8bdfa8)
df60: 00000000 00000000 0000000f 8001aea0 bf8bc000 80712a48 804f0040 00000000
df80: 806d29e8 412fc09a 00000000 bf8bdfb4 bf8bdfb8 bf8bdfa8 8000fbcc 8000fbd0
dfa0: 60000013 ffffffff
 r7:bf8bdf94 r6:ffffffff r5:60000013 r4:8000fbd0
 [<8000fb90>] (default_idle+0x0/0x4c) from [<8001015c>] (cpu_idle+0xbc/0xf8)
[<800100a0>] (cpu_idle+0x0/0xf8) from [<804e7930>] (secondary_start_kernel+0x120/0x148)
 r9:412fc09a r8:1000406a r7:80712d20 r6:10c03c7d r5:00000002
 r4:806e2008
 [<804e7810>] (secondary_start_kernel+0x0/0x148) from [<104e7148>] (0x104e7148)
 r5:0000001f r4:4f8a806a
 CPU3: stopping
 Backtrace:
 [<800132e8>] (dump_backtrace+0x0/0x114) from [<804ea684>] (dump_stack+0x20/0x24)
 r7:00000000 r6:806c3f2c r5:806cf748 r4:80712d18
 [<804ea664>] (dump_stack+0x0/0x24) from [<80014adc>] (handle_IPI+0x140/0x18c)
[<8001499c>] (handle_IPI+0x0/0x18c) from [<800085b0>] (gic_handle_irq+0x68/0x70)
 r9:412fc09a r8:806d29e8 r7:f4000110 r6:bf8bff60 r5:806ce974
 r4:f400010c
 [<80008548>] (gic_handle_irq+0x0/0x70) from [<8000eac0>] (__irq_svc+0x40/0x54)
Exception stack(0xbf8bff60 to 0xbf8bffa8)
ff60: 00000000 00000000 0000000f 8001aea0 bf8be000 80712a48 804f0040 00000000
ff80: 806d29e8 412fc09a 00000000 bf8bffb4 bf8bffb8 bf8bffa8 8000fbcc 8000fbd0
ffa0: 60000013 ffffffff
 r7:bf8bff94 r6:ffffffff r5:60000013 r4:8000fbd0
 [<8000fb90>] (default_idle+0x0/0x4c) from [<8001015c>] (cpu_idle+0xbc/0xf8)
[<800100a0>] (cpu_idle+0x0/0xf8) from [<804e7930>] (secondary_start_kernel+0x120/0x148)
 r9:412fc09a r8:1000406a r7:80712d20 r6:10c03c7d r5:00000003
 r4:806e2008
 [<804e7810>] (secondary_start_kernel+0x0/0x148) from [<104e7148>] (0x104e7148)
 r5:0000001f r4:4f8a806a
 CPU1: stopping
 Backtrace:
 [<800132e8>] (dump_backtrace+0x0/0x114) from [<804ea684>] (dump_stack+0x20/0x24)
 r7:00000000 r6:806c3f2c r5:806cf748 r4:80712d18
 [<804ea664>] (dump_stack+0x0/0x24) from [<80014adc>] (handle_IPI+0x140/0x18c)
[<8001499c>] (handle_IPI+0x0/0x18c) from [<800085b0>] (gic_handle_irq+0x68/0x70)
 r9:412fc09a r8:806d29e8 r7:f4000110 r6:bf8bbf60 r5:806ce974
 r4:f400010c
 [<80008548>] (gic_handle_irq+0x0/0x70) from [<8000eac0>] (__irq_svc+0x40/0x54)
Exception stack(0xbf8bbf60 to 0xbf8bbfa8)
bf60: 00000000 00000000 0000000f 8001aea0 bf8ba000 80712a48 804f0040 00000000
bf80: 806d29e8 412fc09a 00000000 bf8bbfb4 bf8bbfb8 bf8bbfa8 8000fbcc 8000fbd0
bfa0: 60000013 ffffffff
 r7:bf8bbf94 r6:ffffffff r5:60000013 r4:8000fbd0
 [<8000fb90>] (default_idle+0x0/0x4c) from [<8001015c>] (cpu_idle+0xbc/0xf8)
[<800100a0>] (cpu_idle+0x0/0xf8) from [<804e7930>] (secondary_start_kernel+0x120/0x148)
 r9:412fc09a r8:1000406a r7:80712d20 r6:10c03c7d r5:00000001
 r4:806e2008

Tested-by: Marek Vasut <marex at denx.de>
Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/udc.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index b7ead5f..aeabdcf 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -686,9 +686,6 @@ static int _gadget_stop_activity(struct usb_gadget *gadget)
 	usb_ep_fifo_flush(&ci->ep0out->ep);
 	usb_ep_fifo_flush(&ci->ep0in->ep);
 
-	if (ci->driver)
-		ci->driver->disconnect(gadget);
-
 	/* make sure to disable all endpoints */
 	gadget_for_each_ep(ep, gadget) {
 		usb_ep_disable(ep);
@@ -717,6 +714,11 @@ __acquires(ci->lock)
 {
 	int retval;
 
+	if (ci->gadget.speed != USB_SPEED_UNKNOWN) {
+		if (ci->driver)
+			ci->driver->disconnect(&ci->gadget);
+	}
+
 	spin_unlock(&ci->lock);
 	retval = _gadget_stop_activity(&ci->gadget);
 	if (retval)
@@ -1464,6 +1466,8 @@ static int ci_udc_vbus_session(struct usb_gadget *_gadget, int is_active)
 			hw_device_state(ci, ci->ep0out->qh.dma);
 			dev_dbg(ci->dev, "Connected to host\n");
 		} else {
+			if (ci->driver)
+				ci->driver->disconnect(&ci->gadget);
 			hw_device_state(ci, 0);
 			if (ci->platdata->notify_event)
 				ci->platdata->notify_event(ci,
@@ -1674,13 +1678,14 @@ static int ci_udc_stop(struct usb_gadget *gadget,
 		if (ci->platdata->notify_event)
 			ci->platdata->notify_event(ci,
 			CI_HDRC_CONTROLLER_STOPPED_EVENT);
-		ci->driver = NULL;
 		spin_unlock_irqrestore(&ci->lock, flags);
 		_gadget_stop_activity(&ci->gadget);
 		spin_lock_irqsave(&ci->lock, flags);
 		pm_runtime_put(&ci->gadget.dev);
 	}
 
+	ci->driver = NULL;
+
 	spin_unlock_irqrestore(&ci->lock, flags);
 
 	return 0;
-- 
1.7.0.4




From peter.chen at freescale.com  Fri Jul 26 05:18:25 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Fri, 26 Jul 2013 17:18:25 +0800
Subject: [PATCH v13 09/14] usb: chipidea: move otg relate things to otg file
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1374830310-21765-10-git-send-email-peter.chen@freescale.com>

Move otg relate things to otg file.

Tested-by: Marek Vasut <marex at denx.de>
Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/usb/chipidea/core.c |   63 +++++++++----------------------------------
 drivers/usb/chipidea/otg.c  |   57 +++++++++++++++++++++++++++++++++++++-
 drivers/usb/chipidea/otg.h  |    2 +
 3 files changed, 70 insertions(+), 52 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 8884af6..78c4721 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -295,40 +295,6 @@ int hw_device_reset(struct ci_hdrc *ci, u32 mode)
 	return 0;
 }
 
-/**
- * ci_otg_role - pick role based on ID pin state
- * @ci: the controller
- */
-static enum ci_role ci_otg_role(struct ci_hdrc *ci)
-{
-	u32 sts = hw_read(ci, OP_OTGSC, ~0);
-	enum ci_role role = sts & OTGSC_ID
-		? CI_ROLE_GADGET
-		: CI_ROLE_HOST;
-
-	return role;
-}
-
-/**
- * ci_role_work - perform role changing based on ID pin
- * @work: work struct
- */
-static void ci_role_work(struct work_struct *work)
-{
-	struct ci_hdrc *ci = container_of(work, struct ci_hdrc, work);
-	enum ci_role role = ci_otg_role(ci);
-
-	if (role != ci->role) {
-		dev_dbg(ci->dev, "switching from %s to %s\n",
-			ci_role(ci)->name, ci->roles[role]->name);
-
-		ci_role_stop(ci);
-		ci_role_start(ci, role);
-	}
-
-	enable_irq(ci->irq);
-}
-
 static irqreturn_t ci_irq(int irq, void *data)
 {
 	struct ci_hdrc *ci = data;
@@ -409,6 +375,8 @@ static inline void ci_role_destroy(struct ci_hdrc *ci)
 {
 	ci_hdrc_gadget_destroy(ci);
 	ci_hdrc_host_destroy(ci);
+	if (ci->is_otg)
+		ci_hdrc_otg_destory(ci);
 }
 
 static void ci_get_otg_capable(struct ci_hdrc *ci)
@@ -475,13 +443,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	INIT_WORK(&ci->work, ci_role_work);
-	ci->wq = create_singlethread_workqueue("ci_otg");
-	if (!ci->wq) {
-		dev_err(dev, "can't create workqueue\n");
-		return -ENODEV;
-	}
-
 	/* To know if controller is OTG capable or not */
 	ci_get_otg_capable(ci);
 
@@ -510,8 +471,15 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 
 	if (!ci->roles[CI_ROLE_HOST] && !ci->roles[CI_ROLE_GADGET]) {
 		dev_err(dev, "no supported roles\n");
-		ret = -ENODEV;
-		goto rm_wq;
+		return -ENODEV;
+	}
+
+	if (ci->is_otg) {
+		ret = ci_hdrc_otg_init(ci);
+		if (ret) {
+			dev_err(dev, "init otg fails, ret = %d\n", ret);
+			goto stop;
+		}
 	}
 
 	if (ci->roles[CI_ROLE_HOST] && ci->roles[CI_ROLE_GADGET]) {
@@ -522,7 +490,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 			 */
 			mdelay(2);
 			ci->role = ci_otg_role(ci);
-			ci_hdrc_otg_init(ci);
+			ci_enable_otg_interrupt(ci, OTGSC_IDIE);
 		} else {
 			/*
 			 * If the controller is not OTG capable, but support
@@ -541,7 +509,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 	if (ret) {
 		dev_err(dev, "can't start %s role\n", ci_role(ci)->name);
 		ret = -ENODEV;
-		goto rm_wq;
+		goto stop;
 	}
 
 	platform_set_drvdata(pdev, ci);
@@ -557,9 +525,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 	free_irq(ci->irq, ci);
 stop:
 	ci_role_destroy(ci);
-rm_wq:
-	flush_workqueue(ci->wq);
-	destroy_workqueue(ci->wq);
 
 	return ret;
 }
@@ -569,8 +534,6 @@ static int ci_hdrc_remove(struct platform_device *pdev)
 	struct ci_hdrc *ci = platform_get_drvdata(pdev);
 
 	dbg_remove_files(ci);
-	flush_workqueue(ci->wq);
-	destroy_workqueue(ci->wq);
 	free_irq(ci->irq, ci);
 	ci_role_destroy(ci);
 
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index abefb4d..68f2faf 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -39,12 +39,65 @@ void ci_disable_otg_interrupt(struct ci_hdrc *ci, u32 bits)
 }
 
 /**
- * ci_hdrc_otg_init - initialize otgsc bits
+ * ci_otg_role - pick role based on ID pin state
+ * @ci: the controller
+ */
+enum ci_role ci_otg_role(struct ci_hdrc *ci)
+{
+	u32 sts = hw_read(ci, OP_OTGSC, ~0);
+	enum ci_role role = sts & OTGSC_ID
+		? CI_ROLE_GADGET
+		: CI_ROLE_HOST;
+
+	return role;
+}
+
+/**
+ * ci_role_work - perform role changing based on ID pin
+ * @work: work struct
+ */
+static void ci_role_work(struct work_struct *work)
+{
+	struct ci_hdrc *ci = container_of(work, struct ci_hdrc, work);
+	enum ci_role role = ci_otg_role(ci);
+
+	if (role != ci->role) {
+		dev_dbg(ci->dev, "switching from %s to %s\n",
+			ci_role(ci)->name, ci->roles[role]->name);
+
+		ci_role_stop(ci);
+		ci_role_start(ci, role);
+	}
+
+	enable_irq(ci->irq);
+}
+
+/**
+ * ci_hdrc_otg_init - initialize otg struct
  * ci: the controller
  */
 int ci_hdrc_otg_init(struct ci_hdrc *ci)
 {
-	ci_enable_otg_interrupt(ci, OTGSC_IDIE);
+	INIT_WORK(&ci->work, ci_role_work);
+	ci->wq = create_singlethread_workqueue("ci_otg");
+	if (!ci->wq) {
+		dev_err(ci->dev, "can't create workqueue\n");
+		return -ENODEV;
+	}
 
 	return 0;
 }
+
+/**
+ * ci_hdrc_otg_destroy - destory otg struct
+ * ci: the controller
+ */
+void ci_hdrc_otg_destory(struct ci_hdrc *ci)
+{
+	if (ci->wq) {
+		flush_workqueue(ci->wq);
+		destroy_workqueue(ci->wq);
+	}
+	ci_disable_otg_interrupt(ci, OTGSC_INT_EN_BITS);
+	ci_clear_otg_interrupt(ci, OTGSC_INT_STATUS_BITS);
+}
diff --git a/drivers/usb/chipidea/otg.h b/drivers/usb/chipidea/otg.h
index f24ec37..8913062 100644
--- a/drivers/usb/chipidea/otg.h
+++ b/drivers/usb/chipidea/otg.h
@@ -15,5 +15,7 @@ int ci_hdrc_otg_init(struct ci_hdrc *ci);
 void ci_clear_otg_interrupt(struct ci_hdrc *ci, u32 bits);
 void ci_enable_otg_interrupt(struct ci_hdrc *ci, u32 bits);
 void ci_disable_otg_interrupt(struct ci_hdrc *ci, u32 bits);
+void ci_hdrc_otg_destory(struct ci_hdrc *ci);
+enum ci_role ci_otg_role(struct ci_hdrc *ci);
 
 #endif /* __DRIVERS_USB_CHIPIDEA_OTG_H */
-- 
1.7.0.4




From christian.ruppert at abilis.com  Fri Jul 26 05:26:01 2013
From: christian.ruppert at abilis.com (Christian Ruppert)
Date: Fri, 26 Jul 2013 11:26:01 +0200
Subject: Issue with gpio and pinmux
In-Reply-To: <CACRpkdZdbxEt67+YBKif4-BKAToOmN0_c8HFOdjSG91dtJwJQw@mail.gmail.com>
References: <51E667BC.3070804@parrot.com> <51E82FBB.1080905@wwwdotorg.org>
 <CACRpkdb1n07KoQZSme1EMJfV-9pHr-kd_1eJ6HsBV5gz7Dh3Ww@mail.gmail.com>
 <51EB590A.4010600@wwwdotorg.org>
 <CACRpkdZdbxEt67+YBKif4-BKAToOmN0_c8HFOdjSG91dtJwJQw@mail.gmail.com>
Message-ID: <20130726092601.GA1909@ab42.lan>

On Thu, Jul 25, 2013 at 11:37:52AM +0200, Linus Walleij wrote:
> On Sun, Jul 21, 2013 at 5:44 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> 
> > Actually, a better way to do (c) might be to just add an extra "op" to
> > struct pinmux_ops; something like validate_gpio_mux(), passing in
> > information such as whether a mux function is in effect on that pin,
> > whether the pin is already claimed as a GPIO, and whether the function
> > is being called to check a GPIO-claim or mux-claim operation . If the op
> > is missing, no "dual claim" is allowed. If the op is present, the code
> > in the op validates whether the particular GPIO is allowed to be claimed
> > while the particular mux function is active.
> >
> > That way, I think any driver that doesn't want to allow dual-claim
> > doesn't have to do anything, but the few drivers that do can code up
> > whatever algorithm they want; for Tegra, I'd just allow everything for
> > simplicity, but we could always enhance that later if we want.
> 
> You are right, this would be an elegant solution.
> 
> Christian, are you interested in coding this up?

When thinking about it, we require the same mechanism the other way
round: If a GPIO is claimed first we need a mechanism to forbid
incompatible reconfiguration of other functionalities until that GPIO is
free again.

I like Stephen's proposal (in another mail) to claim GPIOs from the
pinctrl drivers but instead of modifying the callback prototypes I
suggest to add the following functions:

/*
 * Claim GPIO pin (in the sense: forbid acutal GPIO usage)
 */
int claim_gpios(struct pinctrl_dev *pctl, unsigned *pins
                unsigned port_selector, unsigned func_selector);

/* allow GPIO usage of the given pins */
void unclaim_gpios(struct pinctrl_dev *pctl, unsigned *pins);

Claiming could be fully dynamic. This way, driver authors don't need to
implement additional callbacks or modify their existing ones. In the
simplest case they do nothing. The entire conflict-checking logic is
confined inside the core.

Alternatively, a similar set of functions could make the use of GPIOs
exclusive with other functions for a given set of pins. This would work
very well with the proposal below and would be easier to manage for most
driver authors: The configuration would be static in most cases.
(We just have to discuss about the default mode, do we want to keep the
backward-compatible inclusive default or change everything to exclusive
by default?).

A last point I would like to address before passing on to implementation
is to introduce the notion of interfaces: I think it is important to
introduce some orthogonality between unrelated interfaces which happen
to be muxed on the same port and ideally we implement this coherently
with the above.

I would like to know your opinion if the following proposal is generic
enough or if it encodes too much chip-specific logic into the core:

- We extend the notion of pin groups to represent either ports (as it is
  currently the case) or interfaces. No need to use name pin groups in
  both cases, I'm open to proposals for better terminology.
- Functions are associated either to one port or a set of interfaces.
- Functions continue to apply to an entire port but they only claim the
  pins of the interfaces they are associated with.
- A client can request either a function or an interface from the
  pinctrl core. In the second case, the core will figure out if the
  request is coherent with previous requests (i.e. if there is a
  function providing all requested interfaces) and call the driver
  accordingly.

We'll have to figure out a few details but I would like to have an
agreement on fundamentals before spending time on implementation.

Greetings,
  Christian

-- 
  Christian Ruppert              ,          <christian.ruppert at abilis.com>
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates


From christian.ruppert at abilis.com  Fri Jul 26 05:26:00 2013
From: christian.ruppert at abilis.com (Christian Ruppert)
Date: Fri, 26 Jul 2013 11:26:00 +0200
Subject: Issue with gpio and pinmux
In-Reply-To: <51EEA58A.30206@wwwdotorg.org>
References: <51E667BC.3070804@parrot.com> <51E82FBB.1080905@wwwdotorg.org>
 <CACRpkdb1n07KoQZSme1EMJfV-9pHr-kd_1eJ6HsBV5gz7Dh3Ww@mail.gmail.com>
 <51EB590A.4010600@wwwdotorg.org> <20130722083535.GA19685@ab42.lan>
 <51EEA58A.30206@wwwdotorg.org>
Message-ID: <20130726092559.GB7207@ab42.lan>

On Tue, Jul 23, 2013 at 08:47:22AM -0700, Stephen Warren wrote:
> On 07/22/2013 01:35 AM, Christian Ruppert wrote:
> > On Sat, Jul 20, 2013 at 09:44:10PM -0600, Stephen Warren wrote:
> >> On 07/20/2013 04:44 PM, Linus Walleij wrote:
> > [...]
> > [ An introductory note on terminology: in the following, "port" refers
> > to a set of pins who's mux is controlled through the same bit field in
> > the same register,
> 
> I believe that's exactly what a "pingroup" is in pinctrl subsystem
> terminology. Where there is already an existing name for something, it'd
> be best to use that so that every person doesn't use a different name
> for everything.

Actually, I use this terminology because in my head a pingroup is "just"
an abstract data structure (i.e. a named list of pins). I think one of
our points of discussion is if this data structure should be used only
to represent what I call ports or if it can also represent things like
interfaces, gpio-ranges etc. Thus, we need a terminology to talk about
the "physical equivalents"...

> > "interface" refers to the set of pins comprising a
> > functional unit, e.g. SCL and SDA of an I2C interface or the four pins
> > of an SPI interface ]
> > 
> > In my understanding, the problem stems from the fact that we always
> > claim an entire port instead of just the pins required for a given
> > functionality.
> 
> Yes.
> 
> > The pinctrl core is already well equipped to manage
> > claiming interfaces instead of ports and thus a fourth alternative would
> > be to
> 
> I would argue that's not the case. pinctrl knows absolutely nothing
> about "interfaces"; there is no data structure defines that describes
> interfaces at all.

Well, pin groups are perfectly capable of representing interfaces
instead of ports (see my remark above).

> That's not saying such a thing could not be added; I'm simply arguing
> that "well equipped" doesn't seem to be true at the moment.

Intuitively, I would implement this by adding a second level of
semantics on top of pin groups (at the same level as the "functions" we
already have).

Alternatively, one could add the notion of interfaces to functions (a
function provides one or more interfaces) but I'm a bit afraid that this
encodes tb10x-specific logic into the core...

> > d) implement gpio/pin conflict management in the already existing
> > callbacks inside the driver: Today, both enable and gpio_request_enable
> > exist (and can refuse a request for a configuration/pin).
> > If we only claim the pins used by a given interface instead of the
> > entire port, conflict management becomes natural (see
> > http://lkml.indiana.edu/hypermail/linux/kernel/1306.2/00749.html and the
> > following).
> 
> OK, that's basically the same as my proposal to add a new callback; it's
> simply re-using and existing driver callback rather than creating a new
> one solely for conflict checking.
> 
> Re-using the existing callback(s) seems fine, with appropriate prototype
> modification to pass back the list of pins that can-or-can't be
> dual-claimed I suppose.

I like this proposal but I would rather add a set of functions to the
core than modifying the prototype (more details in a separate email in
response to LinusW).

> > IMHO, the pinctrl drivers are the right place for everything but the
> > most basic pin conflict management since constraints on what can be
> > muxed at the same time are highly hardware implementation dependent. One
> > could e.g. imagine an implementation where a GPIO can override and snoop
> > a pin's output value in one mux configuration, just snoop the pin value
> > in another and do neither in a third.
> > 
> > I see two (independent) ways to enhance the pinctrl core in order to
> > support drivers in this task:
> > a) Add two functions pin_is_claimed and gpio_is_claimed which allow the
> > pinctrl driver to query if a given pin/gpio is available for muxing.
> > b) Add four functions lock_gpio/unlock_gpio and lock_pin/unlock_pin
> > which allow the pinctrl driver to prevent the core from granting
> > requests on GPIOs/pins.
> 
> Yes, either of those are basically what I proposed in my followup to the
> email you're replying to.

Actually what I was thinking of was the inverse of your suggestion: In
your suggestion the *_is_claimed functions were part of each driver, in
mine they were part of the core.

Greetings,
  Christian

-- 
  Christian Ruppert              ,          <christian.ruppert at abilis.com>
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates


From dwmw2 at infradead.org  Fri Jul 26 05:42:24 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 26 Jul 2013 10:42:24 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726080115.GA5436@netboy>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
Message-ID: <1374831744.2923.42.camel@shinybook.infradead.org>

On Fri, 2013-07-26 at 10:01 +0200, Richard Cochran wrote:
> On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
> > 
> > We use DT has a kernel configuration input. Our environment is
> > designed to guarantee 100% that the kernel and DT match exactly. DT
> > very deliberately isn't an ABI boundary in our systems.
> 
> Think about what you just said.
> 
> The DT describes the *hardware* not the kernel. Why should you ever
> need to update your DT at all?

Well, the nodes which describe hardware devices, according to the
bindings which form an ABI contract between DT and drivers, should not
normally change. Although they *can* change, if for example you change
the MAC address and that's stored there. Or you change the PHY you want
it to use. Or something like that. The *ABI* doesn't change, but the
data you express *using* that ABI can change. That's kind of the point.

And the nodes in /chosen aren't describing hardware at all. Those are
*absolutely* expected to be configuration things. It's quite normal for
those to vary from one boot to the next, if your bootloader is
sophisticated enough to do that.

And if Jason wants to hard-code that kind of configuration data into his
device-tree and ship it as part of the overall system image that gets
installed, I see no particular problem with that.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/b2ffc9da/attachment.bin>

From laurent.pinchart at ideasonboard.com  Fri Jul 26 05:51:51 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 11:51:51 +0200
Subject: [PATCH 01/12] mmc: mmc_spi: Support CD/RO GPIOs
In-Reply-To: <51F1C165.6040600@gmail.com>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <3057612.zXvbbdByqU@avalon> <51F1C165.6040600@gmail.com>
Message-ID: <1734001.ZxAa9p5J8y@avalon>

Hi Ryan,

On Friday 26 July 2013 10:23:01 Ryan Mallon wrote:
> On 26/07/13 10:04, Laurent Pinchart wrote:
> > On Friday 26 July 2013 09:45:26 Ryan Mallon wrote:
> >> On 26/07/13 09:26, Laurent Pinchart wrote:
> >>> Add support for passing CD/RO GPIO numbers directly to the mmc_spi
> >>> driver instead of relying solely on board code callbacks to retrieve the
> >>> CD/RO signals values.
> >>> 
> >>> Signed-off-by: Laurent Pinchart
> >>> <laurent.pinchart+renesas at ideasonboard.com>
> >>> ---
> >>> 
> >>>  drivers/mmc/host/mmc_spi.c    | 32 +++++++++++++++++++++---------
> >>>  drivers/mmc/host/of_mmc_spi.c | 46 ++++++++++--------------------------
> >>>  include/linux/spi/mmc_spi.h   | 11 +++++++++++
> >>>  3 files changed, 46 insertions(+), 43 deletions(-)
> >>> 
> >>> diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
> >>> index 74145d1..4e83908 100644
> >>> --- a/drivers/mmc/host/mmc_spi.c
> >>> +++ b/drivers/mmc/host/mmc_spi.c
> >>> @@ -36,6 +36,7 @@
> >>> 
> >>>  #include <linux/mmc/host.h>
> >>>  #include <linux/mmc/mmc.h>		/* for R1_SPI_* bit values */
> >>> +#include <linux/mmc/slot-gpio.h>
> >>>  #include <linux/spi/spi.h>
> >>>  #include <linux/spi/mmc_spi.h>
> >>> 
> >>> @@ -1278,11 +1279,8 @@ static int mmc_spi_get_ro(struct mmc_host *mmc)
> >>>  	if (host->pdata && host->pdata->get_ro)
> >>>  		return !!host->pdata->get_ro(mmc->parent);
> >>> 
> >>> -	/*
> >>> -	 * Board doesn't support read only detection; let the mmc core
> >>> -	 * decide what to do.
> >>> -	 */
> >>> -	return -ENOSYS;
> >>> +	else
> >>> +		return mmc_gpio_get_ro(mmc);
> >> 
> >> Why not just have the board file assign mmc_gpio_get_ro as
> >> host->pdata->get_ro? This would eliminate the need for the
> >> MMC_SPI_USE_RO_GPIO flag.
> > 
> > Because the idea is to get rid of board callbacks and rely on proper
> > kernel abstraction layers such as the GPIO subsystem. This will be
> > especially important when adding device tree support to the mmc_spi
> > driver.
> > 
> >> Also, if host->pdata->get_ro is not set then this will assume
> >> mmc_gpio_get_ro is valid, even if MMC_SPI_USE_RO_GPIO is not set. I'm
> >> guessing it will end up returning -ENOSYS, but they way the code reads is
> >> that if the host doesn't have get_ro function set, then it is must be a
> >> gpio.
> > 
> > mmc_gpio_get_ro() will indeed return -ENOSYS when the MMC_SPI_USE_RO_GPIO
> > flag isn't set, as the mmc_spi driver will not call mmc_gpio_request_ro()
> > in that case.
> > 
> > This patch hides the -ENOSYS value from the mmc_spi_get_ro() and
> > mmc_spi_get_cd() functions, perhaps making them slightly confusing, but
> > patch 06/12 then gets rid of those functions, so I don't think it's a bit
> > issue.
>
> Ah, I didn't read far enough along in the patch series :-). So all mmc spi
> ro/cd controls are now assumed to be gpios?

That's correct. It's the case in practice for all the boards we support in 
mainline. If the situation changes in the future for a new board (hardware 
engineers tend to have strange design ideas sometimes) a custom GPIO driver 
might be needed (for FPGA/CPLD-controlled GPIOs for instance).

-- 
Regards,

Laurent Pinchart



From laurent.pinchart at ideasonboard.com  Fri Jul 26 05:54:37 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 26 Jul 2013 11:54:37 +0200
Subject: [PATCH 02/12] ARM: ep93xx: vision_ep9307: Use MMC CD and RO GPIO
In-Reply-To: <ADE657CA350FB648AAC2C43247A983F0021DAC5C20AC@AUSP01VMBX24.collaborationhost.net>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1374794808-21890-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <ADE657CA350FB648AAC2C43247A983F0021DAC5C20AC@AUSP01VMBX24.collaborationhost.net>
Message-ID: <1818634.2aPQusYJQq@avalon>

Hi Hartley,

On Thursday 25 July 2013 19:19:52 H Hartley Sweeten wrote:
> On Thursday, July 25, 2013 4:27 PM, Laurent Pinchart wrote:
> > Pass the CD and RO GPIO numbers to the MMC SPI driver and remove the
> > custom .get_cd() and .get_ro() callback functions.
> > 
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas at ideasonboard.com>
> > ---
> > 
> >  arch/arm/mach-ep93xx/vision_ep9307.c | 56  +++---------------------------
> >  1 file changed, 4 insertions(+), 52 deletions(-)
> > 
> > diff --git a/arch/arm/mach-ep93xx/vision_ep9307.c
> > b/arch/arm/mach-ep93xx/vision_ep9307.c index 605956f..ab94dc5 100644
> > --- a/arch/arm/mach-ep93xx/vision_ep9307.c
> > +++ b/arch/arm/mach-ep93xx/vision_ep9307.c
> > @@ -224,62 +224,14 @@ static struct ep93xx_spi_chip_ops
> > vision_spi_flash_hw = {> 
> >  #define VISION_SPI_MMC_WP	EP93XX_GPIO_LINE_F(0)
> >  #define VISION_SPI_MMC_CD	EP93XX_GPIO_LINE_EGPIO15
> > 
> > -static struct gpio vision_spi_mmc_gpios[] = {
> > -	{ VISION_SPI_MMC_WP, GPIOF_DIR_IN, "mmc_spi:wp" },
> > -	{ VISION_SPI_MMC_CD, GPIOF_DIR_IN, "mmc_spi:cd" },
> > -};
> > -
> > -static int vision_spi_mmc_init(struct device *pdev,
> > -			irqreturn_t (*func)(int, void *), void *pdata)
> > -{
> > -	int err;
> > -
> > -	err = gpio_request_array(vision_spi_mmc_gpios,
> > -				 ARRAY_SIZE(vision_spi_mmc_gpios));
> > -	if (err)
> > -		return err;
> > -
> > -	err = gpio_set_debounce(VISION_SPI_MMC_CD, 1);
> > -	if (err)
> > -		goto exit_err;
> 
> I tested this and it _kind_ of works.
> 
> The card detect is a bit flaky due to the gpio interrupt debounce not being
> enabled.
> 
> The only way I can see to fix this is add the following to this patch:
> 
> @@ -233,8 +233,31 @@ static struct mmc_spi_platform_data vision_spi_mmc_data
> = { .caps2          = MMC_CAP2_RO_ACTIVE_HIGH,
>  };
> 
> +static int vision_spi_mmc_enable_cd_debounce(struct spi_device *spi)
> +{
> +       int ret;
> +
> +       ret = gpio_request_one(VISION_SPI_MMC_CD, GPIOF_DIR_IN,
> spi->modalias);
> +       if (ret)
> +               return ret;
> +
> +       ret = gpio_set_debounce(VISION_SPI_MMC_CD, 1);
> +       if (ret)
> +               return ret;
> +
> +       gpio_free(VISION_SPI_MMC_CD);
> +
> +       return 0;
> +}
> +
>  static int vision_spi_mmc_hw_setup(struct spi_device *spi)
>  {
> +       int ret;
> +
> +       ret = vision_spi_mmc_enable_cd_debounce(spi);
> +       if (ret)
> +               return ret;
> +
>         return gpio_request_one(VISION_SPI_MMC_CS, GPIOF_INIT_HIGH,
>                                 spi->modalias);
>  }

What about extending the mmc_spi and MMC core with GPIO debounce support ? The 
mmc_spi driver would get a new cd_gpio_debounce field, which would be passed 
to mmc_gpio_request_cd(). I can cook up a patch.

-- 
Regards,

Laurent Pinchart



From tushar.behera at linaro.org  Fri Jul 26 05:56:06 2013
From: tushar.behera at linaro.org (Tushar Behera)
Date: Fri, 26 Jul 2013 15:26:06 +0530
Subject: XCLKOUT in exynos5250 clock driver
In-Reply-To: <20130725145158.GI9858@sirena.org.uk>
References: <20130725145158.GI9858@sirena.org.uk>
Message-ID: <51F247B6.9010902@linaro.org>

On 07/25/2013 08:21 PM, Mark Brown wrote:
> I appear to be missing something in the clock driver for the exynos5250.
> I'm looking at the Arndale schematic and I see that the audio master
> clock is connected to XCLKOUT on the SoC.  However I can't see any
> reference to XCLKOUT or anything similar in the clock driver or any of
> the DTS files - where is this clock exposed by the clock driver?
> 
> Unfortunately I haven't been able to get access to the datasheet for the
> part so I can't check this myself.
> 

Information as per Exynos5250 user manual:
"XCLKOUT is an output pin for debugging clocks. Exynos5250 has a CLKOUT
logic which can select one of the clocks (within its clock domains) and
output that through XCLKOUT pin."

Not sure if XCLKOUT on Arndale schematics means the same.

-- 
Tushar Behera


From haojian.zhuang at gmail.com  Fri Jul 26 06:05:22 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 26 Jul 2013 18:05:22 +0800
Subject: No subject
Message-ID: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>

Changelog:
v6:
1. Merge clk apbc & apbcp together.
2. Add DT binding document of clock driver.
3. Remove marvell string in properties of clock driver.

v5:
1. Use clk mux table.

v4:
1. Remove .init_irq in mmp & mmp2 DT machine descriptor.
2. Use an argument to replace TIMER_PHYS_BASE. Now transfer virtual
address directly.
3. Merge 10th & 11th patches together. Remove the redundant changes
on drivers/clocksource/Kconfig & drivers/clocksource/Makefile.

v3:
1. Don't use include/linux/irqchip/mmp.h since we don't need to
move <mach/irqs.h> to <include/linux/irqchip/mmp.h>.
2. Move timer-mmp driver into clocksource directory & support
clocksource.
3. Support clksrc in mmp & parse all clock from DTS.

v2:
1. Avoid to include <mach/irqs.h>. Move the head file into
   include/linux/irqchip directory.
2. Avoid to include <mach/pm-pxa910.h> & <mach/pm-mmp2.h>.



From haojian.zhuang at gmail.com  Fri Jul 26 06:05:23 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 26 Jul 2013 18:05:23 +0800
Subject: [PATCH v6 01/11] irqchip: move mmp irq driver
In-Reply-To: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
References: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
Message-ID: <1374833133-21119-2-git-send-email-haojian.zhuang@gmail.com>

Move irq-mmp driver from mach-mmp directory into irqchip directory.

Signed-off-by: Haojian Zhuang <haojian.zhuang at gmail.com>
---
 arch/arm/mach-mmp/Makefile                           | 2 +-
 arch/arm/mach-mmp/common.h                           | 1 -
 arch/arm/mach-mmp/include/mach/pxa168.h              | 1 +
 arch/arm/mach-mmp/include/mach/pxa910.h              | 1 +
 arch/arm/mach-mmp/pxa910.c                           | 1 +
 drivers/irqchip/Makefile                             | 1 +
 arch/arm/mach-mmp/irq.c => drivers/irqchip/irq-mmp.c | 2 --
 7 files changed, 5 insertions(+), 4 deletions(-)
 rename arch/arm/mach-mmp/irq.c => drivers/irqchip/irq-mmp.c (99%)

diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
index 095c155..9b702a1 100644
--- a/arch/arm/mach-mmp/Makefile
+++ b/arch/arm/mach-mmp/Makefile
@@ -2,7 +2,7 @@
 # Makefile for Marvell's PXA168 processors line
 #
 
-obj-y				+= common.o devices.o time.o irq.o
+obj-y				+= common.o devices.o time.o
 
 # SoC support
 obj-$(CONFIG_CPU_PXA168)	+= pxa168.o
diff --git a/arch/arm/mach-mmp/common.h b/arch/arm/mach-mmp/common.h
index 991d7e9..cf445ba 100644
--- a/arch/arm/mach-mmp/common.h
+++ b/arch/arm/mach-mmp/common.h
@@ -3,7 +3,6 @@
 
 extern void timer_init(int irq);
 
-extern void __init icu_init_irq(void);
 extern void __init mmp_map_io(void);
 extern void mmp_restart(enum reboot_mode, const char *);
 extern void __init pxa168_clk_init(void);
diff --git a/arch/arm/mach-mmp/include/mach/pxa168.h b/arch/arm/mach-mmp/include/mach/pxa168.h
index 459c2d0..a83ba7c 100644
--- a/arch/arm/mach-mmp/include/mach/pxa168.h
+++ b/arch/arm/mach-mmp/include/mach/pxa168.h
@@ -4,6 +4,7 @@
 #include <linux/reboot.h>
 
 extern void pxa168_timer_init(void);
+extern void __init icu_init_irq(void);
 extern void __init pxa168_init_irq(void);
 extern void pxa168_restart(enum reboot_mode, const char *);
 extern void pxa168_clear_keypad_wakeup(void);
diff --git a/arch/arm/mach-mmp/include/mach/pxa910.h b/arch/arm/mach-mmp/include/mach/pxa910.h
index b914afa..9225320 100644
--- a/arch/arm/mach-mmp/include/mach/pxa910.h
+++ b/arch/arm/mach-mmp/include/mach/pxa910.h
@@ -2,6 +2,7 @@
 #define __ASM_MACH_PXA910_H
 
 extern void pxa910_timer_init(void);
+extern void __init icu_init_irq(void);
 extern void __init pxa910_init_irq(void);
 
 #include <linux/i2c.h>
diff --git a/arch/arm/mach-mmp/pxa910.c b/arch/arm/mach-mmp/pxa910.c
index ce6393a..a586742 100644
--- a/arch/arm/mach-mmp/pxa910.c
+++ b/arch/arm/mach-mmp/pxa910.c
@@ -23,6 +23,7 @@
 #include <mach/dma.h>
 #include <mach/mfp.h>
 #include <mach/devices.h>
+#include <mach/pxa910.h>
 
 #include "common.h"
 
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index e65c41a..c452943 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_IRQCHIP)			+= irqchip.o
 
 obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2835.o
 obj-$(CONFIG_ARCH_EXYNOS)		+= exynos-combiner.o
+obj-$(CONFIG_ARCH_MMP)			+= irq-mmp.o
 obj-$(CONFIG_ARCH_MVEBU)		+= irq-armada-370-xp.o
 obj-$(CONFIG_ARCH_MXS)			+= irq-mxs.o
 obj-$(CONFIG_ARCH_S3C24XX)		+= irq-s3c24xx.o
diff --git a/arch/arm/mach-mmp/irq.c b/drivers/irqchip/irq-mmp.c
similarity index 99%
rename from arch/arm/mach-mmp/irq.c
rename to drivers/irqchip/irq-mmp.c
index 3c71246..dab6def 100644
--- a/arch/arm/mach-mmp/irq.c
+++ b/drivers/irqchip/irq-mmp.c
@@ -30,8 +30,6 @@
 #include <mach/pm-pxa910.h>
 #endif
 
-#include "common.h"
-
 #define MAX_ICU_NR		16
 
 struct icu_chip_data {
-- 
1.8.1.2



From haojian.zhuang at gmail.com  Fri Jul 26 06:05:24 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 26 Jul 2013 18:05:24 +0800
Subject: [PATCH v6 02/11] irqchip: mmp: support irqchip
In-Reply-To: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
References: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
Message-ID: <1374833133-21119-3-git-send-email-haojian.zhuang@gmail.com>

Support IRQCHIP on irq-mmp driver.

Signed-off-by: Haojian Zhuang <haojian.zhuang at gmail.com>
---
 arch/arm/mach-mmp/mmp-dt.c  |   8 +-
 arch/arm/mach-mmp/mmp2-dt.c |   8 +-
 drivers/irqchip/irq-mmp.c   | 238 +++++++++++++++++++++++---------------------
 3 files changed, 126 insertions(+), 128 deletions(-)

diff --git a/arch/arm/mach-mmp/mmp-dt.c b/arch/arm/mach-mmp/mmp-dt.c
index b37915d..cca529c 100644
--- a/arch/arm/mach-mmp/mmp-dt.c
+++ b/arch/arm/mach-mmp/mmp-dt.c
@@ -9,17 +9,13 @@
  *  publishhed by the Free Software Foundation.
  */
 
-#include <linux/irq.h>
-#include <linux/irqdomain.h>
-#include <linux/of_irq.h>
+#include <linux/irqchip.h>
 #include <linux/of_platform.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
-#include <mach/irqs.h>
 
 #include "common.h"
 
-extern void __init mmp_dt_irq_init(void);
 extern void __init mmp_dt_init_timer(void);
 
 static const struct of_dev_auxdata pxa168_auxdata_lookup[] __initconst = {
@@ -64,7 +60,6 @@ static const char *mmp_dt_board_compat[] __initdata = {
 
 DT_MACHINE_START(PXA168_DT, "Marvell PXA168 (Device Tree Support)")
 	.map_io		= mmp_map_io,
-	.init_irq	= mmp_dt_irq_init,
 	.init_time	= mmp_dt_init_timer,
 	.init_machine	= pxa168_dt_init,
 	.dt_compat	= mmp_dt_board_compat,
@@ -72,7 +67,6 @@ MACHINE_END
 
 DT_MACHINE_START(PXA910_DT, "Marvell PXA910 (Device Tree Support)")
 	.map_io		= mmp_map_io,
-	.init_irq	= mmp_dt_irq_init,
 	.init_time	= mmp_dt_init_timer,
 	.init_machine	= pxa910_dt_init,
 	.dt_compat	= mmp_dt_board_compat,
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index 4ac2567..023cb45 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -10,18 +10,13 @@
  */
 
 #include <linux/io.h>
-#include <linux/irq.h>
-#include <linux/irqdomain.h>
-#include <linux/of_irq.h>
+#include <linux/irqchip.h>
 #include <linux/of_platform.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
-#include <mach/irqs.h>
-#include <mach/regs-apbc.h>
 
 #include "common.h"
 
-extern void __init mmp_dt_irq_init(void);
 extern void __init mmp_dt_init_timer(void);
 
 static const struct of_dev_auxdata mmp2_auxdata_lookup[] __initconst = {
@@ -49,7 +44,6 @@ static const char *mmp2_dt_board_compat[] __initdata = {
 
 DT_MACHINE_START(MMP2_DT, "Marvell MMP2 (Device Tree Support)")
 	.map_io		= mmp_map_io,
-	.init_irq	= mmp_dt_irq_init,
 	.init_time	= mmp_dt_init_timer,
 	.init_machine	= mmp2_dt_init,
 	.dt_compat	= mmp2_dt_board_compat,
diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c
index dab6def..275709b 100644
--- a/drivers/irqchip/irq-mmp.c
+++ b/drivers/irqchip/irq-mmp.c
@@ -30,6 +30,8 @@
 #include <mach/pm-pxa910.h>
 #endif
 
+#include "irqchip.h"
+
 #define MAX_ICU_NR		16
 
 struct icu_chip_data {
@@ -324,138 +326,146 @@ void __init mmp2_init_icu(void)
 }
 
 #ifdef CONFIG_OF
-static const struct of_device_id intc_ids[] __initconst = {
-	{ .compatible = "mrvl,mmp-intc", .data = &mmp_conf },
-	{ .compatible = "mrvl,mmp2-intc", .data = &mmp2_conf },
-	{}
-};
-
-static const struct of_device_id mmp_mux_irq_match[] __initconst = {
-	{ .compatible = "mrvl,mmp2-mux-intc" },
-	{}
-};
-
-int __init mmp2_mux_init(struct device_node *parent)
+static int __init mmp_init_bases(struct device_node *node)
 {
-	struct device_node *node;
-	const struct of_device_id *of_id;
-	struct resource res;
-	int i, irq_base, ret, irq;
-	u32 nr_irqs, mfp_irq;
+	int ret, nr_irqs, irq, i = 0;
 
-	node = parent;
-	max_icu_nr = 1;
-	for (i = 1; i < MAX_ICU_NR; i++) {
-		node = of_find_matching_node(node, mmp_mux_irq_match);
-		if (!node)
-			break;
-		of_id = of_match_node(&mmp_mux_irq_match[0], node);
-		ret = of_property_read_u32(node, "mrvl,intc-nr-irqs",
-					   &nr_irqs);
-		if (ret) {
-			pr_err("Not found mrvl,intc-nr-irqs property\n");
-			ret = -EINVAL;
-			goto err;
-		}
-		ret = of_address_to_resource(node, 0, &res);
-		if (ret < 0) {
-			pr_err("Not found reg property\n");
-			ret = -EINVAL;
-			goto err;
-		}
-		icu_data[i].reg_status = mmp_icu_base + res.start;
-		ret = of_address_to_resource(node, 1, &res);
-		if (ret < 0) {
-			pr_err("Not found reg property\n");
-			ret = -EINVAL;
-			goto err;
-		}
-		icu_data[i].reg_mask = mmp_icu_base + res.start;
-		icu_data[i].cascade_irq = irq_of_parse_and_map(node, 0);
-		if (!icu_data[i].cascade_irq) {
-			ret = -EINVAL;
-			goto err;
-		}
+	ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", &nr_irqs);
+	if (ret) {
+		pr_err("Not found mrvl,intc-nr-irqs property\n");
+		return ret;
+	}
 
-		irq_base = irq_alloc_descs(-1, 0, nr_irqs, 0);
-		if (irq_base < 0) {
-			pr_err("Failed to allocate IRQ numbers for mux intc\n");
-			ret = irq_base;
+	mmp_icu_base = of_iomap(node, 0);
+	if (!mmp_icu_base) {
+		pr_err("Failed to get interrupt controller register\n");
+		return -ENOMEM;
+	}
+
+	icu_data[0].virq_base = 0;
+	icu_data[0].domain = irq_domain_add_linear(node, nr_irqs,
+						   &mmp_irq_domain_ops,
+						   &icu_data[0]);
+	for (irq = 0; irq < nr_irqs; irq++) {
+		ret = irq_create_mapping(icu_data[0].domain, irq);
+		if (!ret) {
+			pr_err("Failed to mapping hwirq\n");
 			goto err;
 		}
-		if (!of_property_read_u32(node, "mrvl,clr-mfp-irq",
-					  &mfp_irq)) {
-			icu_data[i].clr_mfp_irq_base = irq_base;
-			icu_data[i].clr_mfp_hwirq = mfp_irq;
-		}
-		irq_set_chained_handler(icu_data[i].cascade_irq,
-					icu_mux_irq_demux);
-		icu_data[i].nr_irqs = nr_irqs;
-		icu_data[i].virq_base = irq_base;
-		icu_data[i].domain = irq_domain_add_legacy(node, nr_irqs,
-							   irq_base, 0,
-							   &mmp_irq_domain_ops,
-							   &icu_data[i]);
-		for (irq = irq_base; irq < irq_base + nr_irqs; irq++)
-			icu_mask_irq(irq_get_irq_data(irq));
+		if (!irq)
+			icu_data[0].virq_base = ret;
 	}
-	max_icu_nr = i;
+	icu_data[0].nr_irqs = nr_irqs;
 	return 0;
 err:
-	of_node_put(node);
-	max_icu_nr = i;
-	return ret;
+	if (icu_data[0].virq_base) {
+		for (i = 0; i < irq; i++)
+			irq_dispose_mapping(icu_data[0].virq_base + i);
+	}
+	irq_domain_remove(icu_data[0].domain);
+	iounmap(mmp_icu_base);
+	return -EINVAL;
 }
 
-void __init mmp_dt_irq_init(void)
+static int __init mmp_of_init(struct device_node *node,
+			      struct device_node *parent)
 {
-	struct device_node *node;
-	const struct of_device_id *of_id;
-	struct mmp_intc_conf *conf;
-	int nr_irqs, irq_base, ret, irq;
-
-	node = of_find_matching_node(NULL, intc_ids);
-	if (!node) {
-		pr_err("Failed to find interrupt controller in arch-mmp\n");
-		return;
-	}
-	of_id = of_match_node(intc_ids, node);
-	conf = of_id->data;
+	int ret;
 
-	ret = of_property_read_u32(node, "mrvl,intc-nr-irqs", &nr_irqs);
+	ret = mmp_init_bases(node);
+	if (ret < 0)
+		return ret;
+
+	icu_data[0].conf_enable = mmp_conf.conf_enable;
+	icu_data[0].conf_disable = mmp_conf.conf_disable;
+	icu_data[0].conf_mask = mmp_conf.conf_mask;
+	irq_set_default_host(icu_data[0].domain);
+	max_icu_nr = 1;
+	return 0;
+}
+IRQCHIP_DECLARE(mmp_intc, "mrvl,mmp-intc", mmp_of_init);
+
+static int __init mmp2_of_init(struct device_node *node,
+			       struct device_node *parent)
+{
+	int ret;
+
+	ret = mmp_init_bases(node);
+	if (ret < 0)
+		return ret;
+
+	icu_data[0].conf_enable = mmp2_conf.conf_enable;
+	icu_data[0].conf_disable = mmp2_conf.conf_disable;
+	icu_data[0].conf_mask = mmp2_conf.conf_mask;
+	irq_set_default_host(icu_data[0].domain);
+	max_icu_nr = 1;
+	return 0;
+}
+IRQCHIP_DECLARE(mmp2_intc, "mrvl,mmp2-intc", mmp2_of_init);
+
+static int __init mmp2_mux_of_init(struct device_node *node,
+				   struct device_node *parent)
+{
+	struct resource res;
+	int i, ret, irq, j = 0;
+	u32 nr_irqs, mfp_irq;
+
+	if (!parent)
+		return -ENODEV;
+
+	i = max_icu_nr;
+	ret = of_property_read_u32(node, "mrvl,intc-nr-irqs",
+				   &nr_irqs);
 	if (ret) {
 		pr_err("Not found mrvl,intc-nr-irqs property\n");
-		return;
+		return -EINVAL;
 	}
-
-	mmp_icu_base = of_iomap(node, 0);
-	if (!mmp_icu_base) {
-		pr_err("Failed to get interrupt controller register\n");
-		return;
+	ret = of_address_to_resource(node, 0, &res);
+	if (ret < 0) {
+		pr_err("Not found reg property\n");
+		return -EINVAL;
 	}
-
-	irq_base = irq_alloc_descs(-1, 0, nr_irqs - NR_IRQS_LEGACY, 0);
-	if (irq_base < 0) {
-		pr_err("Failed to allocate IRQ numbers\n");
-		goto err;
-	} else if (irq_base != NR_IRQS_LEGACY) {
-		pr_err("ICU's irqbase should be started from 0\n");
-		goto err;
+	icu_data[i].reg_status = mmp_icu_base + res.start;
+	ret = of_address_to_resource(node, 1, &res);
+	if (ret < 0) {
+		pr_err("Not found reg property\n");
+		return -EINVAL;
 	}
-	icu_data[0].conf_enable = conf->conf_enable;
-	icu_data[0].conf_disable = conf->conf_disable;
-	icu_data[0].conf_mask = conf->conf_mask;
-	icu_data[0].nr_irqs = nr_irqs;
-	icu_data[0].virq_base = 0;
-	icu_data[0].domain = irq_domain_add_legacy(node, nr_irqs, 0, 0,
+	icu_data[i].reg_mask = mmp_icu_base + res.start;
+	icu_data[i].cascade_irq = irq_of_parse_and_map(node, 0);
+	if (!icu_data[i].cascade_irq)
+		return -EINVAL;
+
+	icu_data[i].virq_base = 0;
+	icu_data[i].domain = irq_domain_add_linear(node, nr_irqs,
 						   &mmp_irq_domain_ops,
-						   &icu_data[0]);
-	irq_set_default_host(icu_data[0].domain);
-	for (irq = 0; irq < nr_irqs; irq++)
-		icu_mask_irq(irq_get_irq_data(irq));
-	mmp2_mux_init(node);
-	return;
+						   &icu_data[i]);
+	for (irq = 0; irq < nr_irqs; irq++) {
+		ret = irq_create_mapping(icu_data[i].domain, irq);
+		if (!ret) {
+			pr_err("Failed to mapping hwirq\n");
+			goto err;
+		}
+		if (!irq)
+			icu_data[i].virq_base = ret;
+	}
+	icu_data[i].nr_irqs = nr_irqs;
+	if (!of_property_read_u32(node, "mrvl,clr-mfp-irq",
+				  &mfp_irq)) {
+		icu_data[i].clr_mfp_irq_base = icu_data[i].virq_base;
+		icu_data[i].clr_mfp_hwirq = mfp_irq;
+	}
+	irq_set_chained_handler(icu_data[i].cascade_irq,
+				icu_mux_irq_demux);
+	max_icu_nr++;
+	return 0;
 err:
-	iounmap(mmp_icu_base);
+	if (icu_data[i].virq_base) {
+		for (j = 0; j < irq; j++)
+			irq_dispose_mapping(icu_data[i].virq_base + j);
+	}
+	irq_domain_remove(icu_data[i].domain);
+	return -EINVAL;
 }
+IRQCHIP_DECLARE(mmp2_mux_intc, "mrvl,mmp2-mux-intc", mmp2_mux_of_init);
 #endif
-- 
1.8.1.2



From haojian.zhuang at gmail.com  Fri Jul 26 06:05:25 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 26 Jul 2013 18:05:25 +0800
Subject: [PATCH v6 03/11] irqchip: mmp: support MULTI_IRQ_HANDLER
In-Reply-To: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
References: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
Message-ID: <1374833133-21119-4-git-send-email-haojian.zhuang@gmail.com>

Support CONFIG_MULTI_IRQ_HANDLER in ARCH_MMP. So remove entry-macro.S.

Signed-off-by: Haojian Zhuang <haojian.zhuang at gmail.com>
---
 arch/arm/Kconfig                             |  1 +
 arch/arm/mach-mmp/include/mach/entry-macro.S | 26 -----------------
 drivers/irqchip/irq-mmp.c                    | 42 +++++++++++++++++++++++++++-
 3 files changed, 42 insertions(+), 27 deletions(-)
 delete mode 100644 arch/arm/mach-mmp/include/mach/entry-macro.S

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..76793a6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -557,6 +557,7 @@ config ARCH_MMP
 	select GENERIC_CLOCKEVENTS
 	select GPIO_PXA
 	select IRQ_DOMAIN
+	select MULTI_IRQ_HANDLER
 	select NEED_MACH_GPIO_H
 	select PINCTRL
 	select PLAT_PXA
diff --git a/arch/arm/mach-mmp/include/mach/entry-macro.S b/arch/arm/mach-mmp/include/mach/entry-macro.S
deleted file mode 100644
index bd152e2..0000000
--- a/arch/arm/mach-mmp/include/mach/entry-macro.S
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * linux/arch/arm/mach-mmp/include/mach/entry-macro.S
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <asm/irq.h>
-#include <mach/regs-icu.h>
-
-	.macro	get_irqnr_preamble, base, tmp
-	mrc	p15, 0, \tmp, c0, c0, 0		@ CPUID
-	and	\tmp, \tmp, #0xff00
-	cmp	\tmp, #0x5800
-	ldr	\base, =mmp_icu_base
-	ldr	\base, [\base, #0]
-	addne	\base, \base, #0x10c		@ PJ1 AP INT SEL register
-	addeq	\base, \base, #0x104		@ PJ4 IRQ SEL register
-	.endm
-
-	.macro	get_irqnr_and_base, irqnr, irqstat, base, tmp
-	ldr	\tmp, [\base, #0]
-	and	\irqnr, \tmp, #0x3f
-	tst	\tmp, #(1 << 6)
-	.endm
diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c
index 275709b..84d51ff 100644
--- a/drivers/irqchip/irq-mmp.c
+++ b/drivers/irqchip/irq-mmp.c
@@ -21,6 +21,9 @@
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 
+#include <asm/exception.h>
+#include <asm/mach/irq.h>
+
 #include <mach/irqs.h>
 
 #ifdef CONFIG_CPU_MMP2
@@ -34,6 +37,13 @@
 
 #define MAX_ICU_NR		16
 
+#define PJ1_INT_SEL		0x10c
+#define PJ4_INT_SEL		0x104
+
+/* bit fields in PJ1_INT_SEL and PJ4_INT_SEL */
+#define SEL_INT_PENDING		(1 << 6)
+#define SEL_INT_NUM_MASK	0x3f
+
 struct icu_chip_data {
 	int			nr_irqs;
 	unsigned int		virq_base;
@@ -54,7 +64,7 @@ struct mmp_intc_conf {
 	unsigned int	conf_mask;
 };
 
-void __iomem *mmp_icu_base;
+static void __iomem *mmp_icu_base;
 static struct icu_chip_data icu_data[MAX_ICU_NR];
 static int max_icu_nr;
 
@@ -193,6 +203,32 @@ static struct mmp_intc_conf mmp2_conf = {
 	.conf_mask	= 0x7f,
 };
 
+static asmlinkage void __exception_irq_entry
+mmp_handle_irq(struct pt_regs *regs)
+{
+	int irq, hwirq;
+
+	hwirq = readl_relaxed(mmp_icu_base + PJ1_INT_SEL);
+	if (!(hwirq & SEL_INT_PENDING))
+		return;
+	hwirq &= SEL_INT_NUM_MASK;
+	irq = irq_find_mapping(icu_data[0].domain, hwirq);
+	handle_IRQ(irq, regs);
+}
+
+static asmlinkage void __exception_irq_entry
+mmp2_handle_irq(struct pt_regs *regs)
+{
+	int irq, hwirq;
+
+	hwirq = readl_relaxed(mmp_icu_base + PJ4_INT_SEL);
+	if (!(hwirq & SEL_INT_PENDING))
+		return;
+	hwirq &= SEL_INT_NUM_MASK;
+	irq = irq_find_mapping(icu_data[0].domain, hwirq);
+	handle_IRQ(irq, regs);
+}
+
 /* MMP (ARMv5) */
 void __init icu_init_irq(void)
 {
@@ -214,6 +250,7 @@ void __init icu_init_irq(void)
 		set_irq_flags(irq, IRQF_VALID);
 	}
 	irq_set_default_host(icu_data[0].domain);
+	set_handle_irq(mmp_handle_irq);
 #ifdef CONFIG_CPU_PXA910
 	icu_irq_chip.irq_set_wake = pxa910_set_wake;
 #endif
@@ -320,6 +357,7 @@ void __init mmp2_init_icu(void)
 		set_irq_flags(irq, IRQF_VALID);
 	}
 	irq_set_default_host(icu_data[0].domain);
+	set_handle_irq(mmp2_handle_irq);
 #ifdef CONFIG_CPU_MMP2
 	icu_irq_chip.irq_set_wake = mmp2_set_wake;
 #endif
@@ -380,6 +418,7 @@ static int __init mmp_of_init(struct device_node *node,
 	icu_data[0].conf_disable = mmp_conf.conf_disable;
 	icu_data[0].conf_mask = mmp_conf.conf_mask;
 	irq_set_default_host(icu_data[0].domain);
+	set_handle_irq(mmp_handle_irq);
 	max_icu_nr = 1;
 	return 0;
 }
@@ -398,6 +437,7 @@ static int __init mmp2_of_init(struct device_node *node,
 	icu_data[0].conf_disable = mmp2_conf.conf_disable;
 	icu_data[0].conf_mask = mmp2_conf.conf_mask;
 	irq_set_default_host(icu_data[0].domain);
+	set_handle_irq(mmp2_handle_irq);
 	max_icu_nr = 1;
 	return 0;
 }
-- 
1.8.1.2



From haojian.zhuang at gmail.com  Fri Jul 26 06:05:26 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 26 Jul 2013 18:05:26 +0800
Subject: [PATCH v6 04/11] ARM: mmp: avoid to include head file in mach-mmp
In-Reply-To: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
References: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
Message-ID: <1374833133-21119-5-git-send-email-haojian.zhuang@gmail.com>

pxa910_set_wake() & mmp2_set_wake() are both declared in head files
of arch/arm/mach-mmp/include/mach directory. If we include these
head files in irq-mmp driver, it blocks the multiplatform build.
So adjust the code.

Signed-off-by: Haojian Zhuang <haojian.zhuang at gmail.com>
---
 arch/arm/mach-mmp/mmp2.c    |  4 ++++
 arch/arm/mach-mmp/pxa910.c  |  4 ++++
 drivers/irqchip/irq-mmp.c   | 15 +--------------
 include/linux/irqchip/mmp.h |  6 ++++++
 4 files changed, 15 insertions(+), 14 deletions(-)
 create mode 100644 include/linux/irqchip/mmp.h

diff --git a/arch/arm/mach-mmp/mmp2.c b/arch/arm/mach-mmp/mmp2.c
index c7592f1..09fbe7d 100644
--- a/arch/arm/mach-mmp/mmp2.c
+++ b/arch/arm/mach-mmp/mmp2.c
@@ -13,6 +13,8 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/irqchip/mmp.h>
 #include <linux/platform_device.h>
 
 #include <asm/hardware/cache-tauros2.h>
@@ -26,6 +28,7 @@
 #include <mach/mfp.h>
 #include <mach/devices.h>
 #include <mach/mmp2.h>
+#include <mach/pm-mmp2.h>
 
 #include "common.h"
 
@@ -94,6 +97,7 @@ void mmp2_clear_pmic_int(void)
 void __init mmp2_init_irq(void)
 {
 	mmp2_init_icu();
+	icu_irq_chip.irq_set_wake = mmp2_set_wake;
 }
 
 static int __init mmp2_init(void)
diff --git a/arch/arm/mach-mmp/pxa910.c b/arch/arm/mach-mmp/pxa910.c
index a586742..96e125b 100644
--- a/arch/arm/mach-mmp/pxa910.c
+++ b/arch/arm/mach-mmp/pxa910.c
@@ -12,6 +12,8 @@
 #include <linux/init.h>
 #include <linux/list.h>
 #include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/irqchip/mmp.h>
 #include <linux/platform_device.h>
 
 #include <asm/hardware/cache-tauros2.h>
@@ -23,6 +25,7 @@
 #include <mach/dma.h>
 #include <mach/mfp.h>
 #include <mach/devices.h>
+#include <mach/pm-pxa910.h>
 #include <mach/pxa910.h>
 
 #include "common.h"
@@ -80,6 +83,7 @@ static struct mfp_addr_map pxa910_mfp_addr_map[] __initdata =
 void __init pxa910_init_irq(void)
 {
 	icu_init_irq();
+	icu_irq_chip.irq_set_wake = pxa910_set_wake;
 }
 
 static int __init pxa910_init(void)
diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c
index 84d51ff..1f81432 100644
--- a/drivers/irqchip/irq-mmp.c
+++ b/drivers/irqchip/irq-mmp.c
@@ -26,13 +26,6 @@
 
 #include <mach/irqs.h>
 
-#ifdef CONFIG_CPU_MMP2
-#include <mach/pm-mmp2.h>
-#endif
-#ifdef CONFIG_CPU_PXA910
-#include <mach/pm-pxa910.h>
-#endif
-
 #include "irqchip.h"
 
 #define MAX_ICU_NR		16
@@ -132,7 +125,7 @@ static void icu_unmask_irq(struct irq_data *d)
 	}
 }
 
-static struct irq_chip icu_irq_chip = {
+struct irq_chip icu_irq_chip = {
 	.name		= "icu_irq",
 	.irq_mask	= icu_mask_irq,
 	.irq_mask_ack	= icu_mask_ack_irq,
@@ -251,9 +244,6 @@ void __init icu_init_irq(void)
 	}
 	irq_set_default_host(icu_data[0].domain);
 	set_handle_irq(mmp_handle_irq);
-#ifdef CONFIG_CPU_PXA910
-	icu_irq_chip.irq_set_wake = pxa910_set_wake;
-#endif
 }
 
 /* MMP2 (ARMv7) */
@@ -358,9 +348,6 @@ void __init mmp2_init_icu(void)
 	}
 	irq_set_default_host(icu_data[0].domain);
 	set_handle_irq(mmp2_handle_irq);
-#ifdef CONFIG_CPU_MMP2
-	icu_irq_chip.irq_set_wake = mmp2_set_wake;
-#endif
 }
 
 #ifdef CONFIG_OF
diff --git a/include/linux/irqchip/mmp.h b/include/linux/irqchip/mmp.h
new file mode 100644
index 0000000..c78a892
--- /dev/null
+++ b/include/linux/irqchip/mmp.h
@@ -0,0 +1,6 @@
+#ifndef	__IRQCHIP_MMP_H
+#define	__IRQCHIP_MMP_H
+
+extern struct irq_chip icu_irq_chip;
+
+#endif	/* __IRQCHIP_MMP_H */
-- 
1.8.1.2



From haojian.zhuang at gmail.com  Fri Jul 26 06:05:27 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 26 Jul 2013 18:05:27 +0800
Subject: [PATCH v6 05/11] irqchip: mmp: avoid to include irqs head file
In-Reply-To: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
References: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
Message-ID: <1374833133-21119-6-git-send-email-haojian.zhuang@gmail.com>

Since <mach/irqs.h> in irq-mmp.c blocks the multiplatform build,
remove it instead.

Signed-off-by: Haojian Zhuang <haojian.zhuang at gmail.com>
---
 drivers/irqchip/irq-mmp.c | 45 +++++++++++++++++++++------------------------
 1 file changed, 21 insertions(+), 24 deletions(-)

diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c
index 1f81432..2cb7cd0 100644
--- a/drivers/irqchip/irq-mmp.c
+++ b/drivers/irqchip/irq-mmp.c
@@ -24,8 +24,6 @@
 #include <asm/exception.h>
 #include <asm/mach/irq.h>
 
-#include <mach/irqs.h>
-
 #include "irqchip.h"
 
 #define MAX_ICU_NR		16
@@ -249,7 +247,7 @@ void __init icu_init_irq(void)
 /* MMP2 (ARMv7) */
 void __init mmp2_init_icu(void)
 {
-	int irq;
+	int irq, end;
 
 	max_icu_nr = 8;
 	mmp_icu_base = ioremap(0xd4282000, 0x1000);
@@ -263,11 +261,12 @@ void __init mmp2_init_icu(void)
 						   &icu_data[0]);
 	icu_data[1].reg_status = mmp_icu_base + 0x150;
 	icu_data[1].reg_mask = mmp_icu_base + 0x168;
-	icu_data[1].clr_mfp_irq_base = IRQ_MMP2_PMIC_BASE;
-	icu_data[1].clr_mfp_hwirq = IRQ_MMP2_PMIC - IRQ_MMP2_PMIC_BASE;
+	icu_data[1].clr_mfp_irq_base = icu_data[0].virq_base +
+				icu_data[0].nr_irqs;
+	icu_data[1].clr_mfp_hwirq = 1;		/* offset to IRQ_MMP2_PMIC_BASE */
 	icu_data[1].nr_irqs = 2;
 	icu_data[1].cascade_irq = 4;
-	icu_data[1].virq_base = IRQ_MMP2_PMIC_BASE;
+	icu_data[1].virq_base = icu_data[0].virq_base + icu_data[0].nr_irqs;
 	icu_data[1].domain = irq_domain_add_legacy(NULL, icu_data[1].nr_irqs,
 						   icu_data[1].virq_base, 0,
 						   &irq_domain_simple_ops,
@@ -276,7 +275,7 @@ void __init mmp2_init_icu(void)
 	icu_data[2].reg_mask = mmp_icu_base + 0x16c;
 	icu_data[2].nr_irqs = 2;
 	icu_data[2].cascade_irq = 5;
-	icu_data[2].virq_base = IRQ_MMP2_RTC_BASE;
+	icu_data[2].virq_base = icu_data[1].virq_base + icu_data[1].nr_irqs;
 	icu_data[2].domain = irq_domain_add_legacy(NULL, icu_data[2].nr_irqs,
 						   icu_data[2].virq_base, 0,
 						   &irq_domain_simple_ops,
@@ -285,7 +284,7 @@ void __init mmp2_init_icu(void)
 	icu_data[3].reg_mask = mmp_icu_base + 0x17c;
 	icu_data[3].nr_irqs = 3;
 	icu_data[3].cascade_irq = 9;
-	icu_data[3].virq_base = IRQ_MMP2_KEYPAD_BASE;
+	icu_data[3].virq_base = icu_data[2].virq_base + icu_data[2].nr_irqs;
 	icu_data[3].domain = irq_domain_add_legacy(NULL, icu_data[3].nr_irqs,
 						   icu_data[3].virq_base, 0,
 						   &irq_domain_simple_ops,
@@ -294,7 +293,7 @@ void __init mmp2_init_icu(void)
 	icu_data[4].reg_mask = mmp_icu_base + 0x170;
 	icu_data[4].nr_irqs = 5;
 	icu_data[4].cascade_irq = 17;
-	icu_data[4].virq_base = IRQ_MMP2_TWSI_BASE;
+	icu_data[4].virq_base = icu_data[3].virq_base + icu_data[3].nr_irqs;
 	icu_data[4].domain = irq_domain_add_legacy(NULL, icu_data[4].nr_irqs,
 						   icu_data[4].virq_base, 0,
 						   &irq_domain_simple_ops,
@@ -303,7 +302,7 @@ void __init mmp2_init_icu(void)
 	icu_data[5].reg_mask = mmp_icu_base + 0x174;
 	icu_data[5].nr_irqs = 15;
 	icu_data[5].cascade_irq = 35;
-	icu_data[5].virq_base = IRQ_MMP2_MISC_BASE;
+	icu_data[5].virq_base = icu_data[4].virq_base + icu_data[4].nr_irqs;
 	icu_data[5].domain = irq_domain_add_legacy(NULL, icu_data[5].nr_irqs,
 						   icu_data[5].virq_base, 0,
 						   &irq_domain_simple_ops,
@@ -312,7 +311,7 @@ void __init mmp2_init_icu(void)
 	icu_data[6].reg_mask = mmp_icu_base + 0x178;
 	icu_data[6].nr_irqs = 2;
 	icu_data[6].cascade_irq = 51;
-	icu_data[6].virq_base = IRQ_MMP2_MIPI_HSI1_BASE;
+	icu_data[6].virq_base = icu_data[5].virq_base + icu_data[5].nr_irqs;
 	icu_data[6].domain = irq_domain_add_legacy(NULL, icu_data[6].nr_irqs,
 						   icu_data[6].virq_base, 0,
 						   &irq_domain_simple_ops,
@@ -321,28 +320,26 @@ void __init mmp2_init_icu(void)
 	icu_data[7].reg_mask = mmp_icu_base + 0x184;
 	icu_data[7].nr_irqs = 2;
 	icu_data[7].cascade_irq = 55;
-	icu_data[7].virq_base = IRQ_MMP2_MIPI_HSI0_BASE;
+	icu_data[7].virq_base = icu_data[6].virq_base + icu_data[6].nr_irqs;
 	icu_data[7].domain = irq_domain_add_legacy(NULL, icu_data[7].nr_irqs,
 						   icu_data[7].virq_base, 0,
 						   &irq_domain_simple_ops,
 						   &icu_data[7]);
-	for (irq = 0; irq < IRQ_MMP2_MUX_END; irq++) {
+	end = icu_data[7].virq_base + icu_data[7].nr_irqs;
+	for (irq = 0; irq < end; irq++) {
 		icu_mask_irq(irq_get_irq_data(irq));
-		switch (irq) {
-		case IRQ_MMP2_PMIC_MUX:
-		case IRQ_MMP2_RTC_MUX:
-		case IRQ_MMP2_KEYPAD_MUX:
-		case IRQ_MMP2_TWSI_MUX:
-		case IRQ_MMP2_MISC_MUX:
-		case IRQ_MMP2_MIPI_HSI1_MUX:
-		case IRQ_MMP2_MIPI_HSI0_MUX:
+		if (irq == icu_data[1].cascade_irq ||
+		    irq == icu_data[2].cascade_irq ||
+		    irq == icu_data[3].cascade_irq ||
+		    irq == icu_data[4].cascade_irq ||
+		    irq == icu_data[5].cascade_irq ||
+		    irq == icu_data[6].cascade_irq ||
+		    irq == icu_data[7].cascade_irq) {
 			irq_set_chip(irq, &icu_irq_chip);
 			irq_set_chained_handler(irq, icu_mux_irq_demux);
-			break;
-		default:
+		} else {
 			irq_set_chip_and_handler(irq, &icu_irq_chip,
 						 handle_level_irq);
-			break;
 		}
 		set_irq_flags(irq, IRQF_VALID);
 	}
-- 
1.8.1.2



From haojian.zhuang at gmail.com  Fri Jul 26 06:05:28 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 26 Jul 2013 18:05:28 +0800
Subject: [PATCH v6 06/11] clocksource: mmp: move mmp timer driver
In-Reply-To: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
References: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
Message-ID: <1374833133-21119-7-git-send-email-haojian.zhuang@gmail.com>

Move timer-mmp driver from mach-mmp to clocksource directory.

Signed-off-by: Haojian Zhuang <haojian.zhuang at gmail.com>
---
 arch/arm/mach-mmp/Makefile                                  | 2 +-
 drivers/clocksource/Makefile                                | 1 +
 arch/arm/mach-mmp/time.c => drivers/clocksource/timer-mmp.c | 2 --
 3 files changed, 2 insertions(+), 3 deletions(-)
 rename arch/arm/mach-mmp/time.c => drivers/clocksource/timer-mmp.c (99%)

diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
index 9b702a1..5d4ccc6 100644
--- a/arch/arm/mach-mmp/Makefile
+++ b/arch/arm/mach-mmp/Makefile
@@ -2,7 +2,7 @@
 # Makefile for Marvell's PXA168 processors line
 #
 
-obj-y				+= common.o devices.o time.o
+obj-y				+= common.o devices.o
 
 # SoC support
 obj-$(CONFIG_CPU_PXA168)	+= pxa168.o
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 8b00c5c..7dda633 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
 obj-$(CONFIG_ORION_TIMER)	+= time-orion.o
 obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
 obj-$(CONFIG_ARCH_MARCO)	+= timer-marco.o
+obj-$(CONFIG_ARCH_MMP)		+= timer-mmp.o
 obj-$(CONFIG_ARCH_MXS)		+= mxs_timer.o
 obj-$(CONFIG_ARCH_PRIMA2)	+= timer-prima2.o
 obj-$(CONFIG_SUN4I_TIMER)	+= sun4i_timer.o
diff --git a/arch/arm/mach-mmp/time.c b/drivers/clocksource/timer-mmp.c
similarity index 99%
rename from arch/arm/mach-mmp/time.c
rename to drivers/clocksource/timer-mmp.c
index 7ac41e8..ddc1b15 100644
--- a/arch/arm/mach-mmp/time.c
+++ b/drivers/clocksource/timer-mmp.c
@@ -37,8 +37,6 @@
 #include <mach/cputype.h>
 #include <asm/mach/time.h>
 
-#include "clock.h"
-
 #define TIMERS_VIRT_BASE	TIMERS1_VIRT_BASE
 
 #define MAX_DELTA		(0xfffffffe)
-- 
1.8.1.2



From haojian.zhuang at gmail.com  Fri Jul 26 06:05:29 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 26 Jul 2013 18:05:29 +0800
Subject: [PATCH v6 07/11] ARM: mmp: move timer registers into driver
In-Reply-To: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
References: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
Message-ID: <1374833133-21119-8-git-send-email-haojian.zhuang@gmail.com>

Move the definition of timer registers into timer-mmp driver.
And map timer registers in driver.

Signed-off-by: Haojian Zhuang <haojian.zhuang at gmail.com>
---
 arch/arm/mach-mmp/common.h                   |  2 +-
 arch/arm/mach-mmp/include/mach/addr-map.h    |  3 ++
 arch/arm/mach-mmp/include/mach/regs-timers.h | 44 ----------------------------
 arch/arm/mach-mmp/mmp2.c                     |  2 +-
 arch/arm/mach-mmp/pxa168.c                   |  2 +-
 arch/arm/mach-mmp/pxa910.c                   |  2 +-
 drivers/clocksource/timer-mmp.c              | 37 ++++++++++++++++++-----
 7 files changed, 37 insertions(+), 55 deletions(-)
 delete mode 100644 arch/arm/mach-mmp/include/mach/regs-timers.h

diff --git a/arch/arm/mach-mmp/common.h b/arch/arm/mach-mmp/common.h
index cf445ba..22e67c6 100644
--- a/arch/arm/mach-mmp/common.h
+++ b/arch/arm/mach-mmp/common.h
@@ -1,7 +1,7 @@
 #include <linux/reboot.h>
 #define ARRAY_AND_SIZE(x)	(x), ARRAY_SIZE(x)
 
-extern void timer_init(int irq);
+extern void timer_init(void __iomem *base, int irq);
 
 extern void __init mmp_map_io(void);
 extern void mmp_restart(enum reboot_mode, const char *);
diff --git a/arch/arm/mach-mmp/include/mach/addr-map.h b/arch/arm/mach-mmp/include/mach/addr-map.h
index f88a44c..169c280 100644
--- a/arch/arm/mach-mmp/include/mach/addr-map.h
+++ b/arch/arm/mach-mmp/include/mach/addr-map.h
@@ -43,4 +43,7 @@
 #define CIU_VIRT_BASE		(AXI_VIRT_BASE + 0x82c00)
 #define CIU_REG(x)		(CIU_VIRT_BASE + (x))
 
+#define TIMER1_VIRT_BASE	(APB_VIRT_BASE + 0x14000)
+#define TIMER2_VIRT_BASE	(APB_VIRT_BASE + 0x16000)
+
 #endif /* __ASM_MACH_ADDR_MAP_H */
diff --git a/arch/arm/mach-mmp/include/mach/regs-timers.h b/arch/arm/mach-mmp/include/mach/regs-timers.h
deleted file mode 100644
index 45589fe..0000000
--- a/arch/arm/mach-mmp/include/mach/regs-timers.h
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * linux/arch/arm/mach-mmp/include/mach/regs-timers.h
- *
- *   Timers Module
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef __ASM_MACH_REGS_TIMERS_H
-#define __ASM_MACH_REGS_TIMERS_H
-
-#include <mach/addr-map.h>
-
-#define TIMERS1_VIRT_BASE	(APB_VIRT_BASE + 0x14000)
-#define TIMERS2_VIRT_BASE	(APB_VIRT_BASE + 0x16000)
-
-#define TMR_CCR		(0x0000)
-#define TMR_TN_MM(n, m)	(0x0004 + ((n) << 3) + (((n) + (m)) << 2))
-#define TMR_CR(n)	(0x0028 + ((n) << 2))
-#define TMR_SR(n)	(0x0034 + ((n) << 2))
-#define TMR_IER(n)	(0x0040 + ((n) << 2))
-#define TMR_PLVR(n)	(0x004c + ((n) << 2))
-#define TMR_PLCR(n)	(0x0058 + ((n) << 2))
-#define TMR_WMER	(0x0064)
-#define TMR_WMR		(0x0068)
-#define TMR_WVR		(0x006c)
-#define TMR_WSR		(0x0070)
-#define TMR_ICR(n)	(0x0074 + ((n) << 2))
-#define TMR_WICR	(0x0080)
-#define TMR_CER		(0x0084)
-#define TMR_CMR		(0x0088)
-#define TMR_ILR(n)	(0x008c + ((n) << 2))
-#define TMR_WCR		(0x0098)
-#define TMR_WFAR	(0x009c)
-#define TMR_WSAR	(0x00A0)
-#define TMR_CVWR(n)	(0x00A4 + ((n) << 2))
-
-#define TMR_CCR_CS_0(x)	(((x) & 0x3) << 0)
-#define TMR_CCR_CS_1(x)	(((x) & 0x7) << 2)
-#define TMR_CCR_CS_2(x)	(((x) & 0x3) << 5)
-
-#endif /* __ASM_MACH_REGS_TIMERS_H */
diff --git a/arch/arm/mach-mmp/mmp2.c b/arch/arm/mach-mmp/mmp2.c
index 09fbe7d..f26ea9d 100644
--- a/arch/arm/mach-mmp/mmp2.c
+++ b/arch/arm/mach-mmp/mmp2.c
@@ -131,7 +131,7 @@ void __init mmp2_timer_init(void)
 	clk_rst = APBC_APBCLK | APBC_FNCLK | APBC_FNCLKSEL(1);
 	__raw_writel(clk_rst, APBC_TIMERS);
 
-	timer_init(IRQ_MMP2_TIMER1);
+	timer_init(TIMER1_VIRT_BASE, IRQ_MMP2_TIMER1);
 }
 
 /* on-chip devices */
diff --git a/arch/arm/mach-mmp/pxa168.c b/arch/arm/mach-mmp/pxa168.c
index 144e997..b6b3d5b 100644
--- a/arch/arm/mach-mmp/pxa168.c
+++ b/arch/arm/mach-mmp/pxa168.c
@@ -78,7 +78,7 @@ void __init pxa168_timer_init(void)
 	/* 3.25MHz, bus/functional clock enabled, release reset */
 	__raw_writel(TIMER_CLK_RST, APBC_TIMERS);
 
-	timer_init(IRQ_PXA168_TIMER1);
+	timer_init(TIMER1_VIRT_BASE, IRQ_PXA168_TIMER1);
 }
 
 void pxa168_clear_keypad_wakeup(void)
diff --git a/arch/arm/mach-mmp/pxa910.c b/arch/arm/mach-mmp/pxa910.c
index 96e125b..df379c2 100644
--- a/arch/arm/mach-mmp/pxa910.c
+++ b/arch/arm/mach-mmp/pxa910.c
@@ -112,7 +112,7 @@ void __init pxa910_timer_init(void)
 	__raw_writel(APBC_APBCLK | APBC_RST, APBC_TIMERS);
 	__raw_writel(TIMER_CLK_RST, APBC_TIMERS);
 
-	timer_init(IRQ_PXA910_AP1_TIMER1);
+	timer_init(TIMER1_VIRT_BASE, IRQ_PXA910_AP1_TIMER1);
 }
 
 /* on-chip devices */
diff --git a/drivers/clocksource/timer-mmp.c b/drivers/clocksource/timer-mmp.c
index ddc1b15..937d51e 100644
--- a/drivers/clocksource/timer-mmp.c
+++ b/drivers/clocksource/timer-mmp.c
@@ -30,19 +30,39 @@
 #include <linux/of_irq.h>
 #include <linux/sched_clock.h>
 
-#include <mach/addr-map.h>
-#include <mach/regs-timers.h>
-#include <mach/regs-apbc.h>
 #include <mach/irqs.h>
 #include <mach/cputype.h>
 #include <asm/mach/time.h>
 
-#define TIMERS_VIRT_BASE	TIMERS1_VIRT_BASE
+#define TMR_CCR		(0x0000)
+#define TMR_TN_MM(n, m)	(0x0004 + ((n) << 3) + (((n) + (m)) << 2))
+#define TMR_CR(n)	(0x0028 + ((n) << 2))
+#define TMR_SR(n)	(0x0034 + ((n) << 2))
+#define TMR_IER(n)	(0x0040 + ((n) << 2))
+#define TMR_PLVR(n)	(0x004c + ((n) << 2))
+#define TMR_PLCR(n)	(0x0058 + ((n) << 2))
+#define TMR_WMER	(0x0064)
+#define TMR_WMR		(0x0068)
+#define TMR_WVR		(0x006c)
+#define TMR_WSR		(0x0070)
+#define TMR_ICR(n)	(0x0074 + ((n) << 2))
+#define TMR_WICR	(0x0080)
+#define TMR_CER		(0x0084)
+#define TMR_CMR		(0x0088)
+#define TMR_ILR(n)	(0x008c + ((n) << 2))
+#define TMR_WCR		(0x0098)
+#define TMR_WFAR	(0x009c)
+#define TMR_WSAR	(0x00A0)
+#define TMR_CVWR(n)	(0x00A4 + ((n) << 2))
+
+#define TMR_CCR_CS_0(x)	(((x) & 0x3) << 0)
+#define TMR_CCR_CS_1(x)	(((x) & 0x7) << 2)
+#define TMR_CCR_CS_2(x)	(((x) & 0x3) << 5)
 
 #define MAX_DELTA		(0xfffffffe)
 #define MIN_DELTA		(16)
 
-static void __iomem *mmp_timer_base = TIMERS_VIRT_BASE;
+static void __iomem *mmp_timer_base;
 
 /*
  * FIXME: the timer needs some delay to stablize the counter capture
@@ -189,8 +209,11 @@ static struct irqaction timer_irq = {
 	.dev_id		= &ckevt,
 };
 
-void __init timer_init(int irq)
+void __init timer_init(void __iomem *base, int irq)
 {
+	BUG_ON(!base);
+	mmp_timer_base = base;
+
 	timer_config();
 
 	setup_sched_clock(mmp_read_sched_clock, 32, CLOCK_TICK_RATE);
@@ -231,7 +254,7 @@ void __init mmp_dt_init_timer(void)
 		ret = -ENOMEM;
 		goto out;
 	}
-	timer_init(irq);
+	timer_init(mmp_timer_base, irq);
 	return;
 out:
 	pr_err("Failed to get timer from device tree with error:%d\n", ret);
-- 
1.8.1.2



From haojian.zhuang at gmail.com  Fri Jul 26 06:05:30 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 26 Jul 2013 18:05:30 +0800
Subject: [PATCH v6 08/11] ARM: pxa: init dma debugfs in late level
In-Reply-To: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
References: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
Message-ID: <1374833133-21119-9-git-send-email-haojian.zhuang@gmail.com>

Remove pxa_init_dma() from core_initcall level since it's unncecssary
for DT mode. But dma debugfs is also included in pxa_init_dma().
So only initiliaze dma debugfs in late_initcall level.

Signed-off-by: Haojian Zhuang <haojian.zhuang at gmail.com>
---
 arch/arm/mach-mmp/mmp2.c   |  2 +-
 arch/arm/mach-mmp/pxa168.c |  2 +-
 arch/arm/mach-mmp/pxa910.c |  2 +-
 arch/arm/plat-pxa/dma.c    | 30 ++++++++++++++++++++----------
 4 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-mmp/mmp2.c b/arch/arm/mach-mmp/mmp2.c
index f26ea9d..a0abfd7 100644
--- a/arch/arm/mach-mmp/mmp2.c
+++ b/arch/arm/mach-mmp/mmp2.c
@@ -114,7 +114,6 @@ static int __init mmp2_init(void)
 
 	return 0;
 }
-postcore_initcall(mmp2_init);
 
 #define APBC_TIMERS	APBC_REG(0x024)
 
@@ -122,6 +121,7 @@ void __init mmp2_timer_init(void)
 {
 	unsigned long clk_rst;
 
+	mmp2_init();
 	__raw_writel(APBC_APBCLK | APBC_RST, APBC_TIMERS);
 
 	/*
diff --git a/arch/arm/mach-mmp/pxa168.c b/arch/arm/mach-mmp/pxa168.c
index b6b3d5b..a332d51 100644
--- a/arch/arm/mach-mmp/pxa168.c
+++ b/arch/arm/mach-mmp/pxa168.c
@@ -61,7 +61,6 @@ static int __init pxa168_init(void)
 
 	return 0;
 }
-postcore_initcall(pxa168_init);
 
 /* system timer - clock enabled, 3.25MHz */
 #define TIMER_CLK_RST	(APBC_APBCLK | APBC_FNCLK | APBC_FNCLKSEL(3))
@@ -69,6 +68,7 @@ postcore_initcall(pxa168_init);
 
 void __init pxa168_timer_init(void)
 {
+	pxa168_init();
 	/* this is early, we have to initialize the CCU registers by
 	 * ourselves instead of using clk_* API. Clock rate is defined
 	 * by APBC_TIMERS_CLK_RST (3.25MHz) and enabled free-running
diff --git a/arch/arm/mach-mmp/pxa910.c b/arch/arm/mach-mmp/pxa910.c
index df379c2..1a84800 100644
--- a/arch/arm/mach-mmp/pxa910.c
+++ b/arch/arm/mach-mmp/pxa910.c
@@ -100,7 +100,6 @@ static int __init pxa910_init(void)
 
 	return 0;
 }
-postcore_initcall(pxa910_init);
 
 /* system timer - clock enabled, 3.25MHz */
 #define TIMER_CLK_RST	(APBC_APBCLK | APBC_FNCLK | APBC_FNCLKSEL(3))
@@ -108,6 +107,7 @@ postcore_initcall(pxa910_init);
 
 void __init pxa910_timer_init(void)
 {
+	pxa910_init();
 	/* reset and configure */
 	__raw_writel(APBC_APBCLK | APBC_RST, APBC_TIMERS);
 	__raw_writel(TIMER_CLK_RST, APBC_TIMERS);
diff --git a/arch/arm/plat-pxa/dma.c b/arch/arm/plat-pxa/dma.c
index 79ef102..6c5472b 100644
--- a/arch/arm/plat-pxa/dma.c
+++ b/arch/arm/plat-pxa/dma.c
@@ -228,36 +228,46 @@ err_state:
 	return NULL;
 }
 
-static void pxa_dma_init_debugfs(void)
+static int __init pxa_dma_init_debugfs(void)
 {
-	int i;
+	int i, ret;
 	struct dentry *chandir;
 
 	dbgfs_root = debugfs_create_dir(DMA_DEBUG_NAME, NULL);
-	if (IS_ERR(dbgfs_root) || !dbgfs_root)
+	if (IS_ERR(dbgfs_root) || !dbgfs_root) {
+		ret = -EINVAL;
 		goto err_root;
+	}
 
 	dbgfs_state = debugfs_create_file("state", 0400, dbgfs_root, NULL,
 					  &dbg_fops_state);
-	if (!dbgfs_state)
+	if (!dbgfs_state) {
+		ret = -EINVAL;
 		goto err_state;
+	}
 
 	dbgfs_chan = kmalloc(sizeof(*dbgfs_state) * num_dma_channels,
 			     GFP_KERNEL);
-	if (!dbgfs_chan)
+	if (!dbgfs_chan) {
+		ret = -ENOMEM;
 		goto err_alloc;
+	}
 
 	chandir = debugfs_create_dir("channels", dbgfs_root);
-	if (!chandir)
+	if (!chandir) {
+		ret = -EINVAL;
 		goto err_chandir;
+	}
 
 	for (i = 0; i < num_dma_channels; i++) {
 		dbgfs_chan[i] = pxa_dma_dbg_alloc_chan(i, chandir);
-		if (!dbgfs_chan[i])
+		if (!dbgfs_chan[i]) {
+			ret = -EINVAL;
 			goto err_chans;
+		}
 	}
 
-	return;
+	return 0;
 err_chans:
 err_chandir:
 	kfree(dbgfs_chan);
@@ -266,7 +276,9 @@ err_state:
 	debugfs_remove_recursive(dbgfs_root);
 err_root:
 	pr_err("pxa_dma: debugfs is not available\n");
+	return ret;
 }
+late_initcall(pxa_dma_init_debugfs);
 
 static void __exit pxa_dma_cleanup_debugfs(void)
 {
@@ -385,7 +397,5 @@ int __init pxa_init_dma(int irq, int num_ch)
 	}
 	num_dma_channels = num_ch;
 
-	pxa_dma_init_debugfs();
-
 	return 0;
 }
-- 
1.8.1.2



From haojian.zhuang at gmail.com  Fri Jul 26 06:05:31 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 26 Jul 2013 18:05:31 +0800
Subject: [PATCH v6 09/11] clk: mmp: parse clock from dts
In-Reply-To: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
References: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
Message-ID: <1374833133-21119-10-git-send-email-haojian.zhuang@gmail.com>

Parse clock information from DTS file for mach-mmp.

Changelog:
v6:
1. Remove marvell string from properties in clock driver.
2. Append document for clock binding device tree.
3. Use apbc to replace apbcp. Since the main difference is register
base.

v5:
1. Replace clk_register_mux() by clk_register_mux_table().

Signed-off-by: Haojian Zhuang <haojian.zhuang at gmail.com>
---
 .../devicetree/bindings/clock/mmp-clock.txt        |  51 ++++
 arch/arm/mach-mmp/mmp-dt.c                         |   2 +
 drivers/clk/mmp/Makefile                           |   2 +-
 drivers/clk/mmp/clk-mmp.c                          | 300 +++++++++++++++++++++
 4 files changed, 354 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/clock/mmp-clock.txt
 create mode 100644 drivers/clk/mmp/clk-mmp.c

diff --git a/Documentation/devicetree/bindings/clock/mmp-clock.txt b/Documentation/devicetree/bindings/clock/mmp-clock.txt
new file mode 100644
index 0000000..5fe52a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp-clock.txt
@@ -0,0 +1,51 @@
+Device Tree Clock bindings for arch-mmp
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties for fixed rate clocks:
+  - compatible : should be "marvell,mmp-fixed-clkrate".
+  - clocks : should be the input parent clock phandle for the clock. This
+	should be the reference clock.
+  - clock-output-names : should be reference name.
+  - #clock-cells : from common clock binding; should be set to 0.
+  - clock-frequency : frequency of the fixed rate clock
+
+Required properties for fixed factor clocks:
+  - compatible : should be "marvell,mmp-fixed-clkfactor".
+  - clocks : should be the input parent clock phandle for the clock. This
+	should be the reference clock.
+  - clock-output-names : should be reference name.
+  - #clock-cells : from common clock binding; should be set to 0.
+
+Required properties for mux clocks:
+  - compatible : should be "marvell,mmp-clkmux".
+  - clocks : should be the input parent clock phandle for the clock. This
+	should be the reference clock.
+  - clock-output-names : should be reference name.
+  - #clock-cells : from common clock binding; should be set to 0.
+  - mmp-clk-reg : mux register offset & mask bits.
+  - mmp-clk-sel : array of mux select bits
+
+Required properties for divider clocks:
+  - compatible : should be "marvell,mmp-apmu-clkdiv".
+  - clocks : should be the input parent clock phandle for the clock. This
+	should be the reference clock.
+  - clock-output-names : should be reference name.
+  - #clock-cells : from common clock binding; should be set to 0.
+  - mmp-clk-reg : divider register offset & mask bits.
+
+Required properties for gate clocks:
+  - compatible : should be "marvell,mmp-apbc-clk".
+  - clocks : should be the input parent clock phandle for the clock. This
+	should be the reference clock.
+  - clock-output-names : should be reference name.
+  - #clock-cells : from common clock binding; should be set to 0.
+  - mmp-clk-reg : gate register offset & mask bits.
+
+Optional properties for gate clocks:
+  - mmp-clk-delay : delay between enabling function clock and apb clock
+  - mmp-apbc-power-ctrl : enable apbc power control bit
+
+For example:
diff --git a/arch/arm/mach-mmp/mmp-dt.c b/arch/arm/mach-mmp/mmp-dt.c
index cca529c..f109bf6 100644
--- a/arch/arm/mach-mmp/mmp-dt.c
+++ b/arch/arm/mach-mmp/mmp-dt.c
@@ -9,6 +9,7 @@
  *  publishhed by the Free Software Foundation.
  */
 
+#include <linux/clk-provider.h>
 #include <linux/irqchip.h>
 #include <linux/of_platform.h>
 #include <asm/mach/arch.h>
@@ -48,6 +49,7 @@ static void __init pxa168_dt_init(void)
 
 static void __init pxa910_dt_init(void)
 {
+	of_clk_init(NULL);
 	of_platform_populate(NULL, of_default_bus_match_table,
 			     pxa910_auxdata_lookup, NULL);
 }
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 392d780..83182e5 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -2,7 +2,7 @@
 # Makefile for mmp specific clk
 #
 
-obj-y += clk-apbc.o clk-apmu.o clk-frac.o
+obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mmp.o
 
 obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
 obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
diff --git a/drivers/clk/mmp/clk-mmp.c b/drivers/clk/mmp/clk-mmp.c
new file mode 100644
index 0000000..50c16a0
--- /dev/null
+++ b/drivers/clk/mmp/clk-mmp.c
@@ -0,0 +1,300 @@
+/*
+ * Marvell MMP clock driver
+ *
+ * Copyright (c) 2012-2013 Linaro Limited.
+ *
+ * Author: Haojian Zhuang <haojian.zhuang at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+
+#include "clk.h"
+
+enum {
+	MMP_MPMU = 0,
+	MMP_APMU,
+	MMP_APBC,
+	MMP_APBCP,
+	MMP_APB,
+	MMP_MAX,
+};
+
+static void __iomem *mmp_clk_base[MMP_MAX];
+
+static DEFINE_SPINLOCK(mmp_clk_lock);
+
+static const struct of_device_id mmp_of_match[] = {
+	{ .compatible = "marvell,mmp-mpmu", .data = (void *)MMP_MPMU, },
+	{ .compatible = "marvell,mmp-apmu", .data = (void *)MMP_APMU, },
+	{ .compatible = "marvell,mmp-apbc", .data = (void *)MMP_APBC, },
+	{ .compatible = "marvell,mmp-apbcp", .data = (void *)MMP_APBCP, },
+	{ .compatible = "mrvl,apb-bus", .data = (void *)MMP_APB, },
+};
+
+void __iomem __init *mmp_init_clocks(struct device_node *np)
+{
+	struct device_node *parent;
+	const struct of_device_id *match;
+	void __iomem *ret = NULL;
+	int i;
+
+	parent = of_get_parent(np);
+	if (!parent)
+		goto out;
+	match = of_match_node(mmp_of_match, parent);
+	if (!match)
+		goto out;
+
+	i = (unsigned int)match->data;
+	switch (i) {
+	case MMP_MPMU:
+	case MMP_APMU:
+	case MMP_APBC:
+	case MMP_APBCP:
+	case MMP_APB:
+		if (!mmp_clk_base[i]) {
+			ret = of_iomap(parent, 0);
+			WARN_ON(!ret);
+			mmp_clk_base[i] = ret;
+		} else {
+			ret = mmp_clk_base[i];
+		}
+		break;
+	default:
+		goto out;
+	}
+out:
+	return ret;
+}
+
+static void __init mmp_fixed_rate_setup(struct device_node *np)
+{
+	struct clk *clk;
+	const char *clk_name, *parent_name;
+	int rate;
+
+	if (of_property_read_u32(np, "clock-frequency", &rate))
+		return;
+
+	if (of_property_read_string(np, "clock-output-names", &clk_name))
+		return;
+
+	/* this node has only one parent */
+	parent_name = of_clk_get_parent_name(np, 0);
+	if (!parent_name)
+		return;
+
+	clk = clk_register_fixed_rate(NULL, clk_name, parent_name, 0, rate);
+	if (IS_ERR(clk))
+		return;
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+}
+CLK_OF_DECLARE(mmp_fixed_rate, "marvell,mmp-fixed-clkrate",
+	       mmp_fixed_rate_setup);
+
+static void __init mmp_fixed_factor_setup(struct device_node *np)
+{
+	struct clk *clk;
+	const char *clk_name, *parent_name;
+	u32 data[2];
+
+	if (of_property_read_u32_array(np, "mmp-fixed-factor",
+				&data[0], 2))
+		return;
+	if (of_property_read_string(np, "clock-output-names", &clk_name))
+		return;
+
+	/* this node has only one parent */
+	parent_name = of_clk_get_parent_name(np, 0);
+	if (!parent_name)
+		return;
+
+	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
+			data[0], data[1]);
+	if (IS_ERR(clk))
+		return;
+	clk_register_clkdev(clk, clk_name, NULL);
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+}
+CLK_OF_DECLARE(mmp_fixed_factor, "marvell,mmp-fixed-clkfactor",
+	       mmp_fixed_factor_setup);
+
+static void __init mmp_apmu_div_setup(struct device_node *np)
+{
+	u32 data[2];
+	u8 shift, width;
+	void __iomem *reg, *base;
+	const char *parent_name, *clk_name;
+	struct clk *clk;
+
+	base = mmp_init_clocks(np);
+	if (!base)
+		return;
+
+	if (of_property_read_u32_array(np, "mmp-clk-reg", &data[0], 2))
+		return;
+	reg = base + data[0];
+	shift = ffs(data[1]) - 1;
+	width = fls(data[1]) - ffs(data[1]) + 1;
+
+	parent_name = of_clk_get_parent_name(np, 0);
+	if (!parent_name)
+		return;
+	if (of_property_read_string(np, "clock-output-names", &clk_name))
+		return;
+
+	clk = clk_register_divider(NULL, clk_name, parent_name,
+			CLK_SET_RATE_PARENT, reg, shift, width, 0,
+			&mmp_clk_lock);
+	if (IS_ERR(clk))
+		return;
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	return;
+}
+CLK_OF_DECLARE(mmp_div, "marvell,mmp-apmu-clkdiv", mmp_apmu_div_setup);
+
+static int __init mmp_parse_mux(struct device_node *np,
+				u8 *num_parents,
+				u32 *clk_sel)
+{
+	int i, cnt, ret;
+
+	/* get the count of items in mux */
+	for (i = 0, cnt = 0; ; i++, cnt++) {
+		/* parent's #clock-cells property is always 0 */
+		if (!of_parse_phandle(np, "clocks", i))
+			break;
+	}
+
+	for (i = 0; i < cnt; i++) {
+		if (!of_clk_get_parent_name(np, i))
+			break;
+	}
+	*num_parents = cnt;
+	clk_sel = kzalloc(sizeof(u32 *) * cnt, GFP_KERNEL);
+	if (!clk_sel)
+		return -ENOMEM;
+	ret = of_property_read_u32_array(np, "mmp-clk-sel", clk_sel, cnt);
+	if (ret)
+		goto err;
+	return 0;
+err:
+	kfree(clk_sel);
+	return ret;
+}
+
+static void __init mmp_mux_setup(struct device_node *np)
+{
+	u32 data[2], mask, *clk_sel = NULL, mux_flags = 0;
+	u8 shift, num_parents;
+	void __iomem *reg, *base;
+	const char **parent_names;
+	const char *clk_name;
+	struct clk *clk;
+	int i, ret;
+
+	base = mmp_init_clocks(np);
+	if (!base)
+		return;
+	if (of_property_read_string(np, "clock-output-names", &clk_name))
+		return;
+	if (of_property_read_u32_array(np, "mmp-clk-reg", &data[0], 2))
+		return;
+	ret = mmp_parse_mux(np, &num_parents, clk_sel);
+	if (ret)
+		return;
+
+	reg = base + data[0];
+	shift = ffs(data[1]) - 1;
+	mask = data[1] >> shift;
+
+	parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
+	if (!parent_names)
+		goto err;
+	for (i = 0; i < num_parents; i++)
+		parent_names[i] = of_clk_get_parent_name(np, i);
+	clk = clk_register_mux_table(NULL, clk_name, parent_names, num_parents,
+				     CLK_SET_RATE_PARENT, reg, shift, mask,
+				     mux_flags, clk_sel, &mmp_clk_lock);
+	if (IS_ERR(clk))
+		goto err_clk;
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+	return;
+err_clk:
+	kfree(parent_names);
+err:
+	kfree(clk_sel);
+}
+CLK_OF_DECLARE(mmp_mux, "marvell,mmp-clkmux", mmp_mux_setup);
+
+#define APBC_NO_BUS_CTRL	BIT(0)
+#define APBC_POWER_CTRL		BIT(1)
+
+static void __init mmp_apbc_setup(struct device_node *np)
+{
+	u32 data[2], delay, apbc_flags, clkdev;
+	void __iomem *reg, *base;
+	const char **parent_names;
+	const char *clk_name = NULL;
+	struct clk *clk;
+
+	base = mmp_init_clocks(np);
+	if (!base)
+		return;
+
+	if (of_property_read_string(np, "clock-names", &clk_name))
+		clkdev = 1;
+	else {
+		of_property_read_string(np, "clock-output-names", &clk_name);
+		clkdev = 0;
+	}
+
+	if (of_property_read_u32_array(np, "mmp-clk-reg", &data[0], 2))
+		return;
+	/* If mmp-clk-delay property isn't defined, set delay as 10us */
+	if (of_property_read_u32(np, "mmp-clk-delay", &delay))
+		delay = 10;
+	if (of_get_property(np, "mmp-apbc-power-ctrl", NULL))
+		apbc_flags |= APBC_POWER_CTRL;
+
+	reg = base + data[0];
+
+	/* only has the fixed parent */
+	parent_names = kzalloc(sizeof(char *), GFP_KERNEL);
+	if (!parent_names)
+		return;
+	parent_names[0] = of_clk_get_parent_name(np, 0);
+
+	clk = mmp_clk_register_apbc(clk_name, parent_names[0],
+				    reg, delay, 0, &mmp_clk_lock);
+	if (IS_ERR(clk)) {
+		kfree(parent_names);
+		return;
+	}
+	if (clkdev)
+		clk_register_clkdev(clk, clk_name, NULL);
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+}
+CLK_OF_DECLARE(mmp_apbc, "marvell,mmp-apbc-clk", mmp_apbc_setup);
-- 
1.8.1.2



From haojian.zhuang at gmail.com  Fri Jul 26 06:05:32 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 26 Jul 2013 18:05:32 +0800
Subject: [PATCH v6 10/11] ARM: dts: support common clock in arch mmp
In-Reply-To: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
References: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
Message-ID: <1374833133-21119-11-git-send-email-haojian.zhuang@gmail.com>

Support common clock in DTS file for arch mmp.

Signed-off-by: Haojian Zhuang <haojian.zhuang at gmail.com>
---
 arch/arm/boot/dts/pxa168-aspenite.dts |   3 +
 arch/arm/boot/dts/pxa168-clk.dtsi     | 304 ++++++++++++++++++
 arch/arm/boot/dts/pxa168.dtsi         |  10 +
 arch/arm/boot/dts/pxa910-clk.dtsi     | 569 ++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/pxa910-dkb.dts      |  11 +
 arch/arm/boot/dts/pxa910.dtsi         |  12 +-
 6 files changed, 908 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/pxa168-clk.dtsi
 create mode 100644 arch/arm/boot/dts/pxa910-clk.dtsi

diff --git a/arch/arm/boot/dts/pxa168-aspenite.dts b/arch/arm/boot/dts/pxa168-aspenite.dts
index e762fac..2597e98 100644
--- a/arch/arm/boot/dts/pxa168-aspenite.dts
+++ b/arch/arm/boot/dts/pxa168-aspenite.dts
@@ -24,6 +24,9 @@
 
 	soc {
 		apb at d4000000 {
+			timer0: timer at d4014000 {
+				status = "okay";
+			};
 			uart1: uart at d4017000 {
 				status = "okay";
 			};
diff --git a/arch/arm/boot/dts/pxa168-clk.dtsi b/arch/arm/boot/dts/pxa168-clk.dtsi
new file mode 100644
index 0000000..c0d5bd1
--- /dev/null
+++ b/arch/arm/boot/dts/pxa168-clk.dtsi
@@ -0,0 +1,304 @@
+/*
+ *  Copyright (C) 2013
+ *  Author: Haojian Zhuang <haojian.zhuang at gmail.com>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  publishhed by the Free Software Foundation.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	soc {
+		apb at d4000000 {	/* APB */
+			compatible = "mrvl,apb-bus", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0xd4000000 0x00200000>;
+			ranges;
+
+			mpmu: clocks at 50000 {
+				compatible = "marvell,mmp-mpmu";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				reg = <0xd4050000 0x1100>;
+
+				osc_32k: osc32khz {
+					compatible = "fixed-clock";
+					#clock-cells = <0>;
+					clock-frequency = <32768>;
+					clock-output-names = "osc32khz";
+				};
+				osc_26m: osc26mhz {
+					compatible = "fixed-clock";
+					#clock-cells = <0>;
+					clock-frequency = <26000000>;
+					clock-output-names = "osc26mhz";
+				};
+				pll1_312m: refclk312mhz {
+					compatible = "marvell,mmp-fixed-clkrate";
+					#clock-cells = <0>;
+					clocks = <&osc_26m>;
+					clock-frequency = <312000000>;
+					clock-output-names = "refclk312mhz";
+				};
+				refclk156m: refclk156mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&pll1_312m>;
+					clock-output-names = "refclk156mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <1 2>;
+				};
+				refclk118m: refclk117mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&refclk156m>;
+					/* 117.9648MHz */
+					clock-output-names = "refclk118mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <6144 8125>;
+				};
+				refclk104m: refclk104mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&pll1_312m>;
+					clock-output-names = "refclk104mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <1 3>;
+				};
+				refclk59m: refclk59mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&refclk118m>;
+					clock-names = "baud_58.98mhz";
+					/* 58.9824MHz */
+					clock-output-names = "refclk59mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <1 2>;
+				};
+				refclk15m: refclk15mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&refclk156m>;
+					clock-names = "baud_14.86mhz";
+					/* 14.857MHz */
+					clock-output-names = "refclk15mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <2 21>;
+				};
+			};
+
+			apbc: clocks at 15000 {
+				compatible = "marvell,mmp-apbc";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				#clock-cells = <0>;
+				reg = <0xd4015000 0x100>;
+
+				apbc_twsi1_clk: apbc_twsi1_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&refclk32m>;
+					clock-names = "apbc_twsi1_clk";
+					/* register value of each item */
+					mmp-clk-sel = <0>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x2c 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_twsi2_clk: apbc_twsi2_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&refclk32m>;
+					clock-names = "apbc_twsi2_clk";
+					/* register value of each item */
+					mmp-clk-sel = <0>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x6c 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_rtc_clk: apbc_rtc_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&osc_32k>;
+					clock-names = "apbc_rtc_clk";
+					mmp-clk-sel = <0>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x28 0x70>;
+					marvell,mmp-apbc-power-ctl;
+					mmp-clk-delay = <10>;
+				};
+				apbc_gpio_clk: apbc_gpio_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&refclk26m>;
+					clock-names = "apbc_gpio_clk";
+					mmp-clk-sel = <0>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x8 0x0>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_uart1_mux: apbc_uart1_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk59m &refclk15m>;
+					clock-output-names = "apbc_uart1_mux";
+					/* register offset & mask */
+					mmp-clk-reg = <0x0 0x70>;
+					/* register value of each item */
+					mmp-clk-sel = <0 0x10>;
+				};
+				apbc_uart1_clk: apbc_uart1_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_uart1_mux>;
+					clock-names = "apbc_uart1_clk";
+					mmp-clk-reg = <0x0 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_uart2_mux: apbc_uart2_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk59m &refclk15m>;
+					clock-output-names = "apbc_uart2_mux";
+					/* register offset & mask */
+					mmp-clk-reg = <0x4 0x70>;
+					/* register value of each item */
+					mmp-clk-sel = <0 0x10>;
+				};
+				apbc_uart2_clk: apbc_uart2_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_uart2_mux>;
+					clock-names = "apbc_uart2_clk";
+					mmp-clk-reg = <0x4 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_uart3_mux: apbc_uart3_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk59m &refclk15m>;
+					clock-output-names = "apbc_uart3_mux";
+					/* register offset & mask */
+					mmp-clk-reg = <0x70 0x70>;
+					/* register value of each item */
+					mmp-clk-sel = <0 0x10>;
+				};
+				apbc_uart3_clk: apbc_uart3_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_uart3_mux>;
+					clock-names = "apbc_uart3_clk";
+					mmp-clk-reg = <0x70 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_pwm1_mux: apbc_pwm1_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk13m &osc_32k>;
+					clock-output-names = "apbc_pwm1_mux";
+					mmp-clk-sel = <0 0x10>;
+					mmp-clk-reg = <0xc 0x70>;
+				};
+				apbc_pwm1_clk: apbc_pwm1_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_pwm1_mux>;
+					clock-names = "apbc_pwm1_clk";
+					mmp-clk-reg = <0xc 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_pwm2_mux: apbc_pwm2_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk13m &osc_32k>;
+					clock-output-names = "apbc_pwm2_mux";
+					mmp-clk-sel = <0 0x10>;
+					mmp-clk-reg = <0x10 0x70>;
+				};
+				apbc_pwm2_clk: apbc_pwm2_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_pwm2_mux>;
+					clock-names = "apbc_pwm2_clk";
+					mmp-clk-reg = <0x10 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_pwm3_mux: apbc_pwm3_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk13m &osc_32k>;
+					clock-output-names = "apbc_pwm3_mux";
+					mmp-clk-sel = <0 0x10>;
+					mmp-clk-reg = <0x14 0x70>;
+				};
+				apbc_pwm3_clk: apbc_pwm3_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_pwm3_mux>;
+					clock-names = "apbc_pwm3_clk";
+					mmp-clk-reg = <0x14 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_pwm4_mux: apbc_pwm4_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk13m &osc_32k>;
+					clock-output-names = "apbc_pwm4_mux";
+					mmp-clk-sel = <0 0x10>;
+					mmp-clk-reg = <0x18 0x70>;
+				};
+				apbc_pwm4_clk: apbc_pwm4_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_pwm4_mux>;
+					clock-names = "apbc_pwm4_clk";
+					mmp-clk-reg = <0x18 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_kpc_mux: apbc_kpc_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&osc_32k &refclk16k &refclk26m>;
+					clock-output-names = "apbc_kpc_mux";
+					mmp-clk-sel = <0 0x10 0x20>;
+					mmp-clk-reg = <0x30 0x70>;
+				};
+				apbc_kpc_clk: apbc_kpc_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_kpc_mux>;
+					clock-names = "apbc_kpc_clk";
+					mmp-clk-reg = <0x30 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_timer0_mux: apbc_timer0_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk13m &osc_32k &refclk7m &refclk3m>;
+					clock-output-names = "apbc_timer0_mux";
+					mmp-clk-sel = <0 0x10 0x20 0x30>;
+					mmp-clk-reg = <0x34 0x70>;
+				};
+				apbc_timer0_clk: apbc_timer0_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&timer0_mux>;
+					clock-names = "apbc_timer0_clk";
+					mmp-clk-reg = <0x34 0x70>;
+					mmp-clk-delay = <10>;
+				};
+			};
+			timer0_mux: timer0_mux {
+				compatible = "marvell,mmp-clkmux";
+				#clock-cells = <0>;
+				clocks = <&apbc_timer0_mux &osc_32k>;
+				clock-output-names = "timer0_mux";
+				mmp-clk-sel = <0 0x2>;
+				mmp-clk-reg = <0x14000 0x1c>;
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/pxa168.dtsi b/arch/arm/boot/dts/pxa168.dtsi
index 975dad2..250bf2c 100644
--- a/arch/arm/boot/dts/pxa168.dtsi
+++ b/arch/arm/boot/dts/pxa168.dtsi
@@ -8,6 +8,7 @@
  */
 
 /include/ "skeleton.dtsi"
+/include/ "pxa910-clk.dtsi"
 
 / {
 	aliases {
@@ -53,12 +54,15 @@
 				compatible = "mrvl,mmp-timer";
 				reg = <0xd4014000 0x100>;
 				interrupts = <13>;
+				clocks = <&apbc_timer0_clk>;
+				status = "disabled";
 			};
 
 			uart1: uart at d4017000 {
 				compatible = "mrvl,mmp-uart";
 				reg = <0xd4017000 0x1000>;
 				interrupts = <27>;
+				clocks = <&apbc_uart1_clk>;
 				status = "disabled";
 			};
 
@@ -66,6 +70,7 @@
 				compatible = "mrvl,mmp-uart";
 				reg = <0xd4018000 0x1000>;
 				interrupts = <28>;
+				clocks = <&apbc_uart2_clk>;
 				status = "disabled";
 			};
 
@@ -73,6 +78,7 @@
 				compatible = "mrvl,mmp-uart";
 				reg = <0xd4026000 0x1000>;
 				interrupts = <29>;
+				clocks = <&apbc_uart3_clk>;
 				status = "disabled";
 			};
 
@@ -87,6 +93,7 @@
 				interrupt-names = "gpio_mux";
 				interrupt-controller;
 				#interrupt-cells = <1>;
+				clocks = <&apbc_gpio_clk>;
 				ranges;
 
 				gcb0: gpio at d4019000 {
@@ -111,6 +118,7 @@
 				reg = <0xd4011000 0x1000>;
 				interrupts = <7>;
 				mrvl,i2c-fast-mode;
+				clocks = <&apbc_twsi1_clk>;
 				status = "disabled";
 			};
 
@@ -118,6 +126,7 @@
 				compatible = "mrvl,mmp-twsi";
 				reg = <0xd4025000 0x1000>;
 				interrupts = <58>;
+				clocks = <&apbc_twsi2_clk>;
 				status = "disabled";
 			};
 
@@ -126,6 +135,7 @@
 				reg = <0xd4010000 0x1000>;
 				interrupts = <5 6>;
 				interrupt-names = "rtc 1Hz", "rtc alarm";
+				clocks = <&apbc_rtc_clk>;
 				status = "disabled";
 			};
 		};
diff --git a/arch/arm/boot/dts/pxa910-clk.dtsi b/arch/arm/boot/dts/pxa910-clk.dtsi
new file mode 100644
index 0000000..2d9f9ca
--- /dev/null
+++ b/arch/arm/boot/dts/pxa910-clk.dtsi
@@ -0,0 +1,569 @@
+/*
+ *  Copyright (C) 2013
+ *  Author: Haojian Zhuang <haojian.zhuang at gmail.com>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  publishhed by the Free Software Foundation.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	soc {
+		axi at d4200000 {	/* AXI */
+			compatible = "mrvl,axi-bus", "simple-bus";
+			reg = <0xd4200000 0x00200000>;
+			ranges;
+
+			apmu: clocks at 82800 {
+				compatible = "marvell,mmp-apmu";
+				reg = <0xd4282800 0x100>;
+
+				/*
+				 * Processor clocks: pclk, pdclk, baclk, xpclk
+				 * DDR Controller clocks: dclk
+				 * AXI Fabric clocks: aclk
+				 */
+				pclk_refclk: refclk_pclk {
+					compatible = "marvell,mmp-apmu-clkdiv";
+					#clock-cells = <0>;
+					clocks = <&pj1_refclk>;
+					clock-output-names = "pclk";
+					marvell,mmp-clock-frequency = <104000000 156000000 208000000 312000000 500500000 624000000 806000000 1001000000>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x4 0x7>;
+				};
+				/* pdclk -- DDR Interface clock */
+				pdclk_refclk: refclk_pdclk {
+					compatible = "marvell,mmp-apmu-clkdiv";
+					#clock-cells = <0>;
+					clocks = <&pj1_refclk>;
+					clock-output-names = "pdclk";
+					marvell,mmp-clock-frequency = <78000000 104000000 156000000 201000000 250250000>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x4 0x38>;
+				};
+				/* baclk -- AXI Fabric Bus Interface clock */
+				baclk_refclk: refclk_baclk {
+					compatible = "marvell,mmp-apmu-clkdiv";
+					#clock-cells = <0>;
+					clocks = <&pj1_refclk>;
+					clock-output-names = "baclk";
+					marvell,mmp-clock-frequency = <78000000 104000000 156000000 201000000 250250000>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x4 0x1c0>;
+				};
+				/* xpclk -- L2 interface clock */
+				xpclk_refclk: refclk_xpclk {
+					compatible = "marvell,mmp-apmu-clkdiv";
+					#clock-cells = <0>;
+					clocks = <&pj1_refclk>;
+					clock-output-names = "xpclk";
+					marvell,mmp-clock-frequency = <104000000 156000000 250250000 312000000 403000000 500500000>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x4 0xe00>;
+				};
+				/* dclk -- DDR Controller clock */
+				dclk2x_refclk: refclk_dclk2x {
+					compatible = "marvell,mmp-apmu-clkdiv";
+					#clock-cells = <0>;
+					clocks = <&ddr_refclk>;
+					clock-output-names = "dclk2x";
+					marvell,mmp-clock-frequency = <208000000 312000000 402000000 500500000>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x4 0x7000>;
+				};
+				dclk_refclk: refclk_dclk {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&dclk2x_refclk>;
+					clock-output-names = "dclk";
+					/* multiple & divider */
+					mmp-fixed-factor = <1 2>;
+				};
+				/* aclk -- AXI Fabric clock */
+				aclk_refclk: refclk_aclk {
+					compatible = "marvell,mmp-apmu-clkdiv";
+					#clock-cells = <0>;
+					clocks = <&axi_refclk>;
+					clock-output-names = "aclk";
+					marvell,mmp-clock-frequency = <104000000 156000000>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x4 0x38000>;
+				};
+			};
+		};
+
+		apb at d4000000 {	/* APB */
+			compatible = "mrvl,apb-bus", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0xd4000000 0x00200000>;
+			ranges;
+
+			mpmu: clocks at 50000 {
+				compatible = "marvell,mmp-mpmu";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				reg = <0xd4050000 0x1100>;
+
+				osc_32k: osc32khz {
+					compatible = "fixed-clock";
+					#clock-cells = <0>;
+					clock-frequency = <32768>;
+					clock-output-names = "osc32khz";
+				};
+				osc_26m: osc26mhz {
+					compatible = "fixed-clock";
+					#clock-cells = <0>;
+					clock-frequency = <26000000>;
+					clock-output-names = "osc26mhz";
+				};
+				pll1_312m: refclk312mhz {
+					compatible = "marvell,mmp-fixed-clkrate";
+					#clock-cells = <0>;
+					clocks = <&osc_26m>;
+					clock-frequency = <312000000>;
+					clock-output-names = "refclk312mhz";
+				};
+				pll1_624m: refclk624mhz {
+					compatible = "marvell,mmp-fixed-clkrate";
+					#clock-cells = <0>;
+					clocks = <&osc_26m>;
+					clock-frequency = <624000000>;
+					clock-output-names = "refclk624mhz";
+				};
+				pj1_refclk: refclk_pj1 {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&pll1_312m &pll1_624m &pll2>;
+					clock-output-names = "refclk_pj1";
+					/* register value of each item */
+					mmp-clk-sel = <0 0x20000000 0x40000000>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x8 0xe0000000>;
+				};
+				ddr_refclk: refclk_ddr {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&pll1_312m &pll1_624m &pll2>;
+					clock-output-names = "refclk_ddr";
+					/* register value of each item */
+					mmp-clk-sel = <0 0x00800000 0x01000000>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x8 0x01800000>;
+				};
+				axi_refclk: refclk_axi {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&pll1_312m &pll1_624m>;
+					clock-output-names = "refclk_axi";
+					/* register value of each item */
+					mmp-clk-sel = <0 0x00080000>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x8 0x00080000>;
+				};
+				refclk156m: refclk156mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&pll1_312m>;
+					clock-output-names = "refclk156mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <1 2>;
+				};
+				refclk118m: refclk117mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&refclk156m>;
+					/* 117.9648MHz */
+					clock-output-names = "refclk118mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <6144 8125>;
+				};
+				refclk104m: refclk104mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&pll1_312m>;
+					clock-output-names = "refclk104mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <1 3>;
+				};
+				refclk59m: refclk59mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&refclk118m>;
+					clock-names = "baud_58.98mhz";
+					/* 58.9824MHz */
+					clock-output-names = "refclk59mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <1 2>;
+				};
+				refclk52m: refclk52mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&refclk104m>;
+					clock-output-names = "refclk52mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <1 2>;
+				};
+				refclk48m: refclk48mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&pll1_624m>;
+					clock-output-names = "refclk48mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <1 13>;
+				};
+				refclk32m: refclk32mhz@ {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&refclk48m>;
+					clock-output-names = "refclk32mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <2 3>;
+				};
+				refclk26m: refclk26mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&refclk52m>;
+					clock-output-names = "refclk26mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <1 2>;
+				};
+				refclk15m: refclk15mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&refclk156m>;
+					clock-names = "baud_14.86mhz";
+					/* 14.857MHz */
+					clock-output-names = "refclk15mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <2 21>;
+				};
+				refclk13m: refclk13mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&refclk26m>;
+					clock-output-names = "refclk13mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <1 2>;
+				};
+				refclk7m: refclk7mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&refclk13m>;
+					clock-output-names = "refclk7mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <1 2>;
+				};
+				refclk3m: refclk3mhz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&refclk7m>;
+					clock-output-names = "refclk3mhz";
+					/* multiple & divider */
+					mmp-fixed-factor = <1 2>;
+				};
+				refclk16k: refclk16khz {
+					compatible = "marvell,mmp-fixed-clkfactor";
+					#clock-cells = <0>;
+					clocks = <&osc_32k>;
+					clock-output-names = "refclk16khz";
+					/* multiple & divider */
+					mmp-fixed-factor = <1 2>;
+				};
+			};
+
+			apbc: clocks at 15000 {
+				compatible = "marvell,mmp-apbc";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				#clock-cells = <0>;
+				reg = <0xd4015000 0x100>;
+
+				apbc_twsi1_clk: apbc_twsi1_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&refclk32m>;
+					clock-names = "apbc_twsi1_clk";
+					/* register value of each item */
+					mmp-clk-sel = <0>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x2c 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_rtc_clk: apbc_rtc_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&osc_32k>;
+					clock-names = "apbc_rtc_clk";
+					mmp-clk-sel = <0>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x28 0x70>;
+					marvell,mmp-apbc-power-ctl;
+					mmp-clk-delay = <10>;
+				};
+				apbc_gpio_clk: apbc_gpio_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&refclk26m>;
+					clock-names = "apbc_gpio_clk";
+					mmp-clk-sel = <0>;
+					/* register offset & mask */
+					mmp-clk-reg = <0x8 0x0>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_uart1_mux: apbc_uart1_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk59m &refclk15m>;
+					clock-output-names = "apbc_uart1_mux";
+					/* register offset & mask */
+					mmp-clk-reg = <0x0 0x70>;
+					/* register value of each item */
+					mmp-clk-sel = <0 0x10>;
+				};
+				apbc_uart1_clk: apbc_uart1_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_uart1_mux>;
+					clock-names = "apbc_uart1_clk";
+					mmp-clk-reg = <0x0 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_uart2_mux: apbc_uart2_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk59m &refclk15m>;
+					clock-output-names = "apbc_uart2_mux";
+					/* register offset & mask */
+					mmp-clk-reg = <0x4 0x70>;
+					/* register value of each item */
+					mmp-clk-sel = <0 0x10>;
+				};
+				apbc_uart2_clk: apbc_uart2_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_uart2_mux>;
+					clock-names = "apbc_uart2_clk";
+					mmp-clk-reg = <0x4 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_pwm1_mux: apbc_pwm1_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk13m &osc_32k>;
+					clock-output-names = "apbc_pwm1_mux";
+					mmp-clk-sel = <0 0x10>;
+					mmp-clk-reg = <0xc 0x70>;
+				};
+				apbc_pwm1_clk: apbc_pwm1_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_pwm1_mux>;
+					clock-names = "apbc_pwm1_clk";
+					mmp-clk-reg = <0xc 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_pwm2_mux: apbc_pwm2_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk13m &osc_32k>;
+					clock-output-names = "apbc_pwm2_mux";
+					mmp-clk-sel = <0 0x10>;
+					mmp-clk-reg = <0x10 0x70>;
+				};
+				apbc_pwm2_clk: apbc_pwm2_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_pwm2_mux>;
+					clock-names = "apbc_pwm2_clk";
+					mmp-clk-reg = <0x10 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_pwm3_mux: apbc_pwm3_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk13m &osc_32k>;
+					clock-output-names = "apbc_pwm3_mux";
+					mmp-clk-sel = <0 0x10>;
+					mmp-clk-reg = <0x14 0x70>;
+				};
+				apbc_pwm3_clk: apbc_pwm3_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_pwm3_mux>;
+					clock-names = "apbc_pwm3_clk";
+					mmp-clk-reg = <0x14 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_pwm4_mux: apbc_pwm4_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk13m &osc_32k>;
+					clock-output-names = "apbc_pwm4_mux";
+					mmp-clk-sel = <0 0x10>;
+					mmp-clk-reg = <0x18 0x70>;
+				};
+				apbc_pwm4_clk: apbc_pwm4_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_pwm4_mux>;
+					clock-names = "apbc_pwm4_clk";
+					mmp-clk-reg = <0x18 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_ssp1_mux: apbc_ssp1_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk7m &refclk13m &refclk26m &refclk52m>;
+					clock-output-names = "apbc_ssp1_mux";
+					mmp-clk-sel = <0 0x10 0x20 0x30>;
+					mmp-clk-reg = <0x1c 0x70>;
+				};
+				apbc_ssp1_clk: apbc_ssp1_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_ssp1_mux>;
+					clock-names = "apbc_ssp1_clk";
+					mmp-clk-reg = <0x1c 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_ssp2_mux: apbc_ssp2_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk7m &refclk13m &refclk26m &refclk52m>;
+					clock-output-names = "apbc_ssp2_mux";
+					mmp-clk-sel = <0 0x10 0x20 0x30>;
+					mmp-clk-reg = <0x20 0x70>;
+				};
+				apbc_ssp2_clk: apbc_ssp2_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_ssp2_mux>;
+					clock-names = "apbc_ssp2_clk";
+					mmp-clk-reg = <0x20 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_ssp3_mux: apbc_ssp3_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk7m &refclk13m &refclk26m &refclk52m>;
+					clock-output-names = "apbc_ssp3_mux";
+					mmp-clk-sel = <0 0x10 0x20 0x30>;
+					mmp-clk-reg = <0x4c 0x70>;
+				};
+				apbc_ssp3_clk: apbc_ssp3_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_ssp3_mux>;
+					clock-names = "apbc_ssp3_clk";
+					mmp-clk-reg = <0x4c 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_kpc_mux: apbc_kpc_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&osc_32k &refclk16k &refclk26m>;
+					clock-output-names = "apbc_kpc_mux";
+					mmp-clk-sel = <0 0x10 0x20>;
+					mmp-clk-reg = <0x30 0x70>;
+				};
+				apbc_kpc_clk: apbc_kpc_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbc_kpc_mux>;
+					clock-names = "apbc_kpc_clk";
+					mmp-clk-reg = <0x30 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_timer0_mux: apbc_timer0_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk13m &osc_32k &refclk7m &refclk3m>;
+					clock-output-names = "apbc_timer0_mux";
+					mmp-clk-sel = <0 0x10 0x20 0x30>;
+					mmp-clk-reg = <0x34 0x70>;
+				};
+				apbc_timer0_clk: apbc_timer0_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&timer0_mux>;
+					clock-names = "apbc_timer0_clk";
+					mmp-clk-reg = <0x34 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbc_timer1_mux: apbc_timer1_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk13m &osc_32k &refclk7m &refclk3m>;
+					clock-output-names = "apbc_timer1_mux";
+					mmp-clk-sel = <0 0x10 0x20 0x30>;
+					mmp-clk-reg = <0x44 0x70>;
+				};
+				apbc_timer1_clk: apbc_timer1_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&timer1_mux>;
+					clock-names = "apbc_timer1_clk";
+					mmp-clk-reg = <0x44 0x70>;
+					mmp-clk-delay = <10>;
+				};
+			};
+
+			apbcp: clocks at 3b000 {
+				compatible = "marvell,mmp-apbcp";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				reg = <0xd403b000 0x100>;
+
+				apbcp_twsi2_clk: apbcp_twsi2_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&refclk32m>;
+					clock-output-names = "apbcp_twsi2_clk";
+					/* register offset & mask */
+					mmp-clk-reg = <0x28 0x70>;
+					mmp-clk-delay = <10>;
+				};
+				apbcp_uart3_mux: apbcp_uart3_mux {
+					compatible = "marvell,mmp-clkmux";
+					#clock-cells = <0>;
+					clocks = <&refclk59m &refclk15m>;
+					clock-output-names = "apbcp_uart3_mux";
+					/* register offset & mask */
+					mmp-clk-reg = <0x1c 0x70>;
+					/* register value of each item */
+					mmp-clk-sel = <0 0x10>;
+				};
+				apbcp_uart3_clk: apbcp_uart3_clk {
+					compatible = "marvell,mmp-apbc-clk";
+					#clock-cells = <0>;
+					clocks = <&apbcp_uart3_mux>;
+					clock-names = "apbcp_uart3_clk";
+					mmp-clk-reg = <0x1c 0x70>;
+					mmp-clk-delay = <10>;
+				};
+			};
+
+			timer0_mux: timer0_mux {
+				compatible = "marvell,mmp-clkmux";
+				#clock-cells = <0>;
+				clocks = <&refclk3m &osc_32k &apbc_timer0_mux>;
+				clock-output-names = "timer0_mux";
+				mmp-clk-sel = <0 0x1 0x3>;
+				mmp-clk-reg = <0x14000 0x1c>;
+			};
+
+			timer1_mux: timer1_mux {
+				compatible = "marvell,mmp-clkmux";
+				#clock-cells = <0>;
+				clocks = <&refclk3m &osc_32k &apbc_timer1_mux>;
+				clock-output-names = "timer1_mux";
+				mmp-clk-sel = <0 0x1 0x3>;
+				mmp-clk-reg = <0x16000 0x1c>;
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/pxa910-dkb.dts b/arch/arm/boot/dts/pxa910-dkb.dts
index 595492a..b892ebe 100644
--- a/arch/arm/boot/dts/pxa910-dkb.dts
+++ b/arch/arm/boot/dts/pxa910-dkb.dts
@@ -24,6 +24,17 @@
 
 	soc {
 		apb at d4000000 {
+			pll2: refclk1001mhz {
+				/* Reference clock for internal PLL2 */
+				compatible = "marvell,mmp-fixed-clkrate";
+				#clock-cells = <0>;
+				clocks = <&osc_26m>;
+				clock-frequency = <1001000000>;
+				clock-output-names = "refclk1001mhz";
+			};
+			timer0: timer at d4014000 {
+				status = "okay";
+			};
 			uart1: uart at d4017000 {
 				status = "okay";
 			};
diff --git a/arch/arm/boot/dts/pxa910.dtsi b/arch/arm/boot/dts/pxa910.dtsi
index 0247c62..cd888d3 100644
--- a/arch/arm/boot/dts/pxa910.dtsi
+++ b/arch/arm/boot/dts/pxa910.dtsi
@@ -8,6 +8,7 @@
  */
 
 /include/ "skeleton.dtsi"
+/include/ "pxa910-clk.dtsi"
 
 / {
 	aliases {
@@ -44,7 +45,6 @@
 				reg = <0xd4282000 0x1000>;
 				mrvl,intc-nr-irqs = <64>;
 			};
-
 		};
 
 		apb at d4000000 {	/* APB */
@@ -58,12 +58,15 @@
 				compatible = "mrvl,mmp-timer";
 				reg = <0xd4014000 0x100>;
 				interrupts = <13>;
+				clocks = <&apbc_timer0_clk>;
+				status = "disabled";
 			};
 
 			timer1: timer at d4016000 {
 				compatible = "mrvl,mmp-timer";
 				reg = <0xd4016000 0x100>;
 				interrupts = <29>;
+				clocks = <&apbc_timer1_clk>;
 				status = "disabled";
 			};
 
@@ -71,6 +74,7 @@
 				compatible = "mrvl,mmp-uart";
 				reg = <0xd4017000 0x1000>;
 				interrupts = <27>;
+				clocks = <&apbc_uart1_clk>;
 				status = "disabled";
 			};
 
@@ -78,6 +82,7 @@
 				compatible = "mrvl,mmp-uart";
 				reg = <0xd4018000 0x1000>;
 				interrupts = <28>;
+				clocks = <&apbc_uart2_clk>;
 				status = "disabled";
 			};
 
@@ -85,6 +90,7 @@
 				compatible = "mrvl,mmp-uart";
 				reg = <0xd4036000 0x1000>;
 				interrupts = <59>;
+				clocks = <&apbcp_uart3_clk>;
 				status = "disabled";
 			};
 
@@ -99,6 +105,7 @@
 				interrupt-names = "gpio_mux";
 				interrupt-controller;
 				#interrupt-cells = <1>;
+				clocks = <&apbc_gpio_clk>;
 				ranges;
 
 				gcb0: gpio at d4019000 {
@@ -124,6 +131,7 @@
 				#size-cells = <0>;
 				reg = <0xd4011000 0x1000>;
 				interrupts = <7>;
+				clocks = <&apbc_twsi1_clk>;
 				mrvl,i2c-fast-mode;
 				status = "disabled";
 			};
@@ -134,6 +142,7 @@
 				#size-cells = <0>;
 				reg = <0xd4037000 0x1000>;
 				interrupts = <54>;
+				clocks = <&apbcp_twsi2_clk>;
 				status = "disabled";
 			};
 
@@ -142,6 +151,7 @@
 				reg = <0xd4010000 0x1000>;
 				interrupts = <5 6>;
 				interrupt-names = "rtc 1Hz", "rtc alarm";
+				clocks = <&apbc_rtc_clk>;
 				status = "disabled";
 			};
 		};
-- 
1.8.1.2



From haojian.zhuang at gmail.com  Fri Jul 26 06:05:33 2013
From: haojian.zhuang at gmail.com (Haojian Zhuang)
Date: Fri, 26 Jul 2013 18:05:33 +0800
Subject: [PATCH v6 11/11] ARM: mmp: avoid to use cpu_is_xxx in timer
In-Reply-To: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
References: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
Message-ID: <1374833133-21119-12-git-send-email-haojian.zhuang@gmail.com>

Avoid to use cpu_is_xxx() in timer-mmp driver, since it blocks the
multiplatform build. Now add mmp2_mode variable for legacy mode.
In DT mode, set the right clock rate in DTS file.

Signed-off-by: Haojian Zhuang <haojian.zhuang at gmail.com>
---
 arch/arm/Kconfig                      |  1 +
 arch/arm/boot/dts/mmp2-brownstone.dts |  4 ++
 arch/arm/boot/dts/pxa168-aspenite.dts |  1 +
 arch/arm/boot/dts/pxa910-dkb.dts      |  1 +
 arch/arm/mach-mmp/common.h            |  2 +-
 arch/arm/mach-mmp/mmp-dt.c            | 14 ++++---
 arch/arm/mach-mmp/mmp2-dt.c           | 12 ++++--
 arch/arm/mach-mmp/mmp2.c              |  2 +-
 arch/arm/mach-mmp/pxa168.c            |  2 +-
 arch/arm/mach-mmp/pxa910.c            |  2 +-
 drivers/clocksource/timer-mmp.c       | 72 +++++++++++++++++++++--------------
 11 files changed, 72 insertions(+), 41 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 76793a6..eed4919 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -553,6 +553,7 @@ config ARCH_MMP
 	depends on MMU
 	select ARCH_REQUIRE_GPIOLIB
 	select CLKDEV_LOOKUP
+	select CLKSRC_OF if OF
 	select GENERIC_ALLOCATOR
 	select GENERIC_CLOCKEVENTS
 	select GPIO_PXA
diff --git a/arch/arm/boot/dts/mmp2-brownstone.dts b/arch/arm/boot/dts/mmp2-brownstone.dts
index 7f70a39..29c7dc6 100644
--- a/arch/arm/boot/dts/mmp2-brownstone.dts
+++ b/arch/arm/boot/dts/mmp2-brownstone.dts
@@ -24,6 +24,10 @@
 
 	soc {
 		apb at d4000000 {
+			timer0: timer at d4014000 {
+				clock-frequency = <6500000>;
+				status = "okay";
+			};
 			uart3: uart at d4018000 {
 				status = "okay";
 			};
diff --git a/arch/arm/boot/dts/pxa168-aspenite.dts b/arch/arm/boot/dts/pxa168-aspenite.dts
index 2597e98..9b3d6d9 100644
--- a/arch/arm/boot/dts/pxa168-aspenite.dts
+++ b/arch/arm/boot/dts/pxa168-aspenite.dts
@@ -25,6 +25,7 @@
 	soc {
 		apb at d4000000 {
 			timer0: timer at d4014000 {
+				clock-frequency = <3250000>;
 				status = "okay";
 			};
 			uart1: uart at d4017000 {
diff --git a/arch/arm/boot/dts/pxa910-dkb.dts b/arch/arm/boot/dts/pxa910-dkb.dts
index b892ebe..3cd1a85 100644
--- a/arch/arm/boot/dts/pxa910-dkb.dts
+++ b/arch/arm/boot/dts/pxa910-dkb.dts
@@ -33,6 +33,7 @@
 				clock-output-names = "refclk1001mhz";
 			};
 			timer0: timer at d4014000 {
+				clock-frequency = <3250000>;
 				status = "okay";
 			};
 			uart1: uart at d4017000 {
diff --git a/arch/arm/mach-mmp/common.h b/arch/arm/mach-mmp/common.h
index 22e67c6..2415282 100644
--- a/arch/arm/mach-mmp/common.h
+++ b/arch/arm/mach-mmp/common.h
@@ -1,7 +1,7 @@
 #include <linux/reboot.h>
 #define ARRAY_AND_SIZE(x)	(x), ARRAY_SIZE(x)
 
-extern void timer_init(void __iomem *base, int irq);
+extern void timer_init(void __iomem *base, int irq, int mmp2_mode);
 
 extern void __init mmp_map_io(void);
 extern void mmp_restart(enum reboot_mode, const char *);
diff --git a/arch/arm/mach-mmp/mmp-dt.c b/arch/arm/mach-mmp/mmp-dt.c
index f109bf6..8d0253b 100644
--- a/arch/arm/mach-mmp/mmp-dt.c
+++ b/arch/arm/mach-mmp/mmp-dt.c
@@ -10,6 +10,7 @@
  */
 
 #include <linux/clk-provider.h>
+#include <linux/clocksource.h>
 #include <linux/irqchip.h>
 #include <linux/of_platform.h>
 #include <asm/mach/arch.h>
@@ -17,8 +18,6 @@
 
 #include "common.h"
 
-extern void __init mmp_dt_init_timer(void);
-
 static const struct of_dev_auxdata pxa168_auxdata_lookup[] __initconst = {
 	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.0", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.1", NULL),
@@ -49,7 +48,6 @@ static void __init pxa168_dt_init(void)
 
 static void __init pxa910_dt_init(void)
 {
-	of_clk_init(NULL);
 	of_platform_populate(NULL, of_default_bus_match_table,
 			     pxa910_auxdata_lookup, NULL);
 }
@@ -60,16 +58,22 @@ static const char *mmp_dt_board_compat[] __initdata = {
 	NULL,
 };
 
+static void __init mmp_init_timer(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
 DT_MACHINE_START(PXA168_DT, "Marvell PXA168 (Device Tree Support)")
 	.map_io		= mmp_map_io,
-	.init_time	= mmp_dt_init_timer,
+	.init_time	= mmp_init_timer,
 	.init_machine	= pxa168_dt_init,
 	.dt_compat	= mmp_dt_board_compat,
 MACHINE_END
 
 DT_MACHINE_START(PXA910_DT, "Marvell PXA910 (Device Tree Support)")
 	.map_io		= mmp_map_io,
-	.init_time	= mmp_dt_init_timer,
+	.init_time	= mmp_init_timer,
 	.init_machine	= pxa910_dt_init,
 	.dt_compat	= mmp_dt_board_compat,
 MACHINE_END
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index 023cb45..2229d1d 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -9,6 +9,8 @@
  *  publishhed by the Free Software Foundation.
  */
 
+#include <linux/clk-provider.h>
+#include <linux/clocksource.h>
 #include <linux/io.h>
 #include <linux/irqchip.h>
 #include <linux/of_platform.h>
@@ -17,8 +19,6 @@
 
 #include "common.h"
 
-extern void __init mmp_dt_init_timer(void);
-
 static const struct of_dev_auxdata mmp2_auxdata_lookup[] __initconst = {
 	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4030000, "pxa2xx-uart.0", NULL),
 	OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.1", NULL),
@@ -37,6 +37,12 @@ static void __init mmp2_dt_init(void)
 			     mmp2_auxdata_lookup, NULL);
 }
 
+static void __init mmp2_init_timer(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
 static const char *mmp2_dt_board_compat[] __initdata = {
 	"mrvl,mmp2-brownstone",
 	NULL,
@@ -44,7 +50,7 @@ static const char *mmp2_dt_board_compat[] __initdata = {
 
 DT_MACHINE_START(MMP2_DT, "Marvell MMP2 (Device Tree Support)")
 	.map_io		= mmp_map_io,
-	.init_time	= mmp_dt_init_timer,
+	.init_time	= mmp2_init_timer,
 	.init_machine	= mmp2_dt_init,
 	.dt_compat	= mmp2_dt_board_compat,
 MACHINE_END
diff --git a/arch/arm/mach-mmp/mmp2.c b/arch/arm/mach-mmp/mmp2.c
index a0abfd7..d00c0fe 100644
--- a/arch/arm/mach-mmp/mmp2.c
+++ b/arch/arm/mach-mmp/mmp2.c
@@ -131,7 +131,7 @@ void __init mmp2_timer_init(void)
 	clk_rst = APBC_APBCLK | APBC_FNCLK | APBC_FNCLKSEL(1);
 	__raw_writel(clk_rst, APBC_TIMERS);
 
-	timer_init(TIMER1_VIRT_BASE, IRQ_MMP2_TIMER1);
+	timer_init(TIMER1_VIRT_BASE, IRQ_MMP2_TIMER1, 1);
 }
 
 /* on-chip devices */
diff --git a/arch/arm/mach-mmp/pxa168.c b/arch/arm/mach-mmp/pxa168.c
index a332d51..28fba2b 100644
--- a/arch/arm/mach-mmp/pxa168.c
+++ b/arch/arm/mach-mmp/pxa168.c
@@ -78,7 +78,7 @@ void __init pxa168_timer_init(void)
 	/* 3.25MHz, bus/functional clock enabled, release reset */
 	__raw_writel(TIMER_CLK_RST, APBC_TIMERS);
 
-	timer_init(TIMER1_VIRT_BASE, IRQ_PXA168_TIMER1);
+	timer_init(TIMER1_VIRT_BASE, IRQ_PXA168_TIMER1, 0);
 }
 
 void pxa168_clear_keypad_wakeup(void)
diff --git a/arch/arm/mach-mmp/pxa910.c b/arch/arm/mach-mmp/pxa910.c
index 1a84800..0e98bf3 100644
--- a/arch/arm/mach-mmp/pxa910.c
+++ b/arch/arm/mach-mmp/pxa910.c
@@ -112,7 +112,7 @@ void __init pxa910_timer_init(void)
 	__raw_writel(APBC_APBCLK | APBC_RST, APBC_TIMERS);
 	__raw_writel(TIMER_CLK_RST, APBC_TIMERS);
 
-	timer_init(TIMER1_VIRT_BASE, IRQ_PXA910_AP1_TIMER1);
+	timer_init(TIMER1_VIRT_BASE, IRQ_PXA910_AP1_TIMER1, 0);
 }
 
 /* on-chip devices */
diff --git a/drivers/clocksource/timer-mmp.c b/drivers/clocksource/timer-mmp.c
index 937d51e..7e1fc75 100644
--- a/drivers/clocksource/timer-mmp.c
+++ b/drivers/clocksource/timer-mmp.c
@@ -21,6 +21,7 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/interrupt.h>
+#include <linux/clk-provider.h>
 #include <linux/clockchips.h>
 
 #include <linux/io.h>
@@ -30,8 +31,6 @@
 #include <linux/of_irq.h>
 #include <linux/sched_clock.h>
 
-#include <mach/irqs.h>
-#include <mach/cputype.h>
 #include <asm/mach/time.h>
 
 #define TMR_CCR		(0x0000)
@@ -177,16 +176,19 @@ static struct clocksource cksrc = {
 	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
-static void __init timer_config(void)
+static void __init timer_init_clk(int mmp2_mode)
 {
 	uint32_t ccr = __raw_readl(mmp_timer_base + TMR_CCR);
 
 	__raw_writel(0x0, mmp_timer_base + TMR_CER); /* disable */
 
-	ccr &= (cpu_is_mmp2()) ? (TMR_CCR_CS_0(0) | TMR_CCR_CS_1(0)) :
+	ccr &= mmp2_mode ? (TMR_CCR_CS_0(0) | TMR_CCR_CS_1(0)) :
 		(TMR_CCR_CS_0(3) | TMR_CCR_CS_1(3));
 	__raw_writel(ccr, mmp_timer_base + TMR_CCR);
+}
 
+static void __init timer_config(void)
+{
 	/* set timer 0 to periodic mode, and timer 1 to free-running mode */
 	__raw_writel(0x2, mmp_timer_base + TMR_CMR);
 
@@ -209,11 +211,12 @@ static struct irqaction timer_irq = {
 	.dev_id		= &ckevt,
 };
 
-void __init timer_init(void __iomem *base, int irq)
+void __init timer_init(void __iomem *base, int irq, int mmp2_mode)
 {
 	BUG_ON(!base);
 	mmp_timer_base = base;
 
+	timer_init_clk(mmp2_mode);
 	timer_config();
 
 	setup_sched_clock(mmp_read_sched_clock, 32, CLOCK_TICK_RATE);
@@ -227,36 +230,47 @@ void __init timer_init(void __iomem *base, int irq)
 					MIN_DELTA, MAX_DELTA);
 }
 
-#ifdef CONFIG_OF
-static struct of_device_id mmp_timer_dt_ids[] = {
-	{ .compatible = "mrvl,mmp-timer", },
-	{}
-};
-
-void __init mmp_dt_init_timer(void)
+static void __init mmp_dt_init_timer(struct device_node *np)
 {
-	struct device_node *np;
-	int irq, ret;
-
-	np = of_find_matching_node(NULL, mmp_timer_dt_ids);
-	if (!np) {
-		ret = -ENODEV;
-		goto out;
+	struct clk *clk;
+	int irq;
+	u32 rate = 0;
+
+	if (!of_device_is_available(np))
+		return;
+	if (of_property_read_u32(np, "clock-frequency", &rate)) {
+		pr_err("failed to find clock-frequency property\n");
+		return;
 	}
-
 	irq = irq_of_parse_and_map(np, 0);
-	if (!irq) {
-		ret = -EINVAL;
-		goto out;
+	if (!irq)
+		return;
+	clk = of_clk_get(np, 0);
+	if (IS_ERR(clk)) {
+		pr_err("failed to get timer clock\n");
+		return;
 	}
 	mmp_timer_base = of_iomap(np, 0);
-	if (!mmp_timer_base) {
-		ret = -ENOMEM;
+	if (!mmp_timer_base)
 		goto out;
-	}
-	timer_init(mmp_timer_base, irq);
+
+	__raw_writel(0x0, mmp_timer_base + TMR_CER); /* disable */
+	if (rate)
+		clk_set_rate(clk, rate);
+	clk_prepare_enable(clk);
+	timer_config();
+
+	setup_sched_clock(mmp_read_sched_clock, 32, rate);
+
+	ckevt.cpumask = cpumask_of(0);
+
+	setup_irq(irq, &timer_irq);
+
+	clocksource_register_hz(&cksrc, rate);
+	clockevents_config_and_register(&ckevt, rate,
+					MIN_DELTA, MAX_DELTA);
 	return;
 out:
-	pr_err("Failed to get timer from device tree with error:%d\n", ret);
+	clk_put(clk);
 }
-#endif
+CLOCKSOURCE_OF_DECLARE(mmp_timer, "mrvl,mmp-timer", mmp_dt_init_timer);
-- 
1.8.1.2



From p.zabel at pengutronix.de  Fri Jul 26 06:26:24 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 26 Jul 2013 12:26:24 +0200
Subject: [PATCH v11] reset: Add driver for gpio-controlled reset pins
Message-ID: <1374834384-8071-1-git-send-email-p.zabel@pengutronix.de>

This driver implements a reset controller device that toggle a gpio
connected to a reset pin of a peripheral IC. The delay between assertion
and de-assertion of the reset signal can be configured via device tree.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
Reviewed-by: Stephen Warren <swarren at nvidia.com>
---
Changes since v10:
 - Backed out the arch_initcall change again, use module_platform_driver
---
 .../devicetree/bindings/reset/gpio-reset.txt       |  35 +++++
 drivers/reset/Kconfig                              |  11 ++
 drivers/reset/Makefile                             |   1 +
 drivers/reset/gpio-reset.c                         | 174 +++++++++++++++++++++
 4 files changed, 221 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/gpio-reset.txt
 create mode 100644 drivers/reset/gpio-reset.c

diff --git a/Documentation/devicetree/bindings/reset/gpio-reset.txt b/Documentation/devicetree/bindings/reset/gpio-reset.txt
new file mode 100644
index 0000000..bca5348
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/gpio-reset.txt
@@ -0,0 +1,35 @@
+GPIO reset controller
+=====================
+
+A GPIO reset controller controls a single GPIO that is connected to the reset
+pin of a peripheral IC. Please also refer to reset.txt in this directory for
+common reset controller binding usage.
+
+Required properties:
+- compatible: Should be "gpio-reset"
+- reset-gpios: A gpio used as reset line. The gpio specifier for this property
+               depends on the gpio controller that provides the gpio.
+- #reset-cells: 0, see below
+
+Optional properties:
+- reset-delay-us: delay in microseconds. The gpio reset line will be asserted for
+                  this duration to reset.
+- initially-in-reset: boolean. If not set, the initial state should be a
+                      deasserted reset line. If this property exists, the
+                      reset line should be kept in reset.
+
+example:
+
+sii902x_reset: gpio-reset {
+	compatible = "gpio-reset";
+	reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+	reset-delay-us = <10000>;
+	initially-in-reset;
+	#reset-cells = <0>;
+};
+
+/* Device with nRESET pin connected to GPIO5_0 */
+sii902x at 39 {
+	/* ... */
+	resets = <&sii902x_reset>; /* active-low GPIO5_0, 10 ms delay */
+};
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index c9d04f7..1a862df 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -11,3 +11,14 @@ menuconfig RESET_CONTROLLER
 	  via GPIOs or SoC-internal reset controller modules.
 
 	  If unsure, say no.
+
+if RESET_CONTROLLER
+
+config RESET_GPIO
+	tristate "GPIO reset controller support"
+	depends on GPIOLIB && OF
+	help
+	  This driver provides support for reset lines that are controlled
+	  directly by GPIOs.
+
+endif
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 1e2d83f..b854f20 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_RESET_CONTROLLER) += core.o
+obj-$(CONFIG_RESET_GPIO) += gpio-reset.o
diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
new file mode 100644
index 0000000..a49d8fc
--- /dev/null
+++ b/drivers/reset/gpio-reset.c
@@ -0,0 +1,174 @@
+/*
+ * GPIO Reset Controller driver
+ *
+ * Copyright 2013 Philipp Zabel, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+
+struct gpio_reset_data {
+	struct reset_controller_dev rcdev;
+	unsigned int gpio;
+	bool active_low;
+	s32 delay_us;
+};
+
+static void gpio_reset_set(struct reset_controller_dev *rcdev, int asserted)
+{
+	struct gpio_reset_data *drvdata = container_of(rcdev,
+			struct gpio_reset_data, rcdev);
+	int value = asserted;
+
+	if (drvdata->active_low)
+		value = !value;
+
+	gpio_set_value_cansleep(drvdata->gpio, value);
+}
+
+static int gpio_reset(struct reset_controller_dev *rcdev, unsigned long id)
+{
+	struct gpio_reset_data *drvdata = container_of(rcdev,
+			struct gpio_reset_data, rcdev);
+
+	if (drvdata->delay_us < 0)
+		return -ENOSYS;
+
+	gpio_reset_set(rcdev, 1);
+	udelay(drvdata->delay_us);
+	gpio_reset_set(rcdev, 0);
+
+	return 0;
+}
+
+static int gpio_reset_assert(struct reset_controller_dev *rcdev,
+		unsigned long id)
+{
+	gpio_reset_set(rcdev, 1);
+
+	return 0;
+}
+
+static int gpio_reset_deassert(struct reset_controller_dev *rcdev,
+		unsigned long id)
+{
+	gpio_reset_set(rcdev, 0);
+
+	return 0;
+}
+
+static struct reset_control_ops gpio_reset_ops = {
+	.reset = gpio_reset,
+	.assert = gpio_reset_assert,
+	.deassert = gpio_reset_deassert,
+};
+
+static int of_gpio_reset_xlate(struct reset_controller_dev *rcdev,
+			       const struct of_phandle_args *reset_spec)
+{
+	if (WARN_ON(reset_spec->args_count != 0))
+		return -EINVAL;
+
+	return 0;
+}
+
+static int gpio_reset_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct gpio_reset_data *drvdata;
+	enum of_gpio_flags flags;
+	unsigned long gpio_flags;
+	bool initially_in_reset;
+	int ret;
+
+	drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
+	if (drvdata == NULL)
+		return -ENOMEM;
+
+	if (of_gpio_named_count(np, "reset-gpios") != 1) {
+		dev_err(&pdev->dev,
+			"reset-gpios property missing, or not a single gpio\n");
+		return -EINVAL;
+	}
+
+	drvdata->gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
+	if (drvdata->gpio == -EPROBE_DEFER) {
+		return drvdata->gpio;
+	} else if (!gpio_is_valid(drvdata->gpio)) {
+		dev_err(&pdev->dev, "invalid reset gpio: %d\n", drvdata->gpio);
+		return drvdata->gpio;
+	}
+
+	drvdata->active_low = flags & OF_GPIO_ACTIVE_LOW;
+
+	ret = of_property_read_u32(np, "reset-delay-us", &drvdata->delay_us);
+	if (ret < 0)
+		drvdata->delay_us = -1;
+	else if (drvdata->delay_us < 0)
+		dev_warn(&pdev->dev, "reset delay too high\n");
+
+	initially_in_reset = of_property_read_bool(np, "initially-in-reset");
+	if (drvdata->active_low ^ initially_in_reset)
+		gpio_flags = GPIOF_OUT_INIT_HIGH;
+	else
+		gpio_flags = GPIOF_OUT_INIT_LOW;
+
+	ret = devm_gpio_request_one(&pdev->dev, drvdata->gpio, gpio_flags, NULL);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to request gpio %d: %d\n",
+			drvdata->gpio, ret);
+		return ret;
+	}
+
+	platform_set_drvdata(pdev, drvdata);
+
+	drvdata->rcdev.of_node = np;
+	drvdata->rcdev.owner = THIS_MODULE;
+	drvdata->rcdev.nr_resets = 1;
+	drvdata->rcdev.ops = &gpio_reset_ops;
+	drvdata->rcdev.of_xlate = of_gpio_reset_xlate;
+	reset_controller_register(&drvdata->rcdev);
+
+	return 0;
+}
+
+static int gpio_reset_remove(struct platform_device *pdev)
+{
+	struct gpio_reset_data *drvdata = platform_get_drvdata(pdev);
+
+	reset_controller_unregister(&drvdata->rcdev);
+
+	return 0;
+}
+
+static struct of_device_id gpio_reset_dt_ids[] = {
+	{ .compatible = "gpio-reset" },
+	{ }
+};
+
+static struct platform_driver gpio_reset_driver = {
+	.probe = gpio_reset_probe,
+	.remove = gpio_reset_remove,
+	.driver = {
+		.name = "gpio-reset",
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(gpio_reset_dt_ids),
+	},
+};
+
+module_platform_driver(gpio_reset_driver);
+
+MODULE_AUTHOR("Philipp Zabel <p.zabel at pengutronix.de>");
+MODULE_DESCRIPTION("gpio reset controller");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:gpio-reset");
+MODULE_DEVICE_TABLE(of, gpio_reset_dt_ids);
-- 
1.8.3.2



From p.zabel at pengutronix.de  Fri Jul 26 06:26:37 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 26 Jul 2013 12:26:37 +0200
Subject: [PATCH v8] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <CAOesGMgi0j_mPyeBLVHb_QW+DwtAPoFY697eQO3-yp9tnP1vmA@mail.gmail.com>
References: <1369904940-716-1-git-send-email-p.zabel@pengutronix.de>
 <20130716015038.GD28375@S2101-09.ap.freescale.net>
 <51E4BF98.8030604@wwwdotorg.org>
 <20130716041056.GA30067@S2101-09.ap.freescale.net>
 <51E56AA7.7020103@wwwdotorg.org>
 <20130717030246.GA4541@S2101-09.ap.freescale.net>
 <51E6CCE4.20705@wwwdotorg.org> <20130717213836.GA13324@amd.pavel.ucw.cz>
 <51E719A6.6070105@wwwdotorg.org> <20130718112555.GB1021@amd.pavel.ucw.cz>
 <CAOesGMgi0j_mPyeBLVHb_QW+DwtAPoFY697eQO3-yp9tnP1vmA@mail.gmail.com>
Message-ID: <1374834397.4013.15.camel@pizza.hi.pengutronix.de>

Am Donnerstag, den 18.07.2013, 11:45 -0700 schrieb Olof Johansson:
> Hi,
> 
> On Thu, Jul 18, 2013 at 4:25 AM, Pavel Machek <pavel at denx.de> wrote:
> 
> > It sound to me like keeping ammount of -EPROBE_DEFER to minimum is
> > still preferred.
> 
> Hand-crafting initcall level ordering of various drivers and subsystem
> is probably an even greater evil though. We've done it in the past,
> but now that we have deferred probe we have the option of not having
> to do it every time, such as this.
> 
> You're spending an awful lot of energy arguing over this, but nobody
> has actually shown data of how much deferral is happening -- and that
> it's a real problem. Until someone does so there's no reason to change
> it from the default module init level at all, I'd say.

Alright, I've backed out the arch_initcall change and resent the patch.
If you are fine with that, I'll send you a pull request for this and the
"reset: allow drivers to request probe deferral" patch.

regards
Philipp



From ben.dooks at codethink.co.uk  Fri Jul 26 06:31:42 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Fri, 26 Jul 2013 11:31:42 +0100
Subject: [PATCH] ARM: kdgb: use .inst for data to be assembled as
 intruction
In-Reply-To: <20130725180912.GG2546@localhost.localdomain>
References: <1374763778-5305-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374763778-5305-2-git-send-email-ben.dooks@codethink.co.uk>
 <20130725171130.GE2546@localhost.localdomain>
 <51F15CAE.7020008@codethink.co.uk>
 <20130725180912.GG2546@localhost.localdomain>
Message-ID: <51F2500E.5040107@codethink.co.uk>

On 25/07/13 19:09, Dave Martin wrote:
> On Thu, Jul 25, 2013 at 06:13:18PM +0100, Ben Dooks wrote:
>> On 25/07/13 18:11, Dave Martin wrote:
>>> On Thu, Jul 25, 2013 at 03:49:38PM +0100, Ben Dooks wrote:
>>>> The arch_kgdb_breakpoint() function uses an inline assembly directive
>>>> to assemble a specific instruction using .word. This means the linker
>>>> will not treat is as an instruction, and therefore incorrectly swap
>>>> the endian-ness if running BE8.
>>>>
>>>> Note, not tested, please comment if this is wrong.
>>>>
>>>> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
>>>> ---
>>>>   arch/arm/include/asm/kgdb.h |    2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm/include/asm/kgdb.h b/arch/arm/include/asm/kgdb.h
>>>> index 48066ce..76227c8 100644
>>>> --- a/arch/arm/include/asm/kgdb.h
>>>> +++ b/arch/arm/include/asm/kgdb.h
>>>> @@ -41,7 +41,7 @@
>>>>
>>>>   static inline void arch_kgdb_breakpoint(void)
>>>>   {
>>>> -	asm(".word 0xe7ffdeff");
>>>> +	asm(".inst 0xe7ffdeff");
>>>
>>> Yikes, this isn't going to work in a Thumb kernel.
>>>
>>> We should make HAVE_ARCH_KGDB depend on !THUMB2_KERNEL until/unless that
>>> gets fixed...  It looks like the incompatibilities may be more extensive
>>> than just this one instruction.
>>>
>>>
>>> For the ARM case, similarly to the other patches, please use the __inst
>>> macros from<asm/opcodes.h>   instead of emitting the opcode explicitly.
>>
>> See previous objections to that, plus they're marked for internal use
>> only!
>
> Ditto my counterarguments.  I'm not emotionally attached to __inst*(), but
> we should use one or the other: either .inst or __inst(), not a mixture.
> However, the __inst macros work for inline asm and .S, and do more than
> just emitting a single opcode; see opcodes-virt.h for example, so while
> removing them isn't rocket science, it would involve churn in a few places.
>
>
> Note, the "Don't use these directly" comment only applies to the triple-
> underscored helpers.
>
> The broader "using these macros directly is poor practice" comment was
> an attempt to engourage people to write the likes of
>
> #define __KGDB_BKPT_INSTR __inst_arm(0xxe7ffdeff)
>
> static inline void arch_kgdb_breakpoint(void)
> {
> 	asm(__KGDB_BKPT_INSTR);
> }
>
> ...on the basis that this ought to be more readable.
>
> But this is a bit moot in a situation like this where the opcode is
> only used in one place, by itself, in a wrapper whose name makes the
> intent clear anyway.

Ok, I will look into changing the patches in the next day or so
and do the same fixes for kprobes.



-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From nv-dung at jinso.co.jp  Fri Jul 26 06:33:38 2013
From: nv-dung at jinso.co.jp (Nguyen Viet Dung)
Date: Fri, 26 Jul 2013 19:33:38 +0900
Subject: [PATCH v2 0/1 resend] ARM: shmobile: r8a7790: add I2C support
Message-ID: <1374834819-319-1-git-send-email-nv-dung@jinso.co.jp>

Hi Wolfram
CC Morimoto

Please consider the following patch for the r8a7790 Soc.
This patch modify I2C driver of rcar-H1 to usable on both rcar-H1 and rcar-H2.
It was developed base on the renesas-next-20130528 branch and 
have tested on the Lager board.
Input clock of I2C is peripheral module clock that is named peripheral_clk.

V2: dropped patches 2,3,4 from the previous version.

Thanks,
Nguyen viet Dung

Nguyen Viet Dung (1):
  i2c: rcar: modify I2C driver

 drivers/i2c/busses/i2c-rcar.c |   17 +++++++++++++++--
 include/linux/i2c/i2c-rcar.h  |    4 ++++
 2 files changed, 19 insertions(+), 2 deletions(-)

-- 
1.7.9.5



From nv-dung at jinso.co.jp  Fri Jul 26 06:33:39 2013
From: nv-dung at jinso.co.jp (Nguyen Viet Dung)
Date: Fri, 26 Jul 2013 19:33:39 +0900
Subject: [PATCH v2 1/1 resend] i2c: rcar: modify I2C driver
In-Reply-To: <1374834819-319-1-git-send-email-nv-dung@jinso.co.jp>
References: <1374834819-319-1-git-send-email-nv-dung@jinso.co.jp>
Message-ID: <1374834819-319-2-git-send-email-nv-dung@jinso.co.jp>

This patch modify calculate for clock in I2C driver.

Signed-off-by: Nguyen Viet Dung <nv-dung at jinso.co.jp>
---
 drivers/i2c/busses/i2c-rcar.c |   17 +++++++++++++++--
 include/linux/i2c/i2c-rcar.h  |    4 ++++
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 4ba4a95..85987c1 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -221,15 +221,28 @@ static int rcar_i2c_clock_calculate(struct rcar_i2c_priv *priv,
 				    struct device *dev)
 {
 	struct clk *clkp = clk_get(NULL, "peripheral_clk");
+	struct i2c_rcar_platform_data *pdata = dev->platform_data;
 	u32 scgd, cdf;
 	u32 round, ick;
 	u32 scl;
+	u32 cdf_width;
+	u32 flags = pdata ? pdata->flags : 0;
 
 	if (!clkp) {
 		dev_err(dev, "there is no peripheral_clk\n");
 		return -EIO;
 	}
 
+	switch (flags & I2C_RCAR_FLAGS_ICCCR_MASK) {
+	default:
+	case I2C_RCAR_FLAGS_ICCCR_IS_2BIT:
+		cdf_width = 2;
+		break;
+	case I2C_RCAR_FLAGS_ICCCR_IS_3BIT:
+		cdf_width = 3;
+		break;
+	}
+
 	/*
 	 * calculate SCL clock
 	 * see
@@ -245,7 +258,7 @@ static int rcar_i2c_clock_calculate(struct rcar_i2c_priv *priv,
 	 * clkp : peripheral_clk
 	 * F[]  : integer up-valuation
 	 */
-	for (cdf = 0; cdf < 4; cdf++) {
+	for (cdf = 0; cdf < (1 << cdf_width); cdf++) {
 		ick = clk_get_rate(clkp) / (1 + cdf);
 		if (ick < 20000000)
 			goto ick_find;
@@ -287,7 +300,7 @@ scgd_find:
 	/*
 	 * keep icccr value
 	 */
-	priv->icccr = (scgd << 2 | cdf);
+	priv->icccr = (scgd << (cdf_width) | cdf);
 
 	return 0;
 }
diff --git a/include/linux/i2c/i2c-rcar.h b/include/linux/i2c/i2c-rcar.h
index 496f5c2..572a6e5 100644
--- a/include/linux/i2c/i2c-rcar.h
+++ b/include/linux/i2c/i2c-rcar.h
@@ -5,6 +5,10 @@
 
 struct i2c_rcar_platform_data {
 	u32 bus_speed;
+	u32 flags;
+#define I2C_RCAR_FLAGS_ICCCR_MASK	(0xF << 0)
+#define I2C_RCAR_FLAGS_ICCCR_IS_2BIT	(0 << 0) /* default */
+#define I2C_RCAR_FLAGS_ICCCR_IS_3BIT	(1 << 0)
 };
 
 #endif /* __I2C_R_CAR_H__ */
-- 
1.7.9.5



From will.deacon at arm.com  Fri Jul 26 06:34:05 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 26 Jul 2013 11:34:05 +0100
Subject: [PATCH 4/6] ARM: locks: prefetch the destination word for write
 prior to strex
In-Reply-To: <alpine.LFD.2.03.1307251622320.15022@syhkavp.arg>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-5-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231609170.15022@syhkavp.arg>
 <20130724111841.GD11072@mudshark.cambridge.arm.com>
 <51F160EA.6030800@codeaurora.org> <51F1626C.3050008@codeaurora.org>
 <20130725174555.GK12827@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1307251622320.15022@syhkavp.arg>
Message-ID: <20130726103404.GB17886@mudshark.cambridge.arm.com>

Hi Nicolas,

On Thu, Jul 25, 2013 at 09:24:48PM +0100, Nicolas Pitre wrote:
> On Thu, 25 Jul 2013, Will Deacon wrote:
> > > 
> > > Oh joy. Why is rwlock's lock member marked volatile?
> > 
> > Yeah, that was the problematic guy. However, I had to fix that anyway in
> > this patch because otherwise the definition for prefetchw when
> > !ARCH_HAS_PREFETCHW (which expands to __builtin_prefetch(x,1)) will explode.
> 
> Why not always keep ARCH_HAS_PREFETCHW defined then, and have 
> __builtin_prefetch([const volatile void *)x,1)) when we can't do better?
> 
> Or why not adding this cast to the generic definition?

Yes, I'd prefer to fix the generic definition as a separate patch. However,
I think the only case that this generates warnings is when a volatile * is
passed. If volatile is actually required, I question whether prefetching
from that location even makes sense in the first place since, in the kernel,
the keyword seems to be generally associated with IO rather than CPUs accessing
shared memory via caches.

What do you think?

Will


From thomas.petazzoni at free-electrons.com  Fri Jul 26 06:35:00 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 26 Jul 2013 12:35:00 +0200
Subject: [PATCH 03/10] ARM: sunxi: Add the Allwinner A31 compatible to
 the machine definition
In-Reply-To: <1374618312-19001-4-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374618312-19001-4-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20130726123500.58136be1@skate>

Dear Maxime Ripard,

On Wed, 24 Jul 2013 00:25:05 +0200, Maxime Ripard wrote:
> The Allwinner A31 is a quad-Cortex-A7 based SoC, which shares a lot of
> differences with the previous SoCs from Allwinner, like the PIO, I2C,

"shares a lot of differences" ? I suppose you meant "has a lot of
similarities", or "shares a number of hardware blocks", or something
like that?

> UARTs, timers, watchdog IPs, but also differs but droping the WEMAC

"but also differs but droping" ?

> ethernet controller and most notably droping the in-house IRQ
> controller in favor of a ARM GIC one.

droping -> dropping

</nitpick> :)

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From thomas.petazzoni at free-electrons.com  Fri Jul 26 06:35:59 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 26 Jul 2013 12:35:59 +0200
Subject: [PATCH 04/10] ARM: sun6i: Add restart code for the A31
In-Reply-To: <1374618312-19001-5-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374618312-19001-5-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20130726123559.66216580@skate>

Dear Maxime Ripard,

On Wed, 24 Jul 2013 00:25:06 +0200, Maxime Ripard wrote:
> The Allwinner A31 has a sligthly different watchdog that requires a
> different restart code.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  arch/arm/mach-sunxi/sunxi.c | 37 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
> 
> diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> index 11326d9..c18ef3a 100644
> --- a/arch/arm/mach-sunxi/sunxi.c
> +++ b/arch/arm/mach-sunxi/sunxi.c
> @@ -32,6 +32,15 @@
>  #define SUN4I_WATCHDOG_MODE_ENABLE		(1 << 0)
>  #define SUN4I_WATCHDOG_MODE_RESET_ENABLE	(1 << 1)
>  
> +#define SUN6I_WATCHDOG1_IRQ_REG		0x00
> +#define SUN6I_WATCHDOG1_CTRL_REG	0x10
> +#define SUN6I_WATCHDOG1_CTRL_RESTART		(1 << 0)
> +#define SUN6I_WATCHDOG1_CONFIG_REG	0x14
> +#define SUN6I_WATCHDOG1_CONFIG_RESTART		(1 << 0)
> +#define SUN6I_WATCHDOG1_CONFIG_IRQ		(1 << 1)
> +#define SUN6I_WATCHDOG1_MODE_REG	0x18
> +#define SUN6I_WATCHDOG1_MODE_ENABLE		(1 << 0)

Alignment is not nice, and the BIT() macro should be used.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From thomas.petazzoni at free-electrons.com  Fri Jul 26 06:37:47 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 26 Jul 2013 12:37:47 +0200
Subject: [PATCH 05/10] ARM: sunxi: Add Allwinner A31 DTSI
In-Reply-To: <1374618312-19001-6-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374618312-19001-6-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20130726123747.7c88d976@skate>

Dear Maxime Ripard,

On Wed, 24 Jul 2013 00:25:07 +0200, Maxime Ripard wrote:

> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 641b3c9..1482533 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -210,7 +210,8 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
>  	sun4i-a10-mini-xplus.dtb \
>  	sun4i-a10-hackberry.dtb \
>  	sun5i-a10s-olinuxino-micro.dtb \
> -	sun5i-a13-olinuxino.dtb
> +	sun5i-a13-olinuxino.dtb \
> +	sun6i-a31-colombus.dtb

Wrong patch for this chunk. The colombus .dts is added in PATCH 06/10.

> +	soc at 01c20000 {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		reg = <0x01c20000 0x300000>;
> +		ranges;

Just curious, what are these reg and ranges properties for?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From thomas.petazzoni at free-electrons.com  Fri Jul 26 06:39:12 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 26 Jul 2013 12:39:12 +0200
Subject: [PATCH 08/10] ARM: sunxi: dt: Add PIO controller to A31 DTSI
In-Reply-To: <1374618312-19001-9-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374618312-19001-9-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20130726123912.3dd65bb7@skate>

Dear Maxime Ripard,

On Wed, 24 Jul 2013 00:25:10 +0200, Maxime Ripard wrote:
> The A31 has a different set of pins than the one found on the A10 and
> A13, so we will need a different compatible string, even though the IP
> is the same.

Why "we will" ? Isn't this patch presently using a different compatible
string?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From lorenzo.pieralisi at arm.com  Fri Jul 26 06:45:52 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 26 Jul 2013 11:45:52 +0100
Subject: [PATCH 03/13] ARM: b.L: core switcher code
In-Reply-To: <1374550289-25305-4-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-4-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130726104551.GA28084@e102568-lin.cambridge.arm.com>

On Tue, Jul 23, 2013 at 04:31:19AM +0100, Nicolas Pitre wrote:
> This is the core code implementing big.LITTLE switcher functionality.
> Rational for this code is available here:
> 
> http://lwn.net/Articles/481055/
> 
> The main entry point for a switch request is:
> 
> void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
> 
> If the calling CPU is not the wanted one, this wrapper takes care of
> sending the request to the appropriate CPU with schedule_work_on().
> 
> At the moment the core switch operation is handled by bL_switch_to()
> which must be called on the CPU for which a switch is requested.
> 
> What this code does:
> 
>   * Return early if the current cluster is the wanted one.
> 
>   * Close the gate in the kernel entry vector for both the inbound
>     and outbound CPUs.
> 
>   * Wake up the inbound CPU so it can perform its reset sequence in
>     parallel up to the kernel entry vector gate.
> 
>   * Migrate all interrupts in the GIC targeting the outbound CPU
>     interface to the inbound CPU interface, including SGIs. This is
>     performed by gic_migrate_target() in drivers/irqchip/irq-gic.c.
> 
>   * Call cpu_pm_enter() which takes care of flushing the VFP state to
>     RAM and save the CPU interface config from the GIC to RAM.

If I read the code properly, you always resume on the same logical cpu id
you suspended on (different HW CPU of course), correct ? This is to validate
my assumptions on CPU PM notifiers and other code.

> 
>   * Modify the cpu_logical_map to refer to the inbound physical CPU.
> 
>   * Call cpu_suspend() which saves the CPU state (general purpose
>     registers, page table address) onto the stack and store the
>     resulting stack pointer in an array indexed by the updated
>     cpu_logical_map, then call the provided shutdown function.
>     This happens in arch/arm/kernel/sleep.S.
> 
> At this point, the provided shutdown function executed by the outbound
> CPU ungates the inbound CPU. Therefore the inbound CPU:
> 
>   * Picks up the saved stack pointer in the array indexed by its MPIDR
>     in arch/arm/kernel/sleep.S.
> 
>   * The MMU and caches are re-enabled using the saved state on the
>     provided stack, just like if this was a resume operation from a
>     suspended state.
> 
>   * Then cpu_suspend() returns, although this is on the inbound CPU
>     rather than the outbound CPU which called it initially.
> 
>   * The function cpu_pm_exit() is called which effect is to restore the
>     CPU interface state in the GIC using the state previously saved by
>     the outbound CPU.
> 
>   * Exit of bL_switch_to() to resume normal kernel execution on the
>     new CPU.
> 
> However, the outbound CPU is potentially still running in parallel while
> the inbound CPU is resuming normal kernel execution, hence we need
> per CPU stack isolation to execute bL_do_switch().  After the outbound
> CPU has ungated the inbound CPU, it calls mcpm_cpu_power_down() to:
> 
>   * Clean its L1 cache.
> 
>   * If it is the last CPU still alive in its cluster (last man standing),
>     it also cleans its L2 cache and disables cache snooping from the other
>     cluster.
> 
>   * Power down the CPU (or whole cluster).
> 
> Code called from bL_do_switch() might end up referencing 'current' for
> some reasons.  However, 'current' is derived from the stack pointer.
> With any arbitrary stack, the returned value for 'current' and any
> dereferenced values through it are just random garbage which may lead to
> segmentation faults.
> 
> The active page table during the execution of bL_do_switch() is also a
> problem.  There is no guarantee that the inbound CPU won't destroy the
> corresponding task which would free the attached page table while the
> outbound CPU is still running and relying on it.

Yes this is really a sticking point, some comments below.

> To solve both issues, we borrow some of the task space belonging to
> the init/idle task which, by its nature, is lightly used and therefore
> is unlikely to clash with our usage.  The init task is also never going
> away.

Unlikely does not mean it will always work and I think it is best
avoided. Better stick to kernel threads, or a temporary stack but I
understand for a temporary stack to work you have to force constraints
on the mcpm backend you do not necessarily want to. More below.

> Right now the logical CPU number is assumed to be equivalent to the
> physical CPU number within each cluster. The kernel should also be
> booted with only one cluster active.  These limitations will be lifted
> eventually.
> 
> Signed-off-by: Nicolas Pitre <nico at linaro.org>
> ---
>  arch/arm/Kconfig                   |  17 +++
>  arch/arm/common/Makefile           |   1 +
>  arch/arm/common/bL_switcher.c      | 247 +++++++++++++++++++++++++++++++++++++
>  arch/arm/include/asm/bL_switcher.h |  17 +++
>  4 files changed, 282 insertions(+)
>  create mode 100644 arch/arm/common/bL_switcher.c
>  create mode 100644 arch/arm/include/asm/bL_switcher.h
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index ba412e02ec..2c9e5bf734 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1538,6 +1538,23 @@ config MCPM
>           for (multi-)cluster based systems, such as big.LITTLE based
>           systems.
> 
> +config BIG_LITTLE
> +       bool "big.LITTLE support (Experimental)"
> +       depends on CPU_V7 && SMP
> +       select MCPM
> +       help
> +         This option enables support for the big.LITTLE architecture.

Probably this belongs in a separate patch (CPU idle driver probably needs
it too). Not a big deal though (and honestly I do not know how you can
justify a single patch for that - we need to add this config option, somehow).

> +config BL_SWITCHER
> +       bool "big.LITTLE switcher support"
> +       depends on BIG_LITTLE && MCPM && HOTPLUG_CPU
> +       select CPU_PM
> +       select ARM_CPU_SUSPEND
> +       help
> +         The big.LITTLE "switcher" provides the core functionality to
> +         transparently handle transition between a cluster of A15's
> +         and a cluster of A7's in a big.LITTLE system.
> +
>  choice
>         prompt "Memory split"
>         default VMSPLIT_3G
> diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
> index 8c60f473e9..2586240d5a 100644
> --- a/arch/arm/common/Makefile
> +++ b/arch/arm/common/Makefile
> @@ -17,3 +17,4 @@ obj-$(CONFIG_MCPM)            += mcpm_head.o mcpm_entry.o mcpm_platsmp.o vlock.o
>  AFLAGS_mcpm_head.o             := -march=armv7-a
>  AFLAGS_vlock.o                 := -march=armv7-a
>  obj-$(CONFIG_TI_PRIV_EDMA)     += edma.o
> +obj-$(CONFIG_BL_SWITCHER)      += bL_switcher.o
> diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> new file mode 100644
> index 0000000000..e63881b430
> --- /dev/null
> +++ b/arch/arm/common/bL_switcher.c
> @@ -0,0 +1,247 @@
> +/*
> + * arch/arm/common/bL_switcher.c -- big.LITTLE cluster switcher core driver
> + *
> + * Created by: Nicolas Pitre, March 2012
> + * Copyright:  (C) 2012-2013  Linaro Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/sched.h>
> +#include <linux/interrupt.h>
> +#include <linux/cpu_pm.h>
> +#include <linux/workqueue.h>
> +#include <linux/mm.h>
> +#include <linux/string.h>
> +#include <linux/irqchip/arm-gic.h>
> +
> +#include <asm/smp_plat.h>
> +#include <asm/cacheflush.h>
> +#include <asm/suspend.h>
> +#include <asm/mcpm.h>
> +#include <asm/bL_switcher.h>
> +
> +
> +/*
> + * Use our own MPIDR accessors as the generic ones in asm/cputype.h have
> + * __attribute_const__ and we don't want the compiler to assume any
> + * constness here as the value _does_ change along some code paths.
> + */
> +
> +static int read_mpidr(void)
> +{
> +       unsigned int id;
> +       asm volatile ("mrc\tp15, 0, %0, c0, c0, 5" : "=r" (id));
> +       return id & MPIDR_HWID_BITMASK;
> +}
> +
> +/*
> + * bL switcher core code.
> + */
> +
> +static void bL_do_switch(void *_unused)
> +{
> +       unsigned mpidr, cpuid, clusterid, ob_cluster, ib_cluster;
> +
> +       /*
> +        * We now have a piece of stack borrowed from the init task's.
> +        * Let's also switch to init_mm right away to match it.
> +        */
> +       cpu_switch_mm(init_mm.pgd, &init_mm);

Is this cpu_switch_mm necessary ? You are executing it to make sure you
get to wfi with page tables that can't be deallocated by the running inbound
if I got it right. It is not needed to use the init stack, but you know
that.

> +
> +       pr_debug("%s\n", __func__);
> +
> +       mpidr = read_mpidr();
> +       cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +       clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> +       ob_cluster = clusterid;
> +       ib_cluster = clusterid ^ 1;
> +
> +       /*
> +        * Our state has been saved at this point.  Let's release our
> +        * inbound CPU.
> +        */
> +       mcpm_set_entry_vector(cpuid, ib_cluster, cpu_resume);
> +       sev();
> +
> +       /*
> +        * From this point, we must assume that our counterpart CPU might
> +        * have taken over in its parallel world already, as if execution
> +        * just returned from cpu_suspend().  It is therefore important to
> +        * be very careful not to make any change the other guy is not
> +        * expecting.  This is why we need stack isolation.
> +        *
> +        * Fancy under cover tasks could be performed here.  For now
> +        * we have none.
> +        */
> +
> +       /* Let's put ourself down. */
> +       mcpm_cpu_power_down();
> +
> +       /* should never get here */
> +       BUG();
> +}
> +
> +/*
> + * Stack isolation.  To ensure 'current' remains valid, we just borrow
> + * a slice of the init/idle task which should be fairly lightly used.
> + * The borrowed area starts just above the thread_info structure located
> + * at the very bottom of the stack, aligned to a cache line.
> + */
> +#define STACK_SIZE 256
> +extern void call_with_stack(void (*fn)(void *), void *arg, void *sp);
> +static int bL_switchpoint(unsigned long _arg)
> +{
> +       unsigned int mpidr = read_mpidr();
> +       unsigned int cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +       unsigned int clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> +       unsigned int cpu_index = cpuid + clusterid * MAX_CPUS_PER_CLUSTER;
> +       void *stack = &init_thread_info + 1;
> +       stack = PTR_ALIGN(stack, L1_CACHE_BYTES);
> +       stack += cpu_index * STACK_SIZE + STACK_SIZE;

I do not like this much , for two reasons. Firstly because it might not work,
secondly because whatever current usage we do from that point onwards
is attached to the init thread, I am not sure that's 100% safe either.

Moving to kernel threads suffers from the same issue, even though I
should grant there it is easier to monitor stack usage and grab safely
some starting at the bottom. At least the current pointer behaviour is kept
coherent. Overall the risk of using current on both outbound and inbound
CPUs at once with no coordination is a bit scary, probably it is best to
prevent current pointer usage altogether (but this forces constraints on
MCPM). I will give it more thought.

> +       call_with_stack(bL_do_switch, (void *)_arg, stack);
> +       BUG();
> +}
> +
> +/*
> + * Generic switcher interface
> + */
> +
> +/*
> + * bL_switch_to - Switch to a specific cluster for the current CPU
> + * @new_cluster_id: the ID of the cluster to switch to.
> + *
> + * This function must be called on the CPU to be switched.
> + * Returns 0 on success, else a negative status code.
> + */
> +static int bL_switch_to(unsigned int new_cluster_id)
> +{
> +       unsigned int mpidr, cpuid, clusterid, ob_cluster, ib_cluster, this_cpu;
> +       int ret;
> +
> +       mpidr = read_mpidr();
> +       cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> +       clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> +       ob_cluster = clusterid;
> +       ib_cluster = clusterid ^ 1;
> +
> +       if (new_cluster_id == clusterid)
> +               return 0;
> +
> +       pr_debug("before switch: CPU %d in cluster %d\n", cpuid, clusterid);
> +
> +       /* Close the gate for our entry vectors */
> +       mcpm_set_entry_vector(cpuid, ob_cluster, NULL);
> +       mcpm_set_entry_vector(cpuid, ib_cluster, NULL);
> +
> +       /*
> +        * Let's wake up the inbound CPU now in case it requires some delay
> +        * to come online, but leave it gated in our entry vector code.
> +        */
> +       ret = mcpm_cpu_power_up(cpuid, ib_cluster);
> +       if (ret) {
> +               pr_err("%s: mcpm_cpu_power_up() returned %d\n", __func__, ret);
> +               return ret;
> +       }
> +
> +       /*
> +        * From this point we are entering the switch critical zone
> +        * and can't sleep/schedule anymore.
> +        */
> +       local_irq_disable();
> +       local_fiq_disable();
> +
> +       this_cpu = smp_processor_id();
> +
> +       /* redirect GIC's SGIs to our counterpart */
> +       gic_migrate_target(cpuid + ib_cluster*4);
> +
> +       /*
> +        * Raise a SGI on the inbound CPU to make sure it doesn't stall
> +        * in a possible WFI, such as in mcpm_power_down().
> +        */
> +       arch_send_wakeup_ipi_mask(cpumask_of(this_cpu));
> +
> +       ret = cpu_pm_enter();
> +
> +       /* we can not tolerate errors at this point */
> +       if (ret)
> +               panic("%s: cpu_pm_enter() returned %d\n", __func__, ret);
> +
> +       /*
> +        * Flip the cluster in the CPU logical map for this CPU.
> +        * This must be flushed to RAM as the resume code
> +        * needs to access it while the caches are still disabled.
> +        */
> +       cpu_logical_map(this_cpu) ^= (1 << 8);
> +       sync_cache_w(&cpu_logical_map(this_cpu));

sync_w is not needed anymore, cpu_resume does not use cpu_logical_map.

Thanks,
Lorenzo



From pullip.cho at samsung.com  Fri Jul 26 06:46:01 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 26 Jul 2013 19:46:01 +0900
Subject: [PATCH 2/2] iommu/exynos: Follow kernel coding style for
 __sysmmu_enable return type
In-Reply-To: <1374766502-14823-2-git-send-email-a.motakis@virtualopensystems.com>
References: <1374766502-14823-1-git-send-email-a.motakis@virtualopensystems.com>
 <1374766502-14823-2-git-send-email-a.motakis@virtualopensystems.com>
Message-ID: <003101ce89ed$52317330$f6945990$@samsung.com>

> -----Original Message-----
> From: Antonios Motakis [mailto:a.motakis at virtualopensystems.com]
> Sent: Friday, July 26, 2013 12:35 AM
> 
> On success, the __sysmmu_enable returns 1 instead of 0, which does not
> respect the convention described in Chapter 16 of the Linux kernel coding
> style.
> 
> In fact, this return value is propagated all the way up to
> iommu_attach_device() and iommu_attach_device() in drivers/iommu.c,
> which results into inconsistent behavior of the IOMMU API with Exynos
> systems, compared to other IOMMUs.
> 
> This patch replaces the return value with 0, which makes the Exynos'
> IOMMU driver behavior consistent with that of other IOMMUs.
> 
> Signed-off-by: Antonios Motakis <a.motakis at virtualopensystems.com>
> ---
>  drivers/iommu/exynos-iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index c7dd4b5..4ea3abb 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -504,7 +504,7 @@ static int __sysmmu_enable(struct sysmmu_drvdata *data,
> 
>  		dev_dbg(data->sysmmu, "Enabled\n");
>  	} else {
> -		ret = (pgtable == data->pgtable) ? 1 : -EBUSY;
> +		ret = (pgtable == data->pgtable) ? 0 : -EBUSY;
> 
Ok.

__sysmmu_enable() must return 1 if it is called with the same page table.
I have fixed it exynos_iommu_attach_device() to always return zero on success
in the next patchset which I will post today.

Thank you.

>  		dev_dbg(data->sysmmu, "already enabled\n");
>  	}
> --
> 1.8.1.2



From Dave.Martin at arm.com  Fri Jul 26 06:48:40 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Fri, 26 Jul 2013 11:48:40 +0100
Subject: [PATCH 1/2] ARM: Correct BUG() assembly to ensure it is
 endian-agnostic
In-Reply-To: <20130725175456.GF2546@localhost.localdomain>
References: <1374763357-4893-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374763357-4893-2-git-send-email-ben.dooks@codethink.co.uk>
 <20130725155700.GD2546@localhost.localdomain>
 <51F14CAF.5010602@codethink.co.uk>
 <20130725175456.GF2546@localhost.localdomain>
Message-ID: <20130726104835.GA2282@localhost.localdomain>

On Thu, Jul 25, 2013 at 06:54:56PM +0100, Dave Martin wrote:
> On Thu, Jul 25, 2013 at 05:05:03PM +0100, Ben Dooks wrote:
> > On 25/07/13 16:57, Dave Martin wrote:
> > >On Thu, Jul 25, 2013 at 03:42:36PM +0100, Ben Dooks wrote:
> > >>Currently BUG() uses .word or .hword to create the necessary illegal
> > >>instructions. However if we are building BE8 then these get swapped
> > >>by the linker into different illegal instructions in the text.
> > >
> > >In the case of Thumb, the resulting instruction is actually not illegal,
> > >which is even worse...
> > >
> > >>Change to using .inst and .inst.w to create the instructions and mark
> > >>them as instructions so that the linker acts correctly.
> > >>
> > >>Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
> > >>---
> > >>  arch/arm/include/asm/bug.h |    4 ++--
> > >>  1 file changed, 2 insertions(+), 2 deletions(-)
> > >>
> > >>diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
> > >>index 7af5c6c..b95da52 100644
> > >>--- a/arch/arm/include/asm/bug.h
> > >>+++ b/arch/arm/include/asm/bug.h
> > >>@@ -12,10 +12,10 @@
> > >>   */
> > >>  #ifdef CONFIG_THUMB2_KERNEL
> > >>  #define BUG_INSTR_VALUE 0xde02
> > >>-#define BUG_INSTR_TYPE ".hword "
> > >>+#define BUG_INSTR_TYPE ".inst.w "
> > >>  #else
> > >>  #define BUG_INSTR_VALUE 0xe7f001f2
> > >>-#define BUG_INSTR_TYPE ".word "
> > >>+#define BUG_INSTR_TYPE ".inst "
> > >>  #endif
> > >
> > >There was some uncertainty a while ago about precisely which versions of
> > >gas support .inst.
> > >
> > ><asm/opcodes.h>  implements an abstracted workaround for this issue,
> > >whereby you can emit instructions using the __inst*() macros, and
> > >the swabbing and assembler directives should be generated for you.
> > >
> > >The patch below ought to do this for BUG(), but I've only briefly
> > >build-tested it.
> > >
> > >
> > >Note that the disassembly of the injected instructions in .o files
> > >can be a bit confusing, because they are marked as data, do ld --be8
> > >doesn't swab them (unlike the instructions, which do get swabbed).
> > >objdump may also do extra swabbing during disassembly.
> > >
> > >You can sanity-check what is really in the image by dumping the text
> > >section of vmlinux with objdump -s.
> > >
> > >
> > >The change to<asm/opcodes.h>  is due to a missing include which is
> > >really required for correctness, but which didn't show up without
> > >the<asm/bug.h>  change (this causes opcodes.h to get included way
> > >more often than is otherwise the case).
> > >
> > >Cheers
> > >---Dave
> > 
> > Given it was added ~2006 according the mailing lists I have seen, then
> > it should be ok to use for building modern kernels with. I think the
> > use of .inst and .inst.w is a better solution than having the code
> > having bits of it marked as data.
> 
> Of course it is.  But this discussion can be decoupled from bug.h:
> if we decide to migrate to .inst, we can do that in one place in
> opcodes.h, no?
> 
> Otherwise, we have multiple fixes to apply when we decide to make
> that change.

A quick follow-up on that: I found I have a random old binutils
knocking around which is post-2006 and lacks .inst:


$ arm-elf-eabi-as --version
GNU assembler (GNU Binutils) 2.19.1
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-elf-eabi'.

$ echo .inst 0 | arm-elf-eabi-as
{standard input}: Assembler messages:
{standard input}:1: Error: unknown pseudo-op: `.inst'


Maybe .inst never made it onto that release branch.

This goes a small way to explaining why my disk is so full, anyway.


I won't comment on whether it's wise to carry on using tools that old,
but I note that it can build current mainline, except for some newer,
v7-specific configurations.  bug.h is hardly v7-specific.

Because a workaround for the lack of .inst already exists, I think
it would be execessive to cut off backward tool compaitiblity for
all configurations just for this minor, solved issue.

Cheers
---Dave


From will.deacon at arm.com  Fri Jul 26 06:49:08 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 26 Jul 2013 11:49:08 +0100
Subject: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
In-Reply-To: <1374817287-27952-1-git-send-email-vijay.kilari@gmail.com>
References: <1374817287-27952-1-git-send-email-vijay.kilari@gmail.com>
Message-ID: <20130726104908.GC17886@mudshark.cambridge.arm.com>

[Adding Stephen Warren since he has been working in this area]

On Fri, Jul 26, 2013 at 06:41:27AM +0100, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar at caviumnetworks.com>
> 
> In case of normal kexec kernel load, all cpu's are offlined
> before calling machine_kexec() under kernel_kexec() function.
> But in case crash panic cpus are relaxed in
> machine_crash_nonpanic_core() SMP function but not offlined.
> 
> When crash kernel is loaded with kexec and on panic trigger
> machine_kexec() checks for number of cpus online.
> If more than one cpu is online machine_kexec() fails to load
> with below error
> 
> kexec: error: multiple CPUs still online
> 
> In machine_crash_nonpanic_core() SMP function, offline CPU
> before cpu_relax
> 
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar at caviumnetworks.com>
> ---
>  arch/arm/kernel/machine_kexec.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index 4fb074c..163b160 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -73,6 +73,7 @@ void machine_crash_nonpanic_core(void *unused)
>  	crash_save_cpu(&regs, smp_processor_id());
>  	flush_cache_all();
>  
> +	set_cpu_online(smp_processor_id(), false);
>  	atomic_dec(&waiting_for_crash_ipi);
>  	while (1)
>  		cpu_relax();

Ok, I guess this will work since the new kernel is loaded somewhere higher
in memory and the crashed kernel will stick around, so the non-crashing CPUs
can sit around spinning.

Will


From ben.dooks at codethink.co.uk  Fri Jul 26 06:52:36 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Fri, 26 Jul 2013 11:52:36 +0100
Subject: fyi - kprobes testing patches
In-Reply-To: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
References: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <51F254F4.5020900@codethink.co.uk>

On 25/07/13 22:08, Ben Dooks wrote:
> I've been working on kprobes and the kprobes-test driver. It seems
> there are more issues with the kprobes-test that need looking in to
> so I am putting this series out to see if anyone has any comments

the testing logs show a few failures with BE8 mode, however with the
patch series applied the kernel no longer oopses during testing.
                 > FAIL: registers differ 

> FAIL: Test mov  pc, r0, asl r1
> FAIL: Scenario 0
> initial_regs:
> r0  8001b37c | r1  00000000 | r2  21522352 | r3  21522252
> r4  21522552 | r5  21522452 | r6  21522752 | r7  21522652
> r8  21522952 | r9  21522852 | r10 21522b52 | r11 21522a52
> r12 21522d52 | sp  9f847dd4 | lr  21522f52 | pc  8001b370
> cpsr 00000213
> expected_regs:
> expected_regs:
> r0  8001b37c | r1  00000000 | r2  21522352 | r3  21522252
> r4  21522552 | r5  21522452 | r6  21522752 | r7  21522652
> r8  21522952 | r9  21522852 | r10 21522b52 | r11 21522a52
> r12 21522d52 | sp  9f847dd4 | lr  21522f52 | pc  8001b374
> cpsr 00000213
> result_regs:
> r0  8001b37c | r1  00000000 | r2  21522352 | r3  21522252
> r4  21522552 | r5  21522452 | r6  21522752 | r7  21522652
> r8  21522952 | r9  21522852 | r10 21522b52 | r11 21522a52
> r12 21522d52 | sp  9f847dd4 | lr  21522f52 | pc  8001b37c
> cpsr 00000213




-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From thomas.petazzoni at free-electrons.com  Fri Jul 26 06:54:45 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 26 Jul 2013 12:54:45 +0200
Subject: [PATCH] pinctrl: sunxi: Fix gpio_set behaviour
In-Reply-To: <1374748876-23461-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374748876-23461-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20130726125445.612b2acf@skate>

Dear Maxime Ripard,

On Thu, 25 Jul 2013 12:41:16 +0200, Maxime Ripard wrote:
> The current gpio_set function is ignoring the previous value set in the
> GPIO value register, which leads in erasing the values already set for
> the other GPIOs in the same bank when setting the value of a given GPIO.
> 
> Add the usual read/mask/write pattern to fix this brown paper bag bug.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  drivers/pinctrl/pinctrl-sunxi.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
> index fc058b6..4f8bb18 100644
> --- a/drivers/pinctrl/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/pinctrl-sunxi.c
> @@ -464,8 +464,14 @@ static void sunxi_pinctrl_gpio_set(struct gpio_chip *chip,
>  	struct sunxi_pinctrl *pctl = dev_get_drvdata(chip->dev);
>  	u32 reg = sunxi_data_reg(offset);
>  	u8 index = sunxi_data_offset(offset);
> +	u32 regval = readl(pctl->membase + reg);
>  
> -	writel((value & DATA_PINS_MASK) << index, pctl->membase + reg);
> +	if (value)
> +		regval |= BIT(index);
> +	else
> +		regval &= ~(BIT(index));
> +
> +	writel(regval, pctl->membase + reg);

Hum, what about locking?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From broonie at kernel.org  Fri Jul 26 06:55:19 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Jul 2013 11:55:19 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
Message-ID: <20130726105519.GZ9858@sirena.org.uk>

On Thu, Jul 25, 2013 at 02:11:31PM -0500, Rob Herring wrote:

> I would argue that little has gone in (if reviewed) with the
> expectation that the binding will change. Many of the common bindings
> have had many rounds of review and they have not changed. My position
> any time I see an incompatible change has been that it require anyone
> affected to be okay with the change. This has pretty much been limited
> to specific platforms from what I've seen.

The big exception I've seen has been the OMAP hwmod stuff.  Plus of
course the case where things get moved into the DT bindings from the
board file as things are built up, but this should be becoming a non
issue as people move onto DT only boards (though I am worried about
people on systems where the SoC is described in DT).
-------------- 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/20130726/b7ddc32a/attachment-0001.sig>

From pullip.cho at samsung.com  Fri Jul 26 07:25:42 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 26 Jul 2013 20:25:42 +0900
Subject: [PATCH v8 00/12] iommu/exynos: Fixes and Enhancements of System MMU
 driver with DT
Message-ID: <003601ce89f2$dcfde200$96f9a600$@samsung.com>

The current exynos-iommu(System MMU) driver does not work autonomously
since it is lack of support for power management of peripheral blocks.
For example, MFC device driver must ensure that its System MMU is disabled
before MFC block is power-down not to invalidate IOTLB in the System MMU
when I/O memory mapping is changed. Because A System MMU is resides in the
same H/W block, access to control registers of System MMU while the H/W
block is turned off must be prohibited.

This set of changes solves the above problem with setting each System MMUs
as the parent of the device which owns the System MMU to recieve the
information when the device is turned off or turned on.

Another big change to the driver is the support for devicetree.
The bindings for System MMU is described in
Documentation/devicetree/bindings/arm/samsung/system-mmu.txt

In addition, this patchset also includes several bug fixes and enhancements
of the current driver.

Change log:
v8:
- Reordered patch list: moved "change rwloc to spinlock" to the last.
- Fixed remained bug in "fix page table maintenance".
- Always return 0 from exynos_iommu_attach_device().
- Removed prefetch buffer setting when System MMU is enabled
  due to the restriction of prefetch buffers:
  A prefetch buffer must not hit from more than one DMA.
  For instance with GScalers, if a single prefetch buffer is initialized
  with 0x0 ~ 0xFFFFFFFF and a GScaler works on source buffer at 0x10000000
  and target buffer @ 0x20000000, the System MMU may be got deadlock.
  Clients must initialize prefetch buffers with custom function defined
  in exynos-iommu drivers whenever they need to enable prefetch buffers.
- The clock of System MMU has no relationship with the clock of its master H/W.
  The clock of master H/W is always enabled when exynos-iommu driver needs to
  access MMIO area and disabled as soon as the access finishes.
- Removed err_page variable used in exynos_iommu_unmap() in the previous patch
  "fix page table maintenance".
- Split a big patch "add bus notifier for registering System MMU".
   Extracted the following 2 patches: 9/12 and 10/12.
- And some additional fixes...

v7:
- Rebased on the stable 3.10
- Registered PM domains and gate clocks with DT
- Changed connection method between a System MMU and its master H/W
   'mmu-master' property in the node of System MMU
   --> 'iommu' property in the node of master H/W
- Marking device descriptor of master H/W of a System MMU with bus notifier.
- Power management (PM_RUNTIME, PM_SLEEP) of System MMUs with gpd_dev_ops
   of Generic IO Powerdomain. gpd_dev_ops are set to the master H/Ws
   before they are probed in the bus notifier.
- Removed additional debugging features like debugfs entries and
   version names.
- Removed support for advanced features of System MMU 3.2 and 3.3
   the current IOMMU API cannot handle the feature
  (A kind of L2 TLB that fetches several consequence page table entries.
   It must be initialized by the driver of master H/W whenever it works.)

v6:
- Rebased on the branch, next/iommu-exynos of
  git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git

v5:
- new bugfix: patch 01
- Reordered patches
  * patch 01 ~ 05: Bugfix and enhancements of the existing driver
  * patch 06 ~ 10: Device Tree support and callbacks for power management
  * patch 11     : System MMU 3.2 and 3.3 support
  * patch 12 ~ 14: Debugging features
- Additional code compaction

v4:
- Remove Change-Id from v3 patches
- Change the order of the third and the first patch
  Thanks to Kukjin Kim.
- Fix memory leak when allocating and assigning exynos_iommu_owner to client
  device if the client device has multiple System MMUs.
  Thanks to Rahul Sharma.

v3:
- Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
- Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
  Thanks to Prathyush.

v2:
- Split the patch to iommu/exynos into 9 patches
- Support for System MMU 3.3
- Some code compaction

Patch summary:
[PATCH v8 01/12] iommu/exynos: do not include removed header
[PATCH v8 02/12] iommu/exynos: add missing cache flush for removed page table entries
[PATCH v8 03/12] iommu/exynos: fix page table maintenance
[PATCH v8 04/12] iommu/exynos: allocate lv2 page table from own slab
[PATCH v8 05/12] clk: exynos5250: add gate clock descriptions of System MMU
[PATCH v8 06/12] ARM: dts: Add description of System MMU of Exynos SoCs
[PATCH v8 07/12] iommu/exynos: support for device tree
[PATCH v8 08/12] iommu/exynos: remove prefetch buffer setting when enabling System MMU
[PATCH v8 09/12] iommu/exynos: remove custom fault handler
[PATCH v8 10/12] iommu/exynos: add bus notifier for registering System MMU
[PATCH v8 11/12] iommu/exynos: change rwlock to spinlock
[PATCH v8 12/12] iommu/exynos: return 0 if iommu_attach_device() successes

Diffstats:
.../devicetree/bindings/clock/exynos5250-clock.txt |   28 +-
.../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 ++
arch/arm/boot/dts/exynos4.dtsi                     |  122 +++
arch/arm/boot/dts/exynos4210.dtsi                  |   25 +
arch/arm/boot/dts/exynos4x12.dtsi                  |   76 ++
arch/arm/boot/dts/exynos5250.dtsi                  |  291 ++++++
drivers/clk/samsung/clk-exynos5250.c               |   57 +-
drivers/iommu/Kconfig                              |    5 +-
drivers/iommu/exynos-iommu.c                       | 1033 +++++++++++++-------
9 files changed, 1398 insertions(+), 342 deletions(-)



From pullip.cho at samsung.com  Fri Jul 26 07:26:10 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 26 Jul 2013 20:26:10 +0900
Subject: [PATCH v8 01/12] iommu/exynos: do not include removed header
Message-ID: <003701ce89f2$eda94ef0$c8fbecd0$@samsung.com>

This commit remove <mach/sysmmu.h> which is removed.

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 3f32d64..233f382 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -12,6 +12,7 @@
 #define DEBUG
 #endif
 
+#include <linux/kernel.h>
 #include <linux/io.h>
 #include <linux/interrupt.h>
 #include <linux/platform_device.h>
@@ -29,8 +30,6 @@
 #include <asm/cacheflush.h>
 #include <asm/pgtable.h>
 
-#include <mach/sysmmu.h>
-
 /* We does not consider super section mapping (16MB) */
 #define SECT_ORDER 20
 #define LPAGE_ORDER 16
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul 26 07:26:28 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 26 Jul 2013 20:26:28 +0900
Subject: [PATCH v8 02/12] iommu/exynos: add missing cache flush for removed
 page table entries
Message-ID: <003801ce89f2$f8952d20$e9bf8760$@samsung.com>

This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 233f382..e3be3e5 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
 	if (lv2ent_small(ent)) {
 		*ent = 0;
 		size = SPAGE_SIZE;
+		pgtable_flush(ent, ent +1);
 		priv->lv2entcnt[lv1ent_offset(iova)] += 1;
 		goto done;
 	}
@@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
 	BUG_ON(size < LPAGE_SIZE);
 
 	memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
+	pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
 
 	size = LPAGE_SIZE;
 	priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE;
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul 26 07:27:11 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 26 Jul 2013 20:27:11 +0900
Subject: [PATCH v8 03/12] iommu/exynos: fix page table maintenance
Message-ID: <003901ce89f3$126c0390$37440ab0$@samsung.com>

This prevents allocating lv2 page table for the lv1 page table entry
that already has 1MB page mapping. In addition some BUG_ON() is
changed to WARN_ON().

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |   52 +++++++++++++++++++++++++++++------------
 1 files changed, 37 insertions(+), 15 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index e3be3e5..6c4ecce 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -52,11 +52,11 @@
 #define lv2ent_large(pent) ((*(pent) & 3) == 1)
 
 #define section_phys(sent) (*(sent) & SECT_MASK)
-#define section_offs(iova) ((iova) & 0xFFFFF)
+#define section_offs(iova) ((iova) & ~SECT_MASK)
 #define lpage_phys(pent) (*(pent) & LPAGE_MASK)
-#define lpage_offs(iova) ((iova) & 0xFFFF)
+#define lpage_offs(iova) ((iova) & ~LPAGE_MASK)
 #define spage_phys(pent) (*(pent) & SPAGE_MASK)
-#define spage_offs(iova) ((iova) & 0xFFF)
+#define spage_offs(iova) ((iova) & ~SPAGE_MASK)
 
 #define lv1ent_offset(iova) ((iova) >> SECT_ORDER)
 #define lv2ent_offset(iova) (((iova) & 0xFF000) >> SPAGE_ORDER)
@@ -862,12 +862,14 @@ static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long iova,
 		pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
 		BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
 		if (!pent)
-			return NULL;
+			return ERR_PTR(-ENOMEM);
 
 		*sent = mk_lv1ent_page(__pa(pent));
 		*pgcounter = NUM_LV2ENTRIES;
 		pgtable_flush(pent, pent + NUM_LV2ENTRIES);
 		pgtable_flush(sent, sent + 1);
+	} else if (lv1ent_section(sent)) {
+		return ERR_PTR(-EADDRINUSE);
 	}
 
 	return page_entry(sent, iova);
@@ -894,6 +896,12 @@ static int lv1set_section(unsigned long *sent, phys_addr_t paddr, short *pgcnt)
 	return 0;
 }
 
+static void clear_page_table(unsigned long *ent, int n)
+{
+	if (n > 0)
+		memset(ent, 0, sizeof(*ent) * n);
+}
+
 static int lv2set_page(unsigned long *pent, phys_addr_t paddr, size_t size,
 								short *pgcnt)
 {
@@ -908,7 +916,7 @@ static int lv2set_page(unsigned long *pent, phys_addr_t paddr, size_t size,
 		int i;
 		for (i = 0; i < SPAGES_PER_LPAGE; i++, pent++) {
 			if (!lv2ent_fault(pent)) {
-				memset(pent, 0, sizeof(*pent) * i);
+				clear_page_table(pent - i, i);
 				return -EADDRINUSE;
 			}
 
@@ -944,17 +952,16 @@ static int exynos_iommu_map(struct iommu_domain *domain, unsigned long iova,
 		pent = alloc_lv2entry(entry, iova,
 					&priv->lv2entcnt[lv1ent_offset(iova)]);
 
-		if (!pent)
-			ret = -ENOMEM;
+		if (IS_ERR(pent))
+			ret = PTR_ERR(pent);
 		else
 			ret = lv2set_page(pent, paddr, size,
 					&priv->lv2entcnt[lv1ent_offset(iova)]);
 	}
 
-	if (ret) {
-		pr_debug("%s: Failed to map iova 0x%lx/0x%x bytes\n",
-							__func__, iova, size);
-	}
+	if (ret)
+		pr_err("%s: Failed(%d) to map 0x%#x bytes @ %#lx\n",
+			__func__, ret, size, iova);
 
 	spin_unlock_irqrestore(&priv->pgtablelock, flags);
 
@@ -968,6 +975,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
 	struct sysmmu_drvdata *data;
 	unsigned long flags;
 	unsigned long *ent;
+	size_t err_pgsize;
 
 	BUG_ON(priv->pgtable == NULL);
 
@@ -976,7 +984,10 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
 	ent = section_entry(priv->pgtable, iova);
 
 	if (lv1ent_section(ent)) {
-		BUG_ON(size < SECT_SIZE);
+		if (WARN_ON(size < SECT_SIZE)) {
+			err_pgsize = SECT_SIZE;
+			goto err;
+		}
 
 		*ent = 0;
 		pgtable_flush(ent, ent + 1);
@@ -1008,9 +1019,12 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
 	}
 
 	/* lv1ent_large(ent) == true here */
-	BUG_ON(size < LPAGE_SIZE);
+	if (WARN_ON(size < LPAGE_SIZE)) {
+		err_pgsize = LPAGE_SIZE;
+		goto err;
+	}
 
-	memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
+	clear_page_table(ent, SPAGES_PER_LPAGE);
 	pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
 
 	size = LPAGE_SIZE;
@@ -1023,8 +1037,16 @@ done:
 		sysmmu_tlb_invalidate_entry(data->dev, iova);
 	spin_unlock_irqrestore(&priv->lock, flags);
 
-
 	return size;
+err:
+	spin_unlock_irqrestore(&priv->pgtablelock, flags);
+
+	pr_err("%s: Failed due to size(%#x) @ %#lx is"\
+		" smaller than page size %#x\n",
+		__func__, size, iova, err_pgsize);
+
+	return 0;
+
 }
 
 static phys_addr_t exynos_iommu_iova_to_phys(struct iommu_domain *domain,
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul 26 07:27:29 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 26 Jul 2013 20:27:29 +0900
Subject: [PATCH v8 04/12] iommu/exynos: allocate lv2 page table from own slab
Message-ID: <003a01ce89f3$1cb475d0$561d6170$@samsung.com>

Since kmalloc() does not guarantee that the allignment of 1KiB when it
allocates 1KiB, it is required to allocate lv2 page table from own
slab that guarantees alignment of 1KiB

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |   24 ++++++++++++++++++++----
 1 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 6c4ecce..093eea5 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -100,6 +100,8 @@
 #define REG_PB1_SADDR		0x054
 #define REG_PB1_EADDR		0x058
 
+static struct kmem_cache *lv2table_kmem_cache;
+
 static unsigned long *section_entry(unsigned long *pgtable, unsigned long iova)
 {
 	return pgtable + lv1ent_offset(iova);
@@ -765,7 +767,8 @@ static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
 
 	for (i = 0; i < NUM_LV1ENTRIES; i++)
 		if (lv1ent_page(priv->pgtable + i))
-			kfree(__va(lv2table_base(priv->pgtable + i)));
+			kmem_cache_free(lv2table_kmem_cache,
+					__va(lv2table_base(priv->pgtable + i)));
 
 	free_pages((unsigned long)priv->pgtable, 2);
 	free_pages((unsigned long)priv->lv2entcnt, 1);
@@ -859,7 +862,7 @@ static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long iova,
 	if (lv1ent_fault(sent)) {
 		unsigned long *pent;
 
-		pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
+		pent = kmem_cache_zalloc(lv2table_kmem_cache, GFP_ATOMIC);
 		BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
 		if (!pent)
 			return ERR_PTR(-ENOMEM);
@@ -884,7 +887,7 @@ static int lv1set_section(unsigned long *sent, phys_addr_t paddr, short *pgcnt)
 		if (*pgcnt != NUM_LV2ENTRIES)
 			return -EADDRINUSE;
 
-		kfree(page_entry(sent, 0));
+		kmem_cache_free(lv2table_kmem_cache, page_entry(sent, 0));
 
 		*pgcnt = 0;
 	}
@@ -1092,10 +1095,23 @@ static int __init exynos_iommu_init(void)
 {
 	int ret;
 
+	lv2table_kmem_cache = kmem_cache_create("exynos-iommu-lv2table",
+				LV2TABLE_SIZE, LV2TABLE_SIZE, 0, NULL);
+	if (!lv2table_kmem_cache) {
+		pr_err("%s: Failed to create kmem cache\n", __func__);
+		return -ENOMEM;
+	}
+
 	ret = platform_driver_register(&exynos_sysmmu_driver);
 
 	if (ret == 0)
-		bus_set_iommu(&platform_bus_type, &exynos_iommu_ops);
+		ret = bus_set_iommu(&platform_bus_type, &exynos_iommu_ops);
+
+	if (ret) {
+		pr_err("%s: Failed to register exynos-iommu driver.\n",
+								__func__);
+		kmem_cache_destroy(lv2table_kmem_cache);
+	}
 
 	return ret;
 }
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul 26 07:27:54 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 26 Jul 2013 20:27:54 +0900
Subject: [PATCH v8 05/12] clk: exynos5250: add gate clock descriptions of
 System MMU
Message-ID: <003b01ce89f3$2be4db80$83ae9280$@samsung.com>

This adds gate clocks of all System MMUs and their master IPs
that are not apeared in clk-exynos5250.c

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 .../devicetree/bindings/clock/exynos5250-clock.txt |   28 +++++++++-
 drivers/clk/samsung/clk-exynos5250.c               |   57 ++++++++++++++++---
 2 files changed, 75 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 781a627..df49694 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -154,7 +154,33 @@ clock which they consume.
   dsim0			341
   dp			342
   mixer			343
-  hdmi			345
+  hdmi			344
+  camif_top		345
+  smmu_fimc_lite0	346
+  smmu_fimc_lite1	347
+  smmu_fimc_lite2	348
+  smmu_tv		349
+  smmu_fimd1		350
+  smmu_2d		351
+  fimc_isp		352
+  fimc_drc		353
+  fimc_fd		354
+  fimc_scc		355
+  fimc_scp		356
+  fimc_mcuctl		357
+  fimc_odc		358
+  fimc_dis		359
+  fimc_3dnr		360
+  smmu_fimc_isp		361
+  smmu_fimc_drc		362
+  smmu_fimc_fd		363
+  smmu_fimc_scc		364
+  smmu_fimc_scp		365
+  smmu_fimc_mcuctl	366
+  smmu_fimc_odc		367
+  smmu_fimc_dis0	368
+  smmu_fimc_dis1	369
+  smmu_fimc_3dnr	370
 
 Example 1: An example of a clock controller node is listed below.
 
diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index 22d7699..e242bde 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -53,12 +53,15 @@
 #define DIV_PERIC3		0x10564
 #define DIV_PERIC4		0x10568
 #define DIV_PERIC5		0x1056c
+#define GATE_IP_ISP0		0x0C800
+#define GATE_IP_ISP1		0x0C800
 #define GATE_IP_GSCL		0x10920
 #define GATE_IP_MFC		0x1092c
 #define GATE_IP_GEN		0x10934
 #define GATE_IP_FSYS		0x10944
 #define GATE_IP_PERIC		0x10950
 #define GATE_IP_PERIS		0x10960
+#define GATE_IP_ACP		0x18800
 #define SRC_CDREX		0x20200
 #define PLL_DIV2_SEL		0x20a24
 #define GATE_IP_DISP1		0x10928
@@ -100,6 +103,14 @@ enum exynos5250_clks {
 	tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
 	wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
 
+	camif_top, smmu_fimc_lite0, smmu_fimc_lite1, smmu_fimc_lite2,
+	smmu_tv, smmu_fimd1, smmu_2d,
+	fimc_isp, fimc_drc, fimc_fd, fimc_scc, fimc_scp, fimc_mcuctl, fimc_odc,
+	fimc_dis, fimc_3dnr,
+	smmu_fimc_isp, smmu_fimc_drc, smmu_fimc_fd, smmu_fimc_scc,
+	smmu_fimc_scp, smmu_fimc_mcuctl, smmu_fimc_odc, smmu_fimc_dis0,
+	smmu_fimc_dis1, smmu_fimc_3dnr,
+
 	nr_clks,
 };
 
@@ -320,19 +331,26 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
 	GATE(gscl3, "gscl3", "aclk266", GATE_IP_GSCL, 3, 0, 0),
 	GATE(gscl_wa, "gscl_wa", "div_gscl_wa", GATE_IP_GSCL, 5, 0, 0),
 	GATE(gscl_wb, "gscl_wb", "div_gscl_wb", GATE_IP_GSCL, 6, 0, 0),
-	GATE(smmu_gscl0, "smmu_gscl0", "aclk266", GATE_IP_GSCL, 7, 0, 0),
-	GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
-	GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
-	GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
+	GATE(smmu_gscl0, "smmu_gscl0", "none", GATE_IP_GSCL, 7, 0, 0),
+	GATE(smmu_gscl1, "smmu_gscl1", "none", GATE_IP_GSCL, 8, 0, 0),
+	GATE(smmu_gscl2, "smmu_gscl2", "none", GATE_IP_GSCL, 9, 0, 0),
+	GATE(smmu_gscl3, "smmu_gscl3", "none", GATE_IP_GSCL, 10, 0, 0),
+	GATE(camif_top, "camif_top", "aclk266", GATE_IP_GSCL, 4, 0, 0),
+	GATE(smmu_fimc_lite0, "smmu_fimc_lite0", "none",
+						GATE_IP_GSCL, 12, 0, 0),
+	GATE(smmu_fimc_lite1, "smmu_fimc_lite1", "none",
+						GATE_IP_GSCL, 13, 0, 0),
+	GATE(smmu_fimc_lite2, "smmu_fimc_lite2", "none",
+						GATE_IP_GSCL, 14, 0, 0),
 	GATE(mfc, "mfc", "aclk333", GATE_IP_MFC, 0, 0, 0),
-	GATE(smmu_mfcl, "smmu_mfcl", "aclk333", GATE_IP_MFC, 1, 0, 0),
-	GATE(smmu_mfcr, "smmu_mfcr", "aclk333", GATE_IP_MFC, 2, 0, 0),
+	GATE(smmu_mfcr, "smmu_mfcr", "none", GATE_IP_MFC, 1, 0, 0),
+	GATE(smmu_mfcl, "smmu_mfcl", "none", GATE_IP_MFC, 2, 0, 0),
 	GATE(rotator, "rotator", "aclk266", GATE_IP_GEN, 1, 0, 0),
 	GATE(jpeg, "jpeg", "aclk166", GATE_IP_GEN, 2, 0, 0),
 	GATE(mdma1, "mdma1", "aclk266", GATE_IP_GEN, 4, 0, 0),
-	GATE(smmu_rotator, "smmu_rotator", "aclk266", GATE_IP_GEN, 6, 0, 0),
-	GATE(smmu_jpeg, "smmu_jpeg", "aclk166", GATE_IP_GEN, 7, 0, 0),
-	GATE(smmu_mdma1, "smmu_mdma1", "aclk266", GATE_IP_GEN, 9, 0, 0),
+	GATE(smmu_rotator, "smmu_rotator", "none", GATE_IP_GEN, 6, 0, 0),
+	GATE(smmu_jpeg, "smmu_jpeg", "none", GATE_IP_GEN, 7, 0, 0),
+	GATE(smmu_mdma1, "smmu_mdma1", "none", GATE_IP_GEN, 9, 0, 0),
 	GATE(pdma0, "pdma0", "aclk200", GATE_IP_FSYS, 1, 0, 0),
 	GATE(pdma1, "pdma1", "aclk200", GATE_IP_FSYS, 2, 0, 0),
 	GATE(sata, "sata", "aclk200", GATE_IP_FSYS, 6, 0, 0),
@@ -462,6 +480,27 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
 	GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
 	GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
 	GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
+	GATE(smmu_tv, "smmu_tv", "none", GATE_IP_DISP1, 2, 0, 0),
+	GATE(smmu_fimd1, "smmu_fimd1", "none", GATE_IP_DISP1, 8, 0, 0),
+
+	GATE(smmu_fimc_isp, "smmu_fimc_isp", "none", GATE_IP_ISP0, 8, 0, 0),
+	GATE(smmu_fimc_drc, "smmu_fimc_drc", "none", GATE_IP_ISP0, 9, 0, 0),
+	GATE(smmu_fimc_fd, "smmu_fimc_fd", "none", GATE_IP_ISP0, 10, 0, 0),
+	GATE(smmu_fimc_scc, "smmu_fimc_scc", "none",
+							GATE_IP_ISP0, 11, 0, 0),
+	GATE(smmu_fimc_scp, "smmu_fimc_scp", "none",
+							GATE_IP_ISP0, 12, 0, 0),
+	GATE(smmu_fimc_mcuctl, "smmu_fimc_mcuctl", "none",
+							GATE_IP_ISP0, 13, 0, 0),
+	GATE(smmu_fimc_odc, "smmu_fimc_odc", "none", GATE_IP_ISP1, 4, 0, 0),
+	GATE(smmu_fimc_dis0, "smmu_fimc_dis0", "none",
+							GATE_IP_ISP1, 5, 0, 0),
+	GATE(smmu_fimc_dis1, "smmu_fimc_dis1", "none",
+							GATE_IP_ISP1, 6, 0, 0),
+	GATE(smmu_fimc_3dnr, "smmu_fimc_3dnr", "none",
+							GATE_IP_ISP1, 7, 0, 0),
+
+	GATE(smmu_2d, "smmu_2d", "none", GATE_IP_ACP, 7, 0, 0),
 };
 
 static __initdata struct of_device_id ext_clk_match[] = {
-- 
1.7.2.5




From jason at lakedaemon.net  Fri Jul 26 07:27:57 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 26 Jul 2013 07:27:57 -0400
Subject: Location for a kind of GPIO bus driver
In-Reply-To: <20130726085623.GM9916@kw.sim.vm.gnt>
References: <20130723151834.GJ9916@kw.sim.vm.gnt>
 <20130724181924.GI19736@titan.lakedaemon.net>
 <20130725154932.GL9916@kw.sim.vm.gnt>
 <20130725160324.GJ23879@titan.lakedaemon.net>
 <20130726085623.GM9916@kw.sim.vm.gnt>
Message-ID: <20130726112757.GA29916@titan.lakedaemon.net>

On Fri, Jul 26, 2013 at 10:56:23AM +0200, Simon Guinot wrote:
> On Thu, Jul 25, 2013 at 12:03:24PM -0400, Jason Cooper wrote:
> > On Thu, Jul 25, 2013 at 05:49:32PM +0200, Simon Guinot wrote:
> > > On Wed, Jul 24, 2013 at 02:19:24PM -0400, Jason Cooper wrote:
> > > > On Tue, Jul 23, 2013 at 05:18:34PM +0200, Simon Guinot wrote:
> > > > > Hi,
> > > > > 
> > > > > I am currently working on converting the LED driver leds-netxbig to DT.
> > > > > Doing so, I am also considering to move the GPIO extension bus functions
> > > > > (which are currently parts of leds-netxbig) into a separate driver.
> > > > > 
> > > > > On the LaCie "Big Network" board family (netxbig), the LEDs are
> > > > > controlled by a CPLD. In turn, the CPLD can be configured (mostly the
> > > > > LEDs modes) through a kind of parallel GPIO bus, called GPIO extension
> > > > > bus. Two registers (address and data) are exposed. Each of them is made
> > > > > up of several GPIOs. An extra GPIO is used to notify the CPLD that the
> > > > > registers have been updated. The leds-netxbig driver uses some dedicated
> > > > > functions (prefixed by "gpio_ext_") to handle the GPIO bus extension.
> > > > > 
> > > > > On the latest "Big Network" boards, this bus is also used to enable the
> > > > > PM wakeup sources: the CPLD can be asked to keep powered some devices
> > > > > (as the RTC or the Ethernet PHY) while the board is down. I think it
> > > > > could be nice to expose this feature to the userland. That's why I am
> > > > > thinking about moving the GPIO extension bus support into a separate
> > > > > driver. The problem is that I can't find a proper location for a such
> > > > > driver. AFAIK, it doesn't fit with anything existing supported by Linux.
> > > > > Maybe I should consider drivers/bus ? Or even drivers/misc ?
> > > 
> > > Hi Jason,
> > > 
> > > Thanks for your answer.
> > > 
> > > > 
> > > > iiuc, the CPLD is more of gpio multiplexer/expander.  Have you seen
> > > > 
> > > >   66bcb58 arm: mvebu: enable gpio expander over i2c on Mirabox platform
> > > > 
> > > > ?  And the corresponding driver, drivers/gpio/gpio-pca953x.c?
> > > 
> > > All the drivers under drivers/gpio are registering some GPIO chips.
> > > It is a big difference with the LaCie "GPIO extension bus". This last
> > > is more an extension mechanism on the top of GPIOs already existing
> > > (eventually provided by a SoC or a Super-I/O on x86 boards). No new
> > > GPIOs are added. I think that the name "extension" is quite confusing.
> > 
> > Agreed.
> > 
> > > The idea behind this "bus" is to allow to configure a lot of LEDs (in
> > > various modes) using only few GPIOs and a CPLD (which is already
> > > available on the board for other purposes). This cheap solution allows
> > > precisely to save the cost of a GPIO expander :)
> > > 
> > > As an example, you can see the "GPIO extension bus" configuration for
> > > the Kirkwood "Big Network" boards in:
> > > arch/arm/mach-kirkwood/netxbig_v2-setup.c:132.
> > > 
> > > > 
> > > > I would try drivers/gpio.  If there are complaints, it should be trivial
> > > > to move it in a new version of the series.
> > > 
> > > Why not, as long it is clear that the resulting driver will not provide
> > > a GPIO chip but rather functions as a library.
> > 
> > right, but the end result of what the library would do is expose a
> > series of LEDs and PM 'virtual gpios'.  So, even though it's not a gpio
> > expander per-se, it's still filling that role.  Or am I still missing
> > something?
> 
> The library could expose a function allowing to set the address and data
> registers: gpio_ext_set_value(int addr, int value).
> 
> Actually, it is how it works inside leds-netxbig. Simply this function
> would be also accessible by other drivers.

hmmm, at this point I'm inclined to say "post the code RFC" :-)  We can
bikeshed it all day long, and not get any further.  And to answer your
original question, put the library under drivers/bus.  Maybe something
like lacie_gpio?

thx,

Jason.


From pullip.cho at samsung.com  Fri Jul 26 07:28:19 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 26 Jul 2013 20:28:19 +0900
Subject: [PATCH v8 06/12] ARM: dts: Add description of System MMU of Exynos
 SoCs
Message-ID: <003c01ce89f3$3abc4bc0$b034e340$@samsung.com>

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++++++
 arch/arm/boot/dts/exynos4.dtsi                     |  122 ++++++++
 arch/arm/boot/dts/exynos4210.dtsi                  |   25 ++
 arch/arm/boot/dts/exynos4x12.dtsi                  |   76 +++++
 arch/arm/boot/dts/exynos5250.dtsi                  |  291 ++++++++++++++++++++
 5 files changed, 617 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt

diff --git a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
new file mode 100644
index 0000000..92f0a33
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
@@ -0,0 +1,103 @@
+Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management Unit)
+
+Samsung's Exynos architecture contains System MMU that enables scattered
+physical memory chunks visible as a contiguous region to DMA-capable peripheral
+devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
+
+System MMU is a sort of IOMMU and support identical translation table format to
+ARMv7 translation tables with minimum set of page properties including access
+permissions, shareability and security protection. In addition, System MMU has
+another capabilities like L2 TLB or block-fetch buffers to minimize translation
+latency.
+
+A System MMU is dedicated to a single master peripheral device.  Thus, it is
+important to specify the correct System MMU in the device node of its master
+device. Whereas a System MMU is dedicated to a master device, the master device
+may have more than one System MMU.
+
+Required properties:
+- compatible: Should be "samsung,exynos4210-sysmmu"
+- reg: A tuple of base address and size of System MMU registers.
+- interrupt-parent: The phandle of the interrupt controller of System MMU
+- interrupts: A tuple of numbers that indicates the interrupt source.
+- clock-names: Should be "sysmmu" if the System MMU is needed to gate its clock.
+               Please refer to the following documents:
+	       Documentation/devicetree/bindings/clock/clock-bindings.txt
+	       Documentation/devicetree/bindings/clock/exynos4-clock.txt
+	       Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+	       Optional "master" if the clock to the System MMU is gated by
+	       another gate clock other than "sysmmu". The System MMU driver
+	       sets "master" the parent of "sysmmu".
+	       Exynos4 SoCs, there needs no "master" clocks.
+	       Exynos5 SoCs, some System MMUs must have "master" clocks.
+- clocks: Required if the System MMU is needed to gate its clock.
+	  Please refer to the documents listed above.
+- samsung,power-domain: Required if the System MMU is needed to gate its power.
+	  Please refer to the following document:
+	  Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+
+Required properties for the master peripheral devices:
+- iommu: phandles to the System MMUs of the device
+
+Examples:
+A System MMU is dedicated to a single master device.
+	gsc_0:  gsc at 0x13e00000 {
+		compatible = "samsung,exynos5-gsc";
+		reg = <0x13e00000 0x1000>;
+		interrupts = <0 85 0>;
+		samsung,power-domain = <&pd_gsc>;
+		clocks = <&clock 256>;
+		clock-names = "gscl";
+		iommu = <&sysmmu_gsc1>;
+	};
+
+	sysmmu_gsc0: sysmmu at 13E80000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13E80000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-gsc0";
+		interrupts = <2 0>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 262>, <&clock 256>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+MFC has 2 System MMUs for each port that MFC is attached. Thus it seems natural
+to define 2 System MMUs for each port of the MFC:
+
+	mfc: codec at 13400000 {
+		compatible = "samsung,mfc-v5";
+		reg = <0x13400000 0x10000>;
+		interrupts = <0 94 0>;
+		samsung,power-domain = <&pd_mfc>;
+		clocks = <&clock 170>, <&clock 273>;
+		clock-names = "sclk_mfc", "mfc";
+		status = "ok";
+		iommu = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>;
+	};
+
+	sysmmu_mfc_l: sysmmu at 13620000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13620000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-mfc-l";
+		interrupts = <5 5>;
+		clock-names = "sysmmu";
+		clocks = <&clock 274>;
+		samsung,power-domain = <&pd_mfc>;
+		status = "ok";
+	};
+
+	sysmmu_mfc_r: sysmmu at 13630000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13630000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-mfc-r";
+		interrupts = <5 6>;
+		clock-names = "sysmmu";
+		clocks = <&clock 275>;
+		samsung,power-domain = <&pd_mfc>;
+		status = "ok";
+	};
+
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 359694c..ba74ee8 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -161,6 +161,7 @@
 		interrupts = <0 94 0>;
 		samsung,power-domain = <&pd_mfc>;
 		status = "disabled";
+		iommu = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>;
 	};
 
 	serial at 13800000 {
@@ -395,5 +396,126 @@
 		clock-names = "sclk_fimd", "fimd";
 		samsung,power-domain = <&pd_lcd0>;
 		status = "disabled";
+		iommu = <&sysmmu_fimd0>;
+	};
+
+	sysmmu_mfc_l: sysmmu at 13620000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13620000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-mfc-l";
+		interrupts = <5 5>;
+		clock-names = "sysmmu";
+		clocks = <&clock 274>;
+		samsung,power-domain = <&pd_mfc>;
+		status = "ok";
+	};
+
+	sysmmu_mfc_r: sysmmu at 13630000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13630000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-mfc-r";
+		interrupts = <5 6>;
+		clock-names = "sysmmu";
+		clocks = <&clock 275>;
+		samsung,power-domain = <&pd_mfc>;
+		status = "ok";
+	};
+
+	sysmmu_tv: sysmmu at 13E20000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13E20000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-tv";
+		interrupts = <5 4>;
+		clock-names = "sysmmu";
+		clocks = <&clock 272>;
+		samsung,power-domain = <&pd_tv>;
+		status = "ok";
+	};
+
+	sysmmu_fimc0: sysmmu at 11A20000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11A20000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc0";
+		interrupts = <4 2>;
+		clock-names = "sysmmu";
+		clocks = <&clock 263>;
+		samsung,power-domain = <&pd_cam>;
+		status = "ok";
+	};
+
+	sysmmu_fimc1: sysmmu at 11A30000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11A30000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc1";
+		interrupts = <4 3>;
+		clock-names = "sysmmu";
+		clocks = <&clock 264>;
+		samsung,power-domain = <&pd_cam>;
+		status = "ok";
+	};
+
+	sysmmu_fimc2: sysmmu at 11A40000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11A40000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc2";
+		interrupts = <4 4>;
+		clock-names = "sysmmu";
+		clocks = <&clock 265>;
+		samsung,power-domain = <&pd_cam>;
+		status = "ok";
+	};
+
+	sysmmu_fimc3: sysmmu at 11A50000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11A50000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc3";
+		interrupts = <4 5>;
+		clock-names = "sysmmu";
+		clocks = <&clock 266>;
+		samsung,power-domain = <&pd_cam>;
+		status = "ok";
+	};
+
+	sysmmu_jpeg: sysmmu at 11A60000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11A60000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-jpeg";
+		interrupts = <4 6>;
+		clock-names = "sysmmu";
+		clocks = <&clock 267>;
+		samsung,power-domain = <&pd_cam>;
+		status = "ok";
+	};
+
+	sysmmu_rotator: sysmmu at 12A30000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x12A30000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-rotator";
+		interrupts = <5 0>;
+		clock-names = "sysmmu";
+		clocks = <&clock 281>;
+		samsung,power-domain = <&pd_lcd0>;
+		status = "ok";
+	};
+
+	sysmmu_fimd0: sysmmu at 11E20000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11E20000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimd0";
+		interrupts = <5 2>;
+		clock-names = "sysmmu";
+		clocks = <&clock 287>;
+		samsung,power-domain = <&pd_lcd0>;
+		status = "ok";
 	};
 };
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 54710de..09b13da 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -119,5 +119,30 @@
 		reg = <0x12800000 0x1000>;
 		interrupts = <0 89 0>;
 		status = "disabled";
+		iommu = <&sysmmu_g2d>;
+	};
+
+	sysmmu_g2d: sysmmu at 12A20000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x12A20000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-g2d";
+		interrupts = <4 7>;
+		clock-names = "sysmmu";
+		clocks = <&clock 280>;
+		samsung,power-domain = <&pd_lcd0>;
+		status = "ok";
+	};
+
+	sysmmu_fimd1: sysmmu at 12220000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimd1";
+		reg = <0x12220000 0x1000>;
+		interrupts = <5 3>;
+		clock-names = "sysmmu";
+		clocks = <&clock 291>;
+		samsung,power-domain = <&pd_lcd1>;
+		status = "ok";
 	};
 };
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index e3380a7..681db32 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -79,4 +79,80 @@
 		interrupts = <0 89 0>;
 		status = "disabled";
 	};
+
+	sysmmu_g2d: sysmmu at 10A40000{
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x10A40000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-g2d";
+		interrupts = <4 7>;
+		clock-names = "sysmmu";
+		status = "ok";
+	};
+
+	sysmmu_fimc_isp: sysmmu at 12260000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x12260000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_isp";
+		interrupts = <16 2>;
+		clock-names = "sysmmu";
+		clocks = <&clock 362>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_drc: sysmmu at 12270000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x12270000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_drc";
+		interrupts = <16 3>;
+		clock-names = "sysmmu";
+		clocks = <&clock 363>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_fd: sysmmu at 122A0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x122A0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_fd";
+		interrupts = <16 4>;
+		clock-names = "sysmmu";
+		clocks = <&clock 364>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_mcuctl: sysmmu at 122B0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x122B0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_mcuctl";
+		interrupts = <16 5>;
+		clock-names = "sysmmu";
+		clocks = <&clock 376>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_lite0: sysmmu at 123B0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x123B0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_lite0";
+		interrupts = <16 0>;
+		clock-names = "sysmmu";
+		clocks = <&clock 366>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_lite1: sysmmu at 123C0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x123C0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_lite1";
+		interrupts = <16 1>;
+		clock-names = "sysmmu";
+		clocks = <&clock 365>;
+		status = "ok";
+	};
 };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index fc9fb3d..130d23d 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -66,6 +66,16 @@
 		reg = <0x10044040 0x20>;
 	};
 
+	pd_isp: mfc-power-domain at 0x10044020 {
+		compatible = "samsung,exynos4210-pd";
+		reg = <0x10044020 0x20>;
+	};
+
+	pd_disp1: mfc-power-domain at 0x100440A0 {
+		compatible = "samsung,exynos4210-pd";
+		reg = <0x100440A0 0x20>;
+	};
+
 	clock: clock-controller at 0x10010000 {
 		compatible = "samsung,exynos5250-clock";
 		reg = <0x10010000 0x30000>;
@@ -180,6 +190,7 @@
 		reg = <0x11000000 0x10000>;
 		interrupts = <0 96 0>;
 		samsung,power-domain = <&pd_mfc>;
+		iommu = <&sysmmu_mfc_l &sysmmu_mfc_l>;
 	};
 
 	rtc {
@@ -571,6 +582,7 @@
 		samsung,power-domain = <&pd_gsc>;
 		clocks = <&clock 256>;
 		clock-names = "gscl";
+		iommu = <&sysmmu_gsc1>;
 	};
 
 	gsc_1:  gsc at 0x13e10000 {
@@ -580,6 +592,7 @@
 		samsung,power-domain = <&pd_gsc>;
 		clocks = <&clock 257>;
 		clock-names = "gscl";
+		iommu = <&sysmmu_gsc1>;
 	};
 
 	gsc_2:  gsc at 0x13e20000 {
@@ -589,6 +602,7 @@
 		samsung,power-domain = <&pd_gsc>;
 		clocks = <&clock 258>;
 		clock-names = "gscl";
+		iommu = <&sysmmu_gsc2>;
 	};
 
 	gsc_3:  gsc at 0x13e30000 {
@@ -598,6 +612,7 @@
 		samsung,power-domain = <&pd_gsc>;
 		clocks = <&clock 259>;
 		clock-names = "gscl";
+		iommu = <&sysmmu_gsc3>;
 	};
 
 	hdmi {
@@ -614,6 +629,7 @@
 		compatible = "samsung,exynos5-mixer";
 		reg = <0x14450000 0x10000>;
 		interrupts = <0 94 0>;
+		iommu = <&sysmmu_tv>;
 	};
 
 	dp-controller {
@@ -638,5 +654,280 @@
 		interrupts = <18 4>, <18 5>, <18 6>;
 		clocks = <&clock 133>, <&clock 339>;
 		clock-names = "sclk_fimd", "fimd";
+		iommu = <&sysmmu_fimd1>;
+	};
+
+	sysmmu_mfc_l: sysmmu at 11210000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11210000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-mfc_l";
+		interrupts = <8 5>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 267>, <&clock 266>;
+		samsung,power-domain = <&pd_mfc>;
+		status = "ok";
+	};
+
+	sysmmu_mfc_r: sysmmu at 11200000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11200000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-mfc_r";
+		interrupts = <6 2>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 268>, <&clock 266>;
+		samsung,power-domain = <&pd_mfc>;
+		status = "ok";
+	};
+
+	sysmmu_tv: sysmmu at 14650000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x14650000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-tv";
+		interrupts = <7 4>;
+		clock-names = "sysmmu";
+		clocks = <&clock 349>;
+		samsung,power-domain = <&pd_disp1>;
+		status = "ok";
+	};
+
+	sysmmu_gsc0: sysmmu at 13E80000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13E80000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-gsc0";
+		interrupts = <2 0>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 262>, <&clock 256>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+	sysmmu_gsc1: sysmmu at 13E90000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13E90000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-gsc1";
+		interrupts = <2 2>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 263>, <&clock 257>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+	sysmmu_gsc2: sysmmu at 13EA0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13EA0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-gsc2";
+		interrupts = <2 4>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 264>, <&clock 258>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+	sysmmu_gsc3: sysmmu at 13EB0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13EB0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-gsc3";
+		interrupts = <2 6>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 265>, <&clock 259>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+	sysmmu_fimd1: sysmmu at 14640000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x14640000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimd1";
+		interrupts = <3 2>;
+		clock-names = "sysmmu";
+		clocks = <&clock 350>;
+		samsung,power-domain = <&pd_disp1>;
+		status = "ok";
+	};
+
+	sysmmu_rotator: sysmmu at 11D40000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11D40000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-rotator";
+		interrupts = <4 0>;
+		clock-names = "sysmmu";
+		clocks = <&clock 272>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_isp: sysmmu at 13260000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13260000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_isp";
+		interrupts = <10 6>;
+		clock-names = "sysmmu";
+		clocks = <&clock 361>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_drc: sysmmu at 13270000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13270000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_drc";
+		interrupts = <11 6>;
+		clock-names = "sysmmu";
+		clocks = <&clock 362>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_fd: sysmmu at 132A0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x132A0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_fd";
+		interrupts = <5 0>;
+		clock-names = "sysmmu";
+		clocks = <&clock 363>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_scc: sysmmu at 13280000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13280000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_scalerc";
+		interrupts = <5 2>;
+		clock-names = "sysmmu";
+		clocks = <&clock 364>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_scp: sysmmu at 13290000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13290000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_scalerp";
+		interrupts = <3 6>;
+		clock-names = "sysmmu";
+		clocks = <&clock 365>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_mcuctl: sysmmu at 132B0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x132B0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_mcuctl";
+		interrupts = <5 4>;
+		clock-names = "sysmmu";
+		clocks = <&clock 366>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_odc: sysmmu at 132C0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x132C0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_odc";
+		interrupts = <11 0>;
+		clock-names = "sysmmu";
+		clocks = <&clock 367>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_dis0: sysmmu at 132D0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x132D0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_dis0";
+		interrupts = <10 4>;
+		clock-names = "sysmmu";
+		clocks = <&clock 368>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_dis1: sysmmu at 132E0000{
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x132E0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_dis1";
+		interrupts = <9 4>;
+		clock-names = "sysmmu";
+		clocks = <&clock 369>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_3dnr: sysmmu at 132F0000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x132F0000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_3dnr";
+		interrupts = <5 6>;
+		clock-names = "sysmmu";
+		clocks = <&clock 370>;
+		samsung,power-domain = <&pd_isp>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_lite0: sysmmu at 13C40000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13C40000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_lite0";
+		interrupts = <3 4>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 346>, <&clock 345>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_lite1: sysmmu at 13C50000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x13C50000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-fimc_lite1";
+		interrupts = <24 1>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 347>, <&clock 345>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_jpeg: sysmmu at 11F20000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x11F20000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-jpeg";
+		interrupts = <4 2>;
+		clock-names = "sysmmu", "master";
+		clocks = <&clock 273>, <&clock 270>;
+		samsung,power-domain = <&pd_gsc>;
+		status = "ok";
+	};
+
+	sysmmu_fimc_2d: sysmmu at 10A60000 {
+		compatible = "samsung,exynos4210-sysmmu";
+		reg = <0x10A60000 0x1000>;
+		interrupt-parent = <&combiner>;
+		interrupt-names = "sysmmu-2d";
+		interrupts = <24 5>;
+		clock-names = "sysmmu";
+		clocks = <&clock 361>;
+		status = "ok";
 	};
 };
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul 26 07:28:36 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 26 Jul 2013 20:28:36 +0900
Subject: [PATCH v8 07/12] iommu/exynos: support for device tree
Message-ID: <003d01ce89f3$44ec2cf0$cec486d0$@samsung.com>

This commit adds device tree support for System MMU.
This also include the following changes and enhancements:

* use managed device helper functions.
Simplyfies System MMU device driver.

* use only a single clock descriptor.
System MMU device descriptor is seperate if it is imposible to make
a single clock descriptor to make a device descriptor for a group of
System MMUs.

* removed dbgname member from sysmmu_drvdata structure.
debugging kernel message for a System MMU is distinguisheable with the
name of device descroptors.

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/Kconfig        |    5 +-
 drivers/iommu/exynos-iommu.c |  182 ++++++++++++++++--------------------------
 2 files changed, 70 insertions(+), 117 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index c332fb9..d45f3c9 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -168,16 +168,15 @@ config TEGRA_IOMMU_SMMU
 
 config EXYNOS_IOMMU
 	bool "Exynos IOMMU Support"
-	depends on ARCH_EXYNOS && EXYNOS_DEV_SYSMMU
+	depends on ARCH_EXYNOS
 	select IOMMU_API
+	default n
 	help
 	  Support for the IOMMU(System MMU) of Samsung Exynos application
 	  processor family. This enables H/W multimedia accellerators to see
 	  non-linear physical memory chunks as a linear memory in their
 	  address spaces
 
-	  If unsure, say N here.
-
 config EXYNOS_IOMMU_DEBUG
 	bool "Debugging log for Exynos IOMMU"
 	depends on EXYNOS_IOMMU
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 093eea5..cfc02ed 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -26,6 +26,7 @@
 #include <linux/list.h>
 #include <linux/memblock.h>
 #include <linux/export.h>
+#include <linux/of.h>
 
 #include <asm/cacheflush.h>
 #include <asm/pgtable.h>
@@ -170,15 +171,14 @@ struct sysmmu_drvdata {
 	struct list_head node; /* entry of exynos_iommu_domain.clients */
 	struct device *sysmmu;	/* System MMU's device descriptor */
 	struct device *dev;	/* Owner of system MMU */
-	char *dbgname;
 	int nsfrs;
-	void __iomem **sfrbases;
-	struct clk *clk[2];
+	struct clk *clk;
 	int activations;
 	rwlock_t lock;
 	struct iommu_domain *domain;
 	sysmmu_fault_handler_t fault_handler;
 	unsigned long pgtable;
+	void __iomem *sfrbases[0];
 };
 
 static bool set_sysmmu_active(struct sysmmu_drvdata *data)
@@ -385,8 +385,8 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 	if (!ret && (itype != SYSMMU_FAULT_UNKNOWN))
 		__raw_writel(1 << itype, data->sfrbases[i] + REG_INT_CLEAR);
 	else
-		dev_dbg(data->sysmmu, "(%s) %s is not handled.\n",
-				data->dbgname, sysmmu_fault_name[itype]);
+		dev_dbg(data->sysmmu, "%s is not handled.\n",
+				sysmmu_fault_name[itype]);
 
 	if (itype != SYSMMU_FAULT_UNKNOWN)
 		sysmmu_unblock(data->sfrbases[i]);
@@ -410,10 +410,8 @@ static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
 	for (i = 0; i < data->nsfrs; i++)
 		__raw_writel(CTRL_DISABLE, data->sfrbases[i] + REG_MMU_CTRL);
 
-	if (data->clk[1])
-		clk_disable(data->clk[1]);
-	if (data->clk[0])
-		clk_disable(data->clk[0]);
+	if (data->clk)
+		clk_disable(data->clk);
 
 	disabled = true;
 	data->pgtable = 0;
@@ -422,10 +420,10 @@ finish:
 	write_unlock_irqrestore(&data->lock, flags);
 
 	if (disabled)
-		dev_dbg(data->sysmmu, "(%s) Disabled\n", data->dbgname);
+		dev_dbg(data->sysmmu, "Disabled\n");
 	else
-		dev_dbg(data->sysmmu, "(%s) %d times left to be disabled\n",
-					data->dbgname, data->activations);
+		dev_dbg(data->sysmmu, "%d times left to be disabled\n",
+					data->activations);
 
 	return disabled;
 }
@@ -452,14 +450,12 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
 			ret = 1;
 		}
 
-		dev_dbg(data->sysmmu, "(%s) Already enabled\n", data->dbgname);
+		dev_dbg(data->sysmmu, "Already enabled\n");
 		goto finish;
 	}
 
-	if (data->clk[0])
-		clk_enable(data->clk[0]);
-	if (data->clk[1])
-		clk_enable(data->clk[1]);
+	if (data->clk)
+		clk_enable(data->clk);
 
 	data->pgtable = pgtable;
 
@@ -479,7 +475,7 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
 
 	data->domain = domain;
 
-	dev_dbg(data->sysmmu, "(%s) Enabled\n", data->dbgname);
+	dev_dbg(data->sysmmu, "Enabled\n");
 finish:
 	write_unlock_irqrestore(&data->lock, flags);
 
@@ -495,7 +491,7 @@ int exynos_sysmmu_enable(struct device *dev, unsigned long pgtable)
 
 	ret = pm_runtime_get_sync(data->sysmmu);
 	if (ret < 0) {
-		dev_dbg(data->sysmmu, "(%s) Failed to enable\n", data->dbgname);
+		dev_dbg(data->sysmmu, "Failed to enable\n");
 		return ret;
 	}
 
@@ -503,8 +499,8 @@ int exynos_sysmmu_enable(struct device *dev, unsigned long pgtable)
 	if (WARN_ON(ret < 0)) {
 		pm_runtime_put(data->sysmmu);
 		dev_err(data->sysmmu,
-			"(%s) Already enabled with page table %#lx\n",
-			data->dbgname, data->pgtable);
+			"Already enabled with page table %#lx\n",
+			data->pgtable);
 	} else {
 		data->dev = dev;
 	}
@@ -540,9 +536,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
 			}
 		}
 	} else {
-		dev_dbg(data->sysmmu,
-			"(%s) Disabled. Skipping invalidating TLB.\n",
-			data->dbgname);
+		dev_dbg(data->sysmmu, "Disabled. Skipping invalidating TLB.\n");
 	}
 
 	read_unlock_irqrestore(&data->lock, flags);
@@ -564,141 +558,101 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
 			}
 		}
 	} else {
-		dev_dbg(data->sysmmu,
-			"(%s) Disabled. Skipping invalidating TLB.\n",
-			data->dbgname);
+		dev_dbg(data->sysmmu, "Disabled. Skipping invalidating TLB.\n");
 	}
 
 	read_unlock_irqrestore(&data->lock, flags);
 }
 
-static int exynos_sysmmu_probe(struct platform_device *pdev)
+static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 {
 	int i, ret;
-	struct device *dev;
+	struct device *dev = &pdev->dev;
 	struct sysmmu_drvdata *data;
 
-	dev = &pdev->dev;
-
-	data = kzalloc(sizeof(*data), GFP_KERNEL);
-	if (!data) {
-		dev_dbg(dev, "Not enough memory\n");
-		ret = -ENOMEM;
-		goto err_alloc;
+	if (pdev->num_resources == 0) {
+		dev_err(dev, "No System MMU resource defined\n");
+		return -ENODEV;
 	}
 
-	ret = dev_set_drvdata(dev, data);
-	if (ret) {
-		dev_dbg(dev, "Unabled to initialize driver data\n");
-		goto err_init;
+	data = devm_kzalloc(dev,
+			sizeof(*data) +
+			sizeof(*data->sfrbases) * (pdev->num_resources / 2),
+			GFP_KERNEL);
+	if (!data) {
+		dev_err(dev, "Not enough memory for initialization\n");
+		return -ENOMEM;
 	}
 
 	data->nsfrs = pdev->num_resources / 2;
-	data->sfrbases = kmalloc(sizeof(*data->sfrbases) * data->nsfrs,
-								GFP_KERNEL);
-	if (data->sfrbases == NULL) {
-		dev_dbg(dev, "Not enough memory\n");
-		ret = -ENOMEM;
-		goto err_init;
-	}
 
 	for (i = 0; i < data->nsfrs; i++) {
 		struct resource *res;
+
 		res = platform_get_resource(pdev, IORESOURCE_MEM, i);
 		if (!res) {
-			dev_dbg(dev, "Unable to find IOMEM region\n");
-			ret = -ENOENT;
-			goto err_res;
+			dev_err(dev, "Unable to find IOMEM region\n");
+			return -ENOENT;
 		}
 
-		data->sfrbases[i] = ioremap(res->start, resource_size(res));
+		data->sfrbases[i] = devm_request_and_ioremap(dev, res);
 		if (!data->sfrbases[i]) {
-			dev_dbg(dev, "Unable to map IOMEM @ PA:%#x\n",
-							res->start);
-			ret = -ENOENT;
-			goto err_res;
+			dev_err(dev, "Unable to map IOMEM @ %#x\n", res->start);
+			return -EBUSY;
 		}
 	}
 
 	for (i = 0; i < data->nsfrs; i++) {
-		ret = platform_get_irq(pdev, i);
-		if (ret <= 0) {
-			dev_dbg(dev, "Unable to find IRQ resource\n");
-			goto err_irq;
+		int irq;
+
+		irq = platform_get_irq(pdev, i);
+		if (irq <= 0) {
+			dev_err(dev, "Unable to find IRQ resource\n");
+			return -ENOENT;
 		}
 
-		ret = request_irq(ret, exynos_sysmmu_irq, 0,
-					dev_name(dev), data);
+		ret = devm_request_irq(dev, irq, exynos_sysmmu_irq,
+					0, dev_name(dev), data);
 		if (ret) {
-			dev_dbg(dev, "Unabled to register interrupt handler\n");
-			goto err_irq;
+			dev_err(dev, "Unable to register handler to irq %d\n",
+				irq);
+			return ret;
 		}
 	}
 
-	if (dev_get_platdata(dev)) {
-		char *deli, *beg;
-		struct sysmmu_platform_data *platdata = dev_get_platdata(dev);
-
-		beg = platdata->clockname;
-
-		for (deli = beg; (*deli != '\0') && (*deli != ','); deli++)
-			/* NOTHING */;
-
-		if (*deli == '\0')
-			deli = NULL;
-		else
-			*deli = '\0';
-
-		data->clk[0] = clk_get(dev, beg);
-		if (IS_ERR(data->clk[0])) {
-			data->clk[0] = NULL;
-			dev_dbg(dev, "No clock descriptor registered\n");
-		}
+	pm_runtime_enable(dev);
 
-		if (data->clk[0] && deli) {
-			*deli = ',';
-			data->clk[1] = clk_get(dev, deli + 1);
-			if (IS_ERR(data->clk[1]))
-				data->clk[1] = NULL;
-		}
+	__set_fault_handler(data, &default_fault_handler);
 
-		data->dbgname = platdata->dbgname;
+	data->sysmmu = dev;
+	data->clk = devm_clk_get(dev, "sysmmu");
+	if (IS_ERR(data->clk)) {
+		dev_info(dev, "No gate clock found!\n");
+		data->clk = NULL;
 	}
 
-	data->sysmmu = dev;
 	rwlock_init(&data->lock);
 	INIT_LIST_HEAD(&data->node);
 
-	__set_fault_handler(data, &default_fault_handler);
-
-	if (dev->parent)
-		pm_runtime_enable(dev);
+	platform_set_drvdata(pdev, data);
+	dev_dbg(dev, "Probed and initialized\n");
 
-	dev_dbg(dev, "(%s) Initialized\n", data->dbgname);
-	return 0;
-err_irq:
-	while (i-- > 0) {
-		int irq;
-
-		irq = platform_get_irq(pdev, i);
-		free_irq(irq, data);
-	}
-err_res:
-	while (data->nsfrs-- > 0)
-		iounmap(data->sfrbases[data->nsfrs]);
-	kfree(data->sfrbases);
-err_init:
-	kfree(data);
-err_alloc:
-	dev_err(dev, "Failed to initialize\n");
 	return ret;
 }
 
-static struct platform_driver exynos_sysmmu_driver = {
-	.probe		= exynos_sysmmu_probe,
-	.driver		= {
+#ifdef CONFIG_OF
+static struct of_device_id sysmmu_of_match[] __initconst = {
+	{ .compatible	= "samsung,exynos4210-sysmmu", },
+	{ },
+};
+#endif
+
+static struct platform_driver exynos_sysmmu_driver __refdata = {
+	.probe	= exynos_sysmmu_probe,
+	.driver	= {
 		.owner		= THIS_MODULE,
 		.name		= "exynos-sysmmu",
+		.of_match_table	= of_match_ptr(sysmmu_of_match),
 	}
 };
 
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul 26 07:28:49 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 26 Jul 2013 20:28:49 +0900
Subject: [PATCH v8 08/12] iommu/exynos: remove prefetch buffer setting when
 enabling System MMU
Message-ID: <003e01ce89f3$4cdb45e0$e691d1a0$@samsung.com>

Prefetch buffer must be handled accurately, exact range of a buffer,
frame by frame manually. Otherwise, it may causes page fault or
deadlock in System MMU.
Thus this patch removes prefetch buffer setting when System MMU is
initialized(enabled).

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |   32 +++++++++++++++++++++++++++-----
 1 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index cfc02ed..87f6bb7 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -80,6 +80,8 @@
 #define CTRL_BLOCK	0x7
 #define CTRL_DISABLE	0x0
 
+#define CFG_FLPDCACHE	(1 << 20) /* System MMU 3.2+ only */
+
 #define REG_MMU_CTRL		0x000
 #define REG_MMU_CFG		0x004
 #define REG_MMU_STATUS		0x008
@@ -96,6 +98,9 @@
 
 #define REG_MMU_VERSION		0x034
 
+#define MMU_MAJ_VER(reg)	(reg >> 28)
+#define MMU_MIN_VER(reg)	((reg >> 21) & 0x7F)
+
 #define REG_PB0_SADDR		0x04C
 #define REG_PB0_EADDR		0x050
 #define REG_PB1_SADDR		0x054
@@ -200,6 +205,22 @@ static bool is_sysmmu_active(struct sysmmu_drvdata *data)
 	return data->activations > 0;
 }
 
+static unsigned int __sysmmu_version(struct sysmmu_drvdata *data,
+				     int idx, unsigned int *minor)
+{
+	unsigned long major;
+
+	major = readl(data->sfrbases[idx] + REG_MMU_VERSION);
+
+	if (minor)
+		*minor = MMU_MIN_VER(major);
+
+	if (MMU_MAJ_VER(major) > 3)
+		return 1;
+
+	return MMU_MAJ_VER(major);
+}
+
 static void sysmmu_unblock(void __iomem *sfrbase)
 {
 	__raw_writel(CTRL_ENABLE, sfrbase + REG_MMU_CTRL);
@@ -460,14 +481,15 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
 	data->pgtable = pgtable;
 
 	for (i = 0; i < data->nsfrs; i++) {
+		unsigned int min;
+
 		__sysmmu_set_ptbase(data->sfrbases[i], pgtable);
 
-		if ((readl(data->sfrbases[i] + REG_MMU_VERSION) >> 28) == 3) {
-			/* System MMU version is 3.x */
-			__raw_writel((1 << 12) | (2 << 28),
+		if ((__sysmmu_version(data, i, &min) == 3) && (min > 1)) {
+			unsigned long cfg;
+			cfg = __raw_readl(data->sfrbases[i] + REG_MMU_CFG);
+			__raw_writel(cfg | CFG_FLPDCACHE,
 					data->sfrbases[i] + REG_MMU_CFG);
-			__sysmmu_set_prefbuf(data->sfrbases[i], 0, -1, 0);
-			__sysmmu_set_prefbuf(data->sfrbases[i], 0, -1, 1);
 		}
 
 		__raw_writel(CTRL_ENABLE, data->sfrbases[i] + REG_MMU_CTRL);
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul 26 07:29:06 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 26 Jul 2013 20:29:06 +0900
Subject: [PATCH v8 09/12] iommu/exynos: remove custom fault handler
Message-ID: <003f01ce89f3$56ce9340$046bb9c0$@samsung.com>

This commit removes custom fault handler. The device drivers that
need to register fault handler can register
with iommu_set_fault_handler().

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |   71 ++++++++++--------------------------------
 1 files changed, 17 insertions(+), 54 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 87f6bb7..f9853fe 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -131,16 +131,6 @@ enum exynos_sysmmu_inttype {
 	SYSMMU_FAULTS_NUM
 };
 
-/*
- * @itype: type of fault.
- * @pgtable_base: the physical address of page table base. This is 0 if @itype
- *                is SYSMMU_BUSERROR.
- * @fault_addr: the device (virtual) address that the System MMU tried to
- *             translated. This is 0 if @itype is SYSMMU_BUSERROR.
- */
-typedef int (*sysmmu_fault_handler_t)(enum exynos_sysmmu_inttype itype,
-			unsigned long pgtable_base, unsigned long fault_addr);
-
 static unsigned short fault_reg_offset[SYSMMU_FAULTS_NUM] = {
 	REG_PAGE_FAULT_ADDR,
 	REG_AR_FAULT_ADDR,
@@ -181,7 +171,6 @@ struct sysmmu_drvdata {
 	int activations;
 	rwlock_t lock;
 	struct iommu_domain *domain;
-	sysmmu_fault_handler_t fault_handler;
 	unsigned long pgtable;
 	void __iomem *sfrbases[0];
 };
@@ -313,34 +302,17 @@ finish:
 	read_unlock_irqrestore(&data->lock, flags);
 }
 
-static void __set_fault_handler(struct sysmmu_drvdata *data,
-					sysmmu_fault_handler_t handler)
-{
-	unsigned long flags;
-
-	write_lock_irqsave(&data->lock, flags);
-	data->fault_handler = handler;
-	write_unlock_irqrestore(&data->lock, flags);
-}
-
-void exynos_sysmmu_set_fault_handler(struct device *dev,
-					sysmmu_fault_handler_t handler)
-{
-	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
-
-	__set_fault_handler(data, handler);
-}
-
-static int default_fault_handler(enum exynos_sysmmu_inttype itype,
-		     unsigned long pgtable_base, unsigned long fault_addr)
+static void show_fault_information(const char *name,
+		enum exynos_sysmmu_inttype itype,
+		unsigned long pgtable_base, unsigned long fault_addr)
 {
 	unsigned long *ent;
 
 	if ((itype >= SYSMMU_FAULTS_NUM) || (itype < SYSMMU_PAGEFAULT))
 		itype = SYSMMU_FAULT_UNKNOWN;
 
-	pr_err("%s occurred at 0x%lx(Page table base: 0x%lx)\n",
-			sysmmu_fault_name[itype], fault_addr, pgtable_base);
+	pr_err("%s occurred at 0x%lx by %s(Page table base: 0x%lx)\n",
+		sysmmu_fault_name[itype], fault_addr, name, pgtable_base);
 
 	ent = section_entry(__va(pgtable_base), fault_addr);
 	pr_err("\tLv1 entry: 0x%lx\n", *ent);
@@ -353,16 +325,12 @@ static int default_fault_handler(enum exynos_sysmmu_inttype itype,
 	pr_err("Generating Kernel OOPS... because it is unrecoverable.\n");
 
 	BUG();
-
-	return 0;
 }
 
 static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 {
 	/* SYSMMU is in blocked when interrupt occurred. */
 	struct sysmmu_drvdata *data = dev_id;
-	struct resource *irqres;
-	struct platform_device *pdev;
 	enum exynos_sysmmu_inttype itype;
 	unsigned long addr = -1;
 
@@ -372,14 +340,15 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 
 	WARN_ON(!is_sysmmu_active(data));
 
-	pdev = to_platform_device(data->sysmmu);
-	for (i = 0; i < (pdev->num_resources / 2); i++) {
-		irqres = platform_get_resource(pdev, IORESOURCE_IRQ, i);
+	for (i = 0; i < data->nsfrs; i++) {
+		struct resource *irqres;
+		irqres = platform_get_resource(to_platform_device(data->sysmmu),
+						IORESOURCE_IRQ, i);
 		if (irqres && ((int)irqres->start == irq))
 			break;
 	}
 
-	if (i == pdev->num_resources) {
+	if (i == data->nsfrs) {
 		itype = SYSMMU_FAULT_UNKNOWN;
 	} else {
 		itype = (enum exynos_sysmmu_inttype)
@@ -395,19 +364,15 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 		ret = report_iommu_fault(data->domain, data->dev,
 				addr, itype);
 
-	if ((ret == -ENOSYS) && data->fault_handler) {
-		unsigned long base = data->pgtable;
-		if (itype != SYSMMU_FAULT_UNKNOWN)
-			base = __raw_readl(
-					data->sfrbases[i] + REG_PT_BASE_ADDR);
-		ret = data->fault_handler(itype, base, addr);
-	}
-
 	if (!ret && (itype != SYSMMU_FAULT_UNKNOWN))
 		__raw_writel(1 << itype, data->sfrbases[i] + REG_INT_CLEAR);
-	else
-		dev_dbg(data->sysmmu, "%s is not handled.\n",
-				sysmmu_fault_name[itype]);
+	else {
+		unsigned long ba = data->pgtable;
+		if (itype != SYSMMU_FAULT_UNKNOWN)
+			ba = __raw_readl(data->sfrbases[i] + REG_PT_BASE_ADDR);
+		show_fault_information(dev_name(data->sysmmu),
+					itype, ba, addr);
+	}
 
 	if (itype != SYSMMU_FAULT_UNKNOWN)
 		sysmmu_unblock(data->sfrbases[i]);
@@ -644,8 +609,6 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 
 	pm_runtime_enable(dev);
 
-	__set_fault_handler(data, &default_fault_handler);
-
 	data->sysmmu = dev;
 	data->clk = devm_clk_get(dev, "sysmmu");
 	if (IS_ERR(data->clk)) {
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul 26 07:30:17 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 26 Jul 2013 20:30:17 +0900
Subject: [PATCH v8 10/12] iommu/exynos: add bus notifier for registering System
 MMU
Message-ID: <004001ce89f3$813c8b50$83b5a1f0$@samsung.com>

When a device driver is registered, all constructs to handle System MMU
is prepared by bus notifier call.

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |  708 ++++++++++++++++++++++++++++++++---------
 1 files changed, 552 insertions(+), 156 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index f9853fe..c62c244 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -27,6 +27,9 @@
 #include <linux/memblock.h>
 #include <linux/export.h>
 #include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/pm_domain.h>
+#include <linux/notifier.h>
 
 #include <asm/cacheflush.h>
 #include <asm/pgtable.h>
@@ -80,7 +83,13 @@
 #define CTRL_BLOCK	0x7
 #define CTRL_DISABLE	0x0
 
+#define CFG_LRU		0x1
+#define CFG_QOS(n)	((n & 0xF) << 7)
+#define CFG_MASK	0x0150FFFF /* Selecting bit 0-15, 20, 22 and 24 */
+#define CFG_ACGEN	(1 << 24) /* System MMU 3.3 only */
+#define CFG_SYSSEL	(1 << 22) /* System MMU 3.2 only */
 #define CFG_FLPDCACHE	(1 << 20) /* System MMU 3.2+ only */
+#define CFG_SHAREABLE	(1 << 12) /* System MMU 3.x only */
 
 #define REG_MMU_CTRL		0x000
 #define REG_MMU_CFG		0x004
@@ -154,6 +163,14 @@ static char *sysmmu_fault_name[SYSMMU_FAULTS_NUM] = {
 	"UNKNOWN FAULT"
 };
 
+struct exynos_iommu_client {
+	struct list_head node;	/* entry of exynos_iommu_domain.clients */
+	struct device *dev;
+	spinlock_t lock;
+	int num_sysmmu;
+	struct device *sysmmu[0];
+};
+
 struct exynos_iommu_domain {
 	struct list_head clients; /* list of sysmmu_drvdata.node */
 	unsigned long *pgtable; /* lv1 page table, 16KB */
@@ -165,12 +182,14 @@ struct exynos_iommu_domain {
 struct sysmmu_drvdata {
 	struct list_head node; /* entry of exynos_iommu_domain.clients */
 	struct device *sysmmu;	/* System MMU's device descriptor */
-	struct device *dev;	/* Owner of system MMU */
+	struct device *master;	/* Owner of system MMU */
 	int nsfrs;
 	struct clk *clk;
+	struct clk *clk_master;
 	int activations;
 	rwlock_t lock;
 	struct iommu_domain *domain;
+	bool runtime_active;
 	unsigned long pgtable;
 	void __iomem *sfrbases[0];
 };
@@ -245,7 +264,6 @@ static void __sysmmu_tlb_invalidate_entry(void __iomem *sfrbase,
 static void __sysmmu_set_ptbase(void __iomem *sfrbase,
 				       unsigned long pgd)
 {
-	__raw_writel(0x1, sfrbase + REG_MMU_CFG); /* 16KB LV1, LRU */
 	__raw_writel(pgd, sfrbase + REG_PT_BASE_ADDR);
 
 	__sysmmu_tlb_invalidate(sfrbase);
@@ -273,6 +291,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
 	if (!is_sysmmu_active(data))
 		goto finish;
 
+	clk_enable(data->clk_master);
 	for (i = 0; i < data->nsfrs; i++) {
 		if ((readl(data->sfrbases[i] + REG_MMU_VERSION) >> 28) == 3) {
 			if (!sysmmu_block(data->sfrbases[i]))
@@ -298,6 +317,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
 			sysmmu_unblock(data->sfrbases[i]);
 		}
 	}
+	clk_disable(data->clk_master);
 finish:
 	read_unlock_irqrestore(&data->lock, flags);
 }
@@ -331,12 +351,13 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 {
 	/* SYSMMU is in blocked when interrupt occurred. */
 	struct sysmmu_drvdata *data = dev_id;
+	struct exynos_iommu_client *client = NULL;
 	enum exynos_sysmmu_inttype itype;
 	unsigned long addr = -1;
-
 	int i, ret = -ENOSYS;
 
-	read_lock(&data->lock);
+	if (data->master)
+		client = data->master->archdata.iommu;
 
 	WARN_ON(!is_sysmmu_active(data));
 
@@ -348,6 +369,10 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 			break;
 	}
 
+	if (client)
+		spin_lock(&client->lock);
+	read_lock(&data->lock);
+
 	if (i == data->nsfrs) {
 		itype = SYSMMU_FAULT_UNKNOWN;
 	} else {
@@ -361,7 +386,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 	}
 
 	if (data->domain)
-		ret = report_iommu_fault(data->domain, data->dev,
+		ret = report_iommu_fault(data->domain, data->master,
 				addr, itype);
 
 	if (!ret && (itype != SYSMMU_FAULT_UNKNOWN))
@@ -378,177 +403,251 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 		sysmmu_unblock(data->sfrbases[i]);
 
 	read_unlock(&data->lock);
+	if (client)
+		spin_unlock(&client->lock);
 
 	return IRQ_HANDLED;
 }
 
-static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
+static void __sysmmu_disable_nocount(struct sysmmu_drvdata *data)
 {
-	unsigned long flags;
-	bool disabled = false;
 	int i;
 
-	write_lock_irqsave(&data->lock, flags);
+	clk_enable(data->clk_master);
+	for (i = 0; i < data->nsfrs; i++) {
+		__raw_writel(CTRL_DISABLE,
+				data->sfrbases[i] + REG_MMU_CTRL);
+		__raw_writel(0, data->sfrbases[i] + REG_MMU_CFG);
+	}
 
-	if (!set_sysmmu_inactive(data))
-		goto finish;
+	clk_disable(data->clk);
+	clk_disable(data->clk_master);
+}
 
-	for (i = 0; i < data->nsfrs; i++)
-		__raw_writel(CTRL_DISABLE, data->sfrbases[i] + REG_MMU_CTRL);
+static bool __sysmmu_disable(struct sysmmu_drvdata *data)
+{
+	bool disabled;
+	unsigned long flags;
 
-	if (data->clk)
-		clk_disable(data->clk);
+	write_lock_irqsave(&data->lock, flags);
 
-	disabled = true;
-	data->pgtable = 0;
-	data->domain = NULL;
-finish:
-	write_unlock_irqrestore(&data->lock, flags);
+	disabled = set_sysmmu_inactive(data);
+
+	if (disabled) {
+		data->pgtable = 0;
+		data->domain = NULL;
+
+		if (data->runtime_active)
+			__sysmmu_disable_nocount(data);
 
-	if (disabled)
 		dev_dbg(data->sysmmu, "Disabled\n");
-	else
-		dev_dbg(data->sysmmu, "%d times left to be disabled\n",
+	} else  {
+		dev_dbg(data->sysmmu, "%d times left to disable\n",
 					data->activations);
+	}
+
+	write_unlock_irqrestore(&data->lock, flags);
 
 	return disabled;
 }
 
-/* __exynos_sysmmu_enable: Enables System MMU
- *
- * returns -error if an error occurred and System MMU is not enabled,
- * 0 if the System MMU has been just enabled and 1 if System MMU was already
- * enabled before.
- */
-static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
+
+static void __sysmmu_init_config(struct sysmmu_drvdata *data, int idx)
+{
+	unsigned long cfg = CFG_LRU | CFG_QOS(15);
+	int maj, min = 0;
+
+	maj = __sysmmu_version(data, idx, &min);
+	if (maj == 3) {
+		if (min > 1) {
+			cfg |= CFG_FLPDCACHE;
+			cfg |= (min == 2) ? CFG_SYSSEL : CFG_ACGEN;
+		}
+	}
+
+	__raw_writel(cfg, data->sfrbases[idx] + REG_MMU_CFG);
+}
+
+static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
+{
+	int i;
+
+	clk_enable(data->clk_master);
+	clk_enable(data->clk);
+
+	for (i = 0; i < data->nsfrs; i++) {
+		__raw_writel(CTRL_BLOCK, data->sfrbases[i] + REG_MMU_CTRL);
+
+		__sysmmu_init_config(data, i);
+
+		__sysmmu_set_ptbase(data->sfrbases[i], data->pgtable);
+
+		__raw_writel(CTRL_ENABLE, data->sfrbases[i] + REG_MMU_CTRL);
+	}
+	clk_disable(data->clk_master);
+}
+
+static int __sysmmu_enable(struct sysmmu_drvdata *data,
 			unsigned long pgtable, struct iommu_domain *domain)
 {
-	int i, ret = 0;
+	int ret = 0;
 	unsigned long flags;
 
 	write_lock_irqsave(&data->lock, flags);
+	if (set_sysmmu_active(data)) {
+		data->pgtable = pgtable;
+		data->domain = domain;
 
-	if (!set_sysmmu_active(data)) {
-		if (WARN_ON(pgtable != data->pgtable)) {
-			ret = -EBUSY;
-			set_sysmmu_inactive(data);
-		} else {
-			ret = 1;
-		}
+		if (data->runtime_active)
+			__sysmmu_enable_nocount(data);
 
-		dev_dbg(data->sysmmu, "Already enabled\n");
-		goto finish;
+		dev_dbg(data->sysmmu, "Enabled\n");
+	} else {
+		ret = (pgtable == data->pgtable) ? 1 : -EBUSY;
+
+		dev_dbg(data->sysmmu, "already enabled\n");
 	}
 
-	if (data->clk)
-		clk_enable(data->clk);
+	if (WARN_ON(ret < 0))
+		set_sysmmu_inactive(data); /* decrement count */
 
-	data->pgtable = pgtable;
+	write_unlock_irqrestore(&data->lock, flags);
 
-	for (i = 0; i < data->nsfrs; i++) {
-		unsigned int min;
+	return ret;
+}
 
-		__sysmmu_set_ptbase(data->sfrbases[i], pgtable);
+/* __exynos_sysmmu_enable: Enables System MMU
+ *
+ * returns -error if an error occurred and System MMU is not enabled,
+ * 0 if the System MMU has been just enabled and 1 if System MMU was already
+ * enabled before.
+ */
+static int __exynos_sysmmu_enable(struct device *dev, unsigned long pgtable,
+				  struct iommu_domain *domain)
+{
+	int ret = 0;
+	unsigned long flags;
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int i;
 
-		if ((__sysmmu_version(data, i, &min) == 3) && (min > 1)) {
-			unsigned long cfg;
-			cfg = __raw_readl(data->sfrbases[i] + REG_MMU_CFG);
-			__raw_writel(cfg | CFG_FLPDCACHE,
-					data->sfrbases[i] + REG_MMU_CFG);
-		}
+	if (WARN_ON(!client))
+		return -ENODEV;
 
-		__raw_writel(CTRL_ENABLE, data->sfrbases[i] + REG_MMU_CTRL);
-	}
+	spin_lock_irqsave(&client->lock, flags);
 
-	data->domain = domain;
+	for (i = 0; i < client->num_sysmmu; i++) {
+		struct sysmmu_drvdata *data =
+				dev_get_drvdata(client->sysmmu[i]);
+		ret = __sysmmu_enable(data, pgtable, domain);
+		if (ret < 0) {
+			int j;
+			for (j = 0; j < i; j++)
+				__sysmmu_disable(data);
+			break;
+		} else {
+			data->master = dev;
+		}
+	}
 
-	dev_dbg(data->sysmmu, "Enabled\n");
-finish:
-	write_unlock_irqrestore(&data->lock, flags);
+	spin_unlock_irqrestore(&client->lock, flags);
 
 	return ret;
 }
 
 int exynos_sysmmu_enable(struct device *dev, unsigned long pgtable)
 {
-	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
 	int ret;
 
 	BUG_ON(!memblock_is_memory(pgtable));
 
-	ret = pm_runtime_get_sync(data->sysmmu);
-	if (ret < 0) {
-		dev_dbg(data->sysmmu, "Failed to enable\n");
-		return ret;
-	}
-
-	ret = __exynos_sysmmu_enable(data, pgtable, NULL);
-	if (WARN_ON(ret < 0)) {
-		pm_runtime_put(data->sysmmu);
-		dev_err(data->sysmmu,
-			"Already enabled with page table %#lx\n",
-			data->pgtable);
-	} else {
-		data->dev = dev;
-	}
+	ret = __exynos_sysmmu_enable(dev, pgtable, NULL);
 
 	return ret;
 }
 
 static bool exynos_sysmmu_disable(struct device *dev)
 {
-	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
-	bool disabled;
+	unsigned long flags;
+	bool disabled = true;
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int i;
 
-	disabled = __exynos_sysmmu_disable(data);
-	pm_runtime_put(data->sysmmu);
+	if (WARN_ON(!client))
+		return true;
+
+	spin_lock_irqsave(&client->lock, flags);
+
+	/* Every call to __sysmmu_disable() must return same result */
+	for (i = 0; i < client->num_sysmmu; i++) {
+		struct sysmmu_drvdata *data =
+				dev_get_drvdata(client->sysmmu[i]);
+		disabled = __sysmmu_disable(data);
+		if (disabled)
+			data->master = NULL;
+	}
+
+	spin_unlock_irqrestore(&client->lock, flags);
 
 	return disabled;
 }
 
 static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
 {
-	unsigned long flags;
-	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int i;
 
-	read_lock_irqsave(&data->lock, flags);
+	for (i = 0; i < client->num_sysmmu; i++) {
+		unsigned long flags;
+		struct sysmmu_drvdata *data;
 
-	if (is_sysmmu_active(data)) {
-		int i;
-		for (i = 0; i < data->nsfrs; i++) {
-			if (sysmmu_block(data->sfrbases[i])) {
+		data = dev_get_drvdata(client->sysmmu[i]);
+
+		read_lock_irqsave(&data->lock, flags);
+		if (is_sysmmu_active(data) && data->runtime_active) {
+			int i;
+			clk_enable(data->clk_master);
+			for (i = 0; i < data->nsfrs; i++)
 				__sysmmu_tlb_invalidate_entry(
 						data->sfrbases[i], iova);
-				sysmmu_unblock(data->sfrbases[i]);
-			}
+			clk_disable(data->clk_master);
+		} else {
+			dev_dbg(dev,
+				"disabled. Skipping TLB invalidation @ %#lx\n",
+				iova);
 		}
-	} else {
-		dev_dbg(data->sysmmu, "Disabled. Skipping invalidating TLB.\n");
+		read_unlock_irqrestore(&data->lock, flags);
 	}
-
-	read_unlock_irqrestore(&data->lock, flags);
 }
 
 void exynos_sysmmu_tlb_invalidate(struct device *dev)
 {
-	unsigned long flags;
-	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
-
-	read_lock_irqsave(&data->lock, flags);
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int i;
 
-	if (is_sysmmu_active(data)) {
-		int i;
-		for (i = 0; i < data->nsfrs; i++) {
-			if (sysmmu_block(data->sfrbases[i])) {
-				__sysmmu_tlb_invalidate(data->sfrbases[i]);
-				sysmmu_unblock(data->sfrbases[i]);
+	for (i = 0; i < client->num_sysmmu; i++) {
+		unsigned long flags;
+		struct sysmmu_drvdata *data;
+
+		data = dev_get_drvdata(client->sysmmu[i]);
+
+		read_lock_irqsave(&data->lock, flags);
+		if (is_sysmmu_active(data) &&
+				data->runtime_active) {
+			int i;
+			for (i = 0; i < data->nsfrs; i++) {
+				clk_enable(data->clk_master);
+				if (sysmmu_block(data->sfrbases[i])) {
+					__sysmmu_tlb_invalidate(
+							data->sfrbases[i]);
+					sysmmu_unblock(data->sfrbases[i]);
+				}
+				clk_disable(data->clk_master);
 			}
+		} else {
+			dev_dbg(dev, "disabled. Skipping TLB invalidation\n");
 		}
-	} else {
-		dev_dbg(data->sysmmu, "Disabled. Skipping invalidating TLB.\n");
+		read_unlock_irqrestore(&data->lock, flags);
 	}
-
-	read_unlock_irqrestore(&data->lock, flags);
 }
 
 static int __init exynos_sysmmu_probe(struct platform_device *pdev)
@@ -610,12 +709,32 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 	pm_runtime_enable(dev);
 
 	data->sysmmu = dev;
+
 	data->clk = devm_clk_get(dev, "sysmmu");
 	if (IS_ERR(data->clk)) {
 		dev_info(dev, "No gate clock found!\n");
 		data->clk = NULL;
 	}
 
+	ret = clk_prepare(data->clk);
+	if (ret) {
+		dev_err(dev, "Failed to prepare clk\n");
+		return ret;
+	}
+
+	data->clk_master = devm_clk_get(dev, "master");
+	if (IS_ERR(data->clk_master))
+		data->clk_master = NULL;
+
+	ret = clk_prepare(data->clk_master);
+	if (ret) {
+		clk_unprepare(data->clk);
+		dev_err(dev, "Failed to prepare master's clk\n");
+		return ret;
+	}
+
+	data->runtime_active = !pm_runtime_enabled(dev);
+
 	rwlock_init(&data->lock);
 	INIT_LIST_HEAD(&data->node);
 
@@ -625,6 +744,34 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 	return ret;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int sysmmu_suspend(struct device *dev)
+{
+	struct sysmmu_drvdata *data = dev_get_drvdata(dev);
+	unsigned long flags;
+	read_lock_irqsave(&data->lock, flags);
+	if (is_sysmmu_active(data) &&
+		(!pm_runtime_enabled(dev) || data->runtime_active))
+		__sysmmu_disable_nocount(data);
+	read_unlock_irqrestore(&data->lock, flags);
+	return 0;
+}
+
+static int sysmmu_resume(struct device *dev)
+{
+	struct sysmmu_drvdata *data = dev_get_drvdata(dev);
+	unsigned long flags;
+	read_lock_irqsave(&data->lock, flags);
+	if (is_sysmmu_active(data) &&
+		(!pm_runtime_enabled(dev) || data->runtime_active))
+		__sysmmu_enable_nocount(data);
+	read_unlock_irqrestore(&data->lock, flags);
+	return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(sysmmu_pm_ops, sysmmu_suspend, sysmmu_resume);
+
 #ifdef CONFIG_OF
 static struct of_device_id sysmmu_of_match[] __initconst = {
 	{ .compatible	= "samsung,exynos4210-sysmmu", },
@@ -637,6 +784,7 @@ static struct platform_driver exynos_sysmmu_driver __refdata = {
 	.driver	= {
 		.owner		= THIS_MODULE,
 		.name		= "exynos-sysmmu",
+		.pm		= &sysmmu_pm_ops,
 		.of_match_table	= of_match_ptr(sysmmu_of_match),
 	}
 };
@@ -689,7 +837,7 @@ err_pgtable:
 static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
 {
 	struct exynos_iommu_domain *priv = domain->priv;
-	struct sysmmu_drvdata *data;
+	struct exynos_iommu_client *client;
 	unsigned long flags;
 	int i;
 
@@ -697,11 +845,14 @@ static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
 
 	spin_lock_irqsave(&priv->lock, flags);
 
-	list_for_each_entry(data, &priv->clients, node) {
-		while (!exynos_sysmmu_disable(data->dev))
+	list_for_each_entry(client, &priv->clients, node) {
+		while (!exynos_sysmmu_disable(client->dev))
 			; /* until System MMU is actually disabled */
 	}
 
+	while (!list_empty(&priv->clients))
+		list_del_init(priv->clients.next);
+
 	spin_unlock_irqrestore(&priv->lock, flags);
 
 	for (i = 0; i < NUM_LV1ENTRIES; i++)
@@ -718,41 +869,26 @@ static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
 static int exynos_iommu_attach_device(struct iommu_domain *domain,
 				   struct device *dev)
 {
-	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
+	struct exynos_iommu_client *client = dev->archdata.iommu;
 	struct exynos_iommu_domain *priv = domain->priv;
 	unsigned long flags;
 	int ret;
 
-	ret = pm_runtime_get_sync(data->sysmmu);
-	if (ret < 0)
-		return ret;
-
-	ret = 0;
-
 	spin_lock_irqsave(&priv->lock, flags);
 
-	ret = __exynos_sysmmu_enable(data, __pa(priv->pgtable), domain);
-
-	if (ret == 0) {
-		/* 'data->node' must not be appeared in priv->clients */
-		BUG_ON(!list_empty(&data->node));
-		data->dev = dev;
-		list_add_tail(&data->node, &priv->clients);
-	}
+	ret = __exynos_sysmmu_enable(dev, __pa(priv->pgtable), domain);
+	if (ret == 0)
+		list_add_tail(&client->node, &priv->clients);
 
 	spin_unlock_irqrestore(&priv->lock, flags);
 
-	if (ret < 0) {
+	if (ret < 0)
 		dev_err(dev, "%s: Failed to attach IOMMU with pgtable %#lx\n",
 				__func__, __pa(priv->pgtable));
-		pm_runtime_put(data->sysmmu);
-	} else if (ret > 0) {
-		dev_dbg(dev, "%s: IOMMU with pgtable 0x%lx already attached\n",
-					__func__, __pa(priv->pgtable));
-	} else {
-		dev_dbg(dev, "%s: Attached new IOMMU with pgtable 0x%lx\n",
-					__func__, __pa(priv->pgtable));
-	}
+	else
+		dev_dbg(dev, "%s: Attached IOMMU with pgtable 0x%lx%s\n",
+					__func__, __pa(priv->pgtable),
+					(ret == 0) ? "" : ", again");
 
 	return ret;
 }
@@ -760,39 +896,27 @@ static int exynos_iommu_attach_device(struct iommu_domain *domain,
 static void exynos_iommu_detach_device(struct iommu_domain *domain,
 				    struct device *dev)
 {
-	struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
+	struct exynos_iommu_client *client = NULL;
 	struct exynos_iommu_domain *priv = domain->priv;
-	struct list_head *pos;
 	unsigned long flags;
-	bool found = false;
 
 	spin_lock_irqsave(&priv->lock, flags);
 
-	list_for_each(pos, &priv->clients) {
-		if (list_entry(pos, struct sysmmu_drvdata, node) == data) {
-			found = true;
+	list_for_each_entry(client, &priv->clients, node) {
+		if (client == dev->archdata.iommu) {
+			if (exynos_sysmmu_disable(dev))
+				list_del_init(&client->node);
 			break;
 		}
 	}
 
-	if (!found)
-		goto finish;
+	spin_unlock_irqrestore(&priv->lock, flags);
 
-	if (__exynos_sysmmu_disable(data)) {
+	if (client == dev->archdata.iommu)
 		dev_dbg(dev, "%s: Detached IOMMU with pgtable %#lx\n",
 					__func__, __pa(priv->pgtable));
-		list_del_init(&data->node);
-
-	} else {
-		dev_dbg(dev, "%s: Detaching IOMMU with pgtable %#lx delayed",
-					__func__, __pa(priv->pgtable));
-	}
-
-finish:
-	spin_unlock_irqrestore(&priv->lock, flags);
-
-	if (found)
-		pm_runtime_put(data->sysmmu);
+	else
+		dev_dbg(dev, "%s: No IOMMU is attached\n", __func__);
 }
 
 static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long iova,
@@ -914,7 +1038,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
 					       unsigned long iova, size_t size)
 {
 	struct exynos_iommu_domain *priv = domain->priv;
-	struct sysmmu_drvdata *data;
+	struct exynos_iommu_client *client;
 	unsigned long flags;
 	unsigned long *ent;
 	size_t err_pgsize;
@@ -975,8 +1099,8 @@ done:
 	spin_unlock_irqrestore(&priv->pgtablelock, flags);
 
 	spin_lock_irqsave(&priv->lock, flags);
-	list_for_each_entry(data, &priv->clients, node)
-		sysmmu_tlb_invalidate_entry(data->dev, iova);
+	list_for_each_entry(client, &priv->clients, node)
+		sysmmu_tlb_invalidate_entry(client->dev, iova);
 	spin_unlock_irqrestore(&priv->lock, flags);
 
 	return size;
@@ -1055,3 +1179,275 @@ static int __init exynos_iommu_init(void)
 	return ret;
 }
 subsys_initcall(exynos_iommu_init);
+
+#ifdef CONFIG_PM_SLEEP
+static int sysmmu_pm_genpd_suspend(struct device *dev)
+{
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int ret = 0;
+	int i;
+
+	for (i = 0; i < client->num_sysmmu; i++) {
+		ret = pm_generic_suspend(client->sysmmu[i]);
+		if (ret)
+			break;
+	}
+
+	if (!ret)
+		ret = pm_generic_suspend(dev);
+
+	if (ret) {
+		int j;
+
+		for (j = 0; j < i; j++)
+			pm_generic_resume(client->sysmmu[j]);
+	}
+
+	return ret;
+}
+
+static int sysmmu_pm_genpd_resume(struct device *dev)
+{
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int ret = 0;
+	int i;
+
+	for (i = 0; i < client->num_sysmmu; i++) {
+		ret = pm_generic_resume(client->sysmmu[i]);
+		if (ret)
+			break;
+	}
+
+	if (!ret)
+		ret = pm_generic_resume(dev);
+
+	if (ret) {
+		int j;
+
+		for (j = 0; j < i; j++)
+			pm_generic_suspend(client->sysmmu[j]);
+	}
+
+	return ret;
+}
+#endif
+
+#ifdef CONFIG_PM_RUNTIME
+static void sysmmu_restore_state(struct device *sysmmu)
+{
+	struct sysmmu_drvdata *data = dev_get_drvdata(sysmmu);
+	unsigned long flags;
+
+	spin_lock_irqsave(&data->lock, flags);
+	data->runtime_active = true;
+	if (is_sysmmu_active(data))
+		__sysmmu_enable_nocount(data);
+	spin_unlock_irqrestore(&data->lock, flags);
+}
+
+static void sysmmu_save_state(struct device *sysmmu)
+{
+	struct sysmmu_drvdata *data = dev_get_drvdata(sysmmu);
+	unsigned long flags;
+
+	spin_lock_irqsave(&data->lock, flags);
+	if (is_sysmmu_active(data))
+		__sysmmu_disable_nocount(data);
+	data->runtime_active = false;
+	spin_unlock_irqrestore(&data->lock, flags);
+}
+
+static int sysmmu_pm_genpd_save_state(struct device *dev)
+{
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int (*cb)(struct device *__dev);
+	int i;
+
+	if (dev->type && dev->type->pm)
+		cb = dev->type->pm->runtime_suspend;
+	else if (dev->class && dev->class->pm)
+		cb = dev->class->pm->runtime_suspend;
+	else if (dev->bus && dev->bus->pm)
+		cb = dev->bus->pm->runtime_suspend;
+	else
+		cb = NULL;
+
+	if (!cb && dev->driver && dev->driver->pm)
+		cb = dev->driver->pm->runtime_suspend;
+
+	if (cb) {
+		int ret;
+
+		ret = cb(dev);
+		if (ret)
+			return ret;
+	}
+
+	for (i = 0; i < client->num_sysmmu; i++)
+		sysmmu_save_state(client->sysmmu[i]);
+
+	return 0;
+}
+
+static int sysmmu_pm_genpd_restore_state(struct device *dev)
+{
+	struct exynos_iommu_client *client = dev->archdata.iommu;
+	int (*cb)(struct device *__dev);
+	int i;
+
+	if (dev->type && dev->type->pm)
+		cb = dev->type->pm->runtime_resume;
+	else if (dev->class && dev->class->pm)
+		cb = dev->class->pm->runtime_resume;
+	else if (dev->bus && dev->bus->pm)
+		cb = dev->bus->pm->runtime_resume;
+	else
+		cb = NULL;
+
+	if (!cb && dev->driver && dev->driver->pm)
+		cb = dev->driver->pm->runtime_resume;
+
+	for (i = 0; i < client->num_sysmmu; i++)
+		sysmmu_restore_state(client->sysmmu[i]);
+
+	if (cb) {
+		int ret;
+		ret = cb(dev);
+		if (ret) {
+			for (i = 0; i < client->num_sysmmu; i++)
+				sysmmu_save_state(client->sysmmu[i]);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+#endif
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS
+struct gpd_dev_ops sysmmu_devpm_ops = {
+#ifdef CONFIG_PM_RUNTIME
+	.save_state = &sysmmu_pm_genpd_save_state,
+	.restore_state = &sysmmu_pm_genpd_restore_state,
+#endif
+#ifdef CONFIG_PM_SLEEP
+	.suspend = &sysmmu_pm_genpd_suspend,
+	.resume = &sysmmu_pm_genpd_resume,
+#endif
+};
+#endif /* CONFIG_PM_GENERIC_DOMAINS */
+
+static int sysmmu_hook_driver_register(struct notifier_block *nb,
+					unsigned long val,
+					void *p)
+{
+	struct device *dev = p;
+
+	switch (val) {
+	case BUS_NOTIFY_BIND_DRIVER:
+	{
+		int i = 0;
+		int size = 0;
+		const __be32 *phandle;
+		struct exynos_iommu_client *client;
+
+		phandle = of_get_property(dev->of_node, "iommu", &size);
+		if (!phandle)
+			break;
+
+		size = size / sizeof(*phandle); /* number of elements */
+
+		client = devm_kzalloc(dev, sizeof(*client) * size, GFP_KERNEL);
+		if (!client) {
+			dev_err(dev, "No Memory for exynos_iommu_client\n");
+			return -ENOMEM;
+		}
+
+		client->num_sysmmu = size;
+		client->dev = dev;
+		INIT_LIST_HEAD(&client->node);
+		spin_lock_init(&client->lock);
+
+		for (i = 0; i < size; i++) {
+			struct device_node *np;
+			struct platform_device *sysmmu;
+
+			/* this always success: see above of_find_property() */
+			np = of_parse_phandle(dev->of_node, "iommu", i);
+
+			sysmmu = of_find_device_by_node(np);
+			if (!sysmmu) {
+				dev_err(dev,
+					"sysmmu node '%s' is not found\n",
+					np->name);
+				break;
+			}
+
+			client->sysmmu[i] = &sysmmu->dev;
+		}
+
+		if (i < size) {
+			while (--i >= 0)
+				of_node_put(client->sysmmu[i]->of_node);
+			devm_kfree(dev, client);
+			return -ENODEV;
+		}
+
+		i = pm_genpd_add_callbacks(dev, &sysmmu_devpm_ops, NULL);
+		if (i && (i != -ENOSYS)) {
+			dev_err(dev,
+				"Failed to register 'dev_pm_ops' for iommu\n");
+			devm_kfree(dev, client);
+			return i;
+		}
+
+		dev->archdata.iommu = client;
+		break;
+	}
+	case BUS_NOTIFY_BOUND_DRIVER:
+	{
+		struct exynos_iommu_client *client = dev->archdata.iommu;
+		if (dev->archdata.iommu &&
+				(!pm_runtime_enabled(dev) ||
+					 IS_ERR(dev_to_genpd(dev)))) {
+			int i;
+			for (i = 0; i < client->num_sysmmu; i++) {
+				struct sysmmu_drvdata *data;
+				pm_runtime_disable(client->sysmmu[i]);
+				data = dev_get_drvdata(client->sysmmu[i]);
+				if (!data)
+					continue;
+				data->runtime_active =
+					!pm_runtime_enabled(data->sysmmu);
+				if (data->runtime_active &&
+						is_sysmmu_active(data))
+					__sysmmu_enable_nocount(data);
+			}
+		}
+		break;
+	}
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+	{
+		if (dev->archdata.iommu) {
+			__pm_genpd_remove_callbacks(dev, false);
+
+			devm_kfree(dev, dev->archdata.iommu);
+
+			dev->archdata.iommu = NULL;
+		}
+		break;
+	}
+	} /* switch (val) */
+
+	return 0;
+}
+
+static struct notifier_block sysmmu_notifier = {
+	.notifier_call = &sysmmu_hook_driver_register,
+};
+
+static int __init exynos_iommu_prepare(void)
+{
+	return bus_register_notifier(&platform_bus_type, &sysmmu_notifier);
+}
+arch_initcall(exynos_iommu_prepare);
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul 26 07:30:42 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 26 Jul 2013 20:30:42 +0900
Subject: [PATCH v8 11/12] iommu/exynos: change rwlock to spinlock
Message-ID: <004101ce89f3$90200980$b0601c80$@samsung.com>

Since acquiring read_lock is not more frequent than write_lock, it is
not beneficial to use rwlock, this commit changes rwlock to spinlock.

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |   36 ++++++++++++++++++------------------
 1 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index c62c244..51e5b35 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -187,7 +187,7 @@ struct sysmmu_drvdata {
 	struct clk *clk;
 	struct clk *clk_master;
 	int activations;
-	rwlock_t lock;
+	spinlock_t lock;
 	struct iommu_domain *domain;
 	bool runtime_active;
 	unsigned long pgtable;
@@ -287,7 +287,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
 	BUG_ON((base0 + size0) <= base0);
 	BUG_ON((size1 > 0) && ((base1 + size1) <= base1));
 
-	read_lock_irqsave(&data->lock, flags);
+	spin_lock_irqsave(&data->lock, flags);
 	if (!is_sysmmu_active(data))
 		goto finish;
 
@@ -319,7 +319,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
 	}
 	clk_disable(data->clk_master);
 finish:
-	read_unlock_irqrestore(&data->lock, flags);
+	spin_unlock_irqrestore(&data->lock, flags);
 }
 
 static void show_fault_information(const char *name,
@@ -371,7 +371,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 
 	if (client)
 		spin_lock(&client->lock);
-	read_lock(&data->lock);
+	spin_lock(&data->lock);
 
 	if (i == data->nsfrs) {
 		itype = SYSMMU_FAULT_UNKNOWN;
@@ -402,7 +402,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 	if (itype != SYSMMU_FAULT_UNKNOWN)
 		sysmmu_unblock(data->sfrbases[i]);
 
-	read_unlock(&data->lock);
+	spin_unlock(&data->lock);
 	if (client)
 		spin_unlock(&client->lock);
 
@@ -429,7 +429,7 @@ static bool __sysmmu_disable(struct sysmmu_drvdata *data)
 	bool disabled;
 	unsigned long flags;
 
-	write_lock_irqsave(&data->lock, flags);
+	spin_lock_irqsave(&data->lock, flags);
 
 	disabled = set_sysmmu_inactive(data);
 
@@ -446,7 +446,7 @@ static bool __sysmmu_disable(struct sysmmu_drvdata *data)
 					data->activations);
 	}
 
-	write_unlock_irqrestore(&data->lock, flags);
+	spin_unlock_irqrestore(&data->lock, flags);
 
 	return disabled;
 }
@@ -493,7 +493,7 @@ static int __sysmmu_enable(struct sysmmu_drvdata *data,
 	int ret = 0;
 	unsigned long flags;
 
-	write_lock_irqsave(&data->lock, flags);
+	spin_lock_irqsave(&data->lock, flags);
 	if (set_sysmmu_active(data)) {
 		data->pgtable = pgtable;
 		data->domain = domain;
@@ -511,7 +511,7 @@ static int __sysmmu_enable(struct sysmmu_drvdata *data,
 	if (WARN_ON(ret < 0))
 		set_sysmmu_inactive(data); /* decrement count */
 
-	write_unlock_irqrestore(&data->lock, flags);
+	spin_unlock_irqrestore(&data->lock, flags);
 
 	return ret;
 }
@@ -602,7 +602,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
 
 		data = dev_get_drvdata(client->sysmmu[i]);
 
-		read_lock_irqsave(&data->lock, flags);
+		spin_lock_irqsave(&data->lock, flags);
 		if (is_sysmmu_active(data) && data->runtime_active) {
 			int i;
 			clk_enable(data->clk_master);
@@ -615,7 +615,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
 				"disabled. Skipping TLB invalidation @ %#lx\n",
 				iova);
 		}
-		read_unlock_irqrestore(&data->lock, flags);
+		spin_unlock_irqrestore(&data->lock, flags);
 	}
 }
 
@@ -630,7 +630,7 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
 
 		data = dev_get_drvdata(client->sysmmu[i]);
 
-		read_lock_irqsave(&data->lock, flags);
+		spin_lock_irqsave(&data->lock, flags);
 		if (is_sysmmu_active(data) &&
 				data->runtime_active) {
 			int i;
@@ -646,7 +646,7 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
 		} else {
 			dev_dbg(dev, "disabled. Skipping TLB invalidation\n");
 		}
-		read_unlock_irqrestore(&data->lock, flags);
+		spin_unlock_irqrestore(&data->lock, flags);
 	}
 }
 
@@ -735,7 +735,7 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 
 	data->runtime_active = !pm_runtime_enabled(dev);
 
-	rwlock_init(&data->lock);
+	spin_lock_init(&data->lock);
 	INIT_LIST_HEAD(&data->node);
 
 	platform_set_drvdata(pdev, data);
@@ -749,11 +749,11 @@ static int sysmmu_suspend(struct device *dev)
 {
 	struct sysmmu_drvdata *data = dev_get_drvdata(dev);
 	unsigned long flags;
-	read_lock_irqsave(&data->lock, flags);
+	spin_lock_irqsave(&data->lock, flags);
 	if (is_sysmmu_active(data) &&
 		(!pm_runtime_enabled(dev) || data->runtime_active))
 		__sysmmu_disable_nocount(data);
-	read_unlock_irqrestore(&data->lock, flags);
+	spin_unlock_irqrestore(&data->lock, flags);
 	return 0;
 }
 
@@ -761,11 +761,11 @@ static int sysmmu_resume(struct device *dev)
 {
 	struct sysmmu_drvdata *data = dev_get_drvdata(dev);
 	unsigned long flags;
-	read_lock_irqsave(&data->lock, flags);
+	spin_lock_irqsave(&data->lock, flags);
 	if (is_sysmmu_active(data) &&
 		(!pm_runtime_enabled(dev) || data->runtime_active))
 		__sysmmu_enable_nocount(data);
-	read_unlock_irqrestore(&data->lock, flags);
+	spin_unlock_irqrestore(&data->lock, flags);
 	return 0;
 }
 #endif
-- 
1.7.2.5




From pullip.cho at samsung.com  Fri Jul 26 07:31:01 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Fri, 26 Jul 2013 20:31:01 +0900
Subject: [PATCH v8 12/12] iommu/exynos: return 0 if iommu_attach_device()
 successes
Message-ID: <004201ce89f3$9b849a20$d28dce60$@samsung.com>

iommu_attach_device() against exynos-iommu positive integer on success
if the caller calls iommu_attach_device() with the same iommu_domain
multiple times without call to iommu_detach_device() to inform the
caller how many calls to iommu_detach_device() to really detach iommu.

However the convention of the return value of success of common API is
zero, this patch makes iommu_attach_device() call against exynos-iommu
always return zero if the given device is successfully attached to
the given iommu_domain even though it is already attached to the same
iommu_domain.

Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
---
 drivers/iommu/exynos-iommu.c |   13 +++++++------
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 51e5b35..6eed6d6 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -882,15 +882,16 @@ static int exynos_iommu_attach_device(struct iommu_domain *domain,
 
 	spin_unlock_irqrestore(&priv->lock, flags);
 
-	if (ret < 0)
+	if (ret < 0) {
 		dev_err(dev, "%s: Failed to attach IOMMU with pgtable %#lx\n",
 				__func__, __pa(priv->pgtable));
-	else
-		dev_dbg(dev, "%s: Attached IOMMU with pgtable 0x%lx%s\n",
-					__func__, __pa(priv->pgtable),
-					(ret == 0) ? "" : ", again");
+		return ret;
+	}
 
-	return ret;
+	dev_dbg(dev, "%s: Attached IOMMU with pgtable 0x%lx%s\n",
+		__func__, __pa(priv->pgtable), (ret == 0) ? "" : ", again");
+
+	return 0;
 }
 
 static void exynos_iommu_detach_device(struct iommu_domain *domain,
-- 
1.7.2.5




From lorenzo.pieralisi at arm.com  Fri Jul 26 07:31:10 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 26 Jul 2013 12:31:10 +0100
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value to
 index into save array
In-Reply-To: <alpine.LFD.2.03.1307251203550.15022@syhkavp.arg>
References: <alpine.LFD.2.03.1307251203550.15022@syhkavp.arg>
Message-ID: <20130726113110.GB28084@e102568-lin.cambridge.arm.com>

On Thu, Jul 25, 2013 at 05:06:51PM +0100, Nicolas Pitre wrote:
> On Thu, 25 Jul 2013, Dave Martin wrote:
> 
> > On Wed, Jul 24, 2013 at 02:55:00PM -0400, Nicolas Pitre wrote:
> > > On Wed, 24 Jul 2013, Dave Martin wrote:
> > > 
> > > > But this patch commits us to requiring that on the suspend path 
> > > > specifically -- I think that ought to be mentioned somewhere. A 
> > > > comment in the preamble for __cpu_suspend would be enough, I think.
> > > 
> > > What comment would you suggest?  I want to make sure the possible 
> > > confusion you see is properly addressed.
> > 
> > I think we just need to state that the value of
> > cpu_logical_map(smp_processor_id()) must be the MPIDR of the physical
> > CPU the suspending logical CPU will resume on.  Consequently, if doing a
> > migration, cpu_logical_map() must be updated appropriately somewhere
> > between cpu_pm_enter() and cpu_suspend().
> 
> Excellent.  I've amended the patch with this:
> 
> diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
> index 2835d35234..caf938db62 100644
> --- a/arch/arm/kernel/suspend.c
> +++ b/arch/arm/kernel/suspend.c
> @@ -17,6 +17,11 @@ extern void cpu_resume_mmu(void);
>  /*
>   * Hide the first two arguments to __cpu_suspend - these are an implementation
>   * detail which platform code shouldn't have to know about.
> + *
> + * On SMP systems, the value of cpu_logical_map(smp_processor_id()) must be
> + * the MPIDR of the physical CPU the suspending logical CPU will resume on.
> + * Consequently, if doing a physical CPU migration, cpu_logical_map() must be
> + * updated appropriately somewhere between cpu_pm_enter() and cpu_suspend().
>   */
>  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
>  {
> 
> I've put it against cpu_suspend() rather than __cpu_suspend(() as this 
> is what users should care about.
> 
> ACK?

We need this patch to allow IKS to store a cpu context at a specific
index, let's be honest. It is a moot point and I am not very happy
about changing this code for a very specific usage, but the way code is
implemented makes the change acceptable. I really do not think we should
write guidelines on how cpu_suspend users have to change cpu_logical_map
though, that's not needed apart from IKS and that should be limited to IKS
code only.

Again, that's just my opinion, but cpu_suspend API must be kept as it is
and we should not encourage people to use it in creative ways.

Lorenzo



From jason at lakedaemon.net  Fri Jul 26 07:38:09 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 26 Jul 2013 07:38:09 -0400
Subject: DT bindings as ABI [was: Do we have people interested in
 device tree janitoring / cleanup?]
In-Reply-To: <CAKON4OwwOnP9kbN0JqR5L+F1svTucAQvz0RDwqU+Gy9UAFwHog@mail.gmail.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
 <20130725193135.GT23879@titan.lakedaemon.net>
 <20130725231848.GJ24642@n2100.arm.linux.org.uk>
 <CAKON4OwwOnP9kbN0JqR5L+F1svTucAQvz0RDwqU+Gy9UAFwHog@mail.gmail.com>
Message-ID: <20130726113809.GB29916@titan.lakedaemon.net>

On Thu, Jul 25, 2013 at 08:27:15PM -0400, jonsmirl at gmail.com wrote:
> On Thu, Jul 25, 2013 at 7:18 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Thu, Jul 25, 2013 at 03:31:35PM -0400, Jason Cooper wrote:
> >> On Thu, Jul 25, 2013 at 02:11:31PM -0500, Rob Herring wrote:
> >> > On Thu, Jul 25, 2013 at 11:09 AM, Olof Johansson <olof at lixom.net> wrote:
> >>
> >> > > One problem that needs to be solved is obviously how a binding
> >> > > graduates from tentative to locked. This work isn't going to be very
> >> > > interesting to most people, I suspect. Think standards committee type
> >> > > work.
> >> >
> >> > I think a time based stabilization period would be better than a
> >> > separate directory to apply bindings too. Or time plus periodic review
> >> > perhaps.
> >>
> >> The only problem with a time-based versus separate directory is how do
> >> users who've downloaded the tree determine which bindings are stable?
> >> If they pull a tarball, or receive an SDK, there is most likely no git
> >> history attached.
> >>
> >> I think the idea of a 'tentative' directory (or 'locked') is churnish,
> >> but necessary.  If I DL'd a tarball and had to type 'tentative' to get
> >> to the binding doc I wanted, that would be a pretty clear clue to be
> >> delicate about how I trust/use/plan with that binding.
> >
> > It's actually extremely simple.  If the bindings are in development,
> > they must not appear in a -final released kernel.  Anything that appears
> > in a -final kernel becomes part of the ABI at that point.
> >
> > That obviously does not mean you remove them in the last -rc and put
> > them back during the merge window!
> >
> > That's how we handle every other ABI thing in the kernel tree, why should
> > DT files be any different?  (I've added Linus and Grant to this discussion.)
> >
> > As I've already stated, it is intended to eventually remove the DT files
> > from the kernel tree and have them as a separately maintained project,
> > which means they will be independent of the kernel version.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> Having a schema system for the device trees is closely related to this
> discussion.  In this case the schema would probably be equal to the
> stable set of nodes. This has been discussed before on the device tree
> mailing list. The dtc compiler would take this schema and validate the
> trees it compiles against it issuing warnings for 'non-standard'
> usage. Over time the schema would be updated to allow these usages
> when everyone agrees to it. Note that there would be a single schema
> describing all possible legal Linux device trees.

s/Linux// ?

> The scheme is also quite useful for new tree developers since it will
> show them the universe of device tree attributes that have already
> been standardized. By using comments, you could probably turn the
> device tree documentation into the schema source files.

One more note on schema, since DT is a description of hardware, it would
be useful to have two comments, a url to the datasheet, and a canonical
name of the datasheet suitable for $searchengine.  Where available, of
course.

thx,

Jason.


From broonie at kernel.org  Fri Jul 26 07:39:34 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Jul 2013 12:39:34 +0100
Subject: XCLKOUT in exynos5250 clock driver
In-Reply-To: <51F247B6.9010902@linaro.org>
References: <20130725145158.GI9858@sirena.org.uk> <51F247B6.9010902@linaro.org>
Message-ID: <20130726113934.GD9858@sirena.org.uk>

On Fri, Jul 26, 2013 at 03:26:06PM +0530, Tushar Behera wrote:

> Information as per Exynos5250 user manual:
> "XCLKOUT is an output pin for debugging clocks. Exynos5250 has a CLKOUT
> logic which can select one of the clocks (within its clock domains) and
> output that through XCLKOUT pin."

Yeah, I know what XCLKOUT is but to implement this in the driver and DT
I'd need to know about the register or registers that are used to
configure the mux.

> Not sure if XCLKOUT on Arndale schematics means the same.

I'd be astonished if it meant anything else, it's fairly clearly
labelled as that on the schematics and this is a *very* common pattern
in system designs using Samsung SoCs.
-------------- 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/20130726/4242f00d/attachment.sig>

From jason at lakedaemon.net  Fri Jul 26 07:49:40 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 26 Jul 2013 07:49:40 -0400
Subject: [PATCHv5 08/11] ARM: pci: add ->add_bus() and ->remove_bus()
 hooks to hw_pci
In-Reply-To: <20130726101305.22a5c892@skate>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130725165659.GB27802@dhcp-172-17-186-34.nvidia.com>
 <20130726101305.22a5c892@skate>
Message-ID: <20130726114940.GD29916@titan.lakedaemon.net>

On Fri, Jul 26, 2013 at 10:13:05AM +0200, Thomas Petazzoni wrote:
> Dear Thierry Reding,
> 
> On Thu, 25 Jul 2013 09:57:00 -0700, Thierry Reding wrote:
> > On Mon, Jul 15, 2013 at 01:52:44PM +0200, Thomas Petazzoni wrote:
> > > Some PCI drivers may need to adjust the pci_bus structure after it has
> > > been allocated by the Linux PCI core. The PCI core allows
> > > architectures to implement the pcibios_add_bus() and
> > > pcibios_remove_bus() for this purpose. This commit therefore extends
> > > the hw_pci and pci_sys_data structures of the ARM PCI core to allow
> > > PCI drivers to register ->add_bus() and ->remove_bus() in hw_pci,
> > > which will get called when a bus is added or removed from the system.
> > > 
> > > This will be used for example by the Marvell PCIe driver to connect a
> > > particular PCI bus with its corresponding MSI chip to handle Message
> > > Signaled Interrupts.
> > > 
> > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > > Reviewed-by: Thierry Reding <thierry.reding at gmail.com>
> > > ---
> > >  arch/arm/include/asm/mach/pci.h |  4 ++++
> > >  arch/arm/kernel/bios32.c        | 16 ++++++++++++++++
> > >  2 files changed, 20 insertions(+)
> > 
> > Hi Russell,
> > 
> > Can we have your Acked-by on this patch so that it can be moved to a
> > stable branch along with some of the other patches in this branch that
> > both Marvell and Tegra PCIe drivers need?
> 
> I've pinged Russell a few times about this patch already, but haven't
> received feedback from him. Do you think I can just go ahead and submit
> the patch to Russell's patch system, after fixing the minor nits you
> mentioned?

When you do that, please ask Russell to place it in a publicly
accessible, stable topic branch for us to base off of.

thx,

Jason.


From jason at lakedaemon.net  Fri Jul 26 08:01:53 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 26 Jul 2013 08:01:53 -0400
Subject: Location for a kind of GPIO bus driver
In-Reply-To: <20130725221615.GA30881@kroah.com>
References: <20130723151834.GJ9916@kw.sim.vm.gnt>
 <CACRpkdZWQQUCeHvgPPLmxL3O1sw55pc_KbzbnqTSFJx+0_QanQ@mail.gmail.com>
 <20130725221615.GA30881@kroah.com>
Message-ID: <20130726120153.GE29916@titan.lakedaemon.net>

On Thu, Jul 25, 2013 at 03:16:15PM -0700, Greg KH wrote:
> On Thu, Jul 25, 2013 at 11:46:42PM +0200, Linus Walleij wrote:
> > On Tue, Jul 23, 2013 at 5:18 PM, Simon Guinot <simon.guinot at sequanux.org> wrote:
> > 
> > > (...)  I am
> > > thinking about moving the GPIO extension bus support into a separate
> > > driver. The problem is that I can't find a proper location for a such
> > > driver. AFAIK, it doesn't fit with anything existing supported by Linux.
> > > Maybe I should consider drivers/bus ? Or even drivers/misc ?
> > 
> > This is a question to Greg, the device core maintainer.
> > AFAICT they go into drivers/base/foo-bus.c
> 
> No, specific bus code does not go in drivers/base/ it goes where the
> rest of the subsystem lives.

We were thinking drivers/bus since it is addressable and has multiple
devices hanging off of it (leds, power management).

However, since each device is essentially an external gpio, drivers/gpio
might be more appropriate.  It's not a gpio expander, more of an
enhanced gpio controller (led 1, brightness 7)

> > In this case I would first consider using MFD though,
> > please make a case for why this is not simply a multi
> > function device with a few cells (== platform devices).
> 
> I agree with this as well.

To quote Simon from a different response:
> I will definitively have a closer look at mfd. But as I understand,
> mfd is more oriented platform device and resources. Here, the device
> don't expose some memory regions but rather methods to configure a
> CPLD through GPIOs. I am not sure how it can work with the mfd
> framework.

thx,

Jason.


From monstr at monstr.eu  Fri Jul 26 08:09:58 2013
From: monstr at monstr.eu (Michal Simek)
Date: Fri, 26 Jul 2013 14:09:58 +0200
Subject: Zynq clk fixes
Message-ID: <51F26716.6030701@monstr.eu>

Hi Mike, [cc: Arnd and Olof]

Soren has found two bug fixes in zynq clk code.
Can you please add these two patches to your tree?
Will be great if you can add them to v3.11.

Arnd, Olof: I expect that all these clock changes should go through Mike.
If I am wrong please let me know.

Thanks,
Michal


The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.xilinx.com/linux-xlnx.git tags/zynq-clk-fixes-for-3.11

for you to fetch changes up to 97d58aef394831f6f0583653de29e03886a0e09e:

  clk/zynq/clkc: Add CLK_SET_RATE_PARENT flag to ethernet muxes (2013-07-17 08:36:53 +0200)

----------------------------------------------------------------
arm: Xilinx Zynq clock fixes for v3.11

- Fix watchdog clock registration
- Fix gem clock propagation

----------------------------------------------------------------
Soren Brinkmann (2):
      clk/zynq/clkc: Add dedicated spinlock for the SWDT
      clk/zynq/clkc: Add CLK_SET_RATE_PARENT flag to ethernet muxes

 drivers/clk/zynq/clkc.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/f30192d3/attachment.sig>

From jason at lakedaemon.net  Fri Jul 26 08:14:38 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 26 Jul 2013 08:14:38 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130725215315.GV7729@decadent.org.uk>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
 <20130725193135.GT23879@titan.lakedaemon.net>
 <CAL_Jsq+vWbTb8wNEDCR2c_M6sBnKW6e5HGk48QzmXSujQUdddA@mail.gmail.com>
 <20130725203228.GX23879@titan.lakedaemon.net>
 <20130725215315.GV7729@decadent.org.uk>
Message-ID: <20130726121438.GF29916@titan.lakedaemon.net>

On Thu, Jul 25, 2013 at 10:53:15PM +0100, Ben Hutchings wrote:
> On Thu, Jul 25, 2013 at 04:32:28PM -0400, Jason Cooper wrote:
> [...]
> > One of the things I've been trying to square up in my head is how to
> > retain the history of the binding when moving to the new tree.  My
> > current idea was to clone the kernel tree, add one patch deleting
> > everything but the bindings and dts files, and one more patch moving
> > things where we want them (arch/{powerpc,arm}/boot/dts -> dts).
> > 
> > Then, as needed, we could merge a kernel version tag and delete
> > everything we don't need (code) in the merge commit.
> > 
> > The downside of this is it would be messy, the upside is that we could
> > closely track the kernel tree (until the bindings and dts are moved
> > out), and retain the history of the bindings and dts files.
> [...]
> 
> It's *extremely* messy, but 'git filter-branch' might help to make a
> clean tracking branch preserving history of just DT files.  David
> Woodhouse did something like that for the linux-firmware repo
> initially.

ok, but once that is setup, asking patch submitters to keep binding doc
and dts file changes in separate patches from code changes would allow
us to put those patches in a separate branch, mergable into both trees.

thx,

Jason.


From michal.simek at xilinx.com  Fri Jul 26 08:15:06 2013
From: michal.simek at xilinx.com (Michal Simek)
Date: Fri, 26 Jul 2013 14:15:06 +0200
Subject: [PATCH 0/3] arm: zynq: SLCR clean up
In-Reply-To: <1374081015-31431-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1374081015-31431-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <529db7d7-70f5-4dae-8482-cc982c3319cb@VA3EHSMHS026.ehs.local>

On 07/17/2013 07:10 PM, Soren Brinkmann wrote:
> These are just a few patches cleaning up the driver - well at least I
> find it cleaner this way.
> 3/3 though adds correct read-modify-write for some register accesses.
> The current implementation doesn't seem to do any harm, but this looks
> better, IMHO.
> 
> 	S?ren
> 
> Soren Brinkmann (3):
>   arm: zynq: slcr: Remove redundant header #includes
>   arm: zynq: slcr: Clean up #defines
>   arm: zynq: slcr: Use read-modify-write for register writes
> 
>  arch/arm/mach-zynq/slcr.c | 45 +++++++++++++++++----------------------------
>  1 file changed, 17 insertions(+), 28 deletions(-)

Applied to zynq/cleanup branch.

Thanks,
Michal




From sylvester.nawrocki at gmail.com  Fri Jul 26 08:19:39 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Fri, 26 Jul 2013 14:19:39 +0200
Subject: XCLKOUT in exynos5250 clock driver
In-Reply-To: <51F247B6.9010902@linaro.org>
References: <20130725145158.GI9858@sirena.org.uk> <51F247B6.9010902@linaro.org>
Message-ID: <51F2695B.8020109@gmail.com>

On 07/26/2013 11:56 AM, Tushar Behera wrote:
> On 07/25/2013 08:21 PM, Mark Brown wrote:
>> I appear to be missing something in the clock driver for the exynos5250.
>> I'm looking at the Arndale schematic and I see that the audio master
>> clock is connected to XCLKOUT on the SoC.  However I can't see any
>> reference to XCLKOUT or anything similar in the clock driver or any of
>> the DTS files - where is this clock exposed by the clock driver?

This is something that's not yet supported in the mainline kernels I'm
afraid.

>> Unfortunately I haven't been able to get access to the datasheet for the
>> part so I can't check this myself.
>>
>
> Information as per Exynos5250 user manual:
> "XCLKOUT is an output pin for debugging clocks. Exynos5250 has a CLKOUT
> logic which can select one of the clocks (within its clock domains) and
> output that through XCLKOUT pin."
>
> Not sure if XCLKOUT on Arndale schematics means the same.

I suspect that the same, you can easily verify that by checking what ball
identifier corresponds to XCLKOUT pin and how the routing looks like on
the schematics.

We have a bit hackish patch that adds support for the CLKOUT at the
Exynos4 clocks driver to enable the audio codec. An issue here is that the
CLKOUT mux and divider control bitfield is in the PMU registers (as opposed
to CMU where the clock  control registers normally are) and additionally
single register contains the clock mux/divider bitfield as well as couple
other unrelated control bits. Depending if those other bits are considered
really important or not it it might another reason to expose (part of ?)
PMU registers through syscon-like interface. There are registers in PMU
that multiple drivers would be interested in, so instead of all of them to
independently memory map and mess with single registers, probably a regmap
interface could be used. Not sure if this solves the problem well, since
each driver would need to have coded SoC specific register offsets.

It can be seen in the Galaxy S3 kernel code how the Exynos5 CLKOUT handling
might look like. See enum xclkout_select [1], exynos5_pmu_xclkout_set [2].
It would be good someone who has access to the datasheet come up with at
with some patch so the audio works are not blocked. I'm not working right
now on Exynos5 :P.

[1] 
thttps://github.com/sgs3/GT-I9300_Kernel/blob/master/arch/arm/mach-exynos/include/mach/pmu.h
[2] 
https://github.com/sgs3/GT-I9300_Kernel/blob/master/arch/arm/mach-exynos/pmu-exynos5.c

--
Thanks,
Sylwester


From maxime.ripard at free-electrons.com  Fri Jul 26 08:22:19 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 26 Jul 2013 14:22:19 +0200
Subject: [PATCH 03/10] ARM: sunxi: Add the Allwinner A31 compatible to
 the machine definition
In-Reply-To: <20130726123500.58136be1@skate>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374618312-19001-4-git-send-email-maxime.ripard@free-electrons.com>
 <20130726123500.58136be1@skate>
Message-ID: <20130726122219.GA3056@lukather>

Hi Thomas,

On Fri, Jul 26, 2013 at 12:35:00PM +0200, Thomas Petazzoni wrote:
> Dear Maxime Ripard,
> 
> On Wed, 24 Jul 2013 00:25:05 +0200, Maxime Ripard wrote:
> > The Allwinner A31 is a quad-Cortex-A7 based SoC, which shares a lot of
> > differences with the previous SoCs from Allwinner, like the PIO, I2C,
> 
> "shares a lot of differences" ? I suppose you meant "has a lot of
> similarities", or "shares a number of hardware blocks", or something
> like that?

Yep

> > UARTs, timers, watchdog IPs, but also differs but droping the WEMAC
> 
> "but also differs but droping" ?

*by* dropping.

> > ethernet controller and most notably droping the in-house IRQ
> > controller in favor of a ARM GIC one.
> 
> droping -> dropping
> 
> </nitpick> :)

Right.

Thanks!

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130726/0c4dcd13/attachment.sig>

From maxime.ripard at free-electrons.com  Fri Jul 26 08:23:32 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 26 Jul 2013 14:23:32 +0200
Subject: [PATCH 04/10] ARM: sun6i: Add restart code for the A31
In-Reply-To: <20130726123559.66216580@skate>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374618312-19001-5-git-send-email-maxime.ripard@free-electrons.com>
 <20130726123559.66216580@skate>
Message-ID: <20130726122332.GB3056@lukather>

Hi Thomas,

On Fri, Jul 26, 2013 at 12:35:59PM +0200, Thomas Petazzoni wrote:
> Dear Maxime Ripard,
> 
> On Wed, 24 Jul 2013 00:25:06 +0200, Maxime Ripard wrote:
> > The Allwinner A31 has a sligthly different watchdog that requires a
> > different restart code.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > ---
> >  arch/arm/mach-sunxi/sunxi.c | 37 +++++++++++++++++++++++++++++++++++++
> >  1 file changed, 37 insertions(+)
> > 
> > diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> > index 11326d9..c18ef3a 100644
> > --- a/arch/arm/mach-sunxi/sunxi.c
> > +++ b/arch/arm/mach-sunxi/sunxi.c
> > @@ -32,6 +32,15 @@
> >  #define SUN4I_WATCHDOG_MODE_ENABLE		(1 << 0)
> >  #define SUN4I_WATCHDOG_MODE_RESET_ENABLE	(1 << 1)
> >  
> > +#define SUN6I_WATCHDOG1_IRQ_REG		0x00
> > +#define SUN6I_WATCHDOG1_CTRL_REG	0x10
> > +#define SUN6I_WATCHDOG1_CTRL_RESTART		(1 << 0)
> > +#define SUN6I_WATCHDOG1_CONFIG_REG	0x14
> > +#define SUN6I_WATCHDOG1_CONFIG_RESTART		(1 << 0)
> > +#define SUN6I_WATCHDOG1_CONFIG_IRQ		(1 << 1)
> > +#define SUN6I_WATCHDOG1_MODE_REG	0x18
> > +#define SUN6I_WATCHDOG1_MODE_ENABLE		(1 << 0)
> 
> Alignment is not nice, and the BIT() macro should be used.

Actually, the alignment is the one you would expect in the code.

Point taken for the BIT macro, I'll update it.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130726/fa138726/attachment.sig>

From kishon at ti.com  Fri Jul 26 08:42:54 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:12:54 +0530
Subject: [PATCH v10 0/8] PHY framework
Message-ID: <1374842582-13242-1-git-send-email-kishon@ti.com>

Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle.

This framework will be of use only to devices that uses external PHY (PHY
functionality is not embedded within the controller).

The intention of creating this framework is to bring the phy drivers spread
all over the Linux kernel to drivers/phy to increase code re-use and to
increase code maintainability.

Comments to make PHY as bus wasn't done because PHY devices can be part of
other bus and making a same device attached to multiple bus leads to bad
design.

If the PHY driver has to send notification on connect/disconnect, the PHY
driver should make use of the extcon framework. Using this susbsystem
to use extcon framwork will have to be analysed.

You can find this patch series @
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing

I'll create a new branch *next* once this patch series is finalized. All the
PHY driver development that depends on PHY framework can be based on this
branch.

Did USB enumeration testing in panda and beagle after applying [1]

[1] -> https://lkml.org/lkml/2013/7/26/88

Changes from v9:
* Fixed Greg's concern on having *find PHY by string* and changed it to Tomasz
  pseudo code.
* move omap-usb2 phy and twl4030-usb phy to drivers/phy
* made all the dependent drivers select GENERIC_PHY instead of having depends
  on
* Made PHY core to assign the id's (so changed the phy_create API).
* Adapted twl4030-usb to the new design.

Changes from v8:
* Added phy_set_drvdata and phy_get_drvdata in phy.h.
* Changed phy_create API not to take void *priv. private data should now be set
  using phy_set_drvdata now.
Changes from v7:
* Fixed Documentation
* Added to_phy, of_phy_provider_register and devm_of_phy_provider_register
* modified runtime_pm usage in phy_init, phy_exit, phy_power_on and
  phy_power_off. Now phy_power_on will enable the clocks and phy_power_off will
  disable the clocks.
* pm_runtime_no_callbacks() is added so that pm_runtime_get_sync doesn't fail
* modified other patches to adhere to the changes in the PHY framework
* removed usb: phy: twl4030: twl4030 shouldn't be subsys_initcall as it will
  be merged separately.
* reference counting has been added to protect phy ops when the PHY is shared
  by multiple consumers.

Changes from v6
* corrected few typos in Documentation
* Changed PHY Subsystem to *bool* in Kconfig (to avoid compilation errors when
  PHY Subsystem is kept as module and the dependent modules are built-in)
* Added if pm_runtime_enabled check before runtime pm calls.

Changes from v5:
* removed the new sysfs entries as it dint have any new information other than
  what is already there in /sys/devices/...
* removed a bunch of APIs added to get the PHY and now only phy_get and
  devm_phy_get are used.
* Added new APIs to register/unregister the PHY provider. This is needed for
  dt boot case.
* Enabled pm runtime and incorporated the comments given by Alan Stern in a
  different patch series by Gautam.
* Removed the *phy_bind* API. Now the phy binding information should be passed
  using the platform data to the controller devices.
* Fixed a few typos.

Changes from v4:
* removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy providers*
  should use their custom implementation of of_xlate or use of_phy_xlate to get
  *phy instance* from *phy providers*.
* Added of_phy_xlate to be used by *phy providers* if it provides only one PHY.
* changed phy_core from having subsys_initcall to module_init.
* other minor fixes.

Changes from v3:
* Changed the return value of PHY APIs to ENOSYS
* Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting
  PHYs if the same IP implements multiple PHYs.
* modified phy_bind API so that the binding information can now be _updated_.
  In effect of this removed the binding information added in board files and
  added only in usb-musb.c. If a particular board uses a different phy binding,
  it can update it in board file after usb_musb_init().
* Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding
  information.

Changes from v2:
* removed phy_descriptor structure completely so changed the APIs which were
  taking phy_descriptor as parameters
* Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used
  by PHY user drivers which has *phy* and *phy-names* binding in the dt data
* Fixed a few typos
* Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and
  class_dev_iter_exit for traversing through the phy list. (Note we still need
  phy_bind list and phy_bind_mutex).
* Changed the sysfs entry name from *bind* to *phy_bind*.

Changes from v1:
* Added Documentation for the PHY framework
* Added few more APIs mostly w.r.t devres
* Modified omap-usb2 and twl4030 to make use of the new framework

Kishon Vijay Abraham I (8):
  drivers: phy: add generic PHY framework
  usb: phy: omap-usb2: use the new generic PHY framework
  usb: phy: twl4030: use the new generic PHY framework
  arm: omap3: twl: add phy consumer data in twl4030_usb_data
  ARM: dts: omap: update usb_otg_hs data
  usb: musb: omap2430: use the new generic PHY framework
  usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
  usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

 .../devicetree/bindings/phy/phy-bindings.txt       |   66 ++
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 +
 Documentation/phy.txt                              |  166 +++++
 MAINTAINERS                                        |    8 +
 arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 +
 arch/arm/boot/dts/omap3-evm.dts                    |    2 +
 arch/arm/boot/dts/omap3-overo.dtsi                 |    2 +
 arch/arm/boot/dts/omap4.dtsi                       |    3 +
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 arch/arm/mach-omap2/twl-common.c                   |   11 +
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   41 ++
 drivers/phy/Makefile                               |    7 +
 drivers/phy/phy-core.c                             |  714 ++++++++++++++++++++
 drivers/{usb => }/phy/phy-omap-usb2.c              |   60 +-
 drivers/{usb => }/phy/phy-twl4030-usb.c            |   69 +-
 drivers/usb/musb/Kconfig                           |    1 +
 drivers/usb/musb/musb_core.h                       |    2 +
 drivers/usb/musb/omap2430.c                        |   26 +-
 drivers/usb/phy/Kconfig                            |   19 -
 drivers/usb/phy/Makefile                           |    2 -
 include/linux/i2c/twl.h                            |    2 +
 include/linux/phy/phy.h                            |  270 ++++++++
 25 files changed, 1413 insertions(+), 76 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 rename drivers/{usb => }/phy/phy-omap-usb2.c (88%)
 rename drivers/{usb => }/phy/phy-twl4030-usb.c (94%)
 create mode 100644 include/linux/phy/phy.h

-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:42:56 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:12:56 +0530
Subject: [PATCH v10 2/8] usb: phy: omap-usb2: use the new generic PHY framework
In-Reply-To: <1374842582-13242-1-git-send-email-kishon@ti.com>
References: <1374842582-13242-1-git-send-email-kishon@ti.com>
Message-ID: <1374842582-13242-3-git-send-email-kishon@ti.com>

Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.
The omap-usb2 driver is also moved to driver/phy.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 drivers/phy/Kconfig                   |   12 +++++++++
 drivers/phy/Makefile                  |    1 +
 drivers/{usb => }/phy/phy-omap-usb2.c |   45 ++++++++++++++++++++++++++++++---
 drivers/usb/phy/Kconfig               |   10 --------
 drivers/usb/phy/Makefile              |    1 -
 5 files changed, 54 insertions(+), 15 deletions(-)
 rename drivers/{usb => }/phy/phy-omap-usb2.c (88%)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 349bef2..38c3477 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,4 +15,16 @@ config GENERIC_PHY
 	  phy users can obtain reference to the PHY. All the users of this
 	  framework should select this config.
 
+config OMAP_USB2
+	tristate "OMAP USB2 PHY Driver"
+	depends on ARCH_OMAP2PLUS
+	select GENERIC_PHY
+	select USB_PHY
+	select OMAP_CONTROL_USB
+	help
+	  Enable this to support the transceiver that is part of SOC. This
+	  driver takes care of all the PHY functionality apart from comparator.
+	  The USB OTG controller communicates with the comparator using this
+	  driver.
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..ed5b088 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
+obj-$(CONFIG_OMAP_USB2)		+= phy-omap-usb2.o
diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
similarity index 88%
rename from drivers/usb/phy/phy-omap-usb2.c
rename to drivers/phy/phy-omap-usb2.c
index 844ab68..25e0f3c 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/delay.h>
 #include <linux/usb/omap_control_usb.h>
+#include <linux/phy/phy.h>
 
 /**
  * omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,10 +120,36 @@ static int omap_usb2_suspend(struct usb_phy *x, int suspend)
 	return 0;
 }
 
+static int omap_usb_power_off(struct phy *x)
+{
+	struct omap_usb *phy = phy_get_drvdata(x);
+
+	omap_control_usb_phy_power(phy->control_dev, 0);
+
+	return 0;
+}
+
+static int omap_usb_power_on(struct phy *x)
+{
+	struct omap_usb *phy = phy_get_drvdata(x);
+
+	omap_control_usb_phy_power(phy->control_dev, 1);
+
+	return 0;
+}
+
+static struct phy_ops ops = {
+	.power_on	= omap_usb_power_on,
+	.power_off	= omap_usb_power_off,
+	.owner		= THIS_MODULE,
+};
+
 static int omap_usb2_probe(struct platform_device *pdev)
 {
 	struct omap_usb			*phy;
+	struct phy			*generic_phy;
 	struct usb_otg			*otg;
+	struct phy_provider		*phy_provider;
 
 	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
 	if (!phy) {
@@ -144,6 +171,11 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
+	phy_provider = devm_of_phy_provider_register(phy->dev,
+			of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
 	phy->control_dev = omap_get_control_dev();
 	if (IS_ERR(phy->control_dev)) {
 		dev_dbg(&pdev->dev, "Failed to get control device\n");
@@ -159,6 +191,15 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	otg->start_srp		= omap_usb_start_srp;
 	otg->phy		= &phy->phy;
 
+	platform_set_drvdata(pdev, phy);
+	pm_runtime_enable(phy->dev);
+
+	generic_phy = devm_phy_create(phy->dev, &ops, NULL);
+	if (IS_ERR(generic_phy))
+		return PTR_ERR(generic_phy);
+
+	phy_set_drvdata(generic_phy, phy);
+
 	phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");
 	if (IS_ERR(phy->wkupclk)) {
 		dev_err(&pdev->dev, "unable to get usb_phy_cm_clk32k\n");
@@ -174,10 +215,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
 	usb_add_phy_dev(&phy->phy);
 
-	platform_set_drvdata(pdev, phy);
-
-	pm_runtime_enable(phy->dev);
-
 	return 0;
 }
 
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 3622fff..7813238 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -72,16 +72,6 @@ config OMAP_CONTROL_USB
 	  power on the USB2 PHY is present in OMAP4 and OMAP5. OMAP5 has an
 	  additional register to power on USB3 PHY.
 
-config OMAP_USB2
-	tristate "OMAP USB2 PHY Driver"
-	depends on ARCH_OMAP2PLUS
-	select OMAP_CONTROL_USB
-	help
-	  Enable this to support the transceiver that is part of SOC. This
-	  driver takes care of all the PHY functionality apart from comparator.
-	  The USB OTG controller communicates with the comparator using this
-	  driver.
-
 config OMAP_USB3
 	tristate "OMAP USB3 PHY Driver"
 	select OMAP_CONTROL_USB
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 070eca3..56d2b03 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -16,7 +16,6 @@ obj-$(CONFIG_ISP1301_OMAP)		+= phy-isp1301-omap.o
 obj-$(CONFIG_MV_U3D_PHY)		+= phy-mv-u3d-usb.o
 obj-$(CONFIG_NOP_USB_XCEIV)		+= phy-nop.o
 obj-$(CONFIG_OMAP_CONTROL_USB)		+= phy-omap-control.o
-obj-$(CONFIG_OMAP_USB2)			+= phy-omap-usb2.o
 obj-$(CONFIG_OMAP_USB3)			+= phy-omap-usb3.o
 obj-$(CONFIG_SAMSUNG_USBPHY)		+= phy-samsung-usb.o
 obj-$(CONFIG_SAMSUNG_USB2PHY)		+= phy-samsung-usb2.o
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:42:55 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:12:55 +0530
Subject: [PATCH v10 1/8] drivers: phy: add generic PHY framework
In-Reply-To: <1374842582-13242-1-git-send-email-kishon@ti.com>
References: <1374842582-13242-1-git-send-email-kishon@ti.com>
Message-ID: <1374842582-13242-2-git-send-email-kishon@ti.com>

The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.

PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Cc: Tomasz Figa <t.figa at samsung.com>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Tested-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 .../devicetree/bindings/phy/phy-bindings.txt       |   66 ++
 Documentation/phy.txt                              |  166 +++++
 MAINTAINERS                                        |    8 +
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   18 +
 drivers/phy/Makefile                               |    5 +
 drivers/phy/phy-core.c                             |  714 ++++++++++++++++++++
 include/linux/phy/phy.h                            |  270 ++++++++
 9 files changed, 1251 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 0000000..8ae844f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,66 @@
+This document explains only the device tree data binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
+
+PHY device node
+===============
+
+Required Properties:
+#phy-cells:	Number of cells in a PHY specifier;  The meaning of all those
+		cells is defined by the binding for the phy node. The PHY
+		provider can use the values in cells to find the appropriate
+		PHY.
+
+For example:
+
+phys: phy {
+    compatible = "xxx";
+    reg = <...>;
+    .
+    .
+    #phy-cells = <1>;
+    .
+    .
+};
+
+That node describes an IP block (PHY provider) that implements 2 different PHYs.
+In order to differentiate between these 2 PHYs, an additonal specifier should be
+given while trying to get a reference to it.
+
+PHY user node
+=============
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+phy-names : the names of the PHY corresponding to the PHYs present in the
+	    *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss at xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&usb2_phy>, <&usb3_phy>;
+    phy-names = "usb2phy", "usb3phy";
+    .
+    .
+};
+
+This node represents a controller that uses two PHYs, one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss at xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&phys 1>;
+    phy-names = "usbphy";
+    .
+    .
+};
+
+This node represents a controller that uses one of the PHYs of the PHY provider
+device defined previously. Note that the phy handle has an additional specifier
+"1" to differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 0000000..4e056c4
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,166 @@
+			    PHY SUBSYSTEM
+		  Kishon Vijay Abraham I <kishon at ti.com>
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controllers have PHY functionality embedded into it and others use an external
+PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+The intention of creating this framework is to bring the PHY drivers spread
+all over the Linux kernel to drivers/phy to increase code re-use and for
+better code maintainability.
+
+This framework will be of use only to devices that use external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Registering/Unregistering the PHY provider
+
+PHY provider refers to an entity that implements one or more PHY instances.
+For the simple case where the PHY provider implements only a single instance of
+the PHY, the framework provides its own implementation of of_xlate in
+of_phy_simple_xlate. If the PHY provider implements multiple instances, it
+should provide its own implementation of of_xlate. of_xlate is used only for
+dt boot case.
+
+#define of_phy_provider_register(dev, xlate)    \
+        __of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+#define devm_of_phy_provider_register(dev, xlate)       \
+        __of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+of_phy_provider_register and devm_of_phy_provider_register macros can be used to
+register the phy_provider and it takes device and of_xlate as
+arguments. For the dt boot case, all PHY providers should use one of the above
+2 macros to register the PHY provider.
+
+void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider);
+void of_phy_provider_unregister(struct phy_provider *phy_provider);
+
+devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to
+unregister the PHY.
+
+3. Creating the PHY
+
+The PHY driver should create the PHY in order for other peripheral controllers
+to make use of it. The PHY framework provides 2 APIs to create the PHY.
+
+struct phy *phy_create(struct device *dev, const struct phy_ops *ops,
+        struct phy_init_data *init_data);
+struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops,
+	struct phy_init_data *init_data);
+
+The PHY drivers can use one of the above 2 APIs to create the PHY by passing
+the device pointer, phy ops and init_data.
+phy_ops is a set of function pointers for performing PHY operations such as
+init, exit, power_on and power_off. *init_data* is mandatory to get a reference
+to the PHY in the case of non-dt boot. See section *Board File Initialization*
+on how init_data should be used.
+
+Inorder to dereference the private data (in phy_ops), the phy provider driver
+can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
+phy_ops to get back the private data.
+
+4. Getting a reference to the PHY
+
+Before the controller can make use of the PHY, it has to get a reference to
+it. This framework provides the following APIs to get a reference to the PHY.
+
+struct phy *phy_get(struct device *dev, const char *string);
+struct phy *devm_phy_get(struct device *dev, const char *string);
+
+phy_get and devm_phy_get can be used to get the PHY. In the case of dt boot,
+the string arguments should contain the phy name as given in the dt data and
+in the case of non-dt boot, it should contain the label of the PHY.
+The only difference between the two APIs is that devm_phy_get associates the
+device with the PHY using devres on successful PHY get. On driver detach,
+release function is invoked on the the devres data and devres data is freed.
+
+5. Releasing a reference to the PHY
+
+When the controller no longer needs the PHY, it has to release the reference
+to the PHY it has obtained using the APIs mentioned in the above section. The
+PHY framework provides 2 APIs to release a reference to the PHY.
+
+void phy_put(struct phy *phy);
+void devm_phy_put(struct device *dev, struct phy *phy);
+
+Both these APIs are used to release a reference to the PHY and devm_phy_put
+destroys the devres associated with this PHY.
+
+6. Destroying the PHY
+
+When the driver that created the PHY is unloaded, it should destroy the PHY it
+created using one of the following 2 APIs.
+
+void phy_destroy(struct phy *phy);
+void devm_phy_destroy(struct device *dev, struct phy *phy);
+
+Both these APIs destroy the PHY and devm_phy_destroy destroys the devres
+associated with this PHY.
+
+7. PM Runtime
+
+This subsystem is pm runtime enabled. So while creating the PHY,
+pm_runtime_enable of the phy device created by this subsystem is called and
+while destroying the PHY, pm_runtime_disable is called. Note that the phy
+device created by this subsystem will be a child of the device that calls
+phy_create (PHY provider device).
+
+So pm_runtime_get_sync of the phy_device created by this subsystem will invoke
+pm_runtime_get_sync of PHY provider device because of parent-child relationship.
+It should also be noted that phy_power_on and phy_power_off performs
+phy_pm_runtime_get_sync and phy_pm_runtime_put respectively.
+There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync,
+phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
+phy_pm_runtime_forbid for performing PM operations.
+
+8. Board File Initialization
+
+Certain board file initialization is necessary in order to get a reference
+to the PHY in the case of non-dt boot.
+Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe,
+then in the board file the following initialization should be done.
+
+struct phy_consumer consumers[] = {
+	PHY_CONSUMER("dwc3.0", "usb"),
+	PHY_CONSUMER("pcie.0", "pcie"),
+	PHY_CONSUMER("sata.0", "sata"),
+};
+PHY_CONSUMER takes 2 parameters, first is the device name of the controller
+(PHY consumer) and second is the port name.
+
+struct phy_init_data init_data = {
+	.consumers = consumers,
+	.num_consumers = ARRAY_SIZE(consumers),
+};
+
+static const struct platform_device pipe3_phy_dev = {
+	.name = "pipe3-phy",
+	.id = -1,
+	.dev = {
+		.platform_data = {
+			.init_data = &init_data,
+		},
+	},
+};
+
+then, while doing phy_create, the PHY driver should pass this init_data
+	phy_create(dev, ops, pdata->init_data);
+
+and the controller driver (phy consumer) should pass the port name along with
+the device to get a reference to the PHY
+	phy_get(dev, "pcie");
+
+9. DeviceTree Binding
+
+The documentation for PHY dt binding can be found @
+Documentation/devicetree/bindings/phy/phy-bindings.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index bf61e04..96caae7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3594,6 +3594,14 @@ S:	Maintained
 F:	include/asm-generic
 F:	include/uapi/asm-generic
 
+GENERIC PHY FRAMEWORK
+M:	Kishon Vijay Abraham I <kishon at ti.com>
+L:	linux-kernel at vger.kernel.org
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git
+S:	Supported
+F:	drivers/phy/
+F:	include/linux/phy/
+
 GENERIC UIO DRIVER FOR PCI DEVICES
 M:	"Michael S. Tsirkin" <mst at redhat.com>
 L:	kvm at vger.kernel.org
diff --git a/drivers/Kconfig b/drivers/Kconfig
index aa43b91..8f45144 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -166,4 +166,6 @@ source "drivers/reset/Kconfig"
 
 source "drivers/fmc/Kconfig"
 
+source "drivers/phy/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index ab93de8..687da89 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -8,6 +8,8 @@
 obj-y				+= irqchip/
 obj-y				+= bus/
 
+obj-$(CONFIG_GENERIC_PHY)	+= phy/
+
 # GPIO must come after pinctrl as gpios may need to mux pins etc
 obj-y				+= pinctrl/
 obj-y				+= gpio/
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
new file mode 100644
index 0000000..349bef2
--- /dev/null
+++ b/drivers/phy/Kconfig
@@ -0,0 +1,18 @@
+#
+# PHY
+#
+
+menu "PHY Subsystem"
+
+config GENERIC_PHY
+	tristate "PHY Core"
+	help
+	  Generic PHY support.
+
+	  This framework is designed to provide a generic interface for PHY
+	  devices present in the kernel. This layer will have the generic
+	  API by which phy drivers can create PHY using the phy framework and
+	  phy users can obtain reference to the PHY. All the users of this
+	  framework should select this config.
+
+endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
new file mode 100644
index 0000000..9e9560f
--- /dev/null
+++ b/drivers/phy/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 0000000..f1d15e5
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,714 @@
+/*
+ * phy-core.c  --  Generic Phy framework.
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Kishon Vijay Abraham I <kishon at ti.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/idr.h>
+#include <linux/pm_runtime.h>
+
+static struct class *phy_class;
+static DEFINE_MUTEX(phy_provider_mutex);
+static LIST_HEAD(phy_provider_list);
+static DEFINE_IDA(phy_ida);
+
+static int phy_get_id(void)
+{
+	int ret;
+	int id;
+
+	ret = ida_pre_get(&phy_ida, GFP_KERNEL);
+	if (!ret)
+		return -ENOMEM;
+
+	ret = ida_get_new(&phy_ida, &id);
+	if (ret < 0)
+		return ret;
+
+	return id;
+}
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_put(phy);
+}
+
+static void devm_phy_provider_release(struct device *dev, void *res)
+{
+	struct phy_provider *phy_provider = *(struct phy_provider **)res;
+
+	of_phy_provider_unregister(phy_provider);
+}
+
+static void devm_phy_consume(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_destroy(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+	return res == match_data;
+}
+
+static struct phy *phy_lookup(struct device *device, const char *port)
+{
+	unsigned int count;
+	struct phy *phy;
+	struct device *dev;
+	struct phy_consumer *consumers;
+	struct class_dev_iter iter;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = to_phy(dev);
+		count = phy->init_data->num_consumers;
+		consumers = phy->init_data->consumers;
+		while (count--) {
+			if (!strcmp(consumers->dev_name, dev_name(device)) &&
+					!strcmp(consumers->port, port)) {
+				class_dev_iter_exit(&iter);
+				return phy;
+			}
+			consumers++;
+		}
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-ENODEV);
+}
+
+static struct phy_provider *of_phy_provider_lookup(struct device_node *node)
+{
+	struct phy_provider *phy_provider;
+
+	list_for_each_entry(phy_provider, &phy_provider_list, list) {
+		if (phy_provider->dev->of_node == node)
+			return phy_provider;
+	}
+
+	return ERR_PTR(-EPROBE_DEFER);
+}
+
+int phy_pm_runtime_get(struct phy *phy)
+{
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_get(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_pm_runtime_get);
+
+int phy_pm_runtime_get_sync(struct phy *phy)
+{
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_get_sync(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_pm_runtime_get_sync);
+
+int phy_pm_runtime_put(struct phy *phy)
+{
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_put(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_pm_runtime_put);
+
+int phy_pm_runtime_put_sync(struct phy *phy)
+{
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_put_sync(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_pm_runtime_put_sync);
+
+void phy_pm_runtime_allow(struct phy *phy)
+{
+	if (!pm_runtime_enabled(&phy->dev))
+		return;
+
+	pm_runtime_allow(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_pm_runtime_allow);
+
+void phy_pm_runtime_forbid(struct phy *phy)
+{
+	if (!pm_runtime_enabled(&phy->dev))
+		return;
+
+	pm_runtime_forbid(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_pm_runtime_forbid);
+
+int phy_init(struct phy *phy)
+{
+	int ret;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (phy->init_count++ == 0 && phy->ops->init) {
+		ret = phy->ops->init(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy init failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(phy_init);
+
+int phy_exit(struct phy *phy)
+{
+	int ret;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (--phy->init_count == 0 && phy->ops->exit) {
+		ret = phy->ops->exit(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy exit failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(phy_exit);
+
+int phy_power_on(struct phy *phy)
+{
+	int ret = -ENOTSUPP;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (phy->power_count++ == 0 && phy->ops->power_on) {
+		ret = phy->ops->power_on(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy poweron failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(phy_power_on);
+
+int phy_power_off(struct phy *phy)
+{
+	int ret = -ENOTSUPP;
+
+	mutex_lock(&phy->mutex);
+	if (--phy->power_count == 0 && phy->ops->power_off) {
+		ret =  phy->ops->power_off(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy poweroff failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(phy_power_off);
+
+/**
+ * of_phy_get() - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Returns the phy associated with the given phandle value,
+ * after getting a refcount to it or -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded. This function uses of_xlate call back function provided
+ * while registering the phy_provider to find the phy instance.
+ */
+static struct phy *of_phy_get(struct device *dev, int index)
+{
+	int ret;
+	struct phy_provider *phy_provider;
+	struct phy *phy = NULL;
+	struct of_phandle_args args;
+
+	ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
+		index, &args);
+	if (ret) {
+		dev_dbg(dev, "failed to get phy in %s node\n",
+			dev->of_node->full_name);
+		return ERR_PTR(-ENODEV);
+	}
+
+	mutex_lock(&phy_provider_mutex);
+	phy_provider = of_phy_provider_lookup(args.np);
+	if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
+		phy = ERR_PTR(-EPROBE_DEFER);
+		goto err0;
+	}
+
+	phy = phy_provider->of_xlate(phy_provider->dev, &args);
+	module_put(phy_provider->owner);
+
+err0:
+	mutex_unlock(&phy_provider_mutex);
+	of_node_put(args.np);
+
+	return phy;
+}
+
+/**
+ * phy_put() - release the PHY
+ * @phy: the phy returned by phy_get()
+ *
+ * Releases a refcount the caller received from phy_get().
+ */
+void phy_put(struct phy *phy)
+{
+	if (IS_ERR(phy))
+		return;
+
+	module_put(phy->ops->owner);
+	put_device(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_put);
+
+/**
+ * devm_phy_put() - release the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_put
+ * to release the phy.
+ */
+void devm_phy_put(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_release, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_put);
+
+/**
+ * of_phy_simple_xlate() - returns the phy instance from phy provider
+ * @dev: the PHY provider device
+ * @args: of_phandle_args (not used here)
+ *
+ * Intended to be used by phy provider for the common case where #phy-cells is
+ * 0. For other cases where #phy-cells is greater than '0', the phy provider
+ * should provide a custom of_xlate function that reads the *args* and returns
+ * the appropriate phy.
+ */
+struct phy *of_phy_simple_xlate(struct device *dev, struct of_phandle_args
+	*args)
+{
+	struct phy *phy;
+	struct class_dev_iter iter;
+	struct device_node *node = dev->of_node;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = to_phy(dev);
+		if (node != phy->dev.of_node)
+			continue;
+
+		class_dev_iter_exit(&iter);
+		return phy;
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
+
+/**
+ * phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data or the name of the controller
+ * port for non-dt case
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy.  The caller is responsible for
+ * calling phy_put() to release that count.
+ */
+struct phy *phy_get(struct device *dev, const char *string)
+{
+	int index = 0;
+	struct phy *phy = NULL;
+
+	if (string == NULL) {
+		dev_WARN(dev, "missing string\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (dev->of_node) {
+		index = of_property_match_string(dev->of_node, "phy-names",
+			string);
+		phy = of_phy_get(dev, index);
+		if (IS_ERR(phy)) {
+			dev_err(dev, "unable to find phy\n");
+			return phy;
+		}
+	} else {
+		phy = phy_lookup(dev, string);
+		if (IS_ERR(phy)) {
+			dev_err(dev, "unable to find phy\n");
+			return phy;
+		}
+	}
+
+	if (!try_module_get(phy->ops->owner))
+		return ERR_PTR(-EPROBE_DEFER);
+
+	get_device(&phy->dev);
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(phy_get);
+
+/**
+ * devm_phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data or phy device name
+ * for non-dt case
+ *
+ * Gets the phy using phy_get(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_get(struct device *dev, const char *string)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_get(dev, string);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_get);
+
+/**
+ * phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @ops: function pointers for performing phy operations
+ * @init_data: contains the list of PHY consumers or NULL
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, const struct phy_ops *ops,
+	struct phy_init_data *init_data)
+{
+	int ret;
+	int id;
+	struct phy *phy;
+
+	if (!dev) {
+		dev_WARN(dev, "no device provided for PHY\n");
+		ret = -EINVAL;
+		goto err0;
+	}
+
+	phy = kzalloc(sizeof(*phy), GFP_KERNEL);
+	if (!phy) {
+		ret = -ENOMEM;
+		goto err0;
+	}
+
+	id = phy_get_id();
+	if (id < 0) {
+		dev_err(dev, "unable to get id\n");
+		ret = id;
+		goto err0;
+	}
+
+	device_initialize(&phy->dev);
+	mutex_init(&phy->mutex);
+
+	phy->dev.class = phy_class;
+	phy->dev.parent = dev;
+	phy->dev.of_node = dev->of_node;
+	phy->id = id;
+	phy->ops = ops;
+	phy->init_data = init_data;
+
+	ret = dev_set_name(&phy->dev, "phy-%s.%d", dev_name(dev), id);
+	if (ret)
+		goto err1;
+
+	ret = device_add(&phy->dev);
+	if (ret)
+		goto err1;
+
+	if (pm_runtime_enabled(dev)) {
+		pm_runtime_enable(&phy->dev);
+		pm_runtime_no_callbacks(&phy->dev);
+	}
+
+	return phy;
+
+err1:
+	ida_remove(&phy_ida, phy->id);
+	put_device(&phy->dev);
+	kfree(phy);
+
+err0:
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(phy_create);
+
+/**
+ * devm_phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @ops: function pointers for performing phy operations
+ * @init_data: contains the list of PHY consumers or NULL
+ *
+ * Creates a new PHY device adding it to the PHY class.
+ * While at that, it also associates the device with the phy using devres.
+ * On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops,
+	struct phy_init_data *init_data)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_consume, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_create(dev, ops, init_data);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_create);
+
+/**
+ * phy_destroy() - destroy the phy
+ * @phy: the phy to be destroyed
+ *
+ * Called to destroy the phy.
+ */
+void phy_destroy(struct phy *phy)
+{
+	pm_runtime_disable(&phy->dev);
+	device_unregister(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_destroy);
+
+/**
+ * devm_phy_destroy() - destroy the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_destroy
+ * to destroy the phy.
+ */
+void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_consume, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_destroy);
+
+/**
+ * __of_phy_provider_register() - create/register phy provider with the framework
+ * @dev: struct device of the phy provider
+ * @owner: the module owner containing of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy provider
+ *
+ * Creates struct phy_provider from dev and of_xlate function pointer.
+ * This is used in the case of dt boot for finding the phy instance from
+ * phy provider.
+ */
+struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	struct phy_provider *phy_provider;
+
+	phy_provider = kzalloc(sizeof(*phy_provider), GFP_KERNEL);
+	if (!phy_provider)
+		return ERR_PTR(-ENOMEM);
+
+	phy_provider->dev = dev;
+	phy_provider->owner = owner;
+	phy_provider->of_xlate = of_xlate;
+
+	mutex_lock(&phy_provider_mutex);
+	list_add_tail(&phy_provider->list, &phy_provider_list);
+	mutex_unlock(&phy_provider_mutex);
+
+	return phy_provider;
+}
+EXPORT_SYMBOL_GPL(__of_phy_provider_register);
+
+/**
+ * __devm_of_phy_provider_register() - create/register phy provider with the
+ * framework
+ * @dev: struct device of the phy provider
+ * @owner: the module owner containing of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy provider
+ *
+ * Creates struct phy_provider from dev and of_xlate function pointer.
+ * This is used in the case of dt boot for finding the phy instance from
+ * phy provider. While at that, it also associates the device with the
+ * phy provider using devres. On driver detach, release function is invoked
+ * on the devres data, then, devres data is freed.
+ */
+struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	struct phy_provider **ptr, *phy_provider;
+
+	ptr = devres_alloc(devm_phy_provider_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy_provider = __of_phy_provider_register(dev, owner, of_xlate);
+	if (!IS_ERR(phy_provider)) {
+		*ptr = phy_provider;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy_provider;
+}
+EXPORT_SYMBOL_GPL(__devm_of_phy_provider_register);
+
+/**
+ * of_phy_provider_unregister() - unregister phy provider from the framework
+ * @phy_provider: phy provider returned by of_phy_provider_register()
+ *
+ * Removes the phy_provider created using of_phy_provider_register().
+ */
+void of_phy_provider_unregister(struct phy_provider *phy_provider)
+{
+	if (IS_ERR(phy_provider))
+		return;
+
+	mutex_lock(&phy_provider_mutex);
+	list_del(&phy_provider->list);
+	kfree(phy_provider);
+	mutex_unlock(&phy_provider_mutex);
+}
+EXPORT_SYMBOL_GPL(of_phy_provider_unregister);
+
+/**
+ * devm_of_phy_provider_unregister() - remove phy provider from the framework
+ * @dev: struct device of the phy provider
+ *
+ * destroys the devres associated with this phy provider and invokes
+ * of_phy_provider_unregister to unregister the phy provider.
+ */
+void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider) {
+	int r;
+
+	r = devres_destroy(dev, devm_phy_provider_release, devm_phy_match,
+		phy_provider);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY provider device resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_provider_unregister);
+
+/**
+ * phy_release() - release the phy
+ * @dev: the dev member within phy
+ *
+ * When the last reference to the device is removed, it is called
+ * from the embedded kobject as release method.
+ */
+static void phy_release(struct device *dev)
+{
+	struct phy *phy;
+
+	phy = to_phy(dev);
+	dev_vdbg(dev, "releasing '%s'\n", dev_name(dev));
+	ida_remove(&phy_ida, phy->id);
+	kfree(phy);
+}
+
+static int __init phy_core_init(void)
+{
+	phy_class = class_create(THIS_MODULE, "phy");
+	if (IS_ERR(phy_class)) {
+		pr_err("failed to create phy class --> %ld\n",
+			PTR_ERR(phy_class));
+		return PTR_ERR(phy_class);
+	}
+
+	phy_class->dev_release = phy_release;
+
+	return 0;
+}
+module_init(phy_core_init);
+
+static void __exit phy_core_exit(void)
+{
+	class_destroy(phy_class);
+}
+module_exit(phy_core_exit);
+
+MODULE_DESCRIPTION("Generic PHY Framework");
+MODULE_AUTHOR("Kishon Vijay Abraham I <kishon at ti.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
new file mode 100644
index 0000000..e444b23
--- /dev/null
+++ b/include/linux/phy/phy.h
@@ -0,0 +1,270 @@
+/*
+ * phy.h -- generic phy header file
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Kishon Vijay Abraham I <kishon at ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __DRIVERS_PHY_H
+#define __DRIVERS_PHY_H
+
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/device.h>
+#include <linux/pm_runtime.h>
+
+struct phy;
+
+/**
+ * struct phy_ops - set of function pointers for performing phy operations
+ * @init: operation to be performed for initializing phy
+ * @exit: operation to be performed while exiting
+ * @power_on: powering on the phy
+ * @power_off: powering off the phy
+ * @owner: the module owner containing the ops
+ */
+struct phy_ops {
+	int	(*init)(struct phy *phy);
+	int	(*exit)(struct phy *phy);
+	int	(*power_on)(struct phy *phy);
+	int	(*power_off)(struct phy *phy);
+	struct module *owner;
+};
+
+/**
+ * struct phy - represents the phy device
+ * @dev: phy device
+ * @id: id of the phy device
+ * @ops: function pointers for performing phy operations
+ * @init_data: list of PHY consumers (non-dt only)
+ * @mutex: mutex to protect phy_ops
+ * @init_count: used to protect when the PHY is used by multiple consumers
+ * @power_count: used to protect when the PHY is used by multiple consumers
+ */
+struct phy {
+	struct device		dev;
+	int			id;
+	const struct phy_ops	*ops;
+	struct phy_init_data	*init_data;
+	struct mutex		mutex;
+	int			init_count;
+	int			power_count;
+};
+
+/**
+ * struct phy_provider - represents the phy provider
+ * @dev: phy provider device
+ * @owner: the module owner having of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy pointer
+ * @list: to maintain a linked list of PHY providers
+ */
+struct phy_provider {
+	struct device		*dev;
+	struct module		*owner;
+	struct list_head	list;
+	struct phy * (*of_xlate)(struct device *dev,
+		struct of_phandle_args *args);
+};
+
+/**
+ * struct phy_consumer - represents the phy consumer
+ * @dev_name: the device name of the controller that will use this PHY device
+ * @port: name given to the consumer port
+ */
+struct phy_consumer {
+	const char *dev_name;
+	const char *port;
+};
+
+/**
+ * struct phy_init_data - contains the list of PHY consumers
+ * @num_consumers: number of consumers for this PHY device
+ * @consumers: list of PHY consumers
+ */
+struct phy_init_data {
+	unsigned int num_consumers;
+	struct phy_consumer *consumers;
+};
+
+#define PHY_CONSUMER(_dev_name, _port)				\
+{								\
+	.dev_name	= _dev_name,				\
+	.port		= _port,				\
+}
+
+#define	to_phy(dev)	(container_of((dev), struct phy, dev))
+
+#define	of_phy_provider_register(dev, xlate)	\
+	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+#define	devm_of_phy_provider_register(dev, xlate)	\
+	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+static inline void phy_set_drvdata(struct phy *phy, void *data)
+{
+	dev_set_drvdata(&phy->dev, data);
+}
+
+static inline void *phy_get_drvdata(struct phy *phy)
+{
+	return dev_get_drvdata(&phy->dev);
+}
+
+#if IS_ENABLED(CONFIG_GENERIC_PHY)
+extern int phy_pm_runtime_get(struct phy *phy);
+extern int phy_pm_runtime_get_sync(struct phy *phy);
+extern int phy_pm_runtime_put(struct phy *phy);
+extern int phy_pm_runtime_put_sync(struct phy *phy);
+extern void phy_pm_runtime_allow(struct phy *phy);
+extern void phy_pm_runtime_forbid(struct phy *phy);
+extern int phy_init(struct phy *phy);
+extern int phy_exit(struct phy *phy);
+extern int phy_power_on(struct phy *phy);
+extern int phy_power_off(struct phy *phy);
+extern struct phy *phy_get(struct device *dev, const char *string);
+extern struct phy *devm_phy_get(struct device *dev, const char *string);
+extern void phy_put(struct phy *phy);
+extern void devm_phy_put(struct device *dev, struct phy *phy);
+extern struct phy *of_phy_simple_xlate(struct device *dev,
+	struct of_phandle_args *args);
+extern struct phy *phy_create(struct device *dev, const struct phy_ops *ops,
+	struct phy_init_data *init_data);
+extern struct phy *devm_phy_create(struct device *dev,
+	const struct phy_ops *ops, struct phy_init_data *init_data);
+extern void phy_destroy(struct phy *phy);
+extern void devm_phy_destroy(struct device *dev, struct phy *phy);
+extern struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+extern struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+extern void of_phy_provider_unregister(struct phy_provider *phy_provider);
+extern void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider);
+#else
+static inline int phy_pm_runtime_get(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline int phy_pm_runtime_get_sync(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline int phy_pm_runtime_put(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline int phy_pm_runtime_put_sync(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline void phy_pm_runtime_allow(struct phy *phy)
+{
+	return;
+}
+
+static inline void phy_pm_runtime_forbid(struct phy *phy)
+{
+	return;
+}
+
+static inline int phy_init(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline int phy_exit(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline int phy_power_on(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline int phy_power_off(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline struct phy *phy_get(struct device *dev, const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_get(struct device *dev, const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_put(struct phy *phy)
+{
+}
+
+static inline void devm_phy_put(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy *of_phy_simple_xlate(struct device *dev,
+	struct of_phandle_args *args)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *phy_create(struct device *dev,
+	const struct phy_ops *ops, struct phy_init_data *init_data)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_create(struct device *dev,
+	const struct phy_ops *ops, struct phy_init_data *init_data)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_destroy(struct phy *phy)
+{
+}
+
+static inline void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy_provider *__of_phy_provider_register(
+	struct device *dev, struct module *owner, struct phy * (*of_xlate)(
+	struct device *dev, struct of_phandle_args *args))
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy_provider *__devm_of_phy_provider_register(struct device
+	*dev, struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void of_phy_provider_unregister(struct phy_provider *phy_provider)
+{
+}
+
+static inline void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider)
+{
+}
+#endif
+
+#endif /* __DRIVERS_PHY_H */
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:42:57 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:12:57 +0530
Subject: [PATCH v10 3/8] usb: phy: twl4030: use the new generic PHY framework
In-Reply-To: <1374842582-13242-1-git-send-email-kishon@ti.com>
References: <1374842582-13242-1-git-send-email-kishon@ti.com>
Message-ID: <1374842582-13242-4-git-send-email-kishon@ti.com>

Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed. Also twl4030-usb driver is moved
to drivers/phy/.

However using the old usb phy library cannot be completely removed
because otg is intertwined with phy and moving to the new
framework completely will break otg. Once we have a separate otg state machine,
we can get rid of the usb phy library.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 drivers/phy/Kconfig                     |   11 ++++++
 drivers/phy/Makefile                    |    1 +
 drivers/{usb => }/phy/phy-twl4030-usb.c |   56 +++++++++++++++++++++++++++++--
 drivers/usb/phy/Kconfig                 |    9 -----
 drivers/usb/phy/Makefile                |    1 -
 include/linux/i2c/twl.h                 |    2 ++
 6 files changed, 67 insertions(+), 13 deletions(-)
 rename drivers/{usb => }/phy/phy-twl4030-usb.c (95%)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 38c3477..ac239ac 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -27,4 +27,15 @@ config OMAP_USB2
 	  The USB OTG controller communicates with the comparator using this
 	  driver.
 
+config TWL4030_USB
+	tristate "TWL4030 USB Transceiver Driver"
+	depends on TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS
+	select GENERIC_PHY
+	select USB_PHY
+	help
+	  Enable this to support the USB OTG transceiver on TWL4030
+	  family chips (including the TWL5030 and TPS659x0 devices).
+	  This transceiver supports high and full speed devices plus,
+	  in host mode, low speed.
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index ed5b088..0dd8a98 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
 obj-$(CONFIG_OMAP_USB2)		+= phy-omap-usb2.o
+obj-$(CONFIG_TWL4030_USB)	+= phy-twl4030-usb.o
diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
similarity index 95%
rename from drivers/usb/phy/phy-twl4030-usb.c
rename to drivers/phy/phy-twl4030-usb.c
index 8f78d2d..494f107 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -33,6 +33,7 @@
 #include <linux/io.h>
 #include <linux/delay.h>
 #include <linux/usb/otg.h>
+#include <linux/phy/phy.h>
 #include <linux/usb/musb-omap.h>
 #include <linux/usb/ulpi.h>
 #include <linux/i2c/twl.h>
@@ -431,6 +432,14 @@ static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
 	dev_dbg(twl->dev, "%s\n", __func__);
 }
 
+static int twl4030_phy_power_off(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	twl4030_phy_suspend(twl, 0);
+	return 0;
+}
+
 static void __twl4030_phy_resume(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
@@ -459,6 +468,14 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 	}
 }
 
+static int twl4030_phy_power_on(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	twl4030_phy_resume(twl);
+	return 0;
+}
+
 static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
 {
 	/* Enable writing to power configuration registers */
@@ -602,13 +619,22 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 	status = twl4030_usb_linkstat(twl);
 	twl->linkstat = status;
 
-	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
+	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
 		omap_musb_mailbox(twl->linkstat);
+		twl4030_phy_resume(twl);
+	}
 
 	sysfs_notify(&twl->dev->kobj, NULL, "vbus");
 	return 0;
 }
 
+static int twl4030_phy_init(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	return twl4030_usb_phy_init(&twl->phy);
+}
+
 static int twl4030_set_suspend(struct usb_phy *x, int suspend)
 {
 	struct twl4030_usb *twl = phy_to_twl(x);
@@ -646,13 +672,23 @@ static int twl4030_set_host(struct usb_otg *otg, struct usb_bus *host)
 	return 0;
 }
 
+static const struct phy_ops ops = {
+	.init		= twl4030_phy_init,
+	.power_on	= twl4030_phy_power_on,
+	.power_off	= twl4030_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
 static int twl4030_usb_probe(struct platform_device *pdev)
 {
 	struct twl4030_usb_data *pdata = pdev->dev.platform_data;
 	struct twl4030_usb	*twl;
+	struct phy		*phy;
 	int			status, err;
 	struct usb_otg		*otg;
 	struct device_node	*np = pdev->dev.of_node;
+	struct phy_provider	*phy_provider;
+	struct phy_init_data	*init_data = NULL;
 
 	twl = devm_kzalloc(&pdev->dev, sizeof *twl, GFP_KERNEL);
 	if (!twl)
@@ -661,9 +697,10 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	if (np)
 		of_property_read_u32(np, "usb_mode",
 				(enum twl4030_usb_mode *)&twl->usb_mode);
-	else if (pdata)
+	else if (pdata) {
 		twl->usb_mode = pdata->usb_mode;
-	else {
+		init_data = pdata->init_data;
+	} else {
 		dev_err(&pdev->dev, "twl4030 initialized without pdata\n");
 		return -EINVAL;
 	}
@@ -689,6 +726,19 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	otg->set_host		= twl4030_set_host;
 	otg->set_peripheral	= twl4030_set_peripheral;
 
+	phy_provider = devm_of_phy_provider_register(twl->dev,
+		of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	phy = devm_phy_create(twl->dev, &ops, init_data);
+	if (IS_ERR(phy)) {
+		dev_dbg(&pdev->dev, "Failed to create PHY\n");
+		return PTR_ERR(phy);
+	}
+
+	phy_set_drvdata(phy, twl);
+
 	/* init spinlock for workqueue */
 	spin_lock_init(&twl->lock);
 
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 7813238..1e05b1d 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -102,15 +102,6 @@ config SAMSUNG_USB3PHY
 	  Enable this to support Samsung USB 3.0 (Super Speed) phy controller
 	  for samsung SoCs.
 
-config TWL4030_USB
-	tristate "TWL4030 USB Transceiver Driver"
-	depends on TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS
-	help
-	  Enable this to support the USB OTG transceiver on TWL4030
-	  family chips (including the TWL5030 and TPS659x0 devices).
-	  This transceiver supports high and full speed devices plus,
-	  in host mode, low speed.
-
 config TWL6030_USB
 	tristate "TWL6030 USB Transceiver Driver"
 	depends on TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 56d2b03..7bcc9ed0 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -20,7 +20,6 @@ obj-$(CONFIG_OMAP_USB3)			+= phy-omap-usb3.o
 obj-$(CONFIG_SAMSUNG_USBPHY)		+= phy-samsung-usb.o
 obj-$(CONFIG_SAMSUNG_USB2PHY)		+= phy-samsung-usb2.o
 obj-$(CONFIG_SAMSUNG_USB3PHY)		+= phy-samsung-usb3.o
-obj-$(CONFIG_TWL4030_USB)		+= phy-twl4030-usb.o
 obj-$(CONFIG_TWL6030_USB)		+= phy-twl6030-usb.o
 obj-$(CONFIG_USB_EHCI_TEGRA)		+= phy-tegra-usb.o
 obj-$(CONFIG_USB_GPIO_VBUS)		+= phy-gpio-vbus-usb.o
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 81cbbdb..673a3ce 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -26,6 +26,7 @@
 #define __TWL_H_
 
 #include <linux/types.h>
+#include <linux/phy/phy.h>
 #include <linux/input/matrix_keypad.h>
 
 /*
@@ -615,6 +616,7 @@ enum twl4030_usb_mode {
 struct twl4030_usb_data {
 	enum twl4030_usb_mode	usb_mode;
 	unsigned long		features;
+	struct phy_init_data	*init_data;
 
 	int		(*phy_init)(struct device *dev);
 	int		(*phy_exit)(struct device *dev);
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:42:58 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:12:58 +0530
Subject: [PATCH v10 4/8] arm: omap3: twl: add phy consumer data in
 twl4030_usb_data
In-Reply-To: <1374842582-13242-1-git-send-email-kishon@ti.com>
References: <1374842582-13242-1-git-send-email-kishon@ti.com>
Message-ID: <1374842582-13242-5-git-send-email-kishon@ti.com>

The PHY framework uses the phy consumer data populated in platform data in the
case of non-dt boot to return the reference to the PHY when the controller
(PHY consumer) requests for it. So populated the phy consumer data in the platform
data of twl usb.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 arch/arm/mach-omap2/twl-common.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index c05898f..b0d54da 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -24,6 +24,7 @@
 #include <linux/i2c/twl.h>
 #include <linux/gpio.h>
 #include <linux/string.h>
+#include <linux/phy/phy.h>
 #include <linux/regulator/machine.h>
 #include <linux/regulator/fixed.h>
 
@@ -90,8 +91,18 @@ void __init omap_pmic_late_init(void)
 }
 
 #if defined(CONFIG_ARCH_OMAP3)
+struct phy_consumer consumers[] = {
+	PHY_CONSUMER("musb-hdrc.0", "usb"),
+};
+
+struct phy_init_data init_data = {
+	.consumers = consumers,
+	.num_consumers = ARRAY_SIZE(consumers),
+};
+
 static struct twl4030_usb_data omap3_usb_pdata = {
 	.usb_mode	= T2_USB_MODE_ULPI,
+	.init_data	= &init_data,
 };
 
 static int omap3_batt_table[] = {
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:42:59 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:12:59 +0530
Subject: [PATCH v10 5/8] ARM: dts: omap: update usb_otg_hs data
In-Reply-To: <1374842582-13242-1-git-send-email-kishon@ti.com>
References: <1374842582-13242-1-git-send-email-kishon@ti.com>
Message-ID: <1374842582-13242-6-git-send-email-kishon@ti.com>

Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +++++
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 ++++++
 arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 ++
 arch/arm/boot/dts/omap3-evm.dts                    |    2 ++
 arch/arm/boot/dts/omap3-overo.dtsi                 |    2 ++
 arch/arm/boot/dts/omap4.dtsi                       |    3 +++
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 7 files changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 57e71f6..825790d 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
  - power : Should be "50". This signifies the controller can supply up to
    100mA when operating in host mode.
  - usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phy* phandle.
 
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs at 4a0ab000 {
 	num-eps = <16>;
 	ram-bits = <12>;
 	ctrl-module = <&omap_control_usb>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 };
 
 Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
 Required properties:
  - compatible: Should be "ti,omap-usb2"
  - reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy at 4a0ad080 {
 	compatible = "ti,omap-usb2";
 	reg = <0x4a0ad080 0x58>;
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
 
 OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the registers
    filled in "reg".
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy at 4a084400 {
 	      <0x4a084c00 0x40>;
 	reg-names = "phy_rx", "phy_tx", "pll_ctrl";
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..533b2da 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -144,6 +144,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 7d4329d..4134dd0 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -70,6 +70,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
index 8f1abec..a461d2f 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -76,6 +76,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..1e8e2fe 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -520,6 +520,7 @@
 				compatible = "ti,omap-usb2";
 				reg = <0x4a0ad080 0x58>;
 				ctrl-module = <&omap_control_usb>;
+				#phy-cells = <0>;
 			};
 		};
 
@@ -658,6 +659,8 @@
 			interrupt-names = "mc", "dma";
 			ti,hwmods = "usb_otg_hs";
 			usb-phy = <&usb2_phy>;
+			phys = <&usb2_phy>;
+			phy-names = "usb2-phy";
 			multipoint = <1>;
 			num-eps = <16>;
 			ram-bits = <12>;
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index b3034da..ce4cd6f 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -80,6 +80,7 @@
 		usb1v8-supply = <&vusb1v8>;
 		usb3v1-supply = <&vusb3v1>;
 		usb_mode = <1>;
+		#phy-cells = <0>;
 	};
 
 	twl_pwm: pwm {
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:43:00 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:13:00 +0530
Subject: [PATCH v10 6/8] usb: musb: omap2430: use the new generic PHY framework
In-Reply-To: <1374842582-13242-1-git-send-email-kishon@ti.com>
References: <1374842582-13242-1-git-send-email-kishon@ti.com>
Message-ID: <1374842582-13242-7-git-send-email-kishon@ti.com>

Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on and
power_off to align with the new PHY framework.

musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 drivers/usb/musb/Kconfig     |    1 +
 drivers/usb/musb/musb_core.h |    2 ++
 drivers/usb/musb/omap2430.c  |   26 ++++++++++++++++++++------
 3 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 797e3fd..25e2e57 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -76,6 +76,7 @@ config USB_MUSB_TUSB6010
 config USB_MUSB_OMAP2PLUS
 	tristate "OMAP2430 and onwards"
 	depends on ARCH_OMAP2PLUS
+	select GENERIC_PHY
 
 config USB_MUSB_AM35X
 	tristate "AM35x"
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7d341c3..6e567bd 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
 #include <linux/usb.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/musb.h>
+#include <linux/phy/phy.h>
 
 struct musb;
 struct musb_hw_ep;
@@ -346,6 +347,7 @@ struct musb {
 	u16			int_tx;
 
 	struct usb_phy		*xceiv;
+	struct phy		*phy;
 
 	int nIrq;
 	unsigned		irq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 6708a3b..f7b33f4 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -348,11 +348,21 @@ static int omap2430_musb_init(struct musb *musb)
 	 * up through ULPI.  TWL4030-family PMICs include one,
 	 * which needs a driver, drivers aren't always needed.
 	 */
-	if (dev->parent->of_node)
+	if (dev->parent->of_node) {
+		musb->phy = devm_phy_get(dev->parent, "usb2-phy");
+
+		/* We can't totally remove musb->xceiv as of now because
+		 * musb core uses xceiv.state and xceiv.otg. Once we have
+		 * a separate state machine to handle otg, these can be moved
+		 * out of xceiv and then we can start using the generic PHY
+		 * framework
+		 */
 		musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
 		    "usb-phy", 0);
-	else
+	} else {
 		musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+		musb->phy = devm_phy_get(dev, "usb");
+	}
 
 	if (IS_ERR(musb->xceiv)) {
 		status = PTR_ERR(musb->xceiv);
@@ -364,6 +374,10 @@ static int omap2430_musb_init(struct musb *musb)
 		return -EPROBE_DEFER;
 	}
 
+	if (IS_ERR(musb->phy)) {
+		pr_err("HS USB OTG: no PHY configured\n");
+		return PTR_ERR(musb->phy);
+	}
 	musb->isr = omap2430_musb_interrupt;
 
 	status = pm_runtime_get_sync(dev);
@@ -397,7 +411,7 @@ static int omap2430_musb_init(struct musb *musb)
 	if (glue->status != OMAP_MUSB_UNKNOWN)
 		omap_musb_set_mailbox(glue);
 
-	usb_phy_init(musb->xceiv);
+	phy_init(musb->phy);
 
 	pm_runtime_put_noidle(musb->controller);
 	return 0;
@@ -460,6 +474,7 @@ static int omap2430_musb_exit(struct musb *musb)
 	del_timer_sync(&musb_idle_timer);
 
 	omap2430_low_level_exit(musb);
+	phy_exit(musb->phy);
 
 	return 0;
 }
@@ -633,7 +648,7 @@ static int omap2430_runtime_suspend(struct device *dev)
 				OTG_INTERFSEL);
 
 		omap2430_low_level_exit(musb);
-		usb_phy_set_suspend(musb->xceiv, 1);
+		phy_power_off(musb->phy);
 	}
 
 	return 0;
@@ -648,8 +663,7 @@ static int omap2430_runtime_resume(struct device *dev)
 		omap2430_low_level_init(musb);
 		musb_writel(musb->mregs, OTG_INTERFSEL,
 				musb->context.otg_interfsel);
-
-		usb_phy_set_suspend(musb->xceiv, 0);
+		phy_power_on(musb->phy);
 	}
 
 	return 0;
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:43:01 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:13:01 +0530
Subject: [PATCH v10 7/8] usb: phy: omap-usb2: remove *set_suspend* callback
 from omap-usb2
In-Reply-To: <1374842582-13242-1-git-send-email-kishon@ti.com>
References: <1374842582-13242-1-git-send-email-kishon@ti.com>
Message-ID: <1374842582-13242-8-git-send-email-kishon@ti.com>

Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 drivers/phy/phy-omap-usb2.c |   25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 25e0f3c..dec3fab 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -97,29 +97,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
 	return 0;
 }
 
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
-	u32 ret;
-	struct omap_usb *phy = phy_to_omapusb(x);
-
-	if (suspend && !phy->is_suspended) {
-		omap_control_usb_phy_power(phy->control_dev, 0);
-		pm_runtime_put_sync(phy->dev);
-		phy->is_suspended = 1;
-	} else if (!suspend && phy->is_suspended) {
-		ret = pm_runtime_get_sync(phy->dev);
-		if (ret < 0) {
-			dev_err(phy->dev, "get_sync failed with err %d\n",
-									ret);
-			return ret;
-		}
-		omap_control_usb_phy_power(phy->control_dev, 1);
-		phy->is_suspended = 0;
-	}
-
-	return 0;
-}
-
 static int omap_usb_power_off(struct phy *x)
 {
 	struct omap_usb *phy = phy_get_drvdata(x);
@@ -167,7 +144,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
 	phy->phy.dev		= phy->dev;
 	phy->phy.label		= "omap-usb2";
-	phy->phy.set_suspend	= omap_usb2_suspend;
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
@@ -182,7 +158,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	phy->is_suspended	= 1;
 	omap_control_usb_phy_power(phy->control_dev, 0);
 
 	otg->set_host		= omap_usb_set_host;
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:43:02 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:13:02 +0530
Subject: [PATCH v10 8/8] usb: phy: twl4030-usb: remove *set_suspend* and
 *phy_init* ops
In-Reply-To: <1374842582-13242-1-git-send-email-kishon@ti.com>
References: <1374842582-13242-1-git-send-email-kishon@ti.com>
Message-ID: <1374842582-13242-9-git-send-email-kishon@ti.com>

Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 drivers/phy/phy-twl4030-usb.c |   57 ++++++++++-------------------------------
 1 file changed, 13 insertions(+), 44 deletions(-)

diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 494f107..c437211 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -422,25 +422,20 @@ static void twl4030_phy_power(struct twl4030_usb *twl, int on)
 	}
 }
 
-static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
+static int twl4030_phy_power_off(struct phy *phy)
 {
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
 	if (twl->asleep)
-		return;
+		return 0;
 
 	twl4030_phy_power(twl, 0);
 	twl->asleep = 1;
 	dev_dbg(twl->dev, "%s\n", __func__);
-}
-
-static int twl4030_phy_power_off(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	twl4030_phy_suspend(twl, 0);
 	return 0;
 }
 
-static void __twl4030_phy_resume(struct twl4030_usb *twl)
+static void __twl4030_phy_power_on(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
 	twl4030_i2c_access(twl, 1);
@@ -449,11 +444,13 @@ static void __twl4030_phy_resume(struct twl4030_usb *twl)
 		twl4030_i2c_access(twl, 0);
 }
 
-static void twl4030_phy_resume(struct twl4030_usb *twl)
+static int twl4030_phy_power_on(struct phy *phy)
 {
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
 	if (!twl->asleep)
-		return;
-	__twl4030_phy_resume(twl);
+		return 0;
+	__twl4030_phy_power_on(twl);
 	twl->asleep = 0;
 	dev_dbg(twl->dev, "%s\n", __func__);
 
@@ -466,13 +463,6 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 		cancel_delayed_work(&twl->id_workaround_work);
 		schedule_delayed_work(&twl->id_workaround_work, HZ);
 	}
-}
-
-static int twl4030_phy_power_on(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	twl4030_phy_resume(twl);
 	return 0;
 }
 
@@ -604,9 +594,9 @@ static void twl4030_id_workaround_work(struct work_struct *work)
 	}
 }
 
-static int twl4030_usb_phy_init(struct usb_phy *phy)
+static int twl4030_phy_init(struct phy *phy)
 {
-	struct twl4030_usb *twl = phy_to_twl(phy);
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
 	enum omap_musb_vbus_id_status status;
 
 	/*
@@ -621,32 +611,13 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 
 	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
 		omap_musb_mailbox(twl->linkstat);
-		twl4030_phy_resume(twl);
+		twl4030_phy_power_on(phy);
 	}
 
 	sysfs_notify(&twl->dev->kobj, NULL, "vbus");
 	return 0;
 }
 
-static int twl4030_phy_init(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	return twl4030_usb_phy_init(&twl->phy);
-}
-
-static int twl4030_set_suspend(struct usb_phy *x, int suspend)
-{
-	struct twl4030_usb *twl = phy_to_twl(x);
-
-	if (suspend)
-		twl4030_phy_suspend(twl, 1);
-	else
-		twl4030_phy_resume(twl);
-
-	return 0;
-}
-
 static int twl4030_set_peripheral(struct usb_otg *otg,
 					struct usb_gadget *gadget)
 {
@@ -719,8 +690,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	twl->phy.label		= "twl4030";
 	twl->phy.otg		= otg;
 	twl->phy.type		= USB_PHY_TYPE_USB2;
-	twl->phy.set_suspend	= twl4030_set_suspend;
-	twl->phy.init		= twl4030_usb_phy_init;
 
 	otg->phy		= &twl->phy;
 	otg->set_host		= twl4030_set_host;
-- 
1.7.10.4



From maxime.ripard at free-electrons.com  Fri Jul 26 08:48:28 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 26 Jul 2013 14:48:28 +0200
Subject: [PATCH 05/10] ARM: sunxi: Add Allwinner A31 DTSI
In-Reply-To: <20130726123747.7c88d976@skate>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374618312-19001-6-git-send-email-maxime.ripard@free-electrons.com>
 <20130726123747.7c88d976@skate>
Message-ID: <20130726124828.GD3056@lukather>

Hi Thomas,

On Fri, Jul 26, 2013 at 12:37:47PM +0200, Thomas Petazzoni wrote:
> Dear Maxime Ripard,
> 
> On Wed, 24 Jul 2013 00:25:07 +0200, Maxime Ripard wrote:
> 
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 641b3c9..1482533 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -210,7 +210,8 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
> >  	sun4i-a10-mini-xplus.dtb \
> >  	sun4i-a10-hackberry.dtb \
> >  	sun5i-a10s-olinuxino-micro.dtb \
> > -	sun5i-a13-olinuxino.dtb
> > +	sun5i-a13-olinuxino.dtb \
> > +	sun6i-a31-colombus.dtb
> 
> Wrong patch for this chunk. The colombus .dts is added in PATCH 06/10.

Indeed, it was already pointed out by Emilio.

> > +	soc at 01c20000 {
> > +		compatible = "simple-bus";
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		reg = <0x01c20000 0x300000>;
> > +		ranges;
> 
> Just curious, what are these reg and ranges properties for?

The fdt parsing code seem to be needing a ranges property, since it
prints a warning if it's not set.

For the reg one, honestly, I don't have a strong argument on this. The
platforms I'm used to did it that way, so did I. The documentation of
simple-bus doesn't seem to mention it, so maybe it's not needed at all.

I find it pretty convenient though to have the size and range where the
different IPs are located in.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130726/b80465c2/attachment.sig>

From jonas.jensen at gmail.com  Fri Jul 26 08:48:10 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Fri, 26 Jul 2013 14:48:10 +0200
Subject: [PATCH v2] net: Add MOXA ART SoCs ethernet driver
In-Reply-To: <1374140806-12485-1-git-send-email-jonas.jensen@gmail.com>
References: <1374140806-12485-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1374842890-20735-1-git-send-email-jonas.jensen@gmail.com>

The MOXA UC-711X hardware(s) has an ethernet controller that seem to be
developed internally. The IC used is "RTL8201CP".

Since there is no public documentation, this driver is mostly the one
published by MOXA that has been heavily cleaned up / ported from linux 2.6.9.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    According to issues pointed out by Florian:
    
    One more thing is now known about the controller:
    
    It requires descriptors to be located in continuous memory.
    
    .. which is why the driver allocates buffers with kmalloc,
    and memory is reused in RX path to build new skb:s (build_skb),
    before giving packet to stack.
    
    Changes since v1:
    
    1. use NAPI RX polling
    2. preallocate SKBs / use build_skb
    3. increment stats only on success
    4. return NETDEV_TX_BUSY on TX ring busy
    5. use dma_map_single / set descriptors (no memcpy)
    6. free skb:s, unmap DMA on transfer complete
    7. general code cleanup
    
    Applies to next-20130726

 .../devicetree/bindings/net/moxa,moxart-mac.txt    |  25 +
 drivers/net/ethernet/Kconfig                       |   1 +
 drivers/net/ethernet/Makefile                      |   1 +
 drivers/net/ethernet/moxa/Kconfig                  |  30 ++
 drivers/net/ethernet/moxa/Makefile                 |   7 +
 drivers/net/ethernet/moxa/moxart_ether.c           | 586 +++++++++++++++++++++
 drivers/net/ethernet/moxa/moxart_ether.h           | 513 ++++++++++++++++++
 7 files changed, 1163 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
 create mode 100644 drivers/net/ethernet/moxa/Kconfig
 create mode 100644 drivers/net/ethernet/moxa/Makefile
 create mode 100644 drivers/net/ethernet/moxa/moxart_ether.c
 create mode 100644 drivers/net/ethernet/moxa/moxart_ether.h

diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
new file mode 100644
index 0000000..1fc44ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
@@ -0,0 +1,25 @@
+MOXA ART Ethernet Controller
+
+Required properties:
+
+- compatible : Must be "moxa,moxart-mac"
+- reg : Should contain registers location and length
+  index 0 : main register
+  index 1 : mac address (stored on flash)
+- interrupts : Should contain the mac interrupt number
+
+Example:
+
+	mac0: mac at 90900000 {
+		compatible = "moxa,moxart-mac";
+		reg =	<0x90900000 0x100>,
+			<0x80000050 0x6>;
+		interrupts = <25 0>;
+	};
+
+	mac1: mac at 92000000 {
+		compatible = "moxa,moxart-mac";
+		reg =	<0x92000000 0x100>,
+			<0x80000056 0x6>;
+		interrupts = <27 0>;
+	};
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 2037080..506b024 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -90,6 +90,7 @@ source "drivers/net/ethernet/marvell/Kconfig"
 source "drivers/net/ethernet/mellanox/Kconfig"
 source "drivers/net/ethernet/micrel/Kconfig"
 source "drivers/net/ethernet/microchip/Kconfig"
+source "drivers/net/ethernet/moxa/Kconfig"
 source "drivers/net/ethernet/myricom/Kconfig"
 
 config FEALNX
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 390bd0b..c0b8789 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_NET_VENDOR_MARVELL) += marvell/
 obj-$(CONFIG_NET_VENDOR_MELLANOX) += mellanox/
 obj-$(CONFIG_NET_VENDOR_MICREL) += micrel/
 obj-$(CONFIG_NET_VENDOR_MICROCHIP) += microchip/
+obj-$(CONFIG_NET_VENDOR_MOXART) += moxa/
 obj-$(CONFIG_NET_VENDOR_MYRI) += myricom/
 obj-$(CONFIG_FEALNX) += fealnx.o
 obj-$(CONFIG_NET_VENDOR_NATSEMI) += natsemi/
diff --git a/drivers/net/ethernet/moxa/Kconfig b/drivers/net/ethernet/moxa/Kconfig
new file mode 100644
index 0000000..1731e05
--- /dev/null
+++ b/drivers/net/ethernet/moxa/Kconfig
@@ -0,0 +1,30 @@
+#
+# MOXART device configuration
+#
+
+config NET_VENDOR_MOXART
+	bool "MOXA ART devices"
+	default y
+	depends on (ARM && ARCH_MOXART)
+	---help---
+	  If you have a network (Ethernet) card belonging to this class, say Y
+	  and read the Ethernet-HOWTO, available from
+	  <http://www.tldp.org/docs.html#howto>.
+
+	  Note that the answer to this question doesn't directly affect the
+	  kernel: saying N will just cause the configurator to skip all
+	  the questions about MOXA ART devices. If you say Y, you will be asked
+	  for your specific card in the following questions.
+
+if NET_VENDOR_MOXART
+
+config ARM_MOXART_ETHER
+	tristate "MOXART Ethernet support"
+	depends on ARM && ARCH_MOXART
+	select NET_CORE
+	---help---
+	  If you wish to compile a kernel for a hardware with MOXA ART SoC and
+	  want to use the internal ethernet then you should answer Y to this.
+
+
+endif # NET_VENDOR_MOXART
diff --git a/drivers/net/ethernet/moxa/Makefile b/drivers/net/ethernet/moxa/Makefile
new file mode 100644
index 0000000..e182981
--- /dev/null
+++ b/drivers/net/ethernet/moxa/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for the MOXART network device drivers.
+#
+
+obj-$(CONFIG_ARM_MOXART_ETHER) += moxart_ether.o
+
+CFLAGS_moxart_ether.o := -DDEBUG
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
new file mode 100644
index 0000000..af73c9c
--- /dev/null
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -0,0 +1,586 @@
+/* MOXA ART Ethernet (RTL8201CP) driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/skbuff.h>
+#include <linux/dma-mapping.h>
+#include <linux/ethtool.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/crc32.h>
+#include <linux/crc32c.h>
+#include <linux/dma-mapping.h>
+
+#include "moxart_ether.h"
+
+static inline unsigned long moxart_emac_read(struct net_device *ndev,
+					     unsigned int reg)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	return readl(priv->base + reg);
+}
+
+static inline void moxart_emac_write(struct net_device *ndev,
+				     unsigned int reg, unsigned long value)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	writel(value, priv->base + reg);
+}
+
+static void moxart_update_mac_address(struct net_device *ndev)
+{
+	moxart_emac_write(ndev, MAC_MADR_REG_OFFSET,
+			  ((ndev->dev_addr[0] << 8) | (ndev->dev_addr[1])));
+	moxart_emac_write(ndev, MAC_MADR_REG_OFFSET + 4,
+			  ((ndev->dev_addr[2] << 24) |
+			   (ndev->dev_addr[3] << 16) |
+			   (ndev->dev_addr[4] << 8) |
+			   (ndev->dev_addr[5])));
+}
+
+static int moxart_set_mac_address(struct net_device *ndev, void *addr)
+{
+	struct sockaddr *address = addr;
+
+	if (!is_valid_ether_addr(address->sa_data))
+		return -EADDRNOTAVAIL;
+
+	memcpy(ndev->dev_addr, address->sa_data, ndev->addr_len);
+	moxart_update_mac_address(ndev);
+
+	return 0;
+}
+
+static void moxart_mac_free_memory(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	int i;
+
+	for (i = 0; i < RX_DESC_NUM; i++)
+		dma_unmap_single(&ndev->dev, priv->rx_mapping[i],
+				 priv->rx_buf_size, DMA_FROM_DEVICE);
+
+	if (priv->tx_desc_base)
+		dma_free_coherent(NULL, sizeof(struct tx_desc_t)*TX_DESC_NUM,
+				  priv->tx_desc_base, priv->tx_base);
+	if (priv->rx_desc_base)
+		dma_free_coherent(NULL, sizeof(struct rx_desc_t)*RX_DESC_NUM,
+				  priv->rx_desc_base, priv->rx_base);
+
+	kfree(priv->tx_buf_base);
+	kfree(priv->rx_buf_base);
+}
+
+static void moxart_mac_reset(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	writel(SW_RST, priv->base + MACCR_REG_OFFSET);
+	while (readl(priv->base + MACCR_REG_OFFSET) & SW_RST)
+		mdelay(10);
+
+	writel(0, priv->base + IMR_REG_OFFSET);
+
+	priv->reg_maccr = RX_BROADPKT | FULLDUP | CRC_APD | RX_FTL;
+}
+
+static void moxart_mac_enable(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	writel(0x00001010, priv->base + ITC_REG_OFFSET);
+	writel(0x00000001, priv->base + APTC_REG_OFFSET);
+	writel(0x00000390, priv->base + DBLAC_REG_OFFSET);
+
+	priv->reg_imr |= (RPKT_FINISH_M | XPKT_FINISH_M);
+	writel(priv->reg_imr, priv->base + IMR_REG_OFFSET);
+
+	priv->reg_maccr |= (RCV_EN | XMT_EN | RDMA_EN | XDMA_EN);
+	writel(priv->reg_maccr, priv->base + MACCR_REG_OFFSET);
+}
+
+static void moxart_mac_setup_desc_ring(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	struct tx_desc_t *txdesc;
+	struct rx_desc_t *rxdesc;
+	int i;
+
+	for (i = 0; i < TX_DESC_NUM; i++) {
+		txdesc = &priv->tx_desc_base[i];
+		memset(txdesc, 0, sizeof(struct tx_desc_t));
+
+		priv->tx_buf[i] = priv->tx_buf_base + priv->tx_buf_size * i;
+	}
+	priv->tx_desc_base[TX_DESC_NUM - 1].txdes1.ubit.edotr = 1;
+	priv->tx_head = 0;
+	priv->tx_tail = 0;
+
+	for (i = 0; i < RX_DESC_NUM; i++) {
+		rxdesc = &priv->rx_desc_base[i];
+		memset(rxdesc, 0, sizeof(struct rx_desc_t));
+		rxdesc->rxdes0.ubit.rx_dma_own = 1;
+		rxdesc->rxdes1.ubit.rx_buf_size = RX_BUF_SIZE;
+
+		priv->rx_buf[i] = priv->rx_buf_base + priv->rx_buf_size * i;
+		priv->rx_mapping[i] = dma_map_single(&ndev->dev,
+						     priv->rx_buf[i],
+						     priv->rx_buf_size,
+						     DMA_FROM_DEVICE);
+		if (dma_mapping_error(&ndev->dev, priv->rx_mapping[i]))
+			netdev_err(ndev, "DMA mapping error\n");
+
+		rxdesc->rxdes2.addr_phys = priv->rx_mapping[i];
+		rxdesc->rxdes2.addr_virt = priv->rx_buf[i];
+	}
+	priv->rx_desc_base[RX_DESC_NUM - 1].rxdes1.ubit.edorr = 1;
+	priv->rx_head = 0;
+
+	/* reset the MAC controler TX/RX desciptor base address */
+	writel(priv->tx_base, priv->base + TXR_BADR_REG_OFFSET);
+	writel(priv->rx_base, priv->base + RXR_BADR_REG_OFFSET);
+}
+
+static int moxart_mac_open(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	if (!is_valid_ether_addr(ndev->dev_addr))
+		return -EADDRNOTAVAIL;
+
+	napi_enable(&priv->napi);
+
+	moxart_mac_reset(ndev);
+	moxart_update_mac_address(ndev);
+	moxart_mac_setup_desc_ring(ndev);
+	moxart_mac_enable(ndev);
+	netif_start_queue(ndev);
+
+	netdev_dbg(ndev, "%s: IMR=0x%x, MACCR=0x%x\n",
+		   __func__, readl(priv->base + IMR_REG_OFFSET),
+		   readl(priv->base + MACCR_REG_OFFSET));
+
+	return 0;
+}
+
+static int moxart_mac_stop(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	napi_disable(&priv->napi);
+
+	netif_stop_queue(ndev);
+
+	/* disable all interrupts */
+	writel(0, priv->base + IMR_REG_OFFSET);
+
+	/* disable all functions */
+	writel(0, priv->base + MACCR_REG_OFFSET);
+
+	return 0;
+}
+
+static int moxart_rx_poll(struct napi_struct *napi, int budget)
+{
+	struct moxart_mac_priv_t *priv = container_of(napi,
+						      struct moxart_mac_priv_t,
+						      napi);
+	struct net_device *ndev = priv->ndev;
+	struct rx_desc_t *rxdesc;
+	struct sk_buff *skb;
+	unsigned int ui, len;
+	int rx_head = priv->rx_head;
+	int rx = 0;
+
+	while (1) {
+		rxdesc = &priv->rx_desc_base[rx_head];
+		ui = rxdesc->rxdes0.ui;
+
+		if (ui & RXDMA_OWN)
+			break;
+
+		if (ui & (RX_ERR | CRC_ERR | FTL | RUNT | RX_ODD_NB)) {
+			netdev_err(ndev, "packet error\n");
+			priv->stats.rx_dropped++;
+			priv->stats.rx_errors++;
+			continue;
+		}
+
+		len = ui & RFL_MASK;
+
+		if (len > RX_BUF_SIZE)
+			len = RX_BUF_SIZE;
+
+		skb = build_skb(priv->rx_buf[rx_head], priv->rx_buf_size);
+		if (unlikely(!skb)) {
+			netdev_err(ndev, "build_skb failed\n");
+			priv->stats.rx_dropped++;
+		}
+
+		skb_put(skb, len);
+		skb->protocol = eth_type_trans(skb, ndev);
+		napi_gro_receive(&priv->napi, skb);
+		rx++;
+
+		ndev->last_rx = jiffies;
+		priv->stats.rx_packets++;
+		priv->stats.rx_bytes += len;
+		if (ui & MULTICAST_RXDES0)
+			priv->stats.multicast++;
+
+		rxdesc->rxdes0.ui = RXDMA_OWN;
+
+		rx_head = RX_NEXT(rx_head);
+		priv->rx_head = rx_head;
+
+		if (rx >= budget)
+			break;
+	}
+
+	if (rx < budget) {
+		napi_gro_flush(napi, false);
+		__napi_complete(napi);
+	}
+
+	priv->reg_imr |= RPKT_FINISH_M;
+	writel(priv->reg_imr, priv->base + IMR_REG_OFFSET);
+
+	return rx;
+}
+
+static void moxart_tx_finished(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	unsigned tx_head = priv->tx_head;
+	unsigned tx_tail = priv->tx_tail;
+
+	while (tx_tail != tx_head) {
+		dma_unmap_single(&ndev->dev, priv->tx_mapping[tx_tail],
+				 priv->tx_len[tx_tail], DMA_TO_DEVICE);
+		dev_kfree_skb_irq(priv->tx_skb[tx_tail]);
+
+		priv->stats.tx_packets++;
+		priv->stats.tx_bytes += priv->tx_skb[tx_tail]->len;
+
+		priv->tx_skb[tx_tail] = NULL;
+
+		tx_tail = TX_NEXT(tx_tail);
+	}
+	priv->tx_tail = tx_tail;
+}
+
+static irqreturn_t moxart_mac_interrupt(int irq, void *dev_id)
+{
+	struct net_device *ndev = (struct net_device *) dev_id;
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	unsigned int ists = readl(priv->base + ISR_REG_OFFSET);
+
+	if (ists & XPKT_OK_INT_STS)
+		moxart_tx_finished(ndev);
+
+	if (ists & RPKT_FINISH) {
+		if (napi_schedule_prep(&priv->napi)) {
+			priv->reg_imr &= ~RPKT_FINISH_M;
+			writel(priv->reg_imr, priv->base + IMR_REG_OFFSET);
+			__napi_schedule(&priv->napi);
+		}
+	}
+
+	return IRQ_HANDLED;
+}
+
+static int moxart_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	struct tx_desc_t *txdesc;
+	unsigned int len;
+	unsigned int tx_head = priv->tx_head;
+
+	spin_lock_irq(&priv->txlock);
+
+	txdesc = &priv->tx_desc_base[tx_head];
+
+	if (txdesc->txdes0.ubit.tx_dma_own) {
+		netdev_err(ndev, "no TX space for packet\n");
+		priv->stats.tx_dropped++;
+		return NETDEV_TX_BUSY;
+	}
+
+	len = skb->len > TX_BUF_SIZE ? TX_BUF_SIZE : skb->len;
+
+	priv->tx_mapping[tx_head] = dma_map_single(&ndev->dev, skb->data,
+						   len, DMA_TO_DEVICE);
+	if (dma_mapping_error(&ndev->dev, priv->tx_mapping[tx_head])) {
+		netdev_err(ndev, "DMA mapping error\n");
+		return NETDEV_TX_BUSY;
+	}
+
+	priv->tx_len[tx_head] = len;
+	priv->tx_skb[tx_head] = skb;
+
+	txdesc->txdes2.addr_phys = priv->tx_mapping[tx_head];
+	txdesc->txdes2.addr_virt = skb->data;
+
+	if (skb->len < ETH_ZLEN) {
+		memset(&txdesc->txdes2.addr_virt[skb->len],
+		       0, ETH_ZLEN - skb->len);
+		len = ETH_ZLEN;
+	}
+
+	txdesc->txdes1.ubit.lts = 1;
+	txdesc->txdes1.ubit.fts = 1;
+	txdesc->txdes1.ubit.tx2_fic = 0;
+	txdesc->txdes1.ubit.tx_ic = 0;
+	txdesc->txdes1.ubit.tx_buf_size = len;
+	txdesc->txdes0.ui = TXDMA_OWN;
+
+	/* start to send packet */
+	writel(0xffffffff, priv->base + TXPD_REG_OFFSET);
+
+	priv->tx_head = TX_NEXT(tx_head);
+
+	ndev->trans_start = jiffies;
+
+	spin_unlock_irq(&priv->txlock);
+
+	return NETDEV_TX_OK;
+}
+
+static struct net_device_stats *moxart_mac_get_stats(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	return &priv->stats;
+}
+
+static void moxart_mac_setmulticast(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	struct netdev_hw_addr *ha;
+	int crc_val;
+
+	netdev_for_each_mc_addr(ha, ndev) {
+		crc_val = crc32_le(~0, ha->addr, ETH_ALEN);
+		crc_val = (crc_val >> 26) & 0x3f;
+		if (crc_val >= 32) {
+			writel(readl(priv->base + MATH1_REG_OFFSET) |
+			       (1UL << (crc_val - 32)),
+			       priv->base + MATH1_REG_OFFSET);
+		} else {
+			writel(readl(priv->base + MATH0_REG_OFFSET) |
+			       (1UL << crc_val),
+			       priv->base + MATH0_REG_OFFSET);
+		}
+	}
+}
+
+static void moxart_mac_set_rx_mode(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	spin_lock_irq(&priv->txlock);
+
+	(ndev->flags & IFF_PROMISC) ? (priv->reg_maccr |= RCV_ALL) :
+				      (priv->reg_maccr &= ~RCV_ALL);
+
+	(ndev->flags & IFF_ALLMULTI) ? (priv->reg_maccr |= RX_MULTIPKT) :
+				       (priv->reg_maccr &= ~RX_MULTIPKT);
+
+	if ((ndev->flags & IFF_MULTICAST) && netdev_mc_count(ndev)) {
+		priv->reg_maccr |= HT_MULTI_EN;
+		moxart_mac_setmulticast(ndev);
+	} else {
+		priv->reg_maccr &= ~HT_MULTI_EN;
+	}
+
+	writel(priv->reg_maccr, priv->base + MACCR_REG_OFFSET);
+
+	spin_unlock_irq(&priv->txlock);
+}
+
+static struct net_device_ops moxart_netdev_ops = {
+	.ndo_open		= moxart_mac_open,
+	.ndo_stop		= moxart_mac_stop,
+	.ndo_start_xmit		= moxart_mac_start_xmit,
+	.ndo_get_stats		= moxart_mac_get_stats,
+	.ndo_set_rx_mode	= moxart_mac_set_rx_mode,
+	.ndo_set_mac_address	= moxart_set_mac_address,
+	.ndo_validate_addr	= eth_validate_addr,
+	.ndo_change_mtu		= eth_change_mtu,
+};
+
+static void moxart_get_mac_address(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	int i;
+
+	for (i = 0; i <= 5; i++)
+		ndev->dev_addr[i] = readb(priv->flash_base + i);
+}
+
+static int moxart_mac_probe(struct platform_device *pdev)
+{
+	struct device *p_dev = &pdev->dev;
+	struct device_node *node = p_dev->of_node;
+	struct net_device *ndev;
+	struct moxart_mac_priv_t *priv;
+	struct resource *res;
+	unsigned int irq;
+	void *tmp;
+
+	ndev = alloc_etherdev(sizeof(struct moxart_mac_priv_t));
+	if (!ndev)
+		return -ENOMEM;
+
+	irq = irq_of_parse_and_map(node, 0);
+
+	priv = netdev_priv(ndev);
+	priv->ndev = ndev;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	ndev->base_addr = res->start;
+	priv->base = devm_ioremap_resource(p_dev, res);
+	if (IS_ERR(priv->base)) {
+		dev_err(p_dev, "devm_ioremap_resource failed\n");
+		goto init_fail;
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+
+	/* the flash driver (physmap_of) requests the same region
+	 * so use ioremap instead of devm_ioremap_resource
+	 */
+	priv->flash_base = ioremap(res->start, resource_size(res));
+	if (IS_ERR(priv->flash_base)) {
+		dev_err(p_dev, "devm_ioremap_resource failed\n");
+		goto init_fail;
+	}
+
+	spin_lock_init(&priv->txlock);
+
+	priv->tx_buf_size = TX_BUF_SIZE;
+	priv->rx_buf_size = RX_BUF_SIZE +
+			    SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+
+	tmp = dma_alloc_coherent(NULL, sizeof(struct tx_desc_t) * TX_DESC_NUM,
+				 &priv->tx_base, GFP_DMA | GFP_KERNEL);
+	priv->tx_desc_base = (struct tx_desc_t *) tmp;
+	if (priv->tx_desc_base == NULL) {
+		netdev_err(ndev, "TX descriptor alloc failed\n");
+		goto init_fail;
+	}
+
+	tmp = dma_alloc_coherent(NULL, sizeof(struct rx_desc_t) * RX_DESC_NUM,
+				 &priv->rx_base, GFP_DMA | GFP_KERNEL);
+	priv->rx_desc_base = (struct rx_desc_t *) tmp;
+	if (priv->rx_desc_base == NULL) {
+		netdev_err(ndev, "RX descriptor alloc failed\n");
+		goto init_fail;
+	}
+
+	priv->tx_buf_base = kmalloc(priv->tx_buf_size * TX_DESC_NUM,
+				    GFP_ATOMIC);
+	if (!priv->tx_buf_base) {
+		netdev_err(ndev, "TX buffer alloc failed\n");
+		goto init_fail;
+	}
+
+	priv->rx_buf_base = kmalloc(priv->rx_buf_size * RX_DESC_NUM,
+				    GFP_ATOMIC);
+	if (!priv->rx_buf_base) {
+		netdev_err(ndev, "RX buffer alloc failed\n");
+		goto init_fail;
+	}
+
+	platform_set_drvdata(pdev, ndev);
+
+	ether_setup(ndev);
+	ndev->netdev_ops = &moxart_netdev_ops;
+	netif_napi_add(ndev, &priv->napi, moxart_rx_poll, RX_DESC_NUM);
+	ndev->priv_flags |= IFF_UNICAST_FLT;
+
+	SET_NETDEV_DEV(ndev, &pdev->dev);
+
+	moxart_get_mac_address(ndev);
+	moxart_update_mac_address(ndev);
+
+	if (register_netdev(ndev)) {
+		free_netdev(ndev);
+		goto init_fail;
+	}
+
+	ndev->irq = irq;
+
+	if (devm_request_irq(p_dev, irq, moxart_mac_interrupt, 0,
+			     pdev->name, ndev)) {
+		netdev_err(ndev, "devm_request_irq failed\n");
+		free_netdev(ndev);
+		return -EBUSY;
+	}
+
+	netdev_dbg(ndev, "%s: IRQ=%d address=%02x:%02x:%02x:%02x:%02x:%02x\n",
+		   __func__, ndev->irq,
+		   ndev->dev_addr[0], ndev->dev_addr[1], ndev->dev_addr[2],
+		   ndev->dev_addr[3], ndev->dev_addr[4], ndev->dev_addr[5]);
+
+	return 0;
+
+init_fail:
+	netdev_err(ndev, "%s: init failed\n", __func__);
+	moxart_mac_free_memory(ndev);
+
+	return -ENOMEM;
+}
+
+static int moxart_remove(struct platform_device *pdev)
+{
+	struct net_device *ndev = platform_get_drvdata(pdev);
+
+	unregister_netdev(ndev);
+	free_irq(ndev->irq, ndev);
+	moxart_mac_free_memory(ndev);
+	platform_set_drvdata(pdev, NULL);
+	free_netdev(ndev);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_mac_match[] = {
+	{ .compatible = "moxa,moxart-mac" },
+	{ }
+};
+
+struct __initdata platform_driver moxart_mac_driver = {
+	.probe	= moxart_mac_probe,
+	.remove	= moxart_remove,
+	.driver	= {
+		.name		= "moxart-ethernet",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_mac_match,
+	},
+};
+module_platform_driver(moxart_mac_driver);
+
+MODULE_DESCRIPTION("MOXART RTL8201CP Ethernet driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
+
diff --git a/drivers/net/ethernet/moxa/moxart_ether.h b/drivers/net/ethernet/moxa/moxart_ether.h
new file mode 100644
index 0000000..790b6a9
--- /dev/null
+++ b/drivers/net/ethernet/moxa/moxart_ether.h
@@ -0,0 +1,513 @@
+/* MOXA ART Ethernet (RTL8201CP) driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _MOXART_ETHERNET_H
+#define _MOXART_ETHERNET_H
+
+#define TX_DESC_NUM		64
+#define TX_DESC_NUM_MASK	(TX_DESC_NUM-1)
+#define TX_NEXT(N)		(((N) + 1) & (TX_DESC_NUM_MASK))
+#define TX_BUF_SIZE		1600
+
+#define RX_DESC_NUM		64
+#define RX_DESC_NUM_MASK	(RX_DESC_NUM-1)
+#define RX_NEXT(N)		(((N) + 1) & (RX_DESC_NUM_MASK))
+#define RX_BUF_SIZE		1600
+
+struct tx_desc_t {
+	union {
+#define TXDMA_OWN		BIT(31)
+#define TXPKT_EXSCOL		BIT(1)
+#define TXPKT_LATECOL		BIT(0)
+		unsigned int ui;
+
+		struct {
+			/* is aborted due to late collision */
+			unsigned int tx_pkt_late_col:1;
+
+			/* is aborted after 16 collisions */
+			unsigned int rx_pkt_exs_col:1;
+
+			unsigned int reserved1:29;
+
+			/* is owned by the MAC controller */
+			unsigned int tx_dma_own:1;
+		} ubit;
+	} txdes0;
+
+	union {
+#define EDOTR			BIT(31)
+#define TXIC			BIT(30)
+#define TX2FIC			BIT(29)
+#define FTS			BIT(28)
+#define LTS			BIT(27)
+#define TXBUF_SIZE_MASK		0x7ff
+#define TXBUF_SIZE_MAX		(TXBUF_SIZE_MASK+1)
+		unsigned int ui;
+
+		struct {
+			/* transmit buffer size in byte */
+			unsigned int tx_buf_size:11;
+
+			unsigned int reserved2:16;
+
+			/* is the last descriptor of a Tx packet */
+			unsigned int lts:1;
+
+			/* is the first descriptor of a Tx packet */
+			unsigned int fts:1;
+
+			/* transmit to FIFO interrupt on completion */
+			unsigned int tx2_fic:1;
+
+			/* transmit interrupt on completion */
+			unsigned int tx_ic:1;
+
+			/* end descriptor of transmit ring */
+			unsigned int edotr:1;
+		} ubit;
+	} txdes1;
+
+	struct {
+		/* transmit buffer physical base address */
+		unsigned int addr_phys;
+
+		/* transmit buffer virtual base address */
+		unsigned char *addr_virt;
+	} txdes2;
+};
+
+struct rx_desc_t {
+	union {
+#define RXDMA_OWN		BIT(31)
+#define FRS			BIT(29)
+#define LRS			BIT(28)
+#define RX_ODD_NB		BIT(22)
+#define RUNT			BIT(21)
+#define FTL			BIT(20)
+#define CRC_ERR			BIT(19)
+#define RX_ERR			BIT(18)
+#define BROADCAST_RXDES0	BIT(17)
+#define MULTICAST_RXDES0	BIT(16)
+#define RFL_MASK		0x7ff
+#define RFL_MAX			(RFL_MASK+1)
+		unsigned int ui;
+
+		struct {
+			/* receive frame length */
+			unsigned int recv_frame_len:11;
+			unsigned int reserved1:5;
+
+			/* multicast frame */
+			unsigned int multicast:1;
+
+			/* broadcast frame */
+			unsigned int broadcast:1;
+			unsigned int rx_err:1;		/* receive error */
+			unsigned int crc_err:1;		/* CRC error */
+			unsigned int ftl:1;		/* frame too long */
+
+			/* runt packet, less than 64 bytes */
+			unsigned int runt:1;
+
+			/* receive odd nibbles */
+			unsigned int rx_odd_nb:1;
+			unsigned int reserved2:5;
+
+			/* last receive segment descriptor */
+			unsigned int lrs:1;
+
+			/* first receive segment descriptor */
+			unsigned int frs:1;
+
+			unsigned int reserved3:1;
+			unsigned int rx_dma_own:1;	/* RXDMA onwership */
+		} ubit;
+	} rxdes0;
+
+	union {
+#define EDORR			BIT(31)
+#define RXBUF_SIZE_MASK		0x7ff
+#define RXBUF_SIZE_MAX		(RXBUF_SIZE_MASK+1)
+		unsigned int ui;
+
+		struct {
+			/* receive buffer size */
+			unsigned int rx_buf_size:11;
+
+			unsigned int reserved4:20;
+
+			/* end descriptor of receive ring */
+			unsigned int edorr:1;
+		} ubit;
+	} rxdes1;
+
+	struct {
+		/* receive buffer physical base address */
+		unsigned int addr_phys;
+
+		/* receive buffer virtual base address */
+		unsigned char *addr_virt;
+	} rxdes2;
+};
+
+struct mac_control_reg_t {
+
+/* RXDMA has received packets into RX buffer successfully */
+#define RPKT_FINISH		BIT(0)
+/* receive buffer unavailable */
+#define NORXBUF			BIT(1)
+/* TXDMA has moved data into the TX FIFO */
+#define XPKT_FINISH		BIT(2)
+/* transmit buffer unavailable */
+#define NOTXBUF			BIT(3)
+/* packets transmitted to ethernet successfully */
+#define XPKT_OK_INT_STS		BIT(4)
+/* packets transmitted to ethernet lost due to late
+ * collision or excessive collision
+ */
+#define XPKT_LOST_INT_STS	BIT(5)
+/* packets received into RX FIFO successfully */
+#define RPKT_SAV		BIT(6)
+/* received packet lost due to RX FIFO full */
+#define RPKT_LOST_INT_STS	BIT(7)
+#define AHB_ERR			BIT(8)		/* AHB error */
+#define PHYSTS_CHG		BIT(9)		/* PHY link status change */
+	unsigned int isr;			/* interrupt status, 0x0 */
+
+#define RPKT_FINISH_M		BIT(0)		/* interrupt mask of ISR[0] */
+#define NORXBUF_M		BIT(1)		/* interrupt mask of ISR[1] */
+#define XPKT_FINISH_M		BIT(2)		/* interrupt mask of ISR[2] */
+#define NOTXBUF_M		BIT(3)		/* interrupt mask of ISR[3] */
+#define XPKT_OK_M		BIT(4)		/* interrupt mask of ISR[4] */
+#define XPKT_LOST_M		BIT(5)		/* interrupt mask of ISR[5] */
+#define RPKT_SAV_M		BIT(6)		/* interrupt mask of ISR[6] */
+#define RPKT_LOST_M		BIT(7)		/* interrupt mask of ISR[7] */
+#define AHB_ERR_M		BIT(8)		/* interrupt mask of ISR[8] */
+#define PHYSTS_CHG_M		BIT(9)		/* interrupt mask of ISR[9] */
+	unsigned int imr;			/* interrupt mask, 0x4 */
+
+/* the most significant 2 bytes of MAC address */
+#define MAC_MADR_MASK		0xffff
+	/* MAC most significant address, 0x8 */
+	unsigned int mac_madr;
+
+	/* MAC least significant address, 0xc */
+	unsigned int mac_ldar;
+
+	/* multicast address hash table 0, 0x10 */
+	unsigned int matht0;
+
+	/* multicast address hash table 1, 0x14 */
+	unsigned int matht1;
+
+	/* transmit poll demand, 0x18 */
+	unsigned int txpd;
+
+	/* receive poll demand, 0x1c */
+	unsigned int rxpd;
+
+	/* transmit ring base address, 0x20 */
+	unsigned int txr_badr;
+
+	/* receive ring base address, 0x24 */
+	unsigned int rxr_badr;
+
+/* defines the period of TX cycle time */
+#define TXINT_TIME_SEL		BIT(15)
+#define TXINT_THR_MASK		0x7000
+#define TXINT_CNT_MASK		0xf00
+/* defines the period of RX cycle time */
+#define RXINT_TIME_SEL		BIT(7)
+#define RXINT_THR_MASK		0x70
+#define RXINT_CNT_MASK		0xF
+	/* interrupt timer control, 0x28 */
+	unsigned int itc;
+
+/* defines the period of TX poll time */
+#define TXPOLL_TIME_SEL		BIT(12)
+#define TXPOLL_CNT_MASK		0xf00
+#define TXPOLL_CNT_SHIFT_BIT	8
+/* defines the period of RX poll time */
+#define RXPOLL_TIME_SEL		BIT(4)
+#define RXPOLL_CNT_MASK		0xF
+#define RXPOLL_CNT_SHIFT_BIT	0
+	/* automatic polling timer control, 0x2c */
+	unsigned int aptc;
+
+/* enable RX FIFO threshold arbitration */
+#define RX_THR_EN		BIT(9)
+#define RXFIFO_HTHR_MASK	0x1c0
+#define RXFIFO_LTHR_MASK	0x38
+/* use INCR16 burst command in AHB bus */
+#define INCR16_EN		BIT(2)
+/* use INCR8 burst command in AHB bus */
+#define INCR8_EN		BIT(1)
+/* use INCR4 burst command in AHB bus */
+#define INCR4_EN		BIT(0)
+	/* DMA burst length and arbitration control, 0x30 */
+	unsigned int dblac;
+
+	unsigned int reserved1[21];		/* 0x34 - 0x84 */
+
+#define RX_BROADPKT		BIT(17)		/* receive boradcast packet */
+/* receive all multicast packet */
+#define RX_MULTIPKT		BIT(16)
+#define FULLDUP			BIT(15)		/* full duplex */
+/* append CRC to transmitted packet */
+#define CRC_APD			BIT(14)
+/* do not check incoming packet's destination address */
+#define RCV_ALL			BIT(12)
+/* store incoming packet even if its length is great than 1518 bytes */
+#define RX_FTL			BIT(11)
+/* store incoming packet even if its length is less than 64 bytes */
+#define RX_RUNT			BIT(10)
+/* enable storing incoming packet if the packet passes hash table
+ * address filtering and is a multicast packet
+ */
+#define HT_MULTI_EN		BIT(9)
+#define RCV_EN			BIT(8)		/* receiver enable */
+/* enable packet reception when transmitting packet in half duplex mode */
+#define ENRX_IN_HALFTX		BIT(6)
+#define XMT_EN			BIT(5)		/* transmitter enable */
+/* disable CRC check when receiving packets */
+#define CRC_DIS			BIT(4)
+#define LOOP_EN			BIT(3)		/* internal loop-back */
+/* software reset, last 64 AHB bus clocks */
+#define SW_RST			BIT(2)
+#define RDMA_EN			BIT(1)		/* enable receive DMA chan */
+#define XDMA_EN			BIT(0)		/* enable transmit DMA chan */
+	unsigned int maccr;			/* MAC control, 0x88 */
+
+#define COL_EXCEED		BIT(11)		/* collisions exceeds 16 */
+/* transmitter detects late collision */
+#define LATE_COL		BIT(10)
+/* packet transmitted to ethernet lost due to late collision
+ * or excessive collision
+ */
+#define XPKT_LOST		BIT(9)
+/* packets transmitted to ethernet successfully */
+#define XPKT_OK			BIT(8)
+/* receiver detects a runt packet */
+#define RUNT_MAC_STS		BIT(7)
+/* receiver detects a frame that is too long */
+#define FTL_MAC_STS		BIT(6)
+#define CRC_ERR_MAC_STS		BIT(5)
+/* received packets list due to RX FIFO full */
+#define RPKT_LOST		BIT(4)
+/* packets received into RX FIFO successfully */
+#define RPKT_SAVE		BIT(3)
+/* incoming packet dropped due to collision */
+#define COL			BIT(2)
+#define MCPU_BROADCAST		BIT(1)
+#define MCPU_MULTICAST		BIT(0)
+	unsigned int macsr;			/* MAC status, 0x8c */
+
+/* initialize a write sequence to PHY by setting this bit to 1
+ * this bit would be auto cleared after the write operation is finished.
+ */
+#define MIIWR			BIT(27)
+#define MIIRD			BIT(26)
+#define REGAD_MASK		0x3e00000
+#define PHYAD_MASK		0x1f0000
+#define MIIRDATA_MASK		0xffff
+	unsigned int phycr;			/* PHY control, 0x90 */
+
+#define MIIWDATA_MASK		0xffff
+	unsigned int phywdata;			/* PHY write data, 0x94 */
+
+#define PAUSE_TIME_MASK		0xffff0000
+#define FC_HIGH_MASK		0xf000
+#define FC_LOW_MASK		0xf00
+#define RX_PAUSE		BIT(4)		/* receive pause frame */
+/* packet transmission is paused due to receive */
+#define TXPAUSED		BIT(3)
+	/* pause frame */
+/* enable flow control threshold mode. */
+#define FCTHR_EN		BIT(2)
+#define TX_PAUSE		BIT(1)		/* transmit pause frame */
+#define FC_EN			BIT(0)		/* flow control mode enable */
+	unsigned int fcr;			/* flow control, 0x98 */
+
+#define BK_LOW_MASK		0xf00
+#define BKJAM_LEN_MASK		0xf0
+#define BK_MODE			BIT(1)		/* back pressure address mode */
+#define BK_EN			BIT(0)		/* back pressure mode enable */
+	unsigned int bpr;			/* back pressure, 0x9c */
+
+	unsigned int reserved2[9];		/* 0xa0 - 0xc0 */
+
+#define TEST_SEED_MASK      0x3fff
+	unsigned int ts;			/* test seed, 0xc4 */
+
+#define TXD_REQ			BIT(31)		/* TXDMA request */
+#define RXD_REQ			BIT(30)		/* RXDMA request */
+#define DARB_TXGNT		BIT(29)		/* TXDMA grant */
+#define DARB_RXGNT		BIT(28)		/* RXDMA grant */
+#define TXFIFO_EMPTY		BIT(27)		/* TX FIFO is empty */
+#define RXFIFO_EMPTY		BIT(26)		/* RX FIFO is empty */
+#define TXDMA2_SM_MASK		0x7000
+#define TXDMA1_SM_MASK		0xf00
+#define RXDMA2_SM_MASK		0x70
+#define RXDMA1_SM_MASK		0xF
+	unsigned int dmafifos;			/* DMA/FIFO state, 0xc8 */
+
+#define SINGLE_PKT		BIT(26)		/* single packet mode */
+/* automatic polling timer test mode */
+#define PTIMER_TEST		BIT(25)
+#define ITIMER_TEST		BIT(24)		/* interrupt timer test mode */
+#define TEST_SEED_SEL		BIT(22)		/* test seed select */
+#define SEED_SEL		BIT(21)		/* seed select */
+#define TEST_MODE		BIT(20)		/* transmission test mode */
+#define TEST_TIME_MASK		0xffc00
+#define TEST_EXCEL_MASK		0x3e0
+	unsigned int tm;			/* test mode, 0xcc */
+
+	unsigned int reserved3;			/* 0xd0 */
+
+#define TX_MCOL_MASK		0xffff0000
+#define TX_MCOL_SHIFT_BIT	16
+#define TX_SCOL_MASK		0xffff
+#define TX_SCOL_SHIFT_BIT	0
+	/* TX_MCOL and TX_SCOL counter, 0xd4 */
+	unsigned int txmcol_xscol;
+
+#define RPF_MASK		0xffff0000
+#define RPF_SHIFT_BIT		16
+#define AEP_MASK		0xffff
+#define AEP_SHIFT_BIT		0
+	unsigned int rpf_aep;			/* RPF and AEP counter, 0xd8 */
+
+#define XM_MASK			0xffff0000
+#define XM_SHIFT_BIT		16
+#define PG_MASK			0xffff
+#define PG_SHIFT_BIT		0
+	unsigned int xm_pg;			/* XM and PG counter, 0xdc */
+
+#define RUNT_CNT_MASK		0xffff0000
+#define RUNT_CNT_SHIFT_BIT	16
+#define TLCC_MASK		0xffff
+#define TLCC_SHIFT_BIT		0
+	/* RUNT_CNT and TLCC counter, 0xe0 */
+	unsigned int runtcnt_tlcc;
+
+#define CRCER_CNT_MASK		0xffff0000
+#define CRCER_CNT_SHIFT_BIT	16
+#define FTL_CNT_MASK		0xffff
+#define FTL_CNT_SHIFT_BIT	0
+	/* CRCER_CNT and FTL_CNT counter, 0xe4 */
+	unsigned int crcercnt_ftlcnt;
+
+#define RLC_MASK		0xffff0000
+#define RLC_SHIFT_BIT		16
+#define RCC_MASK		0xffff
+#define RCC_SHIFT_BIT		0
+	unsigned int rlc_rcc;		/* RLC and RCC counter, 0xe8 */
+
+	unsigned int broc;		/* BROC counter, 0xec */
+	unsigned int mulca;		/* MULCA counter, 0xf0 */
+	unsigned int rp;		/* RP counter, 0xf4 */
+	unsigned int xp;		/* XP counter, 0xf8 */
+};
+
+#define ISR_REG_OFFSET			0x0
+#define IMR_REG_OFFSET			0x4
+#define MAC_MADR_REG_OFFSET		0x8
+#define MAC_LADR_REG_OFFSET		0xC
+#define MATH0_REG_OFFSET		0x10
+#define MATH1_REG_OFFSET		0x14
+#define TXPD_REG_OFFSET			0x18
+#define RXPD_REG_OFFSET			0x1C
+#define TXR_BADR_REG_OFFSET		0x20
+#define RXR_BADR_REG_OFFSET		0x24
+#define ITC_REG_OFFSET			0x28
+#define APTC_REG_OFFSET			0x2C
+#define DBLAC_REG_OFFSET		0x30
+#define MACCR_REG_OFFSET		0x88
+#define MACSR_REG_OFFSET		0x8C
+#define PHYCR_REG_OFFSET		0x90
+#define PHYWDATA_REG_OFFSET		0x94
+#define FCR_REG_OFFSET			0x98
+#define BPR_REG_OFFSET			0x9C
+#define TS_REG_OFFSET			0xC4
+#define DMAFIFOS_REG_OFFSET		0xC8
+#define TM_REG_OFFSET			0xCC
+#define TX_MCOL_TX_SCOL_REG_OFFSET	0xD4
+#define RPF_AEP_REG_OFFSET		0xD8
+#define XM_PG_REG_OFFSET		0xDC
+#define RUNT_CNT_TLCC_REG_OFFSET	0xE0
+#define CRCER_CNT_FTL_CNT_REG_OFFSET	0xE4
+#define RLC_RCC_REG_OFFSET		0xE8
+#define BROC_REG_OFFSET			0xEC
+#define MULCA_REG_OFFSET		0xF0
+#define RP_REG_OFFSET			0xF4
+#define XP_REG_OFFSET			0xF8
+#define PHY_CNTL_REG			0x0
+#define PHY_STATUS_REG			0x1
+#define PHY_ID_REG1			0x2
+#define PHY_ID_REG2			0x3
+#define PHY_ANA_REG			0x4
+#define PHY_ANLPAR_REG			0x5
+#define PHY_ANE_REG			0x6
+#define PHY_ECNTL_REG1			0x10
+#define PHY_QPDS_REG			0x11
+#define PHY_10BOP_REG			0x12
+#define PHY_ECNTL_REG2			0x13
+#define FTMAC100_REG_PHY_WRITE		0x8000000
+#define FTMAC100_REG_PHY_READ		0x4000000
+
+/* PHY Status register */
+#define AN_COMPLETE			0x20
+
+#define LINK_STATUS			0x4
+
+struct moxart_mac_priv_t {
+	void __iomem *base;
+	void __iomem *flash_base;
+	struct net_device_stats stats;
+	unsigned int reg_maccr;
+	unsigned int reg_imr;
+	struct napi_struct napi;
+	struct net_device *ndev;
+
+	dma_addr_t rx_base;
+	dma_addr_t rx_mapping[RX_DESC_NUM];
+	struct rx_desc_t *rx_desc_base;
+	unsigned char *rx_buf_base;
+	unsigned char *rx_buf[RX_DESC_NUM];
+	unsigned int rx_head;
+	unsigned int rx_buf_size;
+
+	dma_addr_t tx_base;
+	dma_addr_t tx_mapping[TX_DESC_NUM];
+	struct tx_desc_t *tx_desc_base;
+	unsigned char *tx_buf_base;
+	unsigned char *tx_buf[RX_DESC_NUM];
+	unsigned int tx_head;
+	unsigned int tx_buf_size;
+
+	spinlock_t txlock;
+	unsigned int tx_len[TX_DESC_NUM];
+	struct sk_buff *tx_skb[TX_DESC_NUM];
+	unsigned int tx_tail;
+};
+
+#if TX_BUF_SIZE >= TXBUF_SIZE_MAX
+#error MOXA ART Ethernet device driver Tx buffer size too large !
+#endif
+#if RX_BUF_SIZE >= RXBUF_SIZE_MAX
+#error MOXA ART Ethernet device driver Rx buffer size too large !
+#endif
+
+#endif
-- 
1.8.2.1



From kishon at ti.com  Fri Jul 26 08:49:15 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:19:15 +0530
Subject: [RESEND PATCH v10 0/8] PHY framework
Message-ID: <1374842963-13545-1-git-send-email-kishon@ti.com>

Resending with fixed device tree mailing address!

Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle.

This framework will be of use only to devices that uses external PHY (PHY
functionality is not embedded within the controller).

The intention of creating this framework is to bring the phy drivers spread
all over the Linux kernel to drivers/phy to increase code re-use and to
increase code maintainability.

Comments to make PHY as bus wasn't done because PHY devices can be part of
other bus and making a same device attached to multiple bus leads to bad
design.

If the PHY driver has to send notification on connect/disconnect, the PHY
driver should make use of the extcon framework. Using this susbsystem
to use extcon framwork will have to be analysed.

You can find this patch series @
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing

I'll create a new branch *next* once this patch series is finalized. All the
PHY driver development that depends on PHY framework can be based on this
branch.

Did USB enumeration testing in panda and beagle after applying [1]

[1] -> https://lkml.org/lkml/2013/7/26/88

Changes from v9:
* Fixed Greg's concern on having *find PHY by string* and changed it to Tomasz
  pseudo code.
* move omap-usb2 phy and twl4030-usb phy to drivers/phy
* made all the dependent drivers select GENERIC_PHY instead of having depends
  on
* Made PHY core to assign the id's (so changed the phy_create API).
* Adapted twl4030-usb to the new design.

Changes from v8:
* Added phy_set_drvdata and phy_get_drvdata in phy.h.
* Changed phy_create API not to take void *priv. private data should now be set
  using phy_set_drvdata now.
Changes from v7:
* Fixed Documentation
* Added to_phy, of_phy_provider_register and devm_of_phy_provider_register
* modified runtime_pm usage in phy_init, phy_exit, phy_power_on and
  phy_power_off. Now phy_power_on will enable the clocks and phy_power_off will
  disable the clocks.
* pm_runtime_no_callbacks() is added so that pm_runtime_get_sync doesn't fail
* modified other patches to adhere to the changes in the PHY framework
* removed usb: phy: twl4030: twl4030 shouldn't be subsys_initcall as it will
  be merged separately.
* reference counting has been added to protect phy ops when the PHY is shared
  by multiple consumers.

Changes from v6
* corrected few typos in Documentation
* Changed PHY Subsystem to *bool* in Kconfig (to avoid compilation errors when
  PHY Subsystem is kept as module and the dependent modules are built-in)
* Added if pm_runtime_enabled check before runtime pm calls.

Changes from v5:
* removed the new sysfs entries as it dint have any new information other than
  what is already there in /sys/devices/...
* removed a bunch of APIs added to get the PHY and now only phy_get and
  devm_phy_get are used.
* Added new APIs to register/unregister the PHY provider. This is needed for
  dt boot case.
* Enabled pm runtime and incorporated the comments given by Alan Stern in a
  different patch series by Gautam.
* Removed the *phy_bind* API. Now the phy binding information should be passed
  using the platform data to the controller devices.
* Fixed a few typos.

Changes from v4:
* removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy providers*
  should use their custom implementation of of_xlate or use of_phy_xlate to get
  *phy instance* from *phy providers*.
* Added of_phy_xlate to be used by *phy providers* if it provides only one PHY.
* changed phy_core from having subsys_initcall to module_init.
* other minor fixes.

Changes from v3:
* Changed the return value of PHY APIs to ENOSYS
* Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting
  PHYs if the same IP implements multiple PHYs.
* modified phy_bind API so that the binding information can now be _updated_.
  In effect of this removed the binding information added in board files and
  added only in usb-musb.c. If a particular board uses a different phy binding,
  it can update it in board file after usb_musb_init().
* Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding
  information.

Changes from v2:
* removed phy_descriptor structure completely so changed the APIs which were
  taking phy_descriptor as parameters
* Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used
  by PHY user drivers which has *phy* and *phy-names* binding in the dt data
* Fixed a few typos
* Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and
  class_dev_iter_exit for traversing through the phy list. (Note we still need
  phy_bind list and phy_bind_mutex).
* Changed the sysfs entry name from *bind* to *phy_bind*.

Changes from v1:
* Added Documentation for the PHY framework
* Added few more APIs mostly w.r.t devres
* Modified omap-usb2 and twl4030 to make use of the new framework

Kishon Vijay Abraham I (8):
  drivers: phy: add generic PHY framework
  usb: phy: omap-usb2: use the new generic PHY framework
  usb: phy: twl4030: use the new generic PHY framework
  arm: omap3: twl: add phy consumer data in twl4030_usb_data
  ARM: dts: omap: update usb_otg_hs data
  usb: musb: omap2430: use the new generic PHY framework
  usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
  usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

 .../devicetree/bindings/phy/phy-bindings.txt       |   66 ++
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 +
 Documentation/phy.txt                              |  166 +++++
 MAINTAINERS                                        |    8 +
 arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 +
 arch/arm/boot/dts/omap3-evm.dts                    |    2 +
 arch/arm/boot/dts/omap3-overo.dtsi                 |    2 +
 arch/arm/boot/dts/omap4.dtsi                       |    3 +
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 arch/arm/mach-omap2/twl-common.c                   |   11 +
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   41 ++
 drivers/phy/Makefile                               |    7 +
 drivers/phy/phy-core.c                             |  714 ++++++++++++++++++++
 drivers/{usb => }/phy/phy-omap-usb2.c              |   60 +-
 drivers/{usb => }/phy/phy-twl4030-usb.c            |   69 +-
 drivers/usb/musb/Kconfig                           |    1 +
 drivers/usb/musb/musb_core.h                       |    2 +
 drivers/usb/musb/omap2430.c                        |   26 +-
 drivers/usb/phy/Kconfig                            |   19 -
 drivers/usb/phy/Makefile                           |    2 -
 include/linux/i2c/twl.h                            |    2 +
 include/linux/phy/phy.h                            |  270 ++++++++
 25 files changed, 1413 insertions(+), 76 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 rename drivers/{usb => }/phy/phy-omap-usb2.c (88%)
 rename drivers/{usb => }/phy/phy-twl4030-usb.c (94%)
 create mode 100644 include/linux/phy/phy.h

-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:49:17 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:19:17 +0530
Subject: [RESEND PATCH v10 2/8] usb: phy: omap-usb2: use the new generic PHY
 framework
In-Reply-To: <1374842963-13545-1-git-send-email-kishon@ti.com>
References: <1374842963-13545-1-git-send-email-kishon@ti.com>
Message-ID: <1374842963-13545-3-git-send-email-kishon@ti.com>

Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.
The omap-usb2 driver is also moved to driver/phy.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 drivers/phy/Kconfig                   |   12 +++++++++
 drivers/phy/Makefile                  |    1 +
 drivers/{usb => }/phy/phy-omap-usb2.c |   45 ++++++++++++++++++++++++++++++---
 drivers/usb/phy/Kconfig               |   10 --------
 drivers/usb/phy/Makefile              |    1 -
 5 files changed, 54 insertions(+), 15 deletions(-)
 rename drivers/{usb => }/phy/phy-omap-usb2.c (88%)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 349bef2..38c3477 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,4 +15,16 @@ config GENERIC_PHY
 	  phy users can obtain reference to the PHY. All the users of this
 	  framework should select this config.
 
+config OMAP_USB2
+	tristate "OMAP USB2 PHY Driver"
+	depends on ARCH_OMAP2PLUS
+	select GENERIC_PHY
+	select USB_PHY
+	select OMAP_CONTROL_USB
+	help
+	  Enable this to support the transceiver that is part of SOC. This
+	  driver takes care of all the PHY functionality apart from comparator.
+	  The USB OTG controller communicates with the comparator using this
+	  driver.
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..ed5b088 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
+obj-$(CONFIG_OMAP_USB2)		+= phy-omap-usb2.o
diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
similarity index 88%
rename from drivers/usb/phy/phy-omap-usb2.c
rename to drivers/phy/phy-omap-usb2.c
index 844ab68..25e0f3c 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/delay.h>
 #include <linux/usb/omap_control_usb.h>
+#include <linux/phy/phy.h>
 
 /**
  * omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,10 +120,36 @@ static int omap_usb2_suspend(struct usb_phy *x, int suspend)
 	return 0;
 }
 
+static int omap_usb_power_off(struct phy *x)
+{
+	struct omap_usb *phy = phy_get_drvdata(x);
+
+	omap_control_usb_phy_power(phy->control_dev, 0);
+
+	return 0;
+}
+
+static int omap_usb_power_on(struct phy *x)
+{
+	struct omap_usb *phy = phy_get_drvdata(x);
+
+	omap_control_usb_phy_power(phy->control_dev, 1);
+
+	return 0;
+}
+
+static struct phy_ops ops = {
+	.power_on	= omap_usb_power_on,
+	.power_off	= omap_usb_power_off,
+	.owner		= THIS_MODULE,
+};
+
 static int omap_usb2_probe(struct platform_device *pdev)
 {
 	struct omap_usb			*phy;
+	struct phy			*generic_phy;
 	struct usb_otg			*otg;
+	struct phy_provider		*phy_provider;
 
 	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
 	if (!phy) {
@@ -144,6 +171,11 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
+	phy_provider = devm_of_phy_provider_register(phy->dev,
+			of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
 	phy->control_dev = omap_get_control_dev();
 	if (IS_ERR(phy->control_dev)) {
 		dev_dbg(&pdev->dev, "Failed to get control device\n");
@@ -159,6 +191,15 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	otg->start_srp		= omap_usb_start_srp;
 	otg->phy		= &phy->phy;
 
+	platform_set_drvdata(pdev, phy);
+	pm_runtime_enable(phy->dev);
+
+	generic_phy = devm_phy_create(phy->dev, &ops, NULL);
+	if (IS_ERR(generic_phy))
+		return PTR_ERR(generic_phy);
+
+	phy_set_drvdata(generic_phy, phy);
+
 	phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");
 	if (IS_ERR(phy->wkupclk)) {
 		dev_err(&pdev->dev, "unable to get usb_phy_cm_clk32k\n");
@@ -174,10 +215,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
 	usb_add_phy_dev(&phy->phy);
 
-	platform_set_drvdata(pdev, phy);
-
-	pm_runtime_enable(phy->dev);
-
 	return 0;
 }
 
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 3622fff..7813238 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -72,16 +72,6 @@ config OMAP_CONTROL_USB
 	  power on the USB2 PHY is present in OMAP4 and OMAP5. OMAP5 has an
 	  additional register to power on USB3 PHY.
 
-config OMAP_USB2
-	tristate "OMAP USB2 PHY Driver"
-	depends on ARCH_OMAP2PLUS
-	select OMAP_CONTROL_USB
-	help
-	  Enable this to support the transceiver that is part of SOC. This
-	  driver takes care of all the PHY functionality apart from comparator.
-	  The USB OTG controller communicates with the comparator using this
-	  driver.
-
 config OMAP_USB3
 	tristate "OMAP USB3 PHY Driver"
 	select OMAP_CONTROL_USB
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 070eca3..56d2b03 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -16,7 +16,6 @@ obj-$(CONFIG_ISP1301_OMAP)		+= phy-isp1301-omap.o
 obj-$(CONFIG_MV_U3D_PHY)		+= phy-mv-u3d-usb.o
 obj-$(CONFIG_NOP_USB_XCEIV)		+= phy-nop.o
 obj-$(CONFIG_OMAP_CONTROL_USB)		+= phy-omap-control.o
-obj-$(CONFIG_OMAP_USB2)			+= phy-omap-usb2.o
 obj-$(CONFIG_OMAP_USB3)			+= phy-omap-usb3.o
 obj-$(CONFIG_SAMSUNG_USBPHY)		+= phy-samsung-usb.o
 obj-$(CONFIG_SAMSUNG_USB2PHY)		+= phy-samsung-usb2.o
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:49:16 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:19:16 +0530
Subject: [RESEND PATCH v10 1/8] drivers: phy: add generic PHY framework
In-Reply-To: <1374842963-13545-1-git-send-email-kishon@ti.com>
References: <1374842963-13545-1-git-send-email-kishon@ti.com>
Message-ID: <1374842963-13545-2-git-send-email-kishon@ti.com>

The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.

PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Cc: Tomasz Figa <t.figa at samsung.com>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Tested-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 .../devicetree/bindings/phy/phy-bindings.txt       |   66 ++
 Documentation/phy.txt                              |  166 +++++
 MAINTAINERS                                        |    8 +
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   18 +
 drivers/phy/Makefile                               |    5 +
 drivers/phy/phy-core.c                             |  714 ++++++++++++++++++++
 include/linux/phy/phy.h                            |  270 ++++++++
 9 files changed, 1251 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 0000000..8ae844f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,66 @@
+This document explains only the device tree data binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
+
+PHY device node
+===============
+
+Required Properties:
+#phy-cells:	Number of cells in a PHY specifier;  The meaning of all those
+		cells is defined by the binding for the phy node. The PHY
+		provider can use the values in cells to find the appropriate
+		PHY.
+
+For example:
+
+phys: phy {
+    compatible = "xxx";
+    reg = <...>;
+    .
+    .
+    #phy-cells = <1>;
+    .
+    .
+};
+
+That node describes an IP block (PHY provider) that implements 2 different PHYs.
+In order to differentiate between these 2 PHYs, an additonal specifier should be
+given while trying to get a reference to it.
+
+PHY user node
+=============
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+phy-names : the names of the PHY corresponding to the PHYs present in the
+	    *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss at xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&usb2_phy>, <&usb3_phy>;
+    phy-names = "usb2phy", "usb3phy";
+    .
+    .
+};
+
+This node represents a controller that uses two PHYs, one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss at xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&phys 1>;
+    phy-names = "usbphy";
+    .
+    .
+};
+
+This node represents a controller that uses one of the PHYs of the PHY provider
+device defined previously. Note that the phy handle has an additional specifier
+"1" to differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 0000000..4e056c4
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,166 @@
+			    PHY SUBSYSTEM
+		  Kishon Vijay Abraham I <kishon at ti.com>
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controllers have PHY functionality embedded into it and others use an external
+PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+The intention of creating this framework is to bring the PHY drivers spread
+all over the Linux kernel to drivers/phy to increase code re-use and for
+better code maintainability.
+
+This framework will be of use only to devices that use external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Registering/Unregistering the PHY provider
+
+PHY provider refers to an entity that implements one or more PHY instances.
+For the simple case where the PHY provider implements only a single instance of
+the PHY, the framework provides its own implementation of of_xlate in
+of_phy_simple_xlate. If the PHY provider implements multiple instances, it
+should provide its own implementation of of_xlate. of_xlate is used only for
+dt boot case.
+
+#define of_phy_provider_register(dev, xlate)    \
+        __of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+#define devm_of_phy_provider_register(dev, xlate)       \
+        __of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+of_phy_provider_register and devm_of_phy_provider_register macros can be used to
+register the phy_provider and it takes device and of_xlate as
+arguments. For the dt boot case, all PHY providers should use one of the above
+2 macros to register the PHY provider.
+
+void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider);
+void of_phy_provider_unregister(struct phy_provider *phy_provider);
+
+devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to
+unregister the PHY.
+
+3. Creating the PHY
+
+The PHY driver should create the PHY in order for other peripheral controllers
+to make use of it. The PHY framework provides 2 APIs to create the PHY.
+
+struct phy *phy_create(struct device *dev, const struct phy_ops *ops,
+        struct phy_init_data *init_data);
+struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops,
+	struct phy_init_data *init_data);
+
+The PHY drivers can use one of the above 2 APIs to create the PHY by passing
+the device pointer, phy ops and init_data.
+phy_ops is a set of function pointers for performing PHY operations such as
+init, exit, power_on and power_off. *init_data* is mandatory to get a reference
+to the PHY in the case of non-dt boot. See section *Board File Initialization*
+on how init_data should be used.
+
+Inorder to dereference the private data (in phy_ops), the phy provider driver
+can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
+phy_ops to get back the private data.
+
+4. Getting a reference to the PHY
+
+Before the controller can make use of the PHY, it has to get a reference to
+it. This framework provides the following APIs to get a reference to the PHY.
+
+struct phy *phy_get(struct device *dev, const char *string);
+struct phy *devm_phy_get(struct device *dev, const char *string);
+
+phy_get and devm_phy_get can be used to get the PHY. In the case of dt boot,
+the string arguments should contain the phy name as given in the dt data and
+in the case of non-dt boot, it should contain the label of the PHY.
+The only difference between the two APIs is that devm_phy_get associates the
+device with the PHY using devres on successful PHY get. On driver detach,
+release function is invoked on the the devres data and devres data is freed.
+
+5. Releasing a reference to the PHY
+
+When the controller no longer needs the PHY, it has to release the reference
+to the PHY it has obtained using the APIs mentioned in the above section. The
+PHY framework provides 2 APIs to release a reference to the PHY.
+
+void phy_put(struct phy *phy);
+void devm_phy_put(struct device *dev, struct phy *phy);
+
+Both these APIs are used to release a reference to the PHY and devm_phy_put
+destroys the devres associated with this PHY.
+
+6. Destroying the PHY
+
+When the driver that created the PHY is unloaded, it should destroy the PHY it
+created using one of the following 2 APIs.
+
+void phy_destroy(struct phy *phy);
+void devm_phy_destroy(struct device *dev, struct phy *phy);
+
+Both these APIs destroy the PHY and devm_phy_destroy destroys the devres
+associated with this PHY.
+
+7. PM Runtime
+
+This subsystem is pm runtime enabled. So while creating the PHY,
+pm_runtime_enable of the phy device created by this subsystem is called and
+while destroying the PHY, pm_runtime_disable is called. Note that the phy
+device created by this subsystem will be a child of the device that calls
+phy_create (PHY provider device).
+
+So pm_runtime_get_sync of the phy_device created by this subsystem will invoke
+pm_runtime_get_sync of PHY provider device because of parent-child relationship.
+It should also be noted that phy_power_on and phy_power_off performs
+phy_pm_runtime_get_sync and phy_pm_runtime_put respectively.
+There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync,
+phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
+phy_pm_runtime_forbid for performing PM operations.
+
+8. Board File Initialization
+
+Certain board file initialization is necessary in order to get a reference
+to the PHY in the case of non-dt boot.
+Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe,
+then in the board file the following initialization should be done.
+
+struct phy_consumer consumers[] = {
+	PHY_CONSUMER("dwc3.0", "usb"),
+	PHY_CONSUMER("pcie.0", "pcie"),
+	PHY_CONSUMER("sata.0", "sata"),
+};
+PHY_CONSUMER takes 2 parameters, first is the device name of the controller
+(PHY consumer) and second is the port name.
+
+struct phy_init_data init_data = {
+	.consumers = consumers,
+	.num_consumers = ARRAY_SIZE(consumers),
+};
+
+static const struct platform_device pipe3_phy_dev = {
+	.name = "pipe3-phy",
+	.id = -1,
+	.dev = {
+		.platform_data = {
+			.init_data = &init_data,
+		},
+	},
+};
+
+then, while doing phy_create, the PHY driver should pass this init_data
+	phy_create(dev, ops, pdata->init_data);
+
+and the controller driver (phy consumer) should pass the port name along with
+the device to get a reference to the PHY
+	phy_get(dev, "pcie");
+
+9. DeviceTree Binding
+
+The documentation for PHY dt binding can be found @
+Documentation/devicetree/bindings/phy/phy-bindings.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index bf61e04..96caae7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3594,6 +3594,14 @@ S:	Maintained
 F:	include/asm-generic
 F:	include/uapi/asm-generic
 
+GENERIC PHY FRAMEWORK
+M:	Kishon Vijay Abraham I <kishon at ti.com>
+L:	linux-kernel at vger.kernel.org
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git
+S:	Supported
+F:	drivers/phy/
+F:	include/linux/phy/
+
 GENERIC UIO DRIVER FOR PCI DEVICES
 M:	"Michael S. Tsirkin" <mst at redhat.com>
 L:	kvm at vger.kernel.org
diff --git a/drivers/Kconfig b/drivers/Kconfig
index aa43b91..8f45144 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -166,4 +166,6 @@ source "drivers/reset/Kconfig"
 
 source "drivers/fmc/Kconfig"
 
+source "drivers/phy/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index ab93de8..687da89 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -8,6 +8,8 @@
 obj-y				+= irqchip/
 obj-y				+= bus/
 
+obj-$(CONFIG_GENERIC_PHY)	+= phy/
+
 # GPIO must come after pinctrl as gpios may need to mux pins etc
 obj-y				+= pinctrl/
 obj-y				+= gpio/
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
new file mode 100644
index 0000000..349bef2
--- /dev/null
+++ b/drivers/phy/Kconfig
@@ -0,0 +1,18 @@
+#
+# PHY
+#
+
+menu "PHY Subsystem"
+
+config GENERIC_PHY
+	tristate "PHY Core"
+	help
+	  Generic PHY support.
+
+	  This framework is designed to provide a generic interface for PHY
+	  devices present in the kernel. This layer will have the generic
+	  API by which phy drivers can create PHY using the phy framework and
+	  phy users can obtain reference to the PHY. All the users of this
+	  framework should select this config.
+
+endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
new file mode 100644
index 0000000..9e9560f
--- /dev/null
+++ b/drivers/phy/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 0000000..f1d15e5
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,714 @@
+/*
+ * phy-core.c  --  Generic Phy framework.
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Kishon Vijay Abraham I <kishon at ti.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/idr.h>
+#include <linux/pm_runtime.h>
+
+static struct class *phy_class;
+static DEFINE_MUTEX(phy_provider_mutex);
+static LIST_HEAD(phy_provider_list);
+static DEFINE_IDA(phy_ida);
+
+static int phy_get_id(void)
+{
+	int ret;
+	int id;
+
+	ret = ida_pre_get(&phy_ida, GFP_KERNEL);
+	if (!ret)
+		return -ENOMEM;
+
+	ret = ida_get_new(&phy_ida, &id);
+	if (ret < 0)
+		return ret;
+
+	return id;
+}
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_put(phy);
+}
+
+static void devm_phy_provider_release(struct device *dev, void *res)
+{
+	struct phy_provider *phy_provider = *(struct phy_provider **)res;
+
+	of_phy_provider_unregister(phy_provider);
+}
+
+static void devm_phy_consume(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_destroy(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+	return res == match_data;
+}
+
+static struct phy *phy_lookup(struct device *device, const char *port)
+{
+	unsigned int count;
+	struct phy *phy;
+	struct device *dev;
+	struct phy_consumer *consumers;
+	struct class_dev_iter iter;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = to_phy(dev);
+		count = phy->init_data->num_consumers;
+		consumers = phy->init_data->consumers;
+		while (count--) {
+			if (!strcmp(consumers->dev_name, dev_name(device)) &&
+					!strcmp(consumers->port, port)) {
+				class_dev_iter_exit(&iter);
+				return phy;
+			}
+			consumers++;
+		}
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-ENODEV);
+}
+
+static struct phy_provider *of_phy_provider_lookup(struct device_node *node)
+{
+	struct phy_provider *phy_provider;
+
+	list_for_each_entry(phy_provider, &phy_provider_list, list) {
+		if (phy_provider->dev->of_node == node)
+			return phy_provider;
+	}
+
+	return ERR_PTR(-EPROBE_DEFER);
+}
+
+int phy_pm_runtime_get(struct phy *phy)
+{
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_get(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_pm_runtime_get);
+
+int phy_pm_runtime_get_sync(struct phy *phy)
+{
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_get_sync(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_pm_runtime_get_sync);
+
+int phy_pm_runtime_put(struct phy *phy)
+{
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_put(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_pm_runtime_put);
+
+int phy_pm_runtime_put_sync(struct phy *phy)
+{
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_put_sync(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_pm_runtime_put_sync);
+
+void phy_pm_runtime_allow(struct phy *phy)
+{
+	if (!pm_runtime_enabled(&phy->dev))
+		return;
+
+	pm_runtime_allow(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_pm_runtime_allow);
+
+void phy_pm_runtime_forbid(struct phy *phy)
+{
+	if (!pm_runtime_enabled(&phy->dev))
+		return;
+
+	pm_runtime_forbid(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_pm_runtime_forbid);
+
+int phy_init(struct phy *phy)
+{
+	int ret;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (phy->init_count++ == 0 && phy->ops->init) {
+		ret = phy->ops->init(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy init failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(phy_init);
+
+int phy_exit(struct phy *phy)
+{
+	int ret;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (--phy->init_count == 0 && phy->ops->exit) {
+		ret = phy->ops->exit(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy exit failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(phy_exit);
+
+int phy_power_on(struct phy *phy)
+{
+	int ret = -ENOTSUPP;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (phy->power_count++ == 0 && phy->ops->power_on) {
+		ret = phy->ops->power_on(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy poweron failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(phy_power_on);
+
+int phy_power_off(struct phy *phy)
+{
+	int ret = -ENOTSUPP;
+
+	mutex_lock(&phy->mutex);
+	if (--phy->power_count == 0 && phy->ops->power_off) {
+		ret =  phy->ops->power_off(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy poweroff failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(phy_power_off);
+
+/**
+ * of_phy_get() - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Returns the phy associated with the given phandle value,
+ * after getting a refcount to it or -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded. This function uses of_xlate call back function provided
+ * while registering the phy_provider to find the phy instance.
+ */
+static struct phy *of_phy_get(struct device *dev, int index)
+{
+	int ret;
+	struct phy_provider *phy_provider;
+	struct phy *phy = NULL;
+	struct of_phandle_args args;
+
+	ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
+		index, &args);
+	if (ret) {
+		dev_dbg(dev, "failed to get phy in %s node\n",
+			dev->of_node->full_name);
+		return ERR_PTR(-ENODEV);
+	}
+
+	mutex_lock(&phy_provider_mutex);
+	phy_provider = of_phy_provider_lookup(args.np);
+	if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
+		phy = ERR_PTR(-EPROBE_DEFER);
+		goto err0;
+	}
+
+	phy = phy_provider->of_xlate(phy_provider->dev, &args);
+	module_put(phy_provider->owner);
+
+err0:
+	mutex_unlock(&phy_provider_mutex);
+	of_node_put(args.np);
+
+	return phy;
+}
+
+/**
+ * phy_put() - release the PHY
+ * @phy: the phy returned by phy_get()
+ *
+ * Releases a refcount the caller received from phy_get().
+ */
+void phy_put(struct phy *phy)
+{
+	if (IS_ERR(phy))
+		return;
+
+	module_put(phy->ops->owner);
+	put_device(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_put);
+
+/**
+ * devm_phy_put() - release the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_put
+ * to release the phy.
+ */
+void devm_phy_put(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_release, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_put);
+
+/**
+ * of_phy_simple_xlate() - returns the phy instance from phy provider
+ * @dev: the PHY provider device
+ * @args: of_phandle_args (not used here)
+ *
+ * Intended to be used by phy provider for the common case where #phy-cells is
+ * 0. For other cases where #phy-cells is greater than '0', the phy provider
+ * should provide a custom of_xlate function that reads the *args* and returns
+ * the appropriate phy.
+ */
+struct phy *of_phy_simple_xlate(struct device *dev, struct of_phandle_args
+	*args)
+{
+	struct phy *phy;
+	struct class_dev_iter iter;
+	struct device_node *node = dev->of_node;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = to_phy(dev);
+		if (node != phy->dev.of_node)
+			continue;
+
+		class_dev_iter_exit(&iter);
+		return phy;
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
+
+/**
+ * phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data or the name of the controller
+ * port for non-dt case
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy.  The caller is responsible for
+ * calling phy_put() to release that count.
+ */
+struct phy *phy_get(struct device *dev, const char *string)
+{
+	int index = 0;
+	struct phy *phy = NULL;
+
+	if (string == NULL) {
+		dev_WARN(dev, "missing string\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (dev->of_node) {
+		index = of_property_match_string(dev->of_node, "phy-names",
+			string);
+		phy = of_phy_get(dev, index);
+		if (IS_ERR(phy)) {
+			dev_err(dev, "unable to find phy\n");
+			return phy;
+		}
+	} else {
+		phy = phy_lookup(dev, string);
+		if (IS_ERR(phy)) {
+			dev_err(dev, "unable to find phy\n");
+			return phy;
+		}
+	}
+
+	if (!try_module_get(phy->ops->owner))
+		return ERR_PTR(-EPROBE_DEFER);
+
+	get_device(&phy->dev);
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(phy_get);
+
+/**
+ * devm_phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data or phy device name
+ * for non-dt case
+ *
+ * Gets the phy using phy_get(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_get(struct device *dev, const char *string)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_get(dev, string);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_get);
+
+/**
+ * phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @ops: function pointers for performing phy operations
+ * @init_data: contains the list of PHY consumers or NULL
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, const struct phy_ops *ops,
+	struct phy_init_data *init_data)
+{
+	int ret;
+	int id;
+	struct phy *phy;
+
+	if (!dev) {
+		dev_WARN(dev, "no device provided for PHY\n");
+		ret = -EINVAL;
+		goto err0;
+	}
+
+	phy = kzalloc(sizeof(*phy), GFP_KERNEL);
+	if (!phy) {
+		ret = -ENOMEM;
+		goto err0;
+	}
+
+	id = phy_get_id();
+	if (id < 0) {
+		dev_err(dev, "unable to get id\n");
+		ret = id;
+		goto err0;
+	}
+
+	device_initialize(&phy->dev);
+	mutex_init(&phy->mutex);
+
+	phy->dev.class = phy_class;
+	phy->dev.parent = dev;
+	phy->dev.of_node = dev->of_node;
+	phy->id = id;
+	phy->ops = ops;
+	phy->init_data = init_data;
+
+	ret = dev_set_name(&phy->dev, "phy-%s.%d", dev_name(dev), id);
+	if (ret)
+		goto err1;
+
+	ret = device_add(&phy->dev);
+	if (ret)
+		goto err1;
+
+	if (pm_runtime_enabled(dev)) {
+		pm_runtime_enable(&phy->dev);
+		pm_runtime_no_callbacks(&phy->dev);
+	}
+
+	return phy;
+
+err1:
+	ida_remove(&phy_ida, phy->id);
+	put_device(&phy->dev);
+	kfree(phy);
+
+err0:
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(phy_create);
+
+/**
+ * devm_phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @ops: function pointers for performing phy operations
+ * @init_data: contains the list of PHY consumers or NULL
+ *
+ * Creates a new PHY device adding it to the PHY class.
+ * While at that, it also associates the device with the phy using devres.
+ * On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops,
+	struct phy_init_data *init_data)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_consume, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_create(dev, ops, init_data);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_create);
+
+/**
+ * phy_destroy() - destroy the phy
+ * @phy: the phy to be destroyed
+ *
+ * Called to destroy the phy.
+ */
+void phy_destroy(struct phy *phy)
+{
+	pm_runtime_disable(&phy->dev);
+	device_unregister(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_destroy);
+
+/**
+ * devm_phy_destroy() - destroy the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_destroy
+ * to destroy the phy.
+ */
+void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_consume, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_destroy);
+
+/**
+ * __of_phy_provider_register() - create/register phy provider with the framework
+ * @dev: struct device of the phy provider
+ * @owner: the module owner containing of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy provider
+ *
+ * Creates struct phy_provider from dev and of_xlate function pointer.
+ * This is used in the case of dt boot for finding the phy instance from
+ * phy provider.
+ */
+struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	struct phy_provider *phy_provider;
+
+	phy_provider = kzalloc(sizeof(*phy_provider), GFP_KERNEL);
+	if (!phy_provider)
+		return ERR_PTR(-ENOMEM);
+
+	phy_provider->dev = dev;
+	phy_provider->owner = owner;
+	phy_provider->of_xlate = of_xlate;
+
+	mutex_lock(&phy_provider_mutex);
+	list_add_tail(&phy_provider->list, &phy_provider_list);
+	mutex_unlock(&phy_provider_mutex);
+
+	return phy_provider;
+}
+EXPORT_SYMBOL_GPL(__of_phy_provider_register);
+
+/**
+ * __devm_of_phy_provider_register() - create/register phy provider with the
+ * framework
+ * @dev: struct device of the phy provider
+ * @owner: the module owner containing of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy provider
+ *
+ * Creates struct phy_provider from dev and of_xlate function pointer.
+ * This is used in the case of dt boot for finding the phy instance from
+ * phy provider. While at that, it also associates the device with the
+ * phy provider using devres. On driver detach, release function is invoked
+ * on the devres data, then, devres data is freed.
+ */
+struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	struct phy_provider **ptr, *phy_provider;
+
+	ptr = devres_alloc(devm_phy_provider_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy_provider = __of_phy_provider_register(dev, owner, of_xlate);
+	if (!IS_ERR(phy_provider)) {
+		*ptr = phy_provider;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy_provider;
+}
+EXPORT_SYMBOL_GPL(__devm_of_phy_provider_register);
+
+/**
+ * of_phy_provider_unregister() - unregister phy provider from the framework
+ * @phy_provider: phy provider returned by of_phy_provider_register()
+ *
+ * Removes the phy_provider created using of_phy_provider_register().
+ */
+void of_phy_provider_unregister(struct phy_provider *phy_provider)
+{
+	if (IS_ERR(phy_provider))
+		return;
+
+	mutex_lock(&phy_provider_mutex);
+	list_del(&phy_provider->list);
+	kfree(phy_provider);
+	mutex_unlock(&phy_provider_mutex);
+}
+EXPORT_SYMBOL_GPL(of_phy_provider_unregister);
+
+/**
+ * devm_of_phy_provider_unregister() - remove phy provider from the framework
+ * @dev: struct device of the phy provider
+ *
+ * destroys the devres associated with this phy provider and invokes
+ * of_phy_provider_unregister to unregister the phy provider.
+ */
+void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider) {
+	int r;
+
+	r = devres_destroy(dev, devm_phy_provider_release, devm_phy_match,
+		phy_provider);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY provider device resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_provider_unregister);
+
+/**
+ * phy_release() - release the phy
+ * @dev: the dev member within phy
+ *
+ * When the last reference to the device is removed, it is called
+ * from the embedded kobject as release method.
+ */
+static void phy_release(struct device *dev)
+{
+	struct phy *phy;
+
+	phy = to_phy(dev);
+	dev_vdbg(dev, "releasing '%s'\n", dev_name(dev));
+	ida_remove(&phy_ida, phy->id);
+	kfree(phy);
+}
+
+static int __init phy_core_init(void)
+{
+	phy_class = class_create(THIS_MODULE, "phy");
+	if (IS_ERR(phy_class)) {
+		pr_err("failed to create phy class --> %ld\n",
+			PTR_ERR(phy_class));
+		return PTR_ERR(phy_class);
+	}
+
+	phy_class->dev_release = phy_release;
+
+	return 0;
+}
+module_init(phy_core_init);
+
+static void __exit phy_core_exit(void)
+{
+	class_destroy(phy_class);
+}
+module_exit(phy_core_exit);
+
+MODULE_DESCRIPTION("Generic PHY Framework");
+MODULE_AUTHOR("Kishon Vijay Abraham I <kishon at ti.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
new file mode 100644
index 0000000..e444b23
--- /dev/null
+++ b/include/linux/phy/phy.h
@@ -0,0 +1,270 @@
+/*
+ * phy.h -- generic phy header file
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Kishon Vijay Abraham I <kishon at ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __DRIVERS_PHY_H
+#define __DRIVERS_PHY_H
+
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/device.h>
+#include <linux/pm_runtime.h>
+
+struct phy;
+
+/**
+ * struct phy_ops - set of function pointers for performing phy operations
+ * @init: operation to be performed for initializing phy
+ * @exit: operation to be performed while exiting
+ * @power_on: powering on the phy
+ * @power_off: powering off the phy
+ * @owner: the module owner containing the ops
+ */
+struct phy_ops {
+	int	(*init)(struct phy *phy);
+	int	(*exit)(struct phy *phy);
+	int	(*power_on)(struct phy *phy);
+	int	(*power_off)(struct phy *phy);
+	struct module *owner;
+};
+
+/**
+ * struct phy - represents the phy device
+ * @dev: phy device
+ * @id: id of the phy device
+ * @ops: function pointers for performing phy operations
+ * @init_data: list of PHY consumers (non-dt only)
+ * @mutex: mutex to protect phy_ops
+ * @init_count: used to protect when the PHY is used by multiple consumers
+ * @power_count: used to protect when the PHY is used by multiple consumers
+ */
+struct phy {
+	struct device		dev;
+	int			id;
+	const struct phy_ops	*ops;
+	struct phy_init_data	*init_data;
+	struct mutex		mutex;
+	int			init_count;
+	int			power_count;
+};
+
+/**
+ * struct phy_provider - represents the phy provider
+ * @dev: phy provider device
+ * @owner: the module owner having of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy pointer
+ * @list: to maintain a linked list of PHY providers
+ */
+struct phy_provider {
+	struct device		*dev;
+	struct module		*owner;
+	struct list_head	list;
+	struct phy * (*of_xlate)(struct device *dev,
+		struct of_phandle_args *args);
+};
+
+/**
+ * struct phy_consumer - represents the phy consumer
+ * @dev_name: the device name of the controller that will use this PHY device
+ * @port: name given to the consumer port
+ */
+struct phy_consumer {
+	const char *dev_name;
+	const char *port;
+};
+
+/**
+ * struct phy_init_data - contains the list of PHY consumers
+ * @num_consumers: number of consumers for this PHY device
+ * @consumers: list of PHY consumers
+ */
+struct phy_init_data {
+	unsigned int num_consumers;
+	struct phy_consumer *consumers;
+};
+
+#define PHY_CONSUMER(_dev_name, _port)				\
+{								\
+	.dev_name	= _dev_name,				\
+	.port		= _port,				\
+}
+
+#define	to_phy(dev)	(container_of((dev), struct phy, dev))
+
+#define	of_phy_provider_register(dev, xlate)	\
+	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+#define	devm_of_phy_provider_register(dev, xlate)	\
+	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+static inline void phy_set_drvdata(struct phy *phy, void *data)
+{
+	dev_set_drvdata(&phy->dev, data);
+}
+
+static inline void *phy_get_drvdata(struct phy *phy)
+{
+	return dev_get_drvdata(&phy->dev);
+}
+
+#if IS_ENABLED(CONFIG_GENERIC_PHY)
+extern int phy_pm_runtime_get(struct phy *phy);
+extern int phy_pm_runtime_get_sync(struct phy *phy);
+extern int phy_pm_runtime_put(struct phy *phy);
+extern int phy_pm_runtime_put_sync(struct phy *phy);
+extern void phy_pm_runtime_allow(struct phy *phy);
+extern void phy_pm_runtime_forbid(struct phy *phy);
+extern int phy_init(struct phy *phy);
+extern int phy_exit(struct phy *phy);
+extern int phy_power_on(struct phy *phy);
+extern int phy_power_off(struct phy *phy);
+extern struct phy *phy_get(struct device *dev, const char *string);
+extern struct phy *devm_phy_get(struct device *dev, const char *string);
+extern void phy_put(struct phy *phy);
+extern void devm_phy_put(struct device *dev, struct phy *phy);
+extern struct phy *of_phy_simple_xlate(struct device *dev,
+	struct of_phandle_args *args);
+extern struct phy *phy_create(struct device *dev, const struct phy_ops *ops,
+	struct phy_init_data *init_data);
+extern struct phy *devm_phy_create(struct device *dev,
+	const struct phy_ops *ops, struct phy_init_data *init_data);
+extern void phy_destroy(struct phy *phy);
+extern void devm_phy_destroy(struct device *dev, struct phy *phy);
+extern struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+extern struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+extern void of_phy_provider_unregister(struct phy_provider *phy_provider);
+extern void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider);
+#else
+static inline int phy_pm_runtime_get(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline int phy_pm_runtime_get_sync(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline int phy_pm_runtime_put(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline int phy_pm_runtime_put_sync(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline void phy_pm_runtime_allow(struct phy *phy)
+{
+	return;
+}
+
+static inline void phy_pm_runtime_forbid(struct phy *phy)
+{
+	return;
+}
+
+static inline int phy_init(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline int phy_exit(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline int phy_power_on(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline int phy_power_off(struct phy *phy)
+{
+	return -ENOSYS;
+}
+
+static inline struct phy *phy_get(struct device *dev, const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_get(struct device *dev, const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_put(struct phy *phy)
+{
+}
+
+static inline void devm_phy_put(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy *of_phy_simple_xlate(struct device *dev,
+	struct of_phandle_args *args)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *phy_create(struct device *dev,
+	const struct phy_ops *ops, struct phy_init_data *init_data)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_create(struct device *dev,
+	const struct phy_ops *ops, struct phy_init_data *init_data)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_destroy(struct phy *phy)
+{
+}
+
+static inline void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy_provider *__of_phy_provider_register(
+	struct device *dev, struct module *owner, struct phy * (*of_xlate)(
+	struct device *dev, struct of_phandle_args *args))
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy_provider *__devm_of_phy_provider_register(struct device
+	*dev, struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void of_phy_provider_unregister(struct phy_provider *phy_provider)
+{
+}
+
+static inline void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider)
+{
+}
+#endif
+
+#endif /* __DRIVERS_PHY_H */
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:49:19 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:19:19 +0530
Subject: [RESEND PATCH v10 4/8] arm: omap3: twl: add phy consumer data in
 twl4030_usb_data
In-Reply-To: <1374842963-13545-1-git-send-email-kishon@ti.com>
References: <1374842963-13545-1-git-send-email-kishon@ti.com>
Message-ID: <1374842963-13545-5-git-send-email-kishon@ti.com>

The PHY framework uses the phy consumer data populated in platform data in the
case of non-dt boot to return the reference to the PHY when the controller
(PHY consumer) requests for it. So populated the phy consumer data in the platform
data of twl usb.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 arch/arm/mach-omap2/twl-common.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index c05898f..b0d54da 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -24,6 +24,7 @@
 #include <linux/i2c/twl.h>
 #include <linux/gpio.h>
 #include <linux/string.h>
+#include <linux/phy/phy.h>
 #include <linux/regulator/machine.h>
 #include <linux/regulator/fixed.h>
 
@@ -90,8 +91,18 @@ void __init omap_pmic_late_init(void)
 }
 
 #if defined(CONFIG_ARCH_OMAP3)
+struct phy_consumer consumers[] = {
+	PHY_CONSUMER("musb-hdrc.0", "usb"),
+};
+
+struct phy_init_data init_data = {
+	.consumers = consumers,
+	.num_consumers = ARRAY_SIZE(consumers),
+};
+
 static struct twl4030_usb_data omap3_usb_pdata = {
 	.usb_mode	= T2_USB_MODE_ULPI,
+	.init_data	= &init_data,
 };
 
 static int omap3_batt_table[] = {
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:49:18 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:19:18 +0530
Subject: [RESEND PATCH v10 3/8] usb: phy: twl4030: use the new generic PHY
 framework
In-Reply-To: <1374842963-13545-1-git-send-email-kishon@ti.com>
References: <1374842963-13545-1-git-send-email-kishon@ti.com>
Message-ID: <1374842963-13545-4-git-send-email-kishon@ti.com>

Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed. Also twl4030-usb driver is moved
to drivers/phy/.

However using the old usb phy library cannot be completely removed
because otg is intertwined with phy and moving to the new
framework completely will break otg. Once we have a separate otg state machine,
we can get rid of the usb phy library.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 drivers/phy/Kconfig                     |   11 ++++++
 drivers/phy/Makefile                    |    1 +
 drivers/{usb => }/phy/phy-twl4030-usb.c |   56 +++++++++++++++++++++++++++++--
 drivers/usb/phy/Kconfig                 |    9 -----
 drivers/usb/phy/Makefile                |    1 -
 include/linux/i2c/twl.h                 |    2 ++
 6 files changed, 67 insertions(+), 13 deletions(-)
 rename drivers/{usb => }/phy/phy-twl4030-usb.c (95%)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 38c3477..ac239ac 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -27,4 +27,15 @@ config OMAP_USB2
 	  The USB OTG controller communicates with the comparator using this
 	  driver.
 
+config TWL4030_USB
+	tristate "TWL4030 USB Transceiver Driver"
+	depends on TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS
+	select GENERIC_PHY
+	select USB_PHY
+	help
+	  Enable this to support the USB OTG transceiver on TWL4030
+	  family chips (including the TWL5030 and TPS659x0 devices).
+	  This transceiver supports high and full speed devices plus,
+	  in host mode, low speed.
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index ed5b088..0dd8a98 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
 obj-$(CONFIG_OMAP_USB2)		+= phy-omap-usb2.o
+obj-$(CONFIG_TWL4030_USB)	+= phy-twl4030-usb.o
diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
similarity index 95%
rename from drivers/usb/phy/phy-twl4030-usb.c
rename to drivers/phy/phy-twl4030-usb.c
index 8f78d2d..494f107 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -33,6 +33,7 @@
 #include <linux/io.h>
 #include <linux/delay.h>
 #include <linux/usb/otg.h>
+#include <linux/phy/phy.h>
 #include <linux/usb/musb-omap.h>
 #include <linux/usb/ulpi.h>
 #include <linux/i2c/twl.h>
@@ -431,6 +432,14 @@ static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
 	dev_dbg(twl->dev, "%s\n", __func__);
 }
 
+static int twl4030_phy_power_off(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	twl4030_phy_suspend(twl, 0);
+	return 0;
+}
+
 static void __twl4030_phy_resume(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
@@ -459,6 +468,14 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 	}
 }
 
+static int twl4030_phy_power_on(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	twl4030_phy_resume(twl);
+	return 0;
+}
+
 static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
 {
 	/* Enable writing to power configuration registers */
@@ -602,13 +619,22 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 	status = twl4030_usb_linkstat(twl);
 	twl->linkstat = status;
 
-	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
+	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
 		omap_musb_mailbox(twl->linkstat);
+		twl4030_phy_resume(twl);
+	}
 
 	sysfs_notify(&twl->dev->kobj, NULL, "vbus");
 	return 0;
 }
 
+static int twl4030_phy_init(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	return twl4030_usb_phy_init(&twl->phy);
+}
+
 static int twl4030_set_suspend(struct usb_phy *x, int suspend)
 {
 	struct twl4030_usb *twl = phy_to_twl(x);
@@ -646,13 +672,23 @@ static int twl4030_set_host(struct usb_otg *otg, struct usb_bus *host)
 	return 0;
 }
 
+static const struct phy_ops ops = {
+	.init		= twl4030_phy_init,
+	.power_on	= twl4030_phy_power_on,
+	.power_off	= twl4030_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
 static int twl4030_usb_probe(struct platform_device *pdev)
 {
 	struct twl4030_usb_data *pdata = pdev->dev.platform_data;
 	struct twl4030_usb	*twl;
+	struct phy		*phy;
 	int			status, err;
 	struct usb_otg		*otg;
 	struct device_node	*np = pdev->dev.of_node;
+	struct phy_provider	*phy_provider;
+	struct phy_init_data	*init_data = NULL;
 
 	twl = devm_kzalloc(&pdev->dev, sizeof *twl, GFP_KERNEL);
 	if (!twl)
@@ -661,9 +697,10 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	if (np)
 		of_property_read_u32(np, "usb_mode",
 				(enum twl4030_usb_mode *)&twl->usb_mode);
-	else if (pdata)
+	else if (pdata) {
 		twl->usb_mode = pdata->usb_mode;
-	else {
+		init_data = pdata->init_data;
+	} else {
 		dev_err(&pdev->dev, "twl4030 initialized without pdata\n");
 		return -EINVAL;
 	}
@@ -689,6 +726,19 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	otg->set_host		= twl4030_set_host;
 	otg->set_peripheral	= twl4030_set_peripheral;
 
+	phy_provider = devm_of_phy_provider_register(twl->dev,
+		of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	phy = devm_phy_create(twl->dev, &ops, init_data);
+	if (IS_ERR(phy)) {
+		dev_dbg(&pdev->dev, "Failed to create PHY\n");
+		return PTR_ERR(phy);
+	}
+
+	phy_set_drvdata(phy, twl);
+
 	/* init spinlock for workqueue */
 	spin_lock_init(&twl->lock);
 
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 7813238..1e05b1d 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -102,15 +102,6 @@ config SAMSUNG_USB3PHY
 	  Enable this to support Samsung USB 3.0 (Super Speed) phy controller
 	  for samsung SoCs.
 
-config TWL4030_USB
-	tristate "TWL4030 USB Transceiver Driver"
-	depends on TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS
-	help
-	  Enable this to support the USB OTG transceiver on TWL4030
-	  family chips (including the TWL5030 and TPS659x0 devices).
-	  This transceiver supports high and full speed devices plus,
-	  in host mode, low speed.
-
 config TWL6030_USB
 	tristate "TWL6030 USB Transceiver Driver"
 	depends on TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 56d2b03..7bcc9ed0 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -20,7 +20,6 @@ obj-$(CONFIG_OMAP_USB3)			+= phy-omap-usb3.o
 obj-$(CONFIG_SAMSUNG_USBPHY)		+= phy-samsung-usb.o
 obj-$(CONFIG_SAMSUNG_USB2PHY)		+= phy-samsung-usb2.o
 obj-$(CONFIG_SAMSUNG_USB3PHY)		+= phy-samsung-usb3.o
-obj-$(CONFIG_TWL4030_USB)		+= phy-twl4030-usb.o
 obj-$(CONFIG_TWL6030_USB)		+= phy-twl6030-usb.o
 obj-$(CONFIG_USB_EHCI_TEGRA)		+= phy-tegra-usb.o
 obj-$(CONFIG_USB_GPIO_VBUS)		+= phy-gpio-vbus-usb.o
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 81cbbdb..673a3ce 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -26,6 +26,7 @@
 #define __TWL_H_
 
 #include <linux/types.h>
+#include <linux/phy/phy.h>
 #include <linux/input/matrix_keypad.h>
 
 /*
@@ -615,6 +616,7 @@ enum twl4030_usb_mode {
 struct twl4030_usb_data {
 	enum twl4030_usb_mode	usb_mode;
 	unsigned long		features;
+	struct phy_init_data	*init_data;
 
 	int		(*phy_init)(struct device *dev);
 	int		(*phy_exit)(struct device *dev);
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:49:20 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:19:20 +0530
Subject: [RESEND PATCH v10 5/8] ARM: dts: omap: update usb_otg_hs data
In-Reply-To: <1374842963-13545-1-git-send-email-kishon@ti.com>
References: <1374842963-13545-1-git-send-email-kishon@ti.com>
Message-ID: <1374842963-13545-6-git-send-email-kishon@ti.com>

Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +++++
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 ++++++
 arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 ++
 arch/arm/boot/dts/omap3-evm.dts                    |    2 ++
 arch/arm/boot/dts/omap3-overo.dtsi                 |    2 ++
 arch/arm/boot/dts/omap4.dtsi                       |    3 +++
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 7 files changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 57e71f6..825790d 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
  - power : Should be "50". This signifies the controller can supply up to
    100mA when operating in host mode.
  - usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phy* phandle.
 
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs at 4a0ab000 {
 	num-eps = <16>;
 	ram-bits = <12>;
 	ctrl-module = <&omap_control_usb>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 };
 
 Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
 Required properties:
  - compatible: Should be "ti,omap-usb2"
  - reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy at 4a0ad080 {
 	compatible = "ti,omap-usb2";
 	reg = <0x4a0ad080 0x58>;
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
 
 OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the registers
    filled in "reg".
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy at 4a084400 {
 	      <0x4a084c00 0x40>;
 	reg-names = "phy_rx", "phy_tx", "pll_ctrl";
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..533b2da 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -144,6 +144,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 7d4329d..4134dd0 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -70,6 +70,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
index 8f1abec..a461d2f 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -76,6 +76,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..1e8e2fe 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -520,6 +520,7 @@
 				compatible = "ti,omap-usb2";
 				reg = <0x4a0ad080 0x58>;
 				ctrl-module = <&omap_control_usb>;
+				#phy-cells = <0>;
 			};
 		};
 
@@ -658,6 +659,8 @@
 			interrupt-names = "mc", "dma";
 			ti,hwmods = "usb_otg_hs";
 			usb-phy = <&usb2_phy>;
+			phys = <&usb2_phy>;
+			phy-names = "usb2-phy";
 			multipoint = <1>;
 			num-eps = <16>;
 			ram-bits = <12>;
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index b3034da..ce4cd6f 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -80,6 +80,7 @@
 		usb1v8-supply = <&vusb1v8>;
 		usb3v1-supply = <&vusb3v1>;
 		usb_mode = <1>;
+		#phy-cells = <0>;
 	};
 
 	twl_pwm: pwm {
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:49:21 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:19:21 +0530
Subject: [RESEND PATCH v10 6/8] usb: musb: omap2430: use the new generic PHY
 framework
In-Reply-To: <1374842963-13545-1-git-send-email-kishon@ti.com>
References: <1374842963-13545-1-git-send-email-kishon@ti.com>
Message-ID: <1374842963-13545-7-git-send-email-kishon@ti.com>

Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on and
power_off to align with the new PHY framework.

musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Acked-by: Felipe Balbi <balbi at ti.com>
---
 drivers/usb/musb/Kconfig     |    1 +
 drivers/usb/musb/musb_core.h |    2 ++
 drivers/usb/musb/omap2430.c  |   26 ++++++++++++++++++++------
 3 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 797e3fd..25e2e57 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -76,6 +76,7 @@ config USB_MUSB_TUSB6010
 config USB_MUSB_OMAP2PLUS
 	tristate "OMAP2430 and onwards"
 	depends on ARCH_OMAP2PLUS
+	select GENERIC_PHY
 
 config USB_MUSB_AM35X
 	tristate "AM35x"
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7d341c3..6e567bd 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
 #include <linux/usb.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/musb.h>
+#include <linux/phy/phy.h>
 
 struct musb;
 struct musb_hw_ep;
@@ -346,6 +347,7 @@ struct musb {
 	u16			int_tx;
 
 	struct usb_phy		*xceiv;
+	struct phy		*phy;
 
 	int nIrq;
 	unsigned		irq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 6708a3b..f7b33f4 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -348,11 +348,21 @@ static int omap2430_musb_init(struct musb *musb)
 	 * up through ULPI.  TWL4030-family PMICs include one,
 	 * which needs a driver, drivers aren't always needed.
 	 */
-	if (dev->parent->of_node)
+	if (dev->parent->of_node) {
+		musb->phy = devm_phy_get(dev->parent, "usb2-phy");
+
+		/* We can't totally remove musb->xceiv as of now because
+		 * musb core uses xceiv.state and xceiv.otg. Once we have
+		 * a separate state machine to handle otg, these can be moved
+		 * out of xceiv and then we can start using the generic PHY
+		 * framework
+		 */
 		musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
 		    "usb-phy", 0);
-	else
+	} else {
 		musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+		musb->phy = devm_phy_get(dev, "usb");
+	}
 
 	if (IS_ERR(musb->xceiv)) {
 		status = PTR_ERR(musb->xceiv);
@@ -364,6 +374,10 @@ static int omap2430_musb_init(struct musb *musb)
 		return -EPROBE_DEFER;
 	}
 
+	if (IS_ERR(musb->phy)) {
+		pr_err("HS USB OTG: no PHY configured\n");
+		return PTR_ERR(musb->phy);
+	}
 	musb->isr = omap2430_musb_interrupt;
 
 	status = pm_runtime_get_sync(dev);
@@ -397,7 +411,7 @@ static int omap2430_musb_init(struct musb *musb)
 	if (glue->status != OMAP_MUSB_UNKNOWN)
 		omap_musb_set_mailbox(glue);
 
-	usb_phy_init(musb->xceiv);
+	phy_init(musb->phy);
 
 	pm_runtime_put_noidle(musb->controller);
 	return 0;
@@ -460,6 +474,7 @@ static int omap2430_musb_exit(struct musb *musb)
 	del_timer_sync(&musb_idle_timer);
 
 	omap2430_low_level_exit(musb);
+	phy_exit(musb->phy);
 
 	return 0;
 }
@@ -633,7 +648,7 @@ static int omap2430_runtime_suspend(struct device *dev)
 				OTG_INTERFSEL);
 
 		omap2430_low_level_exit(musb);
-		usb_phy_set_suspend(musb->xceiv, 1);
+		phy_power_off(musb->phy);
 	}
 
 	return 0;
@@ -648,8 +663,7 @@ static int omap2430_runtime_resume(struct device *dev)
 		omap2430_low_level_init(musb);
 		musb_writel(musb->mregs, OTG_INTERFSEL,
 				musb->context.otg_interfsel);
-
-		usb_phy_set_suspend(musb->xceiv, 0);
+		phy_power_on(musb->phy);
 	}
 
 	return 0;
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:49:22 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:19:22 +0530
Subject: [RESEND PATCH v10 7/8] usb: phy: omap-usb2: remove *set_suspend*
 callback from omap-usb2
In-Reply-To: <1374842963-13545-1-git-send-email-kishon@ti.com>
References: <1374842963-13545-1-git-send-email-kishon@ti.com>
Message-ID: <1374842963-13545-8-git-send-email-kishon@ti.com>

Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 drivers/phy/phy-omap-usb2.c |   25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 25e0f3c..dec3fab 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -97,29 +97,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
 	return 0;
 }
 
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
-	u32 ret;
-	struct omap_usb *phy = phy_to_omapusb(x);
-
-	if (suspend && !phy->is_suspended) {
-		omap_control_usb_phy_power(phy->control_dev, 0);
-		pm_runtime_put_sync(phy->dev);
-		phy->is_suspended = 1;
-	} else if (!suspend && phy->is_suspended) {
-		ret = pm_runtime_get_sync(phy->dev);
-		if (ret < 0) {
-			dev_err(phy->dev, "get_sync failed with err %d\n",
-									ret);
-			return ret;
-		}
-		omap_control_usb_phy_power(phy->control_dev, 1);
-		phy->is_suspended = 0;
-	}
-
-	return 0;
-}
-
 static int omap_usb_power_off(struct phy *x)
 {
 	struct omap_usb *phy = phy_get_drvdata(x);
@@ -167,7 +144,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
 	phy->phy.dev		= phy->dev;
 	phy->phy.label		= "omap-usb2";
-	phy->phy.set_suspend	= omap_usb2_suspend;
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
@@ -182,7 +158,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	phy->is_suspended	= 1;
 	omap_control_usb_phy_power(phy->control_dev, 0);
 
 	otg->set_host		= omap_usb_set_host;
-- 
1.7.10.4



From kishon at ti.com  Fri Jul 26 08:49:23 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 26 Jul 2013 18:19:23 +0530
Subject: [RESEND PATCH v10 8/8] usb: phy: twl4030-usb: remove *set_suspend*
 and *phy_init* ops
In-Reply-To: <1374842963-13545-1-git-send-email-kishon@ti.com>
References: <1374842963-13545-1-git-send-email-kishon@ti.com>
Message-ID: <1374842963-13545-9-git-send-email-kishon@ti.com>

Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Acked-by: Felipe Balbi <balbi at ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
---
 drivers/phy/phy-twl4030-usb.c |   57 ++++++++++-------------------------------
 1 file changed, 13 insertions(+), 44 deletions(-)

diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 494f107..c437211 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -422,25 +422,20 @@ static void twl4030_phy_power(struct twl4030_usb *twl, int on)
 	}
 }
 
-static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
+static int twl4030_phy_power_off(struct phy *phy)
 {
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
 	if (twl->asleep)
-		return;
+		return 0;
 
 	twl4030_phy_power(twl, 0);
 	twl->asleep = 1;
 	dev_dbg(twl->dev, "%s\n", __func__);
-}
-
-static int twl4030_phy_power_off(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	twl4030_phy_suspend(twl, 0);
 	return 0;
 }
 
-static void __twl4030_phy_resume(struct twl4030_usb *twl)
+static void __twl4030_phy_power_on(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
 	twl4030_i2c_access(twl, 1);
@@ -449,11 +444,13 @@ static void __twl4030_phy_resume(struct twl4030_usb *twl)
 		twl4030_i2c_access(twl, 0);
 }
 
-static void twl4030_phy_resume(struct twl4030_usb *twl)
+static int twl4030_phy_power_on(struct phy *phy)
 {
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
 	if (!twl->asleep)
-		return;
-	__twl4030_phy_resume(twl);
+		return 0;
+	__twl4030_phy_power_on(twl);
 	twl->asleep = 0;
 	dev_dbg(twl->dev, "%s\n", __func__);
 
@@ -466,13 +463,6 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 		cancel_delayed_work(&twl->id_workaround_work);
 		schedule_delayed_work(&twl->id_workaround_work, HZ);
 	}
-}
-
-static int twl4030_phy_power_on(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	twl4030_phy_resume(twl);
 	return 0;
 }
 
@@ -604,9 +594,9 @@ static void twl4030_id_workaround_work(struct work_struct *work)
 	}
 }
 
-static int twl4030_usb_phy_init(struct usb_phy *phy)
+static int twl4030_phy_init(struct phy *phy)
 {
-	struct twl4030_usb *twl = phy_to_twl(phy);
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
 	enum omap_musb_vbus_id_status status;
 
 	/*
@@ -621,32 +611,13 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 
 	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
 		omap_musb_mailbox(twl->linkstat);
-		twl4030_phy_resume(twl);
+		twl4030_phy_power_on(phy);
 	}
 
 	sysfs_notify(&twl->dev->kobj, NULL, "vbus");
 	return 0;
 }
 
-static int twl4030_phy_init(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	return twl4030_usb_phy_init(&twl->phy);
-}
-
-static int twl4030_set_suspend(struct usb_phy *x, int suspend)
-{
-	struct twl4030_usb *twl = phy_to_twl(x);
-
-	if (suspend)
-		twl4030_phy_suspend(twl, 1);
-	else
-		twl4030_phy_resume(twl);
-
-	return 0;
-}
-
 static int twl4030_set_peripheral(struct usb_otg *otg,
 					struct usb_gadget *gadget)
 {
@@ -719,8 +690,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	twl->phy.label		= "twl4030";
 	twl->phy.otg		= otg;
 	twl->phy.type		= USB_PHY_TYPE_USB2;
-	twl->phy.set_suspend	= twl4030_set_suspend;
-	twl->phy.init		= twl4030_usb_phy_init;
 
 	otg->phy		= &twl->phy;
 	otg->set_host		= twl4030_set_host;
-- 
1.7.10.4



From will.deacon at arm.com  Fri Jul 26 09:05:51 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 26 Jul 2013 14:05:51 +0100
Subject: [RFC PATCH] ARM: dma: default ZONE_DMA to y if ARM_LPAE
Message-ID: <1374843951-1615-1-git-send-email-will.deacon@arm.com>

On systems running with LPAE enabled, DMA masters capable only of 32-bit
addressing require ZONE_DMA to be set. Given the proliferation of such
masters, and the tendency to re-use existing system IP with newer
processors, this patch defaults ZONE_DMA to y if ARM_LPAE, rather than
force each SoC to select it individually.

Cc: Olof Johansson <olof at lixom.net>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 82f06982..7fede35 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -192,6 +192,7 @@ config ARCH_MAY_HAVE_PC_FDC
 
 config ZONE_DMA
 	bool
+	default y if ARM_LPAE
 
 config NEED_DMA_MAP_STATE
        def_bool y
-- 
1.8.2.2



From richardcochran at gmail.com  Fri Jul 26 09:09:29 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Fri, 26 Jul 2013 15:09:29 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <1374831744.2923.42.camel@shinybook.infradead.org>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
Message-ID: <20130726130927.GC4219@netboy>

On Fri, Jul 26, 2013 at 10:42:24AM +0100, David Woodhouse wrote:
> On Fri, 2013-07-26 at 10:01 +0200, Richard Cochran wrote:
> > On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
> > > 
> > > We use DT has a kernel configuration input. Our environment is
> > > designed to guarantee 100% that the kernel and DT match exactly. DT
> > > very deliberately isn't an ABI boundary in our systems.
> > 
> > Think about what you just said.
> > 
> > The DT describes the *hardware* not the kernel. Why should you ever
> > need to update your DT at all?
> 
> Well, the nodes which describe hardware devices, according to the
> bindings which form an ABI contract between DT and drivers, should not
> normally change. Although they *can* change, if for example you change
> the MAC address and that's stored there. Or you change the PHY you want
> it to use. Or something like that. The *ABI* doesn't change, but the
> data you express *using* that ABI can change. That's kind of the point.

Unless I totally misunderstood, the thread is talking about letting
established bindings change with each new kernel version.  I am
opposed to that.

Of course, a user may want to change the values of his MAC addresses,
if he needs to. But he should never have to change *how* he specifies
those addresses.

So, as long as everyone can agree to the principle that a working DT
should remain working after a kernel upgrade, then I'll shut up. In
actual fact, this is not the case today, nor was it ever so in the
past, AFAICT, but it never hurts to set goals.

Thanks,
Richard


From jonas.jensen at gmail.com  Fri Jul 26 09:12:01 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Fri, 26 Jul 2013 15:12:01 +0200
Subject: [PATCH] net: Add MOXA ART SoCs ethernet driver
In-Reply-To: <CAGVrzcYdisg5AXMBa5q74GPz7ckWeoXJ9H5di2CGN41VyZ_4vw@mail.gmail.com>
References: <1374140806-12485-1-git-send-email-jonas.jensen@gmail.com>
 <CAGVrzcYdisg5AXMBa5q74GPz7ckWeoXJ9H5di2CGN41VyZ_4vw@mail.gmail.com>
Message-ID: <CACmBeS0Q_WNc17VSALyMPPKzN1wyLUccBLDJpbapVwxq4gdytQ@mail.gmail.com>

Hi Florian,

Thanks for your help on IRC with this. I think most of the issues you
pointed out should be fixed. Comments on still unresolved below:

On 22 July 2013 13:09, Florian Fainelli <florian at openwrt.org> wrote:
>> +++ b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
>> @@ -0,0 +1,25 @@
>> +MOXA ART Ethernet Controller
>> +
>> +Required properties:
>> +
>> +- compatible : Should be "moxa,moxart-mac"
>> +- reg : Should contain registers location and length
>> +  index 0 : main register
>> +  index 1 : mac address (stored on flash)
>
> That is kind of unusual, since the MAC register is within the range of
> the MAC base register, just read the MAC from the base register and
> use that to fill in dev->dev_addr in your ndo_open() callback.

It is, but MAC is zeroed out in controller register after boot. That's why it
has to be read from flash memory (bootloader section), and the reason
it needs to map flash memory at all.

>> +
>> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>> +
>> +       /* the flash driver (physmap_of) requests the same region
>> +        * so use ioremap instead of devm_ioremap_resource
>> +        */
>> +       priv->flash_base = ioremap(res->start, resource_size(res));
>> +       if (IS_ERR(priv->flash_base)) {
>> +               dev_err(p_dev, "%s: devm_ioremap_resource res_flash failed\n",
>> +                       __func__);
>> +               goto init_fail;
>> +       }
>
> As stated above from the Device Tree binding documentation, this is
> unnecessary, since you have a get_mac() function.

This is what the node looks like right now:

mac0: mac at 90900000 {
compatible = "moxa,moxart-mac";
reg = <0x90900000 0x100>,
        <0x80000050 0x6>;
interrupts = <25 0>;
};

Bootloader starts at 0x80000000, looks like MAC is stored in code. I
currently see no way around mapping both registers.

Best regards,
Jonas


From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:37 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:37 -0300
Subject: [PATCH v9 00/30] MBus DT binding for Armada 370/XP and Kirkwood
Message-ID: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>

This is a minor revision of the patchset, splitting patches with DT bindings
changes to separate patches. See the changelog for more context information.

Except for this patch splitting, this can be considered as a v8 resend.

This has been tested on several Armada 370/XP boards, and on Plathome Openblocks
A6 Kirkwood board by myself; Kirkwood and Dove testing has been performed by
Andrew Lunn and Sebastian Hesselbarth respectively.

If anyone wants to do further testing, there's a public branch:

  https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v9

At this point all that's left is to have formal Acked-by from some DT maintainer/s
to the DT binding itself.

This is based on v3.11-rc2.

Changelog
---------

v9:

 * Split DT bindings in separate patches and send only these to the devicetree
   mailing list to avoid overloading it, as suggested by Olof Johansson.

v8:

 * Introduce Kirkwood MBus DT binding and use it to relocate
   the PCIe nodes *only*.

 * Allow MBus to initialize when the node has no ranges property.

 * Add a sanity check for PCIe port base address to prevent a kernel
   panic when this address has not been obtained. Instead of panic,
   the PCIe won't work in such cases.

v7:

 * Add two optional properties pcie-{mem,io}-aperture to the MBus node
   defining the PCIe mem and IO region apertures.

 * Encode the PCIe port in the second cell of the ranges entries, using
   the PCIe slot; and remove such encoding from the first cell, since it
   was violating the specification.

   Quoting Jason Gunthorpe:
   """ [...] the OF spec says that the phys.hi fields of the child address
   spaces in the "ranges" property for PCI does not contain the same
   information as "reg" property entries within PCI nodes. The only information
   that is present in "ranges" phys.hi entries are the non-relocatable,
   prefetchable and the PCI address space bits for which the entry applies.
   I.e., only the n, p and ss bits are present; the bbbbbbbb, ddddd, fff and
   rrrrrrrr fields are 0."""

v6:

 * Change the PCIe ranges translations encoding, removing the big fake
   window encoded as MBUS_ID(0xf0, 0x02) by an array of entries representing
   the PCIe real windows with full 4 GiB size.

 * The corresponding PCIe port is selected by encoding the bus in the first cell
   of the PCIe controller node ranges entry.

 * Remove the name-based MBus window allocation API, replacing it by an
   ID-based API.

v5:

 * Add a required a 'controller' property to specify a phandle containing
   the MBus controller MMIO registers.

v4:

 * Fixed the pcie-controller to mbus address space translations, to match
   a 1:1 mapping between the PCI and CPU busses.

 * Fixed the binding documentation with suggestions from Arnd Bergmann.

 * Added a BootROM sanity check on AXP SMP initialization, as suggested
   by Jason Gunthorpe. This also implied changing slightly the bootrom
   node.

 * Changed the first cell format for the MBus address space.

v3:

 * Replaced the PCIe mapping with 0xffff0002, to avoid using a representation
   that might correspond to a possible window id.

 * Remove every mbus-node 'ranges' property from the dtsi files. Having them
   on the per-board dts files only makes maintaince less painful.

 * Declare children window size, in the children 'ranges' property, as large
   as possible (4 GiB size) and move the property to the dtsi files.
   The per-board dts, does not need to declare that property now.

 * The MBus driver now creates the decoding window using the base address and
   size specified in the mbus-node, instead of using the children entries.

v2:

 * Use the preprocessor on the DT and define a macro for the window ID.

 * Changed the way the address spaces were declared: the window's base
   addresses are only present in the mbus-node ranges property.
   This makes sense since that information belongs only to the MBus
   address space.

 * Drop the ranges dynamic update, since now the DT translations are complete.

 * Replaced the internal register first cell mapping with 0xffff0001, to avoid
   clashing when using 0x00000000.

 * Replaced the PCIe mapping with 0xffff0000.

v1:

  * Initial proposal

Example
-------

Here's an example showing how the MBus DT binding looks now:

soc {
	compatible = "marvell,armadaxp-mbus", "simple-bus";
	controller = <&mbusc>;
	pcie-mem-aperture = <0xe0000000 0x8000000>;
	pcie-io-aperture  = <0xe8000000 0x100000>;

	ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
		  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
		  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;

	bootrom {
		compatible = "marvell,bootrom";
		reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
	};

	devbus-bootcs {
		status = "okay";
		ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;

		/* NOR */
		nor {
			compatible = "cfi-flash";
			reg = <0 0x8000000>;
			bank-width = <2>;
		};
	};

	pcie-controller {
		compatible = "marvell,armada-xp-pcie";
		status = "okay";
		device_type = "pci";
		#address-cells = <3>;
		#size-cells = <2>;

		ranges =
			<0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
			0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
			0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
			0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
			0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
			0x82000000 0x1 0       MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
			0x81000000 0x1 0       MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */
			0x82000000 0x2 0       MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
			0x81000000 0x2 0       MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */>;


		pcie at 1,0 {
			device_type = "pci";
			assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
			reg = <0x0800 0 0 0 0>;
			#address-cells = <3>;
			#size-cells = <2>;
			#interrupt-cells = <1>;
			ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
				  0x81000000 0 0 0x81000000 0x1 0 1 0>;
			interrupt-map-mask = <0 0 0 0>;
			interrupt-map = <0 0 0 0 &mpic 58>;
			marvell,pcie-port = <0>;
			marvell,pcie-lane = <0>;
			clocks = <&gateclk 5>;
			status = "disabled";
		};

		pcie at 2,0 {
			device_type = "pci";
			assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
			reg = <0x1000 0 0 0 0>;
			#address-cells = <3>;
			#size-cells = <2>;
			#interrupt-cells = <1>;
			ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
				  0x81000000 0 0 0x81000000 0x2 0 1 0>;
			interrupt-map-mask = <0 0 0 0>;
			interrupt-map = <0 0 0 0 &mpic 62>;
			marvell,pcie-port = <1>;
			marvell,pcie-lane = <0>;
			clocks = <&gateclk 9>;
			status = "disabled";
		};
	};

	internal-regs {
		compatible = "simple-bus";
		#address-cells = <1>;
		#size-cells = <1>;
		ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;

		mbusc: mbus-controller at 20000 {
			reg = <0x20000 0x100>, <0x20180 0x20>;
		};

		interrupt-controller at 20000 {
			reg = <0x20a00 0x2d0>, <0x21070 0x58>;
		};
	};
};


Ezequiel Garcia (19):
  memory: mvebu-devbus: Remove address decoding window workaround
  bus: mvebu-mbus: Factor out initialization details
  bus: mvebu-mbus: Introduce device tree binding
  bus: mvebu-mbus: Add static window allocation to the DT binding
  bus: mvebu-mbus: Add new API for the PCIe memory and IO aperture
  PCI: mvebu: Check valid base address before port setup
  ARM: mvebu: Remove the harcoded BootROM window allocation
  ARM: mvebu: Initialize MBus using the DT binding
  ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
  ARM: mvebu: Add MBus to Armada 370/XP device tree
  ARM: mvebu: Add BootROM to Armada 370/XP device tree
  ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
  ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes
  ARM: kirkwood: Split DT and legacy MBus initialization
  ARM: kirkwood: Use the preprocessor on device tree files
  ARM: kirkwood: Introduce MBus DT node
  ARM: kirkwood: Introduce MBUS_ID
  ARM: kirkwood: Relocate PCIe device tree nodes
  bus: mvebu-mbus: Add devicetree binding

Thomas Petazzoni (11):
  bus: mvebu-mbus: Add new API for window creation
  ARM: kirkwood: Move to ID based MBus window creation
  ARM: mv78xx0: Move to ID based window creation
  ARM: orion5x: Move to ID based window creation
  ARM: dove: Move to ID based window creation
  PCI: mvebu: Adapt to the new device tree layout
  bus: mvebu-mbus: Remove the no longer used name-based API
  bus: mvebu-mbus: Remove name -> target, attribute mapping tables
  bus: mvebu-mbus: Update main description
  bus: mvebu-mbus: Factorize Armada 370/XP data structures
  PCI: mvebu: Adapt to the new device tree layout

 .../devicetree/bindings/bus/mvebu-mbus.txt         | 276 +++++++++++++
 .../devicetree/bindings/pci/mvebu-pci.txt          | 145 +++++--
 arch/arm/boot/dts/armada-370-db.dts                |   5 +-
 arch/arm/boot/dts/armada-370-mirabox.dts           |  37 +-
 arch/arm/boot/dts/armada-370-rd.dts                |   5 +-
 arch/arm/boot/dts/armada-370-xp.dtsi               | 111 +++---
 arch/arm/boot/dts/armada-370.dtsi                  | 112 +++---
 arch/arm/boot/dts/armada-xp-db.dts                 | 131 +++---
 arch/arm/boot/dts/armada-xp-gp.dts                 | 107 +++--
 arch/arm/boot/dts/armada-xp-mv78230.dtsi           | 222 ++++++-----
 arch/arm/boot/dts/armada-xp-mv78260.dtsi           | 263 ++++++------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi           | 411 ++++++++++---------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |  88 ++--
 arch/arm/boot/dts/armada-xp.dtsi                   |   9 +-
 arch/arm/boot/dts/kirkwood-6281.dtsi               |  66 +--
 arch/arm/boot/dts/kirkwood-6282.dtsi               | 102 ++---
 arch/arm/boot/dts/kirkwood-cloudbox.dts            |   4 +-
 arch/arm/boot/dts/kirkwood-db-88f6281.dts          |   7 +-
 arch/arm/boot/dts/kirkwood-db-88f6282.dts          |   7 +-
 arch/arm/boot/dts/kirkwood-db.dtsi                 |  10 +-
 arch/arm/boot/dts/kirkwood-dns320.dts              |   2 +-
 arch/arm/boot/dts/kirkwood-dns325.dts              |   2 +-
 arch/arm/boot/dts/kirkwood-dnskw.dtsi              |   4 +-
 arch/arm/boot/dts/kirkwood-dockstar.dts            |   4 +-
 arch/arm/boot/dts/kirkwood-dreamplug.dts           |   4 +-
 arch/arm/boot/dts/kirkwood-goflexnet.dts           |   4 +-
 .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |   4 +-
 arch/arm/boot/dts/kirkwood-ib62x0.dts              |   4 +-
 arch/arm/boot/dts/kirkwood-iconnect.dts            |  23 +-
 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts      |   4 +-
 arch/arm/boot/dts/kirkwood-is2.dts                 |   2 +-
 arch/arm/boot/dts/kirkwood-km_kirkwood.dts         |   4 +-
 arch/arm/boot/dts/kirkwood-lschlv2.dts             |   2 +-
 arch/arm/boot/dts/kirkwood-lsxhl.dts               |   2 +-
 arch/arm/boot/dts/kirkwood-lsxl.dtsi               |   4 +-
 arch/arm/boot/dts/kirkwood-mplcec4.dts             |  23 +-
 .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  |  23 +-
 arch/arm/boot/dts/kirkwood-ns2-common.dtsi         |   4 +-
 arch/arm/boot/dts/kirkwood-ns2.dts                 |   2 +-
 arch/arm/boot/dts/kirkwood-ns2lite.dts             |   2 +-
 arch/arm/boot/dts/kirkwood-ns2max.dts              |   2 +-
 arch/arm/boot/dts/kirkwood-ns2mini.dts             |   2 +-
 arch/arm/boot/dts/kirkwood-nsa310.dts              |  23 +-
 arch/arm/boot/dts/kirkwood-openblocks_a6.dts       |   4 +-
 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi  |   4 +-
 arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts    |   2 +-
 arch/arm/boot/dts/kirkwood-sheevaplug.dts          |   2 +-
 arch/arm/boot/dts/kirkwood-topkick.dts             |   4 +-
 arch/arm/boot/dts/kirkwood-ts219-6281.dts          |   6 +-
 arch/arm/boot/dts/kirkwood-ts219-6282.dts          |  25 +-
 arch/arm/boot/dts/kirkwood-ts219.dtsi              |  17 +-
 arch/arm/boot/dts/kirkwood.dtsi                    |  17 +-
 arch/arm/mach-dove/common.c                        |  68 ++--
 arch/arm/mach-kirkwood/board-dt.c                  |   1 +
 arch/arm/mach-kirkwood/common.c                    |  26 +-
 arch/arm/mach-kirkwood/pcie.c                      |  40 +-
 arch/arm/mach-mv78xx0/pcie.c                       |  23 +-
 arch/arm/mach-mvebu/armada-370-xp.c                |  34 +-
 arch/arm/mach-mvebu/platsmp.c                      |  25 +-
 arch/arm/mach-orion5x/common.c                     |  36 +-
 arch/arm/mach-orion5x/common.h                     |  17 +
 arch/arm/mach-orion5x/d2net-setup.c                |   6 +-
 arch/arm/mach-orion5x/db88f5281-setup.c            |  24 +-
 arch/arm/mach-orion5x/dns323-setup.c               |   6 +-
 arch/arm/mach-orion5x/edmini_v2-setup.c            |   6 +-
 arch/arm/mach-orion5x/kurobox_pro-setup.c          |  12 +-
 arch/arm/mach-orion5x/ls-chl-setup.c               |   6 +-
 arch/arm/mach-orion5x/ls_hgl-setup.c               |   6 +-
 arch/arm/mach-orion5x/lsmini-setup.c               |   6 +-
 arch/arm/mach-orion5x/mss2-setup.c                 |   6 +-
 arch/arm/mach-orion5x/mv2120-setup.c               |   6 +-
 arch/arm/mach-orion5x/net2big-setup.c              |   6 +-
 arch/arm/mach-orion5x/pci.c                        |   9 +-
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c       |   6 +-
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c        |   6 +-
 arch/arm/mach-orion5x/rd88f5182-setup.c            |  13 +-
 arch/arm/mach-orion5x/terastation_pro2-setup.c     |   6 +-
 arch/arm/mach-orion5x/ts209-setup.c                |   6 +-
 arch/arm/mach-orion5x/ts409-setup.c                |   6 +-
 arch/arm/mach-orion5x/wnr854t-setup.c              |   6 +-
 arch/arm/mach-orion5x/wrt350n-v2-setup.c           |   6 +-
 drivers/bus/mvebu-mbus.c                           | 441 ++++++++++++---------
 drivers/memory/mvebu-devbus.c                      |  64 +--
 drivers/pci/host/pci-mvebu.c                       | 115 ++++--
 include/linux/mbus.h                               |  16 +-
 85 files changed, 2030 insertions(+), 1379 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt

-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:39 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:39 -0300
Subject: [PATCH v9 02/30] bus: mvebu-mbus: Add new API for window creation
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-3-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

We add an API to create MBus address decoding windows from the target
ID and attribute. This function will be used later and deprecate the
current name based scheme.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 drivers/bus/mvebu-mbus.c | 33 +++++++++++++++++++++++++--------
 include/linux/mbus.h     |  6 ++++++
 2 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 33c6947..827468a 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -748,6 +748,22 @@ static const struct of_device_id of_mvebu_mbus_ids[] = {
 /*
  * Public API of the driver
  */
+int mvebu_mbus_add_window_remap_by_id(unsigned int target,
+				      unsigned int attribute,
+				      phys_addr_t base, size_t size,
+				      phys_addr_t remap)
+{
+	struct mvebu_mbus_state *s = &mbus_state;
+
+	if (!mvebu_mbus_window_conflicts(s, base, size, target, attribute)) {
+		pr_err("cannot add window '%x:%x', conflicts with another window\n",
+		       target, attribute);
+		return -EINVAL;
+	}
+
+	return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
+}
+
 int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 				      size_t size, phys_addr_t remap,
 				      unsigned int flags)
@@ -776,14 +792,8 @@ int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 	else if (flags == MVEBU_MBUS_PCI_WA)
 		attr |= 0x28;
 
-	if (!mvebu_mbus_window_conflicts(s, base, size, target, attr)) {
-		pr_err("cannot add window '%s', conflicts with another window\n",
-		       devname);
-		return -EINVAL;
-	}
-
-	return mvebu_mbus_alloc_window(s, base, size, remap, target, attr);
-
+	return mvebu_mbus_add_window_remap_by_id(target, attr, base,
+						 size, remap);
 }
 
 int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
@@ -792,6 +802,13 @@ int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
 						 MVEBU_MBUS_NO_REMAP, 0);
 }
 
+int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
+				phys_addr_t base, size_t size)
+{
+	return mvebu_mbus_add_window_remap_by_id(target, attribute, base,
+						 size, MVEBU_MBUS_NO_REMAP);
+}
+
 int mvebu_mbus_del_window(phys_addr_t base, size_t size)
 {
 	int win;
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index dba482e..9245b66 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -62,8 +62,14 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
 int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 				      size_t size, phys_addr_t remap,
 				      unsigned int flags);
+int mvebu_mbus_add_window_remap_by_id(unsigned int target,
+				      unsigned int attribute,
+				      phys_addr_t base, size_t size,
+				      phys_addr_t remap);
 int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
 			  size_t size);
+int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
+				phys_addr_t base, size_t size);
 int mvebu_mbus_del_window(phys_addr_t base, size_t size);
 int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
 		    size_t mbus_size, phys_addr_t sdram_phys_base,
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:38 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:38 -0300
Subject: [PATCH v9 01/30] memory: mvebu-devbus: Remove address decoding window
 workaround
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-2-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus device tree binding has been introduced, remove the address
decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in
the device tree, as described by the mbus binding documentation.

Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 drivers/memory/mvebu-devbus.c | 64 ++-----------------------------------------
 1 file changed, 2 insertions(+), 62 deletions(-)

diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
index 978e8e3..94c9248 100644
--- a/drivers/memory/mvebu-devbus.c
+++ b/drivers/memory/mvebu-devbus.c
@@ -208,16 +208,11 @@ static int mvebu_devbus_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct device_node *node = pdev->dev.of_node;
-	struct device_node *parent;
 	struct devbus *devbus;
 	struct resource *res;
 	struct clk *clk;
 	unsigned long rate;
-	const __be32 *ranges;
-	int err, cs;
-	int addr_cells, p_addr_cells, size_cells;
-	int ranges_len, tuple_len;
-	u32 base, size;
+	int err;
 
 	devbus = devm_kzalloc(&pdev->dev, sizeof(struct devbus), GFP_KERNEL);
 	if (!devbus)
@@ -248,68 +243,13 @@ static int mvebu_devbus_probe(struct platform_device *pdev)
 		return err;
 
 	/*
-	 * Allocate an address window for this device.
-	 * If the device probing fails, then we won't be able to
-	 * remove the allocated address decoding window.
-	 *
-	 * FIXME: This is only a temporary hack! We need to do this here
-	 * because we still don't have device tree bindings for mbus.
-	 * Once that support is added, we will declare these address windows
-	 * statically in the device tree, and remove the window configuration
-	 * from here.
-	 */
-
-	/*
-	 * Get the CS to choose the window string.
-	 * This is a bit hacky, but it will be removed once the
-	 * address windows are declared in the device tree.
-	 */
-	cs = (((unsigned long)devbus->base) % 0x400) / 8;
-
-	/*
-	 * Parse 'ranges' property to obtain a (base,size) window tuple.
-	 * This will be removed once the address windows
-	 * are declared in the device tree.
-	 */
-	parent = of_get_parent(node);
-	if (!parent)
-		return -EINVAL;
-
-	p_addr_cells = of_n_addr_cells(parent);
-	of_node_put(parent);
-
-	addr_cells = of_n_addr_cells(node);
-	size_cells = of_n_size_cells(node);
-	tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
-
-	ranges = of_get_property(node, "ranges", &ranges_len);
-	if (ranges == NULL || ranges_len != tuple_len)
-		return -EINVAL;
-
-	base = of_translate_address(node, ranges + addr_cells);
-	if (base == OF_BAD_ADDR)
-		return -EINVAL;
-	size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
-
-	/*
-	 * Create an mbus address windows.
-	 * FIXME: Remove this, together with the above code, once the
-	 * address windows are declared in the device tree.
-	 */
-	err = mvebu_mbus_add_window(devbus_wins[cs], base, size);
-	if (err < 0)
-		return err;
-
-	/*
 	 * We need to create a child device explicitly from here to
 	 * guarantee that the child will be probed after the timing
 	 * parameters for the bus are written.
 	 */
 	err = of_platform_populate(node, NULL, NULL, dev);
-	if (err < 0) {
-		mvebu_mbus_del_window(base, size);
+	if (err < 0)
 		return err;
-	}
 
 	return 0;
 }
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:40 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:40 -0300
Subject: [PATCH v9 03/30] ARM: kirkwood: Move to ID based MBus window creation
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-4-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/mach-kirkwood/common.c | 18 ++++++++++++++----
 arch/arm/mach-kirkwood/pcie.c   | 40 ++++++++++++++++++++++++----------------
 2 files changed, 38 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index e9238b5..165e751 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -37,6 +37,12 @@
 #include <linux/platform_data/dma-mv_xor.h>
 #include "common.h"
 
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_NAND_TARGET 0x01
+#define KIRKWOOD_MBUS_NAND_ATTR   0x2f
+#define KIRKWOOD_MBUS_SRAM_TARGET 0x03
+#define KIRKWOOD_MBUS_SRAM_ATTR   0x01
+
 /*****************************************************************************
  * I/O Address Mapping
  ****************************************************************************/
@@ -672,10 +678,14 @@ char * __init kirkwood_id(void)
 
 void __init kirkwood_setup_wins(void)
 {
-	mvebu_mbus_add_window("nand", KIRKWOOD_NAND_MEM_PHYS_BASE,
-			      KIRKWOOD_NAND_MEM_SIZE);
-	mvebu_mbus_add_window("sram", KIRKWOOD_SRAM_PHYS_BASE,
-			      KIRKWOOD_SRAM_SIZE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_NAND_TARGET,
+				    KIRKWOOD_MBUS_NAND_ATTR,
+				    KIRKWOOD_NAND_MEM_PHYS_BASE,
+				    KIRKWOOD_NAND_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_SRAM_TARGET,
+				    KIRKWOOD_MBUS_SRAM_ATTR,
+				    KIRKWOOD_SRAM_PHYS_BASE,
+				    KIRKWOOD_SRAM_SIZE);
 }
 
 void __init kirkwood_l2_init(void)
diff --git a/arch/arm/mach-kirkwood/pcie.c b/arch/arm/mach-kirkwood/pcie.c
index ddcb09f..12d86f3 100644
--- a/arch/arm/mach-kirkwood/pcie.c
+++ b/arch/arm/mach-kirkwood/pcie.c
@@ -20,6 +20,16 @@
 #include <mach/bridge-regs.h>
 #include "common.h"
 
+/* These can go away once Kirkwood uses the mvebu-mbus DT binding */
+#define KIRKWOOD_MBUS_PCIE0_MEM_TARGET    0x4
+#define KIRKWOOD_MBUS_PCIE0_MEM_ATTR      0xe8
+#define KIRKWOOD_MBUS_PCIE0_IO_TARGET     0x4
+#define KIRKWOOD_MBUS_PCIE0_IO_ATTR       0xe0
+#define KIRKWOOD_MBUS_PCIE1_MEM_TARGET    0x4
+#define KIRKWOOD_MBUS_PCIE1_MEM_ATTR      0xd8
+#define KIRKWOOD_MBUS_PCIE1_IO_TARGET     0x4
+#define KIRKWOOD_MBUS_PCIE1_IO_ATTR       0xd0
+
 static void kirkwood_enable_pcie_clk(const char *port)
 {
 	struct clk *clk;
@@ -254,26 +264,24 @@ static void __init add_pcie_port(int index, void __iomem *base)
 
 void __init kirkwood_pcie_init(unsigned int portmask)
 {
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
+	mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE0_IO_TARGET,
+					  KIRKWOOD_MBUS_PCIE0_IO_ATTR,
 					  KIRKWOOD_PCIE_IO_PHYS_BASE,
 					  KIRKWOOD_PCIE_IO_SIZE,
-					  KIRKWOOD_PCIE_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
-					  KIRKWOOD_PCIE_MEM_PHYS_BASE,
-					  KIRKWOOD_PCIE_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
+					  KIRKWOOD_PCIE_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_PCIE0_MEM_TARGET,
+				    KIRKWOOD_MBUS_PCIE0_MEM_ATTR,
+				    KIRKWOOD_PCIE_MEM_PHYS_BASE,
+				    KIRKWOOD_PCIE_MEM_SIZE);
+	mvebu_mbus_add_window_remap_by_id(KIRKWOOD_MBUS_PCIE1_IO_TARGET,
+					  KIRKWOOD_MBUS_PCIE1_IO_ATTR,
 					  KIRKWOOD_PCIE1_IO_PHYS_BASE,
 					  KIRKWOOD_PCIE1_IO_SIZE,
-					  KIRKWOOD_PCIE1_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
-					  KIRKWOOD_PCIE1_MEM_PHYS_BASE,
-					  KIRKWOOD_PCIE1_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+					  KIRKWOOD_PCIE1_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(KIRKWOOD_MBUS_PCIE1_MEM_TARGET,
+				    KIRKWOOD_MBUS_PCIE1_MEM_ATTR,
+				    KIRKWOOD_PCIE1_MEM_PHYS_BASE,
+				    KIRKWOOD_PCIE1_MEM_SIZE);
 
 	vga_base = KIRKWOOD_PCIE_MEM_PHYS_BASE;
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:41 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:41 -0300
Subject: [PATCH v9 04/30] ARM: mv78xx0: Move to ID based window creation
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-5-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/mach-mv78xx0/pcie.c | 23 +++++++++++------------
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-mv78xx0/pcie.c b/arch/arm/mach-mv78xx0/pcie.c
index dc26a65..445e553 100644
--- a/arch/arm/mach-mv78xx0/pcie.c
+++ b/arch/arm/mach-mv78xx0/pcie.c
@@ -18,6 +18,11 @@
 #include <mach/mv78xx0.h>
 #include "common.h"
 
+#define MV78XX0_MBUS_PCIE_MEM_TARGET(port, lane) ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_MEM_ATTR(port, lane)   (0xf8 & ~(0x10 << (lane)))
+#define MV78XX0_MBUS_PCIE_IO_TARGET(port, lane)  ((port) ? 8 : 4)
+#define MV78XX0_MBUS_PCIE_IO_ATTR(port, lane)    (0xf0 & ~(0x10 << (lane)))
+
 struct pcie_port {
 	u8			maj;
 	u8			min;
@@ -71,7 +76,6 @@ static void __init mv78xx0_pcie_preinit(void)
 	start = MV78XX0_PCIE_MEM_PHYS_BASE;
 	for (i = 0; i < num_pcie_ports; i++) {
 		struct pcie_port *pp = pcie_port + i;
-		char winname[MVEBU_MBUS_MAX_WINNAME_SZ];
 
 		snprintf(pp->mem_space_name, sizeof(pp->mem_space_name),
 			"PCIe %d.%d MEM", pp->maj, pp->min);
@@ -85,17 +89,12 @@ static void __init mv78xx0_pcie_preinit(void)
 		if (request_resource(&iomem_resource, &pp->res))
 			panic("can't allocate PCIe MEM sub-space");
 
-		snprintf(winname, sizeof(winname), "pcie%d.%d",
-			 pp->maj, pp->min);
-
-		mvebu_mbus_add_window_remap_flags(winname,
-						  pp->res.start,
-						  resource_size(&pp->res),
-						  MVEBU_MBUS_NO_REMAP,
-						  MVEBU_MBUS_PCI_MEM);
-		mvebu_mbus_add_window_remap_flags(winname,
-						  i * SZ_64K, SZ_64K,
-						  0, MVEBU_MBUS_PCI_IO);
+		mvebu_mbus_add_window_by_id(MV78XX0_MBUS_PCIE_MEM_TARGET(pp->maj, pp->min),
+					    MV78XX0_MBUS_PCIE_MEM_ATTR(pp->maj, pp->min),
+					    pp->res.start, resource_size(&pp->res));
+		mvebu_mbus_add_window_remap_by_id(MV78XX0_MBUS_PCIE_IO_TARGET(pp->maj, pp->min),
+						  MV78XX0_MBUS_PCIE_IO_ATTR(pp->maj, pp->min),
+						  i * SZ_64K, SZ_64K, 0);
 	}
 }
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:42 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:42 -0300
Subject: [PATCH v9 05/30] ARM: orion5x: Move to ID based window creation
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-6-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/mach-orion5x/common.c                 | 36 ++++++++++++++------------
 arch/arm/mach-orion5x/common.h                 | 17 ++++++++++++
 arch/arm/mach-orion5x/d2net-setup.c            |  6 +++--
 arch/arm/mach-orion5x/db88f5281-setup.c        | 24 +++++++++++------
 arch/arm/mach-orion5x/dns323-setup.c           |  6 +++--
 arch/arm/mach-orion5x/edmini_v2-setup.c        |  6 +++--
 arch/arm/mach-orion5x/kurobox_pro-setup.c      | 12 ++++++---
 arch/arm/mach-orion5x/ls-chl-setup.c           |  6 +++--
 arch/arm/mach-orion5x/ls_hgl-setup.c           |  6 +++--
 arch/arm/mach-orion5x/lsmini-setup.c           |  6 +++--
 arch/arm/mach-orion5x/mss2-setup.c             |  6 +++--
 arch/arm/mach-orion5x/mv2120-setup.c           |  6 +++--
 arch/arm/mach-orion5x/net2big-setup.c          |  6 +++--
 arch/arm/mach-orion5x/pci.c                    |  9 +++----
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c   |  6 +++--
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c    |  6 +++--
 arch/arm/mach-orion5x/rd88f5182-setup.c        | 13 ++++++----
 arch/arm/mach-orion5x/terastation_pro2-setup.c |  6 +++--
 arch/arm/mach-orion5x/ts209-setup.c            |  6 +++--
 arch/arm/mach-orion5x/ts409-setup.c            |  6 +++--
 arch/arm/mach-orion5x/wnr854t-setup.c          |  6 +++--
 arch/arm/mach-orion5x/wrt350n-v2-setup.c       |  6 +++--
 22 files changed, 137 insertions(+), 70 deletions(-)

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index b41599f..91a5852 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -174,8 +174,10 @@ void __init orion5x_xor_init(void)
  ****************************************************************************/
 static void __init orion5x_crypto_init(void)
 {
-	mvebu_mbus_add_window("sram", ORION5X_SRAM_PHYS_BASE,
-			      ORION5X_SRAM_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_SRAM_TARGET,
+				    ORION_MBUS_SRAM_ATTR,
+				    ORION5X_SRAM_PHYS_BASE,
+				    ORION5X_SRAM_SIZE);
 	orion_crypto_init(ORION5X_CRYPTO_PHYS_BASE, ORION5X_SRAM_PHYS_BASE,
 			  SZ_8K, IRQ_ORION5X_CESA);
 }
@@ -222,22 +224,24 @@ void orion5x_setup_wins(void)
 	 * The PCIe windows will no longer be statically allocated
 	 * here once Orion5x is migrated to the pci-mvebu driver.
 	 */
-	mvebu_mbus_add_window_remap_flags("pcie0.0", ORION5X_PCIE_IO_PHYS_BASE,
+	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
+					  ORION_MBUS_PCIE_IO_ATTR,
+					  ORION5X_PCIE_IO_PHYS_BASE,
 					  ORION5X_PCIE_IO_SIZE,
-					  ORION5X_PCIE_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0", ORION5X_PCIE_MEM_PHYS_BASE,
-					  ORION5X_PCIE_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pci0.0", ORION5X_PCI_IO_PHYS_BASE,
+					  ORION5X_PCIE_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
+				    ORION_MBUS_PCIE_MEM_ATTR,
+				    ORION5X_PCIE_MEM_PHYS_BASE,
+				    ORION5X_PCIE_MEM_SIZE);
+	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
+					  ORION_MBUS_PCI_IO_ATTR,
+					  ORION5X_PCI_IO_PHYS_BASE,
 					  ORION5X_PCI_IO_SIZE,
-					  ORION5X_PCI_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pci0.0", ORION5X_PCI_MEM_PHYS_BASE,
-					  ORION5X_PCI_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+					  ORION5X_PCI_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
+				    ORION_MBUS_PCI_MEM_ATTR,
+				    ORION5X_PCI_MEM_PHYS_BASE,
+				    ORION5X_PCI_MEM_SIZE);
 }
 
 int orion5x_tclk;
diff --git a/arch/arm/mach-orion5x/common.h b/arch/arm/mach-orion5x/common.h
index a909afb..f565f99 100644
--- a/arch/arm/mach-orion5x/common.h
+++ b/arch/arm/mach-orion5x/common.h
@@ -7,6 +7,23 @@ struct dsa_platform_data;
 struct mv643xx_eth_platform_data;
 struct mv_sata_platform_data;
 
+#define ORION_MBUS_PCIE_MEM_TARGET    0x04
+#define ORION_MBUS_PCIE_MEM_ATTR      0x59
+#define ORION_MBUS_PCIE_IO_TARGET     0x04
+#define ORION_MBUS_PCIE_IO_ATTR       0x51
+#define ORION_MBUS_PCIE_WA_TARGET     0x04
+#define ORION_MBUS_PCIE_WA_ATTR       0x79
+#define ORION_MBUS_PCI_MEM_TARGET     0x03
+#define ORION_MBUS_PCI_MEM_ATTR       0x59
+#define ORION_MBUS_PCI_IO_TARGET      0x03
+#define ORION_MBUS_PCI_IO_ATTR        0x51
+#define ORION_MBUS_DEVBUS_BOOT_TARGET 0x01
+#define ORION_MBUS_DEVBUS_BOOT_ATTR   0x0f
+#define ORION_MBUS_DEVBUS_TARGET(cs)  0x01
+#define ORION_MBUS_DEVBUS_ATTR(cs)    (~(1 << cs))
+#define ORION_MBUS_SRAM_TARGET        0x00
+#define ORION_MBUS_SRAM_ATTR          0x00
+
 /*
  * Basic Orion init functions used early by machine-setup.
  */
diff --git a/arch/arm/mach-orion5x/d2net-setup.c b/arch/arm/mach-orion5x/d2net-setup.c
index 16c88bb..8f68b74 100644
--- a/arch/arm/mach-orion5x/d2net-setup.c
+++ b/arch/arm/mach-orion5x/d2net-setup.c
@@ -317,8 +317,10 @@ static void __init d2net_init(void)
 	d2net_sata_power_init();
 	orion5x_sata_init(&d2net_sata_data);
 
-	mvebu_mbus_add_window("devbus-boot", D2NET_NOR_BOOT_BASE,
-			      D2NET_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    D2NET_NOR_BOOT_BASE,
+				    D2NET_NOR_BOOT_SIZE);
 	platform_device_register(&d2net_nor_flash);
 
 	platform_device_register(&d2net_gpio_buttons);
diff --git a/arch/arm/mach-orion5x/db88f5281-setup.c b/arch/arm/mach-orion5x/db88f5281-setup.c
index 4e1263d..4b2aefd 100644
--- a/arch/arm/mach-orion5x/db88f5281-setup.c
+++ b/arch/arm/mach-orion5x/db88f5281-setup.c
@@ -340,19 +340,27 @@ static void __init db88f5281_init(void)
 	orion5x_uart0_init();
 	orion5x_uart1_init();
 
-	mvebu_mbus_add_window("devbus-boot", DB88F5281_NOR_BOOT_BASE,
-			      DB88F5281_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    DB88F5281_NOR_BOOT_BASE,
+				    DB88F5281_NOR_BOOT_SIZE);
 	platform_device_register(&db88f5281_boot_flash);
 
-	mvebu_mbus_add_window("devbus-cs0", DB88F5281_7SEG_BASE,
-			      DB88F5281_7SEG_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(0),
+				    ORION_MBUS_DEVBUS_ATTR(0),
+				    DB88F5281_7SEG_BASE,
+				    DB88F5281_7SEG_SIZE);
 
-	mvebu_mbus_add_window("devbus-cs1", DB88F5281_NOR_BASE,
-			      DB88F5281_NOR_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(1),
+				    ORION_MBUS_DEVBUS_ATTR(1),
+				    DB88F5281_NOR_BASE,
+				    DB88F5281_NOR_SIZE);
 	platform_device_register(&db88f5281_nor_flash);
 
-	mvebu_mbus_add_window("devbus-cs2", DB88F5281_NAND_BASE,
-			      DB88F5281_NAND_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(2),
+				    ORION_MBUS_DEVBUS_ATTR(2),
+				    DB88F5281_NAND_BASE,
+				    DB88F5281_NAND_SIZE);
 	platform_device_register(&db88f5281_nand_flash);
 
 	i2c_register_board_info(0, &db88f5281_i2c_rtc, 1);
diff --git a/arch/arm/mach-orion5x/dns323-setup.c b/arch/arm/mach-orion5x/dns323-setup.c
index 9e6baf5..7097473 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -611,8 +611,10 @@ static void __init dns323_init(void)
 	/* setup flash mapping
 	 * CS3 holds a 8 MB Spansion S29GL064M90TFIR4
 	 */
-	mvebu_mbus_add_window("devbus-boot", DNS323_NOR_BOOT_BASE,
-			      DNS323_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    DNS323_NOR_BOOT_BASE,
+				    DNS323_NOR_BOOT_SIZE);
 	platform_device_register(&dns323_nor_flash);
 
 	/* Sort out LEDs, Buttons and i2c devices */
diff --git a/arch/arm/mach-orion5x/edmini_v2-setup.c b/arch/arm/mach-orion5x/edmini_v2-setup.c
index 1476155..0fc33c5 100644
--- a/arch/arm/mach-orion5x/edmini_v2-setup.c
+++ b/arch/arm/mach-orion5x/edmini_v2-setup.c
@@ -154,8 +154,10 @@ void __init edmini_v2_init(void)
 	orion5x_ehci0_init();
 	orion5x_eth_init(&edmini_v2_eth_data);
 
-	mvebu_mbus_add_window("devbus-boot", EDMINI_V2_NOR_BOOT_BASE,
-			      EDMINI_V2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    EDMINI_V2_NOR_BOOT_BASE,
+				    EDMINI_V2_NOR_BOOT_SIZE);
 	platform_device_register(&edmini_v2_nor_flash);
 
 	pr_notice("edmini_v2: USB device port, flash write and power-off "
diff --git a/arch/arm/mach-orion5x/kurobox_pro-setup.c b/arch/arm/mach-orion5x/kurobox_pro-setup.c
index aae10e4..fe6a48a 100644
--- a/arch/arm/mach-orion5x/kurobox_pro-setup.c
+++ b/arch/arm/mach-orion5x/kurobox_pro-setup.c
@@ -359,13 +359,17 @@ static void __init kurobox_pro_init(void)
 	orion5x_uart1_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", KUROBOX_PRO_NOR_BOOT_BASE,
-			      KUROBOX_PRO_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    KUROBOX_PRO_NOR_BOOT_BASE,
+				    KUROBOX_PRO_NOR_BOOT_SIZE);
 	platform_device_register(&kurobox_pro_nor_flash);
 
 	if (machine_is_kurobox_pro()) {
-		mvebu_mbus_add_window("devbus-cs0", KUROBOX_PRO_NAND_BASE,
-				      KUROBOX_PRO_NAND_SIZE);
+		mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(0),
+					    ORION_MBUS_DEVBUS_ATTR(0),
+					    KUROBOX_PRO_NAND_BASE,
+					    KUROBOX_PRO_NAND_SIZE);
 		platform_device_register(&kurobox_pro_nand_flash);
 	}
 
diff --git a/arch/arm/mach-orion5x/ls-chl-setup.c b/arch/arm/mach-orion5x/ls-chl-setup.c
index 6234977..028ea03 100644
--- a/arch/arm/mach-orion5x/ls-chl-setup.c
+++ b/arch/arm/mach-orion5x/ls-chl-setup.c
@@ -294,8 +294,10 @@ static void __init lschl_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LSCHL_NOR_BOOT_BASE,
-			      LSCHL_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LSCHL_NOR_BOOT_BASE,
+				    LSCHL_NOR_BOOT_SIZE);
 	platform_device_register(&lschl_nor_flash);
 
 	platform_device_register(&lschl_leds);
diff --git a/arch/arm/mach-orion5x/ls_hgl-setup.c b/arch/arm/mach-orion5x/ls_hgl-setup.c
index fe04c4b..32b7129 100644
--- a/arch/arm/mach-orion5x/ls_hgl-setup.c
+++ b/arch/arm/mach-orion5x/ls_hgl-setup.c
@@ -243,8 +243,10 @@ static void __init ls_hgl_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LS_HGL_NOR_BOOT_BASE,
-			      LS_HGL_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LS_HGL_NOR_BOOT_BASE,
+				    LS_HGL_NOR_BOOT_SIZE);
 	platform_device_register(&ls_hgl_nor_flash);
 
 	platform_device_register(&ls_hgl_button_device);
diff --git a/arch/arm/mach-orion5x/lsmini-setup.c b/arch/arm/mach-orion5x/lsmini-setup.c
index ca4dbe9..a6493e7 100644
--- a/arch/arm/mach-orion5x/lsmini-setup.c
+++ b/arch/arm/mach-orion5x/lsmini-setup.c
@@ -244,8 +244,10 @@ static void __init lsmini_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", LSMINI_NOR_BOOT_BASE,
-			      LSMINI_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    LSMINI_NOR_BOOT_BASE,
+				    LSMINI_NOR_BOOT_SIZE);
 	platform_device_register(&lsmini_nor_flash);
 
 	platform_device_register(&lsmini_button_device);
diff --git a/arch/arm/mach-orion5x/mss2-setup.c b/arch/arm/mach-orion5x/mss2-setup.c
index 827acba..e105130 100644
--- a/arch/arm/mach-orion5x/mss2-setup.c
+++ b/arch/arm/mach-orion5x/mss2-setup.c
@@ -241,8 +241,10 @@ static void __init mss2_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", MSS2_NOR_BOOT_BASE,
-			      MSS2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    MSS2_NOR_BOOT_BASE,
+				    MSS2_NOR_BOOT_SIZE);
 	platform_device_register(&mss2_nor_flash);
 
 	platform_device_register(&mss2_button_device);
diff --git a/arch/arm/mach-orion5x/mv2120-setup.c b/arch/arm/mach-orion5x/mv2120-setup.c
index 92600ae..e032f01 100644
--- a/arch/arm/mach-orion5x/mv2120-setup.c
+++ b/arch/arm/mach-orion5x/mv2120-setup.c
@@ -204,8 +204,10 @@ static void __init mv2120_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", MV2120_NOR_BOOT_BASE,
-			      MV2120_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    MV2120_NOR_BOOT_BASE,
+				    MV2120_NOR_BOOT_SIZE);
 	platform_device_register(&mv2120_nor_flash);
 
 	platform_device_register(&mv2120_button_device);
diff --git a/arch/arm/mach-orion5x/net2big-setup.c b/arch/arm/mach-orion5x/net2big-setup.c
index dd0641a..ba73dc7 100644
--- a/arch/arm/mach-orion5x/net2big-setup.c
+++ b/arch/arm/mach-orion5x/net2big-setup.c
@@ -397,8 +397,10 @@ static void __init net2big_init(void)
 	net2big_sata_power_init();
 	orion5x_sata_init(&net2big_sata_data);
 
-	mvebu_mbus_add_window("devbus-boot", NET2BIG_NOR_BOOT_BASE,
-			      NET2BIG_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    NET2BIG_NOR_BOOT_BASE,
+				    NET2BIG_NOR_BOOT_SIZE);
 	platform_device_register(&net2big_nor_flash);
 
 	platform_device_register(&net2big_gpio_buttons);
diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion5x/pci.c
index 5033680..7fab670 100644
--- a/arch/arm/mach-orion5x/pci.c
+++ b/arch/arm/mach-orion5x/pci.c
@@ -157,11 +157,10 @@ static int __init pcie_setup(struct pci_sys_data *sys)
 	if (dev == MV88F5181_DEV_ID || dev == MV88F5182_DEV_ID) {
 		printk(KERN_NOTICE "Applying Orion-1/Orion-NAS PCIe config "
 				   "read transaction workaround\n");
-		mvebu_mbus_add_window_remap_flags("pcie0.0",
-						  ORION5X_PCIE_WA_PHYS_BASE,
-						  ORION5X_PCIE_WA_SIZE,
-						  MVEBU_MBUS_NO_REMAP,
-						  MVEBU_MBUS_PCI_WA);
+		mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_WA_TARGET,
+					    ORION_MBUS_PCIE_WA_ATTR,
+					    ORION5X_PCIE_WA_PHYS_BASE,
+					    ORION5X_PCIE_WA_SIZE);
 		pcie_ops.read = pcie_rd_conf_wa;
 	}
 
diff --git a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
index 1c4498b..213b3e1 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
@@ -123,8 +123,10 @@ static void __init rd88f5181l_fxo_init(void)
 	orion5x_eth_switch_init(&rd88f5181l_fxo_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5181L_FXO_NOR_BOOT_BASE,
-			      RD88F5181L_FXO_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5181L_FXO_NOR_BOOT_BASE,
+				    RD88F5181L_FXO_NOR_BOOT_SIZE);
 	platform_device_register(&rd88f5181l_fxo_nor_boot_flash);
 }
 
diff --git a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
index adabe34..594800e 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
@@ -130,8 +130,10 @@ static void __init rd88f5181l_ge_init(void)
 	orion5x_i2c_init();
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5181L_GE_NOR_BOOT_BASE,
-			      RD88F5181L_GE_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5181L_GE_NOR_BOOT_BASE,
+				    RD88F5181L_GE_NOR_BOOT_SIZE);
 	platform_device_register(&rd88f5181l_ge_nor_boot_flash);
 
 	i2c_register_board_info(0, &rd88f5181l_ge_i2c_rtc, 1);
diff --git a/arch/arm/mach-orion5x/rd88f5182-setup.c b/arch/arm/mach-orion5x/rd88f5182-setup.c
index 66e77ec..b1cf684 100644
--- a/arch/arm/mach-orion5x/rd88f5182-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5182-setup.c
@@ -264,11 +264,14 @@ static void __init rd88f5182_init(void)
 	orion5x_uart0_init();
 	orion5x_xor_init();
 
-	mvebu_mbus_add_window("devbus-boot", RD88F5182_NOR_BOOT_BASE,
-			      RD88F5182_NOR_BOOT_SIZE);
-
-	mvebu_mbus_add_window("devbus-cs1", RD88F5182_NOR_BASE,
-			      RD88F5182_NOR_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    RD88F5182_NOR_BOOT_BASE,
+				    RD88F5182_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_TARGET(1),
+				    ORION_MBUS_DEVBUS_ATTR(1),
+				    RD88F5182_NOR_BASE,
+				    RD88F5182_NOR_SIZE);
 	platform_device_register(&rd88f5182_nor_flash);
 	platform_device_register(&rd88f5182_gpio_leds);
 
diff --git a/arch/arm/mach-orion5x/terastation_pro2-setup.c b/arch/arm/mach-orion5x/terastation_pro2-setup.c
index a0bfa53..7e90648 100644
--- a/arch/arm/mach-orion5x/terastation_pro2-setup.c
+++ b/arch/arm/mach-orion5x/terastation_pro2-setup.c
@@ -329,8 +329,10 @@ static void __init tsp2_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", TSP2_NOR_BOOT_BASE,
-			      TSP2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    TSP2_NOR_BOOT_BASE,
+				    TSP2_NOR_BOOT_SIZE);
 	platform_device_register(&tsp2_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/ts209-setup.c b/arch/arm/mach-orion5x/ts209-setup.c
index 80174f0..e90c061 100644
--- a/arch/arm/mach-orion5x/ts209-setup.c
+++ b/arch/arm/mach-orion5x/ts209-setup.c
@@ -286,8 +286,10 @@ static void __init qnap_ts209_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", QNAP_TS209_NOR_BOOT_BASE,
-			      QNAP_TS209_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    QNAP_TS209_NOR_BOOT_BASE,
+				    QNAP_TS209_NOR_BOOT_SIZE);
 	platform_device_register(&qnap_ts209_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/ts409-setup.c b/arch/arm/mach-orion5x/ts409-setup.c
index 9259279..5c079d3 100644
--- a/arch/arm/mach-orion5x/ts409-setup.c
+++ b/arch/arm/mach-orion5x/ts409-setup.c
@@ -277,8 +277,10 @@ static void __init qnap_ts409_init(void)
 	/*
 	 * Configure peripherals.
 	 */
-	mvebu_mbus_add_window("devbus-boot", QNAP_TS409_NOR_BOOT_BASE,
-			      QNAP_TS409_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    QNAP_TS409_NOR_BOOT_BASE,
+				    QNAP_TS409_NOR_BOOT_SIZE);
 	platform_device_register(&qnap_ts409_nor_flash);
 
 	orion5x_ehci0_init();
diff --git a/arch/arm/mach-orion5x/wnr854t-setup.c b/arch/arm/mach-orion5x/wnr854t-setup.c
index 6b84863..80a56ee 100644
--- a/arch/arm/mach-orion5x/wnr854t-setup.c
+++ b/arch/arm/mach-orion5x/wnr854t-setup.c
@@ -127,8 +127,10 @@ static void __init wnr854t_init(void)
 	orion5x_eth_switch_init(&wnr854t_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", WNR854T_NOR_BOOT_BASE,
-			      WNR854T_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    WNR854T_NOR_BOOT_BASE,
+				    WNR854T_NOR_BOOT_SIZE);
 	platform_device_register(&wnr854t_nor_flash);
 }
 
diff --git a/arch/arm/mach-orion5x/wrt350n-v2-setup.c b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
index fae684b..670e30d 100644
--- a/arch/arm/mach-orion5x/wrt350n-v2-setup.c
+++ b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
@@ -213,8 +213,10 @@ static void __init wrt350n_v2_init(void)
 	orion5x_eth_switch_init(&wrt350n_v2_switch_plat_data, NO_IRQ);
 	orion5x_uart0_init();
 
-	mvebu_mbus_add_window("devbus-boot", WRT350N_V2_NOR_BOOT_BASE,
-			      WRT350N_V2_NOR_BOOT_SIZE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
+				    ORION_MBUS_DEVBUS_BOOT_ATTR,
+				    WRT350N_V2_NOR_BOOT_BASE,
+				    WRT350N_V2_NOR_BOOT_SIZE);
 	platform_device_register(&wrt350n_v2_nor_flash);
 	platform_device_register(&wrt350n_v2_leds);
 	platform_device_register(&wrt350n_v2_button_device);
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:43 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:43 -0300
Subject: [PATCH v9 06/30] ARM: dove: Move to ID based window creation
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-7-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

With the introduction of the ID based MBus API, it's better
to switch to use it instead of the current name based scheme.

This will allow to deprecate the name based API, once every
user is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/mach-dove/common.c | 68 ++++++++++++++++++++++++++++++---------------
 1 file changed, 45 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 00247c7..bc22056 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -27,6 +27,22 @@
 #include <plat/time.h>
 #include "common.h"
 
+/* These can go away once Dove uses the mvebu-mbus DT binding */
+#define DOVE_MBUS_PCIE0_MEM_TARGET    0x4
+#define DOVE_MBUS_PCIE0_MEM_ATTR      0xe8
+#define DOVE_MBUS_PCIE0_IO_TARGET     0x4
+#define DOVE_MBUS_PCIE0_IO_ATTR       0xe0
+#define DOVE_MBUS_PCIE1_MEM_TARGET    0x8
+#define DOVE_MBUS_PCIE1_MEM_ATTR      0xe8
+#define DOVE_MBUS_PCIE1_IO_TARGET     0x8
+#define DOVE_MBUS_PCIE1_IO_ATTR       0xe0
+#define DOVE_MBUS_CESA_TARGET         0x3
+#define DOVE_MBUS_CESA_ATTR           0x1
+#define DOVE_MBUS_BOOTROM_TARGET      0x1
+#define DOVE_MBUS_BOOTROM_ATTR        0xfd
+#define DOVE_MBUS_SCRATCHPAD_TARGET   0xd
+#define DOVE_MBUS_SCRATCHPAD_ATTR     0x0
+
 /*****************************************************************************
  * I/O Address Mapping
  ****************************************************************************/
@@ -332,34 +348,40 @@ void __init dove_setup_cpu_wins(void)
 {
 	/*
 	 * The PCIe windows will no longer be statically allocated
-	 * here once Dove is migrated to the pci-mvebu driver.
+	 * here once Dove is migrated to the pci-mvebu driver. The
+	 * non-PCIe windows will no longer be created here once Dove
+	 * fully moves to DT.
 	 */
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
+	mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE0_IO_TARGET,
+					  DOVE_MBUS_PCIE0_IO_ATTR,
 					  DOVE_PCIE0_IO_PHYS_BASE,
 					  DOVE_PCIE0_IO_SIZE,
-					  DOVE_PCIE0_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
+					  DOVE_PCIE0_IO_BUS_BASE);
+	mvebu_mbus_add_window_remap_by_id(DOVE_MBUS_PCIE1_IO_TARGET,
+					  DOVE_MBUS_PCIE1_IO_ATTR,
 					  DOVE_PCIE1_IO_PHYS_BASE,
 					  DOVE_PCIE1_IO_SIZE,
-					  DOVE_PCIE1_IO_BUS_BASE,
-					  MVEBU_MBUS_PCI_IO);
-	mvebu_mbus_add_window_remap_flags("pcie0.0",
-					  DOVE_PCIE0_MEM_PHYS_BASE,
-					  DOVE_PCIE0_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window_remap_flags("pcie1.0",
-					  DOVE_PCIE1_MEM_PHYS_BASE,
-					  DOVE_PCIE1_MEM_SIZE,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
-	mvebu_mbus_add_window("cesa", DOVE_CESA_PHYS_BASE,
-			      DOVE_CESA_SIZE);
-	mvebu_mbus_add_window("bootrom", DOVE_BOOTROM_PHYS_BASE,
-			      DOVE_BOOTROM_SIZE);
-	mvebu_mbus_add_window("scratchpad", DOVE_SCRATCHPAD_PHYS_BASE,
-			      DOVE_SCRATCHPAD_SIZE);
+					  DOVE_PCIE1_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE0_MEM_TARGET,
+				    DOVE_MBUS_PCIE0_MEM_ATTR,
+				    DOVE_PCIE0_MEM_PHYS_BASE,
+				    DOVE_PCIE0_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_PCIE1_MEM_TARGET,
+				    DOVE_MBUS_PCIE1_MEM_ATTR,
+				    DOVE_PCIE1_MEM_PHYS_BASE,
+				    DOVE_PCIE1_MEM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_CESA_TARGET,
+				    DOVE_MBUS_CESA_ATTR,
+				    DOVE_CESA_PHYS_BASE,
+				    DOVE_CESA_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_BOOTROM_TARGET,
+				    DOVE_MBUS_BOOTROM_ATTR,
+				    DOVE_BOOTROM_PHYS_BASE,
+				    DOVE_BOOTROM_SIZE);
+	mvebu_mbus_add_window_by_id(DOVE_MBUS_SCRATCHPAD_TARGET,
+				    DOVE_MBUS_SCRATCHPAD_ATTR,
+				    DOVE_SCRATCHPAD_PHYS_BASE,
+				    DOVE_SCRATCHPAD_SIZE);
 }
 
 void __init dove_init(void)
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:47 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:47 -0300
Subject: [PATCH v9 10/30] bus: mvebu-mbus: Add new API for the PCIe memory and
 IO aperture
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-11-git-send-email-ezequiel.garcia@free-electrons.com>

We add two optional properties to the MBus DT binding, to encode
the PCIe memory and IO aperture. This allows such information to
be retrieved by -for instance- the pci driver to allocate the
MBus decoding windows.

Correspondingly, and in order to retrieve this information,
we add two new APIs.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 drivers/bus/mvebu-mbus.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mbus.h     |  4 ++++
 2 files changed, 53 insertions(+)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 78b8c04..929fed1 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -142,6 +142,8 @@ struct mvebu_mbus_state {
 	struct dentry *debugfs_root;
 	struct dentry *debugfs_sdram;
 	struct dentry *debugfs_devs;
+	struct resource pcie_mem_aperture;
+	struct resource pcie_io_aperture;
 	const struct mvebu_mbus_soc_data *soc;
 	int hw_io_coherency;
 };
@@ -821,6 +823,20 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size)
 	return 0;
 }
 
+void mvebu_mbus_get_pcie_mem_aperture(struct resource *res)
+{
+	if (!res)
+		return;
+	*res = mbus_state.pcie_mem_aperture;
+}
+
+void mvebu_mbus_get_pcie_io_aperture(struct resource *res)
+{
+	if (!res)
+		return;
+	*res = mbus_state.pcie_io_aperture;
+}
+
 static __init int mvebu_mbus_debugfs_init(void)
 {
 	struct mvebu_mbus_state *s = &mbus_state;
@@ -1023,6 +1039,35 @@ static int __init mbus_dt_setup(struct mvebu_mbus_state *mbus,
 	return 0;
 }
 
+static void __init mvebu_mbus_get_pcie_resources(struct device_node *np,
+						 struct resource *mem,
+						 struct resource *io)
+{
+	u32 reg[2];
+	int ret;
+
+	/*
+	 * These are optional, so we clear them and they'll
+	 * be zero if they are missing from the DT.
+	 */
+	memset(mem, 0, sizeof(struct resource));
+	memset(io, 0, sizeof(struct resource));
+
+	ret = of_property_read_u32_array(np, "pcie-mem-aperture", reg, ARRAY_SIZE(reg));
+	if (!ret) {
+		mem->start = reg[0];
+		mem->end = mem->start + reg[1];
+		mem->flags = IORESOURCE_MEM;
+	}
+
+	ret = of_property_read_u32_array(np, "pcie-io-aperture", reg, ARRAY_SIZE(reg));
+	if (!ret) {
+		io->start = reg[0];
+		io->end = io->start + reg[1];
+		io->flags = IORESOURCE_IO;
+	}
+}
+
 int __init mvebu_mbus_dt_init(void)
 {
 	struct resource mbuswins_res, sdramwins_res;
@@ -1062,6 +1107,10 @@ int __init mvebu_mbus_dt_init(void)
 		return -EINVAL;
 	}
 
+	/* Get optional pcie-{mem,io}-aperture properties */
+	mvebu_mbus_get_pcie_resources(np, &mbus_state.pcie_mem_aperture,
+					  &mbus_state.pcie_io_aperture);
+
 	ret = mvebu_mbus_common_init(&mbus_state,
 				     mbuswins_res.start,
 				     resource_size(&mbuswins_res),
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index eadefd6..650bc15 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -11,6 +11,8 @@
 #ifndef __LINUX_MBUS_H
 #define __LINUX_MBUS_H
 
+struct resource;
+
 struct mbus_dram_target_info
 {
 	/*
@@ -59,6 +61,8 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
 }
 #endif
 
+void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
+void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
 int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
 				      size_t size, phys_addr_t remap,
 				      unsigned int flags);
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:44 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:44 -0300
Subject: [PATCH v9 07/30] bus: mvebu-mbus: Factor out initialization details
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-8-git-send-email-ezequiel.garcia@free-electrons.com>

We introduce a common initialization function mvebu_mbus_common_init()
that will be used by both legacy and device-tree initialization code.
This patch is an intermediate step, which will allow to introduce the
DT binding for this driver in a less intrusive way.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 drivers/bus/mvebu-mbus.c | 47 ++++++++++++++++++++++++++++++-----------------
 1 file changed, 30 insertions(+), 17 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 827468a..1b17954 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -847,26 +847,14 @@ static __init int mvebu_mbus_debugfs_init(void)
 }
 fs_initcall(mvebu_mbus_debugfs_init);
 
-int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
-			   size_t mbuswins_size,
-			   phys_addr_t sdramwins_phys_base,
-			   size_t sdramwins_size)
+static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
+					 phys_addr_t mbuswins_phys_base,
+					 size_t mbuswins_size,
+					 phys_addr_t sdramwins_phys_base,
+					 size_t sdramwins_size)
 {
-	struct mvebu_mbus_state *mbus = &mbus_state;
-	const struct of_device_id *of_id;
 	int win;
 
-	for (of_id = of_mvebu_mbus_ids; of_id->compatible; of_id++)
-		if (!strcmp(of_id->compatible, soc))
-			break;
-
-	if (!of_id->compatible) {
-		pr_err("could not find a matching SoC family\n");
-		return -ENODEV;
-	}
-
-	mbus->soc = of_id->data;
-
 	mbus->mbuswins_base = ioremap(mbuswins_phys_base, mbuswins_size);
 	if (!mbus->mbuswins_base)
 		return -ENOMEM;
@@ -887,3 +875,28 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 
 	return 0;
 }
+
+int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
+			   size_t mbuswins_size,
+			   phys_addr_t sdramwins_phys_base,
+			   size_t sdramwins_size)
+{
+	const struct of_device_id *of_id;
+
+	for (of_id = of_mvebu_mbus_ids; of_id->compatible; of_id++)
+		if (!strcmp(of_id->compatible, soc))
+			break;
+
+	if (!of_id->compatible) {
+		pr_err("could not find a matching SoC family\n");
+		return -ENODEV;
+	}
+
+	mbus_state.soc = of_id->data;
+
+	return mvebu_mbus_common_init(&mbus_state,
+			mbuswins_phys_base,
+			mbuswins_size,
+			sdramwins_phys_base,
+			sdramwins_size);
+}
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:45 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:45 -0300
Subject: [PATCH v9 08/30] bus: mvebu-mbus: Introduce device tree binding
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-9-git-send-email-ezequiel.garcia@free-electrons.com>

This patch adds the most fundamental device-tree initialization.
We only introduce what's required to be able to probe the mvebu-mbus
driver from the DT. Follow-up patches will extend the device tree binding,
allowing to describe static address decoding windows.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 drivers/bus/mvebu-mbus.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mbus.h     |  1 +
 2 files changed, 50 insertions(+)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 1b17954..44a07c4 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -900,3 +900,52 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 			sdramwins_phys_base,
 			sdramwins_size);
 }
+
+#ifdef CONFIG_OF
+int __init mvebu_mbus_dt_init(void)
+{
+	struct resource mbuswins_res, sdramwins_res;
+	struct device_node *np, *controller;
+	const struct of_device_id *of_id;
+	const __be32 *prop;
+	int ret;
+
+	np = of_find_matching_node(NULL, of_mvebu_mbus_ids);
+	if (!np) {
+		pr_err("could not find a matching SoC family\n");
+		return -ENODEV;
+	}
+
+	of_id = of_match_node(of_mvebu_mbus_ids, np);
+	mbus_state.soc = of_id->data;
+
+	prop = of_get_property(np, "controller", NULL);
+	if (!prop) {
+		pr_err("required 'controller' property missing\n");
+		return -EINVAL;
+	}
+
+	controller = of_find_node_by_phandle(be32_to_cpup(prop));
+	if (!controller) {
+		pr_err("could not find an 'mbus-controller' node\n");
+		return -ENODEV;
+	}
+
+	if (of_address_to_resource(controller, 0, &mbuswins_res)) {
+		pr_err("cannot get MBUS register address\n");
+		return -EINVAL;
+	}
+
+	if (of_address_to_resource(controller, 1, &sdramwins_res)) {
+		pr_err("cannot get SDRAM register address\n");
+		return -EINVAL;
+	}
+
+	ret = mvebu_mbus_common_init(&mbus_state,
+				     mbuswins_res.start,
+				     resource_size(&mbuswins_res),
+				     sdramwins_res.start,
+				     resource_size(&sdramwins_res));
+	return ret;
+}
+#endif
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 9245b66..eadefd6 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -74,5 +74,6 @@ int mvebu_mbus_del_window(phys_addr_t base, size_t size);
 int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
 		    size_t mbus_size, phys_addr_t sdram_phys_base,
 		    size_t sdram_size);
+int mvebu_mbus_dt_init(void);
 
 #endif /* __LINUX_MBUS_H */
-- 
1.8.1.5



From linux at arm.linux.org.uk  Fri Jul 26 09:14:23 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 14:14:23 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726130927.GC4219@netboy>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy> <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
Message-ID: <20130726131423.GL24642@n2100.arm.linux.org.uk>

On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
> On Fri, Jul 26, 2013 at 10:42:24AM +0100, David Woodhouse wrote:
> > On Fri, 2013-07-26 at 10:01 +0200, Richard Cochran wrote:
> > > On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
> > > > 
> > > > We use DT has a kernel configuration input. Our environment is
> > > > designed to guarantee 100% that the kernel and DT match exactly. DT
> > > > very deliberately isn't an ABI boundary in our systems.
> > > 
> > > Think about what you just said.
> > > 
> > > The DT describes the *hardware* not the kernel. Why should you ever
> > > need to update your DT at all?
> > 
> > Well, the nodes which describe hardware devices, according to the
> > bindings which form an ABI contract between DT and drivers, should not
> > normally change. Although they *can* change, if for example you change
> > the MAC address and that's stored there. Or you change the PHY you want
> > it to use. Or something like that. The *ABI* doesn't change, but the
> > data you express *using* that ABI can change. That's kind of the point.
> 
> Unless I totally misunderstood, the thread is talking about letting
> established bindings change with each new kernel version.  I am
> opposed to that.
> 
> Of course, a user may want to change the values of his MAC addresses,
> if he needs to. But he should never have to change *how* he specifies
> those addresses.
> 
> So, as long as everyone can agree to the principle that a working DT
> should remain working after a kernel upgrade, then I'll shut up. In
> actual fact, this is not the case today, nor was it ever so in the
> past, AFAICT, but it never hurts to set goals.

We agree.

That's precisely why I'm saying that once a binding appears in a -final
released kernel, it is _stable_ by that very fact.  If there were any
doubts about it, it should never have been accepted into the kernel tree
in the first place.

It's no different from how we treat syscalls.  Once we accept a syscall
and it's published in a -final kernel, it can't then be altered - it can
be supplemented by a new syscall with a different interface, but the old
one remains and keeps its semantics for a great many years.

There's no reason for DT to be any different in this regard.


From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:46 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:46 -0300
Subject: [PATCH v9 09/30] bus: mvebu-mbus: Add static window allocation to the
 DT binding
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-10-git-send-email-ezequiel.garcia@free-electrons.com>

This patch adds static window allocation to the device tree binding.
Each first-child of the mbus-compatible node, with a suitable 'ranges'
property, declaring an address translation, will trigger an address
decoding window allocation.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 drivers/bus/mvebu-mbus.c | 127 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 126 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 44a07c4..78b8c04 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -902,6 +902,127 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
 }
 
 #ifdef CONFIG_OF
+/*
+ * The window IDs in the ranges DT property have the following format:
+ *  - bits 28 to 31: MBus custom field
+ *  - bits 24 to 27: window target ID
+ *  - bits 16 to 23: window attribute ID
+ *  - bits  0 to 15: unused
+ */
+#define CUSTOM(id) (((id) & 0xF0000000) >> 24)
+#define TARGET(id) (((id) & 0x0F000000) >> 24)
+#define ATTR(id)   (((id) & 0x00FF0000) >> 16)
+
+static int __init mbus_dt_setup_win(struct mvebu_mbus_state *mbus,
+				    u32 base, u32 size,
+				    u8 target, u8 attr)
+{
+	const struct mvebu_mbus_mapping *map = mbus->soc->map;
+	const char *name;
+	int i;
+
+	/* Search for a suitable window in the existing mappings */
+	for (i = 0; map[i].name; i++)
+		if (map[i].target == target &&
+		    map[i].attr == (attr & map[i].attrmask))
+			break;
+
+	name = map[i].name;
+	if (!name) {
+		pr_err("window 0x%x:0x%x is unknown, skipping\n",
+		       target, attr);
+		return -EINVAL;
+	}
+
+	if (!mvebu_mbus_window_conflicts(mbus, base, size, target, attr)) {
+		pr_err("cannot add window '%s', conflicts with another window\n",
+		       name);
+		return -EBUSY;
+	}
+
+	if (mvebu_mbus_alloc_window(mbus, base, size, MVEBU_MBUS_NO_REMAP,
+				    target, attr)) {
+		pr_err("cannot add window '%s', too many windows\n",
+		       name);
+		return -ENOMEM;
+	}
+	return 0;
+}
+
+static int __init
+mbus_parse_ranges(struct device_node *node,
+		  int *addr_cells, int *c_addr_cells, int *c_size_cells,
+		  int *cell_count, const __be32 **ranges_start,
+		  const __be32 **ranges_end)
+{
+	const __be32 *prop;
+	int ranges_len, tuple_len;
+
+	/* Allow a node with no 'ranges' property */
+	*ranges_start = of_get_property(node, "ranges", &ranges_len);
+	if (*ranges_start == NULL) {
+		*addr_cells = *c_addr_cells = *c_size_cells = *cell_count = 0;
+		*ranges_start = *ranges_end = NULL;
+		return 0;
+	}
+	*ranges_end = *ranges_start + ranges_len / sizeof(__be32);
+
+	*addr_cells = of_n_addr_cells(node);
+
+	prop = of_get_property(node, "#address-cells", NULL);
+	*c_addr_cells = be32_to_cpup(prop);
+
+	prop = of_get_property(node, "#size-cells", NULL);
+	*c_size_cells = be32_to_cpup(prop);
+
+	*cell_count = *addr_cells + *c_addr_cells + *c_size_cells;
+	tuple_len = (*cell_count) * sizeof(__be32);
+
+	if (ranges_len % tuple_len) {
+		pr_warn("malformed ranges entry '%s'\n", node->name);
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static int __init mbus_dt_setup(struct mvebu_mbus_state *mbus,
+				struct device_node *np)
+{
+	int addr_cells, c_addr_cells, c_size_cells;
+	int i, ret, cell_count;
+	const __be32 *r, *ranges_start, *ranges_end;
+
+	ret = mbus_parse_ranges(np, &addr_cells, &c_addr_cells,
+				&c_size_cells, &cell_count,
+				&ranges_start, &ranges_end);
+	if (ret < 0)
+		return ret;
+
+	for (i = 0, r = ranges_start; r < ranges_end; r += cell_count, i++) {
+		u32 windowid, base, size;
+		u8 target, attr;
+
+		/*
+		 * An entry with a non-zero custom field do not
+		 * correspond to a static window, so skip it.
+		 */
+		windowid = of_read_number(r, 1);
+		if (CUSTOM(windowid))
+			continue;
+
+		target = TARGET(windowid);
+		attr = ATTR(windowid);
+
+		base = of_read_number(r + c_addr_cells, addr_cells);
+		size = of_read_number(r + c_addr_cells + addr_cells,
+				      c_size_cells);
+		ret = mbus_dt_setup_win(mbus, base, size, target, attr);
+		if (ret < 0)
+			return ret;
+	}
+	return 0;
+}
+
 int __init mvebu_mbus_dt_init(void)
 {
 	struct resource mbuswins_res, sdramwins_res;
@@ -946,6 +1067,10 @@ int __init mvebu_mbus_dt_init(void)
 				     resource_size(&mbuswins_res),
 				     sdramwins_res.start,
 				     resource_size(&sdramwins_res));
-	return ret;
+	if (ret)
+		return ret;
+
+	/* Setup statically declared windows in the DT */
+	return mbus_dt_setup(&mbus_state, np);
 }
 #endif
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:48 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:48 -0300
Subject: [PATCH v9 11/30] PCI: mvebu: Adapt to the new device tree layout
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-12-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

The new device tree layout encodes the window's target ID and attribute
in the PCIe controller node's ranges property. This allows to parse
such entries to obtain such information and use the recently introduced
MBus API to create the windows, instead of using the current name based
scheme.

Acked-by: Bjorn Helgaas <bhelgaas at google.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 drivers/pci/host/pci-mvebu.c | 113 ++++++++++++++++++++++++++++++++-----------
 1 file changed, 84 insertions(+), 29 deletions(-)

diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 13a633b..424a7b8 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -123,6 +123,10 @@ struct mvebu_pcie_port {
 	u32 port;
 	u32 lane;
 	int devfn;
+	unsigned int mem_target;
+	unsigned int mem_attr;
+	unsigned int io_target;
+	unsigned int io_attr;
 	struct clk *clk;
 	struct mvebu_sw_pci_bridge bridge;
 	struct device_node *dn;
@@ -307,10 +311,9 @@ static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port *port)
 			    (port->bridge.iolimitupper << 16)) -
 			    iobase);
 
-	mvebu_mbus_add_window_remap_flags(port->name, port->iowin_base,
-					  port->iowin_size,
-					  iobase,
-					  MVEBU_MBUS_PCI_IO);
+	mvebu_mbus_add_window_remap_by_id(port->io_target, port->io_attr,
+					  port->iowin_base, port->iowin_size,
+					  iobase);
 
 	pci_ioremap_io(iobase, port->iowin_base);
 }
@@ -342,10 +345,8 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
 		(((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) -
 		port->memwin_base;
 
-	mvebu_mbus_add_window_remap_flags(port->name, port->memwin_base,
-					  port->memwin_size,
-					  MVEBU_MBUS_NO_REMAP,
-					  MVEBU_MBUS_PCI_MEM);
+	mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr,
+				    port->memwin_base, port->memwin_size);
 }
 
 /*
@@ -755,12 +756,54 @@ mvebu_pcie_map_registers(struct platform_device *pdev,
 	return devm_request_and_ioremap(&pdev->dev, &regs);
 }
 
+#define DT_FLAGS_TO_TYPE(flags)       (((flags) >> 24) & 0x03)
+#define    DT_TYPE_IO                 0x1
+#define    DT_TYPE_MEM32              0x2
+#define DT_CPUADDR_TO_TARGET(cpuaddr) (((cpuaddr) >> 56) & 0xFF)
+#define DT_CPUADDR_TO_ATTR(cpuaddr)   (((cpuaddr) >> 48) & 0xFF)
+
+static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
+			      unsigned long type, int *tgt, int *attr)
+{
+	const int na = 3, ns = 2;
+	const __be32 *range;
+	int rlen, nranges, rangesz, pna, i;
+
+	range = of_get_property(np, "ranges", &rlen);
+	if (!range)
+		return -EINVAL;
+
+	pna = of_n_addr_cells(np);
+	rangesz = pna + na + ns;
+	nranges = rlen / sizeof(__be32) / rangesz;
+
+	for (i = 0; i < nranges; i++) {
+		u32 flags = of_read_number(range, 1);
+		u32 slot = of_read_number(range, 2);
+		u64 cpuaddr = of_read_number(range + na, pna);
+		unsigned long rtype;
+
+		if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_IO)
+			rtype = IORESOURCE_IO;
+		else if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_MEM32)
+			rtype = IORESOURCE_MEM;
+
+		if (slot == PCI_SLOT(devfn) && type == rtype) {
+			*tgt = DT_CPUADDR_TO_TARGET(cpuaddr);
+			*attr = DT_CPUADDR_TO_ATTR(cpuaddr);
+			return 0;
+		}
+
+		range += rangesz;
+	}
+
+	return -ENOENT;
+}
+
 static int __init mvebu_pcie_probe(struct platform_device *pdev)
 {
 	struct mvebu_pcie *pcie;
 	struct device_node *np = pdev->dev.of_node;
-	struct of_pci_range range;
-	struct of_pci_range_parser parser;
 	struct device_node *child;
 	int i, ret;
 
@@ -771,29 +814,25 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
 
 	pcie->pdev = pdev;
 
-	if (of_pci_range_parser_init(&parser, np))
+	/* Get the PCIe memory and I/O aperture */
+	mvebu_mbus_get_pcie_mem_aperture(&pcie->mem);
+	if (resource_size(&pcie->mem) == 0) {
+		dev_err(&pdev->dev, "invalid memory aperture size\n");
 		return -EINVAL;
+	}
 
-	/* Get the I/O and memory ranges from DT */
-	for_each_of_pci_range(&parser, &range) {
-		unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
-		if (restype == IORESOURCE_IO) {
-			of_pci_range_to_resource(&range, np, &pcie->io);
-			of_pci_range_to_resource(&range, np, &pcie->realio);
-			pcie->io.name = "I/O";
-			pcie->realio.start = max_t(resource_size_t,
-						   PCIBIOS_MIN_IO,
-						   range.pci_addr);
-			pcie->realio.end = min_t(resource_size_t,
-						 IO_SPACE_LIMIT,
-						 range.pci_addr + range.size);
-		}
-		if (restype == IORESOURCE_MEM) {
-			of_pci_range_to_resource(&range, np, &pcie->mem);
-			pcie->mem.name = "MEM";
-		}
+	mvebu_mbus_get_pcie_io_aperture(&pcie->io);
+	if (resource_size(&pcie->io) == 0) {
+		dev_err(&pdev->dev, "invalid I/O aperture size\n");
+		return -EINVAL;
 	}
 
+	pcie->realio.flags = pcie->io.flags;
+	pcie->realio.start = PCIBIOS_MIN_IO;
+	pcie->realio.end = min_t(resource_size_t,
+				  IO_SPACE_LIMIT,
+				  resource_size(&pcie->io));
+
 	/* Get the bus range */
 	ret = of_pci_parse_bus_range(np, &pcie->busn);
 	if (ret) {
@@ -841,6 +880,22 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
 		if (port->devfn < 0)
 			continue;
 
+		ret = mvebu_get_tgt_attr(np, port->devfn, IORESOURCE_MEM,
+					 &port->mem_target, &port->mem_attr);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "PCIe%d.%d: cannot get tgt/attr for mem window\n",
+				port->port, port->lane);
+			continue;
+		}
+
+		ret = mvebu_get_tgt_attr(np, port->devfn, IORESOURCE_IO,
+					 &port->io_target, &port->io_attr);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "PCIe%d.%d: cannot get tgt/attr for io window\n",
+				port->port, port->lane);
+			continue;
+		}
+
 		port->base = mvebu_pcie_map_registers(pdev, child, port);
 		if (!port->base) {
 			dev_err(&pdev->dev, "PCIe%d.%d: cannot map registers\n",
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:49 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:49 -0300
Subject: [PATCH v9 12/30] PCI: mvebu: Check valid base address before port
 setup
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-13-git-send-email-ezequiel.garcia@free-electrons.com>

This driver does not fail to probe when it cannot obtain
a port base address. Therefore, add a check for NULL base address
before setting up the port, which prevents a kernel panic in such
cases.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 drivers/pci/host/pci-mvebu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 424a7b8..338691b 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -662,6 +662,8 @@ static int __init mvebu_pcie_setup(int nr, struct pci_sys_data *sys)
 
 	for (i = 0; i < pcie->nports; i++) {
 		struct mvebu_pcie_port *port = &pcie->ports[i];
+		if (!port->base)
+			continue;
 		mvebu_pcie_setup_hw(port);
 	}
 
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:50 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:50 -0300
Subject: [PATCH v9 13/30] bus: mvebu-mbus: Remove the no longer used
 name-based API
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-14-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Now that every user of the deprecated name-based API has been
converted to using the ID-based API, let's remove the former one.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 drivers/bus/mvebu-mbus.c | 38 --------------------------------------
 include/linux/mbus.h     |  5 -----
 2 files changed, 43 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 929fed1..b4a7382 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -766,44 +766,6 @@ int mvebu_mbus_add_window_remap_by_id(unsigned int target,
 	return mvebu_mbus_alloc_window(s, base, size, remap, target, attribute);
 }
 
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
-				      size_t size, phys_addr_t remap,
-				      unsigned int flags)
-{
-	struct mvebu_mbus_state *s = &mbus_state;
-	u8 target, attr;
-	int i;
-
-	if (!s->soc->map)
-		return -ENODEV;
-
-	for (i = 0; s->soc->map[i].name; i++)
-		if (!strcmp(s->soc->map[i].name, devname))
-			break;
-
-	if (!s->soc->map[i].name) {
-		pr_err("unknown device '%s'\n", devname);
-		return -ENODEV;
-	}
-
-	target = s->soc->map[i].target;
-	attr   = s->soc->map[i].attr;
-
-	if (flags == MVEBU_MBUS_PCI_MEM)
-		attr |= 0x8;
-	else if (flags == MVEBU_MBUS_PCI_WA)
-		attr |= 0x28;
-
-	return mvebu_mbus_add_window_remap_by_id(target, attr, base,
-						 size, remap);
-}
-
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base, size_t size)
-{
-	return mvebu_mbus_add_window_remap_flags(devname, base, size,
-						 MVEBU_MBUS_NO_REMAP, 0);
-}
-
 int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
 				phys_addr_t base, size_t size)
 {
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 650bc15..345b8c5 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -63,15 +63,10 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
 
 void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
 void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
-int mvebu_mbus_add_window_remap_flags(const char *devname, phys_addr_t base,
-				      size_t size, phys_addr_t remap,
-				      unsigned int flags);
 int mvebu_mbus_add_window_remap_by_id(unsigned int target,
 				      unsigned int attribute,
 				      phys_addr_t base, size_t size,
 				      phys_addr_t remap);
-int mvebu_mbus_add_window(const char *devname, phys_addr_t base,
-			  size_t size);
 int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
 				phys_addr_t base, size_t size);
 int mvebu_mbus_del_window(phys_addr_t base, size_t size);
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:54 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:54 -0300
Subject: [PATCH v9 17/30] ARM: mvebu: Remove the harcoded BootROM window
 allocation
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-18-git-send-email-ezequiel.garcia@free-electrons.com>

The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/mach-mvebu/platsmp.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index ce81d30..c6b00fc 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -21,6 +21,7 @@
 #include <linux/smp.h>
 #include <linux/clk.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/mbus.h>
 #include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
@@ -29,6 +30,9 @@
 #include "pmsu.h"
 #include "coherency.h"
 
+#define AXP_BOOTROM_BASE 0xfff00000
+#define AXP_BOOTROM_SIZE 0x100000
+
 void __init set_secondary_cpus_clock(void)
 {
 	int thiscpu;
@@ -114,10 +118,29 @@ static void __init armada_xp_smp_init_cpus(void)
 
 void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
 {
+	struct device_node *node;
+	struct resource res;
+	int err;
+
 	set_secondary_cpus_clock();
 	flush_cache_all();
 	set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
-	mvebu_mbus_add_window("bootrom", 0xfff00000, SZ_1M);
+
+	/*
+	 * In order to boot the secondary CPUs we need to ensure
+	 * the bootROM is mapped at the correct address.
+	 */
+	node = of_find_compatible_node(NULL, NULL, "marvell,bootrom");
+	if (!node)
+		panic("Cannot find 'marvell,bootrom' compatible node");
+
+	err = of_address_to_resource(node, 0, &res);
+	if (err < 0)
+		panic("Cannot get 'bootrom' node address");
+
+	if (res.start != AXP_BOOTROM_BASE ||
+	    resource_size(&res) != AXP_BOOTROM_SIZE)
+		panic("The address for the BootROM is incorrect");
 }
 
 struct smp_operations armada_xp_smp_ops __initdata = {
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:55 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:55 -0300
Subject: [PATCH v9 18/30] ARM: mvebu: Initialize MBus using the DT binding
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-19-git-send-email-ezequiel.garcia@free-electrons.com>

Now that the mbus device tree binding has been introduced, we can
switch over to it.

Also, and since the initialization of the mbus driver is quite
fundamental for the system to work properly, this patch adds a BUG()
in case mbus fails to initialize.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/mach-mvebu/armada-370-xp.c | 34 +---------------------------------
 1 file changed, 1 insertion(+), 33 deletions(-)

diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 97cbb80..829b573 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -34,44 +34,12 @@ static void __init armada_370_xp_map_io(void)
 	debug_ll_io_init();
 }
 
-/*
- * This initialization will be replaced by a DT-based
- * initialization once the mvebu-mbus driver gains DT support.
- */
-
-#define ARMADA_370_XP_MBUS_WINS_OFFS   0x20000
-#define ARMADA_370_XP_MBUS_WINS_SIZE   0x100
-#define ARMADA_370_XP_SDRAM_WINS_OFFS  0x20180
-#define ARMADA_370_XP_SDRAM_WINS_SIZE  0x20
-
-static void __init armada_370_xp_mbus_init(void)
-{
-	char *mbus_soc_name;
-	struct device_node *dn;
-	const __be32 mbus_wins_offs = cpu_to_be32(ARMADA_370_XP_MBUS_WINS_OFFS);
-	const __be32 sdram_wins_offs = cpu_to_be32(ARMADA_370_XP_SDRAM_WINS_OFFS);
-
-	if (of_machine_is_compatible("marvell,armada370"))
-		mbus_soc_name = "marvell,armada370-mbus";
-	else
-		mbus_soc_name = "marvell,armadaxp-mbus";
-
-	dn = of_find_node_by_name(NULL, "internal-regs");
-	BUG_ON(!dn);
-
-	mvebu_mbus_init(mbus_soc_name,
-			of_translate_address(dn, &mbus_wins_offs),
-			ARMADA_370_XP_MBUS_WINS_SIZE,
-			of_translate_address(dn, &sdram_wins_offs),
-			ARMADA_370_XP_SDRAM_WINS_SIZE);
-}
-
 static void __init armada_370_xp_timer_and_clk_init(void)
 {
 	of_clk_init(NULL);
 	armada_370_xp_timer_init();
 	coherency_init();
-	armada_370_xp_mbus_init();
+	BUG_ON(mvebu_mbus_dt_init());
 #ifdef CONFIG_CACHE_L2X0
 	l2x0_of_init(0, ~0UL);
 #endif
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:56 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:56 -0300
Subject: [PATCH v9 19/30] ARM: mvebu: Use the preprocessor on Armada 370/XP
 device tree files
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-20-git-send-email-ezequiel.garcia@free-electrons.com>

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/boot/dts/armada-370-db.dts              | 2 +-
 arch/arm/boot/dts/armada-370-mirabox.dts         | 2 +-
 arch/arm/boot/dts/armada-370-rd.dts              | 2 +-
 arch/arm/boot/dts/armada-370.dtsi                | 2 +-
 arch/arm/boot/dts/armada-xp-db.dts               | 2 +-
 arch/arm/boot/dts/armada-xp-gp.dts               | 2 +-
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         | 2 +-
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         | 2 +-
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 2 +-
 arch/arm/boot/dts/armada-xp.dtsi                 | 2 +-
 10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index beee169..55b986c 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Marvell Armada 370 Evaluation Board";
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 45b1077..37530af 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -9,7 +9,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Globalscale Mirabox";
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index a3a2fed..7aa2171 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -12,7 +12,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-370.dtsi"
+#include "armada-370.dtsi"
 
 / {
 	model = "Marvell Armada 370 Reference Design";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..08ec6e3 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -15,7 +15,7 @@
  * common to all Armada SoCs.
  */
 
-/include/ "armada-370-xp.dtsi"
+#include "armada-370-xp.dtsi"
 /include/ "skeleton.dtsi"
 
 / {
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index e28e68f..a9bd766 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78460.dtsi"
+#include "armada-xp-mv78460.dtsi"
 
 / {
 	model = "Marvell Armada XP Evaluation Board";
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index c87b2de..54843e5 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -14,7 +14,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78460.dtsi"
+#include "armada-xp-mv78460.dtsi"
 
 / {
 	model = "Marvell Armada XP Development Board DB-MV784MP-GP";
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2d9335d..985373a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -13,7 +13,7 @@
  * common to all Armada XP SoCs.
  */
 
-/include/ "armada-xp.dtsi"
+#include "armada-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP MV78260 SoC";
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index c7b1f4d..f8bf25a 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -13,7 +13,7 @@
  * common to all Armada XP SoCs.
  */
 
-/include/ "armada-xp.dtsi"
+#include "armada-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP MV78460 SoC";
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 8f51045..d090264 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -11,7 +11,7 @@
  */
 
 /dts-v1/;
-/include/ "armada-xp-mv78260.dtsi"
+#include "armada-xp-mv78260.dtsi"
 
 / {
 	model = "PlatHome OpenBlocks AX3-4 board";
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 416eb94..8c07bfe 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -16,7 +16,7 @@
  * common to all Armada SoCs.
  */
 
-/include/ "armada-370-xp.dtsi"
+#include "armada-370-xp.dtsi"
 
 / {
 	model = "Marvell Armada XP family SoC";
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:57 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:57 -0300
Subject: [PATCH v9 20/30] ARM: mvebu: Add MBus to Armada 370/XP device tree
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-21-git-send-email-ezequiel.garcia@free-electrons.com>

The Armada 370/XP SoC family has a completely configurable address
space handled by the MBus controller.

This patch introduces the device tree layout of MBus, making the
'soc' node as mbus-compatible.
Since every peripheral/controller is a child of this 'soc' node,
this makes all of them sit behind the mbus, thus describing the
hardware accurately.

A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/boot/dts/armada-370-db.dts              |  2 ++
 arch/arm/boot/dts/armada-370-mirabox.dts         |  2 ++
 arch/arm/boot/dts/armada-370-rd.dts              |  2 ++
 arch/arm/boot/dts/armada-370-xp.dtsi             | 15 ++++++++++-----
 arch/arm/boot/dts/armada-370.dtsi                |  4 ++--
 arch/arm/boot/dts/armada-xp-db.dts               |  4 +---
 arch/arm/boot/dts/armada-xp-gp.dts               |  4 +---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  4 +---
 arch/arm/boot/dts/armada-xp.dtsi                 |  2 ++
 9 files changed, 23 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 55b986c..5920b4e 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,6 +30,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 37530af..a4202b6 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,6 +25,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index 7aa2171..dd0ba01 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,6 +28,8 @@
 	};
 
 	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 90b1176..62639b4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -18,6 +18,8 @@
 
 /include/ "skeleton64.dtsi"
 
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
 / {
 	model = "Marvell Armada 370 and XP SoC";
 	compatible = "marvell,armada-370-xp";
@@ -38,18 +40,21 @@
 	};
 
 	soc {
-		#address-cells = <1>;
+		#address-cells = <2>;
 		#size-cells = <1>;
-		compatible = "simple-bus";
+		controller = <&mbusc>;
 		interrupt-parent = <&mpic>;
-		ranges = <0          0 0xd0000000 0x0100000 /* internal registers */
-			  0xe0000000 0 0xe0000000 0x8100000 /* PCIe */>;
 
 		internal-regs {
 			compatible = "simple-bus";
 			#address-cells = <1>;
 			#size-cells = <1>;
-			ranges;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
 
 			mpic: interrupt-controller at 20000 {
 				compatible = "marvell,mpic";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 08ec6e3..4b54e51 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -29,8 +29,8 @@
 	};
 
 	soc {
-		ranges = <0          0xd0000000 0x0100000 /* internal registers */
-			  0xe0000000 0xe0000000 0x8100000 /* PCIe */>;
+		compatible = "marvell,armada370-mbus", "simple-bus";
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index a9bd766..0d4ce54 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,9 +30,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000	/* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000     /* PCIe */
-			  0xf0000000 0 0xf0000000 0x1000000>;	/* Device Bus, NOR 16MiB   */
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 54843e5..2fa9209 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,9 +39,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000  /* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000 /* PCIe */
-			  0xf0000000 0 0xf0000000 0x1000000 /* Device Bus, NOR 16MiB  */>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index d090264..a3e3a12 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,9 +27,7 @@
 	};
 
 	soc {
-		ranges = <0          0 0xd0000000 0x100000	/* Internal registers 1MiB */
-			  0xe0000000 0 0xe0000000 0x8100000     /* PCIe */
-			  0xf0000000 0 0xf0000000 0x8000000     /* Device Bus, NOR 128MiB   */>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 8c07bfe..8033824 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -27,6 +27,8 @@
 	};
 
 	soc {
+		compatible = "marvell,armadaxp-mbus", "simple-bus";
+
 		internal-regs {
 			L2: l2-cache {
 				compatible = "marvell,aurora-system-cache";
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:58 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:58 -0300
Subject: [PATCH v9 21/30] ARM: mvebu: Add BootROM to Armada 370/XP device tree
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-22-git-send-email-ezequiel.garcia@free-electrons.com>

In order to access the SoC BootROM, we need to declare a mapping
(through a ranges property). The mbus driver will use this property
to allocate a suitable address decoding window.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/boot/dts/armada-370-db.dts              | 3 ++-
 arch/arm/boot/dts/armada-370-mirabox.dts         | 3 ++-
 arch/arm/boot/dts/armada-370-rd.dts              | 3 ++-
 arch/arm/boot/dts/armada-370.dtsi                | 5 +++++
 arch/arm/boot/dts/armada-xp-db.dts               | 3 ++-
 arch/arm/boot/dts/armada-xp-gp.dts               | 3 ++-
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 3 ++-
 arch/arm/boot/dts/armada-xp.dtsi                 | 5 +++++
 8 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 5920b4e..90ce29d 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,7 +30,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index a4202b6..19341d2 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,7 +25,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index dd0ba01..0b3acf3 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,7 +28,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 4b54e51..bd21d49 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -31,6 +31,11 @@
 	soc {
 		compatible = "marvell,armada370-mbus", "simple-bus";
 
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
+		};
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 0d4ce54..857f272 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,7 +30,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 2fa9209..934dc46 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,7 +39,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index a3e3a12..1700f6f 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,7 +27,8 @@
 	};
 
 	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000>;
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
 
 		internal-regs {
 			serial at 12000 {
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 8033824..7ba99ce 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -29,6 +29,11 @@
 	soc {
 		compatible = "marvell,armadaxp-mbus", "simple-bus";
 
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
+		};
+
 		internal-regs {
 			L2: l2-cache {
 				compatible = "marvell,aurora-system-cache";
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:51 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:51 -0300
Subject: [PATCH v9 14/30] bus: mvebu-mbus: Remove name -> target,
 attribute mapping tables
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-15-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

This tables were used together with the name-based MBus window
creation API. Since that's has been removed, we can also remove
the tables.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 drivers/bus/mvebu-mbus.c | 150 +++--------------------------------------------
 1 file changed, 7 insertions(+), 143 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index b4a7382..c182ef5 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -97,33 +97,6 @@
 
 #define DOVE_DDR_BASE_CS_OFF(n) ((n) << 4)
 
-struct mvebu_mbus_mapping {
-	const char *name;
-	u8 target;
-	u8 attr;
-	u8 attrmask;
-};
-
-/*
- * Masks used for the 'attrmask' field of mvebu_mbus_mapping. They
- * allow to get the real attribute value, discarding the special bits
- * used to select a PCI MEM region or a PCI WA region. This allows the
- * debugfs code to reverse-match the name of a device from its
- * target/attr values.
- *
- * For all devices except PCI, all bits of 'attr' must be
- * considered. For most SoCs, only bit 3 should be ignored (it allows
- * to select between PCI MEM and PCI I/O). On Orion5x however, there
- * is the special bit 5 to select a PCI WA region.
- */
-#define MAPDEF_NOMASK       0xff
-#define MAPDEF_PCIMASK      0xf7
-#define MAPDEF_ORIONPCIMASK 0xd7
-
-/* Macro used to define one mvebu_mbus_mapping entry */
-#define MAPDEF(__n, __t, __a, __m) \
-	{ .name = __n, .target = __t, .attr = __a, .attrmask = __m }
-
 struct mvebu_mbus_state;
 
 struct mvebu_mbus_soc_data {
@@ -133,7 +106,6 @@ struct mvebu_mbus_soc_data {
 	void (*setup_cpu_target)(struct mvebu_mbus_state *s);
 	int (*show_cpu_target)(struct mvebu_mbus_state *s,
 			       struct seq_file *seq, void *v);
-	const struct mvebu_mbus_mapping *map;
 };
 
 struct mvebu_mbus_state {
@@ -430,8 +402,7 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void *v)
 		u64 wbase, wremap;
 		u32 wsize;
 		u8 wtarget, wattr;
-		int enabled, i;
-		const char *name;
+		int enabled;
 
 		mvebu_mbus_read_window(mbus, win,
 				       &enabled, &wbase, &wsize,
@@ -442,18 +413,9 @@ static int mvebu_devs_debug_show(struct seq_file *seq, void *v)
 			continue;
 		}
 
-
-		for (i = 0; mbus->soc->map[i].name; i++)
-			if (mbus->soc->map[i].target == wtarget &&
-			    mbus->soc->map[i].attr ==
-			    (wattr & mbus->soc->map[i].attrmask))
-				break;
-
-		name = mbus->soc->map[i].name ?: "unknown";
-
-		seq_printf(seq, "[%02d] %016llx - %016llx : %s",
+		seq_printf(seq, "[%02d] %016llx - %016llx : %04x:%04x",
 			   win, (unsigned long long)wbase,
-			   (unsigned long long)(wbase + wsize), name);
+			   (unsigned long long)(wbase + wsize), wtarget, wattr);
 
 		if (win < mbus->soc->num_remappable_wins) {
 			seq_printf(seq, " (remap %016llx)\n",
@@ -578,45 +540,12 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
 	mvebu_mbus_dram_info.num_cs = cs;
 }
 
-static const struct mvebu_mbus_mapping armada_370_map[] = {
-	MAPDEF("bootrom",     1, 0xe0, MAPDEF_NOMASK),
-	MAPDEF("devbus-boot", 1, 0x2f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x3e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x3d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x3b, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs3",  1, 0x37, MAPDEF_NOMASK),
-	MAPDEF("pcie0.0",     4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",     8, 0xe0, MAPDEF_PCIMASK),
-	{},
-};
-
 static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
 	.num_wins            = 20,
 	.num_remappable_wins = 8,
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = armada_370_map,
-};
-
-static const struct mvebu_mbus_mapping armada_xp_map[] = {
-	MAPDEF("bootrom",     1, 0x1d, MAPDEF_NOMASK),
-	MAPDEF("devbus-boot", 1, 0x2f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x3e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x3d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x3b, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs3",  1, 0x37, MAPDEF_NOMASK),
-	MAPDEF("pcie0.0",     4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.1",     4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.2",     4, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.3",     4, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",     8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.1",     8, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.2",     8, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.3",     8, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie2.0",     4, 0xf0, MAPDEF_PCIMASK),
-	MAPDEF("pcie3.0",     8, 0xf0, MAPDEF_PCIMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
@@ -625,15 +554,6 @@ static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = armada_xp_map,
-};
-
-static const struct mvebu_mbus_mapping kirkwood_map[] = {
-	MAPDEF("pcie0.0", 4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0", 4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("sram",    3, 0x01, MAPDEF_NOMASK),
-	MAPDEF("nand",    1, 0x2f, MAPDEF_NOMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data kirkwood_mbus_data = {
@@ -642,16 +562,6 @@ static const struct mvebu_mbus_soc_data kirkwood_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = kirkwood_map,
-};
-
-static const struct mvebu_mbus_mapping dove_map[] = {
-	MAPDEF("pcie0.0",    0x4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0",    0x8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("cesa",       0x3, 0x01, MAPDEF_NOMASK),
-	MAPDEF("bootrom",    0x1, 0xfd, MAPDEF_NOMASK),
-	MAPDEF("scratchpad", 0xd, 0x0, MAPDEF_NOMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data dove_mbus_data = {
@@ -660,18 +570,6 @@ static const struct mvebu_mbus_soc_data dove_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_dove_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_dove,
-	.map                 = dove_map,
-};
-
-static const struct mvebu_mbus_mapping orion5x_map[] = {
-	MAPDEF("pcie0.0",     4, 0x51, MAPDEF_ORIONPCIMASK),
-	MAPDEF("pci0.0",      3, 0x51, MAPDEF_ORIONPCIMASK),
-	MAPDEF("devbus-boot", 1, 0x0f, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs0",  1, 0x1e, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs1",  1, 0x1d, MAPDEF_NOMASK),
-	MAPDEF("devbus-cs2",  1, 0x1b, MAPDEF_NOMASK),
-	MAPDEF("sram",        0, 0x00, MAPDEF_NOMASK),
-	{},
 };
 
 /*
@@ -684,7 +582,6 @@ static const struct mvebu_mbus_soc_data orion5x_4win_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = orion5x_map,
 };
 
 static const struct mvebu_mbus_soc_data orion5x_2win_mbus_data = {
@@ -693,21 +590,6 @@ static const struct mvebu_mbus_soc_data orion5x_2win_mbus_data = {
 	.win_cfg_offset      = orion_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = orion5x_map,
-};
-
-static const struct mvebu_mbus_mapping mv78xx0_map[] = {
-	MAPDEF("pcie0.0", 4, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.1", 4, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.2", 4, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie0.3", 4, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.0", 8, 0xe0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.1", 8, 0xd0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.2", 8, 0xb0, MAPDEF_PCIMASK),
-	MAPDEF("pcie1.3", 8, 0x70, MAPDEF_PCIMASK),
-	MAPDEF("pcie2.0", 4, 0xf0, MAPDEF_PCIMASK),
-	MAPDEF("pcie3.0", 8, 0xf0, MAPDEF_PCIMASK),
-	{},
 };
 
 static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
@@ -716,7 +598,6 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
 	.win_cfg_offset      = mv78xx0_mbus_win_offset,
 	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
 	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-	.map                 = mv78xx0_map,
 };
 
 /*
@@ -895,33 +776,16 @@ static int __init mbus_dt_setup_win(struct mvebu_mbus_state *mbus,
 				    u32 base, u32 size,
 				    u8 target, u8 attr)
 {
-	const struct mvebu_mbus_mapping *map = mbus->soc->map;
-	const char *name;
-	int i;
-
-	/* Search for a suitable window in the existing mappings */
-	for (i = 0; map[i].name; i++)
-		if (map[i].target == target &&
-		    map[i].attr == (attr & map[i].attrmask))
-			break;
-
-	name = map[i].name;
-	if (!name) {
-		pr_err("window 0x%x:0x%x is unknown, skipping\n",
-		       target, attr);
-		return -EINVAL;
-	}
-
 	if (!mvebu_mbus_window_conflicts(mbus, base, size, target, attr)) {
-		pr_err("cannot add window '%s', conflicts with another window\n",
-		       name);
+		pr_err("cannot add window '%04x:%04x', conflicts with another window\n",
+		       target, attr);
 		return -EBUSY;
 	}
 
 	if (mvebu_mbus_alloc_window(mbus, base, size, MVEBU_MBUS_NO_REMAP,
 				    target, attr)) {
-		pr_err("cannot add window '%s', too many windows\n",
-		       name);
+		pr_err("cannot add window '%04x:%04x', too many windows\n",
+		       target, attr);
 		return -ENOMEM;
 	}
 	return 0;
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:52 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:52 -0300
Subject: [PATCH v9 15/30] bus: mvebu-mbus: Update main description
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-16-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

After replacing the MBus name-based by the new ID-based API
let's fix the general description of the driver at the beginning
of the file.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 drivers/bus/mvebu-mbus.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index c182ef5..26af145 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -35,13 +35,9 @@
  *
  * - Provides an API for platform code or device drivers to
  *   dynamically add or remove address decoding windows for the CPU ->
- *   device accesses. This API is mvebu_mbus_add_window(),
- *   mvebu_mbus_add_window_remap_flags() and
- *   mvebu_mbus_del_window(). Since the (target, attribute) values
- *   differ from one SoC family to another, the API uses a 'const char
- *   *' string to identify devices, and this driver is responsible for
- *   knowing the mapping between the name of a device and its
- *   corresponding (target, attribute) in the current SoC family.
+ *   device accesses. This API is mvebu_mbus_add_window_by_id(),
+ *   mvebu_mbus_add_window_remap_by_id() and
+ *   mvebu_mbus_del_window().
  *
  * - Provides a debugfs interface in /sys/kernel/debug/mvebu-mbus/ to
  *   see the list of CPU -> SDRAM windows and their configuration
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:53 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:53 -0300
Subject: [PATCH v9 16/30] bus: mvebu-mbus: Factorize Armada 370/XP data
 structures
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-17-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

These structures were only different in the mapping tables.
Now that those tables have been removed, it doesn't make any sense
to keep different structures.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 drivers/bus/mvebu-mbus.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 26af145..19ab6ff 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -536,15 +536,7 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
 	mvebu_mbus_dram_info.num_cs = cs;
 }
 
-static const struct mvebu_mbus_soc_data armada_370_mbus_data = {
-	.num_wins            = 20,
-	.num_remappable_wins = 8,
-	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
-	.setup_cpu_target    = mvebu_mbus_default_setup_cpu_target,
-	.show_cpu_target     = mvebu_sdram_debug_show_orion,
-};
-
-static const struct mvebu_mbus_soc_data armada_xp_mbus_data = {
+static const struct mvebu_mbus_soc_data armada_370_xp_mbus_data = {
 	.num_wins            = 20,
 	.num_remappable_wins = 8,
 	.win_cfg_offset      = armada_370_xp_mbus_win_offset,
@@ -604,9 +596,9 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
  */
 static const struct of_device_id of_mvebu_mbus_ids[] = {
 	{ .compatible = "marvell,armada370-mbus",
-	  .data = &armada_370_mbus_data, },
+	  .data = &armada_370_xp_mbus_data, },
 	{ .compatible = "marvell,armadaxp-mbus",
-	  .data = &armada_xp_mbus_data, },
+	  .data = &armada_370_xp_mbus_data, },
 	{ .compatible = "marvell,kirkwood-mbus",
 	  .data = &kirkwood_mbus_data, },
 	{ .compatible = "marvell,dove-mbus",
-- 
1.8.1.5



From festevam at gmail.com  Fri Jul 26 09:19:44 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 26 Jul 2013 10:19:44 -0300
Subject: [PATCH RESEND v2] ARM: dt: Use the 'model' field for printing the
 hardware revision
Message-ID: <1374844784-2639-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

When booting a device tree kernel, we get the following output from 
'cat /proc/cpuinfo': 

$ cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 5 (v7l)
BogoMIPS        : 531.66
Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc08
CPU revision    : 5

Hardware        : Freescale i.MX51 (Device Tree Support)
Revision        : 0000
Serial          : 0000000000000000

The Hardware line does not really describe the hardware type, as it is reading
the information from the dt 'machine' field.

In the dt case, read the 'model' field instead, so that we can have a better
description output as follows:

Hardware        : Freescale i.MX51 Babbage Board

The hardware output string is unchanged for the non-dt kernel case.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
Changes since v1:
- Fix typo in 'architecture'
 arch/arm/include/asm/mach/arch.h |  1 +
 arch/arm/kernel/devtree.c        | 15 ++++++++-------
 arch/arm/kernel/setup.c          |  7 ++++++-
 3 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 308ad7d..113d4af 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -23,6 +23,7 @@ struct smp_operations;
 struct machine_desc {
 	unsigned int		nr;		/* architecture number	*/
 	const char		*name;		/* architecture name	*/
+	const char		*model;		/* architecture model */
 	unsigned long		atag_offset;	/* tagged list (relative) */
 	const char *const 	*dt_compat;	/* array of device tree
 						 * 'compatible' strings	*/
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 5af04f6..90d541a 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -178,7 +178,6 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	struct machine_desc *mdesc, *mdesc_best = NULL;
 	unsigned int score, mdesc_score = ~1;
 	unsigned long dt_root;
-	const char *model;
 
 #ifdef CONFIG_ARCH_MULTIPLATFORM
 	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
@@ -224,12 +223,14 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 		dump_machine_table(); /* does not return */
 	}
 
-	model = of_get_flat_dt_prop(dt_root, "model", NULL);
-	if (!model)
-		model = of_get_flat_dt_prop(dt_root, "compatible", NULL);
-	if (!model)
-		model = "<unknown>";
-	pr_info("Machine: %s, model: %s\n", mdesc_best->name, model);
+	mdesc_best->model = of_get_flat_dt_prop(dt_root, "model", NULL);
+	if (!mdesc_best->model)
+		mdesc_best->model = of_get_flat_dt_prop(dt_root, "compatible",
+							NULL);
+	if (!mdesc_best->model)
+		mdesc_best->model = "<unknown>";
+	pr_info("Machine: %s, model: %s\n", mdesc_best->name,
+		mdesc_best->model);
 
 	/* Retrieve various information from the /chosen node */
 	of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 79e8d2f..d22f24b 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -137,6 +137,7 @@ EXPORT_SYMBOL(elf_platform);
 
 static const char *cpu_name;
 static const char *machine_name;
+static const char *model_name;
 static char __initdata cmd_line[COMMAND_LINE_SIZE];
 struct machine_desc *machine_desc __initdata;
 
@@ -786,6 +787,7 @@ void __init setup_arch(char **cmdline_p)
 		mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
 	machine_desc = mdesc;
 	machine_name = mdesc->name;
+	model_name = mdesc->model;
 
 	setup_dma_zone(mdesc);
 
@@ -950,7 +952,10 @@ static int c_show(struct seq_file *m, void *v)
 		seq_printf(m, "CPU revision\t: %d\n\n", cpuid & 15);
 	}
 
-	seq_printf(m, "Hardware\t: %s\n", machine_name);
+	if (model_name)
+		seq_printf(m, "Hardware\t: %s\n", model_name);
+	else
+		seq_printf(m, "Hardware\t: %s\n", machine_name);
 	seq_printf(m, "Revision\t: %04x\n", system_rev);
 	seq_printf(m, "Serial\t\t: %08x%08x\n",
 		   system_serial_high, system_serial_low);
-- 
1.8.1.2



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:17:59 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:17:59 -0300
Subject: [PATCH v9 22/30] ARM: mvebu: Relocate Armada 370/XP DeviceBus device
 tree nodes
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-23-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus has been added to the device tree, it's possible to
move the DeviceBus out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the hardware.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi             | 94 +++++++++++++-----------
 arch/arm/boot/dts/armada-xp-db.dts               | 59 +++++++--------
 arch/arm/boot/dts/armada-xp-gp.dts               | 60 +++++++--------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 65 ++++++++--------
 4 files changed, 140 insertions(+), 138 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 62639b4..073dd20 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -45,6 +45,56 @@
 		controller = <&mbusc>;
 		interrupt-parent = <&mpic>;
 
+		devbus-bootcs {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs0 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs1 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs2 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
+		devbus-cs3 {
+			compatible = "marvell,mvebu-devbus";
+			reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>;
+			ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&coreclk 0>;
+			status = "disabled";
+		};
+
 		internal-regs {
 			compatible = "simple-bus";
 			#address-cells = <1>;
@@ -200,50 +250,6 @@
 				status = "disabled";
 			};
 
-			devbus-bootcs at 10400 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10400 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs0 at 10408 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10408 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs1 at 10410 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10410 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs2 at 10418 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10418 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
-
-			devbus-cs3 at 10420 {
-				compatible = "marvell,mvebu-devbus";
-				reg = <0x10420 0x8>;
-				#address-cells = <1>;
-				#size-cells = <1>;
-				clocks = <&coreclk 0>;
-				status = "disabled";
-			};
 		};
 	};
  };
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 857f272..76ae1a9 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -31,7 +31,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x1000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -160,34 +189,6 @@
 				};
 			};
 
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x1000000>;
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 16 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x1000000>;
-					bank-width = <2>;
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 934dc46..8c0de20 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -40,7 +40,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 16 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x1000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -126,35 +155,6 @@
 				};
 			};
 
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf000000, size 0x1000000 */
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 16 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x1000000>;
-					bank-width = <2>;
-				};
-			};
-
 			pcie-controller {
 				status = "okay";
 
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 1700f6f..2b60ee0 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -28,7 +28,36 @@
 
 	soc {
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
-			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
+
+		devbus-bootcs {
+			status = "okay";
+
+			/* Device Bus parameters are required */
+
+			/* Read parameters */
+			devbus,bus-width    = <8>;
+			devbus,turn-off-ps  = <60000>;
+			devbus,badr-skew-ps = <0>;
+			devbus,acc-first-ps = <124000>;
+			devbus,acc-next-ps  = <248000>;
+			devbus,rd-setup-ps  = <0>;
+			devbus,rd-hold-ps   = <0>;
+
+			/* Write parameters */
+			devbus,sync-enable = <0>;
+			devbus,wr-high-ps  = <60000>;
+			devbus,wr-low-ps   = <60000>;
+			devbus,ale-wr-ps   = <60000>;
+
+			/* NOR 128 MiB */
+			nor at 0 {
+				compatible = "cfi-flash";
+				reg = <0 0x8000000>;
+				bank-width = <2>;
+			};
+		};
 
 		internal-regs {
 			serial at 12000 {
@@ -148,40 +177,6 @@
 				status = "okay";
 			};
 
-			/* USB interface in the mini-PCIe connector */
-			usb at 52000 {
-				status = "okay";
-			};
-
-			devbus-bootcs at 10400 {
-				status = "okay";
-				ranges = <0 0xf0000000 0x8000000>; /* @addr 0xf000000, size 0x8000000 */
-
-				/* Device Bus parameters are required */
-
-				/* Read parameters */
-				devbus,bus-width    = <8>;
-				devbus,turn-off-ps  = <60000>;
-				devbus,badr-skew-ps = <0>;
-				devbus,acc-first-ps = <124000>;
-				devbus,acc-next-ps  = <248000>;
-				devbus,rd-setup-ps  = <0>;
-				devbus,rd-hold-ps   = <0>;
-
-				/* Write parameters */
-				devbus,sync-enable = <0>;
-				devbus,wr-high-ps  = <60000>;
-				devbus,wr-low-ps   = <60000>;
-				devbus,ale-wr-ps   = <60000>;
-
-				/* NOR 128 MiB */
-				nor at 0 {
-					compatible = "cfi-flash";
-					reg = <0 0x8000000>;
-					bank-width = <2>;
-				};
-			};
-
 			pcie-controller {
 				status = "okay";
 				/* Internal mini-PCIe connector */
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:18:01 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:18:01 -0300
Subject: [PATCH v9 24/30] ARM: kirkwood: Split DT and legacy MBus
 initialization
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-25-git-send-email-ezequiel.garcia@free-electrons.com>

This commit replaces the legacy MBus initialization with the new
DT-based in Kirkwood. For boards that are not yet converted to DT,
we keep the legacy initialization.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/mach-kirkwood/board-dt.c | 1 +
 arch/arm/mach-kirkwood/common.c   | 8 ++++----
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 6e122ed..682b7ac 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -87,6 +87,7 @@ static void __init kirkwood_dt_init(void)
 	 */
 	writel(readl(CPU_CONFIG) & ~CPU_CONFIG_ERROR_PROP, CPU_CONFIG);
 
+	BUG_ON(mvebu_mbus_dt_init());
 	kirkwood_setup_wins();
 
 	kirkwood_l2_init();
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index 165e751..15b7e72 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -534,10 +534,6 @@ void __init kirkwood_cpuidle_init(void)
 void __init kirkwood_init_early(void)
 {
 	orion_time_set_base(TIMER_VIRT_BASE);
-
-	mvebu_mbus_init("marvell,kirkwood-mbus",
-			BRIDGE_WINS_BASE, BRIDGE_WINS_SZ,
-			DDR_WINDOW_CPU_BASE, DDR_WINDOW_CPU_SZ);
 }
 
 int kirkwood_tclk;
@@ -713,6 +709,10 @@ void __init kirkwood_init(void)
 	 */
 	writel(readl(CPU_CONFIG) & ~CPU_CONFIG_ERROR_PROP, CPU_CONFIG);
 
+	BUG_ON(mvebu_mbus_init("marvell,kirkwood-mbus",
+			BRIDGE_WINS_BASE, BRIDGE_WINS_SZ,
+			DDR_WINDOW_CPU_BASE, DDR_WINDOW_CPU_SZ));
+
 	kirkwood_setup_wins();
 
 	kirkwood_l2_init();
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:18:00 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:18:00 -0300
Subject: [PATCH v9 23/30] ARM: mvebu: Relocate Armada 370/XP PCIe device tree
 nodes
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-24-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.

Moving the PCIe nodes, we now need to introduce an extra cell to
encode the window target ID and attribute. Since this depends on
the PCIe port, we split the ranges translation entries, to correspond
to each MBus window.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/boot/dts/armada-370-mirabox.dts         |  32 +-
 arch/arm/boot/dts/armada-370-xp.dtsi             |   2 +
 arch/arm/boot/dts/armada-370.dtsi                | 101 +++---
 arch/arm/boot/dts/armada-xp-db.dts               |  67 ++--
 arch/arm/boot/dts/armada-xp-gp.dts               |  42 +--
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         | 222 ++++++------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         | 261 ++++++++-------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         | 409 ++++++++++++-----------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  18 +-
 9 files changed, 612 insertions(+), 542 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 19341d2..2471d9d 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -28,6 +28,22 @@
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0xd0000000 0x100000
 			  MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000>;
 
+		pcie-controller {
+			status = "okay";
+
+			/* Internal mini-PCIe connector */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+
+			/* Connected on the PCB to a USB 3.0 XHCI controller */
+			pcie at 2,0 {
+				/* Port 1, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <200000000>;
@@ -123,22 +139,6 @@
 					reg = <0x25>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/* Internal mini-PCIe connector */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-
-				/* Connected on the PCB to a USB 3.0 XHCI controller */
-				pcie at 2,0 {
-					/* Port 1, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 073dd20..e984ce6 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -44,6 +44,8 @@
 		#size-cells = <1>;
 		controller = <&mbusc>;
 		interrupt-parent = <&mpic>;
+		pcie-mem-aperture = <0xe0000000 0x8000000>;
+		pcie-io-aperture  = <0xe8000000 0x100000>;
 
 		devbus-bootcs {
 			compatible = "marvell,mvebu-devbus";
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index bd21d49..648e530 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -36,6 +36,59 @@
 			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
 		};
 
+		pcie-controller {
+			compatible = "marvell,armada-370-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0       1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0       1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0     MBUS_ID(0x08, 0xe8) 0       1 0 /* Port 1.0 MEM */
+				0x81000000 0x2 0     MBUS_ID(0x08, 0xe0) 0       1 0 /* Port 1.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+                                ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+                                          0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+                                ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+                                          0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 62>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 9>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			system-controller at 18200 {
 				compatible = "marvell,armada-370-xp-system-controller";
@@ -174,54 +227,6 @@
 					0x18304 0x4>;
 				status = "okay";
 			};
-
-			pcie-controller {
-				compatible = "marvell,armada-370-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 62>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 9>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index 76ae1a9..bcf6d79 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -62,6 +62,39 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+
+			/*
+			 * All 6 slots are physically present as
+			 * standard PCIe slots on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+			pcie at 2,0 {
+				/* Port 0, Lane 1 */
+				status = "okay";
+			};
+			pcie at 3,0 {
+				/* Port 0, Lane 2 */
+				status = "okay";
+			};
+			pcie at 4,0 {
+				/* Port 0, Lane 3 */
+				status = "okay";
+			};
+			pcie at 9,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+			pcie at 10,0 {
+				/* Port 3, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -155,40 +188,6 @@
 					spi-max-frequency = <20000000>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/*
-				 * All 6 slots are physically present as
-				 * standard PCIe slots on the board.
-				 */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-				pcie at 2,0 {
-					/* Port 0, Lane 1 */
-					status = "okay";
-				};
-				pcie at 3,0 {
-					/* Port 0, Lane 2 */
-					status = "okay";
-				};
-				pcie at 4,0 {
-					/* Port 0, Lane 3 */
-					status = "okay";
-				};
-				pcie at 9,0 {
-					/* Port 2, Lane 0 */
-					status = "okay";
-				};
-				pcie at 10,0 {
-					/* Port 3, Lane 0 */
-					status = "okay";
-				};
-			};
-
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 8c0de20..2298e4a 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -71,6 +71,27 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+
+			/*
+			 * The 3 slots are physically present as
+			 * standard PCIe slots on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+			pcie at 9,0 {
+				/* Port 2, Lane 0 */
+				status = "okay";
+			};
+			pcie at 10,0 {
+				/* Port 3, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -154,27 +175,6 @@
 					spi-max-frequency = <108000000>;
 				};
 			};
-
-			pcie-controller {
-				status = "okay";
-
-				/*
-				 * The 3 slots are physically present as
-				 * standard PCIe slots on the board.
-				 */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-				pcie at 9,0 {
-					/* Port 2, Lane 0 */
-					status = "okay";
-				};
-				pcie at 10,0 {
-					/* Port 3, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f8eaa38..f093e39 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -44,6 +44,124 @@
 	};
 
 	soc {
+		/*
+		 * MV78230 has 2 PCIe units Gen2.0: One unit can be
+		 * configured as x4 or quad x1 lanes. One unit is
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000000 0x1 0       MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0       MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0       MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+				0x81000000 0x2 0       MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+				0x82000000 0x3 0       MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+				0x81000000 0x3 0       MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+				0x82000000 0x4 0       MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+				0x81000000 0x4 0       MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+				0x82000000 0x9 0       MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
+				0x81000000 0x9 0       MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+					  0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+					  0x81000000 0 0 0x81000000 0x3 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+					  0x81000000 0 0 0x81000000 0x4 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+					  0x81000000 0 0 0x81000000 0x9 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78230-pinctrl";
@@ -77,110 +195,6 @@
 				#interrupts-cells = <2>;
 				interrupts = <87>, <88>, <89>;
 			};
-
-			/*
-			 * MV78230 has 2 PCIe units Gen2.0: One unit can be
-			 * configured as x4 or quad x1 lanes. One unit is
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-#address-cells = <3>;
-#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 985373a..6dc3921 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -45,6 +45,145 @@
 	};
 
 	soc {
+		/*
+		 * MV78260 has 3 PCIe units Gen2.0: Two units can be
+		 * configured as x4 or quad x1 lanes. One unit is
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000   /* Port 1.0 registers */
+				0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000   /* Port 3.0 registers */
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+				0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+				0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+				0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+				0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+				0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+				0x82000000 0x9 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
+				0x81000000 0x9 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
+				0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
+				0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+                                ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+                                          0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+					  0x81000000 0 0 0x81000000 0x3 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+					  0x81000000 0 0 0x81000000 0x4 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+					  0x81000000 0 0 0x81000000 0x9 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+
+			pcie at 10,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x82000 0 0x2000>;
+				reg = <0x5000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
+					  0x81000000 0 0 0x81000000 0xa 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 103>;
+				marvell,pcie-port = <3>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 27>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78260-pinctrl";
@@ -97,128 +236,6 @@
 				clocks = <&gateclk 1>;
 				status = "disabled";
 			};
-
-			/*
-			 * MV78260 has 3 PCIe units Gen2.0: Two units can be
-			 * configured as x4 or quad x1 lanes. One unit is
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-
-				pcie at 10,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x82000 0 0x2000>;
-					reg = <0x5000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 103>;
-					marvell,pcie-port = <3>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 27>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index f8bf25a..a6661e3 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -61,6 +61,227 @@
 	};
 
 	soc {
+		/*
+		 * MV78460 has 4 PCIe units Gen2.0: Two units can be
+		 * configured as x4 or quad x1 lanes. Two units are
+		 * x4/x1.
+		 */
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000   /* Port 1.0 registers */
+				0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000   /* Port 3.0 registers */
+				0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000   /* Port 1.1 registers */
+				0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000   /* Port 1.2 registers */
+				0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000   /* Port 1.3 registers */
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+				0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+				0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+				0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+				0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+				0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+
+				0x82000000 0x5 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
+				0x81000000 0x5 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
+				0x82000000 0x6 0     MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */
+				0x81000000 0x6 0     MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO  */
+				0x82000000 0x7 0     MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */
+				0x81000000 0x7 0     MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO  */
+				0x82000000 0x8 0     MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */
+				0x81000000 0x8 0     MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO  */
+
+				0x82000000 0x9 0     MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
+				0x81000000 0x9 0     MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */
+
+				0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
+				0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 58>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 5>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+					  0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 59>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 6>;
+				status = "disabled";
+			};
+
+			pcie at 3,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
+				reg = <0x1800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+					  0x81000000 0 0 0x81000000 0x3 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 60>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 7>;
+				status = "disabled";
+			};
+
+			pcie at 4,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
+				reg = <0x2000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+					  0x81000000 0 0 0x81000000 0x4 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 61>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 8>;
+				status = "disabled";
+			};
+
+			pcie at 5,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
+				reg = <0x2800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
+					  0x81000000 0 0 0x81000000 0x5 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 62>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 9>;
+				status = "disabled";
+			};
+
+			pcie at 6,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
+				reg = <0x3000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0
+					  0x81000000 0 0 0x81000000 0x6 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 63>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <1>;
+				clocks = <&gateclk 10>;
+				status = "disabled";
+			};
+
+			pcie at 7,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
+				reg = <0x3800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0
+					  0x81000000 0 0 0x81000000 0x7 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 64>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <2>;
+				clocks = <&gateclk 11>;
+				status = "disabled";
+			};
+
+			pcie at 8,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
+				reg = <0x4000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0
+					  0x81000000 0 0 0x81000000 0x8 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 65>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <3>;
+				clocks = <&gateclk 12>;
+				status = "disabled";
+			};
+
+			pcie at 9,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
+				reg = <0x4800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+					  0x81000000 0 0 0x81000000 0x9 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 99>;
+				marvell,pcie-port = <2>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+
+			pcie at 10,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
+				reg = <0x5000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
+					  0x81000000 0 0 0x81000000 0xa 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &mpic 103>;
+				marvell,pcie-port = <3>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gateclk 27>;
+				status = "disabled";
+			};
+		};
+
 		internal-regs {
 			pinctrl {
 				compatible = "marvell,mv78460-pinctrl";
@@ -113,194 +334,6 @@
 				clocks = <&gateclk 1>;
 				status = "disabled";
 			};
-
-			/*
-			 * MV78460 has 4 PCIe units Gen2.0: Two units can be
-			 * configured as x4 or quad x1 lanes. Two units are
-			 * x4/x1.
-			 */
-			pcie-controller {
-				compatible = "marvell,armada-xp-pcie";
-				status = "disabled";
-				device_type = "pci";
-
-				#address-cells = <3>;
-				#size-cells = <2>;
-
-				bus-range = <0x00 0xff>;
-
-				ranges = <0x82000000 0 0x40000 0x40000 0 0x00002000   /* Port 0.0 registers */
-					0x82000000 0 0x42000 0x42000 0 0x00002000   /* Port 2.0 registers */
-					0x82000000 0 0x44000 0x44000 0 0x00002000   /* Port 0.1 registers */
-					0x82000000 0 0x48000 0x48000 0 0x00002000   /* Port 0.2 registers */
-					0x82000000 0 0x4c000 0x4c000 0 0x00002000   /* Port 0.3 registers */
-					0x82000000 0 0x80000 0x80000 0 0x00002000   /* Port 1.0 registers */
-					0x82000000 0 0x82000 0x82000 0 0x00002000   /* Port 3.0 registers */
-					0x82000000 0 0x84000 0x84000 0 0x00002000   /* Port 1.1 registers */
-					0x82000000 0 0x88000 0x88000 0 0x00002000   /* Port 1.2 registers */
-					0x82000000 0 0x8c000 0x8c000 0 0x00002000   /* Port 1.3 registers */
-					0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-					0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
-
-				pcie at 1,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
-					reg = <0x0800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 58>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 5>;
-					status = "disabled";
-				};
-
-				pcie at 2,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
-					reg = <0x1000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 59>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 6>;
-					status = "disabled";
-				};
-
-				pcie at 3,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
-					reg = <0x1800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 60>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 7>;
-					status = "disabled";
-				};
-
-				pcie at 4,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
-					reg = <0x2000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 61>;
-					marvell,pcie-port = <0>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 8>;
-					status = "disabled";
-				};
-
-				pcie at 5,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
-					reg = <0x2800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 62>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 9>;
-					status = "disabled";
-				};
-
-				pcie at 6,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
-					reg = <0x3000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 63>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <1>;
-					clocks = <&gateclk 10>;
-					status = "disabled";
-				};
-
-				pcie at 7,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
-					reg = <0x3800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 64>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <2>;
-					clocks = <&gateclk 11>;
-					status = "disabled";
-				};
-
-				pcie at 8,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
-					reg = <0x4000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 65>;
-					marvell,pcie-port = <1>;
-					marvell,pcie-lane = <3>;
-					clocks = <&gateclk 12>;
-					status = "disabled";
-				};
-				pcie at 9,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
-					reg = <0x4800 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 99>;
-					marvell,pcie-port = <2>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 26>;
-					status = "disabled";
-				};
-
-				pcie at 10,0 {
-					device_type = "pci";
-					assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
-					reg = <0x5000 0 0 0 0>;
-					#address-cells = <3>;
-					#size-cells = <2>;
-					#interrupt-cells = <1>;
-					ranges;
-					interrupt-map-mask = <0 0 0 0>;
-					interrupt-map = <0 0 0 0 &mpic 103>;
-					marvell,pcie-port = <3>;
-					marvell,pcie-lane = <0>;
-					clocks = <&gateclk 27>;
-					status = "disabled";
-				};
-			};
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 2b60ee0..5695afc 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -59,6 +59,15 @@
 			};
 		};
 
+		pcie-controller {
+			status = "okay";
+			/* Internal mini-PCIe connector */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+		};
+
 		internal-regs {
 			serial at 12000 {
 				clock-frequency = <250000000>;
@@ -176,15 +185,6 @@
 			usb at 51000 {
 				status = "okay";
 			};
-
-			pcie-controller {
-				status = "okay";
-				/* Internal mini-PCIe connector */
-				pcie at 1,0 {
-					/* Port 0, Lane 0 */
-					status = "okay";
-				};
-			};
 		};
 	};
 };
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:18:04 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:18:04 -0300
Subject: [PATCH v9 27/30] ARM: kirkwood: Introduce MBUS_ID
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-28-git-send-email-ezequiel.garcia@free-electrons.com>

This macro is used to define window's target ID and attribute cells
for the MBus ranges entries.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/boot/dts/kirkwood.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 83d53b3..5003c83 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -1,5 +1,7 @@
 /include/ "skeleton.dtsi"
 
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
 / {
 	compatible = "marvell,kirkwood";
 	interrupt-parent = <&intc>;
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:18:05 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:18:05 -0300
Subject: [PATCH v9 28/30] ARM: kirkwood: Relocate PCIe device tree nodes
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-29-git-send-email-ezequiel.garcia@free-electrons.com>

Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of the ocp node, placing it directly
below the mbus. This is a more accurate representation of the hardware.

Moving the PCIe nodes, we now need to introduce an extra cell to
encode the window target ID and attribute. Since this depends on
the PCIe port, we split the ranges translation entries, to
correspond to each MBus window.

In addition, we encode the PCIe memory and I/O apertures in the MBus
node, according to the MBus DT binding specification. The choice made
is 0xe0000000-0xf0000000 for memory space, and 0xf200000-0xf2100000 for
I/O space. These apertures can be changed in each per-board DT file.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/boot/dts/kirkwood-6281.dtsi               |  66 ++++++-------
 arch/arm/boot/dts/kirkwood-6282.dtsi               | 102 +++++++++++----------
 arch/arm/boot/dts/kirkwood-db-88f6281.dts          |   3 +-
 arch/arm/boot/dts/kirkwood-db-88f6282.dts          |   3 +-
 arch/arm/boot/dts/kirkwood-db.dtsi                 |   8 --
 arch/arm/boot/dts/kirkwood-iconnect.dts            |  19 ++--
 arch/arm/boot/dts/kirkwood-mplcec4.dts             |  19 ++--
 .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts  |  19 ++--
 arch/arm/boot/dts/kirkwood-nsa310.dts              |  19 ++--
 arch/arm/boot/dts/kirkwood-ts219-6282.dts          |  19 ++--
 arch/arm/boot/dts/kirkwood-ts219.dtsi              |  17 ++--
 arch/arm/boot/dts/kirkwood.dtsi                    |   5 +-
 12 files changed, 163 insertions(+), 136 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-6281.dtsi b/arch/arm/boot/dts/kirkwood-6281.dtsi
index 1e5bef0..650ef30 100644
--- a/arch/arm/boot/dts/kirkwood-6281.dtsi
+++ b/arch/arm/boot/dts/kirkwood-6281.dtsi
@@ -1,4 +1,39 @@
 / {
+	mbus {
+		pcie-controller {
+			compatible = "marvell,kirkwood-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0       1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0       1 0 /* Port 0.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &intc 9>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gate_clk 2>;
+				status = "disabled";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		pinctrl: pinctrl at 10000 {
 			compatible = "marvell,88f6281-pinctrl";
@@ -41,37 +76,6 @@
 			};
 		};
 
-		pcie-controller {
-			compatible = "marvell,kirkwood-pcie";
-			status = "disabled";
-			device_type = "pci";
-
-			#address-cells = <3>;
-			#size-cells = <2>;
-
-			bus-range = <0x00 0xff>;
-
-			ranges = <0x82000000 0 0x00040000 0x00040000 0 0x00002000   /* Port 0.0 registers */
-				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-			          0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
-
-			pcie at 1,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
-				reg = <0x0800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &intc 9>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gate_clk 2>;
-				status = "disabled";
-			};
-		};
-
 		rtc at 10300 {
 			compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc";
 			reg = <0x10300 0x20>;
diff --git a/arch/arm/boot/dts/kirkwood-6282.dtsi b/arch/arm/boot/dts/kirkwood-6282.dtsi
index a63a111..3933a33 100644
--- a/arch/arm/boot/dts/kirkwood-6282.dtsi
+++ b/arch/arm/boot/dts/kirkwood-6282.dtsi
@@ -1,4 +1,59 @@
 / {
+	mbus {
+		pcie-controller {
+			compatible = "marvell,kirkwood-pcie";
+			status = "disabled";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			bus-range = <0x00 0xff>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000
+			        0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000
+				0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000
+				0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0       1 0 /* Port 0.0 MEM */
+				0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0       1 0 /* Port 0.0 IO  */
+				0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0       1 0 /* Port 1.0 MEM */
+				0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0       1 0 /* Port 1.0 IO  */>;
+
+			pcie at 1,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
+				reg = <0x0800 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+					  0x81000000 0 0 0x81000000 0x1 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &intc 9>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gate_clk 2>;
+				status = "disabled";
+			};
+
+			pcie at 2,0 {
+				device_type = "pci";
+				assigned-addresses = <0x82001000 0 0x00044000 0 0x2000>;
+				reg = <0x1000 0 0 0 0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				#interrupt-cells = <1>;
+				ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+					  0x81000000 0 0 0x81000000 0x2 0 1 0>;
+				interrupt-map-mask = <0 0 0 0>;
+				interrupt-map = <0 0 0 0 &intc 10>;
+				marvell,pcie-port = <1>;
+				marvell,pcie-lane = <0>;
+				clocks = <&gate_clk 18>;
+				status = "disabled";
+			};
+		};
+	};
 	ocp at f1000000 {
 
 		pinctrl: pinctrl at 10000 {
@@ -94,52 +149,5 @@
 			status = "disabled";
 		};
 
-		pcie-controller {
-			compatible = "marvell,kirkwood-pcie";
-			status = "disabled";
-			device_type = "pci";
-
-			#address-cells = <3>;
-			#size-cells = <2>;
-
-			bus-range = <0x00 0xff>;
-
-			ranges = <0x82000000 0 0x00040000 0x00040000 0 0x00002000   /* Port 0.0 registers */
-			          0x82000000 0 0x00044000 0x00044000 0 0x00002000   /* Port 1.0 registers */
-				  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-			          0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
-
-			pcie at 1,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82000800 0 0x00040000 0 0x2000>;
-				reg = <0x0800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &intc 9>;
-				marvell,pcie-port = <0>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gate_clk 2>;
-				status = "disabled";
-			};
-
-			pcie at 2,0 {
-				device_type = "pci";
-				assigned-addresses = <0x82001000 0 0x00044000 0 0x2000>;
-				reg = <0x1000 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
-				#interrupt-cells = <1>;
-				ranges;
-				interrupt-map-mask = <0 0 0 0>;
-				interrupt-map = <0 0 0 0 &intc 10>;
-				marvell,pcie-port = <1>;
-				marvell,pcie-lane = <0>;
-				clocks = <&gate_clk 18>;
-				status = "disabled";
-			};
-		};
 	};
 };
diff --git a/arch/arm/boot/dts/kirkwood-db-88f6281.dts b/arch/arm/boot/dts/kirkwood-db-88f6281.dts
index f420cbe..72c4b0a 100644
--- a/arch/arm/boot/dts/kirkwood-db-88f6281.dts
+++ b/arch/arm/boot/dts/kirkwood-db-88f6281.dts
@@ -18,7 +18,8 @@
 	model = "Marvell DB-88F6281-BP Development Board";
 	compatible = "marvell,db-88f6281-bp", "marvell,kirkwood-88f6281", "marvell,kirkwood";
 
-	ocp at f1000000 {
+	mbus {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>;
 		pcie-controller {
 			status = "okay";
 
diff --git a/arch/arm/boot/dts/kirkwood-db-88f6282.dts b/arch/arm/boot/dts/kirkwood-db-88f6282.dts
index c5df866..36c411d 100644
--- a/arch/arm/boot/dts/kirkwood-db-88f6282.dts
+++ b/arch/arm/boot/dts/kirkwood-db-88f6282.dts
@@ -18,7 +18,8 @@
 	model = "Marvell DB-88F6282-BP Development Board";
 	compatible = "marvell,db-88f6282-bp", "marvell,kirkwood-88f6282", "marvell,kirkwood";
 
-	ocp at f1000000 {
+	mbus {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>;
 		pcie-controller {
 			status = "okay";
 
diff --git a/arch/arm/boot/dts/kirkwood-db.dtsi b/arch/arm/boot/dts/kirkwood-db.dtsi
index 29bd98e..45c1bf7 100644
--- a/arch/arm/boot/dts/kirkwood-db.dtsi
+++ b/arch/arm/boot/dts/kirkwood-db.dtsi
@@ -77,13 +77,5 @@
 			cd-gpios = <&gpio1 6 0>;
 			status = "okay";
 		};
-
-		pcie-controller {
-			status = "okay";
-
-			pcie at 1,0 {
-				status = "okay";
-			};
-		};
 	};
 };
diff --git a/arch/arm/boot/dts/kirkwood-iconnect.dts b/arch/arm/boot/dts/kirkwood-iconnect.dts
index 1a98487..8314118 100644
--- a/arch/arm/boot/dts/kirkwood-iconnect.dts
+++ b/arch/arm/boot/dts/kirkwood-iconnect.dts
@@ -18,6 +18,17 @@
 		linux,initrd-end   = <0x4800000>;
 	};
 
+	mbus {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>;
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		pinctrl: pinctrl at 10000 {
 			pmx_button_reset: pmx-button-reset {
@@ -101,14 +112,6 @@
 				reg = <0x980000 0x1f400000>;
 			};
 		};
-
-		pcie-controller {
-			status = "okay";
-
-			pcie at 1,0 {
-				status = "okay";
-			};
-		};
 	};
 
 	gpio-leds {
diff --git a/arch/arm/boot/dts/kirkwood-mplcec4.dts b/arch/arm/boot/dts/kirkwood-mplcec4.dts
index 382ad99..21f1954 100644
--- a/arch/arm/boot/dts/kirkwood-mplcec4.dts
+++ b/arch/arm/boot/dts/kirkwood-mplcec4.dts
@@ -16,6 +16,17 @@
                 bootargs = "console=ttyS0,115200n8 earlyprintk";
         };
 
+	mbus {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>;
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		pinctrl: pinctrl at 10000 {
 			pmx_led_health: pmx-led-health {
@@ -134,14 +145,6 @@
 			cd-gpios = <&gpio1 15 1>;
 			/* No WP GPIO */
 		};
-
-		pcie-controller {
-			status = "okay";
-
-			pcie at 1,0 {
-				status = "okay";
-			};
-		};
 	};
 
 	gpio-leds {
diff --git a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
index 8be68bd..84ff31c 100644
--- a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
+++ b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
@@ -16,6 +16,17 @@
 		bootargs = "console=ttyS0,115200n8 earlyprintk";
 	};
 
+	mbus {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>;
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		pinctrl: pinctrl at 10000 {
 			pmx_button_power: pmx-button-power {
@@ -101,14 +112,6 @@
 			status = "okay";
 			nr-ports = <2>;
 		};
-
-		pcie-controller {
-			status = "okay";
-
-			pcie at 1,0 {
-				status = "okay";
-			};
-		};
 	};
 
 	gpio-leds {
diff --git a/arch/arm/boot/dts/kirkwood-nsa310.dts b/arch/arm/boot/dts/kirkwood-nsa310.dts
index 8fd683c..bd7f05f 100644
--- a/arch/arm/boot/dts/kirkwood-nsa310.dts
+++ b/arch/arm/boot/dts/kirkwood-nsa310.dts
@@ -16,6 +16,17 @@
 		bootargs = "console=ttyS0,115200";
 	};
 
+	mbus {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>;
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		pinctrl: pinctrl at 10000 {
 			pinctrl-0 = <&pmx_unknown>;
@@ -162,14 +173,6 @@
 				reg = <0x5040000 0x2fc0000>;
 			};
 		};
-
-		pcie-controller {
-			status = "okay";
-
-			pcie at 1,0 {
-				status = "okay";
-			};
-		};
 	};
 
 	gpio_keys {
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
index 7d6cc86..04f6fe1 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -5,6 +5,17 @@
 #include "kirkwood-ts219.dtsi"
 
 / {
+	mbus {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>;
+		pcie-controller {
+			status = "okay";
+
+			pcie at 2,0 {
+				status = "okay";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		pinctrl: pinctrl at 10000 {
 
@@ -30,14 +41,6 @@
 				marvell,function = "gpio";
 			};
 		};
-		pcie-controller {
-			status = "okay";
-
-			pcie at 2,0 {
-				status = "okay";
-			};
-		};
-
 	};
 
 	gpio_keys {
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
index 0c9a94c..7019cf6 100644
--- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -11,6 +11,16 @@
 		bootargs = "console=ttyS0,115200n8";
 	};
 
+	mbus {
+		pcie-controller {
+			status = "okay";
+
+			pcie at 1,0 {
+				status = "okay";
+			};
+		};
+	};
+
 	ocp at f1000000 {
 		i2c at 11000 {
 			status = "okay";
@@ -87,12 +97,5 @@
 			status = "okay";
 			nr-ports = <2>;
 		};
-		pcie-controller {
-			status = "okay";
-
-			pcie at 1,0 {
-				status = "okay";
-			};
-		};
 	};
 };
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 5003c83..70f414d 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -32,13 +32,16 @@
 
 	mbus {
 		compatible = "marvell,kirkwood-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
 		controller = <&mbusc>;
+		pcie-mem-aperture = <0xe0000000 0x10000000>; /* 256 MiB memory space */
+		pcie-io-aperture  = <0xf2000000 0x100000>;   /*   1 MiB    I/O space */
 	};
 
 	ocp at f1000000 {
 		compatible = "simple-bus";
 		ranges = <0x00000000 0xf1000000 0x0100000
-		          0xe0000000 0xe0000000 0x8100000 /* PCIE */
 		          0xf4000000 0xf4000000 0x0000400
 		          0xf5000000 0xf5000000 0x0000400>;
 		#address-cells = <1>;
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:18:03 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:18:03 -0300
Subject: [PATCH v9 26/30] ARM: kirkwood: Introduce MBus DT node
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-27-git-send-email-ezequiel.garcia@free-electrons.com>

Add a minimal MBus node, just to allow the MBus driver to probe.
Follow-up patches will migrate the rest of the nodes appropriately.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/boot/dts/kirkwood.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 9809fc1..83d53b3 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -28,6 +28,11 @@
 		      <0xf1020214 0x04>;
 	};
 
+	mbus {
+		compatible = "marvell,kirkwood-mbus", "simple-bus";
+		controller = <&mbusc>;
+	};
+
 	ocp at f1000000 {
 		compatible = "simple-bus";
 		ranges = <0x00000000 0xf1000000 0x0100000
@@ -37,6 +42,11 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 
+		mbusc: mbus-controller at 20000 {
+			compatible = "marvell,mbus-controller";
+			reg = <0x20000 0x80>, <0x1500 0x20>;
+		};
+
 		core_clk: core-clocks at 10030 {
 			compatible = "marvell,kirkwood-core-clock";
 			reg = <0x10030 0x4>;
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:18:02 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:18:02 -0300
Subject: [PATCH v9 25/30] ARM: kirkwood: Use the preprocessor on device tree
 files
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-26-git-send-email-ezequiel.garcia@free-electrons.com>

Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 arch/arm/boot/dts/kirkwood-cloudbox.dts                | 4 ++--
 arch/arm/boot/dts/kirkwood-db-88f6281.dts              | 4 ++--
 arch/arm/boot/dts/kirkwood-db-88f6282.dts              | 4 ++--
 arch/arm/boot/dts/kirkwood-db.dtsi                     | 2 +-
 arch/arm/boot/dts/kirkwood-dns320.dts                  | 2 +-
 arch/arm/boot/dts/kirkwood-dns325.dts                  | 2 +-
 arch/arm/boot/dts/kirkwood-dnskw.dtsi                  | 4 ++--
 arch/arm/boot/dts/kirkwood-dockstar.dts                | 4 ++--
 arch/arm/boot/dts/kirkwood-dreamplug.dts               | 4 ++--
 arch/arm/boot/dts/kirkwood-goflexnet.dts               | 4 ++--
 arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts    | 4 ++--
 arch/arm/boot/dts/kirkwood-ib62x0.dts                  | 4 ++--
 arch/arm/boot/dts/kirkwood-iconnect.dts                | 4 ++--
 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts          | 4 ++--
 arch/arm/boot/dts/kirkwood-is2.dts                     | 2 +-
 arch/arm/boot/dts/kirkwood-km_kirkwood.dts             | 4 ++--
 arch/arm/boot/dts/kirkwood-lschlv2.dts                 | 2 +-
 arch/arm/boot/dts/kirkwood-lsxhl.dts                   | 2 +-
 arch/arm/boot/dts/kirkwood-lsxl.dtsi                   | 4 ++--
 arch/arm/boot/dts/kirkwood-mplcec4.dts                 | 4 ++--
 arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts | 4 ++--
 arch/arm/boot/dts/kirkwood-ns2-common.dtsi             | 4 ++--
 arch/arm/boot/dts/kirkwood-ns2.dts                     | 2 +-
 arch/arm/boot/dts/kirkwood-ns2lite.dts                 | 2 +-
 arch/arm/boot/dts/kirkwood-ns2max.dts                  | 2 +-
 arch/arm/boot/dts/kirkwood-ns2mini.dts                 | 2 +-
 arch/arm/boot/dts/kirkwood-nsa310.dts                  | 4 ++--
 arch/arm/boot/dts/kirkwood-openblocks_a6.dts           | 4 ++--
 arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi      | 4 ++--
 arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts        | 2 +-
 arch/arm/boot/dts/kirkwood-sheevaplug.dts              | 2 +-
 arch/arm/boot/dts/kirkwood-topkick.dts                 | 4 ++--
 arch/arm/boot/dts/kirkwood-ts219-6281.dts              | 6 +++---
 arch/arm/boot/dts/kirkwood-ts219-6282.dts              | 6 +++---
 34 files changed, 58 insertions(+), 58 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-cloudbox.dts b/arch/arm/boot/dts/kirkwood-cloudbox.dts
index 00c48d2..9bf139c 100644
--- a/arch/arm/boot/dts/kirkwood-cloudbox.dts
+++ b/arch/arm/boot/dts/kirkwood-cloudbox.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "LaCie CloudBox";
diff --git a/arch/arm/boot/dts/kirkwood-db-88f6281.dts b/arch/arm/boot/dts/kirkwood-db-88f6281.dts
index 9d777ed..f420cbe 100644
--- a/arch/arm/boot/dts/kirkwood-db-88f6281.dts
+++ b/arch/arm/boot/dts/kirkwood-db-88f6281.dts
@@ -11,8 +11,8 @@
 
 /dts-v1/;
 
-/include/ "kirkwood-db.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood-db.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "Marvell DB-88F6281-BP Development Board";
diff --git a/arch/arm/boot/dts/kirkwood-db-88f6282.dts b/arch/arm/boot/dts/kirkwood-db-88f6282.dts
index f4c8528..c5df866 100644
--- a/arch/arm/boot/dts/kirkwood-db-88f6282.dts
+++ b/arch/arm/boot/dts/kirkwood-db-88f6282.dts
@@ -11,8 +11,8 @@
 
 /dts-v1/;
 
-/include/ "kirkwood-db.dtsi"
-/include/ "kirkwood-6282.dtsi"
+#include "kirkwood-db.dtsi"
+#include "kirkwood-6282.dtsi"
 
 / {
 	model = "Marvell DB-88F6282-BP Development Board";
diff --git a/arch/arm/boot/dts/kirkwood-db.dtsi b/arch/arm/boot/dts/kirkwood-db.dtsi
index c87cfb8..29bd98e 100644
--- a/arch/arm/boot/dts/kirkwood-db.dtsi
+++ b/arch/arm/boot/dts/kirkwood-db.dtsi
@@ -12,7 +12,7 @@
  * and 6282 variants of the Marvell Kirkwood Development Board.
  */
 
-/include/ "kirkwood.dtsi"
+#include "kirkwood.dtsi"
 
 / {
 	memory {
diff --git a/arch/arm/boot/dts/kirkwood-dns320.dts b/arch/arm/boot/dts/kirkwood-dns320.dts
index 14d4cee..e112ca6 100644
--- a/arch/arm/boot/dts/kirkwood-dns320.dts
+++ b/arch/arm/boot/dts/kirkwood-dns320.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-dnskw.dtsi"
+#include "kirkwood-dnskw.dtsi"
 
 / {
 	model = "D-Link DNS-320 NAS (Rev A1)";
diff --git a/arch/arm/boot/dts/kirkwood-dns325.dts b/arch/arm/boot/dts/kirkwood-dns325.dts
index 6387257..5119fb8 100644
--- a/arch/arm/boot/dts/kirkwood-dns325.dts
+++ b/arch/arm/boot/dts/kirkwood-dns325.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-dnskw.dtsi"
+#include "kirkwood-dnskw.dtsi"
 
 / {
 	model = "D-Link DNS-325 NAS (Rev A1)";
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 0afe1d0..2e04284 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -1,5 +1,5 @@
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "D-Link DNS NASes (kirkwood-based)";
diff --git a/arch/arm/boot/dts/kirkwood-dockstar.dts b/arch/arm/boot/dts/kirkwood-dockstar.dts
index 7714742..4387ae8 100644
--- a/arch/arm/boot/dts/kirkwood-dockstar.dts
+++ b/arch/arm/boot/dts/kirkwood-dockstar.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "Seagate FreeAgent Dockstar";
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 36c7ba3..c628378 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "Globalscale Technologies Dreamplug";
diff --git a/arch/arm/boot/dts/kirkwood-goflexnet.dts b/arch/arm/boot/dts/kirkwood-goflexnet.dts
index 31caa64..e571180 100644
--- a/arch/arm/boot/dts/kirkwood-goflexnet.dts
+++ b/arch/arm/boot/dts/kirkwood-goflexnet.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "Seagate GoFlex Net";
diff --git a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
index 1e642f3..2c5673a 100644
--- a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
+++ b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "Globalscale Technologies Guruplug Server Plus";
diff --git a/arch/arm/boot/dts/kirkwood-ib62x0.dts b/arch/arm/boot/dts/kirkwood-ib62x0.dts
index 20c4b08..158161f 100644
--- a/arch/arm/boot/dts/kirkwood-ib62x0.dts
+++ b/arch/arm/boot/dts/kirkwood-ib62x0.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "RaidSonic ICY BOX IB-NAS62x0 (Rev B)";
diff --git a/arch/arm/boot/dts/kirkwood-iconnect.dts b/arch/arm/boot/dts/kirkwood-iconnect.dts
index 441204e..1a98487 100644
--- a/arch/arm/boot/dts/kirkwood-iconnect.dts
+++ b/arch/arm/boot/dts/kirkwood-iconnect.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "Iomega Iconnect";
diff --git a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
index 00a7bfe..fd7f053 100644
--- a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
+++ b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "Iomega StorCenter ix2-200";
diff --git a/arch/arm/boot/dts/kirkwood-is2.dts b/arch/arm/boot/dts/kirkwood-is2.dts
index c3f036b..bd88a23 100644
--- a/arch/arm/boot/dts/kirkwood-is2.dts
+++ b/arch/arm/boot/dts/kirkwood-is2.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-ns2-common.dtsi"
+#include "kirkwood-ns2-common.dtsi"
 
 / {
 	model = "LaCie Internet Space v2";
diff --git a/arch/arm/boot/dts/kirkwood-km_kirkwood.dts b/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
index 5d9f5ea..b071d37 100644
--- a/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
+++ b/arch/arm/boot/dts/kirkwood-km_kirkwood.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-98dx4122.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-98dx4122.dtsi"
 
 / {
 	model = "Keymile Kirkwood Reference Design";
diff --git a/arch/arm/boot/dts/kirkwood-lschlv2.dts b/arch/arm/boot/dts/kirkwood-lschlv2.dts
index 9f55d95..e2fa368 100644
--- a/arch/arm/boot/dts/kirkwood-lschlv2.dts
+++ b/arch/arm/boot/dts/kirkwood-lschlv2.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-lsxl.dtsi"
+#include "kirkwood-lsxl.dtsi"
 
 / {
 	model = "Buffalo Linkstation LS-CHLv2";
diff --git a/arch/arm/boot/dts/kirkwood-lsxhl.dts b/arch/arm/boot/dts/kirkwood-lsxhl.dts
index 5c84c11..8d89cdf 100644
--- a/arch/arm/boot/dts/kirkwood-lsxhl.dts
+++ b/arch/arm/boot/dts/kirkwood-lsxhl.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-lsxl.dtsi"
+#include "kirkwood-lsxl.dtsi"
 
 / {
 	model = "Buffalo Linkstation LS-XHL";
diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
index 31b17f5..f7e247c 100644
--- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
+++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
@@ -1,5 +1,5 @@
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	chosen {
diff --git a/arch/arm/boot/dts/kirkwood-mplcec4.dts b/arch/arm/boot/dts/kirkwood-mplcec4.dts
index 6179333..382ad99 100644
--- a/arch/arm/boot/dts/kirkwood-mplcec4.dts
+++ b/arch/arm/boot/dts/kirkwood-mplcec4.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "MPL CEC4";
diff --git a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
index ad6ade7..8be68bd 100644
--- a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
+++ b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6282.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6282.dtsi"
 
 / {
 	model = "NETGEAR ReadyNAS Duo v2";
diff --git a/arch/arm/boot/dts/kirkwood-ns2-common.dtsi b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
index 2afac04..d0fb34d 100644
--- a/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
@@ -1,5 +1,5 @@
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	chosen {
diff --git a/arch/arm/boot/dts/kirkwood-ns2.dts b/arch/arm/boot/dts/kirkwood-ns2.dts
index b50e93d..0599f3c 100644
--- a/arch/arm/boot/dts/kirkwood-ns2.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-ns2-common.dtsi"
+#include "kirkwood-ns2-common.dtsi"
 
 / {
 	model = "LaCie Network Space v2";
diff --git a/arch/arm/boot/dts/kirkwood-ns2lite.dts b/arch/arm/boot/dts/kirkwood-ns2lite.dts
index af8259f..b0e1798 100644
--- a/arch/arm/boot/dts/kirkwood-ns2lite.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2lite.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-ns2-common.dtsi"
+#include "kirkwood-ns2-common.dtsi"
 
 / {
 	model = "LaCie Network Space Lite v2";
diff --git a/arch/arm/boot/dts/kirkwood-ns2max.dts b/arch/arm/boot/dts/kirkwood-ns2max.dts
index 85f24d2..d4f6a58 100644
--- a/arch/arm/boot/dts/kirkwood-ns2max.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2max.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-ns2-common.dtsi"
+#include "kirkwood-ns2-common.dtsi"
 
 / {
 	model = "LaCie Network Space Max v2";
diff --git a/arch/arm/boot/dts/kirkwood-ns2mini.dts b/arch/arm/boot/dts/kirkwood-ns2mini.dts
index 329e530..f30e05a 100644
--- a/arch/arm/boot/dts/kirkwood-ns2mini.dts
+++ b/arch/arm/boot/dts/kirkwood-ns2mini.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "kirkwood-ns2-common.dtsi"
+#include "kirkwood-ns2-common.dtsi"
 
 / {
 	/* This machine is embedded in the first LaCie CloudBox product. */
diff --git a/arch/arm/boot/dts/kirkwood-nsa310.dts b/arch/arm/boot/dts/kirkwood-nsa310.dts
index 6900359..8fd683c 100644
--- a/arch/arm/boot/dts/kirkwood-nsa310.dts
+++ b/arch/arm/boot/dts/kirkwood-nsa310.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	model = "ZyXEL NSA310";
diff --git a/arch/arm/boot/dts/kirkwood-openblocks_a6.dts b/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
index 38dc851..365b792 100644
--- a/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
+++ b/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6282.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6282.dtsi"
 
 / {
 	model = "Plat'Home OpenBlocksA6";
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
index f7143f1..0cc5f26 100644
--- a/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug-common.dtsi
@@ -6,8 +6,8 @@
  * Licensed under GPLv2
  */
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
 
 / {
 	memory {
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts b/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
index f620ce4..eac6a21 100644
--- a/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug-esata.dts
@@ -8,7 +8,7 @@
 
 /dts-v1/;
 
-/include/ "kirkwood-sheevaplug-common.dtsi"
+#include "kirkwood-sheevaplug-common.dtsi"
 
 / {
 	model = "Globalscale Technologies eSATA SheevaPlug";
diff --git a/arch/arm/boot/dts/kirkwood-sheevaplug.dts b/arch/arm/boot/dts/kirkwood-sheevaplug.dts
index bf1dff2..bb61918 100644
--- a/arch/arm/boot/dts/kirkwood-sheevaplug.dts
+++ b/arch/arm/boot/dts/kirkwood-sheevaplug.dts
@@ -8,7 +8,7 @@
 
 /dts-v1/;
 
-/include/ "kirkwood-sheevaplug-common.dtsi"
+#include "kirkwood-sheevaplug-common.dtsi"
 
 / {
 	model = "Globalscale Technologies SheevaPlug";
diff --git a/arch/arm/boot/dts/kirkwood-topkick.dts b/arch/arm/boot/dts/kirkwood-topkick.dts
index f2052d7..974f1e0 100644
--- a/arch/arm/boot/dts/kirkwood-topkick.dts
+++ b/arch/arm/boot/dts/kirkwood-topkick.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6282.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6282.dtsi"
 
 / {
 	model = "Univeral Scientific Industrial Co. Topkick-1281P2";
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6281.dts b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
index 6dd1038..3867ae3 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6281.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
@@ -1,8 +1,8 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6281.dtsi"
-/include/ "kirkwood-ts219.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
+#include "kirkwood-ts219.dtsi"
 
 / {
 	ocp at f1000000 {
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
index 6fdc5ff..7d6cc86 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -1,8 +1,8 @@
 /dts-v1/;
 
-/include/ "kirkwood.dtsi"
-/include/ "kirkwood-6282.dtsi"
-/include/ "kirkwood-ts219.dtsi"
+#include "kirkwood.dtsi"
+#include "kirkwood-6282.dtsi"
+#include "kirkwood-ts219.dtsi"
 
 / {
 	ocp at f1000000 {
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:18:06 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:18:06 -0300
Subject: [PATCH v9 29/30] bus: mvebu-mbus: Add devicetree binding
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-30-git-send-email-ezequiel.garcia@free-electrons.com>

Introduce the devicetree binding for the mvebu MBus driver
avaiable in the mvebu SoCs (Armada 370/XP, Kirkwood, Dove, ...).

This binding provides an accurate model of the SoC address space,
and allows to declare the address and size of the decoding windows the MBus
needs to access the peripherals, together with the target ID and attribute
for those windows.

The binding is composed of two required nodes: one for the MBus bus
and one for the MBus controller.

Cc: devicetree at vger.kernel.org
Signed-off-by: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 .../devicetree/bindings/bus/mvebu-mbus.txt         | 276 +++++++++++++++++++++
 1 file changed, 276 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt

diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
new file mode 100644
index 0000000..7586fb6
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -0,0 +1,276 @@
+
+* Marvell MBus
+
+Required properties:
+
+- compatible:	 Should be set to one of the following:
+		 marvell,armada370-mbus
+		 marvell,armadaxp-mbus
+		 marvell,armada370-mbus
+		 marvell,armadaxp-mbus
+		 marvell,kirkwood-mbus
+		 marvell,dove-mbus
+		 marvell,orion5x-88f5281-mbus
+		 marvell,orion5x-88f5182-mbus
+		 marvell,orion5x-88f5181-mbus
+		 marvell,orion5x-88f6183-mbus
+		 marvell,mv78xx0-mbus
+
+- address-cells: Must be '2'. The first cell for the MBus ID encoding,
+                 the second cell for the address offset within the window.
+
+- size-cells:    Must be '1'.
+
+- ranges:        Must be set up to provide a proper translation for each child.
+	         See the examples below.
+
+- controller:    Contains a single phandle referring to the MBus controller
+                 node. This allows to specify the node that contains the
+		 registers that control the MBus, which is typically contained
+		 within the internal register window (see below).
+
+Optional properties:
+
+- pcie-mem-aperture:	This optional property contains the aperture for
+			the memory region of the PCIe driver.
+			If it's defined, it must encode the base address and
+			size for the address decoding windows allocated for
+			the PCIe memory region.
+
+- pcie-io-aperture:	Just as explained for the above property, this
+			optional property contains the aperture for the
+			I/O region of the PCIe driver.
+
+* Marvell MBus controller
+
+Required properties:
+
+- compatible:	Should be set to "marvell,mbus-controller".
+
+- reg:          Device's register space.
+		Two entries are expected (see the examples below):
+		the first one controls the devices decoding window and
+		the second one controls the SDRAM decoding window.
+
+Example:
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+		pcie-mem-aperture = <0xe0000000 0x8000000>;
+		pcie-io-aperture  = <0xe8000000 0x100000>;
+
+		internal-regs {
+			compatible = "simple-bus";
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* more children ...*/
+		};
+	};
+
+** MBus address decoding window specification
+
+The MBus children address space is comprised of two cells: the first one for
+the window ID and the second one for the offset within the window.
+In order to allow to describe valid and non-valid window entries, the
+following encoding is used:
+
+  0xSIAA0000 0x00oooooo
+
+Where:
+
+  S = 0x0 for a MBus valid window
+  S = 0xf for a non-valid window (see below)
+
+If S = 0x0, then:
+
+   I = 4-bit window target ID
+  AA = windpw attribute
+
+If S = 0xf, then:
+
+   I = don't care
+   AA = 1 for internal register
+
+Following the above encoding, for each ranges entry for a MBus valid window
+(S = 0x0), an address decoding window is allocated. On the other side,
+entries for translation that do not correspond to valid windows (S = 0xf)
+are skipped.
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+
+		ranges = <0xf0010000 0 0 0xd0000000 0x100000
+			  0x01e00000 0 0 0xfff00000 0x100000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <0x01e00000 0 0x100000>;
+		};
+
+		/* other children */
+		...
+
+		internal-regs {
+			compatible = "simple-bus";
+			ranges = <0 0xf0010000 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* more children ...*/
+		};
+	};
+
+In the shown example, the translation entry in the 'ranges' property is what
+makes the MBus driver create a static decoding window for the corresponding
+given child device. Note that the binding does not require child nodes to be
+present. Of course, child nodes are needed to probe the devices.
+
+Since each window is identified by its target ID and attribute ID there's
+a special macro that can be use to simplify the translation entries:
+
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
+Using this macro, the above example would be:
+
+	soc {
+		compatible = "marvell,armada370-mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		controller = <&mbusc>;
+
+		ranges = < MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+			   MBUS_ID(0x01, 0xe0) 0 0 0xfff00000 0x100000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
+		};
+
+		/* other children */
+		...
+
+		internal-regs {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			/* other children */
+			...
+		};
+	};
+
+
+** About the window base address
+
+Remember the MBus controller allows a great deal of flexibility for choosing
+the decoding window base address. When planning the device tree layout it's
+possible to choose any address as the base address, provided of course there's
+a region large enough available, and with the required alignment.
+
+Yet in other words: there's nothing preventing us from setting a base address
+of 0xf0000000, or 0xd0000000 for the NOR device shown above, if such region is
+unused.
+
+** Window allocation policy
+
+The mbus-node ranges property defines a set of mbus windows that are expected
+to be set by the operating system and that are guaranteed to be free of overlaps
+with one another or with the system memory ranges.
+
+Each entry in the property refers to exactly one window. If the operating system
+choses to use a different set of mbus windows, it must ensure that any address
+translations performed from downstream devices are adapted accordingly.
+
+The operating system may insert additional mbus windows that do not conflict
+with the ones listed in the ranges, e.g. for mapping PCIe devices.
+As a special case, the internal register window must be set up by the boot
+loader at the address listed in the ranges property, since access to that region
+is needed to set up the other windows.
+
+** Example
+
+See the example below, where a more complete device tree is shown:
+
+	soc {
+		compatible = "marvell,armadaxp-mbus", "simple-bus";
+		controller = <&mbusc>;
+
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
+			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
+			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
+
+		bootrom {
+			compatible = "marvell,bootrom";
+			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
+		};
+
+		devbus-bootcs {
+			status = "okay";
+			ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;
+
+			/* NOR */
+			nor {
+				compatible = "cfi-flash";
+				reg = <0 0x8000000>;
+				bank-width = <2>;
+			};
+		};
+
+		pcie-controller {
+			compatible = "marvell,armada-xp-pcie";
+			status = "okay";
+			device_type = "pci";
+
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			ranges =
+			       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
+				0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
+				0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
+				0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
+				0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
+				0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
+				0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>;
+
+
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+		};
+
+		internal-regs {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+
+			mbusc: mbus-controller at 20000 {
+				reg = <0x20000 0x100>, <0x20180 0x20>;
+			};
+
+			interrupt-controller at 20000 {
+			      reg = <0x20a00 0x2d0>, <0x21070 0x58>;
+			};
+		};
+	};
-- 
1.8.1.5



From ezequiel.garcia at free-electrons.com  Fri Jul 26 09:18:07 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Fri, 26 Jul 2013 10:18:07 -0300
Subject: [PATCH v9 30/30] PCI: mvebu: Adapt to the new device tree layout
In-Reply-To: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <1374844687-19981-31-git-send-email-ezequiel.garcia@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

The new device tree layout encodes the window's target ID and attribute
in the PCIe controller node's ranges property. This allows to parse
such entries to obtain such information and use the recently introduced
MBus API to create the windows, instead of using the current name based
scheme.

Cc: devicetree at vger.kernel.org
Acked-by: Bjorn Helgaas <bhelgaas at google.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Tested-by: Andrew Lunn <andrew at lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
 .../devicetree/bindings/pci/mvebu-pci.txt          | 145 ++++++++++++++++-----
 1 file changed, 109 insertions(+), 36 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index f8d4058..9556e2f 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -1,6 +1,7 @@
 * Marvell EBU PCIe interfaces
 
 Mandatory properties:
+
 - compatible: one of the following values:
     marvell,armada-370-pcie
     marvell,armada-xp-pcie
@@ -10,11 +11,49 @@ Mandatory properties:
 - #interrupt-cells, set to <1>
 - bus-range: PCI bus numbers covered
 - device_type, set to "pci"
-- ranges: ranges for the PCI memory and I/O regions, as well as the
-  MMIO registers to control the PCIe interfaces.
+- ranges: ranges describing the MMIO registers to control the PCIe
+  interfaces, and ranges describing the MBus windows needed to access
+  the memory and I/O regions of each PCIe interface.
+
+The ranges describing the MMIO registers have the following layout:
+
+    0x82000000 0 r MBUS_ID(0xf0, 0x01) r 0 s
+
+where:
+
+  * r is a 32-bits value that gives the offset of the MMIO
+  registers of this PCIe interface, from the base of the internal
+  registers.
+
+  * s is a 32-bits value that give the size of this MMIO
+  registers area. This range entry translates the '0x82000000 0 r' PCI
+  address into the 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part
+  of the internal register window (as identified by MBUS_ID(0xf0,
+  0x01)).
+
+The ranges describing the MBus windows have the following layout:
+
+    0x8t000000 s 0     MBUS_ID(w, a) 0 1 0
+
+where:
+
+   * t is the type of the MBus window (as defined by the standard PCI DT
+   bindings), 1 for I/O and 2 for memory.
 
-In addition, the Device Tree node must have sub-nodes describing each
+   * s is the PCI slot that corresponds to this PCIe interface
+
+   * w is the 'target ID' value for the MBus window
+
+   * a the 'attribute' value for the MBus window.
+
+Since the location and size of the different MBus windows is not fixed in
+hardware, and only determined in runtime, those ranges cover the full first
+4 GB of the physical address space, and do not translate into a valid CPU
+address.
+
+In addition, the device tree node must have sub-nodes describing each
 PCIe interface, having the following mandatory properties:
+
 - reg: used only for interrupt mapping, so only the first four bytes
   are used to refer to the correct bus number and device number.
 - assigned-addresses: reference to the MMIO registers used to control
@@ -26,7 +65,8 @@ PCIe interface, having the following mandatory properties:
 - #address-cells, set to <3>
 - #size-cells, set to <2>
 - #interrupt-cells, set to <1>
-- ranges, empty property.
+- ranges, translating the MBus windows ranges of the parent node into
+  standard PCI addresses.
 - interrupt-map-mask and interrupt-map, standard PCI properties to
   define the mapping of the PCIe interface to interrupt numbers.
 
@@ -47,27 +87,50 @@ pcie-controller {
 
 	bus-range = <0x00 0xff>;
 
-	ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
-		  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
-		  0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
-		  0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
-		  0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
-		  0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
-		  0x82000000 0 0xd0082000 0xd0082000 0 0x00002000   /* Port 3.0 registers */
-		  0x82000000 0 0xd0084000 0xd0084000 0 0x00002000   /* Port 1.1 registers */
-		  0x82000000 0 0xd0088000 0xd0088000 0 0x00002000   /* Port 1.2 registers */
-		  0x82000000 0 0xd008c000 0xd008c000 0 0x00002000   /* Port 1.3 registers */
-		  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
-		  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
+	ranges =
+	       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000	/* Port 0.0 registers */
+		0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000	/* Port 2.0 registers */
+		0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000	/* Port 0.1 registers */
+		0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000	/* Port 0.2 registers */
+		0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000	/* Port 0.3 registers */
+		0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000	/* Port 1.0 registers */
+		0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000	/* Port 3.0 registers */
+		0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000	/* Port 1.1 registers */
+		0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000	/* Port 1.2 registers */
+		0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000	/* Port 1.3 registers */
+		0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+		0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
+		0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+		0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
+		0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
+		0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
+		0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+		0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
+
+		0x82000000 0x5 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
+		0x81000000 0x5 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
+		0x82000000 0x6 0     MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */
+		0x81000000 0x6 0     MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO  */
+		0x82000000 0x7 0     MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */
+		0x81000000 0x7 0     MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO  */
+		0x82000000 0x8 0     MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */
+		0x81000000 0x8 0     MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO  */
+
+		0x82000000 0x9 0     MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
+		0x81000000 0x9 0     MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */
+
+		0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
+		0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
 
 	pcie at 1,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+		assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
 		reg = <0x0800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+			  0x81000000 0 0 0x81000000 0x1 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 58>;
 		marvell,pcie-port = <0>;
@@ -78,12 +141,13 @@ pcie-controller {
 
 	pcie at 2,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>;
+		assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
 		reg = <0x1000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+			  0x81000000 0 0 0x81000000 0x2 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 59>;
 		marvell,pcie-port = <0>;
@@ -94,12 +158,13 @@ pcie-controller {
 
 	pcie at 3,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>;
+		assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
 		reg = <0x1800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
+			  0x81000000 0 0 0x81000000 0x3 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 60>;
 		marvell,pcie-port = <0>;
@@ -110,12 +175,13 @@ pcie-controller {
 
 	pcie at 4,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>;
+		assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
 		reg = <0x2000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
+			  0x81000000 0 0 0x81000000 0x4 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 61>;
 		marvell,pcie-port = <0>;
@@ -126,12 +192,13 @@ pcie-controller {
 
 	pcie at 5,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
+		assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
 		reg = <0x2800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
+			  0x81000000 0 0 0x81000000 0x5 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 62>;
 		marvell,pcie-port = <1>;
@@ -142,12 +209,13 @@ pcie-controller {
 
 	pcie at 6,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>;
+		assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
 		reg = <0x3000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0
+			  0x81000000 0 0 0x81000000 0x6 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 63>;
 		marvell,pcie-port = <1>;
@@ -158,12 +226,13 @@ pcie-controller {
 
 	pcie at 7,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>;
+		assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
 		reg = <0x3800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0
+			  0x81000000 0 0 0x81000000 0x7 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 64>;
 		marvell,pcie-port = <1>;
@@ -174,12 +243,13 @@ pcie-controller {
 
 	pcie at 8,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>;
+		assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
 		reg = <0x4000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0
+			  0x81000000 0 0 0x81000000 0x8 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 65>;
 		marvell,pcie-port = <1>;
@@ -187,14 +257,16 @@ pcie-controller {
 		clocks = <&gateclk 12>;
 		status = "disabled";
 	};
+
 	pcie at 9,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>;
+		assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
 		reg = <0x4800 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+			  0x81000000 0 0 0x81000000 0x9 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 99>;
 		marvell,pcie-port = <2>;
@@ -205,12 +277,13 @@ pcie-controller {
 
 	pcie at 10,0 {
 		device_type = "pci";
-		assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>;
+		assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
 		reg = <0x5000 0 0 0 0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
-		ranges;
+		ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
+			  0x81000000 0 0 0x81000000 0xa 0 1 0>;
 		interrupt-map-mask = <0 0 0 0>;
 		interrupt-map = <0 0 0 0 &mpic 103>;
 		marvell,pcie-port = <3>;
-- 
1.8.1.5



From zhangfei.gao at linaro.org  Fri Jul 26 09:22:16 2013
From: zhangfei.gao at linaro.org (Zhangfei Gao)
Date: Fri, 26 Jul 2013 21:22:16 +0800
Subject: [PATCH v4 0/2] support hisilicon i2c 
Message-ID: <1374844938-25505-1-git-send-email-zhangfei.gao@linaro.org>

V4:
resend for 3.11

v3:
patch 02, use size instead of threshold

v2:
Suggested by Baruch
Support hisilicon i2c in i2c-designware-platdrv.c, and adding two optional properties

Zhangfei Gao (2):
  i2c: designware: use module_platform_driver
  i2c: designware: add two optional property tx/rx-fifo-size

 .../devicetree/bindings/i2c/i2c-designware.txt     |    7 +++++++
 drivers/i2c/busses/i2c-designware-platdrv.c        |   17 +++++------------
 2 files changed, 12 insertions(+), 12 deletions(-)

-- 
1.7.9.5



From zhangfei.gao at linaro.org  Fri Jul 26 09:22:17 2013
From: zhangfei.gao at linaro.org (Zhangfei Gao)
Date: Fri, 26 Jul 2013 21:22:17 +0800
Subject: [PATCH v4 1/2] i2c: designware: use module_platform_driver
In-Reply-To: <1374844938-25505-1-git-send-email-zhangfei.gao@linaro.org>
References: <1374844938-25505-1-git-send-email-zhangfei.gao@linaro.org>
Message-ID: <1374844938-25505-2-git-send-email-zhangfei.gao@linaro.org>

Instead of use platform_driver_probe, use module_platform_driver
To support deferred probing
Also subsys_initcall may too early to auto set pinctl

Signed-off-by: Zhangfei Gao <zhangfei.gao at linaro.org>
Acked-by: Baruch Siach <baruch at tkos.co.il>
---
 drivers/i2c/busses/i2c-designware-platdrv.c |   14 ++------------
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 4c5fada..36ceebc 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -236,6 +236,7 @@ static SIMPLE_DEV_PM_OPS(dw_i2c_dev_pm_ops, dw_i2c_suspend, dw_i2c_resume);
 MODULE_ALIAS("platform:i2c_designware");
 
 static struct platform_driver dw_i2c_driver = {
+	.probe		= dw_i2c_probe,
 	.remove		= dw_i2c_remove,
 	.driver		= {
 		.name	= "i2c_designware",
@@ -245,18 +246,7 @@ static struct platform_driver dw_i2c_driver = {
 		.pm	= &dw_i2c_dev_pm_ops,
 	},
 };
-
-static int __init dw_i2c_init_driver(void)
-{
-	return platform_driver_probe(&dw_i2c_driver, dw_i2c_probe);
-}
-subsys_initcall(dw_i2c_init_driver);
-
-static void __exit dw_i2c_exit_driver(void)
-{
-	platform_driver_unregister(&dw_i2c_driver);
-}
-module_exit(dw_i2c_exit_driver);
+module_platform_driver(dw_i2c_driver);
 
 MODULE_AUTHOR("Baruch Siach <baruch at tkos.co.il>");
 MODULE_DESCRIPTION("Synopsys DesignWare I2C bus adapter");
-- 
1.7.9.5



From zhangfei.gao at linaro.org  Fri Jul 26 09:22:18 2013
From: zhangfei.gao at linaro.org (Zhangfei Gao)
Date: Fri, 26 Jul 2013 21:22:18 +0800
Subject: [PATCH v4 2/2] i2c: designware: add two optional property
 tx/rx-fifo-size
In-Reply-To: <1374844938-25505-1-git-send-email-zhangfei.gao@linaro.org>
References: <1374844938-25505-1-git-send-email-zhangfei.gao@linaro.org>
Message-ID: <1374844938-25505-3-git-send-email-zhangfei.gao@linaro.org>

Some platform can not get fifo-size info form register DW_IC_COMP_PARAM_1.
Give chance to update rx-fifo-size and tx-fifo-size if provided in dts.

Signed-off-by: Zhangfei Gao <zhangfei.gao at linaro.org>
Acked-by: Baruch Siach <baruch at tkos.co.il>
---
 .../devicetree/bindings/i2c/i2c-designware.txt     |    7 +++++++
 drivers/i2c/busses/i2c-designware-platdrv.c        |    3 +++
 2 files changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
index 7fd7fa2..af0bf8f 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
@@ -6,6 +6,11 @@ Required properties :
  - reg : Offset and length of the register set for the device
  - interrupts : <IRQ> where IRQ is the interrupt number.
 
+Optional properties:
+
+ - rx-fifo-size : 1 cell, Rx fifo size
+ - tx-fifo-size : 1 cell, Tx fifo size
+
 Recommended properties :
 
  - clock-frequency : desired I2C bus clock frequency in Hz.
@@ -22,6 +27,8 @@ Example :
 		compatible = "snps,designware-i2c";
 		reg = <0xf0000 0x1000>;
 		interrupts = <11>;
+		rx-fifo-size = <16>;
+		tx-fifo-size = <16>;
 		clock-frequency = <400000>;
 	};
 
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 36ceebc..f657e65 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -86,6 +86,7 @@ static int dw_i2c_probe(struct platform_device *pdev)
 	struct dw_i2c_dev *dev;
 	struct i2c_adapter *adap;
 	struct resource *mem;
+	struct device_node *np = pdev->dev.of_node;
 	int irq, r;
 
 	irq = platform_get_irq(pdev, 0);
@@ -145,6 +146,8 @@ static int dw_i2c_probe(struct platform_device *pdev)
 		dev->rx_fifo_depth = ((param1 >> 8)  & 0xff) + 1;
 		dev->adapter.nr = pdev->id;
 	}
+	of_property_read_u32(np, "rx-fifo-size", &dev->rx_fifo_depth);
+	of_property_read_u32(np, "tx-fifo-size", &dev->tx_fifo_depth);
 	r = i2c_dw_init(dev);
 	if (r)
 		return r;
-- 
1.7.9.5



From jason at lakedaemon.net  Fri Jul 26 09:27:09 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 26 Jul 2013 09:27:09 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726130927.GC4219@netboy>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
Message-ID: <20130726132709.GH29916@titan.lakedaemon.net>

On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
> On Fri, Jul 26, 2013 at 10:42:24AM +0100, David Woodhouse wrote:
> > On Fri, 2013-07-26 at 10:01 +0200, Richard Cochran wrote:
> > > On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
> > > > 
> > > > We use DT has a kernel configuration input. Our environment is
> > > > designed to guarantee 100% that the kernel and DT match exactly. DT
> > > > very deliberately isn't an ABI boundary in our systems.
> > > 
> > > Think about what you just said.
> > > 
> > > The DT describes the *hardware* not the kernel. Why should you ever
> > > need to update your DT at all?
> > 
> > Well, the nodes which describe hardware devices, according to the
> > bindings which form an ABI contract between DT and drivers, should not
> > normally change. Although they *can* change, if for example you change
> > the MAC address and that's stored there. Or you change the PHY you want
> > it to use. Or something like that. The *ABI* doesn't change, but the
> > data you express *using* that ABI can change. That's kind of the point.
> 
> Unless I totally misunderstood, the thread is talking about letting
> established bindings change with each new kernel version.  I am
> opposed to that.
> 
> Of course, a user may want to change the values of his MAC addresses,
> if he needs to. But he should never have to change *how* he specifies
> those addresses.

The other dynamic change that bears mentioning here is attributes which
have been configured by the bootloader.  For example, in mvebu, we have
the Schrodinger's Cat register.  It allows you to reconfigure the base
address of the registers from *within* that register range.  If the
bootloader does this, the DT needs to be updated to reflect the current
hardware configuration.  Otherwise, the kernel is stuck poking around at
memory addresses hoping to find something sane.

But this falls into the same category as you mentioned, but outside of
chosen {};.

> So, as long as everyone can agree to the principle that a working DT
> should remain working after a kernel upgrade, then I'll shut up. In
> actual fact, this is not the case today, nor was it ever so in the
> past, AFAICT, but it never hurts to set goals.

Some instability is necessary as we figure out what 'stable' is.
Otherwise, things would've been so rigid, we'd've never made any
progress.  I'd say we now a sufficient body of code and experience to
start enforcing the goal.

thx,

Jason.


From maxime.ripard at free-electrons.com  Fri Jul 26 09:26:48 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 26 Jul 2013 15:26:48 +0200
Subject: [PATCH] pinctrl: sunxi: Fix gpio_set behaviour
In-Reply-To: <20130726125445.612b2acf@skate>
References: <1374748876-23461-1-git-send-email-maxime.ripard@free-electrons.com>
 <20130726125445.612b2acf@skate>
Message-ID: <20130726132648.GG3056@lukather>

Hi Thomas,

On Fri, Jul 26, 2013 at 12:54:45PM +0200, Thomas Petazzoni wrote:
> On Thu, 25 Jul 2013 12:41:16 +0200, Maxime Ripard wrote:
> > The current gpio_set function is ignoring the previous value set in the
> > GPIO value register, which leads in erasing the values already set for
> > the other GPIOs in the same bank when setting the value of a given GPIO.
> > 
> > Add the usual read/mask/write pattern to fix this brown paper bag bug.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > ---
> >  drivers/pinctrl/pinctrl-sunxi.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
> > index fc058b6..4f8bb18 100644
> > --- a/drivers/pinctrl/pinctrl-sunxi.c
> > +++ b/drivers/pinctrl/pinctrl-sunxi.c
> > @@ -464,8 +464,14 @@ static void sunxi_pinctrl_gpio_set(struct gpio_chip *chip,
> >  	struct sunxi_pinctrl *pctl = dev_get_drvdata(chip->dev);
> >  	u32 reg = sunxi_data_reg(offset);
> >  	u8 index = sunxi_data_offset(offset);
> > +	u32 regval = readl(pctl->membase + reg);
> >  
> > -	writel((value & DATA_PINS_MASK) << index, pctl->membase + reg);
> > +	if (value)
> > +		regval |= BIT(index);
> > +	else
> > +		regval &= ~(BIT(index));
> > +
> > +	writel(regval, pctl->membase + reg);
> 
> Hum, what about locking?

Right, I should probably use some spinlocks.

I'll do a followup patch, because this chunk won't be the only area
impacted obviously.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130726/6e3654a2/attachment.sig>

From linux at arm.linux.org.uk  Fri Jul 26 09:28:50 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 14:28:50 +0100
Subject: [PATCH RESEND v2] ARM: dt: Use the 'model' field for printing
 the hardware revision
In-Reply-To: <1374844784-2639-1-git-send-email-festevam@gmail.com>
References: <1374844784-2639-1-git-send-email-festevam@gmail.com>
Message-ID: <20130726132850.GM24642@n2100.arm.linux.org.uk>

On Fri, Jul 26, 2013 at 10:19:44AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> When booting a device tree kernel, we get the following output from 
> 'cat /proc/cpuinfo': 
> 
> $ cat /proc/cpuinfo 
> processor       : 0
> model name      : ARMv7 Processor rev 5 (v7l)
> BogoMIPS        : 531.66
> Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls 
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x2
> CPU part        : 0xc08
> CPU revision    : 5
> 
> Hardware        : Freescale i.MX51 (Device Tree Support)
> Revision        : 0000
> Serial          : 0000000000000000
> 
> The Hardware line does not really describe the hardware type, as it is reading
> the information from the dt 'machine' field.
> 
> In the dt case, read the 'model' field instead, so that we can have a better
> description output as follows:
> 
> Hardware        : Freescale i.MX51 Babbage Board
> 
> The hardware output string is unchanged for the non-dt kernel case.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

While I can see the advantage of preserving old ways to do things, that's
not always the best option.

If userspace wants to get at the DT information about a platform, we already
have ways that can happen already - we export the DT stuff so that kexec's
tools can get at it.

And... as the long term goal is to get rid of the individual machine_type
structures for DT, there's no point introducing the new "model" field in
that struct.

And no, you're not supposed to write to mdesc structures.  Thanks for
being the one to point out that they aren't const, I'll make them so now.


From padma.v at samsung.com  Fri Jul 26 09:36:44 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Fri, 26 Jul 2013 19:06:44 +0530
Subject: [PATCH V2 0/8] Add audio support on smdk5420
Message-ID: <1374845812-7803-1-git-send-email-padma.v@samsung.com>

Samsung has different versions of I2S introduced in different
platforms. Each version has some new support added for multichannel,
secondary fifo, s/w reset control, internal mux for rclk src clk and
tdm support. Each newly added change has a quirk. So this patch adds
all the required quirks as driver data and based on compatible string
from dtsi fetches the quirks. This also adds i2s support on exynos5420
and make relevent changes in the dtsi files.

Changes since V1:
	- Pass quirks as driver data and fetch the quirks based on
	  compatible string from dtsi file as suggested by
	  Tomasz Figa and Mark Brown
	- Make the I2S driver more flexible with respect to register
	  access as suggested by Tomasz Figa and Mark Brown
	- Add 5420 support in the driver.
	- Modify the dtsi files with the corresponding compatible
	  strings and removed the i2s quirks from 5250 dtsi file.
	- Updated the i2s Documentation with relevent changes and
	  i2s versioning info.
	- Add i2s nodes on exynos5420.dtsi
	- Enable sound support on smdk5420

This patch set is dependent on the following dma and audio subsystem
clk controller patches.
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20661
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20668

This patch set is made based on Kukjin Kim for-next branch.

Andrew Bresticker (1):
  ARM: dts: exynos5420: add i2s controllers

Padmavathi Venna (7):
  platform: Increase platform name size
  ASoC: Samsung: I2S: Add quirks as driver data in I2S
  ARM: dts: Change i2s compatible string on exynos5250
  ASoC: Samsung: I2S: Modify driver to give more flexibility
  ASoC: Samsung: I2S: Modify the I2S driver to support I2S on
    Exynos5420
  ARM: dts: wm8994: Add wm8994 support on smdk5420
  ARM: dts: Enable sound support on smdk5420

 .../devicetree/bindings/sound/samsung-i2s.txt      |   25 ++-
 arch/arm/boot/dts/exynos5250.dtsi                  |    9 +-
 arch/arm/boot/dts/exynos5420-smdk5420.dts          |   60 ++++++
 arch/arm/boot/dts/exynos5420.dtsi                  |   44 +++++
 include/linux/mod_devicetable.h                    |    2 +-
 include/linux/platform_data/asoc-s3c.h             |    1 +
 sound/soc/samsung/i2s-regs.h                       |   51 ++++--
 sound/soc/samsung/i2s.c                            |  205 +++++++++++++++-----
 8 files changed, 312 insertions(+), 85 deletions(-)

-- 
1.7.4.4



From padma.v at samsung.com  Fri Jul 26 09:36:45 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Fri, 26 Jul 2013 19:06:45 +0530
Subject: [PATCH V2 1/8] platform: Increase platform name size
In-Reply-To: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
Message-ID: <1374845812-7803-2-git-send-email-padma.v@samsung.com>

This patch increases the platform name size from 20 to 30.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---
 include/linux/mod_devicetable.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index b62d4af..f67b5d5 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -478,7 +478,7 @@ struct dmi_system_id {
 #define DMI_MATCH(a, b)	{ .slot = a, .substr = b }
 #define DMI_EXACT_MATCH(a, b)	{ .slot = a, .substr = b, .exact_match = 1 }
 
-#define PLATFORM_NAME_SIZE	20
+#define PLATFORM_NAME_SIZE	30
 #define PLATFORM_MODULE_PREFIX	"platform:"
 
 struct platform_device_id {
-- 
1.7.4.4



From padma.v at samsung.com  Fri Jul 26 09:36:46 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Fri, 26 Jul 2013 19:06:46 +0530
Subject: [PATCH V2 2/8] ASoC: Samsung: I2S: Add quirks as driver data in I2S
In-Reply-To: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
Message-ID: <1374845812-7803-3-git-send-email-padma.v@samsung.com>

Samsung has different versions of I2S introduced in different
platforms. Each version has some new support added for multichannel,
secondary fifo, s/w reset control and internal mux for rclk src clk.
Each newly added change has a quirk. So this patch adds all the
required quirks as driver data and based on compatible string from
dtsi fetches the quirks.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---
 .../devicetree/bindings/sound/samsung-i2s.txt      |   21 +++---
 sound/soc/samsung/i2s.c                            |   82 +++++++++++++-------
 2 files changed, 64 insertions(+), 39 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
index 025e66b..b3f6443 100644
--- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
@@ -2,7 +2,16 @@
 
 Required SoC Specific Properties:
 
-- compatible : "samsung,i2s-v5"
+- compatible : should be one of the following.
+   - samsung,s3c6410-i2s: for 8/16/24bit stereo I2S. Previous versions
+     has only 8/16bit support.
+   - samsung,s3c6410-i2sv4: for 8/16/24bit multichannel(5.1 channel) I2S.
+     Introduced in s3c6410. This also applicable for s5p64x0 platforms.
+   - samsung,s5pc100-i2s: for 8/16/24bit multichannel(5.1 channel) I2S
+     with secondary fifo and s/w reset control.
+   - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with
+     secondary fifo, s/w reset control and internal mux for root clk src.
+
 - reg: physical base address of the controller and length of memory mapped
   region.
 - dmas: list of DMA controller phandle and DMA request line ordered pairs.
@@ -21,13 +30,6 @@ Required SoC Specific Properties:
 
 Optional SoC Specific Properties:
 
-- samsung,supports-6ch: If the I2S Primary sound source has 5.1 Channel
-  support, this flag is enabled.
-- samsung,supports-rstclr: This flag should be set if I2S software reset bit
-  control is required. When this flag is set I2S software reset bit will be
-  enabled or disabled based on need.
-- samsung,supports-secdai:If I2S block has a secondary FIFO and internal DMA,
-  then this flag is enabled.
 - samsung,idma-addr: Internal DMA register base address of the audio
   sub system(used in secondary sound source).
 - pinctrl-0: Should specify pin control groups used for this controller.
@@ -46,9 +48,6 @@ i2s0: i2s at 03830000 {
 		<&clock_audss EXYNOS_I2S_BUS>,
 		<&clock_audss EXYNOS_SCLK_I2S>;
 	clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
-	samsung,supports-6ch;
-	samsung,supports-rstclr;
-	samsung,supports-secdai;
 	samsung,idma-addr = <0x03000000>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&i2s0_bus>;
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 959c702..f661a98 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -40,6 +40,7 @@ enum samsung_dai_type {
 
 struct samsung_i2s_dai_data {
 	int dai_type;
+	u32 quirks;
 };
 
 struct i2s_dai {
@@ -1018,18 +1019,18 @@ static struct i2s_dai *i2s_alloc_dai(struct platform_device *pdev, bool sec)
 
 static const struct of_device_id exynos_i2s_match[];
 
-static inline int samsung_i2s_get_driver_data(struct platform_device *pdev)
+static inline struct samsung_i2s_dai_data *samsung_i2s_get_driver_data(
+						struct platform_device *pdev)
 {
 #ifdef CONFIG_OF
-	struct samsung_i2s_dai_data *data;
 	if (pdev->dev.of_node) {
 		const struct of_device_id *match;
 		match = of_match_node(exynos_i2s_match, pdev->dev.of_node);
-		data = (struct samsung_i2s_dai_data *) match->data;
-		return data->dai_type;
+		return (struct samsung_i2s_dai_data *) match->data;
 	} else
 #endif
-		return platform_get_device_id(pdev)->driver_data;
+		return (struct samsung_i2s_dai_data *)
+				platform_get_device_id(pdev)->driver_data;
 }
 
 #ifdef CONFIG_PM_RUNTIME
@@ -1060,13 +1061,13 @@ static int samsung_i2s_probe(struct platform_device *pdev)
 	struct resource *res;
 	u32 regs_base, quirks = 0, idma_addr = 0;
 	struct device_node *np = pdev->dev.of_node;
-	enum samsung_dai_type samsung_dai_type;
+	struct samsung_i2s_dai_data *i2s_dai_data;
 	int ret = 0;
 
 	/* Call during Seconday interface registration */
-	samsung_dai_type = samsung_i2s_get_driver_data(pdev);
+	i2s_dai_data = samsung_i2s_get_driver_data(pdev);
 
-	if (samsung_dai_type == TYPE_SEC) {
+	if (i2s_dai_data->dai_type == TYPE_SEC) {
 		sec_dai = dev_get_drvdata(&pdev->dev);
 		if (!sec_dai) {
 			dev_err(&pdev->dev, "Unable to get drvdata\n");
@@ -1115,15 +1116,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
 			idma_addr = i2s_cfg->idma_addr;
 		}
 	} else {
-		if (of_find_property(np, "samsung,supports-6ch", NULL))
-			quirks |= QUIRK_PRI_6CHAN;
-
-		if (of_find_property(np, "samsung,supports-secdai", NULL))
-			quirks |= QUIRK_SEC_DAI;
-
-		if (of_find_property(np, "samsung,supports-rstclr", NULL))
-			quirks |= QUIRK_NEED_RSTCLR;
-
+		quirks = i2s_dai_data->quirks;
 		if (of_property_read_u32(np, "samsung,idma-addr",
 					 &idma_addr)) {
 			if (quirks & QUIRK_SEC_DAI) {
@@ -1236,27 +1229,60 @@ static int samsung_i2s_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static struct samsung_i2s_dai_data i2sv3_dai_type = {
+	.dai_type = TYPE_PRI,
+	.quirks = QUIRK_NO_MUXPSR,
+};
+
+static struct samsung_i2s_dai_data i2sv4_dai_type = {
+	.dai_type = TYPE_PRI,
+	.quirks = QUIRK_PRI_6CHAN | QUIRK_NO_MUXPSR,
+};
+
+static struct samsung_i2s_dai_data i2sv5_c100_dai_type = {
+	.dai_type = TYPE_PRI,
+	.quirks = QUIRK_PRI_6CHAN | QUIRK_NO_MUXPSR | QUIRK_SEC_DAI |
+			QUIRK_NEED_RSTCLR,
+};
+
+static struct samsung_i2s_dai_data i2sv5_dai_type = {
+	.dai_type = TYPE_PRI,
+	.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR,
+};
+
+static struct samsung_i2s_dai_data samsung_dai_type_sec = {
+	.dai_type = TYPE_SEC,
+};
+
 static struct platform_device_id samsung_i2s_driver_ids[] = {
 	{
-		.name           = "samsung-i2s",
-		.driver_data	= TYPE_PRI,
+		.name		= "samsung,s3c6410-i2s",
+		.driver_data	= (kernel_ulong_t)&i2sv3_dai_type,
+	}, {
+		.name		= "samsung,s3c6410-i2sv4",
+		.driver_data	= (kernel_ulong_t)&i2sv4_dai_type,
+	}, {
+		.name		= "samsung,s5pc100-i2s",
+		.driver_data	= (kernel_ulong_t)&i2sv5_c100_dai_type,
 	}, {
-		.name           = "samsung-i2s-sec",
-		.driver_data	= TYPE_SEC,
+		.name		= "samsung,s5pv210-i2s",
+		.driver_data	= (kernel_ulong_t)&i2sv5_dai_type,
+	}, {
+		.name		= "samsung-i2s-sec",
+		.driver_data	= (kernel_ulong_t)&samsung_dai_type_sec,
 	},
 	{},
 };
 MODULE_DEVICE_TABLE(platform, samsung_i2s_driver_ids);
 
 #ifdef CONFIG_OF
-static struct samsung_i2s_dai_data samsung_i2s_dai_data_array[] = {
-	[TYPE_PRI] = { TYPE_PRI },
-	[TYPE_SEC] = { TYPE_SEC },
-};
-
 static const struct of_device_id exynos_i2s_match[] = {
-	{ .compatible = "samsung,i2s-v5",
-	  .data = &samsung_i2s_dai_data_array[TYPE_PRI],
+	{
+		.compatible = "samsung,s3c6410-i2s",
+		.data = &i2sv3_dai_type,
+	}, {
+		.compatible = "samsung,s5pv210-i2s",
+		.data = &i2sv5_dai_type,
 	},
 	{},
 };
-- 
1.7.4.4



From padma.v at samsung.com  Fri Jul 26 09:36:47 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Fri, 26 Jul 2013 19:06:47 +0530
Subject: [PATCH V2 3/8] ARM: dts: Change i2s compatible string on exynos5250
In-Reply-To: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
Message-ID: <1374845812-7803-4-git-send-email-padma.v@samsung.com>

This patch removes quirks from i2s node and change the i2s
compatible names.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi |    9 +++------
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index db2ca8b..f7fbedd 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -385,7 +385,7 @@
 	};
 
 	i2s0: i2s at 03830000 {
-		compatible = "samsung,i2s-v5";
+		compatible = "samsung,s5pv210-i2s";
 		reg = <0x03830000 0x100>;
 		dmas = <&pdma0 10
 			&pdma0 9
@@ -395,16 +395,13 @@
 			<&clock_audss EXYNOS_I2S_BUS>,
 			<&clock_audss EXYNOS_SCLK_I2S>;
 		clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
-		samsung,supports-6ch;
-		samsung,supports-rstclr;
-		samsung,supports-secdai;
 		samsung,idma-addr = <0x03000000>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&i2s0_bus>;
 	};
 
 	i2s1: i2s at 12D60000 {
-		compatible = "samsung,i2s-v5";
+		compatible = "samsung,s3c6410-i2s";
 		reg = <0x12D60000 0x100>;
 		dmas = <&pdma1 12
 			&pdma1 11>;
@@ -416,7 +413,7 @@
 	};
 
 	i2s2: i2s at 12D70000 {
-		compatible = "samsung,i2s-v5";
+		compatible = "samsung,s3c6410-i2s";
 		reg = <0x12D70000 0x100>;
 		dmas = <&pdma0 12
 			&pdma0 11>;
-- 
1.7.4.4



From padma.v at samsung.com  Fri Jul 26 09:36:48 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Fri, 26 Jul 2013 19:06:48 +0530
Subject: [PATCH V2 4/8] ASoC: Samsung: I2S: Modify driver to give more
 flexibility
In-Reply-To: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
Message-ID: <1374845812-7803-5-git-send-email-padma.v@samsung.com>

This patch modifies the i2s driver to give flexibility towards register
handling. This is a pre requirement for enabling i2s support on Exynos5420.
This patch modifies only the required registers as a pre-requirement to
support on Exynos5420.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---
 sound/soc/samsung/i2s-regs.h |   36 ++++++++++++++-----------
 sound/soc/samsung/i2s.c      |   58 +++++++++++++++++++++++++----------------
 2 files changed, 55 insertions(+), 39 deletions(-)

diff --git a/sound/soc/samsung/i2s-regs.h b/sound/soc/samsung/i2s-regs.h
index c0e6d9a..30513b7 100644
--- a/sound/soc/samsung/i2s-regs.h
+++ b/sound/soc/samsung/i2s-regs.h
@@ -95,22 +95,26 @@
 #define MOD_RXONLY		(1 << 8)
 #define MOD_TXRX		(2 << 8)
 #define MOD_MASK		(3 << 8)
-#define MOD_LR_LLOW		(0 << 7)
-#define MOD_LR_RLOW		(1 << 7)
-#define MOD_SDF_IIS		(0 << 5)
-#define MOD_SDF_MSB		(1 << 5)
-#define MOD_SDF_LSB		(2 << 5)
-#define MOD_SDF_MASK		(3 << 5)
-#define MOD_RCLK_256FS		(0 << 3)
-#define MOD_RCLK_512FS		(1 << 3)
-#define MOD_RCLK_384FS		(2 << 3)
-#define MOD_RCLK_768FS		(3 << 3)
-#define MOD_RCLK_MASK		(3 << 3)
-#define MOD_BCLK_32FS		(0 << 1)
-#define MOD_BCLK_48FS		(1 << 1)
-#define MOD_BCLK_16FS		(2 << 1)
-#define MOD_BCLK_24FS		(3 << 1)
-#define MOD_BCLK_MASK		(3 << 1)
+#define MOD_LRP_SHIFT		7
+#define MOD_LR_LLOW		0
+#define MOD_LR_RLOW		1
+#define MOD_SDF_SHIFT		5
+#define MOD_SDF_IIS		0
+#define MOD_SDF_MSB		1
+#define MOD_SDF_LSB		2
+#define MOD_SDF_MASK		3
+#define MOD_RCLK_SHIFT		3
+#define MOD_RCLK_256FS		0
+#define MOD_RCLK_512FS		1
+#define MOD_RCLK_384FS		2
+#define MOD_RCLK_768FS		3
+#define MOD_RCLK_MASK		3
+#define MOD_BCLK_SHIFT		1
+#define MOD_BCLK_32FS		0
+#define MOD_BCLK_48FS		1
+#define MOD_BCLK_16FS		2
+#define MOD_BCLK_24FS		3
+#define MOD_BCLK_MASK		3
 #define MOD_8BIT		(1 << 0)
 
 #define MOD_CDCLKCON		(1 << 12)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index f661a98..0b36b0a 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -199,7 +199,8 @@ static inline bool is_manager(struct i2s_dai *i2s)
 /* Read RCLK of I2S (in multiples of LRCLK) */
 static inline unsigned get_rfs(struct i2s_dai *i2s)
 {
-	u32 rfs = (readl(i2s->addr + I2SMOD) >> 3) & 0x3;
+	u32 rfs = (readl(i2s->addr + I2SMOD) >> MOD_RCLK_SHIFT);
+	rfs &= MOD_RCLK_MASK;
 
 	switch (rfs) {
 	case 3:	return 768;
@@ -213,21 +214,22 @@ static inline unsigned get_rfs(struct i2s_dai *i2s)
 static inline void set_rfs(struct i2s_dai *i2s, unsigned rfs)
 {
 	u32 mod = readl(i2s->addr + I2SMOD);
+	int rfs_shift =  MOD_RCLK_SHIFT;
 
-	mod &= ~MOD_RCLK_MASK;
+	mod &= ~(MOD_RCLK_MASK << rfs_shift);
 
 	switch (rfs) {
 	case 768:
-		mod |= MOD_RCLK_768FS;
+		mod |= (MOD_RCLK_768FS << rfs_shift);
 		break;
 	case 512:
-		mod |= MOD_RCLK_512FS;
+		mod |= (MOD_RCLK_512FS << rfs_shift);
 		break;
 	case 384:
-		mod |= MOD_RCLK_384FS;
+		mod |= (MOD_RCLK_384FS << rfs_shift);
 		break;
 	default:
-		mod |= MOD_RCLK_256FS;
+		mod |= (MOD_RCLK_256FS << rfs_shift);
 		break;
 	}
 
@@ -237,7 +239,8 @@ static inline void set_rfs(struct i2s_dai *i2s, unsigned rfs)
 /* Read Bit-Clock of I2S (in multiples of LRCLK) */
 static inline unsigned get_bfs(struct i2s_dai *i2s)
 {
-	u32 bfs = (readl(i2s->addr + I2SMOD) >> 1) & 0x3;
+	u32 bfs =  readl(i2s->addr + I2SMOD) >> MOD_BCLK_SHIFT;
+	bfs &= MOD_BCLK_MASK;
 
 	switch (bfs) {
 	case 3: return 24;
@@ -251,21 +254,22 @@ static inline unsigned get_bfs(struct i2s_dai *i2s)
 static inline void set_bfs(struct i2s_dai *i2s, unsigned bfs)
 {
 	u32 mod = readl(i2s->addr + I2SMOD);
+	int bfs_shift = MOD_BCLK_SHIFT;
 
-	mod &= ~MOD_BCLK_MASK;
+	mod &= ~(MOD_BCLK_MASK << bfs_shift);
 
 	switch (bfs) {
 	case 48:
-		mod |= MOD_BCLK_48FS;
+		mod |= (MOD_BCLK_48FS << bfs_shift);
 		break;
 	case 32:
-		mod |= MOD_BCLK_32FS;
+		mod |= (MOD_BCLK_32FS << bfs_shift);
 		break;
 	case 24:
-		mod |= MOD_BCLK_24FS;
+		mod |= (MOD_BCLK_24FS << bfs_shift);
 		break;
 	case 16:
-		mod |= MOD_BCLK_16FS;
+		mod |= (MOD_BCLK_16FS << bfs_shift);
 		break;
 	default:
 		dev_err(&i2s->pdev->dev, "Wrong BCLK Divider!\n");
@@ -492,20 +496,25 @@ static int i2s_set_fmt(struct snd_soc_dai *dai,
 {
 	struct i2s_dai *i2s = to_info(dai);
 	u32 mod = readl(i2s->addr + I2SMOD);
+	int lrp_shift = MOD_LRP_SHIFT, sdf_shift = MOD_SDF_SHIFT;
+	int sdf_mask, lrp_rlow;
 	u32 tmp = 0;
 
+	sdf_mask = MOD_SDF_MASK << sdf_shift;
+	lrp_rlow = MOD_LR_RLOW << lrp_shift;
+
 	/* Format is priority */
 	switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
 	case SND_SOC_DAIFMT_RIGHT_J:
-		tmp |= MOD_LR_RLOW;
-		tmp |= MOD_SDF_MSB;
+		tmp |= lrp_rlow;
+		tmp |= (MOD_SDF_MSB << sdf_shift);
 		break;
 	case SND_SOC_DAIFMT_LEFT_J:
-		tmp |= MOD_LR_RLOW;
-		tmp |= MOD_SDF_LSB;
+		tmp |= lrp_rlow;
+		tmp |= (MOD_SDF_LSB << sdf_shift);
 		break;
 	case SND_SOC_DAIFMT_I2S:
-		tmp |= MOD_SDF_IIS;
+		tmp |= (MOD_SDF_IIS << sdf_shift);
 		break;
 	default:
 		dev_err(&i2s->pdev->dev, "Format not supported\n");
@@ -520,10 +529,10 @@ static int i2s_set_fmt(struct snd_soc_dai *dai,
 	case SND_SOC_DAIFMT_NB_NF:
 		break;
 	case SND_SOC_DAIFMT_NB_IF:
-		if (tmp & MOD_LR_RLOW)
-			tmp &= ~MOD_LR_RLOW;
+		if (tmp & lrp_rlow)
+			tmp &= ~lrp_rlow;
 		else
-			tmp |= MOD_LR_RLOW;
+			tmp |= lrp_rlow;
 		break;
 	default:
 		dev_err(&i2s->pdev->dev, "Polarity not supported\n");
@@ -545,15 +554,18 @@ static int i2s_set_fmt(struct snd_soc_dai *dai,
 		return -EINVAL;
 	}
 
+	/*
+	 * Don't change the I2S mode if any controller is active on this
+	 * channel.
+	 */
 	if (any_active(i2s) &&
-			((mod & (MOD_SDF_MASK | MOD_LR_RLOW
-				| MOD_SLAVE)) != tmp)) {
+		((mod & (sdf_mask | lrp_rlow | MOD_SLAVE)) != tmp)) {
 		dev_err(&i2s->pdev->dev,
 				"%s:%d Other DAI busy\n", __func__, __LINE__);
 		return -EAGAIN;
 	}
 
-	mod &= ~(MOD_SDF_MASK | MOD_LR_RLOW | MOD_SLAVE);
+	mod &= ~(sdf_mask | lrp_rlow | MOD_SLAVE);
 	mod |= tmp;
 	writel(mod, i2s->addr + I2SMOD);
 
-- 
1.7.4.4



From padma.v at samsung.com  Fri Jul 26 09:36:49 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Fri, 26 Jul 2013 19:06:49 +0530
Subject: [PATCH V2 5/8] ASoC: Samsung: I2S: Modify the I2S driver to support
 I2S on Exynos5420
In-Reply-To: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
Message-ID: <1374845812-7803-6-git-send-email-padma.v@samsung.com>

Exynos5420 added support for I2S TDM mode. For this, there are some
register changes in the I2S controller. This patch adds the relevant
register changes to support I2S in normal mode. This patch adds a
quirk for TDM mode and if TDM mode is present all the relevent changes
will be applied.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---
 .../devicetree/bindings/sound/samsung-i2s.txt      |    4 +
 include/linux/platform_data/asoc-s3c.h             |    1 +
 sound/soc/samsung/i2s-regs.h                       |   15 ++++
 sound/soc/samsung/i2s.c                            |   81 ++++++++++++++++++--
 4 files changed, 93 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
index b3f6443..9b5c892 100644
--- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
@@ -11,6 +11,10 @@ Required SoC Specific Properties:
      with secondary fifo and s/w reset control.
    - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with
      secondary fifo, s/w reset control and internal mux for root clk src.
+   - samsung,exynos5420-i2s: for 8/16/24bit multichannel(7.1) I2S with
+     secondary fifo, s/w reset control, internal mux for root clk src and
+     TDM support. TDM (Time division multiplexing) is to allow transfer of
+     multiple channel audio data on single data line.
 
 - reg: physical base address of the controller and length of memory mapped
   region.
diff --git a/include/linux/platform_data/asoc-s3c.h b/include/linux/platform_data/asoc-s3c.h
index 8827259..9efc04d 100644
--- a/include/linux/platform_data/asoc-s3c.h
+++ b/include/linux/platform_data/asoc-s3c.h
@@ -36,6 +36,7 @@ struct samsung_i2s {
  */
 #define QUIRK_NO_MUXPSR		(1 << 2)
 #define QUIRK_NEED_RSTCLR	(1 << 3)
+#define QUIRK_SUPPORTS_TDM	(1 << 4)
 	/* Quirks of the I2S controller */
 	u32 quirks;
 	dma_addr_t idma_addr;
diff --git a/sound/soc/samsung/i2s-regs.h b/sound/soc/samsung/i2s-regs.h
index 30513b7..821a502 100644
--- a/sound/soc/samsung/i2s-regs.h
+++ b/sound/soc/samsung/i2s-regs.h
@@ -31,6 +31,10 @@
 #define I2SLVL1ADDR	0x34
 #define I2SLVL2ADDR	0x38
 #define I2SLVL3ADDR	0x3c
+#define I2SSTR1		0x40
+#define I2SVER		0x44
+#define I2SFIC2		0x48
+#define I2STDM		0x4c
 
 #define CON_RSTCLR		(1 << 31)
 #define CON_FRXOFSTATUS		(1 << 26)
@@ -117,6 +121,17 @@
 #define MOD_BCLK_MASK		3
 #define MOD_8BIT		(1 << 0)
 
+#define EXYNOS5420_MOD_LRP_SHIFT	15
+#define EXYNOS5420_MOD_SDF_SHIFT	6
+#define EXYNOS5420_MOD_RCLK_SHIFT	4
+#define EXYNOS5420_MOD_BCLK_SHIFT	0
+#define EXYNOS5420_MOD_BCLK_64FS	4
+#define EXYNOS5420_MOD_BCLK_96FS	5
+#define EXYNOS5420_MOD_BCLK_128FS	6
+#define EXYNOS5420_MOD_BCLK_192FS	7
+#define EXYNOS5420_MOD_BCLK_256FS	8
+#define EXYNOS5420_MOD_BCLK_MASK	0xf
+
 #define MOD_CDCLKCON		(1 << 12)
 
 #define PSR_PSREN		(1 << 15)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 0b36b0a..bdbb65d 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -199,7 +199,12 @@ static inline bool is_manager(struct i2s_dai *i2s)
 /* Read RCLK of I2S (in multiples of LRCLK) */
 static inline unsigned get_rfs(struct i2s_dai *i2s)
 {
-	u32 rfs = (readl(i2s->addr + I2SMOD) >> MOD_RCLK_SHIFT);
+	u32 rfs;
+
+	if (i2s->quirks & QUIRK_SUPPORTS_TDM)
+		rfs = readl(i2s->addr + I2SMOD) >> EXYNOS5420_MOD_RCLK_SHIFT;
+	else
+		rfs = (readl(i2s->addr + I2SMOD) >> MOD_RCLK_SHIFT);
 	rfs &= MOD_RCLK_MASK;
 
 	switch (rfs) {
@@ -214,8 +219,12 @@ static inline unsigned get_rfs(struct i2s_dai *i2s)
 static inline void set_rfs(struct i2s_dai *i2s, unsigned rfs)
 {
 	u32 mod = readl(i2s->addr + I2SMOD);
-	int rfs_shift =  MOD_RCLK_SHIFT;
+	int rfs_shift;
 
+	if (i2s->quirks & QUIRK_SUPPORTS_TDM)
+		rfs_shift = EXYNOS5420_MOD_RCLK_SHIFT;
+	else
+		rfs_shift = MOD_RCLK_SHIFT;
 	mod &= ~(MOD_RCLK_MASK << rfs_shift);
 
 	switch (rfs) {
@@ -239,10 +248,22 @@ static inline void set_rfs(struct i2s_dai *i2s, unsigned rfs)
 /* Read Bit-Clock of I2S (in multiples of LRCLK) */
 static inline unsigned get_bfs(struct i2s_dai *i2s)
 {
-	u32 bfs =  readl(i2s->addr + I2SMOD) >> MOD_BCLK_SHIFT;
-	bfs &= MOD_BCLK_MASK;
+	u32 bfs;
+
+	if (i2s->quirks & QUIRK_SUPPORTS_TDM) {
+		bfs = readl(i2s->addr + I2SMOD) >> EXYNOS5420_MOD_BCLK_SHIFT;
+		bfs &= EXYNOS5420_MOD_BCLK_MASK;
+	} else {
+		bfs =  readl(i2s->addr + I2SMOD) >> MOD_BCLK_SHIFT;
+		bfs &= MOD_BCLK_MASK;
+	}
 
 	switch (bfs) {
+	case 8: return 256;
+	case 7: return 192;
+	case 6: return 128;
+	case 5: return 96;
+	case 4: return 64;
 	case 3: return 24;
 	case 2: return 16;
 	case 1:	return 48;
@@ -254,9 +275,22 @@ static inline unsigned get_bfs(struct i2s_dai *i2s)
 static inline void set_bfs(struct i2s_dai *i2s, unsigned bfs)
 {
 	u32 mod = readl(i2s->addr + I2SMOD);
-	int bfs_shift = MOD_BCLK_SHIFT;
+	int bfs_shift;
+	int tdm = i2s->quirks & QUIRK_SUPPORTS_TDM;
 
-	mod &= ~(MOD_BCLK_MASK << bfs_shift);
+	if (i2s->quirks & QUIRK_SUPPORTS_TDM) {
+		bfs_shift = EXYNOS5420_MOD_BCLK_SHIFT;
+		mod &= ~(EXYNOS5420_MOD_BCLK_MASK << bfs_shift);
+	} else {
+		bfs_shift = MOD_BCLK_SHIFT;
+		mod &= ~(MOD_BCLK_MASK << bfs_shift);
+	}
+
+	/* Non-TDM I2S controllers do not support BCLK > 48 * FS */
+	if (!tdm && bfs > 48) {
+		dev_err(&i2s->pdev->dev, "Unsupported BCLK divider\n");
+		return;
+	}
 
 	switch (bfs) {
 	case 48:
@@ -271,6 +305,21 @@ static inline void set_bfs(struct i2s_dai *i2s, unsigned bfs)
 	case 16:
 		mod |= (MOD_BCLK_16FS << bfs_shift);
 		break;
+	case 64:
+		mod |= (EXYNOS5420_MOD_BCLK_64FS << bfs_shift);
+		break;
+	case 96:
+		mod |= (EXYNOS5420_MOD_BCLK_96FS << bfs_shift);
+		break;
+	case 128:
+		mod |= (EXYNOS5420_MOD_BCLK_128FS << bfs_shift);
+		break;
+	case 192:
+		mod |= (EXYNOS5420_MOD_BCLK_192FS << bfs_shift);
+		break;
+	case 256:
+		mod |= (EXYNOS5420_MOD_BCLK_256FS << bfs_shift);
+		break;
 	default:
 		dev_err(&i2s->pdev->dev, "Wrong BCLK Divider!\n");
 		return;
@@ -496,10 +545,17 @@ static int i2s_set_fmt(struct snd_soc_dai *dai,
 {
 	struct i2s_dai *i2s = to_info(dai);
 	u32 mod = readl(i2s->addr + I2SMOD);
-	int lrp_shift = MOD_LRP_SHIFT, sdf_shift = MOD_SDF_SHIFT;
-	int sdf_mask, lrp_rlow;
+	int lrp_shift, sdf_shift, sdf_mask, lrp_rlow;
 	u32 tmp = 0;
 
+	if (i2s->quirks & QUIRK_SUPPORTS_TDM) {
+		lrp_shift = EXYNOS5420_MOD_LRP_SHIFT;
+		sdf_shift = EXYNOS5420_MOD_SDF_SHIFT;
+	} else {
+		lrp_shift = MOD_LRP_SHIFT;
+		sdf_shift = MOD_SDF_SHIFT;
+	}
+
 	sdf_mask = MOD_SDF_MASK << sdf_shift;
 	lrp_rlow = MOD_LR_RLOW << lrp_shift;
 
@@ -1262,6 +1318,12 @@ static struct samsung_i2s_dai_data i2sv5_dai_type = {
 	.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR,
 };
 
+static struct samsung_i2s_dai_data i2sv6_dai_type = {
+	.dai_type = TYPE_PRI,
+	.quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR |
+			QUIRK_SUPPORTS_TDM,
+};
+
 static struct samsung_i2s_dai_data samsung_dai_type_sec = {
 	.dai_type = TYPE_SEC,
 };
@@ -1295,6 +1357,9 @@ static const struct of_device_id exynos_i2s_match[] = {
 	}, {
 		.compatible = "samsung,s5pv210-i2s",
 		.data = &i2sv5_dai_type,
+	}, {
+		.compatible = "samsung,exynos5420-i2s",
+		.data = &i2sv6_dai_type,
 	},
 	{},
 };
-- 
1.7.4.4



From padma.v at samsung.com  Fri Jul 26 09:36:50 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Fri, 26 Jul 2013 19:06:50 +0530
Subject: [PATCH V2 6/8] ARM: dts: exynos5420: add i2s controllers
In-Reply-To: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
Message-ID: <1374845812-7803-7-git-send-email-padma.v@samsung.com>

From: Andrew Bresticker <abrestic at chromium.org>

This adds device-tree bindings for the i2s controllers on Exynos 5420.

Signed-off-by: Andrew Bresticker <abrestic at chromium.org>
Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57713
---
 arch/arm/boot/dts/exynos5420.dtsi |   44 +++++++++++++++++++++++++++++++++++++
 1 files changed, 44 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index d2fdb87..c9ed8d2 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -242,4 +242,48 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&i2c3_bus>;
 	};
+
+	i2s_0: i2s at 03830000 {
+		compatible = "samsung,exynos5420-i2s";
+		reg = <0x03830000 0x100>;
+		dmas = <&adma 0
+			&adma 2
+			&adma 1>;
+		dma-names = "tx", "rx", "tx-sec";
+		clocks = <&clock_audss EXYNOS_I2S_BUS>,
+			<&clock_audss EXYNOS_I2S_BUS>,
+			<&clock_audss EXYNOS_SCLK_I2S>;
+		clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
+		samsung,idma-addr = <0x03000000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&i2s0_bus>;
+		status = "disabled";
+	};
+
+	i2s_1: i2s at 12D60000 {
+		compatible = "samsung,s3c6410-i2s";
+		reg = <0x12D60000 0x100>;
+		dmas = <&pdma1 12
+			&pdma1 11>;
+		dma-names = "tx", "rx";
+		clocks = <&clock 275>, <&clock 138>;
+		clock-names = "iis", "i2s_opclk0";
+		pinctrl-names = "default";
+		pinctrl-0 = <&i2s1_bus>;
+		status = "disabled";
+	};
+
+	i2s_2: i2s at 12D70000 {
+		compatible = "samsung,s3c6410-i2s";
+		reg = <0x12D70000 0x100>;
+		dmas = <&pdma0 12
+			&pdma0 11>;
+		dma-names = "tx", "rx";
+		clocks = <&clock 276>, <&clock 139>;
+		clock-names = "iis", "i2s_opclk0";
+		pinctrl-names = "default";
+		pinctrl-0 = <&i2s2_bus>;
+		status = "disabled";
+	};
+
 };
-- 
1.7.4.4



From padma.v at samsung.com  Fri Jul 26 09:36:51 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Fri, 26 Jul 2013 19:06:51 +0530
Subject: [PATCH V2 7/8] ARM: dts: wm8994: Add wm8994 support on smdk5420
In-Reply-To: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
Message-ID: <1374845812-7803-8-git-send-email-padma.v@samsung.com>

This patch adds wm8994 codec node on i2c bus1 and the required
regulator supplies and properties on smdk5420 board.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---
 arch/arm/boot/dts/exynos5420-smdk5420.dts |   50 +++++++++++++++++++++++++++++
 1 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index d05de7a..28a6855 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -68,4 +68,54 @@
 			bus-width = <4>;
 		};
 	};
+
+	vdd: fixed-regulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd-supply";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
+	};
+
+	dbvdd: fixed-regulator at 1 {
+		compatible = "regulator-fixed";
+		regulator-name = "dbvdd-supply";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
+	spkvdd: fixed-regulator at 2 {
+		compatible = "regulator-fixed";
+		regulator-name = "spkvdd-supply";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	i2c at 12C70000 {
+		status = "okay";
+		samsung,i2c-sda-delay = <100>;
+		samsung,i2c-max-bus-freq = <20000>;
+
+		eeprom at 51 {
+			compatible = "samsung,s524ad0xd1";
+			reg = <0x51>;
+		};
+
+		wm8994: wm8994 at 1a {
+			compatible = "wlf,wm8994";
+			reg = <0x1a>;
+
+			gpio-controller;
+			#gpio-cells = <2>;
+
+			AVDD2-supply = <&vdd>;
+			CPVDD-supply = <&vdd>;
+			DBVDD-supply = <&dbvdd>;
+			SPKVDD1-supply = <&spkvdd>;
+			SPKVDD2-supply = <&spkvdd>;
+		};
+	};
+
 };
-- 
1.7.4.4



From padma.v at samsung.com  Fri Jul 26 09:36:52 2013
From: padma.v at samsung.com (Padmavathi Venna)
Date: Fri, 26 Jul 2013 19:06:52 +0530
Subject: [PATCH V2 8/8] ARM: dts: Enable sound support on smdk5420
In-Reply-To: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
Message-ID: <1374845812-7803-9-git-send-email-padma.v@samsung.com>

This patch enables i2s0 and sound support on smdk5420.

Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
---
 arch/arm/boot/dts/exynos5420-smdk5420.dts |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 28a6855..a5a2c2f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -118,4 +118,14 @@
 		};
 	};
 
+	i2s0: i2s at 03830000 {
+		status = "okay";
+	};
+
+	sound {
+		compatible = "samsung,smdk-wm8994";
+
+		samsung,i2s-controller = <&i2s0>;
+		samsung,audio-codec = <&wm8994>;
+	};
 };
-- 
1.7.4.4



From linux at arm.linux.org.uk  Fri Jul 26 09:38:02 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 14:38:02 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726132709.GH29916@titan.lakedaemon.net>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy> <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy> <20130726132709.GH29916@titan.lakedaemon.net>
Message-ID: <20130726133802.GN24642@n2100.arm.linux.org.uk>

On Fri, Jul 26, 2013 at 09:27:09AM -0400, Jason Cooper wrote:
> On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
> > Unless I totally misunderstood, the thread is talking about letting
> > established bindings change with each new kernel version.  I am
> > opposed to that.
> > 
> > Of course, a user may want to change the values of his MAC addresses,
> > if he needs to. But he should never have to change *how* he specifies
> > those addresses.
> 
> The other dynamic change that bears mentioning here is attributes which
> have been configured by the bootloader.  For example, in mvebu, we have
> the Schrodinger's Cat register.  It allows you to reconfigure the base
> address of the registers from *within* that register range.  If the
> bootloader does this, the DT needs to be updated to reflect the current
> hardware configuration.  Otherwise, the kernel is stuck poking around at
> memory addresses hoping to find something sane.
> 
> But this falls into the same category as you mentioned, but outside of
> chosen {};.

No, this falls within the remit of "describing the hardware" and it is
certainly something that is free to change.

What should not "change" once a kernel is the method by which hardware is
described in DT.  "change" there in the sense that how it was described by
kernel 3.X should still be accepted by 3.X+n, even if 3.X+n comes up with
a much better way to describe it.

The actual data associated with those descriptions is free to change in
whatever way is necessary if the hardware itself changes due to things
being programmed differently.

Think of it as the difference between the design of an interface, and the
interface being used.  We don't mandate that the write() syscall shall
always be called for fd=1 with length=5 and bytes "Hello" in the buffer.
We mandate that the write() syscall shall be passed an integer fd, a
buffer pointer, and a length and we don't change that ever.

Think of "a better way to describe it" as introducing the writev() syscall
to supplement write() so that applications can do writes from scattered
memory locations.  We don't get rid of the write() syscall - we add to
the ABI that's already there leaving the existing interfaces with exactly
the same semantics, so that all the existing stuff continues to work as-is.


From dwmw2 at infradead.org  Fri Jul 26 09:41:10 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 26 Jul 2013 14:41:10 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726132709.GH29916@titan.lakedaemon.net>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726132709.GH29916@titan.lakedaemon.net>
Message-ID: <1374846070.14574.92.camel@i7.infradead.org>

On Fri, 2013-07-26 at 09:27 -0400, Jason Cooper wrote:
> 
> The other dynamic change that bears mentioning here is attributes which
> have been configured by the bootloader.  For example, in mvebu, we have
> the Schrodinger's Cat register.  It allows you to reconfigure the base
> address of the registers from *within* that register range.  If the
> bootloader does this, the DT needs to be updated to reflect the current
> hardware configuration.  Otherwise, the kernel is stuck poking around at
> memory addresses hoping to find something sane.
> 
> But this falls into the same category as you mentioned, but outside of
> chosen {};.

Yeah, /chosen was given as an example of stuff that's almost
*exclusively* "configuration" stuff.

But there's plenty outside there that can reasonably change.

It's OK to change the data, and of *course* the base address reported in
the DT should actually match reality *today*, if it changes on the fly.

It's not OK to change the *schema*  in which those data are expressed.
That's the ABI we're talking about.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/9f7f5720/attachment.bin>

From steve.capper at linaro.org  Fri Jul 26 09:40:48 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Fri, 26 Jul 2013 14:40:48 +0100
Subject: [PATCH 1/2] ARM: mm: Remove general hugetlb code from ARM.
In-Reply-To: <20130717154338.GI27948@arm.com>
References: <1374067574-32034-1-git-send-email-steve.capper@linaro.org>
 <1374067574-32034-2-git-send-email-steve.capper@linaro.org>
 <20130717154338.GI27948@arm.com>
Message-ID: <20130726134048.GA4255@linaro.org>

On Wed, Jul 17, 2013 at 04:43:38PM +0100, Catalin Marinas wrote:
> On Wed, Jul 17, 2013 at 02:26:13PM +0100, Steve Capper wrote:
> > General forms of huge_pte_alloc, huge_pte_offset and follow_huge_pmd
> > are now available in mm/hugetlb.c.
> > 
> > This patch removes the ARM copies of these functions and activates
> > the general ones by enabling:
> > CONFIG_ARCH_WANT_GENERAL_HUGETLB
> > 
> > Signed-off-by: Steve Capper <steve.capper at linaro.org>
> 
> Acked-by: Catalin Marinas <catalin.marinas at arm.com>

If no-one has any objections should I put this into Russell's
patch system?

Cheers,
-- 
Steve


From robherring2 at gmail.com  Fri Jul 26 09:42:58 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 26 Jul 2013 08:42:58 -0500
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130726045433.GB4100@netboy>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy> <20130725213753.GC17616@obsidianresearch.com>
 <20130726045433.GB4100@netboy>
Message-ID: <51F27CE2.6050908@gmail.com>

On 07/25/2013 11:54 PM, Richard Cochran wrote:
> On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
> 
>> We use DT has a kernel configuration input. Our environment is
>> designed to guarantee 100% that the kernel and DT match exactly. DT
>> very deliberately isn't an ABI boundary in our systems.
> 
> It is nice that you use DT in that way, but that is not how DT is
> supposed to work. If you must keep your DT in sync with the kernel,
> then there is no advantage over the old platfrom device method. At
> least that had the virtue of being a C language interface (ABI), and
> some mistakes were be caught by the compiler.

I agree, but there is one advantage in that how the data in the DT is
described is unified. Before, how every platform defined and created
devices was slightly different. Now you know where to go look and don't
have things all over the place and hidden by custom macros. We could
have fixed all that in C without DT, but DT conversion forced the clean-up.

>> We've been doing this for years and have a proven in the field track
>> record of upgrades from pre-2.6.16 to 3.7 and beyond with multiple
>> SOCs. The same bootloader that was shipped to support non-DT 2.6.16
>> boots DT 3.7 just fine.
> 
> Try that with Freescale PowerPCs.  Good luck.
> 
> Heck, even Paul's OMAP test reports have been spoiled by his not
> deleting old dtb files. Of course, that is his fault (and not DT's, no
> never).
>  
>> For closed system embedded DT has proven *WONDERFUL*.
> 
> I too work on commercial embedded systems, and DT has proven to be
> one gigantic *PITA*.

Due to ABI breakage or other reasons?

Rob



From jason at lakedaemon.net  Fri Jul 26 09:45:51 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 26 Jul 2013 09:45:51 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726133802.GN24642@n2100.arm.linux.org.uk>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726132709.GH29916@titan.lakedaemon.net>
 <20130726133802.GN24642@n2100.arm.linux.org.uk>
Message-ID: <20130726134551.GI29916@titan.lakedaemon.net>

On Fri, Jul 26, 2013 at 02:38:02PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 09:27:09AM -0400, Jason Cooper wrote:
> > On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
> > > Unless I totally misunderstood, the thread is talking about letting
> > > established bindings change with each new kernel version.  I am
> > > opposed to that.
> > > 
> > > Of course, a user may want to change the values of his MAC addresses,
> > > if he needs to. But he should never have to change *how* he specifies
> > > those addresses.
> > 
> > The other dynamic change that bears mentioning here is attributes which
> > have been configured by the bootloader.  For example, in mvebu, we have
> > the Schrodinger's Cat register.  It allows you to reconfigure the base
> > address of the registers from *within* that register range.  If the
> > bootloader does this, the DT needs to be updated to reflect the current
> > hardware configuration.  Otherwise, the kernel is stuck poking around at
> > memory addresses hoping to find something sane.
> > 
> > But this falls into the same category as you mentioned, but outside of
> > chosen {};.
> 
> No, this falls within the remit of "describing the hardware" and it is
> certainly something that is free to change.

We agree, I was just highlighting that attributes outside of chosen can
and need to be rewritten by the bootloader.

> What should not "change" once a kernel is the method by which hardware is
> described in DT.  "change" there in the sense that how it was described by
> kernel 3.X should still be accepted by 3.X+n, even if 3.X+n comes up with
> a much better way to describe it.
> 
> The actual data associated with those descriptions is free to change in
> whatever way is necessary if the hardware itself changes due to things
> being programmed differently.
> 
> Think of it as the difference between the design of an interface, and the
> interface being used.  We don't mandate that the write() syscall shall
> always be called for fd=1 with length=5 and bytes "Hello" in the buffer.
> We mandate that the write() syscall shall be passed an integer fd, a
> buffer pointer, and a length and we don't change that ever.
> 
> Think of "a better way to describe it" as introducing the writev() syscall
> to supplement write() so that applications can do writes from scattered
> memory locations.  We don't get rid of the write() syscall - we add to
> the ABI that's already there leaving the existing interfaces with exactly
> the same semantics, so that all the existing stuff continues to work as-is.

Yes, the manner in which the bootloader writes the changes should adhere
to the binding.  In my example, it shouldn't replace the reg property
with reg-mod.  It should just change the addresses to reflect the
current state of the hardware the kernel will see.

thx,

Jason.


From jason at lakedaemon.net  Fri Jul 26 09:47:20 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 26 Jul 2013 09:47:20 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <1374846070.14574.92.camel@i7.infradead.org>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726132709.GH29916@titan.lakedaemon.net>
 <1374846070.14574.92.camel@i7.infradead.org>
Message-ID: <20130726134720.GJ29916@titan.lakedaemon.net>

On Fri, Jul 26, 2013 at 02:41:10PM +0100, David Woodhouse wrote:
> On Fri, 2013-07-26 at 09:27 -0400, Jason Cooper wrote:
> > 
> > The other dynamic change that bears mentioning here is attributes which
> > have been configured by the bootloader.  For example, in mvebu, we have
> > the Schrodinger's Cat register.  It allows you to reconfigure the base
> > address of the registers from *within* that register range.  If the
> > bootloader does this, the DT needs to be updated to reflect the current
> > hardware configuration.  Otherwise, the kernel is stuck poking around at
> > memory addresses hoping to find something sane.
> > 
> > But this falls into the same category as you mentioned, but outside of
> > chosen {};.
> 
> Yeah, /chosen was given as an example of stuff that's almost
> *exclusively* "configuration" stuff.
> 
> But there's plenty outside there that can reasonably change.
> 
> It's OK to change the data, and of *course* the base address reported in
> the DT should actually match reality *today*, if it changes on the fly.
> 
> It's not OK to change the *schema*  in which those data are expressed.
> That's the ABI we're talking about.

Agreed, much more clear than what I was saying.

thx,

Jason.


From will.deacon at arm.com  Fri Jul 26 09:49:20 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 26 Jul 2013 14:49:20 +0100
Subject: [PATCH 1/2] ARM: mm: Remove general hugetlb code from ARM.
In-Reply-To: <20130726134048.GA4255@linaro.org>
References: <1374067574-32034-1-git-send-email-steve.capper@linaro.org>
 <1374067574-32034-2-git-send-email-steve.capper@linaro.org>
 <20130717154338.GI27948@arm.com> <20130726134048.GA4255@linaro.org>
Message-ID: <20130726134920.GE17886@mudshark.cambridge.arm.com>

On Fri, Jul 26, 2013 at 02:40:48PM +0100, Steve Capper wrote:
> On Wed, Jul 17, 2013 at 04:43:38PM +0100, Catalin Marinas wrote:
> > On Wed, Jul 17, 2013 at 02:26:13PM +0100, Steve Capper wrote:
> > > General forms of huge_pte_alloc, huge_pte_offset and follow_huge_pmd
> > > are now available in mm/hugetlb.c.
> > > 
> > > This patch removes the ARM copies of these functions and activates
> > > the general ones by enabling:
> > > CONFIG_ARCH_WANT_GENERAL_HUGETLB
> > > 
> > > Signed-off-by: Steve Capper <steve.capper at linaro.org>
> > 
> > Acked-by: Catalin Marinas <catalin.marinas at arm.com>
> 
> If no-one has any objections should I put this into Russell's
> patch system?

Yes please.

Will


From pawel.moll at arm.com  Fri Jul 26 09:49:22 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Fri, 26 Jul 2013 14:49:22 +0100
Subject: [PATCH] ARM: socfpga: dts: Add support for SD/MMC
In-Reply-To: <1374789881-20611-1-git-send-email-dinguyen@altera.com>
References: <1374789881-20611-1-git-send-email-dinguyen@altera.com>
Message-ID: <1374846562.3213.56.camel@hornet>

Hello Ding,

Excuse me if the questions below were already asked and feel free to
point me at the appropriate mail archive...

On Thu, 2013-07-25 at 23:04 +0100, dinguyen at altera.com wrote:
> Add bindings for SD/MMC for SOCFPGA.
> Add "syscon" to the "altr,sys-mgr" binding.

Are those two related? As in: what does the "syscon" bit have to do with
"Add(ing) support for SD/MMC"? Should those two be separated?

> +* altr,dw-mshc-ciu-div: Specifies the divider value for the card interface
> +  unit (ciu) clock. The value should be (n-1). For Altera's SOCFPGA, the divider
> +  value is fixed at 3, which means parent_clock/4.

In what circumstances would this be different than 3? Is the interface
in question member of the "hard part" of the SOFPGA, or is it supposed
to be synthesized in the FPGA? 

> +* altr,dw-mshc-sdr-timing: Specifies the value of CIU clock phase shift value
> +  in transmit mode and CIU clock phase shift value in receive mode for single
> +  data rate mode operation. Refer to notes below for the order of the cells and the
> +  valid values.
> +
> +  Notes for the sdr-timing values:
> +
> +    The order of the cells should be
> +      - First Cell: CIU clock phase shift value for RX mode, smplsel bits in
> +	the system manager SDMMC control group.
> +      - Second Cell: CIU clock phase shift value for TX mode, drvsel bits in
> +	the system manager SDMMC control group.
> +
> +    Valid values for SDR CIU clock timing for SOCFPGA:
> +      - valid value for tx phase shift and rx phase shift is 0 to 7.

How does one pick those value? Do they depend on the board design? The
FPGA synthesis options?

I am not trying to be picky, just trying to establish if those value are
"hardware" enough to be present in the tree at all...

I've also noticed that Exynos defines almost identical bindings:

> samsung,dw-mshc-ciu-div
> samsung,dw-mshc-sdr-timing
> samsung,dw-mshc-ddr-timing

Aren't you both using the same "Synopsis Designware Mobile Storage Host
Controller" by any chance? Are you sharing a driver? And if not,
why? ;-) If the timings really must be parametrised, would it be
possible to come up with a common set of "synopsis" properties, instead
of "samsung" and "altr" ones? 

Thanks for your time!

Pawel




From dwmw2 at infradead.org  Fri Jul 26 09:50:53 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 26 Jul 2013 14:50:53 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726134551.GI29916@titan.lakedaemon.net>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726132709.GH29916@titan.lakedaemon.net>
 <20130726133802.GN24642@n2100.arm.linux.org.uk>
 <20130726134551.GI29916@titan.lakedaemon.net>
Message-ID: <1374846653.14574.96.camel@i7.infradead.org>

On Fri, 2013-07-26 at 09:45 -0400, Jason Cooper wrote:
> 
> We agree, I was just highlighting that attributes outside of chosen can
> and need to be rewritten by the bootloader.

Yes, absolutely. I had actually edited and re-ordered my message
<1374831744.2923.42.camel at shinybook.infradead.org> to try to make that
clearer by explicitly saying that the nodes which describe hardware
devices *can* change, before I ever made any mention of /chosen as
something which is almost *exclusively* dynamic.

Evidently that wasn't sufficient clarification. :)

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/93200ee8/attachment.bin>

From linux at arm.linux.org.uk  Fri Jul 26 09:53:57 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 14:53:57 +0100
Subject: [PATCH] constify machine_desc structure uses
Message-ID: <20130726135356.GO24642@n2100.arm.linux.org.uk>

struct machine_desc records are defined everywhere as a 'const'
structure, but unfortuantely it loses its const-ness through the use of
linker magic - the symbols which surround the section are not declared
const so it becomes possible not to use 'const' for pointers to these
const structures.

Let's fix this oversight - all pointers to these structures should be
marked const too.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/include/asm/mach/arch.h |    4 ++--
 arch/arm/include/asm/memblock.h  |    3 +--
 arch/arm/include/asm/prom.h      |    4 ++--
 arch/arm/kernel/atags.h          |    5 +++--
 arch/arm/kernel/atags_parse.c    |    6 +++---
 arch/arm/kernel/devtree.c        |    6 +++---
 arch/arm/kernel/setup.c          |   12 ++++++------
 arch/arm/mm/init.c               |    5 +++--
 arch/arm/mm/mmu.c                |    4 ++--
 arch/arm/mm/nommu.c              |    2 +-
 10 files changed, 26 insertions(+), 25 deletions(-)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 441efc4..69b879a 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -65,12 +65,12 @@ struct machine_desc {
 /*
  * Current machine - only accessible during boot.
  */
-extern struct machine_desc *machine_desc;
+extern const struct machine_desc *machine_desc;
 
 /*
  * Machine type table - also only accessible during boot
  */
-extern struct machine_desc __arch_info_begin[], __arch_info_end[];
+extern const struct machine_desc __arch_info_begin[], __arch_info_end[];
 #define for_each_machine_desc(p)			\
 	for (p = __arch_info_begin; p < __arch_info_end; p++)
 
diff --git a/arch/arm/include/asm/memblock.h b/arch/arm/include/asm/memblock.h
index 00ca5f9..c2f5102 100644
--- a/arch/arm/include/asm/memblock.h
+++ b/arch/arm/include/asm/memblock.h
@@ -4,8 +4,7 @@
 struct meminfo;
 struct machine_desc;
 
-extern void arm_memblock_init(struct meminfo *, struct machine_desc *);
-
+void arm_memblock_init(struct meminfo *, const struct machine_desc *);
 phys_addr_t arm_memblock_steal(phys_addr_t size, phys_addr_t align);
 
 #endif
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
index a219227..4a2985e 100644
--- a/arch/arm/include/asm/prom.h
+++ b/arch/arm/include/asm/prom.h
@@ -15,13 +15,13 @@
 
 #ifdef CONFIG_OF
 
-extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
+extern const struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
 extern void arm_dt_memblock_reserve(void);
 extern void __init arm_dt_init_cpu_maps(void);
 
 #else /* CONFIG_OF */
 
-static inline struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
+static inline const struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
 {
 	return NULL;
 }
diff --git a/arch/arm/kernel/atags.h b/arch/arm/kernel/atags.h
index 9edc969..ec4164d 100644
--- a/arch/arm/kernel/atags.h
+++ b/arch/arm/kernel/atags.h
@@ -7,9 +7,10 @@ static inline void save_atags(struct tag *tags) { }
 void convert_to_tag_list(struct tag *tags);
 
 #ifdef CONFIG_ATAGS
-struct machine_desc *setup_machine_tags(phys_addr_t __atags_pointer, unsigned int machine_nr);
+const struct machine_desc *setup_machine_tags(phys_addr_t __atags_pointer,
+	unsigned int machine_nr);
 #else
-static inline struct machine_desc *
+static inline const struct machine_desc *
 setup_machine_tags(phys_addr_t __atags_pointer, unsigned int machine_nr)
 {
 	early_print("no ATAGS support: can't continue\n");
diff --git a/arch/arm/kernel/atags_parse.c b/arch/arm/kernel/atags_parse.c
index 14512e6..8c14de8 100644
--- a/arch/arm/kernel/atags_parse.c
+++ b/arch/arm/kernel/atags_parse.c
@@ -178,11 +178,11 @@ static void __init squash_mem_tags(struct tag *tag)
 			tag->hdr.tag = ATAG_NONE;
 }
 
-struct machine_desc * __init setup_machine_tags(phys_addr_t __atags_pointer,
-						unsigned int machine_nr)
+const struct machine_desc * __init
+setup_machine_tags(phys_addr_t __atags_pointer, unsigned int machine_nr)
 {
 	struct tag *tags = (struct tag *)&default_tags;
-	struct machine_desc *mdesc = NULL, *p;
+	const struct machine_desc *mdesc = NULL, *p;
 	char *from = default_command_line;
 
 	default_tags.mem.start = PHYS_OFFSET;
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 5859c8b..eae1976 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -176,10 +176,10 @@ void __init arm_dt_init_cpu_maps(void)
  * If a dtb was passed to the kernel in r2, then use it to choose the
  * correct machine_desc and to setup the system.
  */
-struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
+const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 {
 	struct boot_param_header *devtree;
-	struct machine_desc *mdesc, *mdesc_best = NULL;
+	const struct machine_desc *mdesc, *mdesc_best = NULL;
 	unsigned int score, mdesc_score = ~1;
 	unsigned long dt_root;
 	const char *model;
@@ -188,7 +188,7 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
 	MACHINE_END
 
-	mdesc_best = (struct machine_desc *)&__mach_desc_GENERIC_DT;
+	mdesc_best = &__mach_desc_GENERIC_DT;
 #endif
 
 	if (!dt_phys)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 63af9a7..8636299 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -72,10 +72,10 @@ static int __init fpe_setup(char *line)
 __setup("fpe=", fpe_setup);
 #endif
 
-extern void paging_init(struct machine_desc *desc);
+extern void paging_init(const struct machine_desc *desc);
 extern void sanity_check_meminfo(void);
 extern enum reboot_mode reboot_mode;
-extern void setup_dma_zone(struct machine_desc *desc);
+extern void setup_dma_zone(const struct machine_desc *desc);
 
 unsigned int processor_id;
 EXPORT_SYMBOL(processor_id);
@@ -139,7 +139,7 @@ EXPORT_SYMBOL(elf_platform);
 static const char *cpu_name;
 static const char *machine_name;
 static char __initdata cmd_line[COMMAND_LINE_SIZE];
-struct machine_desc *machine_desc __initdata;
+const struct machine_desc *machine_desc __initdata;
 
 static union { char c[4]; unsigned long l; } endian_test __initdata = { { 'l', '?', '?', 'b' } };
 #define ENDIANNESS ((char)endian_test.l)
@@ -607,7 +607,7 @@ static void __init setup_processor(void)
 
 void __init dump_machine_table(void)
 {
-	struct machine_desc *p;
+	const struct machine_desc *p;
 
 	early_print("Available machine support:\n\nID (hex)\tNAME\n");
 	for_each_machine_desc(p)
@@ -694,7 +694,7 @@ static int __init early_mem(char *p)
 }
 early_param("mem", early_mem);
 
-static void __init request_standard_resources(struct machine_desc *mdesc)
+static void __init request_standard_resources(const struct machine_desc *mdesc)
 {
 	struct memblock_region *region;
 	struct resource *res;
@@ -850,7 +850,7 @@ void __init hyp_mode_check(void)
 
 void __init setup_arch(char **cmdline_p)
 {
-	struct machine_desc *mdesc;
+	const struct machine_desc *mdesc;
 
 	setup_processor();
 	mdesc = setup_machine_fdt(__atags_pointer);
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 15225d8..2958e74 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -231,7 +231,7 @@ static void __init arm_adjust_dma_zone(unsigned long *size, unsigned long *hole,
 }
 #endif
 
-void __init setup_dma_zone(struct machine_desc *mdesc)
+void __init setup_dma_zone(const struct machine_desc *mdesc)
 {
 #ifdef CONFIG_ZONE_DMA
 	if (mdesc->dma_zone_size) {
@@ -335,7 +335,8 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size, phys_addr_t align)
 	return phys;
 }
 
-void __init arm_memblock_init(struct meminfo *mi, struct machine_desc *mdesc)
+void __init arm_memblock_init(struct meminfo *mi,
+	const struct machine_desc *mdesc)
 {
 	int i;
 
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 4f56617..56054ac 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1151,7 +1151,7 @@ void __init arm_mm_memblock_reserve(void)
  * called function.  This means you can't use any function or debugging
  * method which may touch any device, otherwise the kernel _will_ crash.
  */
-static void __init devicemaps_init(struct machine_desc *mdesc)
+static void __init devicemaps_init(const struct machine_desc *mdesc)
 {
 	struct map_desc map;
 	unsigned long addr;
@@ -1272,7 +1272,7 @@ static void __init map_lowmem(void)
  * paging_init() sets up the page tables, initialises the zone memory
  * maps, and sets up the zero page, bad page and bad page tables.
  */
-void __init paging_init(struct machine_desc *mdesc)
+void __init paging_init(const struct machine_desc *mdesc)
 {
 	void *zero_page;
 
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 1fa5010..34d4ab2 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -299,7 +299,7 @@ void __init sanity_check_meminfo(void)
  * paging_init() sets up the page tables, initialises the zone memory
  * maps, and sets up the zero page, bad page and bad page tables.
  */
-void __init paging_init(struct machine_desc *mdesc)
+void __init paging_init(const struct machine_desc *mdesc)
 {
 	early_trap_init((void *)CONFIG_VECTORS_BASE);
 	mpu_setup();



From broonie at kernel.org  Fri Jul 26 09:57:34 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Jul 2013 14:57:34 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in	device tree janitoring / cleanup?]
In-Reply-To: <20130725231848.GJ24642@n2100.arm.linux.org.uk>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
 <20130725193135.GT23879@titan.lakedaemon.net>
 <20130725231848.GJ24642@n2100.arm.linux.org.uk>
Message-ID: <20130726135734.GE9858@sirena.org.uk>

On Fri, Jul 26, 2013 at 12:18:48AM +0100, Russell King - ARM Linux wrote:

> It's actually extremely simple.  If the bindings are in development,
> they must not appear in a -final released kernel.  Anything that appears
> in a -final kernel becomes part of the ABI at that point.

Of course from that point of view there's also an argument that once
people have shipped something on a device or generally out of the review
process then we have to support it no matter how depressing their
choices may have been.
-------------- 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/20130726/09c3df80/attachment.sig>

From jason at lakedaemon.net  Fri Jul 26 09:59:04 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 26 Jul 2013 09:59:04 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <1374846653.14574.96.camel@i7.infradead.org>
References: <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726132709.GH29916@titan.lakedaemon.net>
 <20130726133802.GN24642@n2100.arm.linux.org.uk>
 <20130726134551.GI29916@titan.lakedaemon.net>
 <1374846653.14574.96.camel@i7.infradead.org>
Message-ID: <20130726135904.GK29916@titan.lakedaemon.net>

On Fri, Jul 26, 2013 at 02:50:53PM +0100, David Woodhouse wrote:
> On Fri, 2013-07-26 at 09:45 -0400, Jason Cooper wrote:
> > 
> > We agree, I was just highlighting that attributes outside of chosen can
> > and need to be rewritten by the bootloader.
> 
> Yes, absolutely. I had actually edited and re-ordered my message
> <1374831744.2923.42.camel at shinybook.infradead.org> to try to make that
> clearer by explicitly saying that the nodes which describe hardware
> devices *can* change, before I ever made any mention of /chosen as
> something which is almost *exclusively* dynamic.
> 
> Evidently that wasn't sufficient clarification. :)

It was, I just wanted to spell out an actual use-case for folks who are
new to devicetree.  Also, I was trying to gently poke everyone to take a
look at the mvebu-mbus binding Ezequiel just posted ;-)

Arnd Bergman and Jason Gunthorpe (and others) have reviewed it to death,
but with this new push for review by the devicetree maintainers, we
thought it best to repost it here (devicetree ml) before merging it.

thx,

Jason.


From steve.capper at linaro.org  Fri Jul 26 10:00:35 2013
From: steve.capper at linaro.org (Steve Capper)
Date: Fri, 26 Jul 2013 15:00:35 +0100
Subject: [PATCH 1/2] ARM: mm: Remove general hugetlb code from ARM.
In-Reply-To: <20130726134920.GE17886@mudshark.cambridge.arm.com>
References: <1374067574-32034-1-git-send-email-steve.capper@linaro.org>
 <1374067574-32034-2-git-send-email-steve.capper@linaro.org>
 <20130717154338.GI27948@arm.com> <20130726134048.GA4255@linaro.org>
 <20130726134920.GE17886@mudshark.cambridge.arm.com>
Message-ID: <20130726140034.GA4695@linaro.org>

On Fri, Jul 26, 2013 at 02:49:20PM +0100, Will Deacon wrote:
> On Fri, Jul 26, 2013 at 02:40:48PM +0100, Steve Capper wrote:
> > 
> > If no-one has any objections should I put this into Russell's
> > patch system?
> 
> Yes please.
> 
> Will

I've added it now, its reference is 7792/1.

Cheers,
-- 
Steve


From Dave.Martin at arm.com  Fri Jul 26 10:02:36 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Fri, 26 Jul 2013 15:02:36 +0100
Subject: [PATCH 4/4] ARM: kprobes-test: move to using a pointer to the
 title text
In-Reply-To: <1374786537-10726-5-git-send-email-ben.dooks@codethink.co.uk>
References: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374786537-10726-5-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <20130726140236.GB2282@localhost.localdomain>

On Thu, Jul 25, 2013 at 10:08:57PM +0100, Ben Dooks wrote:
> When testing the kprobes test code with BE8, there is either an
> issue with the linker or how the code is being built. The issue
> is with embedding the title text as the first part of the test.
> 
> Change to placing a pointer to .rodata with the text title in it
> for the test which seems to stop the issue of the alignment of
> the data following it being changed arbitrarily by the linker.
> 
> The proper thing to do here is to fix the linker, however this
> patch also makes the output much easier to read as there are no
> variable length data items here any more.

Can you elaborate?  I don't understand from this what problem you are
trying to solve.  Can you give a more concrete example?

It should be impossible for the linker to change the alignment of
anything _within_ an input section (bugs notwithstanding).

The assembler might be doing something unexpected, particularly
for Thumb kernels, but I don't know of any bug relating to this.

Cheers
---Dave

> 
> CC: Jon Medhurst <tixy at yxit.co.uk>
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---
>  arch/arm/kernel/kprobes-test.c |   12 +++++-------
>  arch/arm/kernel/kprobes-test.h |    6 ++++--
>  2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/kernel/kprobes-test.c b/arch/arm/kernel/kprobes-test.c
> index 6cfa04d..a915ac3 100644
> --- a/arch/arm/kernel/kprobes-test.c
> +++ b/arch/arm/kernel/kprobes-test.c
> @@ -111,9 +111,7 @@
>   *	@ TESTCASE_START
>   *	bl	__kprobes_test_case_start
>   *	@ start of inline data...
> - *	.ascii "mov r0, r7"	@ text title for test case
> - *	.byte	0
> - *	.align	2
> + *	.word	title_addr	 @ text title for test case
>   *
>   *	@ TEST_ARG_REG
>   *	.byte	ARG_TYPE_REG
> @@ -959,7 +957,7 @@ void __naked __kprobes_test_case_start(void)
>  	__asm__ __volatile__ (
>  		"stmdb	sp!, {r4-r11}				\n\t"
>  		"sub	sp, sp, #"__stringify(TEST_MEMORY_SIZE)"\n\t"
> -		"bic	r0, lr, #1  @ r0 = inline title string	\n\t"
> +		"bic	r0, lr, #3  @ r0 = inline title block	\n\t"
>  		"mov	r1, sp					\n\t"
>  		"bl	kprobes_test_case_start			\n\t"
>  		"bx	r0					\n\t"
> @@ -1336,15 +1334,15 @@ static unsigned long next_instruction(unsigned long pc)
>  	return pc + 4;
>  }
>  
> -static uintptr_t __used kprobes_test_case_start(const char *title, void *stack)
> +static uintptr_t __used kprobes_test_case_start(const char **title, void *stack)
>  {
>  	struct test_arg *args;
>  	struct test_arg_end *end_arg;
>  	unsigned long test_code;
>  
> -	args = (struct test_arg *)PTR_ALIGN(title + strlen(title) + 1, 4);
> +	args = (struct test_arg *)(title + 1);
>  
> -	current_title = title;
> +	current_title = *title;
>  	current_args = args;
>  	current_stack = stack;
>  
> diff --git a/arch/arm/kernel/kprobes-test.h b/arch/arm/kernel/kprobes-test.h
> index e28a869..a71db09 100644
> --- a/arch/arm/kernel/kprobes-test.h
> +++ b/arch/arm/kernel/kprobes-test.h
> @@ -113,9 +113,11 @@ struct test_arg_end {
>  	"bl	__kprobes_test_case_start		\n\t"	\
>  	/* don't use .asciz here as 'title' may be */		\
>  	/* multiple strings to be concatenated.  */		\
> -	".ascii "#title"				\n\t"	\
> +	".pushsection .rodata				\n\t"	\
> +	"9999: .ascii "#title"				\n\t"	\
>  	".byte	0					\n\t"	\
> -	".align	2					\n\t"
> +	".popsection					\n\t"	\
> +	".word	9999b					\n\t"
>  
>  #define	TEST_ARG_REG(reg, val)					\
>  	".byte	"__stringify(ARG_TYPE_REG)"		\n\t"	\
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From jonas.jensen at gmail.com  Fri Jul 26 10:03:38 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Fri, 26 Jul 2013 16:03:38 +0200
Subject: [PATCH] ARM: clocksource: moxart: add bitops.h include
In-Reply-To: <51EB0265.2030508@linaro.org>
References: <51EB0265.2030508@linaro.org>
Message-ID: <1374847418-21436-1-git-send-email-jonas.jensen@gmail.com>

bitops.h included implicitly, add #include <linux/bitops.h>

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Hi Daniel,
    
    A separate patch for moxart clocksource (already merged), as you requested.
    
    Can be applied directly to timers/clockevents-next.
    
    Best regards,
    Jonas

 drivers/clocksource/moxart_timer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/moxart_timer.c b/drivers/clocksource/moxart_timer.c
index 08a5943..5eb2c35 100644
--- a/drivers/clocksource/moxart_timer.c
+++ b/drivers/clocksource/moxart_timer.c
@@ -20,6 +20,7 @@
 #include <linux/of_irq.h>
 #include <linux/io.h>
 #include <linux/clocksource.h>
+#include <linux/bitops.h>
 
 #define TIMER1_BASE		0x00
 #define TIMER2_BASE		0x10
-- 
1.8.2.1



From pawel.moll at arm.com  Fri Jul 26 10:06:04 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Fri, 26 Jul 2013 15:06:04 +0100
Subject: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
In-Reply-To: <CAF6AEGtspnhSGNM4_QQubVfOkZ1Gh1-Z3iyHOLBPVWuqRy81ew@mail.gmail.com>
References: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com>
 <CAF6AEGtspnhSGNM4_QQubVfOkZ1Gh1-Z3iyHOLBPVWuqRy81ew@mail.gmail.com>
Message-ID: <1374847564.3213.70.camel@hornet>

On Thu, 2013-07-25 at 19:21 +0100, Rob Clark wrote:
> >  * Only supports 640x480 mode, which is hard-coded. We intend to
> >    rebase on top of CDF once it is merged, which hopefully will
> >    handle a lot of the EDID parsing & mode setting for us (once
> >    Pawel's CDF patches for VExpress also land).
> 
> note that drm core already handles EDID parsing quite nicely.. I'm not
> entirely sure why CDF would be needed for this?
>
> What is the dependency on CDF?  Is there an external encoder/bridge
> that could be shared between platforms?

By all means. The platform we have here at ARM - Versatile Express - has
a pretty generic idea of "multimedia bus", carrying a set of RGB pixel
data and digital audio. There are three possible source of those: an
FPGA on the motherboard and two daughterboards which can take random
combination of FPGAs or test chips. In other words: the pixel data can
be generated by anything. And some of those things can be driven by
existing fbdev drivers. Now Tom is trying to make the most modern driver
for the oldest of the things ;-)

So that's about sources. All of them are connected to yet another FPGA
which acts as a muxer (switch if you wish). And from there things are
fed to SiI9022 HDMI/DVI formatter which is pretty common in the
"embedded world". In other words: loads of other fbdev-driven display
controllers are driving them as well (googling for sii9022 reveals at
least 3 different more or less custom drivers for it). And this chip is
also a reason Tom mentioned EDID. In order to get (just access, not even
parse) it we must jump through hoops - the chip acts as a I2C master
itself and must be kindly asked to switch into a sort of I2C bridge
mode.

So yes, the display pipeline is exactly straight-forward...

> btw, I think that having some share-able KMS objects is a good idea.
> I'm not entirely sure that the directions that the current CDF
> proposals are headed is necessarily the right way forward.  I'd prefer
> to see small/incremental evolution of KMS (ie. add drm_bridge and
> drm_panel, and refactor the existing encoder-slave).  Keeping it
> inside drm means that we can evolve it more easily, and avoid layers
> of glue code for no good reason.

To keep the story short - I'm a great enthusiast of CDF because it
caters for both DRM *and* fbdev. Today. I'm looking forward to the day
when the last fbdev driver is kicked off the kernel, but it doesn't look
like happening soon. At the same time I couldn't care less about naming,
so if you prefer to call it drm_panel (but keep the API abstract enough
so non-DRM drivers can use them as well) - it's fine for me :-) There
are already generic mode/timing structures and DT bidnings available
(with helpers for the interesting parties), so this doesn't seem like a
unreasonable request?

Cheers!

Pawel




From linux at arm.linux.org.uk  Fri Jul 26 10:06:18 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 15:06:18 +0100
Subject: [PATCH V2 2/8] ASoC: Samsung: I2S: Add quirks as driver data
 in I2S
In-Reply-To: <1374845812-7803-3-git-send-email-padma.v@samsung.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-3-git-send-email-padma.v@samsung.com>
Message-ID: <20130726140618.GP24642@n2100.arm.linux.org.uk>

On Fri, Jul 26, 2013 at 07:06:46PM +0530, Padmavathi Venna wrote:
> -- compatible : "samsung,i2s-v5"
> +- compatible : should be one of the following.
> +   - samsung,s3c6410-i2s: for 8/16/24bit stereo I2S. Previous versions
> +     has only 8/16bit support.
> +   - samsung,s3c6410-i2sv4: for 8/16/24bit multichannel(5.1 channel) I2S.
> +     Introduced in s3c6410. This also applicable for s5p64x0 platforms.
> +   - samsung,s5pc100-i2s: for 8/16/24bit multichannel(5.1 channel) I2S
> +     with secondary fifo and s/w reset control.
> +   - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with
> +     secondary fifo, s/w reset control and internal mux for root clk src.
> +

So what happens with your changes to everyone who is using a DT file with
the "samsung,i2s-v5" compatible string?


From dwmw2 at infradead.org  Fri Jul 26 10:08:33 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 26 Jul 2013 15:08:33 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726113809.GB29916@titan.lakedaemon.net>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
 <20130725193135.GT23879@titan.lakedaemon.net>
 <20130725231848.GJ24642@n2100.arm.linux.org.uk>
 <CAKON4OwwOnP9kbN0JqR5L+F1svTucAQvz0RDwqU+Gy9UAFwHog@mail.gmail.com>
 <20130726113809.GB29916@titan.lakedaemon.net>
Message-ID: <1374847713.14574.100.camel@i7.infradead.org>

On Fri, 2013-07-26 at 07:38 -0400, Jason Cooper wrote:
> > The scheme is also quite useful for new tree developers since it will
> > show them the universe of device tree attributes that have already
> > been standardized. By using comments, you could probably turn the
> > device tree documentation into the schema source files.
> 
> One more note on schema, since DT is a description of hardware, it would
> be useful to have two comments, a url to the datasheet, and a canonical
> name of the datasheet suitable for $searchengine.  Where available, of
> course.

Yes, that's a very good idea. After all, the behaviour described in (a
specific version of) the datasheet is an *implicit* part of the DT
binding. If I tell you "there is an 8390 <here>", then we damn well
ought to agree about how an 8390 behaves. And what revision of the chip
can be assumed from a given 'compatible' string.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/88a97073/attachment.bin>

From ben.dooks at codethink.co.uk  Fri Jul 26 10:08:34 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Fri, 26 Jul 2013 15:08:34 +0100
Subject: [PATCH 4/4] ARM: kprobes-test: move to using a pointer to the
 title text
In-Reply-To: <20130726140236.GB2282@localhost.localdomain>
References: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374786537-10726-5-git-send-email-ben.dooks@codethink.co.uk>
 <20130726140236.GB2282@localhost.localdomain>
Message-ID: <51F282E2.8020802@codethink.co.uk>

On 26/07/13 15:02, Dave Martin wrote:
> On Thu, Jul 25, 2013 at 10:08:57PM +0100, Ben Dooks wrote:
>> When testing the kprobes test code with BE8, there is either an
>> issue with the linker or how the code is being built. The issue
>> is with embedding the title text as the first part of the test.
>>
>> Change to placing a pointer to .rodata with the text title in it
>> for the test which seems to stop the issue of the alignment of
>> the data following it being changed arbitrarily by the linker.
>>
>> The proper thing to do here is to fix the linker, however this
>> patch also makes the output much easier to read as there are no
>> variable length data items here any more.
>
> Can you elaborate?  I don't understand from this what problem you are
> trying to solve.  Can you give a more concrete example?
>
> It should be impossible for the linker to change the alignment of
> anything _within_ an input section (bugs notwithstanding).
>
> The assembler might be doing something unexpected, particularly
> for Thumb kernels, but I don't know of any bug relating to this.

The output in vmlinux looked ok, but there was some weird problems
with some of the structures ending up un-swapped and some swapped.

I do not have a concrete example of this as I didn't have time to
work out exactly what was happening to the binary when it was being
produced.

Placing the strings in the .rodata section seemed to fix the whole
issue which allowed me to turn the kprobes test on without them
blowing up due to mis-reading their list of actions.

> Cheers
> ---Dave
>
>>
>> CC: Jon Medhurst<tixy at yxit.co.uk>
>> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
>> ---
>>   arch/arm/kernel/kprobes-test.c |   12 +++++-------
>>   arch/arm/kernel/kprobes-test.h |    6 ++++--
>>   2 files changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/kernel/kprobes-test.c b/arch/arm/kernel/kprobes-test.c
>> index 6cfa04d..a915ac3 100644
>> --- a/arch/arm/kernel/kprobes-test.c
>> +++ b/arch/arm/kernel/kprobes-test.c
>> @@ -111,9 +111,7 @@
>>    *	@ TESTCASE_START
>>    *	bl	__kprobes_test_case_start
>>    *	@ start of inline data...
>> - *	.ascii "mov r0, r7"	@ text title for test case
>> - *	.byte	0
>> - *	.align	2
>> + *	.word	title_addr	 @ text title for test case
>>    *
>>    *	@ TEST_ARG_REG
>>    *	.byte	ARG_TYPE_REG
>> @@ -959,7 +957,7 @@ void __naked __kprobes_test_case_start(void)
>>   	__asm__ __volatile__ (
>>   		"stmdb	sp!, {r4-r11}				\n\t"
>>   		"sub	sp, sp, #"__stringify(TEST_MEMORY_SIZE)"\n\t"
>> -		"bic	r0, lr, #1  @ r0 = inline title string	\n\t"
>> +		"bic	r0, lr, #3  @ r0 = inline title block	\n\t"
>>   		"mov	r1, sp					\n\t"
>>   		"bl	kprobes_test_case_start			\n\t"
>>   		"bx	r0					\n\t"
>> @@ -1336,15 +1334,15 @@ static unsigned long next_instruction(unsigned long pc)
>>   	return pc + 4;
>>   }
>>
>> -static uintptr_t __used kprobes_test_case_start(const char *title, void *stack)
>> +static uintptr_t __used kprobes_test_case_start(const char **title, void *stack)
>>   {
>>   	struct test_arg *args;
>>   	struct test_arg_end *end_arg;
>>   	unsigned long test_code;
>>
>> -	args = (struct test_arg *)PTR_ALIGN(title + strlen(title) + 1, 4);
>> +	args = (struct test_arg *)(title + 1);
>>
>> -	current_title = title;
>> +	current_title = *title;
>>   	current_args = args;
>>   	current_stack = stack;
>>
>> diff --git a/arch/arm/kernel/kprobes-test.h b/arch/arm/kernel/kprobes-test.h
>> index e28a869..a71db09 100644
>> --- a/arch/arm/kernel/kprobes-test.h
>> +++ b/arch/arm/kernel/kprobes-test.h
>> @@ -113,9 +113,11 @@ struct test_arg_end {
>>   	"bl	__kprobes_test_case_start		\n\t"	\
>>   	/* don't use .asciz here as 'title' may be */		\
>>   	/* multiple strings to be concatenated.  */		\
>> -	".ascii "#title"				\n\t"	\
>> +	".pushsection .rodata				\n\t"	\
>> +	"9999: .ascii "#title"				\n\t"	\
>>   	".byte	0					\n\t"	\
>> -	".align	2					\n\t"
>> +	".popsection					\n\t"	\
>> +	".word	9999b					\n\t"
>>
>>   #define	TEST_ARG_REG(reg, val)					\
>>   	".byte	"__stringify(ARG_TYPE_REG)"		\n\t"	\
>> --
>> 1.7.10.4
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From broonie at kernel.org  Fri Jul 26 10:10:16 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Jul 2013 15:10:16 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726130927.GC4219@netboy>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
Message-ID: <20130726141016.GF9858@sirena.org.uk>

On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:

> Unless I totally misunderstood, the thread is talking about letting
> established bindings change with each new kernel version.  I am
> opposed to that.

No, nobody is really saying that is a particularly good idea.  There is
some debate about how we work out what an established binding is but
there's no serious suggestion that we don't want stable bindings.
-------------- 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/20130726/b4884404/attachment.sig>

From richard.genoud at gmail.com  Fri Jul 26 10:10:56 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Fri, 26 Jul 2013 16:10:56 +0200
Subject: [PATCH v2 00/42] ARM: at91: move to common clk framework
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <51F28370.6050304@gmail.com>

On 17/07/2013 15:34, Boris BREZILLON wrote:
> Hello,
> 
> This patch series is a proposal to move at91 clock implementation
> to common clk framework.
> 
> Most of the clock provided by the PMC (Power Management Controller) are
> implemented :
> - main clock (main oscillator)
> - pll clocks
> - master clock
> - programmable clocks
> - utmi clock
> - peripheral clocks
> - system clocks
> 
> This implementation is compatible with device tree: the goal is
> to define the whole clock tree in the device tree (all currently
> available dt SoCs and boards are patched to support dt clocks).
> Please feel free to comment the dt bindinds.
> 
> I removed the register_clocks function in SoC supporting dt boards only:
> - at91sam9x5 SoCs
> - at91sam9n12 SoC
> - sama5d3 SoCs
> 
> This patch series is based on linux-next and has been tested on sama5d31ek
> board using device tree. It compiles for other SoCs and both with and without
> dt support, but it has not been tested.
> 
> BTW could other people test it on other boards (I only have a kizbox and
> a sama5d31ek dev kit).
> 
> Best Regards,
> Boris
> 
> Changes since v1:
>  - fix bugs in pll, programmable and system clock implementations
>    (wrong bit position).
>  - add usb clock configuration support (ohci and udc drivers +
>    clk_lookup for non dt boards)
>  - rework of the system clock interfaces (no need to define a parent clock,
>    system clock is a gate with no rate info)
>  - change system, peripheral and programmable clk dt bindings (1 master node
>    and multiple child nodes each defining a system/peripheral or prog clock)
>  - fix bugs in sama5 dt definition
> 
Hi Boris,

First of all: Big thumbs up for this work !

Then, I tested the serie on at91sam9g35ek (sam9x5 familly), and I see some problems:
kernel is next-20130725 with the v4 serie of "ARM: at91: prepare transition to common clk framework"
and v2 serie of "ARM: at91: move to common clk framework"

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.11.0-rc2-next-20130725+ (rgenoud at lnx-rg) (gcc version 4.7.3 (Buildroot 2013.05-00157-g6d1e60b-dirty) ) #61 Fri Jul 26 15:30:13 CEST 2013
[    0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine: Atmel AT91SAM (Device Tree), model: Atmel AT91SAM9G35-EK
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] AT91: Detected soc type: at91sam9x5
[    0.000000] AT91: Detected soc subtype: at91sam9g35
[    0.000000] AT91: sram at 0x300000 of 0x8000 mapped at 0xfef70000
[    0.000000] On node 0 totalpages: 32768
[    0.000000] free_area_init_node: node 0, pgdat c039d208, node_mem_map c03b5000
[    0.000000]   Normal zone: 256 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 32768 pages, LIFO batch:7
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
[    0.000000] Kernel command line: console=ttyS0,115200 loglevel=8 ip=dhcp root=/dev/nfs nfsroot=10.128.0.9:/nfsroot,v3 rw earlyprintk
[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Memory: 126044K/131072K available (2804K kernel code, 126K rwdata, 592K rodata, 141K init, 93K bss, 5028K reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0359550   (3398 kB)
[    0.000000]       .init : 0xc035a000 - 0xc037d61c   ( 142 kB)
[    0.000000]       .data : 0xc037e000 - 0xc039d920   ( 127 kB)
[    0.000000]        .bss : 0xc039d920 - 0xc03b4ff4   (  94 kB)
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] AT91: PIT: mck rate = 0
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at arch/arm/mach-at91/at91sam926x_time.c:259 at91sam926x_pit_init+0x114/0x234()
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.0-rc2-next-20130725+ #61
[    0.000000] [<c000ca18>] (unwind_backtrace+0x0/0xe0) from [<c000b0f0>] (show_stack+0x10/0x14)
[    0.000000] [<c000b0f0>] (show_stack+0x10/0x14) from [<c00144e0>] (warn_slowpath_common+0x5c/0x7c)
[    0.000000] [<c00144e0>] (warn_slowpath_common+0x5c/0x7c) from [<c00145b8>] (warn_slowpath_null+0x18/0x1c)
[    0.000000] [<c00145b8>] (warn_slowpath_null+0x18/0x1c) from [<c03607b0>] (at91sam926x_pit_init+0x114/0x234)
[    0.000000] [<c03607b0>] (at91sam926x_pit_init+0x114/0x234) from [<c035ca4c>] (time_init+0x1c/0x24)
[    0.000000] [<c035ca4c>] (time_init+0x1c/0x24) from [<c035a650>] (start_kernel+0x19c/0x2f4)
[    0.000000] [<c035a650>] (start_kernel+0x19c/0x2f4) from [<20008040>] (0x20008040)
[    0.000000] ---[ end trace 1b75b31a2719ed1c ]---
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G        W    3.11.0-rc2-next-20130725+ #61
[    0.000000] [<c000ca18>] (unwind_backtrace+0x0/0xe0) from [<c000b0f0>] (show_stack+0x10/0x14)
[    0.000000] [<c000b0f0>] (show_stack+0x10/0x14) from [<c013f0a0>] (Ldiv0_64+0x8/0x18)
[    0.000000] [<c013f0a0>] (Ldiv0_64+0x8/0x18) from [<c003b864>] (__clocksource_updatefreq_scale+0x30/0x104)
[    0.000000] [<c003b864>] (__clocksource_updatefreq_scale+0x30/0x104) from [<c003b944>] (__clocksource_register_scale+0xc/0x48)
[    0.000000] [<c003b944>] (__clocksource_register_scale+0xc/0x48) from [<c0360810>] (at91sam926x_pit_init+0x174/0x234)
[    0.000000] [<c0360810>] (at91sam926x_pit_init+0x174/0x234) from [<c035ca4c>] (time_init+0x1c/0x24)
[    0.000000] [<c035ca4c>] (time_init+0x1c/0x24) from [<c035a650>] (start_kernel+0x19c/0x2f4)
[    0.000000] [<c035a650>] (start_kernel+0x19c/0x2f4) from [<20008040>] (0x20008040)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G        W    3.11.0-rc2-next-20130725+ #61
[    0.000000] [<c000ca18>] (unwind_backtrace+0x0/0xe0) from [<c000b0f0>] (show_stack+0x10/0x14)
[    0.000000] [<c000b0f0>] (show_stack+0x10/0x14) from [<c013f0a0>] (Ldiv0_64+0x8/0x18)
[    0.000000] [<c013f0a0>] (Ldiv0_64+0x8/0x18) from [<c003b76c>] (clocks_calc_mult_shift+0x70/0xa4)
[    0.000000] [<c003b76c>] (clocks_calc_mult_shift+0x70/0xa4) from [<c003b8e4>] (__clocksource_updatefreq_scale+0xb0/0x104)
[    0.000000] [<c003b8e4>] (__clocksource_updatefreq_scale+0xb0/0x104) from [<c003b944>] (__clocksource_register_scale+0xc/0x48)
[    0.000000] [<c003b944>] (__clocksource_register_scale+0xc/0x48) from [<c0360810>] (at91sam926x_pit_init+0x174/0x234)
[    0.000000] [<c0360810>] (at91sam926x_pit_init+0x174/0x234) from [<c035ca4c>] (time_init+0x1c/0x24)
[    0.000000] [<c035ca4c>] (time_init+0x1c/0x24) from [<c035a650>] (start_kernel+0x19c/0x2f4)
[    0.000000] [<c035a650>] (start_kernel+0x19c/0x2f4) from [<20008040>] (0x20008040)
[...]

Best regards,
Richard


From jonsmirl at gmail.com  Fri Jul 26 10:14:32 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Fri, 26 Jul 2013 10:14:32 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <1374846070.14574.92.camel@i7.infradead.org>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726132709.GH29916@titan.lakedaemon.net>
 <1374846070.14574.92.camel@i7.infradead.org>
Message-ID: <CAKON4OzrkHzUzKkULWCgiEpAtJ5gLxUm78R5ctd7p6trqq_gCA@mail.gmail.com>

On Fri, Jul 26, 2013 at 9:41 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Fri, 2013-07-26 at 09:27 -0400, Jason Cooper wrote:
>>
>> The other dynamic change that bears mentioning here is attributes which
>> have been configured by the bootloader.  For example, in mvebu, we have
>> the Schrodinger's Cat register.  It allows you to reconfigure the base
>> address of the registers from *within* that register range.  If the
>> bootloader does this, the DT needs to be updated to reflect the current
>> hardware configuration.  Otherwise, the kernel is stuck poking around at
>> memory addresses hoping to find something sane.
>>
>> But this falls into the same category as you mentioned, but outside of
>> chosen {};.
>
> Yeah, /chosen was given as an example of stuff that's almost
> *exclusively* "configuration" stuff.
>
> But there's plenty outside there that can reasonably change.
>
> It's OK to change the data, and of *course* the base address reported in
> the DT should actually match reality *today*, if it changes on the fly.
>
> It's not OK to change the *schema*  in which those data are expressed.
> That's the ABI we're talking about.

Yes, yes - that's why the schema should be written down and used as a
validation input to dtc. Then dtc can spit out errors for non-standard
items. There would be two versions - the standard one and a legacy one
that includes the standard one plus the hacks that can't be undone.

But more importantly it provides a framework for people creating new
node definitions. Now they can't work in a vacuum and come up with
random names and structure for everything.

Most of the problems express in the thread would go away if the schema
was written down and discussed. The rule going forward would be no new
nodes that aren't part of the standard schema.

>
> --
> dwmw2
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



-- 
Jon Smirl
jonsmirl at gmail.com


From linux at arm.linux.org.uk  Fri Jul 26 10:14:30 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 15:14:30 +0100
Subject: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
In-Reply-To: <CAF6AEGtspnhSGNM4_QQubVfOkZ1Gh1-Z3iyHOLBPVWuqRy81ew@mail.gmail.com>
References: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com>
 <CAF6AEGtspnhSGNM4_QQubVfOkZ1Gh1-Z3iyHOLBPVWuqRy81ew@mail.gmail.com>
Message-ID: <20130726141430.GQ24642@n2100.arm.linux.org.uk>

On Thu, Jul 25, 2013 at 02:21:59PM -0400, Rob Clark wrote:
> On Thu, Jul 25, 2013 at 1:17 PM,  <tom.cooksey at arm.com> wrote:
> > Known issues:
> >  * It uses KDS. We intend to switch to whatever implicit per-buffer
> >    synchronisation mechanism gets merged, once something is merged.
> >  * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
> >    allocate buffers for the GPU. Still not sure how to resolve this
> >    as we don't use DRM for our GPU driver.
> 
> any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
> once the dma-fence stuff is in place), we'd have gpu-specific drm
> (gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
> using prime/dmabuf to share between the two.

The PL111 primecell is just a scanout device.  It has no GPU embedded
in it.  It's just like the Armada/Dove DRM stuff - if a GPU is provided
it's an entirely separate piece of IP, and will likely remain a separate
non-DRM driver.

In the case of PL111, PL111 is not manufacturer specific so the GPU can
be any standalone GPU.


From dwmw2 at infradead.org  Fri Jul 26 10:16:39 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 26 Jul 2013 15:16:39 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <CAKON4OzrkHzUzKkULWCgiEpAtJ5gLxUm78R5ctd7p6trqq_gCA@mail.gmail.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726132709.GH29916@titan.lakedaemon.net>
 <1374846070.14574.92.camel@i7.infradead.org>
 <CAKON4OzrkHzUzKkULWCgiEpAtJ5gLxUm78R5ctd7p6trqq_gCA@mail.gmail.com>
Message-ID: <1374848199.14574.103.camel@i7.infradead.org>

On Fri, 2013-07-26 at 10:14 -0400, jonsmirl at gmail.com wrote:
> 
> Yes, yes - that's why the schema should be written down and used as a
> validation input to dtc. Then dtc can spit out errors for non-standard
> items. There would be two versions - the standard one and a legacy one
> that includes the standard one plus the hacks that can't be undone.
> 
> But more importantly it provides a framework for people creating new
> node definitions. Now they can't work in a vacuum and come up with
> random names and structure for everything.
> 
> Most of the problems express in the thread would go away if the schema
> was written down and discussed. The rule going forward would be no new
> nodes that aren't part of the standard schema.

Yes, that seems eminently sensible.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/27cb750a/attachment.bin>

From jonas.jensen at gmail.com  Fri Jul 26 10:17:15 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Fri, 26 Jul 2013 16:17:15 +0200
Subject: [PATCH] ARM: clocksource: moxart: documentation: update device tree
 bindings document
Message-ID: <1374848235-21734-1-git-send-email-jonas.jensen@gmail.com>

1. describe compatible variable "Must be" instead of "Should be".
2. change description so it's from the point of view of the device

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Hi Daniel,
    
    The device tree bindings document (already merged) needs another update.
    
    Can be applied directly to timers/clockevents-next.
    
    Best regards,
    Jonas

 Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt b/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt
index ad0bf7f..da2d510 100644
--- a/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt
+++ b/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt
@@ -2,10 +2,10 @@ MOXA ART timer
 
 Required properties:
 
-- compatible : Should be "moxa,moxart-timer"
+- compatible : Must be "moxa,moxart-timer"
 - reg : Should contain registers location and length
 - interrupts : Should contain the timer interrupt number
-- clocks : Should contain phandle for the MOXA ART core clock "coreclk"
+- clocks : Should contain phandle for the clock that drives the counter
 
 Example:
 
-- 
1.8.2.1



From t.figa at samsung.com  Fri Jul 26 10:21:16 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 26 Jul 2013 16:21:16 +0200
Subject: [PATCH V2 2/8] ASoC: Samsung: I2S: Add quirks as driver data	in
 I2S
In-Reply-To: <20130726140618.GP24642@n2100.arm.linux.org.uk>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-3-git-send-email-padma.v@samsung.com>
 <20130726140618.GP24642@n2100.arm.linux.org.uk>
Message-ID: <1479924.YVrWxe87Mh@amdc1227>

Hi Russell,

On Friday 26 of July 2013 15:06:18 Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 07:06:46PM +0530, Padmavathi Venna wrote:
> > -- compatible : "samsung,i2s-v5"
> > +- compatible : should be one of the following.
> > +   - samsung,s3c6410-i2s: for 8/16/24bit stereo I2S. Previous versions
> > +     has only 8/16bit support.
> > +   - samsung,s3c6410-i2sv4: for 8/16/24bit multichannel(5.1 channel)
> > I2S. +     Introduced in s3c6410. This also applicable for s5p64x0
> > platforms. +   - samsung,s5pc100-i2s: for 8/16/24bit multichannel(5.1
> > channel) I2S +     with secondary fifo and s/w reset control.
> > +   - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with
> > +     secondary fifo, s/w reset control and internal mux for root clk
> > src. +
> 
> So what happens with your changes to everyone who is using a DT file with
> the "samsung,i2s-v5" compatible string?

AFAIK we decided that current bindings, if broken, can be redone correctly, 
without caring for compatibility with old DTBs and only then, after 
reviewing these new bindings by DT people, they can be stabilized.

Other issue, though, is that this patch breaks things until they get fixed 
by patch 3. Support for new bindings should be added first, then users fixed 
and only then old bindings can be removed.

Best regards,
Tomasz



From robdclark at gmail.com  Fri Jul 26 10:21:55 2013
From: robdclark at gmail.com (Rob Clark)
Date: Fri, 26 Jul 2013 10:21:55 -0400
Subject: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
In-Reply-To: <1374847564.3213.70.camel@hornet>
References: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com>
 <CAF6AEGtspnhSGNM4_QQubVfOkZ1Gh1-Z3iyHOLBPVWuqRy81ew@mail.gmail.com>
 <1374847564.3213.70.camel@hornet>
Message-ID: <CAF6AEGtNEOpuKqcr7vfieCx0mot44L2bZzOt4ipcmUVv4FwUVw@mail.gmail.com>

On Fri, Jul 26, 2013 at 10:06 AM, Pawel Moll <pawel.moll at arm.com> wrote:
> On Thu, 2013-07-25 at 19:21 +0100, Rob Clark wrote:
>> >  * Only supports 640x480 mode, which is hard-coded. We intend to
>> >    rebase on top of CDF once it is merged, which hopefully will
>> >    handle a lot of the EDID parsing & mode setting for us (once
>> >    Pawel's CDF patches for VExpress also land).
>>
>> note that drm core already handles EDID parsing quite nicely.. I'm not
>> entirely sure why CDF would be needed for this?
>>
>> What is the dependency on CDF?  Is there an external encoder/bridge
>> that could be shared between platforms?
>
> By all means. The platform we have here at ARM - Versatile Express - has
> a pretty generic idea of "multimedia bus", carrying a set of RGB pixel
> data and digital audio. There are three possible source of those: an
> FPGA on the motherboard and two daughterboards which can take random
> combination of FPGAs or test chips. In other words: the pixel data can
> be generated by anything. And some of those things can be driven by
> existing fbdev drivers. Now Tom is trying to make the most modern driver
> for the oldest of the things ;-)
>
> So that's about sources. All of them are connected to yet another FPGA
> which acts as a muxer (switch if you wish). And from there things are
> fed to SiI9022 HDMI/DVI formatter which is pretty common in the
> "embedded world". In other words: loads of other fbdev-driven display
> controllers are driving them as well (googling for sii9022 reveals at
> least 3 different more or less custom drivers for it). And this chip is
> also a reason Tom mentioned EDID. In order to get (just access, not even
> parse) it we must jump through hoops - the chip acts as a I2C master
> itself and must be kindly asked to switch into a sort of I2C bridge
> mode.

btw, you might want to have a look at some of the existing i2c slave
encoders, since that sounds a lot like what the si9022 is.  There is
already drivers/gpu/drm/i2c/sil164_drv.c for some other SI part.  And
tda998x is another more recently added hdmi encoder/formatter (the
edid probing code in there might serve as a reasonable source of
inspiration)

> So yes, the display pipeline is exactly straight-forward...
>
>> btw, I think that having some share-able KMS objects is a good idea.
>> I'm not entirely sure that the directions that the current CDF
>> proposals are headed is necessarily the right way forward.  I'd prefer
>> to see small/incremental evolution of KMS (ie. add drm_bridge and
>> drm_panel, and refactor the existing encoder-slave).  Keeping it
>> inside drm means that we can evolve it more easily, and avoid layers
>> of glue code for no good reason.
>
> To keep the story short - I'm a great enthusiast of CDF because it
> caters for both DRM *and* fbdev. Today. I'm looking forward to the day
> when the last fbdev driver is kicked off the kernel, but it doesn't look
> like happening soon. At the same time I couldn't care less about naming,
> so if you prefer to call it drm_panel (but keep the API abstract enough
> so non-DRM drivers can use them as well) - it's fine for me :-) There
> are already generic mode/timing structures and DT bidnings available
> (with helpers for the interesting parties), so this doesn't seem like a
> unreasonable request?

Well, if you have something complex enough to benefit from CDF, then
you probably ought to be looking at drm/kms.  If someone wants to
somehow come up with some glue to re-use shareable drm/kms components
from fbdev, well.. I guess I don't really care about what goes in
fbdev.  My main concern is that we have more than enough work to do,
and have more than enough complexity.  If we end up w/ bunch of glue
to tie things in to drm properties, how drm helpers sequence things
during modeset, locking, etc.. I just don't see that turning out well.
 And also, just on the logistical side, having something shared across
subsystems makes changes more of a pain during the merge window.  Not
to mention backports to stable kernels, distro kernels, etc.  It all
just seems like it will be a lot of unnecessary headache.

> Cheers!
>
> Pawel
>
>


From t.figa at samsung.com  Fri Jul 26 10:22:44 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 26 Jul 2013 16:22:44 +0200
Subject: [PATCH V2 0/8] Add audio support on smdk5420
In-Reply-To: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
Message-ID: <3356470.kOAo7kipSf@amdc1227>

Hi Padmavathi,

On Friday 26 of July 2013 19:06:44 Padmavathi Venna wrote:
> Samsung has different versions of I2S introduced in different
> platforms. Each version has some new support added for multichannel,
> secondary fifo, s/w reset control, internal mux for rclk src clk and
> tdm support. Each newly added change has a quirk. So this patch adds
> all the required quirks as driver data and based on compatible string
> from dtsi fetches the quirks. This also adds i2s support on exynos5420
> and make relevent changes in the dtsi files.
> 
> Changes since V1:
> 	- Pass quirks as driver data and fetch the quirks based on
> 	  compatible string from dtsi file as suggested by
> 	  Tomasz Figa and Mark Brown
> 	- Make the I2S driver more flexible with respect to register
> 	  access as suggested by Tomasz Figa and Mark Brown
> 	- Add 5420 support in the driver.
> 	- Modify the dtsi files with the corresponding compatible
> 	  strings and removed the i2s quirks from 5250 dtsi file.
> 	- Updated the i2s Documentation with relevent changes and
> 	  i2s versioning info.
> 	- Add i2s nodes on exynos5420.dtsi
> 	- Enable sound support on smdk5420
> 
> This patch set is dependent on the following dma and audio subsystem
> clk controller patches.
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20661
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20668
> 
> This patch set is made based on Kukjin Kim for-next branch.
> 
> Andrew Bresticker (1):
>   ARM: dts: exynos5420: add i2s controllers
> 
> Padmavathi Venna (7):
>   platform: Increase platform name size
>   ASoC: Samsung: I2S: Add quirks as driver data in I2S
>   ARM: dts: Change i2s compatible string on exynos5250
>   ASoC: Samsung: I2S: Modify driver to give more flexibility
>   ASoC: Samsung: I2S: Modify the I2S driver to support I2S on
>     Exynos5420
>   ARM: dts: wm8994: Add wm8994 support on smdk5420
>   ARM: dts: Enable sound support on smdk5420
> 
>  .../devicetree/bindings/sound/samsung-i2s.txt      |   25 ++-
>  arch/arm/boot/dts/exynos5250.dtsi                  |    9 +-
>  arch/arm/boot/dts/exynos5420-smdk5420.dts          |   60 ++++++
>  arch/arm/boot/dts/exynos5420.dtsi                  |   44 +++++
>  include/linux/mod_devicetable.h                    |    2 +-
>  include/linux/platform_data/asoc-s3c.h             |    1 +
>  sound/soc/samsung/i2s-regs.h                       |   51 ++++--
>  sound/soc/samsung/i2s.c                            |  205
> +++++++++++++++----- 8 files changed, 312 insertions(+), 85 deletions(-)

Please resend the whole series again using correct devicetree mailing list, 
which is:

devicetree at vger.kernel.org

The old one (devicetree-discuss at lists.ozlabs.org) is no longer functioning.

Best regards,
Tomasz



From linux at arm.linux.org.uk  Fri Jul 26 10:21:40 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 15:21:40 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <CAKON4OzrkHzUzKkULWCgiEpAtJ5gLxUm78R5ctd7p6trqq_gCA@mail.gmail.com>
References: <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy> <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy> <20130726132709.GH29916@titan.lakedaemon.net>
 <1374846070.14574.92.camel@i7.infradead.org>
 <CAKON4OzrkHzUzKkULWCgiEpAtJ5gLxUm78R5ctd7p6trqq_gCA@mail.gmail.com>
Message-ID: <20130726142140.GR24642@n2100.arm.linux.org.uk>

On Fri, Jul 26, 2013 at 10:14:32AM -0400, jonsmirl at gmail.com wrote:
> Yes, yes - that's why the schema should be written down and used as a
> validation input to dtc. Then dtc can spit out errors for non-standard
> items. There would be two versions - the standard one and a legacy one
> that includes the standard one plus the hacks that can't be undone.
> 
> But more importantly it provides a framework for people creating new
> node definitions. Now they can't work in a vacuum and come up with
> random names and structure for everything.
> 
> Most of the problems express in the thread would go away if the schema
> was written down and discussed. The rule going forward would be no new
> nodes that aren't part of the standard schema.

So this is why I'm seeing patches just a short time ago removing existing
compatible strings from the DT descriptions and associated driver, and
replacing them with new ones... meaning that the old DT files won't work
with newer kernels.

What that means is using the descriptions as the schema won't catch that
because they're changing those as well to match.

There's a solution to that: dtc becomes a separate project external to
the kernel which also contains the schemas that it verifies against.
That way, if you want to make changes such as that above, you need to
get it past not only kernel people but also past dtc maintainers -
which increases the chances of such stuff being caught.


From robdclark at gmail.com  Fri Jul 26 10:24:54 2013
From: robdclark at gmail.com (Rob Clark)
Date: Fri, 26 Jul 2013 10:24:54 -0400
Subject: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
In-Reply-To: <20130726141430.GQ24642@n2100.arm.linux.org.uk>
References: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com>
 <CAF6AEGtspnhSGNM4_QQubVfOkZ1Gh1-Z3iyHOLBPVWuqRy81ew@mail.gmail.com>
 <20130726141430.GQ24642@n2100.arm.linux.org.uk>
Message-ID: <CAF6AEGubFuVO8DtGSgefRpc16mwOEVoV3hPjfNkVg48to6p2Jw@mail.gmail.com>

On Fri, Jul 26, 2013 at 10:14 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Thu, Jul 25, 2013 at 02:21:59PM -0400, Rob Clark wrote:
>> On Thu, Jul 25, 2013 at 1:17 PM,  <tom.cooksey at arm.com> wrote:
>> > Known issues:
>> >  * It uses KDS. We intend to switch to whatever implicit per-buffer
>> >    synchronisation mechanism gets merged, once something is merged.
>> >  * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>> >    allocate buffers for the GPU. Still not sure how to resolve this
>> >    as we don't use DRM for our GPU driver.
>>
>> any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
>> once the dma-fence stuff is in place), we'd have gpu-specific drm
>> (gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
>> using prime/dmabuf to share between the two.
>
> The PL111 primecell is just a scanout device.  It has no GPU embedded
> in it.  It's just like the Armada/Dove DRM stuff - if a GPU is provided
> it's an entirely separate piece of IP, and will likely remain a separate
> non-DRM driver.
>
> In the case of PL111, PL111 is not manufacturer specific so the GPU can
> be any standalone GPU.

Oh, yeah, I know PL111 is different block independent from GPU.  I
wasn't advocating adding mali support in this driver.  But instead
creating a mali DRM driver which had GEM and gpu bits, but not KMS.
Then buffer sharing w/ prime/dmabuf just like you would, for example
on a laptop w/ both integrated graphics and discrete GPU.

BR,
-R


From broonie at kernel.org  Fri Jul 26 10:27:24 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Jul 2013 15:27:24 +0100
Subject: XCLKOUT in exynos5250 clock driver
In-Reply-To: <51F2695B.8020109@gmail.com>
References: <20130725145158.GI9858@sirena.org.uk> <51F247B6.9010902@linaro.org>
 <51F2695B.8020109@gmail.com>
Message-ID: <20130726142724.GG9858@sirena.org.uk>

On Fri, Jul 26, 2013 at 02:19:39PM +0200, Sylwester Nawrocki wrote:
> On 07/26/2013 11:56 AM, Tushar Behera wrote:
> >On 07/25/2013 08:21 PM, Mark Brown wrote:

> >>I appear to be missing something in the clock driver for the exynos5250.
> >>I'm looking at the Arndale schematic and I see that the audio master

> This is something that's not yet supported in the mainline kernels I'm
> afraid.

I was trying to be polite :)

> I suspect that the same, you can easily verify that by checking what ball
> identifier corresponds to XCLKOUT pin and how the routing looks like on
> the schematics.

Right, for what it's worth it's ball AJ27 marked as XCLKOUT/ETC6_1

> We have a bit hackish patch that adds support for the CLKOUT at the
> Exynos4 clocks driver to enable the audio codec. An issue here is that the
> CLKOUT mux and divider control bitfield is in the PMU registers (as opposed
> to CMU where the clock  control registers normally are) and additionally
> single register contains the clock mux/divider bitfield as well as couple
> other unrelated control bits. Depending if those other bits are considered
> really important or not it it might another reason to expose (part of ?)
> PMU registers through syscon-like interface. There are registers in PMU

Sounds like it'd be a good idea to do that if only for the purpose of
describing things clearly in the DT.

> It can be seen in the Galaxy S3 kernel code how the Exynos5 CLKOUT handling
> might look like. See enum xclkout_select [1], exynos5_pmu_xclkout_set [2].
> It would be good someone who has access to the datasheet come up with at
> with some patch so the audio works are not blocked. I'm not working right
> now on Exynos5 :P.

I suspect I can reverse engineer something from this, though it would be
much easier for someone with the datasheet.
-------------- 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/20130726/e93d2ce4/attachment-0001.sig>

From linux at arm.linux.org.uk  Fri Jul 26 10:27:22 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 15:27:22 +0100
Subject: [PATCH V2 2/8] ASoC: Samsung: I2S: Add quirks as driver data in
 I2S
In-Reply-To: <1479924.YVrWxe87Mh@amdc1227>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-3-git-send-email-padma.v@samsung.com>
 <20130726140618.GP24642@n2100.arm.linux.org.uk> <1479924.YVrWxe87Mh@amdc1227>
Message-ID: <20130726142722.GS24642@n2100.arm.linux.org.uk>

On Fri, Jul 26, 2013 at 04:21:16PM +0200, Tomasz Figa wrote:
> Hi Russell,
> 
> On Friday 26 of July 2013 15:06:18 Russell King - ARM Linux wrote:
> > On Fri, Jul 26, 2013 at 07:06:46PM +0530, Padmavathi Venna wrote:
> > > -- compatible : "samsung,i2s-v5"
> > > +- compatible : should be one of the following.
> > > +   - samsung,s3c6410-i2s: for 8/16/24bit stereo I2S. Previous versions
> > > +     has only 8/16bit support.
> > > +   - samsung,s3c6410-i2sv4: for 8/16/24bit multichannel(5.1 channel)
> > > I2S. +     Introduced in s3c6410. This also applicable for s5p64x0
> > > platforms. +   - samsung,s5pc100-i2s: for 8/16/24bit multichannel(5.1
> > > channel) I2S +     with secondary fifo and s/w reset control.
> > > +   - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with
> > > +     secondary fifo, s/w reset control and internal mux for root clk
> > > src. +
> > 
> > So what happens with your changes to everyone who is using a DT file with
> > the "samsung,i2s-v5" compatible string?
> 
> AFAIK we decided that current bindings, if broken, can be redone correctly, 
> without caring for compatibility with old DTBs and only then, after 
> reviewing these new bindings by DT people, they can be stabilized.
> 
> Other issue, though, is that this patch breaks things until they get fixed 
> by patch 3. Support for new bindings should be added first, then users fixed 
> and only then old bindings can be removed.

So, these bindings were merged in the v3.9 merge window, using the
"samsung,i2s-v5" compatible string, and now for the v3.12 merge window,
you're proposing to break the audio description in any DT file which has
been used with v3.9..v3.11 inclusive?

The way you should be doing this is to keep the existing stuff working
and supplement it with the new method of describing the hardware.


From nicolas.pitre at linaro.org  Fri Jul 26 10:29:13 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 26 Jul 2013 10:29:13 -0400 (EDT)
Subject: [PATCH 03/13] ARM: b.L: core switcher code
In-Reply-To: <20130726104551.GA28084@e102568-lin.cambridge.arm.com>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-4-git-send-email-nicolas.pitre@linaro.org>
 <20130726104551.GA28084@e102568-lin.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1307261013500.15022@syhkavp.arg>

On Fri, 26 Jul 2013, Lorenzo Pieralisi wrote:

> On Tue, Jul 23, 2013 at 04:31:19AM +0100, Nicolas Pitre wrote:
> > This is the core code implementing big.LITTLE switcher functionality.
> > Rational for this code is available here:
> > 
> > http://lwn.net/Articles/481055/
> > 
> > The main entry point for a switch request is:
> > 
> > void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
> > 
> > If the calling CPU is not the wanted one, this wrapper takes care of
> > sending the request to the appropriate CPU with schedule_work_on().
> > 
> > At the moment the core switch operation is handled by bL_switch_to()
> > which must be called on the CPU for which a switch is requested.
> > 
> > What this code does:
> > 
> >   * Return early if the current cluster is the wanted one.
> > 
> >   * Close the gate in the kernel entry vector for both the inbound
> >     and outbound CPUs.
> > 
> >   * Wake up the inbound CPU so it can perform its reset sequence in
> >     parallel up to the kernel entry vector gate.
> > 
> >   * Migrate all interrupts in the GIC targeting the outbound CPU
> >     interface to the inbound CPU interface, including SGIs. This is
> >     performed by gic_migrate_target() in drivers/irqchip/irq-gic.c.
> > 
> >   * Call cpu_pm_enter() which takes care of flushing the VFP state to
> >     RAM and save the CPU interface config from the GIC to RAM.
> 
> If I read the code properly, you always resume on the same logical cpu id
> you suspended on (different HW CPU of course), correct ? This is to validate
> my assumptions on CPU PM notifiers and other code.

Yes, the logical CPU number stays the same.  That's the only way to make 
a transparent migration for core kernel code.

As this patch stands, the physical CPU number will be the same as the 
logical CPU number as well (even though the cluster number changes).  
But that particular assumption is removed later on.

> > 
> >   * Modify the cpu_logical_map to refer to the inbound physical CPU.
> > 
> >   * Call cpu_suspend() which saves the CPU state (general purpose
> >     registers, page table address) onto the stack and store the
> >     resulting stack pointer in an array indexed by the updated
> >     cpu_logical_map, then call the provided shutdown function.
> >     This happens in arch/arm/kernel/sleep.S.
> > 
> > At this point, the provided shutdown function executed by the outbound
> > CPU ungates the inbound CPU. Therefore the inbound CPU:
> > 
> >   * Picks up the saved stack pointer in the array indexed by its MPIDR
> >     in arch/arm/kernel/sleep.S.
> > 
> >   * The MMU and caches are re-enabled using the saved state on the
> >     provided stack, just like if this was a resume operation from a
> >     suspended state.
> > 
> >   * Then cpu_suspend() returns, although this is on the inbound CPU
> >     rather than the outbound CPU which called it initially.
> > 
> >   * The function cpu_pm_exit() is called which effect is to restore the
> >     CPU interface state in the GIC using the state previously saved by
> >     the outbound CPU.
> > 
> >   * Exit of bL_switch_to() to resume normal kernel execution on the
> >     new CPU.
> > 
> > However, the outbound CPU is potentially still running in parallel while
> > the inbound CPU is resuming normal kernel execution, hence we need
> > per CPU stack isolation to execute bL_do_switch().  After the outbound
> > CPU has ungated the inbound CPU, it calls mcpm_cpu_power_down() to:
> > 
> >   * Clean its L1 cache.
> > 
> >   * If it is the last CPU still alive in its cluster (last man standing),
> >     it also cleans its L2 cache and disables cache snooping from the other
> >     cluster.
> > 
> >   * Power down the CPU (or whole cluster).
> > 
> > Code called from bL_do_switch() might end up referencing 'current' for
> > some reasons.  However, 'current' is derived from the stack pointer.
> > With any arbitrary stack, the returned value for 'current' and any
> > dereferenced values through it are just random garbage which may lead to
> > segmentation faults.
> > 
> > The active page table during the execution of bL_do_switch() is also a
> > problem.  There is no guarantee that the inbound CPU won't destroy the
> > corresponding task which would free the attached page table while the
> > outbound CPU is still running and relying on it.
> 
> Yes this is really a sticking point, some comments below.
> 
> > To solve both issues, we borrow some of the task space belonging to
> > the init/idle task which, by its nature, is lightly used and therefore
> > is unlikely to clash with our usage.  The init task is also never going
> > away.
> 
> Unlikely does not mean it will always work and I think it is best
> avoided. Better stick to kernel threads, or a temporary stack but I
> understand for a temporary stack to work you have to force constraints
> on the mcpm backend you do not necessarily want to. More below.

Note that this is indeed changed later on.  But I wanted the code to be 
simpler as a first introductory patch.

And because kernel code expects the 'current' pointer to be valid, even 
in unexpected places such as printk(), this stack needs to be tied to a 
thread-info struct.

> > Right now the logical CPU number is assumed to be equivalent to the
> > physical CPU number within each cluster. The kernel should also be
> > booted with only one cluster active.  These limitations will be lifted
> > eventually.
> > 
> > Signed-off-by: Nicolas Pitre <nico at linaro.org>
> > ---
> >  arch/arm/Kconfig                   |  17 +++
> >  arch/arm/common/Makefile           |   1 +
> >  arch/arm/common/bL_switcher.c      | 247 +++++++++++++++++++++++++++++++++++++
> >  arch/arm/include/asm/bL_switcher.h |  17 +++
> >  4 files changed, 282 insertions(+)
> >  create mode 100644 arch/arm/common/bL_switcher.c
> >  create mode 100644 arch/arm/include/asm/bL_switcher.h
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index ba412e02ec..2c9e5bf734 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1538,6 +1538,23 @@ config MCPM
> >           for (multi-)cluster based systems, such as big.LITTLE based
> >           systems.
> > 
> > +config BIG_LITTLE
> > +       bool "big.LITTLE support (Experimental)"
> > +       depends on CPU_V7 && SMP
> > +       select MCPM
> > +       help
> > +         This option enables support for the big.LITTLE architecture.
> 
> Probably this belongs in a separate patch (CPU idle driver probably needs
> it too). Not a big deal though (and honestly I do not know how you can
> justify a single patch for that - we need to add this config option, somehow).
> 
> > +config BL_SWITCHER
> > +       bool "big.LITTLE switcher support"
> > +       depends on BIG_LITTLE && MCPM && HOTPLUG_CPU
> > +       select CPU_PM
> > +       select ARM_CPU_SUSPEND
> > +       help
> > +         The big.LITTLE "switcher" provides the core functionality to
> > +         transparently handle transition between a cluster of A15's
> > +         and a cluster of A7's in a big.LITTLE system.
> > +
> >  choice
> >         prompt "Memory split"
> >         default VMSPLIT_3G
> > diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
> > index 8c60f473e9..2586240d5a 100644
> > --- a/arch/arm/common/Makefile
> > +++ b/arch/arm/common/Makefile
> > @@ -17,3 +17,4 @@ obj-$(CONFIG_MCPM)            += mcpm_head.o mcpm_entry.o mcpm_platsmp.o vlock.o
> >  AFLAGS_mcpm_head.o             := -march=armv7-a
> >  AFLAGS_vlock.o                 := -march=armv7-a
> >  obj-$(CONFIG_TI_PRIV_EDMA)     += edma.o
> > +obj-$(CONFIG_BL_SWITCHER)      += bL_switcher.o
> > diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> > new file mode 100644
> > index 0000000000..e63881b430
> > --- /dev/null
> > +++ b/arch/arm/common/bL_switcher.c
> > @@ -0,0 +1,247 @@
> > +/*
> > + * arch/arm/common/bL_switcher.c -- big.LITTLE cluster switcher core driver
> > + *
> > + * Created by: Nicolas Pitre, March 2012
> > + * Copyright:  (C) 2012-2013  Linaro Limited
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/init.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/sched.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/cpu_pm.h>
> > +#include <linux/workqueue.h>
> > +#include <linux/mm.h>
> > +#include <linux/string.h>
> > +#include <linux/irqchip/arm-gic.h>
> > +
> > +#include <asm/smp_plat.h>
> > +#include <asm/cacheflush.h>
> > +#include <asm/suspend.h>
> > +#include <asm/mcpm.h>
> > +#include <asm/bL_switcher.h>
> > +
> > +
> > +/*
> > + * Use our own MPIDR accessors as the generic ones in asm/cputype.h have
> > + * __attribute_const__ and we don't want the compiler to assume any
> > + * constness here as the value _does_ change along some code paths.
> > + */
> > +
> > +static int read_mpidr(void)
> > +{
> > +       unsigned int id;
> > +       asm volatile ("mrc\tp15, 0, %0, c0, c0, 5" : "=r" (id));
> > +       return id & MPIDR_HWID_BITMASK;
> > +}
> > +
> > +/*
> > + * bL switcher core code.
> > + */
> > +
> > +static void bL_do_switch(void *_unused)
> > +{
> > +       unsigned mpidr, cpuid, clusterid, ob_cluster, ib_cluster;
> > +
> > +       /*
> > +        * We now have a piece of stack borrowed from the init task's.
> > +        * Let's also switch to init_mm right away to match it.
> > +        */
> > +       cpu_switch_mm(init_mm.pgd, &init_mm);
> 
> Is this cpu_switch_mm necessary ? You are executing it to make sure you
> get to wfi with page tables that can't be deallocated by the running inbound
> if I got it right. It is not needed to use the init stack, but you know
> that.

This is also to ensure the active mm matches the value of the 'current' 
pointer.  Again this is going away in a subsequent patch when moving to 
dedicated kernel threads.

> > +
> > +       pr_debug("%s\n", __func__);
> > +
> > +       mpidr = read_mpidr();
> > +       cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> > +       clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> > +       ob_cluster = clusterid;
> > +       ib_cluster = clusterid ^ 1;
> > +
> > +       /*
> > +        * Our state has been saved at this point.  Let's release our
> > +        * inbound CPU.
> > +        */
> > +       mcpm_set_entry_vector(cpuid, ib_cluster, cpu_resume);
> > +       sev();
> > +
> > +       /*
> > +        * From this point, we must assume that our counterpart CPU might
> > +        * have taken over in its parallel world already, as if execution
> > +        * just returned from cpu_suspend().  It is therefore important to
> > +        * be very careful not to make any change the other guy is not
> > +        * expecting.  This is why we need stack isolation.
> > +        *
> > +        * Fancy under cover tasks could be performed here.  For now
> > +        * we have none.
> > +        */
> > +
> > +       /* Let's put ourself down. */
> > +       mcpm_cpu_power_down();
> > +
> > +       /* should never get here */
> > +       BUG();
> > +}
> > +
> > +/*
> > + * Stack isolation.  To ensure 'current' remains valid, we just borrow
> > + * a slice of the init/idle task which should be fairly lightly used.
> > + * The borrowed area starts just above the thread_info structure located
> > + * at the very bottom of the stack, aligned to a cache line.
> > + */
> > +#define STACK_SIZE 256
> > +extern void call_with_stack(void (*fn)(void *), void *arg, void *sp);
> > +static int bL_switchpoint(unsigned long _arg)
> > +{
> > +       unsigned int mpidr = read_mpidr();
> > +       unsigned int cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> > +       unsigned int clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> > +       unsigned int cpu_index = cpuid + clusterid * MAX_CPUS_PER_CLUSTER;
> > +       void *stack = &init_thread_info + 1;
> > +       stack = PTR_ALIGN(stack, L1_CACHE_BYTES);
> > +       stack += cpu_index * STACK_SIZE + STACK_SIZE;
> 
> I do not like this much , for two reasons. Firstly because it might not work,
> secondly because whatever current usage we do from that point onwards
> is attached to the init thread, I am not sure that's 100% safe either.
> 
> Moving to kernel threads suffers from the same issue, even though I
> should grant there it is easier to monitor stack usage and grab safely
> some starting at the bottom. At least the current pointer behaviour is kept
> coherent. Overall the risk of using current on both outbound and inbound
> CPUs at once with no coordination is a bit scary, probably it is best to
> prevent current pointer usage altogether (but this forces constraints on
> MCPM). I will give it more thought.

The only reason for keeping 'current' valid at the moment is for 
printk() to work. Otherwise random memory corruption does occur.

> > +       call_with_stack(bL_do_switch, (void *)_arg, stack);
> > +       BUG();
> > +}
> > +
> > +/*
> > + * Generic switcher interface
> > + */
> > +
> > +/*
> > + * bL_switch_to - Switch to a specific cluster for the current CPU
> > + * @new_cluster_id: the ID of the cluster to switch to.
> > + *
> > + * This function must be called on the CPU to be switched.
> > + * Returns 0 on success, else a negative status code.
> > + */
> > +static int bL_switch_to(unsigned int new_cluster_id)
> > +{
> > +       unsigned int mpidr, cpuid, clusterid, ob_cluster, ib_cluster, this_cpu;
> > +       int ret;
> > +
> > +       mpidr = read_mpidr();
> > +       cpuid = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> > +       clusterid = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> > +       ob_cluster = clusterid;
> > +       ib_cluster = clusterid ^ 1;
> > +
> > +       if (new_cluster_id == clusterid)
> > +               return 0;
> > +
> > +       pr_debug("before switch: CPU %d in cluster %d\n", cpuid, clusterid);
> > +
> > +       /* Close the gate for our entry vectors */
> > +       mcpm_set_entry_vector(cpuid, ob_cluster, NULL);
> > +       mcpm_set_entry_vector(cpuid, ib_cluster, NULL);
> > +
> > +       /*
> > +        * Let's wake up the inbound CPU now in case it requires some delay
> > +        * to come online, but leave it gated in our entry vector code.
> > +        */
> > +       ret = mcpm_cpu_power_up(cpuid, ib_cluster);
> > +       if (ret) {
> > +               pr_err("%s: mcpm_cpu_power_up() returned %d\n", __func__, ret);
> > +               return ret;
> > +       }
> > +
> > +       /*
> > +        * From this point we are entering the switch critical zone
> > +        * and can't sleep/schedule anymore.
> > +        */
> > +       local_irq_disable();
> > +       local_fiq_disable();
> > +
> > +       this_cpu = smp_processor_id();
> > +
> > +       /* redirect GIC's SGIs to our counterpart */
> > +       gic_migrate_target(cpuid + ib_cluster*4);
> > +
> > +       /*
> > +        * Raise a SGI on the inbound CPU to make sure it doesn't stall
> > +        * in a possible WFI, such as in mcpm_power_down().
> > +        */
> > +       arch_send_wakeup_ipi_mask(cpumask_of(this_cpu));
> > +
> > +       ret = cpu_pm_enter();
> > +
> > +       /* we can not tolerate errors at this point */
> > +       if (ret)
> > +               panic("%s: cpu_pm_enter() returned %d\n", __func__, ret);
> > +
> > +       /*
> > +        * Flip the cluster in the CPU logical map for this CPU.
> > +        * This must be flushed to RAM as the resume code
> > +        * needs to access it while the caches are still disabled.
> > +        */
> > +       cpu_logical_map(this_cpu) ^= (1 << 8);
> > +       sync_cache_w(&cpu_logical_map(this_cpu));
> 
> sync_w is not needed anymore, cpu_resume does not use cpu_logical_map.

Good point.


Nicolas


From sachin.kamat at linaro.org  Fri Jul 26 10:36:47 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Fri, 26 Jul 2013 20:06:47 +0530
Subject: [PATCH V2 1/8] platform: Increase platform name size
In-Reply-To: <1374845812-7803-2-git-send-email-padma.v@samsung.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-2-git-send-email-padma.v@samsung.com>
Message-ID: <CAK9yfHxX7j8o3rQNzDM2eL6M66CJVcdGSz3XYR2-4i=5SmCinA@mail.gmail.com>

Hi Padma,

On 26 July 2013 19:06, Padmavathi Venna <padma.v at samsung.com> wrote:
> This patch increases the platform name size from 20 to 30.

Instead of describing what the patch does (which is quite obvious from
the code), it would be useful to describe why this change is required.


>
> Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
> ---
>  include/linux/mod_devicetable.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index b62d4af..f67b5d5 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -478,7 +478,7 @@ struct dmi_system_id {
>  #define DMI_MATCH(a, b)        { .slot = a, .substr = b }
>  #define DMI_EXACT_MATCH(a, b)  { .slot = a, .substr = b, .exact_match = 1 }
>
> -#define PLATFORM_NAME_SIZE     20
> +#define PLATFORM_NAME_SIZE     30
>  #define PLATFORM_MODULE_PREFIX "platform:"
>
>  struct platform_device_id {
> --
> 1.7.4.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
With warm regards,
Sachin


From t.figa at samsung.com  Fri Jul 26 10:37:48 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 26 Jul 2013 16:37:48 +0200
Subject: [PATCH V2 2/8] ASoC: Samsung: I2S: Add quirks as driver data
 in	I2S
In-Reply-To: <20130726142722.GS24642@n2100.arm.linux.org.uk>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1479924.YVrWxe87Mh@amdc1227> <20130726142722.GS24642@n2100.arm.linux.org.uk>
Message-ID: <4423918.aj7FtAoYyV@amdc1227>

On Friday 26 of July 2013 15:27:22 Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 04:21:16PM +0200, Tomasz Figa wrote:
> > Hi Russell,
> > 
> > On Friday 26 of July 2013 15:06:18 Russell King - ARM Linux wrote:
> > > On Fri, Jul 26, 2013 at 07:06:46PM +0530, Padmavathi Venna wrote:
> > > > -- compatible : "samsung,i2s-v5"
> > > > +- compatible : should be one of the following.
> > > > +   - samsung,s3c6410-i2s: for 8/16/24bit stereo I2S. Previous
> > > > versions
> > > > +     has only 8/16bit support.
> > > > +   - samsung,s3c6410-i2sv4: for 8/16/24bit multichannel(5.1
> > > > channel)
> > > > I2S. +     Introduced in s3c6410. This also applicable for s5p64x0
> > > > platforms. +   - samsung,s5pc100-i2s: for 8/16/24bit
> > > > multichannel(5.1
> > > > channel) I2S +     with secondary fifo and s/w reset control.
> > > > +   - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S
> > > > with
> > > > +     secondary fifo, s/w reset control and internal mux for root
> > > > clk
> > > > src. +
> > > 
> > > So what happens with your changes to everyone who is using a DT file
> > > with the "samsung,i2s-v5" compatible string?
> > 
> > AFAIK we decided that current bindings, if broken, can be redone
> > correctly, without caring for compatibility with old DTBs and only
> > then, after reviewing these new bindings by DT people, they can be
> > stabilized.
> > 
> > Other issue, though, is that this patch breaks things until they get
> > fixed by patch 3. Support for new bindings should be added first, then
> > users fixed and only then old bindings can be removed.
> 
> So, these bindings were merged in the v3.9 merge window, using the
> "samsung,i2s-v5" compatible string, and now for the v3.12 merge window,
> you're proposing to break the audio description in any DT file which has
> been used with v3.9..v3.11 inclusive?

It depends whether we want to keep all the broken stuff. At current state 
dts is still pretty much coupled with kernel version from which it comes 
from, so there is not yet too late to replace the broken bindings with 
something acceptable.

> 
> The way you should be doing this is to keep the existing stuff working
> and supplement it with the new method of describing the hardware.

Ideally yes and we are moving towards this with all the plans to separate 
stable and staging bindings. However we are currently half-drowning in a 
swamp of broken bindings, so we would rather try to clean the mess ASAP, 
before things stabilize.

Best regards,
Tomasz



From jonsmirl at gmail.com  Fri Jul 26 10:39:37 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Fri, 26 Jul 2013 10:39:37 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726142140.GR24642@n2100.arm.linux.org.uk>
References: <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726132709.GH29916@titan.lakedaemon.net>
 <1374846070.14574.92.camel@i7.infradead.org>
 <CAKON4OzrkHzUzKkULWCgiEpAtJ5gLxUm78R5ctd7p6trqq_gCA@mail.gmail.com>
 <20130726142140.GR24642@n2100.arm.linux.org.uk>
Message-ID: <CAKON4Oyu2hXa959zeuMWwT7jNpVFb31FoWqcD3gkJVz63jLEMw@mail.gmail.com>

On Fri, Jul 26, 2013 at 10:21 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Fri, Jul 26, 2013 at 10:14:32AM -0400, jonsmirl at gmail.com wrote:
>> Yes, yes - that's why the schema should be written down and used as a
>> validation input to dtc. Then dtc can spit out errors for non-standard
>> items. There would be two versions - the standard one and a legacy one
>> that includes the standard one plus the hacks that can't be undone.
>>
>> But more importantly it provides a framework for people creating new
>> node definitions. Now they can't work in a vacuum and come up with
>> random names and structure for everything.
>>
>> Most of the problems express in the thread would go away if the schema
>> was written down and discussed. The rule going forward would be no new
>> nodes that aren't part of the standard schema.
>
> So this is why I'm seeing patches just a short time ago removing existing
> compatible strings from the DT descriptions and associated driver, and
> replacing them with new ones... meaning that the old DT files won't work
> with newer kernels.
>
> What that means is using the descriptions as the schema won't catch that
> because they're changing those as well to match.
>
> There's a solution to that: dtc becomes a separate project external to
> the kernel which also contains the schemas that it verifies against.
> That way, if you want to make changes such as that above, you need to
> get it past not only kernel people but also past dtc maintainers -
> which increases the chances of such stuff being caught.

I don't see that it has to be outside of the kernel. It could still be
inside and just have different maintainers.

The real value of having that schema inside of the kernel is so that
people writing new drivers have some rules to look at. It would really
help in stopping 37 different descriptions of DMA controllers that are
all slightly different. You'd have to match you DMA controller
description to the generic form or making a convincing argument as to
why you need the master schema to be changed.



-- 
Jon Smirl
jonsmirl at gmail.com


From hauke at hauke-m.de  Fri Jul 26 10:39:28 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Fri, 26 Jul 2013 16:39:28 +0200
Subject: [PATCH v3 1/3] ARM: BCM5301X: initial support for the
 BCM5301X/BCM470X SoCs with ARM CPU
In-Reply-To: <20130726085542.GA17886@mudshark.cambridge.arm.com>
References: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
 <1374792135-30343-2-git-send-email-hauke@hauke-m.de>
 <20130726085542.GA17886@mudshark.cambridge.arm.com>
Message-ID: <51F28A20.7060105@hauke-m.de>

On 07/26/2013 10:55 AM, Will Deacon wrote:
> On Thu, Jul 25, 2013 at 11:42:13PM +0100, Hauke Mehrtens wrote:
>> This patch adds support for the BCM5301X/BCM470X SoCs with an ARM CPUs.
>> Currently just booting to a shell is working and nothing else, no
>> Ethernet, wifi, flash, ...
>>
>> This SoC is used in small office and home router with Broadcom SoCs.
>> This code should support the BCM4707, BCM4708, BCM4709, BCM53010,
>> BCM53011 and BCM53012 SoC. It uses one or two ARM Cortex A9
>> Cores, some highlights are 2 PCIe 2.0 controllers, 4 Gigabit Ethernet
>> MACs and a USB 3.0 host controller.
>>
>> This SoC uses a dual core CPU, but this is currently not implemented.
>> More information about this SoC can be found here:
>> http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers
> 
> [...]
> 
>> +static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
>> +				 struct pt_regs *regs)
>> +{
>> +	/*
>> +	 * These happen for no good reason, possibly left over from CFE
>> +	 */
>> +	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
>> +		addr, fsr);
>> +
>> +	/* Returning non-zero causes fault display and panic */
>> +	return 0;
>> +}
>> +
>> +static void __init bcm5301x_init_early(void)
>> +{
>> +	/* Install our hook */
>> +	hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, 0,
>> +			"imprecise external abort");
>> +}
> 
> Surely you can't be serious?
> 
> At least, we need a pretty good explanation of what *exactly* is causing
> these spurious aborts before we start ignoring them unconditionally like
> this. You're effectively masking an extremely serious error indicator with
> this change.

This fault occurs once every boot sometime early in the boot process,
but the actual time this happens varies randomly.

Sadly I do not understand this completely, and I copied this from the
vendor BSP with the corresponding code documentation. They think CFE
(Common Firmware Environment, the bootloader used on these devices), did
something wrong, but I do not have the actual source of CFE and I do not
have the chip documentation. This occurs just once as far as I have seen
this, we could just catch the first one. Changing the boot loader is
also not an option, because I want to use this code on devices already
shipped to costumers and I do not have access to the boot loader source
code.

Do you know what this fault normally indicates?


Hauke


From broonie at kernel.org  Fri Jul 26 10:40:47 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Jul 2013 15:40:47 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726142140.GR24642@n2100.arm.linux.org.uk>
References: <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726132709.GH29916@titan.lakedaemon.net>
 <1374846070.14574.92.camel@i7.infradead.org>
 <CAKON4OzrkHzUzKkULWCgiEpAtJ5gLxUm78R5ctd7p6trqq_gCA@mail.gmail.com>
 <20130726142140.GR24642@n2100.arm.linux.org.uk>
Message-ID: <20130726144047.GH9858@sirena.org.uk>

On Fri, Jul 26, 2013 at 03:21:40PM +0100, Russell King - ARM Linux wrote:

> So this is why I'm seeing patches just a short time ago removing existing
> compatible strings from the DT descriptions and associated driver, and
> replacing them with new ones... meaning that the old DT files won't work
> with newer kernels.

The big question is if you're seeing such patches merged.  People making
mistakes on submissions is totally normal.

If it's the case I think you mean TBH I'm not sure anyone cares, I don't
think anyone is using that stuff in production yet as those chips go
almost exclusively into Android phones.
-------------- 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/20130726/235a3d4f/attachment.sig>

From pawel.moll at arm.com  Fri Jul 26 10:41:24 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Fri, 26 Jul 2013 15:41:24 +0100
Subject: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
In-Reply-To: <CAF6AEGtNEOpuKqcr7vfieCx0mot44L2bZzOt4ipcmUVv4FwUVw@mail.gmail.com>
References: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com>
 <CAF6AEGtspnhSGNM4_QQubVfOkZ1Gh1-Z3iyHOLBPVWuqRy81ew@mail.gmail.com>
 <1374847564.3213.70.camel@hornet>
 <CAF6AEGtNEOpuKqcr7vfieCx0mot44L2bZzOt4ipcmUVv4FwUVw@mail.gmail.com>
Message-ID: <1374849684.3213.81.camel@hornet>

On Fri, 2013-07-26 at 15:21 +0100, Rob Clark wrote:
> Well, if you have something complex enough to benefit from CDF, then
> you probably ought to be looking at drm/kms. 

That's what we're doing - hope you appreciate Tom's effort of re-writing
a driver for something that pre-dates DRM/KMS by generations ;-)

> I guess I don't really care about what goes in fbdev.  

Well, I've guessed that ;-)

> My main concern is that we have more than enough work to do,
> and have more than enough complexity.  If we end up w/ bunch of glue
> to tie things in to drm properties, how drm helpers sequence things
> during modeset, locking, etc.. I just don't see that turning out well.
>  And also, just on the logistical side, having something shared across
> subsystems makes changes more of a pain during the merge window.  Not
> to mention backports to stable kernels, distro kernels, etc.  It all
> just seems like it will be a lot of unnecessary headache.

I won't argue that, however it seems to me that CDF is such a small
variable in the equation that it would disappear in the noise. Surely
you have (or will have) standard DRM interface to drive the display
pipeline where CDF would be one of many back-ends? In the end you'll
have to solve the same problem - how to represent a random pipeline in a
generic way so different components can be plugged one into another.
Anyway, I'm not planning to stick my nose between DRM and CDF, really.
I'm just hoping for a solution that will fit my needs :-)

Pawel




From nicolas.pitre at linaro.org  Fri Jul 26 10:41:38 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 26 Jul 2013 10:41:38 -0400 (EDT)
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value
 to index into save array
In-Reply-To: <20130726113110.GB28084@e102568-lin.cambridge.arm.com>
References: <alpine.LFD.2.03.1307251203550.15022@syhkavp.arg>
 <20130726113110.GB28084@e102568-lin.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1307261032330.15022@syhkavp.arg>

On Fri, 26 Jul 2013, Lorenzo Pieralisi wrote:

> On Thu, Jul 25, 2013 at 05:06:51PM +0100, Nicolas Pitre wrote:
> > On Thu, 25 Jul 2013, Dave Martin wrote:
> > 
> > > On Wed, Jul 24, 2013 at 02:55:00PM -0400, Nicolas Pitre wrote:
> > > > On Wed, 24 Jul 2013, Dave Martin wrote:
> > > > 
> > > > > But this patch commits us to requiring that on the suspend path 
> > > > > specifically -- I think that ought to be mentioned somewhere. A 
> > > > > comment in the preamble for __cpu_suspend would be enough, I think.
> > > > 
> > > > What comment would you suggest?  I want to make sure the possible 
> > > > confusion you see is properly addressed.
> > > 
> > > I think we just need to state that the value of
> > > cpu_logical_map(smp_processor_id()) must be the MPIDR of the physical
> > > CPU the suspending logical CPU will resume on.  Consequently, if doing a
> > > migration, cpu_logical_map() must be updated appropriately somewhere
> > > between cpu_pm_enter() and cpu_suspend().
> > 
> > Excellent.  I've amended the patch with this:
> > 
> > diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
> > index 2835d35234..caf938db62 100644
> > --- a/arch/arm/kernel/suspend.c
> > +++ b/arch/arm/kernel/suspend.c
> > @@ -17,6 +17,11 @@ extern void cpu_resume_mmu(void);
> >  /*
> >   * Hide the first two arguments to __cpu_suspend - these are an implementation
> >   * detail which platform code shouldn't have to know about.
> > + *
> > + * On SMP systems, the value of cpu_logical_map(smp_processor_id()) must be
> > + * the MPIDR of the physical CPU the suspending logical CPU will resume on.
> > + * Consequently, if doing a physical CPU migration, cpu_logical_map() must be
> > + * updated appropriately somewhere between cpu_pm_enter() and cpu_suspend().
> >   */
> >  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> >  {
> > 
> > I've put it against cpu_suspend() rather than __cpu_suspend(() as this 
> > is what users should care about.
> > 
> > ACK?
> 
> We need this patch to allow IKS to store a cpu context at a specific
> index, let's be honest. It is a moot point and I am not very happy
> about changing this code for a very specific usage, but the way code is
> implemented makes the change acceptable. I really do not think we should
> write guidelines on how cpu_suspend users have to change cpu_logical_map
> though, that's not needed apart from IKS and that should be limited to IKS
> code only.
> 
> Again, that's just my opinion, but cpu_suspend API must be kept as it is
> and we should not encourage people to use it in creative ways.

I tend to agree, but I'm now stuck between two conflicting requests.

Are you saying you are willing to give me your ACK if I revert the 
suggested change?


Nicolas


From nicolas.pitre at linaro.org  Fri Jul 26 10:46:45 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 26 Jul 2013 10:46:45 -0400 (EDT)
Subject: [PATCH 4/6] ARM: locks: prefetch the destination word for write
 prior to strex
In-Reply-To: <20130726103404.GB17886@mudshark.cambridge.arm.com>
References: <1374579389-32704-1-git-send-email-will.deacon@arm.com>
 <1374579389-32704-5-git-send-email-will.deacon@arm.com>
 <alpine.LFD.2.03.1307231609170.15022@syhkavp.arg>
 <20130724111841.GD11072@mudshark.cambridge.arm.com>
 <51F160EA.6030800@codeaurora.org> <51F1626C.3050008@codeaurora.org>
 <20130725174555.GK12827@mudshark.cambridge.arm.com>
 <alpine.LFD.2.03.1307251622320.15022@syhkavp.arg>
 <20130726103404.GB17886@mudshark.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1307261042170.15022@syhkavp.arg>

On Fri, 26 Jul 2013, Will Deacon wrote:

> Hi Nicolas,
> 
> On Thu, Jul 25, 2013 at 09:24:48PM +0100, Nicolas Pitre wrote:
> > On Thu, 25 Jul 2013, Will Deacon wrote:
> > > > 
> > > > Oh joy. Why is rwlock's lock member marked volatile?
> > > 
> > > Yeah, that was the problematic guy. However, I had to fix that anyway in
> > > this patch because otherwise the definition for prefetchw when
> > > !ARCH_HAS_PREFETCHW (which expands to __builtin_prefetch(x,1)) will explode.
> > 
> > Why not always keep ARCH_HAS_PREFETCHW defined then, and have 
> > __builtin_prefetch([const volatile void *)x,1)) when we can't do better?
> > 
> > Or why not adding this cast to the generic definition?
> 
> Yes, I'd prefer to fix the generic definition as a separate patch. However,
> I think the only case that this generates warnings is when a volatile * is
> passed. If volatile is actually required, I question whether prefetching
> from that location even makes sense in the first place since, in the kernel,
> the keyword seems to be generally associated with IO rather than CPUs accessing
> shared memory via caches.
> 
> What do you think?

The only thing volatile is good for is to tell the compiler not to 
attempt any kind of optimization on the access.  Obviously this is 
needed for IO accessors, but we don't want the compiler to think it can 
cache a previous reading of the lock value either.  So as long as all 
accesses are done through some accessors (you did add ACCESS_ONCE() in 
your patch removing the volatile for that reason) then we don't need 
that keyword in the lock definition.


Nicolas


From manjunath.goudar at linaro.org  Fri Jul 26 10:49:15 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Fri, 26 Jul 2013 20:19:15 +0530
Subject: [PATCH V3 0/2] USB: OHCI: more bus glues as separate modules
In-Reply-To: <1372958187-4039-1-git-send-email-manjunath.goudar@linaro.org>
References: <1372958187-4039-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374850157-5854-1-git-send-email-manjunath.goudar@linaro.org>

These patches are for separating the SOC On-Chip ohci host controller
from ohci-hcd host code into its own driver module.
This work is part of enabling multi-platform kernels on ARM.

In V2:

patch 1/2:
     -ohci_hcd_init() statements are removed,
      because by default it is called in ohci_setup().

Patch 2/2:
     -Changed ohci_hcd and pxa27x_ohci struct variable names.
        1 ohci_hcd struct variable name is ohci.
        2 pxa27x_ohci struct variable name is pxa_ohci.
 
In V3:

Patch 1/2:
     -Unused *ohci variable has been removed.

patch 2/2:
     -Rewrite the macro definition of to_pxa27x_ohci.
     -clk_put() function has been called before usb_put_hcd().

Manjunath Goudar (2):
  USB: OHCI: make ohci-ep93xx a separate driver
  USB: OHCI: make ohci-pxa27x a separate driver

 drivers/usb/host/Kconfig       |   16 +++
 drivers/usb/host/Makefile      |    2 +
 drivers/usb/host/ohci-ep93xx.c |   80 ++++++-------
 drivers/usb/host/ohci-hcd.c    |   24 ----
 drivers/usb/host/ohci-pxa27x.c |  242 ++++++++++++++++++----------------------
 5 files changed, 158 insertions(+), 206 deletions(-)

-- 
1.7.9.5



From manjunath.goudar at linaro.org  Fri Jul 26 10:49:16 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Fri, 26 Jul 2013 20:19:16 +0530
Subject: [PATCH V3 1/2] USB: OHCI: make ohci-ep93xx a separate driver
In-Reply-To: <1374850157-5854-1-git-send-email-manjunath.goudar@linaro.org>
References: <1372958187-4039-1-git-send-email-manjunath.goudar@linaro.org>
 <1374850157-5854-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374850157-5854-2-git-send-email-manjunath.goudar@linaro.org>

Separate the OHCI EP93XX host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -ohci_hcd_init() statements are removed,
  because by default it is called in ohci_setup().

V3:
 -Unused *ohci variable has been removed.
---
 drivers/usb/host/Kconfig       |    8 ++++
 drivers/usb/host/Makefile      |    1 +
 drivers/usb/host/ohci-ep93xx.c |   80 +++++++++++++++++-----------------------
 drivers/usb/host/ohci-hcd.c    |   19 ----------
 4 files changed, 43 insertions(+), 65 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index f7f7823..cdfaa04 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -414,6 +414,14 @@ config USB_OHCI_HCD_DA8XX
           Enables support for the on-chip OHCI controller on
           DA8xx/OMAP-L1x chips.
 
+config USB_OHCI_HCD_EP93XX
+	tristate "Support for EP93XX on-chip OHCI USB controller"
+	depends on USB_OHCI_HCD && ARCH_EP93XX
+	default y
+	---help---
+	  Enables support for the on-chip OHCI controller on
+	  EP93XX chips.
+
 config USB_OHCI_HCD_AT91
         tristate "Support for Atmel on-chip OHCI USB controller"
         depends on USB_OHCI_HCD && ARCH_AT91
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index f8d59371..3fee3ea 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_USB_OHCI_HCD_AT91)	+= ohci-at91.o
 obj-$(CONFIG_USB_OHCI_HCD_S3CXXXX)	+= ohci-s3c2410.o
 obj-$(CONFIG_USB_OHCI_HCD_LPC32XX)	+= ohci-nxp.o
 obj-$(CONFIG_USB_OHCI_HCD_DA8XX)	+= ohci-da8xx.o
+obj-$(CONFIG_USB_OHCI_HCD_EP93XX)	+= ohci-ep93xx.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index f0aaa48..7b0e3ae 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -25,8 +25,21 @@
 
 #include <linux/clk.h>
 #include <linux/device.h>
-#include <linux/signal.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/platform_device.h>
+#include <linux/signal.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ohci.h"
+
+#define DRIVER_DESC "OHCI EP93xx driver"
+
+static const char hcd_name[] = "ohci-ep93xx";
+
+static struct hc_driver __read_mostly ohci_ep93xx_hc_driver;
 
 static struct clk *usb_host_clock;
 
@@ -79,8 +92,6 @@ static int usb_hcd_ep93xx_probe(const struct hc_driver *driver,
 
 	ep93xx_start_hc(&pdev->dev);
 
-	ohci_hcd_init(hcd_to_ohci(hcd));
-
 	retval = usb_add_hcd(hcd, pdev->resource[1].start, 0);
 	if (retval == 0)
 		return retval;
@@ -107,48 +118,6 @@ static void usb_hcd_ep93xx_remove(struct usb_hcd *hcd,
 	usb_put_hcd(hcd);
 }
 
-static int ohci_ep93xx_start(struct usb_hcd *hcd)
-{
-	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
-	int ret;
-
-	if ((ret = ohci_init(ohci)) < 0)
-		return ret;
-
-	if ((ret = ohci_run(ohci)) < 0) {
-		dev_err(hcd->self.controller, "can't start %s\n",
-			hcd->self.bus_name);
-		ohci_stop(hcd);
-		return ret;
-	}
-
-	return 0;
-}
-
-static struct hc_driver ohci_ep93xx_hc_driver = {
-	.description		= hcd_name,
-	.product_desc		= "EP93xx OHCI",
-	.hcd_priv_size		= sizeof(struct ohci_hcd),
-	.irq			= ohci_irq,
-	.flags			= HCD_USB11 | HCD_MEMORY,
-	.start			= ohci_ep93xx_start,
-	.stop			= ohci_stop,
-	.shutdown		= ohci_shutdown,
-	.urb_enqueue		= ohci_urb_enqueue,
-	.urb_dequeue		= ohci_urb_dequeue,
-	.endpoint_disable	= ohci_endpoint_disable,
-	.get_frame_number	= ohci_get_frame,
-	.hub_status_data	= ohci_hub_status_data,
-	.hub_control		= ohci_hub_control,
-#ifdef CONFIG_PM
-	.bus_suspend		= ohci_bus_suspend,
-	.bus_resume		= ohci_bus_resume,
-#endif
-	.start_port_reset	= ohci_start_port_reset,
-};
-
-extern int usb_disabled(void);
-
 static int ohci_hcd_ep93xx_drv_probe(struct platform_device *pdev)
 {
 	int ret;
@@ -206,7 +175,6 @@ static int ohci_hcd_ep93xx_drv_resume(struct platform_device *pdev)
 }
 #endif
 
-
 static struct platform_driver ohci_hcd_ep93xx_driver = {
 	.probe		= ohci_hcd_ep93xx_drv_probe,
 	.remove		= ohci_hcd_ep93xx_drv_remove,
@@ -221,4 +189,24 @@ static struct platform_driver ohci_hcd_ep93xx_driver = {
 	},
 };
 
+static int __init ohci_ep93xx_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ohci_init_driver(&ohci_ep93xx_hc_driver, NULL);
+	return platform_driver_register(&ohci_hcd_ep93xx_driver);
+}
+module_init(ohci_ep93xx_init);
+
+static void __exit ohci_ep93xx_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_ep93xx_driver);
+}
+module_exit(ohci_ep93xx_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:ep93xx-ohci");
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index d514e11..3f46cff 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1189,11 +1189,6 @@ MODULE_LICENSE ("GPL");
 #define PLATFORM_DRIVER		ohci_hcd_pxa27x_driver
 #endif
 
-#ifdef CONFIG_ARCH_EP93XX
-#include "ohci-ep93xx.c"
-#define EP93XX_PLATFORM_DRIVER	ohci_hcd_ep93xx_driver
-#endif
-
 #ifdef CONFIG_USB_OHCI_HCD_PPC_OF
 #include "ohci-ppc-of.c"
 #define OF_PLATFORM_DRIVER	ohci_hcd_ppc_of_driver
@@ -1284,20 +1279,9 @@ static int __init ohci_hcd_mod_init(void)
 	if (retval < 0)
 		goto error_tmio;
 #endif
-
-#ifdef EP93XX_PLATFORM_DRIVER
-	retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_ep93xx;
-#endif
-
 	return retval;
 
 	/* Error path */
-#ifdef EP93XX_PLATFORM_DRIVER
-	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
- error_ep93xx:
-#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
  error_tmio:
@@ -1335,9 +1319,6 @@ module_init(ohci_hcd_mod_init);
 
 static void __exit ohci_hcd_mod_exit(void)
 {
-#ifdef EP93XX_PLATFORM_DRIVER
-	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
-#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
 #endif
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Fri Jul 26 10:49:17 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Fri, 26 Jul 2013 20:19:17 +0530
Subject: [PATCH V3 2/2] USB: OHCI: make ohci-pxa27x a separate driver
In-Reply-To: <1374850157-5854-1-git-send-email-manjunath.goudar@linaro.org>
References: <1372958187-4039-1-git-send-email-manjunath.goudar@linaro.org>
 <1374850157-5854-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1374850157-5854-3-git-send-email-manjunath.goudar@linaro.org>

Separate the  OHCI pxa27x/pxa3xx host controller driver from
ohci-hcd host code so that it can be built as a separate driver
module. This work is part of enabling multi-platform kernels on
ARM.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: linux-usb at vger.kernel.org

V2:
 -Changed ohci_hcd and pxa27x_ohci struct variable names.
    1 ohci_hcd struct variable name is ohci.
    2 pxa27x_ohci struct variable name is pxa_ohci.

V3:
 -Rewrite the macro definition of to_pxa27x_ohci.
 -clk_put() function has been called before usb_put_hcd().
---
 drivers/usb/host/Kconfig       |    8 ++
 drivers/usb/host/Makefile      |    1 +
 drivers/usb/host/ohci-hcd.c    |    5 -
 drivers/usb/host/ohci-pxa27x.c |  242 ++++++++++++++++++----------------------
 4 files changed, 115 insertions(+), 141 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index cdfaa04..0d7ee36 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -422,6 +422,14 @@ config USB_OHCI_HCD_EP93XX
 	  Enables support for the on-chip OHCI controller on
 	  EP93XX chips.
 
+config USB_OHCI_HCD_PXA27X
+	tristate "Support for PXA27X/PXA3XX on-chip OHCI USB controller"
+	depends on USB_OHCI_HCD && (PXA27x || PXA3xx)
+	default y
+	---help---
+	  Enables support for the on-chip OHCI controller on
+	  PXA27x/PXA3xx chips.
+
 config USB_OHCI_HCD_AT91
         tristate "Support for Atmel on-chip OHCI USB controller"
         depends on USB_OHCI_HCD && ARCH_AT91
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 3fee3ea..8b7fa89 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_USB_OHCI_HCD_S3CXXXX)	+= ohci-s3c2410.o
 obj-$(CONFIG_USB_OHCI_HCD_LPC32XX)	+= ohci-nxp.o
 obj-$(CONFIG_USB_OHCI_HCD_DA8XX)	+= ohci-da8xx.o
 obj-$(CONFIG_USB_OHCI_HCD_EP93XX)	+= ohci-ep93xx.o
+obj-$(CONFIG_USB_OHCI_HCD_PXA27X)	+= ohci-pxa27x.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 3f46cff..f601dde 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1184,11 +1184,6 @@ MODULE_LICENSE ("GPL");
 #define SA1111_DRIVER		ohci_hcd_sa1111_driver
 #endif
 
-#if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx)
-#include "ohci-pxa27x.c"
-#define PLATFORM_DRIVER		ohci_hcd_pxa27x_driver
-#endif
-
 #ifdef CONFIG_USB_OHCI_HCD_PPC_OF
 #include "ohci-ppc-of.c"
 #define OF_PLATFORM_DRIVER	ohci_hcd_ppc_of_driver
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 5fb91f1..394f221 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -19,15 +19,26 @@
  * This file is licenced under the GPL.
  */
 
-#include <linux/device.h>
-#include <linux/signal.h>
-#include <linux/platform_device.h>
 #include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/of_platform.h>
 #include <linux/of_gpio.h>
-#include <mach/hardware.h>
 #include <linux/platform_data/usb-ohci-pxa27x.h>
 #include <linux/platform_data/usb-pxa3xx-ulpi.h>
+#include <linux/platform_device.h>
+#include <linux/signal.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/otg.h>
+
+#include <mach/hardware.h>
+
+#include "ohci.h"
+
+#define DRIVER_DESC "OHCI PXA27x/PXA3x driver"
 
 /*
  * UHC: USB Host Controller (OHCI-like) register definitions
@@ -101,16 +112,16 @@
 
 #define PXA_UHC_MAX_PORTNUM    3
 
-struct pxa27x_ohci {
-	/* must be 1st member here for hcd_to_ohci() to work */
-	struct ohci_hcd ohci;
+static const char hcd_name[] = "ohci-pxa27x";
+
+static struct hc_driver __read_mostly ohci_pxa27x_hc_driver;
 
-	struct device	*dev;
+struct pxa27x_ohci {
 	struct clk	*clk;
 	void __iomem	*mmio_base;
 };
 
-#define to_pxa27x_ohci(hcd)	(struct pxa27x_ohci *)hcd_to_ohci(hcd)
+#define to_pxa27x_ohci(hcd)	(struct pxa27x_ohci *)(hcd_to_ohci(hcd)->priv)
 
 /*
   PMM_NPS_MODE -- PMM Non-power switching mode
@@ -122,10 +133,10 @@ struct pxa27x_ohci {
   PMM_PERPORT_MODE -- PMM per port switching mode
       Ports are powered individually.
  */
-static int pxa27x_ohci_select_pmm(struct pxa27x_ohci *ohci, int mode)
+static int pxa27x_ohci_select_pmm(struct pxa27x_ohci *pxa_ohci, int mode)
 {
-	uint32_t uhcrhda = __raw_readl(ohci->mmio_base + UHCRHDA);
-	uint32_t uhcrhdb = __raw_readl(ohci->mmio_base + UHCRHDB);
+	uint32_t uhcrhda = __raw_readl(pxa_ohci->mmio_base + UHCRHDA);
+	uint32_t uhcrhdb = __raw_readl(pxa_ohci->mmio_base + UHCRHDB);
 
 	switch (mode) {
 	case PMM_NPS_MODE:
@@ -149,20 +160,18 @@ static int pxa27x_ohci_select_pmm(struct pxa27x_ohci *ohci, int mode)
 		uhcrhda |= RH_A_NPS;
 	}
 
-	__raw_writel(uhcrhda, ohci->mmio_base + UHCRHDA);
-	__raw_writel(uhcrhdb, ohci->mmio_base + UHCRHDB);
+	__raw_writel(uhcrhda, pxa_ohci->mmio_base + UHCRHDA);
+	__raw_writel(uhcrhdb, pxa_ohci->mmio_base + UHCRHDB);
 	return 0;
 }
 
-extern int usb_disabled(void);
-
 /*-------------------------------------------------------------------------*/
 
-static inline void pxa27x_setup_hc(struct pxa27x_ohci *ohci,
+static inline void pxa27x_setup_hc(struct pxa27x_ohci *pxa_ohci,
 				   struct pxaohci_platform_data *inf)
 {
-	uint32_t uhchr = __raw_readl(ohci->mmio_base + UHCHR);
-	uint32_t uhcrhda = __raw_readl(ohci->mmio_base + UHCRHDA);
+	uint32_t uhchr = __raw_readl(pxa_ohci->mmio_base + UHCHR);
+	uint32_t uhcrhda = __raw_readl(pxa_ohci->mmio_base + UHCRHDA);
 
 	if (inf->flags & ENABLE_PORT1)
 		uhchr &= ~UHCHR_SSEP1;
@@ -194,17 +203,17 @@ static inline void pxa27x_setup_hc(struct pxa27x_ohci *ohci,
 		uhcrhda |= UHCRHDA_POTPGT(inf->power_on_delay / 2);
 	}
 
-	__raw_writel(uhchr, ohci->mmio_base + UHCHR);
-	__raw_writel(uhcrhda, ohci->mmio_base + UHCRHDA);
+	__raw_writel(uhchr, pxa_ohci->mmio_base + UHCHR);
+	__raw_writel(uhcrhda, pxa_ohci->mmio_base + UHCRHDA);
 }
 
-static inline void pxa27x_reset_hc(struct pxa27x_ohci *ohci)
+static inline void pxa27x_reset_hc(struct pxa27x_ohci *pxa_ohci)
 {
-	uint32_t uhchr = __raw_readl(ohci->mmio_base + UHCHR);
+	uint32_t uhchr = __raw_readl(pxa_ohci->mmio_base + UHCHR);
 
-	__raw_writel(uhchr | UHCHR_FHR, ohci->mmio_base + UHCHR);
+	__raw_writel(uhchr | UHCHR_FHR, pxa_ohci->mmio_base + UHCHR);
 	udelay(11);
-	__raw_writel(uhchr & ~UHCHR_FHR, ohci->mmio_base + UHCHR);
+	__raw_writel(uhchr & ~UHCHR_FHR, pxa_ohci->mmio_base + UHCHR);
 }
 
 #ifdef CONFIG_PXA27x
@@ -213,25 +222,26 @@ extern void pxa27x_clear_otgph(void);
 #define pxa27x_clear_otgph()	do {} while (0)
 #endif
 
-static int pxa27x_start_hc(struct pxa27x_ohci *ohci, struct device *dev)
+static int pxa27x_start_hc(struct pxa27x_ohci *pxa_ohci, struct device *dev)
 {
 	int retval = 0;
 	struct pxaohci_platform_data *inf;
 	uint32_t uhchr;
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
 
 	inf = dev->platform_data;
 
-	clk_prepare_enable(ohci->clk);
+	clk_prepare_enable(pxa_ohci->clk);
 
-	pxa27x_reset_hc(ohci);
+	pxa27x_reset_hc(pxa_ohci);
 
-	uhchr = __raw_readl(ohci->mmio_base + UHCHR) | UHCHR_FSBIR;
-	__raw_writel(uhchr, ohci->mmio_base + UHCHR);
+	uhchr = __raw_readl(pxa_ohci->mmio_base + UHCHR) | UHCHR_FSBIR;
+	__raw_writel(uhchr, pxa_ohci->mmio_base + UHCHR);
 
-	while (__raw_readl(ohci->mmio_base + UHCHR) & UHCHR_FSBIR)
+	while (__raw_readl(pxa_ohci->mmio_base + UHCHR) & UHCHR_FSBIR)
 		cpu_relax();
 
-	pxa27x_setup_hc(ohci, inf);
+	pxa27x_setup_hc(pxa_ohci, inf);
 
 	if (inf->init)
 		retval = inf->init(dev);
@@ -240,38 +250,39 @@ static int pxa27x_start_hc(struct pxa27x_ohci *ohci, struct device *dev)
 		return retval;
 
 	if (cpu_is_pxa3xx())
-		pxa3xx_u2d_start_hc(&ohci_to_hcd(&ohci->ohci)->self);
+		pxa3xx_u2d_start_hc(&hcd->self);
 
-	uhchr = __raw_readl(ohci->mmio_base + UHCHR) & ~UHCHR_SSE;
-	__raw_writel(uhchr, ohci->mmio_base + UHCHR);
-	__raw_writel(UHCHIE_UPRIE | UHCHIE_RWIE, ohci->mmio_base + UHCHIE);
+	uhchr = __raw_readl(pxa_ohci->mmio_base + UHCHR) & ~UHCHR_SSE;
+	__raw_writel(uhchr, pxa_ohci->mmio_base + UHCHR);
+	__raw_writel(UHCHIE_UPRIE | UHCHIE_RWIE, pxa_ohci->mmio_base + UHCHIE);
 
 	/* Clear any OTG Pin Hold */
 	pxa27x_clear_otgph();
 	return 0;
 }
 
-static void pxa27x_stop_hc(struct pxa27x_ohci *ohci, struct device *dev)
+static void pxa27x_stop_hc(struct pxa27x_ohci *pxa_ohci, struct device *dev)
 {
 	struct pxaohci_platform_data *inf;
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
 	uint32_t uhccoms;
 
 	inf = dev->platform_data;
 
 	if (cpu_is_pxa3xx())
-		pxa3xx_u2d_stop_hc(&ohci_to_hcd(&ohci->ohci)->self);
+		pxa3xx_u2d_stop_hc(&hcd->self);
 
 	if (inf->exit)
 		inf->exit(dev);
 
-	pxa27x_reset_hc(ohci);
+	pxa27x_reset_hc(pxa_ohci);
 
 	/* Host Controller Reset */
-	uhccoms = __raw_readl(ohci->mmio_base + UHCCOMS) | 0x01;
-	__raw_writel(uhccoms, ohci->mmio_base + UHCCOMS);
+	uhccoms = __raw_readl(pxa_ohci->mmio_base + UHCCOMS) | 0x01;
+	__raw_writel(uhccoms, pxa_ohci->mmio_base + UHCCOMS);
 	udelay(10);
 
-	clk_disable_unprepare(ohci->clk);
+	clk_disable_unprepare(pxa_ohci->clk);
 }
 
 #ifdef CONFIG_OF
@@ -356,7 +367,8 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver, struct platform_device
 	int retval, irq;
 	struct usb_hcd *hcd;
 	struct pxaohci_platform_data *inf;
-	struct pxa27x_ohci *ohci;
+	struct pxa27x_ohci *pxa_ohci;
+	struct ohci_hcd *ohci;
 	struct resource *r;
 	struct clk *usb_clk;
 
@@ -409,29 +421,31 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver, struct platform_device
 	}
 
 	/* initialize "struct pxa27x_ohci" */
-	ohci = (struct pxa27x_ohci *)hcd_to_ohci(hcd);
-	ohci->dev = &pdev->dev;
-	ohci->clk = usb_clk;
-	ohci->mmio_base = (void __iomem *)hcd->regs;
+	pxa_ohci = to_pxa27x_ohci(hcd);
+	pxa_ohci->clk = usb_clk;
+	pxa_ohci->mmio_base = (void __iomem *)hcd->regs;
 
-	if ((retval = pxa27x_start_hc(ohci, &pdev->dev)) < 0) {
+	retval = pxa27x_start_hc(pxa_ohci, &pdev->dev);
+	if (retval < 0) {
 		pr_debug("pxa27x_start_hc failed");
 		goto err3;
 	}
 
 	/* Select Power Management Mode */
-	pxa27x_ohci_select_pmm(ohci, inf->port_mode);
+	pxa27x_ohci_select_pmm(pxa_ohci, inf->port_mode);
 
 	if (inf->power_budget)
 		hcd->power_budget = inf->power_budget;
 
-	ohci_hcd_init(hcd_to_ohci(hcd));
+	/* The value of NDP in roothub_a is incorrect on this hardware */
+	ohci = hcd_to_ohci(hcd);
+	ohci->num_ports = 3;
 
 	retval = usb_add_hcd(hcd, irq, 0);
 	if (retval == 0)
 		return retval;
 
-	pxa27x_stop_hc(ohci, &pdev->dev);
+	pxa27x_stop_hc(pxa_ohci, &pdev->dev);
  err3:
 	iounmap(hcd->regs);
  err2:
@@ -459,88 +473,18 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver, struct platform_device
  */
 void usb_hcd_pxa27x_remove (struct usb_hcd *hcd, struct platform_device *pdev)
 {
-	struct pxa27x_ohci *ohci = to_pxa27x_ohci(hcd);
+	struct pxa27x_ohci *pxa_ohci = to_pxa27x_ohci(hcd);
 
 	usb_remove_hcd(hcd);
-	pxa27x_stop_hc(ohci, &pdev->dev);
+	pxa27x_stop_hc(pxa_ohci, &pdev->dev);
 	iounmap(hcd->regs);
 	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
+	clk_put(pxa_ohci->clk);
 	usb_put_hcd(hcd);
-	clk_put(ohci->clk);
-}
-
-/*-------------------------------------------------------------------------*/
-
-static int
-ohci_pxa27x_start (struct usb_hcd *hcd)
-{
-	struct ohci_hcd	*ohci = hcd_to_ohci (hcd);
-	int		ret;
-
-	ohci_dbg (ohci, "ohci_pxa27x_start, ohci:%p", ohci);
-
-	/* The value of NDP in roothub_a is incorrect on this hardware */
-	ohci->num_ports = 3;
-
-	if ((ret = ohci_init(ohci)) < 0)
-		return ret;
-
-	if ((ret = ohci_run (ohci)) < 0) {
-		dev_err(hcd->self.controller, "can't start %s",
-			hcd->self.bus_name);
-		ohci_stop (hcd);
-		return ret;
-	}
-
-	return 0;
 }
 
 /*-------------------------------------------------------------------------*/
 
-static const struct hc_driver ohci_pxa27x_hc_driver = {
-	.description =		hcd_name,
-	.product_desc =		"PXA27x OHCI",
-	.hcd_priv_size =	sizeof(struct pxa27x_ohci),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq =			ohci_irq,
-	.flags =		HCD_USB11 | HCD_MEMORY,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.start =		ohci_pxa27x_start,
-	.stop =			ohci_stop,
-	.shutdown =		ohci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue =		ohci_urb_enqueue,
-	.urb_dequeue =		ohci_urb_dequeue,
-	.endpoint_disable =	ohci_endpoint_disable,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number =	ohci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data =	ohci_hub_status_data,
-	.hub_control =		ohci_hub_control,
-#ifdef  CONFIG_PM
-	.bus_suspend =		ohci_bus_suspend,
-	.bus_resume =		ohci_bus_resume,
-#endif
-	.start_port_reset =	ohci_start_port_reset,
-};
-
-/*-------------------------------------------------------------------------*/
-
 static int ohci_hcd_pxa27x_drv_probe(struct platform_device *pdev)
 {
 	pr_debug ("In ohci_hcd_pxa27x_drv_probe");
@@ -563,38 +507,43 @@ static int ohci_hcd_pxa27x_drv_remove(struct platform_device *pdev)
 static int ohci_hcd_pxa27x_drv_suspend(struct device *dev)
 {
 	struct usb_hcd *hcd = dev_get_drvdata(dev);
-	struct pxa27x_ohci *ohci = to_pxa27x_ohci(hcd);
+	struct pxa27x_ohci *pxa_ohci = to_pxa27x_ohci(hcd);
 	bool do_wakeup = device_may_wakeup(dev);
+	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
 	int ret;
 
-	if (time_before(jiffies, ohci->ohci.next_statechange))
+	if (time_before(jiffies, ohci->next_statechange))
 		msleep(5);
-	ohci->ohci.next_statechange = jiffies;
+
+	ohci->next_statechange = jiffies;
 
 	ret = ohci_suspend(hcd, do_wakeup);
 	if (ret)
 		return ret;
 
-	pxa27x_stop_hc(ohci, dev);
+	pxa27x_stop_hc(pxa_ohci, dev);
 	return ret;
 }
 
 static int ohci_hcd_pxa27x_drv_resume(struct device *dev)
 {
 	struct usb_hcd *hcd = dev_get_drvdata(dev);
-	struct pxa27x_ohci *ohci = to_pxa27x_ohci(hcd);
+	struct pxa27x_ohci *pxa_ohci = to_pxa27x_ohci(hcd);
 	struct pxaohci_platform_data *inf = dev->platform_data;
+	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
 	int status;
 
-	if (time_before(jiffies, ohci->ohci.next_statechange))
+	if (time_before(jiffies, ohci->next_statechange))
 		msleep(5);
-	ohci->ohci.next_statechange = jiffies;
 
-	if ((status = pxa27x_start_hc(ohci, dev)) < 0)
+	ohci->next_statechange = jiffies;
+
+	status = pxa27x_start_hc(pxa_ohci, dev);
+	if (status < 0)
 		return status;
 
 	/* Select Power Management Mode */
-	pxa27x_ohci_select_pmm(ohci, inf->port_mode);
+	pxa27x_ohci_select_pmm(pxa_ohci, inf->port_mode);
 
 	ohci_resume(hcd, false);
 	return 0;
@@ -606,9 +555,6 @@ static const struct dev_pm_ops ohci_hcd_pxa27x_pm_ops = {
 };
 #endif
 
-/* work with hotplug and coldplug */
-MODULE_ALIAS("platform:pxa27x-ohci");
-
 static struct platform_driver ohci_hcd_pxa27x_driver = {
 	.probe		= ohci_hcd_pxa27x_drv_probe,
 	.remove		= ohci_hcd_pxa27x_drv_remove,
@@ -623,3 +569,27 @@ static struct platform_driver ohci_hcd_pxa27x_driver = {
 	},
 };
 
+static const struct ohci_driver_overrides pxa27x_overrides __initconst = {
+	.extra_priv_size =      sizeof(struct pxa27x_ohci),
+};
+
+static int __init ohci_pxa27x_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+	ohci_init_driver(&ohci_pxa27x_hc_driver, &pxa27x_overrides);
+	return platform_driver_register(&ohci_hcd_pxa27x_driver);
+}
+module_init(ohci_pxa27x_init);
+
+static void __exit ohci_pxa27x_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_pxa27x_driver);
+}
+module_exit(ohci_pxa27x_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:pxa27x-ohci");
-- 
1.7.9.5



From dinguyen at altera.com  Fri Jul 26 10:49:45 2013
From: dinguyen at altera.com (Dinh Nguyen)
Date: Fri, 26 Jul 2013 09:49:45 -0500
Subject: [PATCH] ARM: socfpga: dts: Add support for SD/MMC
In-Reply-To: <1374846562.3213.56.camel@hornet>
References: <1374789881-20611-1-git-send-email-dinguyen@altera.com>
 <1374846562.3213.56.camel@hornet>
Message-ID: <1374850185.20685.12.camel@linux-builds1>

Hi Pawel,

On Fri, 2013-07-26 at 14:49 +0100, Pawel Moll wrote:
> Hello Ding,

Dinh please...
> 
> Excuse me if the questions below were already asked and feel free to
> point me at the appropriate mail archive...
> 
> On Thu, 2013-07-25 at 23:04 +0100, dinguyen at altera.com wrote:
> > Add bindings for SD/MMC for SOCFPGA.
> > Add "syscon" to the "altr,sys-mgr" binding.
> 
> Are those two related? As in: what does the "syscon" bit have to do with
> "Add(ing) support for SD/MMC"? Should those two be separated?

You can reference these 2 threads:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168470.html
https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/035227.html

I hope that you will address your question for syscon.

> 
> > +* altr,dw-mshc-ciu-div: Specifies the divider value for the card interface
> > +  unit (ciu) clock. The value should be (n-1). For Altera's SOCFPGA, the divider
> > +  value is fixed at 3, which means parent_clock/4.
> 
> In what circumstances would this be different than 3? Is the interface
> in question member of the "hard part" of the SOFPGA, or is it supposed
> to be synthesized in the FPGA? 
> 
> > +* altr,dw-mshc-sdr-timing: Specifies the value of CIU clock phase shift value
> > +  in transmit mode and CIU clock phase shift value in receive mode for single
> > +  data rate mode operation. Refer to notes below for the order of the cells and the
> > +  valid values.
> > +
> > +  Notes for the sdr-timing values:
> > +
> > +    The order of the cells should be
> > +      - First Cell: CIU clock phase shift value for RX mode, smplsel bits in
> > +	the system manager SDMMC control group.
> > +      - Second Cell: CIU clock phase shift value for TX mode, drvsel bits in
> > +	the system manager SDMMC control group.
> > +
> > +    Valid values for SDR CIU clock timing for SOCFPGA:
> > +      - valid value for tx phase shift and rx phase shift is 0 to 7.
> 
> How does one pick those value? Do they depend on the board design? The
> FPGA synthesis options?

The sd/mmc is not in the FPGA at all, it is a hardened IP. The values
are implementation specific on how the IP is put down.

> 
> I am not trying to be picky, just trying to establish if those value are
> "hardware" enough to be present in the tree at all...

It is very much tied to the hardware.
> 
> I've also noticed that Exynos defines almost identical bindings:
> 
> > samsung,dw-mshc-ciu-div
> > samsung,dw-mshc-sdr-timing
> > samsung,dw-mshc-ddr-timing

Yes, I agree.
> 
> Aren't you both using the same "Synopsis Designware Mobile Storage Host
> Controller" by any chance? Are you sharing a driver? And if not,
> why? ;-) If the timings really must be parametrised, would it be
> possible to come up with a common set of "synopsis" properties, instead
> of "samsung" and "altr" ones? 

We are using the same driver. This is just a platform specifc entries
for how the IP can be implemented. I also agree that we can come up with
a shared set of properties for these.

But since the platform-driver part has already been picked into the
master tree, can I work on a common set after this patch? That way it
enables SD/MMC to work on SocFPGA for the time being.

Thanks alot for the review.

Dinh
> 
> Thanks for your time!
> 
> Pawel
> 
> 
> 





From broonie at kernel.org  Fri Jul 26 10:53:19 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Jul 2013 15:53:19 +0100
Subject: [PATCH V2 2/8] ASoC: Samsung: I2S: Add quirks as driver data in
 I2S
In-Reply-To: <1374845812-7803-3-git-send-email-padma.v@samsung.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-3-git-send-email-padma.v@samsung.com>
Message-ID: <20130726145319.GI9858@sirena.org.uk>

On Fri, Jul 26, 2013 at 07:06:46PM +0530, Padmavathi Venna wrote:
> Samsung has different versions of I2S introduced in different
> platforms. Each version has some new support added for multichannel,
> secondary fifo, s/w reset control and internal mux for rclk src clk.
> Each newly added change has a quirk. So this patch adds all the
> required quirks as driver data and based on compatible string from
> dtsi fetches the quirks.

As Russell indicated you should really keep the old name around, though
marking them as deprecated is OK.  However I'm not sure anyone will have
deployed this so I'm not sure how much it matters - every downstream
kernel I've seen was still using board files anyway.

The actual meat of the patch changing to a quirk scheme does look good,
though.

> -- compatible : "samsung,i2s-v5"
> +- compatible : should be one of the following.
> +   - samsung,s3c6410-i2s: for 8/16/24bit stereo I2S. Previous versions
> +     has only 8/16bit support.
> +   - samsung,s3c6410-i2sv4: for 8/16/24bit multichannel(5.1 channel) I2S.
> +     Introduced in s3c6410. This also applicable for s5p64x0 platforms.
> +   - samsung,s5pc100-i2s: for 8/16/24bit multichannel(5.1 channel) I2S
> +     with secondary fifo and s/w reset control.
> +   - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with
> +     secondary fifo, s/w reset control and internal mux for root clk src.
> +

I think the -vN naming scheme was fine - I see where this came from but
the main point was about having things identified by a string not
switching the naming scheme.  As you can see from the s3c6410 stuff the
SoC isn't that helpful as a naming scheme as multiple IP versions appear
on the same SoC.
-------------- 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/20130726/fc821e65/attachment.sig>

From linux at arm.linux.org.uk  Fri Jul 26 10:53:17 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 15:53:17 +0100
Subject: [PATCH 03/13] ARM: b.L: core switcher code
In-Reply-To: <1374550289-25305-4-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-4-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130726145317.GT24642@n2100.arm.linux.org.uk>

On Mon, Jul 22, 2013 at 11:31:19PM -0400, Nicolas Pitre wrote:
> To solve both issues, we borrow some of the task space belonging to
> the init/idle task which, by its nature, is lightly used and therefore
> is unlikely to clash with our usage.  The init task is also never going
> away.

That is... quite a horrid hack - and it is a hack.  You claim that
the idle task is not likely to clash, but with 8 CPUs each of
256 bytes of stack, that's 2k of stack.  With the thread data
structure at over 512 bytes, that's 2.5k of 8k.

Don't forget that the amount of kernel stack used depends on many
things - not just what the thread does (in the case of the idle
thread, that includes cpuidle stuff) but also the function call
depth of any interrupt in the system, as well as the path used to
get into the idle thread.

If you want to do this, it would be much better to use the bottom
of the stack space for the idle thread associated with the CPU.  The
idle threads are all forked at boot for any possible CPUs before the
secondaries are brought online, and so are persistent.  That would
reduce the additional required space to 256 bytes on the stack, not
2k on a single stack.

It also means that if we see larger clusters, we won't have this
in-built limitation caused by the size of the kernel stack.


From nicolas.pitre at linaro.org  Fri Jul 26 10:58:27 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 26 Jul 2013 10:58:27 -0400 (EDT)
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <20130725120424.GC2546@localhost.localdomain>
References: <20130718150408.GB2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181231510.14924@syhkavp.arg>
 <20130718180323.GC2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181452480.14924@syhkavp.arg>
 <20130719102844.GA3746@localhost.localdomain>
 <20130719105907.GB27389@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307221353360.15022@syhkavp.arg>
 <20130723104352.GA3023@localhost.localdomain>
 <alpine.LFD.2.03.1307230821270.15022@syhkavp.arg>
 <20130723163319.GA781@e102568-lin.cambridge.arm.com>
 <20130725120424.GC2546@localhost.localdomain>
Message-ID: <alpine.LFD.2.03.1307261047380.15022@syhkavp.arg>

On Thu, 25 Jul 2013, Dave Martin wrote:

> On Tue, Jul 23, 2013 at 05:33:19PM +0100, Lorenzo Pieralisi wrote:
> > On Tue, Jul 23, 2013 at 01:28:16PM +0100, Nicolas Pitre wrote:
> > 
> > [...]
> > 
> > > > > + * - The CPU is obviously no longer coherent with the other CPUs.
> > > > > + *
> > > > > + * Further considerations:
> > > > > + *
> > > > > + * - This relies on the presence and behavior of the AUXCR.SMP bit as
> > > > > + *   documented in the ARMv7 TRM.  Vendor implementations that deviate from
> > > > 
> > > > Sorry to be pedantic here, but there is no "ARMv7 TRM".  The SMP bit is
> > > > not part of ARMv7 at all.
> > > 
> > > Well, I just copied Lorenzo's words here, trusting he knew more about it 
> > > than I do.
> > > 
> > > > Also, it seems that A9 isn't precisely the
> > > > same: two ACTLR bits need to be twiddled.  R-class CPUs are generally
> > > > not the same either.
> > 
> > If you mean the ACTLR.FW bit in A9, A5, and R7, then, IIRC, we do not need to
> > clear it, clearing the SMP bit is enough.
> > 
> > See, Dave has a point, there is no explicit "unified v7 TRM disable
> > clean and exit coherency procedure" even though the designers end goal is to
> > have one and that's the one you wrote. The code you posted is perfectly ok on
> > all v7 implementations in the kernel I am aware of, I stand to be corrected
> > but to the best of my knowledge that's the case.
> 
> What I'm really concerned about here is not Cortex-*, but the vendors
> who have their own CPU implementations.  I don't think I've ever seen
> a TRM for one of those.

Could we wait until they materialize before worrying about possible 
incompatibility issues?  After all this is not a user space ABI that 
cannot be changed afterwards.  Remember this is Linux internal code we 
have the ability to change when needed, hence we should resist the 
temptation to over-engineer.

> I confess to exaggeration!  There was obviously an effort to align A15
> and A7, but we know there are differences at the system level, and there
> is always the possibility of b.L pairings which differ on things like
> the SMP bit, or b.L pairings of CPUs not originally designed to pair but
> which are "similar enough" to be pairable.
> 
> > sure about what we should do, but I reiterate my point, the sequence as
> > it stands is OK on all NS v7 implementations I am aware of. We can add
> > macros to differentiate processors when we need them, but again that's
> > just my opinion, as correct as it can be.
> 
> I still vote for naming them a15_* a7_* or similar.
> 
> For big.LITTLE pairings, I think we should assume that the big CPU's
> macro is usable on the LITTLE CPU too.  Assuming sane CPU designs, that
> will be true, and we know it works for A15+A7.

The MCPM backend don't have to assume any kind of pairing.  The TC2 
backend already has to test whether or not it is running on an A15 in 
order to turn off L2 prefetching which is an A15-only feature.  This is 
done outside of this macro exactly to keep the macro generic to all 
known (so far) v7 implementations.


Nicolas


From Dave.Martin at arm.com  Fri Jul 26 10:59:10 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Fri, 26 Jul 2013 15:59:10 +0100
Subject: [PATCH] ARM: kdgb: use .inst for data to be assembled as
 intruction
In-Reply-To: <51F2500E.5040107@codethink.co.uk>
References: <1374763778-5305-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374763778-5305-2-git-send-email-ben.dooks@codethink.co.uk>
 <20130725171130.GE2546@localhost.localdomain>
 <51F15CAE.7020008@codethink.co.uk>
 <20130725180912.GG2546@localhost.localdomain>
 <51F2500E.5040107@codethink.co.uk>
Message-ID: <20130726145910.GC2282@localhost.localdomain>

On Fri, Jul 26, 2013 at 11:31:42AM +0100, Ben Dooks wrote:
> On 25/07/13 19:09, Dave Martin wrote:
> >On Thu, Jul 25, 2013 at 06:13:18PM +0100, Ben Dooks wrote:
> >>On 25/07/13 18:11, Dave Martin wrote:
> >>>On Thu, Jul 25, 2013 at 03:49:38PM +0100, Ben Dooks wrote:
> >>>>The arch_kgdb_breakpoint() function uses an inline assembly directive
> >>>>to assemble a specific instruction using .word. This means the linker
> >>>>will not treat is as an instruction, and therefore incorrectly swap
> >>>>the endian-ness if running BE8.
> >>>>
> >>>>Note, not tested, please comment if this is wrong.
> >>>>
> >>>>Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
> >>>>---
> >>>>  arch/arm/include/asm/kgdb.h |    2 +-
> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>>diff --git a/arch/arm/include/asm/kgdb.h b/arch/arm/include/asm/kgdb.h
> >>>>index 48066ce..76227c8 100644
> >>>>--- a/arch/arm/include/asm/kgdb.h
> >>>>+++ b/arch/arm/include/asm/kgdb.h
> >>>>@@ -41,7 +41,7 @@
> >>>>
> >>>>  static inline void arch_kgdb_breakpoint(void)
> >>>>  {
> >>>>-	asm(".word 0xe7ffdeff");
> >>>>+	asm(".inst 0xe7ffdeff");
> >>>
> >>>Yikes, this isn't going to work in a Thumb kernel.
> >>>
> >>>We should make HAVE_ARCH_KGDB depend on !THUMB2_KERNEL until/unless that
> >>>gets fixed...  It looks like the incompatibilities may be more extensive
> >>>than just this one instruction.
> >>>
> >>>
> >>>For the ARM case, similarly to the other patches, please use the __inst
> >>>macros from<asm/opcodes.h>   instead of emitting the opcode explicitly.
> >>
> >>See previous objections to that, plus they're marked for internal use
> >>only!
> >
> >Ditto my counterarguments.  I'm not emotionally attached to __inst*(), but
> >we should use one or the other: either .inst or __inst(), not a mixture.
> >However, the __inst macros work for inline asm and .S, and do more than
> >just emitting a single opcode; see opcodes-virt.h for example, so while
> >removing them isn't rocket science, it would involve churn in a few places.
> >
> >
> >Note, the "Don't use these directly" comment only applies to the triple-
> >underscored helpers.
> >
> >The broader "using these macros directly is poor practice" comment was
> >an attempt to engourage people to write the likes of
> >
> >#define __KGDB_BKPT_INSTR __inst_arm(0xxe7ffdeff)
> >
> >static inline void arch_kgdb_breakpoint(void)
> >{
> >	asm(__KGDB_BKPT_INSTR);
> >}
> >
> >...on the basis that this ought to be more readable.
> >
> >But this is a bit moot in a situation like this where the opcode is
> >only used in one place, by itself, in a wrapper whose name makes the
> >intent clear anyway.
> 
> Ok, I will look into changing the patches in the next day or so
> and do the same fixes for kprobes.

OK, thanks.

Cheers
---Dave


From pawel.moll at arm.com  Fri Jul 26 11:00:02 2013
From: pawel.moll at arm.com (Pawel Moll)
Date: Fri, 26 Jul 2013 16:00:02 +0100
Subject: [PATCH] ARM: socfpga: dts: Add support for SD/MMC
In-Reply-To: <1374850185.20685.12.camel@linux-builds1>
References: <1374789881-20611-1-git-send-email-dinguyen@altera.com>
 <1374846562.3213.56.camel@hornet> <1374850185.20685.12.camel@linux-builds1>
Message-ID: <1374850802.3213.87.camel@hornet>

On Fri, 2013-07-26 at 15:49 +0100, Dinh Nguyen wrote:
> Dinh please...

Uh, accept my apologies. I know exactly how it feels ;-)

> > I've also noticed that Exynos defines almost identical bindings:
> > 
> > > samsung,dw-mshc-ciu-div
> > > samsung,dw-mshc-sdr-timing
> > > samsung,dw-mshc-ddr-timing
> 
> Yes, I agree.
> > 
> > Aren't you both using the same "Synopsis Designware Mobile Storage Host
> > Controller" by any chance? Are you sharing a driver? And if not,
> > why? ;-) If the timings really must be parametrised, would it be
> > possible to come up with a common set of "synopsis" properties, instead
> > of "samsung" and "altr" ones? 
> 
> We are using the same driver. This is just a platform specifc entries
> for how the IP can be implemented. I also agree that we can come up with
> a shared set of properties for these.
> 
> But since the platform-driver part has already been picked into the
> master tree, can I work on a common set after this patch? That way it
> enables SD/MMC to work on SocFPGA for the time being.

Ah, I see. You should have included the binding documentation in the
driver using the bindings, not in the patch adding the required nodes to
DTS files... Than no one would have any comments on this patch ;-)

So yes, if the driver part got merged I will shut up now, providing you
promise to work on "consolidating" the bindings for the next cycle. The
sooner, the better. Does it sound like a deal?

Pawel




From nicolas.pitre at linaro.org  Fri Jul 26 11:00:48 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 26 Jul 2013 11:00:48 -0400 (EDT)
Subject: [RFC PATCH 3/3] cpuidle: big.LITTLE: vexpress-TC2 CPU idle driver
In-Reply-To: <1374750866-750-4-git-send-email-lorenzo.pieralisi@arm.com>
References: <1374750866-750-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374750866-750-4-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <alpine.LFD.2.03.1307261058510.15022@syhkavp.arg>

On Thu, 25 Jul 2013, Lorenzo Pieralisi wrote:

> +static int notrace bl_powerdown_finisher(unsigned long arg)
> +{
> +	/* MCPM works with HW CPU identifiers */
> +	unsigned int mpidr = read_cpuid_mpidr();
> +	unsigned int cluster = (mpidr >> 8) & 0xf;
> +	unsigned int cpu = mpidr & 0xf;

You probably want to use the MPIDR_AFFINITY_LEVEL() macro here.


Nicolas


From t.figa at samsung.com  Fri Jul 26 11:02:46 2013
From: t.figa at samsung.com (Tomasz Figa)
Date: Fri, 26 Jul 2013 17:02:46 +0200
Subject: [PATCH V2 2/8] ASoC: Samsung: I2S: Add quirks as driver data in
 I2S
In-Reply-To: <20130726145319.GI9858@sirena.org.uk>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-3-git-send-email-padma.v@samsung.com>
 <20130726145319.GI9858@sirena.org.uk>
Message-ID: <1417636.4d7IlsSAyI@amdc1227>

On Friday 26 of July 2013 15:53:19 Mark Brown wrote:
> On Fri, Jul 26, 2013 at 07:06:46PM +0530, Padmavathi Venna wrote:
> > Samsung has different versions of I2S introduced in different
> > platforms. Each version has some new support added for multichannel,
> > secondary fifo, s/w reset control and internal mux for rclk src clk.
> > Each newly added change has a quirk. So this patch adds all the
> > required quirks as driver data and based on compatible string from
> > dtsi fetches the quirks.
> 
> As Russell indicated you should really keep the old name around, though
> marking them as deprecated is OK.  However I'm not sure anyone will have
> deployed this so I'm not sure how much it matters - every downstream
> kernel I've seen was still using board files anyway.
> 
> The actual meat of the patch changing to a quirk scheme does look good,
> though.
> 
> > -- compatible : "samsung,i2s-v5"
> > +- compatible : should be one of the following.
> > +   - samsung,s3c6410-i2s: for 8/16/24bit stereo I2S. Previous versions
> > +     has only 8/16bit support.
> > +   - samsung,s3c6410-i2sv4: for 8/16/24bit multichannel(5.1 channel)
> > I2S. +     Introduced in s3c6410. This also applicable for s5p64x0
> > platforms. +   - samsung,s5pc100-i2s: for 8/16/24bit multichannel(5.1
> > channel) I2S +     with secondary fifo and s/w reset control.
> > +   - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with
> > +     secondary fifo, s/w reset control and internal mux for root clk
> > src. +
> 
> I think the -vN naming scheme was fine - I see where this came from but
> the main point was about having things identified by a string not
> switching the naming scheme.  As you can see from the s3c6410 stuff the
> SoC isn't that helpful as a naming scheme as multiple IP versions appear
> on the same SoC.

IMHO this SoC-based identification looks much better, especially considering 
the fact that IP version isn't something easily determinable, as even the 
documentation can sometimes be not really clear about that.

However the s3c6410-i2sv4 string looks a bit unfortunate. AFAIK there were 
two types of I2S IPs on S3C6410 - normal I2S and I2S multichannel. What 
about having a compatible like s3c6410-i2s-multi?

Best regards,
Tomasz



From broonie at kernel.org  Fri Jul 26 11:05:48 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Jul 2013 16:05:48 +0100
Subject: [PATCH V2 4/8] ASoC: Samsung: I2S: Modify driver to give more
 flexibility
In-Reply-To: <1374845812-7803-5-git-send-email-padma.v@samsung.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-5-git-send-email-padma.v@samsung.com>
Message-ID: <20130726150548.GK9858@sirena.org.uk>

On Fri, Jul 26, 2013 at 07:06:48PM +0530, Padmavathi Venna wrote:
> This patch modifies the i2s driver to give flexibility towards register
> handling. This is a pre requirement for enabling i2s support on Exynos5420.
> This patch modifies only the required registers as a pre-requirement to
> support on Exynos5420.

Applied, thanks.
-------------- 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/20130726/a9f9f4a5/attachment.sig>

From linux at arm.linux.org.uk  Fri Jul 26 11:10:21 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 16:10:21 +0100
Subject: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes
In-Reply-To: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <20130726151021.GU24642@n2100.arm.linux.org.uk>

On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
> PFNs but that breaks the dma_mask for few block layer drivers since
> ARM start of physical memory is not PFN0 unlike most of the architectures.
> Some more read on it is here:
> 	http://lwn.net/Articles/543408/
> 	http://lwn.net/Articles/543424/
> 
> To address this issue, we introduce generic dma_max_pfn() helper which
> can be overridden from the architectures.
> 	
> Another intention behind move to nobootmem is also to convert ARM to
> switch to memblock and getting rid of bootmem allocator dependency which
> don't work for LPAE machines which has physical memory starting beyond
> 4 GB boundary. It needs changes to core kernel and also a new memblock
> API. More on this can be found here:
> 	https://lkml.org/lkml/2013/6/29/77
> 
> I have been trying to cook up these patches with kind help from Russell
> and we know series don't solve all the dma_mask bad assumptions. But at
> least I am hoping that it can get the ball rolling.	
> 
> Comments/testing help is welcome !!

As this is related to some of the cleanup of dma_mask which I've been
doing, I think it may make sense to roll this into one tree.  Any
objection to that?

Can we get any acks on this stuff from Jens and Jejb etc - especially
for the bits which touch block/ and for the scsi bits as these are
touching other subsystems.  (oddly, linux-scsi wasn't on the original
mail for this series summary.)


From nicolas.pitre at linaro.org  Fri Jul 26 11:10:53 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 26 Jul 2013 11:10:53 -0400 (EDT)
Subject: [PATCH 03/13] ARM: b.L: core switcher code
In-Reply-To: <20130726145317.GT24642@n2100.arm.linux.org.uk>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-4-git-send-email-nicolas.pitre@linaro.org>
 <20130726145317.GT24642@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.03.1307261101550.15022@syhkavp.arg>

On Fri, 26 Jul 2013, Russell King - ARM Linux wrote:

> On Mon, Jul 22, 2013 at 11:31:19PM -0400, Nicolas Pitre wrote:
> > To solve both issues, we borrow some of the task space belonging to
> > the init/idle task which, by its nature, is lightly used and therefore
> > is unlikely to clash with our usage.  The init task is also never going
> > away.
> 
> That is... quite a horrid hack - and it is a hack.  You claim that
> the idle task is not likely to clash, but with 8 CPUs each of
> 256 bytes of stack, that's 2k of stack.  With the thread data
> structure at over 512 bytes, that's 2.5k of 8k.

It is a hack indeed.  This way of doing things does not survive until 
the end of the patch series either.  But doing this for the actual first 
switcher patch makes the code much simpler to review.

> Don't forget that the amount of kernel stack used depends on many
> things - not just what the thread does (in the case of the idle
> thread, that includes cpuidle stuff) but also the function call
> depth of any interrupt in the system, as well as the path used to
> get into the idle thread.
> 
> If you want to do this, it would be much better to use the bottom
> of the stack space for the idle thread associated with the CPU.  The
> idle threads are all forked at boot for any possible CPUs before the
> secondaries are brought online, and so are persistent.  That would
> reduce the additional required space to 256 bytes on the stack, not
> 2k on a single stack.

What I do in a later patch is to use dedicated switcher threads per 
logical CPU, and the separate stack is taken from each thread's stack.  
That also means that only 2 special stack areas are needed instead of 8 
or more.

But kernel threads are introduced as a separate patch to ease review.


Nicolas


From domenico.andreoli at linux.com  Fri Jul 26 10:56:40 2013
From: domenico.andreoli at linux.com (Domenico Andreoli)
Date: Fri, 26 Jul 2013 16:56:40 +0200
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build arch/arm/mach-bcm
References: <20130726145639.116237136@gmail.com>
Message-ID: <20130726151223.045835540@gmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: arm-unconditionally-build-in-mach-bcm.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/0f13451e/attachment.ksh>

From domenico.andreoli at linux.com  Fri Jul 26 10:56:43 2013
From: domenico.andreoli at linux.com (Domenico Andreoli)
Date: Fri, 26 Jul 2013 16:56:43 +0200
Subject: [PATCH v2 4/5] ARM: bcm4760: Add ripple counter
References: <20130726145639.116237136@gmail.com>
Message-ID: <20130726151223.989748726@gmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: arm-bcm476x-add-ripple-counter.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/202cecb9/attachment.ksh>

From domenico.andreoli at linux.com  Fri Jul 26 10:56:39 2013
From: domenico.andreoli at linux.com (Domenico Andreoli)
Date: Fri, 26 Jul 2013 16:56:39 +0200
Subject: [PATCH v2 0/5] ARM: Broadcom BCM4760 support
Message-ID: <20130726145639.116237136@gmail.com>

Hi all,

  this is my best proposal for the BCM4760 SoC support so far.

I think I've addressed all the comments made to the previous
patches. Details of the changes since v1 are in each patch.

Ehm... if possible, please review. Thank you.

Best regards,
Domenico


From domenico.andreoli at linux.com  Fri Jul 26 10:56:42 2013
From: domenico.andreoli at linux.com (Domenico Andreoli)
Date: Fri, 26 Jul 2013 16:56:42 +0200
Subject: [PATCH v2 3/5] ARM: bcm4760: Add system timer
References: <20130726145639.116237136@gmail.com>
Message-ID: <20130726151223.607806229@gmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: arm-bcm476x-add-system-timer.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/7d59c5a0/attachment.ksh>

From domenico.andreoli at linux.com  Fri Jul 26 10:56:44 2013
From: domenico.andreoli at linux.com (Domenico Andreoli)
Date: Fri, 26 Jul 2013 16:56:44 +0200
Subject: [PATCH v2 5/5] ARM: bcm4760: Add restart hook
References: <20130726145639.116237136@gmail.com>
Message-ID: <20130726151224.265718946@gmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: arm-bcm476x-add-restart-hook.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/6647443a/attachment.ksh>

From domenico.andreoli at linux.com  Fri Jul 26 10:56:41 2013
From: domenico.andreoli at linux.com (Domenico Andreoli)
Date: Fri, 26 Jul 2013 16:56:41 +0200
Subject: [PATCH v2 2/5] ARM: bcm4760: Add platform infrastructure
References: <20130726145639.116237136@gmail.com>
Message-ID: <20130726151223.309761068@gmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: arm-bcm476x-add-infrastructure.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/af3ec8a5/attachment.ksh>

From swarren at wwwdotorg.org  Fri Jul 26 11:16:36 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 09:16:36 -0600
Subject: [PATCH V2] ARM: dts: tegra114: dalmore: fix the irq trigger type
 of Palmas MFD device
In-Reply-To: <1374663272-9937-1-git-send-email-josephl@nvidia.com>
References: <1374663272-9937-1-git-send-email-josephl@nvidia.com>
Message-ID: <51F292D4.9030208@wwwdotorg.org>

On 07/24/2013 04:54 AM, Joseph Lo wrote:
> The IRQ trigger type of Palmas MFD device (tps65913) is edge trigger. The
> wrong configuration would cause an interrupt storm when booting the
> system. Fixing it in DT with appropriate interrupt type.

> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts

>  		palmas: tps65913 {
>  			compatible = "ti,palmas";
>  			reg = <0x58>;
> -			interrupts = <0 86 0x4>;
> +			interrupts = <0 86 0x0>;

The legal values for that final cell are:

    - bits[3:0] trigger type and level flags
        1 = low-to-high edge triggered
        2 = high-to-low edge triggered
        4 = active high level-sensitive
        8 = active low level-sensitive

0 isn't one of those values. This patch can't be correct.

BTW, this cell should use the constants from
<dt-bindings/interrupt-controller/irq.h>.


From lorenzo.pieralisi at arm.com  Fri Jul 26 11:18:39 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 26 Jul 2013 16:18:39 +0100
Subject: [PATCH 05/13] ARM: bL_switcher: move to dedicated threads rather
 than workqueues
In-Reply-To: <1374550289-25305-6-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-6-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130726151838.GC28084@e102568-lin.cambridge.arm.com>

On Tue, Jul 23, 2013 at 04:31:21AM +0100, Nicolas Pitre wrote:
> The workqueues are problematic as they may be contended.
> They can't be scheduled with top priority either.  Also the optimization
> in bL_switch_request() to skip the workqueue entirely when the target CPU
> and the calling CPU were the same didn't allow for bL_switch_request() to
> be called from atomic context, as might be the case for some cpufreq
> drivers.
> 
> Let's move to dedicated kthreads instead.
> 
> Signed-off-by: Nicolas Pitre <nico at linaro.org>
> ---
>  arch/arm/common/bL_switcher.c      | 101 ++++++++++++++++++++++++++++---------
>  arch/arm/include/asm/bL_switcher.h |   2 +-
>  2 files changed, 79 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> index d6f7e507d9..c2355cafc9 100644
> --- a/arch/arm/common/bL_switcher.c
> +++ b/arch/arm/common/bL_switcher.c
> @@ -15,8 +15,10 @@
>  #include <linux/sched.h>
>  #include <linux/interrupt.h>
>  #include <linux/cpu_pm.h>
> +#include <linux/cpu.h>
>  #include <linux/cpumask.h>
> -#include <linux/workqueue.h>
> +#include <linux/kthread.h>
> +#include <linux/wait.h>
>  #include <linux/clockchips.h>
>  #include <linux/hrtimer.h>
>  #include <linux/tick.h>
> @@ -225,15 +227,48 @@ static int bL_switch_to(unsigned int new_cluster_id)
>  	return ret;
>  }
>  
> -struct switch_args {
> -	unsigned int cluster;
> -	struct work_struct work;
> +struct bL_thread {
> +	struct task_struct *task;
> +	wait_queue_head_t wq;
> +	int wanted_cluster;
>  };
>  
> -static void __bL_switch_to(struct work_struct *work)
> +static struct bL_thread bL_threads[MAX_CPUS_PER_CLUSTER];
> +
> +static int bL_switcher_thread(void *arg)
> +{
> +	struct bL_thread *t = arg;
> +	struct sched_param param = { .sched_priority = 1 };
> +	int cluster;
> +
> +	sched_setscheduler_nocheck(current, SCHED_FIFO, &param);
> +
> +	do {
> +		if (signal_pending(current))
> +			flush_signals(current);
> +		wait_event_interruptible(t->wq,
> +				t->wanted_cluster != -1 ||
> +				kthread_should_stop());
> +		cluster = xchg(&t->wanted_cluster, -1);
> +		if (cluster != -1)
> +			bL_switch_to(cluster);
> +	} while (!kthread_should_stop());
> +
> +	return 0;
> +}
> +
> +static struct task_struct * __init bL_switcher_thread_create(int cpu, void *arg)
>  {
> -	struct switch_args *args = container_of(work, struct switch_args, work);
> -	bL_switch_to(args->cluster);
> +	struct task_struct *task;
> +
> +	task = kthread_create_on_node(bL_switcher_thread, arg,
> +				      cpu_to_node(cpu), "kswitcher_%d", cpu);
> +	if (!IS_ERR(task)) {
> +		kthread_bind(task, cpu);
> +		wake_up_process(task);
> +	} else
> +		pr_err("%s failed for CPU %d\n", __func__, cpu);
> +	return task;
>  }
>  
>  /*
> @@ -242,26 +277,46 @@ static void __bL_switch_to(struct work_struct *work)
>   * @cpu: the CPU to switch
>   * @new_cluster_id: the ID of the cluster to switch to.
>   *
> - * This function causes a cluster switch on the given CPU.  If the given
> - * CPU is the same as the calling CPU then the switch happens right away.
> - * Otherwise the request is put on a work queue to be scheduled on the
> - * remote CPU.
> + * This function causes a cluster switch on the given CPU by waking up
> + * the appropriate switcher thread.  This function may or may not return
> + * before the switch has occurred.
>   */
> -void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
> +int bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
>  {
> -	unsigned int this_cpu = get_cpu();
> -	struct switch_args args;
> +	struct bL_thread *t;
>  
> -	if (cpu == this_cpu) {
> -		bL_switch_to(new_cluster_id);
> -		put_cpu();
> -		return;
> +	if (cpu >= MAX_CPUS_PER_CLUSTER) {
> +		pr_err("%s: cpu %d out of bounds\n", __func__, cpu);
> +		return -EINVAL;
>  	}
> -	put_cpu();
>  
> -	args.cluster = new_cluster_id;
> -	INIT_WORK_ONSTACK(&args.work, __bL_switch_to);
> -	schedule_work_on(cpu, &args.work);
> -	flush_work(&args.work);
> +	t = &bL_threads[cpu];
> +	if (IS_ERR(t->task))
> +		return PTR_ERR(t->task);
> +	if (!t->task)
> +		return -ESRCH;
> +
> +	t->wanted_cluster = new_cluster_id;
> +	wake_up(&t->wq);
> +	return 0;
>  }
>  EXPORT_SYMBOL_GPL(bL_switch_request);
> +
> +static int __init bL_switcher_init(void)
> +{
> +	int cpu;
> +
> +	pr_info("big.LITTLE switcher initializing\n");
> +
> +	for_each_online_cpu(cpu) {
> +		struct bL_thread *t = &bL_threads[cpu];
> +		init_waitqueue_head(&t->wq);

Dereferencing &bL_threads[cpu] is wrong without checking the cpu index against
MAX_CPUS_PER_CLUSTER. I know you hotplug out half of the CPUs in a later patch but
still, this code needs fixing.

> +		t->wanted_cluster = -1;
> +		t->task = bL_switcher_thread_create(cpu, t);
> +	}
> +
> +	pr_info("big.LITTLE switcher initialized\n");
> +	return 0;
> +}
> +
> +late_initcall(bL_switcher_init);
> diff --git a/arch/arm/include/asm/bL_switcher.h b/arch/arm/include/asm/bL_switcher.h
> index 72efe3f349..e0c0bba70b 100644
> --- a/arch/arm/include/asm/bL_switcher.h
> +++ b/arch/arm/include/asm/bL_switcher.h
> @@ -12,6 +12,6 @@
>  #ifndef ASM_BL_SWITCHER_H
>  #define ASM_BL_SWITCHER_H
>  
> -void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id);
> +int bL_switch_request(unsigned int cpu, unsigned int new_cluster_id);

We probably discussed this before, and it is not strictly related to
this patch, but is locking/queuing necessary when requesting a switch ? I do
not remember the outcome of the discussion so I am asking again.

I will go through this patch in details later.

Lorenzo



From broonie at kernel.org  Fri Jul 26 11:19:02 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Jul 2013 16:19:02 +0100
Subject: [PATCH V2 7/8] ARM: dts: wm8994: Add wm8994 support on smdk5420
In-Reply-To: <1374845812-7803-8-git-send-email-padma.v@samsung.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-8-git-send-email-padma.v@samsung.com>
Message-ID: <20130726151902.GL9858@sirena.org.uk>

On Fri, Jul 26, 2013 at 07:06:51PM +0530, Padmavathi Venna wrote:
> This patch adds wm8994 codec node on i2c bus1 and the required
> regulator supplies and properties on smdk5420 board.

This isn't a device tree patch for WM8994, it's a patch for the
SMDK5420.

> +	vdd: fixed-regulator at 0 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vdd-supply";

These names look wrong - they should reflect the names in the schematic
as they're for human comprehensibility.  This may just be a case of
dropping the -supply.

> +		wm8994: wm8994 at 1a {
> +			compatible = "wlf,wm8994";
> +			reg = <0x1a>;
> +
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +
> +			AVDD2-supply = <&vdd>;
> +			CPVDD-supply = <&vdd>;
> +			DBVDD-supply = <&dbvdd>;
> +			SPKVDD1-supply = <&spkvdd>;
> +			SPKVDD2-supply = <&spkvdd>;
> +		};

It would be helpful to also add a clock binding (I posted a binding
documentation update the other day, it's in my tree now) but it's not
essential and I suspect it needs some work on the clock driver side
still.
-------------- 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/20130726/ae020c5c/attachment-0001.sig>

From broonie at kernel.org  Fri Jul 26 11:25:51 2013
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Jul 2013 16:25:51 +0100
Subject: [PATCH V2 2/8] ASoC: Samsung: I2S: Add quirks as driver data in
 I2S
In-Reply-To: <1417636.4d7IlsSAyI@amdc1227>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-3-git-send-email-padma.v@samsung.com>
 <20130726145319.GI9858@sirena.org.uk> <1417636.4d7IlsSAyI@amdc1227>
Message-ID: <20130726152551.GM9858@sirena.org.uk>

On Fri, Jul 26, 2013 at 05:02:46PM +0200, Tomasz Figa wrote:

> IMHO this SoC-based identification looks much better, especially considering 
> the fact that IP version isn't something easily determinable, as even the 
> documentation can sometimes be not really clear about that.

Yeah, it's not terribly clever either way.  We've been using the version
numbers in audio for a long time partly because it is documented
sometimes and partly because most of the SoCs tend to have one fully
featured controller and a bunch of secondary controllers on older IP
revisions.

> However the s3c6410-i2sv4 string looks a bit unfortunate. AFAIK there were 
> two types of I2S IPs on S3C6410 - normal I2S and I2S multichannel. What 
> about having a compatible like s3c6410-i2s-multi?

It was explicitly identified as I2Sv4 in the S3C6410 datasheet so no
real issue there.
-------------- 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/20130726/0034ce34/attachment.sig>

From dinguyen at altera.com  Fri Jul 26 11:27:25 2013
From: dinguyen at altera.com (Dinh Nguyen)
Date: Fri, 26 Jul 2013 10:27:25 -0500
Subject: [PATCH] ARM: socfpga: dts: Add support for SD/MMC
In-Reply-To: <1374850802.3213.87.camel@hornet>
References: <1374789881-20611-1-git-send-email-dinguyen@altera.com>
 <1374846562.3213.56.camel@hornet> <1374850185.20685.12.camel@linux-builds1>
 <1374850802.3213.87.camel@hornet>
Message-ID: <1374852445.20685.18.camel@linux-builds1>

On Fri, 2013-07-26 at 16:00 +0100, Pawel Moll wrote:
> On Fri, 2013-07-26 at 15:49 +0100, Dinh Nguyen wrote:
> > Dinh please...
> 
> Uh, accept my apologies. I know exactly how it feels ;-)
> 
> > > I've also noticed that Exynos defines almost identical bindings:
> > > 
> > > > samsung,dw-mshc-ciu-div
> > > > samsung,dw-mshc-sdr-timing
> > > > samsung,dw-mshc-ddr-timing
> > 
> > Yes, I agree.
> > > 
> > > Aren't you both using the same "Synopsis Designware Mobile Storage Host
> > > Controller" by any chance? Are you sharing a driver? And if not,
> > > why? ;-) If the timings really must be parametrised, would it be
> > > possible to come up with a common set of "synopsis" properties, instead
> > > of "samsung" and "altr" ones? 
> > 
> > We are using the same driver. This is just a platform specifc entries
> > for how the IP can be implemented. I also agree that we can come up with
> > a shared set of properties for these.
> > 
> > But since the platform-driver part has already been picked into the
> > master tree, can I work on a common set after this patch? That way it
> > enables SD/MMC to work on SocFPGA for the time being.
> 
> Ah, I see. You should have included the binding documentation in the
> driver using the bindings, not in the patch adding the required nodes to
> DTS files... Than no one would have any comments on this patch ;-)
> 
> So yes, if the driver part got merged I will shut up now, providing you
> promise to work on "consolidating" the bindings for the next cycle. The
> sooner, the better. Does it sound like a deal?

Yes, you have my promise on the consolidating work! I was also thinking
the same thing when I enabled this for SOCFPGA, but since I don't have
any Exynos HW, I didn't have a way to test. But I will work on a patch
soon and send to the Exynos people to test.

Thanks,
Dinh
> 
> Pawel
> 
> 
> 





From jason at lakedaemon.net  Fri Jul 26 11:29:18 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 26 Jul 2013 11:29:18 -0400
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726151223.045835540@gmail.com>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
Message-ID: <20130726152918.GL29916@titan.lakedaemon.net>

On Fri, Jul 26, 2013 at 04:56:40PM +0200, Domenico Andreoli wrote:
> From: Domenico Andreoli <domenico.andreoli at linux.com>
> 
> arch/arm/mach-bcm contains a plurality of Broadcom SoCs, each configured
> separately. As a matter of flexibility and maintenance, it needs to be
> always included in the build.

So if I'm building mach-kirkwood, I _have_ to build Broadcom?  What is
the *specific* problem you're encountering that this solves?

Notice:

$ git grep '^machine-y'
$

thx,

Jason.

> Cc: Christian Daudt <csd at broadcom.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Domenico Andreoli <domenico.andreoli at linux.com>
> ---
>  arch/arm/Makefile |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: b/arch/arm/Makefile
> ===================================================================
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x0020
>  # Machine directory name.  This list is sorted alphanumerically
>  # by CONFIG_* macro name.
>  machine-$(CONFIG_ARCH_AT91)		+= at91
> -machine-$(CONFIG_ARCH_BCM)		+= bcm
> +machine-y				+= bcm
>  machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
>  machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
>  machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From jason at lakedaemon.net  Fri Jul 26 11:33:02 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 26 Jul 2013 11:33:02 -0400
Subject: [PATCH v2 0/5] ARM: Broadcom BCM4760 support
In-Reply-To: <20130726145639.116237136@gmail.com>
References: <20130726145639.116237136@gmail.com>
Message-ID: <20130726153302.GM29916@titan.lakedaemon.net>

Domenico,

On Fri, Jul 26, 2013 at 04:56:39PM +0200, Domenico Andreoli wrote:
> Hi all,
> 
>   this is my best proposal for the BCM4760 SoC support so far.
> 
> I think I've addressed all the comments made to the previous
> patches. Details of the changes since v1 are in each patch.
> 
> Ehm... if possible, please review. Thank you.

Please separate devicetree binding documentation from code changes and
make sure those patches are Cc:'d to devicetree at vger.kernel.org.

thx,

Jason.


From Dave.Martin at arm.com  Fri Jul 26 11:34:40 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Fri, 26 Jul 2013 16:34:40 +0100
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value to
 index into save array
In-Reply-To: <alpine.LFD.2.03.1307261032330.15022@syhkavp.arg>
References: <alpine.LFD.2.03.1307251203550.15022@syhkavp.arg>
 <20130726113110.GB28084@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307261032330.15022@syhkavp.arg>
Message-ID: <20130726153440.GD2282@localhost.localdomain>

On Fri, Jul 26, 2013 at 10:41:38AM -0400, Nicolas Pitre wrote:
> On Fri, 26 Jul 2013, Lorenzo Pieralisi wrote:
> 
> > On Thu, Jul 25, 2013 at 05:06:51PM +0100, Nicolas Pitre wrote:
> > > On Thu, 25 Jul 2013, Dave Martin wrote:
> > > 
> > > > On Wed, Jul 24, 2013 at 02:55:00PM -0400, Nicolas Pitre wrote:
> > > > > On Wed, 24 Jul 2013, Dave Martin wrote:
> > > > > 
> > > > > > But this patch commits us to requiring that on the suspend path 
> > > > > > specifically -- I think that ought to be mentioned somewhere. A 
> > > > > > comment in the preamble for __cpu_suspend would be enough, I think.
> > > > > 
> > > > > What comment would you suggest?  I want to make sure the possible 
> > > > > confusion you see is properly addressed.
> > > > 
> > > > I think we just need to state that the value of
> > > > cpu_logical_map(smp_processor_id()) must be the MPIDR of the physical
> > > > CPU the suspending logical CPU will resume on.  Consequently, if doing a
> > > > migration, cpu_logical_map() must be updated appropriately somewhere
> > > > between cpu_pm_enter() and cpu_suspend().
> > > 
> > > Excellent.  I've amended the patch with this:
> > > 
> > > diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
> > > index 2835d35234..caf938db62 100644
> > > --- a/arch/arm/kernel/suspend.c
> > > +++ b/arch/arm/kernel/suspend.c
> > > @@ -17,6 +17,11 @@ extern void cpu_resume_mmu(void);
> > >  /*
> > >   * Hide the first two arguments to __cpu_suspend - these are an implementation
> > >   * detail which platform code shouldn't have to know about.
> > > + *
> > > + * On SMP systems, the value of cpu_logical_map(smp_processor_id()) must be
> > > + * the MPIDR of the physical CPU the suspending logical CPU will resume on.
> > > + * Consequently, if doing a physical CPU migration, cpu_logical_map() must be
> > > + * updated appropriately somewhere between cpu_pm_enter() and cpu_suspend().
> > >   */
> > >  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> > >  {
> > > 
> > > I've put it against cpu_suspend() rather than __cpu_suspend(() as this 
> > > is what users should care about.
> > > 
> > > ACK?
> > 
> > We need this patch to allow IKS to store a cpu context at a specific
> > index, let's be honest. It is a moot point and I am not very happy
> > about changing this code for a very specific usage, but the way code is
> > implemented makes the change acceptable. I really do not think we should
> > write guidelines on how cpu_suspend users have to change cpu_logical_map
> > though, that's not needed apart from IKS and that should be limited to IKS
> > code only.
> > 
> > Again, that's just my opinion, but cpu_suspend API must be kept as it is
> > and we should not encourage people to use it in creative ways.
> 
> I tend to agree, but I'm now stuck between two conflicting requests.

Would it make sense to keep the same API to cpu_suspend(), but make it
a wrapper for another function which has the MPIDR argument?  Then people
calling cpu_suspend() continue as normal.  Only IKS needs to know about
the underlying MPIDR handling when calling this.

Cheers
---Dave

> 
> Are you saying you are willing to give me your ACK if I revert the 
> suggested change?
> 
> 
> Nicolas


From robherring2 at gmail.com  Fri Jul 26 11:36:53 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 26 Jul 2013 10:36:53 -0500
Subject: [PATCH RESEND v2] ARM: dt: Use the 'model' field for printing the
 hardware revision
In-Reply-To: <1374844784-2639-1-git-send-email-festevam@gmail.com>
References: <1374844784-2639-1-git-send-email-festevam@gmail.com>
Message-ID: <CAL_JsqKZcWPA6L9duOyBJ7mMyV=Zoda2DhG8eD7g_fgxe8FFkg@mail.gmail.com>

On Fri, Jul 26, 2013 at 8:19 AM, Fabio Estevam <festevam at gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
>
> When booting a device tree kernel, we get the following output from
> 'cat /proc/cpuinfo':
>
> $ cat /proc/cpuinfo
> processor       : 0
> model name      : ARMv7 Processor rev 5 (v7l)
> BogoMIPS        : 531.66
> Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x2
> CPU part        : 0xc08
> CPU revision    : 5
>
> Hardware        : Freescale i.MX51 (Device Tree Support)
> Revision        : 0000
> Serial          : 0000000000000000
>
> The Hardware line does not really describe the hardware type, as it is reading
> the information from the dt 'machine' field.
>
> In the dt case, read the 'model' field instead, so that we can have a better
> description output as follows:
>
> Hardware        : Freescale i.MX51 Babbage Board
>
> The hardware output string is unchanged for the non-dt kernel case.
>
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
> Changes since v1:
> - Fix typo in 'architecture'
>  arch/arm/include/asm/mach/arch.h |  1 +
>  arch/arm/kernel/devtree.c        | 15 ++++++++-------
>  arch/arm/kernel/setup.c          |  7 ++++++-
>  3 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
> index 308ad7d..113d4af 100644
> --- a/arch/arm/include/asm/mach/arch.h
> +++ b/arch/arm/include/asm/mach/arch.h
> @@ -23,6 +23,7 @@ struct smp_operations;
>  struct machine_desc {
>         unsigned int            nr;             /* architecture number  */
>         const char              *name;          /* architecture name    */
> +       const char              *model;         /* architecture model */

As Russell said, we want to get rid of machine_desc at some point. So
I think a better approach is to remove the .name field (i.e. make it
NULL for now) for the DT case.

>         unsigned long           atag_offset;    /* tagged list (relative) */
>         const char *const       *dt_compat;     /* array of device tree
>                                                  * 'compatible' strings */
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 5af04f6..90d541a 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -178,7 +178,6 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>         struct machine_desc *mdesc, *mdesc_best = NULL;
>         unsigned int score, mdesc_score = ~1;
>         unsigned long dt_root;
> -       const char *model;
>
>  #ifdef CONFIG_ARCH_MULTIPLATFORM
>         DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> @@ -224,12 +223,14 @@ struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>                 dump_machine_table(); /* does not return */
>         }
>
> -       model = of_get_flat_dt_prop(dt_root, "model", NULL);
> -       if (!model)
> -               model = of_get_flat_dt_prop(dt_root, "compatible", NULL);
> -       if (!model)
> -               model = "<unknown>";
> -       pr_info("Machine: %s, model: %s\n", mdesc_best->name, model);
> +       mdesc_best->model = of_get_flat_dt_prop(dt_root, "model", NULL);

This won't work with Russell's constifying of machine_desc patch.

Rob


From nicolas.pitre at linaro.org  Fri Jul 26 11:39:02 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 26 Jul 2013 11:39:02 -0400 (EDT)
Subject: [PATCH 05/13] ARM: bL_switcher: move to dedicated threads rather
 than workqueues
In-Reply-To: <20130726151838.GC28084@e102568-lin.cambridge.arm.com>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-6-git-send-email-nicolas.pitre@linaro.org>
 <20130726151838.GC28084@e102568-lin.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1307261127420.15022@syhkavp.arg>

On Fri, 26 Jul 2013, Lorenzo Pieralisi wrote:

> On Tue, Jul 23, 2013 at 04:31:21AM +0100, Nicolas Pitre wrote:
> > The workqueues are problematic as they may be contended.
> > They can't be scheduled with top priority either.  Also the optimization
> > in bL_switch_request() to skip the workqueue entirely when the target CPU
> > and the calling CPU were the same didn't allow for bL_switch_request() to
> > be called from atomic context, as might be the case for some cpufreq
> > drivers.
> > 
> > Let's move to dedicated kthreads instead.
> > 
> > Signed-off-by: Nicolas Pitre <nico at linaro.org>
> > ---
> >  arch/arm/common/bL_switcher.c      | 101 ++++++++++++++++++++++++++++---------
> >  arch/arm/include/asm/bL_switcher.h |   2 +-
> >  2 files changed, 79 insertions(+), 24 deletions(-)
> > 
> > diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> > index d6f7e507d9..c2355cafc9 100644
> > --- a/arch/arm/common/bL_switcher.c
> > +++ b/arch/arm/common/bL_switcher.c
> > @@ -15,8 +15,10 @@
> >  #include <linux/sched.h>
> >  #include <linux/interrupt.h>
> >  #include <linux/cpu_pm.h>
> > +#include <linux/cpu.h>
> >  #include <linux/cpumask.h>
> > -#include <linux/workqueue.h>
> > +#include <linux/kthread.h>
> > +#include <linux/wait.h>
> >  #include <linux/clockchips.h>
> >  #include <linux/hrtimer.h>
> >  #include <linux/tick.h>
> > @@ -225,15 +227,48 @@ static int bL_switch_to(unsigned int new_cluster_id)
> >  	return ret;
> >  }
> >  
> > -struct switch_args {
> > -	unsigned int cluster;
> > -	struct work_struct work;
> > +struct bL_thread {
> > +	struct task_struct *task;
> > +	wait_queue_head_t wq;
> > +	int wanted_cluster;
> >  };
> >  
> > -static void __bL_switch_to(struct work_struct *work)
> > +static struct bL_thread bL_threads[MAX_CPUS_PER_CLUSTER];
> > +
> > +static int bL_switcher_thread(void *arg)
> > +{
> > +	struct bL_thread *t = arg;
> > +	struct sched_param param = { .sched_priority = 1 };
> > +	int cluster;
> > +
> > +	sched_setscheduler_nocheck(current, SCHED_FIFO, &param);
> > +
> > +	do {
> > +		if (signal_pending(current))
> > +			flush_signals(current);
> > +		wait_event_interruptible(t->wq,
> > +				t->wanted_cluster != -1 ||
> > +				kthread_should_stop());
> > +		cluster = xchg(&t->wanted_cluster, -1);
> > +		if (cluster != -1)
> > +			bL_switch_to(cluster);
> > +	} while (!kthread_should_stop());
> > +
> > +	return 0;
> > +}
> > +
> > +static struct task_struct * __init bL_switcher_thread_create(int cpu, void *arg)
> >  {
> > -	struct switch_args *args = container_of(work, struct switch_args, work);
> > -	bL_switch_to(args->cluster);
> > +	struct task_struct *task;
> > +
> > +	task = kthread_create_on_node(bL_switcher_thread, arg,
> > +				      cpu_to_node(cpu), "kswitcher_%d", cpu);
> > +	if (!IS_ERR(task)) {
> > +		kthread_bind(task, cpu);
> > +		wake_up_process(task);
> > +	} else
> > +		pr_err("%s failed for CPU %d\n", __func__, cpu);
> > +	return task;
> >  }
> >  
> >  /*
> > @@ -242,26 +277,46 @@ static void __bL_switch_to(struct work_struct *work)
> >   * @cpu: the CPU to switch
> >   * @new_cluster_id: the ID of the cluster to switch to.
> >   *
> > - * This function causes a cluster switch on the given CPU.  If the given
> > - * CPU is the same as the calling CPU then the switch happens right away.
> > - * Otherwise the request is put on a work queue to be scheduled on the
> > - * remote CPU.
> > + * This function causes a cluster switch on the given CPU by waking up
> > + * the appropriate switcher thread.  This function may or may not return
> > + * before the switch has occurred.
> >   */
> > -void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
> > +int bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)
> >  {
> > -	unsigned int this_cpu = get_cpu();
> > -	struct switch_args args;
> > +	struct bL_thread *t;
> >  
> > -	if (cpu == this_cpu) {
> > -		bL_switch_to(new_cluster_id);
> > -		put_cpu();
> > -		return;
> > +	if (cpu >= MAX_CPUS_PER_CLUSTER) {
> > +		pr_err("%s: cpu %d out of bounds\n", __func__, cpu);
> > +		return -EINVAL;
> >  	}
> > -	put_cpu();
> >  
> > -	args.cluster = new_cluster_id;
> > -	INIT_WORK_ONSTACK(&args.work, __bL_switch_to);
> > -	schedule_work_on(cpu, &args.work);
> > -	flush_work(&args.work);
> > +	t = &bL_threads[cpu];
> > +	if (IS_ERR(t->task))
> > +		return PTR_ERR(t->task);
> > +	if (!t->task)
> > +		return -ESRCH;
> > +
> > +	t->wanted_cluster = new_cluster_id;
> > +	wake_up(&t->wq);
> > +	return 0;
> >  }
> >  EXPORT_SYMBOL_GPL(bL_switch_request);
> > +
> > +static int __init bL_switcher_init(void)
> > +{
> > +	int cpu;
> > +
> > +	pr_info("big.LITTLE switcher initializing\n");
> > +
> > +	for_each_online_cpu(cpu) {
> > +		struct bL_thread *t = &bL_threads[cpu];
> > +		init_waitqueue_head(&t->wq);
> 
> Dereferencing &bL_threads[cpu] is wrong without checking the cpu index against
> MAX_CPUS_PER_CLUSTER. I know you hotplug out half of the CPUs in a later patch but
> still, this code needs fixing.

I've now declared bL_threads[] with NR_CPUS instead.  A later patch 
needed that to happen anyway.

> > +		t->wanted_cluster = -1;
> > +		t->task = bL_switcher_thread_create(cpu, t);
> > +	}
> > +
> > +	pr_info("big.LITTLE switcher initialized\n");
> > +	return 0;
> > +}
> > +
> > +late_initcall(bL_switcher_init);
> > diff --git a/arch/arm/include/asm/bL_switcher.h b/arch/arm/include/asm/bL_switcher.h
> > index 72efe3f349..e0c0bba70b 100644
> > --- a/arch/arm/include/asm/bL_switcher.h
> > +++ b/arch/arm/include/asm/bL_switcher.h
> > @@ -12,6 +12,6 @@
> >  #ifndef ASM_BL_SWITCHER_H
> >  #define ASM_BL_SWITCHER_H
> >  
> > -void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id);
> > +int bL_switch_request(unsigned int cpu, unsigned int new_cluster_id);
> 
> We probably discussed this before, and it is not strictly related to
> this patch, but is locking/queuing necessary when requesting a switch ? I do
> not remember the outcome of the discussion so I am asking again.

Strictly speaking, there is no queueing/locking needed as we currently 
only request a state.  If we request the big cluster, and another 
request comes along for the little cluster in the mean time before the 
request to the big cluster was acted upon, then there is effectively 
nothing to do anymore and the fact that the previous request was 
overwritten is fine.

There is a patch introducing some kind of queueing in the part 2 of the 
whole series that I didn't post yet.  The only reason we need that is to 
call the cpufreq post notifier only after the switch is actually 
complete.  I'll post that along with the patches connecting cpufreq with 
this eventually.


Nicolas


From yadi.brar01 at gmail.com  Fri Jul 26 11:43:30 2013
From: yadi.brar01 at gmail.com (Yadwinder Singh Brar)
Date: Fri, 26 Jul 2013 21:13:30 +0530
Subject: [PATCH 1/3] clk: s2mps11: Add support for s2mps11
In-Reply-To: <1373197462-4033-2-git-send-email-yadi.brar@samsung.com>
References: <1373197462-4033-1-git-send-email-yadi.brar@samsung.com>
 <1373197462-4033-2-git-send-email-yadi.brar@samsung.com>
Message-ID: <CAKew6eXabwATXWNXnLY=MFonKpPHF32n=rgQA1ati5AS0ybJFw@mail.gmail.com>

Gentle ping ...

Any review comments?

On Sun, Jul 7, 2013 at 5:14 PM, Yadwinder Singh Brar
<yadi.brar at samsung.com> wrote:
> This patch adds support to register three(AP/CP/BT) buffered 32.768 KHz
> outputs of mfd-s2mps11 with common clock framework.
>
> Signed-off-by: Yadwinder Singh Brar <yadi.brar at samsung.com>
> ---
>  drivers/clk/Kconfig       |    6 +
>  drivers/clk/Makefile      |    1 +
>  drivers/clk/clk-s2mps11.c |  273 +++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 280 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/clk/clk-s2mps11.c
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 0357ac4..3fdf10e 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -65,6 +65,12 @@ config COMMON_CLK_SI5351
>           This driver supports Silicon Labs 5351A/B/C programmable clock
>           generators.
>
> +config COMMON_CLK_S2MPS11
> +       tristate "Clock driver for S2MPS11 MFD"
> +       depends on MFD_SEC_CORE
> +       ---help---
> +         This driver supports S2MPS11 crystal oscillator clock.
> +
>  config CLK_TWL6040
>         tristate "External McPDM functional clock from twl6040"
>         depends on TWL6040_CORE
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 137d3e7..5fd642d 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -38,4 +38,5 @@ obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
>  obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
>  obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
>  obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
> +obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
>  obj-$(CONFIG_CLK_TWL6040)      += clk-twl6040.o
> diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
> new file mode 100644
> index 0000000..7be41e6
> --- /dev/null
> +++ b/drivers/clk/clk-s2mps11.c
> @@ -0,0 +1,273 @@
> +/*
> + * clk-s2mps11.c - Clock driver for S2MPS11.
> + *
> + * Copyright (C) 2013 Samsung Electornics
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + *
> + * This 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/err.h>
> +#include <linux/of.h>
> +#include <linux/clkdev.h>
> +#include <linux/regmap.h>
> +#include <linux/clk-provider.h>
> +#include <linux/platform_device.h>
> +#include <linux/mfd/samsung/s2mps11.h>
> +#include <linux/mfd/samsung/core.h>
> +
> +#define s2mps11_name(a) (a->hw.init->name)
> +
> +static struct clk **clk_table;
> +static struct clk_onecell_data clk_data;
> +
> +enum {
> +       S2MPS11_CLK_AP = 0,
> +       S2MPS11_CLK_CP,
> +       S2MPS11_CLK_BT,
> +       S2MPS11_CLKS_NUM,
> +};
> +
> +struct s2mps11_clk {
> +       struct sec_pmic_dev *iodev;
> +       struct clk_hw hw;
> +       struct clk *clk;
> +       struct clk_lookup *lookup;
> +       u32 mask;
> +       bool enabled;
> +};
> +
> +static struct s2mps11_clk *to_s2mps11_clk(struct clk_hw *hw)
> +{
> +       return container_of(hw, struct s2mps11_clk, hw);
> +}
> +
> +static int s2mps11_clk_prepare(struct clk_hw *hw)
> +{
> +       struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
> +       int ret;
> +
> +       ret = regmap_update_bits(s2mps11->iodev->regmap,
> +                               S2MPS11_REG_RTC_CTRL,
> +                                s2mps11->mask, s2mps11->mask);
> +       if (!ret)
> +               s2mps11->enabled = true;
> +
> +       return ret;
> +}
> +
> +static void s2mps11_clk_unprepare(struct clk_hw *hw)
> +{
> +       struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
> +       int ret;
> +
> +       ret = regmap_update_bits(s2mps11->iodev->regmap, S2MPS11_REG_RTC_CTRL,
> +                          s2mps11->mask, ~s2mps11->mask);
> +
> +       if (!ret)
> +               s2mps11->enabled = false;
> +}
> +
> +static int s2mps11_clk_is_enabled(struct clk_hw *hw)
> +{
> +       struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
> +
> +       return s2mps11->enabled;
> +}
> +
> +static unsigned long s2mps11_clk_recalc_rate(struct clk_hw *hw,
> +                                            unsigned long parent_rate)
> +{
> +       struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
> +       if (s2mps11->enabled)
> +               return 32768;
> +       else
> +               return 0;
> +}
> +
> +static struct clk_ops s2mps11_clk_ops = {
> +       .prepare        = s2mps11_clk_prepare,
> +       .unprepare      = s2mps11_clk_unprepare,
> +       .is_enabled     = s2mps11_clk_is_enabled,
> +       .recalc_rate    = s2mps11_clk_recalc_rate,
> +};
> +
> +static struct clk_init_data s2mps11_clks_init[S2MPS11_CLKS_NUM] = {
> +       [S2MPS11_CLK_AP] = {
> +               .name = "s2mps11_ap",
> +               .ops = &s2mps11_clk_ops,
> +               .flags = CLK_IS_ROOT,
> +       },
> +       [S2MPS11_CLK_CP] = {
> +               .name = "s2mps11_cp",
> +               .ops = &s2mps11_clk_ops,
> +               .flags = CLK_IS_ROOT,
> +       },
> +       [S2MPS11_CLK_BT] = {
> +               .name = "s2mps11_bt",
> +               .ops = &s2mps11_clk_ops,
> +               .flags = CLK_IS_ROOT,
> +       },
> +};
> +
> +static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev)
> +{
> +       struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
> +       struct device_node *clk_np;
> +       int i;
> +
> +       if (!iodev->dev->of_node)
> +               return NULL;
> +
> +       clk_np = of_find_node_by_name(iodev->dev->of_node, "clocks");
> +       if (!clk_np) {
> +               dev_err(&pdev->dev, "could not find clock sub-node\n");
> +               return ERR_PTR(-EINVAL);
> +       }
> +
> +       clk_table = devm_kzalloc(&pdev->dev, sizeof(struct clk *) *
> +                                S2MPS11_CLKS_NUM, GFP_KERNEL);
> +       if (!clk_table)
> +               return ERR_PTR(-ENOMEM);
> +
> +       for (i = 0; i < S2MPS11_CLKS_NUM; i++)
> +               of_property_read_string_index(clk_np, "clock-output-names", i,
> +                               &s2mps11_clks_init[i].name);
> +
> +       return clk_np;
> +}
> +
> +static int s2mps11_clk_probe(struct platform_device *pdev)
> +{
> +       struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
> +       struct s2mps11_clk *s2mps11_clks, *s2mps11_clk;
> +       struct device_node *clk_np = NULL;
> +       int i, ret = 0;
> +       u32 val;
> +
> +       s2mps11_clks = devm_kzalloc(&pdev->dev, sizeof(*s2mps11_clk) *
> +                                       S2MPS11_CLKS_NUM, GFP_KERNEL);
> +       if (!s2mps11_clks)
> +               return -ENOMEM;
> +
> +       s2mps11_clk = s2mps11_clks;
> +
> +       clk_np = s2mps11_clk_parse_dt(pdev);
> +       if (IS_ERR(clk_np))
> +               return PTR_ERR(clk_np);
> +
> +       for (i = 0; i < S2MPS11_CLKS_NUM; i++, s2mps11_clk++) {
> +               s2mps11_clk->iodev = iodev;
> +               s2mps11_clk->hw.init = &s2mps11_clks_init[i];
> +               s2mps11_clk->mask = 1 << i;
> +
> +               ret = regmap_read(s2mps11_clk->iodev->regmap,
> +                                 S2MPS11_REG_RTC_CTRL, &val);
> +               if (ret < 0)
> +                       goto err_reg;
> +
> +               s2mps11_clk->enabled = val & s2mps11_clk->mask;
> +
> +               s2mps11_clk->clk = devm_clk_register(&pdev->dev,
> +                                                       &s2mps11_clk->hw);
> +               if (IS_ERR(s2mps11_clk->clk)) {
> +                       dev_err(&pdev->dev, "Fail to register : %s\n",
> +                                               s2mps11_name(s2mps11_clk));
> +                       ret = PTR_ERR(s2mps11_clk->clk);
> +                       goto err_reg;
> +               }
> +
> +               s2mps11_clk->lookup = devm_kzalloc(&pdev->dev,
> +                                       sizeof(struct clk_lookup), GFP_KERNEL);
> +               if (!s2mps11_clk->lookup) {
> +                       ret = -ENOMEM;
> +                       goto err_lup;
> +               }
> +
> +               s2mps11_clk->lookup->con_id = s2mps11_name(s2mps11_clk);
> +               s2mps11_clk->lookup->clk = s2mps11_clk->clk;
> +
> +               clkdev_add(s2mps11_clk->lookup);
> +       }
> +
> +       if (clk_table) {
> +               for (i = 0; i < S2MPS11_CLKS_NUM; i++)
> +                       clk_table[i] = s2mps11_clks[i].clk;
> +
> +               clk_data.clks = clk_table;
> +               clk_data.clk_num = S2MPS11_CLKS_NUM;
> +               of_clk_add_provider(clk_np, of_clk_src_onecell_get, &clk_data);
> +       }
> +
> +       platform_set_drvdata(pdev, s2mps11_clks);
> +
> +       return ret;
> +err_lup:
> +       devm_clk_unregister(&pdev->dev, s2mps11_clk->clk);
> +err_reg:
> +       while (s2mps11_clk > s2mps11_clks) {
> +               if (s2mps11_clk->lookup) {
> +                       clkdev_drop(s2mps11_clk->lookup);
> +                       devm_clk_unregister(&pdev->dev, s2mps11_clk->clk);
> +               }
> +               s2mps11_clk--;
> +       }
> +
> +       return ret;
> +}
> +
> +static int s2mps11_clk_remove(struct platform_device *pdev)
> +{
> +       struct s2mps11_clk *s2mps11_clks = platform_get_drvdata(pdev);
> +       int i;
> +
> +       for (i = 0; i < S2MPS11_CLKS_NUM; i++)
> +               clkdev_drop(s2mps11_clks[i].lookup);
> +
> +       return 0;
> +}
> +
> +static const struct platform_device_id s2mps11_clk_id[] = {
> +       { "s2mps11-clk", 0},
> +       { },
> +};
> +MODULE_DEVICE_TABLE(platform, s2mps11_clk_id);
> +
> +static struct platform_driver s2mps11_clk_driver = {
> +       .driver = {
> +               .name  = "s2mps11-clk",
> +               .owner = THIS_MODULE,
> +       },
> +       .probe = s2mps11_clk_probe,
> +       .remove = s2mps11_clk_remove,
> +       .id_table = s2mps11_clk_id,
> +};
> +
> +static int __init s2mps11_clk_init(void)
> +{
> +       return platform_driver_register(&s2mps11_clk_driver);
> +}
> +subsys_initcall(s2mps11_clk_init);
> +
> +static void __init s2mps11_clk_cleanup(void)
> +{
> +       platform_driver_unregister(&s2mps11_clk_driver);
> +}
> +module_exit(s2mps11_clk_cleanup);
> +
> +MODULE_DESCRIPTION("S2MPS11 Clock Driver");
> +MODULE_AUTHOR("Yadwinder Singh Brar <yadi.brar at samsung.com>");
> +MODULE_LICENSE("GPL");
> --
> 1.7.0.4
>


From nicolas.pitre at linaro.org  Fri Jul 26 11:43:34 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 26 Jul 2013 11:43:34 -0400 (EDT)
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value
 to index into save array
In-Reply-To: <20130726153440.GD2282@localhost.localdomain>
References: <alpine.LFD.2.03.1307251203550.15022@syhkavp.arg>
 <20130726113110.GB28084@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307261032330.15022@syhkavp.arg>
 <20130726153440.GD2282@localhost.localdomain>
Message-ID: <alpine.LFD.2.03.1307261139370.15022@syhkavp.arg>

On Fri, 26 Jul 2013, Dave Martin wrote:

> On Fri, Jul 26, 2013 at 10:41:38AM -0400, Nicolas Pitre wrote:
> > On Fri, 26 Jul 2013, Lorenzo Pieralisi wrote:
> > 
> > > On Thu, Jul 25, 2013 at 05:06:51PM +0100, Nicolas Pitre wrote:
> > > > On Thu, 25 Jul 2013, Dave Martin wrote:
> > > > 
> > > > > On Wed, Jul 24, 2013 at 02:55:00PM -0400, Nicolas Pitre wrote:
> > > > > > On Wed, 24 Jul 2013, Dave Martin wrote:
> > > > > > 
> > > > > > > But this patch commits us to requiring that on the suspend path 
> > > > > > > specifically -- I think that ought to be mentioned somewhere. A 
> > > > > > > comment in the preamble for __cpu_suspend would be enough, I think.
> > > > > > 
> > > > > > What comment would you suggest?  I want to make sure the possible 
> > > > > > confusion you see is properly addressed.
> > > > > 
> > > > > I think we just need to state that the value of
> > > > > cpu_logical_map(smp_processor_id()) must be the MPIDR of the physical
> > > > > CPU the suspending logical CPU will resume on.  Consequently, if doing a
> > > > > migration, cpu_logical_map() must be updated appropriately somewhere
> > > > > between cpu_pm_enter() and cpu_suspend().
> > > > 
> > > > Excellent.  I've amended the patch with this:
> > > > 
> > > > diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
> > > > index 2835d35234..caf938db62 100644
> > > > --- a/arch/arm/kernel/suspend.c
> > > > +++ b/arch/arm/kernel/suspend.c
> > > > @@ -17,6 +17,11 @@ extern void cpu_resume_mmu(void);
> > > >  /*
> > > >   * Hide the first two arguments to __cpu_suspend - these are an implementation
> > > >   * detail which platform code shouldn't have to know about.
> > > > + *
> > > > + * On SMP systems, the value of cpu_logical_map(smp_processor_id()) must be
> > > > + * the MPIDR of the physical CPU the suspending logical CPU will resume on.
> > > > + * Consequently, if doing a physical CPU migration, cpu_logical_map() must be
> > > > + * updated appropriately somewhere between cpu_pm_enter() and cpu_suspend().
> > > >   */
> > > >  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> > > >  {
> > > > 
> > > > I've put it against cpu_suspend() rather than __cpu_suspend(() as this 
> > > > is what users should care about.
> > > > 
> > > > ACK?
> > > 
> > > We need this patch to allow IKS to store a cpu context at a specific
> > > index, let's be honest. It is a moot point and I am not very happy
> > > about changing this code for a very specific usage, but the way code is
> > > implemented makes the change acceptable. I really do not think we should
> > > write guidelines on how cpu_suspend users have to change cpu_logical_map
> > > though, that's not needed apart from IKS and that should be limited to IKS
> > > code only.
> > > 
> > > Again, that's just my opinion, but cpu_suspend API must be kept as it is
> > > and we should not encourage people to use it in creative ways.
> > 
> > I tend to agree, but I'm now stuck between two conflicting requests.
> 
> Would it make sense to keep the same API to cpu_suspend(), but make it
> a wrapper for another function which has the MPIDR argument?  Then people
> calling cpu_suspend() continue as normal.  Only IKS needs to know about
> the underlying MPIDR handling when calling this.

The fact is that the switcher _does_ need to swizzle the cpu_logical_map 
anyway before suspending.  Hence really there is no point creating extra
wrappers for this.

So Lorenzo's suggestion to simply not advertise this too much for people 
to not get too creative is probably the best compromize IMHO.


Nicolas


From b.brezillon at overkiz.com  Fri Jul 26 11:44:43 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Fri, 26 Jul 2013 17:44:43 +0200
Subject: [PATCH v2 00/42] ARM: at91: move to common clk framework
In-Reply-To: <51F28370.6050304@gmail.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <51F28370.6050304@gmail.com>
Message-ID: <51F2996B.6000406@overkiz.com>

On 26/07/2013 16:10, Richard Genoud wrote:
> On 17/07/2013 15:34, Boris BREZILLON wrote:
>> Hello,
>>
>> This patch series is a proposal to move at91 clock implementation
>> to common clk framework.
>>
>> Most of the clock provided by the PMC (Power Management Controller) are
>> implemented :
>> - main clock (main oscillator)
>> - pll clocks
>> - master clock
>> - programmable clocks
>> - utmi clock
>> - peripheral clocks
>> - system clocks
>>
>> This implementation is compatible with device tree: the goal is
>> to define the whole clock tree in the device tree (all currently
>> available dt SoCs and boards are patched to support dt clocks).
>> Please feel free to comment the dt bindinds.
>>
>> I removed the register_clocks function in SoC supporting dt boards only:
>> - at91sam9x5 SoCs
>> - at91sam9n12 SoC
>> - sama5d3 SoCs
>>
>> This patch series is based on linux-next and has been tested on sama5d31ek
>> board using device tree. It compiles for other SoCs and both with and without
>> dt support, but it has not been tested.
>>
>> BTW could other people test it on other boards (I only have a kizbox and
>> a sama5d31ek dev kit).
>>
>> Best Regards,
>> Boris
>>
>> Changes since v1:
>>   - fix bugs in pll, programmable and system clock implementations
>>     (wrong bit position).
>>   - add usb clock configuration support (ohci and udc drivers +
>>     clk_lookup for non dt boards)
>>   - rework of the system clock interfaces (no need to define a parent clock,
>>     system clock is a gate with no rate info)
>>   - change system, peripheral and programmable clk dt bindings (1 master node
>>     and multiple child nodes each defining a system/peripheral or prog clock)
>>   - fix bugs in sama5 dt definition
>>
> Hi Boris,
>
> First of all: Big thumbs up for this work !
>
> Then, I tested the serie on at91sam9g35ek (sam9x5 familly), and I see some problems:
> kernel is next-20130725 with the v4 serie of "ARM: at91: prepare transition to common clk framework"
> and v2 serie of "ARM: at91: move to common clk framework"
>
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 3.11.0-rc2-next-20130725+ (rgenoud at lnx-rg) (gcc version 4.7.3 (Buildroot 2013.05-00157-g6d1e60b-dirty) ) #61 Fri Jul 26 15:30:13 CEST 2013
> [    0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
> [    0.000000] CPU: VIVT data cache, VIVT instruction cache
> [    0.000000] Machine: Atmel AT91SAM (Device Tree), model: Atmel AT91SAM9G35-EK
> [    0.000000] bootconsole [earlycon0] enabled
> [    0.000000] Memory policy: ECC disabled, Data cache writeback
> [    0.000000] AT91: Detected soc type: at91sam9x5
> [    0.000000] AT91: Detected soc subtype: at91sam9g35
> [    0.000000] AT91: sram at 0x300000 of 0x8000 mapped at 0xfef70000
> [    0.000000] On node 0 totalpages: 32768
> [    0.000000] free_area_init_node: node 0, pgdat c039d208, node_mem_map c03b5000
> [    0.000000]   Normal zone: 256 pages used for memmap
> [    0.000000]   Normal zone: 0 pages reserved
> [    0.000000]   Normal zone: 32768 pages, LIFO batch:7
> [    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> [    0.000000] pcpu-alloc: [0] 0
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
> [    0.000000] Kernel command line: console=ttyS0,115200 loglevel=8 ip=dhcp root=/dev/nfs nfsroot=10.128.0.9:/nfsroot,v3 rw earlyprintk
> [    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
> [    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> [    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> [    0.000000] Memory: 126044K/131072K available (2804K kernel code, 126K rwdata, 592K rodata, 141K init, 93K bss, 5028K reserved)
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> [    0.000000]     vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
> [    0.000000]       .text : 0xc0008000 - 0xc0359550   (3398 kB)
> [    0.000000]       .init : 0xc035a000 - 0xc037d61c   ( 142 kB)
> [    0.000000]       .data : 0xc037e000 - 0xc039d920   ( 127 kB)
> [    0.000000]        .bss : 0xc039d920 - 0xc03b4ff4   (  94 kB)
> [    0.000000] NR_IRQS:16 nr_irqs:16 16
> [    0.000000] AT91: PIT: mck rate = 0
> [    0.000000] ------------[ cut here ]------------
> [    0.000000] WARNING: CPU: 0 PID: 0 at arch/arm/mach-at91/at91sam926x_time.c:259 at91sam926x_pit_init+0x114/0x234()
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.0-rc2-next-20130725+ #61
> [    0.000000] [<c000ca18>] (unwind_backtrace+0x0/0xe0) from [<c000b0f0>] (show_stack+0x10/0x14)
> [    0.000000] [<c000b0f0>] (show_stack+0x10/0x14) from [<c00144e0>] (warn_slowpath_common+0x5c/0x7c)
> [    0.000000] [<c00144e0>] (warn_slowpath_common+0x5c/0x7c) from [<c00145b8>] (warn_slowpath_null+0x18/0x1c)
> [    0.000000] [<c00145b8>] (warn_slowpath_null+0x18/0x1c) from [<c03607b0>] (at91sam926x_pit_init+0x114/0x234)
> [    0.000000] [<c03607b0>] (at91sam926x_pit_init+0x114/0x234) from [<c035ca4c>] (time_init+0x1c/0x24)
> [    0.000000] [<c035ca4c>] (time_init+0x1c/0x24) from [<c035a650>] (start_kernel+0x19c/0x2f4)
> [    0.000000] [<c035a650>] (start_kernel+0x19c/0x2f4) from [<20008040>] (0x20008040)
> [    0.000000] ---[ end trace 1b75b31a2719ed1c ]---
> [    0.000000] Division by zero in kernel.
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G        W    3.11.0-rc2-next-20130725+ #61
> [    0.000000] [<c000ca18>] (unwind_backtrace+0x0/0xe0) from [<c000b0f0>] (show_stack+0x10/0x14)
> [    0.000000] [<c000b0f0>] (show_stack+0x10/0x14) from [<c013f0a0>] (Ldiv0_64+0x8/0x18)
> [    0.000000] [<c013f0a0>] (Ldiv0_64+0x8/0x18) from [<c003b864>] (__clocksource_updatefreq_scale+0x30/0x104)
> [    0.000000] [<c003b864>] (__clocksource_updatefreq_scale+0x30/0x104) from [<c003b944>] (__clocksource_register_scale+0xc/0x48)
> [    0.000000] [<c003b944>] (__clocksource_register_scale+0xc/0x48) from [<c0360810>] (at91sam926x_pit_init+0x174/0x234)
> [    0.000000] [<c0360810>] (at91sam926x_pit_init+0x174/0x234) from [<c035ca4c>] (time_init+0x1c/0x24)
> [    0.000000] [<c035ca4c>] (time_init+0x1c/0x24) from [<c035a650>] (start_kernel+0x19c/0x2f4)
> [    0.000000] [<c035a650>] (start_kernel+0x19c/0x2f4) from [<20008040>] (0x20008040)
> [    0.000000] Division by zero in kernel.
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G        W    3.11.0-rc2-next-20130725+ #61
> [    0.000000] [<c000ca18>] (unwind_backtrace+0x0/0xe0) from [<c000b0f0>] (show_stack+0x10/0x14)
> [    0.000000] [<c000b0f0>] (show_stack+0x10/0x14) from [<c013f0a0>] (Ldiv0_64+0x8/0x18)
> [    0.000000] [<c013f0a0>] (Ldiv0_64+0x8/0x18) from [<c003b76c>] (clocks_calc_mult_shift+0x70/0xa4)
> [    0.000000] [<c003b76c>] (clocks_calc_mult_shift+0x70/0xa4) from [<c003b8e4>] (__clocksource_updatefreq_scale+0xb0/0x104)
> [    0.000000] [<c003b8e4>] (__clocksource_updatefreq_scale+0xb0/0x104) from [<c003b944>] (__clocksource_register_scale+0xc/0x48)
> [    0.000000] [<c003b944>] (__clocksource_register_scale+0xc/0x48) from [<c0360810>] (at91sam926x_pit_init+0x174/0x234)
> [    0.000000] [<c0360810>] (at91sam926x_pit_init+0x174/0x234) from [<c035ca4c>] (time_init+0x1c/0x24)
> [    0.000000] [<c035ca4c>] (time_init+0x1c/0x24) from [<c035a650>] (start_kernel+0x19c/0x2f4)
> [    0.000000] [<c035a650>] (start_kernel+0x19c/0x2f4) from [<20008040>] (0x20008040)
> [...]
>
> Best regards,
> Richard
Hi Richard,

First, I'd like to thank you for your tests.

Regarding your problem, it seems that mck rate is calculated as 0, which 
is either a bug in recalc_rate callback
of master clock driver or a bug in master clock parent clk (no parent 
found or bug in the current parent clk recalc_rate function).

I checked the dts[i] files and I found a missing clock-frequency 
property for main clock of some
at91sam9x5 boards (those including at91sam9x5cm.dtsi).

You'll find a patch adding this property in attachments.
Tell me if this works for you. If not I'll make a patch adding pr_info 
to trace the bug.

Anyway, it should work without this property (main clock rate can be 
computed using slow clock rate and MCFR register).
I will investigate this bug...

Best Regards,
Boris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-at91-dt-at91sam9x5cm-fix-main-clock-frequency-de.patch
Type: text/x-patch
Size: 1032 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130726/9e92f78f/attachment.bin>

From Dave.Martin at arm.com  Fri Jul 26 11:45:34 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Fri, 26 Jul 2013 16:45:34 +0100
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value to
 index into save array
In-Reply-To: <alpine.LFD.2.03.1307261139370.15022@syhkavp.arg>
References: <alpine.LFD.2.03.1307251203550.15022@syhkavp.arg>
 <20130726113110.GB28084@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307261032330.15022@syhkavp.arg>
 <20130726153440.GD2282@localhost.localdomain>
 <alpine.LFD.2.03.1307261139370.15022@syhkavp.arg>
Message-ID: <20130726154534.GE2282@localhost.localdomain>

On Fri, Jul 26, 2013 at 11:43:34AM -0400, Nicolas Pitre wrote:
> On Fri, 26 Jul 2013, Dave Martin wrote:
> 
> > On Fri, Jul 26, 2013 at 10:41:38AM -0400, Nicolas Pitre wrote:
> > > On Fri, 26 Jul 2013, Lorenzo Pieralisi wrote:
> > > 
> > > > On Thu, Jul 25, 2013 at 05:06:51PM +0100, Nicolas Pitre wrote:
> > > > > On Thu, 25 Jul 2013, Dave Martin wrote:
> > > > > 
> > > > > > On Wed, Jul 24, 2013 at 02:55:00PM -0400, Nicolas Pitre wrote:
> > > > > > > On Wed, 24 Jul 2013, Dave Martin wrote:
> > > > > > > 
> > > > > > > > But this patch commits us to requiring that on the suspend path 
> > > > > > > > specifically -- I think that ought to be mentioned somewhere. A 
> > > > > > > > comment in the preamble for __cpu_suspend would be enough, I think.
> > > > > > > 
> > > > > > > What comment would you suggest?  I want to make sure the possible 
> > > > > > > confusion you see is properly addressed.
> > > > > > 
> > > > > > I think we just need to state that the value of
> > > > > > cpu_logical_map(smp_processor_id()) must be the MPIDR of the physical
> > > > > > CPU the suspending logical CPU will resume on.  Consequently, if doing a
> > > > > > migration, cpu_logical_map() must be updated appropriately somewhere
> > > > > > between cpu_pm_enter() and cpu_suspend().
> > > > > 
> > > > > Excellent.  I've amended the patch with this:
> > > > > 
> > > > > diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
> > > > > index 2835d35234..caf938db62 100644
> > > > > --- a/arch/arm/kernel/suspend.c
> > > > > +++ b/arch/arm/kernel/suspend.c
> > > > > @@ -17,6 +17,11 @@ extern void cpu_resume_mmu(void);
> > > > >  /*
> > > > >   * Hide the first two arguments to __cpu_suspend - these are an implementation
> > > > >   * detail which platform code shouldn't have to know about.
> > > > > + *
> > > > > + * On SMP systems, the value of cpu_logical_map(smp_processor_id()) must be
> > > > > + * the MPIDR of the physical CPU the suspending logical CPU will resume on.
> > > > > + * Consequently, if doing a physical CPU migration, cpu_logical_map() must be
> > > > > + * updated appropriately somewhere between cpu_pm_enter() and cpu_suspend().
> > > > >   */
> > > > >  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> > > > >  {
> > > > > 
> > > > > I've put it against cpu_suspend() rather than __cpu_suspend(() as this 
> > > > > is what users should care about.
> > > > > 
> > > > > ACK?
> > > > 
> > > > We need this patch to allow IKS to store a cpu context at a specific
> > > > index, let's be honest. It is a moot point and I am not very happy
> > > > about changing this code for a very specific usage, but the way code is
> > > > implemented makes the change acceptable. I really do not think we should
> > > > write guidelines on how cpu_suspend users have to change cpu_logical_map
> > > > though, that's not needed apart from IKS and that should be limited to IKS
> > > > code only.
> > > > 
> > > > Again, that's just my opinion, but cpu_suspend API must be kept as it is
> > > > and we should not encourage people to use it in creative ways.
> > > 
> > > I tend to agree, but I'm now stuck between two conflicting requests.
> > 
> > Would it make sense to keep the same API to cpu_suspend(), but make it
> > a wrapper for another function which has the MPIDR argument?  Then people
> > calling cpu_suspend() continue as normal.  Only IKS needs to know about
> > the underlying MPIDR handling when calling this.
> 
> The fact is that the switcher _does_ need to swizzle the cpu_logical_map 
> anyway before suspending.  Hence really there is no point creating extra
> wrappers for this.
> 
> So Lorenzo's suggestion to simply not advertise this too much for people 
> to not get too creative is probably the best compromize IMHO.

Sure, I don't have a problem with that in light of the discussion.

Cheers
---Dave


From olof at lixom.net  Fri Jul 26 11:49:43 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Jul 2013 08:49:43 -0700
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726141016.GF9858@sirena.org.uk>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726141016.GF9858@sirena.org.uk>
Message-ID: <CAOesGMhEr3DiFm5uSgoHPFUMY4jWu4HkeTU2UmOGj=dS75Vk+g@mail.gmail.com>

On Fri, Jul 26, 2013 at 7:10 AM, Mark Brown <broonie at kernel.org> wrote:
> On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
>
>> Unless I totally misunderstood, the thread is talking about letting
>> established bindings change with each new kernel version.  I am
>> opposed to that.
>
> No, nobody is really saying that is a particularly good idea.  There is
> some debate about how we work out what an established binding is but
> there's no serious suggestion that we don't want stable bindings.

Yes, what Mark said -- _today_ all bindings are subject to change and
can be changed in lockstep with the kernel. This has been necessary as
part of development to sort out all of the various bootstrapping
issues across platforms.

What we're talking about is to end that mode of operation, and moving
over to locking in bindings. Device tree contents, as mentioned
elsewhere, might still be changed just like code is -- bugs are fixed,
etc. But it's time to start locking down the bindings, in particular
no longer change the established ones.

Long term, final goal is likely to be close to what Russell is saying
-- nothing should go into the kernel tree unless the binding is in a
fully stable state. However, we have a transitional period between now
and then, and even when we're at the final state there will be need to
have some sort of sandbox for development and test of future bindings.
Dealing with all that, as well as the actual process for locking in
bindings, is what needs to be sorted out.

I think we're all in agreement that bindings that change over time are
nothing but pain, but we're arguing that in circles anyway.


-Olof


From catalin.marinas at arm.com  Fri Jul 26 11:55:20 2013
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 26 Jul 2013 16:55:20 +0100
Subject: [GIT PULL] arm64 fixes for 3.11
Message-ID: <20130726155458.GA31613@arm.com>

Hi Linus,

Please pull the arm64 fixes below. Thanks.


The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b:

  Linux 3.11-rc2 (2013-07-21 12:05:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git tags/arm64-stable

for you to fetch changes up to 845ad05ec31e0f3872a321e10dbeaf872022632c:

  arm64: Change kernel stack size to 16K (2013-07-26 13:37:29 +0100)

----------------------------------------------------------------
- Stack size increased to 16K (similar to other 64-bit architectures)
- Additional cache flushing for secondary CPUs boot mode

----------------------------------------------------------------
Catalin Marinas (1):
      arm64: Fix definition of arm_pm_restart to match the declaration

Feng Kan (1):
      arm64: Change kernel stack size to 16K

Mark Rutland (1):
      arm64: virt: ensure visibility of __boot_cpu_mode

 arch/arm64/include/asm/thread_info.h |  4 ++--
 arch/arm64/include/asm/virt.h        | 13 +++++++++++++
 arch/arm64/kernel/entry.S            |  2 +-
 arch/arm64/kernel/process.c          |  2 +-
 4 files changed, 17 insertions(+), 4 deletions(-)

-- 
Catalin


From csd at broadcom.com  Fri Jul 26 11:55:42 2013
From: csd at broadcom.com (Christian Daudt)
Date: Fri, 26 Jul 2013 08:55:42 -0700
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726152918.GL29916@titan.lakedaemon.net>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net>
Message-ID: <51F29BFE.8000202@broadcom.com>

[resend in plain text]
On 13-07-26 08:29 AM, Jason Cooper wrote:
> On Fri, Jul 26, 2013 at 04:56:40PM +0200, Domenico Andreoli wrote:
>> From: Domenico Andreoli<domenico.andreoli at linux.com>
>>
>> arch/arm/mach-bcm contains a plurality of Broadcom SoCs, each configured
>> separately. As a matter of flexibility and maintenance, it needs to be
>> always included in the build.
> So if I'm building mach-kirkwood, I _have_ to build Broadcom?  What is
> the *specific* problem you're encountering that this solves?
  No it won't, as the Makefile inside mach-bcm will only pull in files 
based on ARCH_ settings. This move is so that a number different 
Broadcom SoCs can co-exist inside the mach-bcm directory.
>> Cc: Christian Daudt<csd at broadcom.com>
>> Cc:linux-arm-kernel at lists.infradead.org
>> Signed-off-by: Domenico Andreoli<domenico.andreoli at linux.com>
>> ---
>>   arch/arm/Makefile |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Index: b/arch/arm/Makefile
>> ===================================================================
>> --- a/arch/arm/Makefile
>> +++ b/arch/arm/Makefile
>> @@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x0020
>>   # Machine directory name.  This list is sorted alphanumerically
>>   # by CONFIG_* macro name.
>>   machine-$(CONFIG_ARCH_AT91)		+= at91
>> -machine-$(CONFIG_ARCH_BCM)		+= bcm
>> +machine-y				+= bcm
>>   machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
>>   machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
>>   machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
>>
>>
This patch is already contained in Hauke's patchset from yesterday ( 
http://article.gmane.org/gmane.linux.ports.arm.kernel/254986) so you'll 
need to sync with him on it. In case yours goes in first:
Acked-by: Christian Daudt <csd at broadcom.com>

  Thanks,
    csd




From lorenzo.pieralisi at arm.com  Fri Jul 26 11:56:45 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 26 Jul 2013 16:56:45 +0100
Subject: [RFC PATCH 3/3] cpuidle: big.LITTLE: vexpress-TC2 CPU idle driver
In-Reply-To: <alpine.LFD.2.03.1307261058510.15022@syhkavp.arg>
References: <1374750866-750-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374750866-750-4-git-send-email-lorenzo.pieralisi@arm.com>
 <alpine.LFD.2.03.1307261058510.15022@syhkavp.arg>
Message-ID: <20130726155645.GD28084@e102568-lin.cambridge.arm.com>

On Fri, Jul 26, 2013 at 04:00:48PM +0100, Nicolas Pitre wrote:
> On Thu, 25 Jul 2013, Lorenzo Pieralisi wrote:
> 
> > +static int notrace bl_powerdown_finisher(unsigned long arg)
> > +{
> > +	/* MCPM works with HW CPU identifiers */
> > +	unsigned int mpidr = read_cpuid_mpidr();
> > +	unsigned int cluster = (mpidr >> 8) & 0xf;
> > +	unsigned int cpu = mpidr & 0xf;
> 
> You probably want to use the MPIDR_AFFINITY_LEVEL() macro here.

Bah, I am so used to this pattern I don't notice anymore. Changed.

Thanks !
Lorenzo



From grundler at chromium.org  Fri Jul 26 11:58:55 2013
From: grundler at chromium.org (Grant Grundler)
Date: Fri, 26 Jul 2013 08:58:55 -0700
Subject: [PATCH v8 02/12] iommu/exynos: add missing cache flush for
 removed page table entries
In-Reply-To: <003801ce89f2$f8952d20$e9bf8760$@samsung.com>
References: <003801ce89f2$f8952d20$e9bf8760$@samsung.com>
Message-ID: <CANEJEGshTH2pymFWeN0rOmdxRZOvVFD+AEbZ23QdxNpVkDmevw@mail.gmail.com>

On Fri, Jul 26, 2013 at 4:26 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> This commit adds cache flush for removed small and large page entries
> in exynos_iommu_unmap(). Missing cache flush of removed page table
> entries can cause missing page fault interrupt when a master IP
> accesses an unmapped area.
>
> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>

Tested-by: Grant Grundler <grundler at chromium.org>

I'm convinced this is a critical fix to apply. Any time we touch the
IOMMU Page Table, we need to flush so the change is immediately
visible to the IOMMU.

thanks,
grant

> ---
>  drivers/iommu/exynos-iommu.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 233f382..e3be3e5 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
>         if (lv2ent_small(ent)) {
>                 *ent = 0;
>                 size = SPAGE_SIZE;
> +               pgtable_flush(ent, ent +1);
>                 priv->lv2entcnt[lv1ent_offset(iova)] += 1;
>                 goto done;
>         }
> @@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
>         BUG_ON(size < LPAGE_SIZE);
>
>         memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
> +       pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
>
>         size = LPAGE_SIZE;
>         priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE;
> --
> 1.7.2.5
>
>


From tom.cooksey at arm.com  Fri Jul 26 11:58:55 2013
From: tom.cooksey at arm.com (Tom Cooksey)
Date: Fri, 26 Jul 2013 16:58:55 +0100
Subject: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
In-Reply-To: <CAF6AEGtspnhSGNM4_QQubVfOkZ1Gh1-Z3iyHOLBPVWuqRy81ew@mail.gmail.com>
References: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com>
 <CAF6AEGtspnhSGNM4_QQubVfOkZ1Gh1-Z3iyHOLBPVWuqRy81ew@mail.gmail.com>
Message-ID: <000001ce8a19$08b1f960$1a15ec20$@cooksey@arm.com>

Hi Rob,

> >  * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
> >    allocate buffers for the GPU. Still not sure how to resolve this
> >    as we don't use DRM for our GPU driver.
> 
> any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
> once the dma-fence stuff is in place), we'd have gpu-specific drm
> (gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
> using prime/dmabuf to share between the two.

The "extra" buffers we were allocating from armsoc DDX were really
being allocated through DRM/GEM so we could get an flink name
for them and pass a reference to them back to our GPU driver on
the client side. If it weren't for our need to access those
extra off-screen buffers with the GPU we wouldn't need to
allocate them with DRM at all. So, given they are really "GPU"
buffers, it does absolutely make sense to allocate them in a
different driver to the display driver.

However, to avoid unnecessary memcpys & related cache
maintenance ops, we'd also like the GPU to render into buffers
which are scanned out by the display controller. So let's say
we continue using DRM_IOCTL_MODE_CREATE_DUMB to allocate scan
out buffers with the display's DRM driver but a custom ioctl
on the GPU's DRM driver to allocate non scanout, off-screen
buffers. Sounds great, but I don't think that really works
with DRI2. If we used two drivers to allocate buffers, which
of those drivers do we return in DRI2ConnectReply? Even if we
solve that somehow, GEM flink names are name-spaced to a
single device node (AFAIK). So when we do a DRI2GetBuffers,
how does the EGL in the client know which DRM device owns GEM
flink name "1234"? We'd need some pretty dirty hacks.

So then we looked at allocating _all_ buffers with the GPU's
DRM driver. That solves the DRI2 single-device-name and single
name-space issue. It also means the GPU would _never_ render
into buffers allocated through DRM_IOCTL_MODE_CREATE_DUMB.
One thing I wasn't sure about is if there was an objection
to using PRIME to export scanout buffers allocated with
DRM_IOCTL_MODE_CREATE_DUMB and then importing them into a GPU
driver to be rendered into? Is that a concern?

Anyway, that latter case also gets quite difficult. The "GPU"
DRM driver would need to know the constraints of the display
controller when allocating buffers intended to be scanned out.
For example, pl111 typically isn't behind an IOMMU and so
requires physically contiguous memory. We'd have to teach the
GPU's DRM driver about the constraints of the display HW. Not
exactly a clean driver model. :-(

I'm still a little stuck on how to proceed, so any ideas
would greatly appreciated! My current train of thought is
having a kind of SoC-specific DRM driver which allocates
buffers for both display and GPU within a single GEM
namespace. That SoC-specific DRM driver could then know the
constraints of both the GPU and the display HW. We could then
use PRIME to export buffers allocated with the SoC DRM driver
and import them into the GPU and/or display DRM driver.

Note: While it doesn't use the DRM framework, the Mali T6xx
kernel driver has supported importing buffers through dma_buf
for some time. I've even written an EGL extension :-):

<http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_im
port.txt>


> I'm not entirely sure that the directions that the current CDF
> proposals are headed is necessarily the right way forward.  I'd prefer
> to see small/incremental evolution of KMS (ie. add drm_bridge and
> drm_panel, and refactor the existing encoder-slave).  Keeping it
> inside drm means that we can evolve it more easily, and avoid layers
> of glue code for no good reason.

I think CDF could allow vendors to re-use code they've written
for their Android driver stack in DRM drivers more easily. Though
I guess ideally KMS would evolve to a point where it could be used
by an Android driver stack. I.e. Support explicit fences.


Cheers,

Tom







From Dave.Martin at arm.com  Fri Jul 26 12:00:15 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Fri, 26 Jul 2013 17:00:15 +0100
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <alpine.LFD.2.03.1307261047380.15022@syhkavp.arg>
References: <20130718180323.GC2655@localhost.localdomain>
 <alpine.LFD.2.03.1307181452480.14924@syhkavp.arg>
 <20130719102844.GA3746@localhost.localdomain>
 <20130719105907.GB27389@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307221353360.15022@syhkavp.arg>
 <20130723104352.GA3023@localhost.localdomain>
 <alpine.LFD.2.03.1307230821270.15022@syhkavp.arg>
 <20130723163319.GA781@e102568-lin.cambridge.arm.com>
 <20130725120424.GC2546@localhost.localdomain>
 <alpine.LFD.2.03.1307261047380.15022@syhkavp.arg>
Message-ID: <20130726160015.GF2282@localhost.localdomain>

On Fri, Jul 26, 2013 at 10:58:27AM -0400, Nicolas Pitre wrote:
> On Thu, 25 Jul 2013, Dave Martin wrote:
> 
> > On Tue, Jul 23, 2013 at 05:33:19PM +0100, Lorenzo Pieralisi wrote:
> > > On Tue, Jul 23, 2013 at 01:28:16PM +0100, Nicolas Pitre wrote:
> > > 
> > > [...]
> > > 
> > > > > > + * - The CPU is obviously no longer coherent with the other CPUs.
> > > > > > + *
> > > > > > + * Further considerations:
> > > > > > + *
> > > > > > + * - This relies on the presence and behavior of the AUXCR.SMP bit as
> > > > > > + *   documented in the ARMv7 TRM.  Vendor implementations that deviate from
> > > > > 
> > > > > Sorry to be pedantic here, but there is no "ARMv7 TRM".  The SMP bit is
> > > > > not part of ARMv7 at all.
> > > > 
> > > > Well, I just copied Lorenzo's words here, trusting he knew more about it 
> > > > than I do.
> > > > 
> > > > > Also, it seems that A9 isn't precisely the
> > > > > same: two ACTLR bits need to be twiddled.  R-class CPUs are generally
> > > > > not the same either.
> > > 
> > > If you mean the ACTLR.FW bit in A9, A5, and R7, then, IIRC, we do not need to
> > > clear it, clearing the SMP bit is enough.
> > > 
> > > See, Dave has a point, there is no explicit "unified v7 TRM disable
> > > clean and exit coherency procedure" even though the designers end goal is to
> > > have one and that's the one you wrote. The code you posted is perfectly ok on
> > > all v7 implementations in the kernel I am aware of, I stand to be corrected
> > > but to the best of my knowledge that's the case.
> > 
> > What I'm really concerned about here is not Cortex-*, but the vendors
> > who have their own CPU implementations.  I don't think I've ever seen
> > a TRM for one of those.
> 
> Could we wait until they materialize before worrying about possible 
> incompatibility issues?  After all this is not a user space ABI that 
> cannot be changed afterwards.  Remember this is Linux internal code we 
> have the ability to change when needed, hence we should resist the 
> temptation to over-engineer.

If I could think of a better name, I would suggest it ... but unless we call
it "cortexa" or something, I don't know what it should be.  I'm not sure
how much I like that either.  Strictly speaking, that's still not correct.

So I guess this comes down to being clear about which CPUs we expect it to
work for.

Right now, we know it works for A7 and A15.

It sounds like we believe it might work for A9.  Lorenzo might know about
A5, A7 etc.  But I'm not sure this exact sequence has been tested on any
of those CPUs(?)

We shouldn't expect it to work for any non ARM Ltd CPU, but on platforms
where firmware does the power control it's not Linux's responsibility
anyhow.  (Probably the case for most of those vendors).

> > I confess to exaggeration!  There was obviously an effort to align A15
> > and A7, but we know there are differences at the system level, and there
> > is always the possibility of b.L pairings which differ on things like
> > the SMP bit, or b.L pairings of CPUs not originally designed to pair but
> > which are "similar enough" to be pairable.
> > 
> > > sure about what we should do, but I reiterate my point, the sequence as
> > > it stands is OK on all NS v7 implementations I am aware of. We can add
> > > macros to differentiate processors when we need them, but again that's
> > > just my opinion, as correct as it can be.
> > 
> > I still vote for naming them a15_* a7_* or similar.
> > 
> > For big.LITTLE pairings, I think we should assume that the big CPU's
> > macro is usable on the LITTLE CPU too.  Assuming sane CPU designs, that
> > will be true, and we know it works for A15+A7.
> 
> The MCPM backend don't have to assume any kind of pairing.  The TC2 
> backend already has to test whether or not it is running on an A15 in 
> order to turn off L2 prefetching which is an A15-only feature.  This is 
> done outside of this macro exactly to keep the macro generic to all 
> known (so far) v7 implementations.

That's true.

Cheers
---Dave


From swarren at wwwdotorg.org  Fri Jul 26 12:01:13 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 10:01:13 -0600
Subject: Issue with gpio and pinmux
In-Reply-To: <20130726092601.GA1909@ab42.lan>
References: <51E667BC.3070804@parrot.com> <51E82FBB.1080905@wwwdotorg.org>
 <CACRpkdb1n07KoQZSme1EMJfV-9pHr-kd_1eJ6HsBV5gz7Dh3Ww@mail.gmail.com>
 <51EB590A.4010600@wwwdotorg.org>
 <CACRpkdZdbxEt67+YBKif4-BKAToOmN0_c8HFOdjSG91dtJwJQw@mail.gmail.com>
 <20130726092601.GA1909@ab42.lan>
Message-ID: <51F29D49.9090807@wwwdotorg.org>

On 07/26/2013 03:26 AM, Christian Ruppert wrote:
> On Thu, Jul 25, 2013 at 11:37:52AM +0200, Linus Walleij wrote:
>> On Sun, Jul 21, 2013 at 5:44 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>
>>> Actually, a better way to do (c) might be to just add an extra "op" to
>>> struct pinmux_ops; something like validate_gpio_mux(), passing in
>>> information such as whether a mux function is in effect on that pin,
>>> whether the pin is already claimed as a GPIO, and whether the function
>>> is being called to check a GPIO-claim or mux-claim operation . If the op
>>> is missing, no "dual claim" is allowed. If the op is present, the code
>>> in the op validates whether the particular GPIO is allowed to be claimed
>>> while the particular mux function is active.
>>>
>>> That way, I think any driver that doesn't want to allow dual-claim
>>> doesn't have to do anything, but the few drivers that do can code up
>>> whatever algorithm they want; for Tegra, I'd just allow everything for
>>> simplicity, but we could always enhance that later if we want.
>>
>> You are right, this would be an elegant solution.
>>
>> Christian, are you interested in coding this up?
> 
> When thinking about it, we require the same mechanism the other way
> round: If a GPIO is claimed first we need a mechanism to forbid
> incompatible reconfiguration of other functionalities until that GPIO is
> free again.
> 
> I like Stephen's proposal (in another mail) to claim GPIOs from the
> pinctrl drivers but instead of modifying the callback prototypes I
> suggest to add the following functions:
> 
> /*
>  * Claim GPIO pin (in the sense: forbid acutal GPIO usage)
>  */
> int claim_gpios(struct pinctrl_dev *pctl, unsigned *pins
>                 unsigned port_selector, unsigned func_selector);

I don't think that interface is quite right.

It assumes there's a concept of ports in pinctrl which there isn't. I
know you're arguing for that below, but dual-claiming and ports seem
like two related but separate issues, and I believe we should keep the
discussions somewhat separate.

How many entries are there in *pins? If just one, no need for a pointer.
If multiple, there needs to be a count parameter, and the
port/func_selector would also need to be arrays, since presumably
there's no reason to expect all the GPIOs to be in the same physical pin
group, if the HW is muxed at a pingroup level.

I think both a claim_gpios() and claim_mux_function() API would be
needed. If this function is intended to cover both, then I'd rather name
it claim_pins, since in the context of pinctrl, "GPIO" is a particular
usage of a pin, rather than a noun meaning the pin/ball/pad itself.

> /* allow GPIO usage of the given pins */
> void unclaim_gpios(struct pinctrl_dev *pctl, unsigned *pins);
> 
> Claiming could be fully dynamic. This way, driver authors don't need to
> implement additional callbacks or modify their existing ones. In the
> simplest case they do nothing. The entire conflict-checking logic is
> confined inside the core.
> 
> Alternatively, a similar set of functions could make the use of GPIOs
> exclusive with other functions for a given set of pins. This would work
> very well with the proposal below and would be easier to manage for most
> driver authors: The configuration would be static in most cases.
> (We just have to discuss about the default mode, do we want to keep the
> backward-compatible inclusive default or change everything to exclusive
> by default?).
> 
> A last point I would like to address before passing on to implementation
> is to introduce the notion of interfaces: I think it is important to
> introduce some orthogonality between unrelated interfaces which happen
> to be muxed on the same port and ideally we implement this coherently
> with the above.
> 
> I would like to know your opinion if the following proposal is generic
> enough or if it encodes too much chip-specific logic into the core:
> 
> - We extend the notion of pin groups to represent either ports (as it is
>   currently the case) or interfaces. No need to use name pin groups in
>   both cases, I'm open to proposals for better terminology.

I think if we start doing this, we really need to come up with unique
names for the usages for each type of "group of pins". Overloading "pin
group" for all the different uses will become rather confusing. It's bad
enough with some pinctrl drivers using them for real HW pingroups and
others for arbitrary SW groups of logically related pins. Introducing
new usage for "ports" and so on without actually calling them "ports" is
going to get even worse.

Perhaps each pin group needs a type associated with it, and we'll have:

PIN_GROUP_TYPE_PHYSICAL (only exists for HW that muxes groups of pins).
PIN_GROUP_TYPE_VIRTUAL (SW fake versions of _PHYSICAL)
PIN_GROUP_TYPE_PORT
PIN_GROUP_TYPE_...

?

I'm still not convinced that pinctrl should care about interfaces at all
though. Perhaps it might be useful if pinctrl wants to be really anal
about validating every detail of whether GPIOs and mux functions can
share pins. However, if the pinctrl configuration is correct, this isn't
necessary anyway, and hence just seems to bring additional complexity
for little benefit.

> - Functions are associated either to one port or a set of interfaces.

> - Functions continue to apply to an entire port but they only claim the
>   pins of the interfaces they are associated with.

This will be rather difficult to model in 100% accurate detail. Some
signals may be optional on some HW modules.

Consider an SDHCI controller which supports either 1-, 4-, or 8-bit
operation. Will a new function value be created for each of those
options, even though they all represent connecting the pins to the same
HW module, and hence the HW probably needs the same value programmed
into it for the relevant pins/groups irrespective of the bus width?

What about the pinctrl DT bindings that already exist, where the set of
available functions has already been defined to match HW. We need to
maintain compatibility with the old DT bindings, and hence can't just
create new function values out of thin air.

> - A client can request either a function or an interface from the
>   pinctrl core. In the second case, the core will figure out if the
>   request is coherent with previous requests (i.e. if there is a
>   function providing all requested interfaces) and call the driver
>   accordingly.

Requesting an interface doesn't make sense. The definition of an
interface implies zero knowledge, in general, about which pins that
interface will be routed to; in general HW can be designed to allow any
interface to be routed to/from different sets of pins. While it's true
that some SoCs don't actually allow this, I think it's best to keep the
pinctrl API model fully general, rather than allowing some drivers to
tailor their usage to more specific configurations. After all, the whole
point of pinctrl is to provide common semantics to drivers, so that if
the HW block they control are re-used across SoCs with different pinctrl
units, the drivers don't have to change.

> We'll have to figure out a few details but I would like to have an
> agreement on fundamentals before spending time on implementation.



From Dave.Martin at arm.com  Fri Jul 26 12:04:42 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Fri, 26 Jul 2013 17:04:42 +0100
Subject: [PATCH 2/4] ARM: traps: use <asm/opcodes.h> to get correct
 instruction order
In-Reply-To: <51F10967.1090302@codethink.co.uk>
References: <1374510833-25716-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374510833-25716-3-git-send-email-ben.dooks@codethink.co.uk>
 <20130724173435.GC4610@localhost.localdomain>
 <51F10967.1090302@codethink.co.uk>
Message-ID: <20130726160441.GG2282@localhost.localdomain>

On Thu, Jul 25, 2013 at 12:17:59PM +0100, Ben Dooks wrote:
> On 24/07/13 18:34, Dave Martin wrote:
> >On Mon, Jul 22, 2013 at 05:33:51PM +0100, Ben Dooks wrote:
> >>The trap handler needs to take into account the endian configuration of
> >>the system when loading instructions. Use<asm/opcodes.h>  to provide the
> >>necessary conversion functions.
> >>
> >>Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
> >>---
> >>  arch/arm/kernel/traps.c |   10 ++++++----
> >>  1 file changed, 6 insertions(+), 4 deletions(-)
> >>
> >>diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> >>index 1c08911..0a56e13 100644
> >>--- a/arch/arm/kernel/traps.c
> >>+++ b/arch/arm/kernel/traps.c
> >>@@ -34,6 +34,7 @@
> >>  #include<asm/unwind.h>
> >>  #include<asm/tls.h>
> >>  #include<asm/system_misc.h>
> >>+#include<asm/opcodes.h>
> >>
> >>  #include "signal.h"
> >
> >Looks like is_valid_bugaddr() might need fixing too?
> >
> >That will need __mem_to_opcode_thumb16() or __mem_to_opcode_arm()
> >depending on CONFIG_THUMB2_KERNEL.
> 
> I was looking at that, and was considering if this is the right
> thing to do or to change the value of BUG_INSTR_VALUE depending
> on this.
> 
> It is possible the linker may try and change the ordering of the
> BUG() instruction as it is being placed in the output with either
> a .hword or .word value. I will go and check this as soon as possible.

I guess the way would be to leave BUG_INSTR_VALUE as-is, and
inject it into the code using the appropriate __inst (similarly to the
KGDB case).

> 
> >>@@ -411,23 +412,24 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
> >>  	if (processor_mode(regs) == SVC_MODE) {
> >>  #ifdef CONFIG_THUMB2_KERNEL
> >>  		if (thumb_mode(regs)) {
> >>-			instr = ((u16 *)pc)[0];
> >>+			instr = __mem_to_opcode_thumb16(((u16 *)pc)[0]);
> >>  			if (is_wide_instruction(instr)) {
> >>  				instr<<= 16;
> >>-				instr |= ((u16 *)pc)[1];
> >>+				instr |= __mem_to_opcode_thumb16(((u16 *)pc)[1]);
> >
> >Could use __opcode_thumb32_compose(), in which case it might look like
> >
> >			if (is_wide_instruction(instr)) {
> >				unsigned int instr2 = __mem_to_opcode_thumb16(
> >					((u16 *)pc)[1]);
> >				instr = __opcode_thumb32_compose(instr, instr2);
> >
> >(Hmmm, I just noticed that is_wide_instruction and __opcode_is_thumb16()
> >kinda duplicate each other.  Could change that too, but it would look
> >more like pointless churn...  is_wide_instruction() is used in a fair
> >few places already.)
> 
> It is possible that it could be changed, but I will avoid that for this
> particular patch

No problem, that was just cosmetic.

> 
> >>  			}
> >>  		} else
> >>  #endif
> >>-			instr = *(u32 *) pc;
> >>+			instr = __mem_to_opcode_arm(*(u32 *) pc);
> >>  	} else if (thumb_mode(regs)) {
> >>  		if (get_user(instr, (u16 __user *)pc))
> >>  			goto die_sig;
> >>+		instr = __mem_to_opcode_thumb16(instr);
> >>  		if (is_wide_instruction(instr)) {
> >>  			unsigned int instr2;
> >>  			if (get_user(instr2, (u16 __user *)pc+1))
> >>  				goto die_sig;
> >>  			instr<<= 16;
> >>-			instr |= instr2;
> >>+			instr |= __mem_to_opcode_thumb16(instr2);
> >>  		}
> >>  	} else if (get_user(instr, (u32 __user *)pc)) {
> >
> >This also needs mem-to-opcode'ing.
> 
> Thanks, will check.

OK.

Cheers
---Dave


From zonque at gmail.com  Fri Jul 26 12:13:08 2013
From: zonque at gmail.com (Daniel Mack)
Date: Fri, 26 Jul 2013 18:13:08 +0200
Subject: Appended DTB files for multi-machine kernels
In-Reply-To: <alpine.LFD.2.03.1307041322070.18597@syhkavp.arg>
References: <51D5A938.30607@gmail.com>
 <alpine.LFD.2.03.1307041322070.18597@syhkavp.arg>
Message-ID: <51F2A014.7000209@gmail.com>

On 04.07.2013 19:28, Nicolas Pitre wrote:
> On Thu, 4 Jul 2013, Daniel Mack wrote:
>> In short, devices that have been deployed in quantities come in three
>> hardware variants, which all boot with a unique machine-id. We ship
>> kernel images that have board support for all three machine types, and
>> do minor fixups to platform data of some drivers at runtime, depending
>> on the board revision number (passed in via ATAGs).
>>

> What you describe above more or less fits the definition of what I 
> called the "impedance matcher".  However it doesn't need to be part of 
> the kernel at all.  But you should make it into a separate binary.
> 
> Please have a look at the bottom of this post for a more comprehensive 
> description: http://article.gmane.org/gmane.linux.ports.arm.kernel/242929

FWIW, I gave that approach a try today for a PXA based hardware
platform, and in fact it seems to work very well. Thanks again for
sharing the idea.

In case anyone is interested, the repository is here:

  https://github.com/zonque/pxa-impedance-matcher

As the README says, it's completely specific to my use case, but maybe
anyone can use the code base to spin a different version for a different
board.


Daniel



From grundler at chromium.org  Fri Jul 26 12:16:59 2013
From: grundler at chromium.org (Grant Grundler)
Date: Fri, 26 Jul 2013 09:16:59 -0700
Subject: [PATCH v8 03/12] iommu/exynos: fix page table maintenance
In-Reply-To: <003901ce89f3$126c0390$37440ab0$@samsung.com>
References: <003901ce89f3$126c0390$37440ab0$@samsung.com>
Message-ID: <CANEJEGvp1msjkMLN-8TfykYXmrT+sq8dMkNsVEoh9i2vDoh=tg@mail.gmail.com>

On Fri, Jul 26, 2013 at 4:27 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> This prevents allocating lv2 page table for the lv1 page table entry
> that already has 1MB page mapping. In addition some BUG_ON() is
> changed to WARN_ON().
>
> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>

Reviewed-by: Grant Grundler <grundler at chromium.org>

In reviewing this, I noticed another issue that is related, but not
caused by this patch. See below.

> ---
>  drivers/iommu/exynos-iommu.c |   52 +++++++++++++++++++++++++++++------------
>  1 files changed, 37 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index e3be3e5..6c4ecce 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -52,11 +52,11 @@
>  #define lv2ent_large(pent) ((*(pent) & 3) == 1)
>
>  #define section_phys(sent) (*(sent) & SECT_MASK)
> -#define section_offs(iova) ((iova) & 0xFFFFF)
> +#define section_offs(iova) ((iova) & ~SECT_MASK)
>  #define lpage_phys(pent) (*(pent) & LPAGE_MASK)
> -#define lpage_offs(iova) ((iova) & 0xFFFF)
> +#define lpage_offs(iova) ((iova) & ~LPAGE_MASK)
>  #define spage_phys(pent) (*(pent) & SPAGE_MASK)
> -#define spage_offs(iova) ((iova) & 0xFFF)
> +#define spage_offs(iova) ((iova) & ~SPAGE_MASK)
>
>  #define lv1ent_offset(iova) ((iova) >> SECT_ORDER)
>  #define lv2ent_offset(iova) (((iova) & 0xFF000) >> SPAGE_ORDER)
> @@ -862,12 +862,14 @@ static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long iova,
>                 pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
>                 BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
>                 if (!pent)
> -                       return NULL;
> +                       return ERR_PTR(-ENOMEM);
>
>                 *sent = mk_lv1ent_page(__pa(pent));
>                 *pgcounter = NUM_LV2ENTRIES;
>                 pgtable_flush(pent, pent + NUM_LV2ENTRIES);
>                 pgtable_flush(sent, sent + 1);
> +       } else if (lv1ent_section(sent)) {
> +               return ERR_PTR(-EADDRINUSE);
>         }
>
>         return page_entry(sent, iova);
> @@ -894,6 +896,12 @@ static int lv1set_section(unsigned long *sent, phys_addr_t paddr, short *pgcnt)
>         return 0;
>  }
>
> +static void clear_page_table(unsigned long *ent, int n)
> +{
> +       if (n > 0)
> +               memset(ent, 0, sizeof(*ent) * n);
> +}
> +
>  static int lv2set_page(unsigned long *pent, phys_addr_t paddr, size_t size,
>                                                                 short *pgcnt)
>  {
> @@ -908,7 +916,7 @@ static int lv2set_page(unsigned long *pent, phys_addr_t paddr, size_t size,
>                 int i;
>                 for (i = 0; i < SPAGES_PER_LPAGE; i++, pent++) {
>                         if (!lv2ent_fault(pent)) {
> -                               memset(pent, 0, sizeof(*pent) * i);
> +                               clear_page_table(pent - i, i);
>                                 return -EADDRINUSE;

I am wondering about two issues with this error handling:
1) we don't call pgtable_flush() in this case - I think just for
consistency we should - don't rush to add since my next comment is to
change this error handling completely.

2) If  -EADDRINUSE is correct, why does the code clear the IO Page
table entries?

   I think this error path should either
   (a) BUG_ON (ie panic) since this is an inconsistency between
generic IOMMU page allocation and chip specific IOMMU mapping code OR
   (b) WARN_ON, not clear the entries, and hope whoever was using it
can finish using the system before crashing or gracefully shutting
down.

In any case, I'm pretty sure this code needs to change and it should
be in a follow up to this series.

thanks,
grant

>                         }
>
> @@ -944,17 +952,16 @@ static int exynos_iommu_map(struct iommu_domain *domain, unsigned long iova,
>                 pent = alloc_lv2entry(entry, iova,
>                                         &priv->lv2entcnt[lv1ent_offset(iova)]);
>
> -               if (!pent)
> -                       ret = -ENOMEM;
> +               if (IS_ERR(pent))
> +                       ret = PTR_ERR(pent);
>                 else
>                         ret = lv2set_page(pent, paddr, size,
>                                         &priv->lv2entcnt[lv1ent_offset(iova)]);
>         }
>
> -       if (ret) {
> -               pr_debug("%s: Failed to map iova 0x%lx/0x%x bytes\n",
> -                                                       __func__, iova, size);
> -       }
> +       if (ret)
> +               pr_err("%s: Failed(%d) to map 0x%#x bytes @ %#lx\n",
> +                       __func__, ret, size, iova);
>
>         spin_unlock_irqrestore(&priv->pgtablelock, flags);
>
> @@ -968,6 +975,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
>         struct sysmmu_drvdata *data;
>         unsigned long flags;
>         unsigned long *ent;
> +       size_t err_pgsize;
>
>         BUG_ON(priv->pgtable == NULL);
>
> @@ -976,7 +984,10 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
>         ent = section_entry(priv->pgtable, iova);
>
>         if (lv1ent_section(ent)) {
> -               BUG_ON(size < SECT_SIZE);
> +               if (WARN_ON(size < SECT_SIZE)) {
> +                       err_pgsize = SECT_SIZE;
> +                       goto err;
> +               }
>
>                 *ent = 0;
>                 pgtable_flush(ent, ent + 1);
> @@ -1008,9 +1019,12 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
>         }
>
>         /* lv1ent_large(ent) == true here */
> -       BUG_ON(size < LPAGE_SIZE);
> +       if (WARN_ON(size < LPAGE_SIZE)) {
> +               err_pgsize = LPAGE_SIZE;
> +               goto err;
> +       }
>
> -       memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
> +       clear_page_table(ent, SPAGES_PER_LPAGE);
>         pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
>
>         size = LPAGE_SIZE;
> @@ -1023,8 +1037,16 @@ done:
>                 sysmmu_tlb_invalidate_entry(data->dev, iova);
>         spin_unlock_irqrestore(&priv->lock, flags);
>
> -
>         return size;
> +err:
> +       spin_unlock_irqrestore(&priv->pgtablelock, flags);
> +
> +       pr_err("%s: Failed due to size(%#x) @ %#lx is"\
> +               " smaller than page size %#x\n",
> +               __func__, size, iova, err_pgsize);
> +
> +       return 0;
> +
>  }
>
>  static phys_addr_t exynos_iommu_iova_to_phys(struct iommu_domain *domain,
> --
> 1.7.2.5
>
>


From lorenzo.pieralisi at arm.com  Fri Jul 26 12:24:10 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 26 Jul 2013 17:24:10 +0100
Subject: [PATCH 1/4] ARM: vexpress/dcscb: fix cache disabling sequences
In-Reply-To: <20130726160015.GF2282@localhost.localdomain>
References: <alpine.LFD.2.03.1307181452480.14924@syhkavp.arg>
 <20130719102844.GA3746@localhost.localdomain>
 <20130719105907.GB27389@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307221353360.15022@syhkavp.arg>
 <20130723104352.GA3023@localhost.localdomain>
 <alpine.LFD.2.03.1307230821270.15022@syhkavp.arg>
 <20130723163319.GA781@e102568-lin.cambridge.arm.com>
 <20130725120424.GC2546@localhost.localdomain>
 <alpine.LFD.2.03.1307261047380.15022@syhkavp.arg>
 <20130726160015.GF2282@localhost.localdomain>
Message-ID: <20130726162410.GE28084@e102568-lin.cambridge.arm.com>

On Fri, Jul 26, 2013 at 05:00:15PM +0100, Dave Martin wrote:
> On Fri, Jul 26, 2013 at 10:58:27AM -0400, Nicolas Pitre wrote:
> > On Thu, 25 Jul 2013, Dave Martin wrote:
> > 
> > > On Tue, Jul 23, 2013 at 05:33:19PM +0100, Lorenzo Pieralisi wrote:
> > > > On Tue, Jul 23, 2013 at 01:28:16PM +0100, Nicolas Pitre wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > > > + * - The CPU is obviously no longer coherent with the other CPUs.
> > > > > > > + *
> > > > > > > + * Further considerations:
> > > > > > > + *
> > > > > > > + * - This relies on the presence and behavior of the AUXCR.SMP bit as
> > > > > > > + *   documented in the ARMv7 TRM.  Vendor implementations that deviate from
> > > > > > 
> > > > > > Sorry to be pedantic here, but there is no "ARMv7 TRM".  The SMP bit is
> > > > > > not part of ARMv7 at all.
> > > > > 
> > > > > Well, I just copied Lorenzo's words here, trusting he knew more about it 
> > > > > than I do.
> > > > > 
> > > > > > Also, it seems that A9 isn't precisely the
> > > > > > same: two ACTLR bits need to be twiddled.  R-class CPUs are generally
> > > > > > not the same either.
> > > > 
> > > > If you mean the ACTLR.FW bit in A9, A5, and R7, then, IIRC, we do not need to
> > > > clear it, clearing the SMP bit is enough.
> > > > 
> > > > See, Dave has a point, there is no explicit "unified v7 TRM disable
> > > > clean and exit coherency procedure" even though the designers end goal is to
> > > > have one and that's the one you wrote. The code you posted is perfectly ok on
> > > > all v7 implementations in the kernel I am aware of, I stand to be corrected
> > > > but to the best of my knowledge that's the case.
> > > 
> > > What I'm really concerned about here is not Cortex-*, but the vendors
> > > who have their own CPU implementations.  I don't think I've ever seen
> > > a TRM for one of those.
> > 
> > Could we wait until they materialize before worrying about possible 
> > incompatibility issues?  After all this is not a user space ABI that 
> > cannot be changed afterwards.  Remember this is Linux internal code we 
> > have the ability to change when needed, hence we should resist the 
> > temptation to over-engineer.
> 
> If I could think of a better name, I would suggest it ... but unless we call
> it "cortexa" or something, I don't know what it should be.  I'm not sure
> how much I like that either.  Strictly speaking, that's still not correct.
> 
> So I guess this comes down to being clear about which CPUs we expect it to
> work for.
> 
> Right now, we know it works for A7 and A15.
> 
> It sounds like we believe it might work for A9.  Lorenzo might know about
> A5, A7 etc.  But I'm not sure this exact sequence has been tested on any
> of those CPUs(?)

I tested this sequence on A9 MP a while ago, even though, obviously was not
this same macro. I know for certain it has been tested on A5, again not the
same macro but the same sequence.

On R7 honestly I can't certify.

What if we postpone the consolidation till MCPM for some A9 platforms
(eg Tegra) is posted (and in the meantime you leave the macro in mach-vexpress
to avoid duplication) ?

Thank you,
Lorenzo



From hartleys at visionengravers.com  Fri Jul 26 12:26:03 2013
From: hartleys at visionengravers.com (H Hartley Sweeten)
Date: Fri, 26 Jul 2013 11:26:03 -0500
Subject: [PATCH 02/12] ARM: ep93xx: vision_ep9307: Use MMC CD and RO GPIO
In-Reply-To: <1818634.2aPQusYJQq@avalon>
References: <1374794808-21890-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <1374794808-21890-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <ADE657CA350FB648AAC2C43247A983F0021DAC5C20AC@AUSP01VMBX24.collaborationhost.net>
 <1818634.2aPQusYJQq@avalon>
Message-ID: <ADE657CA350FB648AAC2C43247A983F0021DAC5C212B@AUSP01VMBX24.collaborationhost.net>

On Friday, July 26, 2013 2:55 AM, Laurent Pinchart wrote:
> On Thursday 25 July 2013 19:19:52 H Hartley Sweeten wrote:
>> On Thursday, July 25, 2013 4:27 PM, Laurent Pinchart wrote:
>>> Pass the CD and RO GPIO numbers to the MMC SPI driver and remove the
>>> custom .get_cd() and .get_ro() callback functions.
>>> 
>>> Signed-off-by: Laurent Pinchart
>>> <laurent.pinchart+renesas at ideasonboard.com>
>>> ---
>>> 
>>>  arch/arm/mach-ep93xx/vision_ep9307.c | 56  +++---------------------------
>>>  1 file changed, 4 insertions(+), 52 deletions(-)

<snip>

>> I tested this and it _kind_ of works.
>> 
>> The card detect is a bit flaky due to the gpio interrupt debounce not being
>> enabled.
>> 
>> The only way I can see to fix this is add the following to this patch:

<snip>

> What about extending the mmc_spi and MMC core with GPIO debounce support ? The 
> mmc_spi driver would get a new cd_gpio_debounce field, which would be passed 
> to mmc_gpio_request_cd(). I can cook up a patch.

Works for me. That would also remove the need for the platform init to request then free
the GPIO just to set the debounce.

Make sure you do the gpiu_set_debounce() after the GPIO has been requested or you
trigger a WARN due to the auto-requested GPIO. Then, of course, the drivers gpio request
will fail...

I'll give it a test when you post it.

Thanks,
Hartley



From santosh.shilimkar at ti.com  Fri Jul 26 12:28:26 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Fri, 26 Jul 2013 12:28:26 -0400
Subject: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes
In-Reply-To: <20130726151021.GU24642@n2100.arm.linux.org.uk>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
 <20130726151021.GU24642@n2100.arm.linux.org.uk>
Message-ID: <51F2A3AA.4060801@ti.com>

On Friday 26 July 2013 11:10 AM, Russell King - ARM Linux wrote:
> On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
>> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
>> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
>> PFNs but that breaks the dma_mask for few block layer drivers since
>> ARM start of physical memory is not PFN0 unlike most of the architectures.
>> Some more read on it is here:
>> 	http://lwn.net/Articles/543408/
>> 	http://lwn.net/Articles/543424/
>>
>> To address this issue, we introduce generic dma_max_pfn() helper which
>> can be overridden from the architectures.
>> 	
>> Another intention behind move to nobootmem is also to convert ARM to
>> switch to memblock and getting rid of bootmem allocator dependency which
>> don't work for LPAE machines which has physical memory starting beyond
>> 4 GB boundary. It needs changes to core kernel and also a new memblock
>> API. More on this can be found here:
>> 	https://lkml.org/lkml/2013/6/29/77
>>
>> I have been trying to cook up these patches with kind help from Russell
>> and we know series don't solve all the dma_mask bad assumptions. But at
>> least I am hoping that it can get the ball rolling.	
>>
>> Comments/testing help is welcome !!
> 
> As this is related to some of the cleanup of dma_mask which I've been
> doing, I think it may make sense to roll this into one tree.  Any
> objection to that?
> 
> Can we get any acks on this stuff from Jens and Jejb etc - especially
> for the bits which touch block/ and for the scsi bits as these are
> touching other subsystems.  (oddly, linux-scsi wasn't on the original
> mail for this series summary.)
> 
Sorry I missed the scsi lists on the summary patch.

While browsing the code I found another spot in mmc layer which
needs fixing. The patch is at the end of the email with Chris
and linux-mmc cc'ed here.

Regards,
Santosh

>From 06a27a784a1fd86bf22adf1b247ac82a7c21d46b Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar at ti.com>
Date: Fri, 19 Jul 2013 21:36:46 -0400
Subject: [PATCH] mmc: Use dma_max_pfn(dev) helper for bounce_limit
 calculations

DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. MMC queue layer
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Chris Ball <cjb at laptop.org>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 drivers/mmc/card/queue.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index fa9632e..357bbc5 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -15,6 +15,7 @@
 #include <linux/freezer.h>
 #include <linux/kthread.h>
 #include <linux/scatterlist.h>
+#include <linux/dma-mapping.h>
 
 #include <linux/mmc/card.h>
 #include <linux/mmc/host.h>
@@ -196,7 +197,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card,
 	struct mmc_queue_req *mqrq_prev = &mq->mqrq[1];
 
 	if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask)
-		limit = *mmc_dev(host)->dma_mask;
+		limit = dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT;
 
 	mq->card = card;
 	mq->queue = blk_init_queue(mmc_request_fn, lock);
-- 
1.7.9.5



From victor.kamensky at linaro.org  Fri Jul 26 12:28:52 2013
From: victor.kamensky at linaro.org (Victor Kamensky)
Date: Fri, 26 Jul 2013 09:28:52 -0700
Subject: [PATCH 0/1] ARM: atomic64: fix endian-ness in atomic.h
Message-ID: <1374856133-2939-1-git-send-email-victor.kamensky@linaro.org>

Fixes atomic64_xxx functions endian-ness isussues as it was discussed on
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185898.html
Patch itself follows in separate email. This cover letter describes what
testing has been done

Tested on pandaboard for both cases: LE and BE, CONFIG_GENERIC_ATOMIC64 was
forcefully disabled.

In BE case it was tested on top of Ben's other BE patches covered by 
(updates for be8  patch series).

The following tests passed:

1) CONFIG_ATOMIC64_SELFTEST

2) The following module produced identical output for both LE, BE, 
and GENERIC_ATOMIC64

#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/atomic.h>


atomic64_t a = {0};

#define STEP 0x40000000

void atomic64_add_test1 (void)
{
    atomic64_add(STEP, &a);
}    

void test_atomic64_add(void)
{
    int i;

    printk("atomic64_add\n");

    atomic64_set(&a, 0);
    
    printk("a = 0x%llx (%lld)\n", a.counter, a.counter);

    for (i = 0; i < 10; i++) {
        atomic64_add_test1();
        printk("i = %2d: a = 0x%llx (%lld)\n", i, a.counter, a.counter);
    }
}

void atomic64_sub_test1 (void)
{
    atomic64_sub(STEP, &a);
}

void test_atomic64_sub(void)
{
    int i;

    printk("atomic64_sub\n");

    /* value of a is set by previos test */
    printk("a = 0x%llx (%lld)\n", a.counter, a.counter);

    for (i = 0; i < 20; i++) {
        atomic64_sub_test1();
        printk("i = %2d: a = 0x%llx (%lld)\n", i, a.counter, a.counter);
    }
}

u64 atomic64_add_return_test1 (void)
{
    return atomic64_add_return(STEP, &a);
}    

void test_atomic64_add_return(void)
{
    int i;
    u64 ret;

    printk("atomic64_add_return\n");

    atomic64_set(&a, 0);
    
    printk("a = 0x%llx (%lld)\n", a.counter, a.counter);

    for (i = 0; i < 10; i++) {
        ret = atomic64_add_return_test1();
        printk("i = %2d: a = 0x%llx (%lld), ret = %llx (%lld)\n",
               i, a.counter, a.counter, ret, ret);
    }
}

u64 atomic64_sub_return_test1 (void)
{
    return atomic64_sub_return(STEP, &a);
}

void test_atomic64_sub_return(void)
{
    int i;
    u64 ret;

    printk("atomic64_sub_return\n");

    /* value of a is set by previos test */
    printk("a = 0x%llx (%lld)\n", a.counter, a.counter);

    for (i = 0; i < 20; i++) {
        ret = atomic64_sub_return_test1();
        printk("i = %2d: a = 0x%llx (%lld), ret = %llx (%lld)\n",
               i, a.counter, a.counter, ret, ret);
    }
}

void atomic64_dec_if_positive_test1 (void)
{
    atomic64_dec_if_positive(&a);
}

void test1_atomic64_dec_if_positive (void)
{
    int i;    
    printk("atomic64_dec_if_positive test1\n");

    atomic64_set(&a, 0x100000003);    
    /* value of a is set by previos test */
    printk("a = 0x%llx (%lld)\n", a.counter, a.counter);

    for (i = 0; i < 10; i++) {
        atomic64_dec_if_positive_test1();
        printk("i = %2d: a = 0x%llx (%lld))\n",
               i, a.counter, a.counter);
    }
}

void test2_atomic64_dec_if_positive (void)
{
    int i;    
    printk("atomic64_dec_if_positive test2\n");

    atomic64_set(&a, 0x3);    
    /* value of a is set by previos test */
    printk("a = 0x%llx (%lld)\n", a.counter, a.counter);

    for (i = 0; i < 10; i++) {
        atomic64_dec_if_positive_test1();
        printk("i = %2d: a = 0x%llx (%lld))\n",
               i, a.counter, a.counter);
    }
}

void atomic64_add_unless_test1(long long u)
{
    atomic64_add_unless(&a, STEP, u);
}

void test_atomic64_add_unless(void)
{
    int i;
    u64 prev;
    
    printk("atomic64_add_unless\n");

    atomic64_set(&a, 0);
    
    printk("a = 0x%llx (%lld)\n", a.counter, a.counter);

    for (i = 0; i < 10; i++) {
        prev = a.counter;
        atomic64_add_unless_test1(prev);
        printk("i = %2d: no change: prev = 0x%llx (%lld), a = 0x%llx (%lld)\n", i,
               prev, prev, a.counter, a.counter);
        atomic64_add_unless_test1(prev - 1);
        printk("i = %2d: change: prev = 0x%llx (%lld), a = 0x%llx (%lld)\n", i,
               prev, prev, a.counter, a.counter);
    }
}


int
init_module (void)
{
    test_atomic64_add();
    test_atomic64_sub();

    test_atomic64_add_return();
    test_atomic64_sub_return();

    test1_atomic64_dec_if_positive();
    test2_atomic64_dec_if_positive();

    test_atomic64_add_unless();
    
    return 0;
}

void
cleanup_module(void)
{
}

MODULE_LICENSE("GPL");

Thanks,
Victor

Victor Kamensky (1):
  ARM: atomic64: fix endian-ness in atomic.h

 arch/arm/include/asm/atomic.h | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

-- 
1.8.1.4



From victor.kamensky at linaro.org  Fri Jul 26 12:28:53 2013
From: victor.kamensky at linaro.org (Victor Kamensky)
Date: Fri, 26 Jul 2013 09:28:53 -0700
Subject: [PATCH 1/1] ARM: atomic64: fix endian-ness in atomic.h
In-Reply-To: <1374856133-2939-1-git-send-email-victor.kamensky@linaro.org>
References: <1374856133-2939-1-git-send-email-victor.kamensky@linaro.org>
Message-ID: <1374856133-2939-2-git-send-email-victor.kamensky@linaro.org>

Fix inline asm for atomic64_xxx functions in arm atomic.h. Instead of
%H operand specifiers code should use %Q for least significant part
of the value, and %R for the most significant part of the value. %H
always returns the higher of the two register numbers, and therefore
it is not endian neutral. %H should be used with ldrexd and strexd
instructions.

Signed-off-by: Victor Kamensky <victor.kamensky at linaro.org>
---
 arch/arm/include/asm/atomic.h | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index da1c77d..6447a0b 100644
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h
@@ -301,8 +301,8 @@ static inline void atomic64_add(u64 i, atomic64_t *v)
 
 	__asm__ __volatile__("@ atomic64_add\n"
 "1:	ldrexd	%0, %H0, [%3]\n"
-"	adds	%0, %0, %4\n"
-"	adc	%H0, %H0, %H4\n"
+"	adds	%Q0, %Q0, %Q4\n"
+"	adc	%R0, %R0, %R4\n"
 "	strexd	%1, %0, %H0, [%3]\n"
 "	teq	%1, #0\n"
 "	bne	1b"
@@ -320,8 +320,8 @@ static inline u64 atomic64_add_return(u64 i, atomic64_t *v)
 
 	__asm__ __volatile__("@ atomic64_add_return\n"
 "1:	ldrexd	%0, %H0, [%3]\n"
-"	adds	%0, %0, %4\n"
-"	adc	%H0, %H0, %H4\n"
+"	adds	%Q0, %Q0, %Q4\n"
+"	adc	%R0, %R0, %R4\n"
 "	strexd	%1, %0, %H0, [%3]\n"
 "	teq	%1, #0\n"
 "	bne	1b"
@@ -341,8 +341,8 @@ static inline void atomic64_sub(u64 i, atomic64_t *v)
 
 	__asm__ __volatile__("@ atomic64_sub\n"
 "1:	ldrexd	%0, %H0, [%3]\n"
-"	subs	%0, %0, %4\n"
-"	sbc	%H0, %H0, %H4\n"
+"	subs	%Q0, %Q0, %Q4\n"
+"	sbc	%R0, %R0, %R4\n"
 "	strexd	%1, %0, %H0, [%3]\n"
 "	teq	%1, #0\n"
 "	bne	1b"
@@ -360,8 +360,8 @@ static inline u64 atomic64_sub_return(u64 i, atomic64_t *v)
 
 	__asm__ __volatile__("@ atomic64_sub_return\n"
 "1:	ldrexd	%0, %H0, [%3]\n"
-"	subs	%0, %0, %4\n"
-"	sbc	%H0, %H0, %H4\n"
+"	subs	%Q0, %Q0, %Q4\n"
+"	sbc	%R0, %R0, %R4\n"
 "	strexd	%1, %0, %H0, [%3]\n"
 "	teq	%1, #0\n"
 "	bne	1b"
@@ -428,9 +428,9 @@ static inline u64 atomic64_dec_if_positive(atomic64_t *v)
 
 	__asm__ __volatile__("@ atomic64_dec_if_positive\n"
 "1:	ldrexd	%0, %H0, [%3]\n"
-"	subs	%0, %0, #1\n"
-"	sbc	%H0, %H0, #0\n"
-"	teq	%H0, #0\n"
+"	subs	%Q0, %Q0, #1\n"
+"	sbc	%R0, %R0, #0\n"
+"	teq	%R0, #0\n"
 "	bmi	2f\n"
 "	strexd	%1, %0, %H0, [%3]\n"
 "	teq	%1, #0\n"
@@ -459,8 +459,8 @@ static inline int atomic64_add_unless(atomic64_t *v, u64 a, u64 u)
 "	teqeq	%H0, %H5\n"
 "	moveq	%1, #0\n"
 "	beq	2f\n"
-"	adds	%0, %0, %6\n"
-"	adc	%H0, %H0, %H6\n"
+"	adds	%Q0, %Q0, %Q6\n"
+"	adc	%R0, %R0, %R6\n"
 "	strexd	%2, %0, %H0, [%4]\n"
 "	teq	%2, #0\n"
 "	bne	1b\n"
-- 
1.8.1.4



From b.brezillon at overkiz.com  Fri Jul 26 12:35:34 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Fri, 26 Jul 2013 18:35:34 +0200
Subject: [PATCH v2 00/42] ARM: at91: move to common clk framework
In-Reply-To: <51F2996B.6000406@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <51F28370.6050304@gmail.com> <51F2996B.6000406@overkiz.com>
Message-ID: <51F2A556.8020109@overkiz.com>

On 26/07/2013 17:44, boris brezillon wrote:
> On 26/07/2013 16:10, Richard Genoud wrote:
>> On 17/07/2013 15:34, Boris BREZILLON wrote:
>>> Hello,
>>>
>>> This patch series is a proposal to move at91 clock implementation
>>> to common clk framework.
>>>
>>> Most of the clock provided by the PMC (Power Management Controller) are
>>> implemented :
>>> - main clock (main oscillator)
>>> - pll clocks
>>> - master clock
>>> - programmable clocks
>>> - utmi clock
>>> - peripheral clocks
>>> - system clocks
>>>
>>> This implementation is compatible with device tree: the goal is
>>> to define the whole clock tree in the device tree (all currently
>>> available dt SoCs and boards are patched to support dt clocks).
>>> Please feel free to comment the dt bindinds.
>>>
>>> I removed the register_clocks function in SoC supporting dt boards only:
>>> - at91sam9x5 SoCs
>>> - at91sam9n12 SoC
>>> - sama5d3 SoCs
>>>
>>> This patch series is based on linux-next and has been tested on
>>> sama5d31ek
>>> board using device tree. It compiles for other SoCs and both with and
>>> without
>>> dt support, but it has not been tested.
>>>
>>> BTW could other people test it on other boards (I only have a kizbox and
>>> a sama5d31ek dev kit).
>>>
>>> Best Regards,
>>> Boris
>>>
>>> Changes since v1:
>>>   - fix bugs in pll, programmable and system clock implementations
>>>     (wrong bit position).
>>>   - add usb clock configuration support (ohci and udc drivers +
>>>     clk_lookup for non dt boards)
>>>   - rework of the system clock interfaces (no need to define a parent
>>> clock,
>>>     system clock is a gate with no rate info)
>>>   - change system, peripheral and programmable clk dt bindings (1
>>> master node
>>>     and multiple child nodes each defining a system/peripheral or
>>> prog clock)
>>>   - fix bugs in sama5 dt definition
>>>
>> Hi Boris,
>>
>> First of all: Big thumbs up for this work !
>>
>> Then, I tested the serie on at91sam9g35ek (sam9x5 familly), and I see
>> some problems:
>> kernel is next-20130725 with the v4 serie of "ARM: at91: prepare
>> transition to common clk framework"
>> and v2 serie of "ARM: at91: move to common clk framework"
>>
>> [    0.000000] Booting Linux on physical CPU 0x0
>> [    0.000000] Linux version 3.11.0-rc2-next-20130725+
>> (rgenoud at lnx-rg) (gcc version 4.7.3 (Buildroot
>> 2013.05-00157-g6d1e60b-dirty) ) #61 Fri Jul 26 15:30:13 CEST 2013
>> [    0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ),
>> cr=00053177
>> [    0.000000] CPU: VIVT data cache, VIVT instruction cache
>> [    0.000000] Machine: Atmel AT91SAM (Device Tree), model: Atmel
>> AT91SAM9G35-EK
>> [    0.000000] bootconsole [earlycon0] enabled
>> [    0.000000] Memory policy: ECC disabled, Data cache writeback
>> [    0.000000] AT91: Detected soc type: at91sam9x5
>> [    0.000000] AT91: Detected soc subtype: at91sam9g35
>> [    0.000000] AT91: sram at 0x300000 of 0x8000 mapped at 0xfef70000
>> [    0.000000] On node 0 totalpages: 32768
>> [    0.000000] free_area_init_node: node 0, pgdat c039d208,
>> node_mem_map c03b5000
>> [    0.000000]   Normal zone: 256 pages used for memmap
>> [    0.000000]   Normal zone: 0 pages reserved
>> [    0.000000]   Normal zone: 32768 pages, LIFO batch:7
>> [    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
>> [    0.000000] pcpu-alloc: [0] 0
>> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
>> Total pages: 32512
>> [    0.000000] Kernel command line: console=ttyS0,115200 loglevel=8
>> ip=dhcp root=/dev/nfs nfsroot=10.128.0.9:/nfsroot,v3 rw earlyprintk
>> [    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
>> [    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536
>> bytes)
>> [    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768
>> bytes)
>> [    0.000000] Memory: 126044K/131072K available (2804K kernel code,
>> 126K rwdata, 592K rodata, 141K init, 93K bss, 5028K reserved)
>> [    0.000000] Virtual kernel memory layout:
>> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>> [    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>> [    0.000000]     vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
>> [    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
>> [    0.000000]       .text : 0xc0008000 - 0xc0359550   (3398 kB)
>> [    0.000000]       .init : 0xc035a000 - 0xc037d61c   ( 142 kB)
>> [    0.000000]       .data : 0xc037e000 - 0xc039d920   ( 127 kB)
>> [    0.000000]        .bss : 0xc039d920 - 0xc03b4ff4   (  94 kB)
>> [    0.000000] NR_IRQS:16 nr_irqs:16 16
>> [    0.000000] AT91: PIT: mck rate = 0
>> [    0.000000] ------------[ cut here ]------------
>> [    0.000000] WARNING: CPU: 0 PID: 0 at
>> arch/arm/mach-at91/at91sam926x_time.c:259
>> at91sam926x_pit_init+0x114/0x234()
>> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
>> 3.11.0-rc2-next-20130725+ #61
>> [    0.000000] [<c000ca18>] (unwind_backtrace+0x0/0xe0) from
>> [<c000b0f0>] (show_stack+0x10/0x14)
>> [    0.000000] [<c000b0f0>] (show_stack+0x10/0x14) from [<c00144e0>]
>> (warn_slowpath_common+0x5c/0x7c)
>> [    0.000000] [<c00144e0>] (warn_slowpath_common+0x5c/0x7c) from
>> [<c00145b8>] (warn_slowpath_null+0x18/0x1c)
>> [    0.000000] [<c00145b8>] (warn_slowpath_null+0x18/0x1c) from
>> [<c03607b0>] (at91sam926x_pit_init+0x114/0x234)
>> [    0.000000] [<c03607b0>] (at91sam926x_pit_init+0x114/0x234) from
>> [<c035ca4c>] (time_init+0x1c/0x24)
>> [    0.000000] [<c035ca4c>] (time_init+0x1c/0x24) from [<c035a650>]
>> (start_kernel+0x19c/0x2f4)
>> [    0.000000] [<c035a650>] (start_kernel+0x19c/0x2f4) from
>> [<20008040>] (0x20008040)
>> [    0.000000] ---[ end trace 1b75b31a2719ed1c ]---
>> [    0.000000] Division by zero in kernel.
>> [    0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G        W
>> 3.11.0-rc2-next-20130725+ #61
>> [    0.000000] [<c000ca18>] (unwind_backtrace+0x0/0xe0) from
>> [<c000b0f0>] (show_stack+0x10/0x14)
>> [    0.000000] [<c000b0f0>] (show_stack+0x10/0x14) from [<c013f0a0>]
>> (Ldiv0_64+0x8/0x18)
>> [    0.000000] [<c013f0a0>] (Ldiv0_64+0x8/0x18) from [<c003b864>]
>> (__clocksource_updatefreq_scale+0x30/0x104)
>> [    0.000000] [<c003b864>]
>> (__clocksource_updatefreq_scale+0x30/0x104) from [<c003b944>]
>> (__clocksource_register_scale+0xc/0x48)
>> [    0.000000] [<c003b944>] (__clocksource_register_scale+0xc/0x48)
>> from [<c0360810>] (at91sam926x_pit_init+0x174/0x234)
>> [    0.000000] [<c0360810>] (at91sam926x_pit_init+0x174/0x234) from
>> [<c035ca4c>] (time_init+0x1c/0x24)
>> [    0.000000] [<c035ca4c>] (time_init+0x1c/0x24) from [<c035a650>]
>> (start_kernel+0x19c/0x2f4)
>> [    0.000000] [<c035a650>] (start_kernel+0x19c/0x2f4) from
>> [<20008040>] (0x20008040)
>> [    0.000000] Division by zero in kernel.
>> [    0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G        W
>> 3.11.0-rc2-next-20130725+ #61
>> [    0.000000] [<c000ca18>] (unwind_backtrace+0x0/0xe0) from
>> [<c000b0f0>] (show_stack+0x10/0x14)
>> [    0.000000] [<c000b0f0>] (show_stack+0x10/0x14) from [<c013f0a0>]
>> (Ldiv0_64+0x8/0x18)
>> [    0.000000] [<c013f0a0>] (Ldiv0_64+0x8/0x18) from [<c003b76c>]
>> (clocks_calc_mult_shift+0x70/0xa4)
>> [    0.000000] [<c003b76c>] (clocks_calc_mult_shift+0x70/0xa4) from
>> [<c003b8e4>] (__clocksource_updatefreq_scale+0xb0/0x104)
>> [    0.000000] [<c003b8e4>]
>> (__clocksource_updatefreq_scale+0xb0/0x104) from [<c003b944>]
>> (__clocksource_register_scale+0xc/0x48)
>> [    0.000000] [<c003b944>] (__clocksource_register_scale+0xc/0x48)
>> from [<c0360810>] (at91sam926x_pit_init+0x174/0x234)
>> [    0.000000] [<c0360810>] (at91sam926x_pit_init+0x174/0x234) from
>> [<c035ca4c>] (time_init+0x1c/0x24)
>> [    0.000000] [<c035ca4c>] (time_init+0x1c/0x24) from [<c035a650>]
>> (start_kernel+0x19c/0x2f4)
>> [    0.000000] [<c035a650>] (start_kernel+0x19c/0x2f4) from
>> [<20008040>] (0x20008040)
>> [...]
>>
>> Best regards,
>> Richard
> Hi Richard,
>
> First, I'd like to thank you for your tests.
>
> Regarding your problem, it seems that mck rate is calculated as 0, which
> is either a bug in recalc_rate callback
> of master clock driver or a bug in master clock parent clk (no parent
> found or bug in the current parent clk recalc_rate function).
>
> I checked the dts[i] files and I found a missing clock-frequency
> property for main clock of some
> at91sam9x5 boards (those including at91sam9x5cm.dtsi).
>
> You'll find a patch adding this property in attachments.
> Tell me if this works for you. If not I'll make a patch adding pr_info
> to trace the bug.
>
> Anyway, it should work without this property (main clock rate can be
> computed using slow clock rate and MCFR register).
> I will investigate this bug...
I found 2 bugs:
1) the main frequency ready test in recalc_rate function is wrong
2) the common clk framework uses the first match for dt clk registration
    and main clk has this compatible property:
    compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
    As a result the main clk is always bound to the fixed-clock driver
    which set the clock frequency to 0 if 'clock-frequency' property is
    missing.

These bugs will be fixed in next version.
Tell me if you want need thesse patches for testing purpose.
>
> Best Regards,
> Boris
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



From robherring2 at gmail.com  Fri Jul 26 12:36:13 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 26 Jul 2013 11:36:13 -0500
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <CAOesGMhEr3DiFm5uSgoHPFUMY4jWu4HkeTU2UmOGj=dS75Vk+g@mail.gmail.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy> <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy> <20130726141016.GF9858@sirena.org.uk>
 <CAOesGMhEr3DiFm5uSgoHPFUMY4jWu4HkeTU2UmOGj=dS75Vk+g@mail.gmail.com>
Message-ID: <51F2A57D.1090704@gmail.com>

On 07/26/2013 10:49 AM, Olof Johansson wrote:
> On Fri, Jul 26, 2013 at 7:10 AM, Mark Brown <broonie at kernel.org> wrote:
>> On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
>>
>>> Unless I totally misunderstood, the thread is talking about letting
>>> established bindings change with each new kernel version.  I am
>>> opposed to that.
>>
>> No, nobody is really saying that is a particularly good idea.  There is
>> some debate about how we work out what an established binding is but
>> there's no serious suggestion that we don't want stable bindings.
> 
> Yes, what Mark said -- _today_ all bindings are subject to change and
> can be changed in lockstep with the kernel. This has been necessary as
> part of development to sort out all of the various bootstrapping
> issues across platforms.

This is absolutely not true on a global basis. Any binding used on
powerpc or sparc is not subject to change. Furthermore, there are ARM
platforms such as highbank where the bindings are expected to be stable.
That's not saying they don't change (new properties for SATA just
today), but they only change in a backwards compatible way.

Rob

> 
> What we're talking about is to end that mode of operation, and moving
> over to locking in bindings. Device tree contents, as mentioned
> elsewhere, might still be changed just like code is -- bugs are fixed,
> etc. But it's time to start locking down the bindings, in particular
> no longer change the established ones.
> 
> Long term, final goal is likely to be close to what Russell is saying
> -- nothing should go into the kernel tree unless the binding is in a
> fully stable state. However, we have a transitional period between now
> and then, and even when we're at the final state there will be need to
> have some sort of sandbox for development and test of future bindings.
> Dealing with all that, as well as the actual process for locking in
> bindings, is what needs to be sorted out.
> 
> I think we're all in agreement that bindings that change over time are
> nothing but pain, but we're arguing that in circles anyway.
> 
> 
> -Olof
> 



From b.brezillon at overkiz.com  Fri Jul 26 12:41:29 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Fri, 26 Jul 2013 18:41:29 +0200
Subject: [PATCH v2 02/42] ARM: at91: add PMC main clock
In-Reply-To: <1374068404-13654-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <1374068404-13654-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <51F2A6B9.1010401@overkiz.com>

On 17/07/2013 15:40, Boris BREZILLON wrote:
> This is the at91 main oscillator clock implementation using common
> clk framework.
>
> If rate is not provided during clock registraction it is computed using
> the slow clock (main clk parent in this case) rate and the MCFR register.
>
> Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
> ---
>   drivers/clk/at91/Makefile   |    5 ++
>   drivers/clk/at91/clk-main.c |  106 +++++++++++++++++++++++++++++++++++++++++++
>   include/linux/clk/at91.h    |   10 ++++
>   3 files changed, 121 insertions(+)
>   create mode 100644 drivers/clk/at91/Makefile
>   create mode 100644 drivers/clk/at91/clk-main.c
>
> diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
> new file mode 100644
> index 0000000..42c084e
> --- /dev/null
> +++ b/drivers/clk/at91/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for at91 specific clk
> +#
> +
> +obj-y += clk-main.o
> diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
> new file mode 100644
> index 0000000..738fa39
> --- /dev/null
> +++ b/drivers/clk/at91/clk-main.c
> @@ -0,0 +1,106 @@
> +/*
> + * drivers/clk/at91/clk-main.c
> + *
> + *  Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
> + *
> + * This mainram is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk/at91.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/io.h>
> +
> +#define to_clk_main(hw) container_of(hw, struct clk_main, hw)
> +struct clk_main {
> +	struct clk_hw hw;
> +	unsigned long rate;
> +};
> +
> +static unsigned long clk_main_recalc_rate(struct clk_hw *hw,
> +					  unsigned long parent_rate)
> +{
> +	u32 tmp;
> +	struct clk_main *clkmain = to_clk_main(hw);
> +	if (clkmain->rate)
> +		return clkmain->rate;
> +	while ((tmp = at91_pmc_read(AT91_CKGR_MCFR)) & AT91_PMC_MAINRDY)
> +		;
wrong test here, should be:

while (!((tmp = at91_pmc_read(AT91_CKGR_MCFR)) & AT91_PMC_MAINRDY))
	;


> +	tmp &= AT91_PMC_MAINF;
> +	clkmain->rate = (tmp * parent_rate) / 16;
> +	return clkmain->rate;
> +}
> +
> +static const struct clk_ops main_ops = {
> +	.recalc_rate = clk_main_recalc_rate,
> +};
> +
> +struct clk * __init
> +at91_clk_register_main(const char *name,
> +		       const char *parent_name,
> +		       unsigned long rate)
> +{
> +	struct clk_main *clkmain;
> +	struct clk *clk = NULL;
> +	struct clk_init_data init;
> +
> +	if (!rate && !parent_name)
> +		return ERR_PTR(-EINVAL);
> +
> +	clkmain = kzalloc(sizeof(*clkmain), GFP_KERNEL);
> +	if (!clkmain)
> +		return ERR_PTR(-ENOMEM);
> +
> +	init.name = name;
> +	init.ops = &main_ops;
> +	init.parent_names = parent_name ? &parent_name : NULL;
> +	init.num_parents = parent_name ? 1 : 0;
> +	init.flags = parent_name ? 0 : CLK_IS_ROOT;
> +
> +	clkmain->hw.init = &init;
> +	clkmain->rate = rate;
> +
> +	clk = clk_register(NULL, &clkmain->hw);
> +
> +	if (IS_ERR(clk))
> +		kfree(clkmain);
> +
> +	return clk;
> +}
> +
> +
> +
> +#if defined(CONFIG_OF)
> +static void __init
> +of_at91_clk_main_setup(struct device_node *np)
> +{
> +	struct clk *clk;
> +	const char *parent_name;
> +	const char *name = np->name;
> +	u32 rate = 0;
> +
> +	parent_name = of_clk_get_parent_name(np, 0);
> +	of_property_read_string(np, "clock-output-names", &name);
> +	of_property_read_u32(np, "clock-frequency", &rate);
> +
> +	clk = at91_clk_register_main(name, parent_name, rate);
> +
> +	if (!IS_ERR(clk))
> +		return;
> +
> +	of_clk_add_provider(np, of_clk_src_simple_get, clk);
> +}
> +
> +static void __init of_at91rm9200_clk_main_setup(struct device_node *np)
> +{
> +	of_at91_clk_main_setup(np);
> +}
> +CLK_OF_DECLARE(at91rm9200_clk_main, "atmel,at91rm9200-clk-main",
> +	       of_at91rm9200_clk_main_setup);
> +#endif
> diff --git a/include/linux/clk/at91.h b/include/linux/clk/at91.h
> index 0ce9586..8e83942 100644
> --- a/include/linux/clk/at91.h
> +++ b/include/linux/clk/at91.h
> @@ -16,6 +16,8 @@
>   #ifndef AT91_PMC_H
>   #define AT91_PMC_H
>   
> +#include <linux/clk-provider.h>
> +
>   #ifndef __ASSEMBLY__
>   extern void __iomem *at91_pmc_base;
>   
> @@ -187,4 +189,12 @@ extern void __iomem *at91_pmc_base;
>   #define			AT91_PMC_PCR_DIV8	0x3			/* Peripheral clock is MCK/8 */
>   #define		AT91_PMC_PCR_EN		(0x1  <<  28)		/* Enable */
>   
> +
> +
> +
> +struct clk * __init
> +at91_clk_register_main(const char *name,
> +		       const char *parent_name,
> +		       unsigned long rate);
> +
>   #endif



From nico at fluxnic.net  Fri Jul 26 12:44:23 2013
From: nico at fluxnic.net (Nicolas Pitre)
Date: Fri, 26 Jul 2013 12:44:23 -0400 (EDT)
Subject: Appended DTB files for multi-machine kernels
In-Reply-To: <51F2A014.7000209@gmail.com>
References: <51D5A938.30607@gmail.com>
 <alpine.LFD.2.03.1307041322070.18597@syhkavp.arg> <51F2A014.7000209@gmail.com>
Message-ID: <alpine.LFD.2.03.1307261233330.15022@syhkavp.arg>

On Fri, 26 Jul 2013, Daniel Mack wrote:

> On 04.07.2013 19:28, Nicolas Pitre wrote:
> > On Thu, 4 Jul 2013, Daniel Mack wrote:
> >> In short, devices that have been deployed in quantities come in three
> >> hardware variants, which all boot with a unique machine-id. We ship
> >> kernel images that have board support for all three machine types, and
> >> do minor fixups to platform data of some drivers at runtime, depending
> >> on the board revision number (passed in via ATAGs).
> >>
> 
> > What you describe above more or less fits the definition of what I 
> > called the "impedance matcher".  However it doesn't need to be part of 
> > the kernel at all.  But you should make it into a separate binary.
> > 
> > Please have a look at the bottom of this post for a more comprehensive 
> > description: http://article.gmane.org/gmane.linux.ports.arm.kernel/242929
> 
> FWIW, I gave that approach a try today for a PXA based hardware
> platform, and in fact it seems to work very well. Thanks again for
> sharing the idea.
> 
> In case anyone is interested, the repository is here:
> 
>   https://github.com/zonque/pxa-impedance-matcher
> 
> As the README says, it's completely specific to my use case, but maybe
> anyone can use the code base to spin a different version for a different
> board.

That looks nice, but I'd suggest going a step further if possible.

If you could load the kernel zImage independently with a separate load 
command in u-boot, then people could update their kernel only without 
having to relink with this shim.  The load address for that zImage can 
be totally arbitrary as longas it is known to be the same from within 
this shim and in the u-boot script.

Also, more related to your code, you apparently link and load it to run 
at 0xa0008000.  This is also where the zImage code is going to 
decompress the final kernel image after it has relocated itself.  I'm 
afraid the DTBs you point to might be overwritten at that point since 
zImage is not aware of them (in fact I'm surprized this works at all as 
you say).  If I were you I'd use 0xa1000000 instead (and make sure the 
initrd is out of the way as well if you have one).


Nicolas


From will.deacon at arm.com  Fri Jul 26 12:53:11 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 26 Jul 2013 17:53:11 +0100
Subject: [PATCH v3 1/3] ARM: BCM5301X: initial support for the
 BCM5301X/BCM470X SoCs with ARM CPU
In-Reply-To: <51F28A20.7060105@hauke-m.de>
References: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
 <1374792135-30343-2-git-send-email-hauke@hauke-m.de>
 <20130726085542.GA17886@mudshark.cambridge.arm.com>
 <51F28A20.7060105@hauke-m.de>
Message-ID: <20130726165311.GH17886@mudshark.cambridge.arm.com>

On Fri, Jul 26, 2013 at 03:39:28PM +0100, Hauke Mehrtens wrote:
> On 07/26/2013 10:55 AM, Will Deacon wrote:
> >> +static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
> >> +				 struct pt_regs *regs)
> >> +{
> >> +	/*
> >> +	 * These happen for no good reason, possibly left over from CFE
> >> +	 */
> >> +	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
> >> +		addr, fsr);
> >> +
> >> +	/* Returning non-zero causes fault display and panic */
> >> +	return 0;
> >> +}
> >> +
> >> +static void __init bcm5301x_init_early(void)
> >> +{
> >> +	/* Install our hook */
> >> +	hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, 0,
> >> +			"imprecise external abort");
> >> +}
> > 
> > Surely you can't be serious?
> > 
> > At least, we need a pretty good explanation of what *exactly* is causing
> > these spurious aborts before we start ignoring them unconditionally like
> > this. You're effectively masking an extremely serious error indicator with
> > this change.
> 
> This fault occurs once every boot sometime early in the boot process,
> but the actual time this happens varies randomly.

Well that's interesting in itself. It sounds like we don't know *for sure*
whether the abort is triggered by Linux. Since the abort is imprecise, the
timing will vary.

> Sadly I do not understand this completely, and I copied this from the
> vendor BSP with the corresponding code documentation. They think CFE
> (Common Firmware Environment, the bootloader used on these devices), did
> something wrong, but I do not have the actual source of CFE and I do not
> have the chip documentation. This occurs just once as far as I have seen
> this, we could just catch the first one. Changing the boot loader is
> also not an option, because I want to use this code on devices already
> shipped to costumers and I do not have access to the boot loader source
> code.

Can somebody with hardware debug capability help you out (I notice csd is on
CC...)? We can have the hack if we know why it's needed, but as it stands it
could easily be hiding other problems.

> Do you know what this fault normally indicates?

Usually that something went horribly wrong in the memory subsystem at some
point in the past (i.e. invalid requests stuck on the bus, to which nobody
replied). You can sometimes get these if you try to probe for
non-discoverable devices by poking around in the physical memory map.

Will


From Sudeep.KarkadaNagesha at arm.com  Fri Jul 26 13:01:37 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Fri, 26 Jul 2013 18:01:37 +0100
Subject: [PATCH v3 07/16] of/device: add helper to get cpu device node
 from logical cpu index
In-Reply-To: <1374492747-13879-8-git-send-email-Sudeep.KarkadaNagesha@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-8-git-send-email-Sudeep.KarkadaNagesha@arm.com>
Message-ID: <51F2AB71.3070102@arm.com>

Rob,

On 22/07/13 12:32, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>
> Multiple drivers need to get the cpu device node from the cpu logical
> index and then access the of_node.
>
> This patch adds helper function to fetch the device node directly.
>
> Cc: Rob Herring <rob.herring at calxeda.com>
> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>

If you have no objections with this patch, can I add your ACK ?

Regards,
Sudeep

> ---
>  include/linux/of_device.h | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
>
> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
> index 9d27475..82ce324 100644
> --- a/include/linux/of_device.h
> +++ b/include/linux/of_device.h
> @@ -1,6 +1,7 @@
>  #ifndef _LINUX_OF_DEVICE_H
>  #define _LINUX_OF_DEVICE_H
>
> +#include <linux/cpu.h>
>  #include <linux/platform_device.h>
>  #include <linux/of_platform.h> /* temporary until merge */
>
> @@ -43,6 +44,15 @@ static inline void of_device_node_put(struct device *dev)
>       of_node_put(dev->of_node);
>  }
>
> +static inline struct device_node *of_cpu_device_node_get(int cpu)
> +{
> +     struct device *cpu_dev;
> +     cpu_dev = get_cpu_device(cpu);
> +     if (!cpu_dev)
> +             return NULL;
> +     return of_node_get(cpu_dev->of_node);
> +}
> +
>  #else /* CONFIG_OF */
>
>  static inline int of_driver_match_device(struct device *dev,
> @@ -67,6 +77,11 @@ static inline const struct of_device_id *of_match_device(
>  {
>       return NULL;
>  }
> +
> +static inline struct device_node *of_cpu_device_node_get(int cpu)
> +{
> +     return NULL;
> +}
>  #endif /* CONFIG_OF */
>
>  #endif /* _LINUX_OF_DEVICE_H */
>


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.



From lorenzo.pieralisi at arm.com  Fri Jul 26 13:04:02 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 26 Jul 2013 18:04:02 +0100
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value to
 index into save array
In-Reply-To: <alpine.LFD.2.03.1307261139370.15022@syhkavp.arg>
References: <alpine.LFD.2.03.1307251203550.15022@syhkavp.arg>
 <20130726113110.GB28084@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307261032330.15022@syhkavp.arg>
 <20130726153440.GD2282@localhost.localdomain>
 <alpine.LFD.2.03.1307261139370.15022@syhkavp.arg>
Message-ID: <20130726170402.GF28084@e102568-lin.cambridge.arm.com>

On Fri, Jul 26, 2013 at 04:43:34PM +0100, Nicolas Pitre wrote:
> On Fri, 26 Jul 2013, Dave Martin wrote:
> 
> > On Fri, Jul 26, 2013 at 10:41:38AM -0400, Nicolas Pitre wrote:
> > > On Fri, 26 Jul 2013, Lorenzo Pieralisi wrote:
> > > 
> > > > On Thu, Jul 25, 2013 at 05:06:51PM +0100, Nicolas Pitre wrote:
> > > > > On Thu, 25 Jul 2013, Dave Martin wrote:
> > > > > 
> > > > > > On Wed, Jul 24, 2013 at 02:55:00PM -0400, Nicolas Pitre wrote:
> > > > > > > On Wed, 24 Jul 2013, Dave Martin wrote:
> > > > > > > 
> > > > > > > > But this patch commits us to requiring that on the suspend path 
> > > > > > > > specifically -- I think that ought to be mentioned somewhere. A 
> > > > > > > > comment in the preamble for __cpu_suspend would be enough, I think.
> > > > > > > 
> > > > > > > What comment would you suggest?  I want to make sure the possible 
> > > > > > > confusion you see is properly addressed.
> > > > > > 
> > > > > > I think we just need to state that the value of
> > > > > > cpu_logical_map(smp_processor_id()) must be the MPIDR of the physical
> > > > > > CPU the suspending logical CPU will resume on.  Consequently, if doing a
> > > > > > migration, cpu_logical_map() must be updated appropriately somewhere
> > > > > > between cpu_pm_enter() and cpu_suspend().
> > > > > 
> > > > > Excellent.  I've amended the patch with this:
> > > > > 
> > > > > diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
> > > > > index 2835d35234..caf938db62 100644
> > > > > --- a/arch/arm/kernel/suspend.c
> > > > > +++ b/arch/arm/kernel/suspend.c
> > > > > @@ -17,6 +17,11 @@ extern void cpu_resume_mmu(void);
> > > > >  /*
> > > > >   * Hide the first two arguments to __cpu_suspend - these are an implementation
> > > > >   * detail which platform code shouldn't have to know about.
> > > > > + *
> > > > > + * On SMP systems, the value of cpu_logical_map(smp_processor_id()) must be
> > > > > + * the MPIDR of the physical CPU the suspending logical CPU will resume on.
> > > > > + * Consequently, if doing a physical CPU migration, cpu_logical_map() must be
> > > > > + * updated appropriately somewhere between cpu_pm_enter() and cpu_suspend().
> > > > >   */
> > > > >  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> > > > >  {
> > > > > 
> > > > > I've put it against cpu_suspend() rather than __cpu_suspend(() as this 
> > > > > is what users should care about.
> > > > > 
> > > > > ACK?
> > > > 
> > > > We need this patch to allow IKS to store a cpu context at a specific
> > > > index, let's be honest. It is a moot point and I am not very happy
> > > > about changing this code for a very specific usage, but the way code is
> > > > implemented makes the change acceptable. I really do not think we should
> > > > write guidelines on how cpu_suspend users have to change cpu_logical_map
> > > > though, that's not needed apart from IKS and that should be limited to IKS
> > > > code only.
> > > > 
> > > > Again, that's just my opinion, but cpu_suspend API must be kept as it is
> > > > and we should not encourage people to use it in creative ways.
> > > 
> > > I tend to agree, but I'm now stuck between two conflicting requests.
> > 
> > Would it make sense to keep the same API to cpu_suspend(), but make it
> > a wrapper for another function which has the MPIDR argument?  Then people
> > calling cpu_suspend() continue as normal.  Only IKS needs to know about
> > the underlying MPIDR handling when calling this.
> 
> The fact is that the switcher _does_ need to swizzle the cpu_logical_map 
> anyway before suspending.  Hence really there is no point creating extra
> wrappers for this.
> 
> So Lorenzo's suggestion to simply not advertise this too much for people 
> to not get too creative is probably the best compromize IMHO.

We could add a function cpu_migrate, almost identical to cpu_suspend
but accepting an MPIDR parameter as Dave said. cpu_suspend would read its
own MPIDR using read_cpuid_mpidr() and pass it to __cpu_suspend, keeping the
current behaviour unchanged (well, MPIDR is now read in cpu_suspend instead
of __cpu_suspend).
cpu_migrate will pass the mpidr to __cpu_suspend, to say "migrate this CPU to
the CPU identified by this MPIDR"; IKS can swizzle cpu_logical_map internally.

Looks like lot of churn though, probably the intent is clearer and closer to
PSCI. Just an idea, probably useless.

I will apply and test the patch as it is first thing next week.

Lorenzo



From sboyd at codeaurora.org  Fri Jul 26 13:05:21 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 26 Jul 2013 10:05:21 -0700
Subject: [PATCH 3/4] msm_serial: Make baud_code detection more dynamic
In-Reply-To: <CAJAp7Og1jwyAn0sGbb_1Bk5_fvBWa1AuDNsRV1b17S0Tijk9kg@mail.gmail.com>
References: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
 <1374691051-28544-4-git-send-email-sboyd@codeaurora.org>
 <CAJAp7Og1jwyAn0sGbb_1Bk5_fvBWa1AuDNsRV1b17S0Tijk9kg@mail.gmail.com>
Message-ID: <20130726170521.GA11922@codeaurora.org>

On 07/25, Bjorn Andersson wrote:
> On Wed, Jul 24, 2013 at 10:37 AM, Stephen Boyd <sboyd at codeaurora.org> wrote:
> > [snip]
> > +       unsigned int i, divisor;
> > +       const struct msm_baud_map *entry;
> > +       static const struct msm_baud_map table[] = {
> > +               { 1536, 0x00,  1 },
> > +               {  768, 0x11,  1 },
> > +               {  384, 0x22,  1 },
> > +               {  192, 0x33,  1 },
> > +               {   96, 0x44,  1 },
> > +               {   48, 0x55,  1 },
> > +               {   32, 0x66,  1 },
> > +               {   24, 0x77,  1 },
> > +               {   16, 0x88,  1 },
> > +               {   12, 0x99,  6 },
> > +               {    8, 0xaa,  6 },
> > +               {    6, 0xbb,  6 },
> > +               {    4, 0xcc,  6 },
> > +               {    3, 0xdd,  8 },
> > +               {    2, 0xee, 16 },
> > +               {    1, 0xff, 31 },
> > +       };
> > +
> > +       divisor = uart_get_divisor(port, baud);
> > +
> > +       for (i = 0, entry = table; i < ARRAY_SIZE(table); i++, entry++)
> > +               if (entry->divisor <= divisor)
> > +                       break;
> > +
> > +       return entry; /* Default to smallest divider */
> 
> Shouldn't matter, but you're not defaulting to the smallest divider.
> Your are defaulting to an undefined value, as `entry` will be off the
> array once i == ARRAY_SIZE().
> 

Yes because the if condition will always be true. Perhaps that's
too confusing? We could add a subtraction by 1 to make it more
obvious.

 for (i = 0; entry = table; i < ARRAY_SIZE(table) - 1; i++, entry++)
 	if (entry->divisor <= divisor)
		break;

 return entry; /* Default to smallest divider*/

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From swarren at wwwdotorg.org  Fri Jul 26 13:05:23 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 11:05:23 -0600
Subject: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
In-Reply-To: <1374817287-27952-1-git-send-email-vijay.kilari@gmail.com>
References: <1374817287-27952-1-git-send-email-vijay.kilari@gmail.com>
Message-ID: <51F2AC53.3070607@wwwdotorg.org>

On 07/25/2013 11:41 PM, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar at caviumnetworks.com>
> 
> In case of normal kexec kernel load, all cpu's are offlined
> before calling machine_kexec() under kernel_kexec() function.

I'm not sure that's true, unless perhaps you have CONFIG_KEXEC_JUMP enabled?

> But in case crash panic cpus are relaxed in
> machine_crash_nonpanic_core() SMP function but not offlined.
> 
> When crash kernel is loaded with kexec and on panic trigger
> machine_kexec() checks for number of cpus online.
> If more than one cpu is online machine_kexec() fails to load
> with below error
> 
> kexec: error: multiple CPUs still online
> 
> In machine_crash_nonpanic_core() SMP function, offline CPU
> before cpu_relax

> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c

> @@ -73,6 +73,7 @@ void machine_crash_nonpanic_core(void *unused)
>  	crash_save_cpu(&regs, smp_processor_id());
>  	flush_cache_all();
>  
> +	set_cpu_online(smp_processor_id(), false);

I'm not familiar with that API, but it looks like it's just setting the
*current* CPU offline. That sounds problematic for two reasons:

1) Setting the current CPU offline sounds like a bad idea; after all,
code is still running on it. Presumably you want to offline all other CPUs.

2) On a dual-CPU system, I guess this will leave a single CPU marked
online, and hence satisfy the test in machine_kexec(). However, on a
quad-core system, won't this just reduce the online CPU count from 4 to
3 and hence the test in machine_kexec() will still fail?

Can't you call disable_nonboot_cpus() from machine_crash_nonpanic_core()
just like machine_shutdown() does?


From hartleys at visionengravers.com  Fri Jul 26 13:04:10 2013
From: hartleys at visionengravers.com (H Hartley Sweeten)
Date: Fri, 26 Jul 2013 12:04:10 -0500
Subject: [PATCH] ARM: debug: use generic option for ep93xx PL10x debug port
In-Reply-To: <201307171048.17430.hartleys@visionengravers.com>
References: <201307171048.17430.hartleys@visionengravers.com>
Message-ID: <ADE657CA350FB648AAC2C43247A983F0021DAC5C2138@AUSP01VMBX24.collaborationhost.net>

Russell,

Ping... Any comments on this?

Thanks,
Hartley

-----Original Message-----
From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of H Hartley Sweeten
Sent: Wednesday, July 17, 2013 10:48 AM
To: ARM Kernel
Cc: Russell King; Ryan Mallon
Subject: [PATCH] ARM: debug: use generic option for ep93xx PL10x debug port

The generic option DEBUG_LL_UART_PL01X is now used to select the UART
type for the kernel low-level debugging on the ep93xx platform. This
enables two config options to provide the physical and virtual base
address of the debug UART.

Use the generic options instead of providing platform specific options
to select the debug UART.

UART1 is selected with:  DEBUG_UART_PHYS = 0x808c0000
                         DEBUG_UART_VIRT = 0xfedc0000

UART2 is selected with:  DEBUG_UART_PHYS = 0x808d0000
                         DEBUG_UART_VIRT = 0xfedd0000

UART3 is selected with:  DEBUG_UART_PHYS = 0x808e0000
                         DEBUG_UART_VIRT = 0xfede0000

The selected UART must already be initialized by the bootloader. If it
isn't setup nothing will appear (which might be desired).

Signed-off-by: H Hartley Sweeten <hsweeten at visionengravers.com>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Cc: Ryan Mallon <rmallon at gmail.com>
---
This applies on top of Russell King's "Clean up the debugging support".

 arch/arm/mach-ep93xx/Kconfig                   | 14 --------------
 arch/arm/mach-ep93xx/include/mach/uncompress.h | 14 ++------------
 2 files changed, 2 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig
index fe3c1fa..93e54fd 100644
--- a/arch/arm/mach-ep93xx/Kconfig
+++ b/arch/arm/mach-ep93xx/Kconfig
@@ -194,20 +194,6 @@ config MACH_VISION_EP9307
 	  Say 'Y' here if you want your kernel to support the
 	  Vision Engraving Systems EP9307 SoM.
 
-choice
-	prompt "Select a UART for early kernel messages"
-
-config EP93XX_EARLY_UART1
-	bool "UART1"
-
-config EP93XX_EARLY_UART2
-	bool "UART2"
-
-config EP93XX_EARLY_UART3
-	bool "UART3"
-
-endchoice
-
 endmenu
 
 endif
diff --git a/arch/arm/mach-ep93xx/include/mach/uncompress.h b/arch/arm/mach-ep93xx/include/mach/uncompress.h
index b5cc77d..03c42e5 100644
--- a/arch/arm/mach-ep93xx/include/mach/uncompress.h
+++ b/arch/arm/mach-ep93xx/include/mach/uncompress.h
@@ -31,18 +31,8 @@ static void __raw_writel(unsigned int value, unsigned int ptr)
 	*((volatile unsigned int *)ptr) = value;
 }
 
-#if defined(CONFIG_EP93XX_EARLY_UART1)
-#define UART_BASE		EP93XX_UART1_PHYS_BASE
-#elif defined(CONFIG_EP93XX_EARLY_UART2)
-#define UART_BASE		EP93XX_UART2_PHYS_BASE
-#elif defined(CONFIG_EP93XX_EARLY_UART3)
-#define UART_BASE		EP93XX_UART3_PHYS_BASE
-#else
-#define UART_BASE		EP93XX_UART1_PHYS_BASE
-#endif
-
-#define PHYS_UART_DATA		(UART_BASE + 0x00)
-#define PHYS_UART_FLAG		(UART_BASE + 0x18)
+#define PHYS_UART_DATA		(CONFIG_DEBUG_UART_PHYS + 0x00)
+#define PHYS_UART_FLAG		(CONFIG_DEBUG_UART_PHYS + 0x18)
 #define UART_FLAG_TXFF		0x20
 
 static inline void putc(int c)
-- 
1.8.3.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From swarren at wwwdotorg.org  Fri Jul 26 13:08:07 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 11:08:07 -0600
Subject: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
In-Reply-To: <20130726104908.GC17886@mudshark.cambridge.arm.com>
References: <1374817287-27952-1-git-send-email-vijay.kilari@gmail.com>
 <20130726104908.GC17886@mudshark.cambridge.arm.com>
Message-ID: <51F2ACF7.9000008@wwwdotorg.org>

On 07/26/2013 04:49 AM, Will Deacon wrote:
> [Adding Stephen Warren since he has been working in this area]
> 
> On Fri, Jul 26, 2013 at 06:41:27AM +0100, vijay.kilari at gmail.com wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar at caviumnetworks.com>
>>
>> In case of normal kexec kernel load, all cpu's are offlined
>> before calling machine_kexec() under kernel_kexec() function.
>> But in case crash panic cpus are relaxed in
>> machine_crash_nonpanic_core() SMP function but not offlined.
>>
>> When crash kernel is loaded with kexec and on panic trigger
>> machine_kexec() checks for number of cpus online.
>> If more than one cpu is online machine_kexec() fails to load
>> with below error
>>
>> kexec: error: multiple CPUs still online
>>
>> In machine_crash_nonpanic_core() SMP function, offline CPU
>> before cpu_relax

>> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c

>> @@ -73,6 +73,7 @@ void machine_crash_nonpanic_core(void *unused)
>>  	crash_save_cpu(&regs, smp_processor_id());
>>  	flush_cache_all();
>>  
>> +	set_cpu_online(smp_processor_id(), false);
>>  	atomic_dec(&waiting_for_crash_ipi);
>>  	while (1)
>>  		cpu_relax();
> 
> Ok, I guess this will work since the new kernel is loaded somewhere higher
> in memory and the crashed kernel will stick around, so the non-crashing CPUs
> can sit around spinning.

Does a kernel that's used as the crash kernel guarantee:

* Never to re-use the memory that was used by the previous kernel, so
that the spin loop code/data won't be corrupted, ever, no matter how
long the crash recovery kernel runs.

* Not use SMP, so there's never a need to re-activate the non-boot CPUs,
which might not work if they aren't truly disabled but rather just
running a pin loop?


From linux at arm.linux.org.uk  Fri Jul 26 13:08:56 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 18:08:56 +0100
Subject: [PATCH] ARM: debug: use generic option for ep93xx PL10x debug port
In-Reply-To: <ADE657CA350FB648AAC2C43247A983F0021DAC5C2138@AUSP01VMBX24.collaborationhost.net>
References: <201307171048.17430.hartleys@visionengravers.com>
 <ADE657CA350FB648AAC2C43247A983F0021DAC5C2138@AUSP01VMBX24.collaborationhost.net>
Message-ID: <20130726170856.GV24642@n2100.arm.linux.org.uk>

On Fri, Jul 26, 2013 at 12:04:10PM -0500, H Hartley Sweeten wrote:
> Russell,
> 
> Ping... Any comments on this?

I did reply on the 22nd, suggesting it gets put in the patch system.

> -----Original Message-----
> From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of H Hartley Sweeten
> Sent: Wednesday, July 17, 2013 10:48 AM
> To: ARM Kernel
> Cc: Russell King; Ryan Mallon
> Subject: [PATCH] ARM: debug: use generic option for ep93xx PL10x debug port
> 
> The generic option DEBUG_LL_UART_PL01X is now used to select the UART
> type for the kernel low-level debugging on the ep93xx platform. This
> enables two config options to provide the physical and virtual base
> address of the debug UART.
> 
> Use the generic options instead of providing platform specific options
> to select the debug UART.
> 
> UART1 is selected with:  DEBUG_UART_PHYS = 0x808c0000
>                          DEBUG_UART_VIRT = 0xfedc0000
> 
> UART2 is selected with:  DEBUG_UART_PHYS = 0x808d0000
>                          DEBUG_UART_VIRT = 0xfedd0000
> 
> UART3 is selected with:  DEBUG_UART_PHYS = 0x808e0000
>                          DEBUG_UART_VIRT = 0xfede0000
> 
> The selected UART must already be initialized by the bootloader. If it
> isn't setup nothing will appear (which might be desired).
> 
> Signed-off-by: H Hartley Sweeten <hsweeten at visionengravers.com>
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> Cc: Ryan Mallon <rmallon at gmail.com>
> ---
> This applies on top of Russell King's "Clean up the debugging support".
> 
>  arch/arm/mach-ep93xx/Kconfig                   | 14 --------------
>  arch/arm/mach-ep93xx/include/mach/uncompress.h | 14 ++------------
>  2 files changed, 2 insertions(+), 26 deletions(-)
> 
> diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig
> index fe3c1fa..93e54fd 100644
> --- a/arch/arm/mach-ep93xx/Kconfig
> +++ b/arch/arm/mach-ep93xx/Kconfig
> @@ -194,20 +194,6 @@ config MACH_VISION_EP9307
>  	  Say 'Y' here if you want your kernel to support the
>  	  Vision Engraving Systems EP9307 SoM.
>  
> -choice
> -	prompt "Select a UART for early kernel messages"
> -
> -config EP93XX_EARLY_UART1
> -	bool "UART1"
> -
> -config EP93XX_EARLY_UART2
> -	bool "UART2"
> -
> -config EP93XX_EARLY_UART3
> -	bool "UART3"
> -
> -endchoice
> -
>  endmenu
>  
>  endif
> diff --git a/arch/arm/mach-ep93xx/include/mach/uncompress.h b/arch/arm/mach-ep93xx/include/mach/uncompress.h
> index b5cc77d..03c42e5 100644
> --- a/arch/arm/mach-ep93xx/include/mach/uncompress.h
> +++ b/arch/arm/mach-ep93xx/include/mach/uncompress.h
> @@ -31,18 +31,8 @@ static void __raw_writel(unsigned int value, unsigned int ptr)
>  	*((volatile unsigned int *)ptr) = value;
>  }
>  
> -#if defined(CONFIG_EP93XX_EARLY_UART1)
> -#define UART_BASE		EP93XX_UART1_PHYS_BASE
> -#elif defined(CONFIG_EP93XX_EARLY_UART2)
> -#define UART_BASE		EP93XX_UART2_PHYS_BASE
> -#elif defined(CONFIG_EP93XX_EARLY_UART3)
> -#define UART_BASE		EP93XX_UART3_PHYS_BASE
> -#else
> -#define UART_BASE		EP93XX_UART1_PHYS_BASE
> -#endif
> -
> -#define PHYS_UART_DATA		(UART_BASE + 0x00)
> -#define PHYS_UART_FLAG		(UART_BASE + 0x18)
> +#define PHYS_UART_DATA		(CONFIG_DEBUG_UART_PHYS + 0x00)
> +#define PHYS_UART_FLAG		(CONFIG_DEBUG_UART_PHYS + 0x18)
>  #define UART_FLAG_TXFF		0x20
>  
>  static inline void putc(int c)
> -- 
> 1.8.3.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From will.deacon at arm.com  Fri Jul 26 13:09:49 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 26 Jul 2013 18:09:49 +0100
Subject: [PATCH 1/1] ARM: atomic64: fix endian-ness in atomic.h
In-Reply-To: <1374856133-2939-2-git-send-email-victor.kamensky@linaro.org>
References: <1374856133-2939-1-git-send-email-victor.kamensky@linaro.org>
 <1374856133-2939-2-git-send-email-victor.kamensky@linaro.org>
Message-ID: <20130726170949.GJ17886@mudshark.cambridge.arm.com>

On Fri, Jul 26, 2013 at 05:28:53PM +0100, Victor Kamensky wrote:
> Fix inline asm for atomic64_xxx functions in arm atomic.h. Instead of
> %H operand specifiers code should use %Q for least significant part
> of the value, and %R for the most significant part of the value. %H
> always returns the higher of the two register numbers, and therefore
> it is not endian neutral. %H should be used with ldrexd and strexd
> instructions.
> 
> Signed-off-by: Victor Kamensky <victor.kamensky at linaro.org>
> ---

Acked-by: Will Deacon <will.deacon at arm.com>

Will


From jason at lakedaemon.net  Fri Jul 26 13:11:53 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 26 Jul 2013 13:11:53 -0400
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <51F29BFE.8000202@broadcom.com>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net>
 <51F29BFE.8000202@broadcom.com>
Message-ID: <20130726171153.GN29916@titan.lakedaemon.net>

Christian,

On Fri, Jul 26, 2013 at 08:55:42AM -0700, Christian Daudt wrote:
> [resend in plain text]
> On 13-07-26 08:29 AM, Jason Cooper wrote:
> >On Fri, Jul 26, 2013 at 04:56:40PM +0200, Domenico Andreoli wrote:
> >>From: Domenico Andreoli<domenico.andreoli at linux.com>
> >>
> >>arch/arm/mach-bcm contains a plurality of Broadcom SoCs, each configured
> >>separately. As a matter of flexibility and maintenance, it needs to be
> >>always included in the build.
> >
> >So if I'm building mach-kirkwood, I _have_ to build Broadcom?  What is
> >the *specific* problem you're encountering that this solves?
> 
>  No it won't, as the Makefile inside mach-bcm will only pull in
> files based on ARCH_ settings. This move is so that a number
> different Broadcom SoCs can co-exist inside the mach-bcm directory.


Why wouldn't this work?

---->8-------
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..97b6aff 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -366,6 +366,12 @@ config ARCH_AT91
 	  This enables support for systems based on Atmel
 	  AT91RM9200 and AT91SAM9* processors.
 
+config ARCH_BCM
+	bool "Broadcom family SoCs"
+	help
+	  This enables support for systems based on the Broadcom
+	  bcm4760 and bcm281XX series SoCs.
+
 config ARCH_CLPS711X
 	bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
 	select ARCH_REQUIRE_GPIOLIB
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index f112895..4b1f9db 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -1,5 +1,9 @@
-config ARCH_BCM
-	bool "Broadcom SoC" if ARCH_MULTI_V7
+if ARCH_BCM
+
+menu "Broadcom SoC Implementations"
+
+config MACH_BCM281XX
+	bool "BCM281XX SoCs" if ARCH_MULTI_V7
 	depends on MMU
 	select ARCH_REQUIRE_GPIOLIB
 	select ARM_ERRATA_754322
@@ -17,3 +21,7 @@ config ARCH_BCM
 	  It currently supports the 'BCM281XX' family, which includes
 	  BCM11130, BCM11140, BCM11351, BCM28145 and
 	  BCM28155 variants.
+
+endmenu
+
+endif
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 6adb6aec..e3f8f27 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -10,6 +10,6 @@
 # of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 # GNU General Public License for more details.
 
-obj-$(CONFIG_ARCH_BCM)		:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
+obj-$(CONFIG_MACH_BCM281XX)	:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_bcm_kona_smc_asm.o	:=-Wa,-march=armv7-a$(plus_sec)


From will.deacon at arm.com  Fri Jul 26 13:11:55 2013
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 26 Jul 2013 18:11:55 +0100
Subject: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
In-Reply-To: <51F2ACF7.9000008@wwwdotorg.org>
References: <1374817287-27952-1-git-send-email-vijay.kilari@gmail.com>
 <20130726104908.GC17886@mudshark.cambridge.arm.com>
 <51F2ACF7.9000008@wwwdotorg.org>
Message-ID: <20130726171155.GK17886@mudshark.cambridge.arm.com>

On Fri, Jul 26, 2013 at 06:08:07PM +0100, Stephen Warren wrote:
> On 07/26/2013 04:49 AM, Will Deacon wrote:
> > [Adding Stephen Warren since he has been working in this area]
> > 
> > On Fri, Jul 26, 2013 at 06:41:27AM +0100, vijay.kilari at gmail.com wrote:
> >> From: Vijaya Kumar K <Vijaya.Kumar at caviumnetworks.com>
> >>
> >> In case of normal kexec kernel load, all cpu's are offlined
> >> before calling machine_kexec() under kernel_kexec() function.
> >> But in case crash panic cpus are relaxed in
> >> machine_crash_nonpanic_core() SMP function but not offlined.
> >>
> >> When crash kernel is loaded with kexec and on panic trigger
> >> machine_kexec() checks for number of cpus online.
> >> If more than one cpu is online machine_kexec() fails to load
> >> with below error
> >>
> >> kexec: error: multiple CPUs still online
> >>
> >> In machine_crash_nonpanic_core() SMP function, offline CPU
> >> before cpu_relax
> 
> >> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> 
> >> @@ -73,6 +73,7 @@ void machine_crash_nonpanic_core(void *unused)
> >>  	crash_save_cpu(&regs, smp_processor_id());
> >>  	flush_cache_all();
> >>  
> >> +	set_cpu_online(smp_processor_id(), false);
> >>  	atomic_dec(&waiting_for_crash_ipi);
> >>  	while (1)
> >>  		cpu_relax();
> > 
> > Ok, I guess this will work since the new kernel is loaded somewhere higher
> > in memory and the crashed kernel will stick around, so the non-crashing CPUs
> > can sit around spinning.
> 
> Does a kernel that's used as the crash kernel guarantee:
> 
> * Never to re-use the memory that was used by the previous kernel, so
> that the spin loop code/data won't be corrupted, ever, no matter how
> long the crash recovery kernel runs.
> 
> * Not use SMP, so there's never a need to re-activate the non-boot CPUs,
> which might not work if they aren't truly disabled but rather just
> running a pin loop?

I *think* this is true, and x86 seems to have code to a similar effect (the
powerpc stuff lost me though). I've never played with crash kernels on SMP
though...

Will


From hartleys at visionengravers.com  Fri Jul 26 13:10:46 2013
From: hartleys at visionengravers.com (H Hartley Sweeten)
Date: Fri, 26 Jul 2013 12:10:46 -0500
Subject: [PATCH] ARM: debug: use generic option for ep93xx PL10x debug port
In-Reply-To: <20130726170856.GV24642@n2100.arm.linux.org.uk>
References: <201307171048.17430.hartleys@visionengravers.com>
 <ADE657CA350FB648AAC2C43247A983F0021DAC5C2138@AUSP01VMBX24.collaborationhost.net>
 <20130726170856.GV24642@n2100.arm.linux.org.uk>
Message-ID: <ADE657CA350FB648AAC2C43247A983F0021DAC5C213A@AUSP01VMBX24.collaborationhost.net>

On Friday, July 26, 2013 10:09 AM, Russell King wrote:
> On Fri, Jul 26, 2013 at 12:04:10PM -0500, H Hartley Sweeten wrote:
>> Russell,
>> 
>> Ping... Any comments on this?
>
> I did reply on the 22nd, suggesting it gets put in the patch system.

Hmm.. I never saw the reply.

I'll get it into the patch system shortly.

Thanks,
Hartley



From jgunthorpe at obsidianresearch.com  Fri Jul 26 13:15:24 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Fri, 26 Jul 2013 11:15:24 -0600
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130726045433.GB4100@netboy>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726045433.GB4100@netboy>
Message-ID: <20130726171524.GB28895@obsidianresearch.com>

On Fri, Jul 26, 2013 at 06:54:33AM +0200, Richard Cochran wrote:
> On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
> 
> > We use DT has a kernel configuration input. Our environment is
> > designed to guarantee 100% that the kernel and DT match exactly. DT
> > very deliberately isn't an ABI boundary in our systems.
> 
> It is nice that you use DT in that way, but that is not how DT is
> supposed to work. If you must keep your DT in sync with the kernel,
> then there is no advantage over the old platfrom device method. At
> least that had the virtue of being a C language interface (ABI), and
> some mistakes were be caught by the compiler.

Over the years we have done it both ways, the platform device/open
coded method was not very flexible and it was hard to get changes into
the kernel. Even something as simple as pre-declaring I2C devices was
(back then) impossible/PITA.

Further, every other kernel release tended to break the board.c files,
just due to the usual kernel churn.

DT is much better, the stuff that can be described in DT is broader
and more thought tends to have been put into DT bindings than was put
into the old C methods. It has less churn, and what churn there is
seems simpler to follow.

Further, I've observed our usages tend to converge on something stable
after a few releases. I think our PPC platform went from 2.6.2x to 3.7
with only very minor DT changes, for instance.

Of course all this could have been done in C, but it wasn't/hasn't been..

> > We've been doing this for years and have a proven in the field track
> > record of upgrades from pre-2.6.16 to 3.7 and beyond with multiple
> > SOCs. The same bootloader that was shipped to support non-DT 2.6.16
> > boots DT 3.7 just fine.
> 
> Try that with Freescale PowerPCs.  Good luck.

Why would Freescale PPC be any different from the IBM PPC we use? We'd
use exactly the same techniques we use on ARM and PPC today and the
churn to the DT wouldn't be an operational problem in the field.

Hint: We don't use uboot on any production systems.

> I too work on commercial embedded systems, and DT has proven to be
> one gigantic *PITA*.

Why do you think our experiences are so different? I have now four
boards on two architectures that have run at least 8 different kernel
versions over 5-6 years (DT and non-DT) and DT has never once been a
problem for my systems. It all just works, and frankly, it works
really well.

[...]

>> We use DT has a kernel configuration input. Our environment is
>> designed to guarantee 100% that the kernel and DT match exactly. DT
>> very deliberately isn't an ABI boundary in our systems.

> Think about what you just said.

*shrug* For embedded I am being *very pragmatic*. I don't need/want an
ABI boundary between the DT and the kernel. I don't need the DT to
statically describe the hardware.

What I need, fundamentally, is a way to describe my board to the
kernel. IMHO, DT is doing that job today better than the old board.c
method.

> The DT describes the *hardware* not the kernel. Why should you ever
> need to update your DT at all?

Well, you know why. The DT schema used by the kernel changes over
time. Kirkwood just went through a massive change in schema in the
past few releases, and the same was true on our PPC platforms when
that was new.

Even if the mainline kernel was perfect, we'd still need to change the
DT schema in our products. Using kirkwood as an example - we have
various parts of the new schemas, and some variations of the
now-mainlined schemas as local patches in our tree to get the
functionality we need. This was all done about 8 months ago - final
upstream versions might ultimately land in 3.12..

I can't delay shipping while upstream sorts this out - so I know
*absolutely* that the DT schema will change. This has been planned for
and designed into the boot system and won't be a problem.

Why would anyone do embedded any other way?

Jason


From grundler at chromium.org  Fri Jul 26 13:16:48 2013
From: grundler at chromium.org (Grant Grundler)
Date: Fri, 26 Jul 2013 10:16:48 -0700
Subject: [PATCH v8 11/12] iommu/exynos: change rwlock to spinlock
In-Reply-To: <004101ce89f3$90200980$b0601c80$@samsung.com>
References: <004101ce89f3$90200980$b0601c80$@samsung.com>
Message-ID: <CANEJEGv0Bj=iMD=O2jPUc4u918mNQ_CuLvjc2P9ztRrKVKP0iQ@mail.gmail.com>

On Fri, Jul 26, 2013 at 4:30 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> Since acquiring read_lock is not more frequent than write_lock, it is
> not beneficial to use rwlock, this commit changes rwlock to spinlock.
>
> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>

Reviewed-by: Grant Grundler <grundler at chromium.org>

cheers,
grant

> ---
>  drivers/iommu/exynos-iommu.c |   36 ++++++++++++++++++------------------
>  1 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index c62c244..51e5b35 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -187,7 +187,7 @@ struct sysmmu_drvdata {
>         struct clk *clk;
>         struct clk *clk_master;
>         int activations;
> -       rwlock_t lock;
> +       spinlock_t lock;
>         struct iommu_domain *domain;
>         bool runtime_active;
>         unsigned long pgtable;
> @@ -287,7 +287,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
>         BUG_ON((base0 + size0) <= base0);
>         BUG_ON((size1 > 0) && ((base1 + size1) <= base1));
>
> -       read_lock_irqsave(&data->lock, flags);
> +       spin_lock_irqsave(&data->lock, flags);
>         if (!is_sysmmu_active(data))
>                 goto finish;
>
> @@ -319,7 +319,7 @@ void exynos_sysmmu_set_prefbuf(struct device *dev,
>         }
>         clk_disable(data->clk_master);
>  finish:
> -       read_unlock_irqrestore(&data->lock, flags);
> +       spin_unlock_irqrestore(&data->lock, flags);
>  }
>
>  static void show_fault_information(const char *name,
> @@ -371,7 +371,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
>
>         if (client)
>                 spin_lock(&client->lock);
> -       read_lock(&data->lock);
> +       spin_lock(&data->lock);
>
>         if (i == data->nsfrs) {
>                 itype = SYSMMU_FAULT_UNKNOWN;
> @@ -402,7 +402,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
>         if (itype != SYSMMU_FAULT_UNKNOWN)
>                 sysmmu_unblock(data->sfrbases[i]);
>
> -       read_unlock(&data->lock);
> +       spin_unlock(&data->lock);
>         if (client)
>                 spin_unlock(&client->lock);
>
> @@ -429,7 +429,7 @@ static bool __sysmmu_disable(struct sysmmu_drvdata *data)
>         bool disabled;
>         unsigned long flags;
>
> -       write_lock_irqsave(&data->lock, flags);
> +       spin_lock_irqsave(&data->lock, flags);
>
>         disabled = set_sysmmu_inactive(data);
>
> @@ -446,7 +446,7 @@ static bool __sysmmu_disable(struct sysmmu_drvdata *data)
>                                         data->activations);
>         }
>
> -       write_unlock_irqrestore(&data->lock, flags);
> +       spin_unlock_irqrestore(&data->lock, flags);
>
>         return disabled;
>  }
> @@ -493,7 +493,7 @@ static int __sysmmu_enable(struct sysmmu_drvdata *data,
>         int ret = 0;
>         unsigned long flags;
>
> -       write_lock_irqsave(&data->lock, flags);
> +       spin_lock_irqsave(&data->lock, flags);
>         if (set_sysmmu_active(data)) {
>                 data->pgtable = pgtable;
>                 data->domain = domain;
> @@ -511,7 +511,7 @@ static int __sysmmu_enable(struct sysmmu_drvdata *data,
>         if (WARN_ON(ret < 0))
>                 set_sysmmu_inactive(data); /* decrement count */
>
> -       write_unlock_irqrestore(&data->lock, flags);
> +       spin_unlock_irqrestore(&data->lock, flags);
>
>         return ret;
>  }
> @@ -602,7 +602,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
>
>                 data = dev_get_drvdata(client->sysmmu[i]);
>
> -               read_lock_irqsave(&data->lock, flags);
> +               spin_lock_irqsave(&data->lock, flags);
>                 if (is_sysmmu_active(data) && data->runtime_active) {
>                         int i;
>                         clk_enable(data->clk_master);
> @@ -615,7 +615,7 @@ static void sysmmu_tlb_invalidate_entry(struct device *dev, unsigned long iova)
>                                 "disabled. Skipping TLB invalidation @ %#lx\n",
>                                 iova);
>                 }
> -               read_unlock_irqrestore(&data->lock, flags);
> +               spin_unlock_irqrestore(&data->lock, flags);
>         }
>  }
>
> @@ -630,7 +630,7 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
>
>                 data = dev_get_drvdata(client->sysmmu[i]);
>
> -               read_lock_irqsave(&data->lock, flags);
> +               spin_lock_irqsave(&data->lock, flags);
>                 if (is_sysmmu_active(data) &&
>                                 data->runtime_active) {
>                         int i;
> @@ -646,7 +646,7 @@ void exynos_sysmmu_tlb_invalidate(struct device *dev)
>                 } else {
>                         dev_dbg(dev, "disabled. Skipping TLB invalidation\n");
>                 }
> -               read_unlock_irqrestore(&data->lock, flags);
> +               spin_unlock_irqrestore(&data->lock, flags);
>         }
>  }
>
> @@ -735,7 +735,7 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
>
>         data->runtime_active = !pm_runtime_enabled(dev);
>
> -       rwlock_init(&data->lock);
> +       spin_lock_init(&data->lock);
>         INIT_LIST_HEAD(&data->node);
>
>         platform_set_drvdata(pdev, data);
> @@ -749,11 +749,11 @@ static int sysmmu_suspend(struct device *dev)
>  {
>         struct sysmmu_drvdata *data = dev_get_drvdata(dev);
>         unsigned long flags;
> -       read_lock_irqsave(&data->lock, flags);
> +       spin_lock_irqsave(&data->lock, flags);
>         if (is_sysmmu_active(data) &&
>                 (!pm_runtime_enabled(dev) || data->runtime_active))
>                 __sysmmu_disable_nocount(data);
> -       read_unlock_irqrestore(&data->lock, flags);
> +       spin_unlock_irqrestore(&data->lock, flags);
>         return 0;
>  }
>
> @@ -761,11 +761,11 @@ static int sysmmu_resume(struct device *dev)
>  {
>         struct sysmmu_drvdata *data = dev_get_drvdata(dev);
>         unsigned long flags;
> -       read_lock_irqsave(&data->lock, flags);
> +       spin_lock_irqsave(&data->lock, flags);
>         if (is_sysmmu_active(data) &&
>                 (!pm_runtime_enabled(dev) || data->runtime_active))
>                 __sysmmu_enable_nocount(data);
> -       read_unlock_irqrestore(&data->lock, flags);
> +       spin_unlock_irqrestore(&data->lock, flags);
>         return 0;
>  }
>  #endif
> --
> 1.7.2.5
>
>


From csd at broadcom.com  Fri Jul 26 13:17:33 2013
From: csd at broadcom.com (Christian Daudt)
Date: Fri, 26 Jul 2013 10:17:33 -0700
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726171153.GN29916@titan.lakedaemon.net>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net>
 <51F29BFE.8000202@broadcom.com>
 <20130726171153.GN29916@titan.lakedaemon.net>
Message-ID: <51F2AF2D.1000300@broadcom.com>

On 13-07-26 10:11 AM, Jason Cooper wrote:
> Christian,
>
> On Fri, Jul 26, 2013 at 08:55:42AM -0700, Christian Daudt wrote:
>> [resend in plain text]
>> On 13-07-26 08:29 AM, Jason Cooper wrote:
>>> On Fri, Jul 26, 2013 at 04:56:40PM +0200, Domenico Andreoli wrote:
>>>> From: Domenico Andreoli<domenico.andreoli at linux.com>
>>>>
>>>> arch/arm/mach-bcm contains a plurality of Broadcom SoCs, each configured
>>>> separately. As a matter of flexibility and maintenance, it needs to be
>>>> always included in the build.
>>> So if I'm building mach-kirkwood, I _have_ to build Broadcom?  What is
>>> the *specific* problem you're encountering that this solves?
>>   No it won't, as the Makefile inside mach-bcm will only pull in
>> files based on ARCH_ settings. This move is so that a number
>> different Broadcom SoCs can co-exist inside the mach-bcm directory.
>
> Why wouldn't this work?
>
> ---->8-------
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index ba412e0..97b6aff 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -366,6 +366,12 @@ config ARCH_AT91
>   	  This enables support for systems based on Atmel
>   	  AT91RM9200 and AT91SAM9* processors.
>   
> +config ARCH_BCM
> +	bool "Broadcom family SoCs"
> +	help
> +	  This enables support for systems based on the Broadcom
> +	  bcm4760 and bcm281XX series SoCs.
> +
>   config ARCH_CLPS711X
>   	bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
>   	select ARCH_REQUIRE_GPIOLIB
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index f112895..4b1f9db 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -1,5 +1,9 @@
> -config ARCH_BCM
> -	bool "Broadcom SoC" if ARCH_MULTI_V7
> +if ARCH_BCM
> +
> +menu "Broadcom SoC Implementations"
> +
> +config MACH_BCM281XX
> +	bool "BCM281XX SoCs" if ARCH_MULTI_V7
>   	depends on MMU
>   	select ARCH_REQUIRE_GPIOLIB
>   	select ARM_ERRATA_754322
> @@ -17,3 +21,7 @@ config ARCH_BCM
>   	  It currently supports the 'BCM281XX' family, which includes
>   	  BCM11130, BCM11140, BCM11351, BCM28145 and
>   	  BCM28155 variants.
> +
> +endmenu
> +
> +endif
> diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> index 6adb6aec..e3f8f27 100644
> --- a/arch/arm/mach-bcm/Makefile
> +++ b/arch/arm/mach-bcm/Makefile
> @@ -10,6 +10,6 @@
>   # of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>   # GNU General Public License for more details.
>   
> -obj-$(CONFIG_ARCH_BCM)		:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
> +obj-$(CONFIG_MACH_BCM281XX)	:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
>   plus_sec := $(call as-instr,.arch_extension sec,+sec)
>   AFLAGS_bcm_kona_smc_asm.o	:=-Wa,-march=armv7-a$(plus_sec)
>
Because ARCH_BCM is meant to be used for a number of SoC families. We've 
started upstreaming one (the BCM281XX) but have 2 more internally that 
we're working towards upstreaming. And in the future our plan is to keep 
the Broadcom Mobile SoCs all building under this single ARCH_BCM 
configuration as multiplatform code building a single zImage for them.
The intent of mach-bcm on the other hand is to aggregate future SoC 
chips beyond ARCH_BCM (which is mobile SoC focused) to include other 
Broadcom ARM based SoCs. And there are 2 in the wings at the moment 
making their way into mainline as patches. The idea here being that with 
the new multiplatform code, the mach- dirs contain so little code that 
it makes sense to aggregate a bunch of SoCs from the same company in 
there (and we are the guinea pig on this one).

  Thanks,
    csd




From grundler at chromium.org  Fri Jul 26 13:22:13 2013
From: grundler at chromium.org (Grant Grundler)
Date: Fri, 26 Jul 2013 10:22:13 -0700
Subject: [PATCH v8 09/12] iommu/exynos: remove custom fault handler
In-Reply-To: <003f01ce89f3$56ce9340$046bb9c0$@samsung.com>
References: <003f01ce89f3$56ce9340$046bb9c0$@samsung.com>
Message-ID: <CANEJEGvcbUXMcb+4Qvu99ULJJEZ8GoHdkH4_nnayt1YzFEF-Jg@mail.gmail.com>

On Fri, Jul 26, 2013 at 4:29 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> This commit removes custom fault handler. The device drivers that
> need to register fault handler can register
> with iommu_set_fault_handler().
>
> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>


Reviewed-by: Grant Grundler <grundler at chromium.org>

cheers
grant

> ---
>  drivers/iommu/exynos-iommu.c |   71 ++++++++++--------------------------------
>  1 files changed, 17 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 87f6bb7..f9853fe 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -131,16 +131,6 @@ enum exynos_sysmmu_inttype {
>         SYSMMU_FAULTS_NUM
>  };
>
> -/*
> - * @itype: type of fault.
> - * @pgtable_base: the physical address of page table base. This is 0 if @itype
> - *                is SYSMMU_BUSERROR.
> - * @fault_addr: the device (virtual) address that the System MMU tried to
> - *             translated. This is 0 if @itype is SYSMMU_BUSERROR.
> - */
> -typedef int (*sysmmu_fault_handler_t)(enum exynos_sysmmu_inttype itype,
> -                       unsigned long pgtable_base, unsigned long fault_addr);
> -
>  static unsigned short fault_reg_offset[SYSMMU_FAULTS_NUM] = {
>         REG_PAGE_FAULT_ADDR,
>         REG_AR_FAULT_ADDR,
> @@ -181,7 +171,6 @@ struct sysmmu_drvdata {
>         int activations;
>         rwlock_t lock;
>         struct iommu_domain *domain;
> -       sysmmu_fault_handler_t fault_handler;
>         unsigned long pgtable;
>         void __iomem *sfrbases[0];
>  };
> @@ -313,34 +302,17 @@ finish:
>         read_unlock_irqrestore(&data->lock, flags);
>  }
>
> -static void __set_fault_handler(struct sysmmu_drvdata *data,
> -                                       sysmmu_fault_handler_t handler)
> -{
> -       unsigned long flags;
> -
> -       write_lock_irqsave(&data->lock, flags);
> -       data->fault_handler = handler;
> -       write_unlock_irqrestore(&data->lock, flags);
> -}
> -
> -void exynos_sysmmu_set_fault_handler(struct device *dev,
> -                                       sysmmu_fault_handler_t handler)
> -{
> -       struct sysmmu_drvdata *data = dev_get_drvdata(dev->archdata.iommu);
> -
> -       __set_fault_handler(data, handler);
> -}
> -
> -static int default_fault_handler(enum exynos_sysmmu_inttype itype,
> -                    unsigned long pgtable_base, unsigned long fault_addr)
> +static void show_fault_information(const char *name,
> +               enum exynos_sysmmu_inttype itype,
> +               unsigned long pgtable_base, unsigned long fault_addr)
>  {
>         unsigned long *ent;
>
>         if ((itype >= SYSMMU_FAULTS_NUM) || (itype < SYSMMU_PAGEFAULT))
>                 itype = SYSMMU_FAULT_UNKNOWN;
>
> -       pr_err("%s occurred at 0x%lx(Page table base: 0x%lx)\n",
> -                       sysmmu_fault_name[itype], fault_addr, pgtable_base);
> +       pr_err("%s occurred at 0x%lx by %s(Page table base: 0x%lx)\n",
> +               sysmmu_fault_name[itype], fault_addr, name, pgtable_base);
>
>         ent = section_entry(__va(pgtable_base), fault_addr);
>         pr_err("\tLv1 entry: 0x%lx\n", *ent);
> @@ -353,16 +325,12 @@ static int default_fault_handler(enum exynos_sysmmu_inttype itype,
>         pr_err("Generating Kernel OOPS... because it is unrecoverable.\n");
>
>         BUG();
> -
> -       return 0;
>  }
>
>  static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
>  {
>         /* SYSMMU is in blocked when interrupt occurred. */
>         struct sysmmu_drvdata *data = dev_id;
> -       struct resource *irqres;
> -       struct platform_device *pdev;
>         enum exynos_sysmmu_inttype itype;
>         unsigned long addr = -1;
>
> @@ -372,14 +340,15 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
>
>         WARN_ON(!is_sysmmu_active(data));
>
> -       pdev = to_platform_device(data->sysmmu);
> -       for (i = 0; i < (pdev->num_resources / 2); i++) {
> -               irqres = platform_get_resource(pdev, IORESOURCE_IRQ, i);
> +       for (i = 0; i < data->nsfrs; i++) {
> +               struct resource *irqres;
> +               irqres = platform_get_resource(to_platform_device(data->sysmmu),
> +                                               IORESOURCE_IRQ, i);
>                 if (irqres && ((int)irqres->start == irq))
>                         break;
>         }
>
> -       if (i == pdev->num_resources) {
> +       if (i == data->nsfrs) {
>                 itype = SYSMMU_FAULT_UNKNOWN;
>         } else {
>                 itype = (enum exynos_sysmmu_inttype)
> @@ -395,19 +364,15 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
>                 ret = report_iommu_fault(data->domain, data->dev,
>                                 addr, itype);
>
> -       if ((ret == -ENOSYS) && data->fault_handler) {
> -               unsigned long base = data->pgtable;
> -               if (itype != SYSMMU_FAULT_UNKNOWN)
> -                       base = __raw_readl(
> -                                       data->sfrbases[i] + REG_PT_BASE_ADDR);
> -               ret = data->fault_handler(itype, base, addr);
> -       }
> -
>         if (!ret && (itype != SYSMMU_FAULT_UNKNOWN))
>                 __raw_writel(1 << itype, data->sfrbases[i] + REG_INT_CLEAR);
> -       else
> -               dev_dbg(data->sysmmu, "%s is not handled.\n",
> -                               sysmmu_fault_name[itype]);
> +       else {
> +               unsigned long ba = data->pgtable;
> +               if (itype != SYSMMU_FAULT_UNKNOWN)
> +                       ba = __raw_readl(data->sfrbases[i] + REG_PT_BASE_ADDR);
> +               show_fault_information(dev_name(data->sysmmu),
> +                                       itype, ba, addr);
> +       }
>
>         if (itype != SYSMMU_FAULT_UNKNOWN)
>                 sysmmu_unblock(data->sfrbases[i]);
> @@ -644,8 +609,6 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
>
>         pm_runtime_enable(dev);
>
> -       __set_fault_handler(data, &default_fault_handler);
> -
>         data->sysmmu = dev;
>         data->clk = devm_clk_get(dev, "sysmmu");
>         if (IS_ERR(data->clk)) {
> --
> 1.7.2.5
>
>


From grundler at chromium.org  Fri Jul 26 13:23:54 2013
From: grundler at chromium.org (Grant Grundler)
Date: Fri, 26 Jul 2013 10:23:54 -0700
Subject: [PATCH v8 12/12] iommu/exynos: return 0 if iommu_attach_device()
 successes
In-Reply-To: <004201ce89f3$9b849a20$d28dce60$@samsung.com>
References: <004201ce89f3$9b849a20$d28dce60$@samsung.com>
Message-ID: <CANEJEGs_mVetwzT-_hiWie0uc9cZDgEzUXAVYhOu8eeszvGXOQ@mail.gmail.com>

On Fri, Jul 26, 2013 at 4:31 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> iommu_attach_device() against exynos-iommu positive integer on success
> if the caller calls iommu_attach_device() with the same iommu_domain
> multiple times without call to iommu_detach_device() to inform the
> caller how many calls to iommu_detach_device() to really detach iommu.
>
> However the convention of the return value of success of common API is
> zero, this patch makes iommu_attach_device() call against exynos-iommu
> always return zero if the given device is successfully attached to
> the given iommu_domain even though it is already attached to the same
> iommu_domain.
>
> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>

Reviewed-by: Grant Grundler <grundler at chromium.org>

cheers,
grant

> ---
>  drivers/iommu/exynos-iommu.c |   13 +++++++------
>  1 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 51e5b35..6eed6d6 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -882,15 +882,16 @@ static int exynos_iommu_attach_device(struct iommu_domain *domain,
>
>         spin_unlock_irqrestore(&priv->lock, flags);
>
> -       if (ret < 0)
> +       if (ret < 0) {
>                 dev_err(dev, "%s: Failed to attach IOMMU with pgtable %#lx\n",
>                                 __func__, __pa(priv->pgtable));
> -       else
> -               dev_dbg(dev, "%s: Attached IOMMU with pgtable 0x%lx%s\n",
> -                                       __func__, __pa(priv->pgtable),
> -                                       (ret == 0) ? "" : ", again");
> +               return ret;
> +       }
>
> -       return ret;
> +       dev_dbg(dev, "%s: Attached IOMMU with pgtable 0x%lx%s\n",
> +               __func__, __pa(priv->pgtable), (ret == 0) ? "" : ", again");
> +
> +       return 0;
>  }
>
>  static void exynos_iommu_detach_device(struct iommu_domain *domain,
> --
> 1.7.2.5
>
>


From swarren at wwwdotorg.org  Fri Jul 26 13:24:20 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 11:24:20 -0600
Subject: [PATCH] ARM: socfpga: dts: Add support for SD/MMC
In-Reply-To: <1374789881-20611-1-git-send-email-dinguyen@altera.com>
References: <1374789881-20611-1-git-send-email-dinguyen@altera.com>
Message-ID: <51F2B0C4.8000301@wwwdotorg.org>

On 07/25/2013 04:04 PM, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen at altera.com>
> 
> Add bindings for SD/MMC for SOCFPGA.
> Add "syscon" to the "altr,sys-mgr" binding.

> diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt

> +* Altera SOCFPGA specific extensions to the Synopsis Designware Mobile
> +  Storage Host Controller

If these are extensions to an existing binding, it feels like the
documentation should be part of that binding, although suppose it's
reasonable to create a HW-specific "sub-class" of an existing binding.

> +Required Properties:
> +
> +* compatible: should be
> +	- "altr,socfpga-dw-mshc": for controllers with Altera SOCFPGA
> +	  specific extensions.

The "altr" vendor prefix doesn't appear in
Documentation/devicetree/bindings/vendor-prefixes.txt. Is there another
patch in flight to add it?

> +* altr,dw-mshc-ciu-div: Specifies the divider value for the card interface
> +  unit (ciu) clock. The value should be (n-1). For Altera's SOCFPGA, the divider
> +  value is fixed at 3, which means parent_clock/4.

Should the clocks be represented using the common clock DT binding? If
this register is something that will always be handled entirely
internally to the HW module, then perhaps there's no need. If the driver
is going to need to call clk_set_rate() at all, then representing the
clock using the standard bindings seems better, unless you expect the
driver to call clk_set_rate(desired_rate * internal_divider) instead of
clk_set_rate(desired_rate) everywhere. That might not be unreasonable
though.

> +Required properties for a slot:
> +
> +* bus-width: Data width for card slot. 4-bit or 8-bit data.

Isn't that already part of the standard MMC bindings, and hence not
something you need to duplicate here?

> +Example:
> +
> +  The MSHC controller node can be split into two portions, SoC specific and
> +  board specific portions, as listed below.

That doesn't sound like a good idea. There should be one DT node for
each logical block. The internal construction of the Linux drivers
(presumably you have entirely separate code to handle the two nodes in
Linux so far?) should not influence the DT construction at all.

> +	dwmmc0 at ff704000 {
> +		compatible = "altr,socfpga-dw-mshc";
> +		reg = <0xff704000 0x1000>;
> +		interrupts = <0 139 4>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +	};
> +
> +	dwmmc0 at ff704000 {
> +		num-slots = <1>;
> +		supports-highspeed;
> +		broken-cd;
> +		fifo-depth = <0x400>;
> +		altr,dw-mshc-ciu-div = <3>;
> +      		altr,dw-mshc-sdr-timing = <0 3>;
> +
> +		slot at 0 {
> +			reg = <0>;
> +			bus-width = <4>;
> +		};
> +	};
> +

You might want to trim that trailing blank line.


From olof at lixom.net  Fri Jul 26 13:24:53 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Jul 2013 10:24:53 -0700
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726151223.045835540@gmail.com>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
Message-ID: <CAOesGMjRAxjh-jEA=qqMVeuS5bXeSL9sa7CLd8jkZ6AL8kUuRQ@mail.gmail.com>

Hi,

On Fri, Jul 26, 2013 at 7:56 AM, Domenico Andreoli
<domenico.andreoli at linux.com> wrote:
> From: Domenico Andreoli <domenico.andreoli at linux.com>
>
> arch/arm/mach-bcm contains a plurality of Broadcom SoCs, each configured
> separately. As a matter of flexibility and maintenance, it needs to be
> always included in the build.
>
> Cc: Christian Daudt <csd at broadcom.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Domenico Andreoli <domenico.andreoli at linux.com>
> ---
>  arch/arm/Makefile |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: b/arch/arm/Makefile
> ===================================================================
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x0020
>  # Machine directory name.  This list is sorted alphanumerically
>  # by CONFIG_* macro name.
>  machine-$(CONFIG_ARCH_AT91)            += at91
> -machine-$(CONFIG_ARCH_BCM)             += bcm
> +machine-y                              += bcm
>  machine-$(CONFIG_ARCH_BCM2835)         += bcm2835
>  machine-$(CONFIG_ARCH_CLPS711X)                += clps711x
>  machine-$(CONFIG_ARCH_CNS3XXX)         += cns3xxx

It's hard to tell what you're trying to do here, since the current
in-tree code works just fine and you're alluding to it having
problems. :)

Are you looking to add new selection of per-SoC config options? If so,
I propose keeping ARCH_BCM as a common, but silent, option that is
just selected by the other SoCs.  See how OMAP does it where
OMAP2/3/4/5 all select ARCH_OMAP2PLUS for comparison.


-Olof


From jason at lakedaemon.net  Fri Jul 26 13:33:00 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 26 Jul 2013 13:33:00 -0400
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <51F2AF2D.1000300@broadcom.com>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net>
 <51F29BFE.8000202@broadcom.com>
 <20130726171153.GN29916@titan.lakedaemon.net>
 <51F2AF2D.1000300@broadcom.com>
Message-ID: <20130726173300.GO29916@titan.lakedaemon.net>

On Fri, Jul 26, 2013 at 10:17:33AM -0700, Christian Daudt wrote:
> On 13-07-26 10:11 AM, Jason Cooper wrote:
> >Christian,
> >
> >On Fri, Jul 26, 2013 at 08:55:42AM -0700, Christian Daudt wrote:
> >>[resend in plain text]
> >>On 13-07-26 08:29 AM, Jason Cooper wrote:
> >>>On Fri, Jul 26, 2013 at 04:56:40PM +0200, Domenico Andreoli wrote:
> >>>>From: Domenico Andreoli<domenico.andreoli at linux.com>
> >>>>
> >>>>arch/arm/mach-bcm contains a plurality of Broadcom SoCs, each configured
> >>>>separately. As a matter of flexibility and maintenance, it needs to be
> >>>>always included in the build.
> >>>So if I'm building mach-kirkwood, I _have_ to build Broadcom?  What is
> >>>the *specific* problem you're encountering that this solves?
> >>  No it won't, as the Makefile inside mach-bcm will only pull in
> >>files based on ARCH_ settings. This move is so that a number
> >>different Broadcom SoCs can co-exist inside the mach-bcm directory.
> >
> >Why wouldn't this work?
> >
> >---->8-------
> >diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >index ba412e0..97b6aff 100644
> >--- a/arch/arm/Kconfig
> >+++ b/arch/arm/Kconfig
> >@@ -366,6 +366,12 @@ config ARCH_AT91
> >  	  This enables support for systems based on Atmel
> >  	  AT91RM9200 and AT91SAM9* processors.
> >+config ARCH_BCM
> >+	bool "Broadcom family SoCs"
> >+	help
> >+	  This enables support for systems based on the Broadcom
> >+	  bcm4760 and bcm281XX series SoCs.
> >+
> >  config ARCH_CLPS711X
> >  	bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
> >  	select ARCH_REQUIRE_GPIOLIB
> >diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> >index f112895..4b1f9db 100644
> >--- a/arch/arm/mach-bcm/Kconfig
> >+++ b/arch/arm/mach-bcm/Kconfig
> >@@ -1,5 +1,9 @@
> >-config ARCH_BCM
> >-	bool "Broadcom SoC" if ARCH_MULTI_V7
> >+if ARCH_BCM
> >+
> >+menu "Broadcom SoC Implementations"
> >+
> >+config MACH_BCM281XX
> >+	bool "BCM281XX SoCs" if ARCH_MULTI_V7
> >  	depends on MMU
> >  	select ARCH_REQUIRE_GPIOLIB
> >  	select ARM_ERRATA_754322
> >@@ -17,3 +21,7 @@ config ARCH_BCM
> >  	  It currently supports the 'BCM281XX' family, which includes
> >  	  BCM11130, BCM11140, BCM11351, BCM28145 and
> >  	  BCM28155 variants.
> >+
> >+endmenu
> >+
> >+endif
> >diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> >index 6adb6aec..e3f8f27 100644
> >--- a/arch/arm/mach-bcm/Makefile
> >+++ b/arch/arm/mach-bcm/Makefile
> >@@ -10,6 +10,6 @@
> >  # of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >  # GNU General Public License for more details.
> >-obj-$(CONFIG_ARCH_BCM)		:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
> >+obj-$(CONFIG_MACH_BCM281XX)	:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
> >  plus_sec := $(call as-instr,.arch_extension sec,+sec)
> >  AFLAGS_bcm_kona_smc_asm.o	:=-Wa,-march=armv7-a$(plus_sec)
> >
> Because ARCH_BCM is meant to be used for a number of SoC families.

As is ARCH_MVEBU for Marvell.  As kirkwood, dove, orion5x and mv78xx0
complete their conversion to DT and are multiplatform capable, they will
be migrated to mach-mvebu.  As is, it already contains two flavors of
their Armada SoCs.  mach-mvebu/Kconfig does things a little differently
than what I proposed above.  But the end result is the same because the
mach-mvebu/Kconfig file gets sourced, just like mach-bcm/Kconfig.

> We've started upstreaming one (the BCM281XX) but have 2 more
> internally that we're working towards upstreaming. And in the future
> our plan is to keep the Broadcom Mobile SoCs all building under this
> single ARCH_BCM configuration as multiplatform code building a
> single zImage for them.
> The intent of mach-bcm on the other hand is to aggregate future SoC
> chips beyond ARCH_BCM (which is mobile SoC focused) to include other
> Broadcom ARM based SoCs. And there are 2 in the wings at the moment
> making their way into mainline as patches. The idea here being that
> with the new multiplatform code, the mach- dirs contain so little
> code that it makes sense to aggregate a bunch of SoCs from the same
> company in there (and we are the guinea pig on this one).

So are we ;-)

thx,

Jason.


From grundler at chromium.org  Fri Jul 26 13:35:59 2013
From: grundler at chromium.org (Grant Grundler)
Date: Fri, 26 Jul 2013 10:35:59 -0700
Subject: [PATCH v8 08/12] iommu/exynos: remove prefetch buffer setting
 when enabling System MMU
In-Reply-To: <003e01ce89f3$4cdb45e0$e691d1a0$@samsung.com>
References: <003e01ce89f3$4cdb45e0$e691d1a0$@samsung.com>
Message-ID: <CANEJEGtWTZHZEr=XzPXHFbJtP7U5JFD-o58kRjLe23XaTzv=fA@mail.gmail.com>

On Fri, Jul 26, 2013 at 4:28 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> Prefetch buffer must be handled accurately, exact range of a buffer,
> frame by frame manually. Otherwise, it may causes page fault or
> deadlock in System MMU.
> Thus this patch removes prefetch buffer setting when System MMU is
> initialized(enabled).
>
> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>

Reviewed-by: Grant Grundler <grundler at chromium.org>

BTW, cscope doesn't find any callers of exynos_sysmmu_enable().
Want to submit another patch to remove it?

(Note I'm talking about exynos_sysmmu_enable() without "__" prefix).

cheers,
grant

> ---
>  drivers/iommu/exynos-iommu.c |   32 +++++++++++++++++++++++++++-----
>  1 files changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index cfc02ed..87f6bb7 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -80,6 +80,8 @@
>  #define CTRL_BLOCK     0x7
>  #define CTRL_DISABLE   0x0
>
> +#define CFG_FLPDCACHE  (1 << 20) /* System MMU 3.2+ only */
> +
>  #define REG_MMU_CTRL           0x000
>  #define REG_MMU_CFG            0x004
>  #define REG_MMU_STATUS         0x008
> @@ -96,6 +98,9 @@
>
>  #define REG_MMU_VERSION                0x034
>
> +#define MMU_MAJ_VER(reg)       (reg >> 28)
> +#define MMU_MIN_VER(reg)       ((reg >> 21) & 0x7F)
> +
>  #define REG_PB0_SADDR          0x04C
>  #define REG_PB0_EADDR          0x050
>  #define REG_PB1_SADDR          0x054
> @@ -200,6 +205,22 @@ static bool is_sysmmu_active(struct sysmmu_drvdata *data)
>         return data->activations > 0;
>  }
>
> +static unsigned int __sysmmu_version(struct sysmmu_drvdata *data,
> +                                    int idx, unsigned int *minor)
> +{
> +       unsigned long major;
> +
> +       major = readl(data->sfrbases[idx] + REG_MMU_VERSION);
> +
> +       if (minor)
> +               *minor = MMU_MIN_VER(major);
> +
> +       if (MMU_MAJ_VER(major) > 3)
> +               return 1;
> +
> +       return MMU_MAJ_VER(major);
> +}
> +
>  static void sysmmu_unblock(void __iomem *sfrbase)
>  {
>         __raw_writel(CTRL_ENABLE, sfrbase + REG_MMU_CTRL);
> @@ -460,14 +481,15 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
>         data->pgtable = pgtable;
>
>         for (i = 0; i < data->nsfrs; i++) {
> +               unsigned int min;
> +
>                 __sysmmu_set_ptbase(data->sfrbases[i], pgtable);
>
> -               if ((readl(data->sfrbases[i] + REG_MMU_VERSION) >> 28) == 3) {
> -                       /* System MMU version is 3.x */
> -                       __raw_writel((1 << 12) | (2 << 28),
> +               if ((__sysmmu_version(data, i, &min) == 3) && (min > 1)) {
> +                       unsigned long cfg;
> +                       cfg = __raw_readl(data->sfrbases[i] + REG_MMU_CFG);
> +                       __raw_writel(cfg | CFG_FLPDCACHE,
>                                         data->sfrbases[i] + REG_MMU_CFG);
> -                       __sysmmu_set_prefbuf(data->sfrbases[i], 0, -1, 0);
> -                       __sysmmu_set_prefbuf(data->sfrbases[i], 0, -1, 1);
>                 }
>
>                 __raw_writel(CTRL_ENABLE, data->sfrbases[i] + REG_MMU_CTRL);
> --
> 1.7.2.5
>
>


From grundler at chromium.org  Fri Jul 26 13:58:19 2013
From: grundler at chromium.org (Grant Grundler)
Date: Fri, 26 Jul 2013 10:58:19 -0700
Subject: [PATCH v8 06/12] ARM: dts: Add description of System MMU of
 Exynos SoCs
In-Reply-To: <003c01ce89f3$3abc4bc0$b034e340$@samsung.com>
References: <003c01ce89f3$3abc4bc0$b034e340$@samsung.com>
Message-ID: <CANEJEGsHyDP+AZejV57gMKPnbi0bi4yiWc42gPM9YuZzOewwLw@mail.gmail.com>

On Fri, Jul 26, 2013 at 4:28 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> ---
>  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++++++
>  arch/arm/boot/dts/exynos4.dtsi                     |  122 ++++++++
>  arch/arm/boot/dts/exynos4210.dtsi                  |   25 ++
>  arch/arm/boot/dts/exynos4x12.dtsi                  |   76 +++++
>  arch/arm/boot/dts/exynos5250.dtsi                  |  291 ++++++++++++++++++++
>  5 files changed, 617 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
>
> diff --git a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> new file mode 100644
> index 0000000..92f0a33
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> @@ -0,0 +1,103 @@
> +Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management Unit)
> +
> +Samsung's Exynos architecture contains System MMU that enables scattered

Cho,
"MMU" should be plural? "MMUs"?

> +physical memory chunks visible as a contiguous region to DMA-capable peripheral
> +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
> +
> +System MMU is a sort of IOMMU and support identical translation table format to

s/a sort of/an/ . Or perhaps "is also an". For the purposes of
documenting DMA support, we are talking about the IOMMU functionality
this device provides. It might be better to mention the functionality
the System MMU supports and refer to other subsystem documents (e,g,
clocking and power control) for details.

> +ARMv7 translation tables with minimum set of page properties including access
> +permissions, shareability and security protection. In addition, System MMU has
> +another capabilities like L2 TLB or block-fetch buffers to minimize translation
> +latency.
> +
> +A System MMU is dedicated to a single master peripheral device.  Thus, it is
> +important to specify the correct System MMU in the device node of its master
> +device.  Whereas a System MMU is dedicated to a master device, the master device
> +may have more than one System MMU.

Can I suggest rewriting the last two sentences to:
  The master device node must correctly specify at least one
SystemMMU. A master  device may have more than one System MMU.

BTW, is there a difference between "master device" and "master
peripheral device" that I'm not aware of?  Perhaps use just one of
those expressions in this document, not both if they are the same
thing (which is what I assumed).

cheers,
grant

> +
> +Required properties:
> +- compatible: Should be "samsung,exynos4210-sysmmu"
> +- reg: A tuple of base address and size of System MMU registers.
> +- interrupt-parent: The phandle of the interrupt controller of System MMU
> +- interrupts: A tuple of numbers that indicates the interrupt source.
> +- clock-names: Should be "sysmmu" if the System MMU is needed to gate its clock.
> +               Please refer to the following documents:
> +              Documentation/devicetree/bindings/clock/clock-bindings.txt
> +              Documentation/devicetree/bindings/clock/exynos4-clock.txt
> +              Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +              Optional "master" if the clock to the System MMU is gated by
> +              another gate clock other than "sysmmu". The System MMU driver
> +              sets "master" the parent of "sysmmu".
> +              Exynos4 SoCs, there needs no "master" clocks.
> +              Exynos5 SoCs, some System MMUs must have "master" clocks.
> +- clocks: Required if the System MMU is needed to gate its clock.
> +         Please refer to the documents listed above.
> +- samsung,power-domain: Required if the System MMU is needed to gate its power.
> +         Please refer to the following document:
> +         Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> +
> +Required properties for the master peripheral devices:
> +- iommu: phandles to the System MMUs of the device
> +
> +Examples:
> +A System MMU is dedicated to a single master device.
> +       gsc_0:  gsc at 0x13e00000 {
> +               compatible = "samsung,exynos5-gsc";
> +               reg = <0x13e00000 0x1000>;
> +               interrupts = <0 85 0>;
> +               samsung,power-domain = <&pd_gsc>;
> +               clocks = <&clock 256>;
> +               clock-names = "gscl";
> +               iommu = <&sysmmu_gsc1>;
> +       };
> +
> +       sysmmu_gsc0: sysmmu at 13E80000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13E80000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-gsc0";
> +               interrupts = <2 0>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 262>, <&clock 256>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +MFC has 2 System MMUs for each port that MFC is attached. Thus it seems natural
> +to define 2 System MMUs for each port of the MFC:
> +
> +       mfc: codec at 13400000 {
> +               compatible = "samsung,mfc-v5";
> +               reg = <0x13400000 0x10000>;
> +               interrupts = <0 94 0>;
> +               samsung,power-domain = <&pd_mfc>;
> +               clocks = <&clock 170>, <&clock 273>;
> +               clock-names = "sclk_mfc", "mfc";
> +               status = "ok";
> +               iommu = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>;
> +       };
> +
> +       sysmmu_mfc_l: sysmmu at 13620000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13620000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-mfc-l";
> +               interrupts = <5 5>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 274>;
> +               samsung,power-domain = <&pd_mfc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_mfc_r: sysmmu at 13630000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13630000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-mfc-r";
> +               interrupts = <5 6>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 275>;
> +               samsung,power-domain = <&pd_mfc>;
> +               status = "ok";
> +       };
> +
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index 359694c..ba74ee8 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -161,6 +161,7 @@
>                 interrupts = <0 94 0>;
>                 samsung,power-domain = <&pd_mfc>;
>                 status = "disabled";
> +               iommu = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>;
>         };
>
>         serial at 13800000 {
> @@ -395,5 +396,126 @@
>                 clock-names = "sclk_fimd", "fimd";
>                 samsung,power-domain = <&pd_lcd0>;
>                 status = "disabled";
> +               iommu = <&sysmmu_fimd0>;
> +       };
> +
> +       sysmmu_mfc_l: sysmmu at 13620000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13620000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-mfc-l";
> +               interrupts = <5 5>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 274>;
> +               samsung,power-domain = <&pd_mfc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_mfc_r: sysmmu at 13630000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13630000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-mfc-r";
> +               interrupts = <5 6>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 275>;
> +               samsung,power-domain = <&pd_mfc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_tv: sysmmu at 13E20000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13E20000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-tv";
> +               interrupts = <5 4>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 272>;
> +               samsung,power-domain = <&pd_tv>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc0: sysmmu at 11A20000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11A20000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc0";
> +               interrupts = <4 2>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 263>;
> +               samsung,power-domain = <&pd_cam>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc1: sysmmu at 11A30000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11A30000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc1";
> +               interrupts = <4 3>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 264>;
> +               samsung,power-domain = <&pd_cam>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc2: sysmmu at 11A40000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11A40000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc2";
> +               interrupts = <4 4>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 265>;
> +               samsung,power-domain = <&pd_cam>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc3: sysmmu at 11A50000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11A50000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc3";
> +               interrupts = <4 5>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 266>;
> +               samsung,power-domain = <&pd_cam>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_jpeg: sysmmu at 11A60000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11A60000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-jpeg";
> +               interrupts = <4 6>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 267>;
> +               samsung,power-domain = <&pd_cam>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_rotator: sysmmu at 12A30000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x12A30000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-rotator";
> +               interrupts = <5 0>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 281>;
> +               samsung,power-domain = <&pd_lcd0>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimd0: sysmmu at 11E20000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11E20000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimd0";
> +               interrupts = <5 2>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 287>;
> +               samsung,power-domain = <&pd_lcd0>;
> +               status = "ok";
>         };
>  };
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
> index 54710de..09b13da 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -119,5 +119,30 @@
>                 reg = <0x12800000 0x1000>;
>                 interrupts = <0 89 0>;
>                 status = "disabled";
> +               iommu = <&sysmmu_g2d>;
> +       };
> +
> +       sysmmu_g2d: sysmmu at 12A20000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x12A20000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-g2d";
> +               interrupts = <4 7>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 280>;
> +               samsung,power-domain = <&pd_lcd0>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimd1: sysmmu at 12220000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimd1";
> +               reg = <0x12220000 0x1000>;
> +               interrupts = <5 3>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 291>;
> +               samsung,power-domain = <&pd_lcd1>;
> +               status = "ok";
>         };
>  };
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
> index e3380a7..681db32 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -79,4 +79,80 @@
>                 interrupts = <0 89 0>;
>                 status = "disabled";
>         };
> +
> +       sysmmu_g2d: sysmmu at 10A40000{
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x10A40000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-g2d";
> +               interrupts = <4 7>;
> +               clock-names = "sysmmu";
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_isp: sysmmu at 12260000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x12260000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_isp";
> +               interrupts = <16 2>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 362>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_drc: sysmmu at 12270000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x12270000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_drc";
> +               interrupts = <16 3>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 363>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_fd: sysmmu at 122A0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x122A0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_fd";
> +               interrupts = <16 4>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 364>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_mcuctl: sysmmu at 122B0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x122B0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_mcuctl";
> +               interrupts = <16 5>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 376>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_lite0: sysmmu at 123B0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x123B0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_lite0";
> +               interrupts = <16 0>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 366>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_lite1: sysmmu at 123C0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x123C0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_lite1";
> +               interrupts = <16 1>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 365>;
> +               status = "ok";
> +       };
>  };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> index fc9fb3d..130d23d 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -66,6 +66,16 @@
>                 reg = <0x10044040 0x20>;
>         };
>
> +       pd_isp: mfc-power-domain at 0x10044020 {
> +               compatible = "samsung,exynos4210-pd";
> +               reg = <0x10044020 0x20>;
> +       };
> +
> +       pd_disp1: mfc-power-domain at 0x100440A0 {
> +               compatible = "samsung,exynos4210-pd";
> +               reg = <0x100440A0 0x20>;
> +       };
> +
>         clock: clock-controller at 0x10010000 {
>                 compatible = "samsung,exynos5250-clock";
>                 reg = <0x10010000 0x30000>;
> @@ -180,6 +190,7 @@
>                 reg = <0x11000000 0x10000>;
>                 interrupts = <0 96 0>;
>                 samsung,power-domain = <&pd_mfc>;
> +               iommu = <&sysmmu_mfc_l &sysmmu_mfc_l>;
>         };
>
>         rtc {
> @@ -571,6 +582,7 @@
>                 samsung,power-domain = <&pd_gsc>;
>                 clocks = <&clock 256>;
>                 clock-names = "gscl";
> +               iommu = <&sysmmu_gsc1>;
>         };
>
>         gsc_1:  gsc at 0x13e10000 {
> @@ -580,6 +592,7 @@
>                 samsung,power-domain = <&pd_gsc>;
>                 clocks = <&clock 257>;
>                 clock-names = "gscl";
> +               iommu = <&sysmmu_gsc1>;
>         };
>
>         gsc_2:  gsc at 0x13e20000 {
> @@ -589,6 +602,7 @@
>                 samsung,power-domain = <&pd_gsc>;
>                 clocks = <&clock 258>;
>                 clock-names = "gscl";
> +               iommu = <&sysmmu_gsc2>;
>         };
>
>         gsc_3:  gsc at 0x13e30000 {
> @@ -598,6 +612,7 @@
>                 samsung,power-domain = <&pd_gsc>;
>                 clocks = <&clock 259>;
>                 clock-names = "gscl";
> +               iommu = <&sysmmu_gsc3>;
>         };
>
>         hdmi {
> @@ -614,6 +629,7 @@
>                 compatible = "samsung,exynos5-mixer";
>                 reg = <0x14450000 0x10000>;
>                 interrupts = <0 94 0>;
> +               iommu = <&sysmmu_tv>;
>         };
>
>         dp-controller {
> @@ -638,5 +654,280 @@
>                 interrupts = <18 4>, <18 5>, <18 6>;
>                 clocks = <&clock 133>, <&clock 339>;
>                 clock-names = "sclk_fimd", "fimd";
> +               iommu = <&sysmmu_fimd1>;
> +       };
> +
> +       sysmmu_mfc_l: sysmmu at 11210000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11210000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-mfc_l";
> +               interrupts = <8 5>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 267>, <&clock 266>;
> +               samsung,power-domain = <&pd_mfc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_mfc_r: sysmmu at 11200000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11200000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-mfc_r";
> +               interrupts = <6 2>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 268>, <&clock 266>;
> +               samsung,power-domain = <&pd_mfc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_tv: sysmmu at 14650000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x14650000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-tv";
> +               interrupts = <7 4>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 349>;
> +               samsung,power-domain = <&pd_disp1>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_gsc0: sysmmu at 13E80000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13E80000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-gsc0";
> +               interrupts = <2 0>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 262>, <&clock 256>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_gsc1: sysmmu at 13E90000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13E90000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-gsc1";
> +               interrupts = <2 2>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 263>, <&clock 257>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_gsc2: sysmmu at 13EA0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13EA0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-gsc2";
> +               interrupts = <2 4>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 264>, <&clock 258>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_gsc3: sysmmu at 13EB0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13EB0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-gsc3";
> +               interrupts = <2 6>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 265>, <&clock 259>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimd1: sysmmu at 14640000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x14640000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimd1";
> +               interrupts = <3 2>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 350>;
> +               samsung,power-domain = <&pd_disp1>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_rotator: sysmmu at 11D40000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11D40000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-rotator";
> +               interrupts = <4 0>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 272>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_isp: sysmmu at 13260000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13260000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_isp";
> +               interrupts = <10 6>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 361>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_drc: sysmmu at 13270000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13270000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_drc";
> +               interrupts = <11 6>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 362>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_fd: sysmmu at 132A0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x132A0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_fd";
> +               interrupts = <5 0>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 363>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_scc: sysmmu at 13280000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13280000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_scalerc";
> +               interrupts = <5 2>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 364>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_scp: sysmmu at 13290000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13290000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_scalerp";
> +               interrupts = <3 6>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 365>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_mcuctl: sysmmu at 132B0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x132B0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_mcuctl";
> +               interrupts = <5 4>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 366>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_odc: sysmmu at 132C0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x132C0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_odc";
> +               interrupts = <11 0>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 367>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_dis0: sysmmu at 132D0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x132D0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_dis0";
> +               interrupts = <10 4>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 368>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_dis1: sysmmu at 132E0000{
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x132E0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_dis1";
> +               interrupts = <9 4>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 369>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_3dnr: sysmmu at 132F0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x132F0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_3dnr";
> +               interrupts = <5 6>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 370>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_lite0: sysmmu at 13C40000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13C40000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_lite0";
> +               interrupts = <3 4>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 346>, <&clock 345>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_lite1: sysmmu at 13C50000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13C50000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_lite1";
> +               interrupts = <24 1>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 347>, <&clock 345>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_jpeg: sysmmu at 11F20000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11F20000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-jpeg";
> +               interrupts = <4 2>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 273>, <&clock 270>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_2d: sysmmu at 10A60000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x10A60000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-2d";
> +               interrupts = <24 5>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 361>;
> +               status = "ok";
>         };
>  };
> --
> 1.7.2.5
>
>


From linux at arm.linux.org.uk  Fri Jul 26 14:47:02 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 19:47:02 +0100
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <51F2AF2D.1000300@broadcom.com>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net> <51F29BFE.8000202@broadcom.com>
 <20130726171153.GN29916@titan.lakedaemon.net> <51F2AF2D.1000300@broadcom.com>
Message-ID: <20130726184702.GW24642@n2100.arm.linux.org.uk>

On Fri, Jul 26, 2013 at 10:17:33AM -0700, Christian Daudt wrote:
> Because ARCH_BCM is meant to be used for a number of SoC families. We've  
> started upstreaming one (the BCM281XX) but have 2 more internally that  
> we're working towards upstreaming. And in the future our plan is to keep  
> the Broadcom Mobile SoCs all building under this single ARCH_BCM  
> configuration as multiplatform code building a single zImage for them.

1. We're moving to a single zImage for everything.  Not just Broadcom.
There's no need for Broadcom stuff to be treated any differently.
Participate in the single zImage project and you will get that benefit
without these games.

2. "library" mach-* support code doesn't go into another mach-* directory.
That's why we have the plat-* stuff.  Please follow this well established
model.  plat-* directories are selected by CONFIG_PLAT_* symbols, so
you would need CONFIG_PLAT_BCM.

Please don't persue your own solutions to problems which were solved years
ago and have established solutions already in place.


From robherring2 at gmail.com  Fri Jul 26 14:55:34 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 26 Jul 2013 13:55:34 -0500
Subject: [PATCH v3 07/16] of/device: add helper to get cpu device node
 from logical cpu index
In-Reply-To: <51F2AB71.3070102@arm.com>
References: <1374069984-20567-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-1-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <1374492747-13879-8-git-send-email-Sudeep.KarkadaNagesha@arm.com>
 <51F2AB71.3070102@arm.com>
Message-ID: <CAL_JsqK5i8fxskOtdqmPYL1pPicesAYHfW6+2NLR41t_fkf+6A@mail.gmail.com>

On Fri, Jul 26, 2013 at 12:01 PM, Sudeep KarkadaNagesha
<Sudeep.KarkadaNagesha at arm.com> wrote:
> Rob,
>
> On 22/07/13 12:32, Sudeep KarkadaNagesha wrote:
>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>>
>> Multiple drivers need to get the cpu device node from the cpu logical
>> index and then access the of_node.
>>
>> This patch adds helper function to fetch the device node directly.
>>
>> Cc: Rob Herring <rob.herring at calxeda.com>
>> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha at arm.com>
>
> If you have no objections with this patch, can I add your ACK ?

Yes.

Acked-by: Rob Herring <rob.herring at calxeda.com>

>
> Regards,
> Sudeep
>
>> ---
>>  include/linux/of_device.h | 15 +++++++++++++++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
>> index 9d27475..82ce324 100644
>> --- a/include/linux/of_device.h
>> +++ b/include/linux/of_device.h
>> @@ -1,6 +1,7 @@
>>  #ifndef _LINUX_OF_DEVICE_H
>>  #define _LINUX_OF_DEVICE_H
>>
>> +#include <linux/cpu.h>
>>  #include <linux/platform_device.h>
>>  #include <linux/of_platform.h> /* temporary until merge */
>>
>> @@ -43,6 +44,15 @@ static inline void of_device_node_put(struct device *dev)
>>       of_node_put(dev->of_node);
>>  }
>>
>> +static inline struct device_node *of_cpu_device_node_get(int cpu)
>> +{
>> +     struct device *cpu_dev;
>> +     cpu_dev = get_cpu_device(cpu);
>> +     if (!cpu_dev)
>> +             return NULL;
>> +     return of_node_get(cpu_dev->of_node);
>> +}
>> +
>>  #else /* CONFIG_OF */
>>
>>  static inline int of_driver_match_device(struct device *dev,
>> @@ -67,6 +77,11 @@ static inline const struct of_device_id *of_match_device(
>>  {
>>       return NULL;
>>  }
>> +
>> +static inline struct device_node *of_cpu_device_node_get(int cpu)
>> +{
>> +     return NULL;
>> +}
>>  #endif /* CONFIG_OF */
>>
>>  #endif /* _LINUX_OF_DEVICE_H */
>>
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From daniel at ffwll.ch  Fri Jul 26 14:56:05 2013
From: daniel at ffwll.ch (Daniel Vetter)
Date: Fri, 26 Jul 2013 20:56:05 +0200
Subject: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
In-Reply-To: <51f29cd1.e686440a.66b2.fffff9d5SMTPIN_ADDED_BROKEN@mx.google.com>
References: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com>
 <CAF6AEGtspnhSGNM4_QQubVfOkZ1Gh1-Z3iyHOLBPVWuqRy81ew@mail.gmail.com>
 <51f29cd1.e686440a.66b2.fffff9d5SMTPIN_ADDED_BROKEN@mx.google.com>
Message-ID: <20130726185604.GK6084@phenom.ffwll.local>

On Fri, Jul 26, 2013 at 04:58:55PM +0100, Tom Cooksey wrote:
> Hi Rob,
> 
> > >  * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
> > >    allocate buffers for the GPU. Still not sure how to resolve this
> > >    as we don't use DRM for our GPU driver.
> > 
> > any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
> > once the dma-fence stuff is in place), we'd have gpu-specific drm
> > (gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
> > using prime/dmabuf to share between the two.
> 
> The "extra" buffers we were allocating from armsoc DDX were really
> being allocated through DRM/GEM so we could get an flink name
> for them and pass a reference to them back to our GPU driver on
> the client side. If it weren't for our need to access those
> extra off-screen buffers with the GPU we wouldn't need to
> allocate them with DRM at all. So, given they are really "GPU"
> buffers, it does absolutely make sense to allocate them in a
> different driver to the display driver.
> 
> However, to avoid unnecessary memcpys & related cache
> maintenance ops, we'd also like the GPU to render into buffers
> which are scanned out by the display controller. So let's say
> we continue using DRM_IOCTL_MODE_CREATE_DUMB to allocate scan
> out buffers with the display's DRM driver but a custom ioctl
> on the GPU's DRM driver to allocate non scanout, off-screen
> buffers. Sounds great, but I don't think that really works
> with DRI2. If we used two drivers to allocate buffers, which
> of those drivers do we return in DRI2ConnectReply? Even if we
> solve that somehow, GEM flink names are name-spaced to a
> single device node (AFAIK). So when we do a DRI2GetBuffers,
> how does the EGL in the client know which DRM device owns GEM
> flink name "1234"? We'd need some pretty dirty hacks.

I don't know the details, but having different gem driver nodes is exactly
what prime support in X allows. The X server then passes the buffer object
between the different ddx drivers using dma-buf sharing.

So if we have two drm drivers, one a kms-only scanout driver and one a
gem-only mali driver, then the userspace gl mali driver would only ever
talk to the mali drm node. So flink for DRI2 would use that node
exclusively. The scanout drm node would then be treated like e.g. an usb
display-link device which is also display-only.

> So then we looked at allocating _all_ buffers with the GPU's
> DRM driver. That solves the DRI2 single-device-name and single
> name-space issue. It also means the GPU would _never_ render
> into buffers allocated through DRM_IOCTL_MODE_CREATE_DUMB.
> One thing I wasn't sure about is if there was an objection
> to using PRIME to export scanout buffers allocated with
> DRM_IOCTL_MODE_CREATE_DUMB and then importing them into a GPU
> driver to be rendered into? Is that a concern?

Imo sharing dumb buffers should be ok. The "dumb" concept is only really
relevant when the display and render part are integrated into one IP block
and driver.

> Anyway, that latter case also gets quite difficult. The "GPU"
> DRM driver would need to know the constraints of the display
> controller when allocating buffers intended to be scanned out.
> For example, pl111 typically isn't behind an IOMMU and so
> requires physically contiguous memory. We'd have to teach the
> GPU's DRM driver about the constraints of the display HW. Not
> exactly a clean driver model. :-(

Well the current dma-buf sharing code essentially only really works on x86
where everyone has a decent graphics tt and no cache flushing is required.

For ARM I expect that we need to have a common dma-buf backing storage
layer which walks all attached devices on the dma-buf, checks allocation
constraints and then picks a suitable pool to allocate the buffer.

Since dma-bufs should only be allocated once they're getting used (and not
when establishing the sharing) that should work out. But with the current
dma apis exposed to drivers that's not possible really. Essentially we
need ion but please not expose the heaps explicitly to userspace.  The
kernel already knows all this, so could take care of this for userspace
without breaking the current dma api abstractions we have.

Of course if you start to share buffers between different userspace drives
they need to talk to each another about what stride/pixel layout/tiling is
suitable. Since I'm a kernel guy I'll punt on this problem ;-)

> I'm still a little stuck on how to proceed, so any ideas
> would greatly appreciated! My current train of thought is
> having a kind of SoC-specific DRM driver which allocates
> buffers for both display and GPU within a single GEM
> namespace. That SoC-specific DRM driver could then know the
> constraints of both the GPU and the display HW. We could then
> use PRIME to export buffers allocated with the SoC DRM driver
> and import them into the GPU and/or display DRM driver.

That's pretty much how ION works and I'm not in favour of leaking
allocation constraints to userspace like that ...

> Note: While it doesn't use the DRM framework, the Mali T6xx
> kernel driver has supported importing buffers through dma_buf
> for some time. I've even written an EGL extension :-):
> 
> <http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_im
> port.txt>
> 
> 
> > I'm not entirely sure that the directions that the current CDF
> > proposals are headed is necessarily the right way forward.  I'd prefer
> > to see small/incremental evolution of KMS (ie. add drm_bridge and
> > drm_panel, and refactor the existing encoder-slave).  Keeping it
> > inside drm means that we can evolve it more easily, and avoid layers
> > of glue code for no good reason.
> 
> I think CDF could allow vendors to re-use code they've written
> for their Android driver stack in DRM drivers more easily. Though
> I guess ideally KMS would evolve to a point where it could be used
> by an Android driver stack. I.e. Support explicit fences.

Just fyi with intel we have some DSI/MIPI support patches floating around.
Our plan is to just merge them and then once we have a 2nd drm driver with
DSI support grow some common infrastructure out of this.

The same approach seems to work neatly for hdmi (infoframes) and dp
(although the dp helpers can be seriously extended).

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


From stern at rowland.harvard.edu  Fri Jul 26 15:01:25 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Fri, 26 Jul 2013 15:01:25 -0400 (EDT)
Subject: [PATCH V3 2/2] USB: OHCI: make ohci-pxa27x a separate driver
In-Reply-To: <1374850157-5854-3-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <Pine.LNX.4.44L0.1307261459060.1028-100000@iolanthe.rowland.org>

On Fri, 26 Jul 2013, Manjunath Goudar wrote:

> Separate the  OHCI pxa27x/pxa3xx host controller driver from
> ohci-hcd host code so that it can be built as a separate driver
> module. This work is part of enabling multi-platform kernels on
> ARM.
> 
> Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Greg KH <greg at kroah.com>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: linux-usb at vger.kernel.org
> 
> V2:
>  -Changed ohci_hcd and pxa27x_ohci struct variable names.
>     1 ohci_hcd struct variable name is ohci.
>     2 pxa27x_ohci struct variable name is pxa_ohci.
> 
> V3:
>  -Rewrite the macro definition of to_pxa27x_ohci.
>  -clk_put() function has been called before usb_put_hcd().

Acked-by: Alan Stern <stern at rowland.harvard.edu>



From csd at broadcom.com  Fri Jul 26 15:09:03 2013
From: csd at broadcom.com (Christian Daudt)
Date: Fri, 26 Jul 2013 12:09:03 -0700
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726184702.GW24642@n2100.arm.linux.org.uk>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net>
 <51F29BFE.8000202@broadcom.com>
 <20130726171153.GN29916@titan.lakedaemon.net>
 <51F2AF2D.1000300@broadcom.com>
 <20130726184702.GW24642@n2100.arm.linux.org.uk>
Message-ID: <51F2C94F.6020405@broadcom.com>

On 13-07-26 11:47 AM, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 10:17:33AM -0700, Christian Daudt wrote:
>> Because ARCH_BCM is meant to be used for a number of SoC families. We've
>> started upstreaming one (the BCM281XX) but have 2 more internally that
>> we're working towards upstreaming. And in the future our plan is to keep
>> the Broadcom Mobile SoCs all building under this single ARCH_BCM
>> configuration as multiplatform code building a single zImage for them.
> 1. We're moving to a single zImage for everything.  Not just Broadcom.
> There's no need for Broadcom stuff to be treated any differently.
> Participate in the single zImage project and you will get that benefit
> without these games.
I don't follow what is the game being played. The Broadcom mobile team 
is planning on building all future chips out of a single ARCH_ config 
(which we called ARCH_BCM), and others need a separate ARCH_ to build 
(other) specific SoCs for different families. Our ARCH_BCM chip was one 
of the first upstreamed with multiplatform enabled (multi_v7_defconfig 
already selects ARCH_BCM). So right now there are the following 3:
ARCH_BCM -> BCM281XX now + a few others to follow
ARCH_BCM5301X -> BCM530X family
ARCH_BCM4760 -> BCM4760 family.

and these would all reside in mach-bcm. The only problem I see with the 
above is that ARCH_BCM would probably have been more aptly named 
ARCH_MOBILE_BCM as the SoCs showing up under that ARCH are all from the 
mobile team @ Broadcom. And if that is what is confusing people, I'm ok 
with changing that.

>
> 2. "library" mach-* support code doesn't go into another mach-* directory.
> That's why we have the plat-* stuff.  Please follow this well established
> model.  plat-* directories are selected by CONFIG_PLAT_* symbols, so
> you would need CONFIG_PLAT_BCM.
>
> Please don't persue your own solutions to problems which were solved years
> ago and have established solutions already in place.
Maybe I missed something but with the migration to multiplatform (and 
the minimalist size of the ensuing arch-specific files) my understanding 
was that there is no need for PLAT going forward, that all socs from a 
single company can just co-exist under the same mach- directory. If you 
look at mach-bcm at present there are 2 .c files + 1 .S file. With the 
cleanups we are doing to support > 1 family under ARCH_BCM, that number 
is going to grow by 2-4 source files. Adding the 2 other ARCHes above 
will add another handful to a grand total of < 10 source files. None of 
these are 'library' files in the current sense (i.e. each subset of 
these files will only be used for a single ARCH_ config option), so 
there is nothing to move to a plat- directory.
  As an alternative to what is currently being done, I guess could go 
back to the 1-mach-directory-per-arch style so we'd have:
mach-bcm -> ARCH_BCM
mach-bcm5301x -> ARCH_BCM530X
mach-bcm4760 -> ARCH_BCM4760
but each of these dirs will have 2-3 source files. Which is what I heard 
a while back we wanted to start avoiding (the explosition of mach- dirs 
with next-to-nothing in each). Are you proposing we revert to this model ?

  thanks,
    csd



From nicolas.pitre at linaro.org  Fri Jul 26 15:19:32 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 26 Jul 2013 15:19:32 -0400 (EDT)
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value
 to index into save array
In-Reply-To: <20130726170402.GF28084@e102568-lin.cambridge.arm.com>
References: <alpine.LFD.2.03.1307251203550.15022@syhkavp.arg>
 <20130726113110.GB28084@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307261032330.15022@syhkavp.arg>
 <20130726153440.GD2282@localhost.localdomain>
 <alpine.LFD.2.03.1307261139370.15022@syhkavp.arg>
 <20130726170402.GF28084@e102568-lin.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1307261351140.15022@syhkavp.arg>

On Fri, 26 Jul 2013, Lorenzo Pieralisi wrote:

> On Fri, Jul 26, 2013 at 04:43:34PM +0100, Nicolas Pitre wrote:
> > On Fri, 26 Jul 2013, Dave Martin wrote:
> > 
> > > On Fri, Jul 26, 2013 at 10:41:38AM -0400, Nicolas Pitre wrote:
> > > > On Fri, 26 Jul 2013, Lorenzo Pieralisi wrote:
> > > > 
> > > > > On Thu, Jul 25, 2013 at 05:06:51PM +0100, Nicolas Pitre wrote:
> > > > > > On Thu, 25 Jul 2013, Dave Martin wrote:
> > > > > > 
> > > > > > > On Wed, Jul 24, 2013 at 02:55:00PM -0400, Nicolas Pitre wrote:
> > > > > > > > On Wed, 24 Jul 2013, Dave Martin wrote:
> > > > > > > > 
> > > > > > > > > But this patch commits us to requiring that on the suspend path 
> > > > > > > > > specifically -- I think that ought to be mentioned somewhere. A 
> > > > > > > > > comment in the preamble for __cpu_suspend would be enough, I think.
> > > > > > > > 
> > > > > > > > What comment would you suggest?  I want to make sure the possible 
> > > > > > > > confusion you see is properly addressed.
> > > > > > > 
> > > > > > > I think we just need to state that the value of
> > > > > > > cpu_logical_map(smp_processor_id()) must be the MPIDR of the physical
> > > > > > > CPU the suspending logical CPU will resume on.  Consequently, if doing a
> > > > > > > migration, cpu_logical_map() must be updated appropriately somewhere
> > > > > > > between cpu_pm_enter() and cpu_suspend().
> > > > > > 
> > > > > > Excellent.  I've amended the patch with this:
> > > > > > 
> > > > > > diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
> > > > > > index 2835d35234..caf938db62 100644
> > > > > > --- a/arch/arm/kernel/suspend.c
> > > > > > +++ b/arch/arm/kernel/suspend.c
> > > > > > @@ -17,6 +17,11 @@ extern void cpu_resume_mmu(void);
> > > > > >  /*
> > > > > >   * Hide the first two arguments to __cpu_suspend - these are an implementation
> > > > > >   * detail which platform code shouldn't have to know about.
> > > > > > + *
> > > > > > + * On SMP systems, the value of cpu_logical_map(smp_processor_id()) must be
> > > > > > + * the MPIDR of the physical CPU the suspending logical CPU will resume on.
> > > > > > + * Consequently, if doing a physical CPU migration, cpu_logical_map() must be
> > > > > > + * updated appropriately somewhere between cpu_pm_enter() and cpu_suspend().
> > > > > >   */
> > > > > >  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> > > > > >  {
> > > > > > 
> > > > > > I've put it against cpu_suspend() rather than __cpu_suspend(() as this 
> > > > > > is what users should care about.
> > > > > > 
> > > > > > ACK?
> > > > > 
> > > > > We need this patch to allow IKS to store a cpu context at a specific
> > > > > index, let's be honest. It is a moot point and I am not very happy
> > > > > about changing this code for a very specific usage, but the way code is
> > > > > implemented makes the change acceptable. I really do not think we should
> > > > > write guidelines on how cpu_suspend users have to change cpu_logical_map
> > > > > though, that's not needed apart from IKS and that should be limited to IKS
> > > > > code only.
> > > > > 
> > > > > Again, that's just my opinion, but cpu_suspend API must be kept as it is
> > > > > and we should not encourage people to use it in creative ways.
> > > > 
> > > > I tend to agree, but I'm now stuck between two conflicting requests.
> > > 
> > > Would it make sense to keep the same API to cpu_suspend(), but make it
> > > a wrapper for another function which has the MPIDR argument?  Then people
> > > calling cpu_suspend() continue as normal.  Only IKS needs to know about
> > > the underlying MPIDR handling when calling this.
> > 
> > The fact is that the switcher _does_ need to swizzle the cpu_logical_map 
> > anyway before suspending.  Hence really there is no point creating extra
> > wrappers for this.
> > 
> > So Lorenzo's suggestion to simply not advertise this too much for people 
> > to not get too creative is probably the best compromize IMHO.
> 
> We could add a function cpu_migrate, almost identical to cpu_suspend
> but accepting an MPIDR parameter as Dave said. cpu_suspend would read its
> own MPIDR using read_cpuid_mpidr() and pass it to __cpu_suspend, keeping the
> current behaviour unchanged (well, MPIDR is now read in cpu_suspend instead
> of __cpu_suspend).
> cpu_migrate will pass the mpidr to __cpu_suspend, to say "migrate this CPU to
> the CPU identified by this MPIDR"; IKS can swizzle cpu_logical_map internally.

Sorry but aren't we getting overboard with this?

- IKS _has_ to swizzle cpu_logical_map

- The suspend path has to get the MPIDR somehow

- This patch keeps the change to a minimum

- We don't necessarily want to "publish" a formal interface for this 
  trick

> Looks like lot of churn though, probably the intent is clearer and closer to
> PSCI. Just an idea, probably useless.

PSCI has to be invoked at a different level.  And frankly we don't need 
to look for analogies to justify an extra interface which we may as well 
dispense with.

> I will apply and test the patch as it is first thing next week.

Thanks.

FYI this patch is already in Linaro's kernel and passed all our testing.


Nicolas


From swarren at wwwdotorg.org  Fri Jul 26 15:21:20 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 13:21:20 -0600
Subject: [PATCH 1/9] ARM: dts: add generic DMA DT binding for tegra apbdma
In-Reply-To: <1374639002-16753-2-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-2-git-send-email-rizhao@nvidia.com>
Message-ID: <51F2CC30.5090200@wwwdotorg.org>

(Stripping the Cc list a lot, but adding in the DT binding maintainers)

On 07/23/2013 10:09 PM, Richard Zhao wrote:
> All Tegra device drivers will soon move to generic DMA device tree bindings.
> Add the required properties to the Tegra DT files to support that. The legacy
> property nvidia,dma-request-selector will be removed after all drivers have
> been converted, in order to maintain bisectability.
> 
> Changes:
>  - Add '#dma-cells' for apbdma nodes
>  - And properties 'dmas' and 'dma-names' for apbdma client nodes
>  - update apbdma DT binding doc
> 
> Signed-off-by: Richard Zhao <rizhao at nvidia.com>
> ---
>  .../devicetree/bindings/dma/tegra20-apbdma.txt     |  1 +
>  arch/arm/boot/dts/tegra114.dtsi                    | 27 ++++++++++++++++++++++
>  arch/arm/boot/dts/tegra20.dtsi                     | 27 ++++++++++++++++++++++
>  arch/arm/boot/dts/tegra30.dtsi                     | 25 ++++++++++++++++++++

This patch should be split differently.

Patch 1 in the series should include the binding document change and the
associated DMA driver change, which will support both the old and new
bindings.

Patch 2 should contain the *.dtsi changes.


From swarren at wwwdotorg.org  Fri Jul 26 15:25:20 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 13:25:20 -0600
Subject: [PATCH 0/9] ARM: tegra: move to generic DMA DT binding
In-Reply-To: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
Message-ID: <51F2CD20.6030700@wwwdotorg.org>

On 07/23/2013 10:09 PM, Richard Zhao wrote:
> The patch series aim to move apbdma to generic DT binding.
> 
> Changes:
> - It add dmas/dma-names properties while leave
>   nvidia,dma-request-selector to be compatible.
> - update apbdma driver and dma client drivers
> - ASoC tegra adds a new struct to pass device and dma-name.
> - at last, remove legacy nvidia,dma-request-selector

I would like to take this series through the Tegra tree to simplify
dependencies. So, I'm looking for ack's on the drivers rather than for
them to be applied. I had hoped Richard would point this out when
posting the patches.


From swarren at wwwdotorg.org  Fri Jul 26 15:27:58 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 13:27:58 -0600
Subject: [PATCH 2/9] dma: tegra20-apbdma: move to generic device tree
 bindings
In-Reply-To: <1374639002-16753-3-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-3-git-send-email-rizhao@nvidia.com>
Message-ID: <51F2CDBE.40802@wwwdotorg.org>

(Stripping the Cc list a lot)

On 07/23/2013 10:09 PM, Richard Zhao wrote:
> Update tegra20-apbdma driver to adopt generic DMA device tree bindings.
> It calls of_dma_controller_register() with of_dma_simple_xlate to get
> the generic DMA device tree helper support. The #dma-cells for apbdma
> must be 1, which is slave ID.
> 
> The existing nvidia,dma-request-selector still works there, and the
> support will be removed after all clients get converted to generic DMA
> device tree helper.

(BTW, I would like to take this series through the Tegra tree to
simplify dependencies. So, I'm looking for ack's on the drivers rather
than for them to be applied. I had hoped Richard would point this out
when posting the patches)

> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c

> +static bool tegra_dma_filter_fn(struct dma_chan *dc, void *param)
> +{
> +	if (dc->device->dev->driver == &tegra_dmac_driver.driver) {
> +		struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
> +		unsigned req = *(unsigned *)param;
> +
> +		tdc->slave_id = req;
> +
> +		return true;
> +	}
> +	return false;
> +}
> +
> +static struct of_dma_filter_info tegra_dma_info = {
> +	.filter_fn = tegra_dma_filter_fn,
> +};

Why does this driver need to define a filter function? I thought the
dmaengine's DT support would already match DMA clients/engines based on
the phandle in DT? Isn't the need to pass the slave channel ID into
drivers something pretty fundamental to dmaengine, and hence something
it already supports?


From arnaud.patard at rtp-net.org  Fri Jul 26 15:32:34 2013
From: arnaud.patard at rtp-net.org (Arnaud Patard (Rtp))
Date: Fri, 26 Jul 2013 21:32:34 +0200
Subject: [PATCH] ARM: dts: imx53-qsb: Make USBH1 functional
In-Reply-To: <1374787113-6628-1-git-send-email-fabio.estevam@freescale.com>
 (Fabio Estevam's message of "Thu, 25 Jul 2013 18:18:33 -0300")
References: <1374787113-6628-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <87ehalunfx.fsf@lebrac.rtp-net.org>

Fabio Estevam <fabio.estevam at freescale.com> writes:
Hi,

[...]

> @@ -302,7 +312,9 @@
>  };
>  
>  &usbh1 {
> -       status = "okay";
> +	vbus-supply = <&reg_usb_vbus>;
> +	phy_type = "utmi";
> +	status = "okay";
>  };
>  
>  &usbotg {

why not putting the vbus supply on the otg node too ?

Other than this point, works for me.

Tested-by: Arnaud Patard <arnaud.patard at rtp-net.org>


From dinguyen at altera.com  Fri Jul 26 15:33:40 2013
From: dinguyen at altera.com (Dinh Nguyen)
Date: Fri, 26 Jul 2013 14:33:40 -0500
Subject: [PATCH] ARM: socfpga: dts: Add support for SD/MMC
In-Reply-To: <51F2B0C4.8000301@wwwdotorg.org>
References: <1374789881-20611-1-git-send-email-dinguyen@altera.com>
 <51F2B0C4.8000301@wwwdotorg.org>
Message-ID: <1374867220.20685.44.camel@linux-builds1>

On Fri, 2013-07-26 at 11:24 -0600, Stephen Warren wrote:
> On 07/25/2013 04:04 PM, dinguyen at altera.com wrote:
> > From: Dinh Nguyen <dinguyen at altera.com>
> > 
> > Add bindings for SD/MMC for SOCFPGA.
> > Add "syscon" to the "altr,sys-mgr" binding.
> 
> > diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
> 
> > +* Altera SOCFPGA specific extensions to the Synopsis Designware Mobile
> > +  Storage Host Controller
> 
> If these are extensions to an existing binding, it feels like the
> documentation should be part of that binding, although suppose it's
> reasonable to create a HW-specific "sub-class" of an existing binding.
> 
> > +Required Properties:
> > +
> > +* compatible: should be
> > +	- "altr,socfpga-dw-mshc": for controllers with Altera SOCFPGA
> > +	  specific extensions.
> 
> The "altr" vendor prefix doesn't appear in
> Documentation/devicetree/bindings/vendor-prefixes.txt. Is there another
> patch in flight to add it?

I will send one shortly.

> 
> > +* altr,dw-mshc-ciu-div: Specifies the divider value for the card interface
> > +  unit (ciu) clock. The value should be (n-1). For Altera's SOCFPGA, the divider
> > +  value is fixed at 3, which means parent_clock/4.
> 
> Should the clocks be represented using the common clock DT binding? If
> this register is something that will always be handled entirely
> internally to the HW module, then perhaps there's no need. If the driver
> is going to need to call clk_set_rate() at all, then representing the
> clock using the standard bindings seems better, unless you expect the
> driver to call clk_set_rate(desired_rate * internal_divider) instead of
> clk_set_rate(desired_rate) everywhere. That might not be unreasonable
> though.

I will have to explore this option. But yes, this register is handled
entirely in the HW module in the case of Exynos, and in SOCFPGA's case
its in another HW block that is not clock related at all.

Since I've based this code on the exynos implementation, I've CCed a few
of those guys to see if this is possible.

> 
> > +Required properties for a slot:
> > +
> > +* bus-width: Data width for card slot. 4-bit or 8-bit data.
> 
> Isn't that already part of the standard MMC bindings, and hence not
> something you need to duplicate here?

Yes, I will remove.

> 
> > +Example:
> > +
> > +  The MSHC controller node can be split into two portions, SoC specific and
> > +  board specific portions, as listed below.
> 
> That doesn't sound like a good idea. There should be one DT node for
> each logical block. The internal construction of the Linux drivers
> (presumably you have entirely separate code to handle the two nodes in
> Linux so far?) should not influence the DT construction at all.

In the end, there is only 1 DT node for each logical block:

dwmmc0 at ff704000 {
	compatible = "altr,socfpga-dw-mshc";
	reg = <0xff704000 0x00001000>;
	interrupts = <0x00000000 0x0000008b 0x00000004>;
	fifo-depth = <0x00000400>;
	#address-cells = <0x00000001>;
	#size-cells = <0x00000000>;
	clocks = <0x00000016 0x00000017>;
	clock-names = "biu", "ciu";
	num-slots = <0x00000001>;
	supports-highspeed;
	broken-cd;
 	altr,dw-mshc-ciu-div = <0x00000003>;
  	altr,dw-mshc-sdr-timing = <0x00000000 0x00000003>;
	slot at 0 {
		reg = <0x00000000>;
		bus-width = <0x00000004>;
		};
	};

> 
> > +	dwmmc0 at ff704000 {
> > +		compatible = "altr,socfpga-dw-mshc";
> > +		reg = <0xff704000 0x1000>;
> > +		interrupts = <0 139 4>;
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +	};
> > +
> > +	dwmmc0 at ff704000 {
> > +		num-slots = <1>;
> > +		supports-highspeed;
> > +		broken-cd;
> > +		fifo-depth = <0x400>;
> > +		altr,dw-mshc-ciu-div = <3>;
> > +      		altr,dw-mshc-sdr-timing = <0 3>;
> > +
> > +		slot at 0 {
> > +			reg = <0>;
> > +			bus-width = <4>;
> > +		};
> > +	};
> > +
> 
> You might want to trim that trailing blank line.
> 

Will do. Thanks for reviewing this.

Dinh




From swarren at wwwdotorg.org  Fri Jul 26 15:34:43 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 13:34:43 -0600
Subject: [PATCH 3/9] spi: tegra114: move to generic dma DT binding
In-Reply-To: <1374639002-16753-4-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-4-git-send-email-rizhao@nvidia.com>
Message-ID: <51F2CF53.30002@wwwdotorg.org>

(Stripping CC list a bit)

On 07/23/2013 10:09 PM, Richard Zhao wrote:
> - driver: remove use of nvidia,dma-request-selector
> 	  use dma_request_slave_channel to request channel
> - if dmas/dma-names are missing, it still supports cpu based transfer
> - update binding doc and specify dmas/dma-names properties as optional

I'll simply repeat the comments I already made downstream:

Most commit messages aren't written as bullet points. This might be
better written as:

----------
Convert the Tegra114 SPI driver to support the standard DMA device-tree
bindings.

Note that DMA mode is optional; if the DT properties required to support
DMA are missing, then the driver will fall back to pure CPU operation.
----------

> diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt

> +Optional properties:
> +- dmas : The Tegra DMA controller's phandle and request selector for
> +  this SPI controller.
> +- dma-names : Should be "rx-tx".

This should reference dma.txt which defines the DMA DT bindings. How about:

----------
Optional properties:
- dmas, dma-names : The DMA channel to use for DMA-mode operation. See
  dma.txt for the definition of these properties. A single entry named
  "rx-tx" must be specified.
----------



From swarren at wwwdotorg.org  Fri Jul 26 15:36:11 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 13:36:11 -0600
Subject: [PATCH 5/9] spi: tegra20-sflash: move to generic dma DT binding
In-Reply-To: <1374639002-16753-6-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-6-git-send-email-rizhao@nvidia.com>
Message-ID: <51F2CFAB.4000609@wwwdotorg.org>

On 07/23/2013 10:09 PM, Richard Zhao wrote:
> update binding doc.

It may be worth mentioning here that the driver isn't updated since it
doesn't support DMA operation (yet?). A more complete patch description
would also be useful.


From swarren at wwwdotorg.org  Fri Jul 26 15:39:15 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 13:39:15 -0600
Subject: [PATCH 6/9] serial: tegra: move to generic dma DT binding
In-Reply-To: <1374639002-16753-7-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-7-git-send-email-rizhao@nvidia.com>
Message-ID: <51F2D063.5010505@wwwdotorg.org>

On 07/23/2013 10:09 PM, Richard Zhao wrote:
> - driver: remove use of nvidia,dma-request-selector
> 	  use dma_request_slave_channel to request channel
> - update binding doc

This patch needs to be amended so that the DMA channel is looked up
during probe() rather than open(), to guarantee that deferred probe
works. It's possible to hold off probe, but not possible AFAIK to hold
off opening the port.


From linux at arm.linux.org.uk  Fri Jul 26 15:39:08 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 20:39:08 +0100
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <51F2C94F.6020405@broadcom.com>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net> <51F29BFE.8000202@broadcom.com>
 <20130726171153.GN29916@titan.lakedaemon.net> <51F2AF2D.1000300@broadcom.com>
 <20130726184702.GW24642@n2100.arm.linux.org.uk>
 <51F2C94F.6020405@broadcom.com>
Message-ID: <20130726193908.GX24642@n2100.arm.linux.org.uk>

On Fri, Jul 26, 2013 at 12:09:03PM -0700, Christian Daudt wrote:
> On 13-07-26 11:47 AM, Russell King - ARM Linux wrote:
>> On Fri, Jul 26, 2013 at 10:17:33AM -0700, Christian Daudt wrote:
>>> Because ARCH_BCM is meant to be used for a number of SoC families. We've
>>> started upstreaming one (the BCM281XX) but have 2 more internally that
>>> we're working towards upstreaming. And in the future our plan is to keep
>>> the Broadcom Mobile SoCs all building under this single ARCH_BCM
>>> configuration as multiplatform code building a single zImage for them.
>> 1. We're moving to a single zImage for everything.  Not just Broadcom.
>> There's no need for Broadcom stuff to be treated any differently.
>> Participate in the single zImage project and you will get that benefit
>> without these games.
> I don't follow what is the game being played.

I don't really mind what you do, but when you start talking about having
any ARM build always descend into mach-bcm, then something is very wrong
with how you're going about it - you don't see anyone else needing that
in the tree, not even OMAP.

I don't really care if your intention is to decend into mach-bcm and then
do nothing - that's not the point.  The point is we shouldn't even
decend into mach-bcm if there's nothing to be built there.


From swarren at wwwdotorg.org  Fri Jul 26 15:41:35 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 13:41:35 -0600
Subject: [PATCH 6/9] serial: tegra: move to generic dma DT binding
In-Reply-To: <51F2D063.5010505@wwwdotorg.org>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-7-git-send-email-rizhao@nvidia.com>
 <51F2D063.5010505@wwwdotorg.org>
Message-ID: <51F2D0EF.9070808@wwwdotorg.org>

On 07/26/2013 01:39 PM, Stephen Warren wrote:
> On 07/23/2013 10:09 PM, Richard Zhao wrote:
>> - driver: remove use of nvidia,dma-request-selector
>> 	  use dma_request_slave_channel to request channel
>> - update binding doc
> 
> This patch needs to be amended so that the DMA channel is looked up
> during probe() rather than open(), to guarantee that deferred probe
> works. It's possible to hold off probe, but not possible AFAIK to hold
> off opening the port.

Hmm. I guess this comment actually applies to all/most of these patches.


From torvalds at linux-foundation.org  Fri Jul 26 15:54:14 2013
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Fri, 26 Jul 2013 12:54:14 -0700
Subject: [GIT PULL] arm64 fixes for 3.11
In-Reply-To: <20130726155458.GA31613@arm.com>
References: <20130726155458.GA31613@arm.com>
Message-ID: <CA+55aFzmEhGvqY883Bg568Gguewy41X9n1qDeaHkW2We6VVhZg@mail.gmail.com>

On Fri, Jul 26, 2013 at 8:55 AM, Catalin Marinas
<catalin.marinas at arm.com> wrote:
>
> - Stack size increased to 16K (similar to other 64-bit architectures)

I pulled, but this is misleading.

*Some* other 64-bit architectures do 16k stack sizes. But neither
x86-64 nor powerpc do, afaik. Instead, they do irq stacks, which is
generally a better idea than having one big stack.

                Linus


From swarren at wwwdotorg.org  Fri Jul 26 15:58:21 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 13:58:21 -0600
Subject: [PATCH 7/9] ASoC: tegra: move to generic DMA DT binding
In-Reply-To: <1374639002-16753-8-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-8-git-send-email-rizhao@nvidia.com>
Message-ID: <51F2D4DD.9060308@wwwdotorg.org>

On 07/23/2013 10:10 PM, Richard Zhao wrote:
> - add tegra_dma_filter_data to specify dma info
>   DMA DT binding needs the device that raise dma request and dma name
>   to request a dma channel. tegra30_i2s is a special case. It should be ahub
>   device and it also has dma name that cannot handled by ASoC dmaengine code.
>   So we pass the info using filter data in snd_dmaengine_dai_dma_data.
> - change i2s/ac97 drivers to use generic DT binding
> - tegra30_i2s: alloc ahub tx/rx fifo at driver probe time

> diff --git a/sound/soc/tegra/tegra30_i2s.c b/sound/soc/tegra/tegra30_i2s.c

I don't understand why the FIFO alloc/free had to move from
startup()/shutdown() to probe()/remove(). This will prevent later
changes from making the connectivity between the AHUB FIFOs and I2S
modules more dynamic, which is kind of the whole point of the AHUB HW
module.

> diff --git a/sound/soc/tegra/tegra_pcm.h b/sound/soc/tegra/tegra_pcm.h

> +#define TEGRA_DMA_NAME_MAX_LEN	10
> +
> +/*
> + * Generic DMA DT binding needs the device that raise dma request and dma name
> + * to request a dma channel. tegra30_i2s is a special case. It should be ahub
> + * device and it also has dma name that cannot handled by ASoC dmaengine code.
> + * So we pass the info using filter data in snd_dmaengine_dai_dma_data.
> + */
> +struct tegra_dma_filter_data {
> +	struct device *dma_dev;
> +	char dma_name[TEGRA_DMA_NAME_MAX_LEN];
> +};

I agree with Lars-Peter's comment that it'd be better to enhance the
ASoC dmaengine support to allow the channel name to be specified so we
don't need to much custom code. And that should use "char *" not a
fixed-length array.


From swarren at wwwdotorg.org  Fri Jul 26 15:59:33 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 13:59:33 -0600
Subject: [PATCH 8/9] ARM: dts: tegra: remove legacy nvidia,
 dma-request-selector properties
In-Reply-To: <1374639002-16753-9-git-send-email-rizhao@nvidia.com>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-9-git-send-email-rizhao@nvidia.com>
Message-ID: <51F2D525.7060605@wwwdotorg.org>

On 07/23/2013 10:10 PM, Richard Zhao wrote:
> All tegra dma client drivers have moved to generic dma binding.

Nit: Tegra not tegra, DMA not dma.


From paul at pwsan.com  Fri Jul 26 16:00:51 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Fri, 26 Jul 2013 20:00:51 +0000 (UTC)
Subject: [PATCH] ARM: OMAP3EVM: Marking omap3_evm_display_init() with
 CONFIG_BROKEN
In-Reply-To: <51ED33F1.4000801@cogentembedded.com>
References: <alpine.DEB.2.02.1307220523380.4804@utopia.booyaka.com>
 <51ED33F1.4000801@cogentembedded.com>
Message-ID: <alpine.DEB.2.02.1307261956520.25740@utopia.booyaka.com>

Hi Sergei

On Mon, 22 Jul 2013, Sergei Shtylyov wrote:

>    Perhaps it's better to follow what Documentation/SubmittingPatches
> suggests:
> 
> #else
> static inline __init void omap3_evm_display_init(void) {}

...

>    ... and eliminate #ifdef here?

While I agree with you in principle, the original patch is already merged.  
In my view, it's not worth checking in another patch on top of it to 
address such a cosmetic, non-functional issue.  I certainly don't think 
it's worth delaying getting v3.10-stable to boot on 37xx EVM...


- Paul


From mturquette at linaro.org  Fri Jul 26 16:01:07 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Fri, 26 Jul 2013 13:01:07 -0700
Subject: [PATCH v8 05/12] clk: exynos5250: add gate clock descriptions of
 System MMU
In-Reply-To: <003b01ce89f3$2be4db80$83ae9280$@samsung.com>
References: <003b01ce89f3$2be4db80$83ae9280$@samsung.com>
Message-ID: <20130726200107.7598.82010@quantum>

Quoting Cho KyongHo (2013-07-26 04:27:54)
> This adds gate clocks of all System MMUs and their master IPs
> that are not apeared in clk-exynos5250.c
> 
> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>

Change looks good to me. Are you OK if I take it into the clk tree or do
you want to keep this series together?

Regards,
Mike

> ---
>  .../devicetree/bindings/clock/exynos5250-clock.txt |   28 +++++++++-
>  drivers/clk/samsung/clk-exynos5250.c               |   57 ++++++++++++++++---
>  2 files changed, 75 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> index 781a627..df49694 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> @@ -154,7 +154,33 @@ clock which they consume.
>    dsim0                        341
>    dp                   342
>    mixer                        343
> -  hdmi                 345
> +  hdmi                 344
> +  camif_top            345
> +  smmu_fimc_lite0      346
> +  smmu_fimc_lite1      347
> +  smmu_fimc_lite2      348
> +  smmu_tv              349
> +  smmu_fimd1           350
> +  smmu_2d              351
> +  fimc_isp             352
> +  fimc_drc             353
> +  fimc_fd              354
> +  fimc_scc             355
> +  fimc_scp             356
> +  fimc_mcuctl          357
> +  fimc_odc             358
> +  fimc_dis             359
> +  fimc_3dnr            360
> +  smmu_fimc_isp                361
> +  smmu_fimc_drc                362
> +  smmu_fimc_fd         363
> +  smmu_fimc_scc                364
> +  smmu_fimc_scp                365
> +  smmu_fimc_mcuctl     366
> +  smmu_fimc_odc                367
> +  smmu_fimc_dis0       368
> +  smmu_fimc_dis1       369
> +  smmu_fimc_3dnr       370
>  
>  Example 1: An example of a clock controller node is listed below.
>  
> diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
> index 22d7699..e242bde 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -53,12 +53,15 @@
>  #define DIV_PERIC3             0x10564
>  #define DIV_PERIC4             0x10568
>  #define DIV_PERIC5             0x1056c
> +#define GATE_IP_ISP0           0x0C800
> +#define GATE_IP_ISP1           0x0C800
>  #define GATE_IP_GSCL           0x10920
>  #define GATE_IP_MFC            0x1092c
>  #define GATE_IP_GEN            0x10934
>  #define GATE_IP_FSYS           0x10944
>  #define GATE_IP_PERIC          0x10950
>  #define GATE_IP_PERIS          0x10960
> +#define GATE_IP_ACP            0x18800
>  #define SRC_CDREX              0x20200
>  #define PLL_DIV2_SEL           0x20a24
>  #define GATE_IP_DISP1          0x10928
> @@ -100,6 +103,14 @@ enum exynos5250_clks {
>         tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
>         wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
>  
> +       camif_top, smmu_fimc_lite0, smmu_fimc_lite1, smmu_fimc_lite2,
> +       smmu_tv, smmu_fimd1, smmu_2d,
> +       fimc_isp, fimc_drc, fimc_fd, fimc_scc, fimc_scp, fimc_mcuctl, fimc_odc,
> +       fimc_dis, fimc_3dnr,
> +       smmu_fimc_isp, smmu_fimc_drc, smmu_fimc_fd, smmu_fimc_scc,
> +       smmu_fimc_scp, smmu_fimc_mcuctl, smmu_fimc_odc, smmu_fimc_dis0,
> +       smmu_fimc_dis1, smmu_fimc_3dnr,
> +
>         nr_clks,
>  };
>  
> @@ -320,19 +331,26 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
>         GATE(gscl3, "gscl3", "aclk266", GATE_IP_GSCL, 3, 0, 0),
>         GATE(gscl_wa, "gscl_wa", "div_gscl_wa", GATE_IP_GSCL, 5, 0, 0),
>         GATE(gscl_wb, "gscl_wb", "div_gscl_wb", GATE_IP_GSCL, 6, 0, 0),
> -       GATE(smmu_gscl0, "smmu_gscl0", "aclk266", GATE_IP_GSCL, 7, 0, 0),
> -       GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
> -       GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
> -       GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
> +       GATE(smmu_gscl0, "smmu_gscl0", "none", GATE_IP_GSCL, 7, 0, 0),
> +       GATE(smmu_gscl1, "smmu_gscl1", "none", GATE_IP_GSCL, 8, 0, 0),
> +       GATE(smmu_gscl2, "smmu_gscl2", "none", GATE_IP_GSCL, 9, 0, 0),
> +       GATE(smmu_gscl3, "smmu_gscl3", "none", GATE_IP_GSCL, 10, 0, 0),
> +       GATE(camif_top, "camif_top", "aclk266", GATE_IP_GSCL, 4, 0, 0),
> +       GATE(smmu_fimc_lite0, "smmu_fimc_lite0", "none",
> +                                               GATE_IP_GSCL, 12, 0, 0),
> +       GATE(smmu_fimc_lite1, "smmu_fimc_lite1", "none",
> +                                               GATE_IP_GSCL, 13, 0, 0),
> +       GATE(smmu_fimc_lite2, "smmu_fimc_lite2", "none",
> +                                               GATE_IP_GSCL, 14, 0, 0),
>         GATE(mfc, "mfc", "aclk333", GATE_IP_MFC, 0, 0, 0),
> -       GATE(smmu_mfcl, "smmu_mfcl", "aclk333", GATE_IP_MFC, 1, 0, 0),
> -       GATE(smmu_mfcr, "smmu_mfcr", "aclk333", GATE_IP_MFC, 2, 0, 0),
> +       GATE(smmu_mfcr, "smmu_mfcr", "none", GATE_IP_MFC, 1, 0, 0),
> +       GATE(smmu_mfcl, "smmu_mfcl", "none", GATE_IP_MFC, 2, 0, 0),
>         GATE(rotator, "rotator", "aclk266", GATE_IP_GEN, 1, 0, 0),
>         GATE(jpeg, "jpeg", "aclk166", GATE_IP_GEN, 2, 0, 0),
>         GATE(mdma1, "mdma1", "aclk266", GATE_IP_GEN, 4, 0, 0),
> -       GATE(smmu_rotator, "smmu_rotator", "aclk266", GATE_IP_GEN, 6, 0, 0),
> -       GATE(smmu_jpeg, "smmu_jpeg", "aclk166", GATE_IP_GEN, 7, 0, 0),
> -       GATE(smmu_mdma1, "smmu_mdma1", "aclk266", GATE_IP_GEN, 9, 0, 0),
> +       GATE(smmu_rotator, "smmu_rotator", "none", GATE_IP_GEN, 6, 0, 0),
> +       GATE(smmu_jpeg, "smmu_jpeg", "none", GATE_IP_GEN, 7, 0, 0),
> +       GATE(smmu_mdma1, "smmu_mdma1", "none", GATE_IP_GEN, 9, 0, 0),
>         GATE(pdma0, "pdma0", "aclk200", GATE_IP_FSYS, 1, 0, 0),
>         GATE(pdma1, "pdma1", "aclk200", GATE_IP_FSYS, 2, 0, 0),
>         GATE(sata, "sata", "aclk200", GATE_IP_FSYS, 6, 0, 0),
> @@ -462,6 +480,27 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
>         GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
>         GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
>         GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
> +       GATE(smmu_tv, "smmu_tv", "none", GATE_IP_DISP1, 2, 0, 0),
> +       GATE(smmu_fimd1, "smmu_fimd1", "none", GATE_IP_DISP1, 8, 0, 0),
> +
> +       GATE(smmu_fimc_isp, "smmu_fimc_isp", "none", GATE_IP_ISP0, 8, 0, 0),
> +       GATE(smmu_fimc_drc, "smmu_fimc_drc", "none", GATE_IP_ISP0, 9, 0, 0),
> +       GATE(smmu_fimc_fd, "smmu_fimc_fd", "none", GATE_IP_ISP0, 10, 0, 0),
> +       GATE(smmu_fimc_scc, "smmu_fimc_scc", "none",
> +                                                       GATE_IP_ISP0, 11, 0, 0),
> +       GATE(smmu_fimc_scp, "smmu_fimc_scp", "none",
> +                                                       GATE_IP_ISP0, 12, 0, 0),
> +       GATE(smmu_fimc_mcuctl, "smmu_fimc_mcuctl", "none",
> +                                                       GATE_IP_ISP0, 13, 0, 0),
> +       GATE(smmu_fimc_odc, "smmu_fimc_odc", "none", GATE_IP_ISP1, 4, 0, 0),
> +       GATE(smmu_fimc_dis0, "smmu_fimc_dis0", "none",
> +                                                       GATE_IP_ISP1, 5, 0, 0),
> +       GATE(smmu_fimc_dis1, "smmu_fimc_dis1", "none",
> +                                                       GATE_IP_ISP1, 6, 0, 0),
> +       GATE(smmu_fimc_3dnr, "smmu_fimc_3dnr", "none",
> +                                                       GATE_IP_ISP1, 7, 0, 0),
> +
> +       GATE(smmu_2d, "smmu_2d", "none", GATE_IP_ACP, 7, 0, 0),
>  };
>  
>  static __initdata struct of_device_id ext_clk_match[] = {
> -- 
> 1.7.2.5
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From swarren at wwwdotorg.org  Fri Jul 26 16:02:50 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 14:02:50 -0600
Subject: [PATCH] ARM: socfpga: dts: Add support for SD/MMC
In-Reply-To: <1374867220.20685.44.camel@linux-builds1>
References: <1374789881-20611-1-git-send-email-dinguyen@altera.com>
 <51F2B0C4.8000301@wwwdotorg.org> <1374867220.20685.44.camel@linux-builds1>
Message-ID: <51F2D5EA.7050108@wwwdotorg.org>

On 07/26/2013 01:33 PM, Dinh Nguyen wrote:
> On Fri, 2013-07-26 at 11:24 -0600, Stephen Warren wrote:
>> On 07/25/2013 04:04 PM, dinguyen at altera.com wrote:
>>> From: Dinh Nguyen <dinguyen at altera.com>
>>>
>>> Add bindings for SD/MMC for SOCFPGA.
>>> Add "syscon" to the "altr,sys-mgr" binding.

>>> diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt

>>> +Example:
>>> +
>>> +  The MSHC controller node can be split into two portions, SoC specific and
>>> +  board specific portions, as listed below.
>>
>> That doesn't sound like a good idea. There should be one DT node for
>> each logical block. The internal construction of the Linux drivers
>> (presumably you have entirely separate code to handle the two nodes in
>> Linux so far?) should not influence the DT construction at all.
> 
> In the end, there is only 1 DT node for each logical block:

Oh right, I see you were intending to show the distinction between the
SoC .dtsi and board .dts file. I hadn't realized that. I don't think
it's common to do that in the examples, so I would recommend just
merging the whole example together myself.

> dwmmc0 at ff704000 {
> 	compatible = "altr,socfpga-dw-mshc";

That should include the baseline synopsis compatible value too.

> 	reg = <0xff704000 0x00001000>;
> 	interrupts = <0x00000000 0x0000008b 0x00000004>;
> 	fifo-depth = <0x00000400>;
> 	#address-cells = <0x00000001>;
> 	#size-cells = <0x00000000>;
> 	clocks = <0x00000016 0x00000017>;
> 	clock-names = "biu", "ciu";
> 	num-slots = <0x00000001>;
> 	supports-highspeed;
> 	broken-cd;
>  	altr,dw-mshc-ciu-div = <0x00000003>;
>   	altr,dw-mshc-sdr-timing = <0x00000000 0x00000003>;
> 	slot at 0 {
> 		reg = <0x00000000>;
> 		bus-width = <0x00000004>;
> 		};
> 	};



From mturquette at linaro.org  Fri Jul 26 16:07:03 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Fri, 26 Jul 2013 13:07:03 -0700
Subject: Zynq clk fixes
In-Reply-To: <51F26716.6030701@monstr.eu>
References: <51F26716.6030701@monstr.eu>
Message-ID: <20130726200703.7598.86150@quantum>

Quoting Michal Simek (2013-07-26 05:09:58)
> Hi Mike, [cc: Arnd and Olof]
> 
> Soren has found two bug fixes in zynq clk code.
> Can you please add these two patches to your tree?
> Will be great if you can add them to v3.11.
> 
> Arnd, Olof: I expect that all these clock changes should go through Mike.
> If I am wrong please let me know.

Looks right to me. Do these fix regressions in the current -rc cycle?

Regards,
Mike

> 
> Thanks,
> Michal
> 
> 
> The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:
> 
>   Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)
> 
> are available in the git repository at:
> 
>   git://git.xilinx.com/linux-xlnx.git tags/zynq-clk-fixes-for-3.11
> 
> for you to fetch changes up to 97d58aef394831f6f0583653de29e03886a0e09e:
> 
>   clk/zynq/clkc: Add CLK_SET_RATE_PARENT flag to ethernet muxes (2013-07-17 08:36:53 +0200)
> 
> ----------------------------------------------------------------
> arm: Xilinx Zynq clock fixes for v3.11
> 
> - Fix watchdog clock registration
> - Fix gem clock propagation
> 
> ----------------------------------------------------------------
> Soren Brinkmann (2):
>       clk/zynq/clkc: Add dedicated spinlock for the SWDT
>       clk/zynq/clkc: Add CLK_SET_RATE_PARENT flag to ethernet muxes
> 
>  drivers/clk/zynq/clkc.c | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> -- 
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
> Maintainer of Linux kernel - Xilinx Zynq ARM architecture
> Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


From sboyd at codeaurora.org  Fri Jul 26 16:15:06 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 26 Jul 2013 13:15:06 -0700
Subject: [PATCH v11] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <1374834384-8071-1-git-send-email-p.zabel@pengutronix.de>
References: <1374834384-8071-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <51F2D8CA.4010601@codeaurora.org>

On 07/26/13 03:26, Philipp Zabel wrote:
> +#include <linux/platform_device.h>
> +#include <linux/reset-controller.h>
> +
> +struct gpio_reset_data {
> +	struct reset_controller_dev rcdev;
> +	unsigned int gpio;
> +	bool active_low;
> +	s32 delay_us;

Maybe I missed it, why is this signed? Do we plan to have negative time
delays?

>
> +
> +static struct reset_control_ops gpio_reset_ops = {

const?

> +	.reset = gpio_reset,
> +	.assert = gpio_reset_assert,
> +	.deassert = gpio_reset_deassert,
> +};
>
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From mturquette at linaro.org  Fri Jul 26 16:18:00 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Fri, 26 Jul 2013 13:18:00 -0700
Subject: [PATCH 1/3] clk: exynos5250: Add G2D gate clock
In-Reply-To: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
References: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <20130726201800.7598.54329@quantum>

Quoting Sachin Kamat (2013-07-05 01:42:27)
> Adds gate clock for G2D IP for Exynos5250 SoC.
> 
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> Cc: Mike Turquette <mturquette at linaro.org>

I've taken patch #1 into clk-next.

> ---
> This patch depends on the following patch:
> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20581

I think I've gotten all three series you sent out, can you confirm?
http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20581
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20829
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20582

Regards,
Mike

> ---
>  .../devicetree/bindings/clock/exynos5250-clock.txt |    1 +
>  drivers/clk/samsung/clk-exynos5250.c               |    5 ++++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> index 1a05761..7e88242 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> @@ -155,6 +155,7 @@ clock which they consume.
>    dp                   342
>    mixer                        343
>    hdmi                 344
> +  g2d                  345
>  
>  Example 1: An example of a clock controller node is listed below.
>  
> diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
> index 6f767c5..3da0bdf 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -62,6 +62,7 @@
>  #define SRC_CDREX              0x20200
>  #define PLL_DIV2_SEL           0x20a24
>  #define GATE_IP_DISP1          0x10928
> +#define GATE_IP_ACP            0x10000
>  
>  /*
>   * Let each supported clock get a unique id. This id is used to lookup the clock
> @@ -99,7 +100,7 @@ enum exynos5250_clks {
>         spi2, i2s1, i2s2, pcm1, pcm2, pwm, spdif, ac97, hsi2c0, hsi2c1, hsi2c2,
>         hsi2c3, chipid, sysreg, pmu, cmu_top, cmu_core, cmu_mem, tzpc0, tzpc1,
>         tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
> -       wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
> +       wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, g2d,
>  
>         nr_clks,
>  };
> @@ -152,6 +153,7 @@ static __initdata unsigned long exynos5250_clk_regs[] = {
>         SRC_CDREX,
>         PLL_DIV2_SEL,
>         GATE_IP_DISP1,
> +       GATE_IP_ACP,
>  };
>  
>  /* list of all parent clock list */
> @@ -463,6 +465,7 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
>         GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
>         GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
>         GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
> +       GATE(g2d, "g2d", "aclk200", GATE_IP_ACP, 3, 0, 0),
>  };
>  
>  static __initdata struct of_device_id ext_clk_match[] = {
> -- 
> 1.7.9.5


From markus.mayer at linaro.org  Fri Jul 26 16:25:42 2013
From: markus.mayer at linaro.org (Markus Mayer)
Date: Fri, 26 Jul 2013 13:25:42 -0700
Subject: [PATCH v3 0/3] ARM: bcm281xx: GPIO driver
Message-ID: <1374870345-8276-1-git-send-email-markus.mayer@linaro.org>

This patch series adds the GPIO driver, and its device tree bindings,
for the Broadcom bcm281xx family of chips.

Markus Mayer (3):
  ARM: bcm281xx: Add GPIO driver
  ARM: bcm281xx: Device Tree bindings for GPIO driver
  ARM: bcm281xx: Enable GPIO driver

 .../devicetree/bindings/gpio/gpio-bcm-kona.txt     |   41 ++
 arch/arm/boot/dts/bcm11351.dtsi                    |   16 +
 arch/arm/mach-bcm/Kconfig                          |    2 +-
 drivers/gpio/Kconfig                               |    6 +
 drivers/gpio/Makefile                              |    1 +
 drivers/gpio/gpio-bcm-kona.c                       |  697 ++++++++++++++++++++
 6 files changed, 762 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt
 create mode 100644 drivers/gpio/gpio-bcm-kona.c

-- 
1.7.9.5




From markus.mayer at linaro.org  Fri Jul 26 16:25:43 2013
From: markus.mayer at linaro.org (Markus Mayer)
Date: Fri, 26 Jul 2013 13:25:43 -0700
Subject: [PATCH v3 1/3] ARM: bcm281xx: Add GPIO driver
In-Reply-To: <1374870345-8276-1-git-send-email-markus.mayer@linaro.org>
References: <1374870345-8276-1-git-send-email-markus.mayer@linaro.org>
Message-ID: <1374870345-8276-2-git-send-email-markus.mayer@linaro.org>

From: Markus Mayer <mmayer at broadcom.com>

This patch adds the GPIO driver for the bcm281xx family of chips.

Signed-off-by: Markus Mayer <markus.mayer at linaro.org>
Reviewed-by: Ray Jui <rjui at broadcom.com>
Reviewed-by: Christian Daudt <csd at broadcom.com>
Reviewed-by: Tim Kryger <tim.kryger at linaro.org>
Reviewed-by: Matt Porter <matt.porter at linaro.org>
Reviewed-by: Alex Elder <alex.elder at linaro.org>
---
 drivers/gpio/gpio-bcm-kona.c |  697 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 697 insertions(+)
 create mode 100644 drivers/gpio/gpio-bcm-kona.c

diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
new file mode 100644
index 0000000..ca6cb7e
--- /dev/null
+++ b/drivers/gpio/gpio-bcm-kona.c
@@ -0,0 +1,697 @@
+/*
+ * Copyright (C) 2012-2013 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/io.h>
+#include <linux/gpio.h>
+#include <linux/of_device.h>
+#include <linux/module.h>
+#include <linux/irqdomain.h>
+#include <linux/irqchip/chained_irq.h>
+
+#define BCM_GPIO_PASSWD	0x00a5a501
+#define GPIO_PER_BANK	32
+
+#define GPIO_BANK(gpio)	((gpio) >> 5)
+#define GPIO_BIT(gpio)	((gpio) & (GPIO_PER_BANK - 1))
+
+#define GPIO_GPOR0_OFFSET					0x00000000
+#define GPIO_GPIR0_OFFSET					0x00000020
+#define GPIO_GPORS0_OFFSET					0x00000040
+#define GPIO_GPORC0_OFFSET					0x00000060
+#define GPIO_ISR0_OFFSET					0x00000080
+#define GPIO_IMR0_OFFSET					0x000000A0
+#define GPIO_IMRC0_OFFSET					0x000000C0
+#define GPIO_GPCTR0_OFFSET					0x00000100
+#define GPIO_GPPLSR0_OFFSET					0x00000500
+#define GPIO_GPPWR_OFFSET					0x00000520
+
+#define GPIO_GPCTR0_DBR_SHIFT					5
+#define GPIO_GPCTR0_DBR_MASK					0x000001E0
+
+#define GPIO_GPCTR0_ITR_SHIFT					3
+#define GPIO_GPCTR0_ITR_MASK					0x00000018
+#define GPIO_GPCTR0_ITR_CMD_RISING_EDGE				0x00000001
+#define GPIO_GPCTR0_ITR_CMD_FALLING_EDGE			0x00000002
+#define GPIO_GPCTR0_ITR_CMD_BOTH_EDGE				0x00000003
+
+#define GPIO_GPCTR0_IOTR_MASK					0x00000001
+#define GPIO_GPCTR0_IOTR_CMD_0UTPUT				0x00000000
+#define GPIO_GPCTR0_IOTR_CMD_INPUT				0x00000001
+
+#define GPIO_GPCTR0_DB_ENABLE_MASK				0x00000100
+
+#define LOCK_CODE	0xFFFFFFFF
+#define UNLOCK_CODE	0x0
+
+struct bcm_kona_gpio_bank {
+	int id;
+	int irq;
+};
+
+struct bcm_kona_gpio {
+	struct irq_domain *irq_domain;
+	void __iomem *reg_base;
+	int num_bank;
+	int irq_base;
+	spinlock_t lock;
+	struct bcm_kona_gpio_bank *banks;
+};
+
+static struct gpio_chip bcm_gpio_chip;
+
+static void bcm_kona_gpio_irq_mask(struct irq_data *d);
+static void bcm_kona_gpio_irq_unmask(struct irq_data *d);
+
+static struct bcm_kona_gpio bcm_kona_gpio;
+
+static inline u32 bcm_kona_gpio_out_status(int bank)
+{
+	return GPIO_GPOR0_OFFSET + (bank << 2);
+}
+
+static inline u32 bcm_kona_gpio_in_status(int bank)
+{
+	return GPIO_GPIR0_OFFSET + (bank << 2);
+}
+
+static inline u32 bcm_kona_gpio_out_set(int bank)
+{
+	return GPIO_GPORS0_OFFSET + (bank << 2);
+}
+
+static inline u32 bcm_kona_gpio_out_clear(int bank)
+{
+	return GPIO_GPORC0_OFFSET + (bank << 2);
+}
+
+static inline u32 bcm_kona_gpio_int_status(int bank)
+{
+	return GPIO_ISR0_OFFSET + (bank << 2);
+}
+
+static inline u32 bcm_kona_gpio_int_mask(int bank)
+{
+	return GPIO_IMR0_OFFSET + (bank << 2);
+}
+
+static inline u32 bcm_kona_gpio_int_mskclr(int bank)
+{
+	return GPIO_IMRC0_OFFSET + (bank << 2);
+}
+
+static inline u32 bcm_kona_gpio_pwd_status(int bank)
+{
+	return GPIO_GPPLSR0_OFFSET + (bank << 2);
+}
+
+static inline u32 bcm_kona_gpio_control(int gpio)
+{
+	return GPIO_GPCTR0_OFFSET + (gpio << 2);
+}
+
+static int bcm_kona_count_irq_resources(struct platform_device *pdev)
+{
+	struct resource *res;
+	int count = 0;
+
+	for (;;) {
+		res = platform_get_resource(pdev, IORESOURCE_IRQ, count);
+		if (!res)
+			break;
+		count++;
+	}
+	return count;
+}
+
+static void  bcm_kona_gpio_set_lockcode_bank(int bank_id, int lockcode)
+{
+	void __iomem *reg_base = bcm_kona_gpio.reg_base;
+	/* This register is password protected  */
+	writel(BCM_GPIO_PASSWD, reg_base + GPIO_GPPWR_OFFSET);
+	/* Lock the bank */
+	writel(lockcode, reg_base + bcm_kona_gpio_pwd_status(bank_id));
+}
+
+static inline void bcm_kona_gpio_lock_bank(int bank_id)
+{
+	bcm_kona_gpio_set_lockcode_bank(bank_id, LOCK_CODE);
+}
+
+static inline void bcm_kona_gpio_unlock_bank(int bank_id)
+{
+	bcm_kona_gpio_set_lockcode_bank(bank_id, UNLOCK_CODE);
+}
+
+static void bcm_kona_gpio_set(struct gpio_chip *chip, unsigned gpio,
+	int value)
+{
+	int bank_id = GPIO_BANK(gpio);
+	int bit = GPIO_BIT(gpio);
+	void __iomem *reg_base = bcm_kona_gpio.reg_base;
+	u32 val, reg_offset;
+	unsigned long flags;
+
+	spin_lock_irqsave(&bcm_kona_gpio.lock, flags);
+	bcm_kona_gpio_unlock_bank(bank_id);
+
+	/* determine the GPIO pin direction */
+	val = readl(reg_base + bcm_kona_gpio_control(gpio));
+	val &= GPIO_GPCTR0_IOTR_MASK;
+
+	/* this function only applies to output pin */
+	if (GPIO_GPCTR0_IOTR_CMD_INPUT == val)
+		return;
+
+	reg_offset = value ? bcm_kona_gpio_out_set(bank_id) :
+				bcm_kona_gpio_out_clear(bank_id);
+
+	val = readl(reg_base + reg_offset);
+	val |= 1 << bit;
+	writel(val, reg_base + reg_offset);
+
+	bcm_kona_gpio_lock_bank(bank_id);
+	spin_unlock_irqrestore(&bcm_kona_gpio.lock, flags);
+}
+
+static int bcm_kona_gpio_get(struct gpio_chip *chip, unsigned gpio)
+{
+	int bank_id = GPIO_BANK(gpio);
+	int bit = GPIO_BIT(gpio);
+	void __iomem *reg_base = bcm_kona_gpio.reg_base;
+	u32 val, reg_offset;
+	unsigned long flags;
+
+	spin_lock_irqsave(&bcm_kona_gpio.lock, flags);
+	bcm_kona_gpio_unlock_bank(bank_id);
+
+	/* determine the GPIO pin direction */
+	val = readl(reg_base + bcm_kona_gpio_control(gpio));
+	val &= GPIO_GPCTR0_IOTR_MASK;
+
+	/* read the GPIO bank status */
+	reg_offset = (GPIO_GPCTR0_IOTR_CMD_INPUT == val) ?
+					bcm_kona_gpio_in_status(bank_id) :
+					bcm_kona_gpio_out_status(bank_id);
+	val = readl(reg_base + reg_offset);
+
+	bcm_kona_gpio_lock_bank(bank_id);
+	spin_unlock_irqrestore(&bcm_kona_gpio.lock, flags);
+
+	/* return the specified bit status */
+	return (val >> bit) & 1;
+}
+
+static int bcm_kona_gpio_direction_input(struct gpio_chip *chip,
+	unsigned gpio)
+{
+	void __iomem *reg_base = bcm_kona_gpio.reg_base;
+	u32 val;
+	unsigned long flags;
+	int bank_id = GPIO_BANK(gpio);
+
+	spin_lock_irqsave(&bcm_kona_gpio.lock, flags);
+	bcm_kona_gpio_unlock_bank(bank_id);
+
+	val = readl(reg_base + bcm_kona_gpio_control(gpio));
+	val &= ~GPIO_GPCTR0_IOTR_MASK;
+	val |= GPIO_GPCTR0_IOTR_CMD_INPUT;
+	writel(val, reg_base + bcm_kona_gpio_control(gpio));
+
+	bcm_kona_gpio_lock_bank(bank_id);
+	spin_unlock_irqrestore(&bcm_kona_gpio.lock, flags);
+
+	return 0;
+}
+
+static int bcm_kona_gpio_direction_output(struct gpio_chip *chip,
+	unsigned gpio, int value)
+{
+	void __iomem *reg_base = bcm_kona_gpio.reg_base;
+	int bank_id = GPIO_BANK(gpio);
+	int bit = GPIO_BIT(gpio);
+	u32 val, reg_offset;
+	unsigned long flags;
+
+	spin_lock_irqsave(&bcm_kona_gpio.lock, flags);
+	bcm_kona_gpio_unlock_bank(bank_id);
+
+	val = readl(reg_base + bcm_kona_gpio_control(gpio));
+	val &= ~GPIO_GPCTR0_IOTR_MASK;
+	val |= GPIO_GPCTR0_IOTR_CMD_0UTPUT;
+	writel(val, reg_base + bcm_kona_gpio_control(gpio));
+	reg_offset = value ? bcm_kona_gpio_out_set(bank_id) :
+				bcm_kona_gpio_out_clear(bank_id);
+
+	val = readl(reg_base + reg_offset);
+	val |= 1 << bit;
+	writel(val, reg_base + reg_offset);
+
+	bcm_kona_gpio_lock_bank(bank_id);
+	spin_unlock_irqrestore(&bcm_kona_gpio.lock, flags);
+
+	return 0;
+}
+
+static int bcm_kona_gpio_to_irq(struct gpio_chip *chip, unsigned gpio)
+{
+	if (gpio >= bcm_gpio_chip.ngpio)
+		return -ENXIO;
+	return irq_create_mapping(bcm_kona_gpio.irq_domain, gpio);
+}
+
+static int bcm_kona_gpio_set_debounce(struct gpio_chip *chip, unsigned gpio,
+	unsigned debounce)
+{
+	void __iomem *reg_base = bcm_kona_gpio.reg_base;
+	u32 val, res;
+	unsigned long flags;
+	int bank_id = GPIO_BANK(gpio);
+
+	/* debounce must be 1-128ms (or 0) */
+	if ((debounce > 0 && debounce < 1000) || debounce > 128000) {
+		dev_err(chip->dev, "Debounce value %u not in range\n",
+			debounce);
+		return -EINVAL;
+	}
+
+	/* calculate debounce bit value */
+	if (debounce != 0) {
+		/* Convert to ms */
+		debounce /= 1000;
+
+		/* find the MSB */
+		res = fls(debounce) - 1;
+
+		/* Check if MSB-1 is set (round up or down) */
+		if (res > 0 && (debounce & 1 << (res - 1)))
+			res++;
+	}
+
+	/* spin lock for read-modify-write of the GPIO register */
+	spin_lock_irqsave(&bcm_kona_gpio.lock, flags);
+	bcm_kona_gpio_unlock_bank(bank_id);
+
+	val = readl(reg_base + bcm_kona_gpio_control(gpio));
+	val &= ~GPIO_GPCTR0_DBR_MASK;
+
+	if (debounce == 0) {
+		/* disable debounce */
+		val &= ~GPIO_GPCTR0_DB_ENABLE_MASK;
+	} else {
+		val |= GPIO_GPCTR0_DB_ENABLE_MASK |
+			  (res << GPIO_GPCTR0_DBR_SHIFT);
+	}
+
+	writel(val, reg_base + bcm_kona_gpio_control(gpio));
+
+	bcm_kona_gpio_lock_bank(bank_id);
+	spin_unlock_irqrestore(&bcm_kona_gpio.lock, flags);
+
+	return 0;
+}
+
+static int bcm_kona_gpio_request(struct gpio_chip *chip, unsigned gpio)
+{
+	struct irq_data d;
+
+	d.hwirq = gpio;
+	bcm_kona_gpio_irq_unmask(&d);
+
+	return 0;
+}
+
+static void bcm_kona_gpio_free(struct gpio_chip *chip, unsigned gpio)
+{
+	struct irq_data d;
+
+	d.hwirq = gpio;
+	bcm_kona_gpio_irq_mask(&d);
+}
+
+static struct gpio_chip bcm_gpio_chip = {
+	.label = "bcm-kona-gpio",
+	.request = bcm_kona_gpio_request,
+	.free = bcm_kona_gpio_free,
+	.direction_input = bcm_kona_gpio_direction_input,
+	.get = bcm_kona_gpio_get,
+	.direction_output = bcm_kona_gpio_direction_output,
+	.set = bcm_kona_gpio_set,
+	.set_debounce = bcm_kona_gpio_set_debounce,
+	.to_irq = bcm_kona_gpio_to_irq,
+	.base = 0,
+};
+
+static void bcm_kona_gpio_irq_ack(struct irq_data *d)
+{
+	int gpio = d->hwirq;
+	int bank_id = GPIO_BANK(gpio);
+	int bit = GPIO_BIT(gpio);
+	void __iomem *reg_base = bcm_kona_gpio.reg_base;
+	u32 val;
+	unsigned long flags;
+
+	spin_lock_irqsave(&bcm_kona_gpio.lock, flags);
+	bcm_kona_gpio_unlock_bank(bank_id);
+
+	val = readl(reg_base + bcm_kona_gpio_int_status(bank_id));
+	val |= 1 << bit;
+	writel(val, reg_base + bcm_kona_gpio_int_status(bank_id));
+
+	bcm_kona_gpio_lock_bank(bank_id);
+	spin_unlock_irqrestore(&bcm_kona_gpio.lock, flags);
+}
+
+static void bcm_kona_gpio_irq_mask(struct irq_data *d)
+{
+	int gpio = d->hwirq;
+	int bank_id = GPIO_BANK(gpio);
+	int bit = GPIO_BIT(gpio);
+	void __iomem *reg_base = bcm_kona_gpio.reg_base;
+	u32 val;
+	unsigned long flags;
+
+	spin_lock_irqsave(&bcm_kona_gpio.lock, flags);
+	bcm_kona_gpio_unlock_bank(bank_id);
+
+	val = readl(reg_base + bcm_kona_gpio_int_mask(bank_id));
+	val |= 1 << bit;
+	writel(val, reg_base + bcm_kona_gpio_int_mask(bank_id));
+
+	bcm_kona_gpio_lock_bank(bank_id);
+	spin_unlock_irqrestore(&bcm_kona_gpio.lock, flags);
+}
+
+static void bcm_kona_gpio_irq_unmask(struct irq_data *d)
+{
+	int gpio = d->hwirq;
+	int bank_id = GPIO_BANK(gpio);
+	int bit = GPIO_BIT(gpio);
+	void __iomem *reg_base = bcm_kona_gpio.reg_base;
+	u32 val;
+	unsigned long flags;
+
+	spin_lock_irqsave(&bcm_kona_gpio.lock, flags);
+	bcm_kona_gpio_unlock_bank(bank_id);
+
+	val = readl(reg_base + bcm_kona_gpio_int_mskclr(bank_id));
+	val |= 1 << bit;
+	writel(val, reg_base + bcm_kona_gpio_int_mskclr(bank_id));
+
+	bcm_kona_gpio_lock_bank(bank_id);
+	spin_unlock_irqrestore(&bcm_kona_gpio.lock, flags);
+}
+
+static int bcm_kona_gpio_irq_set_type(struct irq_data *d, unsigned int type)
+{
+	int gpio = d->hwirq;
+	void __iomem *reg_base = bcm_kona_gpio.reg_base;
+	u32 lvl_type;
+	u32 val;
+	unsigned long flags;
+	int bank_id = GPIO_BANK(gpio);
+
+	switch (type & IRQ_TYPE_SENSE_MASK) {
+	case IRQ_TYPE_EDGE_RISING:
+		lvl_type = GPIO_GPCTR0_ITR_CMD_RISING_EDGE;
+		break;
+
+	case IRQ_TYPE_EDGE_FALLING:
+		lvl_type = GPIO_GPCTR0_ITR_CMD_FALLING_EDGE;
+		break;
+
+	case IRQ_TYPE_EDGE_BOTH:
+		lvl_type = GPIO_GPCTR0_ITR_CMD_BOTH_EDGE;
+		break;
+
+	case IRQ_TYPE_LEVEL_HIGH:
+	case IRQ_TYPE_LEVEL_LOW:
+		/* BCM GPIO doesn't support level triggering */
+	default:
+		dev_err(bcm_gpio_chip.dev, "Invalid BCM GPIO irq type 0x%x\n",
+			type);
+		return -EINVAL;
+	}
+
+	spin_lock_irqsave(&bcm_kona_gpio.lock, flags);
+	bcm_kona_gpio_unlock_bank(bank_id);
+
+	val = readl(reg_base + bcm_kona_gpio_control(gpio));
+	val &= ~GPIO_GPCTR0_ITR_MASK;
+	val |= lvl_type << GPIO_GPCTR0_ITR_SHIFT;
+	writel(val, reg_base + bcm_kona_gpio_control(gpio));
+
+	bcm_kona_gpio_lock_bank(bank_id);
+	spin_unlock_irqrestore(&bcm_kona_gpio.lock, flags);
+
+	return 0;
+}
+
+static void bcm_kona_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
+{
+	int bit, bank_id;
+	void __iomem *reg_base = bcm_kona_gpio.reg_base;
+	unsigned long sta;
+	struct bcm_kona_gpio_bank *bank = irq_get_handler_data(irq);
+	struct irq_chip *chip = irq_desc_get_chip(desc);
+
+	chained_irq_enter(chip, desc);
+
+	bank_id = bank->id;
+	bcm_kona_gpio_unlock_bank(bank_id);
+
+	sta = readl(reg_base + bcm_kona_gpio_int_status(bank_id)) &
+	    (~(readl(reg_base + bcm_kona_gpio_int_mask(bank_id))));
+
+	for_each_set_bit(bit, &sta, 32) {
+		/*
+		 * Clear interrupt before handler is called so we don't
+		 * miss any interrupt occurred during executing them.
+		 */
+		writel(readl(reg_base + bcm_kona_gpio_int_status(bank_id)) |
+				(1 << bit),
+				reg_base + bcm_kona_gpio_int_status(bank_id));
+
+		/* Invoke interrupt handler */
+		generic_handle_irq(gpio_to_irq(GPIO_PER_BANK * bank_id + bit));
+	}
+
+	bcm_kona_gpio_lock_bank(bank_id);
+
+	chained_irq_exit(chip, desc);
+}
+
+static struct irq_chip bcm_gpio_irq_chip = {
+	.name = "bcm-kona-gpio",
+	.irq_ack = bcm_kona_gpio_irq_ack,
+	.irq_mask = bcm_kona_gpio_irq_mask,
+	.irq_unmask = bcm_kona_gpio_irq_unmask,
+	.irq_set_type = bcm_kona_gpio_irq_set_type,
+};
+
+static struct __initconst of_device_id bcm_kona_gpio_of_match[] = {
+	{ .compatible = "brcm,kona-gpio" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, kona_gpio_match);
+
+/*
+ * This lock class tells lockdep that GPIO irqs are in a different
+ * category than their parents, so it won't report false recursion.
+ */
+static struct lock_class_key gpio_lock_class;
+
+static int bcm_kona_gpio_irq_map(struct irq_domain *d, unsigned int virq,
+				irq_hw_number_t hwirq)
+{
+	irq_set_chip_data(virq, &d->host_data);
+	irq_set_lockdep_class(virq, &gpio_lock_class);
+	irq_set_chip_and_handler(virq, &bcm_gpio_irq_chip, handle_simple_irq);
+	irq_set_nested_thread(virq, 1);
+	set_irq_flags(virq, IRQF_VALID);
+
+	return 0;
+}
+
+static void bcm_kona_gpio_irq_unmap(struct irq_domain *d, unsigned int virq)
+{
+	irq_set_chip_and_handler(virq, NULL, NULL);
+	irq_set_chip_data(virq, NULL);
+}
+
+static struct irq_domain_ops bcm_kona_irq_ops = {
+	.map    = bcm_kona_gpio_irq_map,
+	.unmap  = bcm_kona_gpio_irq_unmap,
+	.xlate  = irq_domain_xlate_twocell,
+};
+
+static void bcm_kona_gpio_reset(int num_bank)
+{
+	int i;
+	void __iomem *reg_base = bcm_kona_gpio.reg_base;
+
+	/* disable interrupts and clear status */
+	for (i = 0; i < num_bank; i++) {
+		bcm_kona_gpio_unlock_bank(i);
+		writel(0xFFFFFFFF, reg_base + bcm_kona_gpio_int_mask(i));
+		writel(0xFFFFFFFF, reg_base + bcm_kona_gpio_int_status(i));
+		bcm_kona_gpio_lock_bank(i);
+	}
+}
+
+static int bcm_kona_gpio_probe(struct platform_device *pdev)
+{
+	const struct of_device_id *match;
+	struct resource *res;
+	struct bcm_kona_gpio_bank *bank;
+	int ret;
+	int i;
+
+	match = of_match_device(bcm_kona_gpio_of_match, &pdev->dev);
+	if (!match) {
+		dev_err(&pdev->dev, "Failed to find gpio controller\n");
+		return -ENODEV;
+	}
+
+	bcm_kona_gpio.num_bank = bcm_kona_count_irq_resources(pdev);
+	if (bcm_kona_gpio.num_bank == 0) {
+		dev_err(&pdev->dev, "Couldn't determine # GPIO banks\n");
+		return -ENOENT;
+	}
+	bcm_gpio_chip.of_node = pdev->dev.of_node;
+	bcm_gpio_chip.dev = &pdev->dev;
+	bcm_gpio_chip.ngpio = bcm_kona_gpio.num_bank * GPIO_PER_BANK;
+	bcm_kona_gpio.banks = devm_kzalloc(&pdev->dev,
+				       bcm_kona_gpio.num_bank *
+				       sizeof(*bcm_kona_gpio.banks),
+				       GFP_KERNEL);
+	if (!bcm_kona_gpio.banks) {
+		dev_err(&pdev->dev, "Couldn't allocate bank structure\n");
+		return -ENOMEM;
+	}
+
+	bcm_kona_gpio.irq_base = irq_alloc_descs(-1, 0, bcm_gpio_chip.ngpio,
+						0);
+	if (bcm_kona_gpio.irq_base < 0) {
+		dev_err(&pdev->dev, "Couldn't allocate IRQ numbers\n");
+		return -ENXIO;
+	}
+	bcm_kona_gpio.irq_domain = irq_domain_add_linear(pdev->dev.of_node,
+						bcm_gpio_chip.ngpio,
+						&bcm_kona_irq_ops,
+						&bcm_kona_gpio);
+	if (!bcm_kona_gpio.irq_domain) {
+		dev_err(&pdev->dev, "Couldn't allocate IRQ domain\n");
+		ret = -ENXIO;
+		goto err_irq_descs;
+	}
+	for (i = 0; i < bcm_kona_gpio.num_bank; i++) {
+		bank = &bcm_kona_gpio.banks[i];
+		bank->id = i;
+		bank->irq = platform_get_irq(pdev, i);
+		if (bank->irq < 0) {
+			dev_err(&pdev->dev, "Couldn't get IRQ for bank %d", i);
+			ret = -ENOENT;
+			goto err_irq_domain;
+		}
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(&pdev->dev, "Missing MEM resource\n");
+		ret = -ENXIO;
+		goto err_irq_domain;
+	}
+
+	bcm_kona_gpio.reg_base = devm_request_and_ioremap(&pdev->dev, res);
+	if (!bcm_kona_gpio.reg_base) {
+		dev_err(&pdev->dev, "Couldn't ioremap regs\n");
+		ret = -ENXIO;
+		goto err_irq_domain;
+	}
+	dev_info(&pdev->dev, "Setting up Kona GPIO at 0x%p (phys %#x)\n",
+		bcm_kona_gpio.reg_base, res->start);
+
+	bcm_kona_gpio_reset(bcm_kona_gpio.num_bank);
+
+	ret = gpiochip_add(&bcm_gpio_chip);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Couldn't add GPIO chip -- %d\n", ret);
+		goto err_irq_domain;
+	}
+	for (i = 0; i < bcm_gpio_chip.ngpio; i++) {
+		int irq = bcm_kona_gpio_to_irq(&bcm_gpio_chip, i);
+		bank = &bcm_kona_gpio.banks[GPIO_BANK(i)];
+		irq_set_lockdep_class(irq, &gpio_lock_class);
+		irq_set_chip_data(irq, bank);
+		irq_set_chip_and_handler(irq, &bcm_gpio_irq_chip,
+					 handle_simple_irq);
+		set_irq_flags(irq, IRQF_VALID);
+	}
+	for (i = 0; i < bcm_kona_gpio.num_bank; i++) {
+		bank = &bcm_kona_gpio.banks[i];
+
+		irq_set_chained_handler(bank->irq, bcm_kona_gpio_irq_handler);
+		irq_set_handler_data(bank->irq, bank);
+	}
+
+	spin_lock_init(&bcm_kona_gpio.lock);
+
+	return 0;
+
+err_irq_domain:
+	irq_domain_remove(bcm_kona_gpio.irq_domain);
+
+err_irq_descs:
+	irq_free_descs(bcm_kona_gpio.irq_base, bcm_gpio_chip.ngpio);
+
+	return ret;
+}
+
+static int bcm_kona_gpio_remove(struct platform_device *pdev)
+{
+	int i, ret;
+	struct bcm_kona_gpio_bank *bank;
+
+	for (i = 0; i < bcm_gpio_chip.ngpio; i++)
+		gpio_free(i);
+	ret = gpiochip_remove(&bcm_gpio_chip);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Couldn't remove GPIO chip -- %d\n", ret);
+		return ret;
+	}
+	for (i = 0; i < bcm_kona_gpio.num_bank; i++) {
+		bank = &bcm_kona_gpio.banks[i];
+		irq_set_chained_handler(bank->irq, NULL);
+		irq_set_handler_data(bank->irq, NULL);
+	}
+	irq_domain_remove(bcm_kona_gpio.irq_domain);
+	irq_free_descs(bcm_kona_gpio.irq_base, bcm_gpio_chip.ngpio);
+
+	return 0;
+}
+
+static struct platform_driver bcm_kona_gpio_driver = {
+	.driver = {
+		   .name = "bcm-kona-gpio",
+		   .owner = THIS_MODULE,
+		   .of_match_table = bcm_kona_gpio_of_match,
+		   },
+	.probe = bcm_kona_gpio_probe,
+	.remove = bcm_kona_gpio_remove,
+};
+
+module_platform_driver(bcm_kona_gpio_driver);
+
+MODULE_AUTHOR("Broadcom");
+MODULE_DESCRIPTION("Broadcom Kona GPIO Driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5




From markus.mayer at linaro.org  Fri Jul 26 16:25:44 2013
From: markus.mayer at linaro.org (Markus Mayer)
Date: Fri, 26 Jul 2013 13:25:44 -0700
Subject: [PATCH v3 2/3] ARM: bcm281xx: Device Tree bindings for GPIO
 driver
In-Reply-To: <1374870345-8276-1-git-send-email-markus.mayer@linaro.org>
References: <1374870345-8276-1-git-send-email-markus.mayer@linaro.org>
Message-ID: <1374870345-8276-3-git-send-email-markus.mayer@linaro.org>

Signed-off-by: Markus Mayer <markus.mayer at linaro.org>
Reviewed-by: Christian Daudt <csd at broadcom.com>
Reviewed-by: Tim Kryger <tim.kryger at linaro.org>
Reviewed-by: Matt Porter <matt.porter at linaro.org>
---
 .../devicetree/bindings/gpio/gpio-bcm-kona.txt     |   41 ++++++++++++++++++++
 arch/arm/boot/dts/bcm11351.dtsi                    |   16 ++++++++
 2 files changed, 57 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt b/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt
new file mode 100644
index 0000000..08e9b5a
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt
@@ -0,0 +1,41 @@
+Broadcom Kona Family GPIO
+-------------------------
+
+This GPIO driver is used in the following Broadcom SoCs:
+  BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
+
+The GPIO controller only supports edge, not level triggering.
+
+Required properties:
+  - compatible: "brcm,kona-gpio"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+  - #gpio-cells: Should be <2>. The first cell is the pin number, the second
+    cell is used to specify optional parameters:
+    - bit 0 specifies polarity (0 for normal, 1 for inverted)
+  - #interrupt-cells: Should be <2>. The first cell is the GPIO number.
+    The second cell is used to specify flags:
+    - trigger type (bits[1:0]):
+        1 = low-to-high edge triggered.
+        2 = high-to-low edge triggered.
+        3 = low-to-high or high-to-low edge triggered
+        Valid values are 1, 2, 3
+  - gpio-controller: Marks the device node as a GPIO controller.
+  - interrupt-controller: Marks the device node as an interrupt controller.
+
+Example:
+	gpio: gpio at 35003000 {
+		compatible = "brcm,kona-gpio";
+		reg = <0x35003000 0x800>;
+		interrupts =
+		       <0x0 106 0x4
+			0x0 115 0x4
+			0x0 114 0x4
+			0x0 113 0x4
+			0x0 112 0x4
+			0x0 111 0x4>;
+		#gpio-cells = <2>;
+		#interrupt-cells = <2>;
+		gpio-controller;
+		interrupt-controller;
+	};
diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index c0cdf66..13aaa06 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -63,6 +63,22 @@
 		clock-frequency = <32768>;
 	};
 
+	gpio: gpio at 35003000 {
+		compatible = "brcm,kona-gpio";
+		reg = <0x35003000 0x800>;
+		interrupts =
+		       <0x0 106 0x4
+			0x0 115 0x4
+			0x0 114 0x4
+			0x0 113 0x4
+			0x0 112 0x4
+			0x0 111 0x4>;
+		#gpio-cells = <2>;
+		#interrupt-cells = <2>;
+		gpio-controller;
+		interrupt-controller;
+	};
+
 	sdio0: sdio at 0x3f180000 {
 		compatible = "bcm,kona-sdhci";
 		reg = <0x3f180000 0x10000>;
-- 
1.7.9.5




From markus.mayer at linaro.org  Fri Jul 26 16:25:45 2013
From: markus.mayer at linaro.org (Markus Mayer)
Date: Fri, 26 Jul 2013 13:25:45 -0700
Subject: [PATCH v3 3/3] ARM: bcm281xx: Enable GPIO driver
In-Reply-To: <1374870345-8276-1-git-send-email-markus.mayer@linaro.org>
References: <1374870345-8276-1-git-send-email-markus.mayer@linaro.org>
Message-ID: <1374870345-8276-4-git-send-email-markus.mayer@linaro.org>

This patch adds the Kconfig and Makefile glue to compile the GPIO
driver for bcm281xx when CONFIG_GPIO_BCM=y.

Signed-off-by: Markus Mayer <markus.mayer at linaro.org>
Reviewed-by: Christian Daudt <csd at broadcom.com>
Reviewed-by: Tim Kryger <tim.kryger at linaro.org>
Reviewed-by: Matt Porter <matt.porter at linaro.org>
---
 arch/arm/mach-bcm/Kconfig |    2 +-
 drivers/gpio/Kconfig      |    6 ++++++
 drivers/gpio/Makefile     |    1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index f112895..5819126 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -9,7 +9,7 @@ config ARCH_BCM
 	select CLKSRC_OF
 	select GENERIC_CLOCKEVENTS
 	select GENERIC_TIME
-	select GPIO_BCM
+	select GPIO_BCM_KONA
 	select SPARSE_IRQ
 	select TICK_ONESHOT
 	help
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b2450ba..87d3a23 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -714,6 +714,12 @@ config GPIO_MSIC
 	  Enable support for GPIO on intel MSIC controllers found in
 	  intel MID devices
 
+config GPIO_BCM_KONA
+	bool "Broadcom Kona GPIO"
+	depends on ARCH_BCM
+	help
+	  Turn on GPIO support for Broadcom "Kona" chips.
+
 comment "USB GPIO expanders:"
 
 config GPIO_VIPERBOARD
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index ef3e983..fcd0751 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_GPIO_ADP5520)	+= gpio-adp5520.o
 obj-$(CONFIG_GPIO_ADP5588)	+= gpio-adp5588.o
 obj-$(CONFIG_GPIO_AMD8111)	+= gpio-amd8111.o
 obj-$(CONFIG_GPIO_ARIZONA)	+= gpio-arizona.o
+obj-$(CONFIG_GPIO_BCM_KONA)	+= gpio-bcm-kona.o
 obj-$(CONFIG_GPIO_BT8XX)	+= gpio-bt8xx.o
 obj-$(CONFIG_GPIO_CLPS711X)	+= gpio-clps711x.o
 obj-$(CONFIG_GPIO_CS5535)	+= gpio-cs5535.o
-- 
1.7.9.5




From csd at broadcom.com  Fri Jul 26 16:23:00 2013
From: csd at broadcom.com (Christian Daudt)
Date: Fri, 26 Jul 2013 13:23:00 -0700
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726193908.GX24642@n2100.arm.linux.org.uk>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net>
 <51F29BFE.8000202@broadcom.com>
 <20130726171153.GN29916@titan.lakedaemon.net>
 <51F2AF2D.1000300@broadcom.com>
 <20130726184702.GW24642@n2100.arm.linux.org.uk>
 <51F2C94F.6020405@broadcom.com>
 <20130726193908.GX24642@n2100.arm.linux.org.uk>
Message-ID: <51F2DAA4.2090903@broadcom.com>

On 13-07-26 12:39 PM, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 12:09:03PM -0700, Christian Daudt wrote:
>> On 13-07-26 11:47 AM, Russell King - ARM Linux wrote:
>>> On Fri, Jul 26, 2013 at 10:17:33AM -0700, Christian Daudt wrote:
>>>> Because ARCH_BCM is meant to be used for a number of SoC families. We've
>>>> started upstreaming one (the BCM281XX) but have 2 more internally that
>>>> we're working towards upstreaming. And in the future our plan is to keep
>>>> the Broadcom Mobile SoCs all building under this single ARCH_BCM
>>>> configuration as multiplatform code building a single zImage for them.
>>> 1. We're moving to a single zImage for everything.  Not just Broadcom.
>>> There's no need for Broadcom stuff to be treated any differently.
>>> Participate in the single zImage project and you will get that benefit
>>> without these games.
>> I don't follow what is the game being played.
> I don't really mind what you do, but when you start talking about having
> any ARM build always descend into mach-bcm, then something is very wrong
> with how you're going about it - you don't see anyone else needing that
> in the tree, not even OMAP.
>
> I don't really care if your intention is to decend into mach-bcm and then
> do nothing - that's not the point.  The point is we shouldn't even
> decend into mach-bcm if there's nothing to be built there.
>
Ok, how about creating a ARCH_BROADCOM to select descending into the 
mach-bcm dir, and renaming ARCH_BCM to ARCH_BCMMOBILE, along the lines 
of the attachment ?

  Thanks,
    csd



-------------- next part --------------
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c0ac0f5..cdb6662 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 # Machine directory name.  This list is sorted alphanumerically
 # by CONFIG_* macro name.
 machine-$(CONFIG_ARCH_AT91)		+= at91
-machine-$(CONFIG_ARCH_BCM)		+= bcm
+machine-$(CONFIG_ARCH_BROADCOM)		+= bcm
 machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
 machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
 machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index f112895..0367f94 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -1,4 +1,11 @@
-config ARCH_BCM
+config ARCH_BROADCOM
+	bool "Broadcom Multiplatform SOCs"
+
+if ARCH_BROADCOM
+
+menu  "Broadcom SoC Family"
+
+config ARCH_BCMMOBILE
 	bool "Broadcom SoC" if ARCH_MULTI_V7
 	depends on MMU
 	select ARCH_REQUIRE_GPIOLIB
@@ -13,7 +20,11 @@ config ARCH_BCM
 	select SPARSE_IRQ
 	select TICK_ONESHOT
 	help
-	  This enables support for system based on Broadcom SoCs.
+	  This enables support for systems based on Broadcom mobile SoCs.
 	  It currently supports the 'BCM281XX' family, which includes
 	  BCM11130, BCM11140, BCM11351, BCM28145 and
 	  BCM28155 variants.
+
+endmenu
+
+endif
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 6adb6aec..08f9ebe 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -10,6 +10,6 @@
 # of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 # GNU General Public License for more details.
 
-obj-$(CONFIG_ARCH_BCM)		:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
+obj-$(CONFIG_ARCH_BCMMOBILE)	:= board_bcm.o bcm_kona_smc.o bcm_kona_smc_asm.o
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_bcm_kona_smc_asm.o	:=-Wa,-march=armv7-a$(plus_sec)

From mturquette at linaro.org  Fri Jul 26 16:30:26 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Fri, 26 Jul 2013 13:30:26 -0700
Subject: [PATCH v2] clk: exynos4: Add CLK_GET_RATE_NOCACHE flag for the
 Exynos4x12 ISP clocks
In-Reply-To: <1374786425-6697-1-git-send-email-sylvester.nawrocki@gmail.com>
References: <1374786425-6697-1-git-send-email-sylvester.nawrocki@gmail.com>
Message-ID: <20130726203026.7598.21711@quantum>

Quoting Sylwester Nawrocki (2013-07-25 14:07:05)
> From: Sylwester Nawrocki <s.nawrocki at samsung.com>
> 
> The ISP clock registers belong to the ISP power domain and may change
> their values if this power domain is switched off/on. Add
> CLK_GET_RATE_NOCACHE flags to ensure we do not rely on invalid cached
> data when setting or getting frequency of those clocks.
> 
> Signed-off-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>

Thanks for the fix. I've taken into clk-fixes. Is there a specific
regression this fixes (besides just having wrong clock rates). I can
amend the changelog if you have an example (e.g. device X explodes).

Regards,
Mike

> ---
> 
> Rebased onto v3.11-rc2.
> 
>  drivers/clk/samsung/clk-exynos4.c |   64 +++++++++++++++++++-----------------
>  1 files changed, 34 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
> index 1bdb882..4e57397 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -581,11 +581,15 @@ struct samsung_div_clock exynos4x12_div_clks[] __initdata = {
>         DIV(none, "div_spi1_isp", "mout_spi1_isp", E4X12_DIV_ISP, 16, 4),
>         DIV(none, "div_spi1_isp_pre", "div_spi1_isp", E4X12_DIV_ISP, 20, 8),
>         DIV(none, "div_uart_isp", "mout_uart_isp", E4X12_DIV_ISP, 28, 4),
> -       DIV(div_isp0, "div_isp0", "aclk200", E4X12_DIV_ISP0, 0, 3),
> -       DIV(div_isp1, "div_isp1", "aclk200", E4X12_DIV_ISP0, 4, 3),
> +       DIV_F(div_isp0, "div_isp0", "aclk200", E4X12_DIV_ISP0, 0, 3,
> +                                               CLK_GET_RATE_NOCACHE, 0),
> +       DIV_F(div_isp1, "div_isp1", "aclk200", E4X12_DIV_ISP0, 4, 3,
> +                                               CLK_GET_RATE_NOCACHE, 0),
>         DIV(none, "div_mpwm", "div_isp1", E4X12_DIV_ISP1, 0, 3),
> -       DIV(div_mcuisp0, "div_mcuisp0", "aclk400_mcuisp", E4X12_DIV_ISP1, 4, 3),
> -       DIV(div_mcuisp1, "div_mcuisp1", "div_mcuisp0", E4X12_DIV_ISP1, 8, 3),
> +       DIV_F(div_mcuisp0, "div_mcuisp0", "aclk400_mcuisp", E4X12_DIV_ISP1,
> +                                               4, 3, CLK_GET_RATE_NOCACHE, 0),
> +       DIV_F(div_mcuisp1, "div_mcuisp1", "div_mcuisp0", E4X12_DIV_ISP1,
> +                                               8, 3, CLK_GET_RATE_NOCACHE, 0),
>         DIV(sclk_fimg2d, "sclk_fimg2d", "mout_g2d", DIV_DMC1, 0, 4),
>  };
> 
> @@ -863,57 +867,57 @@ struct samsung_gate_clock exynos4x12_gate_clks[] __initdata = {
>         GATE_DA(i2s0, "samsung-i2s.0", "i2s0", "aclk100",
>                         E4X12_GATE_IP_MAUDIO, 3, 0, 0, "iis"),
>         GATE(fimc_isp, "isp", "aclk200", E4X12_GATE_ISP0, 0,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(fimc_drc, "drc", "aclk200", E4X12_GATE_ISP0, 1,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(fimc_fd, "fd", "aclk200", E4X12_GATE_ISP0, 2,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(fimc_lite0, "lite0", "aclk200", E4X12_GATE_ISP0, 3,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(fimc_lite1, "lite1", "aclk200", E4X12_GATE_ISP0, 4,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(mcuisp, "mcuisp", "aclk200", E4X12_GATE_ISP0, 5,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(gicisp, "gicisp", "aclk200", E4X12_GATE_ISP0, 7,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(smmu_isp, "smmu_isp", "aclk200", E4X12_GATE_ISP0, 8,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(smmu_drc, "smmu_drc", "aclk200", E4X12_GATE_ISP0, 9,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(smmu_fd, "smmu_fd", "aclk200", E4X12_GATE_ISP0, 10,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(smmu_lite0, "smmu_lite0", "aclk200", E4X12_GATE_ISP0, 11,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(smmu_lite1, "smmu_lite1", "aclk200", E4X12_GATE_ISP0, 12,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(ppmuispmx, "ppmuispmx", "aclk200", E4X12_GATE_ISP0, 20,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(ppmuispx, "ppmuispx", "aclk200", E4X12_GATE_ISP0, 21,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(mcuctl_isp, "mcuctl_isp", "aclk200", E4X12_GATE_ISP0, 23,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(mpwm_isp, "mpwm_isp", "aclk200", E4X12_GATE_ISP0, 24,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(i2c0_isp, "i2c0_isp", "aclk200", E4X12_GATE_ISP0, 25,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(i2c1_isp, "i2c1_isp", "aclk200", E4X12_GATE_ISP0, 26,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(mtcadc_isp, "mtcadc_isp", "aclk200", E4X12_GATE_ISP0, 27,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(pwm_isp, "pwm_isp", "aclk200", E4X12_GATE_ISP0, 28,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(wdt_isp, "wdt_isp", "aclk200", E4X12_GATE_ISP0, 30,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(uart_isp, "uart_isp", "aclk200", E4X12_GATE_ISP0, 31,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(asyncaxim, "asyncaxim", "aclk200", E4X12_GATE_ISP1, 0,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(smmu_ispcx, "smmu_ispcx", "aclk200", E4X12_GATE_ISP1, 4,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(spi0_isp, "spi0_isp", "aclk200", E4X12_GATE_ISP1, 12,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(spi1_isp, "spi1_isp", "aclk200", E4X12_GATE_ISP1, 13,
> -                       CLK_IGNORE_UNUSED, 0),
> +                       CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
>         GATE(g2d, "g2d", "aclk200", GATE_IP_DMC, 23, 0, 0),
>  };
> 
> --
> 1.7.4.1


From dinguyen at altera.com  Fri Jul 26 16:44:54 2013
From: dinguyen at altera.com (Dinh Nguyen)
Date: Fri, 26 Jul 2013 15:44:54 -0500
Subject: [PATCH] ARM: socfpga: dts: Add support for SD/MMC
In-Reply-To: <51F2D5EA.7050108@wwwdotorg.org>
References: <1374789881-20611-1-git-send-email-dinguyen@altera.com>
 <51F2B0C4.8000301@wwwdotorg.org> <1374867220.20685.44.camel@linux-builds1>
 <51F2D5EA.7050108@wwwdotorg.org>
Message-ID: <1374871494.20685.46.camel@linux-builds1>

On Fri, 2013-07-26 at 14:02 -0600, Stephen Warren wrote:
> On 07/26/2013 01:33 PM, Dinh Nguyen wrote:
> > On Fri, 2013-07-26 at 11:24 -0600, Stephen Warren wrote:
> >> On 07/25/2013 04:04 PM, dinguyen at altera.com wrote:
> >>> From: Dinh Nguyen <dinguyen at altera.com>
> >>>
> >>> Add bindings for SD/MMC for SOCFPGA.
> >>> Add "syscon" to the "altr,sys-mgr" binding.
> 
> >>> diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
> 
> >>> +Example:
> >>> +
> >>> +  The MSHC controller node can be split into two portions, SoC specific and
> >>> +  board specific portions, as listed below.
> >>
> >> That doesn't sound like a good idea. There should be one DT node for
> >> each logical block. The internal construction of the Linux drivers
> >> (presumably you have entirely separate code to handle the two nodes in
> >> Linux so far?) should not influence the DT construction at all.
> > 
> > In the end, there is only 1 DT node for each logical block:
> 
> Oh right, I see you were intending to show the distinction between the
> SoC .dtsi and board .dts file. I hadn't realized that. I don't think
> it's common to do that in the examples, so I would recommend just
> merging the whole example together myself.

I'll merge it.

> 
> > dwmmc0 at ff704000 {
> > 	compatible = "altr,socfpga-dw-mshc";
> 
> That should include the baseline synopsis compatible value too.

We don't need the baseline synopsis compatible because of
dw_mci_pltfm_register() call.

Thanks,
Dinh
> 
> > 	reg = <0xff704000 0x00001000>;
> > 	interrupts = <0x00000000 0x0000008b 0x00000004>;
> > 	fifo-depth = <0x00000400>;
> > 	#address-cells = <0x00000001>;
> > 	#size-cells = <0x00000000>;
> > 	clocks = <0x00000016 0x00000017>;
> > 	clock-names = "biu", "ciu";
> > 	num-slots = <0x00000001>;
> > 	supports-highspeed;
> > 	broken-cd;
> >  	altr,dw-mshc-ciu-div = <0x00000003>;
> >   	altr,dw-mshc-sdr-timing = <0x00000000 0x00000003>;
> > 	slot at 0 {
> > 		reg = <0x00000000>;
> > 		bus-width = <0x00000004>;
> > 		};
> > 	};
> 
> 





From vivien.didelot at savoirfairelinux.com  Fri Jul 26 16:59:19 2013
From: vivien.didelot at savoirfairelinux.com (Vivien Didelot)
Date: Fri, 26 Jul 2013 16:59:19 -0400 (EDT)
Subject: [RFC] ARM: davinci: da850: add a few pinmux definitions
In-Reply-To: <51F0F377.1060204@ti.com>
Message-ID: <55770703.973667.1374872359591.JavaMail.root@mail>

Hi Sekhar,

You wrote:
> Why do you need to add these definitions? If it is for a new platform
> you are working on, then it should be supported using DT, in which
> case
> we use the pinctrl-single driver and define the muxing needed in
> .dts/.dtsi files.

Ok, good to know.

Thanks,
Vivien


From ben.dooks at codethink.co.uk  Fri Jul 26 17:05:43 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Fri, 26 Jul 2013 22:05:43 +0100
Subject: [PATCH v11] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <1374834384-8071-1-git-send-email-p.zabel@pengutronix.de>
References: <1374834384-8071-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <51F2E4A7.1040200@codethink.co.uk>

On 26/07/13 11:26, Philipp Zabel wrote:
> This driver implements a reset controller device that toggle a gpio
> connected to a reset pin of a peripheral IC. The delay between assertion
> and de-assertion of the reset signal can be configured via device tree.
>
> Signed-off-by: Philipp Zabel<p.zabel at pengutronix.de>
> Reviewed-by: Stephen Warren<swarren at nvidia.com>

[snip]

> +static struct of_device_id gpio_reset_dt_ids[] = {
> +	{ .compatible = "gpio-reset" },
> +	{ }
> +};

I think you need the following:
MODULE_DEVICE_TABLE(of, gpio_reset_dt_ids);

> +static struct platform_driver gpio_reset_driver = {
> +	.probe = gpio_reset_probe,
> +	.remove = gpio_reset_remove,
> +	.driver = {
> +		.name = "gpio-reset",
> +		.owner = THIS_MODULE,
> +		.of_match_table = of_match_ptr(gpio_reset_dt_ids),
> +	},
> +};
> +
> +module_platform_driver(gpio_reset_driver);
> +
> +MODULE_AUTHOR("Philipp Zabel<p.zabel at pengutronix.de>");
> +MODULE_DESCRIPTION("gpio reset controller");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:gpio-reset");
> +MODULE_DEVICE_TABLE(of, gpio_reset_dt_ids);


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From soren.brinkmann at xilinx.com  Fri Jul 26 17:11:52 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Fri, 26 Jul 2013 14:11:52 -0700
Subject: Zynq clk fixes
In-Reply-To: <20130726200703.7598.86150@quantum>
References: <51F26716.6030701@monstr.eu>
 <20130726200703.7598.86150@quantum>
Message-ID: <a76b3a5d-dadc-43b3-87ee-3c65258c15d7@CO1EHSMHS029.ehs.local>

On Fri, Jul 26, 2013 at 01:07:03PM -0700, Mike Turquette wrote:
> Quoting Michal Simek (2013-07-26 05:09:58)
> > Hi Mike, [cc: Arnd and Olof]
> > 
> > Soren has found two bug fixes in zynq clk code.
> > Can you please add these two patches to your tree?
> > Will be great if you can add them to v3.11.
> > 
> > Arnd, Olof: I expect that all these clock changes should go through Mike.
> > If I am wrong please let me know.
> 
> Looks right to me. Do these fix regressions in the current -rc cycle?

I doubt there are real regressions. But since it's still early in
the release cycle and the driver was added in this merge window, I'd prefer
having it hit a release kernel with these fixes included.

	S?ren




From swarren at wwwdotorg.org  Fri Jul 26 17:13:01 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 15:13:01 -0600
Subject: [PATCH] ARM: socfpga: dts: Add support for SD/MMC
In-Reply-To: <1374871494.20685.46.camel@linux-builds1>
References: <1374789881-20611-1-git-send-email-dinguyen@altera.com>
 <51F2B0C4.8000301@wwwdotorg.org> <1374867220.20685.44.camel@linux-builds1>
 <51F2D5EA.7050108@wwwdotorg.org> <1374871494.20685.46.camel@linux-builds1>
Message-ID: <51F2E65D.8090705@wwwdotorg.org>

On 07/26/2013 02:44 PM, Dinh Nguyen wrote:
> On Fri, 2013-07-26 at 14:02 -0600, Stephen Warren wrote:
>> On 07/26/2013 01:33 PM, Dinh Nguyen wrote:
>>> On Fri, 2013-07-26 at 11:24 -0600, Stephen Warren wrote:
>>>> On 07/25/2013 04:04 PM, dinguyen at altera.com wrote:
>>>>> From: Dinh Nguyen <dinguyen at altera.com>
>>>>>
>>>>> Add bindings for SD/MMC for SOCFPGA.
>>>>> Add "syscon" to the "altr,sys-mgr" binding.
>>
>>>>> diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
>>
>>>>> +Example:
>>>>> +
>>>>> +  The MSHC controller node can be split into two portions, SoC specific and
>>>>> +  board specific portions, as listed below.
>>>>
>>>> That doesn't sound like a good idea. There should be one DT node for
>>>> each logical block. The internal construction of the Linux drivers
>>>> (presumably you have entirely separate code to handle the two nodes in
>>>> Linux so far?) should not influence the DT construction at all.
>>>
>>> In the end, there is only 1 DT node for each logical block:
>>
>> Oh right, I see you were intending to show the distinction between the
>> SoC .dtsi and board .dts file. I hadn't realized that. I don't think
>> it's common to do that in the examples, so I would recommend just
>> merging the whole example together myself.
> 
> I'll merge it.
> 
>>
>>> dwmmc0 at ff704000 {
>>> 	compatible = "altr,socfpga-dw-mshc";
>>
>> That should include the baseline synopsis compatible value too.
> 
> We don't need the baseline synopsis compatible because of
> dw_mci_pltfm_register() call.

It's not a matter of whether it's strictly necessary for the SW to work
right now. The compatible property should include entries for everything
that the HW is actually compatible with.

Of course, if a plain driver for the raw synopsis controller/binding
wouldn't actually work on this HW at all, without explicit knowledge of
the extra details of the more HW-specific binding, then that's a good
argument for leaving it out of compatible.


From dinguyen at altera.com  Fri Jul 26 17:22:20 2013
From: dinguyen at altera.com (Dinh Nguyen)
Date: Fri, 26 Jul 2013 16:22:20 -0500
Subject: [PATCH] ARM: socfpga: dts: Add support for SD/MMC
In-Reply-To: <51F2E65D.8090705@wwwdotorg.org>
References: <1374789881-20611-1-git-send-email-dinguyen@altera.com>
 <51F2B0C4.8000301@wwwdotorg.org> <1374867220.20685.44.camel@linux-builds1>
 <51F2D5EA.7050108@wwwdotorg.org> <1374871494.20685.46.camel@linux-builds1>
 <51F2E65D.8090705@wwwdotorg.org>
Message-ID: <1374873740.20685.58.camel@linux-builds1>

On Fri, 2013-07-26 at 15:13 -0600, Stephen Warren wrote:
> On 07/26/2013 02:44 PM, Dinh Nguyen wrote:
> > On Fri, 2013-07-26 at 14:02 -0600, Stephen Warren wrote:
> >> On 07/26/2013 01:33 PM, Dinh Nguyen wrote:
> >>> On Fri, 2013-07-26 at 11:24 -0600, Stephen Warren wrote:
> >>>> On 07/25/2013 04:04 PM, dinguyen at altera.com wrote:
> >>>>> From: Dinh Nguyen <dinguyen at altera.com>
> >>>>>
> >>>>> Add bindings for SD/MMC for SOCFPGA.
> >>>>> Add "syscon" to the "altr,sys-mgr" binding.
> >>
> >>>>> diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
> >>
> >>>>> +Example:
> >>>>> +
> >>>>> +  The MSHC controller node can be split into two portions, SoC specific and
> >>>>> +  board specific portions, as listed below.
> >>>>
> >>>> That doesn't sound like a good idea. There should be one DT node for
> >>>> each logical block. The internal construction of the Linux drivers
> >>>> (presumably you have entirely separate code to handle the two nodes in
> >>>> Linux so far?) should not influence the DT construction at all.
> >>>
> >>> In the end, there is only 1 DT node for each logical block:
> >>
> >> Oh right, I see you were intending to show the distinction between the
> >> SoC .dtsi and board .dts file. I hadn't realized that. I don't think
> >> it's common to do that in the examples, so I would recommend just
> >> merging the whole example together myself.
> > 
> > I'll merge it.
> > 
> >>
> >>> dwmmc0 at ff704000 {
> >>> 	compatible = "altr,socfpga-dw-mshc";
> >>
> >> That should include the baseline synopsis compatible value too.
> > 
> > We don't need the baseline synopsis compatible because of
> > dw_mci_pltfm_register() call.
> 
> It's not a matter of whether it's strictly necessary for the SW to work
> right now. The compatible property should include entries for everything
> that the HW is actually compatible with.

Ah ok..will add the baseline compatible binding. But this also sounds
like there's clean-up work that can be done that I have already
_promised_ Pawell I would do for the next cycle. Along with finding
common attributes for the clocks, I think we can also move all the
platform compatible entries into a single of_device_id struct.

Dinh

> 
> Of course, if a plain driver for the raw synopsis controller/binding
> wouldn't actually work on this HW at all, without explicit knowledge of
> the extra details of the more HW-specific binding, then that's a good
> argument for leaving it out of compatible.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 





From sylvester.nawrocki at gmail.com  Fri Jul 26 17:30:01 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Fri, 26 Jul 2013 23:30:01 +0200
Subject: [PATCH v11] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <51F2E4A7.1040200@codethink.co.uk>
References: <1374834384-8071-1-git-send-email-p.zabel@pengutronix.de>
 <51F2E4A7.1040200@codethink.co.uk>
Message-ID: <51F2EA59.8010908@gmail.com>

On 07/26/2013 11:05 PM, Ben Dooks wrote:
> On 26/07/13 11:26, Philipp Zabel wrote:
>> This driver implements a reset controller device that toggle a gpio
>> connected to a reset pin of a peripheral IC. The delay between assertion
>> and de-assertion of the reset signal can be configured via device tree.
>>
>> Signed-off-by: Philipp Zabel<p.zabel at pengutronix.de>
>> Reviewed-by: Stephen Warren<swarren at nvidia.com>
>
> [snip]
>
>> +static struct of_device_id gpio_reset_dt_ids[] = {
>> + { .compatible = "gpio-reset" },
>> + { }
>> +};
>
> I think you need the following:
> MODULE_DEVICE_TABLE(of, gpio_reset_dt_ids);

It's already there, at bottom of the file. But if I'm not mistaken
the common practice is to keep it together with the actual array
definition. At least that's the case with, e.g. EXPORT_SYMBOL*.

>> +static struct platform_driver gpio_reset_driver = {
>> + .probe = gpio_reset_probe,
>> + .remove = gpio_reset_remove,
>> + .driver = {
>> + .name = "gpio-reset",
>> + .owner = THIS_MODULE,
>> + .of_match_table = of_match_ptr(gpio_reset_dt_ids),
>> + },
>> +};
>> +
>> +module_platform_driver(gpio_reset_driver);
>> +
>> +MODULE_AUTHOR("Philipp Zabel<p.zabel at pengutronix.de>");
>> +MODULE_DESCRIPTION("gpio reset controller");

nit: shouldn't gpio be capitalized ?

>> +MODULE_LICENSE("GPL");
>> +MODULE_ALIAS("platform:gpio-reset");
>> +MODULE_DEVICE_TABLE(of, gpio_reset_dt_ids);

--
Regards,
Sylwester


From zubair.lutfullah at gmail.com  Fri Jul 26 17:37:10 2013
From: zubair.lutfullah at gmail.com (Zubair Lutfullah)
Date: Fri, 26 Jul 2013 22:37:10 +0100
Subject: [PATCH] mfd: input: arm: dts: doc: ti_am335x: typo fixes (coordiante
 -> coordinate)
In-Reply-To: <1374874630-25457-1-git-send-email-zubair.lutfullah@gmail.com>
References: <1374874630-25457-1-git-send-email-zubair.lutfullah@gmail.com>
Message-ID: <1374874630-25457-2-git-send-email-zubair.lutfullah@gmail.com>

Did a grep for 'coordiante' and replaced them all with 'coordinate'

Signed-off-by: Zubair Lutfullah <zubair.lutfullah at gmail.com>
Acked-by: Lee Jones <lee.jones at linaro.org>
---
 .../bindings/input/touchscreen/ti-tsc-adc.txt      |    4 ++--
 arch/arm/boot/dts/am335x-evm.dts                   |    2 +-
 drivers/input/touchscreen/ti_am335x_tsc.c          |    2 +-
 drivers/mfd/ti_am335x_tscadc.c                     |    2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
index 491c97b..3e22aec 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -6,7 +6,7 @@ Required properties:
 	ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen
 		  support on the platform.
 	ti,x-plate-resistance: X plate resistance
-	ti,coordiante-readouts: The sequencer supports a total of 16
+	ti,coordinate-readouts: The sequencer supports a total of 16
 				programmable steps each step is used to
 				read a single coordinate. A single
                                 readout is enough but multiple reads can
@@ -34,7 +34,7 @@ Example:
 		tsc {
 			ti,wires = <4>;
 			ti,x-plate-resistance = <200>;
-			ti,coordiante-readouts = <5>;
+			ti,coordinate-readouts = <5>;
 			ti,wire-config = <0x00 0x11 0x22 0x33>;
 		};
 
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 0fa4c7f..e50b781 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -250,7 +250,7 @@
 	tsc {
 		ti,wires = <4>;
 		ti,x-plate-resistance = <200>;
-		ti,coordiante-readouts = <5>;
+		ti,coordinate-readouts = <5>;
 		ti,wire-config = <0x00 0x11 0x22 0x33>;
 	};
 
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c
index 0e9f02a..6422f65 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -348,7 +348,7 @@ static int titsc_parse_dt(struct platform_device *pdev,
 	if (err < 0)
 		return err;
 
-	err = of_property_read_u32(node, "ti,coordiante-readouts",
+	err = of_property_read_u32(node, "ti,coordinate-readouts",
 			&ts_dev->coordinate_readouts);
 	if (err < 0)
 		return err;
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index cd74d59..1686ae6 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -106,7 +106,7 @@ static	int ti_tscadc_probe(struct platform_device *pdev)
 
 	node = of_get_child_by_name(pdev->dev.of_node, "tsc");
 	of_property_read_u32(node, "ti,wires", &tsc_wires);
-	of_property_read_u32(node, "ti,coordiante-readouts", &readouts);
+	of_property_read_u32(node, "ti,coordinate-readouts", &readouts);
 
 	node = of_get_child_by_name(pdev->dev.of_node, "adc");
 	of_property_for_each_u32(node, "ti,adc-channels", prop, cur, val) {
-- 
1.7.9.5



From zubair.lutfullah at gmail.com  Fri Jul 26 17:37:09 2013
From: zubair.lutfullah at gmail.com (Zubair Lutfullah)
Date: Fri, 26 Jul 2013 22:37:09 +0100
Subject: [PATCH] mfd: input: arm: dts: doc: ti_am335x: typo fix (coordiante ->
 coordinate)
Message-ID: <1374874630-25457-1-git-send-email-zubair.lutfullah@gmail.com>

 
Small typo fix. Received ack from mfd already.
Awaiting acks from all the rest.

As Lee from mfd stated, we can remove these during staging now.
or we'll have to leave typos as is later on.

Zubair Lutfullah (1):
  mfd: input: arm: dts: doc: ti_am335x: typo fixes (coordiante ->
    coordinate)

 .../bindings/input/touchscreen/ti-tsc-adc.txt      |    4 ++--
 arch/arm/boot/dts/am335x-evm.dts                   |    2 +-
 drivers/input/touchscreen/ti_am335x_tsc.c          |    2 +-
 drivers/mfd/ti_am335x_tscadc.c                     |    2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

-- 
1.7.9.5



From festevam at gmail.com  Fri Jul 26 17:55:48 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 26 Jul 2013 18:55:48 -0300
Subject: [PATCH] ARM: dts: imx53-qsb: Make USBH1 functional
In-Reply-To: <87ehalunfx.fsf@lebrac.rtp-net.org>
References: <1374787113-6628-1-git-send-email-fabio.estevam@freescale.com>
 <87ehalunfx.fsf@lebrac.rtp-net.org>
Message-ID: <CAOMZO5DRd097fKfbnQJY1rtGosnqP5FK=5ZxrzJcH-CSwweWsA@mail.gmail.com>

Hi Arnaud,

On Fri, Jul 26, 2013 at 4:32 PM, Arnaud Patard
<arnaud.patard at rtp-net.org> wrote:
> Fabio Estevam <fabio.estevam at freescale.com> writes:
> Hi,
>
> [...]
>
>> @@ -302,7 +312,9 @@
>>  };
>>
>>  &usbh1 {
>> -       status = "okay";
>> +     vbus-supply = <&reg_usb_vbus>;
>> +     phy_type = "utmi";
>> +     status = "okay";
>>  };
>>
>>  &usbotg {
>
> why not putting the vbus supply on the otg node too ?

I think it would be better to use the otg port as peripheral mode
(after Peter Chen's patches get accepted), so that's why I did not
place the regulatoe into the otg node.

If I recall correctly usb role switch does not work on this board, so
better to use peripheral on otg port and host in USBH1.

Regards,

Fabio Estevam


From cavokz at gmail.com  Fri Jul 26 17:59:00 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Fri, 26 Jul 2013 23:59:00 +0200
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726152918.GL29916@titan.lakedaemon.net>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net>
Message-ID: <20130726215859.GA19469@glitch>

On Fri, Jul 26, 2013 at 11:29:18AM -0400, Jason Cooper wrote:
> On Fri, Jul 26, 2013 at 04:56:40PM +0200, Domenico Andreoli wrote:
> > From: Domenico Andreoli <domenico.andreoli at linux.com>
> > 
> > arch/arm/mach-bcm contains a plurality of Broadcom SoCs, each configured
> > separately. As a matter of flexibility and maintenance, it needs to be
> > always included in the build.
> 
> So if I'm building mach-kirkwood, I _have_ to build Broadcom?  What is
> the *specific* problem you're encountering that this solves?

In mach-bcm we (or I, it's not very clear to me) want to have support for
multiple SoCs.

In trying the approach

machine-$(CONFIG_ARCH_BCM)		+= bcm
machine-$(CONFIG_ARCH_BCM4760)		+= bcm

I got linker complains about multiple symbol definitiion in case both the
config options are selected.

The first thought was to use a common option which purpose was only to
include the subdir but then, given my allergy to the tons of config options
with usually not straghtforward purpose, I opted for something more simple.

> 
> Notice:
> 
> $ git grep '^machine-y'
> $
> 
> thx,
> 
> Jason.
> 
> > Cc: Christian Daudt <csd at broadcom.com>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Signed-off-by: Domenico Andreoli <domenico.andreoli at linux.com>
> > ---
> >  arch/arm/Makefile |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Index: b/arch/arm/Makefile
> > ===================================================================
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -145,7 +145,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x0020
> >  # Machine directory name.  This list is sorted alphanumerically
> >  # by CONFIG_* macro name.
> >  machine-$(CONFIG_ARCH_AT91)		+= at91
> > -machine-$(CONFIG_ARCH_BCM)		+= bcm
> > +machine-y				+= bcm
> >  machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
> >  machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
> >  machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
> > 
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From sylvester.nawrocki at gmail.com  Fri Jul 26 18:04:30 2013
From: sylvester.nawrocki at gmail.com (Sylwester Nawrocki)
Date: Sat, 27 Jul 2013 00:04:30 +0200
Subject: [PATCH v2] clk: exynos4: Add CLK_GET_RATE_NOCACHE flag for the
 Exynos4x12 ISP clocks
In-Reply-To: <20130726203026.7598.21711@quantum>
References: <1374786425-6697-1-git-send-email-sylvester.nawrocki@gmail.com>
 <20130726203026.7598.21711@quantum>
Message-ID: <51F2F26E.4090909@gmail.com>

On 07/26/2013 10:30 PM, Mike Turquette wrote:
> Quoting Sylwester Nawrocki (2013-07-25 14:07:05)
>> From: Sylwester Nawrocki<s.nawrocki at samsung.com>
>>
>> The ISP clock registers belong to the ISP power domain and may change
>> their values if this power domain is switched off/on. Add
>> CLK_GET_RATE_NOCACHE flags to ensure we do not rely on invalid cached
>> data when setting or getting frequency of those clocks.
>>
>> Signed-off-by: Sylwester Nawrocki<s.nawrocki at samsung.com>
>> Signed-off-by: Kyungmin Park<kyungmin.park at samsung.com>
>
> Thanks for the fix. I've taken into clk-fixes. Is there a specific
> regression this fixes (besides just having wrong clock rates). I can
> amend the changelog if you have an example (e.g. device X explodes).

Hmm, yes, this fixes a pretty serious problem. There is a companion
commit [1] already in Linus' tree, more details can be found there.

Perhaps something like this could be added:

"Otherwise the FIMC-IS Cortex-A5 core and AXI bus clocks have
incorrect frequencies, which breaks the ISP operation and starting
the video pipeline fails with timeouts reported by the FIMC-IS
firmware.

See related commit 722a860ecb29aa34ec6f7d7f32b949209e8
"[media] exynos4-is: Fix FIMC-IS clocks initialization" for more
details."

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=722a860ecb29aa34ec6f7d7f32b949209e86a2f3

Thanks,
Sylwester


From davidb at codeaurora.org  Fri Jul 26 18:05:22 2013
From: davidb at codeaurora.org (David Brown)
Date: Fri, 26 Jul 2013 15:05:22 -0700
Subject: [GIT PULL] msm gpio fixes for 3.11
Message-ID: <1374876322-2222-1-git-send-email-davidb@codeaurora.org>

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git tags/msm-3.11-fix1

for you to fetch changes up to 8fd62389a778c902c7e8532594ea924bbaf465e8:

  ARM: msm: Consolidate gpiomux for older architectures (2013-07-26 14:55:38 -0700)

----------------------------------------------------------------
Fixes for MSM for 3.11

Two small fixes for MSM.

The first fixes the a gpio controller register address.  I didn't see
any acks from the devicetree maintainers, so I've copied them on this
pull request.  The change itself is minor, and just to the register
address.

The second change removes the gpiomux V1 code from MSM.  This was
breaking compilation for some of the targets.

----------------------------------------------------------------
Rohit Vaswani (2):
      ARM: msm: dts: Fix the gpio register address for msm8960
      ARM: msm: Consolidate gpiomux for older architectures

 arch/arm/boot/dts/msm8960-cdp.dts |  4 ++--
 arch/arm/mach-msm/Kconfig         |  3 +--
 arch/arm/mach-msm/gpiomux-v1.c    | 33 ---------------------------------
 arch/arm/mach-msm/gpiomux.h       | 10 ----------
 4 files changed, 3 insertions(+), 47 deletions(-)
 delete mode 100644 arch/arm/mach-msm/gpiomux-v1.c


From swarren at wwwdotorg.org  Fri Jul 26 18:08:59 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 16:08:59 -0600
Subject: [PATCH v3 2/3] ARM: bcm281xx: Device Tree bindings for GPIO driver
In-Reply-To: <1374870345-8276-3-git-send-email-markus.mayer@linaro.org>
References: <1374870345-8276-1-git-send-email-markus.mayer@linaro.org>
 <1374870345-8276-3-git-send-email-markus.mayer@linaro.org>
Message-ID: <51F2F37B.8030306@wwwdotorg.org>

(CC'ing the DT bindings maintainers hence quoting the binding in full)

On 07/26/2013 02:25 PM, Markus Mayer wrote:

Some kind of patch description is always useful.

>  .../devicetree/bindings/gpio/gpio-bcm-kona.txt     |   41 ++++++++++++++++++++
>  arch/arm/boot/dts/bcm11351.dtsi                    |   16 ++++++++

It's more usual to put the DT binding doc change and driver change in
one patch, then "make use of that" in a later separate patch which edits
*.dts and *.dtsi.

> diff --git a/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt b/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt

> +Broadcom Kona Family GPIO
> +-------------------------
> +
> +This GPIO driver is used in the following Broadcom SoCs:
> +  BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
> +
> +The GPIO controller only supports edge, not level triggering.

add "... of interrupts"? This might not be worth mentioning; it's
clearly spelled out in the description of the interrupt cells below.

> +Required properties:
> +  - compatible: "brcm,kona-gpio"
> +  - reg: Physical base address and length of the controller's registers.
> +  - interrupts: The interrupt outputs from the controller.

How many entries are required? I notice there's more than 1 in the
example below.

> +  - #gpio-cells: Should be <2>. The first cell is the pin number, the second
> +    cell is used to specify optional parameters:
> +    - bit 0 specifies polarity (0 for normal, 1 for inverted)
> +  - #interrupt-cells: Should be <2>. The first cell is the GPIO number.
> +    The second cell is used to specify flags:
> +    - trigger type (bits[1:0]):
> +        1 = low-to-high edge triggered.
> +        2 = high-to-low edge triggered.
> +        3 = low-to-high or high-to-low edge triggered
> +        Valid values are 1, 2, 3
> +  - gpio-controller: Marks the device node as a GPIO controller.
> +  - interrupt-controller: Marks the device node as an interrupt controller.
> +
> +Example:
> +	gpio: gpio at 35003000 {
> +		compatible = "brcm,kona-gpio";
> +		reg = <0x35003000 0x800>;
> +		interrupts =
> +		       <0x0 106 0x4
> +			0x0 115 0x4
> +			0x0 114 0x4
> +			0x0 113 0x4
> +			0x0 112 0x4
> +			0x0 111 0x4>;
> +		#gpio-cells = <2>;
> +		#interrupt-cells = <2>;
> +		gpio-controller;
> +		interrupt-controller;
> +	};

> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi

> +	gpio: gpio at 35003000 {
> +		compatible = "brcm,kona-gpio";

In order to enable any later chip-specific quirking requirements, that
compatible property should both specify the IP block and the specific
chip it's included in, so I'd expect to see something like:

		compatible = "brcm,brcm11351-gpio", "brcm,kona-gpio";


From robherring2 at gmail.com  Fri Jul 26 18:11:32 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Fri, 26 Jul 2013 17:11:32 -0500
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <51F1C412.1010602@wwwdotorg.org>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <CAL_JsqJQWOLC9f1igEpsgJB2X8mFDpqLDaFFRjGGVHctjWZLgQ@mail.gmail.com>
 <20130725193135.GT23879@titan.lakedaemon.net>
 <CAL_Jsq+vWbTb8wNEDCR2c_M6sBnKW6e5HGk48QzmXSujQUdddA@mail.gmail.com>
 <51F1C412.1010602@wwwdotorg.org>
Message-ID: <CAL_JsqLweU0Mt_8zsBu=-3Mx4Tc3Gn088j3xN27Hnq57etCofw@mail.gmail.com>

On Thu, Jul 25, 2013 at 7:34 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/25/2013 01:16 PM, Rob Herring wrote:
>> On Thu, Jul 25, 2013 at 2:31 PM, Jason Cooper <jason at lakedaemon.net> wrote:
>>> On Thu, Jul 25, 2013 at 02:11:31PM -0500, Rob Herring wrote:
>>>> On Thu, Jul 25, 2013 at 11:09 AM, Olof Johansson <olof at lixom.net> wrote:
>>>
>>>>> One problem that needs to be solved is obviously how a binding
>>>>> graduates from tentative to locked. This work isn't going to be very
>>>>> interesting to most people, I suspect. Think standards committee type
>>>>> work.
>>>>
>>>> I think a time based stabilization period would be better than a
>>>> separate directory to apply bindings too. Or time plus periodic review
>>>> perhaps.
>>>
>>> The only problem with a time-based versus separate directory is how do
>>> users who've downloaded the tree determine which bindings are stable?
>>> If they pull a tarball, or receive an SDK, there is most likely no git
>>> history attached.
>>
>> Well, if time based includes moving the binding out of the kernel,
>> then that is what defines it as stable or not. I guess that is a form
>> of a separate directory. I don't think we want to be moving bindings
>> twice: tentative -> stable and kernel -> DT repo.
>>
>> The policy could be as simple as an binding without change in at least
>> N kernel releases is moved out and stable.
>
> That might not be quite the right criteria. Just because something
> didn't change doesn't mean it's "correct" and that any problems in the
> binding have been addressed. As one example, on Tegra, we have a few
> bindings that haven't changed in a while, yet rely on custom properties
> for describing which DMA channel to use, rather than using the
> fairly-recently-introduced standard DMA DT properties (this particular
> example is being rectified now, but I'm sure there are plenty of similar
> examples)

In this case, I would suggest that both bindings are stable and the
conversion from one to the other is a platform decision. You could
make the kernel support both if you wanted. Or you know the platform
is not stable and are okay with having to keep dtb and kernel in sync.

I think this highlights the need to separate stable bindings and
stable dts files.

Rob


From mturquette at linaro.org  Fri Jul 26 18:19:02 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Fri, 26 Jul 2013 15:19:02 -0700
Subject: [PATCH v2] clk: exynos4: Add CLK_GET_RATE_NOCACHE flag for the
 Exynos4x12 ISP clocks
In-Reply-To: <51F2F26E.4090909@gmail.com>
References: <1374786425-6697-1-git-send-email-sylvester.nawrocki@gmail.com>
 <20130726203026.7598.21711@quantum> <51F2F26E.4090909@gmail.com>
Message-ID: <20130726221902.7598.22707@quantum>

Quoting Sylwester Nawrocki (2013-07-26 15:04:30)
> On 07/26/2013 10:30 PM, Mike Turquette wrote:
> > Quoting Sylwester Nawrocki (2013-07-25 14:07:05)
> >> From: Sylwester Nawrocki<s.nawrocki at samsung.com>
> >>
> >> The ISP clock registers belong to the ISP power domain and may change
> >> their values if this power domain is switched off/on. Add
> >> CLK_GET_RATE_NOCACHE flags to ensure we do not rely on invalid cached
> >> data when setting or getting frequency of those clocks.
> >>
> >> Signed-off-by: Sylwester Nawrocki<s.nawrocki at samsung.com>
> >> Signed-off-by: Kyungmin Park<kyungmin.park at samsung.com>
> >
> > Thanks for the fix. I've taken into clk-fixes. Is there a specific
> > regression this fixes (besides just having wrong clock rates). I can
> > amend the changelog if you have an example (e.g. device X explodes).
> 
> Hmm, yes, this fixes a pretty serious problem. There is a companion
> commit [1] already in Linus' tree, more details can be found there.
> 
> Perhaps something like this could be added:
> 
> "Otherwise the FIMC-IS Cortex-A5 core and AXI bus clocks have
> incorrect frequencies, which breaks the ISP operation and starting
> the video pipeline fails with timeouts reported by the FIMC-IS
> firmware.
> 
> See related commit 722a860ecb29aa34ec6f7d7f32b949209e8
> "[media] exynos4-is: Fix FIMC-IS clocks initialization" for more
> details."

That's great.

Thanks,
Mike

> 
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=722a860ecb29aa34ec6f7d7f32b949209e86a2f3
> 
> Thanks,
> Sylwester


From csd at broadcom.com  Fri Jul 26 18:16:52 2013
From: csd at broadcom.com (Christian Daudt)
Date: Fri, 26 Jul 2013 15:16:52 -0700
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X
 SoC with ARM CPU
In-Reply-To: <20130726000412.GH5022@linaro.org>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130719020611.GA4941@glitch> <20130723185733.GB6811@ohporter.com>
 <CAGVrzcYnoN9NnJGvubS7=bVJDk37xSt4BimtvDWghe7OHEWALQ@mail.gmail.com>
 <20130724231106.GB29801@glitch>
 <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
 <20130726000412.GH5022@linaro.org>
Message-ID: <51F2F554.8030709@broadcom.com>

On 13-07-25 05:04 PM, Matt Porter wrote:
> On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote:
>> 2013/7/25 Domenico Andreoli <cavokz at gmail.com>:
>>> On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote:
>>>> 2013/7/23 Matt Porter <matt.porter at linaro.org>:
>>>>> On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
>>>>> It's pretty easy to see that the "ti" vendor prefix has no relation at
>>>>> all to their TXN symbol so that blows that convention out of the water.
>>>>> Rather, the prefix is based on somebody's notion of how that vendor's
>>>>> part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
>>>>> never TXN OMAP. :)
>>>>>
>>>>> For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.
>>>> It was appropriate before being the "wrong" vendor prefix was
>>>> allocated, now that "brcm" has been allocated we should stick to it
>>>> because otherwise we will break existing and on-going DT work.
>>> I still prefer bcm to brcm and I find enough evidence that bcm would be
>>> better in the long term.
>>>
>>> So if Broadcomers can agree on bcm, now it's still the cheapest time to
>>> fix in that direction, later will not be better.
>> If we are to fix it in stone, once and for all, let's go for the full name
>> which would avoid any kind of future confusion (this also seems to be the
>> tendency with new vendor prefixes these days). That way we could make
>> everyone happy with say: "broadcom,bcm2835". Would that work for everyone?
> I really like that.
>
> -Matt
>
broadcom works for me also.
  thanks,
    csd




From mturquette at linaro.org  Fri Jul 26 18:25:01 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Fri, 26 Jul 2013 15:25:01 -0700
Subject: Zynq clk fixes
In-Reply-To: <a76b3a5d-dadc-43b3-87ee-3c65258c15d7@CO1EHSMHS029.ehs.local>
References: <51F26716.6030701@monstr.eu> <20130726200703.7598.86150@quantum>
 <a76b3a5d-dadc-43b3-87ee-3c65258c15d7@CO1EHSMHS029.ehs.local>
Message-ID: <20130726222501.7598.33060@quantum>

Quoting S?ren Brinkmann (2013-07-26 14:11:52)
> On Fri, Jul 26, 2013 at 01:07:03PM -0700, Mike Turquette wrote:
> > Quoting Michal Simek (2013-07-26 05:09:58)
> > > Hi Mike, [cc: Arnd and Olof]
> > > 
> > > Soren has found two bug fixes in zynq clk code.
> > > Can you please add these two patches to your tree?
> > > Will be great if you can add them to v3.11.
> > > 
> > > Arnd, Olof: I expect that all these clock changes should go through Mike.
> > > If I am wrong please let me know.
> > 
> > Looks right to me. Do these fix regressions in the current -rc cycle?
> 
> I doubt there are real regressions. But since it's still early in
> the release cycle and the driver was added in this merge window, I'd prefer
> having it hit a release kernel with these fixes included.

I've taken these into clk-fixes and added the following to the changelog
for each patch:

"This does not fix a specific regression but the clock driver was merged
for 3.11-rc1, so best to fix the known bugs before the release."

Regards,
Mike

> 
>         S?ren


From soren.brinkmann at xilinx.com  Fri Jul 26 18:26:28 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Fri, 26 Jul 2013 15:26:28 -0700
Subject: Zynq clk fixes
In-Reply-To: <20130726222501.7598.33060@quantum>
References: <51F26716.6030701@monstr.eu> <20130726200703.7598.86150@quantum>
 <a76b3a5d-dadc-43b3-87ee-3c65258c15d7@CO1EHSMHS029.ehs.local>
 <20130726222501.7598.33060@quantum>
Message-ID: <50ea1469-dac2-45e9-938a-60bb6c744d36@TX2EHSMHS041.ehs.local>

On Fri, Jul 26, 2013 at 03:25:01PM -0700, Mike Turquette wrote:
> Quoting S?ren Brinkmann (2013-07-26 14:11:52)
> > On Fri, Jul 26, 2013 at 01:07:03PM -0700, Mike Turquette wrote:
> > > Quoting Michal Simek (2013-07-26 05:09:58)
> > > > Hi Mike, [cc: Arnd and Olof]
> > > > 
> > > > Soren has found two bug fixes in zynq clk code.
> > > > Can you please add these two patches to your tree?
> > > > Will be great if you can add them to v3.11.
> > > > 
> > > > Arnd, Olof: I expect that all these clock changes should go through Mike.
> > > > If I am wrong please let me know.
> > > 
> > > Looks right to me. Do these fix regressions in the current -rc cycle?
> > 
> > I doubt there are real regressions. But since it's still early in
> > the release cycle and the driver was added in this merge window, I'd prefer
> > having it hit a release kernel with these fixes included.
> 
> I've taken these into clk-fixes and added the following to the changelog
> for each patch:
> 
> "This does not fix a specific regression but the clock driver was merged
> for 3.11-rc1, so best to fix the known bugs before the release."

Thanks.

	S?ren




From cavokz at gmail.com  Fri Jul 26 18:28:09 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Sat, 27 Jul 2013 00:28:09 +0200
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726193908.GX24642@n2100.arm.linux.org.uk>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net>
 <51F29BFE.8000202@broadcom.com>
 <20130726171153.GN29916@titan.lakedaemon.net>
 <51F2AF2D.1000300@broadcom.com>
 <20130726184702.GW24642@n2100.arm.linux.org.uk>
 <51F2C94F.6020405@broadcom.com>
 <20130726193908.GX24642@n2100.arm.linux.org.uk>
Message-ID: <20130726222809.GB19469@glitch>

On Fri, Jul 26, 2013 at 08:39:08PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 12:09:03PM -0700, Christian Daudt wrote:
> > On 13-07-26 11:47 AM, Russell King - ARM Linux wrote:
> >> On Fri, Jul 26, 2013 at 10:17:33AM -0700, Christian Daudt wrote:
> >>> Because ARCH_BCM is meant to be used for a number of SoC families. We've
> >>> started upstreaming one (the BCM281XX) but have 2 more internally that
> >>> we're working towards upstreaming. And in the future our plan is to keep
> >>> the Broadcom Mobile SoCs all building under this single ARCH_BCM
> >>> configuration as multiplatform code building a single zImage for them.
> >> 1. We're moving to a single zImage for everything.  Not just Broadcom.
> >> There's no need for Broadcom stuff to be treated any differently.
> >> Participate in the single zImage project and you will get that benefit
> >> without these games.
> > I don't follow what is the game being played.
> 
> I don't really mind what you do, but when you start talking about having
> any ARM build always descend into mach-bcm, then something is very wrong
> with how you're going about it - you don't see anyone else needing that
> in the tree, not even OMAP.

That was a Great Idea(tm) of mine that obviously needed some rebuttal.
No insult was implied for those not having had it in solving the very
same problem.

BTW I asked this very same question [1] and got _zero_ feedback so I
thought it was worth a patch.

> I don't really care if your intention is to decend into mach-bcm and then
> do nothing - that's not the point.  The point is we shouldn't even
> decend into mach-bcm if there's nothing to be built there.

I've got the point but didn't fully understand why would be so wrong to
walk one more subdir even if nothing is going to be built.

thanks,
Domenico

[1] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/253500


From cavokz at gmail.com  Fri Jul 26 18:29:12 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Sat, 27 Jul 2013 00:29:12 +0200
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <51F2F554.8030709@broadcom.com>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130719020611.GA4941@glitch> <20130723185733.GB6811@ohporter.com>
 <CAGVrzcYnoN9NnJGvubS7=bVJDk37xSt4BimtvDWghe7OHEWALQ@mail.gmail.com>
 <20130724231106.GB29801@glitch>
 <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
 <20130726000412.GH5022@linaro.org> <51F2F554.8030709@broadcom.com>
Message-ID: <20130726222912.GC19469@glitch>

On Fri, Jul 26, 2013 at 03:16:52PM -0700, Christian Daudt wrote:
> On 13-07-25 05:04 PM, Matt Porter wrote:
> >On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote:
> >>2013/7/25 Domenico Andreoli <cavokz at gmail.com>:
> >>>On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote:
> >>>>2013/7/23 Matt Porter <matt.porter at linaro.org>:
> >>>>>On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
> >>>>>It's pretty easy to see that the "ti" vendor prefix has no relation at
> >>>>>all to their TXN symbol so that blows that convention out of the water.
> >>>>>Rather, the prefix is based on somebody's notion of how that vendor's
> >>>>>part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
> >>>>>never TXN OMAP. :)
> >>>>>
> >>>>>For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.
> >>>>It was appropriate before being the "wrong" vendor prefix was
> >>>>allocated, now that "brcm" has been allocated we should stick to it
> >>>>because otherwise we will break existing and on-going DT work.
> >>>I still prefer bcm to brcm and I find enough evidence that bcm would be
> >>>better in the long term.
> >>>
> >>>So if Broadcomers can agree on bcm, now it's still the cheapest time to
> >>>fix in that direction, later will not be better.
> >>If we are to fix it in stone, once and for all, let's go for the full name
> >>which would avoid any kind of future confusion (this also seems to be the
> >>tendency with new vendor prefixes these days). That way we could make
> >>everyone happy with say: "broadcom,bcm2835". Would that work for everyone?
> >I really like that.
> >
> >-Matt
> >
> broadcom works for me also.
>  thanks,
>    csd

seconded

thanks,
Domenico


From swarren at wwwdotorg.org  Fri Jul 26 18:30:29 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 16:30:29 -0600
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <51F2F554.8030709@broadcom.com>
References: <1373982727-5492-1-git-send-email-hauke@hauke-m.de>
 <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130719020611.GA4941@glitch> <20130723185733.GB6811@ohporter.com>
 <CAGVrzcYnoN9NnJGvubS7=bVJDk37xSt4BimtvDWghe7OHEWALQ@mail.gmail.com>
 <20130724231106.GB29801@glitch>
 <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
 <20130726000412.GH5022@linaro.org> <51F2F554.8030709@broadcom.com>
Message-ID: <51F2F885.2040002@wwwdotorg.org>

I'm CC'ing in the DT bindings maintainers in case they have any comment.

On 07/26/2013 04:16 PM, Christian Daudt wrote:
> On 13-07-25 05:04 PM, Matt Porter wrote:
>> On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote:
>>> 2013/7/25 Domenico Andreoli <cavokz at gmail.com>:
>>>> On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote:
>>>>> 2013/7/23 Matt Porter <matt.porter at linaro.org>:
>>>>>> On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
>>>>>> It's pretty easy to see that the "ti" vendor prefix has no
>>>>>> relation at
>>>>>> all to their TXN symbol so that blows that convention out of the
>>>>>> water.
>>>>>> Rather, the prefix is based on somebody's notion of how that vendor's
>>>>>> part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
>>>>>> never TXN OMAP. :)
>>>>>>
>>>>>> For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.
>>>>> It was appropriate before being the "wrong" vendor prefix was
>>>>> allocated, now that "brcm" has been allocated we should stick to it
>>>>> because otherwise we will break existing and on-going DT work.
>>>> I still prefer bcm to brcm and I find enough evidence that bcm would be
>>>> better in the long term.
>>>>
>>>> So if Broadcomers can agree on bcm, now it's still the cheapest time to
>>>> fix in that direction, later will not be better.
>>> If we are to fix it in stone, once and for all, let's go for the full
>>> name
>>> which would avoid any kind of future confusion (this also seems to be
>>> the
>>> tendency with new vendor prefixes these days). That way we could make
>>> everyone happy with say: "broadcom,bcm2835". Would that work for
>>> everyone?
>> I really like that.
>>
>> -Matt
>>
> broadcom works for me also.
>  thanks,
>    csd

I have no strong objection at this point in principle to renaming the
vendor prefix used by the RPi support, although it will cause a bunch of
pointless churn in the drivers to match the new compatible values,  and
in the pinctrl bindings for the custom properties there...


From linux at arm.linux.org.uk  Fri Jul 26 18:38:29 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 23:38:29 +0100
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726222809.GB19469@glitch>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net> <51F29BFE.8000202@broadcom.com>
 <20130726171153.GN29916@titan.lakedaemon.net> <51F2AF2D.1000300@broadcom.com>
 <20130726184702.GW24642@n2100.arm.linux.org.uk>
 <51F2C94F.6020405@broadcom.com>
 <20130726193908.GX24642@n2100.arm.linux.org.uk>
 <20130726222809.GB19469@glitch>
Message-ID: <20130726223829.GY24642@n2100.arm.linux.org.uk>

On Sat, Jul 27, 2013 at 12:28:09AM +0200, Domenico Andreoli wrote:
> I've got the point but didn't fully understand why would be so wrong to
> walk one more subdir even if nothing is going to be built.

Consider what would happen if we decended the 61 mach- subdirectories
on every build run when only one was really required.  Even though
kbuild tries to be fast, there's still a non-zero amount of time
involved with finding out there's nothing to be done - and you
will still end up generating a built-in.o file even though there's
no other objects, which will then also be included in the final
link - again, adding to the work which has to be done.


From linus.walleij at linaro.org  Fri Jul 26 18:39:58 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 27 Jul 2013 00:39:58 +0200
Subject: Issue with gpio and pinmux
In-Reply-To: <20130726092601.GA1909@ab42.lan>
References: <51E667BC.3070804@parrot.com> <51E82FBB.1080905@wwwdotorg.org>
 <CACRpkdb1n07KoQZSme1EMJfV-9pHr-kd_1eJ6HsBV5gz7Dh3Ww@mail.gmail.com>
 <51EB590A.4010600@wwwdotorg.org>
 <CACRpkdZdbxEt67+YBKif4-BKAToOmN0_c8HFOdjSG91dtJwJQw@mail.gmail.com>
 <20130726092601.GA1909@ab42.lan>
Message-ID: <CACRpkdbLJYOJYLf-KWkxXzJD6tn6h139PPLMk=zGXfQfFHwWAQ@mail.gmail.com>

On Fri, Jul 26, 2013 at 11:26 AM, Christian Ruppert
<christian.ruppert at abilis.com> wrote:

> I like Stephen's proposal (in another mail) to claim GPIOs from the
> pinctrl drivers but instead of modifying the callback prototypes I
> suggest to add the following functions:
>
> /*
>  * Claim GPIO pin (in the sense: forbid acutal GPIO usage)
>  */
> int claim_gpios(struct pinctrl_dev *pctl, unsigned *pins
>                 unsigned port_selector, unsigned func_selector);
>
> /* allow GPIO usage of the given pins */
> void unclaim_gpios(struct pinctrl_dev *pctl, unsigned *pins);

I would keep ports out of this discussion to begin with,
that can be discussed and patched separately. Let's focus on
GPIO exclusivity WRT other functions.

And these should not be separate functions right? It should
be new members of struct pinmux_ops in <linux/pinctrl/pinmux.h>
right?

And there we already have these:

 * @gpio_request_enable: requests and enables GPIO on a certain pin.
 *      Implement this only if you can mux every pin individually as GPIO. The
 *      affected GPIO range is passed along with an offset(pin number) into that
 *      specific GPIO range - function selectors and pin groups are orthogonal
 *      to this, the core will however make sure the pins do not collide.
 * @gpio_disable_free: free up GPIO muxing on a certain pin, the reverse of
 *      @gpio_request_enable


        int (*gpio_request_enable) (struct pinctrl_dev *pctldev,
                                    struct pinctrl_gpio_range *range,
                                    unsigned offset);
        void (*gpio_disable_free) (struct pinctrl_dev *pctldev,
                                   struct pinctrl_gpio_range *range,
                                   unsigned offset);


> Claiming could be fully dynamic. This way, driver authors don't need to
> implement additional callbacks or modify their existing ones. In the
> simplest case they do nothing. The entire conflict-checking logic is
> confined inside the core.

This is the idea.

The core can already do this, basically, it is just that it's
pin_request() from drivers/pinctrl/pinmux.c.

As you can see if it is passed a gpio range, the GPIO request is
handled orhogonal to any other pin request, and calling the above
functions. What we want to do is basically selectively remove the
orthogonality. It should be very simple at this point.

> Alternatively, a similar set of functions could make the use of GPIOs
> exclusive with other functions for a given set of pins. This would work
> very well with the proposal below and would be easier to manage for most
> driver authors: The configuration would be static in most cases.
> (We just have to discuss about the default mode, do we want to keep the
> backward-compatible inclusive default or change everything to exclusive
> by default?).

I'm not following this, sorry.

> A last point I would like to address before passing on to implementation
> is to introduce the notion of interfaces: I think it is important to
> introduce some orthogonality between unrelated interfaces which happen
> to be muxed on the same port and ideally we implement this coherently
> with the above.

The ports concept should be handled separately.

Yours,
Linus Walleij


From mturquette at linaro.org  Fri Jul 26 18:32:36 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Fri, 26 Jul 2013 15:32:36 -0700
Subject: [PATCH v5] clk: add MOXA ART SoCs clock driver
In-Reply-To: <2711657.Br6v071qBc@flatron>
References: <1374221278-18204-1-git-send-email-jonas.jensen@gmail.com>
 <1374221837-23773-1-git-send-email-jonas.jensen@gmail.com>
 <20130722092138.GB18731@e106331-lin.cambridge.arm.com>
 <2711657.Br6v071qBc@flatron>
Message-ID: <20130726223236.7598.70416@quantum>

Quoting Tomasz Figa (2013-07-23 01:09:06)
> On Monday 22 of July 2013 10:21:38 Mark Rutland wrote:
> > On Fri, Jul 19, 2013 at 09:17:17AM +0100, Jonas Jensen wrote:
> > > This patch adds MOXA ART SoCs clock driver support.
> > > 
> > > Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
> > > ---
> > > 
> > > Notes:
> > >     Changes since v4:
> > >     
> > >     1. remove unnecessary header includes
> > >     
> > >     Applies to next-20130716
> > >  
> > >  .../bindings/clock/moxa,moxart-core-clock.txt      | 23 ++++++++
> > >  drivers/clk/Makefile                               |  1 +
> > >  drivers/clk/clk-moxart.c                           | 69
> > >  ++++++++++++++++++++++ 3 files changed, 93 insertions(+)
> > >  create mode 100644
> > >  Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
> > >  create mode 100644 drivers/clk/clk-moxart.c
> > > 
> > > diff --git
> > > a/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
> > > b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
> > > new file mode 100644
> > > index 0000000..528c8b0
> > > --- /dev/null
> > > +++
> > > b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
> > > @@ -0,0 +1,23 @@
> > > +Device Tree Clock bindings for arch-moxart
> > > +
> > > +This binding uses the common clock binding[1].
> > > +
> > > +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> > > +
> > > +MOXA ART SoCs allow to determine core clock frequencies by reading
> > > +a register.
> > > +
> > > +Required properties:
> > > +- compatible : Should be "moxa,moxart-core-clock"
> > > +- #clock-cells : Should be 0
> > > +- reg : Should contain registers location and length
> > > +- clock-output-names : Should be "coreclk"
> > > +
> > > +For example:
> > > +
> > > +   coreclk: core-clock at 98100000 {
> > > +           compatible = "moxa,moxart-core-clock";
> > > +           #clock-cells = <0>;
> > > +           reg = <0x98100000 0x34>;
> > > +           clock-output-names = "coreclk";
> > > +   };
> > > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> > > index 4038c2b..933622f 100644
> > > --- a/drivers/clk/Makefile
> > > +++ b/drivers/clk/Makefile
> > > @@ -11,6 +11,7 @@ obj-$(CONFIG_COMMON_CLK)  += clk-composite.o
> > > 
> > >  # SoCs specific
> > >  obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
> > > 
> > > +obj-$(CONFIG_ARCH_MOXART)  += clk-moxart.o
> > > 
> > >  obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
> > >  obj-$(CONFIG_ARCH_HIGHBANK)        += clk-highbank.o
> > >  obj-$(CONFIG_ARCH_NSPIRE)  += clk-nspire.o
> > > 
> > > diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
> > > new file mode 100644
> > > index 0000000..5559371
> > > --- /dev/null
> > > +++ b/drivers/clk/clk-moxart.c
> > > @@ -0,0 +1,69 @@
> > > +/*
> > > + * MOXA ART SoCs clock driver.
> > > + *
> > > + * Copyright (C) 2013 Jonas Jensen
> > > + *
> > > + * Jonas Jensen <jonas.jensen at gmail.com>
> > > + *
> > > + * This file is licensed under the terms of the GNU General Public
> > > + * License version 2.  This program is licensed "as is" without any
> > > + * warranty of any kind, whether express or implied.
> > > + */
> > > +
> > > +#include <linux/clk-provider.h>
> > > +#include <linux/io.h>
> > > +#include <linux/of_address.h>
> > > +#include <linux/clkdev.h>
> > > +
> > > +void __init moxart_of_clk_init(struct device_node *node)
> > > +{
> > > +   static void __iomem *base;
> > > +   struct clk *clk;
> > > +   unsigned long rate;
> > > +   unsigned int mul, val, div;
> > > +   const char *name;
> > > +
> > > +   base = of_iomap(node, 0);
> > > +   if (IS_ERR(base))
> > > +           panic("%s: of_iomap failed\n", node->full_name);
> > 
> > As far as I'm aware, of_iomap returns NULL, not an ERR_PTR value.
> > 
> > Also, is it necessary to panic() ? In v1 of the patch you used pr_err...
> 
> This is a good question in general, not only for this driver.
> 
> IMHO if you know early that something is really wrong, to the point that 
> the system won't be able to work normally (and failing to initialize 
> clocks looks like it) it is better to let the user/developer know that 
> something is utterly wrong at this point without letting the system run 
> for a bit more and fail anyway with a harder to track down error message.

You can let the user/developer know that something is utterly wrong with
a WARN.

Where panics and BUGs come back to haunt you is when you are bringing up
a new platform or SoC that uses this clock driver, but this clock driver
fails pending some subtle change for the new platform/SoC.

But perhaps your bootloader at least set the clocks up for you sensibly
and your other device drivers might bail out due to not having clocks
but at least you could boot your new system.  But putting a panic/BUG
here makes the above scenario impossible.

> 
> It's not so obvious, though, what kinds of failure should be considered 
> critical. IMHO any failure in low level initialization code, but this is 
> debatable, I guess.

Agreed that's it's hard to know when to use them. But if you can get
away with a WARN then I always err on the cautious side and try to
prevent panicing the system explicitly.

Regards,
Mike

> 
> Best regards,
> Tomasz


From linux at arm.linux.org.uk  Fri Jul 26 18:46:07 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 23:46:07 +0100
Subject: [PATCHv5 08/11] ARM: pci: add ->add_bus() and ->remove_bus()
 hooks to hw_pci
In-Reply-To: <20130725165659.GB27802@dhcp-172-17-186-34.nvidia.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130725165659.GB27802@dhcp-172-17-186-34.nvidia.com>
Message-ID: <20130726224607.GZ24642@n2100.arm.linux.org.uk>

On Thu, Jul 25, 2013 at 09:57:00AM -0700, Thierry Reding wrote:
> On Mon, Jul 15, 2013 at 01:52:44PM +0200, Thomas Petazzoni wrote:
> > Some PCI drivers may need to adjust the pci_bus structure after it has
> > been allocated by the Linux PCI core. The PCI core allows
> > architectures to implement the pcibios_add_bus() and
> > pcibios_remove_bus() for this purpose. This commit therefore extends
> > the hw_pci and pci_sys_data structures of the ARM PCI core to allow
> > PCI drivers to register ->add_bus() and ->remove_bus() in hw_pci,
> > which will get called when a bus is added or removed from the system.
> > 
> > This will be used for example by the Marvell PCIe driver to connect a
> > particular PCI bus with its corresponding MSI chip to handle Message
> > Signaled Interrupts.
> > 
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > Reviewed-by: Thierry Reding <thierry.reding at gmail.com>
> > ---
> >  arch/arm/include/asm/mach/pci.h |  4 ++++
> >  arch/arm/kernel/bios32.c        | 16 ++++++++++++++++
> >  2 files changed, 20 insertions(+)
> 
> Hi Russell,
> 
> Can we have your Acked-by on this patch so that it can be moved to a
> stable branch along with some of the other patches in this branch that
> both Marvell and Tegra PCIe drivers need?

Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>


From markus.mayer at linaro.org  Fri Jul 26 18:51:13 2013
From: markus.mayer at linaro.org (Markus Mayer)
Date: Fri, 26 Jul 2013 15:51:13 -0700
Subject: [PATCH v3 2/3] ARM: bcm281xx: Device Tree bindings for GPIO driver
In-Reply-To: <51F2F37B.8030306@wwwdotorg.org>
References: <1374870345-8276-1-git-send-email-markus.mayer@linaro.org>
 <1374870345-8276-3-git-send-email-markus.mayer@linaro.org>
 <51F2F37B.8030306@wwwdotorg.org>
Message-ID: <CAPdLdqmU0aw5h_KYcD-E=isC9U3mZF6fzr_GVdjUUAW4_PUD5Q@mail.gmail.com>

On 26 July 2013 15:08, Stephen Warren <swarren at wwwdotorg.org> wrote:
> (CC'ing the DT bindings maintainers hence quoting the binding in full)
>
> On 07/26/2013 02:25 PM, Markus Mayer wrote:
>
> Some kind of patch description is always useful.

I will add something along the lines of "GPIO device tree bindings for
the Broadcom bcm281xx family of chips."

>>  .../devicetree/bindings/gpio/gpio-bcm-kona.txt     |   41 ++++++++++++++++++++
>>  arch/arm/boot/dts/bcm11351.dtsi                    |   16 ++++++++
>
> It's more usual to put the DT binding doc change and driver change in
> one patch, then "make use of that" in a later separate patch which edits
> *.dts and *.dtsi.

Sure. I have no issue moving the gpio-bcm-kona.txt into the other
patch, together with the code.

>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt b/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt
>
>> +Broadcom Kona Family GPIO
>> +-------------------------
>> +
>> +This GPIO driver is used in the following Broadcom SoCs:
>> +  BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
>> +
>> +The GPIO controller only supports edge, not level triggering.
>
> add "... of interrupts"? This might not be worth mentioning; it's
> clearly spelled out in the description of the interrupt cells below.

Added.

>> +Required properties:
>> +  - compatible: "brcm,kona-gpio"
>> +  - reg: Physical base address and length of the controller's registers.
>> +  - interrupts: The interrupt outputs from the controller.
>
> How many entries are required? I notice there's more than 1 in the
> example below.

You only "need" the ones you want to use, i.e. at least one. The board
supports up to 6. I can mention as much in the description.

[...]

>> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
>
>> +     gpio: gpio at 35003000 {
>> +             compatible = "brcm,kona-gpio";
>
> In order to enable any later chip-specific quirking requirements, that
> compatible property should both specify the IP block and the specific
> chip it's included in, so I'd expect to see something like:
>
>                 compatible = "brcm,brcm11351-gpio", "brcm,kona-gpio";

Added.

Thanks,
-Markus

-- 
Markus Mayer
Broadcom Landing Team


From linux at arm.linux.org.uk  Fri Jul 26 18:59:10 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Jul 2013 23:59:10 +0100
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <51F0CAA5.8010108@ti.com>
References: <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724145237.GB21614@n2100.arm.linux.org.uk>
 <51F0C841.8000900@ti.com> <51F0CAA5.8010108@ti.com>
Message-ID: <20130726225910.GD21614@n2100.arm.linux.org.uk>

Having worked out how to get around the MMC ordering issue without having
to go and re-tweak it should it change again in the future, I've added
the SDP back into the build.

On Thu, Jul 25, 2013 at 09:50:13AM +0300, Tomi Valkeinen wrote:
> On 25/07/13 09:40, Tomi Valkeinen wrote:
> > On 24/07/13 17:52, Russell King - ARM Linux wrote:
> > 
> >> I also continue to be disappointed by the lack of things working on the
> >> 4430 - it's been a number of years now and _still_ the on-board LCDs do
> >> not work.  People have tried to blame that on hardware faults and the
> >> like, but they're just being idiotic when they say stuff like that.  It
> >> can't be hardware faults when the kernel supplied with the board is able
> >> to make them work to the extent that userspace can play back video on all
> >> three output devices simultaneously, without hiccup or any imperfection.
> >> I don't know whether it's just that the backlight support isn't working
> >> or what - because any information on the 4430 seems to be a tightly
> >> controlled secret that only a few select people are permitted to know
> >> about.  As far as I'm concerned, much of the hardware is a black box to
> >> me.
> > 
> > The 4430SDP's backlight hasn't been working in the mainline due to
> > missing support from the TWL driver. But we finally did get that in for
> > 3.10 (or maybe 3.9), and booting 3.10 non-DT kernel brings up the
> > backlights. However, the BL doesn't work yet with DT boot, so again with
> > 3.11, with no board files, the BL is out... Sigh.
> 
> Ah, sorry, I take that back. Backlight seems to be working fine with 3.11.

... if you know how to configure stuff so it works.  It seems that the
reason it hasn't been working, and the displays have been remaining
blank is because I had no idea that CONFIG_PWM and CONFIG_PWM_TWL were
required.  I've now added those to the config seed, so hopefully they
should start working now.  Only taken... what... two years to find that
out!


From swarren at wwwdotorg.org  Fri Jul 26 19:09:56 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Fri, 26 Jul 2013 17:09:56 -0600
Subject: [PATCH v3 2/3] ARM: bcm281xx: Device Tree bindings for GPIO driver
In-Reply-To: <CAPdLdqmU0aw5h_KYcD-E=isC9U3mZF6fzr_GVdjUUAW4_PUD5Q@mail.gmail.com>
References: <1374870345-8276-1-git-send-email-markus.mayer@linaro.org>
 <1374870345-8276-3-git-send-email-markus.mayer@linaro.org>
 <51F2F37B.8030306@wwwdotorg.org>
 <CAPdLdqmU0aw5h_KYcD-E=isC9U3mZF6fzr_GVdjUUAW4_PUD5Q@mail.gmail.com>
Message-ID: <51F301C4.4070807@wwwdotorg.org>

On 07/26/2013 04:51 PM, Markus Mayer wrote:
> On 26 July 2013 15:08, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> (CC'ing the DT bindings maintainers hence quoting the binding in full)
>>
>> On 07/26/2013 02:25 PM, Markus Mayer wrote:

>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt b/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt

>>> +Required properties:
>>> +  - compatible: "brcm,kona-gpio"
>>> +  - reg: Physical base address and length of the controller's registers.
>>> +  - interrupts: The interrupt outputs from the controller.
>>
>> How many entries are required? I notice there's more than 1 in the
>> example below.
> 
> You only "need" the ones you want to use, i.e. at least one. The board
> supports up to 6. I can mention as much in the description.

Isn't this a property of the SoC's IP block, not of the board?


From gregkh at linuxfoundation.org  Fri Jul 26 19:10:08 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Fri, 26 Jul 2013 16:10:08 -0700
Subject: [PATCH v2 2/3] serial: mxs: enable the DMA only when the RTS/CTS
 is valid
In-Reply-To: <51E648C2.3010304@freescale.com>
References: <1373957732-16638-1-git-send-email-b32955@freescale.com>
 <1373957732-16638-3-git-send-email-b32955@freescale.com>
 <20130716095449.GS12139@pengutronix.de>
 <51E648C2.3010304@freescale.com>
Message-ID: <20130726231008.GA32627@kroah.com>

On Wed, Jul 17, 2013 at 03:33:22PM +0800, Huang Shijie wrote:
> ? 2013?07?16? 17:54, Uwe Kleine-K?nig ??:
> >On Tue, Jul 16, 2013 at 02:55:31PM +0800, Huang Shijie wrote:
> >>The original DMA support works only when RTS/CTS is enabled.
> >What is original here?
> >
> i will add more information for this in the next version.
> >>But after several patches, DMA support has lost this limit.
> >This is still misleading.
> >
> >>This patch adds an optional property for the UART DT node
> >>which indicates the UART has RTS and CTS lines.
> >>
> >>This patch also adds a macro MXS_AUART_RTSCTS, and uses it to check
> >>RTS/CTS before we enable the DMA for the UART.
> >I still think this should go to stable. The options are:
> >
> >	a) also take patch 1 into stable
> >	b) apply this patch without patch 1
> >
> >I don't know if option a) is OK, b) is probably preferable. And as Greg
> to Greg:
> 
> I think a) is ok to me. what's your opinion?

Please reorder them, making patch 2 first, and mark it for stable, then
do patch 1, and the rest, so I don't have to take non-needed patches
into the stable tree.

thanks,

greg k-h


From jgunthorpe at obsidianresearch.com  Fri Jul 26 19:11:08 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Fri, 26 Jul 2013 17:11:08 -0600
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726215859.GA19469@glitch>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net>
 <20130726215859.GA19469@glitch>
Message-ID: <20130726231108.GA10812@obsidianresearch.com>

On Fri, Jul 26, 2013 at 11:59:00PM +0200, Domenico Andreoli wrote:

> In mach-bcm we (or I, it's not very clear to me) want to have support for
> multiple SoCs.
> 
> In trying the approach
> 
> machine-$(CONFIG_ARCH_BCM)		+= bcm
> machine-$(CONFIG_ARCH_BCM4760)		+= bcm
> 
> I got linker complains about multiple symbol definitiion in case both the
> config options are selected.

You can't repeat the same dir. Maybe this?

bcm-machine-$(CONFIG_ARCH_BCM) := bmc
bcm-machine-$(CONFIG_ARCH_BCM4760) := bmc
machine-y += $(bcm-machine-y)

Regards,
Jason


From markus.mayer at linaro.org  Fri Jul 26 19:22:07 2013
From: markus.mayer at linaro.org (Markus Mayer)
Date: Fri, 26 Jul 2013 16:22:07 -0700
Subject: [PATCH v3 2/3] ARM: bcm281xx: Device Tree bindings for GPIO driver
In-Reply-To: <51F301C4.4070807@wwwdotorg.org>
References: <1374870345-8276-1-git-send-email-markus.mayer@linaro.org>
 <1374870345-8276-3-git-send-email-markus.mayer@linaro.org>
 <51F2F37B.8030306@wwwdotorg.org>
 <CAPdLdqmU0aw5h_KYcD-E=isC9U3mZF6fzr_GVdjUUAW4_PUD5Q@mail.gmail.com>
 <51F301C4.4070807@wwwdotorg.org>
Message-ID: <CAPdLdqnq21zPNdJ_4iYS96yQH1XeuTp-TbwHpvkwsECHEKOKaQ@mail.gmail.com>

On 26 July 2013 16:09, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/26/2013 04:51 PM, Markus Mayer wrote:
>> On 26 July 2013 15:08, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> (CC'ing the DT bindings maintainers hence quoting the binding in full)
>>>
>>> On 07/26/2013 02:25 PM, Markus Mayer wrote:
>
>>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt b/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt
>
>>>> +Required properties:
>>>> +  - compatible: "brcm,kona-gpio"
>>>> +  - reg: Physical base address and length of the controller's registers.
>>>> +  - interrupts: The interrupt outputs from the controller.
>>>
>>> How many entries are required? I notice there's more than 1 in the
>>> example below.
>>
>> You only "need" the ones you want to use, i.e. at least one. The board
>> supports up to 6. I can mention as much in the description.
>
> Isn't this a property of the SoC's IP block, not of the board?

Yes. I wasn't very precise with my statement.

What I added to the description is "Specify at least 1 GPIO interrupt.
The maximum number is 6."

-- 
Markus Mayer
Broadcom Landing Team


From linus.walleij at linaro.org  Fri Jul 26 19:22:37 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 27 Jul 2013 01:22:37 +0200
Subject: [PATCH 1/3] pinctrl: rollback check for !dev->pins in
 pinctrl_pm_select*() APIs
In-Reply-To: <20130717154038.GK7656@atomide.com>
References: <1374061312-25469-1-git-send-email-grygorii.strashko@ti.com>
 <1374061312-25469-2-git-send-email-grygorii.strashko@ti.com>
 <20130717154038.GK7656@atomide.com>
Message-ID: <CACRpkdYZOFYNXDwMr6om=3Fuj9z3DnaXYHQ_3B-xfTk9dsWdnQ@mail.gmail.com>

On Wed, Jul 17, 2013 at 5:40 PM, Tony Lindgren <tony at atomide.com> wrote:
> * Grygorii Strashko <grygorii.strashko at ti.com> [130717 04:49]:
>> The pinctrl support in Device core assumed to be optional - so, It's
>> valid case, when there are no definition for default device's pinctrl
>> states in DT at all ("default", "active", "idle", "sleep").
>> And in this case dev->pins == NULL and pinctrl_pm_select*() API
>> should return 0 always.
>>
>> Now the checks for !dev->pins have been removed from
>> pinctrl_pm_select*() API mistakenly by the patch
>> pinctrl: Remove duplicate code in pinctrl_pm_select_state functions
>> http://www.spinics.net/lists/arm-kernel/msg258829.html
>>
>> Hence, rollback these checks in in pinctrl_pm_select*() APIs.
>
> Thanks, it's best that I fold this fix into my patch as it has not
> been committed yet.

I think I've applied the correct v2 version,
please check that linux-next is in good shape...

Yours,
Linus Walleij


From cavokz at gmail.com  Fri Jul 26 19:28:58 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Sat, 27 Jul 2013 01:28:58 +0200
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726231108.GA10812@obsidianresearch.com>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net>
 <20130726215859.GA19469@glitch>
 <20130726231108.GA10812@obsidianresearch.com>
Message-ID: <20130726232858.GA6953@glitch>

On Fri, Jul 26, 2013 at 05:11:08PM -0600, Jason Gunthorpe wrote:
> On Fri, Jul 26, 2013 at 11:59:00PM +0200, Domenico Andreoli wrote:
> 
> > In mach-bcm we (or I, it's not very clear to me) want to have support for
> > multiple SoCs.
> > 
> > In trying the approach
> > 
> > machine-$(CONFIG_ARCH_BCM)		+= bcm
> > machine-$(CONFIG_ARCH_BCM4760)		+= bcm
> > 
> > I got linker complains about multiple symbol definitiion in case both the
> > config options are selected.
> 
> You can't repeat the same dir. Maybe this?
> 
> bcm-machine-$(CONFIG_ARCH_BCM) := bmc
> bcm-machine-$(CONFIG_ARCH_BCM4760) := bmc
> machine-y += $(bcm-machine-y)

nice! I prefer this to the config option used only to descend the dir,
you never know how it is going to be abused.

Christian, would you agree in ditching ARCH_BROADCOM then?

Russel, is it ok?

thanks,
Domenico


From cavokz at gmail.com  Fri Jul 26 19:30:18 2013
From: cavokz at gmail.com (Domenico Andreoli)
Date: Sat, 27 Jul 2013 01:30:18 +0200
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726223829.GY24642@n2100.arm.linux.org.uk>
References: <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net>
 <51F29BFE.8000202@broadcom.com>
 <20130726171153.GN29916@titan.lakedaemon.net>
 <51F2AF2D.1000300@broadcom.com>
 <20130726184702.GW24642@n2100.arm.linux.org.uk>
 <51F2C94F.6020405@broadcom.com>
 <20130726193908.GX24642@n2100.arm.linux.org.uk>
 <20130726222809.GB19469@glitch>
 <20130726223829.GY24642@n2100.arm.linux.org.uk>
Message-ID: <20130726233018.GB6953@glitch>

On Fri, Jul 26, 2013 at 11:38:29PM +0100, Russell King - ARM Linux wrote:
> On Sat, Jul 27, 2013 at 12:28:09AM +0200, Domenico Andreoli wrote:
> > I've got the point but didn't fully understand why would be so wrong to
> > walk one more subdir even if nothing is going to be built.
> 
> Consider what would happen if we decended the 61 mach- subdirectories
> on every build run when only one was really required.  Even though
> kbuild tries to be fast, there's still a non-zero amount of time
> involved with finding out there's nothing to be done - and you
> will still end up generating a built-in.o file even though there's
> no other objects, which will then also be included in the final
> link - again, adding to the work which has to be done.

crystal clear. thanks.

Domenico


From linus.walleij at linaro.org  Fri Jul 26 19:31:05 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 27 Jul 2013 01:31:05 +0200
Subject: [PATCH] pinctrl: tegra: expose config options for individual SoCs
In-Reply-To: <51E81F36.3030802@wwwdotorg.org>
References: <1374014077-22536-1-git-send-email-swarren@wwwdotorg.org>
 <51E81F36.3030802@wwwdotorg.org>
Message-ID: <CACRpkdaUeLG_y1SyinPKsdb9XDNJFup_sf9+EMOMjyW+7u_ZZw@mail.gmail.com>

On Thu, Jul 18, 2013 at 7:00 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/16/2013 04:34 PM, Stephen Warren wrote:
>> I'm planning to remove CONFIG_ARCH_TEGRA_*_SOC, leaving just ARCH_TEGRA.
>> This will reduce the number of configurations that need to be supported
>> by core Tegra code, e.g. CPU idle, hotplug. As a precursor, we need to
>> update Kconfig for all Tegra drivers not to reference ARCH_TEGRA_*_SOC.
>>
>> The Tegra pinctrl driver contains a fairly large amount of SoC-specific
>> code and data. Introduce explicit config options so that the user can
>> trim the set of supported SoCs if they wish. Default these to on, since
>> most people will probably want to enable support for all SoCs. This also
>> avoids the need to change any defconfig files.
>
> I'd like to defer actually applying this patch. There is some discussion
> (in the thread for the equivalent ASoC patches) re: the best way to
> handle the ARCH_TEGRA_*_SOC Kconfig options which might affect this
> patch. Any review comment is still appreciated.

Just poke me when the discussion settles.

I'm totally unenlightened on this issue myself so not of much
help...

Yours,
Linus Walleij


From linux at arm.linux.org.uk  Fri Jul 26 19:42:37 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 27 Jul 2013 00:42:37 +0100
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726231108.GA10812@obsidianresearch.com>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net> <20130726215859.GA19469@glitch>
 <20130726231108.GA10812@obsidianresearch.com>
Message-ID: <20130726234237.GB24642@n2100.arm.linux.org.uk>

On Fri, Jul 26, 2013 at 05:11:08PM -0600, Jason Gunthorpe wrote:
> On Fri, Jul 26, 2013 at 11:59:00PM +0200, Domenico Andreoli wrote:
> 
> > In mach-bcm we (or I, it's not very clear to me) want to have support for
> > multiple SoCs.
> > 
> > In trying the approach
> > 
> > machine-$(CONFIG_ARCH_BCM)		+= bcm
> > machine-$(CONFIG_ARCH_BCM4760)		+= bcm
> > 
> > I got linker complains about multiple symbol definitiion in case both the
> > config options are selected.
> 
> You can't repeat the same dir. Maybe this?
> 
> bcm-machine-$(CONFIG_ARCH_BCM) := bmc
> bcm-machine-$(CONFIG_ARCH_BCM4760) := bmc
> machine-y += $(bcm-machine-y)

Thank you for making me look at that file and see how people fail to read
my comments about keeping stuff appropriately sorted.  Really makes me
wonder why I bother.

Anyway, there's a simpler solutions to this:

machdirs := $(patsubst %,arch/arm/mach-%/,$(sort $(machine-y)))
platdirs := $(patsubst %,arch/arm/plat-%/,$(Sort $(plat-y)))

which will remove all duplicates.


From sergei.shtylyov at cogentembedded.com  Fri Jul 26 19:46:33 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 27 Jul 2013 03:46:33 +0400
Subject: [PATCH] ARM: shmobile: BOCK-W: fix SDHI0 PFC settings
Message-ID: <201307270346.34002.sergei.shtylyov@cogentembedded.com>

The following message is printed on the BOCK-W kernel bootup: 

sh-pfc pfc-r8a7778: invalid group "sdhi0" for function "sdhi0" 

In addition, SD card cannot be detected.  The reason is apparently that commit
ca7bb309485e4ec89a9addd47bea (ARM: shmobile: bockw: add SDHI0 support) matched
the previous version of commit 564617d2f92473031d035deb273da5 (sh-pfc: r8a7778:
add SDHI support).

Add the missing pin groups according to the BOCK-W board schematics.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
The patch is atop of Simon's 'renesas.git' repo, 'renesas-devel-20130726' tag.

 arch/arm/mach-shmobile/board-bockw.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -167,7 +167,13 @@ static const struct pinctrl_map bockw_pi
 				  "usb1", "usb1"),
 	/* SDHI0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
-				  "sdhi0", "sdhi0"),
+				  "sdhi0_data4", "sdhi0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
+				  "sdhi0_ctrl", "sdhi0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
+				  "sdhi0_cd", "sdhi0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
+				  "sdhi0_wp", "sdhi0"),
 };
 
 #define FPGA	0x18200000


From benh at kernel.crashing.org  Fri Jul 26 19:47:53 2013
From: benh at kernel.crashing.org (Benjamin Herrenschmidt)
Date: Sat, 27 Jul 2013 09:47:53 +1000
Subject: [GIT PULL] arm64 fixes for 3.11
In-Reply-To: <CA+55aFzmEhGvqY883Bg568Gguewy41X9n1qDeaHkW2We6VVhZg@mail.gmail.com>
References: <20130726155458.GA31613@arm.com>
 <CA+55aFzmEhGvqY883Bg568Gguewy41X9n1qDeaHkW2We6VVhZg@mail.gmail.com>
Message-ID: <1374882473.9200.33.camel@pasglop>

On Fri, 2013-07-26 at 12:54 -0700, Linus Torvalds wrote:
> 
> *Some* other 64-bit architectures do 16k stack sizes. But neither
> x86-64 nor powerpc do, afaik. Instead, they do irq stacks, which is
> generally a better idea than having one big stack.

Sadly you over estimated us here :-) We do 16K *and* irq stacks on
64-bit ... Remember our ABI with it's 112 bytes minimum per frame ?

It's been a while since I've last audited our actual usage mind you, we
*might* be able to reduce it but at this stage, since our typical
configs use a 64K base page size, it's not a big deal (ie, it's not an
order-N allocation).

Cheers,
Ben.




From sergei.shtylyov at cogentembedded.com  Fri Jul 26 19:55:12 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 27 Jul 2013 03:55:12 +0400
Subject: [PATCH] ARM: shmobile: BOCK-W: fix SDHI0 PFC settings
In-Reply-To: <201307270346.34002.sergei.shtylyov@cogentembedded.com>
References: <201307270346.34002.sergei.shtylyov@cogentembedded.com>
Message-ID: <51F30C60.5050504@cogentembedded.com>

Hello.

On 07/27/2013 03:46 AM, Sergei Shtylyov wrote:

> The following message is printed on the BOCK-W kernel bootup:

> sh-pfc pfc-r8a7778: invalid group "sdhi0" for function "sdhi0"

> In addition, SD card cannot be detected.  The reason is apparently that commit
> ca7bb309485e4ec89a9addd47bea (ARM: shmobile: bockw: add SDHI0 support) matched
> the previous version of commit 564617d2f92473031d035deb273da5 (sh-pfc: r8a7778:
> add SDHI support).

> Add the missing pin groups according to the BOCK-W board schematics.

> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

> ---
> The patch is atop of Simon's 'renesas.git' repo, 'renesas-devel-20130726' tag.

    It also applies to the current Linus' tree cleanly. Please push it for 3.11.

WBR, Sergei



From csd at broadcom.com  Fri Jul 26 19:55:39 2013
From: csd at broadcom.com (Christian Daudt)
Date: Fri, 26 Jul 2013 16:55:39 -0700
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726232858.GA6953@glitch>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net>
 <20130726215859.GA19469@glitch>
 <20130726231108.GA10812@obsidianresearch.com>
 <20130726232858.GA6953@glitch>
Message-ID: <51F30C7B.6000504@broadcom.com>

On 13-07-26 04:28 PM, Domenico Andreoli wrote:
> On Fri, Jul 26, 2013 at 05:11:08PM -0600, Jason Gunthorpe wrote:
>> On Fri, Jul 26, 2013 at 11:59:00PM +0200, Domenico Andreoli wrote:
>>
>>> In mach-bcm we (or I, it's not very clear to me) want to have support for
>>> multiple SoCs.
>>>
>>> In trying the approach
>>>
>>> machine-$(CONFIG_ARCH_BCM)		+= bcm
>>> machine-$(CONFIG_ARCH_BCM4760)		+= bcm
>>>
>>> I got linker complains about multiple symbol definitiion in case both the
>>> config options are selected.
>> You can't repeat the same dir. Maybe this?
>>
>> bcm-machine-$(CONFIG_ARCH_BCM) := bmc
>> bcm-machine-$(CONFIG_ARCH_BCM4760) := bmc
>> machine-y += $(bcm-machine-y)
> nice! I prefer this to the config option used only to descend the dir,
> you never know how it is going to be abused.
>
> Christian, would you agree in ditching ARCH_BROADCOM then?
I'm fine with skipping ARCH_BROADCOM
  Thanks,
    csd




From olof at lixom.net  Fri Jul 26 20:01:08 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Jul 2013 17:01:08 -0700
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726234237.GB24642@n2100.arm.linux.org.uk>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net>
 <20130726215859.GA19469@glitch>
 <20130726231108.GA10812@obsidianresearch.com>
 <20130726234237.GB24642@n2100.arm.linux.org.uk>
Message-ID: <CAOesGMiPHh1FcWM1Tfvq+e-9znQ6zRKGwmzJGe+jGj5GZsaGqA@mail.gmail.com>

On Fri, Jul 26, 2013 at 4:42 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> Thank you for making me look at that file and see how people fail to read
> my comments about keeping stuff appropriately sorted.  Really makes me
> wonder why I bother.

Grmbl. This one escaped me probably because the comment is at the top,
so I didn't see it when just reviewing the patch. I should obviously
have caught it anyway since the list was so obviously sorted before.
My bad. I'll send a patch in a bit.


-Olof


From linux at arm.linux.org.uk  Fri Jul 26 20:04:53 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 27 Jul 2013 01:04:53 +0100
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <CAOesGMiPHh1FcWM1Tfvq+e-9znQ6zRKGwmzJGe+jGj5GZsaGqA@mail.gmail.com>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net> <20130726215859.GA19469@glitch>
 <20130726231108.GA10812@obsidianresearch.com>
 <20130726234237.GB24642@n2100.arm.linux.org.uk>
 <CAOesGMiPHh1FcWM1Tfvq+e-9znQ6zRKGwmzJGe+jGj5GZsaGqA@mail.gmail.com>
Message-ID: <20130727000453.GC24642@n2100.arm.linux.org.uk>

On Fri, Jul 26, 2013 at 05:01:08PM -0700, Olof Johansson wrote:
> On Fri, Jul 26, 2013 at 4:42 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > Thank you for making me look at that file and see how people fail to read
> > my comments about keeping stuff appropriately sorted.  Really makes me
> > wonder why I bother.
> 
> Grmbl. This one escaped me probably because the comment is at the top,
> so I didn't see it when just reviewing the patch. I should obviously
> have caught it anyway since the list was so obviously sorted before.
> My bad. I'll send a patch in a bit.

I've already a patch in my fixes.  It'll appear in -next probably after
the weekend (as next doesn't update over weekends.)

Note that the misordering is not due to these patches, but other previous
patches.


From olof at lixom.net  Fri Jul 26 20:05:55 2013
From: olof at lixom.net (Olof Johansson)
Date: Fri, 26 Jul 2013 17:05:55 -0700
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130727000453.GC24642@n2100.arm.linux.org.uk>
References: <20130726145639.116237136@gmail.com>
 <20130726151223.045835540@gmail.com>
 <20130726152918.GL29916@titan.lakedaemon.net>
 <20130726215859.GA19469@glitch>
 <20130726231108.GA10812@obsidianresearch.com>
 <20130726234237.GB24642@n2100.arm.linux.org.uk>
 <CAOesGMiPHh1FcWM1Tfvq+e-9znQ6zRKGwmzJGe+jGj5GZsaGqA@mail.gmail.com>
 <20130727000453.GC24642@n2100.arm.linux.org.uk>
Message-ID: <CAOesGMh01WMmhUyNa-usF8q-mYVp41RZRc=j1LPbv-hu0ftDyQ@mail.gmail.com>

On Fri, Jul 26, 2013 at 5:04 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Fri, Jul 26, 2013 at 05:01:08PM -0700, Olof Johansson wrote:
>> On Fri, Jul 26, 2013 at 4:42 PM, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>> > Thank you for making me look at that file and see how people fail to read
>> > my comments about keeping stuff appropriately sorted.  Really makes me
>> > wonder why I bother.
>>
>> Grmbl. This one escaped me probably because the comment is at the top,
>> so I didn't see it when just reviewing the patch. I should obviously
>> have caught it anyway since the list was so obviously sorted before.
>> My bad. I'll send a patch in a bit.
>
> I've already a patch in my fixes.  It'll appear in -next probably after
> the weekend (as next doesn't update over weekends.)
>
> Note that the misordering is not due to these patches, but other previous
> patches.

Ok, sounds good.

And yeah, it's pretty obvious based on the order that it has crept in over time.


-Olof


From tim.kryger at linaro.org  Fri Jul 26 20:13:46 2013
From: tim.kryger at linaro.org (Tim Kryger)
Date: Fri, 26 Jul 2013 17:13:46 -0700
Subject: [PATCH v3 2/3] ARM: bcm281xx: Device Tree bindings for GPIO driver
In-Reply-To: <CAPdLdqnq21zPNdJ_4iYS96yQH1XeuTp-TbwHpvkwsECHEKOKaQ@mail.gmail.com>
References: <1374870345-8276-1-git-send-email-markus.mayer@linaro.org>
 <1374870345-8276-3-git-send-email-markus.mayer@linaro.org>
 <51F2F37B.8030306@wwwdotorg.org>
 <CAPdLdqmU0aw5h_KYcD-E=isC9U3mZF6fzr_GVdjUUAW4_PUD5Q@mail.gmail.com>
 <51F301C4.4070807@wwwdotorg.org>
 <CAPdLdqnq21zPNdJ_4iYS96yQH1XeuTp-TbwHpvkwsECHEKOKaQ@mail.gmail.com>
Message-ID: <CAAYSxhrXg=dnhUzMuV=t=oQrnMQUWvLFydGEJD2pZV+EEPGLuA@mail.gmail.com>

On Fri, Jul 26, 2013 at 4:22 PM, Markus Mayer <markus.mayer at linaro.org> wrote:
> On 26 July 2013 16:09, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> Isn't this a property of the SoC's IP block, not of the board?
>
> Yes. I wasn't very precise with my statement.
>
> What I added to the description is "Specify at least 1 GPIO interrupt.
> The maximum number is 6."

The IP has a configurable number of banks, each of which has its own
interrupt.  If a particular SoC was configured to have six banks then
you need to list six interrupts in the DTS.  Perhaps it would help to
spell that out that relationship explicitly in the documentation
rather than talking about a minimum or maximum number of interrupts?
Also, you may want to mention that interrupts should to be ordered by
bank number.


From padma.kvr at gmail.com  Fri Jul 26 21:08:02 2013
From: padma.kvr at gmail.com (Padma Venkat)
Date: Sat, 27 Jul 2013 06:38:02 +0530
Subject: [PATCH V2 2/8] ASoC: Samsung: I2S: Add quirks as driver data in
 I2S
In-Reply-To: <20130726145319.GI9858@sirena.org.uk>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-3-git-send-email-padma.v@samsung.com>
 <20130726145319.GI9858@sirena.org.uk>
Message-ID: <CAAgF-BerOfvhPJemVf0HBK5L4edw7pgm9bgwKGL+XSMpoaR3vw@mail.gmail.com>

Hi Mark,

On Fri, Jul 26, 2013 at 8:23 PM, Mark Brown <broonie at kernel.org> wrote:
> On Fri, Jul 26, 2013 at 07:06:46PM +0530, Padmavathi Venna wrote:
>> Samsung has different versions of I2S introduced in different
>> platforms. Each version has some new support added for multichannel,
>> secondary fifo, s/w reset control and internal mux for rclk src clk.
>> Each newly added change has a quirk. So this patch adds all the
>> required quirks as driver data and based on compatible string from
>> dtsi fetches the quirks.
>
> As Russell indicated you should really keep the old name around, though
> marking them as deprecated is OK.  However I'm not sure anyone will have
> deployed this so I'm not sure how much it matters - every downstream
> kernel I've seen was still using board files anyway.


This is there only on exynos5250.dtsi, so changing this file alone is
enough. patch3 in
this series have the same.

>
> The actual meat of the patch changing to a quirk scheme does look good,
> though.
>
>> -- compatible : "samsung,i2s-v5"
>> +- compatible : should be one of the following.
>> +   - samsung,s3c6410-i2s: for 8/16/24bit stereo I2S. Previous versions
>> +     has only 8/16bit support.
>> +   - samsung,s3c6410-i2sv4: for 8/16/24bit multichannel(5.1 channel) I2S.
>> +     Introduced in s3c6410. This also applicable for s5p64x0 platforms.
>> +   - samsung,s5pc100-i2s: for 8/16/24bit multichannel(5.1 channel) I2S
>> +     with secondary fifo and s/w reset control.
>> +   - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with
>> +     secondary fifo, s/w reset control and internal mux for root clk src.
>> +
>
> I think the -vN naming scheme was fine - I see where this came from but
> the main point was about having things identified by a string not
> switching the naming scheme.  As you can see from the s3c6410 stuff the
> SoC isn't that helpful as a naming scheme as multiple IP versions appear
> on the same SoC.

Having only the version info is confusing. When I posted my previous version of
patches I was clear which version introduced in which platform and
again if I come
back today and see I again had to search each SoC datasheet. So I think this
patch now clearly explains what new support introduced in which
version of IP and which
SoC platform.

Thanks
Padma


From padma.kvr at gmail.com  Fri Jul 26 21:09:39 2013
From: padma.kvr at gmail.com (Padma Venkat)
Date: Sat, 27 Jul 2013 06:39:39 +0530
Subject: [PATCH V2 0/8] Add audio support on smdk5420
In-Reply-To: <3356470.kOAo7kipSf@amdc1227>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <3356470.kOAo7kipSf@amdc1227>
Message-ID: <CAAgF-BeQRioZOX3aEmExK9SqkXtM=P4oUXuHgC4u2mNYBE_kPA@mail.gmail.com>

On Fri, Jul 26, 2013 at 7:52 PM, Tomasz Figa <t.figa at samsung.com> wrote:
> Hi Padmavathi,
>
> On Friday 26 of July 2013 19:06:44 Padmavathi Venna wrote:
>> Samsung has different versions of I2S introduced in different
>> platforms. Each version has some new support added for multichannel,
>> secondary fifo, s/w reset control, internal mux for rclk src clk and
>> tdm support. Each newly added change has a quirk. So this patch adds
>> all the required quirks as driver data and based on compatible string
>> from dtsi fetches the quirks. This also adds i2s support on exynos5420
>> and make relevent changes in the dtsi files.
>>
>> Changes since V1:
>>       - Pass quirks as driver data and fetch the quirks based on
>>         compatible string from dtsi file as suggested by
>>         Tomasz Figa and Mark Brown
>>       - Make the I2S driver more flexible with respect to register
>>         access as suggested by Tomasz Figa and Mark Brown
>>       - Add 5420 support in the driver.
>>       - Modify the dtsi files with the corresponding compatible
>>         strings and removed the i2s quirks from 5250 dtsi file.
>>       - Updated the i2s Documentation with relevent changes and
>>         i2s versioning info.
>>       - Add i2s nodes on exynos5420.dtsi
>>       - Enable sound support on smdk5420
>>
>> This patch set is dependent on the following dma and audio subsystem
>> clk controller patches.
>> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20661
>> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20668
>>
>> This patch set is made based on Kukjin Kim for-next branch.
>>
>> Andrew Bresticker (1):
>>   ARM: dts: exynos5420: add i2s controllers
>>
>> Padmavathi Venna (7):
>>   platform: Increase platform name size
>>   ASoC: Samsung: I2S: Add quirks as driver data in I2S
>>   ARM: dts: Change i2s compatible string on exynos5250
>>   ASoC: Samsung: I2S: Modify driver to give more flexibility
>>   ASoC: Samsung: I2S: Modify the I2S driver to support I2S on
>>     Exynos5420
>>   ARM: dts: wm8994: Add wm8994 support on smdk5420
>>   ARM: dts: Enable sound support on smdk5420
>>
>>  .../devicetree/bindings/sound/samsung-i2s.txt      |   25 ++-
>>  arch/arm/boot/dts/exynos5250.dtsi                  |    9 +-
>>  arch/arm/boot/dts/exynos5420-smdk5420.dts          |   60 ++++++
>>  arch/arm/boot/dts/exynos5420.dtsi                  |   44 +++++
>>  include/linux/mod_devicetable.h                    |    2 +-
>>  include/linux/platform_data/asoc-s3c.h             |    1 +
>>  sound/soc/samsung/i2s-regs.h                       |   51 ++++--
>>  sound/soc/samsung/i2s.c                            |  205
>> +++++++++++++++----- 8 files changed, 312 insertions(+), 85 deletions(-)
>
> Please resend the whole series again using correct devicetree mailing list,
> which is:
>
> devicetree at vger.kernel.org
>
> The old one (devicetree-discuss at lists.ozlabs.org) is no longer functioning.
>
> Best regards,
> Tomasz
>

 OK. I will post.

Thanks
Padma


From padma.kvr at gmail.com  Fri Jul 26 21:13:23 2013
From: padma.kvr at gmail.com (Padma Venkat)
Date: Sat, 27 Jul 2013 06:43:23 +0530
Subject: [PATCH V2 1/8] platform: Increase platform name size
In-Reply-To: <CAK9yfHxX7j8o3rQNzDM2eL6M66CJVcdGSz3XYR2-4i=5SmCinA@mail.gmail.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-2-git-send-email-padma.v@samsung.com>
 <CAK9yfHxX7j8o3rQNzDM2eL6M66CJVcdGSz3XYR2-4i=5SmCinA@mail.gmail.com>
Message-ID: <CAAgF-Bf2fkcZG27QmkhumpB27OkA+WR4vRb1rUumJpOaoDewcg@mail.gmail.com>

Hi Sachin,

On Fri, Jul 26, 2013 at 8:06 PM, Sachin Kamat <sachin.kamat at linaro.org> wrote:
> Hi Padma,
>
> On 26 July 2013 19:06, Padmavathi Venna <padma.v at samsung.com> wrote:
>> This patch increases the platform name size from 20 to 30.
>
> Instead of describing what the patch does (which is quite obvious from
> the code), it would be useful to describe why this change is required.

OK. I will post in my next version.

>
>
>>
>> Signed-off-by: Padmavathi Venna <padma.v at samsung.com>
>> ---
>>  include/linux/mod_devicetable.h |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
>> index b62d4af..f67b5d5 100644
>> --- a/include/linux/mod_devicetable.h
>> +++ b/include/linux/mod_devicetable.h
>> @@ -478,7 +478,7 @@ struct dmi_system_id {
>>  #define DMI_MATCH(a, b)        { .slot = a, .substr = b }
>>  #define DMI_EXACT_MATCH(a, b)  { .slot = a, .substr = b, .exact_match = 1 }
>>
>> -#define PLATFORM_NAME_SIZE     20
>> +#define PLATFORM_NAME_SIZE     30
>>  #define PLATFORM_MODULE_PREFIX "platform:"
>>
>>  struct platform_device_id {
>> --
>> 1.7.4.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> With warm regards,
> Sachin

Thanks
Padma


From padma.kvr at gmail.com  Fri Jul 26 21:16:40 2013
From: padma.kvr at gmail.com (Padma Venkat)
Date: Sat, 27 Jul 2013 06:46:40 +0530
Subject: [PATCH V2 7/8] ARM: dts: wm8994: Add wm8994 support on smdk5420
In-Reply-To: <20130726151902.GL9858@sirena.org.uk>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-8-git-send-email-padma.v@samsung.com>
 <20130726151902.GL9858@sirena.org.uk>
Message-ID: <CAAgF-Be8SNxTZv1yFCwH6yJ-O_3R4reh=3y+pSCLJYW7S9TkUg@mail.gmail.com>

Hi Mark,

On Fri, Jul 26, 2013 at 8:49 PM, Mark Brown <broonie at kernel.org> wrote:
> On Fri, Jul 26, 2013 at 07:06:51PM +0530, Padmavathi Venna wrote:
>> This patch adds wm8994 codec node on i2c bus1 and the required
>> regulator supplies and properties on smdk5420 board.
>
> This isn't a device tree patch for WM8994, it's a patch for the
> SMDK5420.

Yes. I will correct the subject.

>
>> +     vdd: fixed-regulator at 0 {
>> +             compatible = "regulator-fixed";
>> +             regulator-name = "vdd-supply";
>
> These names look wrong - they should reflect the names in the schematic
> as they're for human comprehensibility.  This may just be a case of
> dropping the -supply.

OK.

>
>> +             wm8994: wm8994 at 1a {
>> +                     compatible = "wlf,wm8994";
>> +                     reg = <0x1a>;
>> +
>> +                     gpio-controller;
>> +                     #gpio-cells = <2>;
>> +
>> +                     AVDD2-supply = <&vdd>;
>> +                     CPVDD-supply = <&vdd>;
>> +                     DBVDD-supply = <&dbvdd>;
>> +                     SPKVDD1-supply = <&spkvdd>;
>> +                     SPKVDD2-supply = <&spkvdd>;
>> +             };
>
> It would be helpful to also add a clock binding (I posted a binding
> documentation update the other day, it's in my tree now) but it's not
> essential and I suspect it needs some work on the clock driver side
> still.

OK. I will check this.

Thanks
Padma


From shc_work at mail.ru  Fri Jul 26 23:41:40 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 27 Jul 2013 07:41:40 +0400
Subject: [PATCH] ARM: imx: pllv1: Fix PLL calculation for i.MX27
Message-ID: <1374896500-21862-1-git-send-email-shc_work@mail.ru>

MFN bit 9 on i.MX27 has a different meaning than in other SOCs. This
is a just sign bit. This patch makes different calculation for i.MX27.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/mach-imx/clk-pllv1.c | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/clk-pllv1.c b/arch/arm/mach-imx/clk-pllv1.c
index c1eaee3..e76d601 100644
--- a/arch/arm/mach-imx/clk-pllv1.c
+++ b/arch/arm/mach-imx/clk-pllv1.c
@@ -25,6 +25,11 @@ struct clk_pllv1 {
 
 #define to_clk_pllv1(clk) (container_of(clk, struct clk_pllv1, clk))
 
+static inline bool allow_signed_mfn(void)
+{
+	return !cpu_is_mx1() && !cpu_is_mx21();
+}
+
 static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
 		unsigned long parent_rate)
 {
@@ -59,9 +64,14 @@ static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
 	/*
 	 * On all i.MXs except i.MX1 and i.MX21 mfn is a 10bit
 	 * 2's complements number
+	 * On i.MX27 the bit 9 is the sign bit.
 	 */
-	if (!cpu_is_mx1() && !cpu_is_mx21() && mfn >= 0x200)
-		mfn_abs = 0x400 - mfn;
+	if (allow_signed_mfn() && (mfn & 0x200)) {
+		if (cpu_is_mx27())
+			mfn_abs = mfn & 0x200;
+		else
+			mfn_abs = 0x400 - mfn;
+	}
 
 	rate = parent_rate * 2;
 	rate /= pd + 1;
@@ -70,7 +80,7 @@ static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
 
 	do_div(ll, mfd + 1);
 
-	if (!cpu_is_mx1() && !cpu_is_mx21() && mfn >= 0x200)
+	if (allow_signed_mfn() && (mfn & 0x200))
 		ll = -ll;
 
 	ll = (rate * mfi) + ll;
-- 
1.8.1.5



From paul at pwsan.com  Sat Jul 27 00:10:56 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Sat, 27 Jul 2013 04:10:56 +0000 (UTC)
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <20130724142059.GJ11072@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724142059.GJ11072@mudshark.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>


Tonight I put on a Jon Hopkins album, in recollection of my UK ARM Linux 
colleagues perhaps, and started testing, and eventually wound up with this 
one:

commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc
Author: Will Deacon <will.deacon at arm.com>
Date:   Wed Jun 12 12:25:56 2013 +0100

    ARM: 7757/1: mm: don't flush icache in switch_mm with hardware broadcasting
    
    When scheduling an mm on a CPU where it hasn't previously been used, we
    flush the icache on that CPU so that any code loaded previously on
    a different core can be safely executed.
    
    For cores with hardware broadcasting of cache maintenance operations,
    this is clearly unnecessary, since the inner-shareable invalidation in
    __sync_icache_dcache will affect all CPUs.
    
    This patch conditionalises the icache flush in switch_mm based on
    cache_ops_need_broadcast().
    
    Acked-by: Catalin Marinas <catalin.marinas at arm.com>
    Reported-by: Albin Tonnerre <albin.tonnerre at arm.com>
    Signed-off-by: Will Deacon <will.deacon at arm.com>
    Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>

...

v3.11-rc2 boots with it reverted.  What also works is v3.11-rc2 with the 
below patch applied.

Would be pleased to boot-test anything you'd care to send my way, as long 
as you can tolerate response latency jitter.


- Paul

diff --git a/arch/arm/include/asm/mmu_context.h b/arch/arm/include/asm/mmu_context.h
index b5792b7..8dfb295 100644
--- a/arch/arm/include/asm/mmu_context.h
+++ b/arch/arm/include/asm/mmu_context.h
@@ -112,7 +112,7 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
 	 * so check for possible thread migration and invalidate the I-cache
 	 * if we're new to this CPU.
 	 */
-	if (cache_ops_need_broadcast() &&
+	if (1 &&
 	    !cpumask_empty(mm_cpumask(next)) &&
 	    !cpumask_test_cpu(cpu, mm_cpumask(next)))
 		__flush_icache_all();




From b.brezillon at overkiz.com  Sat Jul 27 00:41:49 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Sat, 27 Jul 2013 06:41:49 +0200
Subject: [PATCH v2 00/42] ARM: at91: move to common clk framework
In-Reply-To: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <51F34F8D.4000106@overkiz.com>

Hello,

This email is a feedback on the discussion I had with Jean-Christophe 
last Wednesday.

As discussed with him, I will try to split this patch series in order to

1) limit the number of patches to review
2) limit the number of SoCs/boards to test

The new at91 clk support on non-dt boards was also discussed, and 
Jean-Christophe thinks this is not mandatory (and should be dropped). 
Does anyone see an interest in keeping this support in the next version 
of the patch series ?

Here is how he though this patch series could be splitted:
1) at91 common clk implemenations + 1 SoC and the associated dt boards
2) 1 SoC and the associated dt boards
...)1 SoC and the associated dt boards

I tried to prepare the first new patch series by including only 
at91sam9260/9g20 SoCs and boards but I failed. In fact I succeed but it 
breaks multi-soc support (using dt) because we can't use both the common 
clk framework and the at91 specific clk framework (they both provides 
the same set of functions and structures definitions).

Should I break the multi-soc support to add at91 common clk ?

The only SoC that could be added without breaking multi-soc support is 
the sama5 as it uses a different arm architecture (ARMv7) and thus 
cannot be compiled in the same kernel as other at91 socs.

Should I choose the sama5 for the next patch series ?

Jean-Christophe, could you at least review the 11 first patches of this 
series ?
I won't send any new version until I get some feedback from you on the 
clk implementations and dt bindings...

Berst Regards,

Boris


Le 17/07/2013 15:34, Boris BREZILLON a ?crit :
> Hello,
>
> This patch series is a proposal to move at91 clock implementation
> to common clk framework.
>
> Most of the clock provided by the PMC (Power Management Controller) are
> implemented :
> - main clock (main oscillator)
> - pll clocks
> - master clock
> - programmable clocks
> - utmi clock
> - peripheral clocks
> - system clocks
>
> This implementation is compatible with device tree: the goal is
> to define the whole clock tree in the device tree (all currently
> available dt SoCs and boards are patched to support dt clocks).
> Please feel free to comment the dt bindinds.
>
> I removed the register_clocks function in SoC supporting dt boards only:
> - at91sam9x5 SoCs
> - at91sam9n12 SoC
> - sama5d3 SoCs
>
> This patch series is based on linux-next and has been tested on sama5d31ek
> board using device tree. It compiles for other SoCs and both with and without
> dt support, but it has not been tested.
>
> BTW could other people test it on other boards (I only have a kizbox and
> a sama5d31ek dev kit).
>
> Best Regards,
> Boris
>
> Changes since v1:
>   - fix bugs in pll, programmable and system clock implementations
>     (wrong bit position).
>   - add usb clock configuration support (ohci and udc drivers +
>     clk_lookup for non dt boards)
>   - rework of the system clock interfaces (no need to define a parent clock,
>     system clock is a gate with no rate info)
>   - change system, peripheral and programmable clk dt bindings (1 master node
>     and multiple child nodes each defining a system/peripheral or prog clock)
>   - fix bugs in sama5 dt definition
>
> Boris BREZILLON (42):
>    ARM: at91: move at91_pmc.h to include/linux/clk/at91.h
>    ARM: at91: add PMC main clock
>    ARM: at91: add PMC pll clocks
>    ARM: at91: add PMC master clock
>    ARM: at91: add PMC system clocks
>    ARM: at91: add PMC peripheral clocks
>    ARM: at91: add PMC programmable clocks
>    ARM: at91: add PMC utmi clock
>    ARM: at91: add PMC usb clock
>    ARM: at91: add PMC smd clock
>    ARM: at91: add PMC clk device tree binding doc.
>    ARM: at91: move to common clk framework
>    ARM: at91: move at91rm9200 SoC to new at91 clk implem
>    ARM: at91: move at91sam9260 SoC to new at91 clk implem
>    ARM: at91: move at91sam9261 SoC to new at91 clk implem
>    ARM: at91: move at91sam9263 SoC to new at91 clk implem
>    ARM: at91: move at91sam9g45 SoC to new at91 clk implem
>    ARM: at91: move at91sam9n12 SoC to new at91 clk implem
>    ARM: at91: move at91sam9rl SoC to new at91 clk implem
>    ARM: at91: move at91sam9x5 SoCs to new at91 clk implem
>    ARM: at91: move at91sam9 SoCs to new at91 clk implem
>    ARM: at91: move sama5d3 SoCs to new at91 clk implem
>    ARM: at91: move at91rm9200 boards to new at91 clk implem
>    ARM: at91: move at91sam9 boards to new at91 clk implem
>    ARM: at91: move pit timer to common clk framework
>    USB: ohci-at91: add usb_clk for transition to common clk framework
>    usb: gadget: at91_udc: add usb_clk for transition to common clk
>      framework
>    ARM: at91/dt: move at91rm9200 SoC to new at91 clk implem
>    ARM: at91/dt: move at91sam9260 SoC to new at91 clk implem
>    ARM: at91/dt: move at91sam9263 SoC to new at91 clk implem
>    ARM: at91/dt: move at91sam9g45 SoC to new at91 clk implem
>    ARM: at91/dt: move at91sam9n12 SoC to new at91 clk implem
>    ARM: at91/dt: move at91sam9x5 SoCs to new at91 clk implem
>    ARM: at91/dt: move at91sam9g20 SoC to new at91 clk implem
>    ARM: at91/dt: move sama5d3 SoCs to new at91 clk implem
>    ARM: at91/dt: move sam9260/sam9g20 to new at91 clk implem
>    ARM: at91/dt: move rm9200 boards to new at91 clk implem
>    ARM: at91/dt: move sam9263 boards to new at91 clk implem
>    ARM: at91/dt: move sam9g45 boards to new at91 clk implem
>    ARM: at91/dt: move sam9n12 boards to new at91 clk implem
>    ARM: at91/dt: move sam9x5 boards to new at91 clk implem
>    ARM: at91/dt: move sama5d3 boards to new at91 clk implem
>
>   .../devicetree/bindings/clock/at91-clock.txt       |  262 ++++++
>   arch/arm/boot/dts/animeo_ip.dts                    |   17 +-
>   arch/arm/boot/dts/at91-ariag25.dts                 |   17 +-
>   arch/arm/boot/dts/at91rm9200.dtsi                  |  231 +++++
>   arch/arm/boot/dts/at91rm9200ek.dts                 |   17 +-
>   arch/arm/boot/dts/at91sam9260.dtsi                 |  236 +++++
>   arch/arm/boot/dts/at91sam9263.dtsi                 |  237 +++++
>   arch/arm/boot/dts/at91sam9263ek.dts                |   17 +-
>   arch/arm/boot/dts/at91sam9g15.dtsi                 |    1 +
>   arch/arm/boot/dts/at91sam9g20.dtsi                 |   37 +
>   arch/arm/boot/dts/at91sam9g20ek_common.dtsi        |   17 +-
>   arch/arm/boot/dts/at91sam9g25.dtsi                 |    3 +
>   arch/arm/boot/dts/at91sam9g35.dtsi                 |    2 +
>   arch/arm/boot/dts/at91sam9g45.dtsi                 |  257 +++++
>   arch/arm/boot/dts/at91sam9m10g45ek.dts             |   17 +-
>   arch/arm/boot/dts/at91sam9n12.dtsi                 |  251 +++++
>   arch/arm/boot/dts/at91sam9n12ek.dts                |   17 +-
>   arch/arm/boot/dts/at91sam9x25.dtsi                 |   25 +-
>   arch/arm/boot/dts/at91sam9x35.dtsi                 |    3 +
>   arch/arm/boot/dts/at91sam9x5.dtsi                  |  319 +++++--
>   arch/arm/boot/dts/at91sam9x5_can.dtsi              |   26 +
>   arch/arm/boot/dts/at91sam9x5_isi.dtsi              |   22 +
>   arch/arm/boot/dts/at91sam9x5_lcdc.dtsi             |   28 +
>   arch/arm/boot/dts/at91sam9x5_macb0.dtsi            |   66 ++
>   arch/arm/boot/dts/at91sam9x5_macb1.dtsi            |   54 ++
>   arch/arm/boot/dts/at91sam9x5_usart3.dtsi           |   58 ++
>   arch/arm/boot/dts/ge863-pro3.dtsi                  |   16 +-
>   arch/arm/boot/dts/kizbox.dts                       |    5 +
>   arch/arm/boot/dts/mpa1600.dts                      |   16 +-
>   arch/arm/boot/dts/pm9g45.dts                       |   16 +-
>   arch/arm/boot/dts/sama5d3.dtsi                     |  510 ++++++----
>   arch/arm/boot/dts/sama5d31ek.dts                   |    4 +
>   arch/arm/boot/dts/sama5d33ek.dts                   |    2 +
>   arch/arm/boot/dts/sama5d34ek.dts                   |    4 +
>   arch/arm/boot/dts/sama5d35ek.dts                   |    6 +
>   arch/arm/boot/dts/sama5d3_can.dtsi                 |   71 ++
>   arch/arm/boot/dts/sama5d3_emac.dtsi                |   54 ++
>   arch/arm/boot/dts/sama5d3_gmac.dtsi                |   87 ++
>   arch/arm/boot/dts/sama5d3_lcd.dtsi                 |   69 ++
>   arch/arm/boot/dts/sama5d3_mci2.dtsi                |   57 ++
>   arch/arm/boot/dts/sama5d3_tcb1.dtsi                |   38 +
>   arch/arm/boot/dts/sama5d3_uart.dtsi                |   46 +
>   arch/arm/boot/dts/sama5d3xcm.dtsi                  |   17 +-
>   arch/arm/boot/dts/tny_a9260_common.dtsi            |   17 +-
>   arch/arm/boot/dts/tny_a9263.dts                    |   17 +-
>   arch/arm/boot/dts/usb_a9260_common.dtsi            |   17 +-
>   arch/arm/boot/dts/usb_a9263.dts                    |   17 +-
>   arch/arm/mach-at91/Kconfig                         |   26 +
>   arch/arm/mach-at91/Makefile                        |    2 +-
>   arch/arm/mach-at91/at91rm9200.c                    |  568 +++++++-----
>   arch/arm/mach-at91/at91sam9260.c                   |  689 +++++++++-----
>   arch/arm/mach-at91/at91sam9261.c                   |  572 ++++++++----
>   arch/arm/mach-at91/at91sam9263.c                   |  595 +++++++-----
>   arch/arm/mach-at91/at91sam926x_time.c              |   21 +-
>   arch/arm/mach-at91/at91sam9g45.c                   |  704 ++++++++------
>   arch/arm/mach-at91/at91sam9g45_devices.c           |    1 -
>   arch/arm/mach-at91/at91sam9n12.c                   |  196 +---
>   arch/arm/mach-at91/at91sam9rl.c                    |  502 ++++++----
>   arch/arm/mach-at91/at91sam9x5.c                    |  293 +-----
>   arch/arm/mach-at91/board-1arm.c                    |   12 +-
>   arch/arm/mach-at91/board-afeb-9260v1.c             |   11 +-
>   arch/arm/mach-at91/board-cam60.c                   |   13 +-
>   arch/arm/mach-at91/board-carmeva.c                 |   13 +-
>   arch/arm/mach-at91/board-cpu9krea.c                |   12 +-
>   arch/arm/mach-at91/board-cpuat91.c                 |   12 +-
>   arch/arm/mach-at91/board-csb337.c                  |   11 +-
>   arch/arm/mach-at91/board-csb637.c                  |   11 +-
>   arch/arm/mach-at91/board-dt-rm9200.c               |    9 +-
>   arch/arm/mach-at91/board-dt-sam9.c                 |    9 +-
>   arch/arm/mach-at91/board-dt-sama5.c                |    9 +-
>   arch/arm/mach-at91/board-eb9200.c                  |   11 +-
>   arch/arm/mach-at91/board-ecbat91.c                 |   12 +-
>   arch/arm/mach-at91/board-eco920.c                  |   13 +-
>   arch/arm/mach-at91/board-flexibity.c               |   12 +-
>   arch/arm/mach-at91/board-foxg20.c                  |   12 +-
>   arch/arm/mach-at91/board-gsia18s.c                 |    8 +-
>   arch/arm/mach-at91/board-kafa.c                    |   12 +-
>   arch/arm/mach-at91/board-kb9202.c                  |   12 +-
>   arch/arm/mach-at91/board-pcontrol-g20.c            |    9 +-
>   arch/arm/mach-at91/board-picotux200.c              |   11 +-
>   arch/arm/mach-at91/board-qil-a9260.c               |   11 +-
>   arch/arm/mach-at91/board-rm9200ek.c                |   11 +-
>   arch/arm/mach-at91/board-rsi-ews.c                 |   12 +-
>   arch/arm/mach-at91/board-sam9-l9260.c              |   11 +-
>   arch/arm/mach-at91/board-sam9260ek.c               |   11 +-
>   arch/arm/mach-at91/board-sam9261ek.c               |   15 +-
>   arch/arm/mach-at91/board-sam9263ek.c               |   11 +-
>   arch/arm/mach-at91/board-sam9g20ek.c               |   15 +-
>   arch/arm/mach-at91/board-sam9m10g45ek.c            |   11 +-
>   arch/arm/mach-at91/board-sam9rlek.c                |   11 +-
>   arch/arm/mach-at91/board-snapper9260.c             |   12 +-
>   arch/arm/mach-at91/board-stamp9g20.c               |   15 +-
>   arch/arm/mach-at91/board-yl-9200.c                 |   12 +-
>   arch/arm/mach-at91/clock.c                         |  977 --------------------
>   arch/arm/mach-at91/clock.h                         |   49 -
>   arch/arm/mach-at91/generic.h                       |   10 +-
>   arch/arm/mach-at91/pm.c                            |    2 +-
>   arch/arm/mach-at91/pm_slowclock.S                  |    2 +-
>   arch/arm/mach-at91/pmc.c                           |   58 ++
>   arch/arm/mach-at91/sama5d3.c                       |  344 +------
>   arch/arm/mach-at91/setup.c                         |   38 +-
>   arch/arm/mach-at91/stamp9g20.h                     |    2 +-
>   drivers/clk/Makefile                               |    1 +
>   drivers/clk/at91/Makefile                          |   11 +
>   drivers/clk/at91/clk-main.c                        |  106 +++
>   drivers/clk/at91/clk-master.c                      |  317 +++++++
>   drivers/clk/at91/clk-peripheral.c                  |  371 ++++++++
>   drivers/clk/at91/clk-pll.c                         |  438 +++++++++
>   drivers/clk/at91/clk-plldiv.c                      |  125 +++
>   drivers/clk/at91/clk-programmable.c                |  368 ++++++++
>   drivers/clk/at91/clk-smd.c                         |  157 ++++
>   drivers/clk/at91/clk-system.c                      |  184 ++++
>   drivers/clk/at91/clk-usb.c                         |  303 ++++++
>   drivers/clk/at91/clk-utmi.c                        |  114 +++
>   drivers/usb/gadget/at91_udc.c                      |   31 +-
>   drivers/usb/gadget/at91_udc.h                      |    2 +-
>   drivers/usb/gadget/atmel_usba_udc.c                |    2 +-
>   drivers/usb/host/ohci-at91.c                       |   16 +-
>   .../mach/at91_pmc.h => include/linux/clk/at91.h    |  116 ++-
>   119 files changed, 8193 insertions(+), 3835 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/clock/at91-clock.txt
>   create mode 100644 arch/arm/boot/dts/at91sam9x5_can.dtsi
>   create mode 100644 arch/arm/boot/dts/at91sam9x5_isi.dtsi
>   create mode 100644 arch/arm/boot/dts/at91sam9x5_lcdc.dtsi
>   create mode 100644 arch/arm/boot/dts/at91sam9x5_macb0.dtsi
>   create mode 100644 arch/arm/boot/dts/at91sam9x5_macb1.dtsi
>   create mode 100644 arch/arm/boot/dts/at91sam9x5_usart3.dtsi
>   create mode 100644 arch/arm/boot/dts/sama5d3_can.dtsi
>   create mode 100644 arch/arm/boot/dts/sama5d3_emac.dtsi
>   create mode 100644 arch/arm/boot/dts/sama5d3_gmac.dtsi
>   create mode 100644 arch/arm/boot/dts/sama5d3_lcd.dtsi
>   create mode 100644 arch/arm/boot/dts/sama5d3_mci2.dtsi
>   create mode 100644 arch/arm/boot/dts/sama5d3_tcb1.dtsi
>   create mode 100644 arch/arm/boot/dts/sama5d3_uart.dtsi
>   delete mode 100644 arch/arm/mach-at91/clock.c
>   delete mode 100644 arch/arm/mach-at91/clock.h
>   create mode 100644 arch/arm/mach-at91/pmc.c
>   create mode 100644 drivers/clk/at91/Makefile
>   create mode 100644 drivers/clk/at91/clk-main.c
>   create mode 100644 drivers/clk/at91/clk-master.c
>   create mode 100644 drivers/clk/at91/clk-peripheral.c
>   create mode 100644 drivers/clk/at91/clk-pll.c
>   create mode 100644 drivers/clk/at91/clk-plldiv.c
>   create mode 100644 drivers/clk/at91/clk-programmable.c
>   create mode 100644 drivers/clk/at91/clk-smd.c
>   create mode 100644 drivers/clk/at91/clk-system.c
>   create mode 100644 drivers/clk/at91/clk-usb.c
>   create mode 100644 drivers/clk/at91/clk-utmi.c
>   rename arch/arm/mach-at91/include/mach/at91_pmc.h => include/linux/clk/at91.h (78%)
>



From richardcochran at gmail.com  Sat Jul 27 00:57:24 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Sat, 27 Jul 2013 06:57:24 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <51F2A57D.1090704@gmail.com>
References: <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726141016.GF9858@sirena.org.uk>
 <CAOesGMhEr3DiFm5uSgoHPFUMY4jWu4HkeTU2UmOGj=dS75Vk+g@mail.gmail.com>
 <51F2A57D.1090704@gmail.com>
Message-ID: <20130727045723.GA4221@netboy>

On Fri, Jul 26, 2013 at 11:36:13AM -0500, Rob Herring wrote:
> On 07/26/2013 10:49 AM, Olof Johansson wrote:
> > On Fri, Jul 26, 2013 at 7:10 AM, Mark Brown <broonie at kernel.org> wrote:
> >> On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
> >>
> >>> Unless I totally misunderstood, the thread is talking about letting
> >>> established bindings change with each new kernel version.  I am
> >>> opposed to that.
> >>
> >> No, nobody is really saying that is a particularly good idea.  There is
> >> some debate about how we work out what an established binding is but
> >> there's no serious suggestion that we don't want stable bindings.
> > 
> > Yes, what Mark said -- _today_ all bindings are subject to change and
> > can be changed in lockstep with the kernel. This has been necessary as
> > part of development to sort out all of the various bootstrapping
> > issues across platforms.

This statement is an incredible piece of doublespeak. "Of course we
want stable bindings. That is why 'all bindings are subject to change
and can be changed in lockstep with the kernel.'"

If you want to get away from the DT churn, then you have got to tell
people in no uncertain terms that bindings in a released kernel are a
stable ABI and must be supported into the future.

If you need a playground for new ideas, refactoring platforms, etc,
then go right ahead and create one, but please don't do this with
released kernels.

> This is absolutely not true on a global basis. Any binding used on
> powerpc or sparc is not subject to change. Furthermore, there are ARM
> platforms such as highbank where the bindings are expected to be stable.
> That's not saying they don't change (new properties for SATA just
> today), but they only change in a backwards compatible way.

Right, and lets hope the arm tree can also take this stand.

Thanks,
Richard


From richardcochran at gmail.com  Sat Jul 27 01:04:08 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Sat, 27 Jul 2013 07:04:08 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <CAOesGMhEr3DiFm5uSgoHPFUMY4jWu4HkeTU2UmOGj=dS75Vk+g@mail.gmail.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726141016.GF9858@sirena.org.uk>
 <CAOesGMhEr3DiFm5uSgoHPFUMY4jWu4HkeTU2UmOGj=dS75Vk+g@mail.gmail.com>
Message-ID: <20130727050406.GB4221@netboy>

On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:
> 
> Long term, final goal is likely to be close to what Russell is saying

Why is this a long term goal? Start today.

> -- nothing should go into the kernel tree unless the binding is in a
> fully stable state. However, we have a transitional period between now
> and then, and even when we're at the final state there will be need to
> have some sort of sandbox for development and test of future bindings.

Why not just set up a git tree right away?

> Dealing with all that, as well as the actual process for locking in
> bindings, is what needs to be sorted out.
> 
> I think we're all in agreement that bindings that change over time are
> nothing but pain, but we're arguing that in circles anyway.

No.

I keep saying, the bindings must be stable ABI, *today*.

You keep saying, maybe later, but until then we will make things up as
we go along.

Thanks,
Richard


From daniel.lezcano at linaro.org  Sat Jul 27 02:13:31 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sat, 27 Jul 2013 08:13:31 +0200
Subject: [RESEND] cpuidle for ARM pull request
In-Reply-To: <1598661.FpX5cmjM1U@vostro.rjw.lan>
References: <51E536C5.1020609@linaro.org> <1766778.ZYeDKBOsjV@vostro.rjw.lan>
 <2075555.RCmWLFAfjq@vostro.rjw.lan> <1598661.FpX5cmjM1U@vostro.rjw.lan>
Message-ID: <51F3650B.8080708@linaro.org>

On 07/26/2013 02:07 AM, Rafael J. Wysocki wrote:
> On Friday, July 26, 2013 12:41:09 AM Rafael J. Wysocki wrote:
>> On Friday, July 26, 2013 12:29:08 AM Rafael J. Wysocki wrote:
>>> On Friday, July 26, 2013 12:07:03 AM Daniel Lezcano wrote:
>>>> On 07/16/2013 02:04 PM, Daniel Lezcano wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> The first PR was against the linux-pm-next tree including the patch:
>>>>>
>>>>> "cpuidle: Add Kconfig.arm and move calxeda, kirkwood and zynq"
>>>>>
>>>>> This patch has been dropped in the meantime.
>>>>>
>>>>> Here is a new PR where my tree has been rebased against linux-pm-next
>>>>> and adding the patch mentioned above.
>>>>>
>>>>> As stated by Rafael, I will handle the ARM specific patches from now.
>>>>>
>>>>> The following changes since commit 48f99d5a97d32d70c0738d6e314d9f4dbefd89bf:
>>>>>
>>>>>   Merge branch 'pm-cpuidle-next' into linux-next (2013-07-16 02:41:06 +0200)
>>>>>
>>>>> are available in the git repository at:
>>>>>
>>>>>
>>>>>   git://git.linaro.org/people/dlezcano/linux.git cpuidle/arm-next
>>>>>
>>>>> for you to fetch changes up to 2b7e79f4a75e803184f483985a25cc751a990f06:
>>>>>
>>>>>   ARM: ux500: cpuidle: Move ux500 cpuidle driver to drivers/cpuidle
>>>>> (2013-07-16 13:57:24 +0200)
>>>>
>>>> ping ?
>>>
>>> Sorry, something distracted me.  I'll pull it later today unless there are any
>>> problems (in which case I'll let you know).
>>
>> Well, there are some.
>>
>> It is based on my linux-next branch, but please rebase it on top of 3.11-rc2.
>>
>> Generally, please send me pull requests based on -rc kernels only (or major
>> releases).
> 
> Unless your material depends on new things in my linux-next branch, in which
> case please let me know and I'll set up a stable branch for you to base things
> on.

Hi Rafael,

I rebased my branch on top of 3.11-rc2, you can try to pull it again.

I thought it would have been easier for us if I could based my PRs on
top of your linux-next branch, so acting as a proxy for ARM patches. I
am maintaining the clocksource drivers and I am basing my tree on top of
tip/core.

I guess you are rebasing your tree often and this is an issue for you,
right ?

Thanks
  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From shc_work at mail.ru  Sat Jul 27 02:56:52 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 27 Jul 2013 10:56:52 +0400
Subject: [PATCH] ARM: i.MX6Q clocks: Fix CKIH clock name
Message-ID: <1374908212-32008-1-git-send-email-shc_work@mail.ru>

i.MX6Q have only one High-frequency reference clock (CKIH).
Patch removes index from CKIH and makes name according datasheet.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/mach-imx/clk-imx6q.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 9181a24..8f2a8b5 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -292,7 +292,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 
 	clk[dummy] = imx_clk_fixed("dummy", 0);
 	clk[ckil] = imx_obtain_fixed_clock("ckil", 0);
-	clk[ckih] = imx_obtain_fixed_clock("ckih1", 0);
+	clk[ckih] = imx_obtain_fixed_clock("ckih", 0);
 	clk[osc] = imx_obtain_fixed_clock("osc", 0);
 
 	np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");
-- 
1.8.1.5



From shc_work at mail.ru  Sat Jul 27 03:19:45 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Sat, 27 Jul 2013 11:19:45 +0400
Subject: [PATCH] ARM: i.MX5 clocks: Remove optional clock setup (CKIH1) from
 i.MX51 template
Message-ID: <1374909585-2724-1-git-send-email-shc_work@mail.ru>

External high frequency clock CKIH1 is optional for i.MX51, so move
it setup into boards where it is used.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx51-apf51.dts   | 4 ----
 arch/arm/boot/dts/imx51-babbage.dts | 4 ++++
 arch/arm/boot/dts/imx51.dtsi        | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/imx51-apf51.dts b/arch/arm/boot/dts/imx51-apf51.dts
index 8f7f9ac..b360699 100644
--- a/arch/arm/boot/dts/imx51-apf51.dts
+++ b/arch/arm/boot/dts/imx51-apf51.dts
@@ -26,10 +26,6 @@
 	};
 
 	clocks {
-		ckih1 {
-			clock-frequency = <0>;
-		};
-
 		osc {
 			clock-frequency = <33554432>;
 		};
diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
index 7c670a6..1d337d9 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -63,6 +63,10 @@
 	};
 
 	clocks {
+		ckih1 {
+			clock-frequency = <22579200>;
+		};
+
 		clk_26M: codec_clock {
 			compatible = "fixed-clock";
 			reg=<0>;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index d7b0646..f0b25c9 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -47,7 +47,7 @@
 
 		ckih1 {
 			compatible = "fsl,imx-ckih1", "fixed-clock";
-			clock-frequency = <22579200>;
+			clock-frequency = <0>;
 		};
 
 		ckih2 {
-- 
1.8.1.5



From richardcochran at gmail.com  Sat Jul 27 04:48:26 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Sat, 27 Jul 2013 10:48:26 +0200
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130726171524.GB28895@obsidianresearch.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726045433.GB4100@netboy>
 <20130726171524.GB28895@obsidianresearch.com>
Message-ID: <20130727084825.GA4707@netboy>

On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote:
> 
> Further, every other kernel release tended to break the board.c files,
> just due to the usual kernel churn.

Yes...

> DT is much better, the stuff that can be described in DT is broader
> and more thought tends to have been put into DT bindings than was put
> into the old C methods. It has less churn, and what churn there is
> seems simpler to follow.

...
 
> Of course all this could have been done in C, but it wasn't/hasn't been..

You have identified the real issue: poor quality of the ARM board
support process within the kernel. Churn is still churn, whether in DT
or in platform devices, but the DT people promised to end the churn.

At least with the platform code, I knew where to look to resolve
issues. Thanks to DT, I now have three haystacks to search, namely
boot loader, DT, and kernel.
 
[ I disagree about the "more thought" part. The current discussion,
  coming years too late after the introduction of DT to ARM Linux, is
  contrary evidence enough. ]

> Why would Freescale PPC be any different from the IBM PPC we use? We'd
> use exactly the same techniques we use on ARM and PPC today and the
> churn to the DT wouldn't be an operational problem in the field.

I always suspected that the IBM powerpc Linux code was of higher
quality. Freescale has been just awful.

And that is just the point. No one is saying that DT cannot work. In
theory (and in your experience) it is really wonderful. However, all
this talk about "one day we will offer stable binding on ARM" already
tells me what kind of quality to expect.

> Why do you think our experiences are so different?

Because the "embedded mindset" was used to develop the code on the
platforms that I have been using.

> *shrug* For embedded I am being *very pragmatic*. I don't need/want an
> ABI boundary between the DT and the kernel. I don't need the DT to
> statically describe the hardware.

Yes, I know the kind of quality to expect from the embedded vendors.
But that doesn't mean that mainline Linux should also stink.

> Well, you know why. The DT schema used by the kernel changes over
> time. Kirkwood just went through a massive change in schema in the
> past few releases, and the same was true on our PPC platforms when
> that was new.

I find the very idea to be total unacceptable. This should never
happen in the stable kernel.

> I can't delay shipping while upstream sorts this out - so I know
> *absolutely* that the DT schema will change. This has been planned for
> and designed into the boot system and won't be a problem.
> 
> Why would anyone do embedded any other way?

Yep, that is the embedded way: ship it!

We can do better than that.

Thanks,
Richard


From richardcochran at gmail.com  Sat Jul 27 04:53:01 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Sat, 27 Jul 2013 10:53:01 +0200
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130726171524.GB28895@obsidianresearch.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726045433.GB4100@netboy>
 <20130726171524.GB28895@obsidianresearch.com>
Message-ID: <20130727085259.GA6207@netboy>

On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote:
> On Fri, Jul 26, 2013 at 06:54:33AM +0200, Richard Cochran wrote:
> > I too work on commercial embedded systems, and DT has proven to be
> > one gigantic *PITA*.
> 
> Why do you think our experiences are so different?

Here are a few recent examples:

* What happens when one wants to boot vanilla kernel on the beaglebone?

  http://www.spinics.net/lists/arm-kernel/msg198431.html

* Wanting already merged code to work is too much to ask.

  http://www.spinics.net/lists/linux-omap/msg79731.html

* When people try in good faith to conduct methodical boot tests,
  DT is working against them.

  http://www.spinics.net/lists/linux-omap/msg79960.html

Thanks,
Richard


From pullip.cho at samsung.com  Sat Jul 27 05:08:11 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Sat, 27 Jul 2013 18:08:11 +0900
Subject: [PATCH v8 05/12] clk: exynos5250: add gate clock descriptions of
 System MMU
In-Reply-To: <20130726200107.7598.82010@quantum>
References: <003b01ce89f3$2be4db80$83ae9280$@samsung.com>
 <20130726200107.7598.82010@quantum>
Message-ID: <001901ce8aa8$d1d6fef0$7584fcd0$@samsung.com>

> -----Original Message-----
> From: Mike Turquette [mailto:mturquette at linaro.org]
> Sent: Saturday, July 27, 2013 5:01 AM
> 
> Quoting Cho KyongHo (2013-07-26 04:27:54)
> > This adds gate clocks of all System MMUs and their master IPs
> > that are not apeared in clk-exynos5250.c
> >
> > Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> 
> Change looks good to me. Are you OK if I take it into the clk tree or do
> you want to keep this series together?

I would like you to pick this to your tree and let me know which branch
contains this patch.
Then I will remove this from my patch series.

Thank you,
Cho KyongHo.
> 
> Regards,
> Mike
> 
> > ---
> >  .../devicetree/bindings/clock/exynos5250-clock.txt |   28 +++++++++-
> >  drivers/clk/samsung/clk-exynos5250.c               |   57 ++++++++++++++++---
> >  2 files changed, 75 insertions(+), 10 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > index 781a627..df49694 100644
> > --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > @@ -154,7 +154,33 @@ clock which they consume.
> >    dsim0                        341
> >    dp                   342
> >    mixer                        343
> > -  hdmi                 345
> > +  hdmi                 344
> > +  camif_top            345
> > +  smmu_fimc_lite0      346
> > +  smmu_fimc_lite1      347
> > +  smmu_fimc_lite2      348
> > +  smmu_tv              349
> > +  smmu_fimd1           350
> > +  smmu_2d              351
> > +  fimc_isp             352
> > +  fimc_drc             353
> > +  fimc_fd              354
> > +  fimc_scc             355
> > +  fimc_scp             356
> > +  fimc_mcuctl          357
> > +  fimc_odc             358
> > +  fimc_dis             359
> > +  fimc_3dnr            360
> > +  smmu_fimc_isp                361
> > +  smmu_fimc_drc                362
> > +  smmu_fimc_fd         363
> > +  smmu_fimc_scc                364
> > +  smmu_fimc_scp                365
> > +  smmu_fimc_mcuctl     366
> > +  smmu_fimc_odc                367
> > +  smmu_fimc_dis0       368
> > +  smmu_fimc_dis1       369
> > +  smmu_fimc_3dnr       370
> >
> >  Example 1: An example of a clock controller node is listed below.
> >
> > diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
> > index 22d7699..e242bde 100644
> > --- a/drivers/clk/samsung/clk-exynos5250.c
> > +++ b/drivers/clk/samsung/clk-exynos5250.c
> > @@ -53,12 +53,15 @@
> >  #define DIV_PERIC3             0x10564
> >  #define DIV_PERIC4             0x10568
> >  #define DIV_PERIC5             0x1056c
> > +#define GATE_IP_ISP0           0x0C800
> > +#define GATE_IP_ISP1           0x0C800
> >  #define GATE_IP_GSCL           0x10920
> >  #define GATE_IP_MFC            0x1092c
> >  #define GATE_IP_GEN            0x10934
> >  #define GATE_IP_FSYS           0x10944
> >  #define GATE_IP_PERIC          0x10950
> >  #define GATE_IP_PERIS          0x10960
> > +#define GATE_IP_ACP            0x18800
> >  #define SRC_CDREX              0x20200
> >  #define PLL_DIV2_SEL           0x20a24
> >  #define GATE_IP_DISP1          0x10928
> > @@ -100,6 +103,14 @@ enum exynos5250_clks {
> >         tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
> >         wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
> >
> > +       camif_top, smmu_fimc_lite0, smmu_fimc_lite1, smmu_fimc_lite2,
> > +       smmu_tv, smmu_fimd1, smmu_2d,
> > +       fimc_isp, fimc_drc, fimc_fd, fimc_scc, fimc_scp, fimc_mcuctl, fimc_odc,
> > +       fimc_dis, fimc_3dnr,
> > +       smmu_fimc_isp, smmu_fimc_drc, smmu_fimc_fd, smmu_fimc_scc,
> > +       smmu_fimc_scp, smmu_fimc_mcuctl, smmu_fimc_odc, smmu_fimc_dis0,
> > +       smmu_fimc_dis1, smmu_fimc_3dnr,
> > +
> >         nr_clks,
> >  };
> >
> > @@ -320,19 +331,26 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
> >         GATE(gscl3, "gscl3", "aclk266", GATE_IP_GSCL, 3, 0, 0),
> >         GATE(gscl_wa, "gscl_wa", "div_gscl_wa", GATE_IP_GSCL, 5, 0, 0),
> >         GATE(gscl_wb, "gscl_wb", "div_gscl_wb", GATE_IP_GSCL, 6, 0, 0),
> > -       GATE(smmu_gscl0, "smmu_gscl0", "aclk266", GATE_IP_GSCL, 7, 0, 0),
> > -       GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
> > -       GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
> > -       GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
> > +       GATE(smmu_gscl0, "smmu_gscl0", "none", GATE_IP_GSCL, 7, 0, 0),
> > +       GATE(smmu_gscl1, "smmu_gscl1", "none", GATE_IP_GSCL, 8, 0, 0),
> > +       GATE(smmu_gscl2, "smmu_gscl2", "none", GATE_IP_GSCL, 9, 0, 0),
> > +       GATE(smmu_gscl3, "smmu_gscl3", "none", GATE_IP_GSCL, 10, 0, 0),
> > +       GATE(camif_top, "camif_top", "aclk266", GATE_IP_GSCL, 4, 0, 0),
> > +       GATE(smmu_fimc_lite0, "smmu_fimc_lite0", "none",
> > +                                               GATE_IP_GSCL, 12, 0, 0),
> > +       GATE(smmu_fimc_lite1, "smmu_fimc_lite1", "none",
> > +                                               GATE_IP_GSCL, 13, 0, 0),
> > +       GATE(smmu_fimc_lite2, "smmu_fimc_lite2", "none",
> > +                                               GATE_IP_GSCL, 14, 0, 0),
> >         GATE(mfc, "mfc", "aclk333", GATE_IP_MFC, 0, 0, 0),
> > -       GATE(smmu_mfcl, "smmu_mfcl", "aclk333", GATE_IP_MFC, 1, 0, 0),
> > -       GATE(smmu_mfcr, "smmu_mfcr", "aclk333", GATE_IP_MFC, 2, 0, 0),
> > +       GATE(smmu_mfcr, "smmu_mfcr", "none", GATE_IP_MFC, 1, 0, 0),
> > +       GATE(smmu_mfcl, "smmu_mfcl", "none", GATE_IP_MFC, 2, 0, 0),
> >         GATE(rotator, "rotator", "aclk266", GATE_IP_GEN, 1, 0, 0),
> >         GATE(jpeg, "jpeg", "aclk166", GATE_IP_GEN, 2, 0, 0),
> >         GATE(mdma1, "mdma1", "aclk266", GATE_IP_GEN, 4, 0, 0),
> > -       GATE(smmu_rotator, "smmu_rotator", "aclk266", GATE_IP_GEN, 6, 0, 0),
> > -       GATE(smmu_jpeg, "smmu_jpeg", "aclk166", GATE_IP_GEN, 7, 0, 0),
> > -       GATE(smmu_mdma1, "smmu_mdma1", "aclk266", GATE_IP_GEN, 9, 0, 0),
> > +       GATE(smmu_rotator, "smmu_rotator", "none", GATE_IP_GEN, 6, 0, 0),
> > +       GATE(smmu_jpeg, "smmu_jpeg", "none", GATE_IP_GEN, 7, 0, 0),
> > +       GATE(smmu_mdma1, "smmu_mdma1", "none", GATE_IP_GEN, 9, 0, 0),
> >         GATE(pdma0, "pdma0", "aclk200", GATE_IP_FSYS, 1, 0, 0),
> >         GATE(pdma1, "pdma1", "aclk200", GATE_IP_FSYS, 2, 0, 0),
> >         GATE(sata, "sata", "aclk200", GATE_IP_FSYS, 6, 0, 0),
> > @@ -462,6 +480,27 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
> >         GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
> >         GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
> >         GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
> > +       GATE(smmu_tv, "smmu_tv", "none", GATE_IP_DISP1, 2, 0, 0),
> > +       GATE(smmu_fimd1, "smmu_fimd1", "none", GATE_IP_DISP1, 8, 0, 0),
> > +
> > +       GATE(smmu_fimc_isp, "smmu_fimc_isp", "none", GATE_IP_ISP0, 8, 0, 0),
> > +       GATE(smmu_fimc_drc, "smmu_fimc_drc", "none", GATE_IP_ISP0, 9, 0, 0),
> > +       GATE(smmu_fimc_fd, "smmu_fimc_fd", "none", GATE_IP_ISP0, 10, 0, 0),
> > +       GATE(smmu_fimc_scc, "smmu_fimc_scc", "none",
> > +                                                       GATE_IP_ISP0, 11, 0, 0),
> > +       GATE(smmu_fimc_scp, "smmu_fimc_scp", "none",
> > +                                                       GATE_IP_ISP0, 12, 0, 0),
> > +       GATE(smmu_fimc_mcuctl, "smmu_fimc_mcuctl", "none",
> > +                                                       GATE_IP_ISP0, 13, 0, 0),
> > +       GATE(smmu_fimc_odc, "smmu_fimc_odc", "none", GATE_IP_ISP1, 4, 0, 0),
> > +       GATE(smmu_fimc_dis0, "smmu_fimc_dis0", "none",
> > +                                                       GATE_IP_ISP1, 5, 0, 0),
> > +       GATE(smmu_fimc_dis1, "smmu_fimc_dis1", "none",
> > +                                                       GATE_IP_ISP1, 6, 0, 0),
> > +       GATE(smmu_fimc_3dnr, "smmu_fimc_3dnr", "none",
> > +                                                       GATE_IP_ISP1, 7, 0, 0),
> > +
> > +       GATE(smmu_2d, "smmu_2d", "none", GATE_IP_ACP, 7, 0, 0),
> >  };
> >
> >  static __initdata struct of_device_id ext_clk_match[] = {
> > --
> > 1.7.2.5
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From tom.leiming at gmail.com  Sat Jul 27 05:16:34 2013
From: tom.leiming at gmail.com (Ming Lei)
Date: Sat, 27 Jul 2013 17:16:34 +0800
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <CAKON4OzrkHzUzKkULWCgiEpAtJ5gLxUm78R5ctd7p6trqq_gCA@mail.gmail.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726132709.GH29916@titan.lakedaemon.net>
 <1374846070.14574.92.camel@i7.infradead.org>
 <CAKON4OzrkHzUzKkULWCgiEpAtJ5gLxUm78R5ctd7p6trqq_gCA@mail.gmail.com>
Message-ID: <CACVXFVNiHg4H5rc1cxxBc=Prv4etstMFeRtk4op-tgqFp7m54A@mail.gmail.com>

On Fri, Jul 26, 2013 at 10:14 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>
> Yes, yes - that's why the schema should be written down and used as a
> validation input to dtc. Then dtc can spit out errors for non-standard
> items. There would be two versions - the standard one and a legacy one
> that includes the standard one plus the hacks that can't be undone.
>
> But more importantly it provides a framework for people creating new
> node definitions. Now they can't work in a vacuum and come up with
> random names and structure for everything.
>
> Most of the problems express in the thread would go away if the schema
> was written down and discussed. The rule going forward would be no new
> nodes that aren't part of the standard schema.

+1.

If we want to keep the schema stable, it has to be defined and described
explicitly with one language, just like syscall ABI: C type/API exported to
userspace header file.


Thanks,
-- 
Ming Lei


From pullip.cho at samsung.com  Sat Jul 27 05:29:12 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Sat, 27 Jul 2013 18:29:12 +0900
Subject: [PATCH v8 06/12] ARM: dts: Add description of System MMU of Exynos
 SoCs
In-Reply-To: <CANEJEGsHyDP+AZejV57gMKPnbi0bi4yiWc42gPM9YuZzOewwLw@mail.gmail.com>
References: <003c01ce89f3$3abc4bc0$b034e340$@samsung.com>
 <CANEJEGsHyDP+AZejV57gMKPnbi0bi4yiWc42gPM9YuZzOewwLw@mail.gmail.com>
Message-ID: <001f01ce8aab$c1859180$4490b480$@samsung.com>

> -----Original Message-----
> From: grundler at google.com [mailto:grundler at google.com] On Behalf Of Grant Grundler
> Sent: Saturday, July 27, 2013 2:58 AM
> 
> On Fri, Jul 26, 2013 at 4:28 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> > Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> > ---
> >  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++++++
> >  arch/arm/boot/dts/exynos4.dtsi                     |  122 ++++++++
> >  arch/arm/boot/dts/exynos4210.dtsi                  |   25 ++
> >  arch/arm/boot/dts/exynos4x12.dtsi                  |   76 +++++
> >  arch/arm/boot/dts/exynos5250.dtsi                  |  291 ++++++++++++++++++++
> >  5 files changed, 617 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> > b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> > new file mode 100644
> > index 0000000..92f0a33
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> > @@ -0,0 +1,103 @@
> > +Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management Unit)
> > +
> > +Samsung's Exynos architecture contains System MMU that enables scattered
> 
> Cho,
> "MMU" should be plural? "MMUs"?
> 

An Exynos SoC has tens of System MMUs.
I agree with you.

Thanks.

> > +physical memory chunks visible as a contiguous region to DMA-capable peripheral
> > +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
> > +
> > +System MMU is a sort of IOMMU and support identical translation table format to
> 
> s/a sort of/an/ . Or perhaps "is also an". For the purposes of
> documenting DMA support, we are talking about the IOMMU functionality
> this device provides. It might be better to mention the functionality
> the System MMU supports and refer to other subsystem documents (e,g,
> clocking and power control) for details.
> 

Thank you for the advice.
Let me check the details in another documents.

> > +ARMv7 translation tables with minimum set of page properties including access
> > +permissions, shareability and security protection. In addition, System MMU has
> > +another capabilities like L2 TLB or block-fetch buffers to minimize translation
> > +latency.
> > +
> > +A System MMU is dedicated to a single master peripheral device.  Thus, it is
> > +important to specify the correct System MMU in the device node of its master
> > +device.  Whereas a System MMU is dedicated to a master device, the master device
> > +may have more than one System MMU.
> 
> Can I suggest rewriting the last two sentences to:
>   The master device node must correctly specify at least one
> SystemMMU. A master  device may have more than one System MMU.
> 

Thanks. It looks much clearer than my expression.

> BTW, is there a difference between "master device" and "master
> peripheral device" that I'm not aware of?  Perhaps use just one of
> those expressions in this document, not both if they are the same
> thing (which is what I assumed).
> 

You assumed correctly.
I meant them the same thing.

Thank you for the detail and kind review.

> cheers,
> grant
> 
> > +
> > +Required properties:
> > +- compatible: Should be "samsung,exynos4210-sysmmu"
> > +- reg: A tuple of base address and size of System MMU registers.
> > +- interrupt-parent: The phandle of the interrupt controller of System MMU
> > +- interrupts: A tuple of numbers that indicates the interrupt source.
> > +- clock-names: Should be "sysmmu" if the System MMU is needed to gate its clock.
> > +               Please refer to the following documents:
> > +              Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +              Documentation/devicetree/bindings/clock/exynos4-clock.txt
> > +              Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > +              Optional "master" if the clock to the System MMU is gated by
> > +              another gate clock other than "sysmmu". The System MMU driver
> > +              sets "master" the parent of "sysmmu".
> > +              Exynos4 SoCs, there needs no "master" clocks.
> > +              Exynos5 SoCs, some System MMUs must have "master" clocks.
> > +- clocks: Required if the System MMU is needed to gate its clock.
> > +         Please refer to the documents listed above.
> > +- samsung,power-domain: Required if the System MMU is needed to gate its power.
> > +         Please refer to the following document:
> > +         Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> > +
> > +Required properties for the master peripheral devices:
> > +- iommu: phandles to the System MMUs of the device
> > +
> > +Examples:
> > +A System MMU is dedicated to a single master device.
> > +       gsc_0:  gsc at 0x13e00000 {
> > +               compatible = "samsung,exynos5-gsc";
> > +               reg = <0x13e00000 0x1000>;
> > +               interrupts = <0 85 0>;
> > +               samsung,power-domain = <&pd_gsc>;
> > +               clocks = <&clock 256>;
> > +               clock-names = "gscl";
> > +               iommu = <&sysmmu_gsc1>;
> > +       };
> > +
> > +       sysmmu_gsc0: sysmmu at 13E80000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13E80000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-gsc0";
> > +               interrupts = <2 0>;
> > +               clock-names = "sysmmu", "master";
> > +               clocks = <&clock 262>, <&clock 256>;
> > +               samsung,power-domain = <&pd_gsc>;
> > +               status = "ok";
> > +       };
> > +
> > +MFC has 2 System MMUs for each port that MFC is attached. Thus it seems natural
> > +to define 2 System MMUs for each port of the MFC:
> > +
> > +       mfc: codec at 13400000 {
> > +               compatible = "samsung,mfc-v5";
> > +               reg = <0x13400000 0x10000>;
> > +               interrupts = <0 94 0>;
> > +               samsung,power-domain = <&pd_mfc>;
> > +               clocks = <&clock 170>, <&clock 273>;
> > +               clock-names = "sclk_mfc", "mfc";
> > +               status = "ok";
> > +               iommu = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>;
> > +       };
> > +
> > +       sysmmu_mfc_l: sysmmu at 13620000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13620000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-mfc-l";
> > +               interrupts = <5 5>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 274>;
> > +               samsung,power-domain = <&pd_mfc>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_mfc_r: sysmmu at 13630000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13630000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-mfc-r";
> > +               interrupts = <5 6>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 275>;
> > +               samsung,power-domain = <&pd_mfc>;
> > +               status = "ok";
> > +       };
> > +
> > diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> > index 359694c..ba74ee8 100644
> > --- a/arch/arm/boot/dts/exynos4.dtsi
> > +++ b/arch/arm/boot/dts/exynos4.dtsi
> > @@ -161,6 +161,7 @@
> >                 interrupts = <0 94 0>;
> >                 samsung,power-domain = <&pd_mfc>;
> >                 status = "disabled";
> > +               iommu = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>;
> >         };
> >
> >         serial at 13800000 {
> > @@ -395,5 +396,126 @@
> >                 clock-names = "sclk_fimd", "fimd";
> >                 samsung,power-domain = <&pd_lcd0>;
> >                 status = "disabled";
> > +               iommu = <&sysmmu_fimd0>;
> > +       };
> > +
> > +       sysmmu_mfc_l: sysmmu at 13620000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13620000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-mfc-l";
> > +               interrupts = <5 5>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 274>;
> > +               samsung,power-domain = <&pd_mfc>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_mfc_r: sysmmu at 13630000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13630000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-mfc-r";
> > +               interrupts = <5 6>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 275>;
> > +               samsung,power-domain = <&pd_mfc>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_tv: sysmmu at 13E20000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13E20000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-tv";
> > +               interrupts = <5 4>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 272>;
> > +               samsung,power-domain = <&pd_tv>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc0: sysmmu at 11A20000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x11A20000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc0";
> > +               interrupts = <4 2>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 263>;
> > +               samsung,power-domain = <&pd_cam>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc1: sysmmu at 11A30000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x11A30000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc1";
> > +               interrupts = <4 3>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 264>;
> > +               samsung,power-domain = <&pd_cam>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc2: sysmmu at 11A40000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x11A40000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc2";
> > +               interrupts = <4 4>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 265>;
> > +               samsung,power-domain = <&pd_cam>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc3: sysmmu at 11A50000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x11A50000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc3";
> > +               interrupts = <4 5>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 266>;
> > +               samsung,power-domain = <&pd_cam>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_jpeg: sysmmu at 11A60000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x11A60000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-jpeg";
> > +               interrupts = <4 6>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 267>;
> > +               samsung,power-domain = <&pd_cam>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_rotator: sysmmu at 12A30000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x12A30000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-rotator";
> > +               interrupts = <5 0>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 281>;
> > +               samsung,power-domain = <&pd_lcd0>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimd0: sysmmu at 11E20000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x11E20000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimd0";
> > +               interrupts = <5 2>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 287>;
> > +               samsung,power-domain = <&pd_lcd0>;
> > +               status = "ok";
> >         };
> >  };
> > diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
> > index 54710de..09b13da 100644
> > --- a/arch/arm/boot/dts/exynos4210.dtsi
> > +++ b/arch/arm/boot/dts/exynos4210.dtsi
> > @@ -119,5 +119,30 @@
> >                 reg = <0x12800000 0x1000>;
> >                 interrupts = <0 89 0>;
> >                 status = "disabled";
> > +               iommu = <&sysmmu_g2d>;
> > +       };
> > +
> > +       sysmmu_g2d: sysmmu at 12A20000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x12A20000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-g2d";
> > +               interrupts = <4 7>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 280>;
> > +               samsung,power-domain = <&pd_lcd0>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimd1: sysmmu at 12220000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimd1";
> > +               reg = <0x12220000 0x1000>;
> > +               interrupts = <5 3>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 291>;
> > +               samsung,power-domain = <&pd_lcd1>;
> > +               status = "ok";
> >         };
> >  };
> > diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
> > index e3380a7..681db32 100644
> > --- a/arch/arm/boot/dts/exynos4x12.dtsi
> > +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> > @@ -79,4 +79,80 @@
> >                 interrupts = <0 89 0>;
> >                 status = "disabled";
> >         };
> > +
> > +       sysmmu_g2d: sysmmu at 10A40000{
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x10A40000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-g2d";
> > +               interrupts = <4 7>;
> > +               clock-names = "sysmmu";
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_isp: sysmmu at 12260000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x12260000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_isp";
> > +               interrupts = <16 2>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 362>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_drc: sysmmu at 12270000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x12270000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_drc";
> > +               interrupts = <16 3>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 363>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_fd: sysmmu at 122A0000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x122A0000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_fd";
> > +               interrupts = <16 4>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 364>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_mcuctl: sysmmu at 122B0000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x122B0000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_mcuctl";
> > +               interrupts = <16 5>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 376>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_lite0: sysmmu at 123B0000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x123B0000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_lite0";
> > +               interrupts = <16 0>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 366>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_lite1: sysmmu at 123C0000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x123C0000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_lite1";
> > +               interrupts = <16 1>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 365>;
> > +               status = "ok";
> > +       };
> >  };
> > diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> > index fc9fb3d..130d23d 100644
> > --- a/arch/arm/boot/dts/exynos5250.dtsi
> > +++ b/arch/arm/boot/dts/exynos5250.dtsi
> > @@ -66,6 +66,16 @@
> >                 reg = <0x10044040 0x20>;
> >         };
> >
> > +       pd_isp: mfc-power-domain at 0x10044020 {
> > +               compatible = "samsung,exynos4210-pd";
> > +               reg = <0x10044020 0x20>;
> > +       };
> > +
> > +       pd_disp1: mfc-power-domain at 0x100440A0 {
> > +               compatible = "samsung,exynos4210-pd";
> > +               reg = <0x100440A0 0x20>;
> > +       };
> > +
> >         clock: clock-controller at 0x10010000 {
> >                 compatible = "samsung,exynos5250-clock";
> >                 reg = <0x10010000 0x30000>;
> > @@ -180,6 +190,7 @@
> >                 reg = <0x11000000 0x10000>;
> >                 interrupts = <0 96 0>;
> >                 samsung,power-domain = <&pd_mfc>;
> > +               iommu = <&sysmmu_mfc_l &sysmmu_mfc_l>;
> >         };
> >
> >         rtc {
> > @@ -571,6 +582,7 @@
> >                 samsung,power-domain = <&pd_gsc>;
> >                 clocks = <&clock 256>;
> >                 clock-names = "gscl";
> > +               iommu = <&sysmmu_gsc1>;
> >         };
> >
> >         gsc_1:  gsc at 0x13e10000 {
> > @@ -580,6 +592,7 @@
> >                 samsung,power-domain = <&pd_gsc>;
> >                 clocks = <&clock 257>;
> >                 clock-names = "gscl";
> > +               iommu = <&sysmmu_gsc1>;
> >         };
> >
> >         gsc_2:  gsc at 0x13e20000 {
> > @@ -589,6 +602,7 @@
> >                 samsung,power-domain = <&pd_gsc>;
> >                 clocks = <&clock 258>;
> >                 clock-names = "gscl";
> > +               iommu = <&sysmmu_gsc2>;
> >         };
> >
> >         gsc_3:  gsc at 0x13e30000 {
> > @@ -598,6 +612,7 @@
> >                 samsung,power-domain = <&pd_gsc>;
> >                 clocks = <&clock 259>;
> >                 clock-names = "gscl";
> > +               iommu = <&sysmmu_gsc3>;
> >         };
> >
> >         hdmi {
> > @@ -614,6 +629,7 @@
> >                 compatible = "samsung,exynos5-mixer";
> >                 reg = <0x14450000 0x10000>;
> >                 interrupts = <0 94 0>;
> > +               iommu = <&sysmmu_tv>;
> >         };
> >
> >         dp-controller {
> > @@ -638,5 +654,280 @@
> >                 interrupts = <18 4>, <18 5>, <18 6>;
> >                 clocks = <&clock 133>, <&clock 339>;
> >                 clock-names = "sclk_fimd", "fimd";
> > +               iommu = <&sysmmu_fimd1>;
> > +       };
> > +
> > +       sysmmu_mfc_l: sysmmu at 11210000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x11210000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-mfc_l";
> > +               interrupts = <8 5>;
> > +               clock-names = "sysmmu", "master";
> > +               clocks = <&clock 267>, <&clock 266>;
> > +               samsung,power-domain = <&pd_mfc>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_mfc_r: sysmmu at 11200000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x11200000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-mfc_r";
> > +               interrupts = <6 2>;
> > +               clock-names = "sysmmu", "master";
> > +               clocks = <&clock 268>, <&clock 266>;
> > +               samsung,power-domain = <&pd_mfc>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_tv: sysmmu at 14650000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x14650000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-tv";
> > +               interrupts = <7 4>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 349>;
> > +               samsung,power-domain = <&pd_disp1>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_gsc0: sysmmu at 13E80000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13E80000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-gsc0";
> > +               interrupts = <2 0>;
> > +               clock-names = "sysmmu", "master";
> > +               clocks = <&clock 262>, <&clock 256>;
> > +               samsung,power-domain = <&pd_gsc>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_gsc1: sysmmu at 13E90000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13E90000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-gsc1";
> > +               interrupts = <2 2>;
> > +               clock-names = "sysmmu", "master";
> > +               clocks = <&clock 263>, <&clock 257>;
> > +               samsung,power-domain = <&pd_gsc>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_gsc2: sysmmu at 13EA0000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13EA0000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-gsc2";
> > +               interrupts = <2 4>;
> > +               clock-names = "sysmmu", "master";
> > +               clocks = <&clock 264>, <&clock 258>;
> > +               samsung,power-domain = <&pd_gsc>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_gsc3: sysmmu at 13EB0000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13EB0000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-gsc3";
> > +               interrupts = <2 6>;
> > +               clock-names = "sysmmu", "master";
> > +               clocks = <&clock 265>, <&clock 259>;
> > +               samsung,power-domain = <&pd_gsc>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimd1: sysmmu at 14640000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x14640000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimd1";
> > +               interrupts = <3 2>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 350>;
> > +               samsung,power-domain = <&pd_disp1>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_rotator: sysmmu at 11D40000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x11D40000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-rotator";
> > +               interrupts = <4 0>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 272>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_isp: sysmmu at 13260000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13260000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_isp";
> > +               interrupts = <10 6>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 361>;
> > +               samsung,power-domain = <&pd_isp>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_drc: sysmmu at 13270000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13270000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_drc";
> > +               interrupts = <11 6>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 362>;
> > +               samsung,power-domain = <&pd_isp>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_fd: sysmmu at 132A0000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x132A0000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_fd";
> > +               interrupts = <5 0>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 363>;
> > +               samsung,power-domain = <&pd_isp>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_scc: sysmmu at 13280000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13280000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_scalerc";
> > +               interrupts = <5 2>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 364>;
> > +               samsung,power-domain = <&pd_isp>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_scp: sysmmu at 13290000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13290000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_scalerp";
> > +               interrupts = <3 6>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 365>;
> > +               samsung,power-domain = <&pd_isp>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_mcuctl: sysmmu at 132B0000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x132B0000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_mcuctl";
> > +               interrupts = <5 4>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 366>;
> > +               samsung,power-domain = <&pd_isp>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_odc: sysmmu at 132C0000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x132C0000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_odc";
> > +               interrupts = <11 0>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 367>;
> > +               samsung,power-domain = <&pd_isp>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_dis0: sysmmu at 132D0000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x132D0000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_dis0";
> > +               interrupts = <10 4>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 368>;
> > +               samsung,power-domain = <&pd_isp>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_dis1: sysmmu at 132E0000{
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x132E0000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_dis1";
> > +               interrupts = <9 4>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 369>;
> > +               samsung,power-domain = <&pd_isp>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_3dnr: sysmmu at 132F0000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x132F0000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_3dnr";
> > +               interrupts = <5 6>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 370>;
> > +               samsung,power-domain = <&pd_isp>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_lite0: sysmmu at 13C40000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13C40000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_lite0";
> > +               interrupts = <3 4>;
> > +               clock-names = "sysmmu", "master";
> > +               clocks = <&clock 346>, <&clock 345>;
> > +               samsung,power-domain = <&pd_gsc>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_lite1: sysmmu at 13C50000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x13C50000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-fimc_lite1";
> > +               interrupts = <24 1>;
> > +               clock-names = "sysmmu", "master";
> > +               clocks = <&clock 347>, <&clock 345>;
> > +               samsung,power-domain = <&pd_gsc>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_jpeg: sysmmu at 11F20000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x11F20000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-jpeg";
> > +               interrupts = <4 2>;
> > +               clock-names = "sysmmu", "master";
> > +               clocks = <&clock 273>, <&clock 270>;
> > +               samsung,power-domain = <&pd_gsc>;
> > +               status = "ok";
> > +       };
> > +
> > +       sysmmu_fimc_2d: sysmmu at 10A60000 {
> > +               compatible = "samsung,exynos4210-sysmmu";
> > +               reg = <0x10A60000 0x1000>;
> > +               interrupt-parent = <&combiner>;
> > +               interrupt-names = "sysmmu-2d";
> > +               interrupts = <24 5>;
> > +               clock-names = "sysmmu";
> > +               clocks = <&clock 361>;
> > +               status = "ok";
> >         };
> >  };
> > --
> > 1.7.2.5
> >
> >



From tomasz.figa at gmail.com  Sat Jul 27 05:51:29 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 27 Jul 2013 11:51:29 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130727050406.GB4221@netboy>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <CAOesGMhEr3DiFm5uSgoHPFUMY4jWu4HkeTU2UmOGj=dS75Vk+g@mail.gmail.com>
 <20130727050406.GB4221@netboy>
Message-ID: <2007664.vYsECFSKrV@flatron>

On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote:
> On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:
> > Long term, final goal is likely to be close to what Russell is saying
> 
> Why is this a long term goal? Start today.
> 
> > -- nothing should go into the kernel tree unless the binding is in a
> > fully stable state. However, we have a transitional period between now
> > and then, and even when we're at the final state there will be need to
> > have some sort of sandbox for development and test of future bindings.
> 
> Why not just set up a git tree right away?
> 
> > Dealing with all that, as well as the actual process for locking in
> > bindings, is what needs to be sorted out.
> > 
> > I think we're all in agreement that bindings that change over time are
> > nothing but pain, but we're arguing that in circles anyway.
> 
> No.
> 
> I keep saying, the bindings must be stable ABI, *today*.
> 
> You keep saying, maybe later, but until then we will make things up as
> we go along.

We have currently a lot of broken bindings, because people didn't know how 
to define ones and those they defined have not been properly reviewed. Do 
you really want such broken ABI in the kernel?

Sure, there are many existing bindings that can be just made stable and 
well they probably are already de facto stable. This is mostly about 
subsystem bindings and whatever already has many users, both made them get 
more thought when designing and more review before merging.

Still, a lot of device and platform-specific bindings are simply broken. 
Take max8925 backlight driver, that Olof started this whole discussion 
with, as an example. We need to sort them out before they can be 
stabilized.

This is the whole point of having distinction between stable and staging 
bindings.

Best regards,
Tomasz



From tomasz.figa at gmail.com  Sat Jul 27 06:20:05 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 27 Jul 2013 12:20:05 +0200
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130727085259.GA6207@netboy>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130726171524.GB28895@obsidianresearch.com> <20130727085259.GA6207@netboy>
Message-ID: <1776866.moAxavOOUJ@flatron>

On Saturday 27 of July 2013 10:53:01 Richard Cochran wrote:
> On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote:
> > On Fri, Jul 26, 2013 at 06:54:33AM +0200, Richard Cochran wrote:
> > > I too work on commercial embedded systems, and DT has proven to be
> > > one gigantic *PITA*.
> > 
> > Why do you think our experiences are so different?
> 
> Here are a few recent examples:
> 
> * What happens when one wants to boot vanilla kernel on the beaglebone?
> 
>   http://www.spinics.net/lists/arm-kernel/msg198431.html

Not really understand point of quoting this thread here. Lack of support 
for Beaglebone at that time was not really related to device tree in any 
way, just not enough support for it was merged at that time (as I could 
read here: http://www.spinics.net/lists/arm-kernel/msg199863.html)

> * Wanting already merged code to work is too much to ask.
> 
>   http://www.spinics.net/lists/linux-omap/msg79731.html

This is about not enough synchronization between OMAP people and TI not 
pushing enough and quickly enough to mainline...

> * When people try in good faith to conduct methodical boot tests,
>   DT is working against them.
> 
>   http://www.spinics.net/lists/linux-omap/msg79960.html

I don't really see any relation with DT in this thread. Again this looks 
like support for this platform was not yet developed enough at that time 
in mainline kernel. Still, you managed to boot 3.7-rc2 
(http://thread.gmane.org/gmane.linux.ports.arm.omap/86719/focus=86952), 
didn't you?

I wouldn't really connect all the problems we are having currently with DT 
alone. For many ARM people this is still something new, something that 
they don't fully know how to work with yet. We don't have proper 
processes, examples, best practices, etc. This is what we are trying to 
fix and a key point of all those discussions like this one.

Best regards,
Tomasz



From arend at broadcom.com  Sat Jul 27 06:24:24 2013
From: arend at broadcom.com (Arend van Spriel)
Date: Sat, 27 Jul 2013 12:24:24 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <2007664.vYsECFSKrV@flatron>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <CAOesGMhEr3DiFm5uSgoHPFUMY4jWu4HkeTU2UmOGj=dS75Vk+g@mail.gmail.com>
 <20130727050406.GB4221@netboy> <2007664.vYsECFSKrV@flatron>
Message-ID: <51F39FD8.6080808@broadcom.com>

On 07/27/2013 11:51 AM, Tomasz Figa wrote:
> On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote:
>> On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:
>>> Long term, final goal is likely to be close to what Russell is saying
>>
>> Why is this a long term goal? Start today.
>>
>>> -- nothing should go into the kernel tree unless the binding is in a
>>> fully stable state. However, we have a transitional period between now
>>> and then, and even when we're at the final state there will be need to
>>> have some sort of sandbox for development and test of future bindings.
>>
>> Why not just set up a git tree right away?
>>
>>> Dealing with all that, as well as the actual process for locking in
>>> bindings, is what needs to be sorted out.
>>>
>>> I think we're all in agreement that bindings that change over time are
>>> nothing but pain, but we're arguing that in circles anyway.
>>
>> No.
>>
>> I keep saying, the bindings must be stable ABI, *today*.
>>
>> You keep saying, maybe later, but until then we will make things up as
>> we go along.
>
> We have currently a lot of broken bindings, because people didn't know how
> to define ones and those they defined have not been properly reviewed. Do
> you really want such broken ABI in the kernel?
>
> Sure, there are many existing bindings that can be just made stable and
> well they probably are already de facto stable. This is mostly about
> subsystem bindings and whatever already has many users, both made them get
> more thought when designing and more review before merging.
>
> Still, a lot of device and platform-specific bindings are simply broken.
> Take max8925 backlight driver, that Olof started this whole discussion
> with, as an example. We need to sort them out before they can be
> stabilized.

That is a nice summary of how we got from null to now and Richard seems 
to be simply saying: let's stop mucking about and make this a project 
with a well-defined process of dealing with staging and stable bindings 
and keep stable bindings stable. Whether it should be within the kernel 
repo as a separate subsystem or in an entire different repo is a trivial 
decision, but still a decision that needs to be made.

Apart from stable DT bindings I would love to see a DT compiler that 
that next to DT syntax detects mistakes in properties used for the 
selfish reason that I spent hours debugging regulator code, because I 
typed vmmc_supply iso vmmc-supply. I did not go through all the 
bindings, but this may require a more formal description so it could be 
compiled/read in the DT compiler.

Regards,
Arend



From arend at broadcom.com  Sat Jul 27 06:34:32 2013
From: arend at broadcom.com (Arend van Spriel)
Date: Sat, 27 Jul 2013 12:34:32 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <51F39FD8.6080808@broadcom.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <CAOesGMhEr3DiFm5uSgoHPFUMY4jWu4HkeTU2UmOGj=dS75Vk+g@mail.gmail.com>
 <20130727050406.GB4221@netboy> <2007664.vYsECFSKrV@flatron>
 <51F39FD8.6080808@broadcom.com>
Message-ID: <51F3A238.3020505@broadcom.com>

On 07/27/2013 12:24 PM, Arend van Spriel wrote:
> On 07/27/2013 11:51 AM, Tomasz Figa wrote:
>> On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote:
>>> On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:
>>>> Long term, final goal is likely to be close to what Russell is saying
>>>
>>> Why is this a long term goal? Start today.
>>>
>>>> -- nothing should go into the kernel tree unless the binding is in a
>>>> fully stable state. However, we have a transitional period between now
>>>> and then, and even when we're at the final state there will be need to
>>>> have some sort of sandbox for development and test of future bindings.
>>>
>>> Why not just set up a git tree right away?
>>>
>>>> Dealing with all that, as well as the actual process for locking in
>>>> bindings, is what needs to be sorted out.
>>>>
>>>> I think we're all in agreement that bindings that change over time are
>>>> nothing but pain, but we're arguing that in circles anyway.
>>>
>>> No.
>>>
>>> I keep saying, the bindings must be stable ABI, *today*.
>>>
>>> You keep saying, maybe later, but until then we will make things up as
>>> we go along.
>>
>> We have currently a lot of broken bindings, because people didn't know
>> how
>> to define ones and those they defined have not been properly reviewed. Do
>> you really want such broken ABI in the kernel?
>>
>> Sure, there are many existing bindings that can be just made stable and
>> well they probably are already de facto stable. This is mostly about
>> subsystem bindings and whatever already has many users, both made them
>> get
>> more thought when designing and more review before merging.
>>
>> Still, a lot of device and platform-specific bindings are simply broken.
>> Take max8925 backlight driver, that Olof started this whole discussion
>> with, as an example. We need to sort them out before they can be
>> stabilized.
>
> That is a nice summary of how we got from null to now and Richard seems
> to be simply saying: let's stop mucking about and make this a project
> with a well-defined process of dealing with staging and stable bindings
> and keep stable bindings stable. Whether it should be within the kernel
> repo as a separate subsystem or in an entire different repo is a trivial
> decision, but still a decision that needs to be made.
>
> Apart from stable DT bindings I would love to see a DT compiler that
> that next to DT syntax detects mistakes in properties used for the
> selfish reason that I spent hours debugging regulator code, because I
> typed vmmc_supply iso vmmc-supply. I did not go through all the
> bindings, but this may require a more formal description so it could be
> compiled/read in the DT compiler.

Oh, and the reason for my tinkering on dts is here:

http://mid.gmane.org/51E7AA24.6080600 at broadcom.com

Happily using Pandaboard for my driver testing and than *kaboom*. 
board-omap4panda.c is gone although the device tree does not provide the 
same functionality. Of course, this is not about DT bindings.

Regards,
Arend




From tomasz.figa at gmail.com  Sat Jul 27 06:36:30 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 27 Jul 2013 12:36:30 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <51F39FD8.6080808@broadcom.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
Message-ID: <2460092.aLmjrOVh1g@flatron>

On Saturday 27 of July 2013 12:24:24 Arend van Spriel wrote:
> On 07/27/2013 11:51 AM, Tomasz Figa wrote:
> > On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote:
> >> On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:
> >>> Long term, final goal is likely to be close to what Russell is
> >>> saying
> >> 
> >> Why is this a long term goal? Start today.
> >> 
> >>> -- nothing should go into the kernel tree unless the binding is in a
> >>> fully stable state. However, we have a transitional period between
> >>> now
> >>> and then, and even when we're at the final state there will be need
> >>> to
> >>> have some sort of sandbox for development and test of future
> >>> bindings.
> >> 
> >> Why not just set up a git tree right away?
> >> 
> >>> Dealing with all that, as well as the actual process for locking in
> >>> bindings, is what needs to be sorted out.
> >>> 
> >>> I think we're all in agreement that bindings that change over time
> >>> are
> >>> nothing but pain, but we're arguing that in circles anyway.
> >> 
> >> No.
> >> 
> >> I keep saying, the bindings must be stable ABI, *today*.
> >> 
> >> You keep saying, maybe later, but until then we will make things up
> >> as
> >> we go along.
> > 
> > We have currently a lot of broken bindings, because people didn't know
> > how to define ones and those they defined have not been properly
> > reviewed. Do you really want such broken ABI in the kernel?
> > 
> > Sure, there are many existing bindings that can be just made stable
> > and
> > well they probably are already de facto stable. This is mostly about
> > subsystem bindings and whatever already has many users, both made them
> > get more thought when designing and more review before merging.
> > 
> > Still, a lot of device and platform-specific bindings are simply
> > broken. Take max8925 backlight driver, that Olof started this whole
> > discussion with, as an example. We need to sort them out before they
> > can be stabilized.
> 
> That is a nice summary of how we got from null to now and Richard seems
> to be simply saying: let's stop mucking about and make this a project
> with a well-defined process of dealing with staging and stable bindings
> and keep stable bindings stable. Whether it should be within the kernel
> repo as a separate subsystem or in an entire different repo is a trivial
> decision, but still a decision that needs to be made.

Yes, basically that's our current situation.

Still, I would disagree about the decision being trivial, as each choice 
will have further, and likely pretty significant, consequences on binding 
maintenance, submission, review and for dependent things, like drivers or 
platforms using such bindings. This needs to be discussed enough.

> Apart from stable DT bindings I would love to see a DT compiler that
> that next to DT syntax detects mistakes in properties used for the
> selfish reason that I spent hours debugging regulator code, because I
> typed vmmc_supply iso vmmc-supply. I did not go through all the
> bindings, but this may require a more formal description so it could be
> compiled/read in the DT compiler.

This bothered me as well and that's why I'm working on this. I still can't 
get myself to write a very long mail (I'm more a coder than writer...) 
about the whole idea, my proposal of how it could look and problems we 
need to solve, but I'll try better this evening.

Best regards,
Tomasz



From linux at arm.linux.org.uk  Sat Jul 27 06:38:11 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 27 Jul 2013 11:38:11 +0100
Subject: [PATCH] pinctrl: shut up a couple of pinctrl warnings
Message-ID: <20130727103811.GD24642@n2100.arm.linux.org.uk>

So, I notice that we get a couple of warnings from the pinctrl code:

drivers/pinctrl/pinconf.c: In function 'pinconf_dbg_config_print':
drivers/pinctrl/pinconf.c:433:36: warning: 'configs' may be used uninitialized in this function
drivers/pinctrl/pinconf.c: In function 'pinconf_dbg_config_write':
drivers/pinctrl/pinconf.c:511:36: warning: 'configs' may be used uninitialized in this function

While the compiler might not be able to work out that "configs" is
safe, the code doesn't lend itself very well to identifying that
fact when reading it either.  This can be trivially solved by a slight
restructuring of the code - which also reduces the LOC.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
This patch is not yet build tested; it'll go through the build system
tonight though.

 drivers/pinctrl/pinconf.c |   29 +++++++++++------------------
 1 files changed, 11 insertions(+), 18 deletions(-)

diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index e875f21..0674df3 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -428,12 +428,11 @@ static int pinconf_dbg_config_print(struct seq_file *s, void *d)
 {
 	struct pinctrl_maps *maps_node;
 	const struct pinctrl_map *map;
-	struct pinctrl_dev *pctldev = NULL;
+	const struct pinctrl_map *found = NULL;
+	struct pinctrl_dev *pctldev;
 	const struct pinconf_ops *confops = NULL;
-	const struct pinctrl_map_configs *configs;
 	struct dbg_cfg *dbg = &pinconf_dbg_conf;
 	int i, j;
-	bool found = false;
 	unsigned long config;
 
 	mutex_lock(&pinctrl_maps_mutex);
@@ -450,14 +449,8 @@ static int pinconf_dbg_config_print(struct seq_file *s, void *d)
 		for (j = 0; j < map->data.configs.num_configs; j++) {
 			if (!strcmp(map->data.configs.group_or_pin,
 					dbg->pin_name)) {
-				/*
-				 * We found the right pin / state, read the
-				 * config and he pctldev for later use
-				 */
-				configs = &map->data.configs;
-				pctldev = get_pinctrl_dev_from_devname
-					(map->ctrl_dev_name);
-				found = true;
+				/* We found the right pin / state */
+				found = map;
 				break;
 			}
 		}
@@ -473,7 +466,8 @@ static int pinconf_dbg_config_print(struct seq_file *s, void *d)
 		goto exit;
 	}
 
-	config = *(configs->configs);
+	pctldev = get_pinctrl_dev_from_devname(found->ctrl_dev_name);
+	config = *found->data.configs.configs;
 	seq_printf(s, "Dev %s has config of %s in state %s: 0x%08lX\n",
 			dbg->dev_name, dbg->pin_name,
 			dbg->state_name, config);
@@ -505,12 +499,12 @@ static int pinconf_dbg_config_write(struct file *file,
 {
 	struct pinctrl_maps *maps_node;
 	const struct pinctrl_map *map;
-	struct pinctrl_dev *pctldev = NULL;
+	const struct pinctrl_map *found = NULL;
+	struct pinctrl_dev *pctldev;
 	const struct pinconf_ops *confops = NULL;
 	struct dbg_cfg *dbg = &pinconf_dbg_conf;
 	const struct pinctrl_map_configs *configs;
 	char config[MAX_NAME_LEN+1];
-	bool found = false;
 	char buf[128];
 	char *b = &buf[0];
 	int buf_size;
@@ -588,10 +582,7 @@ static int pinconf_dbg_config_write(struct file *file,
 
 		/*  we found the right pin / state, so overwrite config */
 		if (!strcmp(map->data.configs.group_or_pin, dbg->pin_name)) {
-			found = true;
-			pctldev = get_pinctrl_dev_from_devname(
-					map->ctrl_dev_name);
-			configs = &map->data.configs;
+			found = map;
 			break;
 		}
 	}
@@ -601,10 +592,12 @@ static int pinconf_dbg_config_write(struct file *file,
 		goto exit;
 	}
 
+	pctldev = get_pinctrl_dev_from_devname(map->ctrl_dev_name);
 	if (pctldev)
 		confops = pctldev->desc->confops;
 
 	if (confops && confops->pin_config_dbg_parse_modify) {
+		configs = &map->data.configs;
 		for (i = 0; i < configs->num_configs; i++) {
 			confops->pin_config_dbg_parse_modify(pctldev,
 						     config,


From broonie at kernel.org  Sat Jul 27 06:40:18 2013
From: broonie at kernel.org (Mark Brown)
Date: Sat, 27 Jul 2013 11:40:18 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130727084825.GA4707@netboy>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726045433.GB4100@netboy>
 <20130726171524.GB28895@obsidianresearch.com>
 <20130727084825.GA4707@netboy>
Message-ID: <20130727104018.GC9858@sirena.org.uk>

On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote:

> [ I disagree about the "more thought" part. The current discussion,
>   coming years too late after the introduction of DT to ARM Linux, is
>   contrary evidence enough. ]

We did have exactly the same discussion when the DT transition was
started - this isn't something that people only just realised might be
an issue.  There was a deliberate decision to focus on getting the
technology deployed to the point where it could be used as a straight
replacement for board files and accept that sometimes the results won't
be perfect and that we may need to rework as a result.

To be clear the idea has always been to try for bindings that can be
stable but we didn't have the process to guarantee that and there were
substantial barriers in place to creating it while there was no critical
mass behind adoption.  What people are saying now is that we're now at a
point where it looks like those barriers can be overcome.
-------------- 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/20130727/8d414b08/attachment.sig>

From hanjun.guo at linaro.org  Sat Jul 27 06:42:07 2013
From: hanjun.guo at linaro.org (Hanjun Guo)
Date: Sat, 27 Jul 2013 18:42:07 +0800
Subject: [RFC][PATCH 1/2] ARM64: add cpu topology definition
Message-ID: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>

Power aware scheduling needs the cpu topology information to improve the
cpu scheduler decision making.

For ARM64, we can get the topology from the MPIDR register which defines the
the affinity of processors.

This patch is mainly based on arch/arm/kernel/topology.c written by
Vincent Guittot, and replaced the topology array with per cpu variable.

Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
---
 arch/arm64/Kconfig                |    9 +++
 arch/arm64/include/asm/cputype.h  |   11 ++++
 arch/arm64/include/asm/topology.h |   41 ++++++++++++
 arch/arm64/kernel/Makefile        |    1 +
 arch/arm64/kernel/smp.c           |    6 ++
 arch/arm64/kernel/topology.c      |  128 +++++++++++++++++++++++++++++++++++++
 6 files changed, 196 insertions(+)
 create mode 100644 arch/arm64/include/asm/topology.h
 create mode 100644 arch/arm64/kernel/topology.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9737e97..f0ce91b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -150,6 +150,15 @@ config SMP
 
 	  If you don't know what to do here, say N.
 
+config ARM64_CPU_TOPOLOGY
+	bool "Support cpu topology definition"
+	depends on SMP && ARM64
+	default y
+	help
+	  Support ARM64 cpu topology definition. The MPIDR register defines
+	  affinity between processors which is then used to describe the cpu
+	  topology of an ARM64 System.
+
 config NR_CPUS
 	int "Maximum number of CPUs (2-32)"
 	range 2 32
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 5fe138e..68b55af 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -30,6 +30,17 @@
 
 #define MPIDR_HWID_BITMASK	0xff00ffffff
 
+#define MPIDR_SMP_BITMASK	(0x1 << 30)
+#define MPIDR_MT_BITMASK	(0x1 << 24)
+
+#define MPIDR_LEVEL_BITS	8
+#define MPIDR_LEVEL_MASK 	((1 << MPIDR_LEVEL_BITS) - 1)
+
+#define MPIDR_AFFINITY_LEVEL_0(mpidr) ((mpidr) & MPIDR_LEVEL_MASK)
+#define MPIDR_AFFINITY_LEVEL_1(mpidr) ((mpidr >> 8) & MPIDR_LEVEL_MASK)
+#define MPIDR_AFFINITY_LEVEL_2(mpidr) ((mpidr >> 16) & MPIDR_LEVEL_MASK)
+#define MPIDR_AFFINITY_LEVEL_3(mpidr) ((mpidr >> 32) & MPIDR_LEVEL_MASK)
+
 #define read_cpuid(reg) ({						\
 	u64 __val;							\
 	asm("mrs	%0, " reg : "=r" (__val));			\
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
new file mode 100644
index 0000000..8631808
--- /dev/null
+++ b/arch/arm64/include/asm/topology.h
@@ -0,0 +1,41 @@
+#ifndef _ASM_ARM64_TOPOLOGY_H
+#define _ASM_ARM64_TOPOLOGY_H
+
+#ifdef CONFIG_ARM64_CPU_TOPOLOGY
+
+#include <linux/cpumask.h>
+
+struct cputopo_arm64 {
+	int thread_id;
+	int core_id;
+	int socket_id;
+	cpumask_t thread_sibling;
+	cpumask_t core_sibling;
+};
+
+DECLARE_PER_CPU(struct cputopo_arm64, cpu_topology);
+
+#define cpu_topo(cpu) per_cpu(cpu_topology, cpu)
+
+#define topology_physical_package_id(cpu)	(cpu_topo(cpu).socket_id)
+#define topology_core_id(cpu)		(cpu_topo(cpu).core_id)
+#define topology_core_cpumask(cpu)	(&cpu_topo(cpu).core_sibling)
+#define topology_thread_cpumask(cpu)	(&cpu_topo(cpu).thread_sibling)
+
+#define mc_capable()	(cpu_topo(0).socket_id != -1)
+#define smt_capable()	(cpu_topo(0).thread_id != -1)
+
+void init_cpu_topology(void);
+void store_cpu_topology(unsigned int cpuid);
+const struct cpumask *cpu_coregroup_mask(int cpu);
+
+#else
+
+static inline void init_cpu_topology(void) { }
+static inline void store_cpu_topology(unsigned int cpuid) { }
+
+#endif
+
+#include <asm-generic/topology.h>
+
+#endif /* _ASM_ARM64_TOPOLOGY_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 7b4b564..a47c359 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -18,6 +18,7 @@ arm64-obj-$(CONFIG_SMP)			+= smp.o smp_spin_table.o smp_psci.o
 arm64-obj-$(CONFIG_HW_PERF_EVENTS)	+= perf_event.o
 arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT)+= hw_breakpoint.o
 arm64-obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
+arm64-obj-$(CONFIG_ARM64_CPU_TOPOLOGY)  += topology.o
 
 obj-y					+= $(arm64-obj-y) vdso/
 obj-m					+= $(arm64-obj-m)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index fee5cce..197b1da 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -39,6 +39,7 @@
 #include <asm/atomic.h>
 #include <asm/cacheflush.h>
 #include <asm/cputype.h>
+#include <asm/topology.h>
 #include <asm/mmu_context.h>
 #include <asm/pgtable.h>
 #include <asm/pgalloc.h>
@@ -215,6 +216,8 @@ asmlinkage void secondary_start_kernel(void)
 	local_irq_enable();
 	local_fiq_enable();
 
+	store_cpu_topology(cpu);
+
 	/*
 	 * OK, it's off to the idle thread for us
 	 */
@@ -387,6 +390,9 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 	int cpu, err;
 	unsigned int ncores = num_possible_cpus();
 
+	init_cpu_topology();
+	store_cpu_topology(smp_processor_id());
+
 	/*
 	 * are we trying to boot more cores than exist?
 	 */
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
new file mode 100644
index 0000000..1eb0435
--- /dev/null
+++ b/arch/arm64/kernel/topology.c
@@ -0,0 +1,128 @@
+/*
+ * arch/arm64/kernel/topology.c
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ * Written by: Hanjun Guo
+ *
+ * based on arch/arm/kernel/topology.c
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include <linux/cpu.h>
+#include <linux/cpumask.h>
+#include <linux/init.h>
+#include <linux/percpu.h>
+#include <linux/sched.h>
+
+#include <asm/cputype.h>
+#include <asm/topology.h>
+
+DEFINE_PER_CPU(struct cputopo_arm64, cpu_topology);
+
+const struct cpumask *cpu_coregroup_mask(int cpu)
+{
+	return &cpu_topo(cpu).core_sibling;
+}
+
+void update_siblings_masks(unsigned int cpuid)
+{
+	struct cputopo_arm64 *topo, *cpuid_topo = &cpu_topo(cpuid);
+	int cpu;
+
+	/* update core and thread sibling masks */
+	for_each_possible_cpu(cpu) {
+		topo = &cpu_topo(cpu);
+
+		if (cpuid_topo->socket_id != topo->socket_id)
+			continue;
+
+		cpumask_set_cpu(cpuid, &topo->core_sibling);
+		if (cpu != cpuid)
+			cpumask_set_cpu(cpu, &cpuid_topo->core_sibling);
+
+		if (cpuid_topo->core_id != topo->core_id)
+			continue;
+
+		cpumask_set_cpu(cpuid, &topo->thread_sibling);
+		if (cpu != cpuid)
+			cpumask_set_cpu(cpu, &cpuid_topo->thread_sibling);
+	}
+	smp_wmb();
+}
+
+/*
+ * store_cpu_topology is called at boot when only one cpu is running
+ * and with the mutex cpu_hotplug.lock locked, when several cpus have booted,
+ * which prevents simultaneous write access to cpu_topology array
+ */
+void store_cpu_topology(unsigned int cpuid)
+{
+	struct cputopo_arm64 *cpuid_topo = &cpu_topo(cpuid);
+	u64 mpidr;
+
+	/* If the cpu topology has been already set, just return */
+	if (cpuid_topo->core_id != -1)
+		return;
+
+	mpidr = read_cpuid_mpidr();
+
+	/* create cpu topology mapping */
+	if (!(mpidr & MPIDR_SMP_BITMASK)) {
+		/*
+		 * This is a multiprocessor system
+		 * multiprocessor format & multiprocessor mode field are set
+		 */
+
+		if (mpidr & MPIDR_MT_BITMASK) {
+			/* core performance interdependency */
+			cpuid_topo->thread_id = MPIDR_AFFINITY_LEVEL_0(mpidr);
+			cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL_1(mpidr);
+			cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_2(mpidr);
+		} else {
+			/* largely independent cores */
+			cpuid_topo->thread_id = -1;
+			cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL_0(mpidr);
+			cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_1(mpidr);
+		}
+	} else {
+		/*
+		 * This is an uniprocessor system
+		 * we are in multiprocessor format but uniprocessor system
+		 * or in the old uniprocessor format
+		 */
+		cpuid_topo->thread_id = -1;
+		cpuid_topo->core_id = 0;
+		cpuid_topo->socket_id = -1;
+	}
+
+	update_siblings_masks(cpuid);
+
+	printk(KERN_INFO "CPU%u: thread %d, cpu %d, socket %d, mpidr 0x%llx\n",
+		cpuid, cpu_topo(cpuid).thread_id,
+		cpu_topo(cpuid).core_id,
+		cpu_topo(cpuid).socket_id, mpidr);
+}
+
+/*
+ * init_cpu_topology is called at boot when only one cpu is running
+ * which prevent simultaneous write access to cpu_topology array
+ */
+void __init init_cpu_topology(void)
+{
+	unsigned int cpu;
+
+	/* init core mask */
+	for_each_possible_cpu(cpu) {
+		struct cputopo_arm64 *topo = &cpu_topo(cpu);
+
+		topo->thread_id = -1;
+		topo->core_id =  -1;
+		topo->socket_id = -1;
+		cpumask_clear(&topo->core_sibling);
+		cpumask_clear(&topo->thread_sibling);
+	}
+	smp_wmb();
+}
-- 
1.7.9.5



From hanjun.guo at linaro.org  Sat Jul 27 06:42:08 2013
From: hanjun.guo at linaro.org (Hanjun Guo)
Date: Sat, 27 Jul 2013 18:42:08 +0800
Subject: [RFC][PATCH 2/2] ARM64: introduce cluster id and make a difference
 between socket id
In-Reply-To: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>
References: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>
Message-ID: <1374921728-9007-2-git-send-email-hanjun.guo@linaro.org>

In the cpu topology information, we define topology_physical_package_id()
as cpu socket id, which means that the socket id is the idenfication for
physical processor, not for a cluster in a cpu die.

On ARM64 platform, multi cluster in a cpu die will be normal, here is a
example with 2 cores in a cluster and 2 cluster in a socket:

|--------------------------------------|
|                socket                |
|                                      |
| |---------------|  |---------------| |
| |    cluster    |  |    cluster    | |
| |               |  |               | |
| | |----| |----| |  | |----| |----| | |
| | |core| |core| |  | |core| |core| | |
| | |----| |----| |  | |----| |----| | |
| |               |  |               | |
| |---------------|  |---------------| |
|                                      |
|--------------------------------------|

ARM64 extended the MPIDR into 64 bit and introduce another affinity level,
we can use this affinity level for socket id and use the third highest level
affinity for cluster id, which  make the socket id behavior in its original
way.

Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
---
 arch/arm64/include/asm/topology.h |    1 +
 arch/arm64/kernel/topology.c      |    8 ++++++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index 8631808..ff68ecc 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -8,6 +8,7 @@
 struct cputopo_arm64 {
 	int thread_id;
 	int core_id;
+	int cluster_id;
 	int socket_id;
 	cpumask_t thread_sibling;
 	cpumask_t core_sibling;
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 1eb0435..6d1e5a6 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -80,12 +80,14 @@ void store_cpu_topology(unsigned int cpuid)
 			/* core performance interdependency */
 			cpuid_topo->thread_id = MPIDR_AFFINITY_LEVEL_0(mpidr);
 			cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL_1(mpidr);
-			cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_2(mpidr);
+			cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL_2(mpidr);
+			cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_3(mpidr);
 		} else {
 			/* largely independent cores */
 			cpuid_topo->thread_id = -1;
 			cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL_0(mpidr);
-			cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_1(mpidr);
+			cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL_1(mpidr);
+			cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_2(mpidr);
 		}
 	} else {
 		/*
@@ -95,6 +97,7 @@ void store_cpu_topology(unsigned int cpuid)
 		 */
 		cpuid_topo->thread_id = -1;
 		cpuid_topo->core_id = 0;
+		cpuid_topo->cluster_id = -1;
 		cpuid_topo->socket_id = -1;
 	}
 
@@ -120,6 +123,7 @@ void __init init_cpu_topology(void)
 
 		topo->thread_id = -1;
 		topo->core_id =  -1;
+		topo->cluster_id = -1;
 		topo->socket_id = -1;
 		cpumask_clear(&topo->core_sibling);
 		cpumask_clear(&topo->thread_sibling);
-- 
1.7.9.5



From arend at broadcom.com  Sat Jul 27 06:59:58 2013
From: arend at broadcom.com (Arend van Spriel)
Date: Sat, 27 Jul 2013 12:59:58 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <2460092.aLmjrOVh1g@flatron>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
 <2460092.aLmjrOVh1g@flatron>
Message-ID: <51F3A82E.2000907@broadcom.com>

On 07/27/2013 12:36 PM, Tomasz Figa wrote:
> On Saturday 27 of July 2013 12:24:24 Arend van Spriel wrote:
>> On 07/27/2013 11:51 AM, Tomasz Figa wrote:
>>> On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote:
>>>> On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:
>>>>> Long term, final goal is likely to be close to what Russell is
>>>>> saying
>>>>
>>>> Why is this a long term goal? Start today.
>>>>
>>>>> -- nothing should go into the kernel tree unless the binding is in a
>>>>> fully stable state. However, we have a transitional period between
>>>>> now
>>>>> and then, and even when we're at the final state there will be need
>>>>> to
>>>>> have some sort of sandbox for development and test of future
>>>>> bindings.
>>>>
>>>> Why not just set up a git tree right away?
>>>>
>>>>> Dealing with all that, as well as the actual process for locking in
>>>>> bindings, is what needs to be sorted out.
>>>>>
>>>>> I think we're all in agreement that bindings that change over time
>>>>> are
>>>>> nothing but pain, but we're arguing that in circles anyway.
>>>>
>>>> No.
>>>>
>>>> I keep saying, the bindings must be stable ABI, *today*.
>>>>
>>>> You keep saying, maybe later, but until then we will make things up
>>>> as
>>>> we go along.
>>>
>>> We have currently a lot of broken bindings, because people didn't know
>>> how to define ones and those they defined have not been properly
>>> reviewed. Do you really want such broken ABI in the kernel?
>>>
>>> Sure, there are many existing bindings that can be just made stable
>>> and
>>> well they probably are already de facto stable. This is mostly about
>>> subsystem bindings and whatever already has many users, both made them
>>> get more thought when designing and more review before merging.
>>>
>>> Still, a lot of device and platform-specific bindings are simply
>>> broken. Take max8925 backlight driver, that Olof started this whole
>>> discussion with, as an example. We need to sort them out before they
>>> can be stabilized.
>>
>> That is a nice summary of how we got from null to now and Richard seems
>> to be simply saying: let's stop mucking about and make this a project
>> with a well-defined process of dealing with staging and stable bindings
>> and keep stable bindings stable. Whether it should be within the kernel
>> repo as a separate subsystem or in an entire different repo is a trivial
>> decision, but still a decision that needs to be made.
>
> Yes, basically that's our current situation.
>
> Still, I would disagree about the decision being trivial, as each choice
> will have further, and likely pretty significant, consequences on binding
> maintenance, submission, review and for dependent things, like drivers or
> platforms using such bindings. This needs to be discussed enough.
>
>> Apart from stable DT bindings I would love to see a DT compiler that
>> that next to DT syntax detects mistakes in properties used for the
>> selfish reason that I spent hours debugging regulator code, because I
>> typed vmmc_supply iso vmmc-supply. I did not go through all the
>> bindings, but this may require a more formal description so it could be
>> compiled/read in the DT compiler.
>
> This bothered me as well and that's why I'm working on this. I still can't
> get myself to write a very long mail (I'm more a coder than writer...)
> about the whole idea, my proposal of how it could look and problems we
> need to solve, but I'll try better this evening.

Let's see how many people go and scream if I say this: Too bad .dts 
files are not done using XML format as DT bindings could be described 
using XML Schema.

Regards,
Arend



From linux at arm.linux.org.uk  Sat Jul 27 07:09:20 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sat, 27 Jul 2013 12:09:20 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <51F3A238.3020505@broadcom.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <CAOesGMhEr3DiFm5uSgoHPFUMY4jWu4HkeTU2UmOGj=dS75Vk+g@mail.gmail.com>
 <20130727050406.GB4221@netboy> <2007664.vYsECFSKrV@flatron>
 <51F39FD8.6080808@broadcom.com> <51F3A238.3020505@broadcom.com>
Message-ID: <20130727110920.GE24642@n2100.arm.linux.org.uk>

On Sat, Jul 27, 2013 at 12:34:32PM +0200, Arend van Spriel wrote:
> Oh, and the reason for my tinkering on dts is here:
>
> http://mid.gmane.org/51E7AA24.6080600 at broadcom.com
>
> Happily using Pandaboard for my driver testing and than *kaboom*.  
> board-omap4panda.c is gone although the device tree does not provide the  
> same functionality. Of course, this is not about DT bindings.

Similar happened to the 4430SDP board - and I took it out of the build
system for over a month because of that.  I knew it would be _painful_
to get DT and running on the board, and I was right, not only because of
the different build process, but also trying to find which kernel config
options need to be added to a previously working configuration for what
is essentially a black box board.

The MMC device for the rootfs magically changed too - which meant finding
out how to tell the kernel which device to use as the rootfs without
giving it an explicit device.  (Using UUIDs, which aren't real UUIDs and
aren't related to the filesystem UUID either - I've still no idea where
this magic number comes from or how to identify it from a running system.)

It's also made a total mess of the boot log.  I've no idea if all the
devices were successfully probed because there's now soo much noise from
the deferred probing that it's like trying to work out if there's any
serious warnings in a kernel build where every file spits out a warning.
It's almost a pen and paper job to work it out.  There's just too much
noise in the kernel boot now that I'm just not going to bother reading
the boot log anymore unless there's something which has noticably failed.

On the plus side, the DT description for the SDP board _may_ have helped
to solve a problem I've had for over two years: that is why the LCDs don't
seem to work on the board.  It seems I need the TWL PWM driver.  I don't
yet know if this has solved the problem or not, because I've not seen the
board boot with that driver in it.  However, it's not clear to me from the
DT description whether that covers both of the LCDs or just one though.


From mpa at pengutronix.de  Sat Jul 27 07:31:53 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 27 Jul 2013 13:31:53 +0200
Subject: [PATCH v10 4/7] ASoC: fsl-ssi: Add support for imx-pcm-fiq
In-Reply-To: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
References: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1374924716-23475-5-git-send-email-mpa@pengutronix.de>

Add support for non-dma pcm for imx platforms with imx-pcm-fiq support.
Instead of imx-pcm-audio, in this case imx-pcm-fiq-audio device is added
and the SIER flags are set differently.

We need imx-pcm-fiq for some boards that use an incompatible codec.
imx-pcm-fiq handles those codecs differently and allows to operate with
them. DMA is not possible because some data sent by the codecs, e.g.
wm9712, is not in the datastream. Also some data is mixed up in the
fifos, so that we need to sort them out manually.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
Tested-by: Shawn Guo <shawn.guo at linaro.org>
---
 .../devicetree/bindings/sound/fsl,ssi.txt          |  4 ++
 sound/soc/fsl/fsl_ssi.c                            | 79 ++++++++++++++++++----
 2 files changed, 71 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
index 5ff76c9..e45cbce 100644
--- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
@@ -47,6 +47,10 @@ Optional properties:
 - codec-handle:     Phandle to a 'codec' node that defines an audio
                     codec connected to this SSI.  This node is typically
                     a child of an I2C or other control node.
+- fsl,fiq-stream-filter: Bool property. Disabled DMA and use FIQ instead to
+		    filter the codec stream. This is necessary for some boards
+		    where an incompatible codec is connected to this SSI, e.g.
+		    on pca100 and pcm043.
 
 Child 'codec' node required properties:
 - compatible:       Compatible list, contains the name of the codec
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 4d78df7..8b075ef 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -8,6 +8,26 @@
  * This file is licensed under the terms of the GNU General Public License
  * version 2.  This program is licensed "as is" without any warranty of any
  * kind, whether express or implied.
+ *
+ *
+ * Some notes why imx-pcm-fiq is used instead of DMA on some boards:
+ *
+ * The i.MX SSI core has some nasty limitations in AC97 mode. While most
+ * sane processor vendors have a FIFO per AC97 slot, the i.MX has only
+ * one FIFO which combines all valid receive slots. We cannot even select
+ * which slots we want to receive. The WM9712 with which this driver
+ * was developed with always sends GPIO status data in slot 12 which
+ * we receive in our (PCM-) data stream. The only chance we have is to
+ * manually skip this data in the FIQ handler. With sampling rates different
+ * from 48000Hz not every frame has valid receive data, so the ratio
+ * between pcm data and GPIO status data changes. Our FIQ handler is not
+ * able to handle this, hence this driver only works with 48000Hz sampling
+ * rate.
+ * Reading and writing AC97 registers is another challenge. The core
+ * provides us status bits when the read register is updated with *another*
+ * value. When we read the same register two times (and the register still
+ * contains the same value) these status bits are not set. We work
+ * around this by not polling these bits but only wait a fixed delay.
  */
 
 #include <linux/init.h>
@@ -121,11 +141,13 @@ struct fsl_ssi_private {
 
 	bool new_binding;
 	bool ssi_on_imx;
+	bool use_dma;
 	struct clk *clk;
 	struct snd_dmaengine_dai_dma_data dma_params_tx;
 	struct snd_dmaengine_dai_dma_data dma_params_rx;
 	struct imx_dma_data filter_data_tx;
 	struct imx_dma_data filter_data_rx;
+	struct imx_pcm_fiq_params fiq_params;
 
 	struct {
 		unsigned int rfrc;
@@ -355,7 +377,12 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream,
 		 */
 
 		/* Enable the interrupts and DMA requests */
-		write_ssi(SIER_FLAGS, &ssi->sier);
+		if (ssi_private->use_dma)
+			write_ssi(SIER_FLAGS, &ssi->sier);
+		else
+			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN |
+					CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN, &ssi->sier);
 
 		/*
 		 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
@@ -543,7 +570,7 @@ static int fsl_ssi_dai_probe(struct snd_soc_dai *dai)
 {
 	struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(dai);
 
-	if (ssi_private->ssi_on_imx) {
+	if (ssi_private->ssi_on_imx && ssi_private->use_dma) {
 		dai->playback_dma_data = &ssi_private->dma_params_tx;
 		dai->capture_dma_data = &ssi_private->dma_params_rx;
 	}
@@ -683,6 +710,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 
 	strcpy(ssi_private->name, p);
 
+	ssi_private->use_dma = !of_property_read_bool(np,
+			"fsl,fiq-stream-filter");
+
 	/* Initialize this copy of the CPU DAI driver structure */
 	memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
 	       sizeof(fsl_ssi_dai_template));
@@ -707,12 +737,16 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 		return -ENXIO;
 	}
 
-	/* The 'name' should not have any slashes in it. */
-	ret = devm_request_irq(&pdev->dev, ssi_private->irq, fsl_ssi_isr, 0,
-			       ssi_private->name, ssi_private);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "could not claim irq %u\n", ssi_private->irq);
-		goto error_irqmap;
+	if (ssi_private->use_dma) {
+		/* The 'name' should not have any slashes in it. */
+		ret = devm_request_irq(&pdev->dev, ssi_private->irq,
+					fsl_ssi_isr, 0, ssi_private->name,
+					ssi_private);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "could not claim irq %u\n",
+					ssi_private->irq);
+			goto error_irqmap;
+		}
 	}
 
 	/* Are the RX and the TX clocks locked? */
@@ -766,7 +800,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 		 */
 		ret = of_property_read_u32_array(pdev->dev.of_node,
 					"fsl,ssi-dma-events", dma_events, 2);
-		if (ret) {
+		if (ret && !ssi_private->use_dma) {
 			dev_err(&pdev->dev, "could not get dma events\n");
 			goto error_clk;
 		}
@@ -805,9 +839,30 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	}
 
 	if (ssi_private->ssi_on_imx) {
-		ret = imx_pcm_dma_init(pdev);
-		if (ret)
-			goto error_dev;
+		if (!ssi_private->use_dma) {
+
+			/*
+			 * Some boards use an incompatible codec. To get it
+			 * working, we are using imx-fiq-pcm-audio, that
+			 * can handle those codecs. DMA is not possible in this
+			 * situation.
+			 */
+
+			ssi_private->fiq_params.irq = ssi_private->irq;
+			ssi_private->fiq_params.base = ssi_private->ssi;
+			ssi_private->fiq_params.dma_params_rx =
+				&ssi_private->dma_params_rx;
+			ssi_private->fiq_params.dma_params_tx =
+				&ssi_private->dma_params_tx;
+
+			ret = imx_pcm_fiq_init(pdev, &ssi_private->fiq_params);
+			if (ret)
+				goto error_dev;
+		} else {
+			ret = imx_pcm_dma_init(pdev);
+			if (ret)
+				goto error_dev;
+		}
 	}
 
 	/*
-- 
1.8.3.2



From mpa at pengutronix.de  Sat Jul 27 07:31:55 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 27 Jul 2013 13:31:55 +0200
Subject: [PATCH v10 6/7] ASoC: fsl-ssi: ac97-slave support
In-Reply-To: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
References: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1374924716-23475-7-git-send-email-mpa@pengutronix.de>

This patch adds ac97-slave support.

For ac97, the registers have to be setup earlier than for other ssi
modes because there is some communication with the external device
before streaming. So this patch introduces a fsl_ssi_setup function to
setup the registers for different ssi operation modes seperately.

This patch was tested with imx27-pca100.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
Tested-by: Shawn Guo <shawn.guo at linaro.org>
---
 .../devicetree/bindings/sound/fsl,ssi.txt          |   4 +
 sound/soc/fsl/fsl_ssi.c                            | 346 ++++++++++++++++-----
 2 files changed, 280 insertions(+), 70 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
index 088a2c0..4303b6a 100644
--- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
@@ -43,6 +43,10 @@ Required properties:
                     together.  This would still allow different sample sizes,
                     but not different sample rates.
 
+Required are also ac97 link bindings if ac97 is used. See
+Documentation/devicetree/bindings/sound/soc-ac97link.txt for the necessary
+bindings.
+
 Optional properties:
 - codec-handle:     Phandle to a 'codec' node that defines an audio
                     codec connected to this SSI.  This node is typically
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 0c072ff..827af75 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -141,6 +141,7 @@ struct fsl_ssi_private {
 
 	bool new_binding;
 	bool ssi_on_imx;
+	bool imx_ac97;
 	bool use_dma;
 	struct clk *clk;
 	struct snd_dmaengine_dai_dma_data dma_params_tx;
@@ -320,6 +321,124 @@ static irqreturn_t fsl_ssi_isr(int irq, void *dev_id)
 	return ret;
 }
 
+static int fsl_ssi_setup(struct fsl_ssi_private *ssi_private)
+{
+	struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+	u8 i2s_mode;
+	u8 wm;
+	int synchronous = ssi_private->cpu_dai_drv.symmetric_rates;
+
+	if (ssi_private->imx_ac97)
+		i2s_mode = CCSR_SSI_SCR_I2S_MODE_NORMAL | CCSR_SSI_SCR_NET;
+	else
+		i2s_mode = CCSR_SSI_SCR_I2S_MODE_SLAVE;
+
+	/*
+	 * Section 16.5 of the MPC8610 reference manual says that the SSI needs
+	 * to be disabled before updating the registers we set here.
+	 */
+	write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
+
+	/*
+	 * Program the SSI into I2S Slave Non-Network Synchronous mode. Also
+	 * enable the transmit and receive FIFO.
+	 *
+	 * FIXME: Little-endian samples require a different shift dir
+	 */
+	write_ssi_mask(&ssi->scr,
+		CCSR_SSI_SCR_I2S_MODE_MASK | CCSR_SSI_SCR_SYN,
+		CCSR_SSI_SCR_TFR_CLK_DIS |
+		i2s_mode |
+		(synchronous ? CCSR_SSI_SCR_SYN : 0));
+
+	write_ssi(CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TFEN0 |
+		 CCSR_SSI_STCR_TFSI | CCSR_SSI_STCR_TEFS |
+		 CCSR_SSI_STCR_TSCKP, &ssi->stcr);
+
+	write_ssi(CCSR_SSI_SRCR_RXBIT0 | CCSR_SSI_SRCR_RFEN0 |
+		 CCSR_SSI_SRCR_RFSI | CCSR_SSI_SRCR_REFS |
+		 CCSR_SSI_SRCR_RSCKP, &ssi->srcr);
+	/*
+	 * The DC and PM bits are only used if the SSI is the clock master.
+	 */
+
+	/*
+	 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We don't
+	 * use FIFO 1. We program the transmit water to signal a DMA transfer
+	 * if there are only two (or fewer) elements left in the FIFO. Two
+	 * elements equals one frame (left channel, right channel). This value,
+	 * however, depends on the depth of the transmit buffer.
+	 *
+	 * We set the watermark on the same level as the DMA burstsize.  For
+	 * fiq it is probably better to use the biggest possible watermark
+	 * size.
+	 */
+	if (ssi_private->use_dma)
+		wm = ssi_private->fifo_depth - 2;
+	else
+		wm = ssi_private->fifo_depth;
+
+	write_ssi(CCSR_SSI_SFCSR_TFWM0(wm) | CCSR_SSI_SFCSR_RFWM0(wm) |
+		CCSR_SSI_SFCSR_TFWM1(wm) | CCSR_SSI_SFCSR_RFWM1(wm),
+		&ssi->sfcsr);
+
+	/*
+	 * For non-ac97 setups, we keep the SSI disabled because if we enable
+	 * it, then the DMA controller will start. It's not supposed to start
+	 * until the SCR.TE (or SCR.RE) bit is set, but it does anyway. The DMA
+	 * controller will transfer one "BWC" of data (i.e. the amount of data
+	 * that the MR.BWC bits are set to). The reason this is bad is because
+	 * at this point, the PCM driver has not finished initializing the DMA
+	 * controller.
+	 */
+
+
+	/*
+	 * For ac97 interrupts are enabled with the startup of the substream
+	 * because it is also running without an active substream. Normally SSI
+	 * is only enabled when there is a substream.
+	 */
+	if (!ssi_private->imx_ac97) {
+		/* Enable the interrupts and DMA requests */
+		if (ssi_private->use_dma)
+			write_ssi(SIER_FLAGS, &ssi->sier);
+		else
+			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN |
+					CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN, &ssi->sier);
+	} else {
+		/*
+		 * Setup the clock control register
+		 */
+		write_ssi(CCSR_SSI_SxCCR_WL(17) | CCSR_SSI_SxCCR_DC(13),
+				&ssi->stccr);
+		write_ssi(CCSR_SSI_SxCCR_WL(17) | CCSR_SSI_SxCCR_DC(13),
+				&ssi->srccr);
+
+		/*
+		 * Enable AC97 mode and startup the SSI
+		 */
+		write_ssi(CCSR_SSI_SACNT_AC97EN | CCSR_SSI_SACNT_FV,
+				&ssi->sacnt);
+		write_ssi(0xff, &ssi->saccdis);
+		write_ssi(0x300, &ssi->saccen);
+
+		/*
+		 * Enable SSI
+		 */
+		write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_SSIEN);
+		write_ssi(CCSR_SSI_SOR_WAIT(3), &ssi->sor);
+
+		/*
+		 * Enable Transmit and Receive
+		 */
+		write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TE | CCSR_SSI_SCR_RE);
+	}
+
+	return 0;
+}
+
+
 /**
  * fsl_ssi_startup: create a new substream
  *
@@ -341,75 +460,14 @@ static int fsl_ssi_startup(struct snd_pcm_substream *substream,
 	 * and initialize the SSI registers.
 	 */
 	if (!ssi_private->first_stream) {
-		struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
-
 		ssi_private->first_stream = substream;
 
 		/*
-		 * Section 16.5 of the MPC8610 reference manual says that the
-		 * SSI needs to be disabled before updating the registers we set
-		 * here.
-		 */
-		write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
-
-		/*
-		 * Program the SSI into I2S Slave Non-Network Synchronous mode.
-		 * Also enable the transmit and receive FIFO.
-		 *
-		 * FIXME: Little-endian samples require a different shift dir
-		 */
-		write_ssi_mask(&ssi->scr,
-			CCSR_SSI_SCR_I2S_MODE_MASK | CCSR_SSI_SCR_SYN,
-			CCSR_SSI_SCR_TFR_CLK_DIS | CCSR_SSI_SCR_I2S_MODE_SLAVE
-			| (synchronous ? CCSR_SSI_SCR_SYN : 0));
-
-		write_ssi(CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TFEN0 |
-			 CCSR_SSI_STCR_TFSI | CCSR_SSI_STCR_TEFS |
-			 CCSR_SSI_STCR_TSCKP, &ssi->stcr);
-
-		write_ssi(CCSR_SSI_SRCR_RXBIT0 | CCSR_SSI_SRCR_RFEN0 |
-			 CCSR_SSI_SRCR_RFSI | CCSR_SSI_SRCR_REFS |
-			 CCSR_SSI_SRCR_RSCKP, &ssi->srcr);
-
-		/*
-		 * The DC and PM bits are only used if the SSI is the clock
-		 * master.
-		 */
-
-		/* Enable the interrupts and DMA requests */
-		if (ssi_private->use_dma)
-			write_ssi(SIER_FLAGS, &ssi->sier);
-		else
-			write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN |
-					CCSR_SSI_SIER_RIE |
-					CCSR_SSI_SIER_RFF0_EN, &ssi->sier);
-
-		/*
-		 * Set the watermark for transmit FIFI 0 and receive FIFO 0. We
-		 * don't use FIFO 1.  We program the transmit water to signal a
-		 * DMA transfer if there are only two (or fewer) elements left
-		 * in the FIFO.  Two elements equals one frame (left channel,
-		 * right channel).  This value, however, depends on the depth of
-		 * the transmit buffer.
-		 *
-		 * We program the receive FIFO to notify us if at least two
-		 * elements (one frame) have been written to the FIFO.  We could
-		 * make this value larger (and maybe we should), but this way
-		 * data will be written to memory as soon as it's available.
-		 */
-		write_ssi(CCSR_SSI_SFCSR_TFWM0(ssi_private->fifo_depth - 2) |
-			CCSR_SSI_SFCSR_RFWM0(ssi_private->fifo_depth - 2),
-			&ssi->sfcsr);
-
-		/*
-		 * We keep the SSI disabled because if we enable it, then the
-		 * DMA controller will start.  It's not supposed to start until
-		 * the SCR.TE (or SCR.RE) bit is set, but it does anyway.  The
-		 * DMA controller will transfer one "BWC" of data (i.e. the
-		 * amount of data that the MR.BWC bits are set to).  The reason
-		 * this is bad is because at this point, the PCM driver has not
-		 * finished initializing the DMA controller.
+		 * fsl_ssi_setup was already called by ac97_init earlier if
+		 * the driver is in ac97 mode.
 		 */
+		if (!ssi_private->imx_ac97)
+			fsl_ssi_setup(ssi_private);
 	} else {
 		if (synchronous) {
 			struct snd_pcm_runtime *first_runtime =
@@ -538,7 +596,8 @@ static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd,
 		else
 			write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_RE, 0);
 
-		if ((read_ssi(&ssi->scr) & (CCSR_SSI_SCR_TE | CCSR_SSI_SCR_RE)) == 0)
+		if (!ssi_private->imx_ac97 && (read_ssi(&ssi->scr) &
+					(CCSR_SSI_SCR_TE | CCSR_SSI_SCR_RE)) == 0)
 			write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
 		break;
 
@@ -608,6 +667,133 @@ static const struct snd_soc_component_driver fsl_ssi_component = {
 	.name		= "fsl-ssi",
 };
 
+/**
+ * fsl_ssi_ac97_trigger: start and stop the AC97 receive/transmit.
+ *
+ * This function is called by ALSA to start, stop, pause, and resume the
+ * transfer of data.
+ */
+static int fsl_ssi_ac97_trigger(struct snd_pcm_substream *substream, int cmd,
+			   struct snd_soc_dai *dai)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(
+			rtd->cpu_dai);
+	struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+
+	switch (cmd) {
+	case SNDRV_PCM_TRIGGER_START:
+	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+			write_ssi_mask(&ssi->sier, 0, CCSR_SSI_SIER_TIE |
+					CCSR_SSI_SIER_TFE0_EN);
+		else
+			write_ssi_mask(&ssi->sier, 0, CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN);
+		break;
+
+	case SNDRV_PCM_TRIGGER_STOP:
+	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+			write_ssi_mask(&ssi->sier, CCSR_SSI_SIER_TIE |
+					CCSR_SSI_SIER_TFE0_EN, 0);
+		else
+			write_ssi_mask(&ssi->sier, CCSR_SSI_SIER_RIE |
+					CCSR_SSI_SIER_RFF0_EN, 0);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+		write_ssi(CCSR_SSI_SOR_TX_CLR, &ssi->sor);
+	else
+		write_ssi(CCSR_SSI_SOR_RX_CLR, &ssi->sor);
+
+	return 0;
+}
+
+static const struct snd_soc_dai_ops fsl_ssi_ac97_dai_ops = {
+	.startup	= fsl_ssi_startup,
+	.shutdown	= fsl_ssi_shutdown,
+	.trigger	= fsl_ssi_ac97_trigger,
+};
+
+static struct snd_soc_dai_driver fsl_ssi_ac97_dai = {
+	.ac97_control = 1,
+	.playback = {
+		.stream_name = "AC97 Playback",
+		.channels_min = 2,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_8000_48000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.capture = {
+		.stream_name = "AC97 Capture",
+		.channels_min = 2,
+		.channels_max = 2,
+		.rates = SNDRV_PCM_RATE_48000,
+		.formats = SNDRV_PCM_FMTBIT_S16_LE,
+	},
+	.ops = &fsl_ssi_ac97_dai_ops,
+};
+
+
+static struct fsl_ssi_private *fsl_ac97_data;
+
+static void fsl_ssi_ac97_init(void)
+{
+	fsl_ssi_setup(fsl_ac97_data);
+}
+
+void fsl_ssi_ac97_write(struct snd_ac97 *ac97, unsigned short reg,
+		unsigned short val)
+{
+	struct ccsr_ssi *ssi = fsl_ac97_data->ssi;
+	unsigned int lreg;
+	unsigned int lval;
+
+	if (reg > 0x7f)
+		return;
+
+
+	lreg = reg <<  12;
+	write_ssi(lreg, &ssi->sacadd);
+
+	lval = val << 4;
+	write_ssi(lval , &ssi->sacdat);
+
+	write_ssi_mask(&ssi->sacnt, CCSR_SSI_SACNT_RDWR_MASK,
+			CCSR_SSI_SACNT_WR);
+	udelay(100);
+}
+
+unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
+		unsigned short reg)
+{
+	struct ccsr_ssi *ssi = fsl_ac97_data->ssi;
+
+	unsigned short val = -1;
+	unsigned int lreg;
+
+	lreg = (reg & 0x7f) <<  12;
+	write_ssi(lreg, &ssi->sacadd);
+	write_ssi_mask(&ssi->sacnt, CCSR_SSI_SACNT_RDWR_MASK,
+			CCSR_SSI_SACNT_RD);
+
+	udelay(100);
+
+	val = (read_ssi(&ssi->sacdat) >> 4) & 0xffff;
+
+	return val;
+}
+
+static struct snd_ac97_bus_ops fsl_ssi_ac97_ops = {
+	.read		= fsl_ssi_ac97_read,
+	.write		= fsl_ssi_ac97_write,
+};
+
 /* Show the statistics of a flag only if its interrupt is enabled.  The
  * compiler will optimze this code to a no-op if the interrupt is not
  * enabled.
@@ -684,6 +870,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	struct resource res;
 	char name[64];
 	bool shared;
+	bool ac97 = false;
 
 	/* SSIs that are not connected on the board should have a
 	 *      status = "disabled"
@@ -694,7 +881,13 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 
 	/* We only support the SSI in "I2S Slave" mode */
 	sprop = of_get_property(np, "fsl,mode", NULL);
-	if (!sprop || strcmp(sprop, "i2s-slave")) {
+	if (!sprop) {
+		dev_err(&pdev->dev, "fsl,mode property is necessary\n");
+		return -EINVAL;
+	}
+	if (!strcmp(sprop, "ac97-slave")) {
+		ac97 = true;
+	} else if (strcmp(sprop, "i2s-slave")) {
 		dev_notice(&pdev->dev, "mode %s is unsupported\n", sprop);
 		return -ENODEV;
 	}
@@ -713,9 +906,19 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	ssi_private->use_dma = !of_property_read_bool(np,
 			"fsl,fiq-stream-filter");
 
-	/* Initialize this copy of the CPU DAI driver structure */
-	memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
-	       sizeof(fsl_ssi_dai_template));
+	if (ac97) {
+		memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_ac97_dai,
+				sizeof(fsl_ssi_ac97_dai));
+
+		fsl_ac97_data = ssi_private;
+		ssi_private->imx_ac97 = true;
+
+		snd_soc_set_ac97_ops_of_reset(&fsl_ssi_ac97_ops, pdev);
+	} else {
+		/* Initialize this copy of the CPU DAI driver structure */
+		memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
+		       sizeof(fsl_ssi_dai_template));
+	}
 	ssi_private->cpu_dai_drv.name = ssi_private->name;
 
 	/* Get the addresses and IRQ */
@@ -901,6 +1104,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 	}
 
 done:
+	if (ssi_private->imx_ac97)
+		fsl_ssi_ac97_init();
+
 	return 0;
 
 error_dai:
-- 
1.8.3.2



From mpa at pengutronix.de  Sat Jul 27 07:31:49 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 27 Jul 2013 13:31:49 +0200
Subject: [PATCH v10 0/7] ASoC: fsl-ssi: ac97-slave support
Message-ID: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>

Hi,

this series implements ac97-slave support for fsl-ssi and phycore ac97 DT
support.

Since v9 there were a lot of changes. I dropped the board specific ac97-link
reset functions and added generic functions to soc-core. It uses devicetree
parsed pinctrl and gpios. The audmux setup was removed from phycore-ac97-dt.
The initial setup can now be defined in DT.

Regards,

Markus


Markus Pargmann (7):
      ASoC: core: Generic ac97 link reset functions
      ASoC: codec: wm9712 simple DT bindings
      ASoC: imx-audmux: Read default configuration from devicetree
      ASoC: fsl-ssi: Add support for imx-pcm-fiq
      ASoC: fsl-ssi: Use generic DMA bindings if possible
      ASoC: fsl-ssi: ac97-slave support
      ASoC: Add phycore-ac97-dt driver

 .../devicetree/bindings/sound/fsl,ssi.txt          |  12 +
 .../devicetree/bindings/sound/imx-audmux.txt       |   9 +
 .../bindings/sound/phytec,phycore-ac97.txt         |  16 +
 .../devicetree/bindings/sound/soc-ac97link.txt     |  28 ++
 Documentation/devicetree/bindings/sound/wm9712.txt |  10 +
 include/sound/soc.h                                |   2 +
 sound/soc/codecs/wm9712.c                          |   9 +
 sound/soc/fsl/Kconfig                              |  15 +-
 sound/soc/fsl/Makefile                             |   2 +
 sound/soc/fsl/fsl_ssi.c                            | 431 +++++++++++++++++----
 sound/soc/fsl/imx-audmux.c                         |  62 +++
 sound/soc/fsl/phycore-ac97-dt.c                    | 124 ++++++
 sound/soc/fsl/phycore-ac97.c                       |  13 +-
 sound/soc/soc-core.c                               | 153 ++++++++
 14 files changed, 789 insertions(+), 97 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
 create mode 100644 Documentation/devicetree/bindings/sound/soc-ac97link.txt
 create mode 100644 Documentation/devicetree/bindings/sound/wm9712.txt
 create mode 100644 sound/soc/fsl/phycore-ac97-dt.c



From mpa at pengutronix.de  Sat Jul 27 07:31:52 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 27 Jul 2013 13:31:52 +0200
Subject: [PATCH v10 3/7] ASoC: imx-audmux: Read default configuration from
 devicetree
In-Reply-To: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
References: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1374924716-23475-4-git-send-email-mpa@pengutronix.de>

Adds a function to parse a default port configuration from devicetree.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 .../devicetree/bindings/sound/imx-audmux.txt       |  9 ++++
 sound/soc/fsl/imx-audmux.c                         | 62 ++++++++++++++++++++++
 2 files changed, 71 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/imx-audmux.txt b/Documentation/devicetree/bindings/sound/imx-audmux.txt
index 215aa98..f88a00e 100644
--- a/Documentation/devicetree/bindings/sound/imx-audmux.txt
+++ b/Documentation/devicetree/bindings/sound/imx-audmux.txt
@@ -5,6 +5,15 @@ Required properties:
   or "fsl,imx31-audmux" for the version firstly used on i.MX31.
 - reg : Should contain AUDMUX registers location and length
 
+An initial configuration can be setup using child nodes.
+
+Required properties of optional child nodes:
+- fsl,audmux-port : Integer of the audmux port that is configured by this
+  child node.
+- fsl,port-config : List of configuration options for the specific port. For
+  imx31-audmux and above, it is a list of tuples <ptcr pdcr>. For
+  imx21-audmux it is a list of pcr values.
+
 Example:
 
 audmux at 021d8000 {
diff --git a/sound/soc/fsl/imx-audmux.c b/sound/soc/fsl/imx-audmux.c
index 1a5da1e..103d1b0 100644
--- a/sound/soc/fsl/imx-audmux.c
+++ b/sound/soc/fsl/imx-audmux.c
@@ -251,6 +251,66 @@ int imx_audmux_v2_configure_port(unsigned int port, unsigned int ptcr,
 }
 EXPORT_SYMBOL_GPL(imx_audmux_v2_configure_port);
 
+static int imx_audmux_parse_dt_defaults(struct platform_device *pdev,
+		struct device_node *of_node)
+{
+	struct device_node *child;
+
+	for_each_available_child_of_node(of_node, child) {
+		unsigned int port;
+		unsigned int ptcr = 0;
+		unsigned int pdcr = 0;
+		unsigned int pcr = 0;
+		unsigned int val;
+		int ret;
+		int i = 0;
+
+		ret = of_property_read_u32(child, "fsl,audmux-port", &port);
+		if (ret) {
+			dev_warn(&pdev->dev, "Failed to get fsl,audmux-port of child node \"%s\"\n",
+					child->full_name);
+			continue;
+		}
+		if (!of_property_read_bool(child, "fsl,port-config")) {
+			dev_warn(&pdev->dev, "child node \"%s\" does not have property fsl,port-config\n",
+					child->full_name);
+			continue;
+		}
+
+		for (i = 0; (ret = of_property_read_u32_index(child,
+					"fsl,port-config\n", i, &val)) == 0;
+				++i) {
+			if (audmux_type == IMX31_AUDMUX) {
+				if (i % 2)
+					pdcr |= val;
+				else
+					ptcr |= val;
+			} else {
+				pcr |= val;
+			}
+		}
+
+		if (ret != -ENODATA) {
+			dev_err(&pdev->dev, "Failed to read u32 at index %d of child %s\n",
+					i, child->full_name);
+			continue;
+		}
+
+		if (audmux_type == IMX31_AUDMUX) {
+			if (i % 2) {
+				dev_err(&pdev->dev, "One pdcr value is missing in child node %s\n",
+						child->full_name);
+				continue;
+			}
+			imx_audmux_v2_configure_port(port, ptcr, pdcr);
+		} else {
+			imx_audmux_v1_configure_port(port, pcr);
+		}
+	}
+
+	return 0;
+}
+
 static int imx_audmux_probe(struct platform_device *pdev)
 {
 	struct resource *res;
@@ -275,6 +335,8 @@ static int imx_audmux_probe(struct platform_device *pdev)
 	if (audmux_type == IMX31_AUDMUX)
 		audmux_debugfs_init();
 
+	imx_audmux_parse_dt_defaults(pdev, pdev->dev.of_node);
+
 	return 0;
 }
 
-- 
1.8.3.2



From mpa at pengutronix.de  Sat Jul 27 07:31:54 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 27 Jul 2013 13:31:54 +0200
Subject: [PATCH v10 5/7] ASoC: fsl-ssi: Use generic DMA bindings if possible
In-Reply-To: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
References: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1374924716-23475-6-git-send-email-mpa@pengutronix.de>

There may be some platforms using fsl-ssi that do not have a DMA driver
with generic DMA bindings. So this patch adds support for the generic
DMA bindings, while still accepting the old "fsl,dma-events" property if
"dmas" is not found.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
Tested-by: Shawn Guo <shawn.guo at linaro.org>
---
 Documentation/devicetree/bindings/sound/fsl,ssi.txt |  4 ++++
 sound/soc/fsl/fsl_ssi.c                             | 20 ++++++++++++--------
 2 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
index e45cbce..088a2c0 100644
--- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
@@ -51,6 +51,10 @@ Optional properties:
 		    filter the codec stream. This is necessary for some boards
 		    where an incompatible codec is connected to this SSI, e.g.
 		    on pca100 and pcm043.
+- dmas:		    Generic dma devicetree binding as described in
+		    Documentation/devicetree/bindings/dma/dma.txt.
+- dma-names:	    Two dmas have to be defined, "tx" and "rx", if fsl,imx-fiq
+		    is not defined.
 
 Child 'codec' node required properties:
 - compatible:       Compatible list, contains the name of the codec
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 8b075ef..0c072ff 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -794,15 +794,19 @@ static int fsl_ssi_probe(struct platform_device *pdev)
 			&ssi_private->filter_data_tx;
 		ssi_private->dma_params_rx.filter_data =
 			&ssi_private->filter_data_rx;
-		/*
-		 * TODO: This is a temporary solution and should be changed
-		 * to use generic DMA binding later when the helplers get in.
-		 */
-		ret = of_property_read_u32_array(pdev->dev.of_node,
+		if (!of_property_read_bool(pdev->dev.of_node, "dmas") &&
+				ssi_private->use_dma) {
+			/*
+			 * FIXME: This is a temporary solution until all
+			 * necessary dma drivers support the generic dma
+			 * bindings.
+			 */
+			ret = of_property_read_u32_array(pdev->dev.of_node,
 					"fsl,ssi-dma-events", dma_events, 2);
-		if (ret && !ssi_private->use_dma) {
-			dev_err(&pdev->dev, "could not get dma events\n");
-			goto error_clk;
+			if (ret && ssi_private->use_dma) {
+				dev_err(&pdev->dev, "could not get dma events but fsl-ssi is configured to use DMA\n");
+				goto error_clk;
+			}
 		}
 
 		shared = of_device_is_compatible(of_get_parent(np),
-- 
1.8.3.2



From mpa at pengutronix.de  Sat Jul 27 07:31:50 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 27 Jul 2013 13:31:50 +0200
Subject: [PATCH v10 1/7] ASoC: core: Generic ac97 link reset functions
In-Reply-To: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
References: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1374924716-23475-2-git-send-email-mpa@pengutronix.de>

This patch adds generic ac97 reset functions using pincontrol and gpio
parsed from devicetree.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 .../devicetree/bindings/sound/soc-ac97link.txt     |  28 ++++
 include/sound/soc.h                                |   2 +
 sound/soc/soc-core.c                               | 153 +++++++++++++++++++++
 3 files changed, 183 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/soc-ac97link.txt

diff --git a/Documentation/devicetree/bindings/sound/soc-ac97link.txt b/Documentation/devicetree/bindings/sound/soc-ac97link.txt
new file mode 100644
index 0000000..80152a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/soc-ac97link.txt
@@ -0,0 +1,28 @@
+AC97 link bindings
+
+These bindings can be included within any other device node.
+
+Required properties:
+ - pinctrl-names: Has to contain following states to setup the correct
+   pinmuxing for the used gpios:
+	"ac97-running": AC97-link is active
+	"ac97-reset": AC97-link reset state
+	"ac97-warm-reset": AC97-link warm reset state
+ - ac97-gpios: List of gpio phandles with args in the order ac97-sync,
+   ac97-sdata, ac97-reset
+
+
+Example:
+
+ssi {
+	...
+
+	pinctrl-names = "default", "ac97-running", "ac97-reset", "ac97-warm-reset";
+	pinctrl-0 = <&ac97link_running>;
+	pinctrl-1 = <&ac97link_running>;
+	pinctrl-2 = <&ac97link_reset>;
+	pinctrl-3 = <&ac97link_warm_reset>;
+	ac97-gpios = <&gpio3 20 0 &gpio3 22 0 &gpio3 28 0>;
+
+	...
+};
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 6eabee7..c0ac3bc 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -468,6 +468,8 @@ int snd_soc_new_ac97_codec(struct snd_soc_codec *codec,
 void snd_soc_free_ac97_codec(struct snd_soc_codec *codec);
 
 int snd_soc_set_ac97_ops(struct snd_ac97_bus_ops *ops);
+int snd_soc_set_ac97_ops_of_reset(struct snd_ac97_bus_ops *ops,
+		struct platform_device *pdev);
 
 /*
  *Controls
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 0ec070c..6010932 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -30,9 +30,12 @@
 #include <linux/bitops.h>
 #include <linux/debugfs.h>
 #include <linux/platform_device.h>
+#include <linux/pinctrl/consumer.h>
 #include <linux/ctype.h>
 #include <linux/slab.h>
 #include <linux/of.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
 #include <sound/ac97_codec.h>
 #include <sound/core.h>
 #include <sound/jack.h>
@@ -69,6 +72,16 @@ static int pmdown_time = 5000;
 module_param(pmdown_time, int, 0);
 MODULE_PARM_DESC(pmdown_time, "DAPM stream powerdown time (msecs)");
 
+struct snd_ac97_reset_cfg {
+	struct pinctrl *pctl;
+	struct pinctrl_state *pstate_reset;
+	struct pinctrl_state *pstate_warm_reset;
+	struct pinctrl_state *pstate_run;
+	int gpio_sdata;
+	int gpio_sync;
+	int gpio_reset;
+};
+
 /* returns the minimum number of bytes needed to represent
  * a particular given value */
 static int min_bytes_needed(unsigned long val)
@@ -2080,6 +2093,117 @@ int snd_soc_new_ac97_codec(struct snd_soc_codec *codec,
 }
 EXPORT_SYMBOL_GPL(snd_soc_new_ac97_codec);
 
+static struct snd_ac97_reset_cfg snd_ac97_rst_cfg;
+
+static void snd_soc_ac97_warm_reset(struct snd_ac97 *ac97)
+{
+	struct pinctrl *pctl = snd_ac97_rst_cfg.pctl;
+
+	pinctrl_select_state(pctl, snd_ac97_rst_cfg.pstate_warm_reset);
+
+	gpio_direction_output(snd_ac97_rst_cfg.gpio_sync, 1);
+
+	udelay(10);
+
+	gpio_direction_output(snd_ac97_rst_cfg.gpio_sync, 0);
+
+	pinctrl_select_state(pctl, snd_ac97_rst_cfg.pstate_run);
+	msleep(2);
+}
+
+static void snd_soc_ac97_reset(struct snd_ac97 *ac97)
+{
+	struct pinctrl *pctl = snd_ac97_rst_cfg.pctl;
+
+	pinctrl_select_state(pctl, snd_ac97_rst_cfg.pstate_reset);
+
+	gpio_direction_output(snd_ac97_rst_cfg.gpio_sync, 0);
+	gpio_direction_output(snd_ac97_rst_cfg.gpio_sdata, 0);
+	gpio_direction_output(snd_ac97_rst_cfg.gpio_reset, 0);
+
+	udelay(10);
+
+	gpio_direction_output(snd_ac97_rst_cfg.gpio_reset, 1);
+
+	pinctrl_select_state(pctl, snd_ac97_rst_cfg.pstate_run);
+	msleep(2);
+}
+
+static int snd_soc_ac97_parse_pinctl(struct device *dev,
+		struct snd_ac97_reset_cfg *cfg)
+{
+	struct pinctrl *p;
+	struct pinctrl_state *state;
+	int gpio;
+	int ret;
+
+	p = devm_pinctrl_get(dev);
+	if (IS_ERR(p)) {
+		dev_err(dev, "Failed to get pinctrl\n");
+		return PTR_RET(p);
+	}
+	cfg->pctl = p;
+
+	state = pinctrl_lookup_state(p, "ac97-reset");
+	if (IS_ERR(state)) {
+		dev_err(dev, "Can't find pinctrl state ac97-reset\n");
+		return PTR_RET(state);
+	}
+	cfg->pstate_reset = state;
+
+	state = pinctrl_lookup_state(p, "ac97-warm-reset");
+	if (IS_ERR(state)) {
+		dev_err(dev, "Can't find pinctrl state ac97-warm-reset\n");
+		return PTR_RET(state);
+	}
+	cfg->pstate_warm_reset = state;
+
+	state = pinctrl_lookup_state(p, "ac97-running");
+	if (IS_ERR(state)) {
+		dev_err(dev, "Can't find pinctrl state ac97-running\n");
+		return PTR_RET(state);
+	}
+	cfg->pstate_run = state;
+
+	gpio = of_get_named_gpio(dev->of_node, "ac97-gpios", 0);
+	if (gpio < 0) {
+		dev_err(dev, "Can't find ac97-sync gpio\n");
+		return gpio;
+	}
+	ret = devm_gpio_request(dev, gpio, "AC97 link sync");
+	if (ret) {
+		dev_err(dev, "Failed requesting ac97-sync gpio\n");
+		return ret;
+	}
+	cfg->gpio_sync = gpio;
+
+	gpio = of_get_named_gpio(dev->of_node, "ac97-gpios", 1);
+	if (gpio < 0) {
+		dev_err(dev, "Can't find ac97-sdata gpio %d\n", gpio);
+		return gpio;
+	}
+	ret = devm_gpio_request(dev, gpio, "AC97 link sdata");
+	if (ret) {
+		dev_err(dev, "Failed requesting ac97-sdata gpio\n");
+		return ret;
+	}
+	cfg->gpio_sdata = gpio;
+
+	gpio = of_get_named_gpio(dev->of_node, "ac97-gpios", 2);
+	if (gpio < 0) {
+		dev_err(dev, "Can't find ac97-reset gpio\n");
+		return gpio;
+	}
+	ret = devm_gpio_request(dev, gpio, "AC97 link reset");
+	if (ret) {
+		dev_err(dev, "Failed requesting ac97-reset gpio\n");
+		return ret;
+	}
+	cfg->gpio_reset = gpio;
+
+	return 0;
+}
+
 struct snd_ac97_bus_ops *soc_ac97_ops;
 EXPORT_SYMBOL_GPL(soc_ac97_ops);
 
@@ -2098,6 +2222,35 @@ int snd_soc_set_ac97_ops(struct snd_ac97_bus_ops *ops)
 EXPORT_SYMBOL_GPL(snd_soc_set_ac97_ops);
 
 /**
+ * snd_soc_set_ac97_ops_of_reset - Set ac97 ops with generic ac97 reset functions
+ *
+ * This function sets the reset and warm_reset properties of ops and parses
+ * the device node of pdev to get pinctrl states and gpio numbers to use.
+ */
+int snd_soc_set_ac97_ops_of_reset(struct snd_ac97_bus_ops *ops,
+		struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct snd_ac97_reset_cfg cfg;
+	int ret;
+
+	ret = snd_soc_ac97_parse_pinctl(dev, &cfg);
+	if (ret)
+		return ret;
+
+	ret = snd_soc_set_ac97_ops(ops);
+	if (ret)
+		return ret;
+
+	ops->warm_reset = snd_soc_ac97_warm_reset;
+	ops->reset = snd_soc_ac97_reset;
+
+	snd_ac97_rst_cfg = cfg;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(snd_soc_set_ac97_ops_of_reset);
+
+/**
  * snd_soc_free_ac97_codec - free AC97 codec device
  * @codec: audio codec
  *
-- 
1.8.3.2



From mpa at pengutronix.de  Sat Jul 27 07:31:51 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 27 Jul 2013 13:31:51 +0200
Subject: [PATCH v10 2/7] ASoC: codec: wm9712 simple DT bindings
In-Reply-To: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
References: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1374924716-23475-3-git-send-email-mpa@pengutronix.de>

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 Documentation/devicetree/bindings/sound/wm9712.txt | 10 ++++++++++
 sound/soc/codecs/wm9712.c                          |  9 +++++++++
 2 files changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/wm9712.txt

diff --git a/Documentation/devicetree/bindings/sound/wm9712.txt b/Documentation/devicetree/bindings/sound/wm9712.txt
new file mode 100644
index 0000000..d29f673
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/wm9712.txt
@@ -0,0 +1,10 @@
+WM9712 audio CODEC
+
+Required properties:
+  - compatible : "wlf,wm9712"
+
+Example:
+
+wm9712: codec {
+	compatible = "wlf,wm9712";
+};
diff --git a/sound/soc/codecs/wm9712.c b/sound/soc/codecs/wm9712.c
index c5eb746..d619cdc 100644
--- a/sound/soc/codecs/wm9712.c
+++ b/sound/soc/codecs/wm9712.c
@@ -697,10 +697,19 @@ static int wm9712_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id wm9712_codec_of_dev_id[] = {
+	{
+		.compatible = "wlf,wm9712",
+	}, {
+		/* sentinel */
+	}
+};
+
 static struct platform_driver wm9712_codec_driver = {
 	.driver = {
 		.name = "wm9712-codec",
 		.owner = THIS_MODULE,
+		.of_match_table = wm9712_codec_of_dev_id,
 	},
 
 	.probe = wm9712_probe,
-- 
1.8.3.2



From mpa at pengutronix.de  Sat Jul 27 07:31:56 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 27 Jul 2013 13:31:56 +0200
Subject: [PATCH v10 7/7] ASoC: Add phycore-ac97-dt driver
In-Reply-To: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
References: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
Message-ID: <1374924716-23475-8-git-send-email-mpa@pengutronix.de>

Add devicetree support for phycore-ac97 driver in a seperated driver for
DT loading. The seperation reduces the confusion with the old style
initialization of this driver via late_initcall. Also this driver is
using fsl-ssi instead of imx-ssi.

platform_of_node and cpu_of_node are set according to the fsl,audmux
phandle.

This patch adds handling of ac97 reset functions according to fsl ac97
support. They are setup from here to avoid board specific code in the
generic fsl-ssi driver.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
Tested-by: Shawn Guo <shawn.guo at linaro.org>
---
 .../bindings/sound/phytec,phycore-ac97.txt         |  16 +++
 sound/soc/fsl/Kconfig                              |  15 ++-
 sound/soc/fsl/Makefile                             |   2 +
 sound/soc/fsl/phycore-ac97-dt.c                    | 124 +++++++++++++++++++++
 sound/soc/fsl/phycore-ac97.c                       |  13 +--
 5 files changed, 156 insertions(+), 14 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
 create mode 100644 sound/soc/fsl/phycore-ac97-dt.c

diff --git a/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
new file mode 100644
index 0000000..b3ce9cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
@@ -0,0 +1,16 @@
+Phytec phycore AC97
+
+Required properties:
+- compatible: "phytec,phycore-ac97"
+- phytec,ssi: A phandle to the ssi device that is connected to ac97.
+- phytec,audmux: A phandle to the audmux device.
+- audio-codec: phandle to the codec device node.
+
+Example:
+
+sound {
+	compatible = "phytec,phycore-ac97";
+	phytec,ssi = <&ssi1>;
+	phytec,audmux = <&audmux>;
+	audio-codec = <&codec>;
+};
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3a79d01..5f992b3 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -142,8 +142,8 @@ config SND_SOC_MX27VIS_AIC32X4
 	  board with TLV320AIC32X4 codec.
 
 config SND_SOC_PHYCORE_AC97
-	tristate "SoC Audio support for Phytec phyCORE (and phyCARD) boards"
-	depends on MACH_PCM043 || MACH_PCA100
+	tristate "SoC Audio support for Phytec phyCORE boards"
+	depends on MACH_PCM043
 	select SND_SOC_AC97_BUS
 	select SND_SOC_WM9712
 	select SND_SOC_IMX_PCM_FIQ
@@ -153,6 +153,17 @@ config SND_SOC_PHYCORE_AC97
 	  Say Y if you want to add support for SoC audio on Phytec phyCORE
 	  and phyCARD boards in AC97 mode
 
+config SND_SOC_PHYCORE_AC97_DT
+	tristate "SoC Audio support for Phytec phyCORE (and phyCARD) boards (devicetree only)"
+	select SND_SOC_AC97_BUS
+	select SND_SOC_WM9712
+	select SND_SOC_IMX_PCM_FIQ
+	select SND_SOC_IMX_AUDMUX
+	select SND_SOC_FSL_SSI
+	help
+	  Say Y if you want to add support for SoC audio on Phytec phyCORE
+	  and phyCARD boards in AC97 mode when using devicetree.
+
 config SND_SOC_EUKREA_TLV320
 	tristate "Eukrea TLV320"
 	depends on MACH_EUKREA_MBIMX27_BASEBOARD \
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index d4b4aa8..31bdd69 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_SND_SOC_IMX_PCM_DMA) += imx-pcm-dma.o
 # i.MX Machine Support
 snd-soc-eukrea-tlv320-objs := eukrea-tlv320.o
 snd-soc-phycore-ac97-objs := phycore-ac97.o
+snd-soc-phycore-ac97-dt-objs := phycore-ac97-dt.o
 snd-soc-mx27vis-aic32x4-objs := mx27vis-aic32x4.o
 snd-soc-wm1133-ev1-objs := wm1133-ev1.o
 snd-soc-imx-sgtl5000-objs := imx-sgtl5000.o
@@ -47,6 +48,7 @@ snd-soc-imx-mc13783-objs := imx-mc13783.o
 
 obj-$(CONFIG_SND_SOC_EUKREA_TLV320) += snd-soc-eukrea-tlv320.o
 obj-$(CONFIG_SND_SOC_PHYCORE_AC97) += snd-soc-phycore-ac97.o
+obj-$(CONFIG_SND_SOC_PHYCORE_AC97_DT) += snd-soc-phycore-ac97-dt.o
 obj-$(CONFIG_SND_SOC_MX27VIS_AIC32X4) += snd-soc-mx27vis-aic32x4.o
 obj-$(CONFIG_SND_MXC_SOC_WM1133_EV1) += snd-soc-wm1133-ev1.o
 obj-$(CONFIG_SND_SOC_IMX_SGTL5000) += snd-soc-imx-sgtl5000.o
diff --git a/sound/soc/fsl/phycore-ac97-dt.c b/sound/soc/fsl/phycore-ac97-dt.c
new file mode 100644
index 0000000..46b3423
--- /dev/null
+++ b/sound/soc/fsl/phycore-ac97-dt.c
@@ -0,0 +1,124 @@
+/*
+ * phycore-ac97-dt.c  --  SoC audio for imx_phycore in AC97 mode
+ *
+ * Copyright 2013 Markus Pargmann, Pengutronix <mpa at pengutronix.de>
+ *
+ *  This program is free software; you can redistribute  it and/or modify it
+ *  under  the terms of  the GNU General  Public License as published by the
+ *  Free Software Foundation;  either version 2 of the  License, or (at your
+ *  option) any later version.
+ *
+ */
+
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of.h>
+#include <sound/core.h>
+#include <sound/pcm.h>
+#include <sound/soc.h>
+
+#include "imx-audmux.h"
+#include "fsl_ssi.h"
+
+#define DRV_NAME "phycore-ac97-dt-driver"
+
+struct phycore_ac97_data {
+	struct snd_soc_card card;
+	struct device_node *cpu_np;
+	struct device_node *codec_np;
+};
+
+static struct snd_soc_dai_link imx_phycore_dai_ac97[] = {
+	{
+		.name		= "HiFi",
+		.stream_name	= "HiFi",
+		.codec_dai_name	= "wm9712-hifi",
+	},
+};
+
+static struct snd_soc_card imx_phycore = {
+	.name		= "PhyCORE-ac97-audio",
+	.owner		= THIS_MODULE,
+	.dai_link	= imx_phycore_dai_ac97,
+	.num_links	= ARRAY_SIZE(imx_phycore_dai_ac97),
+};
+
+static const struct of_device_id imx_phycore_ac97_of_dev_id[] = {
+	{
+		.compatible = "phytec,phycore-ac97",
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, imx_phycore_ac97_of_dev_id);
+
+static int imx_phycore_ac97_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct phycore_ac97_data *priv;
+
+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+
+	if (!priv)
+		return -ENOMEM;
+
+	imx_phycore.dev = &pdev->dev;
+
+	priv->cpu_np = of_parse_phandle(pdev->dev.of_node, "phytec,ssi", 0);
+	if (!priv->cpu_np) {
+		dev_err(&pdev->dev, "No valid ssi phandle found\n");
+		return -EINVAL;
+	}
+
+	priv->codec_np = of_parse_phandle(pdev->dev.of_node, "audio-codec", 0);
+	if (!priv->codec_np) {
+		dev_err(&pdev->dev, "No valid codec phandle found\n");
+		of_node_put(priv->cpu_np);
+		return -EINVAL;
+	}
+
+	imx_phycore_dai_ac97[0].cpu_of_node = priv->cpu_np;
+	imx_phycore_dai_ac97[0].platform_of_node = priv->cpu_np;
+	imx_phycore_dai_ac97[0].codec_of_node = priv->codec_np;
+
+	ret = snd_soc_register_card(&imx_phycore);
+	if (ret) {
+		dev_err(&pdev->dev, "ASoC: soc card registration failed\n");
+		of_node_put(priv->cpu_np);
+		of_node_put(priv->codec_np);
+		return ret;
+	}
+
+	dev_set_drvdata(&pdev->dev, priv);
+
+	return ret;
+}
+
+static int imx_phycore_ac97_remove(struct platform_device *pdev)
+{
+	struct phycore_ac97_data *priv = dev_get_drvdata(&pdev->dev);
+
+	snd_soc_unregister_card(&imx_phycore);
+
+	of_node_put(priv->cpu_np);
+	of_node_put(priv->codec_np);
+
+	return 0;
+}
+
+static struct platform_driver imx_phycore_ac97_driver = {
+	.probe		= imx_phycore_ac97_probe,
+	.remove		= imx_phycore_ac97_remove,
+	.driver		= {
+		.name	= DRV_NAME,
+		.owner	= THIS_MODULE,
+		.of_match_table = imx_phycore_ac97_of_dev_id,
+	},
+};
+
+module_platform_driver(imx_phycore_ac97_driver);
+
+MODULE_AUTHOR("Markus Pargmann <mpa at pengutronix.de>");
+MODULE_DESCRIPTION(DRV_NAME ": PhyCORE ALSA SoC DT driver");
+MODULE_LICENSE("GPL");
diff --git a/sound/soc/fsl/phycore-ac97.c b/sound/soc/fsl/phycore-ac97.c
index ae403c2..4126edc 100644
--- a/sound/soc/fsl/phycore-ac97.c
+++ b/sound/soc/fsl/phycore-ac97.c
@@ -52,18 +52,7 @@ static int __init imx_phycore_init(void)
 {
 	int ret;
 
-	if (machine_is_pca100()) {
-		imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0,
-			IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V1_PCR_TFCSEL(3) |
-			IMX_AUDMUX_V1_PCR_TCLKDIR | /* clock is output */
-			IMX_AUDMUX_V1_PCR_RXDSEL(3));
-		imx_audmux_v1_configure_port(3,
-			IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
-			IMX_AUDMUX_V1_PCR_TFCSEL(0) |
-			IMX_AUDMUX_V1_PCR_TFSDIR |
-			IMX_AUDMUX_V1_PCR_RXDSEL(0));
-	} else if (machine_is_pcm043()) {
+	if (machine_is_pcm043()) {
 		imx_audmux_v2_configure_port(3,
 			IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
 			IMX_AUDMUX_V2_PTCR_TFSEL(0) |
-- 
1.8.3.2



From broonie at kernel.org  Sat Jul 27 07:36:02 2013
From: broonie at kernel.org (Mark Brown)
Date: Sat, 27 Jul 2013 12:36:02 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130727085259.GA6207@netboy>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726045433.GB4100@netboy>
 <20130726171524.GB28895@obsidianresearch.com>
 <20130727085259.GA6207@netboy>
Message-ID: <20130727113602.GD9858@sirena.org.uk>

On Sat, Jul 27, 2013 at 10:53:01AM +0200, Richard Cochran wrote:
> On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote:

> > Why do you think our experiences are so different?

> Here are a few recent examples:

OK, let's go through these...

> * What happens when one wants to boot vanilla kernel on the beaglebone?

>   http://www.spinics.net/lists/arm-kernel/msg198431.html

This actually sounds pretty good - glancing over the thread it seems you
were trying to boot a shiny new board that people were in the process of
trying to upstream support for and were just a bit too early.  Device
tree doesn't seem to have made a difference either way here.

> * Wanting already merged code to work is too much to ask.

>   http://www.spinics.net/lists/linux-omap/msg79731.html

Paul's reply here seems fairly clear - someone had merged a driver which
had been developed in an out of tree or pre-DT environment without DT
support so they just hadn't added DT support.  Sadly doing that is new
feature development and so not appropriate for the stabalisation phase
of development.

> * When people try in good faith to conduct methodical boot tests,
>   DT is working against them.

>   http://www.spinics.net/lists/linux-omap/msg79960.html

Again I don't see anything particularly related to DT here but instead
do with using a SoC and board that are in the early phases of mainline
integration.

I think what you're seeing here is not to do with DT but rather with the
way most SoC vendors engage with mainline - typically they do their SoC
bringup out of tree and then if things do get submitted to mainline that
happens after the SoC is released.  In this respect things seem to have
been going relatively well here, there were clearly active efforts to
get things integrated and facilitate mainline use.

It'd be much better if SoC vendors were to change the way they engage
with the kernel so that support was already in mainline at about the
time the SoC was released but that's a bigger commercial discussion
which isn't really relevant to this one.
-------------- 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/20130727/e72bb460/attachment.sig>

From broonie at kernel.org  Sat Jul 27 07:50:22 2013
From: broonie at kernel.org (Mark Brown)
Date: Sat, 27 Jul 2013 12:50:22 +0100
Subject: [PATCH V2 2/8] ASoC: Samsung: I2S: Add quirks as driver data in
 I2S
In-Reply-To: <CAAgF-BerOfvhPJemVf0HBK5L4edw7pgm9bgwKGL+XSMpoaR3vw@mail.gmail.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-3-git-send-email-padma.v@samsung.com>
 <20130726145319.GI9858@sirena.org.uk>
 <CAAgF-BerOfvhPJemVf0HBK5L4edw7pgm9bgwKGL+XSMpoaR3vw@mail.gmail.com>
Message-ID: <20130727115022.GE9858@sirena.org.uk>

On Sat, Jul 27, 2013 at 06:38:02AM +0530, Padma Venkat wrote:
> On Fri, Jul 26, 2013 at 8:23 PM, Mark Brown <broonie at kernel.org> wrote:

> > As Russell indicated you should really keep the old name around, though
> > marking them as deprecated is OK.  However I'm not sure anyone will have
> > deployed this so I'm not sure how much it matters - every downstream
> > kernel I've seen was still using board files anyway.

> This is there only on exynos5250.dtsi, so changing this file alone is
> enough. patch3 in
> this series have the same.

The idea with DT is that you can bake the DT into a board firmware and
then upgrade the kernel without upgrading the DT.

> Having only the version info is confusing. When I posted my previous version of
> patches I was clear which version introduced in which platform and
> again if I come
> back today and see I again had to search each SoC datasheet. So I think this
> patch now clearly explains what new support introduced in which
> version of IP and which
> SoC platform.

Like I keep saying the problem we've always had is that there's never
been a 1:1 mapping between SoCs and IIS IPs, and of course nobody can
get the documentation on the older SoCs outside of Samsung so...  If it
were a linear march forward in terms of IP it'd be a lot easier :(
-------------- 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/20130727/ae143062/attachment.sig>

From tomasz.figa at gmail.com  Sat Jul 27 07:56:43 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 27 Jul 2013 13:56:43 +0200
Subject: [PATCH V2 2/8] ASoC: Samsung: I2S: Add quirks as driver data in
 I2S
In-Reply-To: <20130726152551.GM9858@sirena.org.uk>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1417636.4d7IlsSAyI@amdc1227> <20130726152551.GM9858@sirena.org.uk>
Message-ID: <2425397.IIfnern1kk@flatron>

On Friday 26 of July 2013 16:25:51 Mark Brown wrote:
> On Fri, Jul 26, 2013 at 05:02:46PM +0200, Tomasz Figa wrote:
> > IMHO this SoC-based identification looks much better, especially
> > considering the fact that IP version isn't something easily
> > determinable, as even the documentation can sometimes be not really
> > clear about that.
> 
> Yeah, it's not terribly clever either way.  We've been using the version
> numbers in audio for a long time partly because it is documented
> sometimes and partly because most of the SoCs tend to have one fully
> featured controller and a bunch of secondary controllers on older IP
> revisions.
> 
> > However the s3c6410-i2sv4 string looks a bit unfortunate. AFAIK there
> > were two types of I2S IPs on S3C6410 - normal I2S and I2S
> > multichannel. What about having a compatible like s3c6410-i2s-multi?
> 
> It was explicitly identified as I2Sv4 in the S3C6410 datasheet so no
> real issue there.

Well, the datasheet I have calls it either "I2S V40" or "IIS MULTI AUDIO 
INTERFACE". I like the latter much more, because it actually says what's 
the difference compared to previous I2S IPs.

I'm not strongly against using the v4 suffix, but since we decided to use 
more meaningful compatible values elsewhere, I think this way would be 
better for sound drivers as well.

Best regards,
Tomasz



From broonie at kernel.org  Sat Jul 27 07:59:50 2013
From: broonie at kernel.org (Mark Brown)
Date: Sat, 27 Jul 2013 12:59:50 +0100
Subject: [PATCH v10 2/7] ASoC: codec: wm9712 simple DT bindings
In-Reply-To: <1374924716-23475-3-git-send-email-mpa@pengutronix.de>
References: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
 <1374924716-23475-3-git-send-email-mpa@pengutronix.de>
Message-ID: <20130727115950.GF9858@sirena.org.uk>

On Sat, Jul 27, 2013 at 01:31:51PM +0200, Markus Pargmann wrote:

> +static const struct of_device_id wm9712_codec_of_dev_id[] = {
> +	{
> +		.compatible = "wlf,wm9712",
> +	}, {
> +		/* sentinel */
> +	}
> +};
> +
>  static struct platform_driver wm9712_codec_driver = {
>  	.driver = {
>  		.name = "wm9712-codec",
>  		.owner = THIS_MODULE,
> +		.of_match_table = wm9712_codec_of_dev_id,
>  	},
>  
>  	.probe = wm9712_probe,

AC'97 is an enumerable bus, we shouldn't need this...
-------------- 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/20130727/5c73c832/attachment-0001.sig>

From broonie at kernel.org  Sat Jul 27 08:05:22 2013
From: broonie at kernel.org (Mark Brown)
Date: Sat, 27 Jul 2013 13:05:22 +0100
Subject: [PATCH v10 1/7] ASoC: core: Generic ac97 link reset functions
In-Reply-To: <1374924716-23475-2-git-send-email-mpa@pengutronix.de>
References: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
 <1374924716-23475-2-git-send-email-mpa@pengutronix.de>
Message-ID: <20130727120522.GG9858@sirena.org.uk>

On Sat, Jul 27, 2013 at 01:31:50PM +0200, Markus Pargmann wrote:

This is a really nice approach to the problem, just one thing I'd like
to see changed in the bindings:

> +ssi {
> +	...
> +
> +	pinctrl-names = "default", "ac97-running", "ac97-reset", "ac97-warm-reset";

I'd like to see some documentation of this "default" state - I'd expect
this corresponds to the bus being idle and waiting for a wakeup from the
CODEC which is definitely a useful state to have for power optimisation
so it'd be good to bake it into the bindings.

Alternatively it could be the bus being totally idle with no possibility
of wakeup in which case it'd be good to say that too then someone can
add the waiting for wakeup state later.

Please also note the new list devicetree at vger.kernel.org.
-------------- 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/20130727/39a1016c/attachment.sig>

From will.deacon at arm.com  Sat Jul 27 08:22:21 2013
From: will.deacon at arm.com (Will Deacon)
Date: Sat, 27 Jul 2013 13:22:21 +0100
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com>
 <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com>
 <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
Message-ID: <20130727122221.GB6618@mudshark.cambridge.arm.com>

On Sat, Jul 27, 2013 at 05:10:56AM +0100, Paul Walmsley wrote:
> 
> Tonight I put on a Jon Hopkins album, in recollection of my UK ARM Linux 
> colleagues perhaps, and started testing, and eventually wound up with this 
> one:
> 
> commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc
> Author: Will Deacon <will.deacon at arm.com>

Oh, great...

> Date:   Wed Jun 12 12:25:56 2013 +0100
> 
>     ARM: 7757/1: mm: don't flush icache in switch_mm with hardware broadcasting
>     
>     When scheduling an mm on a CPU where it hasn't previously been used, we
>     flush the icache on that CPU so that any code loaded previously on
>     a different core can be safely executed.
>     
>     For cores with hardware broadcasting of cache maintenance operations,
>     this is clearly unnecessary, since the inner-shareable invalidation in
>     __sync_icache_dcache will affect all CPUs.
>     
>     This patch conditionalises the icache flush in switch_mm based on
>     cache_ops_need_broadcast().
>     
>     Acked-by: Catalin Marinas <catalin.marinas at arm.com>
>     Reported-by: Albin Tonnerre <albin.tonnerre at arm.com>
>     Signed-off-by: Will Deacon <will.deacon at arm.com>
>     Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
> 
> ...
> 
> v3.11-rc2 boots with it reverted.  What also works is v3.11-rc2 with the 
> below patch applied.

That's very odd -- I *suspect* your bootloader is up to no good (iirc, we've
had issues with the bootloader on this machine in the past, since it enters
the kernel in ABT mode or something).

> Would be pleased to boot-test anything you'd care to send my way, as long 
> as you can tolerate response latency jitter.

Can you try this quick hack please? It clobbers the I-cache as soon as we
enter the kernel, so it should tell us whether my theory is correct.

Cheers,

Will

--->8

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 9cf6063..d74c64c 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -83,6 +83,9 @@ ENTRY(stext)
  THUMB(        .thumb                  )       @ switch to Thumb now.
  THUMB(1:                      )
 
+       mov     r9, #0
+       mcr     p15, 0, r9, c7, c5, 0
+
 #ifdef CONFIG_ARM_VIRT_EXT
        bl      __hyp_stub_install
 #endif


From rjw at sisk.pl  Sat Jul 27 08:37:59 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Sat, 27 Jul 2013 14:37:59 +0200
Subject: [RESEND] cpuidle for ARM pull request
In-Reply-To: <51F3650B.8080708@linaro.org>
References: <51E536C5.1020609@linaro.org> <1598661.FpX5cmjM1U@vostro.rjw.lan>
 <51F3650B.8080708@linaro.org>
Message-ID: <2224191.VjCA0rsPcU@vostro.rjw.lan>

On Saturday, July 27, 2013 08:13:31 AM Daniel Lezcano wrote:
> On 07/26/2013 02:07 AM, Rafael J. Wysocki wrote:
> > On Friday, July 26, 2013 12:41:09 AM Rafael J. Wysocki wrote:
> >> On Friday, July 26, 2013 12:29:08 AM Rafael J. Wysocki wrote:
> >>> On Friday, July 26, 2013 12:07:03 AM Daniel Lezcano wrote:
> >>>> On 07/16/2013 02:04 PM, Daniel Lezcano wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> The first PR was against the linux-pm-next tree including the patch:
> >>>>>
> >>>>> "cpuidle: Add Kconfig.arm and move calxeda, kirkwood and zynq"
> >>>>>
> >>>>> This patch has been dropped in the meantime.
> >>>>>
> >>>>> Here is a new PR where my tree has been rebased against linux-pm-next
> >>>>> and adding the patch mentioned above.
> >>>>>
> >>>>> As stated by Rafael, I will handle the ARM specific patches from now.
> >>>>>
> >>>>> The following changes since commit 48f99d5a97d32d70c0738d6e314d9f4dbefd89bf:
> >>>>>
> >>>>>   Merge branch 'pm-cpuidle-next' into linux-next (2013-07-16 02:41:06 +0200)
> >>>>>
> >>>>> are available in the git repository at:
> >>>>>
> >>>>>
> >>>>>   git://git.linaro.org/people/dlezcano/linux.git cpuidle/arm-next
> >>>>>
> >>>>> for you to fetch changes up to 2b7e79f4a75e803184f483985a25cc751a990f06:
> >>>>>
> >>>>>   ARM: ux500: cpuidle: Move ux500 cpuidle driver to drivers/cpuidle
> >>>>> (2013-07-16 13:57:24 +0200)
> >>>>
> >>>> ping ?
> >>>
> >>> Sorry, something distracted me.  I'll pull it later today unless there are any
> >>> problems (in which case I'll let you know).
> >>
> >> Well, there are some.
> >>
> >> It is based on my linux-next branch, but please rebase it on top of 3.11-rc2.
> >>
> >> Generally, please send me pull requests based on -rc kernels only (or major
> >> releases).
> > 
> > Unless your material depends on new things in my linux-next branch, in which
> > case please let me know and I'll set up a stable branch for you to base things
> > on.
> 
> Hi Rafael,
> 
> I rebased my branch on top of 3.11-rc2, you can try to pull it again.

Pulled, thanks!

Next time, can you please add a general description of what the patches do and
why they do that to the pull request?

> I thought it would have been easier for us if I could based my PRs on
> top of your linux-next branch, so acting as a proxy for ARM patches. I
> am maintaining the clocksource drivers and I am basing my tree on top of
> tip/core.
> 
> I guess you are rebasing your tree often and this is an issue for you,
> right ?

Yes, my linux-next branch may contain commits that will be modified later
(e.g. ACKs added, fixes folded in etc.).

Anyway, as I said, as long as the material you have for me doesn't depend on
anything new in my tree, it's better to base it on top of an -rc kernel.

In case it does depend on that, I've put the entire outstanding cpuidle
material into my pm-cpuidle branch (including your ARM commits just pulled).

Thanks,
Rafael



From shc_work at mail.ru  Sat Jul 27 08:35:39 2013
From: shc_work at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFNoaXlhbg==?=)
Date: Sat, 27 Jul 2013 16:35:39 +0400
Subject: =?UTF-8?B?UmU6IFtQQVRDSF0gQVJNOiBpbXg6IHBsbHYxOiBGaXggUExMIGNhbGN1bGF0?=
 =?UTF-8?B?aW9uIGZvciBpLk1YMjc=?=
In-Reply-To: <1374896500-21862-1-git-send-email-shc_work@mail.ru>
References: <1374896500-21862-1-git-send-email-shc_work@mail.ru>
Message-ID: <1374928539.407887609@f303.i.mail.ru>

Incorrect. Please forget about this patch.

> MFN bit 9 on i.MX27 has a different meaning than in other SOCs. This
> is a just sign bit. This patch makes different calculation for i.MX27.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  arch/arm/mach-imx/clk-pllv1.c | 16 +++++++++++++---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/clk-pllv1.c b/arch/arm/mach-imx/clk-pllv1.c
> index c1eaee3..e76d601 100644
> --- a/arch/arm/mach-imx/clk-pllv1.c
> +++ b/arch/arm/mach-imx/clk-pllv1.c
> @@ -25,6 +25,11 @@ struct clk_pllv1 {
>  
>  #define to_clk_pllv1(clk) (container_of(clk, struct clk_pllv1, clk))
>  
> +static inline bool allow_signed_mfn(void)
> +{
> +	return !cpu_is_mx1() && !cpu_is_mx21();
> +}
> +
>  static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
>  		unsigned long parent_rate)
>  {
> @@ -59,9 +64,14 @@ static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
>  	/*
>  	 * On all i.MXs except i.MX1 and i.MX21 mfn is a 10bit
>  	 * 2's complements number
> +	 * On i.MX27 the bit 9 is the sign bit.
>  	 */
> -	if (!cpu_is_mx1() && !cpu_is_mx21() && mfn >= 0x200)
> -		mfn_abs = 0x400 - mfn;
> +	if (allow_signed_mfn() && (mfn & 0x200)) {
> +		if (cpu_is_mx27())
> +			mfn_abs = mfn & 0x200;
> +		else
> +			mfn_abs = 0x400 - mfn;
> +	}
>  
>  	rate = parent_rate * 2;
>  	rate /= pd + 1;
> @@ -70,7 +80,7 @@ static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
>  
>  	do_div(ll, mfd + 1);
>  
> -	if (!cpu_is_mx1() && !cpu_is_mx21() && mfn >= 0x200)
> +	if (allow_signed_mfn() && (mfn & 0x200))
>  		ll = -ll;
>  
>  	ll = (rate * mfi) + ll;
> -- 

---

From tomasz.figa at gmail.com  Sat Jul 27 08:41:05 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 27 Jul 2013 14:41:05 +0200
Subject: [PATCH v2 1/8] clk: mux: Add support for read-only muxes.
In-Reply-To: <1374536965-3545-2-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
 <1374536965-3545-2-git-send-email-tomasz.figa@gmail.com>
Message-ID: <1460068.oJXN9T0Uhp@flatron>

Hi Mike,

On Tuesday 23 of July 2013 01:49:18 Tomasz Figa wrote:
> Some platforms have read-only clock muxes that are preconfigured at
> reset and cannot be changed at runtime. This patch extends mux clock
> driver to allow handling such read-only muxes by adding new
> CLK_MUX_READ_ONLY mux flag.
> 
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> ---
>  drivers/clk/clk-mux.c        | 10 +++++++++-
>  include/linux/clk-provider.h |  2 ++
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
> index 614444c..92f1a1b 100644
> --- a/drivers/clk/clk-mux.c
> +++ b/drivers/clk/clk-mux.c
> @@ -107,6 +107,11 @@ const struct clk_ops clk_mux_ops = {
>  };
>  EXPORT_SYMBOL_GPL(clk_mux_ops);
> 
> +const struct clk_ops clk_mux_ro_ops = {
> +	.get_parent = clk_mux_get_parent,
> +};
> +EXPORT_SYMBOL_GPL(clk_mux_ro_ops);
> +
>  struct clk *clk_register_mux_table(struct device *dev, const char
> *name, const char **parent_names, u8 num_parents, unsigned long flags,
> void __iomem *reg, u8 shift, u32 mask,
> @@ -133,7 +138,10 @@ struct clk *clk_register_mux_table(struct device
> *dev, const char *name, }
> 
>  	init.name = name;
> -	init.ops = &clk_mux_ops;
> +	if (clk_mux_flags & CLK_MUX_READ_ONLY)
> +		init.ops = &clk_mux_ro_ops;
> +	else
> +		init.ops = &clk_mux_ops;
>  	init.flags = flags | CLK_IS_BASIC;
>  	init.parent_names = parent_names;
>  	init.num_parents = num_parents;
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 1ec14a7..9487b96 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -327,8 +327,10 @@ struct clk_mux {
>  #define CLK_MUX_INDEX_ONE		BIT(0)
>  #define CLK_MUX_INDEX_BIT		BIT(1)
>  #define CLK_MUX_HIWORD_MASK		BIT(2)
> +#define CLK_MUX_READ_ONLY	BIT(3) /* mux setting cannot be changed */
> 
>  extern const struct clk_ops clk_mux_ops;
> +extern const struct clk_ops clk_mux_ro_ops;
> 
>  struct clk *clk_register_mux(struct device *dev, const char *name,
>  		const char **parent_names, u8 num_parents, unsigned long 
flags,

What do you think about this?

Best regards,
Tomasz



From sachin.kamat at linaro.org  Sat Jul 27 09:29:56 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Sat, 27 Jul 2013 18:59:56 +0530
Subject: [PATCH 1/3] clk: exynos5250: Add G2D gate clock
In-Reply-To: <20130726201800.7598.54329@quantum>
References: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
 <20130726201800.7598.54329@quantum>
Message-ID: <CAK9yfHw6KtVDAns-1JhNpiS0brTeUpfiHS-v3q7H2GLWkY-Adw@mail.gmail.com>

On 27 July 2013 01:48, Mike Turquette <mturquette at linaro.org> wrote:
> Quoting Sachin Kamat (2013-07-05 01:42:27)
>> Adds gate clock for G2D IP for Exynos5250 SoC.
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
>> Cc: Mike Turquette <mturquette at linaro.org>
>
> I've taken patch #1 into clk-next.

Thanks Mike.

>
>> ---
>> This patch depends on the following patch:
>> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20581
>
> I think I've gotten all three series you sent out, can you confirm?

I haven't seen any update in your tree [1] since quite some time. The
last commit I see in clk-next branch is 45e3ec3784 ("clk: tegra: fix
ifdef for tegra_periph_reset_assert inline"). I hope I am looking at
the right tree?

[1] git://git.linaro.org/people/mturquette/linux.git

-- 
With warm regards,
Sachin


From mpa at pengutronix.de  Sat Jul 27 09:44:52 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 27 Jul 2013 15:44:52 +0200
Subject: [PATCH v10 2/7] ASoC: codec: wm9712 simple DT bindings
In-Reply-To: <20130727115950.GF9858@sirena.org.uk>
References: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
 <1374924716-23475-3-git-send-email-mpa@pengutronix.de>
 <20130727115950.GF9858@sirena.org.uk>
Message-ID: <20130727134452.GF16871@s25.your-server.de>

On Sat, Jul 27, 2013 at 12:59:50PM +0100, Mark Brown wrote:
> On Sat, Jul 27, 2013 at 01:31:51PM +0200, Markus Pargmann wrote:
> 
> > +static const struct of_device_id wm9712_codec_of_dev_id[] = {
> > +	{
> > +		.compatible = "wlf,wm9712",
> > +	}, {
> > +		/* sentinel */
> > +	}
> > +};
> > +
> >  static struct platform_driver wm9712_codec_driver = {
> >  	.driver = {
> >  		.name = "wm9712-codec",
> >  		.owner = THIS_MODULE,
> > +		.of_match_table = wm9712_codec_of_dev_id,
> >  	},
> >  
> >  	.probe = wm9712_probe,
> 
> AC'97 is an enumerable bus, we shouldn't need this...

What do you mean exactly? Is there a way to automaticaly discover
connected codecs and register them?

Regards,

Markus


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From robherring2 at gmail.com  Sat Jul 27 09:54:47 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Sat, 27 Jul 2013 08:54:47 -0500
Subject: [PATCH v8 06/12] ARM: dts: Add description of System MMU of
 Exynos SoCs
In-Reply-To: <003c01ce89f3$3abc4bc0$b034e340$@samsung.com>
References: <003c01ce89f3$3abc4bc0$b034e340$@samsung.com>
Message-ID: <CAL_JsqJdh5F0rK3koAW7DvRVU3RwS5pLgR5sV_Bak+K-6CrRFA@mail.gmail.com>

On Fri, Jul 26, 2013 at 6:28 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> ---
>  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++++++
>  arch/arm/boot/dts/exynos4.dtsi                     |  122 ++++++++
>  arch/arm/boot/dts/exynos4210.dtsi                  |   25 ++
>  arch/arm/boot/dts/exynos4x12.dtsi                  |   76 +++++
>  arch/arm/boot/dts/exynos5250.dtsi                  |  291 ++++++++++++++++++++
>  5 files changed, 617 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
>
> diff --git a/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> new file mode 100644
> index 0000000..92f0a33
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> @@ -0,0 +1,103 @@
> +Samsung Exynos4210 IOMMU H/W, System MMU (System Memory Management Unit)
> +
> +Samsung's Exynos architecture contains System MMU that enables scattered
> +physical memory chunks visible as a contiguous region to DMA-capable peripheral
> +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
> +
> +System MMU is a sort of IOMMU and support identical translation table format to
> +ARMv7 translation tables with minimum set of page properties including access
> +permissions, shareability and security protection. In addition, System MMU has
> +another capabilities like L2 TLB or block-fetch buffers to minimize translation
> +latency.
> +
> +A System MMU is dedicated to a single master peripheral device.  Thus, it is
> +important to specify the correct System MMU in the device node of its master
> +device. Whereas a System MMU is dedicated to a master device, the master device
> +may have more than one System MMU.

I don't follow the last sentence. Can you elaborate on the type of
connection you are talking about.

Also, please align with the ARM system MMU binding that Will Deacon
has submitted particularly in terms of how master connections are
described.

Rob

> +
> +Required properties:
> +- compatible: Should be "samsung,exynos4210-sysmmu"
> +- reg: A tuple of base address and size of System MMU registers.
> +- interrupt-parent: The phandle of the interrupt controller of System MMU
> +- interrupts: A tuple of numbers that indicates the interrupt source.
> +- clock-names: Should be "sysmmu" if the System MMU is needed to gate its clock.
> +               Please refer to the following documents:
> +              Documentation/devicetree/bindings/clock/clock-bindings.txt
> +              Documentation/devicetree/bindings/clock/exynos4-clock.txt
> +              Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +              Optional "master" if the clock to the System MMU is gated by
> +              another gate clock other than "sysmmu". The System MMU driver
> +              sets "master" the parent of "sysmmu".
> +              Exynos4 SoCs, there needs no "master" clocks.
> +              Exynos5 SoCs, some System MMUs must have "master" clocks.
> +- clocks: Required if the System MMU is needed to gate its clock.
> +         Please refer to the documents listed above.
> +- samsung,power-domain: Required if the System MMU is needed to gate its power.
> +         Please refer to the following document:
> +         Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> +
> +Required properties for the master peripheral devices:
> +- iommu: phandles to the System MMUs of the device
> +
> +Examples:
> +A System MMU is dedicated to a single master device.
> +       gsc_0:  gsc at 0x13e00000 {
> +               compatible = "samsung,exynos5-gsc";
> +               reg = <0x13e00000 0x1000>;
> +               interrupts = <0 85 0>;
> +               samsung,power-domain = <&pd_gsc>;
> +               clocks = <&clock 256>;
> +               clock-names = "gscl";
> +               iommu = <&sysmmu_gsc1>;
> +       };
> +
> +       sysmmu_gsc0: sysmmu at 13E80000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13E80000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-gsc0";
> +               interrupts = <2 0>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 262>, <&clock 256>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +MFC has 2 System MMUs for each port that MFC is attached. Thus it seems natural
> +to define 2 System MMUs for each port of the MFC:
> +
> +       mfc: codec at 13400000 {
> +               compatible = "samsung,mfc-v5";
> +               reg = <0x13400000 0x10000>;
> +               interrupts = <0 94 0>;
> +               samsung,power-domain = <&pd_mfc>;
> +               clocks = <&clock 170>, <&clock 273>;
> +               clock-names = "sclk_mfc", "mfc";
> +               status = "ok";
> +               iommu = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>;
> +       };
> +
> +       sysmmu_mfc_l: sysmmu at 13620000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13620000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-mfc-l";
> +               interrupts = <5 5>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 274>;
> +               samsung,power-domain = <&pd_mfc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_mfc_r: sysmmu at 13630000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13630000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-mfc-r";
> +               interrupts = <5 6>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 275>;
> +               samsung,power-domain = <&pd_mfc>;
> +               status = "ok";
> +       };
> +
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index 359694c..ba74ee8 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -161,6 +161,7 @@
>                 interrupts = <0 94 0>;
>                 samsung,power-domain = <&pd_mfc>;
>                 status = "disabled";
> +               iommu = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>;
>         };
>
>         serial at 13800000 {
> @@ -395,5 +396,126 @@
>                 clock-names = "sclk_fimd", "fimd";
>                 samsung,power-domain = <&pd_lcd0>;
>                 status = "disabled";
> +               iommu = <&sysmmu_fimd0>;
> +       };
> +
> +       sysmmu_mfc_l: sysmmu at 13620000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13620000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-mfc-l";
> +               interrupts = <5 5>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 274>;
> +               samsung,power-domain = <&pd_mfc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_mfc_r: sysmmu at 13630000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13630000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-mfc-r";
> +               interrupts = <5 6>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 275>;
> +               samsung,power-domain = <&pd_mfc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_tv: sysmmu at 13E20000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13E20000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-tv";
> +               interrupts = <5 4>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 272>;
> +               samsung,power-domain = <&pd_tv>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc0: sysmmu at 11A20000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11A20000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc0";
> +               interrupts = <4 2>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 263>;
> +               samsung,power-domain = <&pd_cam>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc1: sysmmu at 11A30000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11A30000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc1";
> +               interrupts = <4 3>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 264>;
> +               samsung,power-domain = <&pd_cam>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc2: sysmmu at 11A40000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11A40000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc2";
> +               interrupts = <4 4>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 265>;
> +               samsung,power-domain = <&pd_cam>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc3: sysmmu at 11A50000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11A50000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc3";
> +               interrupts = <4 5>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 266>;
> +               samsung,power-domain = <&pd_cam>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_jpeg: sysmmu at 11A60000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11A60000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-jpeg";
> +               interrupts = <4 6>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 267>;
> +               samsung,power-domain = <&pd_cam>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_rotator: sysmmu at 12A30000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x12A30000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-rotator";
> +               interrupts = <5 0>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 281>;
> +               samsung,power-domain = <&pd_lcd0>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimd0: sysmmu at 11E20000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11E20000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimd0";
> +               interrupts = <5 2>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 287>;
> +               samsung,power-domain = <&pd_lcd0>;
> +               status = "ok";
>         };
>  };
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
> index 54710de..09b13da 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -119,5 +119,30 @@
>                 reg = <0x12800000 0x1000>;
>                 interrupts = <0 89 0>;
>                 status = "disabled";
> +               iommu = <&sysmmu_g2d>;
> +       };
> +
> +       sysmmu_g2d: sysmmu at 12A20000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x12A20000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-g2d";
> +               interrupts = <4 7>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 280>;
> +               samsung,power-domain = <&pd_lcd0>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimd1: sysmmu at 12220000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimd1";
> +               reg = <0x12220000 0x1000>;
> +               interrupts = <5 3>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 291>;
> +               samsung,power-domain = <&pd_lcd1>;
> +               status = "ok";
>         };
>  };
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
> index e3380a7..681db32 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -79,4 +79,80 @@
>                 interrupts = <0 89 0>;
>                 status = "disabled";
>         };
> +
> +       sysmmu_g2d: sysmmu at 10A40000{
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x10A40000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-g2d";
> +               interrupts = <4 7>;
> +               clock-names = "sysmmu";
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_isp: sysmmu at 12260000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x12260000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_isp";
> +               interrupts = <16 2>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 362>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_drc: sysmmu at 12270000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x12270000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_drc";
> +               interrupts = <16 3>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 363>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_fd: sysmmu at 122A0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x122A0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_fd";
> +               interrupts = <16 4>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 364>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_mcuctl: sysmmu at 122B0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x122B0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_mcuctl";
> +               interrupts = <16 5>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 376>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_lite0: sysmmu at 123B0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x123B0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_lite0";
> +               interrupts = <16 0>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 366>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_lite1: sysmmu at 123C0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x123C0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_lite1";
> +               interrupts = <16 1>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 365>;
> +               status = "ok";
> +       };
>  };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> index fc9fb3d..130d23d 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -66,6 +66,16 @@
>                 reg = <0x10044040 0x20>;
>         };
>
> +       pd_isp: mfc-power-domain at 0x10044020 {
> +               compatible = "samsung,exynos4210-pd";
> +               reg = <0x10044020 0x20>;
> +       };
> +
> +       pd_disp1: mfc-power-domain at 0x100440A0 {
> +               compatible = "samsung,exynos4210-pd";
> +               reg = <0x100440A0 0x20>;
> +       };
> +
>         clock: clock-controller at 0x10010000 {
>                 compatible = "samsung,exynos5250-clock";
>                 reg = <0x10010000 0x30000>;
> @@ -180,6 +190,7 @@
>                 reg = <0x11000000 0x10000>;
>                 interrupts = <0 96 0>;
>                 samsung,power-domain = <&pd_mfc>;
> +               iommu = <&sysmmu_mfc_l &sysmmu_mfc_l>;
>         };
>
>         rtc {
> @@ -571,6 +582,7 @@
>                 samsung,power-domain = <&pd_gsc>;
>                 clocks = <&clock 256>;
>                 clock-names = "gscl";
> +               iommu = <&sysmmu_gsc1>;
>         };
>
>         gsc_1:  gsc at 0x13e10000 {
> @@ -580,6 +592,7 @@
>                 samsung,power-domain = <&pd_gsc>;
>                 clocks = <&clock 257>;
>                 clock-names = "gscl";
> +               iommu = <&sysmmu_gsc1>;
>         };
>
>         gsc_2:  gsc at 0x13e20000 {
> @@ -589,6 +602,7 @@
>                 samsung,power-domain = <&pd_gsc>;
>                 clocks = <&clock 258>;
>                 clock-names = "gscl";
> +               iommu = <&sysmmu_gsc2>;
>         };
>
>         gsc_3:  gsc at 0x13e30000 {
> @@ -598,6 +612,7 @@
>                 samsung,power-domain = <&pd_gsc>;
>                 clocks = <&clock 259>;
>                 clock-names = "gscl";
> +               iommu = <&sysmmu_gsc3>;
>         };
>
>         hdmi {
> @@ -614,6 +629,7 @@
>                 compatible = "samsung,exynos5-mixer";
>                 reg = <0x14450000 0x10000>;
>                 interrupts = <0 94 0>;
> +               iommu = <&sysmmu_tv>;
>         };
>
>         dp-controller {
> @@ -638,5 +654,280 @@
>                 interrupts = <18 4>, <18 5>, <18 6>;
>                 clocks = <&clock 133>, <&clock 339>;
>                 clock-names = "sclk_fimd", "fimd";
> +               iommu = <&sysmmu_fimd1>;
> +       };
> +
> +       sysmmu_mfc_l: sysmmu at 11210000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11210000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-mfc_l";
> +               interrupts = <8 5>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 267>, <&clock 266>;
> +               samsung,power-domain = <&pd_mfc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_mfc_r: sysmmu at 11200000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11200000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-mfc_r";
> +               interrupts = <6 2>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 268>, <&clock 266>;
> +               samsung,power-domain = <&pd_mfc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_tv: sysmmu at 14650000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x14650000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-tv";
> +               interrupts = <7 4>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 349>;
> +               samsung,power-domain = <&pd_disp1>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_gsc0: sysmmu at 13E80000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13E80000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-gsc0";
> +               interrupts = <2 0>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 262>, <&clock 256>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_gsc1: sysmmu at 13E90000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13E90000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-gsc1";
> +               interrupts = <2 2>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 263>, <&clock 257>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_gsc2: sysmmu at 13EA0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13EA0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-gsc2";
> +               interrupts = <2 4>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 264>, <&clock 258>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_gsc3: sysmmu at 13EB0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13EB0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-gsc3";
> +               interrupts = <2 6>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 265>, <&clock 259>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimd1: sysmmu at 14640000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x14640000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimd1";
> +               interrupts = <3 2>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 350>;
> +               samsung,power-domain = <&pd_disp1>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_rotator: sysmmu at 11D40000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11D40000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-rotator";
> +               interrupts = <4 0>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 272>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_isp: sysmmu at 13260000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13260000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_isp";
> +               interrupts = <10 6>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 361>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_drc: sysmmu at 13270000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13270000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_drc";
> +               interrupts = <11 6>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 362>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_fd: sysmmu at 132A0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x132A0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_fd";
> +               interrupts = <5 0>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 363>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_scc: sysmmu at 13280000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13280000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_scalerc";
> +               interrupts = <5 2>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 364>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_scp: sysmmu at 13290000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13290000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_scalerp";
> +               interrupts = <3 6>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 365>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_mcuctl: sysmmu at 132B0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x132B0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_mcuctl";
> +               interrupts = <5 4>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 366>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_odc: sysmmu at 132C0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x132C0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_odc";
> +               interrupts = <11 0>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 367>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_dis0: sysmmu at 132D0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x132D0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_dis0";
> +               interrupts = <10 4>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 368>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_dis1: sysmmu at 132E0000{
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x132E0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_dis1";
> +               interrupts = <9 4>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 369>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_3dnr: sysmmu at 132F0000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x132F0000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_3dnr";
> +               interrupts = <5 6>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 370>;
> +               samsung,power-domain = <&pd_isp>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_lite0: sysmmu at 13C40000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13C40000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_lite0";
> +               interrupts = <3 4>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 346>, <&clock 345>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_lite1: sysmmu at 13C50000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x13C50000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-fimc_lite1";
> +               interrupts = <24 1>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 347>, <&clock 345>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_jpeg: sysmmu at 11F20000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x11F20000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-jpeg";
> +               interrupts = <4 2>;
> +               clock-names = "sysmmu", "master";
> +               clocks = <&clock 273>, <&clock 270>;
> +               samsung,power-domain = <&pd_gsc>;
> +               status = "ok";
> +       };
> +
> +       sysmmu_fimc_2d: sysmmu at 10A60000 {
> +               compatible = "samsung,exynos4210-sysmmu";
> +               reg = <0x10A60000 0x1000>;
> +               interrupt-parent = <&combiner>;
> +               interrupt-names = "sysmmu-2d";
> +               interrupts = <24 5>;
> +               clock-names = "sysmmu";
> +               clocks = <&clock 361>;
> +               status = "ok";
>         };
>  };
> --
> 1.7.2.5
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From mpa at pengutronix.de  Sat Jul 27 09:55:58 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 27 Jul 2013 15:55:58 +0200
Subject: [PATCH v10 1/7] ASoC: core: Generic ac97 link reset functions
In-Reply-To: <20130727120522.GG9858@sirena.org.uk>
References: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
 <1374924716-23475-2-git-send-email-mpa@pengutronix.de>
 <20130727120522.GG9858@sirena.org.uk>
Message-ID: <20130727135558.GG16871@s25.your-server.de>

On Sat, Jul 27, 2013 at 01:05:22PM +0100, Mark Brown wrote:
> On Sat, Jul 27, 2013 at 01:31:50PM +0200, Markus Pargmann wrote:
> 
> This is a really nice approach to the problem, just one thing I'd like
> to see changed in the bindings:
> 
> > +ssi {
> > +	...
> > +
> > +	pinctrl-names = "default", "ac97-running", "ac97-reset", "ac97-warm-reset";
> 
> I'd like to see some documentation of this "default" state - I'd expect
> this corresponds to the bus being idle and waiting for a wakeup from the
> CODEC which is definitely a useful state to have for power optimisation
> so it'd be good to bake it into the bindings.
> 
> Alternatively it could be the bus being totally idle with no possibility
> of wakeup in which case it'd be good to say that too then someone can
> add the waiting for wakeup state later.

The "default" state is actually just the default pin state that is set
before the driver is probed. I will remove it from the example. I didn't
add a low power state although it might be usefull and is defined by the
standard.

> 
> Please also note the new list devicetree at vger.kernel.org.

Yes thanks.

Regards,

Markus



-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From zonque at gmail.com  Sat Jul 27 10:02:37 2013
From: zonque at gmail.com (Daniel Mack)
Date: Sat, 27 Jul 2013 16:02:37 +0200
Subject: [PATCH 1/5] gpio: pxa: remove dead code
In-Reply-To: <CAD6h2NRBsRZkeZnQfko0inQ=QKurqibNSq_ZnuipU5MtZW3h=Q@mail.gmail.com>
References: <1373555877-29887-1-git-send-email-zonque@gmail.com>
 <1373555877-29887-2-git-send-email-zonque@gmail.com>
 <CACRpkdaB7JnWzoLKpQ1eLWAi7yFz9CanhbhwtiCnEtcNWzX3RQ@mail.gmail.com>
 <CAD6h2NS0p-kMUGyhbr93vd_oLSNyaB572riFB8mHt1cu5f-bGw@mail.gmail.com>
 <51F0E92E.6060900@gmail.com>
 <CACRpkdZT51uwW6z-BzmU2tv9-fX=UQN2ywCQwb-SDVHovo4BxA@mail.gmail.com>
 <CAD6h2NRBsRZkeZnQfko0inQ=QKurqibNSq_ZnuipU5MtZW3h=Q@mail.gmail.com>
Message-ID: <625bf823-036c-4d95-93e5-c44edcd1c70f@email.android.com>

Haojian Zhuang <haojian.zhuang at linaro.org> wrote:
>On 25 July 2013 17:30, Linus Walleij <linus.walleij at linaro.org> wrote:
>
>> On Thu, Jul 25, 2013 at 11:00 AM, Daniel Mack <zonque at gmail.com>
>wrote:
>>
>> > And what about the others? I think the first 3 patches of this
>series
>> > can go through Linus W, and the other 2 should end up in the pxa
>tree,
>> > right?
>>
>> Yes. They might need to build on top of the pinctrl tree.
>>
>> Or, if there are no other things happening in the PXA tree for the
>> next merge window, I can take it into my tree, with the ACKs of
>> e.g. Eric and Olof Johansson.
>>
>> Yours,
>> Linus Walleij
>>
>
>It's OK to merge all patches into gpio git tree.

No, wait. I have some more patches coming soon, and they will cause conflicts then in the merge window. So please take the last two ones into the pxa repo, and only the gpio specific one through Linus W.


Thanks,
Daniel

>Acked-by: Haojian Zhuang <haojian.zhuang at linaro.org>




From tomasz.figa at gmail.com  Sat Jul 27 10:06:40 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 27 Jul 2013 16:06:40 +0200
Subject: [PATCH v8 07/12] iommu/exynos: support for device tree
In-Reply-To: <003d01ce89f3$44ec2cf0$cec486d0$@samsung.com>
References: <003d01ce89f3$44ec2cf0$cec486d0$@samsung.com>
Message-ID: <1743111.Ek7FldnHal@flatron>

Hi,

On Friday 26 of July 2013 20:28:36 Cho KyongHo wrote:
> This commit adds device tree support for System MMU.
> This also include the following changes and enhancements:
> 
> * use managed device helper functions.
> Simplyfies System MMU device driver.
> 
> * use only a single clock descriptor.
> System MMU device descriptor is seperate if it is imposible to make
> a single clock descriptor to make a device descriptor for a group of
> System MMUs.
> 
> * removed dbgname member from sysmmu_drvdata structure.
> debugging kernel message for a System MMU is distinguisheable with the
> name of device descroptors.
> 
> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> ---
>  drivers/iommu/Kconfig        |    5 +-
>  drivers/iommu/exynos-iommu.c |  182
> ++++++++++++++++-------------------------- 2 files changed, 70
> insertions(+), 117 deletions(-)

Whenever you introduce or modify (extend) a device tree binding please 
don't forget about reflecting that in documentation 
(Documentation/devicetree/bindings) and CCing devicetree mailing list 
(devicetree at vger.kernel.org). Both of these steps are necessary to get any 
device tree stuff merged.

Best regards,
Tomasz



From broonie at kernel.org  Sat Jul 27 10:21:21 2013
From: broonie at kernel.org (Mark Brown)
Date: Sat, 27 Jul 2013 15:21:21 +0100
Subject: [PATCH v10 2/7] ASoC: codec: wm9712 simple DT bindings
In-Reply-To: <20130727134452.GF16871@s25.your-server.de>
References: <1374924716-23475-1-git-send-email-mpa@pengutronix.de>
 <1374924716-23475-3-git-send-email-mpa@pengutronix.de>
 <20130727115950.GF9858@sirena.org.uk>
 <20130727134452.GF16871@s25.your-server.de>
Message-ID: <20130727142121.GI9858@sirena.org.uk>

On Sat, Jul 27, 2013 at 03:44:52PM +0200, Markus Pargmann wrote:
> On Sat, Jul 27, 2013 at 12:59:50PM +0100, Mark Brown wrote:

> > AC'97 is an enumerable bus, we shouldn't need this...

> What do you mean exactly? Is there a way to automaticaly discover
> connected codecs and register them?

Yes, of coure - just read the ID registers.  Look at how the non-ASoC
AC'97 code works.
-------------- 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/20130727/e7bfe6d5/attachment.sig>

From arnd at arndb.de  Fri Jul 26 12:10:31 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 26 Jul 2013 18:10:31 +0200
Subject: [PATCH v6 05/11] irqchip: mmp: avoid to include irqs head file
In-Reply-To: <1374833133-21119-6-git-send-email-haojian.zhuang@gmail.com>
References: <1374833133-21119-1-git-send-email-haojian.zhuang@gmail.com>
 <1374833133-21119-6-git-send-email-haojian.zhuang@gmail.com>
Message-ID: <201307261810.32069.arnd@arndb.de>

On Friday 26 July 2013, Haojian Zhuang wrote:
> Since <mach/irqs.h> in irq-mmp.c blocks the multiplatform build,
> remove it instead.
> 
> Signed-off-by: Haojian Zhuang <haojian.zhuang at gmail.com>
> ---
>  drivers/irqchip/irq-mmp.c | 45 +++++++++++++++++++++------------------------
>  1 file changed, 21 insertions(+), 24 deletions(-)

The intention behind this patch is good, but I think the implementation is
bad, since the platform still relies on specific hardcoded values for
the base irq numbers. As long as this is the case, you should use the
constants.

> @@ -249,7 +247,7 @@ void __init icu_init_irq(void)
>  /* MMP2 (ARMv7) */
>  void __init mmp2_init_icu(void)
>  {
> -	int irq;
> +	int irq, end;
>  
>  	max_icu_nr = 8;
>  	mmp_icu_base = ioremap(0xd4282000, 0x1000);
> @@ -263,11 +261,12 @@ void __init (void)
>  						   &icu_data[0]);
>  	icu_data[1].reg_status = mmp_icu_base + 0x150;
>  	icu_data[1].reg_mask = mmp_icu_base + 0x168;
> -	icu_data[1].clr_mfp_irq_base = IRQ_MMP2_PMIC_BASE;
> -	icu_data[1].clr_mfp_hwirq = IRQ_MMP2_PMIC - IRQ_MMP2_PMIC_BASE;
> +	icu_data[1].clr_mfp_irq_base = icu_data[0].virq_base +
> +				icu_data[0].nr_irqs;
> +	icu_data[1].clr_mfp_hwirq = 1;		/* offset to IRQ_MMP2_PMIC_BASE */
>  	icu_data[1].nr_irqs = 2;
>  	icu_data[1].cascade_irq = 4;
> -	icu_data[1].virq_base = IRQ_MMP2_PMIC_BASE;
> +	icu_data[1].virq_base = icu_data[0].virq_base + icu_data[0].nr_irqs;
>  	icu_data[1].domain = irq_domain_add_legacy(NULL, icu_data[1].nr_irqs,
>  						   icu_data[1].virq_base, 0,
>  						   &irq_domain_simple_ops,


I'd suggest passing IRQ_MMP2_PMIC_BASE and the other constants from the caller
and changing the prototype accordingly so you can do

	mmp2_init_icu(0, IRQ_MMP2_PMIC_BASE, IRQ_MMP2_RTC_BASE, IRQ_MMP2_KEYPAD_BASE,
			 IRQ_MMP2_TWSI_BASE, IRQ_MMP2_MISC_BASE, IRQ_MMP2_MIPI_HSI1_BASE,
			 IRQ_MMP2_MIPI_HSI0_BASE);

	Arnd



From arnd at arndb.de  Fri Jul 26 12:18:58 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 26 Jul 2013 18:18:58 +0200
Subject: Location for a kind of GPIO bus driver
In-Reply-To: <20130726085623.GM9916@kw.sim.vm.gnt>
References: <20130723151834.GJ9916@kw.sim.vm.gnt>
 <20130725160324.GJ23879@titan.lakedaemon.net>
 <20130726085623.GM9916@kw.sim.vm.gnt>
Message-ID: <201307261818.59002.arnd@arndb.de>

On Friday 26 July 2013, Simon Guinot wrote:
> On Thu, Jul 25, 2013 at 12:03:24PM -0400, Jason Cooper wrote:
> > On Thu, Jul 25, 2013 at 05:49:32PM +0200, Simon Guinot wrote:

> > > > I would try drivers/gpio.  If there are complaints, it should be trivial
> > > > to move it in a new version of the series.
> > > 
> > > Why not, as long it is clear that the resulting driver will not provide
> > > a GPIO chip but rather functions as a library.
> > 
> > right, but the end result of what the library would do is expose a
> > series of LEDs and PM 'virtual gpios'.  So, even though it's not a gpio
> > expander per-se, it's still filling that role.  Or am I still missing
> > something?
> 
> The library could expose a function allowing to set the address and data
> registers: gpio_ext_set_value(int addr, int value).
> 
> Actually, it is how it works inside leds-netxbig. Simply this function
> would be also accessible by other drivers.

With that prototype it still sounds like a regular gpiochip driver would
fit that role well, since the function you describe is just like
gpio_set_value().

Maybe you can post the driver to let others understand what you are
trying to do if it's not just a gpio expander.

	Arnd


From arnd at arndb.de  Sat Jul 27 10:38:16 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 27 Jul 2013 16:38:16 +0200
Subject: [PATCH v2 1/5] ARM: Broadcom: Unconditionally build
 arch/arm/mach-bcm
In-Reply-To: <20130726234237.GB24642@n2100.arm.linux.org.uk>
References: <20130726145639.116237136@gmail.com>
 <20130726231108.GA10812@obsidianresearch.com>
 <20130726234237.GB24642@n2100.arm.linux.org.uk>
Message-ID: <201307271638.16289.arnd@arndb.de>

On Saturday 27 July 2013, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 05:11:08PM -0600, Jason Gunthorpe wrote:
> > On Fri, Jul 26, 2013 at 11:59:00PM +0200, Domenico Andreoli wrote:
>
> Anyway, there's a simpler solutions to this:
> 
> machdirs := $(patsubst %,arch/arm/mach-%/,$(sort $(machine-y)))
> platdirs := $(patsubst %,arch/arm/plat-%/,$(Sort $(plat-y)))
> 
> which will remove all duplicates.

This does sound like the easiest solution, although I still think
Olof's suggestion of making ARCH_BCM a silent Kconfig symbol would be
just as good if we just have this one instance.

	Arnd


From mpa at pengutronix.de  Sat Jul 27 11:26:40 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sat, 27 Jul 2013 17:26:40 +0200
Subject: [RFC 0/8] ARM: imx27 pinctrl
Message-ID: <1374938808-27316-1-git-send-email-mpa@pengutronix.de>

Hi,

this series implements a imx27 pinctrl driver. imx27/21 have a register format
that is not compatible with the rest of imx series processors. I added some
functions to support it within the core imx pinctrl driver.

The gpio data registers are between iomux control registers. In this series,
the gpio devices are initialized as subdevices of the iomux device, sharing the
mapped registers.

Regards,

Markus


Markus Pargmann (8):
      gpio: mxc: Use devm_ functions
      gpio: mxc: Support for initialization as submodule
      pinctrl: imx: Move private struct to header file
      pinctrl: imx: Support imx21 register format
      pinctrl: imx27: imx27 pincontrol driver
      ARM: imx27: enable pinctrl
      ARM: dts: imx27 pin functions
      ARM: dts: imx27 pinctrl

 .../bindings/pinctrl/fsl,imx27-pinctrl.txt         |  53 ++
 arch/arm/boot/dts/imx27-pinfunc.h                  | 520 +++++++++++++++++++
 arch/arm/boot/dts/imx27.dtsi                       | 217 +++++---
 arch/arm/mach-imx/Kconfig                          |   2 +
 drivers/gpio/gpio-mxc.c                            |  51 +-
 drivers/pinctrl/Kconfig                            |   8 +
 drivers/pinctrl/Makefile                           |   1 +
 drivers/pinctrl/pinctrl-imx.c                      | 272 +++++++++-
 drivers/pinctrl/pinctrl-imx.h                      |  12 +
 drivers/pinctrl/pinctrl-imx27.c                    | 553 +++++++++++++++++++++
 include/linux/gpio-mxc.h                           |  17 +
 11 files changed, 1597 insertions(+), 109 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx27-pinctrl.txt
 create mode 100644 arch/arm/boot/dts/imx27-pinfunc.h
 create mode 100644 drivers/pinctrl/pinctrl-imx27.c
 create mode 100644 include/linux/gpio-mxc.h




From david at gibson.dropbear.id.au  Sat Jul 27 11:19:49 2013
From: david at gibson.dropbear.id.au (David Gibson)
Date: Sun, 28 Jul 2013 01:19:49 +1000
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726142140.GR24642@n2100.arm.linux.org.uk>
References: <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726132709.GH29916@titan.lakedaemon.net>
 <1374846070.14574.92.camel@i7.infradead.org>
 <CAKON4OzrkHzUzKkULWCgiEpAtJ5gLxUm78R5ctd7p6trqq_gCA@mail.gmail.com>
 <20130726142140.GR24642@n2100.arm.linux.org.uk>
Message-ID: <20130727151949.GA29970@voom.fritz.box>

On Fri, Jul 26, 2013 at 03:21:40PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 10:14:32AM -0400, jonsmirl at gmail.com wrote:
> > Yes, yes - that's why the schema should be written down and used as a
> > validation input to dtc. Then dtc can spit out errors for non-standard
> > items. There would be two versions - the standard one and a legacy one
> > that includes the standard one plus the hacks that can't be undone.
> > 
> > But more importantly it provides a framework for people creating new
> > node definitions. Now they can't work in a vacuum and come up with
> > random names and structure for everything.
> > 
> > Most of the problems express in the thread would go away if the schema
> > was written down and discussed. The rule going forward would be no new
> > nodes that aren't part of the standard schema.
> 
> So this is why I'm seeing patches just a short time ago removing existing
> compatible strings from the DT descriptions and associated driver, and
> replacing them with new ones... meaning that the old DT files won't work
> with newer kernels.
> 
> What that means is using the descriptions as the schema won't catch that
> because they're changing those as well to match.
> 
> There's a solution to that: dtc becomes a separate project external to
> the kernel which also contains the schemas that it verifies against.

dtc has always been a separate project external to the kernel.  Though
we do have to keep reminding people to send their patches to upstream
first.

It's had minimal support for validation of the tree contents for a
long time.  It has no more than minimal support (including "schemas"
as such for bindings), simply because no-one's implemented it yet.

> That way, if you want to make changes such as that above, you need to
> get it past not only kernel people but also past dtc maintainers -
> which increases the chances of such stuff being caught.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130728/d749095c/attachment.sig>

From david at gibson.dropbear.id.au  Sat Jul 27 11:28:46 2013
From: david at gibson.dropbear.id.au (David Gibson)
Date: Sun, 28 Jul 2013 01:28:46 +1000
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726131423.GL24642@n2100.arm.linux.org.uk>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726131423.GL24642@n2100.arm.linux.org.uk>
Message-ID: <20130727152845.GB29970@voom.fritz.box>

On Fri, Jul 26, 2013 at 02:14:23PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
> > On Fri, Jul 26, 2013 at 10:42:24AM +0100, David Woodhouse wrote:
> > > On Fri, 2013-07-26 at 10:01 +0200, Richard Cochran wrote:
> > > > On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
> > > > > 
> > > > > We use DT has a kernel configuration input. Our environment is
> > > > > designed to guarantee 100% that the kernel and DT match exactly. DT
> > > > > very deliberately isn't an ABI boundary in our systems.
> > > > 
> > > > Think about what you just said.
> > > > 
> > > > The DT describes the *hardware* not the kernel. Why should you ever
> > > > need to update your DT at all?
> > > 
> > > Well, the nodes which describe hardware devices, according to the
> > > bindings which form an ABI contract between DT and drivers, should not
> > > normally change. Although they *can* change, if for example you change
> > > the MAC address and that's stored there. Or you change the PHY you want
> > > it to use. Or something like that. The *ABI* doesn't change, but the
> > > data you express *using* that ABI can change. That's kind of the point.
> > 
> > Unless I totally misunderstood, the thread is talking about letting
> > established bindings change with each new kernel version.  I am
> > opposed to that.
> > 
> > Of course, a user may want to change the values of his MAC addresses,
> > if he needs to. But he should never have to change *how* he specifies
> > those addresses.
> > 
> > So, as long as everyone can agree to the principle that a working DT
> > should remain working after a kernel upgrade, then I'll shut up. In
> > actual fact, this is not the case today, nor was it ever so in the
> > past, AFAICT, but it never hurts to set goals.
> 
> We agree.
> 
> That's precisely why I'm saying that once a binding appears in a -final
> released kernel, it is _stable_ by that very fact.  If there were any
> doubts about it, it should never have been accepted into the kernel tree
> in the first place.
> 
> It's no different from how we treat syscalls.  Once we accept a syscall
> and it's published in a -final kernel, it can't then be altered - it can
> be supplemented by a new syscall with a different interface, but the old
> one remains and keeps its semantics for a great many years.
> 
> There's no reason for DT to be any different in this regard.

I agree, and the fact that we have a bunch of bad bindings in the wild
is a mess which is difficult but necessary to clean up.

Something that helps, is that just as it's possible to support old,
badly-thought out syscalls with a compat shim over newer
implementations, we can in many cases localize handling of bad device
tree bindings to early boot code, so that old bad ideas don't have to
infect every part of every driver.

It would probably be a good idea to implement a DT quirks mechanism,
to be run immediately after unflattening.  That way a driver can just
register a fixup function to patch the DT up to a newer standard,
instead of scattering if (old-style-representation) throughout the
code.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130728/54e30f87/attachment.sig>

From marvin24 at gmx.de  Sat Jul 27 12:12:10 2013
From: marvin24 at gmx.de (Marc Dietrich)
Date: Sat, 27 Jul 2013 18:12:10 +0200
Subject: [PATCH 0/8] ARM: tegra: support LP1 suspend mode
In-Reply-To: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
Message-ID: <2389689.JgQlW00RdN@ax5200p>

On Friday 26 July 2013 17:15:02 Joseph Lo wrote:
> This series adds the support of LP1 suspend mode for Tegra.
> 
> Verified on Seaboard, Cardhu and Dalmore.

tested on AC100 and worked fine, except

[   68.448007] PM: Syncing filesystems ... done.
[   71.370086] Freezing user space processes ... (elapsed 0.001 seconds) done.
[   71.370088] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[   71.371253] Suspending console(s) (use no_console_suspend to debug)
[   71.638481] PM: suspend of devices complete after 266.604 msecs
[   71.638905] PM: late suspend of devices complete after 0.417 msecs
[   71.639477] PM: noirq suspend of devices complete after 0.568 msecs
[   71.639480] Disabling non-boot CPUs ...
[   71.640242] CPU1: shutdown
[   71.641216] Entering suspend state LP1
[   71.641267] Enabling non-boot CPUs ...
[   71.643125] CPU1: Booted secondary processor
[   71.643449] CPU1 is up
[   71.643786] PM: noirq resume of devices complete after 0.331 msecs
[   71.644300] PM: early resume of devices complete after 0.364 msecs
[   71.648038] ------------[ cut here ]------------
[   71.648061] WARNING: CPU: 0 PID: 1025 at kernel/irq/manage.c:529 
irq_set_irq_wake+0xb8/0xf0()
[   71.648064] Unbalanced IRQ 384 wake disable
[   71.648068] Modules linked in:
[   71.648075] CPU: 0 PID: 1025 Comm: bash Not tainted 3.11.0-rc2-
next-20130726-00008-gef01509-dirty #6
[   71.648107] [<c001551c>] (unwind_backtrace+0x0/0xf8) from [<c001154c>] 
(show_stack+0x10/0x14)
[   71.648128] [<c001154c>] (show_stack+0x10/0x14) from [<c0515288>] 
(dump_stack+0x80/0xc4)
[   71.648142] [<c0515288>] (dump_stack+0x80/0xc4) from [<c0025340>] 
(warn_slowpath_common+0x64/0x88)
[   71.648151] [<c0025340>] (warn_slowpath_common+0x64/0x88) from [<c00253f8>] 
(warn_slowpath_fmt+0x30/0x40)
[   71.648161] [<c00253f8>] (warn_slowpath_fmt+0x30/0x40) from [<c007ff8c>] 
(irq_set_irq_wake+0xb8/0xf0)
[   71.648178] [<c007ff8c>] (irq_set_irq_wake+0xb8/0xf0) from [<c0334d00>] 
(tps6586x_rtc_resume+0x30/0x38)
[   71.648192] [<c0334d00>] (tps6586x_rtc_resume+0x30/0x38) from [<c02951d0>] 
(platform_pm_resume+0x2c/0x4c)
[   71.648202] [<c02951d0>] (platform_pm_resume+0x2c/0x4c) from [<c0299d40>] 
(dpm_run_callback.isra.5+0x18/0x38)
[   71.648211] [<c0299d40>] (dpm_run_callback.isra.5+0x18/0x38) from 
[<c029a044>] (device_resume+0xb0/0x170)
[   71.648219] [<c029a044>] (device_resume+0xb0/0x170) from [<c029aeb4>] 
(dpm_resume+0xe8/0x20c)
[   71.648227] [<c029aeb4>] (dpm_resume+0xe8/0x20c) from [<c029b174>] 
(dpm_resume_end+0xc/0x18)
[   71.648245] [<c029b174>] (dpm_resume_end+0xc/0x18) from [<c005e480>] 
(suspend_devices_and_enter+0xdc/0x2f8)
[   71.648256] [<c005e480>] (suspend_devices_and_enter+0xdc/0x2f8) from 
[<c005e810>] (pm_suspend+0x174/0x1e8)
[   71.648265] [<c005e810>] (pm_suspend+0x174/0x1e8) from [<c005d710>] 
(state_store+0x6c/0xbc)
[   71.648285] [<c005d710>] (state_store+0x6c/0xbc) from [<c01eca78>] 
(kobj_attr_store+0x14/0x20)
[   71.648298] [<c01eca78>] (kobj_attr_store+0x14/0x20) from [<c011e970>] 
(sysfs_write_file+0x168/0x198)
[   71.648312] [<c011e970>] (sysfs_write_file+0x168/0x198) from [<c00cd060>] 
(vfs_write+0xb0/0x188)
[   71.648321] [<c00cd060>] (vfs_write+0xb0/0x188) from [<c00cd410>] 
(SyS_write+0x3c/0x70)
[   71.648330] [<c00cd410>] (SyS_write+0x3c/0x70) from [<c000e560>] 
(ret_fast_syscall+0x0/0x30)
[   71.648334] ---[ end trace e5ed8212ac4db5da ]---
[   72.063578] mmc1: power class selection to bus width 8 failed
[   72.297753] usb 2-1: reset high-speed USB device number 2 using tegra-ehci
[   72.567736] usb 3-1: reset high-speed USB device number 2 using tegra-ehci
[   73.022058] usb 3-1.3: reset high-speed USB device number 4 using tegra-
ehci
[   73.216064] usb 3-1.2: reset high-speed USB device number 3 using tegra-
ehci
[   73.360225] PM: resume of devices complete after 1715.937 msecs
[   73.361008] Restarting tasks ... done.

and sdcard being offline after resume (fixed by CONFIG_MMC_UNSAFE_RESUME=y). 
Anyway, thanks for your great work!

Tested-By: Marc Dietrich <marvin24 at gmx.de>

> And tested with THUMB2_KERNEL as well.
> 
> P.S.
> A known issue on Dalmore, the LP1 resume may take 10 ~ 15 seconds due to
> the 792MHz BCT. It can't be reproduced on Seaboard or Cardhu. And the
> root cause of this is about the default settings of EMC registers that
> cause the DRAM can't leave self-refresh mode immediately. If you want
> to test with quick LP1 resume on Dalmore, I can provide another HACK for
> this.
> 
> Joseph Lo (8):
>   ARM: tegra: add common resume handling code for LP1 resuming
>   ARM: tegra: config the polarity of the request of sys clock
>   clk: tegra114: add LP1 suspend/resume support
>   ARM: tegra: add common LP1 suspend support
>   ARM: tegra30: add LP1 suspend support
>   ARM: tegra20: add LP1 suspend support
>   ARM: tegra114: add LP1 suspend support
>   ARM: dts: tegra: enable LP1 suspend mode
> 
>  arch/arm/boot/dts/tegra114-dalmore.dts     |   2 +-
>  arch/arm/boot/dts/tegra20-colibri-512.dtsi |   2 +-
>  arch/arm/boot/dts/tegra20-harmony.dts      |   2 +-
>  arch/arm/boot/dts/tegra20-paz00.dts        |   2 +-
>  arch/arm/boot/dts/tegra20-seaboard.dts     |   2 +-
>  arch/arm/boot/dts/tegra20-tamonten.dtsi    |   2 +-
>  arch/arm/boot/dts/tegra20-trimslice.dts    |   2 +-
>  arch/arm/boot/dts/tegra20-ventana.dts      |   2 +-
>  arch/arm/boot/dts/tegra20-whistler.dts     |   2 +-
>  arch/arm/boot/dts/tegra30-beaver.dts       |   2 +-
>  arch/arm/boot/dts/tegra30-cardhu.dtsi      |   2 +-
>  arch/arm/mach-tegra/Makefile               |   3 +
>  arch/arm/mach-tegra/iomap.h                |   6 +
>  arch/arm/mach-tegra/pm-tegra20.c           |  37 ++
>  arch/arm/mach-tegra/pm-tegra30.c           |  37 ++
>  arch/arm/mach-tegra/pm.c                   | 121 +++++-
>  arch/arm/mach-tegra/pm.h                   |  23 ++
>  arch/arm/mach-tegra/pmc.c                  |  36 +-
>  arch/arm/mach-tegra/pmc.h                  |   3 +
>  arch/arm/mach-tegra/reset-handler.S        |  13 +
>  arch/arm/mach-tegra/reset.c                |   2 +
>  arch/arm/mach-tegra/reset.h                |   4 +
>  arch/arm/mach-tegra/sleep-tegra20.S        | 300 ++++++++++++++
>  arch/arm/mach-tegra/sleep-tegra30.S        | 615
> +++++++++++++++++++++++++++++ arch/arm/mach-tegra/sleep.S                | 
>  8 +-
>  arch/arm/mach-tegra/sleep.h                |  18 +
>  drivers/clk/tegra/clk-tegra114.c           |  32 ++
>  27 files changed, 1259 insertions(+), 21 deletions(-)
>  create mode 100644 arch/arm/mach-tegra/pm-tegra20.c
>  create mode 100644 arch/arm/mach-tegra/pm-tegra30.c


From digetx at gmail.com  Sat Jul 27 12:20:38 2013
From: digetx at gmail.com (Dmitry Osipenko)
Date: Sat, 27 Jul 2013 20:20:38 +0400
Subject: [PATCH 0/8] ARM: tegra: support LP1 suspend mode
In-Reply-To: <2389689.JgQlW00RdN@ax5200p>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
 <2389689.JgQlW00RdN@ax5200p>
Message-ID: <51F3F356.8080709@gmail.com>

27.07.2013 20:12, Marc Dietrich ?????:
> On Friday 26 July 2013 17:15:02 Joseph Lo wrote:
>> This series adds the support of LP1 suspend mode for Tegra.
>>
>> Verified on Seaboard, Cardhu and Dalmore.
> 
> tested on AC100 and worked fine, except
> 
> [   68.448007] PM: Syncing filesystems ... done.
> [   71.370086] Freezing user space processes ... (elapsed 0.001 seconds) done.
> [   71.370088] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
> done.
> [   71.371253] Suspending console(s) (use no_console_suspend to debug)
> [   71.638481] PM: suspend of devices complete after 266.604 msecs
> [   71.638905] PM: late suspend of devices complete after 0.417 msecs
> [   71.639477] PM: noirq suspend of devices complete after 0.568 msecs
> [   71.639480] Disabling non-boot CPUs ...
> [   71.640242] CPU1: shutdown
> [   71.641216] Entering suspend state LP1
> [   71.641267] Enabling non-boot CPUs ...
> [   71.643125] CPU1: Booted secondary processor
> [   71.643449] CPU1 is up
> [   71.643786] PM: noirq resume of devices complete after 0.331 msecs
> [   71.644300] PM: early resume of devices complete after 0.364 msecs
> [   71.648038] ------------[ cut here ]------------
> [   71.648061] WARNING: CPU: 0 PID: 1025 at kernel/irq/manage.c:529 
> irq_set_irq_wake+0xb8/0xf0()
> [   71.648064] Unbalanced IRQ 384 wake disable
> [   71.648068] Modules linked in:
> [   71.648075] CPU: 0 PID: 1025 Comm: bash Not tainted 3.11.0-rc2-
> next-20130726-00008-gef01509-dirty #6
> [   71.648107] [<c001551c>] (unwind_backtrace+0x0/0xf8) from [<c001154c>] 
> (show_stack+0x10/0x14)
> [   71.648128] [<c001154c>] (show_stack+0x10/0x14) from [<c0515288>] 
> (dump_stack+0x80/0xc4)
> [   71.648142] [<c0515288>] (dump_stack+0x80/0xc4) from [<c0025340>] 
> (warn_slowpath_common+0x64/0x88)
> [   71.648151] [<c0025340>] (warn_slowpath_common+0x64/0x88) from [<c00253f8>] 
> (warn_slowpath_fmt+0x30/0x40)
> [   71.648161] [<c00253f8>] (warn_slowpath_fmt+0x30/0x40) from [<c007ff8c>] 
> (irq_set_irq_wake+0xb8/0xf0)
> [   71.648178] [<c007ff8c>] (irq_set_irq_wake+0xb8/0xf0) from [<c0334d00>] 
> (tps6586x_rtc_resume+0x30/0x38)
> [   71.648192] [<c0334d00>] (tps6586x_rtc_resume+0x30/0x38) from [<c02951d0>] 
> (platform_pm_resume+0x2c/0x4c)
> [   71.648202] [<c02951d0>] (platform_pm_resume+0x2c/0x4c) from [<c0299d40>] 
> (dpm_run_callback.isra.5+0x18/0x38)
> [   71.648211] [<c0299d40>] (dpm_run_callback.isra.5+0x18/0x38) from 
> [<c029a044>] (device_resume+0xb0/0x170)
> [   71.648219] [<c029a044>] (device_resume+0xb0/0x170) from [<c029aeb4>] 
> (dpm_resume+0xe8/0x20c)
> [   71.648227] [<c029aeb4>] (dpm_resume+0xe8/0x20c) from [<c029b174>] 
> (dpm_resume_end+0xc/0x18)
> [   71.648245] [<c029b174>] (dpm_resume_end+0xc/0x18) from [<c005e480>] 
> (suspend_devices_and_enter+0xdc/0x2f8)
> [   71.648256] [<c005e480>] (suspend_devices_and_enter+0xdc/0x2f8) from 
> [<c005e810>] (pm_suspend+0x174/0x1e8)
> [   71.648265] [<c005e810>] (pm_suspend+0x174/0x1e8) from [<c005d710>] 
> (state_store+0x6c/0xbc)
> [   71.648285] [<c005d710>] (state_store+0x6c/0xbc) from [<c01eca78>] 
> (kobj_attr_store+0x14/0x20)
> [   71.648298] [<c01eca78>] (kobj_attr_store+0x14/0x20) from [<c011e970>] 
> (sysfs_write_file+0x168/0x198)
> [   71.648312] [<c011e970>] (sysfs_write_file+0x168/0x198) from [<c00cd060>] 
> (vfs_write+0xb0/0x188)
> [   71.648321] [<c00cd060>] (vfs_write+0xb0/0x188) from [<c00cd410>] 
> (SyS_write+0x3c/0x70)
> [   71.648330] [<c00cd410>] (SyS_write+0x3c/0x70) from [<c000e560>] 
> (ret_fast_syscall+0x0/0x30)
> [   71.648334] ---[ end trace e5ed8212ac4db5da ]---
> [   72.063578] mmc1: power class selection to bus width 8 failed
> [   72.297753] usb 2-1: reset high-speed USB device number 2 using tegra-ehci
> [   72.567736] usb 3-1: reset high-speed USB device number 2 using tegra-ehci
> [   73.022058] usb 3-1.3: reset high-speed USB device number 4 using tegra-
> ehci
> [   73.216064] usb 3-1.2: reset high-speed USB device number 3 using tegra-
> ehci
> [   73.360225] PM: resume of devices complete after 1715.937 msecs
> [   73.361008] Restarting tasks ... done.
> 
> and sdcard being offline after resume (fixed by CONFIG_MMC_UNSAFE_RESUME=y). 
> Anyway, thanks for your great work!
> 
> Tested-By: Marc Dietrich <marvin24 at gmx.de>
> 
>> And tested with THUMB2_KERNEL as well.
>>
>> P.S.
>> A known issue on Dalmore, the LP1 resume may take 10 ~ 15 seconds due to
>> the 792MHz BCT. It can't be reproduced on Seaboard or Cardhu. And the
>> root cause of this is about the default settings of EMC registers that
>> cause the DRAM can't leave self-refresh mode immediately. If you want
>> to test with quick LP1 resume on Dalmore, I can provide another HACK for
>> this.
>>
>> Joseph Lo (8):
>>   ARM: tegra: add common resume handling code for LP1 resuming
>>   ARM: tegra: config the polarity of the request of sys clock
>>   clk: tegra114: add LP1 suspend/resume support
>>   ARM: tegra: add common LP1 suspend support
>>   ARM: tegra30: add LP1 suspend support
>>   ARM: tegra20: add LP1 suspend support
>>   ARM: tegra114: add LP1 suspend support
>>   ARM: dts: tegra: enable LP1 suspend mode
>>
>>  arch/arm/boot/dts/tegra114-dalmore.dts     |   2 +-
>>  arch/arm/boot/dts/tegra20-colibri-512.dtsi |   2 +-
>>  arch/arm/boot/dts/tegra20-harmony.dts      |   2 +-
>>  arch/arm/boot/dts/tegra20-paz00.dts        |   2 +-
>>  arch/arm/boot/dts/tegra20-seaboard.dts     |   2 +-
>>  arch/arm/boot/dts/tegra20-tamonten.dtsi    |   2 +-
>>  arch/arm/boot/dts/tegra20-trimslice.dts    |   2 +-
>>  arch/arm/boot/dts/tegra20-ventana.dts      |   2 +-
>>  arch/arm/boot/dts/tegra20-whistler.dts     |   2 +-
>>  arch/arm/boot/dts/tegra30-beaver.dts       |   2 +-
>>  arch/arm/boot/dts/tegra30-cardhu.dtsi      |   2 +-
>>  arch/arm/mach-tegra/Makefile               |   3 +
>>  arch/arm/mach-tegra/iomap.h                |   6 +
>>  arch/arm/mach-tegra/pm-tegra20.c           |  37 ++
>>  arch/arm/mach-tegra/pm-tegra30.c           |  37 ++
>>  arch/arm/mach-tegra/pm.c                   | 121 +++++-
>>  arch/arm/mach-tegra/pm.h                   |  23 ++
>>  arch/arm/mach-tegra/pmc.c                  |  36 +-
>>  arch/arm/mach-tegra/pmc.h                  |   3 +
>>  arch/arm/mach-tegra/reset-handler.S        |  13 +
>>  arch/arm/mach-tegra/reset.c                |   2 +
>>  arch/arm/mach-tegra/reset.h                |   4 +
>>  arch/arm/mach-tegra/sleep-tegra20.S        | 300 ++++++++++++++
>>  arch/arm/mach-tegra/sleep-tegra30.S        | 615
>> +++++++++++++++++++++++++++++ arch/arm/mach-tegra/sleep.S                | 
>>  8 +-
>>  arch/arm/mach-tegra/sleep.h                |  18 +
>>  drivers/clk/tegra/clk-tegra114.c           |  32 ++
>>  27 files changed, 1259 insertions(+), 21 deletions(-)
>>  create mode 100644 arch/arm/mach-tegra/pm-tegra20.c
>>  create mode 100644 arch/arm/mach-tegra/pm-tegra30.c
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
I had same warn on 3.8.
https://bitbucket.org/digetx/picasso-kernel/commits/a86dc95ab48dd77eaa0463844cdf88a5acf9d842


From richardcochran at gmail.com  Sat Jul 27 13:37:48 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Sat, 27 Jul 2013 19:37:48 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130727104018.GC9858@sirena.org.uk>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726045433.GB4100@netboy>
 <20130726171524.GB28895@obsidianresearch.com>
 <20130727084825.GA4707@netboy>
 <20130727104018.GC9858@sirena.org.uk>
Message-ID: <20130727173748.GA4813@netboy>

On Sat, Jul 27, 2013 at 11:40:18AM +0100, Mark Brown wrote:
> On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote:
> 
> > [ I disagree about the "more thought" part. The current discussion,
> >   coming years too late after the introduction of DT to ARM Linux, is
> >   contrary evidence enough. ]
> 
> We did have exactly the same discussion when the DT transition was
> started - this isn't something that people only just realised might be
> an issue.  There was a deliberate decision to focus on getting the
> technology deployed to the point where it could be used as a straight
> replacement for board files and accept that sometimes the results won't
> be perfect and that we may need to rework as a result.

Can you tell a bit more about this decision? When was it made? Who
made it? How was it made public?

Thanks,
Richard


From ben.dooks at codethink.co.uk  Sat Jul 27 13:38:16 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Sat, 27 Jul 2013 18:38:16 +0100
Subject: [PATCH v11] reset: Add driver for gpio-controlled reset pins
In-Reply-To: <51F2EA59.8010908@gmail.com>
References: <1374834384-8071-1-git-send-email-p.zabel@pengutronix.de>
 <51F2E4A7.1040200@codethink.co.uk> <51F2EA59.8010908@gmail.com>
Message-ID: <51F40588.9020907@codethink.co.uk>

On 26/07/13 22:30, Sylwester Nawrocki wrote:
> On 07/26/2013 11:05 PM, Ben Dooks wrote:
>> On 26/07/13 11:26, Philipp Zabel wrote:
>>> This driver implements a reset controller device that toggle a gpio
>>> connected to a reset pin of a peripheral IC. The delay between assertion
>>> and de-assertion of the reset signal can be configured via device tree.
>>>
>>> Signed-off-by: Philipp Zabel<p.zabel at pengutronix.de>
>>> Reviewed-by: Stephen Warren<swarren at nvidia.com>
>>
>> [snip]
>>
>>> +static struct of_device_id gpio_reset_dt_ids[] = {
>>> + { .compatible = "gpio-reset" },
>>> + { }
>>> +};
>>
>> I think you need the following:
>> MODULE_DEVICE_TABLE(of, gpio_reset_dt_ids);
>
> It's already there, at bottom of the file. But if I'm not mistaken
> the common practice is to keep it together with the actual array
> definition. At least that's the case with, e.g. EXPORT_SYMBOL*.
>
>>> +static struct platform_driver gpio_reset_driver = {
>>> + .probe = gpio_reset_probe,
>>> + .remove = gpio_reset_remove,
>>> + .driver = {
>>> + .name = "gpio-reset",
>>> + .owner = THIS_MODULE,
>>> + .of_match_table = of_match_ptr(gpio_reset_dt_ids),
>>> + },
>>> +};
>>> +
>>> +module_platform_driver(gpio_reset_driver);
>>> +
>>> +MODULE_AUTHOR("Philipp Zabel<p.zabel at pengutronix.de>");
>>> +MODULE_DESCRIPTION("gpio reset controller");
>
> nit: shouldn't gpio be capitalized ?
>
>>> +MODULE_LICENSE("GPL");
>>> +MODULE_ALIAS("platform:gpio-reset");
>>> +MODULE_DEVICE_TABLE(of, gpio_reset_dt_ids);
>
> --
> Regards,
> Sylwester

ta, that's why I missed it. Nice if it stays with the table it
references.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From david at lang.hm  Sat Jul 27 13:57:09 2013
From: david at lang.hm (David Lang)
Date: Sat, 27 Jul 2013 10:57:09 -0700 (PDT)
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130727173748.GA4813@netboy>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com> <20130726045433.GB4100@netboy>
 <20130726171524.GB28895@obsidianresearch.com> <20130727084825.GA4707@netboy>
 <20130727104018.GC9858@sirena.org.uk> <20130727173748.GA4813@netboy>
Message-ID: <alpine.DEB.2.02.1307271056060.13167@nftneq.ynat.uz>

On Sat, 27 Jul 2013, Richard Cochran wrote:

> On Sat, Jul 27, 2013 at 11:40:18AM +0100, Mark Brown wrote:
>> On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote:
>>
>>> [ I disagree about the "more thought" part. The current discussion,
>>>   coming years too late after the introduction of DT to ARM Linux, is
>>>   contrary evidence enough. ]
>>
>> We did have exactly the same discussion when the DT transition was
>> started - this isn't something that people only just realised might be
>> an issue.  There was a deliberate decision to focus on getting the
>> technology deployed to the point where it could be used as a straight
>> replacement for board files and accept that sometimes the results won't
>> be perfect and that we may need to rework as a result.
>
> Can you tell a bit more about this decision? When was it made? Who
> made it? How was it made public?

I remember seeing some of the discussion on linux-kernel at the time. I believe 
there was also a LWN article.

David Lang


From richardcochran at gmail.com  Sat Jul 27 14:07:54 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Sat, 27 Jul 2013 20:07:54 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130727113602.GD9858@sirena.org.uk>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726045433.GB4100@netboy>
 <20130726171524.GB28895@obsidianresearch.com>
 <20130727085259.GA6207@netboy>
 <20130727113602.GD9858@sirena.org.uk>
Message-ID: <20130727180752.GB4813@netboy>

On Sat, Jul 27, 2013 at 12:36:02PM +0100, Mark Brown wrote:
> On Sat, Jul 27, 2013 at 10:53:01AM +0200, Richard Cochran wrote:
> > On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote:
> 
> > > Why do you think our experiences are so different?
> 
> > Here are a few recent examples:
> 
> OK, let's go through these...

Yes, lets, and remember the question was, why do I say that dealing
with DT is such a PITA.
 
> > * What happens when one wants to boot vanilla kernel on the beaglebone?
> 
> >   http://www.spinics.net/lists/arm-kernel/msg198431.html
> 
> This actually sounds pretty good - glancing over the thread it seems you
> were trying to boot a shiny new board that people were in the process of
> trying to upstream support for and were just a bit too early.  Device
> tree doesn't seem to have made a difference either way here.

Did you miss the part about CONFIG_ARM_APPENDED_DTB?

> > * Wanting already merged code to work is too much to ask.
> 
> >   http://www.spinics.net/lists/linux-omap/msg79731.html
> 
> Paul's reply here seems fairly clear - someone had merged a driver which
> had been developed in an out of tree or pre-DT environment without DT
> support so they just hadn't added DT support.  Sadly doing that is new
> feature development and so not appropriate for the stabalisation phase
> of development.

This is me asking for maintainers to take patches to fix a driver in
version v3.7 where the driver merged in v3.4. 

The patches contain the missing DT part, and the maintainer rejects
them, saying, no new features!

Q: What the heck kind of process is that?
A: DT process.

Seriously, why is it too hard for y'all to insist on merging drivers
only when they are really, truly ready (and don't forget the DT part,
please).

> > * When people try in good faith to conduct methodical boot tests,
> >   DT is working against them.
> 
> >   http://www.spinics.net/lists/linux-omap/msg79960.html
> 
> Again I don't see anything particularly related to DT here but instead
> do with using a SoC and board that are in the early phases of mainline
> integration.

It is ring around the rosie, DT, boot loader, and kernel.

Understandably, Paul doesn't want to upgrade his boot loader. He says
he is "not interested" in testing the boot loader, just the kernel.
And, if you follow the sage of Paul's test reports, you will find him
being told to update his boot loader and not to forget the delete old
dtb files.

So, like I said, it is a pity PITA.

Thanks,
Richard




From marvin24 at gmx.de  Sat Jul 27 14:09:19 2013
From: marvin24 at gmx.de (Marc Dietrich)
Date: Sat, 27 Jul 2013 20:09:19 +0200
Subject: [PATCH 0/8] ARM: tegra: support LP1 suspend mode
In-Reply-To: <51F3F356.8080709@gmail.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
 <2389689.JgQlW00RdN@ax5200p> <51F3F356.8080709@gmail.com>
Message-ID: <4555938.6N2HxzJnNO@ax5200p>

On Saturday 27 July 2013 20:20:38 Dmitry Osipenko wrote:
> 27.07.2013 20:12, Marc Dietrich ?????:
> > On Friday 26 July 2013 17:15:02 Joseph Lo wrote:
> >> This series adds the support of LP1 suspend mode for Tegra.
> >> 
> >> Verified on Seaboard, Cardhu and Dalmore.
> > 
> > tested on AC100 and worked fine, except
> > 
> > [   68.448007] PM: Syncing filesystems ... done.
> > [   71.370086] Freezing user space processes ... (elapsed 0.001 seconds)
> > done. [   71.370088] Freezing remaining freezable tasks ... (elapsed
> > 0.001 seconds) done.
> > [   71.371253] Suspending console(s) (use no_console_suspend to debug)
> > [   71.638481] PM: suspend of devices complete after 266.604 msecs
> > [   71.638905] PM: late suspend of devices complete after 0.417 msecs
> > [   71.639477] PM: noirq suspend of devices complete after 0.568 msecs
> > [   71.639480] Disabling non-boot CPUs ...
> > [   71.640242] CPU1: shutdown
> > [   71.641216] Entering suspend state LP1
> > [   71.641267] Enabling non-boot CPUs ...
> > [   71.643125] CPU1: Booted secondary processor
> > [   71.643449] CPU1 is up
> > [   71.643786] PM: noirq resume of devices complete after 0.331 msecs
> > [   71.644300] PM: early resume of devices complete after 0.364 msecs
> > [   71.648038] ------------[ cut here ]------------
> > [   71.648061] WARNING: CPU: 0 PID: 1025 at kernel/irq/manage.c:529
> > irq_set_irq_wake+0xb8/0xf0()
> > [   71.648064] Unbalanced IRQ 384 wake disable
> > [   71.648068] Modules linked in:
> > [   71.648075] CPU: 0 PID: 1025 Comm: bash Not tainted 3.11.0-rc2-
> > next-20130726-00008-gef01509-dirty #6
> > [   71.648107] [<c001551c>] (unwind_backtrace+0x0/0xf8) from [<c001154c>]
> > (show_stack+0x10/0x14)
> > [   71.648128] [<c001154c>] (show_stack+0x10/0x14) from [<c0515288>]
> > (dump_stack+0x80/0xc4)
> > [   71.648142] [<c0515288>] (dump_stack+0x80/0xc4) from [<c0025340>]
> > (warn_slowpath_common+0x64/0x88)
> > [   71.648151] [<c0025340>] (warn_slowpath_common+0x64/0x88) from
> > [<c00253f8>] (warn_slowpath_fmt+0x30/0x40)
> > [   71.648161] [<c00253f8>] (warn_slowpath_fmt+0x30/0x40) from
> > [<c007ff8c>]
> > (irq_set_irq_wake+0xb8/0xf0)
> > [   71.648178] [<c007ff8c>] (irq_set_irq_wake+0xb8/0xf0) from [<c0334d00>]
> > (tps6586x_rtc_resume+0x30/0x38)
> > [   71.648192] [<c0334d00>] (tps6586x_rtc_resume+0x30/0x38) from
> > [<c02951d0>] (platform_pm_resume+0x2c/0x4c)
> > [   71.648202] [<c02951d0>] (platform_pm_resume+0x2c/0x4c) from
> > [<c0299d40>] (dpm_run_callback.isra.5+0x18/0x38)
> > [   71.648211] [<c0299d40>] (dpm_run_callback.isra.5+0x18/0x38) from
> > [<c029a044>] (device_resume+0xb0/0x170)
> > [   71.648219] [<c029a044>] (device_resume+0xb0/0x170) from [<c029aeb4>]
> > (dpm_resume+0xe8/0x20c)
> > [   71.648227] [<c029aeb4>] (dpm_resume+0xe8/0x20c) from [<c029b174>]
> > (dpm_resume_end+0xc/0x18)
> > [   71.648245] [<c029b174>] (dpm_resume_end+0xc/0x18) from [<c005e480>]
> > (suspend_devices_and_enter+0xdc/0x2f8)
> > [   71.648256] [<c005e480>] (suspend_devices_and_enter+0xdc/0x2f8) from
> > [<c005e810>] (pm_suspend+0x174/0x1e8)
> > [   71.648265] [<c005e810>] (pm_suspend+0x174/0x1e8) from [<c005d710>]
> > (state_store+0x6c/0xbc)
> > [   71.648285] [<c005d710>] (state_store+0x6c/0xbc) from [<c01eca78>]
> > (kobj_attr_store+0x14/0x20)
> > [   71.648298] [<c01eca78>] (kobj_attr_store+0x14/0x20) from [<c011e970>]
> > (sysfs_write_file+0x168/0x198)
> > [   71.648312] [<c011e970>] (sysfs_write_file+0x168/0x198) from
> > [<c00cd060>] (vfs_write+0xb0/0x188)
> > [   71.648321] [<c00cd060>] (vfs_write+0xb0/0x188) from [<c00cd410>]
> > (SyS_write+0x3c/0x70)
> > [   71.648330] [<c00cd410>] (SyS_write+0x3c/0x70) from [<c000e560>]
> > (ret_fast_syscall+0x0/0x30)
> > [   71.648334] ---[ end trace e5ed8212ac4db5da ]---
> > [   72.063578] mmc1: power class selection to bus width 8 failed
> > [   72.297753] usb 2-1: reset high-speed USB device number 2 using
> > tegra-ehci [   72.567736] usb 3-1: reset high-speed USB device number 2
> > using tegra-ehci [   73.022058] usb 3-1.3: reset high-speed USB device
> > number 4 using tegra- ehci
> > [   73.216064] usb 3-1.2: reset high-speed USB device number 3 using
> > tegra-
> > ehci
> > [   73.360225] PM: resume of devices complete after 1715.937 msecs
> > [   73.361008] Restarting tasks ... done.
> > 
> > and sdcard being offline after resume (fixed by
> > CONFIG_MMC_UNSAFE_RESUME=y). Anyway, thanks for your great work!
> > 
> > Tested-By: Marc Dietrich <marvin24 at gmx.de>
> 
> I had same warn on 3.8.
> https://bitbucket.org/digetx/picasso-kernel/commits/a86dc95ab48dd77eaa046384
> 4cdf88a5acf9d842

Stephen Warren said on IRC that this is known and on the internal bug tracker 
already. I just posted it so others are not surprised. Well, I should have 
added that it's a know problem. Sorry for that.

Marc






From richardcochran at gmail.com  Sat Jul 27 14:17:09 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Sat, 27 Jul 2013 20:17:09 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <alpine.DEB.2.02.1307271056060.13167@nftneq.ynat.uz>
References: <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726045433.GB4100@netboy>
 <20130726171524.GB28895@obsidianresearch.com>
 <20130727084825.GA4707@netboy>
 <20130727104018.GC9858@sirena.org.uk>
 <20130727173748.GA4813@netboy>
 <alpine.DEB.2.02.1307271056060.13167@nftneq.ynat.uz>
Message-ID: <20130727181709.GC4813@netboy>

On Sat, Jul 27, 2013 at 10:57:09AM -0700, David Lang wrote:
> On Sat, 27 Jul 2013, Richard Cochran wrote:
> 
> >On Sat, Jul 27, 2013 at 11:40:18AM +0100, Mark Brown wrote:
> >>On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote:
> >>
> >>>[ I disagree about the "more thought" part. The current discussion,
> >>>  coming years too late after the introduction of DT to ARM Linux, is
> >>>  contrary evidence enough. ]
> >>
> >>We did have exactly the same discussion when the DT transition was
> >>started - this isn't something that people only just realised might be
> >>an issue.  There was a deliberate decision to focus on getting the
> >>technology deployed to the point where it could be used as a straight
> >>replacement for board files and accept that sometimes the results won't
> >>be perfect and that we may need to rework as a result.
> >
> >Can you tell a bit more about this decision? When was it made? Who
> >made it? How was it made public?
> 
> I remember seeing some of the discussion on linux-kernel at the
> time. I believe there was also a LWN article.

I must have missed it on lkml, although I do try to keep an eye on
this topic. I did find

   http://lwn.net/Articles/414016/
   http://lwn.net/Articles/426606/

but no word about unstable bindings. Maybe this was decided by the
modern method of secret committee?

Thanks,
Richard


From digetx at gmail.com  Sat Jul 27 14:26:06 2013
From: digetx at gmail.com (Dmitry Osipenko)
Date: Sat, 27 Jul 2013 22:26:06 +0400
Subject: [PATCH 0/8] ARM: tegra: support LP1 suspend mode
In-Reply-To: <4555938.6N2HxzJnNO@ax5200p>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
 <2389689.JgQlW00RdN@ax5200p> <51F3F356.8080709@gmail.com>
 <4555938.6N2HxzJnNO@ax5200p>
Message-ID: <51F410BE.3000904@gmail.com>

27.07.2013 22:09, Marc Dietrich ?????:
> On Saturday 27 July 2013 20:20:38 Dmitry Osipenko wrote:
>> 27.07.2013 20:12, Marc Dietrich ?????:
>>> On Friday 26 July 2013 17:15:02 Joseph Lo wrote:
>>>> This series adds the support of LP1 suspend mode for Tegra.
>>>>
>>>> Verified on Seaboard, Cardhu and Dalmore.
>>>
>>> tested on AC100 and worked fine, except
>>>
>>> [   68.448007] PM: Syncing filesystems ... done.
>>> [   71.370086] Freezing user space processes ... (elapsed 0.001 seconds)
>>> done. [   71.370088] Freezing remaining freezable tasks ... (elapsed
>>> 0.001 seconds) done.
>>> [   71.371253] Suspending console(s) (use no_console_suspend to debug)
>>> [   71.638481] PM: suspend of devices complete after 266.604 msecs
>>> [   71.638905] PM: late suspend of devices complete after 0.417 msecs
>>> [   71.639477] PM: noirq suspend of devices complete after 0.568 msecs
>>> [   71.639480] Disabling non-boot CPUs ...
>>> [   71.640242] CPU1: shutdown
>>> [   71.641216] Entering suspend state LP1
>>> [   71.641267] Enabling non-boot CPUs ...
>>> [   71.643125] CPU1: Booted secondary processor
>>> [   71.643449] CPU1 is up
>>> [   71.643786] PM: noirq resume of devices complete after 0.331 msecs
>>> [   71.644300] PM: early resume of devices complete after 0.364 msecs
>>> [   71.648038] ------------[ cut here ]------------
>>> [   71.648061] WARNING: CPU: 0 PID: 1025 at kernel/irq/manage.c:529
>>> irq_set_irq_wake+0xb8/0xf0()
>>> [   71.648064] Unbalanced IRQ 384 wake disable
>>> [   71.648068] Modules linked in:
>>> [   71.648075] CPU: 0 PID: 1025 Comm: bash Not tainted 3.11.0-rc2-
>>> next-20130726-00008-gef01509-dirty #6
>>> [   71.648107] [<c001551c>] (unwind_backtrace+0x0/0xf8) from [<c001154c>]
>>> (show_stack+0x10/0x14)
>>> [   71.648128] [<c001154c>] (show_stack+0x10/0x14) from [<c0515288>]
>>> (dump_stack+0x80/0xc4)
>>> [   71.648142] [<c0515288>] (dump_stack+0x80/0xc4) from [<c0025340>]
>>> (warn_slowpath_common+0x64/0x88)
>>> [   71.648151] [<c0025340>] (warn_slowpath_common+0x64/0x88) from
>>> [<c00253f8>] (warn_slowpath_fmt+0x30/0x40)
>>> [   71.648161] [<c00253f8>] (warn_slowpath_fmt+0x30/0x40) from
>>> [<c007ff8c>]
>>> (irq_set_irq_wake+0xb8/0xf0)
>>> [   71.648178] [<c007ff8c>] (irq_set_irq_wake+0xb8/0xf0) from [<c0334d00>]
>>> (tps6586x_rtc_resume+0x30/0x38)
>>> [   71.648192] [<c0334d00>] (tps6586x_rtc_resume+0x30/0x38) from
>>> [<c02951d0>] (platform_pm_resume+0x2c/0x4c)
>>> [   71.648202] [<c02951d0>] (platform_pm_resume+0x2c/0x4c) from
>>> [<c0299d40>] (dpm_run_callback.isra.5+0x18/0x38)
>>> [   71.648211] [<c0299d40>] (dpm_run_callback.isra.5+0x18/0x38) from
>>> [<c029a044>] (device_resume+0xb0/0x170)
>>> [   71.648219] [<c029a044>] (device_resume+0xb0/0x170) from [<c029aeb4>]
>>> (dpm_resume+0xe8/0x20c)
>>> [   71.648227] [<c029aeb4>] (dpm_resume+0xe8/0x20c) from [<c029b174>]
>>> (dpm_resume_end+0xc/0x18)
>>> [   71.648245] [<c029b174>] (dpm_resume_end+0xc/0x18) from [<c005e480>]
>>> (suspend_devices_and_enter+0xdc/0x2f8)
>>> [   71.648256] [<c005e480>] (suspend_devices_and_enter+0xdc/0x2f8) from
>>> [<c005e810>] (pm_suspend+0x174/0x1e8)
>>> [   71.648265] [<c005e810>] (pm_suspend+0x174/0x1e8) from [<c005d710>]
>>> (state_store+0x6c/0xbc)
>>> [   71.648285] [<c005d710>] (state_store+0x6c/0xbc) from [<c01eca78>]
>>> (kobj_attr_store+0x14/0x20)
>>> [   71.648298] [<c01eca78>] (kobj_attr_store+0x14/0x20) from [<c011e970>]
>>> (sysfs_write_file+0x168/0x198)
>>> [   71.648312] [<c011e970>] (sysfs_write_file+0x168/0x198) from
>>> [<c00cd060>] (vfs_write+0xb0/0x188)
>>> [   71.648321] [<c00cd060>] (vfs_write+0xb0/0x188) from [<c00cd410>]
>>> (SyS_write+0x3c/0x70)
>>> [   71.648330] [<c00cd410>] (SyS_write+0x3c/0x70) from [<c000e560>]
>>> (ret_fast_syscall+0x0/0x30)
>>> [   71.648334] ---[ end trace e5ed8212ac4db5da ]---
>>> [   72.063578] mmc1: power class selection to bus width 8 failed
>>> [   72.297753] usb 2-1: reset high-speed USB device number 2 using
>>> tegra-ehci [   72.567736] usb 3-1: reset high-speed USB device number 2
>>> using tegra-ehci [   73.022058] usb 3-1.3: reset high-speed USB device
>>> number 4 using tegra- ehci
>>> [   73.216064] usb 3-1.2: reset high-speed USB device number 3 using
>>> tegra-
>>> ehci
>>> [   73.360225] PM: resume of devices complete after 1715.937 msecs
>>> [   73.361008] Restarting tasks ... done.
>>>
>>> and sdcard being offline after resume (fixed by
>>> CONFIG_MMC_UNSAFE_RESUME=y). Anyway, thanks for your great work!
>>>
>>> Tested-By: Marc Dietrich <marvin24 at gmx.de>
>>
>> I had same warn on 3.8.
>> https://bitbucket.org/digetx/picasso-kernel/commits/a86dc95ab48dd77eaa046384
>> 4cdf88a5acf9d842
> 
> Stephen Warren said on IRC that this is known and on the internal bug tracker 
> already. I just posted it so others are not surprised. Well, I should have 
> added that it's a know problem. Sorry for that.
> 
> Marc
> 
> 
> 
> 
It might be a known problem only for those who faced with it. Since it's on
their internal irc, it wasn't a known issue.

It also would be interesting to know if suspend with thumb2 works correctly. On
3.8 I've ported lp0 suspend and it works fine with arm compiled kernel, thumb2
also works but only for about 5-10 hours (resuming on each 5-30 minutes, default
android behavior) and after I'm getting pmd corruption. I have no idea from
where that corruption comes from without ability for hw debugging.


From digetx at gmail.com  Sat Jul 27 14:29:23 2013
From: digetx at gmail.com (Dmitry Osipenko)
Date: Sat, 27 Jul 2013 22:29:23 +0400
Subject: [PATCH 0/8] ARM: tegra: support LP1 suspend mode
In-Reply-To: <51F410BE.3000904@gmail.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
 <2389689.JgQlW00RdN@ax5200p> <51F3F356.8080709@gmail.com>
 <4555938.6N2HxzJnNO@ax5200p> <51F410BE.3000904@gmail.com>
Message-ID: <51F41183.5070305@gmail.com>

27.07.2013 22:26, Dmitry Osipenko ?????:
> It might be a known problem only for those who faced with it. Since it's on
> their internal irc, it wasn't a known issue.
> 
> It also would be interesting to know if suspend with thumb2 works correctly. On
> 3.8 I've ported lp0 suspend and it works fine with arm compiled kernel, thumb2
> also works but only for about 5-10 hours (resuming on each 5-30 minutes, default
> android behavior) and after I'm getting pmd corruption. I have no idea from
> where that corruption comes from without ability for hw debugging.
s/irc/bug tracker/ :)


From richardcochran at gmail.com  Sat Jul 27 14:31:01 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Sat, 27 Jul 2013 20:31:01 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <51F39FD8.6080808@broadcom.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <CAOesGMhEr3DiFm5uSgoHPFUMY4jWu4HkeTU2UmOGj=dS75Vk+g@mail.gmail.com>
 <20130727050406.GB4221@netboy> <2007664.vYsECFSKrV@flatron>
 <51F39FD8.6080808@broadcom.com>
Message-ID: <20130727183059.GD4813@netboy>

On Sat, Jul 27, 2013 at 12:24:24PM +0200, Arend van Spriel wrote:
> 
> That is a nice summary of how we got from null to now and Richard
> seems to be simply saying: let's stop mucking about and make this a
> project with a well-defined process of dealing with staging and
> stable bindings and keep stable bindings stable.

Yes, that is right.

Frankly, I am really surprised and shocked at the cavalier attitude
expressed here WRT DT bindings in released kernels. Think about the
*users* of this code. Not everyone working with ARM Linux is a kernel
developer or a DT guru. There is really no indication at all that the
ARM Linux DT stuff released so far are not stable and trustworthy.

It is not nice to provide such a mess, and the idea that we *must*
have a mess because the whole system in still in development is bogus,
IMHO. Just make sure that the mainline kernel is really working and
that the DT bindings *there* are for keeps.

It is your job as kernel developers.

Thanks,
Richard


From tomasz.figa at gmail.com  Sat Jul 27 14:51:06 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sat, 27 Jul 2013 11:51:06 -0700 (PDT)
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130727183059.GD4813@netboy>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F39FD8.6080808@broadcom.com> <20130727183059.GD4813@netboy>
Message-ID: <1441731.8CGUI1tUxh@flatron>

On Saturday 27 of July 2013 20:31:01 Richard Cochran wrote:
> On Sat, Jul 27, 2013 at 12:24:24PM +0200, Arend van Spriel wrote:
> > That is a nice summary of how we got from null to now and Richard
> > seems to be simply saying: let's stop mucking about and make this a
> > project with a well-defined process of dealing with staging and
> > stable bindings and keep stable bindings stable.
> 
> Yes, that is right.
> 
> Frankly, I am really surprised and shocked at the cavalier attitude
> expressed here WRT DT bindings in released kernels. Think about the
> *users* of this code. Not everyone working with ARM Linux is a kernel
> developer or a DT guru. There is really no indication at all that the
> ARM Linux DT stuff released so far are not stable and trustworthy.
> 
> It is not nice to provide such a mess, and the idea that we *must*
> have a mess because the whole system in still in development is bogus,
> IMHO. Just make sure that the mainline kernel is really working and
> that the DT bindings *there* are for keeps.
> 
> It is your job as kernel developers.

Well, it depends on how we use the DT. There are (at least) two possible 
usage scenarios:

 a) using DT as direct replacement for board files - this means that you 
    are free to say that DTSes are strictly coupled with kernel version 
    and you are free to modify the bindings - see the analogy to board 
    files, where you could modify the platform data structures and could 
    not directly copy board file from one kernel version to another,

 b) using DT as an ABI - this is the original way, i.e. define stable 
    bindings and make sure that anu DTB built for older kernel will work,
    with equal or greater set of functionality on newer kernels.

Now I believe in this thread the point whether we should use a) or b) or a 
combination of both has been raised.

As for current situation, from users' perspective it's almost no 
difference. With a) they can use appended DTB feature (or hack, whatever 
you prefer). With b) they just upload new zImage/uImage/whatever, leaving 
old DTB as is, if they don't want any new functionality. If there is 
support added for new functionality, they must update their DTBs anyway, 
so there is no clear advantage of b) over a) in this matter.

So, basically, this is not an obvious issue. Without analyzing (and 
discussing) possible use cases, issues, consequences and whatever, there 
is no obvious answer, such as "just stabilize whatever we have now!" or 
"go back to board files!".

We have what we have, it is not perfect, some things have been screwed up, 
but we can't just leave that behind and say "now we'll be doing everything 
correctly", we must fix that up. People don't do everything correctly from 
the start, this is what the whole staging vs stable topic is about.

Best regards,
Tomasz



From marvin24 at gmx.de  Sat Jul 27 15:03:37 2013
From: marvin24 at gmx.de (Marc Dietrich)
Date: Sat, 27 Jul 2013 21:03:37 +0200
Subject: [PATCH 0/8] ARM: tegra: support LP1 suspend mode
In-Reply-To: <51F410BE.3000904@gmail.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
 <4555938.6N2HxzJnNO@ax5200p> <51F410BE.3000904@gmail.com>
Message-ID: <1515727.YuaSFu1ggc@ax5200p>

On Saturday 27 July 2013 22:26:06 Dmitry Osipenko wrote:
> 27.07.2013 22:09, Marc Dietrich ?????:
> > On Saturday 27 July 2013 20:20:38 Dmitry Osipenko wrote:
> >> 27.07.2013 20:12, Marc Dietrich ?????:
> >>> On Friday 26 July 2013 17:15:02 Joseph Lo wrote:
> >>>> This series adds the support of LP1 suspend mode for Tegra.
> >>>> 
> >>>> Verified on Seaboard, Cardhu and Dalmore.
> >>> 
> >>> tested on AC100 and worked fine, except
> >>> 
> >>> [   68.448007] PM: Syncing filesystems ... done.
> >>> [   71.370086] Freezing user space processes ... (elapsed 0.001 seconds)
> >>> done. [   71.370088] Freezing remaining freezable tasks ... (elapsed
> >>> 0.001 seconds) done.
> >>> [   71.371253] Suspending console(s) (use no_console_suspend to debug)
> >>> [   71.638481] PM: suspend of devices complete after 266.604 msecs
> >>> [   71.638905] PM: late suspend of devices complete after 0.417 msecs
> >>> [   71.639477] PM: noirq suspend of devices complete after 0.568 msecs
> >>> [   71.639480] Disabling non-boot CPUs ...
> >>> [   71.640242] CPU1: shutdown
> >>> [   71.641216] Entering suspend state LP1
> >>> [   71.641267] Enabling non-boot CPUs ...
> >>> [   71.643125] CPU1: Booted secondary processor
> >>> [   71.643449] CPU1 is up
> >>> [   71.643786] PM: noirq resume of devices complete after 0.331 msecs
> >>> [   71.644300] PM: early resume of devices complete after 0.364 msecs
> >>> [   71.648038] ------------[ cut here ]------------
> >>> [   71.648061] WARNING: CPU: 0 PID: 1025 at kernel/irq/manage.c:529
> >>> irq_set_irq_wake+0xb8/0xf0()
> >>> [   71.648064] Unbalanced IRQ 384 wake disable
> >>> [   71.648068] Modules linked in:
> >>> [   71.648075] CPU: 0 PID: 1025 Comm: bash Not tainted 3.11.0-rc2-
> >>> next-20130726-00008-gef01509-dirty #6

> > Stephen Warren said on IRC that this is known and on the internal bug
> > tracker already. I just posted it so others are not surprised. Well, I
> > should have added that it's a know problem. Sorry for that.
> 
> It might be a known problem only for those who faced with it. Since it's on
> their internal irc, it wasn't a known issue.
> 
> It also would be interesting to know if suspend with thumb2 works correctly.
> On 3.8 I've ported lp0 suspend and it works fine with arm compiled kernel,
> thumb2 also works but only for about 5-10 hours (resuming on each 5-30
> minutes, default android behavior) and after I'm getting pmd corruption. I
> have no idea from where that corruption comes from without ability for hw
> debugging.

I don't think anyone can comment on this because lp0 support for mainline is 
not published yet. On the other hand, if you have patches for which you want 
some review, feel free to post them here.

Marc



From digetx at gmail.com  Sat Jul 27 15:11:29 2013
From: digetx at gmail.com (Dmitry Osipenko)
Date: Sat, 27 Jul 2013 23:11:29 +0400
Subject: [PATCH 0/8] ARM: tegra: support LP1 suspend mode
In-Reply-To: <1515727.YuaSFu1ggc@ax5200p>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
 <4555938.6N2HxzJnNO@ax5200p> <51F410BE.3000904@gmail.com>
 <1515727.YuaSFu1ggc@ax5200p>
Message-ID: <51F41B61.7030402@gmail.com>

27.07.2013 23:03, Marc Dietrich ?????:
> On Saturday 27 July 2013 22:26:06 Dmitry Osipenko wrote:
>> 27.07.2013 22:09, Marc Dietrich ?????:
>>> On Saturday 27 July 2013 20:20:38 Dmitry Osipenko wrote:
>>>> 27.07.2013 20:12, Marc Dietrich ?????:
>>>>> On Friday 26 July 2013 17:15:02 Joseph Lo wrote:
>>>>>> This series adds the support of LP1 suspend mode for Tegra.
>>>>>>
>>>>>> Verified on Seaboard, Cardhu and Dalmore.
>>>>>
>>>>> tested on AC100 and worked fine, except
>>>>>
>>>>> [   68.448007] PM: Syncing filesystems ... done.
>>>>> [   71.370086] Freezing user space processes ... (elapsed 0.001 seconds)
>>>>> done. [   71.370088] Freezing remaining freezable tasks ... (elapsed
>>>>> 0.001 seconds) done.
>>>>> [   71.371253] Suspending console(s) (use no_console_suspend to debug)
>>>>> [   71.638481] PM: suspend of devices complete after 266.604 msecs
>>>>> [   71.638905] PM: late suspend of devices complete after 0.417 msecs
>>>>> [   71.639477] PM: noirq suspend of devices complete after 0.568 msecs
>>>>> [   71.639480] Disabling non-boot CPUs ...
>>>>> [   71.640242] CPU1: shutdown
>>>>> [   71.641216] Entering suspend state LP1
>>>>> [   71.641267] Enabling non-boot CPUs ...
>>>>> [   71.643125] CPU1: Booted secondary processor
>>>>> [   71.643449] CPU1 is up
>>>>> [   71.643786] PM: noirq resume of devices complete after 0.331 msecs
>>>>> [   71.644300] PM: early resume of devices complete after 0.364 msecs
>>>>> [   71.648038] ------------[ cut here ]------------
>>>>> [   71.648061] WARNING: CPU: 0 PID: 1025 at kernel/irq/manage.c:529
>>>>> irq_set_irq_wake+0xb8/0xf0()
>>>>> [   71.648064] Unbalanced IRQ 384 wake disable
>>>>> [   71.648068] Modules linked in:
>>>>> [   71.648075] CPU: 0 PID: 1025 Comm: bash Not tainted 3.11.0-rc2-
>>>>> next-20130726-00008-gef01509-dirty #6
> 
>>> Stephen Warren said on IRC that this is known and on the internal bug
>>> tracker already. I just posted it so others are not surprised. Well, I
>>> should have added that it's a know problem. Sorry for that.
>>
>> It might be a known problem only for those who faced with it. Since it's on
>> their internal irc, it wasn't a known issue.
>>
>> It also would be interesting to know if suspend with thumb2 works correctly.
>> On 3.8 I've ported lp0 suspend and it works fine with arm compiled kernel,
>> thumb2 also works but only for about 5-10 hours (resuming on each 5-30
>> minutes, default android behavior) and after I'm getting pmd corruption. I
>> have no idea from where that corruption comes from without ability for hw
>> debugging.
> 
> I don't think anyone can comment on this because lp0 support for mainline is 
> not published yet. On the other hand, if you have patches for which you want 
> some review, feel free to post them here.
> 
> Marc
> 
I'm not expecting comment on it, just for notice :) I'll try this patches in
some near future.


From jonsmirl at gmail.com  Sat Jul 27 15:22:52 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Sat, 27 Jul 2013 15:22:52 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <1441731.8CGUI1tUxh@flatron>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F39FD8.6080808@broadcom.com> <20130727183059.GD4813@netboy>
 <1441731.8CGUI1tUxh@flatron>
Message-ID: <CAKON4Owg7guXo7TjtW3_C2Q07jNT8L6f6648AwXYBOxx2GA28w@mail.gmail.com>

On Sat, Jul 27, 2013 at 2:51 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> On Saturday 27 of July 2013 20:31:01 Richard Cochran wrote:
>> On Sat, Jul 27, 2013 at 12:24:24PM +0200, Arend van Spriel wrote:
>> > That is a nice summary of how we got from null to now and Richard
>> > seems to be simply saying: let's stop mucking about and make this a
>> > project with a well-defined process of dealing with staging and
>> > stable bindings and keep stable bindings stable.
>>
>> Yes, that is right.
>>
>> Frankly, I am really surprised and shocked at the cavalier attitude
>> expressed here WRT DT bindings in released kernels. Think about the
>> *users* of this code. Not everyone working with ARM Linux is a kernel
>> developer or a DT guru. There is really no indication at all that the
>> ARM Linux DT stuff released so far are not stable and trustworthy.
>>
>> It is not nice to provide such a mess, and the idea that we *must*
>> have a mess because the whole system in still in development is bogus,
>> IMHO. Just make sure that the mainline kernel is really working and
>> that the DT bindings *there* are for keeps.
>>
>> It is your job as kernel developers.
>
> Well, it depends on how we use the DT. There are (at least) two possible
> usage scenarios:
>
>  a) using DT as direct replacement for board files - this means that you
>     are free to say that DTSes are strictly coupled with kernel version
>     and you are free to modify the bindings - see the analogy to board
>     files, where you could modify the platform data structures and could
>     not directly copy board file from one kernel version to another,
>
>  b) using DT as an ABI - this is the original way, i.e. define stable
>     bindings and make sure that anu DTB built for older kernel will work,
>     with equal or greater set of functionality on newer kernels.

c) There was very good suggestion earlier about using quirks to fix up
legacy DTBs.  I really like that since the DTB can both be an ABI and
we can continue to evolve the kernel. The quirk code will have little
impact since it will be run at boot time and then discarded.

So there would be an evolving schema that represents the device tree
as understood by a particular kernel.  And then there would be a bunch
of quirks for converting the 'legacy' deployed DTBs into this
tree.These deployed DTBs are only the ones in boot loaders since they
are the only ones that can be seen by multiple kernels.

There are a lot of good places in this process to attach error
checking. For example the quirk code could complain about any DTBs it
is unable to fix up. And verifying things against the schema provides
a single point of contact for device tree design. The universal schema
will force discussion of how to create generic bindings for things
like DMA controllers.

Plus it is still possible to experiment in this model. Bind your DTB
to the kernel. Those DTBs won't be run through the quirk code. You'll
be able to have experimental elements that dtc will flag as not
matching the schema but they'll still be there.

Evolution also works very well. Each release of the kernel will
archive the schema and quirks at the point in time when it is
released.


>
> Now I believe in this thread the point whether we should use a) or b) or a
> combination of both has been raised.
>
> As for current situation, from users' perspective it's almost no
> difference. With a) they can use appended DTB feature (or hack, whatever
> you prefer). With b) they just upload new zImage/uImage/whatever, leaving
> old DTB as is, if they don't want any new functionality. If there is
> support added for new functionality, they must update their DTBs anyway,
> so there is no clear advantage of b) over a) in this matter.
>
> So, basically, this is not an obvious issue. Without analyzing (and
> discussing) possible use cases, issues, consequences and whatever, there
> is no obvious answer, such as "just stabilize whatever we have now!" or
> "go back to board files!".
>
> We have what we have, it is not perfect, some things have been screwed up,
> but we can't just leave that behind and say "now we'll be doing everything
> correctly", we must fix that up. People don't do everything correctly from
> the start, this is what the whole staging vs stable topic is about.
>
> Best regards,
> Tomasz
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Jon Smirl
jonsmirl at gmail.com


From grant.likely at secretlab.ca  Sat Jul 27 15:37:19 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sat, 27 Jul 2013 13:37:19 -0600
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726142140.GR24642@n2100.arm.linux.org.uk>
References: <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy> <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy> <20130726132709.GH29916@titan.lakedaemon.net>
 <1374846070.14574.92.camel@i7.infradead.org>
 <CAKON4OzrkHzUzKkULWCgiEpAtJ5gLxUm78R5ctd7p6trqq_gCA@mail.gmail.com>
 <20130726142140.GR24642@n2100.arm.linux.org.uk>
Message-ID: <CACxGe6v9G0aeAHQoymhg1=aTyNqf2w9OEcuK06GR=8rXCbB+fQ@mail.gmail.com>

On Fri, Jul 26, 2013 at 8:21 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Fri, Jul 26, 2013 at 10:14:32AM -0400, jonsmirl at gmail.com wrote:
>> Yes, yes - that's why the schema should be written down and used as a
>> validation input to dtc. Then dtc can spit out errors for non-standard
>> items. There would be two versions - the standard one and a legacy one
>> that includes the standard one plus the hacks that can't be undone.
>>
>> But more importantly it provides a framework for people creating new
>> node definitions. Now they can't work in a vacuum and come up with
>> random names and structure for everything.
>>
>> Most of the problems express in the thread would go away if the schema
>> was written down and discussed. The rule going forward would be no new
>> nodes that aren't part of the standard schema.
>
> So this is why I'm seeing patches just a short time ago removing existing
> compatible strings from the DT descriptions and associated driver, and
> replacing them with new ones... meaning that the old DT files won't work
> with newer kernels.
>
> What that means is using the descriptions as the schema won't catch that
> because they're changing those as well to match.
>
> There's a solution to that: dtc becomes a separate project external to
> the kernel which also contains the schemas that it verifies against.
> That way, if you want to make changes such as that above, you need to
> get it past not only kernel people but also past dtc maintainers -
> which increases the chances of such stuff being caught.

+1

dtc has always been a separate project that happens to be mirrored in
the kernel tree, but the bindings need to come out be turned into
schema that can be validated.

g.


From grant.likely at secretlab.ca  Sat Jul 27 15:45:18 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sat, 27 Jul 2013 13:45:18 -0600
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <51F3A82E.2000907@broadcom.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
 <2460092.aLmjrOVh1g@flatron> <51F3A82E.2000907@broadcom.com>
Message-ID: <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>

On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel <arend at broadcom.com> wrote:
> Let's see how many people go and scream if I say this: Too bad .dts files
> are not done using XML format as DT bindings could be described using XML
> Schema.

Draft an example and show us how it would look!  :-)  There is
absolutely nothing preventing us from expressing a DT in XML format,
or even using XSLT to define DT schema while still using our current
.dts syntax. It would be trivial to do lossless translation between
.dts syntax and xml.

The problem that I have with XML and XSLT is that it is very verbose
and not entirely friendly to mere-mortals. However, I'm more than
willing to be proved wrong on this point.

g.


From arnd at arndb.de  Sat Jul 27 15:49:16 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 27 Jul 2013 21:49:16 +0200
Subject: [PATCH v3 1/3] ARM: BCM5301X: initial support for the
 BCM5301X/BCM470X SoCs with ARM CPU
In-Reply-To: <20130726165311.GH17886@mudshark.cambridge.arm.com>
References: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
 <51F28A20.7060105@hauke-m.de>
 <20130726165311.GH17886@mudshark.cambridge.arm.com>
Message-ID: <201307272149.17108.arnd@arndb.de>

On Friday 26 July 2013, Will Deacon wrote:
> > > At least, we need a pretty good explanation of what exactly is causing
> > > these spurious aborts before we start ignoring them unconditionally like
> > > this. You're effectively masking an extremely serious error indicator with
> > > this change.
> > 
> > This fault occurs once every boot sometime early in the boot process,
> > but the actual time this happens varies randomly.
> 
> Well that's interesting in itself. It sounds like we don't know *for sure*
> whether the abort is triggered by Linux. Since the abort is imprecise, the
> timing will vary.

It might be possible to find out the culprit if you just enter an endless loop
in the early kernel boot code. If you enter the loop before Linux does something
wrong, it won't crash, otherwise it will. After that, you could bisect the
boot process by moving the busy loop around.

If it even crashes at the point where Linux gets entered, it's a bug in the
boot loader.

	Arnd


From jonsmirl at gmail.com  Sat Jul 27 16:01:10 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Sat, 27 Jul 2013 16:01:10 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
 <2460092.aLmjrOVh1g@flatron> <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
Message-ID: <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>

On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
> On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel <arend at broadcom.com> wrote:
>> Let's see how many people go and scream if I say this: Too bad .dts files
>> are not done using XML format as DT bindings could be described using XML
>> Schema.
>
> Draft an example and show us how it would look!  :-)  There is
> absolutely nothing preventing us from expressing a DT in XML format,
> or even using XSLT to define DT schema while still using our current
> .dts syntax. It would be trivial to do lossless translation between
> .dts syntax and xml.
>
> The problem that I have with XML and XSLT is that it is very verbose
> and not entirely friendly to mere-mortals. However, I'm more than
> willing to be proved wrong on this point.

I considered this approach a while ago and discarded it. It would work
but it is just too much of a Frankenstein monster.

Much cleaner to modify dtc to take a schema as part of the compilation
process. The schema language itself has no requirement to look like
DTS syntax. Whoever wrote dtc probably has a favorite language that
would be good for writing schemas in.


>
> g.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Jon Smirl
jonsmirl at gmail.com


From dwmw2 at infradead.org  Sat Jul 27 16:03:09 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 27 Jul 2013 21:03:09 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
 <2460092.aLmjrOVh1g@flatron> <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
Message-ID: <1374955389.2923.101.camel@shinybook.infradead.org>

On Sat, 2013-07-27 at 16:01 -0400, jonsmirl at gmail.com wrote:
> 
> Much cleaner to modify dtc to take a schema as part of the compilation
> process. The schema language itself has no requirement to look like
> DTS syntax. Whoever wrote dtc probably has a favorite language that
> would be good for writing schemas in.

Yes, we *definitely* want dtc to be doing the validation when it builds
trees. And warning (and needing an additional and suitably scarily named
command line option) if you try to build something *without* a schema.

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130727/664eb53a/attachment-0001.bin>

From grant.likely at secretlab.ca  Sat Jul 27 16:25:02 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sat, 27 Jul 2013 14:25:02 -0600
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
 <2460092.aLmjrOVh1g@flatron> <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
Message-ID: <CACxGe6uE6jOE-vz0onW5h93Es-soGiBAcFBM7Dvxh+HvCNrHkw@mail.gmail.com>

On Sat, Jul 27, 2013 at 2:01 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
> On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
>> On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel <arend at broadcom.com> wrote:
>>> Let's see how many people go and scream if I say this: Too bad .dts files
>>> are not done using XML format as DT bindings could be described using XML
>>> Schema.
>>
>> Draft an example and show us how it would look!  :-)  There is
>> absolutely nothing preventing us from expressing a DT in XML format,
>> or even using XSLT to define DT schema while still using our current
>> .dts syntax. It would be trivial to do lossless translation between
>> .dts syntax and xml.
>>
>> The problem that I have with XML and XSLT is that it is very verbose
>> and not entirely friendly to mere-mortals. However, I'm more than
>> willing to be proved wrong on this point.
>
> I considered this approach a while ago and discarded it. It would work
> but it is just too much of a Frankenstein monster.
>
> Much cleaner to modify dtc to take a schema as part of the compilation
> process. The schema language itself has no requirement to look like
> DTS syntax. Whoever wrote dtc probably has a favorite language that
> would be good for writing schemas in.

Making it part of dtc is a required feature as far as I'm concerned.
Using XML/XSLT and dtc-integration are not mutually exclusive, but I
digress.

g.


From daniel.lezcano at linaro.org  Sat Jul 27 17:43:13 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sat, 27 Jul 2013 23:43:13 +0200
Subject: [RESEND] cpuidle for ARM pull request
In-Reply-To: <2224191.VjCA0rsPcU@vostro.rjw.lan>
References: <51E536C5.1020609@linaro.org> <1598661.FpX5cmjM1U@vostro.rjw.lan>
 <51F3650B.8080708@linaro.org> <2224191.VjCA0rsPcU@vostro.rjw.lan>
Message-ID: <51F43EF1.1020108@linaro.org>

On 07/27/2013 02:37 PM, Rafael J. Wysocki wrote:
> On Saturday, July 27, 2013 08:13:31 AM Daniel Lezcano wrote:
>> On 07/26/2013 02:07 AM, Rafael J. Wysocki wrote:
>>> On Friday, July 26, 2013 12:41:09 AM Rafael J. Wysocki wrote:
>>>> On Friday, July 26, 2013 12:29:08 AM Rafael J. Wysocki wrote:
>>>>> On Friday, July 26, 2013 12:07:03 AM Daniel Lezcano wrote:
>>>>>> On 07/16/2013 02:04 PM, Daniel Lezcano wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The first PR was against the linux-pm-next tree including the patch:
>>>>>>>
>>>>>>> "cpuidle: Add Kconfig.arm and move calxeda, kirkwood and zynq"
>>>>>>>
>>>>>>> This patch has been dropped in the meantime.
>>>>>>>
>>>>>>> Here is a new PR where my tree has been rebased against linux-pm-next
>>>>>>> and adding the patch mentioned above.
>>>>>>>
>>>>>>> As stated by Rafael, I will handle the ARM specific patches from now.
>>>>>>>
>>>>>>> The following changes since commit 48f99d5a97d32d70c0738d6e314d9f4dbefd89bf:
>>>>>>>
>>>>>>>   Merge branch 'pm-cpuidle-next' into linux-next (2013-07-16 02:41:06 +0200)
>>>>>>>
>>>>>>> are available in the git repository at:
>>>>>>>
>>>>>>>
>>>>>>>   git://git.linaro.org/people/dlezcano/linux.git cpuidle/arm-next
>>>>>>>
>>>>>>> for you to fetch changes up to 2b7e79f4a75e803184f483985a25cc751a990f06:
>>>>>>>
>>>>>>>   ARM: ux500: cpuidle: Move ux500 cpuidle driver to drivers/cpuidle
>>>>>>> (2013-07-16 13:57:24 +0200)
>>>>>>
>>>>>> ping ?
>>>>>
>>>>> Sorry, something distracted me.  I'll pull it later today unless there are any
>>>>> problems (in which case I'll let you know).
>>>>
>>>> Well, there are some.
>>>>
>>>> It is based on my linux-next branch, but please rebase it on top of 3.11-rc2.
>>>>
>>>> Generally, please send me pull requests based on -rc kernels only (or major
>>>> releases).
>>>
>>> Unless your material depends on new things in my linux-next branch, in which
>>> case please let me know and I'll set up a stable branch for you to base things
>>> on.
>>
>> Hi Rafael,
>>
>> I rebased my branch on top of 3.11-rc2, you can try to pull it again.
> 
> Pulled, thanks!
> 
> Next time, can you please add a general description of what the patches do and
> why they do that to the pull request?

Yes, sure. I will do.

>> I thought it would have been easier for us if I could based my PRs on
>> top of your linux-next branch, so acting as a proxy for ARM patches. I
>> am maintaining the clocksource drivers and I am basing my tree on top of
>> tip/core.
>>
>> I guess you are rebasing your tree often and this is an issue for you,
>> right ?
> 
> Yes, my linux-next branch may contain commits that will be modified later
> (e.g. ACKs added, fixes folded in etc.).
> 
> Anyway, as I said, as long as the material you have for me doesn't depend on
> anything new in my tree, it's better to base it on top of an -rc kernel.
> 
> In case it does depend on that, I've put the entire outstanding cpuidle
> material into my pm-cpuidle branch (including your ARM commits just pulled).

Ok, thanks.

  -- Daniel



-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From joelf at ti.com  Sat Jul 27 19:32:46 2013
From: joelf at ti.com (Joel Fernandes)
Date: Sat, 27 Jul 2013 18:32:46 -0500
Subject: [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA
 resources
In-Reply-To: <1374515989-7391-1-git-send-email-joelf@ti.com>
References: <1374515989-7391-1-git-send-email-joelf@ti.com>
Message-ID: <51F4589E.5070108@ti.com>

Hi Tony or Sekhar,

If this patch looks ok, could you pick it up for -rc cycle?

It fixes DMA breakages after the merge window for devices for which DMA
resources are being populated in device tree instead pdev.

Thanks,

-Joel


On 07/22/2013 12:59 PM, Joel Fernandes wrote:
> HWMOD removal for MMC is breaking edma_start as the events are being manually
> triggered due to unused channel list not being clear, Thanks to Balaji TK for
> finding this issue.
> 
> This patch fixes the issue, by reading the "dmas" property from the DT node if
> it exists and clearing the bits in the unused channel list.
> 
> Cc: Balaji T K <balajitk at ti.com>
> Cc: Pantel Antoniou <panto at antoniou-consulting.com>
> Signed-off-by: Joel Fernandes <joelf at ti.com>
> ---
> v2 changes: Fixed compiler warning
> 
>  arch/arm/common/edma.c |   31 +++++++++++++++++++++++--------
>  1 file changed, 23 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index a432e6c..765d578 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -561,14 +561,29 @@ static int reserve_contiguous_slots(int ctlr, unsigned int id,
>  static int prepare_unused_channel_list(struct device *dev, void *data)
>  {
>  	struct platform_device *pdev = to_platform_device(dev);
> -	int i, ctlr;
> -
> -	for (i = 0; i < pdev->num_resources; i++) {
> -		if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
> -				(int)pdev->resource[i].start >= 0) {
> -			ctlr = EDMA_CTLR(pdev->resource[i].start);
> -			clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
> -					edma_cc[ctlr]->edma_unused);
> +	int i = 0, ctlr;
> +	u32 dma_chan;
> +	const __be32 *dma_chan_p;
> +	struct property *prop;
> +
> +	if (dev->of_node) {
> +		of_property_for_each_u32(dev->of_node, "dmas", prop, \
> +					 dma_chan_p, dma_chan) {
> +			if (i++ & 1) {
> +				ctlr = EDMA_CTLR(dma_chan);
> +				clear_bit(EDMA_CHAN_SLOT(dma_chan),
> +						edma_cc[ctlr]->edma_unused);
> +			}
> +		}
> +	} else {
> +		for (; i < pdev->num_resources; i++) {
> +			if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
> +			    (int)pdev->resource[i].start >= 0) {
> +				ctlr = EDMA_CTLR(pdev->resource[i].start);
> +				clear_bit(EDMA_CHAN_SLOT(
> +					  pdev->resource[i].start),
> +					  edma_cc[ctlr]->edma_unused);
> +			}
>  		}
>  	}
>  
> 



From linux at prisktech.co.nz  Sat Jul 27 20:00:20 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Sun, 28 Jul 2013 12:00:20 +1200
Subject: [PATCH] dts: wandboard: Add support for SDIO bcm4329
Message-ID: <1374969621-4187-1-git-send-email-linux@prisktech.co.nz>

The wandboard has a Broadcom 4329 WiFi connected via SDIO. This patch
sets the required pins to enable the wifi module.

Signed-off-by: Tony Prisk <linux at prisktech.co.nz>
---
 arch/arm/boot/dts/imx6qdl-wandboard.dtsi |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
index 7a46f64..2fb0e9b 100644
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -73,9 +73,14 @@
 	hog {
 		pinctrl_hog: hoggrp {
 			fsl,pins = <
-				MX6QDL_PAD_GPIO_0__CCM_CLKO1 	0x130b0
-				MX6QDL_PAD_GPIO_2__GPIO1_IO02	0x80000000
-				MX6QDL_PAD_EIM_DA9__GPIO3_IO09	0x80000000
+				MX6QDL_PAD_GPIO_0__CCM_CLKO1 	 0x130b0
+				MX6QDL_PAD_GPIO_2__GPIO1_IO02	 0x80000000
+				MX6QDL_PAD_EIM_DA9__GPIO3_IO09	 0x80000000
+				MX6QDL_PAD_EIM_EB1__GPIO2_IO29   0x80000000 /* WL_REF_ON */
+				MX6QDL_PAD_EIM_A25__GPIO5_IO02   0x80000000 /* WL_RST_N */
+				MX6QDL_PAD_ENET_RXD1__GPIO1_IO26 0x80000000 /* WL_REG_ON */
+				MX6QDL_PAD_ENET_TXD1__GPIO1_IO29 0x80000000 /* WL_HOST_WAKE */
+				MX6QDL_PAD_ENET_TXD0__GPIO1_IO30 0x80000000 /* WL_WAKE */
 			>;
 		};
 	};
-- 
1.7.9.5



From grant.likely at secretlab.ca  Sat Jul 27 23:28:15 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sat, 27 Jul 2013 21:28:15 -0600
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <CACxGe6uE6jOE-vz0onW5h93Es-soGiBAcFBM7Dvxh+HvCNrHkw@mail.gmail.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
 <2460092.aLmjrOVh1g@flatron> <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
 <CACxGe6uE6jOE-vz0onW5h93Es-soGiBAcFBM7Dvxh+HvCNrHkw@mail.gmail.com>
Message-ID: <CACxGe6vw9=y5a+EgF1gO39SwGAdGofD2MYjyJ3jYu6uN3ke70A@mail.gmail.com>

On Sat, Jul 27, 2013 at 2:25 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
> On Sat, Jul 27, 2013 at 2:01 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>> On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
>>> On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel <arend at broadcom.com> wrote:
>>>> Let's see how many people go and scream if I say this: Too bad .dts files
>>>> are not done using XML format as DT bindings could be described using XML
>>>> Schema.
>>>
>>> Draft an example and show us how it would look!  :-)  There is
>>> absolutely nothing preventing us from expressing a DT in XML format,
>>> or even using XSLT to define DT schema while still using our current
>>> .dts syntax. It would be trivial to do lossless translation between
>>> .dts syntax and xml.
>>>
>>> The problem that I have with XML and XSLT is that it is very verbose
>>> and not entirely friendly to mere-mortals. However, I'm more than
>>> willing to be proved wrong on this point.
>>
>> I considered this approach a while ago and discarded it. It would work
>> but it is just too much of a Frankenstein monster.
>>
>> Much cleaner to modify dtc to take a schema as part of the compilation
>> process. The schema language itself has no requirement to look like
>> DTS syntax. Whoever wrote dtc probably has a favorite language that
>> would be good for writing schemas in.
>
> Making it part of dtc is a required feature as far as I'm concerned.
> Using XML/XSLT and dtc-integration are not mutually exclusive, but I
> digress.

Oops, ignore the XSLT bit. XSLT isn't schema and has no bearing on the
discussion of schema. Sorry for the noise.

g.


From grant.likely at secretlab.ca  Sun Jul 28 00:11:26 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sat, 27 Jul 2013 22:11:26 -0600
Subject: [PATCHv5 01/11] irqdomain: add irq_alloc_mapping() function
In-Reply-To: <1373889167-27878-2-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-2-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130728041127.068613E08F8@localhost>

On Mon, 15 Jul 2013 13:52:37 +0200, Thomas Petazzoni <thomas.petazzoni at free-electrons.com> wrote:
> This commit extends the irqdomain subsystem with an
> irq_alloc_mapping() function which allows to let the irqdomain code
> find an available hwirq number in the range [ 0 ; domain size ] for
> the given domain, and create a virq mapping for it.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  include/linux/irqdomain.h |  2 ++
>  kernel/irq/irqdomain.c    | 32 ++++++++++++++++++++++++++++++++
>  2 files changed, 34 insertions(+)
> 
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index c983ed1..1ffa336 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -195,6 +195,8 @@ static inline unsigned int irq_linear_revmap(struct irq_domain *domain,
>  extern unsigned int irq_find_mapping(struct irq_domain *host,
>  				     irq_hw_number_t hwirq);
>  extern unsigned int irq_create_direct_mapping(struct irq_domain *host);
> +extern unsigned int irq_alloc_mapping(struct irq_domain *host,
> +				      irq_hw_number_t *hwirq);
>  extern int irq_create_strict_mappings(struct irq_domain *domain,
>  				      unsigned int irq_base,
>  				      irq_hw_number_t hwirq_base, int count);
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 706724e..b9ddb94 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -375,6 +375,38 @@ unsigned int irq_create_direct_mapping(struct irq_domain *domain)
>  EXPORT_SYMBOL_GPL(irq_create_direct_mapping);
>  
>  /**
> + * irq_alloc_mapping() - Allocate an irq for mapping
> + * @domain: domain to allocate the irq for or NULL for default domain
> + * @hwirq:  reference to the returned hwirq
> + *
> + * This routine are used for irq controllers which can choose the
> + * hardware interrupt number from a range [ 0 ; domain size ], such as
> + * is often the case with PCI MSI controllers. The function will
> + * returned the allocated hwirq number in the hwirq pointer, and the
> + * corresponding virq number as the return value.
> + */
> +unsigned int irq_alloc_mapping(struct irq_domain *domain,
> +			       irq_hw_number_t *out_hwirq)
> +{
> +	irq_hw_number_t hwirq;
> +
> +	pr_debug("irq_alloc_mapping(0x%p)\n", domain);
> +
> +	for (hwirq = 0; hwirq < domain->hwirq_max; hwirq++)
> +		if (!irq_find_mapping(domain, hwirq))
> +			break;

Okay, you can add my acked-by, but only if you change the above hunk to:

	for (hwirq = 0; hwirq < domain->revmap_size; hwirq++)
		if (domain->linear_revmap[hwirq] == 0)
			break;

In some cases hwirq_max will be set to ~0, which means calling
irq_find_mapping about 4 billion times. Not safe. The above change
prevents that problem, but it also means the function won't work for the
tree map. A followup patch can be crafted to add support for the tree
mapping.

> +
> +	if (hwirq == domain->hwirq_max) {
> +		pr_debug("-> no available hwirq found\n");
> +		return 0;
> +	}
> +
> +	*out_hwirq = hwirq;
> +	return irq_create_mapping(domain, hwirq);

out_hwirq should *not* be modified if irq_create_mapping fails. You'll
need to rework the above to:

	rc = irq_create_mapping(domain, hwirq);
	if (rc)
		*out_hwirq = hwirq;
	return rc;

When the above two issues are fixed:

Acked-by: Grant Likely <grant.likely at linaro.org>

> +}
> +EXPORT_SYMBOL_GPL(irq_alloc_mapping);
> +
> +/**
>   * irq_create_mapping() - Map a hardware interrupt into linux irq space
>   * @domain: domain owning this hardware interrupt or NULL for default domain
>   * @hwirq: hardware irq number in that domain space
> -- 
> 1.8.1.2
> 



From grant.likely at secretlab.ca  Sun Jul 28 00:33:10 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sat, 27 Jul 2013 22:33:10 -0600
Subject: [PATCHv5 05/11] of: pci: add registry of MSI chips
In-Reply-To: <51E41F7A.4010502@gmail.com>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E41F7A.4010502@gmail.com>
Message-ID: <20130728043310.6CF1D3E08FE@localhost>

On Mon, 15 Jul 2013 11:12:42 -0500, Rob Herring <robherring2 at gmail.com> wrote:
> On 07/15/2013 06:52 AM, Thomas Petazzoni wrote:
> > This commit adds a very basic registry of msi_chip structures, so that
> > an IRQ controller driver can register an msi_chip, and a PCIe host
> > controller can find it, based on a 'struct device_node'.
> > 
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> 
> Acked-by: Rob Herring <rob.herring at calxeda.com>

Actually, I'm going to disagree on this one and say NAK. I don't think
it is a good idea to create a completely separate registry of msi_chips
for binding to dt nodes. I think it would be better to include the
msi_chip pointer directly into the irq_domain which has to be there
anyway. It then becomes another feature for irq controllers if it can
support doing MSI.

In fact, I would even go so far as to say it would make sense for the
msi_chip functionality to be rolled directly into the irq_domain without
a separate structure; but I'm not nacking on that point.

g.

> 
> 
> > ---
> >  drivers/of/of_pci.c    | 45 +++++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/msi.h    |  2 ++
> >  include/linux/of_pci.h | 12 ++++++++++++
> >  3 files changed, 59 insertions(+)
> > 
> > diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> > index 42c687a..e5ca008 100644
> > --- a/drivers/of/of_pci.c
> > +++ b/drivers/of/of_pci.c
> > @@ -89,3 +89,48 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
> >  	return 0;
> >  }
> >  EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
> > +
> > +#ifdef CONFIG_PCI_MSI
> > +
> > +static LIST_HEAD(of_pci_msi_chip_list);
> > +static DEFINE_MUTEX(of_pci_msi_chip_mutex);
> > +
> > +int of_pci_msi_chip_add(struct msi_chip *chip)
> > +{
> > +	if (!of_property_read_bool(chip->of_node, "msi-controller"))
> > +		return -EINVAL;
> > +
> > +	mutex_lock(&of_pci_msi_chip_mutex);
> > +	list_add(&chip->list, &of_pci_msi_chip_list);
> > +	mutex_unlock(&of_pci_msi_chip_mutex);
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(of_pci_msi_chip_add);
> > +
> > +void of_pci_msi_chip_remove(struct msi_chip *chip)
> > +{
> > +	mutex_lock(&of_pci_msi_chip_mutex);
> > +	list_del(&chip->list);
> > +	mutex_unlock(&of_pci_msi_chip_mutex);
> > +}
> > +EXPORT_SYMBOL_GPL(of_pci_msi_chip_remove);
> > +
> > +struct msi_chip *of_pci_find_msi_chip_by_node(struct device_node *of_node)
> > +{
> > +	struct msi_chip *c;
> > +
> > +	mutex_lock(&of_pci_msi_chip_mutex);
> > +	list_for_each_entry(c, &of_pci_msi_chip_list, list) {
> > +		if (c->of_node == of_node) {
> > +			mutex_unlock(&of_pci_msi_chip_mutex);
> > +			return c;
> > +		}
> > +	}
> > +	mutex_unlock(&of_pci_msi_chip_mutex);
> > +
> > +	return NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(of_pci_find_msi_chip_by_node);
> > +
> > +#endif /* CONFIG_PCI_MSI */
> > diff --git a/include/linux/msi.h b/include/linux/msi.h
> > index cbf5d05..80900e0 100644
> > --- a/include/linux/msi.h
> > +++ b/include/linux/msi.h
> > @@ -67,6 +67,8 @@ void default_teardown_msi_irqs(struct pci_dev *dev);
> >  struct msi_chip {
> >  	struct module *owner;
> >  	struct device *dev;
> > +	struct device_node *of_node;
> > +	struct list_head list;
> >  
> >  	int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
> >  			 struct msi_desc *desc);
> > diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> > index 7a04826..29631eb 100644
> > --- a/include/linux/of_pci.h
> > +++ b/include/linux/of_pci.h
> > @@ -2,6 +2,7 @@
> >  #define __OF_PCI_H
> >  
> >  #include <linux/pci.h>
> > +#include <linux/msi.h>
> >  
> >  struct pci_dev;
> >  struct of_irq;
> > @@ -13,4 +14,15 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
> >  int of_pci_get_devfn(struct device_node *np);
> >  int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
> >  
> > +#if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
> > +int of_pci_msi_chip_add(struct msi_chip *chip);
> > +void of_pci_msi_chip_remove(struct msi_chip *chip);
> > +struct msi_chip *of_pci_find_msi_chip_by_node(struct device_node *of_node);
> > +#else
> > +static inline int of_pci_msi_chip_add(struct msi_chip *chip) { return -EINVAL; }
> > +static inline void of_pci_msi_chip_remove(struct msi_chip *chip) { }
> > +static inline struct msi_chip *
> > +of_pci_find_msi_chip_by_node(struct device_node *of_node) { return NULL };
> > +#endif
> > +
> >  #endif
> > 
> 



From grant.likely at secretlab.ca  Sun Jul 28 00:47:25 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sat, 27 Jul 2013 22:47:25 -0600
Subject: Do we have people interested in device tree janitoring / cleanup?
In-Reply-To: <20130725143815.GA5812@darko.cambridge.arm.com>
References: <CAOesGMge5hCDCeXYHXanaF1vR8mngBwdjhNbzD+Tc2EDUPRgCQ@mail.gmail.com>
 <20130725110634.GB2546@localhost.localdomain>
 <20130725112558.GD24642@n2100.arm.linux.org.uk>
 <20130725135645.GA17304@glitch>
 <20130725142702.GE24642@n2100.arm.linux.org.uk>
 <20130725143815.GA5812@darko.cambridge.arm.com>
Message-ID: <20130728044725.965C43E0A24@localhost>

On Thu, 25 Jul 2013 15:38:15 +0100, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Thu, Jul 25, 2013 at 03:27:02PM +0100, Russell King - ARM Linux wrote:
> > Remember the stated assertion when DT was first added to the kernel: the
> > DT descriptions _will_ become a separately maintained project which is
> > independent of the kernel.  They will _not_ be kernel version specific.
> 
> I'm looking forward to this.
> 
> Question for the DT guys: what are the plans here? Are we going to get
> rid of the .dts files inside the kernel tree?

Short answer: yes

Slightly longer answer: we're working out the plan now. There's lots of
discussion going on right now and we'll be talking about it face-to-face
in Edinburgh in October.

g.



From grant.likely at secretlab.ca  Sun Jul 28 00:39:25 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sat, 27 Jul 2013 22:39:25 -0600
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
Message-ID: <20130728043925.8F3BE3E08FE@localhost>

On Thu, 25 Jul 2013 09:09:19 -0700, Olof Johansson <olof at lixom.net> wrote:
> [I'm adding LKML and ksummit-discuss to this thread, since the ACPI/DT
> discussions have been covered there and this overlaps some with that]
> 
> On Thu, Jul 25, 2013 at 7:38 AM, Catalin Marinas
> <catalin.marinas at arm.com> wrote:
> > On Thu, Jul 25, 2013 at 03:27:02PM +0100, Russell King - ARM Linux wrote:
> >> Remember the stated assertion when DT was first added to the kernel: the
> >> DT descriptions _will_ become a separately maintained project which is
> >> independent of the kernel.  They will _not_ be kernel version specific.
> >
> > I'm looking forward to this.
> >
> > Question for the DT guys: what are the plans here? Are we going to get
> > rid of the .dts files inside the kernel tree?
> 
> In the discussions we had in Dublin, a couple of options on how to
> lock in bindings were discussed. I'm a little surprised that Grant
> didn't cover them in his initial emails on the new maintainership
> model, but maybe he wanted the new group to handle it. And they didn't
> bring it up yet either. So I am. :-)

Excellent! My plan to avoid responsibility for stuff is proceeding.
Actually, I think I touched on it, but the details got lost in my head
among all the other stuff we discussed two weeks ago. Thanks for getting
this detail down into an email.

g.



From grant.likely at linaro.org  Sun Jul 28 01:00:21 2013
From: grant.likely at linaro.org (Grant Likely)
Date: Sat, 27 Jul 2013 23:00:21 -0600
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <1681089.qGWOhLKTTo@avalon>
References: <1624911.6TtmtVmU1T@avalon> <1408178.cxAUTUGJc5@avalon>
 <20130725131556.GD9858@sirena.org.uk> <1681089.qGWOhLKTTo@avalon>
Message-ID: <20130728050021.4370E3E0A24@localhost>

On Thu, 25 Jul 2013 15:22:29 +0200, Laurent Pinchart <laurent.pinchart at ideasonboard.com> wrote:
> Hi Mark,
> 
> On Thursday 25 July 2013 14:15:56 Mark Brown wrote:
> > On Thu, Jul 25, 2013 at 11:45:33AM +0200, Laurent Pinchart wrote:
> > > The two devices are independent, so there's no real parent/child
> > > relationship. However, as Grant proposed, I could list all the interrupts
> > > associated with GPIOs in the GPIO controller DT node. I would then just
> > > call irq_of_parse_and_map() in the .to_irq() handler to magically
> > > translate the GPIO number to a mapped IRQ number.
> > > 
> > > The number of interrupts can be pretty high (up to 58 in the worst case so
> > > far), so an alternative would be to specify the interrupt-parent only, and
> > > call irq_create_of_mapping() directly. What solution would you prefer ?
> > 
> > Are the interrupts in a contiguous block in the controller so you can just
> > pass around the controller and a base number?
> 
> In two of the three SoCs I need to fix they are. I've just realized that in 
> the last one the interrupts are in two contiguous blocks in two different 
> parents. I will thus need at least a list of <parent-phandle base count>. Our 
> standard interrupt bindings don't seem to support multiple parents,

You can actually do it by using a dummy node with interrupt-map and
interrupt-map-mask properties, but it is a pretty ugly solution in my
opinion.

> is that 
> something that we want to fix or should I go for custom bindings ?

Yes, I think it is something that we want to fix. Jean-Christophe was
going to propose an alternative to the interrupts property which allows
an array of <phandle interrupt-specifier> tuples, but I've not seen
anything yet. Go ahead and make a proposal.

You could try to encode a base+count variant, but honestly I don't think
it would be a good idea because it only would work with a very narrow
set of use cases. Consider if #interrupt-cells was set to 2. Which cell
gets incremented in the range of interrupts specified? Better I think to
merely have an array of fully specified irqs. Support for that property
could be transparently baked into the core interrupt parsing functions.

g.


From James.Bottomley at HansenPartnership.com  Sun Jul 28 01:11:16 2013
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Sat, 27 Jul 2013 22:11:16 -0700
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <CACxGe6vw9=y5a+EgF1gO39SwGAdGofD2MYjyJ3jYu6uN3ke70A@mail.gmail.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
 <2460092.aLmjrOVh1g@flatron> <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
 <CACxGe6uE6jOE-vz0onW5h93Es-soGiBAcFBM7Dvxh+HvCNrHkw@mail.gmail.com>
 <CACxGe6vw9=y5a+EgF1gO39SwGAdGofD2MYjyJ3jYu6uN3ke70A@mail.gmail.com>
Message-ID: <1374988276.1973.29.camel@dabdike>

On Sat, 2013-07-27 at 21:28 -0600, Grant Likely wrote:
> On Sat, Jul 27, 2013 at 2:25 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
> > On Sat, Jul 27, 2013 at 2:01 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
> >> On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
> >>> On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel <arend at broadcom.com> wrote:
> >>>> Let's see how many people go and scream if I say this: Too bad .dts files
> >>>> are not done using XML format as DT bindings could be described using XML
> >>>> Schema.
> >>>
> >>> Draft an example and show us how it would look!  :-)  There is
> >>> absolutely nothing preventing us from expressing a DT in XML format,
> >>> or even using XSLT to define DT schema while still using our current
> >>> .dts syntax. It would be trivial to do lossless translation between
> >>> .dts syntax and xml.
> >>>
> >>> The problem that I have with XML and XSLT is that it is very verbose
> >>> and not entirely friendly to mere-mortals. However, I'm more than
> >>> willing to be proved wrong on this point.
> >>
> >> I considered this approach a while ago and discarded it. It would work
> >> but it is just too much of a Frankenstein monster.
> >>
> >> Much cleaner to modify dtc to take a schema as part of the compilation
> >> process. The schema language itself has no requirement to look like
> >> DTS syntax. Whoever wrote dtc probably has a favorite language that
> >> would be good for writing schemas in.
> >
> > Making it part of dtc is a required feature as far as I'm concerned.
> > Using XML/XSLT and dtc-integration are not mutually exclusive, but I
> > digress.
> 
> Oops, ignore the XSLT bit. XSLT isn't schema and has no bearing on the
> discussion of schema. Sorry for the noise.

XSLT is a transform language ... you'd use it say to transform xml to
dtc, so it would be an integral component of an xml/xslt based schema.

If you want actually to describe and have validated the xml schema
itself, then you'd use xsd (XML schema description language) and its
associated tools.

I'm not saying you *should* do this, just that it's possible (plus I've
just blown my kernel cred by knowing about xml, sigh).

James




From grant.likely at secretlab.ca  Sun Jul 28 01:13:45 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Sat, 27 Jul 2013 23:13:45 -0600
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <1374988276.1973.29.camel@dabdike>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
 <2460092.aLmjrOVh1g@flatron> <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
 <CACxGe6uE6jOE-vz0onW5h93Es-soGiBAcFBM7Dvxh+HvCNrHkw@mail.gmail.com>
 <CACxGe6vw9=y5a+EgF1gO39SwGAdGofD2MYjyJ3jYu6uN3ke70A@mail.gmail.com>
 <1374988276.1973.29.camel@dabdike>
Message-ID: <CACxGe6tpfbhb6SQVQYieEX9OT56zWTRf04cg0NJFr4M4LJz5Cw@mail.gmail.com>

On Sat, Jul 27, 2013 at 11:11 PM, James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> If you want actually to describe and have validated the xml schema
> itself, then you'd use xsd (XML schema description language) and its
> associated tools.
>
> I'm not saying you *should* do this, just that it's possible (plus I've
> just blown my kernel cred by knowing about xml, sigh).

:)

g.


From paul at pwsan.com  Sun Jul 28 01:38:06 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Sun, 28 Jul 2013 05:38:06 +0000 (UTC)
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <20130727122221.GB6618@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1307280527430.8385@utopia.booyaka.com>

Hi Will,

On Sat, 27 Jul 2013, Will Deacon wrote:

> That's very odd -- I *suspect* your bootloader is up to no good (iirc, we've
> had issues with the bootloader on this machine in the past, since it enters
> the kernel in ABT mode or something).

Maybe you're thinking of the (2420-based) Nokia N800?  The 2430SDP here 
uses u-boot:

http://www.pwsan.com/omap/testlogs/test_v3.10-rc7/20130630191558/boot/2430sdp/

> Can you try this quick hack please? It clobbers the I-cache as soon as we
> enter the kernel, so it should tell us whether my theory is correct.

Tried it and still hangs.  Spent some time debugging - turns out it's due 
to the extended CP15 register read in cache_ops_need_broadcast().. the 
extended regs aren't present on ARM1136 r0* and trigger an undefined 
instruction abort :-(  Sorry about that, should have taken the time to 
send along an earlyprintk trace.  Patches in a few moments -


- Paul


From paul at pwsan.com  Sun Jul 28 01:43:24 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Sun, 28 Jul 2013 05:43:24 +0000 (UTC)
Subject: [PATCH] ARM: v6: avoid read_cpuid_ext() on ARM1136r0 in
 cache_ops_need_broadcast()
In-Reply-To: <20130727122221.GB6618@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1307280538460.8385@utopia.booyaka.com>


Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting") breaks
the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
undefined instruction abort from the CP15 read in
cache_ops_need_broadcast().  It turns out that early ARM1136 variants
don't support several CP15 registers that later ARM cores do.
ARM1136JF-S TRM section 3.2.1 "Register allocation" has the details.

So, prevent cache_ops_need_broadcast() from attempting the CP15 read
if the running CPU doesn't provide the register.
cache_ops_need_broadcast() is a hot path function, so focus on
minimizing the execution time impact.  A subsequent patch will take
care of the remaining cases in the current kernel.

Thanks to Will Deacon for helping track this down.

Signed-off-by: Paul Walmsley <paul at pwsan.com>
Cc: Will Deacon <will.deacon at arm.com>
---

Intended for v3.11-rc.

Tested (along with the followup patch) here:

http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130727224434/README.txt

against stock v3.11-rc2, so several boards aren't booting due to unrelated 
issues.

 arch/arm/include/asm/cputype.h  | 37 ++++++++++++++++++++++++++++++++++++-
 arch/arm/include/asm/smp_plat.h |  4 +++-
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 8c25dc4..91ccd77 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -76,6 +76,8 @@
 #define ARM_CPU_XSCALE_ARCH_V2		0x4000
 #define ARM_CPU_XSCALE_ARCH_V3		0x6000
 
+#define ARM_CPU_ARM1136R0		0x4107b360
+
 extern unsigned int processor_id;
 
 #ifdef CONFIG_CPU_CP15
@@ -89,10 +91,43 @@ extern unsigned int processor_id;
 		__val;							\
 	})
 
+
+/* Workaround for missing CP15 registers on ARM1136 r0 */
+# if defined(CONFIG_CPU_V6)
+/**
+ * cpu_is_arm1136_r0 - is the kernel running on an ARM1136 r0 core?
+ *
+ * Returns true if the kernel is running on an ARM1136 r0 core, or
+ * false otherwise.  Callers use this to avoid undefined instruction
+ * aborts from CP15 accesses to registers not present on the r0
+ * variant, or to detect whether certain CPU features are available.
+ * ARM1136JF-S TRM section 3.2.1 "Register allocation"
+ */
+static inline bool __attribute_const__ cpu_is_arm1136_r0(void)
+{
+	return ((read_cpuid(CPUID_ID) & 0xfffffff0) == ARM_CPU_ARM1136R0);
+}
+
+/*
+ * The mrc in the read_cpuid_ext macro must not be reordered on ARMv6,
+ * else the compiler may move it before any ARM1136r0 test.
+ */
+# define CPUID_EXT_REORDER	volatile
+# else
+static inline bool __attribute_const__ cpu_is_arm1136_r0(void) { return false; }
+# define CPUID_EXT_REORDER
+# endif
+
+/*
+ * Early ARM1136 variants don't support many CP15 registers provided
+ * on later cores.  Users of read_cpuid_ext must ensure that it won't
+ * be used unless it's known that the running core provides the CP15
+ * register ext_reg.  See cpu_is_arm1136_r0() above.
+ */
 #define read_cpuid_ext(ext_reg)						\
 	({								\
 		unsigned int __val;					\
-		asm("mrc	p15, 0, %0, c0, " ext_reg		\
+		asm CPUID_EXT_REORDER("mrc p15, 0, %0, c0, " ext_reg	\
 		    : "=r" (__val)					\
 		    :							\
 		    : "cc");						\
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 6462a72..76214cb 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -25,7 +25,6 @@ static inline bool is_smp(void)
 #endif
 }
 
-/* all SMP configurations have the extended CPUID registers */
 #ifndef CONFIG_MMU
 #define tlb_ops_need_broadcast()	0
 #else
@@ -43,6 +42,9 @@ static inline int tlb_ops_need_broadcast(void)
 #else
 static inline int cache_ops_need_broadcast(void)
 {
+	if (cpu_is_arm1136_r0())
+		return 0;
+
 	if (!is_smp())
 		return 0;
 
-- 
1.8.3.2



From paul at pwsan.com  Sun Jul 28 01:46:05 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Sun, 28 Jul 2013 05:46:05 +0000 (UTC)
Subject: [PATCH] ARM: v6: avoid remaining accesses to missing CP15 registers
 on ARM1136 r0
In-Reply-To: <alpine.DEB.2.02.1307280527430.8385@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307280527430.8385@utopia.booyaka.com>
Message-ID: <alpine.DEB.2.02.1307280543370.8385@utopia.booyaka.com>


Ensure that the remaining callers of read_cpuid_ext can't attempt an
extended CP15 register read on ARMv6.  The only one that appears dodgy
is tlb_ops_need_broadcast().

While here, convert feat_v6_fixup() to use cpu_is_arm1136_r0() to save
a few lines of code.

Signed-off-by: Paul Walmsley <paul at pwsan.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
---

Intended for v3.12.  Depends on the patch "ARM: v6: avoid read_cpuid_ext() 
on ARM1136r0 in cache_ops_need_broadcast()".

Tested (along with the parent patch) here:

http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130727224434/README.txt

against stock v3.11-rc2, so several boards aren't booting due to unrelated 
issues.

 arch/arm/include/asm/smp_plat.h | 3 +++
 arch/arm/kernel/setup.c         | 7 +------
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 76214cb..ad07564 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -30,6 +30,9 @@ static inline bool is_smp(void)
 #else
 static inline int tlb_ops_need_broadcast(void)
 {
+	if (cpu_is_arm1136_r0())
+		return 0;
+
 	if (!is_smp())
 		return 0;
 
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 63af9a7..a601843 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -389,16 +389,11 @@ static void __init cpuid_init_hwcaps(void)
 
 static void __init feat_v6_fixup(void)
 {
-	int id = read_cpuid_id();
-
-	if ((id & 0xff0f0000) != 0x41070000)
-		return;
-
 	/*
 	 * HWCAP_TLS is available only on 1136 r1p0 and later,
 	 * see also kuser_get_tls_init.
 	 */
-	if ((((id >> 4) & 0xfff) == 0xb36) && (((id >> 20) & 3) == 0))
+	if (cpu_is_arm1136_r0())
 		elf_hwcap &= ~HWCAP_TLS;
 }
 
-- 
1.8.3.2



From paul at pwsan.com  Sun Jul 28 01:58:10 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Sun, 28 Jul 2013 05:58:10 +0000 (UTC)
Subject: [PATCH] ARM: v6: avoid remaining accesses to missing CP15
 registers on ARM1136 r0
In-Reply-To: <alpine.DEB.2.02.1307280543370.8385@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307280527430.8385@utopia.booyaka.com>
 <alpine.DEB.2.02.1307280543370.8385@utopia.booyaka.com>
Message-ID: <alpine.DEB.2.02.1307280557130.8385@utopia.booyaka.com>

On Sun, 28 Jul 2013, Paul Walmsley wrote:

> Ensure that the remaining callers of read_cpuid_ext can't attempt an
> extended CP15 register read on ARMv6.

This description is somewhat inaccurate - it should read something like 
"can't attempt an extended CP15 register read on ARMv6 cores that don't 
support it".  Will resend.


- Paul


From paul at pwsan.com  Sun Jul 28 02:00:26 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Sun, 28 Jul 2013 06:00:26 +0000 (UTC)
Subject: [PATCH v2] ARM: v6: avoid remaining accesses to missing CP15 registers
 on ARM1136 r0
In-Reply-To: <alpine.DEB.2.02.1307280543370.8385@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307280527430.8385@utopia.booyaka.com>
 <alpine.DEB.2.02.1307280543370.8385@utopia.booyaka.com>
Message-ID: <alpine.DEB.2.02.1307280559330.8385@utopia.booyaka.com>

Ensure that the remaining callers of read_cpuid_ext can't attempt an 
extended CP15 register read on ARMv6 cores that don't support it.  The 
only one that appears dodgy is tlb_ops_need_broadcast().

While here, convert feat_v6_fixup() to use cpu_is_arm1136_r0() to save
a few lines of code.

Signed-off-by: Paul Walmsley <paul at pwsan.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/include/asm/smp_plat.h | 3 +++
 arch/arm/kernel/setup.c         | 7 +------
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index 76214cb..ad07564 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -30,6 +30,9 @@ static inline bool is_smp(void)
 #else
 static inline int tlb_ops_need_broadcast(void)
 {
+	if (cpu_is_arm1136_r0())
+		return 0;
+
 	if (!is_smp())
 		return 0;
 
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 63af9a7..a601843 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -389,16 +389,11 @@ static void __init cpuid_init_hwcaps(void)
 
 static void __init feat_v6_fixup(void)
 {
-	int id = read_cpuid_id();
-
-	if ((id & 0xff0f0000) != 0x41070000)
-		return;
-
 	/*
 	 * HWCAP_TLS is available only on 1136 r1p0 and later,
 	 * see also kuser_get_tls_init.
 	 */
-	if ((((id >> 4) & 0xfff) == 0xb36) && (((id >> 20) & 3) == 0))
+	if (cpu_is_arm1136_r0())
 		elf_hwcap &= ~HWCAP_TLS;
 }
 
-- 
1.8.3.2



From daniel.lezcano at linaro.org  Sun Jul 28 03:10:09 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sun, 28 Jul 2013 09:10:09 +0200
Subject: [PATCH] ARM: EXYNOS: cpuidle: Skip C1 cpuidle state for exynos5440
In-Reply-To: <0eaf01ce8863$89d3c4e0$9d7b4ea0$@org>
References: <0e7d01ce8840$82f79070$88e6b150$@org>
 <1374659615-29447-1-git-send-email-amit.daniel@samsung.com>
 <0eaf01ce8863$89d3c4e0$9d7b4ea0$@org>
Message-ID: <51F4C3D1.2060901@linaro.org>

On 07/24/2013 01:47 PM, Kukjin Kim wrote:
> Amit Daniel Kachhap wrote:
>>
>> This patch skips the deep C1(AFTR -Arm off top running) state for
>> exynos5440
>> soc as this soc does not support this state. All the cpu's only allows the
>> basic
>> C0 state.
>>
>> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
>> ---
>>  arch/arm/mach-exynos/cpuidle.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
>> exynos/cpuidle.c
>> index 17a18ff..9a776a1 100644
>> --- a/arch/arm/mach-exynos/cpuidle.c
>> +++ b/arch/arm/mach-exynos/cpuidle.c
>> @@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void)
>>  		device->cpu = cpu_id;
>>
>>  		/* Support IDLE only */
>> -		if (cpu_id != 0)
>> +		if (soc_is_exynos5440() || cpu_id != 0)
>>  			device->state_count = 1;
>>
>>  		ret = cpuidle_register_device(device);
>> --
>> 1.7.1
> 
> Applied, thanks.

You shouldn't have. This patch means exynos5540 has no cpuidle driver at
all. It should be fixed in the Kconfig to unselect CONFIG_CPU_IDLE for
an exynos5540.


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From s.hauer at pengutronix.de  Sun Jul 28 04:34:36 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Sun, 28 Jul 2013 10:34:36 +0200
Subject: [RFC 4/8] pinctrl: imx: Support imx21 register format
In-Reply-To: <1374938808-27316-5-git-send-email-mpa@pengutronix.de>
References: <1374938808-27316-1-git-send-email-mpa@pengutronix.de>
 <1374938808-27316-5-git-send-email-mpa@pengutronix.de>
Message-ID: <20130728083436.GI2737@pengutronix.de>

Hi Markus,

On Sat, Jul 27, 2013 at 05:26:44PM +0200, Markus Pargmann wrote:
> The imx pinctrl core driver does not support the imx21 register format
> yet. This patch adds support for the strange iomux control registers of
> imx21 and imx27. Next to a slightly different DT parse function.
> 
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> ---
>  drivers/pinctrl/pinctrl-imx.c | 264 +++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 250 insertions(+), 14 deletions(-)

Is it really worth sharing the i.MX1/21/27 support with the imx driver?
It seems most of the code is rewritten. I just tried and removed all
lines from pinctrl-imx.c you don't use. There's not much left to share.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From richardcochran at gmail.com  Sun Jul 28 04:56:52 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Sun, 28 Jul 2013 10:56:52 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <1441731.8CGUI1tUxh@flatron>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F39FD8.6080808@broadcom.com> <20130727183059.GD4813@netboy>
 <1441731.8CGUI1tUxh@flatron>
Message-ID: <20130728085650.GA4683@netboy>

On Sat, Jul 27, 2013 at 11:51:06AM -0700, Tomasz Figa wrote:
> On Saturday 27 of July 2013 20:31:01 Richard Cochran wrote:
> > 
> > Frankly, I am really surprised and shocked at the cavalier attitude
> > expressed here WRT DT bindings in released kernels. Think about the
> > *users* of this code. Not everyone working with ARM Linux is a kernel
> > developer or a DT guru. There is really no indication at all that the
> > ARM Linux DT stuff released so far are not stable and trustworthy.

Read the above again, please.

> Well, it depends on how we use the DT. There are (at least) two possible 
> usage scenarios:
> 
>  a) using DT as direct replacement for board files - this means that you 
>     are free to say that DTSes are strictly coupled with kernel version 
>     and you are free to modify the bindings - see the analogy to board 
>     files, where you could modify the platform data structures and could 
>     not directly copy board file from one kernel version to another,
> 
>  b) using DT as an ABI - this is the original way, i.e. define stable 
>     bindings and make sure that anu DTB built for older kernel will work,
>     with equal or greater set of functionality on newer kernels.
> 
> Now I believe in this thread the point whether we should use a) or b) or a 
> combination of both has been raised.

If you seriously want to pursue a) then you are thinking only of
yourself.

Please consider the needs of the people trying to use your code in
actual practice.

Thanks,
Richard



From tomasz.figa at gmail.com  Sun Jul 28 05:12:53 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sun, 28 Jul 2013 11:12:53 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130728085650.GA4683@netboy>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1441731.8CGUI1tUxh@flatron> <20130728085650.GA4683@netboy>
Message-ID: <1416484.XDfk5G56BI@flatron>

On Sunday 28 of July 2013 10:56:52 Richard Cochran wrote:
> On Sat, Jul 27, 2013 at 11:51:06AM -0700, Tomasz Figa wrote:
> > On Saturday 27 of July 2013 20:31:01 Richard Cochran wrote:
> > > Frankly, I am really surprised and shocked at the cavalier attitude
> > > expressed here WRT DT bindings in released kernels. Think about the
> > > *users* of this code. Not everyone working with ARM Linux is a
> > > kernel
> > > developer or a DT guru. There is really no indication at all that
> > > the
> > > ARM Linux DT stuff released so far are not stable and trustworthy.
> 
> Read the above again, please.

I'm not really sure what effect on users this has. Maybe you should define 
"users".

Sure, if you don't like the fact that it is not cleary said, whether we 
use a) or b) (see below), then it's hard to disagree with you - it should 
have been said. We are trying to fix this now.

> > Well, it depends on how we use the DT. There are (at least) two
> > possible> 
> > usage scenarios:
> >  a) using DT as direct replacement for board files - this means that
> >  you
> >  
> >     are free to say that DTSes are strictly coupled with kernel
> >     version
> >     and you are free to modify the bindings - see the analogy to board
> >     files, where you could modify the platform data structures and
> >     could
> >     not directly copy board file from one kernel version to another,
> >  
> >  b) using DT as an ABI - this is the original way, i.e. define stable
> >  
> >     bindings and make sure that anu DTB built for older kernel will
> >     work,
> >     with equal or greater set of functionality on newer kernels.
> > 
> > Now I believe in this thread the point whether we should use a) or b)
> > or a combination of both has been raised.
> 
> If you seriously want to pursue a) then you are thinking only of
> yourself.
> 
> Please consider the needs of the people trying to use your code in
> actual practice.

Care to explain this reasoning?

Let's say I'm not strongly for neither of above and I'd like you to 
convince me to one of the options.

Best regards,
Tomasz



From tomasz.figa at gmail.com  Sun Jul 28 05:22:39 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sun, 28 Jul 2013 11:22:39 +0200
Subject: [PATCH] ARM: EXYNOS: cpuidle: Skip C1 cpuidle state for exynos5440
In-Reply-To: <51F4C3D1.2060901@linaro.org>
References: <0e7d01ce8840$82f79070$88e6b150$@org>
 <0eaf01ce8863$89d3c4e0$9d7b4ea0$@org> <51F4C3D1.2060901@linaro.org>
Message-ID: <1877730.qZVs3NAG5h@flatron>

On Sunday 28 of July 2013 09:10:09 Daniel Lezcano wrote:
> On 07/24/2013 01:47 PM, Kukjin Kim wrote:
> > Amit Daniel Kachhap wrote:
> >> This patch skips the deep C1(AFTR -Arm off top running) state for
> >> exynos5440
> >> soc as this soc does not support this state. All the cpu's only
> >> allows the basic
> >> C0 state.
> >> 
> >> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
> >> ---
> >> 
> >>  arch/arm/mach-exynos/cpuidle.c |    2 +-
> >>  1 files changed, 1 insertions(+), 1 deletions(-)
> >> 
> >> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
> >> exynos/cpuidle.c
> >> index 17a18ff..9a776a1 100644
> >> --- a/arch/arm/mach-exynos/cpuidle.c
> >> +++ b/arch/arm/mach-exynos/cpuidle.c
> >> @@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void)
> >> 
> >>  		device->cpu = cpu_id;
> >>  		
> >>  		/* Support IDLE only */
> >> 
> >> -		if (cpu_id != 0)
> >> +		if (soc_is_exynos5440() || cpu_id != 0)
> >> 
> >>  			device->state_count = 1;
> >>  		
> >>  		ret = cpuidle_register_device(device);
> >> 
> >> --
> >> 1.7.1
> > 
> > Applied, thanks.
> 
> You shouldn't have. This patch means exynos5540 has no cpuidle driver at
> all. It should be fixed in the Kconfig to unselect CONFIG_CPU_IDLE for
> an exynos5540.

To shed more light on this, let me add that you need to register a cpuidle 
driver only if you have more states than a simple WFI or you need some 
crazy steps to enter WFI. Default setup falls back to generic ARM WFI. 
(Daniel, do we get the nice idle stats as provided by cpuidle core then?)

Anyway, Exynos cpuidle is using an initcall to initialize and we support 
multiple Exynos SoCs in single zImage, so deselecting CONFIG_CPU_IDLE is 
not an option. Considering multiplatform requirements, the driver has to 
be modified to initialize only on supported platforms, either by:

 a) dropping the initcall and calling the init function directly from 
arch/arm/mach-exynos

 or

 b) checking if machine we are running on is supported, which would mean a 
long list of all Exynos SoCs that needs to be checked.

An evolution of option a) is registering a platform device somewhere in 
arch/arm/mach-exynos and making exynos-cpuidle a platform driver. The 
problem is that you must register a static platform device from arch code, 
because cpuidle is not a real hardware block that can be put into device 
tree.

Best regards,
Tomasz



From tomasz.figa at gmail.com  Sun Jul 28 06:07:48 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sun, 28 Jul 2013 12:07:48 +0200
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <1624911.6TtmtVmU1T@avalon>
References: <1624911.6TtmtVmU1T@avalon>
Message-ID: <12170068.F0utKQgh5l@flatron>

Hi Laurent,

On Wednesday 24 of July 2013 01:21:44 Laurent Pinchart wrote:
> Hello,
> 
> I'm running into an issue on several Renesas SoC with IRQ domains and
> GPIOs.
> 
> On sh73a0, r8a73a4 and r8a7740, GPIOs and external interrupts are
> handled by two separate IP cores, namely the PFC (Pin Function
> Controller) and INTC (Interrupt Controller). The former is handled by
> the sh-pfc driver (drivers/pinctrl/sh-pfc) and the later by the
> irq-renesas-intc-irqpin driver (drivers/irqchip), referred to below as
> the irqpin driver.

Is the INTC used for anything more than just external interrupts on GPIO 
lines?

> The sh73a0, for instance, has 32 external interrupt lines that are
> multiplexed on pins usable as GPIOs. Both the GPIO and external
> interrupt functions are usable at the same time, which allows reading
> the state of the interrupt lines.
> 
> These external interrupts are for MMC/SD support, among other devices.
> In this specific case the MMC/SD Card Detect signal is wired to one of
> the external interrupt signals, and the corresponding GPIO is passed to
> the MMC/SD controller driver. Depending on other configuration
> parameters the driver can then either poll the Card Detect signal, or
> register an interrupt handler to detect changes in the signal state.
> This features is implemented by the MMC/SD core, which call
> gpio_to_irq() on the GPIO to retrieve the corresponding IRQ number.
> 
> On non-DT systems the external IRQs are statically mapped at a known
> offset. The sh-pfc driver, to implement the gpio_to_irq() function
> (through its gpiochip .to_irq() handler), simply searches a
> SoC-specific lookup table for the fixed IRQ number associated with a
> given GPIO.
> 
> However, on DT systems, IRQs are mapped dynamically on demand. The
> irqpin driver registers a simple IRQ domain, and the
> irq_create_mapping() function can then be used to map a given IRQ,
> specified as an offset in the domain. This is where the problem
> appears, as the irqchip .to_irq() function is implemented in the sh-pfc

I assume it should be s/irqchip/gpiochip/ in the line above, shouldn't it?

> driver, which doesn't have access to the IRQ domain registered by the
> irqpin driver.
> 
> I could hack around this by exporting a function in the irqpin driver
> that would map an IRQ, and call that function from the sh-pfc driver.
> I'd rather avoid that solution as it would add a direct dependency
> between the two drivers.

If you could just get the IRQ domain registered by irqpin driver and use 
it in sh-pfc, then I guess it would solve your problem, as you could 
simply call irq_create_mapping() with the domain and hwirq as args in your 
gpiochip .to_irq() callback.

I'm not sure if it's not a hack, but you could add a property to the node 
of your pin controller that would contain a phandle to your interrupt 
controller. Then you could use of_parse_phandle() to get to device node of 
the INTC and then irq_find_host() to retrieve irq domain associated with 
it.

> Has anyone run into a similar issue ? My gut feeling is that the
> architecture isn't right somewhere, but I can't really pinpoint where.
> As the external IRQs are handled by an IP core separate from the PFC

Well, the fact that it's separate doesn't mean anything yet. Here my 
question whether it's used exclusively for GPIO interrupts or not becomes 
significant. If yes, maybe it could be simply moved to the pinctrl driver?

Best regards,
Tomasz



From mpa at pengutronix.de  Sun Jul 28 06:22:15 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 28 Jul 2013 12:22:15 +0200
Subject: [RFC 4/8] pinctrl: imx: Support imx21 register format
In-Reply-To: <20130728083436.GI2737@pengutronix.de>
References: <1374938808-27316-1-git-send-email-mpa@pengutronix.de>
 <1374938808-27316-5-git-send-email-mpa@pengutronix.de>
 <20130728083436.GI2737@pengutronix.de>
Message-ID: <20130728102215.GH16871@s25.your-server.de>

Hi Sascha,

On Sun, Jul 28, 2013 at 10:34:36AM +0200, Sascha Hauer wrote:
> Hi Markus,
> 
> On Sat, Jul 27, 2013 at 05:26:44PM +0200, Markus Pargmann wrote:
> > The imx pinctrl core driver does not support the imx21 register format
> > yet. This patch adds support for the strange iomux control registers of
> > imx21 and imx27. Next to a slightly different DT parse function.
> > 
> > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > ---
> >  drivers/pinctrl/pinctrl-imx.c | 264 +++++++++++++++++++++++++++++++++++++++---
> >  1 file changed, 250 insertions(+), 14 deletions(-)
> 
> Is it really worth sharing the i.MX1/21/27 support with the imx driver?
> It seems most of the code is rewritten. I just tried and removed all
> lines from pinctrl-imx.c you don't use. There's not much left to share.

Yes it's really not that much to share. I will move it to a seperate
file for imx1/21/27.

Thanks,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From daniel.lezcano at linaro.org  Sun Jul 28 06:31:51 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sun, 28 Jul 2013 12:31:51 +0200
Subject: [PATCH] ARM: EXYNOS: cpuidle: Skip C1 cpuidle state for exynos5440
In-Reply-To: <1877730.qZVs3NAG5h@flatron>
References: <0e7d01ce8840$82f79070$88e6b150$@org>
 <0eaf01ce8863$89d3c4e0$9d7b4ea0$@org> <51F4C3D1.2060901@linaro.org>
 <1877730.qZVs3NAG5h@flatron>
Message-ID: <51F4F317.1040001@linaro.org>

On 07/28/2013 11:22 AM, Tomasz Figa wrote:
> On Sunday 28 of July 2013 09:10:09 Daniel Lezcano wrote:
>> On 07/24/2013 01:47 PM, Kukjin Kim wrote:
>>> Amit Daniel Kachhap wrote:
>>>> This patch skips the deep C1(AFTR -Arm off top running) state for
>>>> exynos5440
>>>> soc as this soc does not support this state. All the cpu's only
>>>> allows the basic
>>>> C0 state.
>>>>
>>>> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
>>>> ---
>>>>
>>>>  arch/arm/mach-exynos/cpuidle.c |    2 +-
>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
>>>> exynos/cpuidle.c
>>>> index 17a18ff..9a776a1 100644
>>>> --- a/arch/arm/mach-exynos/cpuidle.c
>>>> +++ b/arch/arm/mach-exynos/cpuidle.c
>>>> @@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void)
>>>>
>>>>  		device->cpu = cpu_id;
>>>>  		
>>>>  		/* Support IDLE only */
>>>>
>>>> -		if (cpu_id != 0)
>>>> +		if (soc_is_exynos5440() || cpu_id != 0)
>>>>
>>>>  			device->state_count = 1;
>>>>  		
>>>>  		ret = cpuidle_register_device(device);
>>>>
>>>> --
>>>> 1.7.1
>>>
>>> Applied, thanks.
>>
>> You shouldn't have. This patch means exynos5540 has no cpuidle driver at
>> all. It should be fixed in the Kconfig to unselect CONFIG_CPU_IDLE for
>> an exynos5540.
> 
> To shed more light on this, let me add that you need to register a cpuidle 
> driver only if you have more states than a simple WFI or you need some 
> crazy steps to enter WFI. Default setup falls back to generic ARM WFI. 
> (Daniel, do we get the nice idle stats as provided by cpuidle core then?)

Nope, but with one state, idle vs busy stats do the trick.

BTW, I am writing a tool to do some stats based on the idle events [1].
It is still at a very early development stage but we can get some
interesting informations.


> Anyway, Exynos cpuidle is using an initcall to initialize and we support 
> multiple Exynos SoCs in single zImage, so deselecting CONFIG_CPU_IDLE is 
> not an option. 

Good point.

> Considering multiplatform requirements, the driver has to 
> be modified to initialize only on supported platforms, either by:
> 
>  a) dropping the initcall and calling the init function directly from 
> arch/arm/mach-exynos
> 
>  or
> 
>  b) checking if machine we are running on is supported, which would mean a 
> long list of all Exynos SoCs that needs to be checked.
> 
> An evolution of option a) is registering a platform device somewhere in 
> arch/arm/mach-exynos and making exynos-cpuidle a platform driver.

Yes, I am favorable to this solution [2].

> The 
> problem is that you must register a static platform device from arch code, 
> because cpuidle is not a real hardware block that can be put into device 
> tree.

Thanks
  -- Daniel

[1] https://git.linaro.org/gitweb?p=people/dlezcano/idlestat.git;a=summary
[2] http://patches.linaro.org/18368/

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From tomasz.figa at gmail.com  Sun Jul 28 06:46:16 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sun, 28 Jul 2013 12:46:16 +0200
Subject: [PATCH] ARM: EXYNOS: cpuidle: Skip C1 cpuidle state for exynos5440
In-Reply-To: <51F4F317.1040001@linaro.org>
References: <0e7d01ce8840$82f79070$88e6b150$@org> <1877730.qZVs3NAG5h@flatron>
 <51F4F317.1040001@linaro.org>
Message-ID: <1449250.PNC13edUOF@flatron>

On Sunday 28 of July 2013 12:31:51 Daniel Lezcano wrote:
> On 07/28/2013 11:22 AM, Tomasz Figa wrote:
> > On Sunday 28 of July 2013 09:10:09 Daniel Lezcano wrote:
> >> On 07/24/2013 01:47 PM, Kukjin Kim wrote:
> >>> Amit Daniel Kachhap wrote:
> >>>> This patch skips the deep C1(AFTR -Arm off top running) state for
> >>>> exynos5440
> >>>> soc as this soc does not support this state. All the cpu's only
> >>>> allows the basic
> >>>> C0 state.
> >>>> 
> >>>> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
> >>>> ---
> >>>> 
> >>>>  arch/arm/mach-exynos/cpuidle.c |    2 +-
> >>>>  1 files changed, 1 insertions(+), 1 deletions(-)
> >>>> 
> >>>> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
> >>>> exynos/cpuidle.c
> >>>> index 17a18ff..9a776a1 100644
> >>>> --- a/arch/arm/mach-exynos/cpuidle.c
> >>>> +++ b/arch/arm/mach-exynos/cpuidle.c
> >>>> @@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void)
> >>>> 
> >>>>  		device->cpu = cpu_id;
> >>>>  		
> >>>>  		/* Support IDLE only */
> >>>> 
> >>>> -		if (cpu_id != 0)
> >>>> +		if (soc_is_exynos5440() || cpu_id != 0)
> >>>> 
> >>>>  			device->state_count = 1;
> >>>>  		
> >>>>  		ret = cpuidle_register_device(device);
> >>>> 
> >>>> --
> >>>> 1.7.1
> >>> 
> >>> Applied, thanks.
> >> 
> >> You shouldn't have. This patch means exynos5540 has no cpuidle driver
> >> at all. It should be fixed in the Kconfig to unselect
> >> CONFIG_CPU_IDLE for an exynos5540.
> > 
> > To shed more light on this, let me add that you need to register a
> > cpuidle driver only if you have more states than a simple WFI or you
> > need some crazy steps to enter WFI. Default setup falls back to
> > generic ARM WFI. (Daniel, do we get the nice idle stats as provided
> > by cpuidle core then?)
> Nope, but with one state, idle vs busy stats do the trick.
> 
> BTW, I am writing a tool to do some stats based on the idle events [1].
> It is still at a very early development stage but we can get some
> interesting informations.

Sounds good.

By the way, a random idea that just came to my mind is that since we 
already support multiple cpuidle drivers, what about providing a default 
cpuidle-wfi driver that gets used in case no other driver is available?

This would give us cpuidle stats at the same place as with other cpuidle 
drivers and might also unify some code paths.

As I said, it's just a random idea, so feel free to redirect it to 
/dev/null.

> > Anyway, Exynos cpuidle is using an initcall to initialize and we
> > support multiple Exynos SoCs in single zImage, so deselecting
> > CONFIG_CPU_IDLE is not an option.
> 
> Good point.
> 
> > Considering multiplatform requirements, the driver has to
> > 
> > be modified to initialize only on supported platforms, either by:
> >  a) dropping the initcall and calling the init function directly from
> > 
> > arch/arm/mach-exynos
> > 
> >  or
> >  
> >  b) checking if machine we are running on is supported, which would
> >  mean a> 
> > long list of all Exynos SoCs that needs to be checked.
> > 
> > An evolution of option a) is registering a platform device somewhere
> > in
> > arch/arm/mach-exynos and making exynos-cpuidle a platform driver.
> 
> Yes, I am favorable to this solution [2].

OK, looks good.

Best regards,
Tomasz



From will.deacon at arm.com  Sun Jul 28 07:10:38 2013
From: will.deacon at arm.com (Will Deacon)
Date: Sun, 28 Jul 2013 12:10:38 +0100
Subject: [PATCH] ARM: v6: avoid read_cpuid_ext() on ARM1136r0 in
 cache_ops_need_broadcast()
In-Reply-To: <alpine.DEB.2.02.1307280538460.8385@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com>
 <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com>
 <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307280538460.8385@utopia.booyaka.com>
Message-ID: <20130728111038.GA9374@mudshark.cambridge.arm.com>

Hi Paul,

Cheers for sticking with this!

On Sun, Jul 28, 2013 at 06:43:24AM +0100, Paul Walmsley wrote:
> 
> Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
> don't flush icache in switch_mm with hardware broadcasting") breaks
> the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
> undefined instruction abort from the CP15 read in
> cache_ops_need_broadcast().  It turns out that early ARM1136 variants
> don't support several CP15 registers that later ARM cores do.
> ARM1136JF-S TRM section 3.2.1 "Register allocation" has the details.

Intriguing... I wouldn't expect a cp15 read to be emitted for 1136, since
the SMP_ON_UP magic should have caused is_smp() to return false.

> diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
> index 6462a72..76214cb 100644
> --- a/arch/arm/include/asm/smp_plat.h
> +++ b/arch/arm/include/asm/smp_plat.h
> @@ -25,7 +25,6 @@ static inline bool is_smp(void)
>  #endif
>  }
>  
> -/* all SMP configurations have the extended CPUID registers */
>  #ifndef CONFIG_MMU
>  #define tlb_ops_need_broadcast()	0
>  #else
> @@ -43,6 +42,9 @@ static inline int tlb_ops_need_broadcast(void)
>  #else
>  static inline int cache_ops_need_broadcast(void)
>  {
> +	if (cpu_is_arm1136_r0())
> +		return 0;
> +
>  	if (!is_smp())
>  		return 0;

So we should have returned 0 here without exploding (this just reads a
.globl initialised in head.S). Are we somehow misidentifying your 1136
as an SMP core?

Will


From broonie at kernel.org  Sun Jul 28 07:27:46 2013
From: broonie at kernel.org (Mark Brown)
Date: Sun, 28 Jul 2013 12:27:46 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130727173748.GA4813@netboy>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726045433.GB4100@netboy>
 <20130726171524.GB28895@obsidianresearch.com>
 <20130727084825.GA4707@netboy>
 <20130727104018.GC9858@sirena.org.uk>
 <20130727173748.GA4813@netboy>
Message-ID: <20130728112746.GM9858@sirena.org.uk>

On Sat, Jul 27, 2013 at 07:37:48PM +0200, Richard Cochran wrote:
> On Sat, Jul 27, 2013 at 11:40:18AM +0100, Mark Brown wrote:

> > We did have exactly the same discussion when the DT transition was
> > started - this isn't something that people only just realised might be
> > an issue.  There was a deliberate decision to focus on getting the
> > technology deployed to the point where it could be used as a straight
> > replacement for board files and accept that sometimes the results won't
> > be perfect and that we may need to rework as a result.

> Can you tell a bit more about this decision? When was it made? Who
> made it? How was it made public?

I honestly can't remember exactly - it was part of the discussion about
keeping the .dtb files in the kernel IIRC.  Given the timing and the
fact that I remember it it'd have been a mailing list discussion but I
couldn't point you at it without searching for a needle in a haystack,
sorry.  Perhaps there's a LWN writeup or something.

It's not the "we don't care" that you're seeing, it's more a product of
"we're not sure what we're doing yet, let's give ourselves a pass if we
mess things up while we're still learning" so it's probably buried in
some thread.
-------------- 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/20130728/4f4a3fe8/attachment.sig>

From linux at arm.linux.org.uk  Sun Jul 28 07:52:20 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sun, 28 Jul 2013 12:52:20 +0100
Subject: [PATCH] ARM: v6: avoid read_cpuid_ext() on ARM1136r0 in
 cache_ops_need_broadcast()
In-Reply-To: <20130728111038.GA9374@mudshark.cambridge.arm.com>
References: <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307280538460.8385@utopia.booyaka.com>
 <20130728111038.GA9374@mudshark.cambridge.arm.com>
Message-ID: <20130728115220.GE21614@n2100.arm.linux.org.uk>

On Sun, Jul 28, 2013 at 12:10:38PM +0100, Will Deacon wrote:
> Hi Paul,
> 
> Cheers for sticking with this!
> 
> On Sun, Jul 28, 2013 at 06:43:24AM +0100, Paul Walmsley wrote:
> > 
> > Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
> > don't flush icache in switch_mm with hardware broadcasting") breaks
> > the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
> > undefined instruction abort from the CP15 read in
> > cache_ops_need_broadcast().  It turns out that early ARM1136 variants
> > don't support several CP15 registers that later ARM cores do.
> > ARM1136JF-S TRM section 3.2.1 "Register allocation" has the details.
> 
> Intriguing... I wouldn't expect a cp15 read to be emitted for 1136, since
> the SMP_ON_UP magic should have caused is_smp() to return false.

The compiler seems to be doing something quite odd with schedule():

00000540 <__schedule>:
 558:   ee103ff1        mrc     15, 0, r3, cr0, cr1, {7}
 560:   e1a03623        lsr     r3, r3, #12
 564:   e203300f        and     r3, r3, #15
 570:   e50b3080        str     r3, [fp, #-128] ; 0x80
...
 6e8:   e59f3428        ldr     r3, [pc, #1064] ; b18 <__schedule+0x5d8>
 6f0:   e5933000        ldr     r3, [r3]
 6f4:   e3530000        cmp     r3, #0
 6f8:   1a000027        bne     79c <__schedule+0x25c>
 6fc:   e2851f65        add     r1, r5, #404    ; 0x194
 700:   ebfffffe        bl      0 <_test_and_set_bit>
                        700: R_ARM_CALL _test_and_set_bit
...
 79c:   e51b1080        ldr     r1, [fp, #-128] ; 0x80
 7a0:   e3510000        cmp     r1, #0
 7a4:   1affffd4        bne     6fc <__schedule+0x1bc>
                        b18: R_ARM_ABS32        smp_on_up

Yes - that's right, it's reading from the mcr at the very start of
__schedule and storing it on the stack for just one test later on.  The
act of storing it on the stack and reading it back of is likely a lot
more expensive than reading it from CP15 in the first place!

We don't want to make the asm() itself volatile, because that means the
asm() statement can't be optimised away.

Adding a memory clobber to that asm seems to place it more appropriately,
but again, that's not particularly desirable.

Another solution would be to make both tlb_ops_need_broadcast and
cache_ops_need_broadcast both be a flag test, but that introduces a
memory load in all those paths no matter if we're running on SMP_ON_UP
or not.


From broonie at kernel.org  Sun Jul 28 08:10:21 2013
From: broonie at kernel.org (Mark Brown)
Date: Sun, 28 Jul 2013 13:10:21 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130727180752.GB4813@netboy>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726045433.GB4100@netboy>
 <20130726171524.GB28895@obsidianresearch.com>
 <20130727085259.GA6207@netboy>
 <20130727113602.GD9858@sirena.org.uk>
 <20130727180752.GB4813@netboy>
Message-ID: <20130728121021.GN9858@sirena.org.uk>

On Sat, Jul 27, 2013 at 08:07:54PM +0200, Richard Cochran wrote:
> On Sat, Jul 27, 2013 at 12:36:02PM +0100, Mark Brown wrote:

> Yes, lets, and remember the question was, why do I say that dealing
> with DT is such a PITA.

There are definite issues with DT (getting a good process for quality
bindings together being the major one, and we're still working on some
of the subsystem bindings) but we shouldn't conflate other things with
those.  What you and others are saying about the need for a stable ABI
for DT is correct but we're going off on tangents here.

My read on what you're saying is that it's more to do with bleeding edge
stuff being painful than it is to do with DT itself; DT gets mentioned a
lot because it is an active area of development and gets used a lot
during bringup but it's not the cause.

> > >   http://www.spinics.net/lists/arm-kernel/msg198431.html

> > This actually sounds pretty good - glancing over the thread it seems you
> > were trying to boot a shiny new board that people were in the process of
> > trying to upstream support for and were just a bit too early.  Device
> > tree doesn't seem to have made a difference either way here.

> Did you miss the part about CONFIG_ARM_APPENDED_DTB?

It didn't seem terribly relevant - it's a feature if people and/or
systems want to use it.

> > >   http://www.spinics.net/lists/linux-omap/msg79731.html

> > Paul's reply here seems fairly clear - someone had merged a driver which
> > had been developed in an out of tree or pre-DT environment without DT
> > support so they just hadn't added DT support.  Sadly doing that is new
> > feature development and so not appropriate for the stabalisation phase
> > of development.

> This is me asking for maintainers to take patches to fix a driver in
> version v3.7 where the driver merged in v3.4. 

> The patches contain the missing DT part, and the maintainer rejects
> them, saying, no new features!

> Q: What the heck kind of process is that?
> A: DT process.

No, this is nothing to do with DT - this is just the general kernel
development process.  DT was a new feature for that driver (which
would've been merged a year or so before we got our first DT only ARM
platform...), it's unfortunate that you needed it for your system since
it was a DT only system but it's still a new feature with respect to the
driver.

> Seriously, why is it too hard for y'all to insist on merging drivers
> only when they are really, truly ready (and don't forget the DT part,
> please).

There's a couple of things there.  One is that subsystem maintainers
have no real way of telling if a driver actually works unless they
happen to have a system they can test it on.  For the most part that's
just not the case so we have to trust that someone will say something if
there's a problem.  We can spot some problems through review but there's
a huge set that just won't be obvious without knowledge of the hardware.

The other is that a partially featured driver in the kernel tends to be
a better thing for development than something out of tree - if it's
useful for someone that's great and it provides a starting point for
someone else to come along and add more features.  So long as it's not
causing problems at a subsystem level it's generally better to have it
than not, that way other people can come along and incrementally improve
the driver without having to work out some way of collaborating out of
tree.

You mention DT specifically here - obviously a lot of platforms don't
require DT (only some architectures use it at all) so it can't be a
requirement for drivers and if someone's done the work to get the
hardware working it seems more useful to get that merged and then let
someone who cares about DT add the bindings later.

> > > * When people try in good faith to conduct methodical boot tests,
> > >   DT is working against them.

> > >   http://www.spinics.net/lists/linux-omap/msg79960.html

> > Again I don't see anything particularly related to DT here but instead
> > do with using a SoC and board that are in the early phases of mainline
> > integration.

> It is ring around the rosie, DT, boot loader, and kernel.

> Understandably, Paul doesn't want to upgrade his boot loader. He says
> he is "not interested" in testing the boot loader, just the kernel.
> And, if you follow the sage of Paul's test reports, you will find him
> being told to update his boot loader and not to forget the delete old
> dtb files.

> So, like I said, it is a pity PITA.

New systems especially those using new SoCs generally are a pain; had
the issues not mentioned DT they might well have been something else
like missing pinmux in the bootloader, some bit of kernel functionality
not being merged yet or something else.  The flow of discussion there
looks very familiar to me from way before DT was talked about for ARM -
it reminds me a bit of some work I did before even PowerPC adopted DT!
-------------- 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/20130728/59f819a2/attachment-0001.sig>

From linux at arm.linux.org.uk  Sun Jul 28 08:13:00 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sun, 28 Jul 2013 13:13:00 +0100
Subject: [PATCH v2] pinctrl: shut up a couple of pinctrl warnings
In-Reply-To: <20130727103811.GD24642@n2100.arm.linux.org.uk>
References: <20130727103811.GD24642@n2100.arm.linux.org.uk>
Message-ID: <20130728121300.GF24642@n2100.arm.linux.org.uk>

So, I notice that we get a couple of warnings from the pinctrl code:

drivers/pinctrl/pinconf.c: In function 'pinconf_dbg_config_print':
drivers/pinctrl/pinconf.c:433:36: warning: 'configs' may be used uninitialized in this function
drivers/pinctrl/pinconf.c: In function 'pinconf_dbg_config_write':
drivers/pinctrl/pinconf.c:511:36: warning: 'configs' may be used uninitialized in this function

While the compiler might not be able to work out that "configs" is
safe, the code doesn't lend itself very well to identifying that
fact when reading it either.  This can be trivially solved by a slight
restructuring of the code - which also reduces the LOC.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
So last nights build test found a silly in the last patch, so that's fixed
in this version.

 drivers/pinctrl/pinconf.c |   29 +++++++++++------------------
 1 files changed, 11 insertions(+), 18 deletions(-)

diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index e875f21..d16ef87 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -428,12 +428,11 @@ static int pinconf_dbg_config_print(struct seq_file *s, void *d)
 {
 	struct pinctrl_maps *maps_node;
 	const struct pinctrl_map *map;
-	struct pinctrl_dev *pctldev = NULL;
+	const struct pinctrl_map *found = NULL;
+	struct pinctrl_dev *pctldev;
 	const struct pinconf_ops *confops = NULL;
-	const struct pinctrl_map_configs *configs;
 	struct dbg_cfg *dbg = &pinconf_dbg_conf;
 	int i, j;
-	bool found = false;
 	unsigned long config;
 
 	mutex_lock(&pinctrl_maps_mutex);
@@ -450,14 +449,8 @@ static int pinconf_dbg_config_print(struct seq_file *s, void *d)
 		for (j = 0; j < map->data.configs.num_configs; j++) {
 			if (!strcmp(map->data.configs.group_or_pin,
 					dbg->pin_name)) {
-				/*
-				 * We found the right pin / state, read the
-				 * config and he pctldev for later use
-				 */
-				configs = &map->data.configs;
-				pctldev = get_pinctrl_dev_from_devname
-					(map->ctrl_dev_name);
-				found = true;
+				/* We found the right pin / state */
+				found = map;
 				break;
 			}
 		}
@@ -473,7 +466,8 @@ static int pinconf_dbg_config_print(struct seq_file *s, void *d)
 		goto exit;
 	}
 
-	config = *(configs->configs);
+	pctldev = get_pinctrl_dev_from_devname(found->ctrl_dev_name);
+	config = *found->data.configs.configs;
 	seq_printf(s, "Dev %s has config of %s in state %s: 0x%08lX\n",
 			dbg->dev_name, dbg->pin_name,
 			dbg->state_name, config);
@@ -505,12 +499,12 @@ static int pinconf_dbg_config_write(struct file *file,
 {
 	struct pinctrl_maps *maps_node;
 	const struct pinctrl_map *map;
-	struct pinctrl_dev *pctldev = NULL;
+	const struct pinctrl_map *found = NULL;
+	struct pinctrl_dev *pctldev;
 	const struct pinconf_ops *confops = NULL;
 	struct dbg_cfg *dbg = &pinconf_dbg_conf;
 	const struct pinctrl_map_configs *configs;
 	char config[MAX_NAME_LEN+1];
-	bool found = false;
 	char buf[128];
 	char *b = &buf[0];
 	int buf_size;
@@ -588,10 +582,7 @@ static int pinconf_dbg_config_write(struct file *file,
 
 		/*  we found the right pin / state, so overwrite config */
 		if (!strcmp(map->data.configs.group_or_pin, dbg->pin_name)) {
-			found = true;
-			pctldev = get_pinctrl_dev_from_devname(
-					map->ctrl_dev_name);
-			configs = &map->data.configs;
+			found = map;
 			break;
 		}
 	}
@@ -601,10 +592,12 @@ static int pinconf_dbg_config_write(struct file *file,
 		goto exit;
 	}
 
+	pctldev = get_pinctrl_dev_from_devname(found->ctrl_dev_name);
 	if (pctldev)
 		confops = pctldev->desc->confops;
 
 	if (confops && confops->pin_config_dbg_parse_modify) {
+		configs = &found->data.configs;
 		for (i = 0; i < configs->num_configs; i++) {
 			confops->pin_config_dbg_parse_modify(pctldev,
 						     config,


From broonie at kernel.org  Sun Jul 28 08:22:46 2013
From: broonie at kernel.org (Mark Brown)
Date: Sun, 28 Jul 2013 13:22:46 +0100
Subject: [PATCH v4 00/20] Samsung PWM support cleanup
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <20130728122246.GP9858@sirena.org.uk>

On Sat, Jul 20, 2013 at 02:04:12AM +0200, Tomasz Figa wrote:

> [Also not sure on what boards, but still]
> Tested-by: Mark Brown <broonie at linaro.org>

Just retested this (on Cragganmore), still works fine.
-------------- 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/20130728/2ccd1f43/attachment.sig>

From broonie at kernel.org  Sun Jul 28 08:30:51 2013
From: broonie at kernel.org (Mark Brown)
Date: Sun, 28 Jul 2013 13:30:51 +0100
Subject: [PATCH v3 2/8] clk: samsung: pll: Add support for PLL6552 and
 PLL6553
In-Reply-To: <11551938.yDBcNngaZN@flatron>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
 <1374536965-3545-3-git-send-email-tomasz.figa@gmail.com>
 <11551938.yDBcNngaZN@flatron>
Message-ID: <20130728123051.GQ9858@sirena.org.uk>

On Wed, Jul 24, 2013 at 01:52:19AM +0200, Tomasz Figa wrote:

> Changes since v2:
>  - Reworked to use new PLL registration method introduced by Yadwinder
>    Singh Brar's patch series:
>    ( http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20041 )

I'm not able to test this series since that lot isn't in -next and I
didn't get a copy.
-------------- 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/20130728/64e1aef9/attachment.sig>

From broonie at kernel.org  Sun Jul 28 08:32:30 2013
From: broonie at kernel.org (Mark Brown)
Date: Sun, 28 Jul 2013 13:32:30 +0100
Subject: [PATCH v2 5/8] ARM: s3c64xx: dma: Use
 clk_prepare_enable/clk_disable_unprepare
In-Reply-To: <1374536965-3545-6-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
 <1374536965-3545-6-git-send-email-tomasz.figa@gmail.com>
Message-ID: <20130728123230.GR9858@sirena.org.uk>

On Tue, Jul 23, 2013 at 01:49:22AM +0200, Tomasz Figa wrote:
> This patch modifies s3c64xx DMA driver to prepare and unprepare clocks
> in addition to enableind and disabling, since it is required by common
> clock framework.

Tested-by: Mark Brown <broonie at linaro.org>
-------------- 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/20130728/b997499b/attachment.sig>

From tomasz.figa at gmail.com  Sun Jul 28 08:38:25 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sun, 28 Jul 2013 14:38:25 +0200
Subject: [PATCH v3 2/8] clk: samsung: pll: Add support for PLL6552 and
 PLL6553
In-Reply-To: <20130728123051.GQ9858@sirena.org.uk>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
 <11551938.yDBcNngaZN@flatron> <20130728123051.GQ9858@sirena.org.uk>
Message-ID: <3758744.oOA9YxCvpA@flatron>

On Sunday 28 of July 2013 13:30:51 Mark Brown wrote:
> On Wed, Jul 24, 2013 at 01:52:19AM +0200, Tomasz Figa wrote:
> > Changes since v2:
> >  - Reworked to use new PLL registration method introduced by Yadwinder
> >  
> >    Singh Brar's patch series:
> >    ( http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20041 )
> 
> I'm not able to test this series since that lot isn't in -next and I
> didn't get a copy.

Hmm, I wonder what happened with that series, as Mike was supposed to
try applying it to clk tree [1].

Mike, could you shed some light on this?

Best regards,
Tomasz

[1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20041/focus=21003



From richardcochran at gmail.com  Sun Jul 28 09:19:03 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Sun, 28 Jul 2013 15:19:03 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <1416484.XDfk5G56BI@flatron>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1441731.8CGUI1tUxh@flatron> <20130728085650.GA4683@netboy>
 <1416484.XDfk5G56BI@flatron>
Message-ID: <20130728131901.GA8864@netboy>

On Sun, Jul 28, 2013 at 11:12:53AM +0200, Tomasz Figa wrote:

> I'm not really sure what effect on users this has. Maybe you should define 
> "users".

...

> Care to explain this reasoning?

Use Case
~~~~~~~~

User acquires a machine running ARM Linux version 3.x, with u-boot
and dtb in a read only flash partition. The board boots and works just
fine. However, for his application, the user requires a new kernel
feature that appeared in version 3.y where y > x. He compiles the new
kernel, and it also works.

Thanks,
Richard





From pavel at ucw.cz  Sun Jul 28 09:37:29 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Sun, 28 Jul 2013 15:37:29 +0200
Subject: N900 device tree conversion: how to do first step
In-Reply-To: <20130719181416.GA1204@earth.universe>
References: <20130609015944.GA23559@amd.pavel.ucw.cz>
 <20130719181416.GA1204@earth.universe>
Message-ID: <20130728133728.GA5382@amd.pavel.ucw.cz>

Hi!

> > I'd like to convert Nokia N900 to device tree.
> > 
> > Unfortunately, serial port is not easily available (very special cable
> > would be needed, does someone know where to get one?)
> 
> One way to get one is building it yourself. I finished mine yesterday:
> 
> http://elektranox.org/n900/adapter/index.html

Nice but a bit above my hardware hacking skills. For now, I'm using
automated scripts to run qemu... (They are available at 

http://tui.cvs.sourceforge.net/viewvc/tui/tui/auto/

). They should allow automated testing for regressions and automatic
bisect.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From tomasz.figa at gmail.com  Sun Jul 28 09:39:56 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Sun, 28 Jul 2013 15:39:56 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130728131901.GA8864@netboy>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1416484.XDfk5G56BI@flatron> <20130728131901.GA8864@netboy>
Message-ID: <2529481.u8xHuXumcd@flatron>

On Sunday 28 of July 2013 15:19:03 Richard Cochran wrote:
> On Sun, Jul 28, 2013 at 11:12:53AM +0200, Tomasz Figa wrote:
> > I'm not really sure what effect on users this has. Maybe you should
> > define "users".
> 
> ...
> 
> > Care to explain this reasoning?
> 
> Use Case
> ~~~~~~~~
> 
> User acquires a machine running ARM Linux version 3.x, with u-boot
> and dtb in a read only flash partition. The board boots and works just
> fine. However, for his application, the user requires a new kernel
> feature that appeared in version 3.y where y > x. He compiles the new
> kernel, and it also works.

Generally the user does not care where the dtb is stored. He just want to 
upgrade the kernel without thinking about internals.

There are many possible options:

a) The BSP packaging script he received from board vendor, or even kernel 
build system, builds dtb from kernel sources and appends it to built 
zImage. He just flashes the zImage and everything is working correctly.

  This is pretty common case today, as many boards still use legacy 
  bootloaders without native support for DT. See the analogy to board 
  files, being compiled as a part of kernel sources.

b) The user always compiles the kernel and dtb and flashes both at the 
same time.

  This does not differ at all to flashing the kernel alone, except two 
  files, not one, need to be flashed.

By the way, in use case you are describing, changes that dtb wouldn't have 
to be updated are very low, unless the one present in read only memory of 
the board is complete, i.e. fully describes all the available hardware, 
which is unlikely for a dtb built at time of 3.x availability, whenever 
the feature showed up in 3.y (y > x). The user will most likely have to 
update the dtb anyway.

Please note, though, I'm _not_ trying to convince you that this kind of 
solutions is good, as I'm not convinced either. That's why we are 
discussing this.

Best regards,
Tomasz



From pavel at ucw.cz  Sun Jul 28 09:44:09 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Sun, 28 Jul 2013 15:44:09 +0200
Subject: [PATCH v2] N900: add device tree
In-Reply-To: <20130714222819.GB3296@blackmetal.musicnaut.iki.fi>
References: <20130613230808.GA14876@amd.pavel.ucw.cz>
 <20130614055629.GM8164@atomide.com>
 <20130614212816.GA31768@atrey.karlin.mff.cuni.cz>
 <20130617111031.GQ20992@atomide.com>
 <20130701211753.GC15318@amd.pavel.ucw.cz>
 <20130704171939.GA27374@blackmetal.musicnaut.iki.fi>
 <20130704202145.GB10752@amd.pavel.ucw.cz>
 <20130704203256.GB27374@blackmetal.musicnaut.iki.fi>
 <20130713121709.GC16473@amd.pavel.ucw.cz>
 <20130714222819.GB3296@blackmetal.musicnaut.iki.fi>
Message-ID: <20130728134409.GB5382@amd.pavel.ucw.cz>

On Mon 2013-07-15 01:28:19, Aaro Koskinen wrote:
> Hi,
> 
> On Sat, Jul 13, 2013 at 02:17:09PM +0200, Pavel Machek wrote:
> > 
> > This adds device tree with neccessary support to boot with functional
> > video (on both emulator and real N900 device).
> > 
> > Signed-off-by: Pavel Machek <pavel at ucw.cz>
> 
> You can also add:
> 
> Signed-off-by: Aaro Koskinen <aaro.koskinen at iki.fi>

Benoit, could you apply this? Tony said you are doing dts changes, and
the patch seems to be ready.

> > From v1: Aaro wants just GPLv2, so I did that. I re-enabled parts that
> > can be enabled on 3.10, and tested it on that kernel.
> > 
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index f0895c5..1950aed 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -141,6 +141,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
> >  	omap3-devkit8000.dtb \
> >  	omap3-beagle-xm.dtb \
> >  	omap3-evm.dtb \
> > +	omap3-n900.dtb \
> >  	omap3-tobi.dtb \
> >  	omap3-igep0020.dtb \
> >  	omap3-igep0030.dtb \
> > diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> > new file mode 100644
> > index 0000000..fb461bf
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > @@ -0,0 +1,92 @@
> > +/*
> > + * Copyright (C) 2013 Pavel Machek <pavel at ucw.cz>
> > + * Copyright 2013 Aaro Koskinen <aaro.koskinen at iki.fi>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +/include/ "omap34xx.dtsi"
> > +
> > +/ {
> > +	model = "Nokia N900";
> > +	compatible = "nokia,omap3-n900", "ti,omap3";
> > +
> > +	cpus {
> > +		cpu at 0 {
> > +			cpu0-supply = <&vcc>;
> > +		};
> > +	};
> > +
> > +	memory {
> > +		device_type = "memory";
> > +		reg = <0x80000000 0x10000000>; /* 256 MB */
> > +	};
> > +
> > +};
> > +
> > +&i2c1 {
> > +	clock-frequency = <2200000>;
> > +
> > +	twl: twl at 48 {
> > +		reg = <0x48>;
> > +		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> > +		interrupt-parent = <&intc>;
> > +	};
> > +};
> > +
> > +/include/ "twl4030.dtsi"
> > +
> > +&twl_gpio {
> > +	ti,pullups	= <0x0>;
> > +	ti,pulldowns	= <0x03ff3f>; /* BIT(0..5) | BIT(8..17) */
> > +};
> > +
> > +&i2c2 {
> > +	clock-frequency = <400000>;
> > +};
> > +
> > +&i2c3 {
> > +	clock-frequency = <100000>;
> > +};
> > +
> > +&mmc1 {
> > +	status = "disabled";
> > +};
> > +
> > +&mmc2 {
> > +	status = "disabled";
> > +};
> > +
> > +&mmc3 {
> > +	status = "disabled";
> > +};
> > +
> > +&mcspi1 {
> > +	// For some reason, touchscreen is neccessary for screen to work at 
> > +	// all on real hw. It works well without it on emulator.
> > +	//
> > +	// Also... order in the device tree actually matters here.
> > +	tsc2005 at 0 {
> > +		compatible = "tsc2005";
> > +		spi-max-frequency = <6000000>;
> > +		reg = <0>;
> > +	};
> > +	mipid at 2 {
> > +		compatible = "acx565akm";
> > +		spi-max-frequency = <6000000>;
> > +		reg = <2>;
> > +		// turbo_mode = 0,
> > +		// cs_per_word = 0
> > +	};
> > +};
> > +
> > +&usb_otg_hs {
> > +	interface-type = <0>;
> > +	usb-phy = <&usb2_phy>;
> > +	mode = <2>;
> > +	power = <50>;
> > +};
> > 
> > -- 
> > (english) http://www.livejournal.com/~pavelmachek
> > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From jonsmirl at gmail.com  Sun Jul 28 10:09:57 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Sun, 28 Jul 2013 10:09:57 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <2529481.u8xHuXumcd@flatron>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1416484.XDfk5G56BI@flatron> <20130728131901.GA8864@netboy>
 <2529481.u8xHuXumcd@flatron>
Message-ID: <CAKON4OzReTRb5JnJE+07vNJ-uDndLfqq8ha04J7K3x=WtsZEWw@mail.gmail.com>

On Sun, Jul 28, 2013 at 9:39 AM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> On Sunday 28 of July 2013 15:19:03 Richard Cochran wrote:
>> On Sun, Jul 28, 2013 at 11:12:53AM +0200, Tomasz Figa wrote:
>> > I'm not really sure what effect on users this has. Maybe you should
>> > define "users".
>>
>> ...
>>
>> > Care to explain this reasoning?
>>
>> Use Case
>> ~~~~~~~~
>>
>> User acquires a machine running ARM Linux version 3.x, with u-boot
>> and dtb in a read only flash partition. The board boots and works just
>> fine. However, for his application, the user requires a new kernel
>> feature that appeared in version 3.y where y > x. He compiles the new
>> kernel, and it also works.
>
> Generally the user does not care where the dtb is stored. He just want to
> upgrade the kernel without thinking about internals.
>
> There are many possible options:
>
> a) The BSP packaging script he received from board vendor, or even kernel
> build system, builds dtb from kernel sources and appends it to built
> zImage. He just flashes the zImage and everything is working correctly.
>
>   This is pretty common case today, as many boards still use legacy
>   bootloaders without native support for DT. See the analogy to board
>   files, being compiled as a part of kernel sources.
>
> b) The user always compiles the kernel and dtb and flashes both at the
> same time.
>
>   This does not differ at all to flashing the kernel alone, except two
>   files, not one, need to be flashed.

c) Use a quirk system to map ROM based DTB's.

3.x kernel was matched to dtb that is flashed into boot rom.
Everything was initially ok.

The 3.y kernel is built with init time quirks that map the dtb from
3.x format  into the 3.y format. These quirks can be easily built
since we know the generic schema from both 3.x and 3.y. Mapping ten
year old power PC dtbs may involve more code.

These quirks aren't going to be large, it's not like the entire schema
is going to change on each kernel release.  They are just going to
make a best effort to map the dtb in ROM into something the 3.y kernel
can understand. Owners of these ROMs will complain loudly if the
quirks aren't right.

3.z kernel is free to alter the schema. But it will have to supply the
necessary quirks needed to keep those old dtb's functioning.

>
> By the way, in use case you are describing, changes that dtb wouldn't have
> to be updated are very low, unless the one present in read only memory of
> the board is complete, i.e. fully describes all the available hardware,
> which is unlikely for a dtb built at time of 3.x availability, whenever
> the feature showed up in 3.y (y > x). The user will most likely have to
> update the dtb anyway.
>
> Please note, though, I'm _not_ trying to convince you that this kind of
> solutions is good, as I'm not convinced either. That's why we are
> discussing this.
>
> Best regards,
> Tomasz
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Jon Smirl
jonsmirl at gmail.com


From thomas.petazzoni at free-electrons.com  Sun Jul 28 10:27:11 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Sun, 28 Jul 2013 16:27:11 +0200
Subject: [PATCHv5 05/11] of: pci: add registry of MSI chips
In-Reply-To: <20130728043310.6CF1D3E08FE@localhost>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E41F7A.4010502@gmail.com> <20130728043310.6CF1D3E08FE@localhost>
Message-ID: <20130728162711.32a9a21e@skate>

Dear Grant Likely,

Thanks for your feedback! Some comments below.

On Sat, 27 Jul 2013 22:33:10 -0600, Grant Likely wrote:

> > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > 
> > Acked-by: Rob Herring <rob.herring at calxeda.com>
> 
> Actually, I'm going to disagree on this one and say NAK. I don't think
> it is a good idea to create a completely separate registry of msi_chips
> for binding to dt nodes. I think it would be better to include the
> msi_chip pointer directly into the irq_domain which has to be there
> anyway. It then becomes another feature for irq controllers if it can
> support doing MSI.

The problem that this patch tries to solve is how can the PCIe driver
work get a pointer to the msi_chip structure from the DT device node
pointed to by the 'msi-parent' property. I.e, we have:

	interrupt-parent = <&mpic>;

	mpic {
		reg = <...>;
		compatible = "...";
		interrupt-controller;
		msi-controller;
	};

	pcie-controller {
		msi-parent = <&mpic>;
	};

The 'mpic' driver registers two irq_domains, one for the "normal"
interrupts, and one for the MSI interrupts. Both irq_domain cannot be
associated to the same &mpic node, or the irq_domain lookup for
interrupt-parent and msi-parent is going to be confused.

In the very first version of this patch set, I was using two separate
DT device nodes to avoid this problem:

	interrupt-parent = <&mpic>;

	interrupt-controller {
		reg = <...>;
		compatible = "...";

		mpic {
			interrupt-controller;
		};

		msi {
			msi-controller;
		};
	};

	pcie-controller {
		msi-parent = <&msi>;
	};

This way, each of the two irq_domain was associated to a distinct DT
device node, and everything was working fine. But during the review, I
was pointed by Arnd that it wasn't the proper way of describing the
interrupt controller, and that there should be only one DT device node
having both the interrupt-controller and msi-controller roles.

So what is your suggestion to allow the PCIe controller to retrieve the
correct irq_domain if we have only one DT node for the IRQ controller
that registers two irq_domains ?

See:

   [RFCv1 00/11] MSI support for Marvell EBU PCIe driver
   https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-March/030578.html

and particularly:

   [RFCv1 07/11] irqchip: armada-370-xp: add MSI support to interrupt
   controller driver
   https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-March/030584.html

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From richardcochran at gmail.com  Sun Jul 28 11:30:32 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Sun, 28 Jul 2013 17:30:32 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <2529481.u8xHuXumcd@flatron>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1416484.XDfk5G56BI@flatron> <20130728131901.GA8864@netboy>
 <2529481.u8xHuXumcd@flatron>
Message-ID: <20130728153031.GA5224@netboy>

On Sun, Jul 28, 2013 at 03:39:56PM +0200, Tomasz Figa wrote:
 
> There are many possible options:

...

Wow, you totally ignored the use case.

> Please note, though, I'm _not_ trying to convince you that this kind of 
> solutions is good, as I'm not convinced either. That's why we are 
> discussing this.

And next you are going to convince me that updating my BIOS is a
normal, expected, and necessary step in upgrading my kernel.

No, thank you.

Richard


From richardcochran at gmail.com  Sun Jul 28 11:35:46 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Sun, 28 Jul 2013 17:35:46 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <CAKON4OzReTRb5JnJE+07vNJ-uDndLfqq8ha04J7K3x=WtsZEWw@mail.gmail.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1416484.XDfk5G56BI@flatron> <20130728131901.GA8864@netboy>
 <2529481.u8xHuXumcd@flatron>
 <CAKON4OzReTRb5JnJE+07vNJ-uDndLfqq8ha04J7K3x=WtsZEWw@mail.gmail.com>
Message-ID: <20130728153546.GB5224@netboy>

On Sun, Jul 28, 2013 at 10:09:57AM -0400, jonsmirl at gmail.com wrote:
> 
> 3.z kernel is free to alter the schema. But it will have to supply the
> necessary quirks needed to keep those old dtb's functioning.

The quirks idea sounds okay to me, if it can really provide forward
compatibility. In practice, I doubt anyone will really spend the
effort to make this work. I think it would be much easier to make sure
the bindings are "future proof" in the first place.

Thanks,
Richard


From jonsmirl at gmail.com  Sun Jul 28 11:50:19 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Sun, 28 Jul 2013 11:50:19 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130728153546.GB5224@netboy>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1416484.XDfk5G56BI@flatron> <20130728131901.GA8864@netboy>
 <2529481.u8xHuXumcd@flatron>
 <CAKON4OzReTRb5JnJE+07vNJ-uDndLfqq8ha04J7K3x=WtsZEWw@mail.gmail.com>
 <20130728153546.GB5224@netboy>
Message-ID: <CAKON4OzQ8BYuP00L6Ugt-tAteTdqqh58YuMfZCWQPirkGf9XMA@mail.gmail.com>

On Sun, Jul 28, 2013 at 11:35 AM, Richard Cochran
<richardcochran at gmail.com> wrote:
> On Sun, Jul 28, 2013 at 10:09:57AM -0400, jonsmirl at gmail.com wrote:
>>
>> 3.z kernel is free to alter the schema. But it will have to supply the
>> necessary quirks needed to keep those old dtb's functioning.
>
> The quirks idea sounds okay to me, if it can really provide forward
> compatibility. In practice, I doubt anyone will really spend the
> effort to make this work. I think it would be much easier to make sure
> the bindings are "future proof" in the first place.

"furture proof" is much easier to say that it is to do. We've been
messing around with the audio bindings for three years and still don't
have a really good scheme. It is pretty easy to come up with the first
90% of a device tree. It is really hard to work out that last 10%.

You can easily get the chips into the tree. Doing that will load the
correct device drivers. But now how are these chips wired together? Is
the appropriate button, LED, etc attached to all the IO pins offered
by the chip? Those answers vary by the PCB the chip was used in..
Trying to figure out a scheme for this has lead to some volatility in
the device trees.  The whole concept of pin mapping was missing from
the early device trees.


>
> Thanks,
> Richard



-- 
Jon Smirl
jonsmirl at gmail.com


From broonie at kernel.org  Sun Jul 28 13:41:27 2013
From: broonie at kernel.org (Mark Brown)
Date: Sun, 28 Jul 2013 18:41:27 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <CAKON4OzQ8BYuP00L6Ugt-tAteTdqqh58YuMfZCWQPirkGf9XMA@mail.gmail.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1416484.XDfk5G56BI@flatron> <20130728131901.GA8864@netboy>
 <2529481.u8xHuXumcd@flatron>
 <CAKON4OzReTRb5JnJE+07vNJ-uDndLfqq8ha04J7K3x=WtsZEWw@mail.gmail.com>
 <20130728153546.GB5224@netboy>
 <CAKON4OzQ8BYuP00L6Ugt-tAteTdqqh58YuMfZCWQPirkGf9XMA@mail.gmail.com>
Message-ID: <20130728174127.GB9858@sirena.org.uk>

On Sun, Jul 28, 2013 at 11:50:19AM -0400, jonsmirl at gmail.com wrote:

> "furture proof" is much easier to say that it is to do. We've been
> messing around with the audio bindings for three years and still don't
> have a really good scheme. It is pretty easy to come up with the first
> 90% of a device tree. It is really hard to work out that last 10%.

I wouldn't say that for audio - we've got a pretty solid idea of what's
going on and little if any churn.  If some more of the subsystems that
we rely on were working well we could do a bit more but it's mostly just
extensions of where we're at now.
-------------- 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/20130728/4fb8f828/attachment.sig>

From broonie at kernel.org  Sun Jul 28 14:41:11 2013
From: broonie at kernel.org (Mark Brown)
Date: Sun, 28 Jul 2013 19:41:11 +0100
Subject: [PATCH v2 4/4] spi:Add Freescale DSPI driver for Vybrid VF610
 platform
In-Reply-To: <20130726072130.GA3029@pengutronix.de>
References: <1374643943-3324-1-git-send-email-b44548@freescale.com>
 <1374643943-3324-5-git-send-email-b44548@freescale.com>
 <20130726072130.GA3029@pengutronix.de>
Message-ID: <20130728184111.GG9858@sirena.org.uk>

On Fri, Jul 26, 2013 at 09:21:30AM +0200, Sascha Hauer wrote:
> On Wed, Jul 24, 2013 at 01:32:23PM +0800, Chao Fu wrote:

Sascha, please delete unneeded context from your mails - it makes it
much easier to find the new text.

> > +	tx_word = is_word_transfer(dspi);
> > +	/* If we are in word mode, but only have a single byte to transfer
> > +	 * then switch to byte mode temporarily.  Will switch back at the
> > +	 * end of the transfer. */

> Not sure if I understand this, but if you are in word mode then I would
> consider it a bug when there's only one byte to transfer.

Yes, this is a definite bug - especially since SPI in word mode has a
fixed word order on the bus.  The driver should never put the hardware
into a word size other than that explicitly requested by the client and
then it should insist on getting exact multiples of that word size.

> > +static int dspi_prepare_transfer_hw(struct spi_master *master)
> > +{
> > +	struct fsl_dspi *dspi = spi_master_get_devdata(master);
> > +
> > +	pm_runtime_get_sync(&dspi->pdev->dev);
> > +
> > +	return 0;
> > +}

I just posted a patch series which would allow you to have the core do
this for you, please rebase on top of that.
-------------- 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/20130728/fb3f560b/attachment.sig>

From linux at prisktech.co.nz  Sun Jul 28 14:53:33 2013
From: linux at prisktech.co.nz (Tony Prisk)
Date: Mon, 29 Jul 2013 06:53:33 +1200
Subject: Board-specific GPIO setup code
Message-ID: <51F568AD.8030001@prisktech.co.nz>

On the Wandboard (IMX6Q SoC), there is a WiFi module connected via SDIO 
that requires a reset procedure to enable it. This would be board 
specific setup, but gpio_* functions can't be used in 
arch/arm/mach-imx/imx6q.c

What would be the correct place to perform the reset code (basically a 
series of gpio calls) to reset the WiFi controller or should it be done 
earlier in uboot?

Regards
Tony Prisk


From paul at pwsan.com  Sun Jul 28 15:47:15 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Sun, 28 Jul 2013 19:47:15 +0000 (UTC)
Subject: [PATCH] ARM: v6: avoid read_cpuid_ext() on ARM1136r0 in
 cache_ops_need_broadcast()
In-Reply-To: <20130728111038.GA9374@mudshark.cambridge.arm.com>
References: <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com>
 <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307280538460.8385@utopia.booyaka.com>
 <20130728111038.GA9374@mudshark.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1307281945530.23852@utopia.booyaka.com>

Hi Will

On Sun, 28 Jul 2013, Will Deacon wrote:

> On Sun, Jul 28, 2013 at 06:43:24AM +0100, Paul Walmsley wrote:
> > 
> > Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
> > don't flush icache in switch_mm with hardware broadcasting") breaks
> > the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
> > undefined instruction abort from the CP15 read in
> > cache_ops_need_broadcast().  It turns out that early ARM1136 variants
> > don't support several CP15 registers that later ARM cores do.
> > ARM1136JF-S TRM section 3.2.1 "Register allocation" has the details.
> 
> Intriguing... I wouldn't expect a cp15 read to be emitted for 1136, since
> the SMP_ON_UP magic should have caused is_smp() to return false.
> 

...

> So we should have returned 0 here without exploding (this just reads a
> .globl initialised in head.S). Are we somehow misidentifying your 1136
> as an SMP core?

You're right - the is_arm1136_r0() logic is completely unnecessary - it's 
just the 'asm volatile' that makes the difference.

- Paul


From paul at pwsan.com  Sun Jul 28 15:56:32 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Sun, 28 Jul 2013 19:56:32 +0000 (UTC)
Subject: [PATCH] ARM: v6: avoid read_cpuid_ext() on ARM1136r0 in
 cache_ops_need_broadcast()
In-Reply-To: <20130728115220.GE21614@n2100.arm.linux.org.uk>
References: <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307280538460.8385@utopia.booyaka.com>
 <20130728111038.GA9374@mudshark.cambridge.arm.com>
 <20130728115220.GE21614@n2100.arm.linux.org.uk>
Message-ID: <alpine.DEB.2.02.1307281947190.23852@utopia.booyaka.com>

On Sun, 28 Jul 2013, Russell King - ARM Linux wrote:

> We don't want to make the asm() itself volatile, because that means the 
> asm() statement can't be optimised away.
> 
> Adding a memory clobber to that asm seems to place it more appropriately,
> but again, that's not particularly desirable.
> 
> Another solution would be to make both tlb_ops_need_broadcast and
> cache_ops_need_broadcast both be a flag test, but that introduces a
> memory load in all those paths no matter if we're running on SMP_ON_UP
> or not.

I considered adding a HWCAP_* bit under the theory that elf_hwcap may 
already be cache-resident.  But thought that the loss of the flag space 
and possible memory access vs. the additional mrc wasn't worth it.

Anyway, if either of you have a preference between these three, I'd be 
happy to update the patch.  Or feel free to take it over from here if 
either of you prefer.


- Paul


From paul at pwsan.com  Sun Jul 28 15:58:08 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Sun, 28 Jul 2013 19:58:08 +0000 (UTC)
Subject: [PATCH v2] ARM: v6: avoid remaining accesses to missing CP15
 registers on ARM1136 r0
In-Reply-To: <alpine.DEB.2.02.1307280559330.8385@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307280527430.8385@utopia.booyaka.com>
 <alpine.DEB.2.02.1307280543370.8385@utopia.booyaka.com>
 <alpine.DEB.2.02.1307280559330.8385@utopia.booyaka.com>
Message-ID: <alpine.DEB.2.02.1307281956420.23852@utopia.booyaka.com>

On Sun, 28 Jul 2013, Paul Walmsley wrote:

> Ensure that the remaining callers of read_cpuid_ext can't attempt an 
> extended CP15 register read on ARMv6 cores that don't support it.  The 
> only one that appears dodgy is tlb_ops_need_broadcast().
> 
> While here, convert feat_v6_fixup() to use cpu_is_arm1136_r0() to save
> a few lines of code.
> 
> Signed-off-by: Paul Walmsley <paul at pwsan.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>

For the archives - this one can be ignored; the cpu_is_arm1136_r0() isn't 
needed due to the SMP-on-UP code.


- Paul


From paul at pwsan.com  Sun Jul 28 16:16:29 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Sun, 28 Jul 2013 20:16:29 +0000 (UTC)
Subject: [PATCH] ARM: v6: prevent gcc from reordering extended CP15 reads
 above is_smp() test
In-Reply-To: <alpine.DEB.2.02.1307280538460.8385@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307280538460.8385@utopia.booyaka.com>
Message-ID: <alpine.DEB.2.02.1307282012280.23852@utopia.booyaka.com>


Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting") breaks
the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
undefined instruction abort from the CP15 read in
cache_ops_need_broadcast().  It turns out that gcc reorders the
extended CP15 read above the is_smp() test.  This breaks ARM1136 r0
cores, since they don't support several CP15 registers that later ARM
cores do.  ARM1136JF-S TRM section 3.2.1 "Register allocation" has the
details.

So, when the kernel is built for ARMv6 cores, mark the extended CP15
read as clobbering memory, which seems to prevent the compiler from
reordering it before the is_smp() test.  Russell states that the code
generated from this approach is preferable to marking the inline asm
as volatile.

This patch was developed in collaboration with Will Deacon and Russell
King.

Signed-off-by: Paul Walmsley <paul at pwsan.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
---

Thought I'd respin this to have a discussion strawman.  It boots cleanly 
on 2430SDP.

[ Updated "ARM: v6: avoid read_cpuid_ext() on ARM1136r0 in 
cache_ops_need_broadcast()" to drop the unnecessary ARM1136 r0 test, to 
switch to a memory clobber per rmk's suggestion, and to update the commit 
message. ]

Intended for v3.11-rc.


 arch/arm/include/asm/cputype.h | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 8c25dc4..f428eb0 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -89,13 +89,25 @@ extern unsigned int processor_id;
 		__val;							\
 	})
 
+
+# if defined(CONFIG_CPU_V6)
+/*
+ * The mrc in the read_cpuid_ext macro must not be reordered on ARMv6,
+ * else the compiler may move it before an is_smp() test, causing
+ * undefined instruction aborts on ARM1136 r0.
+ */
+# define CPUID_EXT_REORDER	"cc", "memory"
+# else
+# define CPUID_EXT_REORDER	"cc"
+# endif
+
 #define read_cpuid_ext(ext_reg)						\
 	({								\
 		unsigned int __val;					\
 		asm("mrc	p15, 0, %0, c0, " ext_reg		\
 		    : "=r" (__val)					\
 		    :							\
-		    : "cc");						\
+		    : CPUID_EXT_REORDER);				\
 		__val;							\
 	})
 
-- 
1.8.3.2



From christoffer.dall at linaro.org  Sun Jul 28 16:55:25 2013
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Sun, 28 Jul 2013 13:55:25 -0700
Subject: [PATCH 3/4] arm64: KVM: let other tasks run when hitting WFE
In-Reply-To: <51ED3A66.4050407@linux.vnet.ibm.com>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
 <CAC4Lta17bmNjBck6LzziBeU0Xc36F1Jms2tQPv6+GaXvik6Wyg@mail.gmail.com>
 <CAMJs5B8Sg1MPHPsRV75mmagnYxkhzA0MKWVkwW2y0WdDVWTSxQ@mail.gmail.com>
 <51ED3A66.4050407@linux.vnet.ibm.com>
Message-ID: <20130728205525.GA14863@cbox>

On Mon, Jul 22, 2013 at 07:27:58PM +0530, Raghavendra K T wrote:
> On 07/22/2013 06:21 PM, Christoffer Dall wrote:
> >On 22 July 2013 10:53, Raghavendra KT <raghavendra.kt.linux at gmail.com> wrote:
> >>On Fri, Jul 19, 2013 at 7:23 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> >>>So far, when a guest executes WFE (like when waiting for a spinlock
> >>>to become unlocked), we don't do a thing and let it run uninterrupted.
> >>>
> >>>Another option is to trap a blocking WFE and offer the opportunity
> >>>to the scheduler to switch to another task, potentially giving the
> >>>vcpu holding the spinlock a chance to run sooner.
> >>>
> >>
> >>Idea looks to be correct from my experiments on x86. It does bring some
> >>percentage of benefits in overcommitted guests. Infact,
> >>
> >>https://lkml.org/lkml/2013/7/22/41 tries to do the same thing for x86.
> >>(this results in using ple handler heuristics in vcpu_block pach).
> >
> >What about the adverse effect in the non-overcommitted case?
> >
> 
> Ideally is should fail to schedule any other task and comeback to halt
> loop. This should not hurt AFAICS. But I agree that, numbers needed to
> support this argument.

So if two VCPUs are scheduled on two PCPUs and the waiting VCPU would
normally wait, say, 1000 cycles to grab the lock, the latency for
grabbing the lock will now be (at least) a couple of thousand cycles
even for a tight switch back into the host and back into the guest (on
currently available hardware).

> 
> For x86, I had seen no side effects with the experiments.
> 

I suspect some workloads on x86 would indeed show some side effects, but
much smaller on ARM, since x86 has a much more hardware-optimized VMEXIT
cycle time on relatively recent CPUs.

-Christoffer


From robherring2 at gmail.com  Sun Jul 28 17:14:08 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Sun, 28 Jul 2013 16:14:08 -0500
Subject: [PATCH v2] ARM: Add check for Cortex-A15 errata 798181 ECO
Message-ID: <1375046048-25853-1-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

The work-around for A15 errata 798181 is not needed if appropriate ECO
fixes have been applied to r3p2 and earlier core revisions. This can be
checked by reading REVIDR register bits 4 and 9. If only bit 4 is set,
then the IPI broadcast can be skipped.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
v2:
- Determine the work-around needed and save in a static varible instead
  of re-reading the ID registers.

 arch/arm/include/asm/cputype.h |  1 +
 arch/arm/kernel/smp_tlb.c      | 31 +++++++++++++++++++++++--------
 2 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 8c25dc4..e5952b7 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -10,6 +10,7 @@
 #define CPUID_TLBTYPE	3
 #define CPUID_MPUIR	4
 #define CPUID_MPIDR	5
+#define CPUID_REVIDR	6
 
 #ifdef CONFIG_CPU_V7M
 #define CPUID_EXT_PFR0	0x40
diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
index a98b62d..da20db1 100644
--- a/arch/arm/kernel/smp_tlb.c
+++ b/arch/arm/kernel/smp_tlb.c
@@ -73,12 +73,29 @@ static inline void ipi_flush_bp_all(void *ignored)
 #ifdef CONFIG_ARM_ERRATA_798181
 static int erratum_a15_798181(void)
 {
-	unsigned int midr = read_cpuid_id();
-
-	/* Cortex-A15 r0p0..r3p2 affected */
-	if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2)
-		return 0;
-	return 1;
+	static int errata_fix_needed = -1;
+
+	if (unlikely(errata_fix_needed == -1)) {
+		unsigned int midr = read_cpuid_id();
+		unsigned int revidr = read_cpuid(CPUID_REVIDR);
+
+		/* Cortex-A15 r0p0..r3p2 w/o ECO fix affected */
+		if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2 ||
+		    (revidr & 0x210) == 0x210) {
+			errata_fix_needed = 0;	/* No work-around needed */
+			return 0;
+		}
+		if (revidr & 0x10)
+			errata_fix_needed = 1;	/* Only TLB flush needed */
+		else
+			errata_fix_needed = 2;	/* IPI broadcast needed */
+	}
+
+	if (errata_fix_needed)
+		dummy_flush_tlb_a15_erratum();
+
+	/* Return 1 if IPI broadcast to other cores is needed */
+	return (errata_fix_needed == 2) ? 1: 0;
 }
 #else
 static int erratum_a15_798181(void)
@@ -97,7 +114,6 @@ static void broadcast_tlb_a15_erratum(void)
 	if (!erratum_a15_798181())
 		return;
 
-	dummy_flush_tlb_a15_erratum();
 	smp_call_function(ipi_flush_tlb_a15_erratum, NULL, 1);
 }
 
@@ -109,7 +125,6 @@ static void broadcast_tlb_mm_a15_erratum(struct mm_struct *mm)
 	if (!erratum_a15_798181())
 		return;
 
-	dummy_flush_tlb_a15_erratum();
 	this_cpu = get_cpu();
 	a15_erratum_get_cpumask(this_cpu, mm, &mask);
 	smp_call_function_many(&mask, ipi_flush_tlb_a15_erratum, NULL, 1);
-- 
1.8.1.2



From robherring2 at gmail.com  Sun Jul 28 17:56:31 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Sun, 28 Jul 2013 16:56:31 -0500
Subject: [PATCH v3 0/7] PSCI support for highbank
Message-ID: <1375048598-15637-1-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

This is an updated series converting highbank platform to use PSCI calls
for smp_ops, cpuidle, suspend, reset and poweroff. Since the last posting,
the PSCI spec has been updated by ARM to version 0.2 [1]. The primary
kernel visible change in the specification is the addition of system level
reset and poweroff functions.

Rob

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0022b/index.html

v2: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/159519.html
v1: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-February/151820.html

Rob Herring (7):
  dt: update PSCI binding documentation for v0.2
  ARM: PSCI: remove unnecessary include of arm-gic.h
  ARM: PSCI: add ops for system restart and power off
  cpuidle: calxeda: add support to use PSCI calls
  ARM: highbank: clean-up some unused includes
  ARM: highbank: adapt to use ARM PSCI calls
  dts: calxeda: add ARM PSCI binding

 Documentation/devicetree/bindings/arm/psci.txt | 25 ++++++--
 arch/arm/boot/dts/ecx-common.dtsi              | 10 +++
 arch/arm/include/asm/psci.h                    |  2 +
 arch/arm/kernel/psci.c                         | 40 ++++++++++++
 arch/arm/kernel/psci_smp.c                     |  1 -
 arch/arm/mach-highbank/Kconfig                 |  2 +-
 arch/arm/mach-highbank/Makefile                |  4 +-
 arch/arm/mach-highbank/core.h                  |  9 ---
 arch/arm/mach-highbank/highbank.c              | 55 +---------------
 arch/arm/mach-highbank/hotplug.c               | 37 -----------
 arch/arm/mach-highbank/platsmp.c               | 68 --------------------
 arch/arm/mach-highbank/pm.c                    | 27 +++-----
 arch/arm/mach-highbank/sysregs.h               | 86 --------------------------
 arch/arm/mach-highbank/system.c                | 33 ----------
 drivers/cpuidle/cpuidle-calxeda.c              | 40 ++----------
 15 files changed, 89 insertions(+), 350 deletions(-)
 delete mode 100644 arch/arm/mach-highbank/hotplug.c
 delete mode 100644 arch/arm/mach-highbank/platsmp.c
 delete mode 100644 arch/arm/mach-highbank/sysregs.h
 delete mode 100644 arch/arm/mach-highbank/system.c

-- 
1.8.1.2



From robherring2 at gmail.com  Sun Jul 28 17:56:32 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Sun, 28 Jul 2013 16:56:32 -0500
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
Message-ID: <1375048598-15637-2-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

The PSCI spec from ARM has been updated to 0.2 version. Update the
binding document to reflect the spec changes. For the binding, the
major changes are addition of system reset and poweroff functions.
The recommended function id numbering has also changed.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
Cc: devicetree at vger.kernel.org
---
 Documentation/devicetree/bindings/arm/psci.txt | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
index 433afe9..b8b4d9f 100644
--- a/Documentation/devicetree/bindings/arm/psci.txt
+++ b/Documentation/devicetree/bindings/arm/psci.txt
@@ -21,7 +21,7 @@ to #0.
 
 Main node required properties:
 
- - compatible    : Must be "arm,psci"
+ - compatible    : Must be "arm,psci-0.2" or "arm,psci"
 
  - method        : The method of calling the PSCI firmware. Permitted
                    values are:
@@ -32,6 +32,9 @@ Main node required properties:
                    "hvc" : HVC #0, with the register assignments specified
 		           in this binding.
 
+ - psci_version  : Function ID for PSCI_VERSION operation. Required for
+                   "arm,psci-0.2" compatible version or later.
+
 Main node optional properties:
 
  - cpu_suspend   : Function ID for CPU_SUSPEND operation
@@ -42,14 +45,24 @@ Main node optional properties:
 
  - migrate       : Function ID for MIGRATE operation
 
+ - system_reset  : Function ID for SYSTEM_RESET operation
+
+ - system_off    : Function ID for SYSTEM_OFF operation
+
 
 Example:
 
 	psci {
-		compatible	= "arm,psci";
+		compatible	= "arm,psci-0.2";
 		method		= "smc";
-		cpu_suspend	= <0x95c10000>;
-		cpu_off		= <0x95c10001>;
-		cpu_on		= <0x95c10002>;
-		migrate		= <0x95c10003>;
+		psci_version	= <0x84000000>;
+		cpu_suspend	= <0x84000001>;
+		cpu_off		= <0x84000002>;
+		cpu_on		= <0x84000003>;
+		affinity_info	= <0x84000004>; 
+		migrate		= <0x84000005>;
+		migrate_info_type = <0x84000006>; 
+		migrate_info_up_cpu = <0x84000007>; 
+		system_off	= <0x84000008>; 
+		system_reset	= <0x84000009>; 
 	};
-- 
1.8.1.2



From robherring2 at gmail.com  Sun Jul 28 17:56:36 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Sun, 28 Jul 2013 16:56:36 -0500
Subject: [PATCH 5/7] ARM: highbank: clean-up some unused includes
In-Reply-To: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
Message-ID: <1375048598-15637-6-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/mach-highbank/highbank.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
index dc5d6be..0f5c661 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -18,14 +18,11 @@
 #include <linux/clocksource.h>
 #include <linux/dma-mapping.h>
 #include <linux/io.h>
-#include <linux/irq.h>
 #include <linux/irqchip.h>
-#include <linux/irqdomain.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/of_address.h>
-#include <linux/smp.h>
 #include <linux/amba/bus.h>
 #include <linux/clk-provider.h>
 
@@ -35,7 +32,6 @@
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
-#include <asm/mach/time.h>
 
 #include "core.h"
 #include "sysregs.h"
-- 
1.8.1.2



From robherring2 at gmail.com  Sun Jul 28 17:56:34 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Sun, 28 Jul 2013 16:56:34 -0500
Subject: [PATCH 3/7] ARM: PSCI: add ops for system restart and power off
In-Reply-To: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
Message-ID: <1375048598-15637-4-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

In PSCI v0.2 spec, operations for system level restart and power off are
added. This adds kernel support for those operations. The behavior for
picking restart function matches the psci_smp_ops such that the PSCI
restart function will be used when present even if a platform defines
a mdesc->restart entry. As pm_power_off depends on platform init code to
setup, using the PSCI version relies on the platform code to not override
it.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
Cc: Russell King <linux at arm.linux.org.uk>
---
 arch/arm/include/asm/psci.h |  2 ++
 arch/arm/kernel/psci.c      | 40 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 42 insertions(+)

diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index c4ae171..04ee1b2 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -29,6 +29,8 @@ struct psci_operations {
 	int (*cpu_off)(struct psci_power_state state);
 	int (*cpu_on)(unsigned long cpuid, unsigned long entry_point);
 	int (*migrate)(unsigned long cpuid);
+	void (*system_off)(void);
+	void (*system_reset)(void);
 };
 
 extern struct psci_operations psci_ops;
diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index 4693188..ffc4a7c 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -17,12 +17,14 @@
 
 #include <linux/init.h>
 #include <linux/of.h>
+#include <linux/pm.h>
 
 #include <asm/compiler.h>
 #include <asm/errno.h>
 #include <asm/opcodes-sec.h>
 #include <asm/opcodes-virt.h>
 #include <asm/psci.h>
+#include <asm/system_misc.h>
 
 struct psci_operations psci_ops;
 
@@ -33,6 +35,8 @@ enum psci_function {
 	PSCI_FN_CPU_ON,
 	PSCI_FN_CPU_OFF,
 	PSCI_FN_MIGRATE,
+	PSCI_FN_SYS_OFF,
+	PSCI_FN_SYS_RESET,
 	PSCI_FN_MAX,
 };
 
@@ -153,6 +157,30 @@ static int psci_migrate(unsigned long cpuid)
 	return psci_to_linux_errno(err);
 }
 
+static void psci_system_off(void)
+{
+	u32 fn = psci_function_id[PSCI_FN_SYS_OFF];
+	invoke_psci_fn(fn, 0, 0, 0);
+}
+
+static void psci_system_reset(void)
+{
+	u32 fn = psci_function_id[PSCI_FN_SYS_RESET];
+	invoke_psci_fn(fn, 0, 0, 0);
+}
+
+void psci_pm_power_off(void)
+{
+	if (psci_ops.system_off)
+		psci_ops.system_off();
+}
+
+void psci_restart(enum reboot_mode reboot_mode, const char *cmd)
+{
+	if (psci_ops.system_off)
+		psci_ops.system_reset();
+}
+
 static const struct of_device_id psci_of_match[] __initconst = {
 	{ .compatible = "arm,psci",	},
 	{},
@@ -204,6 +232,18 @@ void __init psci_init(void)
 		psci_ops.migrate = psci_migrate;
 	}
 
+	if (!of_property_read_u32(np, "system_off", &id)) {
+		psci_function_id[PSCI_FN_SYS_OFF] = id;
+		psci_ops.system_off = psci_system_off;
+		pm_power_off = psci_pm_power_off;
+	}
+
+	if (!of_property_read_u32(np, "system_reset", &id)) {
+		psci_function_id[PSCI_FN_SYS_RESET] = id;
+		psci_ops.system_reset = psci_system_reset;
+		arm_pm_restart = psci_restart;
+	}
+
 out_put_node:
 	of_node_put(np);
 	return;
-- 
1.8.1.2



From robherring2 at gmail.com  Sun Jul 28 17:56:35 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Sun, 28 Jul 2013 16:56:35 -0500
Subject: [PATCH 4/7] cpuidle: calxeda: add support to use PSCI calls
In-Reply-To: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
Message-ID: <1375048598-15637-5-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

This updates the Calxeda cpuidle driver to use PSCI calls to powergate
cores. This is needed to enable cpuidle for the ECX-2000.

This could possibly become a generic PSCI driver, but there are no other
PSCI users in the kernel other than mach-virt.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
Cc: "Rafael J. Wysocki" <rjw at sisk.pl>
Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
Cc: linux-pm at vger.kernel.org
---
 drivers/cpuidle/cpuidle-calxeda.c | 40 ++++++---------------------------------
 1 file changed, 6 insertions(+), 34 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
index 0e6e408..01cfecf3 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -22,51 +22,23 @@
 
 #include <linux/cpuidle.h>
 #include <linux/init.h>
-#include <linux/io.h>
 #include <linux/of.h>
-#include <linux/time.h>
-#include <linux/delay.h>
-#include <linux/suspend.h>
 #include <asm/cpuidle.h>
-#include <asm/proc-fns.h>
-#include <asm/smp_scu.h>
 #include <asm/suspend.h>
-#include <asm/cacheflush.h>
-#include <asm/cp15.h>
-
-extern void highbank_set_cpu_jump(int cpu, void *jump_addr);
-extern void *scu_base_addr;
-
-static noinline void calxeda_idle_restore(void)
-{
-	set_cr(get_cr() | CR_C);
-	set_auxcr(get_auxcr() | 0x40);
-	scu_power_mode(scu_base_addr, SCU_PM_NORMAL);
-}
+#include <asm/psci.h>
 
 static int calxeda_idle_finish(unsigned long val)
 {
-	/* Already flushed cache, but do it again as the outer cache functions
-	 * dirty the cache with spinlocks */
-	flush_cache_all();
-
-	set_auxcr(get_auxcr() & ~0x40);
-	set_cr(get_cr() & ~CR_C);
-
-	scu_power_mode(scu_base_addr, SCU_PM_DORMANT);
-
-	cpu_do_idle();
-
-	/* Restore things if we didn't enter power-gating */
-	calxeda_idle_restore();
-	return 1;
+	const struct psci_power_state ps = {
+		.type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+	};
+	return psci_ops.cpu_suspend(ps, __pa(cpu_resume));
 }
 
 static int calxeda_pwrdown_idle(struct cpuidle_device *dev,
 				struct cpuidle_driver *drv,
 				int index)
 {
-	highbank_set_cpu_jump(smp_processor_id(), cpu_resume);
 	cpu_suspend(0, calxeda_idle_finish);
 	return index;
 }
@@ -90,7 +62,7 @@ static struct cpuidle_driver calxeda_idle_driver = {
 
 static int __init calxeda_cpuidle_init(void)
 {
-	if (!of_machine_is_compatible("calxeda,highbank"))
+	if (!of_machine_is_compatible("calxeda,highbank") || !psci_ops.cpu_suspend)
 		return -ENODEV;
 
 	return cpuidle_register(&calxeda_idle_driver, NULL);
-- 
1.8.1.2



From robherring2 at gmail.com  Sun Jul 28 17:56:33 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Sun, 28 Jul 2013 16:56:33 -0500
Subject: [PATCH 2/7] ARM: PSCI: remove unnecessary include of arm-gic.h
In-Reply-To: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
Message-ID: <1375048598-15637-3-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Now that gic_secondary_init is no longer needed to be called by SMP init
functions, the header is not needed.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
Cc: Russell King <linux at arm.linux.org.uk>
---
 arch/arm/kernel/psci_smp.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
index 70ded3f..570a48c 100644
--- a/arch/arm/kernel/psci_smp.c
+++ b/arch/arm/kernel/psci_smp.c
@@ -14,7 +14,6 @@
  */
 
 #include <linux/init.h>
-#include <linux/irqchip/arm-gic.h>
 #include <linux/smp.h>
 #include <linux/of.h>
 
-- 
1.8.1.2



From robherring2 at gmail.com  Sun Jul 28 17:56:37 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Sun, 28 Jul 2013 16:56:37 -0500
Subject: [PATCH 6/7] ARM: highbank: adapt to use ARM PSCI calls
In-Reply-To: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
Message-ID: <1375048598-15637-7-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

This adapts highbank to use the psci_smp_ops. Additionally,
suspend/resume, reset and poweroff are all converted to use PSCI calls.
Doing this removes direct access to the SCU and factors out the A9 vs.
A15 differences.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/mach-highbank/Kconfig    |  2 +-
 arch/arm/mach-highbank/Makefile   |  4 +-
 arch/arm/mach-highbank/core.h     |  9 ----
 arch/arm/mach-highbank/highbank.c | 51 +----------------------
 arch/arm/mach-highbank/hotplug.c  | 37 -----------------
 arch/arm/mach-highbank/platsmp.c  | 68 -------------------------------
 arch/arm/mach-highbank/pm.c       | 27 ++++--------
 arch/arm/mach-highbank/sysregs.h  | 86 ---------------------------------------
 arch/arm/mach-highbank/system.c   | 33 ---------------
 9 files changed, 12 insertions(+), 305 deletions(-)
 delete mode 100644 arch/arm/mach-highbank/hotplug.c
 delete mode 100644 arch/arm/mach-highbank/platsmp.c
 delete mode 100644 arch/arm/mach-highbank/sysregs.h
 delete mode 100644 arch/arm/mach-highbank/system.c

diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
index cd9fcb1..9c61924 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -5,13 +5,13 @@ config ARCH_HIGHBANK
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_AMBA
 	select ARM_GIC
+	select ARM_PSCI
 	select ARM_TIMER_SP804
 	select CACHE_L2X0
 	select CLKDEV_LOOKUP
 	select COMMON_CLK
 	select CPU_V7
 	select GENERIC_CLOCKEVENTS
-	select HAVE_ARM_SCU
 	select HAVE_ARM_TWD if LOCAL_TIMERS
 	select HAVE_SMP
 	select MAILBOX
diff --git a/arch/arm/mach-highbank/Makefile b/arch/arm/mach-highbank/Makefile
index 8a1ef57..aeabc32 100644
--- a/arch/arm/mach-highbank/Makefile
+++ b/arch/arm/mach-highbank/Makefile
@@ -1,8 +1,6 @@
-obj-y					:= highbank.o system.o smc.o
+obj-y					:= highbank.o smc.o
 
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_smc.o				:=-Wa,-march=armv7-a$(plus_sec)
 
-obj-$(CONFIG_SMP)			+= platsmp.o
-obj-$(CONFIG_HOTPLUG_CPU)		+= hotplug.o
 obj-$(CONFIG_PM_SLEEP)			+= pm.o
diff --git a/arch/arm/mach-highbank/core.h b/arch/arm/mach-highbank/core.h
index aea1ec5..52b713a 100644
--- a/arch/arm/mach-highbank/core.h
+++ b/arch/arm/mach-highbank/core.h
@@ -1,12 +1,6 @@
 #ifndef __HIGHBANK_CORE_H
 #define __HIGHBANK_CORE_H
 
-#include <linux/reboot.h>
-
-extern void highbank_set_cpu_jump(int cpu, void *jump_addr);
-extern void highbank_restart(enum reboot_mode, const char *);
-extern void __iomem *scu_base_addr;
-
 #ifdef CONFIG_PM_SLEEP
 extern void highbank_pm_init(void);
 #else
@@ -14,8 +8,5 @@ static inline void highbank_pm_init(void) {}
 #endif
 
 extern void highbank_smc1(int fn, int arg);
-extern void highbank_cpu_die(unsigned int cpu);
-
-extern struct smp_operations highbank_smp_ops;
 
 #endif
diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
index 0f5c661..fabc5dd 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -26,61 +26,23 @@
 #include <linux/amba/bus.h>
 #include <linux/clk-provider.h>
 
-#include <asm/cacheflush.h>
-#include <asm/cputype.h>
-#include <asm/smp_plat.h>
+#include <asm/psci.h>
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 
 #include "core.h"
-#include "sysregs.h"
 
 void __iomem *sregs_base;
-void __iomem *scu_base_addr;
-
-static void __init highbank_scu_map_io(void)
-{
-	unsigned long base;
-
-	/* Get SCU base */
-	asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
-
-	scu_base_addr = ioremap(base, SZ_4K);
-}
-
-#define HB_JUMP_TABLE_PHYS(cpu)		(0x40 + (0x10 * (cpu)))
-#define HB_JUMP_TABLE_VIRT(cpu)		phys_to_virt(HB_JUMP_TABLE_PHYS(cpu))
-
-void highbank_set_cpu_jump(int cpu, void *jump_addr)
-{
-	cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(cpu), 0);
-	writel(virt_to_phys(jump_addr), HB_JUMP_TABLE_VIRT(cpu));
-	__cpuc_flush_dcache_area(HB_JUMP_TABLE_VIRT(cpu), 16);
-	outer_clean_range(HB_JUMP_TABLE_PHYS(cpu),
-			  HB_JUMP_TABLE_PHYS(cpu) + 15);
-}
-
-#ifdef CONFIG_CACHE_L2X0
-static void highbank_l2x0_disable(void)
-{
-	/* Disable PL310 L2 Cache controller */
-	highbank_smc1(0x102, 0x0);
-}
-#endif
 
 static void __init highbank_init_irq(void)
 {
 	irqchip_init();
 
-	if (of_find_compatible_node(NULL, NULL, "arm,cortex-a9"))
-		highbank_scu_map_io();
-
 #ifdef CONFIG_CACHE_L2X0
 	/* Enable PL310 L2 Cache controller */
 	highbank_smc1(0x102, 0x1);
 	l2x0_of_init(0, ~0UL);
-	outer_cache.disable = highbank_l2x0_disable;
 #endif
 }
 
@@ -98,14 +60,6 @@ static void __init highbank_timer_init(void)
 	clocksource_of_init();
 }
 
-static void highbank_power_off(void)
-{
-	highbank_set_pwr_shutdown();
-
-	while (1)
-		cpu_do_idle();
-}
-
 static int highbank_platform_notifier(struct notifier_block *nb,
 				  unsigned long event, void *__dev)
 {
@@ -155,7 +109,6 @@ static struct notifier_block highbank_platform_nb = {
 
 static void __init highbank_init(void)
 {
-	pm_power_off = highbank_power_off;
 	highbank_pm_init();
 
 	bus_register_notifier(&platform_bus_type, &highbank_platform_nb);
@@ -171,10 +124,8 @@ static const char *highbank_match[] __initconst = {
 };
 
 DT_MACHINE_START(HIGHBANK, "Highbank")
-	.smp		= smp_ops(highbank_smp_ops),
 	.init_irq	= highbank_init_irq,
 	.init_time	= highbank_timer_init,
 	.init_machine	= highbank_init,
 	.dt_compat	= highbank_match,
-	.restart	= highbank_restart,
 MACHINE_END
diff --git a/arch/arm/mach-highbank/hotplug.c b/arch/arm/mach-highbank/hotplug.c
deleted file mode 100644
index a019e4e..0000000
--- a/arch/arm/mach-highbank/hotplug.c
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * Copyright 2011 Calxeda, Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-#include <linux/kernel.h>
-#include <asm/cacheflush.h>
-
-#include "core.h"
-#include "sysregs.h"
-
-extern void secondary_startup(void);
-
-/*
- * platform-specific code to shutdown a CPU
- *
- */
-void __ref highbank_cpu_die(unsigned int cpu)
-{
-	highbank_set_cpu_jump(cpu, phys_to_virt(0));
-
-	flush_cache_louis();
-	highbank_set_core_pwr();
-
-	while (1)
-		cpu_do_idle();
-}
diff --git a/arch/arm/mach-highbank/platsmp.c b/arch/arm/mach-highbank/platsmp.c
deleted file mode 100644
index 32d75cf5..0000000
--- a/arch/arm/mach-highbank/platsmp.c
+++ /dev/null
@@ -1,68 +0,0 @@
-/*
- * Copyright 2010-2011 Calxeda, Inc.
- * Based on platsmp.c, Copyright (C) 2002 ARM Ltd.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-#include <linux/init.h>
-#include <linux/smp.h>
-#include <linux/io.h>
-
-#include <asm/smp_scu.h>
-
-#include "core.h"
-
-extern void secondary_startup(void);
-
-static int highbank_boot_secondary(unsigned int cpu, struct task_struct *idle)
-{
-	highbank_set_cpu_jump(cpu, secondary_startup);
-	arch_send_wakeup_ipi_mask(cpumask_of(cpu));
-	return 0;
-}
-
-/*
- * Initialise the CPU possible map early - this describes the CPUs
- * which may be present or become present in the system.
- */
-static void __init highbank_smp_init_cpus(void)
-{
-	unsigned int i, ncores = 4;
-
-	/* sanity check */
-	if (ncores > NR_CPUS) {
-		printk(KERN_WARNING
-		       "highbank: no. of cores (%d) greater than configured "
-		       "maximum of %d - clipping\n",
-		       ncores, NR_CPUS);
-		ncores = NR_CPUS;
-	}
-
-	for (i = 0; i < ncores; i++)
-		set_cpu_possible(i, true);
-}
-
-static void __init highbank_smp_prepare_cpus(unsigned int max_cpus)
-{
-	if (scu_base_addr)
-		scu_enable(scu_base_addr);
-}
-
-struct smp_operations highbank_smp_ops __initdata = {
-	.smp_init_cpus		= highbank_smp_init_cpus,
-	.smp_prepare_cpus	= highbank_smp_prepare_cpus,
-	.smp_boot_secondary	= highbank_boot_secondary,
-#ifdef CONFIG_HOTPLUG_CPU
-	.cpu_die		= highbank_cpu_die,
-#endif
-};
diff --git a/arch/arm/mach-highbank/pm.c b/arch/arm/mach-highbank/pm.c
index 04eddb4..7f2bd85 100644
--- a/arch/arm/mach-highbank/pm.c
+++ b/arch/arm/mach-highbank/pm.c
@@ -16,27 +16,19 @@
 
 #include <linux/cpu_pm.h>
 #include <linux/init.h>
-#include <linux/io.h>
 #include <linux/suspend.h>
 
-#include <asm/cacheflush.h>
-#include <asm/proc-fns.h>
 #include <asm/suspend.h>
-
-#include "core.h"
-#include "sysregs.h"
+#include <asm/psci.h>
 
 static int highbank_suspend_finish(unsigned long val)
 {
-	outer_flush_all();
-	outer_disable();
-
-	highbank_set_pwr_suspend();
-
-	cpu_do_idle();
+	const struct psci_power_state ps = {
+		.type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
+		.affinity_level = 1,
+	};
 
-	highbank_clear_pwr_request();
-	return 0;
+	return psci_ops.cpu_suspend(ps, __pa(cpu_resume));
 }
 
 static int highbank_pm_enter(suspend_state_t state)
@@ -44,15 +36,11 @@ static int highbank_pm_enter(suspend_state_t state)
 	cpu_pm_enter();
 	cpu_cluster_pm_enter();
 
-	highbank_set_cpu_jump(0, cpu_resume);
 	cpu_suspend(0, highbank_suspend_finish);
 
 	cpu_cluster_pm_exit();
 	cpu_pm_exit();
 
-	highbank_smc1(0x102, 0x1);
-	if (scu_base_addr)
-		scu_enable(scu_base_addr);
 	return 0;
 }
 
@@ -63,5 +51,8 @@ static const struct platform_suspend_ops highbank_pm_ops = {
 
 void __init highbank_pm_init(void)
 {
+	if (!psci_ops.cpu_suspend)
+		return;
+
 	suspend_set_ops(&highbank_pm_ops);
 }
diff --git a/arch/arm/mach-highbank/sysregs.h b/arch/arm/mach-highbank/sysregs.h
deleted file mode 100644
index 5995df7..0000000
--- a/arch/arm/mach-highbank/sysregs.h
+++ /dev/null
@@ -1,86 +0,0 @@
-/*
- * Copyright 2011 Calxeda, Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-#ifndef _MACH_HIGHBANK__SYSREGS_H_
-#define _MACH_HIGHBANK__SYSREGS_H_
-
-#include <linux/io.h>
-#include <linux/smp.h>
-#include <asm/smp_plat.h>
-#include <asm/smp_scu.h>
-#include "core.h"
-
-extern void __iomem *sregs_base;
-
-#define HB_SREG_A9_PWR_REQ		0xf00
-#define HB_SREG_A9_BOOT_STAT		0xf04
-#define HB_SREG_A9_BOOT_DATA		0xf08
-
-#define HB_PWR_SUSPEND			0
-#define HB_PWR_SOFT_RESET		1
-#define HB_PWR_HARD_RESET		2
-#define HB_PWR_SHUTDOWN			3
-
-#define SREG_CPU_PWR_CTRL(c)		(0x200 + ((c) * 4))
-
-static inline void highbank_set_core_pwr(void)
-{
-	int cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(smp_processor_id()), 0);
-	if (scu_base_addr)
-		scu_power_mode(scu_base_addr, SCU_PM_POWEROFF);
-	else
-		writel_relaxed(1, sregs_base + SREG_CPU_PWR_CTRL(cpu));
-}
-
-static inline void highbank_clear_core_pwr(void)
-{
-	int cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(smp_processor_id()), 0);
-	if (scu_base_addr)
-		scu_power_mode(scu_base_addr, SCU_PM_NORMAL);
-	else
-		writel_relaxed(0, sregs_base + SREG_CPU_PWR_CTRL(cpu));
-}
-
-static inline void highbank_set_pwr_suspend(void)
-{
-	writel(HB_PWR_SUSPEND, sregs_base + HB_SREG_A9_PWR_REQ);
-	highbank_set_core_pwr();
-}
-
-static inline void highbank_set_pwr_shutdown(void)
-{
-	writel(HB_PWR_SHUTDOWN, sregs_base + HB_SREG_A9_PWR_REQ);
-	highbank_set_core_pwr();
-}
-
-static inline void highbank_set_pwr_soft_reset(void)
-{
-	writel(HB_PWR_SOFT_RESET, sregs_base + HB_SREG_A9_PWR_REQ);
-	highbank_set_core_pwr();
-}
-
-static inline void highbank_set_pwr_hard_reset(void)
-{
-	writel(HB_PWR_HARD_RESET, sregs_base + HB_SREG_A9_PWR_REQ);
-	highbank_set_core_pwr();
-}
-
-static inline void highbank_clear_pwr_request(void)
-{
-	writel(~0UL, sregs_base + HB_SREG_A9_PWR_REQ);
-	highbank_clear_core_pwr();
-}
-
-#endif
diff --git a/arch/arm/mach-highbank/system.c b/arch/arm/mach-highbank/system.c
deleted file mode 100644
index 2df5870..0000000
--- a/arch/arm/mach-highbank/system.c
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * Copyright 2011 Calxeda, Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-#include <linux/io.h>
-#include <asm/proc-fns.h>
-#include <linux/reboot.h>
-
-#include "core.h"
-#include "sysregs.h"
-
-void highbank_restart(enum reboot_mode mode, const char *cmd)
-{
-	if (mode == REBOOT_HARD)
-		highbank_set_pwr_hard_reset();
-	else
-		highbank_set_pwr_soft_reset();
-
-	while (1)
-		cpu_do_idle();
-}
-
-- 
1.8.1.2



From robherring2 at gmail.com  Sun Jul 28 17:56:38 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Sun, 28 Jul 2013 16:56:38 -0500
Subject: [PATCH 7/7] dts: calxeda: add ARM PSCI binding
In-Reply-To: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
Message-ID: <1375048598-15637-8-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring at calxeda.com>

Add the PSCI binding for Calxeda SOCs. The PSCI function numbers are
different from the DT binding example because the numbering changed in
revisions of the PSCI spec and are already fixed in highbank firmware.
Since the numbering is transparent to the kernel, this difference is not
significant.

Signed-off-by: Rob Herring <rob.herring at calxeda.com>
---
 arch/arm/boot/dts/ecx-common.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/ecx-common.dtsi b/arch/arm/boot/dts/ecx-common.dtsi
index e8559b7..f1dfc09 100644
--- a/arch/arm/boot/dts/ecx-common.dtsi
+++ b/arch/arm/boot/dts/ecx-common.dtsi
@@ -19,6 +19,16 @@
 		bootargs = "console=ttyAMA0";
 	};
 
+	psci {
+		compatible	= "arm,psci";
+		method		= "smc";
+		cpu_suspend	= <0x84000002>;
+		cpu_off		= <0x84000004>;
+		cpu_on		= <0x84000006>;
+		system_off	= <0x84000100>;
+		system_reset	= <0x84000101>;
+	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
1.8.1.2



From david at gibson.dropbear.id.au  Sun Jul 28 17:46:37 2013
From: david at gibson.dropbear.id.au (David Gibson)
Date: Mon, 29 Jul 2013 07:46:37 +1000
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130728153546.GB5224@netboy>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1416484.XDfk5G56BI@flatron> <20130728131901.GA8864@netboy>
 <2529481.u8xHuXumcd@flatron>
 <CAKON4OzReTRb5JnJE+07vNJ-uDndLfqq8ha04J7K3x=WtsZEWw@mail.gmail.com>
 <20130728153546.GB5224@netboy>
Message-ID: <20130728214637.GC29970@voom.fritz.box>

On Sun, Jul 28, 2013 at 05:35:46PM +0200, Richard Cochran wrote:
> On Sun, Jul 28, 2013 at 10:09:57AM -0400, jonsmirl at gmail.com wrote:
> > 
> > 3.z kernel is free to alter the schema. But it will have to supply the
> > necessary quirks needed to keep those old dtb's functioning.
> 
> The quirks idea sounds okay to me, if it can really provide forward
> compatibility. In practice, I doubt anyone will really spend the
> effort to make this work. I think it would be much easier to make sure
> the bindings are "future proof" in the first place.

I should clarify.  The idea of DT quirks is not to remove the need to
properly design and review bindings.  It's to limit the damage when
there are, inevitably, failings in that process.  And when, also
inevitably, firmware vendors ship DTs that don't follow the bindings
correctly, even when there is a good one available.

I think it's more likely that people will create, and get right, a
well localized bit of quirk code, than they will get backwards compat
code correct for every place in which a driver wants info from the
device tree.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130729/fd78ddc3/attachment-0001.sig>

From kuninori.morimoto.gx at renesas.com  Sun Jul 28 20:20:43 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Sun, 28 Jul 2013 17:20:43 -0700 (PDT)
Subject: [PATCH] ARM: shmobile: BOCK-W: fix SDHI0 PFC settings
In-Reply-To: <51F30C60.5050504@cogentembedded.com>
References: <201307270346.34002.sergei.shtylyov@cogentembedded.com>
 <51F30C60.5050504@cogentembedded.com>
Message-ID: <87bo5mrzcc.wl%kuninori.morimoto.gx@renesas.com>


Hi Simon

> > The following message is printed on the BOCK-W kernel bootup:
> 
> > sh-pfc pfc-r8a7778: invalid group "sdhi0" for function "sdhi0"
> 
> > In addition, SD card cannot be detected.  The reason is apparently that commit
> > ca7bb309485e4ec89a9addd47bea (ARM: shmobile: bockw: add SDHI0 support) matched
> > the previous version of commit 564617d2f92473031d035deb273da5 (sh-pfc: r8a7778:
> > add SDHI support).
> 
> > Add the missing pin groups according to the BOCK-W board schematics.
> 
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> > ---
> > The patch is atop of Simon's 'renesas.git' repo, 'renesas-devel-20130726' tag.
> 
>     It also applies to the current Linus' tree cleanly. Please push it for 3.11.
> 
> WBR, Sergei

Something happen on patch.

Linux/master branch seems have old verion.

---- linux/master : old version --------------------------
commit ca7bb309485e4ec89a9addd47beaa1d079841b7d
Author: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Date:   Wed Apr 17 05:17:56 2013 +0000

    ARM: shmobile: bockw: add SDHI0 support
    
    This patch is directly accessing to PUPR4 register which can
    control SDHI0 CD/WP pin pull-up setting.
    It should be replaced in the future.
    
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
    Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
----------------------------------------------------------

This is the correct/latest version

----- correct version ---------------------------------------------
commit c2ee46ab49ce3bb5a60b36940e70355beb409acf
Author: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Date:   Thu Apr 18 20:09:32 2013 -0700

    ARM: shmobile: bockw: add SDHI0 support
    
    This patch is directly accessing to PUPR4 register which can
    control SDHI0 CD/WP pin pull-up setting.
    It should be replaced in the future.
    
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
    Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
-------------------------------------------------------------------

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Best regards
---
Kuninori Morimoto


From tomasz.figa at gmail.com  Sun Jul 28 20:21:52 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 29 Jul 2013 02:21:52 +0200
Subject: Defining schemas for Device Tree
Message-ID: <2469263.vMN09Q7Tzi@flatron>

Hi,

As promised I am starting a discussion about Device Tree schema. Let's 
first shortly introduce the problem.

Device Tree is a text-based data structure used to describe hardware. Its 
main point is separation from kernel code, which has a lot of benefits, 
but, at the moment, also a huge drawback - there is no verification of 
device tree sources against defined bindings. All the dtc compiler does 
currently are syntax checks - no semantic analysis is performed (except
some really basic things). What this means is that anybody can put
anything in their device tree and end up with the dts compiling fine only
to find out that something is wrong at boot time.

Currently, device tree bindings are described in plain text documentation 
files, which can not be considered a formal way of binding description. 
While such documentation provides information for developers/users that 
need to work with particular bindings, it can not be easily used as input 
for validation of device tree sources. This means that we need to define a 
more formal way of binding description, in other words - Device Tree 
schema.

To find a solution for this problem, we must first answer several 
questions to determine a set of requirements we have to meet.

a) What is a device tree binding?
 
For our purposes, I will define a binding as internal format of some 
device tree node, which can be matched using of_find_matching_node(). In 
other words, key for a binding would be node name and/or value of 
compatible property and/or node type. Value for a binding would be a list 
of properties with their formats and/or subnodes with their bindings.
 
b) What information should be specified in schemas? What level of 
   granularity is required?

For each property we need to have at least following data specified:
 - property name (or property name format, e.g. regex),
 - whether the property is mandatory or optional,
 - data type of value.

As for now, I can think of following data types used in device trees:
 - boolean (i.e. without value),
 - array of strings (including single string),
 - array of u32 (including single u32),
 - specifier (aka phandle with args, including cases with 0 args),
 - variable-length cells (e.g. #address-cells of u32s).

Some properties might require a combination of data types to be specified 
or even an array of combinations, like interrupt-map property, which is an 
array of entries consisting of:
 - #address-cells u32s,
 - #interrupt-cells u32s,
 - specifier (phandle of interrupt controller and u32 of count defined by 
   #interrupt-cells of the controller).

We probably want to define allowed range of values for given property, be 
it contiguous or enumerated.

As for subnodes, I think we need to define following constraints:
 - node name (or node name format, e.g. regex),
 - optional or not,
 - how many nodes of this type can be present (one, limited, unlimited),
 - recursively define binding for such node type.

We probably also want human readable descriptions for all properties and 
subnodes, so a textual documentation (like the one currently available) 
could be generated from schemas.

c) What about generic bindings? (e.g. for subsystems like pinctrl or 
regulators)

This is where things get more interesting. Looks like we need some kind of 
inheritance for bindings or binding templates. Templates sound more 
appropriate here, because most of the generic bindings do not fully 
conform to what I defined as binding and need device-specific parameters 
to become so.

Let's consider first example taken from regulator subsystem.

	device {
		compatible = "foo,mydevice";
		/* ... */
		core-supply = <&regulator_a>;
		io-supply = <&regulator_b>;
		/* ... */
	};

Bindings of regulator subsystem define the way of regulator lookup to be 
based on property matching following definition:

	#define REGULATOR(name) name ## _supply = <&phandle>

As you can see, the binding is parametrized, i.e. part of it is defined 
globally, but part is device-specific. Similarly for pinctrl subsystem:

	device {
		compatible = "foo,mydevice";
		/* ... */
		pinctrl-names = "state0", "state1";
		pinctrl-0 = <&phandle>...;
		pinctrl-1 = <&phandle>...;
		/* ... */
	};

This binding is now parametrized in a more complex way:

	#define PINCTRL(name0, name1, ..., nameN) \
		pinctrl-names = name0, name1, ..., nameN; \
		pinctrl-0 = <&phandle>...; \
		pinctrl-1 = <&phandle>...; \
		... \
		pinctrl-N = <&phandle>...;

We need to have a way to describe this kind of inheritance, if we don't 
want to respecify generic attributes in all device bindings using them.

d) When should the validation happen and what should handle it?

In my opinion, similarly to compilation of board files, validation should 
be happening at dts compile time, to show any warnings or errors as early 
as possible.

Whether this should be integrated into dtc or rather handled by external 
tool is another question. Since we are already processing device tree 
sources in dtc, it might be reasonable to reuse its dts parsing 
infrastructure and add validation there, especially that dtc is supposed 
to already contain some infrastructure for doing checks on device tree as 
well. Nothing stops us from running validation on already compiled dtbs, 
though, using an extra tool.

e) What format should be used for Device Tree schema?

This is a non-trivial problem. Key criteria I can think of are as follows:
 - the whole set of information established above must be representable,
 - human-readable, easy to create and edit (extend), preferably similar to 
   something already existing, so could be easily learnt,
 - something that can be integrated with dtc with reasonable amount of 
   work or can reuse a lot (if not all) of already existing parsing code.

Okay, this should be enough to have some discussion. I will post a
follow-up with my proposal of schema format to separate general discussion
from discussion about the proposal, but this will happen tomorrow, as now
it's time to get some sleep.

For now please think about the points above and feel free to correct
anything wrong or suggest what else should be taken into consideration
for DT schemas. Let the discussion start.

Best regards,
Tomasz



From jonsmirl at gmail.com  Sun Jul 28 21:30:22 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Sun, 28 Jul 2013 21:30:22 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <2469263.vMN09Q7Tzi@flatron>
References: <2469263.vMN09Q7Tzi@flatron>
Message-ID: <CAKON4OzgqH5AiOtismEGop5Y++gvu1ZVZEXhwJB3f-6_eczkqQ@mail.gmail.com>

There is another angle to this problem -- how do we make a single
schema for all device trees accepted by the kernel? We certainly don't
want a schema for each vendor where they can do whatever they want.

Obviously all devices in a device class are not identical but many of
their attributes are. The purpose of a unified schema is stop one
vendor from naming an attribute VOLTAGE, another VOLTS, another V, etc
when all of these attributes are doing the same thing - setting a
voltage. It is possible to use different names right now since they
are different device drivers. There's no overall architecture glue
(schema) holding the device class design together.

The main point of this unified schema is to help people creating new
device drivers. When ypu construct your device tree representation you
should first try your best to get it to fit into the existing device
class schema. Only after you determine that it is impossible to make
do with the current schema should you ask for the generic schema to be
extended to include whatever attribute you think you need. At that
point peer review will happen and hopefully a good solution will
ensue.

----------------

Imagine what might be possible with device trees in a few years...

A single kernel image can load on any embedded system. The device tree
sorts out all of the driver loading and tells how everything is wired
together. There is zero board specific code in the kernel. We're
getting close to this one.

And in the far future - send your device tree off to a cloud PCB
printer and get your custom embedded system back in the mail. Sign me
up for this one!

-- 
Jon Smirl
jonsmirl at gmail.com


From 21cnbao at gmail.com  Sun Jul 28 22:14:24 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Mon, 29 Jul 2013 10:14:24 +0800
Subject: [PATCH] DMAEngine: sirf: let the users be able to pause and
 resume specific buffer
In-Reply-To: <1372927373-17407-1-git-send-email-Baohua.Song@csr.com>
References: <1372927373-17407-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <CAGsJ_4wOdDMku-pNWiH-DoS_v39PfFwNYcU4T1Thsd-+L9A8AQ@mail.gmail.com>

2013/7/4 Barry Song <Baohua.Song at csr.com>
>
> From: Qipan Li <Qipan.Li at csr.com>
>
> this patch adds a buffer_index in pause and resume entries, then users
> can pause and resume a buffer they want, but don't pause the whole dma.
>
> a typical application scenerios is Ping-Pang in two buffers:
> at the beginning, we enable buf1 and buf2 to receive dma data, after
> buf1 is full, we pause buf1 and handle the data in this buffer to avoid
> overflow in buf1. but at the same time, dma is still tranferring in buf2.
> once we have finished data process in buf1, we enable buf1 again.
> this will maximize the chance of dma transferring. users pause buf1 by:
> dmaengine_device_control(sirfport->rx_dma_chan, DMA_PAUSE, 1);
> users pause buf2 by:
> dmaengine_device_control(sirfport->rx_dma_chan, DMA_PAUSE, 2);
> users can still pause the whole dma transferring by dmaengine_pause().
>
> Signed-off-by: Qipan Li <Qipan.Li at csr.com>
> Signed-off-by: Barry Song <Baohua.Song at csr.com>
> ---
>  drivers/dma/sirf-dma.c | 102
> ++++++++++++++++++++++++++++++++++++++-----------
>  1 file changed, 80 insertions(+), 22 deletions(-)

Hi Vinod, as we still have some other patches of dma clients depending
on this, would you give some comments about it?

>
> diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
> index 1d627e2..7d500d2 100644
> --- a/drivers/dma/sirf-dma.c
> +++ b/drivers/dma/sirf-dma.c
> @@ -315,43 +315,101 @@ static int sirfsoc_dma_terminate_all(struct
> sirfsoc_dma_chan *schan)
>         return 0;
>  }
>
> -static int sirfsoc_dma_pause_chan(struct sirfsoc_dma_chan *schan)
> +static int sirfsoc_dma_pause_chan(struct sirfsoc_dma_chan *schan,
> +                                               unsigned long buf_index)
>  {
>         struct sirfsoc_dma *sdma = dma_chan_to_sirfsoc_dma(&schan->chan);
>         int cid = schan->chan.chan_id;
>         unsigned long flags;
> +       unsigned long loop_ctrl_val;
>
>         spin_lock_irqsave(&schan->lock, flags);
> -
> -       if (!sdma->is_marco)
> -               writel_relaxed(readl_relaxed(sdma->base +
> SIRFSOC_DMA_CH_LOOP_CTRL)
> -                       & ~((1 << cid) | 1 << (cid + 16)),
> -                       sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
> -       else
> -               writel_relaxed((1 << cid) | 1 << (cid + 16),
> -                       sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL_CLR);
> -
> +       if (!sdma->is_marco) {
> +               loop_ctrl_val = readl_relaxed(sdma->base +
> +                               SIRFSOC_DMA_CH_LOOP_CTRL);
> +               switch (buf_index) {
> +               case 1:
> +                       writel_relaxed(loop_ctrl_val & ~(1 << cid),
> +                                       sdma->base +
> SIRFSOC_DMA_CH_LOOP_CTRL);
> +                       break;
> +               case 2:
> +                       writel_relaxed(loop_ctrl_val & ~(1 << (cid + 16)),
> +                                       sdma->base +
> SIRFSOC_DMA_CH_LOOP_CTRL);
> +                       break;
> +               case 0:
> +               default:
> +                       writel_relaxed(loop_ctrl_val &
> +                                       ~((1 << cid) | 1 << (cid + 16)),
> +                                       sdma->base +
> SIRFSOC_DMA_CH_LOOP_CTRL);
> +                       break;
> +               }
> +       } else {
> +               switch (buf_index) {
> +               case 1:
> +                       writel_relaxed((1 << cid), sdma->base +
> +
> SIRFSOC_DMA_CH_LOOP_CTRL_CLR);
> +                       break;
> +               case 2:
> +                       writel_relaxed(1 << (cid + 16), sdma->base +
> +
> SIRFSOC_DMA_CH_LOOP_CTRL_CLR);
> +                       break;
> +               case 0:
> +               default:
> +                       writel_relaxed((1 << cid) | 1 << (cid + 16),
> +                               sdma->base +
> SIRFSOC_DMA_CH_LOOP_CTRL_CLR);
> +                       break;
> +               }
> +       }
>         spin_unlock_irqrestore(&schan->lock, flags);
>
>         return 0;
>  }
>
> -static int sirfsoc_dma_resume_chan(struct sirfsoc_dma_chan *schan)
> +static int sirfsoc_dma_resume_chan(struct sirfsoc_dma_chan *schan,
> +                                               unsigned long buf_index)
>  {
>         struct sirfsoc_dma *sdma = dma_chan_to_sirfsoc_dma(&schan->chan);
>         int cid = schan->chan.chan_id;
>         unsigned long flags;
> +       unsigned long loop_ctrl_val;
>
>         spin_lock_irqsave(&schan->lock, flags);
> -
> -       if (!sdma->is_marco)
> -               writel_relaxed(readl_relaxed(sdma->base +
> SIRFSOC_DMA_CH_LOOP_CTRL)
> -                       | ((1 << cid) | 1 << (cid + 16)),
> -                       sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
> -       else
> -               writel_relaxed((1 << cid) | 1 << (cid + 16),
> -                       sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
> -
> +       if (!sdma->is_marco) {
> +               loop_ctrl_val = readl_relaxed(sdma->base +
> +                               SIRFSOC_DMA_CH_LOOP_CTRL);
> +               switch (buf_index) {
> +               case 1:
> +                       writel_relaxed(loop_ctrl_val | (1 << cid),
> +                                       sdma->base +
> SIRFSOC_DMA_CH_LOOP_CTRL);
> +                       break;
> +               case 2:
> +                       writel_relaxed(loop_ctrl_val | 1 << (cid + 16),
> +                                       sdma->base +
> SIRFSOC_DMA_CH_LOOP_CTRL);
> +                       break;
> +               case 0:
> +               default:
> +                       writel_relaxed(loop_ctrl_val | (1 << cid) |
> +                                       1 << (cid + 16),
> +                                       sdma->base +
> SIRFSOC_DMA_CH_LOOP_CTRL);
> +                       break;
> +               }
> +       } else {
> +               switch (buf_index) {
> +               case 1:
> +                       writel_relaxed((1 << cid),
> +                                       sdma->base +
> SIRFSOC_DMA_CH_LOOP_CTRL);
> +                       break;
> +               case 2:
> +                       writel_relaxed((1 << (cid + 16)),
> +                                       sdma->base +
> SIRFSOC_DMA_CH_LOOP_CTRL);
> +                       break;
> +               case 0:
> +               default:
> +                       writel_relaxed((1 << cid) | 1 << (cid + 16),
> +                                       sdma->base +
> SIRFSOC_DMA_CH_LOOP_CTRL);
> +                       break;
> +               }
> +       }
>         spin_unlock_irqrestore(&schan->lock, flags);
>
>         return 0;
> @@ -365,9 +423,9 @@ static int sirfsoc_dma_control(struct dma_chan *chan,
> enum dma_ctrl_cmd cmd,
>
>         switch (cmd) {
>         case DMA_PAUSE:
> -               return sirfsoc_dma_pause_chan(schan);
> +               return sirfsoc_dma_pause_chan(schan, arg);
>         case DMA_RESUME:
> -               return sirfsoc_dma_resume_chan(schan);
> +               return sirfsoc_dma_resume_chan(schan, arg);
>         case DMA_TERMINATE_ALL:
>                 return sirfsoc_dma_terminate_all(schan);
>         case DMA_SLAVE_CONFIG:
> --
> 1.8.2.3


-barry


From festevam at gmail.com  Sun Jul 28 23:04:16 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 29 Jul 2013 00:04:16 -0300
Subject: [PATCH 2/2] ARM: imx_v6_v7_defconfig: Add SATA support
In-Reply-To: <1375067056-6370-1-git-send-email-festevam@gmail.com>
References: <1375067056-6370-1-git-send-email-festevam@gmail.com>
Message-ID: <1375067056-6370-2-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Let SATA support be built by default.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/configs/imx_v6_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index ab85d4a..2410bdc 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -97,6 +97,8 @@ CONFIG_SCSI_LOGGING=y
 CONFIG_SCSI_SCAN_ASYNC=y
 # CONFIG_SCSI_LOWLEVEL is not set
 CONFIG_ATA=y
+CONFIG_SATA_AHCI_PLATFORM=y
+CONFIG_AHCI_IMX=y
 CONFIG_PATA_IMX=y
 CONFIG_NETDEVICES=y
 # CONFIG_NET_VENDOR_BROADCOM is not set
-- 
1.8.1.2



From festevam at gmail.com  Sun Jul 28 23:04:15 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 29 Jul 2013 00:04:15 -0300
Subject: [PATCH 1/2] ARM: imx_v6_v7_defconfig: Cleanup imx_v6_v7_defconfig
Message-ID: <1375067056-6370-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Generate imx_v6_v7_defconfig by doing:

make savedefconfig

cp defconfig arch/arm/configs/imx_v6_v7_defconfig

No functional change. The goal here is to cleanup imx_v6_v7_defconfig file to
make easier and cleaner the addition of new entries.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/configs/imx_v6_v7_defconfig | 37 +++++++++++++-----------------------
 1 file changed, 13 insertions(+), 24 deletions(-)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f1662d3..ab85d4a 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -1,4 +1,3 @@
-CONFIG_EXPERIMENTAL=y
 # CONFIG_LOCALVERSION_AUTO is not set
 CONFIG_KERNEL_LZO=y
 CONFIG_SYSVIPC=y
@@ -17,10 +16,8 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 # CONFIG_BLK_DEV_BSG is not set
-CONFIG_ARCH_MXC=y
 CONFIG_ARCH_MULTI_V6=y
-CONFIG_ARCH_MULTI_V7=y
-CONFIG_MACH_IMX31_DT=y
+CONFIG_ARCH_MXC=y
 CONFIG_MACH_MX31LILLY=y
 CONFIG_MACH_MX31LITE=y
 CONFIG_MACH_PCM037=y
@@ -30,6 +27,7 @@ CONFIG_MACH_MX31MOBOARD=y
 CONFIG_MACH_QONG=y
 CONFIG_MACH_ARMADILLO5X0=y
 CONFIG_MACH_KZM_ARM11_01=y
+CONFIG_MACH_IMX31_DT=y
 CONFIG_MACH_PCM043=y
 CONFIG_MACH_MX35_3DS=y
 CONFIG_MACH_VPR200=y
@@ -39,7 +37,6 @@ CONFIG_SOC_IMX53=y
 CONFIG_SOC_IMX6Q=y
 CONFIG_SOC_IMX6SL=y
 CONFIG_SOC_VF610=y
-CONFIG_MXC_PWM=y
 CONFIG_SMP=y
 CONFIG_VMSPLIT_2G=y
 CONFIG_PREEMPT_VOLUNTARY=y
@@ -72,7 +69,6 @@ CONFIG_IMX_WEIM=y
 CONFIG_CONNECTOR=y
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
 CONFIG_MTD_BLOCK=y
 CONFIG_MTD_CFI=y
 CONFIG_MTD_JEDECPROBE=y
@@ -104,7 +100,6 @@ CONFIG_ATA=y
 CONFIG_PATA_IMX=y
 CONFIG_NETDEVICES=y
 # CONFIG_NET_VENDOR_BROADCOM is not set
-# CONFIG_NET_VENDOR_CHELSIO is not set
 CONFIG_CS89x0=y
 CONFIG_CS89x0_PLATFORM=y
 # CONFIG_NET_VENDOR_FARADAY is not set
@@ -140,11 +135,9 @@ CONFIG_SERIAL_FSL_LPUART=y
 CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
 CONFIG_HW_RANDOM=y
 CONFIG_HW_RANDOM_MXC_RNGA=y
-CONFIG_I2C=y
 # CONFIG_I2C_COMPAT is not set
 CONFIG_I2C_CHARDEV=y
 # CONFIG_I2C_HELPER_AUTO is not set
-CONFIG_I2C_ALGOBIT=m
 CONFIG_I2C_ALGOPCF=m
 CONFIG_I2C_ALGOPCA=m
 CONFIG_I2C_IMX=y
@@ -160,32 +153,26 @@ CONFIG_MFD_MC13XXX_SPI=y
 CONFIG_MFD_MC13XXX_I2C=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
-CONFIG_REGULATOR_DA9052=y
 CONFIG_REGULATOR_ANATOP=y
+CONFIG_REGULATOR_DA9052=y
 CONFIG_REGULATOR_MC13783=y
 CONFIG_REGULATOR_MC13892=y
 CONFIG_MEDIA_SUPPORT=y
-CONFIG_VIDEO_DEV=y
-CONFIG_V4L_PLATFORM_DRIVERS=y
 CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_V4L_PLATFORM_DRIVERS=y
 CONFIG_SOC_CAMERA=y
-CONFIG_SOC_CAMERA_OV2640=y
-CONFIG_DRM=y
 CONFIG_VIDEO_MX3=y
 CONFIG_V4L_MEM2MEM_DRIVERS=y
 CONFIG_VIDEO_CODA=y
-CONFIG_FB=y
-CONFIG_LCD_PLATFORM=y
+CONFIG_SOC_CAMERA_OV2640=y
+CONFIG_DRM=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_L4F00242T03=y
+CONFIG_LCD_PLATFORM=y
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_PWM=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
-CONFIG_FONTS=y
-CONFIG_FONT_8x8=y
-CONFIG_FONT_8x16=y
 CONFIG_LOGO=y
 CONFIG_SOUND=y
 CONFIG_SND=y
@@ -195,16 +182,15 @@ CONFIG_SND_SOC_PHYCORE_AC97=y
 CONFIG_SND_SOC_EUKREA_TLV320=y
 CONFIG_SND_SOC_IMX_WM8962=y
 CONFIG_SND_SOC_IMX_SGTL5000=y
-CONFIG_SND_SOC_IMX_MC13783=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_MXC=y
+CONFIG_USB_STORAGE=y
 CONFIG_USB_CHIPIDEA=y
 CONFIG_USB_CHIPIDEA_HOST=y
 CONFIG_USB_PHY=y
 CONFIG_NOP_USB_XCEIV=y
 CONFIG_USB_MXS_PHY=y
-CONFIG_USB_STORAGE=y
 CONFIG_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
@@ -221,10 +207,10 @@ CONFIG_IMX_SDMA=y
 CONFIG_MXS_DMA=y
 CONFIG_STAGING=y
 CONFIG_DRM_IMX=y
-CONFIG_DRM_IMX_TVE=y
-CONFIG_DRM_IMX_LDB=y
 CONFIG_DRM_IMX_FB_HELPER=y
 CONFIG_DRM_IMX_PARALLEL_DISPLAY=y
+CONFIG_DRM_IMX_TVE=y
+CONFIG_DRM_IMX_LDB=y
 CONFIG_DRM_IMX_IPUV3_CORE=y
 CONFIG_DRM_IMX_IPUV3=y
 CONFIG_COMMON_CLK_DEBUG=y
@@ -278,3 +264,6 @@ CONFIG_CRC_CCITT=m
 CONFIG_CRC_T10DIF=y
 CONFIG_CRC7=m
 CONFIG_LIBCRC32C=m
+CONFIG_FONTS=y
+CONFIG_FONT_8x8=y
+CONFIG_FONT_8x16=y
-- 
1.8.1.2



From amit.daniel at samsung.com  Mon Jul 29 00:46:14 2013
From: amit.daniel at samsung.com (amit daniel kachhap)
Date: Mon, 29 Jul 2013 10:16:14 +0530
Subject: [PATCH] ARM: EXYNOS: cpuidle: Skip C1 cpuidle state for exynos5440
In-Reply-To: <51F4F317.1040001@linaro.org>
References: <0e7d01ce8840$82f79070$88e6b150$@org>
 <0eaf01ce8863$89d3c4e0$9d7b4ea0$@org> <51F4C3D1.2060901@linaro.org>
 <1877730.qZVs3NAG5h@flatron> <51F4F317.1040001@linaro.org>
Message-ID: <CADGdYn761S+rDe=GaypFwAYdtQxFZRv0W=jmX9-KomogK5T7ww@mail.gmail.com>

Hi Daniel/Tomasz,

>From the discussion I can conclude that SOC check is needed in the
cpuidle driver for deeper C states. Only the question is where to
insert this.
Also to perform the SOC there can be 2 ways like
1) each SOC check 4120, 4412, 5250 etc (long list)
2) negate the nonsupporting SOC's like 5440 (small list like current patch)
Any opinion?
 As Bartlomiej suggested that this patch conflicts with Daniel's
earlier patch http://marc.info/?l=linux-arm-kernel&m=137467935712513&w=2
So I can re-base my patch on top of this one if needed.

Thanks,
Amit Daniel

On Sun, Jul 28, 2013 at 4:01 PM, Daniel Lezcano
<daniel.lezcano at linaro.org> wrote:
> On 07/28/2013 11:22 AM, Tomasz Figa wrote:
>> On Sunday 28 of July 2013 09:10:09 Daniel Lezcano wrote:
>>> On 07/24/2013 01:47 PM, Kukjin Kim wrote:
>>>> Amit Daniel Kachhap wrote:
>>>>> This patch skips the deep C1(AFTR -Arm off top running) state for
>>>>> exynos5440
>>>>> soc as this soc does not support this state. All the cpu's only
>>>>> allows the basic
>>>>> C0 state.
>>>>>
>>>>> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
>>>>> ---
>>>>>
>>>>>  arch/arm/mach-exynos/cpuidle.c |    2 +-
>>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
>>>>> exynos/cpuidle.c
>>>>> index 17a18ff..9a776a1 100644
>>>>> --- a/arch/arm/mach-exynos/cpuidle.c
>>>>> +++ b/arch/arm/mach-exynos/cpuidle.c
>>>>> @@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void)
>>>>>
>>>>>            device->cpu = cpu_id;
>>>>>
>>>>>            /* Support IDLE only */
>>>>>
>>>>> -          if (cpu_id != 0)
>>>>> +          if (soc_is_exynos5440() || cpu_id != 0)
>>>>>
>>>>>                    device->state_count = 1;
>>>>>
>>>>>            ret = cpuidle_register_device(device);
>>>>>
>>>>> --
>>>>> 1.7.1
>>>>
>>>> Applied, thanks.
>>>
>>> You shouldn't have. This patch means exynos5540 has no cpuidle driver at
>>> all. It should be fixed in the Kconfig to unselect CONFIG_CPU_IDLE for
>>> an exynos5540.
>>
>> To shed more light on this, let me add that you need to register a cpuidle
>> driver only if you have more states than a simple WFI or you need some
>> crazy steps to enter WFI. Default setup falls back to generic ARM WFI.
>> (Daniel, do we get the nice idle stats as provided by cpuidle core then?)
>
> Nope, but with one state, idle vs busy stats do the trick.
>
> BTW, I am writing a tool to do some stats based on the idle events [1].
> It is still at a very early development stage but we can get some
> interesting informations.
>
>
>> Anyway, Exynos cpuidle is using an initcall to initialize and we support
>> multiple Exynos SoCs in single zImage, so deselecting CONFIG_CPU_IDLE is
>> not an option.
>
> Good point.
>
>> Considering multiplatform requirements, the driver has to
>> be modified to initialize only on supported platforms, either by:
>>
>>  a) dropping the initcall and calling the init function directly from
>> arch/arm/mach-exynos
>>
>>  or
>>
>>  b) checking if machine we are running on is supported, which would mean a
>> long list of all Exynos SoCs that needs to be checked.
>>
>> An evolution of option a) is registering a platform device somewhere in
>> arch/arm/mach-exynos and making exynos-cpuidle a platform driver.
>
> Yes, I am favorable to this solution [2].
>
>> The
>> problem is that you must register a static platform device from arch code,
>> because cpuidle is not a real hardware block that can be put into device
>> tree.
>
> Thanks
>   -- Daniel
>
> [1] https://git.linaro.org/gitweb?p=people/dlezcano/idlestat.git;a=summary
> [2] http://patches.linaro.org/18368/
>
> --
>  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From joe at perches.com  Mon Jul 29 01:29:02 2013
From: joe at perches.com (Joe Perches)
Date: Sun, 28 Jul 2013 22:29:02 -0700
Subject: [PATCH 0/3] networking: Use ETH_ALEN where appropriate
Message-ID: <cover.1375075325.git.joe@perches.com>

Convert the uses mac addresses to ETH_ALEN so
it's easier to find and verify where mac addresses
need to be __aligned(2)

Joe Perches (3):
  uapi: Convert some uses of 6 to ETH_ALEN
  include: Convert ethernet mac address declarations to use ETH_ALEN
  ethernet: Convert mac address uses of 6 to ETH_ALEN

 drivers/net/ethernet/8390/ax88796.c                |  4 +-
 drivers/net/ethernet/amd/pcnet32.c                 |  6 +--
 drivers/net/ethernet/broadcom/cnic_if.h            |  6 +--
 drivers/net/ethernet/dec/tulip/tulip_core.c        |  8 +--
 drivers/net/ethernet/i825xx/sun3_82586.h           |  4 +-
 drivers/net/ethernet/myricom/myri10ge/myri10ge.c   |  2 +-
 drivers/net/ethernet/nuvoton/w90p910_ether.c       |  4 +-
 drivers/net/ethernet/pasemi/pasemi_mac.c           | 13 ++---
 drivers/net/ethernet/pasemi/pasemi_mac.h           |  4 +-
 drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c |  4 +-
 drivers/net/ethernet/qlogic/qlge/qlge.h            |  2 +-
 include/acpi/actbl2.h                              |  4 +-
 include/linux/dm9000.h                             |  4 +-
 include/linux/fs_enet_pd.h                         |  3 +-
 include/linux/ieee80211.h                          | 59 +++++++++++-----------
 include/linux/mlx4/device.h                        | 11 ++--
 include/linux/mlx4/qp.h                            |  5 +-
 include/linux/mv643xx_eth.h                        |  3 +-
 include/linux/sh_eth.h                             |  3 +-
 include/linux/smsc911x.h                           |  3 +-
 include/linux/uwb/spec.h                           |  5 +-
 include/media/tveeprom.h                           |  4 +-
 include/net/irda/irlan_common.h                    |  3 +-
 include/uapi/linux/dn.h                            |  3 +-
 include/uapi/linux/if_bridge.h                     |  3 +-
 include/uapi/linux/netfilter_bridge/ebt_802_3.h    |  5 +-
 include/uapi/linux/netfilter_ipv4/ipt_CLUSTERIP.h  |  3 +-
 include/uapi/linux/virtio_net.h                    |  2 +-
 include/uapi/linux/wimax/i2400m.h                  |  4 +-
 29 files changed, 103 insertions(+), 81 deletions(-)

-- 
1.8.1.2.459.gbcd45b4.dirty



From joe at perches.com  Mon Jul 29 01:29:05 2013
From: joe at perches.com (Joe Perches)
Date: Sun, 28 Jul 2013 22:29:05 -0700
Subject: [PATCH 3/3] ethernet: Convert mac address uses of 6 to ETH_ALEN
In-Reply-To: <cover.1375075325.git.joe@perches.com>
References: <cover.1375075325.git.joe@perches.com>
Message-ID: <6b2ad9d97f6a38382e34d9da52cb21f3c7a86c11.1375075325.git.joe@perches.com>

Use the normal #define to help grep find mac addresses
and ensure that addresses are aligned.

Move one address in pasemi_mac.h for alignment.

Signed-off-by: Joe Perches <joe at perches.com>
---
 drivers/net/ethernet/8390/ax88796.c                |  4 ++--
 drivers/net/ethernet/amd/pcnet32.c                 |  6 +++---
 drivers/net/ethernet/broadcom/cnic_if.h            |  6 +++---
 drivers/net/ethernet/dec/tulip/tulip_core.c        |  8 +++++---
 drivers/net/ethernet/i825xx/sun3_82586.h           |  4 ++--
 drivers/net/ethernet/myricom/myri10ge/myri10ge.c   |  2 +-
 drivers/net/ethernet/nuvoton/w90p910_ether.c       |  4 ++--
 drivers/net/ethernet/pasemi/pasemi_mac.c           | 13 +++++++------
 drivers/net/ethernet/pasemi/pasemi_mac.h           |  4 ++--
 drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c |  4 ++--
 drivers/net/ethernet/qlogic/qlge/qlge.h            |  2 +-
 11 files changed, 30 insertions(+), 27 deletions(-)

diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax88796.c
index e1d2643..b7232a9 100644
--- a/drivers/net/ethernet/8390/ax88796.c
+++ b/drivers/net/ethernet/8390/ax88796.c
@@ -707,7 +707,7 @@ static int ax_init_dev(struct net_device *dev)
 
 #ifdef CONFIG_AX88796_93CX6
 	if (ax->plat->flags & AXFLG_HAS_93CX6) {
-		unsigned char mac_addr[6];
+		unsigned char mac_addr[ETH_ALEN];
 		struct eeprom_93cx6 eeprom;
 
 		eeprom.data = ei_local;
@@ -719,7 +719,7 @@ static int ax_init_dev(struct net_device *dev)
 				       (__le16 __force *)mac_addr,
 				       sizeof(mac_addr) >> 1);
 
-		memcpy(dev->dev_addr, mac_addr, 6);
+		memcpy(dev->dev_addr, mac_addr, ETH_ALEN);
 	}
 #endif
 	if (ax->plat->wordlength == 2) {
diff --git a/drivers/net/ethernet/amd/pcnet32.c b/drivers/net/ethernet/amd/pcnet32.c
index ed21307..2d8e288 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -1521,7 +1521,7 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct pci_dev *pdev)
 	char *chipname;
 	struct net_device *dev;
 	const struct pcnet32_access *a = NULL;
-	u8 promaddr[6];
+	u8 promaddr[ETH_ALEN];
 	int ret = -ENODEV;
 
 	/* reset the chip */
@@ -1665,10 +1665,10 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct pci_dev *pdev)
 	}
 
 	/* read PROM address and compare with CSR address */
-	for (i = 0; i < 6; i++)
+	for (i = 0; i < ETH_ALEN; i++)
 		promaddr[i] = inb(ioaddr + i);
 
-	if (memcmp(promaddr, dev->dev_addr, 6) ||
+	if (memcmp(promaddr, dev->dev_addr, ETH_ALEN) ||
 	    !is_valid_ether_addr(dev->dev_addr)) {
 		if (is_valid_ether_addr(promaddr)) {
 			if (pcnet32_debug & NETIF_MSG_PROBE) {
diff --git a/drivers/net/ethernet/broadcom/cnic_if.h b/drivers/net/ethernet/broadcom/cnic_if.h
index ec9bb9a..7902e0c 100644
--- a/drivers/net/ethernet/broadcom/cnic_if.h
+++ b/drivers/net/ethernet/broadcom/cnic_if.h
@@ -238,8 +238,8 @@ struct cnic_sock {
 	u16	src_port;
 	u16	dst_port;
 	u16	vlan_id;
-	unsigned char old_ha[6];
-	unsigned char ha[6];
+	unsigned char old_ha[ETH_ALEN];
+	unsigned char ha[ETH_ALEN];
 	u32	mtu;
 	u32	cid;
 	u32	l5_cid;
@@ -308,7 +308,7 @@ struct cnic_dev {
 #define CNIC_F_BNX2_CLASS	3
 #define CNIC_F_BNX2X_CLASS	4
 	atomic_t	ref_count;
-	u8		mac_addr[6];
+	u8		mac_addr[ETH_ALEN];
 
 	int		max_iscsi_conn;
 	int		max_fcoe_conn;
diff --git a/drivers/net/ethernet/dec/tulip/tulip_core.c b/drivers/net/ethernet/dec/tulip/tulip_core.c
index c94152f..4e8cfa2 100644
--- a/drivers/net/ethernet/dec/tulip/tulip_core.c
+++ b/drivers/net/ethernet/dec/tulip/tulip_core.c
@@ -1304,7 +1304,9 @@ static int tulip_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
 	struct tulip_private *tp;
 	/* See note below on the multiport cards. */
-	static unsigned char last_phys_addr[6] = {0x00, 'L', 'i', 'n', 'u', 'x'};
+	static unsigned char last_phys_addr[ETH_ALEN] = {
+		0x00, 'L', 'i', 'n', 'u', 'x'
+	};
 	static int last_irq;
 	static int multiport_cnt;	/* For four-port boards w/one EEPROM */
 	int i, irq;
@@ -1627,8 +1629,8 @@ static int tulip_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 		dev->dev_addr[i] = last_phys_addr[i] + 1;
 #if defined(CONFIG_SPARC)
 		addr = of_get_property(dp, "local-mac-address", &len);
-		if (addr && len == 6)
-			memcpy(dev->dev_addr, addr, 6);
+		if (addr && len == ETH_ALEN)
+			memcpy(dev->dev_addr, addr, ETH_ALEN);
 #endif
 #if defined(__i386__) || defined(__x86_64__)	/* Patch up x86 BIOS bug. */
 		if (last_irq)
diff --git a/drivers/net/ethernet/i825xx/sun3_82586.h b/drivers/net/ethernet/i825xx/sun3_82586.h
index 93346f0..79aef68 100644
--- a/drivers/net/ethernet/i825xx/sun3_82586.h
+++ b/drivers/net/ethernet/i825xx/sun3_82586.h
@@ -133,8 +133,8 @@ struct rfd_struct
   unsigned char  last;		/* Bit15,Last Frame on List / Bit14,suspend */
   unsigned short next;		/* linkoffset to next RFD */
   unsigned short rbd_offset;	/* pointeroffset to RBD-buffer */
-  unsigned char  dest[6];	/* ethernet-address, destination */
-  unsigned char  source[6];	/* ethernet-address, source */
+  unsigned char  dest[ETH_ALEN];	/* ethernet-address, destination */
+  unsigned char  source[ETH_ALEN];	/* ethernet-address, source */
   unsigned short length;	/* 802.3 frame-length */
   unsigned short zero_dummy;	/* dummy */
 };
diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
index 967bae8..d4cdf4d 100644
--- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
+++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
@@ -244,7 +244,7 @@ struct myri10ge_priv {
 	int fw_ver_minor;
 	int fw_ver_tiny;
 	int adopted_rx_filter_bug;
-	u8 mac_addr[6];		/* eeprom mac address */
+	u8 mac_addr[ETH_ALEN];		/* eeprom mac address */
 	unsigned long serial_number;
 	int vendor_specific_offset;
 	int fw_multicast_support;
diff --git a/drivers/net/ethernet/nuvoton/w90p910_ether.c b/drivers/net/ethernet/nuvoton/w90p910_ether.c
index e88bdb1..dcfe58f 100644
--- a/drivers/net/ethernet/nuvoton/w90p910_ether.c
+++ b/drivers/net/ethernet/nuvoton/w90p910_ether.c
@@ -922,7 +922,7 @@ static void __init get_mac_address(struct net_device *dev)
 {
 	struct w90p910_ether *ether = netdev_priv(dev);
 	struct platform_device *pdev;
-	char addr[6];
+	char addr[ETH_ALEN];
 
 	pdev = ether->pdev;
 
@@ -934,7 +934,7 @@ static void __init get_mac_address(struct net_device *dev)
 	addr[5] = 0xa8;
 
 	if (is_valid_ether_addr(addr))
-		memcpy(dev->dev_addr, &addr, 0x06);
+		memcpy(dev->dev_addr, &addr, ETH_ALEN);
 	else
 		dev_err(&pdev->dev, "invalid mac address\n");
 }
diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c b/drivers/net/ethernet/pasemi/pasemi_mac.c
index a5f0b5d..f21ae7b 100644
--- a/drivers/net/ethernet/pasemi/pasemi_mac.c
+++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
@@ -191,7 +191,7 @@ static int pasemi_get_mac_addr(struct pasemi_mac *mac)
 	struct device_node *dn = pci_device_to_OF_node(pdev);
 	int len;
 	const u8 *maddr;
-	u8 addr[6];
+	u8 addr[ETH_ALEN];
 
 	if (!dn) {
 		dev_dbg(&pdev->dev,
@@ -201,8 +201,8 @@ static int pasemi_get_mac_addr(struct pasemi_mac *mac)
 
 	maddr = of_get_property(dn, "local-mac-address", &len);
 
-	if (maddr && len == 6) {
-		memcpy(mac->mac_addr, maddr, 6);
+	if (maddr && len == ETH_ALEN) {
+		memcpy(mac->mac_addr, maddr, ETH_ALEN);
 		return 0;
 	}
 
@@ -219,14 +219,15 @@ static int pasemi_get_mac_addr(struct pasemi_mac *mac)
 		return -ENOENT;
 	}
 
-	if (sscanf(maddr, "%hhx:%hhx:%hhx:%hhx:%hhx:%hhx", &addr[0],
-		   &addr[1], &addr[2], &addr[3], &addr[4], &addr[5]) != 6) {
+	if (sscanf(maddr, "%hhx:%hhx:%hhx:%hhx:%hhx:%hhx",
+		   &addr[0], &addr[1], &addr[2], &addr[3], &addr[4], &addr[5])
+	    != ETH_ALEN) {
 		dev_warn(&pdev->dev,
 			 "can't parse mac address, not configuring\n");
 		return -EINVAL;
 	}
 
-	memcpy(mac->mac_addr, addr, 6);
+	memcpy(mac->mac_addr, addr, ETH_ALEN);
 
 	return 0;
 }
diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.h b/drivers/net/ethernet/pasemi/pasemi_mac.h
index e2f4efa..649fdb4 100644
--- a/drivers/net/ethernet/pasemi/pasemi_mac.h
+++ b/drivers/net/ethernet/pasemi/pasemi_mac.h
@@ -79,11 +79,11 @@ struct pasemi_mac {
 	int		last_cs;
 	int		num_cs;
 	u32		dma_if;
-	u8		type;
 #define MAC_TYPE_GMAC	1
 #define MAC_TYPE_XAUI	2
 
-	u8		mac_addr[6];
+	u8		mac_addr[ETH_ALEN];
+	u8		type;
 
 	struct net_lro_mgr	lro_mgr;
 	struct net_lro_desc	lro_desc[MAX_LRO_DESCRIPTORS];
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
index 9fbb1cd..8375cbd 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
@@ -536,10 +536,10 @@ static void netxen_p2_nic_set_multi(struct net_device *netdev)
 {
 	struct netxen_adapter *adapter = netdev_priv(netdev);
 	struct netdev_hw_addr *ha;
-	u8 null_addr[6];
+	u8 null_addr[ETH_ALEN];
 	int i;
 
-	memset(null_addr, 0, 6);
+	memset(null_addr, 0, ETH_ALEN);
 
 	if (netdev->flags & IFF_PROMISC) {
 
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge.h b/drivers/net/ethernet/qlogic/qlge/qlge.h
index 7e8d682..8994337 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge.h
+++ b/drivers/net/ethernet/qlogic/qlge/qlge.h
@@ -2149,7 +2149,7 @@ struct ql_adapter {
 	struct timer_list timer;
 	atomic_t lb_count;
 	/* Keep local copy of current mac address. */
-	char current_mac_addr[6];
+	char current_mac_addr[ETH_ALEN];
 };
 
 /*
-- 
1.8.1.2.459.gbcd45b4.dirty



From kgene at kernel.org  Mon Jul 29 01:34:06 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Mon, 29 Jul 2013 14:34:06 +0900
Subject: [PATCH] ARM: EXYNOS: cpuidle: Skip C1 cpuidle state for exynos5440
In-Reply-To: <CADGdYn761S+rDe=GaypFwAYdtQxFZRv0W=jmX9-KomogK5T7ww@mail.gmail.com>
References: <0e7d01ce8840$82f79070$88e6b150$@org>
 <0eaf01ce8863$89d3c4e0$9d7b4ea0$@org> <51F4C3D1.2060901@linaro.org>
 <1877730.qZVs3NAG5h@flatron> <51F4F317.1040001@linaro.org>
 <CADGdYn761S+rDe=GaypFwAYdtQxFZRv0W=jmX9-KomogK5T7ww@mail.gmail.com>
Message-ID: <167801ce8c1d$3e6ceff0$bb46cfd0$@org>

amit daniel kachhap wrote:
> 
> Hi Daniel/Tomasz,
> 
> From the discussion I can conclude that SOC check is needed in the
> cpuidle driver for deeper C states. Only the question is where to
> insert this.
> Also to perform the SOC there can be 2 ways like
> 1) each SOC check 4120, 4412, 5250 etc (long list)
> 2) negate the nonsupporting SOC's like 5440 (small list like current patch)
> Any opinion?

I?d preferred to use 2nd :)

>  As Bartlomiej suggested that this patch conflicts with Daniel's
> earlier patch http://marc.info/?l=linux-arm-kernel&m=137467935712513&w=2
> So I can re-base my patch on top of this one if needed.
> 
Sounds good to me.

Thanks,
Kukjin

> Thanks,
> Amit Daniel
> 
> On Sun, Jul 28, 2013 at 4:01 PM, Daniel Lezcano
> <daniel.lezcano at linaro.org> wrote:
> > On 07/28/2013 11:22 AM, Tomasz Figa wrote:
> >> On Sunday 28 of July 2013 09:10:09 Daniel Lezcano wrote:
> >>> On 07/24/2013 01:47 PM, Kukjin Kim wrote:
> >>>> Amit Daniel Kachhap wrote:
> >>>>> This patch skips the deep C1(AFTR -Arm off top running) state for
> >>>>> exynos5440
> >>>>> soc as this soc does not support this state. All the cpu's only
> >>>>> allows the basic
> >>>>> C0 state.
> >>>>>
> >>>>> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
> >>>>> ---
> >>>>>
> >>>>>  arch/arm/mach-exynos/cpuidle.c |    2 +-
> >>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
> >>>>>
> >>>>> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
> >>>>> exynos/cpuidle.c
> >>>>> index 17a18ff..9a776a1 100644
> >>>>> --- a/arch/arm/mach-exynos/cpuidle.c
> >>>>> +++ b/arch/arm/mach-exynos/cpuidle.c
> >>>>> @@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void)
> >>>>>
> >>>>>            device->cpu = cpu_id;
> >>>>>
> >>>>>            /* Support IDLE only */
> >>>>>
> >>>>> -          if (cpu_id != 0)
> >>>>> +          if (soc_is_exynos5440() || cpu_id != 0)
> >>>>>
> >>>>>                    device->state_count = 1;
> >>>>>
> >>>>>            ret = cpuidle_register_device(device);
> >>>>>
> >>>>> --
> >>>>> 1.7.1
> >>>>
> >>>> Applied, thanks.
> >>>
> >>> You shouldn't have. This patch means exynos5540 has no cpuidle driver
> at
> >>> all. It should be fixed in the Kconfig to unselect CONFIG_CPU_IDLE for
> >>> an exynos5540.
> >>
> >> To shed more light on this, let me add that you need to register a
> cpuidle
> >> driver only if you have more states than a simple WFI or you need some
> >> crazy steps to enter WFI. Default setup falls back to generic ARM WFI.
> >> (Daniel, do we get the nice idle stats as provided by cpuidle core
> then?)
> >
> > Nope, but with one state, idle vs busy stats do the trick.
> >
> > BTW, I am writing a tool to do some stats based on the idle events [1].
> > It is still at a very early development stage but we can get some
> > interesting informations.
> >
> >
> >> Anyway, Exynos cpuidle is using an initcall to initialize and we
> support
> >> multiple Exynos SoCs in single zImage, so deselecting CONFIG_CPU_IDLE
> is
> >> not an option.
> >
> > Good point.
> >
> >> Considering multiplatform requirements, the driver has to
> >> be modified to initialize only on supported platforms, either by:
> >>
> >>  a) dropping the initcall and calling the init function directly from
> >> arch/arm/mach-exynos
> >>
> >>  or
> >>
> >>  b) checking if machine we are running on is supported, which would
> mean a
> >> long list of all Exynos SoCs that needs to be checked.
> >>
> >> An evolution of option a) is registering a platform device somewhere in
> >> arch/arm/mach-exynos and making exynos-cpuidle a platform driver.
> >
> > Yes, I am favorable to this solution [2].
> >
> >> The
> >> problem is that you must register a static platform device from arch
> code,
> >> because cpuidle is not a real hardware block that can be put into
> device
> >> tree.



From paul at pwsan.com  Mon Jul 29 01:46:47 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 29 Jul 2013 05:46:47 +0000 (UTC)
Subject: OMAP baseline test results for v3.11-rc3
Message-ID: <alpine.DEB.2.02.1307290545030.30864@utopia.booyaka.com>


Here are some basic OMAP test results for Linux v3.11-rc3.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v3.11-rc3/20130728224046/


Test summary
------------

Build: uImage:
    Pass (14/14): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
		  omap1_defconfig_1510innovator_only,
		  omap1_defconfig_5912osk_only, omap2plus_defconfig,
		  omap2plus_defconfig_2430sdp_only,
		  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
		  omap2plus_defconfig_omap2_4_only,
		  omap2plus_defconfig_omap3_4_only,
		  rmk_omap3430_ldp_allnoconfig,
		  rmk_omap3430_ldp_oldconfig,
		  rmk_omap4430_sdp_allnoconfig

Build: uImage+dtb:
    Pass ( 3/ 3): am33xx_only/am335x-bone,
		  omap2plus_defconfig/omap4-panda,
		  omap2plus_defconfig/omap4-panda-es

Build: zImage:
    Pass ( 1/ 1): omap2plus_defconfig

Boot to userspace:
    FAIL ( 5/11): 2430sdp, 3530es3beagle, 3730beaglexm, 5912osk,
		  am335xbonelt
    Pass ( 6/11): 3517evm, 37xxevm, 4430es2panda, 4460pandaes,
		  am335xbone, cmt3517

PM: chip retention via suspend:
    FAIL ( 4/ 6): 2430sdp, 3530es3beagle, 3730beaglexm, 4430es2panda
    Pass ( 2/ 6): 37xxevm, 4460pandaes

PM: chip retention via dynamic idle:
    FAIL ( 5/ 6): 2430sdp, 3530es3beagle, 3730beaglexm, 4430es2panda,
		  4460pandaes
    Pass ( 1/ 6): 37xxevm

PM: chip off except CORE via suspend:
    FAIL ( 1/ 1): 3730beaglexm

PM: chip off except CORE via dynamic idle:
    FAIL ( 1/ 1): 3730beaglexm

PM: chip off via suspend:
    FAIL ( 3/ 4): 3530es3beagle, 4430es2panda, 4460pandaes
    Pass ( 1/ 4): 37xxevm

PM: chip off via dynamic idle:
    FAIL ( 3/ 4): 3530es3beagle, 4430es2panda, 4460pandaes
    Pass ( 1/ 4): 37xxevm


vmlinux object size
(delta in bytes from test_v3.11-rc2 (3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b)):
   text     data      bss    total  kernel
  -1879     -216      -64    -2159  am33xx_only
   +200      -16        0     +184  n800_multi_omap2xxx
    +56        0        0      +56  n800_only_a
   +176      +64        0     +240  omap1_defconfig
   +176      +64        0     +240  omap1_defconfig_1510innovator_only
   +176      +64        0     +240  omap1_defconfig_5912osk_only
  -5919     -208      -64    -6191  omap2plus_defconfig
  -5967     -280        0    -6247  omap2plus_defconfig_2430sdp_only
  -5919     -272      -64    -6255  omap2plus_defconfig_cpupm
  -1823     -248      -64    -2135  omap2plus_defconfig_no_pm
  -5919     -240      -64    -6223  omap2plus_defconfig_omap2_4_only
  -1823     -208      -64    -2095  omap2plus_defconfig_omap3_4_only
   +420       +8     -160     +268  rmk_omap3430_ldp_allnoconfig
   -371     -248        0     -619  rmk_omap3430_ldp_oldconfig
   +476      +12     -216     +272  rmk_omap4430_sdp_allnoconfig

Boot-time memory difference
(delta in bytes from test_v3.11-rc2 (3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b))
  avail  rsrvd   high  freed  board          kconfig
    -4k     4k      .      .  am335xbonelt   am33xx_only



From baruch at tkos.co.il  Mon Jul 29 01:59:39 2013
From: baruch at tkos.co.il (Baruch Siach)
Date: Mon, 29 Jul 2013 08:59:39 +0300
Subject: [PATCH] time: sched_clock: fix integer overflow
In-Reply-To: <232c026d1b8d2556679aea56cf77a6811f9a96c5.1374054369.git.baruch@tkos.co.il>
References: <232c026d1b8d2556679aea56cf77a6811f9a96c5.1374054369.git.baruch@tkos.co.il>
Message-ID: <20130729055939.GK5161@tarshish>

Hi Thomas, John,

On Wed, Jul 17, 2013 at 12:46:53PM +0300, Baruch Siach wrote:
> The expression '(1 << 32)' happens to evaluate as 0 on ARM, but it evaluates as
> 1 on xtensa and x86_64. This zeros sched_clock_mask, and breaks sched_clock().
> Set the type of 1 to 'unsigned long long' to get the value we need.

Ping? -rc3 is out, and this bug (which currently breaks xtensa) is not fixed 
yet. Please consider applying.

baruch

> Reported-by: Max Filippov <jcmvbkbc at gmail.com>
> Tested-by: Max Filippov <jcmvbkbc at gmail.com>
> Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>
> Signed-off-by: Baruch Siach <baruch at tkos.co.il>
> ---
>  kernel/time/sched_clock.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
> index a326f27..0b479a6 100644
> --- a/kernel/time/sched_clock.c
> +++ b/kernel/time/sched_clock.c
> @@ -121,7 +121,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
>  	BUG_ON(bits > 32);
>  	WARN_ON(!irqs_disabled());
>  	read_sched_clock = read;
> -	sched_clock_mask = (1 << bits) - 1;
> +	sched_clock_mask = (1ULL << bits) - 1;
>  	cd.rate = rate;
>  
>  	/* calculate the mult/shift to convert counter ticks to ns. */
> -- 

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -


From B18965 at freescale.com  Mon Jul 29 02:13:51 2013
From: B18965 at freescale.com (Wang Huan-B18965)
Date: Mon, 29 Jul 2013 06:13:51 +0000
Subject: [PATCH v2 0/5] ARM: vf610: Add DCU framebuffer driver for
 Vybrid VF610 platform
In-Reply-To: <81BA6E5E0BC2344391CABCEE22D1B6D83AA3AE@039-SN1MPN1-004.039d.mgd.msft.net>
References: <1373609276-14566-1-git-send-email-b18965@freescale.com>
 <81BA6E5E0BC2344391CABCEE22D1B6D83AA3AE@039-SN1MPN1-004.039d.mgd.msft.net>
Message-ID: <81BA6E5E0BC2344391CABCEE22D1B6D83C0479@039-SN1MPN1-002.039d.mgd.msft.net>

Hi, Jean-Christophe, Tomi,

       Do you have any comments for these patches?

       Thanks!


Best Regards,
Alison Wang

> -----Original Message-----
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> bounces at lists.infradead.org] On Behalf Of Wang Huan-B18965
> Sent: Friday, July 19, 2013 11:49 AM
> To: plagnioj at jcrosoft.com; tomi.valkeinen at ti.com; shawn.guo at linaro.org;
> Estevam Fabio-R49496; linux-fbdev at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Cc: Jin Zhengxiong-R64188
> Subject: RE: [PATCH v2 0/5] ARM: vf610: Add DCU framebuffer driver for
> Vybrid VF610 platform
> 
> Hi, Jean-Christophe,
> 
>       Could you please help to review these patches?
> 
>       Thanks a lot!
> 
> 
> Best Regards,
> Alison Wang
> 
> > -----Original Message-----
> > From: linux-arm-kernel [mailto:linux-arm-kernel-
> > bounces at lists.infradead.org] On Behalf Of Alison Wang
> > Sent: Friday, July 12, 2013 2:08 PM
> > To: plagnioj at jcrosoft.com; tomi.valkeinen at ti.com;
> > shawn.guo at linaro.org; Estevam Fabio-R49496;
> > linux-fbdev at vger.kernel.org; linux-arm- kernel at lists.infradead.org
> > Cc: Jin Zhengxiong-R64188
> > Subject: [PATCH v2 0/5] ARM: vf610: Add DCU framebuffer driver for
> > Vybrid VF610 platform
> >
> > This series contain DCU framebuffer driver for Freescale Vybrid VF610
> > platform.
> >
> > The Display Controller Unit (DCU) module is a system master that
> > fetches graphics stored in internal or external memory and displays
> > them on a TFT LCD panel. A wide range of panel sizes is supported and
> > the timing of the interface signals is highly configurable.
> > Graphics are read directly from memory and then blended in real-time,
> > which allows for dynamic content creation with minimal CPU
> intervention.
> >
> > The features:
> >
> > (1) Full RGB888 output to TFT LCD panel.
> > (2) For the current LCD panel, WQVGA "480x272" is tested.
> > (3) Blending of each pixel using up to 4 source layers dependent on
> > size of panel.
> > (4) Each graphic layer can be placed with one pixel resolution in
> > either axis.
> > (5) Each graphic layer support RGB565 and RGB888 direct colors
> without
> > alpha channel and BGRA8888 direct colors with an alpha channel.
> > (6) Each graphic layer support alpha blending with 8-bit resolution.
> >
> > Changes in v2:
> > - Add a document for DCU framebuffer driver under
> > Documentation/devicetree/bindings/fb/.
> >
> > ----------------------------------------------------------------
> > Alison Wang (5):
> >       ARM: dts: vf610: Add DCU and TCON nodes
> >       ARM: dts: vf610-twr: Enable DCU and TCON devices
> >       ARM: clk: vf610: Add DCU and TCON clock support
> >       fb: Add DCU framebuffer driver for Vybrid VF610 platform
> >       Documentation: DT: Add DCU framebuffer driver
> >
> >  Documentation/devicetree/bindings/fb/fsl-dcu-fb.txt |   36 ++++
> >  arch/arm/boot/dts/vf610-twr.dts                     |   10 +
> >  arch/arm/boot/dts/vf610.dtsi                        |   19 +-
> >  arch/arm/mach-imx/clk-vf610.c                       |    5 +
> >  drivers/video/Kconfig                               |    9 +
> >  drivers/video/Makefile                              |    1 +
> >  drivers/video/fsl-dcu-fb.c                          | 1091
> >
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > +++++++++++++++++++++++++
> >  include/dt-bindings/clock/vf610-clock.h             |    3 +-
> >  8 files changed, 1172 insertions(+), 2 deletions(-)  create mode
> > 100644 Documentation/devicetree/bindings/fb/fsl-dcu-fb.txt
> >  create mode 100644 drivers/video/fsl-dcu-fb.c
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel




From sachin.kamat at linaro.org  Mon Jul 29 02:37:56 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Mon, 29 Jul 2013 12:07:56 +0530
Subject: [PATCH v8 06/12] ARM: dts: Add description of System MMU of
 Exynos SoCs
In-Reply-To: <003c01ce89f3$3abc4bc0$b034e340$@samsung.com>
References: <003c01ce89f3$3abc4bc0$b034e340$@samsung.com>
Message-ID: <CAK9yfHy2btp1W+5-GiVQnkffDnJ-CgqXuAjGktkiKYyf7kKQbQ@mail.gmail.com>

Hi KyongHo,

On 26 July 2013 16:58, Cho KyongHo <pullip.cho at samsung.com> wrote:
> Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> ---
>  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++++++
>  arch/arm/boot/dts/exynos4.dtsi                     |  122 ++++++++
>  arch/arm/boot/dts/exynos4210.dtsi                  |   25 ++
>  arch/arm/boot/dts/exynos4x12.dtsi                  |   76 +++++
>  arch/arm/boot/dts/exynos5250.dtsi                  |  291 ++++++++++++++++++++
>  5 files changed, 617 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt

This patch does not apply on the mainline Linus' tree (3.11-rc2). Please rebase.

-- 
With warm regards,
Sachin


From vinod.koul at intel.com  Mon Jul 29 02:08:19 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 29 Jul 2013 11:38:19 +0530
Subject: [PATCH] DMAEngine: sirf: let the users be able to pause and
 resume specific buffer
In-Reply-To: <CAGsJ_4wOdDMku-pNWiH-DoS_v39PfFwNYcU4T1Thsd-+L9A8AQ@mail.gmail.com>
References: <1372927373-17407-1-git-send-email-Baohua.Song@csr.com>
 <CAGsJ_4wOdDMku-pNWiH-DoS_v39PfFwNYcU4T1Thsd-+L9A8AQ@mail.gmail.com>
Message-ID: <20130729060819.GE29095@intel.com>

On Mon, Jul 29, 2013 at 10:14:24AM +0800, Barry Song wrote:
> 2013/7/4 Barry Song <Baohua.Song at csr.com>
well the submitter didn't cc me. So this wasnt in my INBOX!

> >
> > From: Qipan Li <Qipan.Li at csr.com>
> >
> > this patch adds a buffer_index in pause and resume entries, then users
> > can pause and resume a buffer they want, but don't pause the whole dma.
> >
> > a typical application scenerios is Ping-Pang in two buffers:
typo, pong	          		^^^^^^^^^
> > at the beginning, we enable buf1 and buf2 to receive dma data, after
> > buf1 is full, we pause buf1 and handle the data in this buffer to avoid
> > overflow in buf1. but at the same time, dma is still tranferring in buf2.
> > once we have finished data process in buf1, we enable buf1 again.
> > this will maximize the chance of dma transferring. users pause buf1 by:
> > dmaengine_device_control(sirfport->rx_dma_chan, DMA_PAUSE, 1);
> > users pause buf2 by:
> > dmaengine_device_control(sirfport->rx_dma_chan, DMA_PAUSE, 2);
> > users can still pause the whole dma transferring by dmaengine_pause().
Well this is odd, the second arg is not supposed to be valid for PAUSE op. And
PAUSE means you pause the whole channel.

The above can be done by 
a) have two buffers:
	- prepare first and submit, and start
	- while first is ongoing, prepare second and start
	- first is completed, so you start processing that while second is
	  getting DMAed
	- when processing is completed, submit first again
	- when second is completed, start processing that and submit that once
	  proocessed

b) have multiple buffers, A, B, C & D and redo above schema.

Since patch is not the right approach and doesnt use API correctly NAK from me on that

~Vinod


From thierry.reding at gmail.com  Mon Jul 29 02:54:31 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 29 Jul 2013 08:54:31 +0200
Subject: [PATCHv5 05/11] of: pci: add registry of MSI chips
In-Reply-To: <20130728162711.32a9a21e@skate>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E41F7A.4010502@gmail.com> <20130728043310.6CF1D3E08FE@localhost>
 <20130728162711.32a9a21e@skate>
Message-ID: <20130729065431.GA1115@manwe>

On Sun, Jul 28, 2013 at 04:27:11PM +0200, Thomas Petazzoni wrote:
> Dear Grant Likely,
> 
> Thanks for your feedback! Some comments below.
> 
> On Sat, 27 Jul 2013 22:33:10 -0600, Grant Likely wrote:
> 
> > > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > > 
> > > Acked-by: Rob Herring <rob.herring at calxeda.com>
> > 
> > Actually, I'm going to disagree on this one and say NAK. I don't think
> > it is a good idea to create a completely separate registry of msi_chips
> > for binding to dt nodes. I think it would be better to include the
> > msi_chip pointer directly into the irq_domain which has to be there
> > anyway. It then becomes another feature for irq controllers if it can
> > support doing MSI.
> 
> The problem that this patch tries to solve is how can the PCIe driver
> work get a pointer to the msi_chip structure from the DT device node
> pointed to by the 'msi-parent' property. I.e, we have:
> 
> 	interrupt-parent = <&mpic>;
> 
> 	mpic {
> 		reg = <...>;
> 		compatible = "...";
> 		interrupt-controller;
> 		msi-controller;
> 	};
> 
> 	pcie-controller {
> 		msi-parent = <&mpic>;
> 	};
> 
> The 'mpic' driver registers two irq_domains, one for the "normal"
> interrupts, and one for the MSI interrupts. Both irq_domain cannot be
> associated to the same &mpic node, or the irq_domain lookup for
> interrupt-parent and msi-parent is going to be confused.
> 
> In the very first version of this patch set, I was using two separate
> DT device nodes to avoid this problem:
> 
> 	interrupt-parent = <&mpic>;
> 
> 	interrupt-controller {
> 		reg = <...>;
> 		compatible = "...";
> 
> 		mpic {
> 			interrupt-controller;
> 		};
> 
> 		msi {
> 			msi-controller;
> 		};
> 	};
> 
> 	pcie-controller {
> 		msi-parent = <&msi>;
> 	};
> 
> This way, each of the two irq_domain was associated to a distinct DT
> device node, and everything was working fine. But during the review, I
> was pointed by Arnd that it wasn't the proper way of describing the
> interrupt controller, and that there should be only one DT device node
> having both the interrupt-controller and msi-controller roles.
> 
> So what is your suggestion to allow the PCIe controller to retrieve the
> correct irq_domain if we have only one DT node for the IRQ controller
> that registers two irq_domains ?

If I understand correctly, Grant isn't objecting to the introduction of
the lookup function, but rather its implementation. You could add a
pointer to a struct msi_chip within struct irq_domain and then iterate
over all irq_domain instances (see irq_find_host()) and find one which
has the correct device_node pointer and the msi_chip pointer set.

So I think that pretty much boils down to setting the (new) .msi_chip
field of armada_370_xp_msi_domain to the newly allocated MSI chip in
armada_370_xp_msi_init() and modify the lookup function to use the
irq_domain_list instead of the list of of_pci_msi_chip_list(). And a
whole lot of the infrastructure code can go away because it's already
there for irq_domain.

The good thing about it is that it couples the MSI chip more strongly
with its associated IRQ domain. And as a bonus we get to omit the list
and of_node fields from struct msi_chip. =)

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/20130729/3994fc92/attachment.sig>

From nsekhar at ti.com  Mon Jul 29 03:01:45 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 29 Jul 2013 12:31:45 +0530
Subject: [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA
 resources
In-Reply-To: <1374515989-7391-1-git-send-email-joelf@ti.com>
References: <1374515989-7391-1-git-send-email-joelf@ti.com>
Message-ID: <51F61359.1090309@ti.com>

On Monday 22 July 2013 11:29 PM, Joel Fernandes wrote:
> HWMOD removal for MMC is breaking edma_start as the events are being manually
> triggered due to unused channel list not being clear, Thanks to Balaji TK for
> finding this issue.

So, Reported-by: Balaji T K <balajitk at ti.com>

?

> 
> This patch fixes the issue, by reading the "dmas" property from the DT node if
> it exists and clearing the bits in the unused channel list.
> 
> Cc: Balaji T K <balajitk at ti.com>
> Cc: Pantel Antoniou <panto at antoniou-consulting.com>
> Signed-off-by: Joel Fernandes <joelf at ti.com>
> ---
> v2 changes: Fixed compiler warning
> 
>  arch/arm/common/edma.c |   31 +++++++++++++++++++++++--------
>  1 file changed, 23 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index a432e6c..765d578 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -561,14 +561,29 @@ static int reserve_contiguous_slots(int ctlr, unsigned int id,
>  static int prepare_unused_channel_list(struct device *dev, void *data)
>  {
>  	struct platform_device *pdev = to_platform_device(dev);
> -	int i, ctlr;
> -
> -	for (i = 0; i < pdev->num_resources; i++) {
> -		if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
> -				(int)pdev->resource[i].start >= 0) {
> -			ctlr = EDMA_CTLR(pdev->resource[i].start);
> -			clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
> -					edma_cc[ctlr]->edma_unused);
> +	int i = 0, ctlr;
> +	u32 dma_chan;
> +	const __be32 *dma_chan_p;
> +	struct property *prop;
> +
> +	if (dev->of_node) {
> +		of_property_for_each_u32(dev->of_node, "dmas", prop, \
> +					 dma_chan_p, dma_chan) {
> +			if (i++ & 1) {
> +				ctlr = EDMA_CTLR(dma_chan);
> +				clear_bit(EDMA_CHAN_SLOT(dma_chan),
> +						edma_cc[ctlr]->edma_unused);
> +			}

I think it will be cleaner if you use of_property_count_strings() on
dma-names to get the count of DMA channels for this device and then use
of_parse_phandle_with_args() to get access to the args. Honestly, I have
not used these APIs myself, so if this doesn?t work the way I think it
should then let me know and I will try to do some experiments myself.

The current way of skipping over even fields really depends on
#dma-cells for EDMA to be 1. That in itself is not such a bad
assumption, but if you have APIs which already take care of this for
you, why not use them?

> +		}
> +	} else {
> +		for (; i < pdev->num_resources; i++) {
> +			if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
> +			    (int)pdev->resource[i].start >= 0) {
> +				ctlr = EDMA_CTLR(pdev->resource[i].start);
> +				clear_bit(EDMA_CHAN_SLOT(
> +					  pdev->resource[i].start),
> +					  edma_cc[ctlr]->edma_unused);
> +			}

So there is very little in common between OF and non-OF versions of this
function. Why not have two different versions of this function for the
two cases? The OF version can reside under the CONFIG_OF conditional
already in use in the file. This will also save you the ugly line breaks
you had to resort to due to too deep indentation.

Thanks,
Sekhar


From nsekhar at ti.com  Mon Jul 29 03:04:43 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 29 Jul 2013 12:34:43 +0530
Subject: [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA
 resources
In-Reply-To: <51F4589E.5070108@ti.com>
References: <1374515989-7391-1-git-send-email-joelf@ti.com>
 <51F4589E.5070108@ti.com>
Message-ID: <51F6140B.3070600@ti.com>

On Sunday 28 July 2013 05:02 AM, Joel Fernandes wrote:
> Hi Tony or Sekhar,
> 
> If this patch looks ok, could you pick it up for -rc cycle?
> 
> It fixes DMA breakages after the merge window for devices for which DMA
> resources are being populated in device tree instead pdev.

But which DT-enabled platform in kernel is using EDMA? A grep for edma
over arch/arm/boot/dts/* brings up nothing.

Does this really have to go into the -rc cycle or can it wait till v3.12?

Thanks,
Sekhar


From iivanov at mm-sol.com  Mon Jul 29 03:04:19 2013
From: iivanov at mm-sol.com (Ivan T. Ivanov)
Date: Mon, 29 Jul 2013 10:04:19 +0300
Subject: [PATCH v2 1/6] usb: phy: msm: Move mach depndend code to platform data
In-Reply-To: <1375081464-14206-1-git-send-email-iivanov@mm-sol.com>
References: <1375081464-14206-1-git-send-email-iivanov@mm-sol.com>
Message-ID: <1375081464-14206-2-git-send-email-iivanov@mm-sol.com>

From: "Ivan T. Ivanov" <iivanov at mm-sol.com>

This patch fix compilation error and is an intermediate step
before the addition of DeviceTree support for newer targets.
Fix suggested here: https://lkml.org/lkml/2013/6/19/381

Cc: David Brown <davidb at codeaurora.org>
Cc: Daniel Walker <dwalker at fifo99.com>
Cc: Bryan Huntsman <bryanh at codeaurora.org>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-usb at vger.kernel.org

Signed-off-by: Ivan T. Ivanov <iivanov at mm-sol.com>
---
 arch/arm/mach-msm/board-msm7x30.c |   35 +++++++++++++++++++++++
 arch/arm/mach-msm/board-qsd8x50.c |   35 +++++++++++++++++++++++
 drivers/usb/phy/phy-msm-usb.c     |   55 ++++++++++---------------------------
 include/linux/usb/msm_hsusb.h     |    3 ++
 4 files changed, 87 insertions(+), 41 deletions(-)

diff --git a/arch/arm/mach-msm/board-msm7x30.c b/arch/arm/mach-msm/board-msm7x30.c
index db3d8c0..6b35953 100644
--- a/arch/arm/mach-msm/board-msm7x30.c
+++ b/arch/arm/mach-msm/board-msm7x30.c
@@ -31,6 +31,7 @@
 #include <asm/setup.h>
 
 #include <mach/board.h>
+#include <mach/clk.h>
 #include <mach/msm_iomap.h>
 #include <mach/dma.h>
 
@@ -61,10 +62,44 @@ static int hsusb_phy_init_seq[] = {
 	-1
 };
 
+static int hsusb_link_clk_reset(struct clk *link_clk, bool assert)
+{
+	int ret;
+
+	if (assert) {
+		ret = clk_reset(link_clk, CLK_RESET_ASSERT);
+		if (ret)
+			pr_err("usb hs_clk assert failed\n");
+	} else {
+		ret = clk_reset(link_clk, CLK_RESET_DEASSERT);
+		if (ret)
+			pr_err("usb hs_clk deassert failed\n");
+	}
+	return ret;
+}
+
+static int hsusb_phy_clk_reset(struct clk *phy_clk)
+{
+	int ret;
+
+	ret = clk_reset(phy_clk, CLK_RESET_ASSERT);
+	if (ret) {
+		pr_err("usb phy clk assert failed\n");
+		return ret;
+	}
+	usleep_range(10000, 12000);
+	ret = clk_reset(phy_clk, CLK_RESET_DEASSERT);
+	if (ret)
+		pr_err("usb phy clk deassert failed\n");
+	return ret;
+}
+
 static struct msm_otg_platform_data msm_otg_pdata = {
 	.phy_init_seq		= hsusb_phy_init_seq,
 	.mode                   = USB_PERIPHERAL,
 	.otg_control		= OTG_PHY_CONTROL,
+	.link_clk_reset		= hsusb_link_clk_reset,
+	.phy_clk_reset		= hsusb_phy_clk_reset,
 };
 
 struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = {
diff --git a/arch/arm/mach-msm/board-qsd8x50.c b/arch/arm/mach-msm/board-qsd8x50.c
index f14a73d..eb013f7 100644
--- a/arch/arm/mach-msm/board-qsd8x50.c
+++ b/arch/arm/mach-msm/board-qsd8x50.c
@@ -32,6 +32,7 @@
 #include <mach/irqs.h>
 #include <mach/sirc.h>
 #include <mach/vreg.h>
+#include <mach/clk.h>
 #include <linux/platform_data/mmc-msm_sdcc.h>
 
 #include "devices.h"
@@ -82,10 +83,44 @@ static int hsusb_phy_init_seq[] = {
 	-1
 };
 
+static int hsusb_link_clk_reset(struct clk *link_clk, bool assert)
+{
+	int ret;
+
+	if (assert) {
+		ret = clk_reset(link_clk, CLK_RESET_ASSERT);
+		if (ret)
+			pr_err("usb hs_clk assert failed\n");
+	} else {
+		ret = clk_reset(link_clk, CLK_RESET_DEASSERT);
+		if (ret)
+			pr_err("usb hs_clk deassert failed\n");
+	}
+	return ret;
+}
+
+static int hsusb_phy_clk_reset(struct clk *phy_clk)
+{
+	int ret;
+
+	ret = clk_reset(phy_clk, CLK_RESET_ASSERT);
+	if (ret) {
+		pr_err("usb phy clk assert failed\n");
+		return ret;
+	}
+	usleep_range(10000, 12000);
+	ret = clk_reset(phy_clk, CLK_RESET_DEASSERT);
+	if (ret)
+		pr_err("usb phy clk deassert failed\n");
+	return ret;
+}
+
 static struct msm_otg_platform_data msm_otg_pdata = {
 	.phy_init_seq		= hsusb_phy_init_seq,
 	.mode                   = USB_PERIPHERAL,
 	.otg_control		= OTG_PHY_CONTROL,
+	.link_clk_reset		= hsusb_link_clk_reset,
+	.phy_clk_reset		= hsusb_phy_clk_reset,
 };
 
 static struct platform_device *devices[] __initdata = {
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index d08f334..7b74b26 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -40,8 +40,6 @@
 #include <linux/usb/msm_hsusb_hw.h>
 #include <linux/regulator/consumer.h>
 
-#include <mach/clk.h>
-
 #define MSM_USB_BASE	(motg->regs)
 #define DRIVER_NAME	"msm_otg"
 
@@ -306,51 +304,20 @@ static void ulpi_init(struct msm_otg *motg)
 	}
 }
 
-static int msm_otg_link_clk_reset(struct msm_otg *motg, bool assert)
-{
-	int ret;
-
-	if (assert) {
-		ret = clk_reset(motg->clk, CLK_RESET_ASSERT);
-		if (ret)
-			dev_err(motg->phy.dev, "usb hs_clk assert failed\n");
-	} else {
-		ret = clk_reset(motg->clk, CLK_RESET_DEASSERT);
-		if (ret)
-			dev_err(motg->phy.dev, "usb hs_clk deassert failed\n");
-	}
-	return ret;
-}
-
-static int msm_otg_phy_clk_reset(struct msm_otg *motg)
-{
-	int ret;
-
-	ret = clk_reset(motg->phy_reset_clk, CLK_RESET_ASSERT);
-	if (ret) {
-		dev_err(motg->phy.dev, "usb phy clk assert failed\n");
-		return ret;
-	}
-	usleep_range(10000, 12000);
-	ret = clk_reset(motg->phy_reset_clk, CLK_RESET_DEASSERT);
-	if (ret)
-		dev_err(motg->phy.dev, "usb phy clk deassert failed\n");
-	return ret;
-}
-
 static int msm_otg_phy_reset(struct msm_otg *motg)
 {
+	struct msm_otg_platform_data *pdata = motg->pdata;
 	u32 val;
 	int ret;
 	int retries;
 
-	ret = msm_otg_link_clk_reset(motg, 1);
+	ret = pdata->link_clk_reset(motg->clk, true);
 	if (ret)
 		return ret;
-	ret = msm_otg_phy_clk_reset(motg);
+	ret = pdata->phy_clk_reset(motg->phy_reset_clk);
 	if (ret)
 		return ret;
-	ret = msm_otg_link_clk_reset(motg, 0);
+	ret = pdata->link_clk_reset(motg->clk, false);
 	if (ret)
 		return ret;
 
@@ -362,7 +329,7 @@ static int msm_otg_phy_reset(struct msm_otg *motg)
 				ULPI_CLR(ULPI_FUNC_CTRL));
 		if (!ret)
 			break;
-		ret = msm_otg_phy_clk_reset(motg);
+		ret = pdata->phy_clk_reset(motg->phy_reset_clk);
 		if (ret)
 			return ret;
 	}
@@ -370,7 +337,7 @@ static int msm_otg_phy_reset(struct msm_otg *motg)
 		return -ETIMEDOUT;
 
 	/* This reset calibrates the phy, if the above write succeeded */
-	ret = msm_otg_phy_clk_reset(motg);
+	ret = pdata->phy_clk_reset(motg->phy_reset_clk);
 	if (ret)
 		return ret;
 
@@ -378,7 +345,7 @@ static int msm_otg_phy_reset(struct msm_otg *motg)
 		ret = ulpi_read(&motg->phy, ULPI_DEBUG);
 		if (ret != -ETIMEDOUT)
 			break;
-		ret = msm_otg_phy_clk_reset(motg);
+		ret = pdata->phy_clk_reset(motg->phy_reset_clk);
 		if (ret)
 			return ret;
 	}
@@ -1414,16 +1381,22 @@ static void msm_otg_debugfs_cleanup(void)
 static int __init msm_otg_probe(struct platform_device *pdev)
 {
 	int ret = 0;
+	struct msm_otg_platform_data *pdata = pdev->dev.platform_data;
 	struct resource *res;
 	struct msm_otg *motg;
 	struct usb_phy *phy;
 
 	dev_info(&pdev->dev, "msm_otg probe\n");
-	if (!pdev->dev.platform_data) {
+	if (!pdata) {
 		dev_err(&pdev->dev, "No platform data given. Bailing out\n");
 		return -ENODEV;
 	}
 
+	if (!pdata->phy_clk_reset || !pdata->link_clk_reset) {
+		dev_err(&pdev->dev, "No phy or link clock reset methods\n");
+		return -ENODEV;
+	}
+
 	motg = kzalloc(sizeof(struct msm_otg), GFP_KERNEL);
 	if (!motg) {
 		dev_err(&pdev->dev, "unable to allocate msm_otg\n");
diff --git a/include/linux/usb/msm_hsusb.h b/include/linux/usb/msm_hsusb.h
index 22a396c..3275483 100644
--- a/include/linux/usb/msm_hsusb.h
+++ b/include/linux/usb/msm_hsusb.h
@@ -20,6 +20,7 @@
 
 #include <linux/types.h>
 #include <linux/usb/otg.h>
+#include <linux/clk.h>
 
 /**
  * Supported USB modes
@@ -135,6 +136,8 @@ struct msm_otg_platform_data {
 	enum msm_usb_phy_type phy_type;
 	void (*setup_gpio)(enum usb_otg_state state);
 	char *pclk_src_name;
+	int (*link_clk_reset)(struct clk *link_clk, bool assert);
+	int (*phy_clk_reset)(struct clk *phy_clk);
 };
 
 /**
-- 
1.7.9.5



From pullip.cho at samsung.com  Mon Jul 29 03:20:28 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Mon, 29 Jul 2013 16:20:28 +0900
Subject: [PATCH v8 06/12] ARM: dts: Add description of System MMU of Exynos
 SoCs
In-Reply-To: <CAK9yfHy2btp1W+5-GiVQnkffDnJ-CgqXuAjGktkiKYyf7kKQbQ@mail.gmail.com>
References: <003c01ce89f3$3abc4bc0$b034e340$@samsung.com>
 <CAK9yfHy2btp1W+5-GiVQnkffDnJ-CgqXuAjGktkiKYyf7kKQbQ@mail.gmail.com>
Message-ID: <003701ce8c2c$19eff910$4dcfeb30$@samsung.com>

> -----Original Message-----
> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
> Sent: Monday, July 29, 2013 3:38 PM
> 
> Hi KyongHo,
> 
> On 26 July 2013 16:58, Cho KyongHo <pullip.cho at samsung.com> wrote:
> > Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> > ---
> >  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++++++
> >  arch/arm/boot/dts/exynos4.dtsi                     |  122 ++++++++
> >  arch/arm/boot/dts/exynos4210.dtsi                  |   25 ++
> >  arch/arm/boot/dts/exynos4x12.dtsi                  |   76 +++++
> >  arch/arm/boot/dts/exynos5250.dtsi                  |  291 ++++++++++++++++++++
> >  5 files changed, 617 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> 
> This patch does not apply on the mainline Linus' tree (3.11-rc2). Please rebase.
> 

OK. I will rebase the next patches on that.

Thank you.

Cho KyongHo. 
> --
> With warm regards,
> Sachin



From 21cnbao at gmail.com  Mon Jul 29 03:20:31 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Mon, 29 Jul 2013 15:20:31 +0800
Subject: [PATCH] DMAEngine: sirf: let the users be able to pause and
 resume specific buffer
In-Reply-To: <20130729060819.GE29095@intel.com>
References: <1372927373-17407-1-git-send-email-Baohua.Song@csr.com>
 <CAGsJ_4wOdDMku-pNWiH-DoS_v39PfFwNYcU4T1Thsd-+L9A8AQ@mail.gmail.com>
 <20130729060819.GE29095@intel.com>
Message-ID: <CAGsJ_4yVxAJc0UNTFMM1yjKQh6=xv12qPYpnUFZ=wmzrdpUOXQ@mail.gmail.com>

2013/7/29 Vinod Koul <vinod.koul at intel.com>:
> On Mon, Jul 29, 2013 at 10:14:24AM +0800, Barry Song wrote:
>> 2013/7/4 Barry Song <Baohua.Song at csr.com>
> well the submitter didn't cc me. So this wasnt in my INBOX!

Vinod, i must did some misoperation. sorry for that.

>
>> >
>> > From: Qipan Li <Qipan.Li at csr.com>
>> >
>> > this patch adds a buffer_index in pause and resume entries, then users
>> > can pause and resume a buffer they want, but don't pause the whole dma.
>> >
>> > a typical application scenerios is Ping-Pang in two buffers:
> typo, pong                              ^^^^^^^^^
>> > at the beginning, we enable buf1 and buf2 to receive dma data, after
>> > buf1 is full, we pause buf1 and handle the data in this buffer to avoid
>> > overflow in buf1. but at the same time, dma is still tranferring in buf2.
>> > once we have finished data process in buf1, we enable buf1 again.
>> > this will maximize the chance of dma transferring. users pause buf1 by:
>> > dmaengine_device_control(sirfport->rx_dma_chan, DMA_PAUSE, 1);
>> > users pause buf2 by:
>> > dmaengine_device_control(sirfport->rx_dma_chan, DMA_PAUSE, 2);
>> > users can still pause the whole dma transferring by dmaengine_pause().
> Well this is odd, the second arg is not supposed to be valid for PAUSE op. And
> PAUSE means you pause the whole channel.
>
> The above can be done by
> a) have two buffers:
>         - prepare first and submit, and start
>         - while first is ongoing, prepare second and start
>         - first is completed, so you start processing that while second is
>           getting DMAed
>         - when processing is completed, submit first again
>         - when second is completed, start processing that and submit that once
>           proocessed
>
> b) have multiple buffers, A, B, C & D and redo above schema.

yes, that is the original idea for multiple buffer management for DMA.

the reason which pushed us to the ping-pong pause is that we don't
need to issue software dma descriptor every time for every buffer as
hardware can do that.
so we went to a pause for buffers which have been issued by hardware
and stop buffer overflow.

>
> Since patch is not the right approach and doesnt use API correctly NAK from me on that

the original idea is actually extending the DMA pause API insteading
of using current PAUSE pf the whole link. i got a little worried about
the patch too, guys have a long history for ping-pong pause even
before using DMAEngine framework.

if your answer is definite no, let's move to your way which makes more senses.

>
> ~Vinod

-barry


From vinod.koul at intel.com  Mon Jul 29 02:44:15 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 29 Jul 2013 12:14:15 +0530
Subject: [PATCH 1/3] dmaengine: add dma_get_slave_sg_limits()
In-Reply-To: <51E83A9D.5020008@ti.com>
References: <1374166001-31340-1-git-send-email-joelf@ti.com>
 <1374166001-31340-2-git-send-email-joelf@ti.com>
 <20130718170825.GZ21614@n2100.arm.linux.org.uk>
 <51E83A9D.5020008@ti.com>
Message-ID: <20130729064415.GF29095@intel.com>

On Thu, Jul 18, 2013 at 01:57:33PM -0500, Joel Fernandes wrote:
> On 07/18/2013 12:08 PM, Russell King - ARM Linux wrote:
> > As for the maximum number of scatterlist entries, really that's a bug in
> > the DMA engine implementations if they can't accept arbitary lengths.
> > I've created DMA engine drivers for implementations where you have to
> > program each segment individually, ones which can have the current and
> > next segments, as well as those which can walk a list.  Provided you get
> > informed of a transfer being completed, there really is no reason for a
> > DMA engine driver to limit the number of scatterlist entries that it
> > will accept.
> 
> Sure, that makes sense. Can you point to such a typical example
> implementation to get some ideas?
MXS MMC driver uses this: drivers/mmc/host/mxs-mmc.c
And dma engine driver for this is mxs-dma.c

~Vinod
-- 


From raghavendra.kt at linux.vnet.ibm.com  Mon Jul 29 03:35:48 2013
From: raghavendra.kt at linux.vnet.ibm.com (Raghavendra K T)
Date: Mon, 29 Jul 2013 13:05:48 +0530
Subject: [PATCH 3/4] arm64: KVM: let other tasks run when hitting WFE
In-Reply-To: <20130728205525.GA14863@cbox>
References: <1374242035-13199-1-git-send-email-marc.zyngier@arm.com>
 <1374242035-13199-4-git-send-email-marc.zyngier@arm.com>
 <CAC4Lta17bmNjBck6LzziBeU0Xc36F1Jms2tQPv6+GaXvik6Wyg@mail.gmail.com>
 <CAMJs5B8Sg1MPHPsRV75mmagnYxkhzA0MKWVkwW2y0WdDVWTSxQ@mail.gmail.com>
 <51ED3A66.4050407@linux.vnet.ibm.com> <20130728205525.GA14863@cbox>
Message-ID: <51F61B54.9030207@linux.vnet.ibm.com>

On 07/29/2013 02:25 AM, Christoffer Dall wrote:
> On Mon, Jul 22, 2013 at 07:27:58PM +0530, Raghavendra K T wrote:
>> On 07/22/2013 06:21 PM, Christoffer Dall wrote:
>>> On 22 July 2013 10:53, Raghavendra KT <raghavendra.kt.linux at gmail.com> wrote:
>>>> On Fri, Jul 19, 2013 at 7:23 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>>> So far, when a guest executes WFE (like when waiting for a spinlock
>>>>> to become unlocked), we don't do a thing and let it run uninterrupted.
>>>>>
>>>>> Another option is to trap a blocking WFE and offer the opportunity
>>>>> to the scheduler to switch to another task, potentially giving the
>>>>> vcpu holding the spinlock a chance to run sooner.
>>>>>
>>>>
>>>> Idea looks to be correct from my experiments on x86. It does bring some
>>>> percentage of benefits in overcommitted guests. Infact,
>>>>
>>>> https://lkml.org/lkml/2013/7/22/41 tries to do the same thing for x86.
>>>> (this results in using ple handler heuristics in vcpu_block pach).
>>>
>>> What about the adverse effect in the non-overcommitted case?
>>>
>>
>> Ideally is should fail to schedule any other task and comeback to halt
>> loop. This should not hurt AFAICS. But I agree that, numbers needed to
>> support this argument.
>
> So if two VCPUs are scheduled on two PCPUs and the waiting VCPU would
> normally wait, say, 1000 cycles to grab the lock, the latency for
> grabbing the lock will now be (at least) a couple of thousand cycles
> even for a tight switch back into the host and back into the guest (on
> currently available hardware).
>

I agree that unnecessary vmexits increase the latency.

>>
>> For x86, I had seen no side effects with the experiments.
>>
>
> I suspect some workloads on x86 would indeed show some side effects, but
> much smaller on ARM, since x86 has a much more hardware-optimized VMEXIT
> cycle time on relatively recent CPUs.
>

I think I should have clearly explained what was tried in x86. sorry
for confusion.

in x86, what I tried was in the halt handler,
instead of doing simple schedule() do intelligent directed yields, using
already available ple handler.
ple handler does have some undercommit detection logic to return back
also the halt() was triggered by guest only after spinning enough in
pv-spinlocks (which was not normal otherwise).
So there was around 2-3% improvement overall in x86.
But yes, I am not expert to comment on arm ecosystem , though I liked 
the idea. and finally only numbers should prove as always.. :).




From tony at atomide.com  Mon Jul 29 03:30:11 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 29 Jul 2013 00:30:11 -0700
Subject: [PATCH] ARM: v6: prevent gcc from reordering extended CP15
 reads above is_smp() test
In-Reply-To: <alpine.DEB.2.02.1307282012280.23852@utopia.booyaka.com>
References: <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com>
 <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com>
 <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307280538460.8385@utopia.booyaka.com>
 <alpine.DEB.2.02.1307282012280.23852@utopia.booyaka.com>
Message-ID: <20130729073010.GU7656@atomide.com>

Hi,

* Paul Walmsley <paul at pwsan.com> [130728 13:23]:
> 
> Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
> don't flush icache in switch_mm with hardware broadcasting") breaks
> the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
> undefined instruction abort from the CP15 read in
> cache_ops_need_broadcast().  It turns out that gcc reorders the
> extended CP15 read above the is_smp() test.  This breaks ARM1136 r0
> cores, since they don't support several CP15 registers that later ARM
> cores do.  ARM1136JF-S TRM section 3.2.1 "Register allocation" has the
> details.
> 
> So, when the kernel is built for ARMv6 cores, mark the extended CP15
> read as clobbering memory, which seems to prevent the compiler from
> reordering it before the is_smp() test.  Russell states that the code
> generated from this approach is preferable to marking the inline asm
> as volatile.
> 
> This patch was developed in collaboration with Will Deacon and Russell
> King.
> 
> Signed-off-by: Paul Walmsley <paul at pwsan.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>

Sorry to be late to this party, I was offline last week. This
patch fixes the issue for me:

Acked-by: Tony Lindgren <tony at atomide.com>


From maxime.ripard at free-electrons.com  Mon Jul 29 03:31:23 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 29 Jul 2013 09:31:23 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130728131901.GA8864@netboy>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1441731.8CGUI1tUxh@flatron> <20130728085650.GA4683@netboy>
 <1416484.XDfk5G56BI@flatron> <20130728131901.GA8864@netboy>
Message-ID: <20130729073123.GB1441@lukather>

Hi,

On Sun, Jul 28, 2013 at 03:19:03PM +0200, Richard Cochran wrote:
> On Sun, Jul 28, 2013 at 11:12:53AM +0200, Tomasz Figa wrote:
> 
> > I'm not really sure what effect on users this has. Maybe you should define 
> > "users".
> 
> ...
> 
> > Care to explain this reasoning?
> 
> Use Case
> ~~~~~~~~
> 
> User acquires a machine running ARM Linux version 3.x, with u-boot
> and dtb in a read only flash partition. The board boots and works just
> fine. However, for his application, the user requires a new kernel
> feature that appeared in version 3.y where y > x. He compiles the new
> kernel, and it also works.

I'm afraid this kind of use case will never be properly supported, DT
stable ABI or not.

Think about this: what kernel will actually be shipped in that board?
Most likely, it will be a BSP kernel from the vendor. Does the vendor
will have made that commitment to have a stable ABI for the DT? Will it
use the same bindings than mainline? Do we want to support all the crazy
bindings every vendor will come up with?

I'm afraid the answer to these three questions will most of the time be
"no.".

That doesn't mean we shouldn't aim for *mainline* having a stable DT
ABI, but that kind of use case doesn't seem very realistic to me.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130729/3a51fbe2/attachment-0001.sig>

From pullip.cho at samsung.com  Mon Jul 29 03:32:25 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Mon, 29 Jul 2013 16:32:25 +0900
Subject: [PATCH v8 08/12] iommu/exynos: remove prefetch buffer setting when
 enabling System MMU
In-Reply-To: <CANEJEGtWTZHZEr=XzPXHFbJtP7U5JFD-o58kRjLe23XaTzv=fA@mail.gmail.com>
References: <003e01ce89f3$4cdb45e0$e691d1a0$@samsung.com>
 <CANEJEGtWTZHZEr=XzPXHFbJtP7U5JFD-o58kRjLe23XaTzv=fA@mail.gmail.com>
Message-ID: <003d01ce8c2d$c5c349d0$5149dd70$@samsung.com>

> -----Original Message-----
> From: grundler at google.com [mailto:grundler at google.com] On Behalf Of Grant Grundler
> Sent: Saturday, July 27, 2013 2:36 AM
> 
> On Fri, Jul 26, 2013 at 4:28 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> > Prefetch buffer must be handled accurately, exact range of a buffer,
> > frame by frame manually. Otherwise, it may causes page fault or
> > deadlock in System MMU.
> > Thus this patch removes prefetch buffer setting when System MMU is
> > initialized(enabled).
> >
> > Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> 
> Reviewed-by: Grant Grundler <grundler at chromium.org>
> 
> BTW, cscope doesn't find any callers of exynos_sysmmu_enable().
> Want to submit another patch to remove it?
> 
> (Note I'm talking about exynos_sysmmu_enable() without "__" prefix).

Oh, I missed removing that function.

Thank you.

> 
> cheers,
> grant
> 
> > ---
> >  drivers/iommu/exynos-iommu.c |   32 +++++++++++++++++++++++++++-----
> >  1 files changed, 27 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> > index cfc02ed..87f6bb7 100644
> > --- a/drivers/iommu/exynos-iommu.c
> > +++ b/drivers/iommu/exynos-iommu.c
> > @@ -80,6 +80,8 @@
> >  #define CTRL_BLOCK     0x7
> >  #define CTRL_DISABLE   0x0
> >
> > +#define CFG_FLPDCACHE  (1 << 20) /* System MMU 3.2+ only */
> > +
> >  #define REG_MMU_CTRL           0x000
> >  #define REG_MMU_CFG            0x004
> >  #define REG_MMU_STATUS         0x008
> > @@ -96,6 +98,9 @@
> >
> >  #define REG_MMU_VERSION                0x034
> >
> > +#define MMU_MAJ_VER(reg)       (reg >> 28)
> > +#define MMU_MIN_VER(reg)       ((reg >> 21) & 0x7F)
> > +
> >  #define REG_PB0_SADDR          0x04C
> >  #define REG_PB0_EADDR          0x050
> >  #define REG_PB1_SADDR          0x054
> > @@ -200,6 +205,22 @@ static bool is_sysmmu_active(struct sysmmu_drvdata *data)
> >         return data->activations > 0;
> >  }
> >
> > +static unsigned int __sysmmu_version(struct sysmmu_drvdata *data,
> > +                                    int idx, unsigned int *minor)
> > +{
> > +       unsigned long major;
> > +
> > +       major = readl(data->sfrbases[idx] + REG_MMU_VERSION);
> > +
> > +       if (minor)
> > +               *minor = MMU_MIN_VER(major);
> > +
> > +       if (MMU_MAJ_VER(major) > 3)
> > +               return 1;
> > +
> > +       return MMU_MAJ_VER(major);
> > +}
> > +
> >  static void sysmmu_unblock(void __iomem *sfrbase)
> >  {
> >         __raw_writel(CTRL_ENABLE, sfrbase + REG_MMU_CTRL);
> > @@ -460,14 +481,15 @@ static int __exynos_sysmmu_enable(struct sysmmu_drvdata *data,
> >         data->pgtable = pgtable;
> >
> >         for (i = 0; i < data->nsfrs; i++) {
> > +               unsigned int min;
> > +
> >                 __sysmmu_set_ptbase(data->sfrbases[i], pgtable);
> >
> > -               if ((readl(data->sfrbases[i] + REG_MMU_VERSION) >> 28) == 3) {
> > -                       /* System MMU version is 3.x */
> > -                       __raw_writel((1 << 12) | (2 << 28),
> > +               if ((__sysmmu_version(data, i, &min) == 3) && (min > 1)) {
> > +                       unsigned long cfg;
> > +                       cfg = __raw_readl(data->sfrbases[i] + REG_MMU_CFG);
> > +                       __raw_writel(cfg | CFG_FLPDCACHE,
> >                                         data->sfrbases[i] + REG_MMU_CFG);
> > -                       __sysmmu_set_prefbuf(data->sfrbases[i], 0, -1, 0);
> > -                       __sysmmu_set_prefbuf(data->sfrbases[i], 0, -1, 1);
> >                 }
> >
> >                 __raw_writel(CTRL_ENABLE, data->sfrbases[i] + REG_MMU_CTRL);
> > --
> > 1.7.2.5
> >
> >



From paul at pwsan.com  Mon Jul 29 03:52:56 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 29 Jul 2013 07:52:56 +0000 (UTC)
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for
 every GPIO on DT"
Message-ID: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>


Hi

your commit 0e970cec05635adbe7b686063e2548a8e4afb8f4 ("gpio/omap: don't 
create an IRQ mapping for every GPIO on DT") breaks the boot on the 
OMAP5912 OSK:

http://www.pwsan.com/omap/testlogs/bisect_5912osk_boot_fail_v3.11-rc3/20130729013931/boot/5912osk/5912osk_log.txt

This test included a stripped-down version of your commit 
949eb1a4d29dc75e0b5b16b03747886b52ecf854 ("gpio/omap: fix build error when 
OF_GPIO is not defined."), since 0e970cec also broke the build.

The previous commit ad81f0545ef01ea651886dddac4bef6cec930092 ("Linux 
3.11-rc1") boots cleanly:

http://www.pwsan.com/omap/testlogs/test_v3.11-rc1/20130721020309/boot/5912osk/5912osk_log.txt

OMAP5912 OSK is an OMAP1 platform, and therefore non-DT.

Could you please put together a fix for this?


regards,

- Paul


From pullip.cho at samsung.com  Mon Jul 29 03:57:22 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Mon, 29 Jul 2013 16:57:22 +0900
Subject: [PATCH v8 06/12] ARM: dts: Add description of System MMU of Exynos
 SoCs
References: <003c01ce89f3$3abc4bc0$b034e340$@samsung.com>
 <CAK9yfHy2btp1W+5-GiVQnkffDnJ-CgqXuAjGktkiKYyf7kKQbQ@mail.gmail.com>
Message-ID: <003e01ce8c31$41d0c450$c5724cf0$@samsung.com>

> -----Original Message-----
> From: Cho KyongHo [mailto:pullip.cho at samsung.com]
> Sent: Monday, July 29, 2013 4:20 PM
> 
> > -----Original Message-----
> > From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
> > Sent: Monday, July 29, 2013 3:38 PM
> >
> > Hi KyongHo,
> >
> > On 26 July 2013 16:58, Cho KyongHo <pullip.cho at samsung.com> wrote:
> > > Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> > > ---
> > >  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++++++
> > >  arch/arm/boot/dts/exynos4.dtsi                     |  122 ++++++++
> > >  arch/arm/boot/dts/exynos4210.dtsi                  |   25 ++
> > >  arch/arm/boot/dts/exynos4x12.dtsi                  |   76 +++++
> > >  arch/arm/boot/dts/exynos5250.dtsi                  |  291 ++++++++++++++++++++
> > >  5 files changed, 617 insertions(+), 0 deletions(-)
> > >  create mode 100644 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
> >
> > This patch does not apply on the mainline Linus' tree (3.11-rc2). Please rebase.
> >
> 
> OK. I will rebase the next patches on that.

I don't get any conflict both on the latest of Linus's tree (3.11-rc3)
and for-next branch  of Samsung git.
Can you show me the diff?

> 
> Thank you.
> 
> Cho KyongHo.
> > --
> > With warm regards,
> > Sachin



From richard.genoud at gmail.com  Mon Jul 29 04:00:01 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon, 29 Jul 2013 10:00:01 +0200
Subject: [PATCH v2 00/42] ARM: at91: move to common clk framework
In-Reply-To: <51F2A556.8020109@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <51F28370.6050304@gmail.com> <51F2996B.6000406@overkiz.com>
 <51F2A556.8020109@overkiz.com>
Message-ID: <CACQ1gAgw-v3z_sWcsk7SqFFW-ERLjS0RS5GTgAdd5Y1tj3Z1FA@mail.gmail.com>

2013/7/26 boris brezillon <b.brezillon at overkiz.com>:
> On 26/07/2013 17:44, boris brezillon wrote:
> I found 2 bugs:
> 1) the main frequency ready test in recalc_rate function is wrong
> 2) the common clk framework uses the first match for dt clk registration
>    and main clk has this compatible property:
>    compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
>    As a result the main clk is always bound to the fixed-clock driver
>    which set the clock frequency to 0 if 'clock-frequency' property is
>    missing.
>
> These bugs will be fixed in next version.
> Tell me if you want need thesse patches for testing purpose.

Hi Boris,

I tested your patch, the clock is not at 0 anymore:
AT91: PIT: mck rate = 8333333

And it's booting correctly.
There's a small bug I found in the at91sam9x5 dtsi file (ssc id is 28,
not 27). (patch attached)

And yes, I could use your patches for some more tests !

Thanks,

Richard.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-at91-dt-at91sam9x5-fix-wrong-SSC-clock-ID.patch
Type: application/octet-stream
Size: 769 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130729/d3e6ee98/attachment.obj>

From tixy at linaro.org  Mon Jul 29 04:01:41 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Mon, 29 Jul 2013 09:01:41 +0100
Subject: [PATCH 1/4] ARM: kprobes: fix instruction fetch order with
 <asm/opcodes.h>
In-Reply-To: <1374786537-10726-2-git-send-email-ben.dooks@codethink.co.uk>
References: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374786537-10726-2-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1375084901.3521.3.camel@linaro1.home>

On Thu, 2013-07-25 at 22:08 +0100, Ben Dooks wrote:
> If we are running BE8, the data and instruction endian-ness do not
> match, so use <asm/opcodes.h> to correctly translate memory accesses
> into ARM instructions.
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>y
> ---
>  arch/arm/kernel/kprobes-common.c |   14 ++++++++------
>  arch/arm/kernel/kprobes.c        |    9 +++++----
>  2 files changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/kernel/kprobes-common.c b/arch/arm/kernel/kprobes-common.c
> index 18a7628..c0b202e 100644
> --- a/arch/arm/kernel/kprobes-common.c
> +++ b/arch/arm/kernel/kprobes-common.c
> @@ -14,6 +14,7 @@
>  #include <linux/kernel.h>
>  #include <linux/kprobes.h>
>  #include <asm/system_info.h>
> +#include <asm/opcodes.h>
>  
>  #include "kprobes.h"
>  
> @@ -305,7 +306,8 @@ kprobe_decode_ldmstm(kprobe_opcode_t insn, struct arch_specific_insn *asi)
>  
>  	if (handler) {
>  		/* We can emulate the instruction in (possibly) modified form */
> -		asi->insn[0] = (insn & 0xfff00000) | (rn << 16) | reglist;
> +		asi->insn[0] = __opcode_to_mem_arm((insn & 0xfff00000) |
> +						   (rn << 16) | reglist);
>  		asi->insn_handler = handler;
>  		return INSN_GOOD;
>  	}
> @@ -338,9 +340,9 @@ prepare_emulated_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi,
>  		thumb_insn[2] = 0x4770; /* Thumb bx lr */

The line above and the one before it not in this diff also need fixing
by changing to __opcode_to_mem_thumb16(0x4770).

>  		return insn;
>  	}
> -	asi->insn[1] = 0xe12fff1e; /* ARM bx lr */
> +	asi->insn[1] = __opcode_to_mem_arm(0xe12fff1e); /* ARM bx lr */
>  #else
> -	asi->insn[1] = 0xe1a0f00e; /* mov pc, lr */
> +	asi->insn[1] = __opcode_to_mem_arm(0xe1a0f00e); /* mov pc, lr */
>  #endif
>  	/* Make an ARM instruction unconditional */
>  	if (insn < 0xe0000000)
> @@ -360,12 +362,12 @@ set_emulated_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi,
>  	if (thumb) {
>  		u16 *ip = (u16 *)asi->insn;
>  		if (is_wide_instruction(insn))
> -			*ip++ = insn >> 16;
> -		*ip++ = insn;
> +			*ip++ = ___asm_opcode_to_mem_thumb16(insn >> 16);
> +		*ip++ = ___asm_opcode_to_mem_thumb16(insn);


Should these two ___asm_opcode_thumb32_compose() not be
__opcode_thumb32_compose() ?

>  		return;
>  	}
>  #endif
> -	asi->insn[0] = insn;
> +	asi->insn[0] = __opcode_to_mem_arm(insn);
>  }
>  
>  /*
> diff --git a/arch/arm/kernel/kprobes.c b/arch/arm/kernel/kprobes.c
> index 170e9f3..3775af1 100644
> --- a/arch/arm/kernel/kprobes.c
> +++ b/arch/arm/kernel/kprobes.c
> @@ -26,6 +26,7 @@
>  #include <linux/stop_machine.h>
>  #include <linux/stringify.h>
>  #include <asm/traps.h>
> +#include <asm/opcodes.h>
>  #include <asm/cacheflush.h>
>  
>  #include "kprobes.h"
> @@ -62,10 +63,10 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
>  #ifdef CONFIG_THUMB2_KERNEL
>  	thumb = true;
>  	addr &= ~1; /* Bit 0 would normally be set to indicate Thumb code */
> -	insn = ((u16 *)addr)[0];
> +	insn = __mem_to_opcode_thumb16(((u16 *)addr)[0]);
>  	if (is_wide_instruction(insn)) {
> -		insn <<= 16;
> -		insn |= ((u16 *)addr)[1];
> +		u16 inst2 = __mem_to_opcode_thumb16(((u16 *)addr)[1]);
> +		insn = ___asm_opcode_thumb32_compose(insn, inst2);

Again, __opcode_thumb32_compose instead of
___asm_opcode_thumb32_compose

>  		decode_insn = thumb32_kprobe_decode_insn;
>  	} else
>  		decode_insn = thumb16_kprobe_decode_insn;
> @@ -73,7 +74,7 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
>  	thumb = false;
>  	if (addr & 0x3)
>  		return -EINVAL;
> -	insn = *p->addr;
> +	insn = __mem_to_opcode_arm(*p->addr);
>  	decode_insn = arm_kprobe_decode_insn;
>  #endif
>  

-- 
Tixy




From sachin.kamat at linaro.org  Mon Jul 29 04:05:28 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Mon, 29 Jul 2013 13:35:28 +0530
Subject: [PATCH v8 06/12] ARM: dts: Add description of System MMU of
 Exynos SoCs
In-Reply-To: <003e01ce8c31$41d0c450$c5724cf0$@samsung.com>
References: <003c01ce89f3$3abc4bc0$b034e340$@samsung.com>
 <CAK9yfHy2btp1W+5-GiVQnkffDnJ-CgqXuAjGktkiKYyf7kKQbQ@mail.gmail.com>
 <003e01ce8c31$41d0c450$c5724cf0$@samsung.com>
Message-ID: <CAK9yfHyeOQZzf_3Nv-fmuYdZtL8dzZequdx2ZddnUyXDn66bOg@mail.gmail.com>

On 29 July 2013 13:27, Cho KyongHo <pullip.cho at samsung.com> wrote:
>> -----Original Message-----
>> From: Cho KyongHo [mailto:pullip.cho at samsung.com]
>> Sent: Monday, July 29, 2013 4:20 PM
>>
>> > -----Original Message-----
>> > From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
>> > Sent: Monday, July 29, 2013 3:38 PM
>> >
>> > Hi KyongHo,
>> >
>> > On 26 July 2013 16:58, Cho KyongHo <pullip.cho at samsung.com> wrote:
>> > > Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
>> > > ---
>> > >  .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 +++++++
>> > >  arch/arm/boot/dts/exynos4.dtsi                     |  122 ++++++++
>> > >  arch/arm/boot/dts/exynos4210.dtsi                  |   25 ++
>> > >  arch/arm/boot/dts/exynos4x12.dtsi                  |   76 +++++
>> > >  arch/arm/boot/dts/exynos5250.dtsi                  |  291 ++++++++++++++++++++
>> > >  5 files changed, 617 insertions(+), 0 deletions(-)
>> > >  create mode 100644 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt
>> >
>> > This patch does not apply on the mainline Linus' tree (3.11-rc2). Please rebase.
>> >
>>
>> OK. I will rebase the next patches on that.
>
> I don't get any conflict both on the latest of Linus's tree (3.11-rc3)
> and for-next branch  of Samsung git.
> Can you show me the diff?
>

I get the following error when I do git am on this patch (linus' tree
3.11-rc3). Other patches apply fine.

Applying: ARM: dts: Add description of System MMU of Exynos SoCs
<local_path>/linux/.git/rebase-apply/patch:120: new blank line at EOF.
+
error: patch failed: arch/arm/boot/dts/exynos4.dtsi:161
error: arch/arm/boot/dts/exynos4.dtsi: patch does not apply
error: patch failed: arch/arm/boot/dts/exynos4210.dtsi:119
error: arch/arm/boot/dts/exynos4210.dtsi: patch does not apply
error: patch failed: arch/arm/boot/dts/exynos4x12.dtsi:79
error: arch/arm/boot/dts/exynos4x12.dtsi: patch does not apply
error: patch failed: arch/arm/boot/dts/exynos5250.dtsi:614
error: arch/arm/boot/dts/exynos5250.dtsi: patch does not apply
Patch failed at 0001 ARM: dts: Add description of System MMU of Exynos SoCs
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".


-- 
With warm regards,
Sachin


From tixy at linaro.org  Mon Jul 29 04:07:17 2013
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Mon, 29 Jul 2013 09:07:17 +0100
Subject: [PATCH 3/4] ARM: kprobes-test: use <asm/opcodes.h>
In-Reply-To: <1374786537-10726-4-git-send-email-ben.dooks@codethink.co.uk>
References: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374786537-10726-4-git-send-email-ben.dooks@codethink.co.uk>
Message-ID: <1375085237.3521.7.camel@linaro1.home>

On Thu, 2013-07-25 at 22:08 +0100, Ben Dooks wrote:
> Ensure we read instructions in the correct endian-ness by using
> the <asm/opcodes.h> helper to transform them as necessary.
> 
> Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk>
> ---
>  arch/arm/kernel/kprobes-test.c |    9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/kernel/kprobes-test.c b/arch/arm/kernel/kprobes-test.c
> index 0cd63d0..6cfa04d 100644
> --- a/arch/arm/kernel/kprobes-test.c
> +++ b/arch/arm/kernel/kprobes-test.c
> @@ -1374,13 +1374,13 @@ static uintptr_t __used kprobes_test_case_start(const char *title, void *stack)
>  
>  	if (test_case_is_thumb) {
>  		u16 *p = (u16 *)(test_code & ~1);
> -		current_instruction = p[0];
> +		current_instruction = __mem_to_opcode_thumb16(p[0]);
>  		if (is_wide_instruction(current_instruction)) {
> -			current_instruction <<= 16;
> -			current_instruction |= p[1];
> +			u16 instr2 = __mem_to_opcode_thumb16(p[1]);
> +			current_instruction = ___asm_opcode_thumb32_compose(current_instruction, instr2);

Should it not be __opcode_thumb32_compose instead of
___asm_opcode_thumb32_compose ?

>  		}
>  	} else {
> -		current_instruction = *(u32 *)test_code;
> +		current_instruction = __mem_to_opcode_arm(*(u32 *)test_code);
>  	}
>  
>  	if (current_title[0] == '.')
> @@ -1593,7 +1593,6 @@ static int run_test_cases(void (*tests)(void), const union decode_item *table)
>  	return 0;
>  }
>  
> -

A random blank line removal, though by guess it shouldn't have been
there in the first place.

>  static int __init run_all_tests(void)
>  {
>  	int ret = 0;

-- 
Tixy




From dirk.behme at de.bosch.com  Mon Jul 29 04:07:45 2013
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Mon, 29 Jul 2013 10:07:45 +0200
Subject: [PATCH] ARM: i.MX6Q clocks: Fix CKIH clock name
In-Reply-To: <1374908212-32008-1-git-send-email-shc_work@mail.ru>
References: <1374908212-32008-1-git-send-email-shc_work@mail.ru>
Message-ID: <51F622D1.5030009@de.bosch.com>

On 27.07.2013 08:56, Alexander Shiyan wrote:
> i.MX6Q have only one High-frequency reference clock (CKIH).
> Patch removes index from CKIH and makes name according datasheet.
>
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>   arch/arm/mach-imx/clk-imx6q.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
> index 9181a24..8f2a8b5 100644
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -292,7 +292,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
>
>   	clk[dummy] = imx_clk_fixed("dummy", 0);
>   	clk[ckil] = imx_obtain_fixed_clock("ckil", 0);
> -	clk[ckih] = imx_obtain_fixed_clock("ckih1", 0);
> +	clk[ckih] = imx_obtain_fixed_clock("ckih", 0);
>   	clk[osc] = imx_obtain_fixed_clock("osc", 0);
>
>   	np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");

Just for my understanding: This is a cosmetic change, only? And doesn't 
change any functionality? Correct?

Thanks,

Dirk



From dwmw2 at infradead.org  Mon Jul 29 04:27:32 2013
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 29 Jul 2013 09:27:32 +0100
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4OzgqH5AiOtismEGop5Y++gvu1ZVZEXhwJB3f-6_eczkqQ@mail.gmail.com>
References: <2469263.vMN09Q7Tzi@flatron>
 <CAKON4OzgqH5AiOtismEGop5Y++gvu1ZVZEXhwJB3f-6_eczkqQ@mail.gmail.com>
Message-ID: <1375086452.2923.106.camel@shinybook.infradead.org>

On Sun, 2013-07-28 at 21:30 -0400, jonsmirl at gmail.com wrote:
> Imagine what might be possible with device trees in a few years...
> 
> A single kernel image can load on any embedded system. The device tree
> sorts out all of the driver loading and tells how everything is wired
> together. There is zero board specific code in the kernel. We're
> getting close to this one.

Weren't we doing this years ago on PowerPC? I'm sure I've heard of
Freescale bringing up a new SoC without touching a line of kernel code.

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130729/f5c1e814/attachment.bin>

From paul at pwsan.com  Mon Jul 29 04:29:44 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 29 Jul 2013 08:29:44 +0000 (UTC)
Subject: OMAP baseline test results for v3.10-rc6
In-Reply-To: <51CB4C20.3060306@ti.com>
References: <alpine.DEB.2.02.1306170521020.9909@utopia.booyaka.com>
 <20130625160243.GE22312@arwen.pp.htv.fi>
 <alpine.DEB.2.02.1306251746060.14373@utopia.booyaka.com>
 <51C9F0A8.1050607@ti.com>
 <alpine.DEB.2.02.1306261713260.6135@utopia.booyaka.com>
 <51CB4C20.3060306@ti.com>
Message-ID: <alpine.DEB.2.02.1307290826180.30864@utopia.booyaka.com>

Hi

On Wed, 26 Jun 2013, Tom Rini wrote:

> On 06/26/2013 01:19 PM, Paul Walmsley wrote:
> > On Tue, 25 Jun 2013, Tom Rini wrote:
> > 
> >> On 06/25/2013 02:20 PM, Paul Walmsley wrote:
> >>
> >>> BeagleBone-white has the additional complication that it is not easy 
> >>> to automate, due to the way that power is delivered to the board, so 
> >>> there is an extra dimension of difficulty there.
> >>
> >> Ah-ha, I reproduced your failure.  If I make up a concat uImage + DTB,
> >> rather than pass them separately, it fails to boot.  If you switch to
> >> mainline U-Boot (v2012.10 or later) you get support for separate image +
> >> dtb (v2013.04 gives you bootz and zImage support).
> > 
> > Yeah, I've tried to keep the original bootloader that came on the first SD 
> > card image that was used on that device.  But am starting to think that 
> > it's time to stop my bootloader independence jihad, since appended DTB 
> > booting is so broken - have seen similar problems on SoCs from other 
> > vendors as well :-(
> 
> Well, me?  I'm all in favor of people using latest release of U-Boot for
> their board and yelling and screaming (or just reporting bugs) when
> things don't work.  I'm biased of course.

That's exactly how bootloader developers should be testing their changes.  
But most of the rest of us kernel folks don't want to deal with constantly 
replacing bootloaders, and then dealing with the inevitable bootloader 
regressions, when what we're really trying to test is the kernel...
The kernel should be completely independent of the bootloader used.  

> And assuming rmk answers the way I expect he will, like it or not, the 
> version(s) we kit up and get in the box need to be factored into our 
> test system setup so if folks don't want to avail themselves of 
> improvements, they still get a functional system too.

Yep seems like a good idea from a customer service point of view.  Also 
most OMAP devices out there probably have locked bootloaders, so replacing 
the bootloader is often not an option.


- Paul


From tomasz.figa at gmail.com  Mon Jul 29 04:33:28 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 29 Jul 2013 10:33:28 +0200
Subject: [PATCH] ARM: EXYNOS: cpuidle: Skip C1 cpuidle state for exynos5440
In-Reply-To: <CADGdYn761S+rDe=GaypFwAYdtQxFZRv0W=jmX9-KomogK5T7ww@mail.gmail.com>
References: <0e7d01ce8840$82f79070$88e6b150$@org> <51F4F317.1040001@linaro.org>
 <CADGdYn761S+rDe=GaypFwAYdtQxFZRv0W=jmX9-KomogK5T7ww@mail.gmail.com>
Message-ID: <13615299.reg39gbbhi@flatron>

On Monday 29 of July 2013 10:16:14 amit daniel kachhap wrote:
> Hi Daniel/Tomasz,
> 
> From the discussion I can conclude that SOC check is needed in the
> cpuidle driver for deeper C states.

A check is needed for the whole cpuidle driver, so it registers only on 
Exynos SoCs which support deeper C states.

> Only the question is where to
> insert this.

Exynos doesn't support multiplatform yet, but we must make sure that any 
code being added is multiplatform-aware. So initcall is not a good idea. I 
would put this somewhere on Exynos-specific initialization path, i.e. 
something that would not called for all platforms compiled in (in case of 
multiplatform).

As I discussed with Daniel, this should be using a traditional 
platform_driver model, with the difference that it can't be registered 
from device tree, but rather statically in mach code.

For example, you can add an exynos_register_cpuidle() function in 
arch/arm/mach-exynos/common.c, which registers such platform device and 
always call it from exynos4_dt_machine_init() in mach-exynos4-dt.c. In 
mach-exynos5-dt.c you could make this conditional and check if 
!soc_is_exynos5440().

Best regards,
Tomasz

> Also to perform the SOC there can be 2 ways like
> 1) each SOC check 4120, 4412, 5250 etc (long list)
> 2) negate the nonsupporting SOC's like 5440 (small list like current
> patch) Any opinion?
>  As Bartlomiej suggested that this patch conflicts with Daniel's
> earlier patch http://marc.info/?l=linux-arm-kernel&m=137467935712513&w=2
> So I can re-base my patch on top of this one if needed.
> 
> Thanks,
> Amit Daniel
> 
> On Sun, Jul 28, 2013 at 4:01 PM, Daniel Lezcano
> 
> <daniel.lezcano at linaro.org> wrote:
> > On 07/28/2013 11:22 AM, Tomasz Figa wrote:
> >> On Sunday 28 of July 2013 09:10:09 Daniel Lezcano wrote:
> >>> On 07/24/2013 01:47 PM, Kukjin Kim wrote:
> >>>> Amit Daniel Kachhap wrote:
> >>>>> This patch skips the deep C1(AFTR -Arm off top running) state for
> >>>>> exynos5440
> >>>>> soc as this soc does not support this state. All the cpu's only
> >>>>> allows the basic
> >>>>> C0 state.
> >>>>> 
> >>>>> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
> >>>>> ---
> >>>>> 
> >>>>>  arch/arm/mach-exynos/cpuidle.c |    2 +-
> >>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
> >>>>> 
> >>>>> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
> >>>>> exynos/cpuidle.c
> >>>>> index 17a18ff..9a776a1 100644
> >>>>> --- a/arch/arm/mach-exynos/cpuidle.c
> >>>>> +++ b/arch/arm/mach-exynos/cpuidle.c
> >>>>> @@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void)
> >>>>> 
> >>>>>            device->cpu = cpu_id;
> >>>>>            
> >>>>>            /* Support IDLE only */
> >>>>> 
> >>>>> -          if (cpu_id != 0)
> >>>>> +          if (soc_is_exynos5440() || cpu_id != 0)
> >>>>> 
> >>>>>                    device->state_count = 1;
> >>>>>            
> >>>>>            ret = cpuidle_register_device(device);
> >>>>> 
> >>>>> --
> >>>>> 1.7.1
> >>>> 
> >>>> Applied, thanks.
> >>> 
> >>> You shouldn't have. This patch means exynos5540 has no cpuidle
> >>> driver at all. It should be fixed in the Kconfig to unselect
> >>> CONFIG_CPU_IDLE for an exynos5540.
> >> 
> >> To shed more light on this, let me add that you need to register a
> >> cpuidle driver only if you have more states than a simple WFI or you
> >> need some crazy steps to enter WFI. Default setup falls back to
> >> generic ARM WFI. (Daniel, do we get the nice idle stats as provided
> >> by cpuidle core then?)> 
> > Nope, but with one state, idle vs busy stats do the trick.
> > 
> > BTW, I am writing a tool to do some stats based on the idle events
> > [1].
> > It is still at a very early development stage but we can get some
> > interesting informations.
> > 
> >> Anyway, Exynos cpuidle is using an initcall to initialize and we
> >> support multiple Exynos SoCs in single zImage, so deselecting
> >> CONFIG_CPU_IDLE is not an option.
> > 
> > Good point.
> > 
> >> Considering multiplatform requirements, the driver has to
> >> 
> >> be modified to initialize only on supported platforms, either by:
> >>  a) dropping the initcall and calling the init function directly from
> >> 
> >> arch/arm/mach-exynos
> >> 
> >>  or
> >>  
> >>  b) checking if machine we are running on is supported, which would
> >>  mean a>> 
> >> long list of all Exynos SoCs that needs to be checked.
> >> 
> >> An evolution of option a) is registering a platform device somewhere
> >> in
> >> arch/arm/mach-exynos and making exynos-cpuidle a platform driver.
> > 
> > Yes, I am favorable to this solution [2].
> > 
> >> The
> >> problem is that you must register a static platform device from arch
> >> code, because cpuidle is not a real hardware block that can be put
> >> into device tree.
> > 
> > Thanks
> > 
> >   -- Daniel
> > 
> > [1]
> > https://git.linaro.org/gitweb?p=people/dlezcano/idlestat.git;a=summar
> > y [2] http://patches.linaro.org/18368/
> > 
> > --
> > 
> >  <http://www.linaro.org/> Linaro.org ? Open source software for ARM
> >  SoCs
> > 
> > Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> > <http://twitter.com/#!/linaroorg> Twitter |
> > <http://www.linaro.org/linaro-blog/> Blog
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-samsung-soc" in the body of a message to
> > majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html


From paul at pwsan.com  Mon Jul 29 04:35:49 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 29 Jul 2013 08:35:49 +0000 (UTC)
Subject: [PATCH 0/2] ARM: AM33XX: clock: Add debugSS data to clk and
 hwmod database
In-Reply-To: <51C10002.5040301@ti.com>
References: <1371532080-27714-1-git-send-email-hvaibhav@ti.com>
 <51C10002.5040301@ti.com>
Message-ID: <alpine.DEB.2.02.1307290833540.30864@utopia.booyaka.com>

Hi guys

On Tue, 18 Jun 2013, Benoit Cousson wrote:

> On 06/18/2013 12:07 AM, Vaibhav Hiremath wrote:
> > This patch adds DebugSS data to clock-tree and hwmod data files.
> > 
> > Changes from RFC/V1 (No code change):
> > 	- Based on comments, we have to follow DT and loadable module
> > 	  approach for debugSS module as well, so separated out 2 patches
> > 	  of clock-tree and hwmod data addition from the RFC patch-series.
> > 	- Added Paul's Ack on clock-tree patch.
> > 	- Rebased on top of Benoit's for-3.11/dts branch.
> > 
> > Link to original RFC -
> > http://archive.arm.linux.org.uk/lurker/message/20130304.113554.53c9ec25.en.html
> > 
> > Vaibhav Hiremath (2):
> >    ARM: AM33XX: clock: Add debugSS clock nodes
> 
> I'll take that one, but the next one:
> 
> >    ARM: AM33XX: hwmod: Add hwmod data for debugSS
> 
> Still need to go through Paul's tree.
> 
> Paul,
> 
> Do you want to ack it, so I'll be able to take the whole series?

If you all are still waiting on something from me here, please let me know 
-- I lost track of this one...


- Paul


From tomasz.figa at gmail.com  Mon Jul 29 04:40:40 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Mon, 29 Jul 2013 10:40:40 +0200
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4OzgqH5AiOtismEGop5Y++gvu1ZVZEXhwJB3f-6_eczkqQ@mail.gmail.com>
References: <2469263.vMN09Q7Tzi@flatron>
 <CAKON4OzgqH5AiOtismEGop5Y++gvu1ZVZEXhwJB3f-6_eczkqQ@mail.gmail.com>
Message-ID: <3412706.4VriYZPgUq@flatron>

On Sunday 28 of July 2013 21:30:22 jonsmirl at gmail.com wrote:
> There is another angle to this problem -- how do we make a single
> schema for all device trees accepted by the kernel? We certainly don't
> want a schema for each vendor where they can do whatever they want.

Aren't we trying to do it the other way around? We define a single schema 
for device trees acceptable by mainline kernels, which should be used by 
vendors, if they want their hardware support to be mainlined.

This is exactly the same situation as with introducing new code (arch, 
drivers, whatever). Vendors are free to do whatever they want, but only 
code that matches kernel standards (i.e. uses existing generic interfaces, 
not proprietary ones) is going to be accepted.

> Obviously all devices in a device class are not identical but many of
> their attributes are. The purpose of a unified schema is stop one
> vendor from naming an attribute VOLTAGE, another VOLTS, another V, etc
> when all of these attributes are doing the same thing - setting a
> voltage. It is possible to use different names right now since they
> are different device drivers. There's no overall architecture glue
> (schema) holding the device class design together.

Well, as of now, there are only some unwritten agreements for generic 
bindings, so if we have a generic bindings for voltage regulators, they 
should be used, not something new get introduced. Only then such code can 
be mainlined.

> The main point of this unified schema is to help people creating new
> device drivers. When ypu construct your device tree representation you
> should first try your best to get it to fit into the existing device
> class schema. Only after you determine that it is impossible to make
> do with the current schema should you ask for the generic schema to be
> extended to include whatever attribute you think you need. At that
> point peer review will happen and hopefully a good solution will
> ensue.

Yes, I believe this is what we want to achieve.

> ----------------
> 
> Imagine what might be possible with device trees in a few years...
> 
> A single kernel image can load on any embedded system. The device tree
> sorts out all of the driver loading and tells how everything is wired
> together. There is zero board specific code in the kernel. We're
> getting close to this one.

Well, we already have platforms with zero board specific code in the 
kernel, e.g. Exynos.

> And in the far future - send your device tree off to a cloud PCB
> printer and get your custom embedded system back in the mail. Sign me
> up for this one!

Haha, that would be something.

Best regards,
Tomasz



From paul at pwsan.com  Mon Jul 29 04:44:18 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 29 Jul 2013 08:44:18 +0000 (UTC)
Subject: [PATCH 2/4] serial: omap: enable PM runtime only when its fully
 configured
In-Reply-To: <1374487277-26099-3-git-send-email-rnayak@ti.com>
References: <1374487277-26099-1-git-send-email-rnayak@ti.com>
 <1374487277-26099-3-git-send-email-rnayak@ti.com>
Message-ID: <alpine.DEB.2.02.1307290843090.30864@utopia.booyaka.com>

Rajendra,

On Mon, 22 Jul 2013, Rajendra Nayak wrote:

> From: Grygorii Strashko <grygorii.strashko at ti.com>
> 
> If earlyprintk is enabled and current UART is console port the platform
> code can mark it as RPM_ACTIVE to sync real IP state with PM Runtime and
> avoid resuming of already active device, but now, driver initialization
> will be performed in the wrong way:

...

> CC: Tony Lindgren <tony at atomide.com>
> CC: Rajendra Nayak <rnayak at ti.com>
> CC: Felipe Balbi <balbi at ti.com>
> CC: Kevin Hilman <khilman at linaro.org>
> 
> Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>

Did you intend to add your Signed-off-by: to this patch?  Since you're 
formally submitting it, it needs to have your Signed-off-by: for me to 
take it.  Let me know and I'll add it if needed -

- Paul


From Ian.Campbell at citrix.com  Mon Jul 29 04:44:30 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Mon, 29 Jul 2013 09:44:30 +0100
Subject: Requirements for FDT load address on ARM
In-Reply-To: <alpine.LFD.2.03.1307241625190.15022@syhkavp.arg>
References: <1374677923.6623.194.camel@hastur.hellion.org.uk>
 <alpine.LFD.2.03.1307241116200.15022@syhkavp.arg>
 <1374690705.30195.18.camel@hastur.hellion.org.uk>
 <alpine.LFD.2.03.1307241625190.15022@syhkavp.arg>
Message-ID: <1375087470.14896.14.camel@kazak.uk.xensource.com>

On Wed, 2013-07-24 at 17:27 -0400, Nicolas Pitre wrote:
> On Wed, 24 Jul 2013, Ian Campbell wrote:
> 
> > On Wed, 2013-07-24 at 11:24 -0400, Nicolas Pitre wrote:
> > > On Wed, 24 Jul 2013, Ian Campbell wrote:
> > > 
> > > > [apologies if this is a repeat, I don't see it in the archives and at
> > > > least one CC'd recipient (Julien) didn't receive it either. Beasties in
> > > > our email server I expect...]
> > > > 
> > > > Are there any requirements about where the FDT may be loaded by the
> > > > bootloader?
> > > 
> > > It must be located where it is unlikely to be overwritten by the zImage 
> > > decompressor relocating itself.  Same goes for the initrd.
> > 
> > Right. That's a bit hard to determine programmaticaly from a bootloader
> > though :-(
> 
> Well... The kernel has to be loaded in the first 128MB of RAM for the 
> automatic RAM location to work.  So you simply have to load the ftd and 
> initrd sequentially above the 128MB mark.  The kernel cannot grow above 
> 16MB in size or we lose the ability to link modules without far calls, 
> or 32MB for the kernel itself after wich the kernel itself doesn't link.  
> This means the decompressor will never relocate anything above the 128MB 
> mark in any case.

Thanks, that's good info, I shall incorporate it in some way into the
patch (which I'll write as soon as I deal with this post-travel email
backlog!)

> In practice this limit can even be lowered to 64MB.

I like 128M, nice and conservative ;-)

Ian.




From tony at atomide.com  Mon Jul 29 04:50:21 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 29 Jul 2013 01:50:21 -0700
Subject: [PATCH 2/4] pinctrl: single: Add hardware specific hooks for
 IRQ and GPIO wake-up events
In-Reply-To: <CACRpkdZNGHRJX3_HRCAfKgrRGLMVbqNzFBfu7wP-3YrhOUESkw@mail.gmail.com>
References: <20130607203936.16513.57494.stgit@localhost>
 <20130607205040.16513.36794.stgit@localhost>
 <CAN1soZznJ1YxWhaFZ4rhQx+uk3aCigAcVeuLpOU+3oPzmfXF6w@mail.gmail.com>
 <20130610153637.GK8164@atomide.com>
 <CACRpkdZNGHRJX3_HRCAfKgrRGLMVbqNzFBfu7wP-3YrhOUESkw@mail.gmail.com>
Message-ID: <20130729085020.GV7656@atomide.com>

* Linus Walleij <linus.walleij at linaro.org> [130722 14:50]:
> On Mon, Jun 10, 2013 at 5:36 PM, Tony Lindgren <tony at atomide.com> wrote:
> 
> > At least on omaps, each board typically has at least one device
> > configured as wake-up capable from deeper idle modes. In the
> > deeper idle modes the normal interrupt wake-up path won't work
> > as the logic is powered off and separate wake-up hardware is
> > available either via IO ring or GPIO hardware.
> 
> What I do not understand is why the irq_set_wake() should
> not fall through to that IO ring / GPIO hardware.

That certainly makes sense.

> For example: a composite GPIO+irqchip driver should surely
> set the wake up for a certain line for irq_set_wake()?

Yes we might be able to make it all transparent to consumer
drivers. Although irq_set_wake() is for suspend/resume only
AFAIK, but ideally we would not have to configure anything
from the consumer drivers for runtime PM.

For the GPIO wake-up events, GPIO + irqchip driver is not
enough as we also need the mapping between pinctrl registers
and GPIO numbers. And to stay out of the database business,
that mapping should ideally come from device tree as it's
only needed for the pins used, not for all hundreds of pins
on a SoC.
 
> > The wake-up
> > event can be device specific, or may need to be dynamically
> > remuxed to GPIO input for wake-up events. When the wake-up
> > event happens, it's IRQ need to be called so the device won't
> > lose interrupts.
> 
> I recognize this hardware type. The name I use for these
> things are "latent interrupts".

OK
 
> What I think is that they should maybe be modeled as
> irqchip from end to end, so that we don't orthogonally use
> any pinctrl states to set this up.

OK I'll take a look.

Regards,

Tony


From rnayak at ti.com  Mon Jul 29 04:50:51 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 29 Jul 2013 14:20:51 +0530
Subject: [PATCH 2/4] serial: omap: enable PM runtime only when its fully
 configured
In-Reply-To: <alpine.DEB.2.02.1307290843090.30864@utopia.booyaka.com>
References: <1374487277-26099-1-git-send-email-rnayak@ti.com>
 <1374487277-26099-3-git-send-email-rnayak@ti.com>
 <alpine.DEB.2.02.1307290843090.30864@utopia.booyaka.com>
Message-ID: <51F62CEB.2090502@ti.com>

On Monday 29 July 2013 02:14 PM, Paul Walmsley wrote:
> Rajendra,
> 
> On Mon, 22 Jul 2013, Rajendra Nayak wrote:
> 
>> From: Grygorii Strashko <grygorii.strashko at ti.com>
>>
>> If earlyprintk is enabled and current UART is console port the platform
>> code can mark it as RPM_ACTIVE to sync real IP state with PM Runtime and
>> avoid resuming of already active device, but now, driver initialization
>> will be performed in the wrong way:
> 
> ...
> 
>> CC: Tony Lindgren <tony at atomide.com>
>> CC: Rajendra Nayak <rnayak at ti.com>
>> CC: Felipe Balbi <balbi at ti.com>
>> CC: Kevin Hilman <khilman at linaro.org>
>>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
> 
> Did you intend to add your Signed-off-by: to this patch?  Since you're 
> formally submitting it, it needs to have your Signed-off-by: for me to 
> take it.  Let me know and I'll add it if needed -

Sorry about that Paul. I indeed missed adding my SoB for this one.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>

> 
> - Paul
> 



From tony at atomide.com  Mon Jul 29 04:57:34 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 29 Jul 2013 01:57:34 -0700
Subject: [PATCH 1/4] pinctrl: single: Prepare for supporting SoC
 specific features
In-Reply-To: <CACRpkdapXZO003xhRCVg5sfQCfJUPMzunui5u6npmht-2hP7Tg@mail.gmail.com>
References: <20130607203936.16513.57494.stgit@localhost>
 <20130607205037.16513.84242.stgit@localhost>
 <CAN1soZzLYpiakcgPR7mBOC7_mLFW=mZwOG98Dq6JpO+JHUW=cw@mail.gmail.com>
 <20130608152732.GR3331@atomide.com>
 <CACRpkdapXZO003xhRCVg5sfQCfJUPMzunui5u6npmht-2hP7Tg@mail.gmail.com>
Message-ID: <20130729085731.GW7656@atomide.com>

* Linus Walleij <linus.walleij at linaro.org> [130722 14:22]:
> On Sat, Jun 8, 2013 at 5:27 PM, Tony Lindgren <tony at atomide.com> wrote:
> 
> > Subject: [PATCH] pinctrl: single: Prepare for supporting SoC specific features
> >
> > Let's replace is_pinconf with flags and add struct pcs_soc so we
> > can support also other features like pin wake-up events. Let's
> > export the probe so the SoC specific modules can pass their
> > SoC specific data to pinctrl-single if needed.
> 
> I don't quite understand this motivation. Can this be more verbose and
> include a bit about the mechanics?
> 
> - Why is this necessary? For example, pinctrl-single already supports
>  generic pinconf, and we can surely add a PIN_CONFIG_WAKEUP
>  to include/linux/pinctrl/pinconf-generic.h.

OK I'll take a look. I like the irqchip idea, let's see what all is
missing after that.
 
> - Also: how does this cooperate with irq_set_wake()? If a pin is
>  set to GPIO it is often backed by a GPIO driver (which is calling
>  pinctrl_request_gpio() etc), maybe we should just add a
>  pinctrl_set_wake() then that the irqchip portions of the GPIO drivers
>  can call down to so the pinctrl driver sets this bit if need be?

Yes currently we're missing the mapping between GPIO registers and
pinctrl registers. But your idea of using irqchip + pinctrl_set_wake()
might sort that issue.

Regards,

Tony


From tony at atomide.com  Mon Jul 29 04:59:31 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 29 Jul 2013 01:59:31 -0700
Subject: [PATCH 0/4] pinctrl single support for SoC specific features
In-Reply-To: <CACRpkdYGHy0jZ0TD8NejiT6TaR3txmXHKgvS=JXBV1-74jZeGw@mail.gmail.com>
References: <20130607203936.16513.57494.stgit@localhost>
 <51DD4F30.7050603@ti.com> <20130710122417.GT5523@atomide.com>
 <CACRpkdYGHy0jZ0TD8NejiT6TaR3txmXHKgvS=JXBV1-74jZeGw@mail.gmail.com>
Message-ID: <20130729085930.GX7656@atomide.com>

* Linus Walleij <linus.walleij at linaro.org> [130722 14:01]:
> On Wed, Jul 10, 2013 at 2:24 PM, Tony Lindgren <tony at atomide.com> wrote:
> 
> > How about I'll push an immutable branch against v3.11-rc1 when it's
> > tagged and send a pull request to Linus W for the first three patches?
> >
> > That way we can base other branches on this if needed.
> >
> > Linus, does that sound OK to you?
> 
> OK but I still need to look closer at them as well, so no guarantee
> I will pull it...

Good comments, let's try to make it all transparent. I'll drop
my branch and will repost the patches when I have things working
using irqchip.

Regards,

Tony


From linus.walleij at linaro.org  Mon Jul 29 05:01:17 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 Jul 2013 11:01:17 +0200
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping
 for every GPIO on DT"
In-Reply-To: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
Message-ID: <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>

Hi Paul,

On Mon, Jul 29, 2013 at 9:52 AM, Paul Walmsley <paul at pwsan.com> wrote:

> your commit 0e970cec05635adbe7b686063e2548a8e4afb8f4 ("gpio/omap: don't
> create an IRQ mapping for every GPIO on DT") breaks the boot on the
> OMAP5912 OSK:

I'm contemplating just reverting this whole series, as I didn't like
the approach from the beginning and it has exploded in exactly
the way I thought it would.

If we revert these three patches:

commit 949eb1a4d29dc75e0b5b16b03747886b52ecf854
"gpio/omap: fix build error when OF_GPIO is not defined."
commit b4419e1a15905191661ffe75ba2f9e649f5d565e
"gpio/omap: auto request GPIO as input if used as IRQ via DT"
commit 0e970cec05635adbe7b686063e2548a8e4afb8f4
"gpio/omap: don't create an IRQ mapping for every GPIO on DT"

Does the OMAP1 boot again after this?

I think it's a way better idea to proceed with input-hogs on the gpiochip
DT node and use that to get auto-request on the GPIO lines that
will be used as IRQs only.

Yours,
Linus Walleij


From tony at atomide.com  Mon Jul 29 05:05:24 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 29 Jul 2013 02:05:24 -0700
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <51E98AEC.5000802@wwwdotorg.org>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
 <51E70953.1000601@wwwdotorg.org>
 <20130718072034.GO7656@atomide.com>
 <51E8401E.8040705@wwwdotorg.org>
 <20130719072927.GY7656@atomide.com>
 <51E98AEC.5000802@wwwdotorg.org>
Message-ID: <20130729090524.GY7656@atomide.com>

* Stephen Warren <swarren at wwwdotorg.org> [130719 11:59]:
> On 07/19/2013 01:29 AM, Tony Lindgren wrote:
> > 
> > I'd vote for keeping the existing behaviour with pinctrl_select_state()
> > when no active state is defined.
> 
> Yes, I think that will work, since the active state cannot exist before
> this new scheme is in place.

Right.
 
> But, this needs to be very clearly spell out in the DT binding
> documentation: If you have states default/idle/sleep, they're complete
> alternatives, whereas if you have states default/active/idle/sleep, the
> latter 3 are alternatives that build on top of the first. I foresee mass
> confusion, but perhaps I'm being pessimistic.

I'm hoping we can automate the runtime PM handling with default/active/idle
completely from the consumer driver point of view. And then when that's
working, we can probably deprecate any runtime PM related handling using
pinctr_select_state() and print warnings. And we can also improve the
documentation so no new users will use the default/idle/sleep for runtime
PM unless they really want to.

Regards,

Tony



From tony at atomide.com  Mon Jul 29 05:08:22 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 29 Jul 2013 02:08:22 -0700
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <51E98D89.9050407@wwwdotorg.org>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
 <51E70B5D.6030802@wwwdotorg.org>
 <20130718073638.GP7656@atomide.com>
 <51E84180.6080902@wwwdotorg.org>
 <20130719073957.GZ7656@atomide.com> <51E91516.2040301@ti.com>
 <51E98D89.9050407@wwwdotorg.org>
Message-ID: <20130729090822.GZ7656@atomide.com>

* Stephen Warren <swarren at wwwdotorg.org> [130719 12:10]:
> On 07/19/2013 04:29 AM, Grygorii Strashko wrote:
> > 
> > First of all, I'd like to mention that these patches do *not* connect
> > pinctrl to PM runtime, so until driver will call pinctrl_select_state()
> > or pinctrl_pm_select_*() there will be no pins state changes.
> 
> Isn't the whole point of the pinctrl_pm_select*() APIs to eventually be
> called automatically by the runtime PM core, so that we don't need to
> write code to do this in every single driver, just like we moved the
> call to pinctrl_select_state(default) into the device core so that we
> didn't have to make every device do that manually?

Yes I think we can make it all automatic. So far it seems that the
last missing piece was Linus' suggestion of making it mostly happen
using irqchip with calls to pinctrl so consumer drivers may not need
to do anything.
 
> > (As result, i2c-mux is not good example, seems:))
> 
> As such, I think all situations are good examples, because a generic
> feature has to work in all cases.

Yes we need to support both runtime PM, and more complex cases of
sharing pins between devices for example that are not runtime PM
related.

Regards,

Tony


From rnayak at ti.com  Mon Jul 29 05:12:40 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Mon, 29 Jul 2013 14:42:40 +0530
Subject: [RFC 0/2] OMAP2+: Convert hwmod to do clock inits and reset when
 drivers initialize
Message-ID: <1375089162-30664-1-git-send-email-rnayak@ti.com>

hwmod framework today does a module enable/reset/idle for all hwmods registered
for a platform quite early at boot.

This has a few downsides like
-1- An early crash failing to enable/reset a device/module needs earlyprintk
for anyone to see the crash logs
-2- Puts a dependency to have all PM frameworks initialized and ready quite
early which inturn prevents some of these to be converted to be independent
drivers

This RFC is an attempt to remove some of these dependencies and do the
hwmod inits (which need other PM frameworks) and resets when the module
is first enabled.

For modules which never get enabled through the boot, there is late call
to do the inits and resets for rest of those modules.

I have been experimenting with some of these on my omap4 panda es and that
boots fine with these patches. If the approach looks fine I will continue
to work some more in this direction and get rid of the early timer need for
hwmod and other PM frameworks.

Rajendra Nayak (2):
  ARM: OMAP2+: hwmod: Split _init() into _init_early() and _init_late()
  ARM: OMAP2+: hwmod: Do the late part of init and setup/reset on first
    enable

 arch/arm/mach-omap2/omap_hwmod.c |   47 +++++++++++++++++++++++++++++++++-----
 1 file changed, 41 insertions(+), 6 deletions(-)

-- 
1.7.9.5



From pullip.cho at samsung.com  Mon Jul 29 05:18:25 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Mon, 29 Jul 2013 18:18:25 +0900
Subject: [PATCH v8 03/12] iommu/exynos: fix page table maintenance
In-Reply-To: <CANEJEGvp1msjkMLN-8TfykYXmrT+sq8dMkNsVEoh9i2vDoh=tg@mail.gmail.com>
References: <003901ce89f3$126c0390$37440ab0$@samsung.com>
 <CANEJEGvp1msjkMLN-8TfykYXmrT+sq8dMkNsVEoh9i2vDoh=tg@mail.gmail.com>
Message-ID: <004e01ce8c3c$9480f9d0$bd82ed70$@samsung.com>

> -----Original Message-----
> From: grundler at google.com [mailto:grundler at google.com] On Behalf Of Grant Grundler
> Sent: Saturday, July 27, 2013 1:17 AM
> To: Cho KyongHo
> 
> On Fri, Jul 26, 2013 at 4:27 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
> > This prevents allocating lv2 page table for the lv1 page table entry
> > that already has 1MB page mapping. In addition some BUG_ON() is
> > changed to WARN_ON().
> >
> > Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> 
> Reviewed-by: Grant Grundler <grundler at chromium.org>
> 
> In reviewing this, I noticed another issue that is related, but not
> caused by this patch. See below.
> 
> > ---
> >  drivers/iommu/exynos-iommu.c |   52 +++++++++++++++++++++++++++++------------
> >  1 files changed, 37 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> > index e3be3e5..6c4ecce 100644
> > --- a/drivers/iommu/exynos-iommu.c
> > +++ b/drivers/iommu/exynos-iommu.c
> > @@ -52,11 +52,11 @@
> >  #define lv2ent_large(pent) ((*(pent) & 3) == 1)
> >
> >  #define section_phys(sent) (*(sent) & SECT_MASK)
> > -#define section_offs(iova) ((iova) & 0xFFFFF)
> > +#define section_offs(iova) ((iova) & ~SECT_MASK)
> >  #define lpage_phys(pent) (*(pent) & LPAGE_MASK)
> > -#define lpage_offs(iova) ((iova) & 0xFFFF)
> > +#define lpage_offs(iova) ((iova) & ~LPAGE_MASK)
> >  #define spage_phys(pent) (*(pent) & SPAGE_MASK)
> > -#define spage_offs(iova) ((iova) & 0xFFF)
> > +#define spage_offs(iova) ((iova) & ~SPAGE_MASK)
> >
> >  #define lv1ent_offset(iova) ((iova) >> SECT_ORDER)
> >  #define lv2ent_offset(iova) (((iova) & 0xFF000) >> SPAGE_ORDER)
> > @@ -862,12 +862,14 @@ static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long iova,
> >                 pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
> >                 BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
> >                 if (!pent)
> > -                       return NULL;
> > +                       return ERR_PTR(-ENOMEM);
> >
> >                 *sent = mk_lv1ent_page(__pa(pent));
> >                 *pgcounter = NUM_LV2ENTRIES;
> >                 pgtable_flush(pent, pent + NUM_LV2ENTRIES);
> >                 pgtable_flush(sent, sent + 1);
> > +       } else if (lv1ent_section(sent)) {
> > +               return ERR_PTR(-EADDRINUSE);
> >         }
> >
> >         return page_entry(sent, iova);
> > @@ -894,6 +896,12 @@ static int lv1set_section(unsigned long *sent, phys_addr_t paddr, short *pgcnt)
> >         return 0;
> >  }
> >
> > +static void clear_page_table(unsigned long *ent, int n)
> > +{
> > +       if (n > 0)
> > +               memset(ent, 0, sizeof(*ent) * n);
> > +}
> > +
> >  static int lv2set_page(unsigned long *pent, phys_addr_t paddr, size_t size,
> >                                                                 short *pgcnt)
> >  {
> > @@ -908,7 +916,7 @@ static int lv2set_page(unsigned long *pent, phys_addr_t paddr, size_t size,
> >                 int i;
> >                 for (i = 0; i < SPAGES_PER_LPAGE; i++, pent++) {
> >                         if (!lv2ent_fault(pent)) {
> > -                               memset(pent, 0, sizeof(*pent) * i);
> > +                               clear_page_table(pent - i, i);
> >                                 return -EADDRINUSE;
> 
> I am wondering about two issues with this error handling:
> 1) we don't call pgtable_flush() in this case - I think just for
> consistency we should - don't rush to add since my next comment is to
> change this error handling completely.
> 
clear_page_table() is called for the page table entries that are already
fault pages. That is why it does not contain cache flush.

> 2) If  -EADDRINUSE is correct, why does the code clear the IO Page
> table entries?
> 
>    I think this error path should either
>    (a) BUG_ON (ie panic) since this is an inconsistency between
> generic IOMMU page allocation and chip specific IOMMU mapping code OR
>    (b) WARN_ON, not clear the entries, and hope whoever was using it
> can finish using the system before crashing or gracefully shutting
> down.
> 
> In any case, I'm pretty sure this code needs to change and it should
> be in a follow up to this series.

Yes, you're right. But I worried the case that a kernel module calls IOMMU API
functions directly and does not want to make kernel panic when it tries to map
a region that is already in use.
I also wonder if the such kernel module exists.
WARN_ON is also a good idea.

Thank you.

> 
> thanks,
> grant
> 
> >                         }
> >
> > @@ -944,17 +952,16 @@ static int exynos_iommu_map(struct iommu_domain *domain, unsigned long iova,
> >                 pent = alloc_lv2entry(entry, iova,
> >                                         &priv->lv2entcnt[lv1ent_offset(iova)]);
> >
> > -               if (!pent)
> > -                       ret = -ENOMEM;
> > +               if (IS_ERR(pent))
> > +                       ret = PTR_ERR(pent);
> >                 else
> >                         ret = lv2set_page(pent, paddr, size,
> >                                         &priv->lv2entcnt[lv1ent_offset(iova)]);
> >         }
> >
> > -       if (ret) {
> > -               pr_debug("%s: Failed to map iova 0x%lx/0x%x bytes\n",
> > -                                                       __func__, iova, size);
> > -       }
> > +       if (ret)
> > +               pr_err("%s: Failed(%d) to map 0x%#x bytes @ %#lx\n",
> > +                       __func__, ret, size, iova);
> >
> >         spin_unlock_irqrestore(&priv->pgtablelock, flags);
> >
> > @@ -968,6 +975,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
> >         struct sysmmu_drvdata *data;
> >         unsigned long flags;
> >         unsigned long *ent;
> > +       size_t err_pgsize;
> >
> >         BUG_ON(priv->pgtable == NULL);
> >
> > @@ -976,7 +984,10 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
> >         ent = section_entry(priv->pgtable, iova);
> >
> >         if (lv1ent_section(ent)) {
> > -               BUG_ON(size < SECT_SIZE);
> > +               if (WARN_ON(size < SECT_SIZE)) {
> > +                       err_pgsize = SECT_SIZE;
> > +                       goto err;
> > +               }
> >
> >                 *ent = 0;
> >                 pgtable_flush(ent, ent + 1);
> > @@ -1008,9 +1019,12 @@ static size_t exynos_iommu_unmap(struct iommu_domain *domain,
> >         }
> >
> >         /* lv1ent_large(ent) == true here */
> > -       BUG_ON(size < LPAGE_SIZE);
> > +       if (WARN_ON(size < LPAGE_SIZE)) {
> > +               err_pgsize = LPAGE_SIZE;
> > +               goto err;
> > +       }
> >
> > -       memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
> > +       clear_page_table(ent, SPAGES_PER_LPAGE);
> >         pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
> >
> >         size = LPAGE_SIZE;
> > @@ -1023,8 +1037,16 @@ done:
> >                 sysmmu_tlb_invalidate_entry(data->dev, iova);
> >         spin_unlock_irqrestore(&priv->lock, flags);
> >
> > -
> >         return size;
> > +err:
> > +       spin_unlock_irqrestore(&priv->pgtablelock, flags);
> > +
> > +       pr_err("%s: Failed due to size(%#x) @ %#lx is"\
> > +               " smaller than page size %#x\n",
> > +               __func__, size, iova, err_pgsize);
> > +
> > +       return 0;
> > +
> >  }
> >
> >  static phys_addr_t exynos_iommu_iova_to_phys(struct iommu_domain *domain,
> > --
> > 1.7.2.5
> >
> >



From paul at pwsan.com  Mon Jul 29 05:19:16 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 29 Jul 2013 09:19:16 +0000 (UTC)
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping
 for every GPIO on DT"
In-Reply-To: <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
References: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
 <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1307290917160.30864@utopia.booyaka.com>

Hi Linus, 

On Mon, 29 Jul 2013, Linus Walleij wrote:

> If we revert these three patches:
> 
> commit 949eb1a4d29dc75e0b5b16b03747886b52ecf854
> "gpio/omap: fix build error when OF_GPIO is not defined."
> commit b4419e1a15905191661ffe75ba2f9e649f5d565e
> "gpio/omap: auto request GPIO as input if used as IRQ via DT"
> commit 0e970cec05635adbe7b686063e2548a8e4afb8f4
> "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
> 
> Does the OMAP1 boot again after this?

Yep, it boots fine with those three patches reverted:

http://www.pwsan.com/omap/testlogs/bisect_5912osk_boot_fail_v3.11-rc3/20130729030748/boot/5912osk/5912osk_log.txt


- Paul


From arend at broadcom.com  Mon Jul 29 05:19:10 2013
From: arend at broadcom.com (Arend van Spriel)
Date: Mon, 29 Jul 2013 11:19:10 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
 <2460092.aLmjrOVh1g@flatron> <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
Message-ID: <51F6338E.8020101@broadcom.com>

On 07/27/2013 10:01 PM, jonsmirl at gmail.com wrote:
> On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
>> On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel <arend at broadcom.com> wrote:
>>> Let's see how many people go and scream if I say this: Too bad .dts files
>>> are not done using XML format as DT bindings could be described using XML
>>> Schema.
>>
>> Draft an example and show us how it would look!  :-)  There is
>> absolutely nothing preventing us from expressing a DT in XML format,
>> or even using XSLT to define DT schema while still using our current
>> .dts syntax. It would be trivial to do lossless translation between
>> .dts syntax and xml.
>>
>> The problem that I have with XML and XSLT is that it is very verbose
>> and not entirely friendly to mere-mortals. However, I'm more than
>> willing to be proved wrong on this point.
>
> I considered this approach a while ago and discarded it. It would work
> but it is just too much of a Frankenstein monster.

Ah, but he is so cute. At least I do not think it is more monstrous as 
the bindings files. I just browsed through a couple of arm binding files 
as I felt challenged to come up with an example. I did not get the 
impression that there is some kind of template in place to get consitent 
bindings descriptions.

> Much cleaner to modify dtc to take a schema as part of the compilation
> process. The schema language itself has no requirement to look like
> DTS syntax. Whoever wrote dtc probably has a favorite language that
> would be good for writing schemas in.

Not sure if I can follow here. I guess you mean the dts compilation, 
right? There are tools freely available to validate XML files against 
XSD specification files. As an example libxml2 has support for it. I 
suspect it is not desired to have a dependency for DTC with an 
out-of-tree library, but it could be incorporated and have DTC spew the 
validation results.

Regards,
Arend




From tony at atomide.com  Mon Jul 29 05:21:16 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 29 Jul 2013 02:21:16 -0700
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <51E98C71.5010709@wwwdotorg.org>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
 <51E70B5D.6030802@wwwdotorg.org>
 <20130718073638.GP7656@atomide.com>
 <51E84180.6080902@wwwdotorg.org>
 <20130719073957.GZ7656@atomide.com>
 <51E98C71.5010709@wwwdotorg.org>
Message-ID: <20130729092116.GA7656@atomide.com>

* Stephen Warren <swarren at wwwdotorg.org> [130719 12:05]:
> On 07/19/2013 01:39 AM, Tony Lindgren wrote:
> > 
> > I think the only sane way to deal with this is to make the I2C controller
> > to show up as two separate I2C controller instances. Then use runtime
> > PM to save and restore the state for each instance, and locking between
> > the two driver instances.
> > 
> > For the pin muxing part, I'd do this:
> > 
> > 			i2c1 instance	i2c2 instance	notes
> > default_state		0 pins		0 pins		(or dedicated pins only)
> > active_state		all pins	alls pins
> > idle_state		safe mode	safe mode
> > 
> > Then when i2c1 instance is done, it's runtime PM suspend muxes the pins
> > to safe mode, or some nop state. Then when i2c2 instance is woken, it's
> > runtime PM resume muxes pins to i2c2.
> 
> I see two issues with that approach:
> 
> 1) Runtime PM doesn't always put a device into an idle state as soon as
> its work is done. Sometimes (always?) there is a delay between when the
> device is last used and when the HW is actually made idle so that if the
> device is re-activated quickly, the kernel hasn't wasted time making it
> idle then active again. You'd have to force that delay to complete when
> switching between the two virtual controller devices.

There is the autosuspend timeout for delayed transitions, but I think
runtime PM already has calls for making the state change immediate also.
 
> 2) This requires two separate device objects for the two I2C instances.
> I guess you could have the driver for the one I2C mux node end up
> instantiating two child devices for this purpose, and hence make that
> happen without needing to change the DT ABI. However, that sure feels
> complex...

Yes but you will also automatically get quite a bit of sanity to your
I2C driver code rather than trying to handle the two separate instances
within the driver alone. Consider things like scanning the I2C buses for
devices and just dev_dbg().
 
> I wonder if it wouldn't be better to have active/idle/sleep as
> "modifiers" to the state name rather than alternatives, so you end up
> with states named:
> 
> default
> nobus:active
> nobus:idle
> nobus:sleep
> bus0:active
> bus0:idle
> bus0:sleep
> bus1:active
> bus1:idle
> bus1:sleep
> 
> Of course, if you continue on with that approach (i.e. you add more
> sub-fields each separated by a colon), you end up with a huge
> combinatorial mess of state names.

Right :) Sooner or later we'll have some totally messed up piece of
hardware pop up that multiplexes one controller across a large number
number buses..

Regards,

Tony


From b.brezillon at overkiz.com  Mon Jul 29 05:25:42 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Mon, 29 Jul 2013 11:25:42 +0200
Subject: [PATCH v2 00/42] ARM: at91: move to common clk framework
In-Reply-To: <CACQ1gAgw-v3z_sWcsk7SqFFW-ERLjS0RS5GTgAdd5Y1tj3Z1FA@mail.gmail.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <51F28370.6050304@gmail.com> <51F2996B.6000406@overkiz.com>
 <51F2A556.8020109@overkiz.com>
 <CACQ1gAgw-v3z_sWcsk7SqFFW-ERLjS0RS5GTgAdd5Y1tj3Z1FA@mail.gmail.com>
Message-ID: <51F63516.8090000@overkiz.com>

On 29/07/2013 10:00, Richard Genoud wrote:
> 2013/7/26 boris brezillon <b.brezillon at overkiz.com>:
>> On 26/07/2013 17:44, boris brezillon wrote:
>> I found 2 bugs:
>> 1) the main frequency ready test in recalc_rate function is wrong
>> 2) the common clk framework uses the first match for dt clk registration
>>     and main clk has this compatible property:
>>     compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
>>     As a result the main clk is always bound to the fixed-clock driver
>>     which set the clock frequency to 0 if 'clock-frequency' property is
>>     missing.
>>
>> These bugs will be fixed in next version.
>> Tell me if you want need thesse patches for testing purpose.
> Hi Boris,
>
> I tested your patch, the clock is not at 0 anymore:
> AT91: PIT: mck rate = 8333333
>
> And it's booting correctly.
> There's a small bug I found in the at91sam9x5 dtsi file (ssc id is 28,
> not 27). (patch attached)
>
> And yes, I could use your patches for some more tests !
>
> Thanks,
>
> Richard.
Hi Richard,

Thanks for the bug report.

You'll find in attachements the pre-v3 series fixing the detected bugs 
(including the ssc clock id bug).

If you need anything else please let me know.

Best Regards,

Boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: at91-clk-v3.tgz
Type: application/x-compressed-tar
Size: 61170 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130729/5d4fdc8f/attachment-0001.bin>

From javier.martinez at collabora.co.uk  Mon Jul 29 05:19:42 2013
From: javier.martinez at collabora.co.uk (Javier Martinez Canillas)
Date: Mon, 29 Jul 2013 11:19:42 +0200
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping
 for every GPIO on DT"
In-Reply-To: <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
References: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
 <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
Message-ID: <51F633AE.8090308@collabora.co.uk>

On 07/29/2013 11:01 AM, Linus Walleij wrote:
> Hi Paul,
> 
> On Mon, Jul 29, 2013 at 9:52 AM, Paul Walmsley <paul at pwsan.com> wrote:
> 
>> your commit 0e970cec05635adbe7b686063e2548a8e4afb8f4 ("gpio/omap: don't
>> create an IRQ mapping for every GPIO on DT") breaks the boot on the
>> OMAP5912 OSK:
> 
> I'm contemplating just reverting this whole series, as I didn't like
> the approach from the beginning and it has exploded in exactly
> the way I thought it would.
> 
> If we revert these three patches:
> 
> commit 949eb1a4d29dc75e0b5b16b03747886b52ecf854
> "gpio/omap: fix build error when OF_GPIO is not defined."
> commit b4419e1a15905191661ffe75ba2f9e649f5d565e
> "gpio/omap: auto request GPIO as input if used as IRQ via DT"
> commit 0e970cec05635adbe7b686063e2548a8e4afb8f4
> "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
> 
> Does the OMAP1 boot again after this?
> 
> I think it's a way better idea to proceed with input-hogs on the gpiochip
> DT node and use that to get auto-request on the GPIO lines that
> will be used as IRQs only.
> 
> Yours,
> Linus Walleij
> 

Hi Paul,

I've looked at this and it seems that irq_create_mapping() does not call the
irq_domain_ops .map function handler since OMAP1 still uses legacy domain
mapping. I don't have an OMAP1 platform to test but could you please see if the
following patch [1] makes your OMAP1 platforms to boot again?

But I agree with Linus and probably we should just go and revert the whole
series since it is very hard to get it right. In another thread a user reported
that this change also broke his DTS tree.

I really tried to get this right without breaking anything but there are just
too many OMAP platforms behaving differently and most OMAP drivers are only half
converted to DT so this is really a can of worms.

Thanks a lot and sorry for the inconvenience,
Javier

[1]:
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c57244e..f1c6da8 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1090,8 +1090,18 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
         * are used as interrupts.
         */
        if (!omap_gpio_chip_boot_dt(&bank->chip))
-               for (j = 0; j < bank->width; j++)
-                       irq_create_mapping(bank->domain, j);
+               for (j = 0; j < bank->width; j++) {
+                       int irq = irq_create_mapping(bank->domain, j);
+                       irq_set_lockdep_class(irq, &gpio_lock_class);
+                       irq_set_chip_data(irq, bank);
+                       if (bank->is_mpuio) {
+                               omap_mpuio_alloc_gc(bank, irq, bank->width);
+                       } else {
+                               irq_set_chip_and_handler(irq, &gpio_irq_chip,
+                                                        handle_simple_irq);
+                               set_irq_flags(irq, IRQF_VALID);
+                       }
+               }
        irq_set_chained_handler(bank->irq, gpio_irq_handler);
        irq_set_handler_data(bank->irq, bank);



From mark.rutland at arm.com  Mon Jul 29 05:30:00 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 29 Jul 2013 10:30:00 +0100
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <51F2F885.2040002@wwwdotorg.org>
References: <20130716151435.GB3871@linaro.org> <2043662.BcW19XTTMG@lenovo>
 <20130719020611.GA4941@glitch> <20130723185733.GB6811@ohporter.com>
 <CAGVrzcYnoN9NnJGvubS7=bVJDk37xSt4BimtvDWghe7OHEWALQ@mail.gmail.com>
 <20130724231106.GB29801@glitch>
 <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
 <20130726000412.GH5022@linaro.org> <51F2F554.8030709@broadcom.com>
 <51F2F885.2040002@wwwdotorg.org>
Message-ID: <20130729093000.GI3528@e106331-lin.cambridge.arm.com>

On Fri, Jul 26, 2013 at 11:30:29PM +0100, Stephen Warren wrote:
> I'm CC'ing in the DT bindings maintainers in case they have any comment.
> 
> On 07/26/2013 04:16 PM, Christian Daudt wrote:
> > On 13-07-25 05:04 PM, Matt Porter wrote:
> >> On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote:
> >>> 2013/7/25 Domenico Andreoli <cavokz at gmail.com>:
> >>>> On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote:
> >>>>> 2013/7/23 Matt Porter <matt.porter at linaro.org>:
> >>>>>> On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
> >>>>>> It's pretty easy to see that the "ti" vendor prefix has no
> >>>>>> relation at
> >>>>>> all to their TXN symbol so that blows that convention out of the
> >>>>>> water.
> >>>>>> Rather, the prefix is based on somebody's notion of how that vendor's
> >>>>>> part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
> >>>>>> never TXN OMAP. :)
> >>>>>>
> >>>>>> For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.
> >>>>> It was appropriate before being the "wrong" vendor prefix was
> >>>>> allocated, now that "brcm" has been allocated we should stick to it
> >>>>> because otherwise we will break existing and on-going DT work.
> >>>> I still prefer bcm to brcm and I find enough evidence that bcm would be
> >>>> better in the long term.
> >>>>
> >>>> So if Broadcomers can agree on bcm, now it's still the cheapest time to
> >>>> fix in that direction, later will not be better.
> >>> If we are to fix it in stone, once and for all, let's go for the full
> >>> name
> >>> which would avoid any kind of future confusion (this also seems to be
> >>> the
> >>> tendency with new vendor prefixes these days). That way we could make
> >>> everyone happy with say: "broadcom,bcm2835". Would that work for
> >>> everyone?
> >> I really like that.
> >>
> >> -Matt
> >>
> > broadcom works for me also.
> >  thanks,
> >    csd
> 
> I have no strong objection at this point in principle to renaming the
> vendor prefix used by the RPi support, although it will cause a bunch of
> pointless churn in the drivers to match the new compatible values,  and
> in the pinctrl bindings for the custom properties there...
> 

I'd be happy to have "broadcom" for all *new* bindings, as it's already
in some bindings alongside "bcm" and "brcm", and is certainly the
clearest of the available options.

However, given the strong feelings of many against breaking existing
dts, we need to support the existing instances of "bcm" and "brcm" in
bindings. This doesn't preclude us also supporting "broadcom,$DEVICE"
alongside the existing "bcm,$DEVICE" and/or "brcm,$DEVICE" for those
that have a strong desire for consistency in future dts, unless there's
a feeling that creates too much churn.

In the end, this is a purely cosmetic change, so we can live with it
as-is at the cost of another entry in an FAQ somewhere.

Thanks,
Mark.


From tony at atomide.com  Mon Jul 29 05:31:25 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 29 Jul 2013 02:31:25 -0700
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <CACRpkdY6-f1DKfPDfCpYAX9weXMtB7koJ3VwkRgHGm_MzgFawQ@mail.gmail.com>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost>
 <CACRpkdY6-f1DKfPDfCpYAX9weXMtB7koJ3VwkRgHGm_MzgFawQ@mail.gmail.com>
Message-ID: <20130729093125.GB7656@atomide.com>

* Linus Walleij <linus.walleij at linaro.org> [130722 16:14]:
> On Tue, Jul 16, 2013 at 11:05 AM, Tony Lindgren <tony at atomide.com> wrote:
> 
> > To toggle dynamic states, let's add the optional active state in
> > addition to the static default state. Then if the optional active
> > state is defined, we can require that idle and sleep states cover
> > the same pingroups as the active state.
> 
> OK...
> 
> > Then let's add pinctrl_check_dynamic() and pinctrl_select_dynamic()
> > to use instead of pinctrl_select() to avoid breaking existing users.
> >
> > With pinctrl_check_dynamic() we can check that idle and sleep states
> > match the active state for pingroups during init, and don't need to
> > do it during runtime.
> 
> I do not understand why this complexity need to be exposed outside
> of the subsystem.

Unfortunately it's mostly to deal with supporting the current behaviour
of pinctrl_select_state() which is not quite suitable for runtime PM.
 
> pinctrl_select_state() and the PM accessors are enough IMO. Why
> should say a driver care about whether it is dynamic or not?

I think we can make this all transparent to the consumer drivers
for runtime PM. Basically drivers/base/pinctrl.c needs these for the
checks because of the current pinctrl_select_state().
 
> Surely the checking and different paths for static/dynamic configurations
> can be an intrinsic detail of the pinctrl subsystem, by adding flags and
> members to private structs like struct pinctrl itself in worst case.

I'll take a look if we can bury more things inside the pinctrl
subsystem.
 
> So I'm not buying into this, it looks like it is making things complicated
> for consumers outside the subsystem for no reason.

I don't think the consumer drivers eventually need to do much
anything ideally. We're missing runtime PM related set_irq_wake()
but that's a minor detail as we can initially keep the runtime
PM related wake-up events always enabled.

Regards,

Tony


From will.deacon at arm.com  Mon Jul 29 05:32:22 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 29 Jul 2013 10:32:22 +0100
Subject: [PATCH v2] ARM: Add check for Cortex-A15 errata 798181 ECO
In-Reply-To: <1375046048-25853-1-git-send-email-robherring2@gmail.com>
References: <1375046048-25853-1-git-send-email-robherring2@gmail.com>
Message-ID: <20130729093221.GA32383@mudshark.cambridge.arm.com>

Hi Rob,

On Sun, Jul 28, 2013 at 10:14:08PM +0100, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> The work-around for A15 errata 798181 is not needed if appropriate ECO
> fixes have been applied to r3p2 and earlier core revisions. This can be
> checked by reading REVIDR register bits 4 and 9. If only bit 4 is set,
> then the IPI broadcast can be skipped.
> 
> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> ---
> v2:
> - Determine the work-around needed and save in a static varible instead
>   of re-reading the ID registers.
> 
>  arch/arm/include/asm/cputype.h |  1 +
>  arch/arm/kernel/smp_tlb.c      | 31 +++++++++++++++++++++++--------
>  2 files changed, 24 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
> index 8c25dc4..e5952b7 100644
> --- a/arch/arm/include/asm/cputype.h
> +++ b/arch/arm/include/asm/cputype.h
> @@ -10,6 +10,7 @@
>  #define CPUID_TLBTYPE	3
>  #define CPUID_MPUIR	4
>  #define CPUID_MPIDR	5
> +#define CPUID_REVIDR	6
>  
>  #ifdef CONFIG_CPU_V7M
>  #define CPUID_EXT_PFR0	0x40
> diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
> index a98b62d..da20db1 100644
> --- a/arch/arm/kernel/smp_tlb.c
> +++ b/arch/arm/kernel/smp_tlb.c
> @@ -73,12 +73,29 @@ static inline void ipi_flush_bp_all(void *ignored)
>  #ifdef CONFIG_ARM_ERRATA_798181
>  static int erratum_a15_798181(void)
>  {
> -	unsigned int midr = read_cpuid_id();
> -
> -	/* Cortex-A15 r0p0..r3p2 affected */
> -	if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2)
> -		return 0;
> -	return 1;
> +	static int errata_fix_needed = -1;
> +
> +	if (unlikely(errata_fix_needed == -1)) {
> +		unsigned int midr = read_cpuid_id();
> +		unsigned int revidr = read_cpuid(CPUID_REVIDR);
> +
> +		/* Cortex-A15 r0p0..r3p2 w/o ECO fix affected */
> +		if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2 ||
> +		    (revidr & 0x210) == 0x210) {
> +			errata_fix_needed = 0;	/* No work-around needed */
> +			return 0;
> +		}
> +		if (revidr & 0x10)
> +			errata_fix_needed = 1;	/* Only TLB flush needed */
> +		else
> +			errata_fix_needed = 2;	/* IPI broadcast needed */
> +	}
> +
> +	if (errata_fix_needed)
> +		dummy_flush_tlb_a15_erratum();
> +
> +	/* Return 1 if IPI broadcast to other cores is needed */
> +	return (errata_fix_needed == 2) ? 1: 0;

Perhaps this would be cleaner if we had a separate function to initialise an
appropriate function pointer for the workaround instead? It might also be
faster for non-affected cores (depending on what the above ends up compiling
to -- I don't know what ARM GCC does with __builtin_expect).

Will


From iivanov at mm-sol.com  Mon Jul 29 05:31:45 2013
From: iivanov at mm-sol.com (Ivan T. Ivanov)
Date: Mon, 29 Jul 2013 12:31:45 +0300
Subject: [PATCH 0/4] msm_serial fixes and improvements
In-Reply-To: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
References: <1374691051-28544-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375090305.1956.49.camel@iivanov-dev.int.mm-sol.com>


Hi, 

On Wed, 2013-07-24 at 11:37 -0700, Stephen Boyd wrote:
> Here are a couple fixes and improvements to the msm_serial
> driver. The first two patches fix a bug on UARTDM devices and
> silence sparse warnings. The last two patches improve the baud
> code detection and increase the throughput on UARTDM devices.
> 
> After this it is rather trivial to add support for newer UARTDM
> devices via new compatible fields.
> 
> Stephen Boyd (4):
>   msm_serial: Fix NUL byte output on UARTDM
>   msm_serial: Fix sparse warnings
>   msm_serial: Make baud_code detection more dynamic
>   msm_serial: Send more than 1 character at a time on UARTDM
> 

Thanks, It is working on 8074 based DragonBoard.

Tested-by: Ivan T. Ivanov <iivanov at mm-sol.com>


>  drivers/tty/serial/msm_serial.c | 180 ++++++++++++++++++++--------------------
>  drivers/tty/serial/msm_serial.h |  19 ++---
>  2 files changed, 97 insertions(+), 102 deletions(-)
> 




From amit.daniel at samsung.com  Mon Jul 29 05:33:17 2013
From: amit.daniel at samsung.com (amit daniel kachhap)
Date: Mon, 29 Jul 2013 15:03:17 +0530
Subject: [PATCH] ARM: EXYNOS: cpuidle: Skip C1 cpuidle state for exynos5440
In-Reply-To: <13615299.reg39gbbhi@flatron>
References: <0e7d01ce8840$82f79070$88e6b150$@org> <51F4F317.1040001@linaro.org>
 <CADGdYn761S+rDe=GaypFwAYdtQxFZRv0W=jmX9-KomogK5T7ww@mail.gmail.com>
 <13615299.reg39gbbhi@flatron>
Message-ID: <CADGdYn6zsr7HTcV2PD++Ze1Otwf5A51D7GwLDmUuqMdRiN+h=Q@mail.gmail.com>

Hi Tomasz,

On Mon, Jul 29, 2013 at 2:03 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> On Monday 29 of July 2013 10:16:14 amit daniel kachhap wrote:
>> Hi Daniel/Tomasz,
>>
>> From the discussion I can conclude that SOC check is needed in the
>> cpuidle driver for deeper C states.
>
> A check is needed for the whole cpuidle driver, so it registers only on
> Exynos SoCs which support deeper C states.

>
>> Only the question is where to
>> insert this.
>
> Exynos doesn't support multiplatform yet, but we must make sure that any
> code being added is multiplatform-aware. So initcall is not a good idea. I
> would put this somewhere on Exynos-specific initialization path, i.e.
> something that would not called for all platforms compiled in (in case of
> multiplatform).
>
> As I discussed with Daniel, this should be using a traditional
> platform_driver model, with the difference that it can't be registered
> from device tree, but rather statically in mach code.
>
> For example, you can add an exynos_register_cpuidle() function in
> arch/arm/mach-exynos/common.c, which registers such platform device and
> always call it from exynos4_dt_machine_init() in mach-exynos4-dt.c. In
> mach-exynos5-dt.c you could make this conditional and check if
> !soc_is_exynos5440().
thanks for the detailed explanation. Certainly initcall is not good
for multikernel. Still I have few concerns.
1) Each C state might be SOC specific. Say there are 3 C states
C0(basic wfi), c1(single CPU power down) and C2 (System wide power
down like AFTR). In this case some exynos soc may support few of these
states and cpuidle driver should bind C-state to correct SOC.
2) Even for default C0 ( simple wfi) currently there is no sysfs
information if the cpuidle driver is not registered(Not quite sure).
I will try to post the new driver by dynamically creating the
cpuidle_state table based on SOC capability and removing the initcall.

Regards,
Amit D
>
> Best regards,
> Tomasz
>
>> Also to perform the SOC there can be 2 ways like
>> 1) each SOC check 4120, 4412, 5250 etc (long list)
>> 2) negate the nonsupporting SOC's like 5440 (small list like current
>> patch) Any opinion?
>>  As Bartlomiej suggested that this patch conflicts with Daniel's
>> earlier patch http://marc.info/?l=linux-arm-kernel&m=137467935712513&w=2
>> So I can re-base my patch on top of this one if needed.
>>
>> Thanks,
>> Amit Daniel
>>
>> On Sun, Jul 28, 2013 at 4:01 PM, Daniel Lezcano
>>
>> <daniel.lezcano at linaro.org> wrote:
>> > On 07/28/2013 11:22 AM, Tomasz Figa wrote:
>> >> On Sunday 28 of July 2013 09:10:09 Daniel Lezcano wrote:
>> >>> On 07/24/2013 01:47 PM, Kukjin Kim wrote:
>> >>>> Amit Daniel Kachhap wrote:
>> >>>>> This patch skips the deep C1(AFTR -Arm off top running) state for
>> >>>>> exynos5440
>> >>>>> soc as this soc does not support this state. All the cpu's only
>> >>>>> allows the basic
>> >>>>> C0 state.
>> >>>>>
>> >>>>> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
>> >>>>> ---
>> >>>>>
>> >>>>>  arch/arm/mach-exynos/cpuidle.c |    2 +-
>> >>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>> >>>>>
>> >>>>> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
>> >>>>> exynos/cpuidle.c
>> >>>>> index 17a18ff..9a776a1 100644
>> >>>>> --- a/arch/arm/mach-exynos/cpuidle.c
>> >>>>> +++ b/arch/arm/mach-exynos/cpuidle.c
>> >>>>> @@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void)
>> >>>>>
>> >>>>>            device->cpu = cpu_id;
>> >>>>>
>> >>>>>            /* Support IDLE only */
>> >>>>>
>> >>>>> -          if (cpu_id != 0)
>> >>>>> +          if (soc_is_exynos5440() || cpu_id != 0)
>> >>>>>
>> >>>>>                    device->state_count = 1;
>> >>>>>
>> >>>>>            ret = cpuidle_register_device(device);
>> >>>>>
>> >>>>> --
>> >>>>> 1.7.1
>> >>>>
>> >>>> Applied, thanks.
>> >>>
>> >>> You shouldn't have. This patch means exynos5540 has no cpuidle
>> >>> driver at all. It should be fixed in the Kconfig to unselect
>> >>> CONFIG_CPU_IDLE for an exynos5540.
>> >>
>> >> To shed more light on this, let me add that you need to register a
>> >> cpuidle driver only if you have more states than a simple WFI or you
>> >> need some crazy steps to enter WFI. Default setup falls back to
>> >> generic ARM WFI. (Daniel, do we get the nice idle stats as provided
>> >> by cpuidle core then?)>
>> > Nope, but with one state, idle vs busy stats do the trick.
>> >
>> > BTW, I am writing a tool to do some stats based on the idle events
>> > [1].
>> > It is still at a very early development stage but we can get some
>> > interesting informations.
>> >
>> >> Anyway, Exynos cpuidle is using an initcall to initialize and we
>> >> support multiple Exynos SoCs in single zImage, so deselecting
>> >> CONFIG_CPU_IDLE is not an option.
>> >
>> > Good point.
>> >
>> >> Considering multiplatform requirements, the driver has to
>> >>
>> >> be modified to initialize only on supported platforms, either by:
>> >>  a) dropping the initcall and calling the init function directly from
>> >>
>> >> arch/arm/mach-exynos
>> >>
>> >>  or
>> >>
>> >>  b) checking if machine we are running on is supported, which would
>> >>  mean a>>
>> >> long list of all Exynos SoCs that needs to be checked.
>> >>
>> >> An evolution of option a) is registering a platform device somewhere
>> >> in
>> >> arch/arm/mach-exynos and making exynos-cpuidle a platform driver.
>> >
>> > Yes, I am favorable to this solution [2].
>> >
>> >> The
>> >> problem is that you must register a static platform device from arch
>> >> code, because cpuidle is not a real hardware block that can be put
>> >> into device tree.
>> >
>> > Thanks
>> >
>> >   -- Daniel
>> >
>> > [1]
>> > https://git.linaro.org/gitweb?p=people/dlezcano/idlestat.git;a=summar
>> > y [2] http://patches.linaro.org/18368/
>> >
>> > --
>> >
>> >  <http://www.linaro.org/> Linaro.org ? Open source software for ARM
>> >  SoCs
>> >
>> > Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>> > <http://twitter.com/#!/linaroorg> Twitter |
>> > <http://www.linaro.org/linaro-blog/> Blog
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe
>> > linux-samsung-soc" in the body of a message to
>> > majordomo at vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From vincent.guittot at linaro.org  Mon Jul 29 05:38:28 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Mon, 29 Jul 2013 11:38:28 +0200
Subject: [RFC][PATCH 2/2] ARM64: introduce cluster id and make a
 difference between socket id
In-Reply-To: <1374921728-9007-2-git-send-email-hanjun.guo@linaro.org>
References: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>
 <1374921728-9007-2-git-send-email-hanjun.guo@linaro.org>
Message-ID: <CAKfTPtBXi4C3ncLmsWZQEs3x80VbPhHo+gC9hG_EFwMdafJmOQ@mail.gmail.com>

On 27 July 2013 12:42, Hanjun Guo <hanjun.guo at linaro.org> wrote:
> In the cpu topology information, we define topology_physical_package_id()
> as cpu socket id, which means that the socket id is the idenfication for
> physical processor, not for a cluster in a cpu die.
>
> On ARM64 platform, multi cluster in a cpu die will be normal, here is a
> example with 2 cores in a cluster and 2 cluster in a socket:
>
> |--------------------------------------|
> |                socket                |
> |                                      |
> | |---------------|  |---------------| |
> | |    cluster    |  |    cluster    | |
> | |               |  |               | |
> | | |----| |----| |  | |----| |----| | |
> | | |core| |core| |  | |core| |core| | |
> | | |----| |----| |  | |----| |----| | |
> | |               |  |               | |
> | |---------------|  |---------------| |
> |                                      |
> |--------------------------------------|
>
> ARM64 extended the MPIDR into 64 bit and introduce another affinity level,
> we can use this affinity level for socket id and use the third highest level
> affinity for cluster id, which  make the socket id behavior in its original
> way.
>
> Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
> ---
>  arch/arm64/include/asm/topology.h |    1 +
>  arch/arm64/kernel/topology.c      |    8 ++++++--
>  2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> index 8631808..ff68ecc 100644
> --- a/arch/arm64/include/asm/topology.h
> +++ b/arch/arm64/include/asm/topology.h
> @@ -8,6 +8,7 @@
>  struct cputopo_arm64 {
>         int thread_id;
>         int core_id;
> +       int cluster_id;
>         int socket_id;
>         cpumask_t thread_sibling;
>         cpumask_t core_sibling;
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index 1eb0435..6d1e5a6 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
> @@ -80,12 +80,14 @@ void store_cpu_topology(unsigned int cpuid)
>                         /* core performance interdependency */
>                         cpuid_topo->thread_id = MPIDR_AFFINITY_LEVEL_0(mpidr);
>                         cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL_1(mpidr);
> -                       cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_2(mpidr);
> +                       cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL_2(mpidr);
> +                       cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_3(mpidr);

socket_id is currently used by update_siblings_masks to update the
core_sibling mask. This mask defines which CPUs share their cache and
AFAICT, the cache are shared at the cluster level so cluster_id should
be used instead socket_id.

Have you got more information about the goal of this new level_3 ?

Vincent

>                 } else {
>                         /* largely independent cores */
>                         cpuid_topo->thread_id = -1;
>                         cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL_0(mpidr);
> -                       cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_1(mpidr);
> +                       cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL_1(mpidr);
> +                       cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_2(mpidr);
>                 }
>         } else {
>                 /*
> @@ -95,6 +97,7 @@ void store_cpu_topology(unsigned int cpuid)
>                  */
>                 cpuid_topo->thread_id = -1;
>                 cpuid_topo->core_id = 0;
> +               cpuid_topo->cluster_id = -1;
>                 cpuid_topo->socket_id = -1;
>         }
>
> @@ -120,6 +123,7 @@ void __init init_cpu_topology(void)
>
>                 topo->thread_id = -1;
>                 topo->core_id =  -1;
> +               topo->cluster_id = -1;
>                 topo->socket_id = -1;
>                 cpumask_clear(&topo->core_sibling);
>                 cpumask_clear(&topo->thread_sibling);
> --
> 1.7.9.5
>


From javier.martinez at collabora.co.uk  Mon Jul 29 05:39:48 2013
From: javier.martinez at collabora.co.uk (Javier Martinez Canillas)
Date: Mon, 29 Jul 2013 11:39:48 +0200
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping
 for every GPIO on DT"
In-Reply-To: <51F633AE.8090308@collabora.co.uk>
References: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
 <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
 <51F633AE.8090308@collabora.co.uk>
Message-ID: <51F63864.9000601@collabora.co.uk>

On 07/29/2013 11:19 AM, Javier Martinez Canillas wrote:
> On 07/29/2013 11:01 AM, Linus Walleij wrote:
>> Hi Paul,
>> 
>> On Mon, Jul 29, 2013 at 9:52 AM, Paul Walmsley <paul at pwsan.com> wrote:
>> 
>>> your commit 0e970cec05635adbe7b686063e2548a8e4afb8f4 ("gpio/omap: don't
>>> create an IRQ mapping for every GPIO on DT") breaks the boot on the
>>> OMAP5912 OSK:
>> 
>> I'm contemplating just reverting this whole series, as I didn't like
>> the approach from the beginning and it has exploded in exactly
>> the way I thought it would.
>> 
>> If we revert these three patches:
>> 
>> commit 949eb1a4d29dc75e0b5b16b03747886b52ecf854
>> "gpio/omap: fix build error when OF_GPIO is not defined."
>> commit b4419e1a15905191661ffe75ba2f9e649f5d565e
>> "gpio/omap: auto request GPIO as input if used as IRQ via DT"
>> commit 0e970cec05635adbe7b686063e2548a8e4afb8f4
>> "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
>> 
>> Does the OMAP1 boot again after this?
>> 
>> I think it's a way better idea to proceed with input-hogs on the gpiochip
>> DT node and use that to get auto-request on the GPIO lines that
>> will be used as IRQs only.
>> 
>> Yours,
>> Linus Walleij
>> 
> 
> Hi Paul,
> 
> I've looked at this and it seems that irq_create_mapping() does not call the
> irq_domain_ops .map function handler since OMAP1 still uses legacy domain
> mapping. I don't have an OMAP1 platform to test but could you please see if the
> following patch [1] makes your OMAP1 platforms to boot again?
> 
> But I agree with Linus and probably we should just go and revert the whole
> series since it is very hard to get it right. In another thread a user reported
> that this change also broke his DTS tree.
> 
> I really tried to get this right without breaking anything but there are just
> too many OMAP platforms behaving differently and most OMAP drivers are only half
> converted to DT so this is really a can of worms.
> 
> Thanks a lot and sorry for the inconvenience,
> Javier
> 
> [1]:
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index c57244e..f1c6da8 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1090,8 +1090,18 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
>          * are used as interrupts.
>          */
>         if (!omap_gpio_chip_boot_dt(&bank->chip))
> -               for (j = 0; j < bank->width; j++)
> -                       irq_create_mapping(bank->domain, j);
> +               for (j = 0; j < bank->width; j++) {
> +                       int irq = irq_create_mapping(bank->domain, j);
> +                       irq_set_lockdep_class(irq, &gpio_lock_class);
> +                       irq_set_chip_data(irq, bank);
> +                       if (bank->is_mpuio) {
> +                               omap_mpuio_alloc_gc(bank, irq, bank->width);
> +                       } else {
> +                               irq_set_chip_and_handler(irq, &gpio_irq_chip,
> +                                                        handle_simple_irq);
> +                               set_irq_flags(irq, IRQF_VALID);
> +                       }
> +               }
>         irq_set_chained_handler(bank->irq, gpio_irq_handler);
>         irq_set_handler_data(bank->irq, bank);
> 

In case this solves Paul issue, a cleaned patch with a commit message is [2].
But we should decide if is better to fix this or just drop the patches and go
with Linus' input-hogs idea to do the GPIO auto request.

Santosh, Kevin, Grant, what do you think we should do?

Thanks a lot and best regards,
Javier

commit 486402aee8f31f067dacc6a83c4a3509fc9d3bfa
Author: Javier Martinez Canillas <javier.martinez at collabora.co.uk>
Date:   Mon Jul 29 11:03:43 2013 +0200

    gpio/omap: setup IRQ in chip init instead .map for OMAP1

    OMAP1 still uses the legacy domain mapping and was not converted
    to use the linear mapping like OMAP2+ platforms.

    So, irq_create_mapping() does not call the omap irq_domain_ops
    .map function handler and the GPIO-IRQ are not correctly initialized.

    Do the IRQ setup in omap_gpio_chip_init() for OMAP1 platforms to
    avoid this issue.

    Signed-off-by: Javier Martinez Canillas <javier.martinez at collabora.co.uk>

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c57244e..c6f7c56 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1053,6 +1053,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
 {
 	int j;
 	static int gpio;
+	int irq = 0;

 	/*
 	 * REVISIT eventually switch from OMAP-specific gpio structs
@@ -1090,8 +1091,20 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
 	 * are used as interrupts.
 	 */
 	if (!omap_gpio_chip_boot_dt(&bank->chip))
-		for (j = 0; j < bank->width; j++)
-			irq_create_mapping(bank->domain, j);
+		for (j = 0; j < bank->width; j++) {
+			irq = irq_create_mapping(bank->domain, j);
+#ifdef CONFIG_ARCH_OMAP1
+			irq_set_lockdep_class(irq, &gpio_lock_class);
+			irq_set_chip_data(irq, bank);
+			if (bank->is_mpuio) {
+				omap_mpuio_alloc_gc(bank, irq, bank->width);
+			} else {
+				irq_set_chip_and_handler(irq, &gpio_irq_chip,
+							 handle_simple_irq);
+				set_irq_flags(irq, IRQF_VALID);
+			}
+#endif
+		}
 	irq_set_chained_handler(bank->irq, gpio_irq_handler);
 	irq_set_handler_data(bank->irq, bank);
 }


From jonas.jensen at gmail.com  Mon Jul 29 05:44:22 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Mon, 29 Jul 2013 11:44:22 +0200
Subject: [PATCH v6] clk: add MOXA ART SoCs clock driver
In-Reply-To: <1374221837-23773-1-git-send-email-jonas.jensen@gmail.com>
References: <1374221837-23773-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1375091062-3773-1-git-send-email-jonas.jensen@gmail.com>

This patch adds MOXA ART SoCs clock driver support.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v5:
    
    1. corrected of_iomap return value check
    2. don't panic, print the error and return
    
    Applies to next-20130729

 .../bindings/clock/moxa,moxart-core-clock.txt      | 23 +++++++
 drivers/clk/Makefile                               |  1 +
 drivers/clk/clk-moxart.c                           | 71 ++++++++++++++++++++++
 3 files changed, 95 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
 create mode 100644 drivers/clk/clk-moxart.c

diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
new file mode 100644
index 0000000..379ae79
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/moxa,moxart-core-clock.txt
@@ -0,0 +1,23 @@
+Device Tree Clock bindings for arch-moxart
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+MOXA ART SoCs allow to determine core clock frequencies by reading
+a register.
+
+Required properties:
+- compatible : Must be "moxa,moxart-core-clock"
+- #clock-cells : Should be 0
+- reg : Should contain registers location and length
+- clock-output-names : Should be "coreclk"
+
+For example:
+
+	coreclk: core-clock at 98100000 {
+		compatible = "moxa,moxart-core-clock";
+		#clock-cells = <0>;
+		reg = <0x98100000 0x34>;
+		clock-output-names = "coreclk";
+	};
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4038c2b..933622f 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_COMMON_CLK)	+= clk-composite.o
 
 # SoCs specific
 obj-$(CONFIG_ARCH_BCM2835)	+= clk-bcm2835.o
+obj-$(CONFIG_ARCH_MOXART)	+= clk-moxart.o
 obj-$(CONFIG_ARCH_NOMADIK)	+= clk-nomadik.o
 obj-$(CONFIG_ARCH_HIGHBANK)	+= clk-highbank.o
 obj-$(CONFIG_ARCH_NSPIRE)	+= clk-nspire.o
diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
new file mode 100644
index 0000000..14d5b26
--- /dev/null
+++ b/drivers/clk/clk-moxart.c
@@ -0,0 +1,71 @@
+/*
+ * MOXA ART SoCs clock driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/clkdev.h>
+
+void __init moxart_of_clk_init(struct device_node *node)
+{
+	static void __iomem *base;
+	struct clk *clk;
+	unsigned long rate;
+	unsigned int mul, val, div;
+	const char *name;
+
+	base = of_iomap(node, 0);
+	if (!base) {
+		pr_err("%s: of_iomap failed\n", node->full_name);
+		return;
+	}
+
+	mul = (readl(base + 0x30) >> 3) & 0x1ff;
+	val = (readl(base + 0x0c) >> 4) & 0x7;
+
+	switch (val) {
+	case 1:
+		div = 3;
+		break;
+	case 2:
+		div = 4;
+		break;
+	case 3:
+		div = 6;
+		break;
+	case 4:
+		div = 8;
+		break;
+	default:
+		div = 2;
+		break;
+	}
+
+	/*
+	 * the rate calculation below is only tested and proven
+	 * to be true for UC-7112-LX
+	 *
+	 * UC-7112-LX: mul=80 val=0
+	 *
+	 * to support other moxart SoC hardware, this may need
+	 * a change, though it's possible it works there too
+	 */
+	rate = (mul * 1200000 / div);
+
+	of_property_read_string(node, "clock-output-names", &name);
+	clk = clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
+	clk_register_clkdev(clk, NULL, name);
+	of_clk_add_provider(node, of_clk_src_simple_get, clk);
+
+	iounmap(base);
+}
+CLK_OF_DECLARE(moxart_core_clock, "moxa,moxart-core-clock", moxart_of_clk_init);
-- 
1.8.2.1



From tony at atomide.com  Mon Jul 29 05:45:02 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 29 Jul 2013 02:45:02 -0700
Subject: [PATCH 2/4] pinctrl: Allow pinctrl to have multiple active states
In-Reply-To: <CACRpkdY5-OFN4YQywPj06jkf493BhwgJGMEnmKmbovTh+co2Yg@mail.gmail.com>
References: <20130718151213.30990.45828.stgit@localhost>
 <20130718151507.30990.67174.stgit@localhost>
 <CACRpkdY5-OFN4YQywPj06jkf493BhwgJGMEnmKmbovTh+co2Yg@mail.gmail.com>
Message-ID: <20130729094501.GC7656@atomide.com>

* Linus Walleij <linus.walleij at linaro.org> [130722 16:01]:
> On Thu, Jul 18, 2013 at 5:15 PM, Tony Lindgren <tony at atomide.com> wrote:
> 
> > It's quite common that we need to dynamically change some pins for a
> > device for runtime PM, or toggle a pin between rx and tx. Changing all
> 
> What does "change" mean above?
> 
> Please reword to "remux" if that is what is meant.

Yes remux or reconfigure the pinconf depending on the hardware.
And possibly based on the board specific configuration if both
options are available.
 
> > the pins for a device is not efficient way of doing it.
> >
> > So let's allow setting up multiple active states for pinctrl.
> 
> Do you mean multiple default states?
> 
> I have a hard time understanding so please help me out :-/

One default state, which should only contain the static pins that
don't need to be remuxed or reconfigured during runtime PM.

It should probably say "support for multiple currently activated
states", does that make it clearer?
 
> > Currently
> > we only need PINCTRL_STATIC and PINCTRL_DYNAMIC, where PINCTRL_STATIC
> > covers the current default pins, and PINCTRL_DYNAMIC holds the dynamic
> > pins that need to be toggled.
> 
> Toggled when?

Remuxed or reconfigured constantly for runtime PM.
 
> When changing state to another one? Any other state? Or back to
> this state? Sorry not following ... this needs to be more verbose.

How about "toggle dynamic pins between active and idle state
for runtime PM"?
 
> > --- a/drivers/pinctrl/core.h
> > +++ b/drivers/pinctrl/core.h
> > @@ -53,12 +53,18 @@ struct pinctrl_dev {
> >  #endif
> >  };
> >
> > +enum pinctrl_states {
> > +       PINCTRL_STATIC,
> > +       PINCTRL_DYNAMIC,
> > +       PINCTRL_NR_STATES,
> > +};
> 
> This needs some very precise kerneldoc so it is chrystal clear what these
> states are all about. "pinctrl_states" is not a good name for this enum,
> please find some more precise name, because we have functions
> with names like pinctrl_select_state() which is not related to this.
> 
> Is this substates or?

This lists the sets of pins that can be activated the same
time. So after this, we support two sets of pins that a
pinctrl consumer driver can have activated the same time:
static pins and dynamic pins. There can be any number of
named modes for dynamic pins, but typically only active and
idle.

Then if for some reason we need more than two sets activated
the same time, we can expand the array as needed. So that's
mostly to try to keep things future proof and not limit things
to two sets as noted by Stephen earlier.
 
> > +
> >  /**
> >   * struct pinctrl - per-device pin control state holder
> >   * @node: global list node
> >   * @dev: the device using this pin control handle
> >   * @states: a list of states for this device
> > - * @state: the current state
> > + * @state: the current state(s)
> 
> How can more than one state be the current state? Sorry I don't get this.
> This needs to be more precise I think.

Hopefully the explanation above helps with that, if not,
let me know.
 
Regards,

Tony


From vincent.guittot at linaro.org  Mon Jul 29 05:46:06 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Mon, 29 Jul 2013 11:46:06 +0200
Subject: [RFC][PATCH 1/2] ARM64: add cpu topology definition
In-Reply-To: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>
References: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>
Message-ID: <CAKfTPtBpo41LJ3V8TB8YwudwqpURuA2u_Lvu4KYVK=qSs+gFuQ@mail.gmail.com>

On 27 July 2013 12:42, Hanjun Guo <hanjun.guo at linaro.org> wrote:
> Power aware scheduling needs the cpu topology information to improve the
> cpu scheduler decision making.

It's not only power aware scheduling. The scheduler already uses
topology and cache sharing when  CONFIG_SCHED_MC and/or
CONFIG_SCHED_SMT are enable. So you should also add these configs for
arm64 so the scheduler can use it

Vincent

>
> For ARM64, we can get the topology from the MPIDR register which defines the
> the affinity of processors.
>
> This patch is mainly based on arch/arm/kernel/topology.c written by
> Vincent Guittot, and replaced the topology array with per cpu variable.
>
> Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
> ---
>  arch/arm64/Kconfig                |    9 +++
>  arch/arm64/include/asm/cputype.h  |   11 ++++
>  arch/arm64/include/asm/topology.h |   41 ++++++++++++
>  arch/arm64/kernel/Makefile        |    1 +
>  arch/arm64/kernel/smp.c           |    6 ++
>  arch/arm64/kernel/topology.c      |  128 +++++++++++++++++++++++++++++++++++++
>  6 files changed, 196 insertions(+)
>  create mode 100644 arch/arm64/include/asm/topology.h
>  create mode 100644 arch/arm64/kernel/topology.c
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 9737e97..f0ce91b 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -150,6 +150,15 @@ config SMP
>
>           If you don't know what to do here, say N.
>
> +config ARM64_CPU_TOPOLOGY
> +       bool "Support cpu topology definition"
> +       depends on SMP && ARM64
> +       default y
> +       help
> +         Support ARM64 cpu topology definition. The MPIDR register defines
> +         affinity between processors which is then used to describe the cpu
> +         topology of an ARM64 System.
> +
>  config NR_CPUS
>         int "Maximum number of CPUs (2-32)"
>         range 2 32
> diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
> index 5fe138e..68b55af 100644
> --- a/arch/arm64/include/asm/cputype.h
> +++ b/arch/arm64/include/asm/cputype.h
> @@ -30,6 +30,17 @@
>
>  #define MPIDR_HWID_BITMASK     0xff00ffffff
>
> +#define MPIDR_SMP_BITMASK      (0x1 << 30)
> +#define MPIDR_MT_BITMASK       (0x1 << 24)
> +
> +#define MPIDR_LEVEL_BITS       8
> +#define MPIDR_LEVEL_MASK       ((1 << MPIDR_LEVEL_BITS) - 1)
> +
> +#define MPIDR_AFFINITY_LEVEL_0(mpidr) ((mpidr) & MPIDR_LEVEL_MASK)
> +#define MPIDR_AFFINITY_LEVEL_1(mpidr) ((mpidr >> 8) & MPIDR_LEVEL_MASK)
> +#define MPIDR_AFFINITY_LEVEL_2(mpidr) ((mpidr >> 16) & MPIDR_LEVEL_MASK)
> +#define MPIDR_AFFINITY_LEVEL_3(mpidr) ((mpidr >> 32) & MPIDR_LEVEL_MASK)
> +
>  #define read_cpuid(reg) ({                                             \
>         u64 __val;                                                      \
>         asm("mrs        %0, " reg : "=r" (__val));                      \
> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> new file mode 100644
> index 0000000..8631808
> --- /dev/null
> +++ b/arch/arm64/include/asm/topology.h
> @@ -0,0 +1,41 @@
> +#ifndef _ASM_ARM64_TOPOLOGY_H
> +#define _ASM_ARM64_TOPOLOGY_H
> +
> +#ifdef CONFIG_ARM64_CPU_TOPOLOGY
> +
> +#include <linux/cpumask.h>
> +
> +struct cputopo_arm64 {
> +       int thread_id;
> +       int core_id;
> +       int socket_id;
> +       cpumask_t thread_sibling;
> +       cpumask_t core_sibling;
> +};
> +
> +DECLARE_PER_CPU(struct cputopo_arm64, cpu_topology);
> +
> +#define cpu_topo(cpu) per_cpu(cpu_topology, cpu)
> +
> +#define topology_physical_package_id(cpu)      (cpu_topo(cpu).socket_id)
> +#define topology_core_id(cpu)          (cpu_topo(cpu).core_id)
> +#define topology_core_cpumask(cpu)     (&cpu_topo(cpu).core_sibling)
> +#define topology_thread_cpumask(cpu)   (&cpu_topo(cpu).thread_sibling)
> +
> +#define mc_capable()   (cpu_topo(0).socket_id != -1)
> +#define smt_capable()  (cpu_topo(0).thread_id != -1)
> +
> +void init_cpu_topology(void);
> +void store_cpu_topology(unsigned int cpuid);
> +const struct cpumask *cpu_coregroup_mask(int cpu);
> +
> +#else
> +
> +static inline void init_cpu_topology(void) { }
> +static inline void store_cpu_topology(unsigned int cpuid) { }
> +
> +#endif
> +
> +#include <asm-generic/topology.h>
> +
> +#endif /* _ASM_ARM64_TOPOLOGY_H */
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 7b4b564..a47c359 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -18,6 +18,7 @@ arm64-obj-$(CONFIG_SMP)                       += smp.o smp_spin_table.o smp_psci.o
>  arm64-obj-$(CONFIG_HW_PERF_EVENTS)     += perf_event.o
>  arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT)+= hw_breakpoint.o
>  arm64-obj-$(CONFIG_EARLY_PRINTK)       += early_printk.o
> +arm64-obj-$(CONFIG_ARM64_CPU_TOPOLOGY)  += topology.o
>
>  obj-y                                  += $(arm64-obj-y) vdso/
>  obj-m                                  += $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index fee5cce..197b1da 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -39,6 +39,7 @@
>  #include <asm/atomic.h>
>  #include <asm/cacheflush.h>
>  #include <asm/cputype.h>
> +#include <asm/topology.h>
>  #include <asm/mmu_context.h>
>  #include <asm/pgtable.h>
>  #include <asm/pgalloc.h>
> @@ -215,6 +216,8 @@ asmlinkage void secondary_start_kernel(void)
>         local_irq_enable();
>         local_fiq_enable();
>
> +       store_cpu_topology(cpu);
> +
>         /*
>          * OK, it's off to the idle thread for us
>          */
> @@ -387,6 +390,9 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>         int cpu, err;
>         unsigned int ncores = num_possible_cpus();
>
> +       init_cpu_topology();
> +       store_cpu_topology(smp_processor_id());
> +
>         /*
>          * are we trying to boot more cores than exist?
>          */
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> new file mode 100644
> index 0000000..1eb0435
> --- /dev/null
> +++ b/arch/arm64/kernel/topology.c
> @@ -0,0 +1,128 @@
> +/*
> + * arch/arm64/kernel/topology.c
> + *
> + * Copyright (C) 2013 Linaro Limited.
> + * Written by: Hanjun Guo
> + *
> + * based on arch/arm/kernel/topology.c
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file "COPYING" in the main directory of this archive
> + * for more details.
> + */
> +
> +#include <linux/cpu.h>
> +#include <linux/cpumask.h>
> +#include <linux/init.h>
> +#include <linux/percpu.h>
> +#include <linux/sched.h>
> +
> +#include <asm/cputype.h>
> +#include <asm/topology.h>
> +
> +DEFINE_PER_CPU(struct cputopo_arm64, cpu_topology);
> +
> +const struct cpumask *cpu_coregroup_mask(int cpu)
> +{
> +       return &cpu_topo(cpu).core_sibling;
> +}
> +
> +void update_siblings_masks(unsigned int cpuid)
> +{
> +       struct cputopo_arm64 *topo, *cpuid_topo = &cpu_topo(cpuid);
> +       int cpu;
> +
> +       /* update core and thread sibling masks */
> +       for_each_possible_cpu(cpu) {
> +               topo = &cpu_topo(cpu);
> +
> +               if (cpuid_topo->socket_id != topo->socket_id)
> +                       continue;
> +
> +               cpumask_set_cpu(cpuid, &topo->core_sibling);
> +               if (cpu != cpuid)
> +                       cpumask_set_cpu(cpu, &cpuid_topo->core_sibling);
> +
> +               if (cpuid_topo->core_id != topo->core_id)
> +                       continue;
> +
> +               cpumask_set_cpu(cpuid, &topo->thread_sibling);
> +               if (cpu != cpuid)
> +                       cpumask_set_cpu(cpu, &cpuid_topo->thread_sibling);
> +       }
> +       smp_wmb();
> +}
> +
> +/*
> + * store_cpu_topology is called at boot when only one cpu is running
> + * and with the mutex cpu_hotplug.lock locked, when several cpus have booted,
> + * which prevents simultaneous write access to cpu_topology array
> + */
> +void store_cpu_topology(unsigned int cpuid)
> +{
> +       struct cputopo_arm64 *cpuid_topo = &cpu_topo(cpuid);
> +       u64 mpidr;
> +
> +       /* If the cpu topology has been already set, just return */
> +       if (cpuid_topo->core_id != -1)
> +               return;
> +
> +       mpidr = read_cpuid_mpidr();
> +
> +       /* create cpu topology mapping */
> +       if (!(mpidr & MPIDR_SMP_BITMASK)) {
> +               /*
> +                * This is a multiprocessor system
> +                * multiprocessor format & multiprocessor mode field are set
> +                */
> +
> +               if (mpidr & MPIDR_MT_BITMASK) {
> +                       /* core performance interdependency */
> +                       cpuid_topo->thread_id = MPIDR_AFFINITY_LEVEL_0(mpidr);
> +                       cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL_1(mpidr);
> +                       cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_2(mpidr);
> +               } else {
> +                       /* largely independent cores */
> +                       cpuid_topo->thread_id = -1;
> +                       cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL_0(mpidr);
> +                       cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_1(mpidr);
> +               }
> +       } else {
> +               /*
> +                * This is an uniprocessor system
> +                * we are in multiprocessor format but uniprocessor system
> +                * or in the old uniprocessor format
> +                */
> +               cpuid_topo->thread_id = -1;
> +               cpuid_topo->core_id = 0;
> +               cpuid_topo->socket_id = -1;
> +       }
> +
> +       update_siblings_masks(cpuid);
> +
> +       printk(KERN_INFO "CPU%u: thread %d, cpu %d, socket %d, mpidr 0x%llx\n",
> +               cpuid, cpu_topo(cpuid).thread_id,
> +               cpu_topo(cpuid).core_id,
> +               cpu_topo(cpuid).socket_id, mpidr);
> +}
> +
> +/*
> + * init_cpu_topology is called at boot when only one cpu is running
> + * which prevent simultaneous write access to cpu_topology array
> + */
> +void __init init_cpu_topology(void)
> +{
> +       unsigned int cpu;
> +
> +       /* init core mask */
> +       for_each_possible_cpu(cpu) {
> +               struct cputopo_arm64 *topo = &cpu_topo(cpu);
> +
> +               topo->thread_id = -1;
> +               topo->core_id =  -1;
> +               topo->socket_id = -1;
> +               cpumask_clear(&topo->core_sibling);
> +               cpumask_clear(&topo->thread_sibling);
> +       }
> +       smp_wmb();
> +}
> --
> 1.7.9.5
>


From paul at pwsan.com  Mon Jul 29 05:47:45 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 29 Jul 2013 09:47:45 +0000 (UTC)
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping
 for every GPIO on DT"
In-Reply-To: <51F633AE.8090308@collabora.co.uk>
References: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
 <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
 <51F633AE.8090308@collabora.co.uk>
Message-ID: <alpine.DEB.2.02.1307290943000.30864@utopia.booyaka.com>

Hi

On Mon, 29 Jul 2013, Javier Martinez Canillas wrote:

> I've looked at this and it seems that irq_create_mapping() does not call the
> irq_domain_ops .map function handler since OMAP1 still uses legacy domain
> mapping. I don't have an OMAP1 platform to test but could you please see if the
> following patch [1] makes your OMAP1 platforms to boot again?
> 
> But I agree with Linus and probably we should just go and revert the whole
> series since it is very hard to get it right. In another thread a user reported
> that this change also broke his DTS tree.
> 
> I really tried to get this right without breaking anything but there are just
> too many OMAP platforms behaving differently and most OMAP drivers are only half
> converted to DT so this is really a can of worms.
> 
> Thanks a lot and sorry for the inconvenience,
> Javier
> 
> [1]:
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index c57244e..f1c6da8 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1090,8 +1090,18 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
>          * are used as interrupts.
>          */
>         if (!omap_gpio_chip_boot_dt(&bank->chip))
> -               for (j = 0; j < bank->width; j++)
> -                       irq_create_mapping(bank->domain, j);
> +               for (j = 0; j < bank->width; j++) {
> +                       int irq = irq_create_mapping(bank->domain, j);
> +                       irq_set_lockdep_class(irq, &gpio_lock_class);
> +                       irq_set_chip_data(irq, bank);
> +                       if (bank->is_mpuio) {
> +                               omap_mpuio_alloc_gc(bank, irq, bank->width);
> +                       } else {
> +                               irq_set_chip_and_handler(irq, &gpio_irq_chip,
> +                                                        handle_simple_irq);
> +                               set_irq_flags(irq, IRQF_VALID);
> +                       }
> +               }
>         irq_set_chained_handler(bank->irq, gpio_irq_handler);
>         irq_set_handler_data(bank->irq, bank);
> 

For some reason this patch didn't apply cleanly on v3.11-rc3, so 
hand-applied the following patch.  It still doesn't boot on v3.11-rc3:

http://www.pwsan.com/omap/testlogs/bisect_5912osk_boot_fail_v3.11-rc3/20130729032525/boot/5912osk/5912osk_log.txt


- Paul

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c57244e..23da829 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1090,8 +1090,19 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
 	 * are used as interrupts.
 	 */
 	if (!omap_gpio_chip_boot_dt(&bank->chip))
-		for (j = 0; j < bank->width; j++)
-			irq_create_mapping(bank->domain, j);
+		for (j = 0; j < bank->width; j++) {
+			int irq = irq_create_mapping(bank->domain, j);
+			irq_set_lockdep_class(irq, &gpio_lock_class);
+			irq_set_chip_data(irq, bank);
+			if (bank->is_mpuio) {
+				omap_mpuio_alloc_gc(bank, irq, bank->width);
+			} else {
+				irq_set_chip_and_handler(irq, &gpio_irq_chip,
+							 handle_simple_irq);
+				set_irq_flags(irq, IRQF_VALID);
+			}
+		}
+
 	irq_set_chained_handler(bank->irq, gpio_irq_handler);
 	irq_set_handler_data(bank->irq, bank);
 }


From will.deacon at arm.com  Mon Jul 29 05:54:01 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 29 Jul 2013 10:54:01 +0100
Subject: [RFC][PATCH 1/2] ARM64: add cpu topology definition
In-Reply-To: <CAKfTPtBpo41LJ3V8TB8YwudwqpURuA2u_Lvu4KYVK=qSs+gFuQ@mail.gmail.com>
References: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>
 <CAKfTPtBpo41LJ3V8TB8YwudwqpURuA2u_Lvu4KYVK=qSs+gFuQ@mail.gmail.com>
Message-ID: <20130729095400.GB32383@mudshark.cambridge.arm.com>

On Mon, Jul 29, 2013 at 10:46:06AM +0100, Vincent Guittot wrote:
> On 27 July 2013 12:42, Hanjun Guo <hanjun.guo at linaro.org> wrote:
> > Power aware scheduling needs the cpu topology information to improve the
> > cpu scheduler decision making.
> 
> It's not only power aware scheduling. The scheduler already uses
> topology and cache sharing when  CONFIG_SCHED_MC and/or
> CONFIG_SCHED_SMT are enable. So you should also add these configs for
> arm64 so the scheduler can use it

... except that the architecture doesn't define what the AFF fields in MPIDR
really represent. Using them to make key scheduling decisions relating to
cache proximity seems pretty risky to me, especially given the track record
we've seen already on AArch32 silicon. It's a convenient register if it
contains the data we want it to contain, but we need to force ourselves to
come to terms with reality here and simply use it as an identifier for a
CPU.

Can't we just use the device-tree to represent this topological data for
arm64? Lorenzo has been working on bindings in this area.

Will


From a0393675 at ti.com  Mon Jul 29 05:57:08 2013
From: a0393675 at ti.com (Keerthy)
Date: Mon, 29 Jul 2013 15:27:08 +0530
Subject: [PATCH 0/9] ARM: dts: omap5-uevm: fixup wrong regulator
 configuration
In-Reply-To: <1374079538-19548-1-git-send-email-nm@ti.com>
References: <1374079538-19548-1-git-send-email-nm@ti.com>
Message-ID: <51F63C74.6070503@ti.com>

Hi Nishanth,

On Wednesday 17 July 2013 10:15 PM, Nishanth Menon wrote:
> Due to wrong older revision of documentation used as reference, we
> seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
> series is based power tree on production board 750-2628-XXX platform.
> Unfortunately, the wrong voltages may be detrimental to OMAP5 as they
> supply hardware blocks at voltages that are out of specification.

This series looks good to me.

Acked-by:  J Keerthy <j-keerthy at ti.com>
> Also available at:
> based on v3.11-rc1 tag
> http link: https://github.com/nmenon/linux-2.6-playground/commits/push/omap5-palmas-fixes
> git link: git://github.com/nmenon/linux-2.6-playground.git
> branch: push/omap5-palmas-fixes
>
> Tested with https://patchwork.kernel.org/patch/2545061/
>   + https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=for_3.11/out_of_tree/omap5_clk_data
> Test result: http://pastebin.com/YqASYkXG
>
> Relevant documentation:
> - OMAP5 uEVM documentation: https://www.svtronics.com/omap/omap54xx?product_id=33
> - OMAP5432 Data Manual: http://www.ti.com/product/OMAP5432
> - TWL6037 / OTP information: Currently available only under NDA
>
> Nishanth Menon (9):
>    ARM: dts: omap5-uevm: document regulator signals used on the actual
>      board
>    ARM: dts: omap5-uevm: update SMPS9 settings
>    ARM: dts: omap5-uevm: update and disable unused regulators LDO[28]
>    ARM: dts: omap5-uevm: update LDO1 voltage to 1.5V and settings
>    ARM: dts: omap5-uevm: update LDO3 voltage to 1.5V and settings
>    ARM: dts: omap5-uevm: update LDO4 voltage to 1.5V and settings
>    ARM: dts: omap5-uevm: update LDO6 voltage to 1.2V
>    ARM: dts: omap5-uevm: update LDO7 voltage to 2V and settings
>    ARM: dts: omap5-uevm: update SDCARD LDO9 and resource REGEN3
>
>   arch/arm/boot/dts/omap5-uevm.dts |   78 ++++++++++++++++++++++++--------------
>   1 file changed, 49 insertions(+), 29 deletions(-)
>
Regards,
Keerthy


From will.deacon at arm.com  Mon Jul 29 06:02:43 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 29 Jul 2013 11:02:43 +0100
Subject: [PATCH] ARM: v6: prevent gcc from reordering extended CP15 reads
 above is_smp() test
In-Reply-To: <alpine.DEB.2.02.1307282012280.23852@utopia.booyaka.com>
References: <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com>
 <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com>
 <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307280538460.8385@utopia.booyaka.com>
 <alpine.DEB.2.02.1307282012280.23852@utopia.booyaka.com>
Message-ID: <20130729100243.GC32383@mudshark.cambridge.arm.com>

Hi Paul,

On Sun, Jul 28, 2013 at 09:16:29PM +0100, Paul Walmsley wrote:
> 
> Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
> don't flush icache in switch_mm with hardware broadcasting") breaks
> the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
> undefined instruction abort from the CP15 read in
> cache_ops_need_broadcast().  It turns out that gcc reorders the
> extended CP15 read above the is_smp() test.  This breaks ARM1136 r0
> cores, since they don't support several CP15 registers that later ARM
> cores do.  ARM1136JF-S TRM section 3.2.1 "Register allocation" has the
> details.

Cheers for tracking this down. Interestingly, I can't reproduce this with
anything other than GCC 4.5.* tools -- 4.6+ do what we want. Still, it looks
like a valid (if not misguided) thing to do.

> diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
> index 8c25dc4..f428eb0 100644
> --- a/arch/arm/include/asm/cputype.h
> +++ b/arch/arm/include/asm/cputype.h
> @@ -89,13 +89,25 @@ extern unsigned int processor_id;
>  		__val;							\
>  	})
>  
> +
> +# if defined(CONFIG_CPU_V6)
> +/*
> + * The mrc in the read_cpuid_ext macro must not be reordered on ARMv6,
> + * else the compiler may move it before an is_smp() test, causing
> + * undefined instruction aborts on ARM1136 r0.
> + */
> +# define CPUID_EXT_REORDER	"cc", "memory"
> +# else
> +# define CPUID_EXT_REORDER	"cc"
> +# endif
> +
>  #define read_cpuid_ext(ext_reg)						\
>  	({								\
>  		unsigned int __val;					\
>  		asm("mrc	p15, 0, %0, c0, " ext_reg		\
>  		    : "=r" (__val)					\
>  		    :							\
> -		    : "cc");						\
> +		    : CPUID_EXT_REORDER);				\
>  		__val;							\
>  	})

I wouldn't worry about checking for CPU_V6. Besides, we probably need this
to be re-evaluated across barrier() when we get CPU migration on a
big-little platform anyway (we should probably also drop the
__attribute_const__ for that).

So you can just replace the "cc" (now that Nico kindly explained why those
aren't needed the other day) with "memory".

An alternative is to add barrier() between is_smp() and the read_cpuid_ext()
in all callers, adding a fake read from the stack to the latter (like I did
for the per-cpu accessor). However, this relies on fixing all callers for
very little gain, so I don't think it's worth the hassle.

I can cook a patch if you're tied up with other things -- just let me know.

Cheers,

Will


From daniel.lezcano at linaro.org  Mon Jul 29 06:06:16 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 29 Jul 2013 12:06:16 +0200
Subject: [PATCH] ARM: EXYNOS: cpuidle: Skip C1 cpuidle state for exynos5440
In-Reply-To: <CADGdYn6zsr7HTcV2PD++Ze1Otwf5A51D7GwLDmUuqMdRiN+h=Q@mail.gmail.com>
References: <0e7d01ce8840$82f79070$88e6b150$@org> <51F4F317.1040001@linaro.org>
 <CADGdYn761S+rDe=GaypFwAYdtQxFZRv0W=jmX9-KomogK5T7ww@mail.gmail.com>
 <13615299.reg39gbbhi@flatron>
 <CADGdYn6zsr7HTcV2PD++Ze1Otwf5A51D7GwLDmUuqMdRiN+h=Q@mail.gmail.com>
Message-ID: <51F63E98.3090906@linaro.org>

On 07/29/2013 11:33 AM, amit daniel kachhap wrote:
> Hi Tomasz,
> 
> On Mon, Jul 29, 2013 at 2:03 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
>> On Monday 29 of July 2013 10:16:14 amit daniel kachhap wrote:
>>> Hi Daniel/Tomasz,
>>>
>>> From the discussion I can conclude that SOC check is needed in the
>>> cpuidle driver for deeper C states.
>>
>> A check is needed for the whole cpuidle driver, so it registers only on
>> Exynos SoCs which support deeper C states.
> 
>>
>>> Only the question is where to
>>> insert this.
>>
>> Exynos doesn't support multiplatform yet, but we must make sure that any
>> code being added is multiplatform-aware. So initcall is not a good idea. I
>> would put this somewhere on Exynos-specific initialization path, i.e.
>> something that would not called for all platforms compiled in (in case of
>> multiplatform).
>>
>> As I discussed with Daniel, this should be using a traditional
>> platform_driver model, with the difference that it can't be registered
>> from device tree, but rather statically in mach code.
>>
>> For example, you can add an exynos_register_cpuidle() function in
>> arch/arm/mach-exynos/common.c, which registers such platform device and
>> always call it from exynos4_dt_machine_init() in mach-exynos4-dt.c. In
>> mach-exynos5-dt.c you could make this conditional and check if
>> !soc_is_exynos5440().
> thanks for the detailed explanation. Certainly initcall is not good
> for multikernel. Still I have few concerns.
> 1) Each C state might be SOC specific. Say there are 3 C states
> C0(basic wfi), c1(single CPU power down) and C2 (System wide power
> down like AFTR). In this case some exynos soc may support few of these
> states and cpuidle driver should bind C-state to correct SOC.
> 2) Even for default C0 ( simple wfi) currently there is no sysfs
> information if the cpuidle driver is not registered(Not quite sure).
> I will try to post the new driver by dynamically creating the
> cpuidle_state table based on SOC capability and removing the initcall.

Why don't you create a cpuidle driver for each SoC family ?

I am cleaning up all the drivers to unify the code, hoping we can factor
all the drivers through a single ARM driver and assign the ops for the
different states.

As Thomasz said, the platform driver model should be used, no need of
initcall, the code path will initialize the driver or not depending of
the SoC. You should not have any "soc_is_*" checks. This is the
direction all the ARM drivers are going to.

Look at the example I sent with the ux500, it illustrates the idea.
There are other examples also: cpuidle-kirkwood.c, cpuidle for davinci.

Concerning the "single cpu power down" state, is the exynos able to
handle that ? I mean, is it possible to power down a core and have it
woken up by an interrupt ?

Concerning the AFTR state : Is there a way to use this state with *all*
cpus online ? If not, shall we use the same approach than omap4, that is
CPU0 power down CPU1 and goes to AFTR (all interrupts migrated to CPU0)
and then wake up CPU1 when CPU0 is woken up ?

Concerning WFI and sysfs, if there are no cpuidle driver registered, no
sysfs. I would not focus on and spent too much effort for the statistics
because a lot of changes will certainly happen with the power aware
scheduler and the statistics will likely appear at this level.

Regards
  -- Daniel



>> Best regards,
>> Tomasz
>>
>>> Also to perform the SOC there can be 2 ways like
>>> 1) each SOC check 4120, 4412, 5250 etc (long list)
>>> 2) negate the nonsupporting SOC's like 5440 (small list like current
>>> patch) Any opinion?
>>>  As Bartlomiej suggested that this patch conflicts with Daniel's
>>> earlier patch http://marc.info/?l=linux-arm-kernel&m=137467935712513&w=2
>>> So I can re-base my patch on top of this one if needed.
>>>
>>> Thanks,
>>> Amit Daniel
>>>
>>> On Sun, Jul 28, 2013 at 4:01 PM, Daniel Lezcano
>>>
>>> <daniel.lezcano at linaro.org> wrote:
>>>> On 07/28/2013 11:22 AM, Tomasz Figa wrote:
>>>>> On Sunday 28 of July 2013 09:10:09 Daniel Lezcano wrote:
>>>>>> On 07/24/2013 01:47 PM, Kukjin Kim wrote:
>>>>>>> Amit Daniel Kachhap wrote:
>>>>>>>> This patch skips the deep C1(AFTR -Arm off top running) state for
>>>>>>>> exynos5440
>>>>>>>> soc as this soc does not support this state. All the cpu's only
>>>>>>>> allows the basic
>>>>>>>> C0 state.
>>>>>>>>
>>>>>>>> Signed-off-by: Amit Daniel Kachhap <amit.daniel at samsung.com>
>>>>>>>> ---
>>>>>>>>
>>>>>>>>  arch/arm/mach-exynos/cpuidle.c |    2 +-
>>>>>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-
>>>>>>>> exynos/cpuidle.c
>>>>>>>> index 17a18ff..9a776a1 100644
>>>>>>>> --- a/arch/arm/mach-exynos/cpuidle.c
>>>>>>>> +++ b/arch/arm/mach-exynos/cpuidle.c
>>>>>>>> @@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void)
>>>>>>>>
>>>>>>>>            device->cpu = cpu_id;
>>>>>>>>
>>>>>>>>            /* Support IDLE only */
>>>>>>>>
>>>>>>>> -          if (cpu_id != 0)
>>>>>>>> +          if (soc_is_exynos5440() || cpu_id != 0)
>>>>>>>>
>>>>>>>>                    device->state_count = 1;
>>>>>>>>
>>>>>>>>            ret = cpuidle_register_device(device);
>>>>>>>>
>>>>>>>> --
>>>>>>>> 1.7.1
>>>>>>>
>>>>>>> Applied, thanks.
>>>>>>
>>>>>> You shouldn't have. This patch means exynos5540 has no cpuidle
>>>>>> driver at all. It should be fixed in the Kconfig to unselect
>>>>>> CONFIG_CPU_IDLE for an exynos5540.
>>>>>
>>>>> To shed more light on this, let me add that you need to register a
>>>>> cpuidle driver only if you have more states than a simple WFI or you
>>>>> need some crazy steps to enter WFI. Default setup falls back to
>>>>> generic ARM WFI. (Daniel, do we get the nice idle stats as provided
>>>>> by cpuidle core then?)>
>>>> Nope, but with one state, idle vs busy stats do the trick.
>>>>
>>>> BTW, I am writing a tool to do some stats based on the idle events
>>>> [1].
>>>> It is still at a very early development stage but we can get some
>>>> interesting informations.
>>>>
>>>>> Anyway, Exynos cpuidle is using an initcall to initialize and we
>>>>> support multiple Exynos SoCs in single zImage, so deselecting
>>>>> CONFIG_CPU_IDLE is not an option.
>>>>
>>>> Good point.
>>>>
>>>>> Considering multiplatform requirements, the driver has to
>>>>>
>>>>> be modified to initialize only on supported platforms, either by:
>>>>>  a) dropping the initcall and calling the init function directly from
>>>>>
>>>>> arch/arm/mach-exynos
>>>>>
>>>>>  or
>>>>>
>>>>>  b) checking if machine we are running on is supported, which would
>>>>>  mean a>>
>>>>> long list of all Exynos SoCs that needs to be checked.
>>>>>
>>>>> An evolution of option a) is registering a platform device somewhere
>>>>> in
>>>>> arch/arm/mach-exynos and making exynos-cpuidle a platform driver.
>>>>
>>>> Yes, I am favorable to this solution [2].
>>>>
>>>>> The
>>>>> problem is that you must register a static platform device from arch
>>>>> code, because cpuidle is not a real hardware block that can be put
>>>>> into device tree.
>>>>
>>>> Thanks
>>>>
>>>>   -- Daniel
>>>>
>>>> [1]
>>>> https://git.linaro.org/gitweb?p=people/dlezcano/idlestat.git;a=summar
>>>> y [2] http://patches.linaro.org/18368/
>>>>
>>>> --
>>>>
>>>>  <http://www.linaro.org/> Linaro.org ? Open source software for ARM
>>>>  SoCs
>>>>
>>>> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
>>>> <http://twitter.com/#!/linaroorg> Twitter |
>>>> <http://www.linaro.org/linaro-blog/> Blog
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-samsung-soc" in the body of a message to
>>>> majordomo at vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From mark.rutland at arm.com  Mon Jul 29 06:13:03 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 29 Jul 2013 11:13:03 +0100
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <1375048598-15637-2-git-send-email-robherring2@gmail.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
 <1375048598-15637-2-git-send-email-robherring2@gmail.com>
Message-ID: <20130729101302.GJ3528@e106331-lin.cambridge.arm.com>

Hi Rob,

On Sun, Jul 28, 2013 at 10:56:32PM +0100, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> The PSCI spec from ARM has been updated to 0.2 version. Update the
> binding document to reflect the spec changes. For the binding, the
> major changes are addition of system reset and poweroff functions.
> The recommended function id numbering has also changed.
> 
> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> Cc: devicetree at vger.kernel.org
> ---
>  Documentation/devicetree/bindings/arm/psci.txt | 25 +++++++++++++++++++------
>  1 file changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
> index 433afe9..b8b4d9f 100644
> --- a/Documentation/devicetree/bindings/arm/psci.txt
> +++ b/Documentation/devicetree/bindings/arm/psci.txt
> @@ -21,7 +21,7 @@ to #0.
>  
>  Main node required properties:
>  
> - - compatible    : Must be "arm,psci"
> + - compatible    : Must be "arm,psci-0.2" or "arm,psci"

For the purposes of handling different firmware implementations (which
may have different bugs to work around and may require different
arguments to cpu_suspend), it may be better to state "must contain"
rather than "must be". 

>  
>   - method        : The method of calling the PSCI firmware. Permitted
>                     values are:
> @@ -32,6 +32,9 @@ Main node required properties:
>                     "hvc" : HVC #0, with the register assignments specified
>  		           in this binding.
>  
> + - psci_version  : Function ID for PSCI_VERSION operation. Required for
> +                   "arm,psci-0.2" compatible version or later.
> +
>  Main node optional properties:
>  
>   - cpu_suspend   : Function ID for CPU_SUSPEND operation

The low bits of CPU_SUSPEND's power_state argument are platform specific
and we'll need to deal with them if an implementation actually uses them
for something. We can probably associate this with a specific
implementation's compatible string, as we'll almost certainly need
special code to handle the differences between them.

If we have a compatible string for the first platform that ignores the
argument (or just uses zero), that can be shared by all those
implementations that don't give any fine-grained control here.

> @@ -42,14 +45,24 @@ Main node optional properties:
>  
>   - migrate       : Function ID for MIGRATE operation
>  
> + - system_reset  : Function ID for SYSTEM_RESET operation
> +
> + - system_off    : Function ID for SYSTEM_OFF operation
> +
>  
>  Example:
>  
>  	psci {
> -		compatible	= "arm,psci";
> +		compatible	= "arm,psci-0.2";
>  		method		= "smc";
> -		cpu_suspend	= <0x95c10000>;
> -		cpu_off		= <0x95c10001>;
> -		cpu_on		= <0x95c10002>;
> -		migrate		= <0x95c10003>;
> +		psci_version	= <0x84000000>;
> +		cpu_suspend	= <0x84000001>;
> +		cpu_off		= <0x84000002>;
> +		cpu_on		= <0x84000003>;
> +		affinity_info	= <0x84000004>; 
> +		migrate		= <0x84000005>;
> +		migrate_info_type = <0x84000006>; 
> +		migrate_info_up_cpu = <0x84000007>; 
> +		system_off	= <0x84000008>; 
> +		system_reset	= <0x84000009>; 
>  	};

One of the things changed in PSCI 0.2 was the SMC calling convention,
though this isn't clear in the PSCI document. The function IDs for 32bit
and 64bit callers may differ, and we need to support describing an
arbitrary configuration of the two (same ID for both, different across
32-bit/64-bit, only supported for 64-bit, only supported for 32-bit).

I'd like to ensure the binding can deal with that from the start. We
could do this by having -32 and -64 variants of each function id (e.g.
cpu_off-64) , if the IDs actually differ, and use the regular combined
ID if they don't.

Thanks,
Mark.


From hdoyu at nvidia.com  Mon Jul 29 06:13:44 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Mon, 29 Jul 2013 12:13:44 +0200
Subject: [PATCH v2 01/22] [HACK] of: dev_node has struct device pointer
In-Reply-To: <20130716231629.GA12189@dhcp-172-17-186-34.nvidia.com>
References: <1373021097-32420-2-git-send-email-hdoyu@nvidia.com><51E5CFBF.5080407@wwwdotorg.org><20130716231629.GA12189@dhcp-172-17-186-34.nvidia.com>
Message-ID: <20130729.131344.1221933042559369096.hdoyu@nvidia.com>

Thierry Reding <thierry.reding at gmail.com> wrote @ Wed, 17 Jul 2013 01:16:30 +0200:

> * PGP Signed by an unknown key
> 
> On Tue, Jul 16, 2013 at 04:57:03PM -0600, Stephen Warren wrote:
> > On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> > > To prevent of_platform_populate() from trying to populate duplicate
> > > devices if a device has been already populated.
> > 
> > You need to send drivers/of patches to the DT maintainer and
> > devicetree-discuss mailing list.
> > 
> > > Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
> > > ---
> > > Need to take care of early_platform_devices, or alternative solution.
> > 
> > I assume that's a TODO item... Are you planning on fleshing out this
> > patch to address that issue?
>
> There was some more discussion about it, which can be found in the
> following thread:
> 
> 	https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036934.html
> 
> That's one of the last messages and it should have most of the
> background. If not you may have to walk up the thread for more context.
> In a nutshell I raised the question as to why we can't simply call
> of_platform_populate() earlier and side-step all the workarounds that
> have found their way into the kernel to side-step the issue of their not
> being a struct device associated with the struct device_node.

This is the thread which Lorenzo started originally. He may have some
plan to implement/proceed with this, Lorenzo?


From Sudeep.KarkadaNagesha at arm.com  Mon Jul 29 06:15:07 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 29 Jul 2013 11:15:07 +0100
Subject: [RFC][PATCH 1/2] ARM64: add cpu topology definition
In-Reply-To: <CAKfTPtBpo41LJ3V8TB8YwudwqpURuA2u_Lvu4KYVK=qSs+gFuQ@mail.gmail.com>
References: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>
 <CAKfTPtBpo41LJ3V8TB8YwudwqpURuA2u_Lvu4KYVK=qSs+gFuQ@mail.gmail.com>
Message-ID: <51F640AB.2050709@arm.com>

On 29/07/13 10:46, Vincent Guittot wrote:
> On 27 July 2013 12:42, Hanjun Guo <hanjun.guo at linaro.org> wrote:
>> Power aware scheduling needs the cpu topology information to improve the
>> cpu scheduler decision making.
> 
> It's not only power aware scheduling. The scheduler already uses
> topology and cache sharing when  CONFIG_SCHED_MC and/or
> CONFIG_SCHED_SMT are enable. So you should also add these configs for
> arm64 so the scheduler can use it
> 
Just for my knowledge, I thought power aware using SCHED_MC/SMT was
removed. I see commit 8e7fbcbc22c12414bcc9dfdd683637f58fb32759 "sched:
Remove stale power aware scheduling remnants and dysfunctional knobs"
I may be missing something here.

Regards,
Sudeep



From arend at broadcom.com  Mon Jul 29 06:16:10 2013
From: arend at broadcom.com (Arend van Spriel)
Date: Mon, 29 Jul 2013 12:16:10 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <51F6338E.8020101@broadcom.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
 <2460092.aLmjrOVh1g@flatron> <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
 <51F6338E.8020101@broadcom.com>
Message-ID: <51F640EA.7040509@broadcom.com>

On 07/29/2013 11:19 AM, Arend van Spriel wrote:
> On 07/27/2013 10:01 PM, jonsmirl at gmail.com wrote:
>> On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely
>> <grant.likely at secretlab.ca> wrote:
>>> On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel
>>> <arend at broadcom.com> wrote:
>>>> Let's see how many people go and scream if I say this: Too bad .dts
>>>> files
>>>> are not done using XML format as DT bindings could be described
>>>> using XML
>>>> Schema.
>>>
>>> Draft an example and show us how it would look!  :-)  There is
>>> absolutely nothing preventing us from expressing a DT in XML format,
>>> or even using XSLT to define DT schema while still using our current
>>> .dts syntax. It would be trivial to do lossless translation between
>>> .dts syntax and xml.
>>>
>>> The problem that I have with XML and XSLT is that it is very verbose
>>> and not entirely friendly to mere-mortals. However, I'm more than
>>> willing to be proved wrong on this point.
>>
>> I considered this approach a while ago and discarded it. It would work
>> but it is just too much of a Frankenstein monster.
>
> Ah, but he is so cute. At least I do not think it is more monstrous as
> the bindings files. I just browsed through a couple of arm binding files
> as I felt challenged to come up with an example. I did not get the
> impression that there is some kind of template in place to get consitent
> bindings descriptions.
>
>> Much cleaner to modify dtc to take a schema as part of the compilation
>> process. The schema language itself has no requirement to look like
>> DTS syntax. Whoever wrote dtc probably has a favorite language that
>> would be good for writing schemas in.
>
> Not sure if I can follow here. I guess you mean the dts compilation,
> right? There are tools freely available to validate XML files against
> XSD specification files. As an example libxml2 has support for it. I
> suspect it is not desired to have a dependency for DTC with an
> out-of-tree library, but it could be incorporated and have DTC spew the
> validation results.

crap. Probably not as libxml2 has MIT-license.

Regards,
Arend



From javier.martinez at collabora.co.uk  Mon Jul 29 06:19:22 2013
From: javier.martinez at collabora.co.uk (Javier Martinez Canillas)
Date: Mon, 29 Jul 2013 12:19:22 +0200
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping
 for every GPIO on DT"
In-Reply-To: <alpine.DEB.2.02.1307290943000.30864@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
 <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
 <51F633AE.8090308@collabora.co.uk>
 <alpine.DEB.2.02.1307290943000.30864@utopia.booyaka.com>
Message-ID: <D135FD6D-D4B6-4237-9866-4FFED36C03CD@collabora.co.uk>

On 29/07/2013, at 11:47, Paul Walmsley <paul at pwsan.com> wrote:

> Hi
> 
> On Mon, 29 Jul 2013, Javier Martinez Canillas wrote:
> 
>> I've looked at this and it seems that irq_create_mapping() does not call the
>> irq_domain_ops .map function handler since OMAP1 still uses legacy domain
>> mapping. I don't have an OMAP1 platform to test but could you please see if the
>> following patch [1] makes your OMAP1 platforms to boot again?
>> 
>> But I agree with Linus and probably we should just go and revert the whole
>> series since it is very hard to get it right. In another thread a user reported
>> that this change also broke his DTS tree.
>> 
>> I really tried to get this right without breaking anything but there are just
>> too many OMAP platforms behaving differently and most OMAP drivers are only half
>> converted to DT so this is really a can of worms.
>> 
>> Thanks a lot and sorry for the inconvenience,
>> Javier
>> 
>> [1]:
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index c57244e..f1c6da8 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -1090,8 +1090,18 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
>>         * are used as interrupts.
>>         */
>>        if (!omap_gpio_chip_boot_dt(&bank->chip))
>> -               for (j = 0; j < bank->width; j++)
>> -                       irq_create_mapping(bank->domain, j);
>> +               for (j = 0; j < bank->width; j++) {
>> +                       int irq = irq_create_mapping(bank->domain, j);
>> +                       irq_set_lockdep_class(irq, &gpio_lock_class);
>> +                       irq_set_chip_data(irq, bank);
>> +                       if (bank->is_mpuio) {
>> +                               omap_mpuio_alloc_gc(bank, irq, bank->width);
>> +                       } else {
>> +                               irq_set_chip_and_handler(irq, &gpio_irq_chip,
>> +                                                        handle_simple_irq);
>> +                               set_irq_flags(irq, IRQF_VALID);
>> +                       }
>> +               }
>>        irq_set_chained_handler(bank->irq, gpio_irq_handler);
>>        irq_set_handler_data(bank->irq, bank);
> 
> For some reason this patch didn't apply cleanly on v3.11-rc3, so 
> hand-applied the following patch.  It still doesn't boot on v3.11-rc3:
> 
> http://www.pwsan.com/omap/testlogs/bisect_5912osk_boot_fail_v3.11-rc3/20130729032525/boot/5912osk/5912osk_log.txt
> 
> 
> - Paul
> 

Weird since it was against -rc3, maybe my mail client corrupted somehow.

I'm out of ideas now and I don't have an OMAP1 platform to further debug this issue.

I guess the safer approach is to just revert these since they are causing a regression and what the patches aims to fix as been broken since the initial OMAP migration to DT anyways.

Unless the current gpio-omap maintainers are willing to keep these patches and know how to fix this OMAP1 regression

Thanks a lot and sorry for this mess,
Javier

> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index c57244e..23da829 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1090,8 +1090,19 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
>     * are used as interrupts.
>     */
>    if (!omap_gpio_chip_boot_dt(&bank->chip))
> -        for (j = 0; j < bank->width; j++)
> -            irq_create_mapping(bank->domain, j);
> +        for (j = 0; j < bank->width; j++) {
> +            int irq = irq_create_mapping(bank->domain, j);
> +            irq_set_lockdep_class(irq, &gpio_lock_class);
> +            irq_set_chip_data(irq, bank);
> +            if (bank->is_mpuio) {
> +                omap_mpuio_alloc_gc(bank, irq, bank->width);
> +            } else {
> +                irq_set_chip_and_handler(irq, &gpio_irq_chip,
> +                             handle_simple_irq);
> +                set_irq_flags(irq, IRQF_VALID);
> +            }
> +        }
> +
>    irq_set_chained_handler(bank->irq, gpio_irq_handler);
>    irq_set_handler_data(bank->irq, bank);
> }


From stefano.stabellini at eu.citrix.com  Mon Jul 29 06:20:21 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 29 Jul 2013 11:20:21 +0100
Subject: [GIT PULL] Xen ARM fix for 3.11
Message-ID: <alpine.DEB.2.02.1307291056000.4893@kaball.uk.xensource.com>

Linus,
I have one fix for Xen on ARM for 3.11 (also appended for your
convenience):


The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b:

  Linux 3.11-rc2 (2013-07-21 12:05:29 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git xen-arm-3.11-rc2-warn-tag

Stefano Stabellini (1):
      xen/arm,arm64: update xen_restart after ff701306cd49 and 7b6d864b48d9

 arch/arm/xen/enlighten.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Thanks,

Stefano




commit 2451ade070ef9b0a0f118ac41896da856e72b5a1
Author: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Date:   Sun Jul 21 15:17:54 2013 +0000

    xen/arm,arm64: update xen_restart after ff701306cd49 and 7b6d864b48d9
    
    Commit 7b6d864b48d9 (reboot: arm: change reboot_mode to use enum
    reboot_mode) and ff701306cd49 (arm64: use common reboot infrastructure)
    change the prototype of arm_pm_restart on arm and arm64.
    Update xen_restart accordingly.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index f71c37e..c9770ba 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -172,7 +172,7 @@ static void __init xen_percpu_init(void *unused)
 	enable_percpu_irq(xen_events_irq, 0);
 }
 
-static void xen_restart(char str, const char *cmd)
+static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
 {
 	struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
 	int rc;


From jonas.jensen at gmail.com  Mon Jul 29 06:20:15 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Mon, 29 Jul 2013 12:20:15 +0200
Subject: [PATCH v5] watchdog: Add MOXA ART watchdog driver
In-Reply-To: <1374229402-20432-1-git-send-email-jonas.jensen@gmail.com>
References: <1374229402-20432-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1375093215-7136-1-git-send-email-jonas.jensen@gmail.com>

Add watchdog driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v4:
    
    1. #include <linux/err.h> because IS_ERR comes from there
    2. #include <linux/kernel.h> because UINT_MAX comes from there
    3. #include <linux/moduleparam.h> because module_param() comes from there
    
    device tree bindings document:
    4. describe compatible variable "Must be" instead of "Should be".
    5. change description so it's from the point of view of the device
    
    Applies to next-20130729

 .../bindings/watchdog/moxa,moxart-watchdog.txt     |  15 ++
 drivers/watchdog/Kconfig                           |  10 ++
 drivers/watchdog/Makefile                          |   1 +
 drivers/watchdog/moxart_wdt.c                      | 169 +++++++++++++++++++++
 4 files changed, 195 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
 create mode 100644 drivers/watchdog/moxart_wdt.c

diff --git a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
new file mode 100644
index 0000000..1169857
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
@@ -0,0 +1,15 @@
+MOXA ART Watchdog timer
+
+Required properties:
+
+- compatible : Must be "moxa,moxart-watchdog"
+- reg : Should contain registers location and length
+- clocks : Should contain phandle for the clock that drives the counter
+
+Example:
+
+	watchdog: watchdog at 98500000 {
+		compatible = "moxa,moxart-watchdog";
+		reg = <0x98500000 0x10>;
+		clocks = <&coreclk>;
+	};
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 362085d..6883aab 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -382,6 +382,16 @@ config RETU_WATCHDOG
 	  To compile this driver as a module, choose M here: the
 	  module will be called retu_wdt.
 
+config MOXART_WDT
+	tristate "MOXART watchdog"
+	depends on ARCH_MOXART
+	help
+	  Say Y here to include Watchdog timer support for the watchdog
+	  existing on the MOXA ART SoC series platforms.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called moxart_wdt.
+
 # AVR32 Architecture
 
 config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 2f26a0b..7cab53a 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
 obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
 obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
 obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
+obj-$(CONFIG_MOXART_WDT) += moxart_wdt.o
 
 # AVR32 Architecture
 obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
new file mode 100644
index 0000000..d79dc9c
--- /dev/null
+++ b/drivers/watchdog/moxart_wdt.c
@@ -0,0 +1,169 @@
+/*
+ * MOXA ART SoCs watchdog driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/watchdog.h>
+#include <linux/moduleparam.h>
+
+#define REG_COUNT			0x4
+#define REG_MODE			0x8
+#define REG_ENABLE			0xC
+
+struct moxart_wdt_dev {
+	struct watchdog_device dev;
+	void __iomem *base;
+	unsigned int clock_frequency;
+};
+
+static int heartbeat;
+
+static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+
+	writel(0, moxart_wdt->base + REG_ENABLE);
+
+	return 0;
+}
+
+static int moxart_wdt_start(struct watchdog_device *wdt_dev)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+
+	writel(moxart_wdt->clock_frequency * moxart_wdt->dev.timeout,
+	       moxart_wdt->base + REG_COUNT);
+	writel(0x5ab9, moxart_wdt->base + REG_MODE);
+	writel(0x03, moxart_wdt->base + REG_ENABLE);
+
+	return 0;
+}
+
+static int moxart_wdt_set_timeout(struct watchdog_device *wdt_dev,
+				  unsigned int timeout)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+
+	dev_dbg(wdt_dev->dev, "%s: timeout=%u\n", __func__, timeout);
+
+	moxart_wdt->dev.timeout = timeout;
+
+	return 0;
+}
+
+static const struct watchdog_info moxart_wdt_info = {
+	.identity       = "moxart-wdt",
+	.options        = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
+static const struct watchdog_ops moxart_wdt_ops = {
+	.owner          = THIS_MODULE,
+	.start          = moxart_wdt_start,
+	.stop           = moxart_wdt_stop,
+	.set_timeout    = moxart_wdt_set_timeout,
+};
+
+static int moxart_wdt_probe(struct platform_device *pdev)
+{
+	struct moxart_wdt_dev *moxart_wdt;
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct resource *res;
+	struct clk *clk;
+	int err;
+	unsigned int max_timeout;
+	bool nowayout = WATCHDOG_NOWAYOUT;
+
+	moxart_wdt = devm_kzalloc(&pdev->dev, sizeof(*moxart_wdt), GFP_KERNEL);
+	if (!moxart_wdt)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, moxart_wdt);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	moxart_wdt->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_wdt->base))
+		return PTR_ERR(moxart_wdt->base);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk)) {
+		pr_err("%s: of_clk_get failed\n", __func__);
+		return PTR_ERR(clk);
+	}
+
+	moxart_wdt->clock_frequency = clk_get_rate(clk);
+	if (moxart_wdt->clock_frequency == 0) {
+		pr_err("%s: incorrect clock frequency\n", __func__);
+		return -EINVAL;
+	}
+
+	max_timeout = UINT_MAX / moxart_wdt->clock_frequency;
+
+	moxart_wdt->dev.info = &moxart_wdt_info;
+	moxart_wdt->dev.ops = &moxart_wdt_ops;
+	moxart_wdt->dev.timeout = max_timeout;
+	moxart_wdt->dev.min_timeout = 1;
+	moxart_wdt->dev.max_timeout = max_timeout;
+	moxart_wdt->dev.parent = &pdev->dev;
+
+	watchdog_init_timeout(&moxart_wdt->dev, heartbeat, &pdev->dev);
+	watchdog_set_nowayout(&moxart_wdt->dev, nowayout);
+
+	watchdog_set_drvdata(&moxart_wdt->dev, moxart_wdt);
+
+	err = watchdog_register_device(&moxart_wdt->dev);
+	if (unlikely(err))
+		return err;
+
+	dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
+		moxart_wdt->dev.timeout, nowayout);
+
+	return 0;
+}
+
+static int moxart_wdt_remove(struct platform_device *pdev)
+{
+	struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
+
+	moxart_wdt_stop(&moxart_wdt->dev);
+	watchdog_unregister_device(&moxart_wdt->dev);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_watchdog_match[] = {
+	{ .compatible = "moxa,moxart-watchdog" },
+	{ },
+};
+
+static struct platform_driver moxart_wdt_driver = {
+	.probe      = moxart_wdt_probe,
+	.remove     = moxart_wdt_remove,
+	.driver     = {
+		.name		= "moxart-watchdog",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_watchdog_match,
+	},
+};
+module_platform_driver(moxart_wdt_driver);
+
+module_param(heartbeat, int, 0);
+MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");
+
+MODULE_DESCRIPTION("MOXART watchdog driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From mark.rutland at arm.com  Mon Jul 29 06:24:24 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 29 Jul 2013 11:24:24 +0100
Subject: [PATCH 7/7] dts: calxeda: add ARM PSCI binding
In-Reply-To: <1375048598-15637-8-git-send-email-robherring2@gmail.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
 <1375048598-15637-8-git-send-email-robherring2@gmail.com>
Message-ID: <20130729102424.GA24255@e106331-lin.cambridge.arm.com>

On Sun, Jul 28, 2013 at 10:56:38PM +0100, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> Add the PSCI binding for Calxeda SOCs. The PSCI function numbers are
> different from the DT binding example because the numbering changed in
> revisions of the PSCI spec and are already fixed in highbank firmware.
> Since the numbering is transparent to the kernel, this difference is not
> significant.
> 
> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> ---
>  arch/arm/boot/dts/ecx-common.dtsi | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/ecx-common.dtsi b/arch/arm/boot/dts/ecx-common.dtsi
> index e8559b7..f1dfc09 100644
> --- a/arch/arm/boot/dts/ecx-common.dtsi
> +++ b/arch/arm/boot/dts/ecx-common.dtsi
> @@ -19,6 +19,16 @@
>  		bootargs = "console=ttyAMA0";
>  	};
>  
> +	psci {
> +		compatible	= "arm,psci";
> +		method		= "smc";
> +		cpu_suspend	= <0x84000002>;
> +		cpu_off		= <0x84000004>;
> +		cpu_on		= <0x84000006>;
> +		system_off	= <0x84000100>;
> +		system_reset	= <0x84000101>;
> +	};
> +

I see this is somewhat beyond the original PSCI, given the addition of
SYSTEM_OFF and SYSTEM_RESET, but not quite PSCI 0.2 as you don't have
PSCI_VERSION.

It would be nice it the compatible string were more specific here to
deal with this and any implementation-specific power_state ID values.
Something like "calxeda,highbank-psci", "arm,psci" ?

Thanks,
Mark.


From vinod.koul at intel.com  Mon Jul 29 05:45:57 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 29 Jul 2013 15:15:57 +0530
Subject: [PATCH] dma: edma: add device_slave_caps() support
In-Reply-To: <20130725072351.GJ18642@intel.com>
References: <1374597804-3961-1-git-send-email-joelf@ti.com>
 <51EF8A52.90902@metafoo.de> <51EF8C2B.2030409@ti.com>
 <51EF8F4E.8080806@metafoo.de>
 <FB20353E-4890-4462-A671-3587A3841B4A@ti.com>
 <51EF92F2.3030405@metafoo.de> <51F0231C.7000401@ti.com>
 <20130724183329.GH18642@intel.com> <51F02CBA.5060704@ti.com>
 <20130725072351.GJ18642@intel.com>
Message-ID: <20130729094557.GG29095@intel.com>

On Thu, Jul 25, 2013 at 12:53:51PM +0530, Vinod Koul wrote:
> On Wed, Jul 24, 2013 at 02:36:26PM -0500, Joel Fernandes wrote:
> > > Also another point worth considering is the approach Russell suggested, I havent
> > > gotten a chance to dig deeper but if I understood it correctly then programming
> > > the device_dma_parameters should be the right thing to do. Again I need to look
> > > deeper and esp wrt edma
> > 
> > OK. I have some patches sitting in my tree too that I'm working on. With
> > that I don't need to know about maximum number of allowed segments and
> > can send along any number of segment. I will rework them and post them.
> > fwiw, I will also implement caps API incase like Lars did populating the
> > other fields though these will not be unused.
> > 
> > For segment size, at this time I don't know any driver that uses it
> > other than davinci-pcm. For this reason the calculations can be done as
> > Lars suggested (for minimum of maximum). Do you know in advance if
> > you're going to amend to drop segment size if we go with what Russell
> > suggested, or are you going to leave the seg-size in the caps API anyway.
> I am just back and havent really done my work on this. Let me check and as I
> said if my understanding is right I would be inclined to remove these fields...
Okay so the max sg_len should be done by setting the device_dma_parameters.

See the example in MXS DMA and MMC drivers

Now for second parameter why do you need that to be passed, I thought in edma the
clients needs this value somehow to program the channel. It would be good that
if we can delink from this and let edma derive. Also there should be no such
thing as max_sg, the driver should be able to perform any size of sg_list.
Internally it can be breaking the dma into multiple trasnactions.

~Vinod
-- 


From vincent.guittot at linaro.org  Mon Jul 29 06:28:24 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Mon, 29 Jul 2013 12:28:24 +0200
Subject: [RFC][PATCH 1/2] ARM64: add cpu topology definition
In-Reply-To: <51F640AB.2050709@arm.com>
References: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>
 <CAKfTPtBpo41LJ3V8TB8YwudwqpURuA2u_Lvu4KYVK=qSs+gFuQ@mail.gmail.com>
 <51F640AB.2050709@arm.com>
Message-ID: <CAKfTPtDBJUy6smFuACjQNVywQUiQs_iPMFs9T6uCwJOX5f7e8w@mail.gmail.com>

On 29 July 2013 12:15, Sudeep KarkadaNagesha
<Sudeep.KarkadaNagesha at arm.com> wrote:
> On 29/07/13 10:46, Vincent Guittot wrote:
>> On 27 July 2013 12:42, Hanjun Guo <hanjun.guo at linaro.org> wrote:
>>> Power aware scheduling needs the cpu topology information to improve the
>>> cpu scheduler decision making.
>>
>> It's not only power aware scheduling. The scheduler already uses
>> topology and cache sharing when  CONFIG_SCHED_MC and/or
>> CONFIG_SCHED_SMT are enable. So you should also add these configs for
>> arm64 so the scheduler can use it
>>
> Just for my knowledge, I thought power aware using SCHED_MC/SMT was
> removed. I see commit 8e7fbcbc22c12414bcc9dfdd683637f58fb32759 "sched:
> Remove stale power aware scheduling remnants and dysfunctional knobs"
> I may be missing something here.

It's a common mistake to mixed SCHED_MC and powersaving balance with
SCHED_MC. Only the powersaving policy has been removed but the
SCHED_MC and SCHED_SMT are always in the scheduler and gives perf
improvement on arm 32bits

>
> Regards,
> Sudeep
>


From hdoyu at nvidia.com  Mon Jul 29 06:31:55 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Mon, 29 Jul 2013 12:31:55 +0200
Subject: [PATCH v2 21/22] iommu/tegra: smmu: Support Multiple ASID
In-Reply-To: <51E8535A.30605@wwwdotorg.org>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com><1373021097-32420-22-git-send-email-hdoyu@nvidia.com><51E8535A.30605@wwwdotorg.org>
Message-ID: <20130729.133155.1836775489422797370.hdoyu@nvidia.com>

Stephen Warren <swarren at wwwdotorg.org> wrote @ Thu, 18 Jul 2013 22:43:06 +0200:

> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> > Support Multiple Address Space(AS). Tegra SMMU can have multiple
> > ASes. We reserve 2 of them for static assignment, AS[0] for system
> > default, AS[1] for AHB clusters as protected domain from others, where
> > there are many traditional pheripheral devices like USB, SD/MMC. They
> > should be isolated from some smart devices like host1x for system
> > robustness. Even if smart devices behaves wrongly, the traditional
> > devices(SD/MMC, USB) wouldn't be affected, and the system could
> > continue most likely.
> 
> > diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> 
> >  static int smmu_iommu_add_device(struct device *dev)
> >  {
> >  	int err;
> > -	struct dma_iommu_mapping *map = smmu_handle->map[SYSTEM_DEFAULT];
> > +	u64 swgroup;
> > +	struct dma_iommu_mapping *map = NULL;
> > +
> > +	swgroup = smmu_of_get_memory_client(dev);
> > +	switch (swgroup) {
> > +	case TEGRA_SWGROUP_BIT(PPCS):
> > +		map = smmu_handle->map[SYSTEM_PROTECTED];
> > +		break;
> > +	default:
> > +		map = smmu_handle->map[SYSTEM_DEFAULT];
> 
> I already mentioned this, but just for completeness: What is
> smmu->num_as <= SYSTEM_DEFAULT?

I think that this belongs to the system operation policy. Which H/W
should be configured to which Address Space(AS). This put all AHB
clients(PPCS) into AS[1](SYSTEM_PROTECTED), and the rest into
AS[0](SYSTEM_DEFAULT). AHB clients are mainly traditional H/Ws like
USB and SD/MMC so that they should be kept separated from the smart
IOMMU clients like host1x.

Is there any place to configure this kind of board specific policy
rather than here?


From vincent.guittot at linaro.org  Mon Jul 29 06:39:16 2013
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Mon, 29 Jul 2013 12:39:16 +0200
Subject: [RFC][PATCH 1/2] ARM64: add cpu topology definition
In-Reply-To: <20130729095400.GB32383@mudshark.cambridge.arm.com>
References: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>
 <CAKfTPtBpo41LJ3V8TB8YwudwqpURuA2u_Lvu4KYVK=qSs+gFuQ@mail.gmail.com>
 <20130729095400.GB32383@mudshark.cambridge.arm.com>
Message-ID: <CAKfTPtANkeZkDHP_b2OV=tRxQ+q-J_SVMzrMYifgEhiJy=GijA@mail.gmail.com>

On 29 July 2013 11:54, Will Deacon <will.deacon at arm.com> wrote:
> On Mon, Jul 29, 2013 at 10:46:06AM +0100, Vincent Guittot wrote:
>> On 27 July 2013 12:42, Hanjun Guo <hanjun.guo at linaro.org> wrote:
>> > Power aware scheduling needs the cpu topology information to improve the
>> > cpu scheduler decision making.
>>
>> It's not only power aware scheduling. The scheduler already uses
>> topology and cache sharing when  CONFIG_SCHED_MC and/or
>> CONFIG_SCHED_SMT are enable. So you should also add these configs for
>> arm64 so the scheduler can use it
>
> ... except that the architecture doesn't define what the AFF fields in MPIDR
> really represent. Using them to make key scheduling decisions relating to

Do you mean that it's not define for arm64 ARM? AFAIK, there are good
explanation in the arm32 ARM and it's currently used with SCHED_MC and
SCHED_SMT

> cache proximity seems pretty risky to me, especially given the track record
> we've seen already on AArch32 silicon. It's a convenient register if it
> contains the data we want it to contain, but we need to force ourselves to
> come to terms with reality here and simply use it as an identifier for a
> CPU.
>
> Can't we just use the device-tree to represent this topological data for
> arm64? Lorenzo has been working on bindings in this area.

I agree that we should probably use DT if we can't rely in MPIDR for arm64

Vincent
>
> Will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


From jonas.jensen at gmail.com  Mon Jul 29 06:49:34 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Mon, 29 Jul 2013 12:49:34 +0200
Subject: [PATCH v3] mmc: sdhci-moxart: Add MOXA ART SDHCI driver
In-Reply-To: <1374065502-27110-1-git-send-email-jonas.jensen@gmail.com>
References: <1374065502-27110-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1375094974-7536-1-git-send-email-jonas.jensen@gmail.com>

Add SDHCI driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v2:
    
    1. #include <linux/bitops.h> because BIT() comes from there
    2. reinsert dev_set_drvdata() in moxart_remove
    3. remove MODULE_VERSION()
    
    device tree bindings document:
    4. describe compatible variable "Must be" instead of "Should be".
    5. change description so it's from the point of view of the device
    
    Applies to next-20130729

 .../devicetree/bindings/mmc/moxa,moxart-mmc.txt    |  17 +
 drivers/mmc/host/Kconfig                           |   9 +
 drivers/mmc/host/Makefile                          |   1 +
 drivers/mmc/host/sdhci-moxart.c                    | 782 +++++++++++++++++++++
 drivers/mmc/host/sdhci-moxart.h                    | 155 ++++
 5 files changed, 964 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt
 create mode 100644 drivers/mmc/host/sdhci-moxart.c
 create mode 100644 drivers/mmc/host/sdhci-moxart.h

diff --git a/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt b/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt
new file mode 100644
index 0000000..67782ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt
@@ -0,0 +1,17 @@
+MOXA ART SD Host Controller Interface
+
+Required properties:
+
+- compatible : Must be "moxa,moxart-mmc"
+- reg : Should contain registers location and length
+- interrupts : Should contain the interrupt number
+- clocks : Should contain phandle for the clock feeding the SDHCI controller
+
+Example:
+
+	mmc: mmc at 98e00000 {
+		compatible = "moxa,moxart-mmc";
+		reg = <0x98e00000 0x5C>;
+		interrupts = <5 0>;
+		clocks = <&coreclk>;
+	};
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8a4c066..3c246390 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -271,6 +271,15 @@ config MMC_SDHCI_BCM2835
 
 	  If unsure, say N.
 
+config MMC_SDHCI_MOXART
+	tristate "MOXART SD Host Controller Interface support"
+	depends on ARCH_MOXART && MMC
+	help
+	  This selects the MOXART SD Host Controller Interface.
+	  MOXA provides one multi-functional card reader which can
+	  be found on some embedded hardware such as UC-7112-LX.
+	  If you have a controller with this interface, say Y here.
+
 config MMC_OMAP
 	tristate "TI OMAP Multimedia Card Interface support"
 	depends on ARCH_OMAP
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index d422e21..c91317f 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_MMC_SDHCI_OF_ESDHC)	+= sdhci-of-esdhc.o
 obj-$(CONFIG_MMC_SDHCI_OF_HLWD)		+= sdhci-of-hlwd.o
 obj-$(CONFIG_MMC_SDHCI_BCM_KONA)	+= sdhci-bcm-kona.o
 obj-$(CONFIG_MMC_SDHCI_BCM2835)		+= sdhci-bcm2835.o
+obj-$(CONFIG_MMC_SDHCI_MOXART)		+= sdhci-moxart.o
 
 ifeq ($(CONFIG_CB710_DEBUG),y)
 	CFLAGS-cb710-mmc	+= -DDEBUG
diff --git a/drivers/mmc/host/sdhci-moxart.c b/drivers/mmc/host/sdhci-moxart.c
new file mode 100644
index 0000000..fa9056c
--- /dev/null
+++ b/drivers/mmc/host/sdhci-moxart.c
@@ -0,0 +1,782 @@
+/*
+ * MOXA ART MMC host driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/blkdev.h>
+#include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
+#include <linux/mmc/host.h>
+#include <linux/mmc/sd.h>
+#include <linux/mmc/mmc.h>
+#include <linux/sched.h>
+#include <linux/io.h>
+#include <linux/gpio.h>
+#include <linux/sizes.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/clk.h>
+#include <linux/bitops.h>
+
+#include <asm/dma.h>
+#include <asm/irq.h>
+
+#include "sdhci-moxart.h"
+
+#define DMA_FIFO_LEN_FORCE		0
+#define APB_DMA_SD_REQ_NO		5
+#define MIN_POWER (MMC_VDD_360 - MSD_SD_POWER_MASK)
+
+static inline void moxart_init_sg(struct moxart_host *host,
+				  struct mmc_data *data)
+{
+	host->cur_sg = data->sg;
+	host->num_sg = data->sg_len;
+	host->remain = host->cur_sg->length;
+
+	if (host->remain > host->size)
+		host->remain = host->size;
+
+	data->error = MMC_ERR_NONE;
+}
+
+static inline int moxart_next_sg(struct moxart_host *host)
+{
+	int remain;
+	struct mmc_data *data = host->mrq->cmd->data;
+
+	host->cur_sg++;
+	host->num_sg--;
+
+	if (host->num_sg > 0) {
+		host->remain = host->cur_sg->length;
+		remain = host->size - data->bytes_xfered;
+		if (remain > 0 && remain < host->remain)
+			host->remain = remain;
+	}
+
+	return host->num_sg;
+}
+
+static void moxart_send_command(struct moxart_host *host,
+	struct mmc_command *cmd)
+{
+	unsigned int status, cmdctrl;
+	int retry = 0;
+
+	dev_dbg(mmc_dev(host->mmc), "%s: cmd->opcode=%d\n",
+		__func__, cmd->opcode);
+
+	cmd->error = MMC_ERR_TIMEOUT;
+
+	writel(MSD_RSP_TIMEOUT | MSD_RSP_CRC_OK |
+	       MSD_RSP_CRC_FAIL | MSD_CMD_SENT, &host->reg->clear);
+	writel(cmd->arg, &host->reg->argument);
+
+	cmdctrl = cmd->opcode & MSD_CMD_IDX_MASK;
+	if (cmdctrl == SD_APP_SET_BUS_WIDTH || cmdctrl == SD_APP_OP_COND ||
+	    cmdctrl == SD_APP_SEND_SCR || cmdctrl == SD_APP_SD_STATUS ||
+	    cmdctrl == SD_APP_SEND_NUM_WR_BLKS)
+		cmdctrl |= MSD_APP_CMD;
+
+	if (cmd->flags & MMC_RSP_136)
+		cmdctrl |= (MSD_LONG_RSP | MSD_NEED_RSP);
+	else
+		cmdctrl |= MSD_NEED_RSP;
+
+	writel(cmdctrl | MSD_CMD_EN, &host->reg->command);
+
+	while (retry++ < MSD_RETRY_COUNT) {
+		udelay(10);
+		status = readl(&host->reg->status);
+		if (status & MSD_CARD_DETECT) {
+			dev_dbg(mmc_dev(host->mmc), "%s: MSD_CARD_DETECT\n",
+				__func__);
+			cmd->error = MMC_ERR_TIMEOUT;
+			break;
+		}
+		if (cmdctrl & MSD_NEED_RSP) {
+			dev_dbg(mmc_dev(host->mmc), "%s: MSD_NEED_RSP\n",
+				__func__);
+			if (status & MSD_RSP_TIMEOUT) {
+				dev_dbg(mmc_dev(host->mmc), "%s: MSD_RSP_TIMEOUT\n",
+					__func__);
+				writel(MSD_RSP_TIMEOUT, &host->reg->clear);
+				cmd->error = MMC_ERR_TIMEOUT;
+				break;
+			}
+			if ((cmd->flags & MMC_RSP_CRC) &&
+				(status & MSD_RSP_CRC_FAIL)) {
+				dev_dbg(mmc_dev(host->mmc), "%s: MSD_RSP_CRC_FAIL\n",
+					__func__);
+				writel(MSD_RSP_CRC_FAIL, &host->reg->clear);
+				cmd->error = MMC_ERR_BADCRC;
+				break;
+			}
+			if (status & MSD_RSP_CRC_OK) {
+				dev_dbg(mmc_dev(host->mmc), "%s: MSD_RSP_CRC_OK\n",
+					__func__);
+				writel(MSD_RSP_CRC_OK, &host->reg->clear);
+
+				if (cmd->flags & MMC_RSP_136) {
+					cmd->resp[3] =
+						readl(&host->reg->response0);
+					cmd->resp[2] =
+						readl(&host->reg->response1);
+					cmd->resp[1] =
+						readl(&host->reg->response2);
+					cmd->resp[0] =
+						readl(&host->reg->response3);
+				} else {
+					cmd->resp[0] =
+						readl(&host->reg->response0);
+				}
+
+				cmd->error = MMC_ERR_NONE;
+				break;
+			}
+		} else {
+			dev_dbg(mmc_dev(host->mmc), "%s: !(cmdctrl & MSD_NEED_RSP)\n",
+				__func__);
+			if (status & MSD_CMD_SENT) {
+				writel(MSD_CMD_SENT, &host->reg->clear);
+				cmd->error = MMC_ERR_NONE;
+				break;
+			}
+		}
+	}
+
+	if (retry >= (MSD_RETRY_COUNT - 1)) {
+		/*
+		 * this seems to happen a lot on or after CMD25
+		 * (MMC_WRITE_MULTIPLE_BLOCK) with more than 4 blocks
+		 * (>4096), possibly because the transfer is too big
+		 * or takes too long to complete.
+		 * when this happens the controller is usually rendered
+		 * unresponsive and can only be recovered with reboot.
+		 */
+		dev_dbg(mmc_dev(host->mmc), "%s: WARNING! no valid status found!\n",
+			__func__);
+	}
+}
+
+static void moxart_dma_complete(void *param)
+{
+	struct moxart_host *host = param;
+
+	dev_dbg(mmc_dev(host->mmc), "%s: host=%p\n", __func__, host);
+	complete(&host->dma_complete);
+}
+
+static void moxart_transfer_dma(struct mmc_data *data, struct moxart_host *host)
+{
+	unsigned int len, direction_dev;
+	struct dma_async_tx_descriptor *desc = NULL;
+
+	if (host->size == data->bytes_xfered)
+		return;
+
+	direction_dev = (data->flags & MMC_DATA_WRITE) ?
+			DMA_MEM_TO_DEV : DMA_DEV_TO_MEM;
+
+	/*
+	 * because dma_map_sg takes both sg and sg_len as arguments
+	 * (and maps the entire list of buffers) data->sg does not
+	 * have to be incremented between calls (as is required
+	 * in moxart_transfer_pio)
+	 */
+	len = dma_map_sg(host->dma_chan_cur->device->dev, data->sg,
+			 data->sg_len, host->dma_direction);
+
+	if (len > 0) {
+		/* host->dma_active = true;*/
+		desc = dmaengine_prep_slave_sg(host->dma_chan_cur, data->sg,
+					       len, direction_dev,
+					       DMA_PREP_INTERRUPT |
+					       DMA_CTRL_ACK);
+	} else {
+		pr_err("%s: dma_map_sg returned zero length\n",
+			__func__);
+	}
+
+	if (desc) {
+		desc->callback = moxart_dma_complete;
+		desc->callback_param = host;
+		dmaengine_submit(desc);
+		dma_async_issue_pending(host->dma_chan_cur);
+	}
+
+	data->bytes_xfered += host->remain;
+}
+
+/* when DMA is available this is used only for SD_APP_SEND_SCR */
+static void moxart_transfer_pio(struct moxart_host *host)
+{
+	unsigned char *buffer;
+	unsigned int wcnt, i;
+	struct mmc_data *data = host->mrq->cmd->data;
+
+	if (host->size == data->bytes_xfered)
+		goto transfer_complete;
+
+	buffer = sg_virt(host->cur_sg);
+	wcnt = host->remain >> 2;
+
+	if (data->flags & MMC_DATA_WRITE) {
+		for (i = 0; i < wcnt; i++, buffer += 4) {
+			writel(*(unsigned int *)buffer,
+			       &host->reg->data_window);
+			udelay(10);
+		}
+	} else {
+		for (i = 0; i < wcnt; i++, buffer += 4) {
+			/* byte order reversed only when reading SCR */
+			if (data->mrq->cmd->opcode == SD_APP_SEND_SCR) {
+				*(unsigned int *)buffer = ioread32be(
+					&host->reg->data_window);
+			} else {
+				*(unsigned int *)buffer =
+					readl(&host->reg->data_window);
+			}
+			udelay(10);
+		}
+	}
+	wcnt <<= 2;
+	host->remain -= wcnt;
+	data->bytes_xfered += wcnt;
+
+	if (host->size != data->bytes_xfered) {
+		moxart_next_sg(host);
+		/*
+		 * used to goto "transfer_start" label here,
+		 * there is no need, this function will be
+		 * called again from interrupt.
+		 *
+		 * compare with DMA where sg increment is
+		 * redundant thanks to dma_map_sg
+		 */
+	} else {
+		complete(&host->pio_complete);
+	}
+
+transfer_complete:
+	dev_dbg(mmc_dev(host->mmc), "%s: host->size=%d host->remain=%u\n",
+		__func__, host->size, host->remain);
+}
+
+static void moxart_prepare_data(struct moxart_host *host)
+{
+	struct mmc_data *data = host->mrq->cmd->data;
+	unsigned int timeout, datactrl;
+	int blksz_bits;
+
+	dev_dbg(mmc_dev(host->mmc), "%s\n", __func__);
+
+	if (!data)
+		return;
+
+	host->size = data->blocks * data->blksz;
+	blksz_bits = ffs(data->blksz) - 1;
+	BUG_ON(1 << blksz_bits != data->blksz);
+
+	moxart_init_sg(host, data);
+
+	timeout = (host->mmc->f_max / 1000) * (data->timeout_ns / 1000);
+	timeout *= 2;
+
+	datactrl = (blksz_bits & MSD_BLK_SIZE_MASK) | MSD_DATA_EN;
+
+	if (data->flags & MMC_DATA_WRITE)
+		datactrl |= MSD_DATA_WRITE;
+
+	if (((host->size > MSD_FIFO_LENB) || DMA_FIFO_LEN_FORCE)
+	    && host->have_dma) {
+		datactrl |= MSD_DMA_EN;
+	}
+
+	dev_dbg(mmc_dev(host->mmc), "%s: blocks=%d blksz=%d datactrl=0x%08x\n",
+		__func__, data->blocks,	data->blksz, datactrl);
+	dev_dbg(mmc_dev(host->mmc), "%s: timeout=%u timeout_ns=%u\n",
+		__func__, timeout, data->timeout_ns);
+
+	writel(timeout, &host->reg->data_timer);
+	writel(host->size, &host->reg->data_length);
+	writel(datactrl, &host->reg->data_control);
+}
+
+static void moxart_transfer_check(struct mmc_data *data,
+				  struct moxart_host *host)
+{
+	unsigned int status, count = 0;
+
+	dev_dbg(mmc_dev(host->mmc), "%s\n", __func__);
+
+	while (1) {
+		udelay(10);
+		status = readl(&host->reg->status);
+		if (status & (MSD_DATA_CRC_OK | MSD_DATA_CRC_FAIL
+			| MSD_DATA_END)	|| count > 10)
+			break;
+		dev_dbg(mmc_dev(host->mmc), "%s: waiting for status=%08x ..\n",
+			__func__, status);
+		count++;
+	}
+	if (status & MSD_DATA_CRC_OK) {
+		dev_dbg(mmc_dev(host->mmc), "%s: MSD_DATA_CRC_OK\n", __func__);
+		writel(MSD_DATA_CRC_OK, &host->reg->clear);
+	}
+	if (status & MSD_DATA_CRC_FAIL) {
+		dev_dbg(mmc_dev(host->mmc), "%s: MSD_DATA_CRC_FAIL\n",
+			__func__);
+		writel(MSD_DATA_CRC_FAIL, &host->reg->clear);
+		data->error = MMC_ERR_TIMEOUT;
+	}
+	if (status & MSD_DATA_END) {
+		dev_dbg(mmc_dev(host->mmc), "%s: MSD_DATA_END\n",
+			__func__);
+		writel(MSD_DATA_END, &host->reg->clear);
+	}
+	if (status & MSD_DATA_TIMEOUT) {
+		dev_dbg(mmc_dev(host->mmc), "%s: MSD_DATA_TIMEOUT\n",
+			__func__);
+		writel(MSD_DATA_TIMEOUT, &host->reg->clear);
+	}
+}
+
+static void moxart_card_change(struct moxart_host *host)
+{
+	int delay;
+	unsigned long flags;
+
+	spin_lock_irqsave(&host->lock, flags);
+
+	if (readl(&host->reg->status) & MSD_CARD_DETECT) {
+		dev_dbg(mmc_dev(host->mmc), "%s: card removed\n", __func__);
+		if (host->have_dma && host->size > MSD_FIFO_LENB) {
+			dev_dbg(mmc_dev(host->mmc), "%s: call dmaengine_terminate_all\n",
+				__func__);
+			dmaengine_terminate_all(host->dma_chan_rx);
+			dmaengine_terminate_all(host->dma_chan_tx);
+		}
+		host->removed = true;
+		delay = 0;
+	} else {
+		dev_dbg(mmc_dev(host->mmc), "%s: card inserted\n", __func__);
+		host->removed = false;
+		delay = 500;
+	}
+
+	/*
+	 * clearing FIFO interrupts here does not stop a follow up
+	 * MSD_FIFO_*RUN after MSD_CARD_CHANGE. instead, check
+	 * host->mrq != NULL in moxart_irq to avoid unnecessary calls
+	 * to moxart_transfer_pio
+	 * if this happens during transfer the mmc_request in
+	 * moxart_request should still be valid
+	 * (which is why host->mrq can be set NULL here)
+	 */
+	host->mrq = NULL;
+	writel(MSD_CARD_CHANGE | MSD_FIFO_ORUN | MSD_FIFO_URUN,
+	       &host->reg->clear);
+	writel(MSD_CARD_CHANGE, &host->reg->interrupt_mask);
+
+	spin_unlock_irqrestore(&host->lock, flags);
+	dev_dbg(mmc_dev(host->mmc), "%s: call mmc_detect_change\n", __func__);
+	mmc_detect_change(host->mmc, msecs_to_jiffies(delay));
+}
+
+static void moxart_request(struct mmc_host *mmc, struct mmc_request *mrq)
+{
+	struct moxart_host *host = mmc_priv(mmc);
+	unsigned long dma_time, pio_time, flags;
+	unsigned int status;
+
+	dev_dbg(mmc_dev(host->mmc), "%s\n", __func__);
+
+	spin_lock_irqsave(&host->lock, flags);
+
+	init_completion(&host->dma_complete);
+	init_completion(&host->pio_complete);
+
+	host->mrq = mrq;
+
+	if (readl(&host->reg->status) & MSD_CARD_DETECT) {
+		mrq->cmd->error = MMC_ERR_TIMEOUT;
+		goto request_done;
+	}
+
+	moxart_prepare_data(host);
+	moxart_send_command(host, host->mrq->cmd);
+
+	if (mrq->cmd->data) {
+		/* only use DMA/PIO (and wait) when there is data */
+		if (((host->size > MSD_FIFO_LENB) || DMA_FIFO_LEN_FORCE)
+			&& host->have_dma) {
+
+			writel(MSD_CARD_CHANGE, &host->reg->interrupt_mask);
+
+			spin_unlock_irqrestore(&host->lock, flags);
+
+			host->dma_direction = (mrq->cmd->data->flags
+					      & MMC_DATA_WRITE) ?
+					      DMA_TO_DEVICE : DMA_FROM_DEVICE;
+			host->dma_chan_cur = (mrq->cmd->data->flags
+					     & MMC_DATA_WRITE) ?
+					     host->dma_chan_tx :
+					     host->dma_chan_rx;
+			moxart_transfer_dma(mrq->cmd->data, host);
+
+			dma_time = wait_for_completion_interruptible_timeout(
+				   &host->dma_complete, host->timeout);
+			dev_dbg(mmc_dev(host->mmc), "%s: dma_time=%lu (DMA wait time)\n",
+				__func__, dma_time);
+
+			dma_unmap_sg(host->dma_chan_cur->device->dev,
+				     mrq->cmd->data->sg, mrq->cmd->data->sg_len,
+				     host->dma_direction);
+
+			spin_lock_irqsave(&host->lock, flags);
+		} else {
+
+			writel(MSD_FIFO_URUN | MSD_FIFO_ORUN | MSD_CARD_CHANGE,
+			       &host->reg->interrupt_mask);
+
+			status = readl(&host->reg->status);
+			dev_dbg(mmc_dev(host->mmc), "%s: status=%08x\n",
+				__func__, status);
+
+			spin_unlock_irqrestore(&host->lock, flags);
+
+			/* PIO transfer started from interrupt */
+			pio_time = wait_for_completion_interruptible_timeout(
+				   &host->pio_complete, host->timeout);
+			dev_dbg(mmc_dev(host->mmc), "%s: pio_time=%lu (PIO wait time)\n",
+				__func__, pio_time);
+
+			spin_lock_irqsave(&host->lock, flags);
+		}
+
+		/* removed during transfer? (interrupts were just enabled..) */
+		if (host->removed) {
+			dev_dbg(mmc_dev(host->mmc), "%s: host removed during transfer!\n",
+				__func__);
+			mrq->cmd->error = MMC_ERR_TIMEOUT;
+		}
+
+		moxart_transfer_check(mrq->cmd->data, host);
+
+		if (mrq->cmd->data->stop)
+			moxart_send_command(host, mrq->cmd->data->stop);
+	}
+
+request_done:
+	spin_unlock_irqrestore(&host->lock, flags);
+	mmc_request_done(host->mmc, mrq);
+}
+
+static irqreturn_t moxart_irq(int irq, void *devid)
+{
+	struct moxart_host *host = (struct moxart_host *)devid;
+	unsigned int status;
+	unsigned long flags;
+
+	status = readl(&host->reg->status);
+
+	dev_dbg(mmc_dev(host->mmc), "%s: host=%p status=%08x\n",
+		__func__, host, status);
+
+	if (status & MSD_CARD_CHANGE) {
+		dev_dbg(mmc_dev(host->mmc), "%s: call moxart_card_change\n",
+			__func__);
+		moxart_card_change(host);
+	}
+	if (status & (MSD_FIFO_ORUN | MSD_FIFO_URUN) && host->mrq) {
+		writel(status & (MSD_FIFO_ORUN | MSD_FIFO_URUN),
+		       &host->reg->clear);
+		dev_dbg(mmc_dev(host->mmc), "%s: call moxart_transfer_pio\n",
+			__func__);
+		spin_lock_irqsave(&host->lock, flags);
+		moxart_transfer_pio(host);
+		spin_unlock_irqrestore(&host->lock, flags);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static void moxart_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
+{
+	struct moxart_host *host = mmc_priv(mmc);
+	unsigned long flags;
+	unsigned short power;
+	int div;
+
+	spin_lock_irqsave(&host->lock, flags);
+	if (ios->clock) {
+		div = (host->sysclk / (host->mmc->f_max * 2)) - 1;
+
+		if (div > MSD_CLK_DIV_MASK)
+			div = MSD_CLK_DIV_MASK;
+		else if (div < 0)
+			div = 0;
+
+		div |= MSD_CLK_SD;
+		writel(div, &host->reg->clock_control);
+	} else if (!(readl(&host->reg->clock_control) & MSD_CLK_DIS)) {
+		writel(readl(&host->reg->clock_control) | MSD_CLK_DIS,
+		       &host->reg->clock_control);
+	}
+
+	if (ios->power_mode == MMC_POWER_OFF) {
+		writel(readl(&host->reg->power_control) & ~MSD_SD_POWER_ON,
+		       &host->reg->power_control);
+	} else {
+		if (ios->vdd < MIN_POWER)
+			power = 0;
+		else
+			power = ios->vdd - MIN_POWER;
+
+		writel(MSD_SD_POWER_ON | (unsigned int) power,
+		       &host->reg->power_control);
+	}
+
+	if (ios->bus_width == MMC_BUS_WIDTH_1)
+		writel(MSD_SINGLE_BUS, &host->reg->bus_width);
+	else
+		writel(MSD_WIDE_BUS, &host->reg->bus_width);
+
+	spin_unlock_irqrestore(&host->lock, flags);
+}
+
+
+static int moxart_get_ro(struct mmc_host *mmc)
+{
+	int ret;
+	struct moxart_host *host = mmc_priv(mmc);
+
+	(readl(&host->reg->status) & MSD_WRITE_PROT) ? (ret = 1) : (ret = 0);
+	return ret;
+}
+
+static struct mmc_host_ops moxart_ops = {
+	.request = moxart_request,
+	.set_ios = moxart_set_ios,
+	.get_ro = moxart_get_ro,
+};
+
+static int moxart_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct resource res_mmc;
+	struct mmc_host *mmc;
+	struct moxart_host *host = NULL;
+	void __iomem *reg_mmc;
+	dma_cap_mask_t mask;
+	int ret;
+	struct dma_slave_config cfg;
+	unsigned int irq;
+	struct clk *clk;
+	unsigned int dma_chan_rx_req = 1;
+	unsigned int dma_chan_tx_req = 0;
+
+	mmc = mmc_alloc_host(sizeof(struct moxart_host), dev);
+	if (!mmc) {
+		dev_err(dev, "%s: mmc_alloc_host failed\n", __func__);
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	ret = of_address_to_resource(node, 0, &res_mmc);
+	if (ret) {
+		dev_err(dev, "%s: could not get MMC base resource\n", __func__);
+		goto out;
+	}
+
+	irq = irq_of_parse_and_map(node, 0);
+
+	reg_mmc = devm_ioremap_resource(dev, &res_mmc);
+	if (IS_ERR(reg_mmc)) {
+		dev_err(dev, "%s: devm_ioremap_resource res_mmc failed\n",
+			__func__);
+		return PTR_ERR(reg_mmc);
+	}
+
+	mmc->ops = &moxart_ops;
+
+	/*
+	 * hardware does not support MMC_CAP_SD_HIGHSPEED
+	 * CMD6 will timeout and make things not work
+	 */
+	mmc->caps = MMC_CAP_4_BIT_DATA;
+
+	mmc->f_min = 400000;
+	mmc->f_max = 25000000;
+	mmc->ocr_avail = 0xffff00;	/* support 2.0v - 3.6v power */
+	mmc->max_segs = 32;
+	mmc->max_blk_size = 512;
+	mmc->max_blk_count = mmc->max_req_size / mmc->max_blk_size;
+	mmc->max_seg_size = mmc->max_req_size;
+
+	host = mmc_priv(mmc);
+	host->mmc = mmc;
+	host->reg = (struct moxart_reg *)reg_mmc;
+	host->reg_phys = res_mmc.start;
+	host->timeout = msecs_to_jiffies(1000);
+
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk)) {
+		dev_err(dev, "%s: of_clk_get failed\n", __func__);
+		return PTR_ERR(clk);
+	}
+	host->sysclk = clk_get_rate(clk);
+
+	spin_lock_init(&host->lock);
+
+	/* disable all interrupt */
+	writel(0, &host->reg->interrupt_mask);
+
+	/* reset chip */
+	writel(MSD_SDC_RST, &host->reg->command);
+
+	/* wait for reset finished */
+	while (readl(&host->reg->command) & MSD_SDC_RST)
+		udelay(10);
+
+	host->dma_chan_tx = dma_request_channel(mask, moxart_filter_fn,
+						(void *)&dma_chan_tx_req);
+	host->dma_chan_rx = dma_request_channel(mask, moxart_filter_fn,
+						(void *)&dma_chan_rx_req);
+	dev_dbg(dev, "%s: using 2 DMA channels rx=%p tx=%p\n",
+		__func__, host->dma_chan_rx, host->dma_chan_tx);
+
+	if (!host->dma_chan_rx || !host->dma_chan_tx) {
+		host->have_dma = false;
+		mmc->max_blk_count = 1;
+	} else {
+		cfg.slave_id = APB_DMA_SD_REQ_NO;
+		cfg.direction = DMA_MEM_TO_DEV;
+		cfg.src_addr = 0;
+		cfg.dst_addr = (unsigned int)host->reg_phys + MSD_DATA_WIN_REG;
+		cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+		dmaengine_slave_config(host->dma_chan_tx, &cfg);
+
+		cfg.slave_id = APB_DMA_SD_REQ_NO;
+		cfg.direction = DMA_DEV_TO_MEM;
+		cfg.src_addr = (unsigned int)host->reg_phys + MSD_DATA_WIN_REG;
+		cfg.dst_addr = 0;
+		cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+		dmaengine_slave_config(host->dma_chan_rx, &cfg);
+
+		host->have_dma = true;
+
+		/*
+		 * there seems to be a max size on transfers so
+		 * set max_blk_count low for both DMA and PIO
+		 *
+		 * sending large chunks result either in timeout
+		 * or render the MMC controller unresponsive
+		 * (status register 0 on consecutive read retries,
+		 * also see comments in moxart_send_command)
+		 *
+		 * obviously, DMA is quicker and can handle
+		 * larger chunks but setting it higher than 16
+		 * can still bug the controller
+		 */
+		mmc->max_blk_count = 16;
+	}
+
+	devm_request_irq(dev, irq, moxart_irq, 0, "moxart-mmc", host);
+
+	if (ret)
+		goto out;
+
+	dev_set_drvdata(dev, mmc);
+	mmc_add_host(mmc);
+
+	dev_dbg(dev, "%s: IRQ=%d\n", __func__, irq);
+
+	return 0;
+
+out:
+	if (mmc)
+		mmc_free_host(mmc);
+	return ret;
+}
+
+static void moxart_release_dma(struct moxart_host *host)
+{
+	if (host->dma_chan_tx) {
+		struct dma_chan *chan = host->dma_chan_tx;
+		host->dma_chan_tx = NULL;
+		dma_release_channel(chan);
+	}
+	if (host->dma_chan_rx) {
+		struct dma_chan *chan = host->dma_chan_rx;
+		host->dma_chan_rx = NULL;
+		dma_release_channel(chan);
+	}
+}
+
+static int moxart_remove(struct platform_device *pdev)
+{
+	struct mmc_host *mmc = dev_get_drvdata(&pdev->dev);
+	struct moxart_host *host = mmc_priv(mmc);
+
+	dev_set_drvdata(&pdev->dev, NULL);
+
+	if (mmc) {
+		moxart_release_dma(host);
+		mmc_remove_host(mmc);
+		mmc_free_host(mmc);
+
+		writel(0, &host->reg->interrupt_mask);
+		writel(0, &host->reg->power_control);
+		writel(readl(&host->reg->clock_control) | MSD_CLK_DIS,
+		       &host->reg->clock_control);
+	}
+
+	kfree(host);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_mmc_match[] = {
+	{ .compatible = "moxa,moxart-mmc" },
+	{ }
+};
+
+static struct platform_driver moxart_mmc_driver = {
+	.probe      = moxart_probe,
+	.remove     = moxart_remove,
+	.driver     = {
+		.name		= "sdhci-moxart",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_mmc_match,
+	},
+};
+module_platform_driver(moxart_mmc_driver);
+
+MODULE_ALIAS("platform:sdhci-moxart");
+MODULE_DESCRIPTION("MOXART SDHCI driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
diff --git a/drivers/mmc/host/sdhci-moxart.h b/drivers/mmc/host/sdhci-moxart.h
new file mode 100644
index 0000000..7269d40
--- /dev/null
+++ b/drivers/mmc/host/sdhci-moxart.h
@@ -0,0 +1,155 @@
+/*
+ * MOXA ART MMC host driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _SDHCI_MOXART_H
+#define _SDHCI_MOXART_H
+
+extern bool moxart_filter_fn(struct dma_chan *chan, void *param);
+
+#define MSD_CMD_REG		0
+#define MSD_ARG_REG		4
+#define MSD_RESP0_REG		8
+#define MSD_RESP1_REG		0x0c
+#define MSD_RESP2_REG		0x10
+#define MSD_RESP3_REG		0x14
+#define MSD_RESP_CMD_REG	0x18
+#define MSD_DATA_CTRL_REG	0x1c
+#define MSD_DATA_TIMER_REG	0x20
+#define MSD_DATA_LEN_REG	0x24
+#define MSD_STATUS_REG		0x28
+#define MSD_CLEAR_REG		0x2c
+#define MSD_INT_MASK_REG	0x30
+#define MSD_POWER_CTRL_REG	0x34
+#define MSD_CLOCK_CTRL_REG	0x38
+#define MSD_BUS_WIDTH_REG	0x3c
+#define MSD_DATA_WIN_REG	0x40
+#define MSD_FEATURE_REG		0x44
+#define MSD_REVISION_REG	0x48
+
+#define MMC_RSP_SHORT		1
+#define MMC_RSP_LONG		2
+#define MMC_RSP_MASK		3
+#define MMC_ERR_NONE		0
+#define MMC_ERR_TIMEOUT		1
+#define MMC_MODE_MMC		0
+#define MMC_MODE_SD		1
+#define MMC_ERR_BADCRC		2
+#define MMC_VDD_360		23
+
+#define MSD_RETRY_COUNT		10
+
+struct moxart_reg {
+
+#define MSD_SDC_RST		BIT(10)
+#define MSD_CMD_EN		BIT(9)
+#define MSD_APP_CMD		BIT(8)
+#define MSD_LONG_RSP		BIT(7)
+#define MSD_NEED_RSP		BIT(6)
+#define MSD_CMD_IDX_MASK	0x3f
+	unsigned int	command;
+
+	unsigned int	argument;
+	unsigned int	response0;
+	unsigned int	response1;
+	unsigned int	response2;
+	unsigned int	response3;
+
+#define MSD_RSP_CMD_APP		BIT(6)
+#define MSD_RSP_CMD_IDX_MASK	0x3f
+	unsigned int	response_command;
+
+#define MSD_DATA_EN		BIT(6)
+#define MSD_DMA_EN		BIT(5)
+#define MSD_DATA_WRITE		BIT(4)
+#define MSD_BLK_SIZE_MASK	0x0f
+	unsigned int	data_control;
+
+	unsigned int	data_timer;
+
+#define MSD_DATA_LEN_MASK	0xffffff
+	unsigned int	data_length;
+
+#define MSD_WRITE_PROT		BIT(12)
+#define MSD_CARD_DETECT		BIT(11)
+/* 1-10 below can be sent to interrupt or clear register */
+#define MSD_CARD_CHANGE		BIT(10)
+#define MSD_FIFO_ORUN		BIT(9)
+#define MSD_FIFO_URUN		BIT(8)
+#define MSD_DATA_END		BIT(7)
+#define MSD_CMD_SENT		BIT(6)
+#define MSD_DATA_CRC_OK		BIT(5)
+#define MSD_RSP_CRC_OK		BIT(4)
+#define MSD_DATA_TIMEOUT	BIT(3)
+#define MSD_RSP_TIMEOUT		BIT(2)
+#define MSD_DATA_CRC_FAIL	BIT(1)
+#define MSD_RSP_CRC_FAIL	BIT(0)
+	unsigned int	status;
+
+	unsigned int	clear;
+	unsigned int	interrupt_mask;
+
+#define MSD_SD_POWER_ON		BIT(4)
+#define MSD_SD_POWER_MASK	0x0f
+	unsigned int	power_control;
+
+#define MSD_CLK_DIS		BIT(8)
+#define MSD_CLK_SD		BIT(7)
+#define MSD_CLK_DIV_MASK	0x7f
+	unsigned int	clock_control;
+
+#define MSD_WIDE_BUS_SUPPORT	BIT(3)
+#define MSD_WIDE_BUS		BIT(2)	/* bus width is 4 bytes */
+#define MSD_SINGLE_BUS		BIT(0)	/* bus width is 1 byte */
+	unsigned int	bus_width;
+
+	unsigned int	data_window;
+
+#define MSD_CPRM_FUNCTION	BIT(8)
+	unsigned int	feature;
+
+	unsigned int	revision;
+};
+
+struct moxart_host {
+	spinlock_t		lock;
+	struct moxart_reg	*reg;
+	phys_addr_t		reg_phys;
+
+	struct dma_chan		*dma_chan_rx;
+	struct dma_chan		*dma_chan_tx;
+	struct dma_chan		*dma_chan_cur;
+	unsigned int		dma_direction;
+	bool			have_dma;
+	struct completion	dma_complete;
+	struct completion	pio_complete;
+
+	struct mmc_host		*mmc;
+	struct mmc_request	*mrq;
+
+	struct scatterlist	*cur_sg;
+	unsigned int		num_sg;
+	unsigned int		remain;
+	int			size;
+
+	unsigned int		wait_for;
+	unsigned int		timeout;
+	long			sysclk;
+	bool			removed;
+};
+
+#define MSD_FIFO_LENW	4	/* 4 words, total 4 * 4 = 16 bytes */
+#define MSD_FIFO_LENB	16	/* 16 bytes */
+
+#endif	/* _SDHCI_MOXART_H */
-- 
1.8.2.1



From hdoyu at nvidia.com  Mon Jul 29 06:53:36 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Mon, 29 Jul 2013 12:53:36 +0200
Subject: [PATCH v2 03/22] ARM: tegra: Create a DT header defining
 swgroups ID
In-Reply-To: <51E5D220.1070708@wwwdotorg.org>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com><1373021097-32420-4-git-send-email-hdoyu@nvidia.com><51E5D220.1070708@wwwdotorg.org>
Message-ID: <20130729.135336.943359637886118972.hdoyu@nvidia.com>

Stephen Warren <swarren at wwwdotorg.org> wrote @ Wed, 17 Jul 2013 01:07:12 +0200:

> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> > Create a header file to define the swgroup IDs used by the IOMMU(SMMU)
> > binding. "swgroup" is a group of H/W clients in Tegra SoC from S/W POV.
> > 
> > This will allow the same header to be used by both device tree files,
> > and drivers implementing this binding, which guarantees that the two
> > stay in sync. This also makes device trees more readable by using names
> > instead of magic numbers.
> 
> Why does the driver need these constants; shouldn't it simply support
> 0..n SW group IDs that all work the same way? Or, is there some reason
> for it to know the identities?
> 
> > diff --git a/include/dt-bindings/memory/tegra-swgroup.h b/include/dt-bindings/memory/tegra-swgroup.h
> 
> s/memory/iommu/?

This info would be used in PMC code as well, which H/W belongs to
which swgroup. So I use the term "memory(-client)" instead of "iommu".

> s/tegra-swgroup.h/tegra-smmu.h/?

Is "tegra-memory-clients.h" preferable, then?

> > +#define TEGRA_SWGROUP_AFI 0
> 
> Should this file document which values are valid for which SoCs? Should
> there be separate files for each SoC; I don't know if it's guaranteed
> that IDs won't be re-assigned between different SoCs.

I've checked all SoC which I can refer. Those IDs are calculated from
the register offset. But I haven't got any explicit guarantee from H/W
designers yet.

> > +#define TEGRA_SWGROUP_BIT(x)	(1ULL << TEGRA_SWGROUP_##x)
> > +
> > +#define TEGRA30_SWGROUP_ALL	<0x00000000 0x000779ff>
> > +#define TEGRA114_SWGROUP_ALL	<0x00000000 0x01b659fe>
> 
> Are those 3 values needed by DT files, or just the driver?

Only from DT.


From jonathan.austin at arm.com  Mon Jul 29 07:01:02 2013
From: jonathan.austin at arm.com (Jonathan Austin)
Date: Mon, 29 Jul 2013 12:01:02 +0100
Subject: [PATCH 2/2] clk: fixup argument order when setting VCO parameters
In-Reply-To: <20130725174416.7598.73819@quantum>
References: <1374594138-17080-1-git-send-email-jonathan.austin@arm.com>
 <1374594138-17080-3-git-send-email-jonathan.austin@arm.com>
 <CACRpkdbEiNPG0b89zXKpvNgXtAbsKeV9A9ibgEJCBgNa6vQvCw@mail.gmail.com>
 <51F0F035.8010705@arm.com> <20130725174416.7598.73819@quantum>
Message-ID: <51F64B6E.4070300@arm.com>

On 25/07/13 18:44, Mike Turquette wrote:
> Quoting Jonathan Austin (2013-07-25 02:30:29)
>> On 24/07/13 20:32, Linus Walleij wrote:
>>> On Tue, Jul 23, 2013 at 5:42 PM, Jonathan Austin
>>> <jonathan.austin at arm.com> wrote:
>>>
>>>> The order of arguments in the call to vco_set() for the ICST clocks appears to
>>>> have been switched in error, which results in the VCO not being initialised
>>>> correctly. This in turn stops the integrated LCD on things like Integrator/CP
>>>> from working correctly.
>>>>
>>>> This patch fixes the order and restores the expected functionality.
>>>>
>>>> Cc: Linus Walleij <linus.walleij at linaro.org>
>>>> Cc: Mike Turquette <mturquette at linaro.org>
>>>> Signed-off-by: Jonathan Austin <jonathan.austin at arm.com>
>>>
>>> Good catch! Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
>>> You should probably mark this for stable as well.
>>>
>>
>> Mike, will you add Cc: stable when you take the fix or shall I resubmit
>> the patch somehow else?
>
> I'll add it.
>

Thanks very much.

Linus or Mike: Should I put 1/2 in this series in to Russell's tree, or 
should that go in elsewise?

Jonny




From hdoyu at nvidia.com  Mon Jul 29 07:06:46 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Mon, 29 Jul 2013 13:06:46 +0200
Subject: [PATCH v2 05/22] ARM: dt: tegra30: iommu: Add
 "nvidia,memory-client"
In-Reply-To: <51E5D3D9.2090608@wwwdotorg.org>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com><1373021097-32420-6-git-send-email-hdoyu@nvidia.com><51E5D3D9.2090608@wwwdotorg.org>
Message-ID: <20130729.140646.649065361266278007.hdoyu@nvidia.com>

Stephen Warren <swarren at wwwdotorg.org> wrote @ Wed, 17 Jul 2013 01:14:33 +0200:

> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> > Add "nvidia,memory-client" to identify which swgroup ID a device
> > belongs to.
> 
> This property also isn't in the documentation.
> 
> Again, if client devices are required to have this new property, the DT
> isn't backwards-compatible; fail:-(

If there's no this property, just falling back to use the system
default address space. I think that this won't break the
compatibility basically. Only problem may be the inconsistency of
setting this property among the HWs in the same group. If one of them
is set in one AS, but not for the other, then the other H/W won't
work. If we really want to have this kind of constraint implmeneted in
DT, some kind of bus model is needed.


From linux at roeck-us.net  Mon Jul 29 07:05:52 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 29 Jul 2013 04:05:52 -0700
Subject: [PATCH v5] watchdog: Add MOXA ART watchdog driver
In-Reply-To: <1375093215-7136-1-git-send-email-jonas.jensen@gmail.com>
References: <1374229402-20432-1-git-send-email-jonas.jensen@gmail.com>
 <1375093215-7136-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <51F64C90.4080400@roeck-us.net>

On 07/29/2013 03:20 AM, Jonas Jensen wrote:
> Add watchdog driver for MOXA ART SoCs.
>
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
> ---
>
> Notes:
>      Changes since v4:
>
>      1. #include <linux/err.h> because IS_ERR comes from there
>      2. #include <linux/kernel.h> because UINT_MAX comes from there
>      3. #include <linux/moduleparam.h> because module_param() comes from there
>
>      device tree bindings document:
>      4. describe compatible variable "Must be" instead of "Should be".
>      5. change description so it's from the point of view of the device
>
>      Applies to next-20130729
>
>   .../bindings/watchdog/moxa,moxart-watchdog.txt     |  15 ++
>   drivers/watchdog/Kconfig                           |  10 ++
>   drivers/watchdog/Makefile                          |   1 +
>   drivers/watchdog/moxart_wdt.c                      | 169 +++++++++++++++++++++
>   4 files changed, 195 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
>   create mode 100644 drivers/watchdog/moxart_wdt.c
>
> diff --git a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
> new file mode 100644
> index 0000000..1169857
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
> @@ -0,0 +1,15 @@
> +MOXA ART Watchdog timer
> +
> +Required properties:
> +
> +- compatible : Must be "moxa,moxart-watchdog"
> +- reg : Should contain registers location and length
> +- clocks : Should contain phandle for the clock that drives the counter
> +
> +Example:
> +
> +	watchdog: watchdog at 98500000 {
> +		compatible = "moxa,moxart-watchdog";
> +		reg = <0x98500000 0x10>;
> +		clocks = <&coreclk>;
> +	};
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 362085d..6883aab 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -382,6 +382,16 @@ config RETU_WATCHDOG
>   	  To compile this driver as a module, choose M here: the
>   	  module will be called retu_wdt.
>
> +config MOXART_WDT
> +	tristate "MOXART watchdog"
> +	depends on ARCH_MOXART
> +	help
> +	  Say Y here to include Watchdog timer support for the watchdog
> +	  existing on the MOXA ART SoC series platforms.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called moxart_wdt.
> +
>   # AVR32 Architecture
>
>   config AT32AP700X_WDT
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 2f26a0b..7cab53a 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -54,6 +54,7 @@ obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
>   obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
>   obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
>   obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
> +obj-$(CONFIG_MOXART_WDT) += moxart_wdt.o
>
>   # AVR32 Architecture
>   obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
> new file mode 100644
> index 0000000..d79dc9c
> --- /dev/null
> +++ b/drivers/watchdog/moxart_wdt.c
> @@ -0,0 +1,169 @@
> +/*
> + * MOXA ART SoCs watchdog driver.
> + *
> + * Copyright (C) 2013 Jonas Jensen
> + *
> + * Jonas Jensen <jonas.jensen at gmail.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/err.h>
> +#include <linux/kernel.h>
> +#include <linux/platform_device.h>
> +#include <linux/watchdog.h>
> +#include <linux/moduleparam.h>
> +
> +#define REG_COUNT			0x4
> +#define REG_MODE			0x8
> +#define REG_ENABLE			0xC
> +
> +struct moxart_wdt_dev {
> +	struct watchdog_device dev;
> +	void __iomem *base;
> +	unsigned int clock_frequency;
> +};
> +
> +static int heartbeat;
> +
> +static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
> +
> +	writel(0, moxart_wdt->base + REG_ENABLE);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_start(struct watchdog_device *wdt_dev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
> +
> +	writel(moxart_wdt->clock_frequency * moxart_wdt->dev.timeout,
> +	       moxart_wdt->base + REG_COUNT);
> +	writel(0x5ab9, moxart_wdt->base + REG_MODE);
> +	writel(0x03, moxart_wdt->base + REG_ENABLE);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_set_timeout(struct watchdog_device *wdt_dev,
> +				  unsigned int timeout)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
> +
> +	dev_dbg(wdt_dev->dev, "%s: timeout=%u\n", __func__, timeout);
> +
> +	moxart_wdt->dev.timeout = timeout;
> +
Stumbled over this one. Unless I am missing something, &moxart_wdt->dev
and dev are the same, so
	dev->timeout = timeout;
would accomplish the same.

Guenter

> +	return 0;
> +}
> +
> +static const struct watchdog_info moxart_wdt_info = {
> +	.identity       = "moxart-wdt",
> +	.options        = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
> +			  WDIOF_MAGICCLOSE,
> +};
> +
> +static const struct watchdog_ops moxart_wdt_ops = {
> +	.owner          = THIS_MODULE,
> +	.start          = moxart_wdt_start,
> +	.stop           = moxart_wdt_stop,
> +	.set_timeout    = moxart_wdt_set_timeout,
> +};
> +
> +static int moxart_wdt_probe(struct platform_device *pdev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt;
> +	struct device *dev = &pdev->dev;
> +	struct device_node *node = dev->of_node;
> +	struct resource *res;
> +	struct clk *clk;
> +	int err;
> +	unsigned int max_timeout;
> +	bool nowayout = WATCHDOG_NOWAYOUT;
> +
> +	moxart_wdt = devm_kzalloc(&pdev->dev, sizeof(*moxart_wdt), GFP_KERNEL);
> +	if (!moxart_wdt)
> +		return -ENOMEM;
> +
> +	platform_set_drvdata(pdev, moxart_wdt);
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	moxart_wdt->base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(moxart_wdt->base))
> +		return PTR_ERR(moxart_wdt->base);
> +
> +	clk = of_clk_get(node, 0);
> +	if (IS_ERR(clk)) {
> +		pr_err("%s: of_clk_get failed\n", __func__);
> +		return PTR_ERR(clk);
> +	}
> +
> +	moxart_wdt->clock_frequency = clk_get_rate(clk);
> +	if (moxart_wdt->clock_frequency == 0) {
> +		pr_err("%s: incorrect clock frequency\n", __func__);
> +		return -EINVAL;
> +	}
> +
> +	max_timeout = UINT_MAX / moxart_wdt->clock_frequency;
> +
> +	moxart_wdt->dev.info = &moxart_wdt_info;
> +	moxart_wdt->dev.ops = &moxart_wdt_ops;
> +	moxart_wdt->dev.timeout = max_timeout;
> +	moxart_wdt->dev.min_timeout = 1;
> +	moxart_wdt->dev.max_timeout = max_timeout;
> +	moxart_wdt->dev.parent = &pdev->dev;
> +
> +	watchdog_init_timeout(&moxart_wdt->dev, heartbeat, &pdev->dev);
> +	watchdog_set_nowayout(&moxart_wdt->dev, nowayout);
> +
> +	watchdog_set_drvdata(&moxart_wdt->dev, moxart_wdt);
> +
> +	err = watchdog_register_device(&moxart_wdt->dev);
> +	if (unlikely(err))
> +		return err;
> +
> +	dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
> +		moxart_wdt->dev.timeout, nowayout);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_remove(struct platform_device *pdev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
> +
> +	moxart_wdt_stop(&moxart_wdt->dev);
> +	watchdog_unregister_device(&moxart_wdt->dev);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id moxart_watchdog_match[] = {
> +	{ .compatible = "moxa,moxart-watchdog" },
> +	{ },
> +};
> +
> +static struct platform_driver moxart_wdt_driver = {
> +	.probe      = moxart_wdt_probe,
> +	.remove     = moxart_wdt_remove,
> +	.driver     = {
> +		.name		= "moxart-watchdog",
> +		.owner		= THIS_MODULE,
> +		.of_match_table	= moxart_watchdog_match,
> +	},
> +};
> +module_platform_driver(moxart_wdt_driver);
> +
> +module_param(heartbeat, int, 0);
> +MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");
> +
> +MODULE_DESCRIPTION("MOXART watchdog driver");
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
>



From s.hauer at pengutronix.de  Mon Jul 29 07:14:57 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Mon, 29 Jul 2013 13:14:57 +0200
Subject: [PATCH 4/5] fb: Add DCU framebuffer driver for Vybrid VF610
 platform
In-Reply-To: <1373609276-14566-5-git-send-email-b18965@freescale.com>
References: <1373609276-14566-1-git-send-email-b18965@freescale.com>
 <1373609276-14566-5-git-send-email-b18965@freescale.com>
Message-ID: <20130729111457.GB3029@pengutronix.de>

On Fri, Jul 12, 2013 at 02:07:55PM +0800, Alison Wang wrote:
> The Display Controller Unit (DCU) module is a system master that
> fetches graphics stored in internal or external memory and displays
> them on a TFT LCD panel. A wide range of panel sizes is supported
> and the timing of the interface signals is highly configurable.
> Graphics are read directly from memory and then blended in real-time,
> which allows for dynamic content creation with minimal CPU intervention.

Only a review of the code inline.

Maybe the real question is whether we want to introduce another
framebuffer driver at all instead of making it a DRM driver.

> +
> +#define DRIVER_NAME			"fsl-dcu-fb"
> +
> +#define DCU_DCU_MODE			0x0010
> +#define DCU_MODE_BLEND_ITER(x)		(x << 20)

What's the result of DCU_MODE_BLEND_ITER(1 + 1)?

> +static struct fb_videomode dcu_mode_db[] = {
> +	{
> +		.name		= "480x272",
> +		.refresh	= 75,
> +		.xres		= 480,
> +		.yres		= 272,
> +		.pixclock	= 91996,
> +		.left_margin	= 2,
> +		.right_margin	= 2,
> +		.upper_margin	= 1,
> +		.lower_margin	= 1,
> +		.hsync_len	= 41,
> +		.vsync_len	= 2,
> +		.sync		= FB_SYNC_COMP_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
> +		.vmode		= FB_VMODE_NONINTERLACED,
> +	},
> +};

We have ways to describe a panel in dt. Use them.

> +
> +static struct mfb_info mfb_template[] = {
> +	{
> +	.index = LAYER0,
> +	.id = "Layer0",
> +	.alpha = 0xff,
> +	.blend = 0,
> +	.count = 0,
> +	.x_layer_d = 0,
> +	.y_layer_d = 0,
> +	},

Wrong indentation.

> +	default:
> +		printk(KERN_ERR "unsupported color depth: %u\n",
> +			var->bits_per_pixel);

Use dev_* for printing messages in drivers.

> +static int fsl_dcu_check_var(struct fb_var_screeninfo *var,
> +		struct fb_info *info)
> +{
> +	if (var->xres_virtual < var->xres)
> +		var->xres_virtual = var->xres;
> +	if (var->yres_virtual < var->yres)
> +		var->yres_virtual = var->yres;
> +
> +	if (var->xoffset < 0)
> +		var->xoffset = 0;
> +
> +	if (var->yoffset < 0)
> +		var->yoffset = 0;

Ever seen an unsigned value going below zero?

> +	default:
> +		printk(KERN_ERR "unsupported color depth: %u\n",
> +			var->bits_per_pixel);

BUG(). This can't happen since you make that sure above.

> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int calc_div_ratio(struct fb_info *info)
> +{

Use a consistent namespace for function names (fsl_dcu_)

> +	writel(DCU_THRESHOLD_LS_BF_VS(0x3) | DCU_THRESHOLD_OUT_BUF_HIGH(0x78) |
> +		DCU_THRESHOLD_OUT_BUF_LOW(0), dcufb->reg_base + DCU_THRESHOLD);
> +
> +	enable_controller(info);
> +}

Make your functions symmetric. If there's update_controller(), the
function should do exactly that, it should *not* enable the controller.
Call this from the users of this function if necessary.

> +		if (copy_to_user(buf, &alpha, sizeof(alpha)))
> +			return -EFAULT;
> +		break;
> +	case MFB_SET_ALPHA:
> +		if (copy_from_user(&alpha, buf, sizeof(alpha)))
> +			return -EFAULT;
> +		mfbi->blend = 1;
> +		mfbi->alpha = alpha;
> +		fsl_dcu_set_par(info);
> +		break;

Is it still state of the art to introduce ioctls in the fb framework
without any kind of documentation?

> +	default:
> +		printk(KERN_ERR "unknown ioctl command (0x%08X)\n", cmd);

What shall a reader of the kernel log do with a message like this? It's
utterly useless when he doesn't even now which device failed here. Just
drop this.

> +static void enable_interrupts(struct dcu_fb_data *dcufb)
> +{
> +	u32 int_mask = readl(dcufb->reg_base + DCU_INT_MASK);
> +
> +	writel(int_mask & ~DCU_INT_MASK_UNDRUN, dcufb->reg_base + DCU_INT_MASK);
> +}

Inline this code where you need it. Introducing a function for a single
register write seems quite useless.

> +static int install_framebuffer(struct fb_info *info)
> +{
> +	struct mfb_info *mfbi = info->par;
> +	struct fb_videomode *db = dcu_mode_db;
> +	unsigned int dbsize = ARRAY_SIZE(dcu_mode_db);
> +	int ret;
> +
> +	info->var.activate = FB_ACTIVATE_NOW;
> +	info->fbops = &fsl_dcu_ops;
> +	info->flags = FBINFO_FLAG_DEFAULT;
> +	info->pseudo_palette = &mfbi->pseudo_palette;
> +
> +	fb_alloc_cmap(&info->cmap, 16, 0);
> +
> +	ret = fb_find_mode(&info->var, info, fb_mode, db, dbsize,
> +			NULL, default_bpp);
> +
> +	if (fsl_dcu_check_var(&info->var, info)) {
> +		ret = -EINVAL;

Propagate the error.

> +		goto failed_checkvar;
> +	}
> +
> +	if (register_framebuffer(info) < 0) {
> +		ret = -EINVAL;

ditto

> +static irqreturn_t fsl_dcu_irq(int irq, void *dev_id)
> +{
> +	struct dcu_fb_data *dcufb = dev_id;
> +	unsigned int status = readl(dcufb->reg_base + DCU_INT_STATUS);
> +	u32 dcu_mode;
> +
> +	if (status) {

Save indendation level by bailing out early.

> +		if (status & DCU_INT_STATUS_UNDRUN) {
> +			dcu_mode = readl(dcufb->reg_base + DCU_DCU_MODE);
> +			dcu_mode &= ~DCU_MODE_DCU_MODE_MASK;
> +			writel(dcu_mode | DCU_MODE_DCU_MODE(DCU_MODE_OFF),
> +				dcufb->reg_base + DCU_DCU_MODE);
> +			udelay(1);
> +			writel(dcu_mode | DCU_MODE_DCU_MODE(DCU_MODE_NORMAL),
> +				dcufb->reg_base + DCU_DCU_MODE);
> +		}
> +		writel(status, dcufb->reg_base + DCU_INT_STATUS);
> +		return IRQ_HANDLED;
> +	}
> +	return IRQ_NONE;
> +}
> +
> +	if (IS_ERR(tcon_clk)) {
> +		ret = PTR_ERR(tcon_clk);
> +		goto failed_getclock;
> +	}
> +	clk_prepare_enable(tcon_clk);
> +
> +	tcon_reg = of_iomap(tcon_np, 0);

Use devm_*

> +	dcufb->irq = platform_get_irq(pdev, 0);
> +	if (!dcufb->irq) {
> +		ret = -EINVAL;
> +		goto failed_getirq;
> +	}
> +
> +	ret = request_irq(dcufb->irq, fsl_dcu_irq, 0, DRIVER_NAME, dcufb);

Use devm_request_irq

> +	if (ret) {
> +		dev_err(&pdev->dev, "could not request irq\n");
> +		goto failed_requestirq;
> +	}
> +
> +	/* Put TCON in bypass mode, so the input signals from DCU are passed
> +	 * through TCON unchanged */
> +	ret = bypass_tcon(pdev->dev.of_node);
> +	if (ret) {
> +		dev_err(&pdev->dev, "could not bypass TCON\n");
> +		goto failed_bypasstcon;
> +	}
> +
> +	dcufb->clk = devm_clk_get(&pdev->dev, "dcu");
> +	if (IS_ERR(dcufb->clk)) {
> +		dev_err(&pdev->dev, "could not get clock\n");
> +		goto failed_getclock;

You will return 0 here.

> +	}
> +	clk_prepare_enable(dcufb->clk);
> +
> +	for (i = 0; i < ARRAY_SIZE(dcufb->fsl_dcu_info); i++) {
> +		dcufb->fsl_dcu_info[i] =
> +			framebuffer_alloc(sizeof(struct mfb_info), &pdev->dev);
> +		if (!dcufb->fsl_dcu_info[i]) {
> +			ret = ENOMEM;

-ENOMEM

> +failed_alloc_framebuffer:
> +failed_getclock:
> +failed_bypasstcon:
> +	free_irq(dcufb->irq, dcufb);
> +failed_requestirq:
> +failed_getirq:
> +	iounmap(dcufb->reg_base);

You used devm_ioremap, so drop this.

> +failed_ioremap:
> +	kfree(dcufb);

This is allocated with devm_*. Drop this.


Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From linux at arm.linux.org.uk  Mon Jul 29 07:15:03 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 29 Jul 2013 12:15:03 +0100
Subject: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes
In-Reply-To: <51F2A3AA.4060801@ti.com>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
 <20130726151021.GU24642@n2100.arm.linux.org.uk> <51F2A3AA.4060801@ti.com>
Message-ID: <20130729111503.GG24642@n2100.arm.linux.org.uk>

On Fri, Jul 26, 2013 at 12:28:26PM -0400, Santosh Shilimkar wrote:
> On Friday 26 July 2013 11:10 AM, Russell King - ARM Linux wrote:
> > On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
> >> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
> >> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
> >> PFNs but that breaks the dma_mask for few block layer drivers since
> >> ARM start of physical memory is not PFN0 unlike most of the architectures.
> >> Some more read on it is here:
> >> 	http://lwn.net/Articles/543408/
> >> 	http://lwn.net/Articles/543424/
> >>
> >> To address this issue, we introduce generic dma_max_pfn() helper which
> >> can be overridden from the architectures.
> >> 	
> >> Another intention behind move to nobootmem is also to convert ARM to
> >> switch to memblock and getting rid of bootmem allocator dependency which
> >> don't work for LPAE machines which has physical memory starting beyond
> >> 4 GB boundary. It needs changes to core kernel and also a new memblock
> >> API. More on this can be found here:
> >> 	https://lkml.org/lkml/2013/6/29/77
> >>
> >> I have been trying to cook up these patches with kind help from Russell
> >> and we know series don't solve all the dma_mask bad assumptions. But at
> >> least I am hoping that it can get the ball rolling.	
> >>
> >> Comments/testing help is welcome !!
> > 
> > As this is related to some of the cleanup of dma_mask which I've been
> > doing, I think it may make sense to roll this into one tree.  Any
> > objection to that?
> > 
> > Can we get any acks on this stuff from Jens and Jejb etc - especially
> > for the bits which touch block/ and for the scsi bits as these are
> > touching other subsystems.  (oddly, linux-scsi wasn't on the original
> > mail for this series summary.)
> > 
> Sorry I missed the scsi lists on the summary patch.
> 
> While browsing the code I found another spot in mmc layer which
> needs fixing. The patch is at the end of the email with Chris
> and linux-mmc cc'ed here.

Would you mind putting them all in the patch system, I can add the acks
should anyone supply them later, and I'll repost them along with my set
of dma-mask patches.  Thanks.


From hdoyu at nvidia.com  Mon Jul 29 07:24:09 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Mon, 29 Jul 2013 13:24:09 +0200
Subject: [PATCH v2 13/22] iommu/tegra: smmu: Create default IOVA maps
In-Reply-To: <51E84BB5.9010303@wwwdotorg.org>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com><1373021097-32420-14-git-send-email-hdoyu@nvidia.com><51E84BB5.9010303@wwwdotorg.org>
Message-ID: <20130729.142409.995770519696534476.hdoyu@nvidia.com>

Stephen Warren <swarren at wwwdotorg.org> wrote @ Thu, 18 Jul 2013 22:10:29 +0200:

> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> > Create default IOVA maps at boot-up which can be attached to devices.
> 
> > diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> 
> >  static int tegra_smmu_probe(struct platform_device *pdev)
> >  {
> >  	struct smmu_device *smmu;
> 
> > @@ -1160,13 +1182,15 @@ static int tegra_smmu_probe(struct platform_device *pdev)
> >  	if (of_property_read_u32(dev->of_node, "nvidia,#asids", &asids))
> >  		return -ENODEV;
> >  
> > -	bytes = sizeof(*smmu) + asids * sizeof(*smmu->as);
> > +	bytes = sizeof(*smmu) + asids * (sizeof(*smmu->as) +
> > +					 sizeof(struct dma_iommu_mapping *));
> >  	smmu = devm_kzalloc(dev, bytes, GFP_KERNEL);
> >  	if (!smmu) {
> >  		dev_err(dev, "failed to allocate smmu_device\n");
> >  		return -ENOMEM;
> >  	}
> >  
> > +	smmu->map = (struct dma_iommu_mapping **)(smmu->as + asids);
> 
> Shouldn't "+ asids" be "+ asids * sizeof(*smmu->as)" to match the
> calculation of "bytes" above?

The structure is:

smmu {
     ....
     struct dma_iommu_mapping **map;
     ....	
     struct smmu_as	as[0];
};

I think that this is correct, but is the following better?

+ smmu->map = (struct dma_iommu_mapping **)&smmu->as[asids];


From james.hogan at imgtec.com  Mon Jul 29 07:24:58 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Mon, 29 Jul 2013 12:24:58 +0100
Subject: [PATCH v6 1/5] clk: abstract parent cache
In-Reply-To: <1375097102-28892-1-git-send-email-james.hogan@imgtec.com>
References: <1375097102-28892-1-git-send-email-james.hogan@imgtec.com>
Message-ID: <1375097102-28892-2-git-send-email-james.hogan@imgtec.com>

Abstract access to the clock parent cache by defining
clk_get_parent_by_index(clk, index). This allows access to parent
clocks from clock drivers.

Signed-off-by: James Hogan <james.hogan at imgtec.com>
Reviewed-by: Stephen Boyd <sboyd at codeaurora.org>
Cc: Mike Turquette <mturquette at linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
---
Changes in v3:

* remove double underscore prefix from clk_get_parent_by_index()

 drivers/clk/clk.c            | 21 ++++++++++++++-------
 include/linux/clk-provider.h |  1 +
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 54a191c..e06a9ac 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -559,6 +559,19 @@ struct clk *__clk_get_parent(struct clk *clk)
 	return !clk ? NULL : clk->parent;
 }
 
+struct clk *clk_get_parent_by_index(struct clk *clk, u8 index)
+{
+	if (!clk || index >= clk->num_parents)
+		return NULL;
+	else if (!clk->parents)
+		return __clk_lookup(clk->parent_names[index]);
+	else if (!clk->parents[index])
+		return clk->parents[index] =
+			__clk_lookup(clk->parent_names[index]);
+	else
+		return clk->parents[index];
+}
+
 unsigned int __clk_get_enable_count(struct clk *clk)
 {
 	return !clk ? 0 : clk->enable_count;
@@ -1315,13 +1328,7 @@ static struct clk *__clk_init_parent(struct clk *clk)
 			kzalloc((sizeof(struct clk*) * clk->num_parents),
 					GFP_KERNEL);
 
-	if (!clk->parents)
-		ret = __clk_lookup(clk->parent_names[index]);
-	else if (!clk->parents[index])
-		ret = clk->parents[index] =
-			__clk_lookup(clk->parent_names[index]);
-	else
-		ret = clk->parents[index];
+	ret = clk_get_parent_by_index(clk, index);
 
 out:
 	return ret;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1ec14a7..e54dac5 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -418,6 +418,7 @@ const char *__clk_get_name(struct clk *clk);
 struct clk_hw *__clk_get_hw(struct clk *clk);
 u8 __clk_get_num_parents(struct clk *clk);
 struct clk *__clk_get_parent(struct clk *clk);
+struct clk *clk_get_parent_by_index(struct clk *clk, u8 index);
 unsigned int __clk_get_enable_count(struct clk *clk);
 unsigned int __clk_get_prepare_count(struct clk *clk);
 unsigned long __clk_get_rate(struct clk *clk);
-- 
1.8.1.2




From james.hogan at imgtec.com  Mon Jul 29 07:24:57 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Mon, 29 Jul 2013 12:24:57 +0100
Subject: [PATCH v6 0/5] clk: implement remuxing during set_rate
Message-ID: <1375097102-28892-1-git-send-email-james.hogan@imgtec.com>

This patchset adds support for automatic selection of the best parent
for a clock mux, i.e. the one which can provide the closest clock rate
to that requested. It can be disabled by a new CLK_SET_RATE_NO_REPARENT
flag (which is set for all uses of clk_register_mux().

This works by way of adding a new op, determine_rate, similar to
round_rate but with an extra parameter to allow the clock driver to
optionally select a different parent clock. This is used in
clk_calc_new_rates to decide whether to initiate a set_parent operation.

Changes in v6:

* Rebased on v3.11-rc1.
* Added changes to samsung/clk-exynos-audss.c, zynq/clkc.c.

Changes in v5:

* Rebased on latest clk-next ("clk: tegra: Use common of_clk_init
  function")
* Updated clock hardware characteristics table in documentation.

Changes in v4:

* rebased on clk-next ("clk: sun5i: Add compatibles for Allwinner A13").
* replace __clk_set_parent_no_recalc with __clk_set_parent.
* never pass NULL to determine_rate's best_parent_clk parameter, and
  slight refactor of __clk_round_rate to use local copy of clk->parent.
* a few new comments around use of clk::new_child.
* new patch (patch 2) split out of patch 3 to avoid having to declare
  static __clk_set_parent() at the top of clk.c, and to ease readability
  of patch 3.

Changes in v3:

* rebased on v3.10-rc1.
* remove double underscore prefix from clk_get_parent_by_index()
* store new_parent_index in struct clk too (calculated from
  clk_fetch_parent_index, and passed through __clk_set_parent_no_recalc
  to __clk_set_parent).
* allow determine_rate to satisfy recalc_rate check in __clk_init.
* rename/invert CLK_SET_RATE_REMUX to CLK_SET_RATE_NO_REPARENT and move
  to patch 3.
* patch 3: add CLK_SET_RATE_NO_REPARENT flag to all callers of
  clk_register_mux. If you don't mind your clocks being reparented in
  response to set_rate please let me know and I'll drop the relevant
  portion of the patch.

Changes in v2:

I've moved the mux determine_rate implementation into a core helper, but
I haven't pushed it fully into the core, as I think it just wouldn't
work correctly for more complex clocks, e.g. if you (theoretically) had
a combined mux and divide, you'd want to intercept the determine_rate
and ask for a larger rate from the parent clocks, then return the
divided rate. This should be possible by wrapping the mux determine_rate
helper.

Patch 1 still exports the __clk_get_parent_by_index as it seems like it
might be a useful thing for clock implementations to have access to if
they ever wanted to do something more fancy with changing clock parents.

I haven't made any attempt to implement the atomic set_parent+set_rate
as I don't have hardware that could take proper advantage of it, but it
shouldn't be too difficult for others to implement if they wanted since
they're fairly close to one another (in clk_change_rate()).

* switched to using new determine_rate op rather than adding an argument
  to round_rate.
* moved mux implementation into a single helper which should be usable
  from more complex clocks which can mux.
* rewrite main implementation so that no changes are made until after
  the PRE notifications have been sent, and in a way that should ensure
  correct notifications without duplicates, and I think should be safe
  in the event of a notification failing.
* various tidy ups and fixes.

James Hogan (5):
  clk: abstract parent cache
  clk: move some parent related functions upwards
  clk: add support for clock reparent on set_rate
  clk: add CLK_SET_RATE_NO_REPARENT flag
  clk: clk-mux: implement remuxing on set_rate

 Documentation/clk.txt                  |  46 ++--
 arch/arm/mach-imx/clk.h                |   5 +-
 drivers/clk/clk-mux.c                  |   1 +
 drivers/clk/clk.c                      | 420 +++++++++++++++++++++------------
 drivers/clk/mmp/clk-mmp2.c             |  39 ++-
 drivers/clk/mmp/clk-pxa168.c           |  40 ++--
 drivers/clk/mmp/clk-pxa910.c           |  31 ++-
 drivers/clk/mxs/clk.h                  |   4 +-
 drivers/clk/samsung/clk-exynos-audss.c |   6 +-
 drivers/clk/samsung/clk.h              |   2 +-
 drivers/clk/spear/spear1310_clock.c    | 179 +++++++-------
 drivers/clk/spear/spear1340_clock.c    |  97 ++++----
 drivers/clk/spear/spear3xx_clock.c     |  57 +++--
 drivers/clk/spear/spear6xx_clock.c     |  35 +--
 drivers/clk/sunxi/clk-sunxi.c          |   3 +-
 drivers/clk/tegra/clk-tegra114.c       |  36 ++-
 drivers/clk/tegra/clk-tegra20.c        |   6 +-
 drivers/clk/tegra/clk-tegra30.c        |  33 ++-
 drivers/clk/versatile/clk-vexpress.c   |   4 +-
 drivers/clk/zynq/clkc.c                |  86 ++++---
 include/linux/clk-private.h            |   3 +
 include/linux/clk-provider.h           |  12 +
 22 files changed, 692 insertions(+), 453 deletions(-)

-- 
1.8.1.2




From james.hogan at imgtec.com  Mon Jul 29 07:24:59 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Mon, 29 Jul 2013 12:24:59 +0100
Subject: [PATCH v6 2/5] clk: move some parent related functions upwards
In-Reply-To: <1375097102-28892-1-git-send-email-james.hogan@imgtec.com>
References: <1375097102-28892-1-git-send-email-james.hogan@imgtec.com>
Message-ID: <1375097102-28892-3-git-send-email-james.hogan@imgtec.com>

Move some parent related functions up in clk.c so they can be used by
the modifications in the following patch which enables clock reparenting
during set_rate. No other changes are made so this patch makes no
functional difference in isolation. This is separate from the following
patch primarily to ease readability of that patch.

Signed-off-by: James Hogan <james.hogan at imgtec.com>
Reviewed-by: Stephen Boyd <sboyd at codeaurora.org>
Cc: Mike Turquette <mturquette at linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
---
Changes in v5:

* Rebased on latest clk-next ("clk: tegra: Use common of_clk_init
  function")

Changes in v4:

* new patch (patch 2) split out of patch 3 to avoid having to declare
  static __clk_set_parent() at the top of clk.c, and to ease readability
  of patch 3.

 drivers/clk/clk.c | 208 +++++++++++++++++++++++++++---------------------------
 1 file changed, 104 insertions(+), 104 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index e06a9ac..b766db1 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1027,6 +1027,110 @@ unsigned long clk_get_rate(struct clk *clk)
 }
 EXPORT_SYMBOL_GPL(clk_get_rate);
 
+static u8 clk_fetch_parent_index(struct clk *clk, struct clk *parent)
+{
+	u8 i;
+
+	if (!clk->parents)
+		clk->parents = kzalloc((sizeof(struct clk*) * clk->num_parents),
+								GFP_KERNEL);
+
+	/*
+	 * find index of new parent clock using cached parent ptrs,
+	 * or if not yet cached, use string name comparison and cache
+	 * them now to avoid future calls to __clk_lookup.
+	 */
+	for (i = 0; i < clk->num_parents; i++) {
+		if (clk->parents && clk->parents[i] == parent)
+			break;
+		else if (!strcmp(clk->parent_names[i], parent->name)) {
+			if (clk->parents)
+				clk->parents[i] = __clk_lookup(parent->name);
+			break;
+		}
+	}
+
+	return i;
+}
+
+static void clk_reparent(struct clk *clk, struct clk *new_parent)
+{
+	hlist_del(&clk->child_node);
+
+	if (new_parent)
+		hlist_add_head(&clk->child_node, &new_parent->children);
+	else
+		hlist_add_head(&clk->child_node, &clk_orphan_list);
+
+	clk->parent = new_parent;
+}
+
+static int __clk_set_parent(struct clk *clk, struct clk *parent, u8 p_index)
+{
+	unsigned long flags;
+	int ret = 0;
+	struct clk *old_parent = clk->parent;
+
+	/*
+	 * Migrate prepare state between parents and prevent race with
+	 * clk_enable().
+	 *
+	 * If the clock is not prepared, then a race with
+	 * clk_enable/disable() is impossible since we already have the
+	 * prepare lock (future calls to clk_enable() need to be preceded by
+	 * a clk_prepare()).
+	 *
+	 * If the clock is prepared, migrate the prepared state to the new
+	 * parent and also protect against a race with clk_enable() by
+	 * forcing the clock and the new parent on.  This ensures that all
+	 * future calls to clk_enable() are practically NOPs with respect to
+	 * hardware and software states.
+	 *
+	 * See also: Comment for clk_set_parent() below.
+	 */
+	if (clk->prepare_count) {
+		__clk_prepare(parent);
+		clk_enable(parent);
+		clk_enable(clk);
+	}
+
+	/* update the clk tree topology */
+	flags = clk_enable_lock();
+	clk_reparent(clk, parent);
+	clk_enable_unlock(flags);
+
+	/* change clock input source */
+	if (parent && clk->ops->set_parent)
+		ret = clk->ops->set_parent(clk->hw, p_index);
+
+	if (ret) {
+		flags = clk_enable_lock();
+		clk_reparent(clk, old_parent);
+		clk_enable_unlock(flags);
+
+		if (clk->prepare_count) {
+			clk_disable(clk);
+			clk_disable(parent);
+			__clk_unprepare(parent);
+		}
+		return ret;
+	}
+
+	/*
+	 * Finish the migration of prepare state and undo the changes done
+	 * for preventing a race with clk_enable().
+	 */
+	if (clk->prepare_count) {
+		clk_disable(clk);
+		clk_disable(old_parent);
+		__clk_unprepare(old_parent);
+	}
+
+	/* update debugfs with new clk tree topology */
+	clk_debug_reparent(clk, parent);
+	return 0;
+}
+
 /**
  * __clk_speculate_rates
  * @clk: first clk in the subtree
@@ -1334,18 +1438,6 @@ out:
 	return ret;
 }
 
-static void clk_reparent(struct clk *clk, struct clk *new_parent)
-{
-	hlist_del(&clk->child_node);
-
-	if (new_parent)
-		hlist_add_head(&clk->child_node, &new_parent->children);
-	else
-		hlist_add_head(&clk->child_node, &clk_orphan_list);
-
-	clk->parent = new_parent;
-}
-
 void __clk_reparent(struct clk *clk, struct clk *new_parent)
 {
 	clk_reparent(clk, new_parent);
@@ -1353,98 +1445,6 @@ void __clk_reparent(struct clk *clk, struct clk *new_parent)
 	__clk_recalc_rates(clk, POST_RATE_CHANGE);
 }
 
-static u8 clk_fetch_parent_index(struct clk *clk, struct clk *parent)
-{
-	u8 i;
-
-	if (!clk->parents)
-		clk->parents = kzalloc((sizeof(struct clk*) * clk->num_parents),
-								GFP_KERNEL);
-
-	/*
-	 * find index of new parent clock using cached parent ptrs,
-	 * or if not yet cached, use string name comparison and cache
-	 * them now to avoid future calls to __clk_lookup.
-	 */
-	for (i = 0; i < clk->num_parents; i++) {
-		if (clk->parents && clk->parents[i] == parent)
-			break;
-		else if (!strcmp(clk->parent_names[i], parent->name)) {
-			if (clk->parents)
-				clk->parents[i] = __clk_lookup(parent->name);
-			break;
-		}
-	}
-
-	return i;
-}
-
-static int __clk_set_parent(struct clk *clk, struct clk *parent, u8 p_index)
-{
-	unsigned long flags;
-	int ret = 0;
-	struct clk *old_parent = clk->parent;
-
-	/*
-	 * Migrate prepare state between parents and prevent race with
-	 * clk_enable().
-	 *
-	 * If the clock is not prepared, then a race with
-	 * clk_enable/disable() is impossible since we already have the
-	 * prepare lock (future calls to clk_enable() need to be preceded by
-	 * a clk_prepare()).
-	 *
-	 * If the clock is prepared, migrate the prepared state to the new
-	 * parent and also protect against a race with clk_enable() by
-	 * forcing the clock and the new parent on.  This ensures that all
-	 * future calls to clk_enable() are practically NOPs with respect to
-	 * hardware and software states.
-	 *
-	 * See also: Comment for clk_set_parent() below.
-	 */
-	if (clk->prepare_count) {
-		__clk_prepare(parent);
-		clk_enable(parent);
-		clk_enable(clk);
-	}
-
-	/* update the clk tree topology */
-	flags = clk_enable_lock();
-	clk_reparent(clk, parent);
-	clk_enable_unlock(flags);
-
-	/* change clock input source */
-	if (parent && clk->ops->set_parent)
-		ret = clk->ops->set_parent(clk->hw, p_index);
-
-	if (ret) {
-		flags = clk_enable_lock();
-		clk_reparent(clk, old_parent);
-		clk_enable_unlock(flags);
-
-		if (clk->prepare_count) {
-			clk_disable(clk);
-			clk_disable(parent);
-			__clk_unprepare(parent);
-		}
-		return ret;
-	}
-
-	/*
-	 * Finish the migration of prepare state and undo the changes done
-	 * for preventing a race with clk_enable().
-	 */
-	if (clk->prepare_count) {
-		clk_disable(clk);
-		clk_disable(old_parent);
-		__clk_unprepare(old_parent);
-	}
-
-	/* update debugfs with new clk tree topology */
-	clk_debug_reparent(clk, parent);
-	return 0;
-}
-
 /**
  * clk_set_parent - switch the parent of a mux clk
  * @clk: the mux clk whose input we are switching
-- 
1.8.1.2




From james.hogan at imgtec.com  Mon Jul 29 07:25:02 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Mon, 29 Jul 2013 12:25:02 +0100
Subject: [PATCH v6 5/5] clk: clk-mux: implement remuxing on set_rate
In-Reply-To: <1375097102-28892-1-git-send-email-james.hogan@imgtec.com>
References: <1375097102-28892-1-git-send-email-james.hogan@imgtec.com>
Message-ID: <1375097102-28892-6-git-send-email-james.hogan@imgtec.com>

Implement clk-mux remuxing if the CLK_SET_RATE_NO_REPARENT flag isn't
set. This implements determine_rate for clk-mux to propagate to each
parent and to choose the best one (like clk-divider this chooses the
parent which provides the fastest rate <= the requested rate).

The determine_rate op is implemented as a core helper function so that
it can be easily used by more complex clocks which incorporate muxes.

Signed-off-by: James Hogan <james.hogan at imgtec.com>
Reviewed-by: Stephen Boyd <sboyd at codeaurora.org>
Cc: Mike Turquette <mturquette at linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
---
Changes in v4:

* never pass NULL to determine_rate's best_parent_clk parameter.

Changes in v3:

* rename/invert CLK_SET_RATE_REMUX to CLK_SET_RATE_NO_REPARENT and move
  to patch 3.

 drivers/clk/clk-mux.c        |  1 +
 drivers/clk/clk.c            | 49 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/clk-provider.h |  3 +++
 3 files changed, 53 insertions(+)

diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 614444c..b487b3c 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -104,6 +104,7 @@ static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
 const struct clk_ops clk_mux_ops = {
 	.get_parent = clk_mux_get_parent,
 	.set_parent = clk_mux_set_parent,
+	.determine_rate = __clk_mux_determine_rate,
 };
 EXPORT_SYMBOL_GPL(clk_mux_ops);
 
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 2a047a0..1ed9bdd 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -692,6 +692,55 @@ struct clk *__clk_lookup(const char *name)
 	return NULL;
 }
 
+/*
+ * Helper for finding best parent to provide a given frequency. This can be used
+ * directly as a determine_rate callback (e.g. for a mux), or from a more
+ * complex clock that may combine a mux with other operations.
+ */
+long __clk_mux_determine_rate(struct clk_hw *hw, unsigned long rate,
+			      unsigned long *best_parent_rate,
+			      struct clk **best_parent_p)
+{
+	struct clk *clk = hw->clk, *parent, *best_parent = NULL;
+	int i, num_parents;
+	unsigned long parent_rate, best = 0;
+
+	/* if NO_REPARENT flag set, pass through to current parent */
+	if (clk->flags & CLK_SET_RATE_NO_REPARENT) {
+		parent = clk->parent;
+		if (clk->flags & CLK_SET_RATE_PARENT)
+			best = __clk_round_rate(parent, rate);
+		else if (parent)
+			best = __clk_get_rate(parent);
+		else
+			best = __clk_get_rate(clk);
+		goto out;
+	}
+
+	/* find the parent that can provide the fastest rate <= rate */
+	num_parents = clk->num_parents;
+	for (i = 0; i < num_parents; i++) {
+		parent = clk_get_parent_by_index(clk, i);
+		if (!parent)
+			continue;
+		if (clk->flags & CLK_SET_RATE_PARENT)
+			parent_rate = __clk_round_rate(parent, rate);
+		else
+			parent_rate = __clk_get_rate(parent);
+		if (parent_rate <= rate && parent_rate > best) {
+			best_parent = parent;
+			best = parent_rate;
+		}
+	}
+
+out:
+	if (best_parent)
+		*best_parent_p = best_parent;
+	*best_parent_rate = best;
+
+	return best;
+}
+
 /***        clk api        ***/
 
 void __clk_unprepare(struct clk *clk)
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 8ffe06c..9861cee 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -434,6 +434,9 @@ unsigned long __clk_get_flags(struct clk *clk);
 bool __clk_is_prepared(struct clk *clk);
 bool __clk_is_enabled(struct clk *clk);
 struct clk *__clk_lookup(const char *name);
+long __clk_mux_determine_rate(struct clk_hw *hw, unsigned long rate,
+			      unsigned long *best_parent_rate,
+			      struct clk **best_parent_p);
 
 /*
  * FIXME clock api without lock protection
-- 
1.8.1.2




From james.hogan at imgtec.com  Mon Jul 29 07:25:00 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Mon, 29 Jul 2013 12:25:00 +0100
Subject: [PATCH v6 3/5] clk: add support for clock reparent on set_rate
In-Reply-To: <1375097102-28892-1-git-send-email-james.hogan@imgtec.com>
References: <1375097102-28892-1-git-send-email-james.hogan@imgtec.com>
Message-ID: <1375097102-28892-4-git-send-email-james.hogan@imgtec.com>

Add core support to allow clock implementations to select the best
parent clock when rounding a rate, e.g. the one which can provide the
closest clock rate to that requested. This is by way of adding a new
clock op, determine_rate(), which is like round_rate() but has an extra
parameter to allow the clock implementation to optionally select a
different parent clock. The core then takes care of reparenting the
clock when setting the rate.

The parent change takes place with the help of some new private data
members. struct clk::new_parent specifies a clock's new parent (NULL
indicates no change), and struct clk::new_child specifies a clock's new
child (whose new_parent member points back to it). The purpose of these
are to allow correct walking of the future tree for notifications prior
to actually reparenting any clocks, specifically to skip child clocks
who are being reparented to another clock (they will be notified via the
new parent), and to include any new child clock. These pointers are set
by clk_calc_subtree(), and the new_child pointer gets cleared when a
child is actually reparented to avoid duplicate POST_RATE_CHANGE
notifications.

Each place where round_rate() is called, determine_rate() is checked
first and called in preference. This restructures a few of the call
sites to simplify the logic into if/else blocks.

Signed-off-by: James Hogan <james.hogan at imgtec.com>
Reviewed-by: Stephen Boyd <sboyd at codeaurora.org>
Cc: Mike Turquette <mturquette at linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
---
Changes in v5:

* Updated clock hardware characteristics table in documentation.

Changes in v4:

* (not included Stephen Boyd's Reviewed-by due to changes)
* replace __clk_set_parent_no_recalc with __clk_set_parent.
* never pass NULL to determine_rate's best_parent_clk parameter, and
  slight refactor of __clk_round_rate to use local copy of clk->parent.
* a few new comments around use of clk::new_child.

Changes in v3:

* rebased on v3.10-rc1.
* store new_parent_index in struct clk too (calculated from
  clk_fetch_parent_index, and passed through __clk_set_parent_no_recalc
  to __clk_set_parent).
* allow determine_rate to satisfy recalc_rate check in __clk_init.

 Documentation/clk.txt        |  46 ++++++++------
 drivers/clk/clk.c            | 142 +++++++++++++++++++++++++++++--------------
 include/linux/clk-private.h  |   3 +
 include/linux/clk-provider.h |   7 +++
 4 files changed, 132 insertions(+), 66 deletions(-)

diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index 6f68ba0..3aeb5c4 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -70,6 +70,10 @@ the operations defined in clk.h:
 						unsigned long parent_rate);
 		long		(*round_rate)(struct clk_hw *hw, unsigned long,
 						unsigned long *);
+		long		(*determine_rate)(struct clk_hw *hw,
+						unsigned long rate,
+						unsigned long *best_parent_rate,
+						struct clk **best_parent_clk);
 		int		(*set_parent)(struct clk_hw *hw, u8 index);
 		u8		(*get_parent)(struct clk_hw *hw);
 		int		(*set_rate)(struct clk_hw *hw, unsigned long);
@@ -179,26 +183,28 @@ mandatory, a cell marked as "n" implies that either including that
 callback is invalid or otherwise unnecessary.  Empty cells are either
 optional or must be evaluated on a case-by-case basis.
 
-                           clock hardware characteristics
-	     -----------------------------------------------------------
-             | gate | change rate | single parent | multiplexer | root |
-             |------|-------------|---------------|-------------|------|
-.prepare     |      |             |               |             |      |
-.unprepare   |      |             |               |             |      |
-             |      |             |               |             |      |
-.enable      | y    |             |               |             |      |
-.disable     | y    |             |               |             |      |
-.is_enabled  | y    |             |               |             |      |
-             |      |             |               |             |      |
-.recalc_rate |      | y           |               |             |      |
-.round_rate  |      | y           |               |             |      |
-.set_rate    |      | y           |               |             |      |
-             |      |             |               |             |      |
-.set_parent  |      |             | n             | y           | n    |
-.get_parent  |      |             | n             | y           | n    |
-             |      |             |               |             |      |
-.init        |      |             |               |             |      |
-	     -----------------------------------------------------------
+                              clock hardware characteristics
+                -----------------------------------------------------------
+                | gate | change rate | single parent | multiplexer | root |
+                |------|-------------|---------------|-------------|------|
+.prepare        |      |             |               |             |      |
+.unprepare      |      |             |               |             |      |
+                |      |             |               |             |      |
+.enable         | y    |             |               |             |      |
+.disable        | y    |             |               |             |      |
+.is_enabled     | y    |             |               |             |      |
+                |      |             |               |             |      |
+.recalc_rate    |      | y           |               |             |      |
+.round_rate     |      | y [1]       |               |             |      |
+.determine_rate |      | y [1]       |               |             |      |
+.set_rate       |      | y           |               |             |      |
+                |      |             |               |             |      |
+.set_parent     |      |             | n             | y           | n    |
+.get_parent     |      |             | n             | y           | n    |
+                |      |             |               |             |      |
+.init           |      |             |               |             |      |
+                -----------------------------------------------------------
+[1] either one of round_rate or determine_rate is required.
 
 Finally, register your clock at run-time with a hardware-specific
 registration function.  This function simply populates struct clk_foo's
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index b766db1..2a047a0 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -888,21 +888,24 @@ EXPORT_SYMBOL_GPL(clk_enable);
 unsigned long __clk_round_rate(struct clk *clk, unsigned long rate)
 {
 	unsigned long parent_rate = 0;
+	struct clk *parent;
 
 	if (!clk)
 		return 0;
 
-	if (!clk->ops->round_rate) {
-		if (clk->flags & CLK_SET_RATE_PARENT)
-			return __clk_round_rate(clk->parent, rate);
-		else
-			return clk->rate;
-	}
-
-	if (clk->parent)
-		parent_rate = clk->parent->rate;
-
-	return clk->ops->round_rate(clk->hw, rate, &parent_rate);
+	parent = clk->parent;
+	if (parent)
+		parent_rate = parent->rate;
+
+	if (clk->ops->determine_rate)
+		return clk->ops->determine_rate(clk->hw, rate, &parent_rate,
+						&parent);
+	else if (clk->ops->round_rate)
+		return clk->ops->round_rate(clk->hw, rate, &parent_rate);
+	else if (clk->flags & CLK_SET_RATE_PARENT)
+		return __clk_round_rate(clk->parent, rate);
+	else
+		return clk->rate;
 }
 
 /**
@@ -1055,6 +1058,10 @@ static u8 clk_fetch_parent_index(struct clk *clk, struct clk *parent)
 
 static void clk_reparent(struct clk *clk, struct clk *new_parent)
 {
+	/* avoid duplicate POST_RATE_CHANGE notifications */
+	if (new_parent->new_child == clk)
+		new_parent->new_child = NULL;
+
 	hlist_del(&clk->child_node);
 
 	if (new_parent)
@@ -1175,18 +1182,25 @@ out:
 	return ret;
 }
 
-static void clk_calc_subtree(struct clk *clk, unsigned long new_rate)
+static void clk_calc_subtree(struct clk *clk, unsigned long new_rate,
+			     struct clk *new_parent, u8 p_index)
 {
 	struct clk *child;
 
 	clk->new_rate = new_rate;
+	clk->new_parent = new_parent;
+	clk->new_parent_index = p_index;
+	/* include clk in new parent's PRE_RATE_CHANGE notifications */
+	clk->new_child = NULL;
+	if (new_parent && new_parent != clk->parent)
+		new_parent->new_child = clk;
 
 	hlist_for_each_entry(child, &clk->children, child_node) {
 		if (child->ops->recalc_rate)
 			child->new_rate = child->ops->recalc_rate(child->hw, new_rate);
 		else
 			child->new_rate = new_rate;
-		clk_calc_subtree(child, child->new_rate);
+		clk_calc_subtree(child, child->new_rate, NULL, 0);
 	}
 }
 
@@ -1197,50 +1211,63 @@ static void clk_calc_subtree(struct clk *clk, unsigned long new_rate)
 static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate)
 {
 	struct clk *top = clk;
+	struct clk *old_parent, *parent;
 	unsigned long best_parent_rate = 0;
 	unsigned long new_rate;
+	u8 p_index = 0;
 
 	/* sanity */
 	if (IS_ERR_OR_NULL(clk))
 		return NULL;
 
 	/* save parent rate, if it exists */
-	if (clk->parent)
-		best_parent_rate = clk->parent->rate;
-
-	/* never propagate up to the parent */
-	if (!(clk->flags & CLK_SET_RATE_PARENT)) {
-		if (!clk->ops->round_rate) {
-			clk->new_rate = clk->rate;
-			return NULL;
-		}
-		new_rate = clk->ops->round_rate(clk->hw, rate, &best_parent_rate);
+	parent = old_parent = clk->parent;
+	if (parent)
+		best_parent_rate = parent->rate;
+
+	/* find the closest rate and parent clk/rate */
+	if (clk->ops->determine_rate) {
+		new_rate = clk->ops->determine_rate(clk->hw, rate,
+						    &best_parent_rate,
+						    &parent);
+	} else if (clk->ops->round_rate) {
+		new_rate = clk->ops->round_rate(clk->hw, rate,
+						&best_parent_rate);
+	} else if (!parent || !(clk->flags & CLK_SET_RATE_PARENT)) {
+		/* pass-through clock without adjustable parent */
+		clk->new_rate = clk->rate;
+		return NULL;
+	} else {
+		/* pass-through clock with adjustable parent */
+		top = clk_calc_new_rates(parent, rate);
+		new_rate = parent->new_rate;
 		goto out;
 	}
 
-	/* need clk->parent from here on out */
-	if (!clk->parent) {
-		pr_debug("%s: %s has NULL parent\n", __func__, clk->name);
+	/* some clocks must be gated to change parent */
+	if (parent != old_parent &&
+	    (clk->flags & CLK_SET_PARENT_GATE) && clk->prepare_count) {
+		pr_debug("%s: %s not gated but wants to reparent\n",
+			 __func__, clk->name);
 		return NULL;
 	}
 
-	if (!clk->ops->round_rate) {
-		top = clk_calc_new_rates(clk->parent, rate);
-		new_rate = clk->parent->new_rate;
-
-		goto out;
+	/* try finding the new parent index */
+	if (parent) {
+		p_index = clk_fetch_parent_index(clk, parent);
+		if (p_index == clk->num_parents) {
+			pr_debug("%s: clk %s can not be parent of clk %s\n",
+				 __func__, parent->name, clk->name);
+			return NULL;
+		}
 	}
 
-	new_rate = clk->ops->round_rate(clk->hw, rate, &best_parent_rate);
-
-	if (best_parent_rate != clk->parent->rate) {
-		top = clk_calc_new_rates(clk->parent, best_parent_rate);
-
-		goto out;
-	}
+	if ((clk->flags & CLK_SET_RATE_PARENT) && parent &&
+	    best_parent_rate != parent->rate)
+		top = clk_calc_new_rates(parent, best_parent_rate);
 
 out:
-	clk_calc_subtree(clk, new_rate);
+	clk_calc_subtree(clk, new_rate, parent, p_index);
 
 	return top;
 }
@@ -1252,7 +1279,7 @@ out:
  */
 static struct clk *clk_propagate_rate_change(struct clk *clk, unsigned long event)
 {
-	struct clk *child, *fail_clk = NULL;
+	struct clk *child, *tmp_clk, *fail_clk = NULL;
 	int ret = NOTIFY_DONE;
 
 	if (clk->rate == clk->new_rate)
@@ -1265,9 +1292,19 @@ static struct clk *clk_propagate_rate_change(struct clk *clk, unsigned long even
 	}
 
 	hlist_for_each_entry(child, &clk->children, child_node) {
-		clk = clk_propagate_rate_change(child, event);
-		if (clk)
-			fail_clk = clk;
+		/* Skip children who will be reparented to another clock */
+		if (child->new_parent && child->new_parent != clk)
+			continue;
+		tmp_clk = clk_propagate_rate_change(child, event);
+		if (tmp_clk)
+			fail_clk = tmp_clk;
+	}
+
+	/* handle the new child who might not be in clk->children yet */
+	if (clk->new_child) {
+		tmp_clk = clk_propagate_rate_change(clk->new_child, event);
+		if (tmp_clk)
+			fail_clk = tmp_clk;
 	}
 
 	return fail_clk;
@@ -1285,6 +1322,10 @@ static void clk_change_rate(struct clk *clk)
 
 	old_rate = clk->rate;
 
+	/* set parent */
+	if (clk->new_parent && clk->new_parent != clk->parent)
+		__clk_set_parent(clk, clk->new_parent, clk->new_parent_index);
+
 	if (clk->parent)
 		best_parent_rate = clk->parent->rate;
 
@@ -1299,8 +1340,16 @@ static void clk_change_rate(struct clk *clk)
 	if (clk->notifier_count && old_rate != clk->rate)
 		__clk_notify(clk, POST_RATE_CHANGE, old_rate, clk->rate);
 
-	hlist_for_each_entry(child, &clk->children, child_node)
+	hlist_for_each_entry(child, &clk->children, child_node) {
+		/* Skip children who will be reparented to another clock */
+		if (child->new_parent && child->new_parent != clk)
+			continue;
 		clk_change_rate(child);
+	}
+
+	/* handle the new child who might not be in clk->children yet */
+	if (clk->new_child)
+		clk_change_rate(clk->new_child);
 }
 
 /**
@@ -1551,8 +1600,9 @@ int __clk_init(struct device *dev, struct clk *clk)
 
 	/* check that clk_ops are sane.  See Documentation/clk.txt */
 	if (clk->ops->set_rate &&
-			!(clk->ops->round_rate && clk->ops->recalc_rate)) {
-		pr_warning("%s: %s must implement .round_rate & .recalc_rate\n",
+	    !((clk->ops->round_rate || clk->ops->determine_rate) &&
+	      clk->ops->recalc_rate)) {
+		pr_warning("%s: %s must implement .round_rate or .determine_rate in addition to .recalc_rate\n",
 				__func__, clk->name);
 		ret = -EINVAL;
 		goto out;
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index dd7adff..8138c94 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -33,8 +33,11 @@ struct clk {
 	const char		**parent_names;
 	struct clk		**parents;
 	u8			num_parents;
+	u8			new_parent_index;
 	unsigned long		rate;
 	unsigned long		new_rate;
+	struct clk		*new_parent;
+	struct clk		*new_child;
 	unsigned long		flags;
 	unsigned int		enable_count;
 	unsigned int		prepare_count;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index e54dac5..d37e518 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -79,6 +79,10 @@ struct clk_hw;
  * @round_rate:	Given a target rate as input, returns the closest rate actually
  * 		supported by the clock.
  *
+ * @determine_rate: Given a target rate as input, returns the closest rate
+ *		actually supported by the clock, and optionally the parent clock
+ *		that should be used to provide the clock rate.
+ *
  * @get_parent:	Queries the hardware to determine the parent of a clock.  The
  * 		return value is a u8 which specifies the index corresponding to
  * 		the parent clock.  This index can be applied to either the
@@ -126,6 +130,9 @@ struct clk_ops {
 					unsigned long parent_rate);
 	long		(*round_rate)(struct clk_hw *hw, unsigned long,
 					unsigned long *);
+	long		(*determine_rate)(struct clk_hw *hw, unsigned long rate,
+					unsigned long *best_parent_rate,
+					struct clk **best_parent_clk);
 	int		(*set_parent)(struct clk_hw *hw, u8 index);
 	u8		(*get_parent)(struct clk_hw *hw);
 	int		(*set_rate)(struct clk_hw *hw, unsigned long,
-- 
1.8.1.2




From james.hogan at imgtec.com  Mon Jul 29 07:25:01 2013
From: james.hogan at imgtec.com (James Hogan)
Date: Mon, 29 Jul 2013 12:25:01 +0100
Subject: [PATCH v6 4/5] clk: add CLK_SET_RATE_NO_REPARENT flag
In-Reply-To: <1375097102-28892-1-git-send-email-james.hogan@imgtec.com>
References: <1375097102-28892-1-git-send-email-james.hogan@imgtec.com>
Message-ID: <1375097102-28892-5-git-send-email-james.hogan@imgtec.com>

Add a CLK_SET_RATE_NO_REPARENT clock flag, which will prevent muxes
being reparented during clk_set_rate.

To avoid breaking existing platforms, all callers of clk_register_mux()
are adjusted to pass the new flag. Platform maintainers are encouraged
to remove the flag if they wish to allow mux reparenting on set_rate.

Signed-off-by: James Hogan <james.hogan at imgtec.com>
Reviewed-by: Stephen Boyd <sboyd at codeaurora.org>
Cc: Mike Turquette <mturquette at linaro.org>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Sascha Hauer <kernel at pengutronix.de>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Cc: Viresh Kumar <viresh.linux at gmail.com>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: Haojian Zhuang <haojian.zhuang at linaro.org>
Cc: Chao Xie <xiechao.mail at gmail.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: "Emilio L?pez" <emilio at elopez.com.ar>
Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
Cc: Maxime Ripard <maxime.ripard at free-electrons.com>
Cc: Prashant Gaikwad <pgaikwad at nvidia.com>
Cc: Thierry Reding <thierry.reding at gmail.com>
Cc: Peter De Schrijver <pdeschrijver at nvidia.com>
Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Andrew Chew <achew at nvidia.com>
Cc: Doug Anderson <dianders at chromium.org>
Cc: Heiko Stuebner <heiko at sntech.de>
Cc: Paul Walmsley <pwalmsley at nvidia.com>
Cc: Soren Brinkmann <soren.brinkmann at xilinx.com>
Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>
Cc: Thomas Abraham <thomas.abraham at linaro.org>
Cc: Tomasz Figa <t.figa at samsung.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: spear-devel at list.st.com
Cc: linux-tegra at vger.kernel.org
Tested-by: Haojian Zhuang <haojian.zhuang at gmail.com>
Acked-by: Stephen Warren <swarren at nvidia.com> [tegra]
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com> [sunxi]
---
Changes in v6:

* Rebased on v3.11-rc1.
* Added changes to samsung/clk-exynos-audss.c, zynq/clkc.c.

Changes in v5:

* Rebased on latest clk-next ("clk: tegra: Use common of_clk_init
  function")

Changes in v3:

* rename/invert CLK_SET_RATE_REMUX to CLK_SET_RATE_NO_REPARENT and move
  to this new patch.
* patch 3: add CLK_SET_RATE_NO_REPARENT flag to all callers of
  clk_register_mux. If you don't mind your clocks being reparented in
  response to set_rate please let me know and I'll drop the relevant
  portion of the patch.

 arch/arm/mach-imx/clk.h                |   5 +-
 drivers/clk/mmp/clk-mmp2.c             |  39 ++++---
 drivers/clk/mmp/clk-pxa168.c           |  40 +++++---
 drivers/clk/mmp/clk-pxa910.c           |  31 ++++--
 drivers/clk/mxs/clk.h                  |   4 +-
 drivers/clk/samsung/clk-exynos-audss.c |   6 +-
 drivers/clk/samsung/clk.h              |   2 +-
 drivers/clk/spear/spear1310_clock.c    | 179 +++++++++++++++++----------------
 drivers/clk/spear/spear1340_clock.c    |  97 ++++++++++--------
 drivers/clk/spear/spear3xx_clock.c     |  57 +++++++----
 drivers/clk/spear/spear6xx_clock.c     |  35 ++++---
 drivers/clk/sunxi/clk-sunxi.c          |   3 +-
 drivers/clk/tegra/clk-tegra114.c       |  36 ++++---
 drivers/clk/tegra/clk-tegra20.c        |   6 +-
 drivers/clk/tegra/clk-tegra30.c        |  33 ++++--
 drivers/clk/versatile/clk-vexpress.c   |   4 +-
 drivers/clk/zynq/clkc.c                |  86 +++++++++-------
 include/linux/clk-provider.h           |   1 +
 18 files changed, 388 insertions(+), 276 deletions(-)

diff --git a/arch/arm/mach-imx/clk.h b/arch/arm/mach-imx/clk.h
index 0e4e8bb..c8575fb 100644
--- a/arch/arm/mach-imx/clk.h
+++ b/arch/arm/mach-imx/clk.h
@@ -79,7 +79,8 @@ static inline struct clk *imx_clk_gate(const char *name, const char *parent,
 static inline struct clk *imx_clk_mux(const char *name, void __iomem *reg,
 		u8 shift, u8 width, const char **parents, int num_parents)
 {
-	return clk_register_mux(NULL, name, parents, num_parents, 0, reg, shift,
+	return clk_register_mux(NULL, name, parents, num_parents,
+			CLK_SET_RATE_NO_REPARENT, reg, shift,
 			width, 0, &imx_ccm_lock);
 }
 
@@ -88,7 +89,7 @@ static inline struct clk *imx_clk_mux_flags(const char *name,
 		int num_parents, unsigned long flags)
 {
 	return clk_register_mux(NULL, name, parents, num_parents,
-			flags, reg, shift, width, 0,
+			flags | CLK_SET_RATE_NO_REPARENT, reg, shift, width, 0,
 			&imx_ccm_lock);
 }
 
diff --git a/drivers/clk/mmp/clk-mmp2.c b/drivers/clk/mmp/clk-mmp2.c
index d1f1a19..b2721ca 100644
--- a/drivers/clk/mmp/clk-mmp2.c
+++ b/drivers/clk/mmp/clk-mmp2.c
@@ -248,7 +248,8 @@ void __init mmp2_clk_init(void)
 	clk_register_clkdev(clk, NULL, "mmp2-pwm.3");
 
 	clk = clk_register_mux(NULL, "uart0_mux", uart_parent,
-				ARRAY_SIZE(uart_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(uart_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_UART0, 4, 3, 0, &clk_lock);
 	clk_set_parent(clk, vctcxo);
 	clk_register_clkdev(clk, "uart_mux.0", NULL);
@@ -258,7 +259,8 @@ void __init mmp2_clk_init(void)
 	clk_register_clkdev(clk, NULL, "pxa2xx-uart.0");
 
 	clk = clk_register_mux(NULL, "uart1_mux", uart_parent,
-				ARRAY_SIZE(uart_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(uart_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_UART1, 4, 3, 0, &clk_lock);
 	clk_set_parent(clk, vctcxo);
 	clk_register_clkdev(clk, "uart_mux.1", NULL);
@@ -268,7 +270,8 @@ void __init mmp2_clk_init(void)
 	clk_register_clkdev(clk, NULL, "pxa2xx-uart.1");
 
 	clk = clk_register_mux(NULL, "uart2_mux", uart_parent,
-				ARRAY_SIZE(uart_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(uart_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_UART2, 4, 3, 0, &clk_lock);
 	clk_set_parent(clk, vctcxo);
 	clk_register_clkdev(clk, "uart_mux.2", NULL);
@@ -278,7 +281,8 @@ void __init mmp2_clk_init(void)
 	clk_register_clkdev(clk, NULL, "pxa2xx-uart.2");
 
 	clk = clk_register_mux(NULL, "uart3_mux", uart_parent,
-				ARRAY_SIZE(uart_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(uart_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_UART3, 4, 3, 0, &clk_lock);
 	clk_set_parent(clk, vctcxo);
 	clk_register_clkdev(clk, "uart_mux.3", NULL);
@@ -288,7 +292,8 @@ void __init mmp2_clk_init(void)
 	clk_register_clkdev(clk, NULL, "pxa2xx-uart.3");
 
 	clk = clk_register_mux(NULL, "ssp0_mux", ssp_parent,
-				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ssp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_SSP0, 4, 3, 0, &clk_lock);
 	clk_register_clkdev(clk, "uart_mux.0", NULL);
 
@@ -297,7 +302,8 @@ void __init mmp2_clk_init(void)
 	clk_register_clkdev(clk, NULL, "mmp-ssp.0");
 
 	clk = clk_register_mux(NULL, "ssp1_mux", ssp_parent,
-				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ssp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_SSP1, 4, 3, 0, &clk_lock);
 	clk_register_clkdev(clk, "ssp_mux.1", NULL);
 
@@ -306,7 +312,8 @@ void __init mmp2_clk_init(void)
 	clk_register_clkdev(clk, NULL, "mmp-ssp.1");
 
 	clk = clk_register_mux(NULL, "ssp2_mux", ssp_parent,
-				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ssp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_SSP2, 4, 3, 0, &clk_lock);
 	clk_register_clkdev(clk, "ssp_mux.2", NULL);
 
@@ -315,7 +322,8 @@ void __init mmp2_clk_init(void)
 	clk_register_clkdev(clk, NULL, "mmp-ssp.2");
 
 	clk = clk_register_mux(NULL, "ssp3_mux", ssp_parent,
-				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ssp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_SSP3, 4, 3, 0, &clk_lock);
 	clk_register_clkdev(clk, "ssp_mux.3", NULL);
 
@@ -324,7 +332,8 @@ void __init mmp2_clk_init(void)
 	clk_register_clkdev(clk, NULL, "mmp-ssp.3");
 
 	clk = clk_register_mux(NULL, "sdh_mux", sdh_parent,
-				ARRAY_SIZE(sdh_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(sdh_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apmu_base + APMU_SDH0, 8, 2, 0, &clk_lock);
 	clk_register_clkdev(clk, "sdh_mux", NULL);
 
@@ -354,7 +363,8 @@ void __init mmp2_clk_init(void)
 	clk_register_clkdev(clk, "usb_clk", NULL);
 
 	clk = clk_register_mux(NULL, "disp0_mux", disp_parent,
-				ARRAY_SIZE(disp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(disp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apmu_base + APMU_DISP0, 6, 2, 0, &clk_lock);
 	clk_register_clkdev(clk, "disp_mux.0", NULL);
 
@@ -376,7 +386,8 @@ void __init mmp2_clk_init(void)
 	clk_register_clkdev(clk, "disp_sphy.0", NULL);
 
 	clk = clk_register_mux(NULL, "disp1_mux", disp_parent,
-				ARRAY_SIZE(disp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(disp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apmu_base + APMU_DISP1, 6, 2, 0, &clk_lock);
 	clk_register_clkdev(clk, "disp_mux.1", NULL);
 
@@ -394,7 +405,8 @@ void __init mmp2_clk_init(void)
 	clk_register_clkdev(clk, "ccic_arbiter", NULL);
 
 	clk = clk_register_mux(NULL, "ccic0_mux", ccic_parent,
-				ARRAY_SIZE(ccic_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ccic_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apmu_base + APMU_CCIC0, 6, 2, 0, &clk_lock);
 	clk_register_clkdev(clk, "ccic_mux.0", NULL);
 
@@ -421,7 +433,8 @@ void __init mmp2_clk_init(void)
 	clk_register_clkdev(clk, "sphyclk", "mmp-ccic.0");
 
 	clk = clk_register_mux(NULL, "ccic1_mux", ccic_parent,
-				ARRAY_SIZE(ccic_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ccic_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apmu_base + APMU_CCIC1, 6, 2, 0, &clk_lock);
 	clk_register_clkdev(clk, "ccic_mux.1", NULL);
 
diff --git a/drivers/clk/mmp/clk-pxa168.c b/drivers/clk/mmp/clk-pxa168.c
index 28b3b51..014396b 100644
--- a/drivers/clk/mmp/clk-pxa168.c
+++ b/drivers/clk/mmp/clk-pxa168.c
@@ -199,7 +199,8 @@ void __init pxa168_clk_init(void)
 	clk_register_clkdev(clk, NULL, "pxa168-pwm.3");
 
 	clk = clk_register_mux(NULL, "uart0_mux", uart_parent,
-				ARRAY_SIZE(uart_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(uart_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_UART0, 4, 3, 0, &clk_lock);
 	clk_set_parent(clk, uart_pll);
 	clk_register_clkdev(clk, "uart_mux.0", NULL);
@@ -209,7 +210,8 @@ void __init pxa168_clk_init(void)
 	clk_register_clkdev(clk, NULL, "pxa2xx-uart.0");
 
 	clk = clk_register_mux(NULL, "uart1_mux", uart_parent,
-				ARRAY_SIZE(uart_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(uart_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_UART1, 4, 3, 0, &clk_lock);
 	clk_set_parent(clk, uart_pll);
 	clk_register_clkdev(clk, "uart_mux.1", NULL);
@@ -219,7 +221,8 @@ void __init pxa168_clk_init(void)
 	clk_register_clkdev(clk, NULL, "pxa2xx-uart.1");
 
 	clk = clk_register_mux(NULL, "uart2_mux", uart_parent,
-				ARRAY_SIZE(uart_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(uart_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_UART2, 4, 3, 0, &clk_lock);
 	clk_set_parent(clk, uart_pll);
 	clk_register_clkdev(clk, "uart_mux.2", NULL);
@@ -229,7 +232,8 @@ void __init pxa168_clk_init(void)
 	clk_register_clkdev(clk, NULL, "pxa2xx-uart.2");
 
 	clk = clk_register_mux(NULL, "ssp0_mux", ssp_parent,
-				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ssp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_SSP0, 4, 3, 0, &clk_lock);
 	clk_register_clkdev(clk, "uart_mux.0", NULL);
 
@@ -238,7 +242,8 @@ void __init pxa168_clk_init(void)
 	clk_register_clkdev(clk, NULL, "mmp-ssp.0");
 
 	clk = clk_register_mux(NULL, "ssp1_mux", ssp_parent,
-				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ssp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_SSP1, 4, 3, 0, &clk_lock);
 	clk_register_clkdev(clk, "ssp_mux.1", NULL);
 
@@ -247,7 +252,8 @@ void __init pxa168_clk_init(void)
 	clk_register_clkdev(clk, NULL, "mmp-ssp.1");
 
 	clk = clk_register_mux(NULL, "ssp2_mux", ssp_parent,
-				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ssp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_SSP2, 4, 3, 0, &clk_lock);
 	clk_register_clkdev(clk, "ssp_mux.2", NULL);
 
@@ -256,7 +262,8 @@ void __init pxa168_clk_init(void)
 	clk_register_clkdev(clk, NULL, "mmp-ssp.2");
 
 	clk = clk_register_mux(NULL, "ssp3_mux", ssp_parent,
-				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ssp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_SSP3, 4, 3, 0, &clk_lock);
 	clk_register_clkdev(clk, "ssp_mux.3", NULL);
 
@@ -265,7 +272,8 @@ void __init pxa168_clk_init(void)
 	clk_register_clkdev(clk, NULL, "mmp-ssp.3");
 
 	clk = clk_register_mux(NULL, "ssp4_mux", ssp_parent,
-				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ssp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_SSP4, 4, 3, 0, &clk_lock);
 	clk_register_clkdev(clk, "ssp_mux.4", NULL);
 
@@ -278,7 +286,8 @@ void __init pxa168_clk_init(void)
 	clk_register_clkdev(clk, NULL, "pxa3xx-nand.0");
 
 	clk = clk_register_mux(NULL, "sdh0_mux", sdh_parent,
-				ARRAY_SIZE(sdh_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(sdh_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apmu_base + APMU_SDH0, 6, 1, 0, &clk_lock);
 	clk_register_clkdev(clk, "sdh0_mux", NULL);
 
@@ -287,7 +296,8 @@ void __init pxa168_clk_init(void)
 	clk_register_clkdev(clk, NULL, "sdhci-pxa.0");
 
 	clk = clk_register_mux(NULL, "sdh1_mux", sdh_parent,
-				ARRAY_SIZE(sdh_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(sdh_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apmu_base + APMU_SDH1, 6, 1, 0, &clk_lock);
 	clk_register_clkdev(clk, "sdh1_mux", NULL);
 
@@ -304,7 +314,8 @@ void __init pxa168_clk_init(void)
 	clk_register_clkdev(clk, "sph_clk", NULL);
 
 	clk = clk_register_mux(NULL, "disp0_mux", disp_parent,
-				ARRAY_SIZE(disp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(disp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apmu_base + APMU_DISP0, 6, 1, 0, &clk_lock);
 	clk_register_clkdev(clk, "disp_mux.0", NULL);
 
@@ -317,7 +328,8 @@ void __init pxa168_clk_init(void)
 	clk_register_clkdev(clk, "hclk", "mmp-disp.0");
 
 	clk = clk_register_mux(NULL, "ccic0_mux", ccic_parent,
-				ARRAY_SIZE(ccic_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ccic_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apmu_base + APMU_CCIC0, 6, 1, 0, &clk_lock);
 	clk_register_clkdev(clk, "ccic_mux.0", NULL);
 
@@ -327,8 +339,8 @@ void __init pxa168_clk_init(void)
 
 	clk = clk_register_mux(NULL, "ccic0_phy_mux", ccic_phy_parent,
 				ARRAY_SIZE(ccic_phy_parent),
-				CLK_SET_RATE_PARENT, apmu_base + APMU_CCIC0,
-				7, 1, 0, &clk_lock);
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
+				apmu_base + APMU_CCIC0, 7, 1, 0, &clk_lock);
 	clk_register_clkdev(clk, "ccic_phy_mux.0", NULL);
 
 	clk = mmp_clk_register_apmu("ccic0_phy", "ccic0_phy_mux",
diff --git a/drivers/clk/mmp/clk-pxa910.c b/drivers/clk/mmp/clk-pxa910.c
index 6ec0569..9efc6a4 100644
--- a/drivers/clk/mmp/clk-pxa910.c
+++ b/drivers/clk/mmp/clk-pxa910.c
@@ -204,7 +204,8 @@ void __init pxa910_clk_init(void)
 	clk_register_clkdev(clk, NULL, "pxa910-pwm.3");
 
 	clk = clk_register_mux(NULL, "uart0_mux", uart_parent,
-				ARRAY_SIZE(uart_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(uart_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_UART0, 4, 3, 0, &clk_lock);
 	clk_set_parent(clk, uart_pll);
 	clk_register_clkdev(clk, "uart_mux.0", NULL);
@@ -214,7 +215,8 @@ void __init pxa910_clk_init(void)
 	clk_register_clkdev(clk, NULL, "pxa2xx-uart.0");
 
 	clk = clk_register_mux(NULL, "uart1_mux", uart_parent,
-				ARRAY_SIZE(uart_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(uart_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_UART1, 4, 3, 0, &clk_lock);
 	clk_set_parent(clk, uart_pll);
 	clk_register_clkdev(clk, "uart_mux.1", NULL);
@@ -224,7 +226,8 @@ void __init pxa910_clk_init(void)
 	clk_register_clkdev(clk, NULL, "pxa2xx-uart.1");
 
 	clk = clk_register_mux(NULL, "uart2_mux", uart_parent,
-				ARRAY_SIZE(uart_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(uart_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbcp_base + APBCP_UART2, 4, 3, 0, &clk_lock);
 	clk_set_parent(clk, uart_pll);
 	clk_register_clkdev(clk, "uart_mux.2", NULL);
@@ -234,7 +237,8 @@ void __init pxa910_clk_init(void)
 	clk_register_clkdev(clk, NULL, "pxa2xx-uart.2");
 
 	clk = clk_register_mux(NULL, "ssp0_mux", ssp_parent,
-				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ssp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_SSP0, 4, 3, 0, &clk_lock);
 	clk_register_clkdev(clk, "uart_mux.0", NULL);
 
@@ -243,7 +247,8 @@ void __init pxa910_clk_init(void)
 	clk_register_clkdev(clk, NULL, "mmp-ssp.0");
 
 	clk = clk_register_mux(NULL, "ssp1_mux", ssp_parent,
-				ARRAY_SIZE(ssp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ssp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apbc_base + APBC_SSP1, 4, 3, 0, &clk_lock);
 	clk_register_clkdev(clk, "ssp_mux.1", NULL);
 
@@ -256,7 +261,8 @@ void __init pxa910_clk_init(void)
 	clk_register_clkdev(clk, NULL, "pxa3xx-nand.0");
 
 	clk = clk_register_mux(NULL, "sdh0_mux", sdh_parent,
-				ARRAY_SIZE(sdh_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(sdh_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apmu_base + APMU_SDH0, 6, 1, 0, &clk_lock);
 	clk_register_clkdev(clk, "sdh0_mux", NULL);
 
@@ -265,7 +271,8 @@ void __init pxa910_clk_init(void)
 	clk_register_clkdev(clk, NULL, "sdhci-pxa.0");
 
 	clk = clk_register_mux(NULL, "sdh1_mux", sdh_parent,
-				ARRAY_SIZE(sdh_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(sdh_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apmu_base + APMU_SDH1, 6, 1, 0, &clk_lock);
 	clk_register_clkdev(clk, "sdh1_mux", NULL);
 
@@ -282,7 +289,8 @@ void __init pxa910_clk_init(void)
 	clk_register_clkdev(clk, "sph_clk", NULL);
 
 	clk = clk_register_mux(NULL, "disp0_mux", disp_parent,
-				ARRAY_SIZE(disp_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(disp_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apmu_base + APMU_DISP0, 6, 1, 0, &clk_lock);
 	clk_register_clkdev(clk, "disp_mux.0", NULL);
 
@@ -291,7 +299,8 @@ void __init pxa910_clk_init(void)
 	clk_register_clkdev(clk, NULL, "mmp-disp.0");
 
 	clk = clk_register_mux(NULL, "ccic0_mux", ccic_parent,
-				ARRAY_SIZE(ccic_parent), CLK_SET_RATE_PARENT,
+				ARRAY_SIZE(ccic_parent),
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 				apmu_base + APMU_CCIC0, 6, 1, 0, &clk_lock);
 	clk_register_clkdev(clk, "ccic_mux.0", NULL);
 
@@ -301,8 +310,8 @@ void __init pxa910_clk_init(void)
 
 	clk = clk_register_mux(NULL, "ccic0_phy_mux", ccic_phy_parent,
 				ARRAY_SIZE(ccic_phy_parent),
-				CLK_SET_RATE_PARENT, apmu_base + APMU_CCIC0,
-				7, 1, 0, &clk_lock);
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
+				apmu_base + APMU_CCIC0, 7, 1, 0, &clk_lock);
 	clk_register_clkdev(clk, "ccic_phy_mux.0", NULL);
 
 	clk = mmp_clk_register_apmu("ccic0_phy", "ccic0_phy_mux",
diff --git a/drivers/clk/mxs/clk.h b/drivers/clk/mxs/clk.h
index 81421e2..ef10ad9 100644
--- a/drivers/clk/mxs/clk.h
+++ b/drivers/clk/mxs/clk.h
@@ -52,8 +52,8 @@ static inline struct clk *mxs_clk_mux(const char *name, void __iomem *reg,
 		u8 shift, u8 width, const char **parent_names, int num_parents)
 {
 	return clk_register_mux(NULL, name, parent_names, num_parents,
-				CLK_SET_RATE_PARENT, reg, shift, width,
-				0, &mxs_lock);
+				CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
+				reg, shift, width, 0, &mxs_lock);
 }
 
 static inline struct clk *mxs_clk_fixed_factor(const char *name,
diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
index 9b1bbd5..50af9f7 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -82,11 +82,13 @@ void __init exynos_audss_clk_init(struct device_node *np)
 	of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
 
 	clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, "mout_audss",
-				mout_audss_p, ARRAY_SIZE(mout_audss_p), 0,
+				mout_audss_p, ARRAY_SIZE(mout_audss_p),
+				CLK_SET_RATE_NO_REPARENT,
 				reg_base + ASS_CLK_SRC, 0, 1, 0, &lock);
 
 	clk_table[EXYNOS_MOUT_I2S] = clk_register_mux(NULL, "mout_i2s",
-				mout_i2s_p, ARRAY_SIZE(mout_i2s_p), 0,
+				mout_i2s_p, ARRAY_SIZE(mout_i2s_p),
+				CLK_SET_RATE_NO_REPARENT,
 				reg_base + ASS_CLK_SRC, 2, 2, 0, &lock);
 
 	clk_table[EXYNOS_DOUT_SRP] = clk_register_divider(NULL, "dout_srp",
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index 2f7dba2..2613c91a 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -127,7 +127,7 @@ struct samsung_mux_clock {
 		.name		= cname,			\
 		.parent_names	= pnames,			\
 		.num_parents	= ARRAY_SIZE(pnames),		\
-		.flags		= f,				\
+		.flags		= (f) | CLK_SET_RATE_NO_REPARENT, \
 		.offset		= o,				\
 		.shift		= s,				\
 		.width		= w,				\
diff --git a/drivers/clk/spear/spear1310_clock.c b/drivers/clk/spear/spear1310_clock.c
index aedbbe1..65894f7 100644
--- a/drivers/clk/spear/spear1310_clock.c
+++ b/drivers/clk/spear/spear1310_clock.c
@@ -416,9 +416,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	/* clock derived from 24 or 25 MHz osc clk */
 	/* vco-pll */
 	clk = clk_register_mux(NULL, "vco1_mclk", vco_parents,
-			ARRAY_SIZE(vco_parents), 0, SPEAR1310_PLL_CFG,
-			SPEAR1310_PLL1_CLK_SHIFT, SPEAR1310_PLL_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(vco_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_PLL_CFG, SPEAR1310_PLL1_CLK_SHIFT,
+			SPEAR1310_PLL_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "vco1_mclk", NULL);
 	clk = clk_register_vco_pll("vco1_clk", "pll1_clk", NULL, "vco1_mclk",
 			0, SPEAR1310_PLL1_CTR, SPEAR1310_PLL1_FRQ, pll_rtbl,
@@ -427,9 +427,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk1, "pll1_clk", NULL);
 
 	clk = clk_register_mux(NULL, "vco2_mclk", vco_parents,
-			ARRAY_SIZE(vco_parents), 0, SPEAR1310_PLL_CFG,
-			SPEAR1310_PLL2_CLK_SHIFT, SPEAR1310_PLL_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(vco_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_PLL_CFG, SPEAR1310_PLL2_CLK_SHIFT,
+			SPEAR1310_PLL_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "vco2_mclk", NULL);
 	clk = clk_register_vco_pll("vco2_clk", "pll2_clk", NULL, "vco2_mclk",
 			0, SPEAR1310_PLL2_CTR, SPEAR1310_PLL2_FRQ, pll_rtbl,
@@ -438,9 +438,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk1, "pll2_clk", NULL);
 
 	clk = clk_register_mux(NULL, "vco3_mclk", vco_parents,
-			ARRAY_SIZE(vco_parents), 0, SPEAR1310_PLL_CFG,
-			SPEAR1310_PLL3_CLK_SHIFT, SPEAR1310_PLL_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(vco_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_PLL_CFG, SPEAR1310_PLL3_CLK_SHIFT,
+			SPEAR1310_PLL_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "vco3_mclk", NULL);
 	clk = clk_register_vco_pll("vco3_clk", "pll3_clk", NULL, "vco3_mclk",
 			0, SPEAR1310_PLL3_CTR, SPEAR1310_PLL3_FRQ, pll_rtbl,
@@ -515,9 +515,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 
 	/* gpt clocks */
 	clk = clk_register_mux(NULL, "gpt0_mclk", gpt_parents,
-			ARRAY_SIZE(gpt_parents), 0, SPEAR1310_PERIP_CLK_CFG,
-			SPEAR1310_GPT0_CLK_SHIFT, SPEAR1310_GPT_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(gpt_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_PERIP_CLK_CFG, SPEAR1310_GPT0_CLK_SHIFT,
+			SPEAR1310_GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gpt0_mclk", NULL);
 	clk = clk_register_gate(NULL, "gpt0_clk", "gpt0_mclk", 0,
 			SPEAR1310_PERIP1_CLK_ENB, SPEAR1310_GPT0_CLK_ENB, 0,
@@ -525,9 +525,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "gpt0");
 
 	clk = clk_register_mux(NULL, "gpt1_mclk", gpt_parents,
-			ARRAY_SIZE(gpt_parents), 0, SPEAR1310_PERIP_CLK_CFG,
-			SPEAR1310_GPT1_CLK_SHIFT, SPEAR1310_GPT_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(gpt_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_PERIP_CLK_CFG, SPEAR1310_GPT1_CLK_SHIFT,
+			SPEAR1310_GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gpt1_mclk", NULL);
 	clk = clk_register_gate(NULL, "gpt1_clk", "gpt1_mclk", 0,
 			SPEAR1310_PERIP1_CLK_ENB, SPEAR1310_GPT1_CLK_ENB, 0,
@@ -535,9 +535,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "gpt1");
 
 	clk = clk_register_mux(NULL, "gpt2_mclk", gpt_parents,
-			ARRAY_SIZE(gpt_parents), 0, SPEAR1310_PERIP_CLK_CFG,
-			SPEAR1310_GPT2_CLK_SHIFT, SPEAR1310_GPT_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(gpt_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_PERIP_CLK_CFG, SPEAR1310_GPT2_CLK_SHIFT,
+			SPEAR1310_GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gpt2_mclk", NULL);
 	clk = clk_register_gate(NULL, "gpt2_clk", "gpt2_mclk", 0,
 			SPEAR1310_PERIP2_CLK_ENB, SPEAR1310_GPT2_CLK_ENB, 0,
@@ -545,9 +545,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "gpt2");
 
 	clk = clk_register_mux(NULL, "gpt3_mclk", gpt_parents,
-			ARRAY_SIZE(gpt_parents), 0, SPEAR1310_PERIP_CLK_CFG,
-			SPEAR1310_GPT3_CLK_SHIFT, SPEAR1310_GPT_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(gpt_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_PERIP_CLK_CFG, SPEAR1310_GPT3_CLK_SHIFT,
+			SPEAR1310_GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gpt3_mclk", NULL);
 	clk = clk_register_gate(NULL, "gpt3_clk", "gpt3_mclk", 0,
 			SPEAR1310_PERIP2_CLK_ENB, SPEAR1310_GPT3_CLK_ENB, 0,
@@ -562,7 +562,8 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk1, "uart_syn_gclk", NULL);
 
 	clk = clk_register_mux(NULL, "uart0_mclk", uart0_parents,
-			ARRAY_SIZE(uart0_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(uart0_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR1310_PERIP_CLK_CFG, SPEAR1310_UART_CLK_SHIFT,
 			SPEAR1310_UART_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "uart0_mclk", NULL);
@@ -602,7 +603,8 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk1, "c3_syn_gclk", NULL);
 
 	clk = clk_register_mux(NULL, "c3_mclk", c3_parents,
-			ARRAY_SIZE(c3_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(c3_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR1310_PERIP_CLK_CFG, SPEAR1310_C3_CLK_SHIFT,
 			SPEAR1310_C3_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "c3_mclk", NULL);
@@ -614,8 +616,8 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 
 	/* gmac */
 	clk = clk_register_mux(NULL, "phy_input_mclk", gmac_phy_input_parents,
-			ARRAY_SIZE(gmac_phy_input_parents), 0,
-			SPEAR1310_GMAC_CLK_CFG,
+			ARRAY_SIZE(gmac_phy_input_parents),
+			CLK_SET_RATE_NO_REPARENT, SPEAR1310_GMAC_CLK_CFG,
 			SPEAR1310_GMAC_PHY_INPUT_CLK_SHIFT,
 			SPEAR1310_GMAC_PHY_INPUT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "phy_input_mclk", NULL);
@@ -627,15 +629,16 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk1, "phy_syn_gclk", NULL);
 
 	clk = clk_register_mux(NULL, "phy_mclk", gmac_phy_parents,
-			ARRAY_SIZE(gmac_phy_parents), 0,
+			ARRAY_SIZE(gmac_phy_parents), CLK_SET_RATE_NO_REPARENT,
 			SPEAR1310_PERIP_CLK_CFG, SPEAR1310_GMAC_PHY_CLK_SHIFT,
 			SPEAR1310_GMAC_PHY_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "stmmacphy.0", NULL);
 
 	/* clcd */
 	clk = clk_register_mux(NULL, "clcd_syn_mclk", clcd_synth_parents,
-			ARRAY_SIZE(clcd_synth_parents), 0,
-			SPEAR1310_CLCD_CLK_SYNT, SPEAR1310_CLCD_SYNT_CLK_SHIFT,
+			ARRAY_SIZE(clcd_synth_parents),
+			CLK_SET_RATE_NO_REPARENT, SPEAR1310_CLCD_CLK_SYNT,
+			SPEAR1310_CLCD_SYNT_CLK_SHIFT,
 			SPEAR1310_CLCD_SYNT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "clcd_syn_mclk", NULL);
 
@@ -645,7 +648,8 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, "clcd_syn_clk", NULL);
 
 	clk = clk_register_mux(NULL, "clcd_pixel_mclk", clcd_pixel_parents,
-			ARRAY_SIZE(clcd_pixel_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(clcd_pixel_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR1310_PERIP_CLK_CFG, SPEAR1310_CLCD_CLK_SHIFT,
 			SPEAR1310_CLCD_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "clcd_pixel_mclk", NULL);
@@ -657,9 +661,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 
 	/* i2s */
 	clk = clk_register_mux(NULL, "i2s_src_mclk", i2s_src_parents,
-			ARRAY_SIZE(i2s_src_parents), 0, SPEAR1310_I2S_CLK_CFG,
-			SPEAR1310_I2S_SRC_CLK_SHIFT, SPEAR1310_I2S_SRC_CLK_MASK,
-			0, &_lock);
+			ARRAY_SIZE(i2s_src_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_I2S_CLK_CFG, SPEAR1310_I2S_SRC_CLK_SHIFT,
+			SPEAR1310_I2S_SRC_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "i2s_src_mclk", NULL);
 
 	clk = clk_register_aux("i2s_prs1_clk", NULL, "i2s_src_mclk", 0,
@@ -668,7 +672,8 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, "i2s_prs1_clk", NULL);
 
 	clk = clk_register_mux(NULL, "i2s_ref_mclk", i2s_ref_parents,
-			ARRAY_SIZE(i2s_ref_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(i2s_ref_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR1310_I2S_CLK_CFG, SPEAR1310_I2S_REF_SHIFT,
 			SPEAR1310_I2S_REF_SEL_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "i2s_ref_mclk", NULL);
@@ -806,13 +811,15 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 
 	/* RAS clks */
 	clk = clk_register_mux(NULL, "gen_syn0_1_mclk", gen_synth0_1_parents,
-			ARRAY_SIZE(gen_synth0_1_parents), 0, SPEAR1310_PLL_CFG,
+			ARRAY_SIZE(gen_synth0_1_parents),
+			CLK_SET_RATE_NO_REPARENT, SPEAR1310_PLL_CFG,
 			SPEAR1310_RAS_SYNT0_1_CLK_SHIFT,
 			SPEAR1310_RAS_SYNT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gen_syn0_1_clk", NULL);
 
 	clk = clk_register_mux(NULL, "gen_syn2_3_mclk", gen_synth2_3_parents,
-			ARRAY_SIZE(gen_synth2_3_parents), 0, SPEAR1310_PLL_CFG,
+			ARRAY_SIZE(gen_synth2_3_parents),
+			CLK_SET_RATE_NO_REPARENT, SPEAR1310_PLL_CFG,
 			SPEAR1310_RAS_SYNT2_3_CLK_SHIFT,
 			SPEAR1310_RAS_SYNT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gen_syn2_3_clk", NULL);
@@ -929,8 +936,8 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 
 	clk = clk_register_mux(NULL, "smii_rgmii_phy_mclk",
 			smii_rgmii_phy_parents,
-			ARRAY_SIZE(smii_rgmii_phy_parents), 0,
-			SPEAR1310_RAS_CTRL_REG1,
+			ARRAY_SIZE(smii_rgmii_phy_parents),
+			CLK_SET_RATE_NO_REPARENT, SPEAR1310_RAS_CTRL_REG1,
 			SPEAR1310_SMII_RGMII_PHY_CLK_SHIFT,
 			SPEAR1310_PHY_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "stmmacphy.1", NULL);
@@ -938,15 +945,15 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, "stmmacphy.4", NULL);
 
 	clk = clk_register_mux(NULL, "rmii_phy_mclk", rmii_phy_parents,
-			ARRAY_SIZE(rmii_phy_parents), 0,
+			ARRAY_SIZE(rmii_phy_parents), CLK_SET_RATE_NO_REPARENT,
 			SPEAR1310_RAS_CTRL_REG1, SPEAR1310_RMII_PHY_CLK_SHIFT,
 			SPEAR1310_PHY_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "stmmacphy.3", NULL);
 
 	clk = clk_register_mux(NULL, "uart1_mclk", uart_parents,
-			ARRAY_SIZE(uart_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_UART1_CLK_SHIFT, SPEAR1310_RAS_UART_CLK_MASK,
-			0, &_lock);
+			ARRAY_SIZE(uart_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_UART1_CLK_SHIFT,
+			SPEAR1310_RAS_UART_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "uart1_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "uart1_clk", "uart1_mclk", 0,
@@ -955,9 +962,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "5c800000.serial");
 
 	clk = clk_register_mux(NULL, "uart2_mclk", uart_parents,
-			ARRAY_SIZE(uart_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_UART2_CLK_SHIFT, SPEAR1310_RAS_UART_CLK_MASK,
-			0, &_lock);
+			ARRAY_SIZE(uart_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_UART2_CLK_SHIFT,
+			SPEAR1310_RAS_UART_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "uart2_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "uart2_clk", "uart2_mclk", 0,
@@ -966,9 +973,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "5c900000.serial");
 
 	clk = clk_register_mux(NULL, "uart3_mclk", uart_parents,
-			ARRAY_SIZE(uart_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_UART3_CLK_SHIFT, SPEAR1310_RAS_UART_CLK_MASK,
-			0, &_lock);
+			ARRAY_SIZE(uart_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_UART3_CLK_SHIFT,
+			SPEAR1310_RAS_UART_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "uart3_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "uart3_clk", "uart3_mclk", 0,
@@ -977,9 +984,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "5ca00000.serial");
 
 	clk = clk_register_mux(NULL, "uart4_mclk", uart_parents,
-			ARRAY_SIZE(uart_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_UART4_CLK_SHIFT, SPEAR1310_RAS_UART_CLK_MASK,
-			0, &_lock);
+			ARRAY_SIZE(uart_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_UART4_CLK_SHIFT,
+			SPEAR1310_RAS_UART_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "uart4_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "uart4_clk", "uart4_mclk", 0,
@@ -988,9 +995,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "5cb00000.serial");
 
 	clk = clk_register_mux(NULL, "uart5_mclk", uart_parents,
-			ARRAY_SIZE(uart_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_UART5_CLK_SHIFT, SPEAR1310_RAS_UART_CLK_MASK,
-			0, &_lock);
+			ARRAY_SIZE(uart_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_UART5_CLK_SHIFT,
+			SPEAR1310_RAS_UART_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "uart5_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "uart5_clk", "uart5_mclk", 0,
@@ -999,9 +1006,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "5cc00000.serial");
 
 	clk = clk_register_mux(NULL, "i2c1_mclk", i2c_parents,
-			ARRAY_SIZE(i2c_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_I2C1_CLK_SHIFT, SPEAR1310_I2C_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(i2c_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_I2C1_CLK_SHIFT,
+			SPEAR1310_I2C_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "i2c1_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "i2c1_clk", "i2c1_mclk", 0,
@@ -1010,9 +1017,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "5cd00000.i2c");
 
 	clk = clk_register_mux(NULL, "i2c2_mclk", i2c_parents,
-			ARRAY_SIZE(i2c_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_I2C2_CLK_SHIFT, SPEAR1310_I2C_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(i2c_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_I2C2_CLK_SHIFT,
+			SPEAR1310_I2C_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "i2c2_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "i2c2_clk", "i2c2_mclk", 0,
@@ -1021,9 +1028,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "5ce00000.i2c");
 
 	clk = clk_register_mux(NULL, "i2c3_mclk", i2c_parents,
-			ARRAY_SIZE(i2c_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_I2C3_CLK_SHIFT, SPEAR1310_I2C_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(i2c_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_I2C3_CLK_SHIFT,
+			SPEAR1310_I2C_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "i2c3_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "i2c3_clk", "i2c3_mclk", 0,
@@ -1032,9 +1039,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "5cf00000.i2c");
 
 	clk = clk_register_mux(NULL, "i2c4_mclk", i2c_parents,
-			ARRAY_SIZE(i2c_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_I2C4_CLK_SHIFT, SPEAR1310_I2C_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(i2c_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_I2C4_CLK_SHIFT,
+			SPEAR1310_I2C_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "i2c4_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "i2c4_clk", "i2c4_mclk", 0,
@@ -1043,9 +1050,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "5d000000.i2c");
 
 	clk = clk_register_mux(NULL, "i2c5_mclk", i2c_parents,
-			ARRAY_SIZE(i2c_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_I2C5_CLK_SHIFT, SPEAR1310_I2C_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(i2c_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_I2C5_CLK_SHIFT,
+			SPEAR1310_I2C_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "i2c5_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "i2c5_clk", "i2c5_mclk", 0,
@@ -1054,9 +1061,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "5d100000.i2c");
 
 	clk = clk_register_mux(NULL, "i2c6_mclk", i2c_parents,
-			ARRAY_SIZE(i2c_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_I2C6_CLK_SHIFT, SPEAR1310_I2C_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(i2c_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_I2C6_CLK_SHIFT,
+			SPEAR1310_I2C_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "i2c6_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "i2c6_clk", "i2c6_mclk", 0,
@@ -1065,9 +1072,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "5d200000.i2c");
 
 	clk = clk_register_mux(NULL, "i2c7_mclk", i2c_parents,
-			ARRAY_SIZE(i2c_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_I2C7_CLK_SHIFT, SPEAR1310_I2C_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(i2c_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_I2C7_CLK_SHIFT,
+			SPEAR1310_I2C_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "i2c7_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "i2c7_clk", "i2c7_mclk", 0,
@@ -1076,9 +1083,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "5d300000.i2c");
 
 	clk = clk_register_mux(NULL, "ssp1_mclk", ssp1_parents,
-			ARRAY_SIZE(ssp1_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_SSP1_CLK_SHIFT, SPEAR1310_SSP1_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(ssp1_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_SSP1_CLK_SHIFT,
+			SPEAR1310_SSP1_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "ssp1_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "ssp1_clk", "ssp1_mclk", 0,
@@ -1087,9 +1094,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "5d400000.spi");
 
 	clk = clk_register_mux(NULL, "pci_mclk", pci_parents,
-			ARRAY_SIZE(pci_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_PCI_CLK_SHIFT, SPEAR1310_PCI_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(pci_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_PCI_CLK_SHIFT,
+			SPEAR1310_PCI_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "pci_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "pci_clk", "pci_mclk", 0,
@@ -1098,9 +1105,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "pci");
 
 	clk = clk_register_mux(NULL, "tdm1_mclk", tdm_parents,
-			ARRAY_SIZE(tdm_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_TDM1_CLK_SHIFT, SPEAR1310_TDM_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(tdm_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_TDM1_CLK_SHIFT,
+			SPEAR1310_TDM_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "tdm1_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "tdm1_clk", "tdm1_mclk", 0,
@@ -1109,9 +1116,9 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
 	clk_register_clkdev(clk, NULL, "tdm_hdlc.0");
 
 	clk = clk_register_mux(NULL, "tdm2_mclk", tdm_parents,
-			ARRAY_SIZE(tdm_parents), 0, SPEAR1310_RAS_CTRL_REG0,
-			SPEAR1310_TDM2_CLK_SHIFT, SPEAR1310_TDM_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(tdm_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1310_RAS_CTRL_REG0, SPEAR1310_TDM2_CLK_SHIFT,
+			SPEAR1310_TDM_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "tdm2_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "tdm2_clk", "tdm2_mclk", 0,
diff --git a/drivers/clk/spear/spear1340_clock.c b/drivers/clk/spear/spear1340_clock.c
index 9d0b394..fe835c1 100644
--- a/drivers/clk/spear/spear1340_clock.c
+++ b/drivers/clk/spear/spear1340_clock.c
@@ -473,9 +473,9 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	/* clock derived from 24 or 25 MHz osc clk */
 	/* vco-pll */
 	clk = clk_register_mux(NULL, "vco1_mclk", vco_parents,
-			ARRAY_SIZE(vco_parents), 0, SPEAR1340_PLL_CFG,
-			SPEAR1340_PLL1_CLK_SHIFT, SPEAR1340_PLL_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(vco_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1340_PLL_CFG, SPEAR1340_PLL1_CLK_SHIFT,
+			SPEAR1340_PLL_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "vco1_mclk", NULL);
 	clk = clk_register_vco_pll("vco1_clk", "pll1_clk", NULL, "vco1_mclk", 0,
 			SPEAR1340_PLL1_CTR, SPEAR1340_PLL1_FRQ, pll_rtbl,
@@ -484,9 +484,9 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk1, "pll1_clk", NULL);
 
 	clk = clk_register_mux(NULL, "vco2_mclk", vco_parents,
-			ARRAY_SIZE(vco_parents), 0, SPEAR1340_PLL_CFG,
-			SPEAR1340_PLL2_CLK_SHIFT, SPEAR1340_PLL_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(vco_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1340_PLL_CFG, SPEAR1340_PLL2_CLK_SHIFT,
+			SPEAR1340_PLL_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "vco2_mclk", NULL);
 	clk = clk_register_vco_pll("vco2_clk", "pll2_clk", NULL, "vco2_mclk", 0,
 			SPEAR1340_PLL2_CTR, SPEAR1340_PLL2_FRQ, pll_rtbl,
@@ -495,9 +495,9 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk1, "pll2_clk", NULL);
 
 	clk = clk_register_mux(NULL, "vco3_mclk", vco_parents,
-			ARRAY_SIZE(vco_parents), 0, SPEAR1340_PLL_CFG,
-			SPEAR1340_PLL3_CLK_SHIFT, SPEAR1340_PLL_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(vco_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1340_PLL_CFG, SPEAR1340_PLL3_CLK_SHIFT,
+			SPEAR1340_PLL_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "vco3_mclk", NULL);
 	clk = clk_register_vco_pll("vco3_clk", "pll3_clk", NULL, "vco3_mclk", 0,
 			SPEAR1340_PLL3_CTR, SPEAR1340_PLL3_FRQ, pll_rtbl,
@@ -561,8 +561,8 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk, "amba_syn_clk", NULL);
 
 	clk = clk_register_mux(NULL, "sys_mclk", sys_parents,
-			ARRAY_SIZE(sys_parents), 0, SPEAR1340_SYS_CLK_CTRL,
-			SPEAR1340_SCLK_SRC_SEL_SHIFT,
+			ARRAY_SIZE(sys_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1340_SYS_CLK_CTRL, SPEAR1340_SCLK_SRC_SEL_SHIFT,
 			SPEAR1340_SCLK_SRC_SEL_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "sys_mclk", NULL);
 
@@ -583,8 +583,8 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk, NULL, "smp_twd");
 
 	clk = clk_register_mux(NULL, "ahb_clk", ahb_parents,
-			ARRAY_SIZE(ahb_parents), 0, SPEAR1340_SYS_CLK_CTRL,
-			SPEAR1340_HCLK_SRC_SEL_SHIFT,
+			ARRAY_SIZE(ahb_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1340_SYS_CLK_CTRL, SPEAR1340_HCLK_SRC_SEL_SHIFT,
 			SPEAR1340_HCLK_SRC_SEL_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "ahb_clk", NULL);
 
@@ -594,9 +594,9 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 
 	/* gpt clocks */
 	clk = clk_register_mux(NULL, "gpt0_mclk", gpt_parents,
-			ARRAY_SIZE(gpt_parents), 0, SPEAR1340_PERIP_CLK_CFG,
-			SPEAR1340_GPT0_CLK_SHIFT, SPEAR1340_GPT_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(gpt_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1340_PERIP_CLK_CFG, SPEAR1340_GPT0_CLK_SHIFT,
+			SPEAR1340_GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gpt0_mclk", NULL);
 	clk = clk_register_gate(NULL, "gpt0_clk", "gpt0_mclk", 0,
 			SPEAR1340_PERIP1_CLK_ENB, SPEAR1340_GPT0_CLK_ENB, 0,
@@ -604,9 +604,9 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk, NULL, "gpt0");
 
 	clk = clk_register_mux(NULL, "gpt1_mclk", gpt_parents,
-			ARRAY_SIZE(gpt_parents), 0, SPEAR1340_PERIP_CLK_CFG,
-			SPEAR1340_GPT1_CLK_SHIFT, SPEAR1340_GPT_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(gpt_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1340_PERIP_CLK_CFG, SPEAR1340_GPT1_CLK_SHIFT,
+			SPEAR1340_GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gpt1_mclk", NULL);
 	clk = clk_register_gate(NULL, "gpt1_clk", "gpt1_mclk", 0,
 			SPEAR1340_PERIP1_CLK_ENB, SPEAR1340_GPT1_CLK_ENB, 0,
@@ -614,9 +614,9 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk, NULL, "gpt1");
 
 	clk = clk_register_mux(NULL, "gpt2_mclk", gpt_parents,
-			ARRAY_SIZE(gpt_parents), 0, SPEAR1340_PERIP_CLK_CFG,
-			SPEAR1340_GPT2_CLK_SHIFT, SPEAR1340_GPT_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(gpt_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1340_PERIP_CLK_CFG, SPEAR1340_GPT2_CLK_SHIFT,
+			SPEAR1340_GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gpt2_mclk", NULL);
 	clk = clk_register_gate(NULL, "gpt2_clk", "gpt2_mclk", 0,
 			SPEAR1340_PERIP2_CLK_ENB, SPEAR1340_GPT2_CLK_ENB, 0,
@@ -624,9 +624,9 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk, NULL, "gpt2");
 
 	clk = clk_register_mux(NULL, "gpt3_mclk", gpt_parents,
-			ARRAY_SIZE(gpt_parents), 0, SPEAR1340_PERIP_CLK_CFG,
-			SPEAR1340_GPT3_CLK_SHIFT, SPEAR1340_GPT_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(gpt_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1340_PERIP_CLK_CFG, SPEAR1340_GPT3_CLK_SHIFT,
+			SPEAR1340_GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gpt3_mclk", NULL);
 	clk = clk_register_gate(NULL, "gpt3_clk", "gpt3_mclk", 0,
 			SPEAR1340_PERIP2_CLK_ENB, SPEAR1340_GPT3_CLK_ENB, 0,
@@ -641,7 +641,8 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk1, "uart0_syn_gclk", NULL);
 
 	clk = clk_register_mux(NULL, "uart0_mclk", uart0_parents,
-			ARRAY_SIZE(uart0_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(uart0_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR1340_PERIP_CLK_CFG, SPEAR1340_UART0_CLK_SHIFT,
 			SPEAR1340_UART_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "uart0_mclk", NULL);
@@ -658,9 +659,9 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk1, "uart1_syn_gclk", NULL);
 
 	clk = clk_register_mux(NULL, "uart1_mclk", uart1_parents,
-			ARRAY_SIZE(uart1_parents), 0, SPEAR1340_PERIP_CLK_CFG,
-			SPEAR1340_UART1_CLK_SHIFT, SPEAR1340_UART_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(uart1_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1340_PERIP_CLK_CFG, SPEAR1340_UART1_CLK_SHIFT,
+			SPEAR1340_UART_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "uart1_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "uart1_clk", "uart1_mclk", 0,
@@ -698,7 +699,8 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk1, "c3_syn_gclk", NULL);
 
 	clk = clk_register_mux(NULL, "c3_mclk", c3_parents,
-			ARRAY_SIZE(c3_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(c3_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR1340_PERIP_CLK_CFG, SPEAR1340_C3_CLK_SHIFT,
 			SPEAR1340_C3_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "c3_mclk", NULL);
@@ -710,8 +712,8 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 
 	/* gmac */
 	clk = clk_register_mux(NULL, "phy_input_mclk", gmac_phy_input_parents,
-			ARRAY_SIZE(gmac_phy_input_parents), 0,
-			SPEAR1340_GMAC_CLK_CFG,
+			ARRAY_SIZE(gmac_phy_input_parents),
+			CLK_SET_RATE_NO_REPARENT, SPEAR1340_GMAC_CLK_CFG,
 			SPEAR1340_GMAC_PHY_INPUT_CLK_SHIFT,
 			SPEAR1340_GMAC_PHY_INPUT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "phy_input_mclk", NULL);
@@ -723,15 +725,16 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk1, "phy_syn_gclk", NULL);
 
 	clk = clk_register_mux(NULL, "phy_mclk", gmac_phy_parents,
-			ARRAY_SIZE(gmac_phy_parents), 0,
+			ARRAY_SIZE(gmac_phy_parents), CLK_SET_RATE_NO_REPARENT,
 			SPEAR1340_PERIP_CLK_CFG, SPEAR1340_GMAC_PHY_CLK_SHIFT,
 			SPEAR1340_GMAC_PHY_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "stmmacphy.0", NULL);
 
 	/* clcd */
 	clk = clk_register_mux(NULL, "clcd_syn_mclk", clcd_synth_parents,
-			ARRAY_SIZE(clcd_synth_parents), 0,
-			SPEAR1340_CLCD_CLK_SYNT, SPEAR1340_CLCD_SYNT_CLK_SHIFT,
+			ARRAY_SIZE(clcd_synth_parents),
+			CLK_SET_RATE_NO_REPARENT, SPEAR1340_CLCD_CLK_SYNT,
+			SPEAR1340_CLCD_SYNT_CLK_SHIFT,
 			SPEAR1340_CLCD_SYNT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "clcd_syn_mclk", NULL);
 
@@ -741,7 +744,8 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk, "clcd_syn_clk", NULL);
 
 	clk = clk_register_mux(NULL, "clcd_pixel_mclk", clcd_pixel_parents,
-			ARRAY_SIZE(clcd_pixel_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(clcd_pixel_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR1340_PERIP_CLK_CFG, SPEAR1340_CLCD_CLK_SHIFT,
 			SPEAR1340_CLCD_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "clcd_pixel_mclk", NULL);
@@ -753,9 +757,9 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 
 	/* i2s */
 	clk = clk_register_mux(NULL, "i2s_src_mclk", i2s_src_parents,
-			ARRAY_SIZE(i2s_src_parents), 0, SPEAR1340_I2S_CLK_CFG,
-			SPEAR1340_I2S_SRC_CLK_SHIFT, SPEAR1340_I2S_SRC_CLK_MASK,
-			0, &_lock);
+			ARRAY_SIZE(i2s_src_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR1340_I2S_CLK_CFG, SPEAR1340_I2S_SRC_CLK_SHIFT,
+			SPEAR1340_I2S_SRC_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "i2s_src_mclk", NULL);
 
 	clk = clk_register_aux("i2s_prs1_clk", NULL, "i2s_src_mclk",
@@ -765,7 +769,8 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk, "i2s_prs1_clk", NULL);
 
 	clk = clk_register_mux(NULL, "i2s_ref_mclk", i2s_ref_parents,
-			ARRAY_SIZE(i2s_ref_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(i2s_ref_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR1340_I2S_CLK_CFG, SPEAR1340_I2S_REF_SHIFT,
 			SPEAR1340_I2S_REF_SEL_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "i2s_ref_mclk", NULL);
@@ -891,13 +896,15 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 
 	/* RAS clks */
 	clk = clk_register_mux(NULL, "gen_syn0_1_mclk", gen_synth0_1_parents,
-			ARRAY_SIZE(gen_synth0_1_parents), 0, SPEAR1340_PLL_CFG,
+			ARRAY_SIZE(gen_synth0_1_parents),
+			CLK_SET_RATE_NO_REPARENT, SPEAR1340_PLL_CFG,
 			SPEAR1340_GEN_SYNT0_1_CLK_SHIFT,
 			SPEAR1340_GEN_SYNT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gen_syn0_1_mclk", NULL);
 
 	clk = clk_register_mux(NULL, "gen_syn2_3_mclk", gen_synth2_3_parents,
-			ARRAY_SIZE(gen_synth2_3_parents), 0, SPEAR1340_PLL_CFG,
+			ARRAY_SIZE(gen_synth2_3_parents),
+			CLK_SET_RATE_NO_REPARENT, SPEAR1340_PLL_CFG,
 			SPEAR1340_GEN_SYNT2_3_CLK_SHIFT,
 			SPEAR1340_GEN_SYNT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gen_syn2_3_mclk", NULL);
@@ -938,7 +945,8 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk, NULL, "spear_cec.1");
 
 	clk = clk_register_mux(NULL, "spdif_out_mclk", spdif_out_parents,
-			ARRAY_SIZE(spdif_out_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(spdif_out_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR1340_PERIP_CLK_CFG, SPEAR1340_SPDIF_OUT_CLK_SHIFT,
 			SPEAR1340_SPDIF_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "spdif_out_mclk", NULL);
@@ -949,7 +957,8 @@ void __init spear1340_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk, NULL, "d0000000.spdif-out");
 
 	clk = clk_register_mux(NULL, "spdif_in_mclk", spdif_in_parents,
-			ARRAY_SIZE(spdif_in_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(spdif_in_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR1340_PERIP_CLK_CFG, SPEAR1340_SPDIF_IN_CLK_SHIFT,
 			SPEAR1340_SPDIF_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "spdif_in_mclk", NULL);
diff --git a/drivers/clk/spear/spear3xx_clock.c b/drivers/clk/spear/spear3xx_clock.c
index 080c3c5..c2d2043 100644
--- a/drivers/clk/spear/spear3xx_clock.c
+++ b/drivers/clk/spear/spear3xx_clock.c
@@ -294,7 +294,8 @@ static void __init spear320_clk_init(void __iomem *soc_config_base)
 	clk_register_clkdev(clk, NULL, "a9400000.i2s");
 
 	clk = clk_register_mux(NULL, "i2s_ref_clk", i2s_ref_parents,
-			ARRAY_SIZE(i2s_ref_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(i2s_ref_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR320_CONTROL_REG, I2S_REF_PCLK_SHIFT,
 			I2S_REF_PCLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "i2s_ref_clk", NULL);
@@ -313,57 +314,66 @@ static void __init spear320_clk_init(void __iomem *soc_config_base)
 	clk_register_clkdev(clk, "hclk", "ab000000.eth");
 
 	clk = clk_register_mux(NULL, "rs485_clk", uartx_parents,
-			ARRAY_SIZE(uartx_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(uartx_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR320_EXT_CTRL_REG, SPEAR320_RS485_PCLK_SHIFT,
 			SPEAR320_UARTX_PCLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, NULL, "a9300000.serial");
 
 	clk = clk_register_mux(NULL, "sdhci_clk", sdhci_parents,
-			ARRAY_SIZE(sdhci_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(sdhci_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR320_CONTROL_REG, SDHCI_PCLK_SHIFT, SDHCI_PCLK_MASK,
 			0, &_lock);
 	clk_register_clkdev(clk, NULL, "70000000.sdhci");
 
 	clk = clk_register_mux(NULL, "smii_pclk", smii0_parents,
-			ARRAY_SIZE(smii0_parents), 0, SPEAR320_CONTROL_REG,
-			SMII_PCLK_SHIFT, SMII_PCLK_MASK, 0, &_lock);
+			ARRAY_SIZE(smii0_parents), CLK_SET_RATE_NO_REPARENT,
+			SPEAR320_CONTROL_REG, SMII_PCLK_SHIFT, SMII_PCLK_MASK,
+			0, &_lock);
 	clk_register_clkdev(clk, NULL, "smii_pclk");
 
 	clk = clk_register_fixed_factor(NULL, "smii_clk", "smii_pclk", 0, 1, 1);
 	clk_register_clkdev(clk, NULL, "smii");
 
 	clk = clk_register_mux(NULL, "uart1_clk", uartx_parents,
-			ARRAY_SIZE(uartx_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(uartx_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR320_CONTROL_REG, UART1_PCLK_SHIFT, UART1_PCLK_MASK,
 			0, &_lock);
 	clk_register_clkdev(clk, NULL, "a3000000.serial");
 
 	clk = clk_register_mux(NULL, "uart2_clk", uartx_parents,
-			ARRAY_SIZE(uartx_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(uartx_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR320_EXT_CTRL_REG, SPEAR320_UART2_PCLK_SHIFT,
 			SPEAR320_UARTX_PCLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, NULL, "a4000000.serial");
 
 	clk = clk_register_mux(NULL, "uart3_clk", uartx_parents,
-			ARRAY_SIZE(uartx_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(uartx_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR320_EXT_CTRL_REG, SPEAR320_UART3_PCLK_SHIFT,
 			SPEAR320_UARTX_PCLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, NULL, "a9100000.serial");
 
 	clk = clk_register_mux(NULL, "uart4_clk", uartx_parents,
-			ARRAY_SIZE(uartx_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(uartx_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR320_EXT_CTRL_REG, SPEAR320_UART4_PCLK_SHIFT,
 			SPEAR320_UARTX_PCLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, NULL, "a9200000.serial");
 
 	clk = clk_register_mux(NULL, "uart5_clk", uartx_parents,
-			ARRAY_SIZE(uartx_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(uartx_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR320_EXT_CTRL_REG, SPEAR320_UART5_PCLK_SHIFT,
 			SPEAR320_UARTX_PCLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, NULL, "60000000.serial");
 
 	clk = clk_register_mux(NULL, "uart6_clk", uartx_parents,
-			ARRAY_SIZE(uartx_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(uartx_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			SPEAR320_EXT_CTRL_REG, SPEAR320_UART6_PCLK_SHIFT,
 			SPEAR320_UARTX_PCLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, NULL, "60100000.serial");
@@ -427,7 +437,8 @@ void __init spear3xx_clk_init(void __iomem *misc_base, void __iomem *soc_config_
 	clk_register_clkdev(clk1, "uart_syn_gclk", NULL);
 
 	clk = clk_register_mux(NULL, "uart0_mclk", uart0_parents,
-			ARRAY_SIZE(uart0_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(uart0_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			PERIP_CLK_CFG, UART_CLK_SHIFT, UART_CLK_MASK, 0,
 			&_lock);
 	clk_register_clkdev(clk, "uart0_mclk", NULL);
@@ -444,7 +455,8 @@ void __init spear3xx_clk_init(void __iomem *misc_base, void __iomem *soc_config_
 	clk_register_clkdev(clk1, "firda_syn_gclk", NULL);
 
 	clk = clk_register_mux(NULL, "firda_mclk", firda_parents,
-			ARRAY_SIZE(firda_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(firda_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			PERIP_CLK_CFG, FIRDA_CLK_SHIFT, FIRDA_CLK_MASK, 0,
 			&_lock);
 	clk_register_clkdev(clk, "firda_mclk", NULL);
@@ -458,14 +470,16 @@ void __init spear3xx_clk_init(void __iomem *misc_base, void __iomem *soc_config_
 	clk_register_gpt("gpt0_syn_clk", "pll1_clk", 0, PRSC0_CLK_CFG, gpt_rtbl,
 			ARRAY_SIZE(gpt_rtbl), &_lock);
 	clk = clk_register_mux(NULL, "gpt0_clk", gpt0_parents,
-			ARRAY_SIZE(gpt0_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(gpt0_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			PERIP_CLK_CFG, GPT0_CLK_SHIFT, GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, NULL, "gpt0");
 
 	clk_register_gpt("gpt1_syn_clk", "pll1_clk", 0, PRSC1_CLK_CFG, gpt_rtbl,
 			ARRAY_SIZE(gpt_rtbl), &_lock);
 	clk = clk_register_mux(NULL, "gpt1_mclk", gpt1_parents,
-			ARRAY_SIZE(gpt1_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(gpt1_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			PERIP_CLK_CFG, GPT1_CLK_SHIFT, GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gpt1_mclk", NULL);
 	clk = clk_register_gate(NULL, "gpt1_clk", "gpt1_mclk",
@@ -476,7 +490,8 @@ void __init spear3xx_clk_init(void __iomem *misc_base, void __iomem *soc_config_
 	clk_register_gpt("gpt2_syn_clk", "pll1_clk", 0, PRSC2_CLK_CFG, gpt_rtbl,
 			ARRAY_SIZE(gpt_rtbl), &_lock);
 	clk = clk_register_mux(NULL, "gpt2_mclk", gpt2_parents,
-			ARRAY_SIZE(gpt2_parents), CLK_SET_RATE_PARENT,
+			ARRAY_SIZE(gpt2_parents),
+			CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
 			PERIP_CLK_CFG, GPT2_CLK_SHIFT, GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gpt2_mclk", NULL);
 	clk = clk_register_gate(NULL, "gpt2_clk", "gpt2_mclk",
@@ -498,9 +513,9 @@ void __init spear3xx_clk_init(void __iomem *misc_base, void __iomem *soc_config_
 	clk_register_clkdev(clk1, "gen1_syn_gclk", NULL);
 
 	clk = clk_register_mux(NULL, "gen2_3_par_clk", gen2_3_parents,
-			ARRAY_SIZE(gen2_3_parents), 0, CORE_CLK_CFG,
-			GEN_SYNTH2_3_CLK_SHIFT, GEN_SYNTH2_3_CLK_MASK, 0,
-			&_lock);
+			ARRAY_SIZE(gen2_3_parents), CLK_SET_RATE_NO_REPARENT,
+			CORE_CLK_CFG, GEN_SYNTH2_3_CLK_SHIFT,
+			GEN_SYNTH2_3_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gen2_3_par_clk", NULL);
 
 	clk = clk_register_aux("gen2_syn_clk", "gen2_syn_gclk",
@@ -540,8 +555,8 @@ void __init spear3xx_clk_init(void __iomem *misc_base, void __iomem *soc_config_
 	clk_register_clkdev(clk, "ahbmult2_clk", NULL);
 
 	clk = clk_register_mux(NULL, "ddr_clk", ddr_parents,
-			ARRAY_SIZE(ddr_parents), 0, PLL_CLK_CFG, MCTR_CLK_SHIFT,
-			MCTR_CLK_MASK, 0, &_lock);
+			ARRAY_SIZE(ddr_parents), CLK_SET_RATE_NO_REPARENT,
+			PLL_CLK_CFG, MCTR_CLK_SHIFT, MCTR_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "ddr_clk", NULL);
 
 	clk = clk_register_divider(NULL, "apb_clk", "ahb_clk",
diff --git a/drivers/clk/spear/spear6xx_clock.c b/drivers/clk/spear/spear6xx_clock.c
index 9406f24..4f649c9 100644
--- a/drivers/clk/spear/spear6xx_clock.c
+++ b/drivers/clk/spear/spear6xx_clock.c
@@ -169,8 +169,9 @@ void __init spear6xx_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk1, "uart_syn_gclk", NULL);
 
 	clk = clk_register_mux(NULL, "uart_mclk", uart_parents,
-			ARRAY_SIZE(uart_parents), 0, PERIP_CLK_CFG,
-			UART_CLK_SHIFT, UART_CLK_MASK, 0, &_lock);
+			ARRAY_SIZE(uart_parents), CLK_SET_RATE_NO_REPARENT,
+			PERIP_CLK_CFG, UART_CLK_SHIFT, UART_CLK_MASK, 0,
+			&_lock);
 	clk_register_clkdev(clk, "uart_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "uart0", "uart_mclk", 0, PERIP1_CLK_ENB,
@@ -188,8 +189,9 @@ void __init spear6xx_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk1, "firda_syn_gclk", NULL);
 
 	clk = clk_register_mux(NULL, "firda_mclk", firda_parents,
-			ARRAY_SIZE(firda_parents), 0, PERIP_CLK_CFG,
-			FIRDA_CLK_SHIFT, FIRDA_CLK_MASK, 0, &_lock);
+			ARRAY_SIZE(firda_parents), CLK_SET_RATE_NO_REPARENT,
+			PERIP_CLK_CFG, FIRDA_CLK_SHIFT, FIRDA_CLK_MASK, 0,
+			&_lock);
 	clk_register_clkdev(clk, "firda_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "firda_clk", "firda_mclk", 0,
@@ -203,8 +205,9 @@ void __init spear6xx_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk1, "clcd_syn_gclk", NULL);
 
 	clk = clk_register_mux(NULL, "clcd_mclk", clcd_parents,
-			ARRAY_SIZE(clcd_parents), 0, PERIP_CLK_CFG,
-			CLCD_CLK_SHIFT, CLCD_CLK_MASK, 0, &_lock);
+			ARRAY_SIZE(clcd_parents), CLK_SET_RATE_NO_REPARENT,
+			PERIP_CLK_CFG, CLCD_CLK_SHIFT, CLCD_CLK_MASK, 0,
+			&_lock);
 	clk_register_clkdev(clk, "clcd_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "clcd_clk", "clcd_mclk", 0,
@@ -217,13 +220,13 @@ void __init spear6xx_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk, "gpt0_1_syn_clk", NULL);
 
 	clk = clk_register_mux(NULL, "gpt0_mclk", gpt0_1_parents,
-			ARRAY_SIZE(gpt0_1_parents), 0, PERIP_CLK_CFG,
-			GPT0_CLK_SHIFT, GPT_CLK_MASK, 0, &_lock);
+			ARRAY_SIZE(gpt0_1_parents), CLK_SET_RATE_NO_REPARENT,
+			PERIP_CLK_CFG, GPT0_CLK_SHIFT, GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, NULL, "gpt0");
 
 	clk = clk_register_mux(NULL, "gpt1_mclk", gpt0_1_parents,
-			ARRAY_SIZE(gpt0_1_parents), 0, PERIP_CLK_CFG,
-			GPT1_CLK_SHIFT, GPT_CLK_MASK, 0, &_lock);
+			ARRAY_SIZE(gpt0_1_parents), CLK_SET_RATE_NO_REPARENT,
+			PERIP_CLK_CFG, GPT1_CLK_SHIFT, GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gpt1_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "gpt1_clk", "gpt1_mclk", 0,
@@ -235,8 +238,8 @@ void __init spear6xx_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk, "gpt2_syn_clk", NULL);
 
 	clk = clk_register_mux(NULL, "gpt2_mclk", gpt2_parents,
-			ARRAY_SIZE(gpt2_parents), 0, PERIP_CLK_CFG,
-			GPT2_CLK_SHIFT, GPT_CLK_MASK, 0, &_lock);
+			ARRAY_SIZE(gpt2_parents), CLK_SET_RATE_NO_REPARENT,
+			PERIP_CLK_CFG, GPT2_CLK_SHIFT, GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gpt2_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "gpt2_clk", "gpt2_mclk", 0,
@@ -248,8 +251,8 @@ void __init spear6xx_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk, "gpt3_syn_clk", NULL);
 
 	clk = clk_register_mux(NULL, "gpt3_mclk", gpt3_parents,
-			ARRAY_SIZE(gpt3_parents), 0, PERIP_CLK_CFG,
-			GPT3_CLK_SHIFT, GPT_CLK_MASK, 0, &_lock);
+			ARRAY_SIZE(gpt3_parents), CLK_SET_RATE_NO_REPARENT,
+			PERIP_CLK_CFG, GPT3_CLK_SHIFT, GPT_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "gpt3_mclk", NULL);
 
 	clk = clk_register_gate(NULL, "gpt3_clk", "gpt3_mclk", 0,
@@ -277,8 +280,8 @@ void __init spear6xx_clk_init(void __iomem *misc_base)
 	clk_register_clkdev(clk, "ahbmult2_clk", NULL);
 
 	clk = clk_register_mux(NULL, "ddr_clk", ddr_parents,
-			ARRAY_SIZE(ddr_parents), 0, PLL_CLK_CFG, MCTR_CLK_SHIFT,
-			MCTR_CLK_MASK, 0, &_lock);
+			ARRAY_SIZE(ddr_parents), CLK_SET_RATE_NO_REPARENT,
+			PLL_CLK_CFG, MCTR_CLK_SHIFT, MCTR_CLK_MASK, 0, &_lock);
 	clk_register_clkdev(clk, "ddr_clk", NULL);
 
 	clk = clk_register_divider(NULL, "apb_clk", "ahb_clk",
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 412912b..8c44236 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -261,7 +261,8 @@ static void __init sunxi_mux_clk_setup(struct device_node *node,
 	while (i < 5 && (parents[i] = of_clk_get_parent_name(node, i)) != NULL)
 		i++;
 
-	clk = clk_register_mux(NULL, clk_name, parents, i, 0, reg,
+	clk = clk_register_mux(NULL, clk_name, parents, i,
+			       CLK_SET_RATE_NO_REPARENT, reg,
 			       data->shift, SUNXI_MUX_GATE_WIDTH,
 			       0, &clk_lock);
 
diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index b6015cb..c0715f6 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -1558,7 +1558,8 @@ static void __init tegra114_audio_clk_init(void __iomem *clk_base)
 
 	/* audio0 */
 	clk = clk_register_mux(NULL, "audio0_mux", mux_audio_sync_clk,
-			       ARRAY_SIZE(mux_audio_sync_clk), 0,
+			       ARRAY_SIZE(mux_audio_sync_clk),
+			       CLK_SET_RATE_NO_REPARENT,
 			       clk_base + AUDIO_SYNC_CLK_I2S0, 0, 3, 0,
 			       NULL);
 	clks[audio0_mux] = clk;
@@ -1570,7 +1571,8 @@ static void __init tegra114_audio_clk_init(void __iomem *clk_base)
 
 	/* audio1 */
 	clk = clk_register_mux(NULL, "audio1_mux", mux_audio_sync_clk,
-			       ARRAY_SIZE(mux_audio_sync_clk), 0,
+			       ARRAY_SIZE(mux_audio_sync_clk),
+			       CLK_SET_RATE_NO_REPARENT,
 			       clk_base + AUDIO_SYNC_CLK_I2S1, 0, 3, 0,
 			       NULL);
 	clks[audio1_mux] = clk;
@@ -1582,7 +1584,8 @@ static void __init tegra114_audio_clk_init(void __iomem *clk_base)
 
 	/* audio2 */
 	clk = clk_register_mux(NULL, "audio2_mux", mux_audio_sync_clk,
-			       ARRAY_SIZE(mux_audio_sync_clk), 0,
+			       ARRAY_SIZE(mux_audio_sync_clk),
+			       CLK_SET_RATE_NO_REPARENT,
 			       clk_base + AUDIO_SYNC_CLK_I2S2, 0, 3, 0,
 			       NULL);
 	clks[audio2_mux] = clk;
@@ -1594,7 +1597,8 @@ static void __init tegra114_audio_clk_init(void __iomem *clk_base)
 
 	/* audio3 */
 	clk = clk_register_mux(NULL, "audio3_mux", mux_audio_sync_clk,
-			       ARRAY_SIZE(mux_audio_sync_clk), 0,
+			       ARRAY_SIZE(mux_audio_sync_clk),
+			       CLK_SET_RATE_NO_REPARENT,
 			       clk_base + AUDIO_SYNC_CLK_I2S3, 0, 3, 0,
 			       NULL);
 	clks[audio3_mux] = clk;
@@ -1606,7 +1610,8 @@ static void __init tegra114_audio_clk_init(void __iomem *clk_base)
 
 	/* audio4 */
 	clk = clk_register_mux(NULL, "audio4_mux", mux_audio_sync_clk,
-			       ARRAY_SIZE(mux_audio_sync_clk), 0,
+			       ARRAY_SIZE(mux_audio_sync_clk),
+			       CLK_SET_RATE_NO_REPARENT,
 			       clk_base + AUDIO_SYNC_CLK_I2S4, 0, 3, 0,
 			       NULL);
 	clks[audio4_mux] = clk;
@@ -1618,7 +1623,8 @@ static void __init tegra114_audio_clk_init(void __iomem *clk_base)
 
 	/* spdif */
 	clk = clk_register_mux(NULL, "spdif_mux", mux_audio_sync_clk,
-			       ARRAY_SIZE(mux_audio_sync_clk), 0,
+			       ARRAY_SIZE(mux_audio_sync_clk),
+			       CLK_SET_RATE_NO_REPARENT,
 			       clk_base + AUDIO_SYNC_CLK_SPDIF, 0, 3, 0,
 			       NULL);
 	clks[spdif_mux] = clk;
@@ -1713,7 +1719,8 @@ static void __init tegra114_pmc_clk_init(void __iomem *pmc_base)
 
 	/* clk_out_1 */
 	clk = clk_register_mux(NULL, "clk_out_1_mux", clk_out1_parents,
-			       ARRAY_SIZE(clk_out1_parents), 0,
+			       ARRAY_SIZE(clk_out1_parents),
+			       CLK_SET_RATE_NO_REPARENT,
 			       pmc_base + PMC_CLK_OUT_CNTRL, 6, 3, 0,
 			       &clk_out_lock);
 	clks[clk_out_1_mux] = clk;
@@ -1725,7 +1732,8 @@ static void __init tegra114_pmc_clk_init(void __iomem *pmc_base)
 
 	/* clk_out_2 */
 	clk = clk_register_mux(NULL, "clk_out_2_mux", clk_out2_parents,
-			       ARRAY_SIZE(clk_out2_parents), 0,
+			       ARRAY_SIZE(clk_out2_parents),
+			       CLK_SET_RATE_NO_REPARENT,
 			       pmc_base + PMC_CLK_OUT_CNTRL, 14, 3, 0,
 			       &clk_out_lock);
 	clks[clk_out_2_mux] = clk;
@@ -1737,7 +1745,8 @@ static void __init tegra114_pmc_clk_init(void __iomem *pmc_base)
 
 	/* clk_out_3 */
 	clk = clk_register_mux(NULL, "clk_out_3_mux", clk_out3_parents,
-			       ARRAY_SIZE(clk_out3_parents), 0,
+			       ARRAY_SIZE(clk_out3_parents),
+			       CLK_SET_RATE_NO_REPARENT,
 			       pmc_base + PMC_CLK_OUT_CNTRL, 22, 3, 0,
 			       &clk_out_lock);
 	clks[clk_out_3_mux] = clk;
@@ -2055,7 +2064,8 @@ static __init void tegra114_periph_clk_init(void __iomem *clk_base)
 
 	/* dsia */
 	clk = clk_register_mux(NULL, "dsia_mux", mux_plld_out0_plld2_out0,
-			       ARRAY_SIZE(mux_plld_out0_plld2_out0), 0,
+			       ARRAY_SIZE(mux_plld_out0_plld2_out0),
+			       CLK_SET_RATE_NO_REPARENT,
 			       clk_base + PLLD_BASE, 25, 1, 0, &pll_d_lock);
 	clks[dsia_mux] = clk;
 	clk = tegra_clk_register_periph_gate("dsia", "dsia_mux", 0, clk_base,
@@ -2065,7 +2075,8 @@ static __init void tegra114_periph_clk_init(void __iomem *clk_base)
 
 	/* dsib */
 	clk = clk_register_mux(NULL, "dsib_mux", mux_plld_out0_plld2_out0,
-			       ARRAY_SIZE(mux_plld_out0_plld2_out0), 0,
+			       ARRAY_SIZE(mux_plld_out0_plld2_out0),
+			       CLK_SET_RATE_NO_REPARENT,
 			       clk_base + PLLD2_BASE, 25, 1, 0, &pll_d2_lock);
 	clks[dsib_mux] = clk;
 	clk = tegra_clk_register_periph_gate("dsib", "dsib_mux", 0, clk_base,
@@ -2102,7 +2113,8 @@ static __init void tegra114_periph_clk_init(void __iomem *clk_base)
 
 	/* emc */
 	clk = clk_register_mux(NULL, "emc_mux", mux_pllmcp_clkm,
-			       ARRAY_SIZE(mux_pllmcp_clkm), 0,
+			       ARRAY_SIZE(mux_pllmcp_clkm),
+			       CLK_SET_RATE_NO_REPARENT,
 			       clk_base + CLK_SOURCE_EMC,
 			       29, 3, 0, NULL);
 	clk = tegra_clk_register_periph_gate("emc", "emc_mux", 0, clk_base,
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index 759ca47..73ad49d0 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -778,7 +778,8 @@ static void __init tegra20_audio_clk_init(void)
 
 	/* audio */
 	clk = clk_register_mux(NULL, "audio_mux", audio_parents,
-				ARRAY_SIZE(audio_parents), 0,
+				ARRAY_SIZE(audio_parents),
+				CLK_SET_RATE_NO_REPARENT,
 				clk_base + AUDIO_SYNC_CLK, 0, 3, 0, NULL);
 	clk = clk_register_gate(NULL, "audio", "audio_mux", 0,
 				clk_base + AUDIO_SYNC_CLK, 4,
@@ -941,7 +942,8 @@ static void __init tegra20_periph_clk_init(void)
 
 	/* emc */
 	clk = clk_register_mux(NULL, "emc_mux", mux_pllmcp_clkm,
-			       ARRAY_SIZE(mux_pllmcp_clkm), 0,
+			       ARRAY_SIZE(mux_pllmcp_clkm),
+			       CLK_SET_RATE_NO_REPARENT,
 			       clk_base + CLK_SOURCE_EMC,
 			       30, 2, 0, NULL);
 	clk = tegra_clk_register_periph_gate("emc", "emc_mux", 0, clk_base, 0,
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index e2c6ca0..0291ef2 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1026,7 +1026,8 @@ static void __init tegra30_pll_init(void)
 
 	/* PLLE */
 	clk = clk_register_mux(NULL, "pll_e_mux", pll_e_parents,
-			       ARRAY_SIZE(pll_e_parents), 0,
+			       ARRAY_SIZE(pll_e_parents),
+			       CLK_SET_RATE_NO_REPARENT,
 			       clk_base + PLLE_AUX, 2, 1, 0, NULL);
 	clk = tegra_clk_register_plle("pll_e", "pll_e_mux", clk_base, pmc_base,
 			     CLK_GET_RATE_NOCACHE, 100000000, &pll_e_params,
@@ -1086,7 +1087,8 @@ static void __init tegra30_audio_clk_init(void)
 
 	/* audio0 */
 	clk = clk_register_mux(NULL, "audio0_mux", mux_audio_sync_clk,
-				ARRAY_SIZE(mux_audio_sync_clk), 0,
+				ARRAY_SIZE(mux_audio_sync_clk),
+				CLK_SET_RATE_NO_REPARENT,
 				clk_base + AUDIO_SYNC_CLK_I2S0, 0, 3, 0, NULL);
 	clk = clk_register_gate(NULL, "audio0", "audio0_mux", 0,
 				clk_base + AUDIO_SYNC_CLK_I2S0, 4,
@@ -1096,7 +1098,8 @@ static void __init tegra30_audio_clk_init(void)
 
 	/* audio1 */
 	clk = clk_register_mux(NULL, "audio1_mux", mux_audio_sync_clk,
-				ARRAY_SIZE(mux_audio_sync_clk), 0,
+				ARRAY_SIZE(mux_audio_sync_clk),
+				CLK_SET_RATE_NO_REPARENT,
 				clk_base + AUDIO_SYNC_CLK_I2S1, 0, 3, 0, NULL);
 	clk = clk_register_gate(NULL, "audio1", "audio1_mux", 0,
 				clk_base + AUDIO_SYNC_CLK_I2S1, 4,
@@ -1106,7 +1109,8 @@ static void __init tegra30_audio_clk_init(void)
 
 	/* audio2 */
 	clk = clk_register_mux(NULL, "audio2_mux", mux_audio_sync_clk,
-				ARRAY_SIZE(mux_audio_sync_clk), 0,
+				ARRAY_SIZE(mux_audio_sync_clk),
+				CLK_SET_RATE_NO_REPARENT,
 				clk_base + AUDIO_SYNC_CLK_I2S2, 0, 3, 0, NULL);
 	clk = clk_register_gate(NULL, "audio2", "audio2_mux", 0,
 				clk_base + AUDIO_SYNC_CLK_I2S2, 4,
@@ -1116,7 +1120,8 @@ static void __init tegra30_audio_clk_init(void)
 
 	/* audio3 */
 	clk = clk_register_mux(NULL, "audio3_mux", mux_audio_sync_clk,
-				ARRAY_SIZE(mux_audio_sync_clk), 0,
+				ARRAY_SIZE(mux_audio_sync_clk),
+				CLK_SET_RATE_NO_REPARENT,
 				clk_base + AUDIO_SYNC_CLK_I2S3, 0, 3, 0, NULL);
 	clk = clk_register_gate(NULL, "audio3", "audio3_mux", 0,
 				clk_base + AUDIO_SYNC_CLK_I2S3, 4,
@@ -1126,7 +1131,8 @@ static void __init tegra30_audio_clk_init(void)
 
 	/* audio4 */
 	clk = clk_register_mux(NULL, "audio4_mux", mux_audio_sync_clk,
-				ARRAY_SIZE(mux_audio_sync_clk), 0,
+				ARRAY_SIZE(mux_audio_sync_clk),
+				CLK_SET_RATE_NO_REPARENT,
 				clk_base + AUDIO_SYNC_CLK_I2S4, 0, 3, 0, NULL);
 	clk = clk_register_gate(NULL, "audio4", "audio4_mux", 0,
 				clk_base + AUDIO_SYNC_CLK_I2S4, 4,
@@ -1136,7 +1142,8 @@ static void __init tegra30_audio_clk_init(void)
 
 	/* spdif */
 	clk = clk_register_mux(NULL, "spdif_mux", mux_audio_sync_clk,
-				ARRAY_SIZE(mux_audio_sync_clk), 0,
+				ARRAY_SIZE(mux_audio_sync_clk),
+				CLK_SET_RATE_NO_REPARENT,
 				clk_base + AUDIO_SYNC_CLK_SPDIF, 0, 3, 0, NULL);
 	clk = clk_register_gate(NULL, "spdif", "spdif_mux", 0,
 				clk_base + AUDIO_SYNC_CLK_SPDIF, 4,
@@ -1229,7 +1236,8 @@ static void __init tegra30_pmc_clk_init(void)
 
 	/* clk_out_1 */
 	clk = clk_register_mux(NULL, "clk_out_1_mux", clk_out1_parents,
-			       ARRAY_SIZE(clk_out1_parents), 0,
+			       ARRAY_SIZE(clk_out1_parents),
+			       CLK_SET_RATE_NO_REPARENT,
 			       pmc_base + PMC_CLK_OUT_CNTRL, 6, 3, 0,
 			       &clk_out_lock);
 	clks[clk_out_1_mux] = clk;
@@ -1241,7 +1249,8 @@ static void __init tegra30_pmc_clk_init(void)
 
 	/* clk_out_2 */
 	clk = clk_register_mux(NULL, "clk_out_2_mux", clk_out2_parents,
-			       ARRAY_SIZE(clk_out2_parents), 0,
+			       ARRAY_SIZE(clk_out2_parents),
+			       CLK_SET_RATE_NO_REPARENT,
 			       pmc_base + PMC_CLK_OUT_CNTRL, 14, 3, 0,
 			       &clk_out_lock);
 	clk = clk_register_gate(NULL, "clk_out_2", "clk_out_2_mux", 0,
@@ -1252,7 +1261,8 @@ static void __init tegra30_pmc_clk_init(void)
 
 	/* clk_out_3 */
 	clk = clk_register_mux(NULL, "clk_out_3_mux", clk_out3_parents,
-			       ARRAY_SIZE(clk_out3_parents), 0,
+			       ARRAY_SIZE(clk_out3_parents),
+			       CLK_SET_RATE_NO_REPARENT,
 			       pmc_base + PMC_CLK_OUT_CNTRL, 22, 3, 0,
 			       &clk_out_lock);
 	clk = clk_register_gate(NULL, "clk_out_3", "clk_out_3_mux", 0,
@@ -1679,7 +1689,8 @@ static void __init tegra30_periph_clk_init(void)
 
 	/* emc */
 	clk = clk_register_mux(NULL, "emc_mux", mux_pllmcp_clkm,
-			       ARRAY_SIZE(mux_pllmcp_clkm), 0,
+			       ARRAY_SIZE(mux_pllmcp_clkm),
+			       CLK_SET_RATE_NO_REPARENT,
 			       clk_base + CLK_SOURCE_EMC,
 			       30, 2, 0, NULL);
 	clk = tegra_clk_register_periph_gate("emc", "emc_mux", 0, clk_base, 0,
diff --git a/drivers/clk/versatile/clk-vexpress.c b/drivers/clk/versatile/clk-vexpress.c
index a4a728d..2d5e1b4 100644
--- a/drivers/clk/versatile/clk-vexpress.c
+++ b/drivers/clk/versatile/clk-vexpress.c
@@ -37,8 +37,8 @@ static void __init vexpress_sp810_init(void __iomem *base)
 		snprintf(name, ARRAY_SIZE(name), "timerclken%d", i);
 
 		vexpress_sp810_timerclken[i] = clk_register_mux(NULL, name,
-				parents, 2, 0, base + SCCTRL,
-				SCCTRL_TIMERENnSEL_SHIFT(i), 1,
+				parents, 2, CLK_SET_RATE_NO_REPARENT,
+				base + SCCTRL, SCCTRL_TIMERENnSEL_SHIFT(i), 1,
 				0, &vexpress_sp810_lock);
 
 		if (WARN_ON(IS_ERR(vexpress_sp810_timerclken[i])))
diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c
index 5c205b6..e05c9e3 100644
--- a/drivers/clk/zynq/clkc.c
+++ b/drivers/clk/zynq/clkc.c
@@ -124,8 +124,9 @@ static void __init zynq_clk_register_fclk(enum zynq_clk fclk,
 	div0_name = kasprintf(GFP_KERNEL, "%s_div0", clk_name);
 	div1_name = kasprintf(GFP_KERNEL, "%s_div1", clk_name);
 
-	clk = clk_register_mux(NULL, mux_name, parents, 4, 0,
-			fclk_ctrl_reg, 4, 2, 0, fclk_lock);
+	clk = clk_register_mux(NULL, mux_name, parents, 4,
+			CLK_SET_RATE_NO_REPARENT, fclk_ctrl_reg, 4, 2, 0,
+			fclk_lock);
 
 	clk = clk_register_divider(NULL, div0_name, mux_name,
 			0, fclk_ctrl_reg, 8, 6, CLK_DIVIDER_ONE_BASED |
@@ -167,8 +168,8 @@ static void __init zynq_clk_register_periph_clk(enum zynq_clk clk0,
 	mux_name = kasprintf(GFP_KERNEL, "%s_mux", clk_name0);
 	div_name = kasprintf(GFP_KERNEL, "%s_div", clk_name0);
 
-	clk = clk_register_mux(NULL, mux_name, parents, 4, 0,
-			clk_ctrl, 4, 2, 0, lock);
+	clk = clk_register_mux(NULL, mux_name, parents, 4,
+			CLK_SET_RATE_NO_REPARENT, clk_ctrl, 4, 2, 0, lock);
 
 	clk = clk_register_divider(NULL, div_name, mux_name, 0, clk_ctrl, 8, 6,
 			CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO, lock);
@@ -235,25 +236,26 @@ static void __init zynq_clk_setup(struct device_node *np)
 	clk = clk_register_zynq_pll("armpll_int", "ps_clk", SLCR_ARMPLL_CTRL,
 			SLCR_PLL_STATUS, 0, &armpll_lock);
 	clks[armpll] = clk_register_mux(NULL, clk_output_name[armpll],
-			armpll_parents, 2, 0, SLCR_ARMPLL_CTRL, 4, 1, 0,
-			&armpll_lock);
+			armpll_parents, 2, CLK_SET_RATE_NO_REPARENT,
+			SLCR_ARMPLL_CTRL, 4, 1, 0, &armpll_lock);
 
 	clk = clk_register_zynq_pll("ddrpll_int", "ps_clk", SLCR_DDRPLL_CTRL,
 			SLCR_PLL_STATUS, 1, &ddrpll_lock);
 	clks[ddrpll] = clk_register_mux(NULL, clk_output_name[ddrpll],
-			ddrpll_parents, 2, 0, SLCR_DDRPLL_CTRL, 4, 1, 0,
-			&ddrpll_lock);
+			ddrpll_parents, 2, CLK_SET_RATE_NO_REPARENT,
+			SLCR_DDRPLL_CTRL, 4, 1, 0, &ddrpll_lock);
 
 	clk = clk_register_zynq_pll("iopll_int", "ps_clk", SLCR_IOPLL_CTRL,
 			SLCR_PLL_STATUS, 2, &iopll_lock);
 	clks[iopll] = clk_register_mux(NULL, clk_output_name[iopll],
-			iopll_parents, 2, 0, SLCR_IOPLL_CTRL, 4, 1, 0,
-			&iopll_lock);
+			iopll_parents, 2, CLK_SET_RATE_NO_REPARENT,
+			SLCR_IOPLL_CTRL, 4, 1, 0, &iopll_lock);
 
 	/* CPU clocks */
 	tmp = readl(SLCR_621_TRUE) & 1;
-	clk = clk_register_mux(NULL, "cpu_mux", cpu_parents, 4, 0,
-			SLCR_ARM_CLK_CTRL, 4, 2, 0, &armclk_lock);
+	clk = clk_register_mux(NULL, "cpu_mux", cpu_parents, 4,
+			CLK_SET_RATE_NO_REPARENT, SLCR_ARM_CLK_CTRL, 4, 2, 0,
+			&armclk_lock);
 	clk = clk_register_divider(NULL, "cpu_div", "cpu_mux", 0,
 			SLCR_ARM_CLK_CTRL, 8, 6, CLK_DIVIDER_ONE_BASED |
 			CLK_DIVIDER_ALLOW_ZERO, &armclk_lock);
@@ -292,8 +294,9 @@ static void __init zynq_clk_setup(struct device_node *np)
 			swdt_ext_clk_mux_parents[i + 1] = dummy_nm;
 	}
 	clks[swdt] = clk_register_mux(NULL, clk_output_name[swdt],
-			swdt_ext_clk_mux_parents, 2, CLK_SET_RATE_PARENT,
-			SLCR_SWDT_CLK_SEL, 0, 1, 0, &gem0clk_lock);
+			swdt_ext_clk_mux_parents, 2, CLK_SET_RATE_PARENT |
+			CLK_SET_RATE_NO_REPARENT, SLCR_SWDT_CLK_SEL, 0, 1, 0,
+			&gem0clk_lock);
 
 	/* DDR clocks */
 	clk = clk_register_divider(NULL, "ddr2x_div", "ddrpll", 0,
@@ -355,8 +358,9 @@ static void __init zynq_clk_setup(struct device_node *np)
 			gem0_mux_parents[i + 1] = of_clk_get_parent_name(np,
 					idx);
 	}
-	clk = clk_register_mux(NULL, "gem0_mux", periph_parents, 4, 0,
-			SLCR_GEM0_CLK_CTRL, 4, 2, 0, &gem0clk_lock);
+	clk = clk_register_mux(NULL, "gem0_mux", periph_parents, 4,
+			CLK_SET_RATE_NO_REPARENT, SLCR_GEM0_CLK_CTRL, 4, 2, 0,
+			&gem0clk_lock);
 	clk = clk_register_divider(NULL, "gem0_div0", "gem0_mux", 0,
 			SLCR_GEM0_CLK_CTRL, 8, 6, CLK_DIVIDER_ONE_BASED |
 			CLK_DIVIDER_ALLOW_ZERO, &gem0clk_lock);
@@ -364,8 +368,9 @@ static void __init zynq_clk_setup(struct device_node *np)
 			CLK_SET_RATE_PARENT, SLCR_GEM0_CLK_CTRL, 20, 6,
 			CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO,
 			&gem0clk_lock);
-	clk = clk_register_mux(NULL, "gem0_emio_mux", gem0_mux_parents, 2, 0,
-			SLCR_GEM0_CLK_CTRL, 6, 1, 0, &gem0clk_lock);
+	clk = clk_register_mux(NULL, "gem0_emio_mux", gem0_mux_parents, 2,
+			CLK_SET_RATE_NO_REPARENT, SLCR_GEM0_CLK_CTRL, 6, 1, 0,
+			&gem0clk_lock);
 	clks[gem0] = clk_register_gate(NULL, clk_output_name[gem0],
 			"gem0_emio_mux", CLK_SET_RATE_PARENT,
 			SLCR_GEM0_CLK_CTRL, 0, 0, &gem0clk_lock);
@@ -377,8 +382,9 @@ static void __init zynq_clk_setup(struct device_node *np)
 			gem1_mux_parents[i + 1] = of_clk_get_parent_name(np,
 					idx);
 	}
-	clk = clk_register_mux(NULL, "gem1_mux", periph_parents, 4, 0,
-			SLCR_GEM1_CLK_CTRL, 4, 2, 0, &gem1clk_lock);
+	clk = clk_register_mux(NULL, "gem1_mux", periph_parents, 4,
+			CLK_SET_RATE_NO_REPARENT, SLCR_GEM1_CLK_CTRL, 4, 2, 0,
+			&gem1clk_lock);
 	clk = clk_register_divider(NULL, "gem1_div0", "gem1_mux", 0,
 			SLCR_GEM1_CLK_CTRL, 8, 6, CLK_DIVIDER_ONE_BASED |
 			CLK_DIVIDER_ALLOW_ZERO, &gem1clk_lock);
@@ -386,8 +392,9 @@ static void __init zynq_clk_setup(struct device_node *np)
 			CLK_SET_RATE_PARENT, SLCR_GEM1_CLK_CTRL, 20, 6,
 			CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO,
 			&gem1clk_lock);
-	clk = clk_register_mux(NULL, "gem1_emio_mux", gem1_mux_parents, 2, 0,
-			SLCR_GEM1_CLK_CTRL, 6, 1, 0, &gem1clk_lock);
+	clk = clk_register_mux(NULL, "gem1_emio_mux", gem1_mux_parents, 2,
+			CLK_SET_RATE_NO_REPARENT, SLCR_GEM1_CLK_CTRL, 6, 1, 0,
+			&gem1clk_lock);
 	clks[gem1] = clk_register_gate(NULL, clk_output_name[gem1],
 			"gem1_emio_mux", CLK_SET_RATE_PARENT,
 			SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock);
@@ -406,8 +413,9 @@ static void __init zynq_clk_setup(struct device_node *np)
 			can_mio_mux_parents[i] = dummy_nm;
 	}
 	kfree(clk_name);
-	clk = clk_register_mux(NULL, "can_mux", periph_parents, 4, 0,
-			SLCR_CAN_CLK_CTRL, 4, 2, 0, &canclk_lock);
+	clk = clk_register_mux(NULL, "can_mux", periph_parents, 4,
+			CLK_SET_RATE_NO_REPARENT, SLCR_CAN_CLK_CTRL, 4, 2, 0,
+			&canclk_lock);
 	clk = clk_register_divider(NULL, "can_div0", "can_mux", 0,
 			SLCR_CAN_CLK_CTRL, 8, 6, CLK_DIVIDER_ONE_BASED |
 			CLK_DIVIDER_ALLOW_ZERO, &canclk_lock);
@@ -422,17 +430,21 @@ static void __init zynq_clk_setup(struct device_node *np)
 			CLK_SET_RATE_PARENT, SLCR_CAN_CLK_CTRL, 1, 0,
 			&canclk_lock);
 	clk = clk_register_mux(NULL, "can0_mio_mux",
-			can_mio_mux_parents, 54, CLK_SET_RATE_PARENT,
-			SLCR_CAN_MIOCLK_CTRL, 0, 6, 0, &canmioclk_lock);
+			can_mio_mux_parents, 54, CLK_SET_RATE_PARENT |
+			CLK_SET_RATE_NO_REPARENT, SLCR_CAN_MIOCLK_CTRL, 0, 6, 0,
+			&canmioclk_lock);
 	clk = clk_register_mux(NULL, "can1_mio_mux",
-			can_mio_mux_parents, 54, CLK_SET_RATE_PARENT,
-			SLCR_CAN_MIOCLK_CTRL, 16, 6, 0, &canmioclk_lock);
+			can_mio_mux_parents, 54, CLK_SET_RATE_PARENT |
+			CLK_SET_RATE_NO_REPARENT, SLCR_CAN_MIOCLK_CTRL, 16, 6,
+			0, &canmioclk_lock);
 	clks[can0] = clk_register_mux(NULL, clk_output_name[can0],
-			can0_mio_mux2_parents, 2, CLK_SET_RATE_PARENT,
-			SLCR_CAN_MIOCLK_CTRL, 6, 1, 0, &canmioclk_lock);
+			can0_mio_mux2_parents, 2, CLK_SET_RATE_PARENT |
+			CLK_SET_RATE_NO_REPARENT, SLCR_CAN_MIOCLK_CTRL, 6, 1, 0,
+			&canmioclk_lock);
 	clks[can1] = clk_register_mux(NULL, clk_output_name[can1],
-			can1_mio_mux2_parents, 2, CLK_SET_RATE_PARENT,
-			SLCR_CAN_MIOCLK_CTRL, 22, 1, 0, &canmioclk_lock);
+			can1_mio_mux2_parents, 2, CLK_SET_RATE_PARENT |
+			CLK_SET_RATE_NO_REPARENT, SLCR_CAN_MIOCLK_CTRL, 22, 1,
+			0, &canmioclk_lock);
 
 	for (i = 0; i < ARRAY_SIZE(dbgtrc_emio_input_names); i++) {
 		int idx = of_property_match_string(np, "clock-names",
@@ -441,13 +453,15 @@ static void __init zynq_clk_setup(struct device_node *np)
 			dbg_emio_mux_parents[i + 1] = of_clk_get_parent_name(np,
 					idx);
 	}
-	clk = clk_register_mux(NULL, "dbg_mux", periph_parents, 4, 0,
-			SLCR_DBG_CLK_CTRL, 4, 2, 0, &dbgclk_lock);
+	clk = clk_register_mux(NULL, "dbg_mux", periph_parents, 4,
+			CLK_SET_RATE_NO_REPARENT, SLCR_DBG_CLK_CTRL, 4, 2, 0,
+			&dbgclk_lock);
 	clk = clk_register_divider(NULL, "dbg_div", "dbg_mux", 0,
 			SLCR_DBG_CLK_CTRL, 8, 6, CLK_DIVIDER_ONE_BASED |
 			CLK_DIVIDER_ALLOW_ZERO, &dbgclk_lock);
-	clk = clk_register_mux(NULL, "dbg_emio_mux", dbg_emio_mux_parents, 2, 0,
-			SLCR_DBG_CLK_CTRL, 6, 1, 0, &dbgclk_lock);
+	clk = clk_register_mux(NULL, "dbg_emio_mux", dbg_emio_mux_parents, 2,
+			CLK_SET_RATE_NO_REPARENT, SLCR_DBG_CLK_CTRL, 6, 1, 0,
+			&dbgclk_lock);
 	clks[dbg_trc] = clk_register_gate(NULL, clk_output_name[dbg_trc],
 			"dbg_emio_mux", CLK_SET_RATE_PARENT, SLCR_DBG_CLK_CTRL,
 			0, 0, &dbgclk_lock);
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index d37e518..8ffe06c 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -27,6 +27,7 @@
 #define CLK_IS_ROOT		BIT(4) /* root clk, has no parent */
 #define CLK_IS_BASIC		BIT(5) /* Basic clk, can't do a to_clk_foo() */
 #define CLK_GET_RATE_NOCACHE	BIT(6) /* do not use the cached clk rate */
+#define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate change */
 
 struct clk_hw;
 
-- 
1.8.1.2




From hdoyu at nvidia.com  Mon Jul 29 07:27:52 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Mon, 29 Jul 2013 13:27:52 +0200
Subject: [PATCH v2 14/22] iommu/tegra: smmu: Register platform_device to
 IOMMU dynamically
In-Reply-To: <51E84D51.2030404@wwwdotorg.org>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com><1373021097-32420-15-git-send-email-hdoyu@nvidia.com><51E84D51.2030404@wwwdotorg.org>
Message-ID: <20130729.142752.1020949402019811407.hdoyu@nvidia.com>

Stephen Warren <swarren at wwwdotorg.org> wrote @ Thu, 18 Jul 2013 22:17:21 +0200:

> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> > Register platform_devices to IOMMU dynamically via
> > ops->{add,remove}_device().
> 
> > diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> 
> > +/*
> > + * ASID[0] for the system default
> > + * ASID[1] for PPCS, which has SDMMC
> 
> I have no idea what PPCS is. The patch description for 21/22 implies
> much more than SDMMC is "in PPCS"...

"PPCS" is all AHB bus children/(client).

> > + * ASID[2][3].. open for drivers, first come, first served.
> > + */
> > +enum {
> > +	SYSTEM_DEFAULT,
> > +	SYSTEM_PROTECTED,
> > +};
> 
> Why hard-code this mapping? Can't devices be assigned to ASIDs based on
> a DT property? I assume there's nothing in the SMMU HW that requires
> specific ASIDs to be used?

Right. Where should those policy be passed, board DT files?

> I don't see anything in this series which implements the "open for
> drivers" part of the description for ASID 2/3/...

I expect that some smart HW(host1x) will use AS[2/3] for their smarter usage.


From hdoyu at nvidia.com  Mon Jul 29 07:39:50 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Mon, 29 Jul 2013 13:39:50 +0200
Subject: [PATCH v2 16/22] iommu/tegra: smmu: Get "nvidia,swgroup" from DT
In-Reply-To: <51E84FFA.8020509@wwwdotorg.org>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com><1373021097-32420-17-git-send-email-hdoyu@nvidia.com><51E84FFA.8020509@wwwdotorg.org>
Message-ID: <20130729.143950.524913713971518557.hdoyu@nvidia.com>

Stephen Warren <swarren at wwwdotorg.org> wrote @ Thu, 18 Jul 2013 22:28:42 +0200:

> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> > This provides the info about which H/W Accelerators are supported on
> > Tegra SoC. This info is passed from DT. This is necessary to have the
> > unified SMMU driver among Tegra SoCs. Instead of using platform data,
> > DT passes "nvidia,swgroup" now. DT is mandatory in Tegra.
> 
> > diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
> 
> > +- nvidia,swgroups: A bitmap of supported HardWare Accelerators(HWA).
> > +  Each bit represents one swgroup. The assignments may be found in header
> > +  file <dt-bindings/memory/tegra-swgroup.h>.
> 
> There needs to be a default for this field if one is not specified so
> that existing DTs continue to work without modification.

Only enabling PPCS(AHB) can be an option because PPCS has SD/MMC where
rootfs can be located ususally.

> How many cells big is this property?

64

> Is this really a bitmap of HWAs? Surely it's a bitmap of SMMU client
> IDs?

At least this info can be used for PMC too.

.....
> > diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> 
> > @@ -265,7 +265,7 @@ struct smmu_client {
> >  	struct device		*dev;
> >  	struct list_head	list;
> >  	struct smmu_as		*as;
> > -	u32			hwgrp;
> > +	u64			hwgrp;
> 
> Why is that "hwgrp" not "swgrp"? Don't they represent the same
> thing?

They are same but initial SMMU driver used the term "hwgroup". Should
this be renamed with another patch or can it be left as it is?

....
> >  static int __smmu_client_set_hwgrp(struct smmu_client *c,
> > -				   unsigned long map, int on)
> > +				   u64 map, int on)
> >  {
> >  	int i;
> >  	struct smmu_as *as = c->as;
> > @@ -398,12 +400,11 @@ static int __smmu_client_set_hwgrp(struct smmu_client *c,
> >  	if (!on)
> >  		map = smmu_client_hwgrp(c);
> >  
> > -	for_each_set_bit(i, &map, HWGRP_COUNT) {
> > +	for_each_set_bit(i, (unsigned long *)&map,
> > +			 sizeof(map) * BITS_PER_BYTE) {
> 
> Why change the type if it just forces you to add this cast?

u32 map; -> u64 map;

for_each_set_bit() expects "unsigned long *" for any length of bitmap.


From jonas.jensen at gmail.com  Mon Jul 29 07:41:33 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Mon, 29 Jul 2013 13:41:33 +0200
Subject: [PATCH v6] watchdog: Add MOXA ART watchdog driver
In-Reply-To: <1375093215-7136-1-git-send-email-jonas.jensen@gmail.com>
References: <1375093215-7136-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1375098093-8975-1-git-send-email-jonas.jensen@gmail.com>

Add watchdog driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v5:
    
    1. replace "moxart_wdt->dev.timeout" with "wdt_dev->timeout"
    
    Applies to next-20130729

 .../bindings/watchdog/moxa,moxart-watchdog.txt     |  15 ++
 drivers/watchdog/Kconfig                           |  10 ++
 drivers/watchdog/Makefile                          |   1 +
 drivers/watchdog/moxart_wdt.c                      | 165 +++++++++++++++++++++
 4 files changed, 191 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
 create mode 100644 drivers/watchdog/moxart_wdt.c

diff --git a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
new file mode 100644
index 0000000..1169857
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
@@ -0,0 +1,15 @@
+MOXA ART Watchdog timer
+
+Required properties:
+
+- compatible : Must be "moxa,moxart-watchdog"
+- reg : Should contain registers location and length
+- clocks : Should contain phandle for the clock that drives the counter
+
+Example:
+
+	watchdog: watchdog at 98500000 {
+		compatible = "moxa,moxart-watchdog";
+		reg = <0x98500000 0x10>;
+		clocks = <&coreclk>;
+	};
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 362085d..6883aab 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -382,6 +382,16 @@ config RETU_WATCHDOG
 	  To compile this driver as a module, choose M here: the
 	  module will be called retu_wdt.
 
+config MOXART_WDT
+	tristate "MOXART watchdog"
+	depends on ARCH_MOXART
+	help
+	  Say Y here to include Watchdog timer support for the watchdog
+	  existing on the MOXA ART SoC series platforms.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called moxart_wdt.
+
 # AVR32 Architecture
 
 config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 2f26a0b..7cab53a 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
 obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
 obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
 obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
+obj-$(CONFIG_MOXART_WDT) += moxart_wdt.o
 
 # AVR32 Architecture
 obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
new file mode 100644
index 0000000..70b5806
--- /dev/null
+++ b/drivers/watchdog/moxart_wdt.c
@@ -0,0 +1,165 @@
+/*
+ * MOXA ART SoCs watchdog driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/watchdog.h>
+#include <linux/moduleparam.h>
+
+#define REG_COUNT			0x4
+#define REG_MODE			0x8
+#define REG_ENABLE			0xC
+
+struct moxart_wdt_dev {
+	struct watchdog_device dev;
+	void __iomem *base;
+	unsigned int clock_frequency;
+};
+
+static int heartbeat;
+
+static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+
+	writel(0, moxart_wdt->base + REG_ENABLE);
+
+	return 0;
+}
+
+static int moxart_wdt_start(struct watchdog_device *wdt_dev)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+
+	writel(moxart_wdt->clock_frequency * wdt_dev->timeout,
+	       moxart_wdt->base + REG_COUNT);
+	writel(0x5ab9, moxart_wdt->base + REG_MODE);
+	writel(0x03, moxart_wdt->base + REG_ENABLE);
+
+	return 0;
+}
+
+static int moxart_wdt_set_timeout(struct watchdog_device *wdt_dev,
+				  unsigned int timeout)
+{
+	wdt_dev->timeout = timeout;
+
+	return 0;
+}
+
+static const struct watchdog_info moxart_wdt_info = {
+	.identity       = "moxart-wdt",
+	.options        = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
+static const struct watchdog_ops moxart_wdt_ops = {
+	.owner          = THIS_MODULE,
+	.start          = moxart_wdt_start,
+	.stop           = moxart_wdt_stop,
+	.set_timeout    = moxart_wdt_set_timeout,
+};
+
+static int moxart_wdt_probe(struct platform_device *pdev)
+{
+	struct moxart_wdt_dev *moxart_wdt;
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct resource *res;
+	struct clk *clk;
+	int err;
+	unsigned int max_timeout;
+	bool nowayout = WATCHDOG_NOWAYOUT;
+
+	moxart_wdt = devm_kzalloc(&pdev->dev, sizeof(*moxart_wdt), GFP_KERNEL);
+	if (!moxart_wdt)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, moxart_wdt);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	moxart_wdt->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_wdt->base))
+		return PTR_ERR(moxart_wdt->base);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk)) {
+		pr_err("%s: of_clk_get failed\n", __func__);
+		return PTR_ERR(clk);
+	}
+
+	moxart_wdt->clock_frequency = clk_get_rate(clk);
+	if (moxart_wdt->clock_frequency == 0) {
+		pr_err("%s: incorrect clock frequency\n", __func__);
+		return -EINVAL;
+	}
+
+	max_timeout = UINT_MAX / moxart_wdt->clock_frequency;
+
+	moxart_wdt->dev.info = &moxart_wdt_info;
+	moxart_wdt->dev.ops = &moxart_wdt_ops;
+	moxart_wdt->dev.timeout = max_timeout;
+	moxart_wdt->dev.min_timeout = 1;
+	moxart_wdt->dev.max_timeout = max_timeout;
+	moxart_wdt->dev.parent = &pdev->dev;
+
+	watchdog_init_timeout(&moxart_wdt->dev, heartbeat, &pdev->dev);
+	watchdog_set_nowayout(&moxart_wdt->dev, nowayout);
+
+	watchdog_set_drvdata(&moxart_wdt->dev, moxart_wdt);
+
+	err = watchdog_register_device(&moxart_wdt->dev);
+	if (unlikely(err))
+		return err;
+
+	dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
+		moxart_wdt->dev.timeout, nowayout);
+
+	return 0;
+}
+
+static int moxart_wdt_remove(struct platform_device *pdev)
+{
+	struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
+
+	moxart_wdt_stop(&moxart_wdt->dev);
+	watchdog_unregister_device(&moxart_wdt->dev);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_watchdog_match[] = {
+	{ .compatible = "moxa,moxart-watchdog" },
+	{ },
+};
+
+static struct platform_driver moxart_wdt_driver = {
+	.probe      = moxart_wdt_probe,
+	.remove     = moxart_wdt_remove,
+	.driver     = {
+		.name		= "moxart-watchdog",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_watchdog_match,
+	},
+};
+module_platform_driver(moxart_wdt_driver);
+
+module_param(heartbeat, int, 0);
+MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");
+
+MODULE_DESCRIPTION("MOXART watchdog driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From linus.walleij at linaro.org  Mon Jul 29 07:43:09 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 Jul 2013 13:43:09 +0200
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping
 for every GPIO on DT"
In-Reply-To: <D135FD6D-D4B6-4237-9866-4FFED36C03CD@collabora.co.uk>
References: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
 <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
 <51F633AE.8090308@collabora.co.uk>
 <alpine.DEB.2.02.1307290943000.30864@utopia.booyaka.com>
 <D135FD6D-D4B6-4237-9866-4FFED36C03CD@collabora.co.uk>
Message-ID: <CACRpkdZ1E9zC_yyK=UkJSejCwb_k7sYfhNgH5NASZ8Nf-qt2KA@mail.gmail.com>

On Mon, Jul 29, 2013 at 12:19 PM, Javier Martinez Canillas
<javier.martinez at collabora.co.uk> wrote:

> I guess the safer approach is to just revert these since they are causing
> a regression and what the patches aims to fix as been broken since the
> initial OMAP migration to DT anyways.

I have already reverted these and pushed to linux-next.

Actually input-hogs was not such a good idea either, after
meditating on this I realized that the information about what
GPIOs are used as interrupts is a piece of information that
already exist in the device tree, albeit a bit distributed.

So I'm drafting an RFC to indicate how I think this should
be solved.

Yours,
Linus Walleij


From thierry.reding at gmail.com  Mon Jul 29 07:44:38 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 29 Jul 2013 13:44:38 +0200
Subject: [PATCH v4 12/20] pwm: samsung: Rename to pwm-samsung-legacy
In-Reply-To: <1374278673-25615-14-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-14-git-send-email-tomasz.figa@gmail.com>
Message-ID: <20130729114437.GB23152@manwe>

On Sat, Jul 20, 2013 at 02:04:25AM +0200, Tomasz Figa wrote:
> This patch renames the old pwm-samsung driver to pwm-samsung-legacy to
> create place for the new, rewritten, DT-aware pwm-samsung driver using
> Samsung PWM/timer master driver.
> 
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> ---
>  drivers/pwm/Makefile                                | 2 +-
>  drivers/pwm/{pwm-samsung.c => pwm-samsung-legacy.c} | 0
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  rename drivers/pwm/{pwm-samsung.c => pwm-samsung-legacy.c} (100%)

Acked-by: Thierry Reding <thierry.reding at gmail.com>
-------------- 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/20130729/b9cc565c/attachment-0001.sig>

From thierry.reding at gmail.com  Mon Jul 29 07:44:52 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 29 Jul 2013 13:44:52 +0200
Subject: [PATCH v4 13/20] pwm: Add new pwm-samsung driver
In-Reply-To: <1374278673-25615-15-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-15-git-send-email-tomasz.figa@gmail.com>
Message-ID: <20130729114452.GC23152@manwe>

On Sat, Jul 20, 2013 at 02:04:26AM +0200, Tomasz Figa wrote:
> This patch introduces new Samsung PWM driver, which uses Samsung
> PWM/timer master driver to control shared parts of the hardware.
> 
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> ---
>  drivers/pwm/Makefile      |   1 +
>  drivers/pwm/pwm-samsung.c | 606 ++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 607 insertions(+)
>  create mode 100644 drivers/pwm/pwm-samsung.c

Acked-by: Thierry Reding <thierry.reding at gmail.com>
-------------- 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/20130729/87153f83/attachment.sig>

From thierry.reding at gmail.com  Mon Jul 29 07:45:32 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 29 Jul 2013 13:45:32 +0200
Subject: [PATCH v4 16/20] pwm: Remove superseded pwm-samsung-legacy driver
In-Reply-To: <1374278673-25615-18-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1374278673-25615-18-git-send-email-tomasz.figa@gmail.com>
Message-ID: <20130729114531.GD23152@manwe>

On Sat, Jul 20, 2013 at 02:04:29AM +0200, Tomasz Figa wrote:
> This patch removes the now unused pwm-samsung-legacy driver, which was
> replaced by new pwm-samsung driver.
> 
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> ---
>  drivers/pwm/Makefile             |   1 -
>  drivers/pwm/pwm-samsung-legacy.c | 353 ---------------------------------------
>  2 files changed, 354 deletions(-)
>  delete mode 100644 drivers/pwm/pwm-samsung-legacy.c

Acked-by: Thierry Reding <thierry.reding at gmail.com>
-------------- 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/20130729/74f9e49b/attachment.sig>

From lorenzo.pieralisi at arm.com  Mon Jul 29 07:50:16 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 29 Jul 2013 12:50:16 +0100
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value to
 index into save array
In-Reply-To: <1374550289-25305-2-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-2-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130729115016.GA6184@e102568-lin.cambridge.arm.com>

On Tue, Jul 23, 2013 at 04:31:17AM +0100, Nicolas Pitre wrote:
> Currently we hash the MPIDR of the CPU being suspended to determine which
> entry in the sleep_save_sp array to use. In some situations, such as when
> we want to resume on another physical CPU, the MPIDR of another CPU should
> be used instead.
> 
> So let's use the value of cpu_logical_map(smp_processor_id()) in place
> of the MPIDR in the suspend path.  This will result in the same index
> being used as with the previous code unless the caller has modified
> cpu_logical_map() beforehand.

I will rely on your wisdom to rewrite the commit log in a way that
does not hint at dangerous creativity, if you catch my drift :D

> The register allocation in __cpu_suspend is reworked in order to better
> accommodate the additional argument.
> 
> Signed-off-by: Nicolas Pitre <nico at linaro.org>
> ---
>  arch/arm/kernel/sleep.S   | 25 +++++++++++--------------
>  arch/arm/kernel/suspend.c |  8 +++++---
>  2 files changed, 16 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
> index db1536b8b3..836d10e698 100644
> --- a/arch/arm/kernel/sleep.S
> +++ b/arch/arm/kernel/sleep.S
> @@ -55,6 +55,7 @@
>   * specific registers and some other data for resume.
>   *  r0 = suspend function arg0
>   *  r1 = suspend function
> + *  r2 = MPIDR value used to index into sleep_save_sp

CPU's MPIDR or something like that, let's not hint at possible creative usage.

>   */
>  ENTRY(__cpu_suspend)
>  	stmfd	sp!, {r4 - r11, lr}
> @@ -67,23 +68,19 @@ ENTRY(__cpu_suspend)
>  	mov	r5, sp			@ current virtual SP
>  	add	r4, r4, #12		@ Space for pgd, virt sp, phys resume fn
>  	sub	sp, sp, r4		@ allocate CPU state on stack
> -	stmfd	sp!, {r0, r1}		@ save suspend func arg and pointer
> -	add	r0, sp, #8		@ save pointer to save block
> -	mov	r1, r4			@ size of save block
> -	mov	r2, r5			@ virtual SP
>  	ldr	r3, =sleep_save_sp
> +	stmfd	sp!, {r0, r1}		@ save suspend func arg and pointer
>  	ldr	r3, [r3, #SLEEP_SAVE_SP_VIRT]
> -	ALT_SMP(mrc p15, 0, r9, c0, c0, 5)
> -        ALT_UP_B(1f)
> -	ldr	r8, =mpidr_hash
> -	/*
> -	 * This ldmia relies on the memory layout of the mpidr_hash
> -	 * struct mpidr_hash.
> -	 */
> -	ldmia	r8, {r4-r7}	@ r4 = mpidr mask (r5,r6,r7) = l[0,1,2] shifts
> -	compute_mpidr_hash	lr, r5, r6, r7, r9, r4
> -	add	r3, r3, lr, lsl #2
> +	ALT_SMP(ldr r0, =mpidr_hash)
> +       ALT_UP_B(1f)

Should be a tab, do not know if that's an email server issue or not.

> +	/* This ldmia relies on the memory layout of the mpidr_hash struct */
> +	ldmia	r0, {r1, r6-r8}	@ r1 = mpidr mask (r6,r7,r8) = l[0,1,2] shifts
> +	compute_mpidr_hash	r0, r6, r7, r8, r2, r1
> +	add	r3, r3, r0, lsl #2
>  1:
> +	mov	r2, r5			@ virtual SP
> +	mov	r1, r4			@ size of save block
> +	add	r0, sp, #8		@ pointer to save block

It is already a bit complex to follow, code is ok, but line above was
better placed closer to sp last change, not after hashing the MPIDR.

>  	bl	__cpu_suspend_save
>  	adr	lr, BSYM(cpu_suspend_abort)
>  	ldmfd	sp!, {r0, pc}		@ call suspend fn
> diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
> index 41cf3cbf75..2835d35234 100644
> --- a/arch/arm/kernel/suspend.c
> +++ b/arch/arm/kernel/suspend.c
> @@ -10,7 +10,7 @@
>  #include <asm/suspend.h>
>  #include <asm/tlbflush.h>
>  
> -extern int __cpu_suspend(unsigned long, int (*)(unsigned long));
> +extern int __cpu_suspend(unsigned long, int (*)(unsigned long), u32 cpuid);
>  extern void cpu_resume_mmu(void);
>  
>  #ifdef CONFIG_MMU
> @@ -21,6 +21,7 @@ extern void cpu_resume_mmu(void);
>  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
>  {
>  	struct mm_struct *mm = current->active_mm;
> +	u32 __mpidr = cpu_logical_map(smp_processor_id());
>  	int ret;
>  
>  	if (!idmap_pgd)
> @@ -32,7 +33,7 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
>  	 * resume (indicated by a zero return code), we need to switch
>  	 * back to the correct page tables.
>  	 */
> -	ret = __cpu_suspend(arg, fn);
> +	ret = __cpu_suspend(arg, fn, __mpidr);
>  	if (ret == 0) {
>  		cpu_switch_mm(mm->pgd, mm);
>  		local_flush_bp_all();
> @@ -44,7 +45,8 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
>  #else
>  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
>  {
> -	return __cpu_suspend(arg, fn);
> +	u32 __mpidr = cpu_logical_map(smp_processor_id());
> +	return __cpu_suspend(arg, fn, __mpidr);
>  }
>  #define	idmap_pgd	NULL
>  #endif

Apart from these nits, let's hope it is the last cpu_suspend bit we need to
change, please land it on -next asap, of course if Russell is ok with that.

I tested it on TC2.

FWIW:

Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>



From maxime.ripard at free-electrons.com  Mon Jul 29 07:57:04 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 29 Jul 2013 13:57:04 +0200
Subject: [PATCH] ARM: sunxi: Remove Makefile.boot file
In-Reply-To: <1374649972-26088-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1374649972-26088-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20130729115704.GC1441@lukather>

On Wed, Jul 24, 2013 at 09:12:52AM +0200, Maxime Ripard wrote:
> Since we've been a multi-platform enabled kernel from the beginning,
> Makefile.boot has always been dead code.
> 
> Remove it.

Applied to sunxi/core-for-3.12.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130729/e5c6d640/attachment.sig>

From linux at roeck-us.net  Mon Jul 29 07:57:22 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 29 Jul 2013 04:57:22 -0700
Subject: [PATCH v6] watchdog: Add MOXA ART watchdog driver
In-Reply-To: <1375098093-8975-1-git-send-email-jonas.jensen@gmail.com>
References: <1375093215-7136-1-git-send-email-jonas.jensen@gmail.com>
 <1375098093-8975-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <51F658A2.2010007@roeck-us.net>

On 07/29/2013 04:41 AM, Jonas Jensen wrote:
> Add watchdog driver for MOXA ART SoCs.
>
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
> ---
>
> Notes:
>      Changes since v5:
>
>      1. replace "moxart_wdt->dev.timeout" with "wdt_dev->timeout"
>
>      Applies to next-20130729
>
>   .../bindings/watchdog/moxa,moxart-watchdog.txt     |  15 ++
>   drivers/watchdog/Kconfig                           |  10 ++
>   drivers/watchdog/Makefile                          |   1 +
>   drivers/watchdog/moxart_wdt.c                      | 165 +++++++++++++++++++++
>   4 files changed, 191 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
>   create mode 100644 drivers/watchdog/moxart_wdt.c
>
> diff --git a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
> new file mode 100644
> index 0000000..1169857
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
> @@ -0,0 +1,15 @@
> +MOXA ART Watchdog timer
> +
> +Required properties:
> +
> +- compatible : Must be "moxa,moxart-watchdog"
> +- reg : Should contain registers location and length
> +- clocks : Should contain phandle for the clock that drives the counter
> +
> +Example:
> +
> +	watchdog: watchdog at 98500000 {
> +		compatible = "moxa,moxart-watchdog";
> +		reg = <0x98500000 0x10>;
> +		clocks = <&coreclk>;
> +	};
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 362085d..6883aab 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -382,6 +382,16 @@ config RETU_WATCHDOG
>   	  To compile this driver as a module, choose M here: the
>   	  module will be called retu_wdt.
>
> +config MOXART_WDT
> +	tristate "MOXART watchdog"
> +	depends on ARCH_MOXART
> +	help
> +	  Say Y here to include Watchdog timer support for the watchdog
> +	  existing on the MOXA ART SoC series platforms.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called moxart_wdt.
> +
>   # AVR32 Architecture
>
>   config AT32AP700X_WDT
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 2f26a0b..7cab53a 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -54,6 +54,7 @@ obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
>   obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
>   obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
>   obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
> +obj-$(CONFIG_MOXART_WDT) += moxart_wdt.o
>
>   # AVR32 Architecture
>   obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
> new file mode 100644
> index 0000000..70b5806
> --- /dev/null
> +++ b/drivers/watchdog/moxart_wdt.c
> @@ -0,0 +1,165 @@
> +/*
> + * MOXA ART SoCs watchdog driver.
> + *
> + * Copyright (C) 2013 Jonas Jensen
> + *
> + * Jonas Jensen <jonas.jensen at gmail.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/err.h>
> +#include <linux/kernel.h>
> +#include <linux/platform_device.h>
> +#include <linux/watchdog.h>
> +#include <linux/moduleparam.h>
> +
> +#define REG_COUNT			0x4
> +#define REG_MODE			0x8
> +#define REG_ENABLE			0xC
> +
> +struct moxart_wdt_dev {
> +	struct watchdog_device dev;
> +	void __iomem *base;
> +	unsigned int clock_frequency;
> +};
> +
> +static int heartbeat;
> +
> +static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
> +
> +	writel(0, moxart_wdt->base + REG_ENABLE);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_start(struct watchdog_device *wdt_dev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
> +
> +	writel(moxart_wdt->clock_frequency * wdt_dev->timeout,
> +	       moxart_wdt->base + REG_COUNT);
> +	writel(0x5ab9, moxart_wdt->base + REG_MODE);
> +	writel(0x03, moxart_wdt->base + REG_ENABLE);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_set_timeout(struct watchdog_device *wdt_dev,
> +				  unsigned int timeout)
> +{
> +	wdt_dev->timeout = timeout;
> +
> +	return 0;
> +}
> +
> +static const struct watchdog_info moxart_wdt_info = {
> +	.identity       = "moxart-wdt",
> +	.options        = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
> +			  WDIOF_MAGICCLOSE,
> +};
> +
> +static const struct watchdog_ops moxart_wdt_ops = {
> +	.owner          = THIS_MODULE,
> +	.start          = moxart_wdt_start,
> +	.stop           = moxart_wdt_stop,
> +	.set_timeout    = moxart_wdt_set_timeout,
> +};
> +
> +static int moxart_wdt_probe(struct platform_device *pdev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt;
> +	struct device *dev = &pdev->dev;

I have my nitpicking day ;). Even though you declare dev = &pdev->dev,
you use &pdev->dev several times below.

Assuming you change this, feel free to add

Reviewed-by: Guenter Roeck <linux at roeck-us.net>


> +	struct device_node *node = dev->of_node;
> +	struct resource *res;
> +	struct clk *clk;
> +	int err;
> +	unsigned int max_timeout;
> +	bool nowayout = WATCHDOG_NOWAYOUT;
> +
> +	moxart_wdt = devm_kzalloc(&pdev->dev, sizeof(*moxart_wdt), GFP_KERNEL);
> +	if (!moxart_wdt)
> +		return -ENOMEM;
> +
> +	platform_set_drvdata(pdev, moxart_wdt);
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	moxart_wdt->base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(moxart_wdt->base))
> +		return PTR_ERR(moxart_wdt->base);
> +
> +	clk = of_clk_get(node, 0);
> +	if (IS_ERR(clk)) {
> +		pr_err("%s: of_clk_get failed\n", __func__);
> +		return PTR_ERR(clk);
> +	}
> +
> +	moxart_wdt->clock_frequency = clk_get_rate(clk);
> +	if (moxart_wdt->clock_frequency == 0) {
> +		pr_err("%s: incorrect clock frequency\n", __func__);
> +		return -EINVAL;
> +	}
> +
> +	max_timeout = UINT_MAX / moxart_wdt->clock_frequency;
> +
> +	moxart_wdt->dev.info = &moxart_wdt_info;
> +	moxart_wdt->dev.ops = &moxart_wdt_ops;
> +	moxart_wdt->dev.timeout = max_timeout;
> +	moxart_wdt->dev.min_timeout = 1;
> +	moxart_wdt->dev.max_timeout = max_timeout;
> +	moxart_wdt->dev.parent = &pdev->dev;
> +
> +	watchdog_init_timeout(&moxart_wdt->dev, heartbeat, &pdev->dev);
> +	watchdog_set_nowayout(&moxart_wdt->dev, nowayout);
> +
> +	watchdog_set_drvdata(&moxart_wdt->dev, moxart_wdt);
> +
> +	err = watchdog_register_device(&moxart_wdt->dev);
> +	if (unlikely(err))
> +		return err;
> +
> +	dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
> +		moxart_wdt->dev.timeout, nowayout);
> +
> +	return 0;
> +}
> +
> +static int moxart_wdt_remove(struct platform_device *pdev)
> +{
> +	struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
> +
> +	moxart_wdt_stop(&moxart_wdt->dev);
> +	watchdog_unregister_device(&moxart_wdt->dev);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id moxart_watchdog_match[] = {
> +	{ .compatible = "moxa,moxart-watchdog" },
> +	{ },
> +};
> +
> +static struct platform_driver moxart_wdt_driver = {
> +	.probe      = moxart_wdt_probe,
> +	.remove     = moxart_wdt_remove,
> +	.driver     = {
> +		.name		= "moxart-watchdog",
> +		.owner		= THIS_MODULE,
> +		.of_match_table	= moxart_watchdog_match,
> +	},
> +};
> +module_platform_driver(moxart_wdt_driver);
> +
> +module_param(heartbeat, int, 0);
> +MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");
> +
> +MODULE_DESCRIPTION("MOXART watchdog driver");
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
>



From padma.kvr at gmail.com  Mon Jul 29 08:01:16 2013
From: padma.kvr at gmail.com (Padma Venkat)
Date: Mon, 29 Jul 2013 17:31:16 +0530
Subject: [PATCH V2 7/8] ARM: dts: wm8994: Add wm8994 support on smdk5420
In-Reply-To: <CAAgF-Be8SNxTZv1yFCwH6yJ-O_3R4reh=3y+pSCLJYW7S9TkUg@mail.gmail.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-8-git-send-email-padma.v@samsung.com>
 <20130726151902.GL9858@sirena.org.uk>
 <CAAgF-Be8SNxTZv1yFCwH6yJ-O_3R4reh=3y+pSCLJYW7S9TkUg@mail.gmail.com>
Message-ID: <CAAgF-Bexp_fGT8KV+TQ0_kZLJBtq7UK=TG4eYRA6qpTSL+scxg@mail.gmail.com>

Hi Mark,

On Sat, Jul 27, 2013 at 6:46 AM, Padma Venkat <padma.kvr at gmail.com> wrote:
> Hi Mark,
>
> On Fri, Jul 26, 2013 at 8:49 PM, Mark Brown <broonie at kernel.org> wrote:
>> On Fri, Jul 26, 2013 at 07:06:51PM +0530, Padmavathi Venna wrote:
>>> This patch adds wm8994 codec node on i2c bus1 and the required
>>> regulator supplies and properties on smdk5420 board.
>>
>> This isn't a device tree patch for WM8994, it's a patch for the
>> SMDK5420.
>
> Yes. I will correct the subject.
>
>>
>>> +     vdd: fixed-regulator at 0 {
>>> +             compatible = "regulator-fixed";
>>> +             regulator-name = "vdd-supply";
>>
>> These names look wrong - they should reflect the names in the schematic
>> as they're for human comprehensibility.  This may just be a case of
>> dropping the -supply.
>

When I posted the same patch for smdk5250, you asked me to club all
the same supply regulators. So I clubbed AVDD2 and CPVDD. So any other
better name for representing both supplies?

> OK.
>
>>
>>> +             wm8994: wm8994 at 1a {
>>> +                     compatible = "wlf,wm8994";
>>> +                     reg = <0x1a>;
>>> +
>>> +                     gpio-controller;
>>> +                     #gpio-cells = <2>;
>>> +
>>> +                     AVDD2-supply = <&vdd>;
>>> +                     CPVDD-supply = <&vdd>;
>>> +                     DBVDD-supply = <&dbvdd>;
>>> +                     SPKVDD1-supply = <&spkvdd>;
>>> +                     SPKVDD2-supply = <&spkvdd>;
>>> +             };
>>
>> It would be helpful to also add a clock binding (I posted a binding
>> documentation update the other day, it's in my tree now) but it's not
>> essential and I suspect it needs some work on the clock driver side
>> still.
>
> OK. I will check this.

As per schemata, input clock to MCLK1 is an oscillator clock with
16.9MHz and MCLK2 not showing any input clock. So here I need to add a
fixed rate clock with 16.9MHz as MCLK1 in the smdk board file.

Is it correct?

Thanks
Padma


From linux at arm.linux.org.uk  Mon Jul 29 08:08:30 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 29 Jul 2013 13:08:30 +0100
Subject: [PATCH] DMAEngine: sirf: let the users be able to pause and
 resume specific buffer
In-Reply-To: <CAGsJ_4wOdDMku-pNWiH-DoS_v39PfFwNYcU4T1Thsd-+L9A8AQ@mail.gmail.com>
References: <1372927373-17407-1-git-send-email-Baohua.Song@csr.com>
 <CAGsJ_4wOdDMku-pNWiH-DoS_v39PfFwNYcU4T1Thsd-+L9A8AQ@mail.gmail.com>
Message-ID: <20130729120830.GH24642@n2100.arm.linux.org.uk>

On Mon, Jul 29, 2013 at 10:14:24AM +0800, Barry Song wrote:
> 2013/7/4 Barry Song <Baohua.Song at csr.com>
> >
> > From: Qipan Li <Qipan.Li at csr.com>
> >
> > this patch adds a buffer_index in pause and resume entries, then users
> > can pause and resume a buffer they want, but don't pause the whole dma.
> >
> > a typical application scenerios is Ping-Pang in two buffers:
> > at the beginning, we enable buf1 and buf2 to receive dma data, after
> > buf1 is full, we pause buf1 and handle the data in this buffer to avoid
> > overflow in buf1. but at the same time, dma is still tranferring in buf2.
> > once we have finished data process in buf1, we enable buf1 again.
> > this will maximize the chance of dma transferring. users pause buf1 by:
> > dmaengine_device_control(sirfport->rx_dma_chan, DMA_PAUSE, 1);
> > users pause buf2 by:
> > dmaengine_device_control(sirfport->rx_dma_chan, DMA_PAUSE, 2);
> > users can still pause the whole dma transferring by dmaengine_pause().
> >
> > Signed-off-by: Qipan Li <Qipan.Li at csr.com>
> > Signed-off-by: Barry Song <Baohua.Song at csr.com>
> > ---
> >  drivers/dma/sirf-dma.c | 102
> > ++++++++++++++++++++++++++++++++++++++-----------
> >  1 file changed, 80 insertions(+), 22 deletions(-)
> 
> Hi Vinod, as we still have some other patches of dma clients depending
> on this, would you give some comments about it?

You at least need to write up some documentation about this new
feature - you need to describe exactly how this argument relates to
a set of queued DMA descriptor(s) and its semantics with respect to
those queued descriptors.

>From the looks of this patch, it has nothing to do with any particular
queued descriptor, but you're exposing internal knowledge of the SiRF
DMA engine.


From vinod.koul at intel.com  Mon Jul 29 07:35:07 2013
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 29 Jul 2013 17:05:07 +0530
Subject: [PATCH] DMAEngine: sirf: let the users be able to pause and
 resume specific buffer
In-Reply-To: <20130729120830.GH24642@n2100.arm.linux.org.uk>
References: <1372927373-17407-1-git-send-email-Baohua.Song@csr.com>
 <CAGsJ_4wOdDMku-pNWiH-DoS_v39PfFwNYcU4T1Thsd-+L9A8AQ@mail.gmail.com>
 <20130729120830.GH24642@n2100.arm.linux.org.uk>
Message-ID: <20130729113507.GJ29095@intel.com>

On Mon, Jul 29, 2013 at 01:08:30PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 29, 2013 at 10:14:24AM +0800, Barry Song wrote:
> > 2013/7/4 Barry Song <Baohua.Song at csr.com>
> > >
> > > From: Qipan Li <Qipan.Li at csr.com>
> > >
> > > this patch adds a buffer_index in pause and resume entries, then users can
> > > pause and resume a buffer they want, but don't pause the whole dma.
> > >
> > > a typical application scenerios is Ping-Pang in two buffers: at the
> > > beginning, we enable buf1 and buf2 to receive dma data, after buf1 is
> > > full, we pause buf1 and handle the data in this buffer to avoid overflow
> > > in buf1. but at the same time, dma is still tranferring in buf2.  once we
> > > have finished data process in buf1, we enable buf1 again.  this will
> > > maximize the chance of dma transferring. users pause buf1 by:
> > > dmaengine_device_control(sirfport->rx_dma_chan, DMA_PAUSE, 1); users pause
> > > buf2 by: dmaengine_device_control(sirfport->rx_dma_chan, DMA_PAUSE, 2);
> > > users can still pause the whole dma transferring by dmaengine_pause().
> > >
> > > Signed-off-by: Qipan Li <Qipan.Li at csr.com> Signed-off-by: Barry Song
> > > <Baohua.Song at csr.com> --- drivers/dma/sirf-dma.c | 102
> > > ++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 80
> > > insertions(+), 22 deletions(-)
> > 
> > Hi Vinod, as we still have some other patches of dma clients depending on
> > this, would you give some comments about it?
> 
> You at least need to write up some documentation about this new feature - you
> need to describe exactly how this argument relates to a set of queued DMA
> descriptor(s) and its semantics with respect to those queued descriptors.
As I commented earlier today, I dont think we need this way. This can also be
achieved with submitting descriptors after the buffer has been processed.

> From the looks of this patch, it has nothing to do with any particular
> queued descriptor, but you're exposing internal knowledge of the SiRF
> DMA engine.
More than dmaengine its the way of modelling here which seems to be the issue

~Vinod
-- 


From p.zabel at pengutronix.de  Mon Jul 29 08:16:11 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon, 29 Jul 2013 14:16:11 +0200
Subject: [GIT PULL] Reset controller changes for 3.12
Message-ID: <1375100171.4223.10.camel@pizza.hi.pengutronix.de>

Hi Olof,

with the cosmetic issues pointed out by Ben and Sylwester fixed in the
gpio-reset driver, the following changes since commit
5ae90d8e467e625e447000cb4335c4db973b1095:

  Linux 3.11-rc3 (2013-07-28 20:53:33 -0700)

are available in the git repository at:

  git://git.pengutronix.de/git/pza/linux.git reset/for_v3.12

for you to fetch changes up to f4d36f8a5166405154c638c1e49e253f2f017dd7:

  reset: allow drivers to request probe deferral (2013-07-29 14:03:40
+0200)

----------------------------------------------------------------
Philipp Zabel (2):
      reset: Add driver for gpio-controlled reset pins
      reset: allow drivers to request probe deferral

 .../devicetree/bindings/reset/gpio-reset.txt       |  35 +++++
 drivers/reset/Kconfig                              |  11 ++
 drivers/reset/Makefile                             |   1 +
 drivers/reset/core.c                               |   2 +-
 drivers/reset/gpio-reset.c                         | 174
+++++++++++++++++++++
 5 files changed, 222 insertions(+), 1 deletion(-)
 create mode 100644
Documentation/devicetree/bindings/reset/gpio-reset.txt
 create mode 100644 drivers/reset/gpio-reset.c




From linux at arm.linux.org.uk  Mon Jul 29 08:17:15 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 29 Jul 2013 13:17:15 +0100
Subject: [PATCH] DMAEngine: sirf: let the users be able to pause and
 resume specific buffer
In-Reply-To: <CAGsJ_4yVxAJc0UNTFMM1yjKQh6=xv12qPYpnUFZ=wmzrdpUOXQ@mail.gmail.com>
References: <1372927373-17407-1-git-send-email-Baohua.Song@csr.com>
 <CAGsJ_4wOdDMku-pNWiH-DoS_v39PfFwNYcU4T1Thsd-+L9A8AQ@mail.gmail.com>
 <20130729060819.GE29095@intel.com>
 <CAGsJ_4yVxAJc0UNTFMM1yjKQh6=xv12qPYpnUFZ=wmzrdpUOXQ@mail.gmail.com>
Message-ID: <20130729121715.GI24642@n2100.arm.linux.org.uk>

On Mon, Jul 29, 2013 at 03:20:31PM +0800, Barry Song wrote:
> 2013/7/29 Vinod Koul <vinod.koul at intel.com>:
> > The above can be done by
> > a) have two buffers:
> >         - prepare first and submit, and start
> >         - while first is ongoing, prepare second and start
> >         - first is completed, so you start processing that while second is
> >           getting DMAed
> >         - when processing is completed, submit first again
> >         - when second is completed, start processing that and submit that once
> >           proocessed
> >
> > b) have multiple buffers, A, B, C & D and redo above schema.
> 
> yes, that is the original idea for multiple buffer management for DMA.
> 
> the reason which pushed us to the ping-pong pause is that we don't
> need to issue software dma descriptor every time for every buffer as
> hardware can do that.

If your DMA engine is correctly implemented (and this only works for
correctly implemented DMA engines), what you can do is:

- at the start of the transfer, prepare, submit and issue two buffers,
  each with a callback.
- when the first callback happens
  - that buffer has been transferred.
  - you can now do whatever you need with that data.
  - prepare, submit and issue the next buffer

This means the DMA engine always has a buffer available to it, so if
your CPU is fast enough, you can keep the transfer going without the
DMA channel ever stopping or having to be paused.  If your CPU isn't
fast enough to keep up, the DMA engine will stop at the end of the
last queued and issued buffer automatically.

Bonus points if you have implemented the "move to next buffer" correctly
too, so that the hardware can do a continuous transfer without having to
stop and wait between the buffers (provided of course that the next
transfer is compatible with the previous.)


From balbi at ti.com  Mon Jul 29 08:23:44 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 29 Jul 2013 15:23:44 +0300
Subject: [PATCH v2 1/6] usb: phy: msm: Move mach depndend code to
 platform data
In-Reply-To: <1375081464-14206-2-git-send-email-iivanov@mm-sol.com>
References: <1375081464-14206-1-git-send-email-iivanov@mm-sol.com>
 <1375081464-14206-2-git-send-email-iivanov@mm-sol.com>
Message-ID: <20130729122344.GH24801@radagast>

Hi,

On Mon, Jul 29, 2013 at 10:04:19AM +0300, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov" <iivanov at mm-sol.com>
> 
> This patch fix compilation error and is an intermediate step
> before the addition of DeviceTree support for newer targets.
> Fix suggested here: https://lkml.org/lkml/2013/6/19/381
> 
> Cc: David Brown <davidb at codeaurora.org>
> Cc: Daniel Walker <dwalker at fifo99.com>
> Cc: Bryan Huntsman <bryanh at codeaurora.org>
> Cc: Felipe Balbi <balbi at ti.com>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-usb at vger.kernel.org
> 
> Signed-off-by: Ivan T. Ivanov <iivanov at mm-sol.com>
> ---
>  arch/arm/mach-msm/board-msm7x30.c |   35 +++++++++++++++++++++++
>  arch/arm/mach-msm/board-qsd8x50.c |   35 +++++++++++++++++++++++

I need acks for these.

>  drivers/usb/phy/phy-msm-usb.c     |   55 ++++++++++---------------------------
>  include/linux/usb/msm_hsusb.h     |    3 ++
>  4 files changed, 87 insertions(+), 41 deletions(-)
> 
> diff --git a/arch/arm/mach-msm/board-msm7x30.c b/arch/arm/mach-msm/board-msm7x30.c
> index db3d8c0..6b35953 100644
> --- a/arch/arm/mach-msm/board-msm7x30.c
> +++ b/arch/arm/mach-msm/board-msm7x30.c
> @@ -31,6 +31,7 @@
>  #include <asm/setup.h>
>  
>  #include <mach/board.h>
> +#include <mach/clk.h>
>  #include <mach/msm_iomap.h>
>  #include <mach/dma.h>
>  
> @@ -61,10 +62,44 @@ static int hsusb_phy_init_seq[] = {
>  	-1
>  };
>  
> +static int hsusb_link_clk_reset(struct clk *link_clk, bool assert)

looks like you should be using the reset controller framework ?
(drivers/reset)

-- 
balbi
-------------- 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/20130729/77f677a7/attachment-0001.sig>

From thomas.petazzoni at free-electrons.com  Mon Jul 29 08:26:00 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 29 Jul 2013 14:26:00 +0200
Subject: [PATCHv5 05/11] of: pci: add registry of MSI chips
In-Reply-To: <20130729065431.GA1115@manwe>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E41F7A.4010502@gmail.com> <20130728043310.6CF1D3E08FE@localhost>
 <20130728162711.32a9a21e@skate> <20130729065431.GA1115@manwe>
Message-ID: <20130729142600.63eeab50@skate>

Dear Thierry Reding,

On Mon, 29 Jul 2013 08:54:31 +0200, Thierry Reding wrote:

> > So what is your suggestion to allow the PCIe controller to retrieve the
> > correct irq_domain if we have only one DT node for the IRQ controller
> > that registers two irq_domains ?
> 
> If I understand correctly, Grant isn't objecting to the introduction of
> the lookup function, but rather its implementation. You could add a
> pointer to a struct msi_chip within struct irq_domain and then iterate
> over all irq_domain instances (see irq_find_host()) and find one which
> has the correct device_node pointer and the msi_chip pointer set.

Ah ok. The only trick is that we have to change irq_find_host() to
*not* match on MSI domains. Can you check the below patch to see if it
matches what Grant suggested? It works for me, and it allows to completely
remove the registry of msi_chip in drivers/of, as well as the of_node
pointer in struct msi_chip.

Thanks!

Thomas

From c2c0137cb110270f96e1e0fa298a5d585b8d829e Mon Sep 17 00:00:00 2001
From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Date: Mon, 29 Jul 2013 14:12:31 +0200
Subject: [PATCHv6 05/11] irqdomain: add support to associate an irq_domain
 with a msi_chip

Message Signaled Interrupts are a PCI-specific mechanism that allows
PCI devices to notify interrupts to the CPU using in-band
messages. The PCI subsystem represents an MSI-capable interrupt
controller as an msi_chip structure, and this patch improves the
irqdomain subsystem with a new pointer associating an irq_domain with
the corresponding msi_chip.

The __irq_domain_add() function is augmented with an additional
argument, the 'msi_chip' pointer, and all callers of this function are
updated.

A new function irq_domain_add_msi() function is added to allow the
registration of an MSI-type irq domain.

The irq_find_host() function is modified to not match on MSI-type irq
domains: a given DT device node may represent both a normal interrupt
controller and a MSI interrupt controller. irq_find_host() should
return the irq_domain that corresponds to the normal interupt
controller.

An irq_find_msi() function is added to get the MSI_type irq domain
given a DT device node.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 include/linux/irqdomain.h | 20 +++++++++++++++++---
 kernel/irq/irqdomain.c    | 35 +++++++++++++++++++++++++++++++++--
 2 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 1ffa336..f1b11c8 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -38,6 +38,7 @@
 struct device_node;
 struct irq_domain;
 struct of_device_id;
+struct msi_chip;
 
 /* Number of irqs reserved for a legacy isa controller */
 #define NUM_ISA_INTERRUPTS	16
@@ -101,6 +102,7 @@ struct irq_domain {
 	/* Optional data */
 	struct device_node *of_node;
 	struct irq_domain_chip_generic *gc;
+	struct msi_chip *msi_chip;
 
 	/* reverse map data. The linear map gets appended to the irq_domain */
 	irq_hw_number_t hwirq_max;
@@ -114,6 +116,7 @@ struct irq_domain {
 struct irq_domain *__irq_domain_add(struct device_node *of_node, int size,
 				    irq_hw_number_t hwirq_max, int direct_max,
 				    const struct irq_domain_ops *ops,
+				    struct msi_chip *msi_chip,
 				    void *host_data);
 struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
 					 unsigned int size,
@@ -127,6 +130,7 @@ struct irq_domain *irq_domain_add_legacy(struct device_node *of_node,
 					 const struct irq_domain_ops *ops,
 					 void *host_data);
 extern struct irq_domain *irq_find_host(struct device_node *node);
+extern struct irq_domain *irq_find_msi(struct device_node *node);
 extern void irq_set_default_host(struct irq_domain *host);
 
 /**
@@ -141,14 +145,15 @@ static inline struct irq_domain *irq_domain_add_linear(struct device_node *of_no
 					 const struct irq_domain_ops *ops,
 					 void *host_data)
 {
-	return __irq_domain_add(of_node, size, size, 0, ops, host_data);
+	return __irq_domain_add(of_node, size, size, 0, ops, NULL, host_data);
 }
 static inline struct irq_domain *irq_domain_add_nomap(struct device_node *of_node,
 					 unsigned int max_irq,
 					 const struct irq_domain_ops *ops,
 					 void *host_data)
 {
-	return __irq_domain_add(of_node, 0, max_irq, max_irq, ops, host_data);
+	return __irq_domain_add(of_node, 0, max_irq, max_irq, ops, NULL,
+				host_data);
 }
 static inline struct irq_domain *irq_domain_add_legacy_isa(
 				struct device_node *of_node,
@@ -162,7 +167,16 @@ static inline struct irq_domain *irq_domain_add_tree(struct device_node *of_node
 					 const struct irq_domain_ops *ops,
 					 void *host_data)
 {
-	return __irq_domain_add(of_node, 0, ~0, 0, ops, host_data);
+	return __irq_domain_add(of_node, 0, ~0, 0, ops, NULL, host_data);
+}
+static inline struct irq_domain *irq_domain_add_msi(struct device_node *of_node,
+						    unsigned int size,
+						    const struct irq_domain_ops *ops,
+						    struct msi_chip *msi_chip,
+						    void *host_data)
+{
+	return __irq_domain_add(of_node, size, size, 0, ops,
+				msi_chip, host_data);
 }
 
 extern void irq_domain_remove(struct irq_domain *host);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index b9ddb94..80dc1ca 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -29,6 +29,7 @@ static struct irq_domain *irq_default_domain;
  * @direct_max: Maximum value of direct maps; Use ~0 for no limit; 0 for no
  *              direct mapping
  * @ops: map/unmap domain callbacks
+ * @msi_chip: pointer to MSI chip structure, for MSI domains
  * @host_data: Controller private data pointer
  *
  * Allocates and initialize and irq_domain structure.  Caller is expected to
@@ -38,6 +39,7 @@ static struct irq_domain *irq_default_domain;
 struct irq_domain *__irq_domain_add(struct device_node *of_node, int size,
 				    irq_hw_number_t hwirq_max, int direct_max,
 				    const struct irq_domain_ops *ops,
+				    struct msi_chip *msi_chip,
 				    void *host_data)
 {
 	struct irq_domain *domain;
@@ -52,6 +54,7 @@ struct irq_domain *__irq_domain_add(struct device_node *of_node, int size,
 	domain->ops = ops;
 	domain->host_data = host_data;
 	domain->of_node = of_node_get(of_node);
+	domain->msi_chip = msi_chip;
 	domain->hwirq_max = hwirq_max;
 	domain->revmap_size = size;
 	domain->revmap_direct_max_irq = direct_max;
@@ -127,7 +130,7 @@ struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
 {
 	struct irq_domain *domain;
 
-	domain = __irq_domain_add(of_node, size, size, 0, ops, host_data);
+	domain = __irq_domain_add(of_node, size, size, 0, ops, NULL, host_data);
 	if (!domain)
 		return NULL;
 
@@ -172,7 +175,7 @@ struct irq_domain *irq_domain_add_legacy(struct device_node *of_node,
 	struct irq_domain *domain;
 
 	domain = __irq_domain_add(of_node, first_hwirq + size,
-				  first_hwirq + size, 0, ops, host_data);
+				  first_hwirq + size, 0, ops, NULL, host_data);
 	if (!domain)
 		return NULL;
 
@@ -198,6 +201,12 @@ struct irq_domain *irq_find_host(struct device_node *node)
 	 */
 	mutex_lock(&irq_domain_mutex);
 	list_for_each_entry(h, &irq_domain_list, link) {
+		/*
+		 * We only want to match normal interrupt domains, not
+		 * MSI domains
+		 */
+		if (h->msi_chip)
+			continue;
 		if (h->ops->match)
 			rc = h->ops->match(h, node);
 		else
@@ -214,6 +223,28 @@ struct irq_domain *irq_find_host(struct device_node *node)
 EXPORT_SYMBOL_GPL(irq_find_host);
 
 /**
+ * irq_find_msi() - Locates a MSI domain for a given device node
+ * @node: device-tree node of the interrupt controller
+ */
+struct irq_domain *irq_find_msi(struct device_node *node)
+{
+	struct irq_domain *h, *found = NULL;
+
+	mutex_lock(&irq_domain_mutex);
+	list_for_each_entry(h, &irq_domain_list, link) {
+		if (!h->msi_chip)
+			continue;
+		if (h->of_node && h->of_node == node) {
+			found = h;
+			break;
+		}
+	}
+	mutex_unlock(&irq_domain_mutex);
+	return found;
+}
+EXPORT_SYMBOL_GPL(irq_find_msi);
+
+/**
  * irq_set_default_host() - Set a "default" irq domain
  * @domain: default domain pointer
  *
-- 
1.8.1.2




-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From sebastian.hesselbarth at gmail.com  Mon Jul 29 08:29:05 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Jul 2013 14:29:05 +0200
Subject: [PATCH 3/4] ARM: dove: add GPIO IR receiver node to SolidRun CuBox
In-Reply-To: <1375100946-28521-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1375100946-28521-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1375100946-28521-4-git-send-email-sebastian.hesselbarth@gmail.com>

This adds a node for the IR receiver connected to a GPIO pin on the
SolidRun CuBox.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove-cubox.dts |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/dove-cubox.dts b/arch/arm/boot/dts/dove-cubox.dts
index 525fb45..022646e 100644
--- a/arch/arm/boot/dts/dove-cubox.dts
+++ b/arch/arm/boot/dts/dove-cubox.dts
@@ -55,6 +55,13 @@
 			clock-frequency = <25000000>;
 		};
 	};
+
+	ir_recv: ir-receiver {
+		compatible = "gpio-ir-receiver";
+		gpios = <&gpio0 19 1>;
+		pinctrl-0 = <&pmx_gpio_19>;
+		pinctrl-names = "default";
+	};
 };
 
 &uart0 { status = "okay"; };
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Mon Jul 29 08:29:02 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Jul 2013 14:29:02 +0200
Subject: [PATCH 0/4] ARM: dove: DT updates for v3.11-rc2
Message-ID: <1375100946-28521-1-git-send-email-sebastian.hesselbarth@gmail.com>

This patch set comprises some DT updates and cleanup patches that
piled up in the past. The first patch adds a cpu node for the
Marvell Sheeva PJ4(A) CPU found on Dove SoCs. While touching the
dtsi, also some nodes are renamed to achieve a consitent naming
scheme. The second patch adds some common pinmux settings to
the SoC's pinctrl node and moves the default pinctrl properties to
the corresponding nodes. The third patch adds a node for the
IR diode connected to a GPIO pin on SolidRun CuBox. Finally,
the last patch adds an initial DT file for the Globalscale D2Plug
which is also based on Marvell Dove SoC.

The whole patch set is based on v3.11-rc2 with DT part of
mv643xx_eth and irqchip/clocksource patches applied.

Although this patches are Marvell Dove only, the whole set is also
sent to devicetree mailing list to raise attention for potential DT
binding review.

Sebastian Hesselbarth (4):
  ARM: dove: add cpu device tree node
  ARM: dove: add common pinmux functions to DT
  ARM: dove: add GPIO IR receiver node to SolidRun CuBox
  ARM: dove: add initial DT file for Globalscale D2Plug

 arch/arm/boot/dts/Makefile        |    1 +
 arch/arm/boot/dts/dove-cubox.dts  |   30 ++---
 arch/arm/boot/dts/dove-d2plug.dts |   69 +++++++++++
 arch/arm/boot/dts/dove.dtsi       |  235 +++++++++++++++++++++++++++++++++----
 4 files changed, 295 insertions(+), 40 deletions(-)
 create mode 100644 arch/arm/boot/dts/dove-d2plug.dts

---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Mon Jul 29 08:29:04 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Jul 2013 14:29:04 +0200
Subject: [PATCH 2/4] ARM: dove: add common pinmux functions to DT
In-Reply-To: <1375100946-28521-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1375100946-28521-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1375100946-28521-3-git-send-email-sebastian.hesselbarth@gmail.com>

This adds common dedicated and gpio pinmux functions to SoC pinctrl
node. It also relocates pinctrl references to corresponding DT nodes.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove-cubox.dts |   23 +----
 arch/arm/boot/dts/dove.dtsi      |  183 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 186 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/dove-cubox.dts b/arch/arm/boot/dts/dove-cubox.dts
index 955188f..525fb45 100644
--- a/arch/arm/boot/dts/dove-cubox.dts
+++ b/arch/arm/boot/dts/dove-cubox.dts
@@ -42,6 +42,8 @@
 			regulator-always-on;
 			regulator-boot-on;
 			gpio = <&gpio0 1 0>;
+			pinctrl-0 = <&pmx_gpio_1>;
+			pinctrl-names = "default";
 		};
 	};
 
@@ -110,6 +112,7 @@
 	status = "okay";
 	/* sdio0 card detect is connected to wrong pin on CuBox */
 	cd-gpios = <&gpio0 12 1>;
+	pinctrl-0 = <&pmx_sdio0 &pmx_gpio_12>;
 };
 
 &spi0 {
@@ -122,23 +125,3 @@
 		reg = <0>;
 	};
 };
-
-&pinctrl {
-	pinctrl-0 = <&pmx_gpio_1 &pmx_gpio_12>;
-	pinctrl-names = "default";
-
-	pmx_gpio_1: pmx-gpio-1 {
-		marvell,pins = "mpp1";
-		marvell,function = "gpio";
-	};
-
-	pmx_gpio_12: pmx-gpio-12 {
-		marvell,pins = "mpp12";
-		marvell,function = "gpio";
-	};
-
-	pmx_gpio_18: pmx-gpio-18 {
-		marvell,pins = "mpp18";
-		marvell,function = "gpio";
-	};
-};
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 09d9710..90257c7 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -99,6 +99,8 @@
 			reg-shift = <2>;
 			interrupts = <8>;
 			clocks = <&core_clk 0>;
+			pinctrl-0 = <&pmx_uart1>;
+			pinctrl-names = "default";
 			status = "disabled";
 		};
 
@@ -154,6 +156,181 @@
 			compatible = "marvell,dove-pinctrl";
 			reg = <0xd0200 0x10>;
 			clocks = <&gate_clk 22>;
+
+			pmx_gpio_0: pmx-gpio-0 {
+				marvell,pins = "mpp0";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_1: pmx-gpio-1 {
+				marvell,pins = "mpp1";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_2: pmx-gpio-2 {
+				marvell,pins = "mpp2";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_3: pmx-gpio-3 {
+				marvell,pins = "mpp3";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_4: pmx-gpio-4 {
+				marvell,pins = "mpp4";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_5: pmx-gpio-5 {
+				marvell,pins = "mpp5";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_6: pmx-gpio-6 {
+				marvell,pins = "mpp6";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_7: pmx-gpio-7 {
+				marvell,pins = "mpp7";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_8: pmx-gpio-8 {
+				marvell,pins = "mpp8";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_9: pmx-gpio-9 {
+				marvell,pins = "mpp9";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_10: pmx-gpio-10 {
+				marvell,pins = "mpp10";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_11: pmx-gpio-11 {
+				marvell,pins = "mpp11";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_12: pmx-gpio-12 {
+				marvell,pins = "mpp12";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_13: pmx-gpio-13 {
+				marvell,pins = "mpp13";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_14: pmx-gpio-14 {
+				marvell,pins = "mpp14";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_15: pmx-gpio-15 {
+				marvell,pins = "mpp15";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_16: pmx-gpio-16 {
+				marvell,pins = "mpp16";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_17: pmx-gpio-17 {
+				marvell,pins = "mpp17";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_18: pmx-gpio-18 {
+				marvell,pins = "mpp18";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_19: pmx-gpio-19 {
+				marvell,pins = "mpp19";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_20: pmx-gpio-20 {
+				marvell,pins = "mpp20";
+				marvell,function = "gpio";
+			};
+
+			pmx_gpio_21: pmx-gpio-21 {
+				marvell,pins = "mpp21";
+				marvell,function = "gpio";
+			};
+
+			pmx_camera: pmx-camera {
+				marvell,pins = "mpp_camera";
+				marvell,function = "camera";
+			};
+
+			pmx_camera_gpio: pmx-camera-gpio {
+				marvell,pins = "mpp_camera";
+				marvell,function = "gpio";
+			};
+
+			pmx_sdio0: pmx-sdio0 {
+				marvell,pins = "mpp_sdio0";
+				marvell,function = "sdio0";
+			};
+
+			pmx_sdio0_gpio: pmx-sdio0-gpio {
+				marvell,pins = "mpp_sdio0";
+				marvell,function = "gpio";
+			};
+
+			pmx_sdio1: pmx-sdio1 {
+				marvell,pins = "mpp_sdio1";
+				marvell,function = "sdio1";
+			};
+
+			pmx_sdio1_gpio: pmx-sdio1-gpio {
+				marvell,pins = "mpp_sdio1";
+				marvell,function = "gpio";
+			};
+
+			pmx_audio1_gpio: pmx-audio1-gpio {
+				marvell,pins = "mpp_audio1";
+				marvell,function = "gpio";
+			};
+
+			pmx_spi0: pmx-spi0 {
+				marvell,pins = "mpp_spi0";
+				marvell,function = "spi0";
+			};
+
+			pmx_spi0_gpio: pmx-spi0-gpio {
+				marvell,pins = "mpp_spi0";
+				marvell,function = "gpio";
+			};
+
+			pmx_uart1: pmx-uart1 {
+				marvell,pins = "mpp_uart1";
+				marvell,function = "uart1";
+			};
+
+			pmx_uart1_gpio: pmx-uart1-gpio {
+				marvell,pins = "mpp_uart1";
+				marvell,function = "gpio";
+			};
+
+			pmx_nand: pmx-nand {
+				marvell,pins = "mpp_nand";
+				marvell,function = "nand";
+			};
+
+			pmx_nand_gpo: pmx-nand-gpo {
+				marvell,pins = "mpp_nand";
+				marvell,function = "gpo";
+			};
 		};
 
 		spi0: spi-ctrl at 10600 {
@@ -164,6 +341,8 @@
 			interrupts = <6>;
 			reg = <0x10600 0x28>;
 			clocks = <&core_clk 0>;
+			pinctrl-0 = <&pmx_spi0>;
+			pinctrl-names = "default";
 			status = "disabled";
 		};
 
@@ -211,6 +390,8 @@
 			reg = <0x92000 0x100>;
 			interrupts = <35>, <37>;
 			clocks = <&gate_clk 8>;
+			pinctrl-0 = <&pmx_sdio0>;
+			pinctrl-names = "default";
 			status = "disabled";
 		};
 
@@ -219,6 +400,8 @@
 			reg = <0x90000 0x100>;
 			interrupts = <36>, <38>;
 			clocks = <&gate_clk 9>;
+			pinctrl-0 = <&pmx_sdio1>;
+			pinctrl-names = "default";
 			status = "disabled";
 		};
 
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Mon Jul 29 08:29:03 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Jul 2013 14:29:03 +0200
Subject: [PATCH 1/4] ARM: dove: add cpu device tree node
In-Reply-To: <1375100946-28521-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1375100946-28521-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1375100946-28521-2-git-send-email-sebastian.hesselbarth@gmail.com>

This adds a node for the Marvell Sheeva PJ4A CPU found on Dove SoCs.
While at it, also move the l2-cache node out of internal registers and
consistently name different nodes.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove.dtsi |   52 ++++++++++++++++++++++++++-----------------
 1 file changed, 32 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 8d5be1e8..09d9710 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -10,6 +10,23 @@
 		gpio2 = &gpio2;
 	};
 
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu at 0 {
+			compatible = "marvell,pj4a", "marvell,sheeva-v7";
+			device_type = "cpu";
+			next-level-cache = <&l2>;
+			reg = <0>;
+		};
+	};
+
+	l2: l2-cache {
+		compatible = "marvell,tauros2-cache";
+		marvell,tauros2-cache-features = <0>;
+	};
+
 	soc at f1000000 {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -25,11 +42,6 @@
 		          0xf2100000 0xf2100000 0x0100000   /* PCIe0 I/O   1M */
 		          0xf8000000 0xf8000000 0x8000000>; /* BootROM   128M */
 
-		l2: l2-cache {
-			compatible = "marvell,tauros2-cache";
-			marvell,tauros2-cache-features = <0>;
-		};
-
 		timer: timer at 20300 {
 			compatible = "marvell,orion-timer";
 			reg = <0x20300 0x20>;
@@ -60,14 +72,14 @@
 			#clock-cells = <1>;
 		};
 
-		gate_clk: clock-gating-control at d0038 {
+		gate_clk: clock-gating-ctrl at d0038 {
 			compatible = "marvell,dove-gating-clock";
 			reg = <0xd0038 0x4>;
 			clocks = <&core_clk 0>;
 			#clock-cells = <1>;
 		};
 
-		thermal: thermal at d001c {
+		thermal: thermal-diode at d001c {
 			compatible = "marvell,dove-thermal";
 			reg = <0xd001c 0x0c>, <0xd005c 0x08>;
 		};
@@ -108,7 +120,7 @@
 			status = "disabled";
 		};
 
-		gpio0: gpio at d0400 {
+		gpio0: gpio-ctrl at d0400 {
 			compatible = "marvell,orion-gpio";
 			#gpio-cells = <2>;
 			gpio-controller;
@@ -119,7 +131,7 @@
 			interrupts = <12>, <13>, <14>, <60>;
 		};
 
-		gpio1: gpio at d0420 {
+		gpio1: gpio-ctrl at d0420 {
 			compatible = "marvell,orion-gpio";
 			#gpio-cells = <2>;
 			gpio-controller;
@@ -130,7 +142,7 @@
 			interrupts = <61>;
 		};
 
-		gpio2: gpio at e8400 {
+		gpio2: gpio-ctrl at e8400 {
 			compatible = "marvell,orion-gpio";
 			#gpio-cells = <2>;
 			gpio-controller;
@@ -138,13 +150,13 @@
 			ngpios = <8>;
 		};
 
-		pinctrl: pinctrl at d0200 {
+		pinctrl: pin-ctrl at d0200 {
 			compatible = "marvell,dove-pinctrl";
 			reg = <0xd0200 0x10>;
 			clocks = <&gate_clk 22>;
 		};
 
-		spi0: spi at 10600 {
+		spi0: spi-ctrl at 10600 {
 			compatible = "marvell,orion-spi";
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -155,7 +167,7 @@
 			status = "disabled";
 		};
 
-		spi1: spi at 14600 {
+		spi1: spi-ctrl at 14600 {
 			compatible = "marvell,orion-spi";
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -166,7 +178,7 @@
 			status = "disabled";
 		};
 
-		i2c0: i2c at 11000 {
+		i2c0: i2c-ctrl at 11000 {
 			compatible = "marvell,mv64xxx-i2c";
 			reg = <0x11000 0x20>;
 			#address-cells = <1>;
@@ -194,7 +206,7 @@
 			status = "okay";
 		};
 
-		sdio0: sdio at 92000 {
+		sdio0: sdio-host at 92000 {
 			compatible = "marvell,dove-sdhci";
 			reg = <0x92000 0x100>;
 			interrupts = <35>, <37>;
@@ -202,7 +214,7 @@
 			status = "disabled";
 		};
 
-		sdio1: sdio at 90000 {
+		sdio1: sdio-host at 90000 {
 			compatible = "marvell,dove-sdhci";
 			reg = <0x90000 0x100>;
 			interrupts = <36>, <38>;
@@ -210,7 +222,7 @@
 			status = "disabled";
 		};
 
-		sata0: sata at a0000 {
+		sata0: sata-host at a0000 {
 			compatible = "marvell,orion-sata";
 			reg = <0xa0000 0x2400>;
 			interrupts = <62>;
@@ -219,12 +231,12 @@
 			status = "disabled";
 		};
 
-		rtc at d8500 {
+		rtc: real-time-clock at d8500 {
 			compatible = "marvell,orion-rtc";
 			reg = <0xd8500 0x20>;
 		};
 
-		crypto: crypto at 30000 {
+		crypto: crypto-engine at 30000 {
 			compatible = "marvell,orion-crypto";
 			reg = <0x30000 0x10000>,
 			      <0xc8000000 0x800>;
@@ -291,7 +303,7 @@
 			};
 		};
 
-		eth: ethernet-controller at 72000 {
+		eth: ethernet-ctrl at 72000 {
 			compatible = "marvell,orion-eth";
 			#address-cells = <1>;
 			#size-cells = <0>;
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Mon Jul 29 08:29:06 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Jul 2013 14:29:06 +0200
Subject: [PATCH 4/4] ARM: dove: add initial DT file for Globalscale D2Plug
In-Reply-To: <1375100946-28521-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1375100946-28521-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1375100946-28521-5-git-send-email-sebastian.hesselbarth@gmail.com>

This adds an initial DT file for the Globalscale D2Plug with Dove SoC.
Currently, one LED is missing and I have not been able to get SD8787 driver
working. Those will be taken care of later.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/Makefile        |    1 +
 arch/arm/boot/dts/dove-d2plug.dts |   69 +++++++++++++++++++++++++++++++++++++
 2 files changed, 70 insertions(+)
 create mode 100644 arch/arm/boot/dts/dove-d2plug.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..6f10a07 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -47,6 +47,7 @@ dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
 	da850-evm.dtb
 dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
 	dove-cubox.dtb \
+	dove-d2plug.dtb \
 	dove-dove-db.dtb
 dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
 	exynos4210-smdkv310.dtb \
diff --git a/arch/arm/boot/dts/dove-d2plug.dts b/arch/arm/boot/dts/dove-d2plug.dts
new file mode 100644
index 0000000..e2222ce
--- /dev/null
+++ b/arch/arm/boot/dts/dove-d2plug.dts
@@ -0,0 +1,69 @@
+/dts-v1/;
+
+/include/ "dove.dtsi"
+
+/ {
+	model = "Globalscale D2Plug";
+	compatible = "globalscale,d2plug", "marvell,dove";
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x40000000>;
+	};
+
+	chosen {
+		bootargs = "console=ttyS0,115200n8 earlyprintk";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-0 = <&pmx_gpio_0 &pmx_gpio_1 &pmx_gpio_2>;
+		pinctrl-names = "default";
+
+		wlan-ap {
+			label = "wlan-ap";
+			gpios = <&gpio0 0 1>;
+		};
+
+		wlan-act {
+			label = "wlan-act";
+			gpios = <&gpio0 1 1>;
+		};
+
+		bluetooth-act {
+			label = "bt-act";
+			gpios = <&gpio0 2 1>;
+		};
+	};
+};
+
+&uart0 { status = "okay"; };
+&sata0 { status = "okay"; };
+&i2c0 { status = "okay"; };
+&mdio { status = "okay"; };
+&eth { status = "okay"; };
+
+/* Samsung M8G2F eMMC */
+&sdio0 {
+	status = "okay";
+	non-removable;
+	bus-width = <4>;
+};
+
+/* Marvell SD8787 WLAN/BT */
+&sdio1 {
+	status = "okay";
+	non-removable;
+	bus-width = <4>;
+};
+
+&spi0 {
+	status = "okay";
+
+	/* spi0.0: 4M Flash Macronix MX25L3205D */
+	spi-flash at 0 {
+		compatible = "st,m25l3205d";
+		spi-max-frequency = <20000000>;
+		reg = <0>;
+	};
+};
-- 
1.7.10.4



From trini at ti.com  Mon Jul 29 08:29:24 2013
From: trini at ti.com (Tom Rini)
Date: Mon, 29 Jul 2013 08:29:24 -0400
Subject: OMAP baseline test results for v3.10-rc6
In-Reply-To: <alpine.DEB.2.02.1307290826180.30864@utopia.booyaka.com>
References: <alpine.DEB.2.02.1306170521020.9909@utopia.booyaka.com>
 <20130625160243.GE22312@arwen.pp.htv.fi>
 <alpine.DEB.2.02.1306251746060.14373@utopia.booyaka.com>
 <51C9F0A8.1050607@ti.com>
 <alpine.DEB.2.02.1306261713260.6135@utopia.booyaka.com>
 <51CB4C20.3060306@ti.com>
 <alpine.DEB.2.02.1307290826180.30864@utopia.booyaka.com>
Message-ID: <51F66024.1030804@ti.com>

On 07/29/2013 04:29 AM, Paul Walmsley wrote:
> Hi
> 
> On Wed, 26 Jun 2013, Tom Rini wrote:
> 
>> On 06/26/2013 01:19 PM, Paul Walmsley wrote:
>>> On Tue, 25 Jun 2013, Tom Rini wrote:
>>>
>>>> On 06/25/2013 02:20 PM, Paul Walmsley wrote:
>>>>
>>>>> BeagleBone-white has the additional complication that it is not easy 
>>>>> to automate, due to the way that power is delivered to the board, so 
>>>>> there is an extra dimension of difficulty there.
>>>>
>>>> Ah-ha, I reproduced your failure.  If I make up a concat uImage + DTB,
>>>> rather than pass them separately, it fails to boot.  If you switch to
>>>> mainline U-Boot (v2012.10 or later) you get support for separate image +
>>>> dtb (v2013.04 gives you bootz and zImage support).
>>>
>>> Yeah, I've tried to keep the original bootloader that came on the first SD 
>>> card image that was used on that device.  But am starting to think that 
>>> it's time to stop my bootloader independence jihad, since appended DTB 
>>> booting is so broken - have seen similar problems on SoCs from other 
>>> vendors as well :-(
>>
>> Well, me?  I'm all in favor of people using latest release of U-Boot for
>> their board and yelling and screaming (or just reporting bugs) when
>> things don't work.  I'm biased of course.
> 
> That's exactly how bootloader developers should be testing their changes.  
> But most of the rest of us kernel folks don't want to deal with constantly 
> replacing bootloaders, and then dealing with the inevitable bootloader 
> regressions, when what we're really trying to test is the kernel...
> The kernel should be completely independent of the bootloader used.  

And thus the chicken and egg problems we have today.  The kernel should
be independent, but unless someone is also testing more recent U-Boots
as well, we may or may not have more hidden clock problems.  Or if there
is a bug in the bootloader for some particular use case, we don't find
out until a new device ships out with broken code for that case, and now
we're stuck for "forever".

I don't suspect what I'm going to say now will have a lot of traction,
but I really think that much like user space, every once in a while (6
months? year?) one ought to update their environment and make sure
things are still working too.

You folks don't need to test ever rev of U-Boot (that's my job), but it
often feels like there's this cycle of "U-Boot sucks and can't do ... !"
"We've had that fixed / improved / changed for years now, upgrade?" "No,
can't / won't!".  And...

>> And assuming rmk answers the way I expect he will, like it or not, the 
>> version(s) we kit up and get in the box need to be factored into our 
>> test system setup so if folks don't want to avail themselves of 
>> improvements, they still get a functional system too.
> 
> Yep seems like a good idea from a customer service point of view.  Also 
> most OMAP devices out there probably have locked bootloaders, so replacing 
> the bootloader is often not an option.

For shipping consumer product, or however you want to call those kind of
devices, yes, appended dtb needs to work since the bootloader is locked,
and making that boot something else to boot the kernel is an exercise
for us oddballs :)  But the boards which are designed as reference
platform, we can make your lives easier, if you let us help.  If
something is a pain to do, give us feedback.

-- 
Tom


From thierry.reding at gmail.com  Mon Jul 29 08:30:16 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 29 Jul 2013 14:30:16 +0200
Subject: [PATCH v2 0/4] Add PWM polarity flag macro for DT
In-Reply-To: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374101664-21112-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <20130729123015.GF23152@manwe>

On Thu, Jul 18, 2013 at 12:54:20AM +0200, Laurent Pinchart wrote:
> Hello,
> 
> Here's a small patch set that replaces PWM polarity numerical constants with
> macros in DT.
> 
> The series is the result of splitting the original patch into four patches
> that
> 
> - add the flag macro (both in a header file and in the PWM DT binding core
>   documentation)
> - use the macro in the PWM core code
> - update existing DT bindings to refer to the PWM DT bindings core
>   documentation
> - update existing DT sources to use the new macro
> 
> I believe I've taken all comments received so far into account. Most notable
> changes include
> 
> - splitting the original patch
> - removing the PWM_POLARITY_NORMAL flag, which wasn't a flag but was defined
>   as 0
> - renaming the PWM_POLARITY_INVERSED DT flag to PWM_POLARITY_INVERTED
> - not relying on DT flags and PWM C flags having identical names and values
> 
> Laurent Pinchart (4):
>   pwm: Add PWM polarity flag macro for DT
>   pwm: Use the DT macro directly when parsing PWM DT flags
>   pwm: Update DT bindings to reference pwm.txt for cells documentation
>   ARM: dts: Use the PWM polarity flags
> 
>  Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt    |  8 +++-----
>  Documentation/devicetree/bindings/pwm/imx-pwm.txt          |  4 ++--
>  Documentation/devicetree/bindings/pwm/mxs-pwm.txt          |  4 ++--
>  .../devicetree/bindings/pwm/nvidia,tegra20-pwm.txt         |  5 ++---
>  Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt  |  4 ++--
>  Documentation/devicetree/bindings/pwm/pwm-samsung.txt      | 10 +++-------
>  Documentation/devicetree/bindings/pwm/pwm-tiecap.txt       |  8 +++-----
>  Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt     |  8 +++-----
>  Documentation/devicetree/bindings/pwm/pwm.txt              |  7 ++++---
>  Documentation/devicetree/bindings/pwm/spear-pwm.txt        |  5 ++---
>  Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt       |  4 ++--
>  Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt    |  4 ++--
>  Documentation/devicetree/bindings/pwm/vt8500-pwm.txt       |  8 +++-----
>  arch/arm/boot/dts/am335x-evmsk.dts                         |  3 ++-
>  arch/arm/boot/dts/wm8850-w70v2.dts                         |  3 ++-
>  drivers/pwm/core.c                                         |  7 +++----
>  include/dt-bindings/pwm/pwm.h                              | 14 ++++++++++++++
>  17 files changed, 54 insertions(+), 52 deletions(-)
>  create mode 100644 include/dt-bindings/pwm/pwm.h

Applied, thanks.

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/20130729/f79bfd7b/attachment.sig>

From thierry.reding at gmail.com  Mon Jul 29 08:31:03 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 29 Jul 2013 14:31:03 +0200
Subject: [PATCHv5 08/11] ARM: pci: add ->add_bus() and ->remove_bus()
 hooks to hw_pci
In-Reply-To: <20130726224607.GZ24642@n2100.arm.linux.org.uk>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-9-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130725165659.GB27802@dhcp-172-17-186-34.nvidia.com>
 <20130726224607.GZ24642@n2100.arm.linux.org.uk>
Message-ID: <20130729123102.GG23152@manwe>

On Fri, Jul 26, 2013 at 11:46:07PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 25, 2013 at 09:57:00AM -0700, Thierry Reding wrote:
> > On Mon, Jul 15, 2013 at 01:52:44PM +0200, Thomas Petazzoni wrote:
> > > Some PCI drivers may need to adjust the pci_bus structure after it has
> > > been allocated by the Linux PCI core. The PCI core allows
> > > architectures to implement the pcibios_add_bus() and
> > > pcibios_remove_bus() for this purpose. This commit therefore extends
> > > the hw_pci and pci_sys_data structures of the ARM PCI core to allow
> > > PCI drivers to register ->add_bus() and ->remove_bus() in hw_pci,
> > > which will get called when a bus is added or removed from the system.
> > > 
> > > This will be used for example by the Marvell PCIe driver to connect a
> > > particular PCI bus with its corresponding MSI chip to handle Message
> > > Signaled Interrupts.
> > > 
> > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > > Reviewed-by: Thierry Reding <thierry.reding at gmail.com>
> > > ---
> > >  arch/arm/include/asm/mach/pci.h |  4 ++++
> > >  arch/arm/kernel/bios32.c        | 16 ++++++++++++++++
> > >  2 files changed, 20 insertions(+)
> > 
> > Hi Russell,
> > 
> > Can we have your Acked-by on this patch so that it can be moved to a
> > stable branch along with some of the other patches in this branch that
> > both Marvell and Tegra PCIe drivers need?
> 
> Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>

Thanks, Russell.

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/20130729/978fd981/attachment-0001.sig>

From sebastian.hesselbarth at gmail.com  Mon Jul 29 08:31:51 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Jul 2013 14:31:51 +0200
Subject: [PATCH 2/5] ARM: dove: add MBUS_ID macro to Dove DT
In-Reply-To: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1375101114-28858-3-git-send-email-sebastian.hesselbarth@gmail.com>

This adds a macro used for defining address window's target ID and
attribute cells for the MBus ranges entry.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove.dtsi |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 90257c7..397674c 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -1,5 +1,7 @@
 /include/ "skeleton.dtsi"
 
+#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
+
 / {
 	compatible = "marvell,dove";
 	model = "Marvell Armada 88AP510 SoC";
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Mon Jul 29 08:31:50 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Jul 2013 14:31:50 +0200
Subject: [PATCH 1/5] ARM: dove: use preprocessor on device tree files
In-Reply-To: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1375101114-28858-2-git-send-email-sebastian.hesselbarth@gmail.com>

This coverts Dove DT board files to preprocessor includes instead
of dtc includes.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove-cm-a510.dts |    2 +-
 arch/arm/boot/dts/dove-cubox.dts   |    2 +-
 arch/arm/boot/dts/dove-d2plug.dts  |    2 +-
 arch/arm/boot/dts/dove-dove-db.dts |    2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/dove-cm-a510.dts b/arch/arm/boot/dts/dove-cm-a510.dts
index 61a8062..50c0d69 100644
--- a/arch/arm/boot/dts/dove-cm-a510.dts
+++ b/arch/arm/boot/dts/dove-cm-a510.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "dove.dtsi"
+#include "dove.dtsi"
 
 / {
 	model = "Compulab CM-A510";
diff --git a/arch/arm/boot/dts/dove-cubox.dts b/arch/arm/boot/dts/dove-cubox.dts
index 022646e..4af59b6 100644
--- a/arch/arm/boot/dts/dove-cubox.dts
+++ b/arch/arm/boot/dts/dove-cubox.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "dove.dtsi"
+#include "dove.dtsi"
 
 / {
 	model = "SolidRun CuBox";
diff --git a/arch/arm/boot/dts/dove-d2plug.dts b/arch/arm/boot/dts/dove-d2plug.dts
index e2222ce..c11d363 100644
--- a/arch/arm/boot/dts/dove-d2plug.dts
+++ b/arch/arm/boot/dts/dove-d2plug.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "dove.dtsi"
+#include "dove.dtsi"
 
 / {
 	model = "Globalscale D2Plug";
diff --git a/arch/arm/boot/dts/dove-dove-db.dts b/arch/arm/boot/dts/dove-dove-db.dts
index e5a920b..bb725dc 100644
--- a/arch/arm/boot/dts/dove-dove-db.dts
+++ b/arch/arm/boot/dts/dove-dove-db.dts
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-/include/ "dove.dtsi"
+#include "dove.dtsi"
 
 / {
 	model = "Marvell DB-MV88AP510-BP Development Board";
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Mon Jul 29 08:31:49 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Jul 2013 14:31:49 +0200
Subject: [PATCH 0/5] ARM: dove: switch to DT MBus
Message-ID: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>

This patch set converts DT based Dove boards to DT probed MBus to be
introduced with v3.12.

The first two patches prepare Dove DT nodes for MBus ID remapping by using
preprocessor includes and adding the MBUS_ID macro. The third patch adds a
MBus DT node to Dove SoC dtsi with required ranges for internal MBus and
AXI registers, and PCIe mem and I/O apertures. The forth patch relocates
the nodes for the internal devices to the new MBus node. Also, internal-regs
ranges are updated to allow proper translation of MBus children's reg
properties. Finally, legacy MBus init is replaced by DT based MBus init
for DT based Dove.

The patch set depends on the MBus device tree patches that should appear
in v3.12. Currently, it is based on v3.11-rc2 with Dove DT cleanup patches
and MBus patch set v8 applied.

The patch set is _not_ sent to devicetree mainling list, because the MBus
binding will be discussed there on the MBus patches itself.

Sebastian Hesselbarth (5):
  ARM: dove: use preprocessor on device tree files
  ARM: dove: add MBUS_ID macro to Dove DT
  ARM: dove: add MBus DT node
  ARM: dove: relocate internal registers device nodes
  ARM: dove: switch to DT probed mbus address windows

 arch/arm/boot/dts/dove-cm-a510.dts |    2 +-
 arch/arm/boot/dts/dove-cubox.dts   |    2 +-
 arch/arm/boot/dts/dove-d2plug.dts  |    2 +-
 arch/arm/boot/dts/dove-dove-db.dts |    2 +-
 arch/arm/boot/dts/dove.dtsi        |  958 ++++++++++++++++++------------------
 arch/arm/mach-dove/board-dt.c      |   10 +-
 6 files changed, 491 insertions(+), 485 deletions(-)

---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Mon Jul 29 08:31:52 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Jul 2013 14:31:52 +0200
Subject: [PATCH 3/5] ARM: dove: add MBus DT node
In-Reply-To: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1375101114-28858-4-git-send-email-sebastian.hesselbarth@gmail.com>

This adds a MBus node including ranges and pcie apertures required later.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove.dtsi |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 397674c..bdda016 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -29,6 +29,20 @@
 		marvell,tauros2-cache-features = <0>;
 	};
 
+	mbus {
+		compatible = "marvell,dove-mbus", "marvell,mbus", "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		pcie-mem-aperture = <0xe0000000 0x10000000>; /* 256M MEM space */
+		pcie-io-aperture  = <0xf2000000 0x00200000>; /*   2M I/O space */
+
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x0100000   /* MBUS regs  1M */
+			  MBUS_ID(0xf0, 0x02) 0 0xf1800000 0x1000000   /* AXI  regs 16M */
+			  MBUS_ID(0x01, 0xfd) 0 0xf8000000 0x8000000   /* BootROM  128M */
+			  MBUS_ID(0x03, 0x01) 0 0xc8000000 0x0100000   /* CESA SRAM  1M */
+			  MBUS_ID(0x0d, 0x00) 0 0xf0000000 0x0100000>; /* PMU  SRAM  1M */
+	};
+
 	soc at f1000000 {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -44,6 +58,11 @@
 		          0xf2100000 0xf2100000 0x0100000   /* PCIe0 I/O   1M */
 		          0xf8000000 0xf8000000 0x8000000>; /* BootROM   128M */
 
+		mbusc: mbus-ctrl at 20000 {
+			compatible = "marvell,mbus-controller";
+			reg = <0x20000 0x80>, <0x800100 0x8>;
+		};
+
 		timer: timer at 20300 {
 			compatible = "marvell,orion-timer";
 			reg = <0x20300 0x20>;
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Mon Jul 29 08:31:54 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Jul 2013 14:31:54 +0200
Subject: [PATCH 5/5] ARM: dove: switch to DT probed mbus address windows
In-Reply-To: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1375101114-28858-6-git-send-email-sebastian.hesselbarth@gmail.com>

With proper mbus ranges and all internal nodes moved over, we can now
switch from static address window allocation to DT probed allocation.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/mach-dove/board-dt.c |   10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-dove/board-dt.c
index 49f72a8..1efbe1d 100644
--- a/arch/arm/mach-dove/board-dt.c
+++ b/arch/arm/mach-dove/board-dt.c
@@ -51,13 +51,6 @@ static void __init dove_dt_time_init(void)
 	clocksource_of_init();
 }
 
-static void __init dove_dt_init_early(void)
-{
-	mvebu_mbus_init("marvell,dove-mbus",
-			BRIDGE_WINS_BASE, BRIDGE_WINS_SZ,
-			DOVE_MC_WINS_BASE, DOVE_MC_WINS_SZ);
-}
-
 static void __init dove_dt_init(void)
 {
 	pr_info("Dove 88AP510 SoC\n");
@@ -65,7 +58,7 @@ static void __init dove_dt_init(void)
 #ifdef CONFIG_CACHE_TAUROS2
 	tauros2_init(0);
 #endif
-	dove_setup_cpu_wins();
+	BUG_ON(mvebu_mbus_dt_init());
 
 	/* Setup clocks for legacy devices */
 	dove_legacy_clk_init();
@@ -83,7 +76,6 @@ static const char * const dove_dt_board_compat[] = {
 
 DT_MACHINE_START(DOVE_DT, "Marvell Dove (Flattened Device Tree)")
 	.map_io		= dove_map_io,
-	.init_early	= dove_dt_init_early,
 	.init_time	= dove_dt_time_init,
 	.init_machine	= dove_dt_init,
 	.restart	= dove_restart,
-- 
1.7.10.4



From sebastian.hesselbarth at gmail.com  Mon Jul 29 08:31:53 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Jul 2013 14:31:53 +0200
Subject: [PATCH 4/5] ARM: dove: relocate internal registers device nodes
In-Reply-To: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1375101114-28858-5-git-send-email-sebastian.hesselbarth@gmail.com>

With mbus node in place, now relocate all internal device nodes
to internal-regs node with proper address ranges.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
---
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/boot/dts/dove.dtsi |  955 +++++++++++++++++++++----------------------
 1 file changed, 474 insertions(+), 481 deletions(-)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index bdda016..867b945 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -5,6 +5,7 @@
 / {
 	compatible = "marvell,dove";
 	model = "Marvell Armada 88AP510 SoC";
+	interrupt-parent = <&intc>;
 
 	aliases {
 		gpio0 = &gpio0;
@@ -41,489 +42,481 @@
 			  MBUS_ID(0x01, 0xfd) 0 0xf8000000 0x8000000   /* BootROM  128M */
 			  MBUS_ID(0x03, 0x01) 0 0xc8000000 0x0100000   /* CESA SRAM  1M */
 			  MBUS_ID(0x0d, 0x00) 0 0xf0000000 0x0100000>; /* PMU  SRAM  1M */
-	};
-
-	soc at f1000000 {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <1>;
-		interrupt-parent = <&intc>;
-
-		ranges = <0xc8000000 0xc8000000 0x0100000   /* CESA SRAM   1M */
-		          0xe0000000 0xe0000000 0x8000000   /* PCIe0 Mem 128M */
-		          0xe8000000 0xe8000000 0x8000000   /* PCIe1 Mem 128M */
-		          0xf0000000 0xf0000000 0x0100000   /* ScratchPad  1M */
-		          0x00000000 0xf1000000 0x1000000   /* SB/NB regs 16M */
-		          0xf2000000 0xf2000000 0x0100000   /* PCIe0 I/O   1M */
-		          0xf2100000 0xf2100000 0x0100000   /* PCIe0 I/O   1M */
-		          0xf8000000 0xf8000000 0x8000000>; /* BootROM   128M */
-
-		mbusc: mbus-ctrl at 20000 {
-			compatible = "marvell,mbus-controller";
-			reg = <0x20000 0x80>, <0x800100 0x8>;
-		};
-
-		timer: timer at 20300 {
-			compatible = "marvell,orion-timer";
-			reg = <0x20300 0x20>;
-			interrupt-parent = <&bridge_intc>;
-			interrupts = <1>, <2>;
-			clocks = <&core_clk 0>;
-		};
-
-		intc: main-interrupt-ctrl at 20200 {
-			compatible = "marvell,orion-intc";
-			interrupt-controller;
-			#interrupt-cells = <1>;
-			reg = <0x20200 0x10>, <0x20210 0x10>;
-		};
-
-		bridge_intc: bridge-interrupt-ctrl at 20110 {
-			compatible = "marvell,orion-bridge-intc";
-			interrupt-controller;
-			#interrupt-cells = <1>;
-			reg = <0x20110 0x8>;
-			interrupts = <0>;
-			marvell,#interrupts = <5>;
-		};
-
-		core_clk: core-clocks at d0214 {
-			compatible = "marvell,dove-core-clock";
-			reg = <0xd0214 0x4>;
-			#clock-cells = <1>;
-		};
-
-		gate_clk: clock-gating-ctrl at d0038 {
-			compatible = "marvell,dove-gating-clock";
-			reg = <0xd0038 0x4>;
-			clocks = <&core_clk 0>;
-			#clock-cells = <1>;
-		};
-
-		thermal: thermal-diode at d001c {
-			compatible = "marvell,dove-thermal";
-			reg = <0xd001c 0x0c>, <0xd005c 0x08>;
-		};
-
-		uart0: serial at 12000 {
-			compatible = "ns16550a";
-			reg = <0x12000 0x100>;
-			reg-shift = <2>;
-			interrupts = <7>;
-			clocks = <&core_clk 0>;
-			status = "disabled";
-		};
-
-		uart1: serial at 12100 {
-			compatible = "ns16550a";
-			reg = <0x12100 0x100>;
-			reg-shift = <2>;
-			interrupts = <8>;
-			clocks = <&core_clk 0>;
-			pinctrl-0 = <&pmx_uart1>;
-			pinctrl-names = "default";
-			status = "disabled";
-		};
-
-		uart2: serial at 12200 {
-			compatible = "ns16550a";
-			reg = <0x12000 0x100>;
-			reg-shift = <2>;
-			interrupts = <9>;
-			clocks = <&core_clk 0>;
-			status = "disabled";
-		};
-
-		uart3: serial at 12300 {
-			compatible = "ns16550a";
-			reg = <0x12100 0x100>;
-			reg-shift = <2>;
-			interrupts = <10>;
-			clocks = <&core_clk 0>;
-			status = "disabled";
-		};
-
-		gpio0: gpio-ctrl at d0400 {
-			compatible = "marvell,orion-gpio";
-			#gpio-cells = <2>;
-			gpio-controller;
-			reg = <0xd0400 0x20>;
-			ngpios = <32>;
-			interrupt-controller;
-			#interrupt-cells = <2>;
-			interrupts = <12>, <13>, <14>, <60>;
-		};
-
-		gpio1: gpio-ctrl at d0420 {
-			compatible = "marvell,orion-gpio";
-			#gpio-cells = <2>;
-			gpio-controller;
-			reg = <0xd0420 0x20>;
-			ngpios = <32>;
-			interrupt-controller;
-			#interrupt-cells = <2>;
-			interrupts = <61>;
-		};
-
-		gpio2: gpio-ctrl at e8400 {
-			compatible = "marvell,orion-gpio";
-			#gpio-cells = <2>;
-			gpio-controller;
-			reg = <0xe8400 0x0c>;
-			ngpios = <8>;
-		};
-
-		pinctrl: pin-ctrl at d0200 {
-			compatible = "marvell,dove-pinctrl";
-			reg = <0xd0200 0x10>;
-			clocks = <&gate_clk 22>;
-
-			pmx_gpio_0: pmx-gpio-0 {
-				marvell,pins = "mpp0";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_1: pmx-gpio-1 {
-				marvell,pins = "mpp1";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_2: pmx-gpio-2 {
-				marvell,pins = "mpp2";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_3: pmx-gpio-3 {
-				marvell,pins = "mpp3";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_4: pmx-gpio-4 {
-				marvell,pins = "mpp4";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_5: pmx-gpio-5 {
-				marvell,pins = "mpp5";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_6: pmx-gpio-6 {
-				marvell,pins = "mpp6";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_7: pmx-gpio-7 {
-				marvell,pins = "mpp7";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_8: pmx-gpio-8 {
-				marvell,pins = "mpp8";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_9: pmx-gpio-9 {
-				marvell,pins = "mpp9";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_10: pmx-gpio-10 {
-				marvell,pins = "mpp10";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_11: pmx-gpio-11 {
-				marvell,pins = "mpp11";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_12: pmx-gpio-12 {
-				marvell,pins = "mpp12";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_13: pmx-gpio-13 {
-				marvell,pins = "mpp13";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_14: pmx-gpio-14 {
-				marvell,pins = "mpp14";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_15: pmx-gpio-15 {
-				marvell,pins = "mpp15";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_16: pmx-gpio-16 {
-				marvell,pins = "mpp16";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_17: pmx-gpio-17 {
-				marvell,pins = "mpp17";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_18: pmx-gpio-18 {
-				marvell,pins = "mpp18";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_19: pmx-gpio-19 {
-				marvell,pins = "mpp19";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_20: pmx-gpio-20 {
-				marvell,pins = "mpp20";
-				marvell,function = "gpio";
-			};
-
-			pmx_gpio_21: pmx-gpio-21 {
-				marvell,pins = "mpp21";
-				marvell,function = "gpio";
-			};
-
-			pmx_camera: pmx-camera {
-				marvell,pins = "mpp_camera";
-				marvell,function = "camera";
-			};
-
-			pmx_camera_gpio: pmx-camera-gpio {
-				marvell,pins = "mpp_camera";
-				marvell,function = "gpio";
-			};
-
-			pmx_sdio0: pmx-sdio0 {
-				marvell,pins = "mpp_sdio0";
-				marvell,function = "sdio0";
-			};
-
-			pmx_sdio0_gpio: pmx-sdio0-gpio {
-				marvell,pins = "mpp_sdio0";
-				marvell,function = "gpio";
-			};
-
-			pmx_sdio1: pmx-sdio1 {
-				marvell,pins = "mpp_sdio1";
-				marvell,function = "sdio1";
-			};
-
-			pmx_sdio1_gpio: pmx-sdio1-gpio {
-				marvell,pins = "mpp_sdio1";
-				marvell,function = "gpio";
-			};
-
-			pmx_audio1_gpio: pmx-audio1-gpio {
-				marvell,pins = "mpp_audio1";
-				marvell,function = "gpio";
-			};
-
-			pmx_spi0: pmx-spi0 {
-				marvell,pins = "mpp_spi0";
-				marvell,function = "spi0";
-			};
-
-			pmx_spi0_gpio: pmx-spi0-gpio {
-				marvell,pins = "mpp_spi0";
-				marvell,function = "gpio";
-			};
-
-			pmx_uart1: pmx-uart1 {
-				marvell,pins = "mpp_uart1";
-				marvell,function = "uart1";
-			};
-
-			pmx_uart1_gpio: pmx-uart1-gpio {
-				marvell,pins = "mpp_uart1";
-				marvell,function = "gpio";
-			};
-
-			pmx_nand: pmx-nand {
-				marvell,pins = "mpp_nand";
-				marvell,function = "nand";
-			};
-
-			pmx_nand_gpo: pmx-nand-gpo {
-				marvell,pins = "mpp_nand";
-				marvell,function = "gpo";
-			};
-		};
-
-		spi0: spi-ctrl at 10600 {
-			compatible = "marvell,orion-spi";
-			#address-cells = <1>;
-			#size-cells = <0>;
-			cell-index = <0>;
-			interrupts = <6>;
-			reg = <0x10600 0x28>;
-			clocks = <&core_clk 0>;
-			pinctrl-0 = <&pmx_spi0>;
-			pinctrl-names = "default";
-			status = "disabled";
-		};
-
-		spi1: spi-ctrl at 14600 {
-			compatible = "marvell,orion-spi";
-			#address-cells = <1>;
-			#size-cells = <0>;
-			cell-index = <1>;
-			interrupts = <5>;
-			reg = <0x14600 0x28>;
-			clocks = <&core_clk 0>;
-			status = "disabled";
-		};
-
-		i2c0: i2c-ctrl at 11000 {
-			compatible = "marvell,mv64xxx-i2c";
-			reg = <0x11000 0x20>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-			interrupts = <11>;
-			clock-frequency = <400000>;
-			timeout-ms = <1000>;
-			clocks = <&core_clk 0>;
-			status = "disabled";
-		};
-
-		ehci0: usb-host at 50000 {
-			compatible = "marvell,orion-ehci";
-			reg = <0x50000 0x1000>;
-			interrupts = <24>;
-			clocks = <&gate_clk 0>;
-			status = "okay";
-		};
-
-		ehci1: usb-host at 51000 {
-			compatible = "marvell,orion-ehci";
-			reg = <0x51000 0x1000>;
-			interrupts = <25>;
-			clocks = <&gate_clk 1>;
-			status = "okay";
-		};
-
-		sdio0: sdio-host at 92000 {
-			compatible = "marvell,dove-sdhci";
-			reg = <0x92000 0x100>;
-			interrupts = <35>, <37>;
-			clocks = <&gate_clk 8>;
-			pinctrl-0 = <&pmx_sdio0>;
-			pinctrl-names = "default";
-			status = "disabled";
-		};
-
-		sdio1: sdio-host at 90000 {
-			compatible = "marvell,dove-sdhci";
-			reg = <0x90000 0x100>;
-			interrupts = <36>, <38>;
-			clocks = <&gate_clk 9>;
-			pinctrl-0 = <&pmx_sdio1>;
-			pinctrl-names = "default";
-			status = "disabled";
-		};
-
-		sata0: sata-host at a0000 {
-			compatible = "marvell,orion-sata";
-			reg = <0xa0000 0x2400>;
-			interrupts = <62>;
-			clocks = <&gate_clk 3>;
-			nr-ports = <1>;
-			status = "disabled";
-		};
-
-		rtc: real-time-clock at d8500 {
-			compatible = "marvell,orion-rtc";
-			reg = <0xd8500 0x20>;
-		};
-
-		crypto: crypto-engine at 30000 {
-			compatible = "marvell,orion-crypto";
-			reg = <0x30000 0x10000>,
-			      <0xc8000000 0x800>;
-			reg-names = "regs", "sram";
-			interrupts = <31>;
-			clocks = <&gate_clk 15>;
-			status = "okay";
-		};
-
-		xor0: dma-engine at 60800 {
-			compatible = "marvell,orion-xor";
-			reg = <0x60800 0x100
-			       0x60a00 0x100>;
-			clocks = <&gate_clk 23>;
-			status = "okay";
-
-			channel0 {
-				interrupts = <39>;
-				dmacap,memcpy;
-				dmacap,xor;
-			};
-
-			channel1 {
-				interrupts = <40>;
-				dmacap,memset;
-				dmacap,memcpy;
-				dmacap,xor;
-			};
-		};
-
-		xor1: dma-engine at 60900 {
-			compatible = "marvell,orion-xor";
-			reg = <0x60900 0x100
-			       0x60b00 0x100>;
-			clocks = <&gate_clk 24>;
-			status = "okay";
-
-			channel0 {
-				interrupts = <42>;
-				dmacap,memcpy;
-				dmacap,xor;
-			};
-
-			channel1 {
-				interrupts = <43>;
-				dmacap,memset;
-				dmacap,memcpy;
-				dmacap,xor;
-			};
-		};
-
-		mdio: mdio-bus at 72004 {
-			compatible = "marvell,orion-mdio";
-			#address-cells = <1>;
-			#size-cells = <0>;
-			reg = <0x72004 0x84>;
-			interrupts = <30>;
-			clocks = <&gate_clk 2>;
-			status = "disabled";
-
-			ethphy: ethernet-phy {
-				device-type = "ethernet-phy";
-				/* set phy address in board file */
-			};
-		};
 
-		eth: ethernet-ctrl at 72000 {
-			compatible = "marvell,orion-eth";
+		internal-regs {
+			compatible = "simple-bus";
 			#address-cells = <1>;
-			#size-cells = <0>;
-			reg = <0x72000 0x4000>;
-			clocks = <&gate_clk 2>;
-			marvell,tx-checksum-limit = <1600>;
-			status = "disabled";
-
-			ethernet-port at 0 {
-				device_type = "network";
-				compatible = "marvell,orion-eth-port";
-				reg = <0>;
-				interrupts = <29>;
-				/* overwrite MAC address in bootloader */
-				local-mac-address = [00 00 00 00 00 00];
-				phy-handle = <&ethphy>;
+			#size-cells = <1>;
+			ranges = <0x00000000 MBUS_ID(0xf0, 0x01) 0 0x0100000   /* MBUS regs  1M */
+				  0x00800000 MBUS_ID(0xf0, 0x02) 0 0x1000000   /* AXI  regs 16M */
+				  0xffffe000 MBUS_ID(0x03, 0x01) 0 0x0000800   /* CESA SRAM  2k */
+				  0xfffff000 MBUS_ID(0x0d, 0x00) 0 0x0000800>; /* PMU  SRAM  2k */
+
+			mbusc: mbus-ctrl at 20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x80>, <0x800100 0x8>;
+			};
+
+			timer: timer at 20300 {
+				compatible = "marvell,orion-timer";
+				reg = <0x20300 0x20>;
+				interrupt-parent = <&bridge_intc>;
+				interrupts = <1>, <2>;
+				clocks = <&core_clk 0>;
+			};
+
+			intc: main-interrupt-ctrl at 20200 {
+				compatible = "marvell,orion-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+				reg = <0x20200 0x10>, <0x20210 0x10>;
+			};
+
+			bridge_intc: bridge-interrupt-ctrl at 20110 {
+				compatible = "marvell,orion-bridge-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+				reg = <0x20110 0x8>;
+				interrupts = <0>;
+				marvell,#interrupts = <5>;
+			};
+
+			core_clk: core-clocks at d0214 {
+				compatible = "marvell,dove-core-clock";
+				reg = <0xd0214 0x4>;
+				#clock-cells = <1>;
+			};
+
+			gate_clk: clock-gating-ctrl at d0038 {
+				compatible = "marvell,dove-gating-clock";
+				reg = <0xd0038 0x4>;
+				clocks = <&core_clk 0>;
+				#clock-cells = <1>;
+			};
+
+			thermal: thermal-diode at d001c {
+				compatible = "marvell,dove-thermal";
+				reg = <0xd001c 0x0c>, <0xd005c 0x08>;
+			};
+
+			uart0: serial at 12000 {
+				compatible = "ns16550a";
+				reg = <0x12000 0x100>;
+				reg-shift = <2>;
+				interrupts = <7>;
+				clocks = <&core_clk 0>;
+				status = "disabled";
+			};
+
+			uart1: serial at 12100 {
+				compatible = "ns16550a";
+				reg = <0x12100 0x100>;
+				reg-shift = <2>;
+				interrupts = <8>;
+				clocks = <&core_clk 0>;
+				pinctrl-0 = <&pmx_uart1>;
+				pinctrl-names = "default";
+				status = "disabled";
+			};
+
+			uart2: serial at 12200 {
+				compatible = "ns16550a";
+				reg = <0x12000 0x100>;
+				reg-shift = <2>;
+				interrupts = <9>;
+				clocks = <&core_clk 0>;
+				status = "disabled";
+			};
+
+			uart3: serial at 12300 {
+				compatible = "ns16550a";
+				reg = <0x12100 0x100>;
+				reg-shift = <2>;
+				interrupts = <10>;
+				clocks = <&core_clk 0>;
+				status = "disabled";
+			};
+
+			gpio0: gpio-ctrl at d0400 {
+				compatible = "marvell,orion-gpio";
+				#gpio-cells = <2>;
+				gpio-controller;
+				reg = <0xd0400 0x20>;
+				ngpios = <32>;
+				interrupt-controller;
+				#interrupt-cells = <2>;
+				interrupts = <12>, <13>, <14>, <60>;
+			};
+
+			gpio1: gpio-ctrl at d0420 {
+				compatible = "marvell,orion-gpio";
+				#gpio-cells = <2>;
+				gpio-controller;
+				reg = <0xd0420 0x20>;
+				ngpios = <32>;
+				interrupt-controller;
+				#interrupt-cells = <2>;
+				interrupts = <61>;
+			};
+
+			gpio2: gpio-ctrl at e8400 {
+				compatible = "marvell,orion-gpio";
+				#gpio-cells = <2>;
+				gpio-controller;
+				reg = <0xe8400 0x0c>;
+				ngpios = <8>;
+			};
+
+			pinctrl: pin-ctrl at d0200 {
+				compatible = "marvell,dove-pinctrl";
+				reg = <0xd0200 0x10>;
+				clocks = <&gate_clk 22>;
+
+				pmx_gpio_0: pmx-gpio-0 {
+					marvell,pins = "mpp0";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_1: pmx-gpio-1 {
+					marvell,pins = "mpp1";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_2: pmx-gpio-2 {
+					marvell,pins = "mpp2";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_3: pmx-gpio-3 {
+					marvell,pins = "mpp3";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_4: pmx-gpio-4 {
+					marvell,pins = "mpp4";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_5: pmx-gpio-5 {
+					marvell,pins = "mpp5";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_6: pmx-gpio-6 {
+					marvell,pins = "mpp6";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_7: pmx-gpio-7 {
+					marvell,pins = "mpp7";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_8: pmx-gpio-8 {
+					marvell,pins = "mpp8";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_9: pmx-gpio-9 {
+					marvell,pins = "mpp9";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_10: pmx-gpio-10 {
+					marvell,pins = "mpp10";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_11: pmx-gpio-11 {
+					marvell,pins = "mpp11";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_12: pmx-gpio-12 {
+					marvell,pins = "mpp12";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_13: pmx-gpio-13 {
+					marvell,pins = "mpp13";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_14: pmx-gpio-14 {
+					marvell,pins = "mpp14";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_15: pmx-gpio-15 {
+					marvell,pins = "mpp15";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_16: pmx-gpio-16 {
+					marvell,pins = "mpp16";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_17: pmx-gpio-17 {
+					marvell,pins = "mpp17";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_18: pmx-gpio-18 {
+					marvell,pins = "mpp18";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_19: pmx-gpio-19 {
+					marvell,pins = "mpp19";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_20: pmx-gpio-20 {
+					marvell,pins = "mpp20";
+					marvell,function = "gpio";
+				};
+
+				pmx_gpio_21: pmx-gpio-21 {
+					marvell,pins = "mpp21";
+					marvell,function = "gpio";
+				};
+
+				pmx_camera: pmx-camera {
+					marvell,pins = "mpp_camera";
+					marvell,function = "camera";
+				};
+
+				pmx_camera_gpio: pmx-camera-gpio {
+					marvell,pins = "mpp_camera";
+					marvell,function = "gpio";
+				};
+
+				pmx_sdio0: pmx-sdio0 {
+					marvell,pins = "mpp_sdio0";
+					marvell,function = "sdio0";
+				};
+
+				pmx_sdio0_gpio: pmx-sdio0-gpio {
+					marvell,pins = "mpp_sdio0";
+					marvell,function = "gpio";
+				};
+
+				pmx_sdio1: pmx-sdio1 {
+					marvell,pins = "mpp_sdio1";
+					marvell,function = "sdio1";
+				};
+
+				pmx_sdio1_gpio: pmx-sdio1-gpio {
+					marvell,pins = "mpp_sdio1";
+					marvell,function = "gpio";
+				};
+
+				pmx_audio1_gpio: pmx-audio1-gpio {
+					marvell,pins = "mpp_audio1";
+					marvell,function = "gpio";
+				};
+
+				pmx_spi0: pmx-spi0 {
+					marvell,pins = "mpp_spi0";
+					marvell,function = "spi0";
+				};
+
+				pmx_spi0_gpio: pmx-spi0-gpio {
+					marvell,pins = "mpp_spi0";
+					marvell,function = "gpio";
+				};
+
+				pmx_uart1: pmx-uart1 {
+					marvell,pins = "mpp_uart1";
+					marvell,function = "uart1";
+				};
+
+				pmx_uart1_gpio: pmx-uart1-gpio {
+					marvell,pins = "mpp_uart1";
+					marvell,function = "gpio";
+				};
+
+				pmx_nand: pmx-nand {
+					marvell,pins = "mpp_nand";
+					marvell,function = "nand";
+				};
+
+				pmx_nand_gpo: pmx-nand-gpo {
+					marvell,pins = "mpp_nand";
+					marvell,function = "gpo";
+				};
+			};
+
+			spi0: spi-ctrl at 10600 {
+				compatible = "marvell,orion-spi";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				cell-index = <0>;
+				interrupts = <6>;
+				reg = <0x10600 0x28>;
+				clocks = <&core_clk 0>;
+				pinctrl-0 = <&pmx_spi0>;
+				pinctrl-names = "default";
+				status = "disabled";
+			};
+
+			spi1: spi-ctrl at 14600 {
+				compatible = "marvell,orion-spi";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				cell-index = <1>;
+				interrupts = <5>;
+				reg = <0x14600 0x28>;
+				clocks = <&core_clk 0>;
+				status = "disabled";
+			};
+
+			i2c0: i2c-ctrl at 11000 {
+				compatible = "marvell,mv64xxx-i2c";
+				reg = <0x11000 0x20>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				interrupts = <11>;
+				clock-frequency = <400000>;
+				timeout-ms = <1000>;
+				clocks = <&core_clk 0>;
+				status = "disabled";
+			};
+
+			ehci0: usb-host at 50000 {
+				compatible = "marvell,orion-ehci";
+				reg = <0x50000 0x1000>;
+				interrupts = <24>;
+				clocks = <&gate_clk 0>;
+				status = "okay";
+			};
+
+			ehci1: usb-host at 51000 {
+				compatible = "marvell,orion-ehci";
+				reg = <0x51000 0x1000>;
+				interrupts = <25>;
+				clocks = <&gate_clk 1>;
+				status = "okay";
+			};
+
+			sdio0: sdio-host at 92000 {
+				compatible = "marvell,dove-sdhci";
+				reg = <0x92000 0x100>;
+				interrupts = <35>, <37>;
+				clocks = <&gate_clk 8>;
+				pinctrl-0 = <&pmx_sdio0>;
+				pinctrl-names = "default";
+				status = "disabled";
+			};
+
+			sdio1: sdio-host at 90000 {
+				compatible = "marvell,dove-sdhci";
+				reg = <0x90000 0x100>;
+				interrupts = <36>, <38>;
+				clocks = <&gate_clk 9>;
+				pinctrl-0 = <&pmx_sdio1>;
+				pinctrl-names = "default";
+				status = "disabled";
+			};
+
+			sata0: sata-host at a0000 {
+				compatible = "marvell,orion-sata";
+				reg = <0xa0000 0x2400>;
+				interrupts = <62>;
+				clocks = <&gate_clk 3>;
+				nr-ports = <1>;
+				status = "disabled";
+			};
+
+			rtc: real-time-clock at d8500 {
+				compatible = "marvell,orion-rtc";
+				reg = <0xd8500 0x20>;
+			};
+
+			crypto: crypto-engine at 30000 {
+				compatible = "marvell,orion-crypto";
+				reg = <0x30000 0x10000>,
+				      <0xffffe000 0x800>;
+				reg-names = "regs", "sram";
+				interrupts = <31>;
+				clocks = <&gate_clk 15>;
+				status = "okay";
+			};
+
+			xor0: dma-engine at 60800 {
+				compatible = "marvell,orion-xor";
+				reg = <0x60800 0x100
+				       0x60a00 0x100>;
+				clocks = <&gate_clk 23>;
+				status = "okay";
+
+				channel0 {
+					interrupts = <39>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+
+				channel1 {
+					interrupts = <40>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+			};
+
+			xor1: dma-engine at 60900 {
+				compatible = "marvell,orion-xor";
+				reg = <0x60900 0x100
+				       0x60b00 0x100>;
+				clocks = <&gate_clk 24>;
+				status = "okay";
+
+				channel0 {
+					interrupts = <42>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+
+				channel1 {
+					interrupts = <43>;
+					dmacap,memcpy;
+					dmacap,xor;
+				};
+			};
+
+			mdio: mdio-bus at 72004 {
+				compatible = "marvell,orion-mdio";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <0x72004 0x84>;
+				interrupts = <30>;
+				clocks = <&gate_clk 2>;
+				status = "disabled";
+
+				ethphy: ethernet-phy {
+					device-type = "ethernet-phy";
+					/* set phy address in board file */
+				};
+			};
+
+			eth: ethernet-ctrl at 72000 {
+				compatible = "marvell,orion-eth";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <0x72000 0x4000>;
+				clocks = <&gate_clk 2>;
+				marvell,tx-checksum-limit = <1600>;
+				status = "disabled";
+
+				ethernet-port at 0 {
+					device_type = "network";
+					compatible = "marvell,orion-eth-port";
+					reg = <0>;
+					interrupts = <29>;
+					/* overwrite MAC address in bootloader */
+					local-mac-address = [00 00 00 00 00 00];
+					phy-handle = <&ethphy>;
+				};
 			};
 		};
 	};
-- 
1.7.10.4



From jonas.jensen at gmail.com  Mon Jul 29 08:33:48 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Mon, 29 Jul 2013 14:33:48 +0200
Subject: [PATCH v7] watchdog: Add MOXA ART watchdog driver
In-Reply-To: <1375098093-8975-1-git-send-email-jonas.jensen@gmail.com>
References: <1375098093-8975-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1375101228-10930-1-git-send-email-jonas.jensen@gmail.com>

Add watchdog driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v6:
    
    1. use local struct device *dev pointer, replace "&pdev->dev" with "dev"
    
    Applies to next-20130729

 .../bindings/watchdog/moxa,moxart-watchdog.txt     |  15 ++
 drivers/watchdog/Kconfig                           |  10 ++
 drivers/watchdog/Makefile                          |   1 +
 drivers/watchdog/moxart_wdt.c                      | 165 +++++++++++++++++++++
 4 files changed, 191 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
 create mode 100644 drivers/watchdog/moxart_wdt.c

diff --git a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
new file mode 100644
index 0000000..1169857
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
@@ -0,0 +1,15 @@
+MOXA ART Watchdog timer
+
+Required properties:
+
+- compatible : Must be "moxa,moxart-watchdog"
+- reg : Should contain registers location and length
+- clocks : Should contain phandle for the clock that drives the counter
+
+Example:
+
+	watchdog: watchdog at 98500000 {
+		compatible = "moxa,moxart-watchdog";
+		reg = <0x98500000 0x10>;
+		clocks = <&coreclk>;
+	};
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 362085d..6883aab 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -382,6 +382,16 @@ config RETU_WATCHDOG
 	  To compile this driver as a module, choose M here: the
 	  module will be called retu_wdt.
 
+config MOXART_WDT
+	tristate "MOXART watchdog"
+	depends on ARCH_MOXART
+	help
+	  Say Y here to include Watchdog timer support for the watchdog
+	  existing on the MOXA ART SoC series platforms.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called moxart_wdt.
+
 # AVR32 Architecture
 
 config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 2f26a0b..7cab53a 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
 obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
 obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
 obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
+obj-$(CONFIG_MOXART_WDT) += moxart_wdt.o
 
 # AVR32 Architecture
 obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
new file mode 100644
index 0000000..48dc334
--- /dev/null
+++ b/drivers/watchdog/moxart_wdt.c
@@ -0,0 +1,165 @@
+/*
+ * MOXA ART SoCs watchdog driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/watchdog.h>
+#include <linux/moduleparam.h>
+
+#define REG_COUNT			0x4
+#define REG_MODE			0x8
+#define REG_ENABLE			0xC
+
+struct moxart_wdt_dev {
+	struct watchdog_device dev;
+	void __iomem *base;
+	unsigned int clock_frequency;
+};
+
+static int heartbeat;
+
+static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+
+	writel(0, moxart_wdt->base + REG_ENABLE);
+
+	return 0;
+}
+
+static int moxart_wdt_start(struct watchdog_device *wdt_dev)
+{
+	struct moxart_wdt_dev *moxart_wdt = watchdog_get_drvdata(wdt_dev);
+
+	writel(moxart_wdt->clock_frequency * wdt_dev->timeout,
+	       moxart_wdt->base + REG_COUNT);
+	writel(0x5ab9, moxart_wdt->base + REG_MODE);
+	writel(0x03, moxart_wdt->base + REG_ENABLE);
+
+	return 0;
+}
+
+static int moxart_wdt_set_timeout(struct watchdog_device *wdt_dev,
+				  unsigned int timeout)
+{
+	wdt_dev->timeout = timeout;
+
+	return 0;
+}
+
+static const struct watchdog_info moxart_wdt_info = {
+	.identity       = "moxart-wdt",
+	.options        = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
+static const struct watchdog_ops moxart_wdt_ops = {
+	.owner          = THIS_MODULE,
+	.start          = moxart_wdt_start,
+	.stop           = moxart_wdt_stop,
+	.set_timeout    = moxart_wdt_set_timeout,
+};
+
+static int moxart_wdt_probe(struct platform_device *pdev)
+{
+	struct moxart_wdt_dev *moxart_wdt;
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct resource *res;
+	struct clk *clk;
+	int err;
+	unsigned int max_timeout;
+	bool nowayout = WATCHDOG_NOWAYOUT;
+
+	moxart_wdt = devm_kzalloc(dev, sizeof(*moxart_wdt), GFP_KERNEL);
+	if (!moxart_wdt)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, moxart_wdt);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	moxart_wdt->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_wdt->base))
+		return PTR_ERR(moxart_wdt->base);
+
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk)) {
+		pr_err("%s: of_clk_get failed\n", __func__);
+		return PTR_ERR(clk);
+	}
+
+	moxart_wdt->clock_frequency = clk_get_rate(clk);
+	if (moxart_wdt->clock_frequency == 0) {
+		pr_err("%s: incorrect clock frequency\n", __func__);
+		return -EINVAL;
+	}
+
+	max_timeout = UINT_MAX / moxart_wdt->clock_frequency;
+
+	moxart_wdt->dev.info = &moxart_wdt_info;
+	moxart_wdt->dev.ops = &moxart_wdt_ops;
+	moxart_wdt->dev.timeout = max_timeout;
+	moxart_wdt->dev.min_timeout = 1;
+	moxart_wdt->dev.max_timeout = max_timeout;
+	moxart_wdt->dev.parent = dev;
+
+	watchdog_init_timeout(&moxart_wdt->dev, heartbeat, dev);
+	watchdog_set_nowayout(&moxart_wdt->dev, nowayout);
+
+	watchdog_set_drvdata(&moxart_wdt->dev, moxart_wdt);
+
+	err = watchdog_register_device(&moxart_wdt->dev);
+	if (unlikely(err))
+		return err;
+
+	dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
+		moxart_wdt->dev.timeout, nowayout);
+
+	return 0;
+}
+
+static int moxart_wdt_remove(struct platform_device *pdev)
+{
+	struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
+
+	moxart_wdt_stop(&moxart_wdt->dev);
+	watchdog_unregister_device(&moxart_wdt->dev);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_watchdog_match[] = {
+	{ .compatible = "moxa,moxart-watchdog" },
+	{ },
+};
+
+static struct platform_driver moxart_wdt_driver = {
+	.probe      = moxart_wdt_probe,
+	.remove     = moxart_wdt_remove,
+	.driver     = {
+		.name		= "moxart-watchdog",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_watchdog_match,
+	},
+};
+module_platform_driver(moxart_wdt_driver);
+
+module_param(heartbeat, int, 0);
+MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");
+
+MODULE_DESCRIPTION("MOXART watchdog driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From sebastian.hesselbarth at gmail.com  Mon Jul 29 08:36:46 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Jul 2013 14:36:46 +0200
Subject: [PATCH 3/5] ARM: dove: add MBus DT node
In-Reply-To: <1375101114-28858-4-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1375101114-28858-4-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <51F661DE.1070106@gmail.com>

On 07/29/2013 02:31 PM, Sebastian Hesselbarth wrote:
> This adds a MBus node including ranges and pcie apertures required later.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
>   arch/arm/boot/dts/dove.dtsi |   19 +++++++++++++++++++
>   1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
> index 397674c..bdda016 100644
> --- a/arch/arm/boot/dts/dove.dtsi
> +++ b/arch/arm/boot/dts/dove.dtsi
> @@ -29,6 +29,20 @@
>   		marvell,tauros2-cache-features = <0>;
>   	};
>
> +	mbus {
> +		compatible = "marvell,dove-mbus", "marvell,mbus", "simple-bus";
> +		#address-cells = <2>;
> +		#size-cells = <1>;
> +		pcie-mem-aperture = <0xe0000000 0x10000000>; /* 256M MEM space */
> +		pcie-io-aperture  = <0xf2000000 0x00200000>; /*   2M I/O space */

Actually, current v9 of the mbus patch set still requires "controller"
property to match the corresponding controller node. I had a short
discussion with Ezequiel to possibly just use of_find_compatible_node
and blindly assumed post-v8 will already use it.

I will re-post the final patch set anyway on what mbus binding will be
merged for v3.12.

Sebastian

> +		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x0100000   /* MBUS regs  1M */
> +			  MBUS_ID(0xf0, 0x02) 0 0xf1800000 0x1000000   /* AXI  regs 16M */
> +			  MBUS_ID(0x01, 0xfd) 0 0xf8000000 0x8000000   /* BootROM  128M */
> +			  MBUS_ID(0x03, 0x01) 0 0xc8000000 0x0100000   /* CESA SRAM  1M */
> +			  MBUS_ID(0x0d, 0x00) 0 0xf0000000 0x0100000>; /* PMU  SRAM  1M */
> +	};
> +
>   	soc at f1000000 {
>   		compatible = "simple-bus";
>   		#address-cells = <1>;
> @@ -44,6 +58,11 @@
>   		          0xf2100000 0xf2100000 0x0100000   /* PCIe0 I/O   1M */
>   		          0xf8000000 0xf8000000 0x8000000>; /* BootROM   128M */
>
> +		mbusc: mbus-ctrl at 20000 {
> +			compatible = "marvell,mbus-controller";
> +			reg = <0x20000 0x80>, <0x800100 0x8>;
> +		};
> +
>   		timer: timer at 20300 {
>   			compatible = "marvell,orion-timer";
>   			reg = <0x20300 0x20>;
>



From javier.martinez at collabora.co.uk  Mon Jul 29 08:40:33 2013
From: javier.martinez at collabora.co.uk (Javier Martinez Canillas)
Date: Mon, 29 Jul 2013 14:40:33 +0200
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping
 for every GPIO on DT"
In-Reply-To: <CACRpkdZ1E9zC_yyK=UkJSejCwb_k7sYfhNgH5NASZ8Nf-qt2KA@mail.gmail.com>
References: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
 <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
 <51F633AE.8090308@collabora.co.uk>
 <alpine.DEB.2.02.1307290943000.30864@utopia.booyaka.com>
 <D135FD6D-D4B6-4237-9866-4FFED36C03CD@collabora.co.uk>
 <CACRpkdZ1E9zC_yyK=UkJSejCwb_k7sYfhNgH5NASZ8Nf-qt2KA@mail.gmail.com>
Message-ID: <798C2D39-EE8E-4C73-A98D-63231375599C@collabora.co.uk>

On 29/07/2013, at 13:43, Linus Walleij <linus.walleij at linaro.org> wrote:

> On Mon, Jul 29, 2013 at 12:19 PM, Javier Martinez Canillas
> <javier.martinez at collabora.co.uk> wrote:
> 
>> I guess the safer approach is to just revert these since they are causing
>> a regression and what the patches aims to fix as been broken since the
>> initial OMAP migration to DT anyways.
> 
> I have already reverted these and pushed to linux-next.
> 

Thanks for doing that and sorry for all the inconvenience.

Too bad this regression was not found before the patches hit mainline and they even were on linux-next for some time but shit happens :-(

> Actually input-hogs was not such a good idea either, after
> meditating on this I realized that the information about what
> GPIOs are used as interrupts is a piece of information that
> already exist in the device tree, albeit a bit distributed.
> 
> So I'm drafting an RFC to indicate how I think this should
> be solved.
> 

Great, I hope we can finally have a good solution for this long standing issue.

> Yours,
> Linus Walleij

Best regards,
Javier

From Sudeep.KarkadaNagesha at arm.com  Mon Jul 29 08:41:49 2013
From: Sudeep.KarkadaNagesha at arm.com (Sudeep KarkadaNagesha)
Date: Mon, 29 Jul 2013 13:41:49 +0100
Subject: [PATCH 1/4] ARM: dove: add cpu device tree node
In-Reply-To: <1375100946-28521-2-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1375100946-28521-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1375100946-28521-2-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <51F6630D.5010603@arm.com>

On 29/07/13 13:29, Sebastian Hesselbarth wrote:
> This adds a node for the Marvell Sheeva PJ4A CPU found on Dove SoCs.
> While at it, also move the l2-cache node out of internal registers and
> consistently name different nodes.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Andrew Lunn <andrew at lunn.ch>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: devicetree at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  arch/arm/boot/dts/dove.dtsi |   52 ++++++++++++++++++++++++++-----------------
>  1 file changed, 32 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
> index 8d5be1e8..09d9710 100644
> --- a/arch/arm/boot/dts/dove.dtsi
> +++ b/arch/arm/boot/dts/dove.dtsi
> @@ -10,6 +10,23 @@
>  		gpio2 = &gpio2;
>  	};
>  
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu0: cpu at 0 {
> +			compatible = "marvell,pj4a", "marvell,sheeva-v7";
> +			device_type = "cpu";
> +			next-level-cache = <&l2>;
> +			reg = <0>;
> +		};
> +	};
> +
> +	l2: l2-cache {
> +		compatible = "marvell,tauros2-cache";
> +		marvell,tauros2-cache-features = <0>;
> +	};
Hi Sebastian,

This is not entirely related to the patch but thought of checking with
you. I was trying to get info on L2 cache controller on Marvell SoCs,
mainly structure or way/set size. Is that something we can get
dynamically ? Some specification I referred said its integrated and some
said its separate(not unified). Basically I need information around
various L2 cache implementations(Tauros2/Feroceon) from Marvell.

Any pointers or contacts to get this information will be helpful.

Regards,
Sudeep




From 21cnbao at gmail.com  Mon Jul 29 08:46:58 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Mon, 29 Jul 2013 20:46:58 +0800
Subject: [PATCH] DMAEngine: sirf: let the users be able to pause and
 resume specific buffer
In-Reply-To: <20130729121715.GI24642@n2100.arm.linux.org.uk>
References: <1372927373-17407-1-git-send-email-Baohua.Song@csr.com>
 <CAGsJ_4wOdDMku-pNWiH-DoS_v39PfFwNYcU4T1Thsd-+L9A8AQ@mail.gmail.com>
 <20130729060819.GE29095@intel.com>
 <CAGsJ_4yVxAJc0UNTFMM1yjKQh6=xv12qPYpnUFZ=wmzrdpUOXQ@mail.gmail.com>
 <20130729121715.GI24642@n2100.arm.linux.org.uk>
Message-ID: <CAGsJ_4zRZ96L8ezQVyz6LQ8VgBCExML6RF_3DtTQR+ntsJHnZg@mail.gmail.com>

2013/7/29 Russell King - ARM Linux <linux at arm.linux.org.uk>:
> On Mon, Jul 29, 2013 at 03:20:31PM +0800, Barry Song wrote:
>> 2013/7/29 Vinod Koul <vinod.koul at intel.com>:
>> > The above can be done by
>> > a) have two buffers:
>> >         - prepare first and submit, and start
>> >         - while first is ongoing, prepare second and start
>> >         - first is completed, so you start processing that while second is
>> >           getting DMAed
>> >         - when processing is completed, submit first again
>> >         - when second is completed, start processing that and submit that once
>> >           proocessed
>> >
>> > b) have multiple buffers, A, B, C & D and redo above schema.
>>
>> yes, that is the original idea for multiple buffer management for DMA.
>>
>> the reason which pushed us to the ping-pong pause is that we don't
>> need to issue software dma descriptor every time for every buffer as
>> hardware can do that.
>
> If your DMA engine is correctly implemented (and this only works for
> correctly implemented DMA engines), what you can do is:
>
> - at the start of the transfer, prepare, submit and issue two buffers,
>   each with a callback.
> - when the first callback happens
>   - that buffer has been transferred.
>   - you can now do whatever you need with that data.
>   - prepare, submit and issue the next buffer
>
> This means the DMA engine always has a buffer available to it, so if
> your CPU is fast enough, you can keep the transfer going without the
> DMA channel ever stopping or having to be paused.  If your CPU isn't
> fast enough to keep up, the DMA engine will stop at the end of the
> last queued and issued buffer automatically.
>

yes, suppose there are 4 buffers, we can issue all of buffer 0,1,2,3
at first. if buffer 0 has been read when buffer 3 is transferred,
buffer0 must have been issued again.
so that will keep buffers always alive if cpu is fast enough.

> Bonus points if you have implemented the "move to next buffer" correctly
> too, so that the hardware can do a continuous transfer without having to
> stop and wait between the buffers (provided of course that the next
> transfer is compatible with the previous.)

-barry


From 21cnbao at gmail.com  Mon Jul 29 08:49:10 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Mon, 29 Jul 2013 20:49:10 +0800
Subject: [PATCH] DMAEngine: sirf: let the users be able to pause and
 resume specific buffer
In-Reply-To: <20130729113507.GJ29095@intel.com>
References: <1372927373-17407-1-git-send-email-Baohua.Song@csr.com>
 <CAGsJ_4wOdDMku-pNWiH-DoS_v39PfFwNYcU4T1Thsd-+L9A8AQ@mail.gmail.com>
 <20130729120830.GH24642@n2100.arm.linux.org.uk>
 <20130729113507.GJ29095@intel.com>
Message-ID: <CAGsJ_4wZR=YO3caD8YTURTwZXSkVYLPVENgJiuH0a46vZcvDdA@mail.gmail.com>

2013/7/29 Vinod Koul <vinod.koul at intel.com>:
> On Mon, Jul 29, 2013 at 01:08:30PM +0100, Russell King - ARM Linux wrote:
>> On Mon, Jul 29, 2013 at 10:14:24AM +0800, Barry Song wrote:
>> > 2013/7/4 Barry Song <Baohua.Song at csr.com>
>> > >
>> > > From: Qipan Li <Qipan.Li at csr.com>
>> > >
>> > > this patch adds a buffer_index in pause and resume entries, then users can
>> > > pause and resume a buffer they want, but don't pause the whole dma.
>> > >
>> > > a typical application scenerios is Ping-Pang in two buffers: at the
>> > > beginning, we enable buf1 and buf2 to receive dma data, after buf1 is
>> > > full, we pause buf1 and handle the data in this buffer to avoid overflow
>> > > in buf1. but at the same time, dma is still tranferring in buf2.  once we
>> > > have finished data process in buf1, we enable buf1 again.  this will
>> > > maximize the chance of dma transferring. users pause buf1 by:
>> > > dmaengine_device_control(sirfport->rx_dma_chan, DMA_PAUSE, 1); users pause
>> > > buf2 by: dmaengine_device_control(sirfport->rx_dma_chan, DMA_PAUSE, 2);
>> > > users can still pause the whole dma transferring by dmaengine_pause().
>> > >
>> > > Signed-off-by: Qipan Li <Qipan.Li at csr.com> Signed-off-by: Barry Song
>> > > <Baohua.Song at csr.com> --- drivers/dma/sirf-dma.c | 102
>> > > ++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 80
>> > > insertions(+), 22 deletions(-)
>> >
>> > Hi Vinod, as we still have some other patches of dma clients depending on
>> > this, would you give some comments about it?
>>
>> You at least need to write up some documentation about this new feature - you
>> need to describe exactly how this argument relates to a set of queued DMA
>> descriptor(s) and its semantics with respect to those queued descriptors.
> As I commented earlier today, I dont think we need this way. This can also be
> achieved with submitting descriptors after the buffer has been processed.

we submit all buffers together at the beginning, once one buffer is
right handled by cpu after dma transfers, we issue it again.

>
>> From the looks of this patch, it has nothing to do with any particular
>> queued descriptor, but you're exposing internal knowledge of the SiRF
>> DMA engine.
> More than dmaengine its the way of modelling here which seems to be the issue
>
> ~Vinod
> --
-barry


From daniel.lezcano at linaro.org  Mon Jul 29 08:51:49 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 29 Jul 2013 14:51:49 +0200
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
References: <20130717210417.GP13667@xsjandreislx>
 <51E72DCA.9070500@codeaurora.org>
 <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
Message-ID: <51F66565.7010600@linaro.org>

On 07/23/2013 12:41 AM, S?ren Brinkmann wrote:
> Hi,
> 
> adding LKML and LAKML (which I forgot on the original email, sorry)
> 
> On Mon, Jul 22, 2013 at 01:13:48PM -0700, S?ren Brinkmann wrote:
>> On Mon, Jul 22, 2013 at 12:54:26PM -0700, Stephen Boyd wrote:
>>> On 07/22/13 11:25, S?ren Brinkmann wrote:
>>>> On Wed, Jul 17, 2013 at 06:22:35PM -0700, Stephen Boyd wrote:
>>>>> On 07/17/13 17:59, S?ren Brinkmann wrote:
>>>>>> Hi Stephen,
>>>>>>
>>>>>> On Wed, Jul 17, 2013 at 04:50:34PM -0700, Stephen Boyd wrote:
>>>>>>> On 07/17/13 14:04, S?ren Brinkmann wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I'm trying to enable the arm_global_timer on Zynq platforms with the
>>>>>>>> attached patch. Unfortunately that patch breaks booting up. It hangs
>>>>>>>> when handing over to init/early userspace (see attached boot.log).
>>>>>>>>
>>>>>>>> The funny thing is, if I remove either the global timer or the
>>>>>>>> arm,cortex-a9-twd-timer node from my dts, it works. So, it looks like
>>>>>>>> the two timer (drivers) interfere somehow. Does anybody have an idea of
>>>>>>>> what is going on and probably even how to resolve it?
>>>>>>>>
>>>>>>>> The patch is based on commit c0d15cc in Linus' tree.
>>>>>>> If you boot with one CPU does it hang? It looks like secondary CPUs
>>>>>>> aren't getting interrupts but I'm not sure why. Maybe you can try this
>>>>>>> patch and/or put some prints in the timer interrupt handler to see if
>>>>>>> interrupts are firing on secondary CPUs.
>>>>>> Your proposed patch does not seem to make a difference, but adding
>>>>>> 'maxcpus=1' to the kernel command line makes the system boot.
>>>>> Hmm I guess that doesn't really confirm much because TWD doesn't
>>>>> register itself on maxcpus=1 systems, so it's the same as removing the
>>>>> node from DT. Probably easier to put a printk in the interrupt handler
>>>>> and confirm that you're receiving interrupts on secondary CPUs.
>>>> Turns out it does work when I disable Zynq's cpuidle driver. I think I
>>>> can blame that driver.
>>>>
>>>
>>> Hmm.. Perhaps the arm_global_timer driver also needs FEAT_C3_STOP added
>>> to it. Do you know if that timer is reset during low power modes?
>>
>> Our cpudidle driver is not powering off anything, AFAIK. I think it just
>> executes 'wfi' on the CPU. I don't know how the timer core handles it,
>> but I'd expect the CPU should find the timer just a it was left before
>> entering idle (well, the timer continues to run I assume, but other than
>> that).
>> I'll do some debugging and see if I can find out what exactly causes the
>> hang.
> 
> So, what I found:
> The Zynq cpuidle driver provides two idle states, which are both
> basically just ARM wfi states. But the second one set's these flags:
> 	.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_TIMER_STOP,
> 
> I don't know what these flags cause in detail. But the
> CPUIDLE_FLAG_TIMER_STOP seemed suspicious, since wfi does not have any
> effect on the timer. So, I removed that one and things are working.
> 
> I also tried the other approach: Leaving cpuidle as is and adding the
> C3STOP flag to the global timer. That solves it too.
> 
> Does anybody know what the correct solution is?
> In case the C3STOP flag is considered to be corret for the timer, I
> could prepare a patch for that and bundle it with the one to enable the
> timer for Zynq?

Hi Soren,

the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
timer will be stopped when entering to the idle state. In this case, the
cpuidle framework will call clockevents_notify(ENTER) and switches to a
broadcast timer and will call clockevents_notify(EXIT) when exiting the
idle state, switching the local timer back in use.

The C3STOP flag has a similar semantic than the CPUIDLE_FLAG_TIMER_STOP,
that is the timer can be shutdown with a specific idle state. This flag
is used by the tick broadcast code.

If the C3STOP flag is not set for a local timer, the
CPUIDLE_FLAG_TIMER_STOP does not make sense because it will be ignored
by the tick-broadcast code.

If the local timer could be shutdown at idle time, you *must* specify
this flag.

If the idle state shutdowns the cpu with its local timer, you *must*
specify the CPUIDLE_FLAG_TIMER_STOP flag for this specific state.

At the first glance, the idle state #2 is aimed to do DDR self refresh
and to switch to WFI, so no power gating, then no local timer down. The
CPUIDLE_FLAG_TIMER_STOP shouldn't be used here.

IIUC, the global timer does not belong to the CPU and the cluster power
domains, so it can't be shutdown: the C3STOP shouldn't be used.

I hope that helps.

  -- Daniel


> @Michal: What do we do about the cpuidle driver? If you asked me, we
> should rip out the second state completely. We have it as disabled
> placeholder in our vendor tree and it seems to break things having it
> enabled in mainline.
> 
> 
> 	S?ren
> 
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From ian.campbell at citrix.com  Mon Jul 29 08:56:18 2013
From: ian.campbell at citrix.com (Ian Campbell)
Date: Mon, 29 Jul 2013 13:56:18 +0100
Subject: [PATCH] arm: update advice on kernel and FDT load address.
Message-ID: <1375102578-5869-1-git-send-email-ian.campbell@citrix.com>

Based on the discussion in [0]:
  - Recommend that the kernel be placed under 128MiB ("for automatic RAM
    location to work", says Nico)
  - Recommend that DTB larger than ~16KiB be placed after the 128MiB boundary
    (in order to avoid conflicting with the kernel decompressor, kernel is at
    most 32MiB) and within the lowmem region. Somewhat arbitrarily recommend
    placement below the 256MiB boundary, the real lowmem limit is likely up
    around 600-800MiB but varies.

[0] http://article.gmane.org/gmane.linux.ports.arm.kernel/254538

Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Nicolas Pitre <nicolas.pitre at linaro.org>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Dave Martin <dave.martin at linaro.org>
Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: linux-arm-kernel at lists.infradead.org
---
 Documentation/arm/Booting |   14 +++++++++++---
 1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting
index 0c1f475..72c035e 100644
--- a/Documentation/arm/Booting
+++ b/Documentation/arm/Booting
@@ -125,6 +125,13 @@ with the caveat that it may not be located at physical address 0 since
 the kernel interprets a value of 0 in r2 to mean neither a tagged list
 nor a dtb were passed.
 
+If the DTB is larger than ~16KiB, such that placement in the first
+16KiB would lead to a conflict with the kernel loaded at 32KiB (as
+recommended below) which uses the memory between 16KiB-32KiB itself,
+then the DTB should be placed after the first 128MiB of RAM in order
+to avoid conflicting with the kernel decompressor. The recommnded
+placement in this case just below the 256MiB boundary.
+
 5. Calling the kernel image
 ---------------------------
 
@@ -136,9 +143,10 @@ is stored in flash, and is linked correctly to be run from flash,
 then it is legal for the boot loader to call the zImage in flash
 directly.
 
-The zImage may also be placed in system RAM (at any location) and
-called there.  Note that the kernel uses 16K of RAM below the image
-to store page tables.  The recommended placement is 32KiB into RAM.
+The zImage may also be placed in system RAM and called there.  The
+kernel should be placed in the first 128MiB of RAM. Note that the
+kernel uses 16KiB of RAM below the image to store page tables.  The
+recommended placement is 32KiB into RAM.
 
 In either case, the following conditions must be met:
 
-- 
1.7.2.5



From santosh.shilimkar at ti.com  Mon Jul 29 08:57:27 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 29 Jul 2013 08:57:27 -0400
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping
 for every GPIO on DT"
In-Reply-To: <51F63864.9000601@collabora.co.uk>
References: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
 <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
 <51F633AE.8090308@collabora.co.uk> <51F63864.9000601@collabora.co.uk>
Message-ID: <51F666B7.7020209@ti.com>

Javier,

On Monday 29 July 2013 05:39 AM, Javier Martinez Canillas wrote:
> On 07/29/2013 11:19 AM, Javier Martinez Canillas wrote:
>> On 07/29/2013 11:01 AM, Linus Walleij wrote:
>>> Hi Paul,
>>>
>>> On Mon, Jul 29, 2013 at 9:52 AM, Paul Walmsley <paul at pwsan.com> wrote:
>>>
>>>> your commit 0e970cec05635adbe7b686063e2548a8e4afb8f4 ("gpio/omap: don't
>>>> create an IRQ mapping for every GPIO on DT") breaks the boot on the
>>>> OMAP5912 OSK:
>>>
>>> I'm contemplating just reverting this whole series, as I didn't like
>>> the approach from the beginning and it has exploded in exactly
>>> the way I thought it would.
>>>
>>> If we revert these three patches:
>>>
>>> commit 949eb1a4d29dc75e0b5b16b03747886b52ecf854
>>> "gpio/omap: fix build error when OF_GPIO is not defined."
>>> commit b4419e1a15905191661ffe75ba2f9e649f5d565e
>>> "gpio/omap: auto request GPIO as input if used as IRQ via DT"
>>> commit 0e970cec05635adbe7b686063e2548a8e4afb8f4
>>> "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
>>>
>>> Does the OMAP1 boot again after this?
>>>
>>> I think it's a way better idea to proceed with input-hogs on the gpiochip
>>> DT node and use that to get auto-request on the GPIO lines that
>>> will be used as IRQs only.
>>>
>>> Yours,
>>> Linus Walleij
>>>
>>
>> Hi Paul,
>>
>> I've looked at this and it seems that irq_create_mapping() does not call the
>> irq_domain_ops .map function handler since OMAP1 still uses legacy domain
>> mapping. I don't have an OMAP1 platform to test but could you please see if the
>> following patch [1] makes your OMAP1 platforms to boot again?
>>
>> But I agree with Linus and probably we should just go and revert the whole
>> series since it is very hard to get it right. In another thread a user reported
>> that this change also broke his DTS tree.
>>
>> I really tried to get this right without breaking anything but there are just
>> too many OMAP platforms behaving differently and most OMAP drivers are only half
>> converted to DT so this is really a can of worms.
>>
>> Thanks a lot and sorry for the inconvenience,
>> Javier
>>
>> [1]:
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index c57244e..f1c6da8 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -1090,8 +1090,18 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
>>          * are used as interrupts.
>>          */
>>         if (!omap_gpio_chip_boot_dt(&bank->chip))
>> -               for (j = 0; j < bank->width; j++)
>> -                       irq_create_mapping(bank->domain, j);
>> +               for (j = 0; j < bank->width; j++) {
>> +                       int irq = irq_create_mapping(bank->domain, j);
>> +                       irq_set_lockdep_class(irq, &gpio_lock_class);
>> +                       irq_set_chip_data(irq, bank);
>> +                       if (bank->is_mpuio) {
>> +                               omap_mpuio_alloc_gc(bank, irq, bank->width);
>> +                       } else {
>> +                               irq_set_chip_and_handler(irq, &gpio_irq_chip,
>> +                                                        handle_simple_irq);
>> +                               set_irq_flags(irq, IRQF_VALID);
>> +                       }
>> +               }
>>         irq_set_chained_handler(bank->irq, gpio_irq_handler);
>>         irq_set_handler_data(bank->irq, bank);
>>
> 
> In case this solves Paul issue, a cleaned patch with a commit message is [2].
> But we should decide if is better to fix this or just drop the patches and go
> with Linus' input-hogs idea to do the GPIO auto request.
> 
> Santosh, Kevin, Grant, what do you think we should do?
> 
With some helps from MMC and other guys, we validated the Linus's tip which includes
your patches. It actually doesn't break anything and as OMAP hsmmc maintainer
clarified, the cd-gpios isn't supported yet for DT. While supporting that it
can use appropriate binding whichever works.

But with OMAP1 breakage reported by Paul, I think we are not left with choice
but to revert those commits. We *must* respect rc rules for the fixes.
*No regression*

Thanks for your hardwork to cook up those patches but now Linus's W proposal
is going to be generic, hopefully the issue can be address better. Till
then we can't get the ethernet support.

Linus,
I guess you have already gone ahead on revert path as seen from other email.
Lets just make that official. We are sorry for cause you trouble over a
week-end.

Regards,
Santosh




From thierry.reding at gmail.com  Mon Jul 29 08:58:27 2013
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 29 Jul 2013 14:58:27 +0200
Subject: [PATCHv5 05/11] of: pci: add registry of MSI chips
In-Reply-To: <20130729142600.63eeab50@skate>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E41F7A.4010502@gmail.com> <20130728043310.6CF1D3E08FE@localhost>
 <20130728162711.32a9a21e@skate> <20130729065431.GA1115@manwe>
 <20130729142600.63eeab50@skate>
Message-ID: <20130729125826.GH23152@manwe>

On Mon, Jul 29, 2013 at 02:26:00PM +0200, Thomas Petazzoni wrote:
> Dear Thierry Reding,
> 
> On Mon, 29 Jul 2013 08:54:31 +0200, Thierry Reding wrote:
> 
> > > So what is your suggestion to allow the PCIe controller to retrieve the
> > > correct irq_domain if we have only one DT node for the IRQ controller
> > > that registers two irq_domains ?
> > 
> > If I understand correctly, Grant isn't objecting to the introduction of
> > the lookup function, but rather its implementation. You could add a
> > pointer to a struct msi_chip within struct irq_domain and then iterate
> > over all irq_domain instances (see irq_find_host()) and find one which
> > has the correct device_node pointer and the msi_chip pointer set.
> 
> Ah ok. The only trick is that we have to change irq_find_host() to
> *not* match on MSI domains. Can you check the below patch to see if it
> matches what Grant suggested? It works for me, and it allows to completely
> remove the registry of msi_chip in drivers/of, as well as the of_node
> pointer in struct msi_chip.
> 
> Thanks!
> 
> Thomas
> 
> From c2c0137cb110270f96e1e0fa298a5d585b8d829e Mon Sep 17 00:00:00 2001
> From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Date: Mon, 29 Jul 2013 14:12:31 +0200
> Subject: [PATCHv6 05/11] irqdomain: add support to associate an irq_domain
>  with a msi_chip
> 
> Message Signaled Interrupts are a PCI-specific mechanism that allows
> PCI devices to notify interrupts to the CPU using in-band
> messages. The PCI subsystem represents an MSI-capable interrupt
> controller as an msi_chip structure, and this patch improves the
> irqdomain subsystem with a new pointer associating an irq_domain with
> the corresponding msi_chip.
> 
> The __irq_domain_add() function is augmented with an additional
> argument, the 'msi_chip' pointer, and all callers of this function are
> updated.
> 
> A new function irq_domain_add_msi() function is added to allow the
> registration of an MSI-type irq domain.
> 
> The irq_find_host() function is modified to not match on MSI-type irq
> domains: a given DT device node may represent both a normal interrupt
> controller and a MSI interrupt controller. irq_find_host() should
> return the irq_domain that corresponds to the normal interupt

"interupt" -> "interrupt"

> controller.
> 
> An irq_find_msi() function is added to get the MSI_type irq domain

"MSI_type" -> "MSI-type".

> given a DT device node.

And "irq domain" -> "IRQ domain" in all of the above.

> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
[...]
> @@ -162,7 +167,16 @@ static inline struct irq_domain *irq_domain_add_tree(struct device_node *of_node
>  					 const struct irq_domain_ops *ops,
>  					 void *host_data)
>  {
> -	return __irq_domain_add(of_node, 0, ~0, 0, ops, host_data);
> +	return __irq_domain_add(of_node, 0, ~0, 0, ops, NULL, host_data);
> +}
> +static inline struct irq_domain *irq_domain_add_msi(struct device_node *of_node,
> +						    unsigned int size,
> +						    const struct irq_domain_ops *ops,
> +						    struct msi_chip *msi_chip,
> +						    void *host_data)
> +{
> +	return __irq_domain_add(of_node, size, size, 0, ops,
> +				msi_chip, host_data);
>  }

Given that the majority of interrupt controllers probably don't have any
MSI functionality, I wonder if perhaps this should be done in a more
helper-oriented way, see below...

> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
[...]
> @@ -198,6 +201,12 @@ struct irq_domain *irq_find_host(struct device_node *node)
>  	 */
>  	mutex_lock(&irq_domain_mutex);
>  	list_for_each_entry(h, &irq_domain_list, link) {
> +		/*
> +		 * We only want to match normal interrupt domains, not
> +		 * MSI domains
> +		 */
> +		if (h->msi_chip)
> +			continue;
>  		if (h->ops->match)
>  			rc = h->ops->match(h, node);
>  		else
> @@ -214,6 +223,28 @@ struct irq_domain *irq_find_host(struct device_node *node)
>  EXPORT_SYMBOL_GPL(irq_find_host);
>  
>  /**
> + * irq_find_msi() - Locates a MSI domain for a given device node
> + * @node: device-tree node of the interrupt controller
> + */
> +struct irq_domain *irq_find_msi(struct device_node *node)
> +{
> +	struct irq_domain *h, *found = NULL;
> +
> +	mutex_lock(&irq_domain_mutex);
> +	list_for_each_entry(h, &irq_domain_list, link) {
> +		if (!h->msi_chip)
> +			continue;
> +		if (h->of_node && h->of_node == node) {
> +			found = h;
> +			break;
> +		}
> +	}
> +	mutex_unlock(&irq_domain_mutex);
> +	return found;
> +}
> +EXPORT_SYMBOL_GPL(irq_find_msi);

This doesn't quite copy what irq_find_host() does, since it ignores the
associated ops->match().

But given that ops->match() already provides a way to hook into the
lookup, perhaps we could add a function such as this:

	int irq_domain_supports_msi(struct irq_domain *d, struct device_node *node)
	{
		if ((d->of_node == NULL) || (d->of_node != node))
			return 0;

		return d->msi_chip != NULL;
	}

Then use that in drivers that expose MSI functionality via an IRQ domain
like this:

	static const struct irq_domain_ops foo_irq_domain_ops = {
		...
		.match = irq_domain_supports_msi,
		...
	};

One problem with this is that it doesn't solve your problem where two
different IRQ domains are exposed by the same device, because the
irq_find_host() will still match the MSI IRQ domain for the non-MSI
device node as well. This could be solved by adding another match
function...

This goes in hand with the helper-style API that I mentioned above. But
it's really up to Grant to decide which way he wants this to go.

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/20130729/4b52a29e/attachment-0001.sig>

From g.liakhovetski at gmx.de  Mon Jul 29 09:03:01 2013
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Mon, 29 Jul 2013 15:03:01 +0200 (CEST)
Subject: [BUILD BREAKAGE] today's next build broken for pcm037
Message-ID: <Pine.LNX.4.64.1307291458560.14405@axis700.grange>

Hi Sascha,

Attached .config fails to build for me with today's next as follows:

ERROR: "imx_pcm_dma_init" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined!
ERROR: "imx_pcm_dma_exit" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [sub-make] Error 2

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
-------------- next part --------------
CONFIG_LOCALVERSION="-pcm037"
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_FHANDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_EMBEDDED=y
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_LBDAF is not set
# CONFIG_BLK_DEV_BSG is not set
CONFIG_PARTITION_ADVANCED=y
# CONFIG_EFI_PARTITION is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_ARCH_MULTI_V6=y
# CONFIG_ARCH_MULTI_V7 is not set
CONFIG_GPIO_PCA953X=m
CONFIG_ARCH_MXC=y
# CONFIG_MACH_MX31ADS is not set
CONFIG_MACH_PCM037=y
# CONFIG_CACHE_L2X0 is not set
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
# CONFIG_COMPACTION is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="ro"
CONFIG_VFP=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_PM_RUNTIME=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
# CONFIG_INET_DIAG is not set
# CONFIG_IPV6 is not set
CONFIG_NETLINK_MMAP=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_OF_PARTS is not set
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_PHYSMAP=y
# CONFIG_BLK_DEV is not set
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
# CONFIG_SCSI_LOWLEVEL is not set
CONFIG_NETDEVICES=y
# CONFIG_NET_VENDOR_ARC is not set
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_VENDOR_CIRRUS is not set
# CONFIG_NET_VENDOR_FARADAY is not set
# CONFIG_NET_VENDOR_FREESCALE is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_NET_VENDOR_MARVELL is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_NET_VENDOR_SEEQ is not set
CONFIG_SMSC911X=y
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_VIA is not set
# CONFIG_NET_VENDOR_WIZNET is not set
# CONFIG_WLAN is not set
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_IMX=y
CONFIG_SERIAL_IMX_CONSOLE=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_IMX=y
CONFIG_GPIO_SYSFS=y
# CONFIG_HWMON is not set
CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_MEDIA_SUPPORT=m
CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_MEDIA_CONTROLLER=y
CONFIG_VIDEO_V4L2_SUBDEV_API=y
CONFIG_V4L_PLATFORM_DRIVERS=y
CONFIG_SOC_CAMERA=m
CONFIG_SOC_CAMERA_PLATFORM=m
CONFIG_VIDEO_MX3=m
CONFIG_VIDEO_SH_MOBILE_CSI2=m
CONFIG_VIDEO_SH_MOBILE_CEU=m
CONFIG_V4L_TEST_DRIVERS=y
CONFIG_VIDEO_VIVI=m
CONFIG_VIDEO_MEM2MEM_TESTDEV=m
# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
CONFIG_VIDEO_MT9P031=m
CONFIG_SOC_CAMERA_IMX074=m
CONFIG_SOC_CAMERA_MT9M001=m
CONFIG_SOC_CAMERA_MT9M111=m
CONFIG_SOC_CAMERA_MT9T031=m
CONFIG_SOC_CAMERA_MT9T112=m
CONFIG_SOC_CAMERA_MT9V022=m
CONFIG_SOC_CAMERA_OV2640=m
CONFIG_SOC_CAMERA_OV5642=m
CONFIG_SOC_CAMERA_OV6650=m
CONFIG_SOC_CAMERA_OV772X=m
CONFIG_SOC_CAMERA_OV9640=m
CONFIG_SOC_CAMERA_OV9740=m
CONFIG_SOC_CAMERA_RJ54N1=m
CONFIG_SOC_CAMERA_TW9910=m
# CONFIG_DVB_AU8522_V4L is not set
# CONFIG_DVB_TUNER_DIB0070 is not set
# CONFIG_DVB_TUNER_DIB0090 is not set
CONFIG_FB=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
CONFIG_SOUND=m
CONFIG_SND=m
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
# CONFIG_SND_DRIVERS is not set
# CONFIG_SND_ARM is not set
# CONFIG_SND_USB is not set
CONFIG_SND_SOC=m
CONFIG_SND_IMX_SOC=m
CONFIG_SND_SOC_IMX_SGTL5000=m
CONFIG_SND_SIMPLE_CARD=m
CONFIG_USB=m
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_HCD_PLATFORM=m
CONFIG_USB_STORAGE=m
CONFIG_MMC=y
CONFIG_NEW_LEDS=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_PCF8563=m
CONFIG_DMADEVICES=y
CONFIG_EXT2_FS=m
CONFIG_EXT3_FS=m
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
# CONFIG_DNOTIFY is not set
CONFIG_FANOTIFY=y
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=850
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-15"
CONFIG_TMPFS=y
CONFIG_JFFS2_FS=y
CONFIG_NFS_FS=y
CONFIG_ROOT_NFS=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-15"
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_ISO8859_15=y
CONFIG_PRINTK_TIME=y
CONFIG_READABLE_ASM=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
# CONFIG_FTRACE is not set
CONFIG_DEBUG_USER=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y

From thomas.petazzoni at free-electrons.com  Mon Jul 29 09:04:38 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 29 Jul 2013 15:04:38 +0200
Subject: [PATCHv5 05/11] of: pci: add registry of MSI chips
In-Reply-To: <20130729125826.GH23152@manwe>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E41F7A.4010502@gmail.com> <20130728043310.6CF1D3E08FE@localhost>
 <20130728162711.32a9a21e@skate> <20130729065431.GA1115@manwe>
 <20130729142600.63eeab50@skate> <20130729125826.GH23152@manwe>
Message-ID: <20130729150438.4872da76@skate>

Dear Thierry Reding,

On Mon, 29 Jul 2013 14:58:27 +0200, Thierry Reding wrote:

> >  /**
> > + * irq_find_msi() - Locates a MSI domain for a given device node
> > + * @node: device-tree node of the interrupt controller
> > + */
> > +struct irq_domain *irq_find_msi(struct device_node *node)
> > +{
> > +	struct irq_domain *h, *found = NULL;
> > +
> > +	mutex_lock(&irq_domain_mutex);
> > +	list_for_each_entry(h, &irq_domain_list, link) {
> > +		if (!h->msi_chip)
> > +			continue;
> > +		if (h->of_node && h->of_node == node) {
> > +			found = h;
> > +			break;
> > +		}
> > +	}
> > +	mutex_unlock(&irq_domain_mutex);
> > +	return found;
> > +}
> > +EXPORT_SYMBOL_GPL(irq_find_msi);
> 
> This doesn't quite copy what irq_find_host() does, since it ignores the
> associated ops->match().

Correct.

> But given that ops->match() already provides a way to hook into the
> lookup, perhaps we could add a function such as this:
> 
> 	int irq_domain_supports_msi(struct irq_domain *d, struct device_node *node)
> 	{
> 		if ((d->of_node == NULL) || (d->of_node != node))
> 			return 0;
> 
> 		return d->msi_chip != NULL;
> 	}
> 
> Then use that in drivers that expose MSI functionality via an IRQ domain
> like this:
> 
> 	static const struct irq_domain_ops foo_irq_domain_ops = {
> 		...
> 		.match = irq_domain_supports_msi,
> 		...
> 	};
>
> One problem with this is that it doesn't solve your problem where two
> different IRQ domains are exposed by the same device, because the
> irq_find_host() will still match the MSI IRQ domain for the non-MSI
> device node as well.

Indeed.

> This could be solved by adding another match function...

But this would involve changing all the users of irq_find_host(), no?

> This goes in hand with the helper-style API that I mentioned above. But
> it's really up to Grant to decide which way he wants this to go.

Yes, Grant, your suggestions are welcome on this. Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From jonas.jensen at gmail.com  Mon Jul 29 09:06:01 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Mon, 29 Jul 2013 15:06:01 +0200
Subject: [PATCH v4] gpio: Add MOXA ART GPIO driver
In-Reply-To: <1374053693-6166-1-git-send-email-jonas.jensen@gmail.com>
References: <1374053693-6166-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1375103161-12460-1-git-send-email-jonas.jensen@gmail.com>

Add GPIO driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v3:
    
    1. use local struct device *dev pointer, replace "&pdev->dev" with "dev"
    
    device tree bindings document:
    2. describe compatible variable "Must be" instead of "Should be".
    
    Applies to next-20130729

 .../devicetree/bindings/gpio/moxa,moxart-gpio.txt  |  23 +++
 drivers/gpio/Kconfig                               |   7 +
 drivers/gpio/Makefile                              |   1 +
 drivers/gpio/gpio-moxart.c                         | 189 +++++++++++++++++++++
 4 files changed, 220 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt
 create mode 100644 drivers/gpio/gpio-moxart.c

diff --git a/Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt b/Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt
new file mode 100644
index 0000000..795afab
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt
@@ -0,0 +1,23 @@
+MOXA ART GPIO Controller
+
+Required properties:
+
+- #gpio-cells : Should be 2
+- compatible : Must be "moxa,moxart-gpio"
+- reg : Should contain registers location and length
+	index 0 : input, output, and direction control
+	index 1 : enable/disable individual pins, pin 0-31
+- gpio-ready-led : ready LED gpio, with zero flags
+- gpio-reset-switch : reset switch gpio, with zero flags
+
+Example:
+
+	gpio: gpio at 98700000 {
+		gpio-controller;
+		#gpio-cells = <2>;
+		compatible = "moxa,moxart-gpio";
+		reg =	<0x98700000 0xC>,
+			<0x98100100 0x4>;
+		gpio-ready-led = <&gpio 27 0>;
+		gpio-reset-switch = <&gpio 25 0>;
+	};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 4b7ba53..5419413 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -741,6 +741,13 @@ config GPIO_MSIC
 	  Enable support for GPIO on intel MSIC controllers found in
 	  intel MID devices
 
+config GPIO_MOXART
+	bool "MOXART GPIO support"
+	depends on ARCH_MOXART
+	help
+	  Select this option to enable GPIO driver for
+	  MOXA ART SoC devices.
+
 comment "USB GPIO expanders:"
 
 config GPIO_VIPERBOARD
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 156fd28..c7a7a2b 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_GPIO_MC9S08DZ60)	+= gpio-mc9s08dz60.o
 obj-$(CONFIG_GPIO_MCP23S08)	+= gpio-mcp23s08.o
 obj-$(CONFIG_GPIO_ML_IOH)	+= gpio-ml-ioh.o
 obj-$(CONFIG_GPIO_MM_LANTIQ)	+= gpio-mm-lantiq.o
+obj-$(CONFIG_GPIO_MOXART)	+= gpio-moxart.o
 obj-$(CONFIG_GPIO_MPC5200)	+= gpio-mpc5200.o
 obj-$(CONFIG_GPIO_MPC8XXX)	+= gpio-mpc8xxx.o
 obj-$(CONFIG_GPIO_MSIC)		+= gpio-msic.o
diff --git a/drivers/gpio/gpio-moxart.c b/drivers/gpio/gpio-moxart.c
new file mode 100644
index 0000000..a5bdbca
--- /dev/null
+++ b/drivers/gpio/gpio-moxart.c
@@ -0,0 +1,189 @@
+/*
+ * MOXA ART SoCs GPIO driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/io.h>
+#include <linux/gpio.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_gpio.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/delay.h>
+#include <linux/timer.h>
+
+#define GPIO_DATA_OUT		0x00
+#define GPIO_DATA_IN		0x04
+#define GPIO_PIN_DIRECTION	0x08
+
+static void __iomem *moxart_pincontrol_base;
+static void __iomem *moxart_gpio_base;
+
+void moxart_gpio_enable(u32 gpio)
+{
+	writel(readl(moxart_pincontrol_base) | gpio, moxart_pincontrol_base);
+}
+
+void moxart_gpio_disable(u32 gpio)
+{
+	writel(readl(moxart_pincontrol_base) & ~gpio, moxart_pincontrol_base);
+}
+
+static int moxart_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+	moxart_gpio_enable(1 << offset);
+	return pinctrl_request_gpio(offset);
+}
+
+static void moxart_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+	pinctrl_free_gpio(offset);
+	moxart_gpio_disable(1 << offset);
+}
+
+static int moxart_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+	void __iomem *ioaddr = moxart_gpio_base + GPIO_PIN_DIRECTION;
+
+	writel(readl(ioaddr) & ~(1 << offset), ioaddr);
+	return 0;
+}
+
+static int moxart_gpio_direction_output(struct gpio_chip *chip,
+					unsigned offset, int value)
+{
+	void __iomem *ioaddr = moxart_gpio_base + GPIO_PIN_DIRECTION;
+
+	writel(readl(ioaddr) | (1 << offset), ioaddr);
+	return 0;
+}
+
+static void moxart_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+	void __iomem *ioaddr = moxart_gpio_base + GPIO_DATA_OUT;
+	u32 reg = readl(ioaddr);
+
+	(value) ?	writel(reg | (1 << offset), ioaddr) :
+			writel(reg & ~(1 << offset), ioaddr);
+}
+
+static int moxart_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+	u32 ret = readl(moxart_gpio_base + GPIO_PIN_DIRECTION);
+
+	if (ret & (1 << offset))
+		ret = readl(moxart_gpio_base + GPIO_DATA_OUT) & (1 << offset);
+	else
+		ret = readl(moxart_gpio_base + GPIO_DATA_IN) & (1 << offset);
+
+	return ret;
+}
+
+static struct gpio_chip moxart_gpio_chip = {
+	.label			= "moxart-gpio",
+	.request		= moxart_gpio_request,
+	.free			= moxart_gpio_free,
+	.direction_input	= moxart_gpio_direction_input,
+	.direction_output	= moxart_gpio_direction_output,
+	.set			= moxart_gpio_set,
+	.get			= moxart_gpio_get,
+	.base			= 0,
+	.ngpio			= 32,
+	.can_sleep		= 0,
+};
+
+static int moxart_gpio_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct resource *res;
+	int ret, gpio_ready_led, gpio_reset_switch;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	moxart_gpio_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_gpio_base)) {
+		dev_err(dev, "%s: devm_ioremap_resource res_gpio failed\n",
+			dev->of_node->full_name);
+		return PTR_ERR(moxart_gpio_base);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	moxart_pincontrol_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(moxart_pincontrol_base)) {
+		dev_err(dev, "%s: devm_ioremap_resource res_pmu failed\n",
+			dev->of_node->full_name);
+		return PTR_ERR(moxart_pincontrol_base);
+	}
+
+	moxart_gpio_chip.dev = dev;
+
+	ret = gpiochip_add(&moxart_gpio_chip);
+	if (ret)
+		dev_err(dev, "%s: gpiochip_add failed\n",
+			dev->of_node->full_name);
+
+
+	gpio_ready_led = of_get_named_gpio(dev->of_node,
+					   "gpio-ready-led", 0);
+	if (!gpio_is_valid(gpio_ready_led)) {
+		dev_err(dev, "invalid gpio (gpio-ready-led): %d\n",
+			gpio_ready_led);
+		return gpio_ready_led;
+	}
+
+	gpio_reset_switch = of_get_named_gpio(dev->of_node,
+					      "gpio-reset-switch", 0);
+	if (!gpio_is_valid(gpio_reset_switch)) {
+		dev_err(dev, "invalid gpio (gpio-reset-switch): %d\n",
+			gpio_reset_switch);
+		return gpio_reset_switch;
+	}
+
+	moxart_gpio_enable(gpio_ready_led | gpio_reset_switch);
+
+	moxart_gpio_direction_input(&moxart_gpio_chip, gpio_reset_switch);
+
+	/*
+	 * gpio_ready_led=0 ready LED on
+	 * gpio_ready_led=1 ready LED off
+	 */
+	moxart_gpio_direction_output(&moxart_gpio_chip, gpio_ready_led, 0);
+	moxart_gpio_set(&moxart_gpio_chip, gpio_ready_led, 0);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_gpio_match[] = {
+	{ .compatible = "moxa,moxart-gpio" },
+	{ }
+};
+
+static struct platform_driver moxart_gpio_driver = {
+	.driver	= {
+		.name		= "moxart-gpio",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_gpio_match,
+	},
+	.probe	= moxart_gpio_probe,
+};
+
+static int __init moxart_gpio_init(void)
+{
+	return platform_driver_register(&moxart_gpio_driver);
+}
+
+postcore_initcall(moxart_gpio_init);
+
+MODULE_DESCRIPTION("MOXART GPIO chip driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
-- 
1.8.2.1



From daniel.lezcano at linaro.org  Mon Jul 29 09:08:52 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 29 Jul 2013 15:08:52 +0200
Subject: [PATCH v6 02/20] clocksource: samsung_pwm_timer: Correct
 definition of AUTORELOAD bit
In-Reply-To: <2416336.ny4L9Sf7Ts@flatron>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
 <1658534.7nG6RFjcTc@flatron> <51EDA3EA.9020502@linaro.org>
 <2416336.ny4L9Sf7Ts@flatron>
Message-ID: <51F66964.1090803@linaro.org>

On 07/24/2013 01:32 AM, Tomasz Figa wrote:
> PWM channel 4 has its autoreload bit located at different position. This
> patch fixes the driver to account for that.
> 
> This fixes a problem with the clocksource hanging after it overflows because
> it is not reloaded any more.
> 
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> ---

Acked-by: Daniel Lezcano <daniel.lezcano at linaro.org>


>  drivers/clocksource/samsung_pwm_timer.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> Changes since v5:
>  - Added more detailed comment about bit layout in TCON register.
> 
> diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
> index 3fa5b07..5d0049f 100644
> --- a/drivers/clocksource/samsung_pwm_timer.c
> +++ b/drivers/clocksource/samsung_pwm_timer.c
> @@ -44,10 +44,21 @@
>  #define TCFG1_SHIFT(x)	  		((x) * 4)
>  #define TCFG1_MUX_MASK	  		0xf
>  
> +/*
> + * Each channel occupies 4 bits in TCON register, but there is a gap of 4
> + * bits (one channel) after channel 0, so channels have different numbering
> + * when accessing TCON register.
> + *
> + * In addition, the location of autoreload bit for channel 4 (TCON channel 5)
> + * in its set of bits is 2 as opposed to 3 for other channels.
> + */
>  #define TCON_START(chan)		(1 << (4 * (chan) + 0))
>  #define TCON_MANUALUPDATE(chan)		(1 << (4 * (chan) + 1))
>  #define TCON_INVERT(chan)		(1 << (4 * (chan) + 2))
> -#define TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
> +#define _TCON_AUTORELOAD(chan)		(1 << (4 * (chan) + 3))
> +#define _TCON_AUTORELOAD4(chan)		(1 << (4 * (chan) + 2))
> +#define TCON_AUTORELOAD(chan)		\
> +	((chan < 5) ? _TCON_AUTORELOAD(chan) : _TCON_AUTORELOAD4(chan))
>  
>  DEFINE_SPINLOCK(samsung_pwm_lock);
>  EXPORT_SYMBOL(samsung_pwm_lock);
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From heiko at sntech.de  Mon Jul 29 09:10:31 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Mon, 29 Jul 2013 15:10:31 +0200
Subject: [PATCH v4 0/6] ARM: rockchip: add smp functionality
Message-ID: <201307291510.31679.heiko@sntech.de>

This series enables the use of the additional cores on Rockchip
Cortex-A9 SoCs.

To achieve this, add the scu, the needed sram and power-management-unit.

Tested on a rk3066a (dual core) by me and on a rk3188 (quad core)
by Ulrich Prinz.

(Note: rk3188 support in general needs additional upcoming patchsets)

changes since v3:
- address comments from Rob Herring:
  - split the gathering of the reserve-data into a separate loop
  - spelling and style fixes
- first patch only included for reference, already part of the
  char-misc git tree

changes since v2:
- rework the sram allocation following the suggestion from Philipp Zabel

changes since v1:
- add reserved block feature for mmio-sram, to not use two logical
  sram nodes
- the sram content is kept intact while the device is running, so
  copying the trampoline is only needed once

Heiko Stuebner (6):
  misc: sram: fix error path in sram_probe
  misc: sram: add ability to mark sram sections as reserved
  ARM: rockchip: add snoop-control-unit
  ARM: rockchip: add sram dt nodes and documentation
  ARM: rockchip: add power-management-unit dt node
  ARM: rockchip: add smp bringup code

 .../devicetree/bindings/arm/rockchip/pmu.txt       |   16 ++
 .../devicetree/bindings/arm/rockchip/smp-sram.txt  |   23 +++
 Documentation/devicetree/bindings/misc/sram.txt    |    8 +
 arch/arm/boot/dts/rk3066a.dtsi                     |   16 ++
 arch/arm/mach-rockchip/Kconfig                     |    1 +
 arch/arm/mach-rockchip/Makefile                    |    1 +
 arch/arm/mach-rockchip/core.h                      |   22 +++
 arch/arm/mach-rockchip/headsmp.S                   |   32 +++
 arch/arm/mach-rockchip/platsmp.c                   |  203 ++++++++++++++++++++
 arch/arm/mach-rockchip/rockchip.c                  |    2 +
 drivers/misc/sram.c                                |  100 +++++++++-
 11 files changed, 417 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.txt
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
 create mode 100644 arch/arm/mach-rockchip/core.h
 create mode 100644 arch/arm/mach-rockchip/headsmp.S
 create mode 100644 arch/arm/mach-rockchip/platsmp.c

-- 
1.7.10.4



From heiko at sntech.de  Mon Jul 29 09:11:20 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Mon, 29 Jul 2013 15:11:20 +0200
Subject: [PATCH v4 1/6] misc: sram: fix error path in sram_probe
In-Reply-To: <201307291510.31679.heiko@sntech.de>
References: <201307291510.31679.heiko@sntech.de>
Message-ID: <201307291511.21067.heiko@sntech.de>

The pool is created thru devm_gen_pool_create, so the call to
gen_pool_destroy is not necessary.
Instead the sram-clock must be turned off again if it exists.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
Acked-by: Philipp Zabel <p.zabel at pengutronix.de>
---
Only included for reference and completeness, as it is already
added to the char-misc git tree.

 drivers/misc/sram.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index d87cc91..afe66571 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -68,7 +68,8 @@ static int sram_probe(struct platform_device *pdev)
 	ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
 				res->start, size, -1);
 	if (ret < 0) {
-		gen_pool_destroy(sram->pool);
+		if (sram->clk)
+			clk_disable_unprepare(sram->clk);
 		return ret;
 	}
 
-- 
1.7.10.4



From heiko at sntech.de  Mon Jul 29 09:12:24 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Mon, 29 Jul 2013 15:12:24 +0200
Subject: [PATCH v4 2/6] misc: sram: add ability to mark sram sections as
 reserved
In-Reply-To: <201307291510.31679.heiko@sntech.de>
References: <201307291510.31679.heiko@sntech.de>
Message-ID: <201307291512.25126.heiko@sntech.de>

Some SoCs need parts of their sram for special purposes. So while being part
of the peripheral, it should not be part of the genpool controlling the sram.

Therefore add an option mmio-sram-reserved to keep arbitrary portions of the
sram from being part of the pool.

Suggested-by: Rob Herring <robherring2 at gmail.com>
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
Philipp: I didn't carry the ack, because the loop changed significantly again.
So if it looks ok, could you re-ack it please?

 Documentation/devicetree/bindings/misc/sram.txt |    8 ++
 drivers/misc/sram.c                             |  101 +++++++++++++++++++++--
 2 files changed, 101 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
index 4d0a00e..3b7a5c1 100644
--- a/Documentation/devicetree/bindings/misc/sram.txt
+++ b/Documentation/devicetree/bindings/misc/sram.txt
@@ -8,9 +8,17 @@ Required properties:
 
 - reg : SRAM iomem address range
 
+Optional properties:
+
+- mmio-sram-reserved: ordered list of reserved chunks inside the sram that
+  should not be used by the OS.
+  Format is <base size>, <base size>, ...; with base being relative to the
+  reg property base.
+
 Example:
 
 sram: sram at 5c000000 {
 	compatible = "mmio-sram";
 	reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
+	mmio-sram-reserved = <0x0 0x100>; /* reserve 0x5c000000-0x5c000100 */
 };
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index afe66571..b3ceefb 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -36,13 +36,23 @@ struct sram_dev {
 	struct clk *clk;
 };
 
+struct sram_reserve {
+	unsigned long start;
+	unsigned long size;
+};
+
 static int sram_probe(struct platform_device *pdev)
 {
 	void __iomem *virt_base;
 	struct sram_dev *sram;
 	struct resource *res;
-	unsigned long size;
-	int ret;
+	unsigned long size, cur_start, cur_size;
+	const __be32 *reserved_list = NULL;
+	int reserved_size = 0;
+	struct sram_reserve *rblocks;
+	unsigned int nblocks;
+	int ret = 0;
+	int i;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	virt_base = devm_ioremap_resource(&pdev->dev, res);
@@ -65,19 +75,94 @@ static int sram_probe(struct platform_device *pdev)
 	if (!sram->pool)
 		return -ENOMEM;
 
-	ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
-				res->start, size, -1);
-	if (ret < 0) {
-		if (sram->clk)
-			clk_disable_unprepare(sram->clk);
-		return ret;
+	if (pdev->dev.of_node) {
+		reserved_list = of_get_property(pdev->dev.of_node,
+						"mmio-sram-reserved",
+						&reserved_size);
+		if (reserved_list) {
+			reserved_size /= sizeof(*reserved_list);
+			if (!reserved_size || reserved_size % 2) {
+				dev_warn(&pdev->dev, "wrong number of arguments in mmio-sram-reserved\n");
+				reserved_list = NULL;
+				reserved_size = 0;
+			}
+		}
 	}
 
+	/*
+	 * We need an additional block to mark the end of the memory region
+	 * after the reserved blocks from the dt are processed.
+	 */
+	nblocks = reserved_size / 2 + 1;
+	rblocks = kmalloc((nblocks) * sizeof(*rblocks), GFP_KERNEL);
+	if (!rblocks) {
+		ret = -ENOMEM;
+		goto err_alloc;
+	}
+
+	for (i = 0; i < nblocks - 1; i++) {
+		rblocks[i].start = be32_to_cpu(*reserved_list++);
+		rblocks[i].size = be32_to_cpu(*reserved_list++);
+
+		dev_dbg(&pdev->dev, "found reserved block 0x%lx-0x%lx\n",
+			rblocks[i].start,
+			rblocks[i].start + rblocks[i].size);
+	}
+
+	/* the last chunk marks the end of the region */
+	rblocks[nblocks - 1].start = size;
+	rblocks[nblocks - 1].size = 0;
+
+	cur_start = 0;
+	for (i = 0; i < nblocks; i++) {
+		/* catch unsorted list entries */
+		if (rblocks[i].start < cur_start) {
+			dev_err(&pdev->dev,
+				"unsorted reserved list (0x%lx before current 0x%lx)\n",
+				rblocks[i].start, cur_start);
+			ret = -EINVAL;
+			goto err_chunks;
+		}
+
+		/* current start is in a reserved block, so continue after it */
+		if (rblocks[i].start == cur_start) {
+			cur_start = rblocks[i].start + rblocks[i].size;
+			continue;
+		}
+
+		/*
+		 * allocate the space between the current starting
+		 * address and the following reserved block, or the
+		 * end of the region.
+		 */
+		cur_size = rblocks[i].start - cur_start;
+
+		dev_dbg(&pdev->dev, "adding chunk 0x%lx-0x%lx\n",
+			cur_start, cur_start + cur_size);
+		ret = gen_pool_add_virt(sram->pool,
+				(unsigned long)virt_base + cur_start,
+				res->start + cur_start, cur_size, -1);
+		if (ret < 0)
+			goto err_chunks;
+
+		/* next allocation after this reserved block */
+		cur_start = rblocks[i].start + rblocks[i].size;
+	}
+
+	kfree(rblocks);
+
 	platform_set_drvdata(pdev, sram);
 
 	dev_dbg(&pdev->dev, "SRAM pool: %ld KiB @ 0x%p\n", size / 1024, virt_base);
 
 	return 0;
+
+err_chunks:
+	kfree(rblocks);
+err_alloc:
+	if (sram->clk)
+		clk_disable_unprepare(sram->clk);
+	return ret;
 }
 
 static int sram_remove(struct platform_device *pdev)
-- 
1.7.10.4



From heiko at sntech.de  Mon Jul 29 09:13:05 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Mon, 29 Jul 2013 15:13:05 +0200
Subject: [PATCH v4 3/6] ARM: rockchip: add snoop-control-unit
In-Reply-To: <201307291510.31679.heiko@sntech.de>
References: <201307291510.31679.heiko@sntech.de>
Message-ID: <201307291513.06072.heiko@sntech.de>

This adds the device-node and config select to enable the
scu in all Rockchip Cortex-A9 SoCs.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
 arch/arm/boot/dts/rk3066a.dtsi |    5 +++++
 arch/arm/mach-rockchip/Kconfig |    1 +
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 56bfac9..26c4311 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -48,6 +48,11 @@
 		compatible = "simple-bus";
 		ranges;
 
+		scu at 1013c000 {
+			compatible = "arm,cortex-a9-scu";
+			reg = <0x1013c000 0x100>;
+		};
+
 		gic: interrupt-controller at 1013d000 {
 			compatible = "arm,cortex-a9-gic";
 			interrupt-controller;
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 25ee12b..0f5484c 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -5,6 +5,7 @@ config ARCH_ROCKCHIP
 	select ARCH_REQUIRE_GPIOLIB
 	select ARM_GIC
 	select CACHE_L2X0
+	select HAVE_ARM_SCU
 	select HAVE_ARM_TWD if LOCAL_TIMERS
 	select HAVE_SMP
 	select LOCAL_TIMERS if SMP
-- 
1.7.10.4



From xvzhaobin at gmail.com  Mon Jul 29 09:12:58 2013
From: xvzhaobin at gmail.com (zhaobin xv)
Date: Mon, 29 Jul 2013 21:12:58 +0800
Subject: ZTEXTADDR
Message-ID: <CANEcUBWQgoEQ2nrzV4F-dbPzQQYW1NqFwGxwGMOBzo3g-aAuug@mail.gmail.com>

hi
   I see some blogs aboot ZTEXTADDR
in linux 2.4.18 :
in kernel/arch/arm/boot/Makefile?
 ifeq ($(CONFIG_ARCH_S3C2410),y)
ZTEXTADDR = 0x30008000
ZRELADDR = 0x30008000
endif
but
in linux 2.6. :
in kernel/arch/arm/boot/Makefile:
ZTEXTADDR = 0


I want to know why to change?
ZTEXTADDR is link addr or phs addr?


From heiko at sntech.de  Mon Jul 29 09:13:50 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Mon, 29 Jul 2013 15:13:50 +0200
Subject: [PATCH v4 4/6] ARM: rockchip: add sram dt nodes and documentation
In-Reply-To: <201307291510.31679.heiko@sntech.de>
References: <201307291510.31679.heiko@sntech.de>
Message-ID: <201307291513.50507.heiko@sntech.de>

The Rockchip SoCs need a special part of their sram for bringup
of additional cores. Therefore also add a reserved section when adding the
mmio-sram node to keep the sram driver from using this space.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
 .../devicetree/bindings/arm/rockchip/smp-sram.txt  |   23 ++++++++++++++++++++
 arch/arm/boot/dts/rk3066a.dtsi                     |    6 +++++
 2 files changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt

diff --git a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt b/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
new file mode 100644
index 0000000..80c878e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
@@ -0,0 +1,23 @@
+Rockchip SRAM for smp bringup:
+------------------------------
+
+Rockchip's smp-capable SoCs use the first part of the sram for the bringup
+of the cores. Once the core gets powered up it executes the code that is
+residing at the very beginning of the sram.
+
+Therefore a reserved section has to be added to the mmio-sram declaration.
+
+Required node properties:
+- compatible : should contain both "rockchip,rk3066-sram", "mmio-sram"
+  so that the smp code can select the correct sram node.
+
+The rest of the properties should follow the generic mmio-sram discription
+found in ../../misc/sram.txt
+
+Example:
+
+	sram: sram at 10080000 {
+		compatible = "rockchip,rk3066-sram", "mmio-sram";
+		reg = <0x10080000 0x10000>;
+		mmio-sram-reserved = <0x0 0x50>;
+	};
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 26c4311..24d1941 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -53,6 +53,12 @@
 			reg = <0x1013c000 0x100>;
 		};
 
+		sram: sram at 10080000 {
+			compatible = "rockchip,rk3066-sram", "mmio-sram";
+			reg = <0x10080000 0x10000>;
+			mmio-sram-reserved = <0x0 0x50>;
+		};
+
 		gic: interrupt-controller at 1013d000 {
 			compatible = "arm,cortex-a9-gic";
 			interrupt-controller;
-- 
1.7.10.4



From robherring2 at gmail.com  Mon Jul 29 09:13:22 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 29 Jul 2013 08:13:22 -0500
Subject: [PATCH 7/7] dts: calxeda: add ARM PSCI binding
In-Reply-To: <20130729102424.GA24255@e106331-lin.cambridge.arm.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
 <1375048598-15637-8-git-send-email-robherring2@gmail.com>
 <20130729102424.GA24255@e106331-lin.cambridge.arm.com>
Message-ID: <51F66A72.7070209@gmail.com>

On 07/29/2013 05:24 AM, Mark Rutland wrote:
> On Sun, Jul 28, 2013 at 10:56:38PM +0100, Rob Herring wrote:
>> From: Rob Herring <rob.herring at calxeda.com>
>>
>> Add the PSCI binding for Calxeda SOCs. The PSCI function numbers are
>> different from the DT binding example because the numbering changed in
>> revisions of the PSCI spec and are already fixed in highbank firmware.
>> Since the numbering is transparent to the kernel, this difference is not
>> significant.
>>
>> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
>> ---
>>  arch/arm/boot/dts/ecx-common.dtsi | 10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/ecx-common.dtsi b/arch/arm/boot/dts/ecx-common.dtsi
>> index e8559b7..f1dfc09 100644
>> --- a/arch/arm/boot/dts/ecx-common.dtsi
>> +++ b/arch/arm/boot/dts/ecx-common.dtsi
>> @@ -19,6 +19,16 @@
>>  		bootargs = "console=ttyAMA0";
>>  	};
>>  
>> +	psci {
>> +		compatible	= "arm,psci";
>> +		method		= "smc";
>> +		cpu_suspend	= <0x84000002>;
>> +		cpu_off		= <0x84000004>;
>> +		cpu_on		= <0x84000006>;
>> +		system_off	= <0x84000100>;
>> +		system_reset	= <0x84000101>;
>> +	};
>> +
> 
> I see this is somewhat beyond the original PSCI, given the addition of
> SYSTEM_OFF and SYSTEM_RESET, but not quite PSCI 0.2 as you don't have
> PSCI_VERSION.

I do actually support PSCI_VERSION. Forgot to add that to the dts.

> It would be nice it the compatible string were more specific here to
> deal with this and any implementation-specific power_state ID values.
> Something like "calxeda,highbank-psci", "arm,psci" ?

Is that something we always want to do? You can't really know the
implementation quirks up front.

Rob



From lorenzo.pieralisi at arm.com  Mon Jul 29 09:13:44 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 29 Jul 2013 14:13:44 +0100
Subject: [PATCH v2 01/22] [HACK] of: dev_node has struct device pointer
In-Reply-To: <20130729.131344.1221933042559369096.hdoyu@nvidia.com>
References: <1373021097-32420-2-git-send-email-hdoyu@nvidia.com>
 <51E5CFBF.5080407@wwwdotorg.org>
 <20130716231629.GA12189@dhcp-172-17-186-34.nvidia.com>
 <20130729.131344.1221933042559369096.hdoyu@nvidia.com>
Message-ID: <20130729131344.GB6184@e102568-lin.cambridge.arm.com>

Hi Hiroshi,

On Mon, Jul 29, 2013 at 11:13:44AM +0100, Hiroshi Doyu wrote:
> Thierry Reding <thierry.reding at gmail.com> wrote @ Wed, 17 Jul 2013 01:16:30 +0200:
> 
> > * PGP Signed by an unknown key
> > 
> > On Tue, Jul 16, 2013 at 04:57:03PM -0600, Stephen Warren wrote:
> > > On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> > > > To prevent of_platform_populate() from trying to populate duplicate
> > > > devices if a device has been already populated.
> > > 
> > > You need to send drivers/of patches to the DT maintainer and
> > > devicetree-discuss mailing list.
> > > 
> > > > Signed-off-by: Hiroshi Doyu <hdoyu at nvidia.com>
> > > > ---
> > > > Need to take care of early_platform_devices, or alternative solution.
> > > 
> > > I assume that's a TODO item... Are you planning on fleshing out this
> > > patch to address that issue?
> >
> > There was some more discussion about it, which can be found in the
> > following thread:
> > 
> > 	https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036934.html
> > 
> > That's one of the last messages and it should have most of the
> > background. If not you may have to walk up the thread for more context.
> > In a nutshell I raised the question as to why we can't simply call
> > of_platform_populate() earlier and side-step all the workarounds that
> > have found their way into the kernel to side-step the issue of their not
> > being a struct device associated with the struct device_node.
> 
> This is the thread which Lorenzo started originally. He may have some
> plan to implement/proceed with this, Lorenzo?

I was trying to raise the issue and apparently I succeeded. For now,
I put in place yet-another-temporary-solution to the problem in one
of the drivers I need for power management, but certainly the problem is
not solved, and I can't allocate time to do it myself unfortunately.

I am more than happy to review patches though.

Thanks,
Lorenzo



From heiko at sntech.de  Mon Jul 29 09:14:27 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Mon, 29 Jul 2013 15:14:27 +0200
Subject: [PATCH v4 5/6] ARM: rockchip: add power-management-unit dt node
In-Reply-To: <201307291510.31679.heiko@sntech.de>
References: <201307291510.31679.heiko@sntech.de>
Message-ID: <201307291514.27779.heiko@sntech.de>

The pmu is needed to bring up the cores during smp operations.
Therefore add a node and documentation for it.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
 Documentation/devicetree/bindings/arm/rockchip/pmu.txt |   16 ++++++++++++++++
 arch/arm/boot/dts/rk3066a.dtsi                         |    5 +++++
 2 files changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.txt

diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.txt b/Documentation/devicetree/bindings/arm/rockchip/pmu.txt
new file mode 100644
index 0000000..3ee9b42
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.txt
@@ -0,0 +1,16 @@
+Rockchip power-management-unit:
+-------------------------------
+
+The pmu is used to turn off and on different power domains of the SoCs
+This includes the power to the CPU cores.
+
+Required node properties:
+- compatible value : = "rockchip,rk3066-pmu";
+- reg : physical base address and the size of the registers window
+
+Example:
+
+	pmu at 20004000 {
+		compatible = "rockchip,rk3066-pmu";
+		reg = <0x20004000 0x100>;
+	};
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 24d1941..43ac7c8 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -59,6 +59,11 @@
 			mmio-sram-reserved = <0x0 0x50>;
 		};
 
+		pmu at 20004000 {
+			compatible = "rockchip,rk3066-pmu";
+			reg = <0x20004000 0x100>;
+		};
+
 		gic: interrupt-controller at 1013d000 {
 			compatible = "arm,cortex-a9-gic";
 			interrupt-controller;
-- 
1.7.10.4



From heiko at sntech.de  Mon Jul 29 09:15:19 2013
From: heiko at sntech.de (Heiko =?utf-8?q?St=C3=BCbner?=)
Date: Mon, 29 Jul 2013 15:15:19 +0200
Subject: [PATCH v4 6/6] ARM: rockchip: add smp bringup code
In-Reply-To: <201307291510.31679.heiko@sntech.de>
References: <201307291510.31679.heiko@sntech.de>
Message-ID: <201307291515.20138.heiko@sntech.de>

This adds the necessary smp-operations and startup code to use
additional cores on Rockchip SoCs.

We currently hog the power management unit in the smp code, as it is
necessary to control the power to the cpu core and nothing else is
currently using it, so a generic implementation can be done later.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
---
 arch/arm/mach-rockchip/Makefile   |    1 +
 arch/arm/mach-rockchip/core.h     |   22 ++++
 arch/arm/mach-rockchip/headsmp.S  |   32 ++++++
 arch/arm/mach-rockchip/platsmp.c  |  203 +++++++++++++++++++++++++++++++++++++
 arch/arm/mach-rockchip/rockchip.c |    2 +
 5 files changed, 260 insertions(+)
 create mode 100644 arch/arm/mach-rockchip/core.h
 create mode 100644 arch/arm/mach-rockchip/headsmp.S
 create mode 100644 arch/arm/mach-rockchip/platsmp.c

diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 1547d4f..4377a14 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip.o
+obj-$(CONFIG_SMP) += headsmp.o platsmp.o
diff --git a/arch/arm/mach-rockchip/core.h b/arch/arm/mach-rockchip/core.h
new file mode 100644
index 0000000..e2e7c9d
--- /dev/null
+++ b/arch/arm/mach-rockchip/core.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (c) 2013 MundoReader S.L.
+ * Author: Heiko Stuebner <heiko at sntech.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ */
+
+extern char rockchip_secondary_trampoline;
+extern char rockchip_secondary_trampoline_end;
+
+extern unsigned long rockchip_boot_fn;
+extern void rockchip_secondary_startup(void);
+
+extern struct smp_operations rockchip_smp_ops;
diff --git a/arch/arm/mach-rockchip/headsmp.S b/arch/arm/mach-rockchip/headsmp.S
new file mode 100644
index 0000000..3dd72f7
--- /dev/null
+++ b/arch/arm/mach-rockchip/headsmp.S
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2013 MundoReader S.L.
+ * Author: Heiko Stuebner <heiko at sntech.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ */
+#include <linux/linkage.h>
+#include <linux/init.h>
+
+	__CPUINIT
+
+ENTRY(rockchip_secondary_startup)
+	bl	v7_invalidate_l1
+	b	secondary_startup
+ENDPROC(rockchip_secondary_startup)
+
+ENTRY(rockchip_secondary_trampoline)
+	ldr	pc, 1f
+ENDPROC(rockchip_secondary_trampoline)
+	.globl	rockchip_boot_fn
+rockchip_boot_fn:
+1:	.space	4
+
+ENTRY(rockchip_secondary_trampoline_end)
diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c
new file mode 100644
index 0000000..7849c39
--- /dev/null
+++ b/arch/arm/mach-rockchip/platsmp.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (c) 2013 MundoReader S.L.
+ * Author: Heiko Stuebner <heiko at sntech.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This 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.
+ */
+
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/smp.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+#include <asm/cacheflush.h>
+#include <asm/smp_scu.h>
+#include <asm/smp_plat.h>
+#include <asm/mach/map.h>
+
+#include "core.h"
+
+static void __iomem *scu_base_addr;
+static void __iomem *sram_base_addr;
+static int ncores;
+
+/*
+ * temporary PMU handling
+ */
+
+#define PMU_PWRDN_CON		0x08
+#define PMU_PWRDN_ST		0x0c
+
+static void __iomem *pmu_base_addr;
+
+static inline bool pmu_power_domain_is_on(int pd)
+{
+	return !(readl_relaxed(pmu_base_addr + PMU_PWRDN_ST) & BIT(pd));
+}
+
+static void pmu_set_power_domain(int pd, bool on)
+{
+	u32 val = readl_relaxed(pmu_base_addr + PMU_PWRDN_CON);
+	if (on)
+		val &= ~BIT(pd);
+	else
+		val |=  BIT(pd);
+	writel(val, pmu_base_addr + PMU_PWRDN_CON);
+
+	while (pmu_power_domain_is_on(pd) != on) { }
+}
+
+/*
+ * Handling of CPU cores
+ */
+
+static int __cpuinit rockchip_boot_secondary(unsigned int cpu,
+					     struct task_struct *idle)
+{
+	if (!sram_base_addr || !pmu_base_addr) {
+		pr_err("%s: sram or pmu missing for cpu boot\n", __func__);
+		return -ENXIO;
+	}
+
+	if (cpu >= ncores) {
+		pr_err("%s: cpu %d outside maximum number of cpus %d\n",
+							__func__, cpu, ncores);
+		return -ENXIO;
+	}
+
+	/* start the core */
+	pmu_set_power_domain(0 + cpu, true);
+
+	return 0;
+}
+
+/**
+ * rockchip_smp_prepare_sram - populate necessary sram block
+ * Starting cores execute the code residing at the start of the on-chip sram
+ * after power-on. Therefore make sure, this sram region is reserved and
+ * big enough. After this check, copy the trampoline code that directs the
+ * core to the real startup code in ram into the sram-region.
+ * @node: mmio-sram device node
+ */
+static int __init rockchip_smp_prepare_sram(struct device_node *node)
+{
+	unsigned int trampoline_sz = &rockchip_secondary_trampoline_end -
+					    &rockchip_secondary_trampoline;
+	const __be32 *reserved_list = NULL;
+	int reserved_size;
+	int rstart = -1;
+	unsigned int rsize;
+	unsigned int i;
+
+	reserved_list = of_get_property(node, "mmio-sram-reserved",
+					&reserved_size);
+	if (!reserved_list) {
+		pr_err("%s: wrong number of arguments in mmio-sram-reserved\n",
+		       __func__);
+		return -ENOENT;
+	}
+
+	reserved_size /= sizeof(*reserved_list);
+	if (!reserved_size || reserved_size % 2) {
+		pr_err("%s: wrong number of arguments in mmio-sram-reserved\n",
+		       __func__);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < reserved_size; i += 2) {
+		/* get the next reserved block */
+		rstart = be32_to_cpu(*reserved_list++);
+		rsize = be32_to_cpu(*reserved_list++);
+
+		if (!rstart)
+			break;
+	}
+
+	if (rstart) {
+		pr_err("%s: start of sram is not reserved from mmio-sram\n",
+		       __func__);
+		return -EINVAL;
+	}
+
+	if (rsize < trampoline_sz) {
+		pr_err("%s: reserved block with size 0x%x is to small for trampoline size 0x%x\n",
+		       __func__, rsize, trampoline_sz);
+		return -EINVAL;
+	}
+
+	sram_base_addr = of_iomap(node, 0);
+
+	/* set the boot function for the sram code */
+	rockchip_boot_fn = virt_to_phys(rockchip_secondary_startup);
+
+	/* copy the trampoline to sram, that runs during startup of the core */
+	memcpy(sram_base_addr, &rockchip_secondary_trampoline, trampoline_sz);
+	flush_cache_all();
+	outer_clean_range(0, trampoline_sz);
+
+	dsb_sev();
+
+	return 0;
+}
+
+static void __init rockchip_smp_prepare_cpus(unsigned int max_cpus)
+{
+	struct device_node *node;
+	unsigned int i;
+
+	node = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
+	if (!node) {
+		pr_err("%s: missing scu\n", __func__);
+		return;
+	}
+
+	scu_base_addr = of_iomap(node, 0);
+	if (!scu_base_addr) {
+		pr_err("%s: could not map scu registers\n", __func__);
+		return;
+	}
+
+	node = of_find_compatible_node(NULL, NULL, "rockchip,rk3066-sram");
+	if (!node) {
+		pr_err("%s: could not find sram dt node\n", __func__);
+		return;
+	}
+
+	if (rockchip_smp_prepare_sram(node))
+		return;
+
+	node = of_find_compatible_node(NULL, NULL, "rockchip,rk3066-pmu");
+	if (!node) {
+		pr_err("%s: could not find sram dt node\n", __func__);
+		return;
+	}
+
+	pmu_base_addr = of_iomap(node, 0);
+
+	/*
+	 * While the number of cpus is gathered from dt, also get the number
+	 * of cores from the scu to verify this value when booting the cores.
+	 */
+	ncores = scu_get_core_count(scu_base_addr);
+
+	scu_enable(scu_base_addr);
+
+	/* Make sure that all cores except the first are really off */
+	for (i = 1; i < ncores; i++)
+		pmu_set_power_domain(0 + i, false);
+}
+
+struct smp_operations rockchip_smp_ops __initdata = {
+	.smp_prepare_cpus	= rockchip_smp_prepare_cpus,
+	.smp_boot_secondary	= rockchip_boot_secondary,
+};
diff --git a/arch/arm/mach-rockchip/rockchip.c b/arch/arm/mach-rockchip/rockchip.c
index 724d2d8..a0c1f19 100644
--- a/arch/arm/mach-rockchip/rockchip.c
+++ b/arch/arm/mach-rockchip/rockchip.c
@@ -24,6 +24,7 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <asm/hardware/cache-l2x0.h>
+#include "core.h"
 
 static void __init rockchip_timer_init(void)
 {
@@ -46,6 +47,7 @@ static const char * const rockchip_board_dt_compat[] = {
 };
 
 DT_MACHINE_START(ROCKCHIP_DT, "Rockchip Cortex-A9 (Device Tree)")
+	.smp		= smp_ops(rockchip_smp_ops),
 	.init_machine	= rockchip_dt_init,
 	.init_time	= rockchip_timer_init,
 	.dt_compat	= rockchip_board_dt_compat,
-- 
1.7.10.4



From nm at ti.com  Mon Jul 29 09:17:25 2013
From: nm at ti.com (Nishanth Menon)
Date: Mon, 29 Jul 2013 08:17:25 -0500
Subject: [PATCH 0/9] ARM: dts: omap5-uevm: fixup wrong regulator
 configuration
In-Reply-To: <51F63C74.6070503@ti.com>
References: <1374079538-19548-1-git-send-email-nm@ti.com>
 <51F63C74.6070503@ti.com>
Message-ID: <51F66B65.4030702@ti.com>

On 07/29/2013 04:57 AM, Keerthy wrote:
> Hi Nishanth,
>
> On Wednesday 17 July 2013 10:15 PM, Nishanth Menon wrote:
>> Due to wrong older revision of documentation used as reference, we
>> seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
>> series is based power tree on production board 750-2628-XXX platform.
>> Unfortunately, the wrong voltages may be detrimental to OMAP5 as they
>> supply hardware blocks at voltages that are out of specification.
>
> This series looks good to me.
>
> Acked-by:  J Keerthy <j-keerthy at ti.com>

Tony, Benoit - this series could prevent OMAP5 from being damaged on 
uEVMs with current 3.11 rc - could you suggest what we need to do to get 
it in?


-- 
Regards,
Nishanth Menon


From matt.porter at linaro.org  Mon Jul 29 09:20:30 2013
From: matt.porter at linaro.org (Matt Porter)
Date: Mon, 29 Jul 2013 09:20:30 -0400
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <20130729093000.GI3528@e106331-lin.cambridge.arm.com>
References: <2043662.BcW19XTTMG@lenovo> <20130719020611.GA4941@glitch>
 <20130723185733.GB6811@ohporter.com>
 <CAGVrzcYnoN9NnJGvubS7=bVJDk37xSt4BimtvDWghe7OHEWALQ@mail.gmail.com>
 <20130724231106.GB29801@glitch>
 <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
 <20130726000412.GH5022@linaro.org> <51F2F554.8030709@broadcom.com>
 <51F2F885.2040002@wwwdotorg.org>
 <20130729093000.GI3528@e106331-lin.cambridge.arm.com>
Message-ID: <20130729132029.GI5022@ohporter.com>

On Mon, Jul 29, 2013 at 10:30:00AM +0100, Mark Rutland wrote:
> On Fri, Jul 26, 2013 at 11:30:29PM +0100, Stephen Warren wrote:
> > I'm CC'ing in the DT bindings maintainers in case they have any comment.
> > 
> > On 07/26/2013 04:16 PM, Christian Daudt wrote:
> > > On 13-07-25 05:04 PM, Matt Porter wrote:
> > >> On Thu, Jul 25, 2013 at 11:23:21PM +0100, Florian Fainelli wrote:
> > >>> 2013/7/25 Domenico Andreoli <cavokz at gmail.com>:
> > >>>> On Tue, Jul 23, 2013 at 08:05:28PM +0100, Florian Fainelli wrote:
> > >>>>> 2013/7/23 Matt Porter <matt.porter at linaro.org>:
> > >>>>>> On Fri, Jul 19, 2013 at 04:06:11AM +0200, Domenico Andreoli wrote:
> > >>>>>> It's pretty easy to see that the "ti" vendor prefix has no
> > >>>>>> relation at
> > >>>>>> all to their TXN symbol so that blows that convention out of the
> > >>>>>> water.
> > >>>>>> Rather, the prefix is based on somebody's notion of how that vendor's
> > >>>>>> part are normally referred to. In TI-land, it's TI AM335x or TI OMAP,
> > >>>>>> never TXN OMAP. :)
> > >>>>>>
> > >>>>>> For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.
> > >>>>> It was appropriate before being the "wrong" vendor prefix was
> > >>>>> allocated, now that "brcm" has been allocated we should stick to it
> > >>>>> because otherwise we will break existing and on-going DT work.
> > >>>> I still prefer bcm to brcm and I find enough evidence that bcm would be
> > >>>> better in the long term.
> > >>>>
> > >>>> So if Broadcomers can agree on bcm, now it's still the cheapest time to
> > >>>> fix in that direction, later will not be better.
> > >>> If we are to fix it in stone, once and for all, let's go for the full
> > >>> name
> > >>> which would avoid any kind of future confusion (this also seems to be
> > >>> the
> > >>> tendency with new vendor prefixes these days). That way we could make
> > >>> everyone happy with say: "broadcom,bcm2835". Would that work for
> > >>> everyone?
> > >> I really like that.
> > >>
> > >> -Matt
> > >>
> > > broadcom works for me also.
> > >  thanks,
> > >    csd
> > 
> > I have no strong objection at this point in principle to renaming the
> > vendor prefix used by the RPi support, although it will cause a bunch of
> > pointless churn in the drivers to match the new compatible values,  and
> > in the pinctrl bindings for the custom properties there...
> > 
> 
> I'd be happy to have "broadcom" for all *new* bindings, as it's already
> in some bindings alongside "bcm" and "brcm", and is certainly the
> clearest of the available options.
> 
> However, given the strong feelings of many against breaking existing
> dts, we need to support the existing instances of "bcm" and "brcm" in

Whoa, how would existing dts break? At this instant in time, all the
bindings and dts are still in the kernel tree. A series to address this
make all bindings, drivers, and dts consistent in one shot.

> bindings. This doesn't preclude us also supporting "broadcom,$DEVICE"
> alongside the existing "bcm,$DEVICE" and/or "brcm,$DEVICE" for those
> that have a strong desire for consistency in future dts, unless there's
> a feeling that creates too much churn.

As it stands now, "bcm" is 100% unacceptable. It is not captured in
vendor-prefixes.txt and thus all the drivers/dts using it should have
been rejected. It *has* to be fixed by either 1) adding the additional
prefix to vendor-prefixes.txt 2) changing it to the registered prefix
"brcm" 3) changing to another unified prefix
 
> In the end, this is a purely cosmetic change, so we can live with it
> as-is at the cost of another entry in an FAQ somewhere.
 
The only argument I have against this is that DT bindings that went
upstream in the last 6 months or more really should be considered more of
staging quality. They've had little oversight as has been illuminated in
recent events leading to the maintainership change. Since mistakes were
made in keeping to the vision of bindings being specification quality
and set in stone, it makes little sense to me to create this spec filled
with multiple legacy names. Especially at a point where the binding
maintainership and process is just starting to mature.

With that said, we can fix the current broken state of the "bcm"
bindings with a one line patch to vendor-prefixes.txt. If avoiding
churn is the highest priority I'd be happy to do that and just
end this discussion.

-Matt


From thomas.petazzoni at free-electrons.com  Mon Jul 29 09:21:26 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 29 Jul 2013 15:21:26 +0200
Subject: [PATCHv2 0/2] net: mvneta: big endian support
Message-ID: <1375104088-24654-1-git-send-email-thomas.petazzoni@free-electrons.com>

David,

You'll find in this patch series two small patches that add support
for big-endian in the mvneta driver, for the network interface found
in ARM Marvell Armada 370 and Armada XP SOCs. They are based on
3.11-rc3.

Changes since v1:
 * Rebased on top of 3.11-rc2.
 * Version sent once net-next is opened.

Thanks,

Thomas

Thomas Petazzoni (2):
  net: mvneta: move the RX and TX desc macros outside of the structs
  net: mvneta: support big endian

 drivers/net/ethernet/marvell/mvneta.c | 61 +++++++++++++++++++++++++++--------
 1 file changed, 47 insertions(+), 14 deletions(-)

-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 29 09:21:27 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 29 Jul 2013 15:21:27 +0200
Subject: [PATCHv2 1/2] net: mvneta: move the RX and TX desc macros outside of
 the structs
In-Reply-To: <1375104088-24654-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1375104088-24654-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1375104088-24654-2-git-send-email-thomas.petazzoni@free-electrons.com>

The macros used for the various fields of the RX and TX descriptions
are currently declared next to those fields within the structure
definitions of the RX and TX descriptors.

However, in order to support big endian, we'll have to use the "swap
descriptors" features of the hardware, which swaps every byte within
each 64 bits word of the descriptors. This requires a separate
definition of the RX and TX descriptor structures for little and big
endian, as is done in the mv643xx_eth. Those macros can therefore no
longer be defined inside those structures.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 26 +++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 712779f..649162e 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -262,8 +262,7 @@ struct mvneta_port {
  * layout of the transmit and reception DMA descriptors, and their
  * layout is therefore defined by the hardware design
  */
-struct mvneta_tx_desc {
-	u32  command;		/* Options used by HW for packet transmitting.*/
+
 #define MVNETA_TX_L3_OFF_SHIFT	0
 #define MVNETA_TX_IP_HLEN_SHIFT	8
 #define MVNETA_TX_L4_UDP	BIT(16)
@@ -278,15 +277,6 @@ struct mvneta_tx_desc {
 #define MVNETA_TX_L4_CSUM_FULL	BIT(30)
 #define MVNETA_TX_L4_CSUM_NOT	BIT(31)
 
-	u16  reserverd1;	/* csum_l4 (for future use)		*/
-	u16  data_size;		/* Data size of transmitted packet in bytes */
-	u32  buf_phys_addr;	/* Physical addr of transmitted buffer	*/
-	u32  reserved2;		/* hw_cmd - (for future use, PMT)	*/
-	u32  reserved3[4];	/* Reserved - (for future use)		*/
-};
-
-struct mvneta_rx_desc {
-	u32  status;		/* Info about received packet		*/
 #define MVNETA_RXD_ERR_CRC		0x0
 #define MVNETA_RXD_ERR_SUMMARY		BIT(16)
 #define MVNETA_RXD_ERR_OVERRUN		BIT(17)
@@ -297,13 +287,27 @@ struct mvneta_rx_desc {
 #define MVNETA_RXD_FIRST_LAST_DESC	(BIT(26) | BIT(27))
 #define MVNETA_RXD_L4_CSUM_OK		BIT(30)
 
+struct mvneta_tx_desc {
+	u32  command;		/* Options used by HW for packet transmitting.*/
+	u16  reserverd1;	/* csum_l4 (for future use)		*/
+	u16  data_size;		/* Data size of transmitted packet in bytes */
+	u32  buf_phys_addr;	/* Physical addr of transmitted buffer	*/
+	u32  reserved2;		/* hw_cmd - (for future use, PMT)	*/
+	u32  reserved3[4];	/* Reserved - (for future use)		*/
+};
+
+struct mvneta_rx_desc {
+	u32  status;		/* Info about received packet		*/
 	u16  reserved1;		/* pnc_info - (for future use, PnC)	*/
 	u16  data_size;		/* Size of received packet in bytes	*/
+
 	u32  buf_phys_addr;	/* Physical address of the buffer	*/
 	u32  reserved2;		/* pnc_flow_id  (for future use, PnC)	*/
+
 	u32  buf_cookie;	/* cookie for access to RX buffer in rx path */
 	u16  reserved3;		/* prefetch_cmd, for future use		*/
 	u16  reserved4;		/* csum_l4 - (for future use, PnC)	*/
+
 	u32  reserved5;		/* pnc_extra PnC (for future use, PnC)	*/
 	u32  reserved6;		/* hw_cmd (for future use, PnC and HWF)	*/
 };
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 29 09:21:28 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 29 Jul 2013 15:21:28 +0200
Subject: [PATCHv2 2/2] net: mvneta: support big endian
In-Reply-To: <1375104088-24654-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1375104088-24654-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1375104088-24654-3-git-send-email-thomas.petazzoni@free-electrons.com>

Use the "swap descriptor" feature of the hardware to properly swap the
descriptors when running in big endian mode. Since the swapping occurs
on 64 bits words, we also need to provide a separate structure layout
for the DMA descriptors between little endian and big endian mode,
like is done in the mv643xx_eth driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 35 ++++++++++++++++++++++++++++++++---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 649162e..9647976 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -79,10 +79,10 @@
 #define MVNETA_MAC_ADDR_HIGH                     0x2418
 #define MVNETA_SDMA_CONFIG                       0x241c
 #define      MVNETA_SDMA_BRST_SIZE_16            4
-#define      MVNETA_NO_DESC_SWAP                 0x0
 #define      MVNETA_RX_BRST_SZ_MASK(burst)       ((burst) << 1)
 #define      MVNETA_RX_NO_DATA_SWAP              BIT(4)
 #define      MVNETA_TX_NO_DATA_SWAP              BIT(5)
+#define      MVNETA_DESC_SWAP                    BIT(6)
 #define      MVNETA_TX_BRST_SZ_MASK(burst)       ((burst) << 22)
 #define MVNETA_PORT_STATUS                       0x2444
 #define      MVNETA_TX_IN_PRGRS                  BIT(1)
@@ -287,6 +287,7 @@ struct mvneta_port {
 #define MVNETA_RXD_FIRST_LAST_DESC	(BIT(26) | BIT(27))
 #define MVNETA_RXD_L4_CSUM_OK		BIT(30)
 
+#if defined(__LITTLE_ENDIAN)
 struct mvneta_tx_desc {
 	u32  command;		/* Options used by HW for packet transmitting.*/
 	u16  reserverd1;	/* csum_l4 (for future use)		*/
@@ -311,6 +312,32 @@ struct mvneta_rx_desc {
 	u32  reserved5;		/* pnc_extra PnC (for future use, PnC)	*/
 	u32  reserved6;		/* hw_cmd (for future use, PnC and HWF)	*/
 };
+#else
+struct mvneta_tx_desc {
+	u16  data_size;		/* Data size of transmitted packet in bytes */
+	u16  reserverd1;	/* csum_l4 (for future use)		*/
+	u32  command;		/* Options used by HW for packet transmitting.*/
+	u32  reserved2;		/* hw_cmd - (for future use, PMT)	*/
+	u32  buf_phys_addr;	/* Physical addr of transmitted buffer	*/
+	u32  reserved3[4];	/* Reserved - (for future use)		*/
+};
+
+struct mvneta_rx_desc {
+	u16  data_size;		/* Size of received packet in bytes	*/
+	u16  reserved1;		/* pnc_info - (for future use, PnC)	*/
+	u32  status;		/* Info about received packet		*/
+
+	u32  reserved2;		/* pnc_flow_id  (for future use, PnC)	*/
+	u32  buf_phys_addr;	/* Physical address of the buffer	*/
+
+	u16  reserved4;		/* csum_l4 - (for future use, PnC)	*/
+	u16  reserved3;		/* prefetch_cmd, for future use		*/
+	u32  buf_cookie;	/* cookie for access to RX buffer in rx path */
+
+	u32  reserved5;		/* pnc_extra PnC (for future use, PnC)	*/
+	u32  reserved6;		/* hw_cmd (for future use, PnC and HWF)	*/
+};
+#endif
 
 struct mvneta_tx_queue {
 	/* Number of this TX queue, in the range 0-7 */
@@ -908,9 +935,11 @@ static void mvneta_defaults_set(struct mvneta_port *pp)
 	/* Default burst size */
 	val |= MVNETA_TX_BRST_SZ_MASK(MVNETA_SDMA_BRST_SIZE_16);
 	val |= MVNETA_RX_BRST_SZ_MASK(MVNETA_SDMA_BRST_SIZE_16);
+	val |= MVNETA_RX_NO_DATA_SWAP | MVNETA_TX_NO_DATA_SWAP;
 
-	val |= (MVNETA_RX_NO_DATA_SWAP | MVNETA_TX_NO_DATA_SWAP |
-		MVNETA_NO_DESC_SWAP);
+#if defined(__BIG_ENDIAN)
+	val |= MVNETA_DESC_SWAP;
+#endif
 
 	/* Assign port SDMA configuration */
 	mvreg_write(pp, MVNETA_SDMA_CONFIG, val);
-- 
1.8.1.2



From linux at arm.linux.org.uk  Mon Jul 29 09:26:24 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 29 Jul 2013 14:26:24 +0100
Subject: ZTEXTADDR
In-Reply-To: <CANEcUBWQgoEQ2nrzV4F-dbPzQQYW1NqFwGxwGMOBzo3g-aAuug@mail.gmail.com>
References: <CANEcUBWQgoEQ2nrzV4F-dbPzQQYW1NqFwGxwGMOBzo3g-aAuug@mail.gmail.com>
Message-ID: <20130729132624.GJ24642@n2100.arm.linux.org.uk>

On Mon, Jul 29, 2013 at 09:12:58PM +0800, zhaobin xv wrote:
> hi
>    I see some blogs aboot ZTEXTADDR
> in linux 2.4.18 :
> in kernel/arch/arm/boot/Makefile?
>  ifeq ($(CONFIG_ARCH_S3C2410),y)
> ZTEXTADDR = 0x30008000
> ZRELADDR = 0x30008000
> endif
> but
> in linux 2.6. :
> in kernel/arch/arm/boot/Makefile:
> ZTEXTADDR = 0
> 
> 
> I want to know why to change?
> ZTEXTADDR is link addr or phs addr?

ZTEXTADDR is mostly irrelevant now for everyone who places the kernel
image in RAM, because the entire thing is position independent.


From thomas.petazzoni at free-electrons.com  Mon Jul 29 09:26:37 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 29 Jul 2013 15:26:37 +0200
Subject: [repost] ARM big-endian support
In-Reply-To: <51EFFB53.5060003@codethink.co.uk>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <51EFFB53.5060003@codethink.co.uk>
Message-ID: <20130729152637.204c2622@skate>

Dear Ben Dooks,

On Wed, 24 Jul 2013 17:05:39 +0100, Ben Dooks wrote:
> On 24/07/13 11:27, Ben Dooks wrote:
> > A repost (as requested) of the current big-endian core work for review.
> 
> New branches at git.baserock.org/delta/linux.git
> 	311/be/atags-v4
>   	311/be/core-v4

Thanks. Can you post a patch set based on top of 3.11-rc, so that it
can hopefully be merged? Posting something based on 3.10 has no chance
of being merged. Again, if you need any help on this, do not hesitate
to ask.

Also, would it be possible to get cover letters that include a proper
changelog, as well as version number for each posting of the patch
series?

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From santosh.shilimkar at ti.com  Mon Jul 29 09:26:44 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 29 Jul 2013 09:26:44 -0400
Subject: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes
In-Reply-To: <20130729111503.GG24642@n2100.arm.linux.org.uk>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
 <20130726151021.GU24642@n2100.arm.linux.org.uk> <51F2A3AA.4060801@ti.com>
 <20130729111503.GG24642@n2100.arm.linux.org.uk>
Message-ID: <51F66D94.9060706@ti.com>

On Monday 29 July 2013 07:15 AM, Russell King - ARM Linux wrote:
> On Fri, Jul 26, 2013 at 12:28:26PM -0400, Santosh Shilimkar wrote:
>> On Friday 26 July 2013 11:10 AM, Russell King - ARM Linux wrote:
>>> On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
>>>> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
>>>> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
>>>> PFNs but that breaks the dma_mask for few block layer drivers since
>>>> ARM start of physical memory is not PFN0 unlike most of the architectures.
>>>> Some more read on it is here:
>>>> 	http://lwn.net/Articles/543408/
>>>> 	http://lwn.net/Articles/543424/
>>>>
>>>> To address this issue, we introduce generic dma_max_pfn() helper which
>>>> can be overridden from the architectures.
>>>> 	
>>>> Another intention behind move to nobootmem is also to convert ARM to
>>>> switch to memblock and getting rid of bootmem allocator dependency which
>>>> don't work for LPAE machines which has physical memory starting beyond
>>>> 4 GB boundary. It needs changes to core kernel and also a new memblock
>>>> API. More on this can be found here:
>>>> 	https://lkml.org/lkml/2013/6/29/77
>>>>
>>>> I have been trying to cook up these patches with kind help from Russell
>>>> and we know series don't solve all the dma_mask bad assumptions. But at
>>>> least I am hoping that it can get the ball rolling.	
>>>>
>>>> Comments/testing help is welcome !!
>>>
>>> As this is related to some of the cleanup of dma_mask which I've been
>>> doing, I think it may make sense to roll this into one tree.  Any
>>> objection to that?
>>>
>>> Can we get any acks on this stuff from Jens and Jejb etc - especially
>>> for the bits which touch block/ and for the scsi bits as these are
>>> touching other subsystems.  (oddly, linux-scsi wasn't on the original
>>> mail for this series summary.)
>>>
>> Sorry I missed the scsi lists on the summary patch.
>>
>> While browsing the code I found another spot in mmc layer which
>> needs fixing. The patch is at the end of the email with Chris
>> and linux-mmc cc'ed here.
> 
> Would you mind putting them all in the patch system, I can add the acks
> should anyone supply them later, and I'll repost them along with my set
> of dma-mask patches.  Thanks.
> 
Done.
7794/1, 7795/1, 7796/1, 7797/1, 7798/1, 7799/1

Didn't know how to get XXXX/1,2,3,4... pushed into the tracker.
BTW, I have also pushed the patched on my git tree branch [1] just
in case you or some one needs it.

Regards,
Santosh
[1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
3.12/nobootmem_n_dma-mask



From joelf at ti.com  Mon Jul 29 09:29:51 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 29 Jul 2013 08:29:51 -0500
Subject: [PATCH 5/9] dma: edma: Leave linked to Null slot instead of DUMMY slot
In-Reply-To: <1375104595-16018-1-git-send-email-joelf@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
Message-ID: <1375104595-16018-6-git-send-email-joelf@ti.com>

Dummy slot has been used as a way for missed-events not to be
reported as missing. This has been particularly troublesome for cases
where we might want to temporarily pause all incoming events.

For EDMA DMAC, there is no way to do any such pausing of events as
the occurence of the "next" event is not software controlled.
Using "edma_pause" in IRQ handlers doesn't help as by then the event
in concern from the slave is already missed.

Linking a dummy slot, is seen to absorb these events which we didn't
want to miss. So we don't link to dummy, but instead leave it linked
to NULL set, allow an error condition and detect the channel that
missed it.

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
 drivers/dma/edma.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index aa4989f..1eda5cc 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -159,9 +159,6 @@ static void edma_execute(struct edma_chan *echan)
 		/* Link to the previous slot if not the last set */
 		if (i != (total_process - 1))
 			edma_link(echan->slot[i], echan->slot[i+1]);
-		/* Final pset links to the dummy pset */
-		else
-			edma_link(echan->slot[i], echan->ecc->dummy_slot);
 	}
 
 	edesc->total_processed += total_process;
-- 
1.7.9.5



From joelf at ti.com  Mon Jul 29 09:29:46 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 29 Jul 2013 08:29:46 -0500
Subject: [PATCH 0/9] dma: edma: Support scatter-lists of any length
Message-ID: <1375104595-16018-1-git-send-email-joelf@ti.com>

The following series adds support to EDMA driver to enable DMA of
scatter-gather lists of arbitrary length, but still make use of only
a certain MAX number of slots at a time for a given channel. Thus
free-ing up the rest of the slots to other slaves/channels.  With this
there is no need for slave drivers to query the EDMA driver about how
much is the MAX it can send at a time as done in [1]. Drivers can send
SG lists of any number of entries to DMA. Reference discussion at [2].

Tested omap-aes and omap_hsmmc drivers with different MAX number of slots,
even just 1. In the case where it is 1, only 1-slot is used to DMA an
entire scatter list of arbitrary length.
Since this series touches EDMA private API code also shared with davinci-pcm,
playback of a 16-bit 44.1KHz audio file with davinci-pcm has been tested.

Sample test run with 1 vs 16 (MAX number of slots/SG) in omap-aes driver:
MAX slots = 1:
 (128 bit key, 8192 byte blocks): 1266 operations in 1 seconds (10371072 bytes)
MAX slots = 16:
 (128 bit key, 8192 byte blocks): 1601 operations in 1 seconds (13115392 bytes)

Note: For the above test, 8K buffer is mapped into SG list of size 2 so
only 2 slots are required. So beyond size 2, there will not be any noticeable
performance improvement. But using 1 slot is even managed by just DMA'ing 1 SG
entry at a time.

[1] https://lkml.org/lkml/2013/7/18/432
[2] http://marc.info/?l=linux-omap&m=137416733628831&w=2

Joel Fernandes (9):
  dma: edma: Setup parameters to DMA MAX_NR_SG at a time
  dma: edma: Write out and handle MAX_NR_SG at a given time
  ARM: edma: Add function to manually trigger an EDMA channel
  dma: edma: Find missed events and issue them
  dma: edma: Leave linked to Null slot instead of DUMMY slot
  dma: edma: Detect null slot errors and handle them correctly
  ARM: edma: Don't clear EMR of channel in edma_stop
  dma: edma: Link to dummy slot only for last SG list split
  dma: edma: remove limits on number of slots

 arch/arm/common/edma.c             |   22 ++++-
 drivers/dma/edma.c                 |  157 +++++++++++++++++++++++++++---------
 include/linux/platform_data/edma.h |    2 +
 3 files changed, 142 insertions(+), 39 deletions(-)

-- 
1.7.9.5



From joelf at ti.com  Mon Jul 29 09:29:49 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 29 Jul 2013 08:29:49 -0500
Subject: [PATCH 3/9] ARM: edma: Add function to manually trigger an EDMA
 channel
In-Reply-To: <1375104595-16018-1-git-send-email-joelf@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
Message-ID: <1375104595-16018-4-git-send-email-joelf@ti.com>

Manual trigger for events missed as a result of splitting a
scatter gather list and DMA'ing it in batches. Add a helper
function to trigger a channel incase any such events are missed.

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
 arch/arm/common/edma.c             |   21 +++++++++++++++++++++
 include/linux/platform_data/edma.h |    2 ++
 2 files changed, 23 insertions(+)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 3567ba1..10995b2 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1236,6 +1236,27 @@ void edma_resume(unsigned channel)
 }
 EXPORT_SYMBOL(edma_resume);
 
+int edma_manual_trigger(unsigned channel)
+{
+	unsigned ctlr;
+	int j;
+	unsigned int mask;
+
+	ctlr = EDMA_CTLR(channel);
+	channel = EDMA_CHAN_SLOT(channel);
+	mask = BIT(channel & 0x1f);
+
+	j = channel >> 5;
+
+	/* EDMA channels without event association */
+	edma_shadow0_write_array(ctlr, SH_ESR, j, mask);
+
+	pr_debug("EDMA: ESR%d %08x\n", j,
+		 edma_shadow0_read_array(ctlr, SH_ESR, j));
+	return 0;
+}
+EXPORT_SYMBOL(edma_manual_trigger);
+
 /**
  * edma_start - start dma on a channel
  * @channel: channel being activated
diff --git a/include/linux/platform_data/edma.h b/include/linux/platform_data/edma.h
index 57300fd..0e11eca 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -180,4 +180,6 @@ struct edma_soc_info {
 	const s16	(*xbar_chans)[2];
 };
 
+int edma_manual_trigger(unsigned);
+
 #endif
-- 
1.7.9.5



From joelf at ti.com  Mon Jul 29 09:29:53 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 29 Jul 2013 08:29:53 -0500
Subject: [PATCH 7/9] ARM: edma: Don't clear EMR of channel in edma_stop
In-Reply-To: <1375104595-16018-1-git-send-email-joelf@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
Message-ID: <1375104595-16018-8-git-send-email-joelf@ti.com>

We certainly don't want error conditions to be cleared anywhere
as this will make us 'forget' about missed events. We depend on
knowing which events were missed in order to be able to reissue them.

This fixes a race condition where the EMR was being cleared
by the transfer completion interrupt handler.

Basically, what was happening was:

            Missed event
             |
             |
             V
SG1-SG2-SG3-Null
         \
          \__TC Interrupt (Almost same time as ARM is executing
TC interrupt handler, an event got missed and also forgotten
by clearing the EMR).

The EMR is ultimately being cleared by the Error interrupt
handler once it is handled so we don't have to do it in edma_stop.

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
 arch/arm/common/edma.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 10995b2..dec772e 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1328,7 +1328,6 @@ void edma_stop(unsigned channel)
 		edma_shadow0_write_array(ctlr, SH_EECR, j, mask);
 		edma_shadow0_write_array(ctlr, SH_ECR, j, mask);
 		edma_shadow0_write_array(ctlr, SH_SECR, j, mask);
-		edma_write_array(ctlr, EDMA_EMCR, j, mask);
 
 		pr_debug("EDMA: EER%d %08x\n", j,
 				edma_shadow0_read_array(ctlr, SH_EER, j));
-- 
1.7.9.5



From joelf at ti.com  Mon Jul 29 09:29:54 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 29 Jul 2013 08:29:54 -0500
Subject: [PATCH 8/9] dma: edma: Link to dummy slot only for last SG list split
In-Reply-To: <1375104595-16018-1-git-send-email-joelf@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
Message-ID: <1375104595-16018-9-git-send-email-joelf@ti.com>

Consider the case where we have a scatter-list like:
SG1->SG2->SG3->SG4->SG5->SG6->Null

For ex, for a MAX_NR_SG of 2, earlier we were splitting this as:
SG1->SG2->Null
SG3->SG4->Null
SG5->SG6->Null

Now we split it as
SG1->SG2->Null
SG3->SG4->Null
SG5->SG6->Dummy

This approach results in lesser unwanted interrupts that occur
for the last list split. The Dummy slot has the property of not
raising an error condition if events are missed unlike the Null
slot. We are OK with this as we're done with processing the
whole list once we reach Dummy.

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
 drivers/dma/edma.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index c72e8c9..0d3ebde 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -164,6 +164,12 @@ static void edma_execute(struct edma_chan *echan)
 
 	edesc->total_processed += total_process;
 
+	/* If this is either the last set in a set of SG-list transactions
+	   then setup a link to the dummy slot, this results in all future
+	   events being absorbed and that's OK because we're done */
+	if (edesc->total_processed == edesc->pset_nr)
+		edma_link(echan->slot[total_process-1], echan->ecc->dummy_slot);
+
 	edma_resume(echan->ch_num);
 
 	if (edesc->total_processed <= MAX_NR_SG) {
-- 
1.7.9.5



From joelf at ti.com  Mon Jul 29 09:29:50 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 29 Jul 2013 08:29:50 -0500
Subject: [PATCH 4/9] dma: edma: Find missed events and issue them
In-Reply-To: <1375104595-16018-1-git-send-email-joelf@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
Message-ID: <1375104595-16018-5-git-send-email-joelf@ti.com>

In an effort to move to using Scatter gather lists of any size with
EDMA as discussed at [1] instead of placing limitations on the driver,
we work through the limitations of the EDMAC hardware to find missed
events and issue them.

The sequence of events that require this are:

For the scenario where MAX slots for an EDMA channel is 3:

SG1 -> SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> Null

The above SG list will have to be DMA'd in 2 sets:

(1) SG1 -> SG2 -> SG3 -> Null
(2) SG4 -> SG5 -> SG6 -> Null

After (1) is succesfully transferred, the events from the MMC controller
donot stop coming and are missed by the time we have setup the transfer
for (2). So here, we catch the events missed as an error condition and
issue them manually.

[1] http://marc.info/?l=linux-omap&m=137416733628831&w=2

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
 drivers/dma/edma.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index d9a151b..aa4989f 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -417,7 +417,15 @@ static void edma_callback(unsigned ch_num, u16 ch_status, void *data)
 
 		break;
 	case DMA_CC_ERROR:
-		dev_dbg(dev, "transfer error on channel %d\n", ch_num);
+		if (echan->edesc) {
+			dev_dbg(dev, "Missed event on %d, retrying\n",
+				ch_num);
+			edma_clean_channel(echan->ch_num);
+			edma_stop(echan->ch_num);
+			edma_start(echan->ch_num);
+			edma_manual_trigger(echan->ch_num);
+		}
+		dev_dbg(dev, "handled error on channel %d\n", ch_num);
 		break;
 	default:
 		break;
-- 
1.7.9.5



From joelf at ti.com  Mon Jul 29 09:29:48 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 29 Jul 2013 08:29:48 -0500
Subject: [PATCH 2/9] dma: edma: Write out and handle MAX_NR_SG at a given time
In-Reply-To: <1375104595-16018-1-git-send-email-joelf@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
Message-ID: <1375104595-16018-3-git-send-email-joelf@ti.com>

Process SG-elements in batches of MAX_NR_SG if they are greater
than MAX_NR_SG. Due to this, at any given time only those many
slots will be used in the given channel no matter how long the
scatter list is. We keep track of how much has been written
inorder to process the next batch of elements in the scatter-list
and detect completion.

For such intermediate transfer completions (one batch of MAX_NR_SG),
make use of pause and resume functions instead of start and stop
when such intermediate transfer is in progress or completed as we
donot want to clear any pending events.

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
 drivers/dma/edma.c |   79 +++++++++++++++++++++++++++++++++++-----------------
 1 file changed, 54 insertions(+), 25 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 0b68f94..d9a151b 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -56,6 +56,7 @@ struct edma_desc {
 	struct list_head		node;
 	int				absync;
 	int				pset_nr;
+	int				total_processed;
 	struct edmacc_param		pset[0];
 };
 
@@ -104,22 +105,36 @@ static void edma_desc_free(struct virt_dma_desc *vdesc)
 /* Dispatch a queued descriptor to the controller (caller holds lock) */
 static void edma_execute(struct edma_chan *echan)
 {
-	struct virt_dma_desc *vdesc = vchan_next_desc(&echan->vchan);
+	struct virt_dma_desc *vdesc;
 	struct edma_desc *edesc;
-	int i;
+	struct device *dev = echan->vchan.chan.device->dev;
 
-	if (!vdesc) {
-		echan->edesc = NULL;
-		return;
+	int i, j, total_left, total_process;
+
+	/* If either we processed all psets or we're still not started */
+	if (!echan->edesc ||
+	    echan->edesc->pset_nr == echan->edesc->total_processed) {
+		/* Get next vdesc */
+		vdesc = vchan_next_desc(&echan->vchan);
+		if (!vdesc) {
+			echan->edesc = NULL;
+			return;
+		}
+		list_del(&vdesc->node);
+		echan->edesc = to_edma_desc(&vdesc->tx);
 	}
 
-	list_del(&vdesc->node);
+	edesc = echan->edesc;
+
+	/* Find out how many left */
+	total_left = edesc->pset_nr - edesc->total_processed;
+	total_process = total_left > MAX_NR_SG ? MAX_NR_SG : total_left;
 
-	echan->edesc = edesc = to_edma_desc(&vdesc->tx);
 
 	/* Write descriptor PaRAM set(s) */
-	for (i = 0; i < edesc->pset_nr; i++) {
-		edma_write_slot(echan->slot[i], &edesc->pset[i]);
+	for (i = 0; i < total_process; i++) {
+		j = i + edesc->total_processed;
+		edma_write_slot(echan->slot[i], &edesc->pset[j]);
 		dev_dbg(echan->vchan.chan.device->dev,
 			"\n pset[%d]:\n"
 			"  chnum\t%d\n"
@@ -132,24 +147,31 @@ static void edma_execute(struct edma_chan *echan)
 			"  bidx\t%08x\n"
 			"  cidx\t%08x\n"
 			"  lkrld\t%08x\n",
-			i, echan->ch_num, echan->slot[i],
-			edesc->pset[i].opt,
-			edesc->pset[i].src,
-			edesc->pset[i].dst,
-			edesc->pset[i].a_b_cnt,
-			edesc->pset[i].ccnt,
-			edesc->pset[i].src_dst_bidx,
-			edesc->pset[i].src_dst_cidx,
-			edesc->pset[i].link_bcntrld);
+			j, echan->ch_num, echan->slot[i],
+			edesc->pset[j].opt,
+			edesc->pset[j].src,
+			edesc->pset[j].dst,
+			edesc->pset[j].a_b_cnt,
+			edesc->pset[j].ccnt,
+			edesc->pset[j].src_dst_bidx,
+			edesc->pset[j].src_dst_cidx,
+			edesc->pset[j].link_bcntrld);
 		/* Link to the previous slot if not the last set */
-		if (i != (edesc->pset_nr - 1))
+		if (i != (total_process - 1))
 			edma_link(echan->slot[i], echan->slot[i+1]);
 		/* Final pset links to the dummy pset */
 		else
 			edma_link(echan->slot[i], echan->ecc->dummy_slot);
 	}
 
-	edma_start(echan->ch_num);
+	edesc->total_processed += total_process;
+
+	edma_resume(echan->ch_num);
+
+	if (edesc->total_processed <= MAX_NR_SG) {
+		dev_dbg(dev, "first transfer starting %d\n", echan->ch_num);
+		edma_start(echan->ch_num);
+	}
 }
 
 static int edma_terminate_all(struct edma_chan *echan)
@@ -369,19 +391,26 @@ static void edma_callback(unsigned ch_num, u16 ch_status, void *data)
 	struct edma_desc *edesc;
 	unsigned long flags;
 
-	/* Stop the channel */
-	edma_stop(echan->ch_num);
+	/* Pause the channel */
+	edma_pause(echan->ch_num);
 
 	switch (ch_status) {
 	case DMA_COMPLETE:
-		dev_dbg(dev, "transfer complete on channel %d\n", ch_num);
-
 		spin_lock_irqsave(&echan->vchan.lock, flags);
 
 		edesc = echan->edesc;
 		if (edesc) {
+			if (edesc->total_processed == edesc->pset_nr) {
+				dev_dbg(dev, "transfer complete." \
+					" stopping channel %d\n", ch_num);
+				edma_stop(echan->ch_num);
+				vchan_cookie_complete(&edesc->vdesc);
+			} else {
+				dev_dbg(dev, "Intermediate transfer complete" \
+					" on channel %d\n", ch_num);
+			}
+
 			edma_execute(echan);
-			vchan_cookie_complete(&edesc->vdesc);
 		}
 
 		spin_unlock_irqrestore(&echan->vchan.lock, flags);
-- 
1.7.9.5



From joelf at ti.com  Mon Jul 29 09:29:52 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 29 Jul 2013 08:29:52 -0500
Subject: [PATCH 6/9] dma: edma: Detect null slot errors and handle them
 correctly
In-Reply-To: <1375104595-16018-1-git-send-email-joelf@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
Message-ID: <1375104595-16018-7-git-send-email-joelf@ti.com>

For crypto IP, we continue to receive events even continuously in
NULL slot, and request lines don't get de-asserted unlike omap_hsmmc.
Due to this, we continously receive error interrupts when we
manually trigger an event.

We fix this, by first detecting if the Channel is currently transferring
from a NULL slot or not, that's where the edma_read_slot in the error
callback from interrupt handler comes in.

Second thing we do is, if we detect if we are on a NULL slot, we don't
forcefully trigger as this will only result in more error conditions.
Instead we set a missed flag and allow the manual triggerring to happen
in edma_execute which will eventually be called. This fixes the issue
where we are on a NULL slot and continue to receive events from
modules like crypto that don't stop their request events after a
transfer is completed.

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
 drivers/dma/edma.c |   42 ++++++++++++++++++++++++++++++++++++++----
 1 file changed, 38 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 1eda5cc..c72e8c9 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -70,6 +70,7 @@ struct edma_chan {
 	int				ch_num;
 	bool				alloced;
 	int				slot[EDMA_MAX_SLOTS];
+	int				missed;
 	struct dma_slave_config		cfg;
 };
 
@@ -169,6 +170,18 @@ static void edma_execute(struct edma_chan *echan)
 		dev_dbg(dev, "first transfer starting %d\n", echan->ch_num);
 		edma_start(echan->ch_num);
 	}
+
+	/* This happens due to setup times between intermediate transfers
+	   in long SG lists which have to be broken up into transfers of
+	   MAX_NR_SG */
+	if (echan->missed) {
+		dev_dbg(dev, "missed event in execute detected\n");
+		edma_clean_channel(echan->ch_num);
+		edma_stop(echan->ch_num);
+		edma_start(echan->ch_num);
+		edma_manual_trigger(echan->ch_num);
+		echan->missed = 0;
+	}
 }
 
 static int edma_terminate_all(struct edma_chan *echan)
@@ -387,6 +400,7 @@ static void edma_callback(unsigned ch_num, u16 ch_status, void *data)
 	struct device *dev = echan->vchan.chan.device->dev;
 	struct edma_desc *edesc;
 	unsigned long flags;
+	struct edmacc_param p;
 
 	/* Pause the channel */
 	edma_pause(echan->ch_num);
@@ -414,15 +428,35 @@ static void edma_callback(unsigned ch_num, u16 ch_status, void *data)
 
 		break;
 	case DMA_CC_ERROR:
-		if (echan->edesc) {
-			dev_dbg(dev, "Missed event on %d, retrying\n",
-				ch_num);
+		spin_lock_irqsave(&echan->vchan.lock, flags);
+
+		edma_read_slot(EDMA_CHAN_SLOT(echan->slot[0]), &p);
+
+		if (p.a_b_cnt == 0 && p.ccnt == 0) {
+			dev_dbg(dev, "Error occurred, looks like slot is null, just setting miss\n");
+			/*
+			   Issue later based on missed flag which will be sure
+			   to happen as:
+			   (1) we finished transmitting an intermediate slot and
+			       edma_execute is coming up.
+			   (2) or we finished current transfer and issue will
+			       call edma_execute.
+
+			   Important note: issuing can be dangerous here and
+			   lead to some nasty recursion as this is a NULL slot
+			   at this point.
+			*/
+			echan->missed = 1;
+		} else {
+			dev_dbg(dev, "Error occurred but slot is non-null, TRIGGERING\n");
 			edma_clean_channel(echan->ch_num);
 			edma_stop(echan->ch_num);
 			edma_start(echan->ch_num);
 			edma_manual_trigger(echan->ch_num);
 		}
-		dev_dbg(dev, "handled error on channel %d\n", ch_num);
+
+		spin_unlock_irqrestore(&echan->vchan.lock, flags);
+
 		break;
 	default:
 		break;
-- 
1.7.9.5



From joelf at ti.com  Mon Jul 29 09:29:47 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 29 Jul 2013 08:29:47 -0500
Subject: [PATCH 1/9] dma: edma: Setup parameters to DMA MAX_NR_SG at a time
In-Reply-To: <1375104595-16018-1-git-send-email-joelf@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
Message-ID: <1375104595-16018-2-git-send-email-joelf@ti.com>

Changes are made here for configuring existing parameters to support
DMA'ing them out in batches as needed.

Also allocate as many as slots as needed by the SG list, but not more
than MAX_NR_SG. Then these slots will be reused accordingly.
For ex, if MAX_NR_SG=10, and number of SG entries is 40, still only
10 slots will be allocated to DMA the entire SG list of size 40.

Also enable TC interrupts for slots that are a last in a current
iteration, or that fall on a MAX_NR_SG boundary.

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
 drivers/dma/edma.c |   19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 5f3e532..0b68f94 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -222,9 +222,9 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
 	enum dma_slave_buswidth dev_width;
 	u32 burst;
 	struct scatterlist *sg;
-	int i;
 	int acnt, bcnt, ccnt, src, dst, cidx;
 	int src_bidx, dst_bidx, src_cidx, dst_cidx;
+	int i, num_slots_needed;
 
 	if (unlikely(!echan || !sgl || !sg_len))
 		return NULL;
@@ -262,8 +262,11 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
 
 	edesc->pset_nr = sg_len;
 
-	for_each_sg(sgl, sg, sg_len, i) {
-		/* Allocate a PaRAM slot, if needed */
+	/* Allocate a PaRAM slot, if needed */
+
+	num_slots_needed = sg_len > MAX_NR_SG ? MAX_NR_SG : sg_len;
+
+	for (i = 0; i < num_slots_needed; i++) {
 		if (echan->slot[i] < 0) {
 			echan->slot[i] =
 				edma_alloc_slot(EDMA_CTLR(echan->ch_num),
@@ -273,6 +276,10 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
 				return NULL;
 			}
 		}
+	}
+
+	/* Configure PaRAM sets for each SG */
+	for_each_sg(sgl, sg, sg_len, i) {
 
 		acnt = dev_width;
 
@@ -330,6 +337,12 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
 		/* Configure A or AB synchronized transfers */
 		if (edesc->absync)
 			edesc->pset[i].opt |= SYNCDIM;
+
+		/* If this is the last in a current SG set of transactions,
+		   enable interrupts so that next set is processed */
+		if (!((i+1) % MAX_NR_SG))
+			edesc->pset[i].opt |= TCINTEN;
+
 		/* If this is the last set, enable completion interrupt flag */
 		if (i == sg_len - 1)
 			edesc->pset[i].opt |= TCINTEN;
-- 
1.7.9.5



From joelf at ti.com  Mon Jul 29 09:29:55 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 29 Jul 2013 08:29:55 -0500
Subject: [PATCH 9/9] dma: edma: remove limits on number of slots
In-Reply-To: <1375104595-16018-1-git-send-email-joelf@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
Message-ID: <1375104595-16018-10-git-send-email-joelf@ti.com>

With this series, this check is no longer required and
we shouldn't need to reject drivers DMA'ing more than the
MAX number of slots.

Signed-off-by: Joel Fernandes <joelf at ti.com>
---
 drivers/dma/edma.c |    6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 0d3ebde..abf2e87 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -285,12 +285,6 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
 		return NULL;
 	}
 
-	if (sg_len > MAX_NR_SG) {
-		dev_err(dev, "Exceeded max SG segments %d > %d\n",
-			sg_len, MAX_NR_SG);
-		return NULL;
-	}
-
 	edesc = kzalloc(sizeof(*edesc) + sg_len *
 		sizeof(edesc->pset[0]), GFP_ATOMIC);
 	if (!edesc) {
-- 
1.7.9.5



From Dave.Martin at arm.com  Mon Jul 29 09:36:30 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Mon, 29 Jul 2013 14:36:30 +0100
Subject: [RFC][PATCH 1/2] ARM64: add cpu topology definition
In-Reply-To: <20130729095400.GB32383@mudshark.cambridge.arm.com>
References: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>
 <CAKfTPtBpo41LJ3V8TB8YwudwqpURuA2u_Lvu4KYVK=qSs+gFuQ@mail.gmail.com>
 <20130729095400.GB32383@mudshark.cambridge.arm.com>
Message-ID: <20130729133625.GA2280@localhost.localdomain>

On Mon, Jul 29, 2013 at 10:54:01AM +0100, Will Deacon wrote:
> On Mon, Jul 29, 2013 at 10:46:06AM +0100, Vincent Guittot wrote:
> > On 27 July 2013 12:42, Hanjun Guo <hanjun.guo at linaro.org> wrote:
> > > Power aware scheduling needs the cpu topology information to improve the
> > > cpu scheduler decision making.
> > 
> > It's not only power aware scheduling. The scheduler already uses
> > topology and cache sharing when  CONFIG_SCHED_MC and/or
> > CONFIG_SCHED_SMT are enable. So you should also add these configs for
> > arm64 so the scheduler can use it
> 
> ... except that the architecture doesn't define what the AFF fields in MPIDR
> really represent. Using them to make key scheduling decisions relating to

In fact, the ARM Architecture doesn't place any requirements on MPIDRs to
force the aff fields to exist _at all_.  It's just a recommendation.
Instead, you have a 24 or 32-bit number which is unique per CPU, and which
is _probably_ assigned in a way resembling the aff fields.

> cache proximity seems pretty risky to me, especially given the track record
> we've seen already on AArch32 silicon. It's a convenient register if it
> contains the data we want it to contain, but we need to force ourselves to
> come to terms with reality here and simply use it as an identifier for a
> CPU.

+1

Also, we should align arm and arm64.  The problem is basically exactly
the same, and the solution needs to be the same.  struct cputopo_arm is
already being abused  -- for example, TC2 describes the A15 and A7
clusters on a single die as having different "socket_id" values, even
though this is obviously nonsense.  But there's no other way to describe
that system today.

> Can't we just use the device-tree to represent this topological data for
> arm64? Lorenzo has been working on bindings in this area.

This may become more important as we start to see things like asymmetric
topologies appearing (different numbers of nodes and different
interdependence characteristics in adjacent branches of the topology
etc.)

Cheers
---Dave


From benoit.cousson at gmail.com  Mon Jul 29 09:39:59 2013
From: benoit.cousson at gmail.com (Benoit Cousson)
Date: Mon, 29 Jul 2013 15:39:59 +0200
Subject: [PATCH 0/9] ARM: dts: omap5-uevm: fixup wrong regulator
 configuration
In-Reply-To: <51F66B65.4030702@ti.com>
References: <1374079538-19548-1-git-send-email-nm@ti.com>
 <51F63C74.6070503@ti.com> <51F66B65.4030702@ti.com>
Message-ID: <51F670AF.9080808@gmail.com>

Hi Nishanth,

On 29/07/2013 15:17, Nishanth Menon wrote:
> On 07/29/2013 04:57 AM, Keerthy wrote:
>> Hi Nishanth,
>>
>> On Wednesday 17 July 2013 10:15 PM, Nishanth Menon wrote:
>>> Due to wrong older revision of documentation used as reference, we
>>> seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
>>> series is based power tree on production board 750-2628-XXX platform.
>>> Unfortunately, the wrong voltages may be detrimental to OMAP5 as they
>>> supply hardware blocks at voltages that are out of specification.
>>
>> This series looks good to me.
>>
>> Acked-by:  J Keerthy <j-keerthy at ti.com>
>
> Tony, Benoit - this series could prevent OMAP5 from being damaged on
> uEVMs with current 3.11 rc - could you suggest what we need to do to
> get it in?

I'm still on vacation with no way to pull any patch... but I can still
comment on the series quickly.

It seems to me that this series contains some real fixes that might
damage the board due to hihest voltage than expected and some which are
just improvement like for the SMPS9 or LDO[28]. In theory they should no
go necesseraly to -rc, but, I guess that's fine for that one.

All the "fixes" are sharing more than 50% of the changelog content with
only 2 changes in the code, so you'd better squash them into one patch
to avoid repeating the same thing again and again.

Beside that, I will ack the updated one to allow Tony to push them ASAP.

Regards,
Benoit



From linux at arm.linux.org.uk  Mon Jul 29 09:40:12 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 29 Jul 2013 14:40:12 +0100
Subject: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes
In-Reply-To: <51F66D94.9060706@ti.com>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
 <20130726151021.GU24642@n2100.arm.linux.org.uk> <51F2A3AA.4060801@ti.com>
 <20130729111503.GG24642@n2100.arm.linux.org.uk> <51F66D94.9060706@ti.com>
Message-ID: <20130729134012.GK24642@n2100.arm.linux.org.uk>

On Mon, Jul 29, 2013 at 09:26:44AM -0400, Santosh Shilimkar wrote:
> On Monday 29 July 2013 07:15 AM, Russell King - ARM Linux wrote:
> > Would you mind putting them all in the patch system, I can add the acks
> > should anyone supply them later, and I'll repost them along with my set
> > of dma-mask patches.  Thanks.
> > 
> Done.
> 7794/1, 7795/1, 7796/1, 7797/1, 7798/1, 7799/1
> 
> Didn't know how to get XXXX/1,2,3,4... pushed into the tracker.
> BTW, I have also pushed the patched on my git tree branch [1] just
> in case you or some one needs it.

Thanks.  I'd prefer not to have them as stable commits yet because should
we get acks from Jens, Jejb or cjb, we will need to add their acks to them.

My dma-masks branch is still very much unstable at the moment (which is
why its not published) but I shall be posting the patches during this
week.


From santosh.shilimkar at ti.com  Mon Jul 29 09:42:18 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 29 Jul 2013 09:42:18 -0400
Subject: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes
In-Reply-To: <20130729134012.GK24642@n2100.arm.linux.org.uk>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
 <20130726151021.GU24642@n2100.arm.linux.org.uk> <51F2A3AA.4060801@ti.com>
 <20130729111503.GG24642@n2100.arm.linux.org.uk> <51F66D94.9060706@ti.com>
 <20130729134012.GK24642@n2100.arm.linux.org.uk>
Message-ID: <51F6713A.1080403@ti.com>

On Monday 29 July 2013 09:40 AM, Russell King - ARM Linux wrote:
> On Mon, Jul 29, 2013 at 09:26:44AM -0400, Santosh Shilimkar wrote:
>> On Monday 29 July 2013 07:15 AM, Russell King - ARM Linux wrote:
>>> Would you mind putting them all in the patch system, I can add the acks
>>> should anyone supply them later, and I'll repost them along with my set
>>> of dma-mask patches.  Thanks.
>>>
>> Done.
>> 7794/1, 7795/1, 7796/1, 7797/1, 7798/1, 7799/1
>>
>> Didn't know how to get XXXX/1,2,3,4... pushed into the tracker.
>> BTW, I have also pushed the patched on my git tree branch [1] just
>> in case you or some one needs it.
> 
> Thanks.  I'd prefer not to have them as stable commits yet because should
> we get acks from Jens, Jejb or cjb, we will need to add their acks to them.
>
right.
 
> My dma-masks branch is still very much unstable at the moment (which is
> why its not published) but I shall be posting the patches during this
> week.
> 
Sure.

Regards,
Santosh


From broonie at kernel.org  Mon Jul 29 09:43:11 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 29 Jul 2013 14:43:11 +0100
Subject: [PATCH V2 7/8] ARM: dts: wm8994: Add wm8994 support on smdk5420
In-Reply-To: <CAAgF-Bexp_fGT8KV+TQ0_kZLJBtq7UK=TG4eYRA6qpTSL+scxg@mail.gmail.com>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-8-git-send-email-padma.v@samsung.com>
 <20130726151902.GL9858@sirena.org.uk>
 <CAAgF-Be8SNxTZv1yFCwH6yJ-O_3R4reh=3y+pSCLJYW7S9TkUg@mail.gmail.com>
 <CAAgF-Bexp_fGT8KV+TQ0_kZLJBtq7UK=TG4eYRA6qpTSL+scxg@mail.gmail.com>
Message-ID: <20130729134311.GX9858@sirena.org.uk>

On Mon, Jul 29, 2013 at 05:31:16PM +0530, Padma Venkat wrote:
> On Sat, Jul 27, 2013 at 6:46 AM, Padma Venkat <padma.kvr at gmail.com> wrote:

> >>> +     vdd: fixed-regulator at 0 {
> >>> +             compatible = "regulator-fixed";
> >>> +             regulator-name = "vdd-supply";

> >> These names look wrong - they should reflect the names in the schematic
> >> as they're for human comprehensibility.  This may just be a case of
> >> dropping the -supply.

> When I posted the same patch for smdk5250, you asked me to club all
> the same supply regulators. So I clubbed AVDD2 and CPVDD. So any other
> better name for representing both supplies?

No, I'd have told you to combine things taht come from the same supply
on the board - things like the speaker supplies for example aren't going
to be coming from separate places.  The names should reflect whatever
the names on the schemaric are, like I say that's probably just removing
the -supply.

> >> documentation update the other day, it's in my tree now) but it's not
> >> essential and I suspect it needs some work on the clock driver side
> >> still.

> > OK. I will check this.

> As per schemata, input clock to MCLK1 is an oscillator clock with
> 16.9MHz and MCLK2 not showing any input clock. So here I need to add a
> fixed rate clock with 16.9MHz as MCLK1 in the smdk board file.

> Is it correct?

Yes, in the DTS (or to XCLKOUT on the AP?).
-------------- 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/20130729/9290a566/attachment.sig>

From jonas.jensen at gmail.com  Mon Jul 29 09:44:02 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Mon, 29 Jul 2013 15:44:02 +0200
Subject: [PATCH v4] dmaengine: Add MOXA ART DMA engine driver
In-Reply-To: <1374055584-15746-1-git-send-email-jonas.jensen@gmail.com>
References: <1374055584-15746-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1375105442-14827-1-git-send-email-jonas.jensen@gmail.com>

Add dmaengine driver for MOXA ART SoCs.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v3:
    
    1. use BIT() macro in header file
    2. use hardcoded masks in header file
    3. include linux/bitops.h
    
    device tree bindings document:
    4. describe compatible variable "Must be" instead of "Should be"
    
    Applies to next-20130729

 .../devicetree/bindings/dma/moxa,moxart-dma.txt    |  19 +
 drivers/dma/Kconfig                                |   7 +
 drivers/dma/Makefile                               |   1 +
 drivers/dma/moxart-dma.c                           | 478 +++++++++++++++++++++
 drivers/dma/moxart-dma.h                           | 188 ++++++++
 5 files changed, 693 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt
 create mode 100644 drivers/dma/moxart-dma.c
 create mode 100644 drivers/dma/moxart-dma.h

diff --git a/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt b/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt
new file mode 100644
index 0000000..f18f0fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt
@@ -0,0 +1,19 @@
+MOXA ART DMA Controller
+
+See dma.txt first
+
+Required properties:
+
+- compatible : Must be "moxa,moxart-dma"
+- reg : Should contain registers location and length
+- interrupts : Should contain the interrupt number
+- #dma-cells : see dma.txt, should be 1
+
+Example:
+
+	dma: dma at 90500000 {
+		compatible = "moxa,moxart-dma";
+		reg = <0x90500000 0x1000>;
+		interrupts = <24 0>;
+		#dma-cells = <1>;
+	};
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..56c3aaa 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -300,6 +300,13 @@ config DMA_JZ4740
 	select DMA_ENGINE
 	select DMA_VIRTUAL_CHANNELS
 
+config MOXART_DMA
+	tristate "MOXART DMA support"
+	depends on ARCH_MOXART
+	select DMA_ENGINE
+	help
+	  Enable support for the MOXA ART SoC DMA controller.
+
 config DMA_ENGINE
 	bool
 
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 5e0f2ef..470c11b 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_MMP_TDMA) += mmp_tdma.o
 obj-$(CONFIG_DMA_OMAP) += omap-dma.o
 obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o
 obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
+obj-$(CONFIG_MOXART_DMA) += moxart-dma.o
diff --git a/drivers/dma/moxart-dma.c b/drivers/dma/moxart-dma.c
new file mode 100644
index 0000000..4f80a90
--- /dev/null
+++ b/drivers/dma/moxart-dma.c
@@ -0,0 +1,478 @@
+/*
+ * MOXA ART SoCs DMA Engine support.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/irq.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/bitops.h>
+
+#include <asm/cacheflush.h>
+
+#include "dmaengine.h"
+#include "moxart-dma.h"
+
+static DEFINE_SPINLOCK(dma_lock);
+
+struct moxart_dma_chan {
+	struct dma_chan			chan;
+	int				ch_num;
+	bool				allocated;
+	int				error_flag;
+	struct moxart_dma_reg		*reg;
+	void				(*callback)(void *param);
+	void				*callback_param;
+	struct completion		dma_complete;
+	struct dma_slave_config		cfg;
+	struct dma_async_tx_descriptor	tx_desc;
+};
+
+struct moxart_dma_container {
+	int			ctlr;
+	struct dma_device	dma_slave;
+	struct moxart_dma_chan	slave_chans[APB_DMA_MAX_CHANNEL];
+};
+
+struct moxart_dma_container *mdc;
+
+static struct device *chan2dev(struct dma_chan *chan)
+{
+	return &chan->dev->device;
+}
+
+static inline struct moxart_dma_container
+*to_moxart_dma_container(struct dma_device *d)
+{
+	return container_of(d, struct moxart_dma_container, dma_slave);
+}
+
+static inline struct moxart_dma_chan *to_moxart_dma_chan(struct dma_chan *c)
+{
+	return container_of(c, struct moxart_dma_chan, chan);
+}
+
+static int moxart_terminate_all(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+
+	dev_dbg(chan2dev(chan), "%s: mchan=%p\n", __func__, mchan);
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.ul &= ~(APB_DMA_ENABLE | APB_DMA_FIN_INT_EN | APB_DMA_ERR_INT_EN);
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return 0;
+}
+
+static int moxart_slave_config(struct dma_chan *chan,
+			       struct dma_slave_config *cfg)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+	unsigned int data_width, data_inc;
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	memcpy(&mchan->cfg, cfg, sizeof(mchan->cfg));
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.bits.burst = APB_DMAB_BURST_MODE;
+
+	switch (mchan->cfg.src_addr_width) {
+	case DMA_SLAVE_BUSWIDTH_1_BYTE:
+		data_width = APB_DMAB_DATA_WIDTH_1;
+		data_inc = APB_DMAB_DEST_INC_1_4;
+		break;
+	case DMA_SLAVE_BUSWIDTH_2_BYTES:
+		data_width = APB_DMAB_DATA_WIDTH_2;
+		data_inc = APB_DMAB_DEST_INC_2_8;
+		break;
+	default:
+		data_width = APB_DMAB_DATA_WIDTH_4;
+		data_inc = APB_DMAB_DEST_INC_4_16;
+		break;
+	}
+
+	if (mchan->cfg.direction == DMA_MEM_TO_DEV) {
+		mcfg.bits.data_width = data_width;
+		mcfg.bits.dest_sel = APB_DMAB_DEST_APB;
+		mcfg.bits.dest_inc = APB_DMAB_DEST_INC_0;
+		mcfg.bits.source_sel = APB_DMAB_SOURCE_AHB;
+		mcfg.bits.source_inc = data_inc;
+
+		mcfg.bits.dest_req_no = mchan->cfg.slave_id;
+		mcfg.bits.source_req_no = 0;
+	} else {
+		mcfg.bits.data_width = data_width;
+		mcfg.bits.dest_sel = APB_DMAB_SOURCE_AHB;
+		mcfg.bits.dest_inc = data_inc;
+		mcfg.bits.source_sel = APB_DMAB_DEST_APB;
+		mcfg.bits.source_inc = APB_DMAB_DEST_INC_0;
+
+		mcfg.bits.dest_req_no = 0;
+		mcfg.bits.source_req_no = mchan->cfg.slave_id;
+	}
+
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return 0;
+}
+
+static int moxart_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
+			  unsigned long arg)
+{
+	int ret = 0;
+	struct dma_slave_config *config;
+
+	switch (cmd) {
+	case DMA_TERMINATE_ALL:
+		moxart_terminate_all(chan);
+		break;
+	case DMA_SLAVE_CONFIG:
+		config = (struct dma_slave_config *)arg;
+		ret = moxart_slave_config(chan, config);
+		break;
+	default:
+		ret = -ENOSYS;
+	}
+
+	return ret;
+}
+
+static dma_cookie_t moxart_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(tx->chan);
+	dma_cookie_t cookie;
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+
+	mchan->callback = tx->callback;
+	mchan->callback_param = tx->callback_param;
+	mchan->error_flag = 0;
+
+	dev_dbg(chan2dev(tx->chan), "%s: mchan=%p mchan->ch_num=%d mchan->reg=%p\n",
+		__func__, mchan, mchan->ch_num, mchan->reg);
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	cookie = dma_cookie_assign(tx);
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.ul |= (APB_DMA_FIN_INT_EN | APB_DMA_ERR_INT_EN);
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return cookie;
+}
+
+static struct dma_async_tx_descriptor
+*moxart_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
+		      unsigned int sg_len,
+		      enum dma_transfer_direction direction,
+		      unsigned long tx_flags, void *context)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	unsigned long flags;
+	union moxart_dma_reg_cfg mcfg;
+	unsigned int size, adr_width;
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	if (direction == DMA_MEM_TO_DEV) {
+		writel(virt_to_phys((void *)sg_dma_address(&sgl[0])),
+		       &mchan->reg->source_addr);
+		writel(mchan->cfg.dst_addr, &mchan->reg->dest_addr);
+		adr_width = mchan->cfg.src_addr_width;
+	} else {
+		writel(mchan->cfg.src_addr, &mchan->reg->source_addr);
+		writel(virt_to_phys((void *)sg_dma_address(&sgl[0])),
+		       &mchan->reg->dest_addr);
+		adr_width = mchan->cfg.dst_addr_width;
+	}
+
+	size = sgl->length >> adr_width;
+
+	/*
+	 * size is 4 on 64 bytes copied, i.e. once cycle copies 16 bytes
+	 * ( when data_width == APB_DMAB_DATA_WIDTH_4 )
+	 */
+	writel(size, &mchan->reg->cycles);
+
+	dev_dbg(chan2dev(chan), "%s: set %d DMA cycles (sgl->length=%d adr_width=%d)\n",
+		__func__, size, sgl->length, adr_width);
+
+	dev_dbg(chan2dev(chan), "%s: mcfg.ul=%x read from &mchan->reg->cfg.ul=%x\n",
+		__func__, mcfg.ul, (unsigned int)&mchan->reg->cfg.ul);
+
+	dma_async_tx_descriptor_init(&mchan->tx_desc, chan);
+	mchan->tx_desc.tx_submit = moxart_tx_submit;
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+
+	return &mchan->tx_desc;
+}
+
+static struct platform_driver moxart_driver;
+
+bool moxart_filter_fn(struct dma_chan *chan, void *param)
+{
+	if (chan->device->dev->driver == &moxart_driver.driver) {
+		struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+		unsigned int ch_req = *(unsigned int *)param;
+		dev_dbg(chan2dev(chan), "%s: mchan=%p ch_req=%d mchan->ch_num=%d\n",
+			__func__, mchan, ch_req, mchan->ch_num);
+		return ch_req == mchan->ch_num;
+	} else {
+		dev_dbg(chan2dev(chan), "%s: device not registered to this DMA engine\n",
+			__func__);
+		return false;
+	}
+}
+EXPORT_SYMBOL(moxart_filter_fn);
+
+static int moxart_alloc_chan_resources(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	int i;
+	bool found = false;
+
+	for (i = 0; i < APB_DMA_MAX_CHANNEL; i++) {
+		if (i == mchan->ch_num
+			&& !mchan->allocated) {
+			dev_dbg(chan2dev(chan), "%s: allocating channel #%d\n",
+				__func__, mchan->ch_num);
+			mchan->allocated = true;
+			found = true;
+			break;
+		}
+	}
+
+	if (!found)
+		return -ENODEV;
+
+	return 0;
+}
+
+static void moxart_free_chan_resources(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+
+	mchan->allocated = false;
+
+	dev_dbg(chan2dev(chan), "%s: freeing channel #%u\n",
+		__func__, mchan->ch_num);
+}
+
+static void moxart_issue_pending(struct dma_chan *chan)
+{
+	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
+	union moxart_dma_reg_cfg mcfg;
+	unsigned long flags;
+
+	dev_dbg(chan2dev(chan), "%s: mchan=%p\n", __func__, mchan);
+
+	spin_lock_irqsave(&dma_lock, flags);
+
+	mcfg.ul = readl(&mchan->reg->cfg.ul);
+	mcfg.ul |= APB_DMA_ENABLE;
+	writel(mcfg.ul, &mchan->reg->cfg.ul);
+
+	spin_unlock_irqrestore(&dma_lock, flags);
+}
+
+static enum dma_status moxart_tx_status(struct dma_chan *chan,
+					dma_cookie_t cookie,
+					struct dma_tx_state *txstate)
+{
+	enum dma_status ret;
+
+	ret = dma_cookie_status(chan, cookie, txstate);
+	if (ret == DMA_SUCCESS || !txstate)
+		return ret;
+
+	return ret;
+}
+
+static void moxart_dma_init(struct dma_device *dma, struct device *dev)
+{
+	dma->device_prep_slave_sg		= moxart_prep_slave_sg;
+	dma->device_alloc_chan_resources	= moxart_alloc_chan_resources;
+	dma->device_free_chan_resources		= moxart_free_chan_resources;
+	dma->device_issue_pending		= moxart_issue_pending;
+	dma->device_tx_status			= moxart_tx_status;
+	dma->device_control			= moxart_control;
+	dma->dev				= dev;
+
+	INIT_LIST_HEAD(&dma->channels);
+}
+
+static irqreturn_t moxart_dma_interrupt(int irq, void *devid)
+{
+	struct device *dev = devid;
+	struct moxart_dma_chan *mchan = &mdc->slave_chans[0];
+	unsigned int i;
+	union moxart_dma_reg_cfg mcfg;
+
+	dev_dbg(dev, "%s\n", __func__);
+
+	for (i = 0; i < APB_DMA_MAX_CHANNEL; i++, mchan++) {
+		if (mchan->allocated) {
+			mcfg.ul = readl(&mchan->reg->cfg.ul);
+			if (mcfg.ul & APB_DMA_FIN_INT_STS) {
+				mcfg.ul &= ~APB_DMA_FIN_INT_STS;
+				dma_cookie_complete(&mchan->tx_desc);
+			}
+			if (mcfg.ul & APB_DMA_ERR_INT_STS) {
+				mcfg.ul &= ~APB_DMA_ERR_INT_STS;
+				mchan->error_flag = 1;
+			}
+			if (mchan->callback) {
+				dev_dbg(dev, "%s: call callback for mchan=%p\n",
+					__func__, mchan);
+				mchan->callback(mchan->callback_param);
+			}
+			mchan->error_flag = 0;
+			writel(mcfg.ul, &mchan->reg->cfg.ul);
+		}
+	}
+
+	return IRQ_HANDLED;
+}
+
+static struct irqaction moxart_dma_irq = {
+	.name       = "moxart-dma-engine",
+	.flags      = IRQF_DISABLED,
+	.handler    = moxart_dma_interrupt,
+};
+
+static int moxart_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *node = dev->of_node;
+	struct resource res_dma;
+	static void __iomem *dma_base_addr;
+	int ret, i;
+	unsigned int irq;
+	struct moxart_dma_chan *mchan;
+
+	mdc = devm_kzalloc(dev, sizeof(*mdc), GFP_KERNEL);
+	if (!mdc) {
+		dev_err(dev, "can't allocate DMA container\n");
+		return -ENOMEM;
+	}
+
+	ret = of_address_to_resource(node, 0, &res_dma);
+	if (ret) {
+		dev_err(dev, "can't get DMA base resource\n");
+		return ret;
+	}
+
+	irq = irq_of_parse_and_map(node, 0);
+
+	dma_base_addr = devm_ioremap_resource(dev, &res_dma);
+	if (IS_ERR(dma_base_addr)) {
+		dev_err(dev, "devm_ioremap_resource failed\n");
+		return PTR_ERR(dma_base_addr);
+	}
+
+	mdc->ctlr = pdev->id;
+
+	dma_cap_zero(mdc->dma_slave.cap_mask);
+	dma_cap_set(DMA_SLAVE, mdc->dma_slave.cap_mask);
+
+	moxart_dma_init(&mdc->dma_slave, dev);
+
+	mchan = &mdc->slave_chans[0];
+	for (i = 0; i < APB_DMA_MAX_CHANNEL; i++, mchan++) {
+		mchan->ch_num = i;
+		mchan->reg = (struct moxart_dma_reg *)(dma_base_addr + 0x80
+			     + i * sizeof(struct moxart_dma_reg));
+		mchan->callback = NULL;
+		mchan->allocated = 0;
+		mchan->callback_param = NULL;
+
+		dma_cookie_init(&mchan->chan);
+		mchan->chan.device = &mdc->dma_slave;
+		list_add_tail(&mchan->chan.device_node,
+			      &mdc->dma_slave.channels);
+
+		dev_dbg(dev, "%s: mchans[%d]: mchan->ch_num=%d mchan->reg=%p\n",
+			__func__, i, mchan->ch_num, mchan->reg);
+	}
+
+	ret = dma_async_device_register(&mdc->dma_slave);
+	platform_set_drvdata(pdev, mdc);
+
+	moxart_dma_irq.dev_id = dev;
+	setup_irq(irq, &moxart_dma_irq);
+
+	dev_dbg(dev, "%s: IRQ=%d\n", __func__, irq);
+
+	return ret;
+}
+
+static int moxart_remove(struct platform_device *pdev)
+{
+	struct moxart_dma_container *m = dev_get_drvdata(&pdev->dev);
+	dma_async_device_unregister(&m->dma_slave);
+	return 0;
+}
+
+static const struct of_device_id moxart_dma_match[] = {
+	{ .compatible = "moxa,moxart-dma" },
+	{ }
+};
+
+static struct platform_driver moxart_driver = {
+	.probe	= moxart_probe,
+	.remove	= moxart_remove,
+	.driver = {
+		.name		= "moxart-dma-engine",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_dma_match,
+	},
+};
+
+static int moxart_init(void)
+{
+	return platform_driver_register(&moxart_driver);
+}
+subsys_initcall(moxart_init);
+
+static void __exit moxart_exit(void)
+{
+	platform_driver_unregister(&moxart_driver);
+}
+module_exit(moxart_exit);
+
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
+MODULE_DESCRIPTION("MOXART DMA engine driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/dma/moxart-dma.h b/drivers/dma/moxart-dma.h
new file mode 100644
index 0000000..a37b13f
--- /dev/null
+++ b/drivers/dma/moxart-dma.h
@@ -0,0 +1,188 @@
+/*
+ * MOXA ART SoCs DMA Engine support.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __DMA_MOXART_H
+#define __DMA_MOXART_H
+
+#define APB_DMA_MAX_CHANNEL			4
+
+union moxart_dma_reg_cfg {
+
+#define APB_DMA_ENABLE				BIT(0)
+#define APB_DMA_FIN_INT_STS			BIT(1)
+#define APB_DMA_FIN_INT_EN			BIT(2)
+#define APB_DMA_BURST_MODE			BIT(3)
+#define APB_DMA_ERR_INT_STS			BIT(4)
+#define APB_DMA_ERR_INT_EN			BIT(5)
+#define APB_DMA_SOURCE_AHB			BIT(6)
+#define APB_DMA_SOURCE_APB			0
+#define APB_DMA_DEST_AHB			BIT(7)
+#define APB_DMA_DEST_APB			0
+#define APB_DMA_SOURCE_INC_0			0
+#define APB_DMA_SOURCE_INC_1_4			0x100
+#define APB_DMA_SOURCE_INC_2_8			0x200
+#define APB_DMA_SOURCE_INC_4_16			0x300
+#define APB_DMA_SOURCE_DEC_1_4			0x500
+#define APB_DMA_SOURCE_DEC_2_8			0x600
+#define APB_DMA_SOURCE_DEC_4_16			0x700
+#define APB_DMA_SOURCE_INC_MASK			0x700
+#define APB_DMA_DEST_INC_0			0
+#define APB_DMA_DEST_INC_1_4			0x1000
+#define APB_DMA_DEST_INC_2_8			0x2000
+#define APB_DMA_DEST_INC_4_16			0x3000
+#define APB_DMA_DEST_DEC_1_4			0x5000
+#define APB_DMA_DEST_DEC_2_8			0x6000
+#define APB_DMA_DEST_DEC_4_16			0x7000
+#define APB_DMA_DEST_INC_MASK			0x7000
+#define APB_DMA_DEST_REQ_NO_MASK		0xf0000
+#define APB_DMA_DATA_WIDTH_MASK			0x300000
+#define APB_DMA_DATA_WIDTH_4			0
+#define APB_DMA_DATA_WIDTH_2			0x100000
+#define APB_DMA_DATA_WIDTH_1			0x200000
+#define APB_DMA_SOURCE_REQ_NO_MASK		0xf000000
+	unsigned int ul;
+
+	struct {
+
+#define APB_DMAB_ENABLE				1
+		/* enable DMA */
+		unsigned int enable:1;
+
+#define APB_DMAB_FIN_INT_STS			1
+		/* finished interrupt status */
+		unsigned int fin_int_sts:1;
+
+#define APB_DMAB_FIN_INT_EN			1
+		/* finished interrupt enable */
+		unsigned int fin_int_en:1;
+
+#define APB_DMAB_BURST_MODE			1
+		/* burst mode */
+		unsigned int burst:1;
+
+#define APB_DMAB_ERR_INT_STS			1
+		/* error interrupt status */
+		unsigned int err_int_sts:1;
+
+#define APB_DMAB_ERR_INT_EN			1
+		/* error interrupt enable */
+		unsigned int err_int_en:1;
+
+#define APB_DMAB_SOURCE_AHB			1
+#define APB_DMAB_SOURCE_APB			0
+		/* 0:APB (device), 1:AHB (RAM) */
+		unsigned int source_sel:1;
+
+#define APB_DMAB_DEST_AHB			1
+#define APB_DMAB_DEST_APB			0
+		/* 0:APB, 1:AHB */
+		unsigned int dest_sel:1;
+
+#define APB_DMAB_SOURCE_INC_0			0
+#define APB_DMAB_SOURCE_INC_1_4			1
+#define APB_DMAB_SOURCE_INC_2_8			2
+#define APB_DMAB_SOURCE_INC_4_16		3
+#define APB_DMAB_SOURCE_DEC_1_4			5
+#define APB_DMAB_SOURCE_DEC_2_8			6
+#define APB_DMAB_SOURCE_DEC_4_16		7
+#define APB_DMAB_SOURCE_INC_MASK		7
+		/*
+		 * 000: no increment
+		 * 001: +1 (busrt=0), +4  (burst=1)
+		 * 010: +2 (burst=0), +8  (burst=1)
+		 * 011: +4 (burst=0), +16 (burst=1)
+		 * 101: -1 (burst=0), -4  (burst=1)
+		 * 110: -2 (burst=0), -8  (burst=1)
+		 * 111: -4 (burst=0), -16 (burst=1)
+		 */
+		unsigned int source_inc:3;
+
+		unsigned int reserved1:1;
+
+#define APB_DMAB_DEST_INC_0			0
+#define APB_DMAB_DEST_INC_1_4			1
+#define APB_DMAB_DEST_INC_2_8			2
+#define APB_DMAB_DEST_INC_4_16			3
+#define APB_DMAB_DEST_DEC_1_4			5
+#define APB_DMAB_DEST_DEC_2_8			6
+#define APB_DMAB_DEST_DEC_4_16			7
+#define APB_DMAB_DEST_INC_MASK			7
+		/*
+		 * 000: no increment
+		 * 001: +1 (busrt=0), +4  (burst=1)
+		 * 010: +2 (burst=0), +8  (burst=1)
+		 * 011: +4 (burst=0), +16 (burst=1)
+		 * 101: -1 (burst=0), -4  (burst=1)
+		 * 110: -2 (burst=0), -8  (burst=1)
+		 * 111: -4 (burst=0), -16 (burst=1)
+		*/
+		unsigned int dest_inc:3;
+
+		unsigned int reserved2:1;
+
+#define APB_DMAB_DEST_REQ_NO_MASK		15
+		/*
+		 * request signal select of destination
+		 * address for DMA hardware handshake
+		 *
+		 * the request line number is a property of
+		 * the DMA controller itself, e.g. MMC must
+		 * always request channels where
+		 * dma_slave_config->slave_id == 5
+		 *
+		 * 0:	 no request / grant signal
+		 * 1-15: request / grant signal
+		 */
+		unsigned int dest_req_no:4;
+
+#define APB_DMAB_DATA_WIDTH_MASK		3
+#define APB_DMAB_DATA_WIDTH_4			0
+#define APB_DMAB_DATA_WIDTH_2			1
+#define APB_DMAB_DATA_WIDTH_1			2
+		/*
+		 * data width of transfer
+		 * 00: word
+		 * 01: half
+		 * 10: byte
+		 */
+		unsigned int data_width:2;
+
+		unsigned int reserved3:2;
+
+#define APB_DMAB_SOURCE_REQ_NO_MASK		15
+		/*
+		 * request signal select of source
+		 * address for DMA hardware handshake
+		 *
+		 * the request line number is a property of
+		 * the DMA controller itself, e.g. MMC must
+		 * always request channels where
+		 * dma_slave_config->slave_id == 5
+		 *
+		 * 0:	 no request / grant signal
+		 * 1-15: request / grant signal
+		 */
+		unsigned int source_req_no:4;
+
+		unsigned int reserved4:4;
+	} bits;
+};
+
+struct moxart_dma_reg {
+	unsigned int source_addr;
+	unsigned int dest_addr;
+#define APB_DMA_CYCLES_MASK			0x00ffffff
+	unsigned int cycles;	/* depend on burst mode */
+	union moxart_dma_reg_cfg cfg;
+};
+
+#endif
-- 
1.8.2.1



From will.deacon at arm.com  Mon Jul 29 09:50:01 2013
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 29 Jul 2013 14:50:01 +0100
Subject: [PATCH] arm: update advice on kernel and FDT load address.
In-Reply-To: <1375102578-5869-1-git-send-email-ian.campbell@citrix.com>
References: <1375102578-5869-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <20130729135000.GK32383@mudshark.cambridge.arm.com>

Hi Ian,

/me plays English teacher :)

On Mon, Jul 29, 2013 at 01:56:18PM +0100, Ian Campbell wrote:
> Based on the discussion in [0]:
>   - Recommend that the kernel be placed under 128MiB ("for automatic RAM
>     location to work", says Nico)
>   - Recommend that DTB larger than ~16KiB be placed after the 128MiB boundary
>     (in order to avoid conflicting with the kernel decompressor, kernel is at
>     most 32MiB) and within the lowmem region. Somewhat arbitrarily recommend
>     placement below the 256MiB boundary, the real lowmem limit is likely up
>     around 600-800MiB but varies.
> 
> [0] http://article.gmane.org/gmane.linux.ports.arm.kernel/254538
> 
> Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Nicolas Pitre <nicolas.pitre at linaro.org>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Dave Martin <dave.martin at linaro.org>
> Cc: Grant Likely <grant.likely at secretlab.ca>
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>  Documentation/arm/Booting |   14 +++++++++++---
>  1 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting
> index 0c1f475..72c035e 100644
> --- a/Documentation/arm/Booting
> +++ b/Documentation/arm/Booting
> @@ -125,6 +125,13 @@ with the caveat that it may not be located at physical address 0 since
>  the kernel interprets a value of 0 in r2 to mean neither a tagged list
>  nor a dtb were passed.
>  
> +If the DTB is larger than ~16KiB, such that placement in the first
> +16KiB would lead to a conflict with the kernel loaded at 32KiB (as
> +recommended below) which uses the memory between 16KiB-32KiB itself,
> +then the DTB should be placed after the first 128MiB of RAM in order
> +to avoid conflicting with the kernel decompressor. The recommnded

recommended

It also looks like you're repeating part of what is said later regarding the
16k of page tables below the image. Also, we use 20k with LPAE.

> +placement in this case just below the 256MiB boundary.
> +
>  5. Calling the kernel image
>  ---------------------------
>  
> @@ -136,9 +143,10 @@ is stored in flash, and is linked correctly to be run from flash,
>  then it is legal for the boot loader to call the zImage in flash
>  directly.
>  
> -The zImage may also be placed in system RAM (at any location) and
> -called there.  Note that the kernel uses 16K of RAM below the image
> -to store page tables.  The recommended placement is 32KiB into RAM.
> +The zImage may also be placed in system RAM and called there.  The
> +kernel should be placed in the first 128MiB of RAM. Note that the
> +kernel uses 16KiB of RAM below the image to store page tables.  The
> +recommended placement is 32KiB into RAM.

This is a bit clunky since you say that the zImage may be placed in system
RAM, then restrict that in the next sentence.

Will


From coelho at ti.com  Mon Jul 29 09:50:42 2013
From: coelho at ti.com (Luciano Coelho)
Date: Mon, 29 Jul 2013 16:50:42 +0300
Subject: [RFC] clk: add flags to distinguish xtal clocks
In-Reply-To: <1373010853.21065.159.camel@cumari.coelho.fi>
References: <1372971912-10877-1-git-send-email-coelho@ti.com>
 <20130704222538.10823.2559@quantum>
 <1372977465.21065.136.camel@cumari.coelho.fi>
 <20130704231953.10823.94331@quantum>
 <1373010853.21065.159.camel@cumari.coelho.fi>
Message-ID: <1375105842.20048.18.camel@cumari.coelho.fi>

Hi Mike,

On Fri, 2013-07-05 at 10:54 +0300, Luciano Coelho wrote:
> On Thu, 2013-07-04 at 16:19 -0700, Mike Turquette wrote:
> > Quoting Luciano Coelho (2013-07-04 15:37:45)
> > > On Thu, 2013-07-04 at 15:25 -0700, Mike Turquette wrote:
> > > > Or is it the same clock input and basically the problem is that you need
> > > > to know what kind of waveform to expect (e.g. square versus sine)?
> > > 
> > > It's the same clock input in the chip's perspective.  One clock input
> > > that can be any of the combinations I mentioned above.  Again, I'm not
> > > familiar with clocks, so I guess the square vs. sine explanation is
> > > plausible.  What I could see in the firmware is that it handles the
> > > clocks differently if they're xtal or not.
> > 
> > OMAP has a similar thing where sys_clkin (the fast reference clock for
> > the chip) can be 19.2, 26, 38.4, etc. This is easy to handle since only
> > the rates matter.
> 
> Right, this part is easy and I already have the code for that.  What I'm
> missing is a way to pass this XTAL flag to the chip.
> 
> 
> > In your case you need some extra metadata to know what to do. I'm really
> > not sure if CLK_IS_TYPE_XTAL is the most useful form this metadata can
> > take. It would be best to know if the waveform is what you really need
> > to know, or perhaps something else. For instance you might be affected
> > by some clock signal stabilization time. Can you talk to your hardware
> > guys and figure it out? I'd rather model the actual needs instead of
> > just tossing a flag in there.
> 
> I get your point.  I have tried to investigate how this flag is used by
> the firmware and I could see that it is used to set different "buffer
> gains" and "delays" when waking up (I guess this means when the clock is
> starting, so probably related to stabilization time).  They specify two
> "modes", "boost" and "normal" and use different delay values for each.

I tried but I couldn't find any more information on how exactly this
works.  But since this change is really simple and there seems to be
other people who need the same information, couldn't we add it as is and
try to figure out more specific information about the clocks later on?

Even if XTAL is not that useful if we know the other details, at least
it wouldn't hurt to have the flag there anyway.

--
Cheers,
Luca.



From ezequiel.garcia at free-electrons.com  Mon Jul 29 09:52:28 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 29 Jul 2013 10:52:28 -0300
Subject: [PATCH 3/5] ARM: dove: add MBus DT node
In-Reply-To: <51F661DE.1070106@gmail.com>
References: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1375101114-28858-4-git-send-email-sebastian.hesselbarth@gmail.com>
 <51F661DE.1070106@gmail.com>
Message-ID: <20130729135227.GA2417@localhost>

Hi Sebastian,

(Ccing devicetree ML)

On Mon, Jul 29, 2013 at 02:36:46PM +0200, Sebastian Hesselbarth wrote:
> On 07/29/2013 02:31 PM, Sebastian Hesselbarth wrote:
> > This adds a MBus node including ranges and pcie apertures required later.
> >
> > Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> > ---
> >   arch/arm/boot/dts/dove.dtsi |   19 +++++++++++++++++++
> >   1 file changed, 19 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
> > index 397674c..bdda016 100644
> > --- a/arch/arm/boot/dts/dove.dtsi
> > +++ b/arch/arm/boot/dts/dove.dtsi
> > @@ -29,6 +29,20 @@
> >   		marvell,tauros2-cache-features = <0>;
> >   	};
> >
> > +	mbus {
> > +		compatible = "marvell,dove-mbus", "marvell,mbus", "simple-bus";
> > +		#address-cells = <2>;
> > +		#size-cells = <1>;
> > +		pcie-mem-aperture = <0xe0000000 0x10000000>; /* 256M MEM space */
> > +		pcie-io-aperture  = <0xf2000000 0x00200000>; /*   2M I/O space */
> 
> Actually, current v9 of the mbus patch set still requires "controller"
> property to match the corresponding controller node. I had a short
> discussion with Ezequiel to possibly just use of_find_compatible_node
> and blindly assumed post-v8 will already use it.
> 

Ah, regarding this: despite your good arguin against the 'controller' property approach,
I still feel a bit inclined for it, as I like the way it tightly-binds the two nodes.

Maybe the devicetree maintainers can give their opinions on that matter?

Otherwise, it'll just stay as it is :-)
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From daniel.lezcano at linaro.org  Mon Jul 29 10:00:33 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 29 Jul 2013 16:00:33 +0200
Subject: [RFC PATCH 3/3] cpuidle: big.LITTLE: vexpress-TC2 CPU idle driver
In-Reply-To: <1374750866-750-4-git-send-email-lorenzo.pieralisi@arm.com>
References: <1374750866-750-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374750866-750-4-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <51F67581.5080207@linaro.org>

On 07/25/2013 01:14 PM, Lorenzo Pieralisi wrote:
> The big.LITTLE architecture is composed of two clusters of cpus. One cluster
> contains less powerful but more energy efficient processors and the other
> cluster groups the powerful but energy-intensive cpus.
> 
> The TC2 testchip implements two clusters of CPUs (A7 and A15 clusters in
> a big.LITTLE configuration) connected through a CCI interconnect that manages
> coherency of their respective L2 caches and intercluster distributed
> virtual memory messages (DVM).
> 
> TC2 testchip integrates a power controller that manages cores resets, wake-up
> IRQs and cluster low-power states. Power states are managed at cluster
> level, which means that voltage is removed from a cluster iff all cores
> in a cluster are in a wfi state. Single cores can enter a reset state
> which is identical to wfi in terms of power consumption but simplifies the
> way cluster states are entered.
> 
> This patch provides a multiple driver CPU idle implementation for TC2
> which paves the way for a generic big.LITTLE idle driver for all
> upcoming big.LITTLE based systems on chip.
> 
> The driver relies on the MCPM infrastructure to coordinate and manage
> core power states; in particular MCPM allows to suspend specific cores
> and hides the CPUs coordination required to shut-down clusters of CPUs.
> 
> Power down sequences for the respective clusters are implemented in the
> MCPM TC2 backend, with all code needed to clean caches and exit coherency.
> 
> The multiple driver CPU idle infrastructure allows to define different
> C-states for big and little cores, determined at boot by checking the
> part id of the possible CPUs and initializing the respective logical
> masks in the big and little drivers.
> 
> Current big.little systems are composed of A7 and A15 clusters, as
> implemented in TC2, but in the future that may change and the driver
> will have evolve to retrieve what is a 'big' cpu and what is a 'little'
> cpu in order to build the correct topology.
> 
> Cc: Kevin Hilman <khilman at linaro.org>
> Cc: Amit Kucheria <amit.kucheria at linaro.org>
> Cc: Olof Johansson <olof at lixom.net>
> Cc: Nicolas Pitre <nicolas.pitre at linaro.org>
> Cc: Rafael J. Wysocki <rjw at sisk.pl>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
>  MAINTAINERS                          |   9 ++
>  drivers/cpuidle/Kconfig              |  10 ++
>  drivers/cpuidle/Makefile             |   1 +
>  drivers/cpuidle/cpuidle-big_little.c | 187 +++++++++++++++++++++++++++++++++++
>  4 files changed, 207 insertions(+)
>  create mode 100644 drivers/cpuidle/cpuidle-big_little.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bf61e04..01f1b3d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2263,6 +2263,15 @@ F:	drivers/cpufreq/arm_big_little.h
>  F:	drivers/cpufreq/arm_big_little.c
>  F:	drivers/cpufreq/arm_big_little_dt.c
>  
> +CPUIDLE DRIVER - ARM BIG LITTLE
> +M:      Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> +M:      Daniel Lezcano <daniel.lezcano at linaro.org>
> +L:      linux-pm at vger.kernel.org
> +L:      linux-arm-kernel at lists.infradead.org
> +T:      git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
> +S:      Maintained
> +F:      drivers/cpuidle/cpuidle-big_little.c
> +
>  CPUIDLE DRIVERS
>  M:	Rafael J. Wysocki <rjw at sisk.pl>
>  M:	Daniel Lezcano <daniel.lezcano at linaro.org>
> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
> index 0e2cd5c..0f86587 100644
> --- a/drivers/cpuidle/Kconfig
> +++ b/drivers/cpuidle/Kconfig
> @@ -42,6 +42,16 @@ config CPU_IDLE_ZYNQ
>  	help
>  	  Select this to enable cpuidle on Xilinx Zynq processors.
>  
> +config CPU_IDLE_BIG_LITTLE
> +	bool "Support for ARM big.LITTLE processors"
> +	depends on ARCH_VEXPRESS_TC2_PM
> +	select ARM_CPU_SUSPEND
> +	select CPU_IDLE_MULTIPLE_DRIVERS
> +	help
> +	  Select this option to enable CPU idle driver for big.LITTLE based
> +	  ARM systems. Driver manages CPUs coordination through MCPM and
> +	  define different C-states for little and big cores through the
> +	  multiple CPU idle drivers infrastructure.
>  endif
>  
>  config ARCH_NEEDS_CPU_IDLE_COUPLED
> diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
> index 8767a7b..3b6445c 100644
> --- a/drivers/cpuidle/Makefile
> +++ b/drivers/cpuidle/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
>  obj-$(CONFIG_CPU_IDLE_CALXEDA) += cpuidle-calxeda.o
>  obj-$(CONFIG_ARCH_KIRKWOOD) += cpuidle-kirkwood.o
>  obj-$(CONFIG_CPU_IDLE_ZYNQ) += cpuidle-zynq.o
> +obj-$(CONFIG_CPU_IDLE_BIG_LITTLE) += cpuidle-big_little.o
> diff --git a/drivers/cpuidle/cpuidle-big_little.c b/drivers/cpuidle/cpuidle-big_little.c
> new file mode 100644
> index 0000000..98cb375
> --- /dev/null
> +++ b/drivers/cpuidle/cpuidle-big_little.c
> @@ -0,0 +1,187 @@
> +/*
> + * Copyright (c) 2013 ARM/Linaro
> + *
> + * Authors: Daniel Lezcano <daniel.lezcano at linaro.org>
> + *          Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> + *          Nicolas Pitre <nicolas.pitre at linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Maintainer: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> + * Maintainer: Daniel Lezcano <daniel.lezcano at linaro.org>
> + */
> +#include <linux/cpuidle.h>
> +#include <linux/cpu_pm.h>
> +#include <linux/slab.h>
> +#include <linux/of.h>
> +
> +#include <asm/cpu.h>
> +#include <asm/cputype.h>
> +#include <asm/cpuidle.h>
> +#include <asm/mcpm.h>
> +#include <asm/smp_plat.h>
> +#include <asm/suspend.h>
> +
> +static int bl_enter_powerdown(struct cpuidle_device *dev,
> +			      struct cpuidle_driver *drv, int idx);
> +
> +static struct cpuidle_driver bl_idle_little_driver = {
> +	.name = "little_idle",
> +	.owner = THIS_MODULE,
> +	.states[0] = ARM_CPUIDLE_WFI_STATE,
> +	.states[1] = {
> +		.enter			= bl_enter_powerdown,
> +		.exit_latency		= 1000,
> +		.target_residency	= 3500,
> +		.flags			= CPUIDLE_FLAG_TIME_VALID |
> +					  CPUIDLE_FLAG_TIMER_STOP,
> +		.name			= "C1",
> +		.desc			= "ARM little-cluster power down",
> +	},
> +	.state_count = 2,
> +};
> +
> +static struct cpuidle_driver bl_idle_big_driver = {
> +	.name = "big_idle",
> +	.owner = THIS_MODULE,
> +	.states[0] = ARM_CPUIDLE_WFI_STATE,
> +	.states[1] = {
> +		.enter			= bl_enter_powerdown,
> +		.exit_latency		= 1000,
> +		.target_residency	= 3000,
> +		.flags			= CPUIDLE_FLAG_TIME_VALID |
> +					  CPUIDLE_FLAG_TIMER_STOP,
> +		.name			= "C1",
> +		.desc			= "ARM big-cluster power down",
> +	},
> +	.state_count = 2,
> +};
> +
> +/*
> + * notrace prevents trace shims from getting inserted where they
> + * should not. Global jumps and ldrex/strex must not be inserted
> + * in power down sequences where caches and MMU may be turned off.
> + */
> +static int notrace bl_powerdown_finisher(unsigned long arg)
> +{
> +	/* MCPM works with HW CPU identifiers */
> +	unsigned int mpidr = read_cpuid_mpidr();
> +	unsigned int cluster = (mpidr >> 8) & 0xf;
> +	unsigned int cpu = mpidr & 0xf;
> +
> +	mcpm_set_entry_vector(cpu, cluster, cpu_resume);
> +	/*
> +	 * Residency value passed to mcpm_cpu_suspend back-end
> +	 * has to be given clear semantics. Set to 0 as a
> +	 * temporary value.
> +	 */
> +	mcpm_cpu_suspend(0);
> +	/* return value != 0 means failure */
> +	return 1;
> +}
> +
> +/**
> + * bl_enter_powerdown - Programs CPU to enter the specified state
> + * @dev: cpuidle device
> + * @drv: The target state to be programmed
> + * @idx: state index
> + *
> + * Called from the CPUidle framework to program the device to the
> + * specified target state selected by the governor.
> + */
> +static int bl_enter_powerdown(struct cpuidle_device *dev,
> +				struct cpuidle_driver *drv, int idx)
> +{
> +	struct timespec ts_preidle, ts_postidle, ts_idle;
> +	int ret;
> +
> +	/* Used to keep track of the total time in idle */
> +	getnstimeofday(&ts_preidle);
> +
> +	cpu_pm_enter();
> +
> +	ret = cpu_suspend(0, bl_powerdown_finisher);
> +	/* signals the MCPM core that CPU is out of low power state */
> +	mcpm_cpu_powered_up();
> +
> +	cpu_pm_exit();
> +
> +	getnstimeofday(&ts_postidle);
> +	ts_idle = timespec_sub(ts_postidle, ts_preidle);
> +
> +	dev->last_residency = ts_idle.tv_nsec / NSEC_PER_USEC +
> +					ts_idle.tv_sec * USEC_PER_SEC;
> +	local_irq_enable();

time computation and local irq enablement are handled by the cpuidle
framework.

> +	return idx;
> +}
> +
> +static int __init bl_idle_driver_init(struct cpuidle_driver *drv, int cpu_id)
> +{
> +	struct cpuinfo_arm *cpu_info;
> +	struct cpumask *cpumask;
> +	unsigned long cpuid;
> +	int cpu;
> +
> +	cpumask = kzalloc(cpumask_size(), GFP_KERNEL);
> +	if (!cpumask)
> +		return -ENOMEM;
> +
> +	for_each_possible_cpu(cpu) {
> +		cpu_info = &per_cpu(cpu_data, cpu);
> +		cpuid = is_smp() ? cpu_info->cpuid : read_cpuid_id();
> +
> +		/* read cpu id part number */
> +		if ((cpuid & 0xFFF0) == cpu_id)
> +			cpumask_set_cpu(cpu, cpumask);
> +	}
> +
> +	drv->cpumask = cpumask;
> +
> +	return 0;
> +}
> +
> +static int __init bl_idle_init(void)
> +{
> +	int ret;
> +	/*
> +	 * Initialize the driver just for a compliant set of machines
> +	 */
> +	if (!of_machine_is_compatible("arm,vexpress,v2p-ca15_a7"))
> +		return -ENODEV;
> +	/*
> +	 * For now the differentiation between little and big cores
> +	 * is based on the part number. A7 cores are considered little
> +	 * cores, A15 are considered big cores. This distinction may
> +	 * evolve in the future with a more generic matching approach.
> +	 */
> +	ret = bl_idle_driver_init(&bl_idle_little_driver,
> +				  ARM_CPU_PART_CORTEX_A7);
> +	if (ret)
> +		return ret;
> +
> +	ret = bl_idle_driver_init(&bl_idle_big_driver, ARM_CPU_PART_CORTEX_A15);
> +	if (ret)
> +		goto out_uninit_little;
> +
> +	ret = cpuidle_register(&bl_idle_little_driver, NULL);
> +	if (ret)
> +		goto out_uninit_big;
> +
> +	ret = cpuidle_register(&bl_idle_big_driver, NULL);
> +	if (ret)
> +		goto out_unregister_little;
> +
> +	return 0;
> +
> +out_unregister_little:
> +	cpuidle_unregister(&bl_idle_little_driver);
> +out_uninit_big:
> +	kfree(bl_idle_big_driver.cpumask);
> +out_uninit_little:
> +	kfree(bl_idle_little_driver.cpumask);
> +
> +	return ret;
> +}
> +device_initcall(bl_idle_init);
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From p.zabel at pengutronix.de  Mon Jul 29 10:02:00 2013
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon, 29 Jul 2013 16:02:00 +0200
Subject: [PATCH v4 2/6] misc: sram: add ability to mark sram sections as
 reserved
In-Reply-To: <201307291512.25126.heiko@sntech.de>
References: <201307291510.31679.heiko@sntech.de>
 <201307291512.25126.heiko@sntech.de>
Message-ID: <1375106520.4223.24.camel@pizza.hi.pengutronix.de>

Hi Heiko,

Am Montag, den 29.07.2013, 15:12 +0200 schrieb Heiko St?bner:
> Some SoCs need parts of their sram for special purposes. So while being part
> of the peripheral, it should not be part of the genpool controlling the sram.
> 
> Therefore add an option mmio-sram-reserved to keep arbitrary portions of the
> sram from being part of the pool.
> 
> Suggested-by: Rob Herring <robherring2 at gmail.com>
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
> ---
> Philipp: I didn't carry the ack, because the loop changed significantly again.
> So if it looks ok, could you re-ack it please?

I'd prefer the first loop to contain the magic and produce a list of
useable chunks, instead of a list of reserved blocks. The second loop
could then iterate over the array and just call gen_pool_add_virt
repeatedly.

regards
Philipp

>  Documentation/devicetree/bindings/misc/sram.txt |    8 ++
>  drivers/misc/sram.c                             |  101 +++++++++++++++++++++--
>  2 files changed, 101 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
> index 4d0a00e..3b7a5c1 100644
> --- a/Documentation/devicetree/bindings/misc/sram.txt
> +++ b/Documentation/devicetree/bindings/misc/sram.txt
> @@ -8,9 +8,17 @@ Required properties:
>  
>  - reg : SRAM iomem address range
>  
> +Optional properties:
> +
> +- mmio-sram-reserved: ordered list of reserved chunks inside the sram that
> +  should not be used by the OS.
> +  Format is <base size>, <base size>, ...; with base being relative to the
> +  reg property base.
> +
>  Example:
>  
>  sram: sram at 5c000000 {
>  	compatible = "mmio-sram";
>  	reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
> +	mmio-sram-reserved = <0x0 0x100>; /* reserve 0x5c000000-0x5c000100 */
>  };
> diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
> index afe66571..b3ceefb 100644
> --- a/drivers/misc/sram.c
> +++ b/drivers/misc/sram.c
> @@ -36,13 +36,23 @@ struct sram_dev {
>  	struct clk *clk;
>  };
>  
> +struct sram_reserve {
> +	unsigned long start;
> +	unsigned long size;
> +};
> +
>  static int sram_probe(struct platform_device *pdev)
>  {
>  	void __iomem *virt_base;
>  	struct sram_dev *sram;
>  	struct resource *res;
> -	unsigned long size;
> -	int ret;
> +	unsigned long size, cur_start, cur_size;
> +	const __be32 *reserved_list = NULL;
> +	int reserved_size = 0;
> +	struct sram_reserve *rblocks;
> +	unsigned int nblocks;
> +	int ret = 0;
> +	int i;
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	virt_base = devm_ioremap_resource(&pdev->dev, res);
> @@ -65,19 +75,94 @@ static int sram_probe(struct platform_device *pdev)
>  	if (!sram->pool)
>  		return -ENOMEM;
>  
> -	ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
> -				res->start, size, -1);
> -	if (ret < 0) {
> -		if (sram->clk)
> -			clk_disable_unprepare(sram->clk);
> -		return ret;
> +	if (pdev->dev.of_node) {
> +		reserved_list = of_get_property(pdev->dev.of_node,
> +						"mmio-sram-reserved",
> +						&reserved_size);
> +		if (reserved_list) {
> +			reserved_size /= sizeof(*reserved_list);
> +			if (!reserved_size || reserved_size % 2) {
> +				dev_warn(&pdev->dev, "wrong number of arguments in mmio-sram-reserved\n");
> +				reserved_list = NULL;
> +				reserved_size = 0;
> +			}
> +		}
>  	}
>  
> +	/*
> +	 * We need an additional block to mark the end of the memory region
> +	 * after the reserved blocks from the dt are processed.
> +	 */
> +	nblocks = reserved_size / 2 + 1;
> +	rblocks = kmalloc((nblocks) * sizeof(*rblocks), GFP_KERNEL);
> +	if (!rblocks) {
> +		ret = -ENOMEM;
> +		goto err_alloc;
> +	}
> +
> +	for (i = 0; i < nblocks - 1; i++) {
> +		rblocks[i].start = be32_to_cpu(*reserved_list++);
> +		rblocks[i].size = be32_to_cpu(*reserved_list++);
> +
> +		dev_dbg(&pdev->dev, "found reserved block 0x%lx-0x%lx\n",
> +			rblocks[i].start,
> +			rblocks[i].start + rblocks[i].size);
> +	}
> +
> +	/* the last chunk marks the end of the region */
> +	rblocks[nblocks - 1].start = size;
> +	rblocks[nblocks - 1].size = 0;
> +
> +	cur_start = 0;
> +	for (i = 0; i < nblocks; i++) {
> +		/* catch unsorted list entries */
> +		if (rblocks[i].start < cur_start) {
> +			dev_err(&pdev->dev,
> +				"unsorted reserved list (0x%lx before current 0x%lx)\n",
> +				rblocks[i].start, cur_start);
> +			ret = -EINVAL;
> +			goto err_chunks;
> +		}
> +
> +		/* current start is in a reserved block, so continue after it */
> +		if (rblocks[i].start == cur_start) {
> +			cur_start = rblocks[i].start + rblocks[i].size;
> +			continue;
> +		}
> +
> +		/*
> +		 * allocate the space between the current starting
> +		 * address and the following reserved block, or the
> +		 * end of the region.
> +		 */
> +		cur_size = rblocks[i].start - cur_start;
> +
> +		dev_dbg(&pdev->dev, "adding chunk 0x%lx-0x%lx\n",
> +			cur_start, cur_start + cur_size);
> +		ret = gen_pool_add_virt(sram->pool,
> +				(unsigned long)virt_base + cur_start,
> +				res->start + cur_start, cur_size, -1);
> +		if (ret < 0)
> +			goto err_chunks;
> +
> +		/* next allocation after this reserved block */
> +		cur_start = rblocks[i].start + rblocks[i].size;
> +	}
> +
> +	kfree(rblocks);
> +
>  	platform_set_drvdata(pdev, sram);
>  
>  	dev_dbg(&pdev->dev, "SRAM pool: %ld KiB @ 0x%p\n", size / 1024, virt_base);
>  
>  	return 0;
> +
> +err_chunks:
> +	kfree(rblocks);
> +err_alloc:
> +	if (sram->clk)
> +		clk_disable_unprepare(sram->clk);
> +	return ret;
>  }
>  
>  static int sram_remove(struct platform_device *pdev)




From Ian.Campbell at citrix.com  Mon Jul 29 10:03:55 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Mon, 29 Jul 2013 15:03:55 +0100
Subject: [PATCH] arm: update advice on kernel and FDT load address.
In-Reply-To: <20130729135000.GK32383@mudshark.cambridge.arm.com>
References: <1375102578-5869-1-git-send-email-ian.campbell@citrix.com>
 <20130729135000.GK32383@mudshark.cambridge.arm.com>
Message-ID: <1375106635.12741.8.camel@kazak.uk.xensource.com>

On Mon, 2013-07-29 at 14:50 +0100, Will Deacon wrote:
> Hi Ian,
> 
> /me plays English teacher :)
> 
> On Mon, Jul 29, 2013 at 01:56:18PM +0100, Ian Campbell wrote:
> > Based on the discussion in [0]:
> >   - Recommend that the kernel be placed under 128MiB ("for automatic RAM
> >     location to work", says Nico)
> >   - Recommend that DTB larger than ~16KiB be placed after the 128MiB boundary
> >     (in order to avoid conflicting with the kernel decompressor, kernel is at
> >     most 32MiB) and within the lowmem region. Somewhat arbitrarily recommend
> >     placement below the 256MiB boundary, the real lowmem limit is likely up
> >     around 600-800MiB but varies.
> > 
> > [0] http://article.gmane.org/gmane.linux.ports.arm.kernel/254538
> > 
> > Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
> > Cc: Russell King <linux at arm.linux.org.uk>
> > Cc: Nicolas Pitre <nicolas.pitre at linaro.org>
> > Cc: Will Deacon <will.deacon at arm.com>
> > Cc: Dave Martin <dave.martin at linaro.org>
> > Cc: Grant Likely <grant.likely at secretlab.ca>
> > Cc: linux-arm-kernel at lists.infradead.org
> > ---
> >  Documentation/arm/Booting |   14 +++++++++++---
> >  1 files changed, 11 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting
> > index 0c1f475..72c035e 100644
> > --- a/Documentation/arm/Booting
> > +++ b/Documentation/arm/Booting
> > @@ -125,6 +125,13 @@ with the caveat that it may not be located at physical address 0 since
> >  the kernel interprets a value of 0 in r2 to mean neither a tagged list
> >  nor a dtb were passed.
> >  
> > +If the DTB is larger than ~16KiB, such that placement in the first
> > +16KiB would lead to a conflict with the kernel loaded at 32KiB (as
> > +recommended below) which uses the memory between 16KiB-32KiB itself,
> > +then the DTB should be placed after the first 128MiB of RAM in order
> > +to avoid conflicting with the kernel decompressor. The recommnded
> 
> recommended

Should've pressed F5, sorry...

> It also looks like you're repeating part of what is said later regarding the
> 16k of page tables below the image.

yes, this was tricky since I wanted to justify the larger than 16KiB but
that was a forward reference. I went with "as recommended below".
Perhaps I should just omit the justification? Or perhaps "If the DTB is
larger than ~16KiB (see below for why this particular value
matters)...". Clunky :-(

> Also, we use 20k with LPAE.

I'll fold in an update along those lines too.

However given that this then makes everything more complicated (e.g.
it's now DTB > ~12KiB in that case) perhaps we should just ditch the
original recommendation to use the first 16KiB and switch to a
recommendation of "as high as possible below 256MiB" across the board?
That would remove the issue with repeating stuff from the next section
too.

> > +placement in this case just below the 256MiB boundary.
> > +
> >  5. Calling the kernel image
> >  ---------------------------
> >  
> > @@ -136,9 +143,10 @@ is stored in flash, and is linked correctly to be run from flash,
> >  then it is legal for the boot loader to call the zImage in flash
> >  directly.
> >  
> > -The zImage may also be placed in system RAM (at any location) and
> > -called there.  Note that the kernel uses 16K of RAM below the image
> > -to store page tables.  The recommended placement is 32KiB into RAM.
> > +The zImage may also be placed in system RAM and called there.  The
> > +kernel should be placed in the first 128MiB of RAM. Note that the
> > +kernel uses 16KiB of RAM below the image to store page tables.  The
> > +recommended placement is 32KiB into RAM.
> 
> This is a bit clunky since you say that the zImage may be placed in system
> RAM, then restrict that in the next sentence.

How about:

        The kernel may also be placed in the first 128MiB of system RAM
        and called there. Note that the kernel uses 16KiB of RAM below
        the image to store page tables.  The recommended placement is
        32KiB into RAM.

?
Ian.



From mark.rutland at arm.com  Mon Jul 29 10:04:31 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 29 Jul 2013 15:04:31 +0100
Subject: [PATCH 04/10] ARM: sun6i: Add restart code for the A31
In-Reply-To: <1374618312-19001-5-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374618312-19001-5-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20130729140430.GA25264@e106331-lin.cambridge.arm.com>

On Tue, Jul 23, 2013 at 11:25:06PM +0100, Maxime Ripard wrote:
> The Allwinner A31 has a sligthly different watchdog that requires a
> different restart code.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  arch/arm/mach-sunxi/sunxi.c | 37 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
> 
> diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> index 11326d9..c18ef3a 100644
> --- a/arch/arm/mach-sunxi/sunxi.c
> +++ b/arch/arm/mach-sunxi/sunxi.c
> @@ -32,6 +32,15 @@
>  #define SUN4I_WATCHDOG_MODE_ENABLE		(1 << 0)
>  #define SUN4I_WATCHDOG_MODE_RESET_ENABLE	(1 << 1)
>  
> +#define SUN6I_WATCHDOG1_IRQ_REG		0x00
> +#define SUN6I_WATCHDOG1_CTRL_REG	0x10
> +#define SUN6I_WATCHDOG1_CTRL_RESTART		(1 << 0)
> +#define SUN6I_WATCHDOG1_CONFIG_REG	0x14
> +#define SUN6I_WATCHDOG1_CONFIG_RESTART		(1 << 0)
> +#define SUN6I_WATCHDOG1_CONFIG_IRQ		(1 << 1)
> +#define SUN6I_WATCHDOG1_MODE_REG	0x18
> +#define SUN6I_WATCHDOG1_MODE_ENABLE		(1 << 0)
> +
>  static void __iomem *wdt_base;
>  
>  static void sun4i_restart(enum reboot_mode mode, const char *cmd)
> @@ -56,8 +65,36 @@ static void sun4i_restart(enum reboot_mode mode, const char *cmd)
>  	}
>  }
>  
> +static void sun6i_restart(char mode, const char *cmd)
> +{
> +	if (!wdt_base)
> +		return;
> +
> +	/* Disable interrupts */
> +	writel(0, wdt_base + SUN6I_WATCHDOG1_IRQ_REG);
> +
> +	/* We want to disable the IRQ and just reset the whole system */
> +	writel(SUN6I_WATCHDOG1_CONFIG_RESTART,
> +		wdt_base + SUN6I_WATCHDOG1_CONFIG_REG);
> +
> +	/* Enable timer. The default and lowest interval value is 0.5s */
> +	writel(SUN6I_WATCHDOG1_MODE_ENABLE,
> +		wdt_base + SUN6I_WATCHDOG1_MODE_REG);
> +
> +	/* Restart the watchdog. */
> +	writel(SUN6I_WATCHDOG1_CTRL_RESTART,
> +		wdt_base + SUN6I_WATCHDOG1_CTRL_REG);
> +
> +	while (1) {
> +		mdelay(5);
> +		writel(SUN6I_WATCHDOG1_MODE_ENABLE,
> +			wdt_base + SUN6I_WATCHDOG1_MODE_REG);
> +	}
> +}
> +
>  static struct of_device_id sunxi_restart_ids[] = {
>  	{ .compatible = "allwinner,sun4i-wdt", .data = sun4i_restart },
> +	{ .compatible = "allwinner,sun6i-wdt", .data = sun6i_restart },

Is there a corresponding binding document addition? 

sun4i-wdt.txt could be turned into a more general sunxi-wdt.txt.

Thanks,
Mark.


From sebastian.hesselbarth at gmail.com  Mon Jul 29 10:10:19 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Jul 2013 16:10:19 +0200
Subject: [PATCH 1/4] ARM: dove: add cpu device tree node
In-Reply-To: <51F6630D.5010603@arm.com>
References: <1375100946-28521-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1375100946-28521-2-git-send-email-sebastian.hesselbarth@gmail.com>
 <51F6630D.5010603@arm.com>
Message-ID: <51F677CB.4090100@gmail.com>

On 07/29/2013 02:41 PM, Sudeep KarkadaNagesha wrote:
> On 29/07/13 13:29, Sebastian Hesselbarth wrote:
>> This adds a node for the Marvell Sheeva PJ4A CPU found on Dove SoCs.
>> While at it, also move the l2-cache node out of internal registers and
>> consistently name different nodes.
>>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
>> ---
>> Cc: Russell King <linux at arm.linux.org.uk>
>> Cc: Jason Cooper <jason at lakedaemon.net>
>> Cc: Andrew Lunn <andrew at lunn.ch>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree at vger.kernel.org
>> Cc: linux-kernel at vger.kernel.org
>> ---
>>   arch/arm/boot/dts/dove.dtsi |   52 ++++++++++++++++++++++++++-----------------
>>   1 file changed, 32 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
>> index 8d5be1e8..09d9710 100644
>> --- a/arch/arm/boot/dts/dove.dtsi
>> +++ b/arch/arm/boot/dts/dove.dtsi
>> @@ -10,6 +10,23 @@
>>   		gpio2 = &gpio2;
>>   	};
>>
>> +	cpus {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		cpu0: cpu at 0 {
>> +			compatible = "marvell,pj4a", "marvell,sheeva-v7";
>> +			device_type = "cpu";
>> +			next-level-cache = <&l2>;
>> +			reg = <0>;
>> +		};
>> +	};
>> +
>> +	l2: l2-cache {
>> +		compatible = "marvell,tauros2-cache";
>> +		marvell,tauros2-cache-features = <0>;
>> +	};
> Hi Sebastian,
>
> This is not entirely related to the patch but thought of checking with
> you. I was trying to get info on L2 cache controller on Marvell SoCs,
> mainly structure or way/set size. Is that something we can get
> dynamically ? Some specification I referred said its integrated and some
> said its separate(not unified). Basically I need information around
> various L2 cache implementations(Tauros2/Feroceon) from Marvell.
>
> Any pointers or contacts to get this information will be helpful.

Sudeep,

I added Maen and Lior on Cc. Unfortunately, public Marvell SoC
datasheets only refer some closed Marvell datasheets when it comes
to CPU(s) used. Maybe they can help out.

Sebastian



From laurent.pinchart at ideasonboard.com  Mon Jul 29 10:11:44 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 29 Jul 2013 16:11:44 +0200
Subject: [GIT PULL FOR v3.12] sh-pfc fixes and enhancements
Message-ID: <4601856.fyKLDdx1qP@avalon>

Hi Linus,

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://linuxtv.org/pinchartl/fbdev.git pinmux/next/fixes

for you to fetch changes up to e120cacfaac24d4de31b181371daaef6a5773ee3:

  sh-pfc: r8a7790: Add VIN pin groups and functions (2013-07-29 15:52:14 
+0200)

The patches don't conflict with the 'pin-no-gpio' series, the two series can 
be applied independently.

----------------------------------------------------------------
Kunihito Higashiyama (1):
      sh-pfc: r8a7790: Add MSIOF pin groups and functions

Laurent Pinchart (5):
      sh-pfc: Remove unneeded mach/<soc>.h includes
      sh-pfc: sh7372: Replace <mach/irqs.h> with <linux/sh_intc.h>
      sh-pfc: sh73a0: Remove EXT_IRQ16L and EXT_IRQ16H macros
      sh-pfc: r8a7790: Sort pin groups and functions alphabetically
      sh-pfc: r8a7790: Add SCIF2 pin groups and functions

Phil Edworthy (1):
      sh-pfc: r8a7779: Add I2C pin groups

Shinobu Uehara (2):
      sh-pfc: r8a7790: Add USB pin groups and functions
      sh-pfc: r8a7790: Add VIN pin groups and functions

Shinya Kuribayashi (9):
      sh-pfc: r8a7790: Rename I2C SDA/SCL pins
      sh-pfc: r8a7790: Remove trailing '_TANS' string from RTS/CTS pins
      sh-pfc: r8a7790: Remove deprecated Ethernet MII/RMII pins
      sh-pfc: r8a7790: Remove deprecated RDS pins
      sh-pfc: r8a7790: Remove deprecated SPV_EVEN pin
      sh-pfc: r8a7790: Swap SCIFA2_RXD_B and HRX0_C configurations
      sh-pfc: r8a7790: Add TCLK1 pin configuration support
      sh-pfc: r8a7790: Add SCIF2 pins configuration support
      sh-pfc: r8a7790: Fix miscellaneous pinmux configuration tables mistakes

 drivers/pinctrl/sh-pfc/pfc-r8a73a4.c |    1 -
 drivers/pinctrl/sh-pfc/pfc-r8a7740.c |    1 -
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c |  105 +++
 drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 1621 ++++++++++++++++++++-------------
 drivers/pinctrl/sh-pfc/pfc-sh7372.c  |    4 +-
 drivers/pinctrl/sh-pfc/pfc-sh73a0.c  |   68 +-
 6 files changed, 1132 insertions(+), 668 deletions(-)

-- 
Regards,

Laurent Pinchart



From mark.rutland at arm.com  Mon Jul 29 10:11:54 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 29 Jul 2013 15:11:54 +0100
Subject: [PATCH 05/10] ARM: sunxi: Add Allwinner A31 DTSI
In-Reply-To: <1374618312-19001-6-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374618312-19001-6-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20130729141154.GB25264@e106331-lin.cambridge.arm.com>

On Tue, Jul 23, 2013 at 11:25:07PM +0100, Maxime Ripard wrote:
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  arch/arm/boot/dts/Makefile       |   3 +-
>  arch/arm/boot/dts/sun6i-a31.dtsi | 155 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 157 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/sun6i-a31.dtsi

[...]

> +	soc at 01c20000 {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		reg = <0x01c20000 0x300000>;

That's unnecessary, nothing should be using this for a simple-bus.

> +		ranges;
> +
> +		timer at 01c20c00 {
> +			compatible = "allwinner,sun4i-timer";
> +			reg = <0x01c20c00 0xa0>;
> +			interrupts = <
> +					0 18 1
> +					0 19 1
> +					0 20 1
> +					0 21 1
> +					0 22 1
> +					>;

A cosmetic issue, but this would be nicer with each tuple bracketed:

			interrupts = <0 18 1>,
				     <0 19 1>,
				     <0 20 1>,
				     <0 21 1>,
				     <0 22 1>;

> +			clocks = <&osc>;
> +		};

Thanks,
Mark.


From nm at ti.com  Mon Jul 29 10:13:09 2013
From: nm at ti.com (Nishanth Menon)
Date: Mon, 29 Jul 2013 09:13:09 -0500
Subject: [PATCH 0/9] ARM: dts: omap5-uevm: fixup wrong regulator
 configuration
In-Reply-To: <51F670AF.9080808@gmail.com>
References: <1374079538-19548-1-git-send-email-nm@ti.com>
 <51F63C74.6070503@ti.com> <51F66B65.4030702@ti.com>
 <51F670AF.9080808@gmail.com>
Message-ID: <51F67875.9020602@ti.com>

On 07/29/2013 08:39 AM, Benoit Cousson wrote:
> Hi Nishanth,
>
> On 29/07/2013 15:17, Nishanth Menon wrote:
>> On 07/29/2013 04:57 AM, Keerthy wrote:
>>> Hi Nishanth,
>>>
>>> On Wednesday 17 July 2013 10:15 PM, Nishanth Menon wrote:
>>>> Due to wrong older revision of documentation used as reference, we
>>>> seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
>>>> series is based power tree on production board 750-2628-XXX platform.
>>>> Unfortunately, the wrong voltages may be detrimental to OMAP5 as they
>>>> supply hardware blocks at voltages that are out of specification.
>>>
>>> This series looks good to me.
>>>
>>> Acked-by:  J Keerthy <j-keerthy at ti.com>
>>
>> Tony, Benoit - this series could prevent OMAP5 from being damaged on
>> uEVMs with current 3.11 rc - could you suggest what we need to do to
>> get it in?
>
> I'm still on vacation with no way to pull any patch... but I can still
> comment on the series quickly.

Thanks for responding while on vacation.

>
> It seems to me that this series contains some real fixes that might
> damage the board due to hihest voltage than expected and some which are
> just improvement like for the SMPS9 or LDO[28]. In theory they should no
> go necesseraly to -rc, but, I guess that's fine for that one.
>
> All the "fixes" are sharing more than 50% of the changelog content with
> only 2 changes in the code, so you'd better squash them into one patch
> to avoid repeating the same thing again and again.
>
Reason for keeping them separate was to allow any future git bisect to 
narrow down to precise patch.
<--->
  ARM: dts: omap5-uevm: update SMPS9 settings
   ARM: dts: omap5-uevm: update and disable unused regulators LDO[28]
   ARM: dts: omap5-uevm: update LDO1 voltage to 1.5V and settings
   ARM: dts: omap5-uevm: update LDO3 voltage to 1.5V and settings
   ARM: dts: omap5-uevm: update LDO4 voltage to 1.5V and settings
   ARM: dts: omap5-uevm: update LDO6 voltage to 1.2V
   ARM: dts: omap5-uevm: update LDO7 voltage to 2V and settings
   ARM: dts: omap5-uevm: update SDCARD LDO9 and resource REGEN3
<---->

Would you have suggestions on what to squash up?


-- 
Regards,
Nishanth Menon


From daniel.lezcano at linaro.org  Mon Jul 29 10:14:51 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 29 Jul 2013 16:14:51 +0200
Subject: [PATCH 4/7] cpuidle: calxeda: add support to use PSCI calls
In-Reply-To: <1375048598-15637-5-git-send-email-robherring2@gmail.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
 <1375048598-15637-5-git-send-email-robherring2@gmail.com>
Message-ID: <51F678DB.3030308@linaro.org>

On 07/28/2013 11:56 PM, Rob Herring wrote:
> From: Rob Herring <rob.herring at calxeda.com>
> 
> This updates the Calxeda cpuidle driver to use PSCI calls to powergate
> cores. This is needed to enable cpuidle for the ECX-2000.
> 
> This could possibly become a generic PSCI driver, but there are no other
> PSCI users in the kernel other than mach-virt.
> 
> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> Cc: "Rafael J. Wysocki" <rjw at sisk.pl>
> Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
> Cc: linux-pm at vger.kernel.org
> ---

Acked-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Rob,

Shall I take the patch in my tree ?

Thanks
  -- Daniel


>  drivers/cpuidle/cpuidle-calxeda.c | 40 ++++++---------------------------------
>  1 file changed, 6 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
> index 0e6e408..01cfecf3 100644
> --- a/drivers/cpuidle/cpuidle-calxeda.c
> +++ b/drivers/cpuidle/cpuidle-calxeda.c
> @@ -22,51 +22,23 @@
>  
>  #include <linux/cpuidle.h>
>  #include <linux/init.h>
> -#include <linux/io.h>
>  #include <linux/of.h>
> -#include <linux/time.h>
> -#include <linux/delay.h>
> -#include <linux/suspend.h>
>  #include <asm/cpuidle.h>
> -#include <asm/proc-fns.h>
> -#include <asm/smp_scu.h>
>  #include <asm/suspend.h>
> -#include <asm/cacheflush.h>
> -#include <asm/cp15.h>
> -
> -extern void highbank_set_cpu_jump(int cpu, void *jump_addr);
> -extern void *scu_base_addr;
> -
> -static noinline void calxeda_idle_restore(void)
> -{
> -	set_cr(get_cr() | CR_C);
> -	set_auxcr(get_auxcr() | 0x40);
> -	scu_power_mode(scu_base_addr, SCU_PM_NORMAL);
> -}
> +#include <asm/psci.h>
>  
>  static int calxeda_idle_finish(unsigned long val)
>  {
> -	/* Already flushed cache, but do it again as the outer cache functions
> -	 * dirty the cache with spinlocks */
> -	flush_cache_all();
> -
> -	set_auxcr(get_auxcr() & ~0x40);
> -	set_cr(get_cr() & ~CR_C);
> -
> -	scu_power_mode(scu_base_addr, SCU_PM_DORMANT);
> -
> -	cpu_do_idle();
> -
> -	/* Restore things if we didn't enter power-gating */
> -	calxeda_idle_restore();
> -	return 1;
> +	const struct psci_power_state ps = {
> +		.type = PSCI_POWER_STATE_TYPE_POWER_DOWN,
> +	};
> +	return psci_ops.cpu_suspend(ps, __pa(cpu_resume));
>  }
>  
>  static int calxeda_pwrdown_idle(struct cpuidle_device *dev,
>  				struct cpuidle_driver *drv,
>  				int index)
>  {
> -	highbank_set_cpu_jump(smp_processor_id(), cpu_resume);
>  	cpu_suspend(0, calxeda_idle_finish);
>  	return index;
>  }
> @@ -90,7 +62,7 @@ static struct cpuidle_driver calxeda_idle_driver = {
>  
>  static int __init calxeda_cpuidle_init(void)
>  {
> -	if (!of_machine_is_compatible("calxeda,highbank"))
> +	if (!of_machine_is_compatible("calxeda,highbank") || !psci_ops.cpu_suspend)
>  		return -ENODEV;
>  
>  	return cpuidle_register(&calxeda_idle_driver, NULL);
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From sebastian.hesselbarth at gmail.com  Mon Jul 29 10:23:20 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon, 29 Jul 2013 16:23:20 +0200
Subject: [PATCH 3/5] ARM: dove: add MBus DT node
In-Reply-To: <20130729135227.GA2417@localhost>
References: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1375101114-28858-4-git-send-email-sebastian.hesselbarth@gmail.com>
 <51F661DE.1070106@gmail.com> <20130729135227.GA2417@localhost>
Message-ID: <51F67AD8.1070904@gmail.com>

On 07/29/2013 03:52 PM, Ezequiel Garcia wrote:
> Hi Sebastian,
>
> (Ccing devicetree ML)
>
> On Mon, Jul 29, 2013 at 02:36:46PM +0200, Sebastian Hesselbarth wrote:
>> On 07/29/2013 02:31 PM, Sebastian Hesselbarth wrote:
>>> This adds a MBus node including ranges and pcie apertures required later.
>>>
>>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
>>> ---
>>>    arch/arm/boot/dts/dove.dtsi |   19 +++++++++++++++++++
>>>    1 file changed, 19 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
>>> index 397674c..bdda016 100644
>>> --- a/arch/arm/boot/dts/dove.dtsi
>>> +++ b/arch/arm/boot/dts/dove.dtsi
>>> @@ -29,6 +29,20 @@
>>>    		marvell,tauros2-cache-features = <0>;
>>>    	};
>>>
>>> +	mbus {
>>> +		compatible = "marvell,dove-mbus", "marvell,mbus", "simple-bus";
>>> +		#address-cells = <2>;
>>> +		#size-cells = <1>;
>>> +		pcie-mem-aperture = <0xe0000000 0x10000000>; /* 256M MEM space */
>>> +		pcie-io-aperture  = <0xf2000000 0x00200000>; /*   2M I/O space */
>>
>> Actually, current v9 of the mbus patch set still requires "controller"
>> property to match the corresponding controller node. I had a short
>> discussion with Ezequiel to possibly just use of_find_compatible_node
>> and blindly assumed post-v8 will already use it.
>
> Ah, regarding this: despite your good arguin against the 'controller' property approach,
> I still feel a bit inclined for it, as I like the way it tightly-binds the two nodes.

I understand that the phandle property *shows* you that both are
related. But with DT you should always ask for every property, if
(a) it is really required to do the job and (b) does it really
describe the HW or just your SW needs/wishes.

So for the phandle property, I'd prefer to not put it into DT but
let the driver handle it.

Sebastian



From lorenzo.pieralisi at arm.com  Mon Jul 29 10:23:27 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 29 Jul 2013 15:23:27 +0100
Subject: [RFC PATCH 3/3] cpuidle: big.LITTLE: vexpress-TC2 CPU idle driver
In-Reply-To: <51F67581.5080207@linaro.org>
References: <1374750866-750-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1374750866-750-4-git-send-email-lorenzo.pieralisi@arm.com>
 <51F67581.5080207@linaro.org>
Message-ID: <20130729142327.GC6184@e102568-lin.cambridge.arm.com>

On Mon, Jul 29, 2013 at 03:00:33PM +0100, Daniel Lezcano wrote:
> On 07/25/2013 01:14 PM, Lorenzo Pieralisi wrote:

[...]

> > +/**
> > + * bl_enter_powerdown - Programs CPU to enter the specified state
> > + * @dev: cpuidle device
> > + * @drv: The target state to be programmed
> > + * @idx: state index
> > + *
> > + * Called from the CPUidle framework to program the device to the
> > + * specified target state selected by the governor.
> > + */
> > +static int bl_enter_powerdown(struct cpuidle_device *dev,
> > +				struct cpuidle_driver *drv, int idx)
> > +{
> > +	struct timespec ts_preidle, ts_postidle, ts_idle;
> > +	int ret;
> > +
> > +	/* Used to keep track of the total time in idle */
> > +	getnstimeofday(&ts_preidle);
> > +
> > +	cpu_pm_enter();
> > +
> > +	ret = cpu_suspend(0, bl_powerdown_finisher);
> > +	/* signals the MCPM core that CPU is out of low power state */
> > +	mcpm_cpu_powered_up();
> > +
> > +	cpu_pm_exit();
> > +
> > +	getnstimeofday(&ts_postidle);
> > +	ts_idle = timespec_sub(ts_postidle, ts_preidle);
> > +
> > +	dev->last_residency = ts_idle.tv_nsec / NSEC_PER_USEC +
> > +					ts_idle.tv_sec * USEC_PER_SEC;
> > +	local_irq_enable();
> 
> time computation and local irq enablement are handled by the cpuidle
> framework.

Absolutely, rebase leftover, sorry.

Thanks,
Lorenzo



From richard.genoud at gmail.com  Mon Jul 29 10:18:06 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon, 29 Jul 2013 16:18:06 +0200
Subject: [PATCH v2 00/42] ARM: at91: move to common clk framework
In-Reply-To: <51F63516.8090000@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <51F28370.6050304@gmail.com> <51F2996B.6000406@overkiz.com>
 <51F2A556.8020109@overkiz.com>
 <CACQ1gAgw-v3z_sWcsk7SqFFW-ERLjS0RS5GTgAdd5Y1tj3Z1FA@mail.gmail.com>
 <51F63516.8090000@overkiz.com>
Message-ID: <CACQ1gAi53KN=zE8zDxQO=+BY2zvQXakD=OSuzUqc0VLwWLySCA@mail.gmail.com>

2013/7/29 boris brezillon <b.brezillon at overkiz.com>:
> On 29/07/2013 10:00, Richard Genoud wrote:
>>
>> 2013/7/26 boris brezillon <b.brezillon at overkiz.com>:
>>>
>>> On 26/07/2013 17:44, boris brezillon wrote:
>>> I found 2 bugs:
>>> 1) the main frequency ready test in recalc_rate function is wrong
>>> 2) the common clk framework uses the first match for dt clk registration
>>>     and main clk has this compatible property:
>>>     compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
>>>     As a result the main clk is always bound to the fixed-clock driver
>>>     which set the clock frequency to 0 if 'clock-frequency' property is
>>>     missing.
>>>
>>> These bugs will be fixed in next version.
>>> Tell me if you want need thesse patches for testing purpose.
>>
>> Hi Boris,
>>
>> I tested your patch, the clock is not at 0 anymore:
>> AT91: PIT: mck rate = 8333333
>>
>> And it's booting correctly.
>> There's a small bug I found in the at91sam9x5 dtsi file (ssc id is 28,
>> not 27). (patch attached)
>>
>> And yes, I could use your patches for some more tests !
>>
>> Thanks,
>>
>> Richard.
>
> Hi Richard,
>
> Thanks for the bug report.
>
> You'll find in attachements the pre-v3 series fixing the detected bugs
> (including the ssc clock id bug).
>
> If you need anything else please let me know.

Working on sam9g35ek !
you can add my:
Tested-by: Richard Genoud <richard.genoud at gmail.com>


One remark though:
Maybe it would be interesting to keep using the defines in the device
tree for peripheral IDs.
For instance, in arch/arm/boot/dts/at91sam9x5.dtsi : (patch 33)
ssc_clk at 28 {
	id = <28>;
};
May be more readable with the SSC id AT91SAM9X5_ID_SSC, as it was
defined in arch/arm/mach-at91/at91sam9x5.c (removed with patch 20)

IMHO, all AT91SAM9X5_ID_xxx in
arch/arm/mach-at91/include/mach/at91sam9x5.h can me moved in
include/dt-bindings/ and used in at91sam9x5.dtsi

Best regards,
Richard.


From mark.rutland at arm.com  Mon Jul 29 10:30:50 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 29 Jul 2013 15:30:50 +0100
Subject: [PATCH 7/7] dts: calxeda: add ARM PSCI binding
In-Reply-To: <51F66A72.7070209@gmail.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
 <1375048598-15637-8-git-send-email-robherring2@gmail.com>
 <20130729102424.GA24255@e106331-lin.cambridge.arm.com>
 <51F66A72.7070209@gmail.com>
Message-ID: <20130729143050.GC25264@e106331-lin.cambridge.arm.com>

On Mon, Jul 29, 2013 at 02:13:22PM +0100, Rob Herring wrote:
> On 07/29/2013 05:24 AM, Mark Rutland wrote:
> > On Sun, Jul 28, 2013 at 10:56:38PM +0100, Rob Herring wrote:
> >> From: Rob Herring <rob.herring at calxeda.com>
> >>
> >> Add the PSCI binding for Calxeda SOCs. The PSCI function numbers are
> >> different from the DT binding example because the numbering changed in
> >> revisions of the PSCI spec and are already fixed in highbank firmware.
> >> Since the numbering is transparent to the kernel, this difference is not
> >> significant.
> >>
> >> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> >> ---
> >>  arch/arm/boot/dts/ecx-common.dtsi | 10 ++++++++++
> >>  1 file changed, 10 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/ecx-common.dtsi b/arch/arm/boot/dts/ecx-common.dtsi
> >> index e8559b7..f1dfc09 100644
> >> --- a/arch/arm/boot/dts/ecx-common.dtsi
> >> +++ b/arch/arm/boot/dts/ecx-common.dtsi
> >> @@ -19,6 +19,16 @@
> >>  		bootargs = "console=ttyAMA0";
> >>  	};
> >>  
> >> +	psci {
> >> +		compatible	= "arm,psci";
> >> +		method		= "smc";
> >> +		cpu_suspend	= <0x84000002>;
> >> +		cpu_off		= <0x84000004>;
> >> +		cpu_on		= <0x84000006>;
> >> +		system_off	= <0x84000100>;
> >> +		system_reset	= <0x84000101>;
> >> +	};
> >> +
> > 
> > I see this is somewhat beyond the original PSCI, given the addition of
> > SYSTEM_OFF and SYSTEM_RESET, but not quite PSCI 0.2 as you don't have
> > PSCI_VERSION.
> 
> I do actually support PSCI_VERSION. Forgot to add that to the dts.

Ah, ok. Can you upgrade the compatible string to include "arm,psci-0.2"
while you're at it?

> 
> > It would be nice it the compatible string were more specific here to
> > deal with this and any implementation-specific power_state ID values.
> > Something like "calxeda,highbank-psci", "arm,psci" ?
> 
> Is that something we always want to do? You can't really know the
> implementation quirks up front.

While we might not know the quirks up front, it'll mean that when we
discover one we have a greater chance of being able to find out the
presence of the quirk from an old dts.

Thanks,
Mark.


From ezequiel.garcia at free-electrons.com  Mon Jul 29 10:32:23 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 29 Jul 2013 11:32:23 -0300
Subject: [PATCH 0/5] ARM: dove: switch to DT MBus
In-Reply-To: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130729143222.GB2417@localhost>

Hello Sebastian,

On Mon, Jul 29, 2013 at 02:31:49PM +0200, Sebastian Hesselbarth wrote:
> This patch set converts DT based Dove boards to DT probed MBus to be
> introduced with v3.12.
> 
> The first two patches prepare Dove DT nodes for MBus ID remapping by using
> preprocessor includes and adding the MBUS_ID macro. The third patch adds a
> MBus DT node to Dove SoC dtsi with required ranges for internal MBus and
> AXI registers, and PCIe mem and I/O apertures. The forth patch relocates
> the nodes for the internal devices to the new MBus node. Also, internal-regs
> ranges are updated to allow proper translation of MBus children's reg
> properties. Finally, legacy MBus init is replaced by DT based MBus init
> for DT based Dove.
> 
> The patch set depends on the MBus device tree patches that should appear
> in v3.12. Currently, it is based on v3.11-rc2 with Dove DT cleanup patches
> and MBus patch set v8 applied.
> 
> The patch set is _not_ sent to devicetree mainling list, because the MBus
> binding will be discussed there on the MBus patches itself.
> 
> Sebastian Hesselbarth (5):
>   ARM: dove: use preprocessor on device tree files
>   ARM: dove: add MBUS_ID macro to Dove DT
>   ARM: dove: add MBus DT node
>   ARM: dove: relocate internal registers device nodes

Great, thanks for doing this. I just have a minor suggestion
on the patch 4/5 "ARM: dove: relocate internal registers device nodes".

Regards,
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From nm at ti.com  Mon Jul 29 10:34:37 2013
From: nm at ti.com (Nishanth Menon)
Date: Mon, 29 Jul 2013 09:34:37 -0500
Subject: [PATCH 0/9] ARM: dts: omap5-uevm: fixup wrong regulator
 configuration
In-Reply-To: <CADz42=M8LQ=i2q30=JJU+F-Qx89D1PwU7pW3DH7F1iYiC8-pFA@mail.gmail.com>
References: <1374079538-19548-1-git-send-email-nm@ti.com>
 <51F63C74.6070503@ti.com> <51F66B65.4030702@ti.com>
 <51F670AF.9080808@gmail.com> <51F67875.9020602@ti.com>
 <CADz42=M8LQ=i2q30=JJU+F-Qx89D1PwU7pW3DH7F1iYiC8-pFA@mail.gmail.com>
Message-ID: <51F67D7D.9070003@ti.com>

On 07/29/2013 09:19 AM, Benoit Cousson wrote:
> 2013/7/29 Nishanth Menon <nm at ti.com <mailto:nm at ti.com>>
>
> Well you're lucky I'm now in an area with Wifi and 3G access... last
> week it whould have been impossible to receive it :-)
hehe :)

>
>> All the "fixes" are sharing more than 50% of the changelog
>> content with
>> only 2 changes in the code, so you'd better squash them into one
>> patch
>> to avoid repeating the same thing again and again.
>
>> Reason for keeping them separate was to allow any future git bisect
>> to narrow down to precise patch.
>>     <--->
> Mmm, why? Do you expect some settings to not work or generate crash?

It has worked with a backport to full fledged OS on top and I do not 
expect it to fail, however, I am never sure about how the future issues 
look like :)

>       ARM: dts: omap5-uevm: update SMPS9 settings
>        ARM: dts: omap5-uevm: update and disable unused regulators LDO[28]
>        ARM: dts: omap5-uevm: update LDO1 voltage to 1.5V and settings
>        ARM: dts: omap5-uevm: update LDO3 voltage to 1.5V and settings
>        ARM: dts: omap5-uevm: update LDO4 voltage to 1.5V and settings
>        ARM: dts: omap5-uevm: update LDO6 voltage to 1.2V
>        ARM: dts: omap5-uevm: update LDO7 voltage to 2V and settings
>        ARM: dts: omap5-uevm: update SDCARD LDO9 and resource REGEN3
>     <---->
>
>     Would you have suggestions on what to squash up?
>
>
>
> I guess one patch for all the mandatory fixes, and another one with the
> improvements should be good enough.
>
> Does that sounds OK to you?

patch #1 ARM: dts: omap5-uevm: document regulator signals used on the 
actual board
   -> as is, since it is a documentation patch
Patch #2: ARM: dts: omap5-uevm: fix regulator configurations mandatory 
for SoC
squash of:
-> ARM: dts: omap5-uevm: update LDO1 voltage to 1.5V and settings
-> ARM: dts: omap5-uevm: update LDO3 voltage to 1.5V and settings
-> ARM: dts: omap5-uevm: update LDO4 voltage to 1.5V and settings
-> ARM: dts: omap5-uevm: update LDO6 voltage to 1.2V
-> ARM: dts: omap5-uevm: update LDO7 voltage to 2V and settings
-> ARM: dts: omap5-uevm: update SDCARD LDO9 and resource REGEN3

Patch #3: ARM: dts: omap5-uevm: update optional regulator configurations
squash of:
  -> ARM: dts: omap5-uevm: update SMPS9 settings
  -> ARM: dts: omap5-uevm: update and disable unused regulators LDO[28]

Does that sound fine?
-- 
Regards,
Nishanth Menon


From b.brezillon at overkiz.com  Mon Jul 29 10:34:39 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Mon, 29 Jul 2013 16:34:39 +0200
Subject: [PATCH v2 00/42] ARM: at91: move to common clk framework
In-Reply-To: <CACQ1gAi53KN=zE8zDxQO=+BY2zvQXakD=OSuzUqc0VLwWLySCA@mail.gmail.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <51F28370.6050304@gmail.com> <51F2996B.6000406@overkiz.com>
 <51F2A556.8020109@overkiz.com>
 <CACQ1gAgw-v3z_sWcsk7SqFFW-ERLjS0RS5GTgAdd5Y1tj3Z1FA@mail.gmail.com>
 <51F63516.8090000@overkiz.com>
 <CACQ1gAi53KN=zE8zDxQO=+BY2zvQXakD=OSuzUqc0VLwWLySCA@mail.gmail.com>
Message-ID: <51F67D7F.1050906@overkiz.com>

On 29/07/2013 16:18, Richard Genoud wrote:
> 2013/7/29 boris brezillon <b.brezillon at overkiz.com>:
>> On 29/07/2013 10:00, Richard Genoud wrote:
>>> 2013/7/26 boris brezillon <b.brezillon at overkiz.com>:
>>>> On 26/07/2013 17:44, boris brezillon wrote:
>>>> I found 2 bugs:
>>>> 1) the main frequency ready test in recalc_rate function is wrong
>>>> 2) the common clk framework uses the first match for dt clk registration
>>>>      and main clk has this compatible property:
>>>>      compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
>>>>      As a result the main clk is always bound to the fixed-clock driver
>>>>      which set the clock frequency to 0 if 'clock-frequency' property is
>>>>      missing.
>>>>
>>>> These bugs will be fixed in next version.
>>>> Tell me if you want need thesse patches for testing purpose.
>>> Hi Boris,
>>>
>>> I tested your patch, the clock is not at 0 anymore:
>>> AT91: PIT: mck rate = 8333333
>>>
>>> And it's booting correctly.
>>> There's a small bug I found in the at91sam9x5 dtsi file (ssc id is 28,
>>> not 27). (patch attached)
>>>
>>> And yes, I could use your patches for some more tests !
>>>
>>> Thanks,
>>>
>>> Richard.
>> Hi Richard,
>>
>> Thanks for the bug report.
>>
>> You'll find in attachements the pre-v3 series fixing the detected bugs
>> (including the ssc clock id bug).
>>
>> If you need anything else please let me know.
> Working on sam9g35ek !
> you can add my:
> Tested-by: Richard Genoud <richard.genoud at gmail.com>
>
>
> One remark though:
> Maybe it would be interesting to keep using the defines in the device
> tree for peripheral IDs.
> For instance, in arch/arm/boot/dts/at91sam9x5.dtsi : (patch 33)
> ssc_clk at 28 {
> 	id = <28>;
> };
> May be more readable with the SSC id AT91SAM9X5_ID_SSC, as it was
> defined in arch/arm/mach-at91/at91sam9x5.c (removed with patch 20)
>
> IMHO, all AT91SAM9X5_ID_xxx in
> arch/arm/mach-at91/include/mach/at91sam9x5.h can me moved in
> include/dt-bindings/ and used in at91sam9x5.dtsi
This was requested by Jean-Christophe too.
I'll add these macro files and make use of it in next version.

BTW where should I put these macro files 
(include/dt-bindings/at91/'soc-name'/peripherals.h) ?
Should I use macros for address fied of clocks or just for id property 
(or drop the address) ?

ssc_clk at AT91SAM9X5_ID_SSC {
         id = <AT91SAM9X5_ID_SSC>;
};

or

ssc_clk at 28 {
         id = <AT91SAM9X5_ID_SSC>;
};

or

ssc_clk {
         id = <AT91SAM9X5_ID_SSC>;
};
>
> Best regards,
> Richard.



From linus.walleij at linaro.org  Mon Jul 29 10:29:28 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 Jul 2013 16:29:28 +0200
Subject: [GIT PULL FOR v3.12] sh-pfc fixes and enhancements
In-Reply-To: <4601856.fyKLDdx1qP@avalon>
References: <4601856.fyKLDdx1qP@avalon>
Message-ID: <CACRpkdYjjEt4pKznz95FMkmYi4AkKGmb_=Cdbrrqp5x0B5GnzA@mail.gmail.com>

On Mon, Jul 29, 2013 at 4:11 PM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:

> Hi Linus,
>
> The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:
>
>   Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)
>
> are available in the git repository at:

Excellent Laurent, pulled and pushed for-next for testing.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Mon Jul 29 10:36:11 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 Jul 2013 16:36:11 +0200
Subject: [GIT PULL FOR v3.12] sh-pfc fixes and enhancements
In-Reply-To: <CACRpkdYjjEt4pKznz95FMkmYi4AkKGmb_=Cdbrrqp5x0B5GnzA@mail.gmail.com>
References: <4601856.fyKLDdx1qP@avalon>
 <CACRpkdYjjEt4pKznz95FMkmYi4AkKGmb_=Cdbrrqp5x0B5GnzA@mail.gmail.com>
Message-ID: <CACRpkdanWFjFCpZKGNt601bPAa7Fx6PrPJfw5esZUsJEK2TwyQ@mail.gmail.com>

On Mon, Jul 29, 2013 at 4:29 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Mon, Jul 29, 2013 at 4:11 PM, Laurent Pinchart
> <laurent.pinchart at ideasonboard.com> wrote:
>
>> Hi Linus,
>>
>> The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:
>>
>>   Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)
>>
>> are available in the git repository at:
>
> Excellent Laurent, pulled and pushed for-next for testing.

I re-pulled this on top of the GPIO fixes and pushed.

Yours,
Linus Walleij


From robherring2 at gmail.com  Mon Jul 29 10:39:36 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 29 Jul 2013 09:39:36 -0500
Subject: [PATCH 4/7] cpuidle: calxeda: add support to use PSCI calls
In-Reply-To: <51F678DB.3030308@linaro.org>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
 <1375048598-15637-5-git-send-email-robherring2@gmail.com>
 <51F678DB.3030308@linaro.org>
Message-ID: <51F67EA8.8010603@gmail.com>

On 07/29/2013 09:14 AM, Daniel Lezcano wrote:
> On 07/28/2013 11:56 PM, Rob Herring wrote:
>> From: Rob Herring <rob.herring at calxeda.com>
>>
>> This updates the Calxeda cpuidle driver to use PSCI calls to powergate
>> cores. This is needed to enable cpuidle for the ECX-2000.
>>
>> This could possibly become a generic PSCI driver, but there are no other
>> PSCI users in the kernel other than mach-virt.
>>
>> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
>> Cc: "Rafael J. Wysocki" <rjw at sisk.pl>
>> Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
>> Cc: linux-pm at vger.kernel.org
>> ---
> 
> Acked-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Thanks.

> 
> Rob,
> 
> Shall I take the patch in my tree ?

No, there are interdependencies with the rest of the series, so I plan
to send to arm-soc.

Rob



From ezequiel.garcia at free-electrons.com  Mon Jul 29 10:41:25 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 29 Jul 2013 11:41:25 -0300
Subject: [PATCH 4/5] ARM: dove: relocate internal registers device nodes
In-Reply-To: <1375101114-28858-5-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1375101114-28858-5-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130729144124.GC2417@localhost>

Sebastian,

On Mon, Jul 29, 2013 at 02:31:53PM +0200, Sebastian Hesselbarth wrote:
> With mbus node in place, now relocate all internal device nodes
> to internal-regs node with proper address ranges.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Andrew Lunn <andrew at lunn.ch>
> Cc: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  arch/arm/boot/dts/dove.dtsi |  955 +++++++++++++++++++++----------------------
>  1 file changed, 474 insertions(+), 481 deletions(-)
> 

I think you might do this in a slightly different way, and achieve a
less intrusive patch (fwiw, i personally try to avoid intrusive changes).

Maybe it's just a matter of taste, so it's up to you to decide
Anyway, here's my proposal:

----------------------------8<----------------------------------------
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index db9ae00..0fbc30e 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -5,6 +5,7 @@
 / {
 	compatible = "marvell,dove";
 	model = "Marvell Armada 88AP510 SoC";
+	interrupt-parent = <&intc>;
 
 	aliases {
 		gpio0 = &gpio0;
@@ -41,22 +42,17 @@
 			  MBUS_ID(0x01, 0xfd) 0 0xf8000000 0x8000000   /* BootROM  128M */
 			  MBUS_ID(0x03, 0x01) 0 0xc8000000 0x0100000   /* CESA SRAM  1M */
 			  MBUS_ID(0x0d, 0x00) 0 0xf0000000 0x0100000>; /* PMU  SRAM  1M */
-	};
+};
 
-	soc at f1000000 {
+mbus {
+	internal-regs {
 		compatible = "simple-bus";
 		#address-cells = <1>;
 		#size-cells = <1>;
-		interrupt-parent = <&intc>;
-
-		ranges = <0xc8000000 0xc8000000 0x0100000   /* CESA SRAM   1M */
-		          0xe0000000 0xe0000000 0x8000000   /* PCIe0 Mem 128M */
-		          0xe8000000 0xe8000000 0x8000000   /* PCIe1 Mem 128M */
-		          0xf0000000 0xf0000000 0x0100000   /* ScratchPad  1M */
-		          0x00000000 0xf1000000 0x1000000   /* SB/NB regs 16M */
-		          0xf2000000 0xf2000000 0x0100000   /* PCIe0 I/O   1M */
-		          0xf2100000 0xf2100000 0x0100000   /* PCIe0 I/O   1M */
-		          0xf8000000 0xf8000000 0x8000000>; /* BootROM   128M */
+		ranges = <0x00000000 MBUS_ID(0xf0, 0x01) 0 0x0100000   /* MBUS regs  1M */
+			  0x00800000 MBUS_ID(0xf0, 0x02) 0 0x1000000   /* AXI  regs 16M */
+			  0xffffe000 MBUS_ID(0x03, 0x01) 0 0x0000800   /* CESA SRAM  2k */
+			  0xfffff000 MBUS_ID(0x0d, 0x00) 0 0x0000800>; /* PMU  SRAM  2k */
 
 		mbusc: mbus-ctrl at 20000 {
 			compatible = "marvell,mbus-controller";
@@ -443,7 +439,7 @@
 		crypto: crypto-engine at 30000 {
 			compatible = "marvell,orion-crypto";
 			reg = <0x30000 0x10000>,
-			      <0xc8000000 0x800>;
+			      <0xffffe000 0x800>;
 			reg-names = "regs", "sram";
 			interrupts = <31>;
 			clocks = <&gate_clk 15>;
@@ -465,7 +461,6 @@
 
 			channel1 {
 				interrupts = <40>;
-				dmacap,memset;
 				dmacap,memcpy;
 				dmacap,xor;
 			};
@@ -486,7 +481,6 @@
 
 			channel1 {
 				interrupts = <43>;
-				dmacap,memset;
 				dmacap,memcpy;
 				dmacap,xor;
 			};
----------------------------------->8-----------------------------------

It has a much nicer diffstat:

 arch/arm/boot/dts/dove.dtsi | 24 +++++++++---------------
 1 file changed, 9 insertions(+), 15 deletions(-)

And in addition, it allows to see some (maybe unrelated?) changes
other than the node-relocation.

I've seen these kind of things in (e.g.) omap3-igep0020.dts, and it
seems to me it could be a cleaner way of doing this relocation.
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From daniel.lezcano at linaro.org  Mon Jul 29 10:46:40 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 29 Jul 2013 16:46:40 +0200
Subject: [PATCH 4/7] cpuidle: calxeda: add support to use PSCI calls
In-Reply-To: <51F67EA8.8010603@gmail.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
 <1375048598-15637-5-git-send-email-robherring2@gmail.com>
 <51F678DB.3030308@linaro.org> <51F67EA8.8010603@gmail.com>
Message-ID: <51F68050.5070107@linaro.org>

On 07/29/2013 04:39 PM, Rob Herring wrote:
> On 07/29/2013 09:14 AM, Daniel Lezcano wrote:
>> On 07/28/2013 11:56 PM, Rob Herring wrote:
>>> From: Rob Herring <rob.herring at calxeda.com>
>>>
>>> This updates the Calxeda cpuidle driver to use PSCI calls to powergate
>>> cores. This is needed to enable cpuidle for the ECX-2000.
>>>
>>> This could possibly become a generic PSCI driver, but there are no other
>>> PSCI users in the kernel other than mach-virt.
>>>
>>> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
>>> Cc: "Rafael J. Wysocki" <rjw at sisk.pl>
>>> Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
>>> Cc: linux-pm at vger.kernel.org
>>> ---
>>
>> Acked-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> 
> Thanks.
> 
>>
>> Rob,
>>
>> Shall I take the patch in my tree ?
> 
> No, there are interdependencies with the rest of the series, so I plan
> to send to arm-soc.

Ok, thanks.


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From ezequiel.garcia at free-electrons.com  Mon Jul 29 10:51:30 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Mon, 29 Jul 2013 11:51:30 -0300
Subject: [PATCH 3/5] ARM: dove: add MBus DT node
In-Reply-To: <51F67AD8.1070904@gmail.com>
References: <1375101114-28858-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1375101114-28858-4-git-send-email-sebastian.hesselbarth@gmail.com>
 <51F661DE.1070106@gmail.com> <20130729135227.GA2417@localhost>
 <51F67AD8.1070904@gmail.com>
Message-ID: <20130729145129.GD2417@localhost>

On Mon, Jul 29, 2013 at 04:23:20PM +0200, Sebastian Hesselbarth wrote:
> On 07/29/2013 03:52 PM, Ezequiel Garcia wrote:
> > Hi Sebastian,
> >
> > (Ccing devicetree ML)
> >
> > On Mon, Jul 29, 2013 at 02:36:46PM +0200, Sebastian Hesselbarth wrote:
> >> On 07/29/2013 02:31 PM, Sebastian Hesselbarth wrote:
> >>> This adds a MBus node including ranges and pcie apertures required later.
> >>>
> >>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> >>> ---
> >>>    arch/arm/boot/dts/dove.dtsi |   19 +++++++++++++++++++
> >>>    1 file changed, 19 insertions(+)
> >>>
> >>> diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
> >>> index 397674c..bdda016 100644
> >>> --- a/arch/arm/boot/dts/dove.dtsi
> >>> +++ b/arch/arm/boot/dts/dove.dtsi
> >>> @@ -29,6 +29,20 @@
> >>>    		marvell,tauros2-cache-features = <0>;
> >>>    	};
> >>>
> >>> +	mbus {
> >>> +		compatible = "marvell,dove-mbus", "marvell,mbus", "simple-bus";
> >>> +		#address-cells = <2>;
> >>> +		#size-cells = <1>;
> >>> +		pcie-mem-aperture = <0xe0000000 0x10000000>; /* 256M MEM space */
> >>> +		pcie-io-aperture  = <0xf2000000 0x00200000>; /*   2M I/O space */
> >>
> >> Actually, current v9 of the mbus patch set still requires "controller"
> >> property to match the corresponding controller node. I had a short
> >> discussion with Ezequiel to possibly just use of_find_compatible_node
> >> and blindly assumed post-v8 will already use it.
> >
> > Ah, regarding this: despite your good arguin against the 'controller' property approach,
> > I still feel a bit inclined for it, as I like the way it tightly-binds the two nodes.
> 
> I understand that the phandle property *shows* you that both are
> related. But with DT you should always ask for every property, if
> (a) it is really required to do the job and (b) does it really
> describe the HW or just your SW needs/wishes.
> 

I see and I understand your point. For some reason it still feels
a bit dirty to set this kind of compatible nodes requirement (one
node simply requiring another node).

I would hate to set a precedent for a dirty solution...

Maybe the DT maintainers can shed some light on this?
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From robdclark at gmail.com  Mon Jul 29 10:58:26 2013
From: robdclark at gmail.com (Rob Clark)
Date: Mon, 29 Jul 2013 10:58:26 -0400
Subject: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
In-Reply-To: <51f29ccd.f014b40a.34cc.ffffca2aSMTPIN_ADDED_BROKEN@mx.google.com>
References: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com>
 <CAF6AEGtspnhSGNM4_QQubVfOkZ1Gh1-Z3iyHOLBPVWuqRy81ew@mail.gmail.com>
 <51f29ccd.f014b40a.34cc.ffffca2aSMTPIN_ADDED_BROKEN@mx.google.com>
Message-ID: <CAF6AEGvFPGueM_LHVij9KFzM6NJySHCzmaLstuzZkK5GwP+6gQ@mail.gmail.com>

On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey <tom.cooksey at arm.com> wrote:
> Hi Rob,
>
>> >  * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>> >    allocate buffers for the GPU. Still not sure how to resolve this
>> >    as we don't use DRM for our GPU driver.
>>
>> any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
>> once the dma-fence stuff is in place), we'd have gpu-specific drm
>> (gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
>> using prime/dmabuf to share between the two.
>
> The "extra" buffers we were allocating from armsoc DDX were really
> being allocated through DRM/GEM so we could get an flink name
> for them and pass a reference to them back to our GPU driver on
> the client side. If it weren't for our need to access those
> extra off-screen buffers with the GPU we wouldn't need to
> allocate them with DRM at all. So, given they are really "GPU"
> buffers, it does absolutely make sense to allocate them in a
> different driver to the display driver.
>
> However, to avoid unnecessary memcpys & related cache
> maintenance ops, we'd also like the GPU to render into buffers
> which are scanned out by the display controller. So let's say
> we continue using DRM_IOCTL_MODE_CREATE_DUMB to allocate scan
> out buffers with the display's DRM driver but a custom ioctl
> on the GPU's DRM driver to allocate non scanout, off-screen
> buffers. Sounds great, but I don't think that really works
> with DRI2. If we used two drivers to allocate buffers, which
> of those drivers do we return in DRI2ConnectReply? Even if we
> solve that somehow, GEM flink names are name-spaced to a
> single device node (AFAIK). So when we do a DRI2GetBuffers,
> how does the EGL in the client know which DRM device owns GEM
> flink name "1234"? We'd need some pretty dirty hacks.

You would return the name of the display driver allocating the
buffers.  On the client side you can use generic ioctls to go from
flink -> handle -> dmabuf.  So the client side would end up opening
both the display drm device and the gpu, but without needing to know
too much about the display.

(Probably in (for example) mesa there needs to be a bit of work to
handle this better, but I think that would be needed as well for
sharing between, say, nouveau and udl displaylink driver.. which is
really the same scenario.)

> So then we looked at allocating _all_ buffers with the GPU's
> DRM driver. That solves the DRI2 single-device-name and single
> name-space issue. It also means the GPU would _never_ render
> into buffers allocated through DRM_IOCTL_MODE_CREATE_DUMB.

Well, I think we can differentiate between shared buffers and internal
buffers (textures, vertex upload, etc, etc).

For example, in mesa/gallium driver there are two paths to getting a
buffer...  ->resource_create() and ->resource_from_handle(), the
latter is the path you go for dri2 buffers shared w/ x11.  The former
is buffers that are just internal to gpu (if !(bind &
PIPE_BIND_SHARED)).  I guess you must have something similar in mali
driver.

> One thing I wasn't sure about is if there was an objection
> to using PRIME to export scanout buffers allocated with
> DRM_IOCTL_MODE_CREATE_DUMB and then importing them into a GPU
> driver to be rendered into? Is that a concern?

well.. it wasn't quite the original intention of the 'dumb' ioctls.
But I guess in the end if you hand the gpu a buffer with a
layout/format that it can't grok, then gpu does a staging texture plus
copy.  If you had, for example, some setup w/ gpu that could only
render to tiled format, plus a display that could scanout that format,
then your DDX driver would need to allocate the dri2 buffers with
something other than dumb ioctl.  (But at that point, you probably
need to implement your own EXA so you could hook in your own custom
upload-to/download-from screen fxns for sw fallbacks, so you're not
talking about using generic DDX anyways.)

> Anyway, that latter case also gets quite difficult. The "GPU"
> DRM driver would need to know the constraints of the display
> controller when allocating buffers intended to be scanned out.
> For example, pl111 typically isn't behind an IOMMU and so
> requires physically contiguous memory. We'd have to teach the
> GPU's DRM driver about the constraints of the display HW. Not
> exactly a clean driver model. :-(
>
> I'm still a little stuck on how to proceed, so any ideas
> would greatly appreciated! My current train of thought is
> having a kind of SoC-specific DRM driver which allocates
> buffers for both display and GPU within a single GEM
> namespace. That SoC-specific DRM driver could then know the
> constraints of both the GPU and the display HW. We could then
> use PRIME to export buffers allocated with the SoC DRM driver
> and import them into the GPU and/or display DRM driver.

Usually if the display drm driver is allocating the buffers that might
be scanned out, it just needs to have minimal knowledge of the GPU
(pitch alignment constraints).  I don't think we need a 3rd device
just to allocate buffers.

Really I don't think the separate display drm and gpu drm device is
much different from desktop udl/displaylink case.  Or desktop
integrated-gpu + external gpu.

> Note: While it doesn't use the DRM framework, the Mali T6xx
> kernel driver has supported importing buffers through dma_buf
> for some time. I've even written an EGL extension :-):
>
> <http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_im
> port.txt>
>
>
>> I'm not entirely sure that the directions that the current CDF
>> proposals are headed is necessarily the right way forward.  I'd prefer
>> to see small/incremental evolution of KMS (ie. add drm_bridge and
>> drm_panel, and refactor the existing encoder-slave).  Keeping it
>> inside drm means that we can evolve it more easily, and avoid layers
>> of glue code for no good reason.
>
> I think CDF could allow vendors to re-use code they've written
> for their Android driver stack in DRM drivers more easily. Though
> I guess ideally KMS would evolve to a point where it could be used
> by an Android driver stack. I.e. Support explicit fences.
>

yeah, the best would be evolving DRM/KMS to the point that it meets
android requirements.  Because I really don't think android has any
special requirements compared to, say, a wayland compositor.  (Other
than the way they do synchronization.  But that doesn't really *need*
to be different, as far as I can tell.)  It would certainly be easier
if android dev's actually participated in upstream linux graphics, and
talked about what they needed, and maybe even contributed a patch or
two.  But that is a whole different topic.

BR,
-R

>
> Cheers,
>
> Tom
>
>
>
>
>


From jason at lakedaemon.net  Mon Jul 29 11:01:24 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 29 Jul 2013 11:01:24 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <2469263.vMN09Q7Tzi@flatron>
References: <2469263.vMN09Q7Tzi@flatron>
Message-ID: <20130729150124.GS29916@titan.lakedaemon.net>

On Mon, Jul 29, 2013 at 02:21:52AM +0200, Tomasz Figa wrote:
> Hi,
> 
> As promised I am starting a discussion about Device Tree schema. Let's 
> first shortly introduce the problem.
> 
> Device Tree is a text-based data structure used to describe hardware.

Just a clarifying point here:  I think it would be more accurate to say
"devicetree describes how hardware on a given board is *configured*".
The driver learns from the compatible property which IP block it is
dealing with and handles the necessary quirks.  How that IP block is
attached, and interfaced with is DT territory, that it needs an extra
10ns delay (outside of spec) is something the driver should know and
work around.

> Its 
> main point is separation from kernel code, which has a lot of benefits, 
> but, at the moment, also a huge drawback - there is no verification of 
> device tree sources against defined bindings. All the dtc compiler does 
> currently are syntax checks - no semantic analysis is performed (except
> some really basic things). What this means is that anybody can put
> anything in their device tree and end up with the dts compiling fine only
> to find out that something is wrong at boot time.
> 
> Currently, device tree bindings are described in plain text documentation 
> files, which can not be considered a formal way of binding description. 
> While such documentation provides information for developers/users that 
> need to work with particular bindings, it can not be easily used as input 
> for validation of device tree sources. This means that we need to define a 
> more formal way of binding description, in other words - Device Tree 
> schema.

+1

> To find a solution for this problem, we must first answer several 
> questions to determine a set of requirements we have to meet.
> 
> a) What is a device tree binding?
>  
> For our purposes, I will define a binding as internal format of some 
> device tree node, which can be matched using of_find_matching_node(). In 
> other words, key for a binding would be node name and/or value of 
> compatible property and/or node type. Value for a binding would be a list 
> of properties with their formats and/or subnodes with their bindings.
>  
> b) What information should be specified in schemas? What level of 
>    granularity is required?

One item I don't see in this list is node ordering.  There's been some
discussion lately on deferred probing (re boot times).  If we were to
intentionally declare that DT are parsed in the order written, then a
lot of deferred probes could be avoided by moving eg the pinctrl node to
near the top of the tree.

This doesn't impact buses as much, since the nodes needing the bus are
already children.  However, anything accessed via phandles: pins,
clocks, regulators, etc could benefit from declaring and enforcing this.
Eg having the dtc warn when a phandle is used before it's corresponding
node is declared.

Not critical though, just a thought.

thx,

Jason.

> For each property we need to have at least following data specified:
>  - property name (or property name format, e.g. regex),
>  - whether the property is mandatory or optional,
>  - data type of value.
> 
> As for now, I can think of following data types used in device trees:
>  - boolean (i.e. without value),
>  - array of strings (including single string),
>  - array of u32 (including single u32),
>  - specifier (aka phandle with args, including cases with 0 args),
>  - variable-length cells (e.g. #address-cells of u32s).
> 
> Some properties might require a combination of data types to be specified 
> or even an array of combinations, like interrupt-map property, which is an 
> array of entries consisting of:
>  - #address-cells u32s,
>  - #interrupt-cells u32s,
>  - specifier (phandle of interrupt controller and u32 of count defined by 
>    #interrupt-cells of the controller).
> 
> We probably want to define allowed range of values for given property, be 
> it contiguous or enumerated.
> 
> As for subnodes, I think we need to define following constraints:
>  - node name (or node name format, e.g. regex),
>  - optional or not,
>  - how many nodes of this type can be present (one, limited, unlimited),
>  - recursively define binding for such node type.
> 
> We probably also want human readable descriptions for all properties and 
> subnodes, so a textual documentation (like the one currently available) 
> could be generated from schemas.
> 
> c) What about generic bindings? (e.g. for subsystems like pinctrl or 
> regulators)
> 
> This is where things get more interesting. Looks like we need some kind of 
> inheritance for bindings or binding templates. Templates sound more 
> appropriate here, because most of the generic bindings do not fully 
> conform to what I defined as binding and need device-specific parameters 
> to become so.
> 
> Let's consider first example taken from regulator subsystem.
> 
> 	device {
> 		compatible = "foo,mydevice";
> 		/* ... */
> 		core-supply = <&regulator_a>;
> 		io-supply = <&regulator_b>;
> 		/* ... */
> 	};
> 
> Bindings of regulator subsystem define the way of regulator lookup to be 
> based on property matching following definition:
> 
> 	#define REGULATOR(name) name ## _supply = <&phandle>
> 
> As you can see, the binding is parametrized, i.e. part of it is defined 
> globally, but part is device-specific. Similarly for pinctrl subsystem:
> 
> 	device {
> 		compatible = "foo,mydevice";
> 		/* ... */
> 		pinctrl-names = "state0", "state1";
> 		pinctrl-0 = <&phandle>...;
> 		pinctrl-1 = <&phandle>...;
> 		/* ... */
> 	};
> 
> This binding is now parametrized in a more complex way:
> 
> 	#define PINCTRL(name0, name1, ..., nameN) \
> 		pinctrl-names = name0, name1, ..., nameN; \
> 		pinctrl-0 = <&phandle>...; \
> 		pinctrl-1 = <&phandle>...; \
> 		... \
> 		pinctrl-N = <&phandle>...;
> 
> We need to have a way to describe this kind of inheritance, if we don't 
> want to respecify generic attributes in all device bindings using them.
> 
> d) When should the validation happen and what should handle it?
> 
> In my opinion, similarly to compilation of board files, validation should 
> be happening at dts compile time, to show any warnings or errors as early 
> as possible.
> 
> Whether this should be integrated into dtc or rather handled by external 
> tool is another question. Since we are already processing device tree 
> sources in dtc, it might be reasonable to reuse its dts parsing 
> infrastructure and add validation there, especially that dtc is supposed 
> to already contain some infrastructure for doing checks on device tree as 
> well. Nothing stops us from running validation on already compiled dtbs, 
> though, using an extra tool.
> 
> e) What format should be used for Device Tree schema?
> 
> This is a non-trivial problem. Key criteria I can think of are as follows:
>  - the whole set of information established above must be representable,
>  - human-readable, easy to create and edit (extend), preferably similar to 
>    something already existing, so could be easily learnt,
>  - something that can be integrated with dtc with reasonable amount of 
>    work or can reuse a lot (if not all) of already existing parsing code.
> 
> Okay, this should be enough to have some discussion. I will post a
> follow-up with my proposal of schema format to separate general discussion
> from discussion about the proposal, but this will happen tomorrow, as now
> it's time to get some sleep.
> 
> For now please think about the points above and feel free to correct
> anything wrong or suggest what else should be taken into consideration
> for DT schemas. Let the discussion start.
> 
> Best regards,
> Tomasz
> 


From holler at ahsoftware.de  Mon Jul 29 10:52:52 2013
From: holler at ahsoftware.de (Alexander Holler)
Date: Mon, 29 Jul 2013 16:52:52 +0200
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping
 for every GPIO on DT"
In-Reply-To: <51F666B7.7020209@ti.com>
References: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
 <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
 <51F633AE.8090308@collabora.co.uk> <51F63864.9000601@collabora.co.uk>
 <51F666B7.7020209@ti.com>
Message-ID: <51F681C4.3000400@ahsoftware.de>

Am 29.07.2013 14:57, schrieb Santosh Shilimkar:

> With some helps from MMC and other guys, we validated the Linus's tip which includes
> your patches. It actually doesn't break anything and as OMAP hsmmc maintainer
> clarified, the cd-gpios isn't supported yet for DT. While supporting that it
> can use appropriate binding whichever works.
>
> But with OMAP1 breakage reported by Paul, I think we are not left with choice
> but to revert those commits. We *must* respect rc rules for the fixes.
> *No regression*
>
> Thanks for your hardwork to cook up those patches but now Linus's W proposal
> is going to be generic, hopefully the issue can be address better. Till
> then we can't get the ethernet support.

The problem never was just the omap_hsmmc driver. I rather would say all 
drivers which do use GPIOs as IRQs were affected.

I've only used the omap_hsmmc driver as example, because that was the 
driver I've tried to actually use with sd-cards, which is rather 
impossible without having a working CD-signal. And all code was already 
there and seems to work (at least during my few tests), so I've just 
added an entry to the dts to be able to use a mmc-slot as one would 
expect a mmc-slot does work.

If someone wants to test a new feature at the same front, I would 
suggest to try it out using gpio-keys. That driver should work on almost 
any architecture/platform/hardware which supports gpios and is small 
enough to be a good test candidate. Having had a short look at 
gpio-keys.c, I think the same problems as with omap_hsmmc would have 
been occured when someone had tried to use that driver with 3.11-rc2.

Regards,

Alexander Holler



From thomas.petazzoni at free-electrons.com  Mon Jul 29 11:05:08 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 29 Jul 2013 17:05:08 +0200
Subject: [PATCH 0/2] dma: mv_xor: big endian support
Message-ID: <1375110310-26276-1-git-send-email-thomas.petazzoni@free-electrons.com>

Vinod, Dan,

This small set of patches adds support for big endian operation in the
DMA mv_xor driver. It has been tested in both little-endian and
big-endian modes on the Armada XP GP board.

If possible, I'd like those to be merged for 3.12.

Thanks!

Thomas

Thomas Petazzoni (2):
  dma: mv_xor: use readl/writel instead of __raw_{readl,writel}
  dma: mv_xor: support big endian systems using descriptor swap feature

 drivers/dma/mv_xor.c | 47 +++++++++++++++++++++++++++--------------------
 drivers/dma/mv_xor.h | 28 +++++++++++++++++++++++++++-
 2 files changed, 54 insertions(+), 21 deletions(-)

-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 29 11:05:09 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 29 Jul 2013 17:05:09 +0200
Subject: [PATCH 1/2] dma: mv_xor: use readl/writel instead of __raw_{readl,
 writel}
In-Reply-To: <1375110310-26276-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1375110310-26276-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1375110310-26276-2-git-send-email-thomas.petazzoni@free-electrons.com>

In order to support big-endian execution, the mv_xor driver is changed
to use thhe readl() and writel() accessors that properly convert from
the CPU endianess to the device endianess (which in the case of
Marvell XOR hardware is always little-endian).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/dma/mv_xor.c | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index 200f1a3..e98966a 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -114,25 +114,25 @@ static void mv_desc_set_src_addr(struct mv_xor_desc_slot *desc,
 
 static u32 mv_chan_get_current_desc(struct mv_xor_chan *chan)
 {
-	return __raw_readl(XOR_CURR_DESC(chan));
+	return readl(XOR_CURR_DESC(chan));
 }
 
 static void mv_chan_set_next_descriptor(struct mv_xor_chan *chan,
 					u32 next_desc_addr)
 {
-	__raw_writel(next_desc_addr, XOR_NEXT_DESC(chan));
+	writel(next_desc_addr, XOR_NEXT_DESC(chan));
 }
 
 static void mv_chan_unmask_interrupts(struct mv_xor_chan *chan)
 {
-	u32 val = __raw_readl(XOR_INTR_MASK(chan));
+	u32 val = readl(XOR_INTR_MASK(chan));
 	val |= XOR_INTR_MASK_VALUE << (chan->idx * 16);
-	__raw_writel(val, XOR_INTR_MASK(chan));
+	writel(val, XOR_INTR_MASK(chan));
 }
 
 static u32 mv_chan_get_intr_cause(struct mv_xor_chan *chan)
 {
-	u32 intr_cause = __raw_readl(XOR_INTR_CAUSE(chan));
+	u32 intr_cause = readl(XOR_INTR_CAUSE(chan));
 	intr_cause = (intr_cause >> (chan->idx * 16)) & 0xFFFF;
 	return intr_cause;
 }
@@ -149,13 +149,13 @@ static void mv_xor_device_clear_eoc_cause(struct mv_xor_chan *chan)
 {
 	u32 val = ~(1 << (chan->idx * 16));
 	dev_dbg(mv_chan_to_devp(chan), "%s, val 0x%08x\n", __func__, val);
-	__raw_writel(val, XOR_INTR_CAUSE(chan));
+	writel(val, XOR_INTR_CAUSE(chan));
 }
 
 static void mv_xor_device_clear_err_status(struct mv_xor_chan *chan)
 {
 	u32 val = 0xFFFF0000 >> (chan->idx * 16);
-	__raw_writel(val, XOR_INTR_CAUSE(chan));
+	writel(val, XOR_INTR_CAUSE(chan));
 }
 
 static int mv_can_chain(struct mv_xor_desc_slot *desc)
@@ -173,7 +173,7 @@ static void mv_set_mode(struct mv_xor_chan *chan,
 			       enum dma_transaction_type type)
 {
 	u32 op_mode;
-	u32 config = __raw_readl(XOR_CONFIG(chan));
+	u32 config = readl(XOR_CONFIG(chan));
 
 	switch (type) {
 	case DMA_XOR:
@@ -192,7 +192,7 @@ static void mv_set_mode(struct mv_xor_chan *chan,
 
 	config &= ~0x7;
 	config |= op_mode;
-	__raw_writel(config, XOR_CONFIG(chan));
+	writel(config, XOR_CONFIG(chan));
 	chan->current_type = type;
 }
 
@@ -201,14 +201,14 @@ static void mv_chan_activate(struct mv_xor_chan *chan)
 	u32 activation;
 
 	dev_dbg(mv_chan_to_devp(chan), " activate chan.\n");
-	activation = __raw_readl(XOR_ACTIVATION(chan));
+	activation = readl(XOR_ACTIVATION(chan));
 	activation |= 0x1;
-	__raw_writel(activation, XOR_ACTIVATION(chan));
+	writel(activation, XOR_ACTIVATION(chan));
 }
 
 static char mv_chan_is_busy(struct mv_xor_chan *chan)
 {
-	u32 state = __raw_readl(XOR_ACTIVATION(chan));
+	u32 state = readl(XOR_ACTIVATION(chan));
 
 	state = (state >> 4) & 0x3;
 
@@ -755,22 +755,22 @@ static void mv_dump_xor_regs(struct mv_xor_chan *chan)
 {
 	u32 val;
 
-	val = __raw_readl(XOR_CONFIG(chan));
+	val = readl(XOR_CONFIG(chan));
 	dev_err(mv_chan_to_devp(chan), "config       0x%08x\n", val);
 
-	val = __raw_readl(XOR_ACTIVATION(chan));
+	val = readl(XOR_ACTIVATION(chan));
 	dev_err(mv_chan_to_devp(chan), "activation   0x%08x\n", val);
 
-	val = __raw_readl(XOR_INTR_CAUSE(chan));
+	val = readl(XOR_INTR_CAUSE(chan));
 	dev_err(mv_chan_to_devp(chan), "intr cause   0x%08x\n", val);
 
-	val = __raw_readl(XOR_INTR_MASK(chan));
+	val = readl(XOR_INTR_MASK(chan));
 	dev_err(mv_chan_to_devp(chan), "intr mask    0x%08x\n", val);
 
-	val = __raw_readl(XOR_ERROR_CAUSE(chan));
+	val = readl(XOR_ERROR_CAUSE(chan));
 	dev_err(mv_chan_to_devp(chan), "error cause  0x%08x\n", val);
 
-	val = __raw_readl(XOR_ERROR_ADDR(chan));
+	val = readl(XOR_ERROR_ADDR(chan));
 	dev_err(mv_chan_to_devp(chan), "error addr   0x%08x\n", val);
 }
 
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 29 11:05:10 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 29 Jul 2013 17:05:10 +0200
Subject: [PATCH 2/2] dma: mv_xor: support big endian systems using descriptor
 swap feature
In-Reply-To: <1375110310-26276-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1375110310-26276-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1375110310-26276-3-git-send-email-thomas.petazzoni@free-electrons.com>

The mv_xor driver had never been used in a big-endian context, and
therefore was not using the hardware features to support such an
execution environment. The hardware provides a "descriptor swap" bit
that automatically swaps the bytes of the DMA descriptors, within
blocks of 8 bytes. This requires a different DMA descriptor layout on
big-endian systems, as well as enabling this "descriptor swap" bit.

This mechanism is exactly identical to the one already used in the
mv643xx_eth network driver and the mvneta network driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/dma/mv_xor.c | 11 +++++++++--
 drivers/dma/mv_xor.h | 28 +++++++++++++++++++++++++++-
 2 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index e98966a..fc4d0e9 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -64,7 +64,7 @@ static u32 mv_desc_get_src_addr(struct mv_xor_desc_slot *desc,
 				int src_idx)
 {
 	struct mv_xor_desc *hw_desc = desc->hw_desc;
-	return hw_desc->phy_src_addr[src_idx];
+	return hw_desc->phy_src_addr[mv_phy_src_idx(src_idx)];
 }
 
 
@@ -107,7 +107,7 @@ static void mv_desc_set_src_addr(struct mv_xor_desc_slot *desc,
 				 int index, dma_addr_t addr)
 {
 	struct mv_xor_desc *hw_desc = desc->hw_desc;
-	hw_desc->phy_src_addr[index] = addr;
+	hw_desc->phy_src_addr[mv_phy_src_idx(index)] = addr;
 	if (desc->type == DMA_XOR)
 		hw_desc->desc_command |= (1 << index);
 }
@@ -192,6 +192,13 @@ static void mv_set_mode(struct mv_xor_chan *chan,
 
 	config &= ~0x7;
 	config |= op_mode;
+
+#if defined(__BIG_ENDIAN)
+	config |= XOR_DESCRIPTOR_SWAP;
+#else
+	config &= ~XOR_DESCRIPTOR_SWAP;
+#endif
+
 	writel(config, XOR_CONFIG(chan));
 	chan->current_type = type;
 }
diff --git a/drivers/dma/mv_xor.h b/drivers/dma/mv_xor.h
index c619359..06b067f 100644
--- a/drivers/dma/mv_xor.h
+++ b/drivers/dma/mv_xor.h
@@ -29,8 +29,10 @@
 #define MV_XOR_THRESHOLD		1
 #define MV_XOR_MAX_CHANNELS             2
 
+/* Values for the XOR_CONFIG register */
 #define XOR_OPERATION_MODE_XOR		0
 #define XOR_OPERATION_MODE_MEMCPY	2
+#define XOR_DESCRIPTOR_SWAP		BIT(14)
 
 #define XOR_CURR_DESC(chan)	(chan->mmr_base + 0x210 + (chan->idx * 4))
 #define XOR_NEXT_DESC(chan)	(chan->mmr_base + 0x200 + (chan->idx * 4))
@@ -143,7 +145,16 @@ struct mv_xor_desc_slot {
 #endif
 };
 
-/* This structure describes XOR descriptor size 64bytes	*/
+/*
+ * This structure describes XOR descriptor size 64bytes. The
+ * mv_phy_src_idx() macro must be used when indexing the values of the
+ * phy_src_addr[] array. This is due to the fact that the 'descriptor
+ * swap' feature, used on big endian systems, swaps descriptors data
+ * within blocks of 8 bytes. So two consecutive values of the
+ * phy_src_addr[] array are actually swapped in big-endian, which
+ * explains the different mv_phy_src_idx() implementation.
+ */
+#if defined(__LITTLE_ENDIAN)
 struct mv_xor_desc {
 	u32 status;		/* descriptor execution status */
 	u32 crc32_result;	/* result of CRC-32 calculation */
@@ -155,6 +166,21 @@ struct mv_xor_desc {
 	u32 reserved0;
 	u32 reserved1;
 };
+#define mv_phy_src_idx(src_idx) (src_idx)
+#else
+struct mv_xor_desc {
+	u32 crc32_result;	/* result of CRC-32 calculation */
+	u32 status;		/* descriptor execution status */
+	u32 phy_next_desc;	/* next descriptor address pointer */
+	u32 desc_command;	/* type of operation to be carried out */
+	u32 phy_dest_addr;	/* destination block address */
+	u32 byte_count;		/* size of src/dst blocks in bytes */
+	u32 phy_src_addr[8];	/* source block addresses */
+	u32 reserved1;
+	u32 reserved0;
+};
+#define mv_phy_src_idx(src_idx) (src_idx ^ 1)
+#endif
 
 #define to_mv_sw_desc(addr_hw_desc)		\
 	container_of(addr_hw_desc, struct mv_xor_desc_slot, hw_desc)
-- 
1.8.1.2



From santosh.shilimkar at ti.com  Mon Jul 29 11:06:26 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 29 Jul 2013 11:06:26 -0400
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping
 for every GPIO on DT"
In-Reply-To: <51F681C4.3000400@ahsoftware.de>
References: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
 <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
 <51F633AE.8090308@collabora.co.uk> <51F63864.9000601@collabora.co.uk>
 <51F666B7.7020209@ti.com> <51F681C4.3000400@ahsoftware.de>
Message-ID: <51F684F2.5050308@ti.com>

On Monday 29 July 2013 10:52 AM, Alexander Holler wrote:
> Am 29.07.2013 14:57, schrieb Santosh Shilimkar:
> 
>> With some helps from MMC and other guys, we validated the Linus's tip which includes
>> your patches. It actually doesn't break anything and as OMAP hsmmc maintainer
>> clarified, the cd-gpios isn't supported yet for DT. While supporting that it
>> can use appropriate binding whichever works.
>>
>> But with OMAP1 breakage reported by Paul, I think we are not left with choice
>> but to revert those commits. We *must* respect rc rules for the fixes.
>> *No regression*
>>
>> Thanks for your hardwork to cook up those patches but now Linus's W proposal
>> is going to be generic, hopefully the issue can be address better. Till
>> then we can't get the ethernet support.
> 
> The problem never was just the omap_hsmmc driver. I rather would say all drivers which do use GPIOs as IRQs were affected.
> 
> I've only used the omap_hsmmc driver as example, because that was the driver I've tried to actually use with sd-cards, which is rather impossible without having a working CD-signal. And all code was already there and seems to work (at least during my few tests), so I've just added an entry to the dts to be able to use a mmc-slot as one would expect a mmc-slot does work.
> 
> If someone wants to test a new feature at the same front, I would suggest to try it out using gpio-keys. That driver should work on almost any architecture/platform/hardware which supports gpios and is small enough to be a good test candidate. Having had a short look at gpio-keys.c, I think the same problems as with omap_hsmmc would have been occured when someone had tried to use that driver with 3.11-rc2.
> 
The 3 OMAP platforms which supports DT are AM33XX, OMAP4 and OMAP5.
OMAP3 based boards are getting converted but they are bit far from being
DT only. So my statement was again from what we support on mainline today
and those platform don't use gpio-keys. But for testing perspective,
I guess its good idea.

As mentioned above, we are going ahead with revert and possible better
alternative to the root of the problem.

Regards,
Santosh
P.S: Please sensibly wrap your email replies to 80 chars so that
people can read it without scrolling to the end of the line.

Regards,
Santosh






From balbi at ti.com  Mon Jul 29 11:06:38 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 29 Jul 2013 18:06:38 +0300
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given in
 usb_bind_phy
In-Reply-To: <1374829418-27503-3-git-send-email-kishon@ti.com>
References: <1374829418-27503-1-git-send-email-kishon@ti.com>
 <1374829418-27503-3-git-send-email-kishon@ti.com>
Message-ID: <20130729150638.GD3063@radagast>

Hi,

On Fri, Jul 26, 2013 at 02:33:38PM +0530, Kishon Vijay Abraham I wrote:
> Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while creating
> MUSB core device. So in usb_bind_phy (binds the controller with the PHY), the
> device name of the controller had *.auto* in it. Since with using
> PLATFORM_DEVID_AUTO, there is no way to know the exact device name in advance,
> the data given in usb_bind_phy became obsolete and usb_get_phy was failing.
> So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO. Corresponding
> change is done in board file here.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> ---
>  arch/arm/mach-omap2/board-2430sdp.c          |    2 +-
>  arch/arm/mach-omap2/board-3430sdp.c          |    2 +-
>  arch/arm/mach-omap2/board-cm-t35.c           |    2 +-
>  arch/arm/mach-omap2/board-devkit8000.c       |    2 +-
>  arch/arm/mach-omap2/board-igep0020.c         |    2 +-
>  arch/arm/mach-omap2/board-ldp.c              |    2 +-
>  arch/arm/mach-omap2/board-omap3beagle.c      |    2 +-
>  arch/arm/mach-omap2/board-omap3evm.c         |    2 +-
>  arch/arm/mach-omap2/board-omap3logic.c       |    2 +-
>  arch/arm/mach-omap2/board-omap3pandora.c     |    2 +-
>  arch/arm/mach-omap2/board-omap3stalker.c     |    2 +-
>  arch/arm/mach-omap2/board-omap3touchbook.c   |    2 +-
>  arch/arm/mach-omap2/board-overo.c            |    2 +-
>  arch/arm/mach-omap2/board-rm680.c            |    2 +-
>  arch/arm/mach-omap2/board-rx51.c             |    2 +-
>  arch/arm/mach-omap2/board-zoom-peripherals.c |    2 +-
>  16 files changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
> index 244d8a5..17bb076 100644
> --- a/arch/arm/mach-omap2/board-2430sdp.c
> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> @@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
>  	omap_hsmmc_init(mmc);
>  
>  	omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
> -	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
> +	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");

how about moving usb_bind_phy() calls to omap2430.c ?

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..b6abc1a 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device *pdev)
 
 		pdata->board_data	= data;
 		pdata->config		= config;
+	} else {
+		/* bind the PHY */
+		usb_bind_phy(dev_name(&musb->dev), 0, "twl4030_usb");
 	}
 
 	if (pdata->has_mailbox) {

The only problem is if some board comes with a PHY other than
twl4030_usb, but in that case we can add a separate compatible flag and
treat it properly. We only need to bind the phy in non-DT case anyway,
so that's temporary. It might be better than to reintroduce the IDR in
musb_core.c.

-- 
balbi
-------------- 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/20130729/a53c525b/attachment-0001.sig>

From linux at arm.linux.org.uk  Mon Jul 29 11:08:27 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 29 Jul 2013 16:08:27 +0100
Subject: [PATCH 1/2] dma: mv_xor: use readl/writel instead of
 __raw_{readl, writel}
In-Reply-To: <1375110310-26276-2-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1375110310-26276-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1375110310-26276-2-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130729150827.GL24642@n2100.arm.linux.org.uk>

On Mon, Jul 29, 2013 at 05:05:09PM +0200, Thomas Petazzoni wrote:
> In order to support big-endian execution, the mv_xor driver is changed
> to use thhe readl() and writel() accessors that properly convert from
> the CPU endianess to the device endianess (which in the case of
> Marvell XOR hardware is always little-endian).

Is it necessary that all these be barrier-ied IO operations?


From richard.genoud at gmail.com  Mon Jul 29 11:09:43 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Mon, 29 Jul 2013 17:09:43 +0200
Subject: [PATCH v2 00/42] ARM: at91: move to common clk framework
In-Reply-To: <51F67D7F.1050906@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <51F28370.6050304@gmail.com> <51F2996B.6000406@overkiz.com>
 <51F2A556.8020109@overkiz.com>
 <CACQ1gAgw-v3z_sWcsk7SqFFW-ERLjS0RS5GTgAdd5Y1tj3Z1FA@mail.gmail.com>
 <51F63516.8090000@overkiz.com>
 <CACQ1gAi53KN=zE8zDxQO=+BY2zvQXakD=OSuzUqc0VLwWLySCA@mail.gmail.com>
 <51F67D7F.1050906@overkiz.com>
Message-ID: <CACQ1gAirPir5vCyeK7OKHjw806Sv_LTiorDAp5mvhObxNTE3FA@mail.gmail.com>

2013/7/29 boris brezillon <b.brezillon at overkiz.com>:
> On 29/07/2013 16:18, Richard Genoud wrote:
>>
>> 2013/7/29 boris brezillon <b.brezillon at overkiz.com>:
>>>
>>> On 29/07/2013 10:00, Richard Genoud wrote:
>>>>
>>>> 2013/7/26 boris brezillon <b.brezillon at overkiz.com>:
>>>>>
>>>>> On 26/07/2013 17:44, boris brezillon wrote:
>>>>> I found 2 bugs:
>>>>> 1) the main frequency ready test in recalc_rate function is wrong
>>>>> 2) the common clk framework uses the first match for dt clk
>>>>> registration
>>>>>      and main clk has this compatible property:
>>>>>      compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
>>>>>      As a result the main clk is always bound to the fixed-clock driver
>>>>>      which set the clock frequency to 0 if 'clock-frequency' property
>>>>> is
>>>>>      missing.
>>>>>
>>>>> These bugs will be fixed in next version.
>>>>> Tell me if you want need thesse patches for testing purpose.
>>>>
>>>> Hi Boris,
>>>>
>>>> I tested your patch, the clock is not at 0 anymore:
>>>> AT91: PIT: mck rate = 8333333
>>>>
>>>> And it's booting correctly.
>>>> There's a small bug I found in the at91sam9x5 dtsi file (ssc id is 28,
>>>> not 27). (patch attached)
>>>>
>>>> And yes, I could use your patches for some more tests !
>>>>
>>>> Thanks,
>>>>
>>>> Richard.
>>>
>>> Hi Richard,
>>>
>>> Thanks for the bug report.
>>>
>>> You'll find in attachements the pre-v3 series fixing the detected bugs
>>> (including the ssc clock id bug).
>>>
>>> If you need anything else please let me know.
>>
>> Working on sam9g35ek !
>> you can add my:
>> Tested-by: Richard Genoud <richard.genoud at gmail.com>
>>
>>
>> One remark though:
>> Maybe it would be interesting to keep using the defines in the device
>> tree for peripheral IDs.
>> For instance, in arch/arm/boot/dts/at91sam9x5.dtsi : (patch 33)
>> ssc_clk at 28 {
>>         id = <28>;
>> };
>> May be more readable with the SSC id AT91SAM9X5_ID_SSC, as it was
>> defined in arch/arm/mach-at91/at91sam9x5.c (removed with patch 20)
>>
>> IMHO, all AT91SAM9X5_ID_xxx in
>> arch/arm/mach-at91/include/mach/at91sam9x5.h can me moved in
>> include/dt-bindings/ and used in at91sam9x5.dtsi
>
> This was requested by Jean-Christophe too.
> I'll add these macro files and make use of it in next version.
>
> BTW where should I put these macro files
> (include/dt-bindings/at91/'soc-name'/peripherals.h) ?
That sounds correct I suppose.
> Should I use macros for address fied of clocks or just for id property (or
> drop the address) ?
>
> ssc_clk at AT91SAM9X5_ID_SSC {
>         id = <AT91SAM9X5_ID_SSC>;
> };
>
> or
>
> ssc_clk at 28 {
>         id = <AT91SAM9X5_ID_SSC>;
> };
>
> or
>
> ssc_clk {
>         id = <AT91SAM9X5_ID_SSC>;
> };
I would drop the address, since the names are always different (for
instance, dma0_clk and dma1_clk are used).
And the define should also be used here:
ssc0: ssc at f0010000 { [...]
clocks = <&periph AT91SAM9X5_ID_SSC>;
[...]
}


From thomas.petazzoni at free-electrons.com  Mon Jul 29 11:14:26 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 29 Jul 2013 17:14:26 +0200
Subject: [PATCH 1/2] dma: mv_xor: use readl/writel instead of
 __raw_{readl, writel}
In-Reply-To: <20130729150827.GL24642@n2100.arm.linux.org.uk>
References: <1375110310-26276-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1375110310-26276-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130729150827.GL24642@n2100.arm.linux.org.uk>
Message-ID: <20130729171426.4bbd320c@skate>

Dear Russell King - ARM Linux,

On Mon, 29 Jul 2013 16:08:27 +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 29, 2013 at 05:05:09PM +0200, Thomas Petazzoni wrote:
> > In order to support big-endian execution, the mv_xor driver is changed
> > to use thhe readl() and writel() accessors that properly convert from
> > the CPU endianess to the device endianess (which in the case of
> > Marvell XOR hardware is always little-endian).
> 
> Is it necessary that all these be barrier-ied IO operations?

As they used to be __raw_..., I presume that those barrier-ied
operations are not strictly needed, so I could use the relaxed
variants instead.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From b.brezillon at overkiz.com  Mon Jul 29 11:14:26 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Mon, 29 Jul 2013 17:14:26 +0200
Subject: [PATCH v2 00/42] ARM: at91: move to common clk framework
In-Reply-To: <CACQ1gAirPir5vCyeK7OKHjw806Sv_LTiorDAp5mvhObxNTE3FA@mail.gmail.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <51F28370.6050304@gmail.com> <51F2996B.6000406@overkiz.com>
 <51F2A556.8020109@overkiz.com>
 <CACQ1gAgw-v3z_sWcsk7SqFFW-ERLjS0RS5GTgAdd5Y1tj3Z1FA@mail.gmail.com>
 <51F63516.8090000@overkiz.com>
 <CACQ1gAi53KN=zE8zDxQO=+BY2zvQXakD=OSuzUqc0VLwWLySCA@mail.gmail.com>
 <51F67D7F.1050906@overkiz.com>
 <CACQ1gAirPir5vCyeK7OKHjw806Sv_LTiorDAp5mvhObxNTE3FA@mail.gmail.com>
Message-ID: <51F686D2.3020104@overkiz.com>

On 29/07/2013 17:09, Richard Genoud wrote:
> 2013/7/29 boris brezillon <b.brezillon at overkiz.com>:
>> On 29/07/2013 16:18, Richard Genoud wrote:
>>> 2013/7/29 boris brezillon <b.brezillon at overkiz.com>:
>>>> On 29/07/2013 10:00, Richard Genoud wrote:
>>>>> 2013/7/26 boris brezillon <b.brezillon at overkiz.com>:
>>>>>> On 26/07/2013 17:44, boris brezillon wrote:
>>>>>> I found 2 bugs:
>>>>>> 1) the main frequency ready test in recalc_rate function is wrong
>>>>>> 2) the common clk framework uses the first match for dt clk
>>>>>> registration
>>>>>>       and main clk has this compatible property:
>>>>>>       compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
>>>>>>       As a result the main clk is always bound to the fixed-clock driver
>>>>>>       which set the clock frequency to 0 if 'clock-frequency' property
>>>>>> is
>>>>>>       missing.
>>>>>>
>>>>>> These bugs will be fixed in next version.
>>>>>> Tell me if you want need thesse patches for testing purpose.
>>>>> Hi Boris,
>>>>>
>>>>> I tested your patch, the clock is not at 0 anymore:
>>>>> AT91: PIT: mck rate = 8333333
>>>>>
>>>>> And it's booting correctly.
>>>>> There's a small bug I found in the at91sam9x5 dtsi file (ssc id is 28,
>>>>> not 27). (patch attached)
>>>>>
>>>>> And yes, I could use your patches for some more tests !
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Richard.
>>>> Hi Richard,
>>>>
>>>> Thanks for the bug report.
>>>>
>>>> You'll find in attachements the pre-v3 series fixing the detected bugs
>>>> (including the ssc clock id bug).
>>>>
>>>> If you need anything else please let me know.
>>> Working on sam9g35ek !
>>> you can add my:
>>> Tested-by: Richard Genoud <richard.genoud at gmail.com>
>>>
>>>
>>> One remark though:
>>> Maybe it would be interesting to keep using the defines in the device
>>> tree for peripheral IDs.
>>> For instance, in arch/arm/boot/dts/at91sam9x5.dtsi : (patch 33)
>>> ssc_clk at 28 {
>>>          id = <28>;
>>> };
>>> May be more readable with the SSC id AT91SAM9X5_ID_SSC, as it was
>>> defined in arch/arm/mach-at91/at91sam9x5.c (removed with patch 20)
>>>
>>> IMHO, all AT91SAM9X5_ID_xxx in
>>> arch/arm/mach-at91/include/mach/at91sam9x5.h can me moved in
>>> include/dt-bindings/ and used in at91sam9x5.dtsi
>> This was requested by Jean-Christophe too.
>> I'll add these macro files and make use of it in next version.
>>
>> BTW where should I put these macro files
>> (include/dt-bindings/at91/'soc-name'/peripherals.h) ?
> That sounds correct I suppose.
Ok, I will use this path pattern.
>> Should I use macros for address fied of clocks or just for id property (or
>> drop the address) ?
>>
>> ssc_clk at AT91SAM9X5_ID_SSC {
>>          id = <AT91SAM9X5_ID_SSC>;
>> };
>>
>> or
>>
>> ssc_clk at 28 {
>>          id = <AT91SAM9X5_ID_SSC>;
>> };
>>
>> or
>>
>> ssc_clk {
>>          id = <AT91SAM9X5_ID_SSC>;
>> };
> I would drop the address, since the names are always different (for
> instance, dma0_clk and dma1_clk are used).
Ok, I'll drop the address.
> And the define should also be used here:
> ssc0: ssc at f0010000 { [...]
> clocks = <&periph AT91SAM9X5_ID_SSC>;
> [...]
> }
Yes of course, and it should be used for interrupt ids too (but this 
will not be part of this series :)).

Thanks for your review.

Best Regards,

Boris


From holler at ahsoftware.de  Mon Jul 29 11:18:11 2013
From: holler at ahsoftware.de (Alexander Holler)
Date: Mon, 29 Jul 2013 17:18:11 +0200
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping
 for every GPIO on DT"
In-Reply-To: <51F684F2.5050308@ti.com>
References: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
 <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
 <51F633AE.8090308@collabora.co.uk> <51F63864.9000601@collabora.co.uk>
 <51F666B7.7020209@ti.com> <51F681C4.3000400@ahsoftware.de>
 <51F684F2.5050308@ti.com>
Message-ID: <51F687B3.7030902@ahsoftware.de>

Am 29.07.2013 17:06, schrieb Santosh Shilimkar:
> On Monday 29 July 2013 10:52 AM, Alexander Holler wrote:
>> Am 29.07.2013 14:57, schrieb Santosh Shilimkar:
>>
>>> With some helps from MMC and other guys, we validated the Linus's tip which includes
>>> your patches. It actually doesn't break anything and as OMAP hsmmc maintainer
>>> clarified, the cd-gpios isn't supported yet for DT. While supporting that it
>>> can use appropriate binding whichever works.
>>>
>>> But with OMAP1 breakage reported by Paul, I think we are not left with choice
>>> but to revert those commits. We *must* respect rc rules for the fixes.
>>> *No regression*
>>>
>>> Thanks for your hardwork to cook up those patches but now Linus's W proposal
>>> is going to be generic, hopefully the issue can be address better. Till
>>> then we can't get the ethernet support.
>>
>> The problem never was just the omap_hsmmc driver. I rather would say all drivers which do use GPIOs as IRQs were affected.
>>
>> I've only used the omap_hsmmc driver as example, because that was the driver I've tried to actually use with sd-cards, which is rather impossible without having a working CD-signal. And all code was already there and seems to work (at least during my few tests), so I've just added an entry to the dts to be able to use a mmc-slot as one would expect a mmc-slot does work.
>>
>> If someone wants to test a new feature at the same front, I would suggest to try it out using gpio-keys. That driver should work on almost any architecture/platform/hardware which supports gpios and is small enough to be a good test candidate. Having had a short look at gpio-keys.c, I think the same problems as with omap_hsmmc would have been occured when someone had tried to use that driver with 3.11-rc2.
>>
> The 3 OMAP platforms which supports DT are AM33XX, OMAP4 and OMAP5.
> OMAP3 based boards are getting converted but they are bit far from being
> DT only. So my statement was again from what we support on mainline today
> and those platform don't use gpio-keys. But for testing perspective,
> I guess its good idea.
>

I wonder how you do know that no board with OMAP chips does use gpio-keys?

Does TI restrict their users/customers to only certified drivers? ;)


> As mentioned above, we are going ahead with revert and possible better
> alternative to the root of the problem.
>
> Regards,
> Santosh
> P.S: Please sensibly wrap your email replies to 80 chars so that
> people can read it without scrolling to the end of the line.

Line-wrapping mail readers do exist since some decades and I believe 
people should be able to read e-mails with whatever line width they 
prefer (and NOT what I prefer). So I never will hard-limit mails to some 
specific line width on my side (besides from patch). That's just a very 
bad behaviour.

Regards,

Alexander Holler



From santosh.shilimkar at ti.com  Mon Jul 29 11:23:01 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Mon, 29 Jul 2013 11:23:01 -0400
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping
 for every GPIO on DT"
In-Reply-To: <51F687B3.7030902@ahsoftware.de>
References: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
 <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
 <51F633AE.8090308@collabora.co.uk> <51F63864.9000601@collabora.co.uk>
 <51F666B7.7020209@ti.com> <51F681C4.3000400@ahsoftware.de>
 <51F684F2.5050308@ti.com> <51F687B3.7030902@ahsoftware.de>
Message-ID: <51F688D5.4050501@ti.com>

On Monday 29 July 2013 11:18 AM, Alexander Holler wrote:
> Am 29.07.2013 17:06, schrieb Santosh Shilimkar:
>> On Monday 29 July 2013 10:52 AM, Alexander Holler wrote:
>>> Am 29.07.2013 14:57, schrieb Santosh Shilimkar:
>>>
>>>> With some helps from MMC and other guys, we validated the Linus's tip which includes
>>>> your patches. It actually doesn't break anything and as OMAP hsmmc maintainer
>>>> clarified, the cd-gpios isn't supported yet for DT. While supporting that it
>>>> can use appropriate binding whichever works.
>>>>
>>>> But with OMAP1 breakage reported by Paul, I think we are not left with choice
>>>> but to revert those commits. We *must* respect rc rules for the fixes.
>>>> *No regression*
>>>>
>>>> Thanks for your hardwork to cook up those patches but now Linus's W proposal
>>>> is going to be generic, hopefully the issue can be address better. Till
>>>> then we can't get the ethernet support.
>>>
>>> The problem never was just the omap_hsmmc driver. I rather would say all drivers which do use GPIOs as IRQs were affected.
>>>
>>> I've only used the omap_hsmmc driver as example, because that was the driver I've tried to actually use with sd-cards, which is rather impossible without having a working CD-signal. And all code was already there and seems to work (at least during my few tests), so I've just added an entry to the dts to be able to use a mmc-slot as one would expect a mmc-slot does work.
>>>
>>> If someone wants to test a new feature at the same front, I would suggest to try it out using gpio-keys. That driver should work on almost any architecture/platform/hardware which supports gpios and is small enough to be a good test candidate. Having had a short look at gpio-keys.c, I think the same problems as with omap_hsmmc would have been occured when someone had tried to use that driver with 3.11-rc2.
>>>
>> The 3 OMAP platforms which supports DT are AM33XX, OMAP4 and OMAP5.
>> OMAP3 based boards are getting converted but they are bit far from being
>> DT only. So my statement was again from what we support on mainline today
>> and those platform don't use gpio-keys. But for testing perspective,
>> I guess its good idea.
>>
> 
> I wonder how you do know that no board with OMAP chips does use gpio-keys?
> 
> Does TI restrict their users/customers to only certified drivers? ;)
> 
I just grep on kernel.org tree and my comment was restricted to what
is current state in mainline for DT. I never said it can't be used or
no board is using it. Sorry if i was not clear enough.

Regards,
Santosh


From linus.walleij at linaro.org  Mon Jul 29 11:26:32 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 Jul 2013 17:26:32 +0200
Subject: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping
 for every GPIO on DT"
In-Reply-To: <798C2D39-EE8E-4C73-A98D-63231375599C@collabora.co.uk>
References: <alpine.DEB.2.02.1307290604310.30864@utopia.booyaka.com>
 <CACRpkdYa8Kg_-u3gB8jrB_Ws2EpLCnXBh5UGgDvi_7tQspDP7A@mail.gmail.com>
 <51F633AE.8090308@collabora.co.uk>
 <alpine.DEB.2.02.1307290943000.30864@utopia.booyaka.com>
 <D135FD6D-D4B6-4237-9866-4FFED36C03CD@collabora.co.uk>
 <CACRpkdZ1E9zC_yyK=UkJSejCwb_k7sYfhNgH5NASZ8Nf-qt2KA@mail.gmail.com>
 <798C2D39-EE8E-4C73-A98D-63231375599C@collabora.co.uk>
Message-ID: <CACRpkdakWmF4cgAXQMCP04cY+QmqXT9puxmmZ3G4PB9Wj_p8Pg@mail.gmail.com>

On Mon, Jul 29, 2013 at 2:40 PM, Javier Martinez Canillas
<javier.martinez at collabora.co.uk> wrote:
> On 29/07/2013, at 13:43, Linus Walleij <linus.walleij at linaro.org> wrote:

>> So I'm drafting an RFC to indicate how I think this should
>> be solved.
>>
>
> Great, I hope we can finally have a good solution for this long standing issue.

I have sent out this RFC patch, subject:
"RFC: interrupt consistency check for OF GPIO IRQs"

Please review the general concept of this patch and whether
it would help solving the OMAP situation for v3.12.

The patch as it stands will not work, and I cannot create a
proper test here because I have no test target system
(I am technically on vacation), but I will get to it as I get back.

And folks: you shouldn't feel bad about this. The problem is
not OMAPs at all, the problem has been there all the time
and we have discussed it for some time, it just happened that
OMAP was the first system that tried to come up with some
kind of fix for it, and for this you should be thanked, even if
we need to take another path in the end.

Yours,
Linus Walleij


From k.debski at samsung.com  Mon Jul 29 11:28:18 2013
From: k.debski at samsung.com (Kamil Debski)
Date: Mon, 29 Jul 2013 17:28:18 +0200
Subject: [RESEND PATCH v10 1/8] drivers: phy: add generic PHY framework
In-Reply-To: <1374842963-13545-2-git-send-email-kishon@ti.com>
References: <1374842963-13545-1-git-send-email-kishon@ti.com>
 <1374842963-13545-2-git-send-email-kishon@ti.com>
Message-ID: <023801ce8c70$427cbd20$c7763760$%debski@samsung.com>

Hi Kishon,

A small fix follows inline.

> From: linux-media-owner at vger.kernel.org [mailto:linux-media-
> owner at vger.kernel.org] On Behalf Of Kishon Vijay Abraham I
> Sent: Friday, July 26, 2013 2:49 PM
> 
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference
> to the PHY with or without using phandle. For dt-boot, the PHY drivers
> should also register *PHY provider* with the framework.
> 
> PHY drivers should create the PHY by passing id and ops like init, exit,
> power_on and power_off. This framework is also pm runtime enabled.
> 
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for dt binding can be found
> at Documentation/devicetree/bindings/phy/phy-bindings.txt
> 
> Cc: Tomasz Figa <t.figa at samsung.com>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> Acked-by: Felipe Balbi <balbi at ti.com>
> Tested-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> ---
>  .../devicetree/bindings/phy/phy-bindings.txt       |   66 ++
>  Documentation/phy.txt                              |  166 +++++
>  MAINTAINERS                                        |    8 +
>  drivers/Kconfig                                    |    2 +
>  drivers/Makefile                                   |    2 +
>  drivers/phy/Kconfig                                |   18 +
>  drivers/phy/Makefile                               |    5 +
>  drivers/phy/phy-core.c                             |  714
> ++++++++++++++++++++
>  include/linux/phy/phy.h                            |  270 ++++++++
>  9 files changed, 1251 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-
> bindings.txt
>  create mode 100644 Documentation/phy.txt  create mode 100644
> drivers/phy/Kconfig  create mode 100644 drivers/phy/Makefile  create
> mode 100644 drivers/phy/phy-core.c  create mode 100644
> include/linux/phy/phy.h
> 

[snip]

> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h new file
> mode 100644 index 0000000..e444b23
> --- /dev/null
> +++ b/include/linux/phy/phy.h
> @@ -0,0 +1,270 @@

[snip]

> +struct phy_init_data {
> +	unsigned int num_consumers;
> +	struct phy_consumer *consumers;
> +};
> +
> +#define PHY_CONSUMER(_dev_name, _port)				\
> +{								\
> +	.dev_name	= _dev_name,				\
> +	.port		= _port,				\
> +}
> +
> +#define	to_phy(dev)	(container_of((dev), struct phy, dev))
> +
> +#define	of_phy_provider_register(dev, xlate)	\
> +	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
> +
> +#define	devm_of_phy_provider_register(dev, xlate)	\
> +	__of_phy_provider_register((dev), THIS_MODULE, (xlate))

I think this should be:
+	__devm_of_phy_provider_register((dev), THIS_MODULE, (xlate))
Right?

> +
> +static inline void phy_set_drvdata(struct phy *phy, void *data) {
> +	dev_set_drvdata(&phy->dev, data);
> +}
> +
> +static inline void *phy_get_drvdata(struct phy *phy) {
> +	return dev_get_drvdata(&phy->dev);
> +}
> +

[snip]

Best wishes,
-- 
Kamil Debski
Linux Kernel Developer
Samsung R&D Institute Poland






From kishon at ti.com  Mon Jul 29 11:29:26 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 29 Jul 2013 20:59:26 +0530
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given
 in usb_bind_phy
In-Reply-To: <20130729150638.GD3063@radagast>
References: <1374829418-27503-1-git-send-email-kishon@ti.com>
 <1374829418-27503-3-git-send-email-kishon@ti.com>
 <20130729150638.GD3063@radagast>
Message-ID: <51F68A56.8060805@ti.com>

Hi,

On Monday 29 July 2013 08:36 PM, Felipe Balbi wrote:
> Hi,
> 
> On Fri, Jul 26, 2013 at 02:33:38PM +0530, Kishon Vijay Abraham I wrote:
>> Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while creating
>> MUSB core device. So in usb_bind_phy (binds the controller with the PHY), the
>> device name of the controller had *.auto* in it. Since with using
>> PLATFORM_DEVID_AUTO, there is no way to know the exact device name in advance,
>> the data given in usb_bind_phy became obsolete and usb_get_phy was failing.
>> So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO. Corresponding
>> change is done in board file here.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
>> ---
>>  arch/arm/mach-omap2/board-2430sdp.c          |    2 +-
>>  arch/arm/mach-omap2/board-3430sdp.c          |    2 +-
>>  arch/arm/mach-omap2/board-cm-t35.c           |    2 +-
>>  arch/arm/mach-omap2/board-devkit8000.c       |    2 +-
>>  arch/arm/mach-omap2/board-igep0020.c         |    2 +-
>>  arch/arm/mach-omap2/board-ldp.c              |    2 +-
>>  arch/arm/mach-omap2/board-omap3beagle.c      |    2 +-
>>  arch/arm/mach-omap2/board-omap3evm.c         |    2 +-
>>  arch/arm/mach-omap2/board-omap3logic.c       |    2 +-
>>  arch/arm/mach-omap2/board-omap3pandora.c     |    2 +-
>>  arch/arm/mach-omap2/board-omap3stalker.c     |    2 +-
>>  arch/arm/mach-omap2/board-omap3touchbook.c   |    2 +-
>>  arch/arm/mach-omap2/board-overo.c            |    2 +-
>>  arch/arm/mach-omap2/board-rm680.c            |    2 +-
>>  arch/arm/mach-omap2/board-rx51.c             |    2 +-
>>  arch/arm/mach-omap2/board-zoom-peripherals.c |    2 +-
>>  16 files changed, 16 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
>> index 244d8a5..17bb076 100644
>> --- a/arch/arm/mach-omap2/board-2430sdp.c
>> +++ b/arch/arm/mach-omap2/board-2430sdp.c
>> @@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
>>  	omap_hsmmc_init(mmc);
>>  
>>  	omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
>> -	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
>> +	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
> 
> how about moving usb_bind_phy() calls to omap2430.c ?
> 
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index f44e8b5..b6abc1a 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device *pdev)
>  
>  		pdata->board_data	= data;
>  		pdata->config		= config;
> +	} else {
> +		/* bind the PHY */
> +		usb_bind_phy(dev_name(&musb->dev), 0, "twl4030_usb");

This looks like a hack IMHO to workaround the usb phy library. otherwise it is
similar to get_phy_by_name.
>  	}
>  
>  	if (pdata->has_mailbox) {
> 
> The only problem is if some board comes with a PHY other than
> twl4030_usb, but in that case we can add a separate compatible flag and
> treat it properly. We only need to bind the phy in non-DT case anyway,

right.
> so that's temporary. It might be better than to reintroduce the IDR in
> musb_core.c.

that?s needed for generic phy framework anyway :-s

Thanks
Kishon


From kishon at ti.com  Mon Jul 29 11:30:58 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 29 Jul 2013 21:00:58 +0530
Subject: [RESEND PATCH v10 1/8] drivers: phy: add generic PHY framework
In-Reply-To: <023801ce8c70$427cbd20$c7763760$%debski@samsung.com>
References: <1374842963-13545-1-git-send-email-kishon@ti.com>
 <1374842963-13545-2-git-send-email-kishon@ti.com>
 <023801ce8c70$427cbd20$c7763760$%debski@samsung.com>
Message-ID: <51F68AB2.5090402@ti.com>

On Monday 29 July 2013 08:58 PM, Kamil Debski wrote:
> Hi Kishon,
> 
> A small fix follows inline.
> 
>> From: linux-media-owner at vger.kernel.org [mailto:linux-media-
>> owner at vger.kernel.org] On Behalf Of Kishon Vijay Abraham I
>> Sent: Friday, July 26, 2013 2:49 PM
>>
>> The PHY framework provides a set of APIs for the PHY drivers to
>> create/destroy a PHY and APIs for the PHY users to obtain a reference
>> to the PHY with or without using phandle. For dt-boot, the PHY drivers
>> should also register *PHY provider* with the framework.
>>
>> PHY drivers should create the PHY by passing id and ops like init, exit,
>> power_on and power_off. This framework is also pm runtime enabled.
>>
>> The documentation for the generic PHY framework is added in
>> Documentation/phy.txt and the documentation for dt binding can be found
>> at Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> Cc: Tomasz Figa <t.figa at samsung.com>
>> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
>> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
>> Acked-by: Felipe Balbi <balbi at ti.com>
>> Tested-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
>> ---
>>  .../devicetree/bindings/phy/phy-bindings.txt       |   66 ++
>>  Documentation/phy.txt                              |  166 +++++
>>  MAINTAINERS                                        |    8 +
>>  drivers/Kconfig                                    |    2 +
>>  drivers/Makefile                                   |    2 +
>>  drivers/phy/Kconfig                                |   18 +
>>  drivers/phy/Makefile                               |    5 +
>>  drivers/phy/phy-core.c                             |  714
>> ++++++++++++++++++++
>>  include/linux/phy/phy.h                            |  270 ++++++++
>>  9 files changed, 1251 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/phy-
>> bindings.txt
>>  create mode 100644 Documentation/phy.txt  create mode 100644
>> drivers/phy/Kconfig  create mode 100644 drivers/phy/Makefile  create
>> mode 100644 drivers/phy/phy-core.c  create mode 100644
>> include/linux/phy/phy.h
>>
> 
> [snip]
> 
>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h new file
>> mode 100644 index 0000000..e444b23
>> --- /dev/null
>> +++ b/include/linux/phy/phy.h
>> @@ -0,0 +1,270 @@
> 
> [snip]
> 
>> +struct phy_init_data {
>> +	unsigned int num_consumers;
>> +	struct phy_consumer *consumers;
>> +};
>> +
>> +#define PHY_CONSUMER(_dev_name, _port)				\
>> +{								\
>> +	.dev_name	= _dev_name,				\
>> +	.port		= _port,				\
>> +}
>> +
>> +#define	to_phy(dev)	(container_of((dev), struct phy, dev))
>> +
>> +#define	of_phy_provider_register(dev, xlate)	\
>> +	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
>> +
>> +#define	devm_of_phy_provider_register(dev, xlate)	\
>> +	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
> 
> I think this should be:
> +	__devm_of_phy_provider_register((dev), THIS_MODULE, (xlate))
> Right?

right.. thanks for spotting this.

Regards
Kishon


From matt.porter at linaro.org  Mon Jul 29 11:32:05 2013
From: matt.porter at linaro.org (Matt Porter)
Date: Mon, 29 Jul 2013 11:32:05 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130726144047.GH9858@sirena.org.uk>
References: <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726132709.GH29916@titan.lakedaemon.net>
 <1374846070.14574.92.camel@i7.infradead.org>
 <CAKON4OzrkHzUzKkULWCgiEpAtJ5gLxUm78R5ctd7p6trqq_gCA@mail.gmail.com>
 <20130726142140.GR24642@n2100.arm.linux.org.uk>
 <20130726144047.GH9858@sirena.org.uk>
Message-ID: <20130729153204.GJ5022@ohporter.com>

On Fri, Jul 26, 2013 at 03:40:47PM +0100, Mark Brown wrote:
> On Fri, Jul 26, 2013 at 03:21:40PM +0100, Russell King - ARM Linux wrote:
> 
> > So this is why I'm seeing patches just a short time ago removing existing
> > compatible strings from the DT descriptions and associated driver, and
> > replacing them with new ones... meaning that the old DT files won't work
> > with newer kernels.
> 
> The big question is if you're seeing such patches merged.  People making
> mistakes on submissions is totally normal.

Over in the bcm53xx thread, we've discussed such a patch to fix
inconsistencies. The problem here is that there is no canonical answer
to what a mistake is. I can make a strong argument that the support for
these parts is in such an early stage that the bindings (in this case
specifically the two different compatible strings for one vendor) should
be considered unstable and ok to fix the consistency issue. Mark Rutland
suggests we should change nothing and possibly add a third vendor prefix
for new bindings. I'm having trouble accepting that just because these
bindings made it into a final kernel during a period where
scrutinization of these things was not very high that we need to forever
carry this inconsistency in the "specification".

http://www.spinics.net/lists/arm-kernel/msg262059.html

> 
> If it's the case I think you mean TBH I'm not sure anyone cares, I don't
> think anyone is using that stuff in production yet as those chips go
> almost exclusively into Android phones.

At least the bcm281xx stuff falls into this category as you describe.
There's simply nobody that would be upset if its bindings changed from
bcm-><something_else> as there's just nobody using the DT-based upstream
work except for internal Broadcom and a couple people external working
closely with them.

This situation seems to illustrate the strong need for an unstable
binding period that's longer than just inclusion in a final kernel
release.

-Matt


From shc_work at mail.ru  Mon Jul 29 11:37:23 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Mon, 29 Jul 2013 19:37:23 +0400
Subject: [PATCH v2] ARM: imx: pllv1: Fix PLL calculation for i.MX27
Message-ID: <1375112243-1557-1-git-send-email-shc_work@mail.ru>

MFN bit 9 on i.MX27 has a different meaning than in other SOCs. This
is a just sign bit. This patch makes different calculation for i.MX27.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/mach-imx/clk-pllv1.c | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/clk-pllv1.c b/arch/arm/mach-imx/clk-pllv1.c
index c1eaee3..a289ccd 100644
--- a/arch/arm/mach-imx/clk-pllv1.c
+++ b/arch/arm/mach-imx/clk-pllv1.c
@@ -25,6 +25,11 @@ struct clk_pllv1 {
 
 #define to_clk_pllv1(clk) (container_of(clk, struct clk_pllv1, clk))
 
+static inline bool allow_signed_mfn(void)
+{
+	return !cpu_is_mx1() && !cpu_is_mx21();
+}
+
 static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
 		unsigned long parent_rate)
 {
@@ -59,9 +64,14 @@ static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
 	/*
 	 * On all i.MXs except i.MX1 and i.MX21 mfn is a 10bit
 	 * 2's complements number
+	 * On i.MX27 the bit 9 is the sign bit.
 	 */
-	if (!cpu_is_mx1() && !cpu_is_mx21() && mfn >= 0x200)
-		mfn_abs = 0x400 - mfn;
+	if (allow_signed_mfn() && (mfn & 0x200)) {
+		if (cpu_is_mx27())
+			mfn_abs = mfn & 0x1ff;
+		else
+			mfn_abs = 0x400 - mfn;
+	}
 
 	rate = parent_rate * 2;
 	rate /= pd + 1;
@@ -70,7 +80,7 @@ static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
 
 	do_div(ll, mfd + 1);
 
-	if (!cpu_is_mx1() && !cpu_is_mx21() && mfn >= 0x200)
+	if (allow_signed_mfn() && (mfn & 0x200))
 		ll = -ll;
 
 	ll = (rate * mfi) + ll;
-- 
1.8.1.5



From linus.walleij at linaro.org  Mon Jul 29 11:42:15 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 Jul 2013 17:42:15 +0200
Subject: [PATCH] pinctrl: at91: choose appropriate handler for level
 interrupts
In-Reply-To: <1374331893-16009-1-git-send-email-b.brezillon@overkiz.com>
References: <1374331893-16009-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <CACRpkdaGdgLeYrahv0qAJJjL3S2aiZeVwRVUtNcDqQgL3_mQkA@mail.gmail.com>

On Sat, Jul 20, 2013 at 4:51 PM, Boris BREZILLON
<b.brezillon at overkiz.com> wrote:

> The current implementation handle both edge and level interrupts with the
> 'handle_simple_irq' handler.
>
> Level interrupts are active as long as the pin stays at the configured
> level (low or high). In this case we have to use 'handle_level_irq' which
> mask the interrupt until the handle has treated it.
>
> Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>

Nicolas/Jean-Christophe: any opinion on this patch?

I am tempted to just apply it and see if you react to it :-)

Yours,
Linus Walleij


From shc_work at mail.ru  Mon Jul 29 11:42:07 2013
From: shc_work at mail.ru (Alexander Shiyan)
Date: Mon, 29 Jul 2013 19:42:07 +0400
Subject: [PATCH] ARM: i.MX6Q clocks: Fix CKIH clock name
In-Reply-To: <51F622D1.5030009@de.bosch.com>
References: <1374908212-32008-1-git-send-email-shc_work@mail.ru>
 <51F622D1.5030009@de.bosch.com>
Message-ID: <20130729194207.bfb62131c3cfd29e5d5944ea@mail.ru>

On Mon, 29 Jul 2013 10:07:45 +0200
Dirk Behme <dirk.behme at de.bosch.com> wrote:

> On 27.07.2013 08:56, Alexander Shiyan wrote:
> > i.MX6Q have only one High-frequency reference clock (CKIH).
> > Patch removes index from CKIH and makes name according datasheet.
> >
> > Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> > ---
> >   arch/arm/mach-imx/clk-imx6q.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
> > index 9181a24..8f2a8b5 100644
> > --- a/arch/arm/mach-imx/clk-imx6q.c
> > +++ b/arch/arm/mach-imx/clk-imx6q.c
> > @@ -292,7 +292,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> >
> >   	clk[dummy] = imx_clk_fixed("dummy", 0);
> >   	clk[ckil] = imx_obtain_fixed_clock("ckil", 0);
> > -	clk[ckih] = imx_obtain_fixed_clock("ckih1", 0);
> > +	clk[ckih] = imx_obtain_fixed_clock("ckih", 0);
> >   	clk[osc] = imx_obtain_fixed_clock("osc", 0);
> >
> >   	np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");
> 
> Just for my understanding: This is a cosmetic change, only? And doesn't 
> change any functionality? Correct?

Yes, but in any case this is an incomplete patch, because I forgot to change
the relevant DTS.

-- 
Alexander Shiyan <shc_work at mail.ru>


From thomas.petazzoni at free-electrons.com  Mon Jul 29 11:42:12 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 29 Jul 2013 17:42:12 +0200
Subject: [PATCHv2 0/2] dma: mv_xor: big endian support
Message-ID: <1375112534-748-1-git-send-email-thomas.petazzoni@free-electrons.com>

Vinod, Dan,

This small set of patches adds support for big endian operation in the
DMA mv_xor driver. It has been tested in both little-endian and
big-endian modes on the Armada XP GP board.

If possible, I'd like those to be merged for 3.12.

Changes since v1:
 * Use readl_relaxed() and writel_relaxed() instead of readl/writel
   when converting from raw_readl/raw_writel, since they preserve the
   same barrier behavior. Suggested by Russell King.

Thanks!

Thomas

Thomas Petazzoni (2):
  mv_xor: use {readl,writel}_relaxed instead of __raw_{readl,writel}
  mv_xor: support big endian systems using descriptor swap feature

 drivers/dma/mv_xor.c | 47 +++++++++++++++++++++++++++--------------------
 drivers/dma/mv_xor.h | 28 +++++++++++++++++++++++++++-
 2 files changed, 54 insertions(+), 21 deletions(-)

-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 29 11:42:14 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 29 Jul 2013 17:42:14 +0200
Subject: [PATCHv2 2/2] mv_xor: support big endian systems using descriptor
 swap feature
In-Reply-To: <1375112534-748-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1375112534-748-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1375112534-748-3-git-send-email-thomas.petazzoni@free-electrons.com>

The mv_xor driver had never been used in a big-endian context, and
therefore was not using the hardware features to support such an
execution environment. The hardware provides a "descriptor swap" bit
that automatically swaps the bytes of the DMA descriptors, within
blocks of 8 bytes. This requires a different DMA descriptor layout on
big-endian systems, as well as enabling this "descriptor swap" bit.

This mechanism is exactly identical to the one already used in the
mv643xx_eth network driver and the mvneta network driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/dma/mv_xor.c | 11 +++++++++--
 drivers/dma/mv_xor.h | 28 +++++++++++++++++++++++++++-
 2 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index c026b27..d332b9e 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -64,7 +64,7 @@ static u32 mv_desc_get_src_addr(struct mv_xor_desc_slot *desc,
 				int src_idx)
 {
 	struct mv_xor_desc *hw_desc = desc->hw_desc;
-	return hw_desc->phy_src_addr[src_idx];
+	return hw_desc->phy_src_addr[mv_phy_src_idx(src_idx)];
 }
 
 
@@ -107,7 +107,7 @@ static void mv_desc_set_src_addr(struct mv_xor_desc_slot *desc,
 				 int index, dma_addr_t addr)
 {
 	struct mv_xor_desc *hw_desc = desc->hw_desc;
-	hw_desc->phy_src_addr[index] = addr;
+	hw_desc->phy_src_addr[mv_phy_src_idx(index)] = addr;
 	if (desc->type == DMA_XOR)
 		hw_desc->desc_command |= (1 << index);
 }
@@ -192,6 +192,13 @@ static void mv_set_mode(struct mv_xor_chan *chan,
 
 	config &= ~0x7;
 	config |= op_mode;
+
+#if defined(__BIG_ENDIAN)
+	config |= XOR_DESCRIPTOR_SWAP;
+#else
+	config &= ~XOR_DESCRIPTOR_SWAP;
+#endif
+
 	writel_relaxed(config, XOR_CONFIG(chan));
 	chan->current_type = type;
 }
diff --git a/drivers/dma/mv_xor.h b/drivers/dma/mv_xor.h
index c619359..06b067f 100644
--- a/drivers/dma/mv_xor.h
+++ b/drivers/dma/mv_xor.h
@@ -29,8 +29,10 @@
 #define MV_XOR_THRESHOLD		1
 #define MV_XOR_MAX_CHANNELS             2
 
+/* Values for the XOR_CONFIG register */
 #define XOR_OPERATION_MODE_XOR		0
 #define XOR_OPERATION_MODE_MEMCPY	2
+#define XOR_DESCRIPTOR_SWAP		BIT(14)
 
 #define XOR_CURR_DESC(chan)	(chan->mmr_base + 0x210 + (chan->idx * 4))
 #define XOR_NEXT_DESC(chan)	(chan->mmr_base + 0x200 + (chan->idx * 4))
@@ -143,7 +145,16 @@ struct mv_xor_desc_slot {
 #endif
 };
 
-/* This structure describes XOR descriptor size 64bytes	*/
+/*
+ * This structure describes XOR descriptor size 64bytes. The
+ * mv_phy_src_idx() macro must be used when indexing the values of the
+ * phy_src_addr[] array. This is due to the fact that the 'descriptor
+ * swap' feature, used on big endian systems, swaps descriptors data
+ * within blocks of 8 bytes. So two consecutive values of the
+ * phy_src_addr[] array are actually swapped in big-endian, which
+ * explains the different mv_phy_src_idx() implementation.
+ */
+#if defined(__LITTLE_ENDIAN)
 struct mv_xor_desc {
 	u32 status;		/* descriptor execution status */
 	u32 crc32_result;	/* result of CRC-32 calculation */
@@ -155,6 +166,21 @@ struct mv_xor_desc {
 	u32 reserved0;
 	u32 reserved1;
 };
+#define mv_phy_src_idx(src_idx) (src_idx)
+#else
+struct mv_xor_desc {
+	u32 crc32_result;	/* result of CRC-32 calculation */
+	u32 status;		/* descriptor execution status */
+	u32 phy_next_desc;	/* next descriptor address pointer */
+	u32 desc_command;	/* type of operation to be carried out */
+	u32 phy_dest_addr;	/* destination block address */
+	u32 byte_count;		/* size of src/dst blocks in bytes */
+	u32 phy_src_addr[8];	/* source block addresses */
+	u32 reserved1;
+	u32 reserved0;
+};
+#define mv_phy_src_idx(src_idx) (src_idx ^ 1)
+#endif
 
 #define to_mv_sw_desc(addr_hw_desc)		\
 	container_of(addr_hw_desc, struct mv_xor_desc_slot, hw_desc)
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Mon Jul 29 11:42:13 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 29 Jul 2013 17:42:13 +0200
Subject: [PATCHv2 1/2] mv_xor: use {readl,
 writel}_relaxed instead of __raw_{readl, writel}
In-Reply-To: <1375112534-748-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1375112534-748-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1375112534-748-2-git-send-email-thomas.petazzoni@free-electrons.com>

In order to support big-endian execution, the mv_xor driver is changed
to use the readl_relaxed() and writel_relaxed() accessors that
properly convert from the CPU endianess to the device endianess (which
in the case of Marvell XOR hardware is always little-endian).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/dma/mv_xor.c | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index 200f1a3..c026b27 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -114,25 +114,25 @@ static void mv_desc_set_src_addr(struct mv_xor_desc_slot *desc,
 
 static u32 mv_chan_get_current_desc(struct mv_xor_chan *chan)
 {
-	return __raw_readl(XOR_CURR_DESC(chan));
+	return readl_relaxed(XOR_CURR_DESC(chan));
 }
 
 static void mv_chan_set_next_descriptor(struct mv_xor_chan *chan,
 					u32 next_desc_addr)
 {
-	__raw_writel(next_desc_addr, XOR_NEXT_DESC(chan));
+	writel_relaxed(next_desc_addr, XOR_NEXT_DESC(chan));
 }
 
 static void mv_chan_unmask_interrupts(struct mv_xor_chan *chan)
 {
-	u32 val = __raw_readl(XOR_INTR_MASK(chan));
+	u32 val = readl_relaxed(XOR_INTR_MASK(chan));
 	val |= XOR_INTR_MASK_VALUE << (chan->idx * 16);
-	__raw_writel(val, XOR_INTR_MASK(chan));
+	writel_relaxed(val, XOR_INTR_MASK(chan));
 }
 
 static u32 mv_chan_get_intr_cause(struct mv_xor_chan *chan)
 {
-	u32 intr_cause = __raw_readl(XOR_INTR_CAUSE(chan));
+	u32 intr_cause = readl_relaxed(XOR_INTR_CAUSE(chan));
 	intr_cause = (intr_cause >> (chan->idx * 16)) & 0xFFFF;
 	return intr_cause;
 }
@@ -149,13 +149,13 @@ static void mv_xor_device_clear_eoc_cause(struct mv_xor_chan *chan)
 {
 	u32 val = ~(1 << (chan->idx * 16));
 	dev_dbg(mv_chan_to_devp(chan), "%s, val 0x%08x\n", __func__, val);
-	__raw_writel(val, XOR_INTR_CAUSE(chan));
+	writel_relaxed(val, XOR_INTR_CAUSE(chan));
 }
 
 static void mv_xor_device_clear_err_status(struct mv_xor_chan *chan)
 {
 	u32 val = 0xFFFF0000 >> (chan->idx * 16);
-	__raw_writel(val, XOR_INTR_CAUSE(chan));
+	writel_relaxed(val, XOR_INTR_CAUSE(chan));
 }
 
 static int mv_can_chain(struct mv_xor_desc_slot *desc)
@@ -173,7 +173,7 @@ static void mv_set_mode(struct mv_xor_chan *chan,
 			       enum dma_transaction_type type)
 {
 	u32 op_mode;
-	u32 config = __raw_readl(XOR_CONFIG(chan));
+	u32 config = readl_relaxed(XOR_CONFIG(chan));
 
 	switch (type) {
 	case DMA_XOR:
@@ -192,7 +192,7 @@ static void mv_set_mode(struct mv_xor_chan *chan,
 
 	config &= ~0x7;
 	config |= op_mode;
-	__raw_writel(config, XOR_CONFIG(chan));
+	writel_relaxed(config, XOR_CONFIG(chan));
 	chan->current_type = type;
 }
 
@@ -201,14 +201,14 @@ static void mv_chan_activate(struct mv_xor_chan *chan)
 	u32 activation;
 
 	dev_dbg(mv_chan_to_devp(chan), " activate chan.\n");
-	activation = __raw_readl(XOR_ACTIVATION(chan));
+	activation = readl_relaxed(XOR_ACTIVATION(chan));
 	activation |= 0x1;
-	__raw_writel(activation, XOR_ACTIVATION(chan));
+	writel_relaxed(activation, XOR_ACTIVATION(chan));
 }
 
 static char mv_chan_is_busy(struct mv_xor_chan *chan)
 {
-	u32 state = __raw_readl(XOR_ACTIVATION(chan));
+	u32 state = readl_relaxed(XOR_ACTIVATION(chan));
 
 	state = (state >> 4) & 0x3;
 
@@ -755,22 +755,22 @@ static void mv_dump_xor_regs(struct mv_xor_chan *chan)
 {
 	u32 val;
 
-	val = __raw_readl(XOR_CONFIG(chan));
+	val = readl_relaxed(XOR_CONFIG(chan));
 	dev_err(mv_chan_to_devp(chan), "config       0x%08x\n", val);
 
-	val = __raw_readl(XOR_ACTIVATION(chan));
+	val = readl_relaxed(XOR_ACTIVATION(chan));
 	dev_err(mv_chan_to_devp(chan), "activation   0x%08x\n", val);
 
-	val = __raw_readl(XOR_INTR_CAUSE(chan));
+	val = readl_relaxed(XOR_INTR_CAUSE(chan));
 	dev_err(mv_chan_to_devp(chan), "intr cause   0x%08x\n", val);
 
-	val = __raw_readl(XOR_INTR_MASK(chan));
+	val = readl_relaxed(XOR_INTR_MASK(chan));
 	dev_err(mv_chan_to_devp(chan), "intr mask    0x%08x\n", val);
 
-	val = __raw_readl(XOR_ERROR_CAUSE(chan));
+	val = readl_relaxed(XOR_ERROR_CAUSE(chan));
 	dev_err(mv_chan_to_devp(chan), "error cause  0x%08x\n", val);
 
-	val = __raw_readl(XOR_ERROR_ADDR(chan));
+	val = readl_relaxed(XOR_ERROR_ADDR(chan));
 	dev_err(mv_chan_to_devp(chan), "error addr   0x%08x\n", val);
 }
 
-- 
1.8.1.2



From matt.porter at linaro.org  Mon Jul 29 11:45:55 2013
From: matt.porter at linaro.org (Matt Porter)
Date: Mon, 29 Jul 2013 11:45:55 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <CAOesGMhEr3DiFm5uSgoHPFUMY4jWu4HkeTU2UmOGj=dS75Vk+g@mail.gmail.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726080115.GA5436@netboy>
 <1374831744.2923.42.camel@shinybook.infradead.org>
 <20130726130927.GC4219@netboy>
 <20130726141016.GF9858@sirena.org.uk>
 <CAOesGMhEr3DiFm5uSgoHPFUMY4jWu4HkeTU2UmOGj=dS75Vk+g@mail.gmail.com>
Message-ID: <20130729154553.GK5022@ohporter.com>

On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:
> On Fri, Jul 26, 2013 at 7:10 AM, Mark Brown <broonie at kernel.org> wrote:
> > On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
> >
> >> Unless I totally misunderstood, the thread is talking about letting
> >> established bindings change with each new kernel version.  I am
> >> opposed to that.
> >
> > No, nobody is really saying that is a particularly good idea.  There is
> > some debate about how we work out what an established binding is but
> > there's no serious suggestion that we don't want stable bindings.
> 
> Yes, what Mark said -- _today_ all bindings are subject to change and
> can be changed in lockstep with the kernel. This has been necessary as
> part of development to sort out all of the various bootstrapping
> issues across platforms.

However, we still have people arguing that we can't (or should not) change
a binding right now even to fix inconsistency issues that are discovered
after the fact. I'm hearing a different story depending on who is
telling it at the moment.

Getting quickly to a definitive answer on the criteria for an
"established" binding is will help end ongoing discussions as to whether
we can fix a currently broken one or just have to leave it.

> What we're talking about is to end that mode of operation, and moving
> over to locking in bindings. Device tree contents, as mentioned
> elsewhere, might still be changed just like code is -- bugs are fixed,
> etc. But it's time to start locking down the bindings, in particular
> no longer change the established ones.
> 
> Long term, final goal is likely to be close to what Russell is saying
> -- nothing should go into the kernel tree unless the binding is in a
> fully stable state. However, we have a transitional period between now
> and then, and even when we're at the final state there will be need to
> have some sort of sandbox for development and test of future bindings.
> Dealing with all that, as well as the actual process for locking in
> bindings, is what needs to be sorted out.
> 
> I think we're all in agreement that bindings that change over time are
> nothing but pain, but we're arguing that in circles anyway.

+1

-Matt


From soren.brinkmann at xilinx.com  Mon Jul 29 11:50:16 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Mon, 29 Jul 2013 08:50:16 -0700
Subject: [PATCH v6 4/5] clk: add CLK_SET_RATE_NO_REPARENT flag
In-Reply-To: <1375097102-28892-5-git-send-email-james.hogan@imgtec.com>
References: <1375097102-28892-1-git-send-email-james.hogan@imgtec.com>
 <1375097102-28892-5-git-send-email-james.hogan@imgtec.com>
Message-ID: <36053e73-faf4-47c6-9ff5-3e451361ef75@CH1EHSMHS012.ehs.local>

On Mon, Jul 29, 2013 at 12:25:01PM +0100, James Hogan wrote:
> Add a CLK_SET_RATE_NO_REPARENT clock flag, which will prevent muxes
> being reparented during clk_set_rate.
> 
> To avoid breaking existing platforms, all callers of clk_register_mux()
> are adjusted to pass the new flag. Platform maintainers are encouraged
> to remove the flag if they wish to allow mux reparenting on set_rate.
> 
> Signed-off-by: James Hogan <james.hogan at imgtec.com>
> Reviewed-by: Stephen Boyd <sboyd at codeaurora.org>
> Cc: Mike Turquette <mturquette at linaro.org>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Sascha Hauer <kernel at pengutronix.de>
> Cc: Stephen Warren <swarren at wwwdotorg.org>
> Cc: Viresh Kumar <viresh.linux at gmail.com>
> Cc: Kukjin Kim <kgene.kim at samsung.com>
> Cc: Haojian Zhuang <haojian.zhuang at linaro.org>
> Cc: Chao Xie <xiechao.mail at gmail.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: "Emilio L?pez" <emilio at elopez.com.ar>
> Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Cc: Maxime Ripard <maxime.ripard at free-electrons.com>
> Cc: Prashant Gaikwad <pgaikwad at nvidia.com>
> Cc: Thierry Reding <thierry.reding at gmail.com>
> Cc: Peter De Schrijver <pdeschrijver at nvidia.com>
> Cc: Pawel Moll <pawel.moll at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Andrew Chew <achew at nvidia.com>
> Cc: Doug Anderson <dianders at chromium.org>
> Cc: Heiko Stuebner <heiko at sntech.de>
> Cc: Paul Walmsley <pwalmsley at nvidia.com>
> Cc: Soren Brinkmann <soren.brinkmann at xilinx.com>
> Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Cc: Thomas Abraham <thomas.abraham at linaro.org>
> Cc: Tomasz Figa <t.figa at samsung.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org
> Cc: spear-devel at list.st.com
> Cc: linux-tegra at vger.kernel.org
> Tested-by: Haojian Zhuang <haojian.zhuang at gmail.com>
> Acked-by: Stephen Warren <swarren at nvidia.com> [tegra]
> Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com> [sunxi]
ACK for Zynq.

I'll have to look at the details and do some testing to see whether we
can remove the flag later.

	S?ren




From linus.walleij at linaro.org  Mon Jul 29 11:51:17 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 Jul 2013 17:51:17 +0200
Subject: [PATCH] gpio/mxc: add chained_irq_enter/exit() to
 mx2_gpio_irq_handler
In-Reply-To: <1374152286-12955-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1374152286-12955-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <CACRpkdZjsAOtm2Jt7kY-VC2ToFfMQ+UxjWQE7aUZAbsBt0ugvw@mail.gmail.com>

On Thu, Jul 18, 2013 at 2:58 PM, Uwe Kleine-K?nig
<u.kleine-koenig at pengutronix.de> wrote:

> Similar to commit
>
>         0e44b6e (gpio/mxc: add chained_irq_enter/exit() to mx3_gpio_irq_handler())
>
> . It doesn't seem to be critical to make the irqs work, but still it is
> more correct.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Patch is fine, but looks like this to me:

Content-Transfer-Encoding: base64

Sender: "linux-arm-kernel" <linux-arm-kernel-bounces at lists.infradead.org>
Errors-To: linux-arm-kernel-bounces+linus.walleij=linaro.org at lists.infradead.org

U2ltaWxhciB0byBjb21taXQKCgkwZTQ0YjZlIChncGlvL214YzogYWRkIGNoYWluZWRfaXJxX2Vu
dGVyL2V4aXQoKSB0byBteDNfZ3Bpb19pcnFfaGFuZGxlcigpKQoKLiBJdCBkb2Vzbid0IHNlZW0g
dG8gYmUgY3JpdGljYWwgdG8gbWFrZSB0aGUgaXJxcyB3b3JrLCBidXQgc3RpbGwgaXQgaXMKbW9y
ZSBjb3JyZWN0LgoKU2lnbmVkLW9mZi1ieTogVXdlIEtsZWluZS1Lw7ZuaWcgPHUua2xlaW5lLWtv
ZW5pZ0BwZW5ndXRyb25peC5kZT4KLS0tCkhlbGxvLAoKbm90ZSB0aGlzIGlzIGNvbXBsZXRlbHkg
dW50ZXN0ZWQuCgpVd2UKCiBkcml2ZXJzL2dwaW8vZ3Bpby1teGMuYyB8IDQgKysrKwogMSBmaWxl

The encoding is what screw things up.

Can you see if you can resend this without using base64?

Yours,
Linus Walleij


From s.nawrocki at samsung.com  Mon Jul 29 11:51:15 2013
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Mon, 29 Jul 2013 17:51:15 +0200
Subject: [RESEND PATCH v10 1/8] drivers: phy: add generic PHY framework
In-Reply-To: <1374842963-13545-2-git-send-email-kishon@ti.com>
References: <1374842963-13545-1-git-send-email-kishon@ti.com>
 <1374842963-13545-2-git-send-email-kishon@ti.com>
Message-ID: <51F68F73.9060603@samsung.com>

On 07/26/2013 02:49 PM, Kishon Vijay Abraham I wrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
> PHY with or without using phandle. For dt-boot, the PHY drivers should
> also register *PHY provider* with the framework.
> 
> PHY drivers should create the PHY by passing id and ops like init, exit,
> power_on and power_off. This framework is also pm runtime enabled.
> 
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for dt binding can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
> 
> Cc: Tomasz Figa <t.figa at samsung.com>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> Acked-by: Felipe Balbi <balbi at ti.com>
> Tested-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> ---
>  .../devicetree/bindings/phy/phy-bindings.txt       |   66 ++
>  Documentation/phy.txt                              |  166 +++++
>  MAINTAINERS                                        |    8 +
>  drivers/Kconfig                                    |    2 +
>  drivers/Makefile                                   |    2 +
>  drivers/phy/Kconfig                                |   18 +
>  drivers/phy/Makefile                               |    5 +
>  drivers/phy/phy-core.c                             |  714 ++++++++++++++++++++
>  include/linux/phy/phy.h                            |  270 ++++++++
>  9 files changed, 1251 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
>  create mode 100644 Documentation/phy.txt
>  create mode 100644 drivers/phy/Kconfig
>  create mode 100644 drivers/phy/Makefile
>  create mode 100644 drivers/phy/phy-core.c
>  create mode 100644 include/linux/phy/phy.h
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
> new file mode 100644
> index 0000000..8ae844f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
> @@ -0,0 +1,66 @@
> +This document explains only the device tree data binding. For general
> +information about PHY subsystem refer to Documentation/phy.txt
[...]
> @@ -0,0 +1,166 @@
> +			    PHY SUBSYSTEM
> +		  Kishon Vijay Abraham I <kishon at ti.com>
> +
> +This document explains the Generic PHY Framework along with the APIs provided,
> +and how-to-use.
> +
> +1. Introduction
> +
> +*PHY* is the abbreviation for physical layer. It is used to connect a device
> +to the physical medium e.g., the USB controller has a PHY to provide functions
> +such as serialization, de-serialization, encoding, decoding and is responsible
> +for obtaining the required data transmission rate. Note that some USB
> +controllers have PHY functionality embedded into it and others use an external
> +PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
> +SATA etc.
> +
> +The intention of creating this framework is to bring the PHY drivers spread
> +all over the Linux kernel to drivers/phy to increase code re-use and for
> +better code maintainability.
> +
> +This framework will be of use only to devices that use external PHY (PHY
> +functionality is not embedded within the controller).
> +
> +2. Registering/Unregistering the PHY provider
> +
> +PHY provider refers to an entity that implements one or more PHY instances.
> +For the simple case where the PHY provider implements only a single instance of
> +the PHY, the framework provides its own implementation of of_xlate in
> +of_phy_simple_xlate. If the PHY provider implements multiple instances, it
> +should provide its own implementation of of_xlate. of_xlate is used only for
> +dt boot case.
> +
> +#define of_phy_provider_register(dev, xlate)    \
> +        __of_phy_provider_register((dev), THIS_MODULE, (xlate))
> +
> +#define devm_of_phy_provider_register(dev, xlate)       \
> +        __of_phy_provider_register((dev), THIS_MODULE, (xlate))

This needs to be:

	__devm_of_phy_provider_register((dev), THIS_MODULE, (xlate))

as Kamil pointed out. We've tested it here with v9 and it makes
Bad Things happen. ;)

> +of_phy_provider_register and devm_of_phy_provider_register macros can be used to
> +register the phy_provider and it takes device and of_xlate as
> +arguments. For the dt boot case, all PHY providers should use one of the above
> +2 macros to register the PHY provider.
> +
> +void devm_of_phy_provider_unregister(struct device *dev,
> +	struct phy_provider *phy_provider);
> +void of_phy_provider_unregister(struct phy_provider *phy_provider);
> +
> +devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to
> +unregister the PHY.
> +
[...]
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> new file mode 100644
> index 0000000..f1d15e5
> --- /dev/null
> +++ b/drivers/phy/phy-core.c
> @@ -0,0 +1,714 @@
[...]
> +static struct phy *phy_lookup(struct device *device, const char *port)
> +{
> +	unsigned int count;
> +	struct phy *phy;
> +	struct device *dev;
> +	struct phy_consumer *consumers;
> +	struct class_dev_iter iter;
	
Don't you need something like

	if (phy->init_data == NULL)	
		return ERR_PTR(-EINVAL);

to ensure there is no attempt to dereference NULL platform data ?

> +	class_dev_iter_init(&iter, phy_class, NULL, NULL);
> +	while ((dev = class_dev_iter_next(&iter))) {
> +		phy = to_phy(dev);
> +		count = phy->init_data->num_consumers;
> +		consumers = phy->init_data->consumers;
> +		while (count--) {
> +			if (!strcmp(consumers->dev_name, dev_name(device)) &&
> +					!strcmp(consumers->port, port)) {
> +				class_dev_iter_exit(&iter);
> +				return phy;
> +			}
> +			consumers++;
> +		}
> +	}
> +
> +	class_dev_iter_exit(&iter);
> +	return ERR_PTR(-ENODEV);
> +}
> +
[...]
> +int phy_init(struct phy *phy)
> +{
> +	int ret;
> +
> +	ret = phy_pm_runtime_get_sync(phy);
> +	if (ret < 0 && ret != -ENOTSUPP)
> +		return ret;
> +
> +	mutex_lock(&phy->mutex);
> +	if (phy->init_count++ == 0 && phy->ops->init) {
> +		ret = phy->ops->init(phy);
> +		if (ret < 0) {
> +			dev_err(&phy->dev, "phy init failed --> %d\n", ret);
> +			goto out;

Is this 'goto' and similar ones below really needed ?

> +		}
> +	}
> +
> +out:
> +	mutex_unlock(&phy->mutex);
> +	phy_pm_runtime_put(phy);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_init);
> +
> +int phy_exit(struct phy *phy)
> +{
> +	int ret;
> +
> +	ret = phy_pm_runtime_get_sync(phy);
> +	if (ret < 0 && ret != -ENOTSUPP)
> +		return ret;
> +
> +	mutex_lock(&phy->mutex);
> +	if (--phy->init_count == 0 && phy->ops->exit) {
> +		ret = phy->ops->exit(phy);
> +		if (ret < 0) {
> +			dev_err(&phy->dev, "phy exit failed --> %d\n", ret);
> +			goto out;
> +		}
> +	}
> +
> +out:
> +	mutex_unlock(&phy->mutex);
> +	phy_pm_runtime_put(phy);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_exit);
> +
> +int phy_power_on(struct phy *phy)
> +{
> +	int ret = -ENOTSUPP;
> +
> +	ret = phy_pm_runtime_get_sync(phy);
> +	if (ret < 0 && ret != -ENOTSUPP)
> +		return ret;
> +
> +	mutex_lock(&phy->mutex);
> +	if (phy->power_count++ == 0 && phy->ops->power_on) {
> +		ret = phy->ops->power_on(phy);
> +		if (ret < 0) {
> +			dev_err(&phy->dev, "phy poweron failed --> %d\n", ret);
> +			goto out;
> +		}
> +	}
> +
> +out:
> +	mutex_unlock(&phy->mutex);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_power_on);
> +
> +int phy_power_off(struct phy *phy)
> +{
> +	int ret = -ENOTSUPP;
> +
> +	mutex_lock(&phy->mutex);
> +	if (--phy->power_count == 0 && phy->ops->power_off) {
> +		ret =  phy->ops->power_off(phy);
> +		if (ret < 0) {
> +			dev_err(&phy->dev, "phy poweroff failed --> %d\n", ret);
> +			goto out;
> +		}
> +	}
> +
> +out:
> +	mutex_unlock(&phy->mutex);
> +	phy_pm_runtime_put(phy);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_power_off);

--
Thanks,
Sylwester


From b.brezillon at overkiz.com  Mon Jul 29 11:52:16 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Mon, 29 Jul 2013 17:52:16 +0200
Subject: [PATCH] pinctrl: at91: choose appropriate handler for level
 interrupts
In-Reply-To: <CACRpkdaGdgLeYrahv0qAJJjL3S2aiZeVwRVUtNcDqQgL3_mQkA@mail.gmail.com>
References: <1374331893-16009-1-git-send-email-b.brezillon@overkiz.com>
 <CACRpkdaGdgLeYrahv0qAJJjL3S2aiZeVwRVUtNcDqQgL3_mQkA@mail.gmail.com>
Message-ID: <51F68FB0.4090507@overkiz.com>

On 29/07/2013 17:42, Linus Walleij wrote:
> On Sat, Jul 20, 2013 at 4:51 PM, Boris BREZILLON
> <b.brezillon at overkiz.com> wrote:
>
>> The current implementation handle both edge and level interrupts with the
>> 'handle_simple_irq' handler.
>>
>> Level interrupts are active as long as the pin stays at the configured
>> level (low or high). In this case we have to use 'handle_level_irq' which
>> mask the interrupt until the handle has treated it.
>>
>> Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
> Nicolas/Jean-Christophe: any opinion on this patch?
>
> I am tempted to just apply it and see if you react to it :-)
Hello,

Just for clarification, without this patch the kernel hangs if you request a
threaded irq on level state (low or high).

This was tested on sama5ek board.

Best Regards,

Boris
>
> Yours,
> Linus Walleij



From soren.brinkmann at xilinx.com  Mon Jul 29 11:58:50 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Mon, 29 Jul 2013 08:58:50 -0700
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <51F66565.7010600@linaro.org>
References: <20130717210417.GP13667@xsjandreislx>
 <51E72DCA.9070500@codeaurora.org>
 <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
Message-ID: <0fa70aa8-33f1-44bf-99c8-239a4b197798@CO9EHSMHS024.ehs.local>

Hi Daniel,

On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
> On 07/23/2013 12:41 AM, S?ren Brinkmann wrote:
> > Hi,
> > 
> > adding LKML and LAKML (which I forgot on the original email, sorry)
> > 
> > On Mon, Jul 22, 2013 at 01:13:48PM -0700, S?ren Brinkmann wrote:
> >> On Mon, Jul 22, 2013 at 12:54:26PM -0700, Stephen Boyd wrote:
> >>> On 07/22/13 11:25, S?ren Brinkmann wrote:
> >>>> On Wed, Jul 17, 2013 at 06:22:35PM -0700, Stephen Boyd wrote:
> >>>>> On 07/17/13 17:59, S?ren Brinkmann wrote:
> >>>>>> Hi Stephen,
> >>>>>>
> >>>>>> On Wed, Jul 17, 2013 at 04:50:34PM -0700, Stephen Boyd wrote:
> >>>>>>> On 07/17/13 14:04, S?ren Brinkmann wrote:
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>> I'm trying to enable the arm_global_timer on Zynq platforms with the
> >>>>>>>> attached patch. Unfortunately that patch breaks booting up. It hangs
> >>>>>>>> when handing over to init/early userspace (see attached boot.log).
> >>>>>>>>
> >>>>>>>> The funny thing is, if I remove either the global timer or the
> >>>>>>>> arm,cortex-a9-twd-timer node from my dts, it works. So, it looks like
> >>>>>>>> the two timer (drivers) interfere somehow. Does anybody have an idea of
> >>>>>>>> what is going on and probably even how to resolve it?
> >>>>>>>>
> >>>>>>>> The patch is based on commit c0d15cc in Linus' tree.
> >>>>>>> If you boot with one CPU does it hang? It looks like secondary CPUs
> >>>>>>> aren't getting interrupts but I'm not sure why. Maybe you can try this
> >>>>>>> patch and/or put some prints in the timer interrupt handler to see if
> >>>>>>> interrupts are firing on secondary CPUs.
> >>>>>> Your proposed patch does not seem to make a difference, but adding
> >>>>>> 'maxcpus=1' to the kernel command line makes the system boot.
> >>>>> Hmm I guess that doesn't really confirm much because TWD doesn't
> >>>>> register itself on maxcpus=1 systems, so it's the same as removing the
> >>>>> node from DT. Probably easier to put a printk in the interrupt handler
> >>>>> and confirm that you're receiving interrupts on secondary CPUs.
> >>>> Turns out it does work when I disable Zynq's cpuidle driver. I think I
> >>>> can blame that driver.
> >>>>
> >>>
> >>> Hmm.. Perhaps the arm_global_timer driver also needs FEAT_C3_STOP added
> >>> to it. Do you know if that timer is reset during low power modes?
> >>
> >> Our cpudidle driver is not powering off anything, AFAIK. I think it just
> >> executes 'wfi' on the CPU. I don't know how the timer core handles it,
> >> but I'd expect the CPU should find the timer just a it was left before
> >> entering idle (well, the timer continues to run I assume, but other than
> >> that).
> >> I'll do some debugging and see if I can find out what exactly causes the
> >> hang.
> > 
> > So, what I found:
> > The Zynq cpuidle driver provides two idle states, which are both
> > basically just ARM wfi states. But the second one set's these flags:
> > 	.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_TIMER_STOP,
> > 
> > I don't know what these flags cause in detail. But the
> > CPUIDLE_FLAG_TIMER_STOP seemed suspicious, since wfi does not have any
> > effect on the timer. So, I removed that one and things are working.
> > 
> > I also tried the other approach: Leaving cpuidle as is and adding the
> > C3STOP flag to the global timer. That solves it too.
> > 
> > Does anybody know what the correct solution is?
> > In case the C3STOP flag is considered to be corret for the timer, I
> > could prepare a patch for that and bundle it with the one to enable the
> > timer for Zynq?
> 
> Hi Soren,
> 
> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
> timer will be stopped when entering to the idle state. In this case, the
> cpuidle framework will call clockevents_notify(ENTER) and switches to a
> broadcast timer and will call clockevents_notify(EXIT) when exiting the
> idle state, switching the local timer back in use.
> 
> The C3STOP flag has a similar semantic than the CPUIDLE_FLAG_TIMER_STOP,
> that is the timer can be shutdown with a specific idle state. This flag
> is used by the tick broadcast code.
> 
> If the C3STOP flag is not set for a local timer, the
> CPUIDLE_FLAG_TIMER_STOP does not make sense because it will be ignored
> by the tick-broadcast code.
> 
> If the local timer could be shutdown at idle time, you *must* specify
> this flag.
> 
> If the idle state shutdowns the cpu with its local timer, you *must*
> specify the CPUIDLE_FLAG_TIMER_STOP flag for this specific state.
> 
> At the first glance, the idle state #2 is aimed to do DDR self refresh
> and to switch to WFI, so no power gating, then no local timer down. The
> CPUIDLE_FLAG_TIMER_STOP shouldn't be used here.
> 
> IIUC, the global timer does not belong to the CPU and the cluster power
> domains, so it can't be shutdown: the C3STOP shouldn't be used.
> 
> I hope that helps.

Thanks for the explanation. I have to discuss with Michal what to do about the
cpuidle driver and then we should be good to use the global timer.

	Thanks,
	S?ren




From julien.grall at linaro.org  Mon Jul 29 12:06:05 2013
From: julien.grall at linaro.org (Julien Grall)
Date: Mon, 29 Jul 2013 17:06:05 +0100
Subject: [PATCH] xen/arm: missing put_cpu in xen_percpu_init
Message-ID: <1375113966-2859-1-git-send-email-julien.grall@linaro.org>

When CONFIG_PREEMPT is enabled, Linux will not be able to boot and warn:
[    4.127825] ------------[ cut here ]------------
[    4.133376] WARNING: at init/main.c:699 do_one_initcall+0x150/0x158()
[    4.140738] initcall xen_init_events+0x0/0x10c returned with preemption imbalance

This is because xen_percpu_init uses get_cpu but doesn't have the corresponding
put_cpu.

Signed-off-by: Julien Grall <julien.grall at linaro.org>
---
 arch/arm/xen/enlighten.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index f71c37e..dc9f284 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -170,6 +170,7 @@ static void __init xen_percpu_init(void *unused)
 	per_cpu(xen_vcpu, cpu) = vcpup;
 
 	enable_percpu_irq(xen_events_irq, 0);
+	put_cpu();
 }
 
 static void xen_restart(char str, const char *cmd)
-- 
1.7.10.4



From linus.walleij at linaro.org  Mon Jul 29 12:20:13 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 Jul 2013 18:20:13 +0200
Subject: [PATCH 07/10] pinctrl: sunxi: Add Allwinner A31 pins set
In-Reply-To: <1374618312-19001-8-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374618312-19001-8-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <CACRpkdZ1RhsLMC0xWDDr9Hmy78i+uU-9x0-2Y+_NvRZ-yefmVw@mail.gmail.com>

On Wed, Jul 24, 2013 at 12:25 AM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:

> The Allwinner A31 SoC uses the same IP than the one found in the
> A10/A13, with only different pins. Add the pins and the associated
> functions found in the A31.
>
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Will you carry this through ARM SoC or do you want me to merge
this into the pinctrl tree? It seems pretty independent.

Yours,
Linus Walleij


From grundler at chromium.org  Mon Jul 29 12:22:01 2013
From: grundler at chromium.org (Grant Grundler)
Date: Mon, 29 Jul 2013 09:22:01 -0700
Subject: [PATCH v8 03/12] iommu/exynos: fix page table maintenance
In-Reply-To: <004e01ce8c3c$9480f9d0$bd82ed70$@samsung.com>
References: <003901ce89f3$126c0390$37440ab0$@samsung.com>
 <CANEJEGvp1msjkMLN-8TfykYXmrT+sq8dMkNsVEoh9i2vDoh=tg@mail.gmail.com>
 <004e01ce8c3c$9480f9d0$bd82ed70$@samsung.com>
Message-ID: <CANEJEGs-fMeK2yzwyx-jr6iCnNbaG0owC12-i3c8hqjUkpQbPA@mail.gmail.com>

On Mon, Jul 29, 2013 at 2:18 AM, Cho KyongHo <pullip.cho at samsung.com> wrote:
...
>> > @@ -908,7 +916,7 @@ static int lv2set_page(unsigned long *pent, phys_addr_t paddr, size_t size,
>> >                 int i;
>> >                 for (i = 0; i < SPAGES_PER_LPAGE; i++, pent++) {
>> >                         if (!lv2ent_fault(pent)) {
>> > -                               memset(pent, 0, sizeof(*pent) * i);
>> > +                               clear_page_table(pent - i, i);
>> >                                 return -EADDRINUSE;
>>
>> I am wondering about two issues with this error handling:
>> 1) we don't call pgtable_flush() in this case - I think just for
>> consistency we should - don't rush to add since my next comment is to
>> change this error handling completely.
>>
> clear_page_table() is called for the page table entries that are already
> fault pages. That is why it does not contain cache flush.
>
>> 2) If  -EADDRINUSE is correct, why does the code clear the IO Page
>> table entries?
>>
>>    I think this error path should either
>>    (a) BUG_ON (ie panic) since this is an inconsistency between
>> generic IOMMU page allocation and chip specific IOMMU mapping code OR
>>    (b) WARN_ON, not clear the entries, and hope whoever was using it
>> can finish using the system before crashing or gracefully shutting
>> down.
>>
>> In any case, I'm pretty sure this code needs to change and it should
>> be in a follow up to this series.
>
> Yes, you're right. But I worried the case that a kernel module calls IOMMU API
> functions directly and does not want to make kernel panic when it tries to map
> a region that is already in use.

Using a DMA address for a different physical page while the current
mapping is still active can only be a bug. I can confidently say there
is no way to map the same DMA address twice (at least not for a single
page table.)  We can try to fail the mapping somehow and WARN_ON to
indicate we had a "Re-Use before free" type bug.

> I also wonder if the such kernel module exists.

I believe the kernel will never do this.

> WARN_ON is also a good idea.

After this series goes in, post another patch and I'd be happy to
review that as well.

After thinking about it more, I'm also ok with removing this code.
It's a very "defensive" code to catch errors in the generic IOMMU code
that probably no longer exist. Or maybe just make it
"CONFIG_DEBUG_IOMMU_ALLOC" or something like that.

cheers,
grant


From arnd at arndb.de  Mon Jul 29 12:35:20 2013
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 29 Jul 2013 18:35:20 +0200
Subject: [PATCH v4] dmaengine: Add MOXA ART DMA engine driver
In-Reply-To: <1375105442-14827-1-git-send-email-jonas.jensen@gmail.com>
References: <1374055584-15746-1-git-send-email-jonas.jensen@gmail.com>
 <1375105442-14827-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <201307291835.21151.arnd@arndb.de>

On Monday 29 July 2013, Jonas Jensen wrote:

> diff --git a/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt b/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt
> new file mode 100644
> index 0000000..f18f0fb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt
> @@ -0,0 +1,19 @@
> +MOXA ART DMA Controller
> +
> +See dma.txt first
> +
> +Required properties:
> +
> +- compatible : Must be "moxa,moxart-dma"
> +- reg : Should contain registers location and length
> +- interrupts : Should contain the interrupt number
> +- #dma-cells : see dma.txt, should be 1
> +
> +Example:
> +
> +	dma: dma at 90500000 {
> +		compatible = "moxa,moxart-dma";
> +		reg = <0x90500000 0x1000>;
> +		interrupts = <24 0>;
> +		#dma-cells = <1>;
> +	};

The binding should really define what the one cell in the dma specifier refers
to. For all I can tell, it is a hardcoded channel number, and each channel
corresponds to exactly one slave request line.

> +static DEFINE_SPINLOCK(dma_lock);

Can't this be part of the device structure? You should not need a global lock here.

> +struct moxart_dma_container {
> +	int			ctlr;
> +	struct dma_device	dma_slave;
> +	struct moxart_dma_chan	slave_chans[APB_DMA_MAX_CHANNEL];
> +};
> +
> +struct moxart_dma_container *mdc;

Same here. Also, you should never have global identifiers with just three characters.
Most of your 'static' variables are already prefixed "moxart_".

> +static int moxart_slave_config(struct dma_chan *chan,
> +			       struct dma_slave_config *cfg)
> +{
> +	struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
> +	union moxart_dma_reg_cfg mcfg;
> +	unsigned long flags;
> +	unsigned int data_width, data_inc;
> +
> +	spin_lock_irqsave(&dma_lock, flags);
> +
> +	memcpy(&mchan->cfg, cfg, sizeof(mchan->cfg));
> +
> +	mcfg.ul = readl(&mchan->reg->cfg.ul);
> +	mcfg.bits.burst = APB_DMAB_BURST_MODE;
> +
> +	switch (mchan->cfg.src_addr_width) {
> +	case DMA_SLAVE_BUSWIDTH_1_BYTE:
> +		data_width = APB_DMAB_DATA_WIDTH_1;
> +		data_inc = APB_DMAB_DEST_INC_1_4;
> +		break;
> +	case DMA_SLAVE_BUSWIDTH_2_BYTES:
> +		data_width = APB_DMAB_DATA_WIDTH_2;
> +		data_inc = APB_DMAB_DEST_INC_2_8;
> +		break;
> +	default:
> +		data_width = APB_DMAB_DATA_WIDTH_4;
> +		data_inc = APB_DMAB_DEST_INC_4_16;
> +		break;
> +	}
> +
> +	if (mchan->cfg.direction == DMA_MEM_TO_DEV) {
> +		mcfg.bits.data_width = data_width;
> +		mcfg.bits.dest_sel = APB_DMAB_DEST_APB;
> +		mcfg.bits.dest_inc = APB_DMAB_DEST_INC_0;
> +		mcfg.bits.source_sel = APB_DMAB_SOURCE_AHB;
> +		mcfg.bits.source_inc = data_inc;
> +
> +		mcfg.bits.dest_req_no = mchan->cfg.slave_id;
> +		mcfg.bits.source_req_no = 0;

You must not override the "dest_req_no" and "dest_req_no" in moxart_slave_config
since they are already set by the ->xlate() function and the driver calling 
slave_config generally has no knowledge of what the slave id is.

> +static struct platform_driver moxart_driver;

Please reorder the symbols so you don't need the forward declaration.

> +bool moxart_filter_fn(struct dma_chan *chan, void *param)
> +{
> +	if (chan->device->dev->driver == &moxart_driver.driver) {

No need to check the driver. What you want to check instead is that
the *device* matches.

> +		struct moxart_dma_chan *mchan = to_moxart_dma_chan(chan);
> +		unsigned int ch_req = *(unsigned int *)param;
> +		dev_dbg(chan2dev(chan), "%s: mchan=%p ch_req=%d mchan->ch_num=%d\n",
> +			__func__, mchan, ch_req, mchan->ch_num);
> +		return ch_req == mchan->ch_num;
> +	} else {
> +		dev_dbg(chan2dev(chan), "%s: device not registered to this DMA engine\n",
> +			__func__);
> +		return false;
> +	}
> +}
> +EXPORT_SYMBOL(moxart_filter_fn);

Don't export the filter function. No slave driver should rely on this, since you
have DT probing.


> diff --git a/drivers/dma/moxart-dma.h b/drivers/dma/moxart-dma.h
> new file mode 100644
> index 0000000..a37b13f
> --- /dev/null
> +++ b/drivers/dma/moxart-dma.h

You don't need a separate file here, just move the contents into moxart-dma.c

> +union moxart_dma_reg_cfg {
> +
> +#define APB_DMA_ENABLE				BIT(0)
> +#define APB_DMA_FIN_INT_STS			BIT(1)
> +#define APB_DMA_FIN_INT_EN			BIT(2)
> +#define APB_DMA_BURST_MODE			BIT(3)
> +#define APB_DMA_ERR_INT_STS			BIT(4)
> +#define APB_DMA_ERR_INT_EN			BIT(5)
> +#define APB_DMA_SOURCE_AHB			BIT(6)
> +#define APB_DMA_SOURCE_APB			0
> +#define APB_DMA_DEST_AHB			BIT(7)
> +#define APB_DMA_DEST_APB			0
> +#define APB_DMA_SOURCE_INC_0			0
> +#define APB_DMA_SOURCE_INC_1_4			0x100
> +#define APB_DMA_SOURCE_INC_2_8			0x200
> +#define APB_DMA_SOURCE_INC_4_16			0x300
> +#define APB_DMA_SOURCE_DEC_1_4			0x500
> +#define APB_DMA_SOURCE_DEC_2_8			0x600
> +#define APB_DMA_SOURCE_DEC_4_16			0x700
> +#define APB_DMA_SOURCE_INC_MASK			0x700
> +#define APB_DMA_DEST_INC_0			0
> +#define APB_DMA_DEST_INC_1_4			0x1000
> +#define APB_DMA_DEST_INC_2_8			0x2000
> +#define APB_DMA_DEST_INC_4_16			0x3000
> +#define APB_DMA_DEST_DEC_1_4			0x5000
> +#define APB_DMA_DEST_DEC_2_8			0x6000
> +#define APB_DMA_DEST_DEC_4_16			0x7000
> +#define APB_DMA_DEST_INC_MASK			0x7000
> +#define APB_DMA_DEST_REQ_NO_MASK		0xf0000
> +#define APB_DMA_DATA_WIDTH_MASK			0x300000
> +#define APB_DMA_DATA_WIDTH_4			0
> +#define APB_DMA_DATA_WIDTH_2			0x100000
> +#define APB_DMA_DATA_WIDTH_1			0x200000
> +#define APB_DMA_SOURCE_REQ_NO_MASK		0xf000000
> +	unsigned int ul;
> +
> +	struct {
> +
> +#define APB_DMAB_ENABLE				1
> +		/* enable DMA */
> +		unsigned int enable:1;
> +
> +#define APB_DMAB_FIN_INT_STS			1
> +		/* finished interrupt status */
> +		unsigned int fin_int_sts:1;

The bit numbers don't actually match here if you build the kernel as
big-endian. You cannot use bitfields for hw data structures.

While you are here, get rid of the silly 'BIT' macro use as well.
Using hexadecimal literals is much clearer and you do that for
some fields anyway.

	Arnd


From linus.walleij at linaro.org  Mon Jul 29 12:39:29 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 Jul 2013 18:39:29 +0200
Subject: [PATCH 06/27] drivers/i2c/busses: don't check resource with
 devm_ioremap_resource
In-Reply-To: <1374602524-3398-7-git-send-email-wsa@the-dreams.de>
References: <1374602524-3398-1-git-send-email-wsa@the-dreams.de>
 <1374602524-3398-7-git-send-email-wsa@the-dreams.de>
Message-ID: <CACRpkdba0FHnWsCkNOEevmqvD9hZ_mroJ+mqbpjecG7sTAfBFw@mail.gmail.com>

On Tue, Jul 23, 2013 at 8:01 PM, Wolfram Sang <wsa at the-dreams.de> wrote:

> devm_ioremap_resource does sanity checks on the given resource. No need to
> duplicate this in the driver.
>
> Signed-off-by: Wolfram Sang <wsa at the-dreams.de>
> ---
> Please apply via the subsystem-tree.

Are you talking to yourself ;-)

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From b.brezillon at overkiz.com  Mon Jul 29 12:44:03 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Mon, 29 Jul 2013 18:44:03 +0200
Subject: [PATCH v2 00/42] ARM: at91: move to common clk framework
In-Reply-To: <CACQ1gAirPir5vCyeK7OKHjw806Sv_LTiorDAp5mvhObxNTE3FA@mail.gmail.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <51F28370.6050304@gmail.com> <51F2996B.6000406@overkiz.com>
 <51F2A556.8020109@overkiz.com>
 <CACQ1gAgw-v3z_sWcsk7SqFFW-ERLjS0RS5GTgAdd5Y1tj3Z1FA@mail.gmail.com>
 <51F63516.8090000@overkiz.com>
 <CACQ1gAi53KN=zE8zDxQO=+BY2zvQXakD=OSuzUqc0VLwWLySCA@mail.gmail.com>
 <51F67D7F.1050906@overkiz.com>
 <CACQ1gAirPir5vCyeK7OKHjw806Sv_LTiorDAp5mvhObxNTE3FA@mail.gmail.com>
Message-ID: <51F69BD3.508@overkiz.com>

On 29/07/2013 17:09, Richard Genoud wrote:
> 2013/7/29 boris brezillon <b.brezillon at overkiz.com>:
>> On 29/07/2013 16:18, Richard Genoud wrote:
>>> 2013/7/29 boris brezillon <b.brezillon at overkiz.com>:
>>>> On 29/07/2013 10:00, Richard Genoud wrote:
>>>>> 2013/7/26 boris brezillon <b.brezillon at overkiz.com>:
>>>>>> On 26/07/2013 17:44, boris brezillon wrote:
>>>>>> I found 2 bugs:
>>>>>> 1) the main frequency ready test in recalc_rate function is wrong
>>>>>> 2) the common clk framework uses the first match for dt clk
>>>>>> registration
>>>>>>       and main clk has this compatible property:
>>>>>>       compatible = "atmel,at91rm9200-clk-main", "fixed-clock";
>>>>>>       As a result the main clk is always bound to the fixed-clock driver
>>>>>>       which set the clock frequency to 0 if 'clock-frequency' property
>>>>>> is
>>>>>>       missing.
>>>>>>
>>>>>> These bugs will be fixed in next version.
>>>>>> Tell me if you want need thesse patches for testing purpose.
>>>>> Hi Boris,
>>>>>
>>>>> I tested your patch, the clock is not at 0 anymore:
>>>>> AT91: PIT: mck rate = 8333333
>>>>>
>>>>> And it's booting correctly.
>>>>> There's a small bug I found in the at91sam9x5 dtsi file (ssc id is 28,
>>>>> not 27). (patch attached)
>>>>>
>>>>> And yes, I could use your patches for some more tests !
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Richard.
>>>> Hi Richard,
>>>>
>>>> Thanks for the bug report.
>>>>
>>>> You'll find in attachements the pre-v3 series fixing the detected bugs
>>>> (including the ssc clock id bug).
>>>>
>>>> If you need anything else please let me know.
>>> Working on sam9g35ek !
>>> you can add my:
>>> Tested-by: Richard Genoud <richard.genoud at gmail.com>
>>>
>>>
>>> One remark though:
>>> Maybe it would be interesting to keep using the defines in the device
>>> tree for peripheral IDs.
>>> For instance, in arch/arm/boot/dts/at91sam9x5.dtsi : (patch 33)
>>> ssc_clk at 28 {
>>>          id = <28>;
>>> };
>>> May be more readable with the SSC id AT91SAM9X5_ID_SSC, as it was
>>> defined in arch/arm/mach-at91/at91sam9x5.c (removed with patch 20)
>>>
>>> IMHO, all AT91SAM9X5_ID_xxx in
>>> arch/arm/mach-at91/include/mach/at91sam9x5.h can me moved in
>>> include/dt-bindings/ and used in at91sam9x5.dtsi
>> This was requested by Jean-Christophe too.
>> I'll add these macro files and make use of it in next version.
>>
>> BTW where should I put these macro files
>> (include/dt-bindings/at91/'soc-name'/peripherals.h) ?
> That sounds correct I suppose.
I guess I should do the same for system clks :-).
>> Should I use macros for address fied of clocks or just for id property (or
>> drop the address) ?
>>
>> ssc_clk at AT91SAM9X5_ID_SSC {
>>          id = <AT91SAM9X5_ID_SSC>;
>> };
>>
>> or
>>
>> ssc_clk at 28 {
>>          id = <AT91SAM9X5_ID_SSC>;
>> };
>>
>> or
>>
>> ssc_clk {
>>          id = <AT91SAM9X5_ID_SSC>;
>> };
> I would drop the address, since the names are always different (for
> instance, dma0_clk and dma1_clk are used).
> And the define should also be used here:
> ssc0: ssc at f0010000 { [...]
> clocks = <&periph AT91SAM9X5_ID_SSC>;
> [...]
> }



From swarren at wwwdotorg.org  Mon Jul 29 12:49:47 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 10:49:47 -0600
Subject: Board-specific GPIO setup code
In-Reply-To: <51F568AD.8030001@prisktech.co.nz>
References: <51F568AD.8030001@prisktech.co.nz>
Message-ID: <51F69D2B.6030605@wwwdotorg.org>

On 07/28/2013 12:53 PM, Tony Prisk wrote:
> On the Wandboard (IMX6Q SoC), there is a WiFi module connected via SDIO
> that requires a reset procedure to enable it. This would be board
> specific setup, but gpio_* functions can't be used in
> arch/arm/mach-imx/imx6q.c
> 
> What would be the correct place to perform the reset code (basically a
> series of gpio calls) to reset the WiFi controller or should it be done
> earlier in uboot?

The correct approach is probably to enhance the SDIO controller (or SDIO
core) to know how to power/reset/... the device that's attached to it.
For WiFi, this probably also includes turning on a clock to the
conencted device too. Hopefully this is all common enough that the same
set of signals/sequencing/... works for all connected devices, so we
don't have to do custom stuff on different boards.


From Dave.Martin at arm.com  Mon Jul 29 12:49:05 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Mon, 29 Jul 2013 17:49:05 +0100
Subject: Defining schemas for Device Tree
In-Reply-To: <20130729150124.GS29916@titan.lakedaemon.net>
References: <2469263.vMN09Q7Tzi@flatron>
 <20130729150124.GS29916@titan.lakedaemon.net>
Message-ID: <20130729164905.GB2280@localhost.localdomain>

On Mon, Jul 29, 2013 at 11:01:24AM -0400, Jason Cooper wrote:
> On Mon, Jul 29, 2013 at 02:21:52AM +0200, Tomasz Figa wrote:
> > Hi,
> > 
> > As promised I am starting a discussion about Device Tree schema. Let's 
> > first shortly introduce the problem.
> > 
> > Device Tree is a text-based data structure used to describe hardware.
> 
> Just a clarifying point here:  I think it would be more accurate to say
> "devicetree describes how hardware on a given board is *configured*".
> The driver learns from the compatible property which IP block it is
> dealing with and handles the necessary quirks.  How that IP block is
> attached, and interfaced with is DT territory, that it needs an extra
> 10ns delay (outside of spec) is something the driver should know and
> work around.
> 
> > Its 
> > main point is separation from kernel code, which has a lot of benefits, 
> > but, at the moment, also a huge drawback - there is no verification of 
> > device tree sources against defined bindings. All the dtc compiler does 
> > currently are syntax checks - no semantic analysis is performed (except
> > some really basic things). What this means is that anybody can put
> > anything in their device tree and end up with the dts compiling fine only
> > to find out that something is wrong at boot time.
> > 
> > Currently, device tree bindings are described in plain text documentation 
> > files, which can not be considered a formal way of binding description. 
> > While such documentation provides information for developers/users that 
> > need to work with particular bindings, it can not be easily used as input 
> > for validation of device tree sources. This means that we need to define a 
> > more formal way of binding description, in other words - Device Tree 
> > schema.
> 
> +1
> 
> > To find a solution for this problem, we must first answer several 
> > questions to determine a set of requirements we have to meet.
> > 
> > a) What is a device tree binding?
> >  
> > For our purposes, I will define a binding as internal format of some 
> > device tree node, which can be matched using of_find_matching_node(). In 
> > other words, key for a binding would be node name and/or value of 
> > compatible property and/or node type. Value for a binding would be a list 
> > of properties with their formats and/or subnodes with their bindings.
> >  
> > b) What information should be specified in schemas? What level of 
> >    granularity is required?
> 
> One item I don't see in this list is node ordering.  There's been some
> discussion lately on deferred probing (re boot times).  If we were to
> intentionally declare that DT are parsed in the order written, then a
> lot of deferred probes could be avoided by moving eg the pinctrl node to
> near the top of the tree.
> 
> This doesn't impact buses as much, since the nodes needing the bus are
> already children.  However, anything accessed via phandles: pins,
> clocks, regulators, etc could benefit from declaring and enforcing this.
> Eg having the dtc warn when a phandle is used before it's corresponding
> node is declared.
> 
> Not critical though, just a thought.

I don't think that siblings have any defined order in DT.  If reading a
device tree, there's no guarantee you get nodes or properties out in the
same order as the original .dts file.

Provided child/parent relationships are maintained and the set of nodes
and values is the same, I think completely rearranging a .dts file does
not change its meaning.

"depends-on" relationships mostly have to come from the semantics of
the bindings themselves: for example, if a device is connected to some
clocks and regulators, the kernel may need to probe those first.

Cheers
---Dave


From nm at ti.com  Mon Jul 29 13:03:00 2013
From: nm at ti.com (Nishanth Menon)
Date: Mon, 29 Jul 2013 12:03:00 -0500
Subject: [PATCH V2 0/3] ARM: dts: omap5-uevm: fixup wrong regulator
 configuration
In-Reply-To: <51F67D7D.9070003@ti.com>
References: <51F67D7D.9070003@ti.com>
Message-ID: <1375117383-19285-1-git-send-email-nm@ti.com>

Due to wrong older revision of documentation used as reference, we
seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
series is based power tree on production board 750-2628-XXX platform.
Unfortunately, the wrong voltages may be detrimental to OMAP5 as they
supply hardware blocks at voltages that are out of specification.

Also available at:
based on v3.11-rc1 tag
http link: https://github.com/nmenon/linux-2.6-playground/commits/push/omap5-palmas-fixes-v2
git link: git://github.com/nmenon/linux-2.6-playground.git
branch: push/omap5-palmas-fixes-v2

Changes since V1:
 - squash of patches
 - picked up Ack from Keerthy
 - based on v3.11-rc3 tag

V1: http://marc.info/?t=137407980100008&r=1&w=2

Nishanth Menon (3):
  ARM: dts: omap5-uevm: document regulator signals used on the actual
    board
  ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC
  ARM: dts: omap5-uevm: update optional/unused regulator configurations

 arch/arm/boot/dts/omap5-uevm.dts |   78 ++++++++++++++++++++++++--------------
 1 file changed, 49 insertions(+), 29 deletions(-)

Regards,
Nishanth Menon
-- 
1.7.9.5



From nm at ti.com  Mon Jul 29 13:03:03 2013
From: nm at ti.com (Nishanth Menon)
Date: Mon, 29 Jul 2013 12:03:03 -0500
Subject: [PATCH V2 3/3] ARM: dts: omap5-uevm: update optional/unused regulator
 configurations
In-Reply-To: <1375117383-19285-1-git-send-email-nm@ti.com>
References: <51F67D7D.9070003@ti.com>
 <1375117383-19285-1-git-send-email-nm@ti.com>
Message-ID: <1375117383-19285-4-git-send-email-nm@ti.com>

commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.

The following optional/unused regulators can be updated:

- SMPS9 supplies TWL6040 over VDDA_2v1_AUD. This regulator needs to be
enabled only when audio is active. Since it does not come active by
default, it does not require "always-on" or "boot-on".

- LDO2 and LDO8 do not go to any peripheral or connector on the board.
Further, these unused regulators should have been 2.8V for LDO2 and
3.0V for LDO8. Mark these LDOs as disabled in the dts until needed.

Reported-by: Marc J?ttner <m-juettner at ti.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
Acked-by: J Keerthy <j-keerthy at ti.com>
---

V2: squash of multiple patches from V1, as suggested in:
	http://marc.info/?l=devicetree&m=137510852731656&w=2

 arch/arm/boot/dts/omap5-uevm.dts |   17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 247c03c..65d7b60 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -331,8 +331,6 @@
 					regulator-name = "smps9";
 					regulator-min-microvolt = <2100000>;
 					regulator-max-microvolt = <2100000>;
-					regulator-always-on;
-					regulator-boot-on;
 					ti,smps-range = <0x80>;
 				};
 
@@ -355,10 +353,10 @@
 				ldo2_reg: ldo2 {
 					/* VCC_2V8_DISP: Does not go anywhere */
 					regulator-name = "ldo2";
-					regulator-min-microvolt = <2900000>;
-					regulator-max-microvolt = <2900000>;
-					regulator-always-on;
-					regulator-boot-on;
+					regulator-min-microvolt = <2800000>;
+					regulator-max-microvolt = <2800000>;
+					/* Unused */
+					status = "disabled";
 				};
 
 				ldo3_reg: ldo3 {
@@ -408,10 +406,11 @@
 				ldo8_reg: ldo8 {
 					/* VDD_3v0: Does not go anywhere */
 					regulator-name = "ldo8";
-					regulator-min-microvolt = <1500000>;
-					regulator-max-microvolt = <1500000>;
-					regulator-always-on;
+					regulator-min-microvolt = <3000000>;
+					regulator-max-microvolt = <3000000>;
 					regulator-boot-on;
+					/* Unused */
+					status = "disabled";
 				};
 
 				ldo9_reg: ldo9 {
-- 
1.7.9.5



From nm at ti.com  Mon Jul 29 13:03:01 2013
From: nm at ti.com (Nishanth Menon)
Date: Mon, 29 Jul 2013 12:03:01 -0500
Subject: [PATCH V2 1/3] ARM: dts: omap5-uevm: document regulator signals used
 on the actual board
In-Reply-To: <1375117383-19285-1-git-send-email-nm@ti.com>
References: <51F67D7D.9070003@ti.com>
 <1375117383-19285-1-git-send-email-nm@ti.com>
Message-ID: <1375117383-19285-2-git-send-email-nm@ti.com>

commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, currently we use the Palmas regulator names which is used for
different purposes on uEVM. Document the same based on 750-2628-XXX
boards - which is meant to be supported by this dts.

Reported-by: Marc J?ttner <m-juettner at ti.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
Acked-by: J Keerthy <j-keerthy at ti.com>
---

V2: no change
V1: https://patchwork.kernel.org/patch/2828862/

 arch/arm/boot/dts/omap5-uevm.dts |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b430b8f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -282,6 +282,7 @@
 
 			regulators {
 				smps123_reg: smps123 {
+					/* VDD_OPP_MPU */
 					regulator-name = "smps123";
 					regulator-min-microvolt = < 600000>;
 					regulator-max-microvolt = <1500000>;
@@ -290,6 +291,7 @@
 				};
 
 				smps45_reg: smps45 {
+					/* VDD_OPP_MM */
 					regulator-name = "smps45";
 					regulator-min-microvolt = < 600000>;
 					regulator-max-microvolt = <1310000>;
@@ -298,6 +300,7 @@
 				};
 
 				smps6_reg: smps6 {
+					/* VDD_DDR3 - over VDD_SMPS6 */
 					regulator-name = "smps6";
 					regulator-min-microvolt = <1200000>;
 					regulator-max-microvolt = <1200000>;
@@ -306,6 +309,7 @@
 				};
 
 				smps7_reg: smps7 {
+					/* VDDS_1v8_OMAP over VDDS_1v8_MAIN */
 					regulator-name = "smps7";
 					regulator-min-microvolt = <1800000>;
 					regulator-max-microvolt = <1800000>;
@@ -314,6 +318,7 @@
 				};
 
 				smps8_reg: smps8 {
+					/* VDD_OPP_CORE */
 					regulator-name = "smps8";
 					regulator-min-microvolt = < 600000>;
 					regulator-max-microvolt = <1310000>;
@@ -322,6 +327,7 @@
 				};
 
 				smps9_reg: smps9 {
+					/* VDDA_2v1_AUD over VDD_2v1 */
 					regulator-name = "smps9";
 					regulator-min-microvolt = <2100000>;
 					regulator-max-microvolt = <2100000>;
@@ -331,6 +337,7 @@
 				};
 
 				smps10_reg: smps10 {
+					/* VBUS_5V_OTG */
 					regulator-name = "smps10";
 					regulator-min-microvolt = <5000000>;
 					regulator-max-microvolt = <5000000>;
@@ -339,6 +346,7 @@
 				};
 
 				ldo1_reg: ldo1 {
+					/* VDDAPHY_CAM: vdda_csiport */
 					regulator-name = "ldo1";
 					regulator-min-microvolt = <2800000>;
 					regulator-max-microvolt = <2800000>;
@@ -347,6 +355,7 @@
 				};
 
 				ldo2_reg: ldo2 {
+					/* VCC_2V8_DISP: Does not go anywhere */
 					regulator-name = "ldo2";
 					regulator-min-microvolt = <2900000>;
 					regulator-max-microvolt = <2900000>;
@@ -355,6 +364,7 @@
 				};
 
 				ldo3_reg: ldo3 {
+					/* VDDAPHY_MDM: vdda_lli */
 					regulator-name = "ldo3";
 					regulator-min-microvolt = <3000000>;
 					regulator-max-microvolt = <3000000>;
@@ -363,6 +373,7 @@
 				};
 
 				ldo4_reg: ldo4 {
+					/* VDDAPHY_DISP: vdda_dsiport/hdmi */
 					regulator-name = "ldo4";
 					regulator-min-microvolt = <2200000>;
 					regulator-max-microvolt = <2200000>;
@@ -371,6 +382,7 @@
 				};
 
 				ldo5_reg: ldo5 {
+					/* VDDA_1V8_PHY: usb/sata/hdmi.. */
 					regulator-name = "ldo5";
 					regulator-min-microvolt = <1800000>;
 					regulator-max-microvolt = <1800000>;
@@ -379,6 +391,7 @@
 				};
 
 				ldo6_reg: ldo6 {
+					/* VDDS_1V2_WKUP: hsic/ldo_emu_wkup */
 					regulator-name = "ldo6";
 					regulator-min-microvolt = <1500000>;
 					regulator-max-microvolt = <1500000>;
@@ -387,6 +400,7 @@
 				};
 
 				ldo7_reg: ldo7 {
+					/* VDD_VPP: vpp1 */
 					regulator-name = "ldo7";
 					regulator-min-microvolt = <1500000>;
 					regulator-max-microvolt = <1500000>;
@@ -395,6 +409,7 @@
 				};
 
 				ldo8_reg: ldo8 {
+					/* VDD_3v0: Does not go anywhere */
 					regulator-name = "ldo8";
 					regulator-min-microvolt = <1500000>;
 					regulator-max-microvolt = <1500000>;
@@ -403,6 +418,7 @@
 				};
 
 				ldo9_reg: ldo9 {
+					/* VCC_DV_SDIO: vdds_sdcard */
 					regulator-name = "ldo9";
 					regulator-min-microvolt = <1800000>;
 					regulator-max-microvolt = <3300000>;
@@ -411,6 +427,7 @@
 				};
 
 				ldoln_reg: ldoln {
+					/* VDDA_1v8_REF: vdds_osc/mm_l4per.. */
 					regulator-name = "ldoln";
 					regulator-min-microvolt = <1800000>;
 					regulator-max-microvolt = <1800000>;
@@ -419,6 +436,7 @@
 				};
 
 				ldousb_reg: ldousb {
+					/* VDDA_3V_USB: VDDA_USBHS33 */
 					regulator-name = "ldousb";
 					regulator-min-microvolt = <3250000>;
 					regulator-max-microvolt = <3250000>;
-- 
1.7.9.5



From nm at ti.com  Mon Jul 29 13:03:02 2013
From: nm at ti.com (Nishanth Menon)
Date: Mon, 29 Jul 2013 12:03:02 -0500
Subject: [PATCH V2 2/3] ARM: dts: omap5-uevm: fix regulator configurations
 mandatory for SoC
In-Reply-To: <1375117383-19285-1-git-send-email-nm@ti.com>
References: <51F67D7D.9070003@ti.com>
 <1375117383-19285-1-git-send-email-nm@ti.com>
Message-ID: <1375117383-19285-3-git-send-email-nm@ti.com>

commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.

However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.

The following fixes are hence mandatory to ensure right voltage is
supplied to key OMAP5 SoC voltage rails:

- LDO1 supplies VDDAPHY_CAM which is OMAP5's vdda_csiporta/b/c. This
can only be supplied at 1.5V or 1.8V and we currently supply 2.8V.

To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.

Remove 'always-on' and 'boot-on' settings here as it is
a 'on need' supply to SoC IP and is not enabled by PMIC by
default at boot.

- LDO3 supplies Low Latency Interface(LLI) hardware module which is a
special hardware to communicate with Modem. However since uEVM is
not setup by default for this communication, this should be disabled
by default.

Further, vdda_lli is supposed to be 1.5V and not 3V.

- LDO4 supplies VDDAPHY_DISP which is vdda_dsiporta/c/vdda_hdmi

This can only be supplied at 1.5V or 1.8V and we currently
supply 2.2V.

To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.

Remove 'always-on' and 'boot-on' settings here as it is a 'on need'
supply to SoC IP and is not enabled by PMIC by default at boot.

- LDO6 supplies the board specified VDDS_1V2_WKUP supply going to
ldo_emu_wkup/vdds_hsic. To stay within the SoC specification supply
1.2V instead of 1.5V.

- LDO7 supplies VDD_VPP which is vpp1. This is currently configured for
1.5V which as per data manual "A pulse width of 1000 ns and an amplitude
of 2V is required to program each eFuse bit. Otherwise, VPP1 must not
be supplied".

So, fix the voltage to 2V. and disable the supply since we have no plans
of programming efuse bits - it can only be done once - in factory.

Further it is not enabled by default by PMIC so, 'boot-on' must be
removed, and the 'always-on' needs to be removed to achieve pulsing
if efuse needs to be programmed.

- LDO9 supplies the board specified vdds_sdcard supply going within SoC
specification of 1.8V or 3.0V. Further the supply is controlled by
switch enabled by REGEN3. So, introduce REGEN3 and map sdcard slot to
be powered by LDO9. Remove 'always-on' allowing the LDO to be disabled
on need basis.

Reported-by: Marc J?ttner <m-juettner at ti.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
Acked-by: J Keerthy <j-keerthy at ti.com>
---

V2: squash of multiple patches from V1, as suggested in:
	http://marc.info/?l=devicetree&m=137510852731656&w=2

 arch/arm/boot/dts/omap5-uevm.dts |   43 ++++++++++++++++++++------------------
 1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index b430b8f..247c03c 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -235,7 +235,7 @@
 };
 
 &mmc1 {
-	vmmc-supply = <&vmmcsd_fixed>;
+	vmmc-supply = <&ldo9_reg>;
 	bus-width = <4>;
 };
 
@@ -348,10 +348,8 @@
 				ldo1_reg: ldo1 {
 					/* VDDAPHY_CAM: vdda_csiport */
 					regulator-name = "ldo1";
-					regulator-min-microvolt = <2800000>;
-					regulator-max-microvolt = <2800000>;
-					regulator-always-on;
-					regulator-boot-on;
+					regulator-min-microvolt = <1500000>;
+					regulator-max-microvolt = <1800000>;
 				};
 
 				ldo2_reg: ldo2 {
@@ -366,19 +364,18 @@
 				ldo3_reg: ldo3 {
 					/* VDDAPHY_MDM: vdda_lli */
 					regulator-name = "ldo3";
-					regulator-min-microvolt = <3000000>;
-					regulator-max-microvolt = <3000000>;
-					regulator-always-on;
+					regulator-min-microvolt = <1500000>;
+					regulator-max-microvolt = <1500000>;
 					regulator-boot-on;
+					/* Only if Modem is used */
+					status = "disabled";
 				};
 
 				ldo4_reg: ldo4 {
 					/* VDDAPHY_DISP: vdda_dsiport/hdmi */
 					regulator-name = "ldo4";
-					regulator-min-microvolt = <2200000>;
-					regulator-max-microvolt = <2200000>;
-					regulator-always-on;
-					regulator-boot-on;
+					regulator-min-microvolt = <1500000>;
+					regulator-max-microvolt = <1800000>;
 				};
 
 				ldo5_reg: ldo5 {
@@ -393,8 +390,8 @@
 				ldo6_reg: ldo6 {
 					/* VDDS_1V2_WKUP: hsic/ldo_emu_wkup */
 					regulator-name = "ldo6";
-					regulator-min-microvolt = <1500000>;
-					regulator-max-microvolt = <1500000>;
+					regulator-min-microvolt = <1200000>;
+					regulator-max-microvolt = <1200000>;
 					regulator-always-on;
 					regulator-boot-on;
 				};
@@ -402,10 +399,10 @@
 				ldo7_reg: ldo7 {
 					/* VDD_VPP: vpp1 */
 					regulator-name = "ldo7";
-					regulator-min-microvolt = <1500000>;
-					regulator-max-microvolt = <1500000>;
-					regulator-always-on;
-					regulator-boot-on;
+					regulator-min-microvolt = <2000000>;
+					regulator-max-microvolt = <2000000>;
+					/* Only for efuse reprograming! */
+					status = "disabled";
 				};
 
 				ldo8_reg: ldo8 {
@@ -421,8 +418,7 @@
 					/* VCC_DV_SDIO: vdds_sdcard */
 					regulator-name = "ldo9";
 					regulator-min-microvolt = <1800000>;
-					regulator-max-microvolt = <3300000>;
-					regulator-always-on;
+					regulator-max-microvolt = <3000000>;
 					regulator-boot-on;
 				};
 
@@ -443,6 +439,13 @@
 					regulator-always-on;
 					regulator-boot-on;
 				};
+
+				regen3_reg: regen3 {
+					/* REGEN3 controls LDO9 supply to card */
+					regulator-name = "regen3";
+					regulator-always-on;
+					regulator-boot-on;
+				};
 			};
 		};
 	};
-- 
1.7.9.5



From finn at uni-bremen.de  Mon Jul 29 13:05:32 2013
From: finn at uni-bremen.de (Finn Hoffmann)
Date: Mon, 29 Jul 2013 19:05:32 +0200
Subject: NSA310 + DT
In-Reply-To: <20130710073706.GA28212@lunn.ch>
References: <20130710073706.GA28212@lunn.ch>
Message-ID: <51F6A0DC.3020501@uni-bremen.de>

Hello,

I have tried to get a current Kernel running on my NSA310. Everything 
works well on Kernels before DT with the mentioned patches from 
https://github.com/peeter123/NSA310-320-debian .
I have linux-3.10.2 running and after I changed the dts file to lm85 
sensors and fanconrtol work but GPIO does not.
I tried https://github.com/lunn/linux/tree/v3.11-rc1-nsa310-tdc and 
linux-3.11.0-rc3.
Both have the problem that r8169 is not working:
r8169: eth0: unknown chipset (mac_version = 0).
and console is spammed with
r8169 0000:01:00.0 eth0: rtl_phyar_cond == 0 (loop: 20, delay: 25).
until I take eth0 down.
GPIO is working.

Any ideas?

Finn





From swarren at wwwdotorg.org  Mon Jul 29 13:06:52 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 11:06:52 -0600
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X SoC
 with ARM CPU
In-Reply-To: <20130729132029.GI5022@ohporter.com>
References: <2043662.BcW19XTTMG@lenovo> <20130719020611.GA4941@glitch>
 <20130723185733.GB6811@ohporter.com>
 <CAGVrzcYnoN9NnJGvubS7=bVJDk37xSt4BimtvDWghe7OHEWALQ@mail.gmail.com>
 <20130724231106.GB29801@glitch>
 <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
 <20130726000412.GH5022@linaro.org> <51F2F554.8030709@broadcom.com>
 <51F2F885.2040002@wwwdotorg.org>
 <20130729093000.GI3528@e106331-lin.cambridge.arm.com>
 <20130729132029.GI5022@ohporter.com>
Message-ID: <51F6A12C.30101@wwwdotorg.org>

On 07/29/2013 07:20 AM, Matt Porter wrote:
> On Mon, Jul 29, 2013 at 10:30:00AM +0100, Mark Rutland wrote:
...
>> I'd be happy to have "broadcom" for all *new* bindings, as it's already
>> in some bindings alongside "bcm" and "brcm", and is certainly the
>> clearest of the available options.
>>
>> However, given the strong feelings of many against breaking existing
>> dts, we need to support the existing instances of "bcm" and "brcm" in
> 
> Whoa, how would existing dts break? At this instant in time, all the
> bindings and dts are still in the kernel tree. A series to address this
> make all bindings, drivers, and dts consistent in one shot.

While there are some *.dts files in the kernel source tree, that is no
guarantee that:

a) People don't have custom *.dts files that are not in the kernel
source tree, and hence can't be updated by Linux kernel patches.

b) People actually replace their *.dtb when updating their zImage. Since
DT is explicitly supposed to be an ABI, everything is explicitly
supposed to work if they do only update their zImage and not their *.dtb.


From jgunthorpe at obsidianresearch.com  Mon Jul 29 13:11:00 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Mon, 29 Jul 2013 11:11:00 -0600
Subject: Defining schemas for Device Tree
In-Reply-To: <20130729164905.GB2280@localhost.localdomain>
References: <2469263.vMN09Q7Tzi@flatron>
 <20130729150124.GS29916@titan.lakedaemon.net>
 <20130729164905.GB2280@localhost.localdomain>
Message-ID: <20130729171100.GA15861@obsidianresearch.com>

On Mon, Jul 29, 2013 at 05:49:05PM +0100, Dave Martin wrote:

> Provided child/parent relationships are maintained and the set of nodes
> and values is the same, I think completely rearranging a .dts file does
> not change its meaning.
> 
> "depends-on" relationships mostly have to come from the semantics of
> the bindings themselves: for example, if a device is connected to some
> clocks and regulators, the kernel may need to probe those first.

There is already code in the kernel to sort the interrupt controllers
from DT and start them up in the right order.

I've often thought to myself that the deferred probe hack could be
avoided if some layer in the DT stack could do the same kind of topo
sorting, but more generally.

Just topo-sorting based on phandles would probably get things quite
far along??

Jason


From festevam at gmail.com  Mon Jul 29 13:21:05 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 29 Jul 2013 14:21:05 -0300
Subject: Board-specific GPIO setup code
In-Reply-To: <51F69D2B.6030605@wwwdotorg.org>
References: <51F568AD.8030001@prisktech.co.nz> <51F69D2B.6030605@wwwdotorg.org>
Message-ID: <CAOMZO5DCPvKVJNVp9cZMiMvY3bxhXdjmJs+dqNXdhxDDoSLQmQ@mail.gmail.com>

On Mon, Jul 29, 2013 at 1:49 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/28/2013 12:53 PM, Tony Prisk wrote:
>> On the Wandboard (IMX6Q SoC), there is a WiFi module connected via SDIO
>> that requires a reset procedure to enable it. This would be board
>> specific setup, but gpio_* functions can't be used in
>> arch/arm/mach-imx/imx6q.c
>>
>> What would be the correct place to perform the reset code (basically a
>> series of gpio calls) to reset the WiFi controller or should it be done
>> earlier in uboot?
>
> The correct approach is probably to enhance the SDIO controller (or SDIO
> core) to know how to power/reset/... the device that's attached to it.

Can't we just use the gpio reset driver proposed by Philipp Zabel?
http://www.spinics.net/lists/arm-kernel/msg261771.html

Regards,

Fabio Estevam


From lorenzo.pieralisi at arm.com  Mon Jul 29 13:23:27 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 29 Jul 2013 18:23:27 +0100
Subject: [RFC][PATCH 1/2] ARM64: add cpu topology definition
In-Reply-To: <20130729133625.GA2280@localhost.localdomain>
References: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>
 <CAKfTPtBpo41LJ3V8TB8YwudwqpURuA2u_Lvu4KYVK=qSs+gFuQ@mail.gmail.com>
 <20130729095400.GB32383@mudshark.cambridge.arm.com>
 <20130729133625.GA2280@localhost.localdomain>
Message-ID: <20130729172327.GA20592@e102568-lin.cambridge.arm.com>

On Mon, Jul 29, 2013 at 02:36:30PM +0100, Dave Martin wrote:
> On Mon, Jul 29, 2013 at 10:54:01AM +0100, Will Deacon wrote:
> > On Mon, Jul 29, 2013 at 10:46:06AM +0100, Vincent Guittot wrote:
> > > On 27 July 2013 12:42, Hanjun Guo <hanjun.guo at linaro.org> wrote:
> > > > Power aware scheduling needs the cpu topology information to improve the
> > > > cpu scheduler decision making.
> > > 
> > > It's not only power aware scheduling. The scheduler already uses
> > > topology and cache sharing when  CONFIG_SCHED_MC and/or
> > > CONFIG_SCHED_SMT are enable. So you should also add these configs for
> > > arm64 so the scheduler can use it
> > 
> > ... except that the architecture doesn't define what the AFF fields in MPIDR
> > really represent. Using them to make key scheduling decisions relating to
> 
> In fact, the ARM Architecture doesn't place any requirements on MPIDRs to
> force the aff fields to exist _at all_.  It's just a recommendation.
> Instead, you have a 24 or 32-bit number which is unique per CPU, and which
> is _probably_ assigned in a way resembling the aff fields.
> 
> > cache proximity seems pretty risky to me, especially given the track record
> > we've seen already on AArch32 silicon. It's a convenient register if it
> > contains the data we want it to contain, but we need to force ourselves to
> > come to terms with reality here and simply use it as an identifier for a
> > CPU.
> 
> +1
> 
> Also, we should align arm and arm64.  The problem is basically exactly
> the same, and the solution needs to be the same.  struct cputopo_arm is
> already being abused  -- for example, TC2 describes the A15 and A7
> clusters on a single die as having different "socket_id" values, even
> though this is obviously nonsense.  But there's no other way to describe
> that system today.
> 
> > Can't we just use the device-tree to represent this topological data for
> > arm64? Lorenzo has been working on bindings in this area.
> 
> This may become more important as we start to see things like asymmetric
> topologies appearing (different numbers of nodes and different
> interdependence characteristics in adjacent branches of the topology
> etc.)

Will and Dave summed up the existing issues with MPIDR definition related to
the topology description.

FYI, a link to the current topology bindings posted on DT-discuss and LAKML:

https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-April/031725.html

I am waiting for the dust to settle on the DT bindings review discussions to
repost them and get them finalized.

Lorenzo



From jason at lakedaemon.net  Mon Jul 29 13:23:39 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 29 Jul 2013 13:23:39 -0400
Subject: [Ksummit-2013-discuss] Defining schemas for Device Tree
In-Reply-To: <20130729164905.GB2280@localhost.localdomain>
References: <2469263.vMN09Q7Tzi@flatron>
 <20130729150124.GS29916@titan.lakedaemon.net>
 <20130729164905.GB2280@localhost.localdomain>
Message-ID: <20130729172339.GT29916@titan.lakedaemon.net>

On Mon, Jul 29, 2013 at 05:49:05PM +0100, Dave Martin wrote:
> On Mon, Jul 29, 2013 at 11:01:24AM -0400, Jason Cooper wrote:
> > On Mon, Jul 29, 2013 at 02:21:52AM +0200, Tomasz Figa wrote:

> > > b) What information should be specified in schemas? What level of 
> > >    granularity is required?
> > 
> > One item I don't see in this list is node ordering.  There's been some
> > discussion lately on deferred probing (re boot times).  If we were to
> > intentionally declare that DT are parsed in the order written, then a
> > lot of deferred probes could be avoided by moving eg the pinctrl node to
> > near the top of the tree.
> > 
> > This doesn't impact buses as much, since the nodes needing the bus are
> > already children.  However, anything accessed via phandles: pins,
> > clocks, regulators, etc could benefit from declaring and enforcing this.
> > Eg having the dtc warn when a phandle is used before it's corresponding
> > node is declared.
> > 
> > Not critical though, just a thought.
> 
> I don't think that siblings have any defined order in DT.  If reading a
> device tree, there's no guarantee you get nodes or properties out in the
> same order as the original .dts file.

That's why I raised the point.  If people think encoding initialization
order in the DT is a good idea, then we should change the dtc so it
compiles/decompiles in the same order.

> Provided child/parent relationships are maintained and the set of nodes
> and values is the same, I think completely rearranging a .dts file does
> not change its meaning.
> 
> "depends-on" relationships mostly have to come from the semantics of
> the bindings themselves: for example, if a device is connected to some
> clocks and regulators, the kernel may need to probe those first.

true, the answer to this problem may be to create a depgraph of the
nodes based on phandles and child status, then init.  However, if the
goal is to accelerate boot times, then that should not be calculated
during each boot, especially since it doesn't likely change from boot to
boot.

Which means it would either go in the dtc (dts node ordering is
irrelevant), or in the dts.  I'm inclined to say dtc should do it, but I
like the aesthetics of things being in the proper order in something I
can read.  After all, C requires functions to be declared before use,
even though the compiler could figure it out.

thx,

Jason.


From jgunthorpe at obsidianresearch.com  Mon Jul 29 13:29:52 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Mon, 29 Jul 2013 11:29:52 -0600
Subject: [Ksummit-2013-discuss] Defining schemas for Device Tree
In-Reply-To: <20130729172339.GT29916@titan.lakedaemon.net>
References: <2469263.vMN09Q7Tzi@flatron>
 <20130729150124.GS29916@titan.lakedaemon.net>
 <20130729164905.GB2280@localhost.localdomain>
 <20130729172339.GT29916@titan.lakedaemon.net>
Message-ID: <20130729172952.GA1884@obsidianresearch.com>

On Mon, Jul 29, 2013 at 01:23:39PM -0400, Jason Cooper wrote:

> true, the answer to this problem may be to create a depgraph of the
> nodes based on phandles and child status, then init.  However, if the
> goal is to accelerate boot times, then that should not be calculated
> during each boot, especially since it doesn't likely change from boot to
> boot.

That seems like a really smart idea. dtc could store the startup-order
and dependencies in the dtb someplace and the kernel can just run
through that. Using a combination of declaration order and
topo-phandle sorting would probably cover all cases???

Jason


From swarren at wwwdotorg.org  Mon Jul 29 13:33:58 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 11:33:58 -0600
Subject: Board-specific GPIO setup code
In-Reply-To: <CAOMZO5DCPvKVJNVp9cZMiMvY3bxhXdjmJs+dqNXdhxDDoSLQmQ@mail.gmail.com>
References: <51F568AD.8030001@prisktech.co.nz> <51F69D2B.6030605@wwwdotorg.org>
 <CAOMZO5DCPvKVJNVp9cZMiMvY3bxhXdjmJs+dqNXdhxDDoSLQmQ@mail.gmail.com>
Message-ID: <51F6A786.4080709@wwwdotorg.org>

On 07/29/2013 11:21 AM, Fabio Estevam wrote:
> On Mon, Jul 29, 2013 at 1:49 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 07/28/2013 12:53 PM, Tony Prisk wrote:
>>> On the Wandboard (IMX6Q SoC), there is a WiFi module connected via SDIO
>>> that requires a reset procedure to enable it. This would be board
>>> specific setup, but gpio_* functions can't be used in
>>> arch/arm/mach-imx/imx6q.c
>>>
>>> What would be the correct place to perform the reset code (basically a
>>> series of gpio calls) to reset the WiFi controller or should it be done
>>> earlier in uboot?
>>
>> The correct approach is probably to enhance the SDIO controller (or SDIO
>> core) to know how to power/reset/... the device that's attached to it.
> 
> Can't we just use the gpio reset driver proposed by Philipp Zabel?
> http://www.spinics.net/lists/arm-kernel/msg261771.html

Quite possibly, but the SD binding and driver still would need to be
updated to actually invoke it.

Also, that only covers reset, not any enable GPIO, 32KHz clock,
regulator, etc.


From swarren at wwwdotorg.org  Mon Jul 29 13:41:23 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 11:41:23 -0600
Subject: [PATCH v2 21/22] iommu/tegra: smmu: Support Multiple ASID
In-Reply-To: <20130729.133155.1836775489422797370.hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com><1373021097-32420-22-git-send-email-hdoyu@nvidia.com><51E8535A.30605@wwwdotorg.org>
 <20130729.133155.1836775489422797370.hdoyu@nvidia.com>
Message-ID: <51F6A943.8000004@wwwdotorg.org>

On 07/29/2013 04:31 AM, Hiroshi Doyu wrote:
> Stephen Warren <swarren at wwwdotorg.org> wrote @ Thu, 18 Jul 2013 22:43:06 +0200:
> 
>> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
>>> Support Multiple Address Space(AS). Tegra SMMU can have multiple
>>> ASes. We reserve 2 of them for static assignment, AS[0] for system
>>> default, AS[1] for AHB clusters as protected domain from others, where
>>> there are many traditional pheripheral devices like USB, SD/MMC. They
>>> should be isolated from some smart devices like host1x for system
>>> robustness. Even if smart devices behaves wrongly, the traditional
>>> devices(SD/MMC, USB) wouldn't be affected, and the system could
>>> continue most likely.
>>
>>> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
>>
>>>  static int smmu_iommu_add_device(struct device *dev)
>>>  {
>>>  	int err;
>>> -	struct dma_iommu_mapping *map = smmu_handle->map[SYSTEM_DEFAULT];
>>> +	u64 swgroup;
>>> +	struct dma_iommu_mapping *map = NULL;
>>> +
>>> +	swgroup = smmu_of_get_memory_client(dev);
>>> +	switch (swgroup) {
>>> +	case TEGRA_SWGROUP_BIT(PPCS):
>>> +		map = smmu_handle->map[SYSTEM_PROTECTED];
>>> +		break;
>>> +	default:
>>> +		map = smmu_handle->map[SYSTEM_DEFAULT];
>>
>> I already mentioned this, but just for completeness: What is
>> smmu->num_as <= SYSTEM_DEFAULT?
> 
> I think that this belongs to the system operation policy. Which H/W
> should be configured to which Address Space(AS). This put all AHB
> clients(PPCS) into AS[1](SYSTEM_PROTECTED), and the rest into
> AS[0](SYSTEM_DEFAULT). AHB clients are mainly traditional H/Ws like
> USB and SD/MMC so that they should be kept separated from the smart
> IOMMU clients like host1x.
> 
> Is there any place to configure this kind of board specific policy
> rather than here?

I'm not sure that answers the question I asked.

I mean that the driver expects that two AS always exist;
SYSTEM_PROTECTED and SYSTEM_DEFAULT. However, the set of extant ASs is
IIRC defined by the DT content. What if the DT doesn't define two ASs?
Shouldn't there at least be an error-check for this case, so the driver
doesn't just blindly continue and access smmu_handle->map[1] when the
map[] array only has 1 entry?



From davidb at codeaurora.org  Mon Jul 29 13:43:46 2013
From: davidb at codeaurora.org (David Brown)
Date: Mon, 29 Jul 2013 10:43:46 -0700
Subject: [PATCH v2 1/6] usb: phy: msm: Move mach depndend code to
 platform data
In-Reply-To: <1375081464-14206-2-git-send-email-iivanov@mm-sol.com>
References: <1375081464-14206-1-git-send-email-iivanov@mm-sol.com>
 <1375081464-14206-2-git-send-email-iivanov@mm-sol.com>
Message-ID: <20130729174346.GA16352@codeaurora.org>

On Mon, Jul 29, 2013 at 10:04:19AM +0300, Ivan T. Ivanov wrote:
>From: "Ivan T. Ivanov" <iivanov at mm-sol.com>
>
>This patch fix compilation error and is an intermediate step
>before the addition of DeviceTree support for newer targets.
>Fix suggested here: https://lkml.org/lkml/2013/6/19/381
>
>Cc: David Brown <davidb at codeaurora.org>
>Cc: Daniel Walker <dwalker at fifo99.com>
>Cc: Bryan Huntsman <bryanh at codeaurora.org>
>Cc: Felipe Balbi <balbi at ti.com>
>Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
>Cc: linux-arm-kernel at lists.infradead.org
>Cc: linux-kernel at vger.kernel.org
>Cc: linux-usb at vger.kernel.org
>
>Signed-off-by: Ivan T. Ivanov <iivanov at mm-sol.com>
>---
> arch/arm/mach-msm/board-msm7x30.c |   35 +++++++++++++++++++++++
> arch/arm/mach-msm/board-qsd8x50.c |   35 +++++++++++++++++++++++

Acked-by: David Brown <davidb at codeaurora.org>

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From swarren at wwwdotorg.org  Mon Jul 29 13:45:15 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 11:45:15 -0600
Subject: [PATCH v2 03/22] ARM: tegra: Create a DT header defining swgroups
 ID
In-Reply-To: <20130729.135336.943359637886118972.hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com><1373021097-32420-4-git-send-email-hdoyu@nvidia.com><51E5D220.1070708@wwwdotorg.org>
 <20130729.135336.943359637886118972.hdoyu@nvidia.com>
Message-ID: <51F6AA2B.7050509@wwwdotorg.org>

On 07/29/2013 04:53 AM, Hiroshi Doyu wrote:
> Stephen Warren <swarren at wwwdotorg.org> wrote @ Wed, 17 Jul 2013 01:07:12 +0200:
> 
>> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
>>> Create a header file to define the swgroup IDs used by the IOMMU(SMMU)
>>> binding. "swgroup" is a group of H/W clients in Tegra SoC from S/W POV.
>>>
>>> This will allow the same header to be used by both device tree files,
>>> and drivers implementing this binding, which guarantees that the two
>>> stay in sync. This also makes device trees more readable by using names
>>> instead of magic numbers.
>>
>> Why does the driver need these constants; shouldn't it simply support
>> 0..n SW group IDs that all work the same way? Or, is there some reason
>> for it to know the identities?
>>
>>> diff --git a/include/dt-bindings/memory/tegra-swgroup.h b/include/dt-bindings/memory/tegra-swgroup.h
>>
>> s/memory/iommu/?
> 
> This info would be used in PMC code as well, which H/W belongs to
> which swgroup. So I use the term "memory(-client)" instead of "iommu".

Why does the PMC care? An explanation of exactly what SW needs to know
about these groups and why would be a good idea.

>> s/tegra-swgroup.h/tegra-smmu.h/?
> 
> Is "tegra-memory-clients.h" preferable, then?

Perhaps, although aren't these IDs specific to the connection between
modules and the SMMU? Or, are these IDs some more global concept; the HW
modules in question pass the same IDs to both the SMMU and to other HW
modules for some reason?

>>> +#define TEGRA_SWGROUP_BIT(x)	(1ULL << TEGRA_SWGROUP_##x)
>>> +
>>> +#define TEGRA30_SWGROUP_ALL	<0x00000000 0x000779ff>
>>> +#define TEGRA114_SWGROUP_ALL	<0x00000000 0x01b659fe>
>>
>> Are those 3 values needed by DT files, or just the driver?
> 
> Only from DT.

If the values are only needed to write the DT content, I'd tend to
prefer not defining them in a header in <dt-bindings/>; I consider that
directory a definition of the constants that define the ABI itself, not
as a random place to put useful things for DT. You can include headers
in the *.dts directory itself.



From swarren at wwwdotorg.org  Mon Jul 29 13:47:04 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 11:47:04 -0600
Subject: [PATCH v2 05/22] ARM: dt: tegra30: iommu: Add "nvidia,
 memory-client"
In-Reply-To: <20130729.140646.649065361266278007.hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com><1373021097-32420-6-git-send-email-hdoyu@nvidia.com><51E5D3D9.2090608@wwwdotorg.org>
 <20130729.140646.649065361266278007.hdoyu@nvidia.com>
Message-ID: <51F6AA98.4020701@wwwdotorg.org>

On 07/29/2013 05:06 AM, Hiroshi Doyu wrote:
> Stephen Warren <swarren at wwwdotorg.org> wrote @ Wed, 17 Jul 2013 01:14:33 +0200:
> 
>> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
>>> Add "nvidia,memory-client" to identify which swgroup ID a device
>>> belongs to.
>>
>> This property also isn't in the documentation.
>>
>> Again, if client devices are required to have this new property, the DT
>> isn't backwards-compatible; fail:-(
> 
> If there's no this property, just falling back to use the system
> default address space. I think that this won't break the
> compatibility basically. Only problem may be the inconsistency of
> setting this property among the HWs in the same group.

When you say "group" there, what kind of group? I thought that each HW
module had its own "SWGROUP ID", and hence there are no "HWs in the same
group"?


From swarren at wwwdotorg.org  Mon Jul 29 13:50:49 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 11:50:49 -0600
Subject: [PATCH v2 13/22] iommu/tegra: smmu: Create default IOVA maps
In-Reply-To: <20130729.142409.995770519696534476.hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com><1373021097-32420-14-git-send-email-hdoyu@nvidia.com><51E84BB5.9010303@wwwdotorg.org>
 <20130729.142409.995770519696534476.hdoyu@nvidia.com>
Message-ID: <51F6AB79.1000205@wwwdotorg.org>

On 07/29/2013 05:24 AM, Hiroshi Doyu wrote:
> Stephen Warren <swarren at wwwdotorg.org> wrote @ Thu, 18 Jul 2013 22:10:29 +0200:
> 
>> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
>>> Create default IOVA maps at boot-up which can be attached to devices.
>>
>>> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
>>
>>>  static int tegra_smmu_probe(struct platform_device *pdev)
>>>  {
>>>  	struct smmu_device *smmu;
>>
>>> @@ -1160,13 +1182,15 @@ static int tegra_smmu_probe(struct platform_device *pdev)
>>>  	if (of_property_read_u32(dev->of_node, "nvidia,#asids", &asids))
>>>  		return -ENODEV;
>>>  
>>> -	bytes = sizeof(*smmu) + asids * sizeof(*smmu->as);
>>> +	bytes = sizeof(*smmu) + asids * (sizeof(*smmu->as) +
>>> +					 sizeof(struct dma_iommu_mapping *));
>>>  	smmu = devm_kzalloc(dev, bytes, GFP_KERNEL);
>>>  	if (!smmu) {
>>>  		dev_err(dev, "failed to allocate smmu_device\n");
>>>  		return -ENOMEM;
>>>  	}
>>>  
>>> +	smmu->map = (struct dma_iommu_mapping **)(smmu->as + asids);
>>
>> Shouldn't "+ asids" be "+ asids * sizeof(*smmu->as)" to match the
>> calculation of "bytes" above?
> 
> The structure is:
> 
> smmu {
>      ....
>      struct dma_iommu_mapping **map;
>      ....	
>      struct smmu_as	as[0];
> };
> 
> I think that this is correct, but is the following better?

Oh right, I guess since that's pointer-math, the compiler already
multiplies by the array entry size.

> + smmu->map = (struct dma_iommu_mapping **)&smmu->as[asids];

That would be a bit more obvious.


From swarren at wwwdotorg.org  Mon Jul 29 13:54:09 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 11:54:09 -0600
Subject: [PATCH v2 14/22] iommu/tegra: smmu: Register platform_device
 to IOMMU dynamically
In-Reply-To: <20130729.142752.1020949402019811407.hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com><1373021097-32420-15-git-send-email-hdoyu@nvidia.com><51E84D51.2030404@wwwdotorg.org>
 <20130729.142752.1020949402019811407.hdoyu@nvidia.com>
Message-ID: <51F6AC41.30007@wwwdotorg.org>

On 07/29/2013 05:27 AM, Hiroshi Doyu wrote:
> Stephen Warren <swarren at wwwdotorg.org> wrote @ Thu, 18 Jul 2013 22:17:21 +0200:
> 
>> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
>>> Register platform_devices to IOMMU dynamically via
>>> ops->{add,remove}_device().
>>
>>> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
>>
>>> +/*
>>> + * ASID[0] for the system default
>>> + * ASID[1] for PPCS, which has SDMMC
>>
>> I have no idea what PPCS is. The patch description for 21/22 implies
>> much more than SDMMC is "in PPCS"...
> 
> "PPCS" is all AHB bus children/(client).

Just to be clear: I was hoping that the comment would be fixed.

>>> + * ASID[2][3].. open for drivers, first come, first served.
>>> + */
>>> +enum {
>>> +	SYSTEM_DEFAULT,
>>> +	SYSTEM_PROTECTED,
>>> +};
>>
>> Why hard-code this mapping? Can't devices be assigned to ASIDs based on
>> a DT property? I assume there's nothing in the SMMU HW that requires
>> specific ASIDs to be used?
> 
> Right. Where should those policy be passed, board DT files?

Is the HW module (== SW group?) to ASID mapping policy or is a
particular mapping required by HW?

Can the ASID mapping just happen dynamically in SW rather than DT
dictating a particular mapping?

I assume the mapping must be set up before any HW is used, and can't be
modified later, so there's no much chance of deferring any policy
decisions to user-space etc.?


From jgunthorpe at obsidianresearch.com  Mon Jul 29 13:54:00 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Mon, 29 Jul 2013 11:54:00 -0600
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130727084825.GA4707@netboy>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726045433.GB4100@netboy>
 <20130726171524.GB28895@obsidianresearch.com>
 <20130727084825.GA4707@netboy>
Message-ID: <20130729175400.GB15861@obsidianresearch.com>

On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote:

> > Of course all this could have been done in C, but it wasn't/hasn't been..
> 
> You have identified the real issue: poor quality of the ARM board
> support process within the kernel. Churn is still churn, whether in DT
> or in platform devices, but the DT people promised to end the churn.

Actually my experience in this area was mainly from PPC, and granted
it spanned the PPC32/PPC64 merge.

> [ I disagree about the "more thought" part. The current discussion,
>   coming years too late after the introduction of DT to ARM Linux, is
>   contrary evidence enough. ]

The current discussion has little to do with the quality of the
bindings, look at the new kirkwood bindings - they have had much more
thought put into them than the old board.c stuff they are replacing.

> > I can't delay shipping while upstream sorts this out - so I know
> > *absolutely* that the DT schema will change. This has been planned for
> > and designed into the boot system and won't be a problem.
> > 
> > Why would anyone do embedded any other way?
> 
> Yep, that is the embedded way: ship it!
> 
> We can do better than that.

I think you missed the point.

There is no way I can possibly ship a product with a DT that is
finished. I can't tie my company's product release cycles to the whims
of the kernel community.

So embedded people are going to ship with unfinished DT and upgrade
later. They have to. There is no choice. Stable DT doesn't change
anything unless you can create perfect stable bindings for a new SOC
instantaneously.

This is where I see the whole disconnect in this
discussion. General-purpose and embedded are *DIFFERENT* users, and
they have different use-cases and different needs.

Jason


From balbi at ti.com  Mon Jul 29 13:54:13 2013
From: balbi at ti.com (Felipe Balbi)
Date: Mon, 29 Jul 2013 20:54:13 +0300
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given in
 usb_bind_phy
In-Reply-To: <51F68A56.8060805@ti.com>
References: <1374829418-27503-1-git-send-email-kishon@ti.com>
 <1374829418-27503-3-git-send-email-kishon@ti.com>
 <20130729150638.GD3063@radagast> <51F68A56.8060805@ti.com>
Message-ID: <20130729175413.GC4964@radagast>

Hi,

On Mon, Jul 29, 2013 at 08:59:26PM +0530, Kishon Vijay Abraham I wrote:
> >> Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while creating
> >> MUSB core device. So in usb_bind_phy (binds the controller with the PHY), the
> >> device name of the controller had *.auto* in it. Since with using
> >> PLATFORM_DEVID_AUTO, there is no way to know the exact device name in advance,
> >> the data given in usb_bind_phy became obsolete and usb_get_phy was failing.
> >> So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO. Corresponding
> >> change is done in board file here.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> >> ---
> >>  arch/arm/mach-omap2/board-2430sdp.c          |    2 +-
> >>  arch/arm/mach-omap2/board-3430sdp.c          |    2 +-
> >>  arch/arm/mach-omap2/board-cm-t35.c           |    2 +-
> >>  arch/arm/mach-omap2/board-devkit8000.c       |    2 +-
> >>  arch/arm/mach-omap2/board-igep0020.c         |    2 +-
> >>  arch/arm/mach-omap2/board-ldp.c              |    2 +-
> >>  arch/arm/mach-omap2/board-omap3beagle.c      |    2 +-
> >>  arch/arm/mach-omap2/board-omap3evm.c         |    2 +-
> >>  arch/arm/mach-omap2/board-omap3logic.c       |    2 +-
> >>  arch/arm/mach-omap2/board-omap3pandora.c     |    2 +-
> >>  arch/arm/mach-omap2/board-omap3stalker.c     |    2 +-
> >>  arch/arm/mach-omap2/board-omap3touchbook.c   |    2 +-
> >>  arch/arm/mach-omap2/board-overo.c            |    2 +-
> >>  arch/arm/mach-omap2/board-rm680.c            |    2 +-
> >>  arch/arm/mach-omap2/board-rx51.c             |    2 +-
> >>  arch/arm/mach-omap2/board-zoom-peripherals.c |    2 +-
> >>  16 files changed, 16 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
> >> index 244d8a5..17bb076 100644
> >> --- a/arch/arm/mach-omap2/board-2430sdp.c
> >> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> >> @@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
> >>  	omap_hsmmc_init(mmc);
> >>  
> >>  	omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
> >> -	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
> >> +	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
> > 
> > how about moving usb_bind_phy() calls to omap2430.c ?
> > 
> > diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> > index f44e8b5..b6abc1a 100644
> > --- a/drivers/usb/musb/omap2430.c
> > +++ b/drivers/usb/musb/omap2430.c
> > @@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device *pdev)
> >  
> >  		pdata->board_data	= data;
> >  		pdata->config		= config;
> > +	} else {
> > +		/* bind the PHY */
> > +		usb_bind_phy(dev_name(&musb->dev), 0, "twl4030_usb");
> 
> This looks like a hack IMHO to workaround the usb phy library. otherwise it is
> similar to get_phy_by_name.

actually, this is a workaround to the fact that we're not creating all
platform_devices in arch/arm/mach-omap2/ :-)

If we had the musb allocation there, we could easily handle
usb_bind_phy()

> > so that's temporary. It might be better than to reintroduce the IDR in
> > musb_core.c.
> 
> that?s needed for generic phy framework anyway :-s

right, but generic phy framework can handle everything just fine, the
only problem is that names are changing.

-- 
balbi
-------------- 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/20130729/36df298b/attachment.sig>

From swarren at wwwdotorg.org  Mon Jul 29 14:00:06 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 12:00:06 -0600
Subject: [PATCH v2 16/22] iommu/tegra: smmu: Get "nvidia,swgroup" from DT
In-Reply-To: <20130729.143950.524913713971518557.hdoyu@nvidia.com>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com><1373021097-32420-17-git-send-email-hdoyu@nvidia.com><51E84FFA.8020509@wwwdotorg.org>
 <20130729.143950.524913713971518557.hdoyu@nvidia.com>
Message-ID: <51F6ADA6.3040006@wwwdotorg.org>

On 07/29/2013 05:39 AM, Hiroshi Doyu wrote:
> Stephen Warren <swarren at wwwdotorg.org> wrote @ Thu, 18 Jul 2013 22:28:42 +0200:
> 
>> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
>>> This provides the info about which H/W Accelerators are supported on
>>> Tegra SoC. This info is passed from DT. This is necessary to have the
>>> unified SMMU driver among Tegra SoCs. Instead of using platform data,
>>> DT passes "nvidia,swgroup" now. DT is mandatory in Tegra.
>>
>>> diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
>>
>>> +- nvidia,swgroups: A bitmap of supported HardWare Accelerators(HWA).
>>> +  Each bit represents one swgroup. The assignments may be found in header
>>> +  file <dt-bindings/memory/tegra-swgroup.h>.
>>
>> There needs to be a default for this field if one is not specified so
>> that existing DTs continue to work without modification.
> 
> Only enabling PPCS(AHB) can be an option because PPCS has SD/MMC where
> rootfs can be located ususally.

There's no reason that the root filesystem has to be on SD/MMC. Either
way, the DT binding shouldn't be influenced by the root fs location at all.

I think more explanation of exactly what this property does and why is
required.

>> How many cells big is this property?
> 
> 64

I assume that's bits, so 2 cells? To be clear: the document needs to
include this information, not just this email thread.

>> Is this really a bitmap of HWAs? Surely it's a bitmap of SMMU client
>> IDs?
> 
> At least this info can be used for PMC too.

How and why? A complete explanation of how the SMMU and PMC are expected
to interact is required.

The PMC DT binding should include all information related to the PMC;
the binding definitions probably shouldn't expect a PMC driver to go
grovelling in an SMMU node to find information.

> .....
>>> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
>>
>>> @@ -265,7 +265,7 @@ struct smmu_client {
>>>  	struct device		*dev;
>>>  	struct list_head	list;
>>>  	struct smmu_as		*as;
>>> -	u32			hwgrp;
>>> +	u64			hwgrp;
>>
>> Why is that "hwgrp" not "swgrp"? Don't they represent the same
>> thing?
> 
> They are same but initial SMMU driver used the term "hwgroup". Should
> this be renamed with another patch or can it be left as it is?

I thought there had already been a patch to do this rename. Was it not
complete? If so, that work should probably be completed.

> ....
>>>  static int __smmu_client_set_hwgrp(struct smmu_client *c,
>>> -				   unsigned long map, int on)
>>> +				   u64 map, int on)
>>>  {
>>>  	int i;
>>>  	struct smmu_as *as = c->as;
>>> @@ -398,12 +400,11 @@ static int __smmu_client_set_hwgrp(struct smmu_client *c,
>>>  	if (!on)
>>>  		map = smmu_client_hwgrp(c);
>>>  
>>> -	for_each_set_bit(i, &map, HWGRP_COUNT) {
>>> +	for_each_set_bit(i, (unsigned long *)&map,
>>> +			 sizeof(map) * BITS_PER_BYTE) {
>>
>> Why change the type if it just forces you to add this cast?
> 
> u32 map; -> u64 map;
> 
> for_each_set_bit() expects "unsigned long *" for any length of bitmap.

Shouldn't the map just be an "unsigned long map[]" then, so no casts are
needed anywhere? Equally, that pointer could just be passed to the
function rather than copying the data to the stack?


From jgunthorpe at obsidianresearch.com  Mon Jul 29 14:05:13 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Mon, 29 Jul 2013 12:05:13 -0600
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <1441731.8CGUI1tUxh@flatron>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F39FD8.6080808@broadcom.com> <20130727183059.GD4813@netboy>
 <1441731.8CGUI1tUxh@flatron>
Message-ID: <20130729180513.GB1884@obsidianresearch.com>

On Sat, Jul 27, 2013 at 11:51:06AM -0700, Tomasz Figa wrote:

> Well, it depends on how we use the DT. There are (at least) two possible 
> usage scenarios:
> 
>  a) using DT as direct replacement for board files - this means that you 
>     are free to say that DTSes are strictly coupled with kernel version 
>     and you are free to modify the bindings - see the analogy to board 
>     files, where you could modify the platform data structures and could 
>     not directly copy board file from one kernel version to another,
> 
>  b) using DT as an ABI - this is the original way, i.e. define stable 
>     bindings and make sure that anu DTB built for older kernel will work,
>     with equal or greater set of functionality on newer kernels.
> 
> Now I believe in this thread the point whether we should use a) or b) or a 
> combination of both has been raised.

Right, and I think it is very important to consider that different
systems can legitimately fall into those categories.

Clearly general purpose systems (eg servers, workstations, etc) with
*full featured firmware* fall into category b. Linux already basically
has stable DT for those systems - but the firmware is expected to do
lots of work and hide all the low level details from the
kernel. Basically, the DT should stick to approximately ePAR and
everything else is hidden by the firmware. This is essentially how x86
works and achieves its compatibility.

Systems that have minimalist firmware, where firmware functions are
pushed into the kernel and the DT is now required to describe
intricate and unique SOC specific functions are clearly very
different, and I think it makes sense to encourage those environments
to be case 'a'.

Basically, minimalist firmware should have a boot process design that
*can* couple the DT and kernel, while full featured firmware should
keep them seperate. IMHO that should be the clear message to people
implementing this stuff.

After enough time the DT for 'a' should become stable and churn free,
but expecting/demanding that from day 0 is not helping anyone, IMHO.

Jason


From jgunthorpe at obsidianresearch.com  Mon Jul 29 14:15:50 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Mon, 29 Jul 2013 12:15:50 -0600
Subject: Defining schemas for Device Tree
In-Reply-To: <2469263.vMN09Q7Tzi@flatron>
References: <2469263.vMN09Q7Tzi@flatron>
Message-ID: <20130729181550.GD15861@obsidianresearch.com>

On Mon, Jul 29, 2013 at 02:21:52AM +0200, Tomasz Figa wrote:
 
> e) What format should be used for Device Tree schema?
> 
> This is a non-trivial problem. Key criteria I can think of are as
> follows:

You may wish to think about this as a linter+checker (like
sparse/coverity, etc) and code the 'schema' in C code.

As you've noticed already there are many complex cases. Look at the
PCI bindings, for instance, the complexity of what needs to be valided
is very high.

Jason


From linux at arm.linux.org.uk  Mon Jul 29 14:16:07 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 29 Jul 2013 19:16:07 +0100
Subject: DT bindings as ABI [was: Do we have people interested in
 device tree janitoring / cleanup?]
In-Reply-To: <20130729175400.GB15861@obsidianresearch.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy> <20130725213753.GC17616@obsidianresearch.com>
 <20130726045433.GB4100@netboy> <20130726171524.GB28895@obsidianresearch.com>
 <20130727084825.GA4707@netboy> <20130729175400.GB15861@obsidianresearch.com>
Message-ID: <20130729181607.GM24642@n2100.arm.linux.org.uk>

On Mon, Jul 29, 2013 at 11:54:00AM -0600, Jason Gunthorpe wrote:
> There is no way I can possibly ship a product with a DT that is
> finished. I can't tie my company's product release cycles to the whims
> of the kernel community.
> 
> So embedded people are going to ship with unfinished DT and upgrade
> later. They have to. There is no choice. Stable DT doesn't change
> anything unless you can create perfect stable bindings for a new SOC
> instantaneously.
> 
> This is where I see the whole disconnect in this
> discussion. General-purpose and embedded are *DIFFERENT* users, and
> they have different use-cases and different needs.

We have had for the last 20 odd years a stable kernel syscall ABI, in
that syscalls which were around 20 years ago are still around today,
and still function according to how they're meant to.

However, some syscalls were found to be insufficient for todays needs,
so they got augmented.  For example, the uid/gid IDs used to be 16-bit.
We now have 32-bit versions, but the 16-bit versions are still there.
(Since ARM started out from early 1.0 times, it too has the 16-bit
syscalls, and _still_ does.)

So, "stable" is possible.

What has to be realised to achieve that it requires nothing more than
a "keep existing stuff working" attitude towards it.  When you need to
change the interface, you supplement it, leaving the old version to
work in the same manner that it used to (yes, you should choose to
implement the old interfaces using the new stuff, just like we support
the 16-bit UID calls but internally deal with 32-bit UIDs.)

What does it take?  Good practice, care, thought and planning.  All
the qualities which should already be present for kernel _engineers_.
Not an "lets create something for me, I don't care about anyone else"
attitude.

We can draw the line at an interface becoming stable in exactly the
same way that we do every other "stable" interface like syscalls - if
it's in a -final kernel, then it has been released at that point as a
stable interface to the world.  That's how syscalls are dealt with -
if a syscall is supported by a -final kernel, then that interface
immediately becomes part of the userland ABI and can't be changed or
deleted without some really serious thought, a migration path, and
sufficient (which means many years) warning to users that it's obsolete.

If that is followed, then there is absolutely no reason why a "Stable
DT" is not possible - one which it's possible to write a DT file today,
and it should still work in 20 years time with updated kernels.  That's
what a stable interface _should_ allow, and this is what DT _should_ be.

It should be possible to say "I have a XYZ ethernet device, it is
hooked up like this, uses this interrupt" etc and that same way work
in 20 years time to describe exactly the same connections.

Sure, we can create a "staging" directory for stuff which we want to
merge but is not deemed to be properly fit for the kernel, and deem
_that_ stuff to be unstable - just like drivers/stable.  Maybe some
of it can live in drivers/stable too...


From pavel at denx.de  Mon Jul 29 14:25:54 2013
From: pavel at denx.de (Pavel Machek)
Date: Mon, 29 Jul 2013 20:25:54 +0200
Subject: [PATCH 1/2] ARM: dts: Change dw-apb-timer-osc and
 dw-apb-timer-sp to just dw-apb-timer
In-Reply-To: <1374723797-22169-1-git-send-email-dinguyen@altera.com>
References: <1374723797-22169-1-git-send-email-dinguyen@altera.com>
Message-ID: <20130729182554.GA10346@amd.pavel.ucw.cz>

On Wed 2013-07-24 22:43:16, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen at altera.com>
> 
> "dw-apb-timer-osc" and "dw-apb-timer-sp" are the same implementation of the
> DW APB timer, just fed by different clocks.
> 
> Signed-off-by: Dinh Nguyen <dinguyen at altera.com>
> CC: Rob Herring <rob.herring at calxeda.com>
> Cc: Grant Likely <grant.likely at linaro.org>
> CC: Arnd Bergmann <arnd at arndb.de>
> Cc: Olof Johansson <olof at lixom.net>
> CC: Jamie Iles <jamie at jamieiles.com>
> Cc: John Stultz <john.stultz at linaro.org>
> Cc: Heiko Stuebner <heiko at sntech.de>

Looks good to me, thanks!
									Pavel

Reviewed-by: Pavel Machek <pavel at denx.de>
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From linux at arm.linux.org.uk  Mon Jul 29 14:27:30 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 29 Jul 2013 19:27:30 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130729180513.GB1884@obsidianresearch.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F39FD8.6080808@broadcom.com> <20130727183059.GD4813@netboy>
 <1441731.8CGUI1tUxh@flatron> <20130729180513.GB1884@obsidianresearch.com>
Message-ID: <20130729182730.GN24642@n2100.arm.linux.org.uk>

On Mon, Jul 29, 2013 at 12:05:13PM -0600, Jason Gunthorpe wrote:
> Clearly general purpose systems (eg servers, workstations, etc) with
> *full featured firmware* fall into category b. Linux already basically
> has stable DT for those systems - but the firmware is expected to do
> lots of work and hide all the low level details from the
> kernel. Basically, the DT should stick to approximately ePAR and
> everything else is hidden by the firmware. This is essentially how x86
> works and achieves its compatibility.

and the downside of placing that trust in firmware is that it very often
leads to bugs which can't be solved.

I have a set of patches for my laptop/docking station which gets the
serial/printer ports working.  I've had them for many years now - and
I thought I had a problem sorted.  I was wrong - the nice helpful ACPI
reports on dock that the serial port is enabled, but the port is
actually disabled in hardware.

If I have ACPI/PNP stuff setup to always believe that this port is
disabled, then on boot with the docking station connected, it comes up
initially as ttyS0, and then, because the port is "disabled", the
resources are busy so it gets reassigned to a different IO port.
Undocking/redocking works because the port is now properly re-enabled
after a dock event.

If I report the ACPI status to the kernel, then on boot, it correctly
remains as ttyS0.  However, after an undock/redock event, Linux
believes that the port is back, but any attempt to use it gets the
"LSR safety check engaged" message, because the port is actually
disabled.  The only way to get it working again is to manually unbind
the device and rebind it - so the ACPI disable + enable methods get
called.

I've had this problem for years, and it's basically unfixable for me -
it's only fixable if you are IBM and can reflash the BIOS with alternative
ACPI tables which are correct.  And I won't submit these patches all the
time that I don't know they work correctly.

That's the problem with "compatible systems" - you give away trust that
someone else will do the right thing, and if they don't, you may be
screwed in a way that is can not be worked around by quirks or similar
- just like the above.

Firmware is swings and roundabouts.  You give up some control to a
third party so you don't have to think about XYZ, and you hope that
they get it right.


From pavel at denx.de  Mon Jul 29 14:30:06 2013
From: pavel at denx.de (Pavel Machek)
Date: Mon, 29 Jul 2013 20:30:06 +0200
Subject: [PATCH 2/2] clocksource: dw_apb_timer_of: Fix read_sched_clock
In-Reply-To: <1374723797-22169-2-git-send-email-dinguyen@altera.com>
References: <1374723797-22169-1-git-send-email-dinguyen@altera.com>
 <1374723797-22169-2-git-send-email-dinguyen@altera.com>
Message-ID: <20130729183006.GB10346@amd.pavel.ucw.cz>

Hi!

> The read_sched_clock should return the ~value because the clock is a
> countdown implementation. read_sched_clock() should be the same as
> __apbt_read_clocksource().

...for altera boards. But AFAICT:

> diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
> index 4cbae4f..8e00929 100644
> --- a/drivers/clocksource/dw_apb_timer_of.c
> +++ b/drivers/clocksource/dw_apb_timer_of.c
> @@ -102,18 +102,17 @@ static void add_clocksource(struct device_node *source_timer)
>  	 * timer is found. sched_io_base then points to the current_value
>  	 * register of the clocksource timer.
>  	 */
> -	sched_io_base = iobase + 0x04;
> +	sched_io_base = iobase;
>  	sched_rate = rate;
>  }
>  
>  static u32 read_sched_clock(void)
>  {
> -	return __raw_readl(sched_io_base);
> +	return ~__raw_readl(sched_io_base + 0x4);
>  }
>  
>  static const struct of_device_id sptimer_ids[] __initconst = {
>  	{ .compatible = "picochip,pc3x2-rtc" },
> -	{ .compatible = "snps,dw-apb-timer-sp" },
>  	{ /* Sentinel */ },
>  };
>

picochip,pc3x2-rtc is _not_ compatible with snps,dw-apb-timer, and
does count up. You correctly remove snps,dw-apb-timer-sp
compatibility, but AFAICT the ~value change will do something
interesting on picochip boards.

Or maybe I'm just confused about all the timers? Jamie acked this so
it should be fine...?

Thanks,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From richardcochran at gmail.com  Mon Jul 29 14:38:52 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Mon, 29 Jul 2013 20:38:52 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130729073123.GB1441@lukather>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1441731.8CGUI1tUxh@flatron> <20130728085650.GA4683@netboy>
 <1416484.XDfk5G56BI@flatron> <20130728131901.GA8864@netboy>
 <20130729073123.GB1441@lukather>
Message-ID: <20130729183851.GB4209@netboy>

On Mon, Jul 29, 2013 at 09:31:23AM +0200, Maxime Ripard wrote:
> 
> I'm afraid this kind of use case will never be properly supported, DT
> stable ABI or not.
> 
> Think about this: what kernel will actually be shipped in that board?
> Most likely, it will be a BSP kernel from the vendor. Does the vendor
> will have made that commitment to have a stable ABI for the DT? Will it
> use the same bindings than mainline? Do we want to support all the crazy
> bindings every vendor will come up with?
> 
> I'm afraid the answer to these three questions will most of the time be
> "no.".

Yes, I know, and it is sad but true.
 
We can't stop the vendors from shipping half-baked BSPs. I really
don't mind that they do that. After all, they want to get *something*
working when they launch their chips.

> That doesn't mean we shouldn't aim for *mainline* having a stable DT
> ABI, but that kind of use case doesn't seem very realistic to me.

Right, we can and should do better. I got the beaglebone Ethernet
working in mainline (not by writing the driver, but by complaining
over and over again). I except that it will continue to work and not
fall victim to some random DT change.

Thanks,
Richard






From jgunthorpe at obsidianresearch.com  Mon Jul 29 14:40:48 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Mon, 29 Jul 2013 12:40:48 -0600
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130729181607.GM24642@n2100.arm.linux.org.uk>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F168FC.9070906@wwwdotorg.org>
 <20130725182920.GA24955@e106331-lin.cambridge.arm.com>
 <20130725184834.GA8296@netboy>
 <20130725213753.GC17616@obsidianresearch.com>
 <20130726045433.GB4100@netboy>
 <20130726171524.GB28895@obsidianresearch.com>
 <20130727084825.GA4707@netboy>
 <20130729175400.GB15861@obsidianresearch.com>
 <20130729181607.GM24642@n2100.arm.linux.org.uk>
Message-ID: <20130729184048.GE15861@obsidianresearch.com>

On Mon, Jul 29, 2013 at 07:16:07PM +0100, Russell King - ARM Linux wrote:

> What does it take?  Good practice, care, thought and planning.  All
> the qualities which should already be present for kernel _engineers_.
> Not an "lets create something for me, I don't care about anyone else"
> attitude.

I agree with what you've written, but we are looking at this from
different ends of the problem.

I fully agree you can create a main line kernel GIT tree that has a
stable DT ABI.

However, I as an ODM, with time pressure, cannot wait for the kernel
folks to finish this work. So from my perspective the DT will not be
stable, as I will put whatever interm stuff I choose to have a
shippable product.

Thus I have to design my systems for an unstable DT, and the message
from the kernel community to people in my posistion should be:

  When you ship early with non-mainlined DT schema, design your boot
  system around an unstable DT. Plan to migrate your DT to upstream
  once it becomes finalized.

Here is the rub: Once I design for an unstable DT I simply don't
derive value from the kernel communities work to create a stable DT.

So who is getting the benefit of this work, and is it worth the cost?

Jason


From sboyd at codeaurora.org  Mon Jul 29 14:41:41 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 29 Jul 2013 11:41:41 -0700
Subject: [PATCH] time: sched_clock: fix integer overflow
In-Reply-To: <20130729055939.GK5161@tarshish>
References: <232c026d1b8d2556679aea56cf77a6811f9a96c5.1374054369.git.baruch@tkos.co.il>
 <20130729055939.GK5161@tarshish>
Message-ID: <51F6B765.9030404@codeaurora.org>

On 07/28/13 22:59, Baruch Siach wrote:
> Hi Thomas, John,
>
> On Wed, Jul 17, 2013 at 12:46:53PM +0300, Baruch Siach wrote:
>> The expression '(1 << 32)' happens to evaluate as 0 on ARM, but it evaluates as
>> 1 on xtensa and x86_64. This zeros sched_clock_mask, and breaks sched_clock().
>> Set the type of 1 to 'unsigned long long' to get the value we need.
> Ping? -rc3 is out, and this bug (which currently breaks xtensa) is not fixed 
> yet. Please consider applying.

Looks good to me.

Acked-by: Stephen Boyd <sboyd at codeaurora.org>

>
>> Reported-by: Max Filippov <jcmvbkbc at gmail.com>
>> Tested-by: Max Filippov <jcmvbkbc at gmail.com>
>> Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>
>> Signed-off-by: Baruch Siach <baruch at tkos.co.il>
>> ---
>>  kernel/time/sched_clock.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
>> index a326f27..0b479a6 100644
>> --- a/kernel/time/sched_clock.c
>> +++ b/kernel/time/sched_clock.c
>> @@ -121,7 +121,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
>>  	BUG_ON(bits > 32);
>>  	WARN_ON(!irqs_disabled());
>>  	read_sched_clock = read;
>> -	sched_clock_mask = (1 << bits) - 1;
>> +	sched_clock_mask = (1ULL << bits) - 1;
>>  	cd.rate = rate;
>>  
>>  	/* calculate the mult/shift to convert counter ticks to ns. */
>> -- 


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From andrew at lunn.ch  Mon Jul 29 14:45:20 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 29 Jul 2013 20:45:20 +0200
Subject: [PATCH 4/4] ARM: dove: add initial DT file for Globalscale D2Plug
In-Reply-To: <1375100946-28521-5-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1375100946-28521-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1375100946-28521-5-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20130729184520.GI24782@lunn.ch>

On Mon, Jul 29, 2013 at 02:29:06PM +0200, Sebastian Hesselbarth wrote:
> This adds an initial DT file for the Globalscale D2Plug with Dove SoC.
> Currently, one LED is missing and I have not been able to get SD8787 driver
> working. Those will be taken care of later.

Hi Sebastion

I took a hard look at SDIO and failed to get it working when doing
DMA. Polled IO does however work. I guess we need some help from
Marvell engineers before we get stable SDIO with DMA.

	Andrew


From richardcochran at gmail.com  Mon Jul 29 14:51:02 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Mon, 29 Jul 2013 20:51:02 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130729183851.GB4209@netboy>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1441731.8CGUI1tUxh@flatron> <20130728085650.GA4683@netboy>
 <1416484.XDfk5G56BI@flatron> <20130728131901.GA8864@netboy>
 <20130729073123.GB1441@lukather> <20130729183851.GB4209@netboy>
Message-ID: <20130729185100.GC4209@netboy>

On Mon, Jul 29, 2013 at 08:38:52PM +0200, Richard Cochran wrote:
> 
> Right, we can and should do better. I got the beaglebone Ethernet
> working in mainline (not by writing the driver, but by complaining
> over and over again). I except that it will continue to work and not
                          ^^^^^^
expect

> fall victim to some random DT change.

Thanks,
Richard


From iivanov at mm-sol.com  Mon Jul 29 15:02:58 2013
From: iivanov at mm-sol.com (Ivan T. Ivanov)
Date: Mon, 29 Jul 2013 22:02:58 +0300
Subject: [PATCH v2 1/6] usb: phy: msm: Move mach depndend code to
 platform data
In-Reply-To: <20130729122344.GH24801@radagast>
References: <1375081464-14206-1-git-send-email-iivanov@mm-sol.com>
 <1375081464-14206-2-git-send-email-iivanov@mm-sol.com>
 <20130729122344.GH24801@radagast>
Message-ID: <1375124578.5444.2.camel@localhost>

Hi, 

> > Cc: Bryan Huntsman <bryanh at codeaurora.org>
> > Cc: Felipe Balbi <balbi at ti.com>
> > Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: linux-kernel at vger.kernel.org
> > Cc: linux-usb at vger.kernel.org
> > 
> > Signed-off-by: Ivan T. Ivanov <iivanov at mm-sol.com>
> > ---
> >  arch/arm/mach-msm/board-msm7x30.c |   35 +++++++++++++++++++++++
> >  arch/arm/mach-msm/board-qsd8x50.c |   35 +++++++++++++++++++++++
> 
> I need acks for these.
> 
> >  drivers/usb/phy/phy-msm-usb.c     |   55 ++++++++++---------------------------
> >  include/linux/usb/msm_hsusb.h     |    3 ++
> >  4 files changed, 87 insertions(+), 41 deletions(-)
> > 
> > diff --git a/arch/arm/mach-msm/board-msm7x30.c b/arch/arm/mach-msm/board-msm7x30.c
> > index db3d8c0..6b35953 100644
> > --- a/arch/arm/mach-msm/board-msm7x30.c
> > +++ b/arch/arm/mach-msm/board-msm7x30.c
> > @@ -31,6 +31,7 @@
> >  #include <asm/setup.h>
> >  
> >  #include <mach/board.h>
> > +#include <mach/clk.h>
> >  #include <mach/msm_iomap.h>
> >  #include <mach/dma.h>
> >  
> > @@ -61,10 +62,44 @@ static int hsusb_phy_init_seq[] = {
> >  	-1
> >  };
> >  
> > +static int hsusb_link_clk_reset(struct clk *link_clk, bool assert)
> 
> looks like you should be using the reset controller framework ?
> (drivers/reset)

Probably, but there still nothing in place in the msm,
which provide this functionality. I am looking it to
right now.

Regards,
Ivan





From jason at lakedaemon.net  Mon Jul 29 15:21:12 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 29 Jul 2013 15:21:12 -0400
Subject: NSA310 + DT
In-Reply-To: <51F6A0DC.3020501@uni-bremen.de>
References: <20130710073706.GA28212@lunn.ch> <51F6A0DC.3020501@uni-bremen.de>
Message-ID: <20130729192112.GY29916@titan.lakedaemon.net>

Hi Finn,

On Mon, Jul 29, 2013 at 07:05:32PM +0200, Finn Hoffmann wrote:
> Hello,
> 
> I have tried to get a current Kernel running on my NSA310.

Nice.

> Everything works well on Kernels before DT with the mentioned
> patches from https://github.com/peeter123/NSA310-320-debian .
> I have linux-3.10.2 running and after I changed the dts file to lm85
> sensors and fanconrtol work but GPIO does not.
> I tried https://github.com/lunn/linux/tree/v3.11-rc1-nsa310-tdc and
> linux-3.11.0-rc3.
> Both have the problem that r8169 is not working:
> r8169: eth0: unknown chipset (mac_version = 0).
> and console is spammed with
> r8169 0000:01:00.0 eth0: rtl_phyar_cond == 0 (loop: 20, delay: 25).
> until I take eth0 down.
> GPIO is working.
> 
> Any ideas?

Adding Andrew Lunn to the Cc: as he is more familiar with those DT
changes.  In future, please Cc myself, Andrew, and Gregory Clement so we
don't miss the email.

thx,

Jason.


From broonie at kernel.org  Mon Jul 29 15:48:29 2013
From: broonie at kernel.org (Mark Brown)
Date: Mon, 29 Jul 2013 20:48:29 +0100
Subject: [Ksummit-2013-discuss] Defining schemas for Device Tree
In-Reply-To: <20130729172339.GT29916@titan.lakedaemon.net>
References: <2469263.vMN09Q7Tzi@flatron>
 <20130729150124.GS29916@titan.lakedaemon.net>
 <20130729164905.GB2280@localhost.localdomain>
 <20130729172339.GT29916@titan.lakedaemon.net>
Message-ID: <20130729194829.GG9858@sirena.org.uk>

On Mon, Jul 29, 2013 at 01:23:39PM -0400, Jason Cooper wrote:

> true, the answer to this problem may be to create a depgraph of the
> nodes based on phandles and child status, then init.  However, if the
> goal is to accelerate boot times, then that should not be calculated
> during each boot, especially since it doesn't likely change from boot to
> boot.

FWIW this is broadly speaking what deferred probing is supposed to do -
it seemed too complex and fragile to make the graph for board files so
Grant came up with the idea of deferred probing which aims to sidestep
the problem and work it out dynamically, also providing a fallback in
case something that has actually optimised the ordering misses some case
(cleaning up after the effects of parallel probes for example).
-------------- 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/20130729/2f39878e/attachment.sig>

From robherring2 at gmail.com  Mon Jul 29 16:18:43 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Mon, 29 Jul 2013 15:18:43 -0500
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <20130729101302.GJ3528@e106331-lin.cambridge.arm.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
 <1375048598-15637-2-git-send-email-robherring2@gmail.com>
 <20130729101302.GJ3528@e106331-lin.cambridge.arm.com>
Message-ID: <51F6CE23.30306@gmail.com>

On 07/29/2013 05:13 AM, Mark Rutland wrote:
> Hi Rob,
> 
> On Sun, Jul 28, 2013 at 10:56:32PM +0100, Rob Herring wrote:
>> From: Rob Herring <rob.herring at calxeda.com>
>>
>> The PSCI spec from ARM has been updated to 0.2 version. Update the
>> binding document to reflect the spec changes. For the binding, the
>> major changes are addition of system reset and poweroff functions.
>> The recommended function id numbering has also changed.
>>
>> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
>> Cc: devicetree at vger.kernel.org
>> ---
>>  Documentation/devicetree/bindings/arm/psci.txt | 25 +++++++++++++++++++------
>>  1 file changed, 19 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
>> index 433afe9..b8b4d9f 100644
>> --- a/Documentation/devicetree/bindings/arm/psci.txt
>> +++ b/Documentation/devicetree/bindings/arm/psci.txt
>> @@ -21,7 +21,7 @@ to #0.
>>  
>>  Main node required properties:
>>  
>> - - compatible    : Must be "arm,psci"
>> + - compatible    : Must be "arm,psci-0.2" or "arm,psci"
> 
> For the purposes of handling different firmware implementations (which
> may have different bugs to work around and may require different
> arguments to cpu_suspend), it may be better to state "must contain"
> rather than "must be". 
> 
>>  
>>   - method        : The method of calling the PSCI firmware. Permitted
>>                     values are:
>> @@ -32,6 +32,9 @@ Main node required properties:
>>                     "hvc" : HVC #0, with the register assignments specified
>>  		           in this binding.
>>  
>> + - psci_version  : Function ID for PSCI_VERSION operation. Required for
>> +                   "arm,psci-0.2" compatible version or later.
>> +
>>  Main node optional properties:
>>  
>>   - cpu_suspend   : Function ID for CPU_SUSPEND operation
> 
> The low bits of CPU_SUSPEND's power_state argument are platform specific
> and we'll need to deal with them if an implementation actually uses them
> for something. We can probably associate this with a specific
> implementation's compatible string, as we'll almost certainly need
> special code to handle the differences between them.

I'm not a fan of

> If we have a compatible string for the first platform that ignores the
> argument (or just uses zero), that can be shared by all those
> implementations that don't give any fine-grained control here.
> 
>> @@ -42,14 +45,24 @@ Main node optional properties:
>>  
>>   - migrate       : Function ID for MIGRATE operation
>>  
>> + - system_reset  : Function ID for SYSTEM_RESET operation
>> +
>> + - system_off    : Function ID for SYSTEM_OFF operation
>> +
>>  
>>  Example:
>>  
>>  	psci {
>> -		compatible	= "arm,psci";
>> +		compatible	= "arm,psci-0.2";
>>  		method		= "smc";
>> -		cpu_suspend	= <0x95c10000>;
>> -		cpu_off		= <0x95c10001>;
>> -		cpu_on		= <0x95c10002>;
>> -		migrate		= <0x95c10003>;
>> +		psci_version	= <0x84000000>;
>> +		cpu_suspend	= <0x84000001>;
>> +		cpu_off		= <0x84000002>;
>> +		cpu_on		= <0x84000003>;
>> +		affinity_info	= <0x84000004>; 
>> +		migrate		= <0x84000005>;
>> +		migrate_info_type = <0x84000006>; 
>> +		migrate_info_up_cpu = <0x84000007>; 
>> +		system_off	= <0x84000008>; 
>> +		system_reset	= <0x84000009>; 
>>  	};
> 
> One of the things changed in PSCI 0.2 was the SMC calling convention,
> though this isn't clear in the PSCI document. The function IDs for 32bit
> and 64bit callers may differ, and we need to support describing an
> arbitrary configuration of the two (same ID for both, different across
> 32-bit/64-bit, only supported for 64-bit, only supported for 32-bit).
> 
> I'd like to ensure the binding can deal with that from the start. We
> could do this by having -32 and -64 variants of each function id (e.g.
> cpu_off-64) , if the IDs actually differ, and use the regular combined
> ID if they don't.

Uggg. I guess I should have read the SMC calling convention doc... I was
simply documenting what is already in the PSCI doc, but obviously that
is not fully flushed out.

How about something like this (for the complicated case of both 32 and
64 bit):

	method		= "smc", "smc64";
	psci_version	= <0x84000000 0xc4000000>;
	cpu_suspend	= <0x84000001 0xc4000001>;
	cpu_off		= <0x84000002 0xc4000002>;
	cpu_on		= <0x84000003 0xc4000003>;

"smc" is a synonym for smc32 for compatibility. The number and order of
methods determines the number and order of function IDs.

A variation on this would be keep method as is and add a "#psci-cells"
property to specify the number of function IDs. You can determine the
64-bit vs. 32-bit support based on the function ID itself.

Rob



From davidb at codeaurora.org  Mon Jul 29 16:20:31 2013
From: davidb at codeaurora.org (David Brown)
Date: Mon, 29 Jul 2013 13:20:31 -0700
Subject: [PATCH v2 6/9] ARM: msm: Move mach/board.h contents to common.h
In-Reply-To: <1374699274-18388-7-git-send-email-sboyd@codeaurora.org>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
 <1374699274-18388-7-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130729202031.GA20694@codeaurora.org>

On Wed, Jul 24, 2013 at 01:54:31PM -0700, Stephen Boyd wrote:
>The contents of mach/board.h are only used by files within
>mach-msm so there is no need to export this file outside of the
>mach-msm directory. Move the contents of the file to common.h to
>allow us to compile MSM in the multi-platform kernel.
>
>Cc: Florian Tobias Schandinat <FlorianSchandinat at gmx.de>
>Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>---
> drivers/video/msm/msm_fb.c             |  1 -

It'd be nice to get a framebuffer Ack from this part.

original patch:
  https://patchwork.kernel.org/patch/2833029/

David

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From andrew at lunn.ch  Mon Jul 29 16:43:15 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 29 Jul 2013 22:43:15 +0200
Subject: NSA310 + DT
In-Reply-To: <20130729192112.GY29916@titan.lakedaemon.net>
References: <20130710073706.GA28212@lunn.ch> <51F6A0DC.3020501@uni-bremen.de>
 <20130729192112.GY29916@titan.lakedaemon.net>
Message-ID: <20130729204315.GK24782@lunn.ch>

On Mon, Jul 29, 2013 at 03:21:12PM -0400, Jason Cooper wrote:
> Hi Finn,
> 
> On Mon, Jul 29, 2013 at 07:05:32PM +0200, Finn Hoffmann wrote:
> > Hello,
> > 
> > I have tried to get a current Kernel running on my NSA310.
> 
> Nice.
> 
> > Everything works well on Kernels before DT with the mentioned
> > patches from https://github.com/peeter123/NSA310-320-debian .
> > I have linux-3.10.2 running and after I changed the dts file to lm85
> > sensors and fanconrtol work but GPIO does not.
> > I tried https://github.com/lunn/linux/tree/v3.11-rc1-nsa310-tdc and
> > linux-3.11.0-rc3.
> > Both have the problem that r8169 is not working:
> > r8169: eth0: unknown chipset (mac_version = 0).
> > and console is spammed with
> > r8169 0000:01:00.0 eth0: rtl_phyar_cond == 0 (loop: 20, delay: 25).
> > until I take eth0 down.
> > GPIO is working.

Hi Finn

Thanks for testing my tree. I based it on the patches found in 
https://github.com/peeter123/NSA310-320-debian.

The patch-3.6.9-nsa310.diff does not contain any changes to the
ethernet driver. So you best bet is to ask on the netdev mailing
list.

Once you have it solved, it would be nice if you can send a tested-by:
signoff to my patches.

	Andrew


From jld at mozilla.com  Mon Jul 29 17:21:40 2013
From: jld at mozilla.com (Jed Davis)
Date: Mon, 29 Jul 2013 14:21:40 -0700
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y
In-Reply-To: <20130722185234.GA14519@localhost.localdomain>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
 <20130715135420.GG10000@mudshark.cambridge.arm.com>
 <20130720044655.GC9433@mozilla.com>
 <20130721213753.GA29879@mudshark.cambridge.arm.com>
 <20130722185234.GA14519@localhost.localdomain>
Message-ID: <20130729212140.GB12681@mozilla.com>

On Mon, Jul 22, 2013 at 07:52:39PM +0100, Dave Martin wrote:
> On Sun, Jul 21, 2013 at 10:37:53PM +0100, Will Deacon wrote:
> > Ok, I think I'm with you now. I also think that a better solution would be
> > to try and limit the r7/fp confusion to one place, perhaps behind something
> > like:
> > 
> > void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);
> > 
> > then that function can act as the bridge between pt_regs (where we leave
> > everything as it is) and stackframe (where we assign either r7 or fp into
> > the fp member). Then we just fix up the call sites to pass the regs they're
> > interested in to our new function.
> > 
> > What do you think?

I can see that being useful if we wanted to opacify struct stackframe,
but... all uses of stackframe that I see involve passing it to
unwind_frame, which expands it back out into an array of registers.
(Except with CONFIG_FRAME_POINTER, but "APCS variants that require a
frame pointer register are obsolete.")

So... why not make pt_regs and stackframe the same, and avoid the
translations entirely?

> Do the ARM unwind tables guarantee not to need knowledge of any
> virtual registers for the purpose of processing the opcodes of a single
> function's unwind table entry, except those virtual regs that we happen
> to initialise?  Or do we just rely on luck?

Yes, for some value of "luck".  The spec documents 0x90|N, for N a core
register number other than 13 or 15, as setting the vSP to the value of
virtual register N.  We can get away with some omissions for kernel code
(e.g., unwind.c doesn't handle saved floating point registers, nor adding
constants larger than 1024 to vSP), but is this one of them?

[...]
> The purist answer seems to be: we might need all the regs in struct
> stackframe.
> 
> The pragmatic answer might be that we definitely need r7 for Thumb code,
> but given the nimbleness of GCC to evolve we might get away with not
> including extra registers for a long time yet.

The other question to ask here might be: what does the "pragmatic
answer" gain us over the "purist answer"?

> A review of existing custom unwind annotations might be a good idea
> anyway, to check whether any of them requires another register right now.

`egrep -r '\.(setf|movs)p' arch/arm` finds nothing, for what it's worth.

--Jed



From jason at lakedaemon.net  Mon Jul 29 17:24:00 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 29 Jul 2013 21:24:00 +0000
Subject: [PATCH 1/2] add cscope Makefile target
In-Reply-To: <cover.1375131816.git.jason@lakedaemon.net>
References: <cover.1375131816.git.jason@lakedaemon.net>
Message-ID: <dcc21753a1bf975fc97c5f4c8d089e1fb4b00dd2.1375131816.git.jason@lakedaemon.net>

Signed-off-by: Jason Cooper <jason at lakedaemon.net>
---
 .gitignore | 1 +
 Makefile   | 6 ++++++
 2 files changed, 7 insertions(+)

diff --git a/.gitignore b/.gitignore
index c3b59bf..ac4198c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,6 +1,7 @@
 *.sh
 *.o
 *.bin
+cscope.*
 matcher
 uImage
 input/zImage
diff --git a/Makefile b/Makefile
index 5ad5fc0..daeafa4 100644
--- a/Makefile
+++ b/Makefile
@@ -43,3 +43,9 @@ uImage: matcher.bin
 clean:
 	rm -fr matcher.bin matcher *.o uImage
 
+distclean:
+	rm -fr cscope.*
+
+cscope:
+	-find . -name "*.[chS]" >cscope.files
+	-cscope -b -R
-- 
1.8.3.2



From jason at lakedaemon.net  Mon Jul 29 17:23:59 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 29 Jul 2013 21:23:59 +0000
Subject: [RFC PATCH 0/2] impedance-matcher generic improvements
In-Reply-To: <51F2A014.7000209@gmail.com>
References: <51F2A014.7000209@gmail.com>
Message-ID: <cover.1375131816.git.jason@lakedaemon.net>

Daniel,

Here's a patch (plus a cscope target) to attempt to make the impedance-matcher
generic code.  Hopefully I'll have time to test tomorrow.  All I can say atm is
that it compiles cleanly with and without specifying an appended zImage.

Warning: the code in string.c is little better than psuedo-code, maybe not even
that good.  I'm posting this so if anyone else is inclined to work on this,
there's no need to duplicate effort.  And, I have a firm belief in the
motivating effects af posting half-assed code.  ;-)

Basic idea is to replace a device's stock kernel with this impedance-matcher.
Load the kernel and/or the devicetree blob to desired addresses.  Add
'loadaddrs=0xXXXXXXXX,0xYYYYYYYY' to the kernel's command line.  Or, if you are
appending, 'loadaddrs=appended,0xYYYYYYYY'.  First address is the location of
the kernel, second is the location of the dtb.

Then, for u-boot, 'bootm 0xZZZZZZZZ' where 0xZZZZZZZZ is the address of the
impedance-matcher.

For those interested, a public branch can be found at (prone to rebase!):

  git://git.infradead.org/users/jcooper/impedance-matcher.git master

Thomas,

You weren't in the original Cc: of this thread, I added you because this may
help with your shifting register base address issues.

thx,

Jason.

Jason Cooper (2):
  add cscope Makefile target
  WIP: Get kernel and dtb addresses from command line

 .gitignore |  1 +
 Makefile   | 31 ++++++++++------------
 atags.h    |  6 +++++
 board.c    | 88 --------------------------------------------------------------
 board.h    | 13 ----------
 led.c      | 54 --------------------------------------
 led.h      |  6 -----
 main.c     | 52 +++++++++++++++++++++----------------
 string.c   | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 string.h   |  8 ++++++
 10 files changed, 141 insertions(+), 201 deletions(-)
 delete mode 100644 board.c
 delete mode 100644 board.h
 delete mode 100644 led.c
 delete mode 100644 led.h
 create mode 100644 string.c
 create mode 100644 string.h

-- 
1.8.3.2



From jason at lakedaemon.net  Mon Jul 29 17:24:01 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 29 Jul 2013 21:24:01 +0000
Subject: [RFC PATCH 2/2] WIP: Get kernel and dtb addresses from command line
In-Reply-To: <cover.1375131816.git.jason@lakedaemon.net>
References: <cover.1375131816.git.jason@lakedaemon.net>
Message-ID: <9a3f873a28234e664fc2bfddce8218110c0d8dbd.1375131816.git.jason@lakedaemon.net>

Allow for detached kernel and dtb images.

Signed-off-by: Jason Cooper <jason at lakedaemon.net>
---
 Makefile | 25 ++++++------------
 atags.h  |  6 +++++
 board.c  | 88 ----------------------------------------------------------------
 board.h  | 13 ----------
 led.c    | 54 ---------------------------------------
 led.h    |  6 -----
 main.c   | 52 +++++++++++++++++++++-----------------
 string.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 string.h |  8 ++++++
 9 files changed, 134 insertions(+), 201 deletions(-)
 delete mode 100644 board.c
 delete mode 100644 board.h
 delete mode 100644 led.c
 delete mode 100644 led.h
 create mode 100644 string.c
 create mode 100644 string.h

diff --git a/Makefile b/Makefile
index daeafa4..deb76b9 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,10 @@
-CFLAGS=-Wall -ffreestanding
+ifeq ($(origin APPEND_IMAGE), undefined)
+DOAPPEND=
+else
+DOAPPEND=-DAPPENDED_IMAGE=1
+endif
+
+CFLAGS=-Wall -ffreestanding $(DOAPPEND)
 LDFLAGS=-static -nostdlib
 GCC=$(CROSS_COMPILE)gcc
 OBJCOPY=$(CROSS_COMPILE)objcopy
@@ -6,30 +12,15 @@ LD=$(CROSS_COMPILE)ld
 LOADADDR=0xa0008000
 BINFMT=elf32-littlearm
 
-INPUT_OBJS = \
-	zimage.o		\
-	dtb-raumfeld-controller-0.o	\
-	dtb-raumfeld-controller-1.o	\
-	dtb-raumfeld-controller-2.o	\
-	dtb-raumfeld-connector-0.o	\
-	dtb-raumfeld-connector-1.o	\
-	dtb-raumfeld-connector-2.o	\
-	dtb-raumfeld-speaker-0.o	\
-	dtb-raumfeld-speaker-1.o	\
-	dtb-raumfeld-speaker-2.o
-
 all: uImage
 
-dtb-%.o: input/%.dtb
-	$(OBJCOPY) -I binary -O $(BINFMT) -B arm $^ $@
-
 zimage.o: input/zImage
 	$(OBJCOPY) -I binary -O $(BINFMT) -B arm $^ $@
 
 %.o: %.c
 	$(GCC) $(CFLAGS) -c $^
 
-matcher: main.o print.o board.o led.o $(INPUT_OBJS)
+matcher: main.o print.o string.o $(APPEND_IMAGE)
 	$(LD) $(LDFLAGS) -T matcher.lds -o $@ $^
 
 matcher.bin: matcher
diff --git a/atags.h b/atags.h
index 30e6ee7..67d3d01 100644
--- a/atags.h
+++ b/atags.h
@@ -10,15 +10,21 @@ struct tag_header {
 
 /* board revision */
 #define ATAG_REVISION   0x54410007
+#define ATAG_CMDLINE	0x54410009
 
 struct tag_revision {
 	__u32 rev;
 };
 
+struct tag_cmdline {
+	char cmdline[1];     /* this is the minimum size */
+};
+
 struct tag {
 	struct tag_header hdr;
 	union {
 		struct tag_revision	rev;
+		struct tag_cmdline	cmdline;
 	} u;
 };
 
diff --git a/board.c b/board.c
deleted file mode 100644
index f9c2425..0000000
--- a/board.c
+++ /dev/null
@@ -1,88 +0,0 @@
-#include "types.h"
-#include "board.h"
-
-extern __u32 _binary_input_zImage_start;
-extern __u32 _binary_input_raumfeld_controller_0_dtb_start;
-extern __u32 _binary_input_raumfeld_controller_1_dtb_start;
-extern __u32 _binary_input_raumfeld_controller_2_dtb_start;
-extern __u32 _binary_input_raumfeld_connector_0_dtb_start;
-extern __u32 _binary_input_raumfeld_connector_1_dtb_start;
-extern __u32 _binary_input_raumfeld_connector_2_dtb_start;
-extern __u32 _binary_input_raumfeld_speaker_0_dtb_start;
-extern __u32 _binary_input_raumfeld_speaker_1_dtb_start;
-extern __u32 _binary_input_raumfeld_speaker_2_dtb_start;
-
-static struct board boards[] = {
-	/* Controller */
-	{
-		.machid		= 2413,
-		.system_rev	= 0,
-		.dtb		= &_binary_input_raumfeld_controller_0_dtb_start,
-		.name		= "Raumfeld Controller, revision 0",
-	},
-	{
-		.machid		= 2413,
-		.system_rev	= 1,
-		.dtb		= &_binary_input_raumfeld_controller_1_dtb_start,
-		.name		= "Raumfeld Controller, revision 1",
-	},
-	{
-		.machid		= 2413,
-		.system_rev	= 2,
-		.dtb		= &_binary_input_raumfeld_controller_2_dtb_start,
-		.name		= "Raumfeld Controller, revision 2",
-	},
-
-	/* Controller */
-	{
-		.machid		= 2414,
-		.system_rev	= 0,
-		.dtb		= &_binary_input_raumfeld_connector_0_dtb_start,
-		.name		= "Raumfeld Connector, revision 0",
-	},
-	{
-		.machid		= 2414,
-		.system_rev	= 1,
-		.dtb		= &_binary_input_raumfeld_connector_1_dtb_start,
-		.name		= "Raumfeld Connector, revision 1",
-	},
-	{
-		.machid		= 2414,
-		.system_rev	= 2,
-		.dtb		= &_binary_input_raumfeld_connector_2_dtb_start,
-		.name		= "Raumfeld Connector, revision 2",
-	},
-
-	/* Speaker */
-	{
-		.machid		= 2415,
-		.system_rev	= 0,
-		.dtb		= &_binary_input_raumfeld_speaker_0_dtb_start,
-		.name		= "Raumfeld Speaker, revision 0",
-	},
-	{
-		.machid		= 2415,
-		.system_rev	= 1,
-		.dtb		= &_binary_input_raumfeld_speaker_1_dtb_start,
-		.name		= "Raumfeld Speaker, revision 1",
-	},
-	{
-		.machid		= 2415,
-		.system_rev	= 2,
-		.dtb		= &_binary_input_raumfeld_speaker_2_dtb_start,
-		.name		= "Raumfeld Speaker, revision 2",
-	},
-	{ 0, 0, NULL, NULL }	/* sentinel */
-};
-
-struct board *match_board(__u32 machid, __u32 revision)
-{
-	struct board *board;
-
-	for (board = boards; board->machid; board++)
-		if (board->machid == machid && board->system_rev == revision)
-			return board;
-
-	return NULL;
-}
-
diff --git a/board.h b/board.h
deleted file mode 100644
index b256a6c..0000000
--- a/board.h
+++ /dev/null
@@ -1,13 +0,0 @@
-#ifndef _BOARD_H
-#define _BOARD_H
-
-struct board {
-	__u32		machid;
-	__u32		system_rev;
-	void		*dtb;
-	const char	*name;
-};
-
-struct board *match_board(__u32 machid, __u32 revision);
-
-#endif
diff --git a/led.c b/led.c
deleted file mode 100644
index 837d961..0000000
--- a/led.c
+++ /dev/null
@@ -1,54 +0,0 @@
-#include "types.h"
-#include "led.h"
-
-static inline void writel(__u32 val, __u32 addr)
-{
-	*(volatile __u32 *) addr = val;
-}
-
-static inline __u32 readl(__u32 addr)
-{
-	return *(volatile __u32 *) addr;
-}
-
-static void wait(__u32 ticks)
-{
-	__u32 v;
-
-	/* OSCR */
-	writel(0, 0x40A00010);
-
-	do {
-		v = readl(0x40A00010);
-	} while (ticks > v);
-}
-
-static void led_init(void)
-{
-	writel(0, 0x40e10420);		/* GPIO35 */
-	writel(0, 0x40e10424);		/* GPIO36 */
-	writel(0x18, 0x40e00010);	/* GPDR1 */
-}
-
-static void led_set(__u32 index, __u32 state)
-{
-	__u32 v = 1 << (index ? 3 : 4);
-
-	if (state)
-		writel(v, 0x40e0001c);
-	else
-		writel(v, 0x40e00028);
-}
-
-void led_panic(void)
-{
-	int i;
-
-	led_init();
-
-	for (i = 0;; i++) {
-		led_set(0, i & 1);
-		led_set(1, ~i & 1);
-		wait(500000);
-	}
-}
diff --git a/led.h b/led.h
deleted file mode 100644
index 0cdcf31..0000000
--- a/led.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef _LED_H_
-#define _LED_H_
-
-void led_panic(void);
-
-#endif
diff --git a/main.c b/main.c
index 3dd6636..af2b6c8 100644
--- a/main.c
+++ b/main.c
@@ -1,45 +1,51 @@
 #include "types.h"
 #include "atags.h"
 #include "print.h"
-#include "board.h"
-#include "led.h"
+#include "string.h"
 
+#ifdef DOAPPENDED
 extern __u32 _binary_input_zImage_start;
+#endif
 
 void main(__u32 dummy, __u32 machid, const struct tag *tags)
 {
 	const struct tag *t;
-	struct board *board;
-	__u32 system_rev = 0;
-	void (*start_kernel)(__u32 dummy, __u32 machid, void *dtb) =
-		(void *) &_binary_input_zImage_start;
+	void *kernel=NULL;
+	void *dtb=NULL;
+	void (*start_kernel)(__u32 dummy, __u32 machid, void *dtb);
+
+#ifdef DOAPPENDED
+	start_kernel = (void *) &_binary_input_zImage_start;
+#endif
 
 	putstr("++ Impedance Matcher (3rd stage loader) ++\n");
 
 	/* walk the atags to determine the system revision */
 	for_each_tag(t, tags)
 		switch (t->hdr.tag) {
-			case ATAG_REVISION:
-				system_rev = t->u.rev.rev;
+			case ATAG_CMDLINE:
+				/*
+				 * look for load addresses
+				 * eg: loadaddrs=0x0800000,0x0700000
+				 * for           kernel    dtb
+				 */
+				getaddrs(&kernel, &dtb, t->u.cmdline.cmdline);
 				break;
 		}
 
-	board = match_board(machid, system_rev & 0xff);
-	if (!board) {
-		putstr("ERROR MATCHING BOARD!\n");
-		putstr("MACHID: 0x");
-		printhex(machid);
-		putstr("\n");
-		putstr("SYSTEM_REV: 0x");
-		printhex(system_rev);
-		putstr("\n");
-		led_panic();
-	}
-
-	putstr("Detected board: ");
-	putstr(board->name);
+	if (kernel) {
+		putstr("Kernel: 0x");
+		printhex((__u32)kernel);
+		start_kernel = kernel;
+	} else
+		putstr("Kernel: Appended");
+	putstr("\n");
+
+	putstr("DTB:    0x");
+	printhex((__u32)dtb);
 	putstr("\n");
 
 	putstr("Booting into Linux kernel ...\n");
-	start_kernel(0, 0xffffffff, board->dtb);
+	start_kernel(0, 0xffffffff, dtb);
+
 }
diff --git a/string.c b/string.c
new file mode 100644
index 0000000..8eb459f
--- /dev/null
+++ b/string.c
@@ -0,0 +1,83 @@
+#include "types.h"
+#include "string.h"
+
+int hexlut[1 + 'F' - '0'] = {
+	0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, /* 0 - 9 */
+	0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
+	0xa, 0xb, 0xc, 0xd, 0xe, 0xf                      /* A - F */
+};
+
+int strncmp(const char *stra, const char *strb, int len)
+{
+	int diff=0;
+	const char *a = stra;
+	const char *b = strb;
+
+	while ((a - stra) <= len)
+		diff += *(a++) - *(b++);
+
+	return diff;
+}
+
+void *gethexaddr(const char *str, const char **end)
+{
+	const char *s = str;
+	void *addr = NULL;
+	int shift = 0;
+
+	/* set the end */
+	while (*s) {
+		if (*s != ' ' && *s != '\t' && *s != ',')
+			break;
+		s++;
+	}
+
+	if (!*s)
+		return NULL;
+
+	*end = s;
+	s = *end - 1;
+
+	while (s >= str && *s != 'x') {
+		/* we assume base16! */
+		int off = (*s > 'F') ? 0x20 : 0x0;
+		addr += hexlut[*s - ('0' + off)] << shift;
+		shift += 4;
+		s--;
+	}
+
+	return addr;
+}
+
+int getaddrs(void **k, void **d, const char *str)
+{
+	const char *s = str;
+	const char *end;
+
+	while (*(s++)) {
+		if (*s == 'l')
+			if (strncmp(s, "loadaddrs=", 10) == 0)
+				break;
+	}
+
+	if (!*s)
+		return -1;
+
+	s += 10; /* skip over 'loadaddrs=' */
+
+	/* allow address to be 'appended' for some use cases */
+	if (strncmp(s, "appended", 8) == 0) {
+		*k = NULL;
+		end = s + 8;
+	} else
+		*k = gethexaddr(s, &end);
+
+	if (*end == ',')
+		s = end + 1;
+	else
+		return -1;
+
+	*d = gethexaddr(s, NULL);
+
+	return 0;
+}
diff --git a/string.h b/string.h
new file mode 100644
index 0000000..14d6764
--- /dev/null
+++ b/string.h
@@ -0,0 +1,8 @@
+#ifndef _STRING_H_
+
+#include "types.h"
+
+int strncmp(const char *, const char *, int);
+void *gethexaddr(const char *, const char **);
+int getaddrs(void **, void **, const char *);
+#endif
-- 
1.8.3.2



From neko at bakuhatsu.net  Mon Jul 29 17:39:45 2013
From: neko at bakuhatsu.net (Matt Sealey)
Date: Mon, 29 Jul 2013 16:39:45 -0500
Subject: [PATCH v4 2/6] misc: sram: add ability to mark sram sections as
 reserved
In-Reply-To: <1375106520.4223.24.camel@pizza.hi.pengutronix.de>
References: <201307291510.31679.heiko@sntech.de>
 <201307291512.25126.heiko@sntech.de>
 <1375106520.4223.24.camel@pizza.hi.pengutronix.de>
Message-ID: <CAHCPf3vSQHtRkk-_cs3monHfrF-hVx3vTDt1ctcax_bspXDmsg@mail.gmail.com>

On Mon, Jul 29, 2013 at 9:02 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> Hi Heiko,
>
> Am Montag, den 29.07.2013, 15:12 +0200 schrieb Heiko St?bner:
>> Some SoCs need parts of their sram for special purposes. So while being part
>> of the peripheral, it should not be part of the genpool controlling the sram.
>>
>> Therefore add an option mmio-sram-reserved to keep arbitrary portions of the
>> sram from being part of the pool.
>>
>> Suggested-by: Rob Herring <robherring2 at gmail.com>
>> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
>> Tested-by: Ulrich Prinz <ulrich.prinz at googlemail.com>
>> ---
>> Philipp: I didn't carry the ack, because the loop changed significantly again.
>> So if it looks ok, could you re-ack it please?
>
> I'd prefer the first loop to contain the magic and produce a list of
> useable chunks, instead of a list of reserved blocks. The second loop
> could then iterate over the array and just call gen_pool_add_virt
> repeatedly.
>
> regards
> Philipp

Agreed, however specifying chunks of memory should probably match the
format of the standard memory@ node "available" property - mostly
because it would be the same syntax and definition as defining any
other chunk of memory, as OpenFirmware and device trees have been
doing since the dark ages. In this case, why not re-use the
"available" property name instead of creating a new one? Standard OF
memory parsing code is then free for you to use to pull the chunks
out.

-- 
Matt Sealey <mwsealey at gmail.com>


From swarren at wwwdotorg.org  Mon Jul 29 17:47:55 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 15:47:55 -0600
Subject: Defining schemas for Device Tree
In-Reply-To: <2469263.vMN09Q7Tzi@flatron>
References: <2469263.vMN09Q7Tzi@flatron>
Message-ID: <51F6E30B.7060106@wwwdotorg.org>

On 07/28/2013 06:21 PM, Tomasz Figa wrote:
...
> b) What information should be specified in schemas? What level of 
>    granularity is required?
> 
> For each property we need to have at least following data specified:
>  - property name (or property name format, e.g. regex),
>  - whether the property is mandatory or optional,
>  - data type of value.

We might want general restrictions on node/property names, e.g. it seems
we generally prefer - rather than _ in them, although there are a few
entrenched exceptions.

> As for now, I can think of following data types used in device trees:
>  - boolean (i.e. without value),
>  - array of strings (including single string),
>  - array of u32 (including single u32),
>  - specifier (aka phandle with args, including cases with 0 args),
>  - variable-length cells (e.g. #address-cells of u32s).
> 
> Some properties might require a combination of data types to be specified 

I believe phandles are just cells in terms of the storage type at least.
Hence, I'd argue we don't need mixing of types (boolean, cell, string),
but I see your point about semantically needing to represent different
cells meaning different things.

> or even an array of combinations, like interrupt-map property, which is an 
> array of entries consisting of:
>  - #address-cells u32s,
>  - #interrupt-cells u32s,
>  - specifier (phandle of interrupt controller and u32 of count defined by 
>    #interrupt-cells of the controller).
> 
> We probably want to define allowed range of values for given property, be 
> it contiguous or enumerated.

Where defining the length of a property (or part of it) in terms of
another #xxx-cells property, we need to specify where that other
property exists. Sometimes it's the nearest parent node containing the
property (typical for #address-cells), sometimes it's the node
containing the property itself (typical for one of the #address-cells
referenced by a ranges property), and sometimes it's in the node
referenced by the phandle associated with a specifier.

Other content restrictions might be:

* List must contain (at least) these entries/values.

* List can't contain any other entries/values not specified here.

* List must be in this order vs. any order.

* List logical length (in entries, not bytes/cells) must match the
logical length of another cell (consider clocks/clock-names).

* Ordering of one property must match ordering of another property
(again consider clocks/clock-names), although it'd be difficult to tell
whether this condition was met, perhaps we can at least document it.

I'm sure there will be many more criteria to validate that we're
forgetting. This is possible the most complex area?

> As for subnodes, I think we need to define following constraints:
>  - node name (or node name format, e.g. regex),

I don't think node names are supposed to convey any semantic meaning, so
they probably shouldn't be restricted (much?) by schema.

> d) When should the validation happen and what should handle it?
...
> well. Nothing stops us from running validation on already compiled dtbs, 
> though, using an extra tool.

In a DTB, I'm not sure whether all the type information is still present.

For example, in DTS, the following are very obviously different:

prop = "abc", "def";
prop = <0x61626300> <0x64656600>;

... whereas in the DTB, I think they are both just two 32-bit values
that just happen to encode string data or not. Presumably we want the
validator to force string properties to be specified using string syntax?

Equally, I'm not sure there's any difference between:

prop = <&node>;
prop = <0x23648689>;

... in the DTB, except that the value just *happens* to match another
node's phandle value, which could end up leading to false positive
matches if only applied on the raw values not the syntax?



From swarren at wwwdotorg.org  Mon Jul 29 18:01:59 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 16:01:59 -0600
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130729090524.GY7656@atomide.com>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost> <51E70953.1000601@wwwdotorg.org>
 <20130718072034.GO7656@atomide.com> <51E8401E.8040705@wwwdotorg.org>
 <20130719072927.GY7656@atomide.com> <51E98AEC.5000802@wwwdotorg.org>
 <20130729090524.GY7656@atomide.com>
Message-ID: <51F6E657.2060802@wwwdotorg.org>

On 07/29/2013 03:05 AM, Tony Lindgren wrote:
> * Stephen Warren <swarren at wwwdotorg.org> [130719 11:59]:
>> On 07/19/2013 01:29 AM, Tony Lindgren wrote:
>>>
>>> I'd vote for keeping the existing behaviour with pinctrl_select_state()
>>> when no active state is defined.
>>
>> Yes, I think that will work, since the active state cannot exist before
>> this new scheme is in place.
> 
> Right.
>  
>> But, this needs to be very clearly spell out in the DT binding
>> documentation: If you have states default/idle/sleep, they're complete
>> alternatives, whereas if you have states default/active/idle/sleep, the
>> latter 3 are alternatives that build on top of the first. I foresee mass
>> confusion, but perhaps I'm being pessimistic.
> 
> I'm hoping we can automate the runtime PM handling with default/active/idle
> completely from the consumer driver point of view. And then when that's
> working, we can probably deprecate any runtime PM related handling using
> pinctr_select_state() and print warnings. And we can also improve the
> documentation so no new users will use the default/idle/sleep for runtime
> PM unless they really want to.

I was thinking more about people writing the device trees that define
these states; they need to explicitly make the choice re: overlapping
states or independent states. We should not plan to obsolete any current
usage of overlapping states since that will mean an incompatible change
to the DT ABI (deprecate yes so that no more usage is added, but the
kernel should still support the old way).



From festevam at gmail.com  Mon Jul 29 18:04:02 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 29 Jul 2013 19:04:02 -0300
Subject: [BUILD BREAKAGE] today's next build broken for pcm037
In-Reply-To: <Pine.LNX.4.64.1307291458560.14405@axis700.grange>
References: <Pine.LNX.4.64.1307291458560.14405@axis700.grange>
Message-ID: <CAOMZO5CO54+HgMHh+p_h386P72odZinF9a0T198K6sMLCrYZzQ@mail.gmail.com>

Hi Guennadi,

On Mon, Jul 29, 2013 at 10:03 AM, Guennadi Liakhovetski
<g.liakhovetski at gmx.de> wrote:
> Hi Sascha,
>
> Attached .config fails to build for me with today's next as follows:
>
> ERROR: "imx_pcm_dma_init" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined!
> ERROR: "imx_pcm_dma_exit" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined!

Just sent a patch for this:
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-July/064715.html

Regards,

Fabio Estevam


From swarren at wwwdotorg.org  Mon Jul 29 18:08:44 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 16:08:44 -0600
Subject: [PATCH 3/4] pinctrl: Add support for additional dynamic states
In-Reply-To: <20130729092116.GA7656@atomide.com>
References: <20130716090310.5541.36777.stgit@localhost>
 <20130716090536.5541.36289.stgit@localhost> <51E70B5D.6030802@wwwdotorg.org>
 <20130718073638.GP7656@atomide.com> <51E84180.6080902@wwwdotorg.org>
 <20130719073957.GZ7656@atomide.com> <51E98C71.5010709@wwwdotorg.org>
 <20130729092116.GA7656@atomide.com>
Message-ID: <51F6E7EC.4000402@wwwdotorg.org>

On 07/29/2013 03:21 AM, Tony Lindgren wrote:
> * Stephen Warren <swarren at wwwdotorg.org> [130719 12:05]:
>> On 07/19/2013 01:39 AM, Tony Lindgren wrote:
>>>
>>> I think the only sane way to deal with this is to make the I2C controller
>>> to show up as two separate I2C controller instances. Then use runtime
>>> PM to save and restore the state for each instance, and locking between
>>> the two driver instances.
>>>
>>> For the pin muxing part, I'd do this:
>>>
>>> 			i2c1 instance	i2c2 instance	notes
>>> default_state		0 pins		0 pins		(or dedicated pins only)
>>> active_state		all pins	alls pins
>>> idle_state		safe mode	safe mode
>>>
>>> Then when i2c1 instance is done, it's runtime PM suspend muxes the pins
>>> to safe mode, or some nop state. Then when i2c2 instance is woken, it's
>>> runtime PM resume muxes pins to i2c2.
>>
>> I see two issues with that approach:
>>
>> 1) Runtime PM doesn't always put a device into an idle state as soon as
>> its work is done. Sometimes (always?) there is a delay between when the
>> device is last used and when the HW is actually made idle so that if the
>> device is re-activated quickly, the kernel hasn't wasted time making it
>> idle then active again. You'd have to force that delay to complete when
>> switching between the two virtual controller devices.
> 
> There is the autosuspend timeout for delayed transitions, but I think
> runtime PM already has calls for making the state change immediate also.

True, but I /think/ that then you could never use the APIs that perform
delayed idle, since you'd always need to force immediate idle to
guarantee you could always immediately switch to the other
state/virtual-controller.

>> 2) This requires two separate device objects for the two I2C instances.
>> I guess you could have the driver for the one I2C mux node end up
>> instantiating two child devices for this purpose, and hence make that
>> happen without needing to change the DT ABI. However, that sure feels
>> complex...
> 
> Yes but you will also automatically get quite a bit of sanity to your
> I2C driver code rather than trying to handle the two separate instances
> within the driver alone. Consider things like scanning the I2C buses for
> devices and just dev_dbg().

The I2C mux is already very simple. IIRC, it instantiates a separate
"struct i2c_adapter" for each "virtual" I2C controller. It actually
looks like each of those already embeds its own "struct device", so
perhaps this issue is a little moot. However, we'd have to find some way
of redirecting pinctrl requests from those child devices to the
top-level I2C mux struct device itself, since that's what the pinctrl
mapping table entries are defined for. It seems much simpler to just
leave the pinctrl stuff controlled by that top-level device, rather than
pushing it down to the child virtual devices/adapters.


From linux at roeck-us.net  Mon Jul 29 18:18:13 2013
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 29 Jul 2013 15:18:13 -0700
Subject: [PATCH v7] watchdog: Add MOXA ART watchdog driver
In-Reply-To: <1375101228-10930-1-git-send-email-jonas.jensen@gmail.com>
References: <1375098093-8975-1-git-send-email-jonas.jensen@gmail.com>
 <1375101228-10930-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <51F6EA25.6090105@roeck-us.net>

On 07/29/2013 05:33 AM, Jonas Jensen wrote:
> Add watchdog driver for MOXA ART SoCs.
>
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>

Reviewed-by: Guenter Roeck <linux at roeck-us.net>



From benoit.cousson at gmail.com  Mon Jul 29 18:18:11 2013
From: benoit.cousson at gmail.com (Benoit Cousson)
Date: Tue, 30 Jul 2013 00:18:11 +0200
Subject: [PATCH V2 0/3] ARM: dts: omap5-uevm: fixup wrong regulator
 configuration
In-Reply-To: <1375117383-19285-1-git-send-email-nm@ti.com>
References: <51F67D7D.9070003@ti.com>
 <1375117383-19285-1-git-send-email-nm@ti.com>
Message-ID: <51F6EA23.50803@gmail.com>

Hi Nishanth,

Thanks for the quick update.

On 29/07/2013 19:03, Nishanth Menon wrote:
> Due to wrong older revision of documentation used as reference, we
> seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
> series is based power tree on production board 750-2628-XXX platform.
> Unfortunately, the wrong voltages may be detrimental to OMAP5 as they
> supply hardware blocks at voltages that are out of specification.
>
> Also available at:
> based on v3.11-rc1 tag
> http link: https://github.com/nmenon/linux-2.6-playground/commits/push/omap5-palmas-fixes-v2
> git link: git://github.com/nmenon/linux-2.6-playground.git
> branch: push/omap5-palmas-fixes-v2
>
> Changes since V1:
>  - squash of patches
>  - picked up Ack from Keerthy
>  - based on v3.11-rc3 tag
>
> V1: http://marc.info/?t=137407980100008&r=1&w=2
>
> Nishanth Menon (3):
>   ARM: dts: omap5-uevm: document regulator signals used on the actual
>     board
>   ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC
>   ARM: dts: omap5-uevm: update optional/unused regulator configurations
>
>  arch/arm/boot/dts/omap5-uevm.dts |   78 ++++++++++++++++++++++++--------------
>  1 file changed, 49 insertions(+), 29 deletions(-)
>
> Regards,
> Nishanth Menon

For the whole series:

Acked-by: Benoit Cousson <benoit.cousson at gmail.com>


From tomasz.figa at gmail.com  Mon Jul 29 18:20:35 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 30 Jul 2013 00:20:35 +0200
Subject: Defining schemas for Device Tree
In-Reply-To: <51F6E30B.7060106@wwwdotorg.org>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
Message-ID: <6809706.cRofzbG9CV@thinkpad>

On Monday 29 of July 2013 15:47:55 Stephen Warren wrote:
> On 07/28/2013 06:21 PM, Tomasz Figa wrote:
> ...
> 
> > b) What information should be specified in schemas? What level of
> > 
> >    granularity is required?
> > 
> > For each property we need to have at least following data specified:
> >  - property name (or property name format, e.g. regex),
> >  - whether the property is mandatory or optional,
> >  - data type of value.
> 
> We might want general restrictions on node/property names, e.g. it seems
> we generally prefer - rather than _ in them, although there are a few
> entrenched exceptions.

Yes.

> > As for now, I can think of following data types used in device trees:
> >  - boolean (i.e. without value),
> >  - array of strings (including single string),
> >  - array of u32 (including single u32),
> >  - specifier (aka phandle with args, including cases with 0 args),
> >  - variable-length cells (e.g. #address-cells of u32s).
> > 
> > Some properties might require a combination of data types to be specified
> 
> I believe phandles are just cells in terms of the storage type at least.
> Hence, I'd argue we don't need mixing of types (boolean, cell, string),
> but I see your point about semantically needing to represent different
> cells meaning different things.

Let me return to this point a bit later in this message.

> > or even an array of combinations, like interrupt-map property, which is an
> > 
> > array of entries consisting of:
> >  - #address-cells u32s,
> >  - #interrupt-cells u32s,
> >  - specifier (phandle of interrupt controller and u32 of count defined by
> >  
> >    #interrupt-cells of the controller).
> > 
> > We probably want to define allowed range of values for given property, be
> > it contiguous or enumerated.
> 
> Where defining the length of a property (or part of it) in terms of
> another #xxx-cells property, we need to specify where that other
> property exists. Sometimes it's the nearest parent node containing the
> property (typical for #address-cells), sometimes it's the node
> containing the property itself (typical for one of the #address-cells
> referenced by a ranges property), and sometimes it's in the node
> referenced by the phandle associated with a specifier.
> 
> Other content restrictions might be:
> 
> * List must contain (at least) these entries/values.
> 
> * List can't contain any other entries/values not specified here.
> 
> * List must be in this order vs. any order.
> 
> * List logical length (in entries, not bytes/cells) must match the
> logical length of another cell (consider clocks/clock-names).
> 
> * Ordering of one property must match ordering of another property
> (again consider clocks/clock-names), although it'd be difficult to tell
> whether this condition was met, perhaps we can at least document it.
> 
> I'm sure there will be many more criteria to validate that we're
> forgetting. This is possible the most complex area?

Right. Still, this is about the granularity of checks we really need. Do we 
need to check for all those restrictions?

> > As for subnodes, I think we need to define following constraints:
> >  - node name (or node name format, e.g. regex),
> 
> I don't think node names are supposed to convey any semantic meaning, so
> they probably shouldn't be restricted (much?) by schema.

There are bindings currently that require specific node names. Since 
of_match_node() can do matching by names as well, I think we should care about 
node names too,

> > d) When should the validation happen and what should handle it?
> 
> ...
> 
> > well. Nothing stops us from running validation on already compiled dtbs,
> > though, using an extra tool.
> 
> In a DTB, I'm not sure whether all the type information is still present.
> 
> For example, in DTS, the following are very obviously different:
> 
> prop = "abc", "def";
> prop = <0x61626300> <0x64656600>;
> 
> ... whereas in the DTB, I think they are both just two 32-bit values
> that just happen to encode string data or not. Presumably we want the
> validator to force string properties to be specified using string syntax?
> 
> Equally, I'm not sure there's any difference between:
> 
> prop = <&node>;
> prop = <0x23648689>;
> 
> ... in the DTB, except that the value just *happens* to match another
> node's phandle value, which could end up leading to false positive
> matches if only applied on the raw values not the syntax?

This is a good point. From driver's perspective it doesn't matter how you 
specify value of some property, as long as it can be parsed using the same 
code. As a more trivial example, consider following dts code:

	array-prop = <0>, <1>, <2>;
	array-prop-2 = <0 1 2>;

Both array props contain the same data and can be parsed using the same code, 
but from reader's perspective they mean something slightly different - an array 
with 1 cell per element and a single entry of 3 cells.

Now back to the point I deferred my reply to, I think we need different 
handling for at least phandles and properties of which number of cells is 
specified by one or more properties (possibly in other nodes).

At DTS level phandle properties should use the phandle syntax, pointing at 
some node, while at DTB level a raw phandle value could be validated by 
checking if it matches with phandle of some node.

For properties ussing #xxx-cells properties we need to check for correct 
number of cells., which involves getting values of right #xxx-cells 
properties.

Best regards,
Tomasz



From jonsmirl at gmail.com  Mon Jul 29 18:23:30 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Mon, 29 Jul 2013 18:23:30 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <51F6E30B.7060106@wwwdotorg.org>
References: <2469263.vMN09Q7Tzi@flatron>
	<51F6E30B.7060106@wwwdotorg.org>
Message-ID: <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>

The schema should enforce some kind of regularity into the description
of similar devices.  Take SPI for example. I pulled these SPI
controller definitions from the kernel source. Obviously all of these
controllers are different, but it seems to me that their definitions
could be made more regular. DMA seems like it could use a lot of help.

spi_0: spi at 13920000 {
compatible = "samsung,exynos4210-spi";
reg = <0x13920000 0x100>;
interrupts = <0 66 0>;
tx-dma-channel = <&pdma0 7>; /* preliminary */
rx-dma-channel = <&pdma0 6>; /* preliminary */
#address-cells = <1>;
#size-cells = <0>;
clocks = <&clock 327>, <&clock 159>;
clock-names = "spi", "spi_busclk0";
pinctrl-names = "default";
pinctrl-0 = <&spi0_bus>;
status = "disabled";
};

spi1: spi at 1f0e000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "ti,da830-spi";
reg = <0x30e000 0x1000>;
num-cs = <4>;
ti,davinci-spi-intr-line = <1>;
interrupts = <56>;
status = "disabled";
};

spi0: spi at b00d0000 {
cell-index = <0>;
compatible = "sirf,prima2-spi";
reg = <0xb00d0000 0x10000>;
interrupts = <15>;
sirf,spi-num-chipselects = <1>;
cs-gpios = <&gpio 0 0>;
sirf,spi-dma-rx-channel = <25>;
sirf,spi-dma-tx-channel = <20>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&clks 19>;
status = "disabled";
};

spi0: spi at f0000000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "atmel,at91rm9200-spi";
reg = <0xf0000000 0x100>;
interrupts = <13 IRQ_TYPE_LEVEL_HIGH 3>;
dmas = <&dma0 1 AT91_DMA_CFG_PER_ID(1)>,
      <&dma0 1 AT91_DMA_CFG_PER_ID(2)>;
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_spi0>;
status = "disabled";
};

spi0: spi at 48030000 {
compatible = "ti,omap4-mcspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x48030000 0x400>;
interrupts = <65>;
ti,spi-num-cs = <2>;
ti,hwmods = "spi0";
status = "disabled";
};

mcspi1: spi at 48098000 {
compatible = "ti,omap4-mcspi";
reg = <0x48098000 0x200>;
interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "mcspi1";
ti,spi-num-cs = <4>;
dmas = <&sdma 35>,
      <&sdma 36>,
      <&sdma 37>,
      <&sdma 38>,
      <&sdma 39>,
      <&sdma 40>,
      <&sdma 41>,
      <&sdma 42>;
dma-names = "tx0", "rx0", "tx1", "rx1",
   "tx2", "rx2", "tx3", "rx3";
};

spi at 7000d400 {
compatible = "nvidia,tegra114-spi";
reg = <0x7000d400 0x200>;
interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
nvidia,dma-request-selector = <&apbdma 15>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&tegra_car TEGRA114_CLK_SBC1>;
clock-names = "spi";
status = "disabled";
};

On Mon, Jul 29, 2013 at 5:47 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/28/2013 06:21 PM, Tomasz Figa wrote:
> ...
>> b) What information should be specified in schemas? What level of
>>    granularity is required?
>>
>> For each property we need to have at least following data specified:
>>  - property name (or property name format, e.g. regex),
>>  - whether the property is mandatory or optional,
>>  - data type of value.
>
> We might want general restrictions on node/property names, e.g. it seems
> we generally prefer - rather than _ in them, although there are a few
> entrenched exceptions.
>
>> As for now, I can think of following data types used in device trees:
>>  - boolean (i.e. without value),
>>  - array of strings (including single string),
>>  - array of u32 (including single u32),
>>  - specifier (aka phandle with args, including cases with 0 args),
>>  - variable-length cells (e.g. #address-cells of u32s).
>>
>> Some properties might require a combination of data types to be specified
>
> I believe phandles are just cells in terms of the storage type at least.
> Hence, I'd argue we don't need mixing of types (boolean, cell, string),
> but I see your point about semantically needing to represent different
> cells meaning different things.
>
>> or even an array of combinations, like interrupt-map property, which is an
>> array of entries consisting of:
>>  - #address-cells u32s,
>>  - #interrupt-cells u32s,
>>  - specifier (phandle of interrupt controller and u32 of count defined by
>>    #interrupt-cells of the controller).
>>
>> We probably want to define allowed range of values for given property, be
>> it contiguous or enumerated.
>
> Where defining the length of a property (or part of it) in terms of
> another #xxx-cells property, we need to specify where that other
> property exists. Sometimes it's the nearest parent node containing the
> property (typical for #address-cells), sometimes it's the node
> containing the property itself (typical for one of the #address-cells
> referenced by a ranges property), and sometimes it's in the node
> referenced by the phandle associated with a specifier.
>
> Other content restrictions might be:
>
> * List must contain (at least) these entries/values.
>
> * List can't contain any other entries/values not specified here.
>
> * List must be in this order vs. any order.
>
> * List logical length (in entries, not bytes/cells) must match the
> logical length of another cell (consider clocks/clock-names).
>
> * Ordering of one property must match ordering of another property
> (again consider clocks/clock-names), although it'd be difficult to tell
> whether this condition was met, perhaps we can at least document it.
>
> I'm sure there will be many more criteria to validate that we're
> forgetting. This is possible the most complex area?
>
>> As for subnodes, I think we need to define following constraints:
>>  - node name (or node name format, e.g. regex),
>
> I don't think node names are supposed to convey any semantic meaning, so
> they probably shouldn't be restricted (much?) by schema.
>
>> d) When should the validation happen and what should handle it?
> ...
>> well. Nothing stops us from running validation on already compiled dtbs,
>> though, using an extra tool.
>
> In a DTB, I'm not sure whether all the type information is still present.
>
> For example, in DTS, the following are very obviously different:
>
> prop = "abc", "def";
> prop = <0x61626300> <0x64656600>;
>
> ... whereas in the DTB, I think they are both just two 32-bit values
> that just happen to encode string data or not. Presumably we want the
> validator to force string properties to be specified using string syntax?
>
> Equally, I'm not sure there's any difference between:
>
> prop = <&node>;
> prop = <0x23648689>;
>
> ... in the DTB, except that the value just *happens* to match another
> node's phandle value, which could end up leading to false positive
> matches if only applied on the raw values not the syntax?
>



-- 
Jon Smirl
jonsmirl at gmail.com


From tomasz.figa at gmail.com  Mon Jul 29 18:26:17 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 30 Jul 2013 00:26:17 +0200
Subject: Defining schemas for Device Tree
In-Reply-To: <20130729181550.GD15861@obsidianresearch.com>
References: <2469263.vMN09Q7Tzi@flatron>
 <20130729181550.GD15861@obsidianresearch.com>
Message-ID: <2616428.Qqf6nluuzC@thinkpad>

On Monday 29 of July 2013 12:15:50 Jason Gunthorpe wrote:
> On Mon, Jul 29, 2013 at 02:21:52AM +0200, Tomasz Figa wrote:
> > e) What format should be used for Device Tree schema?
> > 
> > This is a non-trivial problem. Key criteria I can think of are as
> 
> > follows:
> You may wish to think about this as a linter+checker (like
> sparse/coverity, etc) and code the 'schema' in C code.
> 
> As you've noticed already there are many complex cases. Look at the
> PCI bindings, for instance, the complexity of what needs to be valided
> is very high.

This sounds like an interesting idea. Not sure about usability of such schemas 
as human-readable documentation, though.

Best regards,
Tomasz



From david at gibson.dropbear.id.au  Mon Jul 29 18:20:39 2013
From: david at gibson.dropbear.id.au (David Gibson)
Date: Tue, 30 Jul 2013 08:20:39 +1000
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130729180513.GB1884@obsidianresearch.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F39FD8.6080808@broadcom.com> <20130727183059.GD4813@netboy>
 <1441731.8CGUI1tUxh@flatron>
 <20130729180513.GB1884@obsidianresearch.com>
Message-ID: <20130729222039.GE29970@voom.fritz.box>

On Mon, Jul 29, 2013 at 12:05:13PM -0600, Jason Gunthorpe wrote:
> On Sat, Jul 27, 2013 at 11:51:06AM -0700, Tomasz Figa wrote:
> 
> > Well, it depends on how we use the DT. There are (at least) two possible 
> > usage scenarios:
> > 
> >  a) using DT as direct replacement for board files - this means that you 
> >     are free to say that DTSes are strictly coupled with kernel version 
> >     and you are free to modify the bindings - see the analogy to board 
> >     files, where you could modify the platform data structures and could 
> >     not directly copy board file from one kernel version to another,
> > 
> >  b) using DT as an ABI - this is the original way, i.e. define stable 
> >     bindings and make sure that anu DTB built for older kernel will work,
> >     with equal or greater set of functionality on newer kernels.
> > 
> > Now I believe in this thread the point whether we should use a) or b) or a 
> > combination of both has been raised.
> 
> Right, and I think it is very important to consider that different
> systems can legitimately fall into those categories.
> 
> Clearly general purpose systems (eg servers, workstations, etc) with
> *full featured firmware* fall into category b. Linux already basically
> has stable DT for those systems - but the firmware is expected to do
> lots of work and hide all the low level details from the
> kernel.  Basically, the DT should stick to approximately ePAR and
> everything else is hidden by the firmware.

No.  With the exception of the hypervisor/virtualization extensions,
ePAPR describes (for now) an entirely passive firmware interface.
That is, once the handover to the OS has happened, there is *no*
further firmware interaction.  It is not capable of hiding any details
from the OS, except those which can be done by one-time
initialization.

In fact, a guiding principle of ePAPR's design was that except in
cases where it's *much* easier for the firmware to do things, the OS
should be expected to do it, because the OS is usually easier to fix
than the firmware.

> This is essentially how x86
> works and achieves its compatibility.
> 
> Systems that have minimalist firmware, where firmware functions are
> pushed into the kernel and the DT is now required to describe
> intricate and unique SOC specific functions are clearly very
> different, and I think it makes sense to encourage those environments
> to be case 'a'.
> 
> Basically, minimalist firmware should have a boot process design that
> *can* couple the DT and kernel, while full featured firmware should
> keep them seperate. IMHO that should be the clear message to people
> implementing this stuff.
> 
> After enough time the DT for 'a' should become stable and churn free,
> but expecting/demanding that from day 0 is not helping anyone, IMHO.
> 
> Jason

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130730/1061cd59/attachment-0001.sig>

From david at gibson.dropbear.id.au  Mon Jul 29 18:29:20 2013
From: david at gibson.dropbear.id.au (David Gibson)
Date: Tue, 30 Jul 2013 08:29:20 +1000
Subject: [Ksummit-2013-discuss] Defining schemas for Device Tree
In-Reply-To: <20130729172339.GT29916@titan.lakedaemon.net>
References: <2469263.vMN09Q7Tzi@flatron>
 <20130729150124.GS29916@titan.lakedaemon.net>
 <20130729164905.GB2280@localhost.localdomain>
 <20130729172339.GT29916@titan.lakedaemon.net>
Message-ID: <20130729222920.GF29970@voom.fritz.box>

On Mon, Jul 29, 2013 at 01:23:39PM -0400, Jason Cooper wrote:
> On Mon, Jul 29, 2013 at 05:49:05PM +0100, Dave Martin wrote:
> > On Mon, Jul 29, 2013 at 11:01:24AM -0400, Jason Cooper wrote:
> > > On Mon, Jul 29, 2013 at 02:21:52AM +0200, Tomasz Figa wrote:
> 
> > > > b) What information should be specified in schemas? What level of 
> > > >    granularity is required?
> > > 
> > > One item I don't see in this list is node ordering.  There's been some
> > > discussion lately on deferred probing (re boot times).  If we were to
> > > intentionally declare that DT are parsed in the order written, then a
> > > lot of deferred probes could be avoided by moving eg the pinctrl node to
> > > near the top of the tree.
> > > 
> > > This doesn't impact buses as much, since the nodes needing the bus are
> > > already children.  However, anything accessed via phandles: pins,
> > > clocks, regulators, etc could benefit from declaring and enforcing this.
> > > Eg having the dtc warn when a phandle is used before it's corresponding
> > > node is declared.
> > > 
> > > Not critical though, just a thought.
> > 
> > I don't think that siblings have any defined order in DT.  If reading a
> > device tree, there's no guarantee you get nodes or properties out in the
> > same order as the original .dts file.
> 
> That's why I raised the point.  If people think encoding initialization
> order in the DT is a good idea, then we should change the dtc so it
> compiles/decompiles in the same order.

I've always considered the DT to be unordered, although the flattened
representation obviously has to have some order.  It is much safer to
explicitly represent any required orderings with properties, rather
than to rely on the flattened tree order.  I really don't think trying
to have dtc magically understand device initialization ordering in
this way is a good idea.

Fwiw, dtc generally preserves order between input and output, with the
exception of the -s option, which sorts the subnodes of each node by
name (useful for dtdiff).

> > Provided child/parent relationships are maintained and the set of nodes
> > and values is the same, I think completely rearranging a .dts file does
> > not change its meaning.
> > 
> > "depends-on" relationships mostly have to come from the semantics of
> > the bindings themselves: for example, if a device is connected to some
> > clocks and regulators, the kernel may need to probe those first.
> 
> true, the answer to this problem may be to create a depgraph of the
> nodes based on phandles and child status, then init.  However, if the
> goal is to accelerate boot times, then that should not be calculated
> during each boot, especially since it doesn't likely change from boot to
> boot.
> 
> Which means it would either go in the dtc (dts node ordering is
> irrelevant), or in the dts.  I'm inclined to say dtc should do it, but I
> like the aesthetics of things being in the proper order in something I
> can read.  After all, C requires functions to be declared before use,
> even though the compiler could figure it out.

It's not necessarily possible to encode device initialization order in
flattened tree order.  Suppose you have bus A with devices A1 and A2,
and bus B with devices B1 and B2.  A1 must be initialized before B1,
but B2 must be initialized before A2.  There are no loops there, it's
a valid set of initialization order constraints, but you can't get
both of them right in the flat tree ordering.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130730/c63ed571/attachment.sig>

From mgr at pengutronix.de  Mon Jul 29 18:30:25 2013
From: mgr at pengutronix.de (Michael Grzeschik)
Date: Tue, 30 Jul 2013 00:30:25 +0200
Subject: [PATCH v13 02/14] usb: chipidea: imx: remove vbus regulator
 operation
In-Reply-To: <1374830310-21765-3-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
 <1374830310-21765-3-git-send-email-peter.chen@freescale.com>
Message-ID: <20130729223025.GA7109@pengutronix.de>

Hi Peter,

On Fri, Jul 26, 2013 at 05:18:18PM +0800, Peter Chen wrote:
> Since we have added vbus reguatlor operation at common
> host file (chipidea/host.c), the glue layer vbus operation
> isn't needed any more.
> 
> Tested-by: Marek Vasut <marex at denx.de>
> Signed-off-by: Peter Chen <peter.chen at freescale.com>
> ---
>  drivers/usb/chipidea/ci_hdrc_imx.c |   30 +++++++-----------------------
>  1 files changed, 7 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
> index 14362c0..d06355e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -31,7 +31,6 @@ struct ci_hdrc_imx_data {
>  	struct usb_phy *phy;
>  	struct platform_device *ci_pdev;
>  	struct clk *clk;
> -	struct regulator *reg_vbus;
>  };
>  
>  static const struct usbmisc_ops *usbmisc_ops;
> @@ -141,22 +140,13 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>  		goto err_clk;
>  	}
>  
> -	/* we only support host now, so enable vbus here */
> -	data->reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
> -	if (!IS_ERR(data->reg_vbus)) {
> -		ret = regulator_enable(data->reg_vbus);
> -		if (ret) {
> -			dev_err(&pdev->dev,
> -				"Failed to enable vbus regulator, err=%d\n",
> -				ret);
> -			goto err_clk;
> -		}
> -	} else {
> -		data->reg_vbus = NULL;
> -	}
> -
>  	pdata.phy = data->phy;
>  
> +	/* Get the vbus regulator */
> +	pdata.reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
> +	if (IS_ERR(pdata.reg_vbus))
> +		pdata.reg_vbus = NULL;
> +

This hunk needs the reg_vbus variable from the previous patch, therefor
it should also be added in that patch. As the user of the variable is
the previous patch, it's the reason to swap their order.

Anyway, can't this be done in core.c instead? I don't see why other
users don't need this code.

>  	if (!pdev->dev.dma_mask)
>  		pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
>  	if (!pdev->dev.coherent_dma_mask)
> @@ -167,7 +157,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>  		if (ret) {
>  			dev_err(&pdev->dev,
>  				"usbmisc init failed, ret=%d\n", ret);
> -			goto err;
> +			goto err_clk;
>  		}
>  	}
>  
> @@ -179,7 +169,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>  		dev_err(&pdev->dev,
>  			"Can't register ci_hdrc platform device, err=%d\n",
>  			ret);
> -		goto err;
> +		goto err_clk;
>  	}
>  
>  	if (usbmisc_ops && usbmisc_ops->post) {
> @@ -200,9 +190,6 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>  
>  disable_device:
>  	ci_hdrc_remove_device(data->ci_pdev);
> -err:
> -	if (data->reg_vbus)
> -		regulator_disable(data->reg_vbus);
>  err_clk:
>  	clk_disable_unprepare(data->clk);
>  	return ret;
> @@ -215,9 +202,6 @@ static int ci_hdrc_imx_remove(struct platform_device *pdev)
>  	pm_runtime_disable(&pdev->dev);
>  	ci_hdrc_remove_device(data->ci_pdev);
>  
> -	if (data->reg_vbus)
> -		regulator_disable(data->reg_vbus);
> -
>  	if (data->phy) {
>  		usb_phy_shutdown(data->phy);
>  		module_put(data->phy->dev->driver->owner);
> -- 
> 1.7.0.4
> 
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From swarren at wwwdotorg.org  Mon Jul 29 18:38:59 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 16:38:59 -0600
Subject: [PATCH 1/8] ARM: tegra: add common resume handling code for LP1
 resuming
In-Reply-To: <1374830110-30685-2-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
 <1374830110-30685-2-git-send-email-josephl@nvidia.com>
Message-ID: <51F6EF03.9000003@wwwdotorg.org>

On 07/26/2013 03:15 AM, Joseph Lo wrote:
> The common LP1 resuming procedures of LP1 on Tegra was checking the LP1
> mask first. The LP1 mask indicated that the Tegra device was in LP1 then
> we need to resume the Tegra from the LP1 reset handler.
> 
> And the LP1 was putting the SDRAM to self-refresh mode, the SDRAM wasn't
> accessible when resuming from LP1. We need to copy the LP1 reset handler
> to IRAM before suspending. That's why you can see the address of LP1
> reset handler was located in IRAM.

That's rather hard to understand. How about:

==========
Add support to the Tegra CPU reset vector to detect whether the CPU is
resuming from LP1 suspend state. If it is, branch to the LP1-specific
resume code.

When Tegra enters the LP1 suspend state, the SDRAM controller is placed
into a self-refresh state. For this reason, we must place the LP1 resume
code into IRAM, so that it is accessible before SDRAM access has been
re-enabled.
==========

Talking about *copying* the LP1 resume code to IRAM isn't appropriate
here, since nothing in this patch performs any copying of the resume code.

> diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S

> @@ -182,6 +182,19 @@ after_errata:
>  1:
>  #endif
>  
> +	/* Waking up from LP1? */
> +	ldr	r8, [r12, #RESET_DATA(MASK_LP1)]
> +	tst	r8, r11				@ if in_lp1
> +	beq	__is_not_lp1
> +	cmp	r10, #0
> +	bne	__die				@ only CPU0 can be here
> +	ldr	lr, [r12, #RESET_DATA(STARTUP_LP1)]
> + THUMB(	add	lr, lr, #1 )			@ switch to Thumb mode
> +	cmp	lr, #0
> +	bleq	__die				@ no LP1 startup handler

On thumb, lr==#1 at this point. I think you want to move the THUMB()
instruction after the bleq.

> diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h

> +#define TEGRA_IRAM_CODE_AREA	(TEGRA_IRAM_BASE + SZ_4K)

The layout of IRAM should be described in irammap.h not sleep.h.


From tomasz.figa at gmail.com  Mon Jul 29 18:45:24 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Tue, 30 Jul 2013 00:45:24 +0200
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
Message-ID: <1706112.Xn49tiCSKF@thinkpad>

On Monday 29 of July 2013 18:23:30 jonsmirl at gmail.com wrote:
> The schema should enforce some kind of regularity into the description
> of similar devices.  Take SPI for example. I pulled these SPI
> controller definitions from the kernel source. Obviously all of these
> controllers are different, but it seems to me that their definitions
> could be made more regular. DMA seems like it could use a lot of help.

Well, there is not much in common in bindings for all those SPI controllers, 
other than general device attributes, such as compatible and reg (not even 
interrupts - see spi-gpio).

There is a lot of generic binding templates (as I called this kind of bindings 
in my first mail) involved here, though.

Taking one of the controllers as the example:
> spi0: spi at f0000000 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "atmel,at91rm9200-spi";
> reg = <0xf0000000 0x100>;
> interrupts = <13 IRQ_TYPE_LEVEL_HIGH 3>;

/inherit/ "interrupts.dtss", 1;

> dmas = <&dma0 1 AT91_DMA_CFG_PER_ID(1)>,
>       <&dma0 1 AT91_DMA_CFG_PER_ID(2)>;
> dma-names = "tx", "rx";

/inherit/ "dma.dtss", "tx", "rx";

> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_spi0>;

/inherit/ "pinctrl.dtss","default";

> status = "disabled";
> };

Best regards,
Tomasz



From sergei.shtylyov at cogentembedded.com  Mon Jul 29 18:46:23 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 30 Jul 2013 02:46:23 +0400
Subject: [PATCH v2 1/2] ARM: shmobile: r8a7778: add HPB-DMAC support
In-Reply-To: <87a9lacd6o.wl%kuninori.morimoto.gx@renesas.com>
References: <201307230218.01495.sergei.shtylyov@cogentembedded.com>
 <201307230222.04763.sergei.shtylyov@cogentembedded.com>
 <20130726001052.GA28912@verge.net.au>
 <87a9lacd6o.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <51F6F0BF.2030004@cogentembedded.com>

Hello.

On 07/26/2013 05:39 AM, Kuninori Morimoto wrote:

>>> +static const struct hpb_dmae_slave_config hpb_dmae_slaves[] = {
>>> +	{
>>> +		.id	= HPBDMA_SLAVE_SDHI0_TX,
>>> +		.addr	= 0xffe4c000 + 0x30,
>>> +		.dcr	= DCR_SPDS_16BIT | DCR_DMDL | DCR_DPDS_16BIT,
>>> +		.rstr	= ASYNCRSTR_ASRST21 | ASYNCRSTR_ASRST22 |
>>> +			  ASYNCRSTR_ASRST23,
>>> +		.mdr	= ASYNCMDR_ASMD21_SINGLE,
>>> +		.mdm	= ASYNCMDR_ASMD21_MASK,
>>> +		.port	= 0x0D0C,
>>> +		.flags	= HPB_DMAE_SET_ASYNC_RESET | HPB_DMAE_SET_ASYNC_MODE,
>>> +		.dma_ch	= 21,
>>> +	}, {
>>> +		.id	= HPBDMA_SLAVE_SDHI0_RX,
>>> +		.addr	= 0xffe4c000 + 0x30,
>>> +		.dcr	= DCR_SMDL | DCR_SPDS_16BIT | DCR_DPDS_16BIT,
>>> +		.rstr	= ASYNCRSTR_ASRST21 | ASYNCRSTR_ASRST22 |
>>> +			  ASYNCRSTR_ASRST23,
>>> +		.mdr	= ASYNCMDR_ASMD22_SINGLE,
>>> +		.mdm	= ASYNCMDR_ASMD22_MASK,
>>> +		.port	= 0x0D0C,
>>> +		.flags	= HPB_DMAE_SET_ASYNC_RESET | HPB_DMAE_SET_ASYNC_MODE,
>>> +		.dma_ch	= 22,
>>> +	},

> I'm not sure detail of SDHI, but TX and RX are using same .port = 0x0D0C.

    It's not one port, it's a pair of ports, source and destination.

> Is this correct ?
> And what is 0x0C port ?

    SDHI0 if you look into the table 16.7 of the R-Car M1A manual 1.00 for the 
channels 21 thru 23.

> My datasheet doens't have it on Ch21 - Ch23

    Maybe you're looking at the wrong table or an obsolete manual?

>>> +static const struct hpb_dmae_channel hpb_dmae_channels[] = {
>>> +	/* ch. 21 SD0 */
>>> +	HPB_DMAE_CHANNEL(0x7e, HPBDMA_SLAVE_SDHI0_TX),
>>> +	/* ch. 22 SD0 */
>>> +	HPB_DMAE_CHANNEL(0x7e, HPBDMA_SLAVE_SDHI0_RX),
>>> +};
>>> +
>>> +static struct hpb_dmae_pdata dma_platform_data __initdata = {
>>> +	.slaves			= hpb_dmae_slaves,
>>> +	.num_slaves		= ARRAY_SIZE(hpb_dmae_slaves),
>>> +	.channels		= hpb_dmae_channels,
>>> +	.num_channels		= ARRAY_SIZE(hpb_dmae_channels),
>>> +	.ts_shift		= {
>>> +		[XMIT_SZ_8BIT]	= 0,
>>> +		[XMIT_SZ_16BIT]	= 1,
>>> +		[XMIT_SZ_32BIT]	= 2,
>>> +	},
>>> +	.num_hw_channels	= 39,
>>> +};

> This is not a big deal, but according to .num_hw_channels,
> we will have max 39 channels (or more over).

> I want 1 line for 1 channels on hpb_dmae_channels.
> like this

> static const struct hpb_dmae_channel hpb_dmae_channels[] = {
> 	HPB_DMAE_CHANNEL(0x7e, HPBDMA_SLAVE_SDHI0_TX), /* ch21 */
> 	HPB_DMAE_CHANNEL(0x7e, HPBDMA_SLAVE_SDHI0_RX), /* ch22 */
> }

    OK, done.

> Best regards
> ---
> Kuninori Morimoto

WBR, Sergei



From mgr at pengutronix.de  Mon Jul 29 18:47:17 2013
From: mgr at pengutronix.de (Michael Grzeschik)
Date: Tue, 30 Jul 2013 00:47:17 +0200
Subject: [PATCH v13 03/14] usb: chipidea: imx: add return value check
 for devm_regulator_get
In-Reply-To: <1374830310-21765-4-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
 <1374830310-21765-4-git-send-email-peter.chen@freescale.com>
Message-ID: <20130729224717.GB7109@pengutronix.de>

On Fri, Jul 26, 2013 at 05:18:19PM +0800, Peter Chen wrote:
> - If devm_regulator_get returns -EPROBE_DEFER, we also return
> -EPROBE_DEFER to wait regulator being ready later.
> - If devm_regulator_get returns -ENODEV, we think there is
> no "vbus-supply" node at DT, it means this board doesn't need
> vbus control.
> - If devm_regulator_get returns other error values, it means
> there are something wrong for getting this regulator.
> 
> Signed-off-by: Peter Chen <peter.chen at freescale.com>
> ---
>  drivers/usb/chipidea/ci_hdrc_imx.c |   14 ++++++++++++--
>  1 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
> index d06355e..0ced8c1 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -144,8 +144,18 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>  
>  	/* Get the vbus regulator */
>  	pdata.reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
> -	if (IS_ERR(pdata.reg_vbus))
> -		pdata.reg_vbus = NULL;
> +	if (PTR_ERR(pdata.reg_vbus) == -EPROBE_DEFER) {
> +		ret = -EPROBE_DEFER;
> +		goto err_clk;
> +	} else if (PTR_ERR(pdata.reg_vbus) == -ENODEV) {
> +		pdata.reg_vbus = NULL; /* no vbus regualator is needed */
> +	} else if (IS_ERR(pdata.reg_vbus)) {
> +		dev_err(&pdev->dev,
> +				"Getting regulator error: %ld\n",
> +					PTR_ERR(pdata.reg_vbus));
> +		ret = PTR_ERR(pdata.reg_vbus);
> +		goto err_clk;
> +	}
>  
>  	if (!pdev->dev.dma_mask)
>  		pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> -- 

This is wrong, you should squash that into the previous patch. And
as already mentioned, this can probably go into core.c as well.

Pick up the habit *not* to change code in one series which another patch
of the same series introduced. This only adds *dusty* unused history in the
patchstack that nobody needs. A *clean* and *coherent* series with discrete
patches is much easier to review and will get accepted much faster.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From swarren at wwwdotorg.org  Mon Jul 29 18:47:37 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 16:47:37 -0600
Subject: [PATCH 2/8] ARM: tegra: config the polarity of the request of
 sys clock
In-Reply-To: <1374830110-30685-3-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
 <1374830110-30685-3-git-send-email-josephl@nvidia.com>
Message-ID: <51F6F109.8010102@wwwdotorg.org>

On 07/26/2013 03:15 AM, Joseph Lo wrote:
> When suspending to LP1 mode, the SYSCLK will be clock gated. And different
> board may have different polarity of the request of SYSCLK, this patch
> configure the polarity from the DT for the board.

> diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c

> @@ -238,6 +240,20 @@ void tegra_pmc_suspend_init(void)
>  	reg = tegra_pmc_readl(PMC_CTRL);
>  	reg |= TEGRA_POWER_CPU_PWRREQ_OE;
>  	tegra_pmc_writel(reg, PMC_CTRL);
> +
> +	reg = tegra_pmc_readl(PMC_CTRL);
> +
> +	if (!pmc_pm_data.sysclkreq_high)
> +		reg |= TEGRA_POWER_SYSCLK_POLARITY;
> +	else
> +		reg &= ~TEGRA_POWER_SYSCLK_POLARITY;
> +
> +	/* configure the output inverts while the request is tristated */
> +	tegra_pmc_writel(reg, PMC_CTRL);

I think s/inverts/polarity/ in that comment would make a lot more sense.

Must _OE be disabled for the code to work correctly? If so, should the
code explicitly clear _OE first, since who knows what state it was
originally in? Can't we just set the new polarity and enable _OE in a
single register write?

> +	/* now enable the request */
> +	reg |= TEGRA_POWER_SYSCLK_OE;
> +	tegra_pmc_writel(reg, PMC_CTRL);



From jason at lakedaemon.net  Mon Jul 29 18:48:40 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Mon, 29 Jul 2013 18:48:40 -0400
Subject: [Ksummit-2013-discuss] Defining schemas for Device Tree
In-Reply-To: <20130729222920.GF29970@voom.fritz.box>
References: <2469263.vMN09Q7Tzi@flatron>
 <20130729150124.GS29916@titan.lakedaemon.net>
 <20130729164905.GB2280@localhost.localdomain>
 <20130729172339.GT29916@titan.lakedaemon.net>
 <20130729222920.GF29970@voom.fritz.box>
Message-ID: <20130729224840.GZ29916@titan.lakedaemon.net>

On Tue, Jul 30, 2013 at 08:29:20AM +1000, David Gibson wrote:
> On Mon, Jul 29, 2013 at 01:23:39PM -0400, Jason Cooper wrote:
> > On Mon, Jul 29, 2013 at 05:49:05PM +0100, Dave Martin wrote:
> > > On Mon, Jul 29, 2013 at 11:01:24AM -0400, Jason Cooper wrote:
> > > > On Mon, Jul 29, 2013 at 02:21:52AM +0200, Tomasz Figa wrote:
> > 
> > > > > b) What information should be specified in schemas? What level of 
> > > > >    granularity is required?
> > > > 
> > > > One item I don't see in this list is node ordering.  There's been some
> > > > discussion lately on deferred probing (re boot times).  If we were to
> > > > intentionally declare that DT are parsed in the order written, then a
> > > > lot of deferred probes could be avoided by moving eg the pinctrl node to
> > > > near the top of the tree.
> > > > 
> > > > This doesn't impact buses as much, since the nodes needing the bus are
> > > > already children.  However, anything accessed via phandles: pins,
> > > > clocks, regulators, etc could benefit from declaring and enforcing this.
> > > > Eg having the dtc warn when a phandle is used before it's corresponding
> > > > node is declared.
> > > > 
> > > > Not critical though, just a thought.
> > > 
> > > I don't think that siblings have any defined order in DT.  If reading a
> > > device tree, there's no guarantee you get nodes or properties out in the
> > > same order as the original .dts file.
> > 
> > That's why I raised the point.  If people think encoding initialization
> > order in the DT is a good idea, then we should change the dtc so it
> > compiles/decompiles in the same order.
> 
> I've always considered the DT to be unordered, although the flattened
> representation obviously has to have some order.  It is much safer to
> explicitly represent any required orderings with properties, rather
> than to rely on the flattened tree order.  I really don't think trying
> to have dtc magically understand device initialization ordering in
> this way is a good idea.
> 
> Fwiw, dtc generally preserves order between input and output, with the
> exception of the -s option, which sorts the subnodes of each node by
> name (useful for dtdiff).
> 
> > > Provided child/parent relationships are maintained and the set of nodes
> > > and values is the same, I think completely rearranging a .dts file does
> > > not change its meaning.
> > > 
> > > "depends-on" relationships mostly have to come from the semantics of
> > > the bindings themselves: for example, if a device is connected to some
> > > clocks and regulators, the kernel may need to probe those first.
> > 
> > true, the answer to this problem may be to create a depgraph of the
> > nodes based on phandles and child status, then init.  However, if the
> > goal is to accelerate boot times, then that should not be calculated
> > during each boot, especially since it doesn't likely change from boot to
> > boot.
> > 
> > Which means it would either go in the dtc (dts node ordering is
> > irrelevant), or in the dts.  I'm inclined to say dtc should do it, but I
> > like the aesthetics of things being in the proper order in something I
> > can read.  After all, C requires functions to be declared before use,
> > even though the compiler could figure it out.
> 
> It's not necessarily possible to encode device initialization order in
> flattened tree order.  Suppose you have bus A with devices A1 and A2,
> and bus B with devices B1 and B2.  A1 must be initialized before B1,
> but B2 must be initialized before A2.  There are no loops there, it's
> a valid set of initialization order constraints, but you can't get
> both of them right in the flat tree ordering.

True, but is there a real scenario where this is the case?  In any
event, this could still fall back to deferred probing.

As I think about it more, working with only what dtc can definitely see,
eg busses and phandles, some ordering optimization could be done to
reduce the number of probe deferrals.

thx,

Jason.


From swarren at wwwdotorg.org  Mon Jul 29 18:51:53 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 16:51:53 -0600
Subject: [PATCH 3/8] clk: tegra114: add LP1 suspend/resume support
In-Reply-To: <1374830110-30685-4-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
 <1374830110-30685-4-git-send-email-josephl@nvidia.com>
Message-ID: <51F6F209.2090309@wwwdotorg.org>

On 07/26/2013 03:15 AM, Joseph Lo wrote:
> When the system suspends to LP1, the clock of the CPU would be switched to
> CLK_M (12MHz Oscillator) during suspend/resume flow. The clock driver
> needs to restore the clock of CPU after LP1 resume.

It's unclear to me how the code change implements "restore the clock of
the CPU". A register name of CCLKG_BURST_POLICY doesn't sound like it's
anything to do with enabled/disabling the CPU clock, nor configuring its
rate. What exactly does this register do, and hence what does this new
code actually restore?

Why don't Tegra20/30 need a similar change?


From swarren at wwwdotorg.org  Mon Jul 29 19:13:41 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 17:13:41 -0600
Subject: [PATCH 4/8] ARM: tegra: add common LP1 suspend support
In-Reply-To: <1374830110-30685-5-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
 <1374830110-30685-5-git-send-email-josephl@nvidia.com>
Message-ID: <51F6F725.6000106@wwwdotorg.org>

On 07/26/2013 03:15 AM, Joseph Lo wrote:
> The LP1 suspending mode on Tegra means CPU rail off, devices and PLLs are
> clock gated and SDRAM in self-refresh mode. That means the low level LP1
> suspending and resuming code couldn't be run on DRAM and the CPU must
> switch to the always on clock domain (a.k.a. CLK_M 12MHz oscillator). And
> the system clock (SCLK) would be switched to CLK_S, a 32KHz oscillator.
> The LP1 low level handling code need to be moved to IRAM area first. And
> marking the LP1 mask for indicating the Tegra device is in LP1. The CPU
> power timer needs to be re-calculated based on 32KHz that was originally
> based on PCLK.

> diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c

>  #ifdef CONFIG_PM_SLEEP
>  static DEFINE_SPINLOCK(tegra_lp2_lock);
> +static void __iomem *iram_code = IO_ADDRESS(TEGRA_IRAM_CODE_AREA);
> +static u32 iram_save_size;
> +static void *iram_save_addr;
> +struct tegra_lp1_iram *tegra_lp1_iram;
>  void (*tegra_tear_down_cpu)(void);
> +void (*tegra_sleep_core_finish)(unsigned long v2p);

I'm not sure all of those are required to be global variables. For
example, iram_code is just a constant, so you could easily just use it
directly in code.

> @@ -174,14 +180,75 @@ enum tegra_suspend_mode tegra_pm_validate_suspend_mode(
>  				enum tegra_suspend_mode mode)
>  {
>  	/*
> -	 * The Tegra devices only support suspending to LP2 currently.
> +	 * The Tegra devices only support suspending to LP1 currently.

That now says that only LP1 is supported. That's not true; both LP1 and
LP2 are supported. How about s/LP1/LP1 or lower/ or s:LP1:LP1/LP2: ?

> +static bool tegra_sleep_core_init(void)
> +{
> +	if (!tegra_sleep_core_finish)
> +		return false;
> +
> +	return true;
> +}

That function seems a little pointless. Why not just check the value of
tegra_sleep_core_finish directly in tegra_init_suspend()?

> +static void tegra_suspend_enter_lp1(void)
> +{
> +	tegra_pmc_suspend();
> +
> +	/* copy the reset vector & SDRAM shutdown code into IRAM */
> +	memcpy(iram_save_addr, iram_code, iram_save_size);
> +	memcpy(iram_code, tegra_lp1_iram->start_addr, iram_save_size);
> +
> +	*((u32 *)tegra_cpu_lp1_mask) = 1;
> +}
> +
> +static void tegra_suspend_exit_lp1(void)
> +{
> +	tegra_pmc_resume();
> +
> +	/* restore IRAM */
> +	memcpy(iram_code, iram_save_addr, iram_save_size);
> +
> +	*(u32 *)tegra_cpu_lp1_mask = 0;
> +}

I'm not really sure I like that, but I suppose it's OK. It sure seems
like a performance limiter, but I suppose LP1 is so slow it doesn't
matter, due to the need to ramp power rails, PLLs, SDRAM controller, etc.

It'd be nice to simply reserve more IRAM for the kernel's use. Right
now, only 1K is reserved, and presumably the code running on the AVP
can't use the rest of that page anyway, or can it?

> @@ -212,9 +282,15 @@ static int tegra_suspend_enter(suspend_state_t state)
>  		break;
>  	}
>  
> -	cpu_suspend(PHYS_OFFSET - PAGE_OFFSET, &tegra_sleep_cpu);
> +	if (mode == TEGRA_SUSPEND_LP2)
> +		cpu_suspend(PHYS_OFFSET - PAGE_OFFSET, &tegra_sleep_cpu);
> +	else
> +		cpu_suspend(PHYS_OFFSET - PAGE_OFFSET, &tegra_sleep_core);

Nit: It might be slightly simpler to simply calculate the parameter to
cpu_suspend(), but then take the same code-path:

if (mode == TEGRA_SUSPEND_LP2)
	sleep_func = tegra_sleep_cpu;
else
	sleep_func = tegra_sleep_core;
cpu_suspend(PHYS_OFFSET - PAGE_OFFSET, sleep_func);

That way, it's a little more obvious that the code always calls
cpu_suspend() in the same way, but simply passes a different function to
it to power things down at the end.

> diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c

>  void tegra_pmc_pm_set(enum tegra_suspend_mode mode)
>  {
>  	u32 reg, csr_reg;
> -	unsigned long rate = 0;
> +	unsigned long rate = 32768;

That's LP1-specific. You should add a "case TEGRA_SUSPEND_LP1:" to the
switch statement that calculates rate instead; after all, that's the
whole point of having that switch statement.



From jgunthorpe at obsidianresearch.com  Mon Jul 29 19:14:25 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Mon, 29 Jul 2013 17:14:25 -0600
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130729222039.GE29970@voom.fritz.box>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F39FD8.6080808@broadcom.com> <20130727183059.GD4813@netboy>
 <1441731.8CGUI1tUxh@flatron>
 <20130729180513.GB1884@obsidianresearch.com>
 <20130729222039.GE29970@voom.fritz.box>
Message-ID: <20130729231425.GA4439@obsidianresearch.com>

On Tue, Jul 30, 2013 at 08:20:39AM +1000, David Gibson wrote:

> > Clearly general purpose systems (eg servers, workstations, etc) with
> > *full featured firmware* fall into category b. Linux already basically
> > has stable DT for those systems - but the firmware is expected to do
> > lots of work and hide all the low level details from the
> > kernel.  Basically, the DT should stick to approximately ePAR and
> > everything else is hidden by the firmware.
> 
> No.  With the exception of the hypervisor/virtualization extensions,
> ePAPR describes (for now) an entirely passive firmware interface.
> That is, once the handover to the OS has happened, there is *no*
> further firmware interaction.  It is not capable of hiding any details
> from the OS, except those which can be done by one-time
> initialization.

Well, one-time initialization details are actually exactly one of the
areas I am thinking about. Some of the embedded SOCs have extensive
one time initization code in the kernel that is highly SOC specific
and on x86 it would live in the firmware.

But I see what you mean, ePAPR was the wrong reference, I didn't
carefully check it. I ment the kind of DT use we've seen in SPARC,
POWER servers, Apple stuff, etc - systems explicitly designed so that
new hardware will boot old OSs.

Jason


From swarren at wwwdotorg.org  Mon Jul 29 19:45:13 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 17:45:13 -0600
Subject: [PATCH 5/8] ARM: tegra30: add LP1 suspend support
In-Reply-To: <1374830110-30685-6-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
 <1374830110-30685-6-git-send-email-josephl@nvidia.com>
Message-ID: <51F6FE89.4060402@wwwdotorg.org>

On 07/26/2013 03:15 AM, Joseph Lo wrote:
> The LP1 suspend mode will power off the CPU, clock gated the PLLs and put
> SDRAM to self-refresh mode. Any interrupt can wake up device from LP1. The
> sequence when LP1 suspending:

> diff --git a/arch/arm/mach-tegra/pm-tegra30.c b/arch/arm/mach-tegra/pm-tegra30.c

> +void tegra30_lp1_iram_hook(void)
> +{
> +	tegra30_lp1_iram.start_addr = &tegra30_iram_start;
> +	tegra30_lp1_iram.end_addr = &tegra30_iram_end;

If you need to fill in the values in that struct dynamically anyway, why
not make tegra_lp1_iram be a struct rather than a pointer, and write
directly to it?

That said, aren't tegra30_iram_start constants that the linker can work
out, so I think you can just initialize the structure at compile-time,
and save some code.

> +	tegra_lp1_iram = &tegra30_lp1_iram;
> +}
> +
> +void tegra30_sleep_core_init(void)
> +{
> +	tegra_sleep_core_finish = tegra30_sleep_core_finish;
> +}

Is there a need to have separate iram_hook()/sleep_core_init()
functions? Perhaps they can be combined into a single function for
simplicity.

> diff --git a/arch/arm/mach-tegra/pm.h b/arch/arm/mach-tegra/pm.h

> +#ifdef CONFIG_ARCH_TEGRA_3x_SOC
> +void tegra30_lp1_iram_hook(void);
> +void tegra30_sleep_core_init(void);
> +#else
> +static inline void tegra30_lp1_iram_hook(void) {}
> +static inline void void tegra30_sleep_core_init(void) {}
> +#endif

It'd be nice to be consistent re: whether we define dummy static
inlines, or use IS_ENABLED() at the call-site. IIRC, there's lots of use
of IS_ENABLED() in the Tegra PM code now, so perhaps these patches
should use that instead?

> diff --git a/arch/arm/mach-tegra/sleep.h b/arch/arm/mach-tegra/sleep.h

> +/* waits until the microsecond counter (base) ticks, for exact timing loops */
> +.macro wait_for_us, rd, base, tmp
> +	ldr	\rd, [\base]
> +1001:	ldr	\tmp, [\base]
> +	cmp	\rd, \tmp
> +	beq	1001b
> +.endm

Doesn't this wait any amount of time from 0..1uS, and hence it actually
/isn't/ very exact?

> +/* waits until the microsecond counter (base) is > rn */
> +.macro wait_until, rn, base, tmp
> +	add	\rn, \rn, #1
> +1002:	ldr	\tmp, [\base]
> +	cmp	\tmp, \rn
> +	bmi	1002b
> +.endm

Parameter "rn" could be renamed to make its purpose clear from the name.
How about target_us or wait_until_this_time? "wait_until" is also rather
a generic name; wait_until_us would be much better, which would require
renaming wait_until_us above, which I think might be better deleted, or
renamed to wait_until_next_us?

> diff --git a/arch/arm/mach-tegra/sleep-tegra30.S b/arch/arm/mach-tegra/sleep-tegra30.S

> +ENTRY(tegra30_sleep_core_finish)

> +	/*
> +	 * Preload all the address literals that are needed for the
> +	 * CPU power-gating process, to avoid loading from SDRAM which
> +	 * are not supported once SDRAM is put into self-refresh.
> +	 * LP0 / LP1 use physical address, since the MMU needs to be
> +	 * disalbed before putting SDRAM into self-refresh to avoid

s/disalbed/disabled/

> +/*
> + * tegra30_lp1_reset
> + *
> + * reset vector for LP1 restore; copied into IRAM during suspend.
> + * Brings the system back up to a safe staring point (SDRAM out of
> + * self-refresh, PLLC, PLLM and PLLP reenabled, CPU running on PLLX,
> + * system clock running on the same PLL that it suspended at), and
> + * jumps to tegra_resume to restore virtual addressing.
> + * The physical address of tegra_resume expected to be stored in
> + * PMC_SCRATCH41.
> + *
> + * NOTE: THIS *MUST* BE RELOCATED TO TEGRA_IRAM_CODE_AREA AND MUST BE FIRST.

What does "AND MUST BE FIRST" mean?

> +ENTRY(tegra30_lp1_reset)
> +	/*
> +	 * The CPU and system bus are running at 32KHz and executing from
> +	 * IRAM when this code is executed; immediately switch to CLKM and
> +	 * enable PLLP, PLLM, PLLC, PLLA and PLLX.
> +	 */
> +	mov32	r0, TEGRA_CLK_RESET_BASE
> +
> +	mov	r1, #(1 << 28)

Some #defines for the various magic values used in this code would be
useful.

> +tegra30_sdram_pad_save:
> +	.word	0
> +	.word	0
> +	.word	0
> +	.word	0
> +	.word	0
> +	.word	0
> +	.word	0
> +	.word	0

This might be simpler, and easier to validate it's the right length:

        .rept   8
        .long   0
        .endr

> +tegra30_sdram_pad_address:
> +	.word	TEGRA_EMC_BASE + EMC_CFG				@0x0
> +	.word	TEGRA_EMC_BASE + EMC_ZCAL_INTERVAL			@0x4
> +	.word	TEGRA_EMC_BASE + EMC_AUTO_CAL_INTERVAL			@0x8
> +	.word	TEGRA_EMC_BASE + EMC_XM2VTTGENPADCTRL			@0xc
> +	.word	TEGRA_EMC_BASE + EMC_XM2VTTGENPADCTRL2			@0x10
> +	.word	TEGRA_PMC_BASE + PMC_IO_DPD_STATUS			@0x14
> +	.word	TEGRA_CLK_RESET_BASE + CLK_RESET_CLK_SOURCE_MSELECT	@0x18
> +	.word	TEGRA_CLK_RESET_BASE + CLK_RESET_SCLK_BURST		@0x1c
> +
> +tegra30_sdram_pad_size:
> +	.word	tegra30_sdram_pad_address - tegra30_sdram_pad_save

Perhaps if you swapp the order of declaring tegra30_sdram_pad_save and
tegra30_sdram_pad_address, you can even do something like:

	.rept (tegra30_sdram_pad_addr_end - tegra30_sdram_pad_addr) / 4

?

> +tegra30_switch_cpu_to_clk32k:
> +	/*
> +	 * start by jumping to CLKM to safely disable PLLs, then jump to

jumping sounds like a CPU program counter operation.
s/jumping/switching/ ?

> +	/* 2uS delay delay between changing SCLK and CCLK */
> +	wait_for_us r1, r7, r9
> +	add	r1, r1, #2
> +	wait_until r1, r7, r9

Ah, I see how wait_for_us is used now. Perhaps rename it
wait_for_us_boundary or wait_for_us_tick? Alternatively, perhaps
wait_until can just incorporate that logic itself?


From david at gibson.dropbear.id.au  Mon Jul 29 19:45:32 2013
From: david at gibson.dropbear.id.au (David Gibson)
Date: Tue, 30 Jul 2013 09:45:32 +1000
Subject: [Ksummit-2013-discuss] Defining schemas for Device Tree
In-Reply-To: <20130729224840.GZ29916@titan.lakedaemon.net>
References: <2469263.vMN09Q7Tzi@flatron>
 <20130729150124.GS29916@titan.lakedaemon.net>
 <20130729164905.GB2280@localhost.localdomain>
 <20130729172339.GT29916@titan.lakedaemon.net>
 <20130729222920.GF29970@voom.fritz.box>
 <20130729224840.GZ29916@titan.lakedaemon.net>
Message-ID: <20130729234532.GH29970@voom.fritz.box>

On Mon, Jul 29, 2013 at 06:48:40PM -0400, Jason Cooper wrote:
> On Tue, Jul 30, 2013 at 08:29:20AM +1000, David Gibson wrote:
> > On Mon, Jul 29, 2013 at 01:23:39PM -0400, Jason Cooper wrote:
> > > On Mon, Jul 29, 2013 at 05:49:05PM +0100, Dave Martin wrote:
> > > > On Mon, Jul 29, 2013 at 11:01:24AM -0400, Jason Cooper wrote:
> > > > > On Mon, Jul 29, 2013 at 02:21:52AM +0200, Tomasz Figa wrote:
> > > 
> > > > > > b) What information should be specified in schemas? What level of 
> > > > > >    granularity is required?
> > > > > 
> > > > > One item I don't see in this list is node ordering.  There's been some
> > > > > discussion lately on deferred probing (re boot times).  If we were to
> > > > > intentionally declare that DT are parsed in the order written, then a
> > > > > lot of deferred probes could be avoided by moving eg the pinctrl node to
> > > > > near the top of the tree.
> > > > > 
> > > > > This doesn't impact buses as much, since the nodes needing the bus are
> > > > > already children.  However, anything accessed via phandles: pins,
> > > > > clocks, regulators, etc could benefit from declaring and enforcing this.
> > > > > Eg having the dtc warn when a phandle is used before it's corresponding
> > > > > node is declared.
> > > > > 
> > > > > Not critical though, just a thought.
> > > > 
> > > > I don't think that siblings have any defined order in DT.  If reading a
> > > > device tree, there's no guarantee you get nodes or properties out in the
> > > > same order as the original .dts file.
> > > 
> > > That's why I raised the point.  If people think encoding initialization
> > > order in the DT is a good idea, then we should change the dtc so it
> > > compiles/decompiles in the same order.
> > 
> > I've always considered the DT to be unordered, although the flattened
> > representation obviously has to have some order.  It is much safer to
> > explicitly represent any required orderings with properties, rather
> > than to rely on the flattened tree order.  I really don't think trying
> > to have dtc magically understand device initialization ordering in
> > this way is a good idea.
> > 
> > Fwiw, dtc generally preserves order between input and output, with the
> > exception of the -s option, which sorts the subnodes of each node by
> > name (useful for dtdiff).
> > 
> > > > Provided child/parent relationships are maintained and the set of nodes
> > > > and values is the same, I think completely rearranging a .dts file does
> > > > not change its meaning.
> > > > 
> > > > "depends-on" relationships mostly have to come from the semantics of
> > > > the bindings themselves: for example, if a device is connected to some
> > > > clocks and regulators, the kernel may need to probe those first.
> > > 
> > > true, the answer to this problem may be to create a depgraph of the
> > > nodes based on phandles and child status, then init.  However, if the
> > > goal is to accelerate boot times, then that should not be calculated
> > > during each boot, especially since it doesn't likely change from boot to
> > > boot.
> > > 
> > > Which means it would either go in the dtc (dts node ordering is
> > > irrelevant), or in the dts.  I'm inclined to say dtc should do it, but I
> > > like the aesthetics of things being in the proper order in something I
> > > can read.  After all, C requires functions to be declared before use,
> > > even though the compiler could figure it out.
> > 
> > It's not necessarily possible to encode device initialization order in
> > flattened tree order.  Suppose you have bus A with devices A1 and A2,
> > and bus B with devices B1 and B2.  A1 must be initialized before B1,
> > but B2 must be initialized before A2.  There are no loops there, it's
> > a valid set of initialization order constraints, but you can't get
> > both of them right in the flat tree ordering.
> 
> True, but is there a real scenario where this is the case?  In any
> event, this could still fall back to deferred probing.

I never count on weird and wonderful arrangements _not_ appearing in
embedded.

But, in regards to falling back do deferred probing.  If you're
thinking of the fdt ordering as purely an optimization, rather than
_required_ to get device init correct, then that's a very different
matter.  I have no problem with optimizing the ordering, as long as
its expected that the kernel will still be correct with arbitrary
ordering.

> As I think about it more, working with only what dtc can definitely see,
> eg busses and phandles, some ordering optimization could be done to
> reduce the number of probe deferrals.

Well.  It depends what you mean here.  To do this fully would require
dtc to interpret properties much more than it currently does - in
nearly all cases it treats them as opaque blobs, whereas many
different kinds of properties can potentially include phandles, and
you have to know how to parse them to discover them.

On the other hand, if what you're referring to is dtc's &-syntax for
phandle references, then I guess we could topsort on that.  As long as
we bear in mind that that can miss cases, if people hand craft their
phandles, instead of using references.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130730/04bf655e/attachment.sig>

From david at gibson.dropbear.id.au  Mon Jul 29 19:49:22 2013
From: david at gibson.dropbear.id.au (David Gibson)
Date: Tue, 30 Jul 2013 09:49:22 +1000
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130729231425.GA4439@obsidianresearch.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F39FD8.6080808@broadcom.com> <20130727183059.GD4813@netboy>
 <1441731.8CGUI1tUxh@flatron>
 <20130729180513.GB1884@obsidianresearch.com>
 <20130729222039.GE29970@voom.fritz.box>
 <20130729231425.GA4439@obsidianresearch.com>
Message-ID: <20130729234922.GI29970@voom.fritz.box>

On Mon, Jul 29, 2013 at 05:14:25PM -0600, Jason Gunthorpe wrote:
> On Tue, Jul 30, 2013 at 08:20:39AM +1000, David Gibson wrote:
> 
> > > Clearly general purpose systems (eg servers, workstations, etc) with
> > > *full featured firmware* fall into category b. Linux already basically
> > > has stable DT for those systems - but the firmware is expected to do
> > > lots of work and hide all the low level details from the
> > > kernel.  Basically, the DT should stick to approximately ePAR and
> > > everything else is hidden by the firmware.
> > 
> > No.  With the exception of the hypervisor/virtualization extensions,
> > ePAPR describes (for now) an entirely passive firmware interface.
> > That is, once the handover to the OS has happened, there is *no*
> > further firmware interaction.  It is not capable of hiding any details
> > from the OS, except those which can be done by one-time
> > initialization.
> 
> Well, one-time initialization details are actually exactly one of the
> areas I am thinking about. Some of the embedded SOCs have extensive
> one time initization code in the kernel that is highly SOC specific
> and on x86 it would live in the firmware.
> 
> But I see what you mean, ePAPR was the wrong reference, I didn't
> carefully check it. I ment the kind of DT use we've seen in SPARC,
> POWER servers, Apple stuff, etc - systems explicitly designed so that
> new hardware will boot old OSs.

Yeah, and at least for POWER servers and Apples, like every other
attempt at this, ever, it at best sorta-kinda worked.  It's not *as*
bad as the mess of broken BIOSes on x86 (mostly due to smaller
variety), but there's still plenty of broken crap in Apple workstation
and IBM server firmwares and device trees.

You see a clear line between "full featured" and "minimal" firmwares
where none exists.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130730/8890d07e/attachment.sig>

From swarren at wwwdotorg.org  Mon Jul 29 19:53:35 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 17:53:35 -0600
Subject: [PATCH 7/8] ARM: tegra114: add LP1 suspend support
In-Reply-To: <1374830110-30685-8-git-send-email-josephl@nvidia.com>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
 <1374830110-30685-8-git-send-email-josephl@nvidia.com>
Message-ID: <51F7007F.6090200@wwwdotorg.org>

On 07/26/2013 03:15 AM, Joseph Lo wrote:
> The LP1 suspend mode will power off the CPU, clock gated the PLLs and put
> SDRAM to self-refresh mode. Any interrupt can wake up device from LP1. The
> sequence when LP1 suspending:

> diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
> index 5ae7ee5..36cadaa 100644
> --- a/arch/arm/mach-tegra/pm.c
> +++ b/arch/arm/mach-tegra/pm.c
> @@ -214,6 +214,7 @@ static bool tegra_lp1_iram_hook(void)
>  		tegra20_lp1_iram_hook();
>  		break;
>  	case TEGRA30:
> +	case TEGRA114:
>  		tegra30_lp1_iram_hook();

That's in pm-tegra30.c, which is only compiled in if
CONFIG_ARCH_TEGRA_3x_SOC is enabled. Similarly, this patch adds a lot of
code to sleep-tegra30.S, which also isn't built/linked if
!CONFIG_ARCH_TEGRA_3x_SOC.

Does this series built with all 7 combinations of Tegra20/30/114 support
enabled?

> diff --git a/arch/arm/mach-tegra/sleep-tegra30.S b/arch/arm/mach-tegra/sleep-tegra30.S

> @@ -96,9 +100,15 @@
>  	orreq	\rd, \rd, #(1 << 30)
>  	streq	\rd, [\r_car_base, #\pll_base]
>  	/* Enable lock detector */
> +	.if	\pll_misc
> +	ldr	\rd, [\r_car_base, #\pll_misc]
> +	bic	\rd, \rd, #(1 << 18)
> +	str	\rd, [\r_car_base, #\pll_misc]
> +	ldr	\rd, [\r_car_base, #\pll_misc]
>  	ldr	\rd, [\r_car_base, #\pll_misc]
>  	orr	\rd, \rd, #(1 << 18)
>  	str	\rd, [\r_car_base, #\pll_misc]
> +	.endif

Hmm. Those last 3 lines that aren't touched by this patch already
touched the pll_misc register even if !pll_misc. Was that a bug in a
previous patch?

Is git bisect maintained for both compile and run-time across this whole
patch series?


From swarren at wwwdotorg.org  Mon Jul 29 20:02:00 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Mon, 29 Jul 2013 18:02:00 -0600
Subject: Defining schemas for Device Tree
In-Reply-To: <6809706.cRofzbG9CV@thinkpad>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <6809706.cRofzbG9CV@thinkpad>
Message-ID: <51F70278.1020002@wwwdotorg.org>

On 07/29/2013 04:20 PM, Tomasz Figa wrote:
> On Monday 29 of July 2013 15:47:55 Stephen Warren wrote:
>> On 07/28/2013 06:21 PM, Tomasz Figa wrote:

...
>> Other content restrictions might be:
>>
>> * List must contain (at least) these entries/values.
>>
>> * List can't contain any other entries/values not specified here.
>>
>> * List must be in this order vs. any order.
>>
>> * List logical length (in entries, not bytes/cells) must match the
>> logical length of another cell (consider clocks/clock-names).
>>
>> * Ordering of one property must match ordering of another property
>> (again consider clocks/clock-names), although it'd be difficult to tell
>> whether this condition was met, perhaps we can at least document it.
>>
>> I'm sure there will be many more criteria to validate that we're
>> forgetting. This is possible the most complex area?
> 
> Right. Still, this is about the granularity of checks we really need. Do we 
> need to check for all those restrictions?

I think all/most of those bullets actually exist in various binding
documents, and I think we want any schema to be able to represent any
restrictions we already impose. So, yes, I do think we want to be able
to validate all of that.

Now, that's not saying that a system which didn't validate that, but
perhaps only validated that certain properties were present, and no
other properties were present. However, I'd still hope that such a
system was just a first step towards the complete system.

>>> As for subnodes, I think we need to define following constraints:
>>>  - node name (or node name format, e.g. regex),
>>
>> I don't think node names are supposed to convey any semantic meaning, so
>> they probably shouldn't be restricted (much?) by schema.
> 
> There are bindings currently that require specific node names. Since 
> of_match_node() can do matching by names as well, I think we should care about 
> node names too,

Hopefully we can discourage this through review though, since I've
definitely been told not to semantically interpret node names.

...
>> Equally, I'm not sure there's any difference between:
>>
>> prop = <&node>;
>> prop = <0x23648689>;
>>
>> ... in the DTB, except that the value just *happens* to match another
>> node's phandle value, which could end up leading to false positive
>> matches if only applied on the raw values not the syntax?
> 
> This is a good point. From driver's perspective it doesn't matter how you 
> specify value of some property, as long as it can be parsed using the same 
> code. As a more trivial example, consider following dts code:
> 
> 	array-prop = <0>, <1>, <2>;
> 	array-prop-2 = <0 1 2>;
> 
> Both array props contain the same data and can be parsed using the same code, 
> but from reader's perspective they mean something slightly different - an array 
> with 1 cell per element and a single entry of 3 cells.

I can certainly understand those two pieces of syntax being interpreted
that way. I've always thought of the above being 100% equivalent, even
though there may be a logical distinction. I not sure that such a
distinction is actually present in all extant DT source files. Perhaps
it's fine as part of the schema effort to re-write the DTs along these
lines though.


From soren.brinkmann at xilinx.com  Mon Jul 29 20:03:15 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Mon, 29 Jul 2013 17:03:15 -0700
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <51F66565.7010600@linaro.org>
References: <20130717210417.GP13667@xsjandreislx>
 <51E72DCA.9070500@codeaurora.org>
 <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
Message-ID: <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>

Hi Daniel,

On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
(snip)
> 
> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
> timer will be stopped when entering to the idle state. In this case, the
> cpuidle framework will call clockevents_notify(ENTER) and switches to a
> broadcast timer and will call clockevents_notify(EXIT) when exiting the
> idle state, switching the local timer back in use.

I've been thinking about this, trying to understand how this makes my
boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
would make the timer core switch to a broadcast device even though it
wouldn't be necessary. But shouldn't it still work? It sounds like we do
something useless, but nothing wrong in a sense that it should result in
breakage. I guess I'm missing something obvious. This timer system will
always remain a mystery to me.

Actually this more or less leads to the question: What is this
'broadcast timer'. I guess that is some clockevent device which is
common to all cores? (that would be the cadence_ttc for Zynq). Is the
hang pointing to some issue with that driver?

	Thanks,
	S?ren




From jonsmirl at gmail.com  Mon Jul 29 20:30:29 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Mon, 29 Jul 2013 20:30:29 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <1706112.Xn49tiCSKF@thinkpad>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
Message-ID: <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>

On Mon, Jul 29, 2013 at 6:45 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> On Monday 29 of July 2013 18:23:30 jonsmirl at gmail.com wrote:
>> The schema should enforce some kind of regularity into the description
>> of similar devices.  Take SPI for example. I pulled these SPI
>> controller definitions from the kernel source. Obviously all of these
>> controllers are different, but it seems to me that their definitions
>> could be made more regular. DMA seems like it could use a lot of help.
>
> Well, there is not much in common in bindings for all those SPI controllers,
> other than general device attributes, such as compatible and reg (not even
> interrupts - see spi-gpio).

I went and read a little about some of those SPI controllers. I
suspect everyone of these controllers could be mapped into a common
SPI controller schema.

Things like:
num-cs
ti,spi-num-cs

should have the same name.
The description of hardware SPI CS vs GPIOs being used for CS could be
unified too.

This...
tx-dma-channel = <&pdma0 7>; /* preliminary */
rx-dma-channel = <&pdma0 6>; /* preliminary */

Probably should be
dmas = <&pdma0 7>,<&pdma0 6>;
dma-names = "tx", "rx";

With a generic schema as a guide all of these controllers can be
described using the same syntax.

>
> There is a lot of generic binding templates (as I called this kind of bindings
> in my first mail) involved here, though.
>
> Taking one of the controllers as the example:
>> spi0: spi at f0000000 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> compatible = "atmel,at91rm9200-spi";
>> reg = <0xf0000000 0x100>;
>> interrupts = <13 IRQ_TYPE_LEVEL_HIGH 3>;
>
> /inherit/ "interrupts.dtss", 1;
>
>> dmas = <&dma0 1 AT91_DMA_CFG_PER_ID(1)>,
>>       <&dma0 1 AT91_DMA_CFG_PER_ID(2)>;
>> dma-names = "tx", "rx";
>
> /inherit/ "dma.dtss", "tx", "rx";
>
>> pinctrl-names = "default";
>> pinctrl-0 = <&pinctrl_spi0>;
>
> /inherit/ "pinctrl.dtss","default";
>
>> status = "disabled";
>> };
>
> Best regards,
> Tomasz
>



-- 
Jon Smirl
jonsmirl at gmail.com


From kuninori.morimoto.gx at renesas.com  Mon Jul 29 20:30:21 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Tue, 30 Jul 2013 09:30:21 +0900
Subject: [PATCH v2 1/2] ARM: shmobile: r8a7778: add HPB-DMAC support
In-Reply-To: <51F6F0BF.2030004@cogentembedded.com>
References: <201307230218.01495.sergei.shtylyov@cogentembedded.com>
 <201307230222.04763.sergei.shtylyov@cogentembedded.com>
 <20130726001052.GA28912@verge.net.au>
 <87a9lacd6o.wl%kuninori.morimoto.gx@renesas.com>
 <51F6F0BF.2030004@cogentembedded.com>
Message-ID: <uzjt499eq.wl%kuninori.morimoto.gx@renesas.com>


Hi Sergei

> > Is this correct ?
> > And what is 0x0C port ?
> 
>     SDHI0 if you look into the table 16.7 of the R-Car M1A manual 1.00 for the 
> channels 21 thru 23.

Ahh... yes, indeed
sorry for my noise

> > I want 1 line for 1 channels on hpb_dmae_channels.
> > like this
> 
> > static const struct hpb_dmae_channel hpb_dmae_channels[] = {
> > 	HPB_DMAE_CHANNEL(0x7e, HPBDMA_SLAVE_SDHI0_TX), /* ch21 */
> > 	HPB_DMAE_CHANNEL(0x7e, HPBDMA_SLAVE_SDHI0_RX), /* ch22 */
> > }
> 
>     OK, done.

Thank you


From david at lang.hm  Mon Jul 29 20:41:11 2013
From: david at lang.hm (David Lang)
Date: Mon, 29 Jul 2013 17:41:11 -0700 (PDT)
Subject: [Ksummit-2013-discuss] Defining schemas for Device Tree
In-Reply-To: <20130729172339.GT29916@titan.lakedaemon.net>
References: <2469263.vMN09Q7Tzi@flatron>
 <20130729150124.GS29916@titan.lakedaemon.net>
 <20130729164905.GB2280@localhost.localdomain>
 <20130729172339.GT29916@titan.lakedaemon.net>
Message-ID: <alpine.DEB.2.02.1307291739150.13736@nftneq.ynat.uz>

On Mon, 29 Jul 2013, Jason Cooper wrote:

> 
>>
>> I don't think that siblings have any defined order in DT.  If reading a
>> device tree, there's no guarantee you get nodes or properties out in the
>> same order as the original .dts file.
>
> That's why I raised the point.  If people think encoding initialization
> order in the DT is a good idea, then we should change the dtc so it
> compiles/decompiles in the same order.

if you make the initializaiton order 'magicly' correct by following the order of 
the flat representation, how do you reflect the case where initialization can be 
overlapped for different devices?

you are just trading one side of the problem for the other.

David Lang


From jonsmirl at gmail.com  Mon Jul 29 20:49:31 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Mon, 29 Jul 2013 20:49:31 -0400
Subject: [Ksummit-2013-discuss] Defining schemas for Device Tree
In-Reply-To: <alpine.DEB.2.02.1307291739150.13736@nftneq.ynat.uz>
References: <2469263.vMN09Q7Tzi@flatron>
 <20130729150124.GS29916@titan.lakedaemon.net>
 <20130729164905.GB2280@localhost.localdomain>
 <20130729172339.GT29916@titan.lakedaemon.net>
 <alpine.DEB.2.02.1307291739150.13736@nftneq.ynat.uz>
Message-ID: <CAKON4Ow2KMC_9xod3Ay51Yetg9RbfMxVcy4DH0A3baHpmxP+7A@mail.gmail.com>

On Mon, Jul 29, 2013 at 8:41 PM, David Lang <david at lang.hm> wrote:
> On Mon, 29 Jul 2013, Jason Cooper wrote:
>
>>
>>>
>>> I don't think that siblings have any defined order in DT.  If reading a
>>> device tree, there's no guarantee you get nodes or properties out in the
>>> same order as the original .dts file.
>>
>>
>> That's why I raised the point.  If people think encoding initialization
>> order in the DT is a good idea, then we should change the dtc so it
>> compiles/decompiles in the same order.
>
>
> if you make the initializaiton order 'magicly' correct by following the
> order of the flat representation, how do you reflect the case where
> initialization can be overlapped for different devices?

I agree with David, using DT to try and eliminate deferred probes
isn't a good solution.  Overlapped probes and doing probes on multiple
CPUs introduces a temporal angle to the problem. Best to just let the
deferred probing code dynamically solve the problem. From what I can
see the deferred probing solution is working out nicely.

Plus there isn't that much code being run in deferred probing. I
suspect potential savings (if there even is any) are under a
millisecond.

>
> you are just trading one side of the problem for the other.
>
> David Lang



-- 
Jon Smirl
jonsmirl at gmail.com


From peter.chen at freescale.com  Mon Jul 29 21:46:17 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Tue, 30 Jul 2013 09:46:17 +0800
Subject: [PATCH v13 02/14] usb: chipidea: imx: remove vbus regulator
 operation
In-Reply-To: <20130729223025.GA7109@pengutronix.de>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
 <1374830310-21765-3-git-send-email-peter.chen@freescale.com>
 <20130729223025.GA7109@pengutronix.de>
Message-ID: <20130730014616.GD27709@nchen-desktop>

On Tue, Jul 30, 2013 at 12:30:25AM +0200, Michael Grzeschik wrote:
> Hi Peter,
> 
> On Fri, Jul 26, 2013 at 05:18:18PM +0800, Peter Chen wrote:
> > Since we have added vbus reguatlor operation at common
> > host file (chipidea/host.c), the glue layer vbus operation
> > isn't needed any more.
> > 
> > Tested-by: Marek Vasut <marex at denx.de>
> > Signed-off-by: Peter Chen <peter.chen at freescale.com>
> > ---
> >  drivers/usb/chipidea/ci_hdrc_imx.c |   30 +++++++-----------------------
> >  1 files changed, 7 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
> > index 14362c0..d06355e 100644
> > --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> > @@ -31,7 +31,6 @@ struct ci_hdrc_imx_data {
> >  	struct usb_phy *phy;
> >  	struct platform_device *ci_pdev;
> >  	struct clk *clk;
> > -	struct regulator *reg_vbus;
> >  };
> >  
> >  static const struct usbmisc_ops *usbmisc_ops;
> > @@ -141,22 +140,13 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
> >  		goto err_clk;
> >  	}
> >  
> > -	/* we only support host now, so enable vbus here */
> > -	data->reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
> > -	if (!IS_ERR(data->reg_vbus)) {
> > -		ret = regulator_enable(data->reg_vbus);
> > -		if (ret) {
> > -			dev_err(&pdev->dev,
> > -				"Failed to enable vbus regulator, err=%d\n",
> > -				ret);
> > -			goto err_clk;
> > -		}
> > -	} else {
> > -		data->reg_vbus = NULL;
> > -	}
> > -
> >  	pdata.phy = data->phy;
> >  
> > +	/* Get the vbus regulator */
> > +	pdata.reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
> > +	if (IS_ERR(pdata.reg_vbus))
> > +		pdata.reg_vbus = NULL;
> > +
> 
> This hunk needs the reg_vbus variable from the previous patch, therefor
> it should also be added in that patch. As the user of the variable is
> the previous patch, it's the reason to swap their order.
> 

The [1/14] implements the vbus operation at common code (host.c)
This one [2/14] implements how the glue layer get the vbus.

I am OK to swap above two, but I still can't see obvious reason.

> Anyway, can't this be done in core.c instead? I don't see why other
> users don't need this code.
> 

We still not implement DT support at core.c, it is a big job, this
is the main reason, besides, Alex prefers platform things at
glue layer.
-- 

Best Regards,
Peter Chen



From david at gibson.dropbear.id.au  Mon Jul 29 21:44:53 2013
From: david at gibson.dropbear.id.au (David Gibson)
Date: Tue, 30 Jul 2013 11:44:53 +1000
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <1374988276.1973.29.camel@dabdike>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
 <2460092.aLmjrOVh1g@flatron> <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
 <CACxGe6uE6jOE-vz0onW5h93Es-soGiBAcFBM7Dvxh+HvCNrHkw@mail.gmail.com>
 <CACxGe6vw9=y5a+EgF1gO39SwGAdGofD2MYjyJ3jYu6uN3ke70A@mail.gmail.com>
 <1374988276.1973.29.camel@dabdike>
Message-ID: <20130730014453.GJ29970@voom.fritz.box>

On Sat, Jul 27, 2013 at 10:11:16PM -0700, James Bottomley wrote:
> On Sat, 2013-07-27 at 21:28 -0600, Grant Likely wrote:
> > On Sat, Jul 27, 2013 at 2:25 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
> > > On Sat, Jul 27, 2013 at 2:01 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
> > >> On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
> > >>> On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel <arend at broadcom.com> wrote:
> > >>>> Let's see how many people go and scream if I say this: Too bad .dts files
> > >>>> are not done using XML format as DT bindings could be described using XML
> > >>>> Schema.
> > >>>
> > >>> Draft an example and show us how it would look!  :-)  There is
> > >>> absolutely nothing preventing us from expressing a DT in XML format,
> > >>> or even using XSLT to define DT schema while still using our current
> > >>> .dts syntax. It would be trivial to do lossless translation between
> > >>> .dts syntax and xml.
> > >>>
> > >>> The problem that I have with XML and XSLT is that it is very verbose
> > >>> and not entirely friendly to mere-mortals. However, I'm more than
> > >>> willing to be proved wrong on this point.
> > >>
> > >> I considered this approach a while ago and discarded it. It would work
> > >> but it is just too much of a Frankenstein monster.
> > >>
> > >> Much cleaner to modify dtc to take a schema as part of the compilation
> > >> process. The schema language itself has no requirement to look like
> > >> DTS syntax. Whoever wrote dtc probably has a favorite language that
> > >> would be good for writing schemas in.
> > >
> > > Making it part of dtc is a required feature as far as I'm concerned.
> > > Using XML/XSLT and dtc-integration are not mutually exclusive, but I
> > > digress.
> > 
> > Oops, ignore the XSLT bit. XSLT isn't schema and has no bearing on the
> > discussion of schema. Sorry for the noise.
> 
> XSLT is a transform language ... you'd use it say to transform xml to
> dtc, so it would be an integral component of an xml/xslt based schema.
> 
> If you want actually to describe and have validated the xml schema
> itself, then you'd use xsd (XML schema description language) and its
> associated tools.
> 
> I'm not saying you *should* do this, just that it's possible (plus I've
> just blown my kernel cred by knowing about xml, sigh).

Heh.  So, it was said in jest, but that actually raises an important
point.

There are basically two criteria to keep in mind for our
representation of schemas:
   1) Adequate expressiveness to validate a sufficiently large part,
of a sufficiently large number of bindings to be useful.
   2) Ease of use and ease of learning **for the target audience**.

To the best of my knowledge xsd would do well on (1), but I'm not
convinced it does very well on (2).  In an environment where XML was
already widely used, XSD would make perfect sense.  Here, I think it
would be pretty ugly to wire onto the existing DT tools and
infrastructure, and unpleasantly unfamiliar for many kernel and board
developers trying to work with DT schemas.


So, by way of investigation, let me propose an alternative expression
of schemas, that I'm also not convinced we should do, but is possible
and expressive.  It's illustrative, because it's kind of the polar
opposite approach to XSD: just use C.

dtc already has a (so far limited) "checks" mechanism which verifies
various aspects of DT content.  These are implemented by C functions
in checks.c.  There's obviously ample expressiveness - you can express
any constraint you want that way.  It can be pretty verbose, and
fiddly.  A good library of helper functions can mitigate that, but
it's not clear how much.  On the other hand, a very good fraction of
people working with this will already be familiar with C, which is a
big plus.  This is, after all, the reason that the dts syntax is
chiefly C inspired.

Now, in practice, I think we will want a more convenient schema
language (just as we wanted dts, rather than manually constructing
FDTs as C structures).  But I absolutely do think, that the schema
handling should be handled as plugins to the checks mechanism -
basically we'd have a validate_schemas() check function.

I also think we should consider the option of having a simple and
straightforward schema language which handles, say, 80% of cases with
a fall back to C for the 20% of curly cases.  That might actually be
simpler to work with in practice than a schema language which can
express absolutely anything, at the cost of being awkward for simple
cases or difficult to get your head around.

Remember, a schema language is only a win if it is - for the target
audience - more convenient to express schemas in than C.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130730/508642a1/attachment.sig>

From peter.chen at freescale.com  Mon Jul 29 21:50:58 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Tue, 30 Jul 2013 09:50:58 +0800
Subject: [PATCH v13 03/14] usb: chipidea: imx: add return value check
 for devm_regulator_get
In-Reply-To: <20130729224717.GB7109@pengutronix.de>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
 <1374830310-21765-4-git-send-email-peter.chen@freescale.com>
 <20130729224717.GB7109@pengutronix.de>
Message-ID: <20130730015057.GE27709@nchen-desktop>

On Tue, Jul 30, 2013 at 12:47:17AM +0200, Michael Grzeschik wrote:
> On Fri, Jul 26, 2013 at 05:18:19PM +0800, Peter Chen wrote:
> > - If devm_regulator_get returns -EPROBE_DEFER, we also return
> > -EPROBE_DEFER to wait regulator being ready later.
> > - If devm_regulator_get returns -ENODEV, we think there is
> > no "vbus-supply" node at DT, it means this board doesn't need
> > vbus control.
> > - If devm_regulator_get returns other error values, it means
> > there are something wrong for getting this regulator.
> > 
> > Signed-off-by: Peter Chen <peter.chen at freescale.com>
> > ---
> >  drivers/usb/chipidea/ci_hdrc_imx.c |   14 ++++++++++++--
> >  1 files changed, 12 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
> > index d06355e..0ced8c1 100644
> > --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> > @@ -144,8 +144,18 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
> >  
> >  	/* Get the vbus regulator */
> >  	pdata.reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
> > -	if (IS_ERR(pdata.reg_vbus))
> > -		pdata.reg_vbus = NULL;
> > +	if (PTR_ERR(pdata.reg_vbus) == -EPROBE_DEFER) {
> > +		ret = -EPROBE_DEFER;
> > +		goto err_clk;
> > +	} else if (PTR_ERR(pdata.reg_vbus) == -ENODEV) {
> > +		pdata.reg_vbus = NULL; /* no vbus regualator is needed */
> > +	} else if (IS_ERR(pdata.reg_vbus)) {
> > +		dev_err(&pdev->dev,
> > +				"Getting regulator error: %ld\n",
> > +					PTR_ERR(pdata.reg_vbus));
> > +		ret = PTR_ERR(pdata.reg_vbus);
> > +		goto err_clk;
> > +	}
> >  
> >  	if (!pdev->dev.dma_mask)
> >  		pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> > -- 
> 
> This is wrong, you should squash that into the previous patch. And
> as already mentioned, this can probably go into core.c as well.
> 
> Pick up the habit *not* to change code in one series which another patch
> of the same series introduced. This only adds *dusty* unused history in the
> patchstack that nobody needs. A *clean* and *coherent* series with discrete
> patches is much easier to review and will get accepted much faster.
> 

My rule is do ONE thing at ONE patch, is it not correct?

Previous one[2/14]: Remove the vbus operation at imx glue layer.
This one [3/14]: Fix a bug that vbus may be gotten delay (EPROBE_DEFER),
and vbus is valid at this case.

-- 

Best Regards,
Peter Chen



From david at gibson.dropbear.id.au  Mon Jul 29 21:50:31 2013
From: david at gibson.dropbear.id.au (David Gibson)
Date: Tue, 30 Jul 2013 11:50:31 +1000
Subject: [Ksummit-2013-discuss] Defining schemas for Device Tree
In-Reply-To: <20130729172339.GT29916@titan.lakedaemon.net>
References: <2469263.vMN09Q7Tzi@flatron>
 <20130729150124.GS29916@titan.lakedaemon.net>
 <20130729164905.GB2280@localhost.localdomain>
 <20130729172339.GT29916@titan.lakedaemon.net>
Message-ID: <20130730015031.GK29970@voom.fritz.box>

On Mon, Jul 29, 2013 at 01:23:39PM -0400, Jason Cooper wrote:
> On Mon, Jul 29, 2013 at 05:49:05PM +0100, Dave Martin wrote:
> > On Mon, Jul 29, 2013 at 11:01:24AM -0400, Jason Cooper wrote:
> > > On Mon, Jul 29, 2013 at 02:21:52AM +0200, Tomasz Figa wrote:
> 
> > > > b) What information should be specified in schemas? What level of 
> > > >    granularity is required?
> > > 
> > > One item I don't see in this list is node ordering.  There's been some
> > > discussion lately on deferred probing (re boot times).  If we were to
> > > intentionally declare that DT are parsed in the order written, then a
> > > lot of deferred probes could be avoided by moving eg the pinctrl node to
> > > near the top of the tree.
> > > 
> > > This doesn't impact buses as much, since the nodes needing the bus are
> > > already children.  However, anything accessed via phandles: pins,
> > > clocks, regulators, etc could benefit from declaring and enforcing this.
> > > Eg having the dtc warn when a phandle is used before it's corresponding
> > > node is declared.
> > > 
> > > Not critical though, just a thought.
> > 
> > I don't think that siblings have any defined order in DT.  If reading a
> > device tree, there's no guarantee you get nodes or properties out in the
> > same order as the original .dts file.
> 
> That's why I raised the point.  If people think encoding initialization
> order in the DT is a good idea, then we should change the dtc so it
> compiles/decompiles in the same order.

I'm not actually sure what you mean by this.  dtc already preserves
order between input and output.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130730/871c21da/attachment.sig>

From horms+renesas at verge.net.au  Mon Jul 29 21:58:59 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 10:58:59 +0900
Subject: [PATCH 0/4] ARM: shmobile: ape6evm: support GPIO switches and LEDs
Message-ID: <1375149543-27564-1-git-send-email-horms+renesas@verge.net.au>

This short series adds support for GPIO swtiches and LEDS to
the ape6evm board.

Applies on top of renesas-devel-20130726.

Simon Horman (4):
  ARM: shmobile: ape6evm: support GPIO switches
  ARM: shmobile: ape6evm: Enable gpio-keys in defconfig
  ARM: shmobile: ape6evm: Add GPIO LEDs
  ARM: shmobile: ape6evm: Enable gpio-leds in defconfig

 arch/arm/configs/ape6evm_defconfig     |  6 +++-
 arch/arm/mach-shmobile/board-ape6evm.c | 60 ++++++++++++++++++++++++++++++++++
 2 files changed, 65 insertions(+), 1 deletion(-)

-- 
1.8.3.2



From horms+renesas at verge.net.au  Mon Jul 29 21:59:02 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 10:59:02 +0900
Subject: [PATCH 3/4] ARM: shmobile: ape6evm: Add GPIO LEDs
In-Reply-To: <1375149543-27564-1-git-send-email-horms+renesas@verge.net.au>
References: <1375149543-27564-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1375149543-27564-4-git-send-email-horms+renesas@verge.net.au>

The board has 6 LEDs connected to GPIOs. Add a led-gpio device to
support them.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-ape6evm.c | 37 ++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
index 677752c..db97460 100644
--- a/arch/arm/mach-shmobile/board-ape6evm.c
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -39,6 +39,40 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
+/* LEDS */
+static struct gpio_led ape6evm_leds[] = {
+	{
+		.name		= "gnss-en",
+		.gpio		= 28,
+		.default_state	= LEDS_GPIO_DEFSTATE_OFF,
+	}, {
+		.name		= "nfc-nrst",
+		.gpio		= 126,
+		.default_state	= LEDS_GPIO_DEFSTATE_OFF,
+	}, {
+		.name		= "gnss-nrst",
+		.gpio		= 132,
+		.default_state	= LEDS_GPIO_DEFSTATE_OFF,
+	}, {
+		.name		= "bt-wakeup",
+		.gpio		= 232,
+		.default_state	= LEDS_GPIO_DEFSTATE_OFF,
+	}, {
+		.name		= "strobe",
+		.gpio		= 250,
+		.default_state	= LEDS_GPIO_DEFSTATE_OFF,
+	}, {
+		.name		= "bbresetout",
+		.gpio		= 288,
+		.default_state	= LEDS_GPIO_DEFSTATE_OFF,
+	},
+};
+
+static __initdata struct gpio_led_platform_data ape6evm_leds_pdata = {
+	.leds		= ape6evm_leds,
+	.num_leds	= ARRAY_SIZE(ape6evm_leds),
+};
+
 /* GPIO KEY */
 #define GPIO_KEY(c, g, d, ...) \
 	{ .code = c, .gpio = g, .desc = d, .active_low = 1 }
@@ -195,6 +229,9 @@ static void __init ape6evm_add_standard_devices(void)
 	platform_device_register_data(&platform_bus, "gpio-keys", -1,
 				      &ape6evm_keys_pdata,
 				      sizeof(ape6evm_keys_pdata));
+	platform_device_register_data(&platform_bus, "leds-gpio", -1,
+				      &ape6evm_leds_pdata,
+				      sizeof(ape6evm_leds_pdata));
 }
 
 static const char *ape6evm_boards_compat_dt[] __initdata = {
-- 
1.8.3.2



From horms+renesas at verge.net.au  Mon Jul 29 21:59:00 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 10:59:00 +0900
Subject: [PATCH 1/4] ARM: shmobile: ape6evm: support GPIO switches
In-Reply-To: <1375149543-27564-1-git-send-email-horms+renesas@verge.net.au>
References: <1375149543-27564-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1375149543-27564-2-git-send-email-horms+renesas@verge.net.au>

The ape6evm board has switches S16 - S23 wired up to GPIO pins.
This patch allows access to those pins as gpio-keys.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-ape6evm.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
index ccf8b04..677752c 100644
--- a/arch/arm/mach-shmobile/board-ape6evm.c
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -19,6 +19,8 @@
  */
 
 #include <linux/gpio.h>
+#include <linux/gpio_keys.h>
+#include <linux/input.h>
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
 #include <linux/mfd/tmio.h>
@@ -37,6 +39,24 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 
+/* GPIO KEY */
+#define GPIO_KEY(c, g, d, ...) \
+	{ .code = c, .gpio = g, .desc = d, .active_low = 1 }
+
+static struct gpio_keys_button gpio_buttons[] = {
+	GPIO_KEY(KEY_0,			324,	"S16"),
+	GPIO_KEY(KEY_MENU,		325,	"S17"),
+	GPIO_KEY(KEY_HOME,		326,	"S18"),
+	GPIO_KEY(KEY_BACK,		327,	"S19"),
+	GPIO_KEY(KEY_VOLUMEUP,		328,	"S20"),
+	GPIO_KEY(KEY_VOLUMEDOWN,	329,	"S21"),
+};
+
+static struct __initdata gpio_keys_platform_data ape6evm_keys_pdata = {
+	.buttons	= gpio_buttons,
+	.nbuttons	= ARRAY_SIZE(gpio_buttons),
+};
+
 /* Dummy supplies, where voltage doesn't matter */
 static struct regulator_consumer_supply dummy_supplies[] = {
 	REGULATOR_SUPPLY("vddvario", "smsc911x"),
@@ -172,6 +192,9 @@ static void __init ape6evm_add_standard_devices(void)
 	platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 1,
 					  sdhi1_resources, ARRAY_SIZE(sdhi1_resources),
 					  &sdhi1_pdata, sizeof(sdhi1_pdata));
+	platform_device_register_data(&platform_bus, "gpio-keys", -1,
+				      &ape6evm_keys_pdata,
+				      sizeof(ape6evm_keys_pdata));
 }
 
 static const char *ape6evm_boards_compat_dt[] __initdata = {
-- 
1.8.3.2



From horms+renesas at verge.net.au  Mon Jul 29 21:59:03 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 10:59:03 +0900
Subject: [PATCH 4/4] ARM: shmobile: ape6evm: Enable gpio-leds in defconfig
In-Reply-To: <1375149543-27564-1-git-send-email-horms+renesas@verge.net.au>
References: <1375149543-27564-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1375149543-27564-5-git-send-email-horms+renesas@verge.net.au>

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/ape6evm_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/ape6evm_defconfig b/arch/arm/configs/ape6evm_defconfig
index e4359c7..1ce3994 100644
--- a/arch/arm/configs/ape6evm_defconfig
+++ b/arch/arm/configs/ape6evm_defconfig
@@ -72,6 +72,9 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_GPIO=y
 # CONFIG_HID is not set
 # CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
 # CONFIG_IOMMU_SUPPORT is not set
 # CONFIG_DNOTIFY is not set
 CONFIG_TMPFS=y
-- 
1.8.3.2



From horms+renesas at verge.net.au  Mon Jul 29 21:59:01 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 10:59:01 +0900
Subject: [PATCH 2/4] ARM: shmobile: ape6evm: Enable gpio-keys in defconfig
In-Reply-To: <1375149543-27564-1-git-send-email-horms+renesas@verge.net.au>
References: <1375149543-27564-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1375149543-27564-3-git-send-email-horms+renesas@verge.net.au>

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/configs/ape6evm_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/ape6evm_defconfig b/arch/arm/configs/ape6evm_defconfig
index dab5a7d..e4359c7 100644
--- a/arch/arm/configs/ape6evm_defconfig
+++ b/arch/arm/configs/ape6evm_defconfig
@@ -54,7 +54,8 @@ CONFIG_NETDEVICES=y
 CONFIG_SMC91X=y
 CONFIG_SMSC911X=y
 # CONFIG_INPUT_MOUSEDEV is not set
-# CONFIG_INPUT_KEYBOARD is not set
+CONFIG_INPUT_EVDEV=y
+CONFIG_KEYBOARD_GPIO=y
 # CONFIG_INPUT_MOUSE is not set
 # CONFIG_SERIO is not set
 CONFIG_SERIAL_NONSTANDARD=y
-- 
1.8.3.2



From horms at verge.net.au  Mon Jul 29 22:06:46 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 11:06:46 +0900
Subject: [PATCH] clocksource: em_sti: Convert to devm_* managed helpers
In-Reply-To: <1374848897-18545-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1374848897-18545-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <20130730020640.GA27724@verge.net.au>

[ CC John Stultz, Thomas Gleixner ]

On Fri, Jul 26, 2013 at 04:28:17PM +0200, Laurent Pinchart wrote:
> Replace kzalloc, clk_get, ioremap and request_irq by their managed
> counterparts to simplify error paths.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Hi Laurent,

I was recently asked for shmobile clocksource patches to be reviewed
by the clocksource maintainers. I believe that means John Stultz
and Thomas Gleixner who I have CCed on this email accordingly.

I have also CCed linux-arm-kernel at lists.infradead.org as many moons ago
I was asked for all patches that will go through my tree and on to arm-soc
to be sent there.

> ---
>  drivers/clocksource/em_sti.c | 49 +++++++++++++-------------------------------
>  1 file changed, 14 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/clocksource/em_sti.c b/drivers/clocksource/em_sti.c
> index 4329a29..b9c81b7 100644
> --- a/drivers/clocksource/em_sti.c
> +++ b/drivers/clocksource/em_sti.c
> @@ -315,68 +315,47 @@ static int em_sti_probe(struct platform_device *pdev)
>  {
>  	struct em_sti_priv *p;
>  	struct resource *res;
> -	int irq, ret;
> +	int irq;
>  
> -	p = kzalloc(sizeof(*p), GFP_KERNEL);
> +	p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
>  	if (p == NULL) {
>  		dev_err(&pdev->dev, "failed to allocate driver data\n");
> -		ret = -ENOMEM;
> -		goto err0;
> +		return -ENOMEM;
>  	}
>  
>  	p->pdev = pdev;
>  	platform_set_drvdata(pdev, p);
>  
> -	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	if (!res) {
> -		dev_err(&pdev->dev, "failed to get I/O memory\n");
> -		ret = -EINVAL;
> -		goto err0;
> -	}
> -
>  	irq = platform_get_irq(pdev, 0);
>  	if (irq < 0) {
>  		dev_err(&pdev->dev, "failed to get irq\n");
> -		ret = -EINVAL;
> -		goto err0;
> +		return -EINVAL;
>  	}
>  
>  	/* map memory, let base point to the STI instance */
> -	p->base = ioremap_nocache(res->start, resource_size(res));
> -	if (p->base == NULL) {
> -		dev_err(&pdev->dev, "failed to remap I/O memory\n");
> -		ret = -ENXIO;
> -		goto err0;
> -	}
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	p->base = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(p->base))
> +		return PTR_ERR(p->base);
>  
>  	/* get hold of clock */
> -	p->clk = clk_get(&pdev->dev, "sclk");
> +	p->clk = devm_clk_get(&pdev->dev, "sclk");
>  	if (IS_ERR(p->clk)) {
>  		dev_err(&pdev->dev, "cannot get clock\n");
> -		ret = PTR_ERR(p->clk);
> -		goto err1;
> +		return PTR_ERR(p->clk);
>  	}
>  
> -	if (request_irq(irq, em_sti_interrupt,
> -			IRQF_TIMER | IRQF_IRQPOLL | IRQF_NOBALANCING,
> -			dev_name(&pdev->dev), p)) {
> +	if (devm_request_irq(&pdev->dev, irq, em_sti_interrupt,
> +			     IRQF_TIMER | IRQF_IRQPOLL | IRQF_NOBALANCING,
> +			     dev_name(&pdev->dev), p)) {
>  		dev_err(&pdev->dev, "failed to request low IRQ\n");
> -		ret = -ENOENT;
> -		goto err2;
> +		return -ENOENT;
>  	}
>  
>  	raw_spin_lock_init(&p->lock);
>  	em_sti_register_clockevent(p);
>  	em_sti_register_clocksource(p);
>  	return 0;
> -
> -err2:
> -	clk_put(p->clk);
> -err1:
> -	iounmap(p->base);
> -err0:
> -	kfree(p);
> -	return ret;
>  }
>  
>  static int em_sti_remove(struct platform_device *pdev)
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From nicolas.pitre at linaro.org  Mon Jul 29 22:08:06 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 29 Jul 2013 22:08:06 -0400 (EDT)
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value
 to index into save array
In-Reply-To: <20130729115016.GA6184@e102568-lin.cambridge.arm.com>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-2-git-send-email-nicolas.pitre@linaro.org>
 <20130729115016.GA6184@e102568-lin.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1307292155040.15022@syhkavp.arg>

On Mon, 29 Jul 2013, Lorenzo Pieralisi wrote:

> On Tue, Jul 23, 2013 at 04:31:17AM +0100, Nicolas Pitre wrote:
> > Currently we hash the MPIDR of the CPU being suspended to determine which
> > entry in the sleep_save_sp array to use. In some situations, such as when
> > we want to resume on another physical CPU, the MPIDR of another CPU should
> > be used instead.
> > 
> > So let's use the value of cpu_logical_map(smp_processor_id()) in place
> > of the MPIDR in the suspend path.  This will result in the same index
> > being used as with the previous code unless the caller has modified
> > cpu_logical_map() beforehand.
> 
> I will rely on your wisdom to rewrite the commit log in a way that
> does not hint at dangerous creativity, if you catch my drift :D

I've augmented it with some of the earlier comments from Dave Martin.  
I think it is fine to be clear in the commit log about what we intend 
this change to be used for.

> > The register allocation in __cpu_suspend is reworked in order to better
> > accommodate the additional argument.
> > 
> > Signed-off-by: Nicolas Pitre <nico at linaro.org>
> > ---
> >  arch/arm/kernel/sleep.S   | 25 +++++++++++--------------
> >  arch/arm/kernel/suspend.c |  8 +++++---
> >  2 files changed, 16 insertions(+), 17 deletions(-)
> > 
> > diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
> > index db1536b8b3..836d10e698 100644
> > --- a/arch/arm/kernel/sleep.S
> > +++ b/arch/arm/kernel/sleep.S
> > @@ -55,6 +55,7 @@
> >   * specific registers and some other data for resume.
> >   *  r0 = suspend function arg0
> >   *  r1 = suspend function
> > + *  r2 = MPIDR value used to index into sleep_save_sp
> 
> CPU's MPIDR or something like that, let's not hint at possible creative usage.

What about "MPIDR of the CPU to be resumed" which should normally just 
be the current CPU's?

After all, creativity is not always a bad thing given it is reviewed 
properly.

> >   */
> >  ENTRY(__cpu_suspend)
> >  	stmfd	sp!, {r4 - r11, lr}
> > @@ -67,23 +68,19 @@ ENTRY(__cpu_suspend)
> >  	mov	r5, sp			@ current virtual SP
> >  	add	r4, r4, #12		@ Space for pgd, virt sp, phys resume fn
> >  	sub	sp, sp, r4		@ allocate CPU state on stack
> > -	stmfd	sp!, {r0, r1}		@ save suspend func arg and pointer
> > -	add	r0, sp, #8		@ save pointer to save block
> > -	mov	r1, r4			@ size of save block
> > -	mov	r2, r5			@ virtual SP
> >  	ldr	r3, =sleep_save_sp
> > +	stmfd	sp!, {r0, r1}		@ save suspend func arg and pointer
> >  	ldr	r3, [r3, #SLEEP_SAVE_SP_VIRT]
> > -	ALT_SMP(mrc p15, 0, r9, c0, c0, 5)
> > -        ALT_UP_B(1f)
> > -	ldr	r8, =mpidr_hash
> > -	/*
> > -	 * This ldmia relies on the memory layout of the mpidr_hash
> > -	 * struct mpidr_hash.
> > -	 */
> > -	ldmia	r8, {r4-r7}	@ r4 = mpidr mask (r5,r6,r7) = l[0,1,2] shifts
> > -	compute_mpidr_hash	lr, r5, r6, r7, r9, r4
> > -	add	r3, r3, lr, lsl #2
> > +	ALT_SMP(ldr r0, =mpidr_hash)
> > +       ALT_UP_B(1f)
> 
> Should be a tab, do not know if that's an email server issue or not.

Amistake on my part.

> > +	/* This ldmia relies on the memory layout of the mpidr_hash struct */
> > +	ldmia	r0, {r1, r6-r8}	@ r1 = mpidr mask (r6,r7,r8) = l[0,1,2] shifts
> > +	compute_mpidr_hash	r0, r6, r7, r8, r2, r1
> > +	add	r3, r3, r0, lsl #2
> >  1:
> > +	mov	r2, r5			@ virtual SP
> > +	mov	r1, r4			@ size of save block
> > +	add	r0, sp, #8		@ pointer to save block
> 
> It is already a bit complex to follow, code is ok, but line above was
> better placed closer to sp last change, not after hashing the MPIDR.

Well, I tend to disagree.  I think it is much clearer to set function 
arguments closer to the call site so that r0 doesn't have to be live 
with the stack location throughout this code.

> >  	bl	__cpu_suspend_save
> >  	adr	lr, BSYM(cpu_suspend_abort)
> >  	ldmfd	sp!, {r0, pc}		@ call suspend fn
> > diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
> > index 41cf3cbf75..2835d35234 100644
> > --- a/arch/arm/kernel/suspend.c
> > +++ b/arch/arm/kernel/suspend.c
> > @@ -10,7 +10,7 @@
> >  #include <asm/suspend.h>
> >  #include <asm/tlbflush.h>
> >  
> > -extern int __cpu_suspend(unsigned long, int (*)(unsigned long));
> > +extern int __cpu_suspend(unsigned long, int (*)(unsigned long), u32 cpuid);
> >  extern void cpu_resume_mmu(void);
> >  
> >  #ifdef CONFIG_MMU
> > @@ -21,6 +21,7 @@ extern void cpu_resume_mmu(void);
> >  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> >  {
> >  	struct mm_struct *mm = current->active_mm;
> > +	u32 __mpidr = cpu_logical_map(smp_processor_id());
> >  	int ret;
> >  
> >  	if (!idmap_pgd)
> > @@ -32,7 +33,7 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> >  	 * resume (indicated by a zero return code), we need to switch
> >  	 * back to the correct page tables.
> >  	 */
> > -	ret = __cpu_suspend(arg, fn);
> > +	ret = __cpu_suspend(arg, fn, __mpidr);
> >  	if (ret == 0) {
> >  		cpu_switch_mm(mm->pgd, mm);
> >  		local_flush_bp_all();
> > @@ -44,7 +45,8 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> >  #else
> >  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> >  {
> > -	return __cpu_suspend(arg, fn);
> > +	u32 __mpidr = cpu_logical_map(smp_processor_id());
> > +	return __cpu_suspend(arg, fn, __mpidr);
> >  }
> >  #define	idmap_pgd	NULL
> >  #endif
> 
> Apart from these nits, let's hope it is the last cpu_suspend bit we need to
> change, please land it on -next asap, of course if Russell is ok with that.
> 
> I tested it on TC2.
> 
> FWIW:
> 
> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

Thanks.


Nicolas


From jonsmirl at gmail.com  Mon Jul 29 22:15:12 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Mon, 29 Jul 2013 22:15:12 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130730014453.GJ29970@voom.fritz.box>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
 <2460092.aLmjrOVh1g@flatron> <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
 <CACxGe6uE6jOE-vz0onW5h93Es-soGiBAcFBM7Dvxh+HvCNrHkw@mail.gmail.com>
 <CACxGe6vw9=y5a+EgF1gO39SwGAdGofD2MYjyJ3jYu6uN3ke70A@mail.gmail.com>
 <1374988276.1973.29.camel@dabdike>
 <20130730014453.GJ29970@voom.fritz.box>
Message-ID: <CAKON4OyWuF+qm2MAhbXnGg=ozzw37kpSWciLxyUy+QQzxoWdxQ@mail.gmail.com>

On Mon, Jul 29, 2013 at 9:44 PM, David Gibson
<david at gibson.dropbear.id.au> wrote:
> On Sat, Jul 27, 2013 at 10:11:16PM -0700, James Bottomley wrote:
>> On Sat, 2013-07-27 at 21:28 -0600, Grant Likely wrote:
>> > On Sat, Jul 27, 2013 at 2:25 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
>> > > On Sat, Jul 27, 2013 at 2:01 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>> > >> On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
>> > >>> On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel <arend at broadcom.com> wrote:
>> > >>>> Let's see how many people go and scream if I say this: Too bad .dts files
>> > >>>> are not done using XML format as DT bindings could be described using XML
>> > >>>> Schema.
>> > >>>
>> > >>> Draft an example and show us how it would look!  :-)  There is
>> > >>> absolutely nothing preventing us from expressing a DT in XML format,
>> > >>> or even using XSLT to define DT schema while still using our current
>> > >>> .dts syntax. It would be trivial to do lossless translation between
>> > >>> .dts syntax and xml.
>> > >>>
>> > >>> The problem that I have with XML and XSLT is that it is very verbose
>> > >>> and not entirely friendly to mere-mortals. However, I'm more than
>> > >>> willing to be proved wrong on this point.
>> > >>
>> > >> I considered this approach a while ago and discarded it. It would work
>> > >> but it is just too much of a Frankenstein monster.
>> > >>
>> > >> Much cleaner to modify dtc to take a schema as part of the compilation
>> > >> process. The schema language itself has no requirement to look like
>> > >> DTS syntax. Whoever wrote dtc probably has a favorite language that
>> > >> would be good for writing schemas in.
>> > >
>> > > Making it part of dtc is a required feature as far as I'm concerned.
>> > > Using XML/XSLT and dtc-integration are not mutually exclusive, but I
>> > > digress.
>> >
>> > Oops, ignore the XSLT bit. XSLT isn't schema and has no bearing on the
>> > discussion of schema. Sorry for the noise.
>>
>> XSLT is a transform language ... you'd use it say to transform xml to
>> dtc, so it would be an integral component of an xml/xslt based schema.
>>
>> If you want actually to describe and have validated the xml schema
>> itself, then you'd use xsd (XML schema description language) and its
>> associated tools.
>>
>> I'm not saying you *should* do this, just that it's possible (plus I've
>> just blown my kernel cred by knowing about xml, sigh).
>
> Heh.  So, it was said in jest, but that actually raises an important
> point.
>
> There are basically two criteria to keep in mind for our
> representation of schemas:
>    1) Adequate expressiveness to validate a sufficiently large part,
> of a sufficiently large number of bindings to be useful.
>    2) Ease of use and ease of learning **for the target audience**.
>
> To the best of my knowledge xsd would do well on (1), but I'm not
> convinced it does very well on (2).  In an environment where XML was
> already widely used, XSD would make perfect sense.  Here, I think it
> would be pretty ugly to wire onto the existing DT tools and
> infrastructure, and unpleasantly unfamiliar for many kernel and board
> developers trying to work with DT schemas.
>
>
> So, by way of investigation, let me propose an alternative expression
> of schemas, that I'm also not convinced we should do, but is possible
> and expressive.  It's illustrative, because it's kind of the polar
> opposite approach to XSD: just use C.
>
> dtc already has a (so far limited) "checks" mechanism which verifies
> various aspects of DT content.  These are implemented by C functions
> in checks.c.  There's obviously ample expressiveness - you can express
> any constraint you want that way.  It can be pretty verbose, and
> fiddly.  A good library of helper functions can mitigate that, but
> it's not clear how much.  On the other hand, a very good fraction of
> people working with this will already be familiar with C, which is a
> big plus.  This is, after all, the reason that the dts syntax is
> chiefly C inspired.
>
> Now, in practice, I think we will want a more convenient schema
> language (just as we wanted dts, rather than manually constructing
> FDTs as C structures).  But I absolutely do think, that the schema
> handling should be handled as plugins to the checks mechanism -
> basically we'd have a validate_schemas() check function.
>
> I also think we should consider the option of having a simple and
> straightforward schema language which handles, say, 80% of cases with
> a fall back to C for the 20% of curly cases.  That might actually be
> simpler to work with in practice than a schema language which can
> express absolutely anything, at the cost of being awkward for simple
> cases or difficult to get your head around.

Would C++ work? You can use operating overloading and templates to
change the syntax into something that doesn't even resemble C any
more.

>
> Remember, a schema language is only a win if it is - for the target
> audience - more convenient to express schemas in than C.
>
> --
> David Gibson                    | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
>                                 | _way_ _around_!
> http://www.ozlabs.org/~dgibson



-- 
Jon Smirl
jonsmirl at gmail.com


From horms at verge.net.au  Mon Jul 29 22:15:46 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 11:15:46 +0900
Subject: [PATCH] ARM: shmobile: BOCK-W: fix SDHI0 PFC settings
In-Reply-To: <87bo5mrzcc.wl%kuninori.morimoto.gx@renesas.com>
References: <201307270346.34002.sergei.shtylyov@cogentembedded.com>
 <51F30C60.5050504@cogentembedded.com>
 <87bo5mrzcc.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <20130730021545.GA31126@verge.net.au>

On Sun, Jul 28, 2013 at 05:20:43PM -0700, Kuninori Morimoto wrote:
> 
> Hi Simon
> 
> > > The following message is printed on the BOCK-W kernel bootup:
> > 
> > > sh-pfc pfc-r8a7778: invalid group "sdhi0" for function "sdhi0"
> > 
> > > In addition, SD card cannot be detected.  The reason is apparently that commit
> > > ca7bb309485e4ec89a9addd47bea (ARM: shmobile: bockw: add SDHI0 support) matched
> > > the previous version of commit 564617d2f92473031d035deb273da5 (sh-pfc: r8a7778:
> > > add SDHI support).
> > 
> > > Add the missing pin groups according to the BOCK-W board schematics.
> > 
> > > Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> > 
> > > ---
> > > The patch is atop of Simon's 'renesas.git' repo, 'renesas-devel-20130726' tag.
> > 
> >     It also applies to the current Linus' tree cleanly. Please push it for 3.11.
> > 
> > WBR, Sergei
> 
> Something happen on patch.

That something was probably me :(

> Linux/master branch seems have old verion.
> 
> ---- linux/master : old version --------------------------
> commit ca7bb309485e4ec89a9addd47beaa1d079841b7d
> Author: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> Date:   Wed Apr 17 05:17:56 2013 +0000
> 
>     ARM: shmobile: bockw: add SDHI0 support
>     
>     This patch is directly accessing to PUPR4 register which can
>     control SDHI0 CD/WP pin pull-up setting.
>     It should be replaced in the future.
>     
>     Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
>     Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> ----------------------------------------------------------
> 
> This is the correct/latest version
> 
> ----- correct version ---------------------------------------------
> commit c2ee46ab49ce3bb5a60b36940e70355beb409acf
> Author: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> Date:   Thu Apr 18 20:09:32 2013 -0700
> 
>     ARM: shmobile: bockw: add SDHI0 support
>     
>     This patch is directly accessing to PUPR4 register which can
>     control SDHI0 CD/WP pin pull-up setting.
>     It should be replaced in the future.
>     
>     Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
>     Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> -------------------------------------------------------------------
> 
> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Thanks, I have queued this up for v3.11 in the fixes-for-v3.11 branch.


From john.stultz at linaro.org  Mon Jul 29 22:19:09 2013
From: john.stultz at linaro.org (John Stultz)
Date: Mon, 29 Jul 2013 19:19:09 -0700
Subject: [PATCH] clocksource: em_sti: Convert to devm_* managed helpers
In-Reply-To: <20130730020640.GA27724@verge.net.au>
References: <1374848897-18545-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <20130730020640.GA27724@verge.net.au>
Message-ID: <51F7229D.7090706@linaro.org>

On 07/29/2013 07:06 PM, Simon Horman wrote:
> [ CC John Stultz, Thomas Gleixner ]
>
> On Fri, Jul 26, 2013 at 04:28:17PM +0200, Laurent Pinchart wrote:
>> Replace kzalloc, clk_get, ioremap and request_irq by their managed
>> counterparts to simplify error paths.
>>
>> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> Hi Laurent,
>
> I was recently asked for shmobile clocksource patches to be reviewed
> by the clocksource maintainers. I believe that means John Stultz
> and Thomas Gleixner who I have CCed on this email accordingly.

Daniel Lezcano (cc'ed) is picking up maintainership of 
clocksource/clockevent code in drivers/clocksource, so please cc him in 
the future.

thanks
-john



From shawn.guo at linaro.org  Mon Jul 29 22:23:30 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 30 Jul 2013 10:23:30 +0800
Subject: [PATCH] ARM: dts: imx53-qsb: Make USBH1 functional
In-Reply-To: <1374787113-6628-1-git-send-email-fabio.estevam@freescale.com>
References: <1374787113-6628-1-git-send-email-fabio.estevam@freescale.com>
Message-ID: <20130730022327.GA19715@S2101-09.ap.freescale.net>

On Thu, Jul 25, 2013 at 06:18:33PM -0300, Fabio Estevam wrote:
> mx53qsb uses GPIO7_8 to turn on VBUS, so add support for it.
> 
> Also specify the PHY type in the device tree.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Applied, thanks.



From horms at verge.net.au  Mon Jul 29 22:27:03 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 11:27:03 +0900
Subject: [PATCH v3 0/4] ARM: shmobile: marzen: Switch to DT_MACHINE_START
In-Reply-To: <1374799913-27461-1-git-send-email-horms+renesas@verge.net.au>
References: <1374799913-27461-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20130730022703.GE31526@verge.net.au>

On Fri, Jul 26, 2013 at 09:51:49AM +0900, Simon Horman wrote:
> A short series to use DT_MACHINE_START on the marzen board.

Magnus, could you find a few moments to review this series?

> 
> Changes since v2
> * Break dtb changes out of "ARM: shmobile: marzen: Switch to
>   DT_MACHINE_START" and into their own patch "ARM: shmobile: marzen: Add
>   r8a7779-marzen.dtb"
> * Correct typo in changelog of "ARM: shmobile: marzen: Enable
>   ARM_APPENDED_DTB in defconfig"
> 
> Changes since v1
> * Add "ARM: shmobile: marzen: Enable ARM_APPENDED_DTB in defconfig" patch
> * Add "ARM: shmobile: r8a7779: Rely on DT for SMP CPU info" patch
> * Enhance "ARM: shmobile: marzen: Switch to DT_MACHINE_START" to:
>   - Select USE_OF in Kconfig
>   - Provide dt_compat in DT_MACHINE_START
>   - Provide r8a7779-marzen dts
> 
> Magnus Damm (1):
>   ARM: shmobile: marzen: Switch to DT_MACHINE_START
> 
> Simon Horman (3):
>   ARM: shmobile: marzen: Add  r8a7779-marzen.dtb
>   ARM: shmobile: r8a7779: Rely on DT for SMP CPU info
>   ARM: shmobile: marzen: Enable ARM_APPENDED_DTB in defconfig
> 
>  arch/arm/boot/dts/Makefile            |  1 +
>  arch/arm/boot/dts/r8a7779-marzen.dts  | 27 +++++++++++++++++++++++++++
>  arch/arm/configs/marzen_defconfig     |  1 +
>  arch/arm/mach-shmobile/Kconfig        |  1 +
>  arch/arm/mach-shmobile/board-marzen.c |  8 +++++++-
>  arch/arm/mach-shmobile/smp-r8a7779.c  | 12 +++---------
>  6 files changed, 40 insertions(+), 10 deletions(-)
>  create mode 100644 arch/arm/boot/dts/r8a7779-marzen.dts
> 
> -- 
> 1.8.2.1
> 


From shawn.guo at linaro.org  Mon Jul 29 22:38:50 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 30 Jul 2013 10:38:50 +0800
Subject: [PATCH 1/2] ARM: mach-imx: Select ARM_CPU_SUSPEND at ARCH_MXC
 level
In-Reply-To: <1374808656-28609-1-git-send-email-festevam@gmail.com>
References: <1374808656-28609-1-git-send-email-festevam@gmail.com>
Message-ID: <20130730023848.GB19715@S2101-09.ap.freescale.net>

On Fri, Jul 26, 2013 at 12:17:35AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Instead of selecting ARM_CPU_SUSPEND only for mx6, we can select it for 
> all SoCs from the ARCH_MXC family.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> ---
>  arch/arm/mach-imx/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index bb1cc9e..1cc219f 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -1,5 +1,6 @@
>  config ARCH_MXC
>  	bool "Freescale i.MX family" if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
> +	select ARM_CPU_SUSPEND if PM

This should be put after ARCH_REQUIRE_GPIOLIB line.  I fixed it up and
applied both patches.

Shawn

>  	select ARCH_REQUIRE_GPIOLIB
>  	select ARM_PATCH_PHYS_VIRT
>  	select AUTO_ZRELADDR if !ZBOOT_ROM



From xvzhaobin at gmail.com  Mon Jul 29 22:42:31 2013
From: xvzhaobin at gmail.com (zhaobin xv)
Date: Tue, 30 Jul 2013 10:42:31 +0800
Subject: ZTEXTADDR
Message-ID: <CANEcUBXpjOPTV_WrhCkonvmHe7cW139dsaSNzXGY0Vz_2O-FBg@mail.gmail.com>

Hi
When I study linux kernel , I don't understand ZTEXTADDR.
I want to know function of ZTEXTADDR.

thanks


From shawn.guo at linaro.org  Mon Jul 29 22:50:26 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 30 Jul 2013 10:50:26 +0800
Subject: [PATCH] ARM: i.MX5 clocks: Remove optional clock setup (CKIH1)
 from i.MX51 template
In-Reply-To: <1374909585-2724-1-git-send-email-shc_work@mail.ru>
References: <1374909585-2724-1-git-send-email-shc_work@mail.ru>
Message-ID: <20130730025024.GC19715@S2101-09.ap.freescale.net>

On Sat, Jul 27, 2013 at 11:19:45AM +0400, Alexander Shiyan wrote:
> External high frequency clock CKIH1 is optional for i.MX51, so move
> it setup into boards where it is used.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>

Applied, thanks.



From gang.chen at asianux.com  Mon Jul 29 22:51:47 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Tue, 30 Jul 2013 10:51:47 +0800
Subject: [PATCH] ARM(64): KVM: add signed type cast for comparation
In-Reply-To: <51ECA4EC.3000408@asianux.com>
References: <51ECA4EC.3000408@asianux.com>
Message-ID: <51F72A43.5090409@asianux.com>

Hello Maintainers:

Please help check the patch whether OK or not, when you have time.

Thanks.

On 07/22/2013 11:20 AM, Chen Gang wrote:
> 'len' is 'unsigned long' which is never less than zero.
> 
> So need a related type cast for comparation.
> 
> The related warning (when building ARM64 with allmodconfig):
> 
>   arch/arm64/kvm/../../../arch/arm/kvm/mmio.c:82:2: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
> 
> 
> Signed-off-by: Chen Gang <gang.chen at asianux.com>
> ---
>  arch/arm/kvm/mmio.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
> index b8e06b7..626dfc8 100644
> --- a/arch/arm/kvm/mmio.c
> +++ b/arch/arm/kvm/mmio.c
> @@ -79,7 +79,7 @@ static int decode_hsr(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	}
>  
>  	len = kvm_vcpu_dabt_get_as(vcpu);
> -	if (unlikely(len < 0))
> +	if (unlikely((long)len < 0))
>  		return len;
>  
>  	is_write = kvm_vcpu_dabt_iswrite(vcpu);
> 


-- 
Chen Gang


From gang.chen at asianux.com  Mon Jul 29 22:52:13 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Tue, 30 Jul 2013 10:52:13 +0800
Subject: [PATCH] ARM64: include: asm: use 'int' instead of 'u32' for
 variable 'target' in kvm_host.h.
In-Reply-To: <51ECA9B6.3010808@asianux.com>
References: <51ECA9B6.3010808@asianux.com>
Message-ID: <51F72A5D.1090004@asianux.com>

Hello Maintainers:

Please help check the patch whether OK or not, when you have time.

Thanks.

On 07/22/2013 11:40 AM, Chen Gang wrote:
> 'target' will be set to '-1' in kvm_arch_vcpu_init(), and it need check
> 'target' whether less than zero or not in kvm_vcpu_initialized().
> 
> So need define target as 'int' instead of 'u32', just like ARM has done.
> 
> 
> The related warning:
> 
>   arch/arm64/kvm/../../../arch/arm/kvm/arm.c:497:2: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
> 
> Signed-off-by: Chen Gang <gang.chen at asianux.com>
> ---
>  arch/arm64/include/asm/kvm_host.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 644d739..0859a4d 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -129,7 +129,7 @@ struct kvm_vcpu_arch {
>  	struct kvm_mmu_memory_cache mmu_page_cache;
>  
>  	/* Target CPU and feature flags */
> -	u32 target;
> +	int target;
>  	DECLARE_BITMAP(features, KVM_VCPU_MAX_FEATURES);
>  
>  	/* Detect first run of a vcpu */
> 


-- 
Chen Gang


From peter.chen at freescale.com  Mon Jul 29 22:54:16 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Tue, 30 Jul 2013 10:54:16 +0800
Subject: [PATCH 1/2] pinctrl: imx: Add exception hook for select input
Message-ID: <1375152857-32177-1-git-send-email-peter.chen@freescale.com>

At some i.mx platforms the select input pin configuration may
not be at common select input register region due to IC found
the pin select pin configuration missing very late (Eg, ECO stage),
so this pin's select input register is at other register space at
pinctrl module. One typical example is USB OTG ID pin at i.mx6q is
at IOMUXC_IOMUXC_GPR1.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 drivers/pinctrl/pinctrl-imx.c   |   11 +++++++++--
 drivers/pinctrl/pinctrl-imx.h   |    8 ++++++--
 drivers/pinctrl/pinctrl-imx6q.c |   14 ++++++++++++++
 3 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-imx.c b/drivers/pinctrl/pinctrl-imx.c
index 57a4eb0..da75cd4 100644
--- a/drivers/pinctrl/pinctrl-imx.c
+++ b/drivers/pinctrl/pinctrl-imx.c
@@ -240,8 +240,15 @@ static int imx_pmx_enable(struct pinctrl_dev *pctldev, unsigned selector,
 			pin_reg->mux_reg, mux[i]);
 
 		/* some pins also need select input setting, set it if found */
-		if (input_reg[i]) {
-			writel(input_val[i], ipctl->base + input_reg[i]);
+		if (input_reg) {
+			if ((input_reg[i] == IMX_SELECT_INPUT_EXCEPTION) &&
+					info->imx_select_input_hook)
+				info->imx_select_input_hook(ipctl->base,
+					input_val[i]);
+			else
+				writel(input_val[i], ipctl->base +
+					input_reg[i]);
+
 			dev_dbg(ipctl->dev,
 				"==>select_input: offset 0x%x val 0x%x\n",
 				input_reg[i], input_val[i]);
diff --git a/drivers/pinctrl/pinctrl-imx.h b/drivers/pinctrl/pinctrl-imx.h
index bcedd99..15e71b9 100644
--- a/drivers/pinctrl/pinctrl-imx.h
+++ b/drivers/pinctrl/pinctrl-imx.h
@@ -26,8 +26,9 @@ struct platform_device;
  *	elements in .pins so we can iterate over that array
  * @mux_mode: the mux mode for each pin in this group. The size of this
  *	array is the same as pins.
- * @input_reg: select input register offset for this mux if any
- *	0 if no select input setting needed.
+ * @input_reg: select input register offset for this mux,
+ *	0 if no select input setting needed, 0xfff if select input setting
+ *	is not at common select input register regiion.
  * @input_val: the select input value for each pin in this group. The size of
  *	this array is the same as pins.
  * @configs: the config for each pin in this group. The size of this
@@ -75,10 +76,13 @@ struct imx_pinctrl_soc_info {
 	struct imx_pmx_func *functions;
 	unsigned int nfunctions;
 	unsigned int flags;
+	/* Handle the exception for select input choose */
+	void (*imx_select_input_hook) (void __iomem *, int);
 };
 
 #define ZERO_OFFSET_VALID	0x1
 #define SHARE_MUX_CONF_REG	0x2
+#define IMX_SELECT_INPUT_EXCEPTION	0xfff
 
 #define NO_MUX		0x0
 #define NO_PAD		0x0
diff --git a/drivers/pinctrl/pinctrl-imx6q.c b/drivers/pinctrl/pinctrl-imx6q.c
index 76dd9c4..61efa97 100644
--- a/drivers/pinctrl/pinctrl-imx6q.c
+++ b/drivers/pinctrl/pinctrl-imx6q.c
@@ -461,9 +461,23 @@ static const struct pinctrl_pin_desc imx6q_pinctrl_pads[] = {
 	IMX_PINCTRL_PIN(MX6Q_PAD_SD2_DAT3),
 };
 
+#define IOMUXC_IOMUXC_GPR1	0x4
+#define IOMUXC_GPR1_USB_OTG_ID_SEL_BIT	13
+static void imx6q_pinctrl_select_input_hook(void __iomem *base, int val)
+{
+	u32 value;
+	/* Add the exceptions one by one */
+
+	/* USB ID select input configuration */
+	value = readl(base + IOMUXC_IOMUXC_GPR1);
+	writel(value | (val << IOMUXC_GPR1_USB_OTG_ID_SEL_BIT),
+		base + IOMUXC_IOMUXC_GPR1);
+}
+
 static struct imx_pinctrl_soc_info imx6q_pinctrl_info = {
 	.pins = imx6q_pinctrl_pads,
 	.npins = ARRAY_SIZE(imx6q_pinctrl_pads),
+	.imx_select_input_hook = imx6q_pinctrl_select_input_hook,
 };
 
 static struct of_device_id imx6q_pinctrl_of_match[] = {
-- 
1.7.0.4




From peter.chen at freescale.com  Mon Jul 29 22:54:17 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Tue, 30 Jul 2013 10:54:17 +0800
Subject: [PATCH 2/2] imx: pinctrl: change XXX_USB_OTG_ID configuration
In-Reply-To: <1375152857-32177-1-git-send-email-peter.chen@freescale.com>
References: <1375152857-32177-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1375152857-32177-2-git-send-email-peter.chen@freescale.com>

The XXX_USB_OTG_ID select input chosen is not at common select
input register region, we add exception for this pin configration.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
 arch/arm/boot/dts/imx6q-pinfunc.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-pinfunc.h b/arch/arm/boot/dts/imx6q-pinfunc.h
index faea6e1..a40a5a6 100644
--- a/arch/arm/boot/dts/imx6q-pinfunc.h
+++ b/arch/arm/boot/dts/imx6q-pinfunc.h
@@ -532,7 +532,7 @@
 #define MX6Q_PAD_ENET_REF_CLK__ESAI_RX_FS         0x1d4 0x4e8 0x85c 0x2 0x0
 #define MX6Q_PAD_ENET_REF_CLK__GPIO1_IO23         0x1d4 0x4e8 0x000 0x5 0x0
 #define MX6Q_PAD_ENET_REF_CLK__SPDIF_SR_CLK       0x1d4 0x4e8 0x000 0x6 0x0
-#define MX6Q_PAD_ENET_RX_ER__USB_OTG_ID           0x1d8 0x4ec 0x000 0x0 0x0
+#define MX6Q_PAD_ENET_RX_ER__USB_OTG_ID           0x1d8 0x4ec 0xfff 0x0 0x0
 #define MX6Q_PAD_ENET_RX_ER__ENET_RX_ER           0x1d8 0x4ec 0x000 0x1 0x0
 #define MX6Q_PAD_ENET_RX_ER__ESAI_RX_HF_CLK       0x1d8 0x4ec 0x864 0x2 0x0
 #define MX6Q_PAD_ENET_RX_ER__SPDIF_IN             0x1d8 0x4ec 0x914 0x3 0x1
@@ -650,7 +650,7 @@
 #define MX6Q_PAD_GPIO_1__ESAI_RX_CLK              0x224 0x5f4 0x86c 0x0 0x1
 #define MX6Q_PAD_GPIO_1__WDOG2_B                  0x224 0x5f4 0x000 0x1 0x0
 #define MX6Q_PAD_GPIO_1__KEY_ROW5                 0x224 0x5f4 0x8f4 0x2 0x0
-#define MX6Q_PAD_GPIO_1__USB_OTG_ID               0x224 0x5f4 0x000 0x3 0x0
+#define MX6Q_PAD_GPIO_1__USB_OTG_ID               0x224 0x5f4 0xfff 0x3 0x1
 #define MX6Q_PAD_GPIO_1__PWM2_OUT                 0x224 0x5f4 0x000 0x4 0x0
 #define MX6Q_PAD_GPIO_1__GPIO1_IO01               0x224 0x5f4 0x000 0x5 0x0
 #define MX6Q_PAD_GPIO_1__SD1_CD_B                 0x224 0x5f4 0x000 0x6 0x0
-- 
1.7.0.4




From rizhao at nvidia.com  Mon Jul 29 22:54:48 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Tue, 30 Jul 2013 10:54:48 +0800
Subject: [PATCH 1/9] ARM: dts: add generic DMA DT binding for tegra apbdma
In-Reply-To: <51F2CC30.5090200@wwwdotorg.org>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-2-git-send-email-rizhao@nvidia.com>
 <51F2CC30.5090200@wwwdotorg.org>
Message-ID: <20130730025448.GI15855@rizhao-lap>

On Sat, Jul 27, 2013 at 03:21:20AM +0800, Stephen Warren wrote:
> (Stripping the Cc list a lot, but adding in the DT binding maintainers)
> 
> On 07/23/2013 10:09 PM, Richard Zhao wrote:
> > All Tegra device drivers will soon move to generic DMA device tree bindings.
> > Add the required properties to the Tegra DT files to support that. The legacy
> > property nvidia,dma-request-selector will be removed after all drivers have
> > been converted, in order to maintain bisectability.
> > 
> > Changes:
> >  - Add '#dma-cells' for apbdma nodes
> >  - And properties 'dmas' and 'dma-names' for apbdma client nodes
> >  - update apbdma DT binding doc
> > 
> > Signed-off-by: Richard Zhao <rizhao at nvidia.com>
> > ---
> >  .../devicetree/bindings/dma/tegra20-apbdma.txt     |  1 +
> >  arch/arm/boot/dts/tegra114.dtsi                    | 27 ++++++++++++++++++++++
> >  arch/arm/boot/dts/tegra20.dtsi                     | 27 ++++++++++++++++++++++
> >  arch/arm/boot/dts/tegra30.dtsi                     | 25 ++++++++++++++++++++
> 
> This patch should be split differently.
> 
> Patch 1 in the series should include the binding document change and the
> associated DMA driver change, which will support both the old and new
> bindings.
> 
> Patch 2 should contain the *.dtsi changes.
The reason I update apbdma binding doc here is to make it consistent
with the mass properties added in dtsi files.
apbdma has less places of changes than dtsi files.

Thanks
Richard


From olof at lixom.net  Mon Jul 29 22:57:44 2013
From: olof at lixom.net (Olof Johansson)
Date: Mon, 29 Jul 2013 19:57:44 -0700
Subject: [ANNOUNCE] ARM kernel summit 2013, Oct 22-23
Message-ID: <CAOesGMjG-6x0Qf0_FEQ7Rw5-p6Dyhf+Wi-tZ7x_cj7iq8UmjFg@mail.gmail.com>

As previous years, we are planning on hosting a ARM Kernel Summit
attached to the main Kernel Summit, and we have graciously been given
space to host it for two days, Oct 22-23 (Oct 23 is the track day for
the main KS, so we're getting an extra day) in Edinburgh, UK.

To make sure we get the right set of people invited, we're looking for
people to propose topics they would like to see covered as part of the
two-day aganda, as well as general invite requests. To request an
invite or to propose a topic, please send an email to
ksummit-2013-discuss at lists.linuxfoundation.org, and cc LAKML/LKML as
appropriate. Please use the tag "[ARM ATTEND]" in the subject to
distinguish these from the general KS ATTEND threads.

It's pretty obvious that device trees and bindings are hot topics this
year, with plenty of overlap between ARM and regular kernel summit and
other subsystems. We are tentatively planning on dedicating Wednesday
afternoon to the topic, to fit the regular agenda of KS track day to
make sure as many interested parties as possible can attend. We'd
still be interested in hearing specific topic requests in that area
though.


The group of us organizing and coordinating this year is:

Arnd Bergmann
Mark Brown
Kevin Hilman
Olof Johansson
Grant Likely


From nicolas.pitre at linaro.org  Mon Jul 29 23:05:06 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 29 Jul 2013 23:05:06 -0400 (EDT)
Subject: [PATCH] arm: update advice on kernel and FDT load address.
In-Reply-To: <1375106635.12741.8.camel@kazak.uk.xensource.com>
References: <1375102578-5869-1-git-send-email-ian.campbell@citrix.com>
 <20130729135000.GK32383@mudshark.cambridge.arm.com>
 <1375106635.12741.8.camel@kazak.uk.xensource.com>
Message-ID: <alpine.LFD.2.03.1307292234040.15022@syhkavp.arg>

On Mon, 29 Jul 2013, Ian Campbell wrote:

> On Mon, 2013-07-29 at 14:50 +0100, Will Deacon wrote:
> > Hi Ian,
> > 
> > /me plays English teacher :)
> > 
> > On Mon, Jul 29, 2013 at 01:56:18PM +0100, Ian Campbell wrote:
> > > Based on the discussion in [0]:
> > >   - Recommend that the kernel be placed under 128MiB ("for automatic RAM
> > >     location to work", says Nico)
> > >   - Recommend that DTB larger than ~16KiB be placed after the 128MiB boundary
> > >     (in order to avoid conflicting with the kernel decompressor, kernel is at
> > >     most 32MiB) and within the lowmem region. Somewhat arbitrarily recommend
> > >     placement below the 256MiB boundary, the real lowmem limit is likely up
> > >     around 600-800MiB but varies.
> > > 
> > > [0] http://article.gmane.org/gmane.linux.ports.arm.kernel/254538
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
> > > Cc: Russell King <linux at arm.linux.org.uk>
> > > Cc: Nicolas Pitre <nicolas.pitre at linaro.org>
> > > Cc: Will Deacon <will.deacon at arm.com>
> > > Cc: Dave Martin <dave.martin at linaro.org>
> > > Cc: Grant Likely <grant.likely at secretlab.ca>
> > > Cc: linux-arm-kernel at lists.infradead.org
> > > ---
> > >  Documentation/arm/Booting |   14 +++++++++++---
> > >  1 files changed, 11 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting
> > > index 0c1f475..72c035e 100644
> > > --- a/Documentation/arm/Booting
> > > +++ b/Documentation/arm/Booting
> > > @@ -125,6 +125,13 @@ with the caveat that it may not be located at physical address 0 since
> > >  the kernel interprets a value of 0 in r2 to mean neither a tagged list
> > >  nor a dtb were passed.
> > >  
> > > +If the DTB is larger than ~16KiB, such that placement in the first
> > > +16KiB would lead to a conflict with the kernel loaded at 32KiB (as
> > > +recommended below) which uses the memory between 16KiB-32KiB itself,
> > > +then the DTB should be placed after the first 128MiB of RAM in order
> > > +to avoid conflicting with the kernel decompressor. The recommnded
> > 
> > recommended
> 
> Should've pressed F5, sorry...
> 
> > It also looks like you're repeating part of what is said later regarding the
> > 16k of page tables below the image.
> 
> yes, this was tricky since I wanted to justify the larger than 16KiB but
> that was a forward reference. I went with "as recommended below".
> Perhaps I should just omit the justification? Or perhaps "If the DTB is
> larger than ~16KiB (see below for why this particular value
> matters)...". Clunky :-(

Why not simply:

	Make sure the loaded DTB doesn't conflict with the zImage 
	decompressor which may relocate itself.  A safe location is 
	just above the 128MB boundary from start of RAM.

> > Also, we use 20k with LPAE.
> 
> I'll fold in an update along those lines too.
> 
> However given that this then makes everything more complicated (e.g.
> it's now DTB > ~12KiB in that case) perhaps we should just ditch the
> original recommendation to use the first 16KiB and switch to a
> recommendation of "as high as possible below 256MiB" across the board?
> That would remove the issue with repeating stuff from the next section
> too.

Sure.

> 
> > > +placement in this case just below the 256MiB boundary.
> > > +
> > >  5. Calling the kernel image
> > >  ---------------------------
> > >  
> > > @@ -136,9 +143,10 @@ is stored in flash, and is linked correctly to be run from flash,
> > >  then it is legal for the boot loader to call the zImage in flash
> > >  directly.
> > >  
> > > -The zImage may also be placed in system RAM (at any location) and
> > > -called there.  Note that the kernel uses 16K of RAM below the image
> > > -to store page tables.  The recommended placement is 32KiB into RAM.
> > > +The zImage may also be placed in system RAM and called there.  The
> > > +kernel should be placed in the first 128MiB of RAM. Note that the
> > > +kernel uses 16KiB of RAM below the image to store page tables.  The
> > > +recommended placement is 32KiB into RAM.
> > 
> > This is a bit clunky since you say that the zImage may be placed in system
> > RAM, then restrict that in the next sentence.
> 
> How about:
> 
>         The kernel may also be placed in the first 128MiB of system RAM
>         and called there.

Not "may" but "must" if you have CONFIG_AUTO_ZRELADDR=y.

>	Note that the kernel uses 16KiB of RAM below
>       the image to store page tables.  The recommended placement is
>         32KiB into RAM.

Well... not completely right.

You may load zImage anywhere in the first 128MB of RAM if you have 
CONFIG_AUTO_ZRELADDR=y.  If CONFIG_AUTO_ZRELADDR=n then zImage may be 
loaded anywhere. In the former case, the zImage code will automatically 
determine the physical start of RAM.  In the later case the start of RAM 
is hardcoded in the zImage binary.

Then, the zImage code will decompress the actual kernel image at an 
offset of (in most cases) 32KB from start of RAM.  However, if the 
decompressed kernel would overwrite the loaded zImage where the 
decompressor code and data is located, then zImage will relocate itself 
just after the end of the decompressed kernel area before proceeding to 
the decompression.  This is where you need to be careful about 
ramdisk/initrd and DTB load addresses.

The initial page table is therefore (in most cases again) just below the 
decompressed kernel location i.e. either Ffrom 16KB from start of RAM, 
or from 12KB if using LPAE.

You can therefore load everything (zImage, initrd, DTB) sequentially 
from the 32MB mark in RAM and be safe.  By loading zImage that high, it 
most certainly won't need to relocate itself (unless the decompressed 
kernel is larger than 32MB which is very unlikely as I mentioned) and 
that will also make the boot process slightly faster.



Nicolas


From rizhao at nvidia.com  Mon Jul 29 23:06:46 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Tue, 30 Jul 2013 11:06:46 +0800
Subject: [PATCH 2/9] dma: tegra20-apbdma: move to generic device tree
 bindings
In-Reply-To: <51F2CDBE.40802@wwwdotorg.org>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-3-git-send-email-rizhao@nvidia.com>
 <51F2CDBE.40802@wwwdotorg.org>
Message-ID: <20130730030644.GJ15855@rizhao-lap>

On Sat, Jul 27, 2013 at 03:27:58AM +0800, Stephen Warren wrote:
> (Stripping the Cc list a lot)
> 
> On 07/23/2013 10:09 PM, Richard Zhao wrote:
> > Update tegra20-apbdma driver to adopt generic DMA device tree bindings.
> > It calls of_dma_controller_register() with of_dma_simple_xlate to get
> > the generic DMA device tree helper support. The #dma-cells for apbdma
> > must be 1, which is slave ID.
> > 
> > The existing nvidia,dma-request-selector still works there, and the
> > support will be removed after all clients get converted to generic DMA
> > device tree helper.
> 
> (BTW, I would like to take this series through the Tegra tree to
> simplify dependencies. So, I'm looking for ack's on the drivers rather
> than for them to be applied. I had hoped Richard would point this out
> when posting the patches)
Sorry I forgot to add maintainr-pick-up suggestions.
> 
> > diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> 
> > +static bool tegra_dma_filter_fn(struct dma_chan *dc, void *param)
> > +{
> > +	if (dc->device->dev->driver == &tegra_dmac_driver.driver) {
> > +		struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
> > +		unsigned req = *(unsigned *)param;
> > +
> > +		tdc->slave_id = req;
> > +
> > +		return true;
> > +	}
> > +	return false;
> > +}
> > +
> > +static struct of_dma_filter_info tegra_dma_info = {
> > +	.filter_fn = tegra_dma_filter_fn,
> > +};
> 
> Why does this driver need to define a filter function? I thought the
> dmaengine's DT support would already match DMA clients/engines based on
> the phandle in DT? Isn't the need to pass the slave channel ID into
> drivers something pretty fundamental to dmaengine, and hence something
> it already supports?
of_dma_simple_xlate only pass slave id to filter function. It needs
change to pass dt node too. I didn't start work on the common code
change yet. Do you think we need to hold it until common code change?

Thanks
Richard
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From shawn.guo at linaro.org  Mon Jul 29 23:14:37 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 30 Jul 2013 11:14:37 +0800
Subject: [RFC 1/8] gpio: mxc: Use devm_ functions
In-Reply-To: <1374938808-27316-2-git-send-email-mpa@pengutronix.de>
References: <1374938808-27316-1-git-send-email-mpa@pengutronix.de>
 <1374938808-27316-2-git-send-email-mpa@pengutronix.de>
Message-ID: <20130730031436.GE19715@S2101-09.ap.freescale.net>

On Sat, Jul 27, 2013 at 05:26:41PM +0200, Markus Pargmann wrote:
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> ---
>  drivers/gpio/gpio-mxc.c | 30 +++++++++++-------------------
>  1 file changed, 11 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
> index 7176743..cee040f 100644
> --- a/drivers/gpio/gpio-mxc.c
> +++ b/drivers/gpio/gpio-mxc.c
> @@ -405,33 +405,31 @@ static int mxc_gpio_probe(struct platform_device *pdev)
>  
>  	mxc_gpio_get_hw(pdev);
>  
> -	port = kzalloc(sizeof(struct mxc_gpio_port), GFP_KERNEL);
> +	port = devm_kzalloc(&pdev->dev, sizeof(struct mxc_gpio_port),
> +			GFP_KERNEL);
>  	if (!port)
>  		return -ENOMEM;
>  
>  	iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	if (!iores) {
> -		err = -ENODEV;
> -		goto out_kfree;
> +		return -ENODEV;
>  	}
>  
> -	if (!request_mem_region(iores->start, resource_size(iores),
> -				pdev->name)) {
> -		err = -EBUSY;
> -		goto out_kfree;
> +	if (!devm_request_mem_region(&pdev->dev, iores->start,
> +				resource_size(iores), pdev->name)) {
> +		return -EBUSY;
>  	}
>  
> -	port->base = ioremap(iores->start, resource_size(iores));
> +	port->base = devm_ioremap(&pdev->dev, iores->start,
> +			resource_size(iores));

It can be even cleaner by using devm_ioremap_resource().

>  	if (!port->base) {
> -		err = -ENOMEM;
> -		goto out_release_mem;
> +		return -ENOMEM;
>  	}

We should probably drop the braces then.

Shawn

>  
>  	port->irq_high = platform_get_irq(pdev, 1);
>  	port->irq = platform_get_irq(pdev, 0);
>  	if (port->irq < 0) {
> -		err = -EINVAL;
> -		goto out_iounmap;
> +		return -EINVAL;
>  	}
>  
>  	/* disable the interrupt and clear the status */
> @@ -462,7 +460,7 @@ static int mxc_gpio_probe(struct platform_device *pdev)
>  			 port->base + GPIO_DR, NULL,
>  			 port->base + GPIO_GDIR, NULL, 0);
>  	if (err)
> -		goto out_iounmap;
> +		return err;
>  
>  	port->bgc.gc.to_irq = mxc_gpio_to_irq;
>  	port->bgc.gc.base = (pdev->id < 0) ? of_alias_get_id(np, "gpio") * 32 :
> @@ -498,12 +496,6 @@ out_gpiochip_remove:
>  	WARN_ON(gpiochip_remove(&port->bgc.gc) < 0);
>  out_bgpio_remove:
>  	bgpio_remove(&port->bgc);
> -out_iounmap:
> -	iounmap(port->base);
> -out_release_mem:
> -	release_mem_region(iores->start, resource_size(iores));
> -out_kfree:
> -	kfree(port);
>  	dev_info(&pdev->dev, "%s failed with errno %d\n", __func__, err);
>  	return err;
>  }
> -- 
> 1.8.3.2
> 



From rizhao at nvidia.com  Mon Jul 29 23:15:36 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Tue, 30 Jul 2013 11:15:36 +0800
Subject: [PATCH 3/9] spi: tegra114: move to generic dma DT binding
In-Reply-To: <51F2CF53.30002@wwwdotorg.org>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-4-git-send-email-rizhao@nvidia.com>
 <51F2CF53.30002@wwwdotorg.org>
Message-ID: <20130730031536.GK15855@rizhao-lap>

On Sat, Jul 27, 2013 at 03:34:43AM +0800, Stephen Warren wrote:
> (Stripping CC list a bit)
> 
> On 07/23/2013 10:09 PM, Richard Zhao wrote:
> > - driver: remove use of nvidia,dma-request-selector
> > 	  use dma_request_slave_channel to request channel
> > - if dmas/dma-names are missing, it still supports cpu based transfer
> > - update binding doc and specify dmas/dma-names properties as optional
> 
> I'll simply repeat the comments I already made downstream:
> 
> Most commit messages aren't written as bullet points. 
Alright, I'll change it. (Personally I like bullet points).
> This might be
> better written as:
> 
> ----------
> Convert the Tegra114 SPI driver to support the standard DMA device-tree
> bindings.
> 
> Note that DMA mode is optional; if the DT properties required to support
> DMA are missing, then the driver will fall back to pure CPU operation.
> ----------
> 
> > diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
> 
> > +Optional properties:
> > +- dmas : The Tegra DMA controller's phandle and request selector for
> > +  this SPI controller.
> > +- dma-names : Should be "rx-tx".
> 
> This should reference dma.txt which defines the DMA DT bindings. How about:
> 
> ----------
> Optional properties:
> - dmas, dma-names : The DMA channel to use for DMA-mode operation. See
>   dma.txt for the definition of these properties. A single entry named
>   "rx-tx" must be specified.
> ----------
Ok. but how about replace "DMA channel" with "DMA request"?

Thanks
Richard


From rizhao at nvidia.com  Mon Jul 29 23:16:13 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Tue, 30 Jul 2013 11:16:13 +0800
Subject: [PATCH 5/9] spi: tegra20-sflash: move to generic dma DT binding
In-Reply-To: <51F2CFAB.4000609@wwwdotorg.org>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-6-git-send-email-rizhao@nvidia.com>
 <51F2CFAB.4000609@wwwdotorg.org>
Message-ID: <20130730031612.GL15855@rizhao-lap>

On Sat, Jul 27, 2013 at 03:36:11AM +0800, Stephen Warren wrote:
> On 07/23/2013 10:09 PM, Richard Zhao wrote:
> > update binding doc.
> 
> It may be worth mentioning here that the driver isn't updated since it
> doesn't support DMA operation (yet?). A more complete patch description
> would also be useful.
ok

Thanks
Richard


From padma.kvr at gmail.com  Mon Jul 29 23:28:39 2013
From: padma.kvr at gmail.com (Padma Venkat)
Date: Tue, 30 Jul 2013 08:58:39 +0530
Subject: [PATCH V2 7/8] ARM: dts: wm8994: Add wm8994 support on smdk5420
In-Reply-To: <20130729134311.GX9858@sirena.org.uk>
References: <1374845812-7803-1-git-send-email-padma.v@samsung.com>
 <1374845812-7803-8-git-send-email-padma.v@samsung.com>
 <20130726151902.GL9858@sirena.org.uk>
 <CAAgF-Be8SNxTZv1yFCwH6yJ-O_3R4reh=3y+pSCLJYW7S9TkUg@mail.gmail.com>
 <CAAgF-Bexp_fGT8KV+TQ0_kZLJBtq7UK=TG4eYRA6qpTSL+scxg@mail.gmail.com>
 <20130729134311.GX9858@sirena.org.uk>
Message-ID: <CAAgF-BeDYm1jNJpkyfTeS5HjpEuaHiumFq+D_PNs=QYG6-Px+w@mail.gmail.com>

Hi Mark,

On Mon, Jul 29, 2013 at 7:13 PM, Mark Brown <broonie at kernel.org> wrote:
> On Mon, Jul 29, 2013 at 05:31:16PM +0530, Padma Venkat wrote:
>> On Sat, Jul 27, 2013 at 6:46 AM, Padma Venkat <padma.kvr at gmail.com> wrote:
>
>> >>> +     vdd: fixed-regulator at 0 {
>> >>> +             compatible = "regulator-fixed";
>> >>> +             regulator-name = "vdd-supply";
>
>> >> These names look wrong - they should reflect the names in the schematic
>> >> as they're for human comprehensibility.  This may just be a case of
>> >> dropping the -supply.
>
>> When I posted the same patch for smdk5250, you asked me to club all
>> the same supply regulators. So I clubbed AVDD2 and CPVDD. So any other
>> better name for representing both supplies?
>
> No, I'd have told you to combine things taht come from the same supply
> on the board - things like the speaker supplies for example aren't going
> to be coming from separate places.  The names should reflect whatever
> the names on the schemaric are, like I say that's probably just removing
> the -supply.
>
>> >> documentation update the other day, it's in my tree now) but it's not
>> >> essential and I suspect it needs some work on the clock driver side
>> >> still.
>
>> > OK. I will check this.
>
>> As per schemata, input clock to MCLK1 is an oscillator clock with
>> 16.9MHz and MCLK2 not showing any input clock. So here I need to add a
>> fixed rate clock with 16.9MHz as MCLK1 in the smdk board file.
>
>> Is it correct?
>
> Yes, in the DTS (or to XCLKOUT on the AP?).

On smdk boards(atleast on smdk5250 and smdk5420) there is no XCLKOUT
funda. Codec MCLK can get clock from oscillator clock in codec master
mode or i2scdclk in codec slave mode. XCLKOUT is there in some other
variants of 5250 and 5420 where it is using other codecs than wm8994.
But the mux and divider of XCLKOUT is out of CMU. As Sylwester told it
is there in PMU registers.

Thanks
Padma


From rizhao at nvidia.com  Mon Jul 29 23:31:35 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Tue, 30 Jul 2013 11:31:35 +0800
Subject: [PATCH 6/9] serial: tegra: move to generic dma DT binding
In-Reply-To: <51F2D063.5010505@wwwdotorg.org>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-7-git-send-email-rizhao@nvidia.com>
 <51F2D063.5010505@wwwdotorg.org>
Message-ID: <20130730033134.GM15855@rizhao-lap>

On Sat, Jul 27, 2013 at 03:39:15AM +0800, Stephen Warren wrote:
> On 07/23/2013 10:09 PM, Richard Zhao wrote:
> > - driver: remove use of nvidia,dma-request-selector
> > 	  use dma_request_slave_channel to request channel
> > - update binding doc
> 
> This patch needs to be amended so that the DMA channel is looked up
> during probe() rather than open(), to guarantee that deferred probe
> works. It's possible to hold off probe, but not possible AFAIK to hold
> off opening the port.
How about avoid return -EPROBE_DEFER at open() time? It can be in
another patch.

Thanks
Richard


From shawn.guo at linaro.org  Mon Jul 29 23:43:57 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 30 Jul 2013 11:43:57 +0800
Subject: [RFC 2/8] gpio: mxc: Support for initialization as submodule
In-Reply-To: <1374938808-27316-3-git-send-email-mpa@pengutronix.de>
References: <1374938808-27316-1-git-send-email-mpa@pengutronix.de>
 <1374938808-27316-3-git-send-email-mpa@pengutronix.de>
Message-ID: <20130730034354.GF19715@S2101-09.ap.freescale.net>

On Sat, Jul 27, 2013 at 05:26:42PM +0200, Markus Pargmann wrote:
> On imx27 and imx21, there is no clear seperation between iomux control
> registers and GPIO data registers. For easier pingroup definitions, the
> gpio drivers will be initialized as subnodes of the iomux controller. It
> is necessary to share the registers between iomux and gpio.
> 
> This patch adds support to pass a register memory region via platform
> data.
> 
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> ---
>  drivers/gpio/gpio-mxc.c  | 35 +++++++++++++++++++----------------
>  include/linux/gpio-mxc.h | 17 +++++++++++++++++
>  2 files changed, 36 insertions(+), 16 deletions(-)
>  create mode 100644 include/linux/gpio-mxc.h

Since the header is created only for holding platform_data, we should
probably put it into include/linux/platform_data/.
> 
> diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
> index cee040f..0c4e32c 100644
> --- a/drivers/gpio/gpio-mxc.c
> +++ b/drivers/gpio/gpio-mxc.c
> @@ -26,6 +26,7 @@
>  #include <linux/irqdomain.h>
>  #include <linux/irqchip/chained_irq.h>
>  #include <linux/gpio.h>
> +#include <linux/gpio-mxc.h>
>  #include <linux/platform_device.h>
>  #include <linux/slab.h>
>  #include <linux/basic_mmio_gpio.h>
> @@ -400,6 +401,7 @@ static int mxc_gpio_probe(struct platform_device *pdev)
>  	struct device_node *np = pdev->dev.of_node;
>  	struct mxc_gpio_port *port;
>  	struct resource *iores;
> +	struct mxc_gpio_platform_data *pdata = pdev->dev.platform_data;
>  	int irq_base;
>  	int err;
>  
> @@ -410,27 +412,28 @@ static int mxc_gpio_probe(struct platform_device *pdev)
>  	if (!port)
>  		return -ENOMEM;
>  
> -	iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	if (!iores) {
> -		return -ENODEV;
> -	}
> -
> -	if (!devm_request_mem_region(&pdev->dev, iores->start,
> -				resource_size(iores), pdev->name)) {
> -		return -EBUSY;
> -	}
> -
> -	port->base = devm_ioremap(&pdev->dev, iores->start,
> -			resource_size(iores));
> -	if (!port->base) {
> -		return -ENOMEM;
> +	if (pdata) {
> +		port->base = pdata->base;
> +		iores = NULL;

Why is this needed?

> +	} else {
> +		iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +		if (!iores)
> +			return -ENODEV;
> +
> +		if (!devm_request_mem_region(&pdev->dev, iores->start,
> +					resource_size(iores), pdev->name))
> +			return -EBUSY;
> +
> +		port->base = devm_ioremap(&pdev->dev, iores->start,
> +				resource_size(iores));
> +		if (!port->base)
> +			return -ENOMEM;
>  	}
>  
>  	port->irq_high = platform_get_irq(pdev, 1);
>  	port->irq = platform_get_irq(pdev, 0);
> -	if (port->irq < 0) {
> +	if (port->irq < 0)
>  		return -EINVAL;
> -	}

The change belongs to patch #1.

Shawn

>  
>  	/* disable the interrupt and clear the status */
>  	writel(0, port->base + GPIO_IMR);
> diff --git a/include/linux/gpio-mxc.h b/include/linux/gpio-mxc.h
> new file mode 100644
> index 0000000..6be51bc
> --- /dev/null
> +++ b/include/linux/gpio-mxc.h
> @@ -0,0 +1,17 @@
> +#ifndef _LINUX_GPIO_MXC_H
> +#define _LINUX_GPIO_MXC_H
> +
> +#include <linux/types.h>
> +
> +/*
> + * MXC GPIO driver platform data. If this platform data is passed to the
> + * driver, it will use the memory base defined in the struct. This is used for
> + * iomuxc drivers on imx21 and imx27, where the GPIO data register is embedded
> + * between the iomuxc registers.
> + */
> +
> +struct mxc_gpio_platform_data {
> +	void __iomem *base;
> +};
> +
> +#endif /* _LINUX_GPIO_MXC_H */
> -- 
> 1.8.3.2
> 



From festevam at gmail.com  Mon Jul 29 23:45:33 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 30 Jul 2013 00:45:33 -0300
Subject: [RFC 1/8] gpio: mxc: Use devm_ functions
In-Reply-To: <20130730031436.GE19715@S2101-09.ap.freescale.net>
References: <1374938808-27316-1-git-send-email-mpa@pengutronix.de>
 <1374938808-27316-2-git-send-email-mpa@pengutronix.de>
 <20130730031436.GE19715@S2101-09.ap.freescale.net>
Message-ID: <CAOMZO5Afr5zZLonmHm1PO4L6ed5SJ2K+vywX3Uu1etBTcrryYg@mail.gmail.com>

On Tue, Jul 30, 2013 at 12:14 AM, Shawn Guo <shawn.guo at linaro.org> wrote:

> It can be even cleaner by using devm_ioremap_resource().

I have already sent a patch that converts to devm_ioremap_resource()
and it is already in Linus Walleij's tree.


From christoffer.dall at linaro.org  Mon Jul 29 23:45:31 2013
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 29 Jul 2013 20:45:31 -0700
Subject: [PATCH] ARM(64): KVM: add signed type cast for comparation
In-Reply-To: <51ECA4EC.3000408@asianux.com>
References: <51ECA4EC.3000408@asianux.com>
Message-ID: <20130730034531.GC5471@cbox>

On Mon, Jul 22, 2013 at 11:20:12AM +0800, Chen Gang wrote:
> 'len' is 'unsigned long' which is never less than zero.
> 
> So need a related type cast for comparation.
> 
> The related warning (when building ARM64 with allmodconfig):
> 
>   arch/arm64/kvm/../../../arch/arm/kvm/mmio.c:82:2: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
> 

Hmmm, interesting, I don't get this error with my compiler.

> 
> Signed-off-by: Chen Gang <gang.chen at asianux.com>
> ---
>  arch/arm/kvm/mmio.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
> index b8e06b7..626dfc8 100644
> --- a/arch/arm/kvm/mmio.c
> +++ b/arch/arm/kvm/mmio.c
> @@ -79,7 +79,7 @@ static int decode_hsr(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	}
>  
>  	len = kvm_vcpu_dabt_get_as(vcpu);
> -	if (unlikely(len < 0))
> +	if (unlikely((long)len < 0))
>  		return len;
>  
>  	is_write = kvm_vcpu_dabt_iswrite(vcpu);
> -- 
> 1.7.7.6

I think the proper fix is to declare len as an int instead.  I'll queue
that instead.

Thanks,
-Christoffer


From christoffer.dall at linaro.org  Mon Jul 29 23:49:45 2013
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 29 Jul 2013 20:49:45 -0700
Subject: [PATCH] ARM64: include: asm: use 'int' instead of 'u32' for
 variable 'target' in kvm_host.h.
In-Reply-To: <51ECA9B6.3010808@asianux.com>
References: <51ECA9B6.3010808@asianux.com>
Message-ID: <20130730034945.GD5471@cbox>

On Mon, Jul 22, 2013 at 11:40:38AM +0800, Chen Gang wrote:
> 'target' will be set to '-1' in kvm_arch_vcpu_init(), and it need check
> 'target' whether less than zero or not in kvm_vcpu_initialized().
> 
> So need define target as 'int' instead of 'u32', just like ARM has done.
> 
> 
> The related warning:
> 
>   arch/arm64/kvm/../../../arch/arm/kvm/arm.c:497:2: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
> 
> Signed-off-by: Chen Gang <gang.chen at asianux.com>
> ---
>  arch/arm64/include/asm/kvm_host.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 644d739..0859a4d 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -129,7 +129,7 @@ struct kvm_vcpu_arch {
>  	struct kvm_mmu_memory_cache mmu_page_cache;
>  
>  	/* Target CPU and feature flags */
> -	u32 target;
> +	int target;
>  	DECLARE_BITMAP(features, KVM_VCPU_MAX_FEATURES);
>  
>  	/* Detect first run of a vcpu */
> -- 
> 1.7.7.6

This looks ok to me, Marc, was there any reason to declare target a u32
on arm64?

-Christoffer


From magnus.damm at gmail.com  Mon Jul 29 23:53:53 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 30 Jul 2013 12:53:53 +0900
Subject: [PATCH v3 0/4] ARM: shmobile: marzen: Switch to DT_MACHINE_START
In-Reply-To: <20130730022703.GE31526@verge.net.au>
References: <1374799913-27461-1-git-send-email-horms+renesas@verge.net.au>
 <20130730022703.GE31526@verge.net.au>
Message-ID: <CANqRtoQy91tKZP2mUYAGeqegWcEzvk81EbZ6=gzxvefKcBaZyg@mail.gmail.com>

Hi Simon,

On Tue, Jul 30, 2013 at 11:27 AM, Simon Horman <horms at verge.net.au> wrote:
> On Fri, Jul 26, 2013 at 09:51:49AM +0900, Simon Horman wrote:
>> A short series to use DT_MACHINE_START on the marzen board.
>
> Magnus, could you find a few moments to review this series?

These are fine with me, thanks for your help!

Acked-by: Magnus Damm <damm at opensource.se>


From david at gibson.dropbear.id.au  Mon Jul 29 23:29:26 2013
From: david at gibson.dropbear.id.au (David Gibson)
Date: Tue, 30 Jul 2013 13:29:26 +1000
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <CAKON4OyWuF+qm2MAhbXnGg=ozzw37kpSWciLxyUy+QQzxoWdxQ@mail.gmail.com>
References: <51F39FD8.6080808@broadcom.com> <2460092.aLmjrOVh1g@flatron>
 <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
 <CACxGe6uE6jOE-vz0onW5h93Es-soGiBAcFBM7Dvxh+HvCNrHkw@mail.gmail.com>
 <CACxGe6vw9=y5a+EgF1gO39SwGAdGofD2MYjyJ3jYu6uN3ke70A@mail.gmail.com>
 <1374988276.1973.29.camel@dabdike>
 <20130730014453.GJ29970@voom.fritz.box>
 <CAKON4OyWuF+qm2MAhbXnGg=ozzw37kpSWciLxyUy+QQzxoWdxQ@mail.gmail.com>
Message-ID: <20130730032926.GL29970@voom.fritz.box>

On Mon, Jul 29, 2013 at 10:15:12PM -0400, jonsmirl at gmail.com wrote:
> On Mon, Jul 29, 2013 at 9:44 PM, David Gibson
> <david at gibson.dropbear.id.au> wrote:
> > On Sat, Jul 27, 2013 at 10:11:16PM -0700, James Bottomley wrote:
> >> On Sat, 2013-07-27 at 21:28 -0600, Grant Likely wrote:
> >> > On Sat, Jul 27, 2013 at 2:25 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
> >> > > On Sat, Jul 27, 2013 at 2:01 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
> >> > >> On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
> >> > >>> On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel <arend at broadcom.com> wrote:
> >> > >>>> Let's see how many people go and scream if I say this: Too bad .dts files
> >> > >>>> are not done using XML format as DT bindings could be described using XML
> >> > >>>> Schema.
> >> > >>>
> >> > >>> Draft an example and show us how it would look!  :-)  There is
> >> > >>> absolutely nothing preventing us from expressing a DT in XML format,
> >> > >>> or even using XSLT to define DT schema while still using our current
> >> > >>> .dts syntax. It would be trivial to do lossless translation between
> >> > >>> .dts syntax and xml.
> >> > >>>
> >> > >>> The problem that I have with XML and XSLT is that it is very verbose
> >> > >>> and not entirely friendly to mere-mortals. However, I'm more than
> >> > >>> willing to be proved wrong on this point.
> >> > >>
> >> > >> I considered this approach a while ago and discarded it. It would work
> >> > >> but it is just too much of a Frankenstein monster.
> >> > >>
> >> > >> Much cleaner to modify dtc to take a schema as part of the compilation
> >> > >> process. The schema language itself has no requirement to look like
> >> > >> DTS syntax. Whoever wrote dtc probably has a favorite language that
> >> > >> would be good for writing schemas in.
> >> > >
> >> > > Making it part of dtc is a required feature as far as I'm concerned.
> >> > > Using XML/XSLT and dtc-integration are not mutually exclusive, but I
> >> > > digress.
> >> >
> >> > Oops, ignore the XSLT bit. XSLT isn't schema and has no bearing on the
> >> > discussion of schema. Sorry for the noise.
> >>
> >> XSLT is a transform language ... you'd use it say to transform xml to
> >> dtc, so it would be an integral component of an xml/xslt based schema.
> >>
> >> If you want actually to describe and have validated the xml schema
> >> itself, then you'd use xsd (XML schema description language) and its
> >> associated tools.
> >>
> >> I'm not saying you *should* do this, just that it's possible (plus I've
> >> just blown my kernel cred by knowing about xml, sigh).
> >
> > Heh.  So, it was said in jest, but that actually raises an important
> > point.
> >
> > There are basically two criteria to keep in mind for our
> > representation of schemas:
> >    1) Adequate expressiveness to validate a sufficiently large part,
> > of a sufficiently large number of bindings to be useful.
> >    2) Ease of use and ease of learning **for the target audience**.
> >
> > To the best of my knowledge xsd would do well on (1), but I'm not
> > convinced it does very well on (2).  In an environment where XML was
> > already widely used, XSD would make perfect sense.  Here, I think it
> > would be pretty ugly to wire onto the existing DT tools and
> > infrastructure, and unpleasantly unfamiliar for many kernel and board
> > developers trying to work with DT schemas.
> >
> >
> > So, by way of investigation, let me propose an alternative expression
> > of schemas, that I'm also not convinced we should do, but is possible
> > and expressive.  It's illustrative, because it's kind of the polar
> > opposite approach to XSD: just use C.
> >
> > dtc already has a (so far limited) "checks" mechanism which verifies
> > various aspects of DT content.  These are implemented by C functions
> > in checks.c.  There's obviously ample expressiveness - you can express
> > any constraint you want that way.  It can be pretty verbose, and
> > fiddly.  A good library of helper functions can mitigate that, but
> > it's not clear how much.  On the other hand, a very good fraction of
> > people working with this will already be familiar with C, which is a
> > big plus.  This is, after all, the reason that the dts syntax is
> > chiefly C inspired.
> >
> > Now, in practice, I think we will want a more convenient schema
> > language (just as we wanted dts, rather than manually constructing
> > FDTs as C structures).  But I absolutely do think, that the schema
> > handling should be handled as plugins to the checks mechanism -
> > basically we'd have a validate_schemas() check function.
> >
> > I also think we should consider the option of having a simple and
> > straightforward schema language which handles, say, 80% of cases with
> > a fall back to C for the 20% of curly cases.  That might actually be
> > simpler to work with in practice than a schema language which can
> > express absolutely anything, at the cost of being awkward for simple
> > cases or difficult to get your head around.
> 
> Would C++ work? You can use operating overloading and templates to
> change the syntax into something that doesn't even resemble C any
> more.

Well, in theory.  But given that dtc and the kernel are both in plain
C, I don't think it's a good idea.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130730/ea6e26b9/attachment.sig>

From gang.chen at asianux.com  Tue Jul 30 00:07:58 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Tue, 30 Jul 2013 12:07:58 +0800
Subject: [PATCH] ARM(64): KVM: add signed type cast for comparation
In-Reply-To: <20130730034531.GC5471@cbox>
References: <51ECA4EC.3000408@asianux.com> <20130730034531.GC5471@cbox>
Message-ID: <51F73C1E.2030505@asianux.com>

On 07/30/2013 11:45 AM, Christoffer Dall wrote:
> On Mon, Jul 22, 2013 at 11:20:12AM +0800, Chen Gang wrote:
>> 'len' is 'unsigned long' which is never less than zero.
>>
>> So need a related type cast for comparation.
>>
>> The related warning (when building ARM64 with allmodconfig):
>>
>>   arch/arm64/kvm/../../../arch/arm/kvm/mmio.c:82:2: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
>>
> 
> Hmmm, interesting, I don't get this error with my compiler.
> 
>>
>> Signed-off-by: Chen Gang <gang.chen at asianux.com>
>> ---
>>  arch/arm/kvm/mmio.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
>> index b8e06b7..626dfc8 100644
>> --- a/arch/arm/kvm/mmio.c
>> +++ b/arch/arm/kvm/mmio.c
>> @@ -79,7 +79,7 @@ static int decode_hsr(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>  	}
>>  
>>  	len = kvm_vcpu_dabt_get_as(vcpu);
>> -	if (unlikely(len < 0))
>> +	if (unlikely((long)len < 0))
>>  		return len;
>>  
>>  	is_write = kvm_vcpu_dabt_iswrite(vcpu);
>> -- 
>> 1.7.7.6
> 
> I think the proper fix is to declare len as an int instead.  I'll queue
> that instead.
> 

Yeah, it is fine to me (better than my original fix).

Thanks.
-- 
Chen Gang


From kgene.kim at samsung.com  Tue Jul 30 00:27:57 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 30 Jul 2013 13:27:57 +0900
Subject: [PATCH] ARM: SAMSUNG: fix to support for missing cpu specific map_io
Message-ID: <190501ce8cdd$2abd6780$80383680$%kim@samsung.com>


Since commit 7ed76e08 (ARM: EXYNOS: Fix low level debug support)
map_io() is not needed for exynos5440 so need to fix to lookup
cpu which using map_io(). Without this, kernel boot log complains
'CPU EXYNOS5440 support not enabled' on exynos5440 and panic().

Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
---
 arch/arm/plat-samsung/init.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-samsung/init.c b/arch/arm/plat-samsung/init.c
index 3e5c461..50a3ea0 100644
--- a/arch/arm/plat-samsung/init.c
+++ b/arch/arm/plat-samsung/init.c
@@ -55,12 +55,13 @@ void __init s3c_init_cpu(unsigned long idcode,
 
 	printk("CPU %s (id 0x%08lx)\n", cpu->name, idcode);
 
-	if (cpu->map_io == NULL || cpu->init == NULL) {
+	if (cpu->init == NULL) {
 		printk(KERN_ERR "CPU %s support not enabled\n", cpu->name);
 		panic("Unsupported Samsung CPU");
 	}
 
-	cpu->map_io();
+	if (cpu->map_io)
+		cpu->map_io();
 }
 
 /* s3c24xx_init_clocks
-- 
1.7.10.4



From kgene.kim at samsung.com  Tue Jul 30 00:29:04 2013
From: kgene.kim at samsung.com (Kukjin Kim)
Date: Tue, 30 Jul 2013 13:29:04 +0900
Subject: [PATCH] ARM: exynos5440_defconfig: add defconfig for EXYNOS5440
Message-ID: <190601ce8cdd$52f0b1d0$f8d21570$%kim@samsung.com>


Since current exynos_defconfig cannot support for EXYNOS5440 because
of LPAE, there were discussions about that in mailing list. So this
adds initial defconfig which is tested on SSDK5440 and SD5v1 for
LPAE enabled EXYNOS5440. This defconfig enables ARCH_EXYNOS, ARM_LPAE,
PCI, CPU_FREQ

Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
---
 arch/arm/configs/exynos5440_defconfig |  138 +++++++++++++++++++++++++++++++++
 1 file changed, 138 insertions(+)
 create mode 100644 arch/arm/configs/exynos5440_defconfig

diff --git a/arch/arm/configs/exynos5440_defconfig b/arch/arm/configs/exynos5440_defconfig
new file mode 100644
index 0000000..53daf04
--- /dev/null
+++ b/arch/arm/configs/exynos5440_defconfig
@@ -0,0 +1,138 @@
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_PERF_EVENTS=y
+CONFIG_MODULES=y
+CONFIG_MODULE_FORCE_LOAD=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_ARCH_EXYNOS=y
+# CONFIG_ARCH_EXYNOS4 is not set
+CONFIG_ARCH_EXYNOS5=y
+# CONFIG_SOC_EXYNOS5250 is not set
+CONFIG_ARM_LPAE=y
+CONFIG_PCI=y
+CONFIG_PCI_EXYNOS=y
+CONFIG_SMP=y
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+CONFIG_HIGHMEM=y
+CONFIG_TRANSPARENT_HUGEPAGE=y
+CONFIG_CMDLINE="root=/dev/sda2 rw rootwait ignore_loglevel early_printk no_console_suspend mem=2048M at 0x80000000
mem=6144M at 0x100000000 console=ttySAC0,115200"
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPU_FREQ_GOV_POWERSAVE=y
+CONFIG_CPU_FREQ_GOV_USERSPACE=y
+CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
+CONFIG_CPU_IDLE=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+CONFIG_PM_AUTOSLEEP=y
+CONFIG_PM_WAKELOCKS=y
+CONFIG_PM_DEBUG=y
+CONFIG_PM_ADVANCED_DEBUG=y
+CONFIG_PM_TEST_SUSPEND=y
+CONFIG_APM_EMULATION=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_NET_KEY=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_RARP=y
+CONFIG_IPV6=y
+CONFIG_RFKILL_REGULATOR=y
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_MTD=y
+CONFIG_MTD_M25P80=y
+# CONFIG_M25PXX_USE_FAST_READ is not set
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=10240
+CONFIG_BLK_DEV_SD=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_ATA=y
+CONFIG_SATA_AHCI_PLATFORM=y
+# CONFIG_ATA_SFF is not set
+CONFIG_NETDEVICES=y
+CONFIG_SMSC911X=y
+CONFIG_STMMAC_ETH=y
+CONFIG_STMMAC_DA=y
+CONFIG_MARVELL_PHY=y
+CONFIG_FIXED_PHY=y
+CONFIG_USB_USBNET=y
+CONFIG_USB_NET_SMSC75XX=y
+CONFIG_USB_NET_SMSC95XX=y
+CONFIG_INPUT_EVDEV=y
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_SAMSUNG=y
+CONFIG_SERIAL_SAMSUNG_CONSOLE=y
+CONFIG_HW_RANDOM=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_S3C2410=y
+CONFIG_SPI=y
+CONFIG_SPI_S3C64XX=y
+# CONFIG_HWMON is not set
+CONFIG_THERMAL=y
+CONFIG_CPU_THERMAL=y
+CONFIG_THERMAL_EMULATION=y
+CONFIG_EXYNOS_THERMAL=y
+CONFIG_EXYNOS_THERMAL_CORE=y
+CONFIG_WATCHDOG=y
+CONFIG_S3C2410_WATCHDOG=y
+CONFIG_MFD_TPS65090=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_GPIO=y
+CONFIG_REGULATOR_TPS65090=y
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_S5P=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_EXYNOS=y
+CONFIG_USB_STORAGE=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_S3C=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+CONFIG_EXT4_FS=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_HUGETLBFS=y
+CONFIG_CRAMFS=y
+CONFIG_ROMFS_FS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ASCII=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_INFO=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_KERNEL=y
+CONFIG_DETECT_HUNG_TASK=y
+CONFIG_DEBUG_RT_MUTEXES=y
+CONFIG_DEBUG_SPINLOCK=y
+CONFIG_DEBUG_MUTEXES=y
+CONFIG_DEBUG_USER=y
+CONFIG_DEBUG_LL=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_CRYPTO_ANSI_CPRNG=y
+CONFIG_CRC_CCITT=y
+CONFIG_VIRTUALIZATION=y
+CONFIG_KVM=y
-- 
1.7.10.4



From grant.likely at linaro.org  Tue Jul 30 00:30:23 2013
From: grant.likely at linaro.org (Grant Likely)
Date: Mon, 29 Jul 2013 22:30:23 -0600
Subject: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
In-Reply-To: <1375101368-17645-1-git-send-email-linus.walleij@linaro.org>
References: <1375101368-17645-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <CACxGe6uNJNMdZ1HYGgCtLM2t2TWGCR6btjOHVmP=vDXXvvFfRg@mail.gmail.com>

On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij <linus.walleij at linaro.org> wrote:
> To solve this dilemma, perform an interrupt consistency check
> when adding a GPIO chip: if the chip is both gpio-controller and
> interrupt-controller, walk all children of the device tree,
> check if these in turn reference the interrupt-controller, and
> if they do, loop over the interrupts used by that child and
> perform gpio_reques() and gpio_direction_input() on these,
> making them unreachable from the GPIO side.

Ugh, that's pretty awful, and it doesn't actually solve the root
problem of the GPIO and IRQ subsystems not cooperating. It's also a
very DT-centric solution even though we're going to see the exact same
issue on ACPI machines.

We have to solve the problem in a better way than that. Rearranging
your patch description, here are some of the points you brought up so
I can comment on them...

> This has the following undesired effects:
>
> - The GPIOlib subsystem is not aware that the line is in use
>   and willingly lets some other consumer perform gpio_request()
>   on it, leading to a complex resource conflict if it occurs.

If a gpio line is being both requested as a gpio and used as an
interrupt line, then either a) it's a bug, or b) the gpio line needs
to be used as input only so it is compatible with irq usage. b) should
be supportable.

> - The GPIO debugfs file claims this GPIO line is "free".

Surely we can fix this. I still don't see a problem of having the
controller request the gpio when it is claimed as an irq if we can get
around the problem of another user performing a /valid/ request on the
same GPIO line. The solution may be to have a special form of request
or flag that allows it to be shared.

> - The line direction of the interrupt GPIO line is not
>   explicitly set as input, even though it is obvious that such
>   a line need to be set up in this way, often making the system
>   depend on boot-on defaults for this kind of settings.

Should also be solvable if the gpio request problem is solved.

g.


From horms at verge.net.au  Tue Jul 30 00:31:04 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 13:31:04 +0900
Subject: [PATCH v3 0/4] ARM: shmobile: marzen: Switch to DT_MACHINE_START
In-Reply-To: <CANqRtoQy91tKZP2mUYAGeqegWcEzvk81EbZ6=gzxvefKcBaZyg@mail.gmail.com>
References: <1374799913-27461-1-git-send-email-horms+renesas@verge.net.au>
 <20130730022703.GE31526@verge.net.au>
 <CANqRtoQy91tKZP2mUYAGeqegWcEzvk81EbZ6=gzxvefKcBaZyg@mail.gmail.com>
Message-ID: <20130730043103.GE5595@verge.net.au>

On Tue, Jul 30, 2013 at 12:53:53PM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Tue, Jul 30, 2013 at 11:27 AM, Simon Horman <horms at verge.net.au> wrote:
> > On Fri, Jul 26, 2013 at 09:51:49AM +0900, Simon Horman wrote:
> >> A short series to use DT_MACHINE_START on the marzen board.
> >
> > Magnus, could you find a few moments to review this series?
> 
> These are fine with me, thanks for your help!
> 
> Acked-by: Magnus Damm <damm at opensource.se>

Thanks, I have queued them up for v3.12.


From grant.likely at secretlab.ca  Tue Jul 30 00:35:03 2013
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 29 Jul 2013 22:35:03 -0600
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130730032926.GL29970@voom.fritz.box>
References: <51F39FD8.6080808@broadcom.com> <2460092.aLmjrOVh1g@flatron>
 <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
 <CACxGe6uE6jOE-vz0onW5h93Es-soGiBAcFBM7Dvxh+HvCNrHkw@mail.gmail.com>
 <CACxGe6vw9=y5a+EgF1gO39SwGAdGofD2MYjyJ3jYu6uN3ke70A@mail.gmail.com>
 <1374988276.1973.29.camel@dabdike> <20130730014453.GJ29970@voom.fritz.box>
 <CAKON4OyWuF+qm2MAhbXnGg=ozzw37kpSWciLxyUy+QQzxoWdxQ@mail.gmail.com>
 <20130730032926.GL29970@voom.fritz.box>
Message-ID: <CACxGe6sUFmLZMT+dvCbpmPrzR3DNMjw64LbD3n=JsjXsmrM-qg@mail.gmail.com>

On Mon, Jul 29, 2013 at 1:31 AM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Hi,
>
> On Sun, Jul 28, 2013 at 03:19:03PM +0200, Richard Cochran wrote:
>> On Sun, Jul 28, 2013 at 11:12:53AM +0200, Tomasz Figa wrote:
>>
>> > I'm not really sure what effect on users this has. Maybe you should define
>> > "users".
>>
>> ...
>>
>> > Care to explain this reasoning?
>>
>> Use Case
>> ~~~~~~~~
>>
>> User acquires a machine running ARM Linux version 3.x, with u-boot
>> and dtb in a read only flash partition. The board boots and works just
>> fine. However, for his application, the user requires a new kernel
>> feature that appeared in version 3.y where y > x. He compiles the new
>> kernel, and it also works.
>
> I'm afraid this kind of use case will never be properly supported, DT
> stable ABI or not.

Why? New kernel features should be no problem at all.

New driver features /might/ not be available, but only if the new
feature requires additional data that isn't present in the tree and
cannot be obtained elsewhere.

>
> Think about this: what kernel will actually be shipped in that board?
> Most likely, it will be a BSP kernel from the vendor. Does the vendor
> will have made that commitment to have a stable ABI for the DT? Will it
> use the same bindings than mainline? Do we want to support all the crazy
> bindings every vendor will come up with?

That's not a DT issue. That an out-of-tree board/SoC support issue. DT
doesn't make that any better or worse.

g.


From sachin.kamat at linaro.org  Tue Jul 30 00:38:26 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Tue, 30 Jul 2013 10:08:26 +0530
Subject: [PATCH] ARM: SAMSUNG: fix to support for missing cpu specific
 map_io
In-Reply-To: <190501ce8cdd$2abd6780$80383680$%kim@samsung.com>
References: <190501ce8cdd$2abd6780$80383680$%kim@samsung.com>
Message-ID: <CAK9yfHwMANp2TfQWHQVXGZ2C-t-KrwGHJOpFT+hedDFYTDng6Q@mail.gmail.com>

On 30 July 2013 09:57, Kukjin Kim <kgene.kim at samsung.com> wrote:
>
> Since commit 7ed76e08 (ARM: EXYNOS: Fix low level debug support)
> map_io() is not needed for exynos5440 so need to fix to lookup
> cpu which using map_io(). Without this, kernel boot log complains
> 'CPU EXYNOS5440 support not enabled' on exynos5440 and panic().
>
> Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
> ---
>  arch/arm/plat-samsung/init.c |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/init.c b/arch/arm/plat-samsung/init.c
> index 3e5c461..50a3ea0 100644
> --- a/arch/arm/plat-samsung/init.c
> +++ b/arch/arm/plat-samsung/init.c
> @@ -55,12 +55,13 @@ void __init s3c_init_cpu(unsigned long idcode,
>
>         printk("CPU %s (id 0x%08lx)\n", cpu->name, idcode);
>
> -       if (cpu->map_io == NULL || cpu->init == NULL) {
> +       if (cpu->init == NULL) {
>                 printk(KERN_ERR "CPU %s support not enabled\n", cpu->name);
>                 panic("Unsupported Samsung CPU");

While at it you could probably remove the printk and have that message
printed by panic instead?

-- 
With warm regards,
Sachin


From joelf at ti.com  Mon Jul 29 23:47:04 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 29 Jul 2013 22:47:04 -0500
Subject: [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA
 resources
In-Reply-To: <51F61359.1090309@ti.com>
References: <1374515989-7391-1-git-send-email-joelf@ti.com>
 <51F61359.1090309@ti.com>
Message-ID: <51F73738.6080901@ti.com>

On 07/29/2013 02:01 AM, Sekhar Nori wrote:> On Monday 22 July 2013 11:29
PM, Joel Fernandes wrote:
>> HWMOD removal for MMC is breaking edma_start as the events are being
manually
>> triggered due to unused channel list not being clear, Thanks to
Balaji TK for
>> finding this issue.
>
> So, Reported-by: Balaji T K <balajitk at ti.com>
>
> ?

Sure, I'll add that as well.

>
>>
>> This patch fixes the issue, by reading the "dmas" property from the
DT node if
>> it exists and clearing the bits in the unused channel list.
>>
>> Cc: Balaji T K <balajitk at ti.com>
>> Cc: Pantel Antoniou <panto at antoniou-consulting.com>
>> Signed-off-by: Joel Fernandes <joelf at ti.com>
>> ---
>> v2 changes: Fixed compiler warning
>>
>>  arch/arm/common/edma.c |   31 +++++++++++++++++++++++--------
>>  1 file changed, 23 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
>> index a432e6c..765d578 100644
>> --- a/arch/arm/common/edma.c
>> +++ b/arch/arm/common/edma.c
>> @@ -561,14 +561,29 @@ static int reserve_contiguous_slots(int ctlr,
unsigned int id,
>>  static int prepare_unused_channel_list(struct device *dev, void *data)
>>  {
>>  	struct platform_device *pdev = to_platform_device(dev);
>> -	int i, ctlr;
>> -
>> -	for (i = 0; i < pdev->num_resources; i++) {
>> -		if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
>> -				(int)pdev->resource[i].start >= 0) {
>> -			ctlr = EDMA_CTLR(pdev->resource[i].start);
>> -			clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
>> -					edma_cc[ctlr]->edma_unused);
>> +	int i = 0, ctlr;
>> +	u32 dma_chan;
>> +	const __be32 *dma_chan_p;
>> +	struct property *prop;
>> +
>> +	if (dev->of_node) {
>> +		of_property_for_each_u32(dev->of_node, "dmas", prop, \
>> +					 dma_chan_p, dma_chan) {
>> +			if (i++ & 1) {
>> +				ctlr = EDMA_CTLR(dma_chan);
>> +				clear_bit(EDMA_CHAN_SLOT(dma_chan),
>> +						edma_cc[ctlr]->edma_unused);
>> +			}
>
> I think it will be cleaner if you use of_property_count_strings() on
> dma-names to get the count of DMA channels for this device and then use
> of_parse_phandle_with_args() to get access to the args. Honestly, I have
> not used these APIs myself, so if this doesn?t work the way I think it
> should then let me know and I will try to do some experiments myself.
>
> The current way of skipping over even fields really depends on
> #dma-cells for EDMA to be 1. That in itself is not such a bad
> assumption, but if you have APIs which already take care of this for
> you, why not use them?

Sure, looks like of_dma_request_slave_channel does same thing in
drive/dma/of-dma.c. Let me follow up with a patch that does it this way.
I agree its cleaner.

>> +		}
>> +	} else {
>> +		for (; i < pdev->num_resources; i++) {
>> +			if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
>> +			    (int)pdev->resource[i].start >= 0) {
>> +				ctlr = EDMA_CTLR(pdev->resource[i].start);
>> +				clear_bit(EDMA_CHAN_SLOT(
>> +					  pdev->resource[i].start),
>> +					  edma_cc[ctlr]->edma_unused);
>> +			}
>
> So there is very little in common between OF and non-OF versions of this
> function. Why not have two different versions of this function for the
> two cases? The OF version can reside under the CONFIG_OF conditional
> already in use in the file. This will also save you the ugly line breaks
> you had to resort to due to too deep indentation.

Actually those line breaks are not necessary and wouldn't result in
compilation errors. I was planning to drop them. I'll go ahead and split
it out anyway, now that also the OF version of the function is going to
be bit longer if we use the of_parse functions.

Thanks for your review,

Regards,

-Joel


From joelf at ti.com  Mon Jul 29 23:53:35 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 29 Jul 2013 22:53:35 -0500
Subject: [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA
 resources
In-Reply-To: <51F6140B.3070600@ti.com>
References: <1374515989-7391-1-git-send-email-joelf@ti.com>
 <51F4589E.5070108@ti.com> <51F6140B.3070600@ti.com>
Message-ID: <51F738BF.7070808@ti.com>

On 07/29/2013 02:04 AM, Sekhar Nori wrote:
> On Sunday 28 July 2013 05:02 AM, Joel Fernandes wrote:
>> Hi Tony or Sekhar,
>>
>> If this patch looks ok, could you pick it up for -rc cycle?
>>
>> It fixes DMA breakages after the merge window for devices for which DMA
>> resources are being populated in device tree instead pdev.
> 
> But which DT-enabled platform in kernel is using EDMA? A grep for edma
> over arch/arm/boot/dts/* brings up nothing.
> Does this really have to go into the -rc cycle or can it wait till
> v3.12?


But unused channel list is also populated for private EDMA callers like
davinci-pcm no? IIRC, HWMOD data is also removed for McASP so EDMA for
those may break.

Thanks,

-Joel


From joelf at ti.com  Tue Jul 30 00:39:21 2013
From: joelf at ti.com (Joel Fernandes)
Date: Mon, 29 Jul 2013 23:39:21 -0500
Subject: [PATCH] dma: edma: add device_slave_caps() support
In-Reply-To: <20130729094557.GG29095@intel.com>
References: <1374597804-3961-1-git-send-email-joelf@ti.com>
 <51EF8A52.90902@metafoo.de> <51EF8C2B.2030409@ti.com>
 <51EF8F4E.8080806@metafoo.de> <FB20353E-4890-4462-A671-3587A3841B4A@ti.com>
 <51EF92F2.3030405@metafoo.de> <51F0231C.7000401@ti.com>
 <20130724183329.GH18642@intel.com> <51F02CBA.5060704@ti.com>
 <20130725072351.GJ18642@intel.com> <20130729094557.GG29095@intel.com>
Message-ID: <51F74379.3050809@ti.com>

Hi Vinod,

On 07/29/2013 04:45 AM, Vinod Koul wrote:
> On Thu, Jul 25, 2013 at 12:53:51PM +0530, Vinod Koul wrote:
>> On Wed, Jul 24, 2013 at 02:36:26PM -0500, Joel Fernandes wrote:
>>>> Also another point worth considering is the approach Russell suggested, I havent
>>>> gotten a chance to dig deeper but if I understood it correctly then programming
>>>> the device_dma_parameters should be the right thing to do. Again I need to look
>>>> deeper and esp wrt edma
>>>
>>> OK. I have some patches sitting in my tree too that I'm working on. With
>>> that I don't need to know about maximum number of allowed segments and
>>> can send along any number of segment. I will rework them and post them.
>>> fwiw, I will also implement caps API incase like Lars did populating the
>>> other fields though these will not be unused.
>>>
>>> For segment size, at this time I don't know any driver that uses it
>>> other than davinci-pcm. For this reason the calculations can be done as
>>> Lars suggested (for minimum of maximum). Do you know in advance if
>>> you're going to amend to drop segment size if we go with what Russell
>>> suggested, or are you going to leave the seg-size in the caps API anyway.
>> I am just back and havent really done my work on this. Let me check and as I
>> said if my understanding is right I would be inclined to remove these fields...
> Okay so the max sg_len should be done by setting the device_dma_parameters.
> 
> See the example in MXS DMA and MMC drivers

Ah, I see those examples. Thanks.

> 
> Now for second parameter why do you need that to be passed, I thought in edma the
> clients needs this value somehow to program the channel. It would be good that
> if we can delink from this and let edma derive.

Do you mean the burst width and device width parameters?

On second thought, I am thinking do we really need to set this
particular parameter if we can rearchitect the driver a bit. EDMA
theoretically can transmit very large segment sizes. There are 3
internal counters (ACNT, BCNT, CCNT) that are 16-bit, total size is
quite large (product of counters).

EDMA driver however currently assumes that ACNT is device width and BCNT
is max burst in units of device width. These parameters are again client
configured so these have to be passed to the EDMA driver by
configuration or passed through API to calculate maximum segment size.
This is required because client may be unaware that CCNT is only 16 bit,
so following calculation is being done in the SG segment size patch:

<snip>
+*edma_get_slave_sg_limits(struct dma_chan *chan,
+			enum dma_slave_buswidth addr_width,
+			u32 maxburst)
+{
[..]
+	echan->sg_limits.max_seg_len =
+		(SZ_64K - 1) * addr_width * maxburst;
</snip>


The other down side of assigning ACNT device width and BCNT as burst
size it seems to be wasteful of the range allowed by 16-bit width.
I am thinking if we can break free from these assumptions, then we can
transmit segments of literally any length and not have to set any
segment size limits at all. I'll try to work on some patches to see if
we can overcome segment size limits.

> Also there should be no such thing as max_sg, the driver should be able to
> perform any size of sg_list. Internally it can be breaking the dma
> into multiple trasnactions.

Sure, I just submitted a patch series that does exactly that:
http://marc.info/?l=linux-omap&m=137510483230005&w=2

Thanks,

-Joel



From nsekhar at ti.com  Tue Jul 30 00:52:24 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 30 Jul 2013 10:22:24 +0530
Subject: [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA
 resources
In-Reply-To: <51F738BF.7070808@ti.com>
References: <1374515989-7391-1-git-send-email-joelf@ti.com>
 <51F4589E.5070108@ti.com> <51F6140B.3070600@ti.com> <51F738BF.7070808@ti.com>
Message-ID: <51F74688.3090702@ti.com>

On Tuesday 30 July 2013 09:23 AM, Joel Fernandes wrote:
> On 07/29/2013 02:04 AM, Sekhar Nori wrote:
>> On Sunday 28 July 2013 05:02 AM, Joel Fernandes wrote:
>>> Hi Tony or Sekhar,
>>>
>>> If this patch looks ok, could you pick it up for -rc cycle?
>>>
>>> It fixes DMA breakages after the merge window for devices for which DMA
>>> resources are being populated in device tree instead pdev.
>>
>> But which DT-enabled platform in kernel is using EDMA? A grep for edma
>> over arch/arm/boot/dts/* brings up nothing.
>> Does this really have to go into the -rc cycle or can it wait till
>> v3.12?
> 
> 
> But unused channel list is also populated for private EDMA callers like
> davinci-pcm no? IIRC, HWMOD data is also removed for McASP so EDMA for
> those may break.

Yes, but which DT-enabled platform has davinci-pcm working today?
AFAICS, this bug affects DT-enabled platforms only.

Thanks,
Sekhar


From hdoyu at nvidia.com  Tue Jul 30 00:56:55 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Tue, 30 Jul 2013 07:56:55 +0300
Subject: [PATCH v2 03/22] ARM: tegra: Create a DT header defining
 swgroups ID
In-Reply-To: <51F6AA2B.7050509@wwwdotorg.org>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-4-git-send-email-hdoyu@nvidia.com>
 <51E5D220.1070708@wwwdotorg.org>
 <20130729.135336.943359637886118972.hdoyu@nvidia.com>
 <51F6AA2B.7050509@wwwdotorg.org>
Message-ID: <20130730075655.b488047ac938342df3c90fa1@nvidia.com>

On Mon, 29 Jul 2013 19:45:15 +0200
Stephen Warren <swarren at wwwdotorg.org> wrote:

> On 07/29/2013 04:53 AM, Hiroshi Doyu wrote:
> > Stephen Warren <swarren at wwwdotorg.org> wrote @ Wed, 17 Jul 2013 01:07:12 +0200:
> > 
> >> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> >>> Create a header file to define the swgroup IDs used by the IOMMU(SMMU)
> >>> binding. "swgroup" is a group of H/W clients in Tegra SoC from S/W POV.
> >>>
> >>> This will allow the same header to be used by both device tree files,
> >>> and drivers implementing this binding, which guarantees that the two
> >>> stay in sync. This also makes device trees more readable by using names
> >>> instead of magic numbers.
> >>
> >> Why does the driver need these constants; shouldn't it simply support
> >> 0..n SW group IDs that all work the same way? Or, is there some reason
> >> for it to know the identities?
> >>
> >>> diff --git a/include/dt-bindings/memory/tegra-swgroup.h b/include/dt-bindings/memory/tegra-swgroup.h
> >>
> >> s/memory/iommu/?
> > 
> > This info would be used in PMC code as well, which H/W belongs to
> > which swgroup. So I use the term "memory(-client)" instead of "iommu".
> 
> Why does the PMC care? An explanation of exactly what SW needs to know
> about these groups and why would be a good idea.

Joseph, can you explain a bit here?


From joelf at ti.com  Tue Jul 30 01:05:25 2013
From: joelf at ti.com (Joel Fernandes)
Date: Tue, 30 Jul 2013 00:05:25 -0500
Subject: [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA
 resources
In-Reply-To: <51F74688.3090702@ti.com>
References: <1374515989-7391-1-git-send-email-joelf@ti.com>
 <51F4589E.5070108@ti.com> <51F6140B.3070600@ti.com> <51F738BF.7070808@ti.com>
 <51F74688.3090702@ti.com>
Message-ID: <51F74995.2050202@ti.com>

On 07/29/2013 11:52 PM, Sekhar Nori wrote:> On Tuesday 30 July 2013
09:23 AM, Joel Fernandes wrote:
>> On 07/29/2013 02:04 AM, Sekhar Nori wrote:
>>> On Sunday 28 July 2013 05:02 AM, Joel Fernandes wrote:
>>>> Hi Tony or Sekhar,
>>>>
>>>> If this patch looks ok, could you pick it up for -rc cycle?
>>>>
>>>> It fixes DMA breakages after the merge window for devices for which DMA
>>>> resources are being populated in device tree instead pdev.
>>>
>>> But which DT-enabled platform in kernel is using EDMA? A grep for edma
>>> over arch/arm/boot/dts/* brings up nothing.
>>> Does this really have to go into the -rc cycle or can it wait till
>>> v3.12?
>>
>>
>> But unused channel list is also populated for private EDMA callers like
>> davinci-pcm no? IIRC, HWMOD data is also removed for McASP so EDMA for
>> those may break.
>
> Yes, but which DT-enabled platform has davinci-pcm working today?
> AFAICS, this bug affects DT-enabled platforms only.

Yes, you're right. I didn't realize nothing else is working yet. I guess
its fine then for next kernel release.

Thanks,

-Joel


From gururaja.hebbar at ti.com  Tue Jul 30 01:05:52 2013
From: gururaja.hebbar at ti.com (Gururaja Hebbar)
Date: Tue, 30 Jul 2013 10:35:52 +0530
Subject: [Patch V2 4/4] ARM: dts: AM33XX: update rtc node compatibility
In-Reply-To: <1372841225-18813-5-git-send-email-gururaja.hebbar@ti.com>
References: <1372841225-18813-1-git-send-email-gururaja.hebbar@ti.com>
 <1372841225-18813-5-git-send-email-gururaja.hebbar@ti.com>
Message-ID: <51F749B0.7020802@ti.com>

Hi,

On 7/3/2013 2:17 PM, Hebbar Gururaja wrote:
> Since AM33xx  RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
>
> Update the rtc compatible property to "ti,am3352-rtc" to enable handling
> of this feature inside rtc-omap driver.

The other 2 rtc driver related patches have been pulled up. If you have 
no comments, can you please pull this up.

Regards
Gururaja

>
> Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> ---
> :100644 100644 77aa1b0... dde180a... M	arch/arm/boot/dts/am33xx.dtsi
>   arch/arm/boot/dts/am33xx.dtsi |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 77aa1b0..dde180a 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -297,7 +297,7 @@
>   		};
>
>   		rtc at 44e3e000 {
> -			compatible = "ti,da830-rtc";
> +			compatible = "ti,am3352-rtc";
>   			reg = <0x44e3e000 0x1000>;
>   			interrupts = <75
>   				      76>;
>



From hdoyu at nvidia.com  Tue Jul 30 01:11:19 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Tue, 30 Jul 2013 08:11:19 +0300
Subject: [PATCH v2 05/22] ARM: dt: tegra30: iommu: Add
 "nvidia,memory-client"
In-Reply-To: <51F6AA98.4020701@wwwdotorg.org>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-6-git-send-email-hdoyu@nvidia.com>
 <51E5D3D9.2090608@wwwdotorg.org>
 <20130729.140646.649065361266278007.hdoyu@nvidia.com>
 <51F6AA98.4020701@wwwdotorg.org>
Message-ID: <20130730081119.71de9d10e08307cdaca62fe3@nvidia.com>

On Mon, 29 Jul 2013 19:47:04 +0200
Stephen Warren <swarren at wwwdotorg.org> wrote:

> On 07/29/2013 05:06 AM, Hiroshi Doyu wrote:
> > Stephen Warren <swarren at wwwdotorg.org> wrote @ Wed, 17 Jul 2013 01:14:33 +0200:
> > 
> >> On 07/05/2013 04:44 AM, Hiroshi Doyu wrote:
> >>> Add "nvidia,memory-client" to identify which swgroup ID a device
> >>> belongs to.
> >>
> >> This property also isn't in the documentation.
> >>
> >> Again, if client devices are required to have this new property, the DT
> >> isn't backwards-compatible; fail:-(
> > 
> > If there's no this property, just falling back to use the system
> > default address space. I think that this won't break the
> > compatibility basically. Only problem may be the inconsistency of
> > setting this property among the HWs in the same group.
> 
> When you say "group" there, what kind of group? I thought that each HW
> module had its own "SWGROUP ID", and hence there are no "HWs in the same
> group"?

A "swgroup" can have multiple HWs. So there are 3 concept here.

swgroup: one client to issue request from MC perspective
HW: swgroup can have multiple HWs(real H/W units)
device driver: Can have multiple swgroups.


From kishon at ti.com  Tue Jul 30 01:12:00 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 30 Jul 2013 10:42:00 +0530
Subject: [RESEND PATCH v10 1/8] drivers: phy: add generic PHY framework
In-Reply-To: <51F68F73.9060603@samsung.com>
References: <1374842963-13545-1-git-send-email-kishon@ti.com>
 <1374842963-13545-2-git-send-email-kishon@ti.com>
 <51F68F73.9060603@samsung.com>
Message-ID: <51F74B20.6070005@ti.com>

Hi,

On Monday 29 July 2013 09:21 PM, Sylwester Nawrocki wrote:
> On 07/26/2013 02:49 PM, Kishon Vijay Abraham I wrote:
>> The PHY framework provides a set of APIs for the PHY drivers to
>> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
>> PHY with or without using phandle. For dt-boot, the PHY drivers should
>> also register *PHY provider* with the framework.
>>
>> PHY drivers should create the PHY by passing id and ops like init, exit,
>> power_on and power_off. This framework is also pm runtime enabled.
>>
>> The documentation for the generic PHY framework is added in
>> Documentation/phy.txt and the documentation for dt binding can be found at
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> Cc: Tomasz Figa <t.figa at samsung.com>
>> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
>> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
>> Acked-by: Felipe Balbi <balbi at ti.com>
>> Tested-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
>> ---
>>  .../devicetree/bindings/phy/phy-bindings.txt       |   66 ++
>>  Documentation/phy.txt                              |  166 +++++
>>  MAINTAINERS                                        |    8 +
>>  drivers/Kconfig                                    |    2 +
>>  drivers/Makefile                                   |    2 +
>>  drivers/phy/Kconfig                                |   18 +
>>  drivers/phy/Makefile                               |    5 +
>>  drivers/phy/phy-core.c                             |  714 ++++++++++++++++++++
>>  include/linux/phy/phy.h                            |  270 ++++++++
>>  9 files changed, 1251 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
>>  create mode 100644 Documentation/phy.txt
>>  create mode 100644 drivers/phy/Kconfig
>>  create mode 100644 drivers/phy/Makefile
>>  create mode 100644 drivers/phy/phy-core.c
>>  create mode 100644 include/linux/phy/phy.h
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
>> new file mode 100644
>> index 0000000..8ae844f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
>> @@ -0,0 +1,66 @@
>> +This document explains only the device tree data binding. For general
>> +information about PHY subsystem refer to Documentation/phy.txt
> [...]
>> @@ -0,0 +1,166 @@
>> +			    PHY SUBSYSTEM
>> +		  Kishon Vijay Abraham I <kishon at ti.com>
>> +
>> +This document explains the Generic PHY Framework along with the APIs provided,
>> +and how-to-use.
>> +
>> +1. Introduction
>> +
>> +*PHY* is the abbreviation for physical layer. It is used to connect a device
>> +to the physical medium e.g., the USB controller has a PHY to provide functions
>> +such as serialization, de-serialization, encoding, decoding and is responsible
>> +for obtaining the required data transmission rate. Note that some USB
>> +controllers have PHY functionality embedded into it and others use an external
>> +PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
>> +SATA etc.
>> +
>> +The intention of creating this framework is to bring the PHY drivers spread
>> +all over the Linux kernel to drivers/phy to increase code re-use and for
>> +better code maintainability.
>> +
>> +This framework will be of use only to devices that use external PHY (PHY
>> +functionality is not embedded within the controller).
>> +
>> +2. Registering/Unregistering the PHY provider
>> +
>> +PHY provider refers to an entity that implements one or more PHY instances.
>> +For the simple case where the PHY provider implements only a single instance of
>> +the PHY, the framework provides its own implementation of of_xlate in
>> +of_phy_simple_xlate. If the PHY provider implements multiple instances, it
>> +should provide its own implementation of of_xlate. of_xlate is used only for
>> +dt boot case.
>> +
>> +#define of_phy_provider_register(dev, xlate)    \
>> +        __of_phy_provider_register((dev), THIS_MODULE, (xlate))
>> +
>> +#define devm_of_phy_provider_register(dev, xlate)       \
>> +        __of_phy_provider_register((dev), THIS_MODULE, (xlate))
> 
> This needs to be:
> 
> 	__devm_of_phy_provider_register((dev), THIS_MODULE, (xlate))
> 
> as Kamil pointed out. We've tested it here with v9 and it makes
> Bad Things happen. ;)
> 
>> +of_phy_provider_register and devm_of_phy_provider_register macros can be used to
>> +register the phy_provider and it takes device and of_xlate as
>> +arguments. For the dt boot case, all PHY providers should use one of the above
>> +2 macros to register the PHY provider.
>> +
>> +void devm_of_phy_provider_unregister(struct device *dev,
>> +	struct phy_provider *phy_provider);
>> +void of_phy_provider_unregister(struct phy_provider *phy_provider);
>> +
>> +devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to
>> +unregister the PHY.
>> +
> [...]
>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>> new file mode 100644
>> index 0000000..f1d15e5
>> --- /dev/null
>> +++ b/drivers/phy/phy-core.c
>> @@ -0,0 +1,714 @@
> [...]
>> +static struct phy *phy_lookup(struct device *device, const char *port)
>> +{
>> +	unsigned int count;
>> +	struct phy *phy;
>> +	struct device *dev;
>> +	struct phy_consumer *consumers;
>> +	struct class_dev_iter iter;
> 	
> Don't you need something like
> 
> 	if (phy->init_data == NULL)	
> 		return ERR_PTR(-EINVAL);
> 
> to ensure there is no attempt to dereference NULL platform data ?

hmm.. perhaps a dev_WARN too..
> 
>> +	class_dev_iter_init(&iter, phy_class, NULL, NULL);
>> +	while ((dev = class_dev_iter_next(&iter))) {
>> +		phy = to_phy(dev);
>> +		count = phy->init_data->num_consumers;
>> +		consumers = phy->init_data->consumers;
>> +		while (count--) {
>> +			if (!strcmp(consumers->dev_name, dev_name(device)) &&
>> +					!strcmp(consumers->port, port)) {
>> +				class_dev_iter_exit(&iter);
>> +				return phy;
>> +			}
>> +			consumers++;
>> +		}
>> +	}
>> +
>> +	class_dev_iter_exit(&iter);
>> +	return ERR_PTR(-ENODEV);
>> +}
>> +
> [...]
>> +int phy_init(struct phy *phy)
>> +{
>> +	int ret;
>> +
>> +	ret = phy_pm_runtime_get_sync(phy);
>> +	if (ret < 0 && ret != -ENOTSUPP)
>> +		return ret;
>> +
>> +	mutex_lock(&phy->mutex);
>> +	if (phy->init_count++ == 0 && phy->ops->init) {
>> +		ret = phy->ops->init(phy);
>> +		if (ret < 0) {
>> +			dev_err(&phy->dev, "phy init failed --> %d\n", ret);
>> +			goto out;
> 
> Is this 'goto' and similar ones below really needed ?
That's just to signify an error path.. it doesn't affect anyways ;-)

Thanks
Kishon


From kishon at ti.com  Tue Jul 30 01:14:48 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 30 Jul 2013 10:44:48 +0530
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given
 in usb_bind_phy
In-Reply-To: <20130729175413.GC4964@radagast>
References: <1374829418-27503-1-git-send-email-kishon@ti.com>
 <1374829418-27503-3-git-send-email-kishon@ti.com>
 <20130729150638.GD3063@radagast> <51F68A56.8060805@ti.com>
 <20130729175413.GC4964@radagast>
Message-ID: <51F74BC8.7020903@ti.com>

Hi,

On Monday 29 July 2013 11:24 PM, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Jul 29, 2013 at 08:59:26PM +0530, Kishon Vijay Abraham I wrote:
>>>> Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while creating
>>>> MUSB core device. So in usb_bind_phy (binds the controller with the PHY), the
>>>> device name of the controller had *.auto* in it. Since with using
>>>> PLATFORM_DEVID_AUTO, there is no way to know the exact device name in advance,
>>>> the data given in usb_bind_phy became obsolete and usb_get_phy was failing.
>>>> So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO. Corresponding
>>>> change is done in board file here.
>>>>
>>>> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
>>>> ---
>>>>  arch/arm/mach-omap2/board-2430sdp.c          |    2 +-
>>>>  arch/arm/mach-omap2/board-3430sdp.c          |    2 +-
>>>>  arch/arm/mach-omap2/board-cm-t35.c           |    2 +-
>>>>  arch/arm/mach-omap2/board-devkit8000.c       |    2 +-
>>>>  arch/arm/mach-omap2/board-igep0020.c         |    2 +-
>>>>  arch/arm/mach-omap2/board-ldp.c              |    2 +-
>>>>  arch/arm/mach-omap2/board-omap3beagle.c      |    2 +-
>>>>  arch/arm/mach-omap2/board-omap3evm.c         |    2 +-
>>>>  arch/arm/mach-omap2/board-omap3logic.c       |    2 +-
>>>>  arch/arm/mach-omap2/board-omap3pandora.c     |    2 +-
>>>>  arch/arm/mach-omap2/board-omap3stalker.c     |    2 +-
>>>>  arch/arm/mach-omap2/board-omap3touchbook.c   |    2 +-
>>>>  arch/arm/mach-omap2/board-overo.c            |    2 +-
>>>>  arch/arm/mach-omap2/board-rm680.c            |    2 +-
>>>>  arch/arm/mach-omap2/board-rx51.c             |    2 +-
>>>>  arch/arm/mach-omap2/board-zoom-peripherals.c |    2 +-
>>>>  16 files changed, 16 insertions(+), 16 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
>>>> index 244d8a5..17bb076 100644
>>>> --- a/arch/arm/mach-omap2/board-2430sdp.c
>>>> +++ b/arch/arm/mach-omap2/board-2430sdp.c
>>>> @@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
>>>>  	omap_hsmmc_init(mmc);
>>>>  
>>>>  	omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
>>>> -	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
>>>> +	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
>>>
>>> how about moving usb_bind_phy() calls to omap2430.c ?
>>>
>>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>>> index f44e8b5..b6abc1a 100644
>>> --- a/drivers/usb/musb/omap2430.c
>>> +++ b/drivers/usb/musb/omap2430.c
>>> @@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device *pdev)
>>>  
>>>  		pdata->board_data	= data;
>>>  		pdata->config		= config;
>>> +	} else {
>>> +		/* bind the PHY */
>>> +		usb_bind_phy(dev_name(&musb->dev), 0, "twl4030_usb");
>>
>> This looks like a hack IMHO to workaround the usb phy library. otherwise it is
>> similar to get_phy_by_name.
> 
> actually, this is a workaround to the fact that we're not creating all
> platform_devices in arch/arm/mach-omap2/ :-)
> 
> If we had the musb allocation there, we could easily handle
> usb_bind_phy()
> 
>>> so that's temporary. It might be better than to reintroduce the IDR in
>>> musb_core.c.
>>
>> that?s needed for generic phy framework anyway :-s
> 
> right, but generic phy framework can handle everything just fine, the
> only problem is that names are changing.

right. But if the names change, PHY framework wouldn't be able to return the
reference to the PHY.

Thanks
Kishon


From rnayak at ti.com  Tue Jul 30 01:16:01 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 10:46:01 +0530
Subject: [PATCH 2/4] serial: omap: enable PM runtime only when its fully
 configured
In-Reply-To: <51F62CEB.2090502@ti.com>
References: <1374487277-26099-1-git-send-email-rnayak@ti.com>
 <1374487277-26099-3-git-send-email-rnayak@ti.com>
 <alpine.DEB.2.02.1307290843090.30864@utopia.booyaka.com>
 <51F62CEB.2090502@ti.com>
Message-ID: <51F74C11.2000306@ti.com>

On Monday 29 July 2013 02:20 PM, Rajendra Nayak wrote:
> On Monday 29 July 2013 02:14 PM, Paul Walmsley wrote:
>> Rajendra,
>>
>> On Mon, 22 Jul 2013, Rajendra Nayak wrote:
>>
>>> From: Grygorii Strashko <grygorii.strashko at ti.com>
>>>
>>> If earlyprintk is enabled and current UART is console port the platform
>>> code can mark it as RPM_ACTIVE to sync real IP state with PM Runtime and
>>> avoid resuming of already active device, but now, driver initialization
>>> will be performed in the wrong way:
>>
>> ...
>>
>>> CC: Tony Lindgren <tony at atomide.com>
>>> CC: Rajendra Nayak <rnayak at ti.com>
>>> CC: Felipe Balbi <balbi at ti.com>
>>> CC: Kevin Hilman <khilman at linaro.org>
>>>
>>> Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
>>
>> Did you intend to add your Signed-off-by: to this patch?  Since you're 
>> formally submitting it, it needs to have your Signed-off-by: for me to 
>> take it.  Let me know and I'll add it if needed -
> 
> Sorry about that Paul. I indeed missed adding my SoB for this one.
> 
> Signed-off-by: Rajendra Nayak <rnayak at ti.com>

Paul,

Looks like this one is already been queued by Greg.

regards,
Rajendra

> 
>>
>> - Paul
>>
> 



From hdoyu at nvidia.com  Tue Jul 30 01:18:03 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Tue, 30 Jul 2013 08:18:03 +0300
Subject: [PATCH v2 14/22] iommu/tegra: smmu: Register platform_device to
 IOMMU dynamically
In-Reply-To: <51F6AC41.30007@wwwdotorg.org>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-15-git-send-email-hdoyu@nvidia.com>
 <51E84D51.2030404@wwwdotorg.org>
 <20130729.142752.1020949402019811407.hdoyu@nvidia.com>
 <51F6AC41.30007@wwwdotorg.org>
Message-ID: <20130730081803.5bb0ed4665f1f6ecf5dab908@nvidia.com>

On Mon, 29 Jul 2013 19:54:09 +0200
Stephen Warren <swarren at wwwdotorg.org> wrote:
...
> >> Why hard-code this mapping? Can't devices be assigned to ASIDs based on
> >> a DT property? I assume there's nothing in the SMMU HW that requires
> >> specific ASIDs to be used?
> > 
> > Right. Where should those policy be passed, board DT files?
> 
> Is the HW module (== SW group?) to ASID mapping policy or is a
> particular mapping required by HW?

only policy.
But swgroup can have multiple HWs, they need to be set in the same swgroup.

> Can the ASID mapping just happen dynamically in SW rather than DT
> dictating a particular mapping?

No info about ASID in DT, at least, right now.
If a board DT file is the place to put policy, then it can be an option.
 
> I assume the mapping must be set up before any HW is used, and can't be
> modified later, so there's no much chance of deferring any policy
> decisions to user-space etc.?

I think that both cases are needed.

Some traditional devices(MMC) can be changed later as it may have rootfs on it.
For some smarter devices like host1x, it want to change ASID dynamically per request/context.


From nsekhar at ti.com  Tue Jul 30 01:18:37 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 30 Jul 2013 10:48:37 +0530
Subject: [PATCH 3/9] ARM: edma: Add function to manually trigger an EDMA
 channel
In-Reply-To: <1375104595-16018-4-git-send-email-joelf@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
 <1375104595-16018-4-git-send-email-joelf@ti.com>
Message-ID: <51F74CAD.3040604@ti.com>

On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
> Manual trigger for events missed as a result of splitting a
> scatter gather list and DMA'ing it in batches. Add a helper
> function to trigger a channel incase any such events are missed.
> 
> Signed-off-by: Joel Fernandes <joelf at ti.com>
> ---
>  arch/arm/common/edma.c             |   21 +++++++++++++++++++++
>  include/linux/platform_data/edma.h |    2 ++
>  2 files changed, 23 insertions(+)
> 
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index 3567ba1..10995b2 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -1236,6 +1236,27 @@ void edma_resume(unsigned channel)
>  }
>  EXPORT_SYMBOL(edma_resume);
>  
> +int edma_manual_trigger(unsigned channel)

edma_trigger_channel() maybe? Brings consistency with
edma_alloc_channel() edma_free_channel() etc.

> +{
> +	unsigned ctlr;
> +	int j;
> +	unsigned int mask;
> +
> +	ctlr = EDMA_CTLR(channel);
> +	channel = EDMA_CHAN_SLOT(channel);
> +	mask = BIT(channel & 0x1f);
> +
> +	j = channel >> 5;
> +
> +	/* EDMA channels without event association */

May be actually check for no-event association before you trigger in
software? You can do that by looking at unused channel list, no?

> +	edma_shadow0_write_array(ctlr, SH_ESR, j, mask);

edma_shadow0_write_array(ctlr, SH_ESR, channel >> 5, mask) is no less
readable, but I leave it to you.

Thanks,
Sekhar



From hdoyu at nvidia.com  Tue Jul 30 01:22:53 2013
From: hdoyu at nvidia.com (Hiroshi Doyu)
Date: Tue, 30 Jul 2013 08:22:53 +0300
Subject: [PATCH v2 21/22] iommu/tegra: smmu: Support Multiple ASID
In-Reply-To: <51F6A943.8000004@wwwdotorg.org>
References: <1373021097-32420-1-git-send-email-hdoyu@nvidia.com>
 <1373021097-32420-22-git-send-email-hdoyu@nvidia.com>
 <51E8535A.30605@wwwdotorg.org>
 <20130729.133155.1836775489422797370.hdoyu@nvidia.com>
 <51F6A943.8000004@wwwdotorg.org>
Message-ID: <20130730082253.be35a8ddadbe757100e92c10@nvidia.com>

On Mon, 29 Jul 2013 19:41:23 +0200
Stephen Warren <swarren at wwwdotorg.org> wrote:
...
> > I think that this belongs to the system operation policy. Which H/W
> > should be configured to which Address Space(AS). This put all AHB
> > clients(PPCS) into AS[1](SYSTEM_PROTECTED), and the rest into
> > AS[0](SYSTEM_DEFAULT). AHB clients are mainly traditional H/Ws like
> > USB and SD/MMC so that they should be kept separated from the smart
> > IOMMU clients like host1x.
> > 
> > Is there any place to configure this kind of board specific policy
> > rather than here?
> 
> I'm not sure that answers the question I asked.
> 
> I mean that the driver expects that two AS always exist;
> SYSTEM_PROTECTED and SYSTEM_DEFAULT. However, the set of extant ASs is
> IIRC defined by the DT content. What if the DT doesn't define two ASs?
> Shouldn't there at least be an error-check for this case, so the driver
> doesn't just blindly continue and access smmu_handle->map[1] when the
> map[] array only has 1 entry?

OK, now I got it.

We can create multiple maps on the same AS in theory. So the limitation
is only for how many maps S/W creaed. This can/should be checked only
within kernel side. No constraints from DT.


From horms+renesas at verge.net.au  Tue Jul 30 01:24:00 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 14:24:00 +0900
Subject: [PATCH 0/4] Renesas ARM based SoC multiplatform updates for v3.12
Message-ID: <cover.1375161473.git.horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

please consider the following Renesas ARM based SoC multiplatform updates
for v3.12. This pull-request is based on renesas-dt-for-v3.12, which I have
already sent a pull-request for, in order to provide pre-requisite code.

The following changes since commit 66a5cab04d339d02b93a4671eadf8e251dbfdc2c:

  ARM: shmobile: Add SMSC ethernet chip to KZM9D DT reference (2013-07-17 10:06:47 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-multiplatform-for-v3.12

for you to fetch changes up to fd071b669ee2405e986636e389a3d1b6776e50a0:

  ARM: shmobile: Allow ARCH_SHMOBILE_MULTI timer configuration (2013-07-23 09:52:44 +0900)

----------------------------------------------------------------
Renesas ARM based SoC multiplatform updates for v3.12

Move Renesas ARM based SoCs a little closer to using
multiplatform by adding ARCH_SHMOBILE_MULTI and only
building clocks when COMMON_CLK=n.

----------------------------------------------------------------
Magnus Damm (4):
      ARM: shmobile: Only build clocks when COMMON_CLK=n
      ARM: shmobile: Introduce ARCH_SHMOBILE_MULTI
      ARM: shmobile: Add EMEV2 and KZM9D to ARCH_SHMOBILE_MULTI
      ARM: shmobile: Allow ARCH_SHMOBILE_MULTI timer configuration

 arch/arm/Makefile                              |  1 +
 arch/arm/boot/dts/Makefile                     |  1 +
 arch/arm/mach-shmobile/Kconfig                 | 52 +++++++++++++++++++++++---
 arch/arm/mach-shmobile/Makefile                | 33 +++++++++++-----
 arch/arm/mach-shmobile/board-kzm9d-reference.c |  3 +-
 arch/arm/mach-shmobile/setup-emev2.c           |  3 +-
 6 files changed, 77 insertions(+), 16 deletions(-)


From horms+renesas at verge.net.au  Tue Jul 30 01:24:14 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 14:24:14 +0900
Subject: [PATCH 4/4] ARM: shmobile: Allow ARCH_SHMOBILE_MULTI timer
 configuration
In-Reply-To: <cover.1375161473.git.horms+renesas@verge.net.au>
References: <cover.1375161473.git.horms+renesas@verge.net.au>
Message-ID: <fd071b669ee2405e986636e389a3d1b6776e50a0.1375161473.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Move the timer configuration bits to allow use in
case of ARCH_SHMOBILE or ARCH_SHMOBILE_MULTI.

The timers all make use of the regular driver model
so they are safe to enable for ARCH_MULTIPLATFORM.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 8914c9b..cdefd7d 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -32,6 +32,8 @@ config MACH_KZM9D_REFERENCE
 	   of not supporting a number of devices.
 
 	   This is intended to aid developers
+
+comment "SH-Mobile System Configuration"
 endif
 
 if ARCH_SHMOBILE
@@ -234,6 +236,15 @@ config CPU_HAS_INTEVT
         bool
 	default y
 
+config SH_CLK_CPG
+	bool
+
+source "drivers/sh/Kconfig"
+
+endif
+
+if ARCH_SHMOBILE || ARCH_SHMOBILE_MULTI
+
 menu "Timer and clock configuration"
 
 config SHMOBILE_TIMER_HZ
@@ -268,9 +279,4 @@ config EM_TIMER_STI
 
 endmenu
 
-config SH_CLK_CPG
-	bool
-
-source "drivers/sh/Kconfig"
-
 endif
-- 
1.8.3.2



From horms+renesas at verge.net.au  Tue Jul 30 01:24:12 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 14:24:12 +0900
Subject: [PATCH 2/4] ARM: shmobile: Introduce ARCH_SHMOBILE_MULTI
In-Reply-To: <cover.1375161473.git.horms+renesas@verge.net.au>
References: <cover.1375161473.git.horms+renesas@verge.net.au>
Message-ID: <efacfce5f8a523457e9419a25d52fe39db00b26a.1375161473.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Add ARCH_SHMOBILE_MULTI to mach-shmobile that can be used
to enable ARCH_MULTIPLATFORM on selected SoCs and boards.

The headers stay under arch/arm/mach-shmobile/include/mach/
for now, they can and will be migrated independently over time.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/Makefile               |  1 +
 arch/arm/mach-shmobile/Kconfig  | 21 +++++++++++++++++++++
 arch/arm/mach-shmobile/Makefile |  2 ++
 3 files changed, 24 insertions(+)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c0ac0f5..d1f717c 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -190,6 +190,7 @@ machine-$(CONFIG_ARCH_EXYNOS)		+= exynos
 machine-$(CONFIG_ARCH_SA1100)		+= sa1100
 machine-$(CONFIG_ARCH_SHARK)		+= shark
 machine-$(CONFIG_ARCH_SHMOBILE) 	+= shmobile
+machine-$(CONFIG_ARCH_SHMOBILE_MULTI) 	+= shmobile
 machine-$(CONFIG_ARCH_TEGRA)		+= tegra
 machine-$(CONFIG_ARCH_U300)		+= u300
 machine-$(CONFIG_ARCH_U8500)		+= ux500
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 7c5034a..4c54298 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -1,3 +1,24 @@
+config ARCH_SHMOBILE_MULTI
+	bool "SH-Mobile Series" if ARCH_MULTI_V7
+	depends on MMU
+	select CPU_V7
+	select GENERIC_CLOCKEVENTS
+	select HAVE_ARM_SCU if SMP
+	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_SMP
+	select ARM_GIC
+	select MIGHT_HAVE_CACHE_L2X0
+	select NO_IOPORT
+	select PINCTRL
+	select ARCH_REQUIRE_GPIOLIB
+	select CLKDEV_LOOKUP
+
+if ARCH_SHMOBILE_MULTI
+
+comment "SH-Mobile System Type"
+
+endif
+
 if ARCH_SHMOBILE
 
 comment "SH-Mobile System Type"
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 5884bea..b150c45 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -2,6 +2,8 @@
 # Makefile for the linux kernel.
 #
 
+ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/arch/arm/mach-shmobile/include
+
 # Common objects
 obj-y				:= timer.o console.o
 
-- 
1.8.3.2



From horms+renesas at verge.net.au  Tue Jul 30 01:24:13 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 14:24:13 +0900
Subject: [PATCH 3/4] ARM: shmobile: Add EMEV2 and KZM9D to ARCH_SHMOBILE_MULTI
In-Reply-To: <cover.1375161473.git.horms+renesas@verge.net.au>
References: <cover.1375161473.git.horms+renesas@verge.net.au>
Message-ID: <cbc60e7c04f3c1390144d4a881f0a7b98b49da98.1375161473.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Enable build of EMEV2 and KZM9D DT Reference in
case of ARCH_MULTIPLATFORM and ARCH_SHMOBILE_MULTI.

IS_ENABLED() is leaves the clock-emev2.c file out
in case of COMMON_CLK=y.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/Makefile                     |  1 +
 arch/arm/mach-shmobile/Kconfig                 | 15 +++++++++++++++
 arch/arm/mach-shmobile/board-kzm9d-reference.c |  3 ++-
 arch/arm/mach-shmobile/setup-emev2.c           |  3 ++-
 4 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index af19e38..f3861de 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -193,6 +193,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
 	sh73a0-kzm9g-reference.dtb \
 	r8a73a4-ape6evm.dtb \
 	sh7372-mackerel.dtb
+dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += emev2-kzm9d-reference.dtb
 dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_cyclone5.dtb \
 	socfpga_vt.dtb
 dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb \
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 4c54298..8914c9b 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -17,6 +17,21 @@ if ARCH_SHMOBILE_MULTI
 
 comment "SH-Mobile System Type"
 
+config ARCH_EMEV2
+	bool "Emma Mobile EV2"
+
+comment "SH-Mobile Board Type"
+
+config MACH_KZM9D_REFERENCE
+	bool "KZM9D board - Reference Device Tree Implementation"
+	depends on ARCH_EMEV2
+	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	---help---
+	   Use reference implementation of KZM9D board support
+	   which makes a greater use of device tree at the expense
+	   of not supporting a number of devices.
+
+	   This is intended to aid developers
 endif
 
 if ARCH_SHMOBILE
diff --git a/arch/arm/mach-shmobile/board-kzm9d-reference.c b/arch/arm/mach-shmobile/board-kzm9d-reference.c
index a7b28b2..8f8bb2f 100644
--- a/arch/arm/mach-shmobile/board-kzm9d-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9d-reference.c
@@ -26,7 +26,8 @@
 
 static void __init kzm9d_add_standard_devices(void)
 {
-	emev2_clock_init();
+	if (!IS_ENABLED(CONFIG_COMMON_CLK))
+		emev2_clock_init();
 
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
index 19980be..1553af8 100644
--- a/arch/arm/mach-shmobile/setup-emev2.c
+++ b/arch/arm/mach-shmobile/setup-emev2.c
@@ -175,7 +175,8 @@ static struct resource pmu_resources[] = {
 
 void __init emev2_add_standard_devices(void)
 {
-	emev2_clock_init();
+	if (!IS_ENABLED(CONFIG_COMMON_CLK))
+		emev2_clock_init();
 
 	emev2_register_uart(0);
 	emev2_register_uart(1);
-- 
1.8.3.2



From horms+renesas at verge.net.au  Tue Jul 30 01:24:11 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 14:24:11 +0900
Subject: [PATCH 1/4] ARM: shmobile: Only build clocks when COMMON_CLK=n
In-Reply-To: <cover.1375161473.git.horms+renesas@verge.net.au>
References: <cover.1375161473.git.horms+renesas@verge.net.au>
Message-ID: <a360feb9e9e6cc36d61e683c03dc13974663298b.1375161473.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Move shared clock.c file and per-SoC clock-xxx.c files
to only build when CONFIG_COMMON_CLK != y.

The regular ARCH_SHMOBILE case with legacy SH clock framework
will build just as before with this patch applied, however
the case when COMMON_CLK=y will exclude all the clock files.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/Makefile | 31 ++++++++++++++++++++++---------
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index e8d0a2c..5884bea 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -3,17 +3,30 @@
 #
 
 # Common objects
-obj-y				:= timer.o console.o clock.o
+obj-y				:= timer.o console.o
 
 # CPU objects
-obj-$(CONFIG_ARCH_SH7372)	+= setup-sh7372.o clock-sh7372.o intc-sh7372.o
-obj-$(CONFIG_ARCH_SH73A0)	+= setup-sh73a0.o clock-sh73a0.o intc-sh73a0.o
-obj-$(CONFIG_ARCH_R8A73A4)	+= setup-r8a73a4.o clock-r8a73a4.o
-obj-$(CONFIG_ARCH_R8A7740)	+= setup-r8a7740.o clock-r8a7740.o intc-r8a7740.o
-obj-$(CONFIG_ARCH_R8A7778)	+= setup-r8a7778.o clock-r8a7778.o
-obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o clock-r8a7779.o intc-r8a7779.o
-obj-$(CONFIG_ARCH_R8A7790)	+= setup-r8a7790.o clock-r8a7790.o
-obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o clock-emev2.o
+obj-$(CONFIG_ARCH_SH7372)	+= setup-sh7372.o intc-sh7372.o
+obj-$(CONFIG_ARCH_SH73A0)	+= setup-sh73a0.o intc-sh73a0.o
+obj-$(CONFIG_ARCH_R8A73A4)	+= setup-r8a73a4.o
+obj-$(CONFIG_ARCH_R8A7740)	+= setup-r8a7740.o intc-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7778)	+= setup-r8a7778.o
+obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o intc-r8a7779.o
+obj-$(CONFIG_ARCH_R8A7790)	+= setup-r8a7790.o
+obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o
+
+# Clock objects
+ifndef CONFIG_COMMON_CLK
+obj-y				+= clock.o
+obj-$(CONFIG_ARCH_SH7372)	+= clock-sh7372.o
+obj-$(CONFIG_ARCH_SH73A0)	+= clock-sh73a0.o
+obj-$(CONFIG_ARCH_R8A73A4)	+= clock-r8a73a4.o
+obj-$(CONFIG_ARCH_R8A7740)	+= clock-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7778)	+= clock-r8a7778.o
+obj-$(CONFIG_ARCH_R8A7779)	+= clock-r8a7779.o
+obj-$(CONFIG_ARCH_R8A7790)	+= clock-r8a7790.o
+obj-$(CONFIG_ARCH_EMEV2)	+= clock-emev2.o
+endif
 
 # SMP objects
 smp-y				:= platsmp.o headsmp.o
-- 
1.8.3.2



From pwalmsley at nvidia.com  Tue Jul 30 01:25:47 2013
From: pwalmsley at nvidia.com (Paul Walmsley)
Date: Mon, 29 Jul 2013 22:25:47 -0700
Subject: Tegra baseline test results for v3.11-rc1
Message-ID: <51F74E5B.2000004@nvidia.com>

Here are some basic Tegra test results for Linux v3.11-rc1.
Logs and other details at:

     http://nvt.pwsan.com/pub/linux/testlogs/test_v3.11-rc1/20130729192251/


Test summary
------------

Build: zImage:
     Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig

Boot to userspace: multi_v7_defconfig:
     Pass: ( 2/ 2): tegra114-dalmore-headless, tegra30-beaver

Boot to userspace: tegra_defconfig:
     Pass: ( 2/ 2): tegra114-dalmore-headless, tegra30-beaver



From pwalmsley at nvidia.com  Tue Jul 30 01:29:36 2013
From: pwalmsley at nvidia.com (Paul Walmsley)
Date: Mon, 29 Jul 2013 22:29:36 -0700
Subject: Tegra baseline test results for v3.11-rc2
Message-ID: <51F74F40.2080403@nvidia.com>

Here are some basic Tegra test results for Linux v3.11-rc2.
Logs and other details at:

     http://nvt.pwsan.com/pub/linux/testlogs/test_v3.11-rc2/20130729210232/


Test summary
------------

Build: zImage:
     Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig

Boot to userspace: multi_v7_defconfig:
     Pass: ( 2/ 2): tegra114-dalmore-headless, tegra30-beaver

Boot to userspace: tegra_defconfig:
     Pass: ( 2/ 2): tegra114-dalmore-headless, tegra30-beaver


vmlinux object size
(delta in bytes from test_v3.11-rc1 (ad81f0545ef01ea651886dddac4bef6cec930092)):
    text     data      bss    total  kernel
    +872     +184        0    +1056  multi_v7_defconfig
    +674     +256        0     +930  tegra_defconfig


Boot-time memory difference
(delta in bytes from test_v3.11-rc1 (ad81f0545ef01ea651886dddac4bef6cec930092))
     avail    rsrvd     high    freed                board              kconfig                  dtb
         .        .        .        . tegra114-dalmore-hea     tegra114-dalmore   multi_v7_defconfig
         .        .        .        . tegra114-dalmore-hea     tegra114-dalmore      tegra_defconfig
         .        .        .        .       tegra30-beaver       tegra30-beaver   multi_v7_defconfig
         .        .        .        .       tegra30-beaver       tegra30-beaver      tegra_defconfig





From pwalmsley at nvidia.com  Tue Jul 30 01:34:58 2013
From: pwalmsley at nvidia.com (Paul Walmsley)
Date: Mon, 29 Jul 2013 22:34:58 -0700
Subject: Tegra baseline test results for v3.11-rc3
Message-ID: <51F75082.6090308@nvidia.com>

Here are some basic Tegra test results for Linux v3.11-rc3.
Logs and other details at:

     http://nvt.pwsan.com/pub/linux/testlogs/test_v3.11-rc3/20130729212315/


Test summary
------------

Build: zImage:
     Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig

Boot to userspace: multi_v7_defconfig:
     Pass: ( 2/ 2): tegra114-dalmore-headless, tegra30-beaver

Boot to userspace: tegra_defconfig:
     Pass: ( 2/ 2): tegra114-dalmore-headless, tegra30-beaver



vmlinux object size
(delta in bytes from test_v3.11-rc2 (3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b)):
    text     data      bss    total  kernel
  +33580     +928    +1152   +35660  multi_v7_defconfig
    +129      +64        0     +193  tegra_defconfig


Boot-time memory difference
(delta in bytes from test_v3.11-rc2 (3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b))
     avail    rsrvd     high    freed                board              kconfig                  dtb
      -40k      40k        .       4k tegra114-dalmore-hea     tegra114-dalmore   multi_v7_defconfig
         .        .        .        . tegra114-dalmore-hea     tegra114-dalmore      tegra_defconfig
      -40k      40k        .       4k       tegra30-beaver       tegra30-beaver   multi_v7_defconfig
         .        .        .        .       tegra30-beaver       tegra30-beaver      tegra_defconfig



From tomi.valkeinen at ti.com  Tue Jul 30 01:45:52 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 30 Jul 2013 08:45:52 +0300
Subject: [PATCH v2 6/9] ARM: msm: Move mach/board.h contents to common.h
In-Reply-To: <20130729202031.GA20694@codeaurora.org>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
 <1374699274-18388-7-git-send-email-sboyd@codeaurora.org>
 <20130729202031.GA20694@codeaurora.org>
Message-ID: <51F75310.80403@ti.com>

On 29/07/13 23:20, David Brown wrote:
> On Wed, Jul 24, 2013 at 01:54:31PM -0700, Stephen Boyd wrote:
>> The contents of mach/board.h are only used by files within
>> mach-msm so there is no need to export this file outside of the
>> mach-msm directory. Move the contents of the file to common.h to
>> allow us to compile MSM in the multi-platform kernel.
>>
>> Cc: Florian Tobias Schandinat <FlorianSchandinat at gmx.de>
>> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>> ---
>> drivers/video/msm/msm_fb.c             |  1 -
> 
> It'd be nice to get a framebuffer Ack from this part.
> 
> original patch:
>  https://patchwork.kernel.org/patch/2833029/

Acked-by: Tomi Valkeinen <tomi.valkeinen at ti.com>

 Tom


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130730/230e8445/attachment.sig>

From archit at ti.com  Tue Jul 30 01:48:45 2013
From: archit at ti.com (Archit Taneja)
Date: Tue, 30 Jul 2013 11:18:45 +0530
Subject: [PATCH 09/21] ARM: OMAP: devkit8000: use new display drivers
In-Reply-To: <1374822504-28949-10-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
 <1374822504-28949-10-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <51F753BD.5040509@ti.com>

Hi,

On Friday 26 July 2013 12:38 PM, Tomi Valkeinen wrote:
> Use new display drivers for devkit8000 board.
>
> The new OMAP display drivers were merged for 3.11, and we can now change
> the board files to use the new ones and phase out the old ones.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
> ---
>   arch/arm/mach-omap2/board-devkit8000.c | 96 +++++++++++++++++++++++-----------
>   1 file changed, 65 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
> index f1d91ba..cdc4fb9 100644
> --- a/arch/arm/mach-omap2/board-devkit8000.c
> +++ b/arch/arm/mach-omap2/board-devkit8000.c
> @@ -112,50 +112,81 @@ static struct regulator_consumer_supply devkit8000_vio_supply[] = {
>   	REGULATOR_SUPPLY("vcc", "spi2.0"),
>   };
>
> -static struct panel_generic_dpi_data lcd_panel = {
> -	.name			= "innolux_at070tn83",
> -	/* gpios filled in code */
> +static const struct display_timing devkit8000_lcd_videomode = {
> +	.pixelclock	= { 0, 40000000, 0 },

This is unrelated to the work being done here, but noticed that the 
pixel clock for this panel seems to be too high for the given timings. 
It puts the refresh rate around 90 Hz, which is odd.

Archit


From balbi at ti.com  Tue Jul 30 02:01:34 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 30 Jul 2013 09:01:34 +0300
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given in
 usb_bind_phy
In-Reply-To: <51F74BC8.7020903@ti.com>
References: <1374829418-27503-1-git-send-email-kishon@ti.com>
 <1374829418-27503-3-git-send-email-kishon@ti.com>
 <20130729150638.GD3063@radagast> <51F68A56.8060805@ti.com>
 <20130729175413.GC4964@radagast> <51F74BC8.7020903@ti.com>
Message-ID: <20130730060134.GD9155@radagast>

Hi,

On Tue, Jul 30, 2013 at 10:44:48AM +0530, Kishon Vijay Abraham I wrote:
> > On Mon, Jul 29, 2013 at 08:59:26PM +0530, Kishon Vijay Abraham I wrote:
> >>>> Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while creating
> >>>> MUSB core device. So in usb_bind_phy (binds the controller with the PHY), the
> >>>> device name of the controller had *.auto* in it. Since with using
> >>>> PLATFORM_DEVID_AUTO, there is no way to know the exact device name in advance,
> >>>> the data given in usb_bind_phy became obsolete and usb_get_phy was failing.
> >>>> So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO. Corresponding
> >>>> change is done in board file here.
> >>>>
> >>>> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> >>>> ---
> >>>>  arch/arm/mach-omap2/board-2430sdp.c          |    2 +-
> >>>>  arch/arm/mach-omap2/board-3430sdp.c          |    2 +-
> >>>>  arch/arm/mach-omap2/board-cm-t35.c           |    2 +-
> >>>>  arch/arm/mach-omap2/board-devkit8000.c       |    2 +-
> >>>>  arch/arm/mach-omap2/board-igep0020.c         |    2 +-
> >>>>  arch/arm/mach-omap2/board-ldp.c              |    2 +-
> >>>>  arch/arm/mach-omap2/board-omap3beagle.c      |    2 +-
> >>>>  arch/arm/mach-omap2/board-omap3evm.c         |    2 +-
> >>>>  arch/arm/mach-omap2/board-omap3logic.c       |    2 +-
> >>>>  arch/arm/mach-omap2/board-omap3pandora.c     |    2 +-
> >>>>  arch/arm/mach-omap2/board-omap3stalker.c     |    2 +-
> >>>>  arch/arm/mach-omap2/board-omap3touchbook.c   |    2 +-
> >>>>  arch/arm/mach-omap2/board-overo.c            |    2 +-
> >>>>  arch/arm/mach-omap2/board-rm680.c            |    2 +-
> >>>>  arch/arm/mach-omap2/board-rx51.c             |    2 +-
> >>>>  arch/arm/mach-omap2/board-zoom-peripherals.c |    2 +-
> >>>>  16 files changed, 16 insertions(+), 16 deletions(-)
> >>>>
> >>>> diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
> >>>> index 244d8a5..17bb076 100644
> >>>> --- a/arch/arm/mach-omap2/board-2430sdp.c
> >>>> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> >>>> @@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
> >>>>  	omap_hsmmc_init(mmc);
> >>>>  
> >>>>  	omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
> >>>> -	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
> >>>> +	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
> >>>
> >>> how about moving usb_bind_phy() calls to omap2430.c ?
> >>>
> >>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> >>> index f44e8b5..b6abc1a 100644
> >>> --- a/drivers/usb/musb/omap2430.c
> >>> +++ b/drivers/usb/musb/omap2430.c
> >>> @@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device *pdev)
> >>>  
> >>>  		pdata->board_data	= data;
> >>>  		pdata->config		= config;
> >>> +	} else {
> >>> +		/* bind the PHY */
> >>> +		usb_bind_phy(dev_name(&musb->dev), 0, "twl4030_usb");
> >>
> >> This looks like a hack IMHO to workaround the usb phy library. otherwise it is
> >> similar to get_phy_by_name.
> > 
> > actually, this is a workaround to the fact that we're not creating all
> > platform_devices in arch/arm/mach-omap2/ :-)
> > 
> > If we had the musb allocation there, we could easily handle
> > usb_bind_phy()
> > 
> >>> so that's temporary. It might be better than to reintroduce the IDR in
> >>> musb_core.c.
> >>
> >> that?s needed for generic phy framework anyway :-s
> > 
> > right, but generic phy framework can handle everything just fine, the
> > only problem is that names are changing.
> 
> right. But if the names change, PHY framework wouldn't be able to return the
> reference to the PHY.

with my suggestion they can change whenever they want since we're using
dev_name() of the just-created musb platform_device. Right ?

-- 
balbi
-------------- 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/20130730/18f1bcd7/attachment-0001.sig>

From tomi.valkeinen at ti.com  Tue Jul 30 02:01:52 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 30 Jul 2013 09:01:52 +0300
Subject: [PATCH 09/21] ARM: OMAP: devkit8000: use new display drivers
In-Reply-To: <51F753BD.5040509@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
 <1374822504-28949-10-git-send-email-tomi.valkeinen@ti.com>
 <51F753BD.5040509@ti.com>
Message-ID: <51F756D0.3050009@ti.com>

On 30/07/13 08:48, Archit Taneja wrote:
> Hi,
> 
> On Friday 26 July 2013 12:38 PM, Tomi Valkeinen wrote:
>> Use new display drivers for devkit8000 board.
>>
>> The new OMAP display drivers were merged for 3.11, and we can now change
>> the board files to use the new ones and phase out the old ones.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
>> ---
>>   arch/arm/mach-omap2/board-devkit8000.c | 96
>> +++++++++++++++++++++++-----------
>>   1 file changed, 65 insertions(+), 31 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-devkit8000.c
>> b/arch/arm/mach-omap2/board-devkit8000.c
>> index f1d91ba..cdc4fb9 100644
>> --- a/arch/arm/mach-omap2/board-devkit8000.c
>> +++ b/arch/arm/mach-omap2/board-devkit8000.c
>> @@ -112,50 +112,81 @@ static struct regulator_consumer_supply
>> devkit8000_vio_supply[] = {
>>       REGULATOR_SUPPLY("vcc", "spi2.0"),
>>   };
>>
>> -static struct panel_generic_dpi_data lcd_panel = {
>> -    .name            = "innolux_at070tn83",
>> -    /* gpios filled in code */
>> +static const struct display_timing devkit8000_lcd_videomode = {
>> +    .pixelclock    = { 0, 40000000, 0 },
> 
> This is unrelated to the work being done here, but noticed that the
> pixel clock for this panel seems to be too high for the given timings.
> It puts the refresh rate around 90 Hz, which is odd.

So it does... Quick googling found the specs for the panel, but even
with the typical values in the spec I get somewhwat odd refresh rate.

Well, as you said, it's unrelated to these changes. I guess it's better
not to touch it.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130730/9d5e4692/attachment.sig>

From shawn.guo at linaro.org  Tue Jul 30 02:09:57 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 30 Jul 2013 14:09:57 +0800
Subject: [RFC 5/8] pinctrl: imx27: imx27 pincontrol driver
In-Reply-To: <1374938808-27316-6-git-send-email-mpa@pengutronix.de>
References: <1374938808-27316-1-git-send-email-mpa@pengutronix.de>
 <1374938808-27316-6-git-send-email-mpa@pengutronix.de>
Message-ID: <20130730060955.GA12382@S2101-09.ap.freescale.net>

On Sat, Jul 27, 2013 at 05:26:45PM +0200, Markus Pargmann wrote:
> +static struct imx_pinctrl_soc_info imx27_pinctrl_info = {
> + .pins = imx27_pinctrl_pads,
> + .npins = ARRAY_SIZE(imx27_pinctrl_pads),
> +};
> +
> +static struct of_device_id imx27_pinctrl_of_match[] = {
> + { .compatible = "fsl,imx27-iomuxc", },
> + { /* sentinel */ }
> +};
> +
> +static struct of_device_id imx21_gpio_of_match[] = {
> + { .compatible = "fsl,imx21-gpio", },

Since we also have "fsl,imx27-gpio" in the compatible string, we can
use it here.

> + { /* sentinel */ }
> +};
> +
> +struct imx27_pinctrl_private {
> + int num_gpio_childs;

Maybe I missed something.  But I see this member is used nowhere.

> + struct platform_device **gpio_dev;
> + struct mxc_gpio_platform_data *gpio_pdata;
> +};

I do not see too much point to have this structure at all.

Shawn

> +
> +static int imx27_pinctrl_probe(struct platform_device *pdev)
> +{
> + struct device_node *child;
> + struct imx_pinctrl *ipctl;
> + struct imx27_pinctrl_private *pctl;
> + int ret;
> + u32 base_addr;
> + int num_gpios = 0;
> + int i = 0;
> +
> + ret = of_property_read_u32(pdev->dev.of_node, "reg", &base_addr);
> + if (ret)
> + return ret;
> +
> + ret = imx_pinctrl_probe(pdev, &imx27_pinctrl_info);
> + if (ret)
> + return ret;
> +
> + pctl = devm_kzalloc(&pdev->dev, sizeof(*pctl), GFP_KERNEL);
> + if (!pctl)
> + return -ENOMEM;
> +
> + ipctl = platform_get_drvdata(pdev);
> +
> + for_each_available_child_of_node(pdev->dev.of_node, child) {
> + u32 memoffset;
> + if (!of_match_node(imx21_gpio_of_match, child))
> + continue;
> + ret = of_property_read_u32(child, "reg", &memoffset);
> + if (ret)
> + continue;
> + ++num_gpios;
> + }
> +
> + pctl->num_gpio_childs = num_gpios;
> + pctl->gpio_dev = devm_kzalloc(&pdev->dev,
> + sizeof(*pctl->gpio_dev) * num_gpios, GFP_KERNEL);
> + pctl->gpio_pdata = devm_kzalloc(&pdev->dev,
> + sizeof(*pctl->gpio_pdata) * num_gpios, GFP_KERNEL);
> +
> + if (!pctl->gpio_pdata || !pctl->gpio_dev)
> + return -ENOMEM;
> +
> +
> + for_each_available_child_of_node(pdev->dev.of_node, child) {
> + u32 memoffset;
> +
> + if (!of_match_node(imx21_gpio_of_match, child))
> + continue;
> + ret = of_property_read_u32(child, "reg", &memoffset);
> + if (ret)
> + continue;
> +
> + memoffset -= base_addr;
> + pctl->gpio_pdata[i].base = ipctl->base + memoffset;
> +
> + pctl->gpio_dev[i] = of_device_alloc(child, NULL, &pdev->dev);
> + pctl->gpio_dev[i]->dev.platform_data = &pctl->gpio_pdata[i];
> + pctl->gpio_dev[i]->dev.bus = &platform_bus_type;
> +
> + ret = of_device_add(pctl->gpio_dev[i]);
> + if (ret) {
> + dev_err(&pdev->dev,
> + "Failed to add child gpio device\n");
> + goto gpio_err;
> + }
> + ++i;
> + }
> + return 0;
> +gpio_err:
> + while (i--)
> + put_device(&pctl->gpio_dev[i]->dev);
> + return ret;
> +}
> +
> +static struct platform_driver imx27_pinctrl_driver = {
> + .driver = {
> + .name = "imx27-pinctrl",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(imx27_pinctrl_of_match),
> + },
> + .probe = imx27_pinctrl_probe,
> + .remove = imx_pinctrl_remove,
> +};
> +
> +static int __init imx27_pinctrl_init(void)
> +{
> + return platform_driver_register(&imx27_pinctrl_driver);
> +}
> +arch_initcall(imx27_pinctrl_init);
> +
> +static void __exit imx27_pinctrl_exit(void)
> +{
> + platform_driver_unregister(&imx27_pinctrl_driver);
> +}
> +module_exit(imx27_pinctrl_exit);
> +MODULE_AUTHOR("Markus Pargmann <mpa at pengutronix.de>");
> +MODULE_DESCRIPTION("Freescale IMX27 pinctrl driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.8.3.2
>



From kishon at ti.com  Tue Jul 30 02:11:23 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 30 Jul 2013 11:41:23 +0530
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given
 in usb_bind_phy
In-Reply-To: <20130730060134.GD9155@radagast>
References: <1374829418-27503-1-git-send-email-kishon@ti.com>
 <1374829418-27503-3-git-send-email-kishon@ti.com>
 <20130729150638.GD3063@radagast> <51F68A56.8060805@ti.com>
 <20130729175413.GC4964@radagast> <51F74BC8.7020903@ti.com>
 <20130730060134.GD9155@radagast>
Message-ID: <51F7590B.4020705@ti.com>

Hi,

On Tuesday 30 July 2013 11:31 AM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 30, 2013 at 10:44:48AM +0530, Kishon Vijay Abraham I wrote:
>>> On Mon, Jul 29, 2013 at 08:59:26PM +0530, Kishon Vijay Abraham I wrote:
>>>>>> Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while creating
>>>>>> MUSB core device. So in usb_bind_phy (binds the controller with the PHY), the
>>>>>> device name of the controller had *.auto* in it. Since with using
>>>>>> PLATFORM_DEVID_AUTO, there is no way to know the exact device name in advance,
>>>>>> the data given in usb_bind_phy became obsolete and usb_get_phy was failing.
>>>>>> So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO. Corresponding
>>>>>> change is done in board file here.
>>>>>>
>>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
>>>>>> ---
>>>>>>  arch/arm/mach-omap2/board-2430sdp.c          |    2 +-
>>>>>>  arch/arm/mach-omap2/board-3430sdp.c          |    2 +-
>>>>>>  arch/arm/mach-omap2/board-cm-t35.c           |    2 +-
>>>>>>  arch/arm/mach-omap2/board-devkit8000.c       |    2 +-
>>>>>>  arch/arm/mach-omap2/board-igep0020.c         |    2 +-
>>>>>>  arch/arm/mach-omap2/board-ldp.c              |    2 +-
>>>>>>  arch/arm/mach-omap2/board-omap3beagle.c      |    2 +-
>>>>>>  arch/arm/mach-omap2/board-omap3evm.c         |    2 +-
>>>>>>  arch/arm/mach-omap2/board-omap3logic.c       |    2 +-
>>>>>>  arch/arm/mach-omap2/board-omap3pandora.c     |    2 +-
>>>>>>  arch/arm/mach-omap2/board-omap3stalker.c     |    2 +-
>>>>>>  arch/arm/mach-omap2/board-omap3touchbook.c   |    2 +-
>>>>>>  arch/arm/mach-omap2/board-overo.c            |    2 +-
>>>>>>  arch/arm/mach-omap2/board-rm680.c            |    2 +-
>>>>>>  arch/arm/mach-omap2/board-rx51.c             |    2 +-
>>>>>>  arch/arm/mach-omap2/board-zoom-peripherals.c |    2 +-
>>>>>>  16 files changed, 16 insertions(+), 16 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
>>>>>> index 244d8a5..17bb076 100644
>>>>>> --- a/arch/arm/mach-omap2/board-2430sdp.c
>>>>>> +++ b/arch/arm/mach-omap2/board-2430sdp.c
>>>>>> @@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
>>>>>>  	omap_hsmmc_init(mmc);
>>>>>>  
>>>>>>  	omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
>>>>>> -	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
>>>>>> +	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
>>>>>
>>>>> how about moving usb_bind_phy() calls to omap2430.c ?
>>>>>
>>>>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>>>>> index f44e8b5..b6abc1a 100644
>>>>> --- a/drivers/usb/musb/omap2430.c
>>>>> +++ b/drivers/usb/musb/omap2430.c
>>>>> @@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device *pdev)
>>>>>  
>>>>>  		pdata->board_data	= data;
>>>>>  		pdata->config		= config;
>>>>> +	} else {
>>>>> +		/* bind the PHY */
>>>>> +		usb_bind_phy(dev_name(&musb->dev), 0, "twl4030_usb");
>>>>
>>>> This looks like a hack IMHO to workaround the usb phy library. otherwise it is
>>>> similar to get_phy_by_name.
>>>
>>> actually, this is a workaround to the fact that we're not creating all
>>> platform_devices in arch/arm/mach-omap2/ :-)
>>>
>>> If we had the musb allocation there, we could easily handle
>>> usb_bind_phy()
>>>
>>>>> so that's temporary. It might be better than to reintroduce the IDR in
>>>>> musb_core.c.
>>>>
>>>> that?s needed for generic phy framework anyway :-s
>>>
>>> right, but generic phy framework can handle everything just fine, the
>>> only problem is that names are changing.
>>
>> right. But if the names change, PHY framework wouldn't be able to return the
>> reference to the PHY.
> 
> with my suggestion they can change whenever they want since we're using
> dev_name() of the just-created musb platform_device. Right ?

right. But the PHY device can be created in a different place from where the
musb devices are created. And in the PHY framework, the PHY device should have
the list of controller device (names) it can support (PHY framework does not
maintain a separate list for binding like how we had in USB PHY library). e.g.
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg92817.html. In such
cases how do we pass the device names. Also will the MUSB core device be
created before twl4030-usb PHY device?

Thanks
Kishon


From balbi at ti.com  Tue Jul 30 02:18:30 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 30 Jul 2013 09:18:30 +0300
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given in
 usb_bind_phy
In-Reply-To: <51F7590B.4020705@ti.com>
References: <1374829418-27503-1-git-send-email-kishon@ti.com>
 <1374829418-27503-3-git-send-email-kishon@ti.com>
 <20130729150638.GD3063@radagast> <51F68A56.8060805@ti.com>
 <20130729175413.GC4964@radagast> <51F74BC8.7020903@ti.com>
 <20130730060134.GD9155@radagast> <51F7590B.4020705@ti.com>
Message-ID: <20130730061830.GE9155@radagast>

Hi,

On Tue, Jul 30, 2013 at 11:41:23AM +0530, Kishon Vijay Abraham I wrote:
> >>>>>> diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
> >>>>>> index 244d8a5..17bb076 100644
> >>>>>> --- a/arch/arm/mach-omap2/board-2430sdp.c
> >>>>>> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> >>>>>> @@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
> >>>>>>  	omap_hsmmc_init(mmc);
> >>>>>>  
> >>>>>>  	omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
> >>>>>> -	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
> >>>>>> +	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
> >>>>>
> >>>>> how about moving usb_bind_phy() calls to omap2430.c ?
> >>>>>
> >>>>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> >>>>> index f44e8b5..b6abc1a 100644
> >>>>> --- a/drivers/usb/musb/omap2430.c
> >>>>> +++ b/drivers/usb/musb/omap2430.c
> >>>>> @@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device *pdev)
> >>>>>  
> >>>>>  		pdata->board_data	= data;
> >>>>>  		pdata->config		= config;
> >>>>> +	} else {
> >>>>> +		/* bind the PHY */
> >>>>> +		usb_bind_phy(dev_name(&musb->dev), 0, "twl4030_usb");
> >>>>
> >>>> This looks like a hack IMHO to workaround the usb phy library. otherwise it is
> >>>> similar to get_phy_by_name.
> >>>
> >>> actually, this is a workaround to the fact that we're not creating all
> >>> platform_devices in arch/arm/mach-omap2/ :-)
> >>>
> >>> If we had the musb allocation there, we could easily handle
> >>> usb_bind_phy()
> >>>
> >>>>> so that's temporary. It might be better than to reintroduce the IDR in
> >>>>> musb_core.c.
> >>>>
> >>>> that?s needed for generic phy framework anyway :-s
> >>>
> >>> right, but generic phy framework can handle everything just fine, the
> >>> only problem is that names are changing.
> >>
> >> right. But if the names change, PHY framework wouldn't be able to return the
> >> reference to the PHY.
> > 
> > with my suggestion they can change whenever they want since we're using
> > dev_name() of the just-created musb platform_device. Right ?
> 
> right. But the PHY device can be created in a different place from where the
> musb devices are created. And in the PHY framework, the PHY device should have

this shouldn't be a problem. As long as the phy is created, all should
be good.

> the list of controller device (names) it can support (PHY framework does not
> maintain a separate list for binding like how we had in USB PHY library). e.g.
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg92817.html. In such

this has nothing to do with $subject though. We talk about generic PHY
framework once all these PHY drivers are moved there :-)

> cases how do we pass the device names. Also will the MUSB core device be
> created before twl4030-usb PHY device?

and why would that be a problem ? We're telling the framework that the
musb device will use a phy with a name of 'twl4030'. If musb calls
usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and
try again later.

-- 
balbi
-------------- 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/20130730/c4161e9a/attachment.sig>

From archit at ti.com  Tue Jul 30 02:21:30 2013
From: archit at ti.com (Archit Taneja)
Date: Tue, 30 Jul 2013 11:51:30 +0530
Subject: [PATCH 06/21] ARM: OMAP: overo: use new display drivers
In-Reply-To: <1374822504-28949-7-git-send-email-tomi.valkeinen@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
 <1374822504-28949-7-git-send-email-tomi.valkeinen@ti.com>
Message-ID: <51F75B6A.6090900@ti.com>

Hi,

On Friday 26 July 2013 12:38 PM, Tomi Valkeinen wrote:
> Use the new display drivers for OMAP3 Overo board.
>
> The new OMAP display drivers were merged for 3.11, and we can now change
> the board files to use the new ones and phase out the old ones.
>
> Note that the LCD add-on boards for lcd43 and lcd35 use the same GPIOs
> for the panels. This means that both panel devices cannot be probed at
> the same time.
>
> DT will handle this correctly, i.e. the DT data will contain the panel
> device only for the add-on board that is attached. However, for the
> board file we need a hackish solution: We parse the kernel boot command
> line, and see whether lcd43 or lcd35 is set as a default display, and
> add the given one. Or, if neither is given, default to lcd43.
>

<snip>

>   static struct omap_dss_board_info overo_dss_data = {
> -	.num_devices	= ARRAY_SIZE(overo_dss_devices),
> -	.devices	= overo_dss_devices,
> -	.default_device	= &overo_dvi_device,
> +	.default_display_name = "lcd43",
>   };

The default display previously was the dvi device, if both lcd43 and 
lcd35 are on add-on boards, then we should probably stick to dvi itself, 
right? The hack won't work if dvi is the default device though.

Archit



From r.sh.open at gmail.com  Tue Jul 30 02:25:15 2013
From: r.sh.open at gmail.com (Rahul Sharma)
Date: Tue, 30 Jul 2013 11:55:15 +0530
Subject: [PATCH v9 0/8] Generic PHY Framework
In-Reply-To: <20130709173429.GE10776@arwen.pp.htv.fi>
References: <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com>
 <51D54694.20203@ti.com> <20130704101216.GD4830@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E9764D5@DBDE04.ent.ti.com>
 <51DAADD1.3060302@ti.com>
 <780E789C2E067A4BB8F69D0BB9EC4F253E976575@DBDE04.ent.ti.com>
 <20130709114416.GL5552@arwen.pp.htv.fi>
 <780E789C2E067A4BB8F69D0BB9EC4F253E97670D@DBDE04.ent.ti.com>
 <20130709173429.GE10776@arwen.pp.htv.fi>
Message-ID: <CAPdUM4MoKfWRuES1QjEkYQ1=Af6MvLjjb_p6j4zdeFOAOcpDFg@mail.gmail.com>

Hi Balbi, Kishon,

I have similar requirements for exynos hdmi phy. hdmi driver (controller)
need to set the operating clock to hdmi phy which depends on the pixel
clock.

Phy has an internal pll to be configured as per changing resolution. It can
be done by writing into phy registers. CCF callbacks (set/get_rate) can
not be used unless I register phy as a clock controller. But that way
hdmi driver loses finer power control for the phy. Phy should be ON, only
when hdmi hotplugged.

Callback: set_phy_operating_freq in phy framework, seems generic and
addressing similar requirements for other phys. What you say on this?

regards,
Rahul Sharma.

On Tue, Jul 9, 2013 at 11:04 PM, Felipe Balbi <balbi at ti.com> wrote:
>
> Hi,
>
> On Tue, Jul 09, 2013 at 02:33:58PM +0200, Patel, Satish wrote:
> > > > Operation:
> > > >
> > > > Once the card gets inserted into the slot, user application can
> > > > initiate activate sequence anytime, it is not mandatory that
> > > > activation has to be called Immediately. It all depends whether
> > > other
> > > > connections ( network, printer) are proper.  User application can do
> > > > some checks and then dynamically activate the card
> > >
> > > The card or the phy ? Who actually activates ? Is the activation
> > > handling part of the PHY or part of the smartcard controller ?
> > >
> >
> > It?s a activation of smart card which is inserted into the phy slot.
> > Smart card activation will by done phy but initiated by user application
> > Handling of activation should be done at both the side - controller as well
> > As phy. Phy will raise certain signals and check timeout while activation
> > , while controller will store data coming from smart card to FIFO. Its
> > Controller which will give command to phy to initiate activation sequence when it
> > is ready.
> >
> > Which means, both controller and phy has role to play while activation.
> > Also it is applicable while deactivation.
>
> right, so when the smartcard device is opened, you want to powerup the
> PHY, powerup the smartcard controller and get things going, which means
> that all your activation logic can, and should, be hidden by
> phy_power_on() and phy_power_off()
>
> Perhaps you also want to delay phy_init() and phy_shutdown() to that
> very time, which would mean that we wouldn't even need
> phy_power_{on,off}() calls whatsoever.
>
> > > > There are 2 sequence of activation - normal activation and warm
> > > reset.
> > > > If first fails then warm reset should be executed, if card does not
> > > > response to both then deactivation will be carried out
> > >
> > > ret = phy_resume(phy);
> > > if (ret == -EINVAL) { /* perhaps there's a better error code */
> > >     ret = phy_reset(phy);
> > >     if (ret)
> > >             phy_suspend(phy);
> > > }
> > >
> >
> > Its not like this. There are the cases, when during normal activation
> > card respond With some characters, but they might not be valid or
> > error prone - This check will be done by user application as only
> > application knows how to decode characters as per protocol.
>
> sure, and if the characters are invalid, the application needs to tell
> the kernel, perhaps it would be enough to send and IOCTL or, even
> easier, close the device and reopen it.
>
> > It there is any error in characters/timeout paratmeters, user
> > application will ask to initiate Warm reset.
>
> and for that we can use an IOCTL which is implemented by smart card
> layer. I mean, I'm assuming the smartcard would be seen as a char dev by
> userland so it would be something like this:
>
> ret = read(fd, buf, SIZE);
> if (ret < 0)
>         boom();
>
> ret = process_buffer(buf, ret);
> if (ret == -EINVAL) { /* we have received invalid characters */
>         ret = ioctl(fd, IOCTL_SMARTCARD_WARM_RESET);
>         if (ret < 0)
>                 handle_error();
> }
>
> in kernel space we would have an ioctl handler like so:
>
> static int smart_card_ioctl(struct file *fd, unsigned code, usigned long v)
> {
>         struct smart_card *sc = fd->private_data;
>         unsigned long flags;
>         int ret;
>
>         spin_lock_irqsave(&sc->lock, flags);
>         switch (v)
>         case SMART_CARD_WARM_RESET:
>                 ret = phy_shutdown(sc->phy);
>                 if (ret < 0)
>                         boom();
>
>                 ret = smart_card_reset(sc);
>                 if (ret < 0)
>                         boom();
>
>                 ret = phy_init(sc->phy);
>                 if (ret < 0)
>                         boom();
>                 break;
>         [ ... ]
>         }
>
>         spin_unlock_irqrestore(&sc->lock, flags);
>
>         return ret;
> }
>
> see, we don't need to add a bunch of stuff in the PHY framework, because
> you shouldn't expose the PHY directly to userland. You *must* have an
> abstraction to userland with an in-kernel usage of the PHY layer.
>
> > > > - on activation card will respond with some initial characters
> > > (ATR),
> > > > which will be verified by application, in case of error user
> > > > application will de-activate the card not the phy module
> > > >
> > > > - After activation, use application initiate normal tx/rx
> > > >
> > > > - Once tx/rx is done, it will initiate deactivation of card not the
> > > > phy module.
> > >
> > > then that has nothing to do with the PHY framework, right ?
> >
> > But all such sequence will be initiated by PHY by raising certain
> > signals and only controller can give the push when to start.
>
> sure, that's fair. But you don't need to expose every single detail of
> the PHY. You need to use abstractions to make accesses to the PHY easy
> to maintain. See the example above.
>
> > > > > > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> > > > >
> > > > > Whats should be exactly done here? Looks to me like it should be
> > > > > part of init. Does these pin settings need to be changed
> > > dynamically?
> > > >
> > > > These are all phy pins which will be physically come in contact with
> > > > smart card When inserted. In case of synchronous card, these pins
> > > will
> > > > be toggled manually by s/w bit bang algorithm
> > >
> > > is that a requirement or just something that everybody does ?
> > >
> >
> > Its requirement for synchronous card. At present there is no open driver
> > Which does this thing.
>
> alright, so you need to tell the PHY in which mode it should work and
> the PHY driver needs to be smart enough to choose proper callbacks
> depending on the mode.
>
> > > In any case, you can hide that under some gpio calls, or something
> > > similar.
> >
> > Can't be done using GPIO as pin can be toggled only which i2c read/write
> > to the phy.
>
> so ? look at the numerous I2C GPIO expanders we have in the kernel ;-)
>
> > > > > > Smartcard_get_version -> phy_get_version
> > > > >
> > > > > Again why? Why would the smartcard need the version of the PHY?
> > > > >
> > > >
> > > > Can be omitted. This is for the test suite reference.
> > >
> > > if it's for testsuite, it sounds like something that should be done
> > > through userland and, as such, should be implemented by a set of
> > > debugfs
> > > files which expose the necessary information. That has nothing to do
> > > with the PHY framework.
> > >
> > Agree.. can be omitted.
> >
> >
> > I am ok to give internal webex presentation (TI team) to brief
> > on phy and smart card controller interface.
>
> let's try to cut down on internal agreements and let the community help
> defining a proper way to handle the PHY :-)
>
> Still, if you want to point me and Kishon (privately) to some internal
> documentation, we can certainly read through it :-)
>
> cheers
>
> --
> balbi
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>


From kishon at ti.com  Tue Jul 30 02:25:04 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 30 Jul 2013 11:55:04 +0530
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given
 in usb_bind_phy
In-Reply-To: <20130730061830.GE9155@radagast>
References: <1374829418-27503-1-git-send-email-kishon@ti.com>
 <1374829418-27503-3-git-send-email-kishon@ti.com>
 <20130729150638.GD3063@radagast> <51F68A56.8060805@ti.com>
 <20130729175413.GC4964@radagast> <51F74BC8.7020903@ti.com>
 <20130730060134.GD9155@radagast> <51F7590B.4020705@ti.com>
 <20130730061830.GE9155@radagast>
Message-ID: <51F75C40.4060406@ti.com>

Hi,

On Tuesday 30 July 2013 11:48 AM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 30, 2013 at 11:41:23AM +0530, Kishon Vijay Abraham I wrote:
>>>>>>>> diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
>>>>>>>> index 244d8a5..17bb076 100644
>>>>>>>> --- a/arch/arm/mach-omap2/board-2430sdp.c
>>>>>>>> +++ b/arch/arm/mach-omap2/board-2430sdp.c
>>>>>>>> @@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
>>>>>>>>  	omap_hsmmc_init(mmc);
>>>>>>>>  
>>>>>>>>  	omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
>>>>>>>> -	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
>>>>>>>> +	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
>>>>>>>
>>>>>>> how about moving usb_bind_phy() calls to omap2430.c ?
>>>>>>>
>>>>>>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>>>>>>> index f44e8b5..b6abc1a 100644
>>>>>>> --- a/drivers/usb/musb/omap2430.c
>>>>>>> +++ b/drivers/usb/musb/omap2430.c
>>>>>>> @@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device *pdev)
>>>>>>>  
>>>>>>>  		pdata->board_data	= data;
>>>>>>>  		pdata->config		= config;
>>>>>>> +	} else {
>>>>>>> +		/* bind the PHY */
>>>>>>> +		usb_bind_phy(dev_name(&musb->dev), 0, "twl4030_usb");
>>>>>>
>>>>>> This looks like a hack IMHO to workaround the usb phy library. otherwise it is
>>>>>> similar to get_phy_by_name.
>>>>>
>>>>> actually, this is a workaround to the fact that we're not creating all
>>>>> platform_devices in arch/arm/mach-omap2/ :-)
>>>>>
>>>>> If we had the musb allocation there, we could easily handle
>>>>> usb_bind_phy()
>>>>>
>>>>>>> so that's temporary. It might be better than to reintroduce the IDR in
>>>>>>> musb_core.c.
>>>>>>
>>>>>> that?s needed for generic phy framework anyway :-s
>>>>>
>>>>> right, but generic phy framework can handle everything just fine, the
>>>>> only problem is that names are changing.
>>>>
>>>> right. But if the names change, PHY framework wouldn't be able to return the
>>>> reference to the PHY.
>>>
>>> with my suggestion they can change whenever they want since we're using
>>> dev_name() of the just-created musb platform_device. Right ?
>>
>> right. But the PHY device can be created in a different place from where the
>> musb devices are created. And in the PHY framework, the PHY device should have
> 
> this shouldn't be a problem. As long as the phy is created, all should
> be good.
> 
>> the list of controller device (names) it can support (PHY framework does not
>> maintain a separate list for binding like how we had in USB PHY library). e.g.
>> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg92817.html. In such
> 
> this has nothing to do with $subject though. We talk about generic PHY
> framework once all these PHY drivers are moved there :-)
> 
>> cases how do we pass the device names. Also will the MUSB core device be
>> created before twl4030-usb PHY device?
> 
> and why would that be a problem ? We're telling the framework that the
> musb device will use a phy with a name of 'twl4030'. If musb calls
> usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and
> try again later.

I think we are talking about different problems here ;-) I'm trying to tell
using idr in MUSB core is needed for Generic PHY Framework. So in a way, the
Generic PHY Framework series depends on this patch series or else MUSB in OMAP3
platforms wont work after Generic PHY framework gets merged.

Thanks
Kishon


From balbi at ti.com  Tue Jul 30 02:28:44 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 30 Jul 2013 09:28:44 +0300
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given in
 usb_bind_phy
In-Reply-To: <51F75C40.4060406@ti.com>
References: <1374829418-27503-1-git-send-email-kishon@ti.com>
 <1374829418-27503-3-git-send-email-kishon@ti.com>
 <20130729150638.GD3063@radagast> <51F68A56.8060805@ti.com>
 <20130729175413.GC4964@radagast> <51F74BC8.7020903@ti.com>
 <20130730060134.GD9155@radagast> <51F7590B.4020705@ti.com>
 <20130730061830.GE9155@radagast> <51F75C40.4060406@ti.com>
Message-ID: <20130730062844.GH9155@radagast>

Hi,

On Tue, Jul 30, 2013 at 11:55:04AM +0530, Kishon Vijay Abraham I wrote:
> > On Tue, Jul 30, 2013 at 11:41:23AM +0530, Kishon Vijay Abraham I wrote:
> >>>>>>>> diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
> >>>>>>>> index 244d8a5..17bb076 100644
> >>>>>>>> --- a/arch/arm/mach-omap2/board-2430sdp.c
> >>>>>>>> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> >>>>>>>> @@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
> >>>>>>>>  	omap_hsmmc_init(mmc);
> >>>>>>>>  
> >>>>>>>>  	omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
> >>>>>>>> -	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
> >>>>>>>> +	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
> >>>>>>>
> >>>>>>> how about moving usb_bind_phy() calls to omap2430.c ?
> >>>>>>>
> >>>>>>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> >>>>>>> index f44e8b5..b6abc1a 100644
> >>>>>>> --- a/drivers/usb/musb/omap2430.c
> >>>>>>> +++ b/drivers/usb/musb/omap2430.c
> >>>>>>> @@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device *pdev)
> >>>>>>>  
> >>>>>>>  		pdata->board_data	= data;
> >>>>>>>  		pdata->config		= config;
> >>>>>>> +	} else {
> >>>>>>> +		/* bind the PHY */
> >>>>>>> +		usb_bind_phy(dev_name(&musb->dev), 0, "twl4030_usb");
> >>>>>>
> >>>>>> This looks like a hack IMHO to workaround the usb phy library. otherwise it is
> >>>>>> similar to get_phy_by_name.
> >>>>>
> >>>>> actually, this is a workaround to the fact that we're not creating all
> >>>>> platform_devices in arch/arm/mach-omap2/ :-)
> >>>>>
> >>>>> If we had the musb allocation there, we could easily handle
> >>>>> usb_bind_phy()
> >>>>>
> >>>>>>> so that's temporary. It might be better than to reintroduce the IDR in
> >>>>>>> musb_core.c.
> >>>>>>
> >>>>>> that?s needed for generic phy framework anyway :-s
> >>>>>
> >>>>> right, but generic phy framework can handle everything just fine, the
> >>>>> only problem is that names are changing.
> >>>>
> >>>> right. But if the names change, PHY framework wouldn't be able to return the
> >>>> reference to the PHY.
> >>>
> >>> with my suggestion they can change whenever they want since we're using
> >>> dev_name() of the just-created musb platform_device. Right ?
> >>
> >> right. But the PHY device can be created in a different place from where the
> >> musb devices are created. And in the PHY framework, the PHY device should have
> > 
> > this shouldn't be a problem. As long as the phy is created, all should
> > be good.
> > 
> >> the list of controller device (names) it can support (PHY framework does not
> >> maintain a separate list for binding like how we had in USB PHY library). e.g.
> >> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg92817.html. In such
> > 
> > this has nothing to do with $subject though. We talk about generic PHY
> > framework once all these PHY drivers are moved there :-)
> > 
> >> cases how do we pass the device names. Also will the MUSB core device be
> >> created before twl4030-usb PHY device?
> > 
> > and why would that be a problem ? We're telling the framework that the
> > musb device will use a phy with a name of 'twl4030'. If musb calls
> > usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and
> > try again later.
> 
> I think we are talking about different problems here ;-) I'm trying to tell
> using idr in MUSB core is needed for Generic PHY Framework. So in a way, the
> Generic PHY Framework series depends on this patch series or else MUSB in OMAP3
> platforms wont work after Generic PHY framework gets merged.

then you just found a limitation in your framework, right ? :-) I mean,
imagine if now we have to add an IDR to every single user of your
framework because they could end up in systems with multiple instances
of the same IP ?

Now consider that you aim to have your framework be used by Network,
USB, SATA, Graphics, etc... Have you really only considered DT
platforms ? DT is quite easy since you can require folks to pass the
proper phandle, but drivers will want to use PLATFORM_DEVID_AUTO and
your framework needs to cope with that.

-- 
balbi
-------------- 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/20130730/6d076c74/attachment.sig>

From LW at KARO-electronics.de  Tue Jul 30 02:37:05 2013
From: LW at KARO-electronics.de (=?utf-8?Q?Lothar_Wa=C3=9Fmann?=)
Date: Tue, 30 Jul 2013 08:37:05 +0200
Subject: [PATCH v2] ARM: imx: pllv1: Fix PLL calculation for i.MX27
In-Reply-To: <1375112243-1557-1-git-send-email-shc_work@mail.ru>
References: <1375112243-1557-1-git-send-email-shc_work@mail.ru>
Message-ID: <20983.24337.582506.529947@ipc1.ka-ro>

Hi,

Alexander Shiyan writes:
> MFN bit 9 on i.MX27 has a different meaning than in other SOCs. This
> is a just sign bit. This patch makes different calculation for i.MX27.
> 
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  arch/arm/mach-imx/clk-pllv1.c | 16 +++++++++++++---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/clk-pllv1.c b/arch/arm/mach-imx/clk-pllv1.c
> index c1eaee3..a289ccd 100644
> --- a/arch/arm/mach-imx/clk-pllv1.c
> +++ b/arch/arm/mach-imx/clk-pllv1.c
> @@ -25,6 +25,11 @@ struct clk_pllv1 {
>  
>  #define to_clk_pllv1(clk) (container_of(clk, struct clk_pllv1, clk))
>  
> +static inline bool allow_signed_mfn(void)
> +{
> +	return !cpu_is_mx1() && !cpu_is_mx21();
> +}
> +
>  static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
>  		unsigned long parent_rate)
>  {
> @@ -59,9 +64,14 @@ static unsigned long clk_pllv1_recalc_rate(struct clk_hw *hw,
>  	/*
>  	 * On all i.MXs except i.MX1 and i.MX21 mfn is a 10bit
>  	 * 2's complements number
> +	 * On i.MX27 the bit 9 is the sign bit.
>  	 */
> -	if (!cpu_is_mx1() && !cpu_is_mx21() && mfn >= 0x200)
> -		mfn_abs = 0x400 - mfn;
> +	if (allow_signed_mfn() && (mfn & 0x200)) {
> +		if (cpu_is_mx27())
> +			mfn_abs = mfn & 0x1ff;
> +		else
> +			mfn_abs = 0x400 - mfn;
> +	}
>  
Please don't hardcode magic numbers. Even more when using variants of
the same number like 0x200 and 0x1ff (0x200 - 1) in multiple places.
If someone copies the code and wants to adapt it, they will have to
change lots of different but related numbers in different places which
is horribly error prone.

#define MFN_BITS 10
#define MFN_SIGN (1 << (MFN_BITS - 1))
#define MFN_MASK (MFN_SIGN - 1)
With these defines you can derive all the numbers you need in a
consistent way and need to change only ONE place to adapt the code.


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________


From tomi.valkeinen at ti.com  Tue Jul 30 02:39:32 2013
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 30 Jul 2013 09:39:32 +0300
Subject: [PATCH 06/21] ARM: OMAP: overo: use new display drivers
In-Reply-To: <51F75B6A.6090900@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
 <1374822504-28949-7-git-send-email-tomi.valkeinen@ti.com>
 <51F75B6A.6090900@ti.com>
Message-ID: <51F75FA4.1050406@ti.com>

On 30/07/13 09:21, Archit Taneja wrote:
> Hi,
> 
> On Friday 26 July 2013 12:38 PM, Tomi Valkeinen wrote:
>> Use the new display drivers for OMAP3 Overo board.
>>
>> The new OMAP display drivers were merged for 3.11, and we can now change
>> the board files to use the new ones and phase out the old ones.
>>
>> Note that the LCD add-on boards for lcd43 and lcd35 use the same GPIOs
>> for the panels. This means that both panel devices cannot be probed at
>> the same time.
>>
>> DT will handle this correctly, i.e. the DT data will contain the panel
>> device only for the add-on board that is attached. However, for the
>> board file we need a hackish solution: We parse the kernel boot command
>> line, and see whether lcd43 or lcd35 is set as a default display, and
>> add the given one. Or, if neither is given, default to lcd43.
>>
> 
> <snip>
> 
>>   static struct omap_dss_board_info overo_dss_data = {
>> -    .num_devices    = ARRAY_SIZE(overo_dss_devices),
>> -    .devices    = overo_dss_devices,
>> -    .default_device    = &overo_dvi_device,
>> +    .default_display_name = "lcd43",
>>   };
> 
> The default display previously was the dvi device, if both lcd43 and
> lcd35 are on add-on boards, then we should probably stick to dvi itself,
> right? The hack won't work if dvi is the default device though.

DVI is also on an add-on board, but it doesn't conflict with lcd43 or lcd35.

The hack works fine even if DVI is the default device. In that case, it
doesn't matter if lcd43 or lcd35 is added, because the user doesn't use
them (as long as only one of them is added, because otherwise there'll
be an error during probe).

If DVI is the default device, we could actually skip adding both lcd43
and lcd35. I just wanted to minimize the code in this hack, so I didn't
do that.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130730/7fcbb0f8/attachment.sig>

From shawn.guo at linaro.org  Tue Jul 30 02:46:54 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 30 Jul 2013 14:46:54 +0800
Subject: [PATCH] dts: wandboard: Add support for SDIO bcm4329
In-Reply-To: <1374969621-4187-1-git-send-email-linux@prisktech.co.nz>
References: <1374969621-4187-1-git-send-email-linux@prisktech.co.nz>
Message-ID: <20130730064652.GB12382@S2101-09.ap.freescale.net>

On Sun, Jul 28, 2013 at 12:00:20PM +1200, Tony Prisk wrote:
> The wandboard has a Broadcom 4329 WiFi connected via SDIO. This patch
> sets the required pins to enable the wifi module.
> 
> Signed-off-by: Tony Prisk <linux at prisktech.co.nz>

Applied, thanks.



From kishon at ti.com  Tue Jul 30 02:46:20 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 30 Jul 2013 12:16:20 +0530
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given
 in usb_bind_phy
In-Reply-To: <20130730062844.GH9155@radagast>
References: <1374829418-27503-1-git-send-email-kishon@ti.com>
 <1374829418-27503-3-git-send-email-kishon@ti.com>
 <20130729150638.GD3063@radagast> <51F68A56.8060805@ti.com>
 <20130729175413.GC4964@radagast> <51F74BC8.7020903@ti.com>
 <20130730060134.GD9155@radagast> <51F7590B.4020705@ti.com>
 <20130730061830.GE9155@radagast> <51F75C40.4060406@ti.com>
 <20130730062844.GH9155@radagast>
Message-ID: <51F7613C.5070803@ti.com>

Hi,

On Tuesday 30 July 2013 11:58 AM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 30, 2013 at 11:55:04AM +0530, Kishon Vijay Abraham I wrote:
>>> On Tue, Jul 30, 2013 at 11:41:23AM +0530, Kishon Vijay Abraham I wrote:
>>>>>>>>>> diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
>>>>>>>>>> index 244d8a5..17bb076 100644
>>>>>>>>>> --- a/arch/arm/mach-omap2/board-2430sdp.c
>>>>>>>>>> +++ b/arch/arm/mach-omap2/board-2430sdp.c
>>>>>>>>>> @@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
>>>>>>>>>>  	omap_hsmmc_init(mmc);
>>>>>>>>>>  
>>>>>>>>>>  	omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
>>>>>>>>>> -	usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
>>>>>>>>>> +	usb_bind_phy("musb-hdrc.0", 0, "twl4030_usb");
>>>>>>>>>
>>>>>>>>> how about moving usb_bind_phy() calls to omap2430.c ?
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>>>>>>>>> index f44e8b5..b6abc1a 100644
>>>>>>>>> --- a/drivers/usb/musb/omap2430.c
>>>>>>>>> +++ b/drivers/usb/musb/omap2430.c
>>>>>>>>> @@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device *pdev)
>>>>>>>>>  
>>>>>>>>>  		pdata->board_data	= data;
>>>>>>>>>  		pdata->config		= config;
>>>>>>>>> +	} else {
>>>>>>>>> +		/* bind the PHY */
>>>>>>>>> +		usb_bind_phy(dev_name(&musb->dev), 0, "twl4030_usb");
>>>>>>>>
>>>>>>>> This looks like a hack IMHO to workaround the usb phy library. otherwise it is
>>>>>>>> similar to get_phy_by_name.
>>>>>>>
>>>>>>> actually, this is a workaround to the fact that we're not creating all
>>>>>>> platform_devices in arch/arm/mach-omap2/ :-)
>>>>>>>
>>>>>>> If we had the musb allocation there, we could easily handle
>>>>>>> usb_bind_phy()
>>>>>>>
>>>>>>>>> so that's temporary. It might be better than to reintroduce the IDR in
>>>>>>>>> musb_core.c.
>>>>>>>>
>>>>>>>> that?s needed for generic phy framework anyway :-s
>>>>>>>
>>>>>>> right, but generic phy framework can handle everything just fine, the
>>>>>>> only problem is that names are changing.
>>>>>>
>>>>>> right. But if the names change, PHY framework wouldn't be able to return the
>>>>>> reference to the PHY.
>>>>>
>>>>> with my suggestion they can change whenever they want since we're using
>>>>> dev_name() of the just-created musb platform_device. Right ?
>>>>
>>>> right. But the PHY device can be created in a different place from where the
>>>> musb devices are created. And in the PHY framework, the PHY device should have
>>>
>>> this shouldn't be a problem. As long as the phy is created, all should
>>> be good.
>>>
>>>> the list of controller device (names) it can support (PHY framework does not
>>>> maintain a separate list for binding like how we had in USB PHY library). e.g.
>>>> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg92817.html. In such
>>>
>>> this has nothing to do with $subject though. We talk about generic PHY
>>> framework once all these PHY drivers are moved there :-)
>>>
>>>> cases how do we pass the device names. Also will the MUSB core device be
>>>> created before twl4030-usb PHY device?
>>>
>>> and why would that be a problem ? We're telling the framework that the
>>> musb device will use a phy with a name of 'twl4030'. If musb calls
>>> usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and
>>> try again later.
>>
>> I think we are talking about different problems here ;-) I'm trying to tell
>> using idr in MUSB core is needed for Generic PHY Framework. So in a way, the
>> Generic PHY Framework series depends on this patch series or else MUSB in OMAP3
>> platforms wont work after Generic PHY framework gets merged.
> 
> then you just found a limitation in your framework, right ? :-) I mean,
> imagine if now we have to add an IDR to every single user of your
> framework because they could end up in systems with multiple instances
> of the same IP ?

I raised a similar concern in the PHY framework discussion [1] :-) And since
it's used everywhere else regulators, clkdev, etc.. it's agreed to be used in
PHY as well. Btw if PLATFORM_DEVID_AUTO is used even regulator, clk_get should
fail IMO.

[1] -> http://lkml.indiana.edu/hypermail/linux/kernel/1307.2/03573.html

Thanks
Kishon


From mturquette at linaro.org  Tue Jul 30 02:46:56 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 29 Jul 2013 23:46:56 -0700
Subject: [PATCH v8 05/12] clk: exynos5250: add gate clock descriptions
 of System MMU
In-Reply-To: <001901ce8aa8$d1d6fef0$7584fcd0$@samsung.com>
References: <003b01ce89f3$2be4db80$83ae9280$@samsung.com>
 <20130726200107.7598.82010@quantum>
 <001901ce8aa8$d1d6fef0$7584fcd0$@samsung.com>
Message-ID: <20130730064655.22022.62937@quantum>

Quoting Cho KyongHo (2013-07-27 02:08:11)
> > -----Original Message-----
> > From: Mike Turquette [mailto:mturquette at linaro.org]
> > Sent: Saturday, July 27, 2013 5:01 AM
> > 
> > Quoting Cho KyongHo (2013-07-26 04:27:54)
> > > This adds gate clocks of all System MMUs and their master IPs
> > > that are not apeared in clk-exynos5250.c
> > >
> > > Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> > 
> > Change looks good to me. Are you OK if I take it into the clk tree or do
> > you want to keep this series together?
> 
> I would like you to pick this to your tree and let me know which branch
> contains this patch.
> Then I will remove this from my patch series.

camif_top corresponds to 345 in your patch, but this conflicts the g2d
clock introduced in patch "clk: exynos5250: Add G2D gate clock" in the
clk tree. I've pushed out the latest clk-next branch with this change:

git://git.linaro.org/people/mturquette/linux.git clk-next

Can you rebase your change on top of this and resolve the clock id
mapping?

Thanks,
Mike

> 
> Thank you,
> Cho KyongHo.
> > 
> > Regards,
> > Mike
> > 
> > > ---
> > >  .../devicetree/bindings/clock/exynos5250-clock.txt |   28 +++++++++-
> > >  drivers/clk/samsung/clk-exynos5250.c               |   57 ++++++++++++++++---
> > >  2 files changed, 75 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > > b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > > index 781a627..df49694 100644
> > > --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > > +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > > @@ -154,7 +154,33 @@ clock which they consume.
> > >    dsim0                        341
> > >    dp                   342
> > >    mixer                        343
> > > -  hdmi                 345
> > > +  hdmi                 344
> > > +  camif_top            345
> > > +  smmu_fimc_lite0      346
> > > +  smmu_fimc_lite1      347
> > > +  smmu_fimc_lite2      348
> > > +  smmu_tv              349
> > > +  smmu_fimd1           350
> > > +  smmu_2d              351
> > > +  fimc_isp             352
> > > +  fimc_drc             353
> > > +  fimc_fd              354
> > > +  fimc_scc             355
> > > +  fimc_scp             356
> > > +  fimc_mcuctl          357
> > > +  fimc_odc             358
> > > +  fimc_dis             359
> > > +  fimc_3dnr            360
> > > +  smmu_fimc_isp                361
> > > +  smmu_fimc_drc                362
> > > +  smmu_fimc_fd         363
> > > +  smmu_fimc_scc                364
> > > +  smmu_fimc_scp                365
> > > +  smmu_fimc_mcuctl     366
> > > +  smmu_fimc_odc                367
> > > +  smmu_fimc_dis0       368
> > > +  smmu_fimc_dis1       369
> > > +  smmu_fimc_3dnr       370
> > >
> > >  Example 1: An example of a clock controller node is listed below.
> > >
> > > diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
> > > index 22d7699..e242bde 100644
> > > --- a/drivers/clk/samsung/clk-exynos5250.c
> > > +++ b/drivers/clk/samsung/clk-exynos5250.c
> > > @@ -53,12 +53,15 @@
> > >  #define DIV_PERIC3             0x10564
> > >  #define DIV_PERIC4             0x10568
> > >  #define DIV_PERIC5             0x1056c
> > > +#define GATE_IP_ISP0           0x0C800
> > > +#define GATE_IP_ISP1           0x0C800
> > >  #define GATE_IP_GSCL           0x10920
> > >  #define GATE_IP_MFC            0x1092c
> > >  #define GATE_IP_GEN            0x10934
> > >  #define GATE_IP_FSYS           0x10944
> > >  #define GATE_IP_PERIC          0x10950
> > >  #define GATE_IP_PERIS          0x10960
> > > +#define GATE_IP_ACP            0x18800
> > >  #define SRC_CDREX              0x20200
> > >  #define PLL_DIV2_SEL           0x20a24
> > >  #define GATE_IP_DISP1          0x10928
> > > @@ -100,6 +103,14 @@ enum exynos5250_clks {
> > >         tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
> > >         wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
> > >
> > > +       camif_top, smmu_fimc_lite0, smmu_fimc_lite1, smmu_fimc_lite2,
> > > +       smmu_tv, smmu_fimd1, smmu_2d,
> > > +       fimc_isp, fimc_drc, fimc_fd, fimc_scc, fimc_scp, fimc_mcuctl, fimc_odc,
> > > +       fimc_dis, fimc_3dnr,
> > > +       smmu_fimc_isp, smmu_fimc_drc, smmu_fimc_fd, smmu_fimc_scc,
> > > +       smmu_fimc_scp, smmu_fimc_mcuctl, smmu_fimc_odc, smmu_fimc_dis0,
> > > +       smmu_fimc_dis1, smmu_fimc_3dnr,
> > > +
> > >         nr_clks,
> > >  };
> > >
> > > @@ -320,19 +331,26 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
> > >         GATE(gscl3, "gscl3", "aclk266", GATE_IP_GSCL, 3, 0, 0),
> > >         GATE(gscl_wa, "gscl_wa", "div_gscl_wa", GATE_IP_GSCL, 5, 0, 0),
> > >         GATE(gscl_wb, "gscl_wb", "div_gscl_wb", GATE_IP_GSCL, 6, 0, 0),
> > > -       GATE(smmu_gscl0, "smmu_gscl0", "aclk266", GATE_IP_GSCL, 7, 0, 0),
> > > -       GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
> > > -       GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
> > > -       GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
> > > +       GATE(smmu_gscl0, "smmu_gscl0", "none", GATE_IP_GSCL, 7, 0, 0),
> > > +       GATE(smmu_gscl1, "smmu_gscl1", "none", GATE_IP_GSCL, 8, 0, 0),
> > > +       GATE(smmu_gscl2, "smmu_gscl2", "none", GATE_IP_GSCL, 9, 0, 0),
> > > +       GATE(smmu_gscl3, "smmu_gscl3", "none", GATE_IP_GSCL, 10, 0, 0),
> > > +       GATE(camif_top, "camif_top", "aclk266", GATE_IP_GSCL, 4, 0, 0),
> > > +       GATE(smmu_fimc_lite0, "smmu_fimc_lite0", "none",
> > > +                                               GATE_IP_GSCL, 12, 0, 0),
> > > +       GATE(smmu_fimc_lite1, "smmu_fimc_lite1", "none",
> > > +                                               GATE_IP_GSCL, 13, 0, 0),
> > > +       GATE(smmu_fimc_lite2, "smmu_fimc_lite2", "none",
> > > +                                               GATE_IP_GSCL, 14, 0, 0),
> > >         GATE(mfc, "mfc", "aclk333", GATE_IP_MFC, 0, 0, 0),
> > > -       GATE(smmu_mfcl, "smmu_mfcl", "aclk333", GATE_IP_MFC, 1, 0, 0),
> > > -       GATE(smmu_mfcr, "smmu_mfcr", "aclk333", GATE_IP_MFC, 2, 0, 0),
> > > +       GATE(smmu_mfcr, "smmu_mfcr", "none", GATE_IP_MFC, 1, 0, 0),
> > > +       GATE(smmu_mfcl, "smmu_mfcl", "none", GATE_IP_MFC, 2, 0, 0),
> > >         GATE(rotator, "rotator", "aclk266", GATE_IP_GEN, 1, 0, 0),
> > >         GATE(jpeg, "jpeg", "aclk166", GATE_IP_GEN, 2, 0, 0),
> > >         GATE(mdma1, "mdma1", "aclk266", GATE_IP_GEN, 4, 0, 0),
> > > -       GATE(smmu_rotator, "smmu_rotator", "aclk266", GATE_IP_GEN, 6, 0, 0),
> > > -       GATE(smmu_jpeg, "smmu_jpeg", "aclk166", GATE_IP_GEN, 7, 0, 0),
> > > -       GATE(smmu_mdma1, "smmu_mdma1", "aclk266", GATE_IP_GEN, 9, 0, 0),
> > > +       GATE(smmu_rotator, "smmu_rotator", "none", GATE_IP_GEN, 6, 0, 0),
> > > +       GATE(smmu_jpeg, "smmu_jpeg", "none", GATE_IP_GEN, 7, 0, 0),
> > > +       GATE(smmu_mdma1, "smmu_mdma1", "none", GATE_IP_GEN, 9, 0, 0),
> > >         GATE(pdma0, "pdma0", "aclk200", GATE_IP_FSYS, 1, 0, 0),
> > >         GATE(pdma1, "pdma1", "aclk200", GATE_IP_FSYS, 2, 0, 0),
> > >         GATE(sata, "sata", "aclk200", GATE_IP_FSYS, 6, 0, 0),
> > > @@ -462,6 +480,27 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
> > >         GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
> > >         GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
> > >         GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
> > > +       GATE(smmu_tv, "smmu_tv", "none", GATE_IP_DISP1, 2, 0, 0),
> > > +       GATE(smmu_fimd1, "smmu_fimd1", "none", GATE_IP_DISP1, 8, 0, 0),
> > > +
> > > +       GATE(smmu_fimc_isp, "smmu_fimc_isp", "none", GATE_IP_ISP0, 8, 0, 0),
> > > +       GATE(smmu_fimc_drc, "smmu_fimc_drc", "none", GATE_IP_ISP0, 9, 0, 0),
> > > +       GATE(smmu_fimc_fd, "smmu_fimc_fd", "none", GATE_IP_ISP0, 10, 0, 0),
> > > +       GATE(smmu_fimc_scc, "smmu_fimc_scc", "none",
> > > +                                                       GATE_IP_ISP0, 11, 0, 0),
> > > +       GATE(smmu_fimc_scp, "smmu_fimc_scp", "none",
> > > +                                                       GATE_IP_ISP0, 12, 0, 0),
> > > +       GATE(smmu_fimc_mcuctl, "smmu_fimc_mcuctl", "none",
> > > +                                                       GATE_IP_ISP0, 13, 0, 0),
> > > +       GATE(smmu_fimc_odc, "smmu_fimc_odc", "none", GATE_IP_ISP1, 4, 0, 0),
> > > +       GATE(smmu_fimc_dis0, "smmu_fimc_dis0", "none",
> > > +                                                       GATE_IP_ISP1, 5, 0, 0),
> > > +       GATE(smmu_fimc_dis1, "smmu_fimc_dis1", "none",
> > > +                                                       GATE_IP_ISP1, 6, 0, 0),
> > > +       GATE(smmu_fimc_3dnr, "smmu_fimc_3dnr", "none",
> > > +                                                       GATE_IP_ISP1, 7, 0, 0),
> > > +
> > > +       GATE(smmu_2d, "smmu_2d", "none", GATE_IP_ACP, 7, 0, 0),
> > >  };
> > >
> > >  static __initdata struct of_device_id ext_clk_match[] = {
> > > --
> > > 1.7.2.5
> > >
> > >
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From shawn.guo at linaro.org  Tue Jul 30 02:48:20 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 30 Jul 2013 14:48:20 +0800
Subject: [PATCH 1/2] ARM: imx_v6_v7_defconfig: Cleanup imx_v6_v7_defconfig
In-Reply-To: <1375067056-6370-1-git-send-email-festevam@gmail.com>
References: <1375067056-6370-1-git-send-email-festevam@gmail.com>
Message-ID: <20130730064818.GC12382@S2101-09.ap.freescale.net>

On Mon, Jul 29, 2013 at 12:04:15AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> Generate imx_v6_v7_defconfig by doing:
> 
> make savedefconfig
> 
> cp defconfig arch/arm/configs/imx_v6_v7_defconfig
> 
> No functional change. The goal here is to cleanup imx_v6_v7_defconfig file to
> make easier and cleaner the addition of new entries.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>

Applied both, thanks.



From mturquette at linaro.org  Tue Jul 30 02:48:00 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Mon, 29 Jul 2013 23:48:00 -0700
Subject: [PATCH 1/3] clk: exynos5250: Add G2D gate clock
In-Reply-To: <CAK9yfHw6KtVDAns-1JhNpiS0brTeUpfiHS-v3q7H2GLWkY-Adw@mail.gmail.com>
References: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
 <20130726201800.7598.54329@quantum>
 <CAK9yfHw6KtVDAns-1JhNpiS0brTeUpfiHS-v3q7H2GLWkY-Adw@mail.gmail.com>
Message-ID: <20130730064800.22022.14773@quantum>

Quoting Sachin Kamat (2013-07-27 06:29:56)
> On 27 July 2013 01:48, Mike Turquette <mturquette at linaro.org> wrote:
> > Quoting Sachin Kamat (2013-07-05 01:42:27)
> >> Adds gate clock for G2D IP for Exynos5250 SoC.
> >>
> >> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> >> Cc: Mike Turquette <mturquette at linaro.org>
> >
> > I've taken patch #1 into clk-next.
> 
> Thanks Mike.
> 
> >
> >> ---
> >> This patch depends on the following patch:
> >> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20581
> >
> > I think I've gotten all three series you sent out, can you confirm?
> 
> I haven't seen any update in your tree [1] since quite some time. The
> last commit I see in clk-next branch is 45e3ec3784 ("clk: tegra: fix
> ifdef for tegra_periph_reset_assert inline"). I hope I am looking at
> the right tree?

You are, but I had not pushed to it since the merge window closed. It is
now updated.

Regards,
Mike

> 
> [1] git://git.linaro.org/people/mturquette/linux.git
> 
> -- 
> With warm regards,
> Sachin


From tony at atomide.com  Tue Jul 30 02:52:54 2013
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 29 Jul 2013 23:52:54 -0700
Subject: [PATCH V2 0/3] ARM: dts: omap5-uevm: fixup wrong regulator
 configuration
In-Reply-To: <51F6EA23.50803@gmail.com>
References: <51F67D7D.9070003@ti.com>
 <1375117383-19285-1-git-send-email-nm@ti.com>
 <51F6EA23.50803@gmail.com>
Message-ID: <20130730065253.GE7656@atomide.com>

* Benoit Cousson <benoit.cousson at gmail.com> [130729 15:24]:
> Hi Nishanth,
> 
> Thanks for the quick update.
> 
> On 29/07/2013 19:03, Nishanth Menon wrote:
> > Due to wrong older revision of documentation used as reference, we
> > seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
> > series is based power tree on production board 750-2628-XXX platform.
> > Unfortunately, the wrong voltages may be detrimental to OMAP5 as they
> > supply hardware blocks at voltages that are out of specification.
> >
> > Also available at:
> > based on v3.11-rc1 tag
> > http link: https://github.com/nmenon/linux-2.6-playground/commits/push/omap5-palmas-fixes-v2
> > git link: git://github.com/nmenon/linux-2.6-playground.git
> > branch: push/omap5-palmas-fixes-v2
> >
> > Changes since V1:
> >  - squash of patches
> >  - picked up Ack from Keerthy
> >  - based on v3.11-rc3 tag
> >
> > V1: http://marc.info/?t=137407980100008&r=1&w=2
> >
> > Nishanth Menon (3):
> >   ARM: dts: omap5-uevm: document regulator signals used on the actual
> >     board
> >   ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC
> >   ARM: dts: omap5-uevm: update optional/unused regulator configurations
> >
> >  arch/arm/boot/dts/omap5-uevm.dts |   78 ++++++++++++++++++++++++--------------
> >  1 file changed, 49 insertions(+), 29 deletions(-)
> >
> > Regards,
> > Nishanth Menon
> 
> For the whole series:
> 
> Acked-by: Benoit Cousson <benoit.cousson at gmail.com>

Thanks, I've applied these into omap-for-v3.11/fixes-omap5
and will send a pull request for these today as these seem
quite urgent fixes.

Regards,

Tony


From sachin.kamat at linaro.org  Tue Jul 30 02:55:33 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Tue, 30 Jul 2013 12:25:33 +0530
Subject: [PATCH 1/3] clk: exynos5250: Add G2D gate clock
In-Reply-To: <20130730064800.22022.14773@quantum>
References: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
 <20130726201800.7598.54329@quantum>
 <CAK9yfHw6KtVDAns-1JhNpiS0brTeUpfiHS-v3q7H2GLWkY-Adw@mail.gmail.com>
 <20130730064800.22022.14773@quantum>
Message-ID: <CAK9yfHxLjYNjQ9h-N8hNLBvqyUTxNzt=Bw10=mEA=D1kg2f9dw@mail.gmail.com>

On 30 July 2013 12:18, Mike Turquette <mturquette at linaro.org> wrote:
> Quoting Sachin Kamat (2013-07-27 06:29:56)
>> On 27 July 2013 01:48, Mike Turquette <mturquette at linaro.org> wrote:
>> > Quoting Sachin Kamat (2013-07-05 01:42:27)
>> >> Adds gate clock for G2D IP for Exynos5250 SoC.
>> >>
>> >> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
>> >> Cc: Mike Turquette <mturquette at linaro.org>
>> >
>> > I've taken patch #1 into clk-next.
>>
>> Thanks Mike.
>>
>> >
>> >> ---
>> >> This patch depends on the following patch:
>> >> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20581
>> >
>> > I think I've gotten all three series you sent out, can you confirm?
>>
>> I haven't seen any update in your tree [1] since quite some time. The
>> last commit I see in clk-next branch is 45e3ec3784 ("clk: tegra: fix
>> ifdef for tegra_periph_reset_assert inline"). I hope I am looking at
>> the right tree?
>
> You are, but I had not pushed to it since the merge window closed. It is
> now updated.
>

Thanks Mike. I confirm that all the three patch series that you
mentioned are applied in your tree.
Please check the below one too.

http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg20598.html

-- 
With warm regards,
Sachin


From nsekhar at ti.com  Tue Jul 30 03:05:02 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 30 Jul 2013 12:35:02 +0530
Subject: [PATCH 4/9] dma: edma: Find missed events and issue them
In-Reply-To: <1375104595-16018-5-git-send-email-joelf@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
 <1375104595-16018-5-git-send-email-joelf@ti.com>
Message-ID: <51F7659E.3040302@ti.com>

On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
> In an effort to move to using Scatter gather lists of any size with
> EDMA as discussed at [1] instead of placing limitations on the driver,
> we work through the limitations of the EDMAC hardware to find missed
> events and issue them.
> 
> The sequence of events that require this are:
> 
> For the scenario where MAX slots for an EDMA channel is 3:
> 
> SG1 -> SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> Null
> 
> The above SG list will have to be DMA'd in 2 sets:
> 
> (1) SG1 -> SG2 -> SG3 -> Null
> (2) SG4 -> SG5 -> SG6 -> Null
> 
> After (1) is succesfully transferred, the events from the MMC controller
> donot stop coming and are missed by the time we have setup the transfer
> for (2). So here, we catch the events missed as an error condition and
> issue them manually.

Are you sure there wont be any effect of these missed events on the
peripheral side. For example, wont McASP get into an underrun condition
when it encounters a null PaRAM set? Even UART has to transmit to a
particular baud so I guess it cannot wait like the way MMC/SD can.

Also, wont this lead to under-utilization of the peripheral bandwith?
Meaning, MMC/SD is ready with data but cannot transfer because the DMA
is waiting to be set-up.

Did you consider a ping-pong scheme with say three PaRAM sets per
channel? That way you can keep a continuous transfer going on from the
peripheral over the complete SG list.

Thanks,
Sekhar



From archit at ti.com  Tue Jul 30 03:07:24 2013
From: archit at ti.com (Archit Taneja)
Date: Tue, 30 Jul 2013 12:37:24 +0530
Subject: [PATCH 06/21] ARM: OMAP: overo: use new display drivers
In-Reply-To: <51F75FA4.1050406@ti.com>
References: <1374822504-28949-1-git-send-email-tomi.valkeinen@ti.com>
 <1374822504-28949-7-git-send-email-tomi.valkeinen@ti.com>
 <51F75B6A.6090900@ti.com> <51F75FA4.1050406@ti.com>
Message-ID: <51F7662C.1060302@ti.com>

On Tuesday 30 July 2013 12:09 PM, Tomi Valkeinen wrote:
> On 30/07/13 09:21, Archit Taneja wrote:
>> Hi,
>>
>> On Friday 26 July 2013 12:38 PM, Tomi Valkeinen wrote:
>>> Use the new display drivers for OMAP3 Overo board.
>>>
>>> The new OMAP display drivers were merged for 3.11, and we can now change
>>> the board files to use the new ones and phase out the old ones.
>>>
>>> Note that the LCD add-on boards for lcd43 and lcd35 use the same GPIOs
>>> for the panels. This means that both panel devices cannot be probed at
>>> the same time.
>>>
>>> DT will handle this correctly, i.e. the DT data will contain the panel
>>> device only for the add-on board that is attached. However, for the
>>> board file we need a hackish solution: We parse the kernel boot command
>>> line, and see whether lcd43 or lcd35 is set as a default display, and
>>> add the given one. Or, if neither is given, default to lcd43.
>>>
>>
>> <snip>
>>
>>>    static struct omap_dss_board_info overo_dss_data = {
>>> -    .num_devices    = ARRAY_SIZE(overo_dss_devices),
>>> -    .devices    = overo_dss_devices,
>>> -    .default_device    = &overo_dvi_device,
>>> +    .default_display_name = "lcd43",
>>>    };
>>
>> The default display previously was the dvi device, if both lcd43 and
>> lcd35 are on add-on boards, then we should probably stick to dvi itself,
>> right? The hack won't work if dvi is the default device though.
>
> DVI is also on an add-on board, but it doesn't conflict with lcd43 or lcd35.
>
> The hack works fine even if DVI is the default device. In that case, it
> doesn't matter if lcd43 or lcd35 is added, because the user doesn't use
> them (as long as only one of them is added, because otherwise there'll
> be an error during probe).
>
> If DVI is the default device, we could actually skip adding both lcd43
> and lcd35. I just wanted to minimize the code in this hack, so I didn't
> do that.

Okay, thanks for the clarification, looks fine then.

Archit



From balbi at ti.com  Tue Jul 30 03:11:06 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 30 Jul 2013 10:11:06 +0300
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130721154653.GG16598@kroah.com>
References: <20130720220006.GA7977@kroah.com> <3839600.WiC1OLF35o@flatron>
 <51EBC0F5.70601@ti.com> <9748041.Qq1fWJBg6D@flatron>
 <20130721154653.GG16598@kroah.com>
Message-ID: <20130730071106.GC16441@radagast>

On Sun, Jul 21, 2013 at 08:46:53AM -0700, Greg KH wrote:
> On Sun, Jul 21, 2013 at 01:12:07PM +0200, Tomasz Figa wrote:
> > On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
> > > Hi,
> > > 
> > > On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
> > > > Hi,
> > > > 
> > > > On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
> > > >> On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
> > > >>> On Sat, 20 Jul 2013, Greg KH wrote:
> > > >>>>>>> That should be passed using platform data.
> > > >>>>>> 
> > > >>>>>> Ick, don't pass strings around, pass pointers.  If you have
> > > >>>>>> platform
> > > >>>>>> data you can get to, then put the pointer there, don't use a
> > > >>>>>> "name".
> > > >>>>> 
> > > >>>>> I don't think I understood you here :-s We wont have phy pointer
> > > >>>>> when we create the device for the controller no?(it'll be done in
> > > >>>>> board file). Probably I'm missing something.
> > > >>>> 
> > > >>>> Why will you not have that pointer?  You can't rely on the "name"
> > > >>>> as
> > > >>>> the device id will not match up, so you should be able to rely on
> > > >>>> the pointer being in the structure that the board sets up, right?
> > > >>>> 
> > > >>>> Don't use names, especially as ids can, and will, change, that is
> > > >>>> going
> > > >>>> to cause big problems.  Use pointers, this is C, we are supposed to
> > > >>>> be
> > > >>>> doing that :)
> > > >>> 
> > > >>> Kishon, I think what Greg means is this:  The name you are using
> > > >>> must
> > > >>> be stored somewhere in a data structure constructed by the board
> > > >>> file,
> > > >>> right?  Or at least, associated with some data structure somehow.
> > > >>> Otherwise the platform code wouldn't know which PHY hardware
> > > >>> corresponded to a particular name.
> > > >>> 
> > > >>> Greg's suggestion is that you store the address of that data
> > > >>> structure
> > > >>> in the platform data instead of storing the name string.  Have the
> > > >>> consumer pass the data structure's address when it calls phy_create,
> > > >>> instead of passing the name.  Then you don't have to worry about two
> > > >>> PHYs accidentally ending up with the same name or any other similar
> > > >>> problems.
> > > >> 
> > > >> Close, but the issue is that whatever returns from phy_create()
> > > >> should
> > > >> then be used, no need to call any "find" functions, as you can just
> > > >> use
> > > >> the pointer that phy_create() returns.  Much like all other class api
> > > >> functions in the kernel work.
> > > > 
> > > > I think there is a confusion here about who registers the PHYs.
> > > > 
> > > > All platform code does is registering a platform/i2c/whatever device,
> > > > which causes a driver (located in drivers/phy/) to be instantiated.
> > > > Such drivers call phy_create(), usually in their probe() callbacks,
> > > > so platform_code has no way (and should have no way, for the sake of
> > > > layering) to get what phy_create() returns.
> 
> Why not put pointers in the platform data structure that can hold these
> pointers?  I thought that is why we created those structures in the
> first place.  If not, what are they there for?

heh, IMO we shouldn't pass pointers of any kind through platform_data,
we want to pass data :-)

Allowing to pass pointers through that, is one of the reasons which got
us in such a big mess in ARM land, well it was much easier for a
board-file/driver writer to pass a function pointer then to create a
generic framework :-)

> > > > IMHO we need a lookup method for PHYs, just like for clocks,
> > > > regulators, PWMs or even i2c busses because there are complex cases
> > > > when passing just a name using platform data will not work. I would
> > > > second what Stephen said [1] and define a structure doing things in a
> > > > DT-like way.
> > > > 
> > > > Example;
> > > > 
> > > > [platform code]
> > > > 
> > > > static const struct phy_lookup my_phy_lookup[] = {
> > > > 
> > > > 	PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
> > > 
> > > The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
> > > creating the device, the ids in the device name would change and
> > > PHY_LOOKUP wont be useful.
> > 
> > I don't think this is a problem. All the existing lookup methods already 
> > use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You 
> > can simply add a requirement that the ID must be assigned manually, 
> > without using PLATFORM_DEVID_AUTO to use PHY lookup.
> 
> And I'm saying that this idea, of using a specific name and id, is
> frought with fragility and will break in the future in various ways when
> devices get added to systems, making these strings constantly have to be
> kept up to date with different board configurations.
> 
> People, NEVER, hardcode something like an id.  The fact that this
> happens today with the clock code, doesn't make it right, it makes the
> clock code wrong.  Others have already said that this is wrong there as
> well, as systems change and dynamic ids get used more and more.
> 
> Let's not repeat the same mistakes of the past just because we refuse to
> learn from them...
> 
> So again, the "find a phy by a string" functions should be removed, the
> device id should be automatically created by the phy core just to make
> things unique in sysfs, and no driver code should _ever_ be reliant on
> the number that is being created, and the pointer to the phy structure
> should be used everywhere instead.
> 
> With those types of changes, I will consider merging this subsystem, but
> without them, sorry, I will not.

I'll agree with Greg here, the very fact that we see people trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points to a
big problem in the framework.

The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
adding similar infrastructure to the driver themselves to make sure we
don't end up with duplicate names in sysfs in case we have multiple
instances of the same IP in the SoC (or several of the same PCIe card).
I really don't want to go back to that.

-- 
balbi
-------------- 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/20130730/625b34cb/attachment-0001.sig>

From balbi at ti.com  Tue Jul 30 03:16:11 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 30 Jul 2013 10:16:11 +0300
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given in
 usb_bind_phy
In-Reply-To: <51F7613C.5070803@ti.com>
References: <20130729150638.GD3063@radagast> <51F68A56.8060805@ti.com>
 <20130729175413.GC4964@radagast> <51F74BC8.7020903@ti.com>
 <20130730060134.GD9155@radagast> <51F7590B.4020705@ti.com>
 <20130730061830.GE9155@radagast> <51F75C40.4060406@ti.com>
 <20130730062844.GH9155@radagast> <51F7613C.5070803@ti.com>
Message-ID: <20130730071611.GD16441@radagast>

Hi,

On Tue, Jul 30, 2013 at 12:16:20PM +0530, Kishon Vijay Abraham I wrote:
> >>>> the list of controller device (names) it can support (PHY framework does not
> >>>> maintain a separate list for binding like how we had in USB PHY library). e.g.
> >>>> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg92817.html. In such
> >>>
> >>> this has nothing to do with $subject though. We talk about generic PHY
> >>> framework once all these PHY drivers are moved there :-)
> >>>
> >>>> cases how do we pass the device names. Also will the MUSB core device be
> >>>> created before twl4030-usb PHY device?
> >>>
> >>> and why would that be a problem ? We're telling the framework that the
> >>> musb device will use a phy with a name of 'twl4030'. If musb calls
> >>> usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and
> >>> try again later.
> >>
> >> I think we are talking about different problems here ;-) I'm trying to tell
> >> using idr in MUSB core is needed for Generic PHY Framework. So in a way, the
> >> Generic PHY Framework series depends on this patch series or else MUSB in OMAP3
> >> platforms wont work after Generic PHY framework gets merged.
> > 
> > then you just found a limitation in your framework, right ? :-) I mean,
> > imagine if now we have to add an IDR to every single user of your
> > framework because they could end up in systems with multiple instances
> > of the same IP ?
> 
> I raised a similar concern in the PHY framework discussion [1] :-) And since
> it's used everywhere else regulators, clkdev, etc.. it's agreed to be used in
> PHY as well. Btw if PLATFORM_DEVID_AUTO is used even regulator, clk_get should
> fail IMO.
> 
> [1] -> http://lkml.indiana.edu/hypermail/linux/kernel/1307.2/03573.html

look at Greg's and my reply to that email.

-- 
balbi
-------------- 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/20130730/a74b90be/attachment.sig>

From u.kleine-koenig at pengutronix.de  Tue Jul 30 03:39:17 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Tue, 30 Jul 2013 09:39:17 +0200
Subject: [PATCH] gpio/mxc: add chained_irq_enter/exit() to
 mx2_gpio_irq_handler
In-Reply-To: <CACRpkdZjsAOtm2Jt7kY-VC2ToFfMQ+UxjWQE7aUZAbsBt0ugvw@mail.gmail.com>
References: <1374152286-12955-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <CACRpkdZjsAOtm2Jt7kY-VC2ToFfMQ+UxjWQE7aUZAbsBt0ugvw@mail.gmail.com>
Message-ID: <20130730073917.GL1754@pengutronix.de>

Hi Linus,

On Mon, Jul 29, 2013 at 05:51:17PM +0200, Linus Walleij wrote:
> On Thu, Jul 18, 2013 at 2:58 PM, Uwe Kleine-K?nig
> <u.kleine-koenig at pengutronix.de> wrote:
> 
> > Similar to commit
> >
> >         0e44b6e (gpio/mxc: add chained_irq_enter/exit() to mx3_gpio_irq_handler())
> >
> > . It doesn't seem to be critical to make the irqs work, but still it is
> > more correct.
> >
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> 
> Patch is fine, but looks like this to me:
> 
> Content-Transfer-Encoding: base64
> 
> Sender: "linux-arm-kernel" <linux-arm-kernel-bounces at lists.infradead.org>
> Errors-To: linux-arm-kernel-bounces+linus.walleij=linaro.org at lists.infradead.org
> 
> U2ltaWxhciB0byBjb21taXQKCgkwZTQ0YjZlIChncGlvL214YzogYWRkIGNoYWluZWRfaXJxX2Vu
> dGVyL2V4aXQoKSB0byBteDNfZ3Bpb19pcnFfaGFuZGxlcigpKQoKLiBJdCBkb2Vzbid0IHNlZW0g
> dG8gYmUgY3JpdGljYWwgdG8gbWFrZSB0aGUgaXJxcyB3b3JrLCBidXQgc3RpbGwgaXQgaXMKbW9y
> ZSBjb3JyZWN0LgoKU2lnbmVkLW9mZi1ieTogVXdlIEtsZWluZS1Lw7ZuaWcgPHUua2xlaW5lLWtv
> ZW5pZ0BwZW5ndXRyb25peC5kZT4KLS0tCkhlbGxvLAoKbm90ZSB0aGlzIGlzIGNvbXBsZXRlbHkg
> dW50ZXN0ZWQuCgpVd2UKCiBkcml2ZXJzL2dwaW8vZ3Bpby1teGMuYyB8IDQgKysrKwogMSBmaWxl
> 
> The encoding is what screw things up.
That means git is unable to apply base64 encoded mail? Hmm, testing with
git 1.8.3.2 (from Debian) I can apply the base64 encoded patch.
Does your git have 87ab799234639c26ea10de74782fa511cb3ca606 (i.e. is
older than 1.5.1)?

> Can you see if you can resend this without using base64?
The version I got back via the kernel at pengutronix.de address has:

	Content-Type: text/plain; charset=UTF-8
	Content-Transfer-Encoding: 8bit

and the content is readable just fine in an editor. My copy I got via
the linux-arm-kernel subscription is base64 encoded, too. So a mail
server on the way to you reencodes my mail. At gmane
(http://article.gmane.org/gmane.linux.ports.arm.kernel/252948/raw) it's
already base64. According to the Received: headers it can only be
casper.infradead.org or merlin.infradead.org.

I found

	http://mail.python.org/pipermail/mailman-users/2008-September/063286.html

which is really annoying. I'll bounce you the original.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From marc.zyngier at arm.com  Tue Jul 30 03:41:34 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 30 Jul 2013 08:41:34 +0100
Subject: [PATCH] ARM64: include: asm: use 'int' instead of 'u32' for
 variable 'target' in kvm_host.h.
In-Reply-To: <20130730034945.GD5471@cbox>
References: <51ECA9B6.3010808@asianux.com> <20130730034945.GD5471@cbox>
Message-ID: <51F76E2E.9050707@arm.com>

On 30/07/13 04:49, Christoffer Dall wrote:
> On Mon, Jul 22, 2013 at 11:40:38AM +0800, Chen Gang wrote:
>> 'target' will be set to '-1' in kvm_arch_vcpu_init(), and it need check
>> 'target' whether less than zero or not in kvm_vcpu_initialized().
>>
>> So need define target as 'int' instead of 'u32', just like ARM has done.
>>
>>
>> The related warning:
>>
>>   arch/arm64/kvm/../../../arch/arm/kvm/arm.c:497:2: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
>>
>> Signed-off-by: Chen Gang <gang.chen at asianux.com>
>> ---
>>  arch/arm64/include/asm/kvm_host.h |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 644d739..0859a4d 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -129,7 +129,7 @@ struct kvm_vcpu_arch {
>>  	struct kvm_mmu_memory_cache mmu_page_cache;
>>  
>>  	/* Target CPU and feature flags */
>> -	u32 target;
>> +	int target;
>>  	DECLARE_BITMAP(features, KVM_VCPU_MAX_FEATURES);
>>  
>>  	/* Detect first run of a vcpu */
>> -- 
>> 1.7.7.6
> 
> This looks ok to me, Marc, was there any reason to declare target a u32
> on arm64?

No, that's simply a bug. I really wonder why my compiler doesn't scream
at something that obvious...

Chen: what compiler version are you using?

I'll queue this fix.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From zonque at gmail.com  Tue Jul 30 03:48:51 2013
From: zonque at gmail.com (Daniel Mack)
Date: Tue, 30 Jul 2013 09:48:51 +0200
Subject: [RFC PATCH 0/2] impedance-matcher generic improvements
In-Reply-To: <cover.1375131816.git.jason@lakedaemon.net>
References: <51F2A014.7000209@gmail.com>
 <cover.1375131816.git.jason@lakedaemon.net>
Message-ID: <51F76FE3.1080302@gmail.com>

Hi Jason,

On 29.07.2013 23:23, Jason Cooper wrote:
> Basic idea is to replace a device's stock kernel with this impedance-matcher.
> Load the kernel and/or the devicetree blob to desired addresses.  Add
> 'loadaddrs=0xXXXXXXXX,0xYYYYYYYY' to the kernel's command line.  Or, if you are
> appending, 'loadaddrs=appended,0xYYYYYYYY'.  First address is the location of
> the kernel, second is the location of the dtb.

Nice to see that idea implemented! For me though, changing any of the
U-Boot variables is out of the question, and I need the matcher just the
way I implemented it, including the LED blink pattern to let the user
know if things go wrong.

Hence, I won't change to your generic version on my boards, and so I
think it might be best if you maintain your own tree for your approach.


Best regards,
Daniel



From horms at verge.net.au  Tue Jul 30 03:49:40 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 16:49:40 +0900
Subject: ARM CPU Hotplug breakage on mach-shmobile and KZM9D
In-Reply-To: <20130725010607.GB31464@verge.net.au>
References: <CANqRtoRx7voEVwJG8UNNy_Jiixo=uRJCvxTD0bZdzVohoryBUA@mail.gmail.com>
 <20130725010607.GB31464@verge.net.au>
Message-ID: <20130730074939.GE7210@verge.net.au>

[ Cc Paul Gortmaker ]

On Thu, Jul 25, 2013 at 10:06:07AM +0900, Simon Horman wrote:
> On Thu, Jul 25, 2013 at 12:15:49AM +0900, Magnus Damm wrote:
> > Hi everyone,
> > 
> > Bad news: CPU Hotplug on KZM9D seems broken on recent kernels.
> > 
> > On renesas-next-20130710 or earlier I can perform the following:
> > 
> > # echo 0 > /sys/devices/system/cpu/cpu1/online
> > CPU1: shutdown
> > # echo 1 > /sys/devices/system/cpu/cpu1/online
> > CPU1: Booted secondary processor
> > #
> > 
> > While on more recent kernels the hotplug boot fails. This may be
> > related to the move to v3.11-rc. The tag renesas-next-20130710
> > surprisingly seems to be the final kernel based on v3.10-rc before
> > jumping to v3.11-rc.
> > 
> > I wonder, do other ARM platforms have working CPU Hotplug in v3.11-rc?
> 
> I have a snowball that I could test if you think it would be useful.

Unfortunately getting snowball to work turned out to be rather painful.
So instead I bisected the problem on the KZM9G (N.b: the D in the subject
seems to be incorrect :^)

The result is that the following patch, added in v3.11-rc1,
appears to be the culprit.

commit 22f0a27367742f65130c0fb25ef00f7297e032c1
Author: Paul Gortmaker <paul.gortmaker at windriver.com>
Date:   Mon Jun 17 18:34:14 2013 -0400

    init.h: remove __cpuinit sections from the kernel
    
    The __cpuinit type of throwaway sections might have made sense
    some time ago when RAM was more constrained, but now the savings
    do not offset the cost and complications.  For example, the fix in
    commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
    is a good example of the nasty type of bugs that can be created
    with improper use of the various __init prefixes.
    
    After a discussion on LKML[1] it was decided that cpuinit should go
    the way of devinit and be phased out.  Once all the users are gone,
    we can then finally remove the macros themselves from linux/init.h.
    
    As an interim step, we can dummy out the macros to be no-ops, and
    this will allow us to avoid a giant tree-wide patch, and instead
    we can feed in smaller chunks mainly via the arch/ trees.  This
    is in keeping with commit 78d86c213f28193082b5d8a1a424044b7ba406f1
    ("init.h: Remove __dev* sections from the kernel")
    
    We don't strictly need to dummy out the macros to do this, but if
    we don't then some harmless section mismatch warnings may temporarily
    result.  For example, notify_cpu_starting() and cpu_up() are arch
    independent (kernel/cpu.c) and are flagged as __cpuinit.  And hence
    the calling functions in the arch specific code are also expected
    to be __cpuinit -- if not, then we get the section mismatch warning.
    
    Two of the three __CPUINIT variants are not used whatsoever, and
    so they are simply removed directly at this point in time.
    
    [1] https://lkml.org/lkml/2013/5/20/589
    
    Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>

diff --git a/include/linux/init.h b/include/linux/init.h
index 8618147..e73f2b70 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -93,13 +93,13 @@
 
 #define __exit          __section(.exit.text) __exitused __cold notrace
 
-/* Used for HOTPLUG_CPU */
-#define __cpuinit        __section(.cpuinit.text) __cold notrace
-#define __cpuinitdata    __section(.cpuinit.data)
-#define __cpuinitconst   __constsection(.cpuinit.rodata)
-#define __cpuexit        __section(.cpuexit.text) __exitused __cold notrace
-#define __cpuexitdata    __section(.cpuexit.data)
-#define __cpuexitconst   __constsection(.cpuexit.rodata)
+/* temporary, until all users are removed */
+#define __cpuinit
+#define __cpuinitdata
+#define __cpuinitconst
+#define __cpuexit
+#define __cpuexitdata
+#define __cpuexitconst
 
 /* Used for MEMORY_HOTPLUG */
 #define __meminit        __section(.meminit.text) __cold notrace
@@ -118,9 +118,8 @@
 #define __INITRODATA	.section	".init.rodata","a",%progbits
 #define __FINITDATA	.previous
 
-#define __CPUINIT        .section	".cpuinit.text", "ax"
-#define __CPUINITDATA    .section	".cpuinit.data", "aw"
-#define __CPUINITRODATA  .section	".cpuinit.rodata", "a"
+/* temporary, until all users are removed */
+#define __CPUINIT
 
 #define __MEMINIT        .section	".meminit.text", "ax"
 #define __MEMINITDATA    .section	".meminit.data", "aw"


From hanjun.guo at linaro.org  Tue Jul 30 03:46:41 2013
From: hanjun.guo at linaro.org (Hanjun Guo)
Date: Tue, 30 Jul 2013 15:46:41 +0800
Subject: [RFC][PATCH 2/2] ARM64: introduce cluster id and make a difference
 between socket id
In-Reply-To: <CAKfTPtBXi4C3ncLmsWZQEs3x80VbPhHo+gC9hG_EFwMdafJmOQ@mail.gmail.com>
References: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>
 <1374921728-9007-2-git-send-email-hanjun.guo@linaro.org>
 <CAKfTPtBXi4C3ncLmsWZQEs3x80VbPhHo+gC9hG_EFwMdafJmOQ@mail.gmail.com>
Message-ID: <51F76F61.40206@linaro.org>

On 2013-7-29 17:38, Vincent Guittot wrote:
> On 27 July 2013 12:42, Hanjun Guo <hanjun.guo at linaro.org> wrote:
>> In the cpu topology information, we define topology_physical_package_id()
>> as cpu socket id, which means that the socket id is the idenfication for
>> physical processor, not for a cluster in a cpu die.
>>
>> On ARM64 platform, multi cluster in a cpu die will be normal, here is a
>> example with 2 cores in a cluster and 2 cluster in a socket:
>>
>> |--------------------------------------|
>> |                socket                |
>> |                                      |
>> | |---------------|  |---------------| |
>> | |    cluster    |  |    cluster    | |
>> | |               |  |               | |
>> | | |----| |----| |  | |----| |----| | |
>> | | |core| |core| |  | |core| |core| | |
>> | | |----| |----| |  | |----| |----| | |
>> | |               |  |               | |
>> | |---------------|  |---------------| |
>> |                                      |
>> |--------------------------------------|
>>
>> ARM64 extended the MPIDR into 64 bit and introduce another affinity level,
>> we can use this affinity level for socket id and use the third highest level
>> affinity for cluster id, which  make the socket id behavior in its original
>> way.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
>> ---
>>  arch/arm64/include/asm/topology.h |    1 +
>>  arch/arm64/kernel/topology.c      |    8 ++++++--
>>  2 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
>> index 8631808..ff68ecc 100644
>> --- a/arch/arm64/include/asm/topology.h
>> +++ b/arch/arm64/include/asm/topology.h
>> @@ -8,6 +8,7 @@
>>  struct cputopo_arm64 {
>>         int thread_id;
>>         int core_id;
>> +       int cluster_id;
>>         int socket_id;
>>         cpumask_t thread_sibling;
>>         cpumask_t core_sibling;
>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
>> index 1eb0435..6d1e5a6 100644
>> --- a/arch/arm64/kernel/topology.c
>> +++ b/arch/arm64/kernel/topology.c
>> @@ -80,12 +80,14 @@ void store_cpu_topology(unsigned int cpuid)
>>                         /* core performance interdependency */
>>                         cpuid_topo->thread_id = MPIDR_AFFINITY_LEVEL_0(mpidr);
>>                         cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL_1(mpidr);
>> -                       cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_2(mpidr);
>> +                       cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL_2(mpidr);
>> +                       cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_3(mpidr);
> 
> socket_id is currently used by update_siblings_masks to update the
> core_sibling mask. This mask defines which CPUs share their cache and
> AFAICT, the cache are shared at the cluster level so cluster_id should
> be used instead socket_id.

For some architecture, cpu cores in a cluster share L2 cache, and clusters
in the cpu die share L3 cache, so I think we can make a difference between
socket id and cluster id.

> 
> Have you got more information about the goal of this new level_3 ?

Actually not, I think ARM should give some recommendations as ARMv7 did.

Thanks
Hanjun


From shawn.guo at linaro.org  Tue Jul 30 03:50:21 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 30 Jul 2013 15:50:21 +0800
Subject: [PATCH 1/2] pinctrl: imx: Add exception hook for select input
In-Reply-To: <1375152857-32177-1-git-send-email-peter.chen@freescale.com>
References: <1375152857-32177-1-git-send-email-peter.chen@freescale.com>
Message-ID: <20130730075018.GD12382@S2101-09.ap.freescale.net>

On Tue, Jul 30, 2013 at 10:54:16AM +0800, Peter Chen wrote:
> At some i.mx platforms the select input pin configuration may
> not be at common select input register region due to IC found
> the pin select pin configuration missing very late (Eg, ECO stage),
> so this pin's select input register is at other register space at
> pinctrl module. One typical example is USB OTG ID pin at i.mx6q is
> at IOMUXC_IOMUXC_GPR1.

Do you know any other case except this USB OTG ID pin on imx6q?  If this
is the only case, I'm wondering if we could work it around in machine
code mach-imx6q.c to avoid the churn of pinctrl driver?

Shawn

> 
> Signed-off-by: Peter Chen <peter.chen at freescale.com>
> ---
>  drivers/pinctrl/pinctrl-imx.c   |   11 +++++++++--
>  drivers/pinctrl/pinctrl-imx.h   |    8 ++++++--
>  drivers/pinctrl/pinctrl-imx6q.c |   14 ++++++++++++++
>  3 files changed, 29 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-imx.c b/drivers/pinctrl/pinctrl-imx.c
> index 57a4eb0..da75cd4 100644
> --- a/drivers/pinctrl/pinctrl-imx.c
> +++ b/drivers/pinctrl/pinctrl-imx.c
> @@ -240,8 +240,15 @@ static int imx_pmx_enable(struct pinctrl_dev *pctldev, unsigned selector,
>  			pin_reg->mux_reg, mux[i]);
>  
>  		/* some pins also need select input setting, set it if found */
> -		if (input_reg[i]) {
> -			writel(input_val[i], ipctl->base + input_reg[i]);
> +		if (input_reg) {
> +			if ((input_reg[i] == IMX_SELECT_INPUT_EXCEPTION) &&
> +					info->imx_select_input_hook)
> +				info->imx_select_input_hook(ipctl->base,
> +					input_val[i]);
> +			else
> +				writel(input_val[i], ipctl->base +
> +					input_reg[i]);
> +
>  			dev_dbg(ipctl->dev,
>  				"==>select_input: offset 0x%x val 0x%x\n",
>  				input_reg[i], input_val[i]);
> diff --git a/drivers/pinctrl/pinctrl-imx.h b/drivers/pinctrl/pinctrl-imx.h
> index bcedd99..15e71b9 100644
> --- a/drivers/pinctrl/pinctrl-imx.h
> +++ b/drivers/pinctrl/pinctrl-imx.h
> @@ -26,8 +26,9 @@ struct platform_device;
>   *	elements in .pins so we can iterate over that array
>   * @mux_mode: the mux mode for each pin in this group. The size of this
>   *	array is the same as pins.
> - * @input_reg: select input register offset for this mux if any
> - *	0 if no select input setting needed.
> + * @input_reg: select input register offset for this mux,
> + *	0 if no select input setting needed, 0xfff if select input setting
> + *	is not at common select input register regiion.
>   * @input_val: the select input value for each pin in this group. The size of
>   *	this array is the same as pins.
>   * @configs: the config for each pin in this group. The size of this
> @@ -75,10 +76,13 @@ struct imx_pinctrl_soc_info {
>  	struct imx_pmx_func *functions;
>  	unsigned int nfunctions;
>  	unsigned int flags;
> +	/* Handle the exception for select input choose */
> +	void (*imx_select_input_hook) (void __iomem *, int);
>  };
>  
>  #define ZERO_OFFSET_VALID	0x1
>  #define SHARE_MUX_CONF_REG	0x2
> +#define IMX_SELECT_INPUT_EXCEPTION	0xfff
>  
>  #define NO_MUX		0x0
>  #define NO_PAD		0x0
> diff --git a/drivers/pinctrl/pinctrl-imx6q.c b/drivers/pinctrl/pinctrl-imx6q.c
> index 76dd9c4..61efa97 100644
> --- a/drivers/pinctrl/pinctrl-imx6q.c
> +++ b/drivers/pinctrl/pinctrl-imx6q.c
> @@ -461,9 +461,23 @@ static const struct pinctrl_pin_desc imx6q_pinctrl_pads[] = {
>  	IMX_PINCTRL_PIN(MX6Q_PAD_SD2_DAT3),
>  };
>  
> +#define IOMUXC_IOMUXC_GPR1	0x4
> +#define IOMUXC_GPR1_USB_OTG_ID_SEL_BIT	13
> +static void imx6q_pinctrl_select_input_hook(void __iomem *base, int val)
> +{
> +	u32 value;
> +	/* Add the exceptions one by one */
> +
> +	/* USB ID select input configuration */
> +	value = readl(base + IOMUXC_IOMUXC_GPR1);
> +	writel(value | (val << IOMUXC_GPR1_USB_OTG_ID_SEL_BIT),
> +		base + IOMUXC_IOMUXC_GPR1);
> +}
> +
>  static struct imx_pinctrl_soc_info imx6q_pinctrl_info = {
>  	.pins = imx6q_pinctrl_pads,
>  	.npins = ARRAY_SIZE(imx6q_pinctrl_pads),
> +	.imx_select_input_hook = imx6q_pinctrl_select_input_hook,
>  };
>  
>  static struct of_device_id imx6q_pinctrl_of_match[] = {
> -- 
> 1.7.0.4
> 
> 



From hanjun.guo at linaro.org  Tue Jul 30 03:49:19 2013
From: hanjun.guo at linaro.org (Hanjun Guo)
Date: Tue, 30 Jul 2013 15:49:19 +0800
Subject: [RFC][PATCH 1/2] ARM64: add cpu topology definition
In-Reply-To: <CAKfTPtBpo41LJ3V8TB8YwudwqpURuA2u_Lvu4KYVK=qSs+gFuQ@mail.gmail.com>
References: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>
 <CAKfTPtBpo41LJ3V8TB8YwudwqpURuA2u_Lvu4KYVK=qSs+gFuQ@mail.gmail.com>
Message-ID: <51F76FFF.6010809@linaro.org>

On 2013-7-29 17:46, Vincent Guittot wrote:
> On 27 July 2013 12:42, Hanjun Guo <hanjun.guo at linaro.org> wrote:
>> Power aware scheduling needs the cpu topology information to improve the
>> cpu scheduler decision making.
> 
> It's not only power aware scheduling. The scheduler already uses
> topology and cache sharing when  CONFIG_SCHED_MC and/or
> CONFIG_SCHED_SMT are enable. So you should also add these configs for
> arm64 so the scheduler can use it

Yes, you are right, thanks for the advice.

> 
> Vincent
> 
>>
>> For ARM64, we can get the topology from the MPIDR register which defines the
>> the affinity of processors.
>>
>> This patch is mainly based on arch/arm/kernel/topology.c written by
>> Vincent Guittot, and replaced the topology array with per cpu variable.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
>> ---
>>  arch/arm64/Kconfig                |    9 +++
>>  arch/arm64/include/asm/cputype.h  |   11 ++++
>>  arch/arm64/include/asm/topology.h |   41 ++++++++++++
>>  arch/arm64/kernel/Makefile        |    1 +
>>  arch/arm64/kernel/smp.c           |    6 ++
>>  arch/arm64/kernel/topology.c      |  128 +++++++++++++++++++++++++++++++++++++
>>  6 files changed, 196 insertions(+)
>>  create mode 100644 arch/arm64/include/asm/topology.h
>>  create mode 100644 arch/arm64/kernel/topology.c
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 9737e97..f0ce91b 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -150,6 +150,15 @@ config SMP
>>
>>           If you don't know what to do here, say N.
>>
>> +config ARM64_CPU_TOPOLOGY
>> +       bool "Support cpu topology definition"
>> +       depends on SMP && ARM64
>> +       default y
>> +       help
>> +         Support ARM64 cpu topology definition. The MPIDR register defines
>> +         affinity between processors which is then used to describe the cpu
>> +         topology of an ARM64 System.
>> +
>>  config NR_CPUS
>>         int "Maximum number of CPUs (2-32)"
>>         range 2 32
>> diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
>> index 5fe138e..68b55af 100644
>> --- a/arch/arm64/include/asm/cputype.h
>> +++ b/arch/arm64/include/asm/cputype.h
>> @@ -30,6 +30,17 @@
>>
>>  #define MPIDR_HWID_BITMASK     0xff00ffffff
>>
>> +#define MPIDR_SMP_BITMASK      (0x1 << 30)
>> +#define MPIDR_MT_BITMASK       (0x1 << 24)
>> +
>> +#define MPIDR_LEVEL_BITS       8
>> +#define MPIDR_LEVEL_MASK       ((1 << MPIDR_LEVEL_BITS) - 1)
>> +
>> +#define MPIDR_AFFINITY_LEVEL_0(mpidr) ((mpidr) & MPIDR_LEVEL_MASK)
>> +#define MPIDR_AFFINITY_LEVEL_1(mpidr) ((mpidr >> 8) & MPIDR_LEVEL_MASK)
>> +#define MPIDR_AFFINITY_LEVEL_2(mpidr) ((mpidr >> 16) & MPIDR_LEVEL_MASK)
>> +#define MPIDR_AFFINITY_LEVEL_3(mpidr) ((mpidr >> 32) & MPIDR_LEVEL_MASK)
>> +
>>  #define read_cpuid(reg) ({                                             \
>>         u64 __val;                                                      \
>>         asm("mrs        %0, " reg : "=r" (__val));                      \
>> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
>> new file mode 100644
>> index 0000000..8631808
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/topology.h
>> @@ -0,0 +1,41 @@
>> +#ifndef _ASM_ARM64_TOPOLOGY_H
>> +#define _ASM_ARM64_TOPOLOGY_H
>> +
>> +#ifdef CONFIG_ARM64_CPU_TOPOLOGY
>> +
>> +#include <linux/cpumask.h>
>> +
>> +struct cputopo_arm64 {
>> +       int thread_id;
>> +       int core_id;
>> +       int socket_id;
>> +       cpumask_t thread_sibling;
>> +       cpumask_t core_sibling;
>> +};
>> +
>> +DECLARE_PER_CPU(struct cputopo_arm64, cpu_topology);
>> +
>> +#define cpu_topo(cpu) per_cpu(cpu_topology, cpu)
>> +
>> +#define topology_physical_package_id(cpu)      (cpu_topo(cpu).socket_id)
>> +#define topology_core_id(cpu)          (cpu_topo(cpu).core_id)
>> +#define topology_core_cpumask(cpu)     (&cpu_topo(cpu).core_sibling)
>> +#define topology_thread_cpumask(cpu)   (&cpu_topo(cpu).thread_sibling)
>> +
>> +#define mc_capable()   (cpu_topo(0).socket_id != -1)
>> +#define smt_capable()  (cpu_topo(0).thread_id != -1)
>> +
>> +void init_cpu_topology(void);
>> +void store_cpu_topology(unsigned int cpuid);
>> +const struct cpumask *cpu_coregroup_mask(int cpu);
>> +
>> +#else
>> +
>> +static inline void init_cpu_topology(void) { }
>> +static inline void store_cpu_topology(unsigned int cpuid) { }
>> +
>> +#endif
>> +
>> +#include <asm-generic/topology.h>
>> +
>> +#endif /* _ASM_ARM64_TOPOLOGY_H */
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index 7b4b564..a47c359 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -18,6 +18,7 @@ arm64-obj-$(CONFIG_SMP)                       += smp.o smp_spin_table.o smp_psci.o
>>  arm64-obj-$(CONFIG_HW_PERF_EVENTS)     += perf_event.o
>>  arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT)+= hw_breakpoint.o
>>  arm64-obj-$(CONFIG_EARLY_PRINTK)       += early_printk.o
>> +arm64-obj-$(CONFIG_ARM64_CPU_TOPOLOGY)  += topology.o
>>
>>  obj-y                                  += $(arm64-obj-y) vdso/
>>  obj-m                                  += $(arm64-obj-m)
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index fee5cce..197b1da 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -39,6 +39,7 @@
>>  #include <asm/atomic.h>
>>  #include <asm/cacheflush.h>
>>  #include <asm/cputype.h>
>> +#include <asm/topology.h>
>>  #include <asm/mmu_context.h>
>>  #include <asm/pgtable.h>
>>  #include <asm/pgalloc.h>
>> @@ -215,6 +216,8 @@ asmlinkage void secondary_start_kernel(void)
>>         local_irq_enable();
>>         local_fiq_enable();
>>
>> +       store_cpu_topology(cpu);
>> +
>>         /*
>>          * OK, it's off to the idle thread for us
>>          */
>> @@ -387,6 +390,9 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>>         int cpu, err;
>>         unsigned int ncores = num_possible_cpus();
>>
>> +       init_cpu_topology();
>> +       store_cpu_topology(smp_processor_id());
>> +
>>         /*
>>          * are we trying to boot more cores than exist?
>>          */
>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
>> new file mode 100644
>> index 0000000..1eb0435
>> --- /dev/null
>> +++ b/arch/arm64/kernel/topology.c
>> @@ -0,0 +1,128 @@
>> +/*
>> + * arch/arm64/kernel/topology.c
>> + *
>> + * Copyright (C) 2013 Linaro Limited.
>> + * Written by: Hanjun Guo
>> + *
>> + * based on arch/arm/kernel/topology.c
>> + *
>> + * This file is subject to the terms and conditions of the GNU General Public
>> + * License.  See the file "COPYING" in the main directory of this archive
>> + * for more details.
>> + */
>> +
>> +#include <linux/cpu.h>
>> +#include <linux/cpumask.h>
>> +#include <linux/init.h>
>> +#include <linux/percpu.h>
>> +#include <linux/sched.h>
>> +
>> +#include <asm/cputype.h>
>> +#include <asm/topology.h>
>> +
>> +DEFINE_PER_CPU(struct cputopo_arm64, cpu_topology);
>> +
>> +const struct cpumask *cpu_coregroup_mask(int cpu)
>> +{
>> +       return &cpu_topo(cpu).core_sibling;
>> +}
>> +
>> +void update_siblings_masks(unsigned int cpuid)
>> +{
>> +       struct cputopo_arm64 *topo, *cpuid_topo = &cpu_topo(cpuid);
>> +       int cpu;
>> +
>> +       /* update core and thread sibling masks */
>> +       for_each_possible_cpu(cpu) {
>> +               topo = &cpu_topo(cpu);
>> +
>> +               if (cpuid_topo->socket_id != topo->socket_id)
>> +                       continue;
>> +
>> +               cpumask_set_cpu(cpuid, &topo->core_sibling);
>> +               if (cpu != cpuid)
>> +                       cpumask_set_cpu(cpu, &cpuid_topo->core_sibling);
>> +
>> +               if (cpuid_topo->core_id != topo->core_id)
>> +                       continue;
>> +
>> +               cpumask_set_cpu(cpuid, &topo->thread_sibling);
>> +               if (cpu != cpuid)
>> +                       cpumask_set_cpu(cpu, &cpuid_topo->thread_sibling);
>> +       }
>> +       smp_wmb();
>> +}
>> +
>> +/*
>> + * store_cpu_topology is called at boot when only one cpu is running
>> + * and with the mutex cpu_hotplug.lock locked, when several cpus have booted,
>> + * which prevents simultaneous write access to cpu_topology array
>> + */
>> +void store_cpu_topology(unsigned int cpuid)
>> +{
>> +       struct cputopo_arm64 *cpuid_topo = &cpu_topo(cpuid);
>> +       u64 mpidr;
>> +
>> +       /* If the cpu topology has been already set, just return */
>> +       if (cpuid_topo->core_id != -1)
>> +               return;
>> +
>> +       mpidr = read_cpuid_mpidr();
>> +
>> +       /* create cpu topology mapping */
>> +       if (!(mpidr & MPIDR_SMP_BITMASK)) {
>> +               /*
>> +                * This is a multiprocessor system
>> +                * multiprocessor format & multiprocessor mode field are set
>> +                */
>> +
>> +               if (mpidr & MPIDR_MT_BITMASK) {
>> +                       /* core performance interdependency */
>> +                       cpuid_topo->thread_id = MPIDR_AFFINITY_LEVEL_0(mpidr);
>> +                       cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL_1(mpidr);
>> +                       cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_2(mpidr);
>> +               } else {
>> +                       /* largely independent cores */
>> +                       cpuid_topo->thread_id = -1;
>> +                       cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL_0(mpidr);
>> +                       cpuid_topo->socket_id = MPIDR_AFFINITY_LEVEL_1(mpidr);
>> +               }
>> +       } else {
>> +               /*
>> +                * This is an uniprocessor system
>> +                * we are in multiprocessor format but uniprocessor system
>> +                * or in the old uniprocessor format
>> +                */
>> +               cpuid_topo->thread_id = -1;
>> +               cpuid_topo->core_id = 0;
>> +               cpuid_topo->socket_id = -1;
>> +       }
>> +
>> +       update_siblings_masks(cpuid);
>> +
>> +       printk(KERN_INFO "CPU%u: thread %d, cpu %d, socket %d, mpidr 0x%llx\n",
>> +               cpuid, cpu_topo(cpuid).thread_id,
>> +               cpu_topo(cpuid).core_id,
>> +               cpu_topo(cpuid).socket_id, mpidr);
>> +}
>> +
>> +/*
>> + * init_cpu_topology is called at boot when only one cpu is running
>> + * which prevent simultaneous write access to cpu_topology array
>> + */
>> +void __init init_cpu_topology(void)
>> +{
>> +       unsigned int cpu;
>> +
>> +       /* init core mask */
>> +       for_each_possible_cpu(cpu) {
>> +               struct cputopo_arm64 *topo = &cpu_topo(cpu);
>> +
>> +               topo->thread_id = -1;
>> +               topo->core_id =  -1;
>> +               topo->socket_id = -1;
>> +               cpumask_clear(&topo->core_sibling);
>> +               cpumask_clear(&topo->thread_sibling);
>> +       }
>> +       smp_wmb();
>> +}
>> --
>> 1.7.9.5
>>



From peter.chen at freescale.com  Tue Jul 30 04:00:29 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Tue, 30 Jul 2013 16:00:29 +0800
Subject: [PATCH 1/2] pinctrl: imx: Add exception hook for select input
In-Reply-To: <20130730075018.GD12382@S2101-09.ap.freescale.net>
References: <1375152857-32177-1-git-send-email-peter.chen@freescale.com>
 <20130730075018.GD12382@S2101-09.ap.freescale.net>
Message-ID: <20130730080028.GA8540@nchen-desktop>

On Tue, Jul 30, 2013 at 03:50:21PM +0800, Shawn Guo wrote:
> On Tue, Jul 30, 2013 at 10:54:16AM +0800, Peter Chen wrote:
> > At some i.mx platforms the select input pin configuration may
> > not be at common select input register region due to IC found
> > the pin select pin configuration missing very late (Eg, ECO stage),
> > so this pin's select input register is at other register space at
> > pinctrl module. One typical example is USB OTG ID pin at i.mx6q is
> > at IOMUXC_IOMUXC_GPR1.
> 
> Do you know any other case except this USB OTG ID pin on imx6q?  If this
> is the only case, I'm wondering if we could work it around in machine
> code mach-imx6q.c to avoid the churn of pinctrl driver?
> 

I searched the RM, this is the only one. If you don't think we need
to consider if it will occur in the future, I am OK to move it at machine
code, but every mx6q board need it if it does not use default select input
value.

-- 

Best Regards,
Peter Chen



From sebastian.hesselbarth at gmail.com  Tue Jul 30 04:03:56 2013
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Tue, 30 Jul 2013 10:03:56 +0200
Subject: [PATCH 4/4] ARM: dove: add initial DT file for Globalscale D2Plug
In-Reply-To: <20130729184520.GI24782@lunn.ch>
References: <1375100946-28521-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1375100946-28521-5-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130729184520.GI24782@lunn.ch>
Message-ID: <51F7736C.5040701@gmail.com>

On 07/29/2013 08:45 PM, Andrew Lunn wrote:
> On Mon, Jul 29, 2013 at 02:29:06PM +0200, Sebastian Hesselbarth wrote:
>> This adds an initial DT file for the Globalscale D2Plug with Dove SoC.
>> Currently, one LED is missing and I have not been able to get SD8787 driver
>> working. Those will be taken care of later.
>
> I took a hard look at SDIO and failed to get it working when doing
> DMA. Polled IO does however work. I guess we need some help from
> Marvell engineers before we get stable SDIO with DMA.

Andrew,

have you tried this on the Dove D2Plug or any other Marvell SoC?
Dove is using a different SDHCI compatible SDIO controller.

Anyway, I haven't had a deep look into neither SDIO/SDHCI DMA nor
sd8787 driver.

Also, the DMA issue is not holding back this patch, is it?

Sebastian



From hanjun.guo at linaro.org  Tue Jul 30 04:09:02 2013
From: hanjun.guo at linaro.org (Hanjun Guo)
Date: Tue, 30 Jul 2013 16:09:02 +0800
Subject: [RFC][PATCH 1/2] ARM64: add cpu topology definition
In-Reply-To: <20130729133625.GA2280@localhost.localdomain>
References: <1374921728-9007-1-git-send-email-hanjun.guo@linaro.org>
 <CAKfTPtBpo41LJ3V8TB8YwudwqpURuA2u_Lvu4KYVK=qSs+gFuQ@mail.gmail.com>
 <20130729095400.GB32383@mudshark.cambridge.arm.com>
 <20130729133625.GA2280@localhost.localdomain>
Message-ID: <51F7749E.1010005@linaro.org>

On 2013-7-29 21:36, Dave Martin wrote:
> On Mon, Jul 29, 2013 at 10:54:01AM +0100, Will Deacon wrote:
>> On Mon, Jul 29, 2013 at 10:46:06AM +0100, Vincent Guittot wrote:
>>> On 27 July 2013 12:42, Hanjun Guo <hanjun.guo at linaro.org> wrote:
>>>> Power aware scheduling needs the cpu topology information to improve the
>>>> cpu scheduler decision making.
>>>
>>> It's not only power aware scheduling. The scheduler already uses
>>> topology and cache sharing when  CONFIG_SCHED_MC and/or
>>> CONFIG_SCHED_SMT are enable. So you should also add these configs for
>>> arm64 so the scheduler can use it
>>
>> ... except that the architecture doesn't define what the AFF fields in MPIDR
>> really represent. Using them to make key scheduling decisions relating to
> 
> In fact, the ARM Architecture doesn't place any requirements on MPIDRs to
> force the aff fields to exist _at all_.  It's just a recommendation.
> Instead, you have a 24 or 32-bit number which is unique per CPU, and which
> is _probably_ assigned in a way resembling the aff fields.
> 
>> cache proximity seems pretty risky to me, especially given the track record
>> we've seen already on AArch32 silicon. It's a convenient register if it
>> contains the data we want it to contain, but we need to force ourselves to
>> come to terms with reality here and simply use it as an identifier for a
>> CPU.
> 
> +1
> 
> Also, we should align arm and arm64.  The problem is basically exactly
> the same, and the solution needs to be the same.  struct cputopo_arm is
> already being abused  -- for example, TC2 describes the A15 and A7
> clusters on a single die as having different "socket_id" values, even
> though this is obviously nonsense.  But there's no other way to describe
> that system today.
> 
>> Can't we just use the device-tree to represent this topological data for
>> arm64? Lorenzo has been working on bindings in this area.
> 
> This may become more important as we start to see things like asymmetric
> topologies appearing (different numbers of nodes and different
> interdependence characteristics in adjacent branches of the topology
> etc.)

Agreed.
I would like to mention that the ACPI Static Resource Affinity Table (SRAT)
stores topology information for all the processors and memory, describing
the physical locations of the processors and memory in the system. ACPI will
be another available solution for this.

Thanks
Hanjun


From kishon at ti.com  Tue Jul 30 04:11:23 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 30 Jul 2013 13:41:23 +0530
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given
 in usb_bind_phy
In-Reply-To: <20130730071611.GD16441@radagast>
References: <20130729150638.GD3063@radagast> <51F68A56.8060805@ti.com>
 <20130729175413.GC4964@radagast> <51F74BC8.7020903@ti.com>
 <20130730060134.GD9155@radagast> <51F7590B.4020705@ti.com>
 <20130730061830.GE9155@radagast> <51F75C40.4060406@ti.com>
 <20130730062844.GH9155@radagast> <51F7613C.5070803@ti.com>
 <20130730071611.GD16441@radagast>
Message-ID: <51F7752B.8050804@ti.com>

On Tuesday 30 July 2013 12:46 PM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 30, 2013 at 12:16:20PM +0530, Kishon Vijay Abraham I wrote:
>>>>>> the list of controller device (names) it can support (PHY framework does not
>>>>>> maintain a separate list for binding like how we had in USB PHY library). e.g.
>>>>>> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg92817.html. In such
>>>>>
>>>>> this has nothing to do with $subject though. We talk about generic PHY
>>>>> framework once all these PHY drivers are moved there :-)
>>>>>
>>>>>> cases how do we pass the device names. Also will the MUSB core device be
>>>>>> created before twl4030-usb PHY device?
>>>>>
>>>>> and why would that be a problem ? We're telling the framework that the
>>>>> musb device will use a phy with a name of 'twl4030'. If musb calls
>>>>> usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and
>>>>> try again later.
>>>>
>>>> I think we are talking about different problems here ;-) I'm trying to tell
>>>> using idr in MUSB core is needed for Generic PHY Framework. So in a way, the
>>>> Generic PHY Framework series depends on this patch series or else MUSB in OMAP3
>>>> platforms wont work after Generic PHY framework gets merged.
>>>
>>> then you just found a limitation in your framework, right ? :-) I mean,
>>> imagine if now we have to add an IDR to every single user of your
>>> framework because they could end up in systems with multiple instances
>>> of the same IP ?
>>
>> I raised a similar concern in the PHY framework discussion [1] :-) And since
>> it's used everywhere else regulators, clkdev, etc.. it's agreed to be used in
>> PHY as well. Btw if PLATFORM_DEVID_AUTO is used even regulator, clk_get should
>> fail IMO.
>>
>> [1] -> http://lkml.indiana.edu/hypermail/linux/kernel/1307.2/03573.html
> 
> look at Greg's and my reply to that email.

but finally Greg agreed to what Tomasz proposed no?

Thanks
Kishon


From gang.chen at asianux.com  Tue Jul 30 04:11:50 2013
From: gang.chen at asianux.com (Chen Gang)
Date: Tue, 30 Jul 2013 16:11:50 +0800
Subject: [PATCH] ARM64: include: asm: use 'int' instead of 'u32' for
 variable 'target' in kvm_host.h.
In-Reply-To: <51F76E2E.9050707@arm.com>
References: <51ECA9B6.3010808@asianux.com> <20130730034945.GD5471@cbox>
 <51F76E2E.9050707@arm.com>
Message-ID: <51F77546.1020906@asianux.com>

On 07/30/2013 03:41 PM, Marc Zyngier wrote:
> On 30/07/13 04:49, Christoffer Dall wrote:
>> On Mon, Jul 22, 2013 at 11:40:38AM +0800, Chen Gang wrote:
>>> 'target' will be set to '-1' in kvm_arch_vcpu_init(), and it need check
>>> 'target' whether less than zero or not in kvm_vcpu_initialized().
>>>
>>> So need define target as 'int' instead of 'u32', just like ARM has done.
>>>
>>>
>>> The related warning:
>>>
>>>   arch/arm64/kvm/../../../arch/arm/kvm/arm.c:497:2: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
>>>
>>> Signed-off-by: Chen Gang <gang.chen at asianux.com>
>>> ---
>>>  arch/arm64/include/asm/kvm_host.h |    2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>>> index 644d739..0859a4d 100644
>>> --- a/arch/arm64/include/asm/kvm_host.h
>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>> @@ -129,7 +129,7 @@ struct kvm_vcpu_arch {
>>>  	struct kvm_mmu_memory_cache mmu_page_cache;
>>>  
>>>  	/* Target CPU and feature flags */
>>> -	u32 target;
>>> +	int target;
>>>  	DECLARE_BITMAP(features, KVM_VCPU_MAX_FEATURES);
>>>  
>>>  	/* Detect first run of a vcpu */
>>> -- 
>>> 1.7.7.6
>>
>> This looks ok to me, Marc, was there any reason to declare target a u32
>> on arm64?
> 
> No, that's simply a bug. I really wonder why my compiler doesn't scream
> at something that obvious...
> 

I make with "EXTRA_CFLAGS=-W", normal make will not report this
warning.  ;-)

> Chen: what compiler version are you using?
> 

[root at gchenlinux linux-next]# aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../libexec/gcc/aarch64-linux-gnu/4.7.3/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/src/gcc-linaro-4.7-2013.02/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=aarch64-linux-gnu --prefix=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/install --with-sysroot=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/install/aarch64-linux-gnu/libc --enable-languages=c,c++,fortran --disable-multilib --with-pkgversion='crosstool-NG linaro-1.13.1-4.7-2013.02-01-20130221 - ARM aarch64 via Linaro' --with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --with-gmp=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static --with-mpfr=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static --with-mpc=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linu
 x/.build/
aarch64-linux-gnu/build/static --with-ppl=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static --with-cloog=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static --with-libelf=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static --with-host-libstdcxx='-L/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/aarch64-linux-gnu/build/static/lib -lpwl' --enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id --enable-plugin --with-local-prefix=/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/install/aarch64-linux-gnu/libc --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.7.3 20130205 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.02-01-20130221 - ARM aarch64 via Linaro) 


> I'll queue this fix.
> 
> Thanks,
> 
> 	M.
> 

Thank you too.

-- 
Chen Gang


From u.kleine-koenig at pengutronix.de  Tue Jul 30 04:15:07 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Tue, 30 Jul 2013 10:15:07 +0200
Subject: [PATCH] ARM: ARMv7-M: Fix name of NVIC handler function
In-Reply-To: <20130708152917.GE29556@pengutronix.de>
References: <1372238855-26112-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <20130708152917.GE29556@pengutronix.de>
Message-ID: <20130730081507.GO1754@pengutronix.de>

Hi Russell,

On Mon, Jul 08, 2013 at 05:29:17PM +0200, Uwe Kleine-K?nig wrote:
> On Wed, Jun 26, 2013 at 11:27:35AM +0200, Uwe Kleine-K?nig wrote:
> > The name changed in response to review comments for the nvic irqchip
> > driver when the original name was already accepted into Russell King's
> > tree.
> > 
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> > ---
> > Hello,
> > 
> > this patch was part of the irqchip patch v4, but I split it out for
> > being easier to merge in v5. It applies on top of Russell's devel-stable
> > branch.
> > 
> > Russell: I put it on top of my for-next branch (
> > 
> > 	git://git.pengutronix.de/git/ukl/linux.git for-next
> > 
> > ) that you merged into your devel-stable some time ago. So assuming
> > you're fine with the patch, you can just repull or I can put it into
> > your patch tracker if you prefer it. In the latter case please tell me.
> The mismatch hit Linus' tree now. How should this patch get to him?
Although it's not critical (as there are no in-tree users) I still think
this should go in before 3.11.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From balbi at ti.com  Tue Jul 30 04:15:20 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 30 Jul 2013 11:15:20 +0300
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given in
 usb_bind_phy
In-Reply-To: <51F7752B.8050804@ti.com>
References: <20130729175413.GC4964@radagast> <51F74BC8.7020903@ti.com>
 <20130730060134.GD9155@radagast> <51F7590B.4020705@ti.com>
 <20130730061830.GE9155@radagast> <51F75C40.4060406@ti.com>
 <20130730062844.GH9155@radagast> <51F7613C.5070803@ti.com>
 <20130730071611.GD16441@radagast> <51F7752B.8050804@ti.com>
Message-ID: <20130730081520.GH16441@radagast>

On Tue, Jul 30, 2013 at 01:41:23PM +0530, Kishon Vijay Abraham I wrote:
> On Tuesday 30 July 2013 12:46 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Tue, Jul 30, 2013 at 12:16:20PM +0530, Kishon Vijay Abraham I wrote:
> >>>>>> the list of controller device (names) it can support (PHY framework does not
> >>>>>> maintain a separate list for binding like how we had in USB PHY library). e.g.
> >>>>>> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg92817.html. In such
> >>>>>
> >>>>> this has nothing to do with $subject though. We talk about generic PHY
> >>>>> framework once all these PHY drivers are moved there :-)
> >>>>>
> >>>>>> cases how do we pass the device names. Also will the MUSB core device be
> >>>>>> created before twl4030-usb PHY device?
> >>>>>
> >>>>> and why would that be a problem ? We're telling the framework that the
> >>>>> musb device will use a phy with a name of 'twl4030'. If musb calls
> >>>>> usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and
> >>>>> try again later.
> >>>>
> >>>> I think we are talking about different problems here ;-) I'm trying to tell
> >>>> using idr in MUSB core is needed for Generic PHY Framework. So in a way, the
> >>>> Generic PHY Framework series depends on this patch series or else MUSB in OMAP3
> >>>> platforms wont work after Generic PHY framework gets merged.
> >>>
> >>> then you just found a limitation in your framework, right ? :-) I mean,
> >>> imagine if now we have to add an IDR to every single user of your
> >>> framework because they could end up in systems with multiple instances
> >>> of the same IP ?
> >>
> >> I raised a similar concern in the PHY framework discussion [1] :-) And since
> >> it's used everywhere else regulators, clkdev, etc.. it's agreed to be used in
> >> PHY as well. Btw if PLATFORM_DEVID_AUTO is used even regulator, clk_get should
> >> fail IMO.
> >>
> >> [1] -> http://lkml.indiana.edu/hypermail/linux/kernel/1307.2/03573.html
> > 
> > look at Greg's and my reply to that email.
> 
> but finally Greg agreed to what Tomasz proposed no?

that's not what I see in the thread. I see Greg agreed to regulator's
own IDs being sequentially created, but he mentions device names can
change.

-- 
balbi
-------------- 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/20130730/12cfc057/attachment.sig>

From magnus.damm at gmail.com  Tue Jul 30 04:26:57 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Tue, 30 Jul 2013 17:26:57 +0900
Subject: [PATCH] ARM: shmobile: lager: do not annotate gpio_buttons as
 __initdata
In-Reply-To: <1374829772-10939-1-git-send-email-horms+renesas@verge.net.au>
References: <1374829772-10939-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <CANqRtoRUc1r_5=4HHa19ZCr71r1jv5AwZQ39Jv7eFNOUomtjag@mail.gmail.com>

On Fri, Jul 26, 2013 at 6:09 PM, Simon Horman
<horms+renesas at verge.net.au> wrote:
> When the gpio-keys device is registered using
> platform_device_register_data() the platform data argument,
> lager_keys_pdata is duplicated and thus should be marked as __initdata
> to avoid wasting memory. However, this is not true of gpio_buttons,
> a reference to it rather than its value is duplicated when lager_keys_pdata
> is duplicated.
>
> This avoids accessing freed memory if gpio-key events occur
> after unused kernel memory is freed late in the kernel's boot.
>
> This but was added when support for gpio-keys was added to lager
> in c3842e4fcbb7664276443b79187b7808c2e80a35
> ("ARM: shmobile: lager: support GPIO switches") which was included
> in v3.11-rc1.
>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
>
> ---
>
> * Noticed when adding gpio-keys support to ape6evm
> * Compile tested only

I just got around to test this patch on a Lager board, works well. Thanks!

Tested-by: Magnus Damm <damm at opensource.se>


From nsekhar at ti.com  Tue Jul 30 04:29:54 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 30 Jul 2013 13:59:54 +0530
Subject: [PATCH 7/9] ARM: edma: Don't clear EMR of channel in edma_stop
In-Reply-To: <1375104595-16018-8-git-send-email-joelf@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
 <1375104595-16018-8-git-send-email-joelf@ti.com>
Message-ID: <51F77982.7030601@ti.com>

On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
> We certainly don't want error conditions to be cleared anywhere

'anywhere' is a really loaded term.

> as this will make us 'forget' about missed events. We depend on
> knowing which events were missed in order to be able to reissue them.

> This fixes a race condition where the EMR was being cleared
> by the transfer completion interrupt handler.
> 
> Basically, what was happening was:
> 
>             Missed event
>              |
>              |
>              V
> SG1-SG2-SG3-Null
>          \
>           \__TC Interrupt (Almost same time as ARM is executing
> TC interrupt handler, an event got missed and also forgotten
> by clearing the EMR).

Sorry, but I dont see how edma_stop() is coming into picture in the race
you describe?

> The EMR is ultimately being cleared by the Error interrupt
> handler once it is handled so we don't have to do it in edma_stop.

This, I agree with. edma_clean_channel() also there to re-initialize the
channel so doing it in edma_stop() certainly seems superfluous.

Thanks,
Sekhar

> 
> Signed-off-by: Joel Fernandes <joelf at ti.com>
> ---
>  arch/arm/common/edma.c |    1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index 10995b2..dec772e 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -1328,7 +1328,6 @@ void edma_stop(unsigned channel)
>  		edma_shadow0_write_array(ctlr, SH_EECR, j, mask);
>  		edma_shadow0_write_array(ctlr, SH_ECR, j, mask);
>  		edma_shadow0_write_array(ctlr, SH_SECR, j, mask);
> -		edma_write_array(ctlr, EDMA_EMCR, j, mask);
>  
>  		pr_debug("EDMA: EER%d %08x\n", j,
>  				edma_shadow0_read_array(ctlr, SH_EER, j));
> 



From horms at verge.net.au  Tue Jul 30 04:31:49 2013
From: horms at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 17:31:49 +0900
Subject: [PATCH] ARM: shmobile: lager: do not annotate gpio_buttons as
 __initdata
In-Reply-To: <CANqRtoRUc1r_5=4HHa19ZCr71r1jv5AwZQ39Jv7eFNOUomtjag@mail.gmail.com>
References: <1374829772-10939-1-git-send-email-horms+renesas@verge.net.au>
 <CANqRtoRUc1r_5=4HHa19ZCr71r1jv5AwZQ39Jv7eFNOUomtjag@mail.gmail.com>
Message-ID: <20130730083148.GC12147@verge.net.au>

On Tue, Jul 30, 2013 at 05:26:57PM +0900, Magnus Damm wrote:
> On Fri, Jul 26, 2013 at 6:09 PM, Simon Horman
> <horms+renesas at verge.net.au> wrote:
> > When the gpio-keys device is registered using
> > platform_device_register_data() the platform data argument,
> > lager_keys_pdata is duplicated and thus should be marked as __initdata
> > to avoid wasting memory. However, this is not true of gpio_buttons,
> > a reference to it rather than its value is duplicated when lager_keys_pdata
> > is duplicated.
> >
> > This avoids accessing freed memory if gpio-key events occur
> > after unused kernel memory is freed late in the kernel's boot.
> >
> > This but was added when support for gpio-keys was added to lager
> > in c3842e4fcbb7664276443b79187b7808c2e80a35
> > ("ARM: shmobile: lager: support GPIO switches") which was included
> > in v3.11-rc1.
> >
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> >
> > ---
> >
> > * Noticed when adding gpio-keys support to ape6evm
> > * Compile tested only
> 
> I just got around to test this patch on a Lager board, works well. Thanks!
> 
> Tested-by: Magnus Damm <damm at opensource.se>

Thanks, I have queued this up for v3.11 in the fixes-for-v3.11 branch.


From shawn.guo at linaro.org  Tue Jul 30 04:38:05 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 30 Jul 2013 16:38:05 +0800
Subject: [PATCH 1/2] pinctrl: imx: Add exception hook for select input
In-Reply-To: <20130730080028.GA8540@nchen-desktop>
References: <1375152857-32177-1-git-send-email-peter.chen@freescale.com>
 <20130730075018.GD12382@S2101-09.ap.freescale.net>
 <20130730080028.GA8540@nchen-desktop>
Message-ID: <20130730083803.GF12382@S2101-09.ap.freescale.net>

On Tue, Jul 30, 2013 at 04:00:29PM +0800, Peter Chen wrote:
> I searched the RM, this is the only one. If you don't think we need
> to consider if it will occur in the future, I am OK to move it at machine
> code, but every mx6q board need it if it does not use default select input
> value.

Yes, maybe you can put it into imx6q_usb_init() with
if (IS_ENABLED(CONFIG_USB_OTG)) protect.

Shawn



From maxime.ripard at free-electrons.com  Tue Jul 30 04:39:32 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 10:39:32 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <CACxGe6sUFmLZMT+dvCbpmPrzR3DNMjw64LbD3n=JsjXsmrM-qg@mail.gmail.com>
References: <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
 <CACxGe6uE6jOE-vz0onW5h93Es-soGiBAcFBM7Dvxh+HvCNrHkw@mail.gmail.com>
 <CACxGe6vw9=y5a+EgF1gO39SwGAdGofD2MYjyJ3jYu6uN3ke70A@mail.gmail.com>
 <1374988276.1973.29.camel@dabdike>
 <20130730014453.GJ29970@voom.fritz.box>
 <CAKON4OyWuF+qm2MAhbXnGg=ozzw37kpSWciLxyUy+QQzxoWdxQ@mail.gmail.com>
 <20130730032926.GL29970@voom.fritz.box>
 <CACxGe6sUFmLZMT+dvCbpmPrzR3DNMjw64LbD3n=JsjXsmrM-qg@mail.gmail.com>
Message-ID: <20130730083932.GE1441@lukather>

On Mon, Jul 29, 2013 at 10:35:03PM -0600, Grant Likely wrote:
> >> User acquires a machine running ARM Linux version 3.x, with u-boot
> >> and dtb in a read only flash partition. The board boots and works just
> >> fine. However, for his application, the user requires a new kernel
> >> feature that appeared in version 3.y where y > x. He compiles the new
> >> kernel, and it also works.
> >
> > I'm afraid this kind of use case will never be properly supported, DT
> > stable ABI or not.
> 
> Why? New kernel features should be no problem at all.
> 
> New driver features /might/ not be available, but only if the new
> feature requires additional data that isn't present in the tree and
> cannot be obtained elsewhere.
> 
> >
> > Think about this: what kernel will actually be shipped in that board?
> > Most likely, it will be a BSP kernel from the vendor. Does the vendor
> > will have made that commitment to have a stable ABI for the DT? Will it
> > use the same bindings than mainline? Do we want to support all the crazy
> > bindings every vendor will come up with?
> 
> That's not a DT issue. That an out-of-tree board/SoC support issue. DT
> doesn't make that any better or worse.

Yet, with the DT switch, the two are bound together.

Before the DT, the only convention we had basically was that we had to
be loaded in memory and executed.

Now, the bootloader has to pass a complex data structure to the kernel.
If this data structure doesn't follow the same convention than we do, we
are screwed, and if we can't update either the bootloader or the DT that
is loaded by it, we end up screwed.

One example that comes to my mind right now is this one: we've been
arguing over spidev probing for quite some time. The easy solution would
be to add a "linux,spidev" compatible. Obviously, this has been ruled
out numerous time. Yet, in the beaglebone black out-of-tree kernel,
there is actually a patch that adds this compatible, that is later used
in the DTs.

These spidev part of the DTs will never work with vanilla. And if you
can't update the DT and want to use mainline, you'll never ever have the
same feature set.

That's of course just a small example, with not much impact on a system,
but that could be way worse.

But saying that vendors will follow the same convention we do is just
unrealistic. I mean, even us haven't be able to work out a stable ABI
for more than 2 years now, yet we should expect anyone else to do it?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130730/9def5cff/attachment.sig>

From mpa at pengutronix.de  Tue Jul 30 04:39:29 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Tue, 30 Jul 2013 10:39:29 +0200
Subject: [RFC 2/8] gpio: mxc: Support for initialization as submodule
In-Reply-To: <20130730034354.GF19715@S2101-09.ap.freescale.net>
References: <1374938808-27316-1-git-send-email-mpa@pengutronix.de>
 <1374938808-27316-3-git-send-email-mpa@pengutronix.de>
 <20130730034354.GF19715@S2101-09.ap.freescale.net>
Message-ID: <20130730083929.GI16871@s25.your-server.de>

On Tue, Jul 30, 2013 at 11:43:57AM +0800, Shawn Guo wrote:
> On Sat, Jul 27, 2013 at 05:26:42PM +0200, Markus Pargmann wrote:
> > On imx27 and imx21, there is no clear seperation between iomux control
> > registers and GPIO data registers. For easier pingroup definitions, the
> > gpio drivers will be initialized as subnodes of the iomux controller. It
> > is necessary to share the registers between iomux and gpio.
> > 
> > This patch adds support to pass a register memory region via platform
> > data.
> > 
> > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > ---
> >  drivers/gpio/gpio-mxc.c  | 35 +++++++++++++++++++----------------
> >  include/linux/gpio-mxc.h | 17 +++++++++++++++++
> >  2 files changed, 36 insertions(+), 16 deletions(-)
> >  create mode 100644 include/linux/gpio-mxc.h
> 
> Since the header is created only for holding platform_data, we should
> probably put it into include/linux/platform_data/.

Yes, I moved the header to include/linux/platform_data/gpio-mxc.h.

> > 
> > diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
> > index cee040f..0c4e32c 100644
> > --- a/drivers/gpio/gpio-mxc.c
> > +++ b/drivers/gpio/gpio-mxc.c
> > @@ -26,6 +26,7 @@
> >  #include <linux/irqdomain.h>
> >  #include <linux/irqchip/chained_irq.h>
> >  #include <linux/gpio.h>
> > +#include <linux/gpio-mxc.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/slab.h>
> >  #include <linux/basic_mmio_gpio.h>
> > @@ -400,6 +401,7 @@ static int mxc_gpio_probe(struct platform_device *pdev)
> >  	struct device_node *np = pdev->dev.of_node;
> >  	struct mxc_gpio_port *port;
> >  	struct resource *iores;
> > +	struct mxc_gpio_platform_data *pdata = pdev->dev.platform_data;
> >  	int irq_base;
> >  	int err;
> >  
> > @@ -410,27 +412,28 @@ static int mxc_gpio_probe(struct platform_device *pdev)
> >  	if (!port)
> >  		return -ENOMEM;
> >  
> > -	iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > -	if (!iores) {
> > -		return -ENODEV;
> > -	}
> > -
> > -	if (!devm_request_mem_region(&pdev->dev, iores->start,
> > -				resource_size(iores), pdev->name)) {
> > -		return -EBUSY;
> > -	}
> > -
> > -	port->base = devm_ioremap(&pdev->dev, iores->start,
> > -			resource_size(iores));
> > -	if (!port->base) {
> > -		return -ENOMEM;
> > +	if (pdata) {
> > +		port->base = pdata->base;
> > +		iores = NULL;
> 
> Why is this needed?

The memory regions used for iomux control overlap the regions used by
the gpio driver. So we need to share the memory with the pinctrl driver.

> 
> > +	} else {
> > +		iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +		if (!iores)
> > +			return -ENODEV;
> > +
> > +		if (!devm_request_mem_region(&pdev->dev, iores->start,
> > +					resource_size(iores), pdev->name))
> > +			return -EBUSY;
> > +
> > +		port->base = devm_ioremap(&pdev->dev, iores->start,
> > +				resource_size(iores));
> > +		if (!port->base)
> > +			return -ENOMEM;
> >  	}
> >  
> >  	port->irq_high = platform_get_irq(pdev, 1);
> >  	port->irq = platform_get_irq(pdev, 0);
> > -	if (port->irq < 0) {
> > +	if (port->irq < 0)
> >  		return -EINVAL;
> > -	}
> 
> The change belongs to patch #1.

Removed from this patch.

Thanks,

Markus

> 
> Shawn
> 
> >  
> >  	/* disable the interrupt and clear the status */
> >  	writel(0, port->base + GPIO_IMR);
> > diff --git a/include/linux/gpio-mxc.h b/include/linux/gpio-mxc.h
> > new file mode 100644
> > index 0000000..6be51bc
> > --- /dev/null
> > +++ b/include/linux/gpio-mxc.h
> > @@ -0,0 +1,17 @@
> > +#ifndef _LINUX_GPIO_MXC_H
> > +#define _LINUX_GPIO_MXC_H
> > +
> > +#include <linux/types.h>
> > +
> > +/*
> > + * MXC GPIO driver platform data. If this platform data is passed to the
> > + * driver, it will use the memory base defined in the struct. This is used for
> > + * iomuxc drivers on imx21 and imx27, where the GPIO data register is embedded
> > + * between the iomuxc registers.
> > + */
> > +
> > +struct mxc_gpio_platform_data {
> > +	void __iomem *base;
> > +};
> > +
> > +#endif /* _LINUX_GPIO_MXC_H */
> > -- 
> > 1.8.3.2
> > 
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From mpa at pengutronix.de  Tue Jul 30 04:41:09 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Tue, 30 Jul 2013 10:41:09 +0200
Subject: [RFC 1/8] gpio: mxc: Use devm_ functions
In-Reply-To: <CAOMZO5Afr5zZLonmHm1PO4L6ed5SJ2K+vywX3Uu1etBTcrryYg@mail.gmail.com>
References: <1374938808-27316-1-git-send-email-mpa@pengutronix.de>
 <1374938808-27316-2-git-send-email-mpa@pengutronix.de>
 <20130730031436.GE19715@S2101-09.ap.freescale.net>
 <CAOMZO5Afr5zZLonmHm1PO4L6ed5SJ2K+vywX3Uu1etBTcrryYg@mail.gmail.com>
Message-ID: <20130730084109.GJ16871@s25.your-server.de>

On Tue, Jul 30, 2013 at 12:45:33AM -0300, Fabio Estevam wrote:
> On Tue, Jul 30, 2013 at 12:14 AM, Shawn Guo <shawn.guo at linaro.org> wrote:
> 
> > It can be even cleaner by using devm_ioremap_resource().
> 
> I have already sent a patch that converts to devm_ioremap_resource()
> and it is already in Linus Walleij's tree.
> 
Thanks, I will remove this patch and use yours.

Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From andrew at lunn.ch  Tue Jul 30 04:40:22 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 30 Jul 2013 10:40:22 +0200
Subject: [PATCH 4/4] ARM: dove: add initial DT file for Globalscale D2Plug
In-Reply-To: <51F7736C.5040701@gmail.com>
References: <1375100946-28521-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1375100946-28521-5-git-send-email-sebastian.hesselbarth@gmail.com>
 <20130729184520.GI24782@lunn.ch> <51F7736C.5040701@gmail.com>
Message-ID: <20130730084022.GO24782@lunn.ch>

On Tue, Jul 30, 2013 at 10:03:56AM +0200, Sebastian Hesselbarth wrote:
> On 07/29/2013 08:45 PM, Andrew Lunn wrote:
> >On Mon, Jul 29, 2013 at 02:29:06PM +0200, Sebastian Hesselbarth wrote:
> >>This adds an initial DT file for the Globalscale D2Plug with Dove SoC.
> >>Currently, one LED is missing and I have not been able to get SD8787 driver
> >>working. Those will be taken care of later.
> >
> >I took a hard look at SDIO and failed to get it working when doing
> >DMA. Polled IO does however work. I guess we need some help from
> >Marvell engineers before we get stable SDIO with DMA.
> 
> Andrew,
> 
> have you tried this on the Dove D2Plug or any other Marvell SoC?

Hi Sebastian

I only tried it on Kirkwood. I've had similar bug reports for 370,
which appears to shares the same IP core.

> Dove is using a different SDHCI compatible SDIO controller.

Ah, O.K. Didn't know. It will be interesting to see if this core has
the same problems, i.e. shares the same DMA engine as the MVSDIO core.

> Also, the DMA issue is not holding back this patch, is it?

No, not at all. I just wanted to point out, there are known problems
with the in kernel driver for MVSDIO.

     Andrew


From daniel.lezcano at linaro.org  Tue Jul 30 04:47:15 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 30 Jul 2013 10:47:15 +0200
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
References: <20130717210417.GP13667@xsjandreislx>
 <51E72DCA.9070500@codeaurora.org>
 <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
 <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
Message-ID: <51F77D93.4030505@linaro.org>

On 07/30/2013 02:03 AM, S?ren Brinkmann wrote:
> Hi Daniel,
> 
> On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
> (snip)
>>
>> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
>> timer will be stopped when entering to the idle state. In this case, the
>> cpuidle framework will call clockevents_notify(ENTER) and switches to a
>> broadcast timer and will call clockevents_notify(EXIT) when exiting the
>> idle state, switching the local timer back in use.
> 
> I've been thinking about this, trying to understand how this makes my
> boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
> would make the timer core switch to a broadcast device even though it
> wouldn't be necessary. But shouldn't it still work? It sounds like we do
> something useless, but nothing wrong in a sense that it should result in
> breakage. I guess I'm missing something obvious. This timer system will
> always remain a mystery to me.
> 
> Actually this more or less leads to the question: What is this
> 'broadcast timer'. I guess that is some clockevent device which is
> common to all cores? (that would be the cadence_ttc for Zynq). Is the
> hang pointing to some issue with that driver?

If you look at the /proc/timer_list, which timer is used for broadcasting ?

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From mpa at pengutronix.de  Tue Jul 30 04:57:27 2013
From: mpa at pengutronix.de (Markus Pargmann)
Date: Tue, 30 Jul 2013 10:57:27 +0200
Subject: [RFC 5/8] pinctrl: imx27: imx27 pincontrol driver
In-Reply-To: <20130730060955.GA12382@S2101-09.ap.freescale.net>
References: <1374938808-27316-1-git-send-email-mpa@pengutronix.de>
 <1374938808-27316-6-git-send-email-mpa@pengutronix.de>
 <20130730060955.GA12382@S2101-09.ap.freescale.net>
Message-ID: <20130730085727.GK16871@s25.your-server.de>

On Tue, Jul 30, 2013 at 02:09:57PM +0800, Shawn Guo wrote:
> On Sat, Jul 27, 2013 at 05:26:45PM +0200, Markus Pargmann wrote:
> > +static struct imx_pinctrl_soc_info imx27_pinctrl_info = {
> > + .pins = imx27_pinctrl_pads,
> > + .npins = ARRAY_SIZE(imx27_pinctrl_pads),
> > +};
> > +
> > +static struct of_device_id imx27_pinctrl_of_match[] = {
> > + { .compatible = "fsl,imx27-iomuxc", },
> > + { /* sentinel */ }
> > +};
> > +
> > +static struct of_device_id imx21_gpio_of_match[] = {
> > + { .compatible = "fsl,imx21-gpio", },
> 
> Since we also have "fsl,imx27-gpio" in the compatible string, we can
> use it here.

Yes, but I moved the child gpio detection into imx1 core driver now,
where I use "fsl,imx1-gpio" and "fsl,imx21-gpio".

> 
> > + { /* sentinel */ }
> > +};
> > +
> > +struct imx27_pinctrl_private {
> > + int num_gpio_childs;
> 
> Maybe I missed something.  But I see this member is used nowhere.
> 
> > + struct platform_device **gpio_dev;
> > + struct mxc_gpio_platform_data *gpio_pdata;
> > +};
> 
> I do not see too much point to have this structure at all.

I forgot to add put_device calls in the driver remove function. So the
structure is used now.

Thanks,

Markus

> 
> Shawn
> 
> > +
> > +static int imx27_pinctrl_probe(struct platform_device *pdev)
> > +{
> > + struct device_node *child;
> > + struct imx_pinctrl *ipctl;
> > + struct imx27_pinctrl_private *pctl;
> > + int ret;
> > + u32 base_addr;
> > + int num_gpios = 0;
> > + int i = 0;
> > +
> > + ret = of_property_read_u32(pdev->dev.of_node, "reg", &base_addr);
> > + if (ret)
> > + return ret;
> > +
> > + ret = imx_pinctrl_probe(pdev, &imx27_pinctrl_info);
> > + if (ret)
> > + return ret;
> > +
> > + pctl = devm_kzalloc(&pdev->dev, sizeof(*pctl), GFP_KERNEL);
> > + if (!pctl)
> > + return -ENOMEM;
> > +
> > + ipctl = platform_get_drvdata(pdev);
> > +
> > + for_each_available_child_of_node(pdev->dev.of_node, child) {
> > + u32 memoffset;
> > + if (!of_match_node(imx21_gpio_of_match, child))
> > + continue;
> > + ret = of_property_read_u32(child, "reg", &memoffset);
> > + if (ret)
> > + continue;
> > + ++num_gpios;
> > + }
> > +
> > + pctl->num_gpio_childs = num_gpios;
> > + pctl->gpio_dev = devm_kzalloc(&pdev->dev,
> > + sizeof(*pctl->gpio_dev) * num_gpios, GFP_KERNEL);
> > + pctl->gpio_pdata = devm_kzalloc(&pdev->dev,
> > + sizeof(*pctl->gpio_pdata) * num_gpios, GFP_KERNEL);
> > +
> > + if (!pctl->gpio_pdata || !pctl->gpio_dev)
> > + return -ENOMEM;
> > +
> > +
> > + for_each_available_child_of_node(pdev->dev.of_node, child) {
> > + u32 memoffset;
> > +
> > + if (!of_match_node(imx21_gpio_of_match, child))
> > + continue;
> > + ret = of_property_read_u32(child, "reg", &memoffset);
> > + if (ret)
> > + continue;
> > +
> > + memoffset -= base_addr;
> > + pctl->gpio_pdata[i].base = ipctl->base + memoffset;
> > +
> > + pctl->gpio_dev[i] = of_device_alloc(child, NULL, &pdev->dev);
> > + pctl->gpio_dev[i]->dev.platform_data = &pctl->gpio_pdata[i];
> > + pctl->gpio_dev[i]->dev.bus = &platform_bus_type;
> > +
> > + ret = of_device_add(pctl->gpio_dev[i]);
> > + if (ret) {
> > + dev_err(&pdev->dev,
> > + "Failed to add child gpio device\n");
> > + goto gpio_err;
> > + }
> > + ++i;
> > + }
> > + return 0;
> > +gpio_err:
> > + while (i--)
> > + put_device(&pctl->gpio_dev[i]->dev);
> > + return ret;
> > +}
> > +
> > +static struct platform_driver imx27_pinctrl_driver = {
> > + .driver = {
> > + .name = "imx27-pinctrl",
> > + .owner = THIS_MODULE,
> > + .of_match_table = of_match_ptr(imx27_pinctrl_of_match),
> > + },
> > + .probe = imx27_pinctrl_probe,
> > + .remove = imx_pinctrl_remove,
> > +};
> > +
> > +static int __init imx27_pinctrl_init(void)
> > +{
> > + return platform_driver_register(&imx27_pinctrl_driver);
> > +}
> > +arch_initcall(imx27_pinctrl_init);
> > +
> > +static void __exit imx27_pinctrl_exit(void)
> > +{
> > + platform_driver_unregister(&imx27_pinctrl_driver);
> > +}
> > +module_exit(imx27_pinctrl_exit);
> > +MODULE_AUTHOR("Markus Pargmann <mpa at pengutronix.de>");
> > +MODULE_DESCRIPTION("Freescale IMX27 pinctrl driver");
> > +MODULE_LICENSE("GPL v2");
> > --
> > 1.8.3.2
> >
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From marc.zyngier at arm.com  Tue Jul 30 04:59:02 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 30 Jul 2013 09:59:02 +0100
Subject: [PATCH 05/10] ARM: sunxi: Add Allwinner A31 DTSI
In-Reply-To: <1374618312-19001-6-git-send-email-maxime.ripard@free-electrons.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374618312-19001-6-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <51F78056.6000104@arm.com>

Hi Maxime,

On 23/07/13 23:25, Maxime Ripard wrote:
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  arch/arm/boot/dts/Makefile       |   3 +-
>  arch/arm/boot/dts/sun6i-a31.dtsi | 155 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 157 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/sun6i-a31.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 641b3c9..1482533 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -210,7 +210,8 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
>  	sun4i-a10-mini-xplus.dtb \
>  	sun4i-a10-hackberry.dtb \
>  	sun5i-a10s-olinuxino-micro.dtb \
> -	sun5i-a13-olinuxino.dtb
> +	sun5i-a13-olinuxino.dtb \
> +	sun6i-a31-colombus.dtb
>  dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
>  	tegra20-iris-512.dtb \
>  	tegra20-medcom-wide.dtb \
> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
> new file mode 100644
> index 0000000..c6c19a9
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> @@ -0,0 +1,155 @@
> +/*
> + * Copyright 2013 Maxime Ripard
> + *
> + * Maxime Ripard <maxime.ripard at free-electrons.com>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/include/ "skeleton.dtsi"
> +

[...]

> +		gic: interrupt-controller at 01c81000 {
> +			compatible = "arm,cortex-a7-gic";
> +			reg = <0x01c81000 0x1000>, <0x01c82000 0x100>;

Th Cortex A7 TRM indicates that its GIC has the virtualization
extensions. You should reflect this in the binding (wider GICC range,
GICH and GICV ranges, maintenance interrupt).

See
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0464d/BGBJFJJA.html
for details.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From maxime.ripard at free-electrons.com  Tue Jul 30 05:00:20 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 11:00:20 +0200
Subject: [PATCH 07/10] pinctrl: sunxi: Add Allwinner A31 pins set
In-Reply-To: <CACRpkdZ1RhsLMC0xWDDr9Hmy78i+uU-9x0-2Y+_NvRZ-yefmVw@mail.gmail.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374618312-19001-8-git-send-email-maxime.ripard@free-electrons.com>
 <CACRpkdZ1RhsLMC0xWDDr9Hmy78i+uU-9x0-2Y+_NvRZ-yefmVw@mail.gmail.com>
Message-ID: <20130730090020.GF1441@lukather>

Hi Linus,

On Mon, Jul 29, 2013 at 06:20:13PM +0200, Linus Walleij wrote:
> On Wed, Jul 24, 2013 at 12:25 AM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> 
> > The Allwinner A31 SoC uses the same IP than the one found in the
> > A10/A13, with only different pins. Add the pins and the associated
> > functions found in the A31.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> 
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> 
> Will you carry this through ARM SoC or do you want me to merge
> this into the pinctrl tree? It seems pretty independent.

I'd prefer if you could merge it through the pinctrl tree.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130730/045c63a8/attachment.sig>

From horms+renesas at verge.net.au  Tue Jul 30 05:00:41 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 18:00:41 +0900
Subject: [PATCH 0/5] Renesas ARM-based SoC board updates for v3.12
Message-ID: <cover.1375174556.git.horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

please consider these Renesas ARM-based SoC board updates for v3.12.
This pull-request is based on renesas-soc-for-v3.12 which I have previously
sent a pull-request for.

The following changes since commit 81b9d5351fa96caad4accc6711bc1b9342927d4a:

  ARM: shmobile: Setup r8a7790 arch timer based on MD pins (2013-07-17 14:26:56 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git boards

for you to fetch changes up to f79d68da510bf1b95beff4d556b78d06801f11dc:

  ARM: shmobile: ape6evm: add SDHI interfaces (2013-07-25 14:46:38 +0900)

----------------------------------------------------------------
Renesas ARM-based SoC board updates for v3.12

* ape6evm: Add SDHI and MMCIF support
* lager: Add MMCIF support
* armadillo800eva: Add DMA support for MMCIF

----------------------------------------------------------------
Guennadi Liakhovetski (4):
      ARM: shmobile: armadillo800eva: add DMA support to MMCIF
      ARM: shmobile: lager: add MMCIF support
      ARM: shmobile: ape6evm: add MMCIF support
      ARM: shmobile: ape6evm: add SDHI interfaces

Kuninori Morimoto (1):
      ARM: shmobile: select the fixed regulator driver on BockW

 arch/arm/mach-shmobile/Kconfig                 |  1 +
 arch/arm/mach-shmobile/board-ape6evm.c         | 79 ++++++++++++++++++++++++++
 arch/arm/mach-shmobile/board-armadillo800eva.c |  2 +
 arch/arm/mach-shmobile/board-lager.c           | 31 ++++++++++
 4 files changed, 113 insertions(+)


From horms+renesas at verge.net.au  Tue Jul 30 05:00:51 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 18:00:51 +0900
Subject: [PATCH 3/5] ARM: shmobile: select the fixed regulator driver on BockW
In-Reply-To: <cover.1375174556.git.horms+renesas@verge.net.au>
References: <cover.1375174556.git.horms+renesas@verge.net.au>
Message-ID: <c9996e51e45df0630cf5493fa0359a257a191eee.1375174556.git.horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

34767f8dccc326026f97cd63f759dd36bd83502d
(ARM: mach-shmobile: select the fixed regulator driver on several boards)
decided to select fixed regulator driver on Kconfig.
BockW follows same style.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
[horms+renesas at verge.net.au: Change mach-shmobile to shmobile in changelog]
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index dd80f21..f76fca6 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -124,6 +124,7 @@ config MACH_BOCKW
 	depends on ARCH_R8A7778
 	select ARCH_REQUIRE_GPIOLIB
 	select RENESAS_INTC_IRQPIN
+	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select USE_OF
 
 config MACH_MARZEN
-- 
1.8.3.2



From horms+renesas at verge.net.au  Tue Jul 30 05:00:49 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 18:00:49 +0900
Subject: [PATCH 1/5] ARM: shmobile: armadillo800eva: add DMA support to MMCIF
In-Reply-To: <cover.1375174556.git.horms+renesas@verge.net.au>
References: <cover.1375174556.git.horms+renesas@verge.net.au>
Message-ID: <872842084c6f01d5f9d1a4c9b7e39a3d68d0630d.1375174556.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Add DMA slave IDs to MMCIF Tx and Rx channels.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-armadillo800eva.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 66cfd56..4432f05 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -779,6 +779,8 @@ static struct sh_mmcif_plat_data sh_mmcif_plat = {
 	.caps		= MMC_CAP_4_BIT_DATA |
 			  MMC_CAP_8_BIT_DATA |
 			  MMC_CAP_NONREMOVABLE,
+	.slave_id_tx	= SHDMA_SLAVE_MMCIF_TX,
+	.slave_id_rx	= SHDMA_SLAVE_MMCIF_RX,
 };
 
 static struct resource sh_mmcif_resources[] = {
-- 
1.8.3.2



From horms+renesas at verge.net.au  Tue Jul 30 05:00:50 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 18:00:50 +0900
Subject: [PATCH 2/5] ARM: shmobile: lager: add MMCIF support
In-Reply-To: <cover.1375174556.git.horms+renesas@verge.net.au>
References: <cover.1375174556.git.horms+renesas@verge.net.au>
Message-ID: <63d0539e5466e1c5765b9dfdffafd619d4115ba5.1375174556.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Add support for the MMCIF1 interface on Lager.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-lager.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index d0da052..3c67b2a 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -24,10 +24,15 @@
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
 #include <linux/leds.h>
+#include <linux/mmc/host.h>
+#include <linux/mmc/sh_mmcif.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_device.h>
+#include <linux/regulator/fixed.h>
+#include <linux/regulator/machine.h>
 #include <mach/common.h>
+#include <mach/irqs.h>
 #include <mach/r8a7790.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -70,6 +75,22 @@ static __initdata struct gpio_keys_platform_data lager_keys_pdata = {
 	.nbuttons	= ARRAY_SIZE(gpio_buttons),
 };
 
+/* Fixed 3.3V regulator to be used by MMCIF */
+static struct regulator_consumer_supply fixed3v3_power_consumers[] =
+{
+	REGULATOR_SUPPLY("vmmc", "sh_mmcif.1"),
+};
+
+/* MMCIF */
+static struct sh_mmcif_plat_data mmcif1_pdata = {
+	.caps		= MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
+};
+
+static struct resource mmcif1_resources[] = {
+	DEFINE_RES_MEM_NAMED(0xee220000, 0x80, "MMCIF1"),
+	DEFINE_RES_IRQ(gic_spi(170)),
+};
+
 static const struct pinctrl_map lager_pinctrl_map[] = {
 	/* SCIF0 (CN19: DEBUG SERIAL0) */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7790",
@@ -77,6 +98,11 @@ static const struct pinctrl_map lager_pinctrl_map[] = {
 	/* SCIF1 (CN20: DEBUG SERIAL1) */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.7", "pfc-r8a7790",
 				  "scif1_data", "scif1"),
+	/* MMCIF1 */
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.1", "pfc-r8a7790",
+				  "mmc1_data8", "mmc1"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.1", "pfc-r8a7790",
+				  "mmc1_ctrl", "mmc1"),
 };
 
 static void __init lager_add_standard_devices(void)
@@ -94,6 +120,11 @@ static void __init lager_add_standard_devices(void)
 	platform_device_register_data(&platform_bus, "gpio-keys", -1,
 				      &lager_keys_pdata,
 				      sizeof(lager_keys_pdata));
+	regulator_register_always_on(0, "fixed-3.3V", fixed3v3_power_consumers,
+				     ARRAY_SIZE(fixed3v3_power_consumers), 3300000);
+	platform_device_register_resndata(&platform_bus, "sh_mmcif", 1,
+					  mmcif1_resources, ARRAY_SIZE(mmcif1_resources),
+					  &mmcif1_pdata, sizeof(mmcif1_pdata));
 }
 
 static const char *lager_boards_compat_dt[] __initdata = {
-- 
1.8.3.2



From horms+renesas at verge.net.au  Tue Jul 30 05:00:52 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 18:00:52 +0900
Subject: [PATCH 4/5] ARM: shmobile: ape6evm: add MMCIF support
In-Reply-To: <cover.1375174556.git.horms+renesas@verge.net.au>
References: <cover.1375174556.git.horms+renesas@verge.net.au>
Message-ID: <8711613252ed931037f9e9f8646935519dd8f362.1375174556.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Add MMCIF support to the APE6EVM board in PIO mode only. Power supply is
fixed for now, eventually support for the tps80032 regulator, also
supplying both VDD and VccQ to the MMCIF slot should be added to APE6EVM.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Acked-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-ape6evm.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
index af6dd39..8c7529c 100644
--- a/arch/arm/mach-shmobile/board-ape6evm.c
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -21,6 +21,8 @@
 #include <linux/gpio.h>
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
+#include <linux/mmc/host.h>
+#include <linux/mmc/sh_mmcif.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/platform_device.h>
 #include <linux/regulator/fixed.h>
@@ -54,6 +56,25 @@ static const struct smsc911x_platform_config lan9220_data = {
 	.irq_polarity	= SMSC911X_IRQ_POLARITY_ACTIVE_HIGH,
 };
 
+/*
+ * On APE6EVM power is supplied to MMCIF by a tps80032 regulator. For now we
+ * model a VDD supply to MMCIF, using a fixed 3.3V regulator.
+ */
+static struct regulator_consumer_supply fixed3v3_power_consumers[] =
+{
+	REGULATOR_SUPPLY("vmmc", "sh_mmcif.0"),
+};
+
+/* MMCIF */
+static struct sh_mmcif_plat_data mmcif0_pdata = {
+	.caps		= MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
+};
+
+static struct resource mmcif0_resources[] = {
+	DEFINE_RES_MEM_NAMED(0xee200000, 0x100, "MMCIF0"),
+	DEFINE_RES_IRQ(gic_spi(169)),
+};
+
 static const struct pinctrl_map ape6evm_pinctrl_map[] = {
 	/* SCIFA0 console */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a73a4",
@@ -61,6 +82,11 @@ static const struct pinctrl_map ape6evm_pinctrl_map[] = {
 	/* SMSC */
 	PIN_MAP_MUX_GROUP_DEFAULT("smsc911x", "pfc-r8a73a4",
 				  "irqc_irq40", "irqc"),
+	/* MMCIF0 */
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-r8a73a4",
+				  "mmc0_data8", "mmc0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-r8a73a4",
+				  "mmc0_ctrl", "mmc0"),
 };
 
 static void __init ape6evm_add_standard_devices(void)
@@ -93,6 +119,11 @@ static void __init ape6evm_add_standard_devices(void)
 	platform_device_register_resndata(&platform_bus, "smsc911x", -1,
 					  lan9220_res, ARRAY_SIZE(lan9220_res),
 					  &lan9220_data, sizeof(lan9220_data));
+	regulator_register_always_on(1, "fixed-3.3V", fixed3v3_power_consumers,
+				     ARRAY_SIZE(fixed3v3_power_consumers), 3300000);
+	platform_device_register_resndata(&platform_bus, "sh_mmcif", 0,
+					  mmcif0_resources, ARRAY_SIZE(mmcif0_resources),
+					  &mmcif0_pdata, sizeof(mmcif0_pdata));
 }
 
 static const char *ape6evm_boards_compat_dt[] __initdata = {
-- 
1.8.3.2



From horms+renesas at verge.net.au  Tue Jul 30 05:00:53 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 18:00:53 +0900
Subject: [PATCH 5/5] ARM: shmobile: ape6evm: add SDHI interfaces
In-Reply-To: <cover.1375174556.git.horms+renesas@verge.net.au>
References: <cover.1375174556.git.horms+renesas@verge.net.au>
Message-ID: <f79d68da510bf1b95beff4d556b78d06801f11dc.1375174556.git.horms+renesas@verge.net.au>

From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Add support for SDHI0 and SDHI1 on APE6EVM in PIO mode only.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-ape6evm.c | 50 +++++++++++++++++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
index 8c7529c..ccf8b04 100644
--- a/arch/arm/mach-shmobile/board-ape6evm.c
+++ b/arch/arm/mach-shmobile/board-ape6evm.c
@@ -21,8 +21,10 @@
 #include <linux/gpio.h>
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
+#include <linux/mfd/tmio.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/sh_mmcif.h>
+#include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/platform_device.h>
 #include <linux/regulator/fixed.h>
@@ -58,11 +60,16 @@ static const struct smsc911x_platform_config lan9220_data = {
 
 /*
  * On APE6EVM power is supplied to MMCIF by a tps80032 regulator. For now we
- * model a VDD supply to MMCIF, using a fixed 3.3V regulator.
+ * model a VDD supply to MMCIF, using a fixed 3.3V regulator. Also use the
+ * static power supply for SDHI0 and SDHI1, whereas SDHI0's VccQ is also
+ * supplied by the same tps80032 regulator and thus can also be adjusted
+ * dynamically.
  */
 static struct regulator_consumer_supply fixed3v3_power_consumers[] =
 {
 	REGULATOR_SUPPLY("vmmc", "sh_mmcif.0"),
+	REGULATOR_SUPPLY("vmmc", "sh_mobile_sdhi.0"),
+	REGULATOR_SUPPLY("vmmc", "sh_mobile_sdhi.1"),
 };
 
 /* MMCIF */
@@ -75,6 +82,29 @@ static struct resource mmcif0_resources[] = {
 	DEFINE_RES_IRQ(gic_spi(169)),
 };
 
+/* SDHI0 */
+static struct sh_mobile_sdhi_info sdhi0_pdata = {
+	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE,
+	.tmio_caps	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
+};
+
+static struct resource sdhi0_resources[] = {
+	DEFINE_RES_MEM_NAMED(0xee100000, 0x100, "SDHI0"),
+	DEFINE_RES_IRQ(gic_spi(165)),
+};
+
+/* SDHI1 */
+static struct sh_mobile_sdhi_info sdhi1_pdata = {
+	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE,
+	.tmio_caps	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
+			  MMC_CAP_NEEDS_POLL,
+};
+
+static struct resource sdhi1_resources[] = {
+	DEFINE_RES_MEM_NAMED(0xee120000, 0x100, "SDHI1"),
+	DEFINE_RES_IRQ(gic_spi(166)),
+};
+
 static const struct pinctrl_map ape6evm_pinctrl_map[] = {
 	/* SCIFA0 console */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a73a4",
@@ -87,6 +117,18 @@ static const struct pinctrl_map ape6evm_pinctrl_map[] = {
 				  "mmc0_data8", "mmc0"),
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.0", "pfc-r8a73a4",
 				  "mmc0_ctrl", "mmc0"),
+	/* SDHI0: uSD: no WP */
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a73a4",
+				  "sdhi0_data4", "sdhi0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a73a4",
+				  "sdhi0_ctrl", "sdhi0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a73a4",
+				  "sdhi0_cd", "sdhi0"),
+	/* SDHI1 */
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.1", "pfc-r8a73a4",
+				  "sdhi1_data4", "sdhi1"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.1", "pfc-r8a73a4",
+				  "sdhi1_ctrl", "sdhi1"),
 };
 
 static void __init ape6evm_add_standard_devices(void)
@@ -124,6 +166,12 @@ static void __init ape6evm_add_standard_devices(void)
 	platform_device_register_resndata(&platform_bus, "sh_mmcif", 0,
 					  mmcif0_resources, ARRAY_SIZE(mmcif0_resources),
 					  &mmcif0_pdata, sizeof(mmcif0_pdata));
+	platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0,
+					  sdhi0_resources, ARRAY_SIZE(sdhi0_resources),
+					  &sdhi0_pdata, sizeof(sdhi0_pdata));
+	platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 1,
+					  sdhi1_resources, ARRAY_SIZE(sdhi1_resources),
+					  &sdhi1_pdata, sizeof(sdhi1_pdata));
 }
 
 static const char *ape6evm_boards_compat_dt[] __initdata = {
-- 
1.8.3.2



From 21cnbao at gmail.com  Tue Jul 30 05:05:59 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Tue, 30 Jul 2013 17:05:59 +0800
Subject: [PATCH v2] arm: prima2: move to generic reset controller driver
 framework
Message-ID: <1375175159-13953-1-git-send-email-Baohua.Song@csr.com>

this moves to generic IP module reset framework, and make other drivers
use common device_reset() API.

Cc: Srinivas Kandagatla <srinivas.kandagatla at st.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 -v2: rebase againest 3.11-rc;
 move the init function to init_machine to avoid redundant calling
 for non-csr platforms of multi-platform;

 arch/arm/boot/dts/atlas6.dtsi |  3 +-
 arch/arm/boot/dts/marco.dtsi  |  3 +-
 arch/arm/boot/dts/prima2.dtsi |  3 +-
 arch/arm/mach-prima2/Kconfig  |  1 +
 arch/arm/mach-prima2/common.c | 12 +++++++-
 arch/arm/mach-prima2/common.h |  1 +
 arch/arm/mach-prima2/rstc.c   | 72 +++++++++++++++++++++++++------------------
 7 files changed, 61 insertions(+), 34 deletions(-)

diff --git a/arch/arm/boot/dts/atlas6.dtsi b/arch/arm/boot/dts/atlas6.dtsi
index 9866cd7..e3f3ec8 100644
--- a/arch/arm/boot/dts/atlas6.dtsi
+++ b/arch/arm/boot/dts/atlas6.dtsi
@@ -56,9 +56,10 @@
 				#clock-cells = <1>;
 			};
 
-			reset-controller at 88010000 {
+			rstc: reset-controller at 88010000 {
 				compatible = "sirf,prima2-rstc";
 				reg = <0x88010000 0x1000>;
+				#reset-cells = <1>;
 			};
 
 			rsc-controller at 88020000 {
diff --git a/arch/arm/boot/dts/marco.dtsi b/arch/arm/boot/dts/marco.dtsi
index 1579c34..0c9647d 100644
--- a/arch/arm/boot/dts/marco.dtsi
+++ b/arch/arm/boot/dts/marco.dtsi
@@ -58,9 +58,10 @@
 			#size-cells = <1>;
 			ranges = <0xc2000000 0xc2000000 0x1000000>;
 
-			reset-controller at c2000000 {
+			rstc: reset-controller at c2000000 {
 				compatible = "sirf,marco-rstc";
 				reg = <0xc2000000 0x10000>;
+				#reset-cells = <1>;
 			};
 		};
 
diff --git a/arch/arm/boot/dts/prima2.dtsi b/arch/arm/boot/dts/prima2.dtsi
index 05e9489..3560ad3 100644
--- a/arch/arm/boot/dts/prima2.dtsi
+++ b/arch/arm/boot/dts/prima2.dtsi
@@ -67,9 +67,10 @@
 				#clock-cells = <1>;
 			};
 
-			reset-controller at 88010000 {
+			rstc: reset-controller at 88010000 {
 				compatible = "sirf,prima2-rstc";
 				reg = <0x88010000 0x1000>;
+				#reset-cells = <1>;
 			};
 
 			rsc-controller at 88020000 {
diff --git a/arch/arm/mach-prima2/Kconfig b/arch/arm/mach-prima2/Kconfig
index 6988b11..f37a1de 100644
--- a/arch/arm/mach-prima2/Kconfig
+++ b/arch/arm/mach-prima2/Kconfig
@@ -1,5 +1,6 @@
 config ARCH_SIRF
 	bool "CSR SiRF" if ARCH_MULTI_V7
+	select ARCH_HAS_RESET_CONTROLLER
 	select ARCH_REQUIRE_GPIOLIB
 	select GENERIC_CLOCKEVENTS
 	select GENERIC_IRQ_CHIP
diff --git a/arch/arm/mach-prima2/common.c b/arch/arm/mach-prima2/common.c
index 2c70f74..73db0dc 100644
--- a/arch/arm/mach-prima2/common.c
+++ b/arch/arm/mach-prima2/common.c
@@ -16,7 +16,14 @@
 #include <linux/of_platform.h>
 #include "common.h"
 
-void __init sirfsoc_init_late(void)
+static void __init sirfsoc_init_mach(void)
+{
+        sirfsoc_of_rstc_init();
+        of_platform_populate(NULL, of_default_bus_match_table,
+                NULL, NULL);
+}
+
+static void __init sirfsoc_init_late(void)
 {
 	sirfsoc_pm_init();
 }
@@ -45,6 +52,7 @@ DT_MACHINE_START(ATLAS6_DT, "Generic ATLAS6 (Flattened Device Tree)")
 	.nr_irqs	= 128,
 	.map_io         = sirfsoc_map_io,
 	.init_time	= sirfsoc_init_time,
+	.init_machine   = sirfsoc_init_mach,
 	.init_late	= sirfsoc_init_late,
 	.dt_compat      = atlas6_dt_match,
 	.restart	= sirfsoc_restart,
@@ -62,6 +70,7 @@ DT_MACHINE_START(PRIMA2_DT, "Generic PRIMA2 (Flattened Device Tree)")
 	.nr_irqs	= 128,
 	.map_io         = sirfsoc_map_io,
 	.init_time	= sirfsoc_init_time,
+	.init_machine   = sirfsoc_init_mach,
 	.dma_zone_size	= SZ_256M,
 	.init_late	= sirfsoc_init_late,
 	.dt_compat      = prima2_dt_match,
@@ -80,6 +89,7 @@ DT_MACHINE_START(MARCO_DT, "Generic MARCO (Flattened Device Tree)")
 	.smp            = smp_ops(sirfsoc_smp_ops),
 	.map_io         = sirfsoc_map_io,
 	.init_time	= sirfsoc_init_time,
+	.init_machine   = sirfsoc_init_mach,
 	.init_late	= sirfsoc_init_late,
 	.dt_compat      = marco_dt_match,
 	.restart	= sirfsoc_restart,
diff --git a/arch/arm/mach-prima2/common.h b/arch/arm/mach-prima2/common.h
index a630485..aaf8d5a 100644
--- a/arch/arm/mach-prima2/common.h
+++ b/arch/arm/mach-prima2/common.h
@@ -22,6 +22,7 @@ extern struct smp_operations   sirfsoc_smp_ops;
 extern void sirfsoc_secondary_startup(void);
 extern void sirfsoc_cpu_die(unsigned int cpu);
 
+extern void __init sirfsoc_of_rstc_init(void);
 extern void __init sirfsoc_of_irq_init(void);
 extern void __init sirfsoc_of_clk_init(void);
 extern void sirfsoc_restart(enum reboot_mode, const char *);
diff --git a/arch/arm/mach-prima2/rstc.c b/arch/arm/mach-prima2/rstc.c
index ccb5339..fee28d8 100644
--- a/arch/arm/mach-prima2/rstc.c
+++ b/arch/arm/mach-prima2/rstc.c
@@ -14,46 +14,24 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/reboot.h>
+#include <linux/reset-controller.h>
+
+#define SIRFSOC_RSTBIT_NUM	64
 
 void __iomem *sirfsoc_rstc_base;
 static DEFINE_MUTEX(rstc_lock);
 
-static struct of_device_id rstc_ids[]  = {
-	{ .compatible = "sirf,prima2-rstc" },
-	{ .compatible = "sirf,marco-rstc" },
-	{},
-};
-
-static int __init sirfsoc_of_rstc_init(void)
-{
-	struct device_node *np;
-
-	np = of_find_matching_node(NULL, rstc_ids);
-	if (!np) {
-		pr_err("unable to find compatible sirf rstc node in dtb\n");
-		return -ENOENT;
-	}
-
-	sirfsoc_rstc_base = of_iomap(np, 0);
-	if (!sirfsoc_rstc_base)
-		panic("unable to map rstc cpu registers\n");
-
-	of_node_put(np);
-
-	return 0;
-}
-early_initcall(sirfsoc_of_rstc_init);
-
-int sirfsoc_reset_device(struct device *dev)
+static int sirfsoc_reset_module(struct reset_controller_dev *rcdev,
+					unsigned long sw_reset_idx)
 {
-	u32 reset_bit;
+	u32 reset_bit = sw_reset_idx;
 
-	if (of_property_read_u32(dev->of_node, "reset-bit", &reset_bit))
+	if (reset_bit >= SIRFSOC_RSTBIT_NUM)
 		return -EINVAL;
 
 	mutex_lock(&rstc_lock);
 
-	if (of_device_is_compatible(dev->of_node, "sirf,prima2-rstc")) {
+	if (of_device_is_compatible(rcdev->of_node, "sirf,prima2-rstc")) {
 		/*
 		 * Writing 1 to this bit resets corresponding block. Writing 0 to this
 		 * bit de-asserts reset signal of the corresponding block.
@@ -83,6 +61,40 @@ int sirfsoc_reset_device(struct device *dev)
 	return 0;
 }
 
+static struct reset_control_ops sirfsoc_rstc_ops = {
+	.reset = sirfsoc_reset_module,
+};
+
+static struct reset_controller_dev sirfsoc_reset_controller = {
+	.ops = &sirfsoc_rstc_ops,
+	.nr_resets = SIRFSOC_RSTBIT_NUM,
+};
+
+static struct of_device_id rstc_ids[]  = {
+	{ .compatible = "sirf,prima2-rstc" },
+	{ .compatible = "sirf,marco-rstc" },
+	{},
+};
+
+void __init sirfsoc_of_rstc_init(void)
+{
+	struct device_node *np = of_find_matching_node(NULL, rstc_ids);
+	if (!np) {
+		pr_err("unable to find compatible sirf rstc node in dtb\n");
+		return;
+	}
+
+	sirfsoc_rstc_base = of_iomap(np, 0);
+	if (!sirfsoc_rstc_base) {
+		pr_err("unable to map rstc cpu registers\n");
+		return;
+	}
+
+	sirfsoc_reset_controller.of_node = np;
+
+	reset_controller_register(&sirfsoc_reset_controller);
+}
+
 #define SIRFSOC_SYS_RST_BIT  BIT(31)
 
 void sirfsoc_restart(enum reboot_mode mode, const char *cmd)
-- 
1.8.2.3



From thomas.petazzoni at free-electrons.com  Tue Jul 30 05:07:05 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 30 Jul 2013 11:07:05 +0200
Subject: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link'
 property
In-Reply-To: <CACxGe6td6uM0v5w92xPVCaVH4tP4AJ-h4SnN-mFoz5gSSosnQw@mail.gmail.com>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <CACxGe6td6uM0v5w92xPVCaVH4tP4AJ-h4SnN-mFoz5gSSosnQw@mail.gmail.com>
Message-ID: <20130730110705.3262bc3d@skate>

Dear Grant Likely,

On Tue, 23 Jul 2013 12:39:52 +0100, Grant Likely wrote:

> > +Such a fixed link situation is described within an Ethernet device
> > +Device Tree node using a 'fixed-link' property, composed of 5
> > +elements:
> > +
> > + 1. A fake PHY ID, which must be unique accross all fixed-link PHYs in
> > +    the system.
> 
> That's just loony!  :)  Regardless of existing code doing this, it is
> absolutely ridiculous to have it in the driver. The kernel should
> handle generating a phy id transparently. I'd rather mark this field
> as reserved in the binding and change the code to not care about it
> anymore.

In fact, this value is used for two things:

 * As the PHY address on the fake "fixed" MDIO bus.

 * As the PHY identifier, as reported by the MII registers PHYS_ID1
   (0x2) and PHYS_ID2 (0x3).

I think this doesn't make sense, because the two things are completely
unrelated. Ideally, we'd like the PHY identifier for fixed PHYs to be
something fixed, identical for all fixed PHYs. The problem is finding
an OUI and device number that is available for that, but maybe we can
ask the OpenMoko people to allocate one (see
http://wiki.openmoko.org/wiki/OUI).

Then, the PHY address could be generated dynamically. This would
require:

 * Adding a fixed_phy_create() function that internally uses
   fixed_phy_add(), but before that creates an unique PHY address for
   this newly created PHY. Those unique addresses will be generated by
   incrementing a global number of fixed PHYs, up to PHY_MAX_ADDR,
   which is the maximum number of fixed PHYs that can anyway be
   registered on the fixed MDIO bus.

   fixed_phy_create() would return this PHY address (positive) on
   success, or a negative error code on failure.

 * Change of_phy_register_fixed_link() to call fixed_phy_create()
   instead of fixed_phy_add() and make it return the PHY address
   allocated by fixed_phy_create().

 * Add a of_phy_connect_fixed_link_direct() that is similar to
   of_phy_connect_fixed_link() but takes an additional PHY address as
   argument and uses that to generate the 'bus_id' used to find the
   phy_device.

Grant, Mark, Florian, do you have other proposals?

Thanks,

Thomas Petazzoni
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From 21cnbao at gmail.com  Tue Jul 30 05:07:52 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Tue, 30 Jul 2013 17:07:52 +0800
Subject: [PATCH 1/2] arm: prima2: pm: enable rtc alarm0 and alarm1 as wakeup
 source
Message-ID: <1375175273-14067-1-git-send-email-Baohua.Song@csr.com>

From: Xianglong Du <Xianglong.Du at csr.com>

this patch also enables RTC alarm as wakeup source after system suspends

Signed-off-by: Xianglong Du <Xianglong.Du at csr.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 arch/arm/mach-prima2/pm.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-prima2/pm.c b/arch/arm/mach-prima2/pm.c
index 02cc3438..3a944ed 100644
--- a/arch/arm/mach-prima2/pm.c
+++ b/arch/arm/mach-prima2/pm.c
@@ -34,7 +34,10 @@ static void sirfsoc_set_wakeup_source(void)
 	pwr_trigger_en_reg = sirfsoc_rtc_iobrg_readl(sirfsoc_pwrc_base +
 		SIRFSOC_PWRC_TRIGGER_EN);
 #define X_ON_KEY_B (1 << 0)
-	sirfsoc_rtc_iobrg_writel(pwr_trigger_en_reg | X_ON_KEY_B,
+#define RTC_ALARM0_B (1 << 2)
+#define RTC_ALARM1_B (1 << 3)
+	sirfsoc_rtc_iobrg_writel(pwr_trigger_en_reg | X_ON_KEY_B |
+		RTC_ALARM0_B | RTC_ALARM1_B,
 		sirfsoc_pwrc_base + SIRFSOC_PWRC_TRIGGER_EN);
 }
 
-- 
1.8.2.3



From 21cnbao at gmail.com  Tue Jul 30 05:07:53 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Tue, 30 Jul 2013 17:07:53 +0800
Subject: [PATCH 2/2] arm: prima2: pm: drop redundant postcore_initcall
In-Reply-To: <1375175273-14067-1-git-send-email-Baohua.Song@csr.com>
References: <1375175273-14067-1-git-send-email-Baohua.Song@csr.com>
Message-ID: <1375175273-14067-2-git-send-email-Baohua.Song@csr.com>

This will delete some redundant calling of sirfsoc_of_pwrc_init() and
sirfsoc_memc_init() for non-CSR platforms if we use multi-platform.

Cc: Srinivas Kandagatla <srinivas.kandagatla at st.com>
Signed-off-by: Barry Song <Baohua.Song at csr.com>
---
 arch/arm/mach-prima2/pm.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-prima2/pm.c b/arch/arm/mach-prima2/pm.c
index 3a944ed..c4525a8 100644
--- a/arch/arm/mach-prima2/pm.c
+++ b/arch/arm/mach-prima2/pm.c
@@ -88,12 +88,6 @@ static const struct platform_suspend_ops sirfsoc_pm_ops = {
 	.valid = suspend_valid_only_mem,
 };
 
-int __init sirfsoc_pm_init(void)
-{
-	suspend_set_ops(&sirfsoc_pm_ops);
-	return 0;
-}
-
 static const struct of_device_id pwrc_ids[] = {
 	{ .compatible = "sirf,prima2-pwrc" },
 	{}
@@ -121,7 +115,6 @@ static int __init sirfsoc_of_pwrc_init(void)
 
 	return 0;
 }
-postcore_initcall(sirfsoc_of_pwrc_init);
 
 static const struct of_device_id memc_ids[] = {
 	{ .compatible = "sirf,prima2-memc" },
@@ -152,4 +145,11 @@ static int __init sirfsoc_memc_init(void)
 {
 	return platform_driver_register(&sirfsoc_memc_driver);
 }
-postcore_initcall(sirfsoc_memc_init);
+
+int __init sirfsoc_pm_init(void)
+{
+	sirfsoc_of_pwrc_init();
+	sirfsoc_memc_init();
+	suspend_set_ops(&sirfsoc_pm_ops);
+	return 0;
+}
-- 
1.8.2.3



From mark.rutland at arm.com  Tue Jul 30 05:08:32 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 30 Jul 2013 10:08:32 +0100
Subject: [PATCH v3] mmc: sdhci-moxart: Add MOXA ART SDHCI driver
In-Reply-To: <1375094974-7536-1-git-send-email-jonas.jensen@gmail.com>
References: <1374065502-27110-1-git-send-email-jonas.jensen@gmail.com>
 <1375094974-7536-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <20130730090832.GB28716@e106331-lin.cambridge.arm.com>

On Mon, Jul 29, 2013 at 11:49:34AM +0100, Jonas Jensen wrote:
> Add SDHCI driver for MOXA ART SoCs.
> 
> Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
> ---
> 
> Notes:
>     Changes since v2:
> 
>     1. #include <linux/bitops.h> because BIT() comes from there
>     2. reinsert dev_set_drvdata() in moxart_remove
>     3. remove MODULE_VERSION()
> 
>     device tree bindings document:
>     4. describe compatible variable "Must be" instead of "Should be".
>     5. change description so it's from the point of view of the device
> 
>     Applies to next-20130729
> 
>  .../devicetree/bindings/mmc/moxa,moxart-mmc.txt    |  17 +
>  drivers/mmc/host/Kconfig                           |   9 +
>  drivers/mmc/host/Makefile                          |   1 +
>  drivers/mmc/host/sdhci-moxart.c                    | 782 +++++++++++++++++++++
>  drivers/mmc/host/sdhci-moxart.h                    | 155 ++++
>  5 files changed, 964 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt
>  create mode 100644 drivers/mmc/host/sdhci-moxart.c
>  create mode 100644 drivers/mmc/host/sdhci-moxart.h
> 
> diff --git a/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt b/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt
> new file mode 100644
> index 0000000..67782ad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt
> @@ -0,0 +1,17 @@
> +MOXA ART SD Host Controller Interface
> +
> +Required properties:
> +
> +- compatible : Must be "moxa,moxart-mmc"
> +- reg : Should contain registers location and length
> +- interrupts : Should contain the interrupt number
> +- clocks : Should contain phandle for the clock feeding the SDHCI controller
> +
> +Example:
> +
> +       mmc: mmc at 98e00000 {
> +               compatible = "moxa,moxart-mmc";
> +               reg = <0x98e00000 0x5C>;
> +               interrupts = <5 0>;
> +               clocks = <&coreclk>;
> +       };

This binding looks sensible, but I'd appreciate someone who understands
MMCs checking that this captures the relevant information, as I don't
know much about MMCs.

Most mmc bindings I see have to describe some gpio pins, pinctrl to mux
the relevant pins on from the SoC, etc. Is this a full description of
the hardware supporting all features?

[...]

> +static int moxart_get_ro(struct mmc_host *mmc)
> +{
> +       int ret;
> +       struct moxart_host *host = mmc_priv(mmc);
> +
> +       (readl(&host->reg->status) & MSD_WRITE_PROT) ? (ret = 1) : (ret = 0);
> +       return ret;

This looks a little odd, how about something like:

return !!(readl(&host->reg->status) & SD_WRITE_PROT);

> +}
> +
> +static struct mmc_host_ops moxart_ops = {
> +       .request = moxart_request,
> +       .set_ios = moxart_set_ios,
> +       .get_ro = moxart_get_ro,
> +};
> +
> +static int moxart_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct device_node *node = dev->of_node;
> +       struct resource res_mmc;
> +       struct mmc_host *mmc;
> +       struct moxart_host *host = NULL;
> +       void __iomem *reg_mmc;
> +       dma_cap_mask_t mask;
> +       int ret;
> +       struct dma_slave_config cfg;
> +       unsigned int irq;
> +       struct clk *clk;
> +       unsigned int dma_chan_rx_req = 1;
> +       unsigned int dma_chan_tx_req = 0;
> +
> +       mmc = mmc_alloc_host(sizeof(struct moxart_host), dev);
> +       if (!mmc) {
> +               dev_err(dev, "%s: mmc_alloc_host failed\n", __func__);
> +               ret = -ENOMEM;
> +               goto out;
> +       }
> +
> +       ret = of_address_to_resource(node, 0, &res_mmc);
> +       if (ret) {
> +               dev_err(dev, "%s: could not get MMC base resource\n", __func__);
> +               goto out;
> +       }
> +
> +       irq = irq_of_parse_and_map(node, 0);
> +
> +       reg_mmc = devm_ioremap_resource(dev, &res_mmc);
> +       if (IS_ERR(reg_mmc)) {
> +               dev_err(dev, "%s: devm_ioremap_resource res_mmc failed\n",
> +                       __func__);
> +               return PTR_ERR(reg_mmc);
> +       }
> +
> +       mmc->ops = &moxart_ops;
> +
> +       /*
> +        * hardware does not support MMC_CAP_SD_HIGHSPEED
> +        * CMD6 will timeout and make things not work
> +        */
> +       mmc->caps = MMC_CAP_4_BIT_DATA;
> +
> +       mmc->f_min = 400000;
> +       mmc->f_max = 25000000;
> +       mmc->ocr_avail = 0xffff00;      /* support 2.0v - 3.6v power */
> +       mmc->max_segs = 32;
> +       mmc->max_blk_size = 512;
> +       mmc->max_blk_count = mmc->max_req_size / mmc->max_blk_size;
> +       mmc->max_seg_size = mmc->max_req_size;
> +
> +       host = mmc_priv(mmc);
> +       host->mmc = mmc;
> +       host->reg = (struct moxart_reg *)reg_mmc;
> +       host->reg_phys = res_mmc.start;
> +       host->timeout = msecs_to_jiffies(1000);
> +
> +       dma_cap_zero(mask);
> +       dma_cap_set(DMA_SLAVE, mask);
> +
> +       clk = of_clk_get(node, 0);
> +       if (IS_ERR(clk)) {
> +               dev_err(dev, "%s: of_clk_get failed\n", __func__);
> +               return PTR_ERR(clk);
> +       }
> +       host->sysclk = clk_get_rate(clk);
> +
> +       spin_lock_init(&host->lock);
> +
> +       /* disable all interrupt */
> +       writel(0, &host->reg->interrupt_mask);
> +
> +       /* reset chip */
> +       writel(MSD_SDC_RST, &host->reg->command);
> +
> +       /* wait for reset finished */
> +       while (readl(&host->reg->command) & MSD_SDC_RST)
> +               udelay(10);
> +
> +       host->dma_chan_tx = dma_request_channel(mask, moxart_filter_fn,
> +                                               (void *)&dma_chan_tx_req);
> +       host->dma_chan_rx = dma_request_channel(mask, moxart_filter_fn,
> +                                               (void *)&dma_chan_rx_req);
> +       dev_dbg(dev, "%s: using 2 DMA channels rx=%p tx=%p\n",
> +               __func__, host->dma_chan_rx, host->dma_chan_tx);
> +
> +       if (!host->dma_chan_rx || !host->dma_chan_tx) {
> +               host->have_dma = false;
> +               mmc->max_blk_count = 1;
> +       } else {
> +               cfg.slave_id = APB_DMA_SD_REQ_NO;
> +               cfg.direction = DMA_MEM_TO_DEV;
> +               cfg.src_addr = 0;
> +               cfg.dst_addr = (unsigned int)host->reg_phys + MSD_DATA_WIN_REG;
> +               cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> +               dmaengine_slave_config(host->dma_chan_tx, &cfg);
> +
> +               cfg.slave_id = APB_DMA_SD_REQ_NO;
> +               cfg.direction = DMA_DEV_TO_MEM;
> +               cfg.src_addr = (unsigned int)host->reg_phys + MSD_DATA_WIN_REG;
> +               cfg.dst_addr = 0;
> +               cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> +               dmaengine_slave_config(host->dma_chan_rx, &cfg);
> +
> +               host->have_dma = true;
> +
> +               /*
> +                * there seems to be a max size on transfers so
> +                * set max_blk_count low for both DMA and PIO
> +                *
> +                * sending large chunks result either in timeout
> +                * or render the MMC controller unresponsive
> +                * (status register 0 on consecutive read retries,
> +                * also see comments in moxart_send_command)
> +                *
> +                * obviously, DMA is quicker and can handle
> +                * larger chunks but setting it higher than 16
> +                * can still bug the controller
> +                */
> +               mmc->max_blk_count = 16;
> +       }
> +
> +       devm_request_irq(dev, irq, moxart_irq, 0, "moxart-mmc", host);
> +
> +       if (ret)
> +               goto out;

Presumably you meant to record the return code of devm_request_irq?

> +
> +       dev_set_drvdata(dev, mmc);
> +       mmc_add_host(mmc);
> +
> +       dev_dbg(dev, "%s: IRQ=%d\n", __func__, irq);
> +
> +       return 0;
> +
> +out:
> +       if (mmc)
> +               mmc_free_host(mmc);
> +       return ret;
> +}

[...]

> +struct moxart_reg {
> +
> +#define MSD_SDC_RST            BIT(10)
> +#define MSD_CMD_EN             BIT(9)
> +#define MSD_APP_CMD            BIT(8)
> +#define MSD_LONG_RSP           BIT(7)
> +#define MSD_NEED_RSP           BIT(6)
> +#define MSD_CMD_IDX_MASK       0x3f
> +       unsigned int    command;
> +
> +       unsigned int    argument;
> +       unsigned int    response0;
> +       unsigned int    response1;
> +       unsigned int    response2;
> +       unsigned int    response3;
> +
> +#define MSD_RSP_CMD_APP                BIT(6)
> +#define MSD_RSP_CMD_IDX_MASK   0x3f
> +       unsigned int    response_command;
> +
> +#define MSD_DATA_EN            BIT(6)
> +#define MSD_DMA_EN             BIT(5)
> +#define MSD_DATA_WRITE         BIT(4)
> +#define MSD_BLK_SIZE_MASK      0x0f
> +       unsigned int    data_control;
> +
> +       unsigned int    data_timer;
> +
> +#define MSD_DATA_LEN_MASK      0xffffff
> +       unsigned int    data_length;
> +
> +#define MSD_WRITE_PROT         BIT(12)
> +#define MSD_CARD_DETECT                BIT(11)
> +/* 1-10 below can be sent to interrupt or clear register */
> +#define MSD_CARD_CHANGE                BIT(10)
> +#define MSD_FIFO_ORUN          BIT(9)
> +#define MSD_FIFO_URUN          BIT(8)
> +#define MSD_DATA_END           BIT(7)
> +#define MSD_CMD_SENT           BIT(6)
> +#define MSD_DATA_CRC_OK                BIT(5)
> +#define MSD_RSP_CRC_OK         BIT(4)
> +#define MSD_DATA_TIMEOUT       BIT(3)
> +#define MSD_RSP_TIMEOUT                BIT(2)
> +#define MSD_DATA_CRC_FAIL      BIT(1)
> +#define MSD_RSP_CRC_FAIL       BIT(0)
> +       unsigned int    status;
> +
> +       unsigned int    clear;
> +       unsigned int    interrupt_mask;
> +
> +#define MSD_SD_POWER_ON                BIT(4)
> +#define MSD_SD_POWER_MASK      0x0f
> +       unsigned int    power_control;
> +
> +#define MSD_CLK_DIS            BIT(8)
> +#define MSD_CLK_SD             BIT(7)
> +#define MSD_CLK_DIV_MASK       0x7f
> +       unsigned int    clock_control;
> +
> +#define MSD_WIDE_BUS_SUPPORT   BIT(3)
> +#define MSD_WIDE_BUS           BIT(2)  /* bus width is 4 bytes */
> +#define MSD_SINGLE_BUS         BIT(0)  /* bus width is 1 byte */
> +       unsigned int    bus_width;
> +
> +       unsigned int    data_window;
> +
> +#define MSD_CPRM_FUNCTION      BIT(8)
> +       unsigned int    feature;
> +
> +       unsigned int    revision;
> +};

I see you're using this to handle your register offsets. This isn't
necessarily portable, as you're relying on the size of unsigned int
being 4 bytes, and that elements aren't padded to a larger size. At the
very least unsigned int should be replaced with u32.

Thanks,
Mark.


From horms+renesas at verge.net.au  Tue Jul 30 05:09:18 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 18:09:18 +0900
Subject: [PATCH v6 0/3] ARM: shmobile: lager: enable Ether
Message-ID: <1375175361-23027-1-git-send-email-horms+renesas@verge.net.au>

this short series enables the on-board ethernet
of the r8a7790 SoC for on lager board.

It has a run-time dependency on
"sh_eth: add support for r8a7790 SoC"

It has been built on top of renesas-next-20130726.

Changes noted in changelogs of individual patches.

Simon Horman (3):
  ARM: shmobile: r8a7790: clocks for Ether support
  ARM: shmobile: lager: enable Ether
  ARM: shmobile: lager: enable nfsroot in DTS

 arch/arm/boot/dts/r8a7790-lager.dts    |  2 +-
 arch/arm/mach-shmobile/board-lager.c   | 30 ++++++++++++++++++++++++++++++
 arch/arm/mach-shmobile/clock-r8a7790.c |  4 ++++
 3 files changed, 35 insertions(+), 1 deletion(-)

-- 
1.8.3.2



From horms+renesas at verge.net.au  Tue Jul 30 05:09:19 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 18:09:19 +0900
Subject: [PATCH v6 1/3] ARM: shmobile: r8a7790: clocks for Ether support
In-Reply-To: <1375175361-23027-1-git-send-email-horms+renesas@verge.net.au>
References: <1375175361-23027-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1375175361-23027-2-git-send-email-horms+renesas@verge.net.au>

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

v5
* Split out from "ARM: shmobile: r8a7790: add Ether support"
---
 arch/arm/mach-shmobile/clock-r8a7790.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c b/arch/arm/mach-shmobile/clock-r8a7790.c
index 50d96f9..fc36d3d 100644
--- a/arch/arm/mach-shmobile/clock-r8a7790.c
+++ b/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -51,6 +51,7 @@
 #define SMSTPCR3 0xe615013c
 #define SMSTPCR5 0xe6150144
 #define SMSTPCR7 0xe615014c
+#define SMSTPCR8 0xe6150990
 
 #define SDCKCR		0xE6150074
 #define SD2CKCR		0xE6150078
@@ -180,6 +181,7 @@ static struct clk div6_clks[DIV6_NR] = {
 
 /* MSTP */
 enum {
+	MSTP813,
 	MSTP721, MSTP720,
 	MSTP717, MSTP716,
 	MSTP522,
@@ -190,6 +192,7 @@ enum {
 };
 
 static struct clk mstp_clks[MSTP_NR] = {
+	[MSTP813] = SH_CLK_MSTP32(&p_clk, SMSTPCR8, 13, 0), /* Ether */
 	[MSTP721] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 21, 0), /* SCIF0 */
 	[MSTP720] = SH_CLK_MSTP32(&p_clk, SMSTPCR7, 20, 0), /* SCIF1 */
 	[MSTP717] = SH_CLK_MSTP32(&zs_clk, SMSTPCR7, 17, 0), /* HSCIF0 */
@@ -258,6 +261,7 @@ static struct clk_lookup lookups[] = {
 	CLKDEV_DEV_ID("sh-sci.7", &mstp_clks[MSTP720]),
 	CLKDEV_DEV_ID("sh-sci.8", &mstp_clks[MSTP717]),
 	CLKDEV_DEV_ID("sh-sci.9", &mstp_clks[MSTP716]),
+	CLKDEV_DEV_ID("r8a7790-ether", &mstp_clks[MSTP813]),
 	CLKDEV_DEV_ID("rcar_thermal", &mstp_clks[MSTP522]),
 	CLKDEV_DEV_ID("ee200000.mmcif", &mstp_clks[MSTP315]),
 	CLKDEV_DEV_ID("sh_mmcif.0", &mstp_clks[MSTP315]),
-- 
1.8.3.2



From horms+renesas at verge.net.au  Tue Jul 30 05:09:21 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 18:09:21 +0900
Subject: [PATCH v6 3/3] ARM: shmobile: lager: enable nfsroot in DTS
In-Reply-To: <1375175361-23027-1-git-send-email-horms+renesas@verge.net.au>
References: <1375175361-23027-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1375175361-23027-4-git-send-email-horms+renesas@verge.net.au>

Now that Ether support has been added to the lager board
it is possible to use nfsroot. This configuration is
in line with that of other shmobile boards.

Cc: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

This patch has a run-time dependency on "ARM: shmobile: lager: enable Ether"

v2
* Split out as a new patch from "ARM: shmobile: lager: enable Ether"
---
 arch/arm/boot/dts/r8a7790-lager.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 09a84fc..b2f61f0 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -16,7 +16,7 @@
 	compatible = "renesas,lager", "renesas,r8a7790";
 
 	chosen {
-		bootargs = "console=ttySC6,115200 ignore_loglevel";
+		bootargs = "console=ttySC6,115200 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096 rw";
 	};
 
 	memory at 40000000 {
-- 
1.8.3.2



From horms+renesas at verge.net.au  Tue Jul 30 05:09:20 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 30 Jul 2013 18:09:20 +0900
Subject: [PATCH v6 2/3] ARM: shmobile: lager: enable Ether
In-Reply-To: <1375175361-23027-1-git-send-email-horms+renesas@verge.net.au>
References: <1375175361-23027-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1375175361-23027-3-git-send-email-horms+renesas@verge.net.au>

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

This patch has a run-time dependency on "sh_eth: add support for r8a7790 SoC".

v6
* Correct first argument of PIN_MAP_MUX_GROUP_DEFAULT()
  to use "r8a7790-ether" instead of "sh-eth".
* Remove bogus "IRQ0" comment in ether_resources[]

v5
* As suggested by Laurent Pinchart
  - Do not use eth_magic pinmux group, that pin is not used on Lager
* As suggested by Morimoto-san and Magnus Damm
  - Refactor moving all setup code into boards-lager.c

v4
* Remove needs_gpio_reset and reset_gpio from ether_platdata
  as the patch that adds that feature and those fields has
  been dropped.
* Annotate ether_platdata as __initdata

v3
* Use newly added "r8a7790-ether" instead of "sh-eth"

v2
* Do not add MSTP812, EtherAVB. It is not used.
* As suggested by Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
  - Move Ethernet element of MSTP enum to a separate line
  - Move declaration of r8a7790_add_ether_device() to immediately
    after that of r8a7790_add_standard_devices()
  - Add __initdata annotation to ether_resource.
* As suggested by Laurent Pinchart
  - Do not manipilate sh_eth reset GPIO directly,
    rather, do so through newly proposed support for this in
    the sh_eth driver.
* A suggested by Sergei Shtylyov
  - Move DTS portion into a separate patch
---
 arch/arm/mach-shmobile/board-lager.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index 3c67b2a..ac4be4a 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -31,6 +31,7 @@
 #include <linux/platform_device.h>
 #include <linux/regulator/fixed.h>
 #include <linux/regulator/machine.h>
+#include <linux/sh_eth.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a7790.h>
@@ -91,6 +92,20 @@ static struct resource mmcif1_resources[] = {
 	DEFINE_RES_IRQ(gic_spi(170)),
 };
 
+/* Ether */
+static struct sh_eth_plat_data ether_pdata __initdata = {
+	.phy			= 0x1,
+	.edmac_endian		= EDMAC_LITTLE_ENDIAN,
+	.register_type		= SH_ETH_REG_FAST_RCAR,
+	.phy_interface		= PHY_INTERFACE_MODE_RMII,
+	.ether_link_active_low	= 1,
+};
+
+static struct resource ether_resources[] __initdata = {
+	DEFINE_RES_MEM(0xee700000, 0x400),
+	DEFINE_RES_IRQ(gic_spi(162)),
+};
+
 static const struct pinctrl_map lager_pinctrl_map[] = {
 	/* SCIF0 (CN19: DEBUG SERIAL0) */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.6", "pfc-r8a7790",
@@ -103,6 +118,15 @@ static const struct pinctrl_map lager_pinctrl_map[] = {
 				  "mmc1_data8", "mmc1"),
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.1", "pfc-r8a7790",
 				  "mmc1_ctrl", "mmc1"),
+	/* Ether */
+	PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-ether", "pfc-r8a7790",
+				  "eth_link", "eth"),
+	PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-ether", "pfc-r8a7790",
+				  "eth_mdio", "eth"),
+	PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-ether", "pfc-r8a7790",
+				  "eth_rmii", "eth"),
+	PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-ether", "pfc-r8a7790",
+				  "intc_irq0", "intc"),
 };
 
 static void __init lager_add_standard_devices(void)
@@ -114,6 +138,7 @@ static void __init lager_add_standard_devices(void)
 	r8a7790_pinmux_init();
 
 	r8a7790_add_standard_devices();
+
 	platform_device_register_data(&platform_bus, "leds-gpio", -1,
 				      &lager_leds_pdata,
 				      sizeof(lager_leds_pdata));
@@ -125,6 +150,11 @@ static void __init lager_add_standard_devices(void)
 	platform_device_register_resndata(&platform_bus, "sh_mmcif", 1,
 					  mmcif1_resources, ARRAY_SIZE(mmcif1_resources),
 					  &mmcif1_pdata, sizeof(mmcif1_pdata));
+
+	platform_device_register_resndata(&platform_bus, "r8a7790-ether", -1,
+					  ether_resources,
+					  ARRAY_SIZE(ether_resources),
+					  &ether_pdata, sizeof(ether_pdata));
 }
 
 static const char *lager_boards_compat_dt[] __initdata = {
-- 
1.8.3.2



From Dave.Martin at arm.com  Tue Jul 30 05:15:16 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Tue, 30 Jul 2013 10:15:16 +0100
Subject: [PATCH 01/13] ARM: suspend: use hash of cpu_logical_map value to
 index into save array
In-Reply-To: <alpine.LFD.2.03.1307292155040.15022@syhkavp.arg>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-2-git-send-email-nicolas.pitre@linaro.org>
 <20130729115016.GA6184@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307292155040.15022@syhkavp.arg>
Message-ID: <20130730091511.GA2478@localhost.localdomain>

On Mon, Jul 29, 2013 at 10:08:06PM -0400, Nicolas Pitre wrote:
> On Mon, 29 Jul 2013, Lorenzo Pieralisi wrote:
> 
> > On Tue, Jul 23, 2013 at 04:31:17AM +0100, Nicolas Pitre wrote:
> > > Currently we hash the MPIDR of the CPU being suspended to determine which
> > > entry in the sleep_save_sp array to use. In some situations, such as when
> > > we want to resume on another physical CPU, the MPIDR of another CPU should
> > > be used instead.
> > > 
> > > So let's use the value of cpu_logical_map(smp_processor_id()) in place
> > > of the MPIDR in the suspend path.  This will result in the same index
> > > being used as with the previous code unless the caller has modified
> > > cpu_logical_map() beforehand.
> > 
> > I will rely on your wisdom to rewrite the commit log in a way that
> > does not hint at dangerous creativity, if you catch my drift :D
> 
> I've augmented it with some of the earlier comments from Dave Martin.  
> I think it is fine to be clear in the commit log about what we intend 
> this change to be used for.
> 
> > > The register allocation in __cpu_suspend is reworked in order to better
> > > accommodate the additional argument.
> > > 
> > > Signed-off-by: Nicolas Pitre <nico at linaro.org>
> > > ---
> > >  arch/arm/kernel/sleep.S   | 25 +++++++++++--------------
> > >  arch/arm/kernel/suspend.c |  8 +++++---
> > >  2 files changed, 16 insertions(+), 17 deletions(-)
> > > 
> > > diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
> > > index db1536b8b3..836d10e698 100644
> > > --- a/arch/arm/kernel/sleep.S
> > > +++ b/arch/arm/kernel/sleep.S
> > > @@ -55,6 +55,7 @@
> > >   * specific registers and some other data for resume.
> > >   *  r0 = suspend function arg0
> > >   *  r1 = suspend function
> > > + *  r2 = MPIDR value used to index into sleep_save_sp
> > 
> > CPU's MPIDR or something like that, let's not hint at possible creative usage.
> 
> What about "MPIDR of the CPU to be resumed" which should normally just 
> be the current CPU's?
> 
> After all, creativity is not always a bad thing given it is reviewed 
> properly.

OK, sounds reasonable.

> 
> > >   */
> > >  ENTRY(__cpu_suspend)
> > >  	stmfd	sp!, {r4 - r11, lr}
> > > @@ -67,23 +68,19 @@ ENTRY(__cpu_suspend)
> > >  	mov	r5, sp			@ current virtual SP
> > >  	add	r4, r4, #12		@ Space for pgd, virt sp, phys resume fn
> > >  	sub	sp, sp, r4		@ allocate CPU state on stack
> > > -	stmfd	sp!, {r0, r1}		@ save suspend func arg and pointer
> > > -	add	r0, sp, #8		@ save pointer to save block
> > > -	mov	r1, r4			@ size of save block
> > > -	mov	r2, r5			@ virtual SP
> > >  	ldr	r3, =sleep_save_sp
> > > +	stmfd	sp!, {r0, r1}		@ save suspend func arg and pointer
> > >  	ldr	r3, [r3, #SLEEP_SAVE_SP_VIRT]
> > > -	ALT_SMP(mrc p15, 0, r9, c0, c0, 5)
> > > -        ALT_UP_B(1f)
> > > -	ldr	r8, =mpidr_hash
> > > -	/*
> > > -	 * This ldmia relies on the memory layout of the mpidr_hash
> > > -	 * struct mpidr_hash.
> > > -	 */
> > > -	ldmia	r8, {r4-r7}	@ r4 = mpidr mask (r5,r6,r7) = l[0,1,2] shifts
> > > -	compute_mpidr_hash	lr, r5, r6, r7, r9, r4
> > > -	add	r3, r3, lr, lsl #2
> > > +	ALT_SMP(ldr r0, =mpidr_hash)
> > > +       ALT_UP_B(1f)
> > 
> > Should be a tab, do not know if that's an email server issue or not.
> 
> Amistake on my part.
> 
> > > +	/* This ldmia relies on the memory layout of the mpidr_hash struct */
> > > +	ldmia	r0, {r1, r6-r8}	@ r1 = mpidr mask (r6,r7,r8) = l[0,1,2] shifts
> > > +	compute_mpidr_hash	r0, r6, r7, r8, r2, r1
> > > +	add	r3, r3, r0, lsl #2
> > >  1:
> > > +	mov	r2, r5			@ virtual SP
> > > +	mov	r1, r4			@ size of save block
> > > +	add	r0, sp, #8		@ pointer to save block
> > 
> > It is already a bit complex to follow, code is ok, but line above was
> > better placed closer to sp last change, not after hashing the MPIDR.
> 
> Well, I tend to disagree.  I think it is much clearer to set function 
> arguments closer to the call site so that r0 doesn't have to be live 
> with the stack location throughout this code.

Fair point, but I'm happy either way.

With or without, feel free to add

Reviewed-by: Dave Martin <Dave.Martin at arm.com>

Cheers
---Dave

> 
> > >  	bl	__cpu_suspend_save
> > >  	adr	lr, BSYM(cpu_suspend_abort)
> > >  	ldmfd	sp!, {r0, pc}		@ call suspend fn
> > > diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
> > > index 41cf3cbf75..2835d35234 100644
> > > --- a/arch/arm/kernel/suspend.c
> > > +++ b/arch/arm/kernel/suspend.c
> > > @@ -10,7 +10,7 @@
> > >  #include <asm/suspend.h>
> > >  #include <asm/tlbflush.h>
> > >  
> > > -extern int __cpu_suspend(unsigned long, int (*)(unsigned long));
> > > +extern int __cpu_suspend(unsigned long, int (*)(unsigned long), u32 cpuid);
> > >  extern void cpu_resume_mmu(void);
> > >  
> > >  #ifdef CONFIG_MMU
> > > @@ -21,6 +21,7 @@ extern void cpu_resume_mmu(void);
> > >  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> > >  {
> > >  	struct mm_struct *mm = current->active_mm;
> > > +	u32 __mpidr = cpu_logical_map(smp_processor_id());
> > >  	int ret;
> > >  
> > >  	if (!idmap_pgd)
> > > @@ -32,7 +33,7 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> > >  	 * resume (indicated by a zero return code), we need to switch
> > >  	 * back to the correct page tables.
> > >  	 */
> > > -	ret = __cpu_suspend(arg, fn);
> > > +	ret = __cpu_suspend(arg, fn, __mpidr);
> > >  	if (ret == 0) {
> > >  		cpu_switch_mm(mm->pgd, mm);
> > >  		local_flush_bp_all();
> > > @@ -44,7 +45,8 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> > >  #else
> > >  int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
> > >  {
> > > -	return __cpu_suspend(arg, fn);
> > > +	u32 __mpidr = cpu_logical_map(smp_processor_id());
> > > +	return __cpu_suspend(arg, fn, __mpidr);
> > >  }
> > >  #define	idmap_pgd	NULL
> > >  #endif
> > 
> > Apart from these nits, let's hope it is the last cpu_suspend bit we need to
> > change, please land it on -next asap, of course if Russell is ok with that.
> > 
> > I tested it on TC2.
> > 
> > FWIW:
> > 
> > Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> 
> Thanks.
> 
> 
> Nicolas


From thomas.petazzoni at free-electrons.com  Tue Jul 30 05:16:04 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 30 Jul 2013 11:16:04 +0200
Subject: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link'
 property
In-Reply-To: <20130723112259.GE4833@e106331-lin.cambridge.arm.com>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130723112259.GE4833@e106331-lin.cambridge.arm.com>
Message-ID: <20130730111604.76fd5b6e@skate>

Dear Mark Rutland,

On Tue, 23 Jul 2013 12:22:59 +0100, Mark Rutland wrote:

> > +Some Ethernet MACs have a "fixed link", and are not connected to a
> > +normal MDIO-managed PHY device. For those situations, a Device Tree
> > +binding allows to describe a "fixed link".
> 
> Are partictular MACs fixed link, or can some either be either fixed link
> or wired to an MDIO-managed PHY? i.e. can we assume a given MAC is
> fixed-link from its compatible string?

No, you can't. The case that I have is that the mvneta Ethernet MAC
(of Marvell 370/XP SOCs) is sometimes used with a MDIO-managed PHY, and
sometimes used with a switch that isn't manageable at all and should be
considered as a fixed link.

So no, the compatible string of the Ethernet MAC cannot be used to
determine whether we're wired fixed link or to a classical MDIO-managed
PHY.

> > +Such a fixed link situation is described within an Ethernet device
> > +Device Tree node using a 'fixed-link' property, composed of 5
> > +elements:
> 
> I'm not sure grouping these values together is the best way of handling
> this. It's rather opaque, and inflexible for future extension.

That's the DT binding that has been used by PowerPC platforms since
several years, and I've simply re-used it. See 'git grep fixed-link
arch/powerpc/boot/dts'.

I have nothing against creating another DT binding, but for a start, I
thought using existing bindings would be the best idea.

> > + 1. A fake PHY ID, which must be unique accross all fixed-link PHYs in
> > +    the system.
> 
> Is there any reason this couldn't be allocated dynamically within the
> kernel as needed? I don't see why an arbitrary unique value should be a
> dt binding requirement; it seems like a leak of Linux implementation
> details.

As I pointed out in my reply to Grant, this value is used both as the
PHY address on the fake fixed MDIO bus, and as the PHY identifier as
reported by MII registers PHYS_ID1 and PHYS_ID2. If we can get assigned
a proper PHY identifier that is used statically by the driver (it
doesn't have to be different per fixed PHY instance), then we can
allocate the PHY address dynamically. It requires a little bit of API
changes but that's certainly doable. See my reply to Grant for a
proposal about this.

> > + 2. The duplex (1 for full-duplex, 0 for half-duplex)
> 
> Will this change for a given MAC?
> 
> Could we not have a boolean property for each of these, and require one
> to be present?
> 
> Possibly fixed-link-full-duplex / fix-link-half-duplex?
> 
> > + 3. The speed (10, 100, 1000)
> 
> fixed-link-speed?
> 
> > + 4. The pause setting (1 for enabled, 0 for disabled)
> > + 5. The asym pause setting (1 for enabled, 0 for disabled)
> 
> Boolean properties for both of these?

As Florian already answered, he already proposed something like this in
the past, and it was rejected because a fixed PHY is not a piece of
hardware and should therefore not be represented in the Device Tree.
However, the fact that the MAC is not connected to a MDIO-manageable
PHY but to some fixed-link thing is a property of the MAC hardware
layout, and can therefore be expressed as a property of the MAC
hardware.

See the thread that starts at
http://article.gmane.org/gmane.linux.network/275771, and specifically
Grant answers to Florian suggestions of having DT nodes to represent
fixed PHY: http://article.gmane.org/gmane.linux.network/276208. Grant's
answer was:

"""
I think this discussion is going in the wrong direction. The concept
of a dummy phy is really a Linux kernel internal detail. Creating some
kind of dummy MDIO bus node does not describe the hardware. There is
already support in the kernel for Ethernet MACs connected directly to
a switch or other device. It is far better to describe how the MAC
needs to be configured than to invent a non-existent phy. Search for
"fixed-link" in the kernel tree to see how it is used.
"""

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From Dave.Martin at arm.com  Tue Jul 30 05:25:18 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Tue, 30 Jul 2013 10:25:18 +0100
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y
In-Reply-To: <20130729212140.GB12681@mozilla.com>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
 <20130715135420.GG10000@mudshark.cambridge.arm.com>
 <20130720044655.GC9433@mozilla.com>
 <20130721213753.GA29879@mudshark.cambridge.arm.com>
 <20130722185234.GA14519@localhost.localdomain>
 <20130729212140.GB12681@mozilla.com>
Message-ID: <20130730092517.GB2478@localhost.localdomain>

On Mon, Jul 29, 2013 at 02:21:40PM -0700, Jed Davis wrote:
> On Mon, Jul 22, 2013 at 07:52:39PM +0100, Dave Martin wrote:
> > On Sun, Jul 21, 2013 at 10:37:53PM +0100, Will Deacon wrote:
> > > Ok, I think I'm with you now. I also think that a better solution would be
> > > to try and limit the r7/fp confusion to one place, perhaps behind something
> > > like:
> > > 
> > > void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame);
> > > 
> > > then that function can act as the bridge between pt_regs (where we leave
> > > everything as it is) and stackframe (where we assign either r7 or fp into
> > > the fp member). Then we just fix up the call sites to pass the regs they're
> > > interested in to our new function.
> > > 
> > > What do you think?
> 
> I can see that being useful if we wanted to opacify struct stackframe,
> but... all uses of stackframe that I see involve passing it to
> unwind_frame, which expands it back out into an array of registers.
> (Except with CONFIG_FRAME_POINTER, but "APCS variants that require a
> frame pointer register are obsolete.")
> 
> So... why not make pt_regs and stackframe the same, and avoid the
> translations entirely?
> 
> > Do the ARM unwind tables guarantee not to need knowledge of any
> > virtual registers for the purpose of processing the opcodes of a single
> > function's unwind table entry, except those virtual regs that we happen
> > to initialise?  Or do we just rely on luck?
> 
> Yes, for some value of "luck".  The spec documents 0x90|N, for N a core
> register number other than 13 or 15, as setting the vSP to the value of
> virtual register N.  We can get away with some omissions for kernel code
> (e.g., unwind.c doesn't handle saved floating point registers, nor adding
> constants larger than 1024 to vSP), but is this one of them?

I think in practice yes.  After all, even requiring r7 is sufficiently
rare that it wasn't flagged up until now.  GCC seems to be quite rigid
in the way it generates stackframe management code.  There's no
guarantee that won't change in the future, of course.

> [...]
> > The purist answer seems to be: we might need all the regs in struct
> > stackframe.
> > 
> > The pragmatic answer might be that we definitely need r7 for Thumb code,
> > but given the nimbleness of GCC to evolve we might get away with not
> > including extra registers for a long time yet.
> 
> The other question to ask here might be: what does the "pragmatic
> answer" gain us over the "purist answer"?

The pragmatic route is less contraversial and lower overhead: even though
it's not correct as per the ABI, GCC is the only supported compiler for
building the kernel anyway.

Tracking the whole register set might actually be useful as a debugging
aid though, even if it's not needed for reliable backtraces.  It might
be worth considering that as a separate enhancement.

> 
> > A review of existing custom unwind annotations might be a good idea
> > anyway, to check whether any of them requires another register right now.
> 
> `egrep -r '\.(setf|movs)p' arch/arm` finds nothing, for what it's worth.

Good idea.  I suspected as much, since the number of custom annotations is
fairly small.  Thanks for checking.

Cheers
---Dave


From shawn.guo at linaro.org  Tue Jul 30 05:37:43 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Tue, 30 Jul 2013 17:37:43 +0800
Subject: [RFC 2/8] gpio: mxc: Support for initialization as submodule
In-Reply-To: <20130730083929.GI16871@s25.your-server.de>
References: <1374938808-27316-1-git-send-email-mpa@pengutronix.de>
 <1374938808-27316-3-git-send-email-mpa@pengutronix.de>
 <20130730034354.GF19715@S2101-09.ap.freescale.net>
 <20130730083929.GI16871@s25.your-server.de>
Message-ID: <20130730093741.GG12382@S2101-09.ap.freescale.net>

On Tue, Jul 30, 2013 at 10:39:29AM +0200, Markus Pargmann wrote:
> > > +	if (pdata) {
> > > +		port->base = pdata->base;
> > > +		iores = NULL;
> > 
> > Why is this needed?
> 
> The memory regions used for iomux control overlap the regions used by
> the gpio driver. So we need to share the memory with the pinctrl driver.

I meant for iores = NULL;

Shawn



From moinejf at free.fr  Tue Jul 30 05:38:53 2013
From: moinejf at free.fr (Jean-Francois Moine)
Date: Tue, 30 Jul 2013 11:38:53 +0200
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]
In-Reply-To: <20130730092517.GB2478@localhost.localdomain>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
 <20130715135420.GG10000@mudshark.cambridge.arm.com>
 <20130720044655.GC9433@mozilla.com>
 <20130721213753.GA29879@mudshark.cambridge.arm.com>
 <20130722185234.GA14519@localhost.localdomain>
 <20130729212140.GB12681@mozilla.com>
 <20130730092517.GB2478@localhost.localdomain>
Message-ID: <20130730113853.46cbb00a@armhf>

On Tue, 30 Jul 2013 10:25:18 +0100
Dave Martin <Dave.Martin at arm.com> wrote:

> The pragmatic route is less contraversial and lower overhead: even though
> it's not correct as per the ABI, GCC is the only supported compiler for
> building the kernel anyway.

BTW, kernels compiled with gcc-4.8 don't work.

Did anybody succeed with clang?

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/


From will.deacon at arm.com  Tue Jul 30 05:41:18 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 30 Jul 2013 10:41:18 +0100
Subject: [PATCH] arm: update advice on kernel and FDT load address.
In-Reply-To: <alpine.LFD.2.03.1307292234040.15022@syhkavp.arg>
References: <1375102578-5869-1-git-send-email-ian.campbell@citrix.com>
 <20130729135000.GK32383@mudshark.cambridge.arm.com>
 <1375106635.12741.8.camel@kazak.uk.xensource.com>
 <alpine.LFD.2.03.1307292234040.15022@syhkavp.arg>
Message-ID: <20130730094118.GF11527@mudshark.cambridge.arm.com>

On Tue, Jul 30, 2013 at 04:05:06AM +0100, Nicolas Pitre wrote:
> On Mon, 29 Jul 2013, Ian Campbell wrote:
> >	Note that the kernel uses 16KiB of RAM below
> >       the image to store page tables.  The recommended placement is
> >         32KiB into RAM.
> 
> Well... not completely right.
> 
> You may load zImage anywhere in the first 128MB of RAM if you have 
> CONFIG_AUTO_ZRELADDR=y.  If CONFIG_AUTO_ZRELADDR=n then zImage may be 
> loaded anywhere. In the former case, the zImage code will automatically 
> determine the physical start of RAM.  In the later case the start of RAM 
> is hardcoded in the zImage binary.
> 
> Then, the zImage code will decompress the actual kernel image at an 
> offset of (in most cases) 32KB from start of RAM.  However, if the 
> decompressed kernel would overwrite the loaded zImage where the 
> decompressor code and data is located, then zImage will relocate itself 
> just after the end of the decompressed kernel area before proceeding to 
> the decompression.  This is where you need to be careful about 
> ramdisk/initrd and DTB load addresses.
> 
> The initial page table is therefore (in most cases again) just below the 
> decompressed kernel location i.e. either Ffrom 16KB from start of RAM, 
> or from 12KB if using LPAE.
> 
> You can therefore load everything (zImage, initrd, DTB) sequentially 
> from the 32MB mark in RAM and be safe.  By loading zImage that high, it 
> most certainly won't need to relocate itself (unless the decompressed 
> kernel is larger than 32MB which is very unlikely as I mentioned) and 
> that will also make the boot process slightly faster.

Hmm, how does that work with CONFIG_INITRAMFS_SOURCE, where the initramfs
is built into the zImage? Would this impose a 32MB uncompressed limit on the
size of the kernel + initramfs?

Will


From 21cnbao at gmail.com  Tue Jul 30 05:44:34 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Tue, 30 Jul 2013 17:44:34 +0800
Subject: [PATCH v2] dmaengine: sirf: add PM entries for sleep and runtime
Message-ID: <1375177474-27583-1-git-send-email-Baohua.Song@csr.com>

this patch adds PM ops entries in sirf-dma drivers, so that this
driver can support suspend/resume, hibernation and runtime PM.

while suspending, sirf-dma will lose all registers, so we save
them at suspend and restore in resume for active channels.

Signed-off-by: Barry Song <Baohua.Song at csr.com>
Signed-off-by: Rongjun Ying <Rongjun.Ying at csr.com>
---
 -v2: add comments for PM state machine;
 don't always put dma to suspended after resuming from sleep as it
 depends on the runtime pm status;

 drivers/dma/sirf-dma.c | 132 +++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 129 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
index 716b23e..ff3cdd2 100644
--- a/drivers/dma/sirf-dma.c
+++ b/drivers/dma/sirf-dma.c
@@ -9,6 +9,7 @@
 #include <linux/module.h>
 #include <linux/dmaengine.h>
 #include <linux/dma-mapping.h>
+#include <linux/pm_runtime.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/slab.h>
@@ -73,6 +74,11 @@ struct sirfsoc_dma_chan {
 	int				mode;
 };
 
+struct sirfsoc_dma_regs {
+	u32				ctrl[SIRFSOC_DMA_CHANNELS];
+	u32				interrupt_en;
+};
+
 struct sirfsoc_dma {
 	struct dma_device		dma;
 	struct tasklet_struct		tasklet;
@@ -81,10 +87,13 @@ struct sirfsoc_dma {
 	int				irq;
 	struct clk			*clk;
 	bool				is_marco;
+	struct sirfsoc_dma_regs		regs_save;
 };
 
 #define DRV_NAME	"sirfsoc_dma"
 
+static int sirfsoc_dma_runtime_suspend(struct device *dev);
+
 /* Convert struct dma_chan to struct sirfsoc_dma_chan */
 static inline
 struct sirfsoc_dma_chan *dma_chan_to_sirfsoc_dma_chan(struct dma_chan *c)
@@ -393,6 +402,8 @@ static int sirfsoc_dma_alloc_chan_resources(struct dma_chan *chan)
 	LIST_HEAD(descs);
 	int i;
 
+	pm_runtime_get_sync(sdma->dma.dev);
+
 	/* Alloc descriptors for this channel */
 	for (i = 0; i < SIRFSOC_DMA_DESCRIPTORS; i++) {
 		sdesc = kzalloc(sizeof(*sdesc), GFP_KERNEL);
@@ -425,6 +436,7 @@ static int sirfsoc_dma_alloc_chan_resources(struct dma_chan *chan)
 static void sirfsoc_dma_free_chan_resources(struct dma_chan *chan)
 {
 	struct sirfsoc_dma_chan *schan = dma_chan_to_sirfsoc_dma_chan(chan);
+	struct sirfsoc_dma *sdma = dma_chan_to_sirfsoc_dma(chan);
 	struct sirfsoc_dma_desc *sdesc, *tmp;
 	unsigned long flags;
 	LIST_HEAD(descs);
@@ -445,6 +457,8 @@ static void sirfsoc_dma_free_chan_resources(struct dma_chan *chan)
 	/* Free descriptors */
 	list_for_each_entry_safe(sdesc, tmp, &descs, node)
 		kfree(sdesc);
+
+	pm_runtime_put(sdma->dma.dev);
 }
 
 /* Send pending descriptor to hardware */
@@ -723,14 +737,14 @@ static int sirfsoc_dma_probe(struct platform_device *op)
 
 	tasklet_init(&sdma->tasklet, sirfsoc_dma_tasklet, (unsigned long)sdma);
 
-	clk_prepare_enable(sdma->clk);
-
 	/* Register DMA engine */
 	dev_set_drvdata(dev, sdma);
+
 	ret = dma_async_device_register(dma);
 	if (ret)
 		goto free_irq;
 
+	pm_runtime_enable(&op->dev);
 	dev_info(dev, "initialized SIRFSOC DMAC driver\n");
 
 	return 0;
@@ -747,13 +761,124 @@ static int sirfsoc_dma_remove(struct platform_device *op)
 	struct device *dev = &op->dev;
 	struct sirfsoc_dma *sdma = dev_get_drvdata(dev);
 
-	clk_disable_unprepare(sdma->clk);
 	dma_async_device_unregister(&sdma->dma);
 	free_irq(sdma->irq, sdma);
 	irq_dispose_mapping(sdma->irq);
+	pm_runtime_disable(&op->dev);
+	if (!pm_runtime_status_suspended(&op->dev))
+		sirfsoc_dma_runtime_suspend(&op->dev);
+
+	return 0;
+}
+
+static int sirfsoc_dma_runtime_suspend(struct device *dev)
+{
+	struct sirfsoc_dma *sdma = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(sdma->clk);
+	return 0;
+}
+
+static int sirfsoc_dma_runtime_resume(struct device *dev)
+{
+	struct sirfsoc_dma *sdma = dev_get_drvdata(dev);
+	int ret;
+
+	ret = clk_prepare_enable(sdma->clk);
+	if (ret < 0) {
+		dev_err(dev, "clk_enable failed: %d\n", ret);
+		return ret;
+	}
+	return 0;
+}
+
+static int sirfsoc_dma_pm_suspend(struct device *dev)
+{
+	struct sirfsoc_dma *sdma = dev_get_drvdata(dev);
+	struct sirfsoc_dma_regs *save = &sdma->regs_save;
+	struct sirfsoc_dma_desc *sdesc;
+	struct sirfsoc_dma_chan *schan;
+	int ch;
+	int ret;
+
+	/*
+	 * if we were runtime-suspended before, resume to enable clock
+	 * before accessing register
+	 */
+	if (pm_runtime_status_suspended(dev)) {
+		ret = sirfsoc_dma_runtime_resume(dev);
+		if (ret < 0)
+			return ret;
+	}
+
+	/*
+	 * DMA controller will lose all registers while suspending
+	 * so we need to save registers for active channels
+	 */
+	for (ch = 0; ch < SIRFSOC_DMA_CHANNELS; ch++) {
+		schan = &sdma->channels[ch];
+		if (list_empty(&schan->active))
+			continue;
+		sdesc = list_first_entry(&schan->active,
+			struct sirfsoc_dma_desc,
+			node);
+		save->ctrl[ch] = readl_relaxed(sdma->base +
+			ch * 0x10 + SIRFSOC_DMA_CH_CTRL);
+	}
+	save->interrupt_en = readl_relaxed(sdma->base + SIRFSOC_DMA_INT_EN);
+
+	/* Disable clock */
+	sirfsoc_dma_runtime_suspend(dev);
+
+	return 0;
+}
+
+static int sirfsoc_dma_pm_resume(struct device *dev)
+{
+	struct sirfsoc_dma *sdma = dev_get_drvdata(dev);
+	struct sirfsoc_dma_regs *save = &sdma->regs_save;
+	struct sirfsoc_dma_desc *sdesc;
+	struct sirfsoc_dma_chan *schan;
+	int ch;
+	int ret;
+
+	/* Enable clock before accessing register */
+	ret = sirfsoc_dma_runtime_resume(dev);
+	if (ret < 0)
+		return ret;
+
+	writel_relaxed(save->interrupt_en, sdma->base + SIRFSOC_DMA_INT_EN);
+	for (ch = 0; ch < SIRFSOC_DMA_CHANNELS; ch++) {
+		schan = &sdma->channels[ch];
+		if (list_empty(&schan->active))
+			continue;
+		sdesc = list_first_entry(&schan->active,
+			struct sirfsoc_dma_desc,
+			node);
+		writel_relaxed(sdesc->width,
+			sdma->base + SIRFSOC_DMA_WIDTH_0 + ch * 4);
+		writel_relaxed(sdesc->xlen,
+			sdma->base + ch * 0x10 + SIRFSOC_DMA_CH_XLEN);
+		writel_relaxed(sdesc->ylen,
+			sdma->base + ch * 0x10 + SIRFSOC_DMA_CH_YLEN);
+		writel_relaxed(save->ctrl[ch],
+			sdma->base + ch * 0x10 + SIRFSOC_DMA_CH_CTRL);
+		writel_relaxed(sdesc->addr >> 2,
+			sdma->base + ch * 0x10 + SIRFSOC_DMA_CH_ADDR);
+	}
+
+	/* if we were runtime-suspended before, suspend again */
+	if (pm_runtime_status_suspended(dev))
+		sirfsoc_dma_runtime_suspend(dev);
+
 	return 0;
 }
 
+static const struct dev_pm_ops sirfsoc_dma_pm_ops = {
+	SET_RUNTIME_PM_OPS(sirfsoc_dma_runtime_suspend, sirfsoc_dma_runtime_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(sirfsoc_dma_pm_suspend, sirfsoc_dma_pm_resume)
+};
+
 static struct of_device_id sirfsoc_dma_match[] = {
 	{ .compatible = "sirf,prima2-dmac", },
 	{ .compatible = "sirf,marco-dmac", },
@@ -766,6 +891,7 @@ static struct platform_driver sirfsoc_dma_driver = {
 	.driver = {
 		.name = DRV_NAME,
 		.owner = THIS_MODULE,
+		.pm = &sirfsoc_dma_pm_ops,
 		.of_match_table	= sirfsoc_dma_match,
 	},
 };
-- 
1.8.2.3



From Dave.Martin at arm.com  Tue Jul 30 05:44:57 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Tue, 30 Jul 2013 10:44:57 +0100
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]
In-Reply-To: <20130730113853.46cbb00a@armhf>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
 <20130715135420.GG10000@mudshark.cambridge.arm.com>
 <20130720044655.GC9433@mozilla.com>
 <20130721213753.GA29879@mudshark.cambridge.arm.com>
 <20130722185234.GA14519@localhost.localdomain>
 <20130729212140.GB12681@mozilla.com>
 <20130730092517.GB2478@localhost.localdomain>
 <20130730113853.46cbb00a@armhf>
Message-ID: <20130730094457.GC2478@localhost.localdomain>

On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
> On Tue, 30 Jul 2013 10:25:18 +0100
> Dave Martin <Dave.Martin at arm.com> wrote:
> 
> > The pragmatic route is less contraversial and lower overhead: even though
> > it's not correct as per the ABI, GCC is the only supported compiler for
> > building the kernel anyway.
> 
> BTW, kernels compiled with gcc-4.8 don't work.

I haven't tried 4.8 yet.  Do you know what the problem is?

> Did anybody succeed with clang?

Hmm, I've no idea.  Is this possible?

Cheers
---Dave

> 
> -- 
> Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
> Jef		|		http://moinejf.free.fr/
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From josephl at nvidia.com  Tue Jul 30 05:46:08 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 30 Jul 2013 17:46:08 +0800
Subject: [PATCH V2] ARM: dts: tegra114: dalmore: fix the irq trigger
 type of Palmas MFD device
In-Reply-To: <51F292D4.9030208@wwwdotorg.org>
References: <1374663272-9937-1-git-send-email-josephl@nvidia.com>
 <51F292D4.9030208@wwwdotorg.org>
Message-ID: <1375177568.1239.16.camel@jlo-ubuntu-64.nvidia.com>

On Fri, 2013-07-26 at 23:16 +0800, Stephen Warren wrote:
> On 07/24/2013 04:54 AM, Joseph Lo wrote:
> > The IRQ trigger type of Palmas MFD device (tps65913) is edge trigger. The
> > wrong configuration would cause an interrupt storm when booting the
> > system. Fixing it in DT with appropriate interrupt type.
> 
> > diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
> 
> >  		palmas: tps65913 {
> >  			compatible = "ti,palmas";
> >  			reg = <0x58>;
> > -			interrupts = <0 86 0x4>;
> > +			interrupts = <0 86 0x0>;
> 
> The legal values for that final cell are:
> 
>     - bits[3:0] trigger type and level flags
>         1 = low-to-high edge triggered
>         2 = high-to-low edge triggered
>         4 = active high level-sensitive
>         8 = active low level-sensitive
> 
> 0 isn't one of those values. This patch can't be correct.
> 
> BTW, this cell should use the constants from
> <dt-bindings/interrupt-controller/irq.h>.

Oops. I made a wrong description in the commit message.

Update my test result again.

> 1 = low-to-high edge triggered
No IRQ storm, but the system always auto wake up by Palmas RTC.
> 2 = high-to-low edge triggered
No IRQ storm, but the GIC didn't support this trigger type. The flag
would be re-configured as 0x0.
> 4 = active high level-sensitive
There is a IRQ storm when system booting.
> 8 = active low level-sensitive
No IRQ strom, but the GIC didn't support this trigger type. The flag
would be re-configured as 0x0.

> nvidia, invert-interrupt
Removing this can fix IRQ storm too, but the system always auto wake up
by Palmas RTC.

So we can only three trigger type here.
IRQ_TYPE_NONE 0
IRQ_TYPE_EDGE_FALLING 2
IRQ_TYPE_LEVEL_LOW 8

But using IRQ_TYPE_EDGE_FALLING or IRQ_TYPE_LEVEL_LOW, it would
configure to IRQ_TYPE_NONE. Because the PMIC is low level trigger to PMC
on Dalmore, I would prefer to use IRQ_TYPE_LEVEL_LOW just like the v1.
Any comments?

Thanks,
Joseph



From mark.rutland at arm.com  Tue Jul 30 05:49:20 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 30 Jul 2013 10:49:20 +0100
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <51F6CE23.30306@gmail.com>
Message-ID: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>

On Mon, Jul 29, 2013 at 09:18:43PM +0100, Rob Herring wrote:
> On 07/29/2013 05:13 AM, Mark Rutland wrote:
> > Hi Rob,
> > 
> > On Sun, Jul 28, 2013 at 10:56:32PM +0100, Rob Herring wrote:
> >> From: Rob Herring <rob.herring at calxeda.com>
> >>
> >> The PSCI spec from ARM has been updated to 0.2 version. Update the
> >> binding document to reflect the spec changes. For the binding, the
> >> major changes are addition of system reset and poweroff functions.
> >> The recommended function id numbering has also changed.
> >>
> >> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> >> Cc: devicetree at vger.kernel.org
> >> ---
> >>  Documentation/devicetree/bindings/arm/psci.txt | 25 +++++++++++++++++++------
> >>  1 file changed, 19 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
> >> index 433afe9..b8b4d9f 100644
> >> --- a/Documentation/devicetree/bindings/arm/psci.txt
> >> +++ b/Documentation/devicetree/bindings/arm/psci.txt
> >> @@ -21,7 +21,7 @@ to #0.
> >>  
> >>  Main node required properties:
> >>  
> >> - - compatible    : Must be "arm,psci"
> >> + - compatible    : Must be "arm,psci-0.2" or "arm,psci"
> > 
> > For the purposes of handling different firmware implementations (which
> > may have different bugs to work around and may require different
> > arguments to cpu_suspend), it may be better to state "must contain"
> > rather than "must be". 
> > 
> >>  
> >>   - method        : The method of calling the PSCI firmware. Permitted
> >>                     values are:
> >> @@ -32,6 +32,9 @@ Main node required properties:
> >>                     "hvc" : HVC #0, with the register assignments specified
> >>  		           in this binding.
> >>  
> >> + - psci_version  : Function ID for PSCI_VERSION operation. Required for
> >> +                   "arm,psci-0.2" compatible version or later.
> >> +
> >>  Main node optional properties:
> >>  
> >>   - cpu_suspend   : Function ID for CPU_SUSPEND operation
> > 
> > The low bits of CPU_SUSPEND's power_state argument are platform specific
> > and we'll need to deal with them if an implementation actually uses them
> > for something. We can probably associate this with a specific
> > implementation's compatible string, as we'll almost certainly need
> > special code to handle the differences between them.
> 
> I'm not a fan of

Me neither. The only alternative I can think of would rely on platform
information from elsewhere to let you know how to call cpu_suspend,
(e.g. a board's compatible string).

As far as I can see, without some knowledge of the platform you can't
use CPU_SUSPEND safely.

> 
> > If we have a compatible string for the first platform that ignores the
> > argument (or just uses zero), that can be shared by all those
> > implementations that don't give any fine-grained control here.
> > 
> >> @@ -42,14 +45,24 @@ Main node optional properties:
> >>  
> >>   - migrate       : Function ID for MIGRATE operation
> >>  
> >> + - system_reset  : Function ID for SYSTEM_RESET operation
> >> +
> >> + - system_off    : Function ID for SYSTEM_OFF operation
> >> +
> >>  
> >>  Example:
> >>  
> >>  	psci {
> >> -		compatible	= "arm,psci";
> >> +		compatible	= "arm,psci-0.2";
> >>  		method		= "smc";
> >> -		cpu_suspend	= <0x95c10000>;
> >> -		cpu_off		= <0x95c10001>;
> >> -		cpu_on		= <0x95c10002>;
> >> -		migrate		= <0x95c10003>;
> >> +		psci_version	= <0x84000000>;
> >> +		cpu_suspend	= <0x84000001>;
> >> +		cpu_off		= <0x84000002>;
> >> +		cpu_on		= <0x84000003>;
> >> +		affinity_info	= <0x84000004>; 
> >> +		migrate		= <0x84000005>;
> >> +		migrate_info_type = <0x84000006>; 
> >> +		migrate_info_up_cpu = <0x84000007>; 
> >> +		system_off	= <0x84000008>; 
> >> +		system_reset	= <0x84000009>; 
> >>  	};
> > 
> > One of the things changed in PSCI 0.2 was the SMC calling convention,
> > though this isn't clear in the PSCI document. The function IDs for 32bit
> > and 64bit callers may differ, and we need to support describing an
> > arbitrary configuration of the two (same ID for both, different across
> > 32-bit/64-bit, only supported for 64-bit, only supported for 32-bit).
> > 
> > I'd like to ensure the binding can deal with that from the start. We
> > could do this by having -32 and -64 variants of each function id (e.g.
> > cpu_off-64) , if the IDs actually differ, and use the regular combined
> > ID if they don't.
> 
> Uggg. I guess I should have read the SMC calling convention doc... I was
> simply documenting what is already in the PSCI doc, but obviously that
> is not fully flushed out.
> 
> How about something like this (for the complicated case of both 32 and
> 64 bit):
> 
> 	method		= "smc", "smc64";
> 	psci_version	= <0x84000000 0xc4000000>;
> 	cpu_suspend	= <0x84000001 0xc4000001>;
> 	cpu_off		= <0x84000002 0xc4000002>;
> 	cpu_on		= <0x84000003 0xc4000003>;
> 
> "smc" is a synonym for smc32 for compatibility. The number and order of
> methods determines the number and order of function IDs.

While this may be compatible with the arm implementation, it won't be
compatible with the arm64 implementation, which assumes smc64 by
default.

As far as I am aware, the implementations currently in use (KVM and Xen)
use the same ID for both, so I think "smc" should cover an ID valid for
a native register width calling convention, and "smc64" and "smc32"
describing values only valid for 64-bit wide and 32-bit wide calling
conventions respectively.

I've added Christoffer, Marc, and Stefano to Cc in case they have any
comments.

> 
> A variation on this would be keep method as is and add a "#psci-cells"
> property to specify the number of function IDs. You can determine the
> 64-bit vs. 32-bit support based on the function ID itself.

I don't think that's a good idea - part of the reasoning for specifying
the IDs is to cater for those not aligned with the ID guidelines in the
spec, so we can't assume their choice of ID value gives us any useful
information as to how they may be used.

Thanks,
Mark.


From josephl at nvidia.com  Tue Jul 30 05:49:15 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Tue, 30 Jul 2013 17:49:15 +0800
Subject: [PATCH 0/8] ARM: tegra: support LP1 suspend mode
In-Reply-To: <2389689.JgQlW00RdN@ax5200p>
References: <1374830110-30685-1-git-send-email-josephl@nvidia.com>
 <2389689.JgQlW00RdN@ax5200p>
Message-ID: <1375177755.1239.19.camel@jlo-ubuntu-64.nvidia.com>

On Sun, 2013-07-28 at 00:12 +0800, Marc Dietrich wrote:
> On Friday 26 July 2013 17:15:02 Joseph Lo wrote:
> > This series adds the support of LP1 suspend mode for Tegra.
> > 
> > Verified on Seaboard, Cardhu and Dalmore.
> 
> tested on AC100 and worked fine, except
> 
[unbalanced wake_enable/disable of rtc-6586x]
> 
> and sdcard being offline after resume (fixed by CONFIG_MMC_UNSAFE_RESUME=y). 
> Anyway, thanks for your great work!
> 
> Tested-By: Marc Dietrich <marvin24 at gmx.de>
> 

Marc,

Thanks for your testing.



From will.deacon at arm.com  Tue Jul 30 05:49:04 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 30 Jul 2013 10:49:04 +0100
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]
In-Reply-To: <20130730113853.46cbb00a@armhf>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
 <20130715135420.GG10000@mudshark.cambridge.arm.com>
 <20130720044655.GC9433@mozilla.com>
 <20130721213753.GA29879@mudshark.cambridge.arm.com>
 <20130722185234.GA14519@localhost.localdomain>
 <20130729212140.GB12681@mozilla.com>
 <20130730092517.GB2478@localhost.localdomain>
 <20130730113853.46cbb00a@armhf>
Message-ID: <20130730094904.GH11527@mudshark.cambridge.arm.com>

On Tue, Jul 30, 2013 at 10:38:53AM +0100, Jean-Francois Moine wrote:
> BTW, kernels compiled with gcc-4.8 don't work.

Erm. Can you elaborate please? There was an issue where SLUB would get
miscompiled with 4.8 due to some per-cpu variable reordering across
barrier(), but I fixed that for ARM in 3.10.

... or are you referring specifically to the unwinder?

Will


From richard.genoud at gmail.com  Tue Jul 30 05:59:44 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 11:59:44 +0200
Subject: [PATCH v6 0/8] Sound support for at91sam9x5-wm8731 based boards
Message-ID: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>

Hi,

This patchset add sound on the at91sam9x5ek board.
It's based on Nicolas Ferre's work in the 2.6.39 atmel patch for sam9x5:
https://github.com/linux4sam/linux-at91/commit/0aa157c9e71ccccf3abc30fa37eb5c95b392978d

It needs Bo Chen's patchset on the generic dmaengine (topic/atmel branch
on Mark's sound tree) and the SSC interrupts disabled (cf
http://www.spinics.net/lists/arm-kernel/msg256901.html)

As the at91 chips are on their way to the common clock framework, I thought
it may be better to retrieve the codec MCLK via this framework.
So it needs Boris Brezillon patch set "ARM: at91: move to common clk framework"
I've separated this patch because I don't know what is better:
 * applying the patchset with a hard coded clock, and once at91 has moved to common
clock framework, update the code and change the DT binding.
 * wait for the common clock framework.

Outstanding issue:
If this machine driver will support more SoCs maybe we should name it differently.
Maybe atmel_wm8731.c ? Since it could be merged with sam9g20_wm8731.c
when the g20 is DT only (There will be some more work though).

It has been tested on at91sam9g35ek, and should work on g15, g25, x25 and x35 also.

patches applies on next-20130729 + "ARM: at91: move to common clk framework"

Changes from v5:
 * Update the wm8731 DT binding documentation with available audio endpoints.
 * Remove Uwe's signed-off since it seems to be "an integration signed-off"
 * Remove rate constrains if freq==0 in wm8731.
 * Allocate dynamically card, dai and private structures.
 * Add a separate patch to set the oscillator value via DT.
NB: this last patch needs Boris Brezillon patch set "ARM: at91: move to common clk framework"


Changes from v4:
 * Move the rates constraints into the codec
 * Hard code the DAI format since it cannot be changed anyway (and
remove the DT bindings accordingly)
 * Add some consistency in the functions naming (sam9x5ek/at91sam9x5ek/sam9x5)
 * Retrieve the SSC id from the SSC controller phandle
 * Clarify the atmel-ssc.txt documentation
 * Develop audio-routing documentation
 * Tidy up the includes in the machine driver

Changes from v3:
 * Remove the use of macros in device tree documentation.

Changes from v2:
 * Change atmel,sam9x5-audio-wm8731 to atmel,sam9x5-wm8731-audio for
consistency with sam9g20 machine driver.
 * Use the snd_pcm_hw_constraint() API as suggested by Mark and Lars-Peter.
 * Remove the unnecessary snd_soc_dapm_sync() call as Lars-Peter suggested.
 * Add documentation for machine driver DT binding.
 * Update atmel-ssc DT binding documentation.
 * Add GPL license instead of just the "GPL" word (hope that's ok !)

Changes from v1-RFC:
 * drop patches on SSC since Bo Chen already did the work
 * reorder patches to have the machine driver first
 * drop code already handled by the ASoC framework
 * drop unneeded SND_ATMEL_SOC_PDC config selection
 * use static snd_soc_card and snd_soc_dai_link structures.

Best regards,
Richard.

Nicolas Ferre (1):
  ASoC: atmel: machine driver for at91sam9x5-wm8731 boards

Richard Genoud (7):
  ASoC: wm8731: add rates constraints
  Documentation: DT: update atmel SSC with DMA binding
  ARM: AT91: DTS: sam9x5: add SSC DMA parameters
  ARM: AT91: DTS: sam9x5ek: add WM8731 codec
  ARM: AT91: DTS: sam9x5ek: enable SSC
  ARM: AT91: DTS: sam9x5ek: add sound configuration
  ASoC: sam9x5: get codec MCLK via device tree

 .../devicetree/bindings/misc/atmel-ssc.txt         |   23 ++-
 .../bindings/sound/atmel-sam9x5-wm8731-audio.txt   |   39 ++++
 Documentation/devicetree/bindings/sound/wm8731.txt |    9 +
 arch/arm/boot/dts/at91sam9x5.dtsi                  |    3 +
 arch/arm/boot/dts/at91sam9x5ek.dtsi                |   32 +++
 sound/soc/atmel/Kconfig                            |   10 +
 sound/soc/atmel/Makefile                           |    2 +
 sound/soc/atmel/sam9x5_wm8731.c                    |  218 ++++++++++++++++++++
 sound/soc/codecs/wm8731.c                          |   60 +++++-
 9 files changed, 392 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
 create mode 100644 sound/soc/atmel/sam9x5_wm8731.c

-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 05:59:47 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 11:59:47 +0200
Subject: [PATCH v6 3/8] Documentation: DT: update atmel SSC with DMA binding
In-Reply-To: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
References: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375178392-26060-4-git-send-email-richard.genoud@gmail.com>

As atmel-ssc can be used with DMA, the documentation should be updated.
Also, a configuration DMA example is given.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 .../devicetree/bindings/misc/atmel-ssc.txt         |   23 +++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
index 38e51ad..a45ae08 100644
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -7,9 +7,30 @@ Required properties:
 - reg: Should contain SSC registers location and length
 - interrupts: Should contain SSC interrupt
 
-Example:
+
+Required properties for devices compatible with "atmel,at91sam9g45-ssc":
+- dmas: DMA specifier, consisting of a phandle to DMA controller node,
+  the memory interface and SSC DMA channel ID (for tx and rx).
+  See Documentation/devicetree/bindings/dma/atmel-dma.txt for details.
+- dma-names: Must be "tx", "rx".
+
+Examples:
+- PDC transfer:
 ssc0: ssc at fffbc000 {
 	compatible = "atmel,at91rm9200-ssc";
 	reg = <0xfffbc000 0x4000>;
 	interrupts = <14 4 5>;
 };
+
+- DMA transfer:
+ssc0: ssc at f0010000 {
+      compatible = "atmel,at91sam9g45-ssc";
+      reg = <0xf0010000 0x4000>;
+      interrupts = <28 4 5>;
+      dmas = <&dma0 1 13>,
+	     <&dma0 1 14>;
+      dma-names = "tx", "rx";
+      pinctrl-names = "default";
+      pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+      status = "disabled";
+};
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 05:59:45 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 11:59:45 +0200
Subject: [PATCH v6 1/8] ASoC: wm8731: add rates constraints
In-Reply-To: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
References: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375178392-26060-2-git-send-email-richard.genoud@gmail.com>

Depending on the mclk (or crystal) selected, the wm8731 codec have some
constraints on its data sampling rates:
e.g. with a 12.288MHz or 18.432MHz crystal, the authorized rates are
8KHz, 32KHz, 48KHz and 96KHz.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 sound/soc/codecs/wm8731.c |   60 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 57 insertions(+), 3 deletions(-)

diff --git a/sound/soc/codecs/wm8731.c b/sound/soc/codecs/wm8731.c
index 5276062..456bb8c 100644
--- a/sound/soc/codecs/wm8731.c
+++ b/sound/soc/codecs/wm8731.c
@@ -45,6 +45,7 @@ static const char *wm8731_supply_names[WM8731_NUM_SUPPLIES] = {
 struct wm8731_priv {
 	struct regmap *regmap;
 	struct regulator_bulk_data supplies[WM8731_NUM_SUPPLIES];
+	const struct snd_pcm_hw_constraint_list *constraints;
 	unsigned int sysclk;
 	int sysclk_type;
 	int playback_fs;
@@ -290,6 +291,36 @@ static const struct _coeff_div coeff_div[] = {
 	{12000000, 88200, 136, 0xf, 0x1, 0x1},
 };
 
+/* rates constraints */
+static const unsigned int wm8731_rates_12000000[] = {
+	8000, 32000, 44100, 48000, 96000, 88200,
+};
+
+static const unsigned int wm8731_rates_12288000_18432000[] = {
+	8000, 32000, 48000, 96000,
+};
+
+static const unsigned int wm8731_rates_11289600_16934400[] = {
+	8000, 44100, 88200,
+};
+
+static const struct snd_pcm_hw_constraint_list wm8731_constraints_12000000 = {
+	.list = wm8731_rates_12000000,
+	.count = ARRAY_SIZE(wm8731_rates_12000000),
+};
+
+static const
+struct snd_pcm_hw_constraint_list wm8731_constraints_12288000_18432000 = {
+	.list = wm8731_rates_12288000_18432000,
+	.count = ARRAY_SIZE(wm8731_rates_12288000_18432000),
+};
+
+static const
+struct snd_pcm_hw_constraint_list wm8731_constraints_11289600_16934400 = {
+	.list = wm8731_rates_11289600_16934400,
+	.count = ARRAY_SIZE(wm8731_rates_11289600_16934400),
+};
+
 static inline int get_coeff(int mclk, int rate)
 {
 	int i;
@@ -362,17 +393,26 @@ static int wm8731_set_dai_sysclk(struct snd_soc_dai *codec_dai,
 	}
 
 	switch (freq) {
-	case 11289600:
+	case 0:
+		wm8731->constraints = NULL;
+		break;
 	case 12000000:
+		wm8731->constraints = &wm8731_constraints_12000000;
+		break;
 	case 12288000:
-	case 16934400:
 	case 18432000:
-		wm8731->sysclk = freq;
+		wm8731->constraints = &wm8731_constraints_12288000_18432000;
+		break;
+	case 16934400:
+	case 11289600:
+		wm8731->constraints = &wm8731_constraints_11289600_16934400;
 		break;
 	default:
 		return -EINVAL;
 	}
 
+	wm8731->sysclk = freq;
+
 	snd_soc_dapm_sync(&codec->dapm);
 
 	return 0;
@@ -475,12 +515,26 @@ static int wm8731_set_bias_level(struct snd_soc_codec *codec,
 	return 0;
 }
 
+static int wm8731_startup(struct snd_pcm_substream *substream,
+	struct snd_soc_dai *dai)
+{
+	struct wm8731_priv *wm8731 = snd_soc_codec_get_drvdata(dai->codec);
+
+	if (wm8731->constraints)
+		snd_pcm_hw_constraint_list(substream->runtime, 0,
+					   SNDRV_PCM_HW_PARAM_RATE,
+					   wm8731->constraints);
+
+	return 0;
+}
+
 #define WM8731_RATES SNDRV_PCM_RATE_8000_96000
 
 #define WM8731_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S20_3LE |\
 	SNDRV_PCM_FMTBIT_S24_LE)
 
 static const struct snd_soc_dai_ops wm8731_dai_ops = {
+	.startup	= wm8731_startup,
 	.hw_params	= wm8731_hw_params,
 	.digital_mute	= wm8731_mute,
 	.set_sysclk	= wm8731_set_dai_sysclk,
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 05:59:46 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 11:59:46 +0200
Subject: [PATCH v6 2/8] ASoC: atmel: machine driver for at91sam9x5-wm8731
 boards
In-Reply-To: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
References: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375178392-26060-3-git-send-email-richard.genoud@gmail.com>

From: Nicolas Ferre <nicolas.ferre at atmel.com>

Description of the Asoc machine driver for an at91sam9x5 based board
with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
master on the SSC/I2S interface. Its connections are a headphone jack
and an Line input jack.

[Richard: this is based on an old patch from Nicolas that I forward
ported and reworked to use only device tree]

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 .../bindings/sound/atmel-sam9x5-wm8731-audio.txt   |   35 ++++
 Documentation/devicetree/bindings/sound/wm8731.txt |    9 +
 sound/soc/atmel/Kconfig                            |   10 +
 sound/soc/atmel/Makefile                           |    2 +
 sound/soc/atmel/sam9x5_wm8731.c                    |  208 ++++++++++++++++++++
 5 files changed, 264 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
 create mode 100644 sound/soc/atmel/sam9x5_wm8731.c

diff --git a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
new file mode 100644
index 0000000..0720857
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
@@ -0,0 +1,35 @@
+* Atmel at91sam9x5ek wm8731 audio complex
+
+Required properties:
+  - compatible: "atmel,sam9x5-wm8731-audio"
+  - atmel,model: The user-visible name of this sound complex.
+  - atmel,ssc-controller: The phandle of the SSC controller
+  - atmel,audio-codec: The phandle of the WM8731 audio codec
+  - atmel,audio-routing: A list of the connections between audio components.
+    Each entry is a pair of strings, the first being the connection's sink,
+    the second being the connection's source.
+
+Available audio endpoints for the audio-routing table:
+
+Board connectors:
+ * Headphone Jack
+ * Line In Jack
+
+wm8731 pins:
+cf Documentation/devicetree/bindings/sound/wm8731.txt
+
+Example:
+sound {
+	compatible = "atmel,sam9x5-wm8731-audio";
+
+	atmel,model = "wm8731 @ AT91SAM9X5EK";
+
+	atmel,audio-routing =
+		"Headphone Jack", "RHPOUT",
+		"Headphone Jack", "LHPOUT",
+		"LLINEIN", "Line In Jack",
+		"RLINEIN", "Line In Jack";
+
+	atmel,ssc-controller = <&ssc0>;
+	atmel,audio-codec = <&wm8731>;
+};
diff --git a/Documentation/devicetree/bindings/sound/wm8731.txt b/Documentation/devicetree/bindings/sound/wm8731.txt
index 15f7004..236690e 100644
--- a/Documentation/devicetree/bindings/sound/wm8731.txt
+++ b/Documentation/devicetree/bindings/sound/wm8731.txt
@@ -16,3 +16,12 @@ codec: wm8731 at 1a {
 	compatible = "wlf,wm8731";
 	reg = <0x1a>;
 };
+
+Available audio endpoints for an audio-routing table:
+ * LOUT: Left Channel Line Output
+ * ROUT: Right Channel Line Output
+ * LHPOUT: Left Channel Headphone Output
+ * RHPOUT: Right Channel Headphone Output
+ * LLINEIN: Left Channel Line Input
+ * RLINEIN: Right Channel Line Input
+ * MICIN: Microphone Input
diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 986323b..e48d38a 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -43,6 +43,16 @@ config SND_ATMEL_SOC_WM8904
 	  Say Y if you want to add support for Atmel ASoC driver for boards using
 	  WM8904 codec.
 
+config SND_AT91_SOC_SAM9X5_WM8731
+	tristate "SoC Audio support for WM8731-based at91sam9x5 board"
+	depends on ATMEL_SSC && SND_ATMEL_SOC && SOC_AT91SAM9X5
+	select SND_ATMEL_SOC_SSC
+	select SND_ATMEL_SOC_DMA
+	select SND_SOC_WM8731
+	help
+	  Say Y if you want to add support for audio SoC on an
+	  at91sam9x5 based board that is using WM8731 codec.
+
 config SND_AT91_SOC_AFEB9260
 	tristate "SoC Audio support for AFEB9260 board"
 	depends on ARCH_AT91 && ATMEL_SSC && ARCH_AT91 && MACH_AFEB9260 && SND_ATMEL_SOC
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index 922d4da..5baabc8 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -12,7 +12,9 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
 # AT91 Machine Support
 snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
 snd-atmel-soc-wm8904-objs := atmel_wm8904.o
+snd-soc-sam9x5-wm8731-objs := sam9x5_wm8731.o
 
 obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
 obj-$(CONFIG_SND_ATMEL_SOC_WM8904) += snd-atmel-soc-wm8904.o
+obj-$(CONFIG_SND_AT91_SOC_SAM9X5_WM8731) += snd-soc-sam9x5-wm8731.o
 obj-$(CONFIG_SND_AT91_SOC_AFEB9260) += snd-soc-afeb9260.o
diff --git a/sound/soc/atmel/sam9x5_wm8731.c b/sound/soc/atmel/sam9x5_wm8731.c
new file mode 100644
index 0000000..992ae38
--- /dev/null
+++ b/sound/soc/atmel/sam9x5_wm8731.c
@@ -0,0 +1,208 @@
+/*
+ * sam9x5_wm8731   --	SoC audio for AT91SAM9X5-based boards
+ *			that are using WM8731 as codec.
+ *
+ *  Copyright (C) 2011 Atmel,
+ *		  Nicolas Ferre <nicolas.ferre at atmel.com>
+ *
+ *  Copyright (C) 2013 Paratronic,
+ *		  Richard Genoud <richard.genoud at gmail.com>
+ *
+ * Based on sam9g20_wm8731.c by:
+ * Sedji Gaouaou <sedji.gaouaou at atmel.com>
+ *
+ *  This program is free software; you can redistribute  it and/or modify it
+ *  under  the terms of  the GNU General  Public License as published by the
+ *  Free Software Foundation;  either version 2 of the  License, or (at your
+ *  option) any later version.
+ *
+ */
+#include <linux/of.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/platform_device.h>
+#include <linux/device.h>
+
+#include <sound/soc.h>
+#include <sound/soc-dai.h>
+#include <sound/soc-dapm.h>
+
+#include "../codecs/wm8731.h"
+#include "atmel_ssc_dai.h"
+
+
+#define MCLK_RATE 12288000
+
+#define DRV_NAME "sam9x5-snd-wm8731"
+
+struct sam9x5_drvdata {
+	int ssc_id;
+};
+
+/*
+ * Logic for a wm8731 as connected on a at91sam9x5ek based board.
+ */
+static int sam9x5_wm8731_init(struct snd_soc_pcm_runtime *rtd)
+{
+	struct snd_soc_dai *codec_dai = rtd->codec_dai;
+	struct device *dev = rtd->dev;
+	int ret;
+
+	dev_dbg(dev, "ASoC: %s called\n", __func__);
+
+	/* set the codec system clock for DAC and ADC */
+	ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
+				     MCLK_RATE, SND_SOC_CLOCK_IN);
+	if (ret < 0) {
+		dev_err(dev, "ASoC: Failed to set WM8731 SYSCLK: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+/*
+ * Audio paths on at91sam9x5ek board:
+ *
+ *  |A| ------------> |      | ---R----> Headphone Jack
+ *  |T| <----\        |  WM  | ---L--/
+ *  |9| ---> CLK <--> | 8731 | <--R----- Line In Jack
+ *  |1| <------------ |      | <--L--/
+ */
+static const struct snd_soc_dapm_widget sam9x5_dapm_widgets[] = {
+	SND_SOC_DAPM_HP("Headphone Jack", NULL),
+	SND_SOC_DAPM_LINE("Line In Jack", NULL),
+};
+
+static int sam9x5_wm8731_driver_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *codec_np, *cpu_np;
+	struct snd_soc_card *card;
+	struct snd_soc_dai_link *dai;
+	struct sam9x5_drvdata *priv;
+	int ret;
+
+	if (!np) {
+		dev_err(&pdev->dev, "No device node supplied\n");
+		return -EINVAL;
+	}
+
+	card = devm_kzalloc(&pdev->dev, sizeof(*card), GFP_KERNEL);
+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+	dai = devm_kzalloc(&pdev->dev, sizeof(*dai), GFP_KERNEL);
+	if (!dai || !card || !priv) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	card->dev = &pdev->dev;
+	card->owner = THIS_MODULE;
+	card->dai_link = dai;
+	card->num_links = 1;
+	card->dapm_widgets = sam9x5_dapm_widgets;
+	card->num_dapm_widgets = ARRAY_SIZE(sam9x5_dapm_widgets);
+	dai->name = "WM8731";
+	dai->stream_name = "WM8731 PCM";
+	dai->codec_dai_name = "wm8731-hifi";
+	dai->init = sam9x5_wm8731_init;
+	dai->dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
+		| SND_SOC_DAIFMT_CBM_CFM;
+
+	ret = snd_soc_of_parse_card_name(card, "atmel,model");
+	if (ret) {
+		dev_err(&pdev->dev, "atmel,model node missing\n");
+		goto out;
+	}
+
+	ret = snd_soc_of_parse_audio_routing(card, "atmel,audio-routing");
+	if (ret) {
+		dev_err(&pdev->dev, "atmel,audio-routing node missing\n");
+		goto out;
+	}
+
+	codec_np = of_parse_phandle(np, "atmel,audio-codec", 0);
+	if (!codec_np) {
+		dev_err(&pdev->dev, "atmel,audio-codec node missing\n");
+		ret = -EINVAL;
+		goto out;
+	}
+
+	dai->codec_of_node = codec_np;
+
+	cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
+	if (!cpu_np) {
+		dev_err(&pdev->dev, "atmel,ssc-controller node missing\n");
+		ret = -EINVAL;
+		goto out;
+	}
+	dai->cpu_of_node = cpu_np;
+	dai->platform_of_node = cpu_np;
+
+	priv->ssc_id = of_alias_get_id(cpu_np, "ssc");
+
+	ret = atmel_ssc_set_audio(priv->ssc_id);
+	if (ret != 0) {
+		dev_err(&pdev->dev,
+			"ASoC: Failed to set SSC %d for audio: %d\n",
+			ret, priv->ssc_id);
+		goto out;
+	}
+
+	of_node_put(codec_np);
+	of_node_put(cpu_np);
+
+	platform_set_drvdata(pdev, card);
+
+	ret = snd_soc_register_card(card);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"ASoC: Platform device allocation failed\n");
+		goto out_put_audio;
+	}
+
+	dev_dbg(&pdev->dev, "ASoC: %s ok\n", __func__);
+
+	return ret;
+
+out_put_audio:
+	atmel_ssc_put_audio(priv->ssc_id);
+out:
+	return ret;
+}
+
+static int sam9x5_wm8731_driver_remove(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = platform_get_drvdata(pdev);
+	struct sam9x5_drvdata *priv = card->drvdata;
+
+	snd_soc_unregister_card(card);
+	atmel_ssc_put_audio(priv->ssc_id);
+
+	return 0;
+}
+
+static const struct of_device_id sam9x5_wm8731_of_match[] = {
+	{ .compatible = "atmel,sam9x5-wm8731-audio", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sam9x5_wm8731_of_match);
+
+static struct platform_driver sam9x5_wm8731_driver = {
+	.driver = {
+		.name = DRV_NAME,
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(sam9x5_wm8731_of_match),
+	},
+	.probe = sam9x5_wm8731_driver_probe,
+	.remove = sam9x5_wm8731_driver_remove,
+};
+module_platform_driver(sam9x5_wm8731_driver);
+
+/* Module information */
+MODULE_AUTHOR("Nicolas Ferre <nicolas.ferre at atmel.com>");
+MODULE_AUTHOR("Richard Genoud <richard.genoud at gmail.com>");
+MODULE_DESCRIPTION("ALSA SoC machine driver for AT91SAM9x5 - WM8731");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:" DRV_NAME);
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 05:59:48 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 11:59:48 +0200
Subject: [PATCH v6 4/8] ARM: AT91: DTS: sam9x5: add SSC DMA parameters
In-Reply-To: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
References: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375178392-26060-5-git-send-email-richard.genoud@gmail.com>

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5.dtsi |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 20b6423..d6c9895 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -716,6 +716,9 @@
 				compatible = "atmel,at91sam9g45-ssc";
 				reg = <0xf0010000 0x4000>;
 				interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
+				dmas = <&dma0 1 AT91_DMA_CFG_PER_ID(13)>,
+				       <&dma0 1 AT91_DMA_CFG_PER_ID(14)>;
+				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
 				clocks = <&periph 28>;
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 05:59:51 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 11:59:51 +0200
Subject: [PATCH v6 7/8] ARM: AT91: DTS: sam9x5ek: add sound configuration
In-Reply-To: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
References: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375178392-26060-8-git-send-email-richard.genoud@gmail.com>

The sam9x5ek board has 2 jacks:
headphone wired on RHPOUT/LHPOUT of the wm8731
line in wired on LLINEIN/RLINEIN of the wm8731

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index f3e83f7..9afe15b 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -113,4 +113,19 @@
 			status = "okay";
 		};
 	};
+
+	sound {
+		compatible = "atmel,sam9x5-wm8731-audio";
+
+		atmel,model = "wm8731 @ AT91SAM9X5EK";
+
+		atmel,audio-routing =
+			"Headphone Jack", "RHPOUT",
+			"Headphone Jack", "LHPOUT",
+			"LLINEIN", "Line In Jack",
+			"RLINEIN", "Line In Jack";
+
+		atmel,ssc-controller = <&ssc0>;
+		atmel,audio-codec = <&wm8731>;
+	};
 };
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 05:59:49 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 11:59:49 +0200
Subject: [PATCH v6 5/8] ARM: AT91: DTS: sam9x5ek: add WM8731 codec
In-Reply-To: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
References: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375178392-26060-6-git-send-email-richard.genoud@gmail.com>

The WM8731 codec on sam9x5ek board is on i2c, address 1A

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
Acked-by: Mark Brown <broonie at linaro.org>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index d107241..e6fb309 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -59,6 +59,11 @@
 
 			i2c0: i2c at f8010000 {
 				status = "okay";
+
+				wm8731: wm8731 at 1a {
+					compatible = "wm8731";
+					reg = <0x1a>;
+				};
 			};
 
 			pinctrl at fffff400 {
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 05:59:50 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 11:59:50 +0200
Subject: [PATCH v6 6/8] ARM: AT91: DTS: sam9x5ek: enable SSC
In-Reply-To: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
References: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375178392-26060-7-git-send-email-richard.genoud@gmail.com>

Enable the SSC needed for the WM8731 codec

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index e6fb309..f3e83f7 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -95,6 +95,10 @@
 			watchdog at fffffe40 {
 				status = "okay";
 			};
+
+			ssc0: ssc at f0010000 {
+				status = "okay";
+			};
 		};
 
 		usb0: ohci at 00600000 {
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 05:59:52 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 11:59:52 +0200
Subject: [PATCH v6 8/8] ASoC: sam9x5: get codec MCLK via device tree
In-Reply-To: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
References: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375178392-26060-9-git-send-email-richard.genoud@gmail.com>

Instead of having the clock rate hard coded, and thus, only compatible
with one board, we can make it compatible with other implementations.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 .../bindings/sound/atmel-sam9x5-wm8731-audio.txt     |    4 ++++
 arch/arm/boot/dts/at91sam9x5ek.dtsi                  |    8 ++++++++
 sound/soc/atmel/sam9x5_wm8731.c                      |   18 ++++++++++++++----
 3 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
index 0720857..114a4c5 100644
--- a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
+++ b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
@@ -8,6 +8,8 @@ Required properties:
   - atmel,audio-routing: A list of the connections between audio components.
     Each entry is a pair of strings, the first being the connection's sink,
     the second being the connection's source.
+  - clocks: Must contain an entry for the codec master clock.
+  - clock-names : Must be "mclk" (clock that feeds the codec master clock)
 
 Available audio endpoints for the audio-routing table:
 
@@ -32,4 +34,6 @@ sound {
 
 	atmel,ssc-controller = <&ssc0>;
 	atmel,audio-codec = <&wm8731>;
+	clocks = <&sound_crystal 0>;
+	clock-names = "mclk";
 };
diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index 9afe15b..b5ff17c 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -114,6 +114,12 @@
 		};
 	};
 
+	sound_crystal: osc at 0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency  = <12288000>;
+	};
+
 	sound {
 		compatible = "atmel,sam9x5-wm8731-audio";
 
@@ -127,5 +133,7 @@
 
 		atmel,ssc-controller = <&ssc0>;
 		atmel,audio-codec = <&wm8731>;
+		clocks = <&sound_crystal 0>;
+		clock-names = "mclk";
 	};
 };
diff --git a/sound/soc/atmel/sam9x5_wm8731.c b/sound/soc/atmel/sam9x5_wm8731.c
index 992ae38..f33c181 100644
--- a/sound/soc/atmel/sam9x5_wm8731.c
+++ b/sound/soc/atmel/sam9x5_wm8731.c
@@ -23,6 +23,8 @@
 #include <linux/mod_devicetable.h>
 #include <linux/platform_device.h>
 #include <linux/device.h>
+#include <linux/err.h>
+#include <linux/clk.h>
 
 #include <sound/soc.h>
 #include <sound/soc-dai.h>
@@ -31,12 +33,10 @@
 #include "../codecs/wm8731.h"
 #include "atmel_ssc_dai.h"
 
-
-#define MCLK_RATE 12288000
-
 #define DRV_NAME "sam9x5-snd-wm8731"
 
 struct sam9x5_drvdata {
+	struct clk *mclk;
 	int ssc_id;
 };
 
@@ -46,6 +46,7 @@ struct sam9x5_drvdata {
 static int sam9x5_wm8731_init(struct snd_soc_pcm_runtime *rtd)
 {
 	struct snd_soc_dai *codec_dai = rtd->codec_dai;
+	struct sam9x5_drvdata *priv = snd_soc_card_get_drvdata(rtd->card);
 	struct device *dev = rtd->dev;
 	int ret;
 
@@ -53,7 +54,8 @@ static int sam9x5_wm8731_init(struct snd_soc_pcm_runtime *rtd)
 
 	/* set the codec system clock for DAC and ADC */
 	ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
-				     MCLK_RATE, SND_SOC_CLOCK_IN);
+				     clk_get_rate(priv->mclk),
+				     SND_SOC_CLOCK_IN);
 	if (ret < 0) {
 		dev_err(dev, "ASoC: Failed to set WM8731 SYSCLK: %d\n", ret);
 		return ret;
@@ -142,6 +144,13 @@ static int sam9x5_wm8731_driver_probe(struct platform_device *pdev)
 
 	priv->ssc_id = of_alias_get_id(cpu_np, "ssc");
 
+	priv->mclk = devm_clk_get(&pdev->dev, "mclk");
+	if (IS_ERR(priv->mclk)) {
+		ret = PTR_ERR(priv->mclk);
+		dev_err(&pdev->dev, "Failed to get MCLK: %d\n", ret);
+		goto out;
+	}
+
 	ret = atmel_ssc_set_audio(priv->ssc_id);
 	if (ret != 0) {
 		dev_err(&pdev->dev,
@@ -153,6 +162,7 @@ static int sam9x5_wm8731_driver_probe(struct platform_device *pdev)
 	of_node_put(codec_np);
 	of_node_put(cpu_np);
 
+	snd_soc_card_set_drvdata(card, priv);
 	platform_set_drvdata(pdev, card);
 
 	ret = snd_soc_register_card(card);
-- 
1.7.10.4



From Dave.Martin at arm.com  Tue Jul 30 06:01:11 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Tue, 30 Jul 2013 11:01:11 +0100
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <51F6CE23.30306@gmail.com>
References: <1375048598-15637-1-git-send-email-robherring2@gmail.com>
 <1375048598-15637-2-git-send-email-robherring2@gmail.com>
 <20130729101302.GJ3528@e106331-lin.cambridge.arm.com>
 <51F6CE23.30306@gmail.com>
Message-ID: <20130730100111.GD2478@localhost.localdomain>

On Mon, Jul 29, 2013 at 03:18:43PM -0500, Rob Herring wrote:
> On 07/29/2013 05:13 AM, Mark Rutland wrote:
> > Hi Rob,
> > 
> > On Sun, Jul 28, 2013 at 10:56:32PM +0100, Rob Herring wrote:
> >> From: Rob Herring <rob.herring at calxeda.com>
> >>
> >> The PSCI spec from ARM has been updated to 0.2 version. Update the
> >> binding document to reflect the spec changes. For the binding, the
> >> major changes are addition of system reset and poweroff functions.
> >> The recommended function id numbering has also changed.
> >>
> >> Signed-off-by: Rob Herring <rob.herring at calxeda.com>
> >> Cc: devicetree at vger.kernel.org
> >> ---
> >>  Documentation/devicetree/bindings/arm/psci.txt | 25 +++++++++++++++++++------
> >>  1 file changed, 19 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
> >> index 433afe9..b8b4d9f 100644
> >> --- a/Documentation/devicetree/bindings/arm/psci.txt
> >> +++ b/Documentation/devicetree/bindings/arm/psci.txt
> >> @@ -21,7 +21,7 @@ to #0.
> >>  
> >>  Main node required properties:
> >>  
> >> - - compatible    : Must be "arm,psci"
> >> + - compatible    : Must be "arm,psci-0.2" or "arm,psci"
> > 
> > For the purposes of handling different firmware implementations (which
> > may have different bugs to work around and may require different
> > arguments to cpu_suspend), it may be better to state "must contain"
> > rather than "must be". 
> > 
> >>  
> >>   - method        : The method of calling the PSCI firmware. Permitted
> >>                     values are:
> >> @@ -32,6 +32,9 @@ Main node required properties:
> >>                     "hvc" : HVC #0, with the register assignments specified
> >>  		           in this binding.
> >>  
> >> + - psci_version  : Function ID for PSCI_VERSION operation. Required for
> >> +                   "arm,psci-0.2" compatible version or later.
> >> +
> >>  Main node optional properties:
> >>  
> >>   - cpu_suspend   : Function ID for CPU_SUSPEND operation
> > 
> > The low bits of CPU_SUSPEND's power_state argument are platform specific
> > and we'll need to deal with them if an implementation actually uses them
> > for something. We can probably associate this with a specific
> > implementation's compatible string, as we'll almost certainly need
> > special code to handle the differences between them.
> 
> I'm not a fan of

...what?

> 
> > If we have a compatible string for the first platform that ignores the
> > argument (or just uses zero), that can be shared by all those
> > implementations that don't give any fine-grained control here.
> > 
> >> @@ -42,14 +45,24 @@ Main node optional properties:
> >>  
> >>   - migrate       : Function ID for MIGRATE operation
> >>  
> >> + - system_reset  : Function ID for SYSTEM_RESET operation
> >> +
> >> + - system_off    : Function ID for SYSTEM_OFF operation
> >> +
> >>  
> >>  Example:
> >>  
> >>  	psci {
> >> -		compatible	= "arm,psci";
> >> +		compatible	= "arm,psci-0.2";
> >>  		method		= "smc";
> >> -		cpu_suspend	= <0x95c10000>;
> >> -		cpu_off		= <0x95c10001>;
> >> -		cpu_on		= <0x95c10002>;
> >> -		migrate		= <0x95c10003>;
> >> +		psci_version	= <0x84000000>;
> >> +		cpu_suspend	= <0x84000001>;
> >> +		cpu_off		= <0x84000002>;
> >> +		cpu_on		= <0x84000003>;
> >> +		affinity_info	= <0x84000004>; 
> >> +		migrate		= <0x84000005>;
> >> +		migrate_info_type = <0x84000006>; 
> >> +		migrate_info_up_cpu = <0x84000007>; 
> >> +		system_off	= <0x84000008>; 
> >> +		system_reset	= <0x84000009>; 
> >>  	};
> > 
> > One of the things changed in PSCI 0.2 was the SMC calling convention,
> > though this isn't clear in the PSCI document. The function IDs for 32bit
> > and 64bit callers may differ, and we need to support describing an
> > arbitrary configuration of the two (same ID for both, different across
> > 32-bit/64-bit, only supported for 64-bit, only supported for 32-bit).
> > 
> > I'd like to ensure the binding can deal with that from the start. We
> > could do this by having -32 and -64 variants of each function id (e.g.
> > cpu_off-64) , if the IDs actually differ, and use the regular combined
> > ID if they don't.
> 
> Uggg. I guess I should have read the SMC calling convention doc... I was
> simply documenting what is already in the PSCI doc, but obviously that
> is not fully flushed out.
> 
> How about something like this (for the complicated case of both 32 and
> 64 bit):
> 
> 	method		= "smc", "smc64";
> 	psci_version	= <0x84000000 0xc4000000>;
> 	cpu_suspend	= <0x84000001 0xc4000001>;
> 	cpu_off		= <0x84000002 0xc4000002>;
> 	cpu_on		= <0x84000003 0xc4000003>;
> 
> "smc" is a synonym for smc32 for compatibility. The number and order of
> methods determines the number and order of function IDs.
> 
> A variation on this would be keep method as is and add a "#psci-cells"
> property to specify the number of function IDs. You can determine the
> 64-bit vs. 32-bit support based on the function ID itself.

Just to point out, these arguments all apply equally to hvc.  So, if
there is an "smc64" method, we should likewise define "hvc64" etc, with
parallel meaning.

Cheers
---Dave


From laurent.pinchart at ideasonboard.com  Tue Jul 30 06:03:07 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:03:07 +0200
Subject: [PATCH] clocksource: em_sti: Convert to devm_* managed helpers
In-Reply-To: <51F7229D.7090706@linaro.org>
References: <1374848897-18545-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <20130730020640.GA27724@verge.net.au> <51F7229D.7090706@linaro.org>
Message-ID: <2725526.9tXHptSQgN@avalon>

Hi Simon, John,

On Monday 29 July 2013 19:19:09 John Stultz wrote:
> On 07/29/2013 07:06 PM, Simon Horman wrote:
> > [ CC John Stultz, Thomas Gleixner ]
> > 
> > On Fri, Jul 26, 2013 at 04:28:17PM +0200, Laurent Pinchart wrote:
> >> Replace kzalloc, clk_get, ioremap and request_irq by their managed
> >> counterparts to simplify error paths.
> >> 
> >> Signed-off-by: Laurent Pinchart
> >> <laurent.pinchart+renesas at ideasonboard.com>
> > 
> > Hi Laurent,
> > 
> > I was recently asked for shmobile clocksource patches to be reviewed
> > by the clocksource maintainers. I believe that means John Stultz
> > and Thomas Gleixner who I have CCed on this email accordingly.
> 
> Daniel Lezcano (cc'ed) is picking up maintainership of
> clocksource/clockevent code in drivers/clocksource, so please cc him in
> the future.

Sure, will do so (I suppose Daniel will show up in MAINTAINERS, otherwise I 
might forget).

-- 
Regards,

Laurent Pinchart



From daniel.lezcano at linaro.org  Tue Jul 30 06:04:59 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 30 Jul 2013 12:04:59 +0200
Subject: [PATCH v4 07/17] clocksource: bcm2835: Switch to
 sched_clock_register()
In-Reply-To: <1374189690-10810-8-git-send-email-sboyd@codeaurora.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-8-git-send-email-sboyd@codeaurora.org>
Message-ID: <51F78FCB.2020004@linaro.org>

On 07/19/2013 01:21 AM, Stephen Boyd wrote:
> The 32 bit sched_clock interface now supports 64 bits. Upgrade to
> the 64 bit function to allow us to remove the 32 bit registration
> interface.
> 
> Cc: Stephen Warren <swarren at wwwdotorg.org>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---

Hi Stephen,

you sent a series with tick and clocksource changes.

John is recipient of part of them. I replaced him to maintain the
clocksource drivers.

Is the series you sent for clocksource drivers supposed to be taken by
me or by Russell ?

In the future if there are no dependencies, it would be preferable to
group the clocksource drivers changes into a series and send them to me.

Thanks
  -- Daniel

>  drivers/clocksource/bcm2835_timer.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clocksource/bcm2835_timer.c b/drivers/clocksource/bcm2835_timer.c
> index 07ea7ce..26ed331 100644
> --- a/drivers/clocksource/bcm2835_timer.c
> +++ b/drivers/clocksource/bcm2835_timer.c
> @@ -49,7 +49,7 @@ struct bcm2835_timer {
>  
>  static void __iomem *system_clock __read_mostly;
>  
> -static u32 notrace bcm2835_sched_read(void)
> +static u64 notrace bcm2835_sched_read(void)
>  {
>  	return readl_relaxed(system_clock);
>  }
> @@ -110,7 +110,7 @@ static void __init bcm2835_timer_init(struct device_node *node)
>  		panic("Can't read clock-frequency");
>  
>  	system_clock = base + REG_COUNTER_LO;
> -	setup_sched_clock(bcm2835_sched_read, 32, freq);
> +	sched_clock_register(bcm2835_sched_read, 32, freq);
>  
>  	clocksource_mmio_init(base + REG_COUNTER_LO, node->name,
>  		freq, 300, 32, clocksource_mmio_readl_up);
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From vijay.kilari at gmail.com  Tue Jul 30 06:05:26 2013
From: vijay.kilari at gmail.com (Vijay Kilari)
Date: Tue, 30 Jul 2013 15:35:26 +0530
Subject: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
In-Reply-To: <51F2AC53.3070607@wwwdotorg.org>
References: <1374817287-27952-1-git-send-email-vijay.kilari@gmail.com>
 <51F2AC53.3070607@wwwdotorg.org>
Message-ID: <CALicx6s5NX9ZaEiiGo1A=jT+o7Lpj8Y4ubkHeeK2p3DmZpwQeg@mail.gmail.com>

On Fri, Jul 26, 2013 at 10:35 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/25/2013 11:41 PM, vijay.kilari at gmail.com wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar at caviumnetworks.com>
>>
>> In case of normal kexec kernel load, all cpu's are offlined
>> before calling machine_kexec() under kernel_kexec() function.
>
> I'm not sure that's true, unless perhaps you have CONFIG_KEXEC_JUMP enabled?
>
>> But in case crash panic cpus are relaxed in
>> machine_crash_nonpanic_core() SMP function but not offlined.
>>
>> When crash kernel is loaded with kexec and on panic trigger
>> machine_kexec() checks for number of cpus online.
>> If more than one cpu is online machine_kexec() fails to load
>> with below error
>>
>> kexec: error: multiple CPUs still online
>>
>> In machine_crash_nonpanic_core() SMP function, offline CPU
>> before cpu_relax
>
>> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
>
>> @@ -73,6 +73,7 @@ void machine_crash_nonpanic_core(void *unused)
>>       crash_save_cpu(&regs, smp_processor_id());
>>       flush_cache_all();
>>
>> +     set_cpu_online(smp_processor_id(), false);
>
> I'm not familiar with that API, but it looks like it's just setting the
> *current* CPU offline. That sounds problematic for two reasons:
>
> 1) Setting the current CPU offline sounds like a bad idea; after all,
> code is still running on it. Presumably you want to offline all other CPUs.
>
   machine_crash_nonpanic_core() is a SMP call (smp_call_function) .
   Setting cpu offline is called for all other CPUs except the caller.

> 2) On a dual-CPU system, I guess this will leave a single CPU marked
> online, and hence satisfy the test in machine_kexec(). However, on a
> quad-core system, won't this just reduce the online CPU count from 4 to
> 3 and hence the test in machine_kexec() will still fail?
>
   Setting CPU offline is called from SMP call function. So it is
called for all the
   CPU's on the system except on caller CPU

> Can't you call disable_nonboot_cpus() from machine_crash_nonpanic_core()
> just like machine_shutdown() does?
   I thought of using disable_nonboot_cpus(). However crash can happen on
   any CPU. So we have to stop only nonpanic CPUs.
   The other mechanisms I thought to offline CPUs is
    1) Calling __cpu_disable() to put CPU completely offline. However
        platform_cpu_disable() does not allow CPU 0 is disable (crash can happen
        on any core).
    2) Calling machine_halt(). This does not allow smp_send_stop() on
bootable cpu


From florian at openwrt.org  Tue Jul 30 06:05:04 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Tue, 30 Jul 2013 11:05:04 +0100
Subject: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link'
 property
In-Reply-To: <20130730110705.3262bc3d@skate>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <CACxGe6td6uM0v5w92xPVCaVH4tP4AJ-h4SnN-mFoz5gSSosnQw@mail.gmail.com>
 <20130730110705.3262bc3d@skate>
Message-ID: <CAGVrzcZC9G2ny5rtojbzxmPu8-6EKQ_3io-+fxi61LLCt4Hk=w@mail.gmail.com>

Hello Thomas,

2013/7/30 Thomas Petazzoni <thomas.petazzoni at free-electrons.com>:
> Dear Grant Likely,
>
> On Tue, 23 Jul 2013 12:39:52 +0100, Grant Likely wrote:
>
>> > +Such a fixed link situation is described within an Ethernet device
>> > +Device Tree node using a 'fixed-link' property, composed of 5
>> > +elements:
>> > +
>> > + 1. A fake PHY ID, which must be unique accross all fixed-link PHYs in
>> > +    the system.
>>
>> That's just loony!  :)  Regardless of existing code doing this, it is
>> absolutely ridiculous to have it in the driver. The kernel should
>> handle generating a phy id transparently. I'd rather mark this field
>> as reserved in the binding and change the code to not care about it
>> anymore.
>
> In fact, this value is used for two things:
>
>  * As the PHY address on the fake "fixed" MDIO bus.
>
>  * As the PHY identifier, as reported by the MII registers PHYS_ID1
>    (0x2) and PHYS_ID2 (0x3).

Right, so I would start with disambiguating the two and just forget
about PHYS_ID1 and PHYS_ID2 for the moment since they probably do not
need to be per-PHY configurable.

>
> I think this doesn't make sense, because the two things are completely
> unrelated. Ideally, we'd like the PHY identifier for fixed PHYs to be
> something fixed, identical for all fixed PHYs. The problem is finding
> an OUI and device number that is available for that, but maybe we can
> ask the OpenMoko people to allocate one (see
> http://wiki.openmoko.org/wiki/OUI).

Well that would be ideal indeed, but I am wondering if we cannot just
go with some kind of magic value here anyway, regardless of
allocations since this is not a real hardware device. How about the
Linux Foundation? Is not that the same problem as with gadget USB
devices which should have some sort of real MAC address for instance?

>
> Then, the PHY address could be generated dynamically. This would
> require:
>
>  * Adding a fixed_phy_create() function that internally uses
>    fixed_phy_add(), but before that creates an unique PHY address for
>    this newly created PHY. Those unique addresses will be generated by
>    incrementing a global number of fixed PHYs, up to PHY_MAX_ADDR,
>    which is the maximum number of fixed PHYs that can anyway be
>    registered on the fixed MDIO bus.

Even though these are purely software PHY implementations, I believe
that some sort of predictability would be welcome, so I would just use
the phy_id argument passed to fixed_phy_add() as the address on the
fixed MDIO bus like it is today.

>
>    fixed_phy_create() would return this PHY address (positive) on
>    success, or a negative error code on failure.
>
>  * Change of_phy_register_fixed_link() to call fixed_phy_create()
>    instead of fixed_phy_add() and make it return the PHY address
>    allocated by fixed_phy_create().
>
>  * Add a of_phy_connect_fixed_link_direct() that is similar to
>    of_phy_connect_fixed_link() but takes an additional PHY address as
>    argument and uses that to generate the 'bus_id' used to find the
>    phy_device.
>
> Grant, Mark, Florian, do you have other proposals?

To sum up, let's just forget about the misuse of phy_id to fill in
PHYS_ID1 and PHYS_ID2 registers and keep the existing code with a
clear note that phy_id means the "PHY address on the fixed MDIO bus".
--
Florian


From daniel.lezcano at linaro.org  Tue Jul 30 06:07:36 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 30 Jul 2013 12:07:36 +0200
Subject: [PATCH 2/3] clocksource: Add missing dependency on CONFIG_OF
 for ARM_ARCH_TIMER
In-Reply-To: <1374682733-7416-3-git-send-email-jonathan.austin@arm.com>
References: <1374682733-7416-1-git-send-email-jonathan.austin@arm.com>
 <1374682733-7416-3-git-send-email-jonathan.austin@arm.com>
Message-ID: <51F79068.5050004@linaro.org>

On 07/24/2013 06:18 PM, Jonathan Austin wrote:
> Initialisation of the ARM Arch timer requires data from the DT. There is no
> fallback initialisation method and hence selecting ARM_ARCH_TIMER without OF
> makes little sense.
> 
> Furthermore, doing so causes a build error because the of_* stubs for
> !CONFIG_OF do not extend to all of the functions being used by this driver,
> and will not be extended unless there are valid use-cases for them to be
> (this is not a valid case).
> 
> Signed-off-by: Jonathan Austin <jonathan.austin at arm.com>
> ---

This falls under the drivers/clocksource umbrella.

Please resend to the maintainers.

Thanks
  -- Daniel

>  drivers/clocksource/Kconfig |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index b7b9b04..4348902 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -72,7 +72,8 @@ config CLKSRC_DBX500_PRCMU_SCHED_CLOCK
>  
>  config ARM_ARCH_TIMER
>  	bool
> -	select CLKSRC_OF if OF
> +	depends on OF
> +	select CLKSRC_OF
>  
>  config ARM_GLOBAL_TIMER
>  	bool
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From moinejf at free.fr  Tue Jul 30 06:09:07 2013
From: moinejf at free.fr (Jean-Francois Moine)
Date: Tue, 30 Jul 2013 12:09:07 +0200
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]
In-Reply-To: <20130730094457.GC2478@localhost.localdomain>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
 <20130715135420.GG10000@mudshark.cambridge.arm.com>
 <20130720044655.GC9433@mozilla.com>
 <20130721213753.GA29879@mudshark.cambridge.arm.com>
 <20130722185234.GA14519@localhost.localdomain>
 <20130729212140.GB12681@mozilla.com>
 <20130730092517.GB2478@localhost.localdomain>
 <20130730113853.46cbb00a@armhf>
 <20130730094457.GC2478@localhost.localdomain>
Message-ID: <20130730120907.6dcc469e@armhf>

On Tue, 30 Jul 2013 10:44:57 +0100
Dave Martin <Dave.Martin at arm.com> wrote:

> On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
> > On Tue, 30 Jul 2013 10:25:18 +0100
> > Dave Martin <Dave.Martin at arm.com> wrote:
> >   
> > > The pragmatic route is less contraversial and lower overhead: even though
> > > it's not correct as per the ABI, GCC is the only supported compiler for
> > > building the kernel anyway.  
> > 
> > BTW, kernels compiled with gcc-4.8 don't work.  
> 
> I haven't tried 4.8 yet.  Do you know what the problem is?

I randomly get 'NULL pointer dereference' in ext3 (trace below).

I compared the gcc-4.6 and gcc-4.8 ARM codes of the function where the
problem occurs, and, while the gcc-4.8 code seems a bit odd, the
problem should be somewhere else, surely in the memory management.

> > Did anybody succeed with clang?  
> 
> Hmm, I've no idea.  Is this possible?

freebsd kernels are compiled with clang, and I heard about linux
patches, but I did not find them yet.

Otherwise, replacing gcc with clang in the main kernel Makefile stops
on an assembly instruction where odd register numbers could not be
used. I did not go further.

------------------ gcc-4.8.1 kernel oops ----------------
Unable to handle kernel NULL pointer dereference at virtual address 00000003
pgd = bcf74000
[00000003] *pgd=3cf16831, *pte=00000000, *ppte=00000000
Internal error: Oops: 811 [#1] PREEMPT ARM
Modules linked in: arc4 p54usb p54common crc_ccitt mac80211 cfg80211 fbcon bitblit softcursor font snd_soc_spdif_tx tda998x dove_drm drm_kms_helper snd_soc_kirkwood mv_cesa drm snd_soc_kirkwood_spdif
CPU: 0 PID: 2426 Comm: iceweasel Not tainted 3.10.0-dirty #55
task: bd92b700 ti: bcf48000 task.ti: bcf48000
PC is at do_mpage_readpage+0x754/0x888
LR is at bio_add_page+0x44/0x4c
pc : [<800e3c70>]    lr : [<800db8ac>]    psr: 600f0113
sp : bcf49c34  ip : bcf49c88  fp : bcf49c5c
r10: 00000003  r9 : 00000000  r8 : 00000043
r7 : 00000001  r6 : 800e3f54  r5 : bcf49c30  r4 : 00000003
r3 : 00020000  r2 : 00000042  r1 : 00000000  r0 : bcf49c5c
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 3cf74019  DAC: 00000015
Process iceweasel (pid: 2426, stack limit = 0xbcf48240)
Stack: (0xbcf49c34 to 0xbcf4a000)
9c20:                                              00000020 bcf49d24 00200200
9c40: 00100100 bd580d94 00000000 80de4260 bcf49cf4 bcf49c60 800e3e78 800e3528
9c60: bcf49c88 bcf49c7c 801164cc 000000c1 804d660c 801164cc da0716b4 00000042
9c80: 00000000 00000000 00000020 00000000 80de4260 000000c1 00287ab6 00000000
9ca0: 00020000 80073500 bd402c80 804d6670 00100100 00000002 00200200 8039a2ac
9cc0: 804d660c 00000002 804d6ca0 80113f84 00000020 00000020 00000042 000000b4
9ce0: 00000000 00000020 bcf49d04 bcf49cf8 80113fa8 800e3db0 bcf49d6c bcf49d08
9d00: 80079ef4 80113f90 bcf00c00 00000018 bd580d94 00000020 bd580d98 bcf49d24
9d20: 00000001 80de4394 80de4254 91827364 bcf49d30 bcf49d30 bcf49d38 bcf49d38
9d40: 00000052 00000052 bcf00c00 bd580d94 bd580d94 bcf49df0 00000000 bcf6c0d0
9d60: bcf49d84 bcf49d70 8007a600 80079d10 00000008 7319d000 bcf49ddc bcf49d88
9d80: 800719f4 8007a5dc 80076670 80075448 00000001 000000c1 bcf00c48 00000002
9da0: 3c5e818f 00000000 bcf48008 bd580ce0 80013e40 bcf6c0d0 bdbc2e40 00000000
9dc0: 7319d000 00000028 00000000 bcf75cc0 bcf49e2c bcf49de0 8008b0ac 8007163c
9de0: bdb247a8 00000000 00000000 00000200 00000028 00000052 7319d000 00000000
9e00: 8007b8d0 bcf6c0d0 7319d000 7319d000 bdbc2e40 bcf6c0d0 00000028 00000000
9e20: bcf49e7c bcf49e30 8008e584 8008b048 00000052 00000028 00000000 000000b1
9e40: da538506 000000b1 804bb718 00000004 804bb708 bcf74000 00000398 7319d000
9e60: bdbc2e40 bcf6c0d0 00000028 bcf75cc0 bcf49eb4 bcf49e80 8008ed14 8008e51c
9e80: bcf75cc0 00000028 da538506 00000017 bcf49fb0 bdbc2e40 bd92b700 7319d288
9ea0: bcf48038 00000028 bcf49efc bcf49eb8 80013c38 8008ec80 0000b533 00000000
9ec0: 0000b533 00000200 00000000 bdbc2e78 00000000 00000017 80013a64 804b76f4
9ee0: 7319d288 bcf49fb0 00000ea1 00000000 bcf49fac bcf49f00 80008460 80013a70
9f00: bcf00c00 00000001 000b45c0 804bc488 bcf48000 00000000 0000001d 00000000
9f20: 00000001 73098000 bcf49f54 804bc488 bcf49f54 bcf49f40 8006a284 8006b524
9f40: 804bb900 bcf48028 00000000 00000000 0000001d 00000000 bcf49f7c bcf49f68
9f60: 80022424 8006db18 00020000 804c3c90 bcf49f9c bcf49f80 8000ec2c 800223a4
9f80: 00000621 75253ff0 200f0030 75238ed2 200f0030 ffffffff 00000000 00000ea1
9fa0: 00000000 bcf49fb0 8000e118 8000842c 7319d2ec 7319d292 7ee06c98 7319d288
9fc0: 7ee06c98 73098000 00000000 00000000 00000ea1 00000ea1 00000000 73223be0
9fe0: 752811fc 7ee06b88 7523bd75 75238ed2 200f0030 ffffffff 00000000 00000000
Backtrace: 
[<800e351c>] (do_mpage_readpage+0x0/0x888) from [<800e3e78>] (mpage_readpages+0xd4/0x130)
[<800e3da4>] (mpage_readpages+0x0/0x130) from [<80113fa8>] (ext3_readpages+0x24/0x28)
[<80113f84>] (ext3_readpages+0x0/0x28) from [<80079ef4>] (__do_page_cache_readahead+0x1f0/0x2d8)
[<80079d04>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007a600>] (ra_submit+0x30/0x38)
[<8007a5d0>] (ra_submit+0x0/0x38) from [<800719f4>] (filemap_fault+0x3c4/0x4b0)
[<80071630>] (filemap_fault+0x0/0x4b0) from [<8008b0ac>] (__do_fault+0x70/0x4a8)
[<8008b03c>] (__do_fault+0x0/0x4a8) from [<8008e584>] (handle_pte_fault+0x74/0x764)
[<8008e510>] (handle_pte_fault+0x0/0x764) from [<8008ed14>] (handle_mm_fault+0xa0/0xd4)
[<8008ec74>] (handle_mm_fault+0x0/0xd4) from [<80013c38>] (do_page_fault+0x1d4/0x278)
[<80013a64>] (do_page_fault+0x0/0x278) from [<80008460>] (do_DataAbort+0x40/0xa0)
[<80008420>] (do_DataAbort+0x0/0xa0) from [<8000e118>] (__dabt_usr+0x38/0x40)
Exception stack(0xbcf49fb0 to 0xbcf49ff8)
9fa0:                                     7319d2ec 7319d292 7ee06c98 7319d288
9fc0: 7ee06c98 73098000 00000000 00000000 00000ea1 00000ea1 00000000 73223be0
9fe0: 752811fc 7ee06b88 7523bd75 75238ed2 200f0030 ffffffff
 r8:00000ea1 r7:00000000 r6:ffffffff r5:200f0030 r4:75238ed2
Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0) 
---[ end trace 838796f906351fb0 ]---


-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/


From richard.genoud at gmail.com  Tue Jul 30 06:10:50 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 12:10:50 +0200
Subject: [PATCH v6 0/8] Sound support for at91sam9x5-wm8731 based boards
In-Reply-To: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
References: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <CACQ1gAjQn=bxCLGeF3VoyB=LLo1JHyUiqX1OD7JZMbP63AQ3Xw@mail.gmail.com>

arrrrggg...
I forgot that the DT list has changed.
I'll resend this with the correct address.

Sorry for the noise.


From rizhao at nvidia.com  Tue Jul 30 06:12:23 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Tue, 30 Jul 2013 18:12:23 +0800
Subject: [PATCH 7/9] ASoC: tegra: move to generic DMA DT binding
In-Reply-To: <51F2D4DD.9060308@wwwdotorg.org>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-8-git-send-email-rizhao@nvidia.com>
 <51F2D4DD.9060308@wwwdotorg.org>
Message-ID: <20130730101221.GO15855@rizhao-lap>

On Sat, Jul 27, 2013 at 03:58:21AM +0800, Stephen Warren wrote:
> On 07/23/2013 10:10 PM, Richard Zhao wrote:
> > - add tegra_dma_filter_data to specify dma info
> >   DMA DT binding needs the device that raise dma request and dma name
> >   to request a dma channel. tegra30_i2s is a special case. It should be ahub
> >   device and it also has dma name that cannot handled by ASoC dmaengine code.
> >   So we pass the info using filter data in snd_dmaengine_dai_dma_data.
> > - change i2s/ac97 drivers to use generic DT binding
> > - tegra30_i2s: alloc ahub tx/rx fifo at driver probe time
> 
> > diff --git a/sound/soc/tegra/tegra30_i2s.c b/sound/soc/tegra/tegra30_i2s.c
> 
> I don't understand why the FIFO alloc/free had to move from
> startup()/shutdown() to probe()/remove().

The call path is:
[<c0520e38>] (dump_stack+0x78/0xbc) from [<c03bb854>] (tegra_pcm_request_chan+0x10/0x34)
[<c03bb854>] (tegra_pcm_request_chan+0x10/0x34) from [<c03b6c2c>] (dmaengine_pcm_new+0xe0/0x134)
[<c03b6c2c>] (dmaengine_pcm_new+0xe0/0x134) from [<c03b5824>] (soc_new_pcm+0x2f0/0x3cc)
[<c03b5824>] (soc_new_pcm+0x2f0/0x3cc) from [<c03aa1a0>] (soc_probe_link_dais+0x358/0x39c)
[<c03aa1a0>] (soc_probe_link_dais+0x358/0x39c) from [<c03ab334>] (snd_soc_instantiate_card+0x35c/0x7a0)
[<c03ab334>] (snd_soc_instantiate_card+0x35c/0x7a0) from [<c03ab9dc>] (snd_soc_register_card+0x264/0x330)
[<c03ab9dc>] (snd_soc_register_card+0x264/0x330) from [<c03be350>] (tegra_rt5640_probe+0xf4/0x17c)
[<c03be350>] (tegra_rt5640_probe+0xf4/0x17c) from [<c0294290>] (platform_drv_probe+0x18/0x1c)

So I need to request dma channel at probe time.

> This will prevent later
> changes from making the connectivity between the AHUB FIFOs and I2S
> modules more dynamic, which is kind of the whole point of the AHUB HW
> module.

That's because it's i2s driver to register pcm device rather not ahub.
Ideally dma channel is only bound to ahub.
> 
> > diff --git a/sound/soc/tegra/tegra_pcm.h b/sound/soc/tegra/tegra_pcm.h
> 
> > +#define TEGRA_DMA_NAME_MAX_LEN	10
> > +
> > +/*
> > + * Generic DMA DT binding needs the device that raise dma request and dma name
> > + * to request a dma channel. tegra30_i2s is a special case. It should be ahub
> > + * device and it also has dma name that cannot handled by ASoC dmaengine code.
> > + * So we pass the info using filter data in snd_dmaengine_dai_dma_data.
> > + */
> > +struct tegra_dma_filter_data {
> > +	struct device *dma_dev;
> > +	char dma_name[TEGRA_DMA_NAME_MAX_LEN];
> > +};
> 
> I agree with Lars-Peter's comment that it'd be better to enhance the
> ASoC dmaengine support to allow the channel name to be specified so we
> don't need to much custom code.

Not only dma-name but also dma client device for this case.

> And that should use "char *" not a
> fixed-length array.
Ok, then there' two solutions.

struct tegra30_i2s {
...
        struct snd_dmaengine_dai_dma_data capture_dma_data;
        char dma_rx_name[10];
        struct tegra_dma_filter_data filter_data_rx;
...
        struct snd_dmaengine_dai_dma_data playback_dma_data;
        char dma_tx_name[10];
        struct tegra_dma_filter_data filter_data_tx;
};

probe: i2s->filter_data_rx.dma_name = i2s.dma_rx_name

or

probe: i2s->filter_data_rx.dma_name = kasprintf(GFP_KERNEL, "channel%d" ...);
remove: kfree(i2s->filter_data_rx.dma.name)

Which one do you like?


Thanks for review!
Richard


From rizhao at nvidia.com  Tue Jul 30 06:16:05 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Tue, 30 Jul 2013 18:16:05 +0800
Subject: [PATCH 8/9] ARM: dts: tegra: remove legacy
 nvidia,dma-request-selector properties
In-Reply-To: <51F2D525.7060605@wwwdotorg.org>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-9-git-send-email-rizhao@nvidia.com>
 <51F2D525.7060605@wwwdotorg.org>
Message-ID: <20130730101605.GP15855@rizhao-lap>

On Sat, Jul 27, 2013 at 03:59:33AM +0800, Stephen Warren wrote:
> On 07/23/2013 10:10 PM, Richard Zhao wrote:
> > All tegra dma client drivers have moved to generic dma binding.
> 
> Nit: Tegra not tegra, DMA not dma.
Alright.

Thanks
Richard


From paul at pwsan.com  Tue Jul 30 06:20:18 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 30 Jul 2013 10:20:18 +0000 (UTC)
Subject: [PATCH 2/4] serial: omap: enable PM runtime only when its fully
 configured
In-Reply-To: <51F74C11.2000306@ti.com>
References: <1374487277-26099-1-git-send-email-rnayak@ti.com>
 <1374487277-26099-3-git-send-email-rnayak@ti.com>
 <alpine.DEB.2.02.1307290843090.30864@utopia.booyaka.com>
 <51F62CEB.2090502@ti.com> <51F74C11.2000306@ti.com>
Message-ID: <alpine.DEB.2.02.1307301019570.8953@utopia.booyaka.com>

On Tue, 30 Jul 2013, Rajendra Nayak wrote:

> Looks like this one is already been queued by Greg.

OK, thanks for letting me know; I've dropped it.

- Paul


From rmk+kernel at arm.linux.org.uk  Tue Jul 30 06:18:52 2013
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Tue, 30 Jul 2013 11:18:52 +0100
Subject: [PATCH] ALSA: ASoC: uda134x: fix codec driver
Message-ID: <E1V4712-0007sg-Dw@rmk-PC.arm.linux.org.uk>

For some reason, the DAC/ADCs are not being powered up when I try and
use the UDA1341 driver; this used to work.  Looking back in the git
history, I don't see anything obvious which would cause this
regression.

However, from dumping the register writes, it seems that the codec is
powered down, and nothing calls set_bias_level to wake the codec up.

Moreover, this driver hasn't had DAPM support added to it, which
prevents platform drivers from taking advantage of DAPMs facilities.
So, let's add DAPM support to the driver.

As we move the power control for the DAC/ADC into DAPM, we no longer
need it in set_bias_level() - this function just becomes a way to
manipulate the power control and sync the register cache with the
hardware at the appropriate point.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
I noticed this while checking the Assabet audio, which uses the UDA1341.
I've also added the corresponding support to my Assabet audio driver.
If this looks like the correct thing to do to fix this, please apply.

 sound/soc/codecs/uda134x.c |   88 ++++++++++++++++++++++++++-----------------
 1 files changed, 53 insertions(+), 35 deletions(-)

diff --git a/sound/soc/codecs/uda134x.c b/sound/soc/codecs/uda134x.c
index 6d0aa44..c94d4c1 100644
--- a/sound/soc/codecs/uda134x.c
+++ b/sound/soc/codecs/uda134x.c
@@ -325,7 +325,6 @@ static int uda134x_set_dai_fmt(struct snd_soc_dai *codec_dai,
 static int uda134x_set_bias_level(struct snd_soc_codec *codec,
 				  enum snd_soc_bias_level level)
 {
-	u8 reg;
 	struct uda134x_platform_data *pd = codec->control_data;
 	int i;
 	u8 *cache = codec->reg_cache;
@@ -334,23 +333,6 @@ static int uda134x_set_bias_level(struct snd_soc_codec *codec,
 
 	switch (level) {
 	case SND_SOC_BIAS_ON:
-		/* ADC, DAC on */
-		switch (pd->model) {
-		case UDA134X_UDA1340:
-		case UDA134X_UDA1344:
-		case UDA134X_UDA1345:
-			reg = uda134x_read_reg_cache(codec, UDA134X_DATA011);
-			uda134x_write(codec, UDA134X_DATA011, reg | 0x03);
-			break;
-		case UDA134X_UDA1341:
-			reg = uda134x_read_reg_cache(codec, UDA134X_STATUS1);
-			uda134x_write(codec, UDA134X_STATUS1, reg | 0x03);
-			break;
-		default:
-			printk(KERN_ERR "UDA134X SoC codec: "
-			       "unsupported model %d\n", pd->model);
-			return -EINVAL;
-		}
 		break;
 	case SND_SOC_BIAS_PREPARE:
 		/* power on */
@@ -362,23 +344,6 @@ static int uda134x_set_bias_level(struct snd_soc_codec *codec,
 		}
 		break;
 	case SND_SOC_BIAS_STANDBY:
-		/* ADC, DAC power off */
-		switch (pd->model) {
-		case UDA134X_UDA1340:
-		case UDA134X_UDA1344:
-		case UDA134X_UDA1345:
-			reg = uda134x_read_reg_cache(codec, UDA134X_DATA011);
-			uda134x_write(codec, UDA134X_DATA011, reg & ~(0x03));
-			break;
-		case UDA134X_UDA1341:
-			reg = uda134x_read_reg_cache(codec, UDA134X_STATUS1);
-			uda134x_write(codec, UDA134X_STATUS1, reg & ~(0x03));
-			break;
-		default:
-			printk(KERN_ERR "UDA134X SoC codec: "
-			       "unsupported model %d\n", pd->model);
-			return -EINVAL;
-		}
 		break;
 	case SND_SOC_BIAS_OFF:
 		/* power off */
@@ -450,6 +415,37 @@ SOC_ENUM("PCM Playback De-emphasis", uda134x_mixer_enum[1]),
 SOC_SINGLE("DC Filter Enable Switch", UDA134X_STATUS0, 0, 1, 0),
 };
 
+/* UDA1341 has the DAC/ADC power down in STATUS1 */
+static const struct snd_soc_dapm_widget uda1341_dapm_widgets[] = {
+	SND_SOC_DAPM_DAC("DAC", "Playback", UDA134X_STATUS1, 0, 0),
+	SND_SOC_DAPM_ADC("ADC", "Capture", UDA134X_STATUS1, 1, 0),
+};
+
+/* UDA1340/4/5 has the DAC/ADC pwoer down in DATA0 11 */
+static const struct snd_soc_dapm_widget uda1340_dapm_widgets[] = {
+	SND_SOC_DAPM_DAC("DAC", "Playback", UDA134X_DATA011, 0, 0),
+	SND_SOC_DAPM_ADC("ADC", "Capture", UDA134X_DATA011, 1, 0),
+};
+
+/* Common DAPM widgets */
+static const struct snd_soc_dapm_widget uda134x_dapm_widgets[] = {
+	SND_SOC_DAPM_INPUT("VINL1"),
+	SND_SOC_DAPM_INPUT("VINR1"),
+	SND_SOC_DAPM_INPUT("VINL2"),
+	SND_SOC_DAPM_INPUT("VINR2"),
+	SND_SOC_DAPM_OUTPUT("VOUTL"),
+	SND_SOC_DAPM_OUTPUT("VOUTR"),
+};
+
+static const struct snd_soc_dapm_route uda134x_dapm_routes[] = {
+	{ "ADC", NULL, "VINL1" },
+	{ "ADC", NULL, "VINR1" },
+	{ "ADC", NULL, "VINL2" },
+	{ "ADC", NULL, "VINR2" },
+	{ "VOUTL", NULL, "DAC" },
+	{ "VOUTR", NULL, "DAC" },
+};
+
 static const struct snd_soc_dai_ops uda134x_dai_ops = {
 	.startup	= uda134x_startup,
 	.shutdown	= uda134x_shutdown,
@@ -485,6 +481,8 @@ static int uda134x_soc_probe(struct snd_soc_codec *codec)
 {
 	struct uda134x_priv *uda134x;
 	struct uda134x_platform_data *pd = codec->card->dev->platform_data;
+	const struct snd_soc_dapm_widget *widgets;
+	unsigned num_widgets;
 
 	int ret;
 
@@ -526,6 +524,22 @@ static int uda134x_soc_probe(struct snd_soc_codec *codec)
 	else
 		uda134x_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
 
+	if (pd->model == UDA134X_UDA1341) {
+		widgets = uda1341_dapm_widgets;
+		num_widgets = ARRAY_SIZE(uda1341_dapm_widgets);
+	} else {
+		widgets = uda1340_dapm_widgets;
+		num_widgets = ARRAY_SIZE(uda1340_dapm_widgets);
+	}
+
+	ret = snd_soc_dapm_new_controls(&codec->dapm, widgets, num_widgets);
+	if (ret) {
+		printk(KERN_ERR "%s failed to register dapm controls: %d",
+			__func__, ret);
+		kfree(uda134x);
+		return ret;
+	}
+
 	switch (pd->model) {
 	case UDA134X_UDA1340:
 	case UDA134X_UDA1344:
@@ -599,6 +613,10 @@ static struct snd_soc_codec_driver soc_codec_dev_uda134x = {
 	.read = uda134x_read_reg_cache,
 	.write = uda134x_write,
 	.set_bias_level = uda134x_set_bias_level,
+	.dapm_widgets = uda134x_dapm_widgets,
+	.num_dapm_widgets = ARRAY_SIZE(uda134x_dapm_widgets),
+	.dapm_routes = uda134x_dapm_routes,
+	.num_dapm_routes = ARRAY_SIZE(uda134x_dapm_routes),
 };
 
 static int uda134x_codec_probe(struct platform_device *pdev)
-- 
1.7.4.4



From linux at arm.linux.org.uk  Tue Jul 30 06:23:33 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 30 Jul 2013 11:23:33 +0100
Subject: [PATCH] arm: update advice on kernel and FDT load address.
In-Reply-To: <20130730094118.GF11527@mudshark.cambridge.arm.com>
References: <1375102578-5869-1-git-send-email-ian.campbell@citrix.com>
 <20130729135000.GK32383@mudshark.cambridge.arm.com>
 <1375106635.12741.8.camel@kazak.uk.xensource.com>
 <alpine.LFD.2.03.1307292234040.15022@syhkavp.arg>
 <20130730094118.GF11527@mudshark.cambridge.arm.com>
Message-ID: <20130730102333.GO24642@n2100.arm.linux.org.uk>

On Tue, Jul 30, 2013 at 10:41:18AM +0100, Will Deacon wrote:
> Hmm, how does that work with CONFIG_INITRAMFS_SOURCE, where the initramfs
> is built into the zImage? Would this impose a 32MB uncompressed limit on the
> size of the kernel + initramfs?

It does, especially if you have things like the CPU resume path in the
.data section so it can access the data necessary to resume without
violating the read-only nature of .text.


From broonie at kernel.org  Tue Jul 30 06:25:11 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 11:25:11 +0100
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
Message-ID: <20130730102511.GM9858@sirena.org.uk>

On Mon, Jul 29, 2013 at 08:30:29PM -0400, jonsmirl at gmail.com wrote:

> This...
> tx-dma-channel = <&pdma0 7>; /* preliminary */
> rx-dma-channel = <&pdma0 6>; /* preliminary */

> Probably should be
> dmas = <&pdma0 7>,<&pdma0 6>;
> dma-names = "tx", "rx";

It should be - the latter is the generic DMA binding.  There's a lot of
bindings in the kernel that predate that but people are currently
working to transfer over, this is one of the examples of instability
that everyone is talking about.
-------------- 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/20130730/ac91dfe8/attachment.sig>

From florian at openwrt.org  Tue Jul 30 06:26:14 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Tue, 30 Jul 2013 11:26:14 +0100
Subject: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link'
 property
In-Reply-To: <20130730111604.76fd5b6e@skate>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130723112259.GE4833@e106331-lin.cambridge.arm.com>
 <20130730111604.76fd5b6e@skate>
Message-ID: <CAGVrzcbQSKp=UCp=6HeA1XZkuzaopUNH2wX4=xgus5BNiMaXXg@mail.gmail.com>

Hello Thomas,

2013/7/30 Thomas Petazzoni <thomas.petazzoni at free-electrons.com>:
> Dear Mark Rutland,
>
> On Tue, 23 Jul 2013 12:22:59 +0100, Mark Rutland wrote:
>
>> > +Some Ethernet MACs have a "fixed link", and are not connected to a
>> > +normal MDIO-managed PHY device. For those situations, a Device Tree
>> > +binding allows to describe a "fixed link".
>>
>> Are partictular MACs fixed link, or can some either be either fixed link
>> or wired to an MDIO-managed PHY? i.e. can we assume a given MAC is
>> fixed-link from its compatible string?
>
> No, you can't. The case that I have is that the mvneta Ethernet MAC
> (of Marvell 370/XP SOCs) is sometimes used with a MDIO-managed PHY, and
> sometimes used with a switch that isn't manageable at all and should be
> considered as a fixed link.
>
> So no, the compatible string of the Ethernet MAC cannot be used to
> determine whether we're wired fixed link or to a classical MDIO-managed
> PHY.
>
>> > +Such a fixed link situation is described within an Ethernet device
>> > +Device Tree node using a 'fixed-link' property, composed of 5
>> > +elements:
>>
>> I'm not sure grouping these values together is the best way of handling
>> this. It's rather opaque, and inflexible for future extension.
>
> That's the DT binding that has been used by PowerPC platforms since
> several years, and I've simply re-used it. See 'git grep fixed-link
> arch/powerpc/boot/dts'.
>
> I have nothing against creating another DT binding, but for a start, I
> thought using existing bindings would be the best idea.
>
>> > + 1. A fake PHY ID, which must be unique accross all fixed-link PHYs in
>> > +    the system.
>>
>> Is there any reason this couldn't be allocated dynamically within the
>> kernel as needed? I don't see why an arbitrary unique value should be a
>> dt binding requirement; it seems like a leak of Linux implementation
>> details.
>
> As I pointed out in my reply to Grant, this value is used both as the
> PHY address on the fake fixed MDIO bus, and as the PHY identifier as
> reported by MII registers PHYS_ID1 and PHYS_ID2. If we can get assigned
> a proper PHY identifier that is used statically by the driver (it
> doesn't have to be different per fixed PHY instance), then we can
> allocate the PHY address dynamically. It requires a little bit of API
> changes but that's certainly doable. See my reply to Grant for a
> proposal about this.
>
>> > + 2. The duplex (1 for full-duplex, 0 for half-duplex)
>>
>> Will this change for a given MAC?
>>
>> Could we not have a boolean property for each of these, and require one
>> to be present?
>>
>> Possibly fixed-link-full-duplex / fix-link-half-duplex?
>>
>> > + 3. The speed (10, 100, 1000)
>>
>> fixed-link-speed?
>>
>> > + 4. The pause setting (1 for enabled, 0 for disabled)
>> > + 5. The asym pause setting (1 for enabled, 0 for disabled)
>>
>> Boolean properties for both of these?
>
> As Florian already answered, he already proposed something like this in
> the past, and it was rejected because a fixed PHY is not a piece of
> hardware and should therefore not be represented in the Device Tree.
> However, the fact that the MAC is not connected to a MDIO-manageable
> PHY but to some fixed-link thing is a property of the MAC hardware
> layout, and can therefore be expressed as a property of the MAC
> hardware.

True, what I *did* not like about this "fixed-link" 5 integer property
is that it does not present a consistent view of a PHY device and puts
some properties in the Ethernet MAC node, while some other are in the
Ethernet PHY node. From a hardware perspective, the Ethernet MAC and
the Ethernet PHY are two pieces of hardware, so both should get their
own node.

That said, since "fixed PHY" devices are not connected on the MDIO
bus, they cannot be represented as Ethernet PHY nodes as leafs of a
parent MDIO bus node, so maybe what we could do is having the fixed
PHY nodes child nodes of the Ethernet MAC but still make them look
like a "relatively" conventional Ethernet PHY node?

>
> See the thread that starts at
> http://article.gmane.org/gmane.linux.network/275771, and specifically
> Grant answers to Florian suggestions of having DT nodes to represent
> fixed PHY: http://article.gmane.org/gmane.linux.network/276208. Grant's
> answer was:
>
> """
> I think this discussion is going in the wrong direction. The concept
> of a dummy phy is really a Linux kernel internal detail. Creating some
> kind of dummy MDIO bus node does not describe the hardware. There is
> already support in the kernel for Ethernet MACs connected directly to
> a switch or other device. It is far better to describe how the MAC
> needs to be configured than to invent a non-existent phy. Search for
> "fixed-link" in the kernel tree to see how it is used.
> """
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com



-- 
Florian


From linux at arm.linux.org.uk  Tue Jul 30 06:26:44 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 30 Jul 2013 11:26:44 +0100
Subject: [PATCH] ARM: ARMv7-M: Fix name of NVIC handler function
In-Reply-To: <20130730081507.GO1754@pengutronix.de>
References: <1372238855-26112-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <20130708152917.GE29556@pengutronix.de>
 <20130730081507.GO1754@pengutronix.de>
Message-ID: <20130730102643.GP24642@n2100.arm.linux.org.uk>

On Tue, Jul 30, 2013 at 10:15:07AM +0200, Uwe Kleine-K?nig wrote:
> Hi Russell,
> 
> On Mon, Jul 08, 2013 at 05:29:17PM +0200, Uwe Kleine-K?nig wrote:
> > On Wed, Jun 26, 2013 at 11:27:35AM +0200, Uwe Kleine-K?nig wrote:
> > > The name changed in response to review comments for the nvic irqchip
> > > driver when the original name was already accepted into Russell King's
> > > tree.
> > > 
> > > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> > > ---
> > > Hello,
> > > 
> > > this patch was part of the irqchip patch v4, but I split it out for
> > > being easier to merge in v5. It applies on top of Russell's devel-stable
> > > branch.
> > > 
> > > Russell: I put it on top of my for-next branch (
> > > 
> > > 	git://git.pengutronix.de/git/ukl/linux.git for-next
> > > 
> > > ) that you merged into your devel-stable some time ago. So assuming
> > > you're fine with the patch, you can just repull or I can put it into
> > > your patch tracker if you prefer it. In the latter case please tell me.
> > The mismatch hit Linus' tree now. How should this patch get to him?
> Although it's not critical (as there are no in-tree users) I still think
> this should go in before 3.11.

Can you put it in the patch system please?


From richard.genoud at gmail.com  Tue Jul 30 06:32:01 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 12:32:01 +0200
Subject: [PATCH v6 0/8] Sound support for at91sam9x5-wm8731 based boards
Message-ID: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>

Hi,

This patchset add sound on the at91sam9x5ek board.
It's based on Nicolas Ferre's work in the 2.6.39 atmel patch for sam9x5:
https://github.com/linux4sam/linux-at91/commit/0aa157c9e71ccccf3abc30fa37eb5c95b392978d

It needs Bo Chen's patchset on the generic dmaengine (topic/atmel branch
on Mark's sound tree) and the SSC interrupts disabled (cf
http://www.spinics.net/lists/arm-kernel/msg256901.html)

As the at91 chips are on their way to the common clock framework, I thought
it may be better to retrieve the codec MCLK via this framework.
So it needs Boris Brezillon patch set "ARM: at91: move to common clk framework"
I've separated this patch because I don't know what is better:
 * applying the patchset with a hard coded clock, and once at91 has moved to common
clock framework, update the code and change the DT binding.
 * wait for the common clock framework.

Outstanding issue:
If this machine driver will support more SoCs maybe we should name it differently.
Maybe atmel_wm8731.c ? Since it could be merged with sam9g20_wm8731.c
when the g20 is DT only (There will be some more work though).

It has been tested on at91sam9g35ek, and should work on g15, g25, x25 and x35 also.

patches applies on next-20130729 + "ARM: at91: move to common clk framework"

Changes from v5:
 * Update the wm8731 DT binding documentation with available audio endpoints.
 * Remove Uwe's signed-off since it seems to be "an integration signed-off"
 * Remove rate constrains if freq==0 in wm8731.
 * Allocate dynamically card, dai and private structures.
 * Add a separate patch to set the oscillator value via DT.
NB: this last patch needs Boris Brezillon patch set "ARM: at91: move to common clk framework"


Changes from v4:
 * Move the rates constraints into the codec
 * Hard code the DAI format since it cannot be changed anyway (and
remove the DT bindings accordingly)
 * Add some consistency in the functions naming (sam9x5ek/at91sam9x5ek/sam9x5)
 * Retrieve the SSC id from the SSC controller phandle
 * Clarify the atmel-ssc.txt documentation
 * Develop audio-routing documentation
 * Tidy up the includes in the machine driver

Changes from v3:
 * Remove the use of macros in device tree documentation.

Changes from v2:
 * Change atmel,sam9x5-audio-wm8731 to atmel,sam9x5-wm8731-audio for
consistency with sam9g20 machine driver.
 * Use the snd_pcm_hw_constraint() API as suggested by Mark and Lars-Peter.
 * Remove the unnecessary snd_soc_dapm_sync() call as Lars-Peter suggested.
 * Add documentation for machine driver DT binding.
 * Update atmel-ssc DT binding documentation.
 * Add GPL license instead of just the "GPL" word (hope that's ok !)

Changes from v1-RFC:
 * drop patches on SSC since Bo Chen already did the work
 * reorder patches to have the machine driver first
 * drop code already handled by the ASoC framework
 * drop unneeded SND_ATMEL_SOC_PDC config selection
 * use static snd_soc_card and snd_soc_dai_link structures.

Best regards,
Richard.

Nicolas Ferre (1):
  ASoC: atmel: machine driver for at91sam9x5-wm8731 boards

Richard Genoud (7):
  ASoC: wm8731: add rates constraints
  Documentation: DT: update atmel SSC with DMA binding
  ARM: AT91: DTS: sam9x5: add SSC DMA parameters
  ARM: AT91: DTS: sam9x5ek: add WM8731 codec
  ARM: AT91: DTS: sam9x5ek: enable SSC
  ARM: AT91: DTS: sam9x5ek: add sound configuration
  ASoC: sam9x5: get codec MCLK via device tree

 .../devicetree/bindings/misc/atmel-ssc.txt         |   23 ++-
 .../bindings/sound/atmel-sam9x5-wm8731-audio.txt   |   39 ++++
 Documentation/devicetree/bindings/sound/wm8731.txt |    9 +
 arch/arm/boot/dts/at91sam9x5.dtsi                  |    3 +
 arch/arm/boot/dts/at91sam9x5ek.dtsi                |   32 +++
 sound/soc/atmel/Kconfig                            |   10 +
 sound/soc/atmel/Makefile                           |    2 +
 sound/soc/atmel/sam9x5_wm8731.c                    |  218 ++++++++++++++++++++
 sound/soc/codecs/wm8731.c                          |   60 +++++-
 9 files changed, 392 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
 create mode 100644 sound/soc/atmel/sam9x5_wm8731.c

-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 06:32:02 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 12:32:02 +0200
Subject: [PATCH v6 1/8] ASoC: wm8731: add rates constraints
In-Reply-To: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375180329-4860-2-git-send-email-richard.genoud@gmail.com>

Depending on the mclk (or crystal) selected, the wm8731 codec have some
constraints on its data sampling rates:
e.g. with a 12.288MHz or 18.432MHz crystal, the authorized rates are
8KHz, 32KHz, 48KHz and 96KHz.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 sound/soc/codecs/wm8731.c |   60 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 57 insertions(+), 3 deletions(-)

diff --git a/sound/soc/codecs/wm8731.c b/sound/soc/codecs/wm8731.c
index 5276062..456bb8c 100644
--- a/sound/soc/codecs/wm8731.c
+++ b/sound/soc/codecs/wm8731.c
@@ -45,6 +45,7 @@ static const char *wm8731_supply_names[WM8731_NUM_SUPPLIES] = {
 struct wm8731_priv {
 	struct regmap *regmap;
 	struct regulator_bulk_data supplies[WM8731_NUM_SUPPLIES];
+	const struct snd_pcm_hw_constraint_list *constraints;
 	unsigned int sysclk;
 	int sysclk_type;
 	int playback_fs;
@@ -290,6 +291,36 @@ static const struct _coeff_div coeff_div[] = {
 	{12000000, 88200, 136, 0xf, 0x1, 0x1},
 };
 
+/* rates constraints */
+static const unsigned int wm8731_rates_12000000[] = {
+	8000, 32000, 44100, 48000, 96000, 88200,
+};
+
+static const unsigned int wm8731_rates_12288000_18432000[] = {
+	8000, 32000, 48000, 96000,
+};
+
+static const unsigned int wm8731_rates_11289600_16934400[] = {
+	8000, 44100, 88200,
+};
+
+static const struct snd_pcm_hw_constraint_list wm8731_constraints_12000000 = {
+	.list = wm8731_rates_12000000,
+	.count = ARRAY_SIZE(wm8731_rates_12000000),
+};
+
+static const
+struct snd_pcm_hw_constraint_list wm8731_constraints_12288000_18432000 = {
+	.list = wm8731_rates_12288000_18432000,
+	.count = ARRAY_SIZE(wm8731_rates_12288000_18432000),
+};
+
+static const
+struct snd_pcm_hw_constraint_list wm8731_constraints_11289600_16934400 = {
+	.list = wm8731_rates_11289600_16934400,
+	.count = ARRAY_SIZE(wm8731_rates_11289600_16934400),
+};
+
 static inline int get_coeff(int mclk, int rate)
 {
 	int i;
@@ -362,17 +393,26 @@ static int wm8731_set_dai_sysclk(struct snd_soc_dai *codec_dai,
 	}
 
 	switch (freq) {
-	case 11289600:
+	case 0:
+		wm8731->constraints = NULL;
+		break;
 	case 12000000:
+		wm8731->constraints = &wm8731_constraints_12000000;
+		break;
 	case 12288000:
-	case 16934400:
 	case 18432000:
-		wm8731->sysclk = freq;
+		wm8731->constraints = &wm8731_constraints_12288000_18432000;
+		break;
+	case 16934400:
+	case 11289600:
+		wm8731->constraints = &wm8731_constraints_11289600_16934400;
 		break;
 	default:
 		return -EINVAL;
 	}
 
+	wm8731->sysclk = freq;
+
 	snd_soc_dapm_sync(&codec->dapm);
 
 	return 0;
@@ -475,12 +515,26 @@ static int wm8731_set_bias_level(struct snd_soc_codec *codec,
 	return 0;
 }
 
+static int wm8731_startup(struct snd_pcm_substream *substream,
+	struct snd_soc_dai *dai)
+{
+	struct wm8731_priv *wm8731 = snd_soc_codec_get_drvdata(dai->codec);
+
+	if (wm8731->constraints)
+		snd_pcm_hw_constraint_list(substream->runtime, 0,
+					   SNDRV_PCM_HW_PARAM_RATE,
+					   wm8731->constraints);
+
+	return 0;
+}
+
 #define WM8731_RATES SNDRV_PCM_RATE_8000_96000
 
 #define WM8731_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S20_3LE |\
 	SNDRV_PCM_FMTBIT_S24_LE)
 
 static const struct snd_soc_dai_ops wm8731_dai_ops = {
+	.startup	= wm8731_startup,
 	.hw_params	= wm8731_hw_params,
 	.digital_mute	= wm8731_mute,
 	.set_sysclk	= wm8731_set_dai_sysclk,
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 06:32:03 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 12:32:03 +0200
Subject: [PATCH v6 2/8] ASoC: atmel: machine driver for at91sam9x5-wm8731
 boards
In-Reply-To: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375180329-4860-3-git-send-email-richard.genoud@gmail.com>

From: Nicolas Ferre <nicolas.ferre at atmel.com>

Description of the Asoc machine driver for an at91sam9x5 based board
with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
master on the SSC/I2S interface. Its connections are a headphone jack
and an Line input jack.

[Richard: this is based on an old patch from Nicolas that I forward
ported and reworked to use only device tree]

Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 .../bindings/sound/atmel-sam9x5-wm8731-audio.txt   |   35 ++++
 Documentation/devicetree/bindings/sound/wm8731.txt |    9 +
 sound/soc/atmel/Kconfig                            |   10 +
 sound/soc/atmel/Makefile                           |    2 +
 sound/soc/atmel/sam9x5_wm8731.c                    |  208 ++++++++++++++++++++
 5 files changed, 264 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
 create mode 100644 sound/soc/atmel/sam9x5_wm8731.c

diff --git a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
new file mode 100644
index 0000000..0720857
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
@@ -0,0 +1,35 @@
+* Atmel at91sam9x5ek wm8731 audio complex
+
+Required properties:
+  - compatible: "atmel,sam9x5-wm8731-audio"
+  - atmel,model: The user-visible name of this sound complex.
+  - atmel,ssc-controller: The phandle of the SSC controller
+  - atmel,audio-codec: The phandle of the WM8731 audio codec
+  - atmel,audio-routing: A list of the connections between audio components.
+    Each entry is a pair of strings, the first being the connection's sink,
+    the second being the connection's source.
+
+Available audio endpoints for the audio-routing table:
+
+Board connectors:
+ * Headphone Jack
+ * Line In Jack
+
+wm8731 pins:
+cf Documentation/devicetree/bindings/sound/wm8731.txt
+
+Example:
+sound {
+	compatible = "atmel,sam9x5-wm8731-audio";
+
+	atmel,model = "wm8731 @ AT91SAM9X5EK";
+
+	atmel,audio-routing =
+		"Headphone Jack", "RHPOUT",
+		"Headphone Jack", "LHPOUT",
+		"LLINEIN", "Line In Jack",
+		"RLINEIN", "Line In Jack";
+
+	atmel,ssc-controller = <&ssc0>;
+	atmel,audio-codec = <&wm8731>;
+};
diff --git a/Documentation/devicetree/bindings/sound/wm8731.txt b/Documentation/devicetree/bindings/sound/wm8731.txt
index 15f7004..236690e 100644
--- a/Documentation/devicetree/bindings/sound/wm8731.txt
+++ b/Documentation/devicetree/bindings/sound/wm8731.txt
@@ -16,3 +16,12 @@ codec: wm8731 at 1a {
 	compatible = "wlf,wm8731";
 	reg = <0x1a>;
 };
+
+Available audio endpoints for an audio-routing table:
+ * LOUT: Left Channel Line Output
+ * ROUT: Right Channel Line Output
+ * LHPOUT: Left Channel Headphone Output
+ * RHPOUT: Right Channel Headphone Output
+ * LLINEIN: Left Channel Line Input
+ * RLINEIN: Right Channel Line Input
+ * MICIN: Microphone Input
diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 986323b..e48d38a 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -43,6 +43,16 @@ config SND_ATMEL_SOC_WM8904
 	  Say Y if you want to add support for Atmel ASoC driver for boards using
 	  WM8904 codec.
 
+config SND_AT91_SOC_SAM9X5_WM8731
+	tristate "SoC Audio support for WM8731-based at91sam9x5 board"
+	depends on ATMEL_SSC && SND_ATMEL_SOC && SOC_AT91SAM9X5
+	select SND_ATMEL_SOC_SSC
+	select SND_ATMEL_SOC_DMA
+	select SND_SOC_WM8731
+	help
+	  Say Y if you want to add support for audio SoC on an
+	  at91sam9x5 based board that is using WM8731 codec.
+
 config SND_AT91_SOC_AFEB9260
 	tristate "SoC Audio support for AFEB9260 board"
 	depends on ARCH_AT91 && ATMEL_SSC && ARCH_AT91 && MACH_AFEB9260 && SND_ATMEL_SOC
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index 922d4da..5baabc8 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -12,7 +12,9 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
 # AT91 Machine Support
 snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
 snd-atmel-soc-wm8904-objs := atmel_wm8904.o
+snd-soc-sam9x5-wm8731-objs := sam9x5_wm8731.o
 
 obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
 obj-$(CONFIG_SND_ATMEL_SOC_WM8904) += snd-atmel-soc-wm8904.o
+obj-$(CONFIG_SND_AT91_SOC_SAM9X5_WM8731) += snd-soc-sam9x5-wm8731.o
 obj-$(CONFIG_SND_AT91_SOC_AFEB9260) += snd-soc-afeb9260.o
diff --git a/sound/soc/atmel/sam9x5_wm8731.c b/sound/soc/atmel/sam9x5_wm8731.c
new file mode 100644
index 0000000..992ae38
--- /dev/null
+++ b/sound/soc/atmel/sam9x5_wm8731.c
@@ -0,0 +1,208 @@
+/*
+ * sam9x5_wm8731   --	SoC audio for AT91SAM9X5-based boards
+ *			that are using WM8731 as codec.
+ *
+ *  Copyright (C) 2011 Atmel,
+ *		  Nicolas Ferre <nicolas.ferre at atmel.com>
+ *
+ *  Copyright (C) 2013 Paratronic,
+ *		  Richard Genoud <richard.genoud at gmail.com>
+ *
+ * Based on sam9g20_wm8731.c by:
+ * Sedji Gaouaou <sedji.gaouaou at atmel.com>
+ *
+ *  This program is free software; you can redistribute  it and/or modify it
+ *  under  the terms of  the GNU General  Public License as published by the
+ *  Free Software Foundation;  either version 2 of the  License, or (at your
+ *  option) any later version.
+ *
+ */
+#include <linux/of.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/platform_device.h>
+#include <linux/device.h>
+
+#include <sound/soc.h>
+#include <sound/soc-dai.h>
+#include <sound/soc-dapm.h>
+
+#include "../codecs/wm8731.h"
+#include "atmel_ssc_dai.h"
+
+
+#define MCLK_RATE 12288000
+
+#define DRV_NAME "sam9x5-snd-wm8731"
+
+struct sam9x5_drvdata {
+	int ssc_id;
+};
+
+/*
+ * Logic for a wm8731 as connected on a at91sam9x5ek based board.
+ */
+static int sam9x5_wm8731_init(struct snd_soc_pcm_runtime *rtd)
+{
+	struct snd_soc_dai *codec_dai = rtd->codec_dai;
+	struct device *dev = rtd->dev;
+	int ret;
+
+	dev_dbg(dev, "ASoC: %s called\n", __func__);
+
+	/* set the codec system clock for DAC and ADC */
+	ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
+				     MCLK_RATE, SND_SOC_CLOCK_IN);
+	if (ret < 0) {
+		dev_err(dev, "ASoC: Failed to set WM8731 SYSCLK: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+/*
+ * Audio paths on at91sam9x5ek board:
+ *
+ *  |A| ------------> |      | ---R----> Headphone Jack
+ *  |T| <----\        |  WM  | ---L--/
+ *  |9| ---> CLK <--> | 8731 | <--R----- Line In Jack
+ *  |1| <------------ |      | <--L--/
+ */
+static const struct snd_soc_dapm_widget sam9x5_dapm_widgets[] = {
+	SND_SOC_DAPM_HP("Headphone Jack", NULL),
+	SND_SOC_DAPM_LINE("Line In Jack", NULL),
+};
+
+static int sam9x5_wm8731_driver_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *codec_np, *cpu_np;
+	struct snd_soc_card *card;
+	struct snd_soc_dai_link *dai;
+	struct sam9x5_drvdata *priv;
+	int ret;
+
+	if (!np) {
+		dev_err(&pdev->dev, "No device node supplied\n");
+		return -EINVAL;
+	}
+
+	card = devm_kzalloc(&pdev->dev, sizeof(*card), GFP_KERNEL);
+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+	dai = devm_kzalloc(&pdev->dev, sizeof(*dai), GFP_KERNEL);
+	if (!dai || !card || !priv) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	card->dev = &pdev->dev;
+	card->owner = THIS_MODULE;
+	card->dai_link = dai;
+	card->num_links = 1;
+	card->dapm_widgets = sam9x5_dapm_widgets;
+	card->num_dapm_widgets = ARRAY_SIZE(sam9x5_dapm_widgets);
+	dai->name = "WM8731";
+	dai->stream_name = "WM8731 PCM";
+	dai->codec_dai_name = "wm8731-hifi";
+	dai->init = sam9x5_wm8731_init;
+	dai->dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
+		| SND_SOC_DAIFMT_CBM_CFM;
+
+	ret = snd_soc_of_parse_card_name(card, "atmel,model");
+	if (ret) {
+		dev_err(&pdev->dev, "atmel,model node missing\n");
+		goto out;
+	}
+
+	ret = snd_soc_of_parse_audio_routing(card, "atmel,audio-routing");
+	if (ret) {
+		dev_err(&pdev->dev, "atmel,audio-routing node missing\n");
+		goto out;
+	}
+
+	codec_np = of_parse_phandle(np, "atmel,audio-codec", 0);
+	if (!codec_np) {
+		dev_err(&pdev->dev, "atmel,audio-codec node missing\n");
+		ret = -EINVAL;
+		goto out;
+	}
+
+	dai->codec_of_node = codec_np;
+
+	cpu_np = of_parse_phandle(np, "atmel,ssc-controller", 0);
+	if (!cpu_np) {
+		dev_err(&pdev->dev, "atmel,ssc-controller node missing\n");
+		ret = -EINVAL;
+		goto out;
+	}
+	dai->cpu_of_node = cpu_np;
+	dai->platform_of_node = cpu_np;
+
+	priv->ssc_id = of_alias_get_id(cpu_np, "ssc");
+
+	ret = atmel_ssc_set_audio(priv->ssc_id);
+	if (ret != 0) {
+		dev_err(&pdev->dev,
+			"ASoC: Failed to set SSC %d for audio: %d\n",
+			ret, priv->ssc_id);
+		goto out;
+	}
+
+	of_node_put(codec_np);
+	of_node_put(cpu_np);
+
+	platform_set_drvdata(pdev, card);
+
+	ret = snd_soc_register_card(card);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"ASoC: Platform device allocation failed\n");
+		goto out_put_audio;
+	}
+
+	dev_dbg(&pdev->dev, "ASoC: %s ok\n", __func__);
+
+	return ret;
+
+out_put_audio:
+	atmel_ssc_put_audio(priv->ssc_id);
+out:
+	return ret;
+}
+
+static int sam9x5_wm8731_driver_remove(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = platform_get_drvdata(pdev);
+	struct sam9x5_drvdata *priv = card->drvdata;
+
+	snd_soc_unregister_card(card);
+	atmel_ssc_put_audio(priv->ssc_id);
+
+	return 0;
+}
+
+static const struct of_device_id sam9x5_wm8731_of_match[] = {
+	{ .compatible = "atmel,sam9x5-wm8731-audio", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sam9x5_wm8731_of_match);
+
+static struct platform_driver sam9x5_wm8731_driver = {
+	.driver = {
+		.name = DRV_NAME,
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(sam9x5_wm8731_of_match),
+	},
+	.probe = sam9x5_wm8731_driver_probe,
+	.remove = sam9x5_wm8731_driver_remove,
+};
+module_platform_driver(sam9x5_wm8731_driver);
+
+/* Module information */
+MODULE_AUTHOR("Nicolas Ferre <nicolas.ferre at atmel.com>");
+MODULE_AUTHOR("Richard Genoud <richard.genoud at gmail.com>");
+MODULE_DESCRIPTION("ALSA SoC machine driver for AT91SAM9x5 - WM8731");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:" DRV_NAME);
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 06:32:05 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 12:32:05 +0200
Subject: [PATCH v6 4/8] ARM: AT91: DTS: sam9x5: add SSC DMA parameters
In-Reply-To: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375180329-4860-5-git-send-email-richard.genoud@gmail.com>

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5.dtsi |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 20b6423..d6c9895 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -716,6 +716,9 @@
 				compatible = "atmel,at91sam9g45-ssc";
 				reg = <0xf0010000 0x4000>;
 				interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
+				dmas = <&dma0 1 AT91_DMA_CFG_PER_ID(13)>,
+				       <&dma0 1 AT91_DMA_CFG_PER_ID(14)>;
+				dma-names = "tx", "rx";
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
 				clocks = <&periph 28>;
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 06:32:04 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 12:32:04 +0200
Subject: [PATCH v6 3/8] Documentation: DT: update atmel SSC with DMA binding
In-Reply-To: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375180329-4860-4-git-send-email-richard.genoud@gmail.com>

As atmel-ssc can be used with DMA, the documentation should be updated.
Also, a configuration DMA example is given.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 .../devicetree/bindings/misc/atmel-ssc.txt         |   23 +++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
index 38e51ad..a45ae08 100644
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -7,9 +7,30 @@ Required properties:
 - reg: Should contain SSC registers location and length
 - interrupts: Should contain SSC interrupt
 
-Example:
+
+Required properties for devices compatible with "atmel,at91sam9g45-ssc":
+- dmas: DMA specifier, consisting of a phandle to DMA controller node,
+  the memory interface and SSC DMA channel ID (for tx and rx).
+  See Documentation/devicetree/bindings/dma/atmel-dma.txt for details.
+- dma-names: Must be "tx", "rx".
+
+Examples:
+- PDC transfer:
 ssc0: ssc at fffbc000 {
 	compatible = "atmel,at91rm9200-ssc";
 	reg = <0xfffbc000 0x4000>;
 	interrupts = <14 4 5>;
 };
+
+- DMA transfer:
+ssc0: ssc at f0010000 {
+      compatible = "atmel,at91sam9g45-ssc";
+      reg = <0xf0010000 0x4000>;
+      interrupts = <28 4 5>;
+      dmas = <&dma0 1 13>,
+	     <&dma0 1 14>;
+      dma-names = "tx", "rx";
+      pinctrl-names = "default";
+      pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+      status = "disabled";
+};
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 06:32:07 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 12:32:07 +0200
Subject: [PATCH v6 6/8] ARM: AT91: DTS: sam9x5ek: enable SSC
In-Reply-To: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375180329-4860-7-git-send-email-richard.genoud@gmail.com>

Enable the SSC needed for the WM8731 codec

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index e6fb309..f3e83f7 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -95,6 +95,10 @@
 			watchdog at fffffe40 {
 				status = "okay";
 			};
+
+			ssc0: ssc at f0010000 {
+				status = "okay";
+			};
 		};
 
 		usb0: ohci at 00600000 {
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 06:32:06 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 12:32:06 +0200
Subject: [PATCH v6 5/8] ARM: AT91: DTS: sam9x5ek: add WM8731 codec
In-Reply-To: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375180329-4860-6-git-send-email-richard.genoud@gmail.com>

The WM8731 codec on sam9x5ek board is on i2c, address 1A

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
Acked-by: Mark Brown <broonie at linaro.org>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index d107241..e6fb309 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -59,6 +59,11 @@
 
 			i2c0: i2c at f8010000 {
 				status = "okay";
+
+				wm8731: wm8731 at 1a {
+					compatible = "wm8731";
+					reg = <0x1a>;
+				};
 			};
 
 			pinctrl at fffff400 {
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 06:32:08 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 12:32:08 +0200
Subject: [PATCH v6 7/8] ARM: AT91: DTS: sam9x5ek: add sound configuration
In-Reply-To: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375180329-4860-8-git-send-email-richard.genoud@gmail.com>

The sam9x5ek board has 2 jacks:
headphone wired on RHPOUT/LHPOUT of the wm8731
line in wired on LLINEIN/RLINEIN of the wm8731

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 arch/arm/boot/dts/at91sam9x5ek.dtsi |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index f3e83f7..9afe15b 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -113,4 +113,19 @@
 			status = "okay";
 		};
 	};
+
+	sound {
+		compatible = "atmel,sam9x5-wm8731-audio";
+
+		atmel,model = "wm8731 @ AT91SAM9X5EK";
+
+		atmel,audio-routing =
+			"Headphone Jack", "RHPOUT",
+			"Headphone Jack", "LHPOUT",
+			"LLINEIN", "Line In Jack",
+			"RLINEIN", "Line In Jack";
+
+		atmel,ssc-controller = <&ssc0>;
+		atmel,audio-codec = <&wm8731>;
+	};
 };
-- 
1.7.10.4



From richard.genoud at gmail.com  Tue Jul 30 06:32:09 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 12:32:09 +0200
Subject: [PATCH v6 8/8] ASoC: sam9x5: get codec MCLK via device tree
In-Reply-To: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
Message-ID: <1375180329-4860-9-git-send-email-richard.genoud@gmail.com>

Instead of having the clock rate hard coded, and thus, only compatible
with one board, we can make it compatible with other implementations.

Signed-off-by: Richard Genoud <richard.genoud at gmail.com>
---
 .../bindings/sound/atmel-sam9x5-wm8731-audio.txt     |    4 ++++
 arch/arm/boot/dts/at91sam9x5ek.dtsi                  |    8 ++++++++
 sound/soc/atmel/sam9x5_wm8731.c                      |   18 ++++++++++++++----
 3 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
index 0720857..114a4c5 100644
--- a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
+++ b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
@@ -8,6 +8,8 @@ Required properties:
   - atmel,audio-routing: A list of the connections between audio components.
     Each entry is a pair of strings, the first being the connection's sink,
     the second being the connection's source.
+  - clocks: Must contain an entry for the codec master clock.
+  - clock-names : Must be "mclk" (clock that feeds the codec master clock)
 
 Available audio endpoints for the audio-routing table:
 
@@ -32,4 +34,6 @@ sound {
 
 	atmel,ssc-controller = <&ssc0>;
 	atmel,audio-codec = <&wm8731>;
+	clocks = <&sound_crystal 0>;
+	clock-names = "mclk";
 };
diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index 9afe15b..b5ff17c 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -114,6 +114,12 @@
 		};
 	};
 
+	sound_crystal: osc at 0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency  = <12288000>;
+	};
+
 	sound {
 		compatible = "atmel,sam9x5-wm8731-audio";
 
@@ -127,5 +133,7 @@
 
 		atmel,ssc-controller = <&ssc0>;
 		atmel,audio-codec = <&wm8731>;
+		clocks = <&sound_crystal 0>;
+		clock-names = "mclk";
 	};
 };
diff --git a/sound/soc/atmel/sam9x5_wm8731.c b/sound/soc/atmel/sam9x5_wm8731.c
index 992ae38..f33c181 100644
--- a/sound/soc/atmel/sam9x5_wm8731.c
+++ b/sound/soc/atmel/sam9x5_wm8731.c
@@ -23,6 +23,8 @@
 #include <linux/mod_devicetable.h>
 #include <linux/platform_device.h>
 #include <linux/device.h>
+#include <linux/err.h>
+#include <linux/clk.h>
 
 #include <sound/soc.h>
 #include <sound/soc-dai.h>
@@ -31,12 +33,10 @@
 #include "../codecs/wm8731.h"
 #include "atmel_ssc_dai.h"
 
-
-#define MCLK_RATE 12288000
-
 #define DRV_NAME "sam9x5-snd-wm8731"
 
 struct sam9x5_drvdata {
+	struct clk *mclk;
 	int ssc_id;
 };
 
@@ -46,6 +46,7 @@ struct sam9x5_drvdata {
 static int sam9x5_wm8731_init(struct snd_soc_pcm_runtime *rtd)
 {
 	struct snd_soc_dai *codec_dai = rtd->codec_dai;
+	struct sam9x5_drvdata *priv = snd_soc_card_get_drvdata(rtd->card);
 	struct device *dev = rtd->dev;
 	int ret;
 
@@ -53,7 +54,8 @@ static int sam9x5_wm8731_init(struct snd_soc_pcm_runtime *rtd)
 
 	/* set the codec system clock for DAC and ADC */
 	ret = snd_soc_dai_set_sysclk(codec_dai, WM8731_SYSCLK_XTAL,
-				     MCLK_RATE, SND_SOC_CLOCK_IN);
+				     clk_get_rate(priv->mclk),
+				     SND_SOC_CLOCK_IN);
 	if (ret < 0) {
 		dev_err(dev, "ASoC: Failed to set WM8731 SYSCLK: %d\n", ret);
 		return ret;
@@ -142,6 +144,13 @@ static int sam9x5_wm8731_driver_probe(struct platform_device *pdev)
 
 	priv->ssc_id = of_alias_get_id(cpu_np, "ssc");
 
+	priv->mclk = devm_clk_get(&pdev->dev, "mclk");
+	if (IS_ERR(priv->mclk)) {
+		ret = PTR_ERR(priv->mclk);
+		dev_err(&pdev->dev, "Failed to get MCLK: %d\n", ret);
+		goto out;
+	}
+
 	ret = atmel_ssc_set_audio(priv->ssc_id);
 	if (ret != 0) {
 		dev_err(&pdev->dev,
@@ -153,6 +162,7 @@ static int sam9x5_wm8731_driver_probe(struct platform_device *pdev)
 	of_node_put(codec_np);
 	of_node_put(cpu_np);
 
+	snd_soc_card_set_drvdata(card, priv);
 	platform_set_drvdata(pdev, card);
 
 	ret = snd_soc_register_card(card);
-- 
1.7.10.4



From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 06:37:24 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:37:24 +0200
Subject: [PATCH v2 00/13] Remove platform callbacks from mmc_spi,
 sh_mmcif and sh_mobile_sdhi drivers
Message-ID: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Hello,

This patch set replaces callbacks to board code with regulators and GPIOs in
the mmc_spi, sh_mmcif and sh_mobile_sdhi MMC drivers.

Most of the required infrastructure is in place already on the drivers side,
except for CD debouncing support in the MMC core and CD/RO GPIOs support in
the mmc_spi driver. The series thus starts with patches 01/13 and 02/13 that
add those features to the MMC core and mmc_spi driver.

Patches 03/13 to 06/13 remove the board callbacks from the ecovec24 and
vision_ep9307 boards. The code has been compile-tested only as I don't have
access to those boards.

Patches 07/13 to 13/13 then proceed to remove the callbacks from the drivers
themselves and from the platform data structures.

This will be a bit messy to merge, as the series interleaves patches for
drivers and board files. Given that the mmc_spi driver is marked as orphan in
MAINTAINERS and that the vision_ep9307 hasn't seen any board-specific
modification in the last couple of kernel versions one option would be to
merge all patches (or at least patches 01/13 to 07/13) through Simon's tree if
all involved maintainers agree.

If patch 01/13 should better be merged through the MMC tree (in which case
02/13 should go through that tree as well), the two patches should be applied
first to the MMC tree, and a stable branch will be needed for Simon to base
the rest of the series on.

The series is based on tag renesas-devel-20130730v2 from
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git

Laurent Pinchart (13):
  mmc: slot-gpio: Add debouncing capability to mmc_gpio_request_cd()
  mmc: mmc_spi: Support CD/RO GPIOs
  ARM: ep93xx: vision_ep9307: Use MMC CD and RO GPIO
  sh: ecovec24: Use MMC/SDHI CD and RO GPIO
  sh: ecovec24: Remove mmcif .down_pwr() callback
  sh: ecovec24: Remove MMCIF and SDHI .set_pwr() callbacks
  mmc: mmc_spi: Remove platform data .get_cd() and .get_ro() callbacks
  mmc: sh_mmcif: Remove .down_pwr() callback from platform data
  mmc: sh_mmcif: Remove .set_pwr() callback from platform data
  mmc: sh_mobile_sdhi: Remove .get_cd() callback from platform data
  mmc: sh_mobile_sdhi: Remove .set_pwr() callback from platform data
  mmc: tmio-mmc: Remove .get_cd() callback from platform data
  mmc: tmio-mmc: Remove .set_pwr() callback from platform data

 arch/arm/mach-ep93xx/vision_ep9307.c | 57 ++---------------------
 arch/sh/boards/mach-ecovec24/setup.c | 89 ++++--------------------------------
 drivers/mmc/core/host.c              |  2 +-
 drivers/mmc/core/slot-gpio.c         | 14 +++++-
 drivers/mmc/host/jz4740_mmc.c        |  2 +-
 drivers/mmc/host/mmc_spi.c           | 49 +++++++++-----------
 drivers/mmc/host/mvsdio.c            |  3 +-
 drivers/mmc/host/of_mmc_spi.c        | 46 +++++--------------
 drivers/mmc/host/sdhci-esdhc-imx.c   |  2 +-
 drivers/mmc/host/sdhci-pxav3.c       |  3 +-
 drivers/mmc/host/sdhci-sirf.c        |  2 +-
 drivers/mmc/host/sh_mmcif.c          |  5 +-
 drivers/mmc/host/sh_mobile_sdhi.c    | 18 --------
 drivers/mmc/host/tmio_mmc.h          |  1 -
 drivers/mmc/host/tmio_mmc_pio.c      | 25 +---------
 include/linux/mfd/tmio.h             |  2 -
 include/linux/mmc/sh_mmcif.h         |  2 -
 include/linux/mmc/sh_mobile_sdhi.h   |  2 -
 include/linux/mmc/slot-gpio.h        |  3 +-
 include/linux/spi/mmc_spi.h          | 19 +++++---
 20 files changed, 86 insertions(+), 260 deletions(-)

-- 
Regards,

Laurent Pinchart



From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 06:37:25 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:37:25 +0200
Subject: [PATCH v2 01/13] mmc: slot-gpio: Add debouncing capability to
 mmc_gpio_request_cd()
In-Reply-To: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1375180657-23641-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Add a debounce parameter to the mmc_gpio_request_cd() function that
enables GPIO debouncing when set to a non-zero value. This can be used
by MMC host drivers to enable debouncing on the card detect signal.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/mmc/core/host.c            |  2 +-
 drivers/mmc/core/slot-gpio.c       | 14 +++++++++++++-
 drivers/mmc/host/jz4740_mmc.c      |  2 +-
 drivers/mmc/host/mvsdio.c          |  3 ++-
 drivers/mmc/host/sdhci-esdhc-imx.c |  2 +-
 drivers/mmc/host/sdhci-pxav3.c     |  3 ++-
 drivers/mmc/host/sdhci-sirf.c      |  2 +-
 drivers/mmc/host/sh_mmcif.c        |  2 +-
 drivers/mmc/host/tmio_mmc_pio.c    |  2 +-
 include/linux/mmc/slot-gpio.h      |  3 ++-
 10 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 6fb6f77..49bc403 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -374,7 +374,7 @@ int mmc_of_parse(struct mmc_host *host)
 			if (!(flags & OF_GPIO_ACTIVE_LOW))
 				gpio_inv_cd = true;
 
-			ret = mmc_gpio_request_cd(host, gpio);
+			ret = mmc_gpio_request_cd(host, gpio, 0);
 			if (ret < 0) {
 				dev_err(host->parent,
 					"Failed to request CD GPIO #%d: %d!\n",
diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index 3242351..46596b71 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -135,6 +135,7 @@ EXPORT_SYMBOL(mmc_gpio_request_ro);
  * mmc_gpio_request_cd - request a gpio for card-detection
  * @host: mmc host
  * @gpio: gpio number requested
+ * @debounce: debounce time in microseconds
  *
  * As devm_* managed functions are used in mmc_gpio_request_cd(), client
  * drivers do not need to explicitly call mmc_gpio_free_cd() for freeing up,
@@ -143,9 +144,14 @@ EXPORT_SYMBOL(mmc_gpio_request_ro);
  * switching for card-detection, they are responsible for calling
  * mmc_gpio_request_cd() and mmc_gpio_free_cd() as a pair on their own.
  *
+ * If GPIO debouncing is desired, set the debounce parameter to a non-zero
+ * value. The caller is responsible for ensuring that the GPIO driver associated
+ * with the GPIO supports debouncing, otherwise an error will be returned.
+ *
  * Returns zero on success, else an error.
  */
-int mmc_gpio_request_cd(struct mmc_host *host, unsigned int gpio)
+int mmc_gpio_request_cd(struct mmc_host *host, unsigned int gpio,
+			unsigned int debounce)
 {
 	struct mmc_gpio *ctx;
 	int irq = gpio_to_irq(gpio);
@@ -167,6 +173,12 @@ int mmc_gpio_request_cd(struct mmc_host *host, unsigned int gpio)
 		 */
 		return ret;
 
+	if (debounce) {
+		ret = gpio_set_debounce(gpio, debounce);
+		if (ret < 0)
+			return ret;
+	}
+
 	/*
 	 * Even if gpio_to_irq() returns a valid IRQ number, the platform might
 	 * still prefer to poll, e.g., because that IRQ number is already used
diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c
index 0308c9f..d868946 100644
--- a/drivers/mmc/host/jz4740_mmc.c
+++ b/drivers/mmc/host/jz4740_mmc.c
@@ -713,7 +713,7 @@ static int jz4740_mmc_request_gpios(struct mmc_host *mmc,
 		mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
 
 	if (gpio_is_valid(pdata->gpio_card_detect)) {
-		ret = mmc_gpio_request_cd(mmc, pdata->gpio_card_detect);
+		ret = mmc_gpio_request_cd(mmc, pdata->gpio_card_detect, 0);
 		if (ret)
 			return ret;
 	}
diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c
index 4ddd83f..06c5b0b 100644
--- a/drivers/mmc/host/mvsdio.c
+++ b/drivers/mmc/host/mvsdio.c
@@ -757,7 +757,8 @@ static int __init mvsd_probe(struct platform_device *pdev)
 		if (mvsd_data->gpio_card_detect &&
 		    gpio_is_valid(mvsd_data->gpio_card_detect)) {
 			ret = mmc_gpio_request_cd(mmc,
-						  mvsd_data->gpio_card_detect);
+						  mvsd_data->gpio_card_detect,
+						  0);
 			if (ret)
 				goto out;
 		} else {
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index 1dd5ba8..abc8cf0 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -616,7 +616,7 @@ static int sdhci_esdhc_imx_probe(struct platform_device *pdev)
 	/* card_detect */
 	switch (boarddata->cd_type) {
 	case ESDHC_CD_GPIO:
-		err = mmc_gpio_request_cd(host->mmc, boarddata->cd_gpio);
+		err = mmc_gpio_request_cd(host->mmc, boarddata->cd_gpio, 0);
 		if (err) {
 			dev_err(mmc_dev(host->mmc),
 				"failed to request card-detect gpio!\n");
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index bf99359..793dacd 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -278,7 +278,8 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
 			host->mmc->pm_caps |= pdata->pm_caps;
 
 		if (gpio_is_valid(pdata->ext_cd_gpio)) {
-			ret = mmc_gpio_request_cd(host->mmc, pdata->ext_cd_gpio);
+			ret = mmc_gpio_request_cd(host->mmc, pdata->ext_cd_gpio,
+						  0);
 			if (ret) {
 				dev_err(mmc_dev(host->mmc),
 					"failed to allocate card detect gpio\n");
diff --git a/drivers/mmc/host/sdhci-sirf.c b/drivers/mmc/host/sdhci-sirf.c
index 62a4a83..696122c 100644
--- a/drivers/mmc/host/sdhci-sirf.c
+++ b/drivers/mmc/host/sdhci-sirf.c
@@ -84,7 +84,7 @@ static int sdhci_sirf_probe(struct platform_device *pdev)
 	 * gets setup in sdhci_add_host() and we oops.
 	 */
 	if (gpio_is_valid(priv->gpio_cd)) {
-		ret = mmc_gpio_request_cd(host->mmc, priv->gpio_cd);
+		ret = mmc_gpio_request_cd(host->mmc, priv->gpio_cd, 0);
 		if (ret) {
 			dev_err(&pdev->dev, "card detect irq request failed: %d\n",
 				ret);
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 6706b5e..35f61cc 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -1436,7 +1436,7 @@ static int sh_mmcif_probe(struct platform_device *pdev)
 	}
 
 	if (pd && pd->use_cd_gpio) {
-		ret = mmc_gpio_request_cd(mmc, pd->cd_gpio);
+		ret = mmc_gpio_request_cd(mmc, pd->cd_gpio, 0);
 		if (ret < 0)
 			goto erqcd;
 	}
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index b72edb7..8486a22 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -1106,7 +1106,7 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host,
 	dev_pm_qos_expose_latency_limit(&pdev->dev, 100);
 
 	if (pdata->flags & TMIO_MMC_USE_GPIO_CD) {
-		ret = mmc_gpio_request_cd(mmc, pdata->cd_gpio);
+		ret = mmc_gpio_request_cd(mmc, pdata->cd_gpio, 0);
 		if (ret < 0) {
 			tmio_mmc_host_remove(_host);
 			return ret;
diff --git a/include/linux/mmc/slot-gpio.h b/include/linux/mmc/slot-gpio.h
index 7d88d27..b0c73e4 100644
--- a/include/linux/mmc/slot-gpio.h
+++ b/include/linux/mmc/slot-gpio.h
@@ -18,7 +18,8 @@ int mmc_gpio_request_ro(struct mmc_host *host, unsigned int gpio);
 void mmc_gpio_free_ro(struct mmc_host *host);
 
 int mmc_gpio_get_cd(struct mmc_host *host);
-int mmc_gpio_request_cd(struct mmc_host *host, unsigned int gpio);
+int mmc_gpio_request_cd(struct mmc_host *host, unsigned int gpio,
+			unsigned int debounce);
 void mmc_gpio_free_cd(struct mmc_host *host);
 
 #endif
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 06:37:27 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:37:27 +0200
Subject: [PATCH v2 03/13] ARM: ep93xx: vision_ep9307: Use MMC CD and RO GPIO
In-Reply-To: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1375180657-23641-4-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Pass the CD and RO GPIO numbers to the MMC SPI driver and remove the
custom .get_cd() and .get_ro() callback functions.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 arch/arm/mach-ep93xx/vision_ep9307.c | 57 ++++--------------------------------
 1 file changed, 5 insertions(+), 52 deletions(-)

diff --git a/arch/arm/mach-ep93xx/vision_ep9307.c b/arch/arm/mach-ep93xx/vision_ep9307.c
index 605956f..5a4c06d 100644
--- a/arch/arm/mach-ep93xx/vision_ep9307.c
+++ b/arch/arm/mach-ep93xx/vision_ep9307.c
@@ -224,62 +224,15 @@ static struct ep93xx_spi_chip_ops vision_spi_flash_hw = {
 #define VISION_SPI_MMC_WP	EP93XX_GPIO_LINE_F(0)
 #define VISION_SPI_MMC_CD	EP93XX_GPIO_LINE_EGPIO15
 
-static struct gpio vision_spi_mmc_gpios[] = {
-	{ VISION_SPI_MMC_WP, GPIOF_DIR_IN, "mmc_spi:wp" },
-	{ VISION_SPI_MMC_CD, GPIOF_DIR_IN, "mmc_spi:cd" },
-};
-
-static int vision_spi_mmc_init(struct device *pdev,
-			irqreturn_t (*func)(int, void *), void *pdata)
-{
-	int err;
-
-	err = gpio_request_array(vision_spi_mmc_gpios,
-				 ARRAY_SIZE(vision_spi_mmc_gpios));
-	if (err)
-		return err;
-
-	err = gpio_set_debounce(VISION_SPI_MMC_CD, 1);
-	if (err)
-		goto exit_err;
-
-	err = request_irq(gpio_to_irq(VISION_SPI_MMC_CD), func,
-			IRQ_TYPE_EDGE_BOTH, "mmc_spi:cd", pdata);
-	if (err)
-		goto exit_err;
-
-	return 0;
-
-exit_err:
-	gpio_free_array(vision_spi_mmc_gpios, ARRAY_SIZE(vision_spi_mmc_gpios));
-	return err;
-
-}
-
-static void vision_spi_mmc_exit(struct device *pdev, void *pdata)
-{
-	free_irq(gpio_to_irq(VISION_SPI_MMC_CD), pdata);
-	gpio_free_array(vision_spi_mmc_gpios, ARRAY_SIZE(vision_spi_mmc_gpios));
-}
-
-static int vision_spi_mmc_get_ro(struct device *pdev)
-{
-	return !!gpio_get_value(VISION_SPI_MMC_WP);
-}
-
-static int vision_spi_mmc_get_cd(struct device *pdev)
-{
-	return !gpio_get_value(VISION_SPI_MMC_CD);
-}
-
 static struct mmc_spi_platform_data vision_spi_mmc_data = {
-	.init		= vision_spi_mmc_init,
-	.exit		= vision_spi_mmc_exit,
-	.get_ro		= vision_spi_mmc_get_ro,
-	.get_cd		= vision_spi_mmc_get_cd,
 	.detect_delay	= 100,
 	.powerup_msecs	= 100,
 	.ocr_mask	= MMC_VDD_32_33 | MMC_VDD_33_34,
+	.flags		= MMC_SPI_USE_CD_GPIO | MMC_SPI_USE_RO_GPIO,
+	.cd_gpio	= VISION_SPI_MMC_CD,
+	.cd_debounce	= 1,
+	.ro_gpio	= VISION_SPI_MMC_WP,
+	.caps2		= MMC_CAP2_RO_ACTIVE_HIGH,
 };
 
 static int vision_spi_mmc_hw_setup(struct spi_device *spi)
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 06:37:26 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:37:26 +0200
Subject: [PATCH v2 02/13] mmc: mmc_spi: Support CD/RO GPIOs
In-Reply-To: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1375180657-23641-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Add support for passing CD/RO GPIO numbers directly to the mmc_spi
driver instead of relying solely on board code callbacks to retrieve the
CD/RO signals values. The driver will enable debouncing on the card
detect GPIO if the cd_debounce field is set to a non-zero value.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/mmc/host/mmc_spi.c    | 33 ++++++++++++++++++++++---------
 drivers/mmc/host/of_mmc_spi.c | 46 +++++++++++--------------------------------
 include/linux/spi/mmc_spi.h   | 16 +++++++++++++++
 3 files changed, 52 insertions(+), 43 deletions(-)

diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index 74145d1..62fb82d 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -36,6 +36,7 @@
 
 #include <linux/mmc/host.h>
 #include <linux/mmc/mmc.h>		/* for R1_SPI_* bit values */
+#include <linux/mmc/slot-gpio.h>
 
 #include <linux/spi/spi.h>
 #include <linux/spi/mmc_spi.h>
@@ -1278,11 +1279,8 @@ static int mmc_spi_get_ro(struct mmc_host *mmc)
 
 	if (host->pdata && host->pdata->get_ro)
 		return !!host->pdata->get_ro(mmc->parent);
-	/*
-	 * Board doesn't support read only detection; let the mmc core
-	 * decide what to do.
-	 */
-	return -ENOSYS;
+	else
+		return mmc_gpio_get_ro(mmc);
 }
 
 static int mmc_spi_get_cd(struct mmc_host *mmc)
@@ -1291,7 +1289,8 @@ static int mmc_spi_get_cd(struct mmc_host *mmc)
 
 	if (host->pdata && host->pdata->get_cd)
 		return !!host->pdata->get_cd(mmc->parent);
-	return -ENOSYS;
+	else
+		return mmc_gpio_get_cd(mmc);
 }
 
 static const struct mmc_host_ops mmc_spi_ops = {
@@ -1324,6 +1323,7 @@ static int mmc_spi_probe(struct spi_device *spi)
 	struct mmc_host		*mmc;
 	struct mmc_spi_host	*host;
 	int			status;
+	bool			has_ro = false;
 
 	/* We rely on full duplex transfers, mostly to reduce
 	 * per-transfer overheads (by making fewer transfers).
@@ -1448,18 +1448,33 @@ static int mmc_spi_probe(struct spi_device *spi)
 	}
 
 	/* pass platform capabilities, if any */
-	if (host->pdata)
+	if (host->pdata) {
 		mmc->caps |= host->pdata->caps;
+		mmc->caps2 |= host->pdata->caps2;
+	}
 
 	status = mmc_add_host(mmc);
 	if (status != 0)
 		goto fail_add_host;
 
+	if (host->pdata && host->pdata->flags & MMC_SPI_USE_CD_GPIO) {
+		status = mmc_gpio_request_cd(mmc, host->pdata->cd_gpio,
+					     host->pdata->cd_debounce);
+		if (status != 0)
+			goto fail_add_host;
+	}
+
+	if (host->pdata && host->pdata->flags & MMC_SPI_USE_RO_GPIO) {
+		has_ro = true;
+		status = mmc_gpio_request_ro(mmc, host->pdata->ro_gpio);
+		if (status != 0)
+			goto fail_add_host;
+	}
+
 	dev_info(&spi->dev, "SD/MMC host %s%s%s%s%s\n",
 			dev_name(&mmc->class_dev),
 			host->dma_dev ? "" : ", no DMA",
-			(host->pdata && host->pdata->get_ro)
-				? "" : ", no WP",
+			has_ro ? "" : ", no WP",
 			(host->pdata && host->pdata->setpower)
 				? "" : ", no poweroff",
 			(mmc->caps & MMC_CAP_NEEDS_POLL)
diff --git a/drivers/mmc/host/of_mmc_spi.c b/drivers/mmc/host/of_mmc_spi.c
index d720b5e..6e218fb 100644
--- a/drivers/mmc/host/of_mmc_spi.c
+++ b/drivers/mmc/host/of_mmc_spi.c
@@ -50,25 +50,6 @@ static struct of_mmc_spi *to_of_mmc_spi(struct device *dev)
 	return container_of(dev->platform_data, struct of_mmc_spi, pdata);
 }
 
-static int of_mmc_spi_read_gpio(struct device *dev, int gpio_num)
-{
-	struct of_mmc_spi *oms = to_of_mmc_spi(dev);
-	bool active_low = oms->alow_gpios[gpio_num];
-	bool value = gpio_get_value(oms->gpios[gpio_num]);
-
-	return active_low ^ value;
-}
-
-static int of_mmc_spi_get_cd(struct device *dev)
-{
-	return of_mmc_spi_read_gpio(dev, CD_GPIO);
-}
-
-static int of_mmc_spi_get_ro(struct device *dev)
-{
-	return of_mmc_spi_read_gpio(dev, WP_GPIO);
-}
-
 static int of_mmc_spi_init(struct device *dev,
 			   irqreturn_t (*irqhandler)(int, void *), void *mmc)
 {
@@ -130,20 +111,22 @@ struct mmc_spi_platform_data *mmc_spi_get_pdata(struct spi_device *spi)
 		if (!gpio_is_valid(oms->gpios[i]))
 			continue;
 
-		ret = gpio_request(oms->gpios[i], dev_name(dev));
-		if (ret < 0) {
-			oms->gpios[i] = -EINVAL;
-			continue;
-		}
-
 		if (gpio_flags & OF_GPIO_ACTIVE_LOW)
 			oms->alow_gpios[i] = true;
 	}
 
-	if (gpio_is_valid(oms->gpios[CD_GPIO]))
-		oms->pdata.get_cd = of_mmc_spi_get_cd;
-	if (gpio_is_valid(oms->gpios[WP_GPIO]))
-		oms->pdata.get_ro = of_mmc_spi_get_ro;
+	if (gpio_is_valid(oms->gpios[CD_GPIO])) {
+		oms->pdata.cd_gpio = oms->gpios[CD_GPIO];
+		oms->pdata.flags |= MMC_SPI_USE_CD_GPIO;
+		if (!oms->alow_gpios[CD_GPIO])
+			oms->pdata.caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
+	}
+	if (gpio_is_valid(oms->gpios[WP_GPIO])) {
+		oms->pdata.ro_gpio = oms->gpios[WP_GPIO];
+		oms->pdata.flags |= MMC_SPI_USE_RO_GPIO;
+		if (!oms->alow_gpios[WP_GPIO])
+			oms->pdata.caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
+	}
 
 	oms->detect_irq = irq_of_parse_and_map(np, 0);
 	if (oms->detect_irq != 0) {
@@ -166,15 +149,10 @@ void mmc_spi_put_pdata(struct spi_device *spi)
 	struct device *dev = &spi->dev;
 	struct device_node *np = dev->of_node;
 	struct of_mmc_spi *oms = to_of_mmc_spi(dev);
-	int i;
 
 	if (!dev->platform_data || !np)
 		return;
 
-	for (i = 0; i < ARRAY_SIZE(oms->gpios); i++) {
-		if (gpio_is_valid(oms->gpios[i]))
-			gpio_free(oms->gpios[i]);
-	}
 	kfree(oms);
 	dev->platform_data = NULL;
 }
diff --git a/include/linux/spi/mmc_spi.h b/include/linux/spi/mmc_spi.h
index 32be8db..87cdb35 100644
--- a/include/linux/spi/mmc_spi.h
+++ b/include/linux/spi/mmc_spi.h
@@ -7,6 +7,11 @@
 struct device;
 struct mmc_host;
 
+#define MMC_SPI_USE_CD_GPIO			(1 << 0)
+#define MMC_SPI_USE_RO_GPIO			(1 << 1)
+#define MMC_SPI_CD_GPIO_ACTIVE_LOW		(1 << 2)
+#define MMC_SPI_RO_GPIO_ACTIVE_LOW		(1 << 3)
+
 /* Put this in platform_data of a device being used to manage an MMC/SD
  * card slot.  (Modeled after PXA mmc glue; see that for usage examples.)
  *
@@ -30,8 +35,19 @@ struct mmc_spi_platform_data {
 	 */
 	int (*get_cd)(struct device *);
 
+	/*
+	 * Card Detect and Read Only GPIOs. To enable debouncing on the card
+	 * detect GPIO, set the cd_debounce to the debounce time in
+	 * microseconds.
+	 */
+	unsigned int flags;
+	unsigned int cd_gpio;
+	unsigned int cd_debounce;
+	unsigned int ro_gpio;
+
 	/* Capabilities to pass into mmc core (e.g. MMC_CAP_NEEDS_POLL). */
 	unsigned long caps;
+	unsigned long caps2;
 
 	/* how long to debounce card detect, in msecs */
 	u16 detect_delay;
-- 
1.8.1.5



From vijay.kilari at gmail.com  Tue Jul 30 06:37:12 2013
From: vijay.kilari at gmail.com (Vijay Kilari)
Date: Tue, 30 Jul 2013 16:07:12 +0530
Subject: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
In-Reply-To: <51F2ACF7.9000008@wwwdotorg.org>
References: <1374817287-27952-1-git-send-email-vijay.kilari@gmail.com>
 <20130726104908.GC17886@mudshark.cambridge.arm.com>
 <51F2ACF7.9000008@wwwdotorg.org>
Message-ID: <CALicx6ugumPG__rSAsTS95SH=6fTGqhpPFsQ8bLG-u-fbk0=pQ@mail.gmail.com>

On Fri, Jul 26, 2013 at 10:38 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/26/2013 04:49 AM, Will Deacon wrote:
>> [Adding Stephen Warren since he has been working in this area]
>>
>> On Fri, Jul 26, 2013 at 06:41:27AM +0100, vijay.kilari at gmail.com wrote:
>>> From: Vijaya Kumar K <Vijaya.Kumar at caviumnetworks.com>
>>>
>>> In case of normal kexec kernel load, all cpu's are offlined
>>> before calling machine_kexec() under kernel_kexec() function.
>>> But in case crash panic cpus are relaxed in
>>> machine_crash_nonpanic_core() SMP function but not offlined.
>>>
>>> When crash kernel is loaded with kexec and on panic trigger
>>> machine_kexec() checks for number of cpus online.
>>> If more than one cpu is online machine_kexec() fails to load
>>> with below error
>>>
>>> kexec: error: multiple CPUs still online
>>>
>>> In machine_crash_nonpanic_core() SMP function, offline CPU
>>> before cpu_relax
>
>>> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
>
>>> @@ -73,6 +73,7 @@ void machine_crash_nonpanic_core(void *unused)
>>>      crash_save_cpu(&regs, smp_processor_id());
>>>      flush_cache_all();
>>>
>>> +    set_cpu_online(smp_processor_id(), false);
>>>      atomic_dec(&waiting_for_crash_ipi);
>>>      while (1)
>>>              cpu_relax();
>>
>> Ok, I guess this will work since the new kernel is loaded somewhere higher
>> in memory and the crashed kernel will stick around, so the non-crashing CPUs
>> can sit around spinning.
>
> Does a kernel that's used as the crash kernel guarantee:
>
> * Never to re-use the memory that was used by the previous kernel, so
> that the spin loop code/data won't be corrupted, ever, no matter how
> long the crash recovery kernel runs.
>
> * Not use SMP, so there's never a need to re-activate the non-boot CPUs,
> which might not work if they aren't truly disabled but rather just
> running a pin loop?

>From cat /proc/iomem, normal kernel is executed from (0x80xxxxxx) with crash
kernel reserved 64M at 0xa0000000

80000000-bfffffff : System RAM
  80008000-805aeddf : Kernel code
  805e2000-8063e427 : Kernel data
  a0000000-a3ffffff : Crash kernel

crash kernel is loaded to reserved memory location and is executed from there.
I could confirm this from /proc/iomem when crash kernel is running

a0000000-a3efffff : System RAM
  a0008000-a05aeddf : Kernel code
  a05e2000-a063e427 : Kernel data


From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 06:37:29 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:37:29 +0200
Subject: [PATCH v2 05/13] sh: ecovec24: Remove mmcif .down_pwr() callback
In-Reply-To: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1375180657-23641-6-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The callback isn't used by the mmcif driver, don't initialize it in
board code.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
---
 arch/sh/boards/mach-ecovec24/setup.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-ecovec24/setup.c
index 4d46700..e1b6aa3 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -983,11 +983,6 @@ static struct platform_device vou_device = {
 
 #if defined(CONFIG_MMC_SH_MMCIF) || defined(CONFIG_MMC_SH_MMCIF_MODULE)
 /* SH_MMCIF */
-static void mmcif_down_pwr(struct platform_device *pdev)
-{
-	cn12_set_pwr(pdev, 0);
-}
-
 static struct resource sh_mmcif_resources[] = {
 	[0] = {
 		.name	= "SH_MMCIF",
@@ -1009,7 +1004,6 @@ static struct resource sh_mmcif_resources[] = {
 
 static struct sh_mmcif_plat_data sh_mmcif_plat = {
 	.set_pwr	= cn12_set_pwr,
-	.down_pwr	= mmcif_down_pwr,
 	.sup_pclk	= 0, /* SH7724: Max Pclk/2 */
 	.caps		= MMC_CAP_4_BIT_DATA |
 			  MMC_CAP_8_BIT_DATA |
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 06:37:28 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:37:28 +0200
Subject: [PATCH v2 04/13] sh: ecovec24: Use MMC/SDHI CD and RO GPIO
In-Reply-To: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1375180657-23641-5-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Pass the CD and RO GPIO numbers to the MMC SPI and SDHI drivers and
remove the custom .get_cd() and .get_ro() callback functions.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
---
 arch/sh/boards/mach-ecovec24/setup.c | 42 +++++++-----------------------------
 1 file changed, 8 insertions(+), 34 deletions(-)

diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-ecovec24/setup.c
index bcbb86b..4d46700 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -620,18 +620,14 @@ static void sdhi0_set_pwr(struct platform_device *pdev, int state)
 	gpio_set_value(GPIO_PTB6, state);
 }
 
-static int sdhi0_get_cd(struct platform_device *pdev)
-{
-	return !gpio_get_value(GPIO_PTY7);
-}
-
 static struct sh_mobile_sdhi_info sdhi0_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI0_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI0_RX,
 	.set_pwr	= sdhi0_set_pwr,
 	.tmio_caps      = MMC_CAP_SDIO_IRQ | MMC_CAP_POWER_OFF_CARD |
 			  MMC_CAP_NEEDS_POLL,
-	.get_cd		= sdhi0_get_cd,
+	.tmio_flags	= TMIO_MMC_USE_GPIO_CD,
+	.cd_gpio	= GPIO_PTY7,
 };
 
 static struct resource sdhi0_resources[] = {
@@ -678,18 +674,14 @@ static void cn12_set_pwr(struct platform_device *pdev, int state)
 
 #if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
 /* SDHI1 */
-static int sdhi1_get_cd(struct platform_device *pdev)
-{
-	return !gpio_get_value(GPIO_PTW7);
-}
-
 static struct sh_mobile_sdhi_info sdhi1_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI1_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI1_RX,
 	.tmio_caps      = MMC_CAP_SDIO_IRQ | MMC_CAP_POWER_OFF_CARD |
 			  MMC_CAP_NEEDS_POLL,
+	.tmio_flags	= TMIO_MMC_USE_GPIO_CD,
+	.cd_gpio	= GPIO_PTW7,
 	.set_pwr	= cn12_set_pwr,
-	.get_cd		= sdhi1_get_cd,
 };
 
 static struct resource sdhi1_resources[] = {
@@ -719,27 +711,19 @@ static struct platform_device sdhi1_device = {
 #else
 
 /* MMC SPI */
-static int mmc_spi_get_ro(struct device *dev)
-{
-	return gpio_get_value(GPIO_PTY6);
-}
-
-static int mmc_spi_get_cd(struct device *dev)
-{
-	return !gpio_get_value(GPIO_PTY7);
-}
-
 static void mmc_spi_setpower(struct device *dev, unsigned int maskval)
 {
 	gpio_set_value(GPIO_PTB6, maskval ? 1 : 0);
 }
 
 static struct mmc_spi_platform_data mmc_spi_info = {
-	.get_ro = mmc_spi_get_ro,
-	.get_cd = mmc_spi_get_cd,
 	.caps = MMC_CAP_NEEDS_POLL,
+	.caps2 = MMC_CAP2_RO_ACTIVE_HIGH,
 	.ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34, /* 3.3V only */
 	.setpower = mmc_spi_setpower,
+	.flags = MMC_SPI_USE_CD_GPIO | MMC_SPI_USE_RO_GPIO,
+	.cd_gpio = GPIO_PTY7,
+	.ro_gpio = GPIO_PTY6,
 };
 
 static struct spi_board_info spi_bus[] = {
@@ -1342,10 +1326,6 @@ static int __init arch_setup(void)
 	gpio_direction_input(GPIO_PTR6);
 
 	/* SD-card slot CN11 */
-	/* Card-detect, used on CN11, either with SDHI0 or with SPI */
-	gpio_request(GPIO_PTY7, NULL);
-	gpio_direction_input(GPIO_PTY7);
-
 #if defined(CONFIG_MMC_SDHI) || defined(CONFIG_MMC_SDHI_MODULE)
 	/* enable SDHI0 on CN11 (needs DS2.4 set to ON) */
 	gpio_request(GPIO_FN_SDHI0WP,  NULL);
@@ -1364,8 +1344,6 @@ static int __init arch_setup(void)
 	gpio_direction_output(GPIO_PTM4, 1); /* active low CS */
 	gpio_request(GPIO_PTB6, NULL); /* 3.3V power control */
 	gpio_direction_output(GPIO_PTB6, 0); /* disable power by default */
-	gpio_request(GPIO_PTY6, NULL); /* write protect */
-	gpio_direction_input(GPIO_PTY6);
 
 	spi_register_board_info(spi_bus, ARRAY_SIZE(spi_bus));
 #endif
@@ -1395,10 +1373,6 @@ static int __init arch_setup(void)
 	gpio_request(GPIO_FN_SDHI1D1,  NULL);
 	gpio_request(GPIO_FN_SDHI1D0,  NULL);
 
-	/* Card-detect, used on CN12 with SDHI1 */
-	gpio_request(GPIO_PTW7, NULL);
-	gpio_direction_input(GPIO_PTW7);
-
 	cn12_enabled = true;
 #endif
 
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 06:37:31 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:37:31 +0200
Subject: [PATCH v2 07/13] mmc: mmc_spi: Remove platform data .get_cd() and
 .get_ro() callbacks
In-Reply-To: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1375180657-23641-8-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

All platforms now pass the CD and RO GPIOs to the MMC SPI driver, those
callbacks are not used anymore. Remove them.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/mmc/host/mmc_spi.c  | 24 ++----------------------
 include/linux/spi/mmc_spi.h |  9 ---------
 2 files changed, 2 insertions(+), 31 deletions(-)

diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index 62fb82d..0a87e56 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -1273,31 +1273,11 @@ static void mmc_spi_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 	}
 }
 
-static int mmc_spi_get_ro(struct mmc_host *mmc)
-{
-	struct mmc_spi_host *host = mmc_priv(mmc);
-
-	if (host->pdata && host->pdata->get_ro)
-		return !!host->pdata->get_ro(mmc->parent);
-	else
-		return mmc_gpio_get_ro(mmc);
-}
-
-static int mmc_spi_get_cd(struct mmc_host *mmc)
-{
-	struct mmc_spi_host *host = mmc_priv(mmc);
-
-	if (host->pdata && host->pdata->get_cd)
-		return !!host->pdata->get_cd(mmc->parent);
-	else
-		return mmc_gpio_get_cd(mmc);
-}
-
 static const struct mmc_host_ops mmc_spi_ops = {
 	.request	= mmc_spi_request,
 	.set_ios	= mmc_spi_set_ios,
-	.get_ro		= mmc_spi_get_ro,
-	.get_cd		= mmc_spi_get_cd,
+	.get_ro		= mmc_gpio_get_ro,
+	.get_cd		= mmc_gpio_get_cd,
 };
 
 
diff --git a/include/linux/spi/mmc_spi.h b/include/linux/spi/mmc_spi.h
index 87cdb35..274bc0f 100644
--- a/include/linux/spi/mmc_spi.h
+++ b/include/linux/spi/mmc_spi.h
@@ -26,15 +26,6 @@ struct mmc_spi_platform_data {
 		void *);
 	void (*exit)(struct device *, void *);
 
-	/* sense switch on sd cards */
-	int (*get_ro)(struct device *);
-
-	/*
-	 * If board does not use CD interrupts, driver can optimize polling
-	 * using this function.
-	 */
-	int (*get_cd)(struct device *);
-
 	/*
 	 * Card Detect and Read Only GPIOs. To enable debouncing on the card
 	 * detect GPIO, set the cd_debounce to the debounce time in
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 06:37:30 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:37:30 +0200
Subject: [PATCH v2 06/13] sh: ecovec24: Remove MMCIF and SDHI .set_pwr()
 callbacks
In-Reply-To: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1375180657-23641-7-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The MMCIF and SHDI platform data .set_pwr() callbacks are used to
control the vmmc/vqmmc power supplies. As the power supplies already
register control GPIOs there's no need to perform the operation
manually. Remove the callback functions.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
---
 arch/sh/boards/mach-ecovec24/setup.c | 41 ------------------------------------
 1 file changed, 41 deletions(-)

diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-ecovec24/setup.c
index e1b6aa3..60bf82c 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -601,29 +601,9 @@ static struct platform_device sdhi0_power = {
 	},
 };
 
-static void sdhi0_set_pwr(struct platform_device *pdev, int state)
-{
-	static int power_gpio = -EINVAL;
-
-	if (power_gpio < 0) {
-		int ret = gpio_request(GPIO_PTB6, NULL);
-		if (!ret) {
-			power_gpio = GPIO_PTB6;
-			gpio_direction_output(power_gpio, 0);
-		}
-	}
-
-	/*
-	 * Toggle the GPIO regardless, whether we managed to grab it above or
-	 * the fixed regulator driver did.
-	 */
-	gpio_set_value(GPIO_PTB6, state);
-}
-
 static struct sh_mobile_sdhi_info sdhi0_info = {
 	.dma_slave_tx	= SHDMA_SLAVE_SDHI0_TX,
 	.dma_slave_rx	= SHDMA_SLAVE_SDHI0_RX,
-	.set_pwr	= sdhi0_set_pwr,
 	.tmio_caps      = MMC_CAP_SDIO_IRQ | MMC_CAP_POWER_OFF_CARD |
 			  MMC_CAP_NEEDS_POLL,
 	.tmio_flags	= TMIO_MMC_USE_GPIO_CD,
@@ -653,25 +633,6 @@ static struct platform_device sdhi0_device = {
 	},
 };
 
-static void cn12_set_pwr(struct platform_device *pdev, int state)
-{
-	static int power_gpio = -EINVAL;
-
-	if (power_gpio < 0) {
-		int ret = gpio_request(GPIO_PTB7, NULL);
-		if (!ret) {
-			power_gpio = GPIO_PTB7;
-			gpio_direction_output(power_gpio, 0);
-		}
-	}
-
-	/*
-	 * Toggle the GPIO regardless, whether we managed to grab it above or
-	 * the fixed regulator driver did.
-	 */
-	gpio_set_value(GPIO_PTB7, state);
-}
-
 #if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
 /* SDHI1 */
 static struct sh_mobile_sdhi_info sdhi1_info = {
@@ -681,7 +642,6 @@ static struct sh_mobile_sdhi_info sdhi1_info = {
 			  MMC_CAP_NEEDS_POLL,
 	.tmio_flags	= TMIO_MMC_USE_GPIO_CD,
 	.cd_gpio	= GPIO_PTW7,
-	.set_pwr	= cn12_set_pwr,
 };
 
 static struct resource sdhi1_resources[] = {
@@ -1003,7 +963,6 @@ static struct resource sh_mmcif_resources[] = {
 };
 
 static struct sh_mmcif_plat_data sh_mmcif_plat = {
-	.set_pwr	= cn12_set_pwr,
 	.sup_pclk	= 0, /* SH7724: Max Pclk/2 */
 	.caps		= MMC_CAP_4_BIT_DATA |
 			  MMC_CAP_8_BIT_DATA |
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 06:37:32 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:37:32 +0200
Subject: [PATCH v2 08/13] mmc: sh_mmcif: Remove .down_pwr() callback from
 platform data
In-Reply-To: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1375180657-23641-9-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The callback isn't used by the driver and isn't initialized by board
code. Remove it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
---
 include/linux/mmc/sh_mmcif.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/mmc/sh_mmcif.h b/include/linux/mmc/sh_mmcif.h
index e7d5dd6..39011eb 100644
--- a/include/linux/mmc/sh_mmcif.h
+++ b/include/linux/mmc/sh_mmcif.h
@@ -34,7 +34,6 @@
 
 struct sh_mmcif_plat_data {
 	void (*set_pwr)(struct platform_device *pdev, int state);
-	void (*down_pwr)(struct platform_device *pdev);
 	int (*get_cd)(struct platform_device *pdef);
 	unsigned int		slave_id_tx;	/* embedded slave_id_[tr]x */
 	unsigned int		slave_id_rx;
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 06:37:33 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:37:33 +0200
Subject: [PATCH v2 09/13] mmc: sh_mmcif: Remove .set_pwr() callback from
 platform data
In-Reply-To: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1375180657-23641-10-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The .set_pwr() callback isn't used anymore as all platforms register
GPIO-controlled regulators. Remove it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
---
 drivers/mmc/host/sh_mmcif.c  | 3 ---
 include/linux/mmc/sh_mmcif.h | 1 -
 2 files changed, 4 deletions(-)

diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 35f61cc..ac8e109 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -956,11 +956,8 @@ static int sh_mmcif_clk_update(struct sh_mmcif_host *host)
 
 static void sh_mmcif_set_power(struct sh_mmcif_host *host, struct mmc_ios *ios)
 {
-	struct sh_mmcif_plat_data *pd = host->pd->dev.platform_data;
 	struct mmc_host *mmc = host->mmc;
 
-	if (pd && pd->set_pwr)
-		pd->set_pwr(host->pd, ios->power_mode != MMC_POWER_OFF);
 	if (!IS_ERR(mmc->supply.vmmc))
 		/* Errors ignored... */
 		mmc_regulator_set_ocr(mmc, mmc->supply.vmmc,
diff --git a/include/linux/mmc/sh_mmcif.h b/include/linux/mmc/sh_mmcif.h
index 39011eb..767fac5 100644
--- a/include/linux/mmc/sh_mmcif.h
+++ b/include/linux/mmc/sh_mmcif.h
@@ -33,7 +33,6 @@
  */
 
 struct sh_mmcif_plat_data {
-	void (*set_pwr)(struct platform_device *pdev, int state);
 	int (*get_cd)(struct platform_device *pdef);
 	unsigned int		slave_id_tx;	/* embedded slave_id_[tr]x */
 	unsigned int		slave_id_rx;
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 06:37:34 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:37:34 +0200
Subject: [PATCH v2 10/13] mmc: sh_mobile_sdhi: Remove .get_cd() callback from
 platform data
In-Reply-To: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1375180657-23641-11-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

All platforms pass the CD GPIO number to the driver in the .cd_gpio
field. The .get_cd() callback isn't used anymore, remove it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
---
 drivers/mmc/host/sh_mobile_sdhi.c  | 9 ---------
 include/linux/mmc/sh_mobile_sdhi.h | 1 -
 2 files changed, 10 deletions(-)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index ebea749..663a672 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -77,13 +77,6 @@ static void sh_mobile_sdhi_set_pwr(struct platform_device *pdev, int state)
 	p->set_pwr(pdev, state);
 }
 
-static int sh_mobile_sdhi_get_cd(struct platform_device *pdev)
-{
-	struct sh_mobile_sdhi_info *p = pdev->dev.platform_data;
-
-	return p->get_cd(pdev);
-}
-
 static int sh_mobile_sdhi_wait_idle(struct tmio_mmc_host *host)
 {
 	int timeout = 1000;
@@ -182,8 +175,6 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
 		mmc_data->cd_gpio = p->cd_gpio;
 		if (p->set_pwr)
 			mmc_data->set_pwr = sh_mobile_sdhi_set_pwr;
-		if (p->get_cd)
-			mmc_data->get_cd = sh_mobile_sdhi_get_cd;
 
 		if (p->dma_slave_tx > 0 && p->dma_slave_rx > 0) {
 			/*
diff --git a/include/linux/mmc/sh_mobile_sdhi.h b/include/linux/mmc/sh_mobile_sdhi.h
index b76bcf0..f31c692 100644
--- a/include/linux/mmc/sh_mobile_sdhi.h
+++ b/include/linux/mmc/sh_mobile_sdhi.h
@@ -26,7 +26,6 @@ struct sh_mobile_sdhi_info {
 	u32 tmio_ocr_mask;	/* available MMC voltages */
 	unsigned int cd_gpio;
 	void (*set_pwr)(struct platform_device *pdev, int state);
-	int (*get_cd)(struct platform_device *pdev);
 
 	/* callbacks for board specific setup code */
 	int (*init)(struct platform_device *pdev,
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 06:37:35 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:37:35 +0200
Subject: [PATCH v2 11/13] mmc: sh_mobile_sdhi: Remove .set_pwr() callback from
 platform data
In-Reply-To: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1375180657-23641-12-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The .set_pwr() callback isn't used anymore as all platforms register
GPIO-controlled regulators. Remove it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
---
 drivers/mmc/host/sh_mobile_sdhi.c  | 9 ---------
 include/linux/mmc/sh_mobile_sdhi.h | 1 -
 2 files changed, 10 deletions(-)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index 663a672..b3fd2c3 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -70,13 +70,6 @@ static void sh_mobile_sdhi_clk_disable(struct platform_device *pdev)
 	clk_disable(priv->clk);
 }
 
-static void sh_mobile_sdhi_set_pwr(struct platform_device *pdev, int state)
-{
-	struct sh_mobile_sdhi_info *p = pdev->dev.platform_data;
-
-	p->set_pwr(pdev, state);
-}
-
 static int sh_mobile_sdhi_wait_idle(struct tmio_mmc_host *host)
 {
 	int timeout = 1000;
@@ -173,8 +166,6 @@ static int sh_mobile_sdhi_probe(struct platform_device *pdev)
 		mmc_data->capabilities |= p->tmio_caps;
 		mmc_data->capabilities2 |= p->tmio_caps2;
 		mmc_data->cd_gpio = p->cd_gpio;
-		if (p->set_pwr)
-			mmc_data->set_pwr = sh_mobile_sdhi_set_pwr;
 
 		if (p->dma_slave_tx > 0 && p->dma_slave_rx > 0) {
 			/*
diff --git a/include/linux/mmc/sh_mobile_sdhi.h b/include/linux/mmc/sh_mobile_sdhi.h
index f31c692..68927ae 100644
--- a/include/linux/mmc/sh_mobile_sdhi.h
+++ b/include/linux/mmc/sh_mobile_sdhi.h
@@ -25,7 +25,6 @@ struct sh_mobile_sdhi_info {
 	unsigned long tmio_caps2;
 	u32 tmio_ocr_mask;	/* available MMC voltages */
 	unsigned int cd_gpio;
-	void (*set_pwr)(struct platform_device *pdev, int state);
 
 	/* callbacks for board specific setup code */
 	int (*init)(struct platform_device *pdev,
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 06:37:36 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:37:36 +0200
Subject: [PATCH v2 12/13] mmc: tmio-mmc: Remove .get_cd() callback from
 platform data
In-Reply-To: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1375180657-23641-13-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

All platforms pass the CD GPIO number to the driver in the .cd_gpio
field. The .get_cd() callback isn't used anymore, remove it

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
---
 drivers/mmc/host/tmio_mmc_pio.c | 16 +---------------
 include/linux/mfd/tmio.h        |  1 -
 2 files changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 8486a22..2a7eb5a 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -932,25 +932,11 @@ static int tmio_mmc_get_ro(struct mmc_host *mmc)
 		 (sd_ctrl_read32(host, CTL_STATUS) & TMIO_STAT_WRPROTECT));
 }
 
-static int tmio_mmc_get_cd(struct mmc_host *mmc)
-{
-	struct tmio_mmc_host *host = mmc_priv(mmc);
-	struct tmio_mmc_data *pdata = host->pdata;
-	int ret = mmc_gpio_get_cd(mmc);
-	if (ret >= 0)
-		return ret;
-
-	if (!pdata->get_cd)
-		return -ENOSYS;
-	else
-		return pdata->get_cd(host->pdev);
-}
-
 static const struct mmc_host_ops tmio_mmc_ops = {
 	.request	= tmio_mmc_request,
 	.set_ios	= tmio_mmc_set_ios,
 	.get_ro         = tmio_mmc_get_ro,
-	.get_cd		= tmio_mmc_get_cd,
+	.get_cd		= mmc_gpio_get_cd,
 	.enable_sdio_irq = tmio_mmc_enable_sdio_irq,
 };
 
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index ce35113..b22883d 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -108,7 +108,6 @@ struct tmio_mmc_data {
 	unsigned int			cd_gpio;
 	void (*set_pwr)(struct platform_device *host, int state);
 	void (*set_clk_div)(struct platform_device *host, int state);
-	int (*get_cd)(struct platform_device *host);
 	int (*write16_hook)(struct tmio_mmc_host *host, int addr);
 	/* clock management callbacks */
 	int (*clk_enable)(struct platform_device *pdev, unsigned int *f);
-- 
1.8.1.5



From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 06:37:37 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 12:37:37 +0200
Subject: [PATCH v2 13/13] mmc: tmio-mmc: Remove .set_pwr() callback from
 platform data
In-Reply-To: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <1375180657-23641-14-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The .set_pwr() callback isn't used anymore as all platforms register
GPIO-controlled regulators. Remove it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
---
 drivers/mmc/host/tmio_mmc.h     | 1 -
 drivers/mmc/host/tmio_mmc_pio.c | 7 -------
 include/linux/mfd/tmio.h        | 1 -
 3 files changed, 9 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 86fd21e..39c2f45 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -68,7 +68,6 @@ struct tmio_mmc_host {
 	enum tmio_mmc_power	power;
 
 	/* Callbacks for clock / power control */
-	void (*set_pwr)(struct platform_device *host, int state);
 	void (*set_clk_div)(struct platform_device *host, int state);
 
 	/* pio related stuff */
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 2a7eb5a..4675513 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -777,9 +777,6 @@ static void tmio_mmc_power_on(struct tmio_mmc_host *host, unsigned short vdd)
 
 	/* .set_ios() is returning void, so, no chance to report an error */
 
-	if (host->set_pwr)
-		host->set_pwr(host->pdev, 1);
-
 	if (!IS_ERR(mmc->supply.vmmc)) {
 		ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
 		/*
@@ -809,9 +806,6 @@ static void tmio_mmc_power_off(struct tmio_mmc_host *host)
 
 	if (!IS_ERR(mmc->supply.vmmc))
 		mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
-
-	if (host->set_pwr)
-		host->set_pwr(host->pdev, 0);
 }
 
 /* Set MMC clock / power.
@@ -998,7 +992,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host,
 	_host->pdev = pdev;
 	platform_set_drvdata(pdev, mmc);
 
-	_host->set_pwr = pdata->set_pwr;
 	_host->set_clk_div = pdata->set_clk_div;
 
 	/* SD control register space size is 0x200, 0x400 for bus_shift=1 */
diff --git a/include/linux/mfd/tmio.h b/include/linux/mfd/tmio.h
index b22883d..baa2346 100644
--- a/include/linux/mfd/tmio.h
+++ b/include/linux/mfd/tmio.h
@@ -106,7 +106,6 @@ struct tmio_mmc_data {
 	struct tmio_mmc_dma		*dma;
 	struct device			*dev;
 	unsigned int			cd_gpio;
-	void (*set_pwr)(struct platform_device *host, int state);
 	void (*set_clk_div)(struct platform_device *host, int state);
 	int (*write16_hook)(struct tmio_mmc_host *host, int addr);
 	/* clock management callbacks */
-- 
1.8.1.5



From paul at pwsan.com  Tue Jul 30 06:58:24 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 30 Jul 2013 10:58:24 +0000 (UTC)
Subject: [PATCH] ARM: v6: prevent gcc from reordering extended CP15 reads
 above is_smp() test
In-Reply-To: <20130729100243.GC32383@mudshark.cambridge.arm.com>
References: <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307280538460.8385@utopia.booyaka.com>
 <alpine.DEB.2.02.1307282012280.23852@utopia.booyaka.com>
 <20130729100243.GC32383@mudshark.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1307301056220.8953@utopia.booyaka.com>

Hi Will

On Mon, 29 Jul 2013, Will Deacon wrote:

> I wouldn't worry about checking for CPU_V6. Besides, we probably need this
> to be re-evaluated across barrier() when we get CPU migration on a
> big-little platform anyway (we should probably also drop the
> __attribute_const__ for that).
> 
> So you can just replace the "cc" (now that Nico kindly explained why those
> aren't needed the other day) with "memory".
> 
> An alternative is to add barrier() between is_smp() and the read_cpuid_ext()
> in all callers, adding a fake read from the stack to the latter (like I did
> for the per-cpu accessor). However, this relies on fixing all callers for
> very little gain, so I don't think it's worth the hassle.
> 
> I can cook a patch if you're tied up with other things -- just let me know.

Makes sense to me.  Have respun the patch and will post it shortly.  
Thanks for the extra compiler research; it's been incorporated into the 
patch description and comments.


- Paul


From broonie at kernel.org  Tue Jul 30 07:17:02 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 12:17:02 +0100
Subject: [PATCH] ALSA: ASoC: uda134x: fix codec driver
In-Reply-To: <E1V4712-0007sg-Dw@rmk-PC.arm.linux.org.uk>
References: <E1V4712-0007sg-Dw@rmk-PC.arm.linux.org.uk>
Message-ID: <20130730111701.GN9858@sirena.org.uk>

On Tue, Jul 30, 2013 at 11:18:52AM +0100, Russell King wrote:
> For some reason, the DAC/ADCs are not being powered up when I try and
> use the UDA1341 driver; this used to work.  Looking back in the git
> history, I don't see anything obvious which would cause this
> regression.

Applied, thanks.  I've applied it for v3.12 for now rather than v3.11
since it's a relatively large change but obviously it's a fix and the
driver doesn't work anyway without it so I'm likely to pull it over for
v3.11.
-------------- 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/20130730/424a021a/attachment.sig>

From pullip.cho at samsung.com  Tue Jul 30 07:17:08 2013
From: pullip.cho at samsung.com (Cho KyongHo)
Date: Tue, 30 Jul 2013 20:17:08 +0900
Subject: [PATCH v8 05/12] clk: exynos5250: add gate clock descriptions
 of System MMU
In-Reply-To: <20130730064655.22022.62937@quantum>
References: <003b01ce89f3$2be4db80$83ae9280$@samsung.com>
 <20130726200107.7598.82010@quantum>
 <001901ce8aa8$d1d6fef0$7584fcd0$@samsung.com>
 <20130730064655.22022.62937@quantum>
Message-ID: <003501ce8d16$542dd5d0$fc898170$@samsung.com>

> -----Original Message-----
> From: Mike Turquette [mailto:mturquette at linaro.org]
> Sent: Tuesday, July 30, 2013 3:47 PM
> To: Cho KyongHo; 'Linux ARM Kernel'; 'Linux IOMMU'; 'Linux Kernel'; 'Linux Samsung SOC'
> Cc: 'Kukjin Kim'; 'Hyunwoong Kim'; 'Prathyush'; 'Grant Grundler'; 'Joerg Roedel'; 'Keyyoung Park';
> 'Subash Patel'; 'Sachin Kamat'; 'Thomas Abraham'; 'Antonios Motakis'; kvmarm at lists.cs.columbia.edu;
> 'Rahul Sharma'
> Subject: Re: RE: [PATCH v8 05/12] clk: exynos5250: add gate clock descriptions of System MMU
> 
> Quoting Cho KyongHo (2013-07-27 02:08:11)
> > > -----Original Message-----
> > > From: Mike Turquette [mailto:mturquette at linaro.org]
> > > Sent: Saturday, July 27, 2013 5:01 AM
> > >
> > > Quoting Cho KyongHo (2013-07-26 04:27:54)
> > > > This adds gate clocks of all System MMUs and their master IPs
> > > > that are not apeared in clk-exynos5250.c
> > > >
> > > > Signed-off-by: Cho KyongHo <pullip.cho at samsung.com>
> > >
> > > Change looks good to me. Are you OK if I take it into the clk tree or do
> > > you want to keep this series together?
> >
> > I would like you to pick this to your tree and let me know which branch
> > contains this patch.
> > Then I will remove this from my patch series.
> 
> camif_top corresponds to 345 in your patch, but this conflicts the g2d
> clock introduced in patch "clk: exynos5250: Add G2D gate clock" in the
> clk tree. I've pushed out the latest clk-next branch with this change:
> 
> git://git.linaro.org/people/mturquette/linux.git clk-next
> 
> Can you rebase your change on top of this and resolve the clock id
> mapping?
> 
Oh,
I will rebase this patch on your git in the next patch version.

Thank you.

> Thanks,
> Mike
> 
> >
> > Thank you,
> > Cho KyongHo.
> > >
> > > Regards,
> > > Mike
> > >
> > > > ---
> > > >  .../devicetree/bindings/clock/exynos5250-clock.txt |   28 +++++++++-
> > > >  drivers/clk/samsung/clk-exynos5250.c               |   57 ++++++++++++++++---
> > > >  2 files changed, 75 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > > > b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > > > index 781a627..df49694 100644
> > > > --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > > > +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> > > > @@ -154,7 +154,33 @@ clock which they consume.
> > > >    dsim0                        341
> > > >    dp                   342
> > > >    mixer                        343
> > > > -  hdmi                 345
> > > > +  hdmi                 344
> > > > +  camif_top            345
> > > > +  smmu_fimc_lite0      346
> > > > +  smmu_fimc_lite1      347
> > > > +  smmu_fimc_lite2      348
> > > > +  smmu_tv              349
> > > > +  smmu_fimd1           350
> > > > +  smmu_2d              351
> > > > +  fimc_isp             352
> > > > +  fimc_drc             353
> > > > +  fimc_fd              354
> > > > +  fimc_scc             355
> > > > +  fimc_scp             356
> > > > +  fimc_mcuctl          357
> > > > +  fimc_odc             358
> > > > +  fimc_dis             359
> > > > +  fimc_3dnr            360
> > > > +  smmu_fimc_isp                361
> > > > +  smmu_fimc_drc                362
> > > > +  smmu_fimc_fd         363
> > > > +  smmu_fimc_scc                364
> > > > +  smmu_fimc_scp                365
> > > > +  smmu_fimc_mcuctl     366
> > > > +  smmu_fimc_odc                367
> > > > +  smmu_fimc_dis0       368
> > > > +  smmu_fimc_dis1       369
> > > > +  smmu_fimc_3dnr       370
> > > >
> > > >  Example 1: An example of a clock controller node is listed below.
> > > >
> > > > diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
> > > > index 22d7699..e242bde 100644
> > > > --- a/drivers/clk/samsung/clk-exynos5250.c
> > > > +++ b/drivers/clk/samsung/clk-exynos5250.c
> > > > @@ -53,12 +53,15 @@
> > > >  #define DIV_PERIC3             0x10564
> > > >  #define DIV_PERIC4             0x10568
> > > >  #define DIV_PERIC5             0x1056c
> > > > +#define GATE_IP_ISP0           0x0C800
> > > > +#define GATE_IP_ISP1           0x0C800
> > > >  #define GATE_IP_GSCL           0x10920
> > > >  #define GATE_IP_MFC            0x1092c
> > > >  #define GATE_IP_GEN            0x10934
> > > >  #define GATE_IP_FSYS           0x10944
> > > >  #define GATE_IP_PERIC          0x10950
> > > >  #define GATE_IP_PERIS          0x10960
> > > > +#define GATE_IP_ACP            0x18800
> > > >  #define SRC_CDREX              0x20200
> > > >  #define PLL_DIV2_SEL           0x20a24
> > > >  #define GATE_IP_DISP1          0x10928
> > > > @@ -100,6 +103,14 @@ enum exynos5250_clks {
> > > >         tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
> > > >         wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
> > > >
> > > > +       camif_top, smmu_fimc_lite0, smmu_fimc_lite1, smmu_fimc_lite2,
> > > > +       smmu_tv, smmu_fimd1, smmu_2d,
> > > > +       fimc_isp, fimc_drc, fimc_fd, fimc_scc, fimc_scp, fimc_mcuctl, fimc_odc,
> > > > +       fimc_dis, fimc_3dnr,
> > > > +       smmu_fimc_isp, smmu_fimc_drc, smmu_fimc_fd, smmu_fimc_scc,
> > > > +       smmu_fimc_scp, smmu_fimc_mcuctl, smmu_fimc_odc, smmu_fimc_dis0,
> > > > +       smmu_fimc_dis1, smmu_fimc_3dnr,
> > > > +
> > > >         nr_clks,
> > > >  };
> > > >
> > > > @@ -320,19 +331,26 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
> > > >         GATE(gscl3, "gscl3", "aclk266", GATE_IP_GSCL, 3, 0, 0),
> > > >         GATE(gscl_wa, "gscl_wa", "div_gscl_wa", GATE_IP_GSCL, 5, 0, 0),
> > > >         GATE(gscl_wb, "gscl_wb", "div_gscl_wb", GATE_IP_GSCL, 6, 0, 0),
> > > > -       GATE(smmu_gscl0, "smmu_gscl0", "aclk266", GATE_IP_GSCL, 7, 0, 0),
> > > > -       GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
> > > > -       GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
> > > > -       GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
> > > > +       GATE(smmu_gscl0, "smmu_gscl0", "none", GATE_IP_GSCL, 7, 0, 0),
> > > > +       GATE(smmu_gscl1, "smmu_gscl1", "none", GATE_IP_GSCL, 8, 0, 0),
> > > > +       GATE(smmu_gscl2, "smmu_gscl2", "none", GATE_IP_GSCL, 9, 0, 0),
> > > > +       GATE(smmu_gscl3, "smmu_gscl3", "none", GATE_IP_GSCL, 10, 0, 0),
> > > > +       GATE(camif_top, "camif_top", "aclk266", GATE_IP_GSCL, 4, 0, 0),
> > > > +       GATE(smmu_fimc_lite0, "smmu_fimc_lite0", "none",
> > > > +                                               GATE_IP_GSCL, 12, 0, 0),
> > > > +       GATE(smmu_fimc_lite1, "smmu_fimc_lite1", "none",
> > > > +                                               GATE_IP_GSCL, 13, 0, 0),
> > > > +       GATE(smmu_fimc_lite2, "smmu_fimc_lite2", "none",
> > > > +                                               GATE_IP_GSCL, 14, 0, 0),
> > > >         GATE(mfc, "mfc", "aclk333", GATE_IP_MFC, 0, 0, 0),
> > > > -       GATE(smmu_mfcl, "smmu_mfcl", "aclk333", GATE_IP_MFC, 1, 0, 0),
> > > > -       GATE(smmu_mfcr, "smmu_mfcr", "aclk333", GATE_IP_MFC, 2, 0, 0),
> > > > +       GATE(smmu_mfcr, "smmu_mfcr", "none", GATE_IP_MFC, 1, 0, 0),
> > > > +       GATE(smmu_mfcl, "smmu_mfcl", "none", GATE_IP_MFC, 2, 0, 0),
> > > >         GATE(rotator, "rotator", "aclk266", GATE_IP_GEN, 1, 0, 0),
> > > >         GATE(jpeg, "jpeg", "aclk166", GATE_IP_GEN, 2, 0, 0),
> > > >         GATE(mdma1, "mdma1", "aclk266", GATE_IP_GEN, 4, 0, 0),
> > > > -       GATE(smmu_rotator, "smmu_rotator", "aclk266", GATE_IP_GEN, 6, 0, 0),
> > > > -       GATE(smmu_jpeg, "smmu_jpeg", "aclk166", GATE_IP_GEN, 7, 0, 0),
> > > > -       GATE(smmu_mdma1, "smmu_mdma1", "aclk266", GATE_IP_GEN, 9, 0, 0),
> > > > +       GATE(smmu_rotator, "smmu_rotator", "none", GATE_IP_GEN, 6, 0, 0),
> > > > +       GATE(smmu_jpeg, "smmu_jpeg", "none", GATE_IP_GEN, 7, 0, 0),
> > > > +       GATE(smmu_mdma1, "smmu_mdma1", "none", GATE_IP_GEN, 9, 0, 0),
> > > >         GATE(pdma0, "pdma0", "aclk200", GATE_IP_FSYS, 1, 0, 0),
> > > >         GATE(pdma1, "pdma1", "aclk200", GATE_IP_FSYS, 2, 0, 0),
> > > >         GATE(sata, "sata", "aclk200", GATE_IP_FSYS, 6, 0, 0),
> > > > @@ -462,6 +480,27 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata = {
> > > >         GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
> > > >         GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
> > > >         GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
> > > > +       GATE(smmu_tv, "smmu_tv", "none", GATE_IP_DISP1, 2, 0, 0),
> > > > +       GATE(smmu_fimd1, "smmu_fimd1", "none", GATE_IP_DISP1, 8, 0, 0),
> > > > +
> > > > +       GATE(smmu_fimc_isp, "smmu_fimc_isp", "none", GATE_IP_ISP0, 8, 0, 0),
> > > > +       GATE(smmu_fimc_drc, "smmu_fimc_drc", "none", GATE_IP_ISP0, 9, 0, 0),
> > > > +       GATE(smmu_fimc_fd, "smmu_fimc_fd", "none", GATE_IP_ISP0, 10, 0, 0),
> > > > +       GATE(smmu_fimc_scc, "smmu_fimc_scc", "none",
> > > > +                                                       GATE_IP_ISP0, 11, 0, 0),
> > > > +       GATE(smmu_fimc_scp, "smmu_fimc_scp", "none",
> > > > +                                                       GATE_IP_ISP0, 12, 0, 0),
> > > > +       GATE(smmu_fimc_mcuctl, "smmu_fimc_mcuctl", "none",
> > > > +                                                       GATE_IP_ISP0, 13, 0, 0),
> > > > +       GATE(smmu_fimc_odc, "smmu_fimc_odc", "none", GATE_IP_ISP1, 4, 0, 0),
> > > > +       GATE(smmu_fimc_dis0, "smmu_fimc_dis0", "none",
> > > > +                                                       GATE_IP_ISP1, 5, 0, 0),
> > > > +       GATE(smmu_fimc_dis1, "smmu_fimc_dis1", "none",
> > > > +                                                       GATE_IP_ISP1, 6, 0, 0),
> > > > +       GATE(smmu_fimc_3dnr, "smmu_fimc_3dnr", "none",
> > > > +                                                       GATE_IP_ISP1, 7, 0, 0),
> > > > +
> > > > +       GATE(smmu_2d, "smmu_2d", "none", GATE_IP_ACP, 7, 0, 0),
> > > >  };
> > > >
> > > >  static __initdata struct of_device_id ext_clk_match[] = {
> > > > --
> > > > 1.7.2.5
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > linux-arm-kernel mailing list
> > > > linux-arm-kernel at lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From thomas.petazzoni at free-electrons.com  Tue Jul 30 07:23:18 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 30 Jul 2013 13:23:18 +0200
Subject: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link'
 property
In-Reply-To: <CAGVrzcZC9G2ny5rtojbzxmPu8-6EKQ_3io-+fxi61LLCt4Hk=w@mail.gmail.com>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <CACxGe6td6uM0v5w92xPVCaVH4tP4AJ-h4SnN-mFoz5gSSosnQw@mail.gmail.com>
 <20130730110705.3262bc3d@skate>
 <CAGVrzcZC9G2ny5rtojbzxmPu8-6EKQ_3io-+fxi61LLCt4Hk=w@mail.gmail.com>
Message-ID: <20130730132318.0270fc4b@skate>

Dear Florian Fainelli,

On Tue, 30 Jul 2013 11:05:04 +0100, Florian Fainelli wrote:

> > In fact, this value is used for two things:
> >
> >  * As the PHY address on the fake "fixed" MDIO bus.
> >
> >  * As the PHY identifier, as reported by the MII registers PHYS_ID1
> >    (0x2) and PHYS_ID2 (0x3).
> 
> Right, so I would start with disambiguating the two and just forget
> about PHYS_ID1 and PHYS_ID2 for the moment since they probably do not
> need to be per-PHY configurable.

Agreed.

> > I think this doesn't make sense, because the two things are completely
> > unrelated. Ideally, we'd like the PHY identifier for fixed PHYs to be
> > something fixed, identical for all fixed PHYs. The problem is finding
> > an OUI and device number that is available for that, but maybe we can
> > ask the OpenMoko people to allocate one (see
> > http://wiki.openmoko.org/wiki/OUI).
> 
> Well that would be ideal indeed, but I am wondering if we cannot just
> go with some kind of magic value here anyway, regardless of
> allocations since this is not a real hardware device.

Well, isn't that exactly what I'm proposing? Have a fixed value for
PHYS_ID1 and PHYS_ID2, that is used for /all/ fixed PHYs.

> How about the Linux Foundation?

I am concerned about the time it would take to get a new OUI
attributed. The OpenMoko OUI is said to be open for free and open
source projects, I think the Linux kernel qualifies :)

> Is not that the same problem as with gadget USB
> devices which should have some sort of real MAC address for instance?

They are either provided by the user or generated randomly, as far as I
can see.

> > Then, the PHY address could be generated dynamically. This would
> > require:
> >
> >  * Adding a fixed_phy_create() function that internally uses
> >    fixed_phy_add(), but before that creates an unique PHY address for
> >    this newly created PHY. Those unique addresses will be generated by
> >    incrementing a global number of fixed PHYs, up to PHY_MAX_ADDR,
> >    which is the maximum number of fixed PHYs that can anyway be
> >    registered on the fixed MDIO bus.
> 
> Even though these are purely software PHY implementations, I believe
> that some sort of predictability would be welcome, so I would just use
> the phy_id argument passed to fixed_phy_add() as the address on the
> fixed MDIO bus like it is today.

Well, the whole starting point of this discussion is precisely that
both Grant and Mark disliked this phy ID that had to be globally
unique, and they wanted it to be dynamically allocated by the kernel,
because the DT shouldn't have to care about such internal details.

> > Grant, Mark, Florian, do you have other proposals?
> 
> To sum up, let's just forget about the misuse of phy_id to fill in
> PHYS_ID1 and PHYS_ID2 registers and keep the existing code with a
> clear note that phy_id means the "PHY address on the fixed MDIO bus".

Except that Grant and Mark point was precisely that the "PHY address on
the fake MDIO bus" is not a description of the hardware, and therefore
shouldn't be mentioned in the Device Tree but instead taken care of by
the kernel itself.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From rnayak at ti.com  Tue Jul 30 07:25:39 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 16:55:39 +0530
Subject: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx
 based SoCs'
In-Reply-To: <1375183546-12758-1-git-send-email-rnayak@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
Message-ID: <1375183546-12758-2-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

The DRA7xx is a high-performance, infotainment application device,
based on enhanced OMAP architecture integrated on a 28-nm technology.

DRA7xx family is composed of DRA75x and DRA74x devices.

Adding the DRA752 ES1.0 cpu revision detection support.

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap1/include/mach/soc.h |    1 +
 arch/arm/mach-omap2/id.c               |   30 ++++++++++++++++++++++--
 arch/arm/mach-omap2/soc.h              |   39 ++++++++++++++++++++++++++++++++
 3 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap1/include/mach/soc.h b/arch/arm/mach-omap1/include/mach/soc.h
index 6cf9c1c..612bd1c 100644
--- a/arch/arm/mach-omap1/include/mach/soc.h
+++ b/arch/arm/mach-omap1/include/mach/soc.h
@@ -195,6 +195,7 @@ IS_OMAP_TYPE(1710, 0x1710)
 #define cpu_is_omap34xx()		0
 #define cpu_is_omap44xx()		0
 #define soc_is_omap54xx()		0
+#define soc_is_dra7xx()			0
 #define soc_is_am33xx()			0
 #define cpu_class_is_omap1()		1
 #define cpu_class_is_omap2()		0
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2dc62a2..332ae95 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -61,7 +61,7 @@ int omap_type(void)
 		val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
 	} else if (cpu_is_omap44xx()) {
 		val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
-	} else if (soc_is_omap54xx()) {
+	} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
 		val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
 		val &= OMAP5_DEVICETYPE_MASK;
 		val >>= 6;
@@ -116,7 +116,7 @@ static u16 tap_prod_id;
 
 void omap_get_die_id(struct omap_die_id *odi)
 {
-	if (cpu_is_omap44xx() || soc_is_omap54xx()) {
+	if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
 		odi->id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0);
 		odi->id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1);
 		odi->id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2);
@@ -606,6 +606,32 @@ void __init omap5xxx_check_revision(void)
 	pr_info("%s %s\n", soc_name, soc_rev);
 }
 
+void __init dra7xx_check_revision(void)
+{
+	u32 idcode;
+	u16 hawkeye;
+	u8 rev;
+
+	idcode = read_tap_reg(OMAP_TAP_IDCODE);
+	hawkeye = (idcode >> 12) & 0xffff;
+	rev = (idcode >> 28) & 0xff;
+	switch (hawkeye) {
+	case 0xb990:
+		switch (rev) {
+		case 0:
+		default:
+			omap_revision = DRA752_REV_ES1_0;
+		}
+		break;
+	default:
+		/* Unknown. Default to latest silicon revision */
+		omap_revision = DRA752_REV_ES1_0;
+	}
+
+	pr_info("DRA%03x ES%d.%d\n", omap_rev() >> 16,
+		((omap_rev() >> 12) & 0xf), ((omap_rev() >> 8) & 0xf));
+}
+
 /*
  * Set up things for map_io and processor detection later on. Gets called
  * pretty much first thing from board init. For multi-omap, this gets
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 8c616e4..0d242f1 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -8,6 +8,7 @@
  * Written by Tony Lindgren <tony.lindgren at nokia.com>
  *
  * Added OMAP4/5 specific defines - Santosh Shilimkar<santosh.shilimkar at ti.com>
+ * Added DRA7xxx specific defines - Sricharan R<r.sricharan at ti.com>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -105,6 +106,15 @@
 # endif
 #endif
 
+#ifdef CONFIG_SOC_DRA7XX
+# ifdef OMAP_NAME
+#  undef MULTI_OMAP2
+#  define MULTI_OMAP2
+# else
+#  define OMAP_NAME DRA7XX
+# endif
+#endif
+
 /*
  * Omap device type i.e. EMU/HS/TST/GP/BAD
  */
@@ -145,6 +155,7 @@ static inline int soc_is_omap(void)
  * cpu_is_omap446x():	True for OMAP4460
  * cpu_is_omap447x():	True for OMAP4470
  * soc_is_omap543x():	True for OMAP5430, OMAP5432
+ * soc_is_dra75x():	True for DRA752, DRA754, DRA756
  */
 #define GET_OMAP_CLASS	(omap_rev() & 0xff)
 
@@ -170,6 +181,12 @@ static inline int is_ti ##class (void)		\
 	return (GET_TI_CLASS == (id)) ? 1 : 0;	\
 }
 
+#define IS_DRA_CLASS(class, id)				\
+static inline int is_dra ##class(void)			\
+{							\
+	return (GET_OMAP_CLASS == (id)) ? 1 : 0;	\
+}
+
 #define GET_OMAP_SUBCLASS	((omap_rev() >> 20) & 0x0fff)
 
 #define IS_OMAP_SUBCLASS(subclass, id)			\
@@ -190,6 +207,12 @@ static inline int is_am ##subclass (void)		\
 	return (GET_OMAP_SUBCLASS == (id)) ? 1 : 0;	\
 }
 
+#define IS_DRA_SUBCLASS(subclass, id)			\
+static inline int is_dra ##subclass(void)		\
+{							\
+	return (GET_OMAP_SUBCLASS == (id)) ? 1 : 0;	\
+}
+
 IS_OMAP_CLASS(24xx, 0x24)
 IS_OMAP_CLASS(34xx, 0x34)
 IS_OMAP_CLASS(44xx, 0x44)
@@ -197,6 +220,7 @@ IS_AM_CLASS(35xx, 0x35)
 IS_OMAP_CLASS(54xx, 0x54)
 IS_AM_CLASS(33xx, 0x33)
 IS_AM_CLASS(43xx, 0x43)
+IS_DRA_CLASS(7xx, 0x7)
 
 IS_TI_CLASS(81xx, 0x81)
 
@@ -213,6 +237,8 @@ IS_TI_SUBCLASS(816x, 0x816)
 IS_TI_SUBCLASS(814x, 0x814)
 IS_AM_SUBCLASS(335x, 0x335)
 IS_AM_SUBCLASS(437x, 0x437)
+IS_DRA_SUBCLASS(75x, 0x75)
+IS_DRA_SUBCLASS(74x, 0x74)
 
 #define cpu_is_omap24xx()		0
 #define cpu_is_omap242x()		0
@@ -233,6 +259,8 @@ IS_AM_SUBCLASS(437x, 0x437)
 #define cpu_is_omap447x()		0
 #define soc_is_omap54xx()		0
 #define soc_is_omap543x()		0
+#define soc_is_dra7xx()			0
+#define soc_is_dra75x()			0
 
 #if defined(MULTI_OMAP2)
 # if defined(CONFIG_ARCH_OMAP2)
@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
 # define soc_is_omap543x()		is_omap543x()
 #endif
 
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()		is_dra7xx()
+# define soc_is_dra75x()		is_dra75x()
+#endif
+
 /* Various silicon revisions for omap2 */
 #define OMAP242X_CLASS		0x24200024
 #define OMAP2420_REV_ES1_0	OMAP242X_CLASS
@@ -443,6 +478,9 @@ IS_OMAP_TYPE(3430, 0x3430)
 #define OMAP5432_REV_ES1_0	(OMAP54XX_CLASS | (0x32 << 16) | (0x10 << 8))
 #define OMAP5432_REV_ES2_0	(OMAP54XX_CLASS | (0x32 << 16) | (0x20 << 8))
 
+#define DRA7XX_CLASS		0x07000007
+#define DRA752_REV_ES1_0	(DRA7XX_CLASS | (0x52 << 16) | (0x10 << 8))
+
 void omap2xxx_check_revision(void);
 void omap3xxx_check_revision(void);
 void omap4xxx_check_revision(void);
@@ -451,6 +489,7 @@ void omap3xxx_check_features(void);
 void ti81xx_check_features(void);
 void am33xx_check_features(void);
 void omap4xxx_check_features(void);
+void dra7xx_check_revision(void);
 
 /*
  * Runtime detection of OMAP3 features
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul 30 07:25:38 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 16:55:38 +0530
Subject: [PATCH v2 0/8] DRA7xx core support
Message-ID: <1375183546-12758-1-git-send-email-rnayak@ti.com>

Changes in v2:
-1- Fixed minor changelog details
-2- Dropped the SRAM support patch since we need to move to drivers/misc/sram.c
-3- Added DTS update patches to this series which were earlier posted as
part of the data series (Since they don't have much objections as against the
other in-kernel data files)
-4- Updated the EVM dts file with pin config details for uart/mcspi and i2c

DRA7xx based SoCs' are high-performance, infotainment application devices,
based on enhanced OMAP architecture integrated on a 28nm
technology.

The DRA7xx family is composed of DRA75x and DRA74x devices.
The current device for which the patches add support is the
DRA752 SoC.

Most of the core IPs are similar to those found on the OMAP5
devices, including the dual cortex-A15 based MPU subsystem,
which has helped quite some reuse from existing OMAP5 support.

This series contains only core support patches and none of
the PRCM and hwmod data needed for the device to boot.

The bootloader support for the platform is already available
in mainline u-boot.

The patches posted in this series are available at:
git://github.com/rrnayak/linux.git for-3.12/dra-core-v2

The patches (including the ones for in-kernel data) which boot
on dra7xx evm are available at:
t://github.com/rrnayak/linux.git out-of-tree/dra-integrated-v2

R Sricharan (7):
  ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
  ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
  ARM: DRA7: Reuse io tables and add a new .init_early
  ARM: DRA7: Resue the clocksource, clockevent support
  ARM: DRA7: board-generic: Add basic DT support
  ARM: DRA7: Kconfig: Make ARCH_NR_GPIO default to 512
  ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board

Rajendra Nayak (1):
  ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5

 .../devicetree/bindings/arm/omap/omap.txt          |    3 +
 arch/arm/Kconfig                                   |    2 +-
 arch/arm/boot/dts/Makefile                         |    3 +-
 arch/arm/boot/dts/dra7-evm.dts                     |  163 +++++++
 arch/arm/boot/dts/dra7.dtsi                        |  488 ++++++++++++++++++++
 arch/arm/mach-omap1/include/mach/soc.h             |    1 +
 arch/arm/mach-omap2/Kconfig                        |    2 +-
 arch/arm/mach-omap2/Makefile                       |    8 +
 arch/arm/mach-omap2/board-generic.c                |   18 +
 arch/arm/mach-omap2/common.h                       |    1 +
 arch/arm/mach-omap2/id.c                           |   30 +-
 arch/arm/mach-omap2/io.c                           |   22 +-
 arch/arm/mach-omap2/omap54xx.h                     |    4 +
 arch/arm/mach-omap2/omap_hwmod.c                   |    2 +-
 arch/arm/mach-omap2/soc.h                          |   39 ++
 arch/arm/mach-omap2/timer.c                        |    3 +-
 16 files changed, 780 insertions(+), 9 deletions(-)
 create mode 100644 arch/arm/boot/dts/dra7-evm.dts
 create mode 100644 arch/arm/boot/dts/dra7.dtsi

-- 
1.7.9.5



From rnayak at ti.com  Tue Jul 30 07:25:40 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 16:55:40 +0530
Subject: [PATCH v2 2/8] ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5
In-Reply-To: <1375183546-12758-1-git-send-email-rnayak@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
Message-ID: <1375183546-12758-3-git-send-email-rnayak@ti.com>

The soc_ops for dra7xx devices can be completed reused
from the ones used for omap4 and omap5 devices.

Signed-off-by: Rajendra Nayak <rnayak at ti.com>
Signed-off-by: R Sricharan <r.sricharan at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7341eff..f6eb29b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -4113,7 +4113,7 @@ void __init omap_hwmod_init(void)
 		soc_ops.assert_hardreset = _omap2_assert_hardreset;
 		soc_ops.deassert_hardreset = _omap2_deassert_hardreset;
 		soc_ops.is_hardreset_asserted = _omap2_is_hardreset_asserted;
-	} else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
+	} else if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
 		soc_ops.enable_module = _omap4_enable_module;
 		soc_ops.disable_module = _omap4_disable_module;
 		soc_ops.wait_target_ready = _omap4_wait_target_ready;
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul 30 07:25:41 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 16:55:41 +0530
Subject: [PATCH v2 3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
In-Reply-To: <1375183546-12758-1-git-send-email-rnayak@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
Message-ID: <1375183546-12758-4-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

The PRCM and MPUSS parts of DRA7 devices are quite identical
to OMAP5 so as to reuse all the existing infrastructure around it.
Makefile updates to do just that.

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/Makefile |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d4f6715..17fb8b7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common)
 obj-$(CONFIG_SOC_AM33XX) += irq.o $(hwmod-common)
 obj-$(CONFIG_SOC_OMAP5)	 += prm44xx.o $(hwmod-common) $(secure-common)
 obj-$(CONFIG_SOC_AM43XX) += $(hwmod-common) $(secure-common)
+obj-$(CONFIG_SOC_DRA7XX) += prm44xx.o $(hwmod-common) $(secure-common)
 
 ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),)
 obj-y += mcbsp.o
@@ -39,6 +40,7 @@ omap-4-5-common				=  omap4-common.o omap-wakeupgen.o
 obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-4-5-common) $(smp-y) sleep44xx.o
 obj-$(CONFIG_SOC_OMAP5)			+= $(omap-4-5-common) $(smp-y) sleep44xx.o
 obj-$(CONFIG_SOC_AM43XX)		+= $(omap-4-5-common)
+obj-$(CONFIG_SOC_DRA7XX)		+= $(omap-4-5-common) $(smp-y)
 
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_omap-headsmp.o			:=-Wa,-march=armv7-a$(plus_sec)
@@ -87,6 +89,7 @@ obj-$(CONFIG_ARCH_OMAP2)		+= sleep24xx.o
 obj-$(CONFIG_ARCH_OMAP3)		+= pm34xx.o sleep34xx.o
 obj-$(CONFIG_ARCH_OMAP4)		+= pm44xx.o omap-mpuss-lowpower.o
 obj-$(CONFIG_SOC_OMAP5)			+= omap-mpuss-lowpower.o
+obj-$(CONFIG_SOC_DRA7XX)		+= omap-mpuss-lowpower.o
 obj-$(CONFIG_PM_DEBUG)			+= pm-debug.o
 
 obj-$(CONFIG_POWER_AVS_OMAP)		+= sr_device.o
@@ -114,6 +117,7 @@ omap-prcm-4-5-common			=  cminst44xx.o cm44xx.o prm44xx.o \
 					   vc44xx_data.o vp44xx_data.o
 obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-prcm-4-5-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(omap-prcm-4-5-common)
+obj-$(CONFIG_SOC_DRA7XX)		+= $(omap-prcm-4-5-common)
 
 # OMAP voltage domains
 voltagedomain-common			:= voltage.o vc.o vp.o
@@ -143,6 +147,7 @@ obj-$(CONFIG_SOC_AM33XX)		+= powerdomains33xx_data.o
 obj-$(CONFIG_SOC_AM43XX)		+= $(powerdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(powerdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= powerdomains54xx_data.o
+obj-$(CONFIG_SOC_DRA7XX)		+= $(powerdomain-common)
 
 # PRCM clockdomain control
 clockdomain-common			+= clockdomain.o
@@ -160,6 +165,7 @@ obj-$(CONFIG_SOC_AM33XX)		+= clockdomains33xx_data.o
 obj-$(CONFIG_SOC_AM43XX)		+= $(clockdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(clockdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= clockdomains54xx_data.o
+obj-$(CONFIG_SOC_DRA7XX)		+= $(clockdomain-common)
 
 # Clock framework
 obj-$(CONFIG_ARCH_OMAP2)		+= $(clock-common) clock2xxx.o
@@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)		+= $(clock-common) dpll3xxx.o
 obj-$(CONFIG_SOC_AM33XX)		+= cclock33xx_data.o
 obj-$(CONFIG_SOC_OMAP5)			+= $(clock-common)
 obj-$(CONFIG_SOC_OMAP5)			+= dpll3xxx.o dpll44xx.o
+obj-$(CONFIG_SOC_DRA7XX)		+= $(clock-common)
+obj-$(CONFIG_SOC_DRA7XX)		+= dpll3xxx.o dpll44xx.o
 
 # OMAP2 clock rate set data (old "OPP" data)
 obj-$(CONFIG_SOC_OMAP2420)		+= opp2420_data.o
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul 30 07:25:43 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 16:55:43 +0530
Subject: [PATCH v2 5/8] ARM: DRA7: Resue the clocksource, clockevent support
In-Reply-To: <1375183546-12758-1-git-send-email-rnayak@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
Message-ID: <1375183546-12758-6-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

All of OMAP5 timer support for clocksource and clockevent is completely
reused across DRA7.

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/Kconfig |    2 +-
 arch/arm/mach-omap2/timer.c |    3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 3eed000..fc6ec23 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -132,7 +132,7 @@ config SOC_HAS_OMAP2_SDRC
 
 config SOC_HAS_REALTIME_COUNTER
 	bool "Real time free running counter"
-	depends on SOC_OMAP5
+	depends on SOC_OMAP5 || SOC_DRA7XX
 	default y
 
 comment "OMAP Core Type"
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b37e1fc..1e77f11 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -594,7 +594,8 @@ OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL,
 		       1, "timer_sys_ck", "ti,timer-alwon");
 #endif
 
-#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
+	defined(CONFIG_SOC_DRA7XX)
 static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
 			       2, "sys_clkin_ck", NULL);
 #endif
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul 30 07:25:42 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 16:55:42 +0530
Subject: [PATCH v2 4/8] ARM: DRA7: Reuse io tables and add a new .init_early
In-Reply-To: <1375183546-12758-1-git-send-email-rnayak@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
Message-ID: <1375183546-12758-5-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

The IO descriptor tables for DRA7 are a complete reuse from OMAP5.
A new dra7xx_init_early() does the base address inits.

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/mach-omap2/common.h   |    1 +
 arch/arm/mach-omap2/io.c       |   22 ++++++++++++++++++++--
 arch/arm/mach-omap2/omap54xx.h |    4 ++++
 3 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index dfcc182..4a5684b 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -110,6 +110,7 @@ void omap3630_init_late(void);
 void am35xx_init_late(void);
 void ti81xx_init_late(void);
 int omap2_common_pm_late_init(void);
+void dra7xx_init_early(void);
 
 #ifdef CONFIG_SOC_BUS
 void omap_soc_device_init(void);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4a3f06f..44aa4f0 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -251,7 +251,7 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
 };
 #endif
 
-#ifdef	CONFIG_SOC_OMAP5
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
 static struct map_desc omap54xx_io_desc[] __initdata = {
 	{
 		.virtual	= L3_54XX_VIRT,
@@ -333,7 +333,7 @@ void __init omap4_map_io(void)
 }
 #endif
 
-#ifdef CONFIG_SOC_OMAP5
+#if defined(CONFIG_SOC_OMAP5) ||  defined(CONFIG_SOC_DRA7XX)
 void __init omap5_map_io(void)
 {
 	iotable_init(omap54xx_io_desc, ARRAY_SIZE(omap54xx_io_desc));
@@ -653,6 +653,24 @@ void __init omap5_init_early(void)
 }
 #endif
 
+#ifdef CONFIG_SOC_DRA7XX
+void __init dra7xx_init_early(void)
+{
+	omap2_set_globals_tap(DRA7XX_CLASS,
+			      OMAP2_L4_IO_ADDRESS(DRA7XX_TAP_BASE));
+	omap2_set_globals_control(OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
+				  OMAP2_L4_IO_ADDRESS(DRA7XX_CTRL_BASE));
+	omap2_set_globals_prm(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE));
+	omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(DRA7XX_CM_CORE_AON_BASE),
+			     OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE));
+	omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
+	omap_prm_base_init();
+	omap_cm_base_init();
+	dra7xx_check_revision();
+}
+#endif
+
+
 void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
 				      struct omap_sdrc_params *sdrc_cs1)
 {
diff --git a/arch/arm/mach-omap2/omap54xx.h b/arch/arm/mach-omap2/omap54xx.h
index a086ba1..2d35c57 100644
--- a/arch/arm/mach-omap2/omap54xx.h
+++ b/arch/arm/mach-omap2/omap54xx.h
@@ -30,4 +30,8 @@
 #define OMAP54XX_CTRL_BASE		0x4a002800
 #define OMAP54XX_SAR_RAM_BASE		0x4ae26000
 
+#define DRA7XX_CM_CORE_AON_BASE		0x4a005000
+#define DRA7XX_CTRL_BASE		0x4a003400
+#define DRA7XX_TAP_BASE			0x4ae0c000
+
 #endif /* __ASM_SOC_OMAP555554XX_H */
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul 30 07:25:44 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 16:55:44 +0530
Subject: [PATCH v2 6/8] ARM: DRA7: board-generic: Add basic DT support
In-Reply-To: <1375183546-12758-1-git-send-email-rnayak@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
Message-ID: <1375183546-12758-7-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

Describe minimal DT boot machine details for DRA7xx based SoC's. DRA7xx
family is based on dual core ARM CORTEX A15 using GIC as the interrupt controller.
The PRCM and timer infrastructure is reused from OMAP5 and so are the io
descriptor tables.

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 .../devicetree/bindings/arm/omap/omap.txt          |    3 +++
 arch/arm/mach-omap2/board-generic.c                |   18 ++++++++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 6d498c7..91b7049 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -59,3 +59,6 @@ Boards:
 
 - AM43x EPOS EVM
   compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
+
+- DRA7 EVM:  Software Developement Board for DRA7XX
+  compatible = "ti,dra7-evm", "ti,dra7"
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index be5d005..b89e55b 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -222,3 +222,21 @@ DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device Tree)")
 	.dt_compat	= am43_boards_compat,
 MACHINE_END
 #endif
+
+#ifdef CONFIG_SOC_DRA7XX
+static const char *dra7xx_boards_compat[] __initdata = {
+	"ti,dra7",
+	NULL,
+};
+
+DT_MACHINE_START(DRA7XX_DT, "Generic DRA7XX (Flattened Device Tree)")
+	.reserve	= omap_reserve,
+	.smp		= smp_ops(omap4_smp_ops),
+	.map_io		= omap5_map_io,
+	.init_early	= dra7xx_init_early,
+	.init_irq	= omap_gic_of_init,
+	.init_machine	= omap_generic_init,
+	.init_time	= omap5_realtime_timer_init,
+	.dt_compat	= dra7xx_boards_compat,
+MACHINE_END
+#endif
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul 30 07:25:45 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 16:55:45 +0530
Subject: [PATCH v2 7/8] ARM: DRA7: Kconfig: Make ARCH_NR_GPIO default to 512
In-Reply-To: <1375183546-12758-1-git-send-email-rnayak@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
Message-ID: <1375183546-12758-8-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

DRA7xx has 8 GPIO banks so that there are 32x8 = 256 GPIOs.
In order for the gpiolib to detect and initialize these
and other TWL GPIOs, ARCH_NR_GPIO is set to 512 using the
kconfig default for DRA7.

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
---
 arch/arm/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 37c0f4e..b9e64f2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1600,7 +1600,7 @@ config LOCAL_TIMERS
 config ARCH_NR_GPIO
 	int
 	default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
-	default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5
+	default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX
 	default 392 if ARCH_U8500
 	default 352 if ARCH_VT8500
 	default 288 if ARCH_SUNXI
-- 
1.7.9.5



From rnayak at ti.com  Tue Jul 30 07:25:46 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 16:55:46 +0530
Subject: [PATCH v2 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC and
 dra7-evm board
In-Reply-To: <1375183546-12758-1-git-send-email-rnayak@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
Message-ID: <1375183546-12758-9-git-send-email-rnayak@ti.com>

From: R Sricharan <r.sricharan at ti.com>

Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved. Also added in the board file are pin configuration
details for i2c, mcspi and uart devices on board.

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Rajendra Nayak <rnayak at ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar at ti.com>
---
 arch/arm/boot/dts/Makefile     |    3 +-
 arch/arm/boot/dts/dra7-evm.dts |  163 ++++++++++++++
 arch/arm/boot/dts/dra7.dtsi    |  488 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 653 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/dra7-evm.dts
 create mode 100644 arch/arm/boot/dts/dra7.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..e2f8566 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -173,7 +173,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
 	am335x-bone.dtb \
 	am3517-evm.dtb \
 	am3517_mt_ventoux.dtb \
-	am43x-epos-evm.dtb
+	am43x-epos-evm.dtb \
+	dra7-evm.dtb
 dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
 dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
 dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
new file mode 100644
index 0000000..7b0b563
--- /dev/null
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -0,0 +1,163 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "dra7.dtsi"
+
+/ {
+	model = "TI DRA7";
+	compatible = "ti,dra7-evm", "ti,dra7";
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x60000000>; /* 1536 MB */
+	};
+};
+
+&dra7_pmx_core {
+	i2c1_pins: pinmux_i2c1_pins {
+		pinctrl-single,pins = <
+			0x400 0x60000	/* i2c1_sda */
+			0x404 0x60000	/* i2c1_scl */
+		>;
+	};
+
+	i2c2_pins: pinmux_i2c2_pins {
+		pinctrl-single,pins = <
+			0x408 0x60000	/* i2c2_sda */
+			0x40c 0x60000	/* i2c2_scl */
+		>;
+	};
+
+	i2c3_pins: pinmux_i2c3_pins {
+		pinctrl-single,pins = <
+			0x410 0x60000	/* i2c3_sda */
+			0x414 0x60000	/* i2c3_scl */
+		>;
+	};
+
+	mcspi1_pins: pinmux_mcspi1_pins {
+		pinctrl-single,pins = <
+			0x3a4 0x40000	/* spi2_clk */
+			0x3a8 0x40000	/* spi2_d1 */
+			0x3ac 0x40000	/* spi2_d0 */
+			0x3b0 0xc0000	/* spi2_cs0 */
+			0x3b4 0xc0000	/* spi2_cs1 */
+			0x3b8 0xe0006	/* spi2_cs2 */
+			0x3bc 0xe0006	/* spi2_cs3 */
+		>;
+	};
+
+	mcspi2_pins: pinmux_mcspi2_pins {
+		pinctrl-single,pins = <
+			0x3c0 0x40000	/* spi2_sclk */
+			0x3c4 0xc0000	/* spi2_d1 */
+			0x3c8 0xc0000	/* spi2_d1 */
+			0x3cc 0xe0000	/* spi2_cs0 */
+		>;
+	};
+
+	uart1_pins: pinmux_uart1_pins {
+		pinctrl-single,pins = <
+			0x3e0 0xe0000	/* uart1_rxd */
+			0x3e4 0xe0000	/* uart1_txd */
+			0x3e8 0x60003	/* uart1_ctsn */
+			0x3ec 0x60003	/* uart1_rtsn */
+		>;
+	};
+
+	uart2_pins: pinmux_uart2_pins {
+		pinctrl-single,pins = <
+			0x3f0 0x60000 /* uart2_rxd */
+			0x3f4 0x60000 /* uart2_txd */
+			0x3f8 0x60000 /* uart2_ctsn */
+			0x3fc 0x60000 /* uart2_rtsn */
+		>;
+	};
+
+	uart3_pins: pinmux_uart3_pins {
+		pinctrl-single,pins = <
+			0x248 0xc0000 /* uart3_rxd */
+			0x24c 0xc0000 /* uart3_txd */
+		>;
+	};
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;
+
+	clock-frequency = <400000>;
+};
+
+&i2c2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c2_pins>;
+
+	clock-frequency = <400000>;
+};
+
+&i2c3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c3_pins>;
+
+	clock-frequency = <3400000>;
+};
+
+&i2c4 {
+	status = "disabled";
+};
+
+&i2c5 {
+	status = "disabled";
+};
+
+&mcspi1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mcspi1_pins>;
+};
+
+&mcspi2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mcspi2_pins>;
+};
+
+&mcspi3 {
+	status = "disabled";
+};
+
+&mcspi4 {
+	status = "disabled";
+};
+
+&uart1 {
+        pinctrl-names = "default";
+        pinctrl-0 = <&uart1_pins>;
+};
+
+&uart2 {
+        pinctrl-names = "default";
+        pinctrl-0 = <&uart2_pins>;
+};
+
+&uart3 {
+        pinctrl-names = "default";
+        pinctrl-0 = <&uart3_pins>;
+};
+
+&uart4 {
+	status = "disabled";
+};
+
+&uart5 {
+	status = "disabled";
+};
+
+&uart6 {
+	status = "disabled";
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
new file mode 100644
index 0000000..8a0c08e
--- /dev/null
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -0,0 +1,488 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * Based on "omap4.dtsi"
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "ti,dra7xx";
+	interrupt-parent = <&gic>;
+
+	aliases {
+		serial0 = &uart1;
+		serial1 = &uart2;
+		serial2 = &uart3;
+		serial3 = &uart4;
+		serial4 = &uart5;
+		serial5 = &uart6;
+	};
+
+	cpus {
+		cpu at 0 {
+			compatible = "arm,cortex-a15";
+			timer {
+				compatible = "arm,armv7-timer";
+				/*
+				 * PPI secure/nonsecure IRQ,
+				 * active low level-sensitive
+				 */
+				interrupts = <1 13 0x308>,
+					     <1 14 0x308>;
+				clock-frequency = <6144000>;
+			};
+		};
+		cpu at 1 {
+			compatible = "arm,cortex-a15";
+			timer {
+				compatible = "arm,armv7-timer";
+				/*
+				 * PPI secure/nonsecure IRQ,
+				 * active low level-sensitive
+				 */
+				interrupts = <1 13 0x308>,
+					     <1 14 0x308>;
+				clock-frequency = <6144000>;
+			};
+		};
+	};
+
+	gic: interrupt-controller at 48211000 {
+		compatible = "arm,cortex-a15-gic";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		reg = <0x48211000 0x1000>,
+		      <0x48212000 0x1000>;
+	};
+
+	/*
+	 * The soc node represents the soc top level view. It is uses for IPs
+	 * that are not memory mapped in the MPU view or for the MPU itself.
+	 */
+	soc {
+		compatible = "ti,omap-infra";
+		mpu {
+			compatible = "ti,omap5-mpu";
+			ti,hwmods = "mpu";
+		};
+	};
+
+	/*
+	 * XXX: Use a flat representation of the SOC interconnect.
+	 * The real OMAP interconnect network is quite complex.
+	 * Since that will not bring real advantage to represent that in DT for
+	 * the moment, just use a fake OCP bus entry to represent the whole bus
+	 * hierarchy.
+	 */
+	ocp {
+		compatible = "ti,omap4-l3-noc", "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		ti,hwmods = "l3_main_1", "l3_main_2";
+
+		counter32k: counter at 4ae04000 {
+			compatible = "ti,omap-counter32k";
+			reg = <0x4ae04000 0x40>;
+			ti,hwmods = "counter_32k";
+		};
+
+		dra7_pmx_core: pinmux at 4a003400 {
+			compatible = "pinctrl-single";
+			reg = <0x4a003400 0x0464>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			pinctrl-single,register-width = <32>;
+			pinctrl-single,function-mask = <0x3fffffff>;
+		};
+
+		sdma: dma-controller at 4a056000 {
+			compatible = "ti,omap4430-sdma";
+			reg = <0x4a056000 0x1000>;
+			interrupts = <0 12 0x4>,
+				     <0 13 0x4>,
+				     <0 14 0x4>,
+				     <0 15 0x4>;
+			#dma-cells = <1>;
+			#dma-channels = <32>;
+			#dma-requests = <127>;
+		};
+
+		gpio1: gpio at 4ae10000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x4ae10000 0x200>;
+			interrupts = <0 29 0x4>;
+			ti,hwmods = "gpio1";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio2: gpio at 48055000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48055000 0x200>;
+			interrupts = <0 30 0x4>;
+			ti,hwmods = "gpio2";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio3: gpio at 48057000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48057000 0x200>;
+			interrupts = <0 31 0x4>;
+			ti,hwmods = "gpio3";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio4: gpio at 48059000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48059000 0x200>;
+			interrupts = <0 32 0x4>;
+			ti,hwmods = "gpio4";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio5: gpio at 4805b000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x4805b000 0x200>;
+			interrupts = <0 33 0x4>;
+			ti,hwmods = "gpio5";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio6: gpio at 4805d000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x4805d000 0x200>;
+			interrupts = <0 34 0x4>;
+			ti,hwmods = "gpio6";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio7: gpio at 48051000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48051000 0x200>;
+			interrupts = <0 35 0x4>;
+			ti,hwmods = "gpio7";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		gpio8: gpio at 48053000 {
+			compatible = "ti,omap4-gpio";
+			reg = <0x48053000 0x200>;
+			interrupts = <0 121 0x4>;
+			ti,hwmods = "gpio8";
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+		};
+
+		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,omap4-uart";
+			reg = <0x48066000 0x100>;
+			interrupts = <0 105 0x4>;
+			ti,hwmods = "uart5";
+			clock-frequency = <48000000>;
+		};
+
+		uart6: serial at 48068000 {
+			compatible = "ti,omap4-uart";
+			reg = <0x48068000 0x100>;
+			interrupts = <0 106 0x4>;
+			ti,hwmods = "uart6";
+			clock-frequency = <48000000>;
+		};
+
+		timer1: timer at 4ae18000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x4ae18000 0x80>;
+			interrupts = <0 37 0x4>;
+			ti,hwmods = "timer1";
+			ti,timer-alwon;
+		};
+
+		timer2: timer at 48032000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48032000 0x80>;
+			interrupts = <0 38 0x4>;
+			ti,hwmods = "timer2";
+		};
+
+		timer3: timer at 48034000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48034000 0x80>;
+			interrupts = <0 39 0x4>;
+			ti,hwmods = "timer3";
+		};
+
+		timer4: timer at 48036000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48036000 0x80>;
+			interrupts = <0 40 0x4>;
+			ti,hwmods = "timer4";
+		};
+
+		timer5: timer at 48820000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48820000 0x80>;
+			interrupts = <0 41 0x4>;
+			ti,hwmods = "timer5";
+			ti,timer-dsp;
+		};
+
+		timer6: timer at 48822000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48822000 0x80>;
+			interrupts = <0 42 0x4>;
+			ti,hwmods = "timer6";
+			ti,timer-dsp;
+			ti,timer-pwm;
+		};
+
+		timer7: timer at 48824000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48824000 0x80>;
+			interrupts = <0 43 0x4>;
+			ti,hwmods = "timer7";
+			ti,timer-dsp;
+		};
+
+		timer8: timer at 48826000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48826000 0x80>;
+			interrupts = <0 44 0x4>;
+			ti,hwmods = "timer8";
+			ti,timer-dsp;
+			ti,timer-pwm;
+		};
+
+		timer9: timer at 4803e000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x4803e000 0x80>;
+			interrupts = <0 45 0x4>;
+			ti,hwmods = "timer9";
+		};
+
+		timer10: timer at 48086000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48086000 0x80>;
+			interrupts = <0 46 0x4>;
+			ti,hwmods = "timer10";
+		};
+
+		timer11: timer at 48088000 {
+			compatible = "ti,omap5430-timer";
+			reg = <0x48088000 0x80>;
+			interrupts = <0 47 0x4>;
+			ti,hwmods = "timer11";
+			ti,timer-pwm;
+		};
+
+		wdt2: wdt at 4ae14000 {
+			compatible = "ti,omap4-wdt";
+			reg = <0x4ae14000 0x80>;
+			interrupts = <0 80 0x4>;
+			ti,hwmods = "wd_timer2";
+		};
+
+		i2c1: i2c at 48070000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x48070000 0x100>;
+			interrupts = <0 56 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c1";
+		};
+
+		i2c2: i2c at 48072000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x48072000 0x100>;
+			interrupts = <0 57 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c2";
+		};
+
+		i2c3: i2c at 48060000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x48060000 0x100>;
+			interrupts = <0 61 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c3";
+		};
+
+		i2c4: i2c at 4807a000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x4807a000 0x100>;
+			interrupts = <0 62 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c4";
+		};
+
+		i2c5: i2c at 4807c000 {
+			compatible = "ti,omap4-i2c";
+			reg = <0x4807c000 0x100>;
+			interrupts = <0 60 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "i2c5";
+		};
+
+		mmc1: mmc at 4809c000 {
+			compatible = "ti,omap4-hsmmc";
+			reg = <0x4809c000 0x400>;
+			interrupts = <0 83 0x4>;
+			ti,hwmods = "mmc1";
+			ti,dual-volt;
+			ti,needs-special-reset;
+			dmas = <&sdma 61>, <&sdma 62>;
+			dma-names = "tx", "rx";
+		};
+
+		mmc2: mmc at 480b4000 {
+			compatible = "ti,omap4-hsmmc";
+			reg = <0x480b4000 0x400>;
+			interrupts = <0 86 0x4>;
+			ti,hwmods = "mmc2";
+			ti,needs-special-reset;
+			dmas = <&sdma 47>, <&sdma 48>;
+			dma-names = "tx", "rx";
+		};
+
+		mmc3: mmc at 480ad000 {
+			compatible = "ti,omap4-hsmmc";
+			reg = <0x480ad000 0x400>;
+			interrupts = <0 94 0x4>;
+			ti,hwmods = "mmc3";
+			ti,needs-special-reset;
+			dmas = <&sdma 77>, <&sdma 78>;
+			dma-names = "tx", "rx";
+		};
+
+		mmc4: mmc at 480d1000 {
+			compatible = "ti,omap4-hsmmc";
+			reg = <0x480d1000 0x400>;
+			interrupts = <0 96 0x4>;
+			ti,hwmods = "mmc4";
+			ti,needs-special-reset;
+			dmas = <&sdma 57>, <&sdma 58>;
+			dma-names = "tx", "rx";
+		};
+
+		mcspi1: spi at 48098000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x48098000 0x200>;
+			interrupts = <0 65 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi1";
+			ti,spi-num-cs = <4>;
+			dmas = <&sdma 35>,
+			       <&sdma 36>,
+			       <&sdma 37>,
+			       <&sdma 38>,
+			       <&sdma 39>,
+			       <&sdma 40>,
+			       <&sdma 41>,
+			       <&sdma 42>;
+			dma-names = "tx0", "rx0", "tx1", "rx1",
+				    "tx2", "rx2", "tx3", "rx3";
+		};
+
+		mcspi2: spi at 4809a000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x4809a000 0x200>;
+			interrupts = <0 66 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi2";
+			ti,spi-num-cs = <2>;
+			dmas = <&sdma 43>,
+			       <&sdma 44>,
+			       <&sdma 45>,
+			       <&sdma 46>;
+			dma-names = "tx0", "rx0", "tx1", "rx1";
+		};
+
+		mcspi3: spi at 480b8000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x480b8000 0x200>;
+			interrupts = <0 91 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi3";
+			ti,spi-num-cs = <2>;
+			dmas = <&sdma 15>, <&sdma 16>;
+			dma-names = "tx0", "rx0";
+		};
+
+		mcspi4: spi at 480ba000 {
+			compatible = "ti,omap4-mcspi";
+			reg = <0x480ba000 0x200>;
+			interrupts = <0 48 0x4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			ti,hwmods = "mcspi4";
+			ti,spi-num-cs = <1>;
+			dmas = <&sdma 70>, <&sdma 71>;
+			dma-names = "tx0", "rx0";
+		};
+	};
+};
-- 
1.7.9.5



From broonie at kernel.org  Tue Jul 30 07:28:16 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 12:28:16 +0100
Subject: [PATCH v6 1/8] ASoC: wm8731: add rates constraints
In-Reply-To: <1375178392-26060-2-git-send-email-richard.genoud@gmail.com>
References: <1375178392-26060-1-git-send-email-richard.genoud@gmail.com>
 <1375178392-26060-2-git-send-email-richard.genoud@gmail.com>
Message-ID: <20130730112816.GO9858@sirena.org.uk>

On Tue, Jul 30, 2013 at 11:59:45AM +0200, Richard Genoud wrote:
> Depending on the mclk (or crystal) selected, the wm8731 codec have some
> constraints on its data sampling rates:
> e.g. with a 12.288MHz or 18.432MHz crystal, the authorized rates are
> 8KHz, 32KHz, 48KHz and 96KHz.

Applied, thanks.
-------------- 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/20130730/cadd91ea/attachment.sig>

From broonie at kernel.org  Tue Jul 30 07:29:49 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 12:29:49 +0100
Subject: [PATCH v6 1/8] ASoC: wm8731: add rates constraints
In-Reply-To: <1375180329-4860-2-git-send-email-richard.genoud@gmail.com>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
 <1375180329-4860-2-git-send-email-richard.genoud@gmail.com>
Message-ID: <20130730112949.GP9858@sirena.org.uk>

On Tue, Jul 30, 2013 at 12:32:02PM +0200, Richard Genoud wrote:
> Depending on the mclk (or crystal) selected, the wm8731 codec have some
> constraints on its data sampling rates:
> e.g. with a 12.288MHz or 18.432MHz crystal, the authorized rates are
> 8KHz, 32KHz, 48KHz and 96KHz.

Applied, thanks.
-------------- 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/20130730/8b2d57f8/attachment.sig>

From paul at pwsan.com  Tue Jul 30 07:32:06 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 30 Jul 2013 11:32:06 +0000 (UTC)
Subject: [PATCH v2] ARM: v6: prevent gcc 4.5 from reordering extended CP15
 reads above is_smp() test
In-Reply-To: <alpine.DEB.2.02.1307282012280.23852@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <20130722184325.GA21614@n2100.arm.linux.org.uk>
 <alpine.DEB.2.02.1307222005370.26048@utopia.booyaka.com>
 <51EE2AA7.5060503@ti.com>
 <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com> <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com> <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307280538460.8385@utopia.booyaka.com>
 <alpine.DEB.2.02.1307282012280.23852@utopia.booyaka.com>
Message-ID: <alpine.DEB.2.02.1307301125420.4505@utopia.booyaka.com>


Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting") breaks
the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
undefined instruction abort from the CP15 read in
cache_ops_need_broadcast().  It turns out that gcc 4.5 reorders the
extended CP15 read above the is_smp() test.  This breaks ARM1136 r0
cores, since they don't support several CP15 registers that later ARM
cores do.  ARM1136JF-S TRM section 3.2.1 "Register allocation" has the
details.

So mark the extended CP15 read as clobbering memory, which prevents
the compiler from reordering it before the is_smp() test.  Russell
states that the code generated from this approach is preferable to
marking the inline asm as volatile.  Remove the existing condition
code clobber as it's obsolete, per Nico's post:

    http://www.spinics.net/lists/arm-kernel/msg261208.html

This patch is a collaboration with Will Deacon and Russell King.

Signed-off-by: Paul Walmsley <paul at pwsan.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Cc: Nicolas Pitre <nicolas.pitre at linaro.org>
Cc: Tony Lindgren <tony at atomide.com>
---

Intended for v3.11-rc.

Basic test logs available here:

http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130730045715/

N.B., several boards have problems on v3.11-rc that are unrelated to this 
patch.

 arch/arm/include/asm/cputype.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 8c25dc4..9672e97 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -89,13 +89,18 @@ extern unsigned int processor_id;
 		__val;							\
 	})
 
+/*
+ * The memory clobber prevents gcc 4.5 from reordering the mrc before
+ * any is_smp() tests, which can cause undefined instruction aborts on
+ * ARM1136 r0 due to the missing extended CP15 registers.
+ */
 #define read_cpuid_ext(ext_reg)						\
 	({								\
 		unsigned int __val;					\
 		asm("mrc	p15, 0, %0, c0, " ext_reg		\
 		    : "=r" (__val)					\
 		    :							\
-		    : "cc");						\
+		    : "memory");					\
 		__val;							\
 	})
 
-- 
1.8.3.2



From florian at openwrt.org  Tue Jul 30 07:43:22 2013
From: florian at openwrt.org (Florian Fainelli)
Date: Tue, 30 Jul 2013 12:43:22 +0100
Subject: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link'
 property
In-Reply-To: <20130730132318.0270fc4b@skate>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <CACxGe6td6uM0v5w92xPVCaVH4tP4AJ-h4SnN-mFoz5gSSosnQw@mail.gmail.com>
 <20130730110705.3262bc3d@skate>
 <CAGVrzcZC9G2ny5rtojbzxmPu8-6EKQ_3io-+fxi61LLCt4Hk=w@mail.gmail.com>
 <20130730132318.0270fc4b@skate>
Message-ID: <CAGVrzcZWHXfQP0=HASSybfLRzKJqmS5t_Y+H0se+VU5oHDWhCA@mail.gmail.com>

2013/7/30 Thomas Petazzoni <thomas.petazzoni at free-electrons.com>:
> Dear Florian Fainelli,
>
> On Tue, 30 Jul 2013 11:05:04 +0100, Florian Fainelli wrote:
>
>> > In fact, this value is used for two things:
>> >
>> >  * As the PHY address on the fake "fixed" MDIO bus.
>> >
>> >  * As the PHY identifier, as reported by the MII registers PHYS_ID1
>> >    (0x2) and PHYS_ID2 (0x3).
>>
>> Right, so I would start with disambiguating the two and just forget
>> about PHYS_ID1 and PHYS_ID2 for the moment since they probably do not
>> need to be per-PHY configurable.
>
> Agreed.
>
>> > I think this doesn't make sense, because the two things are completely
>> > unrelated. Ideally, we'd like the PHY identifier for fixed PHYs to be
>> > something fixed, identical for all fixed PHYs. The problem is finding
>> > an OUI and device number that is available for that, but maybe we can
>> > ask the OpenMoko people to allocate one (see
>> > http://wiki.openmoko.org/wiki/OUI).
>>
>> Well that would be ideal indeed, but I am wondering if we cannot just
>> go with some kind of magic value here anyway, regardless of
>> allocations since this is not a real hardware device.
>
> Well, isn't that exactly what I'm proposing? Have a fixed value for
> PHYS_ID1 and PHYS_ID2, that is used for /all/ fixed PHYs.
>
>> How about the Linux Foundation?
>
> I am concerned about the time it would take to get a new OUI
> attributed. The OpenMoko OUI is said to be open for free and open
> source projects, I think the Linux kernel qualifies :)
>
>> Is not that the same problem as with gadget USB
>> devices which should have some sort of real MAC address for instance?
>
> They are either provided by the user or generated randomly, as far as I
> can see.
>
>> > Then, the PHY address could be generated dynamically. This would
>> > require:
>> >
>> >  * Adding a fixed_phy_create() function that internally uses
>> >    fixed_phy_add(), but before that creates an unique PHY address for
>> >    this newly created PHY. Those unique addresses will be generated by
>> >    incrementing a global number of fixed PHYs, up to PHY_MAX_ADDR,
>> >    which is the maximum number of fixed PHYs that can anyway be
>> >    registered on the fixed MDIO bus.
>>
>> Even though these are purely software PHY implementations, I believe
>> that some sort of predictability would be welcome, so I would just use
>> the phy_id argument passed to fixed_phy_add() as the address on the
>> fixed MDIO bus like it is today.
>
> Well, the whole starting point of this discussion is precisely that
> both Grant and Mark disliked this phy ID that had to be globally
> unique, and they wanted it to be dynamically allocated by the kernel,
> because the DT shouldn't have to care about such internal details.

Ok, well, thinking about this some more, we do not need to be able to
specify the fixed PHY fake MDIO address in the binding anyway. My
concern was first with how to ensure that this would be relatively
stable from an Ethernet driver and user-space perspective, but this
will be stable if we allocate unique IDs in say, parsing/probing order
anyway.

>
>> > Grant, Mark, Florian, do you have other proposals?
>>
>> To sum up, let's just forget about the misuse of phy_id to fill in
>> PHYS_ID1 and PHYS_ID2 registers and keep the existing code with a
>> clear note that phy_id means the "PHY address on the fixed MDIO bus".
>
> Except that Grant and Mark point was precisely that the "PHY address on
> the fake MDIO bus" is not a description of the hardware, and therefore
> shouldn't be mentioned in the Device Tree but instead taken care of by
> the kernel itself.

Right, that works for me now.
--
Florian


From broonie at kernel.org  Tue Jul 30 07:45:02 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 12:45:02 +0100
Subject: [PATCH 0/5] Optional regulator support
Message-ID: <20130730114502.GQ9858@sirena.org.uk>

This patch series adds a variant of regulator_get() which allows
regulator consumers to tell the core that the supply they are requesting
may genuinely be absent in the system.  The goal is to help address some
of the problems with handling errors in regulator_get() in drivers that
are newly converted to the regulator API by allowing the core to provide
stub regulators for supplies that aren't hooked up without disrupting
the operation of drivers like MMC drivers which may genuinely not have
some of their supplies hooked up.

Currently the code simply introduces a new API call with exactly the
same implementation as regulator_get() so there should be zero impact
from the series other than a slightly larger kernel.

Right now all the MMC users are converted over as-is, though it does
look like drivers such as sdhci really ought to be insisting on having a
regulator for VMMC in the same way that the MMC core helper does (and
indeed in that case it looks like it ought to be converted over to the
core code).

If this series is OK I'd like to merge it via the regulator tree so that
the functionality to make use of the optional regulators can be built
out on top of it.

Mark Brown (5):
      regulator: core: Provide hints to the core about optional supplies
      mmc: core: Indicate that vmmcq may be absent
      mmc: sdhci: Indicate that regulators may be absent
      mmc: dw_mmc: Indicate that regulators may be absent
      mmc: pxamci: Indicate that regulators may be absent

 drivers/mmc/core/core.c            |  2 +-
 drivers/mmc/host/dw_mmc.c          |  2 +-
 drivers/mmc/host/pxamci.c          |  2 +-
 drivers/mmc/host/sdhci.c           |  4 +--
 drivers/regulator/core.c           | 59 ++++++++++++++++++++++++++++++++++++++
 include/linux/regulator/consumer.h | 18 +++++++++++-
 6 files changed, 81 insertions(+), 6 deletions(-)
-------------- 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/20130730/ff9caa64/attachment-0001.sig>

From Dave.Martin at arm.com  Tue Jul 30 07:46:01 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Tue, 30 Jul 2013 12:46:01 +0100
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]
In-Reply-To: <20130730120907.6dcc469e@armhf>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
 <20130715135420.GG10000@mudshark.cambridge.arm.com>
 <20130720044655.GC9433@mozilla.com>
 <20130721213753.GA29879@mudshark.cambridge.arm.com>
 <20130722185234.GA14519@localhost.localdomain>
 <20130729212140.GB12681@mozilla.com>
 <20130730092517.GB2478@localhost.localdomain>
 <20130730113853.46cbb00a@armhf>
 <20130730094457.GC2478@localhost.localdomain>
 <20130730120907.6dcc469e@armhf>
Message-ID: <20130730114601.GE2478@localhost.localdomain>

On Tue, Jul 30, 2013 at 12:09:07PM +0200, Jean-Francois Moine wrote:
> On Tue, 30 Jul 2013 10:44:57 +0100
> Dave Martin <Dave.Martin at arm.com> wrote:
> 
> > On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
> > > On Tue, 30 Jul 2013 10:25:18 +0100
> > > Dave Martin <Dave.Martin at arm.com> wrote:
> > >   
> > > > The pragmatic route is less contraversial and lower overhead: even though
> > > > it's not correct as per the ABI, GCC is the only supported compiler for
> > > > building the kernel anyway.  
> > > 
> > > BTW, kernels compiled with gcc-4.8 don't work.  
> > 
> > I haven't tried 4.8 yet.  Do you know what the problem is?
> 
> I randomly get 'NULL pointer dereference' in ext3 (trace below).
> 
> I compared the gcc-4.6 and gcc-4.8 ARM codes of the function where the
> problem occurs, and, while the gcc-4.8 code seems a bit odd, the
> problem should be somewhere else, surely in the memory management.
> 
> > > Did anybody succeed with clang?  
> > 
> > Hmm, I've no idea.  Is this possible?
> 
> freebsd kernels are compiled with clang, and I heard about linux
> patches, but I did not find them yet.

Given the tricks the kernel has to pull with undocumented features of
inline asm and the like, the prospect of dropping in a different
compiler is more than a little scary...

> Otherwise, replacing gcc with clang in the main kernel Makefile stops
> on an assembly instruction where odd register numbers could not be
> used. I did not go further.

Hmm.  Dunno what this is... but I guess it's nothing to do with
backtraces.

Cheers
---Dave

> 
> ------------------ gcc-4.8.1 kernel oops ----------------
> Unable to handle kernel NULL pointer dereference at virtual address 00000003
> pgd = bcf74000
> [00000003] *pgd=3cf16831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 811 [#1] PREEMPT ARM
> Modules linked in: arc4 p54usb p54common crc_ccitt mac80211 cfg80211 fbcon bitblit softcursor font snd_soc_spdif_tx tda998x dove_drm drm_kms_helper snd_soc_kirkwood mv_cesa drm snd_soc_kirkwood_spdif
> CPU: 0 PID: 2426 Comm: iceweasel Not tainted 3.10.0-dirty #55
> task: bd92b700 ti: bcf48000 task.ti: bcf48000
> PC is at do_mpage_readpage+0x754/0x888
> LR is at bio_add_page+0x44/0x4c
> pc : [<800e3c70>]    lr : [<800db8ac>]    psr: 600f0113
> sp : bcf49c34  ip : bcf49c88  fp : bcf49c5c
> r10: 00000003  r9 : 00000000  r8 : 00000043
> r7 : 00000001  r6 : 800e3f54  r5 : bcf49c30  r4 : 00000003
> r3 : 00020000  r2 : 00000042  r1 : 00000000  r0 : bcf49c5c
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 10c5387d  Table: 3cf74019  DAC: 00000015
> Process iceweasel (pid: 2426, stack limit = 0xbcf48240)
> Stack: (0xbcf49c34 to 0xbcf4a000)
> 9c20:                                              00000020 bcf49d24 00200200
> 9c40: 00100100 bd580d94 00000000 80de4260 bcf49cf4 bcf49c60 800e3e78 800e3528
> 9c60: bcf49c88 bcf49c7c 801164cc 000000c1 804d660c 801164cc da0716b4 00000042
> 9c80: 00000000 00000000 00000020 00000000 80de4260 000000c1 00287ab6 00000000
> 9ca0: 00020000 80073500 bd402c80 804d6670 00100100 00000002 00200200 8039a2ac
> 9cc0: 804d660c 00000002 804d6ca0 80113f84 00000020 00000020 00000042 000000b4
> 9ce0: 00000000 00000020 bcf49d04 bcf49cf8 80113fa8 800e3db0 bcf49d6c bcf49d08
> 9d00: 80079ef4 80113f90 bcf00c00 00000018 bd580d94 00000020 bd580d98 bcf49d24
> 9d20: 00000001 80de4394 80de4254 91827364 bcf49d30 bcf49d30 bcf49d38 bcf49d38
> 9d40: 00000052 00000052 bcf00c00 bd580d94 bd580d94 bcf49df0 00000000 bcf6c0d0
> 9d60: bcf49d84 bcf49d70 8007a600 80079d10 00000008 7319d000 bcf49ddc bcf49d88
> 9d80: 800719f4 8007a5dc 80076670 80075448 00000001 000000c1 bcf00c48 00000002
> 9da0: 3c5e818f 00000000 bcf48008 bd580ce0 80013e40 bcf6c0d0 bdbc2e40 00000000
> 9dc0: 7319d000 00000028 00000000 bcf75cc0 bcf49e2c bcf49de0 8008b0ac 8007163c
> 9de0: bdb247a8 00000000 00000000 00000200 00000028 00000052 7319d000 00000000
> 9e00: 8007b8d0 bcf6c0d0 7319d000 7319d000 bdbc2e40 bcf6c0d0 00000028 00000000
> 9e20: bcf49e7c bcf49e30 8008e584 8008b048 00000052 00000028 00000000 000000b1
> 9e40: da538506 000000b1 804bb718 00000004 804bb708 bcf74000 00000398 7319d000
> 9e60: bdbc2e40 bcf6c0d0 00000028 bcf75cc0 bcf49eb4 bcf49e80 8008ed14 8008e51c
> 9e80: bcf75cc0 00000028 da538506 00000017 bcf49fb0 bdbc2e40 bd92b700 7319d288
> 9ea0: bcf48038 00000028 bcf49efc bcf49eb8 80013c38 8008ec80 0000b533 00000000
> 9ec0: 0000b533 00000200 00000000 bdbc2e78 00000000 00000017 80013a64 804b76f4
> 9ee0: 7319d288 bcf49fb0 00000ea1 00000000 bcf49fac bcf49f00 80008460 80013a70
> 9f00: bcf00c00 00000001 000b45c0 804bc488 bcf48000 00000000 0000001d 00000000
> 9f20: 00000001 73098000 bcf49f54 804bc488 bcf49f54 bcf49f40 8006a284 8006b524
> 9f40: 804bb900 bcf48028 00000000 00000000 0000001d 00000000 bcf49f7c bcf49f68
> 9f60: 80022424 8006db18 00020000 804c3c90 bcf49f9c bcf49f80 8000ec2c 800223a4
> 9f80: 00000621 75253ff0 200f0030 75238ed2 200f0030 ffffffff 00000000 00000ea1
> 9fa0: 00000000 bcf49fb0 8000e118 8000842c 7319d2ec 7319d292 7ee06c98 7319d288
> 9fc0: 7ee06c98 73098000 00000000 00000000 00000ea1 00000ea1 00000000 73223be0
> 9fe0: 752811fc 7ee06b88 7523bd75 75238ed2 200f0030 ffffffff 00000000 00000000
> Backtrace: 
> [<800e351c>] (do_mpage_readpage+0x0/0x888) from [<800e3e78>] (mpage_readpages+0xd4/0x130)
> [<800e3da4>] (mpage_readpages+0x0/0x130) from [<80113fa8>] (ext3_readpages+0x24/0x28)
> [<80113f84>] (ext3_readpages+0x0/0x28) from [<80079ef4>] (__do_page_cache_readahead+0x1f0/0x2d8)
> [<80079d04>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007a600>] (ra_submit+0x30/0x38)
> [<8007a5d0>] (ra_submit+0x0/0x38) from [<800719f4>] (filemap_fault+0x3c4/0x4b0)
> [<80071630>] (filemap_fault+0x0/0x4b0) from [<8008b0ac>] (__do_fault+0x70/0x4a8)
> [<8008b03c>] (__do_fault+0x0/0x4a8) from [<8008e584>] (handle_pte_fault+0x74/0x764)
> [<8008e510>] (handle_pte_fault+0x0/0x764) from [<8008ed14>] (handle_mm_fault+0xa0/0xd4)
> [<8008ec74>] (handle_mm_fault+0x0/0xd4) from [<80013c38>] (do_page_fault+0x1d4/0x278)
> [<80013a64>] (do_page_fault+0x0/0x278) from [<80008460>] (do_DataAbort+0x40/0xa0)
> [<80008420>] (do_DataAbort+0x0/0xa0) from [<8000e118>] (__dabt_usr+0x38/0x40)
> Exception stack(0xbcf49fb0 to 0xbcf49ff8)
> 9fa0:                                     7319d2ec 7319d292 7ee06c98 7319d288
> 9fc0: 7ee06c98 73098000 00000000 00000000 00000ea1 00000ea1 00000000 73223be0
> 9fe0: 752811fc 7ee06b88 7523bd75 75238ed2 200f0030 ffffffff
>  r8:00000ea1 r7:00000000 r6:ffffffff r5:200f0030 r4:75238ed2
> Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0) 
> ---[ end trace 838796f906351fb0 ]---
> 
> 
> -- 
> Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
> Jef		|		http://moinejf.free.fr/
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From paul at pwsan.com  Tue Jul 30 07:46:36 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 30 Jul 2013 11:46:36 +0000 (UTC)
Subject: [GIT PULL] ARM: OMAP2+: hwmod fixes for v3.11-rc
Message-ID: <alpine.DEB.2.02.1307301146110.4505@utopia.booyaka.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tony

The following changes since commit 5ae90d8e467e625e447000cb4335c4db973b1095:

  Linux 3.11-rc3 (2013-07-28 20:53:33 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.11-rc/omap-fixes-b

for you to fetch changes up to 50c2a3a1518befe992f868fc1fd867bdad9776ad:

  ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space (2013-07-30 05:13:37 -0600)

- ----------------------------------------------------------------
Some OMAP hwmod fixes for v3.11-rc.  Mostly intended to fix an earlyprintk
regression and an AM33xx cpgmac power management regression.

Basic build, boot, and PM tests are available here:

http://www.pwsan.com/omap/testlogs/hwmod_fixes_a_v3.11-rc/20130730042132/

The tests include temporary fixes for the unrelated 2430SDP and OMAP3
boot regressions, which are not part of this signed tag.

- ----------------------------------------------------------------
Afzal Mohammed (2):
      ARM: OMAP2+: hwmod: rt address space index for DT
      ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space

Rajendra Nayak (3):
      ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL
      ARM: OMAP2+: Avoid idling memory controllers with no drivers
      ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device state

 arch/arm/mach-omap2/omap_device.c                  | 18 ++++++++
 arch/arm/mach-omap2/omap_hwmod.c                   |  2 +-
 arch/arm/mach-omap2/omap_hwmod.h                   | 50 ++++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |  6 +--
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |  3 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |  9 ++--
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |  5 +--
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |  3 +-
 arch/arm/mach-omap2/serial.c                       | 11 -----
 9 files changed, 83 insertions(+), 24 deletions(-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)


wogioQkMcv84GA3e6VmT
=Qr73
-----END PGP SIGNATURE-----


From broonie at kernel.org  Tue Jul 30 07:46:14 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 12:46:14 +0100
Subject: [PATCH 2/5] mmc: core: Indicate that vmmcq may be absent
In-Reply-To: <1375184777-25404-1-git-send-email-broonie@kernel.org>
References: <1375184777-25404-1-git-send-email-broonie@kernel.org>
Message-ID: <1375184777-25404-2-git-send-email-broonie@kernel.org>

From: Mark Brown <broonie at linaro.org>

Use regulator_get_optional() to tell the core that requests for the vmmcq
regulator can fail in a real system.

Signed-off-by: Mark Brown <broonie at linaro.org>
---
 drivers/mmc/core/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 49a5bca..5d08855 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1313,7 +1313,7 @@ int mmc_regulator_get_supply(struct mmc_host *mmc)
 
 	supply = devm_regulator_get(dev, "vmmc");
 	mmc->supply.vmmc = supply;
-	mmc->supply.vqmmc = devm_regulator_get(dev, "vqmmc");
+	mmc->supply.vqmmc = devm_regulator_get_optional(dev, "vqmmc");
 
 	if (IS_ERR(supply))
 		return PTR_ERR(supply);
-- 
1.8.3.2



From broonie at kernel.org  Tue Jul 30 07:46:16 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 12:46:16 +0100
Subject: [PATCH 4/5] mmc: dw_mmc: Indicate that regulators may be absent
In-Reply-To: <1375184777-25404-1-git-send-email-broonie@kernel.org>
References: <1375184777-25404-1-git-send-email-broonie@kernel.org>
Message-ID: <1375184777-25404-4-git-send-email-broonie@kernel.org>

From: Mark Brown <broonie at linaro.org>

Use regulator_get_optional() to tell the core that requests for regulators
can fail in a real system.

Signed-off-by: Mark Brown <broonie at linaro.org>
---
 drivers/mmc/host/dw_mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index ee5f167..5424073 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2231,7 +2231,7 @@ int dw_mci_probe(struct dw_mci *host)
 		}
 	}
 
-	host->vmmc = devm_regulator_get(host->dev, "vmmc");
+	host->vmmc = devm_regulator_get_optional(host->dev, "vmmc");
 	if (IS_ERR(host->vmmc)) {
 		ret = PTR_ERR(host->vmmc);
 		if (ret == -EPROBE_DEFER)
-- 
1.8.3.2



From broonie at kernel.org  Tue Jul 30 07:46:15 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 12:46:15 +0100
Subject: [PATCH 3/5] mmc: sdhci: Indicate that regulators may be absent
In-Reply-To: <1375184777-25404-1-git-send-email-broonie@kernel.org>
References: <1375184777-25404-1-git-send-email-broonie@kernel.org>
Message-ID: <1375184777-25404-3-git-send-email-broonie@kernel.org>

From: Mark Brown <broonie at linaro.org>

Use regulator_get_optional() to tell the core that requests for regulators
can fail in a real system.

Signed-off-by: Mark Brown <broonie at linaro.org>
---
 drivers/mmc/host/sdhci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a78bd4f..dd2c083 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2966,7 +2966,7 @@ int sdhci_add_host(struct sdhci_host *host)
 		mmc->caps |= MMC_CAP_NEEDS_POLL;
 
 	/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
-	host->vqmmc = regulator_get(mmc_dev(mmc), "vqmmc");
+	host->vqmmc = regulator_get_optional(mmc_dev(mmc), "vqmmc");
 	if (IS_ERR_OR_NULL(host->vqmmc)) {
 		if (PTR_ERR(host->vqmmc) < 0) {
 			pr_info("%s: no vqmmc regulator found\n",
@@ -3042,7 +3042,7 @@ int sdhci_add_host(struct sdhci_host *host)
 
 	ocr_avail = 0;
 
-	host->vmmc = regulator_get(mmc_dev(mmc), "vmmc");
+	host->vmmc = regulator_get_optional(mmc_dev(mmc), "vmmc");
 	if (IS_ERR_OR_NULL(host->vmmc)) {
 		if (PTR_ERR(host->vmmc) < 0) {
 			pr_info("%s: no vmmc regulator found\n",
-- 
1.8.3.2



From broonie at kernel.org  Tue Jul 30 07:46:13 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 12:46:13 +0100
Subject: [PATCH 1/5] regulator: core: Provide hints to the core about optional
 supplies
Message-ID: <1375184777-25404-1-git-send-email-broonie@kernel.org>

From: Mark Brown <broonie at linaro.org>

While the majority of supplies on devices are mandatory and can't be
physically omitted for electrical reasons some devices do have optional
supplies and need to know if they are missing, MMC being the most common
of these.

Currently the core accurately reports all errors when regulators are
requested since it does not know if the supply is one that must be provided
even if by a regulator software does not know about or if it is one that
may genuinely be disconnected. In order to allow this behaviour to be
changed and stub regulators to be provided in the former case add a new
regulator request function regulator_get_optional() which provides a hint
to the core that the regulator may genuinely not be connected.

Currently the implementation is identical to the current behaviour, future
patches will add support in the core for returning stub regulators in the
case where normal regulator_get() fails and the board has requested it.

Signed-off-by: Mark Brown <broonie at linaro.org>
---
 drivers/regulator/core.c           | 59 ++++++++++++++++++++++++++++++++++++++
 include/linux/regulator/consumer.h | 18 +++++++++++-
 2 files changed, 76 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 61e4060..f24f401 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1414,6 +1414,65 @@ struct regulator *regulator_get_exclusive(struct device *dev, const char *id)
 }
 EXPORT_SYMBOL_GPL(regulator_get_exclusive);
 
+/**
+ * regulator_get_optional - obtain optional access to a regulator.
+ * @dev: device for regulator "consumer"
+ * @id: Supply name or regulator ID.
+ *
+ * Returns a struct regulator corresponding to the regulator producer,
+ * or IS_ERR() condition containing errno.  Other consumers will be
+ * unable to obtain this reference is held and the use count for the
+ * regulator will be initialised to reflect the current state of the
+ * regulator.
+ *
+ * This is intended for use by consumers for devices which can have
+ * some supplies unconnected in normal use, such as some MMC devices.
+ * It can allow the regulator core to provide stub supplies for other
+ * supplies requested using normal regulator_get() calls without
+ * disrupting the operation of drivers that can handle absent
+ * supplies.
+ *
+ * Use of supply names configured via regulator_set_device_supply() is
+ * strongly encouraged.  It is recommended that the supply name used
+ * should match the name used for the supply and/or the relevant
+ * device pins in the datasheet.
+ */
+struct regulator *regulator_get_optional(struct device *dev, const char *id)
+{
+	return _regulator_get(dev, id, 0);
+}
+EXPORT_SYMBOL_GPL(regulator_get_optional);
+
+/**
+ * devm_regulator_get_optional - Resource managed regulator_get_optional()
+ * @dev: device for regulator "consumer"
+ * @id: Supply name or regulator ID.
+ *
+ * Managed regulator_get_optional(). Regulators returned from this
+ * function are automatically regulator_put() on driver detach. See
+ * regulator_get_optional() for more information.
+ */
+struct regulator *devm_regulator_get_optional(struct device *dev,
+					      const char *id)
+{
+	struct regulator **ptr, *regulator;
+
+	ptr = devres_alloc(devm_regulator_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	regulator = regulator_get_optional(dev, id);
+	if (!IS_ERR(regulator)) {
+		*ptr = regulator;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return regulator;
+}
+EXPORT_SYMBOL_GPL(devm_regulator_get_optional);
+
 /* Locks held by regulator_put() */
 static void _regulator_put(struct regulator *regulator)
 {
diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h
index 1ccc889..2582e41 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -137,6 +137,10 @@ struct regulator *__must_check devm_regulator_get(struct device *dev,
 					     const char *id);
 struct regulator *__must_check regulator_get_exclusive(struct device *dev,
 						       const char *id);
+struct regulator *__must_check regulator_get_optional(struct device *dev,
+						      const char *id);
+struct regulator *__must_check devm_regulator_get_optional(struct device *dev,
+							   const char *id);
 void regulator_put(struct regulator *regulator);
 void devm_regulator_put(struct regulator *regulator);
 
@@ -212,14 +216,26 @@ static inline struct regulator *__must_check regulator_get(struct device *dev,
 }
 
 static inline struct regulator *__must_check
+devm_regulator_get(struct device *dev, const char *id)
+{
+	return NULL;
+}
+
+static inline struct regulator *__must_check
 regulator_get_exclusive(struct device *dev, const char *id)
 {
 	return NULL;
 }
 
+static inline struct regulator *__must_check
+regulator_get_optional(struct device *dev, const char *id)
+{
+	return NULL;
+}
+
 
 static inline struct regulator *__must_check
-devm_regulator_get(struct device *dev, const char *id)
+devm_regulator_get_optional(struct device *dev, const char *id)
 {
 	return NULL;
 }
-- 
1.8.3.2



From broonie at kernel.org  Tue Jul 30 07:46:17 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 12:46:17 +0100
Subject: [PATCH 5/5] mmc: pxamci: Indicate that regulators may be absent
In-Reply-To: <1375184777-25404-1-git-send-email-broonie@kernel.org>
References: <1375184777-25404-1-git-send-email-broonie@kernel.org>
Message-ID: <1375184777-25404-5-git-send-email-broonie@kernel.org>

From: Mark Brown <broonie at linaro.org>

Use regulator_get_optional() to tell the core that requests for regulators
can fail in a real system.

Signed-off-by: Mark Brown <broonie at linaro.org>
---
 drivers/mmc/host/pxamci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c
index 2c5a91b..1956a3d 100644
--- a/drivers/mmc/host/pxamci.c
+++ b/drivers/mmc/host/pxamci.c
@@ -83,7 +83,7 @@ struct pxamci_host {
 static inline void pxamci_init_ocr(struct pxamci_host *host)
 {
 #ifdef CONFIG_REGULATOR
-	host->vcc = regulator_get(mmc_dev(host->mmc), "vmmc");
+	host->vcc = regulator_get_optional(mmc_dev(host->mmc), "vmmc");
 
 	if (IS_ERR(host->vcc))
 		host->vcc = NULL;
-- 
1.8.3.2



From pavel at ucw.cz  Tue Jul 30 07:54:04 2013
From: pavel at ucw.cz (Pavel Machek)
Date: Tue, 30 Jul 2013 13:54:04 +0200
Subject: [PATCH 01/22] ARM: ux500: Remove '0x's from HREF v60+ DTS file
In-Reply-To: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
Message-ID: <20130730115403.GA29992@amd.pavel.ucw.cz>

On Fri 2013-07-19 14:58:32, Lee Jones wrote:
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Why?

									Pavel

> diff --git a/arch/arm/boot/dts/hrefv60plus.dts b/arch/arm/boot/dts/hrefv60plus.dts
> index 3d580d6..46fd8af 100644
> --- a/arch/arm/boot/dts/hrefv60plus.dts
> +++ b/arch/arm/boot/dts/hrefv60plus.dts
> @@ -26,7 +26,7 @@
>  
>  	soc {
>  		i2c at 80110000 {
> -			bu21013_tp at 0x5c {
> +			bu21013_tp at 5c {
>  				reset-gpio = <&gpio4 15 0x4>;
>  			};
>  		};

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From anup at brainfault.org  Tue Jul 30 07:57:54 2013
From: anup at brainfault.org (Anup Patel)
Date: Tue, 30 Jul 2013 17:27:54 +0530
Subject: [PATCH V4] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene
 host
In-Reply-To: <1374471119-26461-1-git-send-email-anup.patel@linaro.org>
References: <1374471119-26461-1-git-send-email-anup.patel@linaro.org>
Message-ID: <CAAhSdy29wvVcmwaUh5PfJTrw4R+MeDrLoWWOPwpnhw2hDvKmKg@mail.gmail.com>

On Mon, Jul 22, 2013 at 11:01 AM, Anup Patel <anup.patel at linaro.org> wrote:
> This patch allows us to have X-Gene guest VCPU when using KVM arm64
> on APM X-Gene host.
>
> We add KVM_ARM_TARGET_XGENE_POTENZA for X-Gene Potenza compatible
> guest VCPU and we return KVM_ARM_TARGET_XGENE_POTENZA in kvm_target_cpu()
> when running on X-Gene host with Potenza core.
>
> V4:
>  - Remove default case from switch statments in kvm_target_cpu()
>
> V3:
>  - Reduce multiple "return -EINVAL" in kvm_target_cpu()
>
> V2:
>  - Renamed KVM_ARM_TARGET_XGENE_V8 to KVM_ARM_TARGET_XGENE_POTENZA
>
> V1:
>  - Initial patch with target named as KVM_ARM_TARGET_XGENE_V8
>
> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
> ---
>  arch/arm64/include/uapi/asm/kvm.h    |    3 ++-
>  arch/arm64/kvm/guest.c               |   32 +++++++++++++++++++-------------
>  arch/arm64/kvm/sys_regs_generic_v8.c |    3 +++
>  3 files changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 5031f42..d9f026b 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -55,8 +55,9 @@ struct kvm_regs {
>  #define KVM_ARM_TARGET_AEM_V8          0
>  #define KVM_ARM_TARGET_FOUNDATION_V8   1
>  #define KVM_ARM_TARGET_CORTEX_A57      2
> +#define KVM_ARM_TARGET_XGENE_POTENZA   3
>
> -#define KVM_ARM_NUM_TARGETS            3
> +#define KVM_ARM_NUM_TARGETS            4
>
>  /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
>  #define KVM_ARM_DEVICE_TYPE_SHIFT      0
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 2c3ff67..d7bf7d6 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -207,20 +207,26 @@ int __attribute_const__ kvm_target_cpu(void)
>         unsigned long implementor = read_cpuid_implementor();
>         unsigned long part_number = read_cpuid_part_number();
>
> -       if (implementor != ARM_CPU_IMP_ARM)
> -               return -EINVAL;
> +       switch (implementor) {
> +       case ARM_CPU_IMP_ARM:
> +               switch (part_number) {
> +               case ARM_CPU_PART_AEM_V8:
> +                       return KVM_ARM_TARGET_AEM_V8;
> +               case ARM_CPU_PART_FOUNDATION:
> +                       return KVM_ARM_TARGET_FOUNDATION_V8;
> +               case ARM_CPU_PART_CORTEX_A57:
> +                       return KVM_ARM_TARGET_CORTEX_A57;
> +               };
> +               break;
> +       case ARM_CPU_IMP_APM:
> +               switch (part_number) {
> +               case APM_CPU_PART_POTENZA:
> +                       return KVM_ARM_TARGET_XGENE_POTENZA;
> +               };
> +               break;
> +       };
>
> -       switch (part_number) {
> -       case ARM_CPU_PART_AEM_V8:
> -               return KVM_ARM_TARGET_AEM_V8;
> -       case ARM_CPU_PART_FOUNDATION:
> -               return KVM_ARM_TARGET_FOUNDATION_V8;
> -       case ARM_CPU_PART_CORTEX_A57:
> -               /* Currently handled by the generic backend */
> -               return KVM_ARM_TARGET_CORTEX_A57;
> -       default:
> -               return -EINVAL;
> -       }
> +       return -EINVAL;
>  }
>
>  int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
> diff --git a/arch/arm64/kvm/sys_regs_generic_v8.c b/arch/arm64/kvm/sys_regs_generic_v8.c
> index 4268ab9..8fe6f76 100644
> --- a/arch/arm64/kvm/sys_regs_generic_v8.c
> +++ b/arch/arm64/kvm/sys_regs_generic_v8.c
> @@ -90,6 +90,9 @@ static int __init sys_reg_genericv8_init(void)
>                                           &genericv8_target_table);
>         kvm_register_target_sys_reg_table(KVM_ARM_TARGET_CORTEX_A57,
>                                           &genericv8_target_table);
> +       kvm_register_target_sys_reg_table(KVM_ARM_TARGET_XGENE_POTENZA,
> +                                         &genericv8_target_table);
> +
>         return 0;
>  }
>  late_initcall(sys_reg_genericv8_init);
> --
> 1.7.9.5
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

Hi Marc,

Do you think more changes are required to this patch ?

Regards,
Anup


From broonie at kernel.org  Tue Jul 30 08:03:04 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 13:03:04 +0100
Subject: [PATCH v6 8/8] ASoC: sam9x5: get codec MCLK via device tree
In-Reply-To: <1375180329-4860-9-git-send-email-richard.genoud@gmail.com>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
 <1375180329-4860-9-git-send-email-richard.genoud@gmail.com>
Message-ID: <20130730120304.GU9858@sirena.org.uk>

On Tue, Jul 30, 2013 at 12:32:09PM +0200, Richard Genoud wrote:

> --- a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
> +++ b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
> @@ -8,6 +8,8 @@ Required properties:
>    - atmel,audio-routing: A list of the connections between audio components.
>      Each entry is a pair of strings, the first being the connection's sink,
>      the second being the connection's source.
> +  - clocks: Must contain an entry for the codec master clock.
> +  - clock-names : Must be "mclk" (clock that feeds the codec master clock)

This should be part of the CODEC binding, not part of the machine driver
binding.  The machine driver should currently have the code to fetch the
clock but since the clock physically goes to the CODEC it should be part
of the CODEC binding.
-------------- 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/20130730/3e5c84c2/attachment.sig>

From jason at lakedaemon.net  Tue Jul 30 08:12:59 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 30 Jul 2013 08:12:59 -0400
Subject: [Ksummit-2013-discuss] Defining schemas for Device Tree
In-Reply-To: <20130729234532.GH29970@voom.fritz.box>
References: <2469263.vMN09Q7Tzi@flatron>
 <20130729150124.GS29916@titan.lakedaemon.net>
 <20130729164905.GB2280@localhost.localdomain>
 <20130729172339.GT29916@titan.lakedaemon.net>
 <20130729222920.GF29970@voom.fritz.box>
 <20130729224840.GZ29916@titan.lakedaemon.net>
 <20130729234532.GH29970@voom.fritz.box>
Message-ID: <20130730121259.GA5882@titan.lakedaemon.net>

On Tue, Jul 30, 2013 at 09:45:32AM +1000, David Gibson wrote:
> On Mon, Jul 29, 2013 at 06:48:40PM -0400, Jason Cooper wrote:
> > On Tue, Jul 30, 2013 at 08:29:20AM +1000, David Gibson wrote:
> > > On Mon, Jul 29, 2013 at 01:23:39PM -0400, Jason Cooper wrote:
> > > > On Mon, Jul 29, 2013 at 05:49:05PM +0100, Dave Martin wrote:
> > > > > On Mon, Jul 29, 2013 at 11:01:24AM -0400, Jason Cooper wrote:
> > > > > > On Mon, Jul 29, 2013 at 02:21:52AM +0200, Tomasz Figa wrote:
> > > > 
> > > > > > > b) What information should be specified in schemas? What level of 
> > > > > > >    granularity is required?
> > > > > > 
> > > > > > One item I don't see in this list is node ordering.  There's been some
> > > > > > discussion lately on deferred probing (re boot times).  If we were to
> > > > > > intentionally declare that DT are parsed in the order written, then a
> > > > > > lot of deferred probes could be avoided by moving eg the pinctrl node to
> > > > > > near the top of the tree.
> > > > > > 
> > > > > > This doesn't impact buses as much, since the nodes needing the bus are
> > > > > > already children.  However, anything accessed via phandles: pins,
> > > > > > clocks, regulators, etc could benefit from declaring and enforcing this.
> > > > > > Eg having the dtc warn when a phandle is used before it's corresponding
> > > > > > node is declared.
> > > > > > 
> > > > > > Not critical though, just a thought.
> > > > > 
> > > > > I don't think that siblings have any defined order in DT.  If reading a
> > > > > device tree, there's no guarantee you get nodes or properties out in the
> > > > > same order as the original .dts file.
> > > > 
> > > > That's why I raised the point.  If people think encoding initialization
> > > > order in the DT is a good idea, then we should change the dtc so it
> > > > compiles/decompiles in the same order.
> > > 
> > > I've always considered the DT to be unordered, although the flattened
> > > representation obviously has to have some order.  It is much safer to
> > > explicitly represent any required orderings with properties, rather
> > > than to rely on the flattened tree order.  I really don't think trying
> > > to have dtc magically understand device initialization ordering in
> > > this way is a good idea.
> > > 
> > > Fwiw, dtc generally preserves order between input and output, with the
> > > exception of the -s option, which sorts the subnodes of each node by
> > > name (useful for dtdiff).
> > > 
> > > > > Provided child/parent relationships are maintained and the set of nodes
> > > > > and values is the same, I think completely rearranging a .dts file does
> > > > > not change its meaning.
> > > > > 
> > > > > "depends-on" relationships mostly have to come from the semantics of
> > > > > the bindings themselves: for example, if a device is connected to some
> > > > > clocks and regulators, the kernel may need to probe those first.
> > > > 
> > > > true, the answer to this problem may be to create a depgraph of the
> > > > nodes based on phandles and child status, then init.  However, if the
> > > > goal is to accelerate boot times, then that should not be calculated
> > > > during each boot, especially since it doesn't likely change from boot to
> > > > boot.
> > > > 
> > > > Which means it would either go in the dtc (dts node ordering is
> > > > irrelevant), or in the dts.  I'm inclined to say dtc should do it, but I
> > > > like the aesthetics of things being in the proper order in something I
> > > > can read.  After all, C requires functions to be declared before use,
> > > > even though the compiler could figure it out.
> > > 
> > > It's not necessarily possible to encode device initialization order in
> > > flattened tree order.  Suppose you have bus A with devices A1 and A2,
> > > and bus B with devices B1 and B2.  A1 must be initialized before B1,
> > > but B2 must be initialized before A2.  There are no loops there, it's
> > > a valid set of initialization order constraints, but you can't get
> > > both of them right in the flat tree ordering.
> > 
> > True, but is there a real scenario where this is the case?  In any
> > event, this could still fall back to deferred probing.
> 
> I never count on weird and wonderful arrangements _not_ appearing in
> embedded.

:-)

> But, in regards to falling back do deferred probing.  If you're
> thinking of the fdt ordering as purely an optimization, rather than
> _required_ to get device init correct, then that's a very different
> matter.  I have no problem with optimizing the ordering, as long as
> its expected that the kernel will still be correct with arbitrary
> ordering.

Yes, after sleeping on it a night, I agree.

> > As I think about it more, working with only what dtc can definitely see,
> > eg busses and phandles, some ordering optimization could be done to
> > reduce the number of probe deferrals.
> 
> Well.  It depends what you mean here.  To do this fully would require
> dtc to interpret properties much more than it currently does - in
> nearly all cases it treats them as opaque blobs, whereas many
> different kinds of properties can potentially include phandles, and
> you have to know how to parse them to discover them.
> 
> On the other hand, if what you're referring to is dtc's &-syntax for
> phandle references, then I guess we could topsort on that.  As long as
> we bear in mind that that can miss cases, if people hand craft their
> phandles, instead of using references.

Just this would eliminate a majority of probe deferrals.

For example, on the Seagate Wireless Plus I was recently trying to put a
mainline kernel on, all of the probe deferrals were pinctrl related.
Just topsorting that node would've fixed the problem.

thx,

Jason.


From richard.genoud at gmail.com  Tue Jul 30 08:15:45 2013
From: richard.genoud at gmail.com (Richard Genoud)
Date: Tue, 30 Jul 2013 14:15:45 +0200
Subject: [PATCH v6 8/8] ASoC: sam9x5: get codec MCLK via device tree
In-Reply-To: <20130730120304.GU9858@sirena.org.uk>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
 <1375180329-4860-9-git-send-email-richard.genoud@gmail.com>
 <20130730120304.GU9858@sirena.org.uk>
Message-ID: <CACQ1gAj=HpEbiNTaPrGO-XxgVy9s-0Nya+pp4-nh7TzOLhxrNg@mail.gmail.com>

2013/7/30 Mark Brown <broonie at kernel.org>:
> On Tue, Jul 30, 2013 at 12:32:09PM +0200, Richard Genoud wrote:
>
>> --- a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
>> +++ b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt
>> @@ -8,6 +8,8 @@ Required properties:
>>    - atmel,audio-routing: A list of the connections between audio components.
>>      Each entry is a pair of strings, the first being the connection's sink,
>>      the second being the connection's source.
>> +  - clocks: Must contain an entry for the codec master clock.
>> +  - clock-names : Must be "mclk" (clock that feeds the codec master clock)
>
> This should be part of the CODEC binding, not part of the machine driver
> binding.  The machine driver should currently have the code to fetch the
> clock but since the clock physically goes to the CODEC it should be part
> of the CODEC binding.
That makes sense.

Thanks !


From festevam at gmail.com  Tue Jul 30 08:15:54 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 30 Jul 2013 09:15:54 -0300
Subject: [PATCH 1/2] ARM: mxs_defconfig: Cleanup mxs_defconfig
Message-ID: <1375186555-4661-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Generate mxs_defconfig by doing:

make mxs_defconfig
make savedefconfig
cp defconfig arch/arm/configs/mxs_defconfig

No functional change. The goal here is to cleanup mxs_defconfig file to
make easier and cleaner the addition of new entries.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/configs/mxs_defconfig | 19 +++++++------------
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/arch/arm/configs/mxs_defconfig b/arch/arm/configs/mxs_defconfig
index 1d6d8fb..4555c02 100644
--- a/arch/arm/configs/mxs_defconfig
+++ b/arch/arm/configs/mxs_defconfig
@@ -1,4 +1,3 @@
-CONFIG_EXPERIMENTAL=y
 CONFIG_SYSVIPC=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
@@ -27,7 +26,6 @@ CONFIG_ARCH_MXS=y
 # CONFIG_ARM_THUMB is not set
 CONFIG_PREEMPT_VOLUNTARY=y
 CONFIG_AEABI=y
-CONFIG_AUTO_ZRELADDR=y
 CONFIG_FPE_NWFPE=y
 CONFIG_NET=y
 CONFIG_PACKET=y
@@ -43,8 +41,6 @@ CONFIG_SYN_COOKIES=y
 # CONFIG_INET_DIAG is not set
 # CONFIG_IPV6 is not set
 CONFIG_CAN=m
-CONFIG_CAN_RAW=m
-CONFIG_CAN_BCM=m
 CONFIG_CAN_FLEXCAN=m
 # CONFIG_WIRELESS is not set
 CONFIG_DEVTMPFS=y
@@ -52,7 +48,6 @@ CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_FIRMWARE_IN_KERNEL is not set
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
 CONFIG_MTD_BLOCK=y
 CONFIG_MTD_DATAFLASH=y
 CONFIG_MTD_M25P80=y
@@ -67,12 +62,12 @@ CONFIG_SCSI=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_NETDEVICES=y
 CONFIG_ENC28J60=y
-CONFIG_USB_USBNET=y
-CONFIG_USB_NET_SMSC95XX=y
 CONFIG_SMSC_PHY=y
 CONFIG_ICPLUS_PHY=y
 CONFIG_REALTEK_PHY=y
 CONFIG_MICREL_PHY=y
+CONFIG_USB_USBNET=y
+CONFIG_USB_NET_SMSC95XX=y
 # CONFIG_WLAN is not set
 # CONFIG_INPUT_MOUSEDEV_PSAUX is not set
 CONFIG_INPUT_EVDEV=y
@@ -110,7 +105,6 @@ CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_PWM=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FONTS=y
 CONFIG_LOGO=y
 CONFIG_SOUND=y
 CONFIG_SND=y
@@ -119,9 +113,9 @@ CONFIG_SND_MXS_SOC=y
 CONFIG_SND_SOC_MXS_SGTL5000=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_STORAGE=y
 CONFIG_USB_CHIPIDEA=y
 CONFIG_USB_CHIPIDEA_HOST=y
-CONFIG_USB_STORAGE=y
 CONFIG_USB_PHY=y
 CONFIG_USB_MXS_PHY=y
 CONFIG_MMC=y
@@ -143,9 +137,9 @@ CONFIG_DMADEVICES=y
 CONFIG_MXS_DMA=y
 CONFIG_STAGING=y
 CONFIG_MXS_LRADC=y
-CONFIG_IIO_SYSFS_TRIGGER=y
 CONFIG_COMMON_CLK_DEBUG=y
 CONFIG_IIO=y
+CONFIG_IIO_SYSFS_TRIGGER=y
 CONFIG_PWM=y
 CONFIG_PWM_MXS=y
 CONFIG_EXT2_FS=y
@@ -173,14 +167,14 @@ CONFIG_NLS_CODEPAGE_850=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_NLS_ISO8859_15=y
 CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_INFO=y
 CONFIG_FRAME_WARN=2048
-CONFIG_MAGIC_SYSRQ=y
 CONFIG_UNUSED_SYMBOLS=y
+CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_KERNEL=y
 CONFIG_LOCKUP_DETECTOR=y
 CONFIG_TIMER_STATS=y
 CONFIG_PROVE_LOCKING=y
-CONFIG_DEBUG_INFO=y
 CONFIG_BLK_DEV_IO_TRACE=y
 CONFIG_STRICT_DEVMEM=y
 CONFIG_DEBUG_USER=y
@@ -188,3 +182,4 @@ CONFIG_DEBUG_USER=y
 # CONFIG_CRYPTO_HW is not set
 CONFIG_CRC_ITU_T=m
 CONFIG_CRC7=m
+CONFIG_FONTS=y
-- 
1.8.1.2



From festevam at gmail.com  Tue Jul 30 08:15:55 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 30 Jul 2013 09:15:55 -0300
Subject: [PATCH 2/2] ARM: imx_v4_v5_defconfig: Cleanup imx_v4_v5_defconfig
In-Reply-To: <1375186555-4661-1-git-send-email-festevam@gmail.com>
References: <1375186555-4661-1-git-send-email-festevam@gmail.com>
Message-ID: <1375186555-4661-2-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Generate imx_v4_v5_defconfig by doing:

make imx_v4_v5_defconfig
make savedefconfig
cp defconfig arch/arm/configs/imx_v4_v5_defconfig

No functional change. The goal here is to cleanup imx_v4_v5_defconfig file to
make easier and cleaner the addition of new entries.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/configs/imx_v4_v5_defconfig | 19 ++++++-------------
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/arch/arm/configs/imx_v4_v5_defconfig b/arch/arm/configs/imx_v4_v5_defconfig
index dcd3d91..6cc94a7 100644
--- a/arch/arm/configs/imx_v4_v5_defconfig
+++ b/arch/arm/configs/imx_v4_v5_defconfig
@@ -1,4 +1,3 @@
-CONFIG_EXPERIMENTAL=y
 # CONFIG_SWAP is not set
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
@@ -17,10 +16,11 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
 # CONFIG_IOSCHED_CFQ is not set
-CONFIG_ARCH_MXC=y
 CONFIG_ARCH_MULTI_V4T=y
 CONFIG_ARCH_MULTI_V5=y
 # CONFIG_ARCH_MULTI_V7 is not set
+CONFIG_ARCH_MXC=y
+CONFIG_MXC_IRQ_PRIOR=y
 CONFIG_ARCH_MX1ADS=y
 CONFIG_MACH_SCB9328=y
 CONFIG_MACH_APF9328=y
@@ -40,8 +40,6 @@ CONFIG_MACH_PCA100=y
 CONFIG_MACH_MXT_TD60=y
 CONFIG_MACH_IMX27IPCAM=y
 CONFIG_MACH_IMX27_DT=y
-CONFIG_MXC_IRQ_PRIOR=y
-CONFIG_MXC_PWM=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
@@ -68,7 +66,6 @@ CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
 CONFIG_MTD_BLOCK=y
 CONFIG_MTD_CFI=y
 CONFIG_MTD_CFI_ADV_OPTIONS=y
@@ -124,24 +121,20 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_MC13783=y
 CONFIG_REGULATOR_MC13892=y
 CONFIG_MEDIA_SUPPORT=y
-CONFIG_VIDEO_DEV=y
-CONFIG_V4L_PLATFORM_DRIVERS=y
 CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_V4L_PLATFORM_DRIVERS=y
 CONFIG_SOC_CAMERA=y
-CONFIG_SOC_CAMERA_OV2640=y
 CONFIG_VIDEO_MX2=y
 CONFIG_V4L_MEM2MEM_DRIVERS=y
 CONFIG_VIDEO_CODA=y
+CONFIG_SOC_CAMERA_OV2640=y
 CONFIG_FB=y
 CONFIG_FB_IMX=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_L4F00242T03=y
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
-CONFIG_BACKLIGHT_PWM=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FONTS=y
-CONFIG_FONT_8x8=y
 CONFIG_LOGO=y
 CONFIG_SOUND=y
 CONFIG_SND=y
@@ -153,12 +146,10 @@ CONFIG_SND_SOC_MX27VIS_AIC32X4=y
 CONFIG_SND_SOC_PHYCORE_AC97=y
 CONFIG_SND_SOC_EUKREA_TLV320=y
 CONFIG_SND_SOC_IMX_SGTL5000=y
-CONFIG_SND_SOC_IMX_MC13783=y
 CONFIG_USB_HID=m
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_MXC=y
-CONFIG_USB_ULPI=y
 CONFIG_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
@@ -199,3 +190,5 @@ CONFIG_NLS_CODEPAGE_850=m
 CONFIG_NLS_ISO8859_1=y
 CONFIG_NLS_ISO8859_15=m
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
+CONFIG_FONTS=y
+CONFIG_FONT_8x8=y
-- 
1.8.1.2



From jason at lakedaemon.net  Tue Jul 30 08:17:43 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 30 Jul 2013 08:17:43 -0400
Subject: [Ksummit-2013-discuss] Defining schemas for Device Tree
In-Reply-To: <20130730015031.GK29970@voom.fritz.box>
References: <2469263.vMN09Q7Tzi@flatron>
 <20130729150124.GS29916@titan.lakedaemon.net>
 <20130729164905.GB2280@localhost.localdomain>
 <20130729172339.GT29916@titan.lakedaemon.net>
 <20130730015031.GK29970@voom.fritz.box>
Message-ID: <20130730121743.GB5882@titan.lakedaemon.net>

On Tue, Jul 30, 2013 at 11:50:31AM +1000, David Gibson wrote:
> On Mon, Jul 29, 2013 at 01:23:39PM -0400, Jason Cooper wrote:
> > On Mon, Jul 29, 2013 at 05:49:05PM +0100, Dave Martin wrote:
> > > On Mon, Jul 29, 2013 at 11:01:24AM -0400, Jason Cooper wrote:
> > > > On Mon, Jul 29, 2013 at 02:21:52AM +0200, Tomasz Figa wrote:
> > 
> > > > > b) What information should be specified in schemas? What level of 
> > > > >    granularity is required?
> > > > 
> > > > One item I don't see in this list is node ordering.  There's been some
> > > > discussion lately on deferred probing (re boot times).  If we were to
> > > > intentionally declare that DT are parsed in the order written, then a
> > > > lot of deferred probes could be avoided by moving eg the pinctrl node to
> > > > near the top of the tree.
> > > > 
> > > > This doesn't impact buses as much, since the nodes needing the bus are
> > > > already children.  However, anything accessed via phandles: pins,
> > > > clocks, regulators, etc could benefit from declaring and enforcing this.
> > > > Eg having the dtc warn when a phandle is used before it's corresponding
> > > > node is declared.
> > > > 
> > > > Not critical though, just a thought.
> > > 
> > > I don't think that siblings have any defined order in DT.  If reading a
> > > device tree, there's no guarantee you get nodes or properties out in the
> > > same order as the original .dts file.
> > 
> > That's why I raised the point.  If people think encoding initialization
> > order in the DT is a good idea, then we should change the dtc so it
> > compiles/decompiles in the same order.
> 
> I'm not actually sure what you mean by this.  dtc already preserves
> order between input and output.

This is an old comment (~ 1d, wow).  My position has evolved to seeing
if we can allow dtc to topsort nodes it can easily tell are needed first
as an optimization.  *Not* a requirement.  Deferred probing would still
be a fall back.

thx,

Jason.


From nm at ti.com  Tue Jul 30 08:18:45 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 07:18:45 -0500
Subject: [PATCH V2 0/3] ARM: dts: omap5-uevm: fixup wrong regulator
 configuration
In-Reply-To: <20130730065253.GE7656@atomide.com>
References: <51F67D7D.9070003@ti.com>
 <1375117383-19285-1-git-send-email-nm@ti.com>
 <51F6EA23.50803@gmail.com> <20130730065253.GE7656@atomide.com>
Message-ID: <CAGo_u6qqGaMKGE66wt_EqeGGcdxNm2jmp6H+NCMeCuswLHT3rA@mail.gmail.com>

On Tue, Jul 30, 2013 at 1:52 AM, Tony Lindgren <tony at atomide.com> wrote:
> * Benoit Cousson <benoit.cousson at gmail.com> [130729 15:24]:
>> On 29/07/2013 19:03, Nishanth Menon wrote:
>> > Due to wrong older revision of documentation used as reference, we
>> > seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
>> > series is based power tree on production board 750-2628-XXX platform.
>> > Unfortunately, the wrong voltages may be detrimental to OMAP5 as they
>> > supply hardware blocks at voltages that are out of specification.
>> >
>> > Also available at:
>> > based on v3.11-rc1 tag
>> > http link: https://github.com/nmenon/linux-2.6-playground/commits/push/omap5-palmas-fixes-v2
>> > git link: git://github.com/nmenon/linux-2.6-playground.git
>> > branch: push/omap5-palmas-fixes-v2
>> >
>> > Changes since V1:
>> >  - squash of patches
>> >  - picked up Ack from Keerthy
>> >  - based on v3.11-rc3 tag
>> >
>> > V1: http://marc.info/?t=137407980100008&r=1&w=2
>> >
>> > Nishanth Menon (3):
>> >   ARM: dts: omap5-uevm: document regulator signals used on the actual
>> >     board
>> >   ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC
>> >   ARM: dts: omap5-uevm: update optional/unused regulator configurations
>> >
>> >  arch/arm/boot/dts/omap5-uevm.dts |   78 ++++++++++++++++++++++++--------------
>> >  1 file changed, 49 insertions(+), 29 deletions(-)
>> >
>> > Regards,
>> > Nishanth Menon
>>
>> For the whole series:
>>
>> Acked-by: Benoit Cousson <benoit.cousson at gmail.com>
>
> Thanks, I've applied these into omap-for-v3.11/fixes-omap5
> and will send a pull request for these today as these seem
> quite urgent fixes.
yes they are. thanks for picking these up and the reviews.

Regards,
Nishanth Menon


From xvzhaobin at gmail.com  Tue Jul 30 08:19:08 2013
From: xvzhaobin at gmail.com (zhaobin xv)
Date: Tue, 30 Jul 2013 20:19:08 +0800
Subject: kernel makefile
Message-ID: <CANEcUBV0k_JgDyO6-MAzAqX3EwaL77ctwPRSzdkHD-qc-eJPEw@mail.gmail.com>

in arch/arm/boot/Makefile:
there is some makefile code:

ifeq ($(CONFIG_ZBOOT_ROM),y)
$(obj)/uImage: LOADADDR=$(CONFIG_ZBOOT_ROM_TEXT)
else
$(obj)/uImage: LOADADDR=$(ZRELADDR)
endif

$(obj)/uImage: STARTADDR=$(LOADADDR)

I can't understand the makefile syntax:$(obj)/uImage: STARTADDR=$(LOADADDR),
I can't find the syntax in GNU make Version 3.82
where can I find the syntax


From u.kleine-koenig at pengutronix.de  Tue Jul 30 08:26:08 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Tue, 30 Jul 2013 14:26:08 +0200
Subject: kernel makefile
In-Reply-To: <CANEcUBV0k_JgDyO6-MAzAqX3EwaL77ctwPRSzdkHD-qc-eJPEw@mail.gmail.com>
References: <CANEcUBV0k_JgDyO6-MAzAqX3EwaL77ctwPRSzdkHD-qc-eJPEw@mail.gmail.com>
Message-ID: <20130730122608.GS1754@pengutronix.de>

Hello,

On Tue, Jul 30, 2013 at 08:19:08PM +0800, zhaobin xv wrote:
> in arch/arm/boot/Makefile:
> there is some makefile code:
> 
> ifeq ($(CONFIG_ZBOOT_ROM),y)
> $(obj)/uImage: LOADADDR=$(CONFIG_ZBOOT_ROM_TEXT)
> else
> $(obj)/uImage: LOADADDR=$(ZRELADDR)
> endif
> 
> $(obj)/uImage: STARTADDR=$(LOADADDR)
> 
> I can't understand the makefile syntax:$(obj)/uImage: STARTADDR=$(LOADADDR),
> I can't find the syntax in GNU make Version 3.82
> where can I find the syntax
Check

	info make 'Target-specific'
	
Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From nm at ti.com  Tue Jul 30 08:26:40 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 07:26:40 -0500
Subject: [PATCH v2 3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
In-Reply-To: <1375183546-12758-4-git-send-email-rnayak@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-4-git-send-email-rnayak@ti.com>
Message-ID: <51F7B100.2020600@ti.com>

On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
> From: R Sricharan <r.sricharan at ti.com>
[...]
>   # Clock framework
>   obj-$(CONFIG_ARCH_OMAP2)		+= $(clock-common) clock2xxx.o
> @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)		+= $(clock-common) dpll3xxx.o
>   obj-$(CONFIG_SOC_AM33XX)		+= cclock33xx_data.o
>   obj-$(CONFIG_SOC_OMAP5)			+= $(clock-common)
>   obj-$(CONFIG_SOC_OMAP5)			+= dpll3xxx.o dpll44xx.o
> +obj-$(CONFIG_SOC_DRA7XX)		+= $(clock-common)
> +obj-$(CONFIG_SOC_DRA7XX)		+= dpll3xxx.o dpll44xx.o
>

are these in sync with DRA7 support being introduced for clock data in [1]?


[1] http://marc.info/?l=linux-omap&m=137456411706971&w=2

-- 
Regards,
Nishanth Menon


From nm at ti.com  Tue Jul 30 08:30:24 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 07:30:24 -0500
Subject: [PATCH v2 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC
 and dra7-evm board
In-Reply-To: <1375183546-12758-9-git-send-email-rnayak@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-9-git-send-email-rnayak@ti.com>
Message-ID: <51F7B1E0.4060800@ti.com>

On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
> From: R Sricharan <r.sricharan at ti.com>
>
> Add minimal device tree source needed for DRA7 based SoCs.
> Also add a board dts file for the dra7-evm (based on dra752)
> which contains 1.5G of memory with 1G interleaved and 512MB
> non-interleaved. Also added in the board file are pin configuration
> details for i2c, mcspi and uart devices on board.
>
> Signed-off-by: R Sricharan <r.sricharan at ti.com>
> Signed-off-by: Rajendra Nayak <rnayak at ti.com>
> Signed-off-by: Sourav Poddar <sourav.poddar at ti.com>
> ---
>   arch/arm/boot/dts/Makefile     |    3 +-
>   arch/arm/boot/dts/dra7-evm.dts |  163 ++++++++++++++
>   arch/arm/boot/dts/dra7.dtsi    |  488 ++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 653 insertions(+), 1 deletion(-)
>   create mode 100644 arch/arm/boot/dts/dra7-evm.dts
>   create mode 100644 arch/arm/boot/dts/dra7.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 641b3c9..e2f8566 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -173,7 +173,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
>   	am335x-bone.dtb \
>   	am3517-evm.dtb \
>   	am3517_mt_ventoux.dtb \
> -	am43x-epos-evm.dtb
> +	am43x-epos-evm.dtb \
> +	dra7-evm.dtb
>   dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
>   dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
>   dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
> new file mode 100644
> index 0000000..7b0b563
> --- /dev/null
> +++ b/arch/arm/boot/dts/dra7-evm.dts
> @@ -0,0 +1,163 @@
> +/*
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +/dts-v1/;
> +
> +/include/ "dra7.dtsi"
> +
> +/ {
> +	model = "TI DRA7";
> +	compatible = "ti,dra7-evm", "ti,dra7";
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x80000000 0x60000000>; /* 1536 MB */
> +	};
> +};
> +
> +&dra7_pmx_core {
> +	i2c1_pins: pinmux_i2c1_pins {
> +		pinctrl-single,pins = <
> +			0x400 0x60000	/* i2c1_sda */
> +			0x404 0x60000	/* i2c1_scl */
> +		>;
> +	};
> +
> +	i2c2_pins: pinmux_i2c2_pins {
> +		pinctrl-single,pins = <
> +			0x408 0x60000	/* i2c2_sda */
> +			0x40c 0x60000	/* i2c2_scl */
> +		>;
> +	};
> +
> +	i2c3_pins: pinmux_i2c3_pins {
> +		pinctrl-single,pins = <
> +			0x410 0x60000	/* i2c3_sda */
> +			0x414 0x60000	/* i2c3_scl */
> +		>;
> +	};
> +
> +	mcspi1_pins: pinmux_mcspi1_pins {
> +		pinctrl-single,pins = <
> +			0x3a4 0x40000	/* spi2_clk */
> +			0x3a8 0x40000	/* spi2_d1 */
> +			0x3ac 0x40000	/* spi2_d0 */
> +			0x3b0 0xc0000	/* spi2_cs0 */
> +			0x3b4 0xc0000	/* spi2_cs1 */
> +			0x3b8 0xe0006	/* spi2_cs2 */
> +			0x3bc 0xe0006	/* spi2_cs3 */
> +		>;
> +	};
> +
> +	mcspi2_pins: pinmux_mcspi2_pins {
> +		pinctrl-single,pins = <
> +			0x3c0 0x40000	/* spi2_sclk */
> +			0x3c4 0xc0000	/* spi2_d1 */
> +			0x3c8 0xc0000	/* spi2_d1 */
> +			0x3cc 0xe0000	/* spi2_cs0 */
> +		>;
> +	};
> +
> +	uart1_pins: pinmux_uart1_pins {
> +		pinctrl-single,pins = <
> +			0x3e0 0xe0000	/* uart1_rxd */
> +			0x3e4 0xe0000	/* uart1_txd */
> +			0x3e8 0x60003	/* uart1_ctsn */
> +			0x3ec 0x60003	/* uart1_rtsn */
> +		>;
> +	};
> +
> +	uart2_pins: pinmux_uart2_pins {
> +		pinctrl-single,pins = <
> +			0x3f0 0x60000 /* uart2_rxd */
> +			0x3f4 0x60000 /* uart2_txd */
> +			0x3f8 0x60000 /* uart2_ctsn */
> +			0x3fc 0x60000 /* uart2_rtsn */
> +		>;
> +	};
> +
> +	uart3_pins: pinmux_uart3_pins {
> +		pinctrl-single,pins = <
> +			0x248 0xc0000 /* uart3_rxd */
> +			0x24c 0xc0000 /* uart3_txd */
> +		>;
> +	};
> +};
> +
> +&i2c1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c1_pins>;
> +
> +	clock-frequency = <400000>;
> +};
> +
> +&i2c2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c2_pins>;
> +
> +	clock-frequency = <400000>;
> +};
> +
> +&i2c3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c3_pins>;
> +
> +	clock-frequency = <3400000>;
> +};
> +
> +&i2c4 {
> +	status = "disabled";
> +};
> +
> +&i2c5 {
> +	status = "disabled";
> +};
> +
> +&mcspi1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mcspi1_pins>;
> +};
> +
> +&mcspi2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mcspi2_pins>;
> +};
> +
> +&mcspi3 {
> +	status = "disabled";
> +};
> +
> +&mcspi4 {
> +	status = "disabled";
> +};
> +
> +&uart1 {
> +        pinctrl-names = "default";
> +        pinctrl-0 = <&uart1_pins>;
> +};
> +
> +&uart2 {
> +        pinctrl-names = "default";
> +        pinctrl-0 = <&uart2_pins>;
> +};
> +
> +&uart3 {
> +        pinctrl-names = "default";
> +        pinctrl-0 = <&uart3_pins>;
> +};
> +
> +&uart4 {
> +	status = "disabled";
> +};
> +
> +&uart5 {
> +	status = "disabled";
> +};
> +
> +&uart6 {
> +	status = "disabled";
> +};
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> new file mode 100644
> index 0000000..8a0c08e
> --- /dev/null
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -0,0 +1,488 @@
> +/*
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + * Based on "omap4.dtsi"
> + */
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	compatible = "ti,dra7xx";
> +	interrupt-parent = <&gic>;
> +
> +	aliases {
> +		serial0 = &uart1;
> +		serial1 = &uart2;
> +		serial2 = &uart3;
> +		serial3 = &uart4;
> +		serial4 = &uart5;
> +		serial5 = &uart6;
> +	};
> +
> +	cpus {
> +		cpu at 0 {
> +			compatible = "arm,cortex-a15";
> +			timer {
> +				compatible = "arm,armv7-timer";
> +				/*
> +				 * PPI secure/nonsecure IRQ,
> +				 * active low level-sensitive
> +				 */
> +				interrupts = <1 13 0x308>,
> +					     <1 14 0x308>;
> +				clock-frequency = <6144000>;
> +			};
> +		};
> +		cpu at 1 {
> +			compatible = "arm,cortex-a15";
> +			timer {
> +				compatible = "arm,armv7-timer";
> +				/*
> +				 * PPI secure/nonsecure IRQ,
> +				 * active low level-sensitive
> +				 */
> +				interrupts = <1 13 0x308>,
> +					     <1 14 0x308>;
> +				clock-frequency = <6144000>;
> +			};
> +		};
> +	};
> +
> +	gic: interrupt-controller at 48211000 {
> +		compatible = "arm,cortex-a15-gic";
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		reg = <0x48211000 0x1000>,
> +		      <0x48212000 0x1000>;
> +	};
> +
> +	/*
> +	 * The soc node represents the soc top level view. It is uses for IPs
> +	 * that are not memory mapped in the MPU view or for the MPU itself.
> +	 */
> +	soc {
> +		compatible = "ti,omap-infra";
> +		mpu {
> +			compatible = "ti,omap5-mpu";
> +			ti,hwmods = "mpu";
> +		};
> +	};
> +
> +	/*
> +	 * XXX: Use a flat representation of the SOC interconnect.
> +	 * The real OMAP interconnect network is quite complex.
> +	 * Since that will not bring real advantage to represent that in DT for
> +	 * the moment, just use a fake OCP bus entry to represent the whole bus
> +	 * hierarchy.
> +	 */
> +	ocp {
> +		compatible = "ti,omap4-l3-noc", "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +		ti,hwmods = "l3_main_1", "l3_main_2";
> +
> +		counter32k: counter at 4ae04000 {
> +			compatible = "ti,omap-counter32k";
> +			reg = <0x4ae04000 0x40>;
> +			ti,hwmods = "counter_32k";
> +		};
> +
> +		dra7_pmx_core: pinmux at 4a003400 {
> +			compatible = "pinctrl-single";
> +			reg = <0x4a003400 0x0464>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			pinctrl-single,register-width = <32>;
> +			pinctrl-single,function-mask = <0x3fffffff>;
> +		};
> +
> +		sdma: dma-controller at 4a056000 {
> +			compatible = "ti,omap4430-sdma";
> +			reg = <0x4a056000 0x1000>;
> +			interrupts = <0 12 0x4>,
> +				     <0 13 0x4>,
> +				     <0 14 0x4>,
> +				     <0 15 0x4>;
> +			#dma-cells = <1>;
> +			#dma-channels = <32>;
> +			#dma-requests = <127>;
> +		};
> +
> +		gpio1: gpio at 4ae10000 {
> +			compatible = "ti,omap4-gpio";
> +			reg = <0x4ae10000 0x200>;
> +			interrupts = <0 29 0x4>;
> +			ti,hwmods = "gpio1";
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <1>;
> +		};
> +
> +		gpio2: gpio at 48055000 {
> +			compatible = "ti,omap4-gpio";
> +			reg = <0x48055000 0x200>;
> +			interrupts = <0 30 0x4>;
> +			ti,hwmods = "gpio2";
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <1>;
> +		};
> +
> +		gpio3: gpio at 48057000 {
> +			compatible = "ti,omap4-gpio";
> +			reg = <0x48057000 0x200>;
> +			interrupts = <0 31 0x4>;
> +			ti,hwmods = "gpio3";
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <1>;
> +		};
> +
> +		gpio4: gpio at 48059000 {
> +			compatible = "ti,omap4-gpio";
> +			reg = <0x48059000 0x200>;
> +			interrupts = <0 32 0x4>;
> +			ti,hwmods = "gpio4";
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <1>;
> +		};
> +
> +		gpio5: gpio at 4805b000 {
> +			compatible = "ti,omap4-gpio";
> +			reg = <0x4805b000 0x200>;
> +			interrupts = <0 33 0x4>;
> +			ti,hwmods = "gpio5";
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <1>;
> +		};
> +
> +		gpio6: gpio at 4805d000 {
> +			compatible = "ti,omap4-gpio";
> +			reg = <0x4805d000 0x200>;
> +			interrupts = <0 34 0x4>;
> +			ti,hwmods = "gpio6";
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <1>;
> +		};
> +
> +		gpio7: gpio at 48051000 {
> +			compatible = "ti,omap4-gpio";
> +			reg = <0x48051000 0x200>;
> +			interrupts = <0 35 0x4>;
> +			ti,hwmods = "gpio7";
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <1>;
> +		};
> +
> +		gpio8: gpio at 48053000 {
> +			compatible = "ti,omap4-gpio";
> +			reg = <0x48053000 0x200>;
> +			interrupts = <0 121 0x4>;
> +			ti,hwmods = "gpio8";
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <1>;
> +		};
> +
> +		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,omap4-uart";
> +			reg = <0x48066000 0x100>;
> +			interrupts = <0 105 0x4>;
> +			ti,hwmods = "uart5";
> +			clock-frequency = <48000000>;
> +		};
> +
> +		uart6: serial at 48068000 {
> +			compatible = "ti,omap4-uart";
> +			reg = <0x48068000 0x100>;
> +			interrupts = <0 106 0x4>;
> +			ti,hwmods = "uart6";
> +			clock-frequency = <48000000>;
> +		};
> +
> +		timer1: timer at 4ae18000 {
> +			compatible = "ti,omap5430-timer";
> +			reg = <0x4ae18000 0x80>;
> +			interrupts = <0 37 0x4>;
> +			ti,hwmods = "timer1";
> +			ti,timer-alwon;
> +		};
> +
> +		timer2: timer at 48032000 {
> +			compatible = "ti,omap5430-timer";
> +			reg = <0x48032000 0x80>;
> +			interrupts = <0 38 0x4>;
> +			ti,hwmods = "timer2";
> +		};
> +
> +		timer3: timer at 48034000 {
> +			compatible = "ti,omap5430-timer";
> +			reg = <0x48034000 0x80>;
> +			interrupts = <0 39 0x4>;
> +			ti,hwmods = "timer3";
> +		};
> +
> +		timer4: timer at 48036000 {
> +			compatible = "ti,omap5430-timer";
> +			reg = <0x48036000 0x80>;
> +			interrupts = <0 40 0x4>;
> +			ti,hwmods = "timer4";
> +		};
> +
> +		timer5: timer at 48820000 {
> +			compatible = "ti,omap5430-timer";
> +			reg = <0x48820000 0x80>;
> +			interrupts = <0 41 0x4>;
> +			ti,hwmods = "timer5";
> +			ti,timer-dsp;
> +		};
> +
> +		timer6: timer at 48822000 {
> +			compatible = "ti,omap5430-timer";
> +			reg = <0x48822000 0x80>;
> +			interrupts = <0 42 0x4>;
> +			ti,hwmods = "timer6";
> +			ti,timer-dsp;
> +			ti,timer-pwm;
> +		};
> +
> +		timer7: timer at 48824000 {
> +			compatible = "ti,omap5430-timer";
> +			reg = <0x48824000 0x80>;
> +			interrupts = <0 43 0x4>;
> +			ti,hwmods = "timer7";
> +			ti,timer-dsp;
> +		};
> +
> +		timer8: timer at 48826000 {
> +			compatible = "ti,omap5430-timer";
> +			reg = <0x48826000 0x80>;
> +			interrupts = <0 44 0x4>;
> +			ti,hwmods = "timer8";
> +			ti,timer-dsp;
> +			ti,timer-pwm;
> +		};
> +
> +		timer9: timer at 4803e000 {
> +			compatible = "ti,omap5430-timer";
> +			reg = <0x4803e000 0x80>;
> +			interrupts = <0 45 0x4>;
> +			ti,hwmods = "timer9";
> +		};
> +
> +		timer10: timer at 48086000 {
> +			compatible = "ti,omap5430-timer";
> +			reg = <0x48086000 0x80>;
> +			interrupts = <0 46 0x4>;
> +			ti,hwmods = "timer10";
> +		};
> +
> +		timer11: timer at 48088000 {
> +			compatible = "ti,omap5430-timer";
> +			reg = <0x48088000 0x80>;
> +			interrupts = <0 47 0x4>;
> +			ti,hwmods = "timer11";
> +			ti,timer-pwm;
> +		};
> +
> +		wdt2: wdt at 4ae14000 {
> +			compatible = "ti,omap4-wdt";
> +			reg = <0x4ae14000 0x80>;
> +			interrupts = <0 80 0x4>;
> +			ti,hwmods = "wd_timer2";
> +		};
> +
> +		i2c1: i2c at 48070000 {
> +			compatible = "ti,omap4-i2c";
> +			reg = <0x48070000 0x100>;
> +			interrupts = <0 56 0x4>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			ti,hwmods = "i2c1";
> +		};
> +
> +		i2c2: i2c at 48072000 {
> +			compatible = "ti,omap4-i2c";
> +			reg = <0x48072000 0x100>;
> +			interrupts = <0 57 0x4>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			ti,hwmods = "i2c2";
> +		};
> +
> +		i2c3: i2c at 48060000 {
> +			compatible = "ti,omap4-i2c";
> +			reg = <0x48060000 0x100>;
> +			interrupts = <0 61 0x4>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			ti,hwmods = "i2c3";
> +		};
> +
> +		i2c4: i2c at 4807a000 {
> +			compatible = "ti,omap4-i2c";
> +			reg = <0x4807a000 0x100>;
> +			interrupts = <0 62 0x4>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			ti,hwmods = "i2c4";
> +		};
> +
> +		i2c5: i2c at 4807c000 {
> +			compatible = "ti,omap4-i2c";
> +			reg = <0x4807c000 0x100>;
> +			interrupts = <0 60 0x4>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			ti,hwmods = "i2c5";
> +		};
> +
> +		mmc1: mmc at 4809c000 {
> +			compatible = "ti,omap4-hsmmc";
> +			reg = <0x4809c000 0x400>;
> +			interrupts = <0 83 0x4>;
> +			ti,hwmods = "mmc1";
> +			ti,dual-volt;
> +			ti,needs-special-reset;
> +			dmas = <&sdma 61>, <&sdma 62>;
> +			dma-names = "tx", "rx";
> +		};
> +
> +		mmc2: mmc at 480b4000 {
> +			compatible = "ti,omap4-hsmmc";
> +			reg = <0x480b4000 0x400>;
> +			interrupts = <0 86 0x4>;
> +			ti,hwmods = "mmc2";
> +			ti,needs-special-reset;
> +			dmas = <&sdma 47>, <&sdma 48>;
> +			dma-names = "tx", "rx";
> +		};
> +
> +		mmc3: mmc at 480ad000 {
> +			compatible = "ti,omap4-hsmmc";
> +			reg = <0x480ad000 0x400>;
> +			interrupts = <0 94 0x4>;
> +			ti,hwmods = "mmc3";
> +			ti,needs-special-reset;
> +			dmas = <&sdma 77>, <&sdma 78>;
> +			dma-names = "tx", "rx";
> +		};
> +
> +		mmc4: mmc at 480d1000 {
> +			compatible = "ti,omap4-hsmmc";
> +			reg = <0x480d1000 0x400>;
> +			interrupts = <0 96 0x4>;
> +			ti,hwmods = "mmc4";
> +			ti,needs-special-reset;
> +			dmas = <&sdma 57>, <&sdma 58>;
> +			dma-names = "tx", "rx";
> +		};
> +
> +		mcspi1: spi at 48098000 {
> +			compatible = "ti,omap4-mcspi";
> +			reg = <0x48098000 0x200>;
> +			interrupts = <0 65 0x4>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			ti,hwmods = "mcspi1";
> +			ti,spi-num-cs = <4>;
> +			dmas = <&sdma 35>,
> +			       <&sdma 36>,
> +			       <&sdma 37>,
> +			       <&sdma 38>,
> +			       <&sdma 39>,
> +			       <&sdma 40>,
> +			       <&sdma 41>,
> +			       <&sdma 42>;
> +			dma-names = "tx0", "rx0", "tx1", "rx1",
> +				    "tx2", "rx2", "tx3", "rx3";
> +		};
> +
> +		mcspi2: spi at 4809a000 {
> +			compatible = "ti,omap4-mcspi";
> +			reg = <0x4809a000 0x200>;
> +			interrupts = <0 66 0x4>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			ti,hwmods = "mcspi2";
> +			ti,spi-num-cs = <2>;
> +			dmas = <&sdma 43>,
> +			       <&sdma 44>,
> +			       <&sdma 45>,
> +			       <&sdma 46>;
> +			dma-names = "tx0", "rx0", "tx1", "rx1";
> +		};
> +
> +		mcspi3: spi at 480b8000 {
> +			compatible = "ti,omap4-mcspi";
> +			reg = <0x480b8000 0x200>;
> +			interrupts = <0 91 0x4>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			ti,hwmods = "mcspi3";
> +			ti,spi-num-cs = <2>;
> +			dmas = <&sdma 15>, <&sdma 16>;
> +			dma-names = "tx0", "rx0";
> +		};
> +
> +		mcspi4: spi at 480ba000 {
> +			compatible = "ti,omap4-mcspi";
> +			reg = <0x480ba000 0x200>;
> +			interrupts = <0 48 0x4>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			ti,hwmods = "mcspi4";
> +			ti,spi-num-cs = <1>;
> +			dmas = <&sdma 70>, <&sdma 71>;
> +			dma-names = "tx0", "rx0";
> +		};
> +	};
> +};
>
ref: [1], we discussed that we should now be able to introduce all 
instances of h/w blocks into the dra7.dts. Further, considering [2]
would you not want to follow "status = disabled" for all modules by 
default and enable required modules in board file, so that we dont have 
to respin this yet again?


[1] http://marc.info/?t=137416599400001&r=1&w=2
[2] http://marc.info/?l=linux-omap&m=137510358229479&w=2
-- 
Regards,
Nishanth Menon


From rnayak at ti.com  Tue Jul 30 08:38:56 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 18:08:56 +0530
Subject: [PATCH v2 3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
In-Reply-To: <51F7B100.2020600@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-4-git-send-email-rnayak@ti.com> <51F7B100.2020600@ti.com>
Message-ID: <51F7B3E0.9020005@ti.com>

On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote:
> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>> From: R Sricharan <r.sricharan at ti.com>
> [...]
>>   # Clock framework
>>   obj-$(CONFIG_ARCH_OMAP2)        += $(clock-common) clock2xxx.o
>> @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
>>   obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
>>   obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
>>   obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
>> +obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
>> +obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
>>
> 
> are these in sync with DRA7 support being introduced for clock data in [1]?

I don't want to have a dependency on those patches since I am not sure of them
making it into 3.12.

> 
> 
> [1] http://marc.info/?l=linux-omap&m=137456411706971&w=2
> 



From B44344 at freescale.com  Tue Jul 30 08:38:18 2013
From: B44344 at freescale.com (Arpit Goel)
Date: Tue, 30 Jul 2013 18:08:18 +0530
Subject: [PATCH 0/2] Make PPC macro spin_event_timeout() architecture
 independent
Message-ID: <1375187900-17582-1-git-send-email-B44344@freescale.com>

This patch-set moves USECS_PER_JIFFY to architecture timex.h from architecture
specific C files. Patch-set further uses this to make PPC macro
spin_event_timeout() architecture independent. This change enables drivers to
use spin_event_timeout() even in non-PowerPC based SoC's.

This patchset has been compiled for ARM, PowerPC and x86.

Patch[1/2] : Moves USECS_PER_JIFFY to architecture specific timex.h files from
	     architecture specific C files.

Patch[2/2] : Converts PPC macro spin_event_timeout() in architecture independent
	     macro.

Arpit Goel (2):
  Make USECS_PER_JIFFY available for generic use
  Convert PowerPC macro spin_event_timeout() to architecture independent
        macro

 arch/arm/include/asm/timex.h      |  2 ++
 arch/arm/kernel/time.c            |  3 ---
 arch/m32r/include/asm/timex.h     |  2 ++
 arch/m32r/kernel/time.c           |  3 ---
 arch/m68k/hp300/time.c            |  4 +---
 arch/m68k/include/asm/timex.h     |  2 ++
 arch/s390/include/asm/timex.h     |  2 ++
 arch/s390/kernel/time.c           |  2 --
 arch/sparc/include/asm/timex_32.h |  2 ++
 arch/sparc/include/asm/timex_64.h |  2 ++
 arch/sparc/kernel/pcic.c          |  1 -
 include/linux/delay.h             | 40 +++++++++++++++++++++++++++++++++++++++
 12 files changed, 53 insertions(+), 12 deletions(-)

-- 
1.8.1.4




From B44344 at freescale.com  Tue Jul 30 08:38:20 2013
From: B44344 at freescale.com (Arpit Goel)
Date: Tue, 30 Jul 2013 18:08:20 +0530
Subject: [PATCH 2/2] Convert PowerPC macro spin_event_timeout() to
 architecture independent macro
In-Reply-To: <1375187900-17582-1-git-send-email-B44344@freescale.com>
References: <1375187900-17582-1-git-send-email-B44344@freescale.com>
Message-ID: <1375187900-17582-3-git-send-email-B44344@freescale.com>

This patch ports PowerPC implementation of spin_event_timeout() for generic
use. Architecture specific implementation can be added to asm/delay.h, which
will override the generic linux implementation.

Signed-off-by: Arpit Goel <B44344 at freescale.com>
---
 include/linux/delay.h | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/include/linux/delay.h b/include/linux/delay.h
index a6ecb34..e975994 100644
--- a/include/linux/delay.h
+++ b/include/linux/delay.h
@@ -52,4 +52,44 @@ static inline void ssleep(unsigned int seconds)
 	msleep(seconds * 1000);
 }
 
+#ifndef spin_event_timeout
+/**
+ * spin_event_timeout - spin until a condition gets true or a timeout elapses
+ * @condition: a C expression to evalate
+ * @timeout: timeout, in microseconds
+ * @delay: the number of microseconds to delay between each evaluation of
+ *         @condition
+ *
+ * The process spins until the condition evaluates to true (non-zero) or the
+ * timeout elapses.  The return value of this macro is the value of
+ * @condition when the loop terminates. This allows you to determine the cause
+ * of the loop terminates.  If the return value is zero, then you know a
+ * timeout has occurred.
+ *
+ * This primary purpose of this macro is to poll on a hardware register
+ * until a status bit changes.  The timeout ensures that the loop still
+ * terminates even if the bit never changes.  The delay is for devices that
+ * need a delay in between successive reads.
+ *
+ * gcc will optimize out the if-statement if @delay is a constant.
+ *
+ * This is copied from PowerPC based spin_event_timeout() implementation
+ * and modified for generic usecase.
+ */
+#define spin_event_timeout(condition, timeout, delay)		\
+({								\
+	typeof(condition) __ret;				\
+	unsigned long __loops = timeout/USECS_PER_JIFFY;	\
+	unsigned long __start = jiffies;			\
+	while (!(__ret = (condition)) &&			\
+		time_before(jiffies, __start + __loops + 1))	\
+		if (delay)					\
+			udelay(delay);				\
+		else						\
+			schedule();				\
+	if (!__ret)						\
+		__ret = (condition);				\
+	__ret;							\
+})
+#endif
 #endif /* defined(_LINUX_DELAY_H) */
-- 
1.8.1.4




From B44344 at freescale.com  Tue Jul 30 08:38:19 2013
From: B44344 at freescale.com (Arpit Goel)
Date: Tue, 30 Jul 2013 18:08:19 +0530
Subject: [PATCH 1/2] Make USECS_PER_JIFFY available for generic use
In-Reply-To: <1375187900-17582-1-git-send-email-B44344@freescale.com>
References: <1375187900-17582-1-git-send-email-B44344@freescale.com>
Message-ID: <1375187900-17582-2-git-send-email-B44344@freescale.com>

USECS_PER_JIFFY is used in several ARCHITECTURE C files.Now USECS_PER_JIFFY
has been moved from architecture specific C files to architecture specific
timex.h. This enables users to include timex.h and make use of USECS_PER_JIFFY.

Signed-off-by: Arpit Goel <B44344 at freescale.com>
---
 arch/arm/include/asm/timex.h      | 2 ++
 arch/arm/kernel/time.c            | 3 ---
 arch/m32r/include/asm/timex.h     | 2 ++
 arch/m32r/kernel/time.c           | 3 ---
 arch/m68k/hp300/time.c            | 4 +---
 arch/m68k/include/asm/timex.h     | 2 ++
 arch/s390/include/asm/timex.h     | 2 ++
 arch/s390/kernel/time.c           | 2 --
 arch/sparc/include/asm/timex_32.h | 2 ++
 arch/sparc/include/asm/timex_64.h | 2 ++
 arch/sparc/kernel/pcic.c          | 1 -
 11 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/arch/arm/include/asm/timex.h b/arch/arm/include/asm/timex.h
index 83f2aa8..55a4f34 100644
--- a/arch/arm/include/asm/timex.h
+++ b/arch/arm/include/asm/timex.h
@@ -18,6 +18,8 @@
 #include <mach/timex.h>
 #endif
 
+/* change this if you have some constant time drift */
+#define USECS_PER_JIFFY	(1000000/HZ)
 typedef unsigned long cycles_t;
 #define get_cycles()	({ cycles_t c; read_current_timer(&c) ? 0 : c; })
 
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 98aee32..7aaead4 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -38,9 +38,6 @@ DEFINE_SPINLOCK(rtc_lock);
 EXPORT_SYMBOL(rtc_lock);
 #endif	/* pc-style 'CMOS' RTC support */
 
-/* change this if you have some constant time drift */
-#define USECS_PER_JIFFY	(1000000/HZ)
-
 #ifdef CONFIG_SMP
 unsigned long profile_pc(struct pt_regs *regs)
 {
diff --git a/arch/m32r/include/asm/timex.h b/arch/m32r/include/asm/timex.h
index bb9fe4f..ff8e6b1 100644
--- a/arch/m32r/include/asm/timex.h
+++ b/arch/m32r/include/asm/timex.h
@@ -9,6 +9,8 @@
 
 #define CLOCK_TICK_RATE	(CONFIG_BUS_CLOCK / CONFIG_TIMER_DIVIDE)
 #define CLOCK_TICK_FACTOR	20	/* Factor of both 1000000 and CLOCK_TICK_RATE */
+/* change this if you have some constant time drift */
+#define USECS_PER_JIFFY	(1000000/HZ)
 
 #ifdef __KERNEL__
 /*
diff --git a/arch/m32r/kernel/time.c b/arch/m32r/kernel/time.c
index 1a15f81..0608e02 100644
--- a/arch/m32r/kernel/time.c
+++ b/arch/m32r/kernel/time.c
@@ -52,9 +52,6 @@ extern void smp_local_timer_interrupt(void);
  * Change this if you have some constant time drift
  */
 
-/* This is for machines which generate the exact clock. */
-#define USECS_PER_JIFFY (1000000/HZ)
-
 static unsigned long latch;
 
 static u32 m32r_gettimeoffset(void)
diff --git a/arch/m68k/hp300/time.c b/arch/m68k/hp300/time.c
index 749543b..9d751d3 100644
--- a/arch/m68k/hp300/time.c
+++ b/arch/m68k/hp300/time.c
@@ -12,6 +12,7 @@
 #include <linux/sched.h>
 #include <linux/kernel_stat.h>
 #include <linux/interrupt.h>
+#include <linux/time.h>
 #include <asm/machdep.h>
 #include <asm/irq.h>
 #include <asm/io.h>
@@ -30,9 +31,6 @@
 #define	CLKMSB2		0x9
 #define	CLKMSB3		0xD
 
-/* This is for machines which generate the exact clock. */
-#define USECS_PER_JIFFY (1000000/HZ)
-
 #define INTVAL ((10000 / 4) - 1)
 
 static irqreturn_t hp300_tick(int irq, void *dev_id)
diff --git a/arch/m68k/include/asm/timex.h b/arch/m68k/include/asm/timex.h
index 6759dad..44f2603 100644
--- a/arch/m68k/include/asm/timex.h
+++ b/arch/m68k/include/asm/timex.h
@@ -21,6 +21,8 @@
 #define CLOCK_TICK_RATE	1193180 /* Underlying HZ */
 #endif
 
+/* change this if you have some constant time drift */
+#define USECS_PER_JIFFY	(1000000/HZ)
 typedef unsigned long cycles_t;
 
 static inline cycles_t get_cycles(void)
diff --git a/arch/s390/include/asm/timex.h b/arch/s390/include/asm/timex.h
index 8ad8af9..91175c9 100644
--- a/arch/s390/include/asm/timex.h
+++ b/arch/s390/include/asm/timex.h
@@ -13,6 +13,8 @@
 
 /* The value of the TOD clock for 1.1.1970. */
 #define TOD_UNIX_EPOCH 0x7d91048bca000000ULL
+/* change this if you have some constant time drift */
+#define USECS_PER_JIFFY	(1000000/HZ)
 
 /* Inline functions for clock register access. */
 static inline int set_tod_clock(__u64 time)
diff --git a/arch/s390/kernel/time.c b/arch/s390/kernel/time.c
index 876546b..eb659b6 100644
--- a/arch/s390/kernel/time.c
+++ b/arch/s390/kernel/time.c
@@ -49,8 +49,6 @@
 #include <asm/cio.h>
 #include "entry.h"
 
-/* change this if you have some constant time drift */
-#define USECS_PER_JIFFY     ((unsigned long) 1000000/HZ)
 #define CLK_TICKS_PER_JIFFY ((unsigned long) USECS_PER_JIFFY << 12)
 
 u64 sched_clock_base_cc = -1;	/* Force to data section. */
diff --git a/arch/sparc/include/asm/timex_32.h b/arch/sparc/include/asm/timex_32.h
index b6ccdb0..cb7f412 100644
--- a/arch/sparc/include/asm/timex_32.h
+++ b/arch/sparc/include/asm/timex_32.h
@@ -7,6 +7,8 @@
 #define _ASMsparc_TIMEX_H
 
 #define CLOCK_TICK_RATE	1193180 /* Underlying HZ */
+/* change this if you have some constant time drift */
+#define USECS_PER_JIFFY	(1000000/HZ)
 
 /* XXX Maybe do something better at some point... -DaveM */
 typedef unsigned long cycles_t;
diff --git a/arch/sparc/include/asm/timex_64.h b/arch/sparc/include/asm/timex_64.h
index 18b30bc..1a5738a 100644
--- a/arch/sparc/include/asm/timex_64.h
+++ b/arch/sparc/include/asm/timex_64.h
@@ -9,6 +9,8 @@
 #include <asm/timer.h>
 
 #define CLOCK_TICK_RATE	1193180 /* Underlying HZ */
+/* change this if you have some constant time drift */
+#define USECS_PER_JIFFY	(1000000/HZ)
 
 /* Getting on the cycle counter on sparc64. */
 typedef unsigned long cycles_t;
diff --git a/arch/sparc/kernel/pcic.c b/arch/sparc/kernel/pcic.c
index 09f4fdd..2a62932 100644
--- a/arch/sparc/kernel/pcic.c
+++ b/arch/sparc/kernel/pcic.c
@@ -703,7 +703,6 @@ static void pcic_clear_clock_irq(void)
 }
 
 /* CPU frequency is 100 MHz, timer increments every 4 CPU clocks */
-#define USECS_PER_JIFFY  (1000000 / HZ)
 #define TICK_TIMER_LIMIT ((100 * 1000000 / 4) / HZ)
 
 static unsigned int pcic_cycles_offset(void)
-- 
1.8.1.4




From cjb at laptop.org  Tue Jul 30 08:40:28 2013
From: cjb at laptop.org (Chris Ball)
Date: Tue, 30 Jul 2013 13:40:28 +0100
Subject: [PATCH 0/5] Optional regulator support
In-Reply-To: <20130730114502.GQ9858@sirena.org.uk> (Mark Brown's message of
 "Tue, 30 Jul 2013 12:45:02 +0100")
References: <20130730114502.GQ9858@sirena.org.uk>
Message-ID: <864nbcte4j.fsf@void.printf.net>

Hi,

On Tue, Jul 30 2013, Mark Brown wrote:
> This patch series adds a variant of regulator_get() which allows
> regulator consumers to tell the core that the supply they are requesting
> may genuinely be absent in the system.  The goal is to help address some
> of the problems with handling errors in regulator_get() in drivers that
> are newly converted to the regulator API by allowing the core to provide
> stub regulators for supplies that aren't hooked up without disrupting
> the operation of drivers like MMC drivers which may genuinely not have
> some of their supplies hooked up.
>
> Currently the code simply introduces a new API call with exactly the
> same implementation as regulator_get() so there should be zero impact
> from the series other than a slightly larger kernel.

Looks good:

Acked-by: Chris Ball <cjb at laptop.org>

> Right now all the MMC users are converted over as-is, though it does
> look like drivers such as sdhci really ought to be insisting on having a
> regulator for VMMC in the same way that the MMC core helper does (and
> indeed in that case it looks like it ought to be converted over to the
> core code).

I didn't follow this part -- I don't think the MMC core insists on a
VMMC regulator, and I don't think sdhci should either, because e.g.
an x86 laptop isn't going to have one.  What am I missing?

Thanks,

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>


From rnayak at ti.com  Tue Jul 30 08:41:27 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 18:11:27 +0530
Subject: [PATCH v2 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC
 and dra7-evm board
In-Reply-To: <51F7B1E0.4060800@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-9-git-send-email-rnayak@ti.com> <51F7B1E0.4060800@ti.com>
Message-ID: <51F7B477.9010701@ti.com>

On Tuesday 30 July 2013 06:00 PM, Nishanth Menon wrote:
> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>> From: R Sricharan <r.sricharan at ti.com>
>>
>> Add minimal device tree source needed for DRA7 based SoCs.
>> Also add a board dts file for the dra7-evm (based on dra752)
>> which contains 1.5G of memory with 1G interleaved and 512MB
>> non-interleaved. Also added in the board file are pin configuration
>> details for i2c, mcspi and uart devices on board.
>>
>> Signed-off-by: R Sricharan <r.sricharan at ti.com>
>> Signed-off-by: Rajendra Nayak <rnayak at ti.com>
>> Signed-off-by: Sourav Poddar <sourav.poddar at ti.com>
>> ---
>>   arch/arm/boot/dts/Makefile     |    3 +-
>>   arch/arm/boot/dts/dra7-evm.dts |  163 ++++++++++++++
>>   arch/arm/boot/dts/dra7.dtsi    |  488 ++++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 653 insertions(+), 1 deletion(-)
>>   create mode 100644 arch/arm/boot/dts/dra7-evm.dts
>>   create mode 100644 arch/arm/boot/dts/dra7.dtsi
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 641b3c9..e2f8566 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -173,7 +173,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
>>       am335x-bone.dtb \
>>       am3517-evm.dtb \
>>       am3517_mt_ventoux.dtb \
>> -    am43x-epos-evm.dtb
>> +    am43x-epos-evm.dtb \
>> +    dra7-evm.dtb
>>   dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
>>   dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
>>   dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
>> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
>> new file mode 100644
>> index 0000000..7b0b563
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>> @@ -0,0 +1,163 @@
>> +/*
>> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +/dts-v1/;
>> +
>> +/include/ "dra7.dtsi"
>> +
>> +/ {
>> +    model = "TI DRA7";
>> +    compatible = "ti,dra7-evm", "ti,dra7";
>> +
>> +    memory {
>> +        device_type = "memory";
>> +        reg = <0x80000000 0x60000000>; /* 1536 MB */
>> +    };
>> +};
>> +
>> +&dra7_pmx_core {
>> +    i2c1_pins: pinmux_i2c1_pins {
>> +        pinctrl-single,pins = <
>> +            0x400 0x60000    /* i2c1_sda */
>> +            0x404 0x60000    /* i2c1_scl */
>> +        >;
>> +    };
>> +
>> +    i2c2_pins: pinmux_i2c2_pins {
>> +        pinctrl-single,pins = <
>> +            0x408 0x60000    /* i2c2_sda */
>> +            0x40c 0x60000    /* i2c2_scl */
>> +        >;
>> +    };
>> +
>> +    i2c3_pins: pinmux_i2c3_pins {
>> +        pinctrl-single,pins = <
>> +            0x410 0x60000    /* i2c3_sda */
>> +            0x414 0x60000    /* i2c3_scl */
>> +        >;
>> +    };
>> +
>> +    mcspi1_pins: pinmux_mcspi1_pins {
>> +        pinctrl-single,pins = <
>> +            0x3a4 0x40000    /* spi2_clk */
>> +            0x3a8 0x40000    /* spi2_d1 */
>> +            0x3ac 0x40000    /* spi2_d0 */
>> +            0x3b0 0xc0000    /* spi2_cs0 */
>> +            0x3b4 0xc0000    /* spi2_cs1 */
>> +            0x3b8 0xe0006    /* spi2_cs2 */
>> +            0x3bc 0xe0006    /* spi2_cs3 */
>> +        >;
>> +    };
>> +
>> +    mcspi2_pins: pinmux_mcspi2_pins {
>> +        pinctrl-single,pins = <
>> +            0x3c0 0x40000    /* spi2_sclk */
>> +            0x3c4 0xc0000    /* spi2_d1 */
>> +            0x3c8 0xc0000    /* spi2_d1 */
>> +            0x3cc 0xe0000    /* spi2_cs0 */
>> +        >;
>> +    };
>> +
>> +    uart1_pins: pinmux_uart1_pins {
>> +        pinctrl-single,pins = <
>> +            0x3e0 0xe0000    /* uart1_rxd */
>> +            0x3e4 0xe0000    /* uart1_txd */
>> +            0x3e8 0x60003    /* uart1_ctsn */
>> +            0x3ec 0x60003    /* uart1_rtsn */
>> +        >;
>> +    };
>> +
>> +    uart2_pins: pinmux_uart2_pins {
>> +        pinctrl-single,pins = <
>> +            0x3f0 0x60000 /* uart2_rxd */
>> +            0x3f4 0x60000 /* uart2_txd */
>> +            0x3f8 0x60000 /* uart2_ctsn */
>> +            0x3fc 0x60000 /* uart2_rtsn */
>> +        >;
>> +    };
>> +
>> +    uart3_pins: pinmux_uart3_pins {
>> +        pinctrl-single,pins = <
>> +            0x248 0xc0000 /* uart3_rxd */
>> +            0x24c 0xc0000 /* uart3_txd */
>> +        >;
>> +    };
>> +};
>> +
>> +&i2c1 {
>> +    pinctrl-names = "default";
>> +    pinctrl-0 = <&i2c1_pins>;
>> +
>> +    clock-frequency = <400000>;
>> +};
>> +
>> +&i2c2 {
>> +    pinctrl-names = "default";
>> +    pinctrl-0 = <&i2c2_pins>;
>> +
>> +    clock-frequency = <400000>;
>> +};
>> +
>> +&i2c3 {
>> +    pinctrl-names = "default";
>> +    pinctrl-0 = <&i2c3_pins>;
>> +
>> +    clock-frequency = <3400000>;
>> +};
>> +
>> +&i2c4 {
>> +    status = "disabled";
>> +};
>> +
>> +&i2c5 {
>> +    status = "disabled";
>> +};
>> +
>> +&mcspi1 {
>> +    pinctrl-names = "default";
>> +    pinctrl-0 = <&mcspi1_pins>;
>> +};
>> +
>> +&mcspi2 {
>> +    pinctrl-names = "default";
>> +    pinctrl-0 = <&mcspi2_pins>;
>> +};
>> +
>> +&mcspi3 {
>> +    status = "disabled";
>> +};
>> +
>> +&mcspi4 {
>> +    status = "disabled";
>> +};
>> +
>> +&uart1 {
>> +        pinctrl-names = "default";
>> +        pinctrl-0 = <&uart1_pins>;
>> +};
>> +
>> +&uart2 {
>> +        pinctrl-names = "default";
>> +        pinctrl-0 = <&uart2_pins>;
>> +};
>> +
>> +&uart3 {
>> +        pinctrl-names = "default";
>> +        pinctrl-0 = <&uart3_pins>;
>> +};
>> +
>> +&uart4 {
>> +    status = "disabled";
>> +};
>> +
>> +&uart5 {
>> +    status = "disabled";
>> +};
>> +
>> +&uart6 {
>> +    status = "disabled";
>> +};
>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>> new file mode 100644
>> index 0000000..8a0c08e
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/dra7.dtsi
>> @@ -0,0 +1,488 @@
>> +/*
>> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + * Based on "omap4.dtsi"
>> + */
>> +
>> +/include/ "skeleton.dtsi"
>> +
>> +/ {
>> +    compatible = "ti,dra7xx";
>> +    interrupt-parent = <&gic>;
>> +
>> +    aliases {
>> +        serial0 = &uart1;
>> +        serial1 = &uart2;
>> +        serial2 = &uart3;
>> +        serial3 = &uart4;
>> +        serial4 = &uart5;
>> +        serial5 = &uart6;
>> +    };
>> +
>> +    cpus {
>> +        cpu at 0 {
>> +            compatible = "arm,cortex-a15";
>> +            timer {
>> +                compatible = "arm,armv7-timer";
>> +                /*
>> +                 * PPI secure/nonsecure IRQ,
>> +                 * active low level-sensitive
>> +                 */
>> +                interrupts = <1 13 0x308>,
>> +                         <1 14 0x308>;
>> +                clock-frequency = <6144000>;
>> +            };
>> +        };
>> +        cpu at 1 {
>> +            compatible = "arm,cortex-a15";
>> +            timer {
>> +                compatible = "arm,armv7-timer";
>> +                /*
>> +                 * PPI secure/nonsecure IRQ,
>> +                 * active low level-sensitive
>> +                 */
>> +                interrupts = <1 13 0x308>,
>> +                         <1 14 0x308>;
>> +                clock-frequency = <6144000>;
>> +            };
>> +        };
>> +    };
>> +
>> +    gic: interrupt-controller at 48211000 {
>> +        compatible = "arm,cortex-a15-gic";
>> +        interrupt-controller;
>> +        #interrupt-cells = <3>;
>> +        reg = <0x48211000 0x1000>,
>> +              <0x48212000 0x1000>;
>> +    };
>> +
>> +    /*
>> +     * The soc node represents the soc top level view. It is uses for IPs
>> +     * that are not memory mapped in the MPU view or for the MPU itself.
>> +     */
>> +    soc {
>> +        compatible = "ti,omap-infra";
>> +        mpu {
>> +            compatible = "ti,omap5-mpu";
>> +            ti,hwmods = "mpu";
>> +        };
>> +    };
>> +
>> +    /*
>> +     * XXX: Use a flat representation of the SOC interconnect.
>> +     * The real OMAP interconnect network is quite complex.
>> +     * Since that will not bring real advantage to represent that in DT for
>> +     * the moment, just use a fake OCP bus entry to represent the whole bus
>> +     * hierarchy.
>> +     */
>> +    ocp {
>> +        compatible = "ti,omap4-l3-noc", "simple-bus";
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +        ranges;
>> +        ti,hwmods = "l3_main_1", "l3_main_2";
>> +
>> +        counter32k: counter at 4ae04000 {
>> +            compatible = "ti,omap-counter32k";
>> +            reg = <0x4ae04000 0x40>;
>> +            ti,hwmods = "counter_32k";
>> +        };
>> +
>> +        dra7_pmx_core: pinmux at 4a003400 {
>> +            compatible = "pinctrl-single";
>> +            reg = <0x4a003400 0x0464>;
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +            pinctrl-single,register-width = <32>;
>> +            pinctrl-single,function-mask = <0x3fffffff>;
>> +        };
>> +
>> +        sdma: dma-controller at 4a056000 {
>> +            compatible = "ti,omap4430-sdma";
>> +            reg = <0x4a056000 0x1000>;
>> +            interrupts = <0 12 0x4>,
>> +                     <0 13 0x4>,
>> +                     <0 14 0x4>,
>> +                     <0 15 0x4>;
>> +            #dma-cells = <1>;
>> +            #dma-channels = <32>;
>> +            #dma-requests = <127>;
>> +        };
>> +
>> +        gpio1: gpio at 4ae10000 {
>> +            compatible = "ti,omap4-gpio";
>> +            reg = <0x4ae10000 0x200>;
>> +            interrupts = <0 29 0x4>;
>> +            ti,hwmods = "gpio1";
>> +            gpio-controller;
>> +            #gpio-cells = <2>;
>> +            interrupt-controller;
>> +            #interrupt-cells = <1>;
>> +        };
>> +
>> +        gpio2: gpio at 48055000 {
>> +            compatible = "ti,omap4-gpio";
>> +            reg = <0x48055000 0x200>;
>> +            interrupts = <0 30 0x4>;
>> +            ti,hwmods = "gpio2";
>> +            gpio-controller;
>> +            #gpio-cells = <2>;
>> +            interrupt-controller;
>> +            #interrupt-cells = <1>;
>> +        };
>> +
>> +        gpio3: gpio at 48057000 {
>> +            compatible = "ti,omap4-gpio";
>> +            reg = <0x48057000 0x200>;
>> +            interrupts = <0 31 0x4>;
>> +            ti,hwmods = "gpio3";
>> +            gpio-controller;
>> +            #gpio-cells = <2>;
>> +            interrupt-controller;
>> +            #interrupt-cells = <1>;
>> +        };
>> +
>> +        gpio4: gpio at 48059000 {
>> +            compatible = "ti,omap4-gpio";
>> +            reg = <0x48059000 0x200>;
>> +            interrupts = <0 32 0x4>;
>> +            ti,hwmods = "gpio4";
>> +            gpio-controller;
>> +            #gpio-cells = <2>;
>> +            interrupt-controller;
>> +            #interrupt-cells = <1>;
>> +        };
>> +
>> +        gpio5: gpio at 4805b000 {
>> +            compatible = "ti,omap4-gpio";
>> +            reg = <0x4805b000 0x200>;
>> +            interrupts = <0 33 0x4>;
>> +            ti,hwmods = "gpio5";
>> +            gpio-controller;
>> +            #gpio-cells = <2>;
>> +            interrupt-controller;
>> +            #interrupt-cells = <1>;
>> +        };
>> +
>> +        gpio6: gpio at 4805d000 {
>> +            compatible = "ti,omap4-gpio";
>> +            reg = <0x4805d000 0x200>;
>> +            interrupts = <0 34 0x4>;
>> +            ti,hwmods = "gpio6";
>> +            gpio-controller;
>> +            #gpio-cells = <2>;
>> +            interrupt-controller;
>> +            #interrupt-cells = <1>;
>> +        };
>> +
>> +        gpio7: gpio at 48051000 {
>> +            compatible = "ti,omap4-gpio";
>> +            reg = <0x48051000 0x200>;
>> +            interrupts = <0 35 0x4>;
>> +            ti,hwmods = "gpio7";
>> +            gpio-controller;
>> +            #gpio-cells = <2>;
>> +            interrupt-controller;
>> +            #interrupt-cells = <1>;
>> +        };
>> +
>> +        gpio8: gpio at 48053000 {
>> +            compatible = "ti,omap4-gpio";
>> +            reg = <0x48053000 0x200>;
>> +            interrupts = <0 121 0x4>;
>> +            ti,hwmods = "gpio8";
>> +            gpio-controller;
>> +            #gpio-cells = <2>;
>> +            interrupt-controller;
>> +            #interrupt-cells = <1>;
>> +        };
>> +
>> +        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,omap4-uart";
>> +            reg = <0x48066000 0x100>;
>> +            interrupts = <0 105 0x4>;
>> +            ti,hwmods = "uart5";
>> +            clock-frequency = <48000000>;
>> +        };
>> +
>> +        uart6: serial at 48068000 {
>> +            compatible = "ti,omap4-uart";
>> +            reg = <0x48068000 0x100>;
>> +            interrupts = <0 106 0x4>;
>> +            ti,hwmods = "uart6";
>> +            clock-frequency = <48000000>;
>> +        };
>> +
>> +        timer1: timer at 4ae18000 {
>> +            compatible = "ti,omap5430-timer";
>> +            reg = <0x4ae18000 0x80>;
>> +            interrupts = <0 37 0x4>;
>> +            ti,hwmods = "timer1";
>> +            ti,timer-alwon;
>> +        };
>> +
>> +        timer2: timer at 48032000 {
>> +            compatible = "ti,omap5430-timer";
>> +            reg = <0x48032000 0x80>;
>> +            interrupts = <0 38 0x4>;
>> +            ti,hwmods = "timer2";
>> +        };
>> +
>> +        timer3: timer at 48034000 {
>> +            compatible = "ti,omap5430-timer";
>> +            reg = <0x48034000 0x80>;
>> +            interrupts = <0 39 0x4>;
>> +            ti,hwmods = "timer3";
>> +        };
>> +
>> +        timer4: timer at 48036000 {
>> +            compatible = "ti,omap5430-timer";
>> +            reg = <0x48036000 0x80>;
>> +            interrupts = <0 40 0x4>;
>> +            ti,hwmods = "timer4";
>> +        };
>> +
>> +        timer5: timer at 48820000 {
>> +            compatible = "ti,omap5430-timer";
>> +            reg = <0x48820000 0x80>;
>> +            interrupts = <0 41 0x4>;
>> +            ti,hwmods = "timer5";
>> +            ti,timer-dsp;
>> +        };
>> +
>> +        timer6: timer at 48822000 {
>> +            compatible = "ti,omap5430-timer";
>> +            reg = <0x48822000 0x80>;
>> +            interrupts = <0 42 0x4>;
>> +            ti,hwmods = "timer6";
>> +            ti,timer-dsp;
>> +            ti,timer-pwm;
>> +        };
>> +
>> +        timer7: timer at 48824000 {
>> +            compatible = "ti,omap5430-timer";
>> +            reg = <0x48824000 0x80>;
>> +            interrupts = <0 43 0x4>;
>> +            ti,hwmods = "timer7";
>> +            ti,timer-dsp;
>> +        };
>> +
>> +        timer8: timer at 48826000 {
>> +            compatible = "ti,omap5430-timer";
>> +            reg = <0x48826000 0x80>;
>> +            interrupts = <0 44 0x4>;
>> +            ti,hwmods = "timer8";
>> +            ti,timer-dsp;
>> +            ti,timer-pwm;
>> +        };
>> +
>> +        timer9: timer at 4803e000 {
>> +            compatible = "ti,omap5430-timer";
>> +            reg = <0x4803e000 0x80>;
>> +            interrupts = <0 45 0x4>;
>> +            ti,hwmods = "timer9";
>> +        };
>> +
>> +        timer10: timer at 48086000 {
>> +            compatible = "ti,omap5430-timer";
>> +            reg = <0x48086000 0x80>;
>> +            interrupts = <0 46 0x4>;
>> +            ti,hwmods = "timer10";
>> +        };
>> +
>> +        timer11: timer at 48088000 {
>> +            compatible = "ti,omap5430-timer";
>> +            reg = <0x48088000 0x80>;
>> +            interrupts = <0 47 0x4>;
>> +            ti,hwmods = "timer11";
>> +            ti,timer-pwm;
>> +        };
>> +
>> +        wdt2: wdt at 4ae14000 {
>> +            compatible = "ti,omap4-wdt";
>> +            reg = <0x4ae14000 0x80>;
>> +            interrupts = <0 80 0x4>;
>> +            ti,hwmods = "wd_timer2";
>> +        };
>> +
>> +        i2c1: i2c at 48070000 {
>> +            compatible = "ti,omap4-i2c";
>> +            reg = <0x48070000 0x100>;
>> +            interrupts = <0 56 0x4>;
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +            ti,hwmods = "i2c1";
>> +        };
>> +
>> +        i2c2: i2c at 48072000 {
>> +            compatible = "ti,omap4-i2c";
>> +            reg = <0x48072000 0x100>;
>> +            interrupts = <0 57 0x4>;
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +            ti,hwmods = "i2c2";
>> +        };
>> +
>> +        i2c3: i2c at 48060000 {
>> +            compatible = "ti,omap4-i2c";
>> +            reg = <0x48060000 0x100>;
>> +            interrupts = <0 61 0x4>;
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +            ti,hwmods = "i2c3";
>> +        };
>> +
>> +        i2c4: i2c at 4807a000 {
>> +            compatible = "ti,omap4-i2c";
>> +            reg = <0x4807a000 0x100>;
>> +            interrupts = <0 62 0x4>;
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +            ti,hwmods = "i2c4";
>> +        };
>> +
>> +        i2c5: i2c at 4807c000 {
>> +            compatible = "ti,omap4-i2c";
>> +            reg = <0x4807c000 0x100>;
>> +            interrupts = <0 60 0x4>;
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +            ti,hwmods = "i2c5";
>> +        };
>> +
>> +        mmc1: mmc at 4809c000 {
>> +            compatible = "ti,omap4-hsmmc";
>> +            reg = <0x4809c000 0x400>;
>> +            interrupts = <0 83 0x4>;
>> +            ti,hwmods = "mmc1";
>> +            ti,dual-volt;
>> +            ti,needs-special-reset;
>> +            dmas = <&sdma 61>, <&sdma 62>;
>> +            dma-names = "tx", "rx";
>> +        };
>> +
>> +        mmc2: mmc at 480b4000 {
>> +            compatible = "ti,omap4-hsmmc";
>> +            reg = <0x480b4000 0x400>;
>> +            interrupts = <0 86 0x4>;
>> +            ti,hwmods = "mmc2";
>> +            ti,needs-special-reset;
>> +            dmas = <&sdma 47>, <&sdma 48>;
>> +            dma-names = "tx", "rx";
>> +        };
>> +
>> +        mmc3: mmc at 480ad000 {
>> +            compatible = "ti,omap4-hsmmc";
>> +            reg = <0x480ad000 0x400>;
>> +            interrupts = <0 94 0x4>;
>> +            ti,hwmods = "mmc3";
>> +            ti,needs-special-reset;
>> +            dmas = <&sdma 77>, <&sdma 78>;
>> +            dma-names = "tx", "rx";
>> +        };
>> +
>> +        mmc4: mmc at 480d1000 {
>> +            compatible = "ti,omap4-hsmmc";
>> +            reg = <0x480d1000 0x400>;
>> +            interrupts = <0 96 0x4>;
>> +            ti,hwmods = "mmc4";
>> +            ti,needs-special-reset;
>> +            dmas = <&sdma 57>, <&sdma 58>;
>> +            dma-names = "tx", "rx";
>> +        };
>> +
>> +        mcspi1: spi at 48098000 {
>> +            compatible = "ti,omap4-mcspi";
>> +            reg = <0x48098000 0x200>;
>> +            interrupts = <0 65 0x4>;
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +            ti,hwmods = "mcspi1";
>> +            ti,spi-num-cs = <4>;
>> +            dmas = <&sdma 35>,
>> +                   <&sdma 36>,
>> +                   <&sdma 37>,
>> +                   <&sdma 38>,
>> +                   <&sdma 39>,
>> +                   <&sdma 40>,
>> +                   <&sdma 41>,
>> +                   <&sdma 42>;
>> +            dma-names = "tx0", "rx0", "tx1", "rx1",
>> +                    "tx2", "rx2", "tx3", "rx3";
>> +        };
>> +
>> +        mcspi2: spi at 4809a000 {
>> +            compatible = "ti,omap4-mcspi";
>> +            reg = <0x4809a000 0x200>;
>> +            interrupts = <0 66 0x4>;
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +            ti,hwmods = "mcspi2";
>> +            ti,spi-num-cs = <2>;
>> +            dmas = <&sdma 43>,
>> +                   <&sdma 44>,
>> +                   <&sdma 45>,
>> +                   <&sdma 46>;
>> +            dma-names = "tx0", "rx0", "tx1", "rx1";
>> +        };
>> +
>> +        mcspi3: spi at 480b8000 {
>> +            compatible = "ti,omap4-mcspi";
>> +            reg = <0x480b8000 0x200>;
>> +            interrupts = <0 91 0x4>;
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +            ti,hwmods = "mcspi3";
>> +            ti,spi-num-cs = <2>;
>> +            dmas = <&sdma 15>, <&sdma 16>;
>> +            dma-names = "tx0", "rx0";
>> +        };
>> +
>> +        mcspi4: spi at 480ba000 {
>> +            compatible = "ti,omap4-mcspi";
>> +            reg = <0x480ba000 0x200>;
>> +            interrupts = <0 48 0x4>;
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +            ti,hwmods = "mcspi4";
>> +            ti,spi-num-cs = <1>;
>> +            dmas = <&sdma 70>, <&sdma 71>;
>> +            dma-names = "tx0", "rx0";
>> +        };
>> +    };
>> +};
>>
> ref: [1], we discussed that we should now be able to introduce all instances of h/w blocks into the dra7.dts. Further, considering [2]

hmm, thats a long discussion on crossbar driver that [1] points to. Do you want to summarize what you mean by 'introduce all instances of h/w blocks'

> would you not want to follow "status = disabled" for all modules by default and enable required modules in board file, so that we dont have to respin this yet again?

Well, I was just following the convention of whats already followed on existing OMAPs. See [3] for some views on these.

> 
> 
> [1] http://marc.info/?t=137416599400001&r=1&w=2
> [2] http://marc.info/?l=linux-omap&m=137510358229479&w=2
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086297.html



From nm at ti.com  Tue Jul 30 08:41:39 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 07:41:39 -0500
Subject: [PATCH v2 3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
In-Reply-To: <51F7B3E0.9020005@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-4-git-send-email-rnayak@ti.com> <51F7B100.2020600@ti.com>
 <51F7B3E0.9020005@ti.com>
Message-ID: <51F7B483.8060908@ti.com>

On 07/30/2013 07:38 AM, Rajendra Nayak wrote:
> On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote:
>> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>>> From: R Sricharan <r.sricharan at ti.com>
>> [...]
>>>    # Clock framework
>>>    obj-$(CONFIG_ARCH_OMAP2)        += $(clock-common) clock2xxx.o
>>> @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
>>>    obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
>>>    obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
>>>    obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
>>> +obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
>>> +obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
>>>
>>
>> are these in sync with DRA7 support being introduced for clock data in [1]?
>
> I don't want to have a dependency on those patches since I am not sure of them
> making it into 3.12.

Then we have to undo these changes again in clock data support. the chip 
wont bootup anyways without clock data information, so why not try and 
keep the changes that Tero is doing independent of these changes?

>
>>
>>
>> [1] http://marc.info/?l=linux-omap&m=137456411706971&w=2
>>
>


-- 
Regards,
Nishanth Menon


From robherring2 at gmail.com  Tue Jul 30 08:42:49 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 30 Jul 2013 07:42:49 -0500
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
Message-ID: <51F7B4C9.2060500@gmail.com>

On 07/30/2013 04:49 AM, Mark Rutland wrote:
> On Mon, Jul 29, 2013 at 09:18:43PM +0100, Rob Herring wrote:
>> On 07/29/2013 05:13 AM, Mark Rutland wrote:
>>> Hi Rob,
>>>
>>> On Sun, Jul 28, 2013 at 10:56:32PM +0100, Rob Herring wrote:
>>>> From: Rob Herring <rob.herring at calxeda.com>

[snip]

>>> One of the things changed in PSCI 0.2 was the SMC calling convention,
>>> though this isn't clear in the PSCI document. The function IDs for 32bit
>>> and 64bit callers may differ, and we need to support describing an
>>> arbitrary configuration of the two (same ID for both, different across
>>> 32-bit/64-bit, only supported for 64-bit, only supported for 32-bit).
>>>
>>> I'd like to ensure the binding can deal with that from the start. We
>>> could do this by having -32 and -64 variants of each function id (e.g.
>>> cpu_off-64) , if the IDs actually differ, and use the regular combined
>>> ID if they don't.
>>
>> Uggg. I guess I should have read the SMC calling convention doc... I was
>> simply documenting what is already in the PSCI doc, but obviously that
>> is not fully flushed out.
>>
>> How about something like this (for the complicated case of both 32 and
>> 64 bit):
>>
>> 	method		= "smc", "smc64";
>> 	psci_version	= <0x84000000 0xc4000000>;
>> 	cpu_suspend	= <0x84000001 0xc4000001>;
>> 	cpu_off		= <0x84000002 0xc4000002>;
>> 	cpu_on		= <0x84000003 0xc4000003>;
>>
>> "smc" is a synonym for smc32 for compatibility. The number and order of
>> methods determines the number and order of function IDs.
> 
> While this may be compatible with the arm implementation, it won't be
> compatible with the arm64 implementation, which assumes smc64 by
> default.
> 
> As far as I am aware, the implementations currently in use (KVM and Xen)
> use the same ID for both, so I think "smc" should cover an ID valid for
> a native register width calling convention, and "smc64" and "smc32"
> describing values only valid for 64-bit wide and 32-bit wide calling
> conventions respectively.

The problem is that does not work for a 32-bit kernel on 64-bit h/w as
native from the dts perspective is smc64. Just like the cpu bindings,
the binding cannot change based on 32 or 64 bit OS. I don't think we
really have to deal with that here. We can simply say "smc" is only for
"arm,psci" and deprecated for "arm,psci-0.2".

> I've added Christoffer, Marc, and Stefano to Cc in case they have any
> comments.
> 
>>
>> A variation on this would be keep method as is and add a "#psci-cells"
>> property to specify the number of function IDs. You can determine the
>> 64-bit vs. 32-bit support based on the function ID itself.
> 
> I don't think that's a good idea - part of the reasoning for specifying
> the IDs is to cater for those not aligned with the ID guidelines in the
> spec, so we can't assume their choice of ID value gives us any useful
> information as to how they may be used.

Kind of pointless to encode information into the IDs if you cannot rely
on that...

Rob


From maxime.ripard at free-electrons.com  Tue Jul 30 08:44:53 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 14:44:53 +0200
Subject: [PATCH 04/10] ARM: sun6i: Add restart code for the A31
In-Reply-To: <20130729140430.GA25264@e106331-lin.cambridge.arm.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374618312-19001-5-git-send-email-maxime.ripard@free-electrons.com>
 <20130729140430.GA25264@e106331-lin.cambridge.arm.com>
Message-ID: <20130730124453.GA12562@lukather>

Hi Mark,

On Mon, Jul 29, 2013 at 03:04:31PM +0100, Mark Rutland wrote:
> On Tue, Jul 23, 2013 at 11:25:06PM +0100, Maxime Ripard wrote:
> > The Allwinner A31 has a sligthly different watchdog that requires a
> > different restart code.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > ---
> >  arch/arm/mach-sunxi/sunxi.c | 37 +++++++++++++++++++++++++++++++++++++
> >  1 file changed, 37 insertions(+)
> > 
> > diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> > index 11326d9..c18ef3a 100644
> > --- a/arch/arm/mach-sunxi/sunxi.c
> > +++ b/arch/arm/mach-sunxi/sunxi.c
> > @@ -32,6 +32,15 @@
> >  #define SUN4I_WATCHDOG_MODE_ENABLE		(1 << 0)
> >  #define SUN4I_WATCHDOG_MODE_RESET_ENABLE	(1 << 1)
> >  
> > +#define SUN6I_WATCHDOG1_IRQ_REG		0x00
> > +#define SUN6I_WATCHDOG1_CTRL_REG	0x10
> > +#define SUN6I_WATCHDOG1_CTRL_RESTART		(1 << 0)
> > +#define SUN6I_WATCHDOG1_CONFIG_REG	0x14
> > +#define SUN6I_WATCHDOG1_CONFIG_RESTART		(1 << 0)
> > +#define SUN6I_WATCHDOG1_CONFIG_IRQ		(1 << 1)
> > +#define SUN6I_WATCHDOG1_MODE_REG	0x18
> > +#define SUN6I_WATCHDOG1_MODE_ENABLE		(1 << 0)
> > +
> >  static void __iomem *wdt_base;
> >  
> >  static void sun4i_restart(enum reboot_mode mode, const char *cmd)
> > @@ -56,8 +65,36 @@ static void sun4i_restart(enum reboot_mode mode, const char *cmd)
> >  	}
> >  }
> >  
> > +static void sun6i_restart(char mode, const char *cmd)
> > +{
> > +	if (!wdt_base)
> > +		return;
> > +
> > +	/* Disable interrupts */
> > +	writel(0, wdt_base + SUN6I_WATCHDOG1_IRQ_REG);
> > +
> > +	/* We want to disable the IRQ and just reset the whole system */
> > +	writel(SUN6I_WATCHDOG1_CONFIG_RESTART,
> > +		wdt_base + SUN6I_WATCHDOG1_CONFIG_REG);
> > +
> > +	/* Enable timer. The default and lowest interval value is 0.5s */
> > +	writel(SUN6I_WATCHDOG1_MODE_ENABLE,
> > +		wdt_base + SUN6I_WATCHDOG1_MODE_REG);
> > +
> > +	/* Restart the watchdog. */
> > +	writel(SUN6I_WATCHDOG1_CTRL_RESTART,
> > +		wdt_base + SUN6I_WATCHDOG1_CTRL_REG);
> > +
> > +	while (1) {
> > +		mdelay(5);
> > +		writel(SUN6I_WATCHDOG1_MODE_ENABLE,
> > +			wdt_base + SUN6I_WATCHDOG1_MODE_REG);
> > +	}
> > +}
> > +
> >  static struct of_device_id sunxi_restart_ids[] = {
> >  	{ .compatible = "allwinner,sun4i-wdt", .data = sun4i_restart },
> > +	{ .compatible = "allwinner,sun6i-wdt", .data = sun6i_restart },
> 
> Is there a corresponding binding document addition? 
> 
> sun4i-wdt.txt could be turned into a more general sunxi-wdt.txt.

Ah, right, thanks!

I'll fix it in the v2.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130730/11fa10a6/attachment.sig>

From nm at ti.com  Tue Jul 30 08:46:21 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 07:46:21 -0500
Subject: [PATCH v2 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC
 and dra7-evm board
In-Reply-To: <51F7B477.9010701@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-9-git-send-email-rnayak@ti.com> <51F7B1E0.4060800@ti.com>
 <51F7B477.9010701@ti.com>
Message-ID: <51F7B59D.5080607@ti.com>

On 07/30/2013 07:41 AM, Rajendra Nayak wrote:
> On Tuesday 30 July 2013 06:00 PM, Nishanth Menon wrote:
>> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>>> From: R Sricharan <r.sricharan at ti.com>
[...]
>>> +        mcspi4: spi at 480ba000 {
>>> +            compatible = "ti,omap4-mcspi";
>>> +            reg = <0x480ba000 0x200>;
>>> +            interrupts = <0 48 0x4>;
>>> +            #address-cells = <1>;
>>> +            #size-cells = <0>;
>>> +            ti,hwmods = "mcspi4";
>>> +            ti,spi-num-cs = <1>;
>>> +            dmas = <&sdma 70>, <&sdma 71>;
>>> +            dma-names = "tx0", "rx0";
>>> +        };
>>> +    };
>>> +};
>>>
>> ref: [1], we discussed that we should now be able to introduce all instances of h/w blocks into the dra7.dts. Further, considering [2]
>
> hmm, thats a long discussion on crossbar driver that [1] points to. Do you want to summarize what you mean by 'introduce all instances of h/w blocks'

I recommend reading the last few emails on the thread about how we could 
do this with pinctrl. unfortunately, this patch is not informative 
enough to indicate that not all instances of the potential IP blocks are 
listed here.

>
>> would you not want to follow "status = disabled" for all modules by default and enable required modules in board file, so that we dont have to respin this yet again?
>
> Well, I was just following the convention of whats already followed on existing OMAPs. See [3] for some views on these.

DRA7 case, I would not think it makes sense due to the number of product 
variants being done, not all will use the same set. Further, rationale 
for DRA7 and my suggestion for Grant's option (1) is mainly because the 
product variants will require more dtsis rather than board files using 
the product variants use just the necessary modules from a common dtsi. 
Makes support of variants like OMAP57xx etc trivial and constrainted to 
board file usage, rather than spinning off new dtsis.

>
>>
>>
>> [1] http://marc.info/?t=137416599400001&r=1&w=2
>> [2] http://marc.info/?l=linux-omap&m=137510358229479&w=2
> [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086297.html
>


-- 
Regards,
Nishanth Menon


From rnayak at ti.com  Tue Jul 30 08:48:44 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 18:18:44 +0530
Subject: [PATCH v2 3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
In-Reply-To: <51F7B483.8060908@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-4-git-send-email-rnayak@ti.com> <51F7B100.2020600@ti.com>
 <51F7B3E0.9020005@ti.com> <51F7B483.8060908@ti.com>
Message-ID: <51F7B62C.9010407@ti.com>

On Tuesday 30 July 2013 06:11 PM, Nishanth Menon wrote:
> On 07/30/2013 07:38 AM, Rajendra Nayak wrote:
>> On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote:
>>> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>>>> From: R Sricharan <r.sricharan at ti.com>
>>> [...]
>>>>    # Clock framework
>>>>    obj-$(CONFIG_ARCH_OMAP2)        += $(clock-common) clock2xxx.o
>>>> @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
>>>>    obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
>>>>    obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
>>>>    obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
>>>> +obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
>>>> +obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
>>>>
>>>
>>> are these in sync with DRA7 support being introduced for clock data in [1]?
>>
>> I don't want to have a dependency on those patches since I am not sure of them
>> making it into 3.12.
> 
> Then we have to undo these changes again in clock data support. the chip wont bootup anyways without clock data information, so why not try and keep the changes that Tero is doing independent of these changes?

I still have something with clock data information which boots which I am maintaining out of tree till the clock movement to DT is sorted out.
Maybe what you are suggesting is quite trivial and I am unable to understand. Are you suggesting we do no compile $(clock-common) and the
dpll files for DRA7? Is that what you are worried we might have to revert?

> 
>>
>>>
>>>
>>> [1] http://marc.info/?l=linux-omap&m=137456411706971&w=2
>>>
>>
> 
> 



From marc.zyngier at arm.com  Tue Jul 30 08:56:46 2013
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 30 Jul 2013 13:56:46 +0100
Subject: [PATCH V4] arm64: KVM: Support X-Gene guest VCPU on APM X-Gene
 host
In-Reply-To: <CAAhSdy29wvVcmwaUh5PfJTrw4R+MeDrLoWWOPwpnhw2hDvKmKg@mail.gmail.com>
References: <1374471119-26461-1-git-send-email-anup.patel@linaro.org>
 <CAAhSdy29wvVcmwaUh5PfJTrw4R+MeDrLoWWOPwpnhw2hDvKmKg@mail.gmail.com>
Message-ID: <51F7B80E.3040905@arm.com>

On 30/07/13 12:57, Anup Patel wrote:
> On Mon, Jul 22, 2013 at 11:01 AM, Anup Patel <anup.patel at linaro.org> wrote:
>> This patch allows us to have X-Gene guest VCPU when using KVM arm64
>> on APM X-Gene host.
>>
>> We add KVM_ARM_TARGET_XGENE_POTENZA for X-Gene Potenza compatible
>> guest VCPU and we return KVM_ARM_TARGET_XGENE_POTENZA in kvm_target_cpu()
>> when running on X-Gene host with Potenza core.

[...]

> Hi Marc,
> 
> Do you think more changes are required to this patch ?

Hi Anup,

It looks OK to me as it is. I'll queue it for 3.12.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



From rnayak at ti.com  Tue Jul 30 08:56:47 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 18:26:47 +0530
Subject: [PATCH v2 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC
 and dra7-evm board
In-Reply-To: <51F7B59D.5080607@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-9-git-send-email-rnayak@ti.com> <51F7B1E0.4060800@ti.com>
 <51F7B477.9010701@ti.com> <51F7B59D.5080607@ti.com>
Message-ID: <51F7B80F.8090202@ti.com>

On Tuesday 30 July 2013 06:16 PM, Nishanth Menon wrote:
> On 07/30/2013 07:41 AM, Rajendra Nayak wrote:
>> On Tuesday 30 July 2013 06:00 PM, Nishanth Menon wrote:
>>> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>>>> From: R Sricharan <r.sricharan at ti.com>
> [...]
>>>> +        mcspi4: spi at 480ba000 {
>>>> +            compatible = "ti,omap4-mcspi";
>>>> +            reg = <0x480ba000 0x200>;
>>>> +            interrupts = <0 48 0x4>;
>>>> +            #address-cells = <1>;
>>>> +            #size-cells = <0>;
>>>> +            ti,hwmods = "mcspi4";
>>>> +            ti,spi-num-cs = <1>;
>>>> +            dmas = <&sdma 70>, <&sdma 71>;
>>>> +            dma-names = "tx0", "rx0";
>>>> +        };
>>>> +    };
>>>> +};
>>>>
>>> ref: [1], we discussed that we should now be able to introduce all instances of h/w blocks into the dra7.dts. Further, considering [2]
>>
>> hmm, thats a long discussion on crossbar driver that [1] points to. Do you want to summarize what you mean by 'introduce all instances of h/w blocks'
> 
> I recommend reading the last few emails on the thread about how we could do this with pinctrl. unfortunately, this patch is not informative enough to indicate that not all instances of the potential IP blocks are listed here.
> 
>>
>>> would you not want to follow "status = disabled" for all modules by default and enable required modules in board file, so that we dont have to respin this yet again?
>>
>> Well, I was just following the convention of whats already followed on existing OMAPs. See [3] for some views on these.
> 
> DRA7 case, I would not think it makes sense due to the number of product variants being done, not all will use the same set. Further, rationale for DRA7 and my suggestion for Grant's option (1) is mainly because the product variants will require more dtsis rather than board files using the product variants use just the necessary modules from a common dtsi. Makes support of variants like OMAP57xx etc trivial and constrainted to board file usage, rather than spinning off new dtsis.

Makes sense with the different product variants for DRA7, AM335x already does it this way, but the rest of OMAP3/4/5 are doing it the other way.
I think its just too confusing to follow different conventions for different SoCs. We should stick to just one, either this way or that.

> 
>>
>>>
>>>
>>> [1] http://marc.info/?t=137416599400001&r=1&w=2
>>> [2] http://marc.info/?l=linux-omap&m=137510358229479&w=2
>> [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086297.html
>>
> 
> 



From mark.rutland at arm.com  Tue Jul 30 08:56:50 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 30 Jul 2013 13:56:50 +0100
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <51F7B4C9.2060500@gmail.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
 <51F7B4C9.2060500@gmail.com>
Message-ID: <20130730125650.GD28716@e106331-lin.cambridge.arm.com>

On Tue, Jul 30, 2013 at 01:42:49PM +0100, Rob Herring wrote:
> On 07/30/2013 04:49 AM, Mark Rutland wrote:
> > On Mon, Jul 29, 2013 at 09:18:43PM +0100, Rob Herring wrote:
> >> On 07/29/2013 05:13 AM, Mark Rutland wrote:
> >>> Hi Rob,
> >>>
> >>> On Sun, Jul 28, 2013 at 10:56:32PM +0100, Rob Herring wrote:
> >>>> From: Rob Herring <rob.herring at calxeda.com>
> 
> [snip]
> 
> >>> One of the things changed in PSCI 0.2 was the SMC calling convention,
> >>> though this isn't clear in the PSCI document. The function IDs for 32bit
> >>> and 64bit callers may differ, and we need to support describing an
> >>> arbitrary configuration of the two (same ID for both, different across
> >>> 32-bit/64-bit, only supported for 64-bit, only supported for 32-bit).
> >>>
> >>> I'd like to ensure the binding can deal with that from the start. We
> >>> could do this by having -32 and -64 variants of each function id (e.g.
> >>> cpu_off-64) , if the IDs actually differ, and use the regular combined
> >>> ID if they don't.
> >>
> >> Uggg. I guess I should have read the SMC calling convention doc... I was
> >> simply documenting what is already in the PSCI doc, but obviously that
> >> is not fully flushed out.
> >>
> >> How about something like this (for the complicated case of both 32 and
> >> 64 bit):
> >>
> >> 	method		= "smc", "smc64";
> >> 	psci_version	= <0x84000000 0xc4000000>;
> >> 	cpu_suspend	= <0x84000001 0xc4000001>;
> >> 	cpu_off		= <0x84000002 0xc4000002>;
> >> 	cpu_on		= <0x84000003 0xc4000003>;
> >>
> >> "smc" is a synonym for smc32 for compatibility. The number and order of
> >> methods determines the number and order of function IDs.
> > 
> > While this may be compatible with the arm implementation, it won't be
> > compatible with the arm64 implementation, which assumes smc64 by
> > default.
> > 
> > As far as I am aware, the implementations currently in use (KVM and Xen)
> > use the same ID for both, so I think "smc" should cover an ID valid for
> > a native register width calling convention, and "smc64" and "smc32"
> > describing values only valid for 64-bit wide and 32-bit wide calling
> > conventions respectively.
> 
> The problem is that does not work for a 32-bit kernel on 64-bit h/w as
> native from the dts perspective is smc64. Just like the cpu bindings,
> the binding cannot change based on 32 or 64 bit OS. I don't think we
> really have to deal with that here. We can simply say "smc" is only for
> "arm,psci" and deprecated for "arm,psci-0.2".

Agreed. I'd be happy with only having "smc32" and "smc64" for
"arm,psci-0.2".

Thanks,
Mark.


From sergei.shtylyov at cogentembedded.com  Tue Jul 30 08:57:06 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 30 Jul 2013 16:57:06 +0400
Subject: [PATCH 5/5] ARM: shmobile: ape6evm: add SDHI interfaces
In-Reply-To: <f79d68da510bf1b95beff4d556b78d06801f11dc.1375174556.git.horms+renesas@verge.net.au>
References: <cover.1375174556.git.horms+renesas@verge.net.au>
 <f79d68da510bf1b95beff4d556b78d06801f11dc.1375174556.git.horms+renesas@verge.net.au>
Message-ID: <51F7B822.7020404@cogentembedded.com>

Hello.

On 30-07-2013 13:00, Simon Horman wrote:

> From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

> Add support for SDHI0 and SDHI1 on APE6EVM in PIO mode only.

> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> ---
>   arch/arm/mach-shmobile/board-ape6evm.c | 50 +++++++++++++++++++++++++++++++++-
>   1 file changed, 49 insertions(+), 1 deletion(-)

> diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
> index 8c7529c..ccf8b04 100644
> --- a/arch/arm/mach-shmobile/board-ape6evm.c
> +++ b/arch/arm/mach-shmobile/board-ape6evm.c
[...]
> @@ -75,6 +82,29 @@ static struct resource mmcif0_resources[] = {
>   	DEFINE_RES_IRQ(gic_spi(169)),
>   };
>
> +/* SDHI0 */
> +static struct sh_mobile_sdhi_info sdhi0_pdata = {
> +	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE,
> +	.tmio_caps	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
> +};
> +
> +static struct resource sdhi0_resources[] = {
> +	DEFINE_RES_MEM_NAMED(0xee100000, 0x100, "SDHI0"),
> +	DEFINE_RES_IRQ(gic_spi(165)),
> +};
> +
> +/* SDHI1 */
> +static struct sh_mobile_sdhi_info sdhi1_pdata = {
> +	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE,
> +	.tmio_caps	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
> +			  MMC_CAP_NEEDS_POLL,
> +};
> +
> +static struct resource sdhi1_resources[] = {
> +	DEFINE_RES_MEM_NAMED(0xee120000, 0x100, "SDHI1"),
> +	DEFINE_RES_IRQ(gic_spi(166)),
> +};
> +

    All of the above are lacking '__initdata' annothation (the resources and 
platform data will be kmemdup()'ed when registering the platform devices). Too 
bad I've noticed this too late...

> @@ -124,6 +166,12 @@ static void __init ape6evm_add_standard_devices(void)
>   	platform_device_register_resndata(&platform_bus, "sh_mmcif", 0,
>   					  mmcif0_resources, ARRAY_SIZE(mmcif0_resources),
>   					  &mmcif0_pdata, sizeof(mmcif0_pdata));
> +	platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0,
> +					  sdhi0_resources, ARRAY_SIZE(sdhi0_resources),
> +					  &sdhi0_pdata, sizeof(sdhi0_pdata));
> +	platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 1,
> +					  sdhi1_resources, ARRAY_SIZE(sdhi1_resources),
> +					  &sdhi1_pdata, sizeof(sdhi1_pdata));
>   }

WBR, Sergei



From nm at ti.com  Tue Jul 30 08:57:52 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 07:57:52 -0500
Subject: [PATCH v2 3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
In-Reply-To: <51F7B62C.9010407@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-4-git-send-email-rnayak@ti.com> <51F7B100.2020600@ti.com>
 <51F7B3E0.9020005@ti.com> <51F7B483.8060908@ti.com> <51F7B62C.9010407@ti.com>
Message-ID: <51F7B850.5090803@ti.com>

On 07/30/2013 07:48 AM, Rajendra Nayak wrote:
> On Tuesday 30 July 2013 06:11 PM, Nishanth Menon wrote:
>> On 07/30/2013 07:38 AM, Rajendra Nayak wrote:
>>> On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote:
>>>> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>>>>> From: R Sricharan <r.sricharan at ti.com>
>>>> [...]
>>>>>     # Clock framework
>>>>>     obj-$(CONFIG_ARCH_OMAP2)        += $(clock-common) clock2xxx.o
>>>>> @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
>>>>>     obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
>>>>>     obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
>>>>>     obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
>>>>> +obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
>>>>> +obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
>>>>>
>>>>
>>>> are these in sync with DRA7 support being introduced for clock data in [1]?
>>>
>>> I don't want to have a dependency on those patches since I am not sure of them
>>> making it into 3.12.
>>
>> Then we have to undo these changes again in clock data support. the chip wont bootup anyways without clock data information, so why not try and keep the changes that Tero is doing independent of these changes?
>
> I still have something with clock data information which boots which I am maintaining out of tree till the clock movement to DT is sorted out.
> Maybe what you are suggesting is quite trivial and I am unable to understand. Are you suggesting we do no compile $(clock-common) and the
> dpll files for DRA7? Is that what you are worried we might have to revert?

yes - lets just drop that change. that allows what ever alignment we 
have for clock data/driver to handle it appropriately. IMHO, could also 
keeps your series independent from Tero's series.

>>
>>>
>>>>
>>>>
>>>> [1] http://marc.info/?l=linux-omap&m=137456411706971&w=2
>>>>
>>>
>>
>>
>


-- 
Regards,
Nishanth Menon


From sergei.shtylyov at cogentembedded.com  Tue Jul 30 08:59:28 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 30 Jul 2013 16:59:28 +0400
Subject: [PATCH 4/5] ARM: shmobile: ape6evm: add MMCIF support
In-Reply-To: <8711613252ed931037f9e9f8646935519dd8f362.1375174556.git.horms+renesas@verge.net.au>
References: <cover.1375174556.git.horms+renesas@verge.net.au>
 <8711613252ed931037f9e9f8646935519dd8f362.1375174556.git.horms+renesas@verge.net.au>
Message-ID: <51F7B8B0.3080201@cogentembedded.com>

Hello.

On 30-07-2013 13:00, Simon Horman wrote:

> From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

> Add MMCIF support to the APE6EVM board in PIO mode only. Power supply is
> fixed for now, eventually support for the tps80032 regulator, also
> supplying both VDD and VccQ to the MMCIF slot should be added to APE6EVM.

> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> Acked-by: Magnus Damm <damm at opensource.se>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> ---
>   arch/arm/mach-shmobile/board-ape6evm.c | 31 +++++++++++++++++++++++++++++++
>   1 file changed, 31 insertions(+)

> diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
> index af6dd39..8c7529c 100644
> --- a/arch/arm/mach-shmobile/board-ape6evm.c
> +++ b/arch/arm/mach-shmobile/board-ape6evm.c
[...]
> @@ -54,6 +56,25 @@ static const struct smsc911x_platform_config lan9220_data = {
[...]
> +/* MMCIF */
> +static struct sh_mmcif_plat_data mmcif0_pdata = {
> +	.caps		= MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
> +};
> +
> +static struct resource mmcif0_resources[] = {
> +	DEFINE_RES_MEM_NAMED(0xee200000, 0x100, "MMCIF0"),
> +	DEFINE_RES_IRQ(gic_spi(169)),
> +};
> +

    The above needed '__initdata' too. And I have only noticed...

>   static const struct pinctrl_map ape6evm_pinctrl_map[] = {
>   	/* SCIFA0 console */
>   	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a73a4",
[...]
> @@ -93,6 +119,11 @@ static void __init ape6evm_add_standard_devices(void)
>   	platform_device_register_resndata(&platform_bus, "smsc911x", -1,
>   					  lan9220_res, ARRAY_SIZE(lan9220_res),
>   					  &lan9220_data, sizeof(lan9220_data));
> +	regulator_register_always_on(1, "fixed-3.3V", fixed3v3_power_consumers,
> +				     ARRAY_SIZE(fixed3v3_power_consumers), 3300000);
> +	platform_device_register_resndata(&platform_bus, "sh_mmcif", 0,
> +					  mmcif0_resources, ARRAY_SIZE(mmcif0_resources),
> +					  &mmcif0_pdata, sizeof(mmcif0_pdata));
>   }

WBR, Sergei



From rnayak at ti.com  Tue Jul 30 08:59:30 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 18:29:30 +0530
Subject: [PATCH v2 3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
In-Reply-To: <51F7B850.5090803@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-4-git-send-email-rnayak@ti.com> <51F7B100.2020600@ti.com>
 <51F7B3E0.9020005@ti.com> <51F7B483.8060908@ti.com> <51F7B62C.9010407@ti.com>
 <51F7B850.5090803@ti.com>
Message-ID: <51F7B8B2.90006@ti.com>

On Tuesday 30 July 2013 06:27 PM, Nishanth Menon wrote:
> On 07/30/2013 07:48 AM, Rajendra Nayak wrote:
>> On Tuesday 30 July 2013 06:11 PM, Nishanth Menon wrote:
>>> On 07/30/2013 07:38 AM, Rajendra Nayak wrote:
>>>> On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote:
>>>>> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>>>>>> From: R Sricharan <r.sricharan at ti.com>
>>>>> [...]
>>>>>>     # Clock framework
>>>>>>     obj-$(CONFIG_ARCH_OMAP2)        += $(clock-common) clock2xxx.o
>>>>>> @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
>>>>>>     obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
>>>>>>     obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
>>>>>>     obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
>>>>>> +obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
>>>>>> +obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
>>>>>>
>>>>>
>>>>> are these in sync with DRA7 support being introduced for clock data in [1]?
>>>>
>>>> I don't want to have a dependency on those patches since I am not sure of them
>>>> making it into 3.12.
>>>
>>> Then we have to undo these changes again in clock data support. the chip wont bootup anyways without clock data information, so why not try and keep the changes that Tero is doing independent of these changes?
>>
>> I still have something with clock data information which boots which I am maintaining out of tree till the clock movement to DT is sorted out.
>> Maybe what you are suggesting is quite trivial and I am unable to understand. Are you suggesting we do no compile $(clock-common) and the
>> dpll files for DRA7? Is that what you are worried we might have to revert?
> 
> yes - lets just drop that change. that allows what ever alignment we have for clock data/driver to handle it appropriately. IMHO, could also keeps your series independent from Tero's series.

I can drop those. no issues.

> 
>>>
>>>>
>>>>>
>>>>>
>>>>> [1] http://marc.info/?l=linux-omap&m=137456411706971&w=2
>>>>>
>>>>
>>>
>>>
>>
> 
> 



From nm at ti.com  Tue Jul 30 08:59:54 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 07:59:54 -0500
Subject: [PATCH v2 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC
 and dra7-evm board
In-Reply-To: <51F7B80F.8090202@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-9-git-send-email-rnayak@ti.com> <51F7B1E0.4060800@ti.com>
 <51F7B477.9010701@ti.com> <51F7B59D.5080607@ti.com> <51F7B80F.8090202@ti.com>
Message-ID: <51F7B8CA.9050707@ti.com>

On 07/30/2013 07:56 AM, Rajendra Nayak wrote:
> On Tuesday 30 July 2013 06:16 PM, Nishanth Menon wrote:
>> On 07/30/2013 07:41 AM, Rajendra Nayak wrote:
>>> On Tuesday 30 July 2013 06:00 PM, Nishanth Menon wrote:
>>>> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>>>>> From: R Sricharan <r.sricharan at ti.com>
>> [...]
>>>>> +        mcspi4: spi at 480ba000 {
>>>>> +            compatible = "ti,omap4-mcspi";
>>>>> +            reg = <0x480ba000 0x200>;
>>>>> +            interrupts = <0 48 0x4>;
>>>>> +            #address-cells = <1>;
>>>>> +            #size-cells = <0>;
>>>>> +            ti,hwmods = "mcspi4";
>>>>> +            ti,spi-num-cs = <1>;
>>>>> +            dmas = <&sdma 70>, <&sdma 71>;
>>>>> +            dma-names = "tx0", "rx0";
>>>>> +        };
>>>>> +    };
>>>>> +};
>>>>>
>>>> ref: [1], we discussed that we should now be able to introduce all instances of h/w blocks into the dra7.dts. Further, considering [2]
>>>
>>> hmm, thats a long discussion on crossbar driver that [1] points to. Do you want to summarize what you mean by 'introduce all instances of h/w blocks'
>>
>> I recommend reading the last few emails on the thread about how we could do this with pinctrl. unfortunately, this patch is not informative enough to indicate that not all instances of the potential IP blocks are listed here.
>>
>>>
>>>> would you not want to follow "status = disabled" for all modules by default and enable required modules in board file, so that we dont have to respin this yet again?
>>>
>>> Well, I was just following the convention of whats already followed on existing OMAPs. See [3] for some views on these.
>>
>> DRA7 case, I would not think it makes sense due to the number of product variants being done, not all will use the same set. Further, rationale for DRA7 and my suggestion for Grant's option (1) is mainly because the product variants will require more dtsis rather than board files using the product variants use just the necessary modules from a common dtsi. Makes support of variants like OMAP57xx etc trivial and constrainted to board file usage, rather than spinning off new dtsis.
>
> Makes sense with the different product variants for DRA7, AM335x already does it this way, but the rest of OMAP3/4/5 are doing it the other way.
> I think its just too confusing to follow different conventions for different SoCs. We should stick to just one, either this way or that.
>

I think bucketing DRA7(with multitude of SoC variants) with OMAP 
family(usually with <5 variants) will be a wrong approach. we should 
choose the approach appropriate for the SoC. hence, OMAPx having all 
default enabled makes sense (as the delta is usually trivial), but on 
DRA7, the variants are larger :(

just my 2 cents.

>>
>>>
>>>>
>>>>
>>>> [1] http://marc.info/?t=137416599400001&r=1&w=2
>>>> [2] http://marc.info/?l=linux-omap&m=137510358229479&w=2
>>> [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086297.html
>>>
>>
>>
>


-- 
Regards,
Nishanth Menon


From rnayak at ti.com  Tue Jul 30 09:01:26 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Tue, 30 Jul 2013 18:31:26 +0530
Subject: [PATCH v2 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC
 and dra7-evm board
In-Reply-To: <51F7B8CA.9050707@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-9-git-send-email-rnayak@ti.com> <51F7B1E0.4060800@ti.com>
 <51F7B477.9010701@ti.com> <51F7B59D.5080607@ti.com> <51F7B80F.8090202@ti.com>
 <51F7B8CA.9050707@ti.com>
Message-ID: <51F7B926.20602@ti.com>

On Tuesday 30 July 2013 06:29 PM, Nishanth Menon wrote:
> On 07/30/2013 07:56 AM, Rajendra Nayak wrote:
>> On Tuesday 30 July 2013 06:16 PM, Nishanth Menon wrote:
>>> On 07/30/2013 07:41 AM, Rajendra Nayak wrote:
>>>> On Tuesday 30 July 2013 06:00 PM, Nishanth Menon wrote:
>>>>> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>>>>>> From: R Sricharan <r.sricharan at ti.com>
>>> [...]
>>>>>> +        mcspi4: spi at 480ba000 {
>>>>>> +            compatible = "ti,omap4-mcspi";
>>>>>> +            reg = <0x480ba000 0x200>;
>>>>>> +            interrupts = <0 48 0x4>;
>>>>>> +            #address-cells = <1>;
>>>>>> +            #size-cells = <0>;
>>>>>> +            ti,hwmods = "mcspi4";
>>>>>> +            ti,spi-num-cs = <1>;
>>>>>> +            dmas = <&sdma 70>, <&sdma 71>;
>>>>>> +            dma-names = "tx0", "rx0";
>>>>>> +        };
>>>>>> +    };
>>>>>> +};
>>>>>>
>>>>> ref: [1], we discussed that we should now be able to introduce all instances of h/w blocks into the dra7.dts. Further, considering [2]
>>>>
>>>> hmm, thats a long discussion on crossbar driver that [1] points to. Do you want to summarize what you mean by 'introduce all instances of h/w blocks'
>>>
>>> I recommend reading the last few emails on the thread about how we could do this with pinctrl. unfortunately, this patch is not informative enough to indicate that not all instances of the potential IP blocks are listed here.
>>>
>>>>
>>>>> would you not want to follow "status = disabled" for all modules by default and enable required modules in board file, so that we dont have to respin this yet again?
>>>>
>>>> Well, I was just following the convention of whats already followed on existing OMAPs. See [3] for some views on these.
>>>
>>> DRA7 case, I would not think it makes sense due to the number of product variants being done, not all will use the same set. Further, rationale for DRA7 and my suggestion for Grant's option (1) is mainly because the product variants will require more dtsis rather than board files using the product variants use just the necessary modules from a common dtsi. Makes support of variants like OMAP57xx etc trivial and constrainted to board file usage, rather than spinning off new dtsis.
>>
>> Makes sense with the different product variants for DRA7, AM335x already does it this way, but the rest of OMAP3/4/5 are doing it the other way.
>> I think its just too confusing to follow different conventions for different SoCs. We should stick to just one, either this way or that.
>>
> 
> I think bucketing DRA7(with multitude of SoC variants) with OMAP family(usually with <5 variants) will be a wrong approach. we should choose the approach appropriate for the SoC. hence, OMAPx having all default enabled makes sense (as the delta is usually trivial), but on DRA7, the variants are larger :(
> 
> just my 2 cents.

I can respin with the changes, but before I do so, Benoit do you agree with the rationale for these and fine with the approach?

> 
>>>
>>>>
>>>>>
>>>>>
>>>>> [1] http://marc.info/?t=137416599400001&r=1&w=2
>>>>> [2] http://marc.info/?l=linux-omap&m=137510358229479&w=2
>>>> [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086297.html
>>>>
>>>
>>>
>>
> 
> 



From coelho at ti.com  Tue Jul 30 09:04:29 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 16:04:29 +0300
Subject: [PATCH v4 1/8] wl1251: split wl251 platform data to a separate
 structure
In-Reply-To: <1375189476-21557-1-git-send-email-coelho@ti.com>
References: <1375189476-21557-1-git-send-email-coelho@ti.com>
Message-ID: <1375189476-21557-2-git-send-email-coelho@ti.com>

Move the wl1251 part of the wl12xx platform data structure into a new
structure specifically for wl1251.  Change the platform data built-in
block and board files accordingly.

Cc: Tony Lindgren <tony at atomide.com>
Signed-off-by: Luciano Coelho <coelho at ti.com>
Acked-by: Tony Lindgren <tony at atomide.com>
Reviewed-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/mach-omap2/board-omap3pandora.c       |  4 +--
 arch/arm/mach-omap2/board-rx51-peripherals.c   |  2 +-
 drivers/net/wireless/ti/wilink_platform_data.c | 37 +++++++++++++++++++++-----
 drivers/net/wireless/ti/wl1251/sdio.c          | 12 ++++-----
 drivers/net/wireless/ti/wl1251/spi.c           |  2 +-
 include/linux/wl12xx.h                         | 22 ++++++++++++++-
 6 files changed, 62 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index b1547a0..84d56e8 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -541,7 +541,7 @@ static struct spi_board_info omap3pandora_spi_board_info[] __initdata = {
 
 static void __init pandora_wl1251_init(void)
 {
-	struct wl12xx_platform_data pandora_wl1251_pdata;
+	struct wl1251_platform_data pandora_wl1251_pdata;
 	int ret;
 
 	memset(&pandora_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
@@ -555,7 +555,7 @@ static void __init pandora_wl1251_init(void)
 		goto fail_irq;
 
 	pandora_wl1251_pdata.use_eeprom = true;
-	ret = wl12xx_set_platform_data(&pandora_wl1251_pdata);
+	ret = wl1251_set_platform_data(&pandora_wl1251_pdata);
 	if (ret < 0)
 		goto fail_irq;
 
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9c2dd10..01e5711 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -80,7 +80,7 @@ enum {
 	RX51_SPI_MIPID,		/* LCD panel */
 };
 
-static struct wl12xx_platform_data wl1251_pdata;
+static struct wl1251_platform_data wl1251_pdata;
 static struct tsc2005_platform_data tsc2005_pdata;
 
 #if defined(CONFIG_SENSORS_LIS3_I2C) || defined(CONFIG_SENSORS_LIS3_I2C_MODULE)
diff --git a/drivers/net/wireless/ti/wilink_platform_data.c b/drivers/net/wireless/ti/wilink_platform_data.c
index 998e958..a92bd3e 100644
--- a/drivers/net/wireless/ti/wilink_platform_data.c
+++ b/drivers/net/wireless/ti/wilink_platform_data.c
@@ -23,17 +23,17 @@
 #include <linux/err.h>
 #include <linux/wl12xx.h>
 
-static struct wl12xx_platform_data *platform_data;
+static struct wl12xx_platform_data *wl12xx_platform_data;
 
 int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
 {
-	if (platform_data)
+	if (wl12xx_platform_data)
 		return -EBUSY;
 	if (!data)
 		return -EINVAL;
 
-	platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
-	if (!platform_data)
+	wl12xx_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+	if (!wl12xx_platform_data)
 		return -ENOMEM;
 
 	return 0;
@@ -41,9 +41,34 @@ int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
 
 struct wl12xx_platform_data *wl12xx_get_platform_data(void)
 {
-	if (!platform_data)
+	if (!wl12xx_platform_data)
 		return ERR_PTR(-ENODEV);
 
-	return platform_data;
+	return wl12xx_platform_data;
 }
 EXPORT_SYMBOL(wl12xx_get_platform_data);
+
+static struct wl1251_platform_data *wl1251_platform_data;
+
+int __init wl1251_set_platform_data(const struct wl1251_platform_data *data)
+{
+	if (wl1251_platform_data)
+		return -EBUSY;
+	if (!data)
+		return -EINVAL;
+
+	wl1251_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+	if (!wl1251_platform_data)
+		return -ENOMEM;
+
+	return 0;
+}
+
+struct wl1251_platform_data *wl1251_get_platform_data(void)
+{
+	if (!wl1251_platform_data)
+		return ERR_PTR(-ENODEV);
+
+	return wl1251_platform_data;
+}
+EXPORT_SYMBOL(wl1251_get_platform_data);
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c b/drivers/net/wireless/ti/wl1251/sdio.c
index e2b3d9c..b75a37a 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -227,7 +227,7 @@ static int wl1251_sdio_probe(struct sdio_func *func,
 	struct wl1251 *wl;
 	struct ieee80211_hw *hw;
 	struct wl1251_sdio *wl_sdio;
-	const struct wl12xx_platform_data *wl12xx_board_data;
+	const struct wl1251_platform_data *wl1251_board_data;
 
 	hw = wl1251_alloc_hw();
 	if (IS_ERR(hw))
@@ -254,11 +254,11 @@ static int wl1251_sdio_probe(struct sdio_func *func,
 	wl->if_priv = wl_sdio;
 	wl->if_ops = &wl1251_sdio_ops;
 
-	wl12xx_board_data = wl12xx_get_platform_data();
-	if (!IS_ERR(wl12xx_board_data)) {
-		wl->set_power = wl12xx_board_data->set_power;
-		wl->irq = wl12xx_board_data->irq;
-		wl->use_eeprom = wl12xx_board_data->use_eeprom;
+	wl1251_board_data = wl1251_get_platform_data();
+	if (!IS_ERR(wl1251_board_data)) {
+		wl->set_power = wl1251_board_data->set_power;
+		wl->irq = wl1251_board_data->irq;
+		wl->use_eeprom = wl1251_board_data->use_eeprom;
 	}
 
 	if (wl->irq) {
diff --git a/drivers/net/wireless/ti/wl1251/spi.c b/drivers/net/wireless/ti/wl1251/spi.c
index c7dc6fe..6bbbfe6 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -238,7 +238,7 @@ static const struct wl1251_if_operations wl1251_spi_ops = {
 
 static int wl1251_spi_probe(struct spi_device *spi)
 {
-	struct wl12xx_platform_data *pdata;
+	struct wl1251_platform_data *pdata;
 	struct ieee80211_hw *hw;
 	struct wl1251 *wl;
 	int ret;
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index a54fe82..b516b4f 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -48,11 +48,15 @@ enum {
 	WL12XX_TCXOCLOCK_33_6	= 7, /* 33.6 MHz */
 };
 
-struct wl12xx_platform_data {
+struct wl1251_platform_data {
 	void (*set_power)(bool enable);
 	/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
 	int irq;
 	bool use_eeprom;
+};
+
+struct wl12xx_platform_data {
+	int irq;
 	int board_ref_clock;
 	int board_tcxo_clock;
 	unsigned long platform_quirks;
@@ -68,6 +72,10 @@ int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
 
 struct wl12xx_platform_data *wl12xx_get_platform_data(void);
 
+int wl1251_set_platform_data(const struct wl1251_platform_data *data);
+
+struct wl1251_platform_data *wl1251_get_platform_data(void);
+
 #else
 
 static inline
@@ -82,6 +90,18 @@ struct wl12xx_platform_data *wl12xx_get_platform_data(void)
 	return ERR_PTR(-ENODATA);
 }
 
+static inline
+int wl1251_set_platform_data(const struct wl1251_platform_data *data)
+{
+	return -ENOSYS;
+}
+
+static inline
+struct wl1251_platform_data *wl1251_get_platform_data(void)
+{
+	return ERR_PTR(-ENODATA);
+}
+
 #endif
 
 #endif
-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 09:04:28 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 16:04:28 +0300
Subject: [PATCH v4 0/8] wilink: add device tree support
Message-ID: <1375189476-21557-1-git-send-email-coelho@ti.com>

Hi,

This patch series adds device tree support to the wlcore_sdio driver,
which is used by WiLink6, WiLink7 and WiLink8.

The first patches do some clean-up to make the data needed in the
wilink device tree node smaller.  The remaining patches implement the
actual device tree node parsing in wlcore_sdio.

Regarding the XTAL clock issues, for now we don't support XTAL mode
with DT, but I have sent a proposal for a small change in the clock
framework to support this, but it's still under discussions [1].

The DTS file changes will be sent separately, since they need to go
via different trees.

A new version of the bindings documentation has been sent [2] and, if
no more comments are given to it, I'll apply it via my tree.

[1] http://news.gmane.org/find-root.php?message_id=1372971912-10877-1-git-send-email-coelho at ti.com
[2] http://news.gmane.org/find-root.php?message_id=1375109728-5931-1-git-send-email-coelho at ti.com

Changes in v4:

* Rebased on top of 3.11-rc3 (eg. no more changes on the board files
  that were removed);

* Use the new irq_get_trigger_type() instead of
  irqd_get_trigger_type() (thanks Javier);

* Added some missing const's (thanks Felipe);

* Reverted Tony's workaround to get WiLink to work on Panda while DT
  was not supported yet.


Please review.


Luciano Coelho (8):
  wl1251: split wl251 platform data to a separate structure
  wlcore: set irq_flags in the board files instead of hiding behind a
    quirk
  wlcore: remove pwr_in_suspend from platform data
  wl12xx: use frequency instead of enumerations for pdata clocks
  wlcore: add initial device tree support to the sdio module
  wlcore: sdio: add wilink clock providers
  wlcore: sdio: get clocks from device tree
  wlcore/wl12xx: check if we got correct clock data from DT

 arch/arm/mach-davinci/board-da850-evm.c        |  11 ++-
 arch/arm/mach-omap2/board-omap3evm.c           |  22 ++++-
 arch/arm/mach-omap2/board-omap3pandora.c       |   4 +-
 arch/arm/mach-omap2/board-rx51-peripherals.c   |   2 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c   |  33 +++++++-
 arch/arm/mach-omap2/devices.c                  |  39 ---------
 drivers/net/wireless/ti/wilink_platform_data.c |  37 ++++++--
 drivers/net/wireless/ti/wl1251/sdio.c          |  12 +--
 drivers/net/wireless/ti/wl1251/spi.c           |   2 +-
 drivers/net/wireless/ti/wl12xx/main.c          |  78 +++++++++++++++--
 drivers/net/wireless/ti/wl12xx/wl12xx.h        |  28 +++++++
 drivers/net/wireless/ti/wlcore/debugfs.c       |   2 +-
 drivers/net/wireless/ti/wlcore/main.c          |  20 ++---
 drivers/net/wireless/ti/wlcore/sdio.c          | 112 +++++++++++++++++++++++--
 drivers/net/wireless/ti/wlcore/wlcore.h        |   5 +-
 drivers/net/wireless/ti/wlcore/wlcore_i.h      |   1 +
 include/linux/wl12xx.h                         |  52 +++++-------
 17 files changed, 340 insertions(+), 120 deletions(-)

-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 09:04:31 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 16:04:31 +0300
Subject: [PATCH v4 3/8] wlcore: remove pwr_in_suspend from platform data
In-Reply-To: <1375189476-21557-1-git-send-email-coelho@ti.com>
References: <1375189476-21557-1-git-send-email-coelho@ti.com>
Message-ID: <1375189476-21557-4-git-send-email-coelho@ti.com>

The pwr_in_suspend flag depends on the MMC settings which can be
retrieved from the SDIO subsystem, so it doesn't need to be part of
the platform data structure.  Move it to the platform device data that
is passed from SDIO to wlcore.

Signed-off-by: Luciano Coelho <coelho at ti.com>
Reviewed-by: Felipe Balbi <balbi at ti.com>
---
 drivers/net/wireless/ti/wlcore/main.c     | 3 +--
 drivers/net/wireless/ti/wlcore/sdio.c     | 2 +-
 drivers/net/wireless/ti/wlcore/wlcore_i.h | 1 +
 include/linux/wl12xx.h                    | 1 -
 4 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 11dab9a..e771de0 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5900,7 +5900,6 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
 	struct wl1271 *wl = context;
 	struct platform_device *pdev = wl->pdev;
 	struct wlcore_platdev_data *pdev_data = pdev->dev.platform_data;
-	struct wl12xx_platform_data *pdata = pdev_data->pdata;
 
 	int ret;
 
@@ -5947,7 +5946,7 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
 	if (!ret) {
 		wl->irq_wake_enabled = true;
 		device_init_wakeup(wl->dev, 1);
-		if (pdata->pwr_in_suspend)
+		if (pdev_data->pwr_in_suspend)
 			wl->hw->wiphy->wowlan = &wlcore_wowlan_support;
 	}
 #endif
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 29ef249..4c7e8ac 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -260,7 +260,7 @@ static int wl1271_probe(struct sdio_func *func,
 	dev_dbg(glue->dev, "sdio PM caps = 0x%x\n", mmcflags);
 
 	if (mmcflags & MMC_PM_KEEP_POWER)
-		pdev_data->pdata->pwr_in_suspend = true;
+		pdev_data->pwr_in_suspend = true;
 
 	sdio_set_drvdata(func, glue);
 
diff --git a/drivers/net/wireless/ti/wlcore/wlcore_i.h b/drivers/net/wireless/ti/wlcore/wlcore_i.h
index e5e1464..f2c4227 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore_i.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore_i.h
@@ -209,6 +209,7 @@ struct wl1271_if_operations {
 struct wlcore_platdev_data {
 	struct wl12xx_platform_data *pdata;
 	struct wl1271_if_operations *if_ops;
+	bool pwr_in_suspend;
 };
 
 #define MAX_NUM_KEYS 14
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 1bfcd19..ab90b1c 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -59,7 +59,6 @@ struct wl12xx_platform_data {
 	int irq;
 	int board_ref_clock;
 	int board_tcxo_clock;
-	bool pwr_in_suspend;
 };
 
 #ifdef CONFIG_WILINK_PLATFORM_DATA
-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 09:04:30 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 16:04:30 +0300
Subject: [PATCH v4 2/8] wlcore: set irq_flags in the board files instead of
 hiding behind a quirk
In-Reply-To: <1375189476-21557-1-git-send-email-coelho@ti.com>
References: <1375189476-21557-1-git-send-email-coelho@ti.com>
Message-ID: <1375189476-21557-3-git-send-email-coelho@ti.com>

The platform_quirk element in the platform data was used to change the
way the IRQ is triggered.  When set, the EDGE_IRQ quirk would change
the irqflags used and treat edge trigger differently from the rest.

Instead of hiding this irq flag setting behind the quirk, have the
board files set the flags during initialization.  This will be more
meaningful than driver-specific quirks when we switch to DT.

Additionally, fix missing gpio_request() calls in the boarding files
(so that setting the flags actually works).

Cc: Tony Lindgren <tony at atomide.com>
Cc: Sekhar Nori <nsekhar at ti.com>
Signed-off-by: Luciano Coelho <coelho at ti.com>
Reviewed-by: Felipe Balbi <balbi at ti.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/board-da850-evm.c      |  8 +++++++-
 arch/arm/mach-omap2/board-omap3evm.c         | 19 ++++++++++++++++++
 arch/arm/mach-omap2/board-zoom-peripherals.c | 30 +++++++++++++++++++++++++---
 drivers/net/wireless/ti/wlcore/debugfs.c     |  2 +-
 drivers/net/wireless/ti/wlcore/main.c        | 17 ++++++++--------
 drivers/net/wireless/ti/wlcore/wlcore.h      |  5 ++---
 include/linux/wl12xx.h                       |  4 ----
 7 files changed, 64 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index bea6793..03de2e9 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1377,7 +1377,6 @@ static const short da850_wl12xx_pins[] __initconst = {
 static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
 	.irq			= -1,
 	.board_ref_clock	= WL12XX_REFCLOCK_38,
-	.platform_quirks	= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
 };
 
 static __init int da850_wl12xx_init(void)
@@ -1408,6 +1407,13 @@ static __init int da850_wl12xx_init(void)
 		goto free_wlan_en;
 	}
 
+	ret = irq_set_irq_type(gpio_to_irq(DA850_WLAN_IRQ),
+			       IRQ_TYPE_EDGE_RISING);
+	if (ret) {
+		pr_err("Could not set wl12xx irq type: %d\n", ret);
+		goto free;
+	}
+
 	da850_wl12xx_wlan_data.irq = gpio_to_irq(DA850_WLAN_IRQ);
 
 	ret = wl12xx_set_platform_data(&da850_wl12xx_wlan_data);
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 8c02626..9c7dfc5 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -614,12 +614,31 @@ static void __init omap3_evm_wl12xx_init(void)
 
 	/* WL12xx WLAN Init */
 	omap3evm_wlan_data.irq = gpio_to_irq(OMAP3EVM_WLAN_IRQ_GPIO);
+
+	ret = gpio_request_one(OMAP3EVM_WLAN_IRQ_GPIO, GPIOF_IN,
+			       "OMAP3EVM_WLAN_IRQ_GPIO");
+	if (ret) {
+		pr_err("error requesting wl12xx gpio: %d\n", ret);
+		goto out;
+	}
+
+	ret = irq_set_irq_type(gpio_to_irq(OMAP3EVM_WLAN_IRQ_GPIO),
+			       IRQ_TYPE_LEVEL_HIGH);
+	if (ret) {
+		pr_err("error setting wl12xx irq type: %d\n", ret);
+		goto free;
+	}
+
 	ret = wl12xx_set_platform_data(&omap3evm_wlan_data);
 	if (ret)
 		pr_err("error setting wl12xx data: %d\n", ret);
 	ret = platform_device_register(&omap3evm_wlan_regulator);
 	if (ret)
 		pr_err("error registering wl12xx device: %d\n", ret);
+out:
+	return;
+free:
+	gpio_free(OMAP3EVM_WLAN_IRQ_GPIO);
 #endif
 }
 
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
index a90375d..4f84cf9 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -339,16 +339,40 @@ static void enable_board_wakeup_source(void)
 		OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
 }
 
-void __init zoom_peripherals_init(void)
+static void __init zoom_wilink_init(void)
 {
 	int ret;
 
 	omap_zoom_wlan_data.irq = gpio_to_irq(OMAP_ZOOM_WLAN_IRQ_GPIO);
-	ret = wl12xx_set_platform_data(&omap_zoom_wlan_data);
 
-	if (ret)
+	ret = gpio_request_one(OMAP_ZOOM_WLAN_IRQ_GPIO, GPIOF_IN,
+			       "OMAP_ZOOM_WLAN_IRQ_GPIO");
+	if (ret) {
+		pr_err("error requesting wl12xx gpio: %d\n", ret);
+		goto out;
+	}
+
+	ret = irq_set_irq_type(gpio_to_irq(OMAP_ZOOM_WLAN_IRQ_GPIO),
+			       IRQ_TYPE_LEVEL_HIGH);
+	if (ret) {
+		pr_err("error setting wl12xx irq type: %d\n", ret);
+		goto free;
+	}
+
+	ret = wl12xx_set_platform_data(&omap_zoom_wlan_data);
+	if (ret) {
 		pr_err("error setting wl12xx data: %d\n", ret);
+		goto free;
+	}
+out:
+	return;
+free:
+	gpio_free(OMAP_ZOOM_WLAN_IRQ_GPIO);
+}
 
+void __init zoom_peripherals_init(void)
+{
+	zoom_wilink_init();
 	omap_hsmmc_init(mmc);
 	omap_i2c_init();
 	pwm_add_table(zoom_pwm_lookup, ARRAY_SIZE(zoom_pwm_lookup));
diff --git a/drivers/net/wireless/ti/wlcore/debugfs.c b/drivers/net/wireless/ti/wlcore/debugfs.c
index e17630c..9544477 100644
--- a/drivers/net/wireless/ti/wlcore/debugfs.c
+++ b/drivers/net/wireless/ti/wlcore/debugfs.c
@@ -486,7 +486,7 @@ static ssize_t driver_state_read(struct file *file, char __user *user_buf,
 	DRIVER_STATE_PRINT_HEX(irq);
 	/* TODO: ref_clock and tcxo_clock were moved to wl12xx priv */
 	DRIVER_STATE_PRINT_HEX(hw_pg_ver);
-	DRIVER_STATE_PRINT_HEX(platform_quirks);
+	DRIVER_STATE_PRINT_HEX(irq_flags);
 	DRIVER_STATE_PRINT_HEX(chip.id);
 	DRIVER_STATE_PRINT_STR(chip.fw_ver_str);
 	DRIVER_STATE_PRINT_STR(chip.phy_fw_ver_str);
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index b8db55c..11dab9a 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -27,6 +27,7 @@
 #include <linux/vmalloc.h>
 #include <linux/wl12xx.h>
 #include <linux/interrupt.h>
+#include <linux/irq.h>
 
 #include "wlcore.h"
 #include "debug.h"
@@ -516,7 +517,7 @@ static int wlcore_irq_locked(struct wl1271 *wl)
 	 * In case edge triggered interrupt must be used, we cannot iterate
 	 * more than once without introducing race conditions with the hardirq.
 	 */
-	if (wl->platform_quirks & WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
+	if (wl->irq_flags & IRQF_TRIGGER_RISING)
 		loopcount = 1;
 
 	wl1271_debug(DEBUG_IRQ, "IRQ work");
@@ -5765,7 +5766,6 @@ struct ieee80211_hw *wlcore_alloc_hw(size_t priv_size, u32 aggr_buf_size,
 	wl->ap_ps_map = 0;
 	wl->ap_fw_ps_map = 0;
 	wl->quirks = 0;
-	wl->platform_quirks = 0;
 	wl->system_hlid = WL12XX_SYSTEM_HLID;
 	wl->active_sta_count = 0;
 	wl->active_link_count = 0;
@@ -5901,7 +5901,7 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
 	struct platform_device *pdev = wl->pdev;
 	struct wlcore_platdev_data *pdev_data = pdev->dev.platform_data;
 	struct wl12xx_platform_data *pdata = pdev_data->pdata;
-	unsigned long irqflags;
+
 	int ret;
 
 	if (fw) {
@@ -5928,16 +5928,15 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
 	wlcore_adjust_conf(wl);
 
 	wl->irq = platform_get_irq(pdev, 0);
-	wl->platform_quirks = pdata->platform_quirks;
 	wl->if_ops = pdev_data->if_ops;
 
-	if (wl->platform_quirks & WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
-		irqflags = IRQF_TRIGGER_RISING;
-	else
-		irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
+	wl->irq_flags = irq_get_trigger_type(wl->irq);
+
+	/* Since we don't use the primary handler, we must set ONESHOT */
+	wl->irq_flags |= IRQF_ONESHOT;
 
 	ret = request_threaded_irq(wl->irq, NULL, wlcore_irq,
-				   irqflags, pdev->name, wl);
+				   wl->irq_flags, pdev->name, wl);
 	if (ret < 0) {
 		wl1271_error("request_irq() failed: %d", ret);
 		goto out_free_nvs;
diff --git a/drivers/net/wireless/ti/wlcore/wlcore.h b/drivers/net/wireless/ti/wlcore/wlcore.h
index 0034979..8306bde 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore.h
@@ -185,6 +185,8 @@ struct wl1271 {
 
 	int irq;
 
+	int irq_flags;
+
 	spinlock_t wl_lock;
 
 	enum wlcore_state state;
@@ -384,9 +386,6 @@ struct wl1271 {
 	/* Quirks of specific hardware revisions */
 	unsigned int quirks;
 
-	/* Platform limitations */
-	unsigned int platform_quirks;
-
 	/* number of currently active RX BA sessions */
 	int ba_rx_session_count;
 
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index b516b4f..1bfcd19 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -59,13 +59,9 @@ struct wl12xx_platform_data {
 	int irq;
 	int board_ref_clock;
 	int board_tcxo_clock;
-	unsigned long platform_quirks;
 	bool pwr_in_suspend;
 };
 
-/* Platform does not support level trigger interrupts */
-#define WL12XX_PLATFORM_QUIRK_EDGE_IRQ	BIT(0)
-
 #ifdef CONFIG_WILINK_PLATFORM_DATA
 
 int wl12xx_set_platform_data(const struct wl12xx_platform_data *data);
-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 09:04:33 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 16:04:33 +0300
Subject: [PATCH v4 5/8] wlcore: add initial device tree support to the sdio
 module
In-Reply-To: <1375189476-21557-1-git-send-email-coelho@ti.com>
References: <1375189476-21557-1-git-send-email-coelho@ti.com>
Message-ID: <1375189476-21557-6-git-send-email-coelho@ti.com>

If platform data is not available, try to get the required information
from the device tree.  Register an OF match table and parse the
appropriate device tree nodes.

Parse interrupt property only, for now.

Signed-off-by: Luciano Coelho <coelho at ti.com>
Reviewed-by: Felipe Balbi <balbi at ti.com>
---
 drivers/net/wireless/ti/wlcore/sdio.c | 69 ++++++++++++++++++++++++++++++++---
 1 file changed, 63 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 4c7e8ac..9370d7e 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -30,7 +30,7 @@
 #include <linux/mmc/sdio_ids.h>
 #include <linux/mmc/card.h>
 #include <linux/mmc/host.h>
-#include <linux/gpio.h>
+#include <linux/of_irq.h>
 #include <linux/wl12xx.h>
 #include <linux/pm_runtime.h>
 #include <linux/printk.h>
@@ -214,6 +214,43 @@ static struct wl1271_if_operations sdio_ops = {
 	.set_block_size = wl1271_sdio_set_block_size,
 };
 
+static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
+{
+	struct wl12xx_platform_data *pdata;
+	struct device_node *np = dev->of_node;
+
+	if (!np) {
+		np = of_find_matching_node(NULL, dev->driver->of_match_table);
+		if (!np) {
+			dev_notice(dev, "device tree node not available\n");
+			pdata = ERR_PTR(-ENODEV);
+			goto out;
+		}
+	}
+
+	pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+	if (!pdata) {
+		dev_err(dev, "can't allocate platform data\n");
+		pdata = ERR_PTR(-ENODEV);
+		goto out;
+	}
+
+	pdata->irq = irq_of_parse_and_map(np, 0);
+	if (pdata->irq < 0) {
+		dev_err(dev, "can't get interrupt gpio from the device tree\n");
+		goto out_free;
+	}
+
+	goto out;
+
+out_free:
+	kfree(pdata);
+	pdata = ERR_PTR(-ENODEV);
+
+out:
+	return pdata;
+}
+
 static int wl1271_probe(struct sdio_func *func,
 				  const struct sdio_device_id *id)
 {
@@ -248,11 +285,22 @@ static int wl1271_probe(struct sdio_func *func,
 	/* Use block mode for transferring over one block size of data */
 	func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
+	/* The pdata allocated here is freed when the device is freed,
+	 * so we don't need an additional out label to free it in case
+	 * of error further on.
+	 */
+
+	/* Try to get legacy platform data from the board file */
 	pdev_data->pdata = wl12xx_get_platform_data();
 	if (IS_ERR(pdev_data->pdata)) {
-		ret = PTR_ERR(pdev_data->pdata);
-		dev_err(glue->dev, "missing wlan platform data: %d\n", ret);
-		goto out_free_glue;
+		dev_info(&func->dev,
+			 "legacy platform data not found, trying device tree\n");
+
+		pdev_data->pdata = wlcore_get_pdata_from_of(&func->dev);
+		if (IS_ERR(pdev_data->pdata)) {
+			dev_err(&func->dev, "can't get platform data\n");
+			goto out_free_glue;
+		}
 	}
 
 	/* if sdio can keep power while host is suspended, enable wow */
@@ -386,16 +434,25 @@ static const struct dev_pm_ops wl1271_sdio_pm_ops = {
 };
 #endif
 
+static const struct of_device_id wlcore_sdio_of_match_table[] = {
+	{ .compatible = "ti,wilink6" },
+	{ .compatible = "ti,wilink7" },
+	{ .compatible = "ti,wilink8" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, wlcore_sdio_of_match_table);
+
 static struct sdio_driver wl1271_sdio_driver = {
 	.name		= "wl1271_sdio",
 	.id_table	= wl1271_devices,
 	.probe		= wl1271_probe,
 	.remove		= wl1271_remove,
-#ifdef CONFIG_PM
 	.drv = {
+#ifdef CONFIG_PM
 		.pm = &wl1271_sdio_pm_ops,
-	},
 #endif
+		.of_match_table = of_match_ptr(wlcore_sdio_of_match_table),
+	},
 };
 
 static int __init wl1271_init(void)
-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 09:04:34 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 16:04:34 +0300
Subject: [PATCH v4 6/8] wlcore: sdio: add wilink clock providers
In-Reply-To: <1375189476-21557-1-git-send-email-coelho@ti.com>
References: <1375189476-21557-1-git-send-email-coelho@ti.com>
Message-ID: <1375189476-21557-7-git-send-email-coelho@ti.com>

Add refclock and tcxoclock as clock providers in WiLink.  These clocks
are not accesible outside the WiLink module, but they are registered
in the clock framework anyway.  Only the WiLink chip consumes these
clocks.

In theory, the WiLink chip could be connected to external clocks
instead of using these internal clocks, so make the clock consumer
code generic enough.  If external clocks are used, then the internal
clock device tree nodes are not necessary, but the external ones must
be specified.

Signed-off-by: Luciano Coelho <coelho at ti.com>
Reviewed-by: Felipe Balbi <balbi at ti.com>
---
 drivers/net/wireless/ti/wlcore/sdio.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 9370d7e..980bf3d 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,7 @@
 #include <linux/wl12xx.h>
 #include <linux/pm_runtime.h>
 #include <linux/printk.h>
+#include <linux/clk-provider.h>
 
 #include "wlcore.h"
 #include "wl12xx_80211.h"
@@ -214,10 +215,15 @@ static struct wl1271_if_operations sdio_ops = {
 	.set_block_size = wl1271_sdio_set_block_size,
 };
 
+static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
+	{ .compatible = "ti,wilink-clock" },
+};
+
 static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 {
 	struct wl12xx_platform_data *pdata;
 	struct device_node *np = dev->of_node;
+	struct device_node *clock_node;
 
 	if (!np) {
 		np = of_find_matching_node(NULL, dev->driver->of_match_table);
@@ -241,6 +247,9 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 		goto out_free;
 	}
 
+	for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
+		of_fixed_clk_setup(clock_node);
+
 	goto out;
 
 out_free:
-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 09:04:32 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 16:04:32 +0300
Subject: [PATCH v4 4/8] wl12xx: use frequency instead of enumerations for
 pdata clocks
In-Reply-To: <1375189476-21557-1-git-send-email-coelho@ti.com>
References: <1375189476-21557-1-git-send-email-coelho@ti.com>
Message-ID: <1375189476-21557-5-git-send-email-coelho@ti.com>

Instead of defining an enumeration with the FW specific values for the
different clock rates, use the actual frequency instead.  Also add a
boolean to specify whether the clock is XTAL or not.

Change all board files to reflect this.

Additionally, this reverts commit 26f45c (ARM: OMAP2+: Legacy support
for wl12xx when booted with devicetree), since this is not be needed
anymore, now that DT support for WiLink is implemented.

Cc: Tony Lindgren <tony at atomide.com>
Cc: Sekhar Nori <nsekhar at ti.com>
Signed-off-by: Luciano Coelho <coelho at ti.com>
Reviewed-by: Felipe Balbi <balbi at ti.com>
---
 arch/arm/mach-davinci/board-da850-evm.c      |  3 +-
 arch/arm/mach-omap2/board-omap3evm.c         |  3 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c |  3 +-
 arch/arm/mach-omap2/devices.c                | 39 -------------------
 drivers/net/wireless/ti/wl12xx/main.c        | 58 +++++++++++++++++++++++++++-
 drivers/net/wireless/ti/wl12xx/wl12xx.h      | 28 ++++++++++++++
 include/linux/wl12xx.h                       | 27 ++-----------
 7 files changed, 93 insertions(+), 68 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 03de2e9..6b2768f 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1376,7 +1376,8 @@ static const short da850_wl12xx_pins[] __initconst = {
 
 static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
 	.irq			= -1,
-	.board_ref_clock	= WL12XX_REFCLOCK_38,
+	.ref_clock_freq		= 38400000,
+	.ref_clock_xtal		= false,
 };
 
 static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 9c7dfc5..4ccfcc0 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -460,7 +460,8 @@ static struct platform_device omap3evm_wlan_regulator = {
 };
 
 struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
-	.board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+	.ref_clock_freq = 38400000,
+	.ref_clock_xtal = false,
 };
 #endif
 
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 4f84cf9..83a9a36 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -244,7 +244,8 @@ static struct platform_device *zoom_devices[] __initdata = {
 };
 
 static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
-	.board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz */
+	.ref_clock_freq = 26000000,
+	.ref_clock_xtal = false,
 };
 
 static struct omap2_hsmmc_info mmc[] = {
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 3c1279f..10e6126 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -8,7 +8,6 @@
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  */
-#include <linux/gpio.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/platform_device.h>
@@ -19,7 +18,6 @@
 #include <linux/of.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/platform_data/omap4-keypad.h>
-#include <linux/wl12xx.h>
 #include <linux/platform_data/mailbox-omap.h>
 
 #include <asm/mach-types.h>
@@ -513,40 +511,6 @@ static void omap_init_vout(void)
 static inline void omap_init_vout(void) {}
 #endif
 
-#if IS_ENABLED(CONFIG_WL12XX)
-
-static struct wl12xx_platform_data wl12xx __initdata;
-
-void __init omap_init_wl12xx_of(void)
-{
-	int ret;
-
-	if (!of_have_populated_dt())
-		return;
-
-	if (of_machine_is_compatible("ti,omap4-sdp")) {
-		wl12xx.board_ref_clock = WL12XX_REFCLOCK_26;
-		wl12xx.board_tcxo_clock = WL12XX_TCXOCLOCK_26;
-		wl12xx.irq = gpio_to_irq(53);
-	} else if (of_machine_is_compatible("ti,omap4-panda")) {
-		wl12xx.board_ref_clock = WL12XX_REFCLOCK_38;
-		wl12xx.irq = gpio_to_irq(53);
-	} else {
-		return;
-	}
-
-	ret = wl12xx_set_platform_data(&wl12xx);
-	if (ret) {
-		pr_err("error setting wl12xx data: %d\n", ret);
-		return;
-	}
-}
-#else
-static inline void omap_init_wl12xx_of(void)
-{
-}
-#endif
-
 /*-------------------------------------------------------------------------*/
 
 static int __init omap2_init_devices(void)
@@ -570,9 +534,6 @@ static int __init omap2_init_devices(void)
 		omap_init_mcspi();
 		omap_init_sham();
 		omap_init_aes();
-	} else {
-		/* These can be removed when bindings are done */
-		omap_init_wl12xx_of();
 	}
 	omap_init_sti();
 	omap_init_rng();
diff --git a/drivers/net/wireless/ti/wl12xx/main.c b/drivers/net/wireless/ti/wl12xx/main.c
index 1c627da..a6c2a14 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1701,6 +1701,43 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
 		},
 };
 
+static const struct wl12xx_clock wl12xx_refclock_table[] = {
+	{ 19200000,	false,	WL12XX_REFCLOCK_19	},
+	{ 26000000,	false,	WL12XX_REFCLOCK_26	},
+	{ 26000000,	true,	WL12XX_REFCLOCK_26_XTAL	},
+	{ 38400000,	false,	WL12XX_REFCLOCK_38	},
+	{ 38400000,	true,	WL12XX_REFCLOCK_38_XTAL	},
+	{ 52000000,	false,	WL12XX_REFCLOCK_52	},
+	{ 0,		false,	0 }
+};
+
+static const struct wl12xx_clock wl12xx_tcxoclock_table[] = {
+	{ 16368000,	true,	WL12XX_TCXOCLOCK_16_368	},
+	{ 16800000,	true,	WL12XX_TCXOCLOCK_16_8	},
+	{ 19200000,	true,	WL12XX_TCXOCLOCK_19_2	},
+	{ 26000000,	true,	WL12XX_TCXOCLOCK_26	},
+	{ 32736000,	true,	WL12XX_TCXOCLOCK_32_736	},
+	{ 33600000,	true,	WL12XX_TCXOCLOCK_33_6	},
+	{ 38400000,	true,	WL12XX_TCXOCLOCK_38_4	},
+	{ 52000000,	true,	WL12XX_TCXOCLOCK_52	},
+	{ 0,		false,	0 }
+};
+
+static int wl12xx_get_clock_idx(const struct wl12xx_clock *table,
+				u32 freq, bool xtal)
+{
+	int i = 0;
+
+	while(table[i].freq != 0) {
+		if ((table[i].freq == freq) &&
+		    (table[i].xtal == xtal))
+			return table[i].hw_idx;
+		i++;
+	};
+
+	return -EINVAL;
+}
+
 static int wl12xx_setup(struct wl1271 *wl)
 {
 	struct wl12xx_priv *priv = wl->priv;
@@ -1722,7 +1759,16 @@ static int wl12xx_setup(struct wl1271 *wl)
 	wl12xx_conf_init(wl);
 
 	if (!fref_param) {
-		priv->ref_clock = pdata->board_ref_clock;
+		priv->ref_clock = wl12xx_get_clock_idx(wl12xx_refclock_table,
+						       pdata->ref_clock_freq,
+						       pdata->ref_clock_xtal);
+		if (priv->ref_clock < 0) {
+			wl1271_error("Invalid ref_clock frequency (%d Hz, %s)",
+				pdata->ref_clock_freq,
+				pdata->ref_clock_xtal ? "XTAL" : "not XTAL");
+
+			return priv->ref_clock;
+		}
 	} else {
 		if (!strcmp(fref_param, "19.2"))
 			priv->ref_clock = WL12XX_REFCLOCK_19;
@@ -1741,7 +1787,15 @@ static int wl12xx_setup(struct wl1271 *wl)
 	}
 
 	if (!tcxo_param) {
-		priv->tcxo_clock = pdata->board_tcxo_clock;
+		priv->tcxo_clock = wl12xx_get_clock_idx(wl12xx_tcxoclock_table,
+							pdata->tcxo_clock_freq,
+							true);
+		if (priv->tcxo_clock < 0) {
+			wl1271_error("Invalid tcxo_clock frequency (%d Hz)",
+				pdata->tcxo_clock_freq);
+
+			return priv->tcxo_clock;
+		}
 	} else {
 		if (!strcmp(tcxo_param, "19.2"))
 			priv->tcxo_clock = WL12XX_TCXOCLOCK_19_2;
diff --git a/drivers/net/wireless/ti/wl12xx/wl12xx.h b/drivers/net/wireless/ti/wl12xx/wl12xx.h
index 9e5484a..05f631b 100644
--- a/drivers/net/wireless/ti/wl12xx/wl12xx.h
+++ b/drivers/net/wireless/ti/wl12xx/wl12xx.h
@@ -79,4 +79,32 @@ struct wl12xx_priv {
 	struct wl127x_rx_mem_pool_addr *rx_mem_addr;
 };
 
+/* Reference clock values */
+enum {
+	WL12XX_REFCLOCK_19	= 0, /* 19.2 MHz */
+	WL12XX_REFCLOCK_26	= 1, /* 26 MHz */
+	WL12XX_REFCLOCK_38	= 2, /* 38.4 MHz */
+	WL12XX_REFCLOCK_52	= 3, /* 52 MHz */
+	WL12XX_REFCLOCK_38_XTAL = 4, /* 38.4 MHz, XTAL */
+	WL12XX_REFCLOCK_26_XTAL = 5, /* 26 MHz, XTAL */
+};
+
+/* TCXO clock values */
+enum {
+	WL12XX_TCXOCLOCK_19_2	= 0, /* 19.2MHz */
+	WL12XX_TCXOCLOCK_26	= 1, /* 26 MHz */
+	WL12XX_TCXOCLOCK_38_4	= 2, /* 38.4MHz */
+	WL12XX_TCXOCLOCK_52	= 3, /* 52 MHz */
+	WL12XX_TCXOCLOCK_16_368	= 4, /* 16.368 MHz */
+	WL12XX_TCXOCLOCK_32_736	= 5, /* 32.736 MHz */
+	WL12XX_TCXOCLOCK_16_8	= 6, /* 16.8 MHz */
+	WL12XX_TCXOCLOCK_33_6	= 7, /* 33.6 MHz */
+};
+
+struct wl12xx_clock {
+	u32	freq;
+	bool	xtal;
+	u8	hw_idx;
+};
+
 #endif /* __WL12XX_PRIV_H__ */
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index ab90b1c..11491ad 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -26,28 +26,6 @@
 
 #include <linux/err.h>
 
-/* Reference clock values */
-enum {
-	WL12XX_REFCLOCK_19	= 0, /* 19.2 MHz */
-	WL12XX_REFCLOCK_26	= 1, /* 26 MHz */
-	WL12XX_REFCLOCK_38	= 2, /* 38.4 MHz */
-	WL12XX_REFCLOCK_52	= 3, /* 52 MHz */
-	WL12XX_REFCLOCK_38_XTAL = 4, /* 38.4 MHz, XTAL */
-	WL12XX_REFCLOCK_26_XTAL = 5, /* 26 MHz, XTAL */
-};
-
-/* TCXO clock values */
-enum {
-	WL12XX_TCXOCLOCK_19_2	= 0, /* 19.2MHz */
-	WL12XX_TCXOCLOCK_26	= 1, /* 26 MHz */
-	WL12XX_TCXOCLOCK_38_4	= 2, /* 38.4MHz */
-	WL12XX_TCXOCLOCK_52	= 3, /* 52 MHz */
-	WL12XX_TCXOCLOCK_16_368	= 4, /* 16.368 MHz */
-	WL12XX_TCXOCLOCK_32_736	= 5, /* 32.736 MHz */
-	WL12XX_TCXOCLOCK_16_8	= 6, /* 16.8 MHz */
-	WL12XX_TCXOCLOCK_33_6	= 7, /* 33.6 MHz */
-};
-
 struct wl1251_platform_data {
 	void (*set_power)(bool enable);
 	/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
@@ -57,8 +35,9 @@ struct wl1251_platform_data {
 
 struct wl12xx_platform_data {
 	int irq;
-	int board_ref_clock;
-	int board_tcxo_clock;
+	int ref_clock_freq;	/* in Hertz */
+	bool ref_clock_xtal;	/* specify whether the clock is XTAL or not */
+	int tcxo_clock_freq;	/* in Hertz, tcxo is always XTAL */
 };
 
 #ifdef CONFIG_WILINK_PLATFORM_DATA
-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 09:04:35 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 16:04:35 +0300
Subject: [PATCH v4 7/8] wlcore: sdio: get clocks from device tree
In-Reply-To: <1375189476-21557-1-git-send-email-coelho@ti.com>
References: <1375189476-21557-1-git-send-email-coelho@ti.com>
Message-ID: <1375189476-21557-8-git-send-email-coelho@ti.com>

Read the clock nodes from the device tree and use them to set the
frequency for the refclock and the tcxo clock.

Also, call sdio_set_drvdata() earlier, so the glue is already set in
the driver data when we call wlcore_get_pdata_from_of() and we don't
need to pass it as a parameter.

Signed-off-by: Luciano Coelho <coelho at ti.com>
Reviewed-by: Felipe Balbi <balbi at ti.com>
---
 drivers/net/wireless/ti/wlcore/sdio.c | 36 +++++++++++++++++++++++++++++++++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 980bf3d..60fce49 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -53,6 +53,7 @@ static bool dump = false;
 struct wl12xx_sdio_glue {
 	struct device *dev;
 	struct platform_device *core;
+	struct clk *refclock, *tcxoclock;
 };
 
 static const struct sdio_device_id wl1271_devices[] = {
@@ -224,6 +225,7 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 	struct wl12xx_platform_data *pdata;
 	struct device_node *np = dev->of_node;
 	struct device_node *clock_node;
+	struct wl12xx_sdio_glue *glue = sdio_get_drvdata(dev_to_sdio_func(dev));
 
 	if (!np) {
 		np = of_find_matching_node(NULL, dev->driver->of_match_table);
@@ -250,6 +252,26 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 	for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
 		of_fixed_clk_setup(clock_node);
 
+	/* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
+	glue->refclock = of_clk_get_by_name(np, "refclock");
+	if (IS_ERR(glue->refclock)) {
+		dev_err(dev, "couldn't find refclock on the device tree\n");
+		glue->refclock = NULL;
+	} else {
+		clk_prepare_enable(glue->refclock);
+		pdata->ref_clock_freq = clk_get_rate(glue->refclock);
+	}
+
+	/* TODO: make sure we have this when needed (ie. for WL7) */
+	glue->tcxoclock = of_clk_get_by_name(np, "tcxoclock");
+	if (IS_ERR(glue->tcxoclock)) {
+		dev_err(dev, "couldn't find tcxoclock on the device tree\n");
+		glue->tcxoclock = NULL;
+	} else {
+		clk_prepare_enable(glue->tcxoclock);
+		pdata->ref_clock_freq = clk_get_rate(glue->tcxoclock);
+	}
+
 	goto out;
 
 out_free:
@@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func,
 	/* Use block mode for transferring over one block size of data */
 	func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
+	sdio_set_drvdata(func, glue);
+
 	/* The pdata allocated here is freed when the device is freed,
 	 * so we don't need an additional out label to free it in case
 	 * of error further on.
@@ -319,8 +343,6 @@ static int wl1271_probe(struct sdio_func *func,
 	if (mmcflags & MMC_PM_KEEP_POWER)
 		pdev_data->pwr_in_suspend = true;
 
-	sdio_set_drvdata(func, glue);
-
 	/* Tell PM core that we don't need the card to be powered now */
 	pm_runtime_put_noidle(&func->dev);
 
@@ -387,6 +409,16 @@ static void wl1271_remove(struct sdio_func *func)
 {
 	struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
 
+	if (glue->refclock) {
+		clk_disable_unprepare(glue->refclock);
+		clk_put(glue->refclock);
+	}
+
+	if (glue->tcxoclock) {
+		clk_disable_unprepare(glue->tcxoclock);
+		clk_put(glue->tcxoclock);
+	}
+
 	/* Undo decrement done above in wl1271_probe */
 	pm_runtime_get_noresume(&func->dev);
 
-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 09:04:36 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 16:04:36 +0300
Subject: [PATCH v4 8/8] wlcore/wl12xx: check if we got correct clock data from
 DT
In-Reply-To: <1375189476-21557-1-git-send-email-coelho@ti.com>
References: <1375189476-21557-1-git-send-email-coelho@ti.com>
Message-ID: <1375189476-21557-9-git-send-email-coelho@ti.com>

The fref and the tcxo clocks settings are optional in some platforms.
WiLink8 doesn't need either, so we don't check the values.  WiLink 6
only needs the fref clock, so we check that it is valid or return with
an error.  WiLink7 needs both clocks, if either is not available we
return with an error.

Signed-off-by: Luciano Coelho <coelho at ti.com>
Reviewed-by: Felipe Balbi <balbi at ti.com>
---
 drivers/net/wireless/ti/wl12xx/main.c | 20 +++++++++++++++++---
 drivers/net/wireless/ti/wlcore/sdio.c |  4 ----
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ti/wl12xx/main.c b/drivers/net/wireless/ti/wl12xx/main.c
index a6c2a14..60d2ff4 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -927,6 +927,11 @@ static int wl128x_boot_clk(struct wl1271 *wl, int *selected_clock)
 	u16 sys_clk_cfg;
 	int ret;
 
+	if ((priv->ref_clock < 0) || (priv->tcxo_clock < 0)) {
+		wl1271_error("Missing fref and/or tcxo clock settings\n");
+		return -EINVAL;
+	}
+
 	/* For XTAL-only modes, FREF will be used after switching from TCXO */
 	if (priv->ref_clock == WL12XX_REFCLOCK_26_XTAL ||
 	    priv->ref_clock == WL12XX_REFCLOCK_38_XTAL) {
@@ -976,6 +981,11 @@ static int wl127x_boot_clk(struct wl1271 *wl)
 	u32 clk;
 	int ret;
 
+	if (priv->ref_clock < 0) {
+		wl1271_error("Missing fref clock settings\n");
+		return -EINVAL;
+	}
+
 	if (WL127X_PG_GET_MAJOR(wl->hw_pg_ver) < 3)
 		wl->quirks |= WLCORE_QUIRK_END_OF_TRANSACTION;
 
@@ -1758,7 +1768,7 @@ static int wl12xx_setup(struct wl1271 *wl)
 	wlcore_set_ht_cap(wl, IEEE80211_BAND_5GHZ, &wl12xx_ht_cap);
 	wl12xx_conf_init(wl);
 
-	if (!fref_param) {
+	if (!fref_param && (pdata->ref_clock_freq > 0)) {
 		priv->ref_clock = wl12xx_get_clock_idx(wl12xx_refclock_table,
 						       pdata->ref_clock_freq,
 						       pdata->ref_clock_xtal);
@@ -1769,6 +1779,8 @@ static int wl12xx_setup(struct wl1271 *wl)
 
 			return priv->ref_clock;
 		}
+	} else if (!fref_param) {
+		priv->ref_clock = -EINVAL;
 	} else {
 		if (!strcmp(fref_param, "19.2"))
 			priv->ref_clock = WL12XX_REFCLOCK_19;
@@ -1786,7 +1798,7 @@ static int wl12xx_setup(struct wl1271 *wl)
 			wl1271_error("Invalid fref parameter %s", fref_param);
 	}
 
-	if (!tcxo_param) {
+	if (!fref_param && (pdata->tcxo_clock_freq > 0)) {
 		priv->tcxo_clock = wl12xx_get_clock_idx(wl12xx_tcxoclock_table,
 							pdata->tcxo_clock_freq,
 							true);
@@ -1796,7 +1808,9 @@ static int wl12xx_setup(struct wl1271 *wl)
 
 			return priv->tcxo_clock;
 		}
-	} else {
+	} else if (!fref_param) {
+		priv->tcxo_clock = -EINVAL;
+	}else {
 		if (!strcmp(tcxo_param, "19.2"))
 			priv->tcxo_clock = WL12XX_TCXOCLOCK_19_2;
 		else if (!strcmp(tcxo_param, "26"))
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 60fce49..c76eb66 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -252,20 +252,16 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
 	for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
 		of_fixed_clk_setup(clock_node);
 
-	/* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
 	glue->refclock = of_clk_get_by_name(np, "refclock");
 	if (IS_ERR(glue->refclock)) {
-		dev_err(dev, "couldn't find refclock on the device tree\n");
 		glue->refclock = NULL;
 	} else {
 		clk_prepare_enable(glue->refclock);
 		pdata->ref_clock_freq = clk_get_rate(glue->refclock);
 	}
 
-	/* TODO: make sure we have this when needed (ie. for WL7) */
 	glue->tcxoclock = of_clk_get_by_name(np, "tcxoclock");
 	if (IS_ERR(glue->tcxoclock)) {
-		dev_err(dev, "couldn't find tcxoclock on the device tree\n");
 		glue->tcxoclock = NULL;
 	} else {
 		clk_prepare_enable(glue->tcxoclock);
-- 
1.8.3.2



From geert at linux-m68k.org  Tue Jul 30 09:08:43 2013
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 30 Jul 2013 15:08:43 +0200
Subject: [PATCH 0/2] Make PPC macro spin_event_timeout() architecture
 independent
In-Reply-To: <1375187900-17582-1-git-send-email-B44344@freescale.com>
References: <1375187900-17582-1-git-send-email-B44344@freescale.com>
Message-ID: <CAMuHMdXP3-uKbftP-2UeZdE6X_iTi1podNDh0aVF3bJwDYssdg@mail.gmail.com>

On Tue, Jul 30, 2013 at 2:38 PM, Arpit Goel <B44344 at freescale.com> wrote:
> This patch-set moves USECS_PER_JIFFY to architecture timex.h from architecture
> specific C files. Patch-set further uses this to make PPC macro
> spin_event_timeout() architecture independent. This change enables drivers to
> use spin_event_timeout() even in non-PowerPC based SoC's.
>
> This patchset has been compiled for ARM, PowerPC and x86.
>
> Patch[1/2] : Moves USECS_PER_JIFFY to architecture specific timex.h files from
>              architecture specific C files.

>  arch/arm/include/asm/timex.h      |  2 ++
>  arch/arm/kernel/time.c            |  3 ---
>  arch/m32r/include/asm/timex.h     |  2 ++
>  arch/m32r/kernel/time.c           |  3 ---
>  arch/m68k/hp300/time.c            |  4 +---
>  arch/m68k/include/asm/timex.h     |  2 ++
>  arch/s390/include/asm/timex.h     |  2 ++
>  arch/s390/kernel/time.c           |  2 --
>  arch/sparc/include/asm/timex_32.h |  2 ++
>  arch/sparc/include/asm/timex_64.h |  2 ++
>  arch/sparc/kernel/pcic.c          |  1 -

As the definition is the same on all architectures, why not move it to
<linux/delay.h>?

> Patch[2/2] : Converts PPC macro spin_event_timeout() in architecture independent
>              macro.

>  include/linux/delay.h             | 40 +++++++++++++++++++++++++++++++++++++++

After your first patch, USECS_PER_JIFFY is still available only on
arm/m32r/m68k/s390/sparc. What about other architectures?
If anyone uses spin_event_timeout() on e.g. x86, it will fail to compile.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From balbi at ti.com  Tue Jul 30 09:10:09 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 30 Jul 2013 16:10:09 +0300
Subject: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for
 DRA7xx based SoCs'
In-Reply-To: <1375183546-12758-2-git-send-email-rnayak@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-2-git-send-email-rnayak@ti.com>
Message-ID: <20130730131009.GA28162@radagast>

Hi,

On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
>  # define soc_is_omap543x()		is_omap543x()
>  #endif
>  
> +# if defined(CONFIG_SOC_DRA7XX)
> +# undef soc_is_dra7xx
> +# undef soc_is_dra75x
> +# define soc_is_dra7xx()		is_dra7xx()
> +# define soc_is_dra75x()		is_dra75x()

since this platform is DT-only, couldn't we just believe DT-data to be
correct of_machine_is_compatible() ? 2/3 of this patch would be removed.

I patched this for OMAP5 (compile-tested only, no boards available) and
came out with the patch below (still needs to be split):

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b3136e5 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -13,7 +13,7 @@
 
 / {
 	model = "TI OMAP5 uEVM board";
-	compatible = "ti,omap5-uevm", "ti,omap5";
+	compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5";
 
 	memory {
 		device_type = "memory";
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 07be2cd..a7bc906 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -17,7 +17,7 @@
 	#address-cells = <1>;
 	#size-cells = <1>;
 
-	compatible = "ti,omap5";
+	compatible = "ti,omap5432-es2.0", "ti,omap5430-es2.0", "ti,omap5";
 	interrupt-parent = <&gic>;
 
 	aliases {
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2dc62a2..ee94309 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -563,49 +563,6 @@ void __init omap4xxx_check_revision(void)
 	pr_info("%s %s\n", soc_name, soc_rev);
 }
 
-void __init omap5xxx_check_revision(void)
-{
-	u32 idcode;
-	u16 hawkeye;
-	u8 rev;
-
-	idcode = read_tap_reg(OMAP_TAP_IDCODE);
-	hawkeye = (idcode >> 12) & 0xffff;
-	rev = (idcode >> 28) & 0xff;
-	switch (hawkeye) {
-	case 0xb942:
-		switch (rev) {
-		case 0:
-			omap_revision = OMAP5430_REV_ES1_0;
-			break;
-		case 1:
-		default:
-			omap_revision = OMAP5430_REV_ES2_0;
-		}
-		break;
-
-	case 0xb998:
-		switch (rev) {
-		case 0:
-			omap_revision = OMAP5432_REV_ES1_0;
-			break;
-		case 1:
-		default:
-			omap_revision = OMAP5432_REV_ES2_0;
-		}
-		break;
-
-	default:
-		/* Unknown default to latest silicon rev as default*/
-		omap_revision = OMAP5430_REV_ES2_0;
-	}
-
-	sprintf(soc_name, "OMAP%04x", omap_rev() >> 16);
-	sprintf(soc_rev, "ES%d.0", (omap_rev() >> 12) & 0xf);
-
-	pr_info("%s %s\n", soc_name, soc_rev);
-}
-
 /*
  * Set up things for map_io and processor detection later on. Gets called
  * pretty much first thing from board init. For multi-omap, this gets
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4a3f06f..aa28940 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -633,8 +633,7 @@ void __init omap4430_init_late(void)
 #ifdef CONFIG_SOC_OMAP5
 void __init omap5_init_early(void)
 {
-	omap2_set_globals_tap(OMAP54XX_CLASS,
-			      OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
+	omap2_set_globals_tap(-1, OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
 	omap2_set_globals_control(OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
 				  OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE));
 	omap2_set_globals_prm(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE));
@@ -644,7 +643,6 @@ void __init omap5_init_early(void)
 	omap_prm_base_init();
 	omap_cm_base_init();
 	omap44xx_prm_init();
-	omap5xxx_check_revision();
 	omap54xx_voltagedomains_init();
 	omap54xx_powerdomains_init();
 	omap54xx_clockdomains_init();
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 8c616e4..b8339ad 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -35,6 +35,7 @@
 #ifndef __ASSEMBLY__
 
 #include <linux/bitops.h>
+#include <linux/of.h>
 
 /*
  * Test if multicore OMAP support is needed
@@ -194,7 +195,6 @@ IS_OMAP_CLASS(24xx, 0x24)
 IS_OMAP_CLASS(34xx, 0x34)
 IS_OMAP_CLASS(44xx, 0x44)
 IS_AM_CLASS(35xx, 0x35)
-IS_OMAP_CLASS(54xx, 0x54)
 IS_AM_CLASS(33xx, 0x33)
 IS_AM_CLASS(43xx, 0x43)
 
@@ -207,7 +207,6 @@ IS_OMAP_SUBCLASS(363x, 0x363)
 IS_OMAP_SUBCLASS(443x, 0x443)
 IS_OMAP_SUBCLASS(446x, 0x446)
 IS_OMAP_SUBCLASS(447x, 0x447)
-IS_OMAP_SUBCLASS(543x, 0x543)
 
 IS_TI_SUBCLASS(816x, 0x816)
 IS_TI_SUBCLASS(814x, 0x814)
@@ -373,10 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430)
 # endif
 
 # if defined(CONFIG_SOC_OMAP5)
-# undef soc_is_omap54xx
-# undef soc_is_omap543x
-# define soc_is_omap54xx()		is_omap54xx()
-# define soc_is_omap543x()		is_omap543x()
+# undef  soc_is_omap54xx
+# undef  soc_is_omap543x
+# define soc_is_omap54xx()		(of_machine_is_compatible("ti,omap5"))
+# define soc_is_omap543x()		(soc_is_omap54xx())
 #endif
 
 /* Various silicon revisions for omap2 */
@@ -437,16 +436,9 @@ IS_OMAP_TYPE(3430, 0x3430)
 #define OMAP447X_CLASS		0x44700044
 #define OMAP4470_REV_ES1_0	(OMAP447X_CLASS | (0x10 << 8))
 
-#define OMAP54XX_CLASS		0x54000054
-#define OMAP5430_REV_ES1_0	(OMAP54XX_CLASS | (0x30 << 16) | (0x10 << 8))
-#define OMAP5430_REV_ES2_0	(OMAP54XX_CLASS | (0x30 << 16) | (0x20 << 8))
-#define OMAP5432_REV_ES1_0	(OMAP54XX_CLASS | (0x32 << 16) | (0x10 << 8))
-#define OMAP5432_REV_ES2_0	(OMAP54XX_CLASS | (0x32 << 16) | (0x20 << 8))
-
 void omap2xxx_check_revision(void);
 void omap3xxx_check_revision(void);
 void omap4xxx_check_revision(void);
-void omap5xxx_check_revision(void);
 void omap3xxx_check_features(void);
 void ti81xx_check_features(void);
 void am33xx_check_features(void);

-- 
balbi
-------------- 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/20130730/dc202606/attachment.sig>

From sajjan.linux at gmail.com  Tue Jul 30 09:13:04 2013
From: sajjan.linux at gmail.com (Vikas Sajjan)
Date: Tue, 30 Jul 2013 18:43:04 +0530
Subject: [PATCH v7 00/11] Add generic set_rate clk_ops for PLL35xx and
 PLL36xx for samsung SoCs
In-Reply-To: <20130723012621.7598.46496@quantum>
References: <1370943076-13461-1-git-send-email-yadi.brar@samsung.com>
 <CAKew6eUOy4=D08v_iq7CTRY5gvt37VAN7Z7WOr2Yt25znDJb2g@mail.gmail.com>
 <CAGm_ybiVZOPBJJ0bYX33wafn1So6aqSAnk7myXZ+Z+RfLBeBQw@mail.gmail.com>
 <1524664.UCV47tfIRU@flatron> <20130621163143.9136.28807@quantum>
 <51C85F8F.9050501@samsung.com> <20130624190227.20448.68120@quantum>
 <007001ce7149$1f683f40$5e38bdc0$%kim@samsung.com>
 <CAKew6eVW6dOzLRN2CG8jT3Oo1uzKrXqi1aRYkAHmUu61dBSDpA@mail.gmail.com>
 <CAGm_ybj31kv=iW2YKsHnBRJ741G2amSNAJf+Mx8Z-JMoVynZ8w@mail.gmail.com>
 <20130723012621.7598.46496@quantum>
Message-ID: <CAGm_ybiiCHVP5GPVe01F==SF+3rCR3a0mFGbxthEVOcbTEGmtA@mail.gmail.com>

Hi Mike,

On Tue, Jul 23, 2013 at 6:56 AM, Mike Turquette <mturquette at linaro.org> wrote:
> Quoting Vikas Sajjan (2013-07-21 23:15:27)
>> Hi Kukjin / Mike,
>>
>> Can you apply this series
>
> Let me apply this to see if the dependencies are taken care of now. If
> so I'll just take it through the clk tree.
>

Any updates on this series.
I could NOT see them at
http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=shortlog;h=refs/heads/clk-next


> Regards,
> Mike
>
>>
>> On Tue, Jul 16, 2013 at 7:10 PM, Yadwinder Singh Brar
>> <yadi.brar01 at gmail.com> wrote:
>> > Hi Kukjin / Mike,
>> >
>> > On Tue, Jun 25, 2013 at 7:40 AM, Kukjin Kim <kgene.kim at samsung.com> wrote:
>> >> Mike Turquette wrote:
>> >>>
>> >>> Quoting Kukjin Kim (2013-06-24 08:02:39)
>> >>> > On 06/22/13 01:31, Mike Turquette wrote:
>> >>> > >
>> >>> > > Acked-by: Mike Turquette<mturquette at linaro.org>
>> >>> > >
>> >>> > > Or I can take this through the clk tree. Either way is fine.
>> >>> > >
>> >>> > Mike, please go ahead taking this series into the clk tree for 3.11.
>> >>>
>> >>> Actually it might be better for you to take it. Patch #5 relies on
>> >>> drivers/clk/samsung/clk-exynos5420.c which only exists in the samsung
>> >>> tree.  It was introduced by commit 1609027f, "clk: exynos5420: register
>> >>> clocks using common clock framework".
>> >>>
>> >> Yes, you're right. It depends on soc-exynos5420 stuff in samsung tree.
>> >>
>> >>> And these patches need to be applied with some fuzz to the clk tree due
>> >>> to other changes which are not in my tree and only present in yours.
>> >>>
>> >>> The best two options are either for you to take this series or it can be
>> >>> rebased on top of clk-next, after which I'll apply it.
>> >>>
>> >> Let me try to send this series via samsung tree for v3.11 but I'm not sure because it's a little bit late for arm-soc tree.
>> >>
>> >> Thanks for your ack, just note I will send to arm-soc tonight in my time.
>> >>
>> >
>> > Can we get this series merge now in any of trees.
>> > Please let me if its required to rebase it.
>> >
>> > Regards,
>> > Yadwinder


From jonsmirl at gmail.com  Tue Jul 30 09:14:42 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Tue, 30 Jul 2013 09:14:42 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <20130730102511.GM9858@sirena.org.uk>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
Message-ID: <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>

On Tue, Jul 30, 2013 at 6:25 AM, Mark Brown <broonie at kernel.org> wrote:
> On Mon, Jul 29, 2013 at 08:30:29PM -0400, jonsmirl at gmail.com wrote:
>
>> This...
>> tx-dma-channel = <&pdma0 7>; /* preliminary */
>> rx-dma-channel = <&pdma0 6>; /* preliminary */
>
>> Probably should be
>> dmas = <&pdma0 7>,<&pdma0 6>;
>> dma-names = "tx", "rx";
>
> It should be - the latter is the generic DMA binding.  There's a lot of
> bindings in the kernel that predate that but people are currently
> working to transfer over, this is one of the examples of instability
> that everyone is talking about.

Is something similar to this possible in device tree syntax?
dmas =  <"tx" &pdma0 7>,  <"rx"  &pdma0 6>;

That's an example of something the quirks system could do. We can make
a quirk for these older definitions and then map them to the new and
improved kernel schema.   And you only need to make quirks for devices
that have been deployed with dtb in boot loaders. There is no need to
accept older dtbs that were appended to the kernel.

The schema system provides the class description for the generic SPI
controller. This generic SPI controller is only generic in the sense
that all of the device syntax is as regular as possible. Each of the
actual SPI controller device drivers is completely different. But now
someone implementing a new SPI controller would have a single DT
example to follow - the schema for the generic SPI controller.

I don't think the quirks system will be that bad to work with. We will
quickly develop a list of device trees that have been deployed in
flash and need to be handled by the quirk system They are already
handled right now by code spread throughout the kernel. Quirks would
just collect everything into an init time segment where it can easily
be discarded.

Also consider that someone like Microsoft might ship SurfaceRT tablets
with a MS specific device tree format. That could be handled by a
quirk. But it would be even better if Microsoft used the generic
schema and followed its format. Right now that schema isn't written
down.

-- 
Jon Smirl
jonsmirl at gmail.com


From jason at lakedaemon.net  Tue Jul 30 09:17:25 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 30 Jul 2013 09:17:25 -0400
Subject: [RFC PATCH 0/2] impedance-matcher generic improvements
In-Reply-To: <51F76FE3.1080302@gmail.com>
References: <51F2A014.7000209@gmail.com>
 <cover.1375131816.git.jason@lakedaemon.net>
 <51F76FE3.1080302@gmail.com>
Message-ID: <20130730131725.GC5882@titan.lakedaemon.net>

On Tue, Jul 30, 2013 at 09:48:51AM +0200, Daniel Mack wrote:
> Hi Jason,
> 
> On 29.07.2013 23:23, Jason Cooper wrote:
> > Basic idea is to replace a device's stock kernel with this impedance-matcher.
> > Load the kernel and/or the devicetree blob to desired addresses.  Add
> > 'loadaddrs=0xXXXXXXXX,0xYYYYYYYY' to the kernel's command line.  Or, if you are
> > appending, 'loadaddrs=appended,0xYYYYYYYY'.  First address is the location of
> > the kernel, second is the location of the dtb.
> 
> Nice to see that idea implemented! For me though, changing any of the
> U-Boot variables is out of the question, and I need the matcher just the
> way I implemented it, including the LED blink pattern to let the user
> know if things go wrong.

Understandable.  After thinking about it a bit, I think I'm going to
rework this patch to allow appending both kernels and dtbs (as you had),
and abstract out the led blink so that your code would become a compile
time option.

> Hence, I won't change to your generic version on my boards, and so I
> think it might be best if you maintain your own tree for your approach.

hrmmm, I don't like forking on general principle.  Let me do the above
rework and see if that works for you, while adding the capabilities I
need.

When I'm done, you should just be able to do:

  $ make APPEND_KERNEL=input/zImage APPEND_DTBS=input/*.dtb uImage

And get the same result.

In the meantime, would you mind adding a license to your code?  If you
have no preference, I like GPLv2-only, but it's your code, so whatever
you like.

thx,

Jason.


From thomas.petazzoni at free-electrons.com  Tue Jul 30 09:18:06 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 30 Jul 2013 15:18:06 +0200
Subject: [PATCH] arm: update advice on kernel and FDT load address.
In-Reply-To: <20130730094118.GF11527@mudshark.cambridge.arm.com>
References: <1375102578-5869-1-git-send-email-ian.campbell@citrix.com>
 <20130729135000.GK32383@mudshark.cambridge.arm.com>
 <1375106635.12741.8.camel@kazak.uk.xensource.com>
 <alpine.LFD.2.03.1307292234040.15022@syhkavp.arg>
 <20130730094118.GF11527@mudshark.cambridge.arm.com>
Message-ID: <20130730151806.33ee3081@skate>

Dear Will Deacon,

On Tue, 30 Jul 2013 10:41:18 +0100, Will Deacon wrote:

> > The initial page table is therefore (in most cases again) just below the 
> > decompressed kernel location i.e. either Ffrom 16KB from start of RAM, 
> > or from 12KB if using LPAE.
> > 
> > You can therefore load everything (zImage, initrd, DTB) sequentially 
> > from the 32MB mark in RAM and be safe.  By loading zImage that high, it 
> > most certainly won't need to relocate itself (unless the decompressed 
> > kernel is larger than 32MB which is very unlikely as I mentioned) and 
> > that will also make the boot process slightly faster.
> 
> Hmm, how does that work with CONFIG_INITRAMFS_SOURCE, where the initramfs
> is built into the zImage? Would this impose a 32MB uncompressed limit on the
> size of the kernel + initramfs?

I've recently had troubles with a kernel + bundled initramfs, when the
compressed size of both exceeds something like 6 MB or so. I haven't
done any serious testing as compressing with XZ worked around the
problem, but I think there's some limit somewhere, but I guess 6 MB
compressed isn't going to expand to 32 MB uncompressed so I'm not sure
it's the limit you're referring to that I'm seeing.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From maxime.ripard at free-electrons.com  Tue Jul 30 09:18:28 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 15:18:28 +0200
Subject: [PATCH 05/10] ARM: sunxi: Add Allwinner A31 DTSI
In-Reply-To: <51F78056.6000104@arm.com>
References: <1374618312-19001-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374618312-19001-6-git-send-email-maxime.ripard@free-electrons.com>
 <51F78056.6000104@arm.com>
Message-ID: <20130730131828.GB12562@lukather>

Hi Marc,

On Tue, Jul 30, 2013 at 09:59:02AM +0100, Marc Zyngier wrote:
> Hi Maxime,
> 
> On 23/07/13 23:25, Maxime Ripard wrote:
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > ---
> >  arch/arm/boot/dts/Makefile       |   3 +-
> >  arch/arm/boot/dts/sun6i-a31.dtsi | 155 +++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 157 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/boot/dts/sun6i-a31.dtsi
> > 
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 641b3c9..1482533 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -210,7 +210,8 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
> >  	sun4i-a10-mini-xplus.dtb \
> >  	sun4i-a10-hackberry.dtb \
> >  	sun5i-a10s-olinuxino-micro.dtb \
> > -	sun5i-a13-olinuxino.dtb
> > +	sun5i-a13-olinuxino.dtb \
> > +	sun6i-a31-colombus.dtb
> >  dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
> >  	tegra20-iris-512.dtb \
> >  	tegra20-medcom-wide.dtb \
> > diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
> > new file mode 100644
> > index 0000000..c6c19a9
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> > @@ -0,0 +1,155 @@
> > +/*
> > + * Copyright 2013 Maxime Ripard
> > + *
> > + * Maxime Ripard <maxime.ripard at free-electrons.com>
> > + *
> > + * The code contained herein is licensed under the GNU General Public
> > + * License. You may obtain a copy of the GNU General Public License
> > + * Version 2 or later at the following locations:
> > + *
> > + * http://www.opensource.org/licenses/gpl-license.html
> > + * http://www.gnu.org/copyleft/gpl.html
> > + */
> > +
> > +/include/ "skeleton.dtsi"
> > +
> 
> [...]
> 
> > +		gic: interrupt-controller at 01c81000 {
> > +			compatible = "arm,cortex-a7-gic";
> > +			reg = <0x01c81000 0x1000>, <0x01c82000 0x100>;
> 
> Th Cortex A7 TRM indicates that its GIC has the virtualization
> extensions. You should reflect this in the binding (wider GICC range,
> GICH and GICV ranges, maintenance interrupt).
> 
> See
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0464d/BGBJFJJA.html
> for details.

Thanks!

I'll add those to the v2.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130730/9870f9ef/attachment.sig>

From balbi at ti.com  Tue Jul 30 09:18:37 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 30 Jul 2013 16:18:37 +0300
Subject: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for
 DRA7xx based SoCs'
In-Reply-To: <20130730131009.GA28162@radagast>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-2-git-send-email-rnayak@ti.com>
 <20130730131009.GA28162@radagast>
Message-ID: <20130730131837.GB28162@radagast>

On Tue, Jul 30, 2013 at 04:10:09PM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
> > @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
> >  # define soc_is_omap543x()		is_omap543x()
> >  #endif
> >  
> > +# if defined(CONFIG_SOC_DRA7XX)
> > +# undef soc_is_dra7xx
> > +# undef soc_is_dra75x
> > +# define soc_is_dra7xx()		is_dra7xx()
> > +# define soc_is_dra75x()		is_dra75x()
> 
> since this platform is DT-only, couldn't we just believe DT-data to be
> correct of_machine_is_compatible() ? 2/3 of this patch would be removed.

s/correct of_/correct and use of_

-- 
balbi
-------------- 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/20130730/0afe06d3/attachment.sig>

From oliver at schinagl.nl  Tue Jul 30 09:22:55 2013
From: oliver at schinagl.nl (Oliver Schinagl)
Date: Tue, 30 Jul 2013 15:22:55 +0200
Subject: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner's
 Security ID fuses
In-Reply-To: <20130719234944.GA11498@kroah.com>
References: <20130624214615.GA17604@kroah.com> <51CAA709.4060801@schinagl.nl>
 <20130626175144.GC2222@kroah.com> <51D674BF.9030207@schinagl.nl>
 <20130706193646.GB9778@kroah.com> <51E466A3.4010503@schinagl.nl>
 <20130716064107.GA10868@kroah.com> <20130717114650.GN3125@lukather>
 <20130717161758.GA9822@kroah.com> <20130719094211.GD5106@lukather>
 <20130719234944.GA11498@kroah.com>
Message-ID: <51F7BE2F.3060004@schinagl.nl>

Hey Greg!

On 20-07-13 01:49, Greg KH wrote:
> On Fri, Jul 19, 2013 at 11:42:11AM +0200, Maxime Ripard wrote:
>> On Wed, Jul 17, 2013 at 09:17:58AM -0700, Greg KH wrote:
>>> On Wed, Jul 17, 2013 at 01:46:50PM +0200, Maxime Ripard wrote:
>>>> On Mon, Jul 15, 2013 at 11:41:07PM -0700, Greg KH wrote:
>>>>> On Mon, Jul 15, 2013 at 11:16:19PM +0200, Oliver Schinagl wrote:
>>>>>> So using these new patches for binary attributes, how can I pass data
>>>>>> between my driver and the sysfs files using a platform_driver? Or are
>>>>>> other 'hacks' needed and using the .groups attribute from
>>>>>> platform_driver->device_driver->groups is really the wrong approach.
>>>>>>
>>>>>> I did ask around and still haven't figured it out so far, so I do
>>>>>> apologize if you feel I'm wasting your precious time.
>>>>> How is the platform device not the same thing that was passed to your
>>>>> probe function?
>>>> One thing I don't get here is why it should be set in the
>>>> platform_driver structure. From my understanding of the device model,
>>>> and since what Oliver is trying to do is exposing a few bytes of memory
>>>> to sysfs, shouldn't the sysfs file be attached to the device instead?
>>> It will be created by the driver core for any device attached to the
>>> driver automatically.
>>>
>>>> I mean, here, the sysfs file will be created under something like
>>>> .../drivers/sunxi-sid/eeprom. What happens when you have several
>>>> instances of that driver loaded? I'd expect it to have several sysfs
>>>> files created, one for each instance. So to me, it should be in the
>>>> device structure, not the driver one.
>>> You can't have multiple drivers with the same name loaded (or the same
>>> module loaded multiple times.)  You can have multiple devices for a
>>> single driver, which is what we do all the time.
>> Yes, I know that, and it's actually my point.
>> With the current oliver's code he pasted earlier in this thread:
>>
>> # find /sys/ -name eeprom
>> /sys/bus/platform/drivers/sunxi-sid/eeprom
>>
>> While I'd expect the eeprom file to be located in
>> /sys/bus/platform/devices/X.eeprom/eeprom like it used to be in the v4,
>> since it's an instance-specific content.
> Oh crap.  You are totally right.  That's why we added the new device
> create call, to allow this to work properly.
>
> Right now you are getting the kobject of the driver, not the device, in
> the callback, which is not what you want (sure, if you only have once
> instance, you can work around it, but don't it's the driver core's fault
> for not giving you the correct api...)
>
> Let me go look at how I can make this work "easier", give me a few days.
Not wanting to be rude, but it has been a little more then a few days, 
any progress? Just want to know what I have to modify my driver to so it 
can go into the next merge window :)

oliver
>
> greg k-h



From tony at atomide.com  Tue Jul 30 09:30:52 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 30 Jul 2013 06:30:52 -0700
Subject: [GIT PULL] urgent omap5 regulator updates against v3.11-rc3
Message-ID: <20130730133052.GK7656@atomide.com>

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/fixes-omap5

for you to fetch changes up to bd3c5544a1e98a25d2d24c98779092e0f84373f7:

  ARM: dts: omap5-uevm: update optional/unused regulator configurations (2013-07-29 23:43:20 -0700)

----------------------------------------------------------------
Fixes for omap5-uevm regulators from Nishanth Menon <nm at ti.com>:

Due to wrong older revision of documentation used as reference, we
seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
series is based power tree on production board 750-2628-XXX platform.
Unfortunately, the wrong voltages may be detrimental to OMAP5 as they
supply hardware blocks at voltages that are out of specification.

There is a chance that without these fixes there can be hardware
damage to omap5-uevm boards with the v3.11-rc series.

----------------------------------------------------------------
Nishanth Menon (3):
      ARM: dts: omap5-uevm: document regulator signals used on the actual board
      ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC
      ARM: dts: omap5-uevm: update optional/unused regulator configurations

 arch/arm/boot/dts/omap5-uevm.dts | 78 +++++++++++++++++++++++++---------------
 1 file changed, 49 insertions(+), 29 deletions(-)


From tgih.jun at samsung.com  Tue Jul 30 09:33:30 2013
From: tgih.jun at samsung.com (Seungwon Jeon)
Date: Tue, 30 Jul 2013 22:33:30 +0900
Subject: [PATCH 4/5] mmc: dw_mmc: Indicate that regulators may be absent
In-Reply-To: <1375184777-25404-4-git-send-email-broonie@kernel.org>
References: <1375184777-25404-1-git-send-email-broonie@kernel.org>
 <1375184777-25404-4-git-send-email-broonie@kernel.org>
Message-ID: <003901ce8d29$610ab3f0$23201bd0$%jun@samsung.com>

On Tue, July 30, 2013, Mark Brown wrote:
> From: Mark Brown <broonie at linaro.org>
> 
> Use regulator_get_optional() to tell the core that requests for regulators
> can fail in a real system.
> 
> Signed-off-by: Mark Brown <broonie at linaro.org>
Acked-by: Seungwon Jeon <tgih.jun at samsung.com>

Thanks,
Seungwon Jeon



From tony at atomide.com  Tue Jul 30 09:33:36 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 30 Jul 2013 06:33:36 -0700
Subject: [GIT PULL] ARM: OMAP2+: hwmod fixes for v3.11-rc
In-Reply-To: <alpine.DEB.2.02.1307301146110.4505@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307301146110.4505@utopia.booyaka.com>
Message-ID: <20130730133336.GL7656@atomide.com>

Arnd & Olof,

Can you please take this pull request directly? Other than the
omap5 regulator dts changes I just posted I don't yet have
anything else queued up right now.

Regards,

Tony

* Paul Walmsley <paul at pwsan.com> [130730 04:53]:
> 
> Hi Tony
> 
> The following changes since commit 5ae90d8e467e625e447000cb4335c4db973b1095:
> 
>   Linux 3.11-rc3 (2013-07-28 20:53:33 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.11-rc/omap-fixes-b
> 
> for you to fetch changes up to 50c2a3a1518befe992f868fc1fd867bdad9776ad:
> 
>   ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space (2013-07-30 05:13:37 -0600)
> 
> ----------------------------------------------------------------
> Some OMAP hwmod fixes for v3.11-rc.  Mostly intended to fix an earlyprintk
> regression and an AM33xx cpgmac power management regression.
> 
> Basic build, boot, and PM tests are available here:
> 
> http://www.pwsan.com/omap/testlogs/hwmod_fixes_a_v3.11-rc/20130730042132/
> 
> The tests include temporary fixes for the unrelated 2430SDP and OMAP3
> boot regressions, which are not part of this signed tag.
> 
> ----------------------------------------------------------------
> Afzal Mohammed (2):
>       ARM: OMAP2+: hwmod: rt address space index for DT
>       ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space
> 
> Rajendra Nayak (3):
>       ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL
>       ARM: OMAP2+: Avoid idling memory controllers with no drivers
>       ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device state
> 
>  arch/arm/mach-omap2/omap_device.c                  | 18 ++++++++
>  arch/arm/mach-omap2/omap_hwmod.c                   |  2 +-
>  arch/arm/mach-omap2/omap_hwmod.h                   | 50 ++++++++++++++++++++++
>  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |  6 +--
>  arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |  3 +-
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |  9 ++--
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |  5 +--
>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |  3 +-
>  arch/arm/mach-omap2/serial.c                       | 11 -----
>  9 files changed, 83 insertions(+), 24 deletions(-)


From zonque at gmail.com  Tue Jul 30 09:37:38 2013
From: zonque at gmail.com (Daniel Mack)
Date: Tue, 30 Jul 2013 15:37:38 +0200
Subject: [RFC PATCH 0/2] impedance-matcher generic improvements
In-Reply-To: <20130730131725.GC5882@titan.lakedaemon.net>
References: <51F2A014.7000209@gmail.com>
 <cover.1375131816.git.jason@lakedaemon.net> <51F76FE3.1080302@gmail.com>
 <20130730131725.GC5882@titan.lakedaemon.net>
Message-ID: <51F7C1A2.5010208@gmail.com>

Hi Jason,

On 30.07.2013 15:17, Jason Cooper wrote:
> On Tue, Jul 30, 2013 at 09:48:51AM +0200, Daniel Mack wrote:
>> On 29.07.2013 23:23, Jason Cooper wrote:
>>> Basic idea is to replace a device's stock kernel with this impedance-matcher.
>>> Load the kernel and/or the devicetree blob to desired addresses.  Add
>>> 'loadaddrs=0xXXXXXXXX,0xYYYYYYYY' to the kernel's command line.  Or, if you are
>>> appending, 'loadaddrs=appended,0xYYYYYYYY'.  First address is the location of
>>> the kernel, second is the location of the dtb.
>>
>> Nice to see that idea implemented! For me though, changing any of the
>> U-Boot variables is out of the question, and I need the matcher just the
>> way I implemented it, including the LED blink pattern to let the user
>> know if things go wrong.
> 
> Understandable.  After thinking about it a bit, I think I'm going to
> rework this patch to allow appending both kernels and dtbs (as you had),
> and abstract out the led blink so that your code would become a compile
> time option.

And how would you match machids and system_rev values to the dtb files?
This is how I identify my boards at least. But as Stephen Warren said in
the thread that started this discussion, there might be totally
different ways of detection. For instance, other boards could read GPIO
lines, or even have a pseudo driver that initializes the I2C controller
in order to talk to an EEPROM or such. Reading from an ADC is another
option.

And the more I think about it, I believe Nicolas was right in saying
that such a thing does not need to be very generic (as much as I like
generic solutions in principle).

If at all, I think we should start thinking of that code base as
something like a framework, consisting of a merely empty main() function
body, a lds linker script and some objcopy magic in the Makefile. And
then have a menuconfig which allows to select one out of many hardware
types, which then uses its specific way of board detection, LED
signaling and so on. The two lines of vectoring to the actual kernel can
be generic then. But again, I really don't know if it's worth the hassle.

> hrmmm, I don't like forking on general principle.  Let me do the above
> rework and see if that works for you, while adding the capabilities I
> need.
> 
> When I'm done, you should just be able to do:
> 
>   $ make APPEND_KERNEL=input/zImage APPEND_DTBS=input/*.dtb uImage

Out of curiosity, I'd like to see how you dynamically create the symbol
definitions for the binary blobs :)

> In the meantime, would you mind adding a license to your code?  If you
> have no preference, I like GPLv2-only, but it's your code, so whatever
> you like.

Done, GPLv2 it is.


Thanks,
Daniel



From will.deacon at arm.com  Tue Jul 30 09:36:01 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 30 Jul 2013 14:36:01 +0100
Subject: [PATCH v3 1/3] ARM: BCM5301X: initial support for the
 BCM5301X/BCM470X SoCs with ARM CPU
In-Reply-To: <201307272149.17108.arnd@arndb.de>
References: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
 <51F28A20.7060105@hauke-m.de>
 <20130726165311.GH17886@mudshark.cambridge.arm.com>
 <201307272149.17108.arnd@arndb.de>
Message-ID: <20130730133601.GN11527@mudshark.cambridge.arm.com>

On Sat, Jul 27, 2013 at 08:49:16PM +0100, Arnd Bergmann wrote:
> On Friday 26 July 2013, Will Deacon wrote:
> > > > At least, we need a pretty good explanation of what exactly is causing
> > > > these spurious aborts before we start ignoring them unconditionally like
> > > > this. You're effectively masking an extremely serious error indicator with
> > > > this change.
> > > 
> > > This fault occurs once every boot sometime early in the boot process,
> > > but the actual time this happens varies randomly.
> > 
> > Well that's interesting in itself. It sounds like we don't know *for sure*
> > whether the abort is triggered by Linux. Since the abort is imprecise, the
> > timing will vary.
> 
> It might be possible to find out the culprit if you just enter an endless loop
> in the early kernel boot code. If you enter the loop before Linux does something
> wrong, it won't crash, otherwise it will. After that, you could bisect the
> boot process by moving the busy loop around.
> 
> If it even crashes at the point where Linux gets entered, it's a bug in the
> boot loader.

Can you give Arnd's suggestion a go please Hauke?

Thanks,

Will


From mark.rutland at arm.com  Tue Jul 30 09:44:27 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 30 Jul 2013 14:44:27 +0100
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <20130730125650.GD28716@e106331-lin.cambridge.arm.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
 <51F7B4C9.2060500@gmail.com>
 <20130730125650.GD28716@e106331-lin.cambridge.arm.com>
Message-ID: <20130730134427.GE28716@e106331-lin.cambridge.arm.com>

On Tue, Jul 30, 2013 at 01:56:50PM +0100, Mark Rutland wrote:
> On Tue, Jul 30, 2013 at 01:42:49PM +0100, Rob Herring wrote:
> > On 07/30/2013 04:49 AM, Mark Rutland wrote:
> > > On Mon, Jul 29, 2013 at 09:18:43PM +0100, Rob Herring wrote:
> > >> On 07/29/2013 05:13 AM, Mark Rutland wrote:
> > >>> Hi Rob,
> > >>>
> > >>> On Sun, Jul 28, 2013 at 10:56:32PM +0100, Rob Herring wrote:
> > >>>> From: Rob Herring <rob.herring at calxeda.com>
> > 
> > [snip]
> > 
> > >>> One of the things changed in PSCI 0.2 was the SMC calling convention,
> > >>> though this isn't clear in the PSCI document. The function IDs for 32bit
> > >>> and 64bit callers may differ, and we need to support describing an
> > >>> arbitrary configuration of the two (same ID for both, different across
> > >>> 32-bit/64-bit, only supported for 64-bit, only supported for 32-bit).
> > >>>
> > >>> I'd like to ensure the binding can deal with that from the start. We
> > >>> could do this by having -32 and -64 variants of each function id (e.g.
> > >>> cpu_off-64) , if the IDs actually differ, and use the regular combined
> > >>> ID if they don't.
> > >>
> > >> Uggg. I guess I should have read the SMC calling convention doc... I was
> > >> simply documenting what is already in the PSCI doc, but obviously that
> > >> is not fully flushed out.
> > >>
> > >> How about something like this (for the complicated case of both 32 and
> > >> 64 bit):
> > >>
> > >> 	method		= "smc", "smc64";
> > >> 	psci_version	= <0x84000000 0xc4000000>;
> > >> 	cpu_suspend	= <0x84000001 0xc4000001>;
> > >> 	cpu_off		= <0x84000002 0xc4000002>;
> > >> 	cpu_on		= <0x84000003 0xc4000003>;
> > >>
> > >> "smc" is a synonym for smc32 for compatibility. The number and order of
> > >> methods determines the number and order of function IDs.
> > > 
> > > While this may be compatible with the arm implementation, it won't be
> > > compatible with the arm64 implementation, which assumes smc64 by
> > > default.
> > > 
> > > As far as I am aware, the implementations currently in use (KVM and Xen)
> > > use the same ID for both, so I think "smc" should cover an ID valid for
> > > a native register width calling convention, and "smc64" and "smc32"
> > > describing values only valid for 64-bit wide and 32-bit wide calling
> > > conventions respectively.
> > 
> > The problem is that does not work for a 32-bit kernel on 64-bit h/w as
> > native from the dts perspective is smc64. Just like the cpu bindings,
> > the binding cannot change based on 32 or 64 bit OS. I don't think we
> > really have to deal with that here. We can simply say "smc" is only for
> > "arm,psci" and deprecated for "arm,psci-0.2".
> 
> Agreed. I'd be happy with only having "smc32" and "smc64" for
> "arm,psci-0.2".

Actually, from some quick discussion with Marc and Dave, I think we can
handle this better, in a way that leaves this backwards compatible.

Rather than relying on the method string to tell us the calling
convention, I think we should rely on the function ID, as I proposed
earlier. The existing function ids provided in the "arm,psci" binding
are implicitly relying on the PSCI implementation to detect the register
width and act accordingly. This is trivially true on 32bit hardware, KVM
(where the same ID is used for 32-bit and 64-bit guests), and while I'm
not entirely sure about Xen I believe it's true there. We can make this
explicit as we extend the binding.

Having a -64 and -32 variant of each ID (while not pretty) allows us to
add additional IDs for functions that might only have a 32-bit or 64-bit
interface implemented, in addition to functions with common IDs:

psci {
	compatible = "$VENDOR,psci-0.2", "arm,psci-0.2", "arm,psci";
	cpu_off = <12345678>;
	cpu_on = <01234567>;
	system_reset-32 = <02222222>;
	system_reset-64 = <12222222>;
	affinity_info-64 = <15555555>;
};

This means that hypervisors could update their PSCI implementation while
keeping their DTS compatible with existing kernels.

Thanks,
Mark.


From tony at atomide.com  Tue Jul 30 09:55:27 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 30 Jul 2013 06:55:27 -0700
Subject: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for
 DRA7xx based SoCs'
In-Reply-To: <20130730131837.GB28162@radagast>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-2-git-send-email-rnayak@ti.com>
 <20130730131009.GA28162@radagast> <20130730131837.GB28162@radagast>
Message-ID: <20130730135527.GM7656@atomide.com>

* Felipe Balbi <balbi at ti.com> [130730 06:25]:
> On Tue, Jul 30, 2013 at 04:10:09PM +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
> > > @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
> > >  # define soc_is_omap543x()		is_omap543x()
> > >  #endif
> > >  
> > > +# if defined(CONFIG_SOC_DRA7XX)
> > > +# undef soc_is_dra7xx
> > > +# undef soc_is_dra75x
> > > +# define soc_is_dra7xx()		is_dra7xx()
> > > +# define soc_is_dra75x()		is_dra75x()
> > 
> > since this platform is DT-only, couldn't we just believe DT-data to be
> > correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
> 
> s/correct of_/correct and use of_

Makes sense to me. AFAIK we no longer need to initialize much
anything super early.

Regards,

Tony


From Ian.Campbell at citrix.com  Tue Jul 30 09:56:10 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Tue, 30 Jul 2013 14:56:10 +0100
Subject: [PATCH] arm: update advice on kernel and FDT load address.
In-Reply-To: <alpine.LFD.2.03.1307292234040.15022@syhkavp.arg>
References: <1375102578-5869-1-git-send-email-ian.campbell@citrix.com>
 <20130729135000.GK32383@mudshark.cambridge.arm.com>
 <1375106635.12741.8.camel@kazak.uk.xensource.com>
 <alpine.LFD.2.03.1307292234040.15022@syhkavp.arg>
Message-ID: <1375192570.32691.27.camel@kazak.uk.xensource.com>

On Mon, 2013-07-29 at 23:05 -0400, Nicolas Pitre wrote:
> On Mon, 29 Jul 2013, Ian Campbell wrote:
> 
> > On Mon, 2013-07-29 at 14:50 +0100, Will Deacon wrote:
> > > Hi Ian,
> > > 
> > > /me plays English teacher :)
> > > 
> > > On Mon, Jul 29, 2013 at 01:56:18PM +0100, Ian Campbell wrote:
> > > > Based on the discussion in [0]:
> > > >   - Recommend that the kernel be placed under 128MiB ("for automatic RAM
> > > >     location to work", says Nico)
> > > >   - Recommend that DTB larger than ~16KiB be placed after the 128MiB boundary
> > > >     (in order to avoid conflicting with the kernel decompressor, kernel is at
> > > >     most 32MiB) and within the lowmem region. Somewhat arbitrarily recommend
> > > >     placement below the 256MiB boundary, the real lowmem limit is likely up
> > > >     around 600-800MiB but varies.
> > > > 
> > > > [0] http://article.gmane.org/gmane.linux.ports.arm.kernel/254538
> > > > 
> > > > Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
> > > > Cc: Russell King <linux at arm.linux.org.uk>
> > > > Cc: Nicolas Pitre <nicolas.pitre at linaro.org>
> > > > Cc: Will Deacon <will.deacon at arm.com>
> > > > Cc: Dave Martin <dave.martin at linaro.org>
> > > > Cc: Grant Likely <grant.likely at secretlab.ca>
> > > > Cc: linux-arm-kernel at lists.infradead.org
> > > > ---
> > > >  Documentation/arm/Booting |   14 +++++++++++---
> > > >  1 files changed, 11 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting
> > > > index 0c1f475..72c035e 100644
> > > > --- a/Documentation/arm/Booting
> > > > +++ b/Documentation/arm/Booting
> > > > @@ -125,6 +125,13 @@ with the caveat that it may not be located at physical address 0 since
> > > >  the kernel interprets a value of 0 in r2 to mean neither a tagged list
> > > >  nor a dtb were passed.
> > > >  
> > > > +If the DTB is larger than ~16KiB, such that placement in the first
> > > > +16KiB would lead to a conflict with the kernel loaded at 32KiB (as
> > > > +recommended below) which uses the memory between 16KiB-32KiB itself,
> > > > +then the DTB should be placed after the first 128MiB of RAM in order
> > > > +to avoid conflicting with the kernel decompressor. The recommnded
> > > 
> > > recommended
> > 
> > Should've pressed F5, sorry...
> > 
> > > It also looks like you're repeating part of what is said later regarding the
> > > 16k of page tables below the image.
> > 
> > yes, this was tricky since I wanted to justify the larger than 16KiB but
> > that was a forward reference. I went with "as recommended below".
> > Perhaps I should just omit the justification? Or perhaps "If the DTB is
> > larger than ~16KiB (see below for why this particular value
> > matters)...". Clunky :-(
> 
> Why not simply:
> 
> 	Make sure the loaded DTB doesn't conflict with the zImage 
> 	decompressor which may relocate itself.  A safe location is 
> 	just above the 128MB boundary from start of RAM.

Sounds good.

> 
> > > Also, we use 20k with LPAE.
> > 
> > I'll fold in an update along those lines too.
> > 
> > However given that this then makes everything more complicated (e.g.
> > it's now DTB > ~12KiB in that case) perhaps we should just ditch the
> > original recommendation to use the first 16KiB and switch to a
> > recommendation of "as high as possible below 256MiB" across the board?
> > That would remove the issue with repeating stuff from the next section
> > too.
> 
> Sure.

I'll make this change.

> > > > +placement in this case just below the 256MiB boundary.
> > > > +
> > > >  5. Calling the kernel image
> > > >  ---------------------------
> > > >  
> > > > @@ -136,9 +143,10 @@ is stored in flash, and is linked correctly to be run from flash,
> > > >  then it is legal for the boot loader to call the zImage in flash
> > > >  directly.
> > > >  
> > > > -The zImage may also be placed in system RAM (at any location) and
> > > > -called there.  Note that the kernel uses 16K of RAM below the image
> > > > -to store page tables.  The recommended placement is 32KiB into RAM.
> > > > +The zImage may also be placed in system RAM and called there.  The
> > > > +kernel should be placed in the first 128MiB of RAM. Note that the
> > > > +kernel uses 16KiB of RAM below the image to store page tables.  The
> > > > +recommended placement is 32KiB into RAM.
> > > 
> > > This is a bit clunky since you say that the zImage may be placed in system
> > > RAM, then restrict that in the next sentence.
> > 
> > How about:
> > 
> >         The kernel may also be placed in the first 128MiB of system RAM
> >         and called there.
> 
> Not "may" but "must" if you have CONFIG_AUTO_ZRELADDR=y.

The "may" here is an alternative to the option of being in flash. Is
that incompatible with AUTO_ZRELADDR?

>From the ZRELADDR Kconfig the answer seems to be yes.

> 
> >	Note that the kernel uses 16KiB of RAM below
> >       the image to store page tables.  The recommended placement is
> >         32KiB into RAM.
> 
> Well... not completely right.

To be fair this was part of the existing text ;)

> You may load zImage anywhere in the first 128MB of RAM if you have 
> CONFIG_AUTO_ZRELADDR=y.  If CONFIG_AUTO_ZRELADDR=n then zImage may be 
> loaded anywhere. In the former case, the zImage code will automatically 
> determine the physical start of RAM.  In the later case the start of RAM 
> is hardcoded in the zImage binary.
> 
> Then, the zImage code will decompress the actual kernel image at an 
> offset of (in most cases) 32KB from start of RAM.  However, if the 
> decompressed kernel would overwrite the loaded zImage where the 
> decompressor code and data is located, then zImage will relocate itself 
> just after the end of the decompressed kernel area before proceeding to 
> the decompression.  This is where you need to be careful about 
> ramdisk/initrd and DTB load addresses.
> 
> The initial page table is therefore (in most cases again) just below the 
> decompressed kernel location i.e. either Ffrom 16KB from start of RAM, 
> or from 12KB if using LPAE.
> 
> You can therefore load everything (zImage, initrd, DTB) sequentially 
> from the 32MB mark in RAM and be safe.  By loading zImage that high, it 
> most certainly won't need to relocate itself (unless the decompressed 
> kernel is larger than 32MB which is very unlikely as I mentioned) and 
> that will also make the boot process slightly faster.

OK. So it sounds like you want to change the existing recommendation of
loading at 32KiB into RAM to instead recommend loading the kernel at
32MiB into RAM, at least for zImage/compressed kernels. Do we care about
any other sort, e.g. bare or uncompressed images?

I think we do still care about people jumping direct to
arch/arm/kernel/head.S rather than arch/arm/boot/compressed/head.S,
don't we? It seems like the recommendation should remain 32KiB for
"bare" kernels.

Actually I've just noticed that the existing text in
Documentation/arm/Booting only talks about zImage and 32KiB, so perhaps
not worrying about non-zImage is acceptable?

Ian.



From balbi at ti.com  Tue Jul 30 10:04:41 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 30 Jul 2013 17:04:41 +0300
Subject: Division by zero caused by CCF
In-Reply-To: <CAPtuhTiUsLffRaC+8Gd8me2OYeMUOuFM4CqW3vnXmkkp53P_yg@mail.gmail.com>
References: <20130716123709.GA15036@arwen.pp.htv.fi> <51E5465F.3090801@ti.com>
 <CAPtuhTiUsLffRaC+8Gd8me2OYeMUOuFM4CqW3vnXmkkp53P_yg@mail.gmail.com>
Message-ID: <20130730140441.GK28162@radagast>

Hi,

this is still broken on v3.11-rc3 and Luca got his Blaze (OMAP4) to fail
the same way

On Tue, Jul 16, 2013 at 10:45:38AM -0700, Mike Turquette wrote:
> On Tue, Jul 16, 2013 at 6:10 AM, Eduardo Valentin
> <eduardo.valentin at ti.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> >
> > Hi,
> >
> > Adding Mike's correct address.
> >
> > On 16-07-2013 08:37, Felipe Balbi wrote:
> >> Hi,
> >>
> >> trying to get USB host verified on OMAP5 uEVM with v3.11-rc1. The
> >> clk_set_rate() call ends up in a division by zero, which is quite
> >> interesting provided the driver will only call clk_set_rate() if the
> >> clock is valid and clk_rate is != 0.
> >>
> >>
> >> [   22.009238] Division by zero in kernel.
> >> [   22.009250] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W    3.11.0-rc1-00081-g3310d44-dirty #118
> >> [   22.009275] [<c001c83c>] (unwind_backtrace+0x0/0xf0) from [<c0018a1c>] (show_stack+0x10/0x14)
> >> [   22.009289] [<c0018a1c>] (show_stack+0x10/0x14) from [<c057403c>] (dump_stack+0x70/0x8c)
> >> [   22.009304] [<c057403c>] (dump_stack+0x70/0x8c) from [<c02e4154>] (Ldiv0+0x8/0x10)
> >> [   22.009319] [<c02e4154>] (Ldiv0+0x8/0x10) from [<c048d460>] (clk_divider_set_rate+0x10/0xdc)
> >> [   22.009331] [<c048d460>] (clk_divider_set_rate+0x10/0xdc) from [<c048c124>] (clk_change_rate+0x38/0xb0)
> >> [   22.009341] [<c048c124>] (clk_change_rate+0x38/0xb0) from [<c048c20c>] (clk_set_rate+0x70/0xa8)
> >> [   22.009354] [<c048c20c>] (clk_set_rate+0x70/0xa8) from [<c042b244>] (nop_usb_xceiv_probe+0x1fc/0x2f8)
> >> [   22.009369] [<c042b244>] (nop_usb_xceiv_probe+0x1fc/0x2f8) from [<c036b47c>] (platform_drv_probe+0x18/0x1c)
> >> [   22.009380] [<c036b47c>] (platform_drv_probe+0x18/0x1c) from [<c0369f44>] (really_probe+0x70/0x1f4)
> >> [   22.009390] [<c0369f44>] (really_probe+0x70/0x1f4) from [<c036a1dc>] (driver_probe_device+0x30/0x48)
> >> [   22.009401] [<c036a1dc>] (driver_probe_device+0x30/0x48) from [<c036a288>] (__driver_attach+0x94/0x98)
> >> [   22.009411] [<c036a288>] (__driver_attach+0x94/0x98) from [<c0368748>] (bus_for_each_dev+0x54/0x88)
> >> [   22.009420] [<c0368748>] (bus_for_each_dev+0x54/0x88) from [<c036972c>] (bus_add_driver+0xdc/0x29c)
> >> [   22.009430] [<c036972c>] (bus_add_driver+0xdc/0x29c) from [<c036a760>] (driver_register+0x78/0x190)
> >> [   22.009440] [<c036a760>] (driver_register+0x78/0x190) from [<c00087b0>] (do_one_initcall+0x34/0x164)
> >> [   22.009453] [<c00087b0>] (do_one_initcall+0x34/0x164) from [<c07b18f4>] (do_basic_setup+0x90/0xc4)
> >> [   22.009466] [<c07b18f4>] (do_basic_setup+0x90/0xc4) from [<c07b199c>] (kernel_init_freeable+0x74/0x110)
> >> [   22.009478] [<c07b199c>] (kernel_init_freeable+0x74/0x110) from [<c05676c4>] (kernel_init+0x8/0xe4)
> >> [   22.009491] [<c05676c4>] (kernel_init+0x8/0xe4) from [<c0014648>] (ret_from_fork+0x14/0x2c)
> >>
> >> I believe the problem is the actual division reaching
> >> clk_divider_set_rate().
> >>
> >> drivers/clk/clk-divider.c::clk_divider_set_rate()
> >>
> >> | static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
> >> |                                 unsigned long parent_rate)
> >> | {
> >> |         struct clk_divider *divider = to_clk_divider(hw);
> >> |         unsigned int div, value;
> >> |         unsigned long flags = 0;
> >> |         u32 val;
> >> |
> >> |         div = parent_rate / rate;
> >>
> >> right here, but how come rate would zero provided driver checks for it
> >> as below.
> >>
> >> drivers/usb/phy/phy-nop.c::nop_usb_xceiv_probe()
> >>
> >> |         if (!IS_ERR(nop->clk) && clk_rate) {
> >> |                 err = clk_set_rate(nop->clk, clk_rate);
> >> |                 if (err) {
> >> |                         dev_err(&pdev->dev, "Error setting clock rate\n");
> >> |                         return err;
> >> |                 }
> >> |         }
> >>
> >> I've added a few prints around CCF to try and track what's going on:
> >>
> >> [   21.592690] ====> nop_usb_xceiv_probe rate 19200000
> >> [   21.592700] ====> clk_set_rate rate 19200000
> >> [   21.592707] ====> clk_calc_new_rates rate 19200000
> >> [   21.592713] ====> clk_divider_round_rate rate 19200000
> >> [   21.592719] ====> clk_divider_bestdiv rate 19200000
> >> [   21.592726] ====> clk_change_rate best_parent_rate 0
> >
> > or because we reach:
> >         if (clk->ops->set_rate)
> >                 clk->ops->set_rate(clk->hw, clk->new_rate, best_parent_rate);
> >
> > with clk->new_rate == 0.
> 
> Hmm, I'll look into this. We used to have a check which would at least
> WARN on division by zero, but looks like that was replaced by some
> other code at some point.
> 
> Also does your clock have the CLK_SET_RATE_PARENT flag set? If so then
> you could be propagating a rate request of zero up to the next parent,
> which would be a neat trick... however based on the dump that doesn't
> seem to be what is happening.
> 
> Regards,
> Mike
> 
> >
> >
> >> [   21.592732] ====> clk_divider_set_rate rate 0
> >> [   21.592737] Division by zero in kernel.
> >> [   21.592747] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W    3.11.0-rc1-00081-g3310d44-dirty #121
> >> [   21.592773] [<c001c83c>] (unwind_backtrace+0x0/0xf0) from [<c0018a1c>] (show_stack+0x10/0x14)
> >> [   21.592787] [<c0018a1c>] (show_stack+0x10/0x14) from [<c057400c>] (dump_stack+0x70/0x8c)
> >> [   21.592803] [<c057400c>] (dump_stack+0x70/0x8c) from [<c02e4154>] (Ldiv0+0x8/0x10)
> >> [   21.592819] [<c02e4154>] (Ldiv0+0x8/0x10) from [<c048d3e0>] (clk_divider_set_rate+0x2c/0x100)
> >> [   21.592831] [<c048d3e0>] (clk_divider_set_rate+0x2c/0x100) from [<c048c050>] (clk_change_rate+0x48/0xe0)
> >> [   21.592841] [<c048c050>] (clk_change_rate+0x48/0xe0) from [<c048c174>] (clk_set_rate+0x8c/0xc0)
> >> [   21.592855] [<c048c174>] (clk_set_rate+0x8c/0xc0) from [<c042b254>] (nop_usb_xceiv_probe+0x20c/0x304)
> >> [   21.592869] [<c042b254>] (nop_usb_xceiv_probe+0x20c/0x304) from [<c036b47c>] (platform_drv_probe+0x18/0x1c)
> >> [   21.592880] [<c036b47c>] (platform_drv_probe+0x18/0x1c) from [<c0369f44>] (really_probe+0x70/0x1f4)
> >> [   21.592891] [<c0369f44>] (really_probe+0x70/0x1f4) from [<c036a1dc>] (driver_probe_device+0x30/0x48)
> >> [   21.592901] [<c036a1dc>] (driver_probe_device+0x30/0x48) from [<c036a288>] (__driver_attach+0x94/0x98)
> >> [   21.592911] [<c036a288>] (__driver_attach+0x94/0x98) from [<c0368748>] (bus_for_each_dev+0x54/0x88)
> >> [   21.592921] [<c0368748>] (bus_for_each_dev+0x54/0x88) from [<c036972c>] (bus_add_driver+0xdc/0x29c)
> >> [   21.592930] [<c036972c>] (bus_add_driver+0xdc/0x29c) from [<c036a760>] (driver_register+0x78/0x190)
> >> [   21.592941] [<c036a760>] (driver_register+0x78/0x190) from [<c00087b0>] (do_one_initcall+0x34/0x164)
> >> [   21.592954] [<c00087b0>] (do_one_initcall+0x34/0x164) from [<c07b18f4>] (do_basic_setup+0x90/0xc4)
> >> [   21.592966] [<c07b18f4>] (do_basic_setup+0x90/0xc4) from [<c07b199c>] (kernel_init_freeable+0x74/0x110)
> >> [   21.592980] [<c07b199c>] (kernel_init_freeable+0x74/0x110) from [<c0567694>] (kernel_init+0x8/0xe4)
> >> [   21.592992] [<c0567694>] (kernel_init+0x8/0xe4) from [<c0014648>] (ret_from_fork+0x14/0x2c)
> >>
> >> even though driver passed 19.2MHz, best_parent_rate ends up being zero
> >> which triggers the division by zero above.
> >>
> >> cheers
> >>
> >
> >
> > - --
> > You have got to be excited about what you are doing. (L. Lamport)
> >
> > Eduardo Valentin
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.12 (GNU/Linux)
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iF4EAREIAAYFAlHlRl8ACgkQCXcVR3XQvP00XQEAtQgDEJLt8OFCJiIhUj46Zq1h
> > PvNq67RSFTRXcq/zHa8A/0IZSPitTXt1TqDfalTKof/DR6n9/W6md8/C2Ovqb59o
> > =AKnu
> > -----END PGP SIGNATURE-----

-- 
balbi
-------------- 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/20130730/1456a858/attachment.sig>

From linux at arm.linux.org.uk  Tue Jul 30 10:04:51 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 30 Jul 2013 15:04:51 +0100
Subject: [PATCH] arm: update advice on kernel and FDT load address.
In-Reply-To: <1375192570.32691.27.camel@kazak.uk.xensource.com>
References: <1375102578-5869-1-git-send-email-ian.campbell@citrix.com>
 <20130729135000.GK32383@mudshark.cambridge.arm.com>
 <1375106635.12741.8.camel@kazak.uk.xensource.com>
 <alpine.LFD.2.03.1307292234040.15022@syhkavp.arg>
 <1375192570.32691.27.camel@kazak.uk.xensource.com>
Message-ID: <20130730140451.GQ24642@n2100.arm.linux.org.uk>

On Tue, Jul 30, 2013 at 02:56:10PM +0100, Ian Campbell wrote:
> Actually I've just noticed that the existing text in
> Documentation/arm/Booting only talks about zImage and 32KiB, so perhaps
> not worrying about non-zImage is acceptable?

Straight binary kernels have tighter requirements, because they're _not_
entirely position independent.  Firstly, with dynamic physical offset,
they calculate that based on their position in physical space when
they're first called.

So, with a PAGE_OFFSET of 0xc0000000 and a link address of 0xc0008000,
a binary kernel image better be placed at 0xXXXX8000, and it _will_
assume that RAM starts 32KiB below itself.  And yes, the 32KiB offset
applies as the kernel uses TEXTADDR-16KiB to store the initial page
tables.


From daniel.lezcano at linaro.org  Tue Jul 30 10:15:37 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 30 Jul 2013 16:15:37 +0200
Subject: [PATCH] clocksource: em_sti: Convert to devm_* managed helpers
In-Reply-To: <2725526.9tXHptSQgN@avalon>
References: <1374848897-18545-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
 <20130730020640.GA27724@verge.net.au> <51F7229D.7090706@linaro.org>
 <2725526.9tXHptSQgN@avalon>
Message-ID: <51F7CA89.5070305@linaro.org>

On 07/30/2013 12:03 PM, Laurent Pinchart wrote:
> Hi Simon, John,
> 
> On Monday 29 July 2013 19:19:09 John Stultz wrote:
>> On 07/29/2013 07:06 PM, Simon Horman wrote:
>>> [ CC John Stultz, Thomas Gleixner ]
>>>
>>> On Fri, Jul 26, 2013 at 04:28:17PM +0200, Laurent Pinchart wrote:
>>>> Replace kzalloc, clk_get, ioremap and request_irq by their managed
>>>> counterparts to simplify error paths.
>>>>
>>>> Signed-off-by: Laurent Pinchart
>>>> <laurent.pinchart+renesas at ideasonboard.com>
>>>
>>> Hi Laurent,
>>>
>>> I was recently asked for shmobile clocksource patches to be reviewed
>>> by the clocksource maintainers. I believe that means John Stultz
>>> and Thomas Gleixner who I have CCed on this email accordingly.
>>
>> Daniel Lezcano (cc'ed) is picking up maintainership of
>> clocksource/clockevent code in drivers/clocksource, so please cc him in
>> the future.
> 
> Sure, will do so (I suppose Daniel will show up in MAINTAINERS, otherwise I 
> might forget).

Yes it is the case [1].

Please could you resend the patch, I don't see it in my mailbox.

Thanks
  -- Daniel

[1]
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers/core&id=9222d247bcbaacc40fe15549158f9d67523c1ace





-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From r.sricharan at ti.com  Tue Jul 30 10:18:23 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Tue, 30 Jul 2013 19:48:23 +0530
Subject: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx
 based SoCs'
In-Reply-To: <20130730131009.GA28162@radagast>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-2-git-send-email-rnayak@ti.com>
 <20130730131009.GA28162@radagast>
Message-ID: <51F7CB2F.6070705@ti.com>

On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
>> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
>>  # define soc_is_omap543x()		is_omap543x()
>>  #endif
>>  
>> +# if defined(CONFIG_SOC_DRA7XX)
>> +# undef soc_is_dra7xx
>> +# undef soc_is_dra75x
>> +# define soc_is_dra7xx()		is_dra7xx()
>> +# define soc_is_dra75x()		is_dra75x()
> since this platform is DT-only, couldn't we just believe DT-data to be
> correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
>
> I patched this for OMAP5 (compile-tested only, no boards available) and
> came out with the patch below (still needs to be split):
>
> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
> index 08b7267..b3136e5 100644
> --- a/arch/arm/boot/dts/omap5-uevm.dts
> +++ b/arch/arm/boot/dts/omap5-uevm.dts
> @@ -13,7 +13,7 @@
>  
>  / {
>  	model = "TI OMAP5 uEVM board";
> -	compatible = "ti,omap5-uevm", "ti,omap5";
> +	compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5";
>  
 ok, nice and simpler way.
 But would this make different revisions, to appear the same ?

Regards,
 Sricharan
>  	memory {
>  		device_type = "memory";
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 07be2cd..a7bc906 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -17,7 +17,7 @@
>  	#address-cells = <1>;
>  	#size-cells = <1>;
>  
> -	compatible = "ti,omap5";
> +	compatible = "ti,omap5432-es2.0", "ti,omap5430-es2.0", "ti,omap5";
>  	interrupt-parent = <&gic>;
>  
>  	aliases {
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 2dc62a2..ee94309 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -563,49 +563,6 @@ void __init omap4xxx_check_revision(void)
>  	pr_info("%s %s\n", soc_name, soc_rev);
>  }
>  
> -void __init omap5xxx_check_revision(void)
> -{
> -	u32 idcode;
> -	u16 hawkeye;
> -	u8 rev;
> -
> -	idcode = read_tap_reg(OMAP_TAP_IDCODE);
> -	hawkeye = (idcode >> 12) & 0xffff;
> -	rev = (idcode >> 28) & 0xff;
> -	switch (hawkeye) {
> -	case 0xb942:
> -		switch (rev) {
> -		case 0:
> -			omap_revision = OMAP5430_REV_ES1_0;
> -			break;
> -		case 1:
> -		default:
> -			omap_revision = OMAP5430_REV_ES2_0;
> -		}
> -		break;
> -
> -	case 0xb998:
> -		switch (rev) {
> -		case 0:
> -			omap_revision = OMAP5432_REV_ES1_0;
> -			break;
> -		case 1:
> -		default:
> -			omap_revision = OMAP5432_REV_ES2_0;
> -		}
> -		break;
> -
> -	default:
> -		/* Unknown default to latest silicon rev as default*/
> -		omap_revision = OMAP5430_REV_ES2_0;
> -	}
> -
> -	sprintf(soc_name, "OMAP%04x", omap_rev() >> 16);
> -	sprintf(soc_rev, "ES%d.0", (omap_rev() >> 12) & 0xf);
> -
> -	pr_info("%s %s\n", soc_name, soc_rev);
> -}
> -
>  /*
>   * Set up things for map_io and processor detection later on. Gets called
>   * pretty much first thing from board init. For multi-omap, this gets
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index 4a3f06f..aa28940 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -633,8 +633,7 @@ void __init omap4430_init_late(void)
>  #ifdef CONFIG_SOC_OMAP5
>  void __init omap5_init_early(void)
>  {
> -	omap2_set_globals_tap(OMAP54XX_CLASS,
> -			      OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
> +	omap2_set_globals_tap(-1, OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
>  	omap2_set_globals_control(OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
>  				  OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE));
>  	omap2_set_globals_prm(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE));
> @@ -644,7 +643,6 @@ void __init omap5_init_early(void)
>  	omap_prm_base_init();
>  	omap_cm_base_init();
>  	omap44xx_prm_init();
> -	omap5xxx_check_revision();
>  	omap54xx_voltagedomains_init();
>  	omap54xx_powerdomains_init();
>  	omap54xx_clockdomains_init();
> diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
> index 8c616e4..b8339ad 100644
> --- a/arch/arm/mach-omap2/soc.h
> +++ b/arch/arm/mach-omap2/soc.h
> @@ -35,6 +35,7 @@
>  #ifndef __ASSEMBLY__
>  
>  #include <linux/bitops.h>
> +#include <linux/of.h>
>  
>  /*
>   * Test if multicore OMAP support is needed
> @@ -194,7 +195,6 @@ IS_OMAP_CLASS(24xx, 0x24)
>  IS_OMAP_CLASS(34xx, 0x34)
>  IS_OMAP_CLASS(44xx, 0x44)
>  IS_AM_CLASS(35xx, 0x35)
> -IS_OMAP_CLASS(54xx, 0x54)
>  IS_AM_CLASS(33xx, 0x33)
>  IS_AM_CLASS(43xx, 0x43)
>  
> @@ -207,7 +207,6 @@ IS_OMAP_SUBCLASS(363x, 0x363)
>  IS_OMAP_SUBCLASS(443x, 0x443)
>  IS_OMAP_SUBCLASS(446x, 0x446)
>  IS_OMAP_SUBCLASS(447x, 0x447)
> -IS_OMAP_SUBCLASS(543x, 0x543)
>  
>  IS_TI_SUBCLASS(816x, 0x816)
>  IS_TI_SUBCLASS(814x, 0x814)
> @@ -373,10 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430)
>  # endif
>  
>  # if defined(CONFIG_SOC_OMAP5)
> -# undef soc_is_omap54xx
> -# undef soc_is_omap543x
> -# define soc_is_omap54xx()		is_omap54xx()
> -# define soc_is_omap543x()		is_omap543x()
> +# undef  soc_is_omap54xx
> +# undef  soc_is_omap543x
> +# define soc_is_omap54xx()		(of_machine_is_compatible("ti,omap5"))
> +# define soc_is_omap543x()		(soc_is_omap54xx())
>  #endif
>  
>  /* Various silicon revisions for omap2 */
> @@ -437,16 +436,9 @@ IS_OMAP_TYPE(3430, 0x3430)
>  #define OMAP447X_CLASS		0x44700044
>  #define OMAP4470_REV_ES1_0	(OMAP447X_CLASS | (0x10 << 8))
>  
> -#define OMAP54XX_CLASS		0x54000054
> -#define OMAP5430_REV_ES1_0	(OMAP54XX_CLASS | (0x30 << 16) | (0x10 << 8))
> -#define OMAP5430_REV_ES2_0	(OMAP54XX_CLASS | (0x30 << 16) | (0x20 << 8))
> -#define OMAP5432_REV_ES1_0	(OMAP54XX_CLASS | (0x32 << 16) | (0x10 << 8))
> -#define OMAP5432_REV_ES2_0	(OMAP54XX_CLASS | (0x32 << 16) | (0x20 << 8))
> -
>  void omap2xxx_check_revision(void);
>  void omap3xxx_check_revision(void);
>  void omap4xxx_check_revision(void);
> -void omap5xxx_check_revision(void);
>  void omap3xxx_check_features(void);
>  void ti81xx_check_features(void);
>  void am33xx_check_features(void);
>



From gregkh at linuxfoundation.org  Tue Jul 30 10:20:47 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 30 Jul 2013 07:20:47 -0700
Subject: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner's
 Security ID fuses
In-Reply-To: <51F7BE2F.3060004@schinagl.nl>
References: <20130626175144.GC2222@kroah.com> <51D674BF.9030207@schinagl.nl>
 <20130706193646.GB9778@kroah.com> <51E466A3.4010503@schinagl.nl>
 <20130716064107.GA10868@kroah.com> <20130717114650.GN3125@lukather>
 <20130717161758.GA9822@kroah.com> <20130719094211.GD5106@lukather>
 <20130719234944.GA11498@kroah.com> <51F7BE2F.3060004@schinagl.nl>
Message-ID: <20130730142047.GA28696@kroah.com>

On Tue, Jul 30, 2013 at 03:22:55PM +0200, Oliver Schinagl wrote:
> >Let me go look at how I can make this work "easier", give me a few days.
> Not wanting to be rude, but it has been a little more then a few
> days, any progress? Just want to know what I have to modify my
> driver to so it can go into the next merge window :)

What?  Oh crap.

I saw this old email in my todo box last week and for some stupid reason
I thought I had already taken care of this, otherwise why would I have
left it around for so long?...

Ugh, very sorry about that...

Hm, this is a mess.  I hate platform devices...

Anyway, as you want to get this into 3.12, and I'm not going to be able
to get the core infrastructure into the platform device by then, just go
ahead and do a sysfs_create_group() call in your device probe callback
for now.  That will register the needed files for the device (not the
driver, DOH that was stupid of me...) and all should be ok.

Yes, you will still race with userspace, but as right now, there's no
way that _any_ platform driver can do this "correctly", you will be in
good company.  I'll clean up all platform drivers in a sweep of the tree
after 3.12 or so when I get the needed infrastructure in place for the
platform_driver code.

Again, very sorry for all of this, you have helped me out a lot in
figuring out that this is a mess, and should be fixed up better, but in
the end, you are pretty much back at the beginning of what you
originally wanted to do, right?

I owe you a beer, at the least, my apologies...

greg k-h


From laurent.pinchart+renesas at ideasonboard.com  Tue Jul 30 10:24:37 2013
From: laurent.pinchart+renesas at ideasonboard.com (Laurent Pinchart)
Date: Tue, 30 Jul 2013 16:24:37 +0200
Subject: [PATCH/RESEND] clocksource: em_sti: Convert to devm_* managed helpers
Message-ID: <1375194277-2850-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Replace kzalloc, clk_get, ioremap and request_irq by their managed
counterparts to simplify error paths.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
---
 drivers/clocksource/em_sti.c | 49 +++++++++++++-------------------------------
 1 file changed, 14 insertions(+), 35 deletions(-)

Resending with Daniel Lezcano CC'ed.

diff --git a/drivers/clocksource/em_sti.c b/drivers/clocksource/em_sti.c
index 4329a29..b9c81b7 100644
--- a/drivers/clocksource/em_sti.c
+++ b/drivers/clocksource/em_sti.c
@@ -315,68 +315,47 @@ static int em_sti_probe(struct platform_device *pdev)
 {
 	struct em_sti_priv *p;
 	struct resource *res;
-	int irq, ret;
+	int irq;
 
-	p = kzalloc(sizeof(*p), GFP_KERNEL);
+	p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
 	if (p == NULL) {
 		dev_err(&pdev->dev, "failed to allocate driver data\n");
-		ret = -ENOMEM;
-		goto err0;
+		return -ENOMEM;
 	}
 
 	p->pdev = pdev;
 	platform_set_drvdata(pdev, p);
 
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (!res) {
-		dev_err(&pdev->dev, "failed to get I/O memory\n");
-		ret = -EINVAL;
-		goto err0;
-	}
-
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
 		dev_err(&pdev->dev, "failed to get irq\n");
-		ret = -EINVAL;
-		goto err0;
+		return -EINVAL;
 	}
 
 	/* map memory, let base point to the STI instance */
-	p->base = ioremap_nocache(res->start, resource_size(res));
-	if (p->base == NULL) {
-		dev_err(&pdev->dev, "failed to remap I/O memory\n");
-		ret = -ENXIO;
-		goto err0;
-	}
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	p->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(p->base))
+		return PTR_ERR(p->base);
 
 	/* get hold of clock */
-	p->clk = clk_get(&pdev->dev, "sclk");
+	p->clk = devm_clk_get(&pdev->dev, "sclk");
 	if (IS_ERR(p->clk)) {
 		dev_err(&pdev->dev, "cannot get clock\n");
-		ret = PTR_ERR(p->clk);
-		goto err1;
+		return PTR_ERR(p->clk);
 	}
 
-	if (request_irq(irq, em_sti_interrupt,
-			IRQF_TIMER | IRQF_IRQPOLL | IRQF_NOBALANCING,
-			dev_name(&pdev->dev), p)) {
+	if (devm_request_irq(&pdev->dev, irq, em_sti_interrupt,
+			     IRQF_TIMER | IRQF_IRQPOLL | IRQF_NOBALANCING,
+			     dev_name(&pdev->dev), p)) {
 		dev_err(&pdev->dev, "failed to request low IRQ\n");
-		ret = -ENOENT;
-		goto err2;
+		return -ENOENT;
 	}
 
 	raw_spin_lock_init(&p->lock);
 	em_sti_register_clockevent(p);
 	em_sti_register_clocksource(p);
 	return 0;
-
-err2:
-	clk_put(p->clk);
-err1:
-	iounmap(p->base);
-err0:
-	kfree(p);
-	return ret;
 }
 
 static int em_sti_remove(struct platform_device *pdev)
-- 
Regards,

Laurent Pinchart



From gregkh at linuxfoundation.org  Tue Jul 30 10:25:17 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 30 Jul 2013 07:25:17 -0700
Subject: [PATCH 2/2] arm: omap: remove *.auto* from device names given in
 usb_bind_phy
In-Reply-To: <20130730081520.GH16441@radagast>
References: <51F74BC8.7020903@ti.com> <20130730060134.GD9155@radagast>
 <51F7590B.4020705@ti.com> <20130730061830.GE9155@radagast>
 <51F75C40.4060406@ti.com> <20130730062844.GH9155@radagast>
 <51F7613C.5070803@ti.com> <20130730071611.GD16441@radagast>
 <51F7752B.8050804@ti.com> <20130730081520.GH16441@radagast>
Message-ID: <20130730142517.GA29015@kroah.com>

On Tue, Jul 30, 2013 at 11:15:20AM +0300, Felipe Balbi wrote:
> > > look at Greg's and my reply to that email.
> > 
> > but finally Greg agreed to what Tomasz proposed no?
> 
> that's not what I see in the thread. I see Greg agreed to regulator's
> own IDs being sequentially created, but he mentions device names can
> change.

And that no one should _ever_ rely on them to be a specific "name", the
bus is responsible for creating the id, it could be "random" and
everything should work just fine.

thanks,

greg k-h


From balbi at ti.com  Tue Jul 30 10:23:53 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 30 Jul 2013 17:23:53 +0300
Subject: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for
 DRA7xx based SoCs'
In-Reply-To: <51F7CB2F.6070705@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-2-git-send-email-rnayak@ti.com>
 <20130730131009.GA28162@radagast> <51F7CB2F.6070705@ti.com>
Message-ID: <20130730142353.GL28162@radagast>

Hi,

On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote:
> On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
> >> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
> >>  # define soc_is_omap543x()		is_omap543x()
> >>  #endif
> >>  
> >> +# if defined(CONFIG_SOC_DRA7XX)
> >> +# undef soc_is_dra7xx
> >> +# undef soc_is_dra75x
> >> +# define soc_is_dra7xx()		is_dra7xx()
> >> +# define soc_is_dra75x()		is_dra75x()
> > since this platform is DT-only, couldn't we just believe DT-data to be
> > correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
> >
> > I patched this for OMAP5 (compile-tested only, no boards available) and
> > came out with the patch below (still needs to be split):
> >
> > diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
> > index 08b7267..b3136e5 100644
> > --- a/arch/arm/boot/dts/omap5-uevm.dts
> > +++ b/arch/arm/boot/dts/omap5-uevm.dts
> > @@ -13,7 +13,7 @@
> >  
> >  / {
> >  	model = "TI OMAP5 uEVM board";
> > -	compatible = "ti,omap5-uevm", "ti,omap5";
> > +	compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5";
> >  
>  ok, nice and simpler way.
>  But would this make different revisions, to appear the same ?

well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up,
it should be treated as such, then you can pass a different string to
that new board's compatible attribute.

-- 
balbi
-------------- 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/20130730/3cbeae19/attachment.sig>

From paul.gortmaker at windriver.com  Tue Jul 30 10:27:51 2013
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Tue, 30 Jul 2013 10:27:51 -0400
Subject: ARM CPU Hotplug breakage on mach-shmobile and KZM9D
In-Reply-To: <20130730074939.GE7210@verge.net.au>
References: <CANqRtoRx7voEVwJG8UNNy_Jiixo=uRJCvxTD0bZdzVohoryBUA@mail.gmail.com>
 <20130725010607.GB31464@verge.net.au> <20130730074939.GE7210@verge.net.au>
Message-ID: <51F7CD67.6020209@windriver.com>

On 13-07-30 03:49 AM, Simon Horman wrote:
> [ Cc Paul Gortmaker ]
> 
> On Thu, Jul 25, 2013 at 10:06:07AM +0900, Simon Horman wrote:
>> On Thu, Jul 25, 2013 at 12:15:49AM +0900, Magnus Damm wrote:
>>> Hi everyone,
>>>
>>> Bad news: CPU Hotplug on KZM9D seems broken on recent kernels.
>>>
>>> On renesas-next-20130710 or earlier I can perform the following:
>>>
>>> # echo 0 > /sys/devices/system/cpu/cpu1/online
>>> CPU1: shutdown
>>> # echo 1 > /sys/devices/system/cpu/cpu1/online
>>> CPU1: Booted secondary processor
>>> #
>>>
>>> While on more recent kernels the hotplug boot fails. This may be
>>> related to the move to v3.11-rc. The tag renesas-next-20130710
>>> surprisingly seems to be the final kernel based on v3.10-rc before
>>> jumping to v3.11-rc.
>>>
>>> I wonder, do other ARM platforms have working CPU Hotplug in v3.11-rc?
>>
>> I have a snowball that I could test if you think it would be useful.
> 
> Unfortunately getting snowball to work turned out to be rather painful.
> So instead I bisected the problem on the KZM9G (N.b: the D in the subject
> seems to be incorrect :^)
> 
> The result is that the following patch, added in v3.11-rc1,
> appears to be the culprit.

Double check that you have this commit present:
 ---------------
commit 8c69d7af12265e5be9326110b695e010b47505bd
Author: Stephen Warren <swarren at nvidia.com>
Date:   Fri Jul 5 22:59:42 2013 +0100

    ARM: 7780/1: add missing linker section markup to head-common.S
 ---------------

as I think you are reporting the same problem that it fixed.

Thanks,
Paul.
--

> 
> commit 22f0a27367742f65130c0fb25ef00f7297e032c1
> Author: Paul Gortmaker <paul.gortmaker at windriver.com>
> Date:   Mon Jun 17 18:34:14 2013 -0400
> 
>     init.h: remove __cpuinit sections from the kernel
>     
>     The __cpuinit type of throwaway sections might have made sense
>     some time ago when RAM was more constrained, but now the savings
>     do not offset the cost and complications.  For example, the fix in
>     commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
>     is a good example of the nasty type of bugs that can be created
>     with improper use of the various __init prefixes.
>     
>     After a discussion on LKML[1] it was decided that cpuinit should go
>     the way of devinit and be phased out.  Once all the users are gone,
>     we can then finally remove the macros themselves from linux/init.h.
>     
>     As an interim step, we can dummy out the macros to be no-ops, and
>     this will allow us to avoid a giant tree-wide patch, and instead
>     we can feed in smaller chunks mainly via the arch/ trees.  This
>     is in keeping with commit 78d86c213f28193082b5d8a1a424044b7ba406f1
>     ("init.h: Remove __dev* sections from the kernel")
>     
>     We don't strictly need to dummy out the macros to do this, but if
>     we don't then some harmless section mismatch warnings may temporarily
>     result.  For example, notify_cpu_starting() and cpu_up() are arch
>     independent (kernel/cpu.c) and are flagged as __cpuinit.  And hence
>     the calling functions in the arch specific code are also expected
>     to be __cpuinit -- if not, then we get the section mismatch warning.
>     
>     Two of the three __CPUINIT variants are not used whatsoever, and
>     so they are simply removed directly at this point in time.
>     
>     [1] https://lkml.org/lkml/2013/5/20/589
>     
>     Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> 
> diff --git a/include/linux/init.h b/include/linux/init.h
> index 8618147..e73f2b70 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -93,13 +93,13 @@
>  
>  #define __exit          __section(.exit.text) __exitused __cold notrace
>  
> -/* Used for HOTPLUG_CPU */
> -#define __cpuinit        __section(.cpuinit.text) __cold notrace
> -#define __cpuinitdata    __section(.cpuinit.data)
> -#define __cpuinitconst   __constsection(.cpuinit.rodata)
> -#define __cpuexit        __section(.cpuexit.text) __exitused __cold notrace
> -#define __cpuexitdata    __section(.cpuexit.data)
> -#define __cpuexitconst   __constsection(.cpuexit.rodata)
> +/* temporary, until all users are removed */
> +#define __cpuinit
> +#define __cpuinitdata
> +#define __cpuinitconst
> +#define __cpuexit
> +#define __cpuexitdata
> +#define __cpuexitconst
>  
>  /* Used for MEMORY_HOTPLUG */
>  #define __meminit        __section(.meminit.text) __cold notrace
> @@ -118,9 +118,8 @@
>  #define __INITRODATA	.section	".init.rodata","a",%progbits
>  #define __FINITDATA	.previous
>  
> -#define __CPUINIT        .section	".cpuinit.text", "ax"
> -#define __CPUINITDATA    .section	".cpuinit.data", "aw"
> -#define __CPUINITRODATA  .section	".cpuinit.rodata", "a"
> +/* temporary, until all users are removed */
> +#define __CPUINIT
>  
>  #define __MEMINIT        .section	".meminit.text", "ax"
>  #define __MEMINITDATA    .section	".meminit.data", "aw"
> 


From Ian.Campbell at citrix.com  Tue Jul 30 10:30:51 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Tue, 30 Jul 2013 15:30:51 +0100
Subject: [PATCH] arm: update advice on kernel and FDT load address.
In-Reply-To: <20130730140451.GQ24642@n2100.arm.linux.org.uk>
References: <1375102578-5869-1-git-send-email-ian.campbell@citrix.com>
 <20130729135000.GK32383@mudshark.cambridge.arm.com>
 <1375106635.12741.8.camel@kazak.uk.xensource.com>
 <alpine.LFD.2.03.1307292234040.15022@syhkavp.arg>
 <1375192570.32691.27.camel@kazak.uk.xensource.com>
 <20130730140451.GQ24642@n2100.arm.linux.org.uk>
Message-ID: <1375194651.32691.52.camel@kazak.uk.xensource.com>

On Tue, 2013-07-30 at 15:04 +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 30, 2013 at 02:56:10PM +0100, Ian Campbell wrote:
> > Actually I've just noticed that the existing text in
> > Documentation/arm/Booting only talks about zImage and 32KiB, so perhaps
> > not worrying about non-zImage is acceptable?
> 
> Straight binary kernels have tighter requirements, because they're _not_
> entirely position independent.  Firstly, with dynamic physical offset,
> they calculate that based on their position in physical space when
> they're first called.
> 
> So, with a PAGE_OFFSET of 0xc0000000 and a link address of 0xc0008000,
> a binary kernel image better be placed at 0xXXXX8000, and it _will_
> assume that RAM starts 32KiB below itself.  And yes, the 32KiB offset
> applies as the kernel uses TEXTADDR-16KiB to store the initial page
> tables.

OK, so in the non-zImage case 32KiB is a Requirement and not just a
recommendation. I'll update things to that affect.

This is turning out to be more complicated to write down than I
imagined!

Ian.



From stefano.stabellini at eu.citrix.com  Tue Jul 30 10:33:34 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 30 Jul 2013 15:33:34 +0100
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <20130730134427.GE28716@e106331-lin.cambridge.arm.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
 <51F7B4C9.2060500@gmail.com>
 <20130730125650.GD28716@e106331-lin.cambridge.arm.com>
 <20130730134427.GE28716@e106331-lin.cambridge.arm.com>
Message-ID: <alpine.DEB.2.02.1307301528540.4893@kaball.uk.xensource.com>

On Tue, 30 Jul 2013, Mark Rutland wrote:
> On Tue, Jul 30, 2013 at 01:56:50PM +0100, Mark Rutland wrote:
> > On Tue, Jul 30, 2013 at 01:42:49PM +0100, Rob Herring wrote:
> > > On 07/30/2013 04:49 AM, Mark Rutland wrote:
> > > > On Mon, Jul 29, 2013 at 09:18:43PM +0100, Rob Herring wrote:
> > > >> On 07/29/2013 05:13 AM, Mark Rutland wrote:
> > > >>> Hi Rob,
> > > >>>
> > > >>> On Sun, Jul 28, 2013 at 10:56:32PM +0100, Rob Herring wrote:
> > > >>>> From: Rob Herring <rob.herring at calxeda.com>
> > > 
> > > [snip]
> > > 
> > > >>> One of the things changed in PSCI 0.2 was the SMC calling convention,
> > > >>> though this isn't clear in the PSCI document. The function IDs for 32bit
> > > >>> and 64bit callers may differ, and we need to support describing an
> > > >>> arbitrary configuration of the two (same ID for both, different across
> > > >>> 32-bit/64-bit, only supported for 64-bit, only supported for 32-bit).
> > > >>>
> > > >>> I'd like to ensure the binding can deal with that from the start. We
> > > >>> could do this by having -32 and -64 variants of each function id (e.g.
> > > >>> cpu_off-64) , if the IDs actually differ, and use the regular combined
> > > >>> ID if they don't.
> > > >>
> > > >> Uggg. I guess I should have read the SMC calling convention doc... I was
> > > >> simply documenting what is already in the PSCI doc, but obviously that
> > > >> is not fully flushed out.
> > > >>
> > > >> How about something like this (for the complicated case of both 32 and
> > > >> 64 bit):
> > > >>
> > > >> 	method		= "smc", "smc64";
> > > >> 	psci_version	= <0x84000000 0xc4000000>;
> > > >> 	cpu_suspend	= <0x84000001 0xc4000001>;
> > > >> 	cpu_off		= <0x84000002 0xc4000002>;
> > > >> 	cpu_on		= <0x84000003 0xc4000003>;
> > > >>
> > > >> "smc" is a synonym for smc32 for compatibility. The number and order of
> > > >> methods determines the number and order of function IDs.
> > > > 
> > > > While this may be compatible with the arm implementation, it won't be
> > > > compatible with the arm64 implementation, which assumes smc64 by
> > > > default.
> > > > 
> > > > As far as I am aware, the implementations currently in use (KVM and Xen)
> > > > use the same ID for both, so I think "smc" should cover an ID valid for
> > > > a native register width calling convention, and "smc64" and "smc32"
> > > > describing values only valid for 64-bit wide and 32-bit wide calling
> > > > conventions respectively.
> > > 
> > > The problem is that does not work for a 32-bit kernel on 64-bit h/w as
> > > native from the dts perspective is smc64. Just like the cpu bindings,
> > > the binding cannot change based on 32 or 64 bit OS. I don't think we
> > > really have to deal with that here. We can simply say "smc" is only for
> > > "arm,psci" and deprecated for "arm,psci-0.2".
> > 
> > Agreed. I'd be happy with only having "smc32" and "smc64" for
> > "arm,psci-0.2".

I would be happy with that too (Xen only uses HVC as "method").


> Actually, from some quick discussion with Marc and Dave, I think we can
> handle this better, in a way that leaves this backwards compatible.
> 
> Rather than relying on the method string to tell us the calling
> convention, I think we should rely on the function ID, as I proposed
> earlier. The existing function ids provided in the "arm,psci" binding
> are implicitly relying on the PSCI implementation to detect the register
> width and act accordingly. This is trivially true on 32bit hardware, KVM
> (where the same ID is used for 32-bit and 64-bit guests), and while I'm
> not entirely sure about Xen I believe it's true there. We can make this
> explicit as we extend the binding.
> 
> Having a -64 and -32 variant of each ID (while not pretty) allows us to
> add additional IDs for functions that might only have a 32-bit or 64-bit
> interface implemented, in addition to functions with common IDs:
> 
> psci {
> 	compatible = "$VENDOR,psci-0.2", "arm,psci-0.2", "arm,psci";
> 	cpu_off = <12345678>;
> 	cpu_on = <01234567>;
> 	system_reset-32 = <02222222>;
> 	system_reset-64 = <12222222>;
> 	affinity_info-64 = <15555555>;
> };
> 
> This means that hypervisors could update their PSCI implementation while
> keeping their DTS compatible with existing kernels.

Are you proposing of getting rid of "method" completely and therefore
have 4 possible function IDs for each function:

system_reset-32-HVC
system_reset-64-SMC
system_reset-32-HVC
system_reset-64-SMC

or are you proposing of choosing just the register width via function
IDs?

Honestly I think it would be cleaner to introduce a new field called
"width" can that be 32 or 64 and represent the register width, rather
than having an explosion of function IDs.


From r.sricharan at ti.com  Tue Jul 30 10:36:31 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Tue, 30 Jul 2013 20:06:31 +0530
Subject: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx
 based SoCs'
In-Reply-To: <20130730142353.GL28162@radagast>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-2-git-send-email-rnayak@ti.com>
 <20130730131009.GA28162@radagast> <51F7CB2F.6070705@ti.com>
 <20130730142353.GL28162@radagast>
Message-ID: <51F7CF6F.6050702@ti.com>

On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote:
>> On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
>>>> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
>>>>  # define soc_is_omap543x()		is_omap543x()
>>>>  #endif
>>>>  
>>>> +# if defined(CONFIG_SOC_DRA7XX)
>>>> +# undef soc_is_dra7xx
>>>> +# undef soc_is_dra75x
>>>> +# define soc_is_dra7xx()		is_dra7xx()
>>>> +# define soc_is_dra75x()		is_dra75x()
>>> since this platform is DT-only, couldn't we just believe DT-data to be
>>> correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
>>>
>>> I patched this for OMAP5 (compile-tested only, no boards available) and
>>> came out with the patch below (still needs to be split):
>>>
>>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
>>> index 08b7267..b3136e5 100644
>>> --- a/arch/arm/boot/dts/omap5-uevm.dts
>>> +++ b/arch/arm/boot/dts/omap5-uevm.dts
>>> @@ -13,7 +13,7 @@
>>>  
>>>  / {
>>>  	model = "TI OMAP5 uEVM board";
>>> -	compatible = "ti,omap5-uevm", "ti,omap5";
>>> +	compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5";
>>>  
>>  ok, nice and simpler way.
>>  But would this make different revisions, to appear the same ?
> well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up,
> it should be treated as such, then you can pass a different string to
> that new board's compatible attribute.
>
 Yes for OMAP5. I was thinking in general about this approach.
 For example, for OMAP4 we have same board and
 different revisions can be socketed there.

 For OMAP5, this is good.

Regards,
 Sricharan


From Ian.Campbell at citrix.com  Tue Jul 30 10:42:34 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Tue, 30 Jul 2013 15:42:34 +0100
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <alpine.DEB.2.02.1307301528540.4893@kaball.uk.xensource.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
 <51F7B4C9.2060500@gmail.com>
 <20130730125650.GD28716@e106331-lin.cambridge.arm.com>
 <20130730134427.GE28716@e106331-lin.cambridge.arm.com>
 <alpine.DEB.2.02.1307301528540.4893@kaball.uk.xensource.com>
Message-ID: <1375195354.32691.55.camel@kazak.uk.xensource.com>

On Tue, 2013-07-30 at 15:33 +0100, Stefano Stabellini wrote:
> On Tue, 30 Jul 2013, Mark Rutland wrote:
> > On Tue, Jul 30, 2013 at 01:56:50PM +0100, Mark Rutland wrote:
> > > On Tue, Jul 30, 2013 at 01:42:49PM +0100, Rob Herring wrote:
> > > > On 07/30/2013 04:49 AM, Mark Rutland wrote:
> > > > > On Mon, Jul 29, 2013 at 09:18:43PM +0100, Rob Herring wrote:
> > > > >> On 07/29/2013 05:13 AM, Mark Rutland wrote:
> > > > >>> Hi Rob,
> > > > >>>
> > > > >>> On Sun, Jul 28, 2013 at 10:56:32PM +0100, Rob Herring wrote:
> > > > >>>> From: Rob Herring <rob.herring at calxeda.com>
> > > > 
> > > > [snip]
> > > > 
> > > > >>> One of the things changed in PSCI 0.2 was the SMC calling convention,
> > > > >>> though this isn't clear in the PSCI document. The function IDs for 32bit
> > > > >>> and 64bit callers may differ, and we need to support describing an
> > > > >>> arbitrary configuration of the two (same ID for both, different across
> > > > >>> 32-bit/64-bit, only supported for 64-bit, only supported for 32-bit).
> > > > >>>
> > > > >>> I'd like to ensure the binding can deal with that from the start. We
> > > > >>> could do this by having -32 and -64 variants of each function id (e.g.
> > > > >>> cpu_off-64) , if the IDs actually differ, and use the regular combined
> > > > >>> ID if they don't.
> > > > >>
> > > > >> Uggg. I guess I should have read the SMC calling convention doc... I was
> > > > >> simply documenting what is already in the PSCI doc, but obviously that
> > > > >> is not fully flushed out.
> > > > >>
> > > > >> How about something like this (for the complicated case of both 32 and
> > > > >> 64 bit):
> > > > >>
> > > > >> 	method		= "smc", "smc64";
> > > > >> 	psci_version	= <0x84000000 0xc4000000>;
> > > > >> 	cpu_suspend	= <0x84000001 0xc4000001>;
> > > > >> 	cpu_off		= <0x84000002 0xc4000002>;
> > > > >> 	cpu_on		= <0x84000003 0xc4000003>;
> > > > >>
> > > > >> "smc" is a synonym for smc32 for compatibility. The number and order of
> > > > >> methods determines the number and order of function IDs.
> > > > > 
> > > > > While this may be compatible with the arm implementation, it won't be
> > > > > compatible with the arm64 implementation, which assumes smc64 by
> > > > > default.
> > > > > 
> > > > > As far as I am aware, the implementations currently in use (KVM and Xen)
> > > > > use the same ID for both, so I think "smc" should cover an ID valid for
> > > > > a native register width calling convention, and "smc64" and "smc32"
> > > > > describing values only valid for 64-bit wide and 32-bit wide calling
> > > > > conventions respectively.
> > > > 
> > > > The problem is that does not work for a 32-bit kernel on 64-bit h/w as
> > > > native from the dts perspective is smc64. Just like the cpu bindings,
> > > > the binding cannot change based on 32 or 64 bit OS. I don't think we
> > > > really have to deal with that here. We can simply say "smc" is only for
> > > > "arm,psci" and deprecated for "arm,psci-0.2".
> > > 
> > > Agreed. I'd be happy with only having "smc32" and "smc64" for
> > > "arm,psci-0.2".
> 
> I would be happy with that too (Xen only uses HVC as "method").

Presumably we have the same issues with hvc vs hvc32 vs hvc64 though?

And does smcX imply hvcX or does that also need to be documented here?

> 
> > Actually, from some quick discussion with Marc and Dave, I think we can
> > handle this better, in a way that leaves this backwards compatible.
> > 
> > Rather than relying on the method string to tell us the calling
> > convention, I think we should rely on the function ID, as I proposed
> > earlier. The existing function ids provided in the "arm,psci" binding
> > are implicitly relying on the PSCI implementation to detect the register
> > width and act accordingly. This is trivially true on 32bit hardware, KVM
> > (where the same ID is used for 32-bit and 64-bit guests), and while I'm
> > not entirely sure about Xen I believe it's true there. We can make this
> > explicit as we extend the binding.
> > 
> > Having a -64 and -32 variant of each ID (while not pretty) allows us to
> > add additional IDs for functions that might only have a 32-bit or 64-bit
> > interface implemented, in addition to functions with common IDs:
> > 
> > psci {
> > 	compatible = "$VENDOR,psci-0.2", "arm,psci-0.2", "arm,psci";
> > 	cpu_off = <12345678>;
> > 	cpu_on = <01234567>;
> > 	system_reset-32 = <02222222>;
> > 	system_reset-64 = <12222222>;
> > 	affinity_info-64 = <15555555>;
> > };
> > 
> > This means that hypervisors could update their PSCI implementation while
> > keeping their DTS compatible with existing kernels.
> 
> Are you proposing of getting rid of "method" completely and therefore
> have 4 possible function IDs for each function:
> 
> system_reset-32-HVC
> system_reset-64-SMC
> system_reset-32-HVC
> system_reset-64-SMC
> 
> or are you proposing of choosing just the register width via function
> IDs?
> 
> Honestly I think it would be cleaner to introduce a new field called
> "width" can that be 32 or 64 and represent the register width, rather
> than having an explosion of function IDs.




From linux at arm.linux.org.uk  Tue Jul 30 10:42:24 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 30 Jul 2013 15:42:24 +0100
Subject: [PATCH] arm: update advice on kernel and FDT load address.
In-Reply-To: <1375194651.32691.52.camel@kazak.uk.xensource.com>
References: <1375102578-5869-1-git-send-email-ian.campbell@citrix.com>
 <20130729135000.GK32383@mudshark.cambridge.arm.com>
 <1375106635.12741.8.camel@kazak.uk.xensource.com>
 <alpine.LFD.2.03.1307292234040.15022@syhkavp.arg>
 <1375192570.32691.27.camel@kazak.uk.xensource.com>
 <20130730140451.GQ24642@n2100.arm.linux.org.uk>
 <1375194651.32691.52.camel@kazak.uk.xensource.com>
Message-ID: <20130730144223.GR24642@n2100.arm.linux.org.uk>

On Tue, Jul 30, 2013 at 03:30:51PM +0100, Ian Campbell wrote:
> On Tue, 2013-07-30 at 15:04 +0100, Russell King - ARM Linux wrote:
> > On Tue, Jul 30, 2013 at 02:56:10PM +0100, Ian Campbell wrote:
> > > Actually I've just noticed that the existing text in
> > > Documentation/arm/Booting only talks about zImage and 32KiB, so perhaps
> > > not worrying about non-zImage is acceptable?
> > 
> > Straight binary kernels have tighter requirements, because they're _not_
> > entirely position independent.  Firstly, with dynamic physical offset,
> > they calculate that based on their position in physical space when
> > they're first called.
> > 
> > So, with a PAGE_OFFSET of 0xc0000000 and a link address of 0xc0008000,
> > a binary kernel image better be placed at 0xXXXX8000, and it _will_
> > assume that RAM starts 32KiB below itself.  And yes, the 32KiB offset
> > applies as the kernel uses TEXTADDR-16KiB to store the initial page
> > tables.
> 
> OK, so in the non-zImage case 32KiB is a Requirement and not just a
> recommendation. I'll update things to that affect.

Not quite a requirement.  The basic requirements for plain images are:

	kernel_offset = TEXT_OFFSET - PAGE_OFFSET
	assert(kernel_offset >= 32KiB)

	physical_memory = kernel_load_address - kernel_offset
	assert(IS_ALIGNED(physical_memory, 2MiB))

	for each memory node(node) {
		assert(physical_memory <= node->start_address);
	}

In other words, you can't link a kernel for 0xc0008000, and then load
it at (eg) 0xX000c000 or 0xX0004000 and expect it to work.


From jason at lakedaemon.net  Tue Jul 30 10:42:48 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 30 Jul 2013 10:42:48 -0400
Subject: [RFC PATCH 0/2] impedance-matcher generic improvements
In-Reply-To: <51F7C1A2.5010208@gmail.com>
References: <51F2A014.7000209@gmail.com>
 <cover.1375131816.git.jason@lakedaemon.net>
 <51F76FE3.1080302@gmail.com>
 <20130730131725.GC5882@titan.lakedaemon.net>
 <51F7C1A2.5010208@gmail.com>
Message-ID: <20130730144248.GF5882@titan.lakedaemon.net>

On Tue, Jul 30, 2013 at 03:37:38PM +0200, Daniel Mack wrote:
> Hi Jason,
> 
> On 30.07.2013 15:17, Jason Cooper wrote:
> > On Tue, Jul 30, 2013 at 09:48:51AM +0200, Daniel Mack wrote:
> >> On 29.07.2013 23:23, Jason Cooper wrote:
> >>> Basic idea is to replace a device's stock kernel with this impedance-matcher.
> >>> Load the kernel and/or the devicetree blob to desired addresses.  Add
> >>> 'loadaddrs=0xXXXXXXXX,0xYYYYYYYY' to the kernel's command line.  Or, if you are
> >>> appending, 'loadaddrs=appended,0xYYYYYYYY'.  First address is the location of
> >>> the kernel, second is the location of the dtb.
> >>
> >> Nice to see that idea implemented! For me though, changing any of the
> >> U-Boot variables is out of the question, and I need the matcher just the
> >> way I implemented it, including the LED blink pattern to let the user
> >> know if things go wrong.
> > 
> > Understandable.  After thinking about it a bit, I think I'm going to
> > rework this patch to allow appending both kernels and dtbs (as you had),
> > and abstract out the led blink so that your code would become a compile
> > time option.
> 
> And how would you match machids and system_rev values to the dtb files?

I'm thinking board-specific match functions.  For your use case, you
would match machid/system_rev to a compatible string.  Then, generic
code would scan the appended dtbs for a matching string.

> This is how I identify my boards at least. But as Stephen Warren said in
> the thread that started this discussion, there might be totally
> different ways of detection. For instance, other boards could read GPIO
> lines, or even have a pseudo driver that initializes the I2C controller
> in order to talk to an EEPROM or such. Reading from an ADC is another
> option.

As long as it resolves to a compatible string.

> And the more I think about it, I believe Nicolas was right in saying
> that such a thing does not need to be very generic (as much as I like
> generic solutions in principle).
> 
> If at all, I think we should start thinking of that code base as
> something like a framework, consisting of a merely empty main() function
> body, a lds linker script and some objcopy magic in the Makefile. And
> then have a menuconfig which allows to select one out of many hardware
> types, which then uses its specific way of board detection, LED
> signaling and so on. The two lines of vectoring to the actual kernel can
> be generic then. But again, I really don't know if it's worth the hassle.
> 
> > hrmmm, I don't like forking on general principle.  Let me do the above
> > rework and see if that works for you, while adding the capabilities I
> > need.
> > 
> > When I'm done, you should just be able to do:
> > 
> >   $ make APPEND_KERNEL=input/zImage APPEND_DTBS=input/*.dtb uImage
> 
> Out of curiosity, I'd like to see how you dynamically create the symbol
> definitions for the binary blobs :)

Me too.  ;-)

> > In the meantime, would you mind adding a license to your code?  If you
> > have no preference, I like GPLv2-only, but it's your code, so whatever
> > you like.
> 
> Done, GPLv2 it is.

Thanks!

thx,

Jason.


From maxime.ripard at free-electrons.com  Tue Jul 30 10:44:18 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:44:18 +0200
Subject: [PATCH 0/4] Add support for the Allwinner A31 clocks
Message-ID: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>

Hi everyone,

The Allwinner A31 SoC has a quite different clock tree and structure that the
other Allwinner SoCs that we already merged, so it requires more work than what
we had for the other SoCs until now.

It's also an opportunity to do some minor cleanup/refactoring to land the new
code properly.

This patch set is based on the "ARM: sunxi: Add support for the Allwinner A31
SoC" serie I sent previously.

Thanks!
Maxime

Maxime Ripard (4):
  clk: sunxi: Rename the structure to prepare the addition of sun6i
  clk: sunxi: Allow to specify the divider width from the dividers data
  clk: sunxi: Add A31 clocks support
  ARM: sun6i: Enable clock support in the DTSI

 arch/arm/boot/dts/sun6i-a31.dtsi | 137 +++++++++++++++++++--
 drivers/clk/sunxi/clk-sunxi.c    | 252 ++++++++++++++++++++++++++++++++-------
 2 files changed, 335 insertions(+), 54 deletions(-)

-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 10:44:20 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:44:20 +0200
Subject: [PATCH 2/4] clk: sunxi: Allow to specify the divider width from the
 dividers data
In-Reply-To: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375195462-19566-3-git-send-email-maxime.ripard@free-electrons.com>

The divider width used to be hardcoded. Some A31 dividers are no longer
with the hardcoded width, so we need to make it specific to each divider
and set it in the dividers data.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 3c91888..6e9cbc9 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -277,26 +277,28 @@ static void __init sunxi_mux_clk_setup(struct device_node *node,
  * sunxi_divider_clk_setup() - Setup function for simple divider clocks
  */
 
-#define SUNXI_DIVISOR_WIDTH	2
-
 struct div_data {
-	u8 shift;
-	u8 pow;
+	u8	shift;
+	u8	pow;
+	u8	width;
 };
 
 static const __initconst struct div_data sun4i_axi_data = {
-	.shift = 0,
-	.pow = 0,
+	.shift	= 0,
+	.pow	= 0,
+	.width	= 2,
 };
 
 static const __initconst struct div_data sun4i_ahb_data = {
-	.shift = 4,
-	.pow = 1,
+	.shift	= 4,
+	.pow	= 1,
+	.width	= 2,
 };
 
 static const __initconst struct div_data sun4i_apb0_data = {
-	.shift = 8,
-	.pow = 1,
+	.shift	= 8,
+	.pow	= 1,
+	.width	= 2,
 };
 
 static void __init sunxi_divider_clk_setup(struct device_node *node,
@@ -312,7 +314,7 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
 	clk_parent = of_clk_get_parent_name(node, 0);
 
 	clk = clk_register_divider(NULL, clk_name, clk_parent, 0,
-				   reg, data->shift, SUNXI_DIVISOR_WIDTH,
+				   reg, data->shift, data->width,
 				   data->pow ? CLK_DIVIDER_POWER_OF_TWO : 0,
 				   &clk_lock);
 	if (clk) {
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 10:44:22 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:44:22 +0200
Subject: [PATCH 4/4] ARM: sun6i: Enable clock support in the DTSI
In-Reply-To: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375195462-19566-5-git-send-email-maxime.ripard@free-electrons.com>

Now that the clock driver has support for the A31 clocks, we can add
them to the DTSI and start using them in the relevant hardware blocks.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 137 ++++++++++++++++++++++++++++++++++++---
 1 file changed, 127 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 0d13dc6..c6a3a91 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -51,13 +51,130 @@
 
 	clocks {
 		#address-cells = <1>;
-		#size-cells = <0>;
+		#size-cells = <1>;
+		ranges;
 
-		osc: oscillator {
+		osc24M: hosc {
 			#clock-cells = <0>;
 			compatible = "fixed-clock";
 			clock-frequency = <24000000>;
 		};
+
+		osc32k: losc {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <32768>;
+		};
+
+		pll1: pll1 at 01c20000 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun6i-pll1-clk";
+			reg = <0x01c20000 0x4>;
+			clocks = <&osc24M>;
+		};
+
+		/*
+		 * This is a dummy clock, to be used as placeholder on
+		 * other mux clocks when a specific parent clock is not
+		 * yet implemented. It should be dropped when the driver
+		 * is complete.
+		 */
+		pll6: pll6 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <0>;
+		};
+
+		cpu: cpu at 01c20050 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-cpu-clk";
+			reg = <0x01c20050 0x4>;
+			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
+		};
+
+		axi: axi at 01c20050 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-axi-clk";
+			reg = <0x01c20050 0x4>;
+			clocks = <&cpu>;
+		};
+
+		ahb1_mux: ahb1_mux at 01c20054 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun6i-ahb1-mux-clk";
+			reg = <0x01c20054 0x4>;
+			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
+		};
+
+		ahb1: ahb1 at 01c20054 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-ahb-clk";
+			reg = <0x01c20054 0x4>;
+			clocks = <&ahb1_mux>;
+		};
+
+		ahb1_gates: ahb1_gates at 01c20060 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun6i-a31-ahb1-gates-clk";
+			reg = <0x01c20060 0x8>;
+			clocks = <&ahb1>;
+			clock-output-names = "ahb1_mipidsi", "ahb1_ss",
+					"ahb1_dma", "ahb1_mmc0", "ahb1_mmc1",
+					"ahb1_mmc2", "ahb1_mmc3", "ahb1_nand1",
+					"ahb1_nand0", "ahb1_sdram",
+					"ahb1_gmac", "ahb1_ts", "ahb1_hstimer",
+					"ahb1_spi0", "ahb1_spi1", "ahb1_spi2",
+					"ahb1_spi3", "ahb1_otg", "ahb1_ehci0",
+					"ahb1_ehci1", "ahb1_ohci0",
+					"ahb1_ohci1", "ahb1_ohci2", "ahb1_ve",
+					"ahb1_lcd0", "ahb1_lcd1", "ahb1_csi",
+					"ahb1_hdmi", "ahb1_de0", "ahb1_de1",
+					"ahb1_fe0", "ahb1_fe1", "ahb1_mp",
+					"ahb1_gpu", "ahb1_deu0", "ahb1_deu1",
+					"ahb1_drc0", "ahb1_drc1";
+		};
+
+		apb1: apb1 at 01c20054 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-apb0-clk";
+			reg = <0x01c20054 0x4>;
+			clocks = <&ahb1>;
+		};
+
+		apb1_gates: apb1_gates at 01c20060 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun6i-a31-apb1-gates-clk";
+			reg = <0x01c20068 0x4>;
+			clocks = <&apb1>;
+			clock-output-names = "apb1_codec", "apb1_digital_mic",
+					"apb1_pio", "apb1_daudio0",
+					"apb1_daudio1";
+		};
+
+		apb2_mux: apb2_mux at 01c20058 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-apb1-mux-clk";
+			reg = <0x01c20058 0x4>;
+			clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
+		};
+
+		apb2: apb2 at 01c20058 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun6i-apb2-div-clk";
+			reg = <0x01c20058 0x4>;
+			clocks = <&apb2_mux>;
+		};
+
+		apb2_gates: apb2_gates at 01c2006c {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun6i-a31-apb2-gates-clk";
+			reg = <0x01c2006c 0x8>;
+			clocks = <&apb2>;
+			clock-output-names = "apb2_i2c0", "apb2_i2c1",
+					"apb2_i2c2", "apb2_i2c3", "apb2_uart0",
+					"apb2_uart1", "apb2_uart2", "apb2_uart3",
+					"apb2_uart4", "apb2_uart5";
+		};
 	};
 
 	soc at 01c20000 {
@@ -69,7 +186,7 @@
 			compatible = "allwinner,sun6i-a31-pinctrl";
 			reg = <0x01c20800 0x400>;
 			interrupts = <0 11 1>, <0 15 1>, <0 16 1>, <0 17 1>;
-			clocks = <&osc>;
+			clocks = <&apb1_gates 5>;
 			gpio-controller;
 			interrupt-controller;
 			#address-cells = <1>;
@@ -92,7 +209,7 @@
 				     <0 20 1>,
 				     <0 21 1>,
 				     <0 22 1>;
-			clocks = <&osc>;
+			clocks = <&osc24M>;
 		};
 
 		wdt1: watchdog at 01c20ca0 {
@@ -106,7 +223,7 @@
 			interrupts = <0 0 1>;
 			reg-shift = <2>;
 			reg-io-width = <4>;
-			clocks = <&osc>;
+			clocks = <&apb2_gates 16>;
 			status = "disabled";
 		};
 
@@ -116,7 +233,7 @@
 			interrupts = <0 1 1>;
 			reg-shift = <2>;
 			reg-io-width = <4>;
-			clocks = <&osc>;
+			clocks = <&apb2_gates 17>;
 			status = "disabled";
 		};
 
@@ -126,7 +243,7 @@
 			interrupts = <0 2 1>;
 			reg-shift = <2>;
 			reg-io-width = <4>;
-			clocks = <&osc>;
+			clocks = <&apb2_gates 18>;
 			status = "disabled";
 		};
 
@@ -136,7 +253,7 @@
 			interrupts = <0 3 1>;
 			reg-shift = <2>;
 			reg-io-width = <4>;
-			clocks = <&osc>;
+			clocks = <&apb2_gates 19>;
 			status = "disabled";
 		};
 
@@ -146,7 +263,7 @@
 			interrupts = <0 4 1>;
 			reg-shift = <2>;
 			reg-io-width = <4>;
-			clocks = <&osc>;
+			clocks = <&apb2_gates 20>;
 			status = "disabled";
 		};
 
@@ -156,7 +273,7 @@
 			interrupts = <0 5 1>;
 			reg-shift = <2>;
 			reg-io-width = <4>;
-			clocks = <&osc>;
+			clocks = <&apb2_gates 21>;
 			status = "disabled";
 		};
 
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 10:44:21 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:44:21 +0200
Subject: [PATCH 3/4] clk: sunxi: Add A31 clocks support
In-Reply-To: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375195462-19566-4-git-send-email-maxime.ripard@free-electrons.com>

The A31 has a mostly different clock set compared to the other older
SoCs currently supported in the Allwinner clock driver.

Add support for the basic useful clocks. The other ones will come in
eventually.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 120 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 120 insertions(+)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 6e9cbc9..8cd69e6 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -124,7 +124,67 @@ static void sun4i_get_pll1_factors(u32 *freq, u32 parent_rate,
 	*n = div / 4;
 }
 
+/**
+ * sun6i_get_pll1_factors() - calculates n, k and m factors for PLL1
+ * PLL1 rate is calculated as follows
+ * rate = parent_rate * (n + 1) * (k + 1) / (m + 1);
+ * parent_rate should always be 24MHz
+ */
+static void sun6i_get_pll1_factors(u32 *freq, u32 parent_rate,
+				   u8 *n, u8 *k, u8 *m, u8 *p)
+{
+	/*
+	 * We can operate only on MHz, this will make our life easier
+	 * later.
+	 */
+	u32 freq_mhz = *freq / 1000000;
+	u32 parent_freq_mhz = parent_rate / 1000000;
+
+	/* If the frequency is a multiple of 32 MHz, k is always 3 */
+	if (!(freq_mhz % 32))
+		*k = 3;
+	/* If the frequency is a multiple of 9 MHz, k is always 2 */
+	else if (!(freq_mhz % 9))
+		*k = 2;
+	/* If the frequency is a multiple of 8 MHz, k is always 1 */
+	else if (!(freq_mhz % 8))
+		*k = 1;
+	/* Otherwise, we don't use the k factor */
+	else
+		*k = 0;
 
+	/*
+	 * If the frequency is a multiple of 2 but not a multiple of
+	 * 3, m is 3. This is the first time we use 6 here, yet we
+	 * will use it on several other places.
+	 * We use this number because it's the lowest frequency we can
+	 * generate (with n = 0, k = 0, m = 3), so every other frequency
+	 * somehow relates to this frequency.
+	 */
+	if ((freq_mhz % 6) == 2 || (freq_mhz % 6) == 4)
+		*m = 2;
+	/*
+	 * If the frequency is a multiple of 6MHz, but the factor is
+	 * odd, m will be 3
+	 */
+	else if ((freq_mhz / 6) & 1)
+		*m = 3;
+	/* Otherwise, we end up with m = 1 */
+	else
+		*m = 1;
+
+	/* Calculate n thanks to the above factors we already got */
+	*n = freq_mhz * (*m + 1) / ((*k + 1) * parent_freq_mhz) - 1;
+
+	/*
+	 * If n end up being outbound, and that we can still decrease
+	 * m, do it.
+	 */
+	if ((*n + 1) > 31 && (*m + 1) > 1) {
+		*n = (*n + 1) / 2 - 1;
+		*m = (*m + 1) / 2 - 1;
+	}
+}
 
 /**
  * sun4i_get_apb1_factors() - calculates m, p factors for APB1
@@ -189,6 +249,15 @@ static struct clk_factors_config sun4i_pll1_config = {
 	.pwidth = 2,
 };
 
+static struct clk_factors_config sun6i_pll1_config = {
+	.nshift	= 8,
+	.nwidth = 5,
+	.kshift = 4,
+	.kwidth = 2,
+	.mshift = 0,
+	.mwidth = 2,
+};
+
 static struct clk_factors_config sun4i_apb1_config = {
 	.mshift = 0,
 	.mwidth = 5,
@@ -201,6 +270,11 @@ static const __initconst struct factors_data sun4i_pll1_data = {
 	.getter = sun4i_get_pll1_factors,
 };
 
+static const __initconst struct factors_data sun6i_pll1_data = {
+	.table = &sun6i_pll1_config,
+	.getter = sun6i_get_pll1_factors,
+};
+
 static const __initconst struct factors_data sun4i_apb1_data = {
 	.table = &sun4i_apb1_config,
 	.getter = sun4i_get_apb1_factors,
@@ -243,6 +317,10 @@ static const __initconst struct mux_data sun4i_cpu_mux_data = {
 	.shift = 16,
 };
 
+static const __initconst struct mux_data sun6i_ahb1_mux_data = {
+	.shift = 12,
+};
+
 static const __initconst struct mux_data sun4i_apb1_mux_data = {
 	.shift = 24,
 };
@@ -301,6 +379,12 @@ static const __initconst struct div_data sun4i_apb0_data = {
 	.width	= 2,
 };
 
+static const __initconst struct div_data sun6i_apb2_div_data = {
+	.shift	= 0,
+	.pow	= 0,
+	.width	= 4,
+};
+
 static void __init sunxi_divider_clk_setup(struct device_node *node,
 					   struct div_data *data)
 {
@@ -347,6 +431,10 @@ static const __initconst struct gates_data sun5i_a13_ahb_gates_data = {
 	.mask = {0x107067e7, 0x185111},
 };
 
+static const __initconst struct gates_data sun6i_a31_ahb1_gates_data = {
+	.mask = { 0xedfe7f62, 0x794f931 },
+};
+
 static const __initconst struct gates_data sun4i_apb0_gates_data = {
 	.mask = {0x4EF},
 };
@@ -363,6 +451,14 @@ static const __initconst struct gates_data sun5i_a13_apb1_gates_data = {
 	.mask = {0xa0007},
 };
 
+static const __initconst struct gates_data sun6i_a31_apb1_gates_data = {
+	.mask = { 0x3031 },
+};
+
+static const __initconst struct gates_data sun6i_a31_apb2_gates_data = {
+	.mask = { 0x3f000f },
+};
+
 static void __init sunxi_gates_clk_setup(struct device_node *node,
 					 struct gates_data *data)
 {
@@ -420,6 +516,10 @@ static const __initconst struct of_device_id clk_factors_match[] = {
 		.data = &sun4i_pll1_data,
 	},
 	{
+		.compatible = "allwinner,sun6i-pll1-clk",
+		.data = &sun6i_pll1_data,
+	},
+	{
 		.compatible = "allwinner,sun4i-apb1-clk",
 		.data = &sun4i_apb1_data,
 	},
@@ -440,6 +540,10 @@ static const __initconst struct of_device_id clk_div_match[] = {
 		.compatible = "allwinner,sun4i-apb0-clk",
 		.data = &sun4i_apb0_data,
 	},
+	{
+		.compatible = "allwinner,sun6i-apb2-div-clk",
+		.data = &sun6i_apb2_div_data,
+	},
 	{}
 };
 
@@ -453,6 +557,10 @@ static const __initconst struct of_device_id clk_mux_match[] = {
 		.compatible = "allwinner,sun4i-apb1-mux-clk",
 		.data = &sun4i_apb1_mux_data,
 	},
+	{
+		.compatible = "allwinner,sun6i-ahb1-mux-clk",
+		.data = &sun6i_ahb1_mux_data,
+	},
 	{}
 };
 
@@ -471,6 +579,10 @@ static const __initconst struct of_device_id clk_gates_match[] = {
 		.data = &sun5i_a13_ahb_gates_data,
 	},
 	{
+		.compatible = "allwinner,sun6i-a31-ahb1-gates-clk",
+		.data = &sun6i_a31_ahb1_gates_data,
+	},
+	{
 		.compatible = "allwinner,sun4i-apb0-gates-clk",
 		.data = &sun4i_apb0_gates_data,
 	},
@@ -486,6 +598,14 @@ static const __initconst struct of_device_id clk_gates_match[] = {
 		.compatible = "allwinner,sun5i-a13-apb1-gates-clk",
 		.data = &sun5i_a13_apb1_gates_data,
 	},
+	{
+		.compatible = "allwinner,sun6i-a31-apb1-gates-clk",
+		.data = &sun6i_a31_apb1_gates_data,
+	},
+	{
+		.compatible = "allwinner,sun6i-a31-apb2-gates-clk",
+		.data = &sun6i_a31_apb2_gates_data,
+	},
 	{}
 };
 
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 10:44:19 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:44:19 +0200
Subject: [PATCH 1/4] clk: sunxi: Rename the structure to prepare the addition
 of sun6i
In-Reply-To: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375195462-19566-2-git-send-email-maxime.ripard@free-electrons.com>

Rename all the generic-named structure to sun4i to avoid confusion when
we will introduce the sun6i (A31) clocks.

While we're at it, avoid too long lines and wrap the DT compatibles
tables.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 108 +++++++++++++++++++++++++++++-------------
 1 file changed, 75 insertions(+), 33 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index fe1528e..3c91888 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -25,12 +25,12 @@
 static DEFINE_SPINLOCK(clk_lock);
 
 /**
- * sunxi_osc_clk_setup() - Setup function for gatable oscillator
+ * sun4i_osc_clk_setup() - Setup function for gatable oscillator
  */
 
 #define SUNXI_OSC24M_GATE	0
 
-static void __init sunxi_osc_clk_setup(struct device_node *node)
+static void __init sun4i_osc_clk_setup(struct device_node *node)
 {
 	struct clk *clk;
 	struct clk_fixed_rate *fixed;
@@ -73,13 +73,13 @@ static void __init sunxi_osc_clk_setup(struct device_node *node)
 
 
 /**
- * sunxi_get_pll1_factors() - calculates n, k, m, p factors for PLL1
+ * sun4i_get_pll1_factors() - calculates n, k, m, p factors for PLL1
  * PLL1 rate is calculated as follows
  * rate = (parent_rate * n * (k + 1) >> p) / (m + 1);
  * parent_rate is always 24Mhz
  */
 
-static void sunxi_get_pll1_factors(u32 *freq, u32 parent_rate,
+static void sun4i_get_pll1_factors(u32 *freq, u32 parent_rate,
 				   u8 *n, u8 *k, u8 *m, u8 *p)
 {
 	u8 div;
@@ -127,12 +127,12 @@ static void sunxi_get_pll1_factors(u32 *freq, u32 parent_rate,
 
 
 /**
- * sunxi_get_apb1_factors() - calculates m, p factors for APB1
+ * sun4i_get_apb1_factors() - calculates m, p factors for APB1
  * APB1 rate is calculated as follows
  * rate = (parent_rate >> p) / (m + 1);
  */
 
-static void sunxi_get_apb1_factors(u32 *freq, u32 parent_rate,
+static void sun4i_get_apb1_factors(u32 *freq, u32 parent_rate,
 				   u8 *n, u8 *k, u8 *m, u8 *p)
 {
 	u8 calcm, calcp;
@@ -178,7 +178,7 @@ struct factors_data {
 	void (*getter) (u32 *rate, u32 parent_rate, u8 *n, u8 *k, u8 *m, u8 *p);
 };
 
-static struct clk_factors_config pll1_config = {
+static struct clk_factors_config sun4i_pll1_config = {
 	.nshift = 8,
 	.nwidth = 5,
 	.kshift = 4,
@@ -189,21 +189,21 @@ static struct clk_factors_config pll1_config = {
 	.pwidth = 2,
 };
 
-static struct clk_factors_config apb1_config = {
+static struct clk_factors_config sun4i_apb1_config = {
 	.mshift = 0,
 	.mwidth = 5,
 	.pshift = 16,
 	.pwidth = 2,
 };
 
-static const __initconst struct factors_data pll1_data = {
-	.table = &pll1_config,
-	.getter = sunxi_get_pll1_factors,
+static const __initconst struct factors_data sun4i_pll1_data = {
+	.table = &sun4i_pll1_config,
+	.getter = sun4i_get_pll1_factors,
 };
 
-static const __initconst struct factors_data apb1_data = {
-	.table = &apb1_config,
-	.getter = sunxi_get_apb1_factors,
+static const __initconst struct factors_data sun4i_apb1_data = {
+	.table = &sun4i_apb1_config,
+	.getter = sun4i_get_apb1_factors,
 };
 
 static void __init sunxi_factors_clk_setup(struct device_node *node,
@@ -239,11 +239,11 @@ struct mux_data {
 	u8 shift;
 };
 
-static const __initconst struct mux_data cpu_mux_data = {
+static const __initconst struct mux_data sun4i_cpu_mux_data = {
 	.shift = 16,
 };
 
-static const __initconst struct mux_data apb1_mux_data = {
+static const __initconst struct mux_data sun4i_apb1_mux_data = {
 	.shift = 24,
 };
 
@@ -284,17 +284,17 @@ struct div_data {
 	u8 pow;
 };
 
-static const __initconst struct div_data axi_data = {
+static const __initconst struct div_data sun4i_axi_data = {
 	.shift = 0,
 	.pow = 0,
 };
 
-static const __initconst struct div_data ahb_data = {
+static const __initconst struct div_data sun4i_ahb_data = {
 	.shift = 4,
 	.pow = 1,
 };
 
-static const __initconst struct div_data apb0_data = {
+static const __initconst struct div_data sun4i_apb0_data = {
 	.shift = 8,
 	.pow = 1,
 };
@@ -413,35 +413,77 @@ CLK_OF_DECLARE(sunxi_osc, "allwinner,sun4i-osc-clk", sunxi_osc_clk_setup);
 
 /* Matches for factors clocks */
 static const __initconst struct of_device_id clk_factors_match[] = {
-	{.compatible = "allwinner,sun4i-pll1-clk", .data = &pll1_data,},
-	{.compatible = "allwinner,sun4i-apb1-clk", .data = &apb1_data,},
+	{
+		.compatible = "allwinner,sun4i-pll1-clk",
+		.data = &sun4i_pll1_data,
+	},
+	{
+		.compatible = "allwinner,sun4i-apb1-clk",
+		.data = &sun4i_apb1_data,
+	},
 	{}
 };
 
 /* Matches for divider clocks */
 static const __initconst struct of_device_id clk_div_match[] = {
-	{.compatible = "allwinner,sun4i-axi-clk", .data = &axi_data,},
-	{.compatible = "allwinner,sun4i-ahb-clk", .data = &ahb_data,},
-	{.compatible = "allwinner,sun4i-apb0-clk", .data = &apb0_data,},
+	{
+		.compatible = "allwinner,sun4i-axi-clk",
+		.data = &sun4i_axi_data,
+	},
+	{
+		.compatible = "allwinner,sun4i-ahb-clk",
+		.data = &sun4i_ahb_data,
+	},
+	{
+		.compatible = "allwinner,sun4i-apb0-clk",
+		.data = &sun4i_apb0_data,
+	},
 	{}
 };
 
 /* Matches for mux clocks */
 static const __initconst struct of_device_id clk_mux_match[] = {
-	{.compatible = "allwinner,sun4i-cpu-clk", .data = &cpu_mux_data,},
-	{.compatible = "allwinner,sun4i-apb1-mux-clk", .data = &apb1_mux_data,},
+	{
+		.compatible = "allwinner,sun4i-cpu-clk",
+		.data = &sun4i_cpu_mux_data,
+	},
+	{
+		.compatible = "allwinner,sun4i-apb1-mux-clk",
+		.data = &sun4i_apb1_mux_data,
+	},
 	{}
 };
 
 /* Matches for gate clocks */
 static const __initconst struct of_device_id clk_gates_match[] = {
-	{.compatible = "allwinner,sun4i-axi-gates-clk", .data = &sun4i_axi_gates_data,},
-	{.compatible = "allwinner,sun4i-ahb-gates-clk", .data = &sun4i_ahb_gates_data,},
-	{.compatible = "allwinner,sun5i-a13-ahb-gates-clk", .data = &sun5i_a13_ahb_gates_data,},
-	{.compatible = "allwinner,sun4i-apb0-gates-clk", .data = &sun4i_apb0_gates_data,},
-	{.compatible = "allwinner,sun5i-a13-apb0-gates-clk", .data = &sun5i_a13_apb0_gates_data,},
-	{.compatible = "allwinner,sun4i-apb1-gates-clk", .data = &sun4i_apb1_gates_data,},
-	{.compatible = "allwinner,sun5i-a13-apb1-gates-clk", .data = &sun5i_a13_apb1_gates_data,},
+	{
+		.compatible = "allwinner,sun4i-axi-gates-clk",
+		.data = &sun4i_axi_gates_data,
+	},
+	{
+		.compatible = "allwinner,sun4i-ahb-gates-clk",
+		.data = &sun4i_ahb_gates_data,
+	},
+	{
+		.compatible = "allwinner,sun5i-a13-ahb-gates-clk",
+		.data = &sun5i_a13_ahb_gates_data,
+	},
+	{
+		.compatible = "allwinner,sun4i-apb0-gates-clk",
+		.data = &sun4i_apb0_gates_data,
+	},
+	{
+		.compatible = "allwinner,sun5i-a13-apb0-gates-clk",
+		.data = &sun5i_a13_apb0_gates_data,
+	},
+	{
+		.compatible = "allwinner,sun4i-apb1-gates-clk",
+		.data = &sun4i_apb1_gates_data,
+	},
+	{
+		.compatible = "allwinner,sun5i-a13-apb1-gates-clk",
+		.data = &sun5i_a13_apb1_gates_data,
+	},
 	{}
 };
 
-- 
1.8.3.4



From mark.rutland at arm.com  Tue Jul 30 10:55:01 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 30 Jul 2013 15:55:01 +0100
Subject: [Patch V2 4/4] ARM: dts: AM33XX: update rtc node compatibility
In-Reply-To: <51F749B0.7020802@ti.com>
References: <1372841225-18813-1-git-send-email-gururaja.hebbar@ti.com>
 <1372841225-18813-5-git-send-email-gururaja.hebbar@ti.com>
 <51F749B0.7020802@ti.com>
Message-ID: <20130730145501.GA29859@e106331-lin.cambridge.arm.com>

On Tue, Jul 30, 2013 at 06:05:52AM +0100, Gururaja Hebbar wrote:
> Hi,
> 
> On 7/3/2013 2:17 PM, Hebbar Gururaja wrote:
> > Since AM33xx  RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
> >
> > Update the rtc compatible property to "ti,am3352-rtc" to enable handling
> > of this feature inside rtc-omap driver.
> 
> The other 2 rtc driver related patches have been pulled up. If you have 
> no comments, can you please pull this up.
> 
> Regards
> Gururaja
> 
> >
> > Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
> > ---
> > :100644 100644 77aa1b0... dde180a... M	arch/arm/boot/dts/am33xx.dtsi
> >   arch/arm/boot/dts/am33xx.dtsi |    2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > index 77aa1b0..dde180a 100644
> > --- a/arch/arm/boot/dts/am33xx.dtsi
> > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > @@ -297,7 +297,7 @@
> >   		};
> >
> >   		rtc at 44e3e000 {
> > -			compatible = "ti,da830-rtc";
> > +			compatible = "ti,am3352-rtc";

Given that this is backwards compatible with the old binding, it would
be nicer to have this as:

	compatible = "ti,am3352-rtc", "ti,da830-rtc";

We must get into the habit of changing dts files in a
backwards-compatible fashion.

Thanks,
Mark.


From thomas.petazzoni at free-electrons.com  Tue Jul 30 10:59:02 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 30 Jul 2013 16:59:02 +0200
Subject: [PATCH] ARM: mvebu: use correct #interrupt-cells instead of
 #interrupts-cells
Message-ID: <1375196342-30286-1-git-send-email-thomas.petazzoni@free-electrons.com>

The Device Tree information for the GPIO banks of the Armada 370 and
Armada XP SOCs was incorrectly using #interrupts-cells instead of
controller when using GPIO interrupts, since the GPIO bank DT node
wasn't recognized as a valid interrupt controller by the OF code.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
Note: until now, this wasn't causing any problem since no board was
using Device Tree based GPIO interrupts.
---
 arch/arm/boot/dts/armada-370.dtsi        | 6 +++---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi | 4 ++--
 arch/arm/boot/dts/armada-xp-mv78260.dtsi | 6 +++---
 arch/arm/boot/dts/armada-xp-mv78460.dtsi | 6 +++---
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..e8deeab 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -78,7 +78,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				interrupt-controller;
-				#interrupts-cells = <2>;
+				#interrupt-cells = <2>;
 				interrupts = <82>, <83>, <84>, <85>;
 			};
 
@@ -89,7 +89,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				interrupt-controller;
-				#interrupts-cells = <2>;
+				#interrupt-cells = <2>;
 				interrupts = <87>, <88>, <89>, <90>;
 			};
 
@@ -100,7 +100,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				interrupt-controller;
-				#interrupts-cells = <2>;
+				#interrupt-cells = <2>;
 				interrupts = <91>;
 			};
 
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f8eaa38..ab40f96 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -63,7 +63,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				interrupt-controller;
-				#interrupts-cells = <2>;
+				#interrupt-cells = <2>;
 				interrupts = <82>, <83>, <84>, <85>;
 			};
 
@@ -74,7 +74,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				interrupt-controller;
-				#interrupts-cells = <2>;
+				#interrupt-cells = <2>;
 				interrupts = <87>, <88>, <89>;
 			};
 
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2d9335d..254bd24 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -64,7 +64,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				interrupt-controller;
-				#interrupts-cells = <2>;
+				#interrupt-cells = <2>;
 				interrupts = <82>, <83>, <84>, <85>;
 			};
 
@@ -75,7 +75,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				interrupt-controller;
-				#interrupts-cells = <2>;
+				#interrupt-cells = <2>;
 				interrupts = <87>, <88>, <89>, <90>;
 			};
 
@@ -86,7 +86,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				interrupt-controller;
-				#interrupts-cells = <2>;
+				#interrupt-cells = <2>;
 				interrupts = <91>;
 			};
 
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index c7b1f4d..9bb9620 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -80,7 +80,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				interrupt-controller;
-				#interrupts-cells = <2>;
+				#interrupt-cells = <2>;
 				interrupts = <82>, <83>, <84>, <85>;
 			};
 
@@ -91,7 +91,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				interrupt-controller;
-				#interrupts-cells = <2>;
+				#interrupt-cells = <2>;
 				interrupts = <87>, <88>, <89>, <90>;
 			};
 
@@ -102,7 +102,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				interrupt-controller;
-				#interrupts-cells = <2>;
+				#interrupt-cells = <2>;
 				interrupts = <91>;
 			};
 
-- 
1.8.1.2



From maxime.ripard at free-electrons.com  Tue Jul 30 10:59:45 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:59:45 +0200
Subject: [PATCH 01/10] ARM: sunxi: Introduce Allwinner A20 support
In-Reply-To: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375196394-21138-2-git-send-email-maxime.ripard@free-electrons.com>

The Allwinner A20 is a dual-core Cortex-A7-based SoC. It is
pin-compatible with the A10, and re-uses most of the IPs found in it,
plus some additional ones like a Gigabit Ethernet controller.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/mach-sunxi/sunxi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 19bcc96..b9b2db6 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -134,6 +134,7 @@ static const char * const sunxi_board_dt_compat[] = {
 	"allwinner,sun5i-a10s",
 	"allwinner,sun5i-a13",
 	"allwinner,sun6i-a31",
+	"allwinner,sun7i-a20",
 	NULL,
 };
 
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 10:59:48 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:59:48 +0200
Subject: [PATCH 04/10] pinctrl: sunxi: Wrap long compatible declaration lines
In-Reply-To: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375196394-21138-5-git-send-email-maxime.ripard@free-electrons.com>

The compatible declaration and their associated data are exceeding the
80-characters width limit.

Split these lines to make them more readable and fit in the kernel
coding guidelines.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/pinctrl-sunxi.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
index 5985e60..246310b 100644
--- a/drivers/pinctrl/pinctrl-sunxi.c
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -628,10 +628,22 @@ static void sunxi_pinctrl_irq_handler(unsigned irq, struct irq_desc *desc)
 }
 
 static struct of_device_id sunxi_pinctrl_match[] = {
-	{ .compatible = "allwinner,sun4i-a10-pinctrl", .data = (void *)&sun4i_a10_pinctrl_data },
-	{ .compatible = "allwinner,sun5i-a10s-pinctrl", .data = (void *)&sun5i_a10s_pinctrl_data },
-	{ .compatible = "allwinner,sun5i-a13-pinctrl", .data = (void *)&sun5i_a13_pinctrl_data },
-	{ .compatible = "allwinner,sun6i-a31-pinctrl", .data = (void *)&sun6i_a31_pinctrl_data },
+	{
+		.compatible = "allwinner,sun4i-a10-pinctrl",
+		.data = (void *)&sun4i_a10_pinctrl_data,
+	},
+	{
+		.compatible = "allwinner,sun5i-a10s-pinctrl",
+		.data = (void *)&sun5i_a10s_pinctrl_data,
+	},
+	{
+		.compatible = "allwinner,sun5i-a13-pinctrl",
+		.data = (void *)&sun5i_a13_pinctrl_data,
+	},
+	{
+		.compatible = "allwinner,sun6i-a31-pinctrl",
+		.data = (void *)&sun6i_a31_pinctrl_data,
+	},
 	{}
 };
 MODULE_DEVICE_TABLE(of, sunxi_pinctrl_match);
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 10:59:44 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:59:44 +0200
Subject: [PATCH 00/10] Introduce Allwinner A20 support
Message-ID: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>

Hi Everyone,

This patchset brings in support for the Allwinner A20 SoC.

This SoC is pretty much the heir of the Allwinner A10. They both have a lot of
IP in common, the A20 is pin-compatible with the A10, the only major difference
being that the A20 has 2 Cortex-A7 instead of the single Cortex-A8 found in the
A10.

Just like the A31, the SMP support isn't there yet, nor do we have clock
support or any storage device.

We also have the same SMP bit issue that makes Linux run without the caches
enabled for the time being when CONFIG_SMP isn't set.

This serie comes on top of the serie "ARM: sunxi: Add support for the Allwinner
A31 SoC" I sent previously.

Thanks,
Maxime

Maxime Ripard (10):
  ARM: sunxi: Introduce Allwinner A20 support
  ARM: sun7i: Add Allwinner A20 DTSI
  ARM: sun7i: Add Olimex A20-Olinuxino-Micro support
  pinctrl: sunxi: Wrap long compatible declaration lines
  pinctrl: sunxi: Add Allwinner A20 pins set
  pinctrl: sunxi: Fix inconsistent indentation
  ARM: sun7i: Add the PIO controller node to the DTSI
  ARM: sun7i: DT: Add UART muxing options to the DTSI
  ARM: sun7i: a20-olinuxino: Enable UARTs muxing
  ARM: sun7i: a20-olinuxino: Enable the user LED

 arch/arm/boot/dts/Makefile                      |    3 +-
 arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts |   61 ++
 arch/arm/boot/dts/sun7i-a20.dtsi                |  204 +++++
 arch/arm/mach-sunxi/sunxi.c                     |    1 +
 drivers/pinctrl/pinctrl-sunxi-pins.h            | 1028 ++++++++++++++++++++++-
 drivers/pinctrl/pinctrl-sunxi.c                 |   24 +-
 6 files changed, 1311 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
 create mode 100644 arch/arm/boot/dts/sun7i-a20.dtsi

-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 10:59:47 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:59:47 +0200
Subject: [PATCH 03/10] ARM: sun7i: Add Olimex A20-Olinuxino-Micro support
In-Reply-To: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375196394-21138-4-git-send-email-maxime.ripard@free-electrons.com>

The Olimex A20-Olinuxino is an open-hardware board based on the
Allwinner A20 SoC, with most of the pins exported on headers, a 10/100M
ethernet port, SATA, SD and uSD slots, etc.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/Makefile                      |  3 ++-
 arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 34 +++++++++++++++++++++++++
 2 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 1482533..18a7374 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -211,7 +211,8 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
 	sun4i-a10-hackberry.dtb \
 	sun5i-a10s-olinuxino-micro.dtb \
 	sun5i-a13-olinuxino.dtb \
-	sun6i-a31-colombus.dtb
+	sun6i-a31-colombus.dtb \
+	sun7i-a20-olinuxino-micro.dtb
 dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
 	tegra20-iris-512.dtb \
 	tegra20-medcom-wide.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
new file mode 100644
index 0000000..29edf8b
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -0,0 +1,34 @@
+/*
+ * Copyright 2013 Maxime Ripard
+ *
+ * Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "sun7i-a20.dtsi"
+
+/ {
+	model = "Olimex A20-Olinuxino Micro";
+	compatible = "olimex,a20-olinuxino-micro", "allwinner,sun7i-a20";
+
+	soc at 01c20000 {
+		uart0: serial at 01c28000 {
+			status = "okay";
+		};
+
+		uart6: serial at 01c29800 {
+			status = "okay";
+		};
+
+		uart7: serial at 01c29c00 {
+			status = "okay";
+		};
+	};
+};
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 10:59:46 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:59:46 +0200
Subject: [PATCH 02/10] ARM: sun7i: Add Allwinner A20 DTSI
In-Reply-To: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375196394-21138-3-git-send-email-maxime.ripard@free-electrons.com>

The Allwinner A20 SoC is based on 2 Cortex A7, an ARM Mali GPU, and is
built to be pin-compatible with the older Allwinner A10.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 171 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 171 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun7i-a20.dtsi

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
new file mode 100644
index 0000000..1afdb4e
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -0,0 +1,171 @@
+/*
+ * Copyright 2013 Maxime Ripard
+ *
+ * Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	interrupt-parent = <&gic>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <0>;
+		};
+
+		cpu at 1 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <1>;
+		};
+	};
+
+	memory {
+		reg = <0x40000000 0x80000000>;
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		osc24M: osc24M at 01c20050 {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <24000000>;
+		};
+
+		osc32k: osc32k {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <32768>;
+		};
+	};
+
+	soc at 01c20000 {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		timer at 01c20c00 {
+			compatible = "allwinner,sun4i-timer";
+			reg = <0x01c20c00 0x90>;
+			interrupts = <0 22 1>,
+				     <0 23 1>,
+				     <0 24 1>,
+				     <0 25 1>,
+				     <0 67 1>,
+				     <0 68 1>;
+			clocks = <&osc24M>;
+		};
+
+		wdt: watchdog at 01c20c90 {
+			compatible = "allwinner,sun4i-wdt";
+			reg = <0x01c20c90 0x10>;
+		};
+
+		uart0: serial at 01c28000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28000 0x400>;
+			interrupts = <0 1 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc24M>;
+			status = "disabled";
+		};
+
+		uart1: serial at 01c28400 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28400 0x400>;
+			interrupts = <0 2 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc24M>;
+			status = "disabled";
+		};
+
+		uart2: serial at 01c28800 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28800 0x400>;
+			interrupts = <0 3 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc24M>;
+			status = "disabled";
+		};
+
+		uart3: serial at 01c28c00 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28c00 0x400>;
+			interrupts = <0 4 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc24M>;
+			status = "disabled";
+		};
+
+		uart4: serial at 01c29000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c29000 0x400>;
+			interrupts = <0 17 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc24M>;
+			status = "disabled";
+		};
+
+		uart5: serial at 01c29400 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c29400 0x400>;
+			interrupts = <0 18 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc24M>;
+			status = "disabled";
+		};
+
+		uart6: serial at 01c29800 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c29800 0x400>;
+			interrupts = <0 19 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc24M>;
+			status = "disabled";
+		};
+
+		uart7: serial at 01c29c00 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c29c00 0x400>;
+			interrupts = <0 20 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc24M>;
+			status = "disabled";
+		};
+
+		gic: interrupt-controller at 01c81000 {
+			compatible = "arm,cortex-a7-gic";
+			reg = <0x01c81000 0x1000>,
+			      <0x01c82000 0x1000>,
+			      <0x01c84000 0x2000>,
+			      <0x01c86000 0x2000>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+			interrupts = <1 9 0xf04>;
+		};
+	};
+};
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 10:59:53 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:59:53 +0200
Subject: [PATCH 09/10] ARM: sun7i: a20-olinuxino: Enable UARTs muxing
In-Reply-To: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375196394-21138-10-git-send-email-maxime.ripard@free-electrons.com>

Instead of relying on the bootloader to mux the UART pins properly, do
it on our own and register the rightful pins for the A20-olinuxino in
the DT using pinctrl.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index 29edf8b..96e8c56 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -20,14 +20,20 @@
 
 	soc at 01c20000 {
 		uart0: serial at 01c28000 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&uart0_pins_a>;
 			status = "okay";
 		};
 
 		uart6: serial at 01c29800 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&uart6_pins_a>;
 			status = "okay";
 		};
 
 		uart7: serial at 01c29c00 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&uart7_pins_a>;
 			status = "okay";
 		};
 	};
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 10:59:51 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:59:51 +0200
Subject: [PATCH 07/10] ARM: sun7i: Add the PIO controller node to the DTSI
In-Reply-To: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375196394-21138-8-git-send-email-maxime.ripard@free-electrons.com>

The PIO controller is responsible for the GPIO/muxing/external
interrupts handling. Now that we have support for the A20 pin set in the
pinctrl driver, we can start using it in the DTSI.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 1afdb4e..704fca9 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -60,6 +60,18 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 
+		pio: pinctrl at 01c20800 {
+			compatible = "allwinner,sun7i-a20-pinctrl";
+			reg = <0x01c20800 0x400>;
+			interrupts = <0 28 1>;
+			clocks = <&osc24M>;
+			gpio-controller;
+			interrupt-controller;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			#gpio-cells = <3>;
+		};
+
 		timer at 01c20c00 {
 			compatible = "allwinner,sun4i-timer";
 			reg = <0x01c20c00 0x90>;
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 10:59:52 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:59:52 +0200
Subject: [PATCH 08/10] ARM: sun7i: DT: Add UART muxing options to the DTSI
In-Reply-To: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375196394-21138-9-git-send-email-maxime.ripard@free-electrons.com>

The UARTs on the A20 can be muxed to several pins. Add a few options to
the DTSI so that we can start using them in the boards' DT.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 704fca9..9f45e8d 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -70,6 +70,27 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 			#gpio-cells = <3>;
+
+			uart0_pins_a: uart0 at 0 {
+				allwinner,pins = "PB22", "PB23";
+				allwinner,function = "uart0";
+				allwinner,drive = <0>;
+				allwinner,pull = <0>;
+			};
+
+			uart6_pins_a: uart6 at 0 {
+				allwinner,pins = "PI12", "PI13";
+				allwinner,function = "uart6";
+				allwinner,drive = <0>;
+				allwinner,pull = <0>;
+			};
+
+			uart7_pins_a: uart7 at 0 {
+				allwinner,pins = "PI20", "PI21";
+				allwinner,function = "uart7";
+				allwinner,drive = <0>;
+				allwinner,pull = <0>;
+			};
 		};
 
 		timer at 01c20c00 {
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 10:59:54 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:59:54 +0200
Subject: [PATCH 10/10] ARM: sun7i: a20-olinuxino: Enable the user LED
In-Reply-To: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375196394-21138-11-git-send-email-maxime.ripard@free-electrons.com>

The A20-olinuxino Micro has a LED connected to the PH2 pin. Use the
gpio-led driver to enable the control over this LED.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index 96e8c56..70affa7 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -19,6 +19,15 @@
 	compatible = "olimex,a20-olinuxino-micro", "allwinner,sun7i-a20";
 
 	soc at 01c20000 {
+		pinctrl at 01c20800 {
+			led_pins_olinuxino: led_pins at 0 {
+				allwinner,pins = "PH2";
+				allwinner,function = "gpio_out";
+				allwinner,drive = <1>;
+				allwinner,pull = <0>;
+			};
+		};
+
 		uart0: serial at 01c28000 {
 			pinctrl-names = "default";
 			pinctrl-0 = <&uart0_pins_a>;
@@ -37,4 +46,16 @@
 			status = "okay";
 		};
 	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&led_pins_olinuxino>;
+
+		green {
+			label = "a20s-olinuxino-micro:green:usr";
+			gpios = <&pio 7 2 0>;
+			default-state = "on";
+		};
+	};
 };
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 10:59:50 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:59:50 +0200
Subject: [PATCH 06/10] pinctrl: sunxi: Fix inconsistent indentation
In-Reply-To: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375196394-21138-7-git-send-email-maxime.ripard@free-electrons.com>

Some pin functions in the array were not indented like the other
functions in this array. Fix this.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/pinctrl-sunxi-pins.h | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-sunxi-pins.h b/drivers/pinctrl/pinctrl-sunxi-pins.h
index 3368965..2c7446a 100644
--- a/drivers/pinctrl/pinctrl-sunxi-pins.h
+++ b/drivers/pinctrl/pinctrl-sunxi-pins.h
@@ -806,7 +806,7 @@ static const struct sunxi_desc_pin sun4i_a10_pins[] = {
 		  SUNXI_FUNCTION(0x3, "pata"),		/* ATAD13 */
 		  SUNXI_FUNCTION(0x4, "keypad"),	/* IN7 */
 		  SUNXI_FUNCTION(0x5, "sim"),		/* VCCEN */
-		SUNXI_FUNCTION_IRQ(0x6, 17),		/* EINT17 */
+		  SUNXI_FUNCTION_IRQ(0x6, 17),		/* EINT17 */
 		  SUNXI_FUNCTION(0x7, "csi1")),		/* D17 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH18,
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
@@ -815,7 +815,7 @@ static const struct sunxi_desc_pin sun4i_a10_pins[] = {
 		  SUNXI_FUNCTION(0x3, "pata"),		/* ATAD14 */
 		  SUNXI_FUNCTION(0x4, "keypad"),	/* OUT0 */
 		  SUNXI_FUNCTION(0x5, "sim"),		/* SCK */
-		SUNXI_FUNCTION_IRQ(0x6, 18),		/* EINT18 */
+		  SUNXI_FUNCTION_IRQ(0x6, 18),		/* EINT18 */
 		  SUNXI_FUNCTION(0x7, "csi1")),		/* D18 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH19,
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
@@ -824,7 +824,7 @@ static const struct sunxi_desc_pin sun4i_a10_pins[] = {
 		  SUNXI_FUNCTION(0x3, "pata"),		/* ATAD15 */
 		  SUNXI_FUNCTION(0x4, "keypad"),	/* OUT1 */
 		  SUNXI_FUNCTION(0x5, "sim"),		/* SDA */
-		SUNXI_FUNCTION_IRQ(0x6, 19),		/* EINT19 */
+		  SUNXI_FUNCTION_IRQ(0x6, 19),		/* EINT19 */
 		  SUNXI_FUNCTION(0x7, "csi1")),		/* D19 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH20,
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
@@ -832,7 +832,7 @@ static const struct sunxi_desc_pin sun4i_a10_pins[] = {
 		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D20 */
 		  SUNXI_FUNCTION(0x3, "pata"),		/* ATAOE */
 		  SUNXI_FUNCTION(0x4, "can"),		/* TX */
-		SUNXI_FUNCTION_IRQ(0x6, 20),		/* EINT20 */
+		  SUNXI_FUNCTION_IRQ(0x6, 20),		/* EINT20 */
 		  SUNXI_FUNCTION(0x7, "csi1")),		/* D20 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH21,
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
@@ -840,7 +840,7 @@ static const struct sunxi_desc_pin sun4i_a10_pins[] = {
 		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D21 */
 		  SUNXI_FUNCTION(0x3, "pata"),		/* ATADREQ */
 		  SUNXI_FUNCTION(0x4, "can"),		/* RX */
-		SUNXI_FUNCTION_IRQ(0x6, 21),		/* EINT21 */
+		  SUNXI_FUNCTION_IRQ(0x6, 21),		/* EINT21 */
 		  SUNXI_FUNCTION(0x7, "csi1")),		/* D21 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH22,
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 10:59:49 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 16:59:49 +0200
Subject: [PATCH 05/10] pinctrl: sunxi: Add Allwinner A20 pins set
In-Reply-To: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375196394-21138-6-git-send-email-maxime.ripard@free-electrons.com>

The Allwinner A20 is pin-compatible with the older A10, so the two pin
set are quite similar. However, since the A20 has new features, we can't
just use the A10 pin set as is, and we need to define our own for the
A20.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/pinctrl-sunxi-pins.h | 1018 ++++++++++++++++++++++++++++++++++
 drivers/pinctrl/pinctrl-sunxi.c      |    4 +
 2 files changed, 1022 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-sunxi-pins.h b/drivers/pinctrl/pinctrl-sunxi-pins.h
index eb0273d..3368965 100644
--- a/drivers/pinctrl/pinctrl-sunxi-pins.h
+++ b/drivers/pinctrl/pinctrl-sunxi-pins.h
@@ -2820,6 +2820,1019 @@ static const struct sunxi_desc_pin sun6i_a31_pins[] = {
 		  SUNXI_FUNCTION(0x2, "nand1")),	/* CE3 */
 };
 
+static const struct sunxi_desc_pin sun7i_a20_pins[] = {
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ERXD3 */
+		  SUNXI_FUNCTION(0x3, "spi1"),		/* CS0 */
+		  SUNXI_FUNCTION(0x4, "uart2"),		/* RTS */
+		  SUNXI_FUNCTION(0x5, "gmac")),		/* GRXD3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ERXD2 */
+		  SUNXI_FUNCTION(0x3, "spi1"),		/* CLK */
+		  SUNXI_FUNCTION(0x4, "uart2"),		/* CTS */
+		  SUNXI_FUNCTION(0x5, "gmac")),		/* GRXD2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ERXD1 */
+		  SUNXI_FUNCTION(0x3, "spi1"),		/* MOSI */
+		  SUNXI_FUNCTION(0x4, "uart2"),		/* TX */
+		  SUNXI_FUNCTION(0x5, "gmac")),		/* GRXD1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ERXD0 */
+		  SUNXI_FUNCTION(0x3, "spi1"),		/* MISO */
+		  SUNXI_FUNCTION(0x4, "uart2"),		/* RX */
+		  SUNXI_FUNCTION(0x5, "gmac")),		/* GRXD0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ETXD3 */
+		  SUNXI_FUNCTION(0x3, "spi1"),		/* CS1 */
+		  SUNXI_FUNCTION(0x5, "gmac")),		/* GTXD3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ETXD2 */
+		  SUNXI_FUNCTION(0x3, "spi3"),		/* CS0 */
+		  SUNXI_FUNCTION(0x5, "gmac")),		/* GTXD2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ETXD1 */
+		  SUNXI_FUNCTION(0x3, "spi3"),		/* CLK */
+		  SUNXI_FUNCTION(0x5, "gmac")),		/* GTXD1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ETXD0 */
+		  SUNXI_FUNCTION(0x3, "spi3"),		/* MOSI */
+		  SUNXI_FUNCTION(0x5, "gmac")),		/* GTXD0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA8,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ERXCK */
+		  SUNXI_FUNCTION(0x3, "spi3"),		/* MISO */
+		  SUNXI_FUNCTION(0x5, "gmac")),		/* GRXCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA9,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ERXERR */
+		  SUNXI_FUNCTION(0x3, "spi3"),		/* CS1 */
+		  SUNXI_FUNCTION(0x5, "gmac"),		/* GNULL / ERXERR */
+		  SUNXI_FUNCTION(0x6, "i2s1")),		/* MCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA10,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ERXDV */
+		  SUNXI_FUNCTION(0x4, "uart1"),		/* TX */
+		  SUNXI_FUNCTION(0x5, "gmac")),		/* GRXCTL / ERXDV */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA11,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* EMDC */
+		  SUNXI_FUNCTION(0x4, "uart1"),		/* RX */
+		  SUNXI_FUNCTION(0x5, "gmac")),		/* EMDC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA12,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* EMDIO */
+		  SUNXI_FUNCTION(0x3, "uart6"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "uart1"),		/* RTS */
+		  SUNXI_FUNCTION(0x5, "gmac")),		/* EMDIO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA13,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ETXEN */
+		  SUNXI_FUNCTION(0x3, "uart6"),		/* RX */
+		  SUNXI_FUNCTION(0x4, "uart1"),		/* CTS */
+		  SUNXI_FUNCTION(0x5, "gmac")),		/* GTXCTL / ETXEN */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA14,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ETXCK */
+		  SUNXI_FUNCTION(0x3, "uart7"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "uart1"),		/* DTR */
+		  SUNXI_FUNCTION(0x5, "gmac"),		/* GNULL / ETXCK */
+		  SUNXI_FUNCTION(0x6, "i2s1")),		/* BCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA15,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ECRS */
+		  SUNXI_FUNCTION(0x3, "uart7"),		/* RX */
+		  SUNXI_FUNCTION(0x4, "uart1"),		/* DSR */
+		  SUNXI_FUNCTION(0x5, "gmac"),		/* GTXCK / ECRS */
+		  SUNXI_FUNCTION(0x6, "i2s1")),		/* LRCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA16,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ECOL */
+		  SUNXI_FUNCTION(0x3, "can"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "uart1"),		/* DCD */
+		  SUNXI_FUNCTION(0x5, "gmac"),		/* GCLKIN / ECOL */
+		  SUNXI_FUNCTION(0x6, "i2s1")),		/* DO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA17,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "emac"),		/* ETXERR */
+		  SUNXI_FUNCTION(0x3, "can"),		/* RX */
+		  SUNXI_FUNCTION(0x4, "uart1"),		/* RING */
+		  SUNXI_FUNCTION(0x5, "gmac"),		/* GNULL / ETXERR */
+		  SUNXI_FUNCTION(0x6, "i2s1")),		/* LRCK */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c0")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c0")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "pwm")),		/* PWM0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ir0"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "spdif")),	/* MCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ir0")),		/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0"),		/* MCLK */
+		  SUNXI_FUNCTION(0x3, "ac97")),		/* MCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0"),		/* BCLK */
+		  SUNXI_FUNCTION(0x3, "ac97")),		/* BCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0"),		/* LRCK */
+		  SUNXI_FUNCTION(0x3, "ac97")),		/* SYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB8,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0"),		/* DO0 */
+		  SUNXI_FUNCTION(0x3, "ac97")),		/* DO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB9,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0")),		/* DO1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB10,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0")),		/* DO2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB11,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0")),		/* DO3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB12,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0"),		/* DI */
+		  SUNXI_FUNCTION(0x3, "ac97"),		/* DI */
+		  SUNXI_FUNCTION(0x4, "spdif")),	/* DI */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB13,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi2"),		/* CS1 */
+		  SUNXI_FUNCTION(0x4, "spdif")),	/* DO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB14,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi2"),		/* CS0 */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* MS0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB15,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi2"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* CK0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB16,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi2"),		/* MOSI */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* DO0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB17,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi2"),		/* MISO */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* DI0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB18,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c1")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB19,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c1")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB20,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c2")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB21,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c2")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB22,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart0"),		/* TX */
+		  SUNXI_FUNCTION(0x3, "ir1")),		/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB23,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart0"),		/* RX */
+		  SUNXI_FUNCTION(0x3, "ir1")),		/* RX */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NWE */
+		  SUNXI_FUNCTION(0x3, "spi0")),		/* MOSI */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NALE */
+		  SUNXI_FUNCTION(0x3, "spi0")),		/* MISO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCLE */
+		  SUNXI_FUNCTION(0x3, "spi0")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NCE1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NCE0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NRE# */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NRB0 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* CMD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NRB1 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC8,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ0 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC9,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ1 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC10,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ2 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC11,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ3 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC12,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NDQ4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC13,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NDQ5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC14,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NDQ6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC15,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NDQ7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC16,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NWP */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC17,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NCE2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC18,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NCE3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC19,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE4 */
+		  SUNXI_FUNCTION(0x3, "spi2"),		/* CS0 */
+		  SUNXI_FUNCTION_IRQ(0x6, 12)),		/* EINT12 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC20,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE5 */
+		  SUNXI_FUNCTION(0x3, "spi2"),		/* CLK */
+		  SUNXI_FUNCTION_IRQ(0x6, 13)),		/* EINT13 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC21,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE6 */
+		  SUNXI_FUNCTION(0x3, "spi2"),		/* MOSI */
+		  SUNXI_FUNCTION_IRQ(0x6, 14)),		/* EINT14 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC22,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE7 */
+		  SUNXI_FUNCTION(0x3, "spi2"),		/* MISO */
+		  SUNXI_FUNCTION_IRQ(0x6, 15)),		/* EINT15 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC23,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x3, "spi0")),		/* CS0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC24,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NDQS */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D0 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VP0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D1 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VN0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D2 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VP1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D3 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VN1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D4 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VP2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D5 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VN2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D6 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VPC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D7 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD8,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D8 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VP3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD9,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D9 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VM3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD10,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D10 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VP0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD11,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D11 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VN0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD12,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D12 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VP1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD13,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D13 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VN1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD14,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D14 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VP2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD15,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D15 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VN2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD16,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D16 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VPC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD17,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D17 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD18,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D18 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VP3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD19,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D19 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VN3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD20,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D20 */
+		  SUNXI_FUNCTION(0x3, "csi1")),		/* MCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD21,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D21 */
+		  SUNXI_FUNCTION(0x3, "sim")),		/* VPPEN */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD22,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D22 */
+		  SUNXI_FUNCTION(0x3, "sim")),		/* VPPPP */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD23,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D23 */
+		  SUNXI_FUNCTION(0x3, "sim")),		/* DET */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD24,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "sim")),		/* VCCEN */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD25,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* DE */
+		  SUNXI_FUNCTION(0x3, "sim")),		/* RST */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD26,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* HSYNC */
+		  SUNXI_FUNCTION(0x3, "sim")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD27,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* VSYNC */
+		  SUNXI_FUNCTION(0x3, "sim")),		/* SDA */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts0"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "csi0")),		/* PCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts0"),		/* ERR */
+		  SUNXI_FUNCTION(0x3, "csi0")),		/* CK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts0"),		/* SYNC */
+		  SUNXI_FUNCTION(0x3, "csi0")),		/* HSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts0"),		/* DVLD */
+		  SUNXI_FUNCTION(0x3, "csi0")),		/* VSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts0"),		/* D0 */
+		  SUNXI_FUNCTION(0x3, "csi0")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts0"),		/* D1 */
+		  SUNXI_FUNCTION(0x3, "csi0"),		/* D1 */
+		  SUNXI_FUNCTION(0x4, "sim")),		/* VPPEN */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts0"),		/* D2 */
+		  SUNXI_FUNCTION(0x3, "csi0")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts0"),		/* D3 */
+		  SUNXI_FUNCTION(0x3, "csi0")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE8,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts0"),		/* D4 */
+		  SUNXI_FUNCTION(0x3, "csi0")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE9,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts0"),		/* D5 */
+		  SUNXI_FUNCTION(0x3, "csi0")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE10,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts0"),		/* D6 */
+		  SUNXI_FUNCTION(0x3, "csi0")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE11,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts0"),		/* D7 */
+		  SUNXI_FUNCTION(0x3, "csi0")),		/* D7 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D1 */
+		  SUNXI_FUNCTION(0x4, "jtag")),		/* MSI */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D0 */
+		  SUNXI_FUNCTION(0x4, "jtag")),		/* DI1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* CLK */
+		  SUNXI_FUNCTION(0x4, "uart0")),	/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* CMD */
+		  SUNXI_FUNCTION(0x4, "jtag")),		/* DO1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D3 */
+		  SUNXI_FUNCTION(0x4, "uart0")),	/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D2 */
+		  SUNXI_FUNCTION(0x4, "jtag")),		/* CK1 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts1"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "csi1"),		/* PCK */
+		  SUNXI_FUNCTION(0x4, "mmc1")),		/* CMD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts1"),		/* ERR */
+		  SUNXI_FUNCTION(0x3, "csi1"),		/* CK */
+		  SUNXI_FUNCTION(0x4, "mmc1")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts1"),		/* SYNC */
+		  SUNXI_FUNCTION(0x3, "csi1"),		/* HSYNC */
+		  SUNXI_FUNCTION(0x4, "mmc1")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts1"),		/* DVLD */
+		  SUNXI_FUNCTION(0x3, "csi1"),		/* VSYNC */
+		  SUNXI_FUNCTION(0x4, "mmc1")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts1"),		/* D0 */
+		  SUNXI_FUNCTION(0x3, "csi1"),		/* D0 */
+		  SUNXI_FUNCTION(0x4, "mmc1"),		/* D2 */
+		  SUNXI_FUNCTION(0x5, "csi0")),		/* D8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts1"),		/* D1 */
+		  SUNXI_FUNCTION(0x3, "csi1"),		/* D1 */
+		  SUNXI_FUNCTION(0x4, "mmc1"),		/* D3 */
+		  SUNXI_FUNCTION(0x5, "csi0")),		/* D9 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts1"),		/* D2 */
+		  SUNXI_FUNCTION(0x3, "csi1"),		/* D2 */
+		  SUNXI_FUNCTION(0x4, "uart3"),		/* TX */
+		  SUNXI_FUNCTION(0x5, "csi0")),		/* D10 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts1"),		/* D3 */
+		  SUNXI_FUNCTION(0x3, "csi1"),		/* D3 */
+		  SUNXI_FUNCTION(0x4, "uart3"),		/* RX */
+		  SUNXI_FUNCTION(0x5, "csi0")),		/* D11 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG8,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts1"),		/* D4 */
+		  SUNXI_FUNCTION(0x3, "csi1"),		/* D4 */
+		  SUNXI_FUNCTION(0x4, "uart3"),		/* RTS */
+		  SUNXI_FUNCTION(0x5, "csi0")),		/* D12 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG9,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts1"),		/* D5 */
+		  SUNXI_FUNCTION(0x3, "csi1"),		/* D5 */
+		  SUNXI_FUNCTION(0x4, "uart3"),		/* CTS */
+		  SUNXI_FUNCTION(0x5, "csi0")),		/* D13 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG10,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts1"),		/* D6 */
+		  SUNXI_FUNCTION(0x3, "csi1"),		/* D6 */
+		  SUNXI_FUNCTION(0x4, "uart4"),		/* TX */
+		  SUNXI_FUNCTION(0x5, "csi0")),		/* D14 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG11,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ts1"),		/* D7 */
+		  SUNXI_FUNCTION(0x3, "csi1"),		/* D7 */
+		  SUNXI_FUNCTION(0x4, "uart4"),		/* RX */
+		  SUNXI_FUNCTION(0x5, "csi0")),		/* D15 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D0 */
+		  SUNXI_FUNCTION(0x4, "uart3"),		/* TX */
+		  SUNXI_FUNCTION_IRQ(0x6, 0),		/* EINT0 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D1 */
+		  SUNXI_FUNCTION(0x4, "uart3"),		/* RX */
+		  SUNXI_FUNCTION_IRQ(0x6, 1),		/* EINT1 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D2 */
+		  SUNXI_FUNCTION(0x4, "uart3"),		/* RTS */
+		  SUNXI_FUNCTION_IRQ(0x6, 2),		/* EINT2 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D3 */
+		  SUNXI_FUNCTION(0x4, "uart3"),		/* CTS */
+		  SUNXI_FUNCTION_IRQ(0x6, 3),		/* EINT3 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D4 */
+		  SUNXI_FUNCTION(0x4, "uart4"),		/* TX */
+		  SUNXI_FUNCTION_IRQ(0x6, 4),		/* EINT4 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D5 */
+		  SUNXI_FUNCTION(0x4, "uart4"),		/* RX */
+		  SUNXI_FUNCTION_IRQ(0x6, 5),		/* EINT5 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D6 */
+		  SUNXI_FUNCTION(0x4, "uart5"),		/* TX */
+		  SUNXI_FUNCTION(0x5, "ms"),		/* BS */
+		  SUNXI_FUNCTION_IRQ(0x6, 6),		/* EINT6 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D7 */
+		  SUNXI_FUNCTION(0x4, "uart5"),		/* RX */
+		  SUNXI_FUNCTION(0x5, "ms"),		/* CLK */
+		  SUNXI_FUNCTION_IRQ(0x6, 7),		/* EINT7 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH8,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D8 */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ERXD3 */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* IN0 */
+		  SUNXI_FUNCTION(0x5, "ms"),		/* D0 */
+		  SUNXI_FUNCTION_IRQ(0x6, 8),		/* EINT8 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH9,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D9 */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ERXD2 */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* IN1 */
+		  SUNXI_FUNCTION(0x5, "ms"),		/* D1 */
+		  SUNXI_FUNCTION_IRQ(0x6, 9),		/* EINT9 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D9 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH10,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D10 */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ERXD1 */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* IN2 */
+		  SUNXI_FUNCTION(0x5, "ms"),		/* D2 */
+		  SUNXI_FUNCTION_IRQ(0x6, 10),		/* EINT10 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D10 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH11,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D11 */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ERXD0 */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* IN3 */
+		  SUNXI_FUNCTION(0x5, "ms"),		/* D3 */
+		  SUNXI_FUNCTION_IRQ(0x6, 11),		/* EINT11 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D11 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH12,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D12 */
+		  SUNXI_FUNCTION(0x4, "ps2"),		/* SCK1 */
+		  SUNXI_FUNCTION_IRQ(0x6, 12),		/* EINT12 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D12 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH13,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D13 */
+		  SUNXI_FUNCTION(0x4, "ps2"),		/* SDA1 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* RST */
+		  SUNXI_FUNCTION_IRQ(0x6, 13),		/* EINT13 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D13 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH14,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D14 */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ETXD3 */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* IN4 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* VPPEN */
+		  SUNXI_FUNCTION_IRQ(0x6, 14),		/* EINT14 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D14 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH15,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D15 */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ETXD3 */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* IN5 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* VPPPP */
+		  SUNXI_FUNCTION_IRQ(0x6, 15),		/* EINT15 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D15 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH16,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D16 */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ETXD2 */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* IN6 */
+		  SUNXI_FUNCTION_IRQ(0x6, 16),		/* EINT16 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D16 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH17,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D17 */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ETXD1 */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* IN7 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* VCCEN */
+		  SUNXI_FUNCTION_IRQ(0x6, 17),		/* EINT17 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D17 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH18,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D18 */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ETXD0 */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* OUT0 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* SCK */
+		  SUNXI_FUNCTION_IRQ(0x6, 18),		/* EINT18 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D18 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH19,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D19 */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ERXERR */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* OUT1 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* SDA */
+		  SUNXI_FUNCTION_IRQ(0x6, 19),		/* EINT19 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D19 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH20,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D20 */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ERXDV */
+		  SUNXI_FUNCTION(0x4, "can"),		/* TX */
+		  SUNXI_FUNCTION_IRQ(0x6, 20),		/* EINT20 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D20 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH21,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D21 */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* EMDC */
+		  SUNXI_FUNCTION(0x4, "can"),		/* RX */
+		  SUNXI_FUNCTION_IRQ(0x6, 21),		/* EINT21 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D21 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH22,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D22 */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* EMDIO */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* OUT2 */
+		  SUNXI_FUNCTION(0x5, "mmc1"),		/* CMD */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D22 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH23,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* D23 */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ETXEN */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* OUT3 */
+		  SUNXI_FUNCTION(0x5, "mmc1"),		/* CLK */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* D23 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH24,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ETXCK */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* OUT4 */
+		  SUNXI_FUNCTION(0x5, "mmc1"),		/* D0 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* PCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH25,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* DE */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ECRS */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* OUT5 */
+		  SUNXI_FUNCTION(0x5, "mmc1"),		/* D1 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* FIELD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH26,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* HSYNC */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ECOL */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* OUT6 */
+		  SUNXI_FUNCTION(0x5, "mmc1"),		/* D2 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* HSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH27,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd1"),		/* VSYNC */
+		  SUNXI_FUNCTION(0x3, "emac"),		/* ETXERR */
+		  SUNXI_FUNCTION(0x4, "keypad"),	/* OUT7 */
+		  SUNXI_FUNCTION(0x5, "mmc1"),		/* D3 */
+		  SUNXI_FUNCTION(0x7, "csi1")),		/* VSYNC */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x3, "i2c3")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x3, "i2c3")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x3, "i2c4")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "pwm"),		/* PWM1 */
+		  SUNXI_FUNCTION(0x3, "i2c4")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc3")),		/* CMD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc3")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc3")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc3")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI8,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc3")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI9,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc3")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI10,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS0 */
+		  SUNXI_FUNCTION(0x3, "uart5"),		/* TX */
+		  SUNXI_FUNCTION_IRQ(0x5, 22)),		/* EINT22 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI11,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi0"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "uart5"),		/* RX */
+		  SUNXI_FUNCTION_IRQ(0x5, 23)),		/* EINT23 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI12,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi0"),		/* MOSI */
+		  SUNXI_FUNCTION(0x3, "uart6"),		/* TX */
+		  SUNXI_FUNCTION_IRQ(0x5, 24)),		/* EINT24 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI13,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi0"),		/* MISO */
+		  SUNXI_FUNCTION(0x3, "uart6"),		/* RX */
+		  SUNXI_FUNCTION_IRQ(0x5, 25)),		/* EINT25 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI14,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS1 */
+		  SUNXI_FUNCTION(0x3, "ps2"),		/* SCK1 */
+		  SUNXI_FUNCTION(0x4, "timer4"),	/* TCLKIN0 */
+		  SUNXI_FUNCTION_IRQ(0x5, 26)),		/* EINT26 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI15,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS1 */
+		  SUNXI_FUNCTION(0x3, "ps2"),		/* SDA1 */
+		  SUNXI_FUNCTION(0x4, "timer5"),	/* TCLKIN1 */
+		  SUNXI_FUNCTION_IRQ(0x5, 27)),		/* EINT27 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI16,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS0 */
+		  SUNXI_FUNCTION(0x3, "uart2"),		/* RTS */
+		  SUNXI_FUNCTION_IRQ(0x5, 28)),		/* EINT28 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI17,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi1"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "uart2"),		/* CTS */
+		  SUNXI_FUNCTION_IRQ(0x5, 29)),		/* EINT29 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI18,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi1"),		/* MOSI */
+		  SUNXI_FUNCTION(0x3, "uart2"),		/* TX */
+		  SUNXI_FUNCTION_IRQ(0x5, 30)),		/* EINT30 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI19,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi1"),		/* MISO */
+		  SUNXI_FUNCTION(0x3, "uart2"),		/* RX */
+		  SUNXI_FUNCTION_IRQ(0x5, 31)),		/* EINT31 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI20,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ps2"),		/* SCK0 */
+		  SUNXI_FUNCTION(0x3, "uart7"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "hdmi")),		/* HSCL */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PI21,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "ps2"),		/* SDA0 */
+		  SUNXI_FUNCTION(0x3, "uart7"),		/* RX */
+		  SUNXI_FUNCTION(0x4, "hdmi")),		/* HSDA */
+};
+
 static const struct sunxi_pinctrl_desc sun4i_a10_pinctrl_data = {
 	.pins = sun4i_a10_pins,
 	.npins = ARRAY_SIZE(sun4i_a10_pins),
@@ -2840,4 +3853,9 @@ static const struct sunxi_pinctrl_desc sun6i_a31_pinctrl_data = {
 	.npins = ARRAY_SIZE(sun6i_a31_pins),
 };
 
+static const struct sunxi_pinctrl_desc sun7i_a20_pinctrl_data = {
+	.pins = sun7i_a20_pins,
+	.npins = ARRAY_SIZE(sun7i_a20_pins),
+};
+
 #endif /* __PINCTRL_SUNXI_PINS_H */
diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
index 246310b..fc058b6 100644
--- a/drivers/pinctrl/pinctrl-sunxi.c
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -644,6 +644,10 @@ static struct of_device_id sunxi_pinctrl_match[] = {
 		.compatible = "allwinner,sun6i-a31-pinctrl",
 		.data = (void *)&sun6i_a31_pinctrl_data,
 	},
+	{
+		.compatible = "allwinner,sun7i-a20-pinctrl",
+		.data = (void *)&sun7i_a20_pinctrl_data,
+	},
 	{}
 };
 MODULE_DEVICE_TABLE(of, sunxi_pinctrl_match);
-- 
1.8.3.4



From nm at ti.com  Tue Jul 30 11:04:30 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 10:04:30 -0500
Subject: [PATCHv4 01/33] CLK: clkdev: add support for looking up clocks
 from DT
In-Reply-To: <1374564028-11352-2-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-2-git-send-email-t-kristo@ti.com>
Message-ID: <51F7D5FE.7030003@ti.com>

On 07/23/2013 02:19 AM, Tero Kristo wrote:
> clk_get_sys / clk_get can now find clocks from device-tree. If a DT clock
> is found, an entry is added to the clk_lookup list also for subsequent
> searches.
>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> ---
>   drivers/clk/clkdev.c |   32 ++++++++++++++++++++++++++++++++
>   1 file changed, 32 insertions(+)
>
> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
> index 442a313..e39f082 100644
> --- a/drivers/clk/clkdev.c
> +++ b/drivers/clk/clkdev.c
> @@ -93,6 +93,18 @@ struct clk *of_clk_get_by_name(struct device_node *np, const char *name)
>   EXPORT_SYMBOL(of_clk_get_by_name);
>   #endif
>
> +/**
> + * clkdev_add_nolock - add lookup entry for a clock
> + * @cl: pointer to new clock lookup entry
> + *
> + * Non-locking version, used internally by clk_find() to add DT based
> + * clock lookup entries.
> + */
> +static void clkdev_add_nolock(struct clk_lookup *cl)
> +{
> +	list_add_tail(&cl->node, &clocks);
> +}
> +
>   /*
>    * Find the correct struct clk for the device and connection ID.
>    * We do slightly fuzzy matching here:
> @@ -106,6 +118,9 @@ static struct clk_lookup *clk_find(const char *dev_id, const char *con_id)
>   {
>   	struct clk_lookup *p, *cl = NULL;
>   	int match, best_found = 0, best_possible = 0;
> +	struct device_node *node;
> +	struct clk *clk;
> +	struct of_phandle_args clkspec;
>
>   	if (dev_id)
>   		best_possible += 2;
> @@ -133,6 +148,23 @@ static struct clk_lookup *clk_find(const char *dev_id, const char *con_id)
>   				break;
>   		}
>   	}
> +
> +	if (cl)
> +		return cl;
> +
> +	/* If clock was not found, attempt to look-up from DT */
> +	node = of_find_node_by_name(NULL, con_id);
> +
> +	clkspec.np = node;
> +
> +	clk = of_clk_get_from_provider(&clkspec);
> +
> +	if (!IS_ERR(clk)) {
> +		/* We found a clock, add node to clkdev */
> +		cl = clkdev_alloc(clk, con_id, dev_id);

clkdev_alloc may return NULL depending on vclkdev_alloc in which case 
clkdev_add_nolock will crash trying to dereference it.

> +		clkdev_add_nolock(cl);
> +	}
> +
>   	return cl;
>   }
>
>


-- 
Regards,
Nishanth Menon


From will.deacon at arm.com  Tue Jul 30 11:04:32 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 30 Jul 2013 16:04:32 +0100
Subject: [PATCH v2] ARM: v6: prevent gcc 4.5 from reordering extended
 CP15 reads above is_smp() test
In-Reply-To: <alpine.DEB.2.02.1307301125420.4505@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307230705000.27017@utopia.booyaka.com>
 <51EE474D.5070804@ti.com>
 <20130724135617.GI11072@mudshark.cambridge.arm.com>
 <51EFE1DD.8070801@ti.com>
 <20130724142059.GJ11072@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307270405470.4546@utopia.booyaka.com>
 <20130727122221.GB6618@mudshark.cambridge.arm.com>
 <alpine.DEB.2.02.1307280538460.8385@utopia.booyaka.com>
 <alpine.DEB.2.02.1307282012280.23852@utopia.booyaka.com>
 <alpine.DEB.2.02.1307301125420.4505@utopia.booyaka.com>
Message-ID: <20130730150432.GR11527@mudshark.cambridge.arm.com>

On Tue, Jul 30, 2013 at 12:32:06PM +0100, Paul Walmsley wrote:
> 
> Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
> don't flush icache in switch_mm with hardware broadcasting") breaks
> the boot on OMAP2430SDP with omap2plus_defconfig.  Tracked to an
> undefined instruction abort from the CP15 read in
> cache_ops_need_broadcast().  It turns out that gcc 4.5 reorders the
> extended CP15 read above the is_smp() test.  This breaks ARM1136 r0
> cores, since they don't support several CP15 registers that later ARM
> cores do.  ARM1136JF-S TRM section 3.2.1 "Register allocation" has the
> details.
> 
> So mark the extended CP15 read as clobbering memory, which prevents
> the compiler from reordering it before the is_smp() test.  Russell
> states that the code generated from this approach is preferable to
> marking the inline asm as volatile.  Remove the existing condition
> code clobber as it's obsolete, per Nico's post:
> 
>     http://www.spinics.net/lists/arm-kernel/msg261208.html
> 
> This patch is a collaboration with Will Deacon and Russell King.
> 
> Signed-off-by: Paul Walmsley <paul at pwsan.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> Cc: Nicolas Pitre <nicolas.pitre at linaro.org>
> Cc: Tony Lindgren <tony at atomide.com>
> ---

Acked-by: Will Deacon <will.deacon at arm.com>

Will


From ijc at hellion.org.uk  Tue Jul 30 11:09:13 2013
From: ijc at hellion.org.uk (Ian Campbell)
Date: Tue, 30 Jul 2013 16:09:13 +0100
Subject: [linux-sunxi] [PATCH 04/10] pinctrl: sunxi: Wrap long
 compatible declaration lines
In-Reply-To: <1375196394-21138-5-git-send-email-maxime.ripard@free-electrons.com>
References: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375196394-21138-5-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375196953.32691.61.camel@kazak.uk.xensource.com>

On Tue, 2013-07-30 at 16:59 +0200, Maxime Ripard wrote:
> The compatible declaration and their associated data are exceeding the
> 80-characters width limit.
> 
> Split these lines to make them more readable and fit in the kernel
> coding guidelines.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> ---
>  drivers/pinctrl/pinctrl-sunxi.c | 20 ++++++++++++++++----
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
> index 5985e60..246310b 100644
> --- a/drivers/pinctrl/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/pinctrl-sunxi.c
> @@ -628,10 +628,22 @@ static void sunxi_pinctrl_irq_handler(unsigned irq, struct irq_desc *desc)
>  }
>  
>  static struct of_device_id sunxi_pinctrl_match[] = {
> -	{ .compatible = "allwinner,sun4i-a10-pinctrl", .data = (void *)&sun4i_a10_pinctrl_data },
> -	{ .compatible = "allwinner,sun5i-a10s-pinctrl", .data = (void *)&sun5i_a10s_pinctrl_data },
> -	{ .compatible = "allwinner,sun5i-a13-pinctrl", .data = (void *)&sun5i_a13_pinctrl_data },
> -	{ .compatible = "allwinner,sun6i-a31-pinctrl", .data = (void *)&sun6i_a31_pinctrl_data },
> +	{
> +		.compatible = "allwinner,sun4i-a10-pinctrl",
> +		.data = (void *)&sun4i_a10_pinctrl_data,
> +	},

I'm not sure this is actually an improvement, the original reads quite
naturally even if it is a little long. What about a #define such that
you can write:
         COMPAT("allwinner,sun4i-a10-pinctrl", sun4i_a10_pinctrl_data),
and thereby stay within 80-chars?

If you wanted to go overboard you could code the macro such that:
        SUNXI_COMPAT(sun4i,a10),
expanded to what you want, that's pretty obfuscated though.

Ian.



From nm at ti.com  Tue Jul 30 11:21:49 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 10:21:49 -0500
Subject: [PATCHv4 02/33] clk: omap: introduce clock driver
In-Reply-To: <1374564028-11352-3-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-3-git-send-email-t-kristo@ti.com>
Message-ID: <51F7DA0D.7060709@ti.com>

On 07/23/2013 02:19 AM, Tero Kristo wrote:
> Parses OMAP clock data from DT and registers those clocks with the clock
> framework.  dt_omap_clk_init must be called early during boot for timer
> initialization so it is exported and called from the existing clock code
> instead of probing like a real driver. Based on initial work done by
> Mike Turquette.
>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> Cc: Mike Turquette <mturquette at linaro.org>
> ---
>   drivers/clk/Makefile      |    1 +
>   drivers/clk/omap/Makefile |    1 +
>   drivers/clk/omap/clk.c    |   39 +++++++++++++++++++++++++++++++++++++++

Minor suggestion - should we just start drivers/clk/ti/ instead of clk/omap?

AM335x/DRA7 are not "strictly OMAP".. might also allow for some reuse 
for other TI platforms..

>   include/linux/clk/omap.h  |   24 ++++++++++++++++++++++++
>   4 files changed, 65 insertions(+)
>   create mode 100644 drivers/clk/omap/Makefile
>   create mode 100644 drivers/clk/omap/clk.c
>   create mode 100644 include/linux/clk/omap.h
>
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 4038c2b..d3c3733 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -32,6 +32,7 @@ obj-$(CONFIG_ARCH_VT8500)	+= clk-vt8500.o
>   obj-$(CONFIG_ARCH_ZYNQ)		+= zynq/
>   obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
>   obj-$(CONFIG_PLAT_SAMSUNG)	+= samsung/
> +obj-$(CONFIG_ARCH_OMAP)		+= omap/
>
>   obj-$(CONFIG_X86)		+= x86/
>
> diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
> new file mode 100644
> index 0000000..8195931
> --- /dev/null
> +++ b/drivers/clk/omap/Makefile
> @@ -0,0 +1 @@
> +obj-y					+= clk.o
> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
> new file mode 100644
> index 0000000..4bf1929
> --- /dev/null
> +++ b/drivers/clk/omap/clk.c
> @@ -0,0 +1,39 @@
> +/*
> + * OMAP PRCM clock driver

maybe then prcm-clk.c ?

> + *
> + * Copyright (C) 2013 Texas Instruments, Inc.
> + *     Tero Kristo <t-kristo at ti.com>
> + *     Mike Turquette <mturquette at linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/clk/omap.h>
> +#include <linux/kernel.h>
> +#include <linux/of_device.h>
> +
> +/* FIXME - should the OMAP PRCM clock driver match generic types? */

should it? :)

> +static const struct of_device_id clk_match[] = {
> +	{.compatible = "fixed-clock", .data = of_fixed_clk_setup, },
drivers/clk/clk-fixed-rate.c seems to already do this with 
CLK_OF_DECLARE, or am I mistaken? and so on?
> +	{.compatible = "mux-clock", .data = of_mux_clk_setup, },
> +	{.compatible = "fixed-factor-clock",
> +		.data = of_fixed_factor_clk_setup, },
> +	{.compatible = "divider-clock", .data = of_divider_clk_setup, },
> +	{.compatible = "gate-clock", .data = of_gate_clk_setup, },
> +	{},
> +};
> +
> +/* FIXME - need to initialize early; skip real driver registration & probe */
> +int __init dt_omap_clk_init(void)

Might be good to have kernel doc to explain the init requirement as 
documented in commit message.

> +{
> +	of_clk_init(clk_match);

just doing of_clk_init(NULL); should do the job, no? that could even be 
a static inline OR introduced in board_generic without additional headers?

> +	return 0;
> +}
> diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
> new file mode 100644
> index 0000000..647f02f
> --- /dev/null
> +++ b/include/linux/clk/omap.h
> @@ -0,0 +1,24 @@
> +/*
> + * Copyright (C) 2013 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.

would you like to match licensing to that of the C file?

> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + */
> +
> +#ifndef __LINUX_CLK_OMAP_H_
> +#define __LINUX_CLK_OMAP_H_
> +
> +int __init dt_omap_clk_init(void);
> +
> +#endif
>


-- 
Regards,
Nishanth Menon


From mark.rutland at arm.com  Tue Jul 30 11:28:24 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 30 Jul 2013 16:28:24 +0100
Subject: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link'
 property
In-Reply-To: <20130730111604.76fd5b6e@skate>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20130723112259.GE4833@e106331-lin.cambridge.arm.com>
 <20130730111604.76fd5b6e@skate>
Message-ID: <20130730152824.GB29859@e106331-lin.cambridge.arm.com>

Hi Thomas,

On Tue, Jul 30, 2013 at 10:16:04AM +0100, Thomas Petazzoni wrote:
> Dear Mark Rutland,
> 
> On Tue, 23 Jul 2013 12:22:59 +0100, Mark Rutland wrote:
> 
> > > +Some Ethernet MACs have a "fixed link", and are not connected to a
> > > +normal MDIO-managed PHY device. For those situations, a Device Tree
> > > +binding allows to describe a "fixed link".
> > 
> > Are partictular MACs fixed link, or can some either be either fixed link
> > or wired to an MDIO-managed PHY? i.e. can we assume a given MAC is
> > fixed-link from its compatible string?
> 
> No, you can't. The case that I have is that the mvneta Ethernet MAC
> (of Marvell 370/XP SOCs) is sometimes used with a MDIO-managed PHY, and
> sometimes used with a switch that isn't manageable at all and should be
> considered as a fixed link.
> 
> So no, the compatible string of the Ethernet MAC cannot be used to
> determine whether we're wired fixed link or to a classical MDIO-managed
> PHY.

Ok. Thanks for the info.

> 
> > > +Such a fixed link situation is described within an Ethernet device
> > > +Device Tree node using a 'fixed-link' property, composed of 5
> > > +elements:
> > 
> > I'm not sure grouping these values together is the best way of handling
> > this. It's rather opaque, and inflexible for future extension.
> 
> That's the DT binding that has been used by PowerPC platforms since
> several years, and I've simply re-used it. See 'git grep fixed-link
> arch/powerpc/boot/dts'.
> 
> I have nothing against creating another DT binding, but for a start, I
> thought using existing bindings would be the best idea.

Sorry, I was not aware that was the case. I agree that reusing the
existing binding is the right place to start.

> 
> > > + 1. A fake PHY ID, which must be unique accross all fixed-link PHYs in
> > > +    the system.
> > 
> > Is there any reason this couldn't be allocated dynamically within the
> > kernel as needed? I don't see why an arbitrary unique value should be a
> > dt binding requirement; it seems like a leak of Linux implementation
> > details.
> 
> As I pointed out in my reply to Grant, this value is used both as the
> PHY address on the fake fixed MDIO bus, and as the PHY identifier as
> reported by MII registers PHYS_ID1 and PHYS_ID2. If we can get assigned
> a proper PHY identifier that is used statically by the driver (it
> doesn't have to be different per fixed PHY instance), then we can
> allocate the PHY address dynamically. It requires a little bit of API
> changes but that's certainly doable. See my reply to Grant for a
> proposal about this.

Ok. I must admit to not knowing enough about ethernet hardware to fully
understand the implications here for the MII registers, but otherwise
your proposal makes sense.

> 
> > > + 2. The duplex (1 for full-duplex, 0 for half-duplex)
> > 
> > Will this change for a given MAC?
> > 
> > Could we not have a boolean property for each of these, and require one
> > to be present?
> > 
> > Possibly fixed-link-full-duplex / fix-link-half-duplex?
> > 
> > > + 3. The speed (10, 100, 1000)
> > 
> > fixed-link-speed?
> > 
> > > + 4. The pause setting (1 for enabled, 0 for disabled)
> > > + 5. The asym pause setting (1 for enabled, 0 for disabled)
> > 
> > Boolean properties for both of these?
> 
> As Florian already answered, he already proposed something like this in
> the past, and it was rejected because a fixed PHY is not a piece of
> hardware and should therefore not be represented in the Device Tree.
> However, the fact that the MAC is not connected to a MDIO-manageable
> PHY but to some fixed-link thing is a property of the MAC hardware
> layout, and can therefore be expressed as a property of the MAC
> hardware.

I think it would certainly make sense to describe this as a property of
the MAC.

Thanks,
Mark.

> 
> See the thread that starts at
> http://article.gmane.org/gmane.linux.network/275771, and specifically
> Grant answers to Florian suggestions of having DT nodes to represent
> fixed PHY: http://article.gmane.org/gmane.linux.network/276208. Grant's
> answer was:
> 
> """
> I think this discussion is going in the wrong direction. The concept
> of a dummy phy is really a Linux kernel internal detail. Creating some
> kind of dummy MDIO bus node does not describe the hardware. There is
> already support in the kernel for Ethernet MACs connected directly to
> a switch or other device. It is far better to describe how the MAC
> needs to be configured than to invent a non-existent phy. Search for
> "fixed-link" in the kernel tree to see how it is used.
> """
> 
> Best regards,
> 
> Thomas
> -- 
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> 


From mark.rutland at arm.com  Tue Jul 30 11:31:21 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 30 Jul 2013 16:31:21 +0100
Subject: [RFC PATCH 1/3] of: provide a binding for the 'fixed-link'
 property
In-Reply-To: <20130730110705.3262bc3d@skate>
References: <1373902450-11857-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373902450-11857-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <CACxGe6td6uM0v5w92xPVCaVH4tP4AJ-h4SnN-mFoz5gSSosnQw@mail.gmail.com>
 <20130730110705.3262bc3d@skate>
Message-ID: <20130730153121.GC29859@e106331-lin.cambridge.arm.com>

On Tue, Jul 30, 2013 at 10:07:05AM +0100, Thomas Petazzoni wrote:
> Dear Grant Likely,
> 
> On Tue, 23 Jul 2013 12:39:52 +0100, Grant Likely wrote:
> 
> > > +Such a fixed link situation is described within an Ethernet device
> > > +Device Tree node using a 'fixed-link' property, composed of 5
> > > +elements:
> > > +
> > > + 1. A fake PHY ID, which must be unique accross all fixed-link PHYs in
> > > +    the system.
> > 
> > That's just loony!  :)  Regardless of existing code doing this, it is
> > absolutely ridiculous to have it in the driver. The kernel should
> > handle generating a phy id transparently. I'd rather mark this field
> > as reserved in the binding and change the code to not care about it
> > anymore.
> 
> In fact, this value is used for two things:
> 
>  * As the PHY address on the fake "fixed" MDIO bus.
> 
>  * As the PHY identifier, as reported by the MII registers PHYS_ID1
>    (0x2) and PHYS_ID2 (0x3).
> 
> I think this doesn't make sense, because the two things are completely
> unrelated. Ideally, we'd like the PHY identifier for fixed PHYs to be
> something fixed, identical for all fixed PHYs. The problem is finding
> an OUI and device number that is available for that, but maybe we can
> ask the OpenMoko people to allocate one (see
> http://wiki.openmoko.org/wiki/OUI).
> 
> Then, the PHY address could be generated dynamically. This would
> require:
> 
>  * Adding a fixed_phy_create() function that internally uses
>    fixed_phy_add(), but before that creates an unique PHY address for
>    this newly created PHY. Those unique addresses will be generated by
>    incrementing a global number of fixed PHYs, up to PHY_MAX_ADDR,
>    which is the maximum number of fixed PHYs that can anyway be
>    registered on the fixed MDIO bus.
> 
>    fixed_phy_create() would return this PHY address (positive) on
>    success, or a negative error code on failure.
> 
>  * Change of_phy_register_fixed_link() to call fixed_phy_create()
>    instead of fixed_phy_add() and make it return the PHY address
>    allocated by fixed_phy_create().
> 
>  * Add a of_phy_connect_fixed_link_direct() that is similar to
>    of_phy_connect_fixed_link() but takes an additional PHY address as
>    argument and uses that to generate the 'bus_id' used to find the
>    phy_device.
> 
> Grant, Mark, Florian, do you have other proposals?

The above sounds good to me.

Thanks,
Mark.


From balbi at ti.com  Tue Jul 30 11:32:58 2013
From: balbi at ti.com (Felipe Balbi)
Date: Tue, 30 Jul 2013 18:32:58 +0300
Subject: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for
 DRA7xx based SoCs'
In-Reply-To: <51F7CF6F.6050702@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-2-git-send-email-rnayak@ti.com>
 <20130730131009.GA28162@radagast> <51F7CB2F.6070705@ti.com>
 <20130730142353.GL28162@radagast> <51F7CF6F.6050702@ti.com>
Message-ID: <20130730153138.GA5978@radagast>

Hi,

On Tue, Jul 30, 2013 at 08:06:31PM +0530, Sricharan R wrote:
> On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote:
> >> On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
> >>>> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
> >>>>  # define soc_is_omap543x()		is_omap543x()
> >>>>  #endif
> >>>>  
> >>>> +# if defined(CONFIG_SOC_DRA7XX)
> >>>> +# undef soc_is_dra7xx
> >>>> +# undef soc_is_dra75x
> >>>> +# define soc_is_dra7xx()		is_dra7xx()
> >>>> +# define soc_is_dra75x()		is_dra75x()
> >>> since this platform is DT-only, couldn't we just believe DT-data to be
> >>> correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
> >>>
> >>> I patched this for OMAP5 (compile-tested only, no boards available) and
> >>> came out with the patch below (still needs to be split):
> >>>
> >>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
> >>> index 08b7267..b3136e5 100644
> >>> --- a/arch/arm/boot/dts/omap5-uevm.dts
> >>> +++ b/arch/arm/boot/dts/omap5-uevm.dts
> >>> @@ -13,7 +13,7 @@
> >>>  
> >>>  / {
> >>>  	model = "TI OMAP5 uEVM board";
> >>> -	compatible = "ti,omap5-uevm", "ti,omap5";
> >>> +	compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5";
> >>>  
> >>  ok, nice and simpler way.
> >>  But would this make different revisions, to appear the same ?
> > well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up,
> > it should be treated as such, then you can pass a different string to
> > that new board's compatible attribute.
> >
>  Yes for OMAP5. I was thinking in general about this approach.
>  For example, for OMAP4 we have same board and
>  different revisions can be socketed there.
> 
>  For OMAP5, this is good.

do we really production socketed boards? Well, at least Blaze has such
thing. But do we have too many differences that need to be trated at
arch/arm or should/could those be handled by reading IP's revision
register (e.g. usb host erratas)

-- 
balbi
-------------- 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/20130730/448d7591/attachment.sig>

From konrad.wilk at oracle.com  Tue Jul 30 11:40:35 2013
From: konrad.wilk at oracle.com (Konrad Rzeszutek Wilk)
Date: Tue, 30 Jul 2013 11:40:35 -0400
Subject: [PATCH] do not allow XEN_TMEM on ARM64
In-Reply-To: <alpine.DEB.2.02.1307231745520.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307231745520.4893@kaball.uk.xensource.com>
Message-ID: <20130730154035.GA9245@phenom.dumpdata.com>

On Tue, Jul 23, 2013 at 05:46:58PM +0100, Stefano Stabellini wrote:
> tmem is not supported on arm or arm64 yet.

So .. I lost track of the conversation about this. We chatted
about this on the hyepervisor side and then there is also
this patch.


What did we decide?

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 9e02d60..a18f350 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -145,7 +146,7 @@ config SWIOTLB_XEN
>  
>  config XEN_TMEM
>  	tristate
> -	depends on !ARM
> +	depends on !ARM && !ARM64
>  	default m if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks


From thomas.petazzoni at free-electrons.com  Tue Jul 30 11:44:51 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 30 Jul 2013 17:44:51 +0200
Subject: [PATCH 2/2] ARM: mvebu: add gpio-keys and input event support in
 defconfig
In-Reply-To: <1375199091-31215-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1375199091-31215-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1375199091-31215-3-git-send-email-thomas.petazzoni@free-electrons.com>

Some Armada 370/XP boards have GPIO buttons, so it makes sense to
enable gpio-keys and the input event interface in mvebu_defconfig.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/configs/mvebu_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 731814e..594d706 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -39,6 +39,8 @@ CONFIG_MVNETA=y
 CONFIG_MARVELL_PHY=y
 CONFIG_MWIFIEX=y
 CONFIG_MWIFIEX_SDIO=y
+CONFIG_INPUT_EVDEV=y
+CONFIG_KEYBOARD_GPIO=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_I2C=y
-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Tue Jul 30 11:44:49 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 30 Jul 2013 17:44:49 +0200
Subject: [PATCH 0/2] Add support for a new Armada XP based board
Message-ID: <1375199091-31215-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello,

The following two patches add support for a new Armada-XP board. The
first patch adds the DTS file, the second patch updates the
mvebu_defconfig file with some more interesting options.

Thanks,

Thomas

Thomas Petazzoni (2):
  ARM: mvebu: add support for the AXP WiFi AP board
  ARM: mvebu: add gpio-keys and input event support in defconfig

 arch/arm/boot/dts/Makefile                |   1 +
 arch/arm/boot/dts/armada-xp-axpwifiap.dts | 164 ++++++++++++++++++++++++++++++
 arch/arm/configs/mvebu_defconfig          |   2 +
 3 files changed, 167 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-xp-axpwifiap.dts

-- 
1.8.1.2



From thomas.petazzoni at free-electrons.com  Tue Jul 30 11:44:50 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 30 Jul 2013 17:44:50 +0200
Subject: [PATCH 1/2] ARM: mvebu: add support for the AXP WiFi AP board
In-Reply-To: <1375199091-31215-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1375199091-31215-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1375199091-31215-2-git-send-email-thomas.petazzoni@free-electrons.com>

The AXP WiFi AP board is a Marvell platform based on the Armada XP
MV78230 SoC. It has two mini-PCIe connectors, one USB 3.0 port powered
by a USB 3.0 controller on PCIe, two Ethernet ports, 1 GB of RAM, 1 GB
of NAND, 16 MB of SPI flash, one SATA port and one button, two UARTs

Successfully tested: USB 3.0 port, the mini-PCIe connectors, SPI
flash, Ethernet ports, SATA port, button, UART.

Untested: NAND flash, due to lack of mainline support for the Armada
370/XP NAND controller for now.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm/boot/dts/Makefile                |   1 +
 arch/arm/boot/dts/armada-xp-axpwifiap.dts | 164 ++++++++++++++++++++++++++++++
 2 files changed, 165 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-xp-axpwifiap.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..66bb64f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -101,6 +101,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
 dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
 	armada-370-mirabox.dtb \
 	armada-370-rd.dtb \
+	armada-xp-axpwifiap.dtb \
 	armada-xp-db.dtb \
 	armada-xp-gp.dtb \
 	armada-xp-openblocks-ax3-4.dtb
diff --git a/arch/arm/boot/dts/armada-xp-axpwifiap.dts b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
new file mode 100644
index 0000000..2a542bd
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
@@ -0,0 +1,164 @@
+/*
+ * Device Tree file for Marvell RD-AXPWiFiAP.
+ *
+ * Note: this board is shipped with a new generation boot loader that
+ * remaps internal registers at 0xf1000000. Therefore, if earlyprintk
+ * is used, the CONFIG_DEBUG_MVEBU_UART_ALTERNATE option should be
+ * used.
+ *
+ * Copyright (C) 2013 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "armada-xp-mv78230.dtsi"
+
+/ {
+	model = "Marvell RD-AXPWiFiAP";
+	compatible = "marvell,rd-axpwifiap", "marvell,armadaxp-mv78230", "marvell,armadaxp", "marvell,armada-370-xp";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x00000000 0x00000000 0x40000000>; /* 1GB */
+	};
+
+	soc {
+		ranges = <0          0 0xf1000000 0x100000  /* Internal registers 1MiB */
+			  0xe0000000 0 0xe0000000 0x8100000 /* PCIe */>;
+
+		internal-regs {
+			pinctrl {
+				pinctrl-0 = <&pmx_phy_int>;
+				pinctrl-names = "default";
+
+				pmx_ge0: pmx-ge0 {
+					marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3",
+						       "mpp4", "mpp5", "mpp6", "mpp7",
+						       "mpp8", "mpp9", "mpp10", "mpp11";
+					marvell,function = "ge0";
+				};
+
+				pmx_ge1: pmx-ge1 {
+					marvell,pins = "mpp12", "mpp13", "mpp14", "mpp15",
+						       "mpp16", "mpp17", "mpp18", "mpp19",
+						       "mpp20", "mpp21", "mpp22", "mpp23";
+					marvell,function = "ge1";
+				};
+
+				pmx_keys: pmx-keys {
+					marvell,pins = "mpp33";
+					marvell,function = "gpio";
+				};
+
+				pmx_spi: pmx-spi {
+					marvell,pins = "mpp36", "mpp37", "mpp38", "mpp39";
+					marvell,function = "spi";
+				};
+
+				pmx_phy_int: pmx-phy-int {
+					marvell,pins = "mpp32";
+					marvell,function = "gpio";
+				};
+			};
+
+			serial at 12000 {
+				clock-frequency = <250000000>;
+				status = "okay";
+			};
+
+			serial at 12100 {
+				clock-frequency = <250000000>;
+				status = "okay";
+			};
+
+			sata at a0000 {
+				nr-ports = <1>;
+				status = "okay";
+			};
+
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
+
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
+			};
+
+			ethernet at 70000 {
+				pinctrl-0 = <&pmx_ge0>;
+				pinctrl-names = "default";
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii-id";
+			};
+			ethernet at 74000 {
+				pinctrl-0 = <&pmx_ge1>;
+				pinctrl-names = "default";
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii-id";
+			};
+
+			spi0: spi at 10600 {
+				status = "okay";
+				pinctrl-0 = <&pmx_spi>;
+				pinctrl-names = "default";
+
+				spi-flash at 0 {
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "n25q128a13";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <108000000>;
+				};
+			};
+
+			pcie-controller {
+				status = "okay";
+
+				/* First mini-PCIe port */
+				pcie at 1,0 {
+					/* Port 0, Lane 0 */
+					status = "okay";
+				};
+
+				/* Second mini-PCIe port */
+				pcie at 2,0 {
+					/* Port 0, Lane 1 */
+					status = "okay";
+				};
+
+				/* Renesas uPD720202 USB 3.0 controller */
+				pcie at 3,0 {
+					/* Port 0, Lane 3 */
+					status = "okay";
+				};
+			};
+		};
+	};
+
+	gpio_keys {
+		compatible = "gpio-keys";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		pinctrl-0 = <&pmx_keys>;
+		pinctrl-names = "default";
+
+		button at 1 {
+			label = "Factory Reset Button";
+			linux,code = <141>; /* KEY_SETUP */
+			gpios = <&gpio1 1 1>;
+		};
+	};
+};
-- 
1.8.1.2



From john.stultz at linaro.org  Tue Jul 30 12:12:24 2013
From: john.stultz at linaro.org (John Stultz)
Date: Tue, 30 Jul 2013 09:12:24 -0700
Subject: [PATCH v4 07/17] clocksource: bcm2835: Switch to
 sched_clock_register()
In-Reply-To: <51F78FCB.2020004@linaro.org>
References: <1374189690-10810-1-git-send-email-sboyd@codeaurora.org>
 <1374189690-10810-8-git-send-email-sboyd@codeaurora.org>
 <51F78FCB.2020004@linaro.org>
Message-ID: <51F7E5E8.5090000@linaro.org>

On 07/30/2013 03:04 AM, Daniel Lezcano wrote:
> On 07/19/2013 01:21 AM, Stephen Boyd wrote:
>> The 32 bit sched_clock interface now supports 64 bits. Upgrade to
>> the 64 bit function to allow us to remove the 32 bit registration
>> interface.
>>
>> Cc: Stephen Warren <swarren at wwwdotorg.org>
>> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>> ---
> Hi Stephen,
>
> you sent a series with tick and clocksource changes.
>
> John is recipient of part of them. I replaced him to maintain the
> clocksource drivers.
>
> Is the series you sent for clocksource drivers supposed to be taken by
> me or by Russell ?
>
> In the future if there are no dependencies, it would be preferable to
> group the clocksource drivers changes into a series and send them to me.


I believe there are some dependencies on the generic bits.

I'm planning on queing the generic parts in one branch (to send to 
thomas), queuing the drivers/clocksource bits to send to you, but was 
waiting on an Ack from Catalin.

I got busy with some other work items, so I haven't pushed these out 
yet, but I'll review things again and push them out today.

thanks
-john





From ezequiel.garcia at free-electrons.com  Tue Jul 30 12:13:41 2013
From: ezequiel.garcia at free-electrons.com (Ezequiel Garcia)
Date: Tue, 30 Jul 2013 13:13:41 -0300
Subject: [PATCH v9 30/30] PCI: mvebu: Adapt to the new device tree layout
In-Reply-To: <1374844687-19981-31-git-send-email-ezequiel.garcia@free-electrons.com>
References: <1374844687-19981-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1374844687-19981-31-git-send-email-ezequiel.garcia@free-electrons.com>
Message-ID: <20130730161340.GA26140@localhost>

On Fri, Jul 26, 2013 at 10:18:07AM -0300, Ezequiel Garcia wrote:
> From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> 
> The new device tree layout encodes the window's target ID and attribute
> in the PCIe controller node's ranges property. This allows to parse
> such entries to obtain such information and use the recently introduced
> MBus API to create the windows, instead of using the current name based
> scheme.
> 
> Cc: devicetree at vger.kernel.org
> Acked-by: Bjorn Helgaas <bhelgaas at google.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Tested-by: Andrew Lunn <andrew at lunn.ch>
> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> ---
>  .../devicetree/bindings/pci/mvebu-pci.txt          | 145 ++++++++++++++++-----
>  1 file changed, 109 insertions(+), 36 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> index f8d4058..9556e2f 100644
> --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> @@ -1,6 +1,7 @@
>  * Marvell EBU PCIe interfaces
>  
>  Mandatory properties:
> +
>  - compatible: one of the following values:
>      marvell,armada-370-pcie
>      marvell,armada-xp-pcie
> @@ -10,11 +11,49 @@ Mandatory properties:
>  - #interrupt-cells, set to <1>
>  - bus-range: PCI bus numbers covered
>  - device_type, set to "pci"
> -- ranges: ranges for the PCI memory and I/O regions, as well as the
> -  MMIO registers to control the PCIe interfaces.
> +- ranges: ranges describing the MMIO registers to control the PCIe
> +  interfaces, and ranges describing the MBus windows needed to access
> +  the memory and I/O regions of each PCIe interface.
> +
> +The ranges describing the MMIO registers have the following layout:
> +
> +    0x82000000 0 r MBUS_ID(0xf0, 0x01) r 0 s
> +
> +where:
> +
> +  * r is a 32-bits value that gives the offset of the MMIO
> +  registers of this PCIe interface, from the base of the internal
> +  registers.
> +
> +  * s is a 32-bits value that give the size of this MMIO
> +  registers area. This range entry translates the '0x82000000 0 r' PCI
> +  address into the 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part
> +  of the internal register window (as identified by MBUS_ID(0xf0,
> +  0x01)).
> +
> +The ranges describing the MBus windows have the following layout:
> +
> +    0x8t000000 s 0     MBUS_ID(w, a) 0 1 0
> +
> +where:
> +
> +   * t is the type of the MBus window (as defined by the standard PCI DT
> +   bindings), 1 for I/O and 2 for memory.
>  
> -In addition, the Device Tree node must have sub-nodes describing each
> +   * s is the PCI slot that corresponds to this PCIe interface
> +
> +   * w is the 'target ID' value for the MBus window
> +
> +   * a the 'attribute' value for the MBus window.
> +
> +Since the location and size of the different MBus windows is not fixed in
> +hardware, and only determined in runtime, those ranges cover the full first
> +4 GB of the physical address space, and do not translate into a valid CPU
> +address.
> +
> +In addition, the device tree node must have sub-nodes describing each
>  PCIe interface, having the following mandatory properties:
> +
>  - reg: used only for interrupt mapping, so only the first four bytes
>    are used to refer to the correct bus number and device number.
>  - assigned-addresses: reference to the MMIO registers used to control
> @@ -26,7 +65,8 @@ PCIe interface, having the following mandatory properties:
>  - #address-cells, set to <3>
>  - #size-cells, set to <2>
>  - #interrupt-cells, set to <1>
> -- ranges, empty property.
> +- ranges, translating the MBus windows ranges of the parent node into
> +  standard PCI addresses.
>  - interrupt-map-mask and interrupt-map, standard PCI properties to
>    define the mapping of the PCIe interface to interrupt numbers.
>  
> @@ -47,27 +87,50 @@ pcie-controller {
>  
>  	bus-range = <0x00 0xff>;
>  
> -	ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
> -		  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
> -		  0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
> -		  0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
> -		  0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
> -		  0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
> -		  0x82000000 0 0xd0082000 0xd0082000 0 0x00002000   /* Port 3.0 registers */
> -		  0x82000000 0 0xd0084000 0xd0084000 0 0x00002000   /* Port 1.1 registers */
> -		  0x82000000 0 0xd0088000 0xd0088000 0 0x00002000   /* Port 1.2 registers */
> -		  0x82000000 0 0xd008c000 0xd008c000 0 0x00002000   /* Port 1.3 registers */
> -		  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
> -		  0x81000000 0 0	  0xe8000000 0 0x00100000>; /* downstream I/O */
> +	ranges =
> +	       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000	/* Port 0.0 registers */
> +		0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000	/* Port 2.0 registers */
> +		0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000	/* Port 0.1 registers */
> +		0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000	/* Port 0.2 registers */
> +		0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000	/* Port 0.3 registers */
> +		0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000	/* Port 1.0 registers */
> +		0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000	/* Port 3.0 registers */
> +		0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000	/* Port 1.1 registers */
> +		0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000	/* Port 1.2 registers */
> +		0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000	/* Port 1.3 registers */
> +		0x82000000 0x1 0     MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
> +		0x81000000 0x1 0     MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO  */
> +		0x82000000 0x2 0     MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
> +		0x81000000 0x2 0     MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO  */
> +		0x82000000 0x3 0     MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */
> +		0x81000000 0x3 0     MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO  */
> +		0x82000000 0x4 0     MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
> +		0x81000000 0x4 0     MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO  */
> +
> +		0x82000000 0x5 0     MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
> +		0x81000000 0x5 0     MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO  */
> +		0x82000000 0x6 0     MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */
> +		0x81000000 0x6 0     MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO  */
> +		0x82000000 0x7 0     MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */
> +		0x81000000 0x7 0     MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO  */
> +		0x82000000 0x8 0     MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */
> +		0x81000000 0x8 0     MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO  */
> +
> +		0x82000000 0x9 0     MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
> +		0x81000000 0x9 0     MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO  */
> +
> +		0x82000000 0xa 0     MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
> +		0x81000000 0xa 0     MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO  */>;
>  
>  	pcie at 1,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
> +		assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
>  		reg = <0x0800 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
> +			  0x81000000 0 0 0x81000000 0x1 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 58>;
>  		marvell,pcie-port = <0>;
> @@ -78,12 +141,13 @@ pcie-controller {
>  
>  	pcie at 2,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>;
> +		assigned-addresses = <0x82001000 0 0x44000 0 0x2000>;
>  		reg = <0x1000 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
> +			  0x81000000 0 0 0x81000000 0x2 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 59>;
>  		marvell,pcie-port = <0>;
> @@ -94,12 +158,13 @@ pcie-controller {
>  
>  	pcie at 3,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>;
> +		assigned-addresses = <0x82001800 0 0x48000 0 0x2000>;
>  		reg = <0x1800 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
> +			  0x81000000 0 0 0x81000000 0x3 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 60>;
>  		marvell,pcie-port = <0>;
> @@ -110,12 +175,13 @@ pcie-controller {
>  
>  	pcie at 4,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>;
> +		assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>;
>  		reg = <0x2000 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
> +			  0x81000000 0 0 0x81000000 0x4 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 61>;
>  		marvell,pcie-port = <0>;
> @@ -126,12 +192,13 @@ pcie-controller {
>  
>  	pcie at 5,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
> +		assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
>  		reg = <0x2800 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
> +			  0x81000000 0 0 0x81000000 0x5 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 62>;
>  		marvell,pcie-port = <1>;
> @@ -142,12 +209,13 @@ pcie-controller {
>  
>  	pcie at 6,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>;
> +		assigned-addresses = <0x82003000 0 0x84000 0 0x2000>;
>  		reg = <0x3000 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0
> +			  0x81000000 0 0 0x81000000 0x6 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 63>;
>  		marvell,pcie-port = <1>;
> @@ -158,12 +226,13 @@ pcie-controller {
>  
>  	pcie at 7,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>;
> +		assigned-addresses = <0x82003800 0 0x88000 0 0x2000>;
>  		reg = <0x3800 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0
> +			  0x81000000 0 0 0x81000000 0x7 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 64>;
>  		marvell,pcie-port = <1>;
> @@ -174,12 +243,13 @@ pcie-controller {
>  
>  	pcie at 8,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>;
> +		assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>;
>  		reg = <0x4000 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0
> +			  0x81000000 0 0 0x81000000 0x8 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 65>;
>  		marvell,pcie-port = <1>;
> @@ -187,14 +257,16 @@ pcie-controller {
>  		clocks = <&gateclk 12>;
>  		status = "disabled";
>  	};
> +
>  	pcie at 9,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>;
> +		assigned-addresses = <0x82004800 0 0x42000 0 0x2000>;
>  		reg = <0x4800 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
> +			  0x81000000 0 0 0x81000000 0x9 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 99>;
>  		marvell,pcie-port = <2>;
> @@ -205,12 +277,13 @@ pcie-controller {
>  
>  	pcie at 10,0 {
>  		device_type = "pci";
> -		assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>;
> +		assigned-addresses = <0x82005000 0 0x82000 0 0x2000>;
>  		reg = <0x5000 0 0 0 0>;
>  		#address-cells = <3>;
>  		#size-cells = <2>;
>  		#interrupt-cells = <1>;
> -		ranges;
> +		ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
> +			  0x81000000 0 0 0x81000000 0xa 0 1 0>;
>  		interrupt-map-mask = <0 0 0 0>;
>  		interrupt-map = <0 0 0 0 &mpic 103>;
>  		marvell,pcie-port = <3>;
> -- 
> 1.8.1.5
> 

Any feedback on this from the DT maintainers?

This patchset has been around for several months now and has been
extensively discussed with Jason Gunthorpe and Arnd Bergmann,
so we'd really like to have an Acked-by on the DT bindings and merge it.

Thanks!
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com


From nsekhar at ti.com  Tue Jul 30 12:21:14 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 30 Jul 2013 21:51:14 +0530
Subject: [Patch V2 4/4] ARM: dts: AM33XX: update rtc node compatibility
In-Reply-To: <20130730145501.GA29859@e106331-lin.cambridge.arm.com>
References: <1372841225-18813-1-git-send-email-gururaja.hebbar@ti.com>
 <1372841225-18813-5-git-send-email-gururaja.hebbar@ti.com>
 <51F749B0.7020802@ti.com>
 <20130730145501.GA29859@e106331-lin.cambridge.arm.com>
Message-ID: <51F7E7FA.3080702@ti.com>

On 7/30/2013 8:25 PM, Mark Rutland wrote:
> On Tue, Jul 30, 2013 at 06:05:52AM +0100, Gururaja Hebbar wrote:
>> Hi,
>>
>> On 7/3/2013 2:17 PM, Hebbar Gururaja wrote:
>>> Since AM33xx  RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
>>>
>>> Update the rtc compatible property to "ti,am3352-rtc" to enable handling
>>> of this feature inside rtc-omap driver.
>>
>> The other 2 rtc driver related patches have been pulled up. If you have 
>> no comments, can you please pull this up.
>>
>> Regards
>> Gururaja
>>
>>>
>>> Signed-off-by: Hebbar Gururaja <gururaja.hebbar at ti.com>
>>> ---
>>> :100644 100644 77aa1b0... dde180a... M	arch/arm/boot/dts/am33xx.dtsi
>>>   arch/arm/boot/dts/am33xx.dtsi |    2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>>> index 77aa1b0..dde180a 100644
>>> --- a/arch/arm/boot/dts/am33xx.dtsi
>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>>> @@ -297,7 +297,7 @@
>>>   		};
>>>
>>>   		rtc at 44e3e000 {
>>> -			compatible = "ti,da830-rtc";
>>> +			compatible = "ti,am3352-rtc";
> 
> Given that this is backwards compatible with the old binding, it would
> be nicer to have this as:
> 
> 	compatible = "ti,am3352-rtc", "ti,da830-rtc";
> 
> We must get into the habit of changing dts files in a
> backwards-compatible fashion.

Right, I suggested this when v1 was posted. It turns out the current
kernel does not handle the compatilble list correctly and the string
selected actually depends on the order in which it appears in match
table in driver instead.

I saw there were patches being discussed to fix this issue, but until
that is fixed, we cannot really use what you (and I before) suggested.

Thanks,
Sekhar


From gdjakov at mm-sol.com  Tue Jul 30 12:22:35 2013
From: gdjakov at mm-sol.com (Georgi Djakov)
Date: Tue, 30 Jul 2013 19:22:35 +0300
Subject: [PATCH] mmc: sdhci-msm: Add support for MSM chipsets
Message-ID: <1375201355-26906-1-git-send-email-gdjakov@mm-sol.com>

This platform driver adds the support of Secure Digital Host
Controller Interface compliant controller in MSM chipsets.

CC: Asutosh Das <asutoshd at codeaurora.org>
CC: Venkat Gopalakrishnan <venkatg at codeaurora.org>
CC: Sahitya Tummala <stummala at codeaurora.org>
CC: Subhash Jadavani <subhashj at codeaurora.org>
Signed-off-by: Georgi Djakov <gdjakov at mm-sol.com>
---
This is an initial version of the Qualcomm MSM SDHCI driver.
It is based on the SDHCI code from coreaurora.org with minor
modifications. The MMC standard DT bindings are used where
possible. The patch applies to v3.11-rc3.

 .../devicetree/bindings/mmc/sdhci-msm.txt          |   71 ++
 drivers/mmc/host/Kconfig                           |   13 +
 drivers/mmc/host/Makefile                          |    1 +
 drivers/mmc/host/sdhci-msm.c                       |  968 ++++++++++++++++++++
 4 files changed, 1053 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
 create mode 100644 drivers/mmc/host/sdhci-msm.c

diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
new file mode 100644
index 0000000..c7b21c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -0,0 +1,71 @@
+* Qualcomm SDHCI controller (sdhci-msm)
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-msm driver.
+
+Required properties:
+- compatible: should be "qcom,sdhci-msm"
+- reg: should contain SDHC, SD Core register map
+- reg-names: indicates various resources passed to driver (via reg proptery) by name
+	"reg-names" examples are "hc_mem" and "core_mem"
+- interrupts: should contain SDHC interrupts
+- interrupt-names: indicates interrupts passed to driver (via interrupts property) by name
+	"interrupt-names" examples are "hc_irq" and "pwr_irq"
+- <supply-name>-supply: phandle to the regulator device tree node
+	"supply-name" examples are "vdd" and "vdd-io"
+
+Optional properties:
+- qcom,bus-speed-mode - specifies supported bus speed modes by host
+	The supported bus speed modes are :
+	"HS200_1p8v" - indicates that host can support HS200 at 1.8v
+	"HS200_1p2v" - indicates that host can support HS200 at 1.2v
+	"DDR_1p8v" - indicates that host can support DDR mode at 1.8v
+	"DDR_1p2v" - indicates that host can support DDR mode at 1.2v
+
+In the following, <supply> can be vdd (flash core voltage) or vdd-io (I/O voltage).
+- qcom,<supply>-always-on - specifies whether supply should be kept "on" always.
+- qcom,<supply>-lpm-sup - specifies whether supply can be kept in low power mode (lpm).
+- qcom,<supply>-voltage-level - specifies voltage levels for supply. Should be
+specified in pairs (min, max), units uV.
+- qcom,<supply>-current-level - specifies load levels for supply in lpm or high power mode
+	(hpm). Should be specified in pairs (lpm, hpm), units uA.
+
+- gpios - specifies gpios assigned for sdhc slot.
+- qcom,gpio-names - a list of strings that map in order to the list of gpios
+
+Example:
+
+	aliases {
+		sdhc1 = &sdhc_1;
+	};
+
+	sdhc_1: qcom,sdhc at f9824900 {
+		compatible = "qcom,sdhci-msm";
+			reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
+			reg-names = "hc_mem", "core_mem";
+			interrupts = <0 123 0>, <0 138 0>;
+			interrupt-names = "hc_irq", "pwr_irq";
+
+		vdd-supply = <&pm8941_l21>;
+		vdd-io-supply = <&pm8941_l13>;
+		qcom,vdd-voltage-level = <2950000 2950000>;
+		qcom,vdd-current-level = <9000 800000>;
+
+		qcom,vdd-io-always-on;
+		qcom,vdd-io-lpm-sup;
+		qcom,vdd-io-voltage-level = <1800000 2950000>;
+		qcom,vdd-io-current-level = <6 22000>;
+
+		bus-width = <4>;
+		non-removable;
+		qcom,bus-speed-mode = "HS200_1p8v", "DDR_1p8v";
+
+		gpios = <&msmgpio 40 0>, /* CLK */
+			<&msmgpio 39 0>, /* CMD */
+			<&msmgpio 38 0>, /* DATA0 */
+			<&msmgpio 37 0>, /* DATA1 */
+			<&msmgpio 36 0>, /* DATA2 */
+			<&msmgpio 35 0>; /* DATA3 */
+		qcom,gpio-names = "CLK", "CMD", "DAT0", "DAT1", "DAT2", "DAT3";
+	};
+
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8a4c066..2b31471 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -322,6 +322,19 @@ config MMC_ATMELMCI
 
 	  If unsure, say N.
 
+config MMC_SDHCI_MSM
+	tristate "Qualcomm SDHCI Controller Support"
+	depends on ARCH_MSM
+	depends on MMC_SDHCI_PLTFM
+	help
+	  This selects the Secure Digital Host Controller Interface (SDHCI)
+	  support present in MSM SOCs from Qualcomm. The controller
+	  supports SD/MMC/SDIO devices.
+
+	  If you have a controller with this interface, say Y or M here.
+
+	  If unsure, say N.
+
 config MMC_MSM
 	tristate "Qualcomm SDCC Controller Support"
 	depends on MMC && ARCH_MSM
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index d422e21..efd6e6a 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_MMC_SDHCI_OF_ESDHC)	+= sdhci-of-esdhc.o
 obj-$(CONFIG_MMC_SDHCI_OF_HLWD)		+= sdhci-of-hlwd.o
 obj-$(CONFIG_MMC_SDHCI_BCM_KONA)	+= sdhci-bcm-kona.o
 obj-$(CONFIG_MMC_SDHCI_BCM2835)		+= sdhci-bcm2835.o
+obj-$(CONFIG_MMC_SDHCI_MSM)		+= sdhci-msm.o
 
 ifeq ($(CONFIG_CB710_DEBUG),y)
 	CFLAGS-cb710-mmc	+= -DDEBUG
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
new file mode 100644
index 0000000..3e4debb
--- /dev/null
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -0,0 +1,968 @@
+/*
+ * drivers/mmc/host/sdhci-msm.c - Qualcomm MSM SDHCI Platform
+ * driver source file
+ *
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/mmc/host.h>
+#include <linux/mmc/card.h>
+#include <linux/mmc/sdio_func.h>
+#include <linux/gfp.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/regulator/consumer.h>
+#include <linux/types.h>
+#include <linux/input.h>
+#include <linux/platform_device.h>
+
+#include "sdhci-pltfm.h"
+
+#define CORE_HC_MODE		0x78
+#define HC_MODE_EN		0x1
+
+#define CORE_POWER		0x0
+#define CORE_SW_RST		(1 << 7)
+
+#define CORE_PWRCTL_STATUS	0xDC
+#define CORE_PWRCTL_MASK	0xE0
+#define CORE_PWRCTL_CLEAR	0xE4
+#define CORE_PWRCTL_CTL		0xE8
+
+#define CORE_PWRCTL_BUS_OFF	0x01
+#define CORE_PWRCTL_BUS_ON	(1 << 1)
+#define CORE_PWRCTL_IO_LOW	(1 << 2)
+#define CORE_PWRCTL_IO_HIGH	(1 << 3)
+
+#define CORE_PWRCTL_BUS_SUCCESS	0x01
+#define CORE_PWRCTL_BUS_FAIL	(1 << 1)
+#define CORE_PWRCTL_IO_SUCCESS	(1 << 2)
+#define CORE_PWRCTL_IO_FAIL	(1 << 3)
+
+#define INT_MASK		0xF
+
+/* This structure keeps information per regulator */
+struct sdhci_msm_reg_data {
+	/* voltage regulator handle */
+	struct regulator *reg;
+	/* regulator name */
+	const char *name;
+	/* voltage level to be set */
+	u32 low_vol_level;
+	u32 high_vol_level;
+	/* Load values for low power and high power mode */
+	u32 lpm_uA;
+	u32 hpm_uA;
+
+	/* is this regulator enabled? */
+	bool is_enabled;
+	/* is this regulator needs to be always on? */
+	bool always_on;
+	/* is low power mode setting required for this regulator? */
+	bool lpm_sup;
+};
+
+/*
+ * This structure keeps information for all the
+ * regulators required for a SDCC slot.
+ */
+struct sdhci_msm_slot_reg_data {
+	/* keeps VDD/VCC regulator info */
+	struct sdhci_msm_reg_data *vdd_data;
+	/* keeps VDD IO regulator info */
+	struct sdhci_msm_reg_data *vdd_io_data;
+};
+
+struct sdhci_msm_gpio {
+	u32 no;
+	const char *name;
+	bool is_always_on;
+	bool is_enabled;
+};
+
+struct sdhci_msm_gpio_data {
+	struct sdhci_msm_gpio *gpio;
+	u8 size;
+};
+
+struct sdhci_msm_pin_data {
+	/*
+	 * = 1 if controller pins are using gpios
+	 * = 0 if controller has dedicated MSM pads
+	 */
+	u8 cfg_sts;
+	struct sdhci_msm_gpio_data *gpio_data;
+};
+
+struct sdhci_msm_pltfm_data {
+	/* Supported UHS-I Modes */
+	u32 caps;
+
+	/* More capabilities */
+	u32 caps2;
+
+	unsigned long mmc_bus_width;
+	u32 max_clk;
+	struct sdhci_msm_slot_reg_data *vreg_data;
+	bool nonremovable;
+	struct sdhci_msm_pin_data *pin_data;
+};
+
+struct sdhci_msm_host {
+	void __iomem *core_mem;	/* MSM SDCC mapped address */
+	struct clk *clk;	/* main SD/MMC bus clock */
+	struct clk *pclk;	/* SDHC peripheral bus clock */
+	struct clk *bus_clk;	/* SDHC bus voter clock */
+	struct sdhci_msm_pltfm_data *pdata;
+	struct mmc_host *mmc;
+	struct sdhci_pltfm_data sdhci_msm_pdata;
+};
+
+enum vdd_io_level {
+	/* set vdd_io_data->low_vol_level */
+	VDD_IO_LOW,
+	/* set vdd_io_data->high_vol_level */
+	VDD_IO_HIGH,
+	/*
+	 * set whatever there in voltage_level (third argument) of
+	 * sdhci_msm_set_vdd_io_vol() function.
+	 */
+	VDD_IO_SET_LEVEL,
+};
+
+static int sdhci_msm_setup_gpio(struct sdhci_msm_pltfm_data *pdata, bool enable)
+{
+	struct sdhci_msm_gpio_data *curr;
+	int i, ret = 0;
+
+	curr = pdata->pin_data->gpio_data;
+	for (i = 0; i < curr->size; i++) {
+		if (!gpio_is_valid(curr->gpio[i].no)) {
+			ret = -EINVAL;
+			pr_err("%s: Invalid gpio = %d\n",
+			       __func__, curr->gpio[i].no);
+			goto free_gpios;
+		}
+		if (enable) {
+			if (curr->gpio[i].is_always_on &&
+			    curr->gpio[i].is_enabled)
+				continue;
+			ret = gpio_request(curr->gpio[i].no,
+					   curr->gpio[i].name);
+			if (ret) {
+				pr_err("%s: gpio_request(%d, %s) failed %d\n",
+				       __func__, curr->gpio[i].no,
+				       curr->gpio[i].name, ret);
+				goto free_gpios;
+			}
+			curr->gpio[i].is_enabled = true;
+		} else {
+			if (curr->gpio[i].is_always_on)
+				continue;
+			gpio_free(curr->gpio[i].no);
+			curr->gpio[i].is_enabled = false;
+		}
+	}
+	return ret;
+
+free_gpios:
+	for (i--; i >= 0; i--) {
+		gpio_free(curr->gpio[i].no);
+		curr->gpio[i].is_enabled = false;
+	}
+	return ret;
+}
+
+static int sdhci_msm_setup_pins(struct sdhci_msm_pltfm_data *pdata, bool enable)
+{
+	int ret = 0;
+
+	if (!pdata->pin_data || pdata->pin_data->cfg_sts == enable)
+		return 0;
+
+	ret = sdhci_msm_setup_gpio(pdata, enable);
+	if (!ret)
+		pdata->pin_data->cfg_sts = enable;
+
+	return ret;
+}
+
+#define MAX_PROP_SIZE 32
+static int sdhci_msm_dt_parse_vreg_info(struct device *dev,
+					struct sdhci_msm_reg_data **vreg_data,
+					const char *vreg_name)
+{
+	int len, ret = 0;
+	const __be32 *prop;
+	char prop_name[MAX_PROP_SIZE];
+	struct sdhci_msm_reg_data *vreg;
+	struct device_node *np = dev->of_node;
+
+	snprintf(prop_name, MAX_PROP_SIZE, "%s-supply", vreg_name);
+	if (!of_parse_phandle(np, prop_name, 0)) {
+		ret = -EINVAL;
+		return ret;
+	}
+
+	vreg = devm_kzalloc(dev, sizeof(*vreg), GFP_KERNEL);
+	if (!vreg) {
+		dev_err(dev, "No memory for vreg: %s\n", vreg_name);
+		ret = -ENOMEM;
+		return ret;
+	}
+
+	vreg->name = vreg_name;
+
+	snprintf(prop_name, MAX_PROP_SIZE, "qcom,%s-always-on", vreg_name);
+	if (of_get_property(np, prop_name, NULL))
+		vreg->always_on = true;
+
+	snprintf(prop_name, MAX_PROP_SIZE, "qcom,%s-lpm-sup", vreg_name);
+	if (of_get_property(np, prop_name, NULL))
+		vreg->lpm_sup = true;
+
+	snprintf(prop_name, MAX_PROP_SIZE, "qcom,%s-voltage-level", vreg_name);
+	prop = of_get_property(np, prop_name, &len);
+	if (!prop || (len != (2 * sizeof(__be32)))) {
+		dev_warn(dev, "%s %s property\n",
+			 prop ? "invalid format" : "no", prop_name);
+	} else {
+		vreg->low_vol_level = be32_to_cpup(&prop[0]);
+		vreg->high_vol_level = be32_to_cpup(&prop[1]);
+	}
+
+	snprintf(prop_name, MAX_PROP_SIZE, "qcom,%s-current-level", vreg_name);
+	prop = of_get_property(np, prop_name, &len);
+	if (!prop || (len != (2 * sizeof(__be32)))) {
+		dev_warn(dev, "%s %s property\n",
+			 prop ? "invalid format" : "no", prop_name);
+	} else {
+		vreg->lpm_uA = be32_to_cpup(&prop[0]);
+		vreg->hpm_uA = be32_to_cpup(&prop[1]);
+	}
+
+	*vreg_data = vreg;
+	dev_dbg(dev, "%s: %s %s vol=[%d %d]uV, curr=[%d %d]uA\n",
+		vreg->name, vreg->always_on ? "always_on," : "",
+		vreg->lpm_sup ? "lpm_sup," : "", vreg->low_vol_level,
+		vreg->high_vol_level, vreg->lpm_uA, vreg->hpm_uA);
+
+	return ret;
+}
+
+#define GPIO_NAME_MAX_LEN 32
+static int sdhci_msm_dt_parse_gpio_info(struct device *dev,
+					struct sdhci_msm_pltfm_data *pdata)
+{
+	int ret = 0, cnt, i;
+	struct sdhci_msm_pin_data *pin_data;
+	struct device_node *np = dev->of_node;
+
+	pin_data = devm_kzalloc(dev, sizeof(*pin_data), GFP_KERNEL);
+	if (!pin_data) {
+		dev_err(dev, "No memory for pin_data\n");
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	cnt = of_gpio_count(np);
+	if (cnt > 0) {
+		pin_data->gpio_data = devm_kzalloc(dev,
+						   sizeof(struct
+							  sdhci_msm_gpio_data),
+						   GFP_KERNEL);
+		if (!pin_data->gpio_data) {
+			dev_err(dev, "No memory for gpio_data\n");
+			ret = -ENOMEM;
+			goto out;
+		}
+		pin_data->gpio_data->size = cnt;
+		pin_data->gpio_data->gpio = devm_kzalloc(dev, cnt *
+							 sizeof(struct
+								sdhci_msm_gpio),
+							 GFP_KERNEL);
+
+		if (!pin_data->gpio_data->gpio) {
+			dev_err(dev, "No memory for gpio\n");
+			ret = -ENOMEM;
+			goto out;
+		}
+		for (i = 0; i < cnt; i++) {
+			const char *name = NULL;
+			char result[GPIO_NAME_MAX_LEN];
+			pin_data->gpio_data->gpio[i].no = of_get_gpio(np, i);
+			of_property_read_string_index(np,
+						      "qcom,gpio-names", i,
+						      &name);
+
+			snprintf(result, GPIO_NAME_MAX_LEN, "%s-%s",
+				 dev_name(dev), name ? name : "?");
+			pin_data->gpio_data->gpio[i].name = result;
+			dev_dbg(dev, "%s: gpio[%s] = %d\n", __func__,
+				pin_data->gpio_data->gpio[i].name,
+				pin_data->gpio_data->gpio[i].no);
+			pdata->pin_data = pin_data;
+		}
+	}
+
+out:
+	if (ret)
+		dev_err(dev, "%s failed with err %d\n", __func__, ret);
+	return ret;
+}
+
+/* Parse platform data */
+static struct sdhci_msm_pltfm_data *sdhci_msm_populate_pdata(struct device *dev)
+{
+	struct sdhci_msm_pltfm_data *pdata = NULL;
+	struct device_node *np = dev->of_node;
+	u32 bus_width = 0;
+	int len, i;
+
+	pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata) {
+		dev_err(dev, "failed to allocate memory for platform data\n");
+		goto out;
+	}
+
+	of_property_read_u32(np, "bus-width", &bus_width);
+	if (bus_width == 8)
+		pdata->mmc_bus_width = MMC_CAP_8_BIT_DATA;
+	else if (bus_width == 4)
+		pdata->mmc_bus_width = MMC_CAP_4_BIT_DATA;
+	else {
+		dev_notice(dev, "invalid bus-width, default to 1-bit mode\n");
+		pdata->mmc_bus_width = 0;
+	}
+
+	pdata->vreg_data = devm_kzalloc(dev, sizeof(struct
+						    sdhci_msm_slot_reg_data),
+					GFP_KERNEL);
+	if (!pdata->vreg_data) {
+		dev_err(dev, "failed to allocate memory for vreg data\n");
+		goto out;
+	}
+
+	if (sdhci_msm_dt_parse_vreg_info(dev, &pdata->vreg_data->vdd_data,
+					 "vdd")) {
+		dev_err(dev, "failed parsing vdd data\n");
+		goto out;
+	}
+	if (sdhci_msm_dt_parse_vreg_info(dev,
+					 &pdata->vreg_data->vdd_io_data,
+					 "vdd-io")) {
+		dev_err(dev, "failed parsing vdd-io data\n");
+		goto out;
+	}
+
+	if (sdhci_msm_dt_parse_gpio_info(dev, pdata)) {
+		dev_err(dev, "failed parsing gpio data\n");
+		goto out;
+	}
+
+	of_property_read_u32(np, "max-frequency", &pdata->max_clk);
+
+	len = of_property_count_strings(np, "qcom,bus-speed-mode");
+
+	for (i = 0; i < len; i++) {
+		const char *name = NULL;
+
+		of_property_read_string_index(np,
+					      "qcom,bus-speed-mode", i, &name);
+		if (!name)
+			continue;
+
+		if (!strncmp(name, "HS200_1p8v", sizeof("HS200_1p8v")))
+			pdata->caps2 |= MMC_CAP2_HS200_1_8V_SDR;
+		else if (!strncmp(name, "HS200_1p2v", sizeof("HS200_1p2v")))
+			pdata->caps2 |= MMC_CAP2_HS200_1_2V_SDR;
+		else if (!strncmp(name, "DDR_1p8v", sizeof("DDR_1p8v")))
+			pdata->caps |= MMC_CAP_1_8V_DDR | MMC_CAP_UHS_DDR50;
+		else if (!strncmp(name, "DDR_1p2v", sizeof("DDR_1p2v")))
+			pdata->caps |= MMC_CAP_1_2V_DDR | MMC_CAP_UHS_DDR50;
+	}
+
+	if (of_get_property(np, "non-removable", NULL))
+		pdata->nonremovable = true;
+
+	return pdata;
+out:
+	return NULL;
+}
+
+/* Regulator utility functions */
+static int sdhci_msm_vreg_init_reg(struct device *dev,
+				   struct sdhci_msm_reg_data *vreg)
+{
+	int ret = 0;
+
+	/* check if regulator is already initialized? */
+	if (vreg->reg)
+		goto out;
+
+	/* Get the regulator handle */
+	vreg->reg = devm_regulator_get(dev, vreg->name);
+	if (IS_ERR(vreg->reg)) {
+		ret = PTR_ERR(vreg->reg);
+		pr_err("%s: devm_regulator_get(%s) failed. ret=%d\n",
+		       __func__, vreg->name, ret);
+		goto out;
+	}
+
+	/* sanity check */
+	if (!vreg->high_vol_level || !vreg->hpm_uA) {
+		pr_err("%s: %s invalid constraints specified\n",
+		       __func__, vreg->name);
+		ret = -EINVAL;
+	}
+
+out:
+	return ret;
+}
+
+static void sdhci_msm_vreg_deinit_reg(struct sdhci_msm_reg_data *vreg)
+{
+	if (vreg->reg)
+		devm_regulator_put(vreg->reg);
+}
+
+static int sdhci_msm_vreg_set_optimum_mode(struct sdhci_msm_reg_data
+					   *vreg, int uA_load)
+{
+	int ret = 0;
+
+	/*
+	 * regulators that do not support regulator_set_voltage also
+	 * do not support regulator_set_optimum_mode
+	 */
+	ret = regulator_set_optimum_mode(vreg->reg, uA_load);
+	if (ret < 0)
+		pr_err
+		    ("%s: regulator_set_optimum_mode(%s,uA_load=%d) fail(%d)\n",
+		     __func__, vreg->name, uA_load, ret);
+	else
+		/*
+		 * regulator_set_optimum_mode() can return non zero
+		 * value even for success case.
+		 */
+		ret = 0;
+	return ret;
+}
+
+static int sdhci_msm_vreg_set_voltage(struct sdhci_msm_reg_data *vreg,
+				      int min_uV, int max_uV)
+{
+	int ret = 0;
+
+	ret = regulator_set_voltage(vreg->reg, min_uV, max_uV);
+	if (ret) {
+		pr_err
+		    ("%s: regulator_set_voltage(%s,min_uV=%d,max_uV=%d) (%d)\n",
+		     __func__, vreg->name, min_uV, max_uV, ret);
+	}
+
+	return ret;
+}
+
+static int sdhci_msm_vreg_enable(struct sdhci_msm_reg_data *vreg)
+{
+	int ret = 0;
+
+	/* Put regulator in HPM (high power mode) */
+	ret = sdhci_msm_vreg_set_optimum_mode(vreg, vreg->hpm_uA);
+	if (ret < 0)
+		return ret;
+
+	if (!vreg->is_enabled) {
+		/* Set voltage level */
+		ret = sdhci_msm_vreg_set_voltage(vreg, vreg->high_vol_level,
+						 vreg->high_vol_level);
+		if (ret)
+			return ret;
+	}
+	ret = regulator_enable(vreg->reg);
+	if (ret) {
+		pr_err("%s: regulator_enable(%s) failed. ret=%d\n",
+		       __func__, vreg->name, ret);
+		return ret;
+	}
+	vreg->is_enabled = true;
+	return ret;
+}
+
+static int sdhci_msm_vreg_disable(struct sdhci_msm_reg_data *vreg)
+{
+	int ret = 0;
+
+	/* Never disable regulator marked as always_on */
+	if (vreg->is_enabled && !vreg->always_on) {
+		ret = regulator_disable(vreg->reg);
+		if (ret) {
+			pr_err("%s: regulator_disable(%s) failed. ret=%d\n",
+			       __func__, vreg->name, ret);
+			goto out;
+		}
+		vreg->is_enabled = false;
+
+		ret = sdhci_msm_vreg_set_optimum_mode(vreg, 0);
+		if (ret < 0)
+			goto out;
+
+		/* Set min. voltage level to 0 */
+		ret = sdhci_msm_vreg_set_voltage(vreg, 0, vreg->high_vol_level);
+		if (ret)
+			goto out;
+	} else if (vreg->is_enabled && vreg->always_on) {
+		if (vreg->lpm_sup) {
+			/* Put always_on regulator in LPM (low power mode) */
+			ret = sdhci_msm_vreg_set_optimum_mode(vreg,
+							      vreg->lpm_uA);
+			if (ret < 0)
+				goto out;
+		}
+	}
+out:
+	return ret;
+}
+
+static int sdhci_msm_setup_vreg(struct sdhci_msm_pltfm_data *pdata,
+				bool enable, bool is_init)
+{
+	int ret = 0, i;
+	struct sdhci_msm_slot_reg_data *curr_slot;
+	struct sdhci_msm_reg_data *vreg_table[2];
+
+	curr_slot = pdata->vreg_data;
+	if (!curr_slot) {
+		pr_debug
+		    ("%s: no vreg info, assuming the slot is always powered\n",
+		     __func__);
+		goto out;
+	}
+
+	vreg_table[0] = curr_slot->vdd_data;
+	vreg_table[1] = curr_slot->vdd_io_data;
+
+	for (i = 0; i < ARRAY_SIZE(vreg_table); i++) {
+		if (vreg_table[i]) {
+			if (enable)
+				ret = sdhci_msm_vreg_enable(vreg_table[i]);
+			else
+				ret = sdhci_msm_vreg_disable(vreg_table[i]);
+			if (ret)
+				goto out;
+		}
+	}
+out:
+	return ret;
+}
+
+/*
+ * Reset vreg by ensuring it is off during probe. A call
+ * to enable vreg is needed to balance disable vreg
+ */
+static int sdhci_msm_vreg_reset(struct sdhci_msm_pltfm_data *pdata)
+{
+	int ret;
+
+	ret = sdhci_msm_setup_vreg(pdata, 1, true);
+	if (ret)
+		return ret;
+	ret = sdhci_msm_setup_vreg(pdata, 0, true);
+	return ret;
+}
+
+/* This init function should be called only once for each SDHC slot */
+static int sdhci_msm_vreg_init(struct device *dev,
+			       struct sdhci_msm_pltfm_data *pdata, bool is_init)
+{
+	int ret = 0;
+	struct sdhci_msm_slot_reg_data *curr_slot;
+	struct sdhci_msm_reg_data *curr_vdd_reg, *curr_vdd_io_reg;
+
+	curr_slot = pdata->vreg_data;
+	if (!curr_slot)
+		goto out;
+
+	curr_vdd_reg = curr_slot->vdd_data;
+	curr_vdd_io_reg = curr_slot->vdd_io_data;
+
+	if (!is_init)
+		/* Deregister all regulators from regulator framework */
+		goto vdd_io_reg_deinit;
+
+	/*
+	 * Get the regulator handle from voltage regulator framework
+	 * and then try to set the voltage level for the regulator
+	 */
+	if (curr_vdd_reg) {
+		ret = sdhci_msm_vreg_init_reg(dev, curr_vdd_reg);
+		if (ret)
+			goto out;
+	}
+	if (curr_vdd_io_reg) {
+		ret = sdhci_msm_vreg_init_reg(dev, curr_vdd_io_reg);
+		if (ret)
+			goto vdd_reg_deinit;
+	}
+	ret = sdhci_msm_vreg_reset(pdata);
+	if (ret)
+		dev_err(dev, "vreg reset failed (%d)\n", ret);
+	goto out;
+
+vdd_io_reg_deinit:
+	if (curr_vdd_io_reg)
+		sdhci_msm_vreg_deinit_reg(curr_vdd_io_reg);
+vdd_reg_deinit:
+	if (curr_vdd_reg)
+		sdhci_msm_vreg_deinit_reg(curr_vdd_reg);
+out:
+	return ret;
+}
+
+static int sdhci_msm_set_vdd_io_vol(struct sdhci_msm_pltfm_data *pdata,
+				    enum vdd_io_level level,
+				    unsigned int voltage_level)
+{
+	int ret = 0;
+	int set_level;
+
+	if (pdata->vreg_data) {
+		struct sdhci_msm_reg_data *vdd_io_reg =
+		    pdata->vreg_data->vdd_io_data;
+
+		if (vdd_io_reg && vdd_io_reg->is_enabled) {
+			switch (level) {
+			case VDD_IO_LOW:
+				set_level = vdd_io_reg->low_vol_level;
+				break;
+			case VDD_IO_HIGH:
+				set_level = vdd_io_reg->high_vol_level;
+				break;
+			case VDD_IO_SET_LEVEL:
+				set_level = voltage_level;
+				break;
+			default:
+				pr_err("%s: invalid argument level = %d",
+				       __func__, level);
+				ret = -EINVAL;
+				goto out;
+			}
+			ret = sdhci_msm_vreg_set_voltage(vdd_io_reg,
+							 set_level, set_level);
+		}
+	}
+
+out:
+	return ret;
+}
+
+static irqreturn_t sdhci_msm_pwr_irq(int irq, void *data)
+{
+	struct sdhci_msm_host *msm_host = (struct sdhci_msm_host *)data;
+	u8 irq_status = 0;
+	u8 irq_ack = 0;
+	int ret = 0;
+
+	irq_status = readb_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS);
+	pr_debug("%s: Received IRQ(%d), status=0x%x\n",
+		 mmc_hostname(msm_host->mmc), irq, irq_status);
+
+	/* Clear the interrupt */
+	writeb_relaxed(irq_status, (msm_host->core_mem + CORE_PWRCTL_CLEAR));
+	/*
+	 * SDHC has core_mem and hc_mem device memory and these memory
+	 * addresses do not fall within 1KB region. Hence, any update to
+	 * core_mem address space would require an mb() to ensure this gets
+	 * completed before its next update to registers within hc_mem.
+	 */
+	mb();
+
+	/* Handle BUS ON/OFF */
+	if (irq_status & (CORE_PWRCTL_BUS_ON | CORE_PWRCTL_BUS_OFF)) {
+		bool flag = (irq_status & CORE_PWRCTL_BUS_ON) ? 1 : 0;
+		ret = sdhci_msm_setup_vreg(msm_host->pdata, flag, false);
+		if (!ret)
+			sdhci_msm_setup_pins(msm_host->pdata, flag);
+		if (ret)
+			irq_ack |= CORE_PWRCTL_BUS_FAIL;
+		else
+			irq_ack |= CORE_PWRCTL_BUS_SUCCESS;
+		goto out;
+	}
+	/* Handle IO LOW/HIGH */
+	if (irq_status & (CORE_PWRCTL_IO_LOW | CORE_PWRCTL_IO_HIGH)) {
+		/* Switch voltage */
+		int io_status = (irq_status & CORE_PWRCTL_IO_LOW) ?
+		    VDD_IO_LOW : VDD_IO_HIGH;
+		ret = sdhci_msm_set_vdd_io_vol(msm_host->pdata, io_status, 0);
+		if (ret)
+			irq_ack |= CORE_PWRCTL_IO_FAIL;
+		else
+			irq_ack |= CORE_PWRCTL_IO_SUCCESS;
+		goto out;
+	}
+
+out:
+	/* ACK status to the core */
+	writeb_relaxed(irq_ack, (msm_host->core_mem + CORE_PWRCTL_CTL));
+	/*
+	 * SDHC has core_mem and hc_mem device memory and these memory
+	 * addresses do not fall within 1KB region. Hence, any update to
+	 * core_mem address space would require an mb() to ensure this gets
+	 * completed before its next update to registers within hc_mem.
+	 */
+	mb();
+
+	pr_debug("%s: Handled IRQ(%d), ret=%d, ack=0x%x\n",
+		 mmc_hostname(msm_host->mmc), irq, ret, irq_ack);
+	return IRQ_HANDLED;
+}
+
+/* This function returns the max. current supported by VDD rail in mA */
+static unsigned int sdhci_msm_get_vreg_vdd_max_current(struct sdhci_msm_host
+						       *host)
+{
+	struct sdhci_msm_slot_reg_data *curr_slot = host->pdata->vreg_data;
+	if (!curr_slot)
+		return 0;
+	if (curr_slot->vdd_data)
+		return curr_slot->vdd_data->hpm_uA / 1000;
+	else
+		return 0;
+}
+
+static int sdhci_msm_probe(struct platform_device *pdev)
+{
+	struct sdhci_host *host;
+	struct sdhci_pltfm_host *pltfm_host;
+	struct sdhci_msm_host *msm_host;
+	struct resource *core_memres = NULL;
+	int ret = 0, pwr_irq = 0, dead = 0;
+
+	msm_host = devm_kzalloc(&pdev->dev, sizeof(struct sdhci_msm_host),
+				GFP_KERNEL);
+	if (!msm_host) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	host = sdhci_pltfm_init(pdev, &msm_host->sdhci_msm_pdata, 0);
+	if (IS_ERR(host)) {
+		dev_err(mmc_dev(host->mmc), "sdhci_pltfm_init error\n");
+		ret = PTR_ERR(host);
+		goto out;
+	}
+
+	pltfm_host = sdhci_priv(host);
+	pltfm_host->priv = msm_host;
+	msm_host->mmc = host->mmc;
+
+	/* Extract platform data */
+	if (pdev->dev.of_node) {
+		msm_host->pdata = sdhci_msm_populate_pdata(&pdev->dev);
+		if (!msm_host->pdata) {
+			dev_err(&pdev->dev, "DT parsing error\n");
+			goto pltfm_free;
+		}
+	} else {
+		dev_err(&pdev->dev, "No device tree node\n");
+		goto pltfm_free;
+	}
+
+	/* Setup Clocks */
+
+	/* Setup SDCC bus voter clock. */
+	msm_host->bus_clk = devm_clk_get(&pdev->dev, "bus_clk");
+	if (!IS_ERR_OR_NULL(msm_host->bus_clk)) {
+		/* Vote for max. clk rate for max. performance */
+		ret = clk_set_rate(msm_host->bus_clk, INT_MAX);
+		if (ret)
+			goto pltfm_free;
+		ret = clk_prepare_enable(msm_host->bus_clk);
+		if (ret)
+			goto pltfm_free;
+	}
+
+	/* Setup main peripheral bus clock */
+	msm_host->pclk = devm_clk_get(&pdev->dev, "iface_clk");
+	if (!IS_ERR(msm_host->pclk)) {
+		ret = clk_prepare_enable(msm_host->pclk);
+		if (ret) {
+			dev_err(&pdev->dev,
+				"Main peripheral clock setup failed (%d)\n",
+				ret);
+			goto bus_clk_disable;
+		}
+	}
+
+	/* Setup SDC MMC clock */
+	msm_host->clk = devm_clk_get(&pdev->dev, "core_clk");
+	if (IS_ERR(msm_host->clk)) {
+		ret = PTR_ERR(msm_host->clk);
+		dev_err(&pdev->dev, "SDC MMC clock setup failed (%d)\n", ret);
+		goto pclk_disable;
+	}
+
+	ret = clk_prepare_enable(msm_host->clk);
+	if (ret)
+		goto pclk_disable;
+
+	/* Setup regulators */
+	ret = sdhci_msm_vreg_init(&pdev->dev, msm_host->pdata, true);
+	if (ret) {
+		dev_err(&pdev->dev, "Regulator setup failed (%d)\n", ret);
+		goto clk_disable;
+	}
+
+	/* Reset the core and Enable SDHC mode */
+	core_memres = platform_get_resource_byname(pdev,
+						   IORESOURCE_MEM, "core_mem");
+	msm_host->core_mem = devm_ioremap(&pdev->dev, core_memres->start,
+					  resource_size(core_memres));
+
+	if (!msm_host->core_mem) {
+		dev_err(&pdev->dev, "Failed to remap registers\n");
+		ret = -ENOMEM;
+		goto vreg_deinit;
+	}
+
+	/* Set SW_RST bit in POWER register (Offset 0x0) */
+	writel_relaxed(CORE_SW_RST, msm_host->core_mem + CORE_POWER);
+	/* Set HC_MODE_EN bit in HC_MODE register */
+	writel_relaxed(HC_MODE_EN, (msm_host->core_mem + CORE_HC_MODE));
+
+	/*
+	 * Following are the deviations from SDHC spec v3.0 -
+	 * 1. Card detection is handled using separate GPIO.
+	 * 2. Bus power control is handled by interacting with PMIC.
+	 */
+	host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
+
+	/* Setup PWRCTL irq */
+	pwr_irq = platform_get_irq_byname(pdev, "pwr_irq");
+	if (pwr_irq < 0) {
+		dev_err(&pdev->dev, "Failed to get pwr_irq by name (%d)\n",
+			pwr_irq);
+		goto vreg_deinit;
+	}
+	ret = devm_request_threaded_irq(&pdev->dev, pwr_irq, NULL,
+					sdhci_msm_pwr_irq, IRQF_ONESHOT,
+					dev_name(&pdev->dev), msm_host);
+	if (ret) {
+		dev_err(&pdev->dev, "Request threaded irq(%d) failed (%d)\n",
+			pwr_irq, ret);
+		goto vreg_deinit;
+	}
+
+	/* Enable pwr irq interrupts */
+	writel_relaxed(INT_MASK, (msm_host->core_mem + CORE_PWRCTL_MASK));
+
+	/* Set host capabilities */
+	msm_host->mmc->caps |= msm_host->pdata->mmc_bus_width;
+	msm_host->mmc->caps |= msm_host->pdata->caps;
+	msm_host->mmc->caps2 |= msm_host->pdata->caps2;
+
+	if (msm_host->pdata->nonremovable)
+		msm_host->mmc->caps |= MMC_CAP_NONREMOVABLE;
+
+	ret = sdhci_add_host(host);
+	if (ret) {
+		dev_err(&pdev->dev, "Add host failed (%d)\n", ret);
+		goto vreg_deinit;
+	}
+
+	/* Set core clk rate, optionally override from dts */
+	if (msm_host->pdata->max_clk)
+		host->max_clk = msm_host->pdata->max_clk;
+	ret = clk_set_rate(msm_host->clk, host->max_clk);
+	if (ret) {
+		dev_err(&pdev->dev, "MClk rate set failed (%d)\n", ret);
+		goto remove_host;
+	}
+
+	host->mmc->max_current_180 =
+	    sdhci_msm_get_vreg_vdd_max_current(msm_host);
+	host->mmc->max_current_300 =
+	    sdhci_msm_get_vreg_vdd_max_current(msm_host);
+	host->mmc->max_current_330 =
+	    sdhci_msm_get_vreg_vdd_max_current(msm_host);
+
+	/* Successful initialization */
+	goto out;
+
+remove_host:
+	dead = (readl_relaxed(host->ioaddr + SDHCI_INT_STATUS) == 0xffffffff);
+	sdhci_remove_host(host, dead);
+vreg_deinit:
+	sdhci_msm_vreg_init(&pdev->dev, msm_host->pdata, false);
+clk_disable:
+	if (!IS_ERR(msm_host->clk))
+		clk_disable_unprepare(msm_host->clk);
+pclk_disable:
+	if (!IS_ERR(msm_host->pclk))
+		clk_disable_unprepare(msm_host->pclk);
+bus_clk_disable:
+	if (!IS_ERR_OR_NULL(msm_host->bus_clk))
+		clk_disable_unprepare(msm_host->bus_clk);
+pltfm_free:
+	sdhci_pltfm_free(pdev);
+out:
+	return ret;
+}
+
+static int sdhci_msm_remove(struct platform_device *pdev)
+{
+	struct sdhci_host *host = platform_get_drvdata(pdev);
+	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+	struct sdhci_msm_host *msm_host = pltfm_host->priv;
+	struct sdhci_msm_pltfm_data *pdata = msm_host->pdata;
+	int dead = (readl_relaxed(host->ioaddr + SDHCI_INT_STATUS) ==
+		    0xffffffff);
+
+	pr_debug("%s: %s\n", dev_name(&pdev->dev), __func__);
+	sdhci_remove_host(host, dead);
+	sdhci_pltfm_free(pdev);
+	sdhci_msm_vreg_init(&pdev->dev, msm_host->pdata, false);
+	if (!IS_ERR(msm_host->clk))
+		clk_disable_unprepare(msm_host->clk);
+	if (!IS_ERR(msm_host->pclk))
+		clk_disable_unprepare(msm_host->pclk);
+	if (!IS_ERR_OR_NULL(msm_host->bus_clk))
+		clk_disable_unprepare(msm_host->bus_clk);
+	if (pdata->pin_data)
+		sdhci_msm_setup_gpio(pdata, false);
+	return 0;
+}
+
+static const struct of_device_id sdhci_msm_dt_match[] = {
+	{.compatible = "qcom,sdhci-msm"},
+};
+
+MODULE_DEVICE_TABLE(of, sdhci_msm_dt_match);
+
+static struct platform_driver sdhci_msm_driver = {
+	.probe = sdhci_msm_probe,
+	.remove = sdhci_msm_remove,
+	.driver = {
+		   .name = "sdhci_msm",
+		   .owner = THIS_MODULE,
+		   .of_match_table = sdhci_msm_dt_match,
+		   },
+};
+
+module_platform_driver(sdhci_msm_driver);
+
+MODULE_DESCRIPTION("Qualcomm Secure Digital Host Controller Interface driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5



From nm at ti.com  Tue Jul 30 12:23:31 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 11:23:31 -0500
Subject: [PATCHv4 03/33] CLK: OMAP4: Add DPLL clock support
In-Reply-To: <1374564028-11352-4-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-4-git-send-email-t-kristo@ti.com>
Message-ID: <51F7E883.7000000@ti.com>

This patch probably was submitted in the wrong sequence - fails build 
and few other issues below.

On 07/23/2013 02:19 AM, Tero Kristo wrote:
> The OMAP clock driver now supports DPLL clock type. This patch also
> adds support for DT DPLL nodes.

Then why is $subject specific to OMAP4? is that because of 
of_omap4_dpll_setup?

>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
>   drivers/clk/omap/Makefile |    2 +-
>   drivers/clk/omap/clk.c    |    1 +
>   drivers/clk/omap/dpll.c   |  295 +++++++++++++++++++++++++++++++++++++++++++++

Device Tree Binding documentation?

>   3 files changed, 297 insertions(+), 1 deletion(-)
>   create mode 100644 drivers/clk/omap/dpll.c
>
> diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
> index 8195931..4cad480 100644
> --- a/drivers/clk/omap/Makefile
> +++ b/drivers/clk/omap/Makefile
> @@ -1 +1 @@
> -obj-y					+= clk.o
> +obj-y					+= clk.o dpll.o
> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
> index 4bf1929..1dafdaa 100644
> --- a/drivers/clk/omap/clk.c
> +++ b/drivers/clk/omap/clk.c
> @@ -28,6 +28,7 @@ static const struct of_device_id clk_match[] = {
>   		.data = of_fixed_factor_clk_setup, },
>   	{.compatible = "divider-clock", .data = of_divider_clk_setup, },
>   	{.compatible = "gate-clock", .data = of_gate_clk_setup, },
> +	{.compatible = "ti,omap4-dpll-clock", .data = of_omap4_dpll_setup, },
>   	{},
>   };
you would not need this if you did just of_clk_init(NULL); ?

Further, at this patch, build fails with:
drivers/clk/omap/clk.c:31:55: error: undefined identifier 
'of_omap4_dpll_setup'
drivers/clk/omap/clk.c:31:48: error: ?of_omap4_dpll_setup? undeclared 
here (not in a function)

which makes sense since we did not export the function.	
>
> diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
> new file mode 100644
> index 0000000..66e82be
> --- /dev/null
> +++ b/drivers/clk/omap/dpll.c
> @@ -0,0 +1,295 @@
> +/*
> + * OMAP DPLL clock support
> + *
> + * Copyright (C) 2013 Texas Instruments, Inc.
> + *
> + * Tero Kristo <t-kristo at ti.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/io.h>
> +#include <linux/err.h>
> +#include <linux/string.h>
> +#include <linux/log2.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
after a quick check, are all these required?

> +#include <linux/clk/omap.h>

why?

> +
> +static const struct clk_ops dpll_m4xen_ck_ops = {
> +	.enable		= &omap3_noncore_dpll_enable,
> +	.disable	= &omap3_noncore_dpll_disable,
> +	.recalc_rate	= &omap4_dpll_regm4xen_recalc,
> +	.round_rate	= &omap4_dpll_regm4xen_round_rate,
> +	.set_rate	= &omap3_noncore_dpll_set_rate,
> +	.get_parent	= &omap2_init_dpll_parent,
> +};
> +
> +static const struct clk_ops dpll_core_ck_ops = {
> +	.recalc_rate	= &omap3_dpll_recalc,
> +	.get_parent	= &omap2_init_dpll_parent,
> +};
> +
> +static const struct clk_ops dpll_ck_ops = {
> +	.enable		= &omap3_noncore_dpll_enable,
> +	.disable	= &omap3_noncore_dpll_disable,
> +	.recalc_rate	= &omap3_dpll_recalc,
> +	.round_rate	= &omap2_dpll_round_rate,
> +	.set_rate	= &omap3_noncore_dpll_set_rate,
> +	.get_parent	= &omap2_init_dpll_parent,
> +	.init		= &omap2_init_clk_clkdm,
> +};
> +
> +static const struct clk_ops dpll_x2_ck_ops = {
> +	.recalc_rate	= &omap3_clkoutx2_recalc,
> +};

none of these are defined at this stage of the patch, generates a huge 
build error for dpll.c
http://pastebin.com/GJucv1A5
> +
> +struct clk *omap_clk_register_dpll(struct device *dev, const char *name,
> +		const char **parent_names, int num_parents, unsigned long flags,
> +		struct dpll_data *dpll_data, const char *clkdm_name,
> +		const struct clk_ops *ops)

why should this be public?

> +{
> +	struct clk *clk;
> +	struct clk_init_data init;

init = { 0 };  just to future proof?

> +	struct clk_hw_omap *clk_hw;

does not exist yet in generic header?

I am assuming you do not do parameter check as you expect clk_register 
to do the same?

> +
> +	/* allocate the divider */
> +	clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
checkpatch complained:
CHECK: Prefer kzalloc(sizeof(*clk_hw)...) over kzalloc(sizeof(struct 
clk_hw_omap)...)

or given we have dev, devm_kzalloc?
> +	if (!clk_hw) {
> +		pr_err("%s: could not allocate clk_hw_omap\n", __func__);
> +		return ERR_PTR(-ENOMEM);
> +	}
> +
> +	clk_hw->dpll_data = dpll_data;
> +	clk_hw->ops = &clkhwops_omap3_dpll;
> +	clk_hw->clkdm_name = clkdm_name;
> +	clk_hw->hw.init = &init;
> +
> +	init.name = name;
> +	init.ops = ops;
> +	init.flags = flags;
> +	init.parent_names = parent_names;
> +	init.num_parents = num_parents;
> +
> +	/* register the clock */
> +	clk = clk_register(dev, &clk_hw->hw);
> +
> +	if (IS_ERR(clk))
> +		kfree(clk_hw);
> +	else
> +		omap2_init_clk_hw_omap_clocks(clk);
what if init fails? and it is in mach-omap2 at this point in time?

> +
> +	return clk;
> +}
> +
> +struct clk *omap_clk_register_dpll_x2(struct device *dev, const char *name,
> +		const char *parent_name, void __iomem *reg,
> +		const struct clk_ops *ops)

same question here as well

> +{
> +	struct clk *clk;
> +	struct clk_init_data init;
> +	struct clk_hw_omap *clk_hw;
> +
> +	if (!parent_name) {
> +		pr_err("%s: dpll_x2 must have parent\n", __func__);
> +		return ERR_PTR(-EINVAL);
> +	}
> +
> +	clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
checkpatch complained:
CHECK: Prefer kzalloc(sizeof(*clk_hw)...) over kzalloc(sizeof(struct 
clk_hw_omap)...)

or devm_kzalloc?

> +	if (!clk_hw) {
> +		pr_err("%s: could not allocate clk_hw_omap\n", __func__);
> +		return ERR_PTR(-ENOMEM);
> +	}
> +
> +	clk_hw->ops = &clkhwops_omap4_dpllmx;
> +	clk_hw->clksel_reg = reg;
> +	clk_hw->hw.init = &init;
> +
> +	init.name = name;
> +	init.ops = ops;
> +	init.parent_names = &parent_name;
> +	init.num_parents = 1;
> +
> +	/* register the clock */
> +	clk = clk_register(dev, &clk_hw->hw);
> +
> +	if (IS_ERR(clk))
> +		kfree(clk_hw);
> +	else
> +		omap2_init_clk_hw_omap_clocks(clk);
> +
> +	return clk;
> +}
this vaguely sounds like a replica of omap_clk_register_dpll with 
num_parents and clk_hw->ops different. why not merge the two?

> +
> +#ifdef CONFIG_OF

why not build the entire thing *iff* CONFIG_OF (Makefile/Kconfig dep)? 
that way, we can drop this #ifdef stuff from drivers that dont need to 
have dual support.

> +
> +/**
> + * of_omap_dpll_setup() - Setup function for OMAP DPLL clocks

node and ops not documented.

> + */
> +static void __init of_omap_dpll_setup(struct device_node *node,
> +					const struct clk_ops *ops)
> +{
> +	struct clk *clk;
> +	const char *clk_name = node->name;
> +	int num_parents;
> +	const char **parent_names;
> +	const char *clkdm_name = NULL;
> +	struct of_phandle_args clkspec;
> +	u8 dpll_flags = 0;
> +	struct dpll_data *dd;
> +	u32 idlest_mask = 0x1;
> +	u32 enable_mask = 0x7;
> +	u32 autoidle_mask = 0x7;
> +	u32 mult_mask = 0x7ff << 8;
> +	u32 div1_mask = 0x7f;
> +	u32 max_multiplier = 2047;
> +	u32 max_divider = 128;
> +	u32 min_divider = 1;
> +	int i;
> +
> +	dd = kzalloc(sizeof(struct dpll_data), GFP_KERNEL);
kzalloc sizeof(*dd) ?

> +	if (!dd) {
> +		pr_err("%s: could not allocate dpll_data\n", __func__);
> +		return;
> +	}
> +
> +	of_property_read_string(node, "clock-output-names", &clk_name);
> +
> +	num_parents = of_clk_get_parent_count(node);
> +	if (num_parents < 1) {
> +		pr_err("%s: omap dpll %s must have parent(s)\n",
> +			__func__, node->name);

checkpatch complained:
CHECK: Alignment should match open parenthesis
#212: FILE: drivers/clk/omap/dpll.c:171:
After applying the patch, I think you should make __func__ aligned with 
" and not %

> +		goto cleanup;
> +	}
> +
> +	parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
> +
> +	for (i = 0; i < num_parents; i++)
> +		parent_names[i] = of_clk_get_parent_name(node, i);
> +
> +	of_property_read_u32(node, "ti,idlest-mask", &idlest_mask);
> +
> +	of_property_read_u32(node, "ti,enable-mask", &enable_mask);
> +
> +	of_property_read_u32(node, "ti,autoidle-mask", &autoidle_mask);

are these going to be different? or can we catch with compatible flag?

> +
> +	clkspec.np = of_parse_phandle(node, "ti,clk-ref", 0);
> +	dd->clk_ref = of_clk_get_from_provider(&clkspec);
> +	if (!dd->clk_ref) {
> +		pr_err("%s: ti,clk-ref for %s not found\n", __func__,
> +			clk_name);

CHECK: Alignment should match open parenthesis
#231: FILE: drivers/clk/omap/dpll.c:190:
similar issue here.

> +		goto cleanup;
> +	}
> +
> +	clkspec.np = of_parse_phandle(node, "ti,clk-bypass", 0);
> +	dd->clk_bypass = of_clk_get_from_provider(&clkspec);
> +	if (!dd->clk_bypass) {
> +		pr_err("%s: ti,clk-bypass for %s not found\n", __func__,
> +			clk_name);

here as well

> +		goto cleanup;
> +	}
> +
> +	of_property_read_string(node, "ti,clkdm-name", &clkdm_name);
> +
> +	dd->control_reg = of_iomap(node, 0);
> +	dd->idlest_reg = of_iomap(node, 1);
> +	dd->autoidle_reg = of_iomap(node, 2);
> +	dd->mult_div1_reg = of_iomap(node, 3);

if dts has errors, should we not verify mandatory parameters?

> +
> +	dd->idlest_mask = idlest_mask;
> +	dd->enable_mask = enable_mask;
> +	dd->autoidle_mask = autoidle_mask;
> +
> +	dd->modes = 0xa0;

what is 0xa0?

> +
> +	if (of_property_read_bool(node, "ti,dpll-j-type")) {
> +		dd->sddiv_mask = 0xff000000;
> +		mult_mask = 0xfff << 8;
> +		div1_mask = 0xff;
> +		max_multiplier = 4095;
> +		max_divider = 256;
> +	}
> +
> +	if (of_property_read_bool(node, "ti,dpll-regm4xen")) {
I think we need bindings to understand this better.

> +		dd->m4xen_mask = 0x800;
> +		dd->lpmode_mask = 1 << 10;
> +	}
> +
> +	dd->mult_mask = mult_mask;
> +	dd->div1_mask = div1_mask;
> +	dd->max_multiplier = max_multiplier;
> +	dd->max_divider = max_divider;
> +	dd->min_divider = min_divider;
> +
> +	clk = omap_clk_register_dpll(NULL, clk_name, parent_names,
> +				num_parents, dpll_flags, dd,
> +				clkdm_name, ops);
> +
> +	if (!IS_ERR(clk))
> +		of_clk_add_provider(node, of_clk_src_simple_get, clk);
error check?
> +	return;
> +
> +cleanup:

kfree(parent_names) ?

> +	kfree(dd);
> +	return;
> +}
> +
> +static void __init of_omap_dpll_x2_setup(struct device_node *node)
> +{
> +	struct clk *clk;
> +	const char *clk_name = node->name;
> +	void __iomem *reg;
> +	const char *parent_name;
> +
> +	of_property_read_string(node, "clock-output-names", &clk_name);
> +
> +	parent_name = of_clk_get_parent_name(node, 0);
> +
> +	reg = of_iomap(node, 0);

if dts has errors, should we not verify mandatory parameters?

> +
> +	clk = omap_clk_register_dpll_x2(NULL, clk_name, parent_name,
> +				reg, &dpll_x2_ck_ops);
> +
> +	if (!IS_ERR(clk))
> +		of_clk_add_provider(node, of_clk_src_simple_get, clk);
error check?

gentle request - in this setup function we dont see a return of error 
value (which makes sense), but more importantly - log saying that node 
was not setup

> +}
> +
> +__init void of_omap3_dpll_setup(struct device_node *node)

^^ void __init? further, you could make this static.

> +{
> +	/* XXX: to be done */
> +}
> +EXPORT_SYMBOL_GPL(of_omap3_dpll_setup);

you can drop the export if you use of_clk_init(NULL);

> +CLK_OF_DECLARE(omap3_dpll_clock, "ti,omap3-dpll-clock", of_omap3_dpll_setup);
> +
> +__init void of_omap4_dpll_setup(struct device_node *node)

^^ void __init? further, you could make this static.

> +{
> +	const struct clk_ops *ops;
> +
> +	ops = &dpll_ck_ops;
> +
> +	if (of_property_read_bool(node, "ti,dpll-regm4xen"))
> +		ops = &dpll_m4xen_ck_ops;
> +
> +	if (of_property_read_bool(node, "ti,dpll-core"))
> +		ops = &dpll_core_ck_ops;
> +
> +	if (of_property_read_bool(node, "ti,dpll-clk-x2")) {
> +		of_omap_dpll_x2_setup(node);
> +		return;
> +	}
> +
> +	of_omap_dpll_setup(node, ops);
> +}
> +EXPORT_SYMBOL_GPL(of_omap4_dpll_setup);

you can drop the export if you use of_clk_init(NULL);

> +CLK_OF_DECLARE(omap4_dpll_clock, "ti,omap4-dpll-clock", of_omap4_dpll_setup);
> +#endif
>
-- 
Regards,
Nishanth Menon


From swarren at wwwdotorg.org  Tue Jul 30 12:24:21 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 10:24:21 -0600
Subject: [PATCH V2] ARM: dts: tegra114: dalmore: fix the irq trigger type
 of Palmas MFD device
In-Reply-To: <1375177568.1239.16.camel@jlo-ubuntu-64.nvidia.com>
References: <1374663272-9937-1-git-send-email-josephl@nvidia.com>
 <51F292D4.9030208@wwwdotorg.org>
 <1375177568.1239.16.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <51F7E8B5.6030009@wwwdotorg.org>

On 07/30/2013 03:46 AM, Joseph Lo wrote:
> On Fri, 2013-07-26 at 23:16 +0800, Stephen Warren wrote:
>> On 07/24/2013 04:54 AM, Joseph Lo wrote:
>>> The IRQ trigger type of Palmas MFD device (tps65913) is edge trigger. The
>>> wrong configuration would cause an interrupt storm when booting the
>>> system. Fixing it in DT with appropriate interrupt type.
>>
>>> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
>>
>>>  		palmas: tps65913 {
>>>  			compatible = "ti,palmas";
>>>  			reg = <0x58>;
>>> -			interrupts = <0 86 0x4>;
>>> +			interrupts = <0 86 0x0>;
>>
>> The legal values for that final cell are:
>>
>>     - bits[3:0] trigger type and level flags
>>         1 = low-to-high edge triggered
>>         2 = high-to-low edge triggered
>>         4 = active high level-sensitive
>>         8 = active low level-sensitive
>>
>> 0 isn't one of those values. This patch can't be correct.
>>
>> BTW, this cell should use the constants from
>> <dt-bindings/interrupt-controller/irq.h>.
> 
> Oops. I made a wrong description in the commit message.
> 
> Update my test result again.
> 
>> 1 = low-to-high edge triggered
> No IRQ storm, but the system always auto wake up by Palmas RTC.
>> 2 = high-to-low edge triggered
> No IRQ storm, but the GIC didn't support this trigger type. The flag
> would be re-configured as 0x0.
>> 4 = active high level-sensitive
> There is a IRQ storm when system booting.
>> 8 = active low level-sensitive
> No IRQ strom, but the GIC didn't support this trigger type. The flag
> would be re-configured as 0x0.
> 
>> nvidia, invert-interrupt
> Removing this can fix IRQ storm too, but the system always auto wake up
> by Palmas RTC.
> 
> So we can only three trigger type here.
> IRQ_TYPE_NONE 0

That's not a valid value; it just means that the GIC driver doesn't
explicitly set the type, and the HW probably defaults to active high?

> IRQ_TYPE_EDGE_FALLING 2
> IRQ_TYPE_LEVEL_LOW 8
> 
> But using IRQ_TYPE_EDGE_FALLING or IRQ_TYPE_LEVEL_LOW, it would
> configure to IRQ_TYPE_NONE. Because the PMIC is low level trigger to PMC
> on Dalmore, I would prefer to use IRQ_TYPE_LEVEL_LOW just like the v1.
> Any comments?

Comments no, I just have confusion!

We should simply set this flag to the correct value. Does the PMIC
output an edge-sensitive or level-sensitive signal? Is the signal
active-high/rising or active-low/falling? Those are the only things that
should be considered when selecting the correct value for the IRQ flags.
This information can be determined by reading the data sheet for the
PMIC; while the test results you mention above are interesting, the HW
documentation should drive the value we select here, unless the
documentation has a known bug.

If there is an IRQ storm, then that sounds like a bug in the code. That
needs to be fixed too, not worked around by setting an incorrect IRQ
flags value.

To be clear, here is what I would expect depending on what kind of IRQ
signal the PMIC outputs:

active-low:
GIC: active-high, PMC: nvidia,invert-interrupt

active-high:
GIC: active-high, PMC: NO nvidia,invert-interrupt

falling-edge:
GIC: rising-edge-triggered, PMC: nvidia,invert-interrupt

rising-edge:
GIC: rising-edge-triggered, PMC: NO nvidia,invert-interrupt


From nsekhar at ti.com  Tue Jul 30 12:29:04 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 30 Jul 2013 21:59:04 +0530
Subject: [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA
 resources
In-Reply-To: <51F73738.6080901@ti.com>
References: <1374515989-7391-1-git-send-email-joelf@ti.com>
 <51F61359.1090309@ti.com> <51F73738.6080901@ti.com>
Message-ID: <51F7E9D0.1080107@ti.com>

On 7/30/2013 9:17 AM, Joel Fernandes wrote:

>>> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
>>> index a432e6c..765d578 100644
>>> --- a/arch/arm/common/edma.c
>>> +++ b/arch/arm/common/edma.c

>>> +	} else {
>>> +		for (; i < pdev->num_resources; i++) {
>>> +			if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
>>> +			    (int)pdev->resource[i].start >= 0) {
>>> +				ctlr = EDMA_CTLR(pdev->resource[i].start);
>>> +				clear_bit(EDMA_CHAN_SLOT(
>>> +					  pdev->resource[i].start),
>>> +					  edma_cc[ctlr]->edma_unused);
>>> +			}
>>
>> So there is very little in common between OF and non-OF versions of this
>> function. Why not have two different versions of this function for the
>> two cases? The OF version can reside under the CONFIG_OF conditional
>> already in use in the file. This will also save you the ugly line breaks
>> you had to resort to due to too deep indentation.
> 
> Actually those line breaks are not necessary and wouldn't result in
> compilation errors. I was planning to drop them. I'll go ahead and split
> it out anyway, now that also the OF version of the function is going to
> be bit longer if we use the of_parse functions.
> 
> Thanks for your review,

It turns out, I gave a bad idea. What I suggested will break the case of
non-DT boot with CONFIG_OF enabled. So what you had was fine. May be
just return from "if (dev->of_node)" so you don't need to have an else
block and can save on the indentation.

Thanks,
Sekhar


From lorenzo.pieralisi at arm.com  Tue Jul 30 12:30:11 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 30 Jul 2013 17:30:11 +0100
Subject: [PATCH 12/13] ARM: bL_switcher: remove assumptions between
 logical and physical CPUs
In-Reply-To: <1374550289-25305-13-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-13-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130730163010.GA8921@e102568-lin.cambridge.arm.com>

On Tue, Jul 23, 2013 at 04:31:28AM +0100, Nicolas Pitre wrote:
> Up to now, the logical CPU was somehow tied to the physical CPU number
> within a cluster.  This causes problems when forcing the boot CPU to be
> different from the first enumerated CPU in the device tree creating a
> discrepancy between logical and physical CPU numbers.
> 
> Let's make the pairing completely independent from physical CPU numbers.
> 
> Let's keep only those logical CPUs with same initial CPU cluster to create
> a uniform scheduler profile without having to modify any of the probed
> topology and compute capacity data.  This has the potential to create
> a non contiguous CPU numbering space when the switcher is active with
> potential impact on buggy user space tools.  It is however better to fix
> those tools rather than making the switcher code more intrusive.

Nico, I am not following you here. Is this not the same problem we
have in a system where we hotplug out some of the CPUs in the logical map ?

Actually you are just hotplugging out some cpus according to a switcher
specific policy, if the problem is there, it is there already, unless
you are referring to MIDRs of the online CPUs that in the switcher case
might change at run-time for a specific logical index, but that happens
regardless.

[...]

>  static void bL_switcher_restore_cpus(void)
> @@ -319,52 +322,86 @@ static void bL_switcher_restore_cpus(void)
>  
>  static int bL_switcher_halve_cpus(void)
>  {
> -	int cpu, cluster, i, ret;
> -	cpumask_t cluster_mask[2], common_mask;
> -
> -	cpumask_clear(&bL_switcher_removed_logical_cpus);
> -	cpumask_clear(&cluster_mask[0]);
> -	cpumask_clear(&cluster_mask[1]);
> +	int i, j, cluster_0, gic_id, ret;
> +	unsigned int cpu, cluster, mask;
> +	cpumask_t available_cpus;
>  
> +	/* First pass to validate what we have */
> +	mask = 0;
>  	for_each_online_cpu(i) {
> -		cpu = cpu_logical_map(i) & 0xff;
> -		cluster = (cpu_logical_map(i) >> 8) & 0xff;
> +		cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 0);
> +		cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 1);
>  		if (cluster >= 2) {
>  			pr_err("%s: only dual cluster systems are supported\n", __func__);
>  			return -EINVAL;
>  		}
> -		cpumask_set_cpu(cpu, &cluster_mask[cluster]);
> +		if (WARN_ON(cpu >= MAX_CPUS_PER_CLUSTER))

pr_warn ?

> +			return -EINVAL;
> +		mask |= (1 << cluster);
>  	}
> -
> -	if (!cpumask_and(&common_mask, &cluster_mask[0], &cluster_mask[1])) {
> -		pr_err("%s: no common set of CPUs\n", __func__);
> +	if (mask != 3) {

Technically, you might have two clusters with eg MPIDR[15:8] = {0,2}
this would break this code. Just saying, I know for now we can live with that.
Given that's the only usage of mask you might use a counter, just as well.

> +		pr_err("%s: no CPU pairing possible\n", __func__);
>  		return -EINVAL;
>  	}
>  
> -	for_each_online_cpu(i) {
> -		cpu = cpu_logical_map(i) & 0xff;
> -		cluster = (cpu_logical_map(i) >> 8) & 0xff;
> -
> -		if (cpumask_test_cpu(cpu, &common_mask)) {
> -			/* Let's take note of the GIC ID for this CPU */
> -			int gic_id = gic_get_cpu_id(i);
> -			if (gic_id < 0) {
> -				pr_err("%s: bad GIC ID for CPU %d\n", __func__, i);
> -				return -EINVAL;
> -			}
> -			bL_gic_id[cpu][cluster] = gic_id;
> -			pr_info("GIC ID for CPU %u cluster %u is %u\n",
> -				cpu, cluster, gic_id);
> -
> +	/*
> +	 * Now let's do the pairing.  We match each CPU with another CPU
> +	 * from a different cluster.  To get a uniform scheduling behavior
> +	 * without fiddling with CPU topology and compute capacity data,
> +	 * we'll use logical CPUs initially belonging to the same cluster.
> +	 */
> +	memset(bL_switcher_cpu_pairing, -1, sizeof(bL_switcher_cpu_pairing));
> +	cpumask_copy(&available_cpus, cpu_online_mask);
> +	cluster_0 = -1;
> +	for_each_cpu(i, &available_cpus) {
> +		int match = -1;
> +		cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 1);
> +		if (cluster_0 == -1)
> +			cluster_0 = cluster;
> +		if (cluster != cluster_0)
> +			continue;
> +		cpumask_clear_cpu(i, &available_cpus);
> +		for_each_cpu(j, &available_cpus) {
> +			cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(j), 1);
>  			/*
> -			 * We keep only those logical CPUs which number
> -			 * is equal to their physical CPU number. This is
> -			 * not perfect but good enough for now.
> +			 * Let's remember the last match to create "odd"
> +			 * pairings on purpose in order for other code not
> +			 * to assume any relation between physical and
> +			 * logical CPU numbers.
>  			 */
> -			if (cpu == i) {
> -				bL_switcher_cpu_original_cluster[cpu] = cluster;
> -				continue;
> -			}
> +			if (cluster != cluster_0)
> +				match = j;
> +		}
> +		if (match != -1) {
> +			bL_switcher_cpu_pairing[i] = match;
> +			cpumask_clear_cpu(match, &available_cpus);
> +			pr_info("CPU%d paired with CPU%d\n", i, match);
> +		}
> +	}
> +
> +	/*
> +	 * Now we disable the unwanted CPUs i.e. everything that has no
> +	 * pairing information (that includes the pairing counterparts).
> +	 */
> +	cpumask_clear(&bL_switcher_removed_logical_cpus);
> +	for_each_online_cpu(i) {
> +		cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 0);
> +		cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 1);
> +
> +		/* Let's take note of the GIC ID for this CPU */
> +		gic_id = gic_get_cpu_id(i);
> +		if (gic_id < 0) {
> +			pr_err("%s: bad GIC ID for CPU %d\n", __func__, i);
> +			bL_switcher_restore_cpus();
> +			return -EINVAL;
> +		}
> +		bL_gic_id[cpu][cluster] = gic_id;
> +		pr_info("GIC ID for CPU %u cluster %u is %u\n",
> +			cpu, cluster, gic_id);
> +
> +		if (bL_switcher_cpu_pairing[i] != -1) {
> +			bL_switcher_cpu_original_cluster[i] = cluster;
> +			continue;
>  		}
>  
>  		ret = cpu_down(i);
> @@ -415,7 +452,7 @@ static int bL_switcher_enable(void)
>  
>  static void bL_switcher_disable(void)
>  {
> -	unsigned int cpu, cluster, i;
> +	unsigned int cpu, cluster;
>  	struct bL_thread *t;
>  	struct task_struct *task;
>  
> @@ -435,7 +472,6 @@ static void bL_switcher_disable(void)
>  	 * possibility for interference from external requests.
>  	 */
>  	for_each_online_cpu(cpu) {
> -		BUG_ON(cpu != (cpu_logical_map(cpu) & 0xff));
>  		t = &bL_threads[cpu];
>  		task = t->task;
>  		t->task = NULL;
> @@ -459,14 +495,10 @@ static void bL_switcher_disable(void)
>  		/* If execution gets here, we're in trouble. */
>  		pr_crit("%s: unable to restore original cluster for CPU %d\n",
>  			__func__, cpu);
> -		for_each_cpu(i, &bL_switcher_removed_logical_cpus) {
> -			if ((cpu_logical_map(i) & 0xff) != cpu)
> -				continue;
> -			pr_crit("%s: CPU %d can't be restored\n",
> -				__func__, i);
> -			cpumask_clear_cpu(i, &bL_switcher_removed_logical_cpus);
> -			break;
> -		}
> +		pr_crit("%s: CPU %d can't be restored\n",
> +			__func__, bL_switcher_cpu_pairing[cpu]);
> +		cpumask_clear_cpu(bL_switcher_cpu_pairing[cpu],
> +				  &bL_switcher_removed_logical_cpus);
>  	}
>  
>  	bL_switcher_restore_cpus();
> -- 

Other than that:

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>



From swarren at wwwdotorg.org  Tue Jul 30 12:30:45 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 10:30:45 -0600
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <CAKON4OyWuF+qm2MAhbXnGg=ozzw37kpSWciLxyUy+QQzxoWdxQ@mail.gmail.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
 <2460092.aLmjrOVh1g@flatron> <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
 <CACxGe6uE6jOE-vz0onW5h93Es-soGiBAcFBM7Dvxh+HvCNrHkw@mail.gmail.com>
 <CACxGe6vw9=y5a+EgF1gO39SwGAdGofD2MYjyJ3jYu6uN3ke70A@mail.gmail.com>
 <1374988276.1973.29.camel@dabdike> <20130730014453.GJ29970@voom.fritz.box>
 <CAKON4OyWuF+qm2MAhbXnGg=ozzw37kpSWciLxyUy+QQzxoWdxQ@mail.gmail.com>
Message-ID: <51F7EA35.6070501@wwwdotorg.org>

On 07/29/2013 08:15 PM, jonsmirl at gmail.com wrote:
> On Mon, Jul 29, 2013 at 9:44 PM, David Gibson
> <david at gibson.dropbear.id.au> wrote:
...
>> I also think we should consider the option of having a simple and
>> straightforward schema language which handles, say, 80% of cases with
>> a fall back to C for the 20% of curly cases.  That might actually be
>> simpler to work with in practice than a schema language which can
>> express absolutely anything, at the cost of being awkward for simple
>> cases or difficult to get your head around.
> 
> Would C++ work? You can use operating overloading and templates to
> change the syntax into something that doesn't even resemble C any
> more.

>From my perspective, that's precisely why C++ should /not/ be used.


From cjb at laptop.org  Tue Jul 30 12:40:16 2013
From: cjb at laptop.org (Chris Ball)
Date: Tue, 30 Jul 2013 17:40:16 +0100
Subject: [PATCH] mmc: sdhci-msm: Add support for MSM chipsets
In-Reply-To: <1375201355-26906-1-git-send-email-gdjakov@mm-sol.com> (Georgi
 Djakov's message of "Tue, 30 Jul 2013 19:22:35 +0300")
References: <1375201355-26906-1-git-send-email-gdjakov@mm-sol.com>
Message-ID: <86y58orogf.fsf@void.printf.net>

Hi Georgi,

On Tue, Jul 30 2013, Georgi Djakov wrote:
> This platform driver adds the support of Secure Digital Host
> Controller Interface compliant controller in MSM chipsets.
>
> CC: Asutosh Das <asutoshd at codeaurora.org>
> CC: Venkat Gopalakrishnan <venkatg at codeaurora.org>
> CC: Sahitya Tummala <stummala at codeaurora.org>
> CC: Subhash Jadavani <subhashj at codeaurora.org>
> Signed-off-by: Georgi Djakov <gdjakov at mm-sol.com>
> ---
> This is an initial version of the Qualcomm MSM SDHCI driver.
> It is based on the SDHCI code from coreaurora.org with minor
> modifications. The MMC standard DT bindings are used where
> possible. The patch applies to v3.11-rc3.

Is the arch code that will use this driver already in mainline,
or on its way in?

Thanks,

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>


From swarren at wwwdotorg.org  Tue Jul 30 12:40:36 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 10:40:36 -0600
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130730014453.GJ29970@voom.fritz.box>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <2007664.vYsECFSKrV@flatron> <51F39FD8.6080808@broadcom.com>
 <2460092.aLmjrOVh1g@flatron> <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
 <CACxGe6uE6jOE-vz0onW5h93Es-soGiBAcFBM7Dvxh+HvCNrHkw@mail.gmail.com>
 <CACxGe6vw9=y5a+EgF1gO39SwGAdGofD2MYjyJ3jYu6uN3ke70A@mail.gmail.com>
 <1374988276.1973.29.camel@dabdike> <20130730014453.GJ29970@voom.fritz.box>
Message-ID: <51F7EC84.90005@wwwdotorg.org>

On 07/29/2013 07:44 PM, David Gibson wrote:
...
> So, by way of investigation, let me propose an alternative
> expression of schemas, that I'm also not convinced we should do,
> but is possible and expressive.  It's illustrative, because it's
> kind of the polar opposite approach to XSD: just use C.

That actually sounds reasonable.

But, I think there's a difference between a schema, which defines
what's legal in an abstract fashion, and a validator, which defines
that the data conforms to the schema.

I can see that codding a validator in C would be pretty easy, and even
potentially quite simple/clean given a suitable set of library
functions as you say.

However, I'm not so convinced that expressing the schema itself as C
would work out so well. I think the code/data-structures would end up
being pretty stylized so they could actually be read as a schema. At
that point, a specific schema language would probably be simpler? Of
course, this is all somewhat conjecture; perhaps the only way to tell
would be to prototype various ideas and see how well they work.

Equally, I'm not sure I want to bind the schema definition to a
particular language. I'd like to be able to programatically generate
or manipulate *.dts files in arbitrary languages. Integrating a C
interpreter into those languages in order to handle the schema would
be annoying, whereas directly handling a special-purpose schema
language seems like it'd be more tangible.

As an aside, in the past I toyed with the idea of using Python data
structures as a *.dts syntax, and hence allowing
macros/auto-generation using custom Python code, and I'm sure Forth
will come up sometime in this thread:-)


From swarren at wwwdotorg.org  Tue Jul 30 12:44:18 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 10:44:18 -0600
Subject: [PATCH 2/9] dma: tegra20-apbdma: move to generic device tree
 bindings
In-Reply-To: <20130730030644.GJ15855@rizhao-lap>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-3-git-send-email-rizhao@nvidia.com>
 <51F2CDBE.40802@wwwdotorg.org> <20130730030644.GJ15855@rizhao-lap>
Message-ID: <51F7ED62.4060404@wwwdotorg.org>

On 07/29/2013 09:06 PM, Richard Zhao wrote:
> On Sat, Jul 27, 2013 at 03:27:58AM +0800, Stephen Warren wrote:
>> (Stripping the Cc list a lot)
>>
>> On 07/23/2013 10:09 PM, Richard Zhao wrote:
>>> Update tegra20-apbdma driver to adopt generic DMA device tree bindings.
>>> It calls of_dma_controller_register() with of_dma_simple_xlate to get
>>> the generic DMA device tree helper support. The #dma-cells for apbdma
>>> must be 1, which is slave ID.
>>>
>>> The existing nvidia,dma-request-selector still works there, and the
>>> support will be removed after all clients get converted to generic DMA
>>> device tree helper.

>>> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
>>
>>> +static bool tegra_dma_filter_fn(struct dma_chan *dc, void *param)
>>> +{
>>> +	if (dc->device->dev->driver == &tegra_dmac_driver.driver) {
>>> +		struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
>>> +		unsigned req = *(unsigned *)param;
>>> +
>>> +		tdc->slave_id = req;
>>> +
>>> +		return true;
>>> +	}
>>> +	return false;
>>> +}
>>> +
>>> +static struct of_dma_filter_info tegra_dma_info = {
>>> +	.filter_fn = tegra_dma_filter_fn,
>>> +};
>>
>> Why does this driver need to define a filter function? I thought the
>> dmaengine's DT support would already match DMA clients/engines based on
>> the phandle in DT? Isn't the need to pass the slave channel ID into
>> drivers something pretty fundamental to dmaengine, and hence something
>> it already supports?
>
> of_dma_simple_xlate only pass slave id to filter function. It needs
> change to pass dt node too. I didn't start work on the common code
> change yet. Do you think we need to hold it until common code change?

Oh dear, I can't see how the core DT DMA support can work for anyone
without the ability to limit DMA clients to the specific DMA controller
that's specified in DT. If that functionality truly is missing, then it
certainly needs to be added first.


From swarren at wwwdotorg.org  Tue Jul 30 12:44:46 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 10:44:46 -0600
Subject: [PATCH 3/9] spi: tegra114: move to generic dma DT binding
In-Reply-To: <20130730031536.GK15855@rizhao-lap>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-4-git-send-email-rizhao@nvidia.com>
 <51F2CF53.30002@wwwdotorg.org> <20130730031536.GK15855@rizhao-lap>
Message-ID: <51F7ED7E.5070000@wwwdotorg.org>

On 07/29/2013 09:15 PM, Richard Zhao wrote:
> On Sat, Jul 27, 2013 at 03:34:43AM +0800, Stephen Warren wrote:
>> (Stripping CC list a bit)
>>
>> On 07/23/2013 10:09 PM, Richard Zhao wrote:
>>> - driver: remove use of nvidia,dma-request-selector
>>> 	  use dma_request_slave_channel to request channel
>>> - if dmas/dma-names are missing, it still supports cpu based transfer
>>> - update binding doc and specify dmas/dma-names properties as optional

>>> diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
>>
>>> +Optional properties:
>>> +- dmas : The Tegra DMA controller's phandle and request selector for
>>> +  this SPI controller.
>>> +- dma-names : Should be "rx-tx".
>>
>> This should reference dma.txt which defines the DMA DT bindings. How about:
>>
>> ----------
>> Optional properties:
>> - dmas, dma-names : The DMA channel to use for DMA-mode operation. See
>>   dma.txt for the definition of these properties. A single entry named
>>   "rx-tx" must be specified.
>> ----------
> Ok. but how about replace "DMA channel" with "DMA request"?

Sure.



From swarren at wwwdotorg.org  Tue Jul 30 12:46:42 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 10:46:42 -0600
Subject: [PATCH 6/9] serial: tegra: move to generic dma DT binding
In-Reply-To: <20130730033134.GM15855@rizhao-lap>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-7-git-send-email-rizhao@nvidia.com>
 <51F2D063.5010505@wwwdotorg.org> <20130730033134.GM15855@rizhao-lap>
Message-ID: <51F7EDF2.60700@wwwdotorg.org>

On 07/29/2013 09:31 PM, Richard Zhao wrote:
> On Sat, Jul 27, 2013 at 03:39:15AM +0800, Stephen Warren wrote:
>> On 07/23/2013 10:09 PM, Richard Zhao wrote:
>>> - driver: remove use of nvidia,dma-request-selector
>>> 	  use dma_request_slave_channel to request channel
>>> - update binding doc
>>
>> This patch needs to be amended so that the DMA channel is looked up
>> during probe() rather than open(), to guarantee that deferred probe
>> works. It's possible to hold off probe, but not possible AFAIK to hold
>> off opening the port.
>
> How about avoid return -EPROBE_DEFER at open() time? It can be in
> another patch.

I don't really understand what you mean. -EPROBE_DEFER is something that
only makes sense for probe() to return (or functions used by probe()).
It doesn't make sense to return it anywhere else, since probe deferral
is something that can only happen for probe().


From swarren at wwwdotorg.org  Tue Jul 30 12:49:05 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 10:49:05 -0600
Subject: [PATCH 1/9] ARM: dts: add generic DMA DT binding for tegra apbdma
In-Reply-To: <20130730025448.GI15855@rizhao-lap>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-2-git-send-email-rizhao@nvidia.com>
 <51F2CC30.5090200@wwwdotorg.org> <20130730025448.GI15855@rizhao-lap>
Message-ID: <51F7EE81.1060105@wwwdotorg.org>

On 07/29/2013 08:54 PM, Richard Zhao wrote:
> On Sat, Jul 27, 2013 at 03:21:20AM +0800, Stephen Warren wrote:
>> (Stripping the Cc list a lot, but adding in the DT binding maintainers)
>>
>> On 07/23/2013 10:09 PM, Richard Zhao wrote:
>>> All Tegra device drivers will soon move to generic DMA device tree bindings.
>>> Add the required properties to the Tegra DT files to support that. The legacy
>>> property nvidia,dma-request-selector will be removed after all drivers have
>>> been converted, in order to maintain bisectability.
>>>
>>> Changes:
>>>  - Add '#dma-cells' for apbdma nodes
>>>  - And properties 'dmas' and 'dma-names' for apbdma client nodes
>>>  - update apbdma DT binding doc
>>>
>>> Signed-off-by: Richard Zhao <rizhao at nvidia.com>
>>> ---
>>>  .../devicetree/bindings/dma/tegra20-apbdma.txt     |  1 +
>>>  arch/arm/boot/dts/tegra114.dtsi                    | 27 ++++++++++++++++++++++
>>>  arch/arm/boot/dts/tegra20.dtsi                     | 27 ++++++++++++++++++++++
>>>  arch/arm/boot/dts/tegra30.dtsi                     | 25 ++++++++++++++++++++
>>
>> This patch should be split differently.
>>
>> Patch 1 in the series should include the binding document change and the
>> associated DMA driver change, which will support both the old and new
>> bindings.
>>
>> Patch 2 should contain the *.dtsi changes.
>
> The reason I update apbdma binding doc here is to make it consistent
> with the mass properties added in dtsi files.
> apbdma has less places of changes than dtsi files.

It'll still be consistent if you update the binding documentation first,
then update the *.dtsi to conform to the new binding docs. It won't
affect the number of changes.


From swarren at wwwdotorg.org  Tue Jul 30 12:54:58 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 10:54:58 -0600
Subject: [PATCH 7/9] ASoC: tegra: move to generic DMA DT binding
In-Reply-To: <20130730101221.GO15855@rizhao-lap>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-8-git-send-email-rizhao@nvidia.com>
 <51F2D4DD.9060308@wwwdotorg.org> <20130730101221.GO15855@rizhao-lap>
Message-ID: <51F7EFE2.6020106@wwwdotorg.org>

On 07/30/2013 04:12 AM, Richard Zhao wrote:
> On Sat, Jul 27, 2013 at 03:58:21AM +0800, Stephen Warren wrote:
>> On 07/23/2013 10:10 PM, Richard Zhao wrote:
>>> - add tegra_dma_filter_data to specify dma info
>>>   DMA DT binding needs the device that raise dma request and dma name
>>>   to request a dma channel. tegra30_i2s is a special case. It should be ahub
>>>   device and it also has dma name that cannot handled by ASoC dmaengine code.
>>>   So we pass the info using filter data in snd_dmaengine_dai_dma_data.
>>> - change i2s/ac97 drivers to use generic DT binding
>>> - tegra30_i2s: alloc ahub tx/rx fifo at driver probe time
>>
>>> diff --git a/sound/soc/tegra/tegra30_i2s.c b/sound/soc/tegra/tegra30_i2s.c
>>
>> I don't understand why the FIFO alloc/free had to move from
>> startup()/shutdown() to probe()/remove().
> 
> The call path is:
> [<c0520e38>] (dump_stack+0x78/0xbc) from [<c03bb854>] (tegra_pcm_request_chan+0x10/0x34)
> [<c03bb854>] (tegra_pcm_request_chan+0x10/0x34) from [<c03b6c2c>] (dmaengine_pcm_new+0xe0/0x134)
> [<c03b6c2c>] (dmaengine_pcm_new+0xe0/0x134) from [<c03b5824>] (soc_new_pcm+0x2f0/0x3cc)
> [<c03b5824>] (soc_new_pcm+0x2f0/0x3cc) from [<c03aa1a0>] (soc_probe_link_dais+0x358/0x39c)
> [<c03aa1a0>] (soc_probe_link_dais+0x358/0x39c) from [<c03ab334>] (snd_soc_instantiate_card+0x35c/0x7a0)
> [<c03ab334>] (snd_soc_instantiate_card+0x35c/0x7a0) from [<c03ab9dc>] (snd_soc_register_card+0x264/0x330)
> [<c03ab9dc>] (snd_soc_register_card+0x264/0x330) from [<c03be350>] (tegra_rt5640_probe+0xf4/0x17c)
> [<c03be350>] (tegra_rt5640_probe+0xf4/0x17c) from [<c0294290>] (platform_drv_probe+0x18/0x1c)
> 
> So I need to request dma channel at probe time.

The AHUB driver should look up and cache the DMA channel information
during its probe() call, and defer probe() there if necessary.

The FIFO alloc/free calls should simply use the cached information for
the allocated channel.

That way, the changes are isolated in the AHUB driver and shouldn't
require any changes in the I2S driver.

The DT parsing and DMA request lookup will then happen well before the
snd_soc_instantiate_card() backtrace you mention above, since it will
prevent the card from being instantiated until all the ASoC components
are fully probed.

>> This will prevent later
>> changes from making the connectivity between the AHUB FIFOs and I2S
>> modules more dynamic, which is kind of the whole point of the AHUB HW
>> module.
> 
> That's because it's i2s driver to register pcm device rather not ahub.
> Ideally dma channel is only bound to ahub.

Long-term, this should change. However, I believe if you make the
changes I mention above, this won't be an issue.

>>> diff --git a/sound/soc/tegra/tegra_pcm.h b/sound/soc/tegra/tegra_pcm.h
>>
>>> +#define TEGRA_DMA_NAME_MAX_LEN	10
>>> +
>>> +/*
>>> + * Generic DMA DT binding needs the device that raise dma request and dma name
>>> + * to request a dma channel. tegra30_i2s is a special case. It should be ahub
>>> + * device and it also has dma name that cannot handled by ASoC dmaengine code.
>>> + * So we pass the info using filter data in snd_dmaengine_dai_dma_data.
>>> + */
>>> +struct tegra_dma_filter_data {
>>> +	struct device *dma_dev;
>>> +	char dma_name[TEGRA_DMA_NAME_MAX_LEN];
>>> +};
>>
>> I agree with Lars-Peter's comment that it'd be better to enhance the
>> ASoC dmaengine support to allow the channel name to be specified so we
>> don't need to much custom code.
> 
> Not only dma-name but also dma client device for this case.
> 
>> And that should use "char *" not a
>> fixed-length array.
>
> Ok, then there' two solutions.
> 
> struct tegra30_i2s {
> ...
>         struct snd_dmaengine_dai_dma_data capture_dma_data;
>         char dma_rx_name[10];
>         struct tegra_dma_filter_data filter_data_rx;
> ...
>         struct snd_dmaengine_dai_dma_data playback_dma_data;
>         char dma_tx_name[10];
>         struct tegra_dma_filter_data filter_data_tx;
> };
> 
> probe: i2s->filter_data_rx.dma_name = i2s.dma_rx_name
> 
> or
> 
> probe: i2s->filter_data_rx.dma_name = kasprintf(GFP_KERNEL, "channel%d" ...);
> remove: kfree(i2s->filter_data_rx.dma.name)
> 
> Which one do you like?

Either is fine, although the first option has less dynamic allocation,
so is probably better. The AHUB driver should be constructing the
channel names though.


From swarren at wwwdotorg.org  Tue Jul 30 12:57:12 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 10:57:12 -0600
Subject: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
In-Reply-To: <CALicx6s5NX9ZaEiiGo1A=jT+o7Lpj8Y4ubkHeeK2p3DmZpwQeg@mail.gmail.com>
References: <1374817287-27952-1-git-send-email-vijay.kilari@gmail.com>
 <51F2AC53.3070607@wwwdotorg.org>
 <CALicx6s5NX9ZaEiiGo1A=jT+o7Lpj8Y4ubkHeeK2p3DmZpwQeg@mail.gmail.com>
Message-ID: <51F7F068.8060509@wwwdotorg.org>

On 07/30/2013 04:05 AM, Vijay Kilari wrote:
> On Fri, Jul 26, 2013 at 10:35 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 07/25/2013 11:41 PM, vijay.kilari at gmail.com wrote:
>>> From: Vijaya Kumar K <Vijaya.Kumar at caviumnetworks.com>
>>>
>>> In case of normal kexec kernel load, all cpu's are offlined
>>> before calling machine_kexec() under kernel_kexec() function.
>>
>> I'm not sure that's true, unless perhaps you have CONFIG_KEXEC_JUMP enabled?
>>
>>> But in case crash panic cpus are relaxed in
>>> machine_crash_nonpanic_core() SMP function but not offlined.
>>>
>>> When crash kernel is loaded with kexec and on panic trigger
>>> machine_kexec() checks for number of cpus online.
>>> If more than one cpu is online machine_kexec() fails to load
>>> with below error
>>>
>>> kexec: error: multiple CPUs still online
>>>
>>> In machine_crash_nonpanic_core() SMP function, offline CPU
>>> before cpu_relax
>>
>>> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
>>
>>> @@ -73,6 +73,7 @@ void machine_crash_nonpanic_core(void *unused)
>>>       crash_save_cpu(&regs, smp_processor_id());
>>>       flush_cache_all();
>>>
>>> +     set_cpu_online(smp_processor_id(), false);
>>
>> I'm not familiar with that API, but it looks like it's just setting the
>> *current* CPU offline. That sounds problematic for two reasons:
>>
>> 1) Setting the current CPU offline sounds like a bad idea; after all,
>> code is still running on it. Presumably you want to offline all other CPUs.
>>
>    machine_crash_nonpanic_core() is a SMP call (smp_call_function) .
>    Setting cpu offline is called for all other CPUs except the caller.

Ah OK, that's what I was missing. This makes sense then.


From swarren at wwwdotorg.org  Tue Jul 30 12:59:13 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 10:59:13 -0600
Subject: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
In-Reply-To: <CALicx6ugumPG__rSAsTS95SH=6fTGqhpPFsQ8bLG-u-fbk0=pQ@mail.gmail.com>
References: <1374817287-27952-1-git-send-email-vijay.kilari@gmail.com>
 <20130726104908.GC17886@mudshark.cambridge.arm.com>
 <51F2ACF7.9000008@wwwdotorg.org>
 <CALicx6ugumPG__rSAsTS95SH=6fTGqhpPFsQ8bLG-u-fbk0=pQ@mail.gmail.com>
Message-ID: <51F7F0E1.5030200@wwwdotorg.org>

On 07/30/2013 04:37 AM, Vijay Kilari wrote:
> On Fri, Jul 26, 2013 at 10:38 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
...
>> Does a kernel that's used as the crash kernel guarantee:
>>
>> * Never to re-use the memory that was used by the previous kernel, so
>> that the spin loop code/data won't be corrupted, ever, no matter how
>> long the crash recovery kernel runs.
>>
>> * Not use SMP, so there's never a need to re-activate the non-boot CPUs,
>> which might not work if they aren't truly disabled but rather just
>> running a pin loop?
> 
> From cat /proc/iomem, normal kernel is executed from (0x80xxxxxx) with crash
> kernel reserved 64M at 0xa0000000
> 
> 80000000-bfffffff : System RAM
>   80008000-805aeddf : Kernel code
>   805e2000-8063e427 : Kernel data
>   a0000000-a3ffffff : Crash kernel
> 
> crash kernel is loaded to reserved memory location and is executed from there.
> I could confirm this from /proc/iomem when crash kernel is running
> 
> a0000000-a3efffff : System RAM
>   a0008000-a05aeddf : Kernel code
>   a05e2000-a063e427 : Kernel data

OK, but in the crash dump kernel, is 80008000..8063e427 reserved as
well, which would guarantee that the spin loop being executed by the
non-crash CPUs won't be corrupted?


From davidb at codeaurora.org  Tue Jul 30 13:17:52 2013
From: davidb at codeaurora.org (David Brown)
Date: Tue, 30 Jul 2013 10:17:52 -0700
Subject: [PATCH] mmc: sdhci-msm: Add support for MSM chipsets
In-Reply-To: <86y58orogf.fsf@void.printf.net>
References: <1375201355-26906-1-git-send-email-gdjakov@mm-sol.com>
 <86y58orogf.fsf@void.printf.net>
Message-ID: <20130730171752.GA30897@codeaurora.org>

On Tue, Jul 30, 2013 at 05:40:16PM +0100, Chris Ball wrote:

>On Tue, Jul 30 2013, Georgi Djakov wrote:
>> This platform driver adds the support of Secure Digital Host
>> Controller Interface compliant controller in MSM chipsets.
>>
>> CC: Asutosh Das <asutoshd at codeaurora.org>
>> CC: Venkat Gopalakrishnan <venkatg at codeaurora.org>
>> CC: Sahitya Tummala <stummala at codeaurora.org>
>> CC: Subhash Jadavani <subhashj at codeaurora.org>
>> Signed-off-by: Georgi Djakov <gdjakov at mm-sol.com>
>> ---
>> This is an initial version of the Qualcomm MSM SDHCI driver.
>> It is based on the SDHCI code from coreaurora.org with minor
>> modifications. The MMC standard DT bindings are used where
>> possible. The patch applies to v3.11-rc3.
>
>Is the arch code that will use this driver already in mainline,
>or on its way in?

It is on it's way.  Once all of the necessary Acks are in place, I'll
be pulling it in.

David

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From swarren at wwwdotorg.org  Tue Jul 30 13:19:18 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 11:19:18 -0600
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
Message-ID: <51F7F596.6020503@wwwdotorg.org>

On 07/30/2013 07:14 AM, jonsmirl at gmail.com wrote:
> On Tue, Jul 30, 2013 at 6:25 AM, Mark Brown <broonie at kernel.org> wrote:
>> On Mon, Jul 29, 2013 at 08:30:29PM -0400, jonsmirl at gmail.com wrote:
>>
>>> This...
>>> tx-dma-channel = <&pdma0 7>; /* preliminary */
>>> rx-dma-channel = <&pdma0 6>; /* preliminary */
>>
>>> Probably should be
>>> dmas = <&pdma0 7>,<&pdma0 6>;
>>> dma-names = "tx", "rx";
>>
>> It should be - the latter is the generic DMA binding.  There's a lot of
>> bindings in the kernel that predate that but people are currently
>> working to transfer over, this is one of the examples of instability
>> that everyone is talking about.
> 
> Is something similar to this possible in device tree syntax?
> dmas =  <"tx" &pdma0 7>,  <"rx"  &pdma0 6>;

I /think/ you can physically write that in *.dts, or something very
similar; with the strings outside the <>:

dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;

However, there's been strong push-back (i.e. doing that has not been
allowed at all) on attempting to mix variable-length strings and
fixed-length/alignment integer cells in the same property. This is
primarily because you then can't ensure that the integer cell data is
aligned in the DTB (dtc and/or the DTB format spec does/requires/allows
no alignment padding), and hence have to be much more careful about data
alignment when parsing the property.


From broonie at kernel.org  Tue Jul 30 13:24:13 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 18:24:13 +0100
Subject: [PATCH 0/5] Optional regulator support
In-Reply-To: <864nbcte4j.fsf@void.printf.net>
References: <20130730114502.GQ9858@sirena.org.uk>
 <864nbcte4j.fsf@void.printf.net>
Message-ID: <20130730172413.GW9858@sirena.org.uk>

On Tue, Jul 30, 2013 at 01:40:28PM +0100, Chris Ball wrote:
> On Tue, Jul 30 2013, Mark Brown wrote:

> > Right now all the MMC users are converted over as-is, though it does
> > look like drivers such as sdhci really ought to be insisting on having a
> > regulator for VMMC in the same way that the MMC core helper does (and
> > indeed in that case it looks like it ought to be converted over to the
> > core code).

> I didn't follow this part -- I don't think the MMC core insists on a
> VMMC regulator, and I don't think sdhci should either, because e.g.
> an x86 laptop isn't going to have one.  What am I missing?

You're missing the fact that there will be a VMMC regulator there since
the card needs power to function, it just might not be one that software
knows about or can control.  If it's one that software can control
that's not mapped in properly (eg, because the driver for the regulator
wasn't loaded) then obviously that's a serious problem and power saving
features in the regulator API may for example turn off the supply even
if it's on by default since they can't tell it's in use.

As things stand the expectation for x86 type systems is that MMC
controllers attached via PCI or USB ought to be setting up a fixed
regulator so that the consumer part can proceed without ignoring errors
that might be serious on other systems.  It's probably not a bad idea to
do this anyway though hopefully in the future this work will make it
less needed.  For embedded systems the system integration ought to be
doing the same thing, normally as part of the configuration of the PMIC.

The goal of this series is to make it much easier for the regulator core
to transparently support such systems where the regulators aren't
visible to software by transparently stubbing out normal supplies that
really must be present somehow for the hardware to operate without
confusing things by also stubbing out suppies that may be missing in
normal operation.  This is the problem for the existing stubbing support
- it works well for normal supplies but it means that any consumer that
wants to handle a supply that's not there can't tell it's missing.
-------------- 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/20130730/60357bc9/attachment-0001.sig>

From coelho at ti.com  Tue Jul 30 13:27:24 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 20:27:24 +0300
Subject: [PATCH 0/4] ARM: dts: add WiLink support to panda and omap4-sdp
Message-ID: <1375205248-25708-1-git-send-email-coelho@ti.com>

Hi,

These patches add the necessary DT configuration to use the WLAN part
of WiLink on OMAP4 Pandaboard and on OMAP4-SDP (including Blaze).

I've tested these changes on Panda and it works fine.  But I couldn't
test the OMAP4 SDP changes properly on 3.11-rc3 because I'm having
problems with clocks and SDIO stuff.  So it's pretty much just
compiled tested.  I've tried this (without the new clock definition
stuff) on Blaze with 3.10 and it was working, though.

Please take a look and let me know what you think.

Luca.


Luciano Coelho (4):
  ARM: dts: omap4-panda: add MMC5 (WiLink WLAN) configuration
  arm: dts: omap4-panda-common: add WiLink6 device tree nodes
  ARM: dts: omap4-sdp: add MMC5 (WiLink WLAN) configuration
  arm: dts: omap4-sdp: add WiLink7 device tree node

 arch/arm/boot/dts/omap4-panda-common.dtsi | 45 +++++++++++++++++++++++++++-
 arch/arm/boot/dts/omap4-sdp.dts           | 49 +++++++++++++++++++++++++++++++
 2 files changed, 93 insertions(+), 1 deletion(-)

-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 13:27:26 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 20:27:26 +0300
Subject: [PATCH 2/4] arm: dts: omap4-panda-common: add WiLink6 device tree
 nodes
In-Reply-To: <1375205248-25708-1-git-send-email-coelho@ti.com>
References: <1375205248-25708-1-git-send-email-coelho@ti.com>
Message-ID: <1375205248-25708-3-git-send-email-coelho@ti.com>

Add the WiLink device tree nodes.  On omap4-panda, a WiLink6 module is
connected on MMC5 and a GPIO interrupt is used.  The refclock
frequency is 38.4MHz.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 arch/arm/boot/dts/omap4-panda-common.dtsi | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index b3f6e1f..77e4a42 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -117,6 +117,20 @@
 		startup-delay-us = <70000>;
 		enable-active-high;
 	};
+
+	wlan {
+		compatible = "ti,wilink6";
+		interrupt-parent = <&gpio2>;
+		interrupts = <21 0x4>;	/* gpio line 53, high level triggered */
+		clocks = <&refclock>;
+		clock-names = "refclock";
+
+		refclock: refclock {
+			compatible = "ti,wilink-clock";
+			#clock-cells = <0>;
+			clock-frequency = <38400000>;
+		};
+	 };
 };
 
 &omap4_pmx_wkup {
-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 13:27:27 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 20:27:27 +0300
Subject: [PATCH 3/4] ARM: dts: omap4-sdp: add MMC5 (WiLink WLAN) configuration
In-Reply-To: <1375205248-25708-1-git-send-email-coelho@ti.com>
References: <1375205248-25708-1-git-send-email-coelho@ti.com>
Message-ID: <1375205248-25708-4-git-send-email-coelho@ti.com>

Add regulator, pin muxing and MMC5 configuration to be used by the
on-board WiLink6 module.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 arch/arm/boot/dts/omap4-sdp.dts | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..3845615 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -140,6 +140,16 @@
 			"DMic", "Digital Mic",
 			"Digital Mic", "Digital Mic1 Bias";
 	};
+
+	wilink_wl_en: fixedregulator at 1 {
+		compatible = "regulator-fixed";
+		regulator-name = "wilink_wl_en";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		gpio = <&gpio2 22 0>; /* gpio line 54 */
+		startup-delay-us = <70000>;
+		enable-active-high;
+	};
 };
 
 &omap4_pmx_wkup {
@@ -166,6 +176,7 @@
 			&mcbsp2_pins
 			&dss_hdmi_pins
 			&tpd12s015_pins
+			&wilink_pins
 	>;
 
 	uart2_pins: pinmux_uart2_pins {
@@ -295,6 +306,19 @@
 			0xf0 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c4_sda */
 		>;
 	};
+
+	wilink_pins: pinmux_wilink_pins {
+		pinctrl-single,pins = <
+			0x7a 0x103      /* gpio_53  INPUT | MODE3 */
+			0x7c 0x3	/* gpio_54  OUTPUT | MODE3 */
+			0x148 0x118     /* clk	    INPUT PULLUP | MODE0 */
+			0x14a 0x118     /* cmd	    INPUT PULLUP | MODE0 */
+			0x14c 0x118     /* dat0	    INPUT PULLUP | MODE0 */
+			0x14e 0x118     /* dat1	    INPUT PULLUP | MODE0 */
+			0x150 0x118     /* dat2	    INPUT PULLUP | MODE0 */
+			0x152 0x118     /* dat3	    INPUT PULLUP | MODE0 */
+		>;
+	};
 };
 
 &i2c1 {
@@ -420,8 +444,13 @@
 };
 
 &mmc5 {
+	status = "okay";
+	vmmc-supply = <&wilink_wl_en>;
 	bus-width = <4>;
+	cap-power-off-card;
+	keep-power-in-suspend;
 	ti,non-removable;
+	ti,needs-special-hs-handling;
 };
 
 &emif1 {
-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 13:27:25 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 20:27:25 +0300
Subject: [PATCH 1/4] ARM: dts: omap4-panda: add MMC5 (WiLink WLAN)
 configuration
In-Reply-To: <1375205248-25708-1-git-send-email-coelho@ti.com>
References: <1375205248-25708-1-git-send-email-coelho@ti.com>
Message-ID: <1375205248-25708-2-git-send-email-coelho@ti.com>

Add regulator, pin muxing and MMC5 configuration to be used by the
on-board WiLink6 module.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 arch/arm/boot/dts/omap4-panda-common.dtsi | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..b3f6e1f 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -107,6 +107,16 @@
 	 */
 		clock-frequency = <19200000>;
 	};
+
+	wilink_wl_en: fixedregulator at 1 {
+		compatible = "regulator-fixed";
+		regulator-name = "wilink_wl_en";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		gpio = <&gpio2 11 0>; /* gpio line 43 */
+		startup-delay-us = <70000>;
+		enable-active-high;
+	};
 };
 
 &omap4_pmx_wkup {
@@ -132,6 +142,7 @@
 			&dss_hdmi_pins
 			&tpd12s015_pins
 			&hsusbb1_pins
+			&wilink_pins
 	>;
 
 	twl6030_pins: pinmux_twl6030_pins {
@@ -235,6 +246,19 @@
 			0x1c (PIN_OUTPUT | MUX_MODE3)	/* gpio_wk8 */
 		>;
 	};
+
+	wilink_pins: pinmux_wilink_pins {
+		pinctrl-single,pins = <
+			0x7a 0x103      /* gpio_53  INPUT | MODE3 */
+			0x66 0x3	/* gpio_43  OUTPUT | MODE3 */
+			0x148 0x118     /* clk	    INPUT PULLUP | MODE0 */
+			0x14a 0x118     /* cmd	    INPUT PULLUP | MODE0 */
+			0x14c 0x118     /* dat0	    INPUT PULLUP | MODE0 */
+			0x14e 0x118     /* dat1	    INPUT PULLUP | MODE0 */
+			0x150 0x118     /* dat2	    INPUT PULLUP | MODE0 */
+			0x152 0x118     /* dat3	    INPUT PULLUP | MODE0 */
+		>;
+	};
 };
 
 &i2c1 {
@@ -314,8 +338,13 @@
 };
 
 &mmc5 {
-	ti,non-removable;
+	status = "okay";
+	vmmc-supply = <&wilink_wl_en>;
 	bus-width = <4>;
+	cap-power-off-card;
+	keep-power-in-suspend;
+	ti,non-removable;
+	ti,needs-special-hs-handling;
 };
 
 &emif1 {
-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 13:27:28 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 20:27:28 +0300
Subject: [PATCH 4/4] arm: dts: omap4-sdp: add WiLink7 device tree node
In-Reply-To: <1375205248-25708-1-git-send-email-coelho@ti.com>
References: <1375205248-25708-1-git-send-email-coelho@ti.com>
Message-ID: <1375205248-25708-5-git-send-email-coelho@ti.com>

Add appropriate device tree node for Blaze's WiLink7 module.  It uses
a GPIO as interrupt, so configure the gpio2 node as interrupt parent
and assign the corresponding GPIO.  Additionally, add the clock
frequencies used by the module.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 arch/arm/boot/dts/omap4-sdp.dts | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 3845615..2fecca1 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -150,6 +150,26 @@
 		startup-delay-us = <70000>;
 		enable-active-high;
 	};
+
+	wlan {
+		compatible = "ti,wilink7";
+		interrupt-parent = <&gpio2>;
+		interrupts = <21 0x4>;	/* gpio line 53, high level triggered */
+		clocks = <&refclock &tcxoclock>;
+		clock-names = "refclock tcxoclock";
+
+		refclock: refclock {
+			compatible = "ti,wilink-clock";
+			#clock-cells = <0>;
+			clock-frequency = <26000000>;
+		};
+
+		tcxoclock: tcxoclock {
+			compatible = "ti,wilink-clock";
+			#clock-cells = <0>;
+			clock-frequency = <26000000>;
+		};
+	 };
 };
 
 &omap4_pmx_wkup {
-- 
1.8.3.2



From jonsmirl at gmail.com  Tue Jul 30 13:29:56 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Tue, 30 Jul 2013 13:29:56 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <51F7F596.6020503@wwwdotorg.org>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
Message-ID: <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>

On Tue, Jul 30, 2013 at 1:19 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>
> On 07/30/2013 07:14 AM, jonsmirl at gmail.com wrote:
> > On Tue, Jul 30, 2013 at 6:25 AM, Mark Brown <broonie at kernel.org> wrote:
> >> On Mon, Jul 29, 2013 at 08:30:29PM -0400, jonsmirl at gmail.com wrote:
> >>
> >>> This...
> >>> tx-dma-channel = <&pdma0 7>; /* preliminary */
> >>> rx-dma-channel = <&pdma0 6>; /* preliminary */
> >>
> >>> Probably should be
> >>> dmas = <&pdma0 7>,<&pdma0 6>;
> >>> dma-names = "tx", "rx";
> >>
> >> It should be - the latter is the generic DMA binding.  There's a lot of
> >> bindings in the kernel that predate that but people are currently
> >> working to transfer over, this is one of the examples of instability
> >> that everyone is talking about.
> >
> > Is something similar to this possible in device tree syntax?
> > dmas =  <"tx" &pdma0 7>,  <"rx"  &pdma0 6>;
>
> I /think/ you can physically write that in *.dts, or something very
> similar; with the strings outside the <>:
>
> dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
>
> However, there's been strong push-back (i.e. doing that has not been
> allowed at all) on attempting to mix variable-length strings and
> fixed-length/alignment integer cells in the same property. This is
> primarily because you then can't ensure that the integer cell data is
> aligned in the DTB (dtc and/or the DTB format spec does/requires/allows

Can we turn the strings into string phandles? Then they'd be fixed sized.

That might provide a way to internationalize the strings too.


>
> no alignment padding), and hence have to be much more careful about data
> alignment when parsing the property.




-- 
Jon Smirl
jonsmirl at gmail.com


From linville at tuxdriver.com  Tue Jul 30 13:27:19 2013
From: linville at tuxdriver.com (John W. Linville)
Date: Tue, 30 Jul 2013 13:27:19 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <51F7EA35.6070501@wwwdotorg.org>
References: <2460092.aLmjrOVh1g@flatron> <51F3A82E.2000907@broadcom.com>
 <CACxGe6t0C7PTiDDaFkgoMZWUpBVokasxwZpV6HEtf3LaPi4qUw@mail.gmail.com>
 <CAKON4OymA55w_V=oP4BL2su84m8EnPgdhnQtyLWKaAJE-yNBkQ@mail.gmail.com>
 <CACxGe6uE6jOE-vz0onW5h93Es-soGiBAcFBM7Dvxh+HvCNrHkw@mail.gmail.com>
 <CACxGe6vw9=y5a+EgF1gO39SwGAdGofD2MYjyJ3jYu6uN3ke70A@mail.gmail.com>
 <1374988276.1973.29.camel@dabdike>
 <20130730014453.GJ29970@voom.fritz.box>
 <CAKON4OyWuF+qm2MAhbXnGg=ozzw37kpSWciLxyUy+QQzxoWdxQ@mail.gmail.com>
 <51F7EA35.6070501@wwwdotorg.org>
Message-ID: <20130730172718.GA2509@tuxdriver.com>

On Tue, Jul 30, 2013 at 10:30:45AM -0600, Stephen Warren wrote:
> On 07/29/2013 08:15 PM, jonsmirl at gmail.com wrote:
> > On Mon, Jul 29, 2013 at 9:44 PM, David Gibson
> > <david at gibson.dropbear.id.au> wrote:
> ...
> >> I also think we should consider the option of having a simple and
> >> straightforward schema language which handles, say, 80% of cases with
> >> a fall back to C for the 20% of curly cases.  That might actually be
> >> simpler to work with in practice than a schema language which can
> >> express absolutely anything, at the cost of being awkward for simple
> >> cases or difficult to get your head around.
> > 
> > Would C++ work? You can use operating overloading and templates to
> > change the syntax into something that doesn't even resemble C any
> > more.
> 
> From my perspective, that's precisely why C++ should /not/ be used.

Amen.

-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.


From swarren at wwwdotorg.org  Tue Jul 30 13:34:12 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 11:34:12 -0600
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
Message-ID: <51F7F914.6040709@wwwdotorg.org>

On 07/30/2013 11:29 AM, jonsmirl at gmail.com wrote:
> On Tue, Jul 30, 2013 at 1:19 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>
>> On 07/30/2013 07:14 AM, jonsmirl at gmail.com wrote:
>>> On Tue, Jul 30, 2013 at 6:25 AM, Mark Brown <broonie at kernel.org> wrote:
>>>> On Mon, Jul 29, 2013 at 08:30:29PM -0400, jonsmirl at gmail.com wrote:
>>>>
>>>>> This...
>>>>> tx-dma-channel = <&pdma0 7>; /* preliminary */
>>>>> rx-dma-channel = <&pdma0 6>; /* preliminary */
>>>>
>>>>> Probably should be
>>>>> dmas = <&pdma0 7>,<&pdma0 6>;
>>>>> dma-names = "tx", "rx";
>>>>
>>>> It should be - the latter is the generic DMA binding.  There's a lot of
>>>> bindings in the kernel that predate that but people are currently
>>>> working to transfer over, this is one of the examples of instability
>>>> that everyone is talking about.
>>>
>>> Is something similar to this possible in device tree syntax?
>>> dmas =  <"tx" &pdma0 7>,  <"rx"  &pdma0 6>;
>>
>> I /think/ you can physically write that in *.dts, or something very
>> similar; with the strings outside the <>:
>>
>> dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
>>
>> However, there's been strong push-back (i.e. doing that has not been
>> allowed at all) on attempting to mix variable-length strings and
>> fixed-length/alignment integer cells in the same property. This is
>> primarily because you then can't ensure that the integer cell data is
>> aligned in the DTB (dtc and/or the DTB format spec does/requires/allows
> 
> Can we turn the strings into string phandles? Then they'd be fixed sized.

I believe that phandles point at nodes not arbitrary data, so no.

Now, could the DTB format be enhanced to allow that? Perhaps, although
we'd need a different string syntax to enable it, since existing
bindings would require the current inline-string format. That's getting
outside the realm of schemas and making active changes to the DT format
though...

> That might provide a way to internationalize the strings too.

I don't think internationalization is needed; DT is an interface to
drivers/SW, rather than something end-user-visible.


From hartleys at visionengravers.com  Tue Jul 30 13:35:47 2013
From: hartleys at visionengravers.com (H Hartley Sweeten)
Date: Tue, 30 Jul 2013 12:35:47 -0500
Subject: [PATCH v2 00/13] Remove platform callbacks from mmc_spi,
 sh_mmcif and sh_mobile_sdhi drivers
In-Reply-To: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375180657-23641-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <ADE657CA350FB648AAC2C43247A983F0021DAC5C24E0@AUSP01VMBX24.collaborationhost.net>

On Tuesday, July 30, 2013 3:37 AM, Laurent Pinchart wrote:
>
> This patch set replaces callbacks to board code with regulators and GPIOs in
> the mmc_spi, sh_mmcif and sh_mobile_sdhi MMC drivers.

Just tested this series on the vision_ep93xx board. Everything looks ok.

For patches 01/13, 02/13 and 07/13 you can add:

Reviewed-by: H Hartley Sweeten <hsweeten at visionengravers.com>

For patch 03/13:

Acked-by: H Hartley Sweeten <hsweeten at visionengravers.com>

> This will be a bit messy to merge, as the series interleaves patches for
> drivers and board files. Given that the mmc_spi driver is marked as orphan in
> MAINTAINERS and that the vision_ep9307 hasn't seen any board-specific
> modification in the last couple of kernel versions one option would be to
> merge all patches (or at least patches 01/13 to 07/13) through Simon's tree if
> all involved maintainers agree.
>
> If patch 01/13 should better be merged through the MMC tree (in which case
> 02/13 should go through that tree as well), the two patches should be applied
> first to the MMC tree, and a stable branch will be needed for Simon to base
> the rest of the series on.

I'm fine with whatever merge path you end up using. I don't currently have
any changes planned to vision_ep93xx.

Thanks,
Hartley




From oliver+list at schinagl.nl  Tue Jul 30 13:39:03 2013
From: oliver+list at schinagl.nl (Oliver Schinagl)
Date: Tue, 30 Jul 2013 19:39:03 +0200
Subject: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner's
 Security ID fuses
In-Reply-To: <20130730142047.GA28696@kroah.com>
References: <20130626175144.GC2222@kroah.com> <51D674BF.9030207@schinagl.nl>
 <20130706193646.GB9778@kroah.com> <51E466A3.4010503@schinagl.nl>
 <20130716064107.GA10868@kroah.com> <20130717114650.GN3125@lukather>
 <20130717161758.GA9822@kroah.com> <20130719094211.GD5106@lukather>
 <20130719234944.GA11498@kroah.com> <51F7BE2F.3060004@schinagl.nl>
 <20130730142047.GA28696@kroah.com>
Message-ID: <51F7FA37.2010407@schinagl.nl>

On 30-07-13 16:20, Greg KH wrote:
> On Tue, Jul 30, 2013 at 03:22:55PM +0200, Oliver Schinagl wrote:
>>> Let me go look at how I can make this work "easier", give me a few days.
>> Not wanting to be rude, but it has been a little more then a few
>> days, any progress? Just want to know what I have to modify my
>> driver to so it can go into the next merge window :)
>
> What?  Oh crap.
>
> I saw this old email in my todo box last week and for some stupid reason
> I thought I had already taken care of this, otherwise why would I have
> left it around for so long?...
>
> Ugh, very sorry about that...
>
> Hm, this is a mess.  I hate platform devices...
>
> Anyway, as you want to get this into 3.12, and I'm not going to be able
> to get the core infrastructure into the platform device by then, just go
> ahead and do a sysfs_create_group() call in your device probe callback
> for now.  That will register the needed files for the device (not the
> driver, DOH that was stupid of me...) and all should be ok.
>
> Yes, you will still race with userspace, but as right now, there's no
> way that _any_ platform driver can do this "correctly", you will be in
> good company.  I'll clean up all platform drivers in a sweep of the tree
> after 3.12 or so when I get the needed infrastructure in place for the
> platform_driver code.
>
> Again, very sorry for all of this, you have helped me out a lot in
> figuring out that this is a mess, and should be fixed up better, but in
> the end, you are pretty much back at the beginning of what you
> originally wanted to do, right?
Alright, I'll modify it to use sysfs_create_group() and try to leave it 
as much as it is no to ease the transition.
>
> I owe you a beer, at the least, my apologies...
Pff, free booze is far better ;) I kid I kid, though Maxime helped a lot 
there.

Ok expect a v6 I think for review and hopefully merge tomorrow.

oliver

>
> greg k-h
>



From swarren at wwwdotorg.org  Tue Jul 30 13:45:12 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 11:45:12 -0600
Subject: [PATCH v6 2/8] ASoC: atmel: machine driver for at91sam9x5-wm8731
 boards
In-Reply-To: <1375180329-4860-3-git-send-email-richard.genoud@gmail.com>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
 <1375180329-4860-3-git-send-email-richard.genoud@gmail.com>
Message-ID: <51F7FBA8.6080400@wwwdotorg.org>

On 07/30/2013 04:32 AM, Richard Genoud wrote:
> From: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> Description of the Asoc machine driver for an at91sam9x5 based board
> with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
> master on the SSC/I2S interface. Its connections are a headphone jack
> and an Line input jack.
> 
> [Richard: this is based on an old patch from Nicolas that I forward
> ported and reworked to use only device tree]

> diff --git a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt

> +* Atmel at91sam9x5ek wm8731 audio complex
> +
> +Required properties:
> +  - compatible: "atmel,sam9x5-wm8731-audio"
> +  - atmel,model: The user-visible name of this sound complex.
> +  - atmel,ssc-controller: The phandle of the SSC controller
> +  - atmel,audio-codec: The phandle of the WM8731 audio codec
> +  - atmel,audio-routing: A list of the connections between audio components.
> +    Each entry is a pair of strings, the first being the connection's sink,
> +    the second being the connection's source.
> +
> +Available audio endpoints for the audio-routing table:
> +
> +Board connectors:
> + * Headphone Jack
> + * Line In Jack
> +
> +wm8731 pins:
> +cf Documentation/devicetree/bindings/sound/wm8731.txt

In the Tegra bindings, I deliberately put the list of CODEC pins into
the audio complex binding rather than the CODEC binding. That's because
I'm not sure that in the long-term we want to use strings to identify
the CODEC pins, rather than using integers. By putting the list orf
CODEC pins in the audio complex binding rather than the CODEC binding, I
didn't lumber the CODEC binding with a list of strings that it had to
support forever.

One reason that strings are problematic is because they can't be mixed
with integers/phandles in the same property, so if we ever end up with
more generic audio bindings where the routing table is expressed more like:

audio-routes = <&component_a $a_pin &component_b $b_pin>;

... in order to allow completely arbitrary and fully name-spaced routing
specification[1], then $a_pin and $b_pin need to be integers not strings.

[1] and perhaps we can get rid of properties like
audio-codec/ssc-controller, and automatically deduce which components
are needed simply by finding all phandles in the audio-routes property.

Perhaps the solution here is to allow mixing phandles/integers/strings
in one property, but that's potentially quite a large change to the DTB
format; we'd need to introduce type fields into the property data, and
other data format changes.


From jonsmirl at gmail.com  Tue Jul 30 13:45:39 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Tue, 30 Jul 2013 13:45:39 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <51F7F914.6040709@wwwdotorg.org>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <51F7F914.6040709@wwwdotorg.org>
Message-ID: <CAKON4Oy6hL9LzHdfq4vWcurbw6TU3HCK_jq14xwweA8dvOGtdw@mail.gmail.com>

On Tue, Jul 30, 2013 at 1:34 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/30/2013 11:29 AM, jonsmirl at gmail.com wrote:
>> On Tue, Jul 30, 2013 at 1:19 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>
>>> On 07/30/2013 07:14 AM, jonsmirl at gmail.com wrote:
>>>> On Tue, Jul 30, 2013 at 6:25 AM, Mark Brown <broonie at kernel.org> wrote:
>>>>> On Mon, Jul 29, 2013 at 08:30:29PM -0400, jonsmirl at gmail.com wrote:
>>>>>
>>>>>> This...
>>>>>> tx-dma-channel = <&pdma0 7>; /* preliminary */
>>>>>> rx-dma-channel = <&pdma0 6>; /* preliminary */
>>>>>
>>>>>> Probably should be
>>>>>> dmas = <&pdma0 7>,<&pdma0 6>;
>>>>>> dma-names = "tx", "rx";
>>>>>
>>>>> It should be - the latter is the generic DMA binding.  There's a lot of
>>>>> bindings in the kernel that predate that but people are currently
>>>>> working to transfer over, this is one of the examples of instability
>>>>> that everyone is talking about.
>>>>
>>>> Is something similar to this possible in device tree syntax?
>>>> dmas =  <"tx" &pdma0 7>,  <"rx"  &pdma0 6>;
>>>
>>> I /think/ you can physically write that in *.dts, or something very
>>> similar; with the strings outside the <>:
>>>
>>> dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
>>>
>>> However, there's been strong push-back (i.e. doing that has not been
>>> allowed at all) on attempting to mix variable-length strings and
>>> fixed-length/alignment integer cells in the same property. This is
>>> primarily because you then can't ensure that the integer cell data is
>>> aligned in the DTB (dtc and/or the DTB format spec does/requires/allows

The PowerPC FDT doc says that strings are indirected into a string
table. So they aren't variable length in the data structures.

I was wondering how dmas = "tx", "rx" was implemented. It is two
pointers into the indirect block. So this should work, there is no
variable length data to worry about in the structure.

>>> dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;


>>
>> Can we turn the strings into string phandles? Then they'd be fixed sized.
>
> I believe that phandles point at nodes not arbitrary data, so no.
>
> Now, could the DTB format be enhanced to allow that? Perhaps, although
> we'd need a different string syntax to enable it, since existing
> bindings would require the current inline-string format. That's getting
> outside the realm of schemas and making active changes to the DT format
> though...
>
>> That might provide a way to internationalize the strings too.
>
> I don't think internationalization is needed; DT is an interface to
> drivers/SW, rather than something end-user-visible.



-- 
Jon Smirl
jonsmirl at gmail.com


From neko at bakuhatsu.net  Tue Jul 30 13:48:59 2013
From: neko at bakuhatsu.net (Matt Sealey)
Date: Tue, 30 Jul 2013 12:48:59 -0500
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <1375195354.32691.55.camel@kazak.uk.xensource.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
 <51F7B4C9.2060500@gmail.com>
 <20130730125650.GD28716@e106331-lin.cambridge.arm.com>
 <20130730134427.GE28716@e106331-lin.cambridge.arm.com>
 <alpine.DEB.2.02.1307301528540.4893@kaball.uk.xensource.com>
 <1375195354.32691.55.camel@kazak.uk.xensource.com>
Message-ID: <CAHCPf3vUA1bD+1xPch-KZX6fdDzxsWjnVpUD39AKC=ds+EKeHQ@mail.gmail.com>

Isn't this being overthought?

"method" (I would have re-used model, but that's by-the-by) should
just determine which call interface to use. Only one should end up in
a device tree - it doesn't make a lot of sense to specify more than
one, to me, given my read of the specs and the SMC calling convention.

For AArch64 chips they should implement 64-bit SMC interface or 32-bit
SMC interface. Either way you get there, the function number is
encoded with the type of call anyway so AArch64 secure monitors or
hypervisors will know which one was intended, given the SMC calling
convention defines this "64-bit" bit pretty clearly. The "method" is
an instruction to the "guest OS" in how to fill it's registers more
than it is in function names.

* An AArch64 guest under an AArch32 hypervisor/sm seems pretty weird
and in any case, the device tree would use the 32-bit convention (any
SMC64 call in 32-bit state should return "Unknown SMC Function
Identifier" if that bit is set)
* An AArch32 guest under an AArch32  hypervisor/sm would use the
32-bit convention
* An AArch32 guest under an AArch64 hypervisor/sm would use the 32-bit
convention
* An AArch64 guest under an AArch64 hypervisor/sm would use the 64-bit
convention or the 32-bit convention depending on how the sm is
written, but it doesn't matter which is used if both can be
supported.. but you'd only want to use one of them.

TLDR; Supply your (EL1) guests with the preferred method, not a list
of all possible methods, as above. If you're the vendor and you
defined any part of EL3 or EL2 you're in complete control of which
method you want subordinate levels to use by way of implementation,
right?

BTW according to the specs you can't have EL2 without EL3 on ARMv7. I
would think the issues with hvc vs hvc64 need to be thought out;
hypervisors can trap SMC from their guests and do the right thing
without the guest ever knowing that a hypervisor is above it. If it is
the case that every Xen DomU kernel needs to know that it is
virtualized and to be told to use HVC instead of SMC? What's the
benefit of that?

-- Matt

On Tue, Jul 30, 2013 at 9:42 AM, Ian Campbell <Ian.Campbell at citrix.com> wrote:
> On Tue, 2013-07-30 at 15:33 +0100, Stefano Stabellini wrote:
>> On Tue, 30 Jul 2013, Mark Rutland wrote:
>> > On Tue, Jul 30, 2013 at 01:56:50PM +0100, Mark Rutland wrote:
>> > > On Tue, Jul 30, 2013 at 01:42:49PM +0100, Rob Herring wrote:
>> > > > On 07/30/2013 04:49 AM, Mark Rutland wrote:
>> > > > > On Mon, Jul 29, 2013 at 09:18:43PM +0100, Rob Herring wrote:
>> > > > >> On 07/29/2013 05:13 AM, Mark Rutland wrote:
>> > > > >>> Hi Rob,
>> > > > >>>
>> > > > >>> On Sun, Jul 28, 2013 at 10:56:32PM +0100, Rob Herring wrote:
>> > > > >>>> From: Rob Herring <rob.herring at calxeda.com>
>> > > >
>> > > > [snip]
>> > > >
>> > > > >>> One of the things changed in PSCI 0.2 was the SMC calling convention,
>> > > > >>> though this isn't clear in the PSCI document. The function IDs for 32bit
>> > > > >>> and 64bit callers may differ, and we need to support describing an
>> > > > >>> arbitrary configuration of the two (same ID for both, different across
>> > > > >>> 32-bit/64-bit, only supported for 64-bit, only supported for 32-bit).
>> > > > >>>
>> > > > >>> I'd like to ensure the binding can deal with that from the start. We
>> > > > >>> could do this by having -32 and -64 variants of each function id (e.g.
>> > > > >>> cpu_off-64) , if the IDs actually differ, and use the regular combined
>> > > > >>> ID if they don't.
>> > > > >>
>> > > > >> Uggg. I guess I should have read the SMC calling convention doc... I was
>> > > > >> simply documenting what is already in the PSCI doc, but obviously that
>> > > > >> is not fully flushed out.
>> > > > >>
>> > > > >> How about something like this (for the complicated case of both 32 and
>> > > > >> 64 bit):
>> > > > >>
>> > > > >>      method          = "smc", "smc64";
>> > > > >>      psci_version    = <0x84000000 0xc4000000>;
>> > > > >>      cpu_suspend     = <0x84000001 0xc4000001>;
>> > > > >>      cpu_off         = <0x84000002 0xc4000002>;
>> > > > >>      cpu_on          = <0x84000003 0xc4000003>;
>> > > > >>
>> > > > >> "smc" is a synonym for smc32 for compatibility. The number and order of
>> > > > >> methods determines the number and order of function IDs.
>> > > > >
>> > > > > While this may be compatible with the arm implementation, it won't be
>> > > > > compatible with the arm64 implementation, which assumes smc64 by
>> > > > > default.
>> > > > >
>> > > > > As far as I am aware, the implementations currently in use (KVM and Xen)
>> > > > > use the same ID for both, so I think "smc" should cover an ID valid for
>> > > > > a native register width calling convention, and "smc64" and "smc32"
>> > > > > describing values only valid for 64-bit wide and 32-bit wide calling
>> > > > > conventions respectively.
>> > > >
>> > > > The problem is that does not work for a 32-bit kernel on 64-bit h/w as
>> > > > native from the dts perspective is smc64. Just like the cpu bindings,
>> > > > the binding cannot change based on 32 or 64 bit OS. I don't think we
>> > > > really have to deal with that here. We can simply say "smc" is only for
>> > > > "arm,psci" and deprecated for "arm,psci-0.2".
>> > >
>> > > Agreed. I'd be happy with only having "smc32" and "smc64" for
>> > > "arm,psci-0.2".
>>
>> I would be happy with that too (Xen only uses HVC as "method").
>
> Presumably we have the same issues with hvc vs hvc32 vs hvc64 though?
>
> And does smcX imply hvcX or does that also need to be documented here?
>
>>
>> > Actually, from some quick discussion with Marc and Dave, I think we can
>> > handle this better, in a way that leaves this backwards compatible.
>> >
>> > Rather than relying on the method string to tell us the calling
>> > convention, I think we should rely on the function ID, as I proposed
>> > earlier. The existing function ids provided in the "arm,psci" binding
>> > are implicitly relying on the PSCI implementation to detect the register
>> > width and act accordingly. This is trivially true on 32bit hardware, KVM
>> > (where the same ID is used for 32-bit and 64-bit guests), and while I'm
>> > not entirely sure about Xen I believe it's true there. We can make this
>> > explicit as we extend the binding.
>> >
>> > Having a -64 and -32 variant of each ID (while not pretty) allows us to
>> > add additional IDs for functions that might only have a 32-bit or 64-bit
>> > interface implemented, in addition to functions with common IDs:
>> >
>> > psci {
>> >     compatible = "$VENDOR,psci-0.2", "arm,psci-0.2", "arm,psci";
>> >     cpu_off = <12345678>;
>> >     cpu_on = <01234567>;
>> >     system_reset-32 = <02222222>;
>> >     system_reset-64 = <12222222>;
>> >     affinity_info-64 = <15555555>;
>> > };
>> >
>> > This means that hypervisors could update their PSCI implementation while
>> > keeping their DTS compatible with existing kernels.
>>
>> Are you proposing of getting rid of "method" completely and therefore
>> have 4 possible function IDs for each function:
>>
>> system_reset-32-HVC
>> system_reset-64-SMC
>> system_reset-32-HVC
>> system_reset-64-SMC
>>
>> or are you proposing of choosing just the register width via function
>> IDs?
>>
>> Honestly I think it would be cleaner to introduce a new field called
>> "width" can that be 32 or 64 and represent the register width, rather
>> than having an explosion of function IDs.
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From swarren at wwwdotorg.org  Tue Jul 30 13:49:26 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 11:49:26 -0600
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4Oy6hL9LzHdfq4vWcurbw6TU3HCK_jq14xwweA8dvOGtdw@mail.gmail.com>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <51F7F914.6040709@wwwdotorg.org>
 <CAKON4Oy6hL9LzHdfq4vWcurbw6TU3HCK_jq14xwweA8dvOGtdw@mail.gmail.com>
Message-ID: <51F7FCA6.6010909@wwwdotorg.org>

On 07/30/2013 11:45 AM, jonsmirl at gmail.com wrote:
> On Tue, Jul 30, 2013 at 1:34 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 07/30/2013 11:29 AM, jonsmirl at gmail.com wrote:
>>> On Tue, Jul 30, 2013 at 1:19 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>>
>>>> On 07/30/2013 07:14 AM, jonsmirl at gmail.com wrote:
>>>>> On Tue, Jul 30, 2013 at 6:25 AM, Mark Brown <broonie at kernel.org> wrote:
>>>>>> On Mon, Jul 29, 2013 at 08:30:29PM -0400, jonsmirl at gmail.com wrote:
>>>>>>
>>>>>>> This...
>>>>>>> tx-dma-channel = <&pdma0 7>; /* preliminary */
>>>>>>> rx-dma-channel = <&pdma0 6>; /* preliminary */
>>>>>>
>>>>>>> Probably should be
>>>>>>> dmas = <&pdma0 7>,<&pdma0 6>;
>>>>>>> dma-names = "tx", "rx";
>>>>>>
>>>>>> It should be - the latter is the generic DMA binding.  There's a lot of
>>>>>> bindings in the kernel that predate that but people are currently
>>>>>> working to transfer over, this is one of the examples of instability
>>>>>> that everyone is talking about.
>>>>>
>>>>> Is something similar to this possible in device tree syntax?
>>>>> dmas =  <"tx" &pdma0 7>,  <"rx"  &pdma0 6>;
>>>>
>>>> I /think/ you can physically write that in *.dts, or something very
>>>> similar; with the strings outside the <>:
>>>>
>>>> dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
>>>>
>>>> However, there's been strong push-back (i.e. doing that has not been
>>>> allowed at all) on attempting to mix variable-length strings and
>>>> fixed-length/alignment integer cells in the same property. This is
>>>> primarily because you then can't ensure that the integer cell data is
>>>> aligned in the DTB (dtc and/or the DTB format spec does/requires/allows
> 
> The PowerPC FDT doc says that strings are indirected into a string
> table. So they aren't variable length in the data structures.

Do you have a link to the document; I'm not sure which one you mean.

> I was wondering how dmas = "tx", "rx" was implemented. It is two
> pointers into the indirect block. So this should work, there is no
> variable length data to worry about in the structure.

If you look at of_property_read_string_index() in drivers/of/base.c,
you'll see that it expects the strings to just be packed together inline.

What you say may be correct for node and property names, just not
property values.


From cov at codeaurora.org  Tue Jul 30 13:50:31 2013
From: cov at codeaurora.org (Christopher Covington)
Date: Tue, 30 Jul 2013 13:50:31 -0400
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]
In-Reply-To: <20130730120907.6dcc469e@armhf>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
 <20130715135420.GG10000@mudshark.cambridge.arm.com>
 <20130720044655.GC9433@mozilla.com>
 <20130721213753.GA29879@mudshark.cambridge.arm.com>
 <20130722185234.GA14519@localhost.localdomain>
 <20130729212140.GB12681@mozilla.com>
 <20130730092517.GB2478@localhost.localdomain> <20130730113853.46cbb00a@armhf>
 <20130730094457.GC2478@localhost.localdomain> <20130730120907.6dcc469e@armhf>
Message-ID: <51F7FCE7.1040006@codeaurora.org>

On 07/30/2013 06:09 AM, Jean-Francois Moine wrote:
> On Tue, 30 Jul 2013 10:44:57 +0100
> Dave Martin <Dave.Martin at arm.com> wrote:
>> On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
>>> On Tue, 30 Jul 2013 10:25:18 +0100
>>> Dave Martin <Dave.Martin at arm.com> wrote:
>>>> The pragmatic route is less contraversial and lower overhead: even though
>>>> it's not correct as per the ABI, GCC is the only supported compiler for
>>>> building the kernel anyway.  

[...]

>>> Did anybody succeed with clang?  
>>
>> Hmm, I've no idea.  Is this possible?
> 
> freebsd kernels are compiled with clang, and I heard about linux
> patches, but I did not find them yet.

There's a project home page here:

http://llvm.linuxfoundation.org/index.php/Main_Page

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.


From will.deacon at arm.com  Tue Jul 30 13:57:14 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 30 Jul 2013 18:57:14 +0100
Subject: [PATCH 1/2] ARM: locks: use early clobber in arch_spin_trylock
Message-ID: <1375207035-8072-1-git-send-email-will.deacon@arm.com>

The res variable is written before we've finished with the input
operands (namely the lock address), so ensure that we mark it as `early
clobber' to avoid unintended register sharing.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/spinlock.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index f8b8965..7ed43f68 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -107,7 +107,7 @@ static inline int arch_spin_trylock(arch_spinlock_t *lock)
 		"	subs	%1, %0, %0, ror #16\n"
 		"	addeq	%0, %0, %4\n"
 		"	strexeq	%2, %0, [%3]"
-		: "=&r" (slock), "=&r" (contended), "=r" (res)
+		: "=&r" (slock), "=&r" (contended), "=&r" (res)
 		: "r" (&lock->slock), "I" (1 << TICKET_SHIFT)
 		: "cc");
 	} while (res);
-- 
1.8.2.2



From will.deacon at arm.com  Tue Jul 30 13:57:15 2013
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 30 Jul 2013 18:57:15 +0100
Subject: [PATCH 2/2] ARM: rwlocks: retry trylock operation if strex fails on
 free lock
In-Reply-To: <1375207035-8072-1-git-send-email-will.deacon@arm.com>
References: <1375207035-8072-1-git-send-email-will.deacon@arm.com>
Message-ID: <1375207035-8072-2-git-send-email-will.deacon@arm.com>

Commit 15e7e5c1ebf5 ("ARM: 7749/1: spinlock: retry trylock operation if
strex fails on free lock") modifying our arch_spin_trylock to retry the
acquisition if the lock appeared uncontended, but the strex failed.

This patch does the same for rwlocks, which were missed by the original
patch.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm/include/asm/spinlock.h | 49 +++++++++++++++++++++++++----------------
 1 file changed, 30 insertions(+), 19 deletions(-)

diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index 7ed43f68..b07c09e 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -168,17 +168,20 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
 
 static inline int arch_write_trylock(arch_rwlock_t *rw)
 {
-	unsigned long tmp;
+	unsigned long contended, res;
 
-	__asm__ __volatile__(
-"	ldrex	%0, [%1]\n"
-"	teq	%0, #0\n"
-"	strexeq	%0, %2, [%1]"
-	: "=&r" (tmp)
-	: "r" (&rw->lock), "r" (0x80000000)
-	: "cc");
+	do {
+		__asm__ __volatile__(
+		"	ldrex	%0, [%2]\n"
+		"	mov	%1, #0\n"
+		"	teq	%0, #0\n"
+		"	strexeq	%1, %3, [%2]"
+		: "=&r" (contended), "=&r" (res)
+		: "r" (&rw->lock), "r" (0x80000000)
+		: "cc");
+	} while (res);
 
-	if (tmp == 0) {
+	if (!contended) {
 		smp_mb();
 		return 1;
 	} else {
@@ -254,18 +257,26 @@ static inline void arch_read_unlock(arch_rwlock_t *rw)
 
 static inline int arch_read_trylock(arch_rwlock_t *rw)
 {
-	unsigned long tmp, tmp2 = 1;
+	unsigned long contended, res;
 
-	__asm__ __volatile__(
-"	ldrex	%0, [%2]\n"
-"	adds	%0, %0, #1\n"
-"	strexpl	%1, %0, [%2]\n"
-	: "=&r" (tmp), "+r" (tmp2)
-	: "r" (&rw->lock)
-	: "cc");
+	do {
+		__asm__ __volatile__(
+		"	ldrex	%0, [%2]\n"
+		"	mov	%1, #0\n"
+		"	adds	%0, %0, #1\n"
+		"	strexpl	%1, %0, [%2]"
+		: "=&r" (contended), "=&r" (res)
+		: "r" (&rw->lock)
+		: "cc");
+	} while (res);
 
-	smp_mb();
-	return tmp2 == 0;
+	/* If the lock is negative, then it is already held for write. */
+	if (contended < 0x80000000) {
+		smp_mb();
+		return 1;
+	} else {
+		return 0;
+	}
 }
 
 /* read_can_lock - would read_trylock() succeed? */
-- 
1.8.2.2



From jonsmirl at gmail.com  Tue Jul 30 14:03:08 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Tue, 30 Jul 2013 14:03:08 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <51F7FCA6.6010909@wwwdotorg.org>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <51F7F914.6040709@wwwdotorg.org>
 <CAKON4Oy6hL9LzHdfq4vWcurbw6TU3HCK_jq14xwweA8dvOGtdw@mail.gmail.com>
 <51F7FCA6.6010909@wwwdotorg.org>
Message-ID: <CAKON4OzLgC-ahDhLnbYEYrSj7dbFRU0z7Do_D32XNqux2UhvXw@mail.gmail.com>

On Tue, Jul 30, 2013 at 1:49 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/30/2013 11:45 AM, jonsmirl at gmail.com wrote:
>> On Tue, Jul 30, 2013 at 1:34 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> On 07/30/2013 11:29 AM, jonsmirl at gmail.com wrote:
>>>> On Tue, Jul 30, 2013 at 1:19 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>>>
>>>>> On 07/30/2013 07:14 AM, jonsmirl at gmail.com wrote:
>>>>>> On Tue, Jul 30, 2013 at 6:25 AM, Mark Brown <broonie at kernel.org> wrote:
>>>>>>> On Mon, Jul 29, 2013 at 08:30:29PM -0400, jonsmirl at gmail.com wrote:
>>>>>>>
>>>>>>>> This...
>>>>>>>> tx-dma-channel = <&pdma0 7>; /* preliminary */
>>>>>>>> rx-dma-channel = <&pdma0 6>; /* preliminary */
>>>>>>>
>>>>>>>> Probably should be
>>>>>>>> dmas = <&pdma0 7>,<&pdma0 6>;
>>>>>>>> dma-names = "tx", "rx";
>>>>>>>
>>>>>>> It should be - the latter is the generic DMA binding.  There's a lot of
>>>>>>> bindings in the kernel that predate that but people are currently
>>>>>>> working to transfer over, this is one of the examples of instability
>>>>>>> that everyone is talking about.
>>>>>>
>>>>>> Is something similar to this possible in device tree syntax?
>>>>>> dmas =  <"tx" &pdma0 7>,  <"rx"  &pdma0 6>;
>>>>>
>>>>> I /think/ you can physically write that in *.dts, or something very
>>>>> similar; with the strings outside the <>:
>>>>>
>>>>> dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
>>>>>
>>>>> However, there's been strong push-back (i.e. doing that has not been
>>>>> allowed at all) on attempting to mix variable-length strings and
>>>>> fixed-length/alignment integer cells in the same property. This is
>>>>> primarily because you then can't ensure that the integer cell data is
>>>>> aligned in the DTB (dtc and/or the DTB format spec does/requires/allows
>>
>> The PowerPC FDT doc says that strings are indirected into a string
>> table. So they aren't variable length in the data structures.
>
> Do you have a link to the document; I'm not sure which one you mean.

So it looks like there is one indirection to get to the block, then
the strings are concatenated. The indirection must have been hidden
when the node structure was created.  I had thought that there was a
list of indirects each pointing to a string in the string block.

https://www.power.org/documentation/epapr-version-1-1/

8.5 Strings Block
The strings block contains strings representing all the property names
used in the tree. These null-
terminated strings are simply concatenated together in this section,
and referred to from the structure
block by an offset into the strings block.
The strings block has no alignment constraints and may appear at any
offset from the beginning of the
device tree blob.


>
>> I was wondering how dmas = "tx", "rx" was implemented. It is two
>> pointers into the indirect block. So this should work, there is no
>> variable length data to worry about in the structure.
>
> If you look at of_property_read_string_index() in drivers/of/base.c,
> you'll see that it expects the strings to just be packed together inline.
>
> What you say may be correct for node and property names, just not
> property values.



-- 
Jon Smirl
jonsmirl at gmail.com


From jonsmirl at gmail.com  Tue Jul 30 14:04:39 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Tue, 30 Jul 2013 14:04:39 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4OzLgC-ahDhLnbYEYrSj7dbFRU0z7Do_D32XNqux2UhvXw@mail.gmail.com>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <51F7F914.6040709@wwwdotorg.org>
 <CAKON4Oy6hL9LzHdfq4vWcurbw6TU3HCK_jq14xwweA8dvOGtdw@mail.gmail.com>
 <51F7FCA6.6010909@wwwdotorg.org>
 <CAKON4OzLgC-ahDhLnbYEYrSj7dbFRU0z7Do_D32XNqux2UhvXw@mail.gmail.com>
Message-ID: <CAKON4OyMfNUR=NGn+OEvN3utcEzRfG6A4rPO6+h5Q4mq_tmoxw@mail.gmail.com>

On Tue, Jul 30, 2013 at 2:03 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
> On Tue, Jul 30, 2013 at 1:49 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 07/30/2013 11:45 AM, jonsmirl at gmail.com wrote:
>>> On Tue, Jul 30, 2013 at 1:34 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>> On 07/30/2013 11:29 AM, jonsmirl at gmail.com wrote:
>>>>> On Tue, Jul 30, 2013 at 1:19 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>>>>
>>>>>> On 07/30/2013 07:14 AM, jonsmirl at gmail.com wrote:
>>>>>>> On Tue, Jul 30, 2013 at 6:25 AM, Mark Brown <broonie at kernel.org> wrote:
>>>>>>>> On Mon, Jul 29, 2013 at 08:30:29PM -0400, jonsmirl at gmail.com wrote:
>>>>>>>>
>>>>>>>>> This...
>>>>>>>>> tx-dma-channel = <&pdma0 7>; /* preliminary */
>>>>>>>>> rx-dma-channel = <&pdma0 6>; /* preliminary */
>>>>>>>>
>>>>>>>>> Probably should be
>>>>>>>>> dmas = <&pdma0 7>,<&pdma0 6>;
>>>>>>>>> dma-names = "tx", "rx";
>>>>>>>>
>>>>>>>> It should be - the latter is the generic DMA binding.  There's a lot of
>>>>>>>> bindings in the kernel that predate that but people are currently
>>>>>>>> working to transfer over, this is one of the examples of instability
>>>>>>>> that everyone is talking about.
>>>>>>>
>>>>>>> Is something similar to this possible in device tree syntax?
>>>>>>> dmas =  <"tx" &pdma0 7>,  <"rx"  &pdma0 6>;
>>>>>>
>>>>>> I /think/ you can physically write that in *.dts, or something very
>>>>>> similar; with the strings outside the <>:
>>>>>>
>>>>>> dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
>>>>>>
>>>>>> However, there's been strong push-back (i.e. doing that has not been
>>>>>> allowed at all) on attempting to mix variable-length strings and
>>>>>> fixed-length/alignment integer cells in the same property. This is
>>>>>> primarily because you then can't ensure that the integer cell data is
>>>>>> aligned in the DTB (dtc and/or the DTB format spec does/requires/allows
>>>
>>> The PowerPC FDT doc says that strings are indirected into a string
>>> table. So they aren't variable length in the data structures.
>>
>> Do you have a link to the document; I'm not sure which one you mean.
>
> So it looks like there is one indirection to get to the block, then
> the strings are concatenated. The indirection must have been hidden
> when the node structure was created.  I had thought that there was a
> list of indirects each pointing to a string in the string block.
>
> https://www.power.org/documentation/epapr-version-1-1/

So what does an alternating use of strings do?

 dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;


>
> 8.5 Strings Block
> The strings block contains strings representing all the property names
> used in the tree. These null-
> terminated strings are simply concatenated together in this section,
> and referred to from the structure
> block by an offset into the strings block.
> The strings block has no alignment constraints and may appear at any
> offset from the beginning of the
> device tree blob.
>
>
>>
>>> I was wondering how dmas = "tx", "rx" was implemented. It is two
>>> pointers into the indirect block. So this should work, there is no
>>> variable length data to worry about in the structure.
>>
>> If you look at of_property_read_string_index() in drivers/of/base.c,
>> you'll see that it expects the strings to just be packed together inline.
>>
>> What you say may be correct for node and property names, just not
>> property values.
>
>
>
> --
> Jon Smirl
> jonsmirl at gmail.com



-- 
Jon Smirl
jonsmirl at gmail.com


From nm at ti.com  Tue Jul 30 14:22:20 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 13:22:20 -0500
Subject: [PATCHv4 04/33] CLK: omap: move part of the machine specific
 clock header contents to driver
In-Reply-To: <1374564028-11352-5-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-5-git-send-email-t-kristo@ti.com>
Message-ID: <51F8045C.6020603@ti.com>

this patch should be 3/33 to allow dpll.c to build.

On 07/23/2013 02:19 AM, Tero Kristo wrote:
> Some of the clock.h contents are needed by the new OMAP clock driver,
> including dpll_data and clk_hw_omap. Thus, move these to the generic
> omap header file which can be accessed by the driver.
>
Looking at the change, I wonder what the rules are for the movement? 
commit message was not clear.

> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
>   arch/arm/mach-omap2/clock.h |  151 +----------------------------------------
>   include/linux/clk/omap.h    |  157 ++++++++++++++++++++++++++++++++++++++++++-
>   2 files changed, 157 insertions(+), 151 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
> index 7aa32cd..d1a3125 100644
> --- a/arch/arm/mach-omap2/clock.h
> +++ b/arch/arm/mach-omap2/clock.h
> @@ -21,6 +21,7 @@
>
>   #include <linux/clkdev.h>
>   #include <linux/clk-provider.h>
> +#include <linux/clk/omap.h>
>
>   struct omap_clk {
>   	u16				cpu;
> @@ -178,83 +179,6 @@ struct clksel {
>   	const struct clksel_rate *rates;
>   };
>
> -/**
> - * struct dpll_data - DPLL registers and integration data
> - * @mult_div1_reg: register containing the DPLL M and N bitfields
> - * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg
> - * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg
> - * @clk_bypass: struct clk pointer to the clock's bypass clock input
> - * @clk_ref: struct clk pointer to the clock's reference clock input
> - * @control_reg: register containing the DPLL mode bitfield
> - * @enable_mask: mask of the DPLL mode bitfield in @control_reg
> - * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate()
> - * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate()
> - * @last_rounded_m4xen: cache of the last M4X result of
> - *			omap4_dpll_regm4xen_round_rate()
> - * @last_rounded_lpmode: cache of the last lpmode result of
> - *			 omap4_dpll_lpmode_recalc()
> - * @max_multiplier: maximum valid non-bypass multiplier value (actual)
> - * @last_rounded_n: cache of the last N result of omap2_dpll_round_rate()
> - * @min_divider: minimum valid non-bypass divider value (actual)
> - * @max_divider: maximum valid non-bypass divider value (actual)
> - * @modes: possible values of @enable_mask
> - * @autoidle_reg: register containing the DPLL autoidle mode bitfield
> - * @idlest_reg: register containing the DPLL idle status bitfield
> - * @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg
> - * @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg
> - * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg
> - * @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg
> - * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg
> - * @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg
> - * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs
> - * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs
> - * @flags: DPLL type/features (see below)
> - *
> - * Possible values for @flags:
> - * DPLL_J_TYPE: "J-type DPLL" (only some 36xx, 4xxx DPLLs)
> - *
> - * @freqsel_mask is only used on the OMAP34xx family and AM35xx.
> - *
> - * XXX Some DPLLs have multiple bypass inputs, so it's not technically
> - * correct to only have one @clk_bypass pointer.
> - *
> - * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m,
> - * @last_rounded_n) should be separated from the runtime-fixed fields
> - * and placed into a different structure, so that the runtime-fixed data
> - * can be placed into read-only space.
> - */
> -struct dpll_data {
> -	void __iomem		*mult_div1_reg;
> -	u32			mult_mask;
> -	u32			div1_mask;
> -	struct clk		*clk_bypass;
> -	struct clk		*clk_ref;
> -	void __iomem		*control_reg;
> -	u32			enable_mask;
> -	unsigned long		last_rounded_rate;
> -	u16			last_rounded_m;
> -	u8			last_rounded_m4xen;
> -	u8			last_rounded_lpmode;
> -	u16			max_multiplier;
> -	u8			last_rounded_n;
> -	u8			min_divider;
> -	u16			max_divider;
> -	u8			modes;
> -	void __iomem		*autoidle_reg;
> -	void __iomem		*idlest_reg;
> -	u32			autoidle_mask;
> -	u32			freqsel_mask;
> -	u32			idlest_mask;
> -	u32			dco_mask;
> -	u32			sddiv_mask;
> -	u32			lpmode_mask;
> -	u32			m4xen_mask;
> -	u8			auto_recal_bit;
> -	u8			recal_en_bit;
> -	u8			recal_st_bit;
> -	u8			flags;
> -};
> -
>   /*
>    * struct clk.flags possibilities
>    *
> @@ -274,56 +198,6 @@ struct dpll_data {
>   #define INVERT_ENABLE		(1 << 4)	/* 0 enables, 1 disables */
>   #define CLOCK_CLKOUTX2		(1 << 5)
>
> -/**
> - * struct clk_hw_omap - OMAP struct clk
> - * @node: list_head connecting this clock into the full clock list
> - * @enable_reg: register to write to enable the clock (see @enable_bit)
> - * @enable_bit: bitshift to write to enable/disable the clock (see @enable_reg)
> - * @flags: see "struct clk.flags possibilities" above
> - * @clksel_reg: for clksel clks, register va containing src/divisor select
> - * @clksel_mask: bitmask in @clksel_reg for the src/divisor selector
> - * @clksel: for clksel clks, pointer to struct clksel for this clock
> - * @dpll_data: for DPLLs, pointer to struct dpll_data for this clock
> - * @clkdm_name: clockdomain name that this clock is contained in
> - * @clkdm: pointer to struct clockdomain, resolved from @clkdm_name at runtime
> - * @rate_offset: bitshift for rate selection bitfield (OMAP1 only)
> - * @src_offset: bitshift for source selection bitfield (OMAP1 only)
> - *
> - * XXX @rate_offset, @src_offset should probably be removed and OMAP1
> - * clock code converted to use clksel.
> - *
> - */
> -
> -struct clk_hw_omap_ops;
> -
> -struct clk_hw_omap {
> -	struct clk_hw		hw;
> -	struct list_head	node;
> -	unsigned long		fixed_rate;
> -	u8			fixed_div;
> -	void __iomem		*enable_reg;
> -	u8			enable_bit;
> -	u8			flags;
> -	void __iomem		*clksel_reg;
> -	u32			clksel_mask;
> -	const struct clksel	*clksel;
> -	struct dpll_data	*dpll_data;
> -	const char		*clkdm_name;
> -	struct clockdomain	*clkdm;
> -	const struct clk_hw_omap_ops	*ops;
> -};
> -
> -struct clk_hw_omap_ops {
> -	void			(*find_idlest)(struct clk_hw_omap *oclk,
> -					void __iomem **idlest_reg,
> -					u8 *idlest_bit, u8 *idlest_val);
> -	void			(*find_companion)(struct clk_hw_omap *oclk,
> -					void __iomem **other_reg,
> -					u8 *other_bit);
> -	void			(*allow_idle)(struct clk_hw_omap *oclk);
> -	void			(*deny_idle)(struct clk_hw_omap *oclk);
> -};
> -
>   unsigned long omap_fixed_divisor_recalc(struct clk_hw *hw,
>   					unsigned long parent_rate);
>
> @@ -356,28 +230,13 @@ unsigned long omap_fixed_divisor_recalc(struct clk_hw *hw,
>   /* DPLL Type and DCO Selection Flags */
>   #define DPLL_J_TYPE		0x1
>
> -long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
> -			unsigned long *parent_rate);
> -unsigned long omap3_dpll_recalc(struct clk_hw *hw, unsigned long parent_rate);
> -int omap3_noncore_dpll_enable(struct clk_hw *hw);
> -void omap3_noncore_dpll_disable(struct clk_hw *hw);
> -int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned long rate,
> -				unsigned long parent_rate);

Why are these being moved to generic?

>   u32 omap3_dpll_autoidle_read(struct clk_hw_omap *clk);
>   void omap3_dpll_allow_idle(struct clk_hw_omap *clk);
>   void omap3_dpll_deny_idle(struct clk_hw_omap *clk);

> -unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
> -				    unsigned long parent_rate);
why move this?

>   int omap4_dpllmx_gatectrl_read(struct clk_hw_omap *clk);
>   void omap4_dpllmx_allow_gatectrl(struct clk_hw_omap *clk);
>   void omap4_dpllmx_deny_gatectrl(struct clk_hw_omap *clk);
> -unsigned long omap4_dpll_regm4xen_recalc(struct clk_hw *hw,
> -				unsigned long parent_rate);
> -long omap4_dpll_regm4xen_round_rate(struct clk_hw *hw,
> -				    unsigned long target_rate,
> -				    unsigned long *parent_rate);
same here.

>
> -void omap2_init_clk_clkdm(struct clk_hw *clk);
same question again.

>   void __init omap2_clk_disable_clkdm_control(void);
>
>   /* clkt_clksel.c public functions */
> @@ -396,7 +255,6 @@ int omap2_clksel_set_parent(struct clk_hw *hw, u8 field_val);
>   extern void omap2_clkt_iclk_allow_idle(struct clk_hw_omap *clk);
>   extern void omap2_clkt_iclk_deny_idle(struct clk_hw_omap *clk);
>
> -u8 omap2_init_dpll_parent(struct clk_hw *hw);
why move this?

>   unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk);
>
>   int omap2_dflt_clk_enable(struct clk_hw *hw);
> @@ -408,9 +266,7 @@ void omap2_clk_dflt_find_companion(struct clk_hw_omap *clk,
>   void omap2_clk_dflt_find_idlest(struct clk_hw_omap *clk,
>   				void __iomem **idlest_reg,
>   				u8 *idlest_bit, u8 *idlest_val);
> -void omap2_init_clk_hw_omap_clocks(struct clk *clk);
why move this?

>   int omap2_clk_enable_autoidle_all(void);
> -int omap2_clk_disable_autoidle_all(void);
why move this?

>   void omap2_clk_enable_init_clocks(const char **clk_names, u8 num_clocks);
>   int omap2_clk_switch_mpurate_at_boot(const char *mpurate_ck_name);
>   void omap2_clk_print_new_rates(const char *hfclkin_ck_name,
> @@ -431,10 +287,8 @@ extern const struct clksel_rate gfx_l3_rates[];
>   extern const struct clksel_rate dsp_ick_rates[];
>   extern struct clk dummy_ck;
>
> -extern const struct clk_hw_omap_ops clkhwops_omap3_dpll;
is this needed to be moved?

>   extern const struct clk_hw_omap_ops clkhwops_iclk_wait;
>   extern const struct clk_hw_omap_ops clkhwops_wait;
> -extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx;
is this needed to be moved?

>   extern const struct clk_hw_omap_ops clkhwops_iclk;
>   extern const struct clk_hw_omap_ops clkhwops_omap3430es2_ssi_wait;
>   extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_ssi_wait;
> @@ -460,8 +314,5 @@ extern const struct clksel_rate div31_1to31_rates[];
>
>   extern int am33xx_clk_init(void);
>
> -extern int omap2_clkops_enable_clkdm(struct clk_hw *hw);
> -extern void omap2_clkops_disable_clkdm(struct clk_hw *hw);
> -


>   extern void omap_clocks_register(struct omap_clk *oclks, int cnt);
>   #endif
> diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
> index 647f02f..cba892a 100644
> --- a/include/linux/clk/omap.h
> +++ b/include/linux/clk/omap.h
> @@ -19,6 +19,161 @@
>   #ifndef __LINUX_CLK_OMAP_H_
>   #define __LINUX_CLK_OMAP_H_
>
> -int __init dt_omap_clk_init(void);
> +/**
> + * struct dpll_data - DPLL registers and integration data
> + * @mult_div1_reg: register containing the DPLL M and N bitfields
> + * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg
> + * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg
> + * @clk_bypass: struct clk pointer to the clock's bypass clock input
> + * @clk_ref: struct clk pointer to the clock's reference clock input
> + * @control_reg: register containing the DPLL mode bitfield
> + * @enable_mask: mask of the DPLL mode bitfield in @control_reg
> + * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate()
> + * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate()
> + * @last_rounded_m4xen: cache of the last M4X result of
> + *                     omap4_dpll_regm4xen_round_rate()
> + * @last_rounded_lpmode: cache of the last lpmode result of
> + *                      omap4_dpll_lpmode_recalc()
> + * @max_multiplier: maximum valid non-bypass multiplier value (actual)
> + * @last_rounded_n: cache of the last N result of omap2_dpll_round_rate()
> + * @min_divider: minimum valid non-bypass divider value (actual)
> + * @max_divider: maximum valid non-bypass divider value (actual)
> + * @modes: possible values of @enable_mask
> + * @autoidle_reg: register containing the DPLL autoidle mode bitfield
> + * @idlest_reg: register containing the DPLL idle status bitfield
> + * @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg
> + * @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg
> + * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg
> + * @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg
> + * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg
> + * @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg
> + * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs
> + * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs
> + * @flags: DPLL type/features (see below)
> + *
> + * Possible values for @flags:
> + * DPLL_J_TYPE: "J-type DPLL" (only some 36xx, 4xxx DPLLs)
but the flag is in arch/arm/mach-omap2/clock.h ?

> + *
> + * @freqsel_mask is only used on the OMAP34xx family and AM35xx.
> + *
> + * XXX Some DPLLs have multiple bypass inputs, so it's not technically
> + * correct to only have one @clk_bypass pointer.
> + *
> + * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m,
> + * @last_rounded_n) should be separated from the runtime-fixed fields
> + * and placed into a different structure, so that the runtime-fixed data
> + * can be placed into read-only space.
> + */
> +struct dpll_data {

is it necessary to export this? usage is limited to dpll.c and could be 
made private to it alone, no?

> +	void __iomem		*mult_div1_reg;
> +	u32			mult_mask;
> +	u32			div1_mask;
> +	struct clk		*clk_bypass;
> +	struct clk		*clk_ref;
> +	void __iomem		*control_reg;
> +	u32			enable_mask;
> +	unsigned long		last_rounded_rate;
> +	u16			last_rounded_m;
> +	u8			last_rounded_m4xen;
> +	u8			last_rounded_lpmode;
> +	u16			max_multiplier;
> +	u8			last_rounded_n;
> +	u8			min_divider;
> +	u16			max_divider;
> +	u8			modes;
> +	void __iomem		*autoidle_reg;
> +	void __iomem		*idlest_reg;
> +	u32			autoidle_mask;
> +	u32			freqsel_mask;
> +	u32			idlest_mask;
> +	u32			dco_mask;

not part of kernel documentation above.

> +	u32			sddiv_mask;

not part of kernel documentation above.


> +	u32			lpmode_mask;
> +	u32			m4xen_mask;
> +	u8			auto_recal_bit;
> +	u8			recal_en_bit;
> +	u8			recal_st_bit;
> +	u8			flags;
> +};
> +
> +/**
> + * struct clk_hw_omap - OMAP struct clk
> + * @node: list_head connecting this clock into the full clock list
> + * @enable_reg: register to write to enable the clock (see @enable_bit)
> + * @enable_bit: bitshift to write to enable/disable the clock (see @enable_reg)
> + * @flags: see "struct clk.flags possibilities" above
> + * @clksel_reg: for clksel clks, register va containing src/divisor select
> + * @clksel_mask: bitmask in @clksel_reg for the src/divisor selector
> + * @clksel: for clksel clks, pointer to struct clksel for this clock
> + * @dpll_data: for DPLLs, pointer to struct dpll_data for this clock
> + * @clkdm_name: clockdomain name that this clock is contained in
> + * @clkdm: pointer to struct clockdomain, resolved from @clkdm_name at runtime
> + * @rate_offset: bitshift for rate selection bitfield (OMAP1 only)
> + * @src_offset: bitshift for source selection bitfield (OMAP1 only)
> + *
> + * XXX @rate_offset, @src_offset should probably be removed and OMAP1
> + * clock code converted to use clksel.
Do you need to carry these forward? they already disappeared from the 
struct below.

> + *
> + */
> +
> +struct clk_hw_omap_ops;
you need to keep the kernel documentation next to the struct which it is 
documenting, by introducing clk_hw_omap_ops forward declaration, we 
introduced the following kernel-doc error:

Error(include/linux/clk/omap.h:119): Cannot parse struct or union!

> +
> +struct clk_hw_omap {
> +	struct clk_hw		hw;
not documented.

> +	struct list_head	node;
> +	unsigned long		fixed_rate;
not documented.

> +	u8			fixed_div;
not documented.

> +	void __iomem		*enable_reg;
> +	u8			enable_bit;
> +	u8			flags;
> +	void __iomem		*clksel_reg;
> +	u32			clksel_mask;
> +	const struct clksel	*clksel;
> +	struct dpll_data	*dpll_data;
> +	const char		*clkdm_name;
> +	struct clockdomain	*clkdm;
> +	const struct clk_hw_omap_ops	*ops;
> +};
> +
> +struct clk_hw_omap_ops {
> +	void			(*find_idlest)(struct clk_hw_omap *oclk,
> +					void __iomem **idlest_reg,
> +					u8 *idlest_bit, u8 *idlest_val);
> +	void			(*find_companion)(struct clk_hw_omap *oclk,
> +					void __iomem **other_reg,
> +					u8 *other_bit);
> +	void			(*allow_idle)(struct clk_hw_omap *oclk);
> +	void			(*deny_idle)(struct clk_hw_omap *oclk);
> +};

will be nice to have kernel documentation for these.

> +
> +void omap2_init_clk_hw_omap_clocks(struct clk *clk);
> +int omap3_noncore_dpll_enable(struct clk_hw *hw);
> +void omap3_noncore_dpll_disable(struct clk_hw *hw);
> +int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned long rate,
> +				unsigned long parent_rate);
> +unsigned long omap4_dpll_regm4xen_recalc(struct clk_hw *hw,
> +				unsigned long parent_rate);
> +long omap4_dpll_regm4xen_round_rate(struct clk_hw *hw,
> +				    unsigned long target_rate,
> +				    unsigned long *parent_rate);
> +u8 omap2_init_dpll_parent(struct clk_hw *hw);
> +unsigned long omap3_dpll_recalc(struct clk_hw *hw, unsigned long parent_rate);
> +long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
> +			unsigned long *parent_rate);
> +void omap2_init_clk_clkdm(struct clk_hw *clk);
> +unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
> +				    unsigned long parent_rate);
> +
> +int omap2_clkops_enable_clkdm(struct clk_hw *hw);
> +void omap2_clkops_disable_clkdm(struct clk_hw *hw);
> +
> +int omap2_clk_disable_autoidle_all(void);
^^ all the above, not clear why we are moving them out enmasse.

> +
> +extern const struct clk_hw_omap_ops clkhwops_omap3_dpll;
> +extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx;
why do we need to export these out?

> +
> +/* DT functions */
> +int dt_omap_clk_init(void);
in this change, we removed __init -> which should have been done in the 
patch that introduced it in the first place.

> +void of_omap4_dpll_setup(struct device_node *node);
we should not be needing this.

>
>   #endif
>

at this point, we have a dependency between drivers/clk/omap/dpll.c and 
arch/arm/mach-omap2/ -> a possible suggestion will be to move required 
data structures first and operations as required.

-- 
Regards,
Nishanth Menon


From swarren at wwwdotorg.org  Tue Jul 30 14:25:42 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 12:25:42 -0600
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4OyMfNUR=NGn+OEvN3utcEzRfG6A4rPO6+h5Q4mq_tmoxw@mail.gmail.com>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <51F7F914.6040709@wwwdotorg.org>
 <CAKON4Oy6hL9LzHdfq4vWcurbw6TU3HCK_jq14xwweA8dvOGtdw@mail.gmail.com>
 <51F7FCA6.6010909@wwwdotorg.org>
 <CAKON4OzLgC-ahDhLnbYEYrSj7dbFRU0z7Do_D32XNqux2UhvXw@mail.gmail.com>
 <CAKON4OyMfNUR=NGn+OEvN3utcEzRfG6A4rPO6+h5Q4mq_tmoxw@mail.gmail.com>
Message-ID: <51F80526.1020201@wwwdotorg.org>

On 07/30/2013 12:04 PM, jonsmirl at gmail.com wrote:
...
> So what does an alternating use of strings do?
> 
>  dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;

cat > temp.dts << ENDOFHERE
/dts-v1/;

/ {
    dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;

    pdma0: dma { };
};
ENDOFHERE

dtc -O dtb -o temp.dtb -I dts temp.dts

hexdump -C temp.dtb

yields:

> 00000000  d0 0d fe ed 00 00 00 ab  00 00 00 38 00 00 00 98  |...........8....|
> 00000010  00 00 00 28 00 00 00 11  00 00 00 10 00 00 00 00  |...(............|
> 00000020  00 00 00 13 00 00 00 60  00 00 00 00 00 00 00 00  |.......`........|
> 00000030  00 00 00 00 00 00 00 00  00 00 00 01 00 00 00 00  |................|
> 00000040  00 00 00 03 00 00 00 16  00 00 00 00 74 78 00 00  |............tx..|
                                                 ss ss ss pp
> 00000050  00 00 01 00 00 00 07 72  78 00 00 00 00 01 00 00  |.......rx.......|
            pp pp pp ii ii ii ii ss  ss ss pp pp pp pp ii ii
> 00000060  00 06 00 00 00 00 00 01  64 6d 61 00 00 00 00 03  |........dma.....|
            ii ii

... where ss represents a string byte, pp a phandle byte, ii an integer
byte.

> 00000070  00 00 00 04 00 00 00 05  00 00 00 01 00 00 00 03  |................|
> 00000080  00 00 00 04 00 00 00 0b  00 00 00 01 00 00 00 02  |................|
> 00000090  00 00 00 02 00 00 00 09  64 6d 61 73 00 6c 69 6e  |........dmas.lin|
> 000000a0  75 78 2c 70 68 61 6e 64  6c 65 00                 |ux,phandle.|

Starting about half way through that last line is the string table.

(the string table indirection is for property names, not property
values, and it looks like not for node names either)


From jonsmirl at gmail.com  Tue Jul 30 14:26:02 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Tue, 30 Jul 2013 14:26:02 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4OyMfNUR=NGn+OEvN3utcEzRfG6A4rPO6+h5Q4mq_tmoxw@mail.gmail.com>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <51F7F914.6040709@wwwdotorg.org>
 <CAKON4Oy6hL9LzHdfq4vWcurbw6TU3HCK_jq14xwweA8dvOGtdw@mail.gmail.com>
 <51F7FCA6.6010909@wwwdotorg.org>
 <CAKON4OzLgC-ahDhLnbYEYrSj7dbFRU0z7Do_D32XNqux2UhvXw@mail.gmail.com>
 <CAKON4OyMfNUR=NGn+OEvN3utcEzRfG6A4rPO6+h5Q4mq_tmoxw@mail.gmail.com>
Message-ID: <CAKON4Oz_Suf0jjGrS8iTeLBs1K=JszuESV6Om4VRarjXqYGgpg@mail.gmail.com>

On Tue, Jul 30, 2013 at 2:04 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
> On Tue, Jul 30, 2013 at 2:03 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>> On Tue, Jul 30, 2013 at 1:49 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> On 07/30/2013 11:45 AM, jonsmirl at gmail.com wrote:
>>>> On Tue, Jul 30, 2013 at 1:34 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>>> On 07/30/2013 11:29 AM, jonsmirl at gmail.com wrote:
>>>>>> On Tue, Jul 30, 2013 at 1:19 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>>>>>
>>>>>>> On 07/30/2013 07:14 AM, jonsmirl at gmail.com wrote:
>>>>>>>> On Tue, Jul 30, 2013 at 6:25 AM, Mark Brown <broonie at kernel.org> wrote:
>>>>>>>>> On Mon, Jul 29, 2013 at 08:30:29PM -0400, jonsmirl at gmail.com wrote:
>>>>>>>>>
>>>>>>>>>> This...
>>>>>>>>>> tx-dma-channel = <&pdma0 7>; /* preliminary */
>>>>>>>>>> rx-dma-channel = <&pdma0 6>; /* preliminary */
>>>>>>>>>
>>>>>>>>>> Probably should be
>>>>>>>>>> dmas = <&pdma0 7>,<&pdma0 6>;
>>>>>>>>>> dma-names = "tx", "rx";
>>>>>>>>>
>>>>>>>>> It should be - the latter is the generic DMA binding.  There's a lot of
>>>>>>>>> bindings in the kernel that predate that but people are currently
>>>>>>>>> working to transfer over, this is one of the examples of instability
>>>>>>>>> that everyone is talking about.
>>>>>>>>
>>>>>>>> Is something similar to this possible in device tree syntax?
>>>>>>>> dmas =  <"tx" &pdma0 7>,  <"rx"  &pdma0 6>;
>>>>>>>
>>>>>>> I /think/ you can physically write that in *.dts, or something very
>>>>>>> similar; with the strings outside the <>:
>>>>>>>
>>>>>>> dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
>>>>>>>
>>>>>>> However, there's been strong push-back (i.e. doing that has not been
>>>>>>> allowed at all) on attempting to mix variable-length strings and
>>>>>>> fixed-length/alignment integer cells in the same property. This is
>>>>>>> primarily because you then can't ensure that the integer cell data is
>>>>>>> aligned in the DTB (dtc and/or the DTB format spec does/requires/allows
>>>>
>>>> The PowerPC FDT doc says that strings are indirected into a string
>>>> table. So they aren't variable length in the data structures.
>>>
>>> Do you have a link to the document; I'm not sure which one you mean.
>>
>> So it looks like there is one indirection to get to the block, then
>> the strings are concatenated. The indirection must have been hidden
>> when the node structure was created.  I had thought that there was a
>> list of indirects each pointing to a string in the string block.
>>
>> https://www.power.org/documentation/epapr-version-1-1/
>
> So what does an alternating use of strings do?
>
>  dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;

dtc compiles this string without complaint....

gpios = "str1", <&gpio0 10 1>, "str2", <&gpio0 10 1>;

It would a new helper function to interpret it but I this it should work.
I've always disliked paired attributes (dmas, dma-names) is easy to
mess them up by accident.

>
>
>>
>> 8.5 Strings Block
>> The strings block contains strings representing all the property names
>> used in the tree. These null-
>> terminated strings are simply concatenated together in this section,
>> and referred to from the structure
>> block by an offset into the strings block.
>> The strings block has no alignment constraints and may appear at any
>> offset from the beginning of the
>> device tree blob.
>>
>>
>>>
>>>> I was wondering how dmas = "tx", "rx" was implemented. It is two
>>>> pointers into the indirect block. So this should work, there is no
>>>> variable length data to worry about in the structure.
>>>
>>> If you look at of_property_read_string_index() in drivers/of/base.c,
>>> you'll see that it expects the strings to just be packed together inline.
>>>
>>> What you say may be correct for node and property names, just not
>>> property values.
>>
>>
>>
>> --
>> Jon Smirl
>> jonsmirl at gmail.com
>
>
>
> --
> Jon Smirl
> jonsmirl at gmail.com



-- 
Jon Smirl
jonsmirl at gmail.com


From jonsmirl at gmail.com  Tue Jul 30 14:28:26 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Tue, 30 Jul 2013 14:28:26 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <51F80526.1020201@wwwdotorg.org>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <51F7F914.6040709@wwwdotorg.org>
 <CAKON4Oy6hL9LzHdfq4vWcurbw6TU3HCK_jq14xwweA8dvOGtdw@mail.gmail.com>
 <51F7FCA6.6010909@wwwdotorg.org>
 <CAKON4OzLgC-ahDhLnbYEYrSj7dbFRU0z7Do_D32XNqux2UhvXw@mail.gmail.com>
 <CAKON4OyMfNUR=NGn+OEvN3utcEzRfG6A4rPO6+h5Q4mq_tmoxw@mail.gmail.com>
 <51F80526.1020201@wwwdotorg.org>
Message-ID: <CAKON4OwY3xh3UGjTxb4ypkcmrTpVYO-FZovq-ierabYMf4CDQA@mail.gmail.com>

On Tue, Jul 30, 2013 at 2:25 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/30/2013 12:04 PM, jonsmirl at gmail.com wrote:
> ...
>> So what does an alternating use of strings do?
>>
>>  dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
>
> cat > temp.dts << ENDOFHERE
> /dts-v1/;
>
> / {
>     dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
>
>     pdma0: dma { };
> };
> ENDOFHERE
>
> dtc -O dtb -o temp.dtb -I dts temp.dts
>
> hexdump -C temp.dtb
>
> yields:
>
>> 00000000  d0 0d fe ed 00 00 00 ab  00 00 00 38 00 00 00 98  |...........8....|
>> 00000010  00 00 00 28 00 00 00 11  00 00 00 10 00 00 00 00  |...(............|
>> 00000020  00 00 00 13 00 00 00 60  00 00 00 00 00 00 00 00  |.......`........|
>> 00000030  00 00 00 00 00 00 00 00  00 00 00 01 00 00 00 00  |................|
>> 00000040  00 00 00 03 00 00 00 16  00 00 00 00 74 78 00 00  |............tx..|
>                                                  ss ss ss pp
>> 00000050  00 00 01 00 00 00 07 72  78 00 00 00 00 01 00 00  |.......rx.......|
>             pp pp pp ii ii ii ii ss  ss ss pp pp pp pp ii ii
>> 00000060  00 06 00 00 00 00 00 01  64 6d 61 00 00 00 00 03  |........dma.....|
>             ii ii
>
> ... where ss represents a string byte, pp a phandle byte, ii an integer
> byte.
>
>> 00000070  00 00 00 04 00 00 00 05  00 00 00 01 00 00 00 03  |................|
>> 00000080  00 00 00 04 00 00 00 0b  00 00 00 01 00 00 00 02  |................|
>> 00000090  00 00 00 02 00 00 00 09  64 6d 61 73 00 6c 69 6e  |........dmas.lin|
>> 000000a0  75 78 2c 70 68 61 6e 64  6c 65 00                 |ux,phandle.|
>
> Starting about half way through that last line is the string table.
>
> (the string table indirection is for property names, not property
> values, and it looks like not for node names either)

Ok, so this won't work without introducing variable length data. Too
bad, I would have liked to eliminate the paired attributes.

-- 
Jon Smirl
jonsmirl at gmail.com


From r.sricharan at ti.com  Tue Jul 30 14:37:35 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Wed, 31 Jul 2013 00:07:35 +0530
Subject: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx
 based SoCs'
In-Reply-To: <20130730153138.GA5978@radagast>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-2-git-send-email-rnayak@ti.com>
 <20130730131009.GA28162@radagast> <51F7CB2F.6070705@ti.com>
 <20130730142353.GL28162@radagast> <51F7CF6F.6050702@ti.com>
 <20130730153138.GA5978@radagast>
Message-ID: <51F807EF.6020809@ti.com>

Hi,
On Tuesday 30 July 2013 09:02 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 30, 2013 at 08:06:31PM +0530, Sricharan R wrote:
>> On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote:
>>>> On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
>>>>> Hi,
>>>>>
>>>>> On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
>>>>>> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
>>>>>>  # define soc_is_omap543x()		is_omap543x()
>>>>>>  #endif
>>>>>>  
>>>>>> +# if defined(CONFIG_SOC_DRA7XX)
>>>>>> +# undef soc_is_dra7xx
>>>>>> +# undef soc_is_dra75x
>>>>>> +# define soc_is_dra7xx()		is_dra7xx()
>>>>>> +# define soc_is_dra75x()		is_dra75x()
>>>>> since this platform is DT-only, couldn't we just believe DT-data to be
>>>>> correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
>>>>>
>>>>> I patched this for OMAP5 (compile-tested only, no boards available) and
>>>>> came out with the patch below (still needs to be split):
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
>>>>> index 08b7267..b3136e5 100644
>>>>> --- a/arch/arm/boot/dts/omap5-uevm.dts
>>>>> +++ b/arch/arm/boot/dts/omap5-uevm.dts
>>>>> @@ -13,7 +13,7 @@
>>>>>  
>>>>>  / {
>>>>>  	model = "TI OMAP5 uEVM board";
>>>>> -	compatible = "ti,omap5-uevm", "ti,omap5";
>>>>> +	compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5";
>>>>>  
>>>>  ok, nice and simpler way.
>>>>  But would this make different revisions, to appear the same ?
>>> well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up,
>>> it should be treated as such, then you can pass a different string to
>>> that new board's compatible attribute.
>>> s
>>  Yes for OMAP5. I was thinking in general about this approach.
>>  For example, for OMAP4 we have same board and
>>  different revisions can be socketed there.
>>
>>  For OMAP5, this is good.
> do we really production socketed boards? Well, at least Blaze has such
> thing. But do we have too many differences that need to be trated at
> arch/arm or should/could those be handled by reading IP's revision
> register (e.g. usb host erratas)
>
 OMAP4 SDP is socketed as well.
 Ya, revision checks used only in few places and as you said
 we handle them using IP revisions, but that we have to look and clean
 up those places, if we really intend to do this for other socs.

Regards,
 Sricharan


From andrew at lunn.ch  Tue Jul 30 14:36:10 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 30 Jul 2013 20:36:10 +0200
Subject: NSA310 + DT
In-Reply-To: <20130730191943.49f8070c@skate>
References: <20130710073706.GA28212@lunn.ch> <51F6A0DC.3020501@uni-bremen.de>
 <20130729192112.GY29916@titan.lakedaemon.net>
 <20130729204315.GK24782@lunn.ch> <51F78DA6.8010307@uni-bremen.de>
 <20130730144752.GR24782@lunn.ch> <20130730172407.3aab15c6@skate>
 <51F7EBB9.7000504@uni-bremen.de> <20130730191943.49f8070c@skate>
Message-ID: <20130730183610.GT24782@lunn.ch>

On Tue, Jul 30, 2013 at 07:19:43PM +0200, Thomas Petazzoni wrote:
> Dear Finn Hoffmann,
> 
> BTW, any reason why this discussion is not taking place on LAKML ?

Ah, sorry, did not look at the CC: list. Now one list...

    Andrew

> 
> On Tue, 30 Jul 2013 18:37:13 +0200, Finn Hoffmann wrote:
> 
> > $ lspci -v
> > 00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if 
> > 00 [Normal decode])
> >          Flags: bus master, fast devsel, latency 0
> >          Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> >          I/O behind bridge: 00010000-00010fff
> >          Prefetchable memory behind bridge: e0000000-e00fffff
> 
> Ok, so there should be one mem window from e0000000 to e0100000...
> 
> > # cat /sys/kernel/debug/mvebu-mbus/devices
> > [00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap 0000000000010000)
> > [01] disabled
> > [02] disabled
> > [03] disabled
> > [04] 00000000f4000000 - 00000000f4010000 : nand
> > [05] 00000000f5000000 - 00000000f5010000 : sram
> > [06] disabled
> > [07] disabled
> 
> ... but there's none here.
> 
> Seems like your device is using a prefetchable memory window, and our
> emulated PCI-to-PCI bridge isn't taking this into account.
> 
> Can you test the below (completely untested) patch? Regardless of
> whether it works or not, I'm interested in seeing the "PCI MVEBU"
> debug messages that I've added, as well as the output
> of /sys/kernel/debug/mvebu-mbus/devices.
> 
> Thanks a lot!
> 
> Thomas
> 
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index 13a633b..641dd3d 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -129,6 +129,8 @@ struct mvebu_pcie_port {
>  	struct mvebu_pcie *pcie;
>  	phys_addr_t memwin_base;
>  	size_t memwin_size;
> +	phys_addr_t prefmemwin_base;
> +	size_t prefmemwin_size;
>  	phys_addr_t iowin_base;
>  	size_t iowin_size;
>  };
> @@ -348,6 +350,39 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
>  					  MVEBU_MBUS_PCI_MEM);
>  }
>  
> +static void mvebu_pcie_handle_prefmembase_change(struct mvebu_pcie_port *port)
> +{
> +	/* Are the new membase/memlimit values invalid? */
> +	if (port->bridge.prefmemlimit < port->bridge.prefmembase) {
> +
> +		/* If a window was configured, remove it */
> +		if (port->prefmemwin_base) {
> +			mvebu_mbus_del_window(port->prefmemwin_base,
> +					      port->prefmemwin_size);
> +			port->prefmemwin_base = 0;
> +			port->prefmemwin_size = 0;
> +		}
> +
> +		return;
> +	}
> +
> +	/*
> +	 * We read the PCI-to-PCI bridge emulated registers, and
> +	 * calculate the base address and size of the address decoding
> +	 * window to setup, according to the PCI-to-PCI bridge
> +	 * specifications.
> +	 */
> +	port->prefmemwin_base  = ((port->bridge.prefmembase & 0xFFF0) << 16);
> +	port->prefmemwin_size  =
> +		(((port->bridge.prefmemlimit & 0xFFF0) << 16) | 0xFFFFF) -
> +		port->prefmemwin_base;
> +
> +	mvebu_mbus_add_window_remap_flags(port->name, port->prefmemwin_base,
> +					  port->prefmemwin_size,
> +					  MVEBU_MBUS_NO_REMAP,
> +					  MVEBU_MBUS_PCI_MEM);
> +}
> +
>  /*
>   * Initialize the configuration space of the PCI-to-PCI bridge
>   * associated with the given PCIe interface.
> @@ -492,18 +527,28 @@ static int mvebu_sw_pci_bridge_write(struct mvebu_pcie_port *port,
>  		bridge->iobase = (value & 0xff) | PCI_IO_RANGE_TYPE_32;
>  		bridge->iolimit = ((value >> 8) & 0xff) | PCI_IO_RANGE_TYPE_32;
>  		bridge->secondary_status = value >> 16;
> +		pr_info("MVEBU PCI %d.%d: new io, base 0x%x, limit 0x%x\n",
> +			port->port, port->lane,
> +			bridge->iobase, bridge->iolimit);
>  		mvebu_pcie_handle_iobase_change(port);
>  		break;
>  
>  	case PCI_MEMORY_BASE:
>  		bridge->membase = value & 0xffff;
>  		bridge->memlimit = value >> 16;
> +		pr_info("MVEBU PCI %d.%d: new mem, base 0x%x, limit 0x%x\n",
> +			port->port, port->lane,
> +			bridge->membase, bridge->memlimit);
>  		mvebu_pcie_handle_membase_change(port);
>  		break;
>  
>  	case PCI_PREF_MEMORY_BASE:
>  		bridge->prefmembase = value & 0xffff;
>  		bridge->prefmemlimit = value >> 16;
> +		pr_info("MVEBU PCI %d.%d: new pref mem, base 0x%x, limit 0x%x\n",
> +			port->port, port->lane,
> +			bridge->prefmembase, bridge->prefmemlimit);
> +		mvebu_pcie_handle_prefmembase_change(port);
>  		break;
>  
>  	case PCI_PREF_BASE_UPPER32:
> 
> 
> -- 
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com


From nm at ti.com  Tue Jul 30 14:40:40 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 13:40:40 -0500
Subject: [PATCHv4 05/33] CLK: omap: add DT duplicate clock registration
 mechanism
In-Reply-To: <1374564028-11352-6-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-6-git-send-email-t-kristo@ti.com>
Message-ID: <51F808A8.6000503@ti.com>

On 07/23/2013 02:20 AM, Tero Kristo wrote:
> Some devices require their clocks to be available with a specific
> dev-id con-id mapping. With DT, the clocks can be found by default
> only with their name, or alternatively through the device node of
> the consumer. With drivers, that don't support DT fully yet, add
> mechanism to register specific clock names.
>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>

with this, should it not be enough to add clocks=<&phandle>

I am not sure I understand what specific drivers should need to carry 
this "old hack" forward. More importantly, why is it preferable to carry 
the hack forward rather than fixing the drivers.


> ---
>   drivers/clk/omap/clk.c   |   39 +++++++++++++++++++++++++++++++++++++++
>   include/linux/clk/omap.h |   17 +++++++++++++++++
>   2 files changed, 56 insertions(+)
>
> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
> index 1dafdaa..cd31a81 100644
> --- a/drivers/clk/omap/clk.c
> +++ b/drivers/clk/omap/clk.c
> @@ -32,6 +32,45 @@ static const struct of_device_id clk_match[] = {
>   	{},
>   };
>
> + /**
> + * omap_dt_clocks_register - register DT duplicate clocks during boot
> + * @oclks: list of clocks to register
> + * @cnt: number of clocks
> + *
> + * Register duplicate or non-standard DT clock entries during boot. By
> + * default, DT clocks are found based on their node name. If any
> + * additional con-id / dev-id -> clock mapping is required, use this
> + * function to list these.
> + */
> +void __init omap_dt_clocks_register(struct omap_dt_clk oclks[], int cnt)

Cant we use a NULL terminated array? then we dont need to pass cnt.

> +{
> +	struct omap_dt_clk *c;
> +	struct device_node *n;
> +	struct clk *clk;
> +	struct of_phandle_args clkspec;
> +
> +	for (c = oclks; c < oclks + cnt; c++) {
> +		n = of_find_node_by_name(NULL, c->node_name);
> +
> +		if (!n) {
> +			pr_err("%s: %s not found!\n", __func__, c->node_name);
> +			continue;
> +		}
> +
> +		clkspec.np = n;
> +
> +		clk = of_clk_get_from_provider(&clkspec);
> +
> +		if (!clk) {
> +			pr_err("%s: %s has no clock!\n", __func__,
> +				c->node_name);
> +			continue;
> +		}
> +		c->lk.clk = clk;
> +		clkdev_add(&c->lk);

why not clk_add_alias ?

> +	}
> +}
> +
>   /* FIXME - need to initialize early; skip real driver registration & probe */
>   int __init dt_omap_clk_init(void)
>   {
> diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
> index cba892a..c39e775 100644
> --- a/include/linux/clk/omap.h
> +++ b/include/linux/clk/omap.h
> @@ -19,6 +19,8 @@
>   #ifndef __LINUX_CLK_OMAP_H_
>   #define __LINUX_CLK_OMAP_H_
>
> +#include <linux/clkdev.h>
> +
>   /**
>    * struct dpll_data - DPLL registers and integration data
>    * @mult_div1_reg: register containing the DPLL M and N bitfields
> @@ -146,6 +148,20 @@ struct clk_hw_omap_ops {
>   	void			(*deny_idle)(struct clk_hw_omap *oclk);
>   };
>
> +struct omap_dt_clk {
> +	struct clk_lookup		lk;
> +	const char			*node_name;
> +};
> +

documentation missing.

> +#define DT_CLK(dev, con, name)		\
> +	{				\
> +		.lk = {			\
> +			.dev_id = dev,	\
> +			.con_id = con,	\
> +		},			\
> +		.node_name = name,	\
> +	}
> +
>   void omap2_init_clk_hw_omap_clocks(struct clk *clk);
>   int omap3_noncore_dpll_enable(struct clk_hw *hw);
>   void omap3_noncore_dpll_disable(struct clk_hw *hw);
> @@ -174,6 +190,7 @@ extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx;
>
>   /* DT functions */
>   int dt_omap_clk_init(void);
> +extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int cnt);

do you need the extern?

>   void of_omap4_dpll_setup(struct device_node *node);
>
>   #endif
>


-- 
Regards,
Nishanth Menon


From nm at ti.com  Tue Jul 30 14:43:05 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 13:43:05 -0500
Subject: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx
 based SoCs'
In-Reply-To: <51F807EF.6020809@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-2-git-send-email-rnayak@ti.com>
 <20130730131009.GA28162@radagast> <51F7CB2F.6070705@ti.com>
 <20130730142353.GL28162@radagast> <51F7CF6F.6050702@ti.com>
 <20130730153138.GA5978@radagast> <51F807EF.6020809@ti.com>
Message-ID: <51F80939.7060403@ti.com>

On 07/30/2013 01:37 PM, Sricharan R wrote:
> Hi,
> On Tuesday 30 July 2013 09:02 PM, Felipe Balbi wrote:
>> Hi,
>>
>> On Tue, Jul 30, 2013 at 08:06:31PM +0530, Sricharan R wrote:
>>> On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote:
>>>> Hi,
>>>>
>>>> On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote:
>>>>> On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
>>>>>>> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
>>>>>>>   # define soc_is_omap543x()		is_omap543x()
>>>>>>>   #endif
>>>>>>>
>>>>>>> +# if defined(CONFIG_SOC_DRA7XX)
>>>>>>> +# undef soc_is_dra7xx
>>>>>>> +# undef soc_is_dra75x
>>>>>>> +# define soc_is_dra7xx()		is_dra7xx()
>>>>>>> +# define soc_is_dra75x()		is_dra75x()
>>>>>> since this platform is DT-only, couldn't we just believe DT-data to be
>>>>>> correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
>>>>>>
>>>>>> I patched this for OMAP5 (compile-tested only, no boards available) and
>>>>>> came out with the patch below (still needs to be split):
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
>>>>>> index 08b7267..b3136e5 100644
>>>>>> --- a/arch/arm/boot/dts/omap5-uevm.dts
>>>>>> +++ b/arch/arm/boot/dts/omap5-uevm.dts
>>>>>> @@ -13,7 +13,7 @@
>>>>>>
>>>>>>   / {
>>>>>>   	model = "TI OMAP5 uEVM board";
>>>>>> -	compatible = "ti,omap5-uevm", "ti,omap5";
>>>>>> +	compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5";
>>>>>>
>>>>>   ok, nice and simpler way.
>>>>>   But would this make different revisions, to appear the same ?
>>>> well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up,
>>>> it should be treated as such, then you can pass a different string to
>>>> that new board's compatible attribute.
>>>> s
>>>   Yes for OMAP5. I was thinking in general about this approach.
>>>   For example, for OMAP4 we have same board and
>>>   different revisions can be socketed there.
>>>
>>>   For OMAP5, this is good.
>> do we really production socketed boards? Well, at least Blaze has such
>> thing. But do we have too many differences that need to be trated at
>> arch/arm or should/could those be handled by reading IP's revision
>> register (e.g. usb host erratas)
>>
>   OMAP4 SDP is socketed as well.
a) OMAP4SDP is not production device
b) OMAP4SDP uses SOM (System On Module)
c) Socketted SOMs were used only during initial days of SoC
d) almost all latest OMAP4 SDP switched to using soldered in SOM
e) we claim compatibility of OMAP4 SDP with Blaze.

So, I dont think this is a rational argument for keeping soc checks with 
dts.

>   Ya, revision checks used only in few places and as you said
>   we handle them using IP revisions, but that we have to look and clean
>   up those places, if we really intend to do this for other socs.

I agree this is the right approach :).


-- 
Regards,
Nishanth Menon


From john.stultz at linaro.org  Tue Jul 30 14:50:49 2013
From: john.stultz at linaro.org (John Stultz)
Date: Tue, 30 Jul 2013 11:50:49 -0700
Subject: [GIT PULL] 64bit friendly generic sched_clock() base for 3.12
Message-ID: <51F80B09.8060509@linaro.org>

Hey Thomas, Olof,
     Here is the common base changes in Stephen's "64bit friendly 
generic sched_clock()" patch series. This common base will be needed so 
that following patch series can be merged via both the tip/timers/core 
and arm-soc trees independently.

Please let me know if you have any issues or objections with this set.

thanks
-john


The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

   Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

   git://git.linaro.org/people/jstultz/linux.git 
fortglx/3.12/sched-clock64-base

for you to fetch changes up to e7e3ff1bfe9c42ee31172e9afdc0383a9e595e29:

   sched_clock: Add support for >32 bit sched_clock (2013-07-30 11:24:21 
-0700)

----------------------------------------------------------------
Stephen Boyd (4):
       clocksource: Extract max nsec calculation into separate function
       sched_clock: Use seqcount instead of rolling our own
       sched_clock: Use an hrtimer instead of timer
       sched_clock: Add support for >32 bit sched_clock

  include/linux/clocksource.h |   2 +
  include/linux/sched_clock.h |   2 +
  kernel/time/clocksource.c   |  45 ++++++++++++------
  kernel/time/sched_clock.c   | 111 
++++++++++++++++++++++++--------------------
  4 files changed, 95 insertions(+), 65 deletions(-)


From nm at ti.com  Tue Jul 30 14:56:55 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 13:56:55 -0500
Subject: [PATCHv4 06/33] CLK: omap: add autoidle support
In-Reply-To: <1374564028-11352-7-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-7-git-send-email-t-kristo@ti.com>
Message-ID: <51F80C77.9020109@ti.com>

On 07/23/2013 02:20 AM, Tero Kristo wrote:
> OMAP clk driver now routes some of the basic clocks through own
> registration routine to allow autoidle support. This routine just
> checks a couple of device node properties and adds autoidle support
> if required, and just passes the registration forward to basic clocks.

why not extend standard framework to support autoidle capable clocks OR 
introduce our own clk node which depends on basic clocks?
>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
>   arch/arm/mach-omap2/clock.c |    6 ++
>   drivers/clk/omap/Makefile   |    2 +-
>   drivers/clk/omap/autoidle.c |  130 +++++++++++++++++++++++++++++++++++++++++++
>   drivers/clk/omap/clk.c      |    4 +-
>   include/linux/clk/omap.h    |    4 ++
>   5 files changed, 143 insertions(+), 3 deletions(-)
>   create mode 100644 drivers/clk/omap/autoidle.c

I know it is getting a little stale, but anyways, device tree binding 
missing.

>
> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
> index 0c38ca9..669d4c4 100644
> --- a/arch/arm/mach-omap2/clock.c
> +++ b/arch/arm/mach-omap2/clock.c
Not sure why, at this point in time we are going to calling drivers/clk 
code.

> @@ -520,6 +520,9 @@ int omap2_clk_enable_autoidle_all(void)
>   	list_for_each_entry(c, &clk_hw_omap_clocks, node)
>   		if (c->ops && c->ops->allow_idle)
>   			c->ops->allow_idle(c);
> +
> +	of_omap_clk_allow_autoidle_all();
> +
>   	return 0;
>   }
>
> @@ -539,6 +542,9 @@ int omap2_clk_disable_autoidle_all(void)
>   	list_for_each_entry(c, &clk_hw_omap_clocks, node)
>   		if (c->ops && c->ops->deny_idle)
>   			c->ops->deny_idle(c);
> +
> +	of_omap_clk_deny_autoidle_all();
> +

these are defined for CONFIG_OF.. anyways, without dt nodes (OMAP3 is 
supposed to support non-DT boot even now), this would not work, would it?


>   	return 0;
>   }
>
> diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
> index 4cad480..ca56700 100644
> --- a/drivers/clk/omap/Makefile
> +++ b/drivers/clk/omap/Makefile
> @@ -1 +1 @@
> -obj-y					+= clk.o dpll.o
> +obj-y					+= clk.o dpll.o autoidle.o
> diff --git a/drivers/clk/omap/autoidle.c b/drivers/clk/omap/autoidle.c
> new file mode 100644
> index 0000000..6424cb2
> --- /dev/null
> +++ b/drivers/clk/omap/autoidle.c
> @@ -0,0 +1,130 @@
> +/*
> + * OMAP clock autoidle support
> + *
> + * Copyright (C) 2013 Texas Instruments, Inc.
> + *
> + * Tero Kristo <t-kristo at ti.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/io.h>
> +#include <linux/err.h>
> +#include <linux/string.h>
> +#include <linux/log2.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
at all of these required?

> +
> +#ifdef CONFIG_OF
> +struct clk_omap_autoidle {
> +	void __iomem		*reg;
> +	u8			shift;
> +	u8			flags;
> +	const char		*name;
> +	struct list_head	node;
> +};
> +
> +#define AUTOIDLE_LOW		0x1
> +
> +static LIST_HEAD(autoidle_clks);
> +
> +static void omap_allow_autoidle(struct clk_omap_autoidle *clk)
> +{
> +	u32 val;
> +
> +	val = readl(clk->reg);
> +
> +	if (clk->flags & AUTOIDLE_LOW)
> +		val &= ~(1 << clk->shift);
> +	else
> +		val |= (1 << clk->shift);
> +
> +	writel(val, clk->reg);
> +}
> +
> +static void omap_deny_autoidle(struct clk_omap_autoidle *clk)
> +{
> +	u32 val;
> +
> +	val = readl(clk->reg);
> +
> +	if (clk->flags & AUTOIDLE_LOW)
> +		val |= (1 << clk->shift);
> +	else
> +		val &= ~(1 << clk->shift);
> +
> +	writel(val, clk->reg);
> +}
> +
> +void of_omap_clk_allow_autoidle_all(void)
> +{
> +	struct clk_omap_autoidle *c;
> +
> +	list_for_each_entry(c, &autoidle_clks, node)
> +		omap_allow_autoidle(c);
> +}
> +
> +void of_omap_clk_deny_autoidle_all(void)
> +{
> +	struct clk_omap_autoidle *c;
> +
> +	list_for_each_entry(c, &autoidle_clks, node)
> +		omap_deny_autoidle(c);
> +}
> +
> +static __init void of_omap_autoidle_setup(struct device_node *node)
> +{
> +	u32 shift;
> +	void __iomem *reg;
> +	struct clk_omap_autoidle *clk;
> +
> +	if (of_property_read_u32(node, "ti,autoidle-shift", &shift))
> +		return;
> +
> +	reg = of_iomap(node, 0);
> +
> +	clk = kzalloc(sizeof(struct clk_omap_autoidle), GFP_KERNEL);
> +
> +	if (!clk) {
> +		pr_err("%s: kzalloc failed\n", __func__);
> +		return;
> +	}
> +
> +	clk->shift = shift;
> +	clk->name = node->name;
> +	clk->reg = reg;
> +
> +	if (of_property_read_bool(node, "ti,autoidle-low"))
> +		clk->flags |= AUTOIDLE_LOW;
> +
> +	list_add(&clk->node, &autoidle_clks);
> +}
> +
> +void __init of_omap_divider_setup(struct device_node *node)
> +{
> +	of_divider_clk_setup(node);
> +	of_omap_autoidle_setup(node);
> +}
> +EXPORT_SYMBOL_GPL(of_omap_divider_setup);
> +CLK_OF_DECLARE(omap_autoidle_clock, "divider-clock", of_omap_divider_setup);

This is overriding drivers/clk/clk-divider.c ?
> +
> +void __init of_omap_fixed_factor_setup(struct device_node *node)
> +{
> +	of_fixed_factor_clk_setup(node);
> +	of_omap_autoidle_setup(node);
> +}
> +EXPORT_SYMBOL_GPL(of_omap_fixed_factor_setup);
> +CLK_OF_DECLARE(omap_fixed_factor_clock, "fixed-factor-clock",
> +	of_omap_fixed_factor_setup);

This is overriding drivers/clk/clk-fixed-factor.c ?
> +
> +#endif
> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
> index cd31a81..c149097 100644
> --- a/drivers/clk/omap/clk.c
> +++ b/drivers/clk/omap/clk.c
> @@ -25,8 +25,8 @@ static const struct of_device_id clk_match[] = {
>   	{.compatible = "fixed-clock", .data = of_fixed_clk_setup, },
>   	{.compatible = "mux-clock", .data = of_mux_clk_setup, },
>   	{.compatible = "fixed-factor-clock",
> -		.data = of_fixed_factor_clk_setup, },
> -	{.compatible = "divider-clock", .data = of_divider_clk_setup, },
> +		.data = of_omap_fixed_factor_setup, },
> +	{.compatible = "divider-clock", .data = of_omap_divider_setup, },
>   	{.compatible = "gate-clock", .data = of_gate_clk_setup, },
>   	{.compatible = "ti,omap4-dpll-clock", .data = of_omap4_dpll_setup, },
>   	{},
> diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
> index c39e775..904bdad 100644
> --- a/include/linux/clk/omap.h
> +++ b/include/linux/clk/omap.h
> @@ -192,5 +192,9 @@ extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx;
>   int dt_omap_clk_init(void);
>   extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int cnt);
>   void of_omap4_dpll_setup(struct device_node *node);
> +void of_omap_fixed_factor_setup(struct device_node *node);
> +void of_omap_divider_setup(struct device_node *node);
> +void of_omap_clk_allow_autoidle_all(void);
> +void of_omap_clk_deny_autoidle_all(void);
>
>   #endif
>

I personally dont prefer the fact that divider-clock and 
fixed-rate-clock now has double meaning - building a multi-arch kernel 
for example, this can wreak havoc. standard definitions should not be 
monkeyed around with thus if avoidable, and in this case, very much 
avoidable.

just my 2 cents.
-- 
Regards,
Nishanth Menon


From keescook at chromium.org  Tue Jul 30 15:05:40 2013
From: keescook at chromium.org (Kees Cook)
Date: Tue, 30 Jul 2013 12:05:40 -0700
Subject: [ARM ATTEND] catching up on exploit mitigations
Message-ID: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>

I'd like to propose the topic of catching up to x86 exploit
mitigations and security features, and potentially identifying
ARM-unique mitigations/features that could be implemented. Several
years ago, with Nicolas Pitre doing all the real work, I coordinated
getting ARM caught up on things like userspace ASLR and
stack-protector. Recently, based on work by Will Drewry, I ported
seccomp-bpf to ARM. I'd like to continue this kind of thing, and I
think it's overdue to examine this area again. A lot of work has
already been done by grsecurity in this area (see
http://forums.grsecurity.net/viewtopic.php?f=7&t=3292), so it would be
good to start there.

While it may expose my current ignorance of low level ARM mechanics,
I'd like to examine and discuss:

- RO and W^X kernel page table protections (similar to x86's
DEBUG_RODATA and DEBUG_SET_MODULE_RONX; it's not clear to me how much
LPAE and PXN is already handling this, if at all)

- something like x86's SMEP and SMAP (to deter kernel exploitation
from userspace)

- vector table protections (needs to be protected like the x86_64
vsyscall table, RO, etc)

- kernel ASLR (I'm close to having this upstreamable for x86)

- fuzzing (is anyone running trinity or similar on the ARM tree?)

- any other things ... ?

Thanks,

-Kees

-- 
Kees Cook
Chrome OS Security


From sergei.shtylyov at cogentembedded.com  Tue Jul 30 15:07:21 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 30 Jul 2013 23:07:21 +0400
Subject: [PATCH 08/10] ARM: sun7i: DT: Add UART muxing options to the DTSI
In-Reply-To: <1375196394-21138-9-git-send-email-maxime.ripard@free-electrons.com>
References: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375196394-21138-9-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <51F80EE9.30801@cogentembedded.com>

Hello.

On 07/30/2013 06:59 PM, Maxime Ripard wrote:

> The UARTs on the A20 can be muxed to several pins. Add a few options to
> the DTSI so that we can start using them in the boards' DT.

> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>   arch/arm/boot/dts/sun7i-a20.dtsi | 21 +++++++++++++++++++++
>   1 file changed, 21 insertions(+)

> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 704fca9..9f45e8d 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -70,6 +70,27 @@
>   			#address-cells = <1>;
>   			#size-cells = <0>;
>   			#gpio-cells = <3>;
> +
> +			uart0_pins_a: uart0 at 0 {

    Why have address part of the node name if there's not "reg" property?
And the preferred node name is "serial", not "uart", according to the ePAPR 
spec (http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf).

> +				allwinner,pins = "PB22", "PB23";
> +				allwinner,function = "uart0";
> +				allwinner,drive = <0>;
> +				allwinner,pull = <0>;
> +			};
> +
> +			uart6_pins_a: uart6 at 0 {
> +				allwinner,pins = "PI12", "PI13";
> +				allwinner,function = "uart6";
> +				allwinner,drive = <0>;
> +				allwinner,pull = <0>;
> +			};
> +
> +			uart7_pins_a: uart7 at 0 {
> +				allwinner,pins = "PI20", "PI21";
> +				allwinner,function = "uart7";
> +				allwinner,drive = <0>;
> +				allwinner,pull = <0>;
> +			};

WBR, Sergei



From nicolas.pitre at linaro.org  Tue Jul 30 15:15:02 2013
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 30 Jul 2013 15:15:02 -0400 (EDT)
Subject: [PATCH 12/13] ARM: bL_switcher: remove assumptions between
 logical and physical CPUs
In-Reply-To: <20130730163010.GA8921@e102568-lin.cambridge.arm.com>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-13-git-send-email-nicolas.pitre@linaro.org>
 <20130730163010.GA8921@e102568-lin.cambridge.arm.com>
Message-ID: <alpine.LFD.2.03.1307301502120.15022@syhkavp.arg>

On Tue, 30 Jul 2013, Lorenzo Pieralisi wrote:

> On Tue, Jul 23, 2013 at 04:31:28AM +0100, Nicolas Pitre wrote:
> > Up to now, the logical CPU was somehow tied to the physical CPU number
> > within a cluster.  This causes problems when forcing the boot CPU to be
> > different from the first enumerated CPU in the device tree creating a
> > discrepancy between logical and physical CPU numbers.
> > 
> > Let's make the pairing completely independent from physical CPU numbers.
> > 
> > Let's keep only those logical CPUs with same initial CPU cluster to create
> > a uniform scheduler profile without having to modify any of the probed
> > topology and compute capacity data.  This has the potential to create
> > a non contiguous CPU numbering space when the switcher is active with
> > potential impact on buggy user space tools.  It is however better to fix
> > those tools rather than making the switcher code more intrusive.
> 
> Nico, I am not following you here. Is this not the same problem we
> have in a system where we hotplug out some of the CPUs in the logical map ?

Yes, it is.  Although with the switcher, user space does initialize with 
holes in the logical CPU map since some CPUs have been hotplugged out 
before the boot completed which is something some tools are not 
expecting.  And it did cause problems with Android for example, although 
that has been fixed now.

> [...]
> 
> >  static void bL_switcher_restore_cpus(void)
> > @@ -319,52 +322,86 @@ static void bL_switcher_restore_cpus(void)
> >  
> >  static int bL_switcher_halve_cpus(void)
> >  {
> > -	int cpu, cluster, i, ret;
> > -	cpumask_t cluster_mask[2], common_mask;
> > -
> > -	cpumask_clear(&bL_switcher_removed_logical_cpus);
> > -	cpumask_clear(&cluster_mask[0]);
> > -	cpumask_clear(&cluster_mask[1]);
> > +	int i, j, cluster_0, gic_id, ret;
> > +	unsigned int cpu, cluster, mask;
> > +	cpumask_t available_cpus;
> >  
> > +	/* First pass to validate what we have */
> > +	mask = 0;
> >  	for_each_online_cpu(i) {
> > -		cpu = cpu_logical_map(i) & 0xff;
> > -		cluster = (cpu_logical_map(i) >> 8) & 0xff;
> > +		cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 0);
> > +		cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 1);
> >  		if (cluster >= 2) {
> >  			pr_err("%s: only dual cluster systems are supported\n", __func__);
> >  			return -EINVAL;
> >  		}
> > -		cpumask_set_cpu(cpu, &cluster_mask[cluster]);
> > +		if (WARN_ON(cpu >= MAX_CPUS_PER_CLUSTER))
> 
> pr_warn ?

I dunno.  What's the policy for choosing between those two?
Obviously this is a "shouldn't happen" case.

> 
> > +			return -EINVAL;
> > +		mask |= (1 << cluster);
> >  	}
> > -
> > -	if (!cpumask_and(&common_mask, &cluster_mask[0], &cluster_mask[1])) {
> > -		pr_err("%s: no common set of CPUs\n", __func__);
> > +	if (mask != 3) {
> 
> Technically, you might have two clusters with eg MPIDR[15:8] = {0,2}
> this would break this code. Just saying, I know for now we can live with that.
> Given that's the only usage of mask you might use a counter, just as well.

Well, there are assumptions about the cluster encoding all over the 
place, so this is a stop gap to trap anything which is not following the 
0,1 enumeration.

This assumption could be fixed eventually if it turns to e false on some 
hardware.

> > +		pr_err("%s: no CPU pairing possible\n", __func__);
> >  		return -EINVAL;
> >  	}
> >  
> > -	for_each_online_cpu(i) {
> > -		cpu = cpu_logical_map(i) & 0xff;
> > -		cluster = (cpu_logical_map(i) >> 8) & 0xff;
> > -
> > -		if (cpumask_test_cpu(cpu, &common_mask)) {
> > -			/* Let's take note of the GIC ID for this CPU */
> > -			int gic_id = gic_get_cpu_id(i);
> > -			if (gic_id < 0) {
> > -				pr_err("%s: bad GIC ID for CPU %d\n", __func__, i);
> > -				return -EINVAL;
> > -			}
> > -			bL_gic_id[cpu][cluster] = gic_id;
> > -			pr_info("GIC ID for CPU %u cluster %u is %u\n",
> > -				cpu, cluster, gic_id);
> > -
> > +	/*
> > +	 * Now let's do the pairing.  We match each CPU with another CPU
> > +	 * from a different cluster.  To get a uniform scheduling behavior
> > +	 * without fiddling with CPU topology and compute capacity data,
> > +	 * we'll use logical CPUs initially belonging to the same cluster.
> > +	 */
> > +	memset(bL_switcher_cpu_pairing, -1, sizeof(bL_switcher_cpu_pairing));
> > +	cpumask_copy(&available_cpus, cpu_online_mask);
> > +	cluster_0 = -1;
> > +	for_each_cpu(i, &available_cpus) {
> > +		int match = -1;
> > +		cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 1);
> > +		if (cluster_0 == -1)
> > +			cluster_0 = cluster;
> > +		if (cluster != cluster_0)
> > +			continue;
> > +		cpumask_clear_cpu(i, &available_cpus);
> > +		for_each_cpu(j, &available_cpus) {
> > +			cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(j), 1);
> >  			/*
> > -			 * We keep only those logical CPUs which number
> > -			 * is equal to their physical CPU number. This is
> > -			 * not perfect but good enough for now.
> > +			 * Let's remember the last match to create "odd"
> > +			 * pairings on purpose in order for other code not
> > +			 * to assume any relation between physical and
> > +			 * logical CPU numbers.
> >  			 */
> > -			if (cpu == i) {
> > -				bL_switcher_cpu_original_cluster[cpu] = cluster;
> > -				continue;
> > -			}
> > +			if (cluster != cluster_0)
> > +				match = j;
> > +		}
> > +		if (match != -1) {
> > +			bL_switcher_cpu_pairing[i] = match;
> > +			cpumask_clear_cpu(match, &available_cpus);
> > +			pr_info("CPU%d paired with CPU%d\n", i, match);
> > +		}
> > +	}
> > +
> > +	/*
> > +	 * Now we disable the unwanted CPUs i.e. everything that has no
> > +	 * pairing information (that includes the pairing counterparts).
> > +	 */
> > +	cpumask_clear(&bL_switcher_removed_logical_cpus);
> > +	for_each_online_cpu(i) {
> > +		cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 0);
> > +		cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 1);
> > +
> > +		/* Let's take note of the GIC ID for this CPU */
> > +		gic_id = gic_get_cpu_id(i);
> > +		if (gic_id < 0) {
> > +			pr_err("%s: bad GIC ID for CPU %d\n", __func__, i);
> > +			bL_switcher_restore_cpus();
> > +			return -EINVAL;
> > +		}
> > +		bL_gic_id[cpu][cluster] = gic_id;
> > +		pr_info("GIC ID for CPU %u cluster %u is %u\n",
> > +			cpu, cluster, gic_id);
> > +
> > +		if (bL_switcher_cpu_pairing[i] != -1) {
> > +			bL_switcher_cpu_original_cluster[i] = cluster;
> > +			continue;
> >  		}
> >  
> >  		ret = cpu_down(i);
> > @@ -415,7 +452,7 @@ static int bL_switcher_enable(void)
> >  
> >  static void bL_switcher_disable(void)
> >  {
> > -	unsigned int cpu, cluster, i;
> > +	unsigned int cpu, cluster;
> >  	struct bL_thread *t;
> >  	struct task_struct *task;
> >  
> > @@ -435,7 +472,6 @@ static void bL_switcher_disable(void)
> >  	 * possibility for interference from external requests.
> >  	 */
> >  	for_each_online_cpu(cpu) {
> > -		BUG_ON(cpu != (cpu_logical_map(cpu) & 0xff));
> >  		t = &bL_threads[cpu];
> >  		task = t->task;
> >  		t->task = NULL;
> > @@ -459,14 +495,10 @@ static void bL_switcher_disable(void)
> >  		/* If execution gets here, we're in trouble. */
> >  		pr_crit("%s: unable to restore original cluster for CPU %d\n",
> >  			__func__, cpu);
> > -		for_each_cpu(i, &bL_switcher_removed_logical_cpus) {
> > -			if ((cpu_logical_map(i) & 0xff) != cpu)
> > -				continue;
> > -			pr_crit("%s: CPU %d can't be restored\n",
> > -				__func__, i);
> > -			cpumask_clear_cpu(i, &bL_switcher_removed_logical_cpus);
> > -			break;
> > -		}
> > +		pr_crit("%s: CPU %d can't be restored\n",
> > +			__func__, bL_switcher_cpu_pairing[cpu]);
> > +		cpumask_clear_cpu(bL_switcher_cpu_pairing[cpu],
> > +				  &bL_switcher_removed_logical_cpus);
> >  	}
> >  
> >  	bL_switcher_restore_cpus();
> > -- 
> 
> Other than that:
> 
> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

Thanks.


Nicolas


> 


From nm at ti.com  Tue Jul 30 15:17:28 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 14:17:28 -0500
Subject: [PATCHv4 07/33] CLK: omap: add support for OMAP gate clock
In-Reply-To: <1374564028-11352-8-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-8-git-send-email-t-kristo@ti.com>
Message-ID: <51F81148.4080203@ti.com>

On 07/23/2013 02:20 AM, Tero Kristo wrote:
> This node adds support for a clock node which allows control to the
> clockdomain enable / disable.

Dont we have clkdm_enable/disable for the same? should we model 
clockdomain as a clock node?

>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
>   drivers/clk/omap/Makefile |    2 +-
>   drivers/clk/omap/clk.c    |    1 +
>   drivers/clk/omap/gate.c   |   88 +++++++++++++++++++++++++++++++++++++++++++++
>   include/linux/clk/omap.h  |    1 +
>   4 files changed, 91 insertions(+), 1 deletion(-)
>   create mode 100644 drivers/clk/omap/gate.c
>

my usual crib: device tree binding documentation is missing

> diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
> index ca56700..3d3ca30f 100644
> --- a/drivers/clk/omap/Makefile
> +++ b/drivers/clk/omap/Makefile
> @@ -1 +1 @@
> -obj-y					+= clk.o dpll.o autoidle.o
> +obj-y					+= clk.o dpll.o autoidle.o gate.o
> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
> index c149097..8c89714 100644
> --- a/drivers/clk/omap/clk.c
> +++ b/drivers/clk/omap/clk.c
> @@ -29,6 +29,7 @@ static const struct of_device_id clk_match[] = {
>   	{.compatible = "divider-clock", .data = of_omap_divider_setup, },
>   	{.compatible = "gate-clock", .data = of_gate_clk_setup, },
>   	{.compatible = "ti,omap4-dpll-clock", .data = of_omap4_dpll_setup, },
> +	{.compatible = "ti,gate-clock", .data = of_omap_gate_clk_setup, },

I am a little lost - is there any SoC dts that actually uses this? at 
least this series does not seem to introduce any node that uses this 
compatibility as per git grep :(

might as well drop the patch?

>   	{},
>   };
>
> diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
> new file mode 100644
> index 0000000..7186bb2
> --- /dev/null
> +++ b/drivers/clk/omap/gate.c
> @@ -0,0 +1,88 @@
> +/*
> + * OMAP gate clock support
> + *
> + * Copyright (C) 2013 Texas Instruments, Inc.
> + *
> + * Tero Kristo <t-kristo at ti.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/io.h>
> +#include <linux/err.h>
> +#include <linux/string.h>
> +#include <linux/log2.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/clk/omap.h>
> +
> +#ifdef CONFIG_OF
> +
> +static const struct clk_ops omap_gate_clk_ops = {
> +	.init		= &omap2_init_clk_clkdm,
> +	.enable		= &omap2_clkops_enable_clkdm,
> +	.disable	= &omap2_clkops_disable_clkdm,
> +};
> +
> +void __init of_omap_gate_clk_setup(struct device_node *node)
> +{
> +	struct clk *clk;
> +	struct clk_init_data init;
init = { 0 };
> +	struct clk_hw_omap *clk_hw;
> +	const char *clk_name = node->name;
> +	int num_parents;
> +	const char **parent_names;
> +	int i;
> +
> +	clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
kzalloc(sizeof(*clk_hw)...) over kzalloc(sizeof(struct clk_hw_omap)...)

> +	if (!clk_hw) {
> +		pr_err("%s: could not allocate clk_hw_omap\n", __func__);
> +		return;
> +	}
> +
> +	clk_hw->hw.init = &init;
> +
> +	of_property_read_string(node, "clock-output-names", &clk_name);
> +	of_property_read_string(node, "ti,clkdm-name", &clk_hw->clkdm_name);
> +
> +	init.name = clk_name;
> +	init.ops = &omap_gate_clk_ops;
> +
> +	num_parents = of_clk_get_parent_count(node);
> +	if (num_parents < 1) {
> +		pr_err("%s: omap trace_clk %s must have parent(s)\n",
> +			__func__, node->name);
CHECK: Alignment should match open parenthesis

> +		goto cleanup;
> +	}
> +
> +	parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
> +
> +	for (i = 0; i < num_parents; i++)
> +		parent_names[i] = of_clk_get_parent_name(node, i);
> +
> +	init.num_parents = num_parents;
> +	init.parent_names = parent_names;
> +
> +	clk = clk_register(NULL, &clk_hw->hw);
> +
> +	if (!IS_ERR(clk)) {
> +		of_clk_add_provider(node, of_clk_src_simple_get, clk);
> +		return;
> +	}
> +
> +cleanup:
kfree(parent_names)?
> +	kfree(clk_hw);
> +}
> +EXPORT_SYMBOL(of_omap_gate_clk_setup);
> +CLK_OF_DECLARE(omap_gate_clk, "ti,omap-gate-clock", of_omap_gate_clk_setup);
> +#endif
> diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
> index 904bdad..58ebb80 100644
> --- a/include/linux/clk/omap.h
> +++ b/include/linux/clk/omap.h
> @@ -194,6 +194,7 @@ extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int cnt);
>   void of_omap4_dpll_setup(struct device_node *node);
>   void of_omap_fixed_factor_setup(struct device_node *node);
>   void of_omap_divider_setup(struct device_node *node);
> +void of_omap_gate_clk_setup(struct device_node *node);
dont need to export I think if we use strategy mentioned previously.

>   void of_omap_clk_allow_autoidle_all(void);
>   void of_omap_clk_deny_autoidle_all(void);
>
>


-- 
Regards,
Nishanth Menon


From nm at ti.com  Tue Jul 30 15:18:39 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 14:18:39 -0500
Subject: [PATCHv4 15/33] CLK: OMAP: DPLL: add support for DT property
 ti,dpll-no-gate
In-Reply-To: <1374564028-11352-16-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-16-git-send-email-t-kristo@ti.com>
Message-ID: <51F8118F.3000104@ti.com>

On 07/23/2013 02:20 AM, Tero Kristo wrote:
> AM335x has DPLL clocks that should never be attempted to be gated. Adding
> ti,dpll-no-gate property for them handles this situation.
>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
>   drivers/clk/omap/dpll.c |   10 ++++++++++
>   1 file changed, 10 insertions(+)
>
> diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
> index 66e82be..1d24feada 100644
> --- a/drivers/clk/omap/dpll.c
> +++ b/drivers/clk/omap/dpll.c
> @@ -54,6 +54,13 @@ static const struct clk_ops dpll_x2_ck_ops = {
>   	.recalc_rate	= &omap3_clkoutx2_recalc,
>   };
>
> +static const struct clk_ops dpll_no_gate_ck_ops = {
> +	.recalc_rate	= &omap3_dpll_recalc,
> +	.get_parent	= &omap2_init_dpll_parent,
> +	.round_rate	= &omap2_dpll_round_rate,
> +	.set_rate	= &omap3_noncore_dpll_set_rate,
> +};
> +
>   struct clk *omap_clk_register_dpll(struct device *dev, const char *name,
>   		const char **parent_names, int num_parents, unsigned long flags,
>   		struct dpll_data *dpll_data, const char *clkdm_name,
> @@ -288,6 +295,9 @@ __init void of_omap4_dpll_setup(struct device_node *node)
>   		return;
>   	}
>
> +	if (of_property_read_bool(node, "ti,dpll-no-gate"))
> +		ops = &dpll_no_gate_ck_ops;
> +
>   	of_omap_dpll_setup(node, ops);
>   }
>   EXPORT_SYMBOL_GPL(of_omap4_dpll_setup);
>
squash this to dpll patch?

-- 
Regards,
Nishanth Menon


From carlo.caione at gmail.com  Tue Jul 30 15:20:46 2013
From: carlo.caione at gmail.com (Carlo Caione)
Date: Tue, 30 Jul 2013 21:20:46 +0200
Subject: [PATCH v7] ARM: sunxi: New watchdog driver for Allwinner A10/A13
Message-ID: <1375212046-12823-1-git-send-email-carlo.caione@gmail.com>

This patch adds the driver for the watchdog found in the Allwinner A10 and
A13 SoCs. It has DT-support and uses the new watchdog framework.

Signed-off-by: Carlo Caione <carlo.caione at gmail.com>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/watchdog/Kconfig     |  10 ++
 drivers/watchdog/Makefile    |   1 +
 drivers/watchdog/sunxi_wdt.c | 237 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 248 insertions(+)
 create mode 100644 drivers/watchdog/sunxi_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 362085d..d1d53f3 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -290,6 +290,16 @@ config ORION_WATCHDOG
 	  To compile this driver as a module, choose M here: the
 	  module will be called orion_wdt.
 
+config SUNXI_WATCHDOG
+	tristate "Allwinner SoCs watchdog support"
+	depends on ARCH_SUNXI
+	select WATCHDOG_CORE
+	help
+	  Say Y here to include support for the watchdog timer
+	  in Allwinner SoCs.
+	  To compile this driver as a module, choose M here: the
+	  module will be called sunxi_wdt.
+
 config COH901327_WATCHDOG
 	bool "ST-Ericsson COH 901 327 watchdog"
 	depends on ARCH_U300
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 2f26a0b..6c5bb27 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_PNX4008_WATCHDOG) += pnx4008_wdt.o
 obj-$(CONFIG_IOP_WATCHDOG) += iop_wdt.o
 obj-$(CONFIG_DAVINCI_WATCHDOG) += davinci_wdt.o
 obj-$(CONFIG_ORION_WATCHDOG) += orion_wdt.o
+obj-$(CONFIG_SUNXI_WATCHDOG) += sunxi_wdt.o
 obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
 obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
 obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
diff --git a/drivers/watchdog/sunxi_wdt.c b/drivers/watchdog/sunxi_wdt.c
new file mode 100644
index 0000000..1f94b42
--- /dev/null
+++ b/drivers/watchdog/sunxi_wdt.c
@@ -0,0 +1,237 @@
+/*
+ *      sunxi Watchdog Driver
+ *
+ *      Copyright (c) 2013 Carlo Caione
+ *                    2012 Henrik Nordstrom
+ *
+ *      This program is free software; you can redistribute it and/or
+ *      modify it under the terms of the GNU General Public License
+ *      as published by the Free Software Foundation; either version
+ *      2 of the License, or (at your option) any later version.
+ *
+ *      Based on xen_wdt.c
+ *      (c) Copyright 2010 Novell, Inc.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+#include <linux/watchdog.h>
+
+#define WDT_MAX_TIMEOUT         16
+#define WDT_MIN_TIMEOUT         1
+#define WDT_MODE_TIMEOUT(n)     ((n) << 3)
+#define WDT_TIMEOUT_MASK        WDT_MODE_TIMEOUT(0x0F)
+
+#define WDT_CTRL                0x00
+#define WDT_CTRL_RELOAD         ((1 << 0) | (0x0a57 << 1))
+
+#define WDT_MODE                0x04
+#define WDT_MODE_EN             (1 << 0)
+#define WDT_MODE_RST_EN         (1 << 1)
+
+#define DRV_NAME		"sunxi-wdt"
+#define DRV_VERSION		"1.0"
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+static unsigned int timeout = WDT_MAX_TIMEOUT;
+
+struct sunxi_wdt_dev {
+	struct watchdog_device wdt_dev;
+	void __iomem *wdt_base;
+};
+
+/*
+ * wdt_timeout_map maps the watchdog timer interval value in seconds to
+ * the value of the register WDT_MODE bit 3:6
+ *
+ * [timeout seconds] = register value
+ *
+ */
+
+static const int wdt_timeout_map[] = {
+	[1] = 0b0001,  /* 1s  */
+	[2] = 0b0010,  /* 2s  */
+	[3] = 0b0011,  /* 3s  */
+	[4] = 0b0100,  /* 4s  */
+	[5] = 0b0101,  /* 5s  */
+	[6] = 0b0110,  /* 6s  */
+	[8] = 0b0111,  /* 8s  */
+	[10] = 0b1000, /* 10s */
+	[12] = 0b1001, /* 12s */
+	[14] = 0b1010, /* 14s */
+	[16] = 0b1011, /* 16s */
+};
+
+static int sunxi_wdt_ping(struct watchdog_device *wdt_dev)
+{
+	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
+	void __iomem *wdt_base = sunxi_wdt->wdt_base;
+
+	iowrite32(WDT_CTRL_RELOAD, wdt_base + WDT_CTRL);
+
+	return 0;
+}
+
+static int sunxi_wdt_set_timeout(struct watchdog_device *wdt_dev,
+		unsigned int timeout)
+{
+	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
+	void __iomem *wdt_base = sunxi_wdt->wdt_base;
+	u32 reg;
+
+	if (wdt_timeout_map[timeout] == 0)
+		timeout++;
+
+	sunxi_wdt->wdt_dev.timeout = timeout;
+
+	reg = ioread32(wdt_base + WDT_MODE);
+	reg &= ~WDT_TIMEOUT_MASK;
+	reg |= WDT_MODE_TIMEOUT(wdt_timeout_map[timeout]);
+	iowrite32(reg, wdt_base + WDT_MODE);
+
+	sunxi_wdt_ping(wdt_dev);
+
+	return 0;
+}
+
+static int sunxi_wdt_stop(struct watchdog_device *wdt_dev)
+{
+	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
+	void __iomem *wdt_base = sunxi_wdt->wdt_base;
+
+	iowrite32(0, wdt_base + WDT_MODE);
+
+	return 0;
+}
+
+static int sunxi_wdt_start(struct watchdog_device *wdt_dev)
+{
+	u32 reg;
+	struct sunxi_wdt_dev *sunxi_wdt = watchdog_get_drvdata(wdt_dev);
+	void __iomem *wdt_base = sunxi_wdt->wdt_base;
+	int ret;
+
+	ret = sunxi_wdt_set_timeout(&sunxi_wdt->wdt_dev,
+			sunxi_wdt->wdt_dev.timeout);
+	if (ret < 0)
+		return ret;
+
+	reg = ioread32(wdt_base + WDT_MODE);
+	reg |= (WDT_MODE_RST_EN | WDT_MODE_EN);
+	iowrite32(reg, wdt_base + WDT_MODE);
+
+	return 0;
+}
+
+static const struct watchdog_info sunxi_wdt_info = {
+	.identity	= DRV_NAME,
+	.options	= WDIOF_SETTIMEOUT |
+			  WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
+static const struct watchdog_ops sunxi_wdt_ops = {
+	.owner		= THIS_MODULE,
+	.start		= sunxi_wdt_start,
+	.stop		= sunxi_wdt_stop,
+	.ping		= sunxi_wdt_ping,
+	.set_timeout	= sunxi_wdt_set_timeout,
+};
+
+static int __init sunxi_wdt_probe(struct platform_device *pdev)
+{
+	struct sunxi_wdt_dev *sunxi_wdt;
+	struct resource *res;
+	int err;
+
+	sunxi_wdt = devm_kzalloc(&pdev->dev, sizeof(*sunxi_wdt), GFP_KERNEL);
+	if (!sunxi_wdt)
+		return -EINVAL;
+
+	platform_set_drvdata(pdev, sunxi_wdt);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	sunxi_wdt->wdt_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(sunxi_wdt->wdt_base))
+		return PTR_ERR(sunxi_wdt->wdt_base);
+
+	sunxi_wdt->wdt_dev.info = &sunxi_wdt_info;
+	sunxi_wdt->wdt_dev.ops = &sunxi_wdt_ops;
+	sunxi_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
+	sunxi_wdt->wdt_dev.max_timeout = WDT_MAX_TIMEOUT;
+	sunxi_wdt->wdt_dev.min_timeout = WDT_MIN_TIMEOUT;
+	sunxi_wdt->wdt_dev.parent = &pdev->dev;
+
+	watchdog_init_timeout(&sunxi_wdt->wdt_dev, timeout, &pdev->dev);
+	watchdog_set_nowayout(&sunxi_wdt->wdt_dev, nowayout);
+
+	watchdog_set_drvdata(&sunxi_wdt->wdt_dev, sunxi_wdt);
+
+	sunxi_wdt_stop(&sunxi_wdt->wdt_dev);
+
+	err = watchdog_register_device(&sunxi_wdt->wdt_dev);
+	if (unlikely(err))
+		return err;
+
+	dev_info(&pdev->dev, "Watchdog enabled (timeout=%d sec, nowayout=%d)",
+			sunxi_wdt->wdt_dev.timeout, nowayout);
+
+	return 0;
+}
+
+static int __exit sunxi_wdt_remove(struct platform_device *pdev)
+{
+	struct sunxi_wdt_dev *sunxi_wdt = platform_get_drvdata(pdev);
+
+	watchdog_unregister_device(&sunxi_wdt->wdt_dev);
+	watchdog_set_drvdata(&sunxi_wdt->wdt_dev, NULL);
+
+	return 0;
+}
+
+static void sunxi_wdt_shutdown(struct platform_device *pdev)
+{
+	struct sunxi_wdt_dev *sunxi_wdt = platform_get_drvdata(pdev);
+
+	sunxi_wdt_stop(&sunxi_wdt->wdt_dev);
+}
+
+static const struct of_device_id sunxi_wdt_dt_ids[] = {
+	{ .compatible = "allwinner,sun4i-wdt" },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sunxi_wdt_dt_ids);
+
+static struct platform_driver sunxi_wdt_driver = {
+	.probe		= sunxi_wdt_probe,
+	.remove		= sunxi_wdt_remove,
+	.shutdown	= sunxi_wdt_shutdown,
+	.driver		= {
+		.owner		= THIS_MODULE,
+		.name		= DRV_NAME,
+		.of_match_table	= of_match_ptr(sunxi_wdt_dt_ids)
+	},
+};
+
+module_platform_driver(sunxi_wdt_driver);
+
+module_param(timeout, uint, 0);
+MODULE_PARM_DESC(timeout, "Watchdog heartbeat in seconds");
+
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
+		"(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Carlo Caione <carlo.caione at gmail.com>");
+MODULE_AUTHOR("Henrik Nordstrom <henrik at henriknordstrom.net>");
+MODULE_DESCRIPTION("sunxi WatchDog Timer Driver");
+MODULE_VERSION(DRV_VERSION);
-- 
1.8.3.4



From nm at ti.com  Tue Jul 30 15:27:47 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 14:27:47 -0500
Subject: [PATCHv4 08/33] ARM: dts: omap4 clock data
In-Reply-To: <1374564028-11352-9-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-9-git-send-email-t-kristo@ti.com>
Message-ID: <51F813B3.7020000@ti.com>

On 07/23/2013 02:20 AM, Tero Kristo wrote:
> This patch creates a unique node for each clock in the OMAP4 power,
> reset and clock manager (PRCM). OMAP443x and OMAP446x have slightly
> different clock tree which is taken into account in the data.
>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
>   arch/arm/boot/dts/omap443x-clocks.dtsi |   17 +
>   arch/arm/boot/dts/omap443x.dtsi        |    8 +
>   arch/arm/boot/dts/omap4460.dtsi        |    8 +
>   arch/arm/boot/dts/omap446x-clocks.dtsi |   27 +
>   arch/arm/boot/dts/omap44xx-clocks.dtsi | 1654 ++++++++++++++++++++++++++++++++
arch/arm/boot/dts/omap44xx-common-clocks.dtsi ?
>   5 files changed, 1714 insertions(+)
>   create mode 100644 arch/arm/boot/dts/omap443x-clocks.dtsi
>   create mode 100644 arch/arm/boot/dts/omap446x-clocks.dtsi
>   create mode 100644 arch/arm/boot/dts/omap44xx-clocks.dtsi
>
> diff --git a/arch/arm/boot/dts/omap443x-clocks.dtsi b/arch/arm/boot/dts/omap443x-clocks.dtsi
> new file mode 100644
> index 0000000..2bd82b2
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap443x-clocks.dtsi
> @@ -0,0 +1,17 @@
> +/*
> + * Device Tree Source for OMAP443x clock data
> + *
> + * Copyright (C) 2013 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
Doing
/include/ "omap44xx-clocks.dtsi" might avoid including that header in 
corresponding SoC dtsi,
OR:
> +bandgap_fclk: bandgap_fclk at 4a307888 {
> +	#clock-cells = <0>;
> +	compatible = "gate-clock";
> +	clocks = <&sys_32k_ck>;
> +	bit-shift = <8>;
> +	reg = <0x4a307888 0x4>;
> +};

Since we already have omap443x.dtsi and omap446x.dtsi, do we need 
clock.dtsi containing just a few entries?
instead we could define the delta clocks in the clocks section, and save 
on two additional files, no?

[...]

> diff --git a/arch/arm/boot/dts/omap44xx-clocks.dtsi b/arch/arm/boot/dts/omap44xx-clocks.dtsi
> new file mode 100644
> index 0000000..ed6bc9b
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap44xx-clocks.dtsi
[...]

> +dpll_abe_m2x2_ck: dpll_abe_m2x2_ck at 4a0041f0 {
> +	#clock-cells = <0>;
> +	compatible = "divider-clock";
> +	clocks = <&dpll_abe_x2_ck>;
> +	ti,autoidle-shift = <8>;
> +	reg = <0x4a0041f0 0x4>;
> +	bit-mask = <0x1f>;
> +	index-starts-at-one;
> +	ti,autoidle-low;
> +};
> +
> +abe_24m_fclk: abe_24m_fclk {
> +	#clock-cells = <0>;
> +	compatible = "fixed-factor-clock";
> +	clocks = <&dpll_abe_m2x2_ck>;
> +	clock-mult = <1>;
> +	clock-div = <8>;
> +};
> +
> +abe_clk: abe_clk at 4a004108 {
> +	#clock-cells = <0>;
> +	compatible = "divider-clock";
> +	clocks = <&dpll_abe_m2x2_ck>;
> +	reg = <0x4a004108 0x4>;
> +	bit-mask = <0x3>;
> +	index-power-of-two;
> +};
> +
> +aess_fclk: aess_fclk at 4a004528 {
is there a naming convention used here? abe_clk, fclk etc?

> +	#clock-cells = <0>;
> +	compatible = "divider-clock";
> +	clocks = <&abe_clk>;
> +	bit-shift = <24>;
> +	reg = <0x4a004528 0x4>;
> +	bit-mask = <0x1>;
> +};

[...]

> +
> +ocp2scp_usb_phy_phy_48m: ocp2scp_usb_phy_phy_48m at 4a0093e0 {
_ck?

[...]


-- 
Regards,
Nishanth Menon


From finn at uni-bremen.de  Tue Jul 30 15:31:44 2013
From: finn at uni-bremen.de (Finn Hoffmann)
Date: Tue, 30 Jul 2013 21:31:44 +0200
Subject: NSA310 + DT
In-Reply-To: <20130730183610.GT24782@lunn.ch>
References: <20130710073706.GA28212@lunn.ch> <51F6A0DC.3020501@uni-bremen.de>
 <20130729192112.GY29916@titan.lakedaemon.net>
 <20130729204315.GK24782@lunn.ch> <51F78DA6.8010307@uni-bremen.de>
 <20130730144752.GR24782@lunn.ch> <20130730172407.3aab15c6@skate>
 <51F7EBB9.7000504@uni-bremen.de> <20130730191943.49f8070c@skate>
 <20130730183610.GT24782@lunn.ch>
Message-ID: <51F814A0.2050403@uni-bremen.de>


Am 30.07.2013 20:36, schrieb Andrew Lunn:
> On Tue, Jul 30, 2013 at 07:19:43PM +0200, Thomas Petazzoni wrote:
>> Dear Finn Hoffmann,
>>
>> BTW, any reason why this discussion is not taking place on LAKML ?
> Ah, sorry, did not look at the CC: list. Now one list...
>
>      Andrew
>
>> On Tue, 30 Jul 2013 18:37:13 +0200, Finn Hoffmann wrote:
>>
>>> $ lspci -v
>>> 00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if
>>> 00 [Normal decode])
>>>           Flags: bus master, fast devsel, latency 0
>>>           Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>>>           I/O behind bridge: 00010000-00010fff
>>>           Prefetchable memory behind bridge: e0000000-e00fffff
>> Ok, so there should be one mem window from e0000000 to e0100000...
>>
>>> # cat /sys/kernel/debug/mvebu-mbus/devices
>>> [00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap 0000000000010000)
>>> [01] disabled
>>> [02] disabled
>>> [03] disabled
>>> [04] 00000000f4000000 - 00000000f4010000 : nand
>>> [05] 00000000f5000000 - 00000000f5010000 : sram
>>> [06] disabled
>>> [07] disabled
>> ... but there's none here.
>>
>> Seems like your device is using a prefetchable memory window, and our
>> emulated PCI-to-PCI bridge isn't taking this into account.
>>
>> Can you test the below (completely untested) patch? Regardless of
>> whether it works or not, I'm interested in seeing the "PCI MVEBU"
>> debug messages that I've added, as well as the output
>> of /sys/kernel/debug/mvebu-mbus/devices.
>>
>> Thanks a lot!
>>
>> Thomas
# cat /sys/kernel/debug/mvebu-mbus/devices
[00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap 0000000000010000)
[01] disabled
[02] disabled
[03] disabled
[04] 00000000f4000000 - 00000000f4010000 : nand
[05] 00000000f5000000 - 00000000f5010000 : sram
[06] 00000000fff00000 - 0000000100000000 : pcie0.0
[07] disabled


# lspci -v
00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if 
00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00010000-00010fff
Prefetchable memory behind bridge: e0000000-e00fffff

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev
03)
Subsystem: Realtek Semiconductor Co., Ltd. TEG-ECTX Gigabit PCI-E 
Adapter [Trendnet]
Flags: bus master, fast devsel, latency 0, IRQ 9
I/O ports at 10000 [size=256]
Memory at e0014000 (64-bit, prefetchable) [size=4K]
Memory at e0010000 (64-bit, prefetchable) [size=16K]
[virtual] Expansion ROM at e0000000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [ac] MSI-X: Enable- Count=4 Masked-
Capabilities: [cc] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
Kernel driver in use: r8169




3122350 bytes read
## Booting image at 00800000 ...
Image Name: Linux-3.11.0-rc3
Created: 2013-07-30 18:56:55 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3122286 Bytes = 3 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.11.0-rc3 (finn at T400) (gcc version 4.7.3 (Ubuntu/Linaro 
4.7.3-1ubuntu1) ) #2 PREEMPT Tue Jul 30
20:56:41 CEST 2013
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Marvell Kirkwood (Flattened Device Tree), model: ZyXEL NSA310
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: console=ttyS0,115200 root=/dev/sda2
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 253156K/262144K available (4404K kernel code, 243K rwdata, 1216K 
rodata, 151K init, 615K bss, 8988K reserved)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0xc0008000 - 0xc0585248 (5621 kB)
.init : 0xc0586000 - 0xc05abcc4 ( 152 kB)
.data : 0xc05ac000 - 0xc05e8fe0 ( 244 kB)
.bss : 0xc05e8fe0 - 0xc0682d60 ( 616 kB)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:114
sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms
Console: colour dummy device 80x30
Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc042fe08 - 0xc042fe44
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
Kirkwood: MV88F6281-A1, TCLK=200000000.
Feroceon L2: Enabling L2
Feroceon L2: Cache support initialised.
bio: create slab <bio-0> at 0
mvebu-pcie pcie-controller.1: PCIe0.0: link up
mvebu-pcie pcie-controller.1: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x1000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus1: Fast back to back transfers disabled
MVEBU PCI 0.0: new pref mem, base 0xfff0, limit 0xfff0
MVEBU PCI 0.0: new pref mem, base 0x0, limit 0x0
mvebu_mbus: cannot add window 'pcie0.0', conflicts with another window
pci 0000:00:01.0: BAR 9: assigned [mem 0xe0000000-0xe00fffff pref]
pci 0000:00:01.0: BAR 7: assigned [io 0x10000-0x10fff]
pci 0000:01:00.0: BAR 6: assigned [mem 0xe0000000-0xe000ffff pref]
pci 0000:01:00.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref]
pci 0000:01:00.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref]
pci 0000:01:00.0: BAR 0: assigned [io 0x10000-0x100ff]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0: bridge window [io 0x10000-0x10fff]
MVEBU PCI 0.0: new io, base 0x1, limit 0x1
MVEBU PCI 0.0: new mem, base 0xfff0, limit 0x0
pci 0000:00:01.0: bridge window [mem 0xe0000000-0xe00fffff pref]
MVEBU PCI 0.0: new pref mem, base 0xe000, limit 0xe000
mvebu_mbus: cannot add window 'pcie0.0', conflicts with another window
PCI: enabling device 0000:00:01.0 (0140 -> 0143)
USB Power Off: Failed to request enable GPIO21: -517
reg-fixed-voltage 1.regulator: Failed to register regulator: -517
platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
cfg80211: Calling CRDA to update world regulatory domain
Switched to clocksource orion_clocksource
NET: Registered protocol family 2
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP: reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
msgmni has been set to 494
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
kirkwood-pinctrl f1010000.pinctrl: registered pinctrl driver
mv_xor f1060800.xor: Marvell shared XOR driver
mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
mv_xor f1060900.xor: Marvell shared XOR driver
mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
console [ttyS0] enabled
loop: module loaded
sata_mv f1080000.sata: slots 32 ports 2
scsi0 : sata_mv
scsi1 : sata_mv
ata1: SATA max UDMA/133 irq 21
ata2: SATA max UDMA/133 irq 21
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 
3,3V 8-bit), 128MiB, page size: 2048, OOB size: 6
4
Scanning device for bad blocks
Bad eraseblock 249 at 0x000001f20000
9 ofpart partitions found on MTD device orion_nand
Creating 9 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "uboot"
0x000000100000-0x000000180000 : "uboot_env"
0x000000180000-0x000000200000 : "key_store"
0x000000200000-0x000000280000 : "info"
0x000000280000-0x000000c80000 : "etc"
0x000000c80000-0x000001680000 : "kernel_1"
0x000001680000-0x000004640000 : "rootfs1"
0x000004640000-0x000005040000 : "kernel_2"
0x000005040000-0x000008000000 : "rootfs2"
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:01:00.0 eth0: RTL8169 at 0xd092e000, 00:00:00:00:00:00, XID 
00000000 IRQ 9
r8169 0000:01:00.0 eth0: jumbo features [frames: 7152 bytes, tx 
checksumming: ok]
libertas_sdio: Libertas SDIO driver
libertas_sdio: Copyright Pierre Ossman
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-orion: EHCI orion driver
orion-ehci f1050000.ehci: EHCI Host Controller
orion-ehci f1050000.ehci: new USB bus registered, assigned bus number 1
orion-ehci f1050000.ehci: irq 19, io mem 0xf1050000
orion-ehci f1050000.ehci: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
usbcore: registered new interface driver ums-datafab
usbcore: registered new interface driver ums-freecom
usbcore: registered new interface driver ums-jumpshot
usbcore: registered new interface driver ums-sddr09
usbcore: registered new interface driver ums-sddr55
mousedev: PS/2 mouse device common for all mice
rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0
i2c /dev entries driver
orion_wdt: Initial timeout 21 sec
cpuidle: using governor ladder
cpuidle: using governor menu
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: no performance counters
oprofile: using timer interrupt.
TCP: cubic registered
NET: Registered protocol family 17
lib80211: common routines for IEEE802.11 drivers
USB Power Off: 5000 mV
input: gpio_keys.2 as /devices/gpio_keys.2/input/input0
rtc-mv f1010300.rtc: setting system clock to 2013-07-30 19:25:09 UTC 
(1375212309)
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
ata1.00: ATA-8: ST31500541AS, CC32, max UDMA/133
ata1.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32)
usb 1-1: new high-speed USB device number 2 using orion-ehci
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA ST31500541AS CC32 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
sd 0:0:0:0: [sda] Attached SCSI disk
ata2: SATA link down (SStatus 0 SControl F300)
EXT3-fs (sda2): error: couldn't mount because of unsupported optional 
features (240)
EXT2-fs (sda2): error: couldn't mount because of unsupported optional 
features (240)
EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 8:2.
Freeing unused kernel memory: 148K (c0586000 - c05ab000)
INIT: version 2.88 booting

>> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
>> index 13a633b..641dd3d 100644
>> --- a/drivers/pci/host/pci-mvebu.c
>> +++ b/drivers/pci/host/pci-mvebu.c
>> @@ -129,6 +129,8 @@ struct mvebu_pcie_port {
>>   	struct mvebu_pcie *pcie;
>>   	phys_addr_t memwin_base;
>>   	size_t memwin_size;
>> +	phys_addr_t prefmemwin_base;
>> +	size_t prefmemwin_size;
>>   	phys_addr_t iowin_base;
>>   	size_t iowin_size;
>>   };
>> @@ -348,6 +350,39 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
>>   					  MVEBU_MBUS_PCI_MEM);
>>   }
>>   
>> +static void mvebu_pcie_handle_prefmembase_change(struct mvebu_pcie_port *port)
>> +{
>> +	/* Are the new membase/memlimit values invalid? */
>> +	if (port->bridge.prefmemlimit < port->bridge.prefmembase) {
>> +
>> +		/* If a window was configured, remove it */
>> +		if (port->prefmemwin_base) {
>> +			mvebu_mbus_del_window(port->prefmemwin_base,
>> +					      port->prefmemwin_size);
>> +			port->prefmemwin_base = 0;
>> +			port->prefmemwin_size = 0;
>> +		}
>> +
>> +		return;
>> +	}
>> +
>> +	/*
>> +	 * We read the PCI-to-PCI bridge emulated registers, and
>> +	 * calculate the base address and size of the address decoding
>> +	 * window to setup, according to the PCI-to-PCI bridge
>> +	 * specifications.
>> +	 */
>> +	port->prefmemwin_base  = ((port->bridge.prefmembase & 0xFFF0) << 16);
>> +	port->prefmemwin_size  =
>> +		(((port->bridge.prefmemlimit & 0xFFF0) << 16) | 0xFFFFF) -
>> +		port->prefmemwin_base;
>> +
>> +	mvebu_mbus_add_window_remap_flags(port->name, port->prefmemwin_base,
>> +					  port->prefmemwin_size,
>> +					  MVEBU_MBUS_NO_REMAP,
>> +					  MVEBU_MBUS_PCI_MEM);
>> +}
>> +
>>   /*
>>    * Initialize the configuration space of the PCI-to-PCI bridge
>>    * associated with the given PCIe interface.
>> @@ -492,18 +527,28 @@ static int mvebu_sw_pci_bridge_write(struct mvebu_pcie_port *port,
>>   		bridge->iobase = (value & 0xff) | PCI_IO_RANGE_TYPE_32;
>>   		bridge->iolimit = ((value >> 8) & 0xff) | PCI_IO_RANGE_TYPE_32;
>>   		bridge->secondary_status = value >> 16;
>> +		pr_info("MVEBU PCI %d.%d: new io, base 0x%x, limit 0x%x\n",
>> +			port->port, port->lane,
>> +			bridge->iobase, bridge->iolimit);
>>   		mvebu_pcie_handle_iobase_change(port);
>>   		break;
>>   
>>   	case PCI_MEMORY_BASE:
>>   		bridge->membase = value & 0xffff;
>>   		bridge->memlimit = value >> 16;
>> +		pr_info("MVEBU PCI %d.%d: new mem, base 0x%x, limit 0x%x\n",
>> +			port->port, port->lane,
>> +			bridge->membase, bridge->memlimit);
>>   		mvebu_pcie_handle_membase_change(port);
>>   		break;
>>   
>>   	case PCI_PREF_MEMORY_BASE:
>>   		bridge->prefmembase = value & 0xffff;
>>   		bridge->prefmemlimit = value >> 16;
>> +		pr_info("MVEBU PCI %d.%d: new pref mem, base 0x%x, limit 0x%x\n",
>> +			port->port, port->lane,
>> +			bridge->prefmembase, bridge->prefmemlimit);
>> +		mvebu_pcie_handle_prefmembase_change(port);
>>   		break;
>>   
>>   	case PCI_PREF_BASE_UPPER32:
>>
>>
>> -- 
>> Thomas Petazzoni, Free Electrons
>> Kernel, drivers, real-time and embedded Linux
>> development, consulting, training and support.
>> http://free-electrons.com
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From nm at ti.com  Tue Jul 30 15:33:42 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 14:33:42 -0500
Subject: [PATCHv4 09/33] CLK: omap: add omap4 clock init file
In-Reply-To: <1374564028-11352-10-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-10-git-send-email-t-kristo@ti.com>
Message-ID: <51F81516.3050302@ti.com>

On 07/23/2013 02:20 AM, Tero Kristo wrote:
> clk-44xx.c now contains the clock init functionality for omap4, including
> DT clock registration and adding of static clkdev entries.
>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
>   drivers/clk/omap/clk-44xx.c |  118 +++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 118 insertions(+)
>   create mode 100644 drivers/clk/omap/clk-44xx.c
>
> diff --git a/drivers/clk/omap/clk-44xx.c b/drivers/clk/omap/clk-44xx.c
> new file mode 100644
> index 0000000..cc12134
> --- /dev/null
> +++ b/drivers/clk/omap/clk-44xx.c
> @@ -0,0 +1,118 @@
> +/*
> + * OMAP4 Clock data
> + *
> + * Copyright (C) 2009-2012 Texas Instruments, Inc.
> + * Copyright (C) 2009-2010 Nokia Corporation
> + *
> + * Paul Walmsley (paul at pwsan.com)
> + * Rajendra Nayak (rnayak at ti.com)
> + * Benoit Cousson (b-cousson at ti.com)
> + * Mike Turquette (mturquette at ti.com)
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * XXX Some of the ES1 clocks have been removed/changed; once support
> + * is added for discriminating clocks by ES level, these should be added back
> + * in.
> + *
> + * XXX All of the remaining MODULEMODE clock nodes should be removed
> + * once the drivers are updated to use pm_runtime or to use the appropriate
> + * upstream clock node for rate/parent selection.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/list.h>
> +#include <linux/clk-private.h>
> +#include <linux/clkdev.h>
> +#include <linux/io.h>
> +#include <linux/clk/omap.h>
> +
> +/*
> + * OMAP4 ABE DPLL default frequency. In OMAP4460 TRM version V, section
> + * "3.6.3.2.3 CM1_ABE Clock Generator" states that the "DPLL_ABE_X2_CLK
> + * must be set to 196.608 MHz" and hence, the DPLL locked frequency is
> + * half of this value.
> + */
> +#define OMAP4_DPLL_ABE_DEFFREQ				98304000
> +
> +/*
> + * OMAP4 USB DPLL default frequency. In OMAP4430 TRM version V, section
> + * "3.6.3.9.5 DPLL_USB Preferred Settings" shows that the preferred
> + * locked frequency for the USB DPLL is 960MHz.
> + */
> +#define OMAP4_DPLL_USB_DEFFREQ				960000000
> +
> +static struct omap_dt_clk omap44xx_clks[] = {
> +	DT_CLK("smp_twd",	NULL,			"mpu_periphclk"),
> +	DT_CLK("omapdss_dss", "ick", "dss_fck"),
> +	DT_CLK("usbhs_omap", "fs_fck", "usb_host_fs_fck"),
> +	DT_CLK("usbhs_omap", "hs_fck", "usb_host_hs_fck"),
> +	DT_CLK("usbhs_omap", "usbtll_ick", "usb_tll_hs_ick"),
> +	DT_CLK("usbhs_tll", "usbtll_ick", "usb_tll_hs_ick"),
> +	DT_CLK(NULL,	"timer_32k_ck",	"sys_32k_ck"),
> +	/* TODO: Remove "omap_timer.X" aliases once DT migration is complete */
> +	DT_CLK("omap_timer.1",	"timer_sys_ck",	"sys_clkin_ck"),
> +	DT_CLK("omap_timer.2",	"timer_sys_ck",	"sys_clkin_ck"),
> +	DT_CLK("omap_timer.3",	"timer_sys_ck",	"sys_clkin_ck"),
> +	DT_CLK("omap_timer.4",	"timer_sys_ck",	"sys_clkin_ck"),
> +	DT_CLK("omap_timer.9",	"timer_sys_ck",	"sys_clkin_ck"),
> +	DT_CLK("omap_timer.10",	"timer_sys_ck",	"sys_clkin_ck"),
> +	DT_CLK("omap_timer.11",	"timer_sys_ck",	"sys_clkin_ck"),
> +	DT_CLK("omap_timer.5",	"timer_sys_ck",	"syc_clk_div_ck"),
> +	DT_CLK("omap_timer.6",	"timer_sys_ck",	"syc_clk_div_ck"),
> +	DT_CLK("omap_timer.7",	"timer_sys_ck",	"syc_clk_div_ck"),
> +	DT_CLK("omap_timer.8",	"timer_sys_ck",	"syc_clk_div_ck"),
> +	DT_CLK("4a318000.timer",	"timer_sys_ck",	"sys_clkin_ck"),
> +	DT_CLK("48032000.timer",	"timer_sys_ck",	"sys_clkin_ck"),
> +	DT_CLK("48034000.timer",	"timer_sys_ck",	"sys_clkin_ck"),
> +	DT_CLK("48036000.timer",	"timer_sys_ck",	"sys_clkin_ck"),
> +	DT_CLK("4803e000.timer",	"timer_sys_ck",	"sys_clkin_ck"),
> +	DT_CLK("48086000.timer",	"timer_sys_ck",	"sys_clkin_ck"),
> +	DT_CLK("48088000.timer",	"timer_sys_ck",	"sys_clkin_ck"),
> +	DT_CLK("40138000.timer",	"timer_sys_ck",	"syc_clk_div_ck"),
> +	DT_CLK("4013a000.timer",	"timer_sys_ck",	"syc_clk_div_ck"),
> +	DT_CLK("4013c000.timer",	"timer_sys_ck",	"syc_clk_div_ck"),
> +	DT_CLK("4013e000.timer",	"timer_sys_ck",	"syc_clk_div_ck"),

> +	DT_CLK(NULL,	"cpufreq_ck",	"dpll_mpu_ck"),
please remove cpufreq.

> +};
> +
> +int __init omap4xxx_clk_init(void)
> +{
> +	int rc;
> +	struct clk *abe_dpll_ref, *abe_dpll, *sys_32k_ck, *usb_dpll;
> +
> +	/* FIXME register clocks from DT first */
> +	dt_omap_clk_init();
> +
> +	omap_dt_clocks_register(omap44xx_clks, ARRAY_SIZE(omap44xx_clks));
> +
> +	omap2_clk_disable_autoidle_all();
> +
> +	/*
> +	 * On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
> +	 * state when turning the ABE clock domain. Workaround this by
> +	 * locking the ABE DPLL on boot.
> +	 * Lock the ABE DPLL in any case to avoid issues with audio.
> +	 */

But this code will be called for 4430 and 4460. if the requirement is 
only for 4460, then we are not adhering to the spec?

> +	abe_dpll_ref = clk_get_sys(NULL, "abe_dpll_refclk_mux_ck");
> +	sys_32k_ck = clk_get_sys(NULL, "sys_32k_ck");
> +	rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
> +	abe_dpll = clk_get_sys(NULL, "dpll_abe_ck");
> +	if (!rc)
> +		rc = clk_set_rate(abe_dpll, OMAP4_DPLL_ABE_DEFFREQ);
> +	if (rc)
> +		pr_err("%s: failed to configure ABE DPLL!\n", __func__);
> +
> +	/*
> +	 * Lock USB DPLL on OMAP4 devices so that the L3INIT power
> +	 * domain can transition to retention state when not in use.
> +	 */
> +	usb_dpll = clk_get_sys(NULL, "dpll_usb_ck");
> +	rc = clk_set_rate(usb_dpll, OMAP4_DPLL_USB_DEFFREQ);
> +	if (rc)
> +		pr_err("%s: failed to configure USB DPLL!\n", __func__);

^^^^ why cant we have a generic property that does this "automagically" 
from dts property to the node?
a) be able to select a parent
b) be able to set a frequency.
c) how do we ensure that CLK_SET_RATE_PARENT are setup for the clock 
nodes defined by dt?

> +
> +	return 0;
> +}
>


-- 
Regards,
Nishanth Menon


From robherring2 at gmail.com  Tue Jul 30 15:34:20 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Tue, 30 Jul 2013 14:34:20 -0500
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <alpine.DEB.2.02.1307301528540.4893@kaball.uk.xensource.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
 <51F7B4C9.2060500@gmail.com>
 <20130730125650.GD28716@e106331-lin.cambridge.arm.com>
 <20130730134427.GE28716@e106331-lin.cambridge.arm.com>
 <alpine.DEB.2.02.1307301528540.4893@kaball.uk.xensource.com>
Message-ID: <51F8153C.8030503@gmail.com>

On 07/30/2013 09:33 AM, Stefano Stabellini wrote:
> On Tue, 30 Jul 2013, Mark Rutland wrote:
>> On Tue, Jul 30, 2013 at 01:56:50PM +0100, Mark Rutland wrote:
>>> On Tue, Jul 30, 2013 at 01:42:49PM +0100, Rob Herring wrote:
>>>> On 07/30/2013 04:49 AM, Mark Rutland wrote:
>>>>> On Mon, Jul 29, 2013 at 09:18:43PM +0100, Rob Herring wrote:
>>>>>> On 07/29/2013 05:13 AM, Mark Rutland wrote:
>>>>>>> Hi Rob,
>>>>>>>
>>>>>>> On Sun, Jul 28, 2013 at 10:56:32PM +0100, Rob Herring wrote:
>>>>>>>> From: Rob Herring <rob.herring at calxeda.com>
>>>>
>>>> [snip]
>>>>
>>>>>>> One of the things changed in PSCI 0.2 was the SMC calling convention,
>>>>>>> though this isn't clear in the PSCI document. The function IDs for 32bit
>>>>>>> and 64bit callers may differ, and we need to support describing an
>>>>>>> arbitrary configuration of the two (same ID for both, different across
>>>>>>> 32-bit/64-bit, only supported for 64-bit, only supported for 32-bit).
>>>>>>>
>>>>>>> I'd like to ensure the binding can deal with that from the start. We
>>>>>>> could do this by having -32 and -64 variants of each function id (e.g.
>>>>>>> cpu_off-64) , if the IDs actually differ, and use the regular combined
>>>>>>> ID if they don't.
>>>>>>
>>>>>> Uggg. I guess I should have read the SMC calling convention doc... I was
>>>>>> simply documenting what is already in the PSCI doc, but obviously that
>>>>>> is not fully flushed out.
>>>>>>
>>>>>> How about something like this (for the complicated case of both 32 and
>>>>>> 64 bit):
>>>>>>
>>>>>> 	method		= "smc", "smc64";
>>>>>> 	psci_version	= <0x84000000 0xc4000000>;
>>>>>> 	cpu_suspend	= <0x84000001 0xc4000001>;
>>>>>> 	cpu_off		= <0x84000002 0xc4000002>;
>>>>>> 	cpu_on		= <0x84000003 0xc4000003>;
>>>>>>
>>>>>> "smc" is a synonym for smc32 for compatibility. The number and order of
>>>>>> methods determines the number and order of function IDs.
>>>>>
>>>>> While this may be compatible with the arm implementation, it won't be
>>>>> compatible with the arm64 implementation, which assumes smc64 by
>>>>> default.
>>>>>
>>>>> As far as I am aware, the implementations currently in use (KVM and Xen)
>>>>> use the same ID for both, so I think "smc" should cover an ID valid for
>>>>> a native register width calling convention, and "smc64" and "smc32"
>>>>> describing values only valid for 64-bit wide and 32-bit wide calling
>>>>> conventions respectively.
>>>>
>>>> The problem is that does not work for a 32-bit kernel on 64-bit h/w as
>>>> native from the dts perspective is smc64. Just like the cpu bindings,
>>>> the binding cannot change based on 32 or 64 bit OS. I don't think we
>>>> really have to deal with that here. We can simply say "smc" is only for
>>>> "arm,psci" and deprecated for "arm,psci-0.2".
>>>
>>> Agreed. I'd be happy with only having "smc32" and "smc64" for
>>> "arm,psci-0.2".
> 
> I would be happy with that too (Xen only uses HVC as "method").
> 
> 
>> Actually, from some quick discussion with Marc and Dave, I think we can
>> handle this better, in a way that leaves this backwards compatible.
>>
>> Rather than relying on the method string to tell us the calling
>> convention, I think we should rely on the function ID, as I proposed
>> earlier. The existing function ids provided in the "arm,psci" binding
>> are implicitly relying on the PSCI implementation to detect the register
>> width and act accordingly. This is trivially true on 32bit hardware, KVM
>> (where the same ID is used for 32-bit and 64-bit guests), and while I'm
>> not entirely sure about Xen I believe it's true there. We can make this
>> explicit as we extend the binding.
>>
>> Having a -64 and -32 variant of each ID (while not pretty) allows us to
>> add additional IDs for functions that might only have a 32-bit or 64-bit
>> interface implemented, in addition to functions with common IDs:
>>
>> psci {
>> 	compatible = "$VENDOR,psci-0.2", "arm,psci-0.2", "arm,psci";
>> 	cpu_off = <12345678>;
>> 	cpu_on = <01234567>;
>> 	system_reset-32 = <02222222>;
>> 	system_reset-64 = <12222222>;
>> 	affinity_info-64 = <15555555>;
>> };
>>
>> This means that hypervisors could update their PSCI implementation while
>> keeping their DTS compatible with existing kernels.
> 
> Are you proposing of getting rid of "method" completely and therefore
> have 4 possible function IDs for each function:
> 
> system_reset-32-HVC
> system_reset-64-SMC
> system_reset-32-HVC
> system_reset-64-SMC

No. you should never have a DTB with both hvc and smc. The h/w
(firmware) to OS interface is smc. The hypervisor to guest interface is
a separate ABI and would be hvc. They are independent of each other.

> or are you proposing of choosing just the register width via function
> IDs?
> 
> Honestly I think it would be cleaner to introduce a new field called
> "width" can that be 32 or 64 and represent the register width, rather
> than having an explosion of function IDs.

I can think of lots of ways it would be cleaner, but that is not what
ARM defined. There are 3 cases to handle: 32-bit only calls, 64-bit only
calls and both 32/64-bit calls. I think hypervisors have the same issue
as firmware. Do you know the guest is 32 or 64 bit up front and can
provide it a dtb based on that? If not, then you can never use the
64-bit only calls. So Xen has to use 32-bit only or provide both 32 and
64 bit interfaces.

Rob



From nm at ti.com  Tue Jul 30 15:42:33 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 14:42:33 -0500
Subject: [PATCHv4 10/33] ARM: OMAP4: remove old clock data and link in
 new clock init code
In-Reply-To: <1374564028-11352-11-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-11-git-send-email-t-kristo@ti.com>
Message-ID: <51F81729.5010406@ti.com>

On 07/23/2013 02:20 AM, Tero Kristo wrote:

> diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
> deleted file mode 100644
> index 88e37a4..0000000
> --- a/arch/arm/mach-omap2/cclock44xx_data.c
> +++ /dev/null
[...]
> -
> -int __init omap4xxx_clk_init(void)
> -{
arch/arm/mach-omap2/clock44xx.h:int omap4xxx_clk_init(void);
arch/arm/mach-omap2/io.c:       omap_clk_init = omap4xxx_clk_init;
code in drivers/clk/omap/clk-44xx.c

Seems goofy to me a little.
entire purpose of having a clk-44xx.c is:
a) doing a clk alias for device nodes
b) set_parent, rate
both of these seem to be an old style carry forward and should instead 
be fixes with generic properties IMHO voiding the need for SoC specific 
inits.

instead all we should be doing is call of_clk_init(NULL); at appropriate 
init sequence.

-- 
Regards,
Nishanth Menon


From andrew at lunn.ch  Tue Jul 30 15:42:44 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 30 Jul 2013 21:42:44 +0200
Subject: NSA310 + DT
In-Reply-To: <51F814A0.2050403@uni-bremen.de>
References: <51F6A0DC.3020501@uni-bremen.de>
 <20130729192112.GY29916@titan.lakedaemon.net>
 <20130729204315.GK24782@lunn.ch> <51F78DA6.8010307@uni-bremen.de>
 <20130730144752.GR24782@lunn.ch> <20130730172407.3aab15c6@skate>
 <51F7EBB9.7000504@uni-bremen.de> <20130730191943.49f8070c@skate>
 <20130730183610.GT24782@lunn.ch> <51F814A0.2050403@uni-bremen.de>
Message-ID: <20130730194244.GV24782@lunn.ch>

On Tue, Jul 30, 2013 at 09:31:44PM +0200, Finn Hoffmann wrote:
> 
> Am 30.07.2013 20:36, schrieb Andrew Lunn:
> >On Tue, Jul 30, 2013 at 07:19:43PM +0200, Thomas Petazzoni wrote:
> >>Dear Finn Hoffmann,
> >>
> >>BTW, any reason why this discussion is not taking place on LAKML ?
> >Ah, sorry, did not look at the CC: list. Now one list...
> >
> >     Andrew
> >
> >>On Tue, 30 Jul 2013 18:37:13 +0200, Finn Hoffmann wrote:
> >>
> >>>$ lspci -v
> >>>00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if
> >>>00 [Normal decode])
> >>>          Flags: bus master, fast devsel, latency 0
> >>>          Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> >>>          I/O behind bridge: 00010000-00010fff
> >>>          Prefetchable memory behind bridge: e0000000-e00fffff
> >>Ok, so there should be one mem window from e0000000 to e0100000...
> >>
> >>># cat /sys/kernel/debug/mvebu-mbus/devices
> >>>[00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap 0000000000010000)
> >>>[01] disabled
> >>>[02] disabled
> >>>[03] disabled
> >>>[04] 00000000f4000000 - 00000000f4010000 : nand
> >>>[05] 00000000f5000000 - 00000000f5010000 : sram
> >>>[06] disabled
> >>>[07] disabled
> >>... but there's none here.
> >>
> >>Seems like your device is using a prefetchable memory window, and our
> >>emulated PCI-to-PCI bridge isn't taking this into account.
> >>
> >>Can you test the below (completely untested) patch? Regardless of
> >>whether it works or not, I'm interested in seeing the "PCI MVEBU"
> >>debug messages that I've added, as well as the output
> >>of /sys/kernel/debug/mvebu-mbus/devices.
> >>
> >>Thanks a lot!
> >>
> >>Thomas
> # cat /sys/kernel/debug/mvebu-mbus/devices
> [00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap 0000000000010000)
> [01] disabled
> [02] disabled
> [03] disabled
> [04] 00000000f4000000 - 00000000f4010000 : nand
> [05] 00000000f5000000 - 00000000f5010000 : sram
> [06] 00000000fff00000 - 0000000100000000 : pcie0.0
> [07] disabled
> 
> 
> # lspci -v
> 00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846
> (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: 00010000-00010fff
> Prefetchable memory behind bridge: e0000000-e00fffff
> 
> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168B PCI Express Gigabit Ethernet controller (rev
> 03)
> Subsystem: Realtek Semiconductor Co., Ltd. TEG-ECTX Gigabit PCI-E
> Adapter [Trendnet]
> Flags: bus master, fast devsel, latency 0, IRQ 9
> I/O ports at 10000 [size=256]
> Memory at e0014000 (64-bit, prefetchable) [size=4K]
> Memory at e0010000 (64-bit, prefetchable) [size=16K]
> [virtual] Expansion ROM at e0000000 [disabled] [size=64K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> Capabilities: [70] Express Endpoint, MSI 01
> Capabilities: [ac] MSI-X: Enable- Count=4 Masked-
> Capabilities: [cc] Vital Product Data
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
> Kernel driver in use: r8169
> 
> 
> 
> 
> 3122350 bytes read
> ## Booting image at 00800000 ...
> Image Name: Linux-3.11.0-rc3
> Created: 2013-07-30 18:56:55 UTC
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 3122286 Bytes = 3 MB
> Load Address: 00008000
> Entry Point: 00008000
> Verifying Checksum ... OK
> OK
> 
> Starting kernel ...
> 
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 3.11.0-rc3 (finn at T400) (gcc version 4.7.3
> (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #2 PREEMPT Tue Jul 30
> 20:56:41 CEST 2013
> CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
> CPU: VIVT data cache, VIVT instruction cache
> Machine: Marvell Kirkwood (Flattened Device Tree), model: ZyXEL NSA310
> Memory policy: ECC disabled, Data cache writeback
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
> Kernel command line: console=ttyS0,115200 root=/dev/sda2
> PID hash table entries: 1024 (order: 0, 4096 bytes)
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 253156K/262144K available (4404K kernel code, 243K rwdata,
> 1216K rodata, 151K init, 615K bss, 8988K reserved)
> Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
> vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
> lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
> modules : 0xbf000000 - 0xc0000000 ( 16 MB)
> .text : 0xc0008000 - 0xc0585248 (5621 kB)
> .init : 0xc0586000 - 0xc05abcc4 ( 152 kB)
> .data : 0xc05ac000 - 0xc05e8fe0 ( 244 kB)
> .bss : 0xc05e8fe0 - 0xc0682d60 ( 616 kB)
> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> Preemptible hierarchical RCU implementation.
> NR_IRQS:114
> sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms
> Console: colour dummy device 80x30
> Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> Setting up static identity map for 0xc042fe08 - 0xc042fe44
> pinctrl core: initialized pinctrl subsystem
> regulator-dummy: no parameters
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> Kirkwood: MV88F6281-A1, TCLK=200000000.
> Feroceon L2: Enabling L2
> Feroceon L2: Cache support initialised.
> bio: create slab <bio-0> at 0
> mvebu-pcie pcie-controller.1: PCIe0.0: link up
> mvebu-pcie pcie-controller.1: PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [io 0x1000-0xfffff]
> pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
> pci_bus 0000:00: root bus resource [bus 00-ff]
> PCI: bus0: Fast back to back transfers disabled
> pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> PCI: bus1: Fast back to back transfers disabled
> MVEBU PCI 0.0: new pref mem, base 0xfff0, limit 0xfff0
> MVEBU PCI 0.0: new pref mem, base 0x0, limit 0x0
> mvebu_mbus: cannot add window 'pcie0.0', conflicts with another window

Hi Thomas

That does not look good, does it?

     Andrew

> pci 0000:00:01.0: BAR 9: assigned [mem 0xe0000000-0xe00fffff pref]
> pci 0000:00:01.0: BAR 7: assigned [io 0x10000-0x10fff]
> pci 0000:01:00.0: BAR 6: assigned [mem 0xe0000000-0xe000ffff pref]
> pci 0000:01:00.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref]
> pci 0000:01:00.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref]
> pci 0000:01:00.0: BAR 0: assigned [io 0x10000-0x100ff]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0: bridge window [io 0x10000-0x10fff]
> MVEBU PCI 0.0: new io, base 0x1, limit 0x1
> MVEBU PCI 0.0: new mem, base 0xfff0, limit 0x0
> pci 0000:00:01.0: bridge window [mem 0xe0000000-0xe00fffff pref]
> MVEBU PCI 0.0: new pref mem, base 0xe000, limit 0xe000
> mvebu_mbus: cannot add window 'pcie0.0', conflicts with another window
> PCI: enabling device 0000:00:01.0 (0140 -> 0143)
> USB Power Off: Failed to request enable GPIO21: -517
> reg-fixed-voltage 1.regulator: Failed to register regulator: -517
> platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
> vgaarb: loaded
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> cfg80211: Calling CRDA to update world regulatory domain
> Switched to clocksource orion_clocksource
> NET: Registered protocol family 2
> TCP established hash table entries: 2048 (order: 2, 16384 bytes)
> TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
> TCP: Hash tables configured (established 2048 bind 2048)
> TCP: reno registered
> UDP hash table entries: 256 (order: 0, 4096 bytes)
> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> NET: Registered protocol family 1
> RPC: Registered named UNIX socket transport module.
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
> msgmni has been set to 494
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> kirkwood-pinctrl f1010000.pinctrl: registered pinctrl driver
> mv_xor f1060800.xor: Marvell shared XOR driver
> mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
> mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
> mv_xor f1060900.xor: Marvell shared XOR driver
> mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
> mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
> Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
> console [ttyS0] enabled
> loop: module loaded
> sata_mv f1080000.sata: slots 32 ports 2
> scsi0 : sata_mv
> scsi1 : sata_mv
> ata1: SATA max UDMA/133 irq 21
> ata2: SATA max UDMA/133 irq 21
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND
> 128MiB 3,3V 8-bit), 128MiB, page size: 2048, OOB size: 6
> 4
> Scanning device for bad blocks
> Bad eraseblock 249 at 0x000001f20000
> 9 ofpart partitions found on MTD device orion_nand
> Creating 9 MTD partitions on "orion_nand":
> 0x000000000000-0x000000100000 : "uboot"
> 0x000000100000-0x000000180000 : "uboot_env"
> 0x000000180000-0x000000200000 : "key_store"
> 0x000000200000-0x000000280000 : "info"
> 0x000000280000-0x000000c80000 : "etc"
> 0x000000c80000-0x000001680000 : "kernel_1"
> 0x000001680000-0x000004640000 : "rootfs1"
> 0x000004640000-0x000005040000 : "kernel_2"
> 0x000005040000-0x000008000000 : "rootfs2"
> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> r8169 0000:01:00.0 eth0: RTL8169 at 0xd092e000, 00:00:00:00:00:00,
> XID 00000000 IRQ 9
> r8169 0000:01:00.0 eth0: jumbo features [frames: 7152 bytes, tx
> checksumming: ok]
> libertas_sdio: Libertas SDIO driver
> libertas_sdio: Copyright Pierre Ossman
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-pci: EHCI PCI platform driver
> ehci-orion: EHCI orion driver
> orion-ehci f1050000.ehci: EHCI Host Controller
> orion-ehci f1050000.ehci: new USB bus registered, assigned bus number 1
> orion-ehci f1050000.ehci: irq 19, io mem 0xf1050000
> orion-ehci f1050000.ehci: USB 2.0 started, EHCI 1.00
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> usbcore: registered new interface driver usb-storage
> usbcore: registered new interface driver ums-datafab
> usbcore: registered new interface driver ums-freecom
> usbcore: registered new interface driver ums-jumpshot
> usbcore: registered new interface driver ums-sddr09
> usbcore: registered new interface driver ums-sddr55
> mousedev: PS/2 mouse device common for all mice
> rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0
> i2c /dev entries driver
> orion_wdt: Initial timeout 21 sec
> cpuidle: using governor ladder
> cpuidle: using governor menu
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> oprofile: no performance counters
> oprofile: using timer interrupt.
> TCP: cubic registered
> NET: Registered protocol family 17
> lib80211: common routines for IEEE802.11 drivers
> USB Power Off: 5000 mV
> input: gpio_keys.2 as /devices/gpio_keys.2/input/input0
> rtc-mv f1010300.rtc: setting system clock to 2013-07-30 19:25:09 UTC
> (1375212309)
> ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
> ata1.00: ATA-8: ST31500541AS, CC32, max UDMA/133
> ata1.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32)
> usb 1-1: new high-speed USB device number 2 using orion-ehci
> ata1.00: configured for UDMA/133
> scsi 0:0:0:0: Direct-Access ATA ST31500541AS CC32 PQ: 0 ANSI: 5
> sd 0:0:0:0: [sda] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA
> hub 1-1:1.0: USB hub found
> hub 1-1:1.0: 4 ports detected
> sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
> sd 0:0:0:0: [sda] Attached SCSI disk
> ata2: SATA link down (SStatus 0 SControl F300)
> EXT3-fs (sda2): error: couldn't mount because of unsupported
> optional features (240)
> EXT2-fs (sda2): error: couldn't mount because of unsupported
> optional features (240)
> EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
> VFS: Mounted root (ext4 filesystem) readonly on device 8:2.
> Freeing unused kernel memory: 148K (c0586000 - c05ab000)
> INIT: version 2.88 booting
> 
> >>diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> >>index 13a633b..641dd3d 100644
> >>--- a/drivers/pci/host/pci-mvebu.c
> >>+++ b/drivers/pci/host/pci-mvebu.c
> >>@@ -129,6 +129,8 @@ struct mvebu_pcie_port {
> >>  	struct mvebu_pcie *pcie;
> >>  	phys_addr_t memwin_base;
> >>  	size_t memwin_size;
> >>+	phys_addr_t prefmemwin_base;
> >>+	size_t prefmemwin_size;
> >>  	phys_addr_t iowin_base;
> >>  	size_t iowin_size;
> >>  };
> >>@@ -348,6 +350,39 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
> >>  					  MVEBU_MBUS_PCI_MEM);
> >>  }
> >>+static void mvebu_pcie_handle_prefmembase_change(struct mvebu_pcie_port *port)
> >>+{
> >>+	/* Are the new membase/memlimit values invalid? */
> >>+	if (port->bridge.prefmemlimit < port->bridge.prefmembase) {
> >>+
> >>+		/* If a window was configured, remove it */
> >>+		if (port->prefmemwin_base) {
> >>+			mvebu_mbus_del_window(port->prefmemwin_base,
> >>+					      port->prefmemwin_size);
> >>+			port->prefmemwin_base = 0;
> >>+			port->prefmemwin_size = 0;
> >>+		}
> >>+
> >>+		return;
> >>+	}
> >>+
> >>+	/*
> >>+	 * We read the PCI-to-PCI bridge emulated registers, and
> >>+	 * calculate the base address and size of the address decoding
> >>+	 * window to setup, according to the PCI-to-PCI bridge
> >>+	 * specifications.
> >>+	 */
> >>+	port->prefmemwin_base  = ((port->bridge.prefmembase & 0xFFF0) << 16);
> >>+	port->prefmemwin_size  =
> >>+		(((port->bridge.prefmemlimit & 0xFFF0) << 16) | 0xFFFFF) -
> >>+		port->prefmemwin_base;
> >>+
> >>+	mvebu_mbus_add_window_remap_flags(port->name, port->prefmemwin_base,
> >>+					  port->prefmemwin_size,
> >>+					  MVEBU_MBUS_NO_REMAP,
> >>+					  MVEBU_MBUS_PCI_MEM);
> >>+}
> >>+
> >>  /*
> >>   * Initialize the configuration space of the PCI-to-PCI bridge
> >>   * associated with the given PCIe interface.
> >>@@ -492,18 +527,28 @@ static int mvebu_sw_pci_bridge_write(struct mvebu_pcie_port *port,
> >>  		bridge->iobase = (value & 0xff) | PCI_IO_RANGE_TYPE_32;
> >>  		bridge->iolimit = ((value >> 8) & 0xff) | PCI_IO_RANGE_TYPE_32;
> >>  		bridge->secondary_status = value >> 16;
> >>+		pr_info("MVEBU PCI %d.%d: new io, base 0x%x, limit 0x%x\n",
> >>+			port->port, port->lane,
> >>+			bridge->iobase, bridge->iolimit);
> >>  		mvebu_pcie_handle_iobase_change(port);
> >>  		break;
> >>  	case PCI_MEMORY_BASE:
> >>  		bridge->membase = value & 0xffff;
> >>  		bridge->memlimit = value >> 16;
> >>+		pr_info("MVEBU PCI %d.%d: new mem, base 0x%x, limit 0x%x\n",
> >>+			port->port, port->lane,
> >>+			bridge->membase, bridge->memlimit);
> >>  		mvebu_pcie_handle_membase_change(port);
> >>  		break;
> >>  	case PCI_PREF_MEMORY_BASE:
> >>  		bridge->prefmembase = value & 0xffff;
> >>  		bridge->prefmemlimit = value >> 16;
> >>+		pr_info("MVEBU PCI %d.%d: new pref mem, base 0x%x, limit 0x%x\n",
> >>+			port->port, port->lane,
> >>+			bridge->prefmembase, bridge->prefmemlimit);
> >>+		mvebu_pcie_handle_prefmembase_change(port);
> >>  		break;
> >>  	case PCI_PREF_BASE_UPPER32:
> >>
> >>
> >>-- 
> >>Thomas Petazzoni, Free Electrons
> >>Kernel, drivers, real-time and embedded Linux
> >>development, consulting, training and support.
> >>http://free-electrons.com
> >_______________________________________________
> >linux-arm-kernel mailing list
> >linux-arm-kernel at lists.infradead.org
> >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From nm at ti.com  Tue Jul 30 15:49:31 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 14:49:31 -0500
Subject: [PATCHv4 16/33] CLK: OMAP: DPLL: do not of_iomap NULL autoidle
 register
In-Reply-To: <1374564028-11352-17-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-17-git-send-email-t-kristo@ti.com>
Message-ID: <51F818CB.4060007@ti.com>

On 07/23/2013 02:20 AM, Tero Kristo wrote:
> AM33xx series SoCs do not have autoidle support, and for these the
> autoidle register is marked as NULL. Check against a NULL pointer and
> do not attempt to of_iomap in this case, as this just creates a bogus
> pointer and causes a kernel crash during boot.
>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
>   drivers/clk/omap/dpll.c |   10 +++++++++-
>   1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
> index 1d24feada..d8a958a 100644
> --- a/drivers/clk/omap/dpll.c
> +++ b/drivers/clk/omap/dpll.c
> @@ -162,6 +162,7 @@ static void __init of_omap_dpll_setup(struct device_node *node,
>   	u32 max_multiplier = 2047;
>   	u32 max_divider = 128;
>   	u32 min_divider = 1;
> +	u32 val;
>   	int i;
>
>   	dd = kzalloc(sizeof(struct dpll_data), GFP_KERNEL);
> @@ -210,7 +211,14 @@ static void __init of_omap_dpll_setup(struct device_node *node,
>
>   	dd->control_reg = of_iomap(node, 0);
>   	dd->idlest_reg = of_iomap(node, 1);
> -	dd->autoidle_reg = of_iomap(node, 2);
> +	/*
> +	 * AM33xx DPLLs have no autoidle support, and the autoidle reg
> +	 * for these is NULL. Do not attempt to of_iomap in this case,
> +	 * as this just creates a bogus pointer and crashes the kernel.
> +	 */
> +	of_property_read_u32_index(node, "reg", 2 * 2, &val);
> +	if (val)
> +		dd->autoidle_reg = of_iomap(node, 2);
should we not do that for all the parameters?
OR:
move this as index 3 which is optional and is not defined for am33xx?

>   	dd->mult_div1_reg = of_iomap(node, 3);

>
>   	dd->idlest_mask = idlest_mask;
>
we could probably squash this in original dpll.c as a result?

-- 
Regards,
Nishanth Menon


From nm at ti.com  Tue Jul 30 15:58:02 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 14:58:02 -0500
Subject: [PATCHv4 17/33] CLK: DT: add support for set-rate-parent flag
In-Reply-To: <1374564028-11352-18-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-18-git-send-email-t-kristo@ti.com>
Message-ID: <51F81ACA.7090501@ti.com>

On 07/23/2013 02:20 AM, Tero Kristo wrote:
> Adding set-rate-parent to clock node now allows a node to forward
> clk_set_rate request to its parent clock.

Apologies about previous comment of set-parent missing, the sequence of 
patches messed with me :(. had expected generic clk changes at the start 
of the series followed by the rest.

>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
>   drivers/clk/clk-divider.c      |    6 +++++-
>   drivers/clk/clk-fixed-factor.c |    6 +++++-
>   drivers/clk/clk-gate.c         |    8 ++++++--
>   drivers/clk/clk-mux.c          |    6 +++++-
>   4 files changed, 21 insertions(+), 5 deletions(-)

Documentation/devicetree/bindings/clock/ needs update as well.
[...]

-- 
Regards,
Nishanth Menon


From nm at ti.com  Tue Jul 30 16:00:40 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 15:00:40 -0500
Subject: [PATCHv4 19/33] CLK: omap: add am33xx clock init file
In-Reply-To: <1374564028-11352-20-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-20-git-send-email-t-kristo@ti.com>
Message-ID: <51F81B68.2020708@ti.com>

On 07/23/2013 02:20 AM, Tero Kristo wrote:
> clk-33xx.c now contains the clock init functionality for am33xx, including
> DT clock registration and adding of static clkdev entries.
>
> This patch also moves the omap2_clk_enable_init_clocks declaration to
> the driver include, as this is needed by the am33xx clock init code.
>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
>   arch/arm/mach-omap2/clock.h |    1 -
>   drivers/clk/omap/clk-33xx.c |   85 +++++++++++++++++++++++++++++++++++++++++++
>   include/linux/clk/omap.h    |    1 +
>   3 files changed, 86 insertions(+), 1 deletion(-)
>   create mode 100644 drivers/clk/omap/clk-33xx.c
>
> diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
> index d1a3125..6273f14 100644
> --- a/arch/arm/mach-omap2/clock.h
> +++ b/arch/arm/mach-omap2/clock.h
> @@ -267,7 +267,6 @@ void omap2_clk_dflt_find_idlest(struct clk_hw_omap *clk,
>   				void __iomem **idlest_reg,
>   				u8 *idlest_bit, u8 *idlest_val);
>   int omap2_clk_enable_autoidle_all(void);
> -void omap2_clk_enable_init_clocks(const char **clk_names, u8 num_clocks);
>   int omap2_clk_switch_mpurate_at_boot(const char *mpurate_ck_name);
>   void omap2_clk_print_new_rates(const char *hfclkin_ck_name,
>   			       const char *core_ck_name,
> diff --git a/drivers/clk/omap/clk-33xx.c b/drivers/clk/omap/clk-33xx.c
> new file mode 100644
> index 0000000..3ada30e
> --- /dev/null
> +++ b/drivers/clk/omap/clk-33xx.c
[...]
> +static const char *enable_init_clks[] = {
> +	"dpll_ddr_m2_ck",
> +	"dpll_mpu_m2_ck",
> +	"l3_gclk",
> +	"l4hs_gclk",
> +	"l4fw_gclk",
> +	"l4ls_gclk",
> +	/* Required for external peripherals like, Audio codecs */
> +	"clkout2_ck",
> +};

should be a sort of dt property?

-- 
Regards,
Nishanth Menon


From nm at ti.com  Tue Jul 30 16:08:26 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 15:08:26 -0500
Subject: [PATCHv4 21/33] CLK: OMAP: DPLL: add omap3 dpll support
In-Reply-To: <1374564028-11352-22-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-22-git-send-email-t-kristo@ti.com>
Message-ID: <51F81D3A.7080007@ti.com>

On 07/23/2013 02:20 AM, Tero Kristo wrote:
> OMAP3 has slightly different DPLLs from those compared to OMAP4. Modified
> code for the same.
>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
>   drivers/clk/omap/dpll.c |   96 +++++++++++++++++++++++++++++++++++++++++------
>   1 file changed, 85 insertions(+), 11 deletions(-)
>
:) wont repeat the binding crib again..

> diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
> index d8a958a..ecb1fbd 100644
> --- a/drivers/clk/omap/dpll.c
> +++ b/drivers/clk/omap/dpll.c
> @@ -26,6 +26,11 @@
>   #include <linux/of_address.h>
>   #include <linux/clk/omap.h>
>
> +enum {
> +	SUBTYPE_OMAP3_DPLL,
> +	SUBTYPE_OMAP4_DPLL,
> +};
> +
>   static const struct clk_ops dpll_m4xen_ck_ops = {
>   	.enable		= &omap3_noncore_dpll_enable,
>   	.disable	= &omap3_noncore_dpll_disable,
> @@ -40,6 +45,13 @@ static const struct clk_ops dpll_core_ck_ops = {
>   	.get_parent	= &omap2_init_dpll_parent,
>   };
>
> +static const struct clk_ops omap3_dpll_core_ck_ops = {
> +	.init		= &omap2_init_clk_clkdm,
> +	.get_parent	= &omap2_init_dpll_parent,
> +	.recalc_rate	= &omap3_dpll_recalc,
> +	.round_rate	= &omap2_dpll_round_rate,
> +};
> +
>   static const struct clk_ops dpll_ck_ops = {
>   	.enable		= &omap3_noncore_dpll_enable,
>   	.disable	= &omap3_noncore_dpll_disable,
> @@ -50,6 +62,26 @@ static const struct clk_ops dpll_ck_ops = {
>   	.init		= &omap2_init_clk_clkdm,
>   };
>
> +static const struct clk_ops omap3_dpll_ck_ops = {
> +	.init		= &omap2_init_clk_clkdm,
> +	.enable		= &omap3_noncore_dpll_enable,
> +	.disable	= &omap3_noncore_dpll_disable,
> +	.get_parent	= &omap2_init_dpll_parent,
> +	.recalc_rate	= &omap3_dpll_recalc,
> +	.set_rate	= &omap3_noncore_dpll_set_rate,
> +	.round_rate	= &omap2_dpll_round_rate,
> +};
> +
> +static const struct clk_ops omap3_dpll_per_ck_ops = {
> +	.init		= &omap2_init_clk_clkdm,
> +	.enable		= &omap3_noncore_dpll_enable,
> +	.disable	= &omap3_noncore_dpll_disable,
> +	.get_parent	= &omap2_init_dpll_parent,
> +	.recalc_rate	= &omap3_dpll_recalc,
> +	.set_rate	= &omap3_dpll4_set_rate,
> +	.round_rate	= &omap2_dpll_round_rate,
> +};
> +
>   static const struct clk_ops dpll_x2_ck_ops = {
>   	.recalc_rate	= &omap3_clkoutx2_recalc,
>   };
> @@ -144,7 +176,9 @@ struct clk *omap_clk_register_dpll_x2(struct device *dev, const char *name,
>    * of_omap_dpll_setup() - Setup function for OMAP DPLL clocks
>    */
>   static void __init of_omap_dpll_setup(struct device_node *node,
> -					const struct clk_ops *ops)
> +					const struct clk_ops *ops, u32 freqsel,
> +					u32 modes, u8 mul_div_shift,
> +					int subtype)
>   {
>   	struct clk *clk;
>   	const char *clk_name = node->name;
> @@ -157,8 +191,8 @@ static void __init of_omap_dpll_setup(struct device_node *node,
>   	u32 idlest_mask = 0x1;
>   	u32 enable_mask = 0x7;
>   	u32 autoidle_mask = 0x7;
> -	u32 mult_mask = 0x7ff << 8;
> -	u32 div1_mask = 0x7f;
> +	u32 mult_mask = 0x7ff << (8 + mul_div_shift);
> +	u32 div1_mask = 0x7f << mul_div_shift;
>   	u32 max_multiplier = 2047;
>   	u32 max_divider = 128;
>   	u32 min_divider = 1;
> @@ -193,7 +227,7 @@ static void __init of_omap_dpll_setup(struct device_node *node,
>
>   	clkspec.np = of_parse_phandle(node, "ti,clk-ref", 0);
>   	dd->clk_ref = of_clk_get_from_provider(&clkspec);
> -	if (!dd->clk_ref) {
> +	if (IS_ERR(dd->clk_ref)) {

belongs to original patch.

>   		pr_err("%s: ti,clk-ref for %s not found\n", __func__,
>   			clk_name);
>   		goto cleanup;
> @@ -201,7 +235,7 @@ static void __init of_omap_dpll_setup(struct device_node *node,
>
>   	clkspec.np = of_parse_phandle(node, "ti,clk-bypass", 0);
>   	dd->clk_bypass = of_clk_get_from_provider(&clkspec);
> -	if (!dd->clk_bypass) {
> +	if (IS_ERR(dd->clk_bypass)) {

same

>   		pr_err("%s: ti,clk-bypass for %s not found\n", __func__,
>   			clk_name);
>   		goto cleanup;
> @@ -225,14 +259,31 @@ static void __init of_omap_dpll_setup(struct device_node *node,
>   	dd->enable_mask = enable_mask;
>   	dd->autoidle_mask = autoidle_mask;
>
> -	dd->modes = 0xa0;
> +	if (!of_property_read_u32(node, "ti,recal-en-bit", &val))
> +		dd->recal_en_bit = val;
> +
> +	if (!of_property_read_u32(node, "ti,recal-st-bit", &val))
> +		dd->recal_st_bit = val;
> +
> +	if (!of_property_read_u32(node, "ti,auto-recal-bit", &val))
> +		dd->auto_recal_bit = val;

now I understand what it means.

> +
> +	of_property_read_u32(node, "ti,modes", &modes);
i see we pass in modes, and read ti,modes to &modes. it is a bit sketchy 
without bindings documentation.

> +
> +	dd->modes = modes;

Should have belonged to original patch.

> +
> +	dd->freqsel_mask = freqsel;
>
>   	if (of_property_read_bool(node, "ti,dpll-j-type")) {
>   		dd->sddiv_mask = 0xff000000;
> -		mult_mask = 0xfff << 8;
> -		div1_mask = 0xff;
> +		mult_mask = 0xfff << (8 + mul_div_shift);
>   		max_multiplier = 4095;
> -		max_divider = 256;
> +		if (subtype == SUBTYPE_OMAP3_DPLL) {
> +			dd->dco_mask = 0xe00000;
> +		} else {
> +			div1_mask = 0xff << mul_div_shift;
> +			max_divider = 256;
> +		}
>   	}
>
>   	if (of_property_read_bool(node, "ti,dpll-regm4xen")) {
> @@ -281,7 +332,30 @@ static void __init of_omap_dpll_x2_setup(struct device_node *node)
>
>   __init void of_omap3_dpll_setup(struct device_node *node)
>   {
> -	/* XXX: to be done */
> +	const struct clk_ops *ops;
> +	u32 freqsel = 0xf0;
> +	u32 modes = 0xa0;
> +	u8 mul_div_shift = 0;
> +
> +	ops = &omap3_dpll_ck_ops;
> +
> +	if (of_property_read_bool(node, "ti,dpll-core")) {
> +		ops = &omap3_dpll_core_ck_ops;
> +		mul_div_shift = 8;
> +		modes = 0x0;
> +	}
> +
> +	if (of_property_read_bool(node, "ti,dpll-peripheral")) {
> +		ops = &omap3_dpll_per_ck_ops;
> +		freqsel = 0xf00000;
> +	}
> +
> +	if (of_property_read_bool(node, "ti,dpll-j-type"))
> +		freqsel = 0x0;
> +
> +	of_omap_dpll_setup(node, ops, freqsel, modes, mul_div_shift,
> +		SUBTYPE_OMAP3_DPLL);
> +
>   }
>   EXPORT_SYMBOL_GPL(of_omap3_dpll_setup);
>   CLK_OF_DECLARE(omap3_dpll_clock, "ti,omap3-dpll-clock", of_omap3_dpll_setup);
> @@ -306,7 +380,7 @@ __init void of_omap4_dpll_setup(struct device_node *node)
>   	if (of_property_read_bool(node, "ti,dpll-no-gate"))
>   		ops = &dpll_no_gate_ck_ops;
>
> -	of_omap_dpll_setup(node, ops);
> +	of_omap_dpll_setup(node, ops, 0, 0xa0, 0, SUBTYPE_OMAP4_DPLL);
what is 0xa0?

>   }
>   EXPORT_SYMBOL_GPL(of_omap4_dpll_setup);
>   CLK_OF_DECLARE(omap4_dpll_clock, "ti,omap4-dpll-clock", of_omap4_dpll_setup);
>

I think this should be squashed and a single dpll.c introduction to be done.


-- 
Regards,
Nishanth Menon


From maxime.ripard at free-electrons.com  Tue Jul 30 16:10:06 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 22:10:06 +0200
Subject: [PATCH 08/10] ARM: sun7i: DT: Add UART muxing options to the DTSI
In-Reply-To: <51F80EE9.30801@cogentembedded.com>
References: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375196394-21138-9-git-send-email-maxime.ripard@free-electrons.com>
 <51F80EE9.30801@cogentembedded.com>
Message-ID: <20130730201006.GD12562@lukather>

Hi Sergei,

On Tue, Jul 30, 2013 at 11:07:21PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 07/30/2013 06:59 PM, Maxime Ripard wrote:
> 
> >The UARTs on the A20 can be muxed to several pins. Add a few options to
> >the DTSI so that we can start using them in the boards' DT.
> 
> >Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> >---
> >  arch/arm/boot/dts/sun7i-a20.dtsi | 21 +++++++++++++++++++++
> >  1 file changed, 21 insertions(+)
> 
> >diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> >index 704fca9..9f45e8d 100644
> >--- a/arch/arm/boot/dts/sun7i-a20.dtsi
> >+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> >@@ -70,6 +70,27 @@
> >  			#address-cells = <1>;
> >  			#size-cells = <0>;
> >  			#gpio-cells = <3>;
> >+
> >+			uart0_pins_a: uart0 at 0 {
> 
>    Why have address part of the node name if there's not "reg" property?

It allows to easily differentiate distinct pin groups for the same IP.

A second group of pin that can be muxed to uart0 would be defined as
uart0_pins_b: uart0 at 1.

I could have used any other construct, like uart0-0 and uart0-1, I just
find that it fits more in the usual DT constructs.

> And the preferred node name is "serial", not "uart", according to
> the ePAPR spec (http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf).

But only for actual serial driver right? This is a pinctrl group
declaration.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130730/10421948/attachment.sig>

From nm at ti.com  Tue Jul 30 16:13:40 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 15:13:40 -0500
Subject: [PATCHv4 22/33] CLK: OMAP: update gate clock setup for OMAP3
In-Reply-To: <1374564028-11352-23-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-23-git-send-email-t-kristo@ti.com>
Message-ID: <51F81E74.9070609@ti.com>

On 07/23/2013 02:20 AM, Tero Kristo wrote:
> OMAP3 gate clocks are handled through the clk driver now. Basic gate
> clock can't be used as the OMAP3 gate clocks have some special features,
> namely the idle status linkage which is on separate register.
>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
>   drivers/clk/omap/gate.c |   27 +++++++++++++++++++++++++--
>   1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
> index 7186bb2..b560ff4 100644
> --- a/drivers/clk/omap/gate.c
> +++ b/drivers/clk/omap/gate.c
> @@ -28,12 +28,19 @@
>
>   #ifdef CONFIG_OF
>
> -static const struct clk_ops omap_gate_clk_ops = {
> +static const struct clk_ops omap_gate_clkdm_clk_ops = {
>   	.init		= &omap2_init_clk_clkdm,
>   	.enable		= &omap2_clkops_enable_clkdm,
>   	.disable	= &omap2_clkops_disable_clkdm,
>   };
>
> +static const struct clk_ops omap_gate_clk_ops = {
> +	.init		= &omap2_init_clk_clkdm,
> +	.enable		= &omap2_dflt_clk_enable,
> +	.disable	= &omap2_dflt_clk_disable,
> +	.is_enabled	= &omap2_dflt_clk_is_enabled,
> +};
> +
>   void __init of_omap_gate_clk_setup(struct device_node *node)
>   {
>   	struct clk *clk;
> @@ -43,6 +50,7 @@ void __init of_omap_gate_clk_setup(struct device_node *node)
>   	int num_parents;
>   	const char **parent_names;
>   	int i;
> +	u32 val;
>
>   	clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
>   	if (!clk_hw) {
> @@ -56,7 +64,22 @@ void __init of_omap_gate_clk_setup(struct device_node *node)
>   	of_property_read_string(node, "ti,clkdm-name", &clk_hw->clkdm_name);
>
>   	init.name = clk_name;
> -	init.ops = &omap_gate_clk_ops;
> +	init.flags = 0;
> +
> +	if (of_property_read_u32_index(node, "reg", 0, &val)) {
> +		/* No register, clkdm control only */
> +		init.ops = &omap_gate_clkdm_clk_ops;
> +	} else {
> +		init.ops = &omap_gate_clk_ops;
> +		clk_hw->enable_reg = of_iomap(node, 0);
> +		of_property_read_u32(node, "ti,enable-bit", &val);
> +		clk_hw->enable_bit = val;
> +
> +		if (of_property_read_bool(node, "ti,dss-clk"))
> +			clk_hw->ops = &clkhwops_omap3430es2_dss_usbhost_wait;

umm, it was going relatively ok so far, till i hit this :( it is 
probably a quirk... but still..

> +		else
> +			clk_hw->ops = &clkhwops_wait;
> +	}
>
>   	num_parents = of_clk_get_parent_count(node);
>   	if (num_parents < 1) {
>

but still no usage of "ti,omap-gate-clock" makes me question the need 
for this file.

-- 
Regards,
Nishanth Menon


From nm at ti.com  Tue Jul 30 16:19:35 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 15:19:35 -0500
Subject: [PATCHv4 29/33] CLK: omap: add omap3 clock init file
In-Reply-To: <1374564028-11352-30-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-30-git-send-email-t-kristo@ti.com>
Message-ID: <51F81FD7.2060707@ti.com>

On 07/23/2013 02:20 AM, Tero Kristo wrote:
> clk-3xxx.c now contains the clock init functionality for omap3, including
> DT clock registration and adding of static clkdev entries.
>
> This patch also splits the OMAP3 clock registration code under mach-omap2
> to use OMAP3 subtype specific clk init functions.
>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
>   arch/arm/mach-omap2/Makefile          |    2 +-
>   arch/arm/mach-omap2/cclock3xxx_data.c | 3641 ---------------------------------

Tony and a lot of people is not going to like removing support for 
non-dt boot for OMAP3 before "it's time is due" ;)



-- 
Regards,
Nishanth Menon


From coelho at ti.com  Tue Jul 30 16:21:08 2013
From: coelho at ti.com (Luciano Coelho)
Date: Tue, 30 Jul 2013 23:21:08 +0300
Subject: [PATCH v3] Documentation: dt: bindings: TI WiLink modules
Message-ID: <1375215668-29171-1-git-send-email-coelho@ti.com>

Add device tree bindings documentation for the TI WiLink modules.
Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8
modules is supported.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---

In v3, use IRQ_TYPE_LEVEL_HIGH in the example, as suggested by Laurent.

 .../devicetree/bindings/net/wireless/ti-wilink.txt | 68 ++++++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/wireless/ti-wilink.txt

diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
new file mode 100644
index 0000000..aafebb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
@@ -0,0 +1,68 @@
+TI WiLink Wireless Modules Device Tree Bindings
+===============================================
+
+The WiLink modules provide wireless connectivity, such as WLAN,
+Bluetooth, FM and NFC.
+
+There are several different modules available, which can be grouped by
+their generation: WiLink6, WiLink7 and WiLink8.  WiLink4 is not
+currently supported with device tree.
+
+Currently, only the WLAN portion of the modules is supported with
+device tree.
+
+Required properties:
+--------------------
+
+- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8"
+- interrupt-parent: the interrupt controller
+- interrupts: out-of-band WLAN interrupt
+	See the interrupt controller's bindings documentation for
+	detailed definition.
+
+Optional properties:
+--------------------
+
+- clocks: list of clocks needed by the chip as follows:
+
+  refclock: the internal WLAN reference clock frequency (required for
+	WiLink6 and WiLink7; not used for WiLink8).
+
+  tcxoclock: the internal WLAN TCXO clock frequency (required for
+	WiLink7 not used for WiLink6 and WiLink8).
+
+  The clocks must be defined and named accordingly.  For example:
+
+  clocks = <&refclock>
+  clock-names = "refclock";
+
+  refclock: refclock {
+		     compatible = "ti,wilink-clock";
+		     #clock-cells = <0>;
+		     clock-frequency = <38400000>;
+	};
+
+  Some modules that contain the WiLink chip provide clocks in the
+  module itself.  In this case, we define a "ti,wilink-clock" as shown
+  above.  But any other clock could in theory be used, so the proper
+  clock definition should be used.
+
+
+Example:
+--------
+
+Example definition that can be used in OMAP4 Panda:
+
+wlan {
+	compatible = "ti,wilink6";
+	interrupt-parent = <&gpio2>;
+	interrupts = <21 IRQ_TYPE_LEVEL_HIGH>;	/* gpio line 53 */
+	clocks = <&refclock>;
+	clock-names = "refclock";
+
+	refclock: refclock {
+		compatible = "ti,wilink-clock";
+		#clock-cells = <0>;
+		clock-frequency = <38400000>;
+	};
+};
-- 
1.8.3.2



From paul at pwsan.com  Tue Jul 30 16:23:40 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 30 Jul 2013 20:23:40 +0000 (UTC)
Subject: OMAP baseline test results for v3.10-rc6
In-Reply-To: <51F66024.1030804@ti.com>
References: <alpine.DEB.2.02.1306170521020.9909@utopia.booyaka.com>
 <20130625160243.GE22312@arwen.pp.htv.fi>
 <alpine.DEB.2.02.1306251746060.14373@utopia.booyaka.com>
 <51C9F0A8.1050607@ti.com>
 <alpine.DEB.2.02.1306261713260.6135@utopia.booyaka.com>
 <51CB4C20.3060306@ti.com>
 <alpine.DEB.2.02.1307290826180.30864@utopia.booyaka.com>
 <51F66024.1030804@ti.com>
Message-ID: <alpine.DEB.2.02.1307302001500.4505@utopia.booyaka.com>

Hi Tom,

On Mon, 29 Jul 2013, Tom Rini wrote:

> On 07/29/2013 04:29 AM, Paul Walmsley wrote:
> > On Wed, 26 Jun 2013, Tom Rini wrote:
> >>
> >> Well, me?  I'm all in favor of people using latest release of U-Boot for
> >> their board and yelling and screaming (or just reporting bugs) when
> >> things don't work.  I'm biased of course.
> > 
> > That's exactly how bootloader developers should be testing their changes.  
> > But most of the rest of us kernel folks don't want to deal with constantly 
> > replacing bootloaders, and then dealing with the inevitable bootloader 
> > regressions, when what we're really trying to test is the kernel...
> > The kernel should be completely independent of the bootloader used.  
> 
> And thus the chicken and egg problems we have today.  The kernel should
> be independent, but unless someone is also testing more recent U-Boots
> as well, we may or may not have more hidden clock problems.

It doesn't have to be this way :-)

IMHO the only thing that the bootloader should be responsible for is the 
minimum that's needed to get the kernel started.  Setting up RAM, maybe a 
handful of critical system clocks, and that's basically it.

In fact it would be great if there was a bootloader option where it would 
return the rest of the bits on the chip that it tweaked to power-on reset 
status.  That would let you guys off the hook for everything that we don't 
set up correctly in the kernel.  And it would allow the kernel folks to 
see where the problems really are.  And then for customer-targeted images, 
that bootloader option could be kept off so management doesn't freak out.

You might not believe this, but we went to great pain on the OMAP Linux 
kernel to reset as much as we could, as early as possible.  This was 
partially so that if kernel device driver authors assumed that the 
bootloader would configure their device, it would show up as a bug that 
would need to be fixed.  We were even resetting and reprogramming the 
SDRAM controller for a while.  Unfortunately we weren't able to reset the 
clocks...

> I don't suspect what I'm going to say now will have a lot of traction,
> but I really think that much like user space, every once in a while (6
> months? year?) one ought to update their environment and make sure
> things are still working too.
> 
> You folks don't need to test ever rev of U-Boot (that's my job), but it
> often feels like there's this cycle of "U-Boot sucks and can't do ... !"
> "We've had that fixed / improved / changed for years now, upgrade?" "No,
> can't / won't!".  And...

I've always wanted to switch most of the devices in my test platform over 
to serial-booted bootloaders and MLOs/X-loaders/SPLs.  That way any 
bootloader could be booted during automated test.  This is what's 
happening now on the BeagleBone-black here; that's really easy to 
cold-boot from serial due to the Xmodem download code implemented in the 
ROM, plus the lack of flash:

http://www.pwsan.com/omap/testlogs/test_v3.11-rc3/20130728224046/boot/am335xbonelt/am335x-bone/

Do you know if anyone ever got serial cold-booting working well for, say, 
OMAP3 and OMAP4 chips?
 
> For shipping consumer product, or however you want to call those kind of
> devices, yes, appended dtb needs to work since the bootloader is locked,
> and making that boot something else to boot the kernel is an exercise
> for us oddballs :)  But the boards which are designed as reference
> platform, we can make your lives easier, if you let us help.  If
> something is a pain to do, give us feedback.

OK I would love it if you would add a bootloader option 
"ASSUME_WORKING_KERNEL" that would reset every non-essential device on the 
board to power-on reset, and reset any non-essential clock register bits 
etc. to their POR values.  Unlock the USB DPLL, etc.  To start with, you'd 
need to leave that disabled for shipping customer images, but we could 
start testing with it and prevent patches from going upstream that 
implicitly rely on the bootloader settings.


- Paul


From nm at ti.com  Tue Jul 30 16:23:59 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 15:23:59 -0500
Subject: [PATCHv4 23/33] CLK: OMAP: add interface clock support for OMAP3
In-Reply-To: <1374564028-11352-24-git-send-email-t-kristo@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-24-git-send-email-t-kristo@ti.com>
Message-ID: <51F820DF.1080306@ti.com>

On 07/23/2013 02:20 AM, Tero Kristo wrote:
> OMAP3 has interface clocks in addition to functional clocks, which
is it just OMAP3?

> require special handling for the autoidle and idle status register
> offsets mainly.

>
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
>   drivers/clk/omap/Makefile    |    2 +-
>   drivers/clk/omap/clk.c       |    3 ++
>   drivers/clk/omap/interface.c |  110 ++++++++++++++++++++++++++++++++++++++++++
should this be isolated off for omap3?

>   3 files changed, 114 insertions(+), 1 deletion(-)
>   create mode 100644 drivers/clk/omap/interface.c
>
> diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
> index c4e8825..faaeb62 100644
> --- a/drivers/clk/omap/Makefile
> +++ b/drivers/clk/omap/Makefile
> @@ -1,3 +1,3 @@
>   obj-y					+= clk.o dpll.o autoidle.o gate.o \
>   					   clk-44xx.o clk-54xx.o clk-7xx.o \
> -					   clk-33xx.o
> +					   clk-33xx.o interface.o
> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
> index 8c89714..5cbefde 100644
> --- a/drivers/clk/omap/clk.c
> +++ b/drivers/clk/omap/clk.c
> @@ -30,6 +30,9 @@ static const struct of_device_id clk_match[] = {
>   	{.compatible = "gate-clock", .data = of_gate_clk_setup, },
>   	{.compatible = "ti,omap4-dpll-clock", .data = of_omap4_dpll_setup, },
>   	{.compatible = "ti,gate-clock", .data = of_omap_gate_clk_setup, },
> +	{.compatible = "ti,interface-clock",
> +		.data = of_omap_interface_clk_setup, },

> +	{.compatible = "ti,omap3-dpll-clock", .data = of_omap3_dpll_setup, },
I dont see how this line has anything to do with the patch.
>   	{},
>   };
>
> diff --git a/drivers/clk/omap/interface.c b/drivers/clk/omap/interface.c
> new file mode 100644
> index 0000000..f1f1a1a
> --- /dev/null
> +++ b/drivers/clk/omap/interface.c
> @@ -0,0 +1,110 @@
> +/*
> + * OMAP interface clock support
> + *
> + * Copyright (C) 2013 Texas Instruments, Inc.
> + *
> + * Tero Kristo <t-kristo at ti.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/io.h>
> +#include <linux/err.h>
> +#include <linux/string.h>
> +#include <linux/log2.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/clk/omap.h>
> +
> +#ifdef CONFIG_OF
> +
> +static const struct clk_ops omap_interface_clk_ops = {
> +	.init		= &omap2_init_clk_clkdm,
> +	.enable		= &omap2_dflt_clk_enable,
> +	.disable	= &omap2_dflt_clk_disable,
> +	.is_enabled	= &omap2_dflt_clk_is_enabled,
> +};
> +
> +void __init of_omap_interface_clk_setup(struct device_node *node)
> +{
> +	struct clk *clk;
> +	struct clk_init_data init;
> +	struct clk_hw_omap *clk_hw;
> +	const char *clk_name = node->name;
> +	int num_parents;
> +	const char **parent_names;
> +	int i;
> +	u32 val;
> +
> +	clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
> +	if (!clk_hw) {
> +		pr_err("%s: could not allocate clk_hw_omap\n", __func__);
> +		return;
> +	}
> +
> +	clk_hw->hw.init = &init;
> +	clk_hw->ops = &clkhwops_iclk_wait;
> +	clk_hw->enable_reg = of_iomap(node, 0);
> +
> +	if (!of_property_read_u32(node, "ti,enable-bit", &val))
> +		clk_hw->enable_bit = val;
> +
> +	if (of_property_read_bool(node, "ti,iclk-no-wait"))
> +		clk_hw->ops = &clkhwops_iclk;
> +
> +	if (of_property_read_bool(node, "ti,iclk-hsotgusb"))
> +		clk_hw->ops = &clkhwops_omap3430es2_iclk_hsotgusb_wait;
> +
> +	if (of_property_read_bool(node, "ti,iclk-dss"))
> +		clk_hw->ops = &clkhwops_omap3430es2_iclk_dss_usbhost_wait;
> +
> +	if (of_property_read_bool(node, "ti,iclk-ssi"))
> +		clk_hw->ops = &clkhwops_omap3430es2_iclk_ssi_wait;
> +
> +	of_property_read_string(node, "clock-output-names", &clk_name);
> +	of_property_read_string(node, "ti,clkdm-name", &clk_hw->clkdm_name);
> +
> +	init.name = clk_name;
> +	init.ops = &omap_interface_clk_ops;
> +	init.flags = 0;
> +
> +	num_parents = of_clk_get_parent_count(node);
> +	if (num_parents < 1) {
> +		pr_err("%s: omap interface_clk %s must have parent(s)\n",
> +			__func__, node->name);
> +		goto cleanup;
> +	}
> +
> +	parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
> +
> +	for (i = 0; i < num_parents; i++)
> +		parent_names[i] = of_clk_get_parent_name(node, i);
> +
> +	init.num_parents = num_parents;
> +	init.parent_names = parent_names;
> +
> +	clk = clk_register(NULL, &clk_hw->hw);
> +
> +	if (!IS_ERR(clk)) {
> +		of_clk_add_provider(node, of_clk_src_simple_get, clk);
> +		omap2_init_clk_hw_omap_clocks(clk);
> +		return;
> +	}
> +
> +cleanup:
the usual stuff about parent name, error checks init = { 0 } etc..

> +	kfree(clk_hw);
> +}
> +EXPORT_SYMBOL(of_omap_interface_clk_setup);
> +CLK_OF_DECLARE(omap_interface_clk, "ti,omap-interface-clock",
> +		of_omap_interface_clk_setup);
> +#endif
>


-- 
Regards,
Nishanth Menon


From nm at ti.com  Tue Jul 30 16:28:17 2013
From: nm at ti.com (Nishanth Menon)
Date: Tue, 30 Jul 2013 15:28:17 -0500
Subject: OMAP baseline test results for v3.10-rc6
In-Reply-To: <alpine.DEB.2.02.1307302001500.4505@utopia.booyaka.com>
References: <alpine.DEB.2.02.1306170521020.9909@utopia.booyaka.com>
 <20130625160243.GE22312@arwen.pp.htv.fi>
 <alpine.DEB.2.02.1306251746060.14373@utopia.booyaka.com>
 <51C9F0A8.1050607@ti.com>
 <alpine.DEB.2.02.1306261713260.6135@utopia.booyaka.com>
 <51CB4C20.3060306@ti.com>
 <alpine.DEB.2.02.1307290826180.30864@utopia.booyaka.com>
 <51F66024.1030804@ti.com>
 <alpine.DEB.2.02.1307302001500.4505@utopia.booyaka.com>
Message-ID: <51F821E1.3040808@ti.com>

On 07/30/2013 03:23 PM, Paul Walmsley wrote:

> Do you know if anyone ever got serial cold-booting working well for, say,
> OMAP3 and OMAP4 chips?

I had done configuration header based OMAP3 boot[1] once upon a time, 
but serial boot straight to kernel, we need a second that gives control 
there.. could be done, have'nt heard it done + I dont directly see a 
customer usage model for it ("ROI for investment of time") - so doubt 
any investment was done.

CH was the closest I could get to avoiding bootloaders in it's entirety. 
but the level of interest fell off when there was no viable usage model 
for the same.


[1] http://marc.info/?t=127232401100003&r=1&w=2
-- 
Regards,
Nishanth Menon


From maxime.ripard at free-electrons.com  Tue Jul 30 16:31:15 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 22:31:15 +0200
Subject: [linux-sunxi] [PATCH 04/10] pinctrl: sunxi: Wrap long compatible
 declaration lines
In-Reply-To: <1375196953.32691.61.camel@kazak.uk.xensource.com>
References: <1375196394-21138-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375196394-21138-5-git-send-email-maxime.ripard@free-electrons.com>
 <1375196953.32691.61.camel@kazak.uk.xensource.com>
Message-ID: <20130730203115.GE12562@lukather>

Hi Ian,

On Tue, Jul 30, 2013 at 04:09:13PM +0100, Ian Campbell wrote:
> On Tue, 2013-07-30 at 16:59 +0200, Maxime Ripard wrote:
> > The compatible declaration and their associated data are exceeding the
> > 80-characters width limit.
> > 
> > Split these lines to make them more readable and fit in the kernel
> > coding guidelines.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > Cc: Linus Walleij <linus.walleij at linaro.org>
> > ---
> >  drivers/pinctrl/pinctrl-sunxi.c | 20 ++++++++++++++++----
> >  1 file changed, 16 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
> > index 5985e60..246310b 100644
> > --- a/drivers/pinctrl/pinctrl-sunxi.c
> > +++ b/drivers/pinctrl/pinctrl-sunxi.c
> > @@ -628,10 +628,22 @@ static void sunxi_pinctrl_irq_handler(unsigned irq, struct irq_desc *desc)
> >  }
> >  
> >  static struct of_device_id sunxi_pinctrl_match[] = {
> > -	{ .compatible = "allwinner,sun4i-a10-pinctrl", .data = (void *)&sun4i_a10_pinctrl_data },
> > -	{ .compatible = "allwinner,sun5i-a10s-pinctrl", .data = (void *)&sun5i_a10s_pinctrl_data },
> > -	{ .compatible = "allwinner,sun5i-a13-pinctrl", .data = (void *)&sun5i_a13_pinctrl_data },
> > -	{ .compatible = "allwinner,sun6i-a31-pinctrl", .data = (void *)&sun6i_a31_pinctrl_data },
> > +	{
> > +		.compatible = "allwinner,sun4i-a10-pinctrl",
> > +		.data = (void *)&sun4i_a10_pinctrl_data,
> > +	},
> 
> I'm not sure this is actually an improvement, the original reads quite
> naturally even if it is a little long. What about a #define such that
> you can write:
>          COMPAT("allwinner,sun4i-a10-pinctrl", sun4i_a10_pinctrl_data),
> and thereby stay within 80-chars?
> 
> If you wanted to go overboard you could code the macro such that:
>         SUNXI_COMPAT(sun4i,a10),
> expanded to what you want, that's pretty obfuscated though.

To be honest, I'm not convinced by any of the constructs seen above. The
one we had is too long, the 4-lines one is not that great either, and
the macro only obfuscates things away.

You know what, I'll drop this patch.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130730/5afa76e1/attachment.sig>

From broonie at kernel.org  Tue Jul 30 16:45:11 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 21:45:11 +0100
Subject: [PATCH v6 2/8] ASoC: atmel: machine driver for at91sam9x5-wm8731
 boards
In-Reply-To: <51F7FBA8.6080400@wwwdotorg.org>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
 <1375180329-4860-3-git-send-email-richard.genoud@gmail.com>
 <51F7FBA8.6080400@wwwdotorg.org>
Message-ID: <20130730204511.GX9858@sirena.org.uk>

On Tue, Jul 30, 2013 at 11:45:12AM -0600, Stephen Warren wrote:
> On 07/30/2013 04:32 AM, Richard Genoud wrote:

> > +wm8731 pins:
> > +cf Documentation/devicetree/bindings/sound/wm8731.txt

> In the Tegra bindings, I deliberately put the list of CODEC pins into
> the audio complex binding rather than the CODEC binding. That's because

You really shouldn't do this, it's not accomplishing much.

> I'm not sure that in the long-term we want to use strings to identify
> the CODEC pins, rather than using integers. By putting the list orf
> CODEC pins in the audio complex binding rather than the CODEC binding, I
> didn't lumber the CODEC binding with a list of strings that it had to
> support forever.

How would you create the numbers - you can't use the pin numbers since
BGA type packages have alphanumeric ball identifiers?  Even with
numerical pin numbering ou'd need to specify some defines for this not
to be totally awful at which point you may as well have the strings
documented since you'd end up writing a table in the binding document
that's basically a mapping of pin names to numbers,

> One reason that strings are problematic is because they can't be mixed
> with integers/phandles in the same property, so if we ever end up with
> more generic audio bindings where the routing table is expressed more like:

> audio-routes = <&component_a $a_pin &component_b $b_pin>;

> ... in order to allow completely arbitrary and fully name-spaced routing
> specification[1], then $a_pin and $b_pin need to be integers not strings.

The above is going to be legibility challenged without defines at which
point the strings end up appearing in the binding document anyway.

Besides, you're stuck with the names you picked anyway so you may as
well put them in the CODEC driver binding document so that anyone else
using the same CODEC can reuse that bit of work.

> [1] and perhaps we can get rid of properties like
> audio-codec/ssc-controller, and automatically deduce which components
> are needed simply by finding all phandles in the audio-routes property.

> Perhaps the solution here is to allow mixing phandles/integers/strings
> in one property, but that's potentially quite a large change to the DTB
> format; we'd need to introduce type fields into the property data, and
> other data format changes.

I really do think this is a DT failure which ought to be addressed
there; people are working around this with things like parallel arrays
with names and phandles which aren't awesome once the arrays get to be
any size.

One option that seems sensible is to introduce syntactic sugar which
will do the parallel arrays trick automatically - the actual DT that
gets output could still be two arrays with indexes that match up (so no
impact on parsers) but the DT author would be able to write an array of
(phandle, string) tuples or something instead of having to line up two
arrays.
-------------- 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/20130730/9ad5b386/attachment-0001.sig>

From maxime.ripard at free-electrons.com  Tue Jul 30 16:49:30 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 22:49:30 +0200
Subject: [PATCHv2 01/10] irqchip: GIC: Add Cortex-A7 compatible string
In-Reply-To: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375217379-15126-2-git-send-email-maxime.ripard@free-electrons.com>

The GIC can also be found on Cortex-A7 based SoCs. Register a new
compatible string for those cases.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Cc: Thomas Gleixner <tglx at linutronix.de>
---
 drivers/irqchip/irq-gic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 19ceaa6..5b5fe23 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -854,6 +854,7 @@ int __init gic_of_init(struct device_node *node, struct device_node *parent)
 }
 IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
 IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
+IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init);
 IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init);
 IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
 
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 16:49:32 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 22:49:32 +0200
Subject: [PATCHv2 03/10] ARM: sunxi: Add the Allwinner A31 compatible to the
 machine definition
In-Reply-To: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375217379-15126-4-git-send-email-maxime.ripard@free-electrons.com>

The Allwinner A31 is a quad-Cortex-A7 based SoC, which shares a lot of
IPs with the previous SoCs from Allwinner, like the PIO, I2C, UARTs,
timers, watchdog IPs, but also differs by dropping the WEMAC ethernet
controller and most notably dropping the in-house IRQ controller in
favor of a ARM GIC one.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/mach-sunxi/Kconfig | 2 ++
 arch/arm/mach-sunxi/sunxi.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 5b045e3..3ab2f65 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -10,3 +10,5 @@ config ARCH_SUNXI
 	select SPARSE_IRQ
 	select SUN4I_TIMER
 	select PINCTRL_SUNXI
+	select ARM_GIC
+	select HAVE_SMP
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 38a3c55..11326d9 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -96,6 +96,7 @@ static const char * const sunxi_board_dt_compat[] = {
 	"allwinner,sun4i-a10",
 	"allwinner,sun5i-a10s",
 	"allwinner,sun5i-a13",
+	"allwinner,sun6i-a31",
 	NULL,
 };
 
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 16:49:29 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 22:49:29 +0200
Subject: [PATCHv2 00/10] ARM: sunxi: Add support for the Allwinner A31 SoC
Message-ID: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>

Hi everyone,

This patchset add support in Linux for the Allwinner A31 SoC. This SoC is the
current high-end Allwinner SoC, and is powered by 4 Cortex-A7.

SMP support is not there yet, but should come eventually, so does the clock
support.

As usual, since we don't have any storage device driver yet, it only boots from
an initramfs.

Finally, something worth mentionning is that with the current bootloader,
you'll encounter 2 ~6s hangs during the boot. This is because the SMP bit of
the Cortex-A7 doesn't appear to be set, leading to the CPU caches being
disabled. This can partially be addressed by selecting CONFIG_SMP, that will
remove the second hang, because the SMP bit is set after kernel decompression.

Obviously, this won't remove the first hang that happens during decompression,
but it's better than nothing. A proper fix would be to fix the bootloader.

Thanks,
Maxime

Changes from v1:
  - Used the GIC bindings for the virtualization extensions available in the Cortex-A7
  - Cosmetic changes on the interrupts definitions
  - Removed the reg property in the soc bus
  - Fixed a bug squashing issue when adding the A31 dtsi
  - Added the A31 watchdog compatible to the binding documentation
  - Used the BIT macro in the restart code
  - Fix a few errors/typos in the commit logs

Emilio L?pez (1):
  clk: sunxi: fix initialization of basic clocks

Maxime Ripard (9):
  irqchip: GIC: Add Cortex-A7 compatible string
  ARM: sunxi: Add the Allwinner A31 compatible to the machine definition
  ARM: sun6i: Add restart code for the A31
  ARM: sunxi: Add Allwinner A31 DTSI
  ARM: sun6i: Add WITS Colombus A31 evaluation kit support
  pinctrl: sunxi: Add Allwinner A31 pins set
  ARM: sunxi: dt: Add PIO controller to A31 DTSI
  ARM: sun6i: Add UART0 muxing options
  ARM: sun6i: colombus: Add uart0 muxing

 .../devicetree/bindings/watchdog/sun4i-wdt.txt     |  13 -
 .../devicetree/bindings/watchdog/sunxi-wdt.txt     |  14 +
 arch/arm/boot/dts/Makefile                         |   3 +-
 arch/arm/boot/dts/sun6i-a31-colombus.dts           |  32 +
 arch/arm/boot/dts/sun6i-a31.dtsi                   | 175 +++++
 arch/arm/mach-sunxi/Kconfig                        |   2 +
 arch/arm/mach-sunxi/sunxi.c                        |  44 +-
 drivers/clk/sunxi/clk-sunxi.c                      |  11 +-
 drivers/irqchip/irq-gic.c                          |   1 +
 drivers/pinctrl/pinctrl-sunxi-pins.h               | 820 +++++++++++++++++++++
 drivers/pinctrl/pinctrl-sunxi.c                    |   1 +
 11 files changed, 1091 insertions(+), 25 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
 create mode 100644 arch/arm/boot/dts/sun6i-a31-colombus.dts
 create mode 100644 arch/arm/boot/dts/sun6i-a31.dtsi

-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 16:49:31 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 22:49:31 +0200
Subject: [PATCHv2 02/10] clk: sunxi: fix initialization of basic clocks
In-Reply-To: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375217379-15126-3-git-send-email-maxime.ripard@free-electrons.com>

From: Emilio L?pez <emilio at elopez.com.ar>

With the recent move towards CLK_OF_DECLARE(...), the driver stopped
initializing osc32k, which is compatible "fixed-clock". This is because
we never called of_clk_init(NULL). Fix this by moving the only other
simple clock (osc24M) to use CLK_OF_DECLARE(...) and call of_clk_init(NULL)
to initialize both of them.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Cc: Mike Turquette <mturquette at linaro.org>
---
 drivers/clk/sunxi/clk-sunxi.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 412912b..fe1528e 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -409,12 +409,7 @@ static void __init sunxi_gates_clk_setup(struct device_node *node,
 
 	of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
 }
-
-/* Matches for of_clk_init */
-static const __initconst struct of_device_id clk_match[] = {
-	{.compatible = "allwinner,sun4i-osc-clk", .data = sunxi_osc_clk_setup,},
-	{}
-};
+CLK_OF_DECLARE(sunxi_osc, "allwinner,sun4i-osc-clk", sunxi_osc_clk_setup);
 
 /* Matches for factors clocks */
 static const __initconst struct of_device_id clk_factors_match[] = {
@@ -467,8 +462,8 @@ static void __init of_sunxi_table_clock_setup(const struct of_device_id *clk_mat
 
 void __init sunxi_init_clocks(void)
 {
-	/* Register all the simple sunxi clocks on DT */
-	of_clk_init(clk_match);
+	/* Register all the simple and basic clocks on DT */
+	of_clk_init(NULL);
 
 	/* Register factor clocks */
 	of_sunxi_table_clock_setup(clk_factors_match, sunxi_factors_clk_setup);
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 16:49:33 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 22:49:33 +0200
Subject: [PATCHv2 04/10] ARM: sun6i: Add restart code for the A31
In-Reply-To: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375217379-15126-5-git-send-email-maxime.ripard@free-electrons.com>

The Allwinner A31 has a different watchdog, with a slightly different
register layout, that requires a different restart code.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 .../devicetree/bindings/watchdog/sun4i-wdt.txt     | 13 -------
 .../devicetree/bindings/watchdog/sunxi-wdt.txt     | 14 +++++++
 arch/arm/mach-sunxi/sunxi.c                        | 43 ++++++++++++++++++++--
 3 files changed, 54 insertions(+), 16 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt

diff --git a/Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt b/Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt
deleted file mode 100644
index ecd650a..0000000
--- a/Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-Allwinner sun4i Watchdog timer
-
-Required properties:
-
-- compatible : should be "allwinner,sun4i-wdt"
-- reg : Specifies base physical address and size of the registers.
-
-Example:
-
-wdt: watchdog at 01c20c90 {
-	compatible = "allwinner,sun4i-wdt";
-	reg = <0x01c20c90 0x10>;
-};
diff --git a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
new file mode 100644
index 0000000..e39cb26
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
@@ -0,0 +1,14 @@
+Allwinner SoCs Watchdog timer
+
+Required properties:
+
+- compatible : should be "allwinner,<soc-family>-wdt", the currently supported
+  SoC families being sun4i and sun6i
+- reg : Specifies base physical address and size of the registers.
+
+Example:
+
+wdt: watchdog at 01c20c90 {
+	compatible = "allwinner,sun4i-wdt";
+	reg = <0x01c20c90 0x10>;
+};
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 11326d9..19bcc96 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -27,10 +27,19 @@
 #include <asm/system_misc.h>
 
 #define SUN4I_WATCHDOG_CTRL_REG		0x00
-#define SUN4I_WATCHDOG_CTRL_RESTART		(1 << 0)
+#define SUN4I_WATCHDOG_CTRL_RESTART		BIT(0)
 #define SUN4I_WATCHDOG_MODE_REG		0x04
-#define SUN4I_WATCHDOG_MODE_ENABLE		(1 << 0)
-#define SUN4I_WATCHDOG_MODE_RESET_ENABLE	(1 << 1)
+#define SUN4I_WATCHDOG_MODE_ENABLE		BIT(0)
+#define SUN4I_WATCHDOG_MODE_RESET_ENABLE	BIT(1)
+
+#define SUN6I_WATCHDOG1_IRQ_REG		0x00
+#define SUN6I_WATCHDOG1_CTRL_REG	0x10
+#define SUN6I_WATCHDOG1_CTRL_RESTART		BIT(0)
+#define SUN6I_WATCHDOG1_CONFIG_REG	0x14
+#define SUN6I_WATCHDOG1_CONFIG_RESTART		BIT(0)
+#define SUN6I_WATCHDOG1_CONFIG_IRQ		BIT(1)
+#define SUN6I_WATCHDOG1_MODE_REG	0x18
+#define SUN6I_WATCHDOG1_MODE_ENABLE		BIT(0)
 
 static void __iomem *wdt_base;
 
@@ -56,8 +65,36 @@ static void sun4i_restart(enum reboot_mode mode, const char *cmd)
 	}
 }
 
+static void sun6i_restart(char mode, const char *cmd)
+{
+	if (!wdt_base)
+		return;
+
+	/* Disable interrupts */
+	writel(0, wdt_base + SUN6I_WATCHDOG1_IRQ_REG);
+
+	/* We want to disable the IRQ and just reset the whole system */
+	writel(SUN6I_WATCHDOG1_CONFIG_RESTART,
+		wdt_base + SUN6I_WATCHDOG1_CONFIG_REG);
+
+	/* Enable timer. The default and lowest interval value is 0.5s */
+	writel(SUN6I_WATCHDOG1_MODE_ENABLE,
+		wdt_base + SUN6I_WATCHDOG1_MODE_REG);
+
+	/* Restart the watchdog. */
+	writel(SUN6I_WATCHDOG1_CTRL_RESTART,
+		wdt_base + SUN6I_WATCHDOG1_CTRL_REG);
+
+	while (1) {
+		mdelay(5);
+		writel(SUN6I_WATCHDOG1_MODE_ENABLE,
+			wdt_base + SUN6I_WATCHDOG1_MODE_REG);
+	}
+}
+
 static struct of_device_id sunxi_restart_ids[] = {
 	{ .compatible = "allwinner,sun4i-wdt", .data = sun4i_restart },
+	{ .compatible = "allwinner,sun6i-wdt", .data = sun6i_restart },
 	{ /*sentinel*/ }
 };
 
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 16:49:39 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 22:49:39 +0200
Subject: [PATCHv2 10/10] ARM: sun6i: colombus: Add uart0 muxing
In-Reply-To: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375217379-15126-11-git-send-email-maxime.ripard@free-electrons.com>

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun6i-a31-colombus.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31-colombus.dts b/arch/arm/boot/dts/sun6i-a31-colombus.dts
index 0128754..1f2c0f0 100644
--- a/arch/arm/boot/dts/sun6i-a31-colombus.dts
+++ b/arch/arm/boot/dts/sun6i-a31-colombus.dts
@@ -24,6 +24,8 @@
 
 	soc at 01c20000 {
 		uart0: serial at 01c28000 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&uart0_pins_a>;
 			status = "okay";
 		};
 	};
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 16:49:38 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 22:49:38 +0200
Subject: [PATCHv2 09/10] ARM: sun6i: Add UART0 muxing options
In-Reply-To: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375217379-15126-10-git-send-email-maxime.ripard@free-electrons.com>

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 2d10eb4..e6ccddf 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -76,6 +76,13 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 			#gpio-cells = <3>;
+
+			uart0_pins_a: uart0 at 0 {
+				allwinner,pins = "PH20", "PH21";
+				allwinner,function = "uart0";
+				allwinner,drive = <0>;
+				allwinner,pull = <0>;
+			};
 		};
 
 		timer at 01c20c00 {
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 16:49:37 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 22:49:37 +0200
Subject: [PATCHv2 08/10] ARM: sunxi: dt: Add PIO controller to A31 DTSI
In-Reply-To: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375217379-15126-9-git-send-email-maxime.ripard@free-electrons.com>

The A31 has a different set of pins than the one found on the A10 and
A13. Now that we have support for the A31 pin set in the pinctrl driver,
we can enable it in the DTSI with its own compatible.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 407e7b4..2d10eb4 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -66,6 +66,18 @@
 		#size-cells = <1>;
 		ranges;
 
+		pio: pinctrl at 01c20800 {
+			compatible = "allwinner,sun6i-a31-pinctrl";
+			reg = <0x01c20800 0x400>;
+			interrupts = <0 11 1>, <0 15 1>, <0 16 1>, <0 17 1>;
+			clocks = <&osc>;
+			gpio-controller;
+			interrupt-controller;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			#gpio-cells = <3>;
+		};
+
 		timer at 01c20c00 {
 			compatible = "allwinner,sun4i-timer";
 			reg = <0x01c20c00 0xa0>;
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 16:49:35 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 22:49:35 +0200
Subject: [PATCHv2 06/10] ARM: sun6i: Add WITS Colombus A31 evaluation kit
 support
In-Reply-To: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375217379-15126-7-git-send-email-maxime.ripard@free-electrons.com>

This platform from WITS is the evaluation board for the Allwinner A31.
It features a quad-Cortex A7, 2048MB of RAM, NAND, USB, MMC, several
UART, HDMI, a 2048 x 1536 10" screen, powered by a PowerVR, etc.

Of course, most of these peripherals aren't supported yet, but support
for those will come eventually.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/Makefile               |  3 ++-
 arch/arm/boot/dts/sun6i-a31-colombus.dts | 30 ++++++++++++++++++++++++++++++
 2 files changed, 32 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun6i-a31-colombus.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..1482533 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -210,7 +210,8 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
 	sun4i-a10-mini-xplus.dtb \
 	sun4i-a10-hackberry.dtb \
 	sun5i-a10s-olinuxino-micro.dtb \
-	sun5i-a13-olinuxino.dtb
+	sun5i-a13-olinuxino.dtb \
+	sun6i-a31-colombus.dtb
 dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
 	tegra20-iris-512.dtb \
 	tegra20-medcom-wide.dtb \
diff --git a/arch/arm/boot/dts/sun6i-a31-colombus.dts b/arch/arm/boot/dts/sun6i-a31-colombus.dts
new file mode 100644
index 0000000..0128754
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31-colombus.dts
@@ -0,0 +1,30 @@
+/*
+ * Copyright 2013 Maxime Ripard
+ *
+ * Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "sun6i-a31.dtsi"
+
+/ {
+	model = "WITS A31 Colombus Evaluation Board";
+	compatible = "wits,colombus", "allwinner,sun6i-a31";
+
+	chosen {
+		bootargs = "earlyprintk console=ttyS0,115200";
+	};
+
+	soc at 01c20000 {
+		uart0: serial at 01c28000 {
+			status = "okay";
+		};
+	};
+};
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 16:49:34 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 22:49:34 +0200
Subject: [PATCHv2 05/10] ARM: sunxi: Add Allwinner A31 DTSI
In-Reply-To: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375217379-15126-6-git-send-email-maxime.ripard@free-electrons.com>

The Allwinner A31 SoC is a multimedia SoC powered by 4 Cortex-A7 and a
PowerVR GPU.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 156 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 156 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun6i-a31.dtsi

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
new file mode 100644
index 0000000..407e7b4
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -0,0 +1,156 @@
+/*
+ * Copyright 2013 Maxime Ripard
+ *
+ * Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	interrupt-parent = <&gic>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <0>;
+		};
+
+		cpu at 1 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <1>;
+		};
+
+		cpu at 2 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <2>;
+		};
+
+		cpu at 3 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <3>;
+		};
+	};
+
+	memory {
+		reg = <0x40000000 0x80000000>;
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		osc: oscillator {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <24000000>;
+		};
+	};
+
+	soc at 01c20000 {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		timer at 01c20c00 {
+			compatible = "allwinner,sun4i-timer";
+			reg = <0x01c20c00 0xa0>;
+			interrupts = <0 18 1>,
+				     <0 19 1>,
+				     <0 20 1>,
+				     <0 21 1>,
+				     <0 22 1>;
+			clocks = <&osc>;
+		};
+
+		wdt1: watchdog at 01c20ca0 {
+			compatible = "allwinner,sun6i-wdt";
+			reg = <0x01c20ca0 0x20>;
+		};
+
+		uart0: serial at 01c28000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28000 0x400>;
+			interrupts = <0 0 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc>;
+			status = "disabled";
+		};
+
+		uart1: serial at 01c28400 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28400 0x400>;
+			interrupts = <0 1 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc>;
+			status = "disabled";
+		};
+
+		uart2: serial at 01c28800 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28800 0x400>;
+			interrupts = <0 2 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc>;
+			status = "disabled";
+		};
+
+		uart3: serial at 01c28c00 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28c00 0x400>;
+			interrupts = <0 3 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc>;
+			status = "disabled";
+		};
+
+		uart4: serial at 01c29000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c29000 0x400>;
+			interrupts = <0 4 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc>;
+			status = "disabled";
+		};
+
+		uart5: serial at 01c29400 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c29400 0x400>;
+			interrupts = <0 5 1>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&osc>;
+			status = "disabled";
+		};
+
+		gic: interrupt-controller at 01c81000 {
+			compatible = "arm,cortex-a7-gic";
+			reg = <0x01c81000 0x1000>,
+			      <0x01c82000 0x1000>,
+			      <0x01c84000 0x2000>,
+			      <0x01c86000 0x2000>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+			interrupts = <1 9 0xf04>;
+		};
+	};
+};
-- 
1.8.3.4



From maxime.ripard at free-electrons.com  Tue Jul 30 16:49:36 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 30 Jul 2013 22:49:36 +0200
Subject: [PATCHv2 07/10] pinctrl: sunxi: Add Allwinner A31 pins set
In-Reply-To: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1375217379-15126-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1375217379-15126-8-git-send-email-maxime.ripard@free-electrons.com>

The Allwinner A31 SoC uses the same IP than the one found in the
A10/A13, with only different pins. Add the pins and the associated
functions found in the A31.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/pinctrl-sunxi-pins.h | 820 +++++++++++++++++++++++++++++++++++
 drivers/pinctrl/pinctrl-sunxi.c      |   1 +
 2 files changed, 821 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-sunxi-pins.h b/drivers/pinctrl/pinctrl-sunxi-pins.h
index 2eeae0c..eb0273d 100644
--- a/drivers/pinctrl/pinctrl-sunxi-pins.h
+++ b/drivers/pinctrl/pinctrl-sunxi-pins.h
@@ -2005,6 +2005,821 @@ static const struct sunxi_desc_pin sun5i_a13_pins[] = {
 		  SUNXI_FUNCTION_IRQ(0x6, 12)),		/* EINT12 */
 };
 
+static const struct sunxi_desc_pin sun6i_a31_pins[] = {
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* TXD0 */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D0 */
+		  SUNXI_FUNCTION(0x4, "uart1")),	/* DTR */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* TXD1 */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D1 */
+		  SUNXI_FUNCTION(0x4, "uart1")),	/* DSR */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* TXD2 */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D2 */
+		  SUNXI_FUNCTION(0x4, "uart1")),	/* DCD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* TXD3 */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D3 */
+		  SUNXI_FUNCTION(0x4, "uart1")),	/* RING */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* TXD4 */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D4 */
+		  SUNXI_FUNCTION(0x4, "uart1")),	/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* TXD5 */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D5 */
+		  SUNXI_FUNCTION(0x4, "uart1")),	/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* TXD6 */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D6 */
+		  SUNXI_FUNCTION(0x4, "uart1")),	/* RTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* TXD7 */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D7 */
+		  SUNXI_FUNCTION(0x4, "uart1")),	/* CTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA8,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* TXCLK */
+		  SUNXI_FUNCTION(0x3, "lcd1")),		/* D8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA9,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* TXEN */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D9 */
+		  SUNXI_FUNCTION(0x4, "mmc3"),		/* CMD */
+		  SUNXI_FUNCTION(0x5, "mmc2")),		/* CMD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA10,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* GTXCLK */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D10 */
+		  SUNXI_FUNCTION(0x4, "mmc3"),		/* CLK */
+		  SUNXI_FUNCTION(0x5, "mmc2")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA11,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* RXD0 */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D11 */
+		  SUNXI_FUNCTION(0x4, "mmc3"),		/* D0 */
+		  SUNXI_FUNCTION(0x5, "mmc2")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA12,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* RXD1 */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D12 */
+		  SUNXI_FUNCTION(0x4, "mmc3"),		/* D1 */
+		  SUNXI_FUNCTION(0x5, "mmc2")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA13,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* RXD2 */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D13 */
+		  SUNXI_FUNCTION(0x4, "mmc3"),		/* D2 */
+		  SUNXI_FUNCTION(0x5, "mmc2")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA14,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* RXD3 */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D14 */
+		  SUNXI_FUNCTION(0x4, "mmc3"),		/* D3 */
+		  SUNXI_FUNCTION(0x5, "mmc2")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA15,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* RXD4 */
+		  SUNXI_FUNCTION(0x3, "lcd1")),		/* D15 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA16,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* RXD5 */
+		  SUNXI_FUNCTION(0x3, "lcd1")),		/* D16 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA17,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* RXD6 */
+		  SUNXI_FUNCTION(0x3, "lcd1")),		/* D17 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA18,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* RXD7 */
+		  SUNXI_FUNCTION(0x3, "lcd1")),		/* D18 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA19,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* RXDV */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D19 */
+		  SUNXI_FUNCTION(0x4, "pwm3")),		/* Positive */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA20,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* RXCLK */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D20 */
+		  SUNXI_FUNCTION(0x4, "pwm3")),		/* Negative */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA21,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* TXERR */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D21 */
+		  SUNXI_FUNCTION(0x4, "spi3")),		/* CS0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA22,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* RXERR */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D22 */
+		  SUNXI_FUNCTION(0x4, "spi3")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA23,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* COL */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* D23 */
+		  SUNXI_FUNCTION(0x4, "spi3")),		/* MOSI */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA24,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* CRS */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* CLK */
+		  SUNXI_FUNCTION(0x4, "spi3")),		/* MISO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA25,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* CLKIN */
+		  SUNXI_FUNCTION(0x3, "lcd1"),		/* DE */
+		  SUNXI_FUNCTION(0x4, "spi3")),		/* CS1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA26,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* MDC */
+		  SUNXI_FUNCTION(0x3, "lcd1")),		/* HSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PA27,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "gmac"),		/* MDIO */
+		  SUNXI_FUNCTION(0x3, "lcd1")),		/* VSYNC */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0"),		/* MCLK */
+		  SUNXI_FUNCTION(0x3, "uart3"),		/* CTS */
+		  SUNXI_FUNCTION(0x4, "csi")),		/* MCLK1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0")),		/* BCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0")),		/* LRCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0")),		/* DO0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0"),		/* DO1 */
+		  SUNXI_FUNCTION(0x3, "uart3")),	/* RTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0"),		/* DO2 */
+		  SUNXI_FUNCTION(0x3, "uart3"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "i2c3")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2s0"),		/* DO3 */
+		  SUNXI_FUNCTION(0x3, "uart3"),		/* RX */
+		  SUNXI_FUNCTION(0x4, "i2c3")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PB7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x3, "i2s0")),		/* DI */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* WE */
+		  SUNXI_FUNCTION(0x3, "spi0")),		/* MOSI */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* ALE */
+		  SUNXI_FUNCTION(0x3, "spi0")),		/* MISO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* CLE */
+		  SUNXI_FUNCTION(0x3, "spi0")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* CE1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* CE0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* RE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* RB0 */
+		  SUNXI_FUNCTION(0x3, "mmc2"),		/* CMD */
+		  SUNXI_FUNCTION(0x4, "mmc3")),		/* CMD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* RB1 */
+		  SUNXI_FUNCTION(0x3, "mmc2"),		/* CLK */
+		  SUNXI_FUNCTION(0x4, "mmc3")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC8,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ0 */
+		  SUNXI_FUNCTION(0x3, "mmc2"),		/* D0 */
+		  SUNXI_FUNCTION(0x4, "mmc3")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC9,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ1 */
+		  SUNXI_FUNCTION(0x3, "mmc2"),		/* D1 */
+		  SUNXI_FUNCTION(0x4, "mmc3")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC10,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ2 */
+		  SUNXI_FUNCTION(0x3, "mmc2"),		/* D2 */
+		  SUNXI_FUNCTION(0x4, "mmc3")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC11,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ3 */
+		  SUNXI_FUNCTION(0x3, "mmc2"),		/* D3 */
+		  SUNXI_FUNCTION(0x4, "mmc3")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC12,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ4 */
+		  SUNXI_FUNCTION(0x3, "mmc2"),		/* D4 */
+		  SUNXI_FUNCTION(0x4, "mmc3")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC13,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ5 */
+		  SUNXI_FUNCTION(0x3, "mmc2"),		/* D5 */
+		  SUNXI_FUNCTION(0x4, "mmc3")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC14,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ6 */
+		  SUNXI_FUNCTION(0x3, "mmc2"),		/* D6 */
+		  SUNXI_FUNCTION(0x4, "mmc3")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC15,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ7 */
+		  SUNXI_FUNCTION(0x3, "mmc2"),		/* D7 */
+		  SUNXI_FUNCTION(0x4, "mmc3")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC16,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ8 */
+		  SUNXI_FUNCTION(0x3, "nand1")),	/* DQ0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC17,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ9 */
+		  SUNXI_FUNCTION(0x3, "nand1")),	/* DQ1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC18,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ10 */
+		  SUNXI_FUNCTION(0x3, "nand1")),	/* DQ2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC19,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ11 */
+		  SUNXI_FUNCTION(0x3, "nand1")),	/* DQ3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC20,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ12 */
+		  SUNXI_FUNCTION(0x3, "nand1")),	/* DQ4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC21,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ13 */
+		  SUNXI_FUNCTION(0x3, "nand1")),	/* DQ5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC22,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ14 */
+		  SUNXI_FUNCTION(0x3, "nand1")),	/* DQ6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC23,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQ15 */
+		  SUNXI_FUNCTION(0x3, "nand1")),	/* DQ7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC24,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* DQS */
+		  SUNXI_FUNCTION(0x3, "mmc2"),		/* RST */
+		  SUNXI_FUNCTION(0x4, "mmc3")),		/* RST */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC25,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* CE2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC26,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* CE3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PC27,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x3, "spi0")),		/* CS0 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D0 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VP0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D1 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VN0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D2 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VP1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D3 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VN1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D4 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VP2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D5 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VN2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D6 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VPC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D7 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD8,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D8 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VP3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD9,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D9 */
+		  SUNXI_FUNCTION(0x3, "lvds0")),	/* VN3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD10,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D10 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VP0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD11,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D11 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VN0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD12,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D12 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VP1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD13,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D13 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VN1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD14,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D14 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VP2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD15,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D15 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VN2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD16,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D16 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VPC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD17,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D17 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD18,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D18 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VP3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD19,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D19 */
+		  SUNXI_FUNCTION(0x3, "lvds1")),	/* VN3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD20,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0")),		/* D20 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD21,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0")),		/* D21 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD22,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0")),		/* D22 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD23,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0")),		/* D23 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD24,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD25,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0")),		/* DE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD26,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0")),		/* HSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PD27,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0")),		/* VSYNC */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* PCLK */
+		  SUNXI_FUNCTION(0x3, "ts")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* MCLK */
+		  SUNXI_FUNCTION(0x3, "ts")),		/* ERR */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* HSYNC */
+		  SUNXI_FUNCTION(0x3, "ts")),		/* SYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* VSYNC */
+		  SUNXI_FUNCTION(0x3, "ts")),		/* DVLD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* D0 */
+		  SUNXI_FUNCTION(0x3, "uart5")),	/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* D1 */
+		  SUNXI_FUNCTION(0x3, "uart5")),	/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* D2 */
+		  SUNXI_FUNCTION(0x3, "uart5")),	/* RTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* D3 */
+		  SUNXI_FUNCTION(0x3, "uart5")),	/* CTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE8,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* D4 */
+		  SUNXI_FUNCTION(0x3, "ts")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE9,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* D5 */
+		  SUNXI_FUNCTION(0x3, "ts")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE10,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* D6 */
+		  SUNXI_FUNCTION(0x3, "ts")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE11,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* D7 */
+		  SUNXI_FUNCTION(0x3, "ts")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE12,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* D8 */
+		  SUNXI_FUNCTION(0x3, "ts")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE13,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* D9 */
+		  SUNXI_FUNCTION(0x3, "ts")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE14,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* D10 */
+		  SUNXI_FUNCTION(0x3, "ts")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE15,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi"),		/* D11 */
+		  SUNXI_FUNCTION(0x3, "ts")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PE16,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi")),		/* MIPI CSI MCLK */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D1 */
+		  SUNXI_FUNCTION(0x4, "jtag")),		/* MS1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D0 */
+		  SUNXI_FUNCTION(0x4, "jtag")),		/* DI1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* CLK */
+		  SUNXI_FUNCTION(0x4, "uart0")),	/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* CMD */
+		  SUNXI_FUNCTION(0x4, "jtag")),		/* DO1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D3 */
+		  SUNXI_FUNCTION(0x4, "uart0")),	/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PF5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D2 */
+		  SUNXI_FUNCTION(0x4, "jtag")),		/* CK1 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1")),		/* CMD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2")),	/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2")),	/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG8,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2")),	/* RTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG9,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2")),	/* CTS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG10,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c3"),		/* SCK */
+		  SUNXI_FUNCTION(0x3, "usb")),		/* DP3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG11,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c3"),		/* SDA */
+		  SUNXI_FUNCTION(0x3, "usb")),		/* DM3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG12,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS1 */
+		  SUNXI_FUNCTION(0x3, "i2s1")),		/* MCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG13,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS0 */
+		  SUNXI_FUNCTION(0x3, "i2s1")),		/* BCLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG14,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi1"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "i2s1")),		/* LRCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG15,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi1"),		/* MOSI */
+		  SUNXI_FUNCTION(0x3, "i2s1")),		/* DIN */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG16,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi1"),		/* MISO */
+		  SUNXI_FUNCTION(0x3, "i2s1")),		/* DOUT */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG17,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart4")),	/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PG18,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart4")),	/* RX */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH0,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand1")),	/* WE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH1,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand1")),	/* ALE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH2,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand1")),	/* CLE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH3,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand1")),	/* CE1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH4,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand1")),	/* CE0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH5,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand1")),	/* RE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH6,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand1")),	/* RB0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH7,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand1")),	/* RB1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH8,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand1")),	/* DQS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH9,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi2"),		/* CS0 */
+		  SUNXI_FUNCTION(0x3, "jtag"),		/* MS0 */
+		  SUNXI_FUNCTION(0x4, "pwm1")),		/* Positive */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH10,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi2"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "jtag"),		/* CK0 */
+		  SUNXI_FUNCTION(0x4, "pwm1")),		/* Negative */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH11,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi2"),		/* MOSI */
+		  SUNXI_FUNCTION(0x3, "jtag"),		/* DO0 */
+		  SUNXI_FUNCTION(0x4, "pwm2")),		/* Positive */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH12,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spi2"),		/* MISO */
+		  SUNXI_FUNCTION(0x3, "jtag"),		/* DI0 */
+		  SUNXI_FUNCTION(0x4, "pwm2")),		/* Negative */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH13,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "pwm0")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH14,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c0")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH15,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c0")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH16,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c1")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH17,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c1")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH18,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c2")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH19,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c2")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH20,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart0")),	/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH21,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart0")),	/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH22,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH23,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH24,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH25,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH26,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH27,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH28,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH29,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand1")),	/* CE2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN_PH30,
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand1")),	/* CE3 */
+};
+
 static const struct sunxi_pinctrl_desc sun4i_a10_pinctrl_data = {
 	.pins = sun4i_a10_pins,
 	.npins = ARRAY_SIZE(sun4i_a10_pins),
@@ -2020,4 +2835,9 @@ static const struct sunxi_pinctrl_desc sun5i_a13_pinctrl_data = {
 	.npins = ARRAY_SIZE(sun5i_a13_pins),
 };
 
+static const struct sunxi_pinctrl_desc sun6i_a31_pinctrl_data = {
+	.pins = sun6i_a31_pins,
+	.npins = ARRAY_SIZE(sun6i_a31_pins),
+};
+
 #endif /* __PINCTRL_SUNXI_PINS_H */
diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
index c47fd1e..5985e60 100644
--- a/drivers/pinctrl/pinctrl-sunxi.c
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -631,6 +631,7 @@ static struct of_device_id sunxi_pinctrl_match[] = {
 	{ .compatible = "allwinner,sun4i-a10-pinctrl", .data = (void *)&sun4i_a10_pinctrl_data },
 	{ .compatible = "allwinner,sun5i-a10s-pinctrl", .data = (void *)&sun5i_a10s_pinctrl_data },
 	{ .compatible = "allwinner,sun5i-a13-pinctrl", .data = (void *)&sun5i_a13_pinctrl_data },
+	{ .compatible = "allwinner,sun6i-a31-pinctrl", .data = (void *)&sun6i_a31_pinctrl_data },
 	{}
 };
 MODULE_DEVICE_TABLE(of, sunxi_pinctrl_match);
-- 
1.8.3.4



From hauke at hauke-m.de  Tue Jul 30 16:54:04 2013
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Tue, 30 Jul 2013 22:54:04 +0200
Subject: [PATCH v3 1/3] ARM: BCM5301X: initial support for the
 BCM5301X/BCM470X SoCs with ARM CPU
In-Reply-To: <20130730133601.GN11527@mudshark.cambridge.arm.com>
References: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
 <51F28A20.7060105@hauke-m.de>
 <20130726165311.GH17886@mudshark.cambridge.arm.com>
 <201307272149.17108.arnd@arndb.de>
 <20130730133601.GN11527@mudshark.cambridge.arm.com>
Message-ID: <51F827EC.3090104@hauke-m.de>

On 07/30/2013 03:36 PM, Will Deacon wrote:
> On Sat, Jul 27, 2013 at 08:49:16PM +0100, Arnd Bergmann wrote:
>> On Friday 26 July 2013, Will Deacon wrote:
>>>>> At least, we need a pretty good explanation of what exactly is causing
>>>>> these spurious aborts before we start ignoring them unconditionally like
>>>>> this. You're effectively masking an extremely serious error indicator with
>>>>> this change.
>>>>
>>>> This fault occurs once every boot sometime early in the boot process,
>>>> but the actual time this happens varies randomly.
>>>
>>> Well that's interesting in itself. It sounds like we don't know *for sure*
>>> whether the abort is triggered by Linux. Since the abort is imprecise, the
>>> timing will vary.
>>
>> It might be possible to find out the culprit if you just enter an endless loop
>> in the early kernel boot code. If you enter the loop before Linux does something
>> wrong, it won't crash, otherwise it will. After that, you could bisect the
>> boot process by moving the busy loop around.
>>
>> If it even crashes at the point where Linux gets entered, it's a bug in the
>> boot loader.
> 
> Can you give Arnd's suggestion a go please Hauke?

Hi

I just tried that, but it did not crash in the loop. :-(

Now, with 3.11-rc3 it crashed reproducible after Freeing unused kernel
memory, see this:

[    0.859198] Freeing unused kernel memory: 1124K (c0260000 - c0379000)
[    0.866298] Unhandled fault: imprecise external abort (0x1c06) at
0xb6f8b005
[    0.873538] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000007

Do you have some more informations about this type of error?

Hauke


From davidb at codeaurora.org  Tue Jul 30 16:55:32 2013
From: davidb at codeaurora.org (David Brown)
Date: Tue, 30 Jul 2013 13:55:32 -0700
Subject: [PATCH v2 3/9] ARM: msm: Move debug-macro.S to include/debug
In-Reply-To: <1374699274-18388-4-git-send-email-sboyd@codeaurora.org>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
 <1374699274-18388-4-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130730205532.GA18638@codeaurora.org>

On Wed, Jul 24, 2013 at 01:54:28PM -0700, Stephen Boyd wrote:
>One more step to allowing MSM to participate in the
>multi-platform defconfig.

Full patch: https://patchwork.kernel.org/patch/2833034/

>Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>---
> arch/arm/Kconfig.debug                             |  9 +++-
> .../mach/debug-macro.S => include/debug/msm.S}     | 32 ++++++++++-
> arch/arm/mach-msm/include/mach/msm_iomap-8960.h    |  5 --
> arch/arm/mach-msm/include/mach/msm_iomap-8x60.h    |  5 --
> arch/arm/mach-msm/include/mach/msm_iomap.h         | 12 -----
> arch/arm/mach-msm/include/mach/uncompress.h        | 63 ----------------------
> arch/arm/mach-msm/io.c                             | 40 +++++++-------
> 7 files changed, 58 insertions(+), 108 deletions(-)
> rename arch/arm/{mach-msm/include/mach/debug-macro.S => include/debug/msm.S} (61%)
> delete mode 100644 arch/arm/mach-msm/include/mach/uncompress.h

Any comments on this?  This is mostly an MSM change, but I'd like to
get an Ack from someone because of the file moving into
arch/arm/include/debug.

Thanks,
David

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From broonie at kernel.org  Tue Jul 30 16:57:16 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 21:57:16 +0100
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
Message-ID: <20130730205716.GZ9858@sirena.org.uk>

On Tue, Jul 30, 2013 at 01:29:56PM -0400, jonsmirl at gmail.com wrote:
> On Tue, Jul 30, 2013 at 1:19 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> > On 07/30/2013 07:14 AM, jonsmirl at gmail.com wrote:

> > > Is something similar to this possible in device tree syntax?
> > > dmas =  <"tx" &pdma0 7>,  <"rx"  &pdma0 6>;

> > I /think/ you can physically write that in *.dts, or something very
> > similar; with the strings outside the <>:

> > dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;

> Can we turn the strings into string phandles? Then they'd be fixed sized.

> That might provide a way to internationalize the strings too.

I don't know how viable or sane this actually is but one suggestion I
just made elsewhere which might help is to fix this at the dtc level by
having syntatic sugar which will do the parallel arrays trick that
people are currently using to write things out.  The user writes one
array with multiple types of data in it and the actual output is two or
more matched arrays each with a single type of data.

It would help legibility and wouldn't impact the parsers.
-------------- 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/20130730/a8e63708/attachment.sig>

From mturquette at linaro.org  Tue Jul 30 17:00:06 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 30 Jul 2013 14:00:06 -0700
Subject: [PATCH v4 1/6] clk/exynos5250: Fix HDMI clock number in
 documentation
In-Reply-To: <1374728857-4208-2-git-send-email-rahul.sharma@samsung.com>
References: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
 <1374728857-4208-2-git-send-email-rahul.sharma@samsung.com>
Message-ID: <20130730210006.5270.42195@quantum>

Quoting Rahul Sharma (2013-07-24 22:07:32)
> From: Arun Kumar K <arun.kk at samsung.com>
> 
> This patch corrects the HDMI clock number given wrongly
> in the documentation.
> 
> Signed-off-by: Arun Kumar K <arun.kk at samsung.com>
> Signed-off-by: Rahul Sharma <rahul.sharma at samsung.com>

You can drop this patch as it is fixed in the clk-next branch already by
commit "of/documentation: Fix a typo in exynos5250-clock.txt", 07c2ae9c.

Regards,
Mike

> ---
>  Documentation/devicetree/bindings/clock/exynos5250-clock.txt |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> index 781a627..1a05761 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> @@ -154,7 +154,7 @@ clock which they consume.
>    dsim0                        341
>    dp                   342
>    mixer                        343
> -  hdmi                 345
> +  hdmi                 344
>  
>  Example 1: An example of a clock controller node is listed below.
>  
> -- 
> 1.7.10.4


From mturquette at linaro.org  Tue Jul 30 17:08:14 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 30 Jul 2013 14:08:14 -0700
Subject: [PATCH v4 0/6] clk/exynos5250: add clocks for hdmi subsystem
In-Reply-To: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
References: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
Message-ID: <20130730210814.5270.44742@quantum>

Quoting Rahul Sharma (2013-07-24 22:07:31)
> Add clock changes for hdmi subsystem for exynos5250 SoC. These
> include addition of new clocks like mout_hdmi and smmu_tv, associating
> ID to clk_hdmiphy and some essential corrections.
> 
> This set is based on kukjin's for-next branch at
> http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.

I've taken patches 2-4 into the clk-next branch. Patch #1 can be
dropped.

Patches 5 & 6 need to be rebased onto clk-next as the g2d clock has
reserved mapping 345.  Also I've cc'd Cho KyongHo who is rebasing his
system mmu clock patch[1] onto clk-next. Can the two of your coordinate
your changes to avoid mapping conflicts in the binding? Perhaps Rahul
can carry Cho's patch in his next version when he rebases patches 5 & 6.

Thanks,
Mike

[1] https://lkml.org/lkml/2013/7/30/51

> 
> V4:
> 1) Added Arun's patch hdmi clock number correction in this series.
> 2) Corrected clock number for smmu_mixer
> 
> V3:
> 1) Rebase to kgene for-next based on 3.11-rc1.
> 2) Added Tushar's patch in the series.
> 
> V2:
> 1) Dropped "clk/exynos5250: Fix HDMI clock number in documentation" as
> it already get merged.
> 
> Arun Kumar K (1):
>   clk/exynos5250: Fix HDMI clock number in documentation
> 
> Rahul Sharma (4):
>   clk/exynos5250: add mout_hdmi mux clock for hdmi
>   clk/exynos5250: add sclk_hdmiphy in the list of special clocks
>   clk/exynos5250: add clock for mixer sysmmu
>   clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem
> 
> Tushar Behera (1):
>   Documentation: exynos5250-clock: Add div_i2s1 and div_i2s2
> 
>  .../devicetree/bindings/clock/exynos5250-clock.txt |   14 +++++++++++++-
>  drivers/clk/samsung/clk-exynos5250.c               |   20 ++++++++++++++------
>  2 files changed, 27 insertions(+), 7 deletions(-)
> 
> -- 
> 1.7.10.4


From linux at arm.linux.org.uk  Tue Jul 30 17:09:13 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 30 Jul 2013 22:09:13 +0100
Subject: [PATCH v2 3/9] ARM: msm: Move debug-macro.S to include/debug
In-Reply-To: <20130730205532.GA18638@codeaurora.org>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
 <1374699274-18388-4-git-send-email-sboyd@codeaurora.org>
 <20130730205532.GA18638@codeaurora.org>
Message-ID: <20130730210912.GS24642@n2100.arm.linux.org.uk>

On Tue, Jul 30, 2013 at 01:55:32PM -0700, David Brown wrote:
> On Wed, Jul 24, 2013 at 01:54:28PM -0700, Stephen Boyd wrote:
>> One more step to allowing MSM to participate in the
>> multi-platform defconfig.
>
> Full patch: https://patchwork.kernel.org/patch/2833034/
>
>> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>> ---
>> arch/arm/Kconfig.debug                             |  9 +++-
>> .../mach/debug-macro.S => include/debug/msm.S}     | 32 ++++++++++-
>> arch/arm/mach-msm/include/mach/msm_iomap-8960.h    |  5 --
>> arch/arm/mach-msm/include/mach/msm_iomap-8x60.h    |  5 --
>> arch/arm/mach-msm/include/mach/msm_iomap.h         | 12 -----
>> arch/arm/mach-msm/include/mach/uncompress.h        | 63 ----------------------
>> arch/arm/mach-msm/io.c                             | 40 +++++++-------
>> 7 files changed, 58 insertions(+), 108 deletions(-)
>> rename arch/arm/{mach-msm/include/mach/debug-macro.S => include/debug/msm.S} (61%)
>> delete mode 100644 arch/arm/mach-msm/include/mach/uncompress.h
>
> Any comments on this?  This is mostly an MSM change, but I'd like to
> get an Ack from someone because of the file moving into
> arch/arm/include/debug.

Well, there will be some conflicts in Kconfig.debug, but there's some
other comments.  Please see my reply on the actual patch.


From linux at arm.linux.org.uk  Tue Jul 30 17:15:01 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 30 Jul 2013 22:15:01 +0100
Subject: [PATCH v2 3/9] ARM: msm: Move debug-macro.S to include/debug
In-Reply-To: <1374699274-18388-4-git-send-email-sboyd@codeaurora.org>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
 <1374699274-18388-4-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130730211501.GT24642@n2100.arm.linux.org.uk>

On Wed, Jul 24, 2013 at 01:54:28PM -0700, Stephen Boyd wrote:
> One more step to allowing MSM to participate in the
> multi-platform defconfig.
> 
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  arch/arm/Kconfig.debug                             |  9 +++-
>  .../mach/debug-macro.S => include/debug/msm.S}     | 32 ++++++++++-
>  arch/arm/mach-msm/include/mach/msm_iomap-8960.h    |  5 --
>  arch/arm/mach-msm/include/mach/msm_iomap-8x60.h    |  5 --
>  arch/arm/mach-msm/include/mach/msm_iomap.h         | 12 -----
>  arch/arm/mach-msm/include/mach/uncompress.h        | 63 ----------------------
>  arch/arm/mach-msm/io.c                             | 40 +++++++-------
>  7 files changed, 58 insertions(+), 108 deletions(-)
>  rename arch/arm/{mach-msm/include/mach/debug-macro.S => include/debug/msm.S} (61%)
>  delete mode 100644 arch/arm/mach-msm/include/mach/uncompress.h
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index e401a76..4a62a8d 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -777,6 +777,11 @@ config DEBUG_LL_INCLUDE
>  				 DEBUG_IMX6SL_UART
>  	default "debug/keystone.S" if DEBUG_KEYSTONE_UART0 || \
>  				      DEBUG_KEYSTONE_UART1
> +	default "debug/msm.S" if DEBUG_MSM_UART1 || \
> +				 DEBUG_MSM_UART2 || \
> +				 DEBUG_MSM_UART3 || \
> +				 DEBUG_MSM8660_UART || \
> +				 DEBUG_MSM8960_UART
>  	default "debug/mvebu.S" if DEBUG_MVEBU_UART || \
>  				   DEBUG_MVEBU_UART_ALTERNATE
>  	default "debug/mxs.S" if DEBUG_IMX23_UART || DEBUG_IMX28_UART
> @@ -804,13 +809,13 @@ config DEBUG_LL_INCLUDE
>  
>  config DEBUG_UNCOMPRESS
>  	bool
> -	default y if ARCH_MULTIPLATFORM && DEBUG_LL && \
> +	default y if (ARCH_MULTIPLATFORM || ARCH_MSM) && DEBUG_LL && \
>  		     !DEBUG_OMAP2PLUS_UART && \
>  		     !DEBUG_TEGRA_UART
>  
>  config UNCOMPRESS_INCLUDE
>  	string
> -	default "debug/uncompress.h" if ARCH_MULTIPLATFORM
> +	default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM
>  	default "mach/uncompress.h"

I hope the above two aren't going to grow.

>  	{
>  		.virtual =  (unsigned long) MSM_SHARED_RAM_BASE,
>  		.pfn = __phys_to_pfn(MSM_SHARED_RAM_PHYS),
>  		.length =   MSM_SHARED_RAM_SIZE,
>  		.type =     MT_DEVICE,
>  	},

A comment here mentioning that the below must be the last entry would
probably be a good idea as you overwrite the virtual/pfn members of this
last entry.

> +#if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
> +		defined(CONFIG_DEBUG_MSM_UART3)
> +	{
> +		/* virtual and pfn filled in by debug_ll_addr() */
> +		.length = SZ_4K,
> +		.type = MT_DEVICE_NONSHARED,
> +	}
> +#endif

Other than that, this seems to be fine.


From coelho at ti.com  Tue Jul 30 17:15:19 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 31 Jul 2013 00:15:19 +0300
Subject: [PATCH v2 0/4] ARM: dts: add WiLink support to panda and omap4-sdp
Message-ID: <1375218923-29876-1-git-send-email-coelho@ti.com>

Hi,

In v2: use IRQ_TYPE_LEVEL_HIGH when defining the interrupts, as
suggested by Laurent.


These patches add the necessary DT configuration to use the WLAN part
of WiLink on OMAP4 Pandaboard and on OMAP4-SDP (including Blaze).

I've tested these changes on Panda and it works fine.  But I couldn't
test the OMAP4 SDP changes properly on 3.11-rc3 because I'm having
problems with clocks and SDIO stuff.  So it's pretty much just
compiled tested.  I've tried this (without the new clock definition
stuff) on Blaze with 3.10 and it was working, though.

Please take a look and let me know what you think.

Luca.

Luciano Coelho (4):
  ARM: dts: omap4-panda: add MMC5 (WiLink WLAN) configuration
  arm: dts: omap4-panda-common: add WiLink6 device tree nodes
  ARM: dts: omap4-sdp: add MMC5 (WiLink WLAN) configuration
  arm: dts: omap4-sdp: add WiLink7 device tree node

 arch/arm/boot/dts/omap4-panda-common.dtsi | 46 +++++++++++++++++++++++++++-
 arch/arm/boot/dts/omap4-sdp.dts           | 50 +++++++++++++++++++++++++++++++
 2 files changed, 95 insertions(+), 1 deletion(-)

-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 17:15:20 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 31 Jul 2013 00:15:20 +0300
Subject: [PATCH v2 1/4] ARM: dts: omap4-panda: add MMC5 (WiLink WLAN)
 configuration
In-Reply-To: <1375218923-29876-1-git-send-email-coelho@ti.com>
References: <1375218923-29876-1-git-send-email-coelho@ti.com>
Message-ID: <1375218923-29876-2-git-send-email-coelho@ti.com>

Add regulator, pin muxing and MMC5 configuration to be used by the
on-board WiLink6 module.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 arch/arm/boot/dts/omap4-panda-common.dtsi | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..b3f6e1f 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -107,6 +107,16 @@
 	 */
 		clock-frequency = <19200000>;
 	};
+
+	wilink_wl_en: fixedregulator at 1 {
+		compatible = "regulator-fixed";
+		regulator-name = "wilink_wl_en";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		gpio = <&gpio2 11 0>; /* gpio line 43 */
+		startup-delay-us = <70000>;
+		enable-active-high;
+	};
 };
 
 &omap4_pmx_wkup {
@@ -132,6 +142,7 @@
 			&dss_hdmi_pins
 			&tpd12s015_pins
 			&hsusbb1_pins
+			&wilink_pins
 	>;
 
 	twl6030_pins: pinmux_twl6030_pins {
@@ -235,6 +246,19 @@
 			0x1c (PIN_OUTPUT | MUX_MODE3)	/* gpio_wk8 */
 		>;
 	};
+
+	wilink_pins: pinmux_wilink_pins {
+		pinctrl-single,pins = <
+			0x7a 0x103      /* gpio_53  INPUT | MODE3 */
+			0x66 0x3	/* gpio_43  OUTPUT | MODE3 */
+			0x148 0x118     /* clk	    INPUT PULLUP | MODE0 */
+			0x14a 0x118     /* cmd	    INPUT PULLUP | MODE0 */
+			0x14c 0x118     /* dat0	    INPUT PULLUP | MODE0 */
+			0x14e 0x118     /* dat1	    INPUT PULLUP | MODE0 */
+			0x150 0x118     /* dat2	    INPUT PULLUP | MODE0 */
+			0x152 0x118     /* dat3	    INPUT PULLUP | MODE0 */
+		>;
+	};
 };
 
 &i2c1 {
@@ -314,8 +338,13 @@
 };
 
 &mmc5 {
-	ti,non-removable;
+	status = "okay";
+	vmmc-supply = <&wilink_wl_en>;
 	bus-width = <4>;
+	cap-power-off-card;
+	keep-power-in-suspend;
+	ti,non-removable;
+	ti,needs-special-hs-handling;
 };
 
 &emif1 {
-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 17:15:21 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 31 Jul 2013 00:15:21 +0300
Subject: [PATCH v2 2/4] arm: dts: omap4-panda-common: add WiLink6 device tree
 nodes
In-Reply-To: <1375218923-29876-1-git-send-email-coelho@ti.com>
References: <1375218923-29876-1-git-send-email-coelho@ti.com>
Message-ID: <1375218923-29876-3-git-send-email-coelho@ti.com>

Add the WiLink device tree nodes.  On omap4-panda, a WiLink6 module is
connected on MMC5 and a GPIO interrupt is used.  The refclock
frequency is 38.4MHz.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 arch/arm/boot/dts/omap4-panda-common.dtsi | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index b3f6e1f..59a797d 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -5,6 +5,7 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+#include <dt-bindings/interrupt-controller/irq.h>
 #include "elpida_ecb240abacn.dtsi"
 
 / {
@@ -117,6 +118,20 @@
 		startup-delay-us = <70000>;
 		enable-active-high;
 	};
+
+	wlan {
+		compatible = "ti,wilink6";
+		interrupt-parent = <&gpio2>;
+		interrupts = <21 IRQ_TYPE_LEVEL_HIGH>;	/* gpio line 53 */
+		clocks = <&refclock>;
+		clock-names = "refclock";
+
+		refclock: refclock {
+			compatible = "ti,wilink-clock";
+			#clock-cells = <0>;
+			clock-frequency = <38400000>;
+		};
+	 };
 };
 
 &omap4_pmx_wkup {
-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 17:15:23 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 31 Jul 2013 00:15:23 +0300
Subject: [PATCH v2 4/4] arm: dts: omap4-sdp: add WiLink7 device tree node
In-Reply-To: <1375218923-29876-1-git-send-email-coelho@ti.com>
References: <1375218923-29876-1-git-send-email-coelho@ti.com>
Message-ID: <1375218923-29876-5-git-send-email-coelho@ti.com>

Add appropriate device tree node for Blaze's WiLink7 module.  It uses
a GPIO as interrupt, so configure the gpio2 node as interrupt parent
and assign the corresponding GPIO.  Additionally, add the clock
frequencies used by the module.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 arch/arm/boot/dts/omap4-sdp.dts | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 3845615..63f1af1 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -7,6 +7,7 @@
  */
 /dts-v1/;
 
+#include <dt-bindings/interrupt-controller/irq.h>
 #include "omap443x.dtsi"
 #include "elpida_ecb240abacn.dtsi"
 
@@ -150,6 +151,26 @@
 		startup-delay-us = <70000>;
 		enable-active-high;
 	};
+
+	wlan {
+		compatible = "ti,wilink7";
+		interrupt-parent = <&gpio2>;
+		interrupts = <21 IRQ_TYPE_LEVEL_HIGH>;	/* gpio line 53 */
+		clocks = <&refclock &tcxoclock>;
+		clock-names = "refclock tcxoclock";
+
+		refclock: refclock {
+			compatible = "ti,wilink-clock";
+			#clock-cells = <0>;
+			clock-frequency = <26000000>;
+		};
+
+		tcxoclock: tcxoclock {
+			compatible = "ti,wilink-clock";
+			#clock-cells = <0>;
+			clock-frequency = <26000000>;
+		};
+	 };
 };
 
 &omap4_pmx_wkup {
-- 
1.8.3.2



From coelho at ti.com  Tue Jul 30 17:15:22 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 31 Jul 2013 00:15:22 +0300
Subject: [PATCH v2 3/4] ARM: dts: omap4-sdp: add MMC5 (WiLink WLAN)
 configuration
In-Reply-To: <1375218923-29876-1-git-send-email-coelho@ti.com>
References: <1375218923-29876-1-git-send-email-coelho@ti.com>
Message-ID: <1375218923-29876-4-git-send-email-coelho@ti.com>

Add regulator, pin muxing and MMC5 configuration to be used by the
on-board WiLink6 module.

Signed-off-by: Luciano Coelho <coelho at ti.com>
---
 arch/arm/boot/dts/omap4-sdp.dts | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..3845615 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -140,6 +140,16 @@
 			"DMic", "Digital Mic",
 			"Digital Mic", "Digital Mic1 Bias";
 	};
+
+	wilink_wl_en: fixedregulator at 1 {
+		compatible = "regulator-fixed";
+		regulator-name = "wilink_wl_en";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		gpio = <&gpio2 22 0>; /* gpio line 54 */
+		startup-delay-us = <70000>;
+		enable-active-high;
+	};
 };
 
 &omap4_pmx_wkup {
@@ -166,6 +176,7 @@
 			&mcbsp2_pins
 			&dss_hdmi_pins
 			&tpd12s015_pins
+			&wilink_pins
 	>;
 
 	uart2_pins: pinmux_uart2_pins {
@@ -295,6 +306,19 @@
 			0xf0 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c4_sda */
 		>;
 	};
+
+	wilink_pins: pinmux_wilink_pins {
+		pinctrl-single,pins = <
+			0x7a 0x103      /* gpio_53  INPUT | MODE3 */
+			0x7c 0x3	/* gpio_54  OUTPUT | MODE3 */
+			0x148 0x118     /* clk	    INPUT PULLUP | MODE0 */
+			0x14a 0x118     /* cmd	    INPUT PULLUP | MODE0 */
+			0x14c 0x118     /* dat0	    INPUT PULLUP | MODE0 */
+			0x14e 0x118     /* dat1	    INPUT PULLUP | MODE0 */
+			0x150 0x118     /* dat2	    INPUT PULLUP | MODE0 */
+			0x152 0x118     /* dat3	    INPUT PULLUP | MODE0 */
+		>;
+	};
 };
 
 &i2c1 {
@@ -420,8 +444,13 @@
 };
 
 &mmc5 {
+	status = "okay";
+	vmmc-supply = <&wilink_wl_en>;
 	bus-width = <4>;
+	cap-power-off-card;
+	keep-power-in-suspend;
 	ti,non-removable;
+	ti,needs-special-hs-handling;
 };
 
 &emif1 {
-- 
1.8.3.2



From mturquette at linaro.org  Tue Jul 30 17:21:00 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 30 Jul 2013 14:21:00 -0700
Subject: [PATCH 08/11] clk: tegra114: add suspend/resume function for
 tegar_cpu_car_ops
In-Reply-To: <1372152475-18617-9-git-send-email-josephl@nvidia.com>
References: <1372152475-18617-1-git-send-email-josephl@nvidia.com>
 <1372152475-18617-9-git-send-email-josephl@nvidia.com>
Message-ID: <20130730212100.5270.53947@quantum>

Quoting Joseph Lo (2013-06-25 02:27:52)
> Adding suspend/resume function for tegra_cpu_car_ops. We only save and
> restore the setting of the clock of CoreSight. Other clocks still need
> to be taken care by clock driver.
> 
> Cc: Mike Turquette <mturquette at linaro.org>
> Signed-off-by: Joseph Lo <josephl at nvidia.com>

Change looks OK to me, besides Stephen's comments. I was waiting for a
V2 to hit the list but I never saw it. Any plans?

Regards,
Mike

> ---
>  drivers/clk/tegra/clk-tegra114.c | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
> index dbd0428..cd51d75 100644
> --- a/drivers/clk/tegra/clk-tegra114.c
> +++ b/drivers/clk/tegra/clk-tegra114.c
> @@ -258,6 +258,12 @@
>  #define PMC_PLLM_WB0_OVERRIDE 0x1dc
>  #define PMC_PLLM_WB0_OVERRIDE_2 0x2b0
>  
> +#ifdef CONFIG_PM_SLEEP
> +static struct cpu_clk_suspend_context {
> +       u32 clk_csite_src;
> +} tegra114_cpu_clk_sctx;
> +#endif
> +
>  static int periph_clk_enb_refcnt[CLK_OUT_ENB_NUM * 32];
>  
>  static void __iomem *clk_base;
> @@ -2107,9 +2113,29 @@ static void tegra114_disable_cpu_clock(u32 cpu)
>         /* flow controller would take care in the power sequence. */
>  }
>  
> +#ifdef CONFIG_PM_SLEEP
> +static void tegra114_cpu_clock_suspend(void)
> +{
> +       /* switch coresite to clk_m, save off original source */
> +       tegra114_cpu_clk_sctx.clk_csite_src =
> +                               readl(clk_base + CLK_SOURCE_CSITE);
> +       writel(3<<30, clk_base + CLK_SOURCE_CSITE);
> +}
> +
> +static void tegra114_cpu_clock_resume(void)
> +{
> +       writel(tegra114_cpu_clk_sctx.clk_csite_src,
> +                                       clk_base + CLK_SOURCE_CSITE);
> +}
> +#endif
> +
>  static struct tegra_cpu_car_ops tegra114_cpu_car_ops = {
>         .wait_for_reset = tegra114_wait_cpu_in_reset,
>         .disable_clock  = tegra114_disable_cpu_clock,
> +#ifdef CONFIG_PM_SLEEP
> +       .suspend        = tegra114_cpu_clock_suspend,
> +       .resume         = tegra114_cpu_clock_resume,
> +#endif
>  };
>  
>  static const struct of_device_id pmc_match[] __initconst = {
> -- 
> 1.8.3.1


From thomas.petazzoni at free-electrons.com  Tue Jul 30 17:23:16 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 30 Jul 2013 23:23:16 +0200
Subject: NSA310 + DT
In-Reply-To: <51F814A0.2050403@uni-bremen.de>
References: <20130710073706.GA28212@lunn.ch> <51F6A0DC.3020501@uni-bremen.de>
 <20130729192112.GY29916@titan.lakedaemon.net>
 <20130729204315.GK24782@lunn.ch> <51F78DA6.8010307@uni-bremen.de>
 <20130730144752.GR24782@lunn.ch> <20130730172407.3aab15c6@skate>
 <51F7EBB9.7000504@uni-bremen.de> <20130730191943.49f8070c@skate>
 <20130730183610.GT24782@lunn.ch> <51F814A0.2050403@uni-bremen.de>
Message-ID: <20130730232316.10dc7019@skate>

Dear Finn Hoffmann,

On Tue, 30 Jul 2013 21:31:44 +0200, Finn Hoffmann wrote:
> # cat /sys/kernel/debug/mvebu-mbus/devices
> [00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap 0000000000010000)
> [01] disabled
> [02] disabled
> [03] disabled
> [04] 00000000f4000000 - 00000000f4010000 : nand
> [05] 00000000f5000000 - 00000000f5010000 : sram
> [06] 00000000fff00000 - 0000000100000000 : pcie0.0

Ok, now we have a memory window created, which looks better, but its
addresses are wrong.

> mvebu-pcie pcie-controller.1: PCIe0.0: link up
> mvebu-pcie pcie-controller.1: PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [io 0x1000-0xfffff]
> pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
> pci_bus 0000:00: root bus resource [bus 00-ff]
> PCI: bus0: Fast back to back transfers disabled
> pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> PCI: bus1: Fast back to back transfers disabled
> MVEBU PCI 0.0: new pref mem, base 0xfff0, limit 0xfff0
> MVEBU PCI 0.0: new pref mem, base 0x0, limit 0x0
> mvebu_mbus: cannot add window 'pcie0.0', conflicts with another window
> pci 0000:00:01.0: BAR 9: assigned [mem 0xe0000000-0xe00fffff pref]
> pci 0000:00:01.0: BAR 7: assigned [io 0x10000-0x10fff]
> pci 0000:01:00.0: BAR 6: assigned [mem 0xe0000000-0xe000ffff pref]
> pci 0000:01:00.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref]
> pci 0000:01:00.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref]
> pci 0000:01:00.0: BAR 0: assigned [io 0x10000-0x100ff]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0: bridge window [io 0x10000-0x10fff]
> MVEBU PCI 0.0: new io, base 0x1, limit 0x1
> MVEBU PCI 0.0: new mem, base 0xfff0, limit 0x0
> pci 0000:00:01.0: bridge window [mem 0xe0000000-0xe00fffff pref]
> MVEBU PCI 0.0: new pref mem, base 0xe000, limit 0xe000
> mvebu_mbus: cannot add window 'pcie0.0', conflicts with another window

Thanks for this log. I need a bit of time to analyze this with the
PCI-to-PCI bridge specification, and I'll cook up a new patch,
hopefully tomorrow.

Thanks again a lot for taking the time to report this bug and test the
patches,

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From swarren at wwwdotorg.org  Tue Jul 30 17:29:17 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 15:29:17 -0600
Subject: [PATCH v6 2/8] ASoC: atmel: machine driver for at91sam9x5-wm8731
 boards
In-Reply-To: <20130730204511.GX9858@sirena.org.uk>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
 <1375180329-4860-3-git-send-email-richard.genoud@gmail.com>
 <51F7FBA8.6080400@wwwdotorg.org> <20130730204511.GX9858@sirena.org.uk>
Message-ID: <51F8302D.406@wwwdotorg.org>

On 07/30/2013 02:45 PM, Mark Brown wrote:
> On Tue, Jul 30, 2013 at 11:45:12AM -0600, Stephen Warren wrote:
>> On 07/30/2013 04:32 AM, Richard Genoud wrote:
> 
>>> +wm8731 pins: +cf
>>> Documentation/devicetree/bindings/sound/wm8731.txt
> 
>> In the Tegra bindings, I deliberately put the list of CODEC pins
>> into the audio complex binding rather than the CODEC binding.
>> That's because
> 
> You really shouldn't do this, it's not accomplishing much.

What it accomplishes is not polluting the CODEC's binding with a set
of strings that must always be supported since DT is an ABI. The
strings are isolated into the specific audio complex binding, which
might possibly become deprecated and replaced with something better
and more generic.

>> I'm not sure that in the long-term we want to use strings to
>> identify the CODEC pins, rather than using integers. By putting
>> the list orf CODEC pins in the audio complex binding rather than
>> the CODEC binding, I didn't lumber the CODEC binding with a list
>> of strings that it had to support forever.
> 
> How would you create the numbers - you can't use the pin numbers
> since BGA type packages have alphanumeric ball identifiers?

The numbering would be arbitrary, except perhaps for packages that had
simple numeric pin IDs in which case those could be used. There would
be a file in <dt-bindings/audio/...> that defined it, which DTs would
include to create the properties, and CODEC/... drivers would include
and use whenever it needed to identify the pins, e.g. in some kind of
.of_xlate() function.

> Even with numerical pin numbering ou'd need to specify some defines
> for this not to be totally awful at which point you may as well
> have the strings documented since you'd end up writing a table in
> the binding document that's basically a mapping of pin names to
> numbers,
> 
>> One reason that strings are problematic is because they can't be
>> mixed with integers/phandles in the same property, so if we ever
>> end up with more generic audio bindings where the routing table
>> is expressed more like:
> 
>> audio-routes = <&component_a $a_pin &component_b $b_pin>;
> 
>> ... in order to allow completely arbitrary and fully name-spaced
>> routing specification[1], then $a_pin and $b_pin need to be
>> integers not strings.
> 
> The above is going to be legibility challenged without defines at
> which point the strings end up appearing in the binding document
> anyway.

Yes, you'd certainly have to use defines not raw integers. The strings
wouldn't appear in the binding doc so much as the numbers.


From swarren at wwwdotorg.org  Tue Jul 30 17:40:25 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 15:40:25 -0600
Subject: [PATCH] ARM: kexec: validate CPU hotplug support
In-Reply-To: <51E958CC.5070906@wwwdotorg.org>
References: <1373582931-11956-1-git-send-email-swarren@wwwdotorg.org>
 <51E958CC.5070906@wwwdotorg.org>
Message-ID: <51F832C9.9000900@wwwdotorg.org>

On 07/19/2013 09:18 AM, Stephen Warren wrote:
> On 07/11/2013 04:48 PM, Stephen Warren wrote:
>> From: Stephen Warren <swarren at nvidia.com>
>>
>> Architectures should fully validate whether kexec is possible as part of
>> machine_kexec_prepare(), so that user-space's kexec_load() operation can
>> report any problems. Performing validation in machine_kexec() itself is
>> too late, since it is not allowed to return.
>>
>> Prior to this patch, ARM's machine_kexec() was testing after-the-fact
>> whether machine_kexec_prepare() was able to disable all but one CPU.
>> Instead, modify machine_kexec_prepare() to validate all conditions
>> necessary for machine_kexec_prepare()'s to succeed. BUG if the validation
>> succeeded, yet disabling the CPUs didn't actually work.
> 
> Russell, does this look good to put into the ARM patch tracker?

I put this in the patch tracker since I assume that no response means no
objection.


From sboyd at codeaurora.org  Tue Jul 30 17:53:07 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 30 Jul 2013 14:53:07 -0700
Subject: [PATCH v2 3/9] ARM: msm: Move debug-macro.S to include/debug
In-Reply-To: <20130730211501.GT24642@n2100.arm.linux.org.uk>
References: <1374699274-18388-1-git-send-email-sboyd@codeaurora.org>
 <1374699274-18388-4-git-send-email-sboyd@codeaurora.org>
 <20130730211501.GT24642@n2100.arm.linux.org.uk>
Message-ID: <20130730215307.GG8868@codeaurora.org>

On 07/30, Russell King - ARM Linux wrote:
> On Wed, Jul 24, 2013 at 01:54:28PM -0700, Stephen Boyd wrote:
> > One more step to allowing MSM to participate in the
> > multi-platform defconfig.
> > 
> > Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> > ---
> >  arch/arm/Kconfig.debug                             |  9 +++-
> >  .../mach/debug-macro.S => include/debug/msm.S}     | 32 ++++++++++-
> >  arch/arm/mach-msm/include/mach/msm_iomap-8960.h    |  5 --
> >  arch/arm/mach-msm/include/mach/msm_iomap-8x60.h    |  5 --
> >  arch/arm/mach-msm/include/mach/msm_iomap.h         | 12 -----
> >  arch/arm/mach-msm/include/mach/uncompress.h        | 63 ----------------------
> >  arch/arm/mach-msm/io.c                             | 40 +++++++-------
> >  7 files changed, 58 insertions(+), 108 deletions(-)
> >  rename arch/arm/{mach-msm/include/mach/debug-macro.S => include/debug/msm.S} (61%)
> >  delete mode 100644 arch/arm/mach-msm/include/mach/uncompress.h
> > 
> > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> > index e401a76..4a62a8d 100644
> > --- a/arch/arm/Kconfig.debug
> > +++ b/arch/arm/Kconfig.debug
> > @@ -777,6 +777,11 @@ config DEBUG_LL_INCLUDE
> >  				 DEBUG_IMX6SL_UART
> >  	default "debug/keystone.S" if DEBUG_KEYSTONE_UART0 || \
> >  				      DEBUG_KEYSTONE_UART1
> > +	default "debug/msm.S" if DEBUG_MSM_UART1 || \
> > +				 DEBUG_MSM_UART2 || \
> > +				 DEBUG_MSM_UART3 || \
> > +				 DEBUG_MSM8660_UART || \
> > +				 DEBUG_MSM8960_UART
> >  	default "debug/mvebu.S" if DEBUG_MVEBU_UART || \
> >  				   DEBUG_MVEBU_UART_ALTERNATE
> >  	default "debug/mxs.S" if DEBUG_IMX23_UART || DEBUG_IMX28_UART
> > @@ -804,13 +809,13 @@ config DEBUG_LL_INCLUDE
> >  
> >  config DEBUG_UNCOMPRESS
> >  	bool
> > -	default y if ARCH_MULTIPLATFORM && DEBUG_LL && \
> > +	default y if (ARCH_MULTIPLATFORM || ARCH_MSM) && DEBUG_LL && \
> >  		     !DEBUG_OMAP2PLUS_UART && \
> >  		     !DEBUG_TEGRA_UART
> >  
> >  config UNCOMPRESS_INCLUDE
> >  	string
> > -	default "debug/uncompress.h" if ARCH_MULTIPLATFORM
> > +	default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM
> >  	default "mach/uncompress.h"
> 
> I hope the above two aren't going to grow.

>From what I can tell we should convert everyone over to this so
that they don't have to put almost exactly the same code in the
uncompress.h as they put in their debug-macro.S

> 
> >  	{
> >  		.virtual =  (unsigned long) MSM_SHARED_RAM_BASE,
> >  		.pfn = __phys_to_pfn(MSM_SHARED_RAM_PHYS),
> >  		.length =   MSM_SHARED_RAM_SIZE,
> >  		.type =     MT_DEVICE,
> >  	},
> 
> A comment here mentioning that the below must be the last entry would
> probably be a good idea as you overwrite the virtual/pfn members of this
> last entry.

I thought the comment there was sufficient. I'll add "must be
last" to be more explicit.

> 
> > +#if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
> > +		defined(CONFIG_DEBUG_MSM_UART3)
> > +	{
> > +		/* virtual and pfn filled in by debug_ll_addr() */
> > +		.length = SZ_4K,
> > +		.type = MT_DEVICE_NONSHARED,
> > +	}
> > +#endif

David can you fold this in?

---8<-----
diff --git a/arch/arm/mach-msm/io.c b/arch/arm/mach-msm/io.c
index 5f1b0aa..adc8971 100644
--- a/arch/arm/mach-msm/io.c
+++ b/arch/arm/mach-msm/io.c
@@ -60,7 +60,7 @@ static struct map_desc msm_io_desc[] __initdata = {
 #if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
 		defined(CONFIG_DEBUG_MSM_UART3)
 	{
-		/* virtual and pfn filled in by debug_ll_addr() */
+		/* Must be last: virtual and pfn filled in by debug_ll_addr() */
 		.length = SZ_4K,
 		.type = MT_DEVICE_NONSHARED,
 	}

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From sboyd at codeaurora.org  Tue Jul 30 18:12:31 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 30 Jul 2013 15:12:31 -0700
Subject: [PATCH v2] ARM: Fix deadlock scenario with smp_send_stop()
In-Reply-To: <1374698170-26605-1-git-send-email-sboyd@codeaurora.org>
References: <1374698170-26605-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <51F83A4F.10800@codeaurora.org>

On 07/24/13 13:36, Stephen Boyd wrote:
> If one process calls sys_reboot and that process then stops other
> CPUs while those CPUs are within a spin_lock() region we can
> potentially encounter a deadlock scenario like below.
>
> CPU 0                   CPU 1
> -----                   -----
>                         spin_lock(my_lock)
> smp_send_stop()
>  <send IPI>             handle_IPI()
>                          disable_preemption/irqs
>                           while(1);
>  <PREEMPT>
> spin_lock(my_lock) <--- Waits forever
>
> We shouldn't attempt to run any other tasks after we send a stop
> IPI to a CPU so disable preemption so that this task runs to
> completion. We use local_irq_disable() here for cross-arch
> consistency with x86.
>
> Reported-by: Sundarajan Srinivasan <sundaraj at codeaurora.com>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---

Ok I threw this into the patch tracker because there were no more comments.

> Changes since v1:
>  - Use local_irq_disable() instead of preempt_disable()
>
>  arch/arm/kernel/process.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index d3ca4f6..08b47eb 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -197,6 +197,7 @@ void machine_shutdown(void)
>   */
>  void machine_halt(void)
>  {
> +	local_irq_disable();
>  	smp_send_stop();
>  
>  	local_irq_disable();
> @@ -211,6 +212,7 @@ void machine_halt(void)
>   */
>  void machine_power_off(void)
>  {
> +	local_irq_disable();
>  	smp_send_stop();
>  
>  	if (pm_power_off)
> @@ -230,6 +232,7 @@ void machine_power_off(void)
>   */
>  void machine_restart(char *cmd)
>  {
> +	local_irq_disable();
>  	smp_send_stop();
>  
>  	arm_pm_restart(reboot_mode, cmd);


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From davej at redhat.com  Tue Jul 30 18:14:35 2013
From: davej at redhat.com (Dave Jones)
Date: Tue, 30 Jul 2013 18:14:35 -0400
Subject: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit
 mitigations
In-Reply-To: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
References: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
Message-ID: <20130730221435.GA22240@redhat.com>

On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
 
 > - fuzzing (is anyone running trinity or similar on the ARM tree?)
 
Someone was kind enough to send me an arm chromebook, so I tried this just
last week (albeit, on the 3.4 kernel it shipped with). The results make
me think the answer is a resounding 'no'.

I don't have time to build more recent kernels on it, but I wouldn't
be surprised to find that things aren't much better (If they are, someone
is seriously sucking at backporting stuff to stable).

There's no ARM64 support yet in trinity, though it'd be easy to add for
someone with hardware. Again, wouldn't be surprised at all to learn there
are bugs there (It's been true of every new arch ported to so far).

On the subject of trinity, I've been hesitant about proposing a slot
at k-s this year, though if there's interest I'm always happy to talk
about it, and get feedback for new places it could go..

	Dave



From soren.brinkmann at xilinx.com  Tue Jul 30 18:14:43 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Tue, 30 Jul 2013 15:14:43 -0700
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <51F77D93.4030505@linaro.org>
References: <51E72DCA.9070500@codeaurora.org>
 <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
 <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
 <51F77D93.4030505@linaro.org>
Message-ID: <b8d1f8ab-e9b2-4f16-9935-4af249bd5375@CH1EHSMHS041.ehs.local>

On Tue, Jul 30, 2013 at 10:47:15AM +0200, Daniel Lezcano wrote:
> On 07/30/2013 02:03 AM, S?ren Brinkmann wrote:
> > Hi Daniel,
> > 
> > On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
> > (snip)
> >>
> >> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
> >> timer will be stopped when entering to the idle state. In this case, the
> >> cpuidle framework will call clockevents_notify(ENTER) and switches to a
> >> broadcast timer and will call clockevents_notify(EXIT) when exiting the
> >> idle state, switching the local timer back in use.
> > 
> > I've been thinking about this, trying to understand how this makes my
> > boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
> > would make the timer core switch to a broadcast device even though it
> > wouldn't be necessary. But shouldn't it still work? It sounds like we do
> > something useless, but nothing wrong in a sense that it should result in
> > breakage. I guess I'm missing something obvious. This timer system will
> > always remain a mystery to me.
> > 
> > Actually this more or less leads to the question: What is this
> > 'broadcast timer'. I guess that is some clockevent device which is
> > common to all cores? (that would be the cadence_ttc for Zynq). Is the
> > hang pointing to some issue with that driver?
> 
> If you look at the /proc/timer_list, which timer is used for broadcasting ?

In case of a vanilla kernel and with my patches for enabling the global
timer (I removed the wrongly set flag from the C2 state + adding the DT
fragment to use the GT), this is what I see (full output from timer_list
attached):
	Tick Device: mode:     1
	Broadcast device
	Clock Event Device: xttcps_clockevent

And the local timer seems to be the arm twd timer (also in both cases).

I don't think I can gather this information for the actual broken case,
but AFAIK, there shouldn't be any other timer be capable of this for
Zynq.

	S?ren

-------------- next part --------------
Timer List Version: v0.7
HRTIMER_MAX_CLOCK_BASES: 3
now at 76779317814 nsecs

cpu: 0
 clock 0:
  .base:       c14a0c90
  .index:      0
  .resolution: 1 nsecs
  .get_time:   ktime_get
  .offset:     0 nsecs
active timers:
 #0: <c14a2b50>, menu_hrtimer_notify, S:01, hrtimer_start, swapper/0/0
 # expires at 76779328789-76779328789 nsecs [in 10975 to 10975 nsecs]
 #1: <c14a0dd8>, tick_sched_timer, S:01, hrtimer_start, swapper/0/0
 # expires at 76800000000-76800000000 nsecs [in 20682186 to 20682186 nsecs]
 #2: <ed956e40>, timerfd_tmrproc, S:01, hrtimer_start, systemd/1
 # expires at 93249172026-93249172026 nsecs [in 16469854212 to 16469854212 nsecs]
 #3: <ed956c00>, timerfd_tmrproc, S:01, hrtimer_start, systemd/1
 # expires at 900000055806-900000055806 nsecs [in 823220737992 to 823220737992 nsecs]
 clock 1:
  .base:       c14a0cc8
  .index:      1
  .resolution: 1 nsecs
  .get_time:   ktime_get_real
  .offset:     975789465870609368 nsecs
active timers:
 clock 2:
  .base:       c14a0d00
  .index:      2
  .resolution: 1 nsecs
  .get_time:   ktime_get_boottime
  .offset:     0 nsecs
active timers:
  .expires_next   : 76779492678 nsecs
  .hres_active    : 1
  .nr_events      : 2449
  .nr_retries     : 66
  .nr_hangs       : 0
  .max_hang_time  : 0 nsecs
  .nohz_mode      : 2
  .last_tick      : 76780000000 nsecs
  .tick_stopped   : 1
  .idle_jiffies   : 4294944973
  .idle_calls     : 3114
  .idle_sleeps    : 981
  .idle_entrytime : 76779354678 nsecs
  .idle_waketime  : 76779336246 nsecs
  .idle_exittime  : 76769862116 nsecs
  .idle_sleeptime : 70735903990 nsecs
  .iowait_sleeptime: 18432 nsecs
  .last_jiffies   : 4294944973
  .next_jiffies   : 4294944976
  .idle_expires   : 76800000000 nsecs
jiffies: 4294944973

cpu: 1
 clock 0:
  .base:       c14a9c90
  .index:      0
  .resolution: 1 nsecs
  .get_time:   ktime_get
  .offset:     0 nsecs
active timers:
 #0: <c14a9dd8>, tick_sched_timer, S:01, hrtimer_start_range_ns, swapper/1/0
 # expires at 76780000000-76780000000 nsecs [in 682186 to 682186 nsecs]
 clock 1:
  .base:       c14a9cc8
  .index:      1
  .resolution: 1 nsecs
  .get_time:   ktime_get_real
  .offset:     975789465870609368 nsecs
active timers:
 clock 2:
  .base:       c14a9d00
  .index:      2
  .resolution: 1 nsecs
  .get_time:   ktime_get_boottime
  .offset:     0 nsecs
active timers:
  .expires_next   : 76780000000 nsecs
  .hres_active    : 1
  .nr_events      : 2257
  .nr_retries     : 61
  .nr_hangs       : 0
  .max_hang_time  : 0 nsecs
  .nohz_mode      : 2
  .last_tick      : 76700000000 nsecs
  .tick_stopped   : 0
  .idle_jiffies   : 4294944965
  .idle_calls     : 2998
  .idle_sleeps    : 444
  .idle_entrytime : 76771944950 nsecs
  .idle_waketime  : 76768498136 nsecs
  .idle_exittime  : 76768498136 nsecs
  .idle_sleeptime : 72124544054 nsecs
  .iowait_sleeptime: 4276262 nsecs
  .last_jiffies   : 4294944973
  .next_jiffies   : 4294944974
  .idle_expires   : 78880000000 nsecs
jiffies: 4294944973


Tick Device: mode:     1
Broadcast device
Clock Event Device: xttcps_clockevent
 max_delta_ns:   1207932479
 min_delta_ns:   18432
 mult:           233015
 shift:          32
 mode:           1
 next_event:     9223372036854775807 nsecs
 set_next_event: xttcps_set_next_event
 set_mode:       xttcps_set_mode
 event_handler:  tick_handle_oneshot_broadcast
 retries:        0
tick_broadcast_mask: 00000000
tick_broadcast_oneshot_mask: 00000000


Tick Device: mode:     1
Per CPU device: 0
Clock Event Device: local_timer
 max_delta_ns:   12884902005
 min_delta_ns:   1000
 mult:           715827876
 shift:          31
 mode:           3
 next_event:     76800000000 nsecs
 set_next_event: twd_set_next_event
 set_mode:       twd_set_mode
 event_handler:  hrtimer_interrupt
 retries:        0

Tick Device: mode:     1
Per CPU device: 1
Clock Event Device: local_timer
 max_delta_ns:   12884902005
 min_delta_ns:   1000
 mult:           715827876
 shift:          31
 mode:           3
 next_event:     76780000000 nsecs
 set_next_event: twd_set_next_event
 set_mode:       twd_set_mode
 event_handler:  hrtimer_interrupt
 retries:        0


From jonsmirl at gmail.com  Tue Jul 30 18:19:08 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Tue, 30 Jul 2013 18:19:08 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <20130730205716.GZ9858@sirena.org.uk>
References: <2469263.vMN09Q7Tzi@flatron> <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <20130730205716.GZ9858@sirena.org.uk>
Message-ID: <CAKON4Ox7-6Jf0ce64Wqr5E49KS+9E135mqc_iG-PWQ7r8bzWHA@mail.gmail.com>

On Tue, Jul 30, 2013 at 4:57 PM, Mark Brown <broonie at kernel.org> wrote:
> On Tue, Jul 30, 2013 at 01:29:56PM -0400, jonsmirl at gmail.com wrote:
>> On Tue, Jul 30, 2013 at 1:19 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> > On 07/30/2013 07:14 AM, jonsmirl at gmail.com wrote:
>
>> > > Is something similar to this possible in device tree syntax?
>> > > dmas =  <"tx" &pdma0 7>,  <"rx"  &pdma0 6>;
>
>> > I /think/ you can physically write that in *.dts, or something very
>> > similar; with the strings outside the <>:
>
>> > dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
>
>> Can we turn the strings into string phandles? Then they'd be fixed sized.
>
>> That might provide a way to internationalize the strings too.
>
> I don't know how viable or sane this actually is but one suggestion I
> just made elsewhere which might help is to fix this at the dtc level by
> having syntatic sugar which will do the parallel arrays trick that
> people are currently using to write things out.  The user writes one
> array with multiple types of data in it and the actual output is two or
> more matched arrays each with a single type of data.
>
> It would help legibility and wouldn't impact the parsers.

FDT is versioned and PowerPC docs say that multiple versions have been
released.  If we find enough flaws we could do a new release then use
the quirks scheme to read the older versions.

So far the only issue I know of is that all of the strings aren't
stored in the string table. If all of the strings were in the string
table then we wouldn't have this variable attribute size problem.

8.2 Header
The layout of the header for the device tree is defined by the
following C structure. All the header
fields are 32-bit integers, stored in big-endian format.
struct fdt_header {
uint32_t magic;
uint32_t totalsize;
uint32_t off_dt_struct;
uint32_t off_dt_strings;
uint32_t off_mem_rsvmap;
uint32_t version;
uint32_t last_comp_version;
uint32_t boot_cpuid_phys;
uint32_t size_dt_strings;
uint32_t size_dt_struct;
};
?
magic
This field shall contain the value 0xd00dfeed (big-endian).
?
totalsize
This field shall contain the total size of the device tree data
structure. This size shall
encompass all sections of the structure: the header, the memory
reservation block, structure
block and strings block, as well as any free space gaps between the
blocks or after the final
block.
?
off_dt_struct
This field shall contain the offset in bytes of the structure block
(see 8.4) from the beginning
of the header.
?
off_dt_strings
This field shall contain the offset in bytes of the strings block (see
8.5) from the beginning of
the header.
?
off_mem_rsvmap
This field shall contain the offset in bytes of the memory reservation
block (see 8.3) from the
beginning of the header.
?
version
This field shall contain the version of the device tree data
structure. The version is 17 if using
the structure as defined in this document. An ePAPR boot program may
provide the device
tree of a later version, in which case this field shall contain the
version number defined in
whichever later document gives the details of that version.
?
last_comp_version
This field shall contain the lowest version of the device tree data
structure with which the
version used is backwards compatible. So, for the structure as defined
in this document
(version 17), this field shall contain 16 because version 17 is
backwards compatible with
version 16, but not earlier versions. As per 8.1, an ePAPR boot
program should provide a
device tree in a format which is backwards compatible with version 16,
and thus this field
shall always contain 16.
?
boot_cpuid_phys
This field shall contain the physical ID of the system?s boot CPU. It
shall be identical to the
physical ID given in the reg property of that CPU node within the device tree.
?
size_dt_strings
This field shall contain the length in bytes of the strings block
section of the device tree blob.
?
size_dt_struct
This field shall contain the length in bytes of the structure block
section of the device tree
blob.

-- 
Jon Smirl
jonsmirl at gmail.com


From tomasz.figa at gmail.com  Tue Jul 30 18:16:56 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 31 Jul 2013 00:16:56 +0200
Subject: Defining schemas for Device Tree
In-Reply-To: <2469263.vMN09Q7Tzi@flatron>
References: <2469263.vMN09Q7Tzi@flatron>
Message-ID: <3852729.INDSeEDz7b@thinkpad>

On Monday 29 of July 2013 02:21:52 Tomasz Figa wrote:
> Hi,
> 
> As promised I am starting a discussion about Device Tree schema. Let's
> first shortly introduce the problem.
> 
> Device Tree is a text-based data structure used to describe hardware. Its
> main point is separation from kernel code, which has a lot of benefits,
> but, at the moment, also a huge drawback - there is no verification of
> device tree sources against defined bindings. All the dtc compiler does
> currently are syntax checks - no semantic analysis is performed (except
> some really basic things). What this means is that anybody can put
> anything in their device tree and end up with the dts compiling fine only
> to find out that something is wrong at boot time.
> 
> Currently, device tree bindings are described in plain text documentation
> files, which can not be considered a formal way of binding description.
> While such documentation provides information for developers/users that
> need to work with particular bindings, it can not be easily used as input
> for validation of device tree sources. This means that we need to define a
> more formal way of binding description, in other words - Device Tree
> schema.
> 
> To find a solution for this problem, we must first answer several
> questions to determine a set of requirements we have to meet.
> 
> a) What is a device tree binding?
> 
> For our purposes, I will define a binding as internal format of some
> device tree node, which can be matched using of_find_matching_node(). In
> other words, key for a binding would be node name and/or value of
> compatible property and/or node type. Value for a binding would be a list
> of properties with their formats and/or subnodes with their bindings.

Now as I think of it, there is one more thing that needs to be considered. Do 
we want the schemas to strictly specify available set of properties, warning 
about any unrecognized ones or just enforce checking of recognized properties 
(including presence of required ones)? Or maybe both, depending on some 
keyword or whatever?

> b) What information should be specified in schemas? What level of
>    granularity is required?
> 
> For each property we need to have at least following data specified:
>  - property name (or property name format, e.g. regex),
>  - whether the property is mandatory or optional,
>  - data type of value.
> 
> As for now, I can think of following data types used in device trees:
>  - boolean (i.e. without value),
>  - array of strings (including single string),
>  - array of u32 (including single u32),
>  - specifier (aka phandle with args, including cases with 0 args),
>  - variable-length cells (e.g. #address-cells of u32s).
> 
> Some properties might require a combination of data types to be specified
> or even an array of combinations, like interrupt-map property, which is an
> array of entries consisting of:
>  - #address-cells u32s,
>  - #interrupt-cells u32s,
>  - specifier (phandle of interrupt controller and u32 of count defined by
>    #interrupt-cells of the controller).
> 
> We probably want to define allowed range of values for given property, be
> it contiguous or enumerated.
> 
> As for subnodes, I think we need to define following constraints:
>  - node name (or node name format, e.g. regex),
>  - optional or not,
>  - how many nodes of this type can be present (one, limited, unlimited),
>  - recursively define binding for such node type.
> 
> We probably also want human readable descriptions for all properties and
> subnodes, so a textual documentation (like the one currently available)
> could be generated from schemas.
> 
> c) What about generic bindings? (e.g. for subsystems like pinctrl or
> regulators)
> 
> This is where things get more interesting. Looks like we need some kind of
> inheritance for bindings or binding templates. Templates sound more
> appropriate here, because most of the generic bindings do not fully
> conform to what I defined as binding and need device-specific parameters
> to become so.
> 
> Let's consider first example taken from regulator subsystem.
> 
> 	device {
> 		compatible = "foo,mydevice";
> 		/* ... */
> 		core-supply = <&regulator_a>;
> 		io-supply = <&regulator_b>;
> 		/* ... */
> 	};
> 
> Bindings of regulator subsystem define the way of regulator lookup to be
> based on property matching following definition:
> 
> 	#define REGULATOR(name) name ## _supply = <&phandle>
> 
> As you can see, the binding is parametrized, i.e. part of it is defined
> globally, but part is device-specific. Similarly for pinctrl subsystem:
> 
> 	device {
> 		compatible = "foo,mydevice";
> 		/* ... */
> 		pinctrl-names = "state0", "state1";
> 		pinctrl-0 = <&phandle>...;
> 		pinctrl-1 = <&phandle>...;
> 		/* ... */
> 	};
> 
> This binding is now parametrized in a more complex way:
> 
> 	#define PINCTRL(name0, name1, ..., nameN) \
> 		pinctrl-names = name0, name1, ..., nameN; \
> 		pinctrl-0 = <&phandle>...; \
> 		pinctrl-1 = <&phandle>...; \
> 		... \
> 		pinctrl-N = <&phandle>...;
> 
> We need to have a way to describe this kind of inheritance, if we don't
> want to respecify generic attributes in all device bindings using them.
> 
> d) When should the validation happen and what should handle it?
> 
> In my opinion, similarly to compilation of board files, validation should
> be happening at dts compile time, to show any warnings or errors as early
> as possible.
> 
> Whether this should be integrated into dtc or rather handled by external
> tool is another question. Since we are already processing device tree
> sources in dtc, it might be reasonable to reuse its dts parsing
> infrastructure and add validation there, especially that dtc is supposed
> to already contain some infrastructure for doing checks on device tree as
> well. Nothing stops us from running validation on already compiled dtbs,
> though, using an extra tool.
> 
> e) What format should be used for Device Tree schema?
> 
> This is a non-trivial problem. Key criteria I can think of are as follows:
>  - the whole set of information established above must be representable,
>  - human-readable, easy to create and edit (extend), preferably similar to
>    something already existing, so could be easily learnt,
>  - something that can be integrated with dtc with reasonable amount of
>    work or can reuse a lot (if not all) of already existing parsing code.
> 
> Okay, this should be enough to have some discussion. I will post a
> follow-up with my proposal of schema format to separate general discussion
> from discussion about the proposal, but this will happen tomorrow, as now
> it's time to get some sleep.

Finally I didn't manage to post it yet, but this might be better, as there 
have been a lot of interesting points in the discussion, which I'm now taking 
into consideration, while writing a sample schema.

Best regards,
Tomasz

> For now please think about the points above and feel free to correct
> anything wrong or suggest what else should be taken into consideration
> for DT schemas. Let the discussion start.
> 
> Best regards,
> Tomasz


From soren.brinkmann at xilinx.com  Tue Jul 30 18:23:20 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Tue, 30 Jul 2013 15:23:20 -0700
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <b8d1f8ab-e9b2-4f16-9935-4af249bd5375@CH1EHSMHS041.ehs.local>
References: <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
 <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
 <51F77D93.4030505@linaro.org>
 <b8d1f8ab-e9b2-4f16-9935-4af249bd5375@CH1EHSMHS041.ehs.local>
Message-ID: <0a90a9dd-d504-4767-a601-387427feb9c1@CO1EHSMHS025.ehs.local>

Forget this. It's trash. I had to migrate some stuff around due to some
quota issues and missed to update a few scripts. Sorry, I'll rerun this
test.

	S?ren

On Tue, Jul 30, 2013 at 03:14:43PM -0700, S?ren Brinkmann wrote:
> On Tue, Jul 30, 2013 at 10:47:15AM +0200, Daniel Lezcano wrote:
> > On 07/30/2013 02:03 AM, S?ren Brinkmann wrote:
> > > Hi Daniel,
> > > 
> > > On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
> > > (snip)
> > >>
> > >> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
> > >> timer will be stopped when entering to the idle state. In this case, the
> > >> cpuidle framework will call clockevents_notify(ENTER) and switches to a
> > >> broadcast timer and will call clockevents_notify(EXIT) when exiting the
> > >> idle state, switching the local timer back in use.
> > > 
> > > I've been thinking about this, trying to understand how this makes my
> > > boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
> > > would make the timer core switch to a broadcast device even though it
> > > wouldn't be necessary. But shouldn't it still work? It sounds like we do
> > > something useless, but nothing wrong in a sense that it should result in
> > > breakage. I guess I'm missing something obvious. This timer system will
> > > always remain a mystery to me.
> > > 
> > > Actually this more or less leads to the question: What is this
> > > 'broadcast timer'. I guess that is some clockevent device which is
> > > common to all cores? (that would be the cadence_ttc for Zynq). Is the
> > > hang pointing to some issue with that driver?
> > 
> > If you look at the /proc/timer_list, which timer is used for broadcasting ?
> 
> In case of a vanilla kernel and with my patches for enabling the global
> timer (I removed the wrongly set flag from the C2 state + adding the DT
> fragment to use the GT), this is what I see (full output from timer_list
> attached):
> 	Tick Device: mode:     1
> 	Broadcast device
> 	Clock Event Device: xttcps_clockevent
> 
> And the local timer seems to be the arm twd timer (also in both cases).
> 
> I don't think I can gather this information for the actual broken case,
> but AFAIK, there shouldn't be any other timer be capable of this for
> Zynq.
> 
> 	S?ren
> 

> Timer List Version: v0.7
> HRTIMER_MAX_CLOCK_BASES: 3
> now at 76779317814 nsecs
> 
> cpu: 0
>  clock 0:
>   .base:       c14a0c90
>   .index:      0
>   .resolution: 1 nsecs
>   .get_time:   ktime_get
>   .offset:     0 nsecs
> active timers:
>  #0: <c14a2b50>, menu_hrtimer_notify, S:01, hrtimer_start, swapper/0/0
>  # expires at 76779328789-76779328789 nsecs [in 10975 to 10975 nsecs]
>  #1: <c14a0dd8>, tick_sched_timer, S:01, hrtimer_start, swapper/0/0
>  # expires at 76800000000-76800000000 nsecs [in 20682186 to 20682186 nsecs]
>  #2: <ed956e40>, timerfd_tmrproc, S:01, hrtimer_start, systemd/1
>  # expires at 93249172026-93249172026 nsecs [in 16469854212 to 16469854212 nsecs]
>  #3: <ed956c00>, timerfd_tmrproc, S:01, hrtimer_start, systemd/1
>  # expires at 900000055806-900000055806 nsecs [in 823220737992 to 823220737992 nsecs]
>  clock 1:
>   .base:       c14a0cc8
>   .index:      1
>   .resolution: 1 nsecs
>   .get_time:   ktime_get_real
>   .offset:     975789465870609368 nsecs
> active timers:
>  clock 2:
>   .base:       c14a0d00
>   .index:      2
>   .resolution: 1 nsecs
>   .get_time:   ktime_get_boottime
>   .offset:     0 nsecs
> active timers:
>   .expires_next   : 76779492678 nsecs
>   .hres_active    : 1
>   .nr_events      : 2449
>   .nr_retries     : 66
>   .nr_hangs       : 0
>   .max_hang_time  : 0 nsecs
>   .nohz_mode      : 2
>   .last_tick      : 76780000000 nsecs
>   .tick_stopped   : 1
>   .idle_jiffies   : 4294944973
>   .idle_calls     : 3114
>   .idle_sleeps    : 981
>   .idle_entrytime : 76779354678 nsecs
>   .idle_waketime  : 76779336246 nsecs
>   .idle_exittime  : 76769862116 nsecs
>   .idle_sleeptime : 70735903990 nsecs
>   .iowait_sleeptime: 18432 nsecs
>   .last_jiffies   : 4294944973
>   .next_jiffies   : 4294944976
>   .idle_expires   : 76800000000 nsecs
> jiffies: 4294944973
> 
> cpu: 1
>  clock 0:
>   .base:       c14a9c90
>   .index:      0
>   .resolution: 1 nsecs
>   .get_time:   ktime_get
>   .offset:     0 nsecs
> active timers:
>  #0: <c14a9dd8>, tick_sched_timer, S:01, hrtimer_start_range_ns, swapper/1/0
>  # expires at 76780000000-76780000000 nsecs [in 682186 to 682186 nsecs]
>  clock 1:
>   .base:       c14a9cc8
>   .index:      1
>   .resolution: 1 nsecs
>   .get_time:   ktime_get_real
>   .offset:     975789465870609368 nsecs
> active timers:
>  clock 2:
>   .base:       c14a9d00
>   .index:      2
>   .resolution: 1 nsecs
>   .get_time:   ktime_get_boottime
>   .offset:     0 nsecs
> active timers:
>   .expires_next   : 76780000000 nsecs
>   .hres_active    : 1
>   .nr_events      : 2257
>   .nr_retries     : 61
>   .nr_hangs       : 0
>   .max_hang_time  : 0 nsecs
>   .nohz_mode      : 2
>   .last_tick      : 76700000000 nsecs
>   .tick_stopped   : 0
>   .idle_jiffies   : 4294944965
>   .idle_calls     : 2998
>   .idle_sleeps    : 444
>   .idle_entrytime : 76771944950 nsecs
>   .idle_waketime  : 76768498136 nsecs
>   .idle_exittime  : 76768498136 nsecs
>   .idle_sleeptime : 72124544054 nsecs
>   .iowait_sleeptime: 4276262 nsecs
>   .last_jiffies   : 4294944973
>   .next_jiffies   : 4294944974
>   .idle_expires   : 78880000000 nsecs
> jiffies: 4294944973
> 
> 
> Tick Device: mode:     1
> Broadcast device
> Clock Event Device: xttcps_clockevent
>  max_delta_ns:   1207932479
>  min_delta_ns:   18432
>  mult:           233015
>  shift:          32
>  mode:           1
>  next_event:     9223372036854775807 nsecs
>  set_next_event: xttcps_set_next_event
>  set_mode:       xttcps_set_mode
>  event_handler:  tick_handle_oneshot_broadcast
>  retries:        0
> tick_broadcast_mask: 00000000
> tick_broadcast_oneshot_mask: 00000000
> 
> 
> Tick Device: mode:     1
> Per CPU device: 0
> Clock Event Device: local_timer
>  max_delta_ns:   12884902005
>  min_delta_ns:   1000
>  mult:           715827876
>  shift:          31
>  mode:           3
>  next_event:     76800000000 nsecs
>  set_next_event: twd_set_next_event
>  set_mode:       twd_set_mode
>  event_handler:  hrtimer_interrupt
>  retries:        0
> 
> Tick Device: mode:     1
> Per CPU device: 1
> Clock Event Device: local_timer
>  max_delta_ns:   12884902005
>  min_delta_ns:   1000
>  mult:           715827876
>  shift:          31
>  mode:           3
>  next_event:     76780000000 nsecs
>  set_next_event: twd_set_next_event
>  set_mode:       twd_set_mode
>  event_handler:  hrtimer_interrupt
>  retries:        0
> 



From jonsmirl at gmail.com  Tue Jul 30 18:27:13 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Tue, 30 Jul 2013 18:27:13 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <3852729.INDSeEDz7b@thinkpad>
References: <2469263.vMN09Q7Tzi@flatron>
	<3852729.INDSeEDz7b@thinkpad>
Message-ID: <CAKON4Oy3nvN4PajkOgZjYpPY_2XLry4qOvnVJ_KusYZeEdzpOw@mail.gmail.com>

On Tue, Jul 30, 2013 at 6:16 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> On Monday 29 of July 2013 02:21:52 Tomasz Figa wrote:
>> Hi,
>>
>> As promised I am starting a discussion about Device Tree schema. Let's
>> first shortly introduce the problem.
>>
>> Device Tree is a text-based data structure used to describe hardware. Its
>> main point is separation from kernel code, which has a lot of benefits,
>> but, at the moment, also a huge drawback - there is no verification of
>> device tree sources against defined bindings. All the dtc compiler does
>> currently are syntax checks - no semantic analysis is performed (except
>> some really basic things). What this means is that anybody can put
>> anything in their device tree and end up with the dts compiling fine only
>> to find out that something is wrong at boot time.
>>
>> Currently, device tree bindings are described in plain text documentation
>> files, which can not be considered a formal way of binding description.
>> While such documentation provides information for developers/users that
>> need to work with particular bindings, it can not be easily used as input
>> for validation of device tree sources. This means that we need to define a
>> more formal way of binding description, in other words - Device Tree
>> schema.
>>
>> To find a solution for this problem, we must first answer several
>> questions to determine a set of requirements we have to meet.
>>
>> a) What is a device tree binding?
>>
>> For our purposes, I will define a binding as internal format of some
>> device tree node, which can be matched using of_find_matching_node(). In
>> other words, key for a binding would be node name and/or value of
>> compatible property and/or node type. Value for a binding would be a list
>> of properties with their formats and/or subnodes with their bindings.
>
> Now as I think of it, there is one more thing that needs to be considered. Do
> we want the schemas to strictly specify available set of properties, warning
> about any unrecognized ones or just enforce checking of recognized properties
> (including presence of required ones)? Or maybe both, depending on some
> keyword or whatever?

I think it should warn about anything it doesn't recognize. That's the
hint for new DT developers to get on lkml and talk about their need
for a new attribute to be added to the master schema.

The device tree quirks should be put into a file which can both be
used at init time by the kernel or by the schema checker.  Now you can
feed those flash based DTB into the schema checker, apply the quirks
to them and ensure that your quirk code is working right. The
validator would take DTB input, apply the quirks, and write the DTS
output plus any errors it finds in the transformed tree.

So the dtc source in the kernel tree would build the quirks files into it.

>
>> b) What information should be specified in schemas? What level of
>>    granularity is required?
>>
>> For each property we need to have at least following data specified:
>>  - property name (or property name format, e.g. regex),
>>  - whether the property is mandatory or optional,
>>  - data type of value.
>>
>> As for now, I can think of following data types used in device trees:
>>  - boolean (i.e. without value),
>>  - array of strings (including single string),
>>  - array of u32 (including single u32),
>>  - specifier (aka phandle with args, including cases with 0 args),
>>  - variable-length cells (e.g. #address-cells of u32s).
>>
>> Some properties might require a combination of data types to be specified
>> or even an array of combinations, like interrupt-map property, which is an
>> array of entries consisting of:
>>  - #address-cells u32s,
>>  - #interrupt-cells u32s,
>>  - specifier (phandle of interrupt controller and u32 of count defined by
>>    #interrupt-cells of the controller).
>>
>> We probably want to define allowed range of values for given property, be
>> it contiguous or enumerated.
>>
>> As for subnodes, I think we need to define following constraints:
>>  - node name (or node name format, e.g. regex),
>>  - optional or not,
>>  - how many nodes of this type can be present (one, limited, unlimited),
>>  - recursively define binding for such node type.
>>
>> We probably also want human readable descriptions for all properties and
>> subnodes, so a textual documentation (like the one currently available)
>> could be generated from schemas.
>>
>> c) What about generic bindings? (e.g. for subsystems like pinctrl or
>> regulators)
>>
>> This is where things get more interesting. Looks like we need some kind of
>> inheritance for bindings or binding templates. Templates sound more
>> appropriate here, because most of the generic bindings do not fully
>> conform to what I defined as binding and need device-specific parameters
>> to become so.
>>
>> Let's consider first example taken from regulator subsystem.
>>
>>       device {
>>               compatible = "foo,mydevice";
>>               /* ... */
>>               core-supply = <&regulator_a>;
>>               io-supply = <&regulator_b>;
>>               /* ... */
>>       };
>>
>> Bindings of regulator subsystem define the way of regulator lookup to be
>> based on property matching following definition:
>>
>>       #define REGULATOR(name) name ## _supply = <&phandle>
>>
>> As you can see, the binding is parametrized, i.e. part of it is defined
>> globally, but part is device-specific. Similarly for pinctrl subsystem:
>>
>>       device {
>>               compatible = "foo,mydevice";
>>               /* ... */
>>               pinctrl-names = "state0", "state1";
>>               pinctrl-0 = <&phandle>...;
>>               pinctrl-1 = <&phandle>...;
>>               /* ... */
>>       };
>>
>> This binding is now parametrized in a more complex way:
>>
>>       #define PINCTRL(name0, name1, ..., nameN) \
>>               pinctrl-names = name0, name1, ..., nameN; \
>>               pinctrl-0 = <&phandle>...; \
>>               pinctrl-1 = <&phandle>...; \
>>               ... \
>>               pinctrl-N = <&phandle>...;
>>
>> We need to have a way to describe this kind of inheritance, if we don't
>> want to respecify generic attributes in all device bindings using them.
>>
>> d) When should the validation happen and what should handle it?
>>
>> In my opinion, similarly to compilation of board files, validation should
>> be happening at dts compile time, to show any warnings or errors as early
>> as possible.
>>
>> Whether this should be integrated into dtc or rather handled by external
>> tool is another question. Since we are already processing device tree
>> sources in dtc, it might be reasonable to reuse its dts parsing
>> infrastructure and add validation there, especially that dtc is supposed
>> to already contain some infrastructure for doing checks on device tree as
>> well. Nothing stops us from running validation on already compiled dtbs,
>> though, using an extra tool.
>>
>> e) What format should be used for Device Tree schema?
>>
>> This is a non-trivial problem. Key criteria I can think of are as follows:
>>  - the whole set of information established above must be representable,
>>  - human-readable, easy to create and edit (extend), preferably similar to
>>    something already existing, so could be easily learnt,
>>  - something that can be integrated with dtc with reasonable amount of
>>    work or can reuse a lot (if not all) of already existing parsing code.
>>
>> Okay, this should be enough to have some discussion. I will post a
>> follow-up with my proposal of schema format to separate general discussion
>> from discussion about the proposal, but this will happen tomorrow, as now
>> it's time to get some sleep.
>
> Finally I didn't manage to post it yet, but this might be better, as there
> have been a lot of interesting points in the discussion, which I'm now taking
> into consideration, while writing a sample schema.
>
> Best regards,
> Tomasz
>
>> For now please think about the points above and feel free to correct
>> anything wrong or suggest what else should be taken into consideration
>> for DT schemas. Let the discussion start.
>>
>> Best regards,
>> Tomasz



-- 
Jon Smirl
jonsmirl at gmail.com


From swarren at wwwdotorg.org  Tue Jul 30 18:28:13 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 16:28:13 -0600
Subject: [PATCH] ARM: allow DEBUG_UNCOMPRESS for Tegra
Message-ID: <1375223293-13115-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

DEBUG_UNCOMPRESS was previously disallowed for Tegra due to tegra.S's
use of global data that was not linked into the decompressor. Solve this
by declaring this symbol in tegra.S when it is being built into the
decompressor. For the kernel proper, leave the declaration in
mach-tegra/common.c as explained in the comment.

Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/Kconfig.debug         |  3 +--
 arch/arm/include/debug/tegra.S | 28 ++++++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 38c92d7..d8ff7f7 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1046,8 +1046,7 @@ config DEBUG_UART_8250_FLOW_CONTROL
 config DEBUG_UNCOMPRESS
 	bool
 	depends on ARCH_MULTIPLATFORM
-	default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \
-		     !DEBUG_TEGRA_UART
+	default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART
 	help
 	  This option influences the normal decompressor output for
 	  multiplatform kernels.  Normally, multiplatform kernels disable
diff --git a/arch/arm/include/debug/tegra.S b/arch/arm/include/debug/tegra.S
index 883d7c2..1ebe9aa 100644
--- a/arch/arm/include/debug/tegra.S
+++ b/arch/arm/include/debug/tegra.S
@@ -221,3 +221,31 @@
 1002:
 #endif
 		.endm
+
+/*
+ * Storage for the state maintained by the macros above.
+ *
+ * In the kernel proper, this data is located in arch/arm/mach-tegra/common.c.
+ * That's because this header is included from multiple files, and we only
+ * want a single copy of the data. In particular, the UART probing code above
+ * assumes it's running using physical addresses. This is true when this file
+ * is included from head.o, but not when included from debug.o. So we need
+ * to share the probe results between the two copies, rather than having
+ * to re-run the probing again later.
+ *
+ * In the decompressor, we put the symbol/storage right here, since common.c
+ * isn't included in the decompressor build. This symbol gets put in .text
+ * even though it's really data, since .data is discarded from the
+ * decompressor. Luckily, .text is writeable in the decompressor!
+ */
+#if defined(ZIMAGE)
+tegra_uart_config:
+	/* Debug UART initialization required */
+	.word 1
+	/* Debug UART physical address */
+	.word 0
+	/* Debug UART virtual address */
+	.word 0
+	/* Scratch space for debug macro */
+	.word 0
+#endif
-- 
1.8.1.5



From hpa at zytor.com  Tue Jul 30 18:28:59 2013
From: hpa at zytor.com (H. Peter Anvin)
Date: Tue, 30 Jul 2013 15:28:59 -0700
Subject: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit
 mitigations
In-Reply-To: <20130730221435.GA22240@redhat.com>
References: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
 <20130730221435.GA22240@redhat.com>
Message-ID: <51F83E2B.7040808@zytor.com>

On 07/30/2013 03:14 PM, Dave Jones wrote:
> 
> On the subject of trinity, I've been hesitant about proposing a slot
> at k-s this year, though if there's interest I'm always happy to talk
> about it, and get feedback for new places it could go..
> 

I'd certainly be interested, no matter which forum.

	-hpa




From soren.brinkmann at xilinx.com  Tue Jul 30 18:34:46 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Tue, 30 Jul 2013 15:34:46 -0700
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <51F77D93.4030505@linaro.org>
References: <51E72DCA.9070500@codeaurora.org>
 <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
 <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
 <51F77D93.4030505@linaro.org>
Message-ID: <829dbb20-0f14-4a3b-8da9-1f7b1b5b8b59@DB8EHSMHS005.ehs.local>

On Tue, Jul 30, 2013 at 10:47:15AM +0200, Daniel Lezcano wrote:
> On 07/30/2013 02:03 AM, S?ren Brinkmann wrote:
> > Hi Daniel,
> > 
> > On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
> > (snip)
> >>
> >> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
> >> timer will be stopped when entering to the idle state. In this case, the
> >> cpuidle framework will call clockevents_notify(ENTER) and switches to a
> >> broadcast timer and will call clockevents_notify(EXIT) when exiting the
> >> idle state, switching the local timer back in use.
> > 
> > I've been thinking about this, trying to understand how this makes my
> > boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
> > would make the timer core switch to a broadcast device even though it
> > wouldn't be necessary. But shouldn't it still work? It sounds like we do
> > something useless, but nothing wrong in a sense that it should result in
> > breakage. I guess I'm missing something obvious. This timer system will
> > always remain a mystery to me.
> > 
> > Actually this more or less leads to the question: What is this
> > 'broadcast timer'. I guess that is some clockevent device which is
> > common to all cores? (that would be the cadence_ttc for Zynq). Is the
> > hang pointing to some issue with that driver?
> 
> If you look at the /proc/timer_list, which timer is used for broadcasting ?

So, the correct run results (full output attached).

The vanilla kernel uses the twd timers as local timers and the TTC as
broadcast device:
	Tick Device: mode:     1                                                         
	Broadcast device  
	Clock Event Device: ttc_clockevent

When I remove the offending CPUIDLE flag and add the DT fragment to
enable the global timer, the twd timers are still used as local timers
and the broadcast device is the global timer:
	Tick Device: mode:     1                                                         
	Broadcast device                                                                 
	Clock Event Device: arm_global_timer

Again, since boot hangs in the actually broken case, I don't see way to
obtain this information for that case.

	Thanks,
	S?ren

-------------- next part --------------
# cat /proc/timer_list 
Timer List Version: v0.7
HRTIMER_MAX_CLOCK_BASES: 4
now at 55591467929 nsecs

cpu: 0
 clock 0:
  .base:       c148e718
  .index:      0
  .resolution: 1 nsecs
  .get_time:   ktime_get
  .offset:     0 nsecs
active timers:
 #0: <c1490670>, menu_hrtimer_notify, S:01, hrtimer_start, swapper/0/0
 # expires at 55591646361-55591646361 nsecs [in 178432 to 178432 nsecs]
 clock 1:
  .base:       c148e750
  .index:      1
  .resolution: 1 nsecs
  .get_time:   ktime_get_real
  .offset:     0 nsecs
active timers:
 clock 2:
  .base:       c148e788
  .index:      2
  .resolution: 1 nsecs
  .get_time:   ktime_get_boottime
  .offset:     0 nsecs
active timers:
 clock 3:
  .base:       c148e7c0
  .index:      3
  .resolution: 1 nsecs
  .get_time:   ktime_get_clocktai
  .offset:     0 nsecs
active timers:
  .expires_next   : 55591705658 nsecs
  .hres_active    : 1
  .nr_events      : 917
  .nr_retries     : 34
  .nr_hangs       : 0
  .max_hang_time  : 0 nsecs
  .nohz_mode      : 2
  .last_tick      : 55590000000 nsecs
  .tick_stopped   : 1
  .idle_jiffies   : 4294942854
  .idle_calls     : 1977
  .idle_sleeps    : 250
  .idle_entrytime : 55591578522 nsecs
  .idle_waketime  : 55591578522 nsecs
  .idle_exittime  : 55582307145 nsecs
  .idle_sleeptime : 52623799592 nsecs
  .iowait_sleeptime: 0 nsecs
  .last_jiffies   : 4294942855
  .next_jiffies   : 4294949450
  .idle_expires   : 121540000000 nsecs
jiffies: 4294942855

cpu: 1
 clock 0:
  .base:       c1497718
  .index:      0
  .resolution: 1 nsecs
  .get_time:   ktime_get
  .offset:     0 nsecs
active timers:
 #0: <c1497ac8>, tick_sched_timer, S:01, hrtimer_start_range_ns, swapper/1/0
 # expires at 55600000000-55600000000 nsecs [in 8532071 to 8532071 nsecs]
 #1: <ed851c80>, timerfd_tmrproc, S:01, hrtimer_start, systemd/1
 # expires at 102214419661-102214419661 nsecs [in 46622951732 to 46622951732 nsecs]
 #2: <ed92fc80>, timerfd_tmrproc, S:01, hrtimer_start, systemd/1
 # expires at 900000055748-900000055748 nsecs [in 844408587819 to 844408587819 nsecs]
 clock 1:
  .base:       c1497750
  .index:      1
  .resolution: 1 nsecs
  .get_time:   ktime_get_real
  .offset:     0 nsecs
active timers:
 clock 2:
  .base:       c1497788
  .index:      2
  .resolution: 1 nsecs
  .get_time:   ktime_get_boottime
  .offset:     0 nsecs
active timers:
 clock 3:
  .base:       c14977c0
  .index:      3
  .resolution: 1 nsecs
  .get_time:   ktime_get_clocktai
  .offset:     0 nsecs
active timers:
  .expires_next   : 55600000000 nsecs
  .hres_active    : 1
  .nr_events      : 921
  .nr_retries     : 20
  .nr_hangs       : 0
  .max_hang_time  : 0 nsecs
  .nohz_mode      : 2
  .last_tick      : 55590000000 nsecs
  .tick_stopped   : 0
  .idle_jiffies   : 4294942854
  .idle_calls     : 1482
  .idle_sleeps    : 234
  .idle_entrytime : 55584131929 nsecs
  .idle_waketime  : 55584058200 nsecs
  .idle_exittime  : 55584131929 nsecs
  .idle_sleeptime : 53182424229 nsecs
  .iowait_sleeptime: 0 nsecs
  .last_jiffies   : 4294942854
  .next_jiffies   : 4294949632
  .idle_expires   : 56520692335 nsecs
jiffies: 4294942855

Tick Device: mode:     1
Broadcast device
Clock Event Device: ttc_clockevent
 max_delta_ns:   1207932479
 min_delta_ns:   18432
 mult:           233015
 shift:          32
 mode:           3
 next_event:     9223372036854775807 nsecs
 set_next_event: ttc_set_next_event
 set_mode:       ttc_set_mode
 event_handler:  tick_handle_oneshot_broadcast
 retries:        5

tick_broadcast_mask: 00000003
tick_broadcast_oneshot_mask: 00000000

Tick Device: mode:     1
Per CPU device: 0
Clock Event Device: local_timer
 max_delta_ns:   12884902005
 min_delta_ns:   1000
 mult:           715827876
 shift:          31
 mode:           3
 next_event:     55592004140 nsecs
 set_next_event: twd_set_next_event
 set_mode:       twd_set_mode
 event_handler:  hrtimer_interrupt
 retries:        0

Tick Device: mode:     1
Per CPU device: 1
Clock Event Device: local_timer
 max_delta_ns:   12884902005
 min_delta_ns:   1000
 mult:           715827876
 shift:          31
 mode:           3
 next_event:     55600000000 nsecs
 set_next_event: twd_set_next_event
 set_mode:       twd_set_mode
 event_handler:  hrtimer_interrupt
 retries:        0

#

-------------- next part --------------
# cat /proc/timer_list 
Timer List Version: v0.7
HRTIMER_MAX_CLOCK_BASES: 4
now at 246603578154 nsecs

cpu: 0
 clock 0:
  .base:       c148e718
  .index:      0
  .resolution: 1 nsecs
  .get_time:   ktime_get
  .offset:     0 nsecs
active timers:
 #0: <c1490670>, menu_hrtimer_notify, S:01, hrtimer_start, swapper/0/0
 # expires at 246603698006-246603698006 nsecs [in 120539 to 120539 nsecs]
 #1: <c148eac8>, tick_sched_timer, S:01, hrtimer_start, swapper/0/0
 # expires at 252080000000-252080000000 nsecs [in 5476422533 to 5476422533 nsecs]
 #2: <ed9faa80>, timerfd_tmrproc, S:01, hrtimer_start, systemd/1
 # expires at 900000053569-900000053569 nsecs [in 653396476102 to 653396476102 nsecs]
 clock 1:
  .base:       c148e750
  .index:      1
  .resolution: 1 nsecs
  .get_time:   ktime_get_real
  .offset:     0 nsecs
active timers:
 clock 2:
  .base:       c148e788
  .index:      2
  .resolution: 1 nsecs
  .get_time:   ktime_get_boottime
  .offset:     0 nsecs
active timers:
 clock 3:
  .base:       c148e7c0
  .index:      3
  .resolution: 1 nsecs
  .get_time:   ktime_get_clocktai
  .offset:     0 nsecs
active timers:
  .expires_next   : 246603871523 nsecs
  .hres_active    : 1
  .nr_events      : 935
  .nr_retries     : 0
  .nr_hangs       : 0
  .max_hang_time  : 0 nsecs
  .nohz_mode      : 2
  .last_tick      : 246600000000 nsecs
  .tick_stopped   : 1
  .idle_jiffies   : 4294961955
  .idle_calls     : 1974
  .idle_sleeps    : 259
  .idle_entrytime : 246603709947 nsecs
  .idle_waketime  : 246603700671 nsecs
  .idle_exittime  : 246594690344 nsecs
  .idle_sleeptime : 243604071460 nsecs
  .iowait_sleeptime: 0 nsecs
  .last_jiffies   : 4294961956
  .next_jiffies   : 4294962504
  .idle_expires   : 252080000000 nsecs
jiffies: 4294961956

cpu: 1
 clock 0:
  .base:       c1497718
  .index:      0
  .resolution: 1 nsecs
  .get_time:   ktime_get
  .offset:     0 nsecs
active timers:
 #0: <c1497ac8>, tick_sched_timer, S:01, hrtimer_start_range_ns, swapper/1/0
 # expires at 246610000000-246610000000 nsecs [in 6422533 to 6422533 nsecs]
 clock 1:
  .base:       c1497750
  .index:      1
  .resolution: 1 nsecs
  .get_time:   ktime_get_real
  .offset:     0 nsecs
active timers:
 clock 2:
  .base:       c1497788
  .index:      2
  .resolution: 1 nsecs
  .get_time:   ktime_get_boottime
  .offset:     0 nsecs
active timers:
 clock 3:
  .base:       c14977c0
  .index:      3
  .resolution: 1 nsecs
  .get_time:   ktime_get_clocktai
  .offset:     0 nsecs
active timers:
  .expires_next   : 246610000000 nsecs
  .hres_active    : 1
  .nr_events      : 882
  .nr_retries     : 0
  .nr_hangs       : 0
  .max_hang_time  : 0 nsecs
  .nohz_mode      : 2
  .last_tick      : 245680000000 nsecs
  .tick_stopped   : 0
  .idle_jiffies   : 4294961863
  .idle_calls     : 1405
  .idle_sleeps    : 272
  .idle_entrytime : 246596515784 nsecs
  .idle_waketime  : 244320007598 nsecs
  .idle_exittime  : 246593639546 nsecs
  .idle_sleeptime : 243941063708 nsecs
  .iowait_sleeptime: 0 nsecs
  .last_jiffies   : 4294961955
  .next_jiffies   : 4294961956
  .idle_expires   : 361550000000 nsecs
jiffies: 4294961956

Tick Device: mode:     1
Broadcast device
Clock Event Device: arm_global_timer
 max_delta_ns:   12884902005
 min_delta_ns:   1000
 mult:           715827876
 shift:          31
 mode:           1
 next_event:     9223372036854775807 nsecs
 set_next_event: gt_clockevent_set_next_event
 set_mode:       gt_clockevent_set_mode
 event_handler:  tick_handle_oneshot_broadcast
 retries:        0

tick_broadcast_mask: 00000000
tick_broadcast_oneshot_mask: 00000000

Tick Device: mode:     1
Per CPU device: 0
Clock Event Device: local_timer
 max_delta_ns:   12884902005
 min_delta_ns:   1000
 mult:           715827876
 shift:          31
 mode:           3
 next_event:     246604040852 nsecs
 set_next_event: twd_set_next_event
 set_mode:       twd_set_mode
 event_handler:  hrtimer_interrupt
 retries:        0

Tick Device: mode:     1
Per CPU device: 1
Clock Event Device: local_timer
 max_delta_ns:   12884902005
 min_delta_ns:   1000
 mult:           715827876
 shift:          31
 mode:           3
 next_event:     246610000000 nsecs
 set_next_event: twd_set_next_event
 set_mode:       twd_set_mode
 event_handler:  hrtimer_interrupt
 retries:        0

## 


From swarren at wwwdotorg.org  Tue Jul 30 18:26:15 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 16:26:15 -0600
Subject: Defining schemas for Device Tree
In-Reply-To: <3852729.INDSeEDz7b@thinkpad>
References: <2469263.vMN09Q7Tzi@flatron> <3852729.INDSeEDz7b@thinkpad>
Message-ID: <51F83D87.2010707@wwwdotorg.org>

On 07/30/2013 04:16 PM, Tomasz Figa wrote:
> On Monday 29 of July 2013 02:21:52 Tomasz Figa wrote:
>> Hi,
>>
>> As promised I am starting a discussion about Device Tree schema. Let's
>> first shortly introduce the problem.
>>
>> Device Tree is a text-based data structure used to describe hardware. Its
>> main point is separation from kernel code, which has a lot of benefits,
>> but, at the moment, also a huge drawback - there is no verification of
>> device tree sources against defined bindings. All the dtc compiler does
>> currently are syntax checks - no semantic analysis is performed (except
>> some really basic things). What this means is that anybody can put
>> anything in their device tree and end up with the dts compiling fine only
>> to find out that something is wrong at boot time.
>>
>> Currently, device tree bindings are described in plain text documentation
>> files, which can not be considered a formal way of binding description.
>> While such documentation provides information for developers/users that
>> need to work with particular bindings, it can not be easily used as input
>> for validation of device tree sources. This means that we need to define a
>> more formal way of binding description, in other words - Device Tree
>> schema.
>>
>> To find a solution for this problem, we must first answer several
>> questions to determine a set of requirements we have to meet.
>>
>> a) What is a device tree binding?
>>
>> For our purposes, I will define a binding as internal format of some
>> device tree node, which can be matched using of_find_matching_node(). In
>> other words, key for a binding would be node name and/or value of
>> compatible property and/or node type. Value for a binding would be a list
>> of properties with their formats and/or subnodes with their bindings.
> 
> Now as I think of it, there is one more thing that needs to be considered. Do 
> we want the schemas to strictly specify available set of properties, warning 
> about any unrecognized ones or just enforce checking of recognized properties 
> (including presence of required ones)? Or maybe both, depending on some 
> keyword or whatever?

I think one of the use-cases that having schema validation was asked to
cover was the case of a typo in a property name leading to that property
having no effect. This could only be caught by the validation tool if it
warned (or worse) about unknown properties.


From mturquette at linaro.org  Tue Jul 30 18:35:35 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 30 Jul 2013 15:35:35 -0700
Subject: [PATCH v4 6/8] wlcore: sdio: add wilink clock providers
In-Reply-To: <1375189476-21557-7-git-send-email-coelho@ti.com>
References: <1375189476-21557-1-git-send-email-coelho@ti.com>
 <1375189476-21557-7-git-send-email-coelho@ti.com>
Message-ID: <20130730223535.5270.39864@quantum>

Quoting Luciano Coelho (2013-07-30 06:04:34)
> +static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
> +       { .compatible = "ti,wilink-clock" },
> +};
> +
>  static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
>  {
>         struct wl12xx_platform_data *pdata;
>         struct device_node *np = dev->of_node;
> +       struct device_node *clock_node;
>  
>         if (!np) {
>                 np = of_find_matching_node(NULL, dev->driver->of_match_table);
> @@ -241,6 +247,9 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
>                 goto out_free;
>         }
>  
> +       for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
> +               of_fixed_clk_setup(clock_node);

Hi Luciano,

Any reason for establishing your own compatible string if you just plan
to use the fixed rate clock? You could just use "fixed-clock" compatible
in your DTS.

I will be posting patches this week which makes the fixed-rate clock a
proper driver and matches that compatible string to instantiate those
clocks. That means that your driver could probably remove the clock
setup code completely.

Regards,
Mike

> +
>         goto out;
>  
>  out_free:
> -- 
> 1.8.3.2


From scottwood at freescale.com  Tue Jul 30 18:40:11 2013
From: scottwood at freescale.com (Scott Wood)
Date: Tue, 30 Jul 2013 17:40:11 -0500
Subject: [4/4] Added device tree entries for Legerity SLIC node on
 various Freescale Platforms
In-Reply-To: <1362655668-26721-4-git-send-email-Sandeep@freescale.com>
References: <1362655668-26721-4-git-send-email-Sandeep@freescale.com>
Message-ID: <20130730224011.GA15915@home.buserror.net>

On Thu, Mar 07, 2013 at 04:57:48PM +0530, Sandeep Singh wrote:
> diff --git a/arch/powerpc/boot/dts/p1024rdb.dtsi b/arch/powerpc/boot/dts/p1024rdb.dtsi
> index b05dcb4..cec36a3 100644
> --- a/arch/powerpc/boot/dts/p1024rdb.dtsi
> +++ b/arch/powerpc/boot/dts/p1024rdb.dtsi
> @@ -164,6 +164,19 @@
>  				label = "SPI JFFS2 RFS";
>  			};
>  		};
> +
> +                tdm_phy_0: slic at 0 {
> +                        compatible = "zarlink,le88266", "tdm-phy-slic";
> +			reg = <1>;
> +			spi-max-frequency = <8000000>;
> +		};
> +
> +                tdm_phy_1: slic at 1 {
> +                        compatible = "zarlink,le88266", "tdm-phy-slic";
> +			reg = <2>;
> +			spi-max-frequency = <8000000>;
> +		};
> +
>  	};
>  
>  	i2c at 3000 {
> @@ -173,6 +186,11 @@
>  		};
>  	};
>  
> +        tdm at 16000 {
> +                num-phy = <2>;
> +                phy-handle = <&tdm_phy_0>, <&tdm_phy_1>;
> +        };
> +
>  	usb at 22000 {
>  		phy_type = "ulpi";
>  	};

Whitespace

What is "tdm-phy-slic"?  "num-phy"?  Document these in the binding and
use proper vendor prefixes.

Why "<&tdm_phy_0>, <&tdm_phy_1>" rather than "<&tdm_phy_0 &tdm_phy_1>"? 
And can you just use the length of phy-handle rather than having a
separate num-phy property?

-Scott
 



From swarren at wwwdotorg.org  Tue Jul 30 18:49:18 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 16:49:18 -0600
Subject: [PATCH] ARM: allow DEBUG_UNCOMPRESS for omap2plus
Message-ID: <1375224558-8170-1-git-send-email-swarren@wwwdotorg.org>

From: Stephen Warren <swarren at nvidia.com>

DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to
omap2plus.S's use of .data, which is not allowed in the decompressor.
Solve this by placing that data into .text when building the file into
the decompressor. This relies on .text actually being writable in the
decompressor, which it is in practice.

Cc: Shawn Guo <shawn.guo at linaro.org>
Signed-off-by: Stephen Warren <swarren at nvidia.com>
---
Note that I have build-tested this with omap2plus_defconfig, but not
run-time tested it in any way.
---
 arch/arm/Kconfig.debug             | 2 +-
 arch/arm/include/debug/omap2plus.S | 4 ++++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index d8ff7f7..8eb04b1 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1046,7 +1046,7 @@ config DEBUG_UART_8250_FLOW_CONTROL
 config DEBUG_UNCOMPRESS
 	bool
 	depends on ARCH_MULTIPLATFORM
-	default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART
+	default y if DEBUG_LL
 	help
 	  This option influences the normal decompressor output for
 	  multiplatform kernels.  Normally, multiplatform kernels disable
diff --git a/arch/arm/include/debug/omap2plus.S b/arch/arm/include/debug/omap2plus.S
index 6d867ae..364ae35 100644
--- a/arch/arm/include/debug/omap2plus.S
+++ b/arch/arm/include/debug/omap2plus.S
@@ -58,11 +58,15 @@
 
 #define UART_OFFSET(addr)	((addr) & 0x00ffffff)
 
+#if !defined(ZIMAGE)
 		.pushsection .data
+#endif
 omap_uart_phys:	.word	0
 omap_uart_virt:	.word	0
 omap_uart_lsr:	.word	0
+#if !defined(ZIMAGE)
 		.popsection
+#endif
 
 		.macro	addruart, rp, rv, tmp
 
-- 
1.8.1.5



From linux at arm.linux.org.uk  Tue Jul 30 18:52:33 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 30 Jul 2013 23:52:33 +0100
Subject: [PATCH] ARM: allow DEBUG_UNCOMPRESS for omap2plus
In-Reply-To: <1375224558-8170-1-git-send-email-swarren@wwwdotorg.org>
References: <1375224558-8170-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <20130730225233.GF21614@n2100.arm.linux.org.uk>

On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to
> omap2plus.S's use of .data, which is not allowed in the decompressor.
> Solve this by placing that data into .text when building the file into
> the decompressor. This relies on .text actually being writable in the
> decompressor, which it is in practice.

Unless you decide to use ZBOOT and flash the zImage.


From broonie at kernel.org  Tue Jul 30 18:58:45 2013
From: broonie at kernel.org (Mark Brown)
Date: Tue, 30 Jul 2013 23:58:45 +0100
Subject: [PATCH v6 2/8] ASoC: atmel: machine driver for at91sam9x5-wm8731
 boards
In-Reply-To: <51F8302D.406@wwwdotorg.org>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
 <1375180329-4860-3-git-send-email-richard.genoud@gmail.com>
 <51F7FBA8.6080400@wwwdotorg.org>
 <20130730204511.GX9858@sirena.org.uk> <51F8302D.406@wwwdotorg.org>
Message-ID: <20130730225845.GB9858@sirena.org.uk>

On Tue, Jul 30, 2013 at 03:29:17PM -0600, Stephen Warren wrote:
> On 07/30/2013 02:45 PM, Mark Brown wrote:

> > You really shouldn't do this, it's not accomplishing much.

> What it accomplishes is not polluting the CODEC's binding with a set
> of strings that must always be supported since DT is an ABI. The
> strings are isolated into the specific audio complex binding, which
> might possibly become deprecated and replaced with something better
> and more generic.

You seem to be assuming that the strings are a bad thing.  I'm not sure
that this is the case modulo the tooling issues...

Besides the reality is that we're using strings right now and they're
being baked into bindings right now, I can't see anything being saved by
listing them in the board binding rather than in the CODEC binding since
both are ABIs especially once you get to the second board binding.  The
ship has sailed on that one.  

All the CODEC binding does is say "there are pins called this", it's up
to some other binding to define how they're used and the CODEC binding
can always add extra information to that list, including a mapping to
integers.

> > The above is going to be legibility challenged without defines at
> > which point the strings end up appearing in the binding document
> > anyway.

> Yes, you'd certainly have to use defines not raw integers. The strings
> wouldn't appear in the binding doc so much as the numbers.

The strings would be there in the text explaining what the numbers mean
- whatever happens the pin names are going to be physically present in
the document, it's just a formatting difference.  The CODEC document
has to list all the pins, we're not going to avoid that by defining a
mapping to integers since adding the integers will in some way end up
defining the names even if just as part of the name of a constant.

We could start adding the integers right now - something like:

	The X CODEC has the following numbered input and output pins:

		1. HPOUTL
		2. HPOUTR
		...

	(see datasheet for details), a header file is provided with
	constants X_PIN_foo for convenience.

would work with either approach to identifying the pins or if we're
being less verbose and just reference the header file for the
definitions that becomes something like:

	The X CODEC has input and output pins listed with numerical
	identifiers in the form the X_PIN_foo defined in the X.h header
	file where foo is the name of the pin.

(that's not good boilerplate wording but you get my drift) which still
ends up defining a set of known strings for pins.

In fact now that I think about this why don't we just go ahead and do
all this, starting by putting the numbers into the bindings for the
CODECs since that's the simplest thing and doesn't involve writing code?
I even have several boards on my desk that run DT ASoC...
-------------- 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/20130730/e03ac78f/attachment.sig>

From swarren at wwwdotorg.org  Tue Jul 30 19:01:27 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 30 Jul 2013 17:01:27 -0600
Subject: [PATCH] ARM: allow DEBUG_UNCOMPRESS for omap2plus
In-Reply-To: <20130730225233.GF21614@n2100.arm.linux.org.uk>
References: <1375224558-8170-1-git-send-email-swarren@wwwdotorg.org>
 <20130730225233.GF21614@n2100.arm.linux.org.uk>
Message-ID: <51F845C7.8020106@wwwdotorg.org>

On 07/30/2013 04:52 PM, Russell King - ARM Linux wrote:
> On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote:
>> From: Stephen Warren <swarren at nvidia.com>
>>
>> DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to
>> omap2plus.S's use of .data, which is not allowed in the decompressor.
>> Solve this by placing that data into .text when building the file into
>> the decompressor. This relies on .text actually being writable in the
>> decompressor, which it is in practice.
> 
> Unless you decide to use ZBOOT and flash the zImage.

I knew there had to be a catch:-)

I have no idea if ZBOOT is a use-case that's relevant to OMAP?

On Tegra at least (the same issue applies to the other patch I just
sent), that use-case is almost impossible; even if the boot ROM directly
booted a kernel, the boot ROM is hard-coded to copy whatever it's
booting to SDRAM first, although I suppose if that was a boot-loader it
could just jump back to a ROM location. That said, NOR flash is
extremely rare on Tegra. So, I don't know if we care about this issue.

Is it reasonable to just say "If you use ZBOOT, don't enable
DEBUG_UNCOMPRESS"? Perhaps these patches should not completely remove
the !DEBUG_TEGRA_UART from config DEBUG_UNCOMPRESS, but instead say:

default y if DEBUG_LL && (!DEBUG_TEGRA_UART || !ZBOOT)?


From mturquette at linaro.org  Tue Jul 30 19:03:24 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 30 Jul 2013 16:03:24 -0700
Subject: [PATCH RESEND] clk: export __clk_get_flags for modular clock
 providers
In-Reply-To: <51D5DEE7.2070400@ti.com>
References: <1366009186-32199-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <51D5DEE7.2070400@ti.com>
Message-ID: <20130730230324.5270.4519@quantum>

Quoting Luciano Coelho (2013-07-04 13:45:27)
> Hi,
> 
> On 04/15/2013 09:59 AM, Sebastian Hesselbarth wrote:
> > The common clock api provides some helpers for clk-providers but does
> > not export these helpers. This hinders clk-providers to be built as modules.
> > This patch adds __clk_get_flags() to the list of exported symbols.
> >
> > Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> > ---
> > Cc: Mike Turquette <mturquette at linaro.org>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: linux-kernel at vger.kernel.org
> > ---
> >   drivers/clk/clk.c |    1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index ed87b24..3e478b8 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -450,6 +450,7 @@ unsigned long __clk_get_flags(struct clk *clk)
> >   {
> >       return !clk ? 0 : clk->flags;
> >   }
> > +EXPORT_SYMBOL_GPL(__clk_get_flags);
> >
> >   bool __clk_is_enabled(struct clk *clk)
> >   {
> >
> 
> I think this got merged slightly wrong.  The EXPORT_SYMBOL_GPL macro 
> came under clk_unprepare_unused_subtree() instead of under 
> __clk_get_flags():
> 
> 
> Of course this is not that important, but it's a bit confusing when you 
> look at the code.

Thanks for pointing this out. I've fixed it up.

Regards,
Mike

> 
> --
> Cheers,
> Luca.


From broonie at kernel.org  Tue Jul 30 19:03:31 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 31 Jul 2013 00:03:31 +0100
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4Ox7-6Jf0ce64Wqr5E49KS+9E135mqc_iG-PWQ7r8bzWHA@mail.gmail.com>
References: <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <20130730205716.GZ9858@sirena.org.uk>
 <CAKON4Ox7-6Jf0ce64Wqr5E49KS+9E135mqc_iG-PWQ7r8bzWHA@mail.gmail.com>
Message-ID: <20130730230331.GC9858@sirena.org.uk>

On Tue, Jul 30, 2013 at 06:19:08PM -0400, jonsmirl at gmail.com wrote:

> FDT is versioned and PowerPC docs say that multiple versions have been
> released.  If we find enough flaws we could do a new release then use
> the quirks scheme to read the older versions.

That does involve updating everything that wants to understand FDTs in
the new FDT format version though.  I'm not sure that's going to be
greeted with universal enthusiasm.
-------------- 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/20130731/af092b57/attachment-0001.sig>

From coelho at ti.com  Tue Jul 30 19:04:26 2013
From: coelho at ti.com (Luciano Coelho)
Date: Wed, 31 Jul 2013 02:04:26 +0300
Subject: [PATCH v4 6/8] wlcore: sdio: add wilink clock providers
In-Reply-To: <20130730223535.5270.39864@quantum>
References: <1375189476-21557-1-git-send-email-coelho@ti.com>
 <1375189476-21557-7-git-send-email-coelho@ti.com>
 <20130730223535.5270.39864@quantum>
Message-ID: <1375225466.30009.7.camel@cumari.coelho.fi>

On Tue, 2013-07-30 at 15:35 -0700, Mike Turquette wrote:
> Quoting Luciano Coelho (2013-07-30 06:04:34)
> > +static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
> > +       { .compatible = "ti,wilink-clock" },
> > +};
> > +
> >  static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
> >  {
> >         struct wl12xx_platform_data *pdata;
> >         struct device_node *np = dev->of_node;
> > +       struct device_node *clock_node;
> >  
> >         if (!np) {
> >                 np = of_find_matching_node(NULL, dev->driver->of_match_table);
> > @@ -241,6 +247,9 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
> >                 goto out_free;
> >         }
> >  
> > +       for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
> > +               of_fixed_clk_setup(clock_node);
> 
> Hi Luciano,

Hi Mike,


> Any reason for establishing your own compatible string if you just plan
> to use the fixed rate clock? You could just use "fixed-clock" compatible
> in your DTS.

The reason is that I can't call of_clk_init(), because this function is
not exported and my module can't use it.  I would have to link with the
clk code to be able to call it.

Also, I reckoned that, since these clock cannot be used by anyone else
than the WiLink module itself, it would make sense to have a different
compatible string.


> I will be posting patches this week which makes the fixed-rate clock a
> proper driver and matches that compatible string to instantiate those
> clocks. That means that your driver could probably remove the clock
> setup code completely.

Okay, if this is done, then I could probably use "fixed-clock" directly,
since the driver itself will take care of going through the DT and
initializing all the fixed-clocks.

--
Luca.



From csd at broadcom.com  Tue Jul 30 19:08:27 2013
From: csd at broadcom.com (Christian Daudt)
Date: Tue, 30 Jul 2013 16:08:27 -0700
Subject: [PATCH] bcm53xx: initial support for the BCM5301/BCM470X
 SoC with ARM CPU
In-Reply-To: <51F6A12C.30101@wwwdotorg.org>
References: <2043662.BcW19XTTMG@lenovo> <20130719020611.GA4941@glitch>
 <20130723185733.GB6811@ohporter.com>
 <CAGVrzcYnoN9NnJGvubS7=bVJDk37xSt4BimtvDWghe7OHEWALQ@mail.gmail.com>
 <20130724231106.GB29801@glitch>
 <CAGVrzcYudfgqs_eafje4BT2z2qE0kSJPx1B-xrq0WxtUkGxSFw@mail.gmail.com>
 <20130726000412.GH5022@linaro.org> <51F2F554.8030709@broadcom.com>
 <51F2F885.2040002@wwwdotorg.org>
 <20130729093000.GI3528@e106331-lin.cambridge.arm.com>
 <20130729132029.GI5022@ohporter.com> <51F6A12C.30101@wwwdotorg.org>
Message-ID: <51F8476B.3080508@broadcom.com>

On 13-07-29 10:06 AM, Stephen Warren wrote:
> On 07/29/2013 07:20 AM, Matt Porter wrote:
>> On Mon, Jul 29, 2013 at 10:30:00AM +0100, Mark Rutland wrote:
> ...
>>> I'd be happy to have "broadcom" for all *new* bindings, as it's already
>>> in some bindings alongside "bcm" and "brcm", and is certainly the
>>> clearest of the available options.
>>>
>>> However, given the strong feelings of many against breaking existing
>>> dts, we need to support the existing instances of "bcm" and "brcm" in
>> Whoa, how would existing dts break? At this instant in time, all the
>> bindings and dts are still in the kernel tree. A series to address this
>> make all bindings, drivers, and dts consistent in one shot.
> While there are some *.dts files in the kernel source tree, that is no
> guarantee that:
>
> a) People don't have custom *.dts files that are not in the kernel
> source tree, and hence can't be updated by Linux kernel patches.
>
> b) People actually replace their *.dtb when updating their zImage. Since
> DT is explicitly supposed to be an ABI, everything is explicitly
> supposed to work if they do only update their zImage and not their *.dtb.
>
In the interest of maintaining compatibility, we've discussed this 
internally @ Broadcom and we'll be standardizing on brcm vendor prefix 
going forward (at least the 2 teams represented in this thread...). 
Given that I am responsible for all of the current offending uses of 
"bcm," in dt bindings, and I can assure that switching them at this 
point causes no damage to the platforms (as the kernel tree being 
upstreamed is not yet being used internally), I'll follow up with a 
patch to switch these "bcm," uses into "brcm,".
  Going forward, our new drivers will switch to brcm, prior to being 
submitted upstream. With that, we can safely remove all vestiges of 
"bcm," dt prefix.

  Thanks,
    csd




From aaro.koskinen at iki.fi  Tue Jul 30 19:11:20 2013
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Wed, 31 Jul 2013 02:11:20 +0300
Subject: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit
 mitigations
In-Reply-To: <20130730221435.GA22240@redhat.com>
References: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
 <20130730221435.GA22240@redhat.com>
Message-ID: <20130730231120.GC30725@blackmetal.musicnaut.iki.fi>

Hi,

On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
> On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
>  > - fuzzing (is anyone running trinity or similar on the ARM tree?)
>  
> Someone was kind enough to send me an arm chromebook, so I tried this just
> last week (albeit, on the 3.4 kernel it shipped with). The results make
> me think the answer is a resounding 'no'.

Shouldn't you run trinity only under QEMU or similar virtual
environment? Don't know about chromebook, but on some of my ARM boards
a misbehaving kernel could at least in theory brick the board...

A.


From davej at redhat.com  Tue Jul 30 19:15:33 2013
From: davej at redhat.com (Dave Jones)
Date: Tue, 30 Jul 2013 19:15:33 -0400
Subject: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit
 mitigations
In-Reply-To: <20130730231120.GC30725@blackmetal.musicnaut.iki.fi>
References: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
 <20130730221435.GA22240@redhat.com>
 <20130730231120.GC30725@blackmetal.musicnaut.iki.fi>
Message-ID: <20130730231533.GA26824@redhat.com>

On Wed, Jul 31, 2013 at 02:11:20AM +0300, Aaro Koskinen wrote:
 > Hi,
 > 
 > On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
 > > On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
 > >  > - fuzzing (is anyone running trinity or similar on the ARM tree?)
 > >  
 > > Someone was kind enough to send me an arm chromebook, so I tried this just
 > > last week (albeit, on the 3.4 kernel it shipped with). The results make
 > > me think the answer is a resounding 'no'.
 > 
 > Shouldn't you run trinity only under QEMU or similar virtual
 > environment? Don't know about chromebook, but on some of my ARM boards
 > a misbehaving kernel could at least in theory brick the board...
 
I like to live dangerously.  Don't imitate everything you see on TV,
or read about on lkml.

More seriously, that's true if you're running trinity as root, which
yes, I usually advise people only do in qemu etc.

If you're running it as a regular user and you can brick the board,
you might have bigger problems.

	Dave



From jonsmirl at gmail.com  Tue Jul 30 19:23:36 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Tue, 30 Jul 2013 19:23:36 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <20130730230331.GC9858@sirena.org.uk>
References: <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <20130730205716.GZ9858@sirena.org.uk>
 <CAKON4Ox7-6Jf0ce64Wqr5E49KS+9E135mqc_iG-PWQ7r8bzWHA@mail.gmail.com>
 <20130730230331.GC9858@sirena.org.uk>
Message-ID: <CAKON4OzFdZhX0Kzu_6KiimD=KxDr6EM13zUH3GGE=hHaYx=m=Q@mail.gmail.com>

On Tue, Jul 30, 2013 at 7:03 PM, Mark Brown <broonie at kernel.org> wrote:
> On Tue, Jul 30, 2013 at 06:19:08PM -0400, jonsmirl at gmail.com wrote:
>
>> FDT is versioned and PowerPC docs say that multiple versions have been
>> released.  If we find enough flaws we could do a new release then use
>> the quirks scheme to read the older versions.
>
> That does involve updating everything that wants to understand FDTs in
> the new FDT format version though.  I'm not sure that's going to be
> greeted with universal enthusiasm.

Shipped hardware containing FDTs would keep the version they shipped
with. That's the point of making this  a stable ABI. The Linux quirk
code would convert the older format to the new format at boot time.

So to change this you need to:
1) change dtc to produce the new version
2) adjust the kernel code to understand the new version
3) adjust the quirk code to convert the known set of older firmware
based FDTs into the new format. For the simple string case the strings
would be turned into indirect pointers instead of being in-line.

The only way you could get in trouble would be by upgrading an old
firmware FDT to the new format and then booting an old Linux or
another OS. But this is a general problem not specific to the FDT
versioning - if you replace the firmware FDT with one of the later
Linux ones that has been rewritten, the older stuff isn't going to
boot either since it won't understand the changes.  Simple answer - if
you are going to boot other OSes or old Linux kernels, don't mess with
the firmware FDT that the device shipped with, leave it alone.

Uboot could be an issue but I don't think they are actually doing
anything with FDTs yet, they are just talking about doing it.


-- 
Jon Smirl
jonsmirl at gmail.com


From davem at davemloft.net  Tue Jul 30 19:24:34 2013
From: davem at davemloft.net (David Miller)
Date: Tue, 30 Jul 2013 16:24:34 -0700 (PDT)
Subject: [PATCH v2] net: Add MOXA ART SoCs ethernet driver
In-Reply-To: <1374842890-20735-1-git-send-email-jonas.jensen@gmail.com>
References: <1374140806-12485-1-git-send-email-jonas.jensen@gmail.com>
 <1374842890-20735-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <20130730.162434.539163047913568607.davem@davemloft.net>

From: Jonas Jensen <jonas.jensen at gmail.com>
Date: Fri, 26 Jul 2013 14:48:10 +0200

> +
> +CFLAGS_moxart_ether.o := -DDEBUG

This is not appropriate, please remove this.


From keescook at chromium.org  Tue Jul 30 19:33:38 2013
From: keescook at chromium.org (Kees Cook)
Date: Tue, 30 Jul 2013 16:33:38 -0700
Subject: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit
 mitigations
In-Reply-To: <20130730231533.GA26824@redhat.com>
References: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
 <20130730221435.GA22240@redhat.com>
 <20130730231120.GC30725@blackmetal.musicnaut.iki.fi>
 <20130730231533.GA26824@redhat.com>
Message-ID: <CAGXu5jLQxE14Gy3x20XMyFyUQKwMQ+RU9S24H742cQevEF9Aew@mail.gmail.com>

On Tue, Jul 30, 2013 at 4:15 PM, Dave Jones <davej at redhat.com> wrote:
> On Wed, Jul 31, 2013 at 02:11:20AM +0300, Aaro Koskinen wrote:
>  > Hi,
>  >
>  > On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
>  > > On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
>  > >  > - fuzzing (is anyone running trinity or similar on the ARM tree?)
>  > >
>  > > Someone was kind enough to send me an arm chromebook, so I tried this just
>  > > last week (albeit, on the 3.4 kernel it shipped with). The results make
>  > > me think the answer is a resounding 'no'.
>  >
>  > Shouldn't you run trinity only under QEMU or similar virtual
>  > environment? Don't know about chromebook, but on some of my ARM boards
>  > a misbehaving kernel could at least in theory brick the board...
>
> I like to live dangerously.  Don't imitate everything you see on TV,
> or read about on lkml.
>
> More seriously, that's true if you're running trinity as root, which
> yes, I usually advise people only do in qemu etc.
>
> If you're running it as a regular user and you can brick the board,
> you might have bigger problems.

Exactly, and finding those problems tends to be worth the hardware hassle. :)

-Kees

-- 
Kees Cook
Chrome OS Security


From rjw at sisk.pl  Tue Jul 30 19:48:45 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Wed, 31 Jul 2013 01:48:45 +0200
Subject: Linux Plumbers ACPI/PM, PCI Microconference
In-Reply-To: <CAKocOOOgEb5h1dZWP_2UqBKhSK9U-kxKUbvTdzHfds=RiDzNJg@mail.gmail.com>
References: <CAL-B5D03ki8NHsM6EuESTH2K-Eh+XyFHNXPDYwgDq+oagDjtMQ@mail.gmail.com>
 <CAKocOOOgEb5h1dZWP_2UqBKhSK9U-kxKUbvTdzHfds=RiDzNJg@mail.gmail.com>
Message-ID: <1476124.sWE2ygoo2D@vostro.rjw.lan>

On Wednesday, July 17, 2013 08:31:55 AM Shuah Khan wrote:
> Myron,
> 
> On Tue, Jul 16, 2013 at 8:21 PM, Myron Stowe <myron.stowe at gmail.com> wrote:
> 
> >
> > Shuah - You brought up the idea about "Converting drivers from Legacy
> > PM ops to dev_pm_ops"; would you like to present what you have
> > done/encountered so far?
> >
> 
> Awesome. Yes, I would like to present what I have done so far and I do
> have a couple of things that could benefit from a face to face
> discussion which would help me make progress on the rest of the work
> that needs to get done.

Care to sumbit a formal proposal through the LPC web page?

Rafael



From linus.walleij at linaro.org  Tue Jul 30 19:44:53 2013
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 31 Jul 2013 01:44:53 +0200
Subject: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
In-Reply-To: <CACxGe6uNJNMdZ1HYGgCtLM2t2TWGCR6btjOHVmP=vDXXvvFfRg@mail.gmail.com>
References: <1375101368-17645-1-git-send-email-linus.walleij@linaro.org>
 <CACxGe6uNJNMdZ1HYGgCtLM2t2TWGCR6btjOHVmP=vDXXvvFfRg@mail.gmail.com>
Message-ID: <CACRpkdYjJL6FZwEbB7XLnb9QtjB=3LeE9Ny6KQ4PkM3zpdNqqg@mail.gmail.com>

On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely <grant.likely at linaro.org> wrote:
> On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij <linus.walleij at linaro.org> wrote:
>> To solve this dilemma, perform an interrupt consistency check
>> when adding a GPIO chip: if the chip is both gpio-controller and
>> interrupt-controller, walk all children of the device tree,
>> check if these in turn reference the interrupt-controller, and
>> if they do, loop over the interrupts used by that child and
>> perform gpio_reques() and gpio_direction_input() on these,
>> making them unreachable from the GPIO side.
>
> Ugh, that's pretty awful, and it doesn't actually solve the root
> problem of the GPIO and IRQ subsystems not cooperating. It's also a
> very DT-centric solution even though we're going to see the exact same
> issue on ACPI machines.

The problem is that the patches for OMAP that I applied
and now have had to revert solves it in an even uglier way,
leading to breaking boards, as was noticed.

The approach in this patch has the potential to actually
work without regressing a bunch of boards...

Whether this is a problem in ACPI or not remains to be seen,
but I'm not sure about that. Device trees allows for a GPIO line
to be used as an interrupt source and GPIO line orthogonally,
and that is the root of this problem. Does ACPI have the same
problem, or does it impose natural restrictions on such use
cases?

> We have to solve the problem in a better way than that. Rearranging
> your patch description, here are some of the points you brought up so
> I can comment on them...
>
>> This has the following undesired effects:
>>
>> - The GPIOlib subsystem is not aware that the line is in use
>>   and willingly lets some other consumer perform gpio_request()
>>   on it, leading to a complex resource conflict if it occurs.
>
> If a gpio line is being both requested as a gpio and used as an
> interrupt line, then either a) it's a bug, or b) the gpio line needs
> to be used as input only so it is compatible with irq usage. b) should
> be supportable.

Yes this is what I'm saying too I think...

The bug in (a) manifested itself in the OMAP patch with
no real solution in sight.

>> - The GPIO debugfs file claims this GPIO line is "free".
>
> Surely we can fix this. I still don't see a problem of having the
> controller request the gpio when it is claimed as an irq if we can get
> around the problem of another user performing a /valid/ request on the
> same GPIO line. The solution may be to have a special form of request
> or flag that allows it to be shared.

I don't see how sharing works here, or how another user,
i.e. another one than the user wanting to recieve the IRQ,
can validly request such a line? What would the usecase for
that valid request be?

Basically I believe these two things need to be exclusive in
the DT world:

A: request_irq(a resource passed from "interrupts");
     -> core implicitly performs gpio_request()
         gpio_direction_input()

B: gpio_request(a resource passed from "gpios");
     gpio_direction_input()
     request_irq(gpio_to_irq())

Never both. And IIUC that was what happened in the
OMAP case.

>> - The line direction of the interrupt GPIO line is not
>>   explicitly set as input, even though it is obvious that such
>>   a line need to be set up in this way, often making the system
>>   depend on boot-on defaults for this kind of settings.
>
> Should also be solvable if the gpio request problem is solved.

Agreed...

Yours,
Linus Walleij


From davem at davemloft.net  Tue Jul 30 19:51:33 2013
From: davem at davemloft.net (David Miller)
Date: Tue, 30 Jul 2013 16:51:33 -0700 (PDT)
Subject: [PATCHv2 0/2] net: mvneta: big endian support
In-Reply-To: <1375104088-24654-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1375104088-24654-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20130730.165133.957470552413947516.davem@davemloft.net>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Date: Mon, 29 Jul 2013 15:21:26 +0200

> You'll find in this patch series two small patches that add support
> for big-endian in the mvneta driver, for the network interface found
> in ARM Marvell Armada 370 and Armada XP SOCs. They are based on
> 3.11-rc3.

Both applied to net-next, thanks.


From aaro.koskinen at iki.fi  Tue Jul 30 19:58:34 2013
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Wed, 31 Jul 2013 02:58:34 +0300
Subject: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit
 mitigations
In-Reply-To: <20130730231533.GA26824@redhat.com>
References: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
 <20130730221435.GA22240@redhat.com>
 <20130730231120.GC30725@blackmetal.musicnaut.iki.fi>
 <20130730231533.GA26824@redhat.com>
Message-ID: <20130730235834.GD30725@blackmetal.musicnaut.iki.fi>

Hi,

On Tue, Jul 30, 2013 at 07:15:33PM -0400, Dave Jones wrote:
> On Wed, Jul 31, 2013 at 02:11:20AM +0300, Aaro Koskinen wrote:
>  > On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
>  > > On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
>  > >  > - fuzzing (is anyone running trinity or similar on the ARM tree?)
>  > >  
>  > > Someone was kind enough to send me an arm chromebook, so I tried this just
>  > > last week (albeit, on the 3.4 kernel it shipped with). The results make
>  > > me think the answer is a resounding 'no'.
>  > 
>  > Shouldn't you run trinity only under QEMU or similar virtual
>  > environment? Don't know about chromebook, but on some of my ARM boards
>  > a misbehaving kernel could at least in theory brick the board...
>  
> I like to live dangerously.  Don't imitate everything you see on TV,
> or read about on lkml.

Sadly I have no TV. :)

Anyway, I think it would be interesting to learn about arch-specific
bugs discovered with trinity. Quickly thinking, the results should be
mostly same regardless of the architecture since the code being tested
is generic especially when running as a regular user. But of course
there are 32/64-bit and big-endian/little-endian and such differences,
and maybe some permission bugs (likely in vendor kernels).

A.


From hpa at zytor.com  Tue Jul 30 20:01:37 2013
From: hpa at zytor.com (H. Peter Anvin)
Date: Tue, 30 Jul 2013 17:01:37 -0700
Subject: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit
 mitigations
In-Reply-To: <CAGXu5jLQxE14Gy3x20XMyFyUQKwMQ+RU9S24H742cQevEF9Aew@mail.gmail.com>
References: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
 <20130730221435.GA22240@redhat.com>
 <20130730231120.GC30725@blackmetal.musicnaut.iki.fi>
 <20130730231533.GA26824@redhat.com>
 <CAGXu5jLQxE14Gy3x20XMyFyUQKwMQ+RU9S24H742cQevEF9Aew@mail.gmail.com>
Message-ID: <51F853E1.2080808@zytor.com>

On 07/30/2013 04:33 PM, Kees Cook wrote:
>>
>> If you're running it as a regular user and you can brick the board,
>> you might have bigger problems.
> 
> Exactly, and finding those problems tends to be worth the hardware hassle. :)
> 

Even as root the number of things allowed to brick the hardware is quite
small.  Call it destructive testing.

	-hpa




From shuah.kh at samsung.com  Tue Jul 30 20:02:46 2013
From: shuah.kh at samsung.com (Shuah Khan)
Date: Wed, 31 Jul 2013 00:02:46 +0000
Subject: Linux Plumbers ACPI/PM, PCI Microconference
References: <CAL-B5D03ki8NHsM6EuESTH2K-Eh+XyFHNXPDYwgDq+oagDjtMQ@mail.gmail.com>
 <CAKocOOOgEb5h1dZWP_2UqBKhSK9U-kxKUbvTdzHfds=RiDzNJg@mail.gmail.com>
 <1476124.sWE2ygoo2D@vostro.rjw.lan>
Message-ID: <B8EFE96D1287C24090BAD9D858E15E6174F0B5@sisaex01sj>

On 07/30/2013 05:38 PM, Rafael J. Wysocki wrote:
> On Wednesday, July 17, 2013 08:31:55 AM Shuah Khan wrote:
>> Myron,
>>
>> On Tue, Jul 16, 2013 at 8:21 PM, Myron Stowe <myron.stowe at gmail.com> wrote:
>>
>>>
>>> Shuah - You brought up the idea about "Converting drivers from Legacy
>>> PM ops to dev_pm_ops"; would you like to present what you have
>>> done/encountered so far?
>>>
>>
>> Awesome. Yes, I would like to present what I have done so far and I do
>> have a couple of things that could benefit from a face to face
>> discussion which would help me make progress on the rest of the work
>> that needs to get done.
>
> Care to sumbit a formal proposal through the LPC web page?
>
> Rafael
>
>

Rafael,

I did submit a formal talk proposal to LinuxCon/LPC and it was rejected. 
Submission is closed now as far as I know.

-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research 
America (Silicon Valley) shuah.kh at samsung.com | (970) 672-0658


From davej at redhat.com  Tue Jul 30 20:04:44 2013
From: davej at redhat.com (Dave Jones)
Date: Tue, 30 Jul 2013 20:04:44 -0400
Subject: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit
 mitigations
In-Reply-To: <20130730235834.GD30725@blackmetal.musicnaut.iki.fi>
References: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
 <20130730221435.GA22240@redhat.com>
 <20130730231120.GC30725@blackmetal.musicnaut.iki.fi>
 <20130730231533.GA26824@redhat.com>
 <20130730235834.GD30725@blackmetal.musicnaut.iki.fi>
Message-ID: <20130731000444.GC1281@redhat.com>

On Wed, Jul 31, 2013 at 02:58:34AM +0300, Aaro Koskinen wrote:

 > Anyway, I think it would be interesting to learn about arch-specific
 > bugs discovered with trinity. Quickly thinking, the results should be
 > mostly same regardless of the architecture since the code being tested
 > is generic especially when running as a regular user. But of course
 > there are 32/64-bit and big-endian/little-endian and such differences,
 > and maybe some permission bugs (likely in vendor kernels).

To use ARM as an example, the bugs I've seen have mostly been in arch specific
code that does things like page-table manipulation.  The chromebook bugs I
was hitting for eg were various kinds of PTE corruption warnings. 

ISTR the ia64 & sparc64 bugs it discovered long ago were also due to
things like missing cache flushes, as well as trivial fence-post errors.

	Dave



From emilio at elopez.com.ar  Tue Jul 30 20:14:14 2013
From: emilio at elopez.com.ar (=?ISO-8859-1?Q?Emilio_L=F3pez?=)
Date: Tue, 30 Jul 2013 21:14:14 -0300
Subject: [PATCH 1/4] clk: sunxi: Rename the structure to prepare the
 addition of sun6i
In-Reply-To: <1375195462-19566-2-git-send-email-maxime.ripard@free-electrons.com>
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375195462-19566-2-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <51F856D6.2050504@elopez.com.ar>

Hi Maxime,

El 30/07/13 11:44, Maxime Ripard escribi?:
> Rename all the generic-named structure to sun4i to avoid confusion when
> we will introduce the sun6i (A31) clocks.
> 
> While we're at it, avoid too long lines and wrap the DT compatibles
> tables.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Overall the patch looks good :)

> ---
>  drivers/clk/sunxi/clk-sunxi.c | 108 +++++++++++++++++++++++++++++-------------
>  1 file changed, 75 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index fe1528e..3c91888 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -25,12 +25,12 @@
>  static DEFINE_SPINLOCK(clk_lock);
>  
>  /**
> - * sunxi_osc_clk_setup() - Setup function for gatable oscillator
> + * sun4i_osc_clk_setup() - Setup function for gatable oscillator
>   */
>  
>  #define SUNXI_OSC24M_GATE	0
>  
> -static void __init sunxi_osc_clk_setup(struct device_node *node)
> +static void __init sun4i_osc_clk_setup(struct device_node *node)
>  {
>  	struct clk *clk;
>  	struct clk_fixed_rate *fixed;
> @@ -73,13 +73,13 @@ static void __init sunxi_osc_clk_setup(struct device_node *node)
>  
>  
>  /**
> - * sunxi_get_pll1_factors() - calculates n, k, m, p factors for PLL1
> + * sun4i_get_pll1_factors() - calculates n, k, m, p factors for PLL1
>   * PLL1 rate is calculated as follows
>   * rate = (parent_rate * n * (k + 1) >> p) / (m + 1);
>   * parent_rate is always 24Mhz
>   */
>  
> -static void sunxi_get_pll1_factors(u32 *freq, u32 parent_rate,
> +static void sun4i_get_pll1_factors(u32 *freq, u32 parent_rate,
>  				   u8 *n, u8 *k, u8 *m, u8 *p)
>  {
>  	u8 div;
> @@ -127,12 +127,12 @@ static void sunxi_get_pll1_factors(u32 *freq, u32 parent_rate,
>  
>  
>  /**
> - * sunxi_get_apb1_factors() - calculates m, p factors for APB1
> + * sun4i_get_apb1_factors() - calculates m, p factors for APB1
>   * APB1 rate is calculated as follows
>   * rate = (parent_rate >> p) / (m + 1);
>   */
>  
> -static void sunxi_get_apb1_factors(u32 *freq, u32 parent_rate,
> +static void sun4i_get_apb1_factors(u32 *freq, u32 parent_rate,
>  				   u8 *n, u8 *k, u8 *m, u8 *p)
>  {
>  	u8 calcm, calcp;
> @@ -178,7 +178,7 @@ struct factors_data {
>  	void (*getter) (u32 *rate, u32 parent_rate, u8 *n, u8 *k, u8 *m, u8 *p);
>  };
>  
> -static struct clk_factors_config pll1_config = {
> +static struct clk_factors_config sun4i_pll1_config = {
>  	.nshift = 8,
>  	.nwidth = 5,
>  	.kshift = 4,
> @@ -189,21 +189,21 @@ static struct clk_factors_config pll1_config = {
>  	.pwidth = 2,
>  };
>  
> -static struct clk_factors_config apb1_config = {
> +static struct clk_factors_config sun4i_apb1_config = {
>  	.mshift = 0,
>  	.mwidth = 5,
>  	.pshift = 16,
>  	.pwidth = 2,
>  };
>  
> -static const __initconst struct factors_data pll1_data = {
> -	.table = &pll1_config,
> -	.getter = sunxi_get_pll1_factors,
> +static const __initconst struct factors_data sun4i_pll1_data = {
> +	.table = &sun4i_pll1_config,
> +	.getter = sun4i_get_pll1_factors,
>  };
>  
> -static const __initconst struct factors_data apb1_data = {
> -	.table = &apb1_config,
> -	.getter = sunxi_get_apb1_factors,
> +static const __initconst struct factors_data sun4i_apb1_data = {
> +	.table = &sun4i_apb1_config,
> +	.getter = sun4i_get_apb1_factors,
>  };
>  
>  static void __init sunxi_factors_clk_setup(struct device_node *node,
> @@ -239,11 +239,11 @@ struct mux_data {
>  	u8 shift;
>  };
>  
> -static const __initconst struct mux_data cpu_mux_data = {
> +static const __initconst struct mux_data sun4i_cpu_mux_data = {
>  	.shift = 16,
>  };
>  
> -static const __initconst struct mux_data apb1_mux_data = {
> +static const __initconst struct mux_data sun4i_apb1_mux_data = {
>  	.shift = 24,
>  };
>  
> @@ -284,17 +284,17 @@ struct div_data {
>  	u8 pow;
>  };
>  
> -static const __initconst struct div_data axi_data = {
> +static const __initconst struct div_data sun4i_axi_data = {
>  	.shift = 0,
>  	.pow = 0,
>  };
>  
> -static const __initconst struct div_data ahb_data = {
> +static const __initconst struct div_data sun4i_ahb_data = {
>  	.shift = 4,
>  	.pow = 1,
>  };
>  
> -static const __initconst struct div_data apb0_data = {
> +static const __initconst struct div_data sun4i_apb0_data = {
>  	.shift = 8,
>  	.pow = 1,
>  };
> @@ -413,35 +413,77 @@ CLK_OF_DECLARE(sunxi_osc, "allwinner,sun4i-osc-clk", sunxi_osc_clk_setup);
>  
>  /* Matches for factors clocks */
>  static const __initconst struct of_device_id clk_factors_match[] = {
> -	{.compatible = "allwinner,sun4i-pll1-clk", .data = &pll1_data,},
> -	{.compatible = "allwinner,sun4i-apb1-clk", .data = &apb1_data,},
> +	{
> +		.compatible = "allwinner,sun4i-pll1-clk",
> +		.data = &sun4i_pll1_data,
> +	},
> +	{
> +		.compatible = "allwinner,sun4i-apb1-clk",
> +		.data = &sun4i_apb1_data,
> +	},
>  	{}
>  };
>  
>  /* Matches for divider clocks */
>  static const __initconst struct of_device_id clk_div_match[] = {
> -	{.compatible = "allwinner,sun4i-axi-clk", .data = &axi_data,},
> -	{.compatible = "allwinner,sun4i-ahb-clk", .data = &ahb_data,},
> -	{.compatible = "allwinner,sun4i-apb0-clk", .data = &apb0_data,},
> +	{
> +		.compatible = "allwinner,sun4i-axi-clk",
> +		.data = &sun4i_axi_data,
> +	},
> +	{
> +		.compatible = "allwinner,sun4i-ahb-clk",
> +		.data = &sun4i_ahb_data,
> +	},
> +	{
> +		.compatible = "allwinner,sun4i-apb0-clk",
> +		.data = &sun4i_apb0_data,
> +	},
>  	{}
>  };
>  
>  /* Matches for mux clocks */
>  static const __initconst struct of_device_id clk_mux_match[] = {
> -	{.compatible = "allwinner,sun4i-cpu-clk", .data = &cpu_mux_data,},
> -	{.compatible = "allwinner,sun4i-apb1-mux-clk", .data = &apb1_mux_data,},
> +	{
> +		.compatible = "allwinner,sun4i-cpu-clk",
> +		.data = &sun4i_cpu_mux_data,
> +	},
> +	{
> +		.compatible = "allwinner,sun4i-apb1-mux-clk",
> +		.data = &sun4i_apb1_mux_data,
> +	},
>  	{}
>  };
>  
>  /* Matches for gate clocks */
>  static const __initconst struct of_device_id clk_gates_match[] = {
> -	{.compatible = "allwinner,sun4i-axi-gates-clk", .data = &sun4i_axi_gates_data,},
> -	{.compatible = "allwinner,sun4i-ahb-gates-clk", .data = &sun4i_ahb_gates_data,},
> -	{.compatible = "allwinner,sun5i-a13-ahb-gates-clk", .data = &sun5i_a13_ahb_gates_data,},
> -	{.compatible = "allwinner,sun4i-apb0-gates-clk", .data = &sun4i_apb0_gates_data,},
> -	{.compatible = "allwinner,sun5i-a13-apb0-gates-clk", .data = &sun5i_a13_apb0_gates_data,},
> -	{.compatible = "allwinner,sun4i-apb1-gates-clk", .data = &sun4i_apb1_gates_data,},
> -	{.compatible = "allwinner,sun5i-a13-apb1-gates-clk", .data = &sun5i_a13_apb1_gates_data,},
> +	{
> +		.compatible = "allwinner,sun4i-axi-gates-clk",
> +		.data = &sun4i_axi_gates_data,
> +	},
> +	{
> +		.compatible = "allwinner,sun4i-ahb-gates-clk",
> +		.data = &sun4i_ahb_gates_data,
> +	},
> +	{
> +		.compatible = "allwinner,sun5i-a13-ahb-gates-clk",
> +		.data = &sun5i_a13_ahb_gates_data,
> +	},
> +	{
> +		.compatible = "allwinner,sun4i-apb0-gates-clk",
> +		.data = &sun4i_apb0_gates_data,
> +	},
> +	{
> +		.compatible = "allwinner,sun5i-a13-apb0-gates-clk",
> +		.data = &sun5i_a13_apb0_gates_data,
> +	},
> +	{
> +		.compatible = "allwinner,sun4i-apb1-gates-clk",
> +		.data = &sun4i_apb1_gates_data,
> +	},
> +	{
> +		.compatible = "allwinner,sun5i-a13-apb1-gates-clk",
> +		.data = &sun5i_a13_apb1_gates_data,
> +	},
>  	{}
>  };
>  

I'm not particularly a fan of this though; in my opinion it hurts
readability a bit and it uses 4x the lines. It looks like a highly
probable source of git conflicts too if not handled appropriately :)

Other than that,

Reviewed-by: Emilio L?pez <emilio at elopez.com.ar>

Thanks!

Emilio


From emilio at elopez.com.ar  Tue Jul 30 20:27:33 2013
From: emilio at elopez.com.ar (=?ISO-8859-1?Q?Emilio_L=F3pez?=)
Date: Tue, 30 Jul 2013 21:27:33 -0300
Subject: [PATCH 2/4] clk: sunxi: Allow to specify the divider width from
 the dividers data
In-Reply-To: <1375195462-19566-3-git-send-email-maxime.ripard@free-electrons.com>
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375195462-19566-3-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <51F859F5.70501@elopez.com.ar>

El 30/07/13 11:44, Maxime Ripard escribi?:
> The divider width used to be hardcoded. Some A31 dividers are no longer
> with the hardcoded width, so we need to make it specific to each divider
> and set it in the dividers data.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Looks good to me,

Reviewed-by: Emilio L?pez <emilio at elopez.com.ar>

> ---
>  drivers/clk/sunxi/clk-sunxi.c | 24 +++++++++++++-----------
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 3c91888..6e9cbc9 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -277,26 +277,28 @@ static void __init sunxi_mux_clk_setup(struct device_node *node,
>   * sunxi_divider_clk_setup() - Setup function for simple divider clocks
>   */
>  
> -#define SUNXI_DIVISOR_WIDTH	2
> -
>  struct div_data {
> -	u8 shift;
> -	u8 pow;
> +	u8	shift;
> +	u8	pow;
> +	u8	width;
>  };
>  
>  static const __initconst struct div_data sun4i_axi_data = {
> -	.shift = 0,
> -	.pow = 0,
> +	.shift	= 0,
> +	.pow	= 0,
> +	.width	= 2,
>  };

Is there a style rule governing the use of tabs/spaces on structs? Maybe
we should do this alignment cleanup on the full file some time.

>  
>  static const __initconst struct div_data sun4i_ahb_data = {
> -	.shift = 4,
> -	.pow = 1,
> +	.shift	= 4,
> +	.pow	= 1,
> +	.width	= 2,
>  };
>  
>  static const __initconst struct div_data sun4i_apb0_data = {
> -	.shift = 8,
> -	.pow = 1,
> +	.shift	= 8,
> +	.pow	= 1,
> +	.width	= 2,
>  };
>  
>  static void __init sunxi_divider_clk_setup(struct device_node *node,
> @@ -312,7 +314,7 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
>  	clk_parent = of_clk_get_parent_name(node, 0);
>  
>  	clk = clk_register_divider(NULL, clk_name, clk_parent, 0,
> -				   reg, data->shift, SUNXI_DIVISOR_WIDTH,
> +				   reg, data->shift, data->width,
>  				   data->pow ? CLK_DIVIDER_POWER_OF_TWO : 0,
>  				   &clk_lock);
>  	if (clk) {
> 

Thanks!

Emilio


From horms at verge.net.au  Tue Jul 30 20:29:44 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 31 Jul 2013 09:29:44 +0900
Subject: [PATCH 5/5] ARM: shmobile: ape6evm: add SDHI interfaces
In-Reply-To: <51F7B822.7020404@cogentembedded.com>
References: <cover.1375174556.git.horms+renesas@verge.net.au>
 <f79d68da510bf1b95beff4d556b78d06801f11dc.1375174556.git.horms+renesas@verge.net.au>
 <51F7B822.7020404@cogentembedded.com>
Message-ID: <20130731002944.GD17209@verge.net.au>

On Tue, Jul 30, 2013 at 04:57:06PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 30-07-2013 13:00, Simon Horman wrote:
> 
> >From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
> 
> >Add support for SDHI0 and SDHI1 on APE6EVM in PIO mode only.
> 
> >Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> >Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> >---
> >  arch/arm/mach-shmobile/board-ape6evm.c | 50 +++++++++++++++++++++++++++++++++-
> >  1 file changed, 49 insertions(+), 1 deletion(-)
> 
> >diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
> >index 8c7529c..ccf8b04 100644
> >--- a/arch/arm/mach-shmobile/board-ape6evm.c
> >+++ b/arch/arm/mach-shmobile/board-ape6evm.c
> [...]
> >@@ -75,6 +82,29 @@ static struct resource mmcif0_resources[] = {
> >  	DEFINE_RES_IRQ(gic_spi(169)),
> >  };
> >
> >+/* SDHI0 */
> >+static struct sh_mobile_sdhi_info sdhi0_pdata = {
> >+	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE,
> >+	.tmio_caps	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
> >+};
> >+
> >+static struct resource sdhi0_resources[] = {
> >+	DEFINE_RES_MEM_NAMED(0xee100000, 0x100, "SDHI0"),
> >+	DEFINE_RES_IRQ(gic_spi(165)),
> >+};
> >+
> >+/* SDHI1 */
> >+static struct sh_mobile_sdhi_info sdhi1_pdata = {
> >+	.tmio_flags	= TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE,
> >+	.tmio_caps	= MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |
> >+			  MMC_CAP_NEEDS_POLL,
> >+};
> >+
> >+static struct resource sdhi1_resources[] = {
> >+	DEFINE_RES_MEM_NAMED(0xee120000, 0x100, "SDHI1"),
> >+	DEFINE_RES_IRQ(gic_spi(166)),
> >+};
> >+
> 
>    All of the above are lacking '__initdata' annothation (the
> resources and platform data will be kmemdup()'ed when registering
> the platform devices). Too bad I've noticed this too late...

Thanks Sergei.

Guennadi,

as I have already queued-up this patch could you please
make an incremental patch that adds __initdata to the above structures?

> 
> >@@ -124,6 +166,12 @@ static void __init ape6evm_add_standard_devices(void)
> >  	platform_device_register_resndata(&platform_bus, "sh_mmcif", 0,
> >  					  mmcif0_resources, ARRAY_SIZE(mmcif0_resources),
> >  					  &mmcif0_pdata, sizeof(mmcif0_pdata));
> >+	platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0,
> >+					  sdhi0_resources, ARRAY_SIZE(sdhi0_resources),
> >+					  &sdhi0_pdata, sizeof(sdhi0_pdata));
> >+	platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 1,
> >+					  sdhi1_resources, ARRAY_SIZE(sdhi1_resources),
> >+					  &sdhi1_pdata, sizeof(sdhi1_pdata));
> >  }
> 
> WBR, Sergei
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From horms at verge.net.au  Tue Jul 30 20:30:32 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 31 Jul 2013 09:30:32 +0900
Subject: [PATCH 4/5] ARM: shmobile: ape6evm: add MMCIF support
In-Reply-To: <51F7B8B0.3080201@cogentembedded.com>
References: <cover.1375174556.git.horms+renesas@verge.net.au>
 <8711613252ed931037f9e9f8646935519dd8f362.1375174556.git.horms+renesas@verge.net.au>
 <51F7B8B0.3080201@cogentembedded.com>
Message-ID: <20130731003032.GE17209@verge.net.au>

On Tue, Jul 30, 2013 at 04:59:28PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 30-07-2013 13:00, Simon Horman wrote:
> 
> >From: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
> 
> >Add MMCIF support to the APE6EVM board in PIO mode only. Power supply is
> >fixed for now, eventually support for the tps80032 regulator, also
> >supplying both VDD and VccQ to the MMCIF slot should be added to APE6EVM.
> 
> >Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
> >Acked-by: Magnus Damm <damm at opensource.se>
> >Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> >---
> >  arch/arm/mach-shmobile/board-ape6evm.c | 31 +++++++++++++++++++++++++++++++
> >  1 file changed, 31 insertions(+)
> 
> >diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c
> >index af6dd39..8c7529c 100644
> >--- a/arch/arm/mach-shmobile/board-ape6evm.c
> >+++ b/arch/arm/mach-shmobile/board-ape6evm.c
> [...]
> >@@ -54,6 +56,25 @@ static const struct smsc911x_platform_config lan9220_data = {
> [...]
> >+/* MMCIF */
> >+static struct sh_mmcif_plat_data mmcif0_pdata = {
> >+	.caps		= MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE,
> >+};
> >+
> >+static struct resource mmcif0_resources[] = {
> >+	DEFINE_RES_MEM_NAMED(0xee200000, 0x100, "MMCIF0"),
> >+	DEFINE_RES_IRQ(gic_spi(169)),
> >+};
> >+
> 
>    The above needed '__initdata' too. And I have only noticed...

Thanks again Sergei.

Guennadi,

as I have already queued-up this patch could you please
make an incremental patch that adds __initdata to the above structures?

> >  static const struct pinctrl_map ape6evm_pinctrl_map[] = {
> >  	/* SCIFA0 console */
> >  	PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a73a4",
> [...]
> >@@ -93,6 +119,11 @@ static void __init ape6evm_add_standard_devices(void)
> >  	platform_device_register_resndata(&platform_bus, "smsc911x", -1,
> >  					  lan9220_res, ARRAY_SIZE(lan9220_res),
> >  					  &lan9220_data, sizeof(lan9220_data));
> >+	regulator_register_always_on(1, "fixed-3.3V", fixed3v3_power_consumers,
> >+				     ARRAY_SIZE(fixed3v3_power_consumers), 3300000);
> >+	platform_device_register_resndata(&platform_bus, "sh_mmcif", 0,
> >+					  mmcif0_resources, ARRAY_SIZE(mmcif0_resources),
> >+					  &mmcif0_pdata, sizeof(mmcif0_pdata));
> >  }
> 
> WBR, Sergei
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From panetta.mike at gmail.com  Tue Jul 30 20:36:07 2013
From: panetta.mike at gmail.com (Mike Panetta)
Date: Tue, 30 Jul 2013 20:36:07 -0400
Subject: [PATCH 1/2] ARM: dts: imx6qdl-wandboard: add gpio lines to
 wandboard shared dtsi.
In-Reply-To: <CAJB6Qec_bTt_+Sj07J3Jh0e=XQni=R59Fb-KD=tbVw6vhApHww@mail.gmail.com>
References: <CAJB6Qec_bTt_+Sj07J3Jh0e=XQni=R59Fb-KD=tbVw6vhApHww@mail.gmail.com>
Message-ID: <CAJB6Qed=jZ2Egdd6RjoAm4Qeb2Fgn6T6502iC37D4=cz+VAuFQ@mail.gmail.com>

Ok, trying again. Sorry for the HTML.

On Tue, Jul 30, 2013 at 8:33 PM, Mike Panetta <panetta.mike at gmail.com> wrote:
> Hello, I'm not yet subscribed to the list, so I hope this makes it.  I am
> working on adding some extra IO to the wandboard, this is the first patch in
> the series, it adds the pin configs for the 10 available GPIO pins on the
> wandboard EDM module.
>
> Signed-off-by: Mike Panetta <panetta.mike at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-wandboard-gpio-dts.patch
Type: application/octet-stream
Size: 1115 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130730/45966b0d/attachment-0001.obj>

From alex.williamson at redhat.com  Tue Jul 30 20:36:32 2013
From: alex.williamson at redhat.com (Alex Williamson)
Date: Tue, 30 Jul 2013 18:36:32 -0600
Subject: Linux Plumbers ACPI/PM, PCI Microconference
In-Reply-To: <B8EFE96D1287C24090BAD9D858E15E6174F0B5@sisaex01sj>
References: <CAL-B5D03ki8NHsM6EuESTH2K-Eh+XyFHNXPDYwgDq+oagDjtMQ@mail.gmail.com>
 <CAKocOOOgEb5h1dZWP_2UqBKhSK9U-kxKUbvTdzHfds=RiDzNJg@mail.gmail.com>
 <1476124.sWE2ygoo2D@vostro.rjw.lan>
 <B8EFE96D1287C24090BAD9D858E15E6174F0B5@sisaex01sj>
Message-ID: <1375230992.31262.87.camel@ul30vt.home>

On Wed, 2013-07-31 at 00:02 +0000, Shuah Khan wrote:
> On 07/30/2013 05:38 PM, Rafael J. Wysocki wrote:
> > On Wednesday, July 17, 2013 08:31:55 AM Shuah Khan wrote:
> >> Myron,
> >>
> >> On Tue, Jul 16, 2013 at 8:21 PM, Myron Stowe <myron.stowe at gmail.com> wrote:
> >>
> >>>
> >>> Shuah - You brought up the idea about "Converting drivers from Legacy
> >>> PM ops to dev_pm_ops"; would you like to present what you have
> >>> done/encountered so far?
> >>>
> >>
> >> Awesome. Yes, I would like to present what I have done so far and I do
> >> have a couple of things that could benefit from a face to face
> >> discussion which would help me make progress on the rest of the work
> >> that needs to get done.
> >
> > Care to sumbit a formal proposal through the LPC web page?
> >
> > Rafael
> >
> >
> 
> Rafael,
> 
> I did submit a formal talk proposal to LinuxCon/LPC and it was rejected. 
> Submission is closed now as far as I know.

Microconference topics should be submitted here:

http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/proposals/new



From panetta.mike at gmail.com  Tue Jul 30 20:41:50 2013
From: panetta.mike at gmail.com (Mike Panetta)
Date: Tue, 30 Jul 2013 20:41:50 -0400
Subject: [PATCH 2/2] ARM: dts: imx6qdl-wandboard: add debug led for headless
 bringup to wandboard shared dtsi.
Message-ID: <CAJB6QefCYSBYxAuAiYAxNRhuRcO35OV_zuHKkiaS-+U5guppvQ@mail.gmail.com>

The following patch is the second in the series, it adds a debug led
to the system so that someone can know immediately if the kernel is up
on the wandboard.

Signed-off-by: Mike Panetta <panetta.mike at gmail.com>

Thanks,
Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-add-wandboard-leds-dts.patch
Type: application/octet-stream
Size: 504 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130730/616950b6/attachment.obj>

From bjorn at kryo.se  Tue Jul 30 20:19:44 2013
From: bjorn at kryo.se (Bjorn Andersson)
Date: Tue, 30 Jul 2013 16:19:44 -0800
Subject: [PATCH] mmc: sdhci-msm: Add support for MSM chipsets
In-Reply-To: <1375201355-26906-1-git-send-email-gdjakov@mm-sol.com>
References: <1375201355-26906-1-git-send-email-gdjakov@mm-sol.com>
Message-ID: <CAJAp7OgOT82G=W8RpDvaogskUmAN26CWq4gKUs45RwOeU8pXvQ@mail.gmail.com>

On Tue, Jul 30, 2013 at 8:22 AM, Georgi Djakov <gdjakov at mm-sol.com> wrote:
> This platform driver adds the support of Secure Digital Host
> Controller Interface compliant controller in MSM chipsets.
>
> [snip]
> +
> +       sdhc_1: qcom,sdhc at f9824900 {
> +               compatible = "qcom,sdhci-msm";
> +                       reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
> +                       reg-names = "hc_mem", "core_mem";
> +                       interrupts = <0 123 0>, <0 138 0>;
> +                       interrupt-names = "hc_irq", "pwr_irq";
> +
> +               vdd-supply = <&pm8941_l21>;
> +               vdd-io-supply = <&pm8941_l13>;
> +               qcom,vdd-voltage-level = <2950000 2950000>;
> +               qcom,vdd-current-level = <9000 800000>;
> +
> +               qcom,vdd-io-always-on;
> +               qcom,vdd-io-lpm-sup;
> +               qcom,vdd-io-voltage-level = <1800000 2950000>;
> +               qcom,vdd-io-current-level = <6 22000>;
> +
> +               bus-width = <4>;
> +               non-removable;
> +               qcom,bus-speed-mode = "HS200_1p8v", "DDR_1p8v";
> +
> +               gpios = <&msmgpio 40 0>, /* CLK */
> +                       <&msmgpio 39 0>, /* CMD */
> +                       <&msmgpio 38 0>, /* DATA0 */
> +                       <&msmgpio 37 0>, /* DATA1 */
> +                       <&msmgpio 36 0>, /* DATA2 */
> +                       <&msmgpio 35 0>; /* DATA3 */
> +               qcom,gpio-names = "CLK", "CMD", "DAT0", "DAT1", "DAT2", "DAT3";

I believe these gpio references (and in the rest of the patch) should
be replaced by pinctrl. As far as I can see it provides what you want
and gives you configurability and potential sleep states of those pins
nicely integrated.

Regards,
Bjorn


From pwalmsley at nvidia.com  Tue Jul 30 20:53:51 2013
From: pwalmsley at nvidia.com (Paul Walmsley)
Date: Wed, 31 Jul 2013 00:53:51 +0000 (UTC)
Subject: Tegra baseline test results for v3.10-rc5
In-Reply-To: <51B72D2A.6040909@arm.com>
References: <alpine.DEB.2.02.1306111220490.22645@utopia.booyaka.com>
 <51B72D2A.6040909@arm.com>
Message-ID: <alpine.DEB.2.02.1307310037530.22504@utopia.booyaka.com>

Hi Jonathan,

I'm sorry it's taken me so long to respond -

On Tue, 11 Jun 2013, Jonathan Austin wrote:

> On 11/06/13 13:24, Paul Walmsley wrote:
> > 
> > Here are some basic Tegra test results for Linux v3.10-rc5.
> > Logs and other details at:
> > 
> >      http://www.pwsan.com/tegra/testlogs/test_v3.10-rc5/20130611044210/
> > 
> 
> These automated tests look pretty useful - is this some well known tool that's
> passed me by, or something you've written yourself? Something in between?

A little of both.  The OMAP version of this is built on modified versions 
of Minicom and dtach, along with some Perl and shell scripts.  An early, 
extremely ugly version has been released to a few people under the GPL.  
A wider release is planned, once it's cleaned up.  The code changes 
required by the recent DT boot changes and kernel message text changes 
have consumed a large amount of time here.

If there's interest in the serial interaction scripts, e.g., the scripts 
that do PM testing once the board is booted, such as

http://www.pwsan.com/omap/testlogs/test_v3.11-rc1/20130721020309/pm/37xxevm/

those can be released sooner.  Maybe folks can even contribute new test 
scenarios for use in the testbed?

> Particularly, does whatever you have handle boards on serial ports
> automagically, with a way to add different interfaces for resetting locked
> boards etc?

All the console captures and command interaction is from the board serial 
consoles.  The board power inputs are connected to Ethernet-controlled AC 
or DC relays, and are automatically controlled by the scripts.  


Thanks for the interest,

- Paul


From paul at pwsan.com  Tue Jul 30 20:57:47 2013
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 31 Jul 2013 00:57:47 +0000 (UTC)
Subject: OMAP2430 SDP boot broken after Linus' rmk merge
In-Reply-To: <51EE5C13.1000004@arm.com>
References: <alpine.DEB.2.02.1307221801110.10891@utopia.booyaka.com>
 <51EE5C13.1000004@arm.com>
Message-ID: <alpine.DEB.2.02.1307310055090.22504@utopia.booyaka.com>

On Tue, 23 Jul 2013, Jonathan Austin wrote:

> I've just had a quick go at booting 3.11-rc2 on an integrator-cp (1136) in the
> hope that we might be able to reproduce this on those boards, but I'm afraid
> the integrator works...
> 
> I took your config, modified it as little as possible to switch to Integrator
> and turn on earlyprintk, and then tried to boot. That *did* require switching
> away from ARCH_MULTIPLATFORM, so it isn't as similar as I'd like, though...
> 
> So I think we can at least say that this is not 1136 specific... Sorry not to
> be more helpful...

Just saw this message - thanks for the test.  What 1136 variant does the 
Integrator-CP have in it?  Would assume an r1 or later?


- Paul


From emilio at elopez.com.ar  Tue Jul 30 21:01:25 2013
From: emilio at elopez.com.ar (=?ISO-8859-1?Q?Emilio_L=F3pez?=)
Date: Tue, 30 Jul 2013 22:01:25 -0300
Subject: [PATCH 3/4] clk: sunxi: Add A31 clocks support
In-Reply-To: <1375195462-19566-4-git-send-email-maxime.ripard@free-electrons.com>
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375195462-19566-4-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <51F861E5.7010909@elopez.com.ar>

Hi Maxime,

El 30/07/13 11:44, Maxime Ripard escribi?:
> The A31 has a mostly different clock set compared to the other older
> SoCs currently supported in the Allwinner clock driver.
> 
> Add support for the basic useful clocks. The other ones will come in
> eventually.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  drivers/clk/sunxi/clk-sunxi.c | 120 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 120 insertions(+)
> 
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 6e9cbc9..8cd69e6 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -124,7 +124,67 @@ static void sun4i_get_pll1_factors(u32 *freq, u32 parent_rate,
>  	*n = div / 4;
>  }
>  
> +/**
> + * sun6i_get_pll1_factors() - calculates n, k and m factors for PLL1
> + * PLL1 rate is calculated as follows
> + * rate = parent_rate * (n + 1) * (k + 1) / (m + 1);
> + * parent_rate should always be 24MHz
> + */
> +static void sun6i_get_pll1_factors(u32 *freq, u32 parent_rate,
> +				   u8 *n, u8 *k, u8 *m, u8 *p)
> +{
> +	/*
> +	 * We can operate only on MHz, this will make our life easier
> +	 * later.
> +	 */
> +	u32 freq_mhz = *freq / 1000000;
> +	u32 parent_freq_mhz = parent_rate / 1000000;
> +
> +	/* If the frequency is a multiple of 32 MHz, k is always 3 */
> +	if (!(freq_mhz % 32))
> +		*k = 3;
> +	/* If the frequency is a multiple of 9 MHz, k is always 2 */
> +	else if (!(freq_mhz % 9))
> +		*k = 2;
> +	/* If the frequency is a multiple of 8 MHz, k is always 1 */
> +	else if (!(freq_mhz % 8))
> +		*k = 1;
> +	/* Otherwise, we don't use the k factor */
> +	else
> +		*k = 0;
>  
> +	/*
> +	 * If the frequency is a multiple of 2 but not a multiple of
> +	 * 3, m is 3. This is the first time we use 6 here, yet we
> +	 * will use it on several other places.
> +	 * We use this number because it's the lowest frequency we can
> +	 * generate (with n = 0, k = 0, m = 3), so every other frequency
> +	 * somehow relates to this frequency.
> +	 */
> +	if ((freq_mhz % 6) == 2 || (freq_mhz % 6) == 4)
> +		*m = 2;
> +	/*
> +	 * If the frequency is a multiple of 6MHz, but the factor is
> +	 * odd, m will be 3
> +	 */
> +	else if ((freq_mhz / 6) & 1)
> +		*m = 3;
> +	/* Otherwise, we end up with m = 1 */
> +	else
> +		*m = 1;
> +
> +	/* Calculate n thanks to the above factors we already got */
> +	*n = freq_mhz * (*m + 1) / ((*k + 1) * parent_freq_mhz) - 1;
> +
> +	/*
> +	 * If n end up being outbound, and that we can still decrease
> +	 * m, do it.
> +	 */
> +	if ((*n + 1) > 31 && (*m + 1) > 1) {
> +		*n = (*n + 1) / 2 - 1;
> +		*m = (*m + 1) / 2 - 1;
> +	}
> +}

Nice! My rate-to-factors functions pale in comparison :) Remember that
n/k/m/p may be NULL when the caller just wants you to round freq to an
achievable value (see clk_factors_round_rate(...) in clk-factors.c).

>  /**
>   * sun4i_get_apb1_factors() - calculates m, p factors for APB1
> @@ -189,6 +249,15 @@ static struct clk_factors_config sun4i_pll1_config = {
>  	.pwidth = 2,
>  };
>  
> +static struct clk_factors_config sun6i_pll1_config = {
> +	.nshift	= 8,
> +	.nwidth = 5,
> +	.kshift = 4,
> +	.kwidth = 2,
> +	.mshift = 0,
> +	.mwidth = 2,
> +};
> +
>  static struct clk_factors_config sun4i_apb1_config = {
>  	.mshift = 0,
>  	.mwidth = 5,
> @@ -201,6 +270,11 @@ static const __initconst struct factors_data sun4i_pll1_data = {
>  	.getter = sun4i_get_pll1_factors,
>  };
>  
> +static const __initconst struct factors_data sun6i_pll1_data = {
> +	.table = &sun6i_pll1_config,
> +	.getter = sun6i_get_pll1_factors,
> +};
> +
>  static const __initconst struct factors_data sun4i_apb1_data = {
>  	.table = &sun4i_apb1_config,
>  	.getter = sun4i_get_apb1_factors,
> @@ -243,6 +317,10 @@ static const __initconst struct mux_data sun4i_cpu_mux_data = {
>  	.shift = 16,
>  };
>  
> +static const __initconst struct mux_data sun6i_ahb1_mux_data = {
> +	.shift = 12,
> +};
> +
>  static const __initconst struct mux_data sun4i_apb1_mux_data = {
>  	.shift = 24,
>  };
> @@ -301,6 +379,12 @@ static const __initconst struct div_data sun4i_apb0_data = {
>  	.width	= 2,
>  };
>  
> +static const __initconst struct div_data sun6i_apb2_div_data = {
> +	.shift	= 0,
> +	.pow	= 0,
> +	.width	= 4,
> +};
> +
>  static void __init sunxi_divider_clk_setup(struct device_node *node,
>  					   struct div_data *data)
>  {
> @@ -347,6 +431,10 @@ static const __initconst struct gates_data sun5i_a13_ahb_gates_data = {
>  	.mask = {0x107067e7, 0x185111},
>  };
>  
> +static const __initconst struct gates_data sun6i_a31_ahb1_gates_data = {
> +	.mask = { 0xedfe7f62, 0x794f931 },
> +};
> +
>  static const __initconst struct gates_data sun4i_apb0_gates_data = {
>  	.mask = {0x4EF},
>  };
> @@ -363,6 +451,14 @@ static const __initconst struct gates_data sun5i_a13_apb1_gates_data = {
>  	.mask = {0xa0007},
>  };
>  
> +static const __initconst struct gates_data sun6i_a31_apb1_gates_data = {
> +	.mask = { 0x3031 },
> +};
> +
> +static const __initconst struct gates_data sun6i_a31_apb2_gates_data = {
> +	.mask = { 0x3f000f },
> +};
> +

We should decide on a style here and use it across the board, so far we
have definitions with and without spaces between constants and braces,
and constants both with upper and lower case A-F. Personally I don't
feel strongly about the spacing and prefer upper-case constants, but if
the style guide suggests otherwise, I can live with it (as long as we
use it consistently, that is)

>  static void __init sunxi_gates_clk_setup(struct device_node *node,
>  					 struct gates_data *data)
>  {
> @@ -420,6 +516,10 @@ static const __initconst struct of_device_id clk_factors_match[] = {
>  		.data = &sun4i_pll1_data,
>  	},
>  	{
> +		.compatible = "allwinner,sun6i-pll1-clk",
> +		.data = &sun6i_pll1_data,
> +	},
> +	{
>  		.compatible = "allwinner,sun4i-apb1-clk",
>  		.data = &sun4i_apb1_data,
>  	},
> @@ -440,6 +540,10 @@ static const __initconst struct of_device_id clk_div_match[] = {
>  		.compatible = "allwinner,sun4i-apb0-clk",
>  		.data = &sun4i_apb0_data,
>  	},
> +	{
> +		.compatible = "allwinner,sun6i-apb2-div-clk",
> +		.data = &sun6i_apb2_div_data,
> +	},
>  	{}
>  };
>  
> @@ -453,6 +557,10 @@ static const __initconst struct of_device_id clk_mux_match[] = {
>  		.compatible = "allwinner,sun4i-apb1-mux-clk",
>  		.data = &sun4i_apb1_mux_data,
>  	},
> +	{
> +		.compatible = "allwinner,sun6i-ahb1-mux-clk",
> +		.data = &sun6i_ahb1_mux_data,
> +	},
>  	{}
>  };
>  
> @@ -471,6 +579,10 @@ static const __initconst struct of_device_id clk_gates_match[] = {
>  		.data = &sun5i_a13_ahb_gates_data,
>  	},
>  	{
> +		.compatible = "allwinner,sun6i-a31-ahb1-gates-clk",
> +		.data = &sun6i_a31_ahb1_gates_data,
> +	},
> +	{
>  		.compatible = "allwinner,sun4i-apb0-gates-clk",
>  		.data = &sun4i_apb0_gates_data,
>  	},
> @@ -486,6 +598,14 @@ static const __initconst struct of_device_id clk_gates_match[] = {
>  		.compatible = "allwinner,sun5i-a13-apb1-gates-clk",
>  		.data = &sun5i_a13_apb1_gates_data,
>  	},
> +	{
> +		.compatible = "allwinner,sun6i-a31-apb1-gates-clk",
> +		.data = &sun6i_a31_apb1_gates_data,
> +	},
> +	{
> +		.compatible = "allwinner,sun6i-a31-apb2-gates-clk",
> +		.data = &sun6i_a31_apb2_gates_data,
> +	},

Please see my comments on the first patch regarding these.

Thanks!

Emilio


From horms at verge.net.au  Tue Jul 30 21:04:04 2013
From: horms at verge.net.au (Simon Horman)
Date: Wed, 31 Jul 2013 10:04:04 +0900
Subject: ARM CPU Hotplug breakage on mach-shmobile and KZM9D
In-Reply-To: <51F7CD67.6020209@windriver.com>
References: <CANqRtoRx7voEVwJG8UNNy_Jiixo=uRJCvxTD0bZdzVohoryBUA@mail.gmail.com>
 <20130725010607.GB31464@verge.net.au>
 <20130730074939.GE7210@verge.net.au>
 <51F7CD67.6020209@windriver.com>
Message-ID: <20130731010404.GJ17209@verge.net.au>

On Tue, Jul 30, 2013 at 10:27:51AM -0400, Paul Gortmaker wrote:
> On 13-07-30 03:49 AM, Simon Horman wrote:
> > [ Cc Paul Gortmaker ]
> > 
> > On Thu, Jul 25, 2013 at 10:06:07AM +0900, Simon Horman wrote:
> >> On Thu, Jul 25, 2013 at 12:15:49AM +0900, Magnus Damm wrote:
> >>> Hi everyone,
> >>>
> >>> Bad news: CPU Hotplug on KZM9D seems broken on recent kernels.
> >>>
> >>> On renesas-next-20130710 or earlier I can perform the following:
> >>>
> >>> # echo 0 > /sys/devices/system/cpu/cpu1/online
> >>> CPU1: shutdown
> >>> # echo 1 > /sys/devices/system/cpu/cpu1/online
> >>> CPU1: Booted secondary processor
> >>> #
> >>>
> >>> While on more recent kernels the hotplug boot fails. This may be
> >>> related to the move to v3.11-rc. The tag renesas-next-20130710
> >>> surprisingly seems to be the final kernel based on v3.10-rc before
> >>> jumping to v3.11-rc.
> >>>
> >>> I wonder, do other ARM platforms have working CPU Hotplug in v3.11-rc?
> >>
> >> I have a snowball that I could test if you think it would be useful.
> > 
> > Unfortunately getting snowball to work turned out to be rather painful.
> > So instead I bisected the problem on the KZM9G (N.b: the D in the subject
> > seems to be incorrect :^)
> > 
> > The result is that the following patch, added in v3.11-rc1,
> > appears to be the culprit.
> 
> Double check that you have this commit present:
>  ---------------
> commit 8c69d7af12265e5be9326110b695e010b47505bd
> Author: Stephen Warren <swarren at nvidia.com>
> Date:   Fri Jul 5 22:59:42 2013 +0100
> 
>     ARM: 7780/1: add missing linker section markup to head-common.S
>  ---------------
> 
> as I think you are reporting the same problem that it fixed.

Unfortunately that does not seem to resolve the problem that I am seeing.
I have tried both v3.11-rc3 and 22f0a27367742f65130c0fb25ef00f7297e032c1
with 8c69d7af12265e5be9326110b695e010b47505bd cherry picked on top and
in both cases I see:

# echo 0 > /sys/devices/system/cpu/cpu1/online
CPU1: shutdown
# echo 1 > /sys/devices/system/cpu/cpu1/online
CPU1: failed to come online

> Thanks,
> Paul.
> --
> 
> > 
> > commit 22f0a27367742f65130c0fb25ef00f7297e032c1
> > Author: Paul Gortmaker <paul.gortmaker at windriver.com>
> > Date:   Mon Jun 17 18:34:14 2013 -0400
> > 
> >     init.h: remove __cpuinit sections from the kernel
> >     
> >     The __cpuinit type of throwaway sections might have made sense
> >     some time ago when RAM was more constrained, but now the savings
> >     do not offset the cost and complications.  For example, the fix in
> >     commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
> >     is a good example of the nasty type of bugs that can be created
> >     with improper use of the various __init prefixes.
> >     
> >     After a discussion on LKML[1] it was decided that cpuinit should go
> >     the way of devinit and be phased out.  Once all the users are gone,
> >     we can then finally remove the macros themselves from linux/init.h.
> >     
> >     As an interim step, we can dummy out the macros to be no-ops, and
> >     this will allow us to avoid a giant tree-wide patch, and instead
> >     we can feed in smaller chunks mainly via the arch/ trees.  This
> >     is in keeping with commit 78d86c213f28193082b5d8a1a424044b7ba406f1
> >     ("init.h: Remove __dev* sections from the kernel")
> >     
> >     We don't strictly need to dummy out the macros to do this, but if
> >     we don't then some harmless section mismatch warnings may temporarily
> >     result.  For example, notify_cpu_starting() and cpu_up() are arch
> >     independent (kernel/cpu.c) and are flagged as __cpuinit.  And hence
> >     the calling functions in the arch specific code are also expected
> >     to be __cpuinit -- if not, then we get the section mismatch warning.
> >     
> >     Two of the three __CPUINIT variants are not used whatsoever, and
> >     so they are simply removed directly at this point in time.
> >     
> >     [1] https://lkml.org/lkml/2013/5/20/589
> >     
> >     Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> > 
> > diff --git a/include/linux/init.h b/include/linux/init.h
> > index 8618147..e73f2b70 100644
> > --- a/include/linux/init.h
> > +++ b/include/linux/init.h
> > @@ -93,13 +93,13 @@
> >  
> >  #define __exit          __section(.exit.text) __exitused __cold notrace
> >  
> > -/* Used for HOTPLUG_CPU */
> > -#define __cpuinit        __section(.cpuinit.text) __cold notrace
> > -#define __cpuinitdata    __section(.cpuinit.data)
> > -#define __cpuinitconst   __constsection(.cpuinit.rodata)
> > -#define __cpuexit        __section(.cpuexit.text) __exitused __cold notrace
> > -#define __cpuexitdata    __section(.cpuexit.data)
> > -#define __cpuexitconst   __constsection(.cpuexit.rodata)
> > +/* temporary, until all users are removed */
> > +#define __cpuinit
> > +#define __cpuinitdata
> > +#define __cpuinitconst
> > +#define __cpuexit
> > +#define __cpuexitdata
> > +#define __cpuexitconst
> >  
> >  /* Used for MEMORY_HOTPLUG */
> >  #define __meminit        __section(.meminit.text) __cold notrace
> > @@ -118,9 +118,8 @@
> >  #define __INITRODATA	.section	".init.rodata","a",%progbits
> >  #define __FINITDATA	.previous
> >  
> > -#define __CPUINIT        .section	".cpuinit.text", "ax"
> > -#define __CPUINITDATA    .section	".cpuinit.data", "aw"
> > -#define __CPUINITRODATA  .section	".cpuinit.rodata", "a"
> > +/* temporary, until all users are removed */
> > +#define __CPUINIT
> >  
> >  #define __MEMINIT        .section	".meminit.text", "ax"
> >  #define __MEMINITDATA    .section	".meminit.data", "aw"
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From horms+renesas at verge.net.au  Tue Jul 30 21:33:50 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 31 Jul 2013 10:33:50 +0900
Subject: [PATCH 2/4] shdma: fixup sh_dmae_get_partial() calculation error
In-Reply-To: <cover.1375234088.git.horms+renesas@verge.net.au>
References: <cover.1375234088.git.horms+renesas@verge.net.au>
Message-ID: <3c4d9276626c93477af0b0b9d46b4dcb37e2eed2.1375234088.git.horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

sh_desc->hw.tcr is controlling real data size,
and, register TCR is controlling data transfer count
which was xmit_shifted value of hw.tcr.
Current sh_dmae_get_partial() is calculating in different unit.
This patch fixes it.

This bug has been present since c014906a870ce70e009def0c9d170ccabeb0be63
("dmaengine: shdma: extend .device_terminate_all() to record partial
transfer"), which was added in 2.6.34-rc1.

Cc: Vinod Koul <vinod.koul at intel.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski+renesas at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/dma/sh/shdma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/sh/shdma.c b/drivers/dma/sh/shdma.c
index b67f45f..5039fbc 100644
--- a/drivers/dma/sh/shdma.c
+++ b/drivers/dma/sh/shdma.c
@@ -400,8 +400,8 @@ static size_t sh_dmae_get_partial(struct shdma_chan *schan,
 						    shdma_chan);
 	struct sh_dmae_desc *sh_desc = container_of(sdesc,
 					struct sh_dmae_desc, shdma_desc);
-	return (sh_desc->hw.tcr - sh_dmae_readl(sh_chan, TCR)) <<
-		sh_chan->xmit_shift;
+	return sh_desc->hw.tcr -
+		(sh_dmae_readl(sh_chan, TCR) << sh_chan->xmit_shift);
 }
 
 /* Called from error IRQ or NMI */
-- 
1.8.3.2



From horms+renesas at verge.net.au  Tue Jul 30 21:33:51 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 31 Jul 2013 10:33:51 +0900
Subject: [PATCH 3/4] ARM: shmobile: BOCK-W: fix SDHI0 PFC settings
In-Reply-To: <cover.1375234088.git.horms+renesas@verge.net.au>
References: <cover.1375234088.git.horms+renesas@verge.net.au>
Message-ID: <fa3e0cee12fbdd9e0b03470b2b8cf968f537c161.1375234088.git.horms+renesas@verge.net.au>

From: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

The following message is printed on the BOCK-W kernel bootup:

sh-pfc pfc-r8a7778: invalid group "sdhi0" for function "sdhi0"

In addition, SD card cannot be detected.  The reason is apparently that commit
ca7bb309485e4ec89a9addd47bea (ARM: shmobile: bockw: add SDHI0 support) matched
the previous version of commit 564617d2f92473031d035deb273da5 (sh-pfc: r8a7778:
add SDHI support).

Add the missing pin groups according to the BOCK-W board schematics.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-bockw.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/board-bockw.c b/arch/arm/mach-shmobile/board-bockw.c
index d555464..3354a85 100644
--- a/arch/arm/mach-shmobile/board-bockw.c
+++ b/arch/arm/mach-shmobile/board-bockw.c
@@ -167,7 +167,13 @@ static const struct pinctrl_map bockw_pinctrl_map[] = {
 				  "usb1", "usb1"),
 	/* SDHI0 */
 	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
-				  "sdhi0", "sdhi0"),
+				  "sdhi0_data4", "sdhi0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
+				  "sdhi0_ctrl", "sdhi0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
+				  "sdhi0_cd", "sdhi0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.0", "pfc-r8a7778",
+				  "sdhi0_wp", "sdhi0"),
 };
 
 #define FPGA	0x18200000
-- 
1.8.3.2



From horms+renesas at verge.net.au  Tue Jul 30 21:33:52 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 31 Jul 2013 10:33:52 +0900
Subject: [PATCH 4/4] ARM: shmobile: lager: do not annotate gpio_buttons as
 __initdata
In-Reply-To: <cover.1375234088.git.horms+renesas@verge.net.au>
References: <cover.1375234088.git.horms+renesas@verge.net.au>
Message-ID: <a601469386b543df2a4d97ad7d524716945278a3.1375234088.git.horms+renesas@verge.net.au>

When the gpio-keys device is registered using
platform_device_register_data() the platform data argument,
lager_keys_pdata is duplicated and thus should be marked as __initdata
to avoid wasting memory. However, this is not true of gpio_buttons,
a reference to it rather than its value is duplicated when lager_keys_pdata
is duplicated.

This avoids accessing freed memory if gpio-key events occur
after unused kernel memory is freed late in the kernel's boot.

This but was added when support for gpio-keys was added to lager
in c3842e4fcbb7664276443b79187b7808c2e80a35
("ARM: shmobile: lager: support GPIO switches") which was included
in v3.11-rc1.

Tested-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-lager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index d73e21d..8d6bd5c 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -59,7 +59,7 @@ static __initdata struct gpio_led_platform_data lager_leds_pdata = {
 #define GPIO_KEY(c, g, d, ...) \
 	{ .code = c, .gpio = g, .desc = d, .active_low = 1 }
 
-static __initdata struct gpio_keys_button gpio_buttons[] = {
+static struct gpio_keys_button gpio_buttons[] = {
 	GPIO_KEY(KEY_4,		RCAR_GP_PIN(1, 28),	"SW2-pin4"),
 	GPIO_KEY(KEY_3,		RCAR_GP_PIN(1, 26),	"SW2-pin3"),
 	GPIO_KEY(KEY_2,		RCAR_GP_PIN(1, 24),	"SW2-pin2"),
-- 
1.8.3.2



From horms+renesas at verge.net.au  Tue Jul 30 21:33:49 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 31 Jul 2013 10:33:49 +0900
Subject: [PATCH 1/4] ARM: shmobile: armadillo800eva: Don't request GPIO 166 in
 board code
In-Reply-To: <cover.1375234088.git.horms+renesas@verge.net.au>
References: <cover.1375234088.git.horms+renesas@verge.net.au>
Message-ID: <16b551dd22cc7edacb952f7a2e175f36c3aa4bdb.1375234088.git.horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

89ae7b5bbd3e65bc6ab7a577ca5ec18569589c8c
(ARM: shmobile: armadillo800eva: Register pinctrl mapping for INTC)
mistakenly requests GPIO 166 in board code,
most probably due to a wrong merge conflict resolution.
As the GPIO is passed to the st1232 driver through platform
data and requested by the driver,
there's no need to request it in board code. Fix it.

Tested by: Cao Minh Hiep <cm-hiep at jinso.co.jp>
Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/board-armadillo800eva.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index e115f67..c5be60d 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -1162,9 +1162,6 @@ static void __init eva_init(void)
 	gpio_request_one(61, GPIOF_OUT_INIT_HIGH, NULL); /* LCDDON */
 	gpio_request_one(202, GPIOF_OUT_INIT_LOW, NULL); /* LCD0_LED_CONT */
 
-	/* Touchscreen */
-	gpio_request_one(166, GPIOF_OUT_INIT_HIGH, NULL); /* TP_RST_B */
-
 	/* GETHER */
 	gpio_request_one(18, GPIOF_OUT_INIT_HIGH, NULL); /* PHY_RST */
 
-- 
1.8.3.2



From horms+renesas at verge.net.au  Tue Jul 30 21:33:44 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 31 Jul 2013 10:33:44 +0900
Subject: [GIT 0/4] Second round of Renesas ARM based SoC fixes for v3.11
Message-ID: <cover.1375234088.git.horms+renesas@verge.net.au>

Hi Olof, Hi Arnd,

please consider the following Renesas ARM based SoC fixes for v3.11.

The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:

  Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-fixes2-for-v3.11

for you to fetch changes up to a601469386b543df2a4d97ad7d524716945278a3:

  ARM: shmobile: lager: do not annotate gpio_buttons as __initdata (2013-07-31 10:11:17 +0900)

----------------------------------------------------------------
Second round of Renesas ARM based SoC fixes for v3.11

* Lager board: do not annotate gpio_buttons as __initdata
  - This avoids accessing uninitialised memory if keys are pressed
    after kernel initialisation completes.
  - Bug introduced in gpio-keys were enabled in v3.11-rc1

* Bock-W board: fix SDHI0 PFC settings
  - Allow detection of SD card
  - Bug introduced in SDHI support was added in v3.11-rc1

* shdma: fixup sh_dmae_get_partial() calculation error
  - Bug introduced in 2.6.34-rc1.

* armadillo800eva board: Don't request GPIO 166 in board code
  - Allow use of touchscreen
  - Bug introduced in v3.11-rc1

----------------------------------------------------------------
Kuninori Morimoto (2):
      ARM: shmobile: armadillo800eva: Don't request GPIO 166 in board code
      shdma: fixup sh_dmae_get_partial() calculation error

Sergei Shtylyov (1):
      ARM: shmobile: BOCK-W: fix SDHI0 PFC settings

Simon Horman (1):
      ARM: shmobile: lager: do not annotate gpio_buttons as __initdata

 arch/arm/mach-shmobile/board-armadillo800eva.c | 3 ---
 arch/arm/mach-shmobile/board-bockw.c           | 8 +++++++-
 arch/arm/mach-shmobile/board-lager.c           | 2 +-
 drivers/dma/sh/shdma.c                         | 4 ++--
 4 files changed, 10 insertions(+), 7 deletions(-)


From emilio at elopez.com.ar  Tue Jul 30 21:36:46 2013
From: emilio at elopez.com.ar (=?ISO-8859-1?Q?Emilio_L=F3pez?=)
Date: Tue, 30 Jul 2013 22:36:46 -0300
Subject: [PATCH 4/4] ARM: sun6i: Enable clock support in the DTSI
In-Reply-To: <1375195462-19566-5-git-send-email-maxime.ripard@free-electrons.com>
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375195462-19566-5-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <51F86A2E.10505@elopez.com.ar>

Hi Maxime,

Overall this looks good to me, but I have some small comments:

El 30/07/13 11:44, Maxime Ripard escribi?:
> Now that the clock driver has support for the A31 clocks, we can add
> them to the DTSI and start using them in the relevant hardware blocks.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  arch/arm/boot/dts/sun6i-a31.dtsi | 137 ++++++++++++++++++++++++++++++++++++---
>  1 file changed, 127 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
> index 0d13dc6..c6a3a91 100644
> --- a/arch/arm/boot/dts/sun6i-a31.dtsi
> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> @@ -51,13 +51,130 @@
>  
>  	clocks {
>  		#address-cells = <1>;
> -		#size-cells = <0>;
> +		#size-cells = <1>;
> +		ranges;
>  
> -		osc: oscillator {
> +		osc24M: hosc {

Please use osc24M and osc32k instead of hosc and losc, respectively.

>  			#clock-cells = <0>;
>  			compatible = "fixed-clock";
>  			clock-frequency = <24000000>;

Is osc24M not gatable on A31?

>  		};
> +
> +		osc32k: losc {
> +			#clock-cells = <0>;
> +			compatible = "fixed-clock";
> +			clock-frequency = <32768>;
> +		};
> +
> +		pll1: pll1 at 01c20000 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun6i-pll1-clk";
> +			reg = <0x01c20000 0x4>;
> +			clocks = <&osc24M>;
> +		};
> +
> +		/*
> +		 * This is a dummy clock, to be used as placeholder on
> +		 * other mux clocks when a specific parent clock is not
> +		 * yet implemented. It should be dropped when the driver
> +		 * is complete.
> +		 */
> +		pll6: pll6 {
> +			#clock-cells = <0>;
> +			compatible = "fixed-clock";
> +			clock-frequency = <0>;
> +		};
> +
> +		cpu: cpu at 01c20050 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-cpu-clk";
> +			reg = <0x01c20050 0x4>;
> +			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;

Listing pll1 twice doesn't sound correct, but vendor code seems to
indicate so. A comment to clarify it's not a typo would be good I think.

> +		};
> +
> +		axi: axi at 01c20050 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-axi-clk";
> +			reg = <0x01c20050 0x4>;
> +			clocks = <&cpu>;
> +		};
> +
> +		ahb1_mux: ahb1_mux at 01c20054 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun6i-ahb1-mux-clk";
> +			reg = <0x01c20054 0x4>;
> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
> +		};
> +
> +		ahb1: ahb1 at 01c20054 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-ahb-clk";
> +			reg = <0x01c20054 0x4>;
> +			clocks = <&ahb1_mux>;
> +		};

Depending on when this lands, I believe these two above could be merged
into one with the refactoring introduced on my patchset.

> +
> +		ahb1_gates: ahb1_gates at 01c20060 {
> +			#clock-cells = <1>;
> +			compatible = "allwinner,sun6i-a31-ahb1-gates-clk";
> +			reg = <0x01c20060 0x8>;
> +			clocks = <&ahb1>;
> +			clock-output-names = "ahb1_mipidsi", "ahb1_ss",
> +					"ahb1_dma", "ahb1_mmc0", "ahb1_mmc1",
> +					"ahb1_mmc2", "ahb1_mmc3", "ahb1_nand1",
> +					"ahb1_nand0", "ahb1_sdram",
> +					"ahb1_gmac", "ahb1_ts", "ahb1_hstimer",
> +					"ahb1_spi0", "ahb1_spi1", "ahb1_spi2",
> +					"ahb1_spi3", "ahb1_otg", "ahb1_ehci0",
> +					"ahb1_ehci1", "ahb1_ohci0",
> +					"ahb1_ohci1", "ahb1_ohci2", "ahb1_ve",
> +					"ahb1_lcd0", "ahb1_lcd1", "ahb1_csi",
> +					"ahb1_hdmi", "ahb1_de0", "ahb1_de1",
> +					"ahb1_fe0", "ahb1_fe1", "ahb1_mp",
> +					"ahb1_gpu", "ahb1_deu0", "ahb1_deu1",
> +					"ahb1_drc0", "ahb1_drc1";
> +		};
> +
> +		apb1: apb1 at 01c20054 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-apb0-clk";
> +			reg = <0x01c20054 0x4>;
> +			clocks = <&ahb1>;
> +		};
> +
> +		apb1_gates: apb1_gates at 01c20060 {
> +			#clock-cells = <1>;
> +			compatible = "allwinner,sun6i-a31-apb1-gates-clk";
> +			reg = <0x01c20068 0x4>;
> +			clocks = <&apb1>;
> +			clock-output-names = "apb1_codec", "apb1_digital_mic",
> +					"apb1_pio", "apb1_daudio0",
> +					"apb1_daudio1";
> +		};
> +
> +		apb2_mux: apb2_mux at 01c20058 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-apb1-mux-clk";
> +			reg = <0x01c20058 0x4>;
> +			clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
> +		};
> +
> +		apb2: apb2 at 01c20058 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun6i-apb2-div-clk";
> +			reg = <0x01c20058 0x4>;
> +			clocks = <&apb2_mux>;
> +		};

Ditto for apb2_mux and apb2.

> +
> +		apb2_gates: apb2_gates at 01c2006c {
> +			#clock-cells = <1>;
> +			compatible = "allwinner,sun6i-a31-apb2-gates-clk";
> +			reg = <0x01c2006c 0x8>;
> +			clocks = <&apb2>;
> +			clock-output-names = "apb2_i2c0", "apb2_i2c1",
> +					"apb2_i2c2", "apb2_i2c3", "apb2_uart0",
> +					"apb2_uart1", "apb2_uart2", "apb2_uart3",
> +					"apb2_uart4", "apb2_uart5";
> +		};
>  	};
>  
>  	soc at 01c20000 {
> @@ -69,7 +186,7 @@
>  			compatible = "allwinner,sun6i-a31-pinctrl";
>  			reg = <0x01c20800 0x400>;
>  			interrupts = <0 11 1>, <0 15 1>, <0 16 1>, <0 17 1>;
> -			clocks = <&osc>;
> +			clocks = <&apb1_gates 5>;
>  			gpio-controller;
>  			interrupt-controller;
>  			#address-cells = <1>;
> @@ -92,7 +209,7 @@
>  				     <0 20 1>,
>  				     <0 21 1>,
>  				     <0 22 1>;
> -			clocks = <&osc>;
> +			clocks = <&osc24M>;
>  		};
>  
>  		wdt1: watchdog at 01c20ca0 {
> @@ -106,7 +223,7 @@
>  			interrupts = <0 0 1>;
>  			reg-shift = <2>;
>  			reg-io-width = <4>;
> -			clocks = <&osc>;
> +			clocks = <&apb2_gates 16>;
>  			status = "disabled";
>  		};
>  
> @@ -116,7 +233,7 @@
>  			interrupts = <0 1 1>;
>  			reg-shift = <2>;
>  			reg-io-width = <4>;
> -			clocks = <&osc>;
> +			clocks = <&apb2_gates 17>;
>  			status = "disabled";
>  		};
>  
> @@ -126,7 +243,7 @@
>  			interrupts = <0 2 1>;
>  			reg-shift = <2>;
>  			reg-io-width = <4>;
> -			clocks = <&osc>;
> +			clocks = <&apb2_gates 18>;
>  			status = "disabled";
>  		};
>  
> @@ -136,7 +253,7 @@
>  			interrupts = <0 3 1>;
>  			reg-shift = <2>;
>  			reg-io-width = <4>;
> -			clocks = <&osc>;
> +			clocks = <&apb2_gates 19>;
>  			status = "disabled";
>  		};
>  
> @@ -146,7 +263,7 @@
>  			interrupts = <0 4 1>;
>  			reg-shift = <2>;
>  			reg-io-width = <4>;
> -			clocks = <&osc>;
> +			clocks = <&apb2_gates 20>;
>  			status = "disabled";
>  		};
>  
> @@ -156,7 +273,7 @@
>  			interrupts = <0 5 1>;
>  			reg-shift = <2>;
>  			reg-io-width = <4>;
> -			clocks = <&osc>;
> +			clocks = <&apb2_gates 21>;
>  			status = "disabled";
>  		};
>  
> 

Thanks for working on this!

Emilio


From 21cnbao at gmail.com  Tue Jul 30 21:40:04 2013
From: 21cnbao at gmail.com (Barry Song)
Date: Wed, 31 Jul 2013 09:40:04 +0800
Subject: [ANNOUNCE] ARM kernel summit 2013, Oct 22-23
In-Reply-To: <CAOesGMjG-6x0Qf0_FEQ7Rw5-p6Dyhf+Wi-tZ7x_cj7iq8UmjFg@mail.gmail.com>
References: <CAOesGMjG-6x0Qf0_FEQ7Rw5-p6Dyhf+Wi-tZ7x_cj7iq8UmjFg@mail.gmail.com>
Message-ID: <CAGsJ_4zbugzzCMuG_85kY0RoBVBpTEBsxuVQ2c5y4tNtSLqmKA@mail.gmail.com>

2013/7/30 Olof Johansson <olof at lixom.net>:
> As previous years, we are planning on hosting a ARM Kernel Summit
> attached to the main Kernel Summit, and we have graciously been given
> space to host it for two days, Oct 22-23 (Oct 23 is the track day for
> the main KS, so we're getting an extra day) in Edinburgh, UK.
>
> To make sure we get the right set of people invited, we're looking for
> people to propose topics they would like to see covered as part of the
> two-day aganda, as well as general invite requests. To request an
> invite or to propose a topic, please send an email to
> ksummit-2013-discuss at lists.linuxfoundation.org, and cc LAKML/LKML as
> appropriate. Please use the tag "[ARM ATTEND]" in the subject to
> distinguish these from the general KS ATTEND threads.
>
> It's pretty obvious that device trees and bindings are hot topics this
> year, with plenty of overlap between ARM and regular kernel summit and
> other subsystems. We are tentatively planning on dedicating Wednesday
> afternoon to the topic, to fit the regular agenda of KS track day to
> make sure as many interested parties as possible can attend. We'd
> still be interested in hearing specific topic requests in that area
> though.

It seems IKS and HMP of b.L are coming to hot. There is a prototype
now, and we need to push it to practice.
and as an user of both mainline and google Android, even there are
many Android patches in mainline now, we still need to maintain both
now. it seems google likes to rebase its patch series againest new
kernel version instead of merging everytime. so what about talking
Android mainlining project more?

>
>
> The group of us organizing and coordinating this year is:
>
> Arnd Bergmann
> Mark Brown
> Kevin Hilman
> Olof Johansson
> Grant Likely

-barry


From mturquette at linaro.org  Tue Jul 30 21:43:28 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 30 Jul 2013 18:43:28 -0700
Subject: [PATCH RFC 3/3] cpufreq: cpufreq-cpu0: clk rate-change notifiers
In-Reply-To: <CAOh2x=kAM98Qta5RquVVByR8jJ3=t+6fNZ4o4WSroVCCZi+0Cg@mail.gmail.com>
References: <1373247868-21444-1-git-send-email-mturquette@linaro.org>
 <1373247868-21444-4-git-send-email-mturquette@linaro.org>
 <CAOh2x=kAM98Qta5RquVVByR8jJ3=t+6fNZ4o4WSroVCCZi+0Cg@mail.gmail.com>
Message-ID: <20130731014328.5270.4248@quantum>

Quoting Viresh Kumar (2013-07-07 21:10:54)
> On Mon, Jul 8, 2013 at 7:14 AM, Mike Turquette <mturquette at linaro.org> wrote:
> > Removes direct handling of OPP tables and voltage regulators by calling
> > of_clk_cpufreq_notifier_handler, introduced by commit "clk: cpufreq
> > helper for voltage scaling".
> >
> > In the future this can help consolidate code found across similar
> > CPUfreq drivers.
> >
> > Signed-off-by: Mike Turquette <mturquette at linaro.org>
> > ---
> >  drivers/cpufreq/cpufreq-cpu0.c | 125 ++++++++---------------------------------
> >  1 file changed, 22 insertions(+), 103 deletions(-)
> 
> Good patch, really gets lots of stuff out from cpufreq drivers.
> 
> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>

Viresh,

Thanks for the Ack. I received no comments on this series besides your
own, so I plan to merge it. Do you want to take patch #3, or do you want
me to take it, or should I give you and Rafael a stable branch instead?

Regards,
Mike


From josephl at nvidia.com  Tue Jul 30 22:27:17 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 31 Jul 2013 10:27:17 +0800
Subject: [PATCH 08/11] clk: tegra114: add suspend/resume function for
 tegar_cpu_car_ops
In-Reply-To: <20130730212100.5270.53947@quantum>
References: <1372152475-18617-1-git-send-email-josephl@nvidia.com>
 <1372152475-18617-9-git-send-email-josephl@nvidia.com>
 <20130730212100.5270.53947@quantum>
Message-ID: <1375237637.1231.1.camel@jlo-ubuntu-64.nvidia.com>

On Wed, 2013-07-31 at 05:21 +0800, Mike Turquette wrote:
> Quoting Joseph Lo (2013-06-25 02:27:52)
> > Adding suspend/resume function for tegra_cpu_car_ops. We only save and
> > restore the setting of the clock of CoreSight. Other clocks still need
> > to be taken care by clock driver.
> > 
> > Cc: Mike Turquette <mturquette at linaro.org>
> > Signed-off-by: Joseph Lo <josephl at nvidia.com>
> 
> Change looks OK to me, besides Stephen's comments. I was waiting for a
> V2 to hit the list but I never saw it. Any plans?
> 
Hi Mike,

The V2 was sent on 2013/7/3.

Thanks,
Joseph




From jh80.chung at samsung.com  Tue Jul 30 23:29:27 2013
From: jh80.chung at samsung.com (Jaehoon Chung)
Date: Wed, 31 Jul 2013 12:29:27 +0900
Subject: [PATCH 4/5] mmc: dw_mmc: Indicate that regulators may be absent
In-Reply-To: <003901ce8d29$610ab3f0$23201bd0$%jun@samsung.com>
References: <1375184777-25404-1-git-send-email-broonie@kernel.org>
 <1375184777-25404-4-git-send-email-broonie@kernel.org>
 <003901ce8d29$610ab3f0$23201bd0$%jun@samsung.com>
Message-ID: <51F88497.5020909@samsung.com>

Acked-by: Jaehoon Chung <jh80.chung at samsung.com>

Best Regards,
Jaehoon Chung

On 07/30/2013 10:33 PM, Seungwon Jeon wrote:
> On Tue, July 30, 2013, Mark Brown wrote:
>> From: Mark Brown <broonie at linaro.org>
>>
>> Use regulator_get_optional() to tell the core that requests for regulators
>> can fail in a real system.
>>
>> Signed-off-by: Mark Brown <broonie at linaro.org>
> Acked-by: Seungwon Jeon <tgih.jun at samsung.com>
> 
> Thanks,
> Seungwon Jeon
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



From mturquette at linaro.org  Tue Jul 30 23:37:21 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 30 Jul 2013 20:37:21 -0700
Subject: [PATCH 08/11] clk: tegra114: add suspend/resume function for
 tegar_cpu_car_ops
In-Reply-To: <1375237637.1231.1.camel@jlo-ubuntu-64.nvidia.com>
References: <1372152475-18617-1-git-send-email-josephl@nvidia.com>
 <1372152475-18617-9-git-send-email-josephl@nvidia.com>
 <20130730212100.5270.53947@quantum>
 <1375237637.1231.1.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <CAPtuhTgsU0mr0ARK1WT=670ct5R158B5eAz3TwWkM-hL+X-hVQ@mail.gmail.com>

On Tue, Jul 30, 2013 at 7:27 PM, Joseph Lo <josephl at nvidia.com> wrote:
> On Wed, 2013-07-31 at 05:21 +0800, Mike Turquette wrote:
>> Quoting Joseph Lo (2013-06-25 02:27:52)
>> > Adding suspend/resume function for tegra_cpu_car_ops. We only save and
>> > restore the setting of the clock of CoreSight. Other clocks still need
>> > to be taken care by clock driver.
>> >
>> > Cc: Mike Turquette <mturquette at linaro.org>
>> > Signed-off-by: Joseph Lo <josephl at nvidia.com>
>>
>> Change looks OK to me, besides Stephen's comments. I was waiting for a
>> V2 to hit the list but I never saw it. Any plans?
>>
> Hi Mike,
>
> The V2 was sent on 2013/7/3.

Ok, looks like Stephen took it into his branch.

Thanks,
Mike

>
> Thanks,
> Joseph
>
>


From rizhao at nvidia.com  Tue Jul 30 23:45:41 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Wed, 31 Jul 2013 11:45:41 +0800
Subject: [PATCH 6/9] serial: tegra: move to generic dma DT binding
In-Reply-To: <51F7EDF2.60700@wwwdotorg.org>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-7-git-send-email-rizhao@nvidia.com>
 <51F2D063.5010505@wwwdotorg.org>
 <20130730033134.GM15855@rizhao-lap> <51F7EDF2.60700@wwwdotorg.org>
Message-ID: <20130731034541.GQ15855@rizhao-lap>

On Wed, Jul 31, 2013 at 12:46:42AM +0800, Stephen Warren wrote:
> On 07/29/2013 09:31 PM, Richard Zhao wrote:
> > On Sat, Jul 27, 2013 at 03:39:15AM +0800, Stephen Warren wrote:
> >> On 07/23/2013 10:09 PM, Richard Zhao wrote:
> >>> - driver: remove use of nvidia,dma-request-selector
> >>> 	  use dma_request_slave_channel to request channel
> >>> - update binding doc
> >>
> >> This patch needs to be amended so that the DMA channel is looked up
> >> during probe() rather than open(), to guarantee that deferred probe
> >> works. It's possible to hold off probe, but not possible AFAIK to hold
> >> off opening the port.
> >
> > How about avoid return -EPROBE_DEFER at open() time? It can be in
> > another patch.
> 
> I don't really understand what you mean. -EPROBE_DEFER is something that
> only makes sense for probe() to return (or functions used by probe()).
> It doesn't make sense to return it anywhere else, since probe deferral
> is something that can only happen for probe().
What I meant is, it might not worth to move request channel to probe
only because we need to check error and return -EPROBE_DEFER.

dma_request_slave_channel is better to be called as late as possible to
make better dynamic use of dma channels.

Actually, I searched the kernel code, most drivers don't return EPROBE_DEFER
when dma_request_slave_channel failed. dma_request_slave_channel can
fail in many cases, and dma device not probed is only one case.

Thanks
Richard


From sachin.kamat at linaro.org  Tue Jul 30 23:48:56 2013
From: sachin.kamat at linaro.org (Sachin Kamat)
Date: Wed, 31 Jul 2013 09:18:56 +0530
Subject: [PATCH 1/3] clk: exynos5250: Add G2D gate clock
In-Reply-To: <20130731034235.5270.7481@quantum>
References: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
 <20130726201800.7598.54329@quantum>
 <CAK9yfHw6KtVDAns-1JhNpiS0brTeUpfiHS-v3q7H2GLWkY-Adw@mail.gmail.com>
 <20130730064800.22022.14773@quantum>
 <CAK9yfHxLjYNjQ9h-N8hNLBvqyUTxNzt=Bw10=mEA=D1kg2f9dw@mail.gmail.com>
 <20130731034235.5270.7481@quantum>
Message-ID: <CAK9yfHxi-4f5UtbRj1oZZ0_jMPFBfsPHnPXoO-020-rsLXEOoQ@mail.gmail.com>

On 31 July 2013 09:12, Mike Turquette <mturquette at linaro.org> wrote:
> Quoting Sachin Kamat (2013-07-29 23:55:33)
>> On 30 July 2013 12:18, Mike Turquette <mturquette at linaro.org> wrote:
>> > Quoting Sachin Kamat (2013-07-27 06:29:56)
>> >> On 27 July 2013 01:48, Mike Turquette <mturquette at linaro.org> wrote:
>> >> > Quoting Sachin Kamat (2013-07-05 01:42:27)
>> >> >> Adds gate clock for G2D IP for Exynos5250 SoC.
>> >> >>
>> >> >> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
>> >> >> Cc: Mike Turquette <mturquette at linaro.org>
>> >> >
>> >> > I've taken patch #1 into clk-next.
>> >>
>> >> Thanks Mike.
>> >>
>> >> >
>> >> >> ---
>> >> >> This patch depends on the following patch:
>> >> >> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20581
>> >> >
>> >> > I think I've gotten all three series you sent out, can you confirm?
>> >>
>> >> I haven't seen any update in your tree [1] since quite some time. The
>> >> last commit I see in clk-next branch is 45e3ec3784 ("clk: tegra: fix
>> >> ifdef for tegra_periph_reset_assert inline"). I hope I am looking at
>> >> the right tree?
>> >
>> > You are, but I had not pushed to it since the merge window closed. It is
>> > now updated.
>> >
>>
>> Thanks Mike. I confirm that all the three patch series that you
>> mentioned are applied in your tree.
>> Please check the below one too.
>>
>> http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg20598.html
>
> Ok, I picked that one up too.

Thanks Mike.

-- 
With warm regards,
Sachin


From mturquette at linaro.org  Tue Jul 30 23:42:35 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 30 Jul 2013 20:42:35 -0700
Subject: [PATCH 1/3] clk: exynos5250: Add G2D gate clock
In-Reply-To: <CAK9yfHxLjYNjQ9h-N8hNLBvqyUTxNzt=Bw10=mEA=D1kg2f9dw@mail.gmail.com>
References: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
 <20130726201800.7598.54329@quantum>
 <CAK9yfHw6KtVDAns-1JhNpiS0brTeUpfiHS-v3q7H2GLWkY-Adw@mail.gmail.com>
 <20130730064800.22022.14773@quantum>
 <CAK9yfHxLjYNjQ9h-N8hNLBvqyUTxNzt=Bw10=mEA=D1kg2f9dw@mail.gmail.com>
Message-ID: <20130731034235.5270.7481@quantum>

Quoting Sachin Kamat (2013-07-29 23:55:33)
> On 30 July 2013 12:18, Mike Turquette <mturquette at linaro.org> wrote:
> > Quoting Sachin Kamat (2013-07-27 06:29:56)
> >> On 27 July 2013 01:48, Mike Turquette <mturquette at linaro.org> wrote:
> >> > Quoting Sachin Kamat (2013-07-05 01:42:27)
> >> >> Adds gate clock for G2D IP for Exynos5250 SoC.
> >> >>
> >> >> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> >> >> Cc: Mike Turquette <mturquette at linaro.org>
> >> >
> >> > I've taken patch #1 into clk-next.
> >>
> >> Thanks Mike.
> >>
> >> >
> >> >> ---
> >> >> This patch depends on the following patch:
> >> >> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20581
> >> >
> >> > I think I've gotten all three series you sent out, can you confirm?
> >>
> >> I haven't seen any update in your tree [1] since quite some time. The
> >> last commit I see in clk-next branch is 45e3ec3784 ("clk: tegra: fix
> >> ifdef for tegra_periph_reset_assert inline"). I hope I am looking at
> >> the right tree?
> >
> > You are, but I had not pushed to it since the merge window closed. It is
> > now updated.
> >
> 
> Thanks Mike. I confirm that all the three patch series that you
> mentioned are applied in your tree.
> Please check the below one too.
> 
> http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg20598.html

Ok, I picked that one up too.

Regards,
Mike

> 
> -- 
> With warm regards,
> Sachin


From rizhao at nvidia.com  Tue Jul 30 23:52:56 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Wed, 31 Jul 2013 11:52:56 +0800
Subject: [PATCH 2/9] dma: tegra20-apbdma: move to generic device tree
 bindings
In-Reply-To: <51F7ED62.4060404@wwwdotorg.org>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-3-git-send-email-rizhao@nvidia.com>
 <51F2CDBE.40802@wwwdotorg.org> <20130730030644.GJ15855@rizhao-lap>
 <51F7ED62.4060404@wwwdotorg.org>
Message-ID: <20130731035256.GR15855@rizhao-lap>

On Wed, Jul 31, 2013 at 12:44:18AM +0800, Stephen Warren wrote:
> On 07/29/2013 09:06 PM, Richard Zhao wrote:
> > On Sat, Jul 27, 2013 at 03:27:58AM +0800, Stephen Warren wrote:
> >> (Stripping the Cc list a lot)
> >>
> >> On 07/23/2013 10:09 PM, Richard Zhao wrote:
> >>> Update tegra20-apbdma driver to adopt generic DMA device tree bindings.
> >>> It calls of_dma_controller_register() with of_dma_simple_xlate to get
> >>> the generic DMA device tree helper support. The #dma-cells for apbdma
> >>> must be 1, which is slave ID.
> >>>
> >>> The existing nvidia,dma-request-selector still works there, and the
> >>> support will be removed after all clients get converted to generic DMA
> >>> device tree helper.
> 
> >>> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> >>
> >>> +static bool tegra_dma_filter_fn(struct dma_chan *dc, void *param)
> >>> +{
> >>> +	if (dc->device->dev->driver == &tegra_dmac_driver.driver) {
> >>> +		struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
> >>> +		unsigned req = *(unsigned *)param;
> >>> +
> >>> +		tdc->slave_id = req;
> >>> +
> >>> +		return true;
> >>> +	}
> >>> +	return false;
> >>> +}
> >>> +
> >>> +static struct of_dma_filter_info tegra_dma_info = {
> >>> +	.filter_fn = tegra_dma_filter_fn,
> >>> +};
> >>
> >> Why does this driver need to define a filter function? I thought the
> >> dmaengine's DT support would already match DMA clients/engines based on
> >> the phandle in DT? Isn't the need to pass the slave channel ID into
> >> drivers something pretty fundamental to dmaengine, and hence something
> >> it already supports?
> >
> > of_dma_simple_xlate only pass slave id to filter function. It needs
> > change to pass dt node too. I didn't start work on the common code
> > change yet. Do you think we need to hold it until common code change?
> 
> Oh dear, I can't see how the core DT DMA support can work for anyone
> without the ability to limit DMA clients to the specific DMA controller
> that's specified in DT. If that functionality truly is missing, then it
> certainly needs to be added first.

omap-dma uses the same way. 



From mturquette at linaro.org  Wed Jul 31 00:00:56 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 30 Jul 2013 21:00:56 -0700
Subject: [PATCH Resend 1/1] clk: exynos4: Add clock entries for TMU
In-Reply-To: <0eb201ce8866$212e3080$638a9180$@org>
References: <1374660555-17429-1-git-send-email-sachin.kamat@linaro.org>
 <0eb201ce8866$212e3080$638a9180$@org>
Message-ID: <20130731040056.24490.65774@quantum>

Quoting Kukjin Kim (2013-07-24 05:05:46)
> Sachin Kamat wrote:
> > 
> > Added clock entries for thermal management unit (TMU) for
> > Exynos4 SoCs.
> > 
> > Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> 
> Acked-by: Kukjin Kim <kgene.kim at samsung.com>
> 
> Mike, I remember you're ok this for v3.12 so if you do not apply this in
> clk-next yet, please go ahead :)

You remember correctly. I've pulled this into clk-next.

Regards,
Mike

> 
> Thanks,
> Kukjin
> 
> > ---
> > Resending this (after rebasing) based on the below discussion:
> > http://comments.gmane.org/gmane.linux.kernel.samsung-soc/19933
> > 
> > Previous version:
> > http://comments.gmane.org/gmane.linux.kernel.samsung-soc/18081
> > ---
> >  .../devicetree/bindings/clock/exynos4-clock.txt    |    1 +
> >  drivers/clk/samsung/clk-exynos4.c                  |    4 +++-
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> > b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> > index 14d5c2a..c6bf8a6 100644
> > --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> > +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
> > @@ -236,6 +236,7 @@ Exynos4 SoC and this is specified where applicable.
> >    spi0_isp_sclk       380     Exynos4x12
> >    spi1_isp_sclk       381     Exynos4x12
> >    uart_isp_sclk       382     Exynos4x12
> > +  tmu_apbif           383
> > 
> >               [Mux Clocks]
> > 
> > diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-
> > exynos4.c
> > index 75635eb..cee297d 100644
> > --- a/drivers/clk/samsung/clk-exynos4.c
> > +++ b/drivers/clk/samsung/clk-exynos4.c
> > @@ -169,7 +169,7 @@ enum exynos4_clks {
> >       gicisp, smmu_isp, smmu_drc, smmu_fd, smmu_lite0, smmu_lite1,
> > mcuctl_isp,
> >       mpwm_isp, i2c0_isp, i2c1_isp, mtcadc_isp, pwm_isp, wdt_isp,
> > uart_isp,
> >       asyncaxim, smmu_ispcx, spi0_isp, spi1_isp, pwm_isp_sclk,
> > spi0_isp_sclk,
> > -     spi1_isp_sclk, uart_isp_sclk,
> > +     spi1_isp_sclk, uart_isp_sclk, tmu_apbif,
> > 
> >       /* mux clocks */
> >       mout_fimc0 = 384, mout_fimc1, mout_fimc2, mout_fimc3, mout_cam0,
> > @@ -814,6 +814,7 @@ static struct samsung_gate_clock
> exynos4210_gate_clks[]
> > __initdata = {
> >       GATE_A(keyif, "keyif", "aclk100", E4210_GATE_IP_PERIR, 16, 0, 0,
> > "keypad"),
> >       GATE_DA(sclk_fimd1, "exynos4-fb.1", "sclk_fimd1", "div_fimd1",
> >                       E4210_SRC_MASK_LCD1, 0, CLK_SET_RATE_PARENT, 0,
> > "sclk_fimd"),
> > +     GATE(tmu_apbif, "tmu_apbif", "aclk100", E4210_GATE_IP_PERIR, 17, 0,
> > 0),
> >  };
> > 
> >  /* list of gate clocks supported in exynos4x12 soc */
> > @@ -915,6 +916,7 @@ static struct samsung_gate_clock
> exynos4x12_gate_clks[]
> > __initdata = {
> >       GATE(spi1_isp, "spi1_isp", "aclk200", E4X12_GATE_ISP1, 13,
> >                       CLK_IGNORE_UNUSED, 0),
> >       GATE(g2d, "g2d", "aclk200", GATE_IP_DMC, 23, 0, 0),
> > +     GATE(tmu_apbif, "tmu_apbif", "aclk100", E4X12_GATE_IP_PERIR, 17, 0,
> > 0),
> >  };
> > 
> >  /*
> > --
> > 1.7.9.5


From mturquette at linaro.org  Wed Jul 31 00:02:23 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Tue, 30 Jul 2013 21:02:23 -0700
Subject: [PATCH v2 Resend 2/3] of/documentation: Update G2D documentation
In-Reply-To: <1373351355-27444-1-git-send-email-sachin.kamat@linaro.org>
References: <1373351355-27444-1-git-send-email-sachin.kamat@linaro.org>
Message-ID: <20130731040223.24490.62098@quantum>

Quoting Sachin Kamat (2013-07-08 23:29:15)
> Exynos5250 G2D IP requires only the gate clock. Update the
> binding documentation accordingly.
> 
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> Cc: Inki Dae <inki.dae at samsung.com>

Taken into clk-next.

Thanks,
Mike

> ---
> Updated the description of clock-names as suggested by Tomasz Figa.
> ---
>  .../devicetree/bindings/gpu/samsung-g2d.txt        |    7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
> index 3f454ff..c4f358d 100644
> --- a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
> +++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
> @@ -11,8 +11,11 @@ Required properties:
>  
>    - interrupts : G2D interrupt number to the CPU.
>    - clocks : from common clock binding: handle to G2D clocks.
> -  - clock-names : from common clock binding: must contain "sclk_fimg2d" and
> -                 "fimg2d", corresponding to entries in the clocks property.
> +  - clock-names : names of clocks listed in clocks property, in the same
> +                 order, depending on SoC type:
> +                 - for S5PV210 and Exynos4 based SoCs: "fimg2d" and
> +                   "sclk_fimg2d"
> +                 - for Exynos5250 SoC: "fimg2d".
>  
>  Example:
>         g2d at 12800000 {
> -- 
> 1.7.9.5


From viresh.kumar at linaro.org  Wed Jul 31 00:39:03 2013
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Wed, 31 Jul 2013 10:09:03 +0530
Subject: [PATCH RFC 3/3] cpufreq: cpufreq-cpu0: clk rate-change notifiers
In-Reply-To: <20130731014328.5270.4248@quantum>
References: <1373247868-21444-1-git-send-email-mturquette@linaro.org>
 <1373247868-21444-4-git-send-email-mturquette@linaro.org>
 <CAOh2x=kAM98Qta5RquVVByR8jJ3=t+6fNZ4o4WSroVCCZi+0Cg@mail.gmail.com>
 <20130731014328.5270.4248@quantum>
Message-ID: <CAKohpom-8KXixJ0ZbQ7Poh3uqJCqo7LFyYEfYeMyp+yZx9QmHA@mail.gmail.com>

On 31 July 2013 07:13, Mike Turquette <mturquette at linaro.org> wrote:
> Quoting Viresh Kumar (2013-07-07 21:10:54)
>> On Mon, Jul 8, 2013 at 7:14 AM, Mike Turquette <mturquette at linaro.org> wrote:
>> > Removes direct handling of OPP tables and voltage regulators by calling
>> > of_clk_cpufreq_notifier_handler, introduced by commit "clk: cpufreq
>> > helper for voltage scaling".
>> >
>> > In the future this can help consolidate code found across similar
>> > CPUfreq drivers.
>> >
>> > Signed-off-by: Mike Turquette <mturquette at linaro.org>
>> > ---
>> >  drivers/cpufreq/cpufreq-cpu0.c | 125 ++++++++---------------------------------
>> >  1 file changed, 22 insertions(+), 103 deletions(-)
>>
>> Good patch, really gets lots of stuff out from cpufreq drivers.
>>
>> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
>
> Viresh,
>
> Thanks for the Ack. I received no comments on this series besides your
> own, so I plan to merge it. Do you want to take patch #3, or do you want
> me to take it, or should I give you and Rafael a stable branch instead?

Its only related to cpufreq-cpu0 and to handle dependencies well they
should go through a single tree.. Probably your tree is the right place for
now. Rafael?


From shawn.guo at linaro.org  Wed Jul 31 01:20:34 2013
From: shawn.guo at linaro.org (Shawn Guo)
Date: Wed, 31 Jul 2013 13:20:34 +0800
Subject: [PATCH 1/2] pinctrl: imx: Add exception hook for select input
In-Reply-To: <20130730083803.GF12382@S2101-09.ap.freescale.net>
References: <1375152857-32177-1-git-send-email-peter.chen@freescale.com>
 <20130730075018.GD12382@S2101-09.ap.freescale.net>
 <20130730080028.GA8540@nchen-desktop>
 <20130730083803.GF12382@S2101-09.ap.freescale.net>
Message-ID: <20130731052031.GA19098@S2101-09.ap.freescale.net>

On Tue, Jul 30, 2013 at 04:38:05PM +0800, Shawn Guo wrote:
> On Tue, Jul 30, 2013 at 04:00:29PM +0800, Peter Chen wrote:
> > I searched the RM, this is the only one. If you don't think we need
> > to consider if it will occur in the future, I am OK to move it at machine
> > code, but every mx6q board need it if it does not use default select input
> > value.
> 
> Yes, maybe you can put it into imx6q_usb_init() with
> if (IS_ENABLED(CONFIG_USB_OTG)) protect.

I misunderstood it.  As it varies from board to board, we can not nicely
handle it in mach-imx6q.c.  I have some other idea to solve the problem,
and will cook up a patch to demonstrate it.

Shawn



From joelf at ti.com  Wed Jul 31 01:06:33 2013
From: joelf at ti.com (Joel Fernandes)
Date: Wed, 31 Jul 2013 00:06:33 -0500
Subject: [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA
 resources
In-Reply-To: <51F7E9D0.1080107@ti.com>
References: <1374515989-7391-1-git-send-email-joelf@ti.com>
 <51F61359.1090309@ti.com> <51F73738.6080901@ti.com> <51F7E9D0.1080107@ti.com>
Message-ID: <51F89B59.6010708@ti.com>

On 07/30/2013 11:29 AM, Sekhar Nori wrote:
> On 7/30/2013 9:17 AM, Joel Fernandes wrote:
> 
>>>> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
>>>> index a432e6c..765d578 100644
>>>> --- a/arch/arm/common/edma.c
>>>> +++ b/arch/arm/common/edma.c
> 
>>>> +	} else {
>>>> +		for (; i < pdev->num_resources; i++) {
>>>> +			if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
>>>> +			    (int)pdev->resource[i].start >= 0) {
>>>> +				ctlr = EDMA_CTLR(pdev->resource[i].start);
>>>> +				clear_bit(EDMA_CHAN_SLOT(
>>>> +					  pdev->resource[i].start),
>>>> +					  edma_cc[ctlr]->edma_unused);
>>>> +			}
>>>
>>> So there is very little in common between OF and non-OF versions of this
>>> function. Why not have two different versions of this function for the
>>> two cases? The OF version can reside under the CONFIG_OF conditional
>>> already in use in the file. This will also save you the ugly line breaks
>>> you had to resort to due to too deep indentation.
>>
>> Actually those line breaks are not necessary and wouldn't result in
>> compilation errors. I was planning to drop them. I'll go ahead and split
>> it out anyway, now that also the OF version of the function is going to
>> be bit longer if we use the of_parse functions.
>>
>> Thanks for your review,
> 
> It turns out, I gave a bad idea. What I suggested will break the case of
> non-DT boot with CONFIG_OF enabled. So what you had was fine. May be
> just return from "if (dev->of_node)" so you don't need to have an else
> block and can save on the indentation.>

Ok, sure. I will go ahead and return from the if block.

Thanks,

-Joel




From joelf at ti.com  Wed Jul 31 01:05:15 2013
From: joelf at ti.com (Joel Fernandes)
Date: Wed, 31 Jul 2013 00:05:15 -0500
Subject: [PATCH 7/9] ARM: edma: Don't clear EMR of channel in edma_stop
In-Reply-To: <51F77982.7030601@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
 <1375104595-16018-8-git-send-email-joelf@ti.com> <51F77982.7030601@ti.com>
Message-ID: <51F89B0B.4080803@ti.com>

On 07/30/2013 03:29 AM, Sekhar Nori wrote:
> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>> We certainly don't want error conditions to be cleared anywhere
> 
> 'anywhere' is a really loaded term.
> 
>> as this will make us 'forget' about missed events. We depend on
>> knowing which events were missed in order to be able to reissue them.
> 
>> This fixes a race condition where the EMR was being cleared
>> by the transfer completion interrupt handler.
>>
>> Basically, what was happening was:
>>
>>             Missed event
>>              |
>>              |
>>              V
>> SG1-SG2-SG3-Null
>>          \
>>           \__TC Interrupt (Almost same time as ARM is executing
>> TC interrupt handler, an event got missed and also forgotten
>> by clearing the EMR).
> 
> Sorry, but I dont see how edma_stop() is coming into picture in the race
> you describe?

In edma_callback function, for the case of DMA_COMPLETE (Transfer
completion interrupt), edma_stop() is called when all sets have been
processed. This had the effect of clearing the EMR.

This has 2 problems:

1.
If error interrupt is also pending and TC interrupt clears the EMR.

Due to this the ARM will execute the error interrupt even though the EMR
is clear. As a result, the following if condition in dma_ccerr_handler
will be true and IRQ_NONE is returned.

        if ((edma_read_array(ctlr, EDMA_EMR, 0) == 0) &&
            (edma_read_array(ctlr, EDMA_EMR, 1) == 0) &&
            (edma_read(ctlr, EDMA_QEMR) == 0) &&
            (edma_read(ctlr, EDMA_CCERR) == 0))
                return IRQ_NONE;

If this happens enough number of times, IRQ subsystem disables the
interrupt thinking its spurious which creates serious problems.

2.
If the above if statement condition is removed, then EMR is 0 so the
callback function will not be called in dma_ccerr_handler thus the event
is forgotten, never triggered manually or never sets missed flag of the
channel.

So about the race: TC interrupt handler executing before the error
interrupt handler can result in clearing the EMR and creates these problems.

>> The EMR is ultimately being cleared by the Error interrupt
>> handler once it is handled so we don't have to do it in edma_stop.
> 
> This, I agree with. edma_clean_channel() also there to re-initialize the
> channel so doing it in edma_stop() certainly seems superfluous.

Sure.

Thanks,

-Joel


From joelf at ti.com  Wed Jul 31 00:49:39 2013
From: joelf at ti.com (Joel Fernandes)
Date: Tue, 30 Jul 2013 23:49:39 -0500
Subject: [PATCH 4/9] dma: edma: Find missed events and issue them
In-Reply-To: <51F7659E.3040302@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
 <1375104595-16018-5-git-send-email-joelf@ti.com> <51F7659E.3040302@ti.com>
Message-ID: <51F89763.1010102@ti.com>

Hi Sekhar,

On 07/30/2013 02:05 AM, Sekhar Nori wrote:
> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>> In an effort to move to using Scatter gather lists of any size with
>> EDMA as discussed at [1] instead of placing limitations on the driver,
>> we work through the limitations of the EDMAC hardware to find missed
>> events and issue them.
>>
>> The sequence of events that require this are:
>>
>> For the scenario where MAX slots for an EDMA channel is 3:
>>
>> SG1 -> SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> Null
>>
>> The above SG list will have to be DMA'd in 2 sets:
>>
>> (1) SG1 -> SG2 -> SG3 -> Null
>> (2) SG4 -> SG5 -> SG6 -> Null
>>
>> After (1) is succesfully transferred, the events from the MMC controller
>> donot stop coming and are missed by the time we have setup the transfer
>> for (2). So here, we catch the events missed as an error condition and
>> issue them manually.
> 
> Are you sure there wont be any effect of these missed events on the
> peripheral side. For example, wont McASP get into an underrun condition
> when it encounters a null PaRAM set? Even UART has to transmit to a

But it will not encounter null PaRAM set because McASP uses contiguous
buffers for transfer which are not scattered across physical memory.
This can be accomplished with an SG of size 1. For such SGs, this patch
series leaves it linked Dummy and does not link to Null set. Null set is
only used for SG lists that are > MAX_NR_SG in size such as those
created for example by MMC and Crypto.

> particular baud so I guess it cannot wait like the way MMC/SD can.

Existing driver have to wait anyway if they hit MAX SG limit today. If
they don't want to wait, they would have allocated a contiguous block of
memory and DMA that in one stretch so they don't lose any events, and in
such cases we are not linking to Null.

> Also, wont this lead to under-utilization of the peripheral bandwith?
> Meaning, MMC/SD is ready with data but cannot transfer because the DMA
> is waiting to be set-up.

But it is waiting anyway even today. Currently based on MAX segs, MMC
driver/subsystem will make SG list of size max_segs. Between these
sessions of creating such smaller SG-lists, if for some reason the MMC
controller is sending events, these will be lost anyway.

What will happen now with this patch series is we are simply accepting a
bigger list than this, and handling all the max_segs stuff within the
EDMA driver itself without outside world knowing. This is actually more
efficient as for long transfers, we are not going back and forth much
between the client and EDMA driver.

> Did you consider a ping-pong scheme with say three PaRAM sets per
> channel? That way you can keep a continuous transfer going on from the
> peripheral over the complete SG list.

Do you mean ping-pong scheme as used in the davinci-pcm driver today?
This can be used only for buffers that are contiguous in memory, not
those that are scattered across memory.

Thanks,

-Joel


From joelf at ti.com  Wed Jul 31 00:30:10 2013
From: joelf at ti.com (Joel Fernandes)
Date: Tue, 30 Jul 2013 23:30:10 -0500
Subject: [PATCH 3/9] ARM: edma: Add function to manually trigger an EDMA
 channel
In-Reply-To: <51F74CAD.3040604@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
 <1375104595-16018-4-git-send-email-joelf@ti.com> <51F74CAD.3040604@ti.com>
Message-ID: <51F892D2.4090805@ti.com>

On 07/30/2013 12:18 AM, Sekhar Nori wrote:
> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>> Manual trigger for events missed as a result of splitting a
>> scatter gather list and DMA'ing it in batches. Add a helper
>> function to trigger a channel incase any such events are missed.
>>
>> Signed-off-by: Joel Fernandes <joelf at ti.com>
>> ---
>>  arch/arm/common/edma.c             |   21 +++++++++++++++++++++
>>  include/linux/platform_data/edma.h |    2 ++
>>  2 files changed, 23 insertions(+)
>>
>> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
>> index 3567ba1..10995b2 100644
>> --- a/arch/arm/common/edma.c
>> +++ b/arch/arm/common/edma.c
>> @@ -1236,6 +1236,27 @@ void edma_resume(unsigned channel)
>>  }
>>  EXPORT_SYMBOL(edma_resume);
>>  
>> +int edma_manual_trigger(unsigned channel)
> 
> edma_trigger_channel() maybe? Brings consistency with
> edma_alloc_channel() edma_free_channel() etc.

Ok, sure.

> 
>> +{
>> +	unsigned ctlr;
>> +	int j;
>> +	unsigned int mask;
>> +
>> +	ctlr = EDMA_CTLR(channel);
>> +	channel = EDMA_CHAN_SLOT(channel);
>> +	mask = BIT(channel & 0x1f);
>> +
>> +	j = channel >> 5;
>> +
>> +	/* EDMA channels without event association */
> 
> May be actually check for no-event association before you trigger in
> software? You can do that by looking at unused channel list, no?

But, we want to trigger whether there is event association or not in
this function. For ex, MMC has event associated but still this function
is used to trigger event for it.

> 
>> +	edma_shadow0_write_array(ctlr, SH_ESR, j, mask);
> 
> edma_shadow0_write_array(ctlr, SH_ESR, channel >> 5, mask) is no less
> readable, but I leave it to you.

Sure that's more readable, will changed it to that.

Thanks,

-Joel



From nsekhar at ti.com  Wed Jul 31 01:23:42 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 31 Jul 2013 10:53:42 +0530
Subject: [PATCH 3/9] ARM: edma: Add function to manually trigger an EDMA
 channel
In-Reply-To: <51F892D2.4090805@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
 <1375104595-16018-4-git-send-email-joelf@ti.com> <51F74CAD.3040604@ti.com>
 <51F892D2.4090805@ti.com>
Message-ID: <51F89F5E.2050605@ti.com>

On Wednesday 31 July 2013 10:00 AM, Joel Fernandes wrote:
> On 07/30/2013 12:18 AM, Sekhar Nori wrote:
>> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>>> Manual trigger for events missed as a result of splitting a
>>> scatter gather list and DMA'ing it in batches. Add a helper
>>> function to trigger a channel incase any such events are missed.
>>>
>>> Signed-off-by: Joel Fernandes <joelf at ti.com>
>>> ---
>>>  arch/arm/common/edma.c             |   21 +++++++++++++++++++++
>>>  include/linux/platform_data/edma.h |    2 ++
>>>  2 files changed, 23 insertions(+)
>>>
>>> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
>>> index 3567ba1..10995b2 100644
>>> --- a/arch/arm/common/edma.c
>>> +++ b/arch/arm/common/edma.c
>>> @@ -1236,6 +1236,27 @@ void edma_resume(unsigned channel)
>>>  }
>>>  EXPORT_SYMBOL(edma_resume);
>>>  
>>> +int edma_manual_trigger(unsigned channel)
>>
>> edma_trigger_channel() maybe? Brings consistency with
>> edma_alloc_channel() edma_free_channel() etc.
> 
> Ok, sure.
> 
>>
>>> +{
>>> +	unsigned ctlr;
>>> +	int j;
>>> +	unsigned int mask;
>>> +
>>> +	ctlr = EDMA_CTLR(channel);
>>> +	channel = EDMA_CHAN_SLOT(channel);
>>> +	mask = BIT(channel & 0x1f);
>>> +
>>> +	j = channel >> 5;
>>> +
>>> +	/* EDMA channels without event association */
>>
>> May be actually check for no-event association before you trigger in
>> software? You can do that by looking at unused channel list, no?
> 
> But, we want to trigger whether there is event association or not in
> this function. For ex, MMC has event associated but still this function
> is used to trigger event for it.

Okay, just drop the misleading comment then.

Regards,
Sekhar


From r.sh.open at gmail.com  Wed Jul 31 01:25:44 2013
From: r.sh.open at gmail.com (Rahul Sharma)
Date: Wed, 31 Jul 2013 10:55:44 +0530
Subject: [PATCH v4 0/6] clk/exynos5250: add clocks for hdmi subsystem
In-Reply-To: <20130730210814.5270.44742@quantum>
References: <1374728857-4208-1-git-send-email-rahul.sharma@samsung.com>
 <20130730210814.5270.44742@quantum>
Message-ID: <CAPdUM4OQLAZaVrsR3TMQbwWihdh+rMZ6JJPt-L32KQethXhUwg@mail.gmail.com>

On Wed, Jul 31, 2013 at 2:38 AM, Mike Turquette <mturquette at linaro.org> wrote:
> Quoting Rahul Sharma (2013-07-24 22:07:31)
>> Add clock changes for hdmi subsystem for exynos5250 SoC. These
>> include addition of new clocks like mout_hdmi and smmu_tv, associating
>> ID to clk_hdmiphy and some essential corrections.
>>
>> This set is based on kukjin's for-next branch at
>> http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.
>
> I've taken patches 2-4 into the clk-next branch. Patch #1 can be
> dropped.
>
> Patches 5 & 6 need to be rebased onto clk-next as the g2d clock has
> reserved mapping 345.  Also I've cc'd Cho KyongHo who is rebasing his
> system mmu clock patch[1] onto clk-next. Can the two of your coordinate
> your changes to avoid mapping conflicts in the binding? Perhaps Rahul
> can carry Cho's patch in his next version when he rebases patches 5 & 6.
>
> Thanks,
> Mike
>

Thanks Mike,

I will rebase and post 5, 6 on top of Cho's patches (based on  clk-next) .

regards,
Rahul Sharma.

> [1] https://lkml.org/lkml/2013/7/30/51
>
>>
>> V4:
>> 1) Added Arun's patch hdmi clock number correction in this series.
>> 2) Corrected clock number for smmu_mixer
>>
>> V3:
>> 1) Rebase to kgene for-next based on 3.11-rc1.
>> 2) Added Tushar's patch in the series.
>>
>> V2:
>> 1) Dropped "clk/exynos5250: Fix HDMI clock number in documentation" as
>> it already get merged.
>>
>> Arun Kumar K (1):
>>   clk/exynos5250: Fix HDMI clock number in documentation
>>
>> Rahul Sharma (4):
>>   clk/exynos5250: add mout_hdmi mux clock for hdmi
>>   clk/exynos5250: add sclk_hdmiphy in the list of special clocks
>>   clk/exynos5250: add clock for mixer sysmmu
>>   clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem
>>
>> Tushar Behera (1):
>>   Documentation: exynos5250-clock: Add div_i2s1 and div_i2s2
>>
>>  .../devicetree/bindings/clock/exynos5250-clock.txt |   14 +++++++++++++-
>>  drivers/clk/samsung/clk-exynos5250.c               |   20 ++++++++++++++------
>>  2 files changed, 27 insertions(+), 7 deletions(-)
>>
>> --
>> 1.7.10.4


From joelf at ti.com  Wed Jul 31 01:34:14 2013
From: joelf at ti.com (Fernandes, Joel)
Date: Wed, 31 Jul 2013 05:34:14 +0000
Subject: [PATCH 3/9] ARM: edma: Add function to manually trigger an EDMA
 channel
In-Reply-To: <51F89F5E.2050605@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
 <1375104595-16018-4-git-send-email-joelf@ti.com> <51F74CAD.3040604@ti.com>
 <51F892D2.4090805@ti.com>,<51F89F5E.2050605@ti.com>
Message-ID: <D8824BFD-347E-4544-9024-2BE52D68100D@ti.com>

On Jul 31, 2013, at 12:23 AM, "Nori, Sekhar" <nsekhar at ti.com> wrote:

> On Wednesday 31 July 2013 10:00 AM, Joel Fernandes wrote:
>> On 07/30/2013 12:18 AM, Sekhar Nori wrote:
>>> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>>>> Manual trigger for events missed as a result of splitting a
>>>> scatter gather list and DMA'ing it in batches. Add a helper
>>>> function to trigger a channel incase any such events are missed.
>>>> 
>>>> Signed-off-by: Joel Fernandes <joelf at ti.com>
>>>> ---
>>>> arch/arm/common/edma.c             |   21 +++++++++++++++++++++
>>>> include/linux/platform_data/edma.h |    2 ++
>>>> 2 files changed, 23 insertions(+)
>>>> 
>>>> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
>>>> index 3567ba1..10995b2 100644
>>>> --- a/arch/arm/common/edma.c
>>>> +++ b/arch/arm/common/edma.c
>>>> @@ -1236,6 +1236,27 @@ void edma_resume(unsigned channel)
>>>> }
>>>> EXPORT_SYMBOL(edma_resume);
>>>> 
>>>> +int edma_manual_trigger(unsigned channel)
>>> 
>>> edma_trigger_channel() maybe? Brings consistency with
>>> edma_alloc_channel() edma_free_channel() etc.
>> 
>> Ok, sure.
>> 
>>> 
>>>> +{
>>>> +    unsigned ctlr;
>>>> +    int j;
>>>> +    unsigned int mask;
>>>> +
>>>> +    ctlr = EDMA_CTLR(channel);
>>>> +    channel = EDMA_CHAN_SLOT(channel);
>>>> +    mask = BIT(channel & 0x1f);
>>>> +
>>>> +    j = channel >> 5;
>>>> +
>>>> +    /* EDMA channels without event association */
>>> 
>>> May be actually check for no-event association before you trigger in
>>> software? You can do that by looking at unused channel list, no?
>> 
>> But, we want to trigger whether there is event association or not in
>> this function. For ex, MMC has event associated but still this function
>> is used to trigger event for it.
> 
> Okay, just drop the misleading comment then.

Ok, will do.

Thanks,

-Joel

> 
> Regards,
> Sekhar


From olof at lixom.net  Wed Jul 31 01:36:23 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 30 Jul 2013 22:36:23 -0700
Subject: New dapm panic on beaver with next-20130730
Message-ID: <CAOesGMig6jry1GJLoTnOqxom1KjtBTUtZz-_-SiZLpGTc3VkqA@mail.gmail.com>

Hi Mark, Lars-Peter,

I noticed the below panic on beaver (Tegra30). Seems like seaboard
(Tegra20) is fine. This is with next-20130730, tegra_defconfig.

I noticed a bunch of recent dapm changes in the asoc tree on the 29th,
and I was able to bisect it down to:

commit 5106b92f80a2cd37c52cffed80b4f5acfb77ccfd
Author: Lars-Peter Clausen <lars at metafoo.de>
Date:   Mon Jul 29 17:14:00 2013 +0200

    ASoC: dapm: Keep a list of paths per kcontrol

    Currently we store for each path which control (if any at all) is associated
    with that control. But we are only ever interested in the reverse
relationship,
    i.e. we want to know all the paths a certain control is associated
with. This is
    currently implemented by always iterating over all paths. This
patch updates the
    code to keep a list for each control which contains all the paths that are
    associated with that control. This improves the run time of e.g.
    soc_dapm_mixer_update_power() and soc_dapm_mux_update_power() from
O(n) (with n
    being the number of paths for the card) to O(1).

    Signed-off-by: Lars-Peter Clausen <lars at metafoo.de>
    Signed-off-by: Mark Brown <broonie at linaro.org>


Panic output is below. I need to figure out why I'm not actually
getting a backtrace in panics any more as well so this is of somewhat
limited use, unfortuantely.

Running a brute force function lookup on all words on the stack gives
a rough idea of call path though:

c03b1bb4   dapm_clear_walk_output
c03b3450   dapm_generic_check_power
c03b56b0   dapm_power_widgets
c03b608c   snd_soc_dapm_new_widgets
[c069f8f8   kallsyms_token_index]
c03ae9fc   soc_post_component_init
c03b0dd0   soc_probe_link_dais
c069abb0   kallsyms_token_index
[c029ac24   devm_kzalloc_release]
c03b1870   snd_soc_register_card
c03c3964   tegra_rt5640_probe
c0707b74   tegra_rt5640_driver_init
c02999e0   platform_drv_probe
c02999c8   platform_drv_probe
c029878c   driver_probe_device


[    1.845620] Unable to handle kernel paging request at virtual
address 6b6b6bd3
[    1.852855] pgd = c0004000
[    1.855552] [6b6b6bd3] *pgd=00000000
[    1.859125] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[    1.864422] Modules linked in:
[    1.867473] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.11.0-rc3-next-20130730 #42
[    1.875023] task: ef064a40 ti: ef074000 task.ti: ef074000
[    1.880421] PC is at dapm_clear_walk_output+0x8/0x68
[    1.885371] LR is at dapm_clear_walk_output+0x54/0x68
[    1.890408] pc : [<c03bb77c>]    lr : [<c03bb7c8>]    psr: 20000113
[    1.890408] sp : ef075ce8  ip : 00000000  fp : 00000010
[    1.901858] r10: ef075d2c  r9 : c076dd00  r8 : c076dbf8
[    1.907066] r7 : ef075d34  r6 : eeb490b8  r5 : 6b6b6bd3  r4 : ef39c4b0
[    1.913574] r3 : 00000069  r2 : 00000192  r1 : 6b6b6bd3  r0 : eeb490b8
[    1.920084] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment kernel
[    1.927372] Control: 10c5387d  Table: 8000404a  DAC: 00000015
[    1.933101] Process swapper/0 (pid: 1, stack limit = 0xef074238)
[    1.939090] Stack: (0xef075ce8 to 0xef076000)
[    1.943434] 5ce0:                   ef39c4b0 ef3ad728 eeb490b8
c03bb7c8 ef3ad6c0 00000000
[    1.951591] 5d00: 00000000 c03bd074 c076dcf8 ef3ad6c0 ef075d3c
c03bf310 00000000 c076dcf8
[    1.959747] 5d20: 00000000 eec537f0 c077ca0c ef075d2c ef075d2c
ef075d34 ef075d34 ef075d3c
[    1.967904] 5d40: ef075d3c c01c298c eec66734 ef3ad584 c076dcd4
000000f0 ef3ad5a0 c076dce8
[    1.976060] 5d60: c0587888 00000005 00000010 c03bfcd8 c0587888
00000000 c076dbf8 c076dc34
[    1.984216] 5d80: 00000000 eeb56010 eeb49000 c076dbf8 00000000
c06ab0f8 c076dda8 00000000
[    1.992374] 5da0: 00000002 c03b8618 00000000 00000000 00000000
eeb56010 00000000 ef21e3c0
[    2.000531] 5dc0: c076dbf8 c076dda8 ef21e0c0 00000000 00000002
c03ba9e4 c076dc08 000000d0
[    2.008688] 5de0: ef000500 c076a5a8 c076dd08 00000000 ef21e184
c076dcf8 c076a5ec eeb49000
[    2.016844] 5e00: c076dce0 c076a5a8 ef3b1e8c eeb49034 c06a63ac
c076dc18 c02a2a24 c076dbf8
[    2.025001] 5e20: 000005d4 ef369a90 c17dd4f4 00000000 000000b3
ef074028 00000000 c03bb484
[    2.033157] 5e40: c17dba28 c076db24 ef18ae10 c03cd59c c07bffd8
ef18ae10 00000000 c076db38
[    2.041315] 5e60: c0712a54 c02a17e0 c02a17c8 c02a058c 00000000
ef18ae10 c076db38 ef18ae44
[    2.049471] 5e80: 00000000 c02a0778 00000000 c076db38 c02a06ec
c029eac8 ef06d0e0 ef181d74
[    2.057627] 5ea0: c076db38 ef3af840 c07526d8 c029fd44 c06ab0d4
c076db38 00000006 c076db38
[    2.065783] 5ec0: 00000006 c0777a40 c0777a40 c02a0d54 c07277c0
00000006 c0777a40 c0777a40
[    2.073941] 5ee0: c0712a54 c00089f8 ef025900 c0659cf4 ef1160c0
c053b498 00000000 00000001
[    2.082098] 5f00: 0000027c c073bd78 c17dd77b c0550080 000000b3
c003d884 00000000 c071d9dc
[    2.090254] 5f20: c06937c8 c06ed458 00000006 00000006 c003d198
c003d1f0 00000000 c07277c0
[    2.098411] 5f40: 00000006 c0777a40 c0777a40 c06f027c 000000b3
c071d9dc c071d9d0 c06f0970
[    2.106569] 5f60: 00000006 00000006 c06f027c ffffbfc7 ff7ffffd
fffff7ff 9fffffff 00000000
[    2.114726] 5f80: c0526f58 00000000 00000000 00000000 00000000
00000000 00000000 c0526f60
[    2.122884] 5fa0: 00000000 00000000 c0526f58 c000e578 00000000
00000000 00000000 00000000
[    2.131040] 5fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[    2.139198] 5fe0: 00000000 00000000 00000000 00000000 00000013
00000000 bf7fcdff eefffeff
[    2.147359] Code: 1affffe1 eafffff5 e92d4070 e1a05001 (e5914000)
[    2.153588] ---[ end trace a5214c5b7e3cefc9 ]---
[    2.158220] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b


From kishon at ti.com  Wed Jul 31 01:44:32 2013
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 31 Jul 2013 11:14:32 +0530
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <20130730071106.GC16441@radagast>
References: <20130720220006.GA7977@kroah.com> <3839600.WiC1OLF35o@flatron>
 <51EBC0F5.70601@ti.com> <9748041.Qq1fWJBg6D@flatron>
 <20130721154653.GG16598@kroah.com> <20130730071106.GC16441@radagast>
Message-ID: <51F8A440.8010803@ti.com>

Hi,

On Tuesday 30 July 2013 12:41 PM, Felipe Balbi wrote:
> On Sun, Jul 21, 2013 at 08:46:53AM -0700, Greg KH wrote:
>> On Sun, Jul 21, 2013 at 01:12:07PM +0200, Tomasz Figa wrote:
>>> On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
>>>> Hi,
>>>>
>>>> On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
>>>>> Hi,
>>>>>
>>>>> On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
>>>>>> On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
>>>>>>> On Sat, 20 Jul 2013, Greg KH wrote:
>>>>>>>>>>> That should be passed using platform data.
>>>>>>>>>>
>>>>>>>>>> Ick, don't pass strings around, pass pointers.  If you have
>>>>>>>>>> platform
>>>>>>>>>> data you can get to, then put the pointer there, don't use a
>>>>>>>>>> "name".
>>>>>>>>>
>>>>>>>>> I don't think I understood you here :-s We wont have phy pointer
>>>>>>>>> when we create the device for the controller no?(it'll be done in
>>>>>>>>> board file). Probably I'm missing something.
>>>>>>>>
>>>>>>>> Why will you not have that pointer?  You can't rely on the "name"
>>>>>>>> as
>>>>>>>> the device id will not match up, so you should be able to rely on
>>>>>>>> the pointer being in the structure that the board sets up, right?
>>>>>>>>
>>>>>>>> Don't use names, especially as ids can, and will, change, that is
>>>>>>>> going
>>>>>>>> to cause big problems.  Use pointers, this is C, we are supposed to
>>>>>>>> be
>>>>>>>> doing that :)
>>>>>>>
>>>>>>> Kishon, I think what Greg means is this:  The name you are using
>>>>>>> must
>>>>>>> be stored somewhere in a data structure constructed by the board
>>>>>>> file,
>>>>>>> right?  Or at least, associated with some data structure somehow.
>>>>>>> Otherwise the platform code wouldn't know which PHY hardware
>>>>>>> corresponded to a particular name.
>>>>>>>
>>>>>>> Greg's suggestion is that you store the address of that data
>>>>>>> structure
>>>>>>> in the platform data instead of storing the name string.  Have the
>>>>>>> consumer pass the data structure's address when it calls phy_create,
>>>>>>> instead of passing the name.  Then you don't have to worry about two
>>>>>>> PHYs accidentally ending up with the same name or any other similar
>>>>>>> problems.
>>>>>>
>>>>>> Close, but the issue is that whatever returns from phy_create()
>>>>>> should
>>>>>> then be used, no need to call any "find" functions, as you can just
>>>>>> use
>>>>>> the pointer that phy_create() returns.  Much like all other class api
>>>>>> functions in the kernel work.
>>>>>
>>>>> I think there is a confusion here about who registers the PHYs.
>>>>>
>>>>> All platform code does is registering a platform/i2c/whatever device,
>>>>> which causes a driver (located in drivers/phy/) to be instantiated.
>>>>> Such drivers call phy_create(), usually in their probe() callbacks,
>>>>> so platform_code has no way (and should have no way, for the sake of
>>>>> layering) to get what phy_create() returns.
>>
>> Why not put pointers in the platform data structure that can hold these
>> pointers?  I thought that is why we created those structures in the
>> first place.  If not, what are they there for?
> 
> heh, IMO we shouldn't pass pointers of any kind through platform_data,
> we want to pass data :-)
> 
> Allowing to pass pointers through that, is one of the reasons which got
> us in such a big mess in ARM land, well it was much easier for a
> board-file/driver writer to pass a function pointer then to create a
> generic framework :-)
> 
>>>>> IMHO we need a lookup method for PHYs, just like for clocks,
>>>>> regulators, PWMs or even i2c busses because there are complex cases
>>>>> when passing just a name using platform data will not work. I would
>>>>> second what Stephen said [1] and define a structure doing things in a
>>>>> DT-like way.
>>>>>
>>>>> Example;
>>>>>
>>>>> [platform code]
>>>>>
>>>>> static const struct phy_lookup my_phy_lookup[] = {
>>>>>
>>>>> 	PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
>>>>
>>>> The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
>>>> creating the device, the ids in the device name would change and
>>>> PHY_LOOKUP wont be useful.
>>>
>>> I don't think this is a problem. All the existing lookup methods already 
>>> use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You 
>>> can simply add a requirement that the ID must be assigned manually, 
>>> without using PLATFORM_DEVID_AUTO to use PHY lookup.
>>
>> And I'm saying that this idea, of using a specific name and id, is
>> frought with fragility and will break in the future in various ways when
>> devices get added to systems, making these strings constantly have to be
>> kept up to date with different board configurations.
>>
>> People, NEVER, hardcode something like an id.  The fact that this
>> happens today with the clock code, doesn't make it right, it makes the
>> clock code wrong.  Others have already said that this is wrong there as
>> well, as systems change and dynamic ids get used more and more.
>>
>> Let's not repeat the same mistakes of the past just because we refuse to
>> learn from them...
>>
>> So again, the "find a phy by a string" functions should be removed, the
>> device id should be automatically created by the phy core just to make
>> things unique in sysfs, and no driver code should _ever_ be reliant on
>> the number that is being created, and the pointer to the phy structure
>> should be used everywhere instead.
>>
>> With those types of changes, I will consider merging this subsystem, but
>> without them, sorry, I will not.
> 
> I'll agree with Greg here, the very fact that we see people trying to
> add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points to a
> big problem in the framework.
> 
> The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
> adding similar infrastructure to the driver themselves to make sure we
> don't end up with duplicate names in sysfs in case we have multiple
> instances of the same IP in the SoC (or several of the same PCIe card).
> I really don't want to go back to that.

If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can give the
correct binding information to the PHY framework. I think we can drop having
this non-dt support in PHY framework? I see only one platform (OMAP3) going to
be needing this non-dt support and we can use the USB PHY library for it.

Thanks
Kishon


From kgene at kernel.org  Wed Jul 31 01:44:48 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 31 Jul 2013 14:44:48 +0900
Subject: [PATCH] ARM: SAMSUNG: fix to support for missing cpu specific
 map_io
In-Reply-To: <CAK9yfHwMANp2TfQWHQVXGZ2C-t-KrwGHJOpFT+hedDFYTDng6Q@mail.gmail.com>
References: <190501ce8cdd$2abd6780$80383680$%kim@samsung.com>
 <CAK9yfHwMANp2TfQWHQVXGZ2C-t-KrwGHJOpFT+hedDFYTDng6Q@mail.gmail.com>
Message-ID: <1bb601ce8db1$11fa30a0$35ee91e0$@org>

Sachin Kamat wrote:
> 
> On 30 July 2013 09:57, Kukjin Kim <kgene.kim at samsung.com> wrote:
> >
> > Since commit 7ed76e08 (ARM: EXYNOS: Fix low level debug support)
> > map_io() is not needed for exynos5440 so need to fix to lookup
> > cpu which using map_io(). Without this, kernel boot log complains
> > 'CPU EXYNOS5440 support not enabled' on exynos5440 and panic().
> >
> > Signed-off-by: Kukjin Kim <kgene.kim at samsung.com>
> > ---
> >  arch/arm/plat-samsung/init.c |    5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/plat-samsung/init.c b/arch/arm/plat-samsung/init.c
> > index 3e5c461..50a3ea0 100644
> > --- a/arch/arm/plat-samsung/init.c
> > +++ b/arch/arm/plat-samsung/init.c
> > @@ -55,12 +55,13 @@ void __init s3c_init_cpu(unsigned long idcode,
> >
> >         printk("CPU %s (id 0x%08lx)\n", cpu->name, idcode);
> >
> > -       if (cpu->map_io == NULL || cpu->init == NULL) {
> > +       if (cpu->init == NULL) {
> >                 printk(KERN_ERR "CPU %s support not enabled\n",
cpu->name);
> >                 panic("Unsupported Samsung CPU");
> 
> While at it you could probably remove the printk and have that message
> printed by panic instead?
> 
If required, it should be handled separately, and it is not critical.

- Kukjin



From nsekhar at ti.com  Wed Jul 31 01:47:43 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 31 Jul 2013 11:17:43 +0530
Subject: [PATCH v3 6/6] ARM: davinci: da850: configure system configuration
 chip(CFGCHIP3) for emac
In-Reply-To: <1371999607-6483-7-git-send-email-prabhakar.csengg@gmail.com>
References: <1371999607-6483-1-git-send-email-prabhakar.csengg@gmail.com>
 <1371999607-6483-7-git-send-email-prabhakar.csengg@gmail.com>
Message-ID: <51F8A4FF.8020803@ti.com>

On Sunday 23 June 2013 08:30 PM, Prabhakar Lad wrote:
> From: "Lad, Prabhakar" <prabhakar.csengg at gmail.com>
> 
> This patch makes a common function for to configure emac and calls
> it appropriately in DT and non DT boot mode. The system configuration
> chip CFGCHIP3, controls the emac module. This patch appropriately
> configures this register for emac and sets DA850_MII_MDIO_CLKEN_PIN
> GPIO pin appropriately.
> 
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg at gmail.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Cc: netdev at vger.kernel.org
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: Sekhar Nori <nsekhar at ti.com>
> Cc: Heiko Schocher <hs at denx.de>
> ---
>  Changes for v2: none
>  Changes for v3:
>   a> added a common function in da850.c to configure
>      the CFGCHIP3 chip.
>      
>  arch/arm/mach-davinci/board-da850-evm.c    |   36 ++--------------------
>  arch/arm/mach-davinci/da850.c              |   45 ++++++++++++++++++++++++++++
>  arch/arm/mach-davinci/da8xx-dt.c           |   16 ++++++++++
>  arch/arm/mach-davinci/include/mach/da8xx.h |    1 +
>  4 files changed, 64 insertions(+), 34 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 8a24b6c..03dd1df 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -50,7 +50,6 @@
>  #include <media/tvp514x.h>
>  #include <media/adv7343.h>
>  
> -#define DA850_EVM_PHY_ID		"davinci_mdio-0:00"
>  #define DA850_LCD_PWR_PIN		GPIO_TO_PIN(2, 8)
>  #define DA850_LCD_BL_PIN		GPIO_TO_PIN(2, 15)
>  
> @@ -60,8 +59,6 @@
>  #define DA850_WLAN_EN			GPIO_TO_PIN(6, 9)
>  #define DA850_WLAN_IRQ			GPIO_TO_PIN(6, 10)
>  
> -#define DA850_MII_MDIO_CLKEN_PIN	GPIO_TO_PIN(2, 6)
> -
>  static struct mtd_partition da850evm_spiflash_part[] = {
>  	[0] = {
>  		.name = "UBL",
> @@ -1033,26 +1030,18 @@ static const short da850_evm_rmii_pins[] = {
>  
>  static int __init da850_evm_config_emac(void)
>  {
> -	void __iomem *cfg_chip3_base;
> -	int ret;
> -	u32 val;
>  	struct davinci_soc_info *soc_info = &davinci_soc_info;
>  	u8 rmii_en = soc_info->emac_pdata->rmii_en;
> +	int ret;
>  
>  	if (!machine_is_davinci_da850_evm())
>  		return 0;
>  
> -	cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
> -
> -	val = __raw_readl(cfg_chip3_base);
> -
>  	if (rmii_en) {
> -		val |= BIT(8);
>  		ret = davinci_cfg_reg_list(da850_evm_rmii_pins);
>  		pr_info("EMAC: RMII PHY configured, MII PHY will not be"
>  							" functional\n");
>  	} else {
> -		val &= ~BIT(8);
>  		ret = davinci_cfg_reg_list(da850_evm_mii_pins);
>  		pr_info("EMAC: MII PHY configured, RMII PHY will not be"
>  							" functional\n");
> @@ -1062,28 +1051,7 @@ static int __init da850_evm_config_emac(void)
>  		pr_warn("%s: CPGMAC/RMII mux setup failed: %d\n",
>  			__func__, ret);
>  
> -	/* configure the CFGCHIP3 register for RMII or MII */
> -	__raw_writel(val, cfg_chip3_base);
> -
> -	ret = davinci_cfg_reg(DA850_GPIO2_6);
> -	if (ret)
> -		pr_warn("%s:GPIO(2,6) mux setup failed\n", __func__);
> -
> -	ret = gpio_request(DA850_MII_MDIO_CLKEN_PIN, "mdio_clk_en");
> -	if (ret) {
> -		pr_warn("Cannot open GPIO %d\n", DA850_MII_MDIO_CLKEN_PIN);
> -		return ret;
> -	}
> -
> -	/* Enable/Disable MII MDIO clock */
> -	gpio_direction_output(DA850_MII_MDIO_CLKEN_PIN, rmii_en);
> -
> -	soc_info->emac_pdata->phy_id = DA850_EVM_PHY_ID;
> -
> -	ret = da8xx_register_emac();
> -	if (ret)
> -		pr_warn("%s: EMAC registration failed: %d\n", __func__, ret);
> -
> +	da850_config_emac(0, rmii_en);
>  	return 0;
>  }
>  device_initcall(da850_evm_config_emac);
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index c43abee..d8021bb 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -1197,6 +1197,51 @@ no_ddrpll_mem:
>  	return ret;
>  }
>  
> +void __init da850_config_emac(u32 dt_mode, u32 rmii_enabled)
> +{
> +#define DA850_MII_MDIO_CLKEN_PIN	GPIO_TO_PIN(2, 6)
> +#define DA850_EVM_PHY_ID		"davinci_mdio-0:00"
> +
> +	void __iomem *cfg_chip3_base;
> +	int ret;
> +	u32 val;
> +
> +	cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
> +
> +	val = readl(cfg_chip3_base);
> +
> +	if (rmii_enabled)
> +		val |= BIT(8);
> +	else
> +		val &= ~BIT(8);
> +
> +	/* configure the CFGCHIP3 register for RMII or MII */
> +	writel(val, cfg_chip3_base);
> +
> +	ret = davinci_cfg_reg(DA850_GPIO2_6);
> +	if (ret)
> +		pr_warn("%s:GPIO(2,6) mux setup failed\n", __func__);
> +
> +	ret = gpio_request(DA850_MII_MDIO_CLKEN_PIN, "mdio_clk_en");
> +	if (ret) {
> +		pr_warn("Cannot open GPIO %d\n", DA850_MII_MDIO_CLKEN_PIN);
> +		return;
> +	}

You cannot do this in SoC specific code. All boards wont use a GPIO to
choose between MII/RMII. You need to do this in a EVM specific manner.
This just means you retain the GPIO part of code in board-da850-evm.c
and for the DT case use a board specific GPIO node. See a similar
example in arch/arm/boot/dts/ste-nomadik-s8815.dts and how the code uses
it in arch/arm/mach-nomadik/cpu-8815.c.

Thanks,
Sekhar


From kgene at kernel.org  Wed Jul 31 01:52:21 2013
From: kgene at kernel.org (Kukjin Kim)
Date: Wed, 31 Jul 2013 14:52:21 +0900
Subject: [PATCH 3/3] ARM: EXYNOS: Add G2D support to exynos5250
In-Reply-To: <1373013749-14530-3-git-send-email-sachin.kamat@linaro.org>
References: <1373013749-14530-1-git-send-email-sachin.kamat@linaro.org>
 <1373013749-14530-3-git-send-email-sachin.kamat@linaro.org>
Message-ID: <1bb701ce8db2$1f96e180$5ec4a480$@org>

Sachin Kamat wrote:
> 
> Adds G2D node to exynos5250 DT file.
> 
> Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
> ---
>  arch/arm/boot/dts/exynos5250.dtsi |    8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index ef57277..6f356ce 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -163,6 +163,14 @@
>  		clock-names = "watchdog";
>  	};
> 
> +	g2d at 10850000 {
> +		compatible = "samsung,exynos5250-g2d";
> +		reg = <0x10850000 0x1000>;
> +		interrupts = <0 91 0>;
> +		clocks = <&clock 345>;
> +		clock-names = "fimg2d";
> +	};
> +
>  	codec at 11000000 {
>  		compatible = "samsung,mfc-v6";
>  		reg = <0x11000000 0x10000>;
> --
> 1.7.9.5

Looks ok to me, applied.

Thanks,
Kukjin



From magnus.damm at gmail.com  Wed Jul 31 01:58:07 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 31 Jul 2013 14:58:07 +0900
Subject: [PATCH] ARM: Fix memblock_reserve() to include stext
Message-ID: <20130731055807.14054.70106.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

This fix for the ARM architecture will include stext
in the memblock_reserve() call to make sure that the
following symbols are not overwritten (from System.map):

c0008000 T _text
c0008000 T stext
...
c0008138 T secondary_startup
...
c0009000 T _stext

With this patch applied CPU Hotplug starts working
again. Without this patch code in secondary_startup
never gets reached as expected.

This issue started triggering on kernels later than
v3.10 - perhaps a side effect of the CPU Hotplug init
section rework - so this is a fix for v3.11-rc.

Tested on the sh73a0 KZM9G board with CPU Hotplug:

 # echo 0 > /sys/devices/system/cpu/cpu1/online
 CPU1: shutdown
 # echo 1 > /sys/devices/system/cpu/cpu1/online
 CPU1: Booted secondary processor

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mm/init.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 0001/arch/arm/mm/init.c
+++ work/arch/arm/mm/init.c	2013-07-31 14:17:49.000000000 +0900
@@ -346,7 +346,7 @@ void __init arm_memblock_init(struct mem
 #ifdef CONFIG_XIP_KERNEL
 	memblock_reserve(__pa(_sdata), _end - _sdata);
 #else
-	memblock_reserve(__pa(_stext), _end - _stext);
+	memblock_reserve(__pa(_text), _end - _text);
 #endif
 #ifdef CONFIG_BLK_DEV_INITRD
 	if (phys_initrd_size &&


From magnus.damm at gmail.com  Wed Jul 31 02:00:08 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 31 Jul 2013 15:00:08 +0900
Subject: ARM CPU Hotplug breakage on mach-shmobile and KZM9D
In-Reply-To: <20130731010404.GJ17209@verge.net.au>
References: <CANqRtoRx7voEVwJG8UNNy_Jiixo=uRJCvxTD0bZdzVohoryBUA@mail.gmail.com>
 <20130725010607.GB31464@verge.net.au>
 <20130730074939.GE7210@verge.net.au>
 <51F7CD67.6020209@windriver.com>
 <20130731010404.GJ17209@verge.net.au>
Message-ID: <CANqRtoRcNGo+xXPzmgEtXgqqWF+07bbf8Ch6yRWeOFURRVMtwQ@mail.gmail.com>

Hi Simon, Paul,

On Wed, Jul 31, 2013 at 10:04 AM, Simon Horman <horms at verge.net.au> wrote:
> On Tue, Jul 30, 2013 at 10:27:51AM -0400, Paul Gortmaker wrote:
>> On 13-07-30 03:49 AM, Simon Horman wrote:
>> > [ Cc Paul Gortmaker ]
>> >
>> > On Thu, Jul 25, 2013 at 10:06:07AM +0900, Simon Horman wrote:
>> >> On Thu, Jul 25, 2013 at 12:15:49AM +0900, Magnus Damm wrote:
>> >>> Hi everyone,
>> >>>
>> >>> Bad news: CPU Hotplug on KZM9D seems broken on recent kernels.
>> >>>
>> >>> On renesas-next-20130710 or earlier I can perform the following:
>> >>>
>> >>> # echo 0 > /sys/devices/system/cpu/cpu1/online
>> >>> CPU1: shutdown
>> >>> # echo 1 > /sys/devices/system/cpu/cpu1/online
>> >>> CPU1: Booted secondary processor
>> >>> #
>> >>>
>> >>> While on more recent kernels the hotplug boot fails. This may be
>> >>> related to the move to v3.11-rc. The tag renesas-next-20130710
>> >>> surprisingly seems to be the final kernel based on v3.10-rc before
>> >>> jumping to v3.11-rc.
>> >>>
>> >>> I wonder, do other ARM platforms have working CPU Hotplug in v3.11-rc?
>> >>
>> >> I have a snowball that I could test if you think it would be useful.
>> >
>> > Unfortunately getting snowball to work turned out to be rather painful.
>> > So instead I bisected the problem on the KZM9G (N.b: the D in the subject
>> > seems to be incorrect :^)
>> >
>> > The result is that the following patch, added in v3.11-rc1,
>> > appears to be the culprit.
>>
>> Double check that you have this commit present:
>>  ---------------
>> commit 8c69d7af12265e5be9326110b695e010b47505bd
>> Author: Stephen Warren <swarren at nvidia.com>
>> Date:   Fri Jul 5 22:59:42 2013 +0100
>>
>>     ARM: 7780/1: add missing linker section markup to head-common.S
>>  ---------------
>>
>> as I think you are reporting the same problem that it fixed.
>
> Unfortunately that does not seem to resolve the problem that I am seeing.
> I have tried both v3.11-rc3 and 22f0a27367742f65130c0fb25ef00f7297e032c1
> with 8c69d7af12265e5be9326110b695e010b47505bd cherry picked on top and
> in both cases I see:
>
> # echo 0 > /sys/devices/system/cpu/cpu1/online
> CPU1: shutdown
> # echo 1 > /sys/devices/system/cpu/cpu1/online
> CPU1: failed to come online

Thanks for your help. I've now tracked down this issue to the following fix:

[PATCH] ARM: Fix memblock_reserve() to include stext

Let me know if you think the code should be changed somehow.

Cheers,

/ magnus


From rnayak at ti.com  Wed Jul 31 02:02:34 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Wed, 31 Jul 2013 11:32:34 +0530
Subject: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx
 based SoCs'
In-Reply-To: <51F80939.7060403@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-2-git-send-email-rnayak@ti.com>
 <20130730131009.GA28162@radagast> <51F7CB2F.6070705@ti.com>
 <20130730142353.GL28162@radagast> <51F7CF6F.6050702@ti.com>
 <20130730153138.GA5978@radagast> <51F807EF.6020809@ti.com>
 <51F80939.7060403@ti.com>
Message-ID: <51F8A87A.9080002@ti.com>

On Wednesday 31 July 2013 12:13 AM, Nishanth Menon wrote:
> On 07/30/2013 01:37 PM, Sricharan R wrote:
>> Hi,
>> On Tuesday 30 July 2013 09:02 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Tue, Jul 30, 2013 at 08:06:31PM +0530, Sricharan R wrote:
>>>> On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote:
>>>>> Hi,
>>>>>
>>>>> On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote:
>>>>>> On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
>>>>>>>> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
>>>>>>>>   # define soc_is_omap543x()        is_omap543x()
>>>>>>>>   #endif
>>>>>>>>
>>>>>>>> +# if defined(CONFIG_SOC_DRA7XX)
>>>>>>>> +# undef soc_is_dra7xx
>>>>>>>> +# undef soc_is_dra75x
>>>>>>>> +# define soc_is_dra7xx()        is_dra7xx()
>>>>>>>> +# define soc_is_dra75x()        is_dra75x()
>>>>>>> since this platform is DT-only, couldn't we just believe DT-data to be
>>>>>>> correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
>>>>>>>
>>>>>>> I patched this for OMAP5 (compile-tested only, no boards available) and
>>>>>>> came out with the patch below (still needs to be split):
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
>>>>>>> index 08b7267..b3136e5 100644
>>>>>>> --- a/arch/arm/boot/dts/omap5-uevm.dts
>>>>>>> +++ b/arch/arm/boot/dts/omap5-uevm.dts
>>>>>>> @@ -13,7 +13,7 @@
>>>>>>>
>>>>>>>   / {
>>>>>>>       model = "TI OMAP5 uEVM board";
>>>>>>> -    compatible = "ti,omap5-uevm", "ti,omap5";
>>>>>>> +    compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5";
>>>>>>>
>>>>>>   ok, nice and simpler way.
>>>>>>   But would this make different revisions, to appear the same ?
>>>>> well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up,
>>>>> it should be treated as such, then you can pass a different string to
>>>>> that new board's compatible attribute.
>>>>> s
>>>>   Yes for OMAP5. I was thinking in general about this approach.
>>>>   For example, for OMAP4 we have same board and
>>>>   different revisions can be socketed there.
>>>>
>>>>   For OMAP5, this is good.
>>> do we really production socketed boards? Well, at least Blaze has such
>>> thing. But do we have too many differences that need to be trated at
>>> arch/arm or should/could those be handled by reading IP's revision
>>> register (e.g. usb host erratas)
>>>
>>   OMAP4 SDP is socketed as well.
> a) OMAP4SDP is not production device
> b) OMAP4SDP uses SOM (System On Module)
> c) Socketted SOMs were used only during initial days of SoC
> d) almost all latest OMAP4 SDP switched to using soldered in SOM
> e) we claim compatibility of OMAP4 SDP with Blaze.
> 
> So, I dont think this is a rational argument for keeping soc checks with dts.

What about OMAP4 pandas? I for instance, have an old 4430 panda and I have no idea
if its a es2.1 or a es2.3 or something else. If we start relying on dt to pass the
right revision check then (we need to create different dts files for these to begin with) I
need to know exactly what silicon rev I am running on.

I know its good to completely get rid of all silicon rev checks and depend on IP revisions
but we have had various IPs which do not have proper rev checks. We have I guess most often
used these to identify PRCM differences.

Tony, what do you suggest we do for this series? Since we have just an es1.0 and one board
at this point for dra7xx, things would be fine even if we do a dt based parsing to identify
the device, and I am fine with it if thats what we feel is the right way forward.
For the rest of the DT only platforms (omap4/5/am335x) anyway getting rid of these rev checks
from the kernel and depending on DT parsing needs to be a separate series anyway and I dont
plan to address those as part of this series.

> 
>>   Ya, revision checks used only in few places and as you said
>>   we handle them using IP revisions, but that we have to look and clean
>>   up those places, if we really intend to do this for other socs.
> 
> I agree this is the right approach :).
> 
> 



From lars at metafoo.de  Wed Jul 31 02:05:39 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Wed, 31 Jul 2013 08:05:39 +0200
Subject: New dapm panic on beaver with next-20130730
In-Reply-To: <CAOesGMig6jry1GJLoTnOqxom1KjtBTUtZz-_-SiZLpGTc3VkqA@mail.gmail.com>
References: <CAOesGMig6jry1GJLoTnOqxom1KjtBTUtZz-_-SiZLpGTc3VkqA@mail.gmail.com>
Message-ID: <51F8A933.4080708@metafoo.de>

On 07/31/2013 07:36 AM, Olof Johansson wrote:
> Hi Mark, Lars-Peter,
>
> I noticed the below panic on beaver (Tegra30). Seems like seaboard
> (Tegra20) is fine. This is with next-20130730, tegra_defconfig.

Hi,

So the same machine driver with the same codec works on tegra2, but not on 
tegra3? The crash doesn't seem to be directly related to the patch, but the 
patch changed the memory layout. Is it possible that you still have a outdated 
module that's being loaded on your tegra3 board?

Can you add a few debugging printks and run the test again and paste the last 
few lines before the crash:

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index b779d36..22c41fd 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -774,8 +774,12 @@
  	struct snd_soc_dapm_path *p;

  	list_for_each_entry(p, sink, list_source) {
+		printk("dapm_clear_walk_output 1: %p\n", p);
  		if (p->walked) {
  			p->walked = 0;
+			printk("dapm_clear_walk_output 2: %p\n", p->sink);
+			printk("dapm_clear_walk_output 3: %s\n",
+				p->sink->name);
  			dapm_clear_walk_output(dapm, &p->sink->sinks);
  		}
  	}
@@ -1189,6 +1193,8 @@

  	DAPM_UPDATE_STAT(w, power_checks);

+	printk("dapm_generic_check_power: %s\n", w->name);
+
  	in = is_connected_input_ep(w, NULL);
  	dapm_clear_walk_input(w->dapm, &w->sources);
  	out = is_connected_output_ep(w, NULL);

- Lars

>
> I noticed a bunch of recent dapm changes in the asoc tree on the 29th,
> and I was able to bisect it down to:
>
> commit 5106b92f80a2cd37c52cffed80b4f5acfb77ccfd
> Author: Lars-Peter Clausen <lars at metafoo.de>
> Date:   Mon Jul 29 17:14:00 2013 +0200
>
>      ASoC: dapm: Keep a list of paths per kcontrol
>
>      Currently we store for each path which control (if any at all) is associated
>      with that control. But we are only ever interested in the reverse
> relationship,
>      i.e. we want to know all the paths a certain control is associated
> with. This is
>      currently implemented by always iterating over all paths. This
> patch updates the
>      code to keep a list for each control which contains all the paths that are
>      associated with that control. This improves the run time of e.g.
>      soc_dapm_mixer_update_power() and soc_dapm_mux_update_power() from
> O(n) (with n
>      being the number of paths for the card) to O(1).
>
>      Signed-off-by: Lars-Peter Clausen <lars at metafoo.de>
>      Signed-off-by: Mark Brown <broonie at linaro.org>
>
>
> Panic output is below. I need to figure out why I'm not actually
> getting a backtrace in panics any more as well so this is of somewhat
> limited use, unfortuantely.
>
> Running a brute force function lookup on all words on the stack gives
> a rough idea of call path though:
>
> c03b1bb4   dapm_clear_walk_output
> c03b3450   dapm_generic_check_power
> c03b56b0   dapm_power_widgets
> c03b608c   snd_soc_dapm_new_widgets
> [c069f8f8   kallsyms_token_index]
> c03ae9fc   soc_post_component_init
> c03b0dd0   soc_probe_link_dais
> c069abb0   kallsyms_token_index
> [c029ac24   devm_kzalloc_release]
> c03b1870   snd_soc_register_card
> c03c3964   tegra_rt5640_probe
> c0707b74   tegra_rt5640_driver_init
> c02999e0   platform_drv_probe
> c02999c8   platform_drv_probe
> c029878c   driver_probe_device
>
>
> [    1.845620] Unable to handle kernel paging request at virtual
> address 6b6b6bd3
> [    1.852855] pgd = c0004000
> [    1.855552] [6b6b6bd3] *pgd=00000000
> [    1.859125] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> [    1.864422] Modules linked in:
> [    1.867473] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 3.11.0-rc3-next-20130730 #42
> [    1.875023] task: ef064a40 ti: ef074000 task.ti: ef074000
> [    1.880421] PC is at dapm_clear_walk_output+0x8/0x68
> [    1.885371] LR is at dapm_clear_walk_output+0x54/0x68
> [    1.890408] pc : [<c03bb77c>]    lr : [<c03bb7c8>]    psr: 20000113
> [    1.890408] sp : ef075ce8  ip : 00000000  fp : 00000010
> [    1.901858] r10: ef075d2c  r9 : c076dd00  r8 : c076dbf8
> [    1.907066] r7 : ef075d34  r6 : eeb490b8  r5 : 6b6b6bd3  r4 : ef39c4b0
> [    1.913574] r3 : 00000069  r2 : 00000192  r1 : 6b6b6bd3  r0 : eeb490b8
> [    1.920084] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
> Segment kernel
> [    1.927372] Control: 10c5387d  Table: 8000404a  DAC: 00000015
> [    1.933101] Process swapper/0 (pid: 1, stack limit = 0xef074238)
> [    1.939090] Stack: (0xef075ce8 to 0xef076000)
> [    1.943434] 5ce0:                   ef39c4b0 ef3ad728 eeb490b8
> c03bb7c8 ef3ad6c0 00000000
> [    1.951591] 5d00: 00000000 c03bd074 c076dcf8 ef3ad6c0 ef075d3c
> c03bf310 00000000 c076dcf8
> [    1.959747] 5d20: 00000000 eec537f0 c077ca0c ef075d2c ef075d2c
> ef075d34 ef075d34 ef075d3c
> [    1.967904] 5d40: ef075d3c c01c298c eec66734 ef3ad584 c076dcd4
> 000000f0 ef3ad5a0 c076dce8
> [    1.976060] 5d60: c0587888 00000005 00000010 c03bfcd8 c0587888
> 00000000 c076dbf8 c076dc34
> [    1.984216] 5d80: 00000000 eeb56010 eeb49000 c076dbf8 00000000
> c06ab0f8 c076dda8 00000000
> [    1.992374] 5da0: 00000002 c03b8618 00000000 00000000 00000000
> eeb56010 00000000 ef21e3c0
> [    2.000531] 5dc0: c076dbf8 c076dda8 ef21e0c0 00000000 00000002
> c03ba9e4 c076dc08 000000d0
> [    2.008688] 5de0: ef000500 c076a5a8 c076dd08 00000000 ef21e184
> c076dcf8 c076a5ec eeb49000
> [    2.016844] 5e00: c076dce0 c076a5a8 ef3b1e8c eeb49034 c06a63ac
> c076dc18 c02a2a24 c076dbf8
> [    2.025001] 5e20: 000005d4 ef369a90 c17dd4f4 00000000 000000b3
> ef074028 00000000 c03bb484
> [    2.033157] 5e40: c17dba28 c076db24 ef18ae10 c03cd59c c07bffd8
> ef18ae10 00000000 c076db38
> [    2.041315] 5e60: c0712a54 c02a17e0 c02a17c8 c02a058c 00000000
> ef18ae10 c076db38 ef18ae44
> [    2.049471] 5e80: 00000000 c02a0778 00000000 c076db38 c02a06ec
> c029eac8 ef06d0e0 ef181d74
> [    2.057627] 5ea0: c076db38 ef3af840 c07526d8 c029fd44 c06ab0d4
> c076db38 00000006 c076db38
> [    2.065783] 5ec0: 00000006 c0777a40 c0777a40 c02a0d54 c07277c0
> 00000006 c0777a40 c0777a40
> [    2.073941] 5ee0: c0712a54 c00089f8 ef025900 c0659cf4 ef1160c0
> c053b498 00000000 00000001
> [    2.082098] 5f00: 0000027c c073bd78 c17dd77b c0550080 000000b3
> c003d884 00000000 c071d9dc
> [    2.090254] 5f20: c06937c8 c06ed458 00000006 00000006 c003d198
> c003d1f0 00000000 c07277c0
> [    2.098411] 5f40: 00000006 c0777a40 c0777a40 c06f027c 000000b3
> c071d9dc c071d9d0 c06f0970
> [    2.106569] 5f60: 00000006 00000006 c06f027c ffffbfc7 ff7ffffd
> fffff7ff 9fffffff 00000000
> [    2.114726] 5f80: c0526f58 00000000 00000000 00000000 00000000
> 00000000 00000000 c0526f60
> [    2.122884] 5fa0: 00000000 00000000 c0526f58 c000e578 00000000
> 00000000 00000000 00000000
> [    2.131040] 5fc0: 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
> [    2.139198] 5fe0: 00000000 00000000 00000000 00000000 00000013
> 00000000 bf7fcdff eefffeff
> [    2.147359] Code: 1affffe1 eafffff5 e92d4070 e1a05001 (e5914000)
> [    2.153588] ---[ end trace a5214c5b7e3cefc9 ]---
> [    2.158220] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b
>



From manjunath.goudar at linaro.org  Wed Jul 31 02:07:58 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Wed, 31 Jul 2013 11:37:58 +0530
Subject: [PATCH V4 0/6]  USB: OHCI: more bus glues as separate modules
In-Reply-To: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1375250884-28447-1-git-send-email-manjunath.goudar@linaro.org>

These patches are for separating the SOC On-Chip ohci host controller
from ohci-hcd host code into its own driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.12.

V2:
  In patch 5/6 and 6/6:
  -Set non-standard fields in hc_driver manually, rather than
   relying on an expanded struct ohci_driver_overrides.
  -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
   relying on ohci_hub_control and hub_status_data being exported.

  In patch 1/6 to 4/6
  -ohci_setup() has been removed because it is called in .reset member
   of the ohci_hc_driver structure.

V3:
 In patch 5/6 and 6/6:
 -ohci_setup() has been removed because it is called in .reset member
  of the ohci_hc_driver structure.

 In patch 5/6:
 -The ohci_restart() function is not required in  current scenario,
  only discarding connection state of integrated transceivers is sufficient,
  for this directly handling ohci->hc_control.

 In patch 2/6 :
 -rewritten if (config->otg || config->rwc) block statements into
  two separate 'if blocks' to handle below scenarios
  1. config->otg set scenario.
  2. if any of these (config->otg, config->rwc) are set, this
     scenario should be handled only after ohci_setup()
 
 In patch 1/6 and 4/6:
  No change.

V4:
 In patch 1/6 and 4/6:
  No change.

 In patch 2/6 :
 -usb_remove_hcd() function is required a valid clock that is what
  omap_ohci_clock_power(0) is called after hcd shutdown.

 In patch 3/6 :
 -V3 modification revert back, only ohci->regs setting write()
  function has been removed because ohci->regs doesn't get set until
  usb_add_hcd.

 In patch 5/6 :
 - Removed extra space after "tristate".
 - Removed extra space between function name  and '(' characters.
 - MODULE_ALIAS line moved to last statement of ohci-at91 file.

 In patch 6/6 :
 - Removed extra space before the '='.
 - Moved  /* forward definitions */ line before the declarations of functions.

Manjunath Goudar (6):
  USB: OHCI: make ohci-exynos a separate driver
  USB: OHCI: make ohci-omap a separate driver
  USB: OHCI: make ohci-omap3 a separate driver
  USB: OHCI: make ohci-spear a separate driver
  USB: OHCI: make ohci-at91 a separate driver
  USB: OHCI: make ohci-s3c2410 a separate driver

 drivers/usb/host/Kconfig        |   30 ++++++-
 drivers/usb/host/Makefile       |    6 ++
 drivers/usb/host/ohci-at91.c    |  153 ++++++++++++++++-------------------
 drivers/usb/host/ohci-exynos.c  |  167 ++++++++++++++++-----------------------
 drivers/usb/host/ohci-hcd.c     |  108 -------------------------
 drivers/usb/host/ohci-omap.c    |  156 +++++++++++++-----------------------
 drivers/usb/host/ohci-omap3.c   |  118 +++++++++------------------
 drivers/usb/host/ohci-s3c2410.c |  128 +++++++++++++-----------------
 drivers/usb/host/ohci-spear.c   |  140 +++++++++++++-------------------
 9 files changed, 374 insertions(+), 632 deletions(-)

-- 
1.7.9.5



From manjunath.goudar at linaro.org  Wed Jul 31 02:08:00 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Wed, 31 Jul 2013 11:38:00 +0530
Subject: [PATCH V4 2/6] USB: OHCI: make ohci-omap a separate driver
In-Reply-To: <1375250884-28447-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
 <1375250884-28447-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1375250884-28447-3-git-send-email-manjunath.goudar@linaro.org>

Separate the  TI OHCI OMAP1/2 host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -omap_ohci_clock_power(0) called in usb_hcd_omap_remove().
 -Removed ohci_setup() call from usb_hcd_omap_probe().
 -host_enabled and host_initialized variables aren't used for anything
  thats what removed.

V3:
 -rewritten if (config->otg || config->rwc) block statements into
  two separate 'if blocks' to handle below scenarios
  1. config->otg set scenario.
  2. if any of these (config->otg, config->rwc) are set, this
     scenario should be handled only after ohci_setup()

V4:
 -usb_remove_hcd() function is required a valid clock that is what
  omap_ohci_clock_power(0) is called after hcd shutdown.
---
 drivers/usb/host/Kconfig     |    2 +-
 drivers/usb/host/Makefile    |    1 +
 drivers/usb/host/ohci-hcd.c  |   18 -----
 drivers/usb/host/ohci-omap.c |  156 ++++++++++++++----------------------------
 4 files changed, 55 insertions(+), 122 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 7b8f6bd..99b7e7e 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -376,7 +376,7 @@ config USB_OHCI_HCD
 if USB_OHCI_HCD
 
 config USB_OHCI_HCD_OMAP1
-	bool "OHCI support for OMAP1/2 chips"
+	tristate "OHCI support for OMAP1/2 chips"
 	depends on ARCH_OMAP1
 	default y
 	---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 26cf69a..c7076ec 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_USB_OHCI_HCD)	+= ohci-hcd.o
 obj-$(CONFIG_USB_OHCI_HCD_PCI)	+= ohci-pci.o
 obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)	+= ohci-platform.o
 obj-$(CONFIG_USB_OHCI_EXYNOS)	+= ohci-exynos.o
+obj-$(CONFIG_USB_OHCI_HCD_OMAP1)	+= ohci-omap.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 2980bb6..1abc1e7 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1182,11 +1182,6 @@ MODULE_LICENSE ("GPL");
 #define S3C2410_PLATFORM_DRIVER	ohci_hcd_s3c2410_driver
 #endif
 
-#ifdef CONFIG_USB_OHCI_HCD_OMAP1
-#include "ohci-omap.c"
-#define OMAP1_PLATFORM_DRIVER	ohci_hcd_omap_driver
-#endif
-
 #ifdef CONFIG_USB_OHCI_HCD_OMAP3
 #include "ohci-omap3.c"
 #define OMAP3_PLATFORM_DRIVER	ohci_hcd_omap3_driver
@@ -1289,12 +1284,6 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_platform;
 #endif
 
-#ifdef OMAP1_PLATFORM_DRIVER
-	retval = platform_driver_register(&OMAP1_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_omap1_platform;
-#endif
-
 #ifdef OMAP3_PLATFORM_DRIVER
 	retval = platform_driver_register(&OMAP3_PLATFORM_DRIVER);
 	if (retval < 0)
@@ -1408,10 +1397,6 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
  error_omap3_platform:
 #endif
-#ifdef OMAP1_PLATFORM_DRIVER
-	platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
- error_omap1_platform:
-#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
  error_platform:
@@ -1466,9 +1451,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef OMAP3_PLATFORM_DRIVER
 	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
 #endif
-#ifdef OMAP1_PLATFORM_DRIVER
-	platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
-#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 8747fa6..8149ef0 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -14,12 +14,21 @@
  * This file is licenced under the GPL.
  */
 
-#include <linux/signal.h>
-#include <linux/jiffies.h>
-#include <linux/platform_device.h>
 #include <linux/clk.h>
+#include <linux/dma-mapping.h>
 #include <linux/err.h>
 #include <linux/gpio.h>
+#include <linux/io.h>
+#include <linux/jiffies.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/usb/otg.h>
+#include <linux/platform_device.h>
+#include <linux/signal.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ohci.h"
 
 #include <asm/io.h>
 #include <asm/mach-types.h>
@@ -42,10 +51,7 @@
 #define OMAP1510_LB_MMU_RAM_H	0xfffec234
 #define OMAP1510_LB_MMU_RAM_L	0xfffec238
 
-
-#ifndef CONFIG_ARCH_OMAP
-#error "This file is OMAP bus glue.  CONFIG_OMAP must be defined."
-#endif
+#define DRIVER_DESC "OHCI OMAP driver"
 
 #ifdef CONFIG_TPS65010
 #include <linux/i2c/tps65010.h>
@@ -68,8 +74,9 @@ extern int ocpi_enable(void);
 
 static struct clk *usb_host_ck;
 static struct clk *usb_dc_ck;
-static int host_enabled;
-static int host_initialized;
+
+static const char hcd_name[] = "ohci-omap";
+static struct hc_driver __read_mostly ohci_omap_hc_driver;
 
 static void omap_ohci_clock_power(int on)
 {
@@ -188,7 +195,7 @@ static void start_hnp(struct ohci_hcd *ohci)
 
 /*-------------------------------------------------------------------------*/
 
-static int ohci_omap_init(struct usb_hcd *hcd)
+static int ohci_omap_reset(struct usb_hcd *hcd)
 {
 	struct ohci_hcd		*ohci = hcd_to_ohci(hcd);
 	struct omap_usb_config	*config = hcd->self.controller->platform_data;
@@ -198,9 +205,9 @@ static int ohci_omap_init(struct usb_hcd *hcd)
 	dev_dbg(hcd->self.controller, "starting USB Controller\n");
 
 	if (config->otg) {
-		ohci_to_hcd(ohci)->self.otg_port = config->otg;
+		hcd->self.otg_port = config->otg;
 		/* default/minimum OTG power budget:  8 mA */
-		ohci_to_hcd(ohci)->power_budget = 8;
+		hcd->power_budget = 8;
 	}
 
 	/* boards can use OTG transceivers in non-OTG modes */
@@ -238,9 +245,15 @@ static int ohci_omap_init(struct usb_hcd *hcd)
 		omap_1510_local_bus_init();
 	}
 
-	if ((ret = ohci_init(ohci)) < 0)
+	ret = ohci_setup(hcd);
+	if (ret < 0)
 		return ret;
 
+	if (config->otg || config->rwc) {
+		ohci->hc_control = OHCI_CTRL_RWC;
+		writel(OHCI_CTRL_RWC, &ohci->regs->control);
+	}
+
 	/* board-specific power switching and overcurrent support */
 	if (machine_is_omap_osk() || machine_is_omap_innovator()) {
 		u32	rh = roothub_a (ohci);
@@ -281,14 +294,6 @@ static int ohci_omap_init(struct usb_hcd *hcd)
 	return 0;
 }
 
-static void ohci_omap_stop(struct usb_hcd *hcd)
-{
-	dev_dbg(hcd->self.controller, "stopping USB Controller\n");
-	ohci_stop(hcd);
-	omap_ohci_clock_power(0);
-}
-
-
 /*-------------------------------------------------------------------------*/
 
 /**
@@ -304,7 +309,6 @@ static int usb_hcd_omap_probe (const struct hc_driver *driver,
 {
 	int retval, irq;
 	struct usb_hcd *hcd = 0;
-	struct ohci_hcd *ohci;
 
 	if (pdev->num_resources != 2) {
 		printk(KERN_ERR "hcd probe: invalid num_resources: %i\n",
@@ -354,12 +358,6 @@ static int usb_hcd_omap_probe (const struct hc_driver *driver,
 		goto err2;
 	}
 
-	ohci = hcd_to_ohci(hcd);
-	ohci_hcd_init(ohci);
-
-	host_initialized = 0;
-	host_enabled = 1;
-
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
 		retval = -ENXIO;
@@ -369,11 +367,6 @@ static int usb_hcd_omap_probe (const struct hc_driver *driver,
 	if (retval)
 		goto err3;
 
-	host_initialized = 1;
-
-	if (!host_enabled)
-		omap_ohci_clock_power(0);
-
 	return 0;
 err3:
 	iounmap(hcd->regs);
@@ -402,7 +395,9 @@ err0:
 static inline void
 usb_hcd_omap_remove (struct usb_hcd *hcd, struct platform_device *pdev)
 {
+	dev_dbg(hcd->self.controller, "stopping USB Controller\n");
 	usb_remove_hcd(hcd);
+	omap_ohci_clock_power(0);
 	if (!IS_ERR_OR_NULL(hcd->phy)) {
 		(void) otg_set_host(hcd->phy->otg, 0);
 		usb_put_phy(hcd->phy);
@@ -418,76 +413,6 @@ usb_hcd_omap_remove (struct usb_hcd *hcd, struct platform_device *pdev)
 
 /*-------------------------------------------------------------------------*/
 
-static int
-ohci_omap_start (struct usb_hcd *hcd)
-{
-	struct omap_usb_config *config;
-	struct ohci_hcd	*ohci = hcd_to_ohci (hcd);
-	int		ret;
-
-	if (!host_enabled)
-		return 0;
-	config = hcd->self.controller->platform_data;
-	if (config->otg || config->rwc) {
-		ohci->hc_control = OHCI_CTRL_RWC;
-		writel(OHCI_CTRL_RWC, &ohci->regs->control);
-	}
-
-	if ((ret = ohci_run (ohci)) < 0) {
-		dev_err(hcd->self.controller, "can't start\n");
-		ohci_stop (hcd);
-		return ret;
-	}
-	return 0;
-}
-
-/*-------------------------------------------------------------------------*/
-
-static const struct hc_driver ohci_omap_hc_driver = {
-	.description =		hcd_name,
-	.product_desc =		"OMAP OHCI",
-	.hcd_priv_size =	sizeof(struct ohci_hcd),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq =			ohci_irq,
-	.flags =		HCD_USB11 | HCD_MEMORY,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.reset =		ohci_omap_init,
-	.start =		ohci_omap_start,
-	.stop =			ohci_omap_stop,
-	.shutdown =		ohci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue =		ohci_urb_enqueue,
-	.urb_dequeue =		ohci_urb_dequeue,
-	.endpoint_disable =	ohci_endpoint_disable,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number =	ohci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data =	ohci_hub_status_data,
-	.hub_control =		ohci_hub_control,
-#ifdef	CONFIG_PM
-	.bus_suspend =		ohci_bus_suspend,
-	.bus_resume =		ohci_bus_resume,
-#endif
-	.start_port_reset =	ohci_start_port_reset,
-};
-
-/*-------------------------------------------------------------------------*/
-
 static int ohci_hcd_omap_drv_probe(struct platform_device *dev)
 {
 	return usb_hcd_omap_probe(&ohci_omap_hc_driver, dev);
@@ -553,4 +478,29 @@ static struct platform_driver ohci_hcd_omap_driver = {
 	},
 };
 
+static const struct ohci_driver_overrides omap_overrides __initconst = {
+	.product_desc	= "OMAP OHCI",
+	.reset		= ohci_omap_reset
+};
+
+static int __init ohci_omap_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ohci_init_driver(&ohci_omap_hc_driver, &omap_overrides);
+	return platform_driver_register(&ohci_hcd_omap_driver);
+}
+module_init(ohci_omap_init);
+
+static void __exit ohci_omap_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_omap_driver);
+}
+module_exit(ohci_omap_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_ALIAS("platform:ohci");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Wed Jul 31 02:08:01 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Wed, 31 Jul 2013 11:38:01 +0530
Subject: [PATCH V4 3/6] USB: OHCI: make ohci-omap3 a separate driver
In-Reply-To: <1375250884-28447-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
 <1375250884-28447-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1375250884-28447-4-git-send-email-manjunath.goudar@linaro.org>

Separate the  TI OHCI OMAP3 host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Anand Gadiyar <gadiyar at ti.com>
Cc: Felipe Balbi <balbi at ti.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -ohci_setup() removed because it is called in .reset member
  of the ohci_hc_driver structure.
 -The improper multi-line commenting style written in proper way.
  ('*' characters aligned in vertically).

V3:
 -RemoteWakeupConnected setting has been removed.

V4:
 -V3 modification revert back, only ohci->regs setting write()
  function has been removed because ohci->regs doesn't get set until
  usb_add_hcd.
---
 drivers/usb/host/Kconfig      |    2 +-
 drivers/usb/host/Makefile     |    1 +
 drivers/usb/host/ohci-hcd.c   |   18 -------
 drivers/usb/host/ohci-omap3.c |  118 +++++++++++++----------------------------
 4 files changed, 40 insertions(+), 99 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 99b7e7e..3eab432 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -383,7 +383,7 @@ config USB_OHCI_HCD_OMAP1
 	  Enables support for the OHCI controller on OMAP1/2 chips.
 
 config USB_OHCI_HCD_OMAP3
-	bool "OHCI support for OMAP3 and later chips"
+	tristate "OHCI support for OMAP3 and later chips"
 	depends on (ARCH_OMAP3 || ARCH_OMAP4)
 	default y
 	---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index c7076ec..954466d 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_USB_OHCI_HCD_PCI)	+= ohci-pci.o
 obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)	+= ohci-platform.o
 obj-$(CONFIG_USB_OHCI_EXYNOS)	+= ohci-exynos.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP1)	+= ohci-omap.o
+obj-$(CONFIG_USB_OHCI_HCD_OMAP3)	+= ohci-omap3.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 1abc1e7..cad51d2 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1182,11 +1182,6 @@ MODULE_LICENSE ("GPL");
 #define S3C2410_PLATFORM_DRIVER	ohci_hcd_s3c2410_driver
 #endif
 
-#ifdef CONFIG_USB_OHCI_HCD_OMAP3
-#include "ohci-omap3.c"
-#define OMAP3_PLATFORM_DRIVER	ohci_hcd_omap3_driver
-#endif
-
 #if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx)
 #include "ohci-pxa27x.c"
 #define PLATFORM_DRIVER		ohci_hcd_pxa27x_driver
@@ -1284,12 +1279,6 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_platform;
 #endif
 
-#ifdef OMAP3_PLATFORM_DRIVER
-	retval = platform_driver_register(&OMAP3_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_omap3_platform;
-#endif
-
 #ifdef OF_PLATFORM_DRIVER
 	retval = platform_driver_register(&OF_PLATFORM_DRIVER);
 	if (retval < 0)
@@ -1393,10 +1382,6 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
  error_of_platform:
 #endif
-#ifdef OMAP3_PLATFORM_DRIVER
-	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
- error_omap3_platform:
-#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
  error_platform:
@@ -1448,9 +1433,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef OF_PLATFORM_DRIVER
 	platform_driver_unregister(&OF_PLATFORM_DRIVER);
 #endif
-#ifdef OMAP3_PLATFORM_DRIVER
-	platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
-#endif
 #ifdef PLATFORM_DRIVER
 	platform_driver_unregister(&PLATFORM_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
index 8f71357..e14f4d9 100644
--- a/drivers/usb/host/ohci-omap3.c
+++ b/drivers/usb/host/ohci-omap3.c
@@ -29,90 +29,22 @@
  *	- add kernel-doc
  */
 
+#include <linux/dma-mapping.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/usb/otg.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
-#include <linux/of.h>
-#include <linux/dma-mapping.h>
-
-/*-------------------------------------------------------------------------*/
-
-static int ohci_omap3_init(struct usb_hcd *hcd)
-{
-	dev_dbg(hcd->self.controller, "starting OHCI controller\n");
-
-	return ohci_init(hcd_to_ohci(hcd));
-}
-
-/*-------------------------------------------------------------------------*/
-
-static int ohci_omap3_start(struct usb_hcd *hcd)
-{
-	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
-	int ret;
-
-	/*
-	 * RemoteWakeupConnected has to be set explicitly before
-	 * calling ohci_run. The reset value of RWC is 0.
-	 */
-	ohci->hc_control = OHCI_CTRL_RWC;
-	writel(OHCI_CTRL_RWC, &ohci->regs->control);
-
-	ret = ohci_run(ohci);
-
-	if (ret < 0) {
-		dev_err(hcd->self.controller, "can't start\n");
-		ohci_stop(hcd);
-	}
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
 
-	return ret;
-}
+#include "ohci.h"
 
-/*-------------------------------------------------------------------------*/
+#define DRIVER_DESC "OHCI OMAP3 driver"
 
-static const struct hc_driver ohci_omap3_hc_driver = {
-	.description =		hcd_name,
-	.product_desc =		"OMAP3 OHCI Host Controller",
-	.hcd_priv_size =	sizeof(struct ohci_hcd),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq =			ohci_irq,
-	.flags =		HCD_USB11 | HCD_MEMORY,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.reset =		ohci_omap3_init,
-	.start =		ohci_omap3_start,
-	.stop =			ohci_stop,
-	.shutdown =		ohci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue =		ohci_urb_enqueue,
-	.urb_dequeue =		ohci_urb_dequeue,
-	.endpoint_disable =	ohci_endpoint_disable,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number =	ohci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data =	ohci_hub_status_data,
-	.hub_control =		ohci_hub_control,
-#ifdef	CONFIG_PM
-	.bus_suspend =		ohci_bus_suspend,
-	.bus_resume =		ohci_bus_resume,
-#endif
-	.start_port_reset =	ohci_start_port_reset,
-};
-
-/*-------------------------------------------------------------------------*/
+static const char hcd_name[] = "ohci-omap3";
+static struct hc_driver __read_mostly ohci_omap3_hc_driver;
 
 /*
  * configure so an HC device and id are always provided
@@ -129,6 +61,7 @@ static const struct hc_driver ohci_omap3_hc_driver = {
 static int ohci_hcd_omap3_probe(struct platform_device *pdev)
 {
 	struct device		*dev = &pdev->dev;
+	struct ohci_hcd		*ohci;
 	struct usb_hcd		*hcd = NULL;
 	void __iomem		*regs = NULL;
 	struct resource		*res;
@@ -185,7 +118,12 @@ static int ohci_hcd_omap3_probe(struct platform_device *pdev)
 	pm_runtime_enable(dev);
 	pm_runtime_get_sync(dev);
 
-	ohci_hcd_init(hcd_to_ohci(hcd));
+	ohci = hcd_to_ohci(hcd);
+	/*
+	 * RemoteWakeupConnected has to be set explicitly before
+	 * calling ohci_run. The reset value of RWC is 0.
+	 */
+	ohci->hc_control = OHCI_CTRL_RWC;
 
 	ret = usb_add_hcd(hcd, irq, 0);
 	if (ret) {
@@ -256,5 +194,25 @@ static struct platform_driver ohci_hcd_omap3_driver = {
 	},
 };
 
+static int __init ohci_omap3_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ohci_init_driver(&ohci_omap3_hc_driver, NULL);
+	return platform_driver_register(&ohci_hcd_omap3_driver);
+}
+module_init(ohci_omap3_init);
+
+static void __exit ohci_omap3_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_omap3_driver);
+}
+module_exit(ohci_omap3_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_ALIAS("platform:ohci-omap3");
 MODULE_AUTHOR("Anand Gadiyar <gadiyar at ti.com>");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Wed Jul 31 02:08:02 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Wed, 31 Jul 2013 11:38:02 +0530
Subject: [PATCH V4 4/6] USB: OHCI: make ohci-spear a separate driver
In-Reply-To: <1375250884-28447-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
 <1375250884-28447-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1375250884-28447-5-git-send-email-manjunath.goudar@linaro.org>

Separate the ST OHCI SPEAr host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Viresh Kumar <viresh.linux at gmail.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -ohci_setup() removed because it is called in .reset member
  of the ohci_hc_driver structure.
 -debugging stuff isn't needed any more that's what removed.

V3:
 No change.
---
 drivers/usb/host/Kconfig      |    8 +++
 drivers/usb/host/Makefile     |    1 +
 drivers/usb/host/ohci-hcd.c   |   18 ------
 drivers/usb/host/ohci-spear.c |  140 +++++++++++++++++------------------------
 4 files changed, 65 insertions(+), 102 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 3eab432..a5a34a3 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -382,6 +382,14 @@ config USB_OHCI_HCD_OMAP1
 	---help---
 	  Enables support for the OHCI controller on OMAP1/2 chips.
 
+config USB_OHCI_HCD_SPEAR
+        tristate "Support for ST SPEAr on-chip OHCI USB controller"
+        depends on USB_OHCI_HCD && PLAT_SPEAR
+        default y
+        ---help---
+          Enables support for the on-chip OHCI controller on
+          ST SPEAr chips.
+
 config USB_OHCI_HCD_OMAP3
 	tristate "OHCI support for OMAP3 and later chips"
 	depends on (ARCH_OMAP3 || ARCH_OMAP4)
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 954466d..b8ea17c 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)	+= ohci-platform.o
 obj-$(CONFIG_USB_OHCI_EXYNOS)	+= ohci-exynos.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP1)	+= ohci-omap.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP3)	+= ohci-omap3.o
+obj-$(CONFIG_USB_OHCI_HCD_SPEAR)	+= ohci-spear.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index cad51d2..34ec156 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1212,11 +1212,6 @@ MODULE_LICENSE ("GPL");
 #define OF_PLATFORM_DRIVER	ohci_hcd_ppc_of_driver
 #endif
 
-#ifdef CONFIG_PLAT_SPEAR
-#include "ohci-spear.c"
-#define SPEAR_PLATFORM_DRIVER	spear_ohci_hcd_driver
-#endif
-
 #ifdef CONFIG_PPC_PS3
 #include "ohci-ps3.c"
 #define PS3_SYSTEM_BUS_DRIVER	ps3_ohci_driver
@@ -1333,19 +1328,9 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_davinci;
 #endif
 
-#ifdef SPEAR_PLATFORM_DRIVER
-	retval = platform_driver_register(&SPEAR_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_spear;
-#endif
-
 	return retval;
 
 	/* Error path */
-#ifdef SPEAR_PLATFORM_DRIVER
-	platform_driver_unregister(&SPEAR_PLATFORM_DRIVER);
- error_spear:
-#endif
 #ifdef DAVINCI_PLATFORM_DRIVER
 	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
  error_davinci:
@@ -1403,9 +1388,6 @@ module_init(ohci_hcd_mod_init);
 
 static void __exit ohci_hcd_mod_exit(void)
 {
-#ifdef SPEAR_PLATFORM_DRIVER
-	platform_driver_unregister(&SPEAR_PLATFORM_DRIVER);
-#endif
 #ifdef DAVINCI_PLATFORM_DRIVER
 	platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
index cc9dd9e..31ff3fc 100644
--- a/drivers/usb/host/ohci-spear.c
+++ b/drivers/usb/host/ohci-spear.c
@@ -11,92 +11,37 @@
 * warranty of any kind, whether express or implied.
 */
 
-#include <linux/signal.h>
-#include <linux/platform_device.h>
 #include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/signal.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ohci.h"
 
+#define DRIVER_DESC "OHCI SPEAr driver"
+
+static const char hcd_name[] = "SPEAr-ohci";
 struct spear_ohci {
-	struct ohci_hcd ohci;
 	struct clk *clk;
 };
 
-#define to_spear_ohci(hcd)	(struct spear_ohci *)hcd_to_ohci(hcd)
-
-static void spear_start_ohci(struct spear_ohci *ohci)
-{
-	clk_prepare_enable(ohci->clk);
-}
-
-static void spear_stop_ohci(struct spear_ohci *ohci)
-{
-	clk_disable_unprepare(ohci->clk);
-}
-
-static int ohci_spear_start(struct usb_hcd *hcd)
-{
-	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
-	int ret;
-
-	ret = ohci_init(ohci);
-	if (ret < 0)
-		return ret;
-	ohci->regs = hcd->regs;
-
-	ret = ohci_run(ohci);
-	if (ret < 0) {
-		dev_err(hcd->self.controller, "can't start\n");
-		ohci_stop(hcd);
-		return ret;
-	}
-
-	create_debug_files(ohci);
-
-#ifdef DEBUG
-	ohci_dump(ohci, 1);
-#endif
-	return 0;
-}
-
-static const struct hc_driver ohci_spear_hc_driver = {
-	.description		= hcd_name,
-	.product_desc		= "SPEAr OHCI",
-	.hcd_priv_size		= sizeof(struct spear_ohci),
-
-	/* generic hardware linkage */
-	.irq			= ohci_irq,
-	.flags			= HCD_USB11 | HCD_MEMORY,
-
-	/* basic lifecycle operations */
-	.start			= ohci_spear_start,
-	.stop			= ohci_stop,
-	.shutdown		= ohci_shutdown,
-#ifdef	CONFIG_PM
-	.bus_suspend		= ohci_bus_suspend,
-	.bus_resume		= ohci_bus_resume,
-#endif
-
-	/* managing i/o requests and associated device resources */
-	.urb_enqueue		= ohci_urb_enqueue,
-	.urb_dequeue		= ohci_urb_dequeue,
-	.endpoint_disable	= ohci_endpoint_disable,
-
-	/* scheduling support */
-	.get_frame_number	= ohci_get_frame,
+#define to_spear_ohci(hcd)     (struct spear_ohci *)(hcd_to_ohci(hcd)->priv)
 
-	/* root hub support */
-	.hub_status_data	= ohci_hub_status_data,
-	.hub_control		= ohci_hub_control,
-
-	.start_port_reset	= ohci_start_port_reset,
-};
+static struct hc_driver __read_mostly ohci_spear_hc_driver;
 
 static int spear_ohci_hcd_drv_probe(struct platform_device *pdev)
 {
 	const struct hc_driver *driver = &ohci_spear_hc_driver;
+	struct ohci_hcd *ohci;
 	struct usb_hcd *hcd = NULL;
 	struct clk *usbh_clk;
-	struct spear_ohci *ohci_p;
+	struct spear_ohci *sohci_p;
 	struct resource *res;
 	int retval, irq;
 
@@ -151,16 +96,18 @@ static int spear_ohci_hcd_drv_probe(struct platform_device *pdev)
 		goto err_put_hcd;
 	}
 
-	ohci_p = (struct spear_ohci *)hcd_to_ohci(hcd);
-	ohci_p->clk = usbh_clk;
-	spear_start_ohci(ohci_p);
-	ohci_hcd_init(hcd_to_ohci(hcd));
+	sohci_p = to_spear_ohci(hcd);
+	sohci_p->clk = usbh_clk;
+
+	clk_prepare_enable(sohci_p->clk);
+
+	ohci = hcd_to_ohci(hcd);
 
 	retval = usb_add_hcd(hcd, platform_get_irq(pdev, 0), 0);
 	if (retval == 0)
 		return retval;
 
-	spear_stop_ohci(ohci_p);
+	clk_disable_unprepare(sohci_p->clk);
 err_put_hcd:
 	usb_put_hcd(hcd);
 fail:
@@ -172,11 +119,11 @@ fail:
 static int spear_ohci_hcd_drv_remove(struct platform_device *pdev)
 {
 	struct usb_hcd *hcd = platform_get_drvdata(pdev);
-	struct spear_ohci *ohci_p = to_spear_ohci(hcd);
+	struct spear_ohci *sohci_p = to_spear_ohci(hcd);
 
 	usb_remove_hcd(hcd);
-	if (ohci_p->clk)
-		spear_stop_ohci(ohci_p);
+	if (sohci_p->clk)
+		clk_disable_unprepare(sohci_p->clk);
 
 	usb_put_hcd(hcd);
 	return 0;
@@ -188,13 +135,14 @@ static int spear_ohci_hcd_drv_suspend(struct platform_device *dev,
 {
 	struct usb_hcd *hcd = platform_get_drvdata(dev);
 	struct ohci_hcd	*ohci = hcd_to_ohci(hcd);
-	struct spear_ohci *ohci_p = to_spear_ohci(hcd);
+	struct spear_ohci *sohci_p = to_spear_ohci(hcd);
 
 	if (time_before(jiffies, ohci->next_statechange))
 		msleep(5);
 	ohci->next_statechange = jiffies;
 
-	spear_stop_ohci(ohci_p);
+	clk_disable_unprepare(sohci_p->clk);
+
 	return 0;
 }
 
@@ -202,13 +150,13 @@ static int spear_ohci_hcd_drv_resume(struct platform_device *dev)
 {
 	struct usb_hcd *hcd = platform_get_drvdata(dev);
 	struct ohci_hcd	*ohci = hcd_to_ohci(hcd);
-	struct spear_ohci *ohci_p = to_spear_ohci(hcd);
+	struct spear_ohci *sohci_p = to_spear_ohci(hcd);
 
 	if (time_before(jiffies, ohci->next_statechange))
 		msleep(5);
 	ohci->next_statechange = jiffies;
 
-	spear_start_ohci(ohci_p);
+	clk_prepare_enable(sohci_p->clk);
 	ohci_resume(hcd, false);
 	return 0;
 }
@@ -234,4 +182,28 @@ static struct platform_driver spear_ohci_hcd_driver = {
 	},
 };
 
+static const struct ohci_driver_overrides spear_overrides __initconst = {
+	.extra_priv_size = sizeof(struct spear_ohci),
+};
+static int __init ohci_spear_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ohci_init_driver(&ohci_spear_hc_driver, &spear_overrides);
+	return platform_driver_register(&spear_ohci_hcd_driver);
+}
+module_init(ohci_spear_init);
+
+static void __exit ohci_spear_cleanup(void)
+{
+	platform_driver_unregister(&spear_ohci_hcd_driver);
+}
+module_exit(ohci_spear_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_AUTHOR("Deepak Sikri");
+MODULE_LICENSE("GPL v2");
 MODULE_ALIAS("platform:spear-ohci");
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Wed Jul 31 02:08:03 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Wed, 31 Jul 2013 11:38:03 +0530
Subject: [PATCH V4 5/6] USB: OHCI: make ohci-at91 a separate driver
In-Reply-To: <1375250884-28447-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
 <1375250884-28447-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1375250884-28447-6-git-send-email-manjunath.goudar@linaro.org>

Separate the  TI OHCI Atmel host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.12.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -Set non-standard fields in ohci_at91_hc_driver manually, rather than
  relying on an expanded struct ohci_driver_overrides.
 -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
  relying on ohci_hub_control and hub_status_data being exported.
 -ohci_setup() has been removed because it is called in .reset member
  of the ohci_hc_driver structure.

V3:
 -The ohci_restart() function is not required in  current scenario,
  only discarding connection state of integrated transceivers is sufficient,
  for this directly handling ohci->hc_control.

V4:
 - Removed extra space after "tristate".
 - Removed extra space between function name  and '(' characters.
 - MODULE_ALIAS line moved to last statement of ohci-at91 file.
---
 drivers/usb/host/Kconfig     |    8 +++
 drivers/usb/host/Makefile    |    1 +
 drivers/usb/host/ohci-at91.c |  153 +++++++++++++++++++-----------------------
 drivers/usb/host/ohci-hcd.c  |   18 -----
 4 files changed, 77 insertions(+), 103 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a5a34a3..693560a 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR
           Enables support for the on-chip OHCI controller on
           ST SPEAr chips.
 
+config USB_OHCI_HCD_AT91
+        tristate "Support for Atmel on-chip OHCI USB controller"
+        depends on USB_OHCI_HCD && ARCH_AT91
+        default y
+        ---help---
+          Enables support for the on-chip OHCI controller on
+          Atmel chips.
+
 config USB_OHCI_HCD_OMAP3
 	tristate "OHCI support for OMAP3 and later chips"
 	depends on (ARCH_OMAP3 || ARCH_OMAP4)
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index b8ea17c..a70b044 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_USB_OHCI_EXYNOS)	+= ohci-exynos.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP1)	+= ohci-omap.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP3)	+= ohci-omap3.o
 obj-$(CONFIG_USB_OHCI_HCD_SPEAR)	+= ohci-spear.o
+obj-$(CONFIG_USB_OHCI_HCD_AT91)	+= ohci-at91.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 9677f68..08e28eb 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -13,27 +13,41 @@
  */
 
 #include <linux/clk.h>
-#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
 #include <linux/of_platform.h>
 #include <linux/of_gpio.h>
+#include <linux/platform_device.h>
 #include <linux/platform_data/atmel.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
 
 #include <mach/hardware.h>
 #include <asm/gpio.h>
 
 #include <mach/cpu.h>
 
-#ifndef CONFIG_ARCH_AT91
-#error "CONFIG_ARCH_AT91 must be defined."
-#endif
+
+#include "ohci.h"
 
 #define valid_port(index)	((index) >= 0 && (index) < AT91_MAX_USBH_PORTS)
 #define at91_for_each_port(index)	\
 		for ((index) = 0; (index) < AT91_MAX_USBH_PORTS; (index)++)
 
 /* interface and function clocks; sometimes also an AHB clock */
+
+#define DRIVER_DESC "OHCI Atmel driver"
+
+static const char hcd_name[] = "ohci-atmel";
+
+static struct hc_driver __read_mostly ohci_at91_hc_driver;
 static struct clk *iclk, *fclk, *hclk;
 static int clocked;
+static int (*orig_ohci_hub_control)(struct usb_hcd  *hcd, u16 typeReq,
+			u16 wValue, u16 wIndex, char *buf, u16 wLength);
+static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
 
 extern int usb_disabled(void);
 
@@ -111,6 +125,8 @@ static void usb_hcd_at91_remove (struct usb_hcd *, struct platform_device *);
 static int usb_hcd_at91_probe(const struct hc_driver *driver,
 			struct platform_device *pdev)
 {
+	struct at91_usbh_data *board;
+	struct ohci_hcd *ohci;
 	int retval;
 	struct usb_hcd *hcd = NULL;
 
@@ -163,8 +179,10 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
 		goto err5;
 	}
 
+	board = hcd->self.controller->platform_data;
+	ohci = hcd_to_ohci(hcd);
+	ohci->num_ports = board->ports;
 	at91_start_hc(pdev);
-	ohci_hcd_init(hcd_to_ohci(hcd));
 
 	retval = usb_add_hcd(hcd, pdev->resource[1].start, IRQF_SHARED);
 	if (retval == 0)
@@ -221,36 +239,6 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
 }
 
 /*-------------------------------------------------------------------------*/
-
-static int
-ohci_at91_reset (struct usb_hcd *hcd)
-{
-	struct at91_usbh_data	*board = hcd->self.controller->platform_data;
-	struct ohci_hcd		*ohci = hcd_to_ohci (hcd);
-	int			ret;
-
-	if ((ret = ohci_init(ohci)) < 0)
-		return ret;
-
-	ohci->num_ports = board->ports;
-	return 0;
-}
-
-static int
-ohci_at91_start (struct usb_hcd *hcd)
-{
-	struct ohci_hcd		*ohci = hcd_to_ohci (hcd);
-	int			ret;
-
-	if ((ret = ohci_run(ohci)) < 0) {
-		dev_err(hcd->self.controller, "can't start %s\n",
-			hcd->self.bus_name);
-		ohci_stop(hcd);
-		return ret;
-	}
-	return 0;
-}
-
 static void ohci_at91_usb_set_power(struct at91_usbh_data *pdata, int port, int enable)
 {
 	if (!valid_port(port))
@@ -281,7 +269,7 @@ static int ohci_at91_usb_get_power(struct at91_usbh_data *pdata, int port)
 static int ohci_at91_hub_status_data(struct usb_hcd *hcd, char *buf)
 {
 	struct at91_usbh_data *pdata = hcd->self.controller->platform_data;
-	int length = ohci_hub_status_data(hcd, buf);
+	int length = orig_ohci_hub_status_data(hcd, buf);
 	int port;
 
 	at91_for_each_port(port) {
@@ -359,7 +347,8 @@ static int ohci_at91_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
 		break;
 	}
 
-	ret = ohci_hub_control(hcd, typeReq, wValue, wIndex + 1, buf, wLength);
+	ret = orig_ohci_hub_control(hcd, typeReq, wValue, wIndex + 1,
+				buf, wLength);
 	if (ret)
 		goto out;
 
@@ -413,51 +402,6 @@ static int ohci_at91_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
 
 /*-------------------------------------------------------------------------*/
 
-static const struct hc_driver ohci_at91_hc_driver = {
-	.description =		hcd_name,
-	.product_desc =		"AT91 OHCI",
-	.hcd_priv_size =	sizeof(struct ohci_hcd),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq =			ohci_irq,
-	.flags =		HCD_USB11 | HCD_MEMORY,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.reset =		ohci_at91_reset,
-	.start =		ohci_at91_start,
-	.stop =			ohci_stop,
-	.shutdown =		ohci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue =		ohci_urb_enqueue,
-	.urb_dequeue =		ohci_urb_dequeue,
-	.endpoint_disable =	ohci_endpoint_disable,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number =	ohci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data =	ohci_at91_hub_status_data,
-	.hub_control =		ohci_at91_hub_control,
-#ifdef CONFIG_PM
-	.bus_suspend =		ohci_bus_suspend,
-	.bus_resume =		ohci_bus_resume,
-#endif
-	.start_port_reset =	ohci_start_port_reset,
-};
-
-/*-------------------------------------------------------------------------*/
-
 static irqreturn_t ohci_hcd_at91_overcurrent_irq(int irq, void *data)
 {
 	struct platform_device *pdev = data;
@@ -686,7 +630,11 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev, pm_message_t mesg)
 	 * REVISIT: some boards will be able to turn VBUS off...
 	 */
 	if (at91_suspend_entering_slow_clock()) {
-		ohci_usb_reset (ohci);
+		ohci->hc_control = ohci_readl(ohci, &ohci->regs->control);
+		ohci->hc_control &= OHCI_CTRL_RWC;
+		ohci_writel(ohci, ohci->hc_control, &ohci->regs->control);
+		ohci->rh_state = OHCI_RH_HALTED;
+
 		/* flush the writes */
 		(void) ohci_readl (ohci, &ohci->regs->control);
 		at91_stop_clock();
@@ -713,8 +661,6 @@ static int ohci_hcd_at91_drv_resume(struct platform_device *pdev)
 #define ohci_hcd_at91_drv_resume  NULL
 #endif
 
-MODULE_ALIAS("platform:at91_ohci");
-
 static struct platform_driver ohci_hcd_at91_driver = {
 	.probe		= ohci_hcd_at91_drv_probe,
 	.remove		= ohci_hcd_at91_drv_remove,
@@ -727,3 +673,40 @@ static struct platform_driver ohci_hcd_at91_driver = {
 		.of_match_table	= of_match_ptr(at91_ohci_dt_ids),
 	},
 };
+
+static int __init ohci_at91_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+	ohci_init_driver(&ohci_at91_hc_driver, NULL);
+
+	/*
+	 * The Atmel HW has some unusual quirks, which require Atmel-specific
+	 * workarounds. We override certain hc_driver functions here to
+	 * achieve that. We explicitly do not enhance ohci_driver_overrides to
+	 * allow this more easily, since this is an unusual case, and we don't
+	 * want to encourage others to override these functions by making it
+	 * too easy.
+	 */
+
+	orig_ohci_hub_control = ohci_at91_hc_driver.hub_control;
+	orig_ohci_hub_status_data = ohci_at91_hc_driver.hub_status_data;
+
+	ohci_at91_hc_driver.hub_status_data	= ohci_at91_hub_status_data;
+	ohci_at91_hc_driver.hub_control		= ohci_at91_hub_control;
+
+	return platform_driver_register(&ohci_hcd_at91_driver);
+}
+module_init(ohci_at91_init);
+
+static void __exit ohci_at91_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_at91_driver);
+}
+module_exit(ohci_at91_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:at91_ohci");
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 34ec156..b48c892 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1192,11 +1192,6 @@ MODULE_LICENSE ("GPL");
 #define EP93XX_PLATFORM_DRIVER	ohci_hcd_ep93xx_driver
 #endif
 
-#ifdef CONFIG_ARCH_AT91
-#include "ohci-at91.c"
-#define AT91_PLATFORM_DRIVER	ohci_hcd_at91_driver
-#endif
-
 #ifdef CONFIG_ARCH_LPC32XX
 #include "ohci-nxp.c"
 #define NXP_PLATFORM_DRIVER	usb_hcd_nxp_driver
@@ -1310,12 +1305,6 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_ep93xx;
 #endif
 
-#ifdef AT91_PLATFORM_DRIVER
-	retval = platform_driver_register(&AT91_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_at91;
-#endif
-
 #ifdef NXP_PLATFORM_DRIVER
 	retval = platform_driver_register(&NXP_PLATFORM_DRIVER);
 	if (retval < 0)
@@ -1339,10 +1328,6 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
  error_nxp:
 #endif
-#ifdef AT91_PLATFORM_DRIVER
-	platform_driver_unregister(&AT91_PLATFORM_DRIVER);
- error_at91:
-#endif
 #ifdef EP93XX_PLATFORM_DRIVER
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
  error_ep93xx:
@@ -1394,9 +1379,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef NXP_PLATFORM_DRIVER
 	platform_driver_unregister(&NXP_PLATFORM_DRIVER);
 #endif
-#ifdef AT91_PLATFORM_DRIVER
-	platform_driver_unregister(&AT91_PLATFORM_DRIVER);
-#endif
 #ifdef EP93XX_PLATFORM_DRIVER
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
 #endif
-- 
1.7.9.5



From manjunath.goudar at linaro.org  Wed Jul 31 02:08:04 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Wed, 31 Jul 2013 11:38:04 +0530
Subject: [PATCH V4 6/6] USB: OHCI: make ohci-s3c2410 a separate driver
In-Reply-To: <1375250884-28447-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
 <1375250884-28447-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1375250884-28447-7-git-send-email-manjunath.goudar@linaro.org>

Separate the Samsung OHCI S3CXXXX host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.12.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -Set non-standard fields in ohci_s3c2410_hc_driver manually, rather than
  relying on an expanded struct ohci_driver_overrides.
 -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
  relying on ohci_hub_control and hub_status_data being exported.

V3:
 -Kconfig wrong parentheses discription fixed.
 -ohci_setup() has been removed because it is called in .reset member
  of the ohci_hc_driver structure.

V4:
 - Removed extra space before the '='.
 - Moved  /* forward definitions */ line before the declarations of functions.
---
 drivers/usb/host/Kconfig        |    8 +++
 drivers/usb/host/Makefile       |    1 +
 drivers/usb/host/ohci-hcd.c     |   18 ------
 drivers/usb/host/ohci-s3c2410.c |  128 +++++++++++++++++----------------------
 4 files changed, 66 insertions(+), 89 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 693560a..795d14d 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR
           Enables support for the on-chip OHCI controller on
           ST SPEAr chips.
 
+config USB_OHCI_HCD_S3CXXXX
+        tristate "Support for S3CXXXX on-chip OHCI USB controller"
+        depends on USB_OHCI_HCD && (ARCH_S3C24XX || ARCH_S3C64XX)
+        default y
+        ---help---
+          Enables support for the on-chip OHCI controller on
+          S3CXXXX chips.
+
 config USB_OHCI_HCD_AT91
         tristate "Support for Atmel on-chip OHCI USB controller"
         depends on USB_OHCI_HCD && ARCH_AT91
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index a70b044..9dffe81 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_USB_OHCI_HCD_OMAP1)	+= ohci-omap.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP3)	+= ohci-omap3.o
 obj-$(CONFIG_USB_OHCI_HCD_SPEAR)	+= ohci-spear.o
 obj-$(CONFIG_USB_OHCI_HCD_AT91)	+= ohci-at91.o
+obj-$(CONFIG_USB_OHCI_HCD_S3CXXXX)	+= ohci-s3c2410.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index b48c892..b69a49e 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1177,11 +1177,6 @@ MODULE_LICENSE ("GPL");
 #define SA1111_DRIVER		ohci_hcd_sa1111_driver
 #endif
 
-#if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX)
-#include "ohci-s3c2410.c"
-#define S3C2410_PLATFORM_DRIVER	ohci_hcd_s3c2410_driver
-#endif
-
 #if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx)
 #include "ohci-pxa27x.c"
 #define PLATFORM_DRIVER		ohci_hcd_pxa27x_driver
@@ -1293,12 +1288,6 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_tmio;
 #endif
 
-#ifdef S3C2410_PLATFORM_DRIVER
-	retval = platform_driver_register(&S3C2410_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_s3c2410;
-#endif
-
 #ifdef EP93XX_PLATFORM_DRIVER
 	retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
 	if (retval < 0)
@@ -1332,10 +1321,6 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
  error_ep93xx:
 #endif
-#ifdef S3C2410_PLATFORM_DRIVER
-	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
- error_s3c2410:
-#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
  error_tmio:
@@ -1382,9 +1367,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef EP93XX_PLATFORM_DRIVER
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
 #endif
-#ifdef S3C2410_PLATFORM_DRIVER
-	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
-#endif
 #ifdef TMIO_OHCI_DRIVER
 	platform_driver_unregister(&TMIO_OHCI_DRIVER);
 #endif
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index e125770..48b5948 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -19,19 +19,36 @@
  * This file is licenced under the GPL.
 */
 
-#include <linux/platform_device.h>
 #include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
 #include <linux/platform_data/usb-ohci-s3c2410.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ohci.h"
+
 
 #define valid_port(idx) ((idx) == 1 || (idx) == 2)
 
 /* clock device associated with the hcd */
 
+
+#define DRIVER_DESC "OHCI S3CXXXX driver"
+
+static const char hcd_name[] = "ohci-s3cxxxx";
+
 static struct clk *clk;
 static struct clk *usb_clk;
 
 /* forward definitions */
 
+static int (*orig_ohci_hub_control)(struct usb_hcd  *hcd, u16 typeReq,
+			u16 wValue, u16 wIndex, char *buf, u16 wLength);
+static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
+
 static void s3c2410_hcd_oc(struct s3c2410_hcd_info *info, int port_oc);
 
 /* conversion functions */
@@ -93,7 +110,7 @@ ohci_s3c2410_hub_status_data(struct usb_hcd *hcd, char *buf)
 	int orig;
 	int portno;
 
-	orig  = ohci_hub_status_data(hcd, buf);
+	orig = orig_ohci_hub_status_data(hcd, buf);
 
 	if (info == NULL)
 		return orig;
@@ -164,7 +181,7 @@ static int ohci_s3c2410_hub_control(
 	 * process the request straight away and exit */
 
 	if (info == NULL) {
-		ret = ohci_hub_control(hcd, typeReq, wValue,
+		ret = orig_ohci_hub_control(hcd, typeReq, wValue,
 				       wIndex, buf, wLength);
 		goto out;
 	}
@@ -214,7 +231,7 @@ static int ohci_s3c2410_hub_control(
 		break;
 	}
 
-	ret = ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+	ret = orig_ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
 	if (ret)
 		goto out;
 
@@ -373,8 +390,6 @@ static int usb_hcd_s3c2410_probe(const struct hc_driver *driver,
 
 	s3c2410_start_hc(dev, hcd);
 
-	ohci_hcd_init(hcd_to_ohci(hcd));
-
 	retval = usb_add_hcd(hcd, dev->resource[1].start, 0);
 	if (retval != 0)
 		goto err_ioremap;
@@ -391,71 +406,7 @@ static int usb_hcd_s3c2410_probe(const struct hc_driver *driver,
 
 /*-------------------------------------------------------------------------*/
 
-static int
-ohci_s3c2410_start(struct usb_hcd *hcd)
-{
-	struct ohci_hcd	*ohci = hcd_to_ohci(hcd);
-	int ret;
-
-	ret = ohci_init(ohci);
-	if (ret < 0)
-		return ret;
-
-	ret = ohci_run(ohci);
-	if (ret < 0) {
-		dev_err(hcd->self.controller, "can't start %s\n",
-			hcd->self.bus_name);
-		ohci_stop(hcd);
-		return ret;
-	}
-
-	return 0;
-}
-
-
-static const struct hc_driver ohci_s3c2410_hc_driver = {
-	.description =		hcd_name,
-	.product_desc =		"S3C24XX OHCI",
-	.hcd_priv_size =	sizeof(struct ohci_hcd),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq =			ohci_irq,
-	.flags =		HCD_USB11 | HCD_MEMORY,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.start =		ohci_s3c2410_start,
-	.stop =			ohci_stop,
-	.shutdown =		ohci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue =		ohci_urb_enqueue,
-	.urb_dequeue =		ohci_urb_dequeue,
-	.endpoint_disable =	ohci_endpoint_disable,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number =	ohci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data =	ohci_s3c2410_hub_status_data,
-	.hub_control =		ohci_s3c2410_hub_control,
-#ifdef	CONFIG_PM
-	.bus_suspend =		ohci_bus_suspend,
-	.bus_resume =		ohci_bus_resume,
-#endif
-	.start_port_reset =	ohci_start_port_reset,
-};
-
-/* device driver */
+static struct hc_driver __read_mostly ohci_s3c2410_hc_driver;
 
 static int ohci_hcd_s3c2410_drv_probe(struct platform_device *pdev)
 {
@@ -532,4 +483,39 @@ static struct platform_driver ohci_hcd_s3c2410_driver = {
 	},
 };
 
+static int __init ohci_s3cxxxx_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+	ohci_init_driver(&ohci_s3c2410_hc_driver, NULL);
+
+	/*
+	 * The Samsung HW has some unusual quirks, which require
+	 * Sumsung-specific workarounds. We override certain hc_driver
+	 * functions here to achieve that. We explicitly do not enhance
+	 * ohci_driver_overrides to allow this more easily, since this
+	 * is an unusual case, and we don't want to encourage others to
+	 * override these functions by making it too easy.
+	 */
+
+	orig_ohci_hub_control = ohci_s3c2410_hc_driver.hub_control;
+	orig_ohci_hub_status_data = ohci_s3c2410_hc_driver.hub_status_data;
+
+	ohci_s3c2410_hc_driver.hub_status_data	= ohci_s3c2410_hub_status_data;
+	ohci_s3c2410_hc_driver.hub_control	= ohci_s3c2410_hub_control;
+
+	return platform_driver_register(&ohci_hcd_s3c2410_driver);
+}
+module_init(ohci_s3cxxxx_init);
+
+static void __exit ohci_s3cxxxx_cleanup(void)
+{
+	platform_driver_unregister(&ohci_hcd_s3c2410_driver);
+}
+module_exit(ohci_s3cxxxx_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:s3c2410-ohci");
-- 
1.7.9.5



From olof at lixom.net  Wed Jul 31 02:13:52 2013
From: olof at lixom.net (Olof Johansson)
Date: Tue, 30 Jul 2013 23:13:52 -0700
Subject: New dapm panic on beaver with next-20130730
In-Reply-To: <51F8A933.4080708@metafoo.de>
References: <CAOesGMig6jry1GJLoTnOqxom1KjtBTUtZz-_-SiZLpGTc3VkqA@mail.gmail.com>
 <51F8A933.4080708@metafoo.de>
Message-ID: <CAOesGMjqyF7zPoGsW6oBRFey7Bc_umnoGob7oQ=_c3n7oevuaQ@mail.gmail.com>

On Tue, Jul 30, 2013 at 11:05 PM, Lars-Peter Clausen <lars at metafoo.de> wrote:
> On 07/31/2013 07:36 AM, Olof Johansson wrote:
>>
>> Hi Mark, Lars-Peter,
>>
>> I noticed the below panic on beaver (Tegra30). Seems like seaboard
>> (Tegra20) is fine. This is with next-20130730, tegra_defconfig.
>
>
> Hi,
>
> So the same machine driver with the same codec works on tegra2, but not on
> tegra3? The crash doesn't seem to be directly related to the patch, but the
> patch changed the memory layout. Is it possible that you still have a
> outdated module that's being loaded on your tegra3 board?

Sorry, I should have been cleared on that. Not at all the same codec,
seaboard uses wm8903, beaver rt5640.

> Can you add a few debugging printks and run the test again and paste the
> last few lines before the crash:

[beaver          00:18] [    4.045897] dapm_generic_check_power: IF2 ADC L
[beaver          00:18] [    4.050417] dapm_clear_walk_output 1: ee3a7bc0
[beaver          00:18] [    4.054845] dapm_generic_check_power: IF2 DAC
[beaver          00:18] [    4.059193] dapm_clear_walk_output 1: ee3a8240
[beaver          00:18] [    4.063621] dapm_clear_walk_output 1: ee3a8280
[beaver          00:18] [    4.068048] dapm_generic_check_power: IF1 ADC R
[beaver          00:18] [    4.072661] dapm_clear_walk_output 1: ee3a7c40
[beaver          00:18] [    4.077091] dapm_generic_check_power: IF1 ADC L
[beaver          00:18] [    4.081616] dapm_clear_walk_output 1: ee3a7c80
[beaver          00:18] [    4.086045] dapm_generic_check_power: IF1 DAC
[beaver          00:18] [    4.090394] dapm_clear_walk_output 1: ee3a82c0
[beaver          00:18] [    4.094821] dapm_clear_walk_output 1: ee3a8300
[beaver          00:18] [    4.099256] dapm_generic_check_power: INR Mux
[beaver          00:18] [    4.103599] dapm_clear_walk_output 1: ee3af670
[beaver          00:18] [    4.108026] dapm_generic_check_power: INL Mux
[beaver          00:18] [    4.112375] dapm_clear_walk_output 1: ee3af5f0
[beaver          00:18] [    4.116802] dapm_clear_walk_output 2: 6b6b6b6b
[beaver          00:18] [    4.121246] Unable to handle kernel paging
request at virtual address 6b6b6b6f
[beaver          00:18] [    4.128449] pgd = c0004000
[beaver          00:18] [    4.131151] [6b6b6b6f] *pgd=00000000
[beaver          00:18] [    4.134723] Internal error: Oops: 5 [#1]
PREEMPT SMP ARM


From manjunath.goudar at linaro.org  Wed Jul 31 02:07:59 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Wed, 31 Jul 2013 11:37:59 +0530
Subject: [PATCH V4 1/6] USB: OHCI: make ohci-exynos a separate driver
In-Reply-To: <1375250884-28447-1-git-send-email-manjunath.goudar@linaro.org>
References: <1370585013-12809-1-git-send-email-manjunath.goudar@linaro.org>
 <1375250884-28447-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1375250884-28447-2-git-send-email-manjunath.goudar@linaro.org>

Separate the  Samsung OHCI EXYNOS host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Acked-by: Jingoo Han <jg1.han at samsung.com>
Cc: Vivek Gautam <gautam.vivek at samsung.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org

V2:
 -exynos_ohci_hcd structure assignment error fixed.
 -Removed multiple usb_create_hcd() from prob funtion.
 -platform_set_drvdata() called before exynos_ohci_phy_enable().
 -ohci_setup() removed because it is called in .reset member
  of the ohci_hc_driver structure

V3:
 -No major changes only "exynos" written in capital letters
  in "OHCI exynos driver".
---
 drivers/usb/host/Kconfig       |    2 +-
 drivers/usb/host/Makefile      |    1 +
 drivers/usb/host/ohci-exynos.c |  167 +++++++++++++++++-----------------------
 drivers/usb/host/ohci-hcd.c    |   18 -----
 4 files changed, 71 insertions(+), 117 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 7bc598b..7b8f6bd 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -463,7 +463,7 @@ config USB_OHCI_SH
 	  If you use the PCI OHCI controller, this option is not necessary.
 
 config USB_OHCI_EXYNOS
-	boolean "OHCI support for Samsung EXYNOS SoC Series"
+	tristate "OHCI support for Samsung EXYNOS SoC Series"
 	depends on ARCH_EXYNOS
 	help
 	 Enable support for the Samsung Exynos SOC's on-chip OHCI controller.
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 480e203..26cf69a 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_USB_ISP1362_HCD)	+= isp1362-hcd.o
 obj-$(CONFIG_USB_OHCI_HCD)	+= ohci-hcd.o
 obj-$(CONFIG_USB_OHCI_HCD_PCI)	+= ohci-pci.o
 obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)	+= ohci-platform.o
+obj-$(CONFIG_USB_OHCI_EXYNOS)	+= ohci-exynos.o
 
 obj-$(CONFIG_USB_UHCI_HCD)	+= uhci-hcd.o
 obj-$(CONFIG_USB_FHCI_HCD)	+= fhci.o
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index b0b542c..ae6068d 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -12,24 +12,39 @@
  */
 
 #include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/platform_data/usb-ohci-exynos.h>
 #include <linux/usb/phy.h>
 #include <linux/usb/samsung_usb_phy.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+#include <linux/usb/otg.h>
+
+#include "ohci.h"
+
+#define DRIVER_DESC "OHCI EXYNOS driver"
+
+static const char hcd_name[] = "ohci-exynos";
+static struct hc_driver __read_mostly exynos_ohci_hc_driver;
+
+#define to_exynos_ohci(hcd) (struct exynos_ohci_hcd *)(hcd_to_ohci(hcd)->priv)
 
 struct exynos_ohci_hcd {
-	struct device *dev;
-	struct usb_hcd *hcd;
 	struct clk *clk;
 	struct usb_phy *phy;
 	struct usb_otg *otg;
 	struct exynos4_ohci_platdata *pdata;
 };
 
-static void exynos_ohci_phy_enable(struct exynos_ohci_hcd *exynos_ohci)
+static void exynos_ohci_phy_enable(struct platform_device *pdev)
 {
-	struct platform_device *pdev = to_platform_device(exynos_ohci->dev);
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
+	struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 
 	if (exynos_ohci->phy)
 		usb_phy_init(exynos_ohci->phy);
@@ -37,9 +52,10 @@ static void exynos_ohci_phy_enable(struct exynos_ohci_hcd *exynos_ohci)
 		exynos_ohci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
 }
 
-static void exynos_ohci_phy_disable(struct exynos_ohci_hcd *exynos_ohci)
+static void exynos_ohci_phy_disable(struct platform_device *pdev)
 {
-	struct platform_device *pdev = to_platform_device(exynos_ohci->dev);
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
+	struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 
 	if (exynos_ohci->phy)
 		usb_phy_shutdown(exynos_ohci->phy);
@@ -47,63 +63,11 @@ static void exynos_ohci_phy_disable(struct exynos_ohci_hcd *exynos_ohci)
 		exynos_ohci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
 }
 
-static int ohci_exynos_reset(struct usb_hcd *hcd)
-{
-	return ohci_init(hcd_to_ohci(hcd));
-}
-
-static int ohci_exynos_start(struct usb_hcd *hcd)
-{
-	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
-	int ret;
-
-	ohci_dbg(ohci, "ohci_exynos_start, ohci:%p", ohci);
-
-	ret = ohci_run(ohci);
-	if (ret < 0) {
-		dev_err(hcd->self.controller, "can't start %s\n",
-			hcd->self.bus_name);
-		ohci_stop(hcd);
-		return ret;
-	}
-
-	return 0;
-}
-
-static const struct hc_driver exynos_ohci_hc_driver = {
-	.description		= hcd_name,
-	.product_desc		= "EXYNOS OHCI Host Controller",
-	.hcd_priv_size		= sizeof(struct ohci_hcd),
-
-	.irq			= ohci_irq,
-	.flags			= HCD_MEMORY|HCD_USB11,
-
-	.reset			= ohci_exynos_reset,
-	.start			= ohci_exynos_start,
-	.stop			= ohci_stop,
-	.shutdown		= ohci_shutdown,
-
-	.get_frame_number	= ohci_get_frame,
-
-	.urb_enqueue		= ohci_urb_enqueue,
-	.urb_dequeue		= ohci_urb_dequeue,
-	.endpoint_disable	= ohci_endpoint_disable,
-
-	.hub_status_data	= ohci_hub_status_data,
-	.hub_control		= ohci_hub_control,
-#ifdef	CONFIG_PM
-	.bus_suspend		= ohci_bus_suspend,
-	.bus_resume		= ohci_bus_resume,
-#endif
-	.start_port_reset	= ohci_start_port_reset,
-};
-
 static int exynos_ohci_probe(struct platform_device *pdev)
 {
 	struct exynos4_ohci_platdata *pdata = pdev->dev.platform_data;
 	struct exynos_ohci_hcd *exynos_ohci;
 	struct usb_hcd *hcd;
-	struct ohci_hcd *ohci;
 	struct resource *res;
 	struct usb_phy *phy;
 	int irq;
@@ -119,10 +83,14 @@ static int exynos_ohci_probe(struct platform_device *pdev)
 	if (!pdev->dev.coherent_dma_mask)
 		pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
 
-	exynos_ohci = devm_kzalloc(&pdev->dev, sizeof(struct exynos_ohci_hcd),
-					GFP_KERNEL);
-	if (!exynos_ohci)
+	hcd = usb_create_hcd(&exynos_ohci_hc_driver,
+				&pdev->dev, dev_name(&pdev->dev));
+	if (!hcd) {
+		dev_err(&pdev->dev, "Unable to create HCD\n");
 		return -ENOMEM;
+	}
+
+	exynos_ohci = to_exynos_ohci(hcd);
 
 	if (of_device_is_compatible(pdev->dev.of_node,
 					"samsung,exynos5440-ohci"))
@@ -143,17 +111,6 @@ static int exynos_ohci_probe(struct platform_device *pdev)
 	}
 
 skip_phy:
-
-	exynos_ohci->dev = &pdev->dev;
-
-	hcd = usb_create_hcd(&exynos_ohci_hc_driver, &pdev->dev,
-					dev_name(&pdev->dev));
-	if (!hcd) {
-		dev_err(&pdev->dev, "Unable to create HCD\n");
-		return -ENOMEM;
-	}
-
-	exynos_ohci->hcd = hcd;
 	exynos_ohci->clk = devm_clk_get(&pdev->dev, "usbhost");
 
 	if (IS_ERR(exynos_ohci->clk)) {
@@ -190,26 +147,21 @@ skip_phy:
 	}
 
 	if (exynos_ohci->otg)
-		exynos_ohci->otg->set_host(exynos_ohci->otg,
-					&exynos_ohci->hcd->self);
+		exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
 
-	exynos_ohci_phy_enable(exynos_ohci);
+	platform_set_drvdata(pdev, hcd);
 
-	ohci = hcd_to_ohci(hcd);
-	ohci_hcd_init(ohci);
+	exynos_ohci_phy_enable(pdev);
 
 	err = usb_add_hcd(hcd, irq, IRQF_SHARED);
 	if (err) {
 		dev_err(&pdev->dev, "Failed to add USB HCD\n");
 		goto fail_add_hcd;
 	}
-
-	platform_set_drvdata(pdev, exynos_ohci);
-
 	return 0;
 
 fail_add_hcd:
-	exynos_ohci_phy_disable(exynos_ohci);
+	exynos_ohci_phy_disable(pdev);
 fail_io:
 	clk_disable_unprepare(exynos_ohci->clk);
 fail_clk:
@@ -219,16 +171,15 @@ fail_clk:
 
 static int exynos_ohci_remove(struct platform_device *pdev)
 {
-	struct exynos_ohci_hcd *exynos_ohci = platform_get_drvdata(pdev);
-	struct usb_hcd *hcd = exynos_ohci->hcd;
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
+	struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 
 	usb_remove_hcd(hcd);
 
 	if (exynos_ohci->otg)
-		exynos_ohci->otg->set_host(exynos_ohci->otg,
-					&exynos_ohci->hcd->self);
+		exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
 
-	exynos_ohci_phy_disable(exynos_ohci);
+	exynos_ohci_phy_disable(pdev);
 
 	clk_disable_unprepare(exynos_ohci->clk);
 
@@ -239,8 +190,7 @@ static int exynos_ohci_remove(struct platform_device *pdev)
 
 static void exynos_ohci_shutdown(struct platform_device *pdev)
 {
-	struct exynos_ohci_hcd *exynos_ohci = platform_get_drvdata(pdev);
-	struct usb_hcd *hcd = exynos_ohci->hcd;
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
 
 	if (hcd->driver->shutdown)
 		hcd->driver->shutdown(hcd);
@@ -249,9 +199,10 @@ static void exynos_ohci_shutdown(struct platform_device *pdev)
 #ifdef CONFIG_PM
 static int exynos_ohci_suspend(struct device *dev)
 {
-	struct exynos_ohci_hcd *exynos_ohci = dev_get_drvdata(dev);
-	struct usb_hcd *hcd = exynos_ohci->hcd;
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
+	struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 	struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+	struct platform_device *pdev = to_platform_device(dev);
 	unsigned long flags;
 	int rc = 0;
 
@@ -271,10 +222,9 @@ static int exynos_ohci_suspend(struct device *dev)
 	clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
 
 	if (exynos_ohci->otg)
-		exynos_ohci->otg->set_host(exynos_ohci->otg,
-					&exynos_ohci->hcd->self);
+		exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
 
-	exynos_ohci_phy_disable(exynos_ohci);
+	exynos_ohci_phy_disable(pdev);
 
 	clk_disable_unprepare(exynos_ohci->clk);
 
@@ -286,16 +236,16 @@ fail:
 
 static int exynos_ohci_resume(struct device *dev)
 {
-	struct exynos_ohci_hcd *exynos_ohci = dev_get_drvdata(dev);
-	struct usb_hcd *hcd = exynos_ohci->hcd;
+	struct usb_hcd *hcd			= dev_get_drvdata(dev);
+	struct exynos_ohci_hcd *exynos_ohci	= to_exynos_ohci(hcd);
+	struct platform_device *pdev		= to_platform_device(dev);
 
 	clk_prepare_enable(exynos_ohci->clk);
 
 	if (exynos_ohci->otg)
-		exynos_ohci->otg->set_host(exynos_ohci->otg,
-					&exynos_ohci->hcd->self);
+		exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
 
-	exynos_ohci_phy_enable(exynos_ohci);
+	exynos_ohci_phy_enable(pdev);
 
 	ohci_resume(hcd, false);
 
@@ -306,6 +256,10 @@ static int exynos_ohci_resume(struct device *dev)
 #define exynos_ohci_resume	NULL
 #endif
 
+static const struct ohci_driver_overrides exynos_overrides __initconst = {
+	.extra_priv_size =	sizeof(struct exynos_ohci_hcd),
+};
+
 static const struct dev_pm_ops exynos_ohci_pm_ops = {
 	.suspend	= exynos_ohci_suspend,
 	.resume		= exynos_ohci_resume,
@@ -331,6 +285,23 @@ static struct platform_driver exynos_ohci_driver = {
 		.of_match_table	= of_match_ptr(exynos_ohci_match),
 	}
 };
+static int __init ohci_exynos_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+	ohci_init_driver(&exynos_ohci_hc_driver, &exynos_overrides);
+	return platform_driver_register(&exynos_ohci_driver);
+}
+module_init(ohci_exynos_init);
+
+static void __exit ohci_exynos_cleanup(void)
+{
+	platform_driver_unregister(&exynos_ohci_driver);
+}
+module_exit(ohci_exynos_cleanup);
 
 MODULE_ALIAS("platform:exynos-ohci");
 MODULE_AUTHOR("Jingoo Han <jg1.han at samsung.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index a9d3437..2980bb6 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1182,11 +1182,6 @@ MODULE_LICENSE ("GPL");
 #define S3C2410_PLATFORM_DRIVER	ohci_hcd_s3c2410_driver
 #endif
 
-#ifdef CONFIG_USB_OHCI_EXYNOS
-#include "ohci-exynos.c"
-#define EXYNOS_PLATFORM_DRIVER	exynos_ohci_driver
-#endif
-
 #ifdef CONFIG_USB_OHCI_HCD_OMAP1
 #include "ohci-omap.c"
 #define OMAP1_PLATFORM_DRIVER	ohci_hcd_omap_driver
@@ -1336,12 +1331,6 @@ static int __init ohci_hcd_mod_init(void)
 		goto error_s3c2410;
 #endif
 
-#ifdef EXYNOS_PLATFORM_DRIVER
-	retval = platform_driver_register(&EXYNOS_PLATFORM_DRIVER);
-	if (retval < 0)
-		goto error_exynos;
-#endif
-
 #ifdef EP93XX_PLATFORM_DRIVER
 	retval = platform_driver_register(&EP93XX_PLATFORM_DRIVER);
 	if (retval < 0)
@@ -1395,10 +1384,6 @@ static int __init ohci_hcd_mod_init(void)
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
  error_ep93xx:
 #endif
-#ifdef EXYNOS_PLATFORM_DRIVER
-	platform_driver_unregister(&EXYNOS_PLATFORM_DRIVER);
- error_exynos:
-#endif
 #ifdef S3C2410_PLATFORM_DRIVER
 	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
  error_s3c2410:
@@ -1463,9 +1448,6 @@ static void __exit ohci_hcd_mod_exit(void)
 #ifdef EP93XX_PLATFORM_DRIVER
 	platform_driver_unregister(&EP93XX_PLATFORM_DRIVER);
 #endif
-#ifdef EXYNOS_PLATFORM_DRIVER
-	platform_driver_unregister(&EXYNOS_PLATFORM_DRIVER);
-#endif
 #ifdef S3C2410_PLATFORM_DRIVER
 	platform_driver_unregister(&S3C2410_PLATFORM_DRIVER);
 #endif
-- 
1.7.9.5



From balbi at ti.com  Wed Jul 31 02:15:38 2013
From: balbi at ti.com (Felipe Balbi)
Date: Wed, 31 Jul 2013 09:15:38 +0300
Subject: [PATCH 01/15] drivers: phy: add generic PHY framework
In-Reply-To: <51F8A440.8010803@ti.com>
References: <20130720220006.GA7977@kroah.com> <3839600.WiC1OLF35o@flatron>
 <51EBC0F5.70601@ti.com> <9748041.Qq1fWJBg6D@flatron>
 <20130721154653.GG16598@kroah.com>
 <20130730071106.GC16441@radagast> <51F8A440.8010803@ti.com>
Message-ID: <20130731061538.GC13289@radagast>

Hi,

On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
> >>>>> IMHO we need a lookup method for PHYs, just like for clocks,
> >>>>> regulators, PWMs or even i2c busses because there are complex cases
> >>>>> when passing just a name using platform data will not work. I would
> >>>>> second what Stephen said [1] and define a structure doing things in a
> >>>>> DT-like way.
> >>>>>
> >>>>> Example;
> >>>>>
> >>>>> [platform code]
> >>>>>
> >>>>> static const struct phy_lookup my_phy_lookup[] = {
> >>>>>
> >>>>> 	PHY_LOOKUP("s3c-hsotg.0", "otg", "samsung-usbphy.1", "phy.2"),
> >>>>
> >>>> The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
> >>>> creating the device, the ids in the device name would change and
> >>>> PHY_LOOKUP wont be useful.
> >>>
> >>> I don't think this is a problem. All the existing lookup methods already 
> >>> use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You 
> >>> can simply add a requirement that the ID must be assigned manually, 
> >>> without using PLATFORM_DEVID_AUTO to use PHY lookup.
> >>
> >> And I'm saying that this idea, of using a specific name and id, is
> >> frought with fragility and will break in the future in various ways when
> >> devices get added to systems, making these strings constantly have to be
> >> kept up to date with different board configurations.
> >>
> >> People, NEVER, hardcode something like an id.  The fact that this
> >> happens today with the clock code, doesn't make it right, it makes the
> >> clock code wrong.  Others have already said that this is wrong there as
> >> well, as systems change and dynamic ids get used more and more.
> >>
> >> Let's not repeat the same mistakes of the past just because we refuse to
> >> learn from them...
> >>
> >> So again, the "find a phy by a string" functions should be removed, the
> >> device id should be automatically created by the phy core just to make
> >> things unique in sysfs, and no driver code should _ever_ be reliant on
> >> the number that is being created, and the pointer to the phy structure
> >> should be used everywhere instead.
> >>
> >> With those types of changes, I will consider merging this subsystem, but
> >> without them, sorry, I will not.
> > 
> > I'll agree with Greg here, the very fact that we see people trying to
> > add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points to a
> > big problem in the framework.
> > 
> > The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
> > adding similar infrastructure to the driver themselves to make sure we
> > don't end up with duplicate names in sysfs in case we have multiple
> > instances of the same IP in the SoC (or several of the same PCIe card).
> > I really don't want to go back to that.
> 
> If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can give the
> correct binding information to the PHY framework. I think we can drop having
> this non-dt support in PHY framework? I see only one platform (OMAP3) going to
> be needing this non-dt support and we can use the USB PHY library for it.

you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)

-- 
balbi
-------------- 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/20130731/1e807bf5/attachment-0001.sig>

From horms+renesas at verge.net.au  Wed Jul 31 02:16:01 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 31 Jul 2013 15:16:01 +0900
Subject: [PATCH v3] ARM: shmobile: Add lager defconfig
Message-ID: <1375251361-29320-1-git-send-email-horms+renesas@verge.net.au>

This is intended to be used until multi-arch is able to be
used for the lager board at which time a more generic configuration
will be used in place of this one.

Acked-by: Magnus Damm <magnus.damm at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

v3
* Disable CONFIG_SMP: The code does not currently support SMP
* Enable CONFIG_RCAR_THERMAL

v2
* Place defconfig in correct directory
* Bump SERIAL_SH_SCI_NR_UARTS up to 10 to reflect the
  number of devices present
---
 arch/arm/configs/lager_defconfig | 119 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 arch/arm/configs/lager_defconfig

diff --git a/arch/arm/configs/lager_defconfig b/arch/arm/configs/lager_defconfig
new file mode 100644
index 0000000..ce3f711
--- /dev/null
+++ b/arch/arm/configs/lager_defconfig
@@ -0,0 +1,119 @@
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
+CONFIG_SLAB=y
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_SHMOBILE=y
+CONFIG_ARCH_R8A7790=y
+CONFIG_MACH_LAGER=y
+# CONFIG_SH_TIMER_TMU is not set
+# CONFIG_EM_TIMER_STI is not set
+CONFIG_ARM_ERRATA_430973=y
+CONFIG_ARM_ERRATA_458693=y
+CONFIG_ARM_ERRATA_460075=y
+CONFIG_ARM_ERRATA_743622=y
+CONFIG_ARM_ERRATA_754322=y
+CONFIG_AEABI=y
+# CONFIG_OABI_COMPAT is not set
+CONFIG_FORCE_MAX_ZONEORDER=13
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_KEXEC=y
+CONFIG_AUTO_ZRELADDR=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_PM_RUNTIME=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_NETDEVICES=y
+# CONFIG_NET_CORE is not set
+# CONFIG_NET_VENDOR_ARC is not set
+# CONFIG_NET_CADENCE is not set
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+CONFIG_SH_ETH=y
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
+CONFIG_INPUT_EVDEV=y
+# CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_GPIO=y
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_SH_SCI=y
+CONFIG_SERIAL_SH_SCI_NR_UARTS=10
+CONFIG_SERIAL_SH_SCI_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+CONFIG_I2C_GPIO=y
+CONFIG_I2C_SH_MOBILE=y
+CONFIG_GPIO_SH_PFC=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_RCAR=y
+# CONFIG_HWMON is not set
+CONFIG_THERMAL=y
+CONFIG_RCAR_THERMAL=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_SDHI=y
+CONFIG_MMC_SH_MMCIF=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_RTC_CLASS=y
+CONFIG_DMADEVICES=y
+CONFIG_SH_DMAE=y
+# CONFIG_IOMMU_SUPPORT is not set
+# CONFIG_DNOTIFY is not set
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_CONFIGFS_FS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_NFS_V4_1=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+# CONFIG_ARM_UNWIND is not set
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+# CONFIG_CRYPTO_HW is not set
-- 
1.8.3.2



From horms+renesas at verge.net.au  Wed Jul 31 02:25:40 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 31 Jul 2013 15:25:40 +0900
Subject: [PATCH] clocksource: em_sti: Adjust clock event rating to fix SMP
 broadcast
Message-ID: <1375251940-7809-1-git-send-email-horms+renesas@verge.net.au>

From: Magnus Damm <damm at opensource.se>

Update the STI rating from 200 to 80 to fix SMP operation with
the ARM broadcast timer. This breakage was introduced by:

f7db706 ARM: 7674/1: smp: Avoid dummy clockevent being preferred over real hardware clock-event

Without this fix SMP operation is broken on EMEV2 since no
broadcast timer interrupts trigger on the secondary CPU cores.

Signed-off-by: Magnus Damm <damm at opensource.se>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 drivers/clocksource/em_sti.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/em_sti.c b/drivers/clocksource/em_sti.c
index b9c81b7..37b87c0 100644
--- a/drivers/clocksource/em_sti.c
+++ b/drivers/clocksource/em_sti.c
@@ -300,7 +300,7 @@ static void em_sti_register_clockevent(struct em_sti_priv *p)
 	memset(ced, 0, sizeof(*ced));
 	ced->name = dev_name(&p->pdev->dev);
 	ced->features = CLOCK_EVT_FEAT_ONESHOT;
-	ced->rating = 200;
+	ced->rating = 80;
 	ced->cpumask = cpumask_of(0);
 	ced->set_next_event = em_sti_clock_event_next;
 	ced->set_mode = em_sti_clock_event_mode;
-- 
1.8.3.2



From horms+renesas at verge.net.au  Wed Jul 31 02:29:25 2013
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 31 Jul 2013 15:29:25 +0900
Subject: [PATCH v4] ARM: shmobile: Add lager defconfig
Message-ID: <1375252165-9019-1-git-send-email-horms+renesas@verge.net.au>

This is intended to be used until multi-arch is able to be
used for the lager board at which time a more generic configuration
will be used in place of this one.

Acked-by: Magnus Damm <magnus.damm at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---

v4
* Enable CONFIG_HAVE_ARM_ARCH_TIMER

v3
* Disable CONFIG_SMP: The code does not currently support SMP
* Enable CONFIG_RCAR_THERMAL

v2
* Place defconfig in correct directory
* Bump SERIAL_SH_SCI_NR_UARTS up to 10 to reflect the
  number of devices present
---
 arch/arm/configs/lager_defconfig | 120 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 120 insertions(+)
 create mode 100644 arch/arm/configs/lager_defconfig

diff --git a/arch/arm/configs/lager_defconfig b/arch/arm/configs/lager_defconfig
new file mode 100644
index 0000000..e777ef2
--- /dev/null
+++ b/arch/arm/configs/lager_defconfig
@@ -0,0 +1,120 @@
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
+CONFIG_SLAB=y
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_SHMOBILE=y
+CONFIG_ARCH_R8A7790=y
+CONFIG_MACH_LAGER=y
+# CONFIG_SH_TIMER_TMU is not set
+# CONFIG_EM_TIMER_STI is not set
+CONFIG_ARM_ERRATA_430973=y
+CONFIG_ARM_ERRATA_458693=y
+CONFIG_ARM_ERRATA_460075=y
+CONFIG_ARM_ERRATA_743622=y
+CONFIG_ARM_ERRATA_754322=y
+CONFIG_HAVE_ARM_ARCH_TIMER=y
+CONFIG_AEABI=y
+# CONFIG_OABI_COMPAT is not set
+CONFIG_FORCE_MAX_ZONEORDER=13
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_KEXEC=y
+CONFIG_AUTO_ZRELADDR=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_PM_RUNTIME=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_NETDEVICES=y
+# CONFIG_NET_CORE is not set
+# CONFIG_NET_VENDOR_ARC is not set
+# CONFIG_NET_CADENCE is not set
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+CONFIG_SH_ETH=y
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
+CONFIG_INPUT_EVDEV=y
+# CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_GPIO=y
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_SH_SCI=y
+CONFIG_SERIAL_SH_SCI_NR_UARTS=10
+CONFIG_SERIAL_SH_SCI_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+CONFIG_I2C_GPIO=y
+CONFIG_I2C_SH_MOBILE=y
+CONFIG_GPIO_SH_PFC=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_RCAR=y
+# CONFIG_HWMON is not set
+CONFIG_THERMAL=y
+CONFIG_RCAR_THERMAL=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_SDHI=y
+CONFIG_MMC_SH_MMCIF=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_RTC_CLASS=y
+CONFIG_DMADEVICES=y
+CONFIG_SH_DMAE=y
+# CONFIG_IOMMU_SUPPORT is not set
+# CONFIG_DNOTIFY is not set
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_CONFIGFS_FS=y
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_NFS_V4_1=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+# CONFIG_ARM_UNWIND is not set
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+# CONFIG_CRYPTO_HW is not set
-- 
1.8.3.2



From tony at atomide.com  Wed Jul 31 02:35:13 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 30 Jul 2013 23:35:13 -0700
Subject: [PATCHv4 29/33] CLK: omap: add omap3 clock init file
In-Reply-To: <51F81FD7.2060707@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-30-git-send-email-t-kristo@ti.com>
 <51F81FD7.2060707@ti.com>
Message-ID: <20130731063512.GP7656@atomide.com>

* Nishanth Menon <nm at ti.com> [130730 13:26]:
> On 07/23/2013 02:20 AM, Tero Kristo wrote:
> >clk-3xxx.c now contains the clock init functionality for omap3, including
> >DT clock registration and adding of static clkdev entries.
> >
> >This patch also splits the OMAP3 clock registration code under mach-omap2
> >to use OMAP3 subtype specific clk init functions.
> >
> >Signed-off-by: Tero Kristo <t-kristo at ti.com>
> >---
> >  arch/arm/mach-omap2/Makefile          |    2 +-
> >  arch/arm/mach-omap2/cclock3xxx_data.c | 3641 ---------------------------------
> 
> Tony and a lot of people is not going to like removing support for
> non-dt boot for OMAP3 before "it's time is due" ;)

I think the only showstopper for that is that we need the
pending pinctrl changes merged first to keep off-idle working.
So the omap3 legacy code removal probably needs to wait until
v3.13 merge window. For omap4 and am33xx we can do it now.

Regards,

Tony


From lars at metafoo.de  Wed Jul 31 02:35:49 2013
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Wed, 31 Jul 2013 08:35:49 +0200
Subject: New dapm panic on beaver with next-20130730
In-Reply-To: <CAOesGMjqyF7zPoGsW6oBRFey7Bc_umnoGob7oQ=_c3n7oevuaQ@mail.gmail.com>
References: <CAOesGMig6jry1GJLoTnOqxom1KjtBTUtZz-_-SiZLpGTc3VkqA@mail.gmail.com>
 <51F8A933.4080708@metafoo.de>
 <CAOesGMjqyF7zPoGsW6oBRFey7Bc_umnoGob7oQ=_c3n7oevuaQ@mail.gmail.com>
Message-ID: <51F8B045.8030303@metafoo.de>

On 07/31/2013 08:13 AM, Olof Johansson wrote:
> On Tue, Jul 30, 2013 at 11:05 PM, Lars-Peter Clausen <lars at metafoo.de> wrote:
>> On 07/31/2013 07:36 AM, Olof Johansson wrote:
>>>
>>> Hi Mark, Lars-Peter,
>>>
>>> I noticed the below panic on beaver (Tegra30). Seems like seaboard
>>> (Tegra20) is fine. This is with next-20130730, tegra_defconfig.
>>
>>
>> Hi,
>>
>> So the same machine driver with the same codec works on tegra2, but not on
>> tegra3? The crash doesn't seem to be directly related to the patch, but the
>> patch changed the memory layout. Is it possible that you still have a
>> outdated module that's being loaded on your tegra3 board?
>
> Sorry, I should have been cleared on that. Not at all the same codec,
> seaboard uses wm8903, beaver rt5640.
>
>> Can you add a few debugging printks and run the test again and paste the
>> last few lines before the crash:
>
> [beaver          00:18] [    4.045897] dapm_generic_check_power: IF2 ADC L
> [beaver          00:18] [    4.050417] dapm_clear_walk_output 1: ee3a7bc0
> [beaver          00:18] [    4.054845] dapm_generic_check_power: IF2 DAC
> [beaver          00:18] [    4.059193] dapm_clear_walk_output 1: ee3a8240
> [beaver          00:18] [    4.063621] dapm_clear_walk_output 1: ee3a8280
> [beaver          00:18] [    4.068048] dapm_generic_check_power: IF1 ADC R
> [beaver          00:18] [    4.072661] dapm_clear_walk_output 1: ee3a7c40
> [beaver          00:18] [    4.077091] dapm_generic_check_power: IF1 ADC L
> [beaver          00:18] [    4.081616] dapm_clear_walk_output 1: ee3a7c80
> [beaver          00:18] [    4.086045] dapm_generic_check_power: IF1 DAC
> [beaver          00:18] [    4.090394] dapm_clear_walk_output 1: ee3a82c0
> [beaver          00:18] [    4.094821] dapm_clear_walk_output 1: ee3a8300
> [beaver          00:18] [    4.099256] dapm_generic_check_power: INR Mux
> [beaver          00:18] [    4.103599] dapm_clear_walk_output 1: ee3af670
> [beaver          00:18] [    4.108026] dapm_generic_check_power: INL Mux
> [beaver          00:18] [    4.112375] dapm_clear_walk_output 1: ee3af5f0
> [beaver          00:18] [    4.116802] dapm_clear_walk_output 2: 6b6b6b6b

0x6b6b6b6b is poisoned freed memory. According to the source neither the INR 
Mux nor the INL Mux widget should have any sinks. Can you add a couple more 
printks:

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index b779d36..1a82e75 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -774,8 +774,13 @@
  	struct snd_soc_dapm_path *p;

  	list_for_each_entry(p, sink, list_source) {
+		printk("dapm_clear_walk_output 1: %p\n", p);
  		if (p->walked) {
  			p->walked = 0;
+			printk("dapm_clear_walk_output 1: %p\n", p->source);
+			printk("dapm_clear_walk_output 2: %p\n", p->sink);
+			printk("dapm_clear_walk_output 3: %s\n",
+				p->sink->name);
  			dapm_clear_walk_output(dapm, &p->sink->sinks);
  		}
  	}
@@ -1189,6 +1194,8 @@
  	DAPM_UPDATE_STAT(w, power_checks);

+	printk("dapm_generic_check_power: %p %s\n", w, w->name);
+
  	in = is_connected_input_ep(w, NULL);
  	dapm_clear_walk_input(w->dapm, &w->sources);
  	out = is_connected_output_ep(w, NULL);



From tony at atomide.com  Wed Jul 31 02:42:01 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 30 Jul 2013 23:42:01 -0700
Subject: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for
 DRA7xx based SoCs'
In-Reply-To: <51F8A87A.9080002@ti.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-2-git-send-email-rnayak@ti.com>
 <20130730131009.GA28162@radagast> <51F7CB2F.6070705@ti.com>
 <20130730142353.GL28162@radagast> <51F7CF6F.6050702@ti.com>
 <20130730153138.GA5978@radagast> <51F807EF.6020809@ti.com>
 <51F80939.7060403@ti.com> <51F8A87A.9080002@ti.com>
Message-ID: <20130731064201.GQ7656@atomide.com>

* Rajendra Nayak <rnayak at ti.com> [130730 23:09]:
> 
> Tony, what do you suggest we do for this series? Since we have just an es1.0 and one board
> at this point for dra7xx, things would be fine even if we do a dt based parsing to identify
> the device, and I am fine with it if thats what we feel is the right way forward.
> For the rest of the DT only platforms (omap4/5/am335x) anyway getting rid of these rev checks
> from the kernel and depending on DT parsing needs to be a separate series anyway and I dont
> plan to address those as part of this series.

Well I'd say there's no need to drop the hardware revision checks
at this point at least for existing hardware. That's a very minimal
piece of code and there are way bigger issues to tackle.

For new SoCs, we could do it based on the compatible flag. If it
helps booting newer hardware with older kernels, then that's a good
reason to do it.

Regards,

Tony


From tony at atomide.com  Wed Jul 31 02:46:34 2013
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 30 Jul 2013 23:46:34 -0700
Subject: [PATCH] ARM: allow DEBUG_UNCOMPRESS for omap2plus
In-Reply-To: <51F845C7.8020106@wwwdotorg.org>
References: <1375224558-8170-1-git-send-email-swarren@wwwdotorg.org>
 <20130730225233.GF21614@n2100.arm.linux.org.uk>
 <51F845C7.8020106@wwwdotorg.org>
Message-ID: <20130731064634.GR7656@atomide.com>

* Stephen Warren <swarren at wwwdotorg.org> [130730 16:08]:
> On 07/30/2013 04:52 PM, Russell King - ARM Linux wrote:
> > On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote:
> >> From: Stephen Warren <swarren at nvidia.com>
> >>
> >> DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to
> >> omap2plus.S's use of .data, which is not allowed in the decompressor.
> >> Solve this by placing that data into .text when building the file into
> >> the decompressor. This relies on .text actually being writable in the
> >> decompressor, which it is in practice.
> > 
> > Unless you decide to use ZBOOT and flash the zImage.
> 
> I knew there had to be a catch:-)
> 
> I have no idea if ZBOOT is a use-case that's relevant to OMAP?
> 
> On Tegra at least (the same issue applies to the other patch I just
> sent), that use-case is almost impossible; even if the boot ROM directly
> booted a kernel, the boot ROM is hard-coded to copy whatever it's
> booting to SDRAM first, although I suppose if that was a boot-loader it
> could just jump back to a ROM location. That said, NOR flash is
> extremely rare on Tegra. So, I don't know if we care about this issue.
> 
> Is it reasonable to just say "If you use ZBOOT, don't enable
> DEBUG_UNCOMPRESS"? Perhaps these patches should not completely remove
> the !DEBUG_TEGRA_UART from config DEBUG_UNCOMPRESS, but instead say:
> 
> default y if DEBUG_LL && (!DEBUG_TEGRA_UART || !ZBOOT)?

I think we're best off removing the remaining uncompress code
configured port detection features as the port properties are now
defined in kconfig anyways. That simplifies the code quite a bit.

Regards,

Tony


From rnayak at ti.com  Wed Jul 31 02:49:22 2013
From: rnayak at ti.com (Rajendra Nayak)
Date: Wed, 31 Jul 2013 12:19:22 +0530
Subject: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx
 based SoCs'
In-Reply-To: <20130731064201.GQ7656@atomide.com>
References: <1375183546-12758-1-git-send-email-rnayak@ti.com>
 <1375183546-12758-2-git-send-email-rnayak@ti.com>
 <20130730131009.GA28162@radagast> <51F7CB2F.6070705@ti.com>
 <20130730142353.GL28162@radagast> <51F7CF6F.6050702@ti.com>
 <20130730153138.GA5978@radagast> <51F807EF.6020809@ti.com>
 <51F80939.7060403@ti.com> <51F8A87A.9080002@ti.com>
 <20130731064201.GQ7656@atomide.com>
Message-ID: <51F8B372.2000309@ti.com>

On Wednesday 31 July 2013 12:12 PM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak at ti.com> [130730 23:09]:
>>
>> Tony, what do you suggest we do for this series? Since we have just an es1.0 and one board
>> at this point for dra7xx, things would be fine even if we do a dt based parsing to identify
>> the device, and I am fine with it if thats what we feel is the right way forward.
>> For the rest of the DT only platforms (omap4/5/am335x) anyway getting rid of these rev checks
>> from the kernel and depending on DT parsing needs to be a separate series anyway and I dont
>> plan to address those as part of this series.
> 
> Well I'd say there's no need to drop the hardware revision checks
> at this point at least for existing hardware. That's a very minimal
> piece of code and there are way bigger issues to tackle.

right, makes sense.

> 
> For new SoCs, we could do it based on the compatible flag. If it
> helps booting newer hardware with older kernels, then that's a good
> reason to do it.

Sure, we can have dra7xx use the compatible flag and not add all the rev checks.
That said, I would be glad if the latest kernels at least boot on newer hardware
let alone older kernels :) But I guess we have bigger issues to tackle before
even that happens. Thanks for the quick response.

regards,
Rajendra

> 
> Regards,
> 
> Tony
> 



From tony at atomide.com  Wed Jul 31 03:01:09 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 31 Jul 2013 00:01:09 -0700
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4OwY3xh3UGjTxb4ypkcmrTpVYO-FZovq-ierabYMf4CDQA@mail.gmail.com>
References: <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <51F7F914.6040709@wwwdotorg.org>
 <CAKON4Oy6hL9LzHdfq4vWcurbw6TU3HCK_jq14xwweA8dvOGtdw@mail.gmail.com>
 <51F7FCA6.6010909@wwwdotorg.org>
 <CAKON4OzLgC-ahDhLnbYEYrSj7dbFRU0z7Do_D32XNqux2UhvXw@mail.gmail.com>
 <CAKON4OyMfNUR=NGn+OEvN3utcEzRfG6A4rPO6+h5Q4mq_tmoxw@mail.gmail.com>
 <51F80526.1020201@wwwdotorg.org>
 <CAKON4OwY3xh3UGjTxb4ypkcmrTpVYO-FZovq-ierabYMf4CDQA@mail.gmail.com>
Message-ID: <20130731070108.GS7656@atomide.com>

* jonsmirl at gmail.com <jonsmirl at gmail.com> [130730 11:36]:
> On Tue, Jul 30, 2013 at 2:25 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> > On 07/30/2013 12:04 PM, jonsmirl at gmail.com wrote:
> > ...
> >> So what does an alternating use of strings do?
> >>
> >>  dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
> >
> > cat > temp.dts << ENDOFHERE
> > /dts-v1/;
> >
> > / {
> >     dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
> >
> >     pdma0: dma { };
> > };
> > ENDOFHERE
> >
> > dtc -O dtb -o temp.dtb -I dts temp.dts
> >
> > hexdump -C temp.dtb
> >
> > yields:
> >
> >> 00000000  d0 0d fe ed 00 00 00 ab  00 00 00 38 00 00 00 98  |...........8....|
> >> 00000010  00 00 00 28 00 00 00 11  00 00 00 10 00 00 00 00  |...(............|
> >> 00000020  00 00 00 13 00 00 00 60  00 00 00 00 00 00 00 00  |.......`........|
> >> 00000030  00 00 00 00 00 00 00 00  00 00 00 01 00 00 00 00  |................|
> >> 00000040  00 00 00 03 00 00 00 16  00 00 00 00 74 78 00 00  |............tx..|
> >                                                  ss ss ss pp
> >> 00000050  00 00 01 00 00 00 07 72  78 00 00 00 00 01 00 00  |.......rx.......|
> >             pp pp pp ii ii ii ii ss  ss ss pp pp pp pp ii ii
> >> 00000060  00 06 00 00 00 00 00 01  64 6d 61 00 00 00 00 03  |........dma.....|
> >             ii ii
> >
> > ... where ss represents a string byte, pp a phandle byte, ii an integer
> > byte.
> >
> >> 00000070  00 00 00 04 00 00 00 05  00 00 00 01 00 00 00 03  |................|
> >> 00000080  00 00 00 04 00 00 00 0b  00 00 00 01 00 00 00 02  |................|
> >> 00000090  00 00 00 02 00 00 00 09  64 6d 61 73 00 6c 69 6e  |........dmas.lin|
> >> 000000a0  75 78 2c 70 68 61 6e 64  6c 65 00                 |ux,phandle.|
> >
> > Starting about half way through that last line is the string table.
> >
> > (the string table indirection is for property names, not property
> > values, and it looks like not for node names either)
> 
> Ok, so this won't work without introducing variable length data. Too
> bad, I would have liked to eliminate the paired attributes.

Yup that's my experience too. But then again, using string values
in .dts should not be done in general as it bloats things and makes
the parsing slow.

These kind of names for something is usually something that should
be implemented as user space debug tools, and the kernel really does
not need to know names for something coming from DT.

Of course without using string names there's the issue how to know
what is rx dma and what is tx dma in the binding :) Probably what
we've done with interrupt numbers is the way to go with DT to avoid
string names.

Regards,

Tony


From magnus.damm at gmail.com  Wed Jul 31 03:07:02 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 31 Jul 2013 16:07:02 +0900
Subject: [PATCH 00/07] ARM: shmobile: sh73a0, r8a7779 and emev2 SMP SCU rework
Message-ID: <20130731070702.14444.64961.sendpatchset@w520>

ARM: shmobile: sh73a0, r8a7779 and emev2 SMP SCU rework

[PATCH 01/07] ARM: shmobile: Introduce shared SCU SMP boot code
[PATCH 02/07] ARM: shmobile: Use shared SCU SMP boot code on sh73a0
[PATCH 03/07] ARM: shmobile: Use shared SCU SMP boot code on r8a7779
[PATCH 04/07] ARM: shmobile: Use shared SCU SMP boot code on emev2
[PATCH 05/07] ARM: shmobile: Add shared SCU CPU Hotplug code
[PATCH 06/07] ARM: shmobile: Use shared SCU CPU Hotplug code on sh73a0
[PATCH 07/07] ARM: shmobile: Use shared SCU CPU Hotplug code on r8a7779

This series consolidates mach-shmobile SMP code into SCU specific code
for SMP boot and CPU Hotplug. The shared SCU code will in the future hook
into some low level assembly code that provides SMP boot and sleep
functionality, so this is is also preparations for future work.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Written against renesas.git renesas-devel-20130731
 
 Requires "[PATCH] ARM: Fix memblock_reserve() to include stext" during
 run time to allow test of CPU Hotplug with v3.11-rc kernels.

 arch/arm/mach-shmobile/Makefile              |    6 +-
 arch/arm/mach-shmobile/include/mach/common.h |    5 +
 arch/arm/mach-shmobile/platsmp-scu.c         |   76 ++++++++++++++++++++++++++
 arch/arm/mach-shmobile/smp-emev2.c           |   19 +++---
 arch/arm/mach-shmobile/smp-r8a7779.c         |   64 +++++----------------
 arch/arm/mach-shmobile/smp-sh73a0.c          |   67 +++++-----------------
 6 files changed, 126 insertions(+), 111 deletions(-)


From magnus.damm at gmail.com  Wed Jul 31 03:07:12 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 31 Jul 2013 16:07:12 +0900
Subject: [PATCH 01/07] ARM: shmobile: Introduce shared SCU SMP boot code
In-Reply-To: <20130731070702.14444.64961.sendpatchset@w520>
References: <20130731070702.14444.64961.sendpatchset@w520>
Message-ID: <20130731070712.14444.49956.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Add SMP boot functions for SCU equipped mach-shmobile SoCs.

At this point shmobile_smp_scu_prepare_cpus() controls the SCU and
installs boot fn and arg, while shmobile_smp_scu_boot_secondary()
currently does nothing. In the future the boot function and arg
install code will be reworked, so the empty function is ground
work for that.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/include/mach/common.h |    3 ++
 arch/arm/mach-shmobile/platsmp-scu.c         |   31 ++++++++++++++++++++++++++
 2 files changed, 34 insertions(+)

--- 0001/arch/arm/mach-shmobile/include/mach/common.h
+++ work/arch/arm/mach-shmobile/include/mach/common.h	2013-07-29 16:50:17.000000000 +0900
@@ -11,6 +11,9 @@ extern void shmobile_boot_vector(void);
 extern unsigned long shmobile_boot_fn;
 extern unsigned long shmobile_boot_arg;
 extern void shmobile_boot_scu(void);
+extern void shmobile_smp_scu_prepare_cpus(unsigned int max_cpus);
+extern int shmobile_smp_scu_boot_secondary(unsigned int cpu,
+					   struct task_struct *idle);
 struct clk;
 extern int shmobile_clk_init(void);
 extern void shmobile_handle_irq_intc(struct pt_regs *);
--- /dev/null
+++ work/arch/arm/mach-shmobile/platsmp-scu.c	2013-07-29 21:39:30.000000000 +0900
@@ -0,0 +1,31 @@
+/*
+ * SMP support for SoCs with SCU covered by mach-shmobile
+ *
+ * Copyright (C) 2013  Magnus Damm
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/smp.h>
+#include <asm/smp_plat.h>
+#include <asm/smp_scu.h>
+#include <mach/common.h>
+
+void __init shmobile_smp_scu_prepare_cpus(unsigned int max_cpus)
+{
+	shmobile_boot_fn = virt_to_phys(shmobile_boot_scu);
+	shmobile_boot_arg = (unsigned long)shmobile_scu_base;
+
+	/* enable SCU and cache coherency on booting CPU */
+	scu_enable(shmobile_scu_base);
+	scu_power_mode(shmobile_scu_base, SCU_PM_NORMAL);
+}
+
+int shmobile_smp_scu_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+	/* do nothing for now */
+	return 0;
+}


From magnus.damm at gmail.com  Wed Jul 31 03:07:21 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 31 Jul 2013 16:07:21 +0900
Subject: [PATCH 02/07] ARM: shmobile: Use shared SCU SMP boot code on sh73a0
In-Reply-To: <20130731070702.14444.64961.sendpatchset@w520>
References: <20130731070702.14444.64961.sendpatchset@w520>
Message-ID: <20130731070721.14444.80422.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Use shared SCU code on sh73a0 for SMP boot.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/Makefile     |    2 +-
 arch/arm/mach-shmobile/smp-sh73a0.c |   26 +++++++++++++-------------
 2 files changed, 14 insertions(+), 14 deletions(-)

--- 0001/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-07-29 21:40:18.000000000 +0900
@@ -17,7 +17,7 @@ obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.
 
 # SMP objects
 smp-y				:= platsmp.o headsmp.o
-smp-$(CONFIG_ARCH_SH73A0)	+= smp-sh73a0.o headsmp-scu.o
+smp-$(CONFIG_ARCH_SH73A0)	+= smp-sh73a0.o headsmp-scu.o platsmp-scu.o
 smp-$(CONFIG_ARCH_R8A7779)	+= smp-r8a7779.o headsmp-scu.o
 smp-$(CONFIG_ARCH_EMEV2)	+= smp-emev2.o headsmp-scu.o
 
--- 0002/arch/arm/mach-shmobile/smp-sh73a0.c
+++ work/arch/arm/mach-shmobile/smp-sh73a0.c	2013-07-29 21:41:27.000000000 +0900
@@ -50,30 +50,30 @@ void __init sh73a0_register_twd(void)
 
 static int __cpuinit sh73a0_boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
-	cpu = cpu_logical_map(cpu);
+	unsigned int lcpu = cpu_logical_map(cpu);
+	int ret;
 
-	if (((__raw_readl(PSTR) >> (4 * cpu)) & 3) == 3)
-		__raw_writel(1 << cpu, WUPCR);	/* wake up */
+	ret = shmobile_smp_scu_boot_secondary(cpu, idle);
+	if (ret)
+		return ret;
+
+	if (((__raw_readl(PSTR) >> (4 * lcpu)) & 3) == 3)
+		__raw_writel(1 << lcpu, WUPCR);	/* wake up */
 	else
-		__raw_writel(1 << cpu, SRESCR);	/* reset */
+		__raw_writel(1 << lcpu, SRESCR);	/* reset */
 
 	return 0;
 }
 
 static void __init sh73a0_smp_prepare_cpus(unsigned int max_cpus)
 {
-	/* setup sh73a0 specific SCU base */
-	shmobile_scu_base = IOMEM(SH73A0_SCU_BASE);
-	scu_enable(shmobile_scu_base);
-
-	/* Map the reset vector (in headsmp-scu.S, headsmp.S) */
+	/* Map the reset vector (in headsmp.S) */
 	__raw_writel(0, APARMBAREA);      /* 4k */
 	__raw_writel(__pa(shmobile_boot_vector), SBAR);
-	shmobile_boot_fn = virt_to_phys(shmobile_boot_scu);
-	shmobile_boot_arg = (unsigned long)shmobile_scu_base;
 
-	/* enable cache coherency on booting CPU */
-	scu_power_mode(shmobile_scu_base, SCU_PM_NORMAL);
+	/* setup sh73a0 specific SCU bits */
+	shmobile_scu_base = IOMEM(SH73A0_SCU_BASE);
+	shmobile_smp_scu_prepare_cpus(max_cpus);
 }
 
 #ifdef CONFIG_HOTPLUG_CPU


From magnus.damm at gmail.com  Wed Jul 31 03:07:31 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 31 Jul 2013 16:07:31 +0900
Subject: [PATCH 03/07] ARM: shmobile: Use shared SCU SMP boot code on r8a7779
In-Reply-To: <20130731070702.14444.64961.sendpatchset@w520>
References: <20130731070702.14444.64961.sendpatchset@w520>
Message-ID: <20130731070731.14444.50089.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Use shared SCU code on r8a7779 for SMP boot.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/Makefile      |    2 +-
 arch/arm/mach-shmobile/smp-r8a7779.c |   23 ++++++++++++-----------
 2 files changed, 13 insertions(+), 12 deletions(-)

--- 0003/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-07-31 11:56:16.000000000 +0900
@@ -33,7 +33,7 @@ endif
 # SMP objects
 smp-y				:= platsmp.o headsmp.o
 smp-$(CONFIG_ARCH_SH73A0)	+= smp-sh73a0.o headsmp-scu.o platsmp-scu.o
-smp-$(CONFIG_ARCH_R8A7779)	+= smp-r8a7779.o headsmp-scu.o
+smp-$(CONFIG_ARCH_R8A7779)	+= smp-r8a7779.o headsmp-scu.o platsmp-scu.o
 smp-$(CONFIG_ARCH_EMEV2)	+= smp-emev2.o headsmp-scu.o
 
 # IRQ objects
--- 0001/arch/arm/mach-shmobile/smp-r8a7779.c
+++ work/arch/arm/mach-shmobile/smp-r8a7779.c	2013-07-31 11:55:30.000000000 +0900
@@ -84,33 +84,34 @@ static int r8a7779_platform_cpu_kill(uns
 static int r8a7779_boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
 	struct r8a7779_pm_ch *ch = NULL;
-	int ret = -EIO;
+	unsigned int lcpu = cpu_logical_map(cpu);
+	int ret;
 
-	cpu = cpu_logical_map(cpu);
+	ret = shmobile_smp_scu_boot_secondary(cpu, idle);
+	if (ret)
+		return ret;
 
-	if (cpu < ARRAY_SIZE(r8a7779_ch_cpu))
-		ch = r8a7779_ch_cpu[cpu];
+	if (lcpu < ARRAY_SIZE(r8a7779_ch_cpu))
+		ch = r8a7779_ch_cpu[lcpu];
 
 	if (ch)
 		ret = r8a7779_sysc_power_up(ch);
+	else
+		ret = -EIO;
 
 	return ret;
 }
 
 static void __init r8a7779_smp_prepare_cpus(unsigned int max_cpus)
 {
-
-	/* setup r8a7779 specific SCU base */
-	shmobile_scu_base = IOMEM(R8A7779_SCU_BASE);
-	scu_enable(shmobile_scu_base);
-
 	/* Map the reset vector (in headsmp-scu.S, headsmp.S) */
 	__raw_writel(__pa(shmobile_boot_vector), AVECR);
 	shmobile_boot_fn = virt_to_phys(shmobile_boot_scu);
 	shmobile_boot_arg = (unsigned long)shmobile_scu_base;
 
-	/* enable cache coherency on booting CPU */
-	scu_power_mode(shmobile_scu_base, SCU_PM_NORMAL);
+	/* setup r8a7779 specific SCU bits */
+	shmobile_scu_base = IOMEM(R8A7779_SCU_BASE);
+	shmobile_smp_scu_prepare_cpus(max_cpus);
 
 	r8a7779_pm_init();
 


From magnus.damm at gmail.com  Wed Jul 31 03:07:40 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 31 Jul 2013 16:07:40 +0900
Subject: [PATCH 04/07] ARM: shmobile: Use shared SCU SMP boot code on emev2
In-Reply-To: <20130731070702.14444.64961.sendpatchset@w520>
References: <20130731070702.14444.64961.sendpatchset@w520>
Message-ID: <20130731070740.14444.10398.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Use shared SCU code on emev2 for SMP boot.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/Makefile    |    2 +-
 arch/arm/mach-shmobile/smp-emev2.c |   19 ++++++++++---------
 2 files changed, 11 insertions(+), 10 deletions(-)

--- 0004/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-07-31 11:58:03.000000000 +0900
@@ -34,7 +34,7 @@ endif
 smp-y				:= platsmp.o headsmp.o
 smp-$(CONFIG_ARCH_SH73A0)	+= smp-sh73a0.o headsmp-scu.o platsmp-scu.o
 smp-$(CONFIG_ARCH_R8A7779)	+= smp-r8a7779.o headsmp-scu.o platsmp-scu.o
-smp-$(CONFIG_ARCH_EMEV2)	+= smp-emev2.o headsmp-scu.o
+smp-$(CONFIG_ARCH_EMEV2)	+= smp-emev2.o headsmp-scu.o platsmp-scu.o
 
 # IRQ objects
 obj-$(CONFIG_ARCH_SH7372)	+= entry-intc.o
--- 0001/arch/arm/mach-shmobile/smp-emev2.c
+++ work/arch/arm/mach-shmobile/smp-emev2.c	2013-07-31 11:58:39.000000000 +0900
@@ -34,6 +34,12 @@
 
 static int emev2_boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
+	int ret;
+
+	ret = shmobile_smp_scu_boot_secondary(cpu, idle);
+	if (ret)
+		return ret;
+
 	arch_send_wakeup_ipi_mask(cpumask_of(cpu_logical_map(cpu)));
 	return 0;
 }
@@ -42,21 +48,16 @@ static void __init emev2_smp_prepare_cpu
 {
 	void __iomem *smu;
 
-	/* setup EMEV2 specific SCU base, enable */
-	shmobile_scu_base = ioremap(EMEV2_SCU_BASE, PAGE_SIZE);
-	scu_enable(shmobile_scu_base);
-
-	/* Tell ROM loader about our vector (in headsmp-scu.S, headsmp.S) */
+	/* Tell ROM loader about our vector (in headsmp.S) */
 	smu = ioremap(EMEV2_SMU_BASE, PAGE_SIZE);
 	if (smu) {
 		iowrite32(__pa(shmobile_boot_vector), smu + SMU_GENERAL_REG0);
 		iounmap(smu);
 	}
-	shmobile_boot_fn = virt_to_phys(shmobile_boot_scu);
-	shmobile_boot_arg = (unsigned long)shmobile_scu_base;
 
-	/* enable cache coherency on booting CPU */
-	scu_power_mode(shmobile_scu_base, SCU_PM_NORMAL);
+	/* setup EMEV2 specific SCU bits */
+	shmobile_scu_base = ioremap(EMEV2_SCU_BASE, PAGE_SIZE);
+	shmobile_smp_scu_prepare_cpus(max_cpus);
 }
 
 struct smp_operations emev2_smp_ops __initdata = {


From magnus.damm at gmail.com  Wed Jul 31 03:07:49 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 31 Jul 2013 16:07:49 +0900
Subject: [PATCH 05/07] ARM: shmobile: Add shared SCU CPU Hotplug code
In-Reply-To: <20130731070702.14444.64961.sendpatchset@w520>
References: <20130731070702.14444.64961.sendpatchset@w520>
Message-ID: <20130731070749.14444.18254.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Add CPU Hotplug functions for SCU equipped mach-shmobile SoCs.

The functions shmobile_smp_scu_cpu_die() together with
shmobile_smp_scu_cpu_kill() perform basic shutdown and
allows checking of shutdown status. These are written
to work together with SMP boot code in  headsmp-scu.S.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/include/mach/common.h |    2 +
 arch/arm/mach-shmobile/platsmp-scu.c         |   45 ++++++++++++++++++++++++++
 2 files changed, 47 insertions(+)

--- 0004/arch/arm/mach-shmobile/include/mach/common.h
+++ work/arch/arm/mach-shmobile/include/mach/common.h	2013-07-29 16:59:06.000000000 +0900
@@ -14,6 +14,8 @@ extern void shmobile_boot_scu(void);
 extern void shmobile_smp_scu_prepare_cpus(unsigned int max_cpus);
 extern int shmobile_smp_scu_boot_secondary(unsigned int cpu,
 					   struct task_struct *idle);
+extern void shmobile_smp_scu_cpu_die(unsigned int cpu);
+extern int shmobile_smp_scu_cpu_kill(unsigned int cpu);
 struct clk;
 extern int shmobile_clk_init(void);
 extern void shmobile_handle_irq_intc(struct pt_regs *);
--- 0004/arch/arm/mach-shmobile/platsmp-scu.c
+++ work/arch/arm/mach-shmobile/platsmp-scu.c	2013-07-29 16:58:43.000000000 +0900
@@ -7,9 +7,11 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+#include <linux/delay.h>
 #include <linux/init.h>
 #include <linux/io.h>
 #include <linux/smp.h>
+#include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
 #include <asm/smp_scu.h>
 #include <mach/common.h>
@@ -29,3 +31,46 @@ int shmobile_smp_scu_boot_secondary(unsi
 	arch_send_wakeup_ipi_mask(cpumask_of(cpu_logical_map(cpu)));
 	return 0;
 }
+
+#ifdef CONFIG_HOTPLUG_CPU
+void shmobile_smp_scu_cpu_die(unsigned int cpu)
+{
+	dsb();
+	flush_cache_all();
+
+	/* disable cache coherency */
+	scu_power_mode(shmobile_scu_base, SCU_PM_POWEROFF);
+
+	/* Endless loop until reset */
+	while (1)
+		cpu_do_idle();
+}
+
+static int shmobile_smp_scu_psr_core_disabled(int cpu)
+{
+	unsigned long mask = SCU_PM_POWEROFF << (cpu * 8);
+
+	if ((__raw_readl(shmobile_scu_base + 8) & mask) == mask)
+		return 1;
+
+	return 0;
+}
+
+int shmobile_smp_scu_cpu_kill(unsigned int cpu)
+{
+	int k;
+
+	/* this function is running on another CPU than the offline target,
+	 * here we need wait for shutdown code in platform_cpu_die() to
+	 * finish before asking SoC-specific code to power off the CPU core.
+	 */
+	for (k = 0; k < 1000; k++) {
+		if (shmobile_smp_scu_psr_core_disabled(cpu))
+			return 1;
+
+		mdelay(1);
+	}
+
+	return 0;
+}
+#endif


From magnus.damm at gmail.com  Wed Jul 31 03:07:59 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 31 Jul 2013 16:07:59 +0900
Subject: [PATCH 06/07] ARM: shmobile: Use shared SCU CPU Hotplug code on sh73a0
In-Reply-To: <20130731070702.14444.64961.sendpatchset@w520>
References: <20130731070702.14444.64961.sendpatchset@w520>
Message-ID: <20130731070759.14444.7805.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Update the sh73a0 specific CPU Hotplug code to make use of
the recently introduced shared SCU functions. The sh73a0
power control hardware relies on SCU_PM_POWEROFF with WFI
so the shared SCU code will as-is power down the hardware
as expected.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/smp-sh73a0.c |   41 ++---------------------------------
 1 file changed, 3 insertions(+), 38 deletions(-)

--- 0005/arch/arm/mach-shmobile/smp-sh73a0.c
+++ work/arch/arm/mach-shmobile/smp-sh73a0.c	2013-07-29 21:48:41.000000000 +0900
@@ -20,14 +20,11 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/smp.h>
-#include <linux/spinlock.h>
 #include <linux/io.h>
 #include <linux/delay.h>
 #include <mach/common.h>
-#include <asm/cacheflush.h>
-#include <asm/smp_plat.h>
 #include <mach/sh73a0.h>
-#include <asm/smp_scu.h>
+#include <asm/smp_plat.h>
 #include <asm/smp_twd.h>
 
 #define WUPCR		IOMEM(0xe6151010)
@@ -36,8 +33,6 @@
 #define SBAR		IOMEM(0xe6180020)
 #define APARMBAREA	IOMEM(0xe6f10020)
 
-#define PSTR_SHUTDOWN_MODE	3
-
 #define SH73A0_SCU_BASE 0xf0000000
 
 #ifdef CONFIG_HAVE_ARM_TWD
@@ -77,36 +72,6 @@ static void __init sh73a0_smp_prepare_cp
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
-static int sh73a0_cpu_kill(unsigned int cpu)
-{
-
-	int k;
-	u32 pstr;
-
-	/*
-	 * wait until the power status register confirms the shutdown of the
-	 * offline target
-	 */
-	for (k = 0; k < 1000; k++) {
-		pstr = (__raw_readl(PSTR) >> (4 * cpu)) & 3;
-		if (pstr == PSTR_SHUTDOWN_MODE)
-			return 1;
-
-		mdelay(1);
-	}
-
-	return 0;
-}
-
-static void sh73a0_cpu_die(unsigned int cpu)
-{
-	/* Set power off mode. This takes the CPU out of the MP cluster */
-	scu_power_mode(shmobile_scu_base, SCU_PM_POWEROFF);
-
-	/* Enter shutdown mode */
-	cpu_do_idle();
-}
-
 static int sh73a0_cpu_disable(unsigned int cpu)
 {
 	return 0; /* CPU0 and CPU1 supported */
@@ -117,8 +82,8 @@ struct smp_operations sh73a0_smp_ops __i
 	.smp_prepare_cpus	= sh73a0_smp_prepare_cpus,
 	.smp_boot_secondary	= sh73a0_boot_secondary,
 #ifdef CONFIG_HOTPLUG_CPU
-	.cpu_kill		= sh73a0_cpu_kill,
-	.cpu_die		= sh73a0_cpu_die,
 	.cpu_disable		= sh73a0_cpu_disable,
+	.cpu_die		= shmobile_smp_scu_cpu_die,
+	.cpu_kill		= shmobile_smp_scu_cpu_kill,
 #endif
 };


From magnus.damm at gmail.com  Wed Jul 31 03:08:09 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Wed, 31 Jul 2013 16:08:09 +0900
Subject: [PATCH 07/07] ARM: shmobile: Use shared SCU CPU Hotplug code on
 r8a7779
In-Reply-To: <20130731070702.14444.64961.sendpatchset@w520>
References: <20130731070702.14444.64961.sendpatchset@w520>
Message-ID: <20130731070809.14444.98907.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Update the r8a7779 specific CPU Hotplug code to make use of
the recently introduced shared SCU functions. The r8a7779
power domain hardware requires special power down handling
at ->kill() time.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/smp-r8a7779.c |   41 +++-------------------------------
 1 file changed, 4 insertions(+), 37 deletions(-)

--- 0004/arch/arm/mach-shmobile/smp-r8a7779.c
+++ work/arch/arm/mach-shmobile/smp-r8a7779.c	2013-07-31 12:12:26.000000000 +0900
@@ -122,47 +122,14 @@ static void __init r8a7779_smp_prepare_c
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
-static int r8a7779_scu_psr_core_disabled(int cpu)
-{
-	unsigned long mask = 3 << (cpu * 8);
-
-	if ((__raw_readl(shmobile_scu_base + 8) & mask) == mask)
-		return 1;
-
-	return 0;
-}
-
 static int r8a7779_cpu_kill(unsigned int cpu)
 {
-	int k;
-
-	/* this function is running on another CPU than the offline target,
-	 * here we need wait for shutdown code in platform_cpu_die() to
-	 * finish before asking SoC-specific code to power off the CPU core.
-	 */
-	for (k = 0; k < 1000; k++) {
-		if (r8a7779_scu_psr_core_disabled(cpu))
-			return r8a7779_platform_cpu_kill(cpu);
-
-		mdelay(1);
-	}
+	if (shmobile_smp_scu_cpu_kill(cpu))
+		return r8a7779_platform_cpu_kill(cpu);
 
 	return 0;
 }
 
-static void r8a7779_cpu_die(unsigned int cpu)
-{
-	dsb();
-	flush_cache_all();
-
-	/* disable cache coherency */
-	scu_power_mode(shmobile_scu_base, SCU_PM_POWEROFF);
-
-	/* Endless loop until power off from r8a7779_cpu_kill() */
-	while (1)
-		cpu_do_idle();
-}
-
 static int r8a7779_cpu_disable(unsigned int cpu)
 {
 	/* only CPU1->3 have power domains, do not allow hotplug of CPU0 */
@@ -174,8 +141,8 @@ struct smp_operations r8a7779_smp_ops  _
 	.smp_prepare_cpus	= r8a7779_smp_prepare_cpus,
 	.smp_boot_secondary	= r8a7779_boot_secondary,
 #ifdef CONFIG_HOTPLUG_CPU
-	.cpu_kill		= r8a7779_cpu_kill,
-	.cpu_die		= r8a7779_cpu_die,
 	.cpu_disable		= r8a7779_cpu_disable,
+	.cpu_die		= shmobile_smp_scu_cpu_die,
+	.cpu_kill		= r8a7779_cpu_kill,
 #endif
 };


From sboyd at codeaurora.org  Wed Jul 31 03:16:30 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 00:16:30 -0700
Subject: [PATCH 2/2] Convert PowerPC macro spin_event_timeout() to
 architecture independent macro
In-Reply-To: <1375187900-17582-3-git-send-email-B44344@freescale.com>
References: <1375187900-17582-1-git-send-email-B44344@freescale.com>
 <1375187900-17582-3-git-send-email-B44344@freescale.com>
Message-ID: <20130731071630.GI8868@codeaurora.org>

On 07/30, Arpit Goel wrote:
> This patch ports PowerPC implementation of spin_event_timeout() for generic
> use. Architecture specific implementation can be added to asm/delay.h, which
> will override the generic linux implementation.
> 
> Signed-off-by: Arpit Goel <B44344 at freescale.com>
> ---

We use something similar internally but it's tied specifically to
readl.

>  
> +#ifndef spin_event_timeout
> +/**
> + * spin_event_timeout - spin until a condition gets true or a timeout elapses
> + * @condition: a C expression to evalate
> + * @timeout: timeout, in microseconds
> + * @delay: the number of microseconds to delay between each evaluation of
> + *         @condition
> + *
> + * The process spins until the condition evaluates to true (non-zero) or the
> + * timeout elapses.  The return value of this macro is the value of
> + * @condition when the loop terminates. This allows you to determine the cause
> + * of the loop terminates.  If the return value is zero, then you know a
> + * timeout has occurred.
> + *
> + * This primary purpose of this macro is to poll on a hardware register
> + * until a status bit changes.  The timeout ensures that the loop still
> + * terminates even if the bit never changes.  The delay is for devices that
> + * need a delay in between successive reads.
> + *
> + * gcc will optimize out the if-statement if @delay is a constant.
> + *
> + * This is copied from PowerPC based spin_event_timeout() implementation
> + * and modified for generic usecase.
> + */
> +#define spin_event_timeout(condition, timeout, delay)		\
> +({								\
> +	typeof(condition) __ret;				\
> +	unsigned long __loops = timeout/USECS_PER_JIFFY;	\
> +	unsigned long __start = jiffies;			\
> +	while (!(__ret = (condition)) &&			\
> +		time_before(jiffies, __start + __loops + 1))	\
> +		if (delay)					\
> +			udelay(delay);				\
> +		else						\
> +			schedule();				\
> +	if (!__ret)						\
> +		__ret = (condition);				\
> +	__ret;							\
> +})

What do you do here if jiffies aren't incrementing (i.e
interrupts are disabled). The time_before() check won't work
there and it would be nice if we were able to use this in such
situations. I think powerpc gets around this by reading the
hardware timer directly?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From daniel.lezcano at linaro.org  Wed Jul 31 03:27:25 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 31 Jul 2013 09:27:25 +0200
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <829dbb20-0f14-4a3b-8da9-1f7b1b5b8b59@DB8EHSMHS005.ehs.local>
References: <51E72DCA.9070500@codeaurora.org>
 <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
 <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
 <51F77D93.4030505@linaro.org>
 <829dbb20-0f14-4a3b-8da9-1f7b1b5b8b59@DB8EHSMHS005.ehs.local>
Message-ID: <51F8BC5D.80605@linaro.org>

On 07/31/2013 12:34 AM, S?ren Brinkmann wrote:
> On Tue, Jul 30, 2013 at 10:47:15AM +0200, Daniel Lezcano wrote:
>> On 07/30/2013 02:03 AM, S?ren Brinkmann wrote:
>>> Hi Daniel,
>>>
>>> On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
>>> (snip)
>>>>
>>>> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
>>>> timer will be stopped when entering to the idle state. In this case, the
>>>> cpuidle framework will call clockevents_notify(ENTER) and switches to a
>>>> broadcast timer and will call clockevents_notify(EXIT) when exiting the
>>>> idle state, switching the local timer back in use.
>>>
>>> I've been thinking about this, trying to understand how this makes my
>>> boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
>>> would make the timer core switch to a broadcast device even though it
>>> wouldn't be necessary. But shouldn't it still work? It sounds like we do
>>> something useless, but nothing wrong in a sense that it should result in
>>> breakage. I guess I'm missing something obvious. This timer system will
>>> always remain a mystery to me.
>>>
>>> Actually this more or less leads to the question: What is this
>>> 'broadcast timer'. I guess that is some clockevent device which is
>>> common to all cores? (that would be the cadence_ttc for Zynq). Is the
>>> hang pointing to some issue with that driver?
>>
>> If you look at the /proc/timer_list, which timer is used for broadcasting ?
> 
> So, the correct run results (full output attached).
> 
> The vanilla kernel uses the twd timers as local timers and the TTC as
> broadcast device:
> 	Tick Device: mode:     1                                                         
> 	Broadcast device  
> 	Clock Event Device: ttc_clockevent
> 
> When I remove the offending CPUIDLE flag and add the DT fragment to
> enable the global timer, the twd timers are still used as local timers
> and the broadcast device is the global timer:
> 	Tick Device: mode:     1                                                         
> 	Broadcast device                                                                 
> 	Clock Event Device: arm_global_timer
> 
> Again, since boot hangs in the actually broken case, I don't see way to
> obtain this information for that case.

Hmm, interesting. Can you give the ouput of /proc/interrupts also with
the global timer ?


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From maxime.ripard at free-electrons.com  Wed Jul 31 03:37:24 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 31 Jul 2013 09:37:24 +0200
Subject: [PATCH 4/4] ARM: sun6i: Enable clock support in the DTSI
In-Reply-To: <51F86A2E.10505@elopez.com.ar>
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375195462-19566-5-git-send-email-maxime.ripard@free-electrons.com>
 <51F86A2E.10505@elopez.com.ar>
Message-ID: <20130731073724.GA24439@lukather>

Hi Emilio,

On Tue, Jul 30, 2013 at 10:36:46PM -0300, Emilio L?pez wrote:
> Hi Maxime,
> 
> Overall this looks good to me, but I have some small comments:
> 
> El 30/07/13 11:44, Maxime Ripard escribi?:
> > Now that the clock driver has support for the A31 clocks, we can add
> > them to the DTSI and start using them in the relevant hardware blocks.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > ---
> >  arch/arm/boot/dts/sun6i-a31.dtsi | 137 ++++++++++++++++++++++++++++++++++++---
> >  1 file changed, 127 insertions(+), 10 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
> > index 0d13dc6..c6a3a91 100644
> > --- a/arch/arm/boot/dts/sun6i-a31.dtsi
> > +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> > @@ -51,13 +51,130 @@
> >  
> >  	clocks {
> >  		#address-cells = <1>;
> > -		#size-cells = <0>;
> > +		#size-cells = <1>;
> > +		ranges;
> >  
> > -		osc: oscillator {
> > +		osc24M: hosc {
> 
> Please use osc24M and osc32k instead of hosc and losc, respectively.

The problem is a bit more complex than that.

On the A31, the losc clock is actually a mux between an external
oscillator running at 32kHz, and the internal oscillator running at
667MHz, that would be scaled down.

Support for this mux is not quite there yet, since I've not seen any
documentation for it, but this would allow to just rearrange losc
parents and compatible when we will had such support.

Hence why I chose these names.

> >  			#clock-cells = <0>;
> >  			compatible = "fixed-clock";
> >  			clock-frequency = <24000000>;
> 
> Is osc24M not gatable on A31?

Nope.

> >  		};
> > +
> > +		osc32k: losc {
> > +			#clock-cells = <0>;
> > +			compatible = "fixed-clock";
> > +			clock-frequency = <32768>;
> > +		};
> > +
> > +		pll1: pll1 at 01c20000 {
> > +			#clock-cells = <0>;
> > +			compatible = "allwinner,sun6i-pll1-clk";
> > +			reg = <0x01c20000 0x4>;
> > +			clocks = <&osc24M>;
> > +		};
> > +
> > +		/*
> > +		 * This is a dummy clock, to be used as placeholder on
> > +		 * other mux clocks when a specific parent clock is not
> > +		 * yet implemented. It should be dropped when the driver
> > +		 * is complete.
> > +		 */
> > +		pll6: pll6 {
> > +			#clock-cells = <0>;
> > +			compatible = "fixed-clock";
> > +			clock-frequency = <0>;
> > +		};
> > +
> > +		cpu: cpu at 01c20050 {
> > +			#clock-cells = <0>;
> > +			compatible = "allwinner,sun4i-cpu-clk";
> > +			reg = <0x01c20050 0x4>;
> > +			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
> 
> Listing pll1 twice doesn't sound correct, but vendor code seems to
> indicate so. A comment to clarify it's not a typo would be good I think.

Yes, I suspect an error in the datasheet, but until proven otherwise,
it's that way.

I'll add a comment.

> > +		};
> > +
> > +		axi: axi at 01c20050 {
> > +			#clock-cells = <0>;
> > +			compatible = "allwinner,sun4i-axi-clk";
> > +			reg = <0x01c20050 0x4>;
> > +			clocks = <&cpu>;
> > +		};
> > +
> > +		ahb1_mux: ahb1_mux at 01c20054 {
> > +			#clock-cells = <0>;
> > +			compatible = "allwinner,sun6i-ahb1-mux-clk";
> > +			reg = <0x01c20054 0x4>;
> > +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
> > +		};
> > +
> > +		ahb1: ahb1 at 01c20054 {
> > +			#clock-cells = <0>;
> > +			compatible = "allwinner,sun4i-ahb-clk";
> > +			reg = <0x01c20054 0x4>;
> > +			clocks = <&ahb1_mux>;
> > +		};
> 
> Depending on when this lands, I believe these two above could be merged
> into one with the refactoring introduced on my patchset.

Since your patchset is still in RFC and we had no comments from Mike so
far, while this one looks pretty similar to the one we had before, I
guess the safest thing to do would be to rebase your patches on top of
this ones.

But it's right those clocks (AHB1 and APB2) will benefit from your work
as well :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130731/458dcc5f/attachment-0001.sig>

From tony at atomide.com  Wed Jul 31 03:38:03 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 31 Jul 2013 00:38:03 -0700
Subject: [ATTEND] [ARM ATTEND] kernel data bloat and how to avoid it
Message-ID: <20130731073802.GT7656@atomide.com>

Hi all,

Probably the biggest kernel data bloat issue is in the ARM land, but
it also seems that it's becoming a Linux generic issue too, so I
guess it could be discussed in either context.

The kernel data bloat issue is slightly related to the devicetree talks
as well as I'm seeing a lot of the device tree bindings heading the wrong
way both at the binding level and the device driver level.

Basically the data bloat issue is there for the arch code and drivers
and may not show up initially until things have headed the wrong way for
too long.

After struggling with the data issues in the ARM land over past few
years, I think we have now pretty good idea how to spot the issues
early and avoid building databases into Linux kernel.

So some kind of discussion on data bloat and how to avoid it might be
interesting to a bunch of maintainers?

Regards,

Tony


From b.brezillon at overkiz.com  Wed Jul 31 03:56:11 2013
From: b.brezillon at overkiz.com (boris brezillon)
Date: Wed, 31 Jul 2013 09:56:11 +0200
Subject: [PATCH v2 26/42] USB: ohci-at91: add usb_clk for transition to
 common clk framework
In-Reply-To: <1374076062-20293-1-git-send-email-b.brezillon@overkiz.com>
References: <1374068069-13496-1-git-send-email-b.brezillon@overkiz.com>
 <1374076062-20293-1-git-send-email-b.brezillon@overkiz.com>
Message-ID: <51F8C31B.1020305@overkiz.com>

Hello Alan,

I don't know if you remember but a few days back I sent a series which
included this patch ("ARM: at91: prepare transition to common clk 
framework").

It was decided to move this patch out of the "prepare" series to avoid 
backward
compatility handling.

Things have changed a little bit.

I was asked to split the "ARM: at91: move to common clk framework" 
series into
several smaller series (one for each SoC).
This means at91 will have some SoCs supporting using common clk framework
(and thus will define the usb_clk) and other SoCs using the old at91 clk 
implementation
(which does not define usb_clk).

I was also requested to drop common clk framework support for non dt 
boards, which
means, as long as at91 keep non dt boards the at91 old clk implem will 
remain active.

For all these reasons I will have to reintroduce the backward 
compatibility hack.

Should I get this patch (and patch 27) out of the this series and back 
to the "prepare" series ?

Best Regards,

Boris

On 17/07/2013 17:47, Boris BREZILLON wrote:
> The AT91 PMC (Power Management Controller) provides an USB clock used by
> USB Full Speed host (ohci) and USB Full Speed device (udc).
> The usb drivers (ohci and udc) must configure this clock to 48Mhz.
> This configuration was formely done in mach-at91/clock.c, but this
> implementation will be removed when moving to common clk framework.
>
> This patch add support for usb clock retrieval and configuration.
>
> Signed-off-by: Boris BREZILLON <b.brezillon at overkiz.com>
> ---
>   drivers/usb/host/ohci-at91.c |   16 ++++++++++++++--
>   1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
> index 9677f68..ca1cdd6 100644
> --- a/drivers/usb/host/ohci-at91.c
> +++ b/drivers/usb/host/ohci-at91.c
> @@ -31,8 +31,8 @@
>   #define at91_for_each_port(index)	\
>   		for ((index) = 0; (index) < AT91_MAX_USBH_PORTS; (index)++)
>   
> -/* interface and function clocks; sometimes also an AHB clock */
> -static struct clk *iclk, *fclk, *hclk;
> +/* interface, function and usb clocks; sometimes also an AHB clock */
> +static struct clk *iclk, *fclk, *uclk, *hclk;
>   static int clocked;
>   
>   extern int usb_disabled(void);
> @@ -41,6 +41,8 @@ extern int usb_disabled(void);
>   
>   static void at91_start_clock(void)
>   {
> +	clk_set_rate(uclk, 48000000);
> +	clk_prepare_enable(uclk);
>   	clk_prepare_enable(hclk);
>   	clk_prepare_enable(iclk);
>   	clk_prepare_enable(fclk);
> @@ -52,6 +54,7 @@ static void at91_stop_clock(void)
>   	clk_disable_unprepare(fclk);
>   	clk_disable_unprepare(iclk);
>   	clk_disable_unprepare(hclk);
> +	clk_disable_unprepare(uclk);
>   	clocked = 0;
>   }
>   
> @@ -162,6 +165,12 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
>   		retval = PTR_ERR(hclk);
>   		goto err5;
>   	}
> +	uclk = clk_get(&pdev->dev, "usb_clk");
> +	if (IS_ERR(uclk)) {
> +		dev_err(&pdev->dev, "failed to get usb_clk\n");
> +		retval = PTR_ERR(uclk);
> +		goto err6;
> +	}
>   
>   	at91_start_hc(pdev);
>   	ohci_hcd_init(hcd_to_ohci(hcd));
> @@ -173,6 +182,8 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
>   	/* Error handling */
>   	at91_stop_hc(pdev);
>   
> +	clk_put(uclk);
> + err6:
>   	clk_put(hclk);
>    err5:
>   	clk_put(fclk);
> @@ -212,6 +223,7 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
>   	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
>   	usb_put_hcd(hcd);
>   
> +	clk_put(uclk);
>   	clk_put(hclk);
>   	clk_put(fclk);
>   	clk_put(iclk);



From thomas.petazzoni at free-electrons.com  Wed Jul 31 04:03:59 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 31 Jul 2013 10:03:59 +0200
Subject: pci-mvebu driver on km_kirkwood
In-Reply-To: <51DD88A4.1030506@keymile.com>
References: <51DD88A4.1030506@keymile.com>
Message-ID: <20130731100359.3e789236@skate>

Dear Gerlando Falauto,

On Wed, 10 Jul 2013 18:15:32 +0200, Gerlando Falauto wrote:

> I am trying to use the pci-mvebu driver on one of our km_kirkwood 
> boards. The board is based on Marvell's 98dx4122, which should 
> essentially be 6281 compatible.

In the end, did you manage to get the pci-mvebu driver to work on your
platform?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From tony at atomide.com  Wed Jul 31 04:15:53 2013
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 31 Jul 2013 01:15:53 -0700
Subject: [GIT PULL] ARM: OMAP2+: PRCM: drop macros not currently in use
In-Reply-To: <alpine.DEB.2.02.1307220454470.4804@utopia.booyaka.com>
References: <alpine.DEB.2.02.1307220454470.4804@utopia.booyaka.com>
Message-ID: <20130731081552.GU7656@atomide.com>

* Paul Walmsley <paul at pwsan.com> [130721 22:02]:
> Hi Tony,
> 
> Sorry for the delay on this - wanted to make sure it passed the local
> testbed before sending it upstream.
> 
> The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b:
> 
>   Linux 3.11-rc2 (2013-07-21 12:05:29 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.11-rc/omap-fixes-a
> 
> for you to fetch changes up to 11dab344053f726fe17ede95aa52c1eea1258a66:
> 
>   ARM: OMAP5: PRM/CM: Cleanup unused header (2013-07-21 22:10:25 -0600)
> 
> ----------------------------------------------------------------
> This series removes the currently-unused PRCM macros from
> arch/arm/mach-omap2.

Thanks & sorry for the delay on my part too, I was offline last week.
I'll pull these into omap-for-v3.12/cleanup.

Regards,

Tony


From gerlando.falauto at keymile.com  Wed Jul 31 04:26:44 2013
From: gerlando.falauto at keymile.com (Gerlando Falauto)
Date: Wed, 31 Jul 2013 10:26:44 +0200
Subject: pci-mvebu driver on km_kirkwood
In-Reply-To: <20130731100359.3e789236@skate>
References: <51DD88A4.1030506@keymile.com> <20130731100359.3e789236@skate>
Message-ID: <51F8CA44.4080802@keymile.com>

Hi Thomas,

On 07/31/2013 10:03 AM, Thomas Petazzoni wrote:
> Dear Gerlando Falauto,
>
> On Wed, 10 Jul 2013 18:15:32 +0200, Gerlando Falauto wrote:
>
>> I am trying to use the pci-mvebu driver on one of our km_kirkwood
>> boards. The board is based on Marvell's 98dx4122, which should
>> essentially be 6281 compatible.
>
> In the end, did you manage to get the pci-mvebu driver to work on your
> platform?

Yes, I did -- though I didn't go much beyond simple device probing (i.e. 
no real, intense usage of devices). AND I'm not using the DT-based mbus 
driver (i.e. addresses are still hardcoded within the source code).

Actually, the main reason for trying to use this driver was because I 
wanted to model a PCIe *device* within the device tree, so to expose its 
GPIOs and IRQs to be referenced (through phandles) from other device 
tree nodes. The way I understand it, turns out this is not the way to 
go, as PCI/PCIe are essentially enumerated busses, so you're not 
supposed to -and it's not a trivial task to- put any information about 
real devices within the device tree.
Do you have any suggestion about that?

On the other hand, for our use case I'm afraid there might be some 
hardcoded values within drivers or userspace code, where a certain PCIe 
device is expected to be connected within a given bus number with a 
given device number (bleah!).
If I understand correctly, your driver creates a virtual PCI-to-PCI 
bridge, so our devices would be connected to BUS #1 as opposed to #0 -- 
which might break existing (cr*ee*ppy) code.
But that's not your fault of course.

If you're interested, I can keep you posted as soon as we proceed 
further with this (most likely in September or so).

Next step would be to test Ezequiel's MBus DT binding [PATCH v8], but 
I'm afraid that'll have to wait too, until end of August or so, as I am 
about to leave for vacation.

Thank you!
Gerlando


From javier.martinez at collabora.co.uk  Wed Jul 31 04:35:01 2013
From: javier.martinez at collabora.co.uk (Javier Martinez Canillas)
Date: Wed, 31 Jul 2013 10:35:01 +0200
Subject: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
In-Reply-To: <CACRpkdYjJL6FZwEbB7XLnb9QtjB=3LeE9Ny6KQ4PkM3zpdNqqg@mail.gmail.com>
References: <1375101368-17645-1-git-send-email-linus.walleij@linaro.org>
 <CACxGe6uNJNMdZ1HYGgCtLM2t2TWGCR6btjOHVmP=vDXXvvFfRg@mail.gmail.com>
 <CACRpkdYjJL6FZwEbB7XLnb9QtjB=3LeE9Ny6KQ4PkM3zpdNqqg@mail.gmail.com>
Message-ID: <51F8CC35.1070704@collabora.co.uk>

On 07/31/2013 01:44 AM, Linus Walleij wrote:
> On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely <grant.likely at linaro.org> wrote:
>> On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij <linus.walleij at linaro.org> wrote:
>>> To solve this dilemma, perform an interrupt consistency check
>>> when adding a GPIO chip: if the chip is both gpio-controller and
>>> interrupt-controller, walk all children of the device tree,
>>> check if these in turn reference the interrupt-controller, and
>>> if they do, loop over the interrupts used by that child and
>>> perform gpio_reques() and gpio_direction_input() on these,
>>> making them unreachable from the GPIO side.
>>
>> Ugh, that's pretty awful, and it doesn't actually solve the root
>> problem of the GPIO and IRQ subsystems not cooperating. It's also a
>> very DT-centric solution even though we're going to see the exact same
>> issue on ACPI machines.
> 
> The problem is that the patches for OMAP that I applied
> and now have had to revert solves it in an even uglier way,
> leading to breaking boards, as was noticed.
> 
> The approach in this patch has the potential to actually
> work without regressing a bunch of boards...
>
> Whether this is a problem in ACPI or not remains to be seen,
> but I'm not sure about that. Device trees allows for a GPIO line
> to be used as an interrupt source and GPIO line orthogonally,
> and that is the root of this problem. Does ACPI have the same
> problem, or does it impose natural restrictions on such use
> cases?
>

I agree with Linus here. The problem is that GPIO controllers that can work as
IRQ sources are treated in the kernel as if there where two separate controlers
that are rather orthogonal: an irq_chip and a gpio_chip.
But DT allows to use a GPIO line as an IRQ just by using an omap-gpio phandle as
"interrupt-parent".

So, there should be a place where both irq_chip and gpio_chip has to be related
somehow to properly configure a GPIO (request it and setting it as input) when
used as an IRQ by DT.

My patch for OMAP used an irq_domain_ops .map function handler to configure the
GPIO when a IRQ was mapped since that seemed to me as the best place to do it.
This worked well in OMAP2+ platforms but unfortunately broke OMAP1 platforms
since they are still using legacy domain mapping thus not call .map.

Linus' approach is much better IMHO since it is both generic and will only try
to setup an GPIO when a GPIO bank is added by the DT core. So checking there if
a GPIO line is being used as an IRQ and configuring the GPIO seems like a good
solution to me.

Old platforms like OMAP1 won't break since they don't (and probably never will)
have DT support.

>> We have to solve the problem in a better way than that. Rearranging
>> your patch description, here are some of the points you brought up so
>> I can comment on them...
>>
>>> This has the following undesired effects:
>>>
>>> - The GPIOlib subsystem is not aware that the line is in use
>>>   and willingly lets some other consumer perform gpio_request()
>>>   on it, leading to a complex resource conflict if it occurs.
>>
>> If a gpio line is being both requested as a gpio and used as an
>> interrupt line, then either a) it's a bug, or b) the gpio line needs
>> to be used as input only so it is compatible with irq usage. b) should
>> be supportable.
> 
> Yes this is what I'm saying too I think...
> 
> The bug in (a) manifested itself in the OMAP patch with
> no real solution in sight.
> 
>>> - The GPIO debugfs file claims this GPIO line is "free".
>>
>> Surely we can fix this. I still don't see a problem of having the
>> controller request the gpio when it is claimed as an irq if we can get
>> around the problem of another user performing a /valid/ request on the
>> same GPIO line. The solution may be to have a special form of request
>> or flag that allows it to be shared.
> 
> I don't see how sharing works here, or how another user,
> i.e. another one than the user wanting to recieve the IRQ,
> can validly request such a line? What would the usecase for
> that valid request be?
> 
> Basically I believe these two things need to be exclusive in
> the DT world:
> 
> A: request_irq(a resource passed from "interrupts");
>      -> core implicitly performs gpio_request()
>          gpio_direction_input()
> 
> B: gpio_request(a resource passed from "gpios");
>      gpio_direction_input()
>      request_irq(gpio_to_irq())
> 
> Never both. And IIUC that was what happened in the
> OMAP case.
>

Actually the OMAP case was not related to resource conflict but I'll explain the
issues we had with the OMAP patch in a moment. First I just want to say that I
don't think that makes sense that there are two users of a GPIO. There *could*
be two users for the same IRQ that is mapped to a GPIO but in that case there
will be only one user of the GPIO and that will be the IRQ controller even when
in practice is the same chip and the same driver. If the same GPIO line is used
for two devices in the DT, then gpio_request_one(gpio, GPIOF_IN, NULL) should be
called just once and that state has to be saved somewhere so whoever setups the
GPIO won't do it twice for the same IRQ.

But if a GPIO line is mapped as an IRQ and another user calls gpio_request()
then is correct that he gets an -EBUSY.

There are two issues that have to be solved at least for the OMAP case but they
seems to be general:

1) When a GPIO-IRQ mapping has to be created. e.g: call to irq_create_mapping()
2) When a GPIO-IRQ is setup.e.g: calling irq_set_chip_{data,and_handler,etc}()
3) When a GPIO line has to be requested and configured as input. e.g: call
gpio_request_one(gpio, GPIOF_IN, NULL)

For 1) in the DT case we don't need an explicit call to irq_create_mapping()
since it is called from irq_create_of_mapping() when an IRQ is mapped while
these explicit calls are needed for platforms that still use legacy boot.

The problem is that board files and drivers that has not not been completed
migrated to DT assumes (at least for OMAP) that *every* GPIO line is mapped as
an IRQ and they just do:

gpio_request(gpio,...);
gpio_direction_input()
request[_threaded]_irq(gpio_to_irq(gpio), ...);

My patch-set changed the gpio-omap driver to not map all GPIO lines but only the
ones that were really used as an IRQ and let the DT core to do the mapping from
irq_create_of_mapping(). The first problem reported with the OMAP patch was that
a driver was using the above sequence and that the GPIO had not been mapped.
This user was booting with DT and so this showed a bug in the driver and a DT
that did not conform with the standard schema used in mainline but this shows a
potential issue.

For 2) I moved all the GPIO-IRQ setup logic to the .map function handler since I
(wrongly) thought that .map will be called either when an explicit
irq_create_mapping() call was made and when the OF core handled it via
irq_create_of_mapping(). This was certainly true for OMAP2+ platforms and such
DT and legacy boot worked on my tests.

But it broke OMAP1 platforms since as I said still use legacy booting and thus
don't call the .map function handler. This was the reason why the patches got
reverted and not a resource conflict.

For 3) my patch called the gpio_request_one(gpio, GPIOF_IN, NULL) only if
chip->of_node was defined in the irqchip .map function handler.

But as we saw, this approach was a completely mess and we had to revert three
patches and bother Linus W on his holidays :)

So, I don't really know how to solve this issue and it seems I did more harm
than good when trying to do it. I think that Linus' approach is the least bad
solution but it seems to me that it just solves 3) but no 1) and 2).

>>> - The line direction of the interrupt GPIO line is not
>>>   explicitly set as input, even though it is obvious that such
>>>   a line need to be set up in this way, often making the system
>>>   depend on boot-on defaults for this kind of settings.
>>
>> Should also be solvable if the gpio request problem is solved.
> 
> Agreed...
>

+1

> Yours,
> Linus Walleij
> 

Thanks a lot and best regards,
Javier


From t-kristo at ti.com  Wed Jul 31 04:43:41 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 11:43:41 +0300
Subject: [PATCHv4 01/33] CLK: clkdev: add support for looking up clocks
 from DT
In-Reply-To: <51F7D5FE.7030003@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-2-git-send-email-t-kristo@ti.com> <51F7D5FE.7030003@ti.com>
Message-ID: <51F8CE3D.6040101@ti.com>

On 07/30/2013 06:04 PM, Nishanth Menon wrote:
> On 07/23/2013 02:19 AM, Tero Kristo wrote:
>> clk_get_sys / clk_get can now find clocks from device-tree. If a DT clock
>> is found, an entry is added to the clk_lookup list also for subsequent
>> searches.
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> Cc: Russell King <linux at arm.linux.org.uk>
>> ---
>>   drivers/clk/clkdev.c |   32 ++++++++++++++++++++++++++++++++
>>   1 file changed, 32 insertions(+)
>>
>> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
>> index 442a313..e39f082 100644
>> --- a/drivers/clk/clkdev.c
>> +++ b/drivers/clk/clkdev.c
>> @@ -93,6 +93,18 @@ struct clk *of_clk_get_by_name(struct device_node
>> *np, const char *name)
>>   EXPORT_SYMBOL(of_clk_get_by_name);
>>   #endif
>>
>> +/**
>> + * clkdev_add_nolock - add lookup entry for a clock
>> + * @cl: pointer to new clock lookup entry
>> + *
>> + * Non-locking version, used internally by clk_find() to add DT based
>> + * clock lookup entries.
>> + */
>> +static void clkdev_add_nolock(struct clk_lookup *cl)
>> +{
>> +    list_add_tail(&cl->node, &clocks);
>> +}
>> +
>>   /*
>>    * Find the correct struct clk for the device and connection ID.
>>    * We do slightly fuzzy matching here:
>> @@ -106,6 +118,9 @@ static struct clk_lookup *clk_find(const char
>> *dev_id, const char *con_id)
>>   {
>>       struct clk_lookup *p, *cl = NULL;
>>       int match, best_found = 0, best_possible = 0;
>> +    struct device_node *node;
>> +    struct clk *clk;
>> +    struct of_phandle_args clkspec;
>>
>>       if (dev_id)
>>           best_possible += 2;
>> @@ -133,6 +148,23 @@ static struct clk_lookup *clk_find(const char
>> *dev_id, const char *con_id)
>>                   break;
>>           }
>>       }
>> +
>> +    if (cl)
>> +        return cl;
>> +
>> +    /* If clock was not found, attempt to look-up from DT */
>> +    node = of_find_node_by_name(NULL, con_id);
>> +
>> +    clkspec.np = node;
>> +
>> +    clk = of_clk_get_from_provider(&clkspec);
>> +
>> +    if (!IS_ERR(clk)) {
>> +        /* We found a clock, add node to clkdev */
>> +        cl = clkdev_alloc(clk, con_id, dev_id);
>
> clkdev_alloc may return NULL depending on vclkdev_alloc in which case
> clkdev_add_nolock will crash trying to dereference it.

I'll add a check for that.

-Tero

>
>> +        clkdev_add_nolock(cl);
>> +    }
>> +
>>       return cl;
>>   }
>>
>>
>
>



From Ian.Campbell at citrix.com  Wed Jul 31 04:55:06 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Wed, 31 Jul 2013 09:55:06 +0100
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <CAHCPf3vUA1bD+1xPch-KZX6fdDzxsWjnVpUD39AKC=ds+EKeHQ@mail.gmail.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
 <51F7B4C9.2060500@gmail.com>
 <20130730125650.GD28716@e106331-lin.cambridge.arm.com>
 <20130730134427.GE28716@e106331-lin.cambridge.arm.com>
 <alpine.DEB.2.02.1307301528540.4893@kaball.uk.xensource.com>
 <1375195354.32691.55.camel@kazak.uk.xensource.com>
 <CAHCPf3vUA1bD+1xPch-KZX6fdDzxsWjnVpUD39AKC=ds+EKeHQ@mail.gmail.com>
Message-ID: <1375260906.32691.93.camel@kazak.uk.xensource.com>

On Tue, 2013-07-30 at 12:48 -0500, Matt Sealey wrote:
> * An AArch64 guest under an AArch32 hypervisor/sm seems pretty weird
> and in any case, the device tree would use the 32-bit convention (any
> SMC64 call in 32-bit state should return "Unknown SMC Function
> Identifier" if that bit is set)

I don't believe 64-bit EL1 under 32-bit EL2 is allowed by the
architecture. Each EL must be at least the width of the one below it.

> TLDR; Supply your (EL1) guests with the preferred method, not a list
> of all possible methods, as above. If you're the vendor and you
> defined any part of EL3 or EL2 you're in complete control of which
> method you want subordinate levels to use by way of implementation,
> right?

I haven't seen the entirety of this discussion, but that seems logical
to me.

> 
> BTW according to the specs you can't have EL2 without EL3 on ARMv7. I
> would think the issues with hvc vs hvc64 need to be thought out;
> hypervisors can trap SMC from their guests and do the right thing
> without the guest ever knowing that a hypervisor is above it.

The issue is that SMC traps don't provide you with the #imm in the
syndrome register so you need to fetch and decode the instruction in the
hypervisor manually, which is possible but faffsome and relatively
costly (mostly due to the need to map guest memory on demand).

> If it is the case that every Xen DomU kernel needs to know that it is
> virtualized and to be told to use HVC instead of SMC? What's the
> benefit of that?

Just the avoidance of a fetch and decode, I think.

I'm also not sure if Secure world can't prevent NS EL2 from tapping SMC,
would need to check the specs.

Ian.



From Ian.Campbell at citrix.com  Wed Jul 31 04:57:12 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Wed, 31 Jul 2013 09:57:12 +0100
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <51F8153C.8030503@gmail.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
 <51F7B4C9.2060500@gmail.com>
 <20130730125650.GD28716@e106331-lin.cambridge.arm.com>
 <20130730134427.GE28716@e106331-lin.cambridge.arm.com>
 <alpine.DEB.2.02.1307301528540.4893@kaball.uk.xensource.com>
 <51F8153C.8030503@gmail.com>
Message-ID: <1375261032.32691.95.camel@kazak.uk.xensource.com>

On Tue, 2013-07-30 at 14:34 -0500, Rob Herring wrote:

> I can think of lots of ways it would be cleaner, but that is not what
> ARM defined. There are 3 cases to handle: 32-bit only calls, 64-bit only
> calls and both 32/64-bit calls. I think hypervisors have the same issue
> as firmware. Do you know the guest is 32 or 64 bit up front and can
> provide it a dtb based on that?

Yes. An EL cannot change its own bit width and needs to rely on the EL
above returning in the right mode. IOW a hypervisor needs to know if it
is launching a 32- or 64-bit guest already.

I suppose in theory we could supply a mode switch hypercall, but we
don't and I think that is rather out of scope here...

Ian.



From t-kristo at ti.com  Wed Jul 31 04:59:15 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 11:59:15 +0300
Subject: [PATCHv4 02/33] clk: omap: introduce clock driver
In-Reply-To: <51F7DA0D.7060709@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-3-git-send-email-t-kristo@ti.com> <51F7DA0D.7060709@ti.com>
Message-ID: <51F8D1E3.2@ti.com>

On 07/30/2013 06:21 PM, Nishanth Menon wrote:
> On 07/23/2013 02:19 AM, Tero Kristo wrote:
>> Parses OMAP clock data from DT and registers those clocks with the clock
>> framework.  dt_omap_clk_init must be called early during boot for timer
>> initialization so it is exported and called from the existing clock code
>> instead of probing like a real driver. Based on initial work done by
>> Mike Turquette.
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> Cc: Mike Turquette <mturquette at linaro.org>
>> ---
>>   drivers/clk/Makefile      |    1 +
>>   drivers/clk/omap/Makefile |    1 +
>>   drivers/clk/omap/clk.c    |   39
>> +++++++++++++++++++++++++++++++++++++++
>
> Minor suggestion - should we just start drivers/clk/ti/ instead of
> clk/omap?
>
> AM335x/DRA7 are not "strictly OMAP".. might also allow for some reuse
> for other TI platforms..

Not sure, this idea has been bounced around a bit. samsung has its own 
directory under drivers/clk/ so maybe. I can change this if there is a 
strong wish for this.

>
>>   include/linux/clk/omap.h  |   24 ++++++++++++++++++++++++
>>   4 files changed, 65 insertions(+)
>>   create mode 100644 drivers/clk/omap/Makefile
>>   create mode 100644 drivers/clk/omap/clk.c
>>   create mode 100644 include/linux/clk/omap.h
>>
>> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
>> index 4038c2b..d3c3733 100644
>> --- a/drivers/clk/Makefile
>> +++ b/drivers/clk/Makefile
>> @@ -32,6 +32,7 @@ obj-$(CONFIG_ARCH_VT8500)    += clk-vt8500.o
>>   obj-$(CONFIG_ARCH_ZYNQ)        += zynq/
>>   obj-$(CONFIG_ARCH_TEGRA)    += tegra/
>>   obj-$(CONFIG_PLAT_SAMSUNG)    += samsung/
>> +obj-$(CONFIG_ARCH_OMAP)        += omap/
>>
>>   obj-$(CONFIG_X86)        += x86/
>>
>> diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
>> new file mode 100644
>> index 0000000..8195931
>> --- /dev/null
>> +++ b/drivers/clk/omap/Makefile
>> @@ -0,0 +1 @@
>> +obj-y                    += clk.o
>> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
>> new file mode 100644
>> index 0000000..4bf1929
>> --- /dev/null
>> +++ b/drivers/clk/omap/clk.c
>> @@ -0,0 +1,39 @@
>> +/*
>> + * OMAP PRCM clock driver
>
> maybe then prcm-clk.c ?

Maybe remove the PRCM part. We have some clocks behind i2c for example, 
and we might want to add support for them here.

>
>> + *
>> + * Copyright (C) 2013 Texas Instruments, Inc.
>> + *     Tero Kristo <t-kristo at ti.com>
>> + *     Mike Turquette <mturquette at linaro.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/clk-provider.h>
>> +#include <linux/clk/omap.h>
>> +#include <linux/kernel.h>
>> +#include <linux/of_device.h>
>> +
>> +/* FIXME - should the OMAP PRCM clock driver match generic types? */
>
> should it? :)

Not 100% sure about the answer to this, the current implementation works 
though so we could potentially drop this comment. :)

>
>> +static const struct of_device_id clk_match[] = {
>> +    {.compatible = "fixed-clock", .data = of_fixed_clk_setup, },
> drivers/clk/clk-fixed-rate.c seems to already do this with
> CLK_OF_DECLARE, or am I mistaken? and so on?
>> +    {.compatible = "mux-clock", .data = of_mux_clk_setup, },
>> +    {.compatible = "fixed-factor-clock",
>> +        .data = of_fixed_factor_clk_setup, },
>> +    {.compatible = "divider-clock", .data = of_divider_clk_setup, },
>> +    {.compatible = "gate-clock", .data = of_gate_clk_setup, },
>> +    {},
>> +};
>> +
>> +/* FIXME - need to initialize early; skip real driver registration &
>> probe */
>> +int __init dt_omap_clk_init(void)
>
> Might be good to have kernel doc to explain the init requirement as
> documented in commit message.

Yeah, I am lacking docs once again.

>
>> +{
>> +    of_clk_init(clk_match);
>
> just doing of_clk_init(NULL); should do the job, no? that could even be
> a static inline OR introduced in board_generic without additional headers?

I don't think that works, as we have special clock node types we want to 
support (the TI specific types, and we want to override the default 
behavior of some.)

>
>> +    return 0;
>> +}
>> diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
>> new file mode 100644
>> index 0000000..647f02f
>> --- /dev/null
>> +++ b/include/linux/clk/omap.h
>> @@ -0,0 +1,24 @@
>> +/*
>> + * Copyright (C) 2013 Texas Instruments, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>
> would you like to match licensing to that of the C file?

Ok, copy paste bug #2 for this. Initial version was worse than this though.

>
>> + *
>> + * 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
>> 02111-1307  USA
>> + */
>> +
>> +#ifndef __LINUX_CLK_OMAP_H_
>> +#define __LINUX_CLK_OMAP_H_
>> +
>> +int __init dt_omap_clk_init(void);
>> +
>> +#endif
>>
>
>



From thomas.petazzoni at free-electrons.com  Wed Jul 31 05:00:45 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 31 Jul 2013 11:00:45 +0200
Subject: pci-mvebu driver on km_kirkwood
In-Reply-To: <51F8CA44.4080802@keymile.com>
References: <51DD88A4.1030506@keymile.com> <20130731100359.3e789236@skate>
 <51F8CA44.4080802@keymile.com>
Message-ID: <20130731110045.2dc84981@skate>

Dear Gerlando Falauto,

[ Device Tree mailing list readers: there is a question for you below. ]

On Wed, 31 Jul 2013 10:26:44 +0200, Gerlando Falauto wrote:

> >> I am trying to use the pci-mvebu driver on one of our km_kirkwood
> >> boards. The board is based on Marvell's 98dx4122, which should
> >> essentially be 6281 compatible.
> >
> > In the end, did you manage to get the pci-mvebu driver to work on your
> > platform?
> 
> Yes, I did -- though I didn't go much beyond simple device probing (i.e. 
> no real, intense usage of devices).

Ok, good.

> AND I'm not using the DT-based mbus 
> driver (i.e. addresses are still hardcoded within the source code).

Ok, that will be the next step, but I don't expect you to face many
issues. The DT-based mbus doesn't change much the internal logic, it's
really just the DT representation that's different. On the other hand,
the new PCIe driver was completely changing the internal logic, by
adding the emulated PCI-to-PCI bridge.

> Actually, the main reason for trying to use this driver was because I 
> wanted to model a PCIe *device* within the device tree, so to expose its 
> GPIOs and IRQs to be referenced (through phandles) from other device 
> tree nodes. The way I understand it, turns out this is not the way to 
> go, as PCI/PCIe are essentially enumerated busses, so you're not 
> supposed to -and it's not a trivial task to- put any information about 
> real devices within the device tree.
> Do you have any suggestion about that?

Indeed, PCI/PCIe devices are enumerated dynamically, so they are not
listed in the Device Tree, so there's no way to "attach" more
information to them.

Device Tree people, any suggestion about the above question?

> On the other hand, for our use case I'm afraid there might be some 
> hardcoded values within drivers or userspace code, where a certain PCIe 
> device is expected to be connected within a given bus number with a 
> given device number (bleah!).
> If I understand correctly, your driver creates a virtual PCI-to-PCI 
> bridge, so our devices would be connected to BUS #1 as opposed to #0 -- 
> which might break existing (cr*ee*ppy) code.
> But that's not your fault of course.

Yeah, I believe normally userspace code shouldn't rely on a particular
PCI bus topology.

> If you're interested, I can keep you posted as soon as we proceed 
> further with this (most likely in September or so).

Sure.

> Next step would be to test Ezequiel's MBus DT binding [PATCH v8], but 
> I'm afraid that'll have to wait too, until end of August or so, as I am 
> about to leave for vacation.

Ok, thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From moinejf at free.fr  Wed Jul 31 05:03:09 2013
From: moinejf at free.fr (Jean-Francois Moine)
Date: Wed, 31 Jul 2013 11:03:09 +0200
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]
In-Reply-To: <20130730094904.GH11527@mudshark.cambridge.arm.com>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
 <20130715135420.GG10000@mudshark.cambridge.arm.com>
 <20130720044655.GC9433@mozilla.com>
 <20130721213753.GA29879@mudshark.cambridge.arm.com>
 <20130722185234.GA14519@localhost.localdomain>
 <20130729212140.GB12681@mozilla.com>
 <20130730092517.GB2478@localhost.localdomain>
 <20130730113853.46cbb00a@armhf>
 <20130730094904.GH11527@mudshark.cambridge.arm.com>
Message-ID: <20130731110309.758cf0aa@armhf>

On Tue, 30 Jul 2013 10:49:04 +0100
Will Deacon <will.deacon at arm.com> wrote:

> On Tue, Jul 30, 2013 at 10:38:53AM +0100, Jean-Francois Moine wrote:
> > BTW, kernels compiled with gcc-4.8 don't work.  
> 
> Erm. Can you elaborate please? There was an issue where SLUB would get
> miscompiled with 4.8 due to some per-cpu variable reordering across
> barrier(), but I fixed that for ARM in 3.10.

I compiled the 3.11.0-rc3 with gcc-4.8.1 and I still get oops in ext3
(no problem when compiled with gcc-4.6). Here is the dmesg.

Booting Linux on physical CPU 0x0
Linux version 3.11.0-rc3-00004-g36f571e-dirty (jef at armhf) (gcc version 4.8.1 (Debian 4.8.1-8) ) #1 PREEMPT Wed Jul 31 09:22:30 CEST 2013
CPU: ARMv7 Processor [560f5815] revision 5 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine: Marvell Dove (Flattened Device Tree), model: SolidRun CuBox
cma: CMA: reserved 32 MiB at 3e000000
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat 804ebd2c, node_mem_map 8075b000
  Normal zone: 2048 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 262144 pages, LIFO batch:31
CPU: All CPU(s) started in SVC mode.
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: console=ttyS0,115200n8 console=tty1,115200 root=/dev/sda7 rootwait video=HDMI-A-1:1920x1080-32 at 60
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1001516K/1048576K available (3715K kernel code, 177K rwdata, 980K rodata, 135K init, 129K bss, 47060K reserved)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
    lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
    modules : 0x7f000000 - 0x80000000   (  16 MB)
      .text : 0x80008000 - 0x8049df34   (4696 kB)
      .init : 0x8049e000 - 0x804bfe68   ( 136 kB)
      .data : 0x804c0000 - 0x804ec5c0   ( 178 kB)
       .bss : 0x804ec5c0 - 0x8050cad0   ( 130 kB)
Preemptible hierarchical RCU implementation.
	Dump stacks of tasks blocking RCU-preempt GP.
NR_IRQS:135
sched_clock: 32 bits at 166MHz, resolution 5ns, wraps every 25769ms
Console: colour dummy device 80x30
console [tty1] enabled
Calibrating delay loop... 789.70 BogoMIPS (lpj=3948544)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x803a6620 - 0x803a6654
devtmpfs: initialized
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
Dove 88AP510 SoC
Tauros2: Disabling L2 prefetch.
Tauros2: Disabling line fill burt8.
Tauros2: Enabling L2 cache.
Tauros2: L2 cache support initialised in ARMv7 mode.
bio: create slab <bio-0> at 0
USB Power: Failed to request enable GPIO1: -517
reg-fixed-voltage 1.regulator: Failed to register regulator: -517
platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Linux video capture interface: v2.00
Advanced Linux Sound Architecture Driver Initialized.
Switched to clocksource orion_clocksource
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
NET: Registered protocol family 1
audit: initializing netlink socket (disabled)
type=2000 audit(0.070:1): initialized
msgmni has been set to 2020
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
dove-pinctrl f10d0200.pinctrl: registered pinctrl driver
mv_xor f1060800.dma-engine: Marvell shared XOR driver
mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
mv_xor f1060900.dma-engine: Marvell shared XOR driver
mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 7) is a 16550A
console [ttyS0] enabled
brd: module loaded
sata_mv f10a0000.sata: version 1.28
sata_mv f10a0000.sata: slots 32 ports 1
scsi0 : sata_mv
ata1: SATA max UDMA/133 irq 62
libphy: orion_mdio_bus: probed
mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
libphy: PHY orion-mdio-mii:08 not found
libphy: PHY orion-mdio-mii:09 not found
libphy: PHY orion-mdio-mii:0a not found
libphy: PHY orion-mdio-mii:0b not found
libphy: PHY orion-mdio-mii:0c not found
libphy: PHY orion-mdio-mii:0d not found
libphy: PHY orion-mdio-mii:0e not found
libphy: PHY orion-mdio-mii:0f not found
libphy: PHY orion-mdio-mii:10 not found
libphy: PHY orion-mdio-mii:11 not found
libphy: PHY orion-mdio-mii:12 not found
libphy: PHY orion-mdio-mii:13 not found
libphy: PHY orion-mdio-mii:14 not found
libphy: PHY orion-mdio-mii:15 not found
libphy: PHY orion-mdio-mii:16 not found
libphy: PHY orion-mdio-mii:17 not found
libphy: PHY orion-mdio-mii:18 not found
libphy: PHY orion-mdio-mii:19 not found
libphy: PHY orion-mdio-mii:1a not found
libphy: PHY orion-mdio-mii:1b not found
libphy: PHY orion-mdio-mii:1c not found
libphy: PHY orion-mdio-mii:1d not found
libphy: PHY orion-mdio-mii:1e not found
libphy: PHY orion-mdio-mii:1f not found
libphy: PHY orion-mdio-mii:00 not found
mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:b6:3b:10
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-orion: EHCI orion driver
orion-ehci f1050000.usb-host: EHCI Host Controller
orion-ehci f1050000.usb-host: new USB bus registered, assigned bus number 1
orion-ehci f1050000.usb-host: irq 24, io mem 0xf1050000
orion-ehci f1050000.usb-host: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
orion-ehci f1051000.usb-host: EHCI Host Controller
orion-ehci f1051000.usb-host: new USB bus registered, assigned bus number 2
orion-ehci f1051000.usb-host: irq 25, io mem 0xf1051000
orion-ehci f1051000.usb-host: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
rtc-mv f10d8500.rtc: rtc core: registered f10d8500.rtc as rtc0
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: no vqmmc regulator found
mmc0: no vmmc regulator found
mmc0: SDHCI controller on f1092000.sdio [f1092000.sdio] using DMA
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP: cubic registered
NET: Registered protocol family 10
NET: Registered protocol family 17
VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5
ThumbEE CPU extension supported.
PJ4 iWMMXt coprocessor enabled.
USB Power: 5000 mV 
rtc-mv f10d8500.rtc: setting system clock to 2013-07-31 08:15:22 UTC (1375258522)
ALSA device list:
  No soundcards found.
ata1: SATA link down (SStatus 0 SControl F300)
mmc0: new high speed SDHC card at address e624
mmcblk0: mmc0:e624 SU16G 14.8 GiB 
 mmcblk0: p1 p2 p3
Waiting for root device /dev/sda7...
usb 1-1: new high-speed USB device number 2 using orion-ehci
usb-storage 1-1:1.0: USB Mass Storage device detected
scsi1 : usb-storage 1-1:1.0
usb 2-1: new high-speed USB device number 2 using orion-ehci
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 4 ports detected
usb 2-1.4: new high-speed USB device number 3 using orion-ehci
hub 2-1.4:1.0: USB hub found
hub 2-1.4:1.0: 4 ports detected
usb 2-1.4.2: new high-speed USB device number 4 using orion-ehci
scsi 1:0:0:0: Direct-Access     WDC WD25 00JB-55REA0      20.0 PQ: 0 ANSI: 0
sd 1:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 03 00 00 00
sd 1:0:0:0: [sda] No Caching mode page present
sd 1:0:0:0: [sda] Assuming drive cache: write through
sd 1:0:0:0: [sda] No Caching mode page present
sd 1:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
sd 1:0:0:0: [sda] No Caching mode page present
sd 1:0:0:0: [sda] Assuming drive cache: write through
sd 1:0:0:0: [sda] Attached SCSI disk
EXT3-fs (sda7): mounted filesystem with ordered data mode
kjournald starting.  Commit interval 5 seconds
usb 2-1.4.3: new low-speed USB device number 5 using orion-ehci
VFS: Mounted root (ext3 filesystem) readonly on device 8:7.
devtmpfs: mounted
Freeing unused kernel memory: 132K (8049e000 - 804bf000)
input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.0/input/input0
hid-generic 0003:13BA:0017.0001: input: USB HID v1.10 Keyboard [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input0
input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.1/input/input1
hid-generic 0003:13BA:0017.0002: input: USB HID v1.10 Mouse [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input1
udevd[583]: starting version 175
[drm] Initialized drm 1.1.0 20060810
cfg80211: Calling CRDA to update world regulatory domain
simple-dt-audio sound.5:  dit-hifi <-> f10b4000.audio-controller mapping ok
tda998x 0-0070: found TDA19988
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
usb 2-1.4.2: reset high-speed USB device number 4 using orion-ehci
usb 2-1.4.2: Loading firmware file isl3887usb
usbcore: registered new interface driver p54usb
ieee80211 phy0: p54 detected a LM87 firmware
p54: rx_mtu reduced from 3240 to 2384
ieee80211 phy0: FW rev 2.13.25.0 - Softmac protocol 5.9
ieee80211 phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
Console: switching to colour frame buffer device 240x67
dove-drm video.6: fb0:  frame buffer device
dove-drm video.6: registered panic notifier
[drm] Initialized dove-drm 1.0.0 20130516 on minor 0
ieee80211 phy0: hwaddr 00:12:bf:1e:9c:e4, MAC:isl3887 RF:Frisbee
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
usb 2-1.4.2: is registered as 'phy0'
Unable to handle kernel NULL pointer dereference at virtual address 00000003
pgd = bd374000
[00000003] *pgd=3d3af831, *pte=00000000, *ppte=00000000
Internal error: Oops: 811 [#1] PREEMPT ARM
Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
CPU: 0 PID: 731 Comm: usb-db Not tainted 3.11.0-rc3-00004-g36f571e-dirty #1
task: bda0dc00 ti: bd2fa000 task.ti: bd2fa000
PC is at do_mpage_readpage+0x754/0x888
LR is at bio_add_page+0x44/0x4c
pc : [<800e89c0>]    lr : [<800e05e4>]    psr: 600e0013
sp : bd2fbc74  ip : bd2fbcc8  fp : bd2fbc9c
r10: 00000003  r9 : 00000000  r8 : 00000004
r7 : 00000001  r6 : 800e8ca4  r5 : bd2fbc70  r4 : 00000003
r3 : 00001000  r2 : 00000003  r1 : 00000000  r0 : bd2fbc9c
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 3d374019  DAC: 00000015
Process usb-db (pid: 731, stack limit = 0xbd2fa240)
Stack: (0xbd2fbc74 to 0xbd2fc000)
bc60:                                              00000001 bd2fbd64 00200200
bc80: 00100100 bd53cd54 bd9f1340 80eed380 bd2fbd34 bd2fbca0 800e8bc8 800e8278
bca0: bd2fbcc8 bd2fbcbc 8011c554 000000c1 804ebd2c 8011c554 00000002 00000003
bcc0: 0028de87 00000000 00000000 bd2fbcd8 80eed380 803a2f54 0028df40 00000000
bce0: 00001000 00000000 bd402ac0 8003b810 bd2fbcf0 bd2fbcf0 bd53ccb4 bd2fbd7c
bd00: bd53ccbc 00000002 bd2fbd24 8011a00c 00000004 00000004 00000000 0000007a
bd20: 00000000 00000004 bd2fbd44 bd2fbd38 8011a030 800e8b00 bd2fbdac bd2fbd48
bd40: 8007dd28 8011a018 bda54780 00000001 bd53cd54 00000004 bd53cd58 bd2fbd64
bd60: 800c23bc bd2fbd64 bd2fbd64 91827364 bd8d5de8 bd8d5de8 bd2fbd78 bd2fbd78
bd80: 800add50 bd53cd54 bda54780 bda547c8 00000000 00000020 00000003 bd53cd54
bda0: bd2fbdec bd2fbdb0 8007e0e0 8007db44 00000003 bd11e470 bd95462c bdbe1540
bdc0: bd2fbddc bd53cd54 00000000 00000000 bd53cc98 00000001 00000000 bda54780
bde0: bd2fbe0c bd2fbdf0 8007e3b8 8007dfc4 00000000 00000001 00000000 bd53cd54
be00: bd2fbeac bd2fbe10 8007471c 8007e378 00000001 bd954b78 bd9545f8 bd9545f8
be20: 76f24000 76f25000 00000001 00080001 bd2fbeb8 bd2fbec0 ffffffff 00000000
be40: 00000000 bdbe1540 00000001 bd954608 00000001 00000fff bd2fa000 bda547c8
be60: 00000000 00000001 76f25000 00000000 00000000 00001000 76f24000 00000000
be80: 80097780 00000000 00000000 00001000 bd2fbf78 bda54780 bda0dc00 00020000
bea0: bd2fbf44 bd2fbeb0 800abf60 800741cc 00000000 00000000 76f24000 00001000
bec0: 00000001 bda54780 00000000 00000000 00000000 bda0dc00 00000000 00000000
bee0: 00000000 00000000 00000000 00000000 00001000 00000000 00001000 00000000
bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bf20: bda54780 76f24000 bd2fbf78 76f24000 00000000 00001000 bd2fbf74 bd2fbf48
bf40: 800ac69c 800abeec 00800007 00000022 00000000 00000000 bda54780 76f24000
bf60: 00000000 00001000 bd2fbfa4 bd2fbf78 800acd84 800ac608 00000000 00000000
bf80: 017f7278 76ec7c58 00000000 00000003 8000e604 bd2fa000 00000000 bd2fbfa8
bfa0: 8000e480 800acd4c 017f7278 76ec7c58 00000003 76f24000 00001000 00000000
bfc0: 017f7278 76ec7c58 00000000 00000003 7eac3ad0 7eac3ad4 76f29000 00000000
bfe0: 00000000 7eac3a64 76e389cf 76e6f21c 400e0010 00000003 00000000 00000000
Backtrace: 
[<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
[<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
[<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
[<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
[<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
[<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
 r4:bd53cd54
[<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
[<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
 r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
r4:bda54780
[<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
 r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
r4:00000000
[<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
 r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
r4:017f7278
Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0) 
---[ end trace e23d6b4d1dcd7a83 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 731 at /home/jef/kernel/kernel/exit.c:703 do_exit+0x54/0x900()
Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
CPU: 0 PID: 731 Comm: usb-db Tainted: G      D      3.11.0-rc3-00004-g36f571e-dirty #1
Backtrace: 
[<800112c4>] (dump_backtrace+0x0/0x110) from [<800114dc>] (show_stack+0x18/0x1c)
 r6:000002bf r5:00000009 r4:00000000 r3:00000000
[<800114c4>] (show_stack+0x0/0x1c) from [<803a25b0>] (dump_stack+0x24/0x28)
[<803a258c>] (dump_stack+0x0/0x28) from [<8001ad28>] (warn_slowpath_common+0x74/0x8c)
[<8001acb4>] (warn_slowpath_common+0x0/0x8c) from [<8001ade4>] (warn_slowpath_null+0x24/0x2c)
 r8:00000811 r7:bd2fa000 r6:80439cc4 r5:0000000b r4:804cb598
[<8001adc0>] (warn_slowpath_null+0x0/0x2c) from [<8001f248>] (do_exit+0x54/0x900)
[<8001f1f4>] (do_exit+0x0/0x900) from [<80011664>] (die+0x184/0x238)
 r7:bd2fa000
[<800114e0>] (die+0x0/0x238) from [<803a07dc>] (__do_kernel_fault.part.10+0x6c/0x7c)
[<803a0770>] (__do_kernel_fault.part.10+0x0/0x7c) from [<8001420c>] (do_sect_fault+0x0/0x18)
 r7:bdbe1540 r3:bd2fbc28
[<8001417c>] (do_bad_area+0x0/0x90) from [<80015d10>] (do_alignment+0xd0/0x844)
 r7:00000003 r6:800e89c0 r5:804ec85c r4:bd2fbc28
[<80015c40>] (do_alignment+0x0/0x844) from [<80008460>] (do_DataAbort+0x40/0xa0)
[<80008420>] (do_DataAbort+0x0/0xa0) from [<80011fb8>] (__dabt_svc+0x38/0x60)
Exception stack(0xbd2fbc28 to 0xbd2fbc70)
bc20:                   bd2fbc9c 00000000 00000003 00001000 00000003 bd2fbc70
bc40: 800e8ca4 00000001 00000004 00000000 00000003 bd2fbc9c bd2fbcc8 bd2fbc74
bc60: 800e05e4 800e89c0 600e0013 ffffffff
 r8:00000004 r7:bd2fbc5c r6:ffffffff r5:600e0013 r4:800e89c0
[<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
[<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
[<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
[<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
[<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
[<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
 r4:bd53cd54
[<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
[<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
 r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
r4:bda54780
[<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
 r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
r4:00000000
[<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
 r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
r4:017f7278
---[ end trace e23d6b4d1dcd7a84 ]---
EXT3-fs (sda7): using internal journal
IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
wlan1: authenticate with 00:24:d4:9c:29:68
wlan1: send auth to 00:24:d4:9c:29:68 (try 1/3)
wlan1: authenticated
p54usb 2-1.4.2:1.0 wlan1: disabling HT/VHT due to WEP/TKIP use
wlan1: associate with 00:24:d4:9c:29:68 (try 1/3)
wlan1: RX AssocResp from 00:24:d4:9c:29:68 (capab=0x411 status=0 aid=1)
IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
wlan1: associated

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/


From josephl at nvidia.com  Wed Jul 31 05:10:41 2013
From: josephl at nvidia.com (Joseph Lo)
Date: Wed, 31 Jul 2013 17:10:41 +0800
Subject: [PATCH V2] ARM: dts: tegra114: dalmore: fix the irq trigger
 type of Palmas MFD device
In-Reply-To: <51F7E8B5.6030009@wwwdotorg.org>
References: <1374663272-9937-1-git-send-email-josephl@nvidia.com>
 <51F292D4.9030208@wwwdotorg.org>
 <1375177568.1239.16.camel@jlo-ubuntu-64.nvidia.com>
 <51F7E8B5.6030009@wwwdotorg.org>
Message-ID: <1375261841.1231.166.camel@jlo-ubuntu-64.nvidia.com>

On Wed, 2013-07-31 at 00:24 +0800, Stephen Warren wrote:
> On 07/30/2013 03:46 AM, Joseph Lo wrote:
> > On Fri, 2013-07-26 at 23:16 +0800, Stephen Warren wrote:
> >> On 07/24/2013 04:54 AM, Joseph Lo wrote:
> >>> The IRQ trigger type of Palmas MFD device (tps65913) is edge trigger. The
> >>> wrong configuration would cause an interrupt storm when booting the
> >>> system. Fixing it in DT with appropriate interrupt type.
> >>
> >>> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
> >>
> >>>  		palmas: tps65913 {
> >>>  			compatible = "ti,palmas";
> >>>  			reg = <0x58>;
> >>> -			interrupts = <0 86 0x4>;
> >>> +			interrupts = <0 86 0x0>;
> >>
> >> The legal values for that final cell are:
> >>
> >>     - bits[3:0] trigger type and level flags
> >>         1 = low-to-high edge triggered
> >>         2 = high-to-low edge triggered
> >>         4 = active high level-sensitive
> >>         8 = active low level-sensitive
> >>
> >> 0 isn't one of those values. This patch can't be correct.
> >>
> >> BTW, this cell should use the constants from
> >> <dt-bindings/interrupt-controller/irq.h>.
> > 
> > Oops. I made a wrong description in the commit message.
> > 
> > Update my test result again.
> > 
> >> 1 = low-to-high edge triggered
> > No IRQ storm, but the system always auto wake up by Palmas RTC.
> >> 2 = high-to-low edge triggered
> > No IRQ storm, but the GIC didn't support this trigger type. The flag
> > would be re-configured as 0x0.
> >> 4 = active high level-sensitive
> > There is a IRQ storm when system booting.
> >> 8 = active low level-sensitive
> > No IRQ strom, but the GIC didn't support this trigger type. The flag
> > would be re-configured as 0x0.
> > 
> >> nvidia, invert-interrupt
> > Removing this can fix IRQ storm too, but the system always auto wake up
> > by Palmas RTC.
> > 
> > So we can only three trigger type here.
> > IRQ_TYPE_NONE 0
> 
> That's not a valid value; it just means that the GIC driver doesn't
> explicitly set the type, and the HW probably defaults to active high?
> 
oh,yes. May be.

> > IRQ_TYPE_EDGE_FALLING 2
> > IRQ_TYPE_LEVEL_LOW 8
> > 
> > But using IRQ_TYPE_EDGE_FALLING or IRQ_TYPE_LEVEL_LOW, it would
> > configure to IRQ_TYPE_NONE. Because the PMIC is low level trigger to PMC
> > on Dalmore, I would prefer to use IRQ_TYPE_LEVEL_LOW just like the v1.
> > Any comments?
> 
> Comments no, I just have confusion!
> 
> We should simply set this flag to the correct value. Does the PMIC
> output an edge-sensitive or level-sensitive signal? Is the signal
> active-high/rising or active-low/falling? Those are the only things that
> should be considered when selecting the correct value for the IRQ flags.
> This information can be determined by reading the data sheet for the
> PMIC; while the test results you mention above are interesting, the HW
> documentation should drive the value we select here, unless the
> documentation has a known bug.
> 
OK, the PMIC(Palmas here) only support level-sensitive and default is
active low.

But it was being configured as active high in the Dalmore's DT. And yes,
it can work fine with the configuration you mentioned below. The suspend
mode of LP1/LP2 that could be woken up by IRQ is OK in this case.

But if checking the PMU_INT signal in the schematic of Dalmore, it only
supports active low. It was connected to !PWR_INT of Tegra114 that will
cause the system wake up automatically when syspended to LP0 if active
high.

That's why my change is setting the IRQ type of PMIC to active low and
keep the "nvidia,invert-interrupt". And it can make the LP0/1/2 work
proper.

> If there is an IRQ storm, then that sounds like a bug in the code. That
> needs to be fixed too, not worked around by setting an incorrect IRQ
> flags value.
> 
By the way, don't you see IRQ storm like below(You use "if" here)?

[   87.054085] irq 118: nobody cared (try booting with the "irqpoll"
option)
[   87.060862] CPU: 0 PID: 41 Comm: irq/118-palmas Not tainted
3.11.0-rc2-next-20130722-00011-gadb202a-dirty #11
[   87.070811] [<c0012161>] (unwind_backtrace+0x1/0x98) from
[<c000f07b>] (show_stack+0xb/0xc)
[   87.079134] [<c000f07b>] (show_stack+0xb/0xc) from [<c038af89>]
(dump_stack+0x59/0x8c)
[   87.087035] [<c038af89>] (dump_stack+0x59/0x8c) from [<c005eef9>]
(__report_bad_irq+0x15/0x80)
[   87.095676] [<c005eef9>] (__report_bad_irq+0x15/0x80) from
[<c005f22d>] (note_interrupt+0x139/0x17c)
[   87.104782] [<c005f22d>] (note_interrupt+0x139/0x17c) from
[<c005e4d7>] (irq_thread+0xc3/0xd4)
[   87.113424] [<c005e4d7>] (irq_thread+0xc3/0xd4) from [<c002f87b>]
(kthread+0x6b/0x74)
[   87.121237] [<c002f87b>] (kthread+0x6b/0x74) from [<c000ccfd>]
(ret_from_fork+0x11/0x34)
[   87.121325] vdd-sensor-2v85: disabling
[   87.133064] handlers:
[   87.135335] [<c005dd85>] irq_default_primary_handler threaded
[<c01dbd99>] regmap_irq_thread
[   87.143762] Disabling IRQ #118

           CPU0       CPU1       CPU2       CPU3       
...
 85:     804308          0          0          0       GIC  85  i2c
118:     100001          0          0          0       GIC 118  palmas
122:        152          0          0          0       GIC 122  serial
...

> To be clear, here is what I would expect depending on what kind of IRQ
> signal the PMIC outputs:
> 
> active-low:
> GIC: active-high, PMC: nvidia,invert-interrupt
> 
> active-high:
> GIC: active-high, PMC: NO nvidia,invert-interrupt
> 
> falling-edge:
> GIC: rising-edge-triggered, PMC: nvidia,invert-interrupt
> 
> rising-edge:
> GIC: rising-edge-triggered, PMC: NO nvidia,invert-interrupt




From thomas.petazzoni at free-electrons.com  Wed Jul 31 05:14:14 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 31 Jul 2013 11:14:14 +0200
Subject: NSA310 + DT
In-Reply-To: <20130730232316.10dc7019@skate>
References: <20130710073706.GA28212@lunn.ch> <51F6A0DC.3020501@uni-bremen.de>
 <20130729192112.GY29916@titan.lakedaemon.net>
 <20130729204315.GK24782@lunn.ch> <51F78DA6.8010307@uni-bremen.de>
 <20130730144752.GR24782@lunn.ch> <20130730172407.3aab15c6@skate>
 <51F7EBB9.7000504@uni-bremen.de> <20130730191943.49f8070c@skate>
 <20130730183610.GT24782@lunn.ch> <51F814A0.2050403@uni-bremen.de>
 <20130730232316.10dc7019@skate>
Message-ID: <20130731111414.47e7670b@skate>

Hello Finn,

On Tue, 30 Jul 2013 23:23:16 +0200, Thomas Petazzoni wrote:

> Thanks for this log. I need a bit of time to analyze this with the
> PCI-to-PCI bridge specification, and I'll cook up a new patch,
> hopefully tomorrow.
> 
> Thanks again a lot for taking the time to report this bug and test the
> patches,

Ok, here is another patch that completely disables prefetchable
support, which hopefully should make the PCI stuff fallback on normal
memory. Could you try this one, and again report lspci -v + the
contents of the debugfs file that lists the mbus windows?

I've worked more on the prefetchable support, but doing it right with
the PCI-to-PCI bridge emulation is a bit complex.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-pci-mvebu-disable-prefetchable-memory-support.patch
Type: text/x-patch
Size: 1780 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130731/bce3bb46/attachment.bin>

From daniel.lezcano at linaro.org  Wed Jul 31 05:09:59 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 31 Jul 2013 11:09:59 +0200
Subject: [PATCH/RESEND] clocksource: em_sti: Convert to devm_* managed
 helpers
In-Reply-To: <1375194277-2850-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
References: <1375194277-2850-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Message-ID: <51F8D467.1030400@linaro.org>

On 07/30/2013 04:24 PM, Laurent Pinchart wrote:
> Replace kzalloc, clk_get, ioremap and request_irq by their managed
> counterparts to simplify error paths.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> ---

Sounds good.

Reviewed-by: Daniel Lezcano <daniel.lezcano at linaro.org>

[ ... ]

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From nsekhar at ti.com  Wed Jul 31 05:18:31 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 31 Jul 2013 14:48:31 +0530
Subject: [PATCH 4/9] dma: edma: Find missed events and issue them
In-Reply-To: <51F89763.1010102@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
 <1375104595-16018-5-git-send-email-joelf@ti.com> <51F7659E.3040302@ti.com>
 <51F89763.1010102@ti.com>
Message-ID: <51F8D667.2040406@ti.com>

On Wednesday 31 July 2013 10:19 AM, Joel Fernandes wrote:
> Hi Sekhar,
> 
> On 07/30/2013 02:05 AM, Sekhar Nori wrote:
>> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>>> In an effort to move to using Scatter gather lists of any size with
>>> EDMA as discussed at [1] instead of placing limitations on the driver,
>>> we work through the limitations of the EDMAC hardware to find missed
>>> events and issue them.
>>>
>>> The sequence of events that require this are:
>>>
>>> For the scenario where MAX slots for an EDMA channel is 3:
>>>
>>> SG1 -> SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> Null
>>>
>>> The above SG list will have to be DMA'd in 2 sets:
>>>
>>> (1) SG1 -> SG2 -> SG3 -> Null
>>> (2) SG4 -> SG5 -> SG6 -> Null
>>>
>>> After (1) is succesfully transferred, the events from the MMC controller
>>> donot stop coming and are missed by the time we have setup the transfer
>>> for (2). So here, we catch the events missed as an error condition and
>>> issue them manually.
>>
>> Are you sure there wont be any effect of these missed events on the
>> peripheral side. For example, wont McASP get into an underrun condition
>> when it encounters a null PaRAM set? Even UART has to transmit to a
> 
> But it will not encounter null PaRAM set because McASP uses contiguous
> buffers for transfer which are not scattered across physical memory.
> This can be accomplished with an SG of size 1. For such SGs, this patch
> series leaves it linked Dummy and does not link to Null set. Null set is
> only used for SG lists that are > MAX_NR_SG in size such as those
> created for example by MMC and Crypto.
> 
>> particular baud so I guess it cannot wait like the way MMC/SD can.
> 
> Existing driver have to wait anyway if they hit MAX SG limit today. If
> they don't want to wait, they would have allocated a contiguous block of
> memory and DMA that in one stretch so they don't lose any events, and in
> such cases we are not linking to Null.

As long as DMA driver can advertize its MAX SG limit, peripherals can
always work around that by limiting the number of sync events they
generate so as to not having any of the events getting missed. With this
series, I am worried that EDMA drivers is advertizing that it can handle
any length SG list while not taking care of missing any events while
doing so. This will break the assumptions that driver writers make.

> 
>> Also, wont this lead to under-utilization of the peripheral bandwith?
>> Meaning, MMC/SD is ready with data but cannot transfer because the DMA
>> is waiting to be set-up.
> 
> But it is waiting anyway even today. Currently based on MAX segs, MMC
> driver/subsystem will make SG list of size max_segs. Between these
> sessions of creating such smaller SG-lists, if for some reason the MMC
> controller is sending events, these will be lost anyway.

But if MMC/SD driver knows how many events it should generate if it
knows the MAX SG limit. So there should not be any missed events in
current code. And I am not claiming that your solution is making matters
worse. But its not making it much better as well.

> 
> What will happen now with this patch series is we are simply accepting a
> bigger list than this, and handling all the max_segs stuff within the
> EDMA driver itself without outside world knowing. This is actually more
> efficient as for long transfers, we are not going back and forth much
> between the client and EDMA driver.

Agreed, I am not debating that we need to handle SG lists of any length.
The hardware is capable of handling them, and no reason kernel should not.

> 
>> Did you consider a ping-pong scheme with say three PaRAM sets per
>> channel? That way you can keep a continuous transfer going on from the
>> peripheral over the complete SG list.
> 
> Do you mean ping-pong scheme as used in the davinci-pcm driver today?

No. AFAIR, thats a ping-pong between internal RAM and DDR for earlier
audio ports which did not come with FIFO.

> This can be used only for buffers that are contiguous in memory, not
> those that are scattered across memory.

I was hinting at using the linking facility of EDMA to achieve this.
Each PaRAM set has full 32-bit source and destination pointers so I see
no reason why non-contiguous case cannot be handled.

Lets say you need to transfer SG[0..6] on channel C. Now, PaRAM sets are
typically 4 times the number of channels. In this case we use one DMA
PaRAM set and two Link PaRAM sets per channel. P0 is the DMA PaRAM set
and P1 and P2 are the Link sets.

Initial setup:

SG0 -> SG1 -> SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> NULL
 ^      ^      ^
 |      |      |
P0  -> P1  -> P2  -> NULL

P[0..2].TCINTEN = 1, so get an interrupt after each SG element
completion. On each completion interrupt, hardware automatically copies
the linked PaRAM set into the DMA PaRAM set so after SG0 is transferred
out, the state of hardware is:

SG1  -> SG2 -> SG3 -> SG3 -> SG6 -> NULL
 ^       ^
 |       |
P0,1    P2  -> NULL
 |       ^
 |       |
 ---------

SG1 transfer has already started by the time the TC interrupt is
handled. As you can see P1 is now redundant and ready to be recycled. So
in the interrupt handler, software recycles P1. Thus:

SG1 -> SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> NULL
 ^      ^      ^
 |      |      |
P0  -> P2  -> P1  -> NULL

Now, on next interrupt, P2 gets copied and thus can get recycled.
Hardware state:

SG2  -> SG3 -> SG4 -> SG5 -> SG6 -> NULL
 ^       ^
 |       |
P0,2    P1  -> NULL
 |       ^
 |       |
 ---------

As part of TC completion interrupt handling:

SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> NULL
 ^      ^      ^
 |      |      |
P0  -> P1  -> P2  -> NULL

This goes on until the SG list in exhausted. If you use more PaRAM sets,
interrupt handler gets more time to recycle the PaRAM set. At no point
we touch P0 as it is always under active transfer. Thus the peripheral
is always kept busy.

Do you see any reason why such a mechanism cannot be implemented?

Thanks,
Sekhar


From maxime.ripard at free-electrons.com  Wed Jul 31 05:20:43 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 31 Jul 2013 11:20:43 +0200
Subject: [PATCH 1/4] clk: sunxi: Rename the structure to prepare the
 addition of sun6i
In-Reply-To: <51F856D6.2050504@elopez.com.ar>
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375195462-19566-2-git-send-email-maxime.ripard@free-electrons.com>
 <51F856D6.2050504@elopez.com.ar>
Message-ID: <20130731092043.GA2911@lukather>

Hi Emilio,

On Tue, Jul 30, 2013 at 09:14:14PM -0300, Emilio L?pez wrote:
> Hi Maxime,
> 
> El 30/07/13 11:44, Maxime Ripard escribi?:
> > Rename all the generic-named structure to sun4i to avoid confusion when
> > we will introduce the sun6i (A31) clocks.
> > 
> > While we're at it, avoid too long lines and wrap the DT compatibles
> > tables.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> 
> Overall the patch looks good :)
> 
> > ---
> >  drivers/clk/sunxi/clk-sunxi.c | 108 +++++++++++++++++++++++++++++-------------
> >  1 file changed, 75 insertions(+), 33 deletions(-)
> > 
> > diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> > index fe1528e..3c91888 100644
> > --- a/drivers/clk/sunxi/clk-sunxi.c
> > +++ b/drivers/clk/sunxi/clk-sunxi.c
> > @@ -25,12 +25,12 @@
> >  static DEFINE_SPINLOCK(clk_lock);
> >  
> >  /**
> > - * sunxi_osc_clk_setup() - Setup function for gatable oscillator
> > + * sun4i_osc_clk_setup() - Setup function for gatable oscillator
> >   */
> >  
> >  #define SUNXI_OSC24M_GATE	0
> >  
> > -static void __init sunxi_osc_clk_setup(struct device_node *node)
> > +static void __init sun4i_osc_clk_setup(struct device_node *node)
> >  {
> >  	struct clk *clk;
> >  	struct clk_fixed_rate *fixed;
> > @@ -73,13 +73,13 @@ static void __init sunxi_osc_clk_setup(struct device_node *node)
> >  
> >  
> >  /**
> > - * sunxi_get_pll1_factors() - calculates n, k, m, p factors for PLL1
> > + * sun4i_get_pll1_factors() - calculates n, k, m, p factors for PLL1
> >   * PLL1 rate is calculated as follows
> >   * rate = (parent_rate * n * (k + 1) >> p) / (m + 1);
> >   * parent_rate is always 24Mhz
> >   */
> >  
> > -static void sunxi_get_pll1_factors(u32 *freq, u32 parent_rate,
> > +static void sun4i_get_pll1_factors(u32 *freq, u32 parent_rate,
> >  				   u8 *n, u8 *k, u8 *m, u8 *p)
> >  {
> >  	u8 div;
> > @@ -127,12 +127,12 @@ static void sunxi_get_pll1_factors(u32 *freq, u32 parent_rate,
> >  
> >  
> >  /**
> > - * sunxi_get_apb1_factors() - calculates m, p factors for APB1
> > + * sun4i_get_apb1_factors() - calculates m, p factors for APB1
> >   * APB1 rate is calculated as follows
> >   * rate = (parent_rate >> p) / (m + 1);
> >   */
> >  
> > -static void sunxi_get_apb1_factors(u32 *freq, u32 parent_rate,
> > +static void sun4i_get_apb1_factors(u32 *freq, u32 parent_rate,
> >  				   u8 *n, u8 *k, u8 *m, u8 *p)
> >  {
> >  	u8 calcm, calcp;
> > @@ -178,7 +178,7 @@ struct factors_data {
> >  	void (*getter) (u32 *rate, u32 parent_rate, u8 *n, u8 *k, u8 *m, u8 *p);
> >  };
> >  
> > -static struct clk_factors_config pll1_config = {
> > +static struct clk_factors_config sun4i_pll1_config = {
> >  	.nshift = 8,
> >  	.nwidth = 5,
> >  	.kshift = 4,
> > @@ -189,21 +189,21 @@ static struct clk_factors_config pll1_config = {
> >  	.pwidth = 2,
> >  };
> >  
> > -static struct clk_factors_config apb1_config = {
> > +static struct clk_factors_config sun4i_apb1_config = {
> >  	.mshift = 0,
> >  	.mwidth = 5,
> >  	.pshift = 16,
> >  	.pwidth = 2,
> >  };
> >  
> > -static const __initconst struct factors_data pll1_data = {
> > -	.table = &pll1_config,
> > -	.getter = sunxi_get_pll1_factors,
> > +static const __initconst struct factors_data sun4i_pll1_data = {
> > +	.table = &sun4i_pll1_config,
> > +	.getter = sun4i_get_pll1_factors,
> >  };
> >  
> > -static const __initconst struct factors_data apb1_data = {
> > -	.table = &apb1_config,
> > -	.getter = sunxi_get_apb1_factors,
> > +static const __initconst struct factors_data sun4i_apb1_data = {
> > +	.table = &sun4i_apb1_config,
> > +	.getter = sun4i_get_apb1_factors,
> >  };
> >  
> >  static void __init sunxi_factors_clk_setup(struct device_node *node,
> > @@ -239,11 +239,11 @@ struct mux_data {
> >  	u8 shift;
> >  };
> >  
> > -static const __initconst struct mux_data cpu_mux_data = {
> > +static const __initconst struct mux_data sun4i_cpu_mux_data = {
> >  	.shift = 16,
> >  };
> >  
> > -static const __initconst struct mux_data apb1_mux_data = {
> > +static const __initconst struct mux_data sun4i_apb1_mux_data = {
> >  	.shift = 24,
> >  };
> >  
> > @@ -284,17 +284,17 @@ struct div_data {
> >  	u8 pow;
> >  };
> >  
> > -static const __initconst struct div_data axi_data = {
> > +static const __initconst struct div_data sun4i_axi_data = {
> >  	.shift = 0,
> >  	.pow = 0,
> >  };
> >  
> > -static const __initconst struct div_data ahb_data = {
> > +static const __initconst struct div_data sun4i_ahb_data = {
> >  	.shift = 4,
> >  	.pow = 1,
> >  };
> >  
> > -static const __initconst struct div_data apb0_data = {
> > +static const __initconst struct div_data sun4i_apb0_data = {
> >  	.shift = 8,
> >  	.pow = 1,
> >  };
> > @@ -413,35 +413,77 @@ CLK_OF_DECLARE(sunxi_osc, "allwinner,sun4i-osc-clk", sunxi_osc_clk_setup);
> >  
> >  /* Matches for factors clocks */
> >  static const __initconst struct of_device_id clk_factors_match[] = {
> > -	{.compatible = "allwinner,sun4i-pll1-clk", .data = &pll1_data,},
> > -	{.compatible = "allwinner,sun4i-apb1-clk", .data = &apb1_data,},
> > +	{
> > +		.compatible = "allwinner,sun4i-pll1-clk",
> > +		.data = &sun4i_pll1_data,
> > +	},
> > +	{
> > +		.compatible = "allwinner,sun4i-apb1-clk",
> > +		.data = &sun4i_apb1_data,
> > +	},
> >  	{}
> >  };
> >  
> >  /* Matches for divider clocks */
> >  static const __initconst struct of_device_id clk_div_match[] = {
> > -	{.compatible = "allwinner,sun4i-axi-clk", .data = &axi_data,},
> > -	{.compatible = "allwinner,sun4i-ahb-clk", .data = &ahb_data,},
> > -	{.compatible = "allwinner,sun4i-apb0-clk", .data = &apb0_data,},
> > +	{
> > +		.compatible = "allwinner,sun4i-axi-clk",
> > +		.data = &sun4i_axi_data,
> > +	},
> > +	{
> > +		.compatible = "allwinner,sun4i-ahb-clk",
> > +		.data = &sun4i_ahb_data,
> > +	},
> > +	{
> > +		.compatible = "allwinner,sun4i-apb0-clk",
> > +		.data = &sun4i_apb0_data,
> > +	},
> >  	{}
> >  };
> >  
> >  /* Matches for mux clocks */
> >  static const __initconst struct of_device_id clk_mux_match[] = {
> > -	{.compatible = "allwinner,sun4i-cpu-clk", .data = &cpu_mux_data,},
> > -	{.compatible = "allwinner,sun4i-apb1-mux-clk", .data = &apb1_mux_data,},
> > +	{
> > +		.compatible = "allwinner,sun4i-cpu-clk",
> > +		.data = &sun4i_cpu_mux_data,
> > +	},
> > +	{
> > +		.compatible = "allwinner,sun4i-apb1-mux-clk",
> > +		.data = &sun4i_apb1_mux_data,
> > +	},
> >  	{}
> >  };
> >  
> >  /* Matches for gate clocks */
> >  static const __initconst struct of_device_id clk_gates_match[] = {
> > -	{.compatible = "allwinner,sun4i-axi-gates-clk", .data = &sun4i_axi_gates_data,},
> > -	{.compatible = "allwinner,sun4i-ahb-gates-clk", .data = &sun4i_ahb_gates_data,},
> > -	{.compatible = "allwinner,sun5i-a13-ahb-gates-clk", .data = &sun5i_a13_ahb_gates_data,},
> > -	{.compatible = "allwinner,sun4i-apb0-gates-clk", .data = &sun4i_apb0_gates_data,},
> > -	{.compatible = "allwinner,sun5i-a13-apb0-gates-clk", .data = &sun5i_a13_apb0_gates_data,},
> > -	{.compatible = "allwinner,sun4i-apb1-gates-clk", .data = &sun4i_apb1_gates_data,},
> > -	{.compatible = "allwinner,sun5i-a13-apb1-gates-clk", .data = &sun5i_a13_apb1_gates_data,},
> > +	{
> > +		.compatible = "allwinner,sun4i-axi-gates-clk",
> > +		.data = &sun4i_axi_gates_data,
> > +	},
> > +	{
> > +		.compatible = "allwinner,sun4i-ahb-gates-clk",
> > +		.data = &sun4i_ahb_gates_data,
> > +	},
> > +	{
> > +		.compatible = "allwinner,sun5i-a13-ahb-gates-clk",
> > +		.data = &sun5i_a13_ahb_gates_data,
> > +	},
> > +	{
> > +		.compatible = "allwinner,sun4i-apb0-gates-clk",
> > +		.data = &sun4i_apb0_gates_data,
> > +	},
> > +	{
> > +		.compatible = "allwinner,sun5i-a13-apb0-gates-clk",
> > +		.data = &sun5i_a13_apb0_gates_data,
> > +	},
> > +	{
> > +		.compatible = "allwinner,sun4i-apb1-gates-clk",
> > +		.data = &sun4i_apb1_gates_data,
> > +	},
> > +	{
> > +		.compatible = "allwinner,sun5i-a13-apb1-gates-clk",
> > +		.data = &sun5i_a13_apb1_gates_data,
> > +	},
> >  	{}
> >  };
> >  
> 
> I'm not particularly a fan of this though; in my opinion it hurts
> readability a bit and it uses 4x the lines. It looks like a highly
> probable source of git conflicts too if not handled appropriately :)

Yeah, I'll drop it just like for pinctrl then.

> 
> Other than that,
> 
> Reviewed-by: Emilio L?pez <emilio at elopez.com.ar>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130731/a9a2f6a8/attachment-0001.sig>

From daniel.lezcano at linaro.org  Wed Jul 31 05:34:48 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 31 Jul 2013 11:34:48 +0200
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <829dbb20-0f14-4a3b-8da9-1f7b1b5b8b59@DB8EHSMHS005.ehs.local>
References: <51E72DCA.9070500@codeaurora.org>
 <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
 <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
 <51F77D93.4030505@linaro.org>
 <829dbb20-0f14-4a3b-8da9-1f7b1b5b8b59@DB8EHSMHS005.ehs.local>
Message-ID: <51F8DA38.2060508@linaro.org>

On 07/31/2013 12:34 AM, S?ren Brinkmann wrote:
> On Tue, Jul 30, 2013 at 10:47:15AM +0200, Daniel Lezcano wrote:
>> On 07/30/2013 02:03 AM, S?ren Brinkmann wrote:
>>> Hi Daniel,
>>>
>>> On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
>>> (snip)
>>>>
>>>> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
>>>> timer will be stopped when entering to the idle state. In this case, the
>>>> cpuidle framework will call clockevents_notify(ENTER) and switches to a
>>>> broadcast timer and will call clockevents_notify(EXIT) when exiting the
>>>> idle state, switching the local timer back in use.
>>>
>>> I've been thinking about this, trying to understand how this makes my
>>> boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
>>> would make the timer core switch to a broadcast device even though it
>>> wouldn't be necessary. But shouldn't it still work? It sounds like we do
>>> something useless, but nothing wrong in a sense that it should result in
>>> breakage. I guess I'm missing something obvious. This timer system will
>>> always remain a mystery to me.
>>>
>>> Actually this more or less leads to the question: What is this
>>> 'broadcast timer'. I guess that is some clockevent device which is
>>> common to all cores? (that would be the cadence_ttc for Zynq). Is the
>>> hang pointing to some issue with that driver?
>>
>> If you look at the /proc/timer_list, which timer is used for broadcasting ?
> 
> So, the correct run results (full output attached).
> 
> The vanilla kernel uses the twd timers as local timers and the TTC as
> broadcast device:
> 	Tick Device: mode:     1                                                         
> 	Broadcast device  
> 	Clock Event Device: ttc_clockevent
> 
> When I remove the offending CPUIDLE flag and add the DT fragment to
> enable the global timer, the twd timers are still used as local timers
> and the broadcast device is the global timer:
> 	Tick Device: mode:     1                                                         
> 	Broadcast device                                                                 
> 	Clock Event Device: arm_global_timer
> 
> Again, since boot hangs in the actually broken case, I don't see way to
> obtain this information for that case.

Is it possible the global timer driver simply does not work ? So when
the cpuidle driver switches to it, the system stays stuck with no interrupt.

Removing the CPUIDLE_FLAG_TIMER_STOP prevents to use the broadcast timer
(aka arm global timer), so the problem does not appear.

And when the C3STOP feature flag is added to the global timer, this one
can't be a broadcast timer, so another clock is selected for that (I
guess cadence_ttc). So again the problem does not appear.

I am more and more convinced the problem is not coming from the cpuidle
driver. The cpuidle flag has just spotted a problem somewhere else and I
suspect the arm_global_timer is not working for zynq.


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From nsekhar at ti.com  Wed Jul 31 05:35:24 2013
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 31 Jul 2013 15:05:24 +0530
Subject: [PATCH 7/9] ARM: edma: Don't clear EMR of channel in edma_stop
In-Reply-To: <51F89B0B.4080803@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
 <1375104595-16018-8-git-send-email-joelf@ti.com> <51F77982.7030601@ti.com>
 <51F89B0B.4080803@ti.com>
Message-ID: <51F8DA5C.9060503@ti.com>

On Wednesday 31 July 2013 10:35 AM, Joel Fernandes wrote:
> On 07/30/2013 03:29 AM, Sekhar Nori wrote:
>> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>>> We certainly don't want error conditions to be cleared anywhere
>>
>> 'anywhere' is a really loaded term.
>>
>>> as this will make us 'forget' about missed events. We depend on
>>> knowing which events were missed in order to be able to reissue them.
>>
>>> This fixes a race condition where the EMR was being cleared
>>> by the transfer completion interrupt handler.
>>>
>>> Basically, what was happening was:
>>>
>>>             Missed event
>>>              |
>>>              |
>>>              V
>>> SG1-SG2-SG3-Null
>>>          \
>>>           \__TC Interrupt (Almost same time as ARM is executing
>>> TC interrupt handler, an event got missed and also forgotten
>>> by clearing the EMR).
>>
>> Sorry, but I dont see how edma_stop() is coming into picture in the race
>> you describe?
> 
> In edma_callback function, for the case of DMA_COMPLETE (Transfer
> completion interrupt), edma_stop() is called when all sets have been
> processed. This had the effect of clearing the EMR.

Ah, thanks. I was missing the fact that the race comes into picture only
when using the DMA engine driver. I guess that should be mentioned
somewhere since it is not immediately obvious.

The patch looks good to me. So if you respin just this one with some
updated explanation based on what you wrote below, I will take it.

Thanks,
Sekhar



From linux at arm.linux.org.uk  Wed Jul 31 05:40:12 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 31 Jul 2013 10:40:12 +0100
Subject: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit
 mitigations
In-Reply-To: <20130731000444.GC1281@redhat.com>
References: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
 <20130730221435.GA22240@redhat.com>
 <20130730231120.GC30725@blackmetal.musicnaut.iki.fi>
 <20130730231533.GA26824@redhat.com>
 <20130730235834.GD30725@blackmetal.musicnaut.iki.fi>
 <20130731000444.GC1281@redhat.com>
Message-ID: <20130731094012.GU24642@n2100.arm.linux.org.uk>

On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
> To use ARM as an example, the bugs I've seen have mostly been in arch specific
> code that does things like page-table manipulation.  The chromebook bugs I
> was hitting for eg were various kinds of PTE corruption warnings. 

Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
having any changes related to bug reports on PTEs on ARM.


From lorenzo.pieralisi at arm.com  Wed Jul 31 05:41:28 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 31 Jul 2013 10:41:28 +0100
Subject: [PATCH 12/13] ARM: bL_switcher: remove assumptions between
 logical and physical CPUs
In-Reply-To: <alpine.LFD.2.03.1307301502120.15022@syhkavp.arg>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-13-git-send-email-nicolas.pitre@linaro.org>
 <20130730163010.GA8921@e102568-lin.cambridge.arm.com>
 <alpine.LFD.2.03.1307301502120.15022@syhkavp.arg>
Message-ID: <20130731094127.GB6583@e102568-lin.cambridge.arm.com>

On Tue, Jul 30, 2013 at 08:15:02PM +0100, Nicolas Pitre wrote:
> On Tue, 30 Jul 2013, Lorenzo Pieralisi wrote:
> 
> > On Tue, Jul 23, 2013 at 04:31:28AM +0100, Nicolas Pitre wrote:
> > > Up to now, the logical CPU was somehow tied to the physical CPU number
> > > within a cluster.  This causes problems when forcing the boot CPU to be
> > > different from the first enumerated CPU in the device tree creating a
> > > discrepancy between logical and physical CPU numbers.
> > > 
> > > Let's make the pairing completely independent from physical CPU numbers.
> > > 
> > > Let's keep only those logical CPUs with same initial CPU cluster to create
> > > a uniform scheduler profile without having to modify any of the probed
> > > topology and compute capacity data.  This has the potential to create
> > > a non contiguous CPU numbering space when the switcher is active with
> > > potential impact on buggy user space tools.  It is however better to fix
> > > those tools rather than making the switcher code more intrusive.
> > 
> > Nico, I am not following you here. Is this not the same problem we
> > have in a system where we hotplug out some of the CPUs in the logical map ?
> 
> Yes, it is.  Although with the switcher, user space does initialize with 
> holes in the logical CPU map since some CPUs have been hotplugged out 
> before the boot completed which is something some tools are not 
> expecting.  And it did cause problems with Android for example, although 
> that has been fixed now.

Well, fixing them is a good thing to do, as you mentioned, so it is not
your problem.

> > [...]
> > 
> > >  static void bL_switcher_restore_cpus(void)
> > > @@ -319,52 +322,86 @@ static void bL_switcher_restore_cpus(void)
> > >  
> > >  static int bL_switcher_halve_cpus(void)
> > >  {
> > > -	int cpu, cluster, i, ret;
> > > -	cpumask_t cluster_mask[2], common_mask;
> > > -
> > > -	cpumask_clear(&bL_switcher_removed_logical_cpus);
> > > -	cpumask_clear(&cluster_mask[0]);
> > > -	cpumask_clear(&cluster_mask[1]);
> > > +	int i, j, cluster_0, gic_id, ret;
> > > +	unsigned int cpu, cluster, mask;
> > > +	cpumask_t available_cpus;
> > >  
> > > +	/* First pass to validate what we have */
> > > +	mask = 0;
> > >  	for_each_online_cpu(i) {
> > > -		cpu = cpu_logical_map(i) & 0xff;
> > > -		cluster = (cpu_logical_map(i) >> 8) & 0xff;
> > > +		cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 0);
> > > +		cluster = MPIDR_AFFINITY_LEVEL(cpu_logical_map(i), 1);
> > >  		if (cluster >= 2) {
> > >  			pr_err("%s: only dual cluster systems are supported\n", __func__);
> > >  			return -EINVAL;
> > >  		}
> > > -		cpumask_set_cpu(cpu, &cluster_mask[cluster]);
> > > +		if (WARN_ON(cpu >= MAX_CPUS_PER_CLUSTER))
> > 
> > pr_warn ?
> 
> I dunno.  What's the policy for choosing between those two?
> Obviously this is a "shouldn't happen" case.

For sure we have to bail out of there if that's hit, whether you need a
stack dump or not, I do not know, probably we don't, but that's arguable.

> > > +			return -EINVAL;
> > > +		mask |= (1 << cluster);
> > >  	}
> > > -
> > > -	if (!cpumask_and(&common_mask, &cluster_mask[0], &cluster_mask[1])) {
> > > -		pr_err("%s: no common set of CPUs\n", __func__);
> > > +	if (mask != 3) {
> > 
> > Technically, you might have two clusters with eg MPIDR[15:8] = {0,2}
> > this would break this code. Just saying, I know for now we can live with that.
> > Given that's the only usage of mask you might use a counter, just as well.
> 
> Well, there are assumptions about the cluster encoding all over the 
> place, so this is a stop gap to trap anything which is not following the 
> 0,1 enumeration.
> 
> This assumption could be fixed eventually if it turns to e false on some 
> hardware.

Yes, you are absolutely right, for now as I mentioned let's live with this
restriction.

Lorenzo



From finn at uni-bremen.de  Wed Jul 31 05:43:22 2013
From: finn at uni-bremen.de (Finn Hoffmann)
Date: Wed, 31 Jul 2013 11:43:22 +0200
Subject: NSA310 + DT
In-Reply-To: <20130731111414.47e7670b@skate>
References: <20130710073706.GA28212@lunn.ch> <51F6A0DC.3020501@uni-bremen.de>
 <20130729192112.GY29916@titan.lakedaemon.net>
 <20130729204315.GK24782@lunn.ch> <51F78DA6.8010307@uni-bremen.de>
 <20130730144752.GR24782@lunn.ch> <20130730172407.3aab15c6@skate>
 <51F7EBB9.7000504@uni-bremen.de> <20130730191943.49f8070c@skate>
 <20130730183610.GT24782@lunn.ch> <51F814A0.2050403@uni-bremen.de>
 <20130730232316.10dc7019@skate> <20130731111414.47e7670b@skate>
Message-ID: <51F8DC3A.6010007@uni-bremen.de>


Am 31.07.2013 11:14, schrieb Thomas Petazzoni:
> Hello Finn,
>
> On Tue, 30 Jul 2013 23:23:16 +0200, Thomas Petazzoni wrote:
>
>> Thanks for this log. I need a bit of time to analyze this with the
>> PCI-to-PCI bridge specification, and I'll cook up a new patch,
>> hopefully tomorrow.
>>
>> Thanks again a lot for taking the time to report this bug and test the
>> patches,
> Ok, here is another patch that completely disables prefetchable
> support, which hopefully should make the PCI stuff fallback on normal
> memory. Could you try this one, and again report lspci -v + the
> contents of the debugfs file that lists the mbus windows?
>
> I've worked more on the prefetchable support, but doing it right with
> the PCI-to-PCI bridge emulation is a bit complex.
>
> Thanks!
>
> Thomas
>
Hi Thomas,
here you are.
Network is working.
Thanks
Finn


$ lspci -v
00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if 
00 [Normal decode])
         Flags: bus master, fast devsel, latency 0
         Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
         I/O behind bridge: 00010000-00010fff
         Memory behind bridge: e0000000-e00fffff
         Prefetchable memory behind bridge: 00000000-000fffff

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev)
         Subsystem: Realtek Semiconductor Co., Ltd. TEG-ECTX Gigabit 
PCI-E Adapter [Trendnet]
         Flags: bus master, fast devsel, latency 0, IRQ 9
         I/O ports at 10000 [size=256]
         Memory at e0014000 (64-bit, prefetchable) [size=4K]
         Memory at e0010000 (64-bit, prefetchable) [size=16K]
         [virtual] Expansion ROM at e0000000 [disabled] [size=64K]
         Capabilities: <access denied>
         Kernel driver in use: r8169

# cat /sys/kernel/debug/mvebu-mbus/devices
[00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap 0000000000010000)
[01] disabled
[02] disabled
[03] disabled
[04] 00000000f4000000 - 00000000f4010000 : nand
[05] 00000000f5000000 - 00000000f5010000 : sram
[06] 00000000e0000000 - 00000000e0100000 : pcie0.0
[07] disabled

bootlog excerpt:
mvebu-pcie pcie-controller.1: PCIe0.0: link up
mvebu-pcie pcie-controller.1: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus1: Fast back to back transfers disabled
pci 0000:00:01.0: BAR 8: assigned [mem 0xe0000000-0xe00fffff]
pci 0000:00:01.0: BAR 7: assigned [io  0x10000-0x10fff]
pci 0000:01:00.0: BAR 6: assigned [mem 0xe0000000-0xe000ffff pref]
pci 0000:01:00.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref]
pci 0000:01:00.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref]
pci 0000:01:00.0: BAR 0: assigned [io  0x10000-0x100ff]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [io  0x10000-0x10fff]
pci 0000:00:01.0:   bridge window [mem 0xe0000000-0xe00fffff]
PCI: enabling device 0000:00:01.0 (0140 -> 0143)



From linux at arm.linux.org.uk  Wed Jul 31 05:43:53 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 31 Jul 2013 10:43:53 +0100
Subject: [PATCH] ARM: Fix memblock_reserve() to include stext
In-Reply-To: <20130731055807.14054.70106.sendpatchset@w520>
References: <20130731055807.14054.70106.sendpatchset@w520>
Message-ID: <20130731094352.GV24642@n2100.arm.linux.org.uk>

On Wed, Jul 31, 2013 at 02:58:07PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm at opensource.se>
> 
> This fix for the ARM architecture will include stext
> in the memblock_reserve() call to make sure that the
> following symbols are not overwritten (from System.map):
> 
> c0008000 T _text
> c0008000 T stext
> ...
> c0008138 T secondary_startup
> ...
> c0009000 T _stext
> 
> With this patch applied CPU Hotplug starts working
> again. Without this patch code in secondary_startup
> never gets reached as expected.
> 
> This issue started triggering on kernels later than
> v3.10 - perhaps a side effect of the CPU Hotplug init
> section rework - so this is a fix for v3.11-rc.

This is not the right fix.  The commit you previously pointed out (removal
of CPU hotplug) probably means there's a missing annotation somewhere in
the code.

And yes - the __CPUINIT just before ENTRY(secondary_startup) was removed
rather than being replaced with a .text (in both head.S and head-nommu.S).
Same goes for ENTRY(lookup_processor_type) in head-common.S.  All these
need to be replaced with .text to stop them falling into the head section.


From u.kleine-koenig at pengutronix.de  Wed Jul 31 05:44:34 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Wed, 31 Jul 2013 11:44:34 +0200
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731090512.GD9858@sirena.org.uk>
References: <1375232669-27846-1-git-send-email-festevam@gmail.com>
 <1375232669-27846-2-git-send-email-festevam@gmail.com>
 <20130731073306.GZ1754@pengutronix.de>
 <20130731082054.GF8540@nchen-desktop>
 <20130731084645.GB1754@pengutronix.de>
 <20130731090512.GD9858@sirena.org.uk>
Message-ID: <20130731094434.GC1754@pengutronix.de>

[Expanded Cc: a bit]

Hello,

On Wed, Jul 31, 2013 at 10:05:12AM +0100, Mark Brown wrote:
> On Wed, Jul 31, 2013 at 10:46:45AM +0200, Uwe Kleine-K?nig wrote:
We're discussing about devm_request_irq and wonder what happens at
remove time when the irq is still active.

> > OK, so the possible problem is that remove is called while the irq is
> > still active. That means you have to assert that all resources the irq
> > handler is using (e.g. ioremap, clk_prepare_enable) are only freed
> > *after* the irq is done. For ioremap that means it must be done using
> > devm_ioremap_resource. For a clock it's not that easy because the irq
> > handler has to assert that a used clk is kept prepared which can only be
> > done using clk_prepare which in turn is not allowed in an irq handler.
> 
> > Hmm. So the only possible fixes are
> > 	- devm* can be told to also care about clk_disable_unprepare
> > 	- after disabling irqs in the remove callback wait for all
> > 	  active irqs to be done. (i.e. call synchronize_irq(irq))
> > 	- don't use devm_request_irq
> 
> I'm not sure that devm_ guarantees any ordering in the cleanups it does
> so I'd not like to rely on the first option either, if there were some
> guarantee of that it'd help.  The nice thing about explicitly freeing
> the IRQ is that you can tell that all this stuff is safe by inspection.
devm_* at least uses list_for_each_entry_reverse
(drivers/base/devres.c:release_nodes()). Without this guarantee devm_
would not make much sense IMHO.

To also manage clks, we'd need something like:

	devm_clk_prepare(&dev, some_clk);

that makes devm_clk_release also call clk_unprepare the right number of
times. Maybe also the same for devm_clk_enable? Does this make sense?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From t-kristo at ti.com  Wed Jul 31 05:46:32 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 12:46:32 +0300
Subject: [PATCHv4 03/33] CLK: OMAP4: Add DPLL clock support
In-Reply-To: <51F7E883.7000000@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-4-git-send-email-t-kristo@ti.com> <51F7E883.7000000@ti.com>
Message-ID: <51F8DCF8.2040309@ti.com>

On 07/30/2013 07:23 PM, Nishanth Menon wrote:
> This patch probably was submitted in the wrong sequence - fails build
> and few other issues below.

Yeah, I'll double check the build sequence for these.

>
> On 07/23/2013 02:19 AM, Tero Kristo wrote:
>> The OMAP clock driver now supports DPLL clock type. This patch also
>> adds support for DT DPLL nodes.
>
> Then why is $subject specific to OMAP4? is that because of
> of_omap4_dpll_setup?

The driver only supports omap4 dpll type at this point, omap3 dplls 
require some modifications on top of this, and are provided later in the 
series.

>
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> ---
>>   drivers/clk/omap/Makefile |    2 +-
>>   drivers/clk/omap/clk.c    |    1 +
>>   drivers/clk/omap/dpll.c   |  295
>> +++++++++++++++++++++++++++++++++++++++++++++
>
> Device Tree Binding documentation?

Didn't bother writing those yet as I haven't received too much feedback 
whether this approach is acceptable or not.

>
>>   3 files changed, 297 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/clk/omap/dpll.c
>>
>> diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
>> index 8195931..4cad480 100644
>> --- a/drivers/clk/omap/Makefile
>> +++ b/drivers/clk/omap/Makefile
>> @@ -1 +1 @@
>> -obj-y                    += clk.o
>> +obj-y                    += clk.o dpll.o
>> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
>> index 4bf1929..1dafdaa 100644
>> --- a/drivers/clk/omap/clk.c
>> +++ b/drivers/clk/omap/clk.c
>> @@ -28,6 +28,7 @@ static const struct of_device_id clk_match[] = {
>>           .data = of_fixed_factor_clk_setup, },
>>       {.compatible = "divider-clock", .data = of_divider_clk_setup, },
>>       {.compatible = "gate-clock", .data = of_gate_clk_setup, },
>> +    {.compatible = "ti,omap4-dpll-clock", .data =
>> of_omap4_dpll_setup, },
>>       {},
>>   };
> you would not need this if you did just of_clk_init(NULL); ?

Why not? And I think we still need to do this.

>
> Further, at this patch, build fails with:
> drivers/clk/omap/clk.c:31:55: error: undefined identifier
> 'of_omap4_dpll_setup'
> drivers/clk/omap/clk.c:31:48: error: ?of_omap4_dpll_setup? undeclared
> here (not in a function)
>
> which makes sense since we did not export the function.

Yea seems like wrong ordering of patches, sorry about that. >.<

>>
>> diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
>> new file mode 100644
>> index 0000000..66e82be
>> --- /dev/null
>> +++ b/drivers/clk/omap/dpll.c
>> @@ -0,0 +1,295 @@
>> +/*
>> + * OMAP DPLL clock support
>> + *
>> + * Copyright (C) 2013 Texas Instruments, Inc.
>> + *
>> + * Tero Kristo <t-kristo at ti.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/clk-provider.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/io.h>
>> +#include <linux/err.h>
>> +#include <linux/string.h>
>> +#include <linux/log2.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
> after a quick check, are all these required?

Seems like some might not be needed, I'll double check this.

>
>> +#include <linux/clk/omap.h>
>
> why?

Need dpll_data definition for example.

>
>> +
>> +static const struct clk_ops dpll_m4xen_ck_ops = {
>> +    .enable        = &omap3_noncore_dpll_enable,
>> +    .disable    = &omap3_noncore_dpll_disable,
>> +    .recalc_rate    = &omap4_dpll_regm4xen_recalc,
>> +    .round_rate    = &omap4_dpll_regm4xen_round_rate,
>> +    .set_rate    = &omap3_noncore_dpll_set_rate,
>> +    .get_parent    = &omap2_init_dpll_parent,
>> +};
>> +
>> +static const struct clk_ops dpll_core_ck_ops = {
>> +    .recalc_rate    = &omap3_dpll_recalc,
>> +    .get_parent    = &omap2_init_dpll_parent,
>> +};
>> +
>> +static const struct clk_ops dpll_ck_ops = {
>> +    .enable        = &omap3_noncore_dpll_enable,
>> +    .disable    = &omap3_noncore_dpll_disable,
>> +    .recalc_rate    = &omap3_dpll_recalc,
>> +    .round_rate    = &omap2_dpll_round_rate,
>> +    .set_rate    = &omap3_noncore_dpll_set_rate,
>> +    .get_parent    = &omap2_init_dpll_parent,
>> +    .init        = &omap2_init_clk_clkdm,
>> +};
>> +
>> +static const struct clk_ops dpll_x2_ck_ops = {
>> +    .recalc_rate    = &omap3_clkoutx2_recalc,
>> +};
>
> none of these are defined at this stage of the patch, generates a huge
> build error for dpll.c
> http://pastebin.com/GJucv1A5

Yea, wrong ordering, linux/clk/omap.h is not up to date. I'll fix this 
and rest of the similar issues.

>> +
>> +struct clk *omap_clk_register_dpll(struct device *dev, const char *name,
>> +        const char **parent_names, int num_parents, unsigned long flags,
>> +        struct dpll_data *dpll_data, const char *clkdm_name,
>> +        const struct clk_ops *ops)
>
> why should this be public?

Currently does not need to be, but someone could in theory build up 
cclockXxxx_data.c file and use these calls from there. Kind of legacy 
support, see some of the basic clk types. I guess I can add static to 
this, and remove some of the params along.

>
>> +{
>> +    struct clk *clk;
>> +    struct clk_init_data init;
>
> init = { 0 };  just to future proof?

Good idea, i'll add this.

>
>> +    struct clk_hw_omap *clk_hw;
>
> does not exist yet in generic header?

Yea.

>
> I am assuming you do not do parameter check as you expect clk_register
> to do the same?

True, so I'll change the above function to static.

>
>> +
>> +    /* allocate the divider */
>> +    clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
> checkpatch complained:
> CHECK: Prefer kzalloc(sizeof(*clk_hw)...) over kzalloc(sizeof(struct
> clk_hw_omap)...)

Hmm, I didn't get this with checkpatch. Some special option/version you 
use? I still see both types of sizeof used in the kernel.

>
> or given we have dev, devm_kzalloc?

Actually we don't have dev, check how this is called from below.

>> +    if (!clk_hw) {
>> +        pr_err("%s: could not allocate clk_hw_omap\n", __func__);
>> +        return ERR_PTR(-ENOMEM);
>> +    }
>> +
>> +    clk_hw->dpll_data = dpll_data;
>> +    clk_hw->ops = &clkhwops_omap3_dpll;
>> +    clk_hw->clkdm_name = clkdm_name;
>> +    clk_hw->hw.init = &init;
>> +
>> +    init.name = name;
>> +    init.ops = ops;
>> +    init.flags = flags;
>> +    init.parent_names = parent_names;
>> +    init.num_parents = num_parents;
>> +
>> +    /* register the clock */
>> +    clk = clk_register(dev, &clk_hw->hw);
>> +
>> +    if (IS_ERR(clk))
>> +        kfree(clk_hw);
>> +    else
>> +        omap2_init_clk_hw_omap_clocks(clk);
> what if init fails? and it is in mach-omap2 at this point in time?

Yea, this just calls the autoidle init part under mach-omap2.

>
>> +
>> +    return clk;
>> +}
>> +
>> +struct clk *omap_clk_register_dpll_x2(struct device *dev, const char
>> *name,
>> +        const char *parent_name, void __iomem *reg,
>> +        const struct clk_ops *ops)
>
> same question here as well

Yea, can change to static I think.

>
>> +{
>> +    struct clk *clk;
>> +    struct clk_init_data init;
>> +    struct clk_hw_omap *clk_hw;
>> +
>> +    if (!parent_name) {
>> +        pr_err("%s: dpll_x2 must have parent\n", __func__);
>> +        return ERR_PTR(-EINVAL);
>> +    }
>> +
>> +    clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
> checkpatch complained:
> CHECK: Prefer kzalloc(sizeof(*clk_hw)...) over kzalloc(sizeof(struct
> clk_hw_omap)...)
>
> or devm_kzalloc?

Same as above.

>
>> +    if (!clk_hw) {
>> +        pr_err("%s: could not allocate clk_hw_omap\n", __func__);
>> +        return ERR_PTR(-ENOMEM);
>> +    }
>> +
>> +    clk_hw->ops = &clkhwops_omap4_dpllmx;
>> +    clk_hw->clksel_reg = reg;
>> +    clk_hw->hw.init = &init;
>> +
>> +    init.name = name;
>> +    init.ops = ops;
>> +    init.parent_names = &parent_name;
>> +    init.num_parents = 1;
>> +
>> +    /* register the clock */
>> +    clk = clk_register(dev, &clk_hw->hw);
>> +
>> +    if (IS_ERR(clk))
>> +        kfree(clk_hw);
>> +    else
>> +        omap2_init_clk_hw_omap_clocks(clk);
>> +
>> +    return clk;
>> +}
> this vaguely sounds like a replica of omap_clk_register_dpll with
> num_parents and clk_hw->ops different. why not merge the two?

Some of the params are different but yes, I'll see if I can merge the two.

>
>> +
>> +#ifdef CONFIG_OF
>
> why not build the entire thing *iff* CONFIG_OF (Makefile/Kconfig dep)?
> that way, we can drop this #ifdef stuff from drivers that dont need to
> have dual support.

Yea, I guess I can do this.

>
>> +
>> +/**
>> + * of_omap_dpll_setup() - Setup function for OMAP DPLL clocks
>
> node and ops not documented.

I'll add some beef here.

>
>> + */
>> +static void __init of_omap_dpll_setup(struct device_node *node,
>> +                    const struct clk_ops *ops)
>> +{
>> +    struct clk *clk;
>> +    const char *clk_name = node->name;
>> +    int num_parents;
>> +    const char **parent_names;
>> +    const char *clkdm_name = NULL;
>> +    struct of_phandle_args clkspec;
>> +    u8 dpll_flags = 0;
>> +    struct dpll_data *dd;
>> +    u32 idlest_mask = 0x1;
>> +    u32 enable_mask = 0x7;
>> +    u32 autoidle_mask = 0x7;
>> +    u32 mult_mask = 0x7ff << 8;
>> +    u32 div1_mask = 0x7f;
>> +    u32 max_multiplier = 2047;
>> +    u32 max_divider = 128;
>> +    u32 min_divider = 1;
>> +    int i;
>> +
>> +    dd = kzalloc(sizeof(struct dpll_data), GFP_KERNEL);
> kzalloc sizeof(*dd) ?

See above.

>
>> +    if (!dd) {
>> +        pr_err("%s: could not allocate dpll_data\n", __func__);
>> +        return;
>> +    }
>> +
>> +    of_property_read_string(node, "clock-output-names", &clk_name);
>> +
>> +    num_parents = of_clk_get_parent_count(node);
>> +    if (num_parents < 1) {
>> +        pr_err("%s: omap dpll %s must have parent(s)\n",
>> +            __func__, node->name);
>
> checkpatch complained:
> CHECK: Alignment should match open parenthesis
> #212: FILE: drivers/clk/omap/dpll.c:171:
> After applying the patch, I think you should make __func__ aligned with
> " and not %

Again, what version of checkpatch you use? Or what flags?

>
>> +        goto cleanup;
>> +    }
>> +
>> +    parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
>> +
>> +    for (i = 0; i < num_parents; i++)
>> +        parent_names[i] = of_clk_get_parent_name(node, i);
>> +
>> +    of_property_read_u32(node, "ti,idlest-mask", &idlest_mask);
>> +
>> +    of_property_read_u32(node, "ti,enable-mask", &enable_mask);
>> +
>> +    of_property_read_u32(node, "ti,autoidle-mask", &autoidle_mask);
>
> are these going to be different? or can we catch with compatible flag?

For example, omap3 dpll4:

dpll4_ck: dpll4_ck at 48004d00 {
         ti,autoidle-mask = <0x38>;
         ti,idlest-mask = <0x2>;
         ti,enable-mask = <0x70000>;
};

It seems that currently we can catch all cases with the 
ti,dpll-peripheral flag. I'll modify the code accordingly.


>
>> +
>> +    clkspec.np = of_parse_phandle(node, "ti,clk-ref", 0);
>> +    dd->clk_ref = of_clk_get_from_provider(&clkspec);
>> +    if (!dd->clk_ref) {
>> +        pr_err("%s: ti,clk-ref for %s not found\n", __func__,
>> +            clk_name);
>
> CHECK: Alignment should match open parenthesis
> #231: FILE: drivers/clk/omap/dpll.c:190:
> similar issue here.
>
>> +        goto cleanup;
>> +    }
>> +
>> +    clkspec.np = of_parse_phandle(node, "ti,clk-bypass", 0);
>> +    dd->clk_bypass = of_clk_get_from_provider(&clkspec);
>> +    if (!dd->clk_bypass) {
>> +        pr_err("%s: ti,clk-bypass for %s not found\n", __func__,
>> +            clk_name);
>
> here as well
>
>> +        goto cleanup;
>> +    }
>> +
>> +    of_property_read_string(node, "ti,clkdm-name", &clkdm_name);
>> +
>> +    dd->control_reg = of_iomap(node, 0);
>> +    dd->idlest_reg = of_iomap(node, 1);
>> +    dd->autoidle_reg = of_iomap(node, 2);
>> +    dd->mult_div1_reg = of_iomap(node, 3);
>
> if dts has errors, should we not verify mandatory parameters?
>
>> +
>> +    dd->idlest_mask = idlest_mask;
>> +    dd->enable_mask = enable_mask;
>> +    dd->autoidle_mask = autoidle_mask;
>> +
>> +    dd->modes = 0xa0;
>
> what is 0xa0?

Magic mode. :) I'll copy paste a macro for this.

>
>> +
>> +    if (of_property_read_bool(node, "ti,dpll-j-type")) {
>> +        dd->sddiv_mask = 0xff000000;
>> +        mult_mask = 0xfff << 8;
>> +        div1_mask = 0xff;
>> +        max_multiplier = 4095;
>> +        max_divider = 256;
>> +    }
>> +
>> +    if (of_property_read_bool(node, "ti,dpll-regm4xen")) {
> I think we need bindings to understand this better.

Or documentation you mean?

>
>> +        dd->m4xen_mask = 0x800;
>> +        dd->lpmode_mask = 1 << 10;
>> +    }
>> +
>> +    dd->mult_mask = mult_mask;
>> +    dd->div1_mask = div1_mask;
>> +    dd->max_multiplier = max_multiplier;
>> +    dd->max_divider = max_divider;
>> +    dd->min_divider = min_divider;
>> +
>> +    clk = omap_clk_register_dpll(NULL, clk_name, parent_names,
>> +                num_parents, dpll_flags, dd,
>> +                clkdm_name, ops);
>> +
>> +    if (!IS_ERR(clk))
>> +        of_clk_add_provider(node, of_clk_src_simple_get, clk);
> error check?

This is not done with other drivers either. Would require clk_unregister 
use to cleanup the above register call which is currently unavailable. I 
could add an error trace for this though.

>> +    return;
>> +
>> +cleanup:
>
> kfree(parent_names) ?

Hmm yea.

>
>> +    kfree(dd);
>> +    return;
>> +}
>> +
>> +static void __init of_omap_dpll_x2_setup(struct device_node *node)
>> +{
>> +    struct clk *clk;
>> +    const char *clk_name = node->name;
>> +    void __iomem *reg;
>> +    const char *parent_name;
>> +
>> +    of_property_read_string(node, "clock-output-names", &clk_name);
>> +
>> +    parent_name = of_clk_get_parent_name(node, 0);
>> +
>> +    reg = of_iomap(node, 0);
>
> if dts has errors, should we not verify mandatory parameters?

You mean checking the validity of this pointer? It seems of_iomap does 
something strange when it fails, e.g. when passed a 0x0 from DT. You can 
see what I do in a later patch for adding am335x support for DPLLs.

>
>> +
>> +    clk = omap_clk_register_dpll_x2(NULL, clk_name, parent_name,
>> +                reg, &dpll_x2_ck_ops);
>> +
>> +    if (!IS_ERR(clk))
>> +        of_clk_add_provider(node, of_clk_src_simple_get, clk);
> error check?
>
> gentle request - in this setup function we dont see a return of error
> value (which makes sense), but more importantly - log saying that node
> was not setup

Yea, I can add error prints.

>
>> +}
>> +
>> +__init void of_omap3_dpll_setup(struct device_node *node)
>
> ^^ void __init? further, you could make this static.

Ok.

>
>> +{
>> +    /* XXX: to be done */
>> +}
>> +EXPORT_SYMBOL_GPL(of_omap3_dpll_setup);
>
> you can drop the export if you use of_clk_init(NULL);

Same comment as earlier.

>
>> +CLK_OF_DECLARE(omap3_dpll_clock, "ti,omap3-dpll-clock",
>> of_omap3_dpll_setup);
>> +
>> +__init void of_omap4_dpll_setup(struct device_node *node)
>
> ^^ void __init? further, you could make this static.

Ok.

>
>> +{
>> +    const struct clk_ops *ops;
>> +
>> +    ops = &dpll_ck_ops;
>> +
>> +    if (of_property_read_bool(node, "ti,dpll-regm4xen"))
>> +        ops = &dpll_m4xen_ck_ops;
>> +
>> +    if (of_property_read_bool(node, "ti,dpll-core"))
>> +        ops = &dpll_core_ck_ops;
>> +
>> +    if (of_property_read_bool(node, "ti,dpll-clk-x2")) {
>> +        of_omap_dpll_x2_setup(node);
>> +        return;
>> +    }
>> +
>> +    of_omap_dpll_setup(node, ops);
>> +}
>> +EXPORT_SYMBOL_GPL(of_omap4_dpll_setup);
>
> you can drop the export if you use of_clk_init(NULL);

Hmm no?

Actually dug this further, I think the init setup is slightly wrong at 
the moment, we should not do CLK_OF_DECLARE at all within the omap 
specific clock drivers, but instead just use the match table from clk.c. 
I'll change it like so.

>
>> +CLK_OF_DECLARE(omap4_dpll_clock, "ti,omap4-dpll-clock",
>> of_omap4_dpll_setup);

So, for example this should be removed. We don't want to support this 
clock type on non-omap platforms just to avoid problems.

>> +#endif
>>



From thomas.petazzoni at free-electrons.com  Wed Jul 31 05:51:08 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 31 Jul 2013 11:51:08 +0200
Subject: NSA310 + DT
In-Reply-To: <51F8DC3A.6010007@uni-bremen.de>
References: <20130710073706.GA28212@lunn.ch> <51F6A0DC.3020501@uni-bremen.de>
 <20130729192112.GY29916@titan.lakedaemon.net>
 <20130729204315.GK24782@lunn.ch> <51F78DA6.8010307@uni-bremen.de>
 <20130730144752.GR24782@lunn.ch> <20130730172407.3aab15c6@skate>
 <51F7EBB9.7000504@uni-bremen.de> <20130730191943.49f8070c@skate>
 <20130730183610.GT24782@lunn.ch> <51F814A0.2050403@uni-bremen.de>
 <20130730232316.10dc7019@skate> <20130731111414.47e7670b@skate>
 <51F8DC3A.6010007@uni-bremen.de>
Message-ID: <20130731115108.21c043fd@skate>

Dear Finn Hoffmann,

On Wed, 31 Jul 2013 11:43:22 +0200, Finn Hoffmann wrote:

> Hi Thomas,
> here you are.
> Network is working.

Excellent, thanks!

> # cat /sys/kernel/debug/mvebu-mbus/devices
> [00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap
> 0000000000010000) [01] disabled
> [02] disabled
> [03] disabled
> [04] 00000000f4000000 - 00000000f4010000 : nand
> [05] 00000000f5000000 - 00000000f5010000 : sram
> [06] 00000000e0000000 - 00000000e0100000 : pcie0.0
> [07] disabled

Now this looks good, we have both the PCIe memory and PCIe I/O windows
created.

I'll clean up the patch and send it, hopefully for the final 3.11.

Thanks again for all your testing!

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From htejun at gmail.com  Wed Jul 31 05:54:11 2013
From: htejun at gmail.com (Tejun Heo)
Date: Wed, 31 Jul 2013 05:54:11 -0400
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731094434.GC1754@pengutronix.de>
References: <1375232669-27846-1-git-send-email-festevam@gmail.com>
 <1375232669-27846-2-git-send-email-festevam@gmail.com>
 <20130731073306.GZ1754@pengutronix.de>
 <20130731082054.GF8540@nchen-desktop>
 <20130731084645.GB1754@pengutronix.de>
 <20130731090512.GD9858@sirena.org.uk>
 <20130731094434.GC1754@pengutronix.de>
Message-ID: <20130731095411.GA2810@htj.dyndns.org>

Hello,

On Wed, Jul 31, 2013 at 11:44:34AM +0200, Uwe Kleine-K?nig wrote:
> > > OK, so the possible problem is that remove is called while the irq is
> > > still active. That means you have to assert that all resources the irq

If your driver destruction path is running while your irq handler is
still running, it's a crappy / broken driver.  You need a deactivation
step whether you're using devm or not.  IRQs can be shared and the
device should be in a quiesced state before the driver detaches
itself.  Note that you can queue deactivation routine using devm.  For
an example, please take a look at
drivers/ata/libata-core.c::ata_host_start().

> > > handler is using (e.g. ioremap, clk_prepare_enable) are only freed
> > > *after* the irq is done. For ioremap that means it must be done using
> > > devm_ioremap_resource. For a clock it's not that easy because the irq
> > > handler has to assert that a used clk is kept prepared which can only be
> > > done using clk_prepare which in turn is not allowed in an irq handler.
> > 
> > > Hmm. So the only possible fixes are
> > > 	- devm* can be told to also care about clk_disable_unprepare
> > > 	- after disabling irqs in the remove callback wait for all
> > > 	  active irqs to be done. (i.e. call synchronize_irq(irq))
> > > 	- don't use devm_request_irq

Again, the right thing to do is having a proper deactivation step.
This is nothing devm can do automatically.  There's no way for it to
find out that the device is actually quiesced.  Let's say it waits for
the current instance of irq handler to finish.  How would it know that
it won't start again between the flushing of the current instance and
irq deregistration.  Add an explicit deactivation step using
devres_alloc().

> > I'm not sure that devm_ guarantees any ordering in the cleanups it does
> > so I'd not like to rely on the first option either, if there were some
> > guarantee of that it'd help.  The nice thing about explicitly freeing
> > the IRQ is that you can tell that all this stuff is safe by inspection.
> devm_* at least uses list_for_each_entry_reverse
> (drivers/base/devres.c:release_nodes()). Without this guarantee devm_
> would not make much sense IMHO.

devm guarantees that the destruction callbacks are called in the
reverse order of registration.

Thanks.

-- 
tejun


From t-kristo at ti.com  Wed Jul 31 05:59:42 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 12:59:42 +0300
Subject: [PATCHv4 04/33] CLK: omap: move part of the machine specific
 clock header contents to driver
In-Reply-To: <51F8045C.6020603@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-5-git-send-email-t-kristo@ti.com> <51F8045C.6020603@ti.com>
Message-ID: <51F8E00E.7070506@ti.com>

On 07/30/2013 09:22 PM, Nishanth Menon wrote:
> this patch should be 3/33 to allow dpll.c to build.
>
> On 07/23/2013 02:19 AM, Tero Kristo wrote:
>> Some of the clock.h contents are needed by the new OMAP clock driver,
>> including dpll_data and clk_hw_omap. Thus, move these to the generic
>> omap header file which can be accessed by the driver.
>>
> Looking at the change, I wonder what the rules are for the movement?
> commit message was not clear.

This is kind of a merge of almost everything that is needed by clock 
drivers at some point. I can move the changes along to the patches that 
actually need the exports for clarity and to keep compilation clean.

>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> ---
>>   arch/arm/mach-omap2/clock.h |  151
>> +----------------------------------------
>>   include/linux/clk/omap.h    |  157
>> ++++++++++++++++++++++++++++++++++++++++++-
>>   2 files changed, 157 insertions(+), 151 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
>> index 7aa32cd..d1a3125 100644
>> --- a/arch/arm/mach-omap2/clock.h
>> +++ b/arch/arm/mach-omap2/clock.h
>> @@ -21,6 +21,7 @@
>>
>>   #include <linux/clkdev.h>
>>   #include <linux/clk-provider.h>
>> +#include <linux/clk/omap.h>
>>
>>   struct omap_clk {
>>       u16                cpu;
>> @@ -178,83 +179,6 @@ struct clksel {
>>       const struct clksel_rate *rates;
>>   };
>>
>> -/**
>> - * struct dpll_data - DPLL registers and integration data
>> - * @mult_div1_reg: register containing the DPLL M and N bitfields
>> - * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg
>> - * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg
>> - * @clk_bypass: struct clk pointer to the clock's bypass clock input
>> - * @clk_ref: struct clk pointer to the clock's reference clock input
>> - * @control_reg: register containing the DPLL mode bitfield
>> - * @enable_mask: mask of the DPLL mode bitfield in @control_reg
>> - * @last_rounded_rate: cache of the last rate result of
>> omap2_dpll_round_rate()
>> - * @last_rounded_m: cache of the last M result of
>> omap2_dpll_round_rate()
>> - * @last_rounded_m4xen: cache of the last M4X result of
>> - *            omap4_dpll_regm4xen_round_rate()
>> - * @last_rounded_lpmode: cache of the last lpmode result of
>> - *             omap4_dpll_lpmode_recalc()
>> - * @max_multiplier: maximum valid non-bypass multiplier value (actual)
>> - * @last_rounded_n: cache of the last N result of
>> omap2_dpll_round_rate()
>> - * @min_divider: minimum valid non-bypass divider value (actual)
>> - * @max_divider: maximum valid non-bypass divider value (actual)
>> - * @modes: possible values of @enable_mask
>> - * @autoidle_reg: register containing the DPLL autoidle mode bitfield
>> - * @idlest_reg: register containing the DPLL idle status bitfield
>> - * @autoidle_mask: mask of the DPLL autoidle mode bitfield in
>> @autoidle_reg
>> - * @freqsel_mask: mask of the DPLL jitter correction bitfield in
>> @control_reg
>> - * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg
>> - * @lpmode_mask: mask of the DPLL low-power mode bitfield in
>> @control_reg
>> - * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg
>> - * @auto_recal_bit: bitshift of the driftguard enable bit in
>> @control_reg
>> - * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for
>> recalibration IRQs
>> - * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for
>> recalibration IRQs
>> - * @flags: DPLL type/features (see below)
>> - *
>> - * Possible values for @flags:
>> - * DPLL_J_TYPE: "J-type DPLL" (only some 36xx, 4xxx DPLLs)
>> - *
>> - * @freqsel_mask is only used on the OMAP34xx family and AM35xx.
>> - *
>> - * XXX Some DPLLs have multiple bypass inputs, so it's not technically
>> - * correct to only have one @clk_bypass pointer.
>> - *
>> - * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m,
>> - * @last_rounded_n) should be separated from the runtime-fixed fields
>> - * and placed into a different structure, so that the runtime-fixed data
>> - * can be placed into read-only space.
>> - */
>> -struct dpll_data {
>> -    void __iomem        *mult_div1_reg;
>> -    u32            mult_mask;
>> -    u32            div1_mask;
>> -    struct clk        *clk_bypass;
>> -    struct clk        *clk_ref;
>> -    void __iomem        *control_reg;
>> -    u32            enable_mask;
>> -    unsigned long        last_rounded_rate;
>> -    u16            last_rounded_m;
>> -    u8            last_rounded_m4xen;
>> -    u8            last_rounded_lpmode;
>> -    u16            max_multiplier;
>> -    u8            last_rounded_n;
>> -    u8            min_divider;
>> -    u16            max_divider;
>> -    u8            modes;
>> -    void __iomem        *autoidle_reg;
>> -    void __iomem        *idlest_reg;
>> -    u32            autoidle_mask;
>> -    u32            freqsel_mask;
>> -    u32            idlest_mask;
>> -    u32            dco_mask;
>> -    u32            sddiv_mask;
>> -    u32            lpmode_mask;
>> -    u32            m4xen_mask;
>> -    u8            auto_recal_bit;
>> -    u8            recal_en_bit;
>> -    u8            recal_st_bit;
>> -    u8            flags;
>> -};
>> -
>>   /*
>>    * struct clk.flags possibilities
>>    *
>> @@ -274,56 +198,6 @@ struct dpll_data {
>>   #define INVERT_ENABLE        (1 << 4)    /* 0 enables, 1 disables */
>>   #define CLOCK_CLKOUTX2        (1 << 5)
>>
>> -/**
>> - * struct clk_hw_omap - OMAP struct clk
>> - * @node: list_head connecting this clock into the full clock list
>> - * @enable_reg: register to write to enable the clock (see @enable_bit)
>> - * @enable_bit: bitshift to write to enable/disable the clock (see
>> @enable_reg)
>> - * @flags: see "struct clk.flags possibilities" above
>> - * @clksel_reg: for clksel clks, register va containing src/divisor
>> select
>> - * @clksel_mask: bitmask in @clksel_reg for the src/divisor selector
>> - * @clksel: for clksel clks, pointer to struct clksel for this clock
>> - * @dpll_data: for DPLLs, pointer to struct dpll_data for this clock
>> - * @clkdm_name: clockdomain name that this clock is contained in
>> - * @clkdm: pointer to struct clockdomain, resolved from @clkdm_name
>> at runtime
>> - * @rate_offset: bitshift for rate selection bitfield (OMAP1 only)
>> - * @src_offset: bitshift for source selection bitfield (OMAP1 only)
>> - *
>> - * XXX @rate_offset, @src_offset should probably be removed and OMAP1
>> - * clock code converted to use clksel.
>> - *
>> - */
>> -
>> -struct clk_hw_omap_ops;
>> -
>> -struct clk_hw_omap {
>> -    struct clk_hw        hw;
>> -    struct list_head    node;
>> -    unsigned long        fixed_rate;
>> -    u8            fixed_div;
>> -    void __iomem        *enable_reg;
>> -    u8            enable_bit;
>> -    u8            flags;
>> -    void __iomem        *clksel_reg;
>> -    u32            clksel_mask;
>> -    const struct clksel    *clksel;
>> -    struct dpll_data    *dpll_data;
>> -    const char        *clkdm_name;
>> -    struct clockdomain    *clkdm;
>> -    const struct clk_hw_omap_ops    *ops;
>> -};
>> -
>> -struct clk_hw_omap_ops {
>> -    void            (*find_idlest)(struct clk_hw_omap *oclk,
>> -                    void __iomem **idlest_reg,
>> -                    u8 *idlest_bit, u8 *idlest_val);
>> -    void            (*find_companion)(struct clk_hw_omap *oclk,
>> -                    void __iomem **other_reg,
>> -                    u8 *other_bit);
>> -    void            (*allow_idle)(struct clk_hw_omap *oclk);
>> -    void            (*deny_idle)(struct clk_hw_omap *oclk);
>> -};
>> -
>>   unsigned long omap_fixed_divisor_recalc(struct clk_hw *hw,
>>                       unsigned long parent_rate);
>>
>> @@ -356,28 +230,13 @@ unsigned long omap_fixed_divisor_recalc(struct
>> clk_hw *hw,
>>   /* DPLL Type and DCO Selection Flags */
>>   #define DPLL_J_TYPE        0x1
>>
>> -long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
>> -            unsigned long *parent_rate);
>> -unsigned long omap3_dpll_recalc(struct clk_hw *hw, unsigned long
>> parent_rate);
>> -int omap3_noncore_dpll_enable(struct clk_hw *hw);
>> -void omap3_noncore_dpll_disable(struct clk_hw *hw);
>> -int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned long rate,
>> -                unsigned long parent_rate);
>
> Why are these being moved to generic?

These are used from the dpll.c by the ops.

>
>>   u32 omap3_dpll_autoidle_read(struct clk_hw_omap *clk);
>>   void omap3_dpll_allow_idle(struct clk_hw_omap *clk);
>>   void omap3_dpll_deny_idle(struct clk_hw_omap *clk);
>
>> -unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
>> -                    unsigned long parent_rate);
> why move this?

Same, anyway, I'll cover the rest of similar comments by moving them 
along with the patch that actually needs the export.


>
>>   int omap4_dpllmx_gatectrl_read(struct clk_hw_omap *clk);
>>   void omap4_dpllmx_allow_gatectrl(struct clk_hw_omap *clk);
>>   void omap4_dpllmx_deny_gatectrl(struct clk_hw_omap *clk);
>> -unsigned long omap4_dpll_regm4xen_recalc(struct clk_hw *hw,
>> -                unsigned long parent_rate);
>> -long omap4_dpll_regm4xen_round_rate(struct clk_hw *hw,
>> -                    unsigned long target_rate,
>> -                    unsigned long *parent_rate);
> same here.
>
>>
>> -void omap2_init_clk_clkdm(struct clk_hw *clk);
> same question again.
>
>>   void __init omap2_clk_disable_clkdm_control(void);
>>
>>   /* clkt_clksel.c public functions */
>> @@ -396,7 +255,6 @@ int omap2_clksel_set_parent(struct clk_hw *hw, u8
>> field_val);
>>   extern void omap2_clkt_iclk_allow_idle(struct clk_hw_omap *clk);
>>   extern void omap2_clkt_iclk_deny_idle(struct clk_hw_omap *clk);
>>
>> -u8 omap2_init_dpll_parent(struct clk_hw *hw);
> why move this?
>
>>   unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk);
>>
>>   int omap2_dflt_clk_enable(struct clk_hw *hw);
>> @@ -408,9 +266,7 @@ void omap2_clk_dflt_find_companion(struct
>> clk_hw_omap *clk,
>>   void omap2_clk_dflt_find_idlest(struct clk_hw_omap *clk,
>>                   void __iomem **idlest_reg,
>>                   u8 *idlest_bit, u8 *idlest_val);
>> -void omap2_init_clk_hw_omap_clocks(struct clk *clk);
> why move this?
>
>>   int omap2_clk_enable_autoidle_all(void);
>> -int omap2_clk_disable_autoidle_all(void);
> why move this?
>
>>   void omap2_clk_enable_init_clocks(const char **clk_names, u8
>> num_clocks);
>>   int omap2_clk_switch_mpurate_at_boot(const char *mpurate_ck_name);
>>   void omap2_clk_print_new_rates(const char *hfclkin_ck_name,
>> @@ -431,10 +287,8 @@ extern const struct clksel_rate gfx_l3_rates[];
>>   extern const struct clksel_rate dsp_ick_rates[];
>>   extern struct clk dummy_ck;
>>
>> -extern const struct clk_hw_omap_ops clkhwops_omap3_dpll;
> is this needed to be moved?
>
>>   extern const struct clk_hw_omap_ops clkhwops_iclk_wait;
>>   extern const struct clk_hw_omap_ops clkhwops_wait;
>> -extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx;
> is this needed to be moved?
>
>>   extern const struct clk_hw_omap_ops clkhwops_iclk;
>>   extern const struct clk_hw_omap_ops clkhwops_omap3430es2_ssi_wait;
>>   extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_ssi_wait;
>> @@ -460,8 +314,5 @@ extern const struct clksel_rate div31_1to31_rates[];
>>
>>   extern int am33xx_clk_init(void);
>>
>> -extern int omap2_clkops_enable_clkdm(struct clk_hw *hw);
>> -extern void omap2_clkops_disable_clkdm(struct clk_hw *hw);
>> -
>
>
>>   extern void omap_clocks_register(struct omap_clk *oclks, int cnt);
>>   #endif
>> diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
>> index 647f02f..cba892a 100644
>> --- a/include/linux/clk/omap.h
>> +++ b/include/linux/clk/omap.h
>> @@ -19,6 +19,161 @@
>>   #ifndef __LINUX_CLK_OMAP_H_
>>   #define __LINUX_CLK_OMAP_H_
>>
>> -int __init dt_omap_clk_init(void);
>> +/**
>> + * struct dpll_data - DPLL registers and integration data
>> + * @mult_div1_reg: register containing the DPLL M and N bitfields
>> + * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg
>> + * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg
>> + * @clk_bypass: struct clk pointer to the clock's bypass clock input
>> + * @clk_ref: struct clk pointer to the clock's reference clock input
>> + * @control_reg: register containing the DPLL mode bitfield
>> + * @enable_mask: mask of the DPLL mode bitfield in @control_reg
>> + * @last_rounded_rate: cache of the last rate result of
>> omap2_dpll_round_rate()
>> + * @last_rounded_m: cache of the last M result of
>> omap2_dpll_round_rate()
>> + * @last_rounded_m4xen: cache of the last M4X result of
>> + *                     omap4_dpll_regm4xen_round_rate()
>> + * @last_rounded_lpmode: cache of the last lpmode result of
>> + *                      omap4_dpll_lpmode_recalc()
>> + * @max_multiplier: maximum valid non-bypass multiplier value (actual)
>> + * @last_rounded_n: cache of the last N result of
>> omap2_dpll_round_rate()
>> + * @min_divider: minimum valid non-bypass divider value (actual)
>> + * @max_divider: maximum valid non-bypass divider value (actual)
>> + * @modes: possible values of @enable_mask
>> + * @autoidle_reg: register containing the DPLL autoidle mode bitfield
>> + * @idlest_reg: register containing the DPLL idle status bitfield
>> + * @autoidle_mask: mask of the DPLL autoidle mode bitfield in
>> @autoidle_reg
>> + * @freqsel_mask: mask of the DPLL jitter correction bitfield in
>> @control_reg
>> + * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg
>> + * @lpmode_mask: mask of the DPLL low-power mode bitfield in
>> @control_reg
>> + * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg
>> + * @auto_recal_bit: bitshift of the driftguard enable bit in
>> @control_reg
>> + * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for
>> recalibration IRQs
>> + * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for
>> recalibration IRQs
>> + * @flags: DPLL type/features (see below)
>> + *
>> + * Possible values for @flags:
>> + * DPLL_J_TYPE: "J-type DPLL" (only some 36xx, 4xxx DPLLs)
> but the flag is in arch/arm/mach-omap2/clock.h ?

I'll look at this and probably move the flag also.

>
>> + *
>> + * @freqsel_mask is only used on the OMAP34xx family and AM35xx.
>> + *
>> + * XXX Some DPLLs have multiple bypass inputs, so it's not technically
>> + * correct to only have one @clk_bypass pointer.
>> + *
>> + * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m,
>> + * @last_rounded_n) should be separated from the runtime-fixed fields
>> + * and placed into a different structure, so that the runtime-fixed data
>> + * can be placed into read-only space.
>> + */
>> +struct dpll_data {
>
> is it necessary to export this? usage is limited to dpll.c and could be
> made private to it alone, no?

No, unfortunately dpll_data is used both by the dpll.c and the support 
code under mach-omap2. This is some sort of intermediate solution, so 
get DT clocks working first, then move the support code also under 
drivers/clk/omap.

>
>> +    void __iomem        *mult_div1_reg;
>> +    u32            mult_mask;
>> +    u32            div1_mask;
>> +    struct clk        *clk_bypass;
>> +    struct clk        *clk_ref;
>> +    void __iomem        *control_reg;
>> +    u32            enable_mask;
>> +    unsigned long        last_rounded_rate;
>> +    u16            last_rounded_m;
>> +    u8            last_rounded_m4xen;
>> +    u8            last_rounded_lpmode;
>> +    u16            max_multiplier;
>> +    u8            last_rounded_n;
>> +    u8            min_divider;
>> +    u16            max_divider;
>> +    u8            modes;
>> +    void __iomem        *autoidle_reg;
>> +    void __iomem        *idlest_reg;
>> +    u32            autoidle_mask;
>> +    u32            freqsel_mask;
>> +    u32            idlest_mask;
>> +    u32            dco_mask;
>
> not part of kernel documentation above.
>
>> +    u32            sddiv_mask;
>
> not part of kernel documentation above.

Copy paste from the corresponding mach-omap2 file, I need to double 
check what these parameters actually do.

>
>
>> +    u32            lpmode_mask;
>> +    u32            m4xen_mask;
>> +    u8            auto_recal_bit;
>> +    u8            recal_en_bit;
>> +    u8            recal_st_bit;
>> +    u8            flags;
>> +};
>> +
>> +/**
>> + * struct clk_hw_omap - OMAP struct clk
>> + * @node: list_head connecting this clock into the full clock list
>> + * @enable_reg: register to write to enable the clock (see @enable_bit)
>> + * @enable_bit: bitshift to write to enable/disable the clock (see
>> @enable_reg)
>> + * @flags: see "struct clk.flags possibilities" above
>> + * @clksel_reg: for clksel clks, register va containing src/divisor
>> select
>> + * @clksel_mask: bitmask in @clksel_reg for the src/divisor selector
>> + * @clksel: for clksel clks, pointer to struct clksel for this clock
>> + * @dpll_data: for DPLLs, pointer to struct dpll_data for this clock
>> + * @clkdm_name: clockdomain name that this clock is contained in
>> + * @clkdm: pointer to struct clockdomain, resolved from @clkdm_name
>> at runtime
>> + * @rate_offset: bitshift for rate selection bitfield (OMAP1 only)
>> + * @src_offset: bitshift for source selection bitfield (OMAP1 only)
>> + *
>> + * XXX @rate_offset, @src_offset should probably be removed and OMAP1
>> + * clock code converted to use clksel.
> Do you need to carry these forward? they already disappeared from the
> struct below.

Hmm, I'll check this.

>
>> + *
>> + */
>> +
>> +struct clk_hw_omap_ops;
> you need to keep the kernel documentation next to the struct which it is
> documenting, by introducing clk_hw_omap_ops forward declaration, we
> introduced the following kernel-doc error:
>
> Error(include/linux/clk/omap.h:119): Cannot parse struct or union!

Copy pasted problem it seems, I'll fix it.

>
>> +
>> +struct clk_hw_omap {
>> +    struct clk_hw        hw;
> not documented.
>
>> +    struct list_head    node;
>> +    unsigned long        fixed_rate;
> not documented.
>
>> +    u8            fixed_div;
> not documented.

I'll fix these.

>
>> +    void __iomem        *enable_reg;
>> +    u8            enable_bit;
>> +    u8            flags;
>> +    void __iomem        *clksel_reg;
>> +    u32            clksel_mask;
>> +    const struct clksel    *clksel;
>> +    struct dpll_data    *dpll_data;
>> +    const char        *clkdm_name;
>> +    struct clockdomain    *clkdm;
>> +    const struct clk_hw_omap_ops    *ops;
>> +};
>> +
>> +struct clk_hw_omap_ops {
>> +    void            (*find_idlest)(struct clk_hw_omap *oclk,
>> +                    void __iomem **idlest_reg,
>> +                    u8 *idlest_bit, u8 *idlest_val);
>> +    void            (*find_companion)(struct clk_hw_omap *oclk,
>> +                    void __iomem **other_reg,
>> +                    u8 *other_bit);
>> +    void            (*allow_idle)(struct clk_hw_omap *oclk);
>> +    void            (*deny_idle)(struct clk_hw_omap *oclk);
>> +};
>
> will be nice to have kernel documentation for these.

Okay.

>
>> +
>> +void omap2_init_clk_hw_omap_clocks(struct clk *clk);
>> +int omap3_noncore_dpll_enable(struct clk_hw *hw);
>> +void omap3_noncore_dpll_disable(struct clk_hw *hw);
>> +int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned long rate,
>> +                unsigned long parent_rate);
>> +unsigned long omap4_dpll_regm4xen_recalc(struct clk_hw *hw,
>> +                unsigned long parent_rate);
>> +long omap4_dpll_regm4xen_round_rate(struct clk_hw *hw,
>> +                    unsigned long target_rate,
>> +                    unsigned long *parent_rate);
>> +u8 omap2_init_dpll_parent(struct clk_hw *hw);
>> +unsigned long omap3_dpll_recalc(struct clk_hw *hw, unsigned long
>> parent_rate);
>> +long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
>> +            unsigned long *parent_rate);
>> +void omap2_init_clk_clkdm(struct clk_hw *clk);
>> +unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
>> +                    unsigned long parent_rate);
>> +
>> +int omap2_clkops_enable_clkdm(struct clk_hw *hw);
>> +void omap2_clkops_disable_clkdm(struct clk_hw *hw);
>> +
>> +int omap2_clk_disable_autoidle_all(void);
> ^^ all the above, not clear why we are moving them out enmasse.

Will split out the moves.


>
>> +
>> +extern const struct clk_hw_omap_ops clkhwops_omap3_dpll;
>> +extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx;
> why do we need to export these out?

Ditto. But these are used by the dpll.c code.

>
>> +
>> +/* DT functions */
>> +int dt_omap_clk_init(void);
> in this change, we removed __init -> which should have been done in the
> patch that introduced it in the first place.
>
>> +void of_omap4_dpll_setup(struct device_node *node);
> we should not be needing this.

I think we do.

>
>>
>>   #endif
>>
>
> at this point, we have a dependency between drivers/clk/omap/dpll.c and
> arch/arm/mach-omap2/ -> a possible suggestion will be to move required
> data structures first and operations as required.

My plan is to move the data structs + code later once the initial 
support is in. Otherwise this excercise is going to take much more time 
to get anything up and running.

Also, you can't even move some of the support code / structs, as they 
are still needed by the code under mach-omap2 (clock data for other 
platforms for example.)

-Tero



From manjunath.goudar at linaro.org  Wed Jul 31 06:05:27 2013
From: manjunath.goudar at linaro.org (Manjunath Goudar)
Date: Wed, 31 Jul 2013 15:35:27 +0530
Subject: [PATCH V2] USB: EHCI: make ehci-w90X900 a separate driver
In-Reply-To: <1372347109-5563-1-git-send-email-manjunath.goudar@linaro.org>
References: <1372347109-5563-1-git-send-email-manjunath.goudar@linaro.org>
Message-ID: <1375265127-2051-1-git-send-email-manjunath.goudar@linaro.org>

Separate the W90X900(W90P910) on-chip host controller driver from
ehci-hcd host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before W90X900(W90P910)
can be booted with a multi-platform kernel

and an ehci driver that only works on one of them.

With the infrastructure added by Alan Stern in patch 3e0232039
"USB: EHCI: prepare to make ehci-hcd a library module", we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the w90X900 bus glue.

Signed-off-by: Manjunath Goudar <manjunath.goudar at linaro.org>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Wan ZongShun <mcuos.com at gmail.com>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Cc: Greg KH <greg at kroah.com>
Cc: linux-usb at vger.kernel.org
Cc: linux-kernel at vger.kernel.org

V2:
 -Arranged  #include's in alphabetical order.
 -Replaced "w90p910" by "w90x900" because it is supports
  all series of w90x900.
---
 drivers/usb/host/Kconfig        |    2 +-
 drivers/usb/host/Makefile       |    1 +
 drivers/usb/host/ehci-hcd.c     |    5 ---
 drivers/usb/host/ehci-w90x900.c |   85 ++++++++++++++++-----------------------
 4 files changed, 37 insertions(+), 56 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index ba52912..7bc598b 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -244,7 +244,7 @@ config USB_EHCI_MV
 	  SoCs, see USB_EHCI_HCD_ORION for those.
 
 config USB_W90X900_EHCI
-	bool "W90X900(W90P910) EHCI support"
+	tristate "W90X900(W90P910) EHCI support"
 	depends on ARCH_W90X900
 	---help---
 		Enables support for the W90X900 USB controller
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 7664db8..28adb3f 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
 obj-$(CONFIG_USB_EHCI_MSM)	+= ehci-msm.o
 obj-$(CONFIG_USB_EHCI_TEGRA)	+= ehci-tegra.o
 obj-$(CONFIG_USB_EHCI_MV)       += ehci-mv.o
+obj-$(CONFIG_USB_W90X900_EHCI)	+= ehci-w90x900.o
 
 obj-$(CONFIG_USB_OXU210HP_HCD)	+= oxu210hp-hcd.o
 obj-$(CONFIG_USB_ISP116X_HCD)	+= isp116x-hcd.o
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 5717dcd..4a5644e 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1249,11 +1249,6 @@ MODULE_LICENSE ("GPL");
 #define XILINX_OF_PLATFORM_DRIVER	ehci_hcd_xilinx_of_driver
 #endif
 
-#ifdef CONFIG_USB_W90X900_EHCI
-#include "ehci-w90x900.c"
-#define	PLATFORM_DRIVER		ehci_hcd_w90x900_driver
-#endif
-
 #ifdef CONFIG_USB_OCTEON_EHCI
 #include "ehci-octeon.c"
 #define PLATFORM_DRIVER		ehci_octeon_driver
diff --git a/drivers/usb/host/ehci-w90x900.c b/drivers/usb/host/ehci-w90x900.c
index 59e0e24..4d6631d 100644
--- a/drivers/usb/host/ehci-w90x900.c
+++ b/drivers/usb/host/ehci-w90x900.c
@@ -11,13 +11,28 @@
  *
  */
 
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ehci.h"
 
 /* enable phy0 and phy1 for w90p910 */
 #define	ENPHY		(0x01<<8)
 #define PHY0_CTR	(0xA4)
 #define PHY1_CTR	(0xA8)
 
+#define DRIVER_DESC "EHCI w90x900 driver"
+
+static const char hcd_name[] = "ehci-w90x900 ";
+
+static struct hc_driver __read_mostly ehci_w90x900_hc_driver;
+
 static int usb_w90x900_probe(const struct hc_driver *driver,
 		      struct platform_device *pdev)
 {
@@ -99,54 +114,6 @@ void usb_w90x900_remove(struct usb_hcd *hcd, struct platform_device *pdev)
 	usb_put_hcd(hcd);
 }
 
-static const struct hc_driver ehci_w90x900_hc_driver = {
-	.description = hcd_name,
-	.product_desc = "Nuvoton w90x900 EHCI Host Controller",
-	.hcd_priv_size = sizeof(struct ehci_hcd),
-
-	/*
-	 * generic hardware linkage
-	 */
-	.irq = ehci_irq,
-	.flags = HCD_USB2|HCD_MEMORY,
-
-	/*
-	 * basic lifecycle operations
-	 */
-	.reset = ehci_setup,
-	.start = ehci_run,
-
-	.stop = ehci_stop,
-	.shutdown = ehci_shutdown,
-
-	/*
-	 * managing i/o requests and associated device resources
-	 */
-	.urb_enqueue = ehci_urb_enqueue,
-	.urb_dequeue = ehci_urb_dequeue,
-	.endpoint_disable = ehci_endpoint_disable,
-	.endpoint_reset = ehci_endpoint_reset,
-
-	/*
-	 * scheduling support
-	 */
-	.get_frame_number = ehci_get_frame,
-
-	/*
-	 * root hub support
-	 */
-	.hub_status_data = ehci_hub_status_data,
-	.hub_control = ehci_hub_control,
-#ifdef	CONFIG_PM
-	.bus_suspend = ehci_bus_suspend,
-	.bus_resume = ehci_bus_resume,
-#endif
-	.relinquish_port	= ehci_relinquish_port,
-	.port_handed_over	= ehci_port_handed_over,
-
-	.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
-};
-
 static int ehci_w90x900_probe(struct platform_device *pdev)
 {
 	if (usb_disabled())
@@ -173,7 +140,25 @@ static struct platform_driver ehci_hcd_w90x900_driver = {
 	},
 };
 
+static int __init ehci_w90X900_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ehci_init_driver(&ehci_w90x900_hc_driver, NULL);
+	return platform_driver_register(&ehci_hcd_w90x900_driver);
+}
+module_init(ehci_w90X900_init);
+
+static void __exit ehci_w90X900_cleanup(void)
+{
+	platform_driver_unregister(&ehci_hcd_w90x900_driver);
+}
+module_exit(ehci_w90X900_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_AUTHOR("Wan ZongShun <mcuos.com at gmail.com>");
-MODULE_DESCRIPTION("w90p910 usb ehci driver!");
-MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:w90p910-ehci");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5



From t-kristo at ti.com  Wed Jul 31 06:07:49 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 13:07:49 +0300
Subject: [PATCHv4 05/33] CLK: omap: add DT duplicate clock registration
 mechanism
In-Reply-To: <51F808A8.6000503@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-6-git-send-email-t-kristo@ti.com> <51F808A8.6000503@ti.com>
Message-ID: <51F8E1F5.20706@ti.com>

On 07/30/2013 09:40 PM, Nishanth Menon wrote:
> On 07/23/2013 02:20 AM, Tero Kristo wrote:
>> Some devices require their clocks to be available with a specific
>> dev-id con-id mapping. With DT, the clocks can be found by default
>> only with their name, or alternatively through the device node of
>> the consumer. With drivers, that don't support DT fully yet, add
>> mechanism to register specific clock names.
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>
> with this, should it not be enough to add clocks=<&phandle>

Don't know, I am not an expert on DT. :)

>
> I am not sure I understand what specific drivers should need to carry
> this "old hack" forward. More importantly, why is it preferable to carry
> the hack forward rather than fixing the drivers.

At least the GP timer seems to need this, and I don't want to touch / 
verify all the potential drivers touched by this so it is easier to 
provide a (semi) temporary tweak.

>
>
>> ---
>>   drivers/clk/omap/clk.c   |   39 +++++++++++++++++++++++++++++++++++++++
>>   include/linux/clk/omap.h |   17 +++++++++++++++++
>>   2 files changed, 56 insertions(+)
>>
>> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
>> index 1dafdaa..cd31a81 100644
>> --- a/drivers/clk/omap/clk.c
>> +++ b/drivers/clk/omap/clk.c
>> @@ -32,6 +32,45 @@ static const struct of_device_id clk_match[] = {
>>       {},
>>   };
>>
>> + /**
>> + * omap_dt_clocks_register - register DT duplicate clocks during boot
>> + * @oclks: list of clocks to register
>> + * @cnt: number of clocks
>> + *
>> + * Register duplicate or non-standard DT clock entries during boot. By
>> + * default, DT clocks are found based on their node name. If any
>> + * additional con-id / dev-id -> clock mapping is required, use this
>> + * function to list these.
>> + */
>> +void __init omap_dt_clocks_register(struct omap_dt_clk oclks[], int cnt)
>
> Cant we use a NULL terminated array? then we dont need to pass cnt.

Yea can.

>
>> +{
>> +    struct omap_dt_clk *c;
>> +    struct device_node *n;
>> +    struct clk *clk;
>> +    struct of_phandle_args clkspec;
>> +
>> +    for (c = oclks; c < oclks + cnt; c++) {
>> +        n = of_find_node_by_name(NULL, c->node_name);
>> +
>> +        if (!n) {
>> +            pr_err("%s: %s not found!\n", __func__, c->node_name);
>> +            continue;
>> +        }
>> +
>> +        clkspec.np = n;
>> +
>> +        clk = of_clk_get_from_provider(&clkspec);
>> +
>> +        if (!clk) {
>> +            pr_err("%s: %s has no clock!\n", __func__,
>> +                c->node_name);
>> +            continue;
>> +        }
>> +        c->lk.clk = clk;
>> +        clkdev_add(&c->lk);
>
> why not clk_add_alias ?

Hmm yea, that might work also now that I made patch #1.

>
>> +    }
>> +}
>> +
>>   /* FIXME - need to initialize early; skip real driver registration &
>> probe */
>>   int __init dt_omap_clk_init(void)
>>   {
>> diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
>> index cba892a..c39e775 100644
>> --- a/include/linux/clk/omap.h
>> +++ b/include/linux/clk/omap.h
>> @@ -19,6 +19,8 @@
>>   #ifndef __LINUX_CLK_OMAP_H_
>>   #define __LINUX_CLK_OMAP_H_
>>
>> +#include <linux/clkdev.h>
>> +
>>   /**
>>    * struct dpll_data - DPLL registers and integration data
>>    * @mult_div1_reg: register containing the DPLL M and N bitfields
>> @@ -146,6 +148,20 @@ struct clk_hw_omap_ops {
>>       void            (*deny_idle)(struct clk_hw_omap *oclk);
>>   };
>>
>> +struct omap_dt_clk {
>> +    struct clk_lookup        lk;
>> +    const char            *node_name;
>> +};
>> +
>
> documentation missing.

Yea, will add.

>
>> +#define DT_CLK(dev, con, name)        \
>> +    {                \
>> +        .lk = {            \
>> +            .dev_id = dev,    \
>> +            .con_id = con,    \
>> +        },            \
>> +        .node_name = name,    \
>> +    }
>> +
>>   void omap2_init_clk_hw_omap_clocks(struct clk *clk);
>>   int omap3_noncore_dpll_enable(struct clk_hw *hw);
>>   void omap3_noncore_dpll_disable(struct clk_hw *hw);
>> @@ -174,6 +190,7 @@ extern const struct clk_hw_omap_ops
>> clkhwops_omap4_dpllmx;
>>
>>   /* DT functions */
>>   int dt_omap_clk_init(void);
>> +extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int cnt);
>
> do you need the extern?

I guess not.

>
>>   void of_omap4_dpll_setup(struct device_node *node);
>>
>>   #endif
>>
>
>



From t-kristo at ti.com  Wed Jul 31 06:13:57 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 13:13:57 +0300
Subject: [PATCHv4 06/33] CLK: omap: add autoidle support
In-Reply-To: <51F80C77.9020109@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-7-git-send-email-t-kristo@ti.com> <51F80C77.9020109@ti.com>
Message-ID: <51F8E365.8080604@ti.com>

On 07/30/2013 09:56 PM, Nishanth Menon wrote:
> On 07/23/2013 02:20 AM, Tero Kristo wrote:
>> OMAP clk driver now routes some of the basic clocks through own
>> registration routine to allow autoidle support. This routine just
>> checks a couple of device node properties and adds autoidle support
>> if required, and just passes the registration forward to basic clocks.
>
> why not extend standard framework to support autoidle capable clocks OR
> introduce our own clk node which depends on basic clocks?

Was kind of easier this way.

>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> ---
>>   arch/arm/mach-omap2/clock.c |    6 ++
>>   drivers/clk/omap/Makefile   |    2 +-
>>   drivers/clk/omap/autoidle.c |  130
>> +++++++++++++++++++++++++++++++++++++++++++
>>   drivers/clk/omap/clk.c      |    4 +-
>>   include/linux/clk/omap.h    |    4 ++
>>   5 files changed, 143 insertions(+), 3 deletions(-)
>>   create mode 100644 drivers/clk/omap/autoidle.c
>
> I know it is getting a little stale, but anyways, device tree binding
> missing.
>
>>
>> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
>> index 0c38ca9..669d4c4 100644
>> --- a/arch/arm/mach-omap2/clock.c
>> +++ b/arch/arm/mach-omap2/clock.c
> Not sure why, at this point in time we are going to calling drivers/clk
> code.
>
>> @@ -520,6 +520,9 @@ int omap2_clk_enable_autoidle_all(void)
>>       list_for_each_entry(c, &clk_hw_omap_clocks, node)
>>           if (c->ops && c->ops->allow_idle)
>>               c->ops->allow_idle(c);
>> +
>> +    of_omap_clk_allow_autoidle_all();
>> +
>>       return 0;
>>   }
>>
>> @@ -539,6 +542,9 @@ int omap2_clk_disable_autoidle_all(void)
>>       list_for_each_entry(c, &clk_hw_omap_clocks, node)
>>           if (c->ops && c->ops->deny_idle)
>>               c->ops->deny_idle(c);
>> +
>> +    of_omap_clk_deny_autoidle_all();
>> +
>
> these are defined for CONFIG_OF.. anyways, without dt nodes (OMAP3 is
> supposed to support non-DT boot even now), this would not work, would it?

The lists are empty so the funcs do nothing. However, dropping CONFIG_OF 
would break these of course. Will figure out a fix for this.

The calls are needed for the transition phase until we can move more clk 
stuff from mach-omap2 to drivers.

>
>
>>       return 0;
>>   }
>>
>> diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
>> index 4cad480..ca56700 100644
>> --- a/drivers/clk/omap/Makefile
>> +++ b/drivers/clk/omap/Makefile
>> @@ -1 +1 @@
>> -obj-y                    += clk.o dpll.o
>> +obj-y                    += clk.o dpll.o autoidle.o
>> diff --git a/drivers/clk/omap/autoidle.c b/drivers/clk/omap/autoidle.c
>> new file mode 100644
>> index 0000000..6424cb2
>> --- /dev/null
>> +++ b/drivers/clk/omap/autoidle.c
>> @@ -0,0 +1,130 @@
>> +/*
>> + * OMAP clock autoidle support
>> + *
>> + * Copyright (C) 2013 Texas Instruments, Inc.
>> + *
>> + * Tero Kristo <t-kristo at ti.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/clk-provider.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/io.h>
>> +#include <linux/err.h>
>> +#include <linux/string.h>
>> +#include <linux/log2.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
> at all of these required?

I'll double check.

>
>> +
>> +#ifdef CONFIG_OF
>> +struct clk_omap_autoidle {
>> +    void __iomem        *reg;
>> +    u8            shift;
>> +    u8            flags;
>> +    const char        *name;
>> +    struct list_head    node;
>> +};
>> +
>> +#define AUTOIDLE_LOW        0x1
>> +
>> +static LIST_HEAD(autoidle_clks);
>> +
>> +static void omap_allow_autoidle(struct clk_omap_autoidle *clk)
>> +{
>> +    u32 val;
>> +
>> +    val = readl(clk->reg);
>> +
>> +    if (clk->flags & AUTOIDLE_LOW)
>> +        val &= ~(1 << clk->shift);
>> +    else
>> +        val |= (1 << clk->shift);
>> +
>> +    writel(val, clk->reg);
>> +}
>> +
>> +static void omap_deny_autoidle(struct clk_omap_autoidle *clk)
>> +{
>> +    u32 val;
>> +
>> +    val = readl(clk->reg);
>> +
>> +    if (clk->flags & AUTOIDLE_LOW)
>> +        val |= (1 << clk->shift);
>> +    else
>> +        val &= ~(1 << clk->shift);
>> +
>> +    writel(val, clk->reg);
>> +}
>> +
>> +void of_omap_clk_allow_autoidle_all(void)
>> +{
>> +    struct clk_omap_autoidle *c;
>> +
>> +    list_for_each_entry(c, &autoidle_clks, node)
>> +        omap_allow_autoidle(c);
>> +}
>> +
>> +void of_omap_clk_deny_autoidle_all(void)
>> +{
>> +    struct clk_omap_autoidle *c;
>> +
>> +    list_for_each_entry(c, &autoidle_clks, node)
>> +        omap_deny_autoidle(c);
>> +}
>> +
>> +static __init void of_omap_autoidle_setup(struct device_node *node)
>> +{
>> +    u32 shift;
>> +    void __iomem *reg;
>> +    struct clk_omap_autoidle *clk;
>> +
>> +    if (of_property_read_u32(node, "ti,autoidle-shift", &shift))
>> +        return;
>> +
>> +    reg = of_iomap(node, 0);
>> +
>> +    clk = kzalloc(sizeof(struct clk_omap_autoidle), GFP_KERNEL);
>> +
>> +    if (!clk) {
>> +        pr_err("%s: kzalloc failed\n", __func__);
>> +        return;
>> +    }
>> +
>> +    clk->shift = shift;
>> +    clk->name = node->name;
>> +    clk->reg = reg;
>> +
>> +    if (of_property_read_bool(node, "ti,autoidle-low"))
>> +        clk->flags |= AUTOIDLE_LOW;
>> +
>> +    list_add(&clk->node, &autoidle_clks);
>> +}
>> +
>> +void __init of_omap_divider_setup(struct device_node *node)
>> +{
>> +    of_divider_clk_setup(node);
>> +    of_omap_autoidle_setup(node);
>> +}
>> +EXPORT_SYMBOL_GPL(of_omap_divider_setup);
>> +CLK_OF_DECLARE(omap_autoidle_clock, "divider-clock",
>> of_omap_divider_setup);
>
> This is overriding drivers/clk/clk-divider.c ?

Yea, this declaration here should be removed.

>> +
>> +void __init of_omap_fixed_factor_setup(struct device_node *node)
>> +{
>> +    of_fixed_factor_clk_setup(node);
>> +    of_omap_autoidle_setup(node);
>> +}
>> +EXPORT_SYMBOL_GPL(of_omap_fixed_factor_setup);
>> +CLK_OF_DECLARE(omap_fixed_factor_clock, "fixed-factor-clock",
>> +    of_omap_fixed_factor_setup);
>
> This is overriding drivers/clk/clk-fixed-factor.c ?

Ditto.

>> +
>> +#endif
>> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
>> index cd31a81..c149097 100644
>> --- a/drivers/clk/omap/clk.c
>> +++ b/drivers/clk/omap/clk.c
>> @@ -25,8 +25,8 @@ static const struct of_device_id clk_match[] = {
>>       {.compatible = "fixed-clock", .data = of_fixed_clk_setup, },
>>       {.compatible = "mux-clock", .data = of_mux_clk_setup, },
>>       {.compatible = "fixed-factor-clock",
>> -        .data = of_fixed_factor_clk_setup, },
>> -    {.compatible = "divider-clock", .data = of_divider_clk_setup, },
>> +        .data = of_omap_fixed_factor_setup, },
>> +    {.compatible = "divider-clock", .data = of_omap_divider_setup, },

These should be enough for registration.

>>       {.compatible = "gate-clock", .data = of_gate_clk_setup, },
>>       {.compatible = "ti,omap4-dpll-clock", .data =
>> of_omap4_dpll_setup, },
>>       {},
>> diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
>> index c39e775..904bdad 100644
>> --- a/include/linux/clk/omap.h
>> +++ b/include/linux/clk/omap.h
>> @@ -192,5 +192,9 @@ extern const struct clk_hw_omap_ops
>> clkhwops_omap4_dpllmx;
>>   int dt_omap_clk_init(void);
>>   extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int
>> cnt);
>>   void of_omap4_dpll_setup(struct device_node *node);
>> +void of_omap_fixed_factor_setup(struct device_node *node);
>> +void of_omap_divider_setup(struct device_node *node);
>> +void of_omap_clk_allow_autoidle_all(void);
>> +void of_omap_clk_deny_autoidle_all(void);
>>
>>   #endif
>>
>
> I personally dont prefer the fact that divider-clock and
> fixed-rate-clock now has double meaning - building a multi-arch kernel
> for example, this can wreak havoc. standard definitions should not be
> monkeyed around with thus if avoidable, and in this case, very much
> avoidable.
>
> just my 2 cents.

Yea, as described before, I'll change the code not to make a global 
override, instead, just make omap specific override which parses the 
extra params. That sound better or still see some issues with that?

-Tero


From maxime.ripard at free-electrons.com  Wed Jul 31 06:14:33 2013
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 31 Jul 2013 12:14:33 +0200
Subject: [PATCH 3/4] clk: sunxi: Add A31 clocks support
In-Reply-To: <51F861E5.7010909@elopez.com.ar>
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375195462-19566-4-git-send-email-maxime.ripard@free-electrons.com>
 <51F861E5.7010909@elopez.com.ar>
Message-ID: <20130731101433.GC2911@lukather>

Hi Emilio,

On Tue, Jul 30, 2013 at 10:01:25PM -0300, Emilio L?pez wrote:
> Hi Maxime,
> 
> El 30/07/13 11:44, Maxime Ripard escribi?:
> > The A31 has a mostly different clock set compared to the other older
> > SoCs currently supported in the Allwinner clock driver.
> > 
> > Add support for the basic useful clocks. The other ones will come in
> > eventually.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > ---
> >  drivers/clk/sunxi/clk-sunxi.c | 120 ++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 120 insertions(+)
> > 
> > diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> > index 6e9cbc9..8cd69e6 100644
> > --- a/drivers/clk/sunxi/clk-sunxi.c
> > +++ b/drivers/clk/sunxi/clk-sunxi.c
> > @@ -124,7 +124,67 @@ static void sun4i_get_pll1_factors(u32 *freq, u32 parent_rate,
> >  	*n = div / 4;
> >  }
> >  
> > +/**
> > + * sun6i_get_pll1_factors() - calculates n, k and m factors for PLL1
> > + * PLL1 rate is calculated as follows
> > + * rate = parent_rate * (n + 1) * (k + 1) / (m + 1);
> > + * parent_rate should always be 24MHz
> > + */
> > +static void sun6i_get_pll1_factors(u32 *freq, u32 parent_rate,
> > +				   u8 *n, u8 *k, u8 *m, u8 *p)
> > +{
> > +	/*
> > +	 * We can operate only on MHz, this will make our life easier
> > +	 * later.
> > +	 */
> > +	u32 freq_mhz = *freq / 1000000;
> > +	u32 parent_freq_mhz = parent_rate / 1000000;
> > +
> > +	/* If the frequency is a multiple of 32 MHz, k is always 3 */
> > +	if (!(freq_mhz % 32))
> > +		*k = 3;
> > +	/* If the frequency is a multiple of 9 MHz, k is always 2 */
> > +	else if (!(freq_mhz % 9))
> > +		*k = 2;
> > +	/* If the frequency is a multiple of 8 MHz, k is always 1 */
> > +	else if (!(freq_mhz % 8))
> > +		*k = 1;
> > +	/* Otherwise, we don't use the k factor */
> > +	else
> > +		*k = 0;
> >  
> > +	/*
> > +	 * If the frequency is a multiple of 2 but not a multiple of
> > +	 * 3, m is 3. This is the first time we use 6 here, yet we
> > +	 * will use it on several other places.
> > +	 * We use this number because it's the lowest frequency we can
> > +	 * generate (with n = 0, k = 0, m = 3), so every other frequency
> > +	 * somehow relates to this frequency.
> > +	 */
> > +	if ((freq_mhz % 6) == 2 || (freq_mhz % 6) == 4)
> > +		*m = 2;
> > +	/*
> > +	 * If the frequency is a multiple of 6MHz, but the factor is
> > +	 * odd, m will be 3
> > +	 */
> > +	else if ((freq_mhz / 6) & 1)
> > +		*m = 3;
> > +	/* Otherwise, we end up with m = 1 */
> > +	else
> > +		*m = 1;
> > +
> > +	/* Calculate n thanks to the above factors we already got */
> > +	*n = freq_mhz * (*m + 1) / ((*k + 1) * parent_freq_mhz) - 1;
> > +
> > +	/*
> > +	 * If n end up being outbound, and that we can still decrease
> > +	 * m, do it.
> > +	 */
> > +	if ((*n + 1) > 31 && (*m + 1) > 1) {
> > +		*n = (*n + 1) / 2 - 1;
> > +		*m = (*m + 1) / 2 - 1;
> > +	}
> > +}
> 
> Nice! My rate-to-factors functions pale in comparison :) Remember that
> n/k/m/p may be NULL when the caller just wants you to round freq to an
> achievable value (see clk_factors_round_rate(...) in clk-factors.c).

Ah, right, I forgot that usecase.

> >  /**
> >   * sun4i_get_apb1_factors() - calculates m, p factors for APB1
> > @@ -189,6 +249,15 @@ static struct clk_factors_config sun4i_pll1_config = {
> >  	.pwidth = 2,
> >  };
> >  
> > +static struct clk_factors_config sun6i_pll1_config = {
> > +	.nshift	= 8,
> > +	.nwidth = 5,
> > +	.kshift = 4,
> > +	.kwidth = 2,
> > +	.mshift = 0,
> > +	.mwidth = 2,
> > +};
> > +
> >  static struct clk_factors_config sun4i_apb1_config = {
> >  	.mshift = 0,
> >  	.mwidth = 5,
> > @@ -201,6 +270,11 @@ static const __initconst struct factors_data sun4i_pll1_data = {
> >  	.getter = sun4i_get_pll1_factors,
> >  };
> >  
> > +static const __initconst struct factors_data sun6i_pll1_data = {
> > +	.table = &sun6i_pll1_config,
> > +	.getter = sun6i_get_pll1_factors,
> > +};
> > +
> >  static const __initconst struct factors_data sun4i_apb1_data = {
> >  	.table = &sun4i_apb1_config,
> >  	.getter = sun4i_get_apb1_factors,
> > @@ -243,6 +317,10 @@ static const __initconst struct mux_data sun4i_cpu_mux_data = {
> >  	.shift = 16,
> >  };
> >  
> > +static const __initconst struct mux_data sun6i_ahb1_mux_data = {
> > +	.shift = 12,
> > +};
> > +
> >  static const __initconst struct mux_data sun4i_apb1_mux_data = {
> >  	.shift = 24,
> >  };
> > @@ -301,6 +379,12 @@ static const __initconst struct div_data sun4i_apb0_data = {
> >  	.width	= 2,
> >  };
> >  
> > +static const __initconst struct div_data sun6i_apb2_div_data = {
> > +	.shift	= 0,
> > +	.pow	= 0,
> > +	.width	= 4,
> > +};
> > +
> >  static void __init sunxi_divider_clk_setup(struct device_node *node,
> >  					   struct div_data *data)
> >  {
> > @@ -347,6 +431,10 @@ static const __initconst struct gates_data sun5i_a13_ahb_gates_data = {
> >  	.mask = {0x107067e7, 0x185111},
> >  };
> >  
> > +static const __initconst struct gates_data sun6i_a31_ahb1_gates_data = {
> > +	.mask = { 0xedfe7f62, 0x794f931 },
> > +};
> > +
> >  static const __initconst struct gates_data sun4i_apb0_gates_data = {
> >  	.mask = {0x4EF},
> >  };
> > @@ -363,6 +451,14 @@ static const __initconst struct gates_data sun5i_a13_apb1_gates_data = {
> >  	.mask = {0xa0007},
> >  };
> >  
> > +static const __initconst struct gates_data sun6i_a31_apb1_gates_data = {
> > +	.mask = { 0x3031 },
> > +};
> > +
> > +static const __initconst struct gates_data sun6i_a31_apb2_gates_data = {
> > +	.mask = { 0x3f000f },
> > +};
> > +
> 
> We should decide on a style here and use it across the board, so far we
> have definitions with and without spaces between constants and braces,
> and constants both with upper and lower case A-F. Personally I don't
> feel strongly about the spacing and prefer upper-case constants, but if
> the style guide suggests otherwise, I can live with it (as long as we
> use it consistently, that is)

Hmmm, like you probably noticed, I prefer the { 0xdeadbeef } way, and
that's what is used everywhere else for sunxi I believe. There's no
strong convention on this one, but it's true that we have to remain
consistent.

I'll stick with your convention already in use in the clocks driver for
the time being, and we'll see later to unify the drivers on this
convention later on.

> >  static void __init sunxi_gates_clk_setup(struct device_node *node,
> >  					 struct gates_data *data)
> >  {
> > @@ -420,6 +516,10 @@ static const __initconst struct of_device_id clk_factors_match[] = {
> >  		.data = &sun4i_pll1_data,
> >  	},
> >  	{
> > +		.compatible = "allwinner,sun6i-pll1-clk",
> > +		.data = &sun6i_pll1_data,
> > +	},
> > +	{
> >  		.compatible = "allwinner,sun4i-apb1-clk",
> >  		.data = &sun4i_apb1_data,
> >  	},
> > @@ -440,6 +540,10 @@ static const __initconst struct of_device_id clk_div_match[] = {
> >  		.compatible = "allwinner,sun4i-apb0-clk",
> >  		.data = &sun4i_apb0_data,
> >  	},
> > +	{
> > +		.compatible = "allwinner,sun6i-apb2-div-clk",
> > +		.data = &sun6i_apb2_div_data,
> > +	},
> >  	{}
> >  };
> >  
> > @@ -453,6 +557,10 @@ static const __initconst struct of_device_id clk_mux_match[] = {
> >  		.compatible = "allwinner,sun4i-apb1-mux-clk",
> >  		.data = &sun4i_apb1_mux_data,
> >  	},
> > +	{
> > +		.compatible = "allwinner,sun6i-ahb1-mux-clk",
> > +		.data = &sun6i_ahb1_mux_data,
> > +	},
> >  	{}
> >  };
> >  
> > @@ -471,6 +579,10 @@ static const __initconst struct of_device_id clk_gates_match[] = {
> >  		.data = &sun5i_a13_ahb_gates_data,
> >  	},
> >  	{
> > +		.compatible = "allwinner,sun6i-a31-ahb1-gates-clk",
> > +		.data = &sun6i_a31_ahb1_gates_data,
> > +	},
> > +	{
> >  		.compatible = "allwinner,sun4i-apb0-gates-clk",
> >  		.data = &sun4i_apb0_gates_data,
> >  	},
> > @@ -486,6 +598,14 @@ static const __initconst struct of_device_id clk_gates_match[] = {
> >  		.compatible = "allwinner,sun5i-a13-apb1-gates-clk",
> >  		.data = &sun5i_a13_apb1_gates_data,
> >  	},
> > +	{
> > +		.compatible = "allwinner,sun6i-a31-apb1-gates-clk",
> > +		.data = &sun6i_a31_apb1_gates_data,
> > +	},
> > +	{
> > +		.compatible = "allwinner,sun6i-a31-apb2-gates-clk",
> > +		.data = &sun6i_a31_apb2_gates_data,
> > +	},
> 
> Please see my comments on the first patch regarding these.

Yes, that will be fixed.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130731/cb5c4e75/attachment-0001.sig>

From rjw at sisk.pl  Wed Jul 31 06:30:45 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Wed, 31 Jul 2013 12:30:45 +0200
Subject: [PATCH RFC 3/3] cpufreq: cpufreq-cpu0: clk rate-change notifiers
In-Reply-To: <CAKohpom-8KXixJ0ZbQ7Poh3uqJCqo7LFyYEfYeMyp+yZx9QmHA@mail.gmail.com>
References: <1373247868-21444-1-git-send-email-mturquette@linaro.org>
 <20130731014328.5270.4248@quantum>
 <CAKohpom-8KXixJ0ZbQ7Poh3uqJCqo7LFyYEfYeMyp+yZx9QmHA@mail.gmail.com>
Message-ID: <2244883.xRIZhTlqYe@vostro.rjw.lan>

On Wednesday, July 31, 2013 10:09:03 AM Viresh Kumar wrote:
> On 31 July 2013 07:13, Mike Turquette <mturquette at linaro.org> wrote:
> > Quoting Viresh Kumar (2013-07-07 21:10:54)
> >> On Mon, Jul 8, 2013 at 7:14 AM, Mike Turquette <mturquette at linaro.org> wrote:
> >> > Removes direct handling of OPP tables and voltage regulators by calling
> >> > of_clk_cpufreq_notifier_handler, introduced by commit "clk: cpufreq
> >> > helper for voltage scaling".
> >> >
> >> > In the future this can help consolidate code found across similar
> >> > CPUfreq drivers.
> >> >
> >> > Signed-off-by: Mike Turquette <mturquette at linaro.org>
> >> > ---
> >> >  drivers/cpufreq/cpufreq-cpu0.c | 125 ++++++++---------------------------------
> >> >  1 file changed, 22 insertions(+), 103 deletions(-)
> >>
> >> Good patch, really gets lots of stuff out from cpufreq drivers.
> >>
> >> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
> >
> > Viresh,
> >
> > Thanks for the Ack. I received no comments on this series besides your
> > own, so I plan to merge it. Do you want to take patch #3, or do you want
> > me to take it, or should I give you and Rafael a stable branch instead?
> 
> Its only related to cpufreq-cpu0 and to handle dependencies well they
> should go through a single tree.. Probably your tree is the right place for
> now. Rafael?

Yes, the entire series should go through the Mike's tree I think.

Thanks,
Rafael



From lee.jones at linaro.org  Wed Jul 31 06:21:00 2013
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 31 Jul 2013 11:21:00 +0100
Subject: [PATCH 01/22] ARM: ux500: Remove '0x's from HREF v60+ DTS file
In-Reply-To: <20130730115403.GA29992@amd.pavel.ucw.cz>
References: <1374242333-6852-1-git-send-email-lee.jones@linaro.org>
 <20130730115403.GA29992@amd.pavel.ucw.cz>
Message-ID: <20130731102100.GD13298@lee--X1>

On Tue, 30 Jul 2013, Pavel Machek wrote:

> On Fri 2013-07-19 14:58:32, Lee Jones wrote:
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> Why?

Convention.

> > diff --git a/arch/arm/boot/dts/hrefv60plus.dts b/arch/arm/boot/dts/hrefv60plus.dts
> > index 3d580d6..46fd8af 100644
> > --- a/arch/arm/boot/dts/hrefv60plus.dts
> > +++ b/arch/arm/boot/dts/hrefv60plus.dts
> > @@ -26,7 +26,7 @@
> >  
> >  	soc {
> >  		i2c at 80110000 {
> > -			bu21013_tp at 0x5c {
> > +			bu21013_tp at 5c {
> >  				reset-gpio = <&gpio4 15 0x4>;
> >  			};
> >  		};
> 

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From u.kleine-koenig at pengutronix.de  Wed Jul 31 06:28:53 2013
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Wed, 31 Jul 2013 12:28:53 +0200
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731095411.GA2810@htj.dyndns.org>
References: <1375232669-27846-1-git-send-email-festevam@gmail.com>
 <1375232669-27846-2-git-send-email-festevam@gmail.com>
 <20130731073306.GZ1754@pengutronix.de>
 <20130731082054.GF8540@nchen-desktop>
 <20130731084645.GB1754@pengutronix.de>
 <20130731090512.GD9858@sirena.org.uk>
 <20130731094434.GC1754@pengutronix.de>
 <20130731095411.GA2810@htj.dyndns.org>
Message-ID: <20130731102853.GD1754@pengutronix.de>

On Wed, Jul 31, 2013 at 05:54:11AM -0400, Tejun Heo wrote:
> Hello,
> 
> On Wed, Jul 31, 2013 at 11:44:34AM +0200, Uwe Kleine-K?nig wrote:
> > > > OK, so the possible problem is that remove is called while the irq is
> > > > still active. That means you have to assert that all resources the irq
> 
> If your driver destruction path is running while your irq handler is
> still running, it's a crappy / broken driver.  You need a deactivation
Well, you cannot avoid assuming that the irq is still active when your
driver's remove callback is called. But I agree about crappyness at the
end of the destruction path. The problem is that crap is as easy as:

	probe(..)
	{
		clk = devm_get_clk(...);
		clk_prepare_enable(clk);
		writel(1, base + IRQENABLE);
		devm_request_irq(...);
	}

	remove(..)
	{
		writel(0, base + IRQENABLE);
		clk_disable_unprepare(clk);
	}

and I think there are more and more drivers doing that.

> step whether you're using devm or not.  IRQs can be shared and the
> device should be in a quiesced state before the driver detaches
> itself.  Note that you can queue deactivation routine using devm.  For
> an example, please take a look at
> drivers/ata/libata-core.c::ata_host_start().
> 
> > > > handler is using (e.g. ioremap, clk_prepare_enable) are only freed
> > > > *after* the irq is done. For ioremap that means it must be done using
> > > > devm_ioremap_resource. For a clock it's not that easy because the irq
> > > > handler has to assert that a used clk is kept prepared which can only be
> > > > done using clk_prepare which in turn is not allowed in an irq handler.
> > > 
> > > > Hmm. So the only possible fixes are
> > > > 	- devm* can be told to also care about clk_disable_unprepare
> > > > 	- after disabling irqs in the remove callback wait for all
> > > > 	  active irqs to be done. (i.e. call synchronize_irq(irq))
> > > > 	- don't use devm_request_irq
> 
> Again, the right thing to do is having a proper deactivation step.
> This is nothing devm can do automatically.  There's no way for it to
> find out that the device is actually quiesced.  Let's say it waits for
> the current instance of irq handler to finish.  How would it know that
> it won't start again between the flushing of the current instance and
> irq deregistration.  Add an explicit deactivation step using
> devres_alloc().
> 
> > > I'm not sure that devm_ guarantees any ordering in the cleanups it does
> > > so I'd not like to rely on the first option either, if there were some
> > > guarantee of that it'd help.  The nice thing about explicitly freeing
> > > the IRQ is that you can tell that all this stuff is safe by inspection.
> > devm_* at least uses list_for_each_entry_reverse
> > (drivers/base/devres.c:release_nodes()). Without this guarantee devm_
> > would not make much sense IMHO.
> 
> devm guarantees that the destruction callbacks are called in the
> reverse order of registration.
That's fine.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From lorenzo.pieralisi at arm.com  Wed Jul 31 06:30:25 2013
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 31 Jul 2013 11:30:25 +0100
Subject: [PATCH 11/13] ARM: bL_switcher: veto CPU hotplug requests when
 the switcher is active
In-Reply-To: <1374550289-25305-12-git-send-email-nicolas.pitre@linaro.org>
References: <1374550289-25305-1-git-send-email-nicolas.pitre@linaro.org>
 <1374550289-25305-12-git-send-email-nicolas.pitre@linaro.org>
Message-ID: <20130731103025.GC6583@e102568-lin.cambridge.arm.com>

On Tue, Jul 23, 2013 at 04:31:27AM +0100, Nicolas Pitre wrote:
> Trying to support both the switcher and CPU hotplug at the same time
> is quickly becoming very complex due to ambiguous semantics.  So let's
> simply veto any hotplug requests when the switcher is active for now.
> 
> This restriction might be loosened eventually.
> 
> Signed-off-by: Nicolas Pitre <nico at linaro.org>
> ---
>  arch/arm/common/bL_switcher.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/arch/arm/common/bL_switcher.c b/arch/arm/common/bL_switcher.c
> index 704c4b4ef3..2fe3911601 100644
> --- a/arch/arm/common/bL_switcher.c
> +++ b/arch/arm/common/bL_switcher.c
> @@ -528,6 +528,25 @@ static int __init bL_switcher_sysfs_init(void)
>  
>  #endif  /* CONFIG_SYSFS */
>  
> +/*
> + * Veto any CPU hotplug operation while the switcher is active.
> + * We're just not ready to deal with that given the trickery involved.
> + */
> +static int bL_switcher_hotplug_callback(struct notifier_block *nfb,
> +					unsigned long action, void *hcpu)
> +{
> +	switch (action) {
> +	case CPU_UP_PREPARE:
> +	case CPU_DOWN_PREPARE:
> +		if (bL_switcher_active)
> +			return NOTIFY_BAD;

This is a bit of a sledgehammer. It implies that S2R can't be implemented when
the switcher is active. Are we really sure that hotplug, given MCPM HW
CPUs awareness, is incompatible with the switcher as it stands ?

What are the main issues that have to be tackled ?

Thanks,
Lorenzo

> +	}
> +	return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block bL_switcher_hotplug_notifier =
> +	{ &bL_switcher_hotplug_callback, NULL, 0 };
> +
>  static bool no_bL_switcher;
>  core_param(no_bL_switcher, no_bL_switcher, bool, 0644);
>  
> @@ -540,6 +559,8 @@ static int __init bL_switcher_init(void)
>  		return -EINVAL;
>  	}
>  
> +	register_cpu_notifier(&bL_switcher_hotplug_notifier);
> +
>  	if (!no_bL_switcher) {
>  		ret = bL_switcher_enable();
>  		if (ret)
> -- 
> 1.8.1.2
> 
> 
> 



From laurent.pinchart at ideasonboard.com  Wed Jul 31 06:36:07 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Wed, 31 Jul 2013 12:36:07 +0200
Subject: [PATCH v3] Documentation: dt: bindings: TI WiLink modules
In-Reply-To: <1375215668-29171-1-git-send-email-coelho@ti.com>
References: <1375215668-29171-1-git-send-email-coelho@ti.com>
Message-ID: <19103383.PkgSdCFM10@avalon>

Hi Luciano,

On Tuesday 30 July 2013 23:21:08 Luciano Coelho wrote:
> Add device tree bindings documentation for the TI WiLink modules.
> Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8
> modules is supported.
> 
> Signed-off-by: Luciano Coelho <coelho at ti.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> ---
> 
> In v3, use IRQ_TYPE_LEVEL_HIGH in the example, as suggested by Laurent.
> 
>  .../devicetree/bindings/net/wireless/ti-wilink.txt | 68
> ++++++++++++++++++++++ 1 file changed, 68 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
> b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt new file
> mode 100644
> index 0000000..aafebb1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
> @@ -0,0 +1,68 @@
> +TI WiLink Wireless Modules Device Tree Bindings
> +===============================================
> +
> +The WiLink modules provide wireless connectivity, such as WLAN,
> +Bluetooth, FM and NFC.
> +
> +There are several different modules available, which can be grouped by
> +their generation: WiLink6, WiLink7 and WiLink8.  WiLink4 is not
> +currently supported with device tree.
> +
> +Currently, only the WLAN portion of the modules is supported with
> +device tree.
> +
> +Required properties:
> +--------------------
> +
> +- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8"
> +- interrupt-parent: the interrupt controller
> +- interrupts: out-of-band WLAN interrupt
> +	See the interrupt controller's bindings documentation for
> +	detailed definition.
> +
> +Optional properties:
> +--------------------
> +
> +- clocks: list of clocks needed by the chip as follows:
> +
> +  refclock: the internal WLAN reference clock frequency (required for
> +	WiLink6 and WiLink7; not used for WiLink8).
> +
> +  tcxoclock: the internal WLAN TCXO clock frequency (required for
> +	WiLink7 not used for WiLink6 and WiLink8).
> +
> +  The clocks must be defined and named accordingly.  For example:
> +
> +  clocks = <&refclock>
> +  clock-names = "refclock";
> +
> +  refclock: refclock {
> +		     compatible = "ti,wilink-clock";
> +		     #clock-cells = <0>;
> +		     clock-frequency = <38400000>;
> +	};
> +
> +  Some modules that contain the WiLink chip provide clocks in the
> +  module itself.  In this case, we define a "ti,wilink-clock" as shown
> +  above.  But any other clock could in theory be used, so the proper
> +  clock definition should be used.
> +
> +
> +Example:
> +--------
> +
> +Example definition that can be used in OMAP4 Panda:
> +
> +wlan {
> +	compatible = "ti,wilink6";
> +	interrupt-parent = <&gpio2>;
> +	interrupts = <21 IRQ_TYPE_LEVEL_HIGH>;	/* gpio line 53 */
> +	clocks = <&refclock>;
> +	clock-names = "refclock";
> +
> +	refclock: refclock {
> +		compatible = "ti,wilink-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <38400000>;
> +	};
> +};
-- 
Regards,

Laurent Pinchart



From will.deacon at arm.com  Wed Jul 31 06:35:07 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 31 Jul 2013 11:35:07 +0100
Subject: [PATCH v3 1/3] ARM: BCM5301X: initial support for the
 BCM5301X/BCM470X SoCs with ARM CPU
In-Reply-To: <51F827EC.3090104@hauke-m.de>
References: <1374792135-30343-1-git-send-email-hauke@hauke-m.de>
 <51F28A20.7060105@hauke-m.de>
 <20130726165311.GH17886@mudshark.cambridge.arm.com>
 <201307272149.17108.arnd@arndb.de>
 <20130730133601.GN11527@mudshark.cambridge.arm.com>
 <51F827EC.3090104@hauke-m.de>
Message-ID: <20130731103507.GF23681@mudshark.cambridge.arm.com>

On Tue, Jul 30, 2013 at 09:54:04PM +0100, Hauke Mehrtens wrote:
> On 07/30/2013 03:36 PM, Will Deacon wrote:
> > On Sat, Jul 27, 2013 at 08:49:16PM +0100, Arnd Bergmann wrote:
> >> On Friday 26 July 2013, Will Deacon wrote:
> >>>>> At least, we need a pretty good explanation of what exactly is causing
> >>>>> these spurious aborts before we start ignoring them unconditionally like
> >>>>> this. You're effectively masking an extremely serious error indicator with
> >>>>> this change.
> >>>>
> >>>> This fault occurs once every boot sometime early in the boot process,
> >>>> but the actual time this happens varies randomly.
> >>>
> >>> Well that's interesting in itself. It sounds like we don't know *for sure*
> >>> whether the abort is triggered by Linux. Since the abort is imprecise, the
> >>> timing will vary.
> >>
> >> It might be possible to find out the culprit if you just enter an endless loop
> >> in the early kernel boot code. If you enter the loop before Linux does something
> >> wrong, it won't crash, otherwise it will. After that, you could bisect the
> >> boot process by moving the busy loop around.
> >>
> >> If it even crashes at the point where Linux gets entered, it's a bug in the
> >> boot loader.
> > 
> > Can you give Arnd's suggestion a go please Hauke?
> 
> Hi
> 
> I just tried that, but it did not crash in the loop. :-(

Turn that frown around -- this is a useful result! It means that the abort
is likely caused by the kernel, rather than the boot loader (although we
still can't rule it out, it depends where you put the loop).

> Now, with 3.11-rc3 it crashed reproducible after Freeing unused kernel
> memory, see this:
> 
> [    0.859198] Freeing unused kernel memory: 1124K (c0260000 - c0379000)
> [    0.866298] Unhandled fault: imprecise external abort (0x1c06) at
> 0xb6f8b005
> [    0.873538] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x00000007
> 
> Do you have some more informations about this type of error?

Hmm, so that's now exploding on a user address. Is this an A9-based SoC? If
so, can you try disabling PL310 (CONFIG_CACHE_L2X0) and see if it makes a
different please?

Cheers,

Will


From broonie at kernel.org  Wed Jul 31 06:36:10 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 31 Jul 2013 11:36:10 +0100
Subject: New dapm panic on beaver with next-20130730
In-Reply-To: <51F8B045.8030303@metafoo.de>
References: <CAOesGMig6jry1GJLoTnOqxom1KjtBTUtZz-_-SiZLpGTc3VkqA@mail.gmail.com>
 <51F8A933.4080708@metafoo.de>
 <CAOesGMjqyF7zPoGsW6oBRFey7Bc_umnoGob7oQ=_c3n7oevuaQ@mail.gmail.com>
 <51F8B045.8030303@metafoo.de>
Message-ID: <20130731103610.GH9858@sirena.org.uk>

On Wed, Jul 31, 2013 at 08:35:49AM +0200, Lars-Peter Clausen wrote:

> 0x6b6b6b6b is poisoned freed memory. According to the source neither
> the INR Mux nor the INL Mux widget should have any sinks. Can you
> add a couple more printks:

Dan Carpenter sent a patch which is probably the issue - I'm trying to
figure out how to boot my Beaver board so hopefully I can test, it'll be
in -next tomorrow anyway.
-------------- 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/20130731/62a5d1e0/attachment-0001.sig>

From mbizon at freebox.fr  Wed Jul 31 06:37:37 2013
From: mbizon at freebox.fr (Maxime Bizon)
Date: Wed, 31 Jul 2013 12:37:37 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <1441731.8CGUI1tUxh@flatron>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <51F39FD8.6080808@broadcom.com> <20130727183059.GD4813@netboy>
 <1441731.8CGUI1tUxh@flatron>
Message-ID: <1375267057.20042.52.camel@sakura.staff.proxad.net>


On Sat, 2013-07-27 at 11:51 -0700, Tomasz Figa wrote:

> Well, it depends on how we use the DT. There are (at least) two possible 
> usage scenarios:
> 
>  a) using DT as direct replacement for board files - this means that you 
>     are free to say that DTSes are strictly coupled with kernel version 
>     and you are free to modify the bindings - see the analogy to board 
>     files, where you could modify the platform data structures and could 
>     not directly copy board file from one kernel version to another,

I'm shocked to see this as a possible option.

Board files are C code anyone has the skill to edit/understand/refactor.
Moving to DT and keep them in tree tightly coupled with the kernel
version just adds another layer of indirection for *no purpose*.

The fact that we loose compiler syntax/type checking (as highlighted
somewhere else in this thread) even looks like a regression.


>  b) using DT as an ABI - this is the original way, i.e. define stable 
>     bindings and make sure that anu DTB built for older kernel will
> work, with equal or greater set of functionality on newer kernels.
> 
Linus started the whole thing some years ago by refusing to pull ARM
tree [1]. Reread his post, what he wants is clearly b).

Going a) does not solve any problem. You are just moving churn to
somewhere else. We had board files churn, then defconfigs churn, DTS
files (and associated drivers) will be next.

DT is self inflicted pain. It has to be for the greater good.

Going b) *might* allow what some people here dream about, a kernel free
of hardware knowledge. A new board could boot a kernel compiled before
it was even designed.

Now since I do "embedded" stuff everyday, I don't think b) can apply to
the whole ARM world. There is just to much hardware peculiarity.


[1] https://lkml.org/lkml/2011/3/30/525

-- 
Maxime




From will.deacon at arm.com  Wed Jul 31 06:38:47 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 31 Jul 2013 11:38:47 +0100
Subject: [PATCH] ARM: Fix r7/r11 confusion when CONFIG_THUMB2_KERNEL=y [OT]
In-Reply-To: <20130731110309.758cf0aa@armhf>
References: <1373685501-1620-1-git-send-email-jld@mozilla.com>
 <20130715135420.GG10000@mudshark.cambridge.arm.com>
 <20130720044655.GC9433@mozilla.com>
 <20130721213753.GA29879@mudshark.cambridge.arm.com>
 <20130722185234.GA14519@localhost.localdomain>
 <20130729212140.GB12681@mozilla.com>
 <20130730092517.GB2478@localhost.localdomain>
 <20130730113853.46cbb00a@armhf>
 <20130730094904.GH11527@mudshark.cambridge.arm.com>
 <20130731110309.758cf0aa@armhf>
Message-ID: <20130731103847.GG23681@mudshark.cambridge.arm.com>

[Adding Gregory, as this is a Marvell CPU]

On Wed, Jul 31, 2013 at 10:03:09AM +0100, Jean-Francois Moine wrote:
> I compiled the 3.11.0-rc3 with gcc-4.8.1 and I still get oops in ext3
> (no problem when compiled with gcc-4.6). Here is the dmesg.

There were some recent errata fixes from Gregory and I don't think they all
made it into mainline yet. Gregory -- does the panic below look like
something that could be related to the problems you were seeing with DMA?

Cheers,

Will

> Booting Linux on physical CPU 0x0
> Linux version 3.11.0-rc3-00004-g36f571e-dirty (jef at armhf) (gcc version 4.8.1 (Debian 4.8.1-8) ) #1 PREEMPT Wed Jul 31 09:22:30 CEST 2013
> CPU: ARMv7 Processor [560f5815] revision 5 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
> Machine: Marvell Dove (Flattened Device Tree), model: SolidRun CuBox
> cma: CMA: reserved 32 MiB at 3e000000
> Memory policy: ECC disabled, Data cache writeback
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 804ebd2c, node_mem_map 8075b000
>   Normal zone: 2048 pages used for memmap
>   Normal zone: 0 pages reserved
>   Normal zone: 262144 pages, LIFO batch:31
> CPU: All CPU(s) started in SVC mode.
> pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> pcpu-alloc: [0] 0
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
> Kernel command line: console=ttyS0,115200n8 console=tty1,115200 root=/dev/sda7 rootwait video=HDMI-A-1:1920x1080-32 at 60
> PID hash table entries: 4096 (order: 2, 16384 bytes)
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 1001516K/1048576K available (3715K kernel code, 177K rwdata, 980K rodata, 135K init, 129K bss, 47060K reserved)
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
>     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>     modules : 0x7f000000 - 0x80000000   (  16 MB)
>       .text : 0x80008000 - 0x8049df34   (4696 kB)
>       .init : 0x8049e000 - 0x804bfe68   ( 136 kB)
>       .data : 0x804c0000 - 0x804ec5c0   ( 178 kB)
>        .bss : 0x804ec5c0 - 0x8050cad0   ( 130 kB)
> Preemptible hierarchical RCU implementation.
>         Dump stacks of tasks blocking RCU-preempt GP.
> NR_IRQS:135
> sched_clock: 32 bits at 166MHz, resolution 5ns, wraps every 25769ms
> Console: colour dummy device 80x30
> console [tty1] enabled
> Calibrating delay loop... 789.70 BogoMIPS (lpj=3948544)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> Setting up static identity map for 0x803a6620 - 0x803a6654
> devtmpfs: initialized
> pinctrl core: initialized pinctrl subsystem
> regulator-dummy: no parameters
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> Dove 88AP510 SoC
> Tauros2: Disabling L2 prefetch.
> Tauros2: Disabling line fill burt8.
> Tauros2: Enabling L2 cache.
> Tauros2: L2 cache support initialised in ARMv7 mode.
> bio: create slab <bio-0> at 0
> USB Power: Failed to request enable GPIO1: -517
> reg-fixed-voltage 1.regulator: Failed to register regulator: -517
> platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
> SCSI subsystem initialized
> libata version 3.00 loaded.
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Linux video capture interface: v2.00
> Advanced Linux Sound Architecture Driver Initialized.
> Switched to clocksource orion_clocksource
> NET: Registered protocol family 2
> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP: reno registered
> UDP hash table entries: 512 (order: 1, 8192 bytes)
> UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
> NET: Registered protocol family 1
> audit: initializing netlink socket (disabled)
> type=2000 audit(0.070:1): initialized
> msgmni has been set to 2020
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> dove-pinctrl f10d0200.pinctrl: registered pinctrl driver
> mv_xor f1060800.dma-engine: Marvell shared XOR driver
> mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
> mv_xor f1060800.dma-engine: Marvell XOR: ( xor cpy )
> mv_xor f1060900.dma-engine: Marvell shared XOR driver
> mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
> mv_xor f1060900.dma-engine: Marvell XOR: ( xor cpy )
> Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 7) is a 16550A
> console [ttyS0] enabled
> brd: module loaded
> sata_mv f10a0000.sata: version 1.28
> sata_mv f10a0000.sata: slots 32 ports 1
> scsi0 : sata_mv
> ata1: SATA max UDMA/133 irq 62
> libphy: orion_mdio_bus: probed
> mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
> libphy: PHY orion-mdio-mii:08 not found
> libphy: PHY orion-mdio-mii:09 not found
> libphy: PHY orion-mdio-mii:0a not found
> libphy: PHY orion-mdio-mii:0b not found
> libphy: PHY orion-mdio-mii:0c not found
> libphy: PHY orion-mdio-mii:0d not found
> libphy: PHY orion-mdio-mii:0e not found
> libphy: PHY orion-mdio-mii:0f not found
> libphy: PHY orion-mdio-mii:10 not found
> libphy: PHY orion-mdio-mii:11 not found
> libphy: PHY orion-mdio-mii:12 not found
> libphy: PHY orion-mdio-mii:13 not found
> libphy: PHY orion-mdio-mii:14 not found
> libphy: PHY orion-mdio-mii:15 not found
> libphy: PHY orion-mdio-mii:16 not found
> libphy: PHY orion-mdio-mii:17 not found
> libphy: PHY orion-mdio-mii:18 not found
> libphy: PHY orion-mdio-mii:19 not found
> libphy: PHY orion-mdio-mii:1a not found
> libphy: PHY orion-mdio-mii:1b not found
> libphy: PHY orion-mdio-mii:1c not found
> libphy: PHY orion-mdio-mii:1d not found
> libphy: PHY orion-mdio-mii:1e not found
> libphy: PHY orion-mdio-mii:1f not found
> libphy: PHY orion-mdio-mii:00 not found
> mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:b6:3b:10
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-orion: EHCI orion driver
> orion-ehci f1050000.usb-host: EHCI Host Controller
> orion-ehci f1050000.usb-host: new USB bus registered, assigned bus number 1
> orion-ehci f1050000.usb-host: irq 24, io mem 0xf1050000
> orion-ehci f1050000.usb-host: USB 2.0 started, EHCI 1.00
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> orion-ehci f1051000.usb-host: EHCI Host Controller
> orion-ehci f1051000.usb-host: new USB bus registered, assigned bus number 2
> orion-ehci f1051000.usb-host: irq 25, io mem 0xf1051000
> orion-ehci f1051000.usb-host: USB 2.0 started, EHCI 1.00
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 1 port detected
> usbcore: registered new interface driver usb-storage
> mousedev: PS/2 mouse device common for all mice
> rtc-mv f10d8500.rtc: rtc core: registered f10d8500.rtc as rtc0
> sdhci: Secure Digital Host Controller Interface driver
> sdhci: Copyright(c) Pierre Ossman
> sdhci-pltfm: SDHCI platform and OF driver helper
> mmc0: no vqmmc regulator found
> mmc0: no vmmc regulator found
> mmc0: SDHCI controller on f1092000.sdio [f1092000.sdio] using DMA
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> TCP: cubic registered
> NET: Registered protocol family 10
> NET: Registered protocol family 17
> VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5
> ThumbEE CPU extension supported.
> PJ4 iWMMXt coprocessor enabled.
> USB Power: 5000 mV
> rtc-mv f10d8500.rtc: setting system clock to 2013-07-31 08:15:22 UTC (1375258522)
> ALSA device list:
>   No soundcards found.
> ata1: SATA link down (SStatus 0 SControl F300)
> mmc0: new high speed SDHC card at address e624
> mmcblk0: mmc0:e624 SU16G 14.8 GiB
>  mmcblk0: p1 p2 p3
> Waiting for root device /dev/sda7...
> usb 1-1: new high-speed USB device number 2 using orion-ehci
> usb-storage 1-1:1.0: USB Mass Storage device detected
> scsi1 : usb-storage 1-1:1.0
> usb 2-1: new high-speed USB device number 2 using orion-ehci
> hub 2-1:1.0: USB hub found
> hub 2-1:1.0: 4 ports detected
> usb 2-1.4: new high-speed USB device number 3 using orion-ehci
> hub 2-1.4:1.0: USB hub found
> hub 2-1.4:1.0: 4 ports detected
> usb 2-1.4.2: new high-speed USB device number 4 using orion-ehci
> scsi 1:0:0:0: Direct-Access     WDC WD25 00JB-55REA0      20.0 PQ: 0 ANSI: 0
> sd 1:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB)
> sd 1:0:0:0: [sda] Write Protect is off
> sd 1:0:0:0: [sda] Mode Sense: 03 00 00 00
> sd 1:0:0:0: [sda] No Caching mode page present
> sd 1:0:0:0: [sda] Assuming drive cache: write through
> sd 1:0:0:0: [sda] No Caching mode page present
> sd 1:0:0:0: [sda] Assuming drive cache: write through
>  sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
> sd 1:0:0:0: [sda] No Caching mode page present
> sd 1:0:0:0: [sda] Assuming drive cache: write through
> sd 1:0:0:0: [sda] Attached SCSI disk
> EXT3-fs (sda7): mounted filesystem with ordered data mode
> kjournald starting.  Commit interval 5 seconds
> usb 2-1.4.3: new low-speed USB device number 5 using orion-ehci
> VFS: Mounted root (ext3 filesystem) readonly on device 8:7.
> devtmpfs: mounted
> Freeing unused kernel memory: 132K (8049e000 - 804bf000)
> input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.0/input/input0
> hid-generic 0003:13BA:0017.0001: input: USB HID v1.10 Keyboard [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input0
> input: Generic USB K/B as /devices/soc.0/f1051000.usb-host/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.1/input/input1
> hid-generic 0003:13BA:0017.0002: input: USB HID v1.10 Mouse [Generic USB K/B] on usb-f1051000.usb-host-1.4.3/input1
> udevd[583]: starting version 175
> [drm] Initialized drm 1.1.0 20060810
> cfg80211: Calling CRDA to update world regulatory domain
> simple-dt-audio sound.5:  dit-hifi <-> f10b4000.audio-controller mapping ok
> tda998x 0-0070: found TDA19988
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] No driver support for vblank timestamp query.
> usb 2-1.4.2: reset high-speed USB device number 4 using orion-ehci
> usb 2-1.4.2: Loading firmware file isl3887usb
> usbcore: registered new interface driver p54usb
> ieee80211 phy0: p54 detected a LM87 firmware
> p54: rx_mtu reduced from 3240 to 2384
> ieee80211 phy0: FW rev 2.13.25.0 - Softmac protocol 5.9
> ieee80211 phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
> Console: switching to colour frame buffer device 240x67
> dove-drm video.6: fb0:  frame buffer device
> dove-drm video.6: registered panic notifier
> [drm] Initialized dove-drm 1.0.0 20130516 on minor 0
> ieee80211 phy0: hwaddr 00:12:bf:1e:9c:e4, MAC:isl3887 RF:Frisbee
> ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> usb 2-1.4.2: is registered as 'phy0'
> Unable to handle kernel NULL pointer dereference at virtual address 00000003
> pgd = bd374000
> [00000003] *pgd=3d3af831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 811 [#1] PREEMPT ARM
> Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
> CPU: 0 PID: 731 Comm: usb-db Not tainted 3.11.0-rc3-00004-g36f571e-dirty #1
> task: bda0dc00 ti: bd2fa000 task.ti: bd2fa000
> PC is at do_mpage_readpage+0x754/0x888
> LR is at bio_add_page+0x44/0x4c
> pc : [<800e89c0>]    lr : [<800e05e4>]    psr: 600e0013
> sp : bd2fbc74  ip : bd2fbcc8  fp : bd2fbc9c
> r10: 00000003  r9 : 00000000  r8 : 00000004
> r7 : 00000001  r6 : 800e8ca4  r5 : bd2fbc70  r4 : 00000003
> r3 : 00001000  r2 : 00000003  r1 : 00000000  r0 : bd2fbc9c
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 10c5387d  Table: 3d374019  DAC: 00000015
> Process usb-db (pid: 731, stack limit = 0xbd2fa240)
> Stack: (0xbd2fbc74 to 0xbd2fc000)
> bc60:                                              00000001 bd2fbd64 00200200
> bc80: 00100100 bd53cd54 bd9f1340 80eed380 bd2fbd34 bd2fbca0 800e8bc8 800e8278
> bca0: bd2fbcc8 bd2fbcbc 8011c554 000000c1 804ebd2c 8011c554 00000002 00000003
> bcc0: 0028de87 00000000 00000000 bd2fbcd8 80eed380 803a2f54 0028df40 00000000
> bce0: 00001000 00000000 bd402ac0 8003b810 bd2fbcf0 bd2fbcf0 bd53ccb4 bd2fbd7c
> bd00: bd53ccbc 00000002 bd2fbd24 8011a00c 00000004 00000004 00000000 0000007a
> bd20: 00000000 00000004 bd2fbd44 bd2fbd38 8011a030 800e8b00 bd2fbdac bd2fbd48
> bd40: 8007dd28 8011a018 bda54780 00000001 bd53cd54 00000004 bd53cd58 bd2fbd64
> bd60: 800c23bc bd2fbd64 bd2fbd64 91827364 bd8d5de8 bd8d5de8 bd2fbd78 bd2fbd78
> bd80: 800add50 bd53cd54 bda54780 bda547c8 00000000 00000020 00000003 bd53cd54
> bda0: bd2fbdec bd2fbdb0 8007e0e0 8007db44 00000003 bd11e470 bd95462c bdbe1540
> bdc0: bd2fbddc bd53cd54 00000000 00000000 bd53cc98 00000001 00000000 bda54780
> bde0: bd2fbe0c bd2fbdf0 8007e3b8 8007dfc4 00000000 00000001 00000000 bd53cd54
> be00: bd2fbeac bd2fbe10 8007471c 8007e378 00000001 bd954b78 bd9545f8 bd9545f8
> be20: 76f24000 76f25000 00000001 00080001 bd2fbeb8 bd2fbec0 ffffffff 00000000
> be40: 00000000 bdbe1540 00000001 bd954608 00000001 00000fff bd2fa000 bda547c8
> be60: 00000000 00000001 76f25000 00000000 00000000 00001000 76f24000 00000000
> be80: 80097780 00000000 00000000 00001000 bd2fbf78 bda54780 bda0dc00 00020000
> bea0: bd2fbf44 bd2fbeb0 800abf60 800741cc 00000000 00000000 76f24000 00001000
> bec0: 00000001 bda54780 00000000 00000000 00000000 bda0dc00 00000000 00000000
> bee0: 00000000 00000000 00000000 00000000 00001000 00000000 00001000 00000000
> bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> bf20: bda54780 76f24000 bd2fbf78 76f24000 00000000 00001000 bd2fbf74 bd2fbf48
> bf40: 800ac69c 800abeec 00800007 00000022 00000000 00000000 bda54780 76f24000
> bf60: 00000000 00001000 bd2fbfa4 bd2fbf78 800acd84 800ac608 00000000 00000000
> bf80: 017f7278 76ec7c58 00000000 00000003 8000e604 bd2fa000 00000000 bd2fbfa8
> bfa0: 8000e480 800acd4c 017f7278 76ec7c58 00000003 76f24000 00001000 00000000
> bfc0: 017f7278 76ec7c58 00000000 00000003 7eac3ad0 7eac3ad4 76f29000 00000000
> bfe0: 00000000 7eac3a64 76e389cf 76e6f21c 400e0010 00000003 00000000 00000000
> Backtrace:
> [<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
> [<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
> [<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
> [<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
> [<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
> [<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
>  r4:bd53cd54
> [<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
> [<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
>  r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
> r4:bda54780
> [<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
>  r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
> r4:00000000
> [<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
>  r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
> r4:017f7278
> Code: e0854184 e51b0084 e14424d8 e51b40a0 (e1c420f0)
> ---[ end trace e23d6b4d1dcd7a83 ]---
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 731 at /home/jef/kernel/kernel/exit.c:703 do_exit+0x54/0x900()
> Modules linked in: arc4 p54usb p54common crc_ccitt fbcon bitblit mac80211 softcursor font cfg80211 dove_drm tda998x drm_kms_helper drm clk_si5351 snd_soc_simple_dt_card snd_soc_spdif_tx mv_cesa snd_soc_kirkwood
> CPU: 0 PID: 731 Comm: usb-db Tainted: G      D      3.11.0-rc3-00004-g36f571e-dirty #1
> Backtrace:
> [<800112c4>] (dump_backtrace+0x0/0x110) from [<800114dc>] (show_stack+0x18/0x1c)
>  r6:000002bf r5:00000009 r4:00000000 r3:00000000
> [<800114c4>] (show_stack+0x0/0x1c) from [<803a25b0>] (dump_stack+0x24/0x28)
> [<803a258c>] (dump_stack+0x0/0x28) from [<8001ad28>] (warn_slowpath_common+0x74/0x8c)
> [<8001acb4>] (warn_slowpath_common+0x0/0x8c) from [<8001ade4>] (warn_slowpath_null+0x24/0x2c)
>  r8:00000811 r7:bd2fa000 r6:80439cc4 r5:0000000b r4:804cb598
> [<8001adc0>] (warn_slowpath_null+0x0/0x2c) from [<8001f248>] (do_exit+0x54/0x900)
> [<8001f1f4>] (do_exit+0x0/0x900) from [<80011664>] (die+0x184/0x238)
>  r7:bd2fa000
> [<800114e0>] (die+0x0/0x238) from [<803a07dc>] (__do_kernel_fault.part.10+0x6c/0x7c)
> [<803a0770>] (__do_kernel_fault.part.10+0x0/0x7c) from [<8001420c>] (do_sect_fault+0x0/0x18)
>  r7:bdbe1540 r3:bd2fbc28
> [<8001417c>] (do_bad_area+0x0/0x90) from [<80015d10>] (do_alignment+0xd0/0x844)
>  r7:00000003 r6:800e89c0 r5:804ec85c r4:bd2fbc28
> [<80015c40>] (do_alignment+0x0/0x844) from [<80008460>] (do_DataAbort+0x40/0xa0)
> [<80008420>] (do_DataAbort+0x0/0xa0) from [<80011fb8>] (__dabt_svc+0x38/0x60)
> Exception stack(0xbd2fbc28 to 0xbd2fbc70)
> bc20:                   bd2fbc9c 00000000 00000003 00001000 00000003 bd2fbc70
> bc40: 800e8ca4 00000001 00000004 00000000 00000003 bd2fbc9c bd2fbcc8 bd2fbc74
> bc60: 800e05e4 800e89c0 600e0013 ffffffff
>  r8:00000004 r7:bd2fbc5c r6:ffffffff r5:600e0013 r4:800e89c0
> [<800e826c>] (do_mpage_readpage+0x0/0x888) from [<800e8bc8>] (mpage_readpages+0xd4/0x130)
> [<800e8af4>] (mpage_readpages+0x0/0x130) from [<8011a030>] (ext3_readpages+0x24/0x28)
> [<8011a00c>] (ext3_readpages+0x0/0x28) from [<8007dd28>] (__do_page_cache_readahead+0x1f0/0x2d8)
> [<8007db38>] (__do_page_cache_readahead+0x0/0x2d8) from [<8007e0e0>] (ondemand_readahead+0x128/0x238)
> [<8007dfb8>] (ondemand_readahead+0x0/0x238) from [<8007e3b8>] (page_cache_sync_readahead+0x4c/0x6c)
> [<8007e36c>] (page_cache_sync_readahead+0x0/0x6c) from [<8007471c>] (generic_file_aio_read+0x55c/0x7c0)
>  r4:bd53cd54
> [<800741c0>] (generic_file_aio_read+0x0/0x7c0) from [<800abf60>] (do_sync_read+0x80/0xa8)
> [<800abee0>] (do_sync_read+0x0/0xa8) from [<800ac69c>] (vfs_read+0xa0/0x148)
>  r9:00001000 r8:00000000 r7:76f24000 r6:bd2fbf78 r5:76f24000
> r4:bda54780
> [<800ac5fc>] (vfs_read+0x0/0x148) from [<800acd84>] (SyS_read+0x44/0x80)
>  r9:00001000 r8:00000000 r7:76f24000 r6:bda54780 r5:00000000
> r4:00000000
> [<800acd40>] (SyS_read+0x0/0x80) from [<8000e480>] (ret_fast_syscall+0x0/0x30)
>  r9:bd2fa000 r8:8000e604 r7:00000003 r6:00000000 r5:76ec7c58
> r4:017f7278
> ---[ end trace e23d6b4d1dcd7a84 ]---
> EXT3-fs (sda7): using internal journal
> IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
> wlan1: authenticate with 00:24:d4:9c:29:68
> wlan1: send auth to 00:24:d4:9c:29:68 (try 1/3)
> wlan1: authenticated
> p54usb 2-1.4.2:1.0 wlan1: disabling HT/VHT due to WEP/TKIP use
> wlan1: associate with 00:24:d4:9c:29:68 (try 1/3)
> wlan1: RX AssocResp from 00:24:d4:9c:29:68 (capab=0x411 status=0 aid=1)
> IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
> wlan1: associated
> 
> --
> Ken ar c'henta? |             ** Breizh ha Linux atav! **
> Jef             |               http://moinejf.free.fr/
> 


From htejun at gmail.com  Wed Jul 31 06:41:25 2013
From: htejun at gmail.com (Tejun Heo)
Date: Wed, 31 Jul 2013 06:41:25 -0400
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731102853.GD1754@pengutronix.de>
References: <1375232669-27846-1-git-send-email-festevam@gmail.com>
 <1375232669-27846-2-git-send-email-festevam@gmail.com>
 <20130731073306.GZ1754@pengutronix.de>
 <20130731082054.GF8540@nchen-desktop>
 <20130731084645.GB1754@pengutronix.de>
 <20130731090512.GD9858@sirena.org.uk>
 <20130731094434.GC1754@pengutronix.de>
 <20130731095411.GA2810@htj.dyndns.org>
 <20130731102853.GD1754@pengutronix.de>
Message-ID: <20130731104125.GF2810@htj.dyndns.org>

On Wed, Jul 31, 2013 at 12:28:53PM +0200, Uwe Kleine-K?nig wrote:
> Well, you cannot avoid assuming that the irq is still active when your
> driver's remove callback is called. But I agree about crappyness at the
> end of the destruction path. The problem is that crap is as easy as:
> 
> 	probe(..)
> 	{
> 		clk = devm_get_clk(...);
> 		clk_prepare_enable(clk);
> 		writel(1, base + IRQENABLE);
> 		devm_request_irq(...);
> 	}
> 
> 	remove(..)
> 	{
> 		writel(0, base + IRQENABLE);
> 		clk_disable_unprepare(clk);
> 	}
> 
> and I think there are more and more drivers doing that.

Oh, so, the problem is that the driver is mixing devm and non-devm
resource management and ending up messing the order of shutdown?
Well, the obvious solution is using devm for clk too.  devm does
provide constructs to build custom destruction sequence so that such
calls can be mixed but it's a bit of hassle and mostly meant for
driver midlayers (libata, firewire, usb and so on) so that they can
provide nicely wrapped init/exit helpers for low level drivers.

In general, partial devm conversion can easily lead to subtle shutdown
order problems and it's best to go all the way.

Thanks.

-- 
tejun


From linux at arm.linux.org.uk  Wed Jul 31 06:56:43 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 31 Jul 2013 11:56:43 +0100
Subject: [RFC/RFT PATCH 4/5] ARM: mm: change max*pfn to include the
 physical offset of memory
In-Reply-To: <1373665694-7580-5-git-send-email-santosh.shilimkar@ti.com>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
 <1373665694-7580-5-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <20130731105643.GW24642@n2100.arm.linux.org.uk>

On Fri, Jul 12, 2013 at 05:48:13PM -0400, Santosh Shilimkar wrote:
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index 5b579b9..b2d5937 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -47,12 +47,12 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
>  #ifndef __arch_pfn_to_dma
>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>  {
> -	return (dma_addr_t)__pfn_to_bus(pfn);
> +	return (dma_addr_t)__pfn_to_bus(pfn + PHYS_PFN_OFFSET);
>  }
>  
>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>  {
> -	return __bus_to_pfn(addr);
> +	return __bus_to_pfn(addr) - PHYS_PFN_OFFSET;
>  }
>  
>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
> @@ -64,15 +64,16 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>  {
>  	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
>  }
> +
>  #else
>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>  {
> -	return __arch_pfn_to_dma(dev, pfn);
> +	return __arch_pfn_to_dma(dev, pfn + PHYS_PFN_OFFSET);
>  }
>  
>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>  {
> -	return __arch_dma_to_pfn(dev, addr);
> +	return __arch_dma_to_pfn(dev, addr) - PHYS_PFN_OFFSET;
>  }
>  
>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
> @@ -86,6 +87,13 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>  }
>  #endif

Note that I don't think the above are correct - the 'pfn' argument to the
above functions already includes the PFN offset of physical memory -
they're all physical_address >> PAGE_SHIFT values.

> +/* The ARM override for dma_max_pfn() */
> +static inline unsigned long dma_max_pfn(struct device *dev)
> +{
> +	return dma_to_pfn(dev, *dev->dma_mask);
> +}
> +#define dma_max_pfn(dev) dma_max_pfn(dev)

So I'd suggest this becomes:

	return PHYS_PFN_OFFSET + dma_to_pfn(dev, *dev->dma_mask);


From tomasz.figa at gmail.com  Wed Jul 31 06:59:59 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 31 Jul 2013 12:59:59 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <1375267057.20042.52.camel@sakura.staff.proxad.net>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1441731.8CGUI1tUxh@flatron>
 <1375267057.20042.52.camel@sakura.staff.proxad.net>
Message-ID: <1479410.BSGDrOcRvP@thinkpad>

On Wednesday 31 of July 2013 12:37:37 Maxime Bizon wrote:
> On Sat, 2013-07-27 at 11:51 -0700, Tomasz Figa wrote:
> > Well, it depends on how we use the DT. There are (at least) two possible
> > 
> > usage scenarios:
> >  a) using DT as direct replacement for board files - this means that you
> >  
> >     are free to say that DTSes are strictly coupled with kernel version
> >     and you are free to modify the bindings - see the analogy to board
> >     files, where you could modify the platform data structures and could
> >     not directly copy board file from one kernel version to another,
> 
> I'm shocked to see this as a possible option.
> 
> Board files are C code anyone has the skill to edit/understand/refactor.
> Moving to DT and keep them in tree tightly coupled with the kernel
> version just adds another layer of indirection for *no purpose*.

Well, I agree that it's not the most fortunate scenario, but it is not that 
bad as it might seem. It still has the benefit of separating hardware data 
(including board-specific data) from kernel code and has all the benefits of DT, 
e.g. easy way to specify relations between devices (phandles), no need to 
manually register any resources, platform data or platform devices, in other 
words, when describing hardware you just care about the hardware, not how the 
kernel works.

> The fact that we loose compiler syntax/type checking (as highlighted
> somewhere else in this thread) even looks like a regression.

Syntax checking is already there. We don't have semantic checking yet, but we 
are working on this.

> >  b) using DT as an ABI - this is the original way, i.e. define stable
> >  
> >     bindings and make sure that anu DTB built for older kernel will
> > 
> > work, with equal or greater set of functionality on newer kernels.
> 
> Linus started the whole thing some years ago by refusing to pull ARM
> tree [1]. Reread his post, what he wants is clearly b).
> 
> Going a) does not solve any problem. You are just moving churn to
> somewhere else. We had board files churn, then defconfigs churn, DTS
> files (and associated drivers) will be next.
> 
> DT is self inflicted pain. It has to be for the greater good.

It has several benefits over board files that I mentioned above, possible 
without fully separating them from kernel tree.

> Going b) *might* allow what some people here dream about, a kernel free
> of hardware knowledge. A new board could boot a kernel compiled before
> it was even designed.

This is very unlikely to happen. You can already see problems with defining 
bindings for existing hardware and what to say about hardware that is not even 
designed yet? Unless all the board uses is a set of already supported 
components, that have bindings defined and drivers merged, you would still need 
to provide remaining drivers and bindings for them.

> Now since I do "embedded" stuff everyday, I don't think b) can apply to
> the whole ARM world. There is just to much hardware peculiarity.

That's why I think we need a hybrid solution. Staging bindings could use a) 
and those stable one would use b). Staging bindings would be fixed over time if 
needed and if they turn out to be fine, they can be stabilized and move to b).

So basically, you can get all the stable functionality with one DTB on any 
kernel released after the functionality got stable, but during development of 
some functionality you might need to change the DTB to test the development.

Best regards,
Tomasz
 
> [1] https://lkml.org/lkml/2011/3/30/525


From B44344 at freescale.com  Wed Jul 31 07:09:29 2013
From: B44344 at freescale.com (Goel Arpit-B44344)
Date: Wed, 31 Jul 2013 11:09:29 +0000
Subject: [PATCH 0/2] Make PPC macro spin_event_timeout() architecture
 independent
In-Reply-To: <CAMuHMdXP3-uKbftP-2UeZdE6X_iTi1podNDh0aVF3bJwDYssdg@mail.gmail.com>
References: <1375187900-17582-1-git-send-email-B44344@freescale.com>
 <CAMuHMdXP3-uKbftP-2UeZdE6X_iTi1podNDh0aVF3bJwDYssdg@mail.gmail.com>
Message-ID: <0DFB48290CDB0C4680160EBE62E8F9A809E9A13C@039-SN2MPN1-023.039d.mgd.msft.net>

On Tue, Jul 30, 2013 at 2:38 PM, Arpit Goel <B44344 at freescale.com> wrote:
> This patch-set moves USECS_PER_JIFFY to architecture timex.h from 
> architecture specific C files. Patch-set further uses this to make PPC 
> macro
> spin_event_timeout() architecture independent. This change enables 
> drivers to use spin_event_timeout() even in non-PowerPC based SoC's.
>
> This patchset has been compiled for ARM, PowerPC and x86.
>
> Patch[1/2] : Moves USECS_PER_JIFFY to architecture specific timex.h files from
>              architecture specific C files.

>  arch/arm/include/asm/timex.h      |  2 ++
>  arch/arm/kernel/time.c            |  3 ---
>  arch/m32r/include/asm/timex.h     |  2 ++
>  arch/m32r/kernel/time.c           |  3 ---
>  arch/m68k/hp300/time.c            |  4 +---
>  arch/m68k/include/asm/timex.h     |  2 ++
>  arch/s390/include/asm/timex.h     |  2 ++
>  arch/s390/kernel/time.c           |  2 --
>  arch/sparc/include/asm/timex_32.h |  2 ++  
> arch/sparc/include/asm/timex_64.h |  2 ++
>  arch/sparc/kernel/pcic.c          |  1 -

As the definition is the same on all architectures, why not move it to <linux/delay.h>?

[Arpit] I will add USECS_PER_JIFFY definition to <linux/timex.h> and will keep 
        definitions in <arch/timex.h> as it is. So that USECS_PER_JIFFY is available 
	  for generic use and architecture specific implementation can override it.	

> Patch[2/2] : Converts PPC macro spin_event_timeout() in architecture independent
>              macro.

>  include/linux/delay.h             | 40 +++++++++++++++++++++++++++++++++++++++

After your first patch, USECS_PER_JIFFY is still available only on arm/m32r/m68k/s390/sparc. What about other architectures?
If anyone uses spin_event_timeout() on e.g. x86, it will fail to compile.
 
[Arpit] After adding USEC_PER_JIFFY to <linux/timex.h>, this issue can be addressed as well.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From laurent.pinchart at ideasonboard.com  Wed Jul 31 07:11:33 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Wed, 31 Jul 2013 13:11:33 +0200
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <12170068.F0utKQgh5l@flatron>
References: <1624911.6TtmtVmU1T@avalon> <12170068.F0utKQgh5l@flatron>
Message-ID: <2175074.sF1r3oKahE@avalon>

Hi Tomasz,

On Sunday 28 July 2013 12:07:48 Tomasz Figa wrote:
> On Wednesday 24 of July 2013 01:21:44 Laurent Pinchart wrote:
> > Hello,
> > 
> > I'm running into an issue on several Renesas SoC with IRQ domains and
> > GPIOs.
> > 
> > On sh73a0, r8a73a4 and r8a7740, GPIOs and external interrupts are
> > handled by two separate IP cores, namely the PFC (Pin Function
> > Controller) and INTC (Interrupt Controller). The former is handled by
> > the sh-pfc driver (drivers/pinctrl/sh-pfc) and the later by the
> > irq-renesas-intc-irqpin driver (drivers/irqchip), referred to below as
> > the irqpin driver.
> 
> Is the INTC used for anything more than just external interrupts on GPIO
> lines?

Yes, it also handles other interrupt sources (NMI and peripherals), but those 
are not implemented now. The peripheral interrupts are also handled by the 
GIC, which is preferred over INTC.

> > The sh73a0, for instance, has 32 external interrupt lines that are
> > multiplexed on pins usable as GPIOs. Both the GPIO and external
> > interrupt functions are usable at the same time, which allows reading
> > the state of the interrupt lines.
> > 
> > These external interrupts are for MMC/SD support, among other devices.
> > In this specific case the MMC/SD Card Detect signal is wired to one of
> > the external interrupt signals, and the corresponding GPIO is passed to
> > the MMC/SD controller driver. Depending on other configuration
> > parameters the driver can then either poll the Card Detect signal, or
> > register an interrupt handler to detect changes in the signal state.
> > This features is implemented by the MMC/SD core, which call
> > gpio_to_irq() on the GPIO to retrieve the corresponding IRQ number.
> > 
> > On non-DT systems the external IRQs are statically mapped at a known
> > offset. The sh-pfc driver, to implement the gpio_to_irq() function
> > (through its gpiochip .to_irq() handler), simply searches a
> > SoC-specific lookup table for the fixed IRQ number associated with a
> > given GPIO.
> > 
> > However, on DT systems, IRQs are mapped dynamically on demand. The
> > irqpin driver registers a simple IRQ domain, and the
> > irq_create_mapping() function can then be used to map a given IRQ,
> > specified as an offset in the domain. This is where the problem
> > appears, as the irqchip .to_irq() function is implemented in the sh-pfc
> 
> I assume it should be s/irqchip/gpiochip/ in the line above, shouldn't it?

Yes, my bad.

> > driver, which doesn't have access to the IRQ domain registered by the
> > irqpin driver.
> > 
> > I could hack around this by exporting a function in the irqpin driver
> > that would map an IRQ, and call that function from the sh-pfc driver.
> > I'd rather avoid that solution as it would add a direct dependency
> > between the two drivers.
> 
> If you could just get the IRQ domain registered by irqpin driver and use
> it in sh-pfc, then I guess it would solve your problem, as you could
> simply call irq_create_mapping() with the domain and hwirq as args in your
> gpiochip .to_irq() callback.
>
> I'm not sure if it's not a hack, but you could add a property to the node
> of your pin controller that would contain a phandle to your interrupt
> controller. Then you could use of_parse_phandle() to get to device node of
> the INTC and then irq_find_host() to retrieve irq domain associated with
> it.

That was my initial idea. However, one on of the SoCs, the GPIO interrupts are 
divided in two separate blocks, handled by two different interrupt controller 
instances. I could thus have a list of phandle + range, but that becomes 
pretty hackish. Specifying the interrupts explicitly would be more extensible.

> > Has anyone run into a similar issue ? My gut feeling is that the
> > architecture isn't right somewhere, but I can't really pinpoint where.
> > As the external IRQs are handled by an IP core separate from the PFC
> 
> Well, the fact that it's separate doesn't mean anything yet. Here my
> question whether it's used exclusively for GPIO interrupts or not becomes
> significant. If yes, maybe it could be simply moved to the pinctrl driver?

Depending on the SoC, I have two different IRQ controllers used for GPIO 
interrupts. They're called INTC and IRQC. INTC has other purposes (although 
not implemented at the moment). The IRQC instances used for GPIO interrupts 
are (at the moment) dedicated to GPIO interrupts, but other instances of the 
same IP core are used for other interrupts, so a separate driver makes sense 
in my opinion.

-- 
Regards,

Laurent Pinchart



From laurent.pinchart at ideasonboard.com  Wed Jul 31 07:14:47 2013
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Wed, 31 Jul 2013 13:14:47 +0200
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <20130728050021.4370E3E0A24@localhost>
References: <1624911.6TtmtVmU1T@avalon> <1681089.qGWOhLKTTo@avalon>
 <20130728050021.4370E3E0A24@localhost>
Message-ID: <26968517.tbY84mICFD@avalon>

Hi Grant,

On Saturday 27 July 2013 23:00:21 Grant Likely wrote:
> On Thu, 25 Jul 2013 15:22:29 +0200, Laurent Pinchart wrote:
> > On Thursday 25 July 2013 14:15:56 Mark Brown wrote:
> > > On Thu, Jul 25, 2013 at 11:45:33AM +0200, Laurent Pinchart wrote:
> > > > The two devices are independent, so there's no real parent/child
> > > > relationship. However, as Grant proposed, I could list all the
> > > > interrupts associated with GPIOs in the GPIO controller DT node. I
> > > > would then just call irq_of_parse_and_map() in the .to_irq() handler
> > > > to magically translate the GPIO number to a mapped IRQ number.
> > > > 
> > > > The number of interrupts can be pretty high (up to 58 in the worst
> > > > case so far), so an alternative would be to specify the interrupt-
> > > > parent only, and call irq_create_of_mapping() directly. What solution
> > > > would you prefer ?
> > > 
> > > Are the interrupts in a contiguous block in the controller so you can
> > > just pass around the controller and a base number?
> > 
> > In two of the three SoCs I need to fix they are. I've just realized that
> > in the last one the interrupts are in two contiguous blocks in two
> > different parents. I will thus need at least a list of <parent-phandle
> > base count>.
> >
> > Our standard interrupt bindings don't seem to support multiple parents,
>
> You can actually do it by using a dummy node with interrupt-map and
> interrupt-map-mask properties, but it is a pretty ugly solution in my
> opinion.
> 
> > is that something that we want to fix or should I go for custom bindings ?
> 
> Yes, I think it is something that we want to fix. Jean-Christophe was going
> to propose an alternative to the interrupts property which allows an array
> of <phandle interrupt-specifier> tuples, but I've not seen anything yet. Go
> ahead and make a proposal.

More work, great :-)

A bit of bikeshedding here, as the "interrupts" property is already used, how 
should I name the new property ?

> You could try to encode a base+count variant, but honestly I don't think it
> would be a good idea because it only would work with a very narrow set of
> use cases. Consider if #interrupt-cells was set to 2. Which cell gets
> incremented in the range of interrupts specified? Better I think to merely
> have an array of fully specified irqs. Support for that property could be
> transparently baked into the core interrupt parsing functions.

I agree, I'll try that.

-- 
Regards,

Laurent Pinchart



From broonie at kernel.org  Wed Jul 31 07:18:53 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 31 Jul 2013 12:18:53 +0100
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731095411.GA2810@htj.dyndns.org>
References: <1375232669-27846-1-git-send-email-festevam@gmail.com>
 <1375232669-27846-2-git-send-email-festevam@gmail.com>
 <20130731073306.GZ1754@pengutronix.de>
 <20130731082054.GF8540@nchen-desktop>
 <20130731084645.GB1754@pengutronix.de>
 <20130731090512.GD9858@sirena.org.uk>
 <20130731094434.GC1754@pengutronix.de>
 <20130731095411.GA2810@htj.dyndns.org>
Message-ID: <20130731111853.GJ9858@sirena.org.uk>

On Wed, Jul 31, 2013 at 05:54:11AM -0400, Tejun Heo wrote:
> On Wed, Jul 31, 2013 at 11:44:34AM +0200, Uwe Kleine-K?nig wrote:

> > > > OK, so the possible problem is that remove is called while the irq is
> > > > still active. That means you have to assert that all resources the irq

> If your driver destruction path is running while your irq handler is
> still running, it's a crappy / broken driver.  You need a deactivation
> step whether you're using devm or not.  IRQs can be shared and the
> device should be in a quiesced state before the driver detaches
> itself.  Note that you can queue deactivation routine using devm.  For
> an example, please take a look at
> drivers/ata/libata-core.c::ata_host_start().

I'm not sure I understand how this relates the problem.  The main issue
here is that for the shared IRQ case quiescing the device doesn't make
any difference since one of the other users of the interrupt could cause
the interrupt handler to be called regardless of what the hardware is
doing.  This means that we need to guarantee that anything the interrupt
handler relies on has not been deallocated before the interrupt handler
is unregistered.

> irq deregistration.  Add an explicit deactivation step using
> devres_alloc().

> devm guarantees that the destruction callbacks are called in the
> reverse order of registration.

OK, that's helpful.  It'd be good to document this if it's something
the API is intending to guarantee, though - devres.txt doesn't mention
this and it's not something I'd intuitively expect to be the case.
-------------- 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/20130731/e15fad37/attachment.sig>

From tomasz.figa at gmail.com  Wed Jul 31 07:29:26 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 31 Jul 2013 13:29:26 +0200
Subject: How to create IRQ mappings in a GPIO driver that doesn't control
 its IRQ domain ?
In-Reply-To: <2175074.sF1r3oKahE@avalon>
References: <1624911.6TtmtVmU1T@avalon> <12170068.F0utKQgh5l@flatron>
 <2175074.sF1r3oKahE@avalon>
Message-ID: <18585358.29goqe5cyM@thinkpad>

On Wednesday 31 of July 2013 13:11:33 Laurent Pinchart wrote:
> Hi Tomasz,
> 
> On Sunday 28 July 2013 12:07:48 Tomasz Figa wrote:
> > On Wednesday 24 of July 2013 01:21:44 Laurent Pinchart wrote:
> > > Hello,
> > > 
> > > I'm running into an issue on several Renesas SoC with IRQ domains and
> > > GPIOs.
> > > 
> > > On sh73a0, r8a73a4 and r8a7740, GPIOs and external interrupts are
> > > handled by two separate IP cores, namely the PFC (Pin Function
> > > Controller) and INTC (Interrupt Controller). The former is handled by
> > > the sh-pfc driver (drivers/pinctrl/sh-pfc) and the later by the
> > > irq-renesas-intc-irqpin driver (drivers/irqchip), referred to below as
> > > the irqpin driver.
> > 
> > Is the INTC used for anything more than just external interrupts on GPIO
> > lines?
> 
> Yes, it also handles other interrupt sources (NMI and peripherals), but
> those are not implemented now. The peripheral interrupts are also handled
> by the GIC, which is preferred over INTC.

OK, this is much more clear now.

> > > The sh73a0, for instance, has 32 external interrupt lines that are
> > > multiplexed on pins usable as GPIOs. Both the GPIO and external
> > > interrupt functions are usable at the same time, which allows reading
> > > the state of the interrupt lines.
> > > 
> > > These external interrupts are for MMC/SD support, among other devices.
> > > In this specific case the MMC/SD Card Detect signal is wired to one of
> > > the external interrupt signals, and the corresponding GPIO is passed to
> > > the MMC/SD controller driver. Depending on other configuration
> > > parameters the driver can then either poll the Card Detect signal, or
> > > register an interrupt handler to detect changes in the signal state.
> > > This features is implemented by the MMC/SD core, which call
> > > gpio_to_irq() on the GPIO to retrieve the corresponding IRQ number.
> > > 
> > > On non-DT systems the external IRQs are statically mapped at a known
> > > offset. The sh-pfc driver, to implement the gpio_to_irq() function
> > > (through its gpiochip .to_irq() handler), simply searches a
> > > SoC-specific lookup table for the fixed IRQ number associated with a
> > > given GPIO.
> > > 
> > > However, on DT systems, IRQs are mapped dynamically on demand. The
> > > irqpin driver registers a simple IRQ domain, and the
> > > irq_create_mapping() function can then be used to map a given IRQ,
> > > specified as an offset in the domain. This is where the problem
> > > appears, as the irqchip .to_irq() function is implemented in the sh-pfc
> > 
> > I assume it should be s/irqchip/gpiochip/ in the line above, shouldn't it?
> 
> Yes, my bad.

No problem.

> > > driver, which doesn't have access to the IRQ domain registered by the
> > > irqpin driver.
> > > 
> > > I could hack around this by exporting a function in the irqpin driver
> > > that would map an IRQ, and call that function from the sh-pfc driver.
> > > I'd rather avoid that solution as it would add a direct dependency
> > > between the two drivers.
> > 
> > If you could just get the IRQ domain registered by irqpin driver and use
> > it in sh-pfc, then I guess it would solve your problem, as you could
> > simply call irq_create_mapping() with the domain and hwirq as args in your
> > gpiochip .to_irq() callback.
> > 
> > I'm not sure if it's not a hack, but you could add a property to the node
> > of your pin controller that would contain a phandle to your interrupt
> > controller. Then you could use of_parse_phandle() to get to device node of
> > the INTC and then irq_find_host() to retrieve irq domain associated with
> > it.
> 
> That was my initial idea. However, one on of the SoCs, the GPIO interrupts
> are divided in two separate blocks, handled by two different interrupt
> controller instances. I could thus have a list of phandle + range, but that
> becomes pretty hackish. Specifying the interrupts explicitly would be more
> extensible.

Yes, in this case passing the domain alone makes little sense and domain + 
range would be a bit hackish indeed.

> > > Has anyone run into a similar issue ? My gut feeling is that the
> > > architecture isn't right somewhere, but I can't really pinpoint where.
> > > As the external IRQs are handled by an IP core separate from the PFC
> > 
> > Well, the fact that it's separate doesn't mean anything yet. Here my
> > question whether it's used exclusively for GPIO interrupts or not becomes
> > significant. If yes, maybe it could be simply moved to the pinctrl driver?
> 
> Depending on the SoC, I have two different IRQ controllers used for GPIO
> interrupts. They're called INTC and IRQC. INTC has other purposes (although
> not implemented at the moment). The IRQC instances used for GPIO interrupts
> are (at the moment) dedicated to GPIO interrupts, but other instances of the
> same IP core are used for other interrupts, so a separate driver makes
> sense in my opinion.

OK. So you need a bit smarter solution then.

Best regards,
Tomasz



From htejun at gmail.com  Wed Jul 31 07:32:44 2013
From: htejun at gmail.com (Tejun Heo)
Date: Wed, 31 Jul 2013 07:32:44 -0400
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731111853.GJ9858@sirena.org.uk>
References: <1375232669-27846-1-git-send-email-festevam@gmail.com>
 <1375232669-27846-2-git-send-email-festevam@gmail.com>
 <20130731073306.GZ1754@pengutronix.de>
 <20130731082054.GF8540@nchen-desktop>
 <20130731084645.GB1754@pengutronix.de>
 <20130731090512.GD9858@sirena.org.uk>
 <20130731094434.GC1754@pengutronix.de>
 <20130731095411.GA2810@htj.dyndns.org>
 <20130731111853.GJ9858@sirena.org.uk>
Message-ID: <20130731113244.GI2810@htj.dyndns.org>

Hello,

On Wed, Jul 31, 2013 at 12:18:53PM +0100, Mark Brown wrote:
> I'm not sure I understand how this relates the problem.  The main issue
> here is that for the shared IRQ case quiescing the device doesn't make
> any difference since one of the other users of the interrupt could cause
> the interrupt handler to be called regardless of what the hardware is
> doing.  This means that we need to guarantee that anything the interrupt
> handler relies on has not been deallocated before the interrupt handler
> is unregistered.

Yeah, if all resources are allocated using devm - note that you can
hook in non-devm resources using devres_alloc() - all resources which
would be necessary for the interrupt handler would have been allocated
before the irq was allocated, right?  And thus they'll of course
released after the IRQ is freed.  The problem arises when devm and
non-devm releases are mixed as non-devm ones would happen before all
devm ones messing up the release sequencing.

> OK, that's helpful.  It'd be good to document this if it's something
> the API is intending to guarantee, though - devres.txt doesn't mention

Oh, it's definitely guaranteed.  Nothing would work otherwise.

> this and it's not something I'd intuitively expect to be the case.

Oops... I guess I forgot to mention that.  Care to submit a patch?

Thanks.

-- 
tejun


From broonie at kernel.org  Wed Jul 31 07:34:01 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 31 Jul 2013 12:34:01 +0100
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4OzFdZhX0Kzu_6KiimD=KxDr6EM13zUH3GGE=hHaYx=m=Q@mail.gmail.com>
References: <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <20130730205716.GZ9858@sirena.org.uk>
 <CAKON4Ox7-6Jf0ce64Wqr5E49KS+9E135mqc_iG-PWQ7r8bzWHA@mail.gmail.com>
 <20130730230331.GC9858@sirena.org.uk>
 <CAKON4OzFdZhX0Kzu_6KiimD=KxDr6EM13zUH3GGE=hHaYx=m=Q@mail.gmail.com>
Message-ID: <20130731113401.GM9858@sirena.org.uk>

On Tue, Jul 30, 2013 at 07:23:36PM -0400, jonsmirl at gmail.com wrote:

> Uboot could be an issue but I don't think they are actually doing
> anything with FDTs yet, they are just talking about doing it.

Right, plus any other bootloaders that handle the DT in some way.  Those
that just copy the file through without looking at it aren't an issue
but I thought people were doing things like adding in properties for
serial numbers but perhaps that's less widespread than I'd thought and
it's not an issue.
-------------- 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/20130731/85b18fa2/attachment.sig>

From vijay.kilari at gmail.com  Wed Jul 31 07:37:22 2013
From: vijay.kilari at gmail.com (Vijay Kilari)
Date: Wed, 31 Jul 2013 17:07:22 +0530
Subject: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
In-Reply-To: <51F7F0E1.5030200@wwwdotorg.org>
References: <1374817287-27952-1-git-send-email-vijay.kilari@gmail.com>
 <20130726104908.GC17886@mudshark.cambridge.arm.com>
 <51F2ACF7.9000008@wwwdotorg.org>
 <CALicx6ugumPG__rSAsTS95SH=6fTGqhpPFsQ8bLG-u-fbk0=pQ@mail.gmail.com>
 <51F7F0E1.5030200@wwwdotorg.org>
Message-ID: <CALicx6tJFkGbvKO+-XZixj+8RSh1awFnXK91Pdew1+5Oa+dDqg@mail.gmail.com>

On Tue, Jul 30, 2013 at 10:29 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/30/2013 04:37 AM, Vijay Kilari wrote:
>> On Fri, Jul 26, 2013 at 10:38 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> ...
>>> Does a kernel that's used as the crash kernel guarantee:
>>>
>>> * Never to re-use the memory that was used by the previous kernel, so
>>> that the spin loop code/data won't be corrupted, ever, no matter how
>>> long the crash recovery kernel runs.
>>>
>>> * Not use SMP, so there's never a need to re-activate the non-boot CPUs,
>>> which might not work if they aren't truly disabled but rather just
>>> running a pin loop?
>>
>> From cat /proc/iomem, normal kernel is executed from (0x80xxxxxx) with crash
>> kernel reserved 64M at 0xa0000000
>>
>> 80000000-bfffffff : System RAM
>>   80008000-805aeddf : Kernel code
>>   805e2000-8063e427 : Kernel data
>>   a0000000-a3ffffff : Crash kernel
>>
>> crash kernel is loaded to reserved memory location and is executed from there.
>> I could confirm this from /proc/iomem when crash kernel is running
>>
>> a0000000-a3efffff : System RAM
>>   a0008000-a05aeddf : Kernel code
>>   a05e2000-a063e427 : Kernel data
>
> OK, but in the crash dump kernel, is 80008000..8063e427 reserved as
> well, which would guarantee that the spin loop being executed by the
> non-crash CPUs won't be corrupted?

The crash dump kernel runs from reserved memory area (0xa0000000 - 0xa3effffff).
 So it should not corrupt the memory area of original kernel that was running
 at 0x80000000,where other CPU's are in spin loop.


From emilio at elopez.com.ar  Wed Jul 31 07:37:51 2013
From: emilio at elopez.com.ar (=?UTF-8?B?RW1pbGlvIEzDs3Bleg==?=)
Date: Wed, 31 Jul 2013 08:37:51 -0300
Subject: [PATCH 4/4] ARM: sun6i: Enable clock support in the DTSI
In-Reply-To: <2013073116110750016327@gmail.com>
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375195462-19566-5-git-send-email-maxime.ripard@free-electrons.com>
 <51F86A2E.10505@elopez.com.ar>,
 <20130731073724.GA24439@lukather> <2013073116110750016327@gmail.com>
Message-ID: <51F8F70F.70208@elopez.com.ar>

Hi,

El 31/07/13 05:11, kevin.z.m escribi?:
> Hi, Maxime,
>  
>> The problem is a bit more complex than that.
>  
>> On the A31, the losc clock is actually a mux between an external
>> oscillator running at 32kHz, and the internal oscillator running at
>> 667MHz, that would be scaled down.
>  
>> Support for this mux is not quite there yet, since I've not seen any
>> documentation for it, but this would allow to just rearrange losc
>> parents and compatible when we will had such support.
>  
> I think there is some misunderstanding. All allwinner's platforms have
> 2 losc clock source. One is the external 32KHz oscillator, and the other
> is internal 32kHz R/C circuit. The internal 32k R/C circuit can't provide
> a very exact clock on 32KHz. The mux is just for select external osc or
> internal
> 32KHz R/C. If there is no external 32kHz oscillator, we can replace it with
> internal 32kHz R/C for some low speed but not exact clock requirement.

Thanks for the clarification :)

(snip)

>> > + ahb1_mux: ahb1_mux at 01c20054 {
>> > + #clock-cells = <0>;
>> > + compatible = "allwinner,sun6i-ahb1-mux-clk";
>> > + reg = <0x01c20054 0x4>;
>> > + clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
>> > + };
>> > +
>> > + ahb1: ahb1 at 01c20054 {
>> > + #clock-cells = <0>;
>> > + compatible = "allwinner,sun4i-ahb-clk";
>> > + reg = <0x01c20054 0x4>;
>> > + clocks = <&ahb1_mux>;
>> > + };
>> 
>> Depending on when this lands, I believe these two above could be merged
>> into one with the refactoring introduced on my patchset.
>  
> Since your patchset is still in RFC and we had no comments from Mike so
> far, while this one looks pretty similar to the one we had before, I
> guess the safest thing to do would be to rebase your patches on top of
> this ones.

Ok, I'll do that.

Cheers,

Emilio


From finn at uni-bremen.de  Wed Jul 31 07:41:23 2013
From: finn at uni-bremen.de (Finn Hoffmann)
Date: Wed, 31 Jul 2013 13:41:23 +0200
Subject: NSA310 + DT
In-Reply-To: <20130731115108.21c043fd@skate>
References: <20130710073706.GA28212@lunn.ch> <51F6A0DC.3020501@uni-bremen.de>
 <20130729192112.GY29916@titan.lakedaemon.net>
 <20130729204315.GK24782@lunn.ch> <51F78DA6.8010307@uni-bremen.de>
 <20130730144752.GR24782@lunn.ch> <20130730172407.3aab15c6@skate>
 <51F7EBB9.7000504@uni-bremen.de> <20130730191943.49f8070c@skate>
 <20130730183610.GT24782@lunn.ch> <51F814A0.2050403@uni-bremen.de>
 <20130730232316.10dc7019@skate> <20130731111414.47e7670b@skate>
 <51F8DC3A.6010007@uni-bremen.de> <20130731115108.21c043fd@skate>
Message-ID: <51F8F7E3.9090404@uni-bremen.de>


Am 31.07.2013 11:51, schrieb Thomas Petazzoni:
> Dear Finn Hoffmann,
>
> On Wed, 31 Jul 2013 11:43:22 +0200, Finn Hoffmann wrote:
>
>> Hi Thomas,
>> here you are.
>> Network is working.
> Excellent, thanks!
>
>> # cat /sys/kernel/debug/mvebu-mbus/devices
>> [00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap
>> 0000000000010000) [01] disabled
>> [02] disabled
>> [03] disabled
>> [04] 00000000f4000000 - 00000000f4010000 : nand
>> [05] 00000000f5000000 - 00000000f5010000 : sram
>> [06] 00000000e0000000 - 00000000e0100000 : pcie0.0
>> [07] disabled
> Now this looks good, we have both the PCIe memory and PCIe I/O windows
> created.
>
> I'll clean up the patch and send it, hopefully for the final 3.11.
>
> Thanks again for all your testing!
>
> Best regards,
>
> Thomas
Thomas, thank you for your Work.

I have a question about LED's:
Is it possible to have the powerled blinking while kernel is loading? 
Right now all LED's are turned off when the kernel starts.

I came across one curious thing: With Andrews kernel I had:
$ sensors
adt7476-i2c-0-2e
Adapter: mv64xxx_i2c adapter
in0: +1.82 V (min = +0.00 V, max = +3.31 V)
in1: +1.09 V (min = +0.00 V, max = +2.99 V)
in2: +3.27 V (min = +2.98 V, max = +3.63 V)
in3: +5.12 V (min = +4.53 V, max = +5.52 V)
in4: +11.98 V (min = +0.00 V, max = +15.69 V)
fan1: 4330 RPM (min = 0 RPM)
fan2: 0 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
fan4: 0 RPM (min = 0 RPM)
temp1: +32.2??C (low = -127.0??C, high = +127.0??C)
(crit = +100.0??C, hyst = +96.0??C)
temp2: +32.5??C (low = -127.0??C, high = +127.0??C)
(crit = +100.0??C, hyst = +96.0??C)
temp3: +41.0??C (low = -127.0??C, high = +127.0??C)
(crit = +100.0??C, hyst = +96.0??C)
cpu0_vid: +0.000 V

normally I have:
# sensors
lm85-i2c-0-2e
Adapter: mv64xxx_i2c adapter
in0: +1.82 V (min = +0.00 V, max = +3.32 V)
Vcore: +1.07 V (min = +0.00 V, max = +2.99 V)
+3.3V: +3.25 V (min = +2.97 V, max = +3.63 V)
+5V: +5.05 V (min = +4.50 V, max = +5.50 V)
+12V: +12.12 V (min = +0.00 V, max = +15.94 V)
fan1: 2480 RPM (min = 0 RPM)
temp1: +35.0?C (low = -127.0?C, high = +127.0?C)
temp2: +34.0?C (low = -127.0?C, high = +127.0?C)
temp3: +47.0?C (low = -127.0?C, high = +127.0?C)





From thomas.petazzoni at free-electrons.com  Wed Jul 31 07:47:44 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 31 Jul 2013 13:47:44 +0200
Subject: NSA310 + DT
In-Reply-To: <51F8F7E3.9090404@uni-bremen.de>
References: <20130710073706.GA28212@lunn.ch> <51F6A0DC.3020501@uni-bremen.de>
 <20130729192112.GY29916@titan.lakedaemon.net>
 <20130729204315.GK24782@lunn.ch> <51F78DA6.8010307@uni-bremen.de>
 <20130730144752.GR24782@lunn.ch> <20130730172407.3aab15c6@skate>
 <51F7EBB9.7000504@uni-bremen.de> <20130730191943.49f8070c@skate>
 <20130730183610.GT24782@lunn.ch> <51F814A0.2050403@uni-bremen.de>
 <20130730232316.10dc7019@skate> <20130731111414.47e7670b@skate>
 <51F8DC3A.6010007@uni-bremen.de> <20130731115108.21c043fd@skate>
 <51F8F7E3.9090404@uni-bremen.de>
Message-ID: <20130731134744.2d8830f0@skate>

Dear Finn Hoffmann,

On Wed, 31 Jul 2013 13:41:23 +0200, Finn Hoffmann wrote:

> I have a question about LED's:
> Is it possible to have the powerled blinking while kernel is loading? 
> Right now all LED's are turned off when the kernel starts.

Yes, you can set a default trigger for GPIO LEDs. Just edit the
kirkwood-nsa310.dts file and add:

	linux,default-trigger	= "heartbeat";

into the GPIO LED that you want to see blinking once the kernel is
running. Note that it won't be blinking while the kernel is loading
(because loading the kernel is done by the bootloader), but it will
start blinking as soon as the kernel has initialized the GPIO LEDs.

> I came across one curious thing: With Andrews kernel I had:
> $ sensors
> adt7476-i2c-0-2e
> Adapter: mv64xxx_i2c adapter
> in0: +1.82 V (min = +0.00 V, max = +3.31 V)
> in1: +1.09 V (min = +0.00 V, max = +2.99 V)
> in2: +3.27 V (min = +2.98 V, max = +3.63 V)
> in3: +5.12 V (min = +4.53 V, max = +5.52 V)
> in4: +11.98 V (min = +0.00 V, max = +15.69 V)
> fan1: 4330 RPM (min = 0 RPM)
> fan2: 0 RPM (min = 0 RPM)
> fan3: 0 RPM (min = 0 RPM)
> fan4: 0 RPM (min = 0 RPM)
> temp1: +32.2??C (low = -127.0??C, high = +127.0??C)
> (crit = +100.0??C, hyst = +96.0??C)
> temp2: +32.5??C (low = -127.0??C, high = +127.0??C)
> (crit = +100.0??C, hyst = +96.0??C)
> temp3: +41.0??C (low = -127.0??C, high = +127.0??C)
> (crit = +100.0??C, hyst = +96.0??C)
> cpu0_vid: +0.000 V
> 
> normally I have:
> # sensors
> lm85-i2c-0-2e
> Adapter: mv64xxx_i2c adapter
> in0: +1.82 V (min = +0.00 V, max = +3.32 V)
> Vcore: +1.07 V (min = +0.00 V, max = +2.99 V)
> +3.3V: +3.25 V (min = +2.97 V, max = +3.63 V)
> +5V: +5.05 V (min = +4.50 V, max = +5.50 V)
> +12V: +12.12 V (min = +0.00 V, max = +15.94 V)
> fan1: 2480 RPM (min = 0 RPM)
> temp1: +35.0?C (low = -127.0?C, high = +127.0?C)
> temp2: +34.0?C (low = -127.0?C, high = +127.0?C)
> temp3: +47.0?C (low = -127.0?C, high = +127.0?C)

I am not sure to understand which one you believe is correct and which
one is wrong, and how the wrong one is wrong. But I don't have much
sensor experience, maybe Andrew has more knowledge than me on this
stuff.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From maxime.ripard at free-electrons.com  Wed Jul 31 07:49:57 2013
From: maxime.ripard at free-electrons.com (maxime.ripard)
Date: Wed, 31 Jul 2013 13:49:57 +0200
Subject: [PATCH 4/4] ARM: sun6i: Enable clock support in the DTSI
In-Reply-To: <2013073116110750016327@gmail.com>
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375195462-19566-5-git-send-email-maxime.ripard@free-electrons.com>
 <51F86A2E.10505@elopez.com.ar> <20130731073724.GA24439@lukather>
 <2013073116110750016327@gmail.com>
Message-ID: <20130731114957.GD2911@lukather>

Hi Kevin,

On Wed, Jul 31, 2013 at 04:11:11PM +0800, kevin.z.m wrote:
> Hi, Maxime,
> 
> > The problem is a bit more complex than that.
> 
> > On the A31, the losc clock is actually a mux between an external
> > oscillator running at 32kHz, and the internal oscillator running at
> > 667MHz, that would be scaled down.
> 
> > Support for this mux is not quite there yet, since I've not seen any
> > documentation for it, but this would allow to just rearrange losc
> > parents and compatible when we will had such support.
> 
> I think there is some misunderstanding. All allwinner's platforms have 
> 2 losc clock source. One is the external 32KHz oscillator, and the other
> is internal 32kHz R/C circuit. The internal 32k R/C circuit can't provide
> a very exact clock on 32KHz. The mux is just for select external osc or internal
> 32KHz R/C. If there is no external 32kHz oscillator, we can replace it with 
> internal 32kHz R/C for some low speed but not exact clock requirement.

Thanks for the clarification.

How does one select either the internal or the external 32kHz
oscillator? Is this done in software (I can't find any reference to that
in the user manuals) or in hardware?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130731/aacb1f76/attachment.sig>

From broonie at kernel.org  Wed Jul 31 07:50:27 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 31 Jul 2013 12:50:27 +0100
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731113244.GI2810@htj.dyndns.org>
References: <1375232669-27846-1-git-send-email-festevam@gmail.com>
 <1375232669-27846-2-git-send-email-festevam@gmail.com>
 <20130731073306.GZ1754@pengutronix.de>
 <20130731082054.GF8540@nchen-desktop>
 <20130731084645.GB1754@pengutronix.de>
 <20130731090512.GD9858@sirena.org.uk>
 <20130731094434.GC1754@pengutronix.de>
 <20130731095411.GA2810@htj.dyndns.org>
 <20130731111853.GJ9858@sirena.org.uk>
 <20130731113244.GI2810@htj.dyndns.org>
Message-ID: <20130731115027.GN9858@sirena.org.uk>

On Wed, Jul 31, 2013 at 07:32:44AM -0400, Tejun Heo wrote:

> Yeah, if all resources are allocated using devm - note that you can
> hook in non-devm resources using devres_alloc() - all resources which
> would be necessary for the interrupt handler would have been allocated
> before the irq was allocated, right?  And thus they'll of course
> released after the IRQ is freed.  The problem arises when devm and
> non-devm releases are mixed as non-devm ones would happen before all
> devm ones messing up the release sequencing.



> > OK, that's helpful.  It'd be good to document this if it's something
> > the API is intending to guarantee, though - devres.txt doesn't mention

> Oh, it's definitely guaranteed.  Nothing would work otherwise.

Most things would work just fine - most of the uses of devm_ are just
resource allocations that can safely be freed in essentially any order.
It doesn't really matter if you free the driver's private structure
before you free the clock that's pointing to it or whatever since
neither has any real connection to the other.

> > this and it's not something I'd intuitively expect to be the case.

> Oops... I guess I forgot to mention that.  Care to submit a patch?

I'll take a look.
-------------- 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/20130731/c5f64924/attachment.sig>

From htejun at gmail.com  Wed Jul 31 07:55:27 2013
From: htejun at gmail.com (Tejun Heo)
Date: Wed, 31 Jul 2013 07:55:27 -0400
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731115027.GN9858@sirena.org.uk>
References: <1375232669-27846-2-git-send-email-festevam@gmail.com>
 <20130731073306.GZ1754@pengutronix.de>
 <20130731082054.GF8540@nchen-desktop>
 <20130731084645.GB1754@pengutronix.de>
 <20130731090512.GD9858@sirena.org.uk>
 <20130731094434.GC1754@pengutronix.de>
 <20130731095411.GA2810@htj.dyndns.org>
 <20130731111853.GJ9858@sirena.org.uk>
 <20130731113244.GI2810@htj.dyndns.org>
 <20130731115027.GN9858@sirena.org.uk>
Message-ID: <20130731115527.GR2810@htj.dyndns.org>

On Wed, Jul 31, 2013 at 12:50:27PM +0100, Mark Brown wrote:
> Most things would work just fine - most of the uses of devm_ are just
> resource allocations that can safely be freed in essentially any order.
> It doesn't really matter if you free the driver's private structure
> before you free the clock that's pointing to it or whatever since
> neither has any real connection to the other.

If you have DMA / IRQ / command engine deactivations in devm path
which often is the case with full conversions, freeing any resources
including DMA areas and host private data in the wrong order is a
horrible idea.  It's worse as it won't really be noticeable in most
cases.

Thanks.

-- 
tejun


From jonsmirl at gmail.com  Wed Jul 31 08:01:54 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Wed, 31 Jul 2013 08:01:54 -0400
Subject: Defining schemas for Device Tree
In-Reply-To: <20130731113401.GM9858@sirena.org.uk>
References: <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <20130730205716.GZ9858@sirena.org.uk>
 <CAKON4Ox7-6Jf0ce64Wqr5E49KS+9E135mqc_iG-PWQ7r8bzWHA@mail.gmail.com>
 <20130730230331.GC9858@sirena.org.uk>
 <CAKON4OzFdZhX0Kzu_6KiimD=KxDr6EM13zUH3GGE=hHaYx=m=Q@mail.gmail.com>
 <20130731113401.GM9858@sirena.org.uk>
Message-ID: <CAKON4OyQUcqw1RFcWj3uy0i2i+3UBB8fG1rPw6tcrMGDZ40y6g@mail.gmail.com>

On Wed, Jul 31, 2013 at 7:34 AM, Mark Brown <broonie at kernel.org> wrote:
> On Tue, Jul 30, 2013 at 07:23:36PM -0400, jonsmirl at gmail.com wrote:
>
>> Uboot could be an issue but I don't think they are actually doing
>> anything with FDTs yet, they are just talking about doing it.
>
> Right, plus any other bootloaders that handle the DT in some way.  Those
> that just copy the file through without looking at it aren't an issue
> but I thought people were doing things like adding in properties for
> serial numbers but perhaps that's less widespread than I'd thought and
> it's not an issue.

uboot patches up the amount of RAM it finds into the FDT. It might
patch up clock speed too, I don't remember. I haven't seen it add
serial numbers but it might, not sure which serial numbers.

There has been talk for several years about turning uboot into a bunch
of device drivers and using FDT to control it. Allwinner has done that
with the fex implementation. The uboot work is still in the talking
about it phase.

-- 
Jon Smirl
jonsmirl at gmail.com


From kevin.z.m.zh at gmail.com  Wed Jul 31 08:10:32 2013
From: kevin.z.m.zh at gmail.com (kevin.z.m)
Date: Wed, 31 Jul 2013 20:10:32 +0800
Subject: [PATCH 4/4] ARM: sun6i: Enable clock support in the DTSI
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375195462-19566-5-git-send-email-maxime.ripard@free-electrons.com>
 <51F86A2E.10505@elopez.com.ar> <20130731073724.GA24439@lukather>
 <2013073116110750016327@gmail.com>, 
 <20130731114957.GD2911@lukather>
Message-ID: <2013073120102496855035@gmail.com>


Hi, Maxime,

> How does one select either the internal or the external 32kHz
> oscillator? Is this done in software (I can't find any reference to that
> in the user manuals) or in hardware?
For A20, it should be in the Timer module, and there is a register named "LOSC_CTRL_REG".
For A31, it is in the RTC module, same name of "LOSC_CTRL_REG".


Best Regards, 
kevin.z.m


From tomasz.figa at gmail.com  Wed Jul 31 08:21:49 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 31 Jul 2013 14:21:49 +0200
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4OyQUcqw1RFcWj3uy0i2i+3UBB8fG1rPw6tcrMGDZ40y6g@mail.gmail.com>
References: <1706112.Xn49tiCSKF@thinkpad> <20130731113401.GM9858@sirena.org.uk>
 <CAKON4OyQUcqw1RFcWj3uy0i2i+3UBB8fG1rPw6tcrMGDZ40y6g@mail.gmail.com>
Message-ID: <2300415.ZNNddtVGav@thinkpad>

On Wednesday 31 of July 2013 08:01:54 jonsmirl at gmail.com wrote:
> On Wed, Jul 31, 2013 at 7:34 AM, Mark Brown <broonie at kernel.org> wrote:
> > On Tue, Jul 30, 2013 at 07:23:36PM -0400, jonsmirl at gmail.com wrote:
> >> Uboot could be an issue but I don't think they are actually doing
> >> anything with FDTs yet, they are just talking about doing it.
> > 
> > Right, plus any other bootloaders that handle the DT in some way.  Those
> > that just copy the file through without looking at it aren't an issue
> > but I thought people were doing things like adding in properties for
> > serial numbers but perhaps that's less widespread than I'd thought and
> > it's not an issue.
> 
> uboot patches up the amount of RAM it finds into the FDT. It might
> patch up clock speed too, I don't remember. I haven't seen it add
> serial numbers but it might, not sure which serial numbers.
> 
> There has been talk for several years about turning uboot into a bunch
> of device drivers and using FDT to control it. Allwinner has done that
> with the fex implementation. The uboot work is still in the talking
> about it phase.

u-boot still does not have generic driver model or at least did not have when 
I last checked it not so long ago, so it seems like there is still long way to 
go for using FDT as source of information about hardware in u-boot.

barebox [1], aka u-boot-v2, might be closer to this approach (it might be 
already using it, but this needs to be checked) as it already has generic 
driver model and support for DT.

Best regards,
Tomasz

[1] http://barebox.org/



From greg at kroah.com  Wed Jul 31 08:33:51 2013
From: greg at kroah.com (Greg KH)
Date: Wed, 31 Jul 2013 05:33:51 -0700
Subject: [Ksummit-2013-discuss] [ATTEND] [ARM ATTEND] kernel data bloat
 and how to avoid it
In-Reply-To: <20130731073802.GT7656@atomide.com>
References: <20130731073802.GT7656@atomide.com>
Message-ID: <20130731123351.GA30474@kroah.com>

On Wed, Jul 31, 2013 at 12:38:03AM -0700, Tony Lindgren wrote:
> Hi all,
> 
> Probably the biggest kernel data bloat issue is in the ARM land, but
> it also seems that it's becoming a Linux generic issue too, so I
> guess it could be discussed in either context.

Why is it specific to ARM?  What is so unique to ARM that causes it to
"bloat"?

And what exactly do you mean by "bloat"?

> Basically the data bloat issue is there for the arch code and drivers
> and may not show up initially until things have headed the wrong way for
> too long.

What do you mean by this?  You seem to be very vague here.

greg k-h


From m.szyprowski at samsung.com  Wed Jul 31 08:51:55 2013
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 31 Jul 2013 14:51:55 +0200
Subject: [PATCH v4 0/4] Device Tree support for CMA (Contiguous Memory
 Allocator)
Message-ID: <1375275119-12787-1-git-send-email-m.szyprowski@samsung.com>

Hello,

This is a fourth version of my proposal for device tree integration for
reserved memory and Contiguous Memory Allocator. After the comments from
Grant Likely I moved back memory region definitions back to /memory node
(as it was in the first version of this proposal). I've also extended
the code and made it more generic, added support for so called reserved
dma memory (special dma memory regions created by dma_alloc_coherent()
function, for exclusive usage for dma allocation for the given device).

Just a few words for those who see this code for the first time:

The proposed bindings allows to define contiguous memory regions of
specified base address and size. Then, the defined regions can be
assigned to the given device(s) by adding a property with a phanle to
the defined contiguous memory region. From the device tree perspective
that's all. Once the bindings are added, all the memory allocations from
dma-mapping subsystem will be served from the defined contiguous memory
regions.

Contiguous Memory Allocator is a framework, which lets to provide a
large contiguous memory buffers for (usually a multimedia) devices. The
contiguous memory is reserved during early boot and then shared with
kernel, which is allowed to allocate it for movable pages. Then, when
device driver requests a contigouous buffer, the framework migrates
movable pages out of contiguous region and gives it to the driver. When
device driver frees the buffer, it is added to kernel memory pool again.
For more information, please refer to commit c64be2bb1c6eb43c838b2c6d57
("drivers: add Contiguous Memory Allocator") and d484864dd96e1830e76895
(CMA merge commit).

Why we need device tree bindings for CMA at all?

Older ARM kernels used so called board-based initialization. Those board
files contained a definition of all hardware blocks available on the
target system and particular kernel and driver software configuration
selected by the board maintainer.

In the new approach the board files will be removed completely and
Device Tree approach is used to describe all hardware blocks available
on the target system. By definition, the bindings should be software
independent, so at least in theory it should be possible to use those
bindings with other operating systems than Linux kernel.

Reserved memory configuration belongs to the grey area. It might depend
on hardware restriction of the board or modules and low-level
configuration done by bootloader. Putting reserved and contiguous memory
regions to /memory node and having phandles to those regions in the
device nodes however matches well with the device-tree typical style of
linking devices with other resources like clocks, interrupts,
regulators, power domains, etc. This is the main reason to use such
approach instead of putting everything to /chosen node as it has been
proposed in v2 and v3.

Best regards
Marek Szyprowski
Samsung R&D Institute Poland

Changelog:

v4:
- moved back contiguous-memory bindings from /chosen/contiguous-memory
  to /memory nodes as suggested by Grant (see 
  http://article.gmane.org/gmane.linux.drivers.devicetree/41030
  for more details)
- added support for DMA reserved memory with dma_declare_coherent()
- moved code to drivers/of/of_reserved_mem.c
- added generic code to scan specific path in flat device tree

v3: http://thread.gmane.org/gmane.linux.drivers.devicetree/40013/
- fixed issues pointed by Laura and updated documentation

v2: http://thread.gmane.org/gmane.linux.drivers.devicetree/34075
- moved contiguous-memory bindings from /memory to /chosen/contiguous-memory/
  node to avoid spreading Linux specific parameters over the whole device
  tree definitions
- added support for autoconfigured regions (use zero base)
- fixes minor bugs

v1: http://thread.gmane.org/gmane.linux.drivers.devicetree/30111/
- initial proposal

Patch summary:

Marek Szyprowski (4):
  drivers: dma-contiguous: clean source code and prepare for device
    tree
  drivers: of: add function to scan fdt nodes given by path
  drivers: of: add initialization code for dma reserved memory
  ARM: init: add support for reserved memory defined by device tree

 Documentation/devicetree/bindings/memory.txt |  152 ++++++++++++++++++++++
 arch/arm/mm/init.c                           |    3 +
 drivers/base/dma-contiguous.c                |  147 +++++++++++-----------
 drivers/of/Kconfig                           |    6 +
 drivers/of/Makefile                          |    1 +
 drivers/of/fdt.c                             |   76 +++++++++++
 drivers/of/of_reserved_mem.c                 |  175 ++++++++++++++++++++++++++
 include/asm-generic/dma-coherent.h           |    6 +
 include/asm-generic/dma-contiguous.h         |    2 -
 include/linux/dma-contiguous.h               |   49 +++++++-
 include/linux/of_fdt.h                       |    3 +
 11 files changed, 541 insertions(+), 79 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/memory.txt
 create mode 100644 drivers/of/of_reserved_mem.c

-- 
1.7.9.5



From m.szyprowski at samsung.com  Wed Jul 31 08:51:56 2013
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 31 Jul 2013 14:51:56 +0200
Subject: [PATCH v4 1/4] drivers: dma-contiguous: clean source code and prepare
 for device tree
In-Reply-To: <1375275119-12787-1-git-send-email-m.szyprowski@samsung.com>
References: <1375275119-12787-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1375275119-12787-2-git-send-email-m.szyprowski@samsung.com>

This patch cleans the initialization of dma contiguous framework. The
all-in-one dma_declare_contiguous() function is now separated into
dma_contiguous_reserve_area() which only steals the the memory from
memblock allocator and dma_contiguous_add_device() function, which
assigns given device to the specified reserved memory area. This improves
the flexibility in defining contiguous memory areas and assigning device
to them, because now it is possible to assign more than one device to
the given contiguous memory area. Such split in initialization procedure
is also required for upcoming device tree support.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
Acked-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/base/dma-contiguous.c        |  147 +++++++++++++++++-----------------
 include/asm-generic/dma-contiguous.h |    2 -
 include/linux/dma-contiguous.h       |   49 +++++++++++-
 3 files changed, 119 insertions(+), 79 deletions(-)

diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 0ca5442..2cc9c77 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -96,7 +96,7 @@ static inline __maybe_unused phys_addr_t cma_early_percent_memory(void)
 #endif
 
 /**
- * dma_contiguous_reserve() - reserve area for contiguous memory handling
+ * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling
  * @limit: End address of the reserved memory (optional, 0 for any).
  *
  * This function reserves memory from early allocator. It should be
@@ -124,22 +124,29 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
 #endif
 	}
 
-	if (selected_size) {
+	if (selected_size && !dma_contiguous_default_area) {
 		pr_debug("%s: reserving %ld MiB for global area\n", __func__,
 			 (unsigned long)selected_size / SZ_1M);
 
-		dma_declare_contiguous(NULL, selected_size, 0, limit);
+		dma_contiguous_reserve_area(selected_size, 0, limit,
+					    &dma_contiguous_default_area);
 	}
 };
 
 static DEFINE_MUTEX(cma_mutex);
 
-static __init int cma_activate_area(unsigned long base_pfn, unsigned long count)
+static __init int cma_activate_area(struct cma *cma)
 {
-	unsigned long pfn = base_pfn;
-	unsigned i = count >> pageblock_order;
+	int bitmap_size = BITS_TO_LONGS(cma->count) * sizeof(long);
+	unsigned long base_pfn = cma->base_pfn, pfn = base_pfn;
+	unsigned i = cma->count >> pageblock_order;
 	struct zone *zone;
 
+	cma->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+
+	if (!cma->bitmap)
+		return -ENOMEM;
+
 	WARN_ON_ONCE(!pfn_valid(pfn));
 	zone = page_zone(pfn_to_page(pfn));
 
@@ -153,92 +160,53 @@ static __init int cma_activate_area(unsigned long base_pfn, unsigned long count)
 		}
 		init_cma_reserved_pageblock(pfn_to_page(base_pfn));
 	} while (--i);
-	return 0;
-}
-
-static __init struct cma *cma_create_area(unsigned long base_pfn,
-				     unsigned long count)
-{
-	int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
-	struct cma *cma;
-	int ret = -ENOMEM;
-
-	pr_debug("%s(base %08lx, count %lx)\n", __func__, base_pfn, count);
-
-	cma = kmalloc(sizeof *cma, GFP_KERNEL);
-	if (!cma)
-		return ERR_PTR(-ENOMEM);
 
-	cma->base_pfn = base_pfn;
-	cma->count = count;
-	cma->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
-
-	if (!cma->bitmap)
-		goto no_mem;
-
-	ret = cma_activate_area(base_pfn, count);
-	if (ret)
-		goto error;
-
-	pr_debug("%s: returned %p\n", __func__, (void *)cma);
-	return cma;
-
-error:
-	kfree(cma->bitmap);
-no_mem:
-	kfree(cma);
-	return ERR_PTR(ret);
+	return 0;
 }
 
-static struct cma_reserved {
-	phys_addr_t start;
-	unsigned long size;
-	struct device *dev;
-} cma_reserved[MAX_CMA_AREAS] __initdata;
-static unsigned cma_reserved_count __initdata;
+static struct cma cma_areas[MAX_CMA_AREAS];
+static unsigned cma_area_count;
 
 static int __init cma_init_reserved_areas(void)
 {
-	struct cma_reserved *r = cma_reserved;
-	unsigned i = cma_reserved_count;
-
-	pr_debug("%s()\n", __func__);
+	int i;
 
-	for (; i; --i, ++r) {
-		struct cma *cma;
-		cma = cma_create_area(PFN_DOWN(r->start),
-				      r->size >> PAGE_SHIFT);
-		if (!IS_ERR(cma))
-			dev_set_cma_area(r->dev, cma);
+	for (i = 0; i < cma_area_count; i++) {
+		int ret = cma_activate_area(&cma_areas[i]);
+		if (ret)
+			return ret;
 	}
+
 	return 0;
 }
 core_initcall(cma_init_reserved_areas);
 
 /**
- * dma_declare_contiguous() - reserve area for contiguous memory handling
- *			      for particular device
- * @dev:   Pointer to device structure.
- * @size:  Size of the reserved memory.
- * @base:  Start address of the reserved memory (optional, 0 for any).
+ * dma_contiguous_reserve_area() - reserve custom contiguous area
+ * @size: Size of the reserved area (in bytes),
+ * @base: Base address of the reserved area optional, use 0 for any
  * @limit: End address of the reserved memory (optional, 0 for any).
+ * @res_cma: Pointer to store the created cma region.
  *
- * This function reserves memory for specified device. It should be
- * called by board specific code when early allocator (memblock or bootmem)
- * is still activate.
+ * This function reserves memory from early allocator. It should be
+ * called by arch specific code once the early allocator (memblock or bootmem)
+ * has been activated and all other subsystems have already allocated/reserved
+ * memory. This function allows to create custom reserved areas for specific
+ * devices.
  */
-int __init dma_declare_contiguous(struct device *dev, phys_addr_t size,
-				  phys_addr_t base, phys_addr_t limit)
+int __init dma_contiguous_reserve_area(phys_addr_t size, phys_addr_t base,
+				       phys_addr_t limit, struct cma **res_cma)
 {
-	struct cma_reserved *r = &cma_reserved[cma_reserved_count];
+	struct cma *cma = &cma_areas[cma_area_count];
 	phys_addr_t alignment;
+	int ret = 0;
 
 	pr_debug("%s(size %lx, base %08lx, limit %08lx)\n", __func__,
 		 (unsigned long)size, (unsigned long)base,
 		 (unsigned long)limit);
 
 	/* Sanity checks */
-	if (cma_reserved_count == ARRAY_SIZE(cma_reserved)) {
+	if (cma_area_count == ARRAY_SIZE(cma_areas)) {
 		pr_err("Not enough slots for CMA reserved regions!\n");
 		return -ENOSPC;
 	}
@@ -256,7 +224,7 @@ int __init dma_declare_contiguous(struct device *dev, phys_addr_t size,
 	if (base) {
 		if (memblock_is_region_reserved(base, size) ||
 		    memblock_reserve(base, size) < 0) {
-			base = -EBUSY;
+			ret = -EBUSY;
 			goto err;
 		}
 	} else {
@@ -266,7 +234,7 @@ int __init dma_declare_contiguous(struct device *dev, phys_addr_t size,
 		 */
 		phys_addr_t addr = __memblock_alloc_base(size, alignment, limit);
 		if (!addr) {
-			base = -ENOMEM;
+			ret = -ENOMEM;
 			goto err;
 		} else {
 			base = addr;
@@ -277,10 +245,11 @@ int __init dma_declare_contiguous(struct device *dev, phys_addr_t size,
 	 * Each reserved area must be initialised later, when more kernel
 	 * subsystems (like slab allocator) are available.
 	 */
-	r->start = base;
-	r->size = size;
-	r->dev = dev;
-	cma_reserved_count++;
+	cma->base_pfn = PFN_DOWN(base);
+	cma->count = size >> PAGE_SHIFT;
+	*res_cma = cma;
+	cma_area_count++;
+
 	pr_info("CMA: reserved %ld MiB at %08lx\n", (unsigned long)size / SZ_1M,
 		(unsigned long)base);
 
@@ -289,9 +258,37 @@ int __init dma_declare_contiguous(struct device *dev, phys_addr_t size,
 	return 0;
 err:
 	pr_err("CMA: failed to reserve %ld MiB\n", (unsigned long)size / SZ_1M);
-	return base;
+	return ret;
+}
+
+/**
+ * dma_contiguous_add_device() - add device to custom contiguous reserved area
+ * @dev:   Pointer to device structure.
+ * @cma:   Pointer to the cma structure for the reserved area
+ *
+ * This function assigns the given device to the contiguous memory area
+ * reserved earlier by dma_contiguous_reserve_area() function.
+ */
+int __init dma_contiguous_add_device(struct device *dev, struct cma *cma)
+{
+	dev_set_cma_area(dev, cma);
+	return 0;
+}
+
+/**
+ * dma_contiguous_set_default_area() - set global contiguous reserved area
+ * @cma:   Pointer to the cma structure for the reserved area
+ *
+ * This function sets global, device independent contiguous memory area to
+ * the area created earlier by dma_contiguous_reserve_area() function.
+ */
+int __init dma_contiguous_set_default_area(struct cma *cma)
+{
+	dma_contiguous_default_area = cma;
+	return 0;
 }
 
+
 /**
  * dma_alloc_from_contiguous() - allocate pages from contiguous area
  * @dev:   Pointer to device for which the allocation is performed.
diff --git a/include/asm-generic/dma-contiguous.h b/include/asm-generic/dma-contiguous.h
index 294b1e7..8979f86 100644
--- a/include/asm-generic/dma-contiguous.h
+++ b/include/asm-generic/dma-contiguous.h
@@ -18,8 +18,6 @@ static inline void dev_set_cma_area(struct device *dev, struct cma *cma)
 {
 	if (dev)
 		dev->cma_area = cma;
-	if (!dev && !dma_contiguous_default_area)
-		dma_contiguous_default_area = cma;
 }
 
 #endif
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index 01b5c84..9c807c2 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -68,8 +68,37 @@ struct device;
 extern struct cma *dma_contiguous_default_area;
 
 void dma_contiguous_reserve(phys_addr_t addr_limit);
-int dma_declare_contiguous(struct device *dev, phys_addr_t size,
-			   phys_addr_t base, phys_addr_t limit);
+
+int __init dma_contiguous_reserve_area(phys_addr_t size, phys_addr_t base,
+				       phys_addr_t limit, struct cma **res_cma);
+
+int dma_contiguous_add_device(struct device *dev, struct cma *cma);
+int dma_contiguous_set_default_area(struct cma *cma);
+
+/**
+ * dma_declare_contiguous() - reserve area for contiguous memory handling
+ *			      for particular device
+ * @dev:   Pointer to device structure.
+ * @size:  Size of the reserved memory.
+ * @base:  Start address of the reserved memory (optional, 0 for any).
+ * @limit: End address of the reserved memory (optional, 0 for any).
+ *
+ * This function reserves memory for specified device. It should be
+ * called by board specific code when early allocator (memblock or bootmem)
+ * is still activate.
+ */
+
+static inline int dma_declare_contiguous(struct device *dev, phys_addr_t size,
+					 phys_addr_t base, phys_addr_t limit)
+{
+	struct cma *cma;
+	int ret;
+	ret = dma_contiguous_reserve_area(size, base, limit, &cma);
+	if (ret == 0)
+		dma_contiguous_add_device(dev, cma);
+
+	return ret;
+}
 
 struct page *dma_alloc_from_contiguous(struct device *dev, int count,
 				       unsigned int order);
@@ -82,6 +111,22 @@ bool dma_release_from_contiguous(struct device *dev, struct page *pages,
 
 static inline void dma_contiguous_reserve(phys_addr_t limit) { }
 
+static inline int dma_contiguous_reserve_area(phys_addr_t size, phys_addr_t base,
+				       phys_addr_t limit, struct cma **res_cma) {
+	return -ENOSYS;
+}
+
+static inline int dma_contiguous_add_device(struct device *dev, struct cma *cma)
+{
+	return -ENOSYS;
+}
+
+static inline int dma_contiguous_set_default_area(struct cma *cma)
+{
+	return -ENOSYS;
+}
+
+
 static inline
 int dma_declare_contiguous(struct device *dev, phys_addr_t size,
 			   phys_addr_t base, phys_addr_t limit)
-- 
1.7.9.5



From m.szyprowski at samsung.com  Wed Jul 31 08:51:57 2013
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 31 Jul 2013 14:51:57 +0200
Subject: [PATCH v4 2/4] drivers: of: add function to scan fdt nodes given by
 path
In-Reply-To: <1375275119-12787-1-git-send-email-m.szyprowski@samsung.com>
References: <1375275119-12787-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1375275119-12787-3-git-send-email-m.szyprowski@samsung.com>

Add a function to scan the flattened device-tree starting from the
node given by the path. It is used to extract information (like reserved
memory), which is required on ealy boot before we can unflatten the tree.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
Acked-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 drivers/of/fdt.c       |   76 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of_fdt.h |    3 ++
 2 files changed, 79 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 6bb7cf2..8d6e7e8 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -543,6 +543,82 @@ int __init of_flat_dt_match(unsigned long node, const char *const *compat)
 	return of_fdt_match(initial_boot_params, node, compat);
 }
 
+struct fdt_scan_status {
+	const char *name;
+	int namelen;
+	int depth;
+	int found;
+	int (*iterator)(unsigned long node, const char *uname, int depth, void *data);
+	void *data;
+};
+
+/**
+ * fdt_scan_node_by_path - iterator for of_scan_flat_dt_by_path function
+ */
+static int __init fdt_scan_node_by_path(unsigned long node, const char *uname,
+					int depth, void *data)
+{
+	struct fdt_scan_status *st = data;
+
+	/*
+	 * if scan at the requested fdt node has been completed,
+	 * return -ENXIO to abort further scanning
+	 */
+	if (depth <= st->depth)
+		return -ENXIO;
+
+	/* requested fdt node has been found, so call iterator function */
+	if (st->found)
+		return st->iterator(node, uname, depth, st->data);
+
+	/* check if scanning automata is entering next level of fdt nodes */
+	if (depth == st->depth + 1 &&
+	    strncmp(st->name, uname, st->namelen) == 0) {
+		st->depth += 1;
+		if (st->name[st->namelen] == 0) {
+			st->found = 1;
+		} else {
+			const char *next = st->name + st->namelen + 1;
+			const char *p = next;
+			while (*p != '/' && *p != 0)
+				p++;
+			st->name = next;
+			st->namelen = p - next;
+		}
+		return 0;
+	}
+
+	/* scan next fdt node */
+	return 0;
+}
+
+/**
+ * of_scan_flat_dt_by_path - scan flattened tree blob and call callback on each
+ *			     child of the given path.
+ * @path: path to start searching for children
+ * @it: callback function
+ * @data: context data pointer
+ *
+ * This function is used to scan the flattened device-tree starting from the
+ * node given by path. It is used to extract information (like reserved
+ * memory), which is required on ealy boot before we can unflatten the tree.
+ */
+int __init of_scan_flat_dt_by_path(const char *path,
+	int (*it)(unsigned long node, const char *name, int depth, void *data),
+	void *data)
+{
+	struct fdt_scan_status st = {path, 0, -1, 0, it, data};
+	int ret = 0;
+
+	if (initial_boot_params)
+		ret = of_scan_flat_dt(fdt_scan_node_by_path, &st);
+
+	if (st.found && ret == -ENXIO)	/* scan has been completed */
+		return 0;
+	else
+		return -ENOENT;
+}
+
 #ifdef CONFIG_BLK_DEV_INITRD
 /**
  * early_init_dt_check_for_initrd - Decode initrd location from flat tree
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index ed136ad..1151a7f 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -90,6 +90,9 @@ extern void *of_get_flat_dt_prop(unsigned long node, const char *name,
 extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
 extern int of_flat_dt_match(unsigned long node, const char *const *matches);
 extern unsigned long of_get_flat_dt_root(void);
+extern int __init of_scan_flat_dt_by_path(const char *path,
+	int (*it)(unsigned long node, const char *name, int depth, void *data),
+	void *data);
 
 extern int early_init_dt_scan_chosen(unsigned long node, const char *uname,
 				     int depth, void *data);
-- 
1.7.9.5



From m.szyprowski at samsung.com  Wed Jul 31 08:51:58 2013
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 31 Jul 2013 14:51:58 +0200
Subject: [PATCH v4 3/4] drivers: of: add initialization code for dma reserved
 memory
In-Reply-To: <1375275119-12787-1-git-send-email-m.szyprowski@samsung.com>
References: <1375275119-12787-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1375275119-12787-4-git-send-email-m.szyprowski@samsung.com>

Add device tree support for contiguous and reserved memory regions
defined in device tree. Initialization is done in 2 steps. First, the
memory is reserved, what happens very early when only flattened device
tree is available. Then on device initialization the corresponding cma
and reserved regions are assigned to each device structure.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
Acked-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 Documentation/devicetree/bindings/memory.txt |  152 ++++++++++++++++++++++
 drivers/of/Kconfig                           |    6 +
 drivers/of/Makefile                          |    1 +
 drivers/of/of_reserved_mem.c                 |  175 ++++++++++++++++++++++++++
 include/asm-generic/dma-coherent.h           |    6 +
 5 files changed, 340 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory.txt
 create mode 100644 drivers/of/of_reserved_mem.c

diff --git a/Documentation/devicetree/bindings/memory.txt b/Documentation/devicetree/bindings/memory.txt
new file mode 100644
index 0000000..4aece19
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory.txt
@@ -0,0 +1,152 @@
+*** Memory binding ***
+
+The /memory node provides basic information about the address and size
+of the physical memory. This node is usually filled or updated by the
+bootloader, depending on the actual memory configuration of the given
+hardware.
+
+The memory layout is described by the folllowing node:
+
+memory {
+	reg =  <(baseaddr1) (size1)
+		(baseaddr2) (size2)
+		...
+		(baseaddrN) (sizeN)>;
+};
+
+baseaddrX:	the base address of the defined memory bank
+sizeX:		the size of the defined memory bank
+
+More than one memory bank can be defined.
+
+
+*** Reserved memory regions ***
+
+In /memory/reserved-memory node one can create additional nodes
+describing particular reserved (excluded from normal use) memory
+regions. Such memory regions are usually designed for the special usage
+by various device drivers. A good example are contiguous memory
+allocations or memory sharing with other operating system on the same
+hardware board. Those special memory regions might depend on the board
+configuration and devices used on the target system.
+
+Parameters for each memory region can be encoded into the device tree
+wit the following convention:
+
+[(label):] (name)@(address) {
+	compatible = "contiguous-memory-region", "reserved-memory-region";
+	reg = <(address) (size)>;
+	(linux,contiguous-region);
+	(linux,default-contiguous-region);
+};
+
+label:		label given to the defined region (optional)
+name:		an name given to the defined region
+address:	the base address of the defined region
+size:		the size of the memory region
+
+compatible:	"contiguous-memory-region" - enables binding of this
+		region to Contiguous Memory Allocator (special region for
+		contiguous memory allocations, shared with movable system
+		memory, Linux kernel-specific), alternatively if
+		"reserved-memory-region" - compatibility is defined, given
+		region is assigned for exclusive usage for DMA transfers
+
+linux,default-contiguous-region: property indicating that the region
+		is the default region for all contiguous memory
+		allocations, Linux specific (optional)
+
+Each defined region must use unique name. It is optional to specify the
+base address, so if one wants to use autoconfiguration of the base
+address, he must specify the '0' as base address in the 'reg' property
+and assign ann uniqe name to such regions.
+
+
+*** Device node's properties ***
+
+Once the regions in the /memory/reserved-memory node are defined, they
+can be assigned to device nodes to enable drivers for their special use.
+The following properties are defined:
+
+dma-memory-region = <&phandle_to_defined_region>;
+
+This property indicates that the device driver should use the
+memory region pointed by the given phandle.
+
+
+*** Example ***
+
+This example defines a memory consisting of 4 memory banks. 3 contiguous
+regions are defined for Linux kernel, one default of all device drivers
+(named contig_mem, placed at 0x72000000, 64MiB), one dedicated to the
+framebuffer device (labelled display_mem, placed at 0x78000000, 8MiB)
+and one for multimedia processing (labelled multimedia_mem, placed at
+0x77000000, 64MiB). 'display_mem' region is then assigned to fb at 12300000
+device for DMA memory allocations (Linux kernel drivers will use CMA is
+available or dma-exclusive usage otherwise). 'multimedia_mem' is
+assigned to scaller at 12500000 and codec at 12600000 devices for contiguous
+memory allocations when CMA driver is enabled.
+
+The reason for creating a separate region for framebuffer device is to
+match the framebuffer base address to the one configured by bootloader,
+so once Linux kernel drivers starts no glitches on the displayed boot
+logo appears. Scaller and codec drivers should share the memory
+allocations.
+
+/ {
+	/* ... */
+	memory {
+		reg =  <0x40000000 0x10000000
+			0x50000000 0x10000000
+			0x60000000 0x10000000
+			0x70000000 0x10000000>;
+
+		reserved-memory {
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			/*
+			 * global autoconfigured region for contiguous allocations
+			 * (used only with Contiguous Memory Allocator)
+			 */
+			contig_region at 0 {
+				compatible = "contiguous-memory-region";
+				reg = <0x0 0x4000000>;
+				linux,default-contiguous-region;
+			};
+
+			/*
+			 * special region for framebuffer
+			 */
+			display_mem: region at 78000000 {
+				compatible = "contiguous-memory-region", "reserved-memory-region";
+				reg = <0x78000000 0x800000>;
+			};
+
+			/*
+			 * special region for multimedia processing devices
+			 */
+			multimedia_mem: region at 77000000 {
+				compatible = "contiguous-memory-region";
+				reg = <0x77000000 0x4000000>;
+			};
+		};
+	};
+
+	/* ... */
+
+	fb0: fb at 12300000 {
+		status = "okay";
+		dma-memory-region = <&display_mem>;
+	};
+
+	scaller: scaller at 12500000 {
+		status = "okay";
+		dma-memory-region = <&multimedia_mem>;
+	};
+
+	codec: codec at 12600000 {
+		status = "okay";
+		dma-memory-region = <&multimedia_mem>;
+	};
+};
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 80e5c13..a83ab43 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -80,4 +80,10 @@ config OF_MTD
 	depends on MTD
 	def_bool y
 
+config OF_RESERVED_MEM
+	depends on CMA || (HAVE_GENERIC_DMA_COHERENT && HAVE_MEMBLOCK)
+	def_bool y
+	help
+	  Initialization code for DMA reserved memory
+
 endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 1f9c0c4..e7e3322 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_OF_MDIO)	+= of_mdio.o
 obj-$(CONFIG_OF_PCI)	+= of_pci.o
 obj-$(CONFIG_OF_PCI_IRQ)  += of_pci_irq.o
 obj-$(CONFIG_OF_MTD)	+= of_mtd.o
+obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
new file mode 100644
index 0000000..d97fcdf
--- /dev/null
+++ b/drivers/of/of_reserved_mem.c
@@ -0,0 +1,175 @@
+/*
+ * Device tree based initialization code for reserved memory.
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ * Author: Marek Szyprowski <m.szyprowski at samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License or (at your optional) any later version of the license.
+ */
+
+#include <asm/dma-contiguous.h>
+
+#include <linux/memblock.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+#include <linux/of_platform.h>
+#include <linux/mm.h>
+#include <linux/sizes.h>
+#include <linux/mm_types.h>
+#include <linux/dma-contiguous.h>
+#include <linux/dma-mapping.h>
+
+#define MAX_RESERVED_REGIONS	16
+struct reserved_mem {
+	phys_addr_t		base;
+	unsigned long		size;
+	struct cma		*cma;
+	char			name[32];
+};
+static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
+static int reserved_mem_count;
+
+static int __init reserved_mem_fdt_scan(unsigned long node, const char *uname,
+				    int depth, void *data)
+{
+	phys_addr_t base, size;
+	int is_cma, is_reserved;
+	unsigned long len;
+	void *prop;
+
+	is_cma = of_flat_dt_is_compatible(node, "contiguous-memory-region");
+	is_reserved = of_flat_dt_is_compatible(node, "reserved-memory-region");
+
+	if (!is_reserved && !(is_cma && IS_ENABLED(CONFIG_CMA)))
+		return 0;
+
+	prop = of_get_flat_dt_prop(node, "reg", &len);
+	if (!prop || (len != 2 * sizeof(unsigned long))) {
+		pr_err("Reserved mem: node %s, incorrect \"reg\" property\n",
+		       uname);
+		return 0;
+	}
+
+	if (sizeof(unsigned long) == 4) {
+		base = be32_to_cpu(((__be32 *)prop)[0]);
+		size = be32_to_cpu(((__be32 *)prop)[1]);
+	} else {
+		base = be64_to_cpu(((__be64 *)prop)[0]);
+		size = be64_to_cpu(((__be64 *)prop)[1]);
+	}
+
+	pr_info("Reserved mem: found %s, memory base %lx, size %ld MiB\n",
+		uname, (unsigned long)base, (unsigned long)size / SZ_1M);
+
+	if (reserved_mem_count == ARRAY_SIZE(reserved_mem))
+		return -ENOMEM;
+
+	reserved_mem[reserved_mem_count].base = base;
+	reserved_mem[reserved_mem_count].size = size;
+	strcpy(reserved_mem[reserved_mem_count].name, uname);
+
+	if (IS_ENABLED(CONFIG_CMA) && is_cma) {
+		struct cma *cma;
+		if (dma_contiguous_reserve_area(size, base, 0, &cma) == 0) {
+			reserved_mem[reserved_mem_count].cma = cma;
+			reserved_mem_count++;
+
+			if (of_get_flat_dt_prop(node,
+						"linux,default-contiguous-region",
+						NULL))
+				dma_contiguous_set_default_area(cma);
+		}
+	} else if (is_reserved) {
+		if (memblock_remove(base, size) == 0)
+			reserved_mem_count++;
+		else
+			pr_err("Failed to reserve memory for %s\n", uname);
+	}
+
+	return 0;
+}
+
+static struct reserved_mem *get_dma_memory_region(struct device *dev)
+{
+	struct device_node *node;
+	const char *name;
+	int i;
+
+	node = of_parse_phandle(dev->of_node, "dma-memory-region", 0);
+	if (!node)
+		return NULL;
+
+	name = kbasename(node->full_name);
+	for (i = 0; i < reserved_mem_count; i++)
+		if (strcmp(name, reserved_mem[i].name) == 0)
+			return &reserved_mem[i];
+	return NULL;
+}
+
+static void reserved_mem_assign_device_from_dt(struct device *dev)
+{
+	struct reserved_mem *region = get_dma_memory_region(dev);
+	if (!region)
+		return;
+
+	if (region->cma) {
+		dma_contiguous_add_device(dev, region->cma);
+		pr_info("Assigned CMA %s to %s device\n", region->name,
+			dev_name(dev));
+	} else {
+		if (dma_declare_coherent_memory(dev, region->base, region->base,
+		    region->size, DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE) != 0)
+			pr_info("Declared reserved memory %s to %s device\n",
+				region->name, dev_name(dev));
+	}
+}
+
+static void reserved_mem_release_device_from_dt(struct device *dev)
+{
+	struct reserved_mem *region = get_dma_memory_region(dev);
+	if (!region)
+		return;
+	if (!region->cma)
+		dma_release_declared_memory(dev);
+}
+
+static int reserved_mem_device_init_notifier_call(struct notifier_block *nb,
+						unsigned long event, void *data)
+{
+	struct device *dev = data;
+	if (event == BUS_NOTIFY_ADD_DEVICE && dev->of_node)
+		reserved_mem_assign_device_from_dt(dev);
+	else if (event == BUS_NOTIFY_DEL_DEVICE && dev->of_node)
+		reserved_mem_release_device_from_dt(dev);
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block reserved_mem_dev_init_nb = {
+	.notifier_call = reserved_mem_device_init_notifier_call,
+};
+
+static int __init reserved_mem_init_reserved_areas(void)
+{
+	bus_register_notifier(&platform_bus_type, &reserved_mem_dev_init_nb);
+	return 0;
+}
+core_initcall(reserved_mem_init_reserved_areas);
+
+/**
+ * dma_reserved_mem_reserve() - grab memory reserved for device exclusive use
+ *
+ * This function grabs memory from early allocator for device exclusive use
+ * defined in device tree structures. It should be called by arch specific code
+ * once the early allocator (memblock) has been activated and all other
+ * subsystems have already allocated/reserved memory.
+ */
+void __init dma_reserved_mem_of_reserve(void)
+{
+	of_scan_flat_dt_by_path("/memory/reserved-memory",
+				reserved_mem_fdt_scan, NULL);
+}
diff --git a/include/asm-generic/dma-coherent.h b/include/asm-generic/dma-coherent.h
index 2be8a2d..06111d00 100644
--- a/include/asm-generic/dma-coherent.h
+++ b/include/asm-generic/dma-coherent.h
@@ -32,4 +32,10 @@ dma_mark_declared_memory_occupied(struct device *dev,
 #define dma_mmap_from_coherent(dev, vma, vaddr, order, ret) (0)
 #endif
 
+#ifdef CONFIG_OF_RESERVED_MEM
+void __init dma_reserved_mem_of_reserve(void);
+#else
+#define dma_reserved_mem_of_reserve()
+#endif
+
 #endif
-- 
1.7.9.5



From m.szyprowski at samsung.com  Wed Jul 31 08:51:59 2013
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 31 Jul 2013 14:51:59 +0200
Subject: [PATCH v4 4/4] ARM: init: add support for reserved memory defined by
 device tree
In-Reply-To: <1375275119-12787-1-git-send-email-m.szyprowski@samsung.com>
References: <1375275119-12787-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1375275119-12787-5-git-send-email-m.szyprowski@samsung.com>

Enable reserved memory initialization from device tree.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
Acked-by: Kyungmin Park <kyungmin.park at samsung.com>
---
 arch/arm/mm/init.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 15225d8..82db8d8 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -20,6 +20,7 @@
 #include <linux/highmem.h>
 #include <linux/gfp.h>
 #include <linux/memblock.h>
+#include <linux/dma-mapping.h>
 #include <linux/dma-contiguous.h>
 #include <linux/sizes.h>
 
@@ -377,6 +378,8 @@ void __init arm_memblock_init(struct meminfo *mi, struct machine_desc *mdesc)
 	if (mdesc->reserve)
 		mdesc->reserve();
 
+	dma_reserved_mem_of_reserve();
+
 	/*
 	 * reserve memory for DMA contigouos allocations,
 	 * must come from DMA area inside low memory
-- 
1.7.9.5



From Ian.Campbell at citrix.com  Wed Jul 31 08:58:11 2013
From: Ian.Campbell at citrix.com (Ian Campbell)
Date: Wed, 31 Jul 2013 13:58:11 +0100
Subject: DT bindings as ABI [was: Do we have people interested in device
 tree janitoring / cleanup?]
In-Reply-To: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
References: <CAOesGMhJ+je8FZqeFxhAcYwU0CHYer+aGP6DA_8x3azrzfA2sw@mail.gmail.com>
 <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
Message-ID: <1375275491.7382.39.camel@kazak.uk.xensource.com>

On Thu, 2013-07-25 at 18:57 +0100, Mark Rutland wrote:
> > A possible way to handle this is to have exactly that: A group of
> > people that essentially constitute the "standards committee" that meet
> > on a regular basis to review and approve new bindings. They should be
> > people not just doing ARM Linux work, but other stakeholders in these
> > bindings too. One of the things they should probably do is sift
> > through our current in-kernel bindings and select those who seem ready
> > to be locked in, review/discuss/decide upon that and once the decision
> > is made, that specific binding does become part of the static,
> > never-ever-change ABI of firmware-to-kernel interfaces.   That might
> > also be the time that the binding is moved from the kernel to a
> > separate repo, but that's a technicality that we'll let the DT
> > maintainers decide among themselves, IMHO.
> 
> We're going to need input from other OSs too, or the bindings will
> remain Linux-specific regardless of how far away the bindings and dts
> repo(s) is/are.

FWIW my primary interest in stable DT ABIs is because Xen would like to
consume the same device trees on boot, as well as be able to do other
clever things with DT at runtime. Specifically:
      * Take the host device tree passed to Xen at boot, filter out the
        stuff which Xen uses for itself (which is for the most part core
        architectural stuff) and pass the remainder to the dom0 Linux
        kernel (or perhaps in the future another kernel) to drive the
        remainder of the hardware (mostly the SoC specific stuff, but
        some architectural and some Xen defined stuff too)
      * Generate a suitable DT for a guest domain on the fly depending
        on the guest configuration.

Obviously both of those need a stable ABI for us to understand,
manipulate and generate.

Ian.



From mark.rutland at arm.com  Wed Jul 31 09:05:01 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 31 Jul 2013 14:05:01 +0100
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <alpine.DEB.2.02.1307301528540.4893@kaball.uk.xensource.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
 <51F7B4C9.2060500@gmail.com>
 <20130730125650.GD28716@e106331-lin.cambridge.arm.com>
 <20130730134427.GE28716@e106331-lin.cambridge.arm.com>
 <alpine.DEB.2.02.1307301528540.4893@kaball.uk.xensource.com>
Message-ID: <20130731130500.GL29859@e106331-lin.cambridge.arm.com>

On Tue, Jul 30, 2013 at 03:33:34PM +0100, Stefano Stabellini wrote:
> On Tue, 30 Jul 2013, Mark Rutland wrote:
> > On Tue, Jul 30, 2013 at 01:56:50PM +0100, Mark Rutland wrote:
> > > On Tue, Jul 30, 2013 at 01:42:49PM +0100, Rob Herring wrote:
> > > > On 07/30/2013 04:49 AM, Mark Rutland wrote:
> > > > > On Mon, Jul 29, 2013 at 09:18:43PM +0100, Rob Herring wrote:
> > > > >> On 07/29/2013 05:13 AM, Mark Rutland wrote:
> > > > >>> Hi Rob,
> > > > >>>
> > > > >>> On Sun, Jul 28, 2013 at 10:56:32PM +0100, Rob Herring wrote:
> > > > >>>> From: Rob Herring <rob.herring at calxeda.com>
> > > > 
> > > > [snip]
> > > > 
> > > > >>> One of the things changed in PSCI 0.2 was the SMC calling convention,
> > > > >>> though this isn't clear in the PSCI document. The function IDs for 32bit
> > > > >>> and 64bit callers may differ, and we need to support describing an
> > > > >>> arbitrary configuration of the two (same ID for both, different across
> > > > >>> 32-bit/64-bit, only supported for 64-bit, only supported for 32-bit).
> > > > >>>
> > > > >>> I'd like to ensure the binding can deal with that from the start. We
> > > > >>> could do this by having -32 and -64 variants of each function id (e.g.
> > > > >>> cpu_off-64) , if the IDs actually differ, and use the regular combined
> > > > >>> ID if they don't.
> > > > >>
> > > > >> Uggg. I guess I should have read the SMC calling convention doc... I was
> > > > >> simply documenting what is already in the PSCI doc, but obviously that
> > > > >> is not fully flushed out.
> > > > >>
> > > > >> How about something like this (for the complicated case of both 32 and
> > > > >> 64 bit):
> > > > >>
> > > > >> 	method		= "smc", "smc64";
> > > > >> 	psci_version	= <0x84000000 0xc4000000>;
> > > > >> 	cpu_suspend	= <0x84000001 0xc4000001>;
> > > > >> 	cpu_off		= <0x84000002 0xc4000002>;
> > > > >> 	cpu_on		= <0x84000003 0xc4000003>;
> > > > >>
> > > > >> "smc" is a synonym for smc32 for compatibility. The number and order of
> > > > >> methods determines the number and order of function IDs.
> > > > > 
> > > > > While this may be compatible with the arm implementation, it won't be
> > > > > compatible with the arm64 implementation, which assumes smc64 by
> > > > > default.
> > > > > 
> > > > > As far as I am aware, the implementations currently in use (KVM and Xen)
> > > > > use the same ID for both, so I think "smc" should cover an ID valid for
> > > > > a native register width calling convention, and "smc64" and "smc32"
> > > > > describing values only valid for 64-bit wide and 32-bit wide calling
> > > > > conventions respectively.
> > > > 
> > > > The problem is that does not work for a 32-bit kernel on 64-bit h/w as
> > > > native from the dts perspective is smc64. Just like the cpu bindings,
> > > > the binding cannot change based on 32 or 64 bit OS. I don't think we
> > > > really have to deal with that here. We can simply say "smc" is only for
> > > > "arm,psci" and deprecated for "arm,psci-0.2".
> > > 
> > > Agreed. I'd be happy with only having "smc32" and "smc64" for
> > > "arm,psci-0.2".
> 
> I would be happy with that too (Xen only uses HVC as "method").
> 
> 
> > Actually, from some quick discussion with Marc and Dave, I think we can
> > handle this better, in a way that leaves this backwards compatible.
> > 
> > Rather than relying on the method string to tell us the calling
> > convention, I think we should rely on the function ID, as I proposed
> > earlier. The existing function ids provided in the "arm,psci" binding
> > are implicitly relying on the PSCI implementation to detect the register
> > width and act accordingly. This is trivially true on 32bit hardware, KVM
> > (where the same ID is used for 32-bit and 64-bit guests), and while I'm
> > not entirely sure about Xen I believe it's true there. We can make this
> > explicit as we extend the binding.
> > 
> > Having a -64 and -32 variant of each ID (while not pretty) allows us to
> > add additional IDs for functions that might only have a 32-bit or 64-bit
> > interface implemented, in addition to functions with common IDs:
> > 
> > psci {
> > 	compatible = "$VENDOR,psci-0.2", "arm,psci-0.2", "arm,psci";
> > 	cpu_off = <12345678>;
> > 	cpu_on = <01234567>;
> > 	system_reset-32 = <02222222>;
> > 	system_reset-64 = <12222222>;
> > 	affinity_info-64 = <15555555>;
> > };
> > 
> > This means that hypervisors could update their PSCI implementation while
> > keeping their DTS compatible with existing kernels.
> 
> Are you proposing of getting rid of "method" completely and therefore
> have 4 possible function IDs for each function:
> 
> system_reset-32-HVC
> system_reset-64-SMC
> system_reset-32-HVC
> system_reset-64-SMC
> 
> or are you proposing of choosing just the register width via function
> IDs?

Just the register width via the function ID's property name.

> 
> Honestly I think it would be cleaner to introduce a new field called
> "width" can that be 32 or 64 and represent the register width, rather
> than having an explosion of function IDs.
> 

Possibly. I'm worried people may create a mixture of shared, 64-bit
only, and 32-bit only IDs.

Thanks,
Mark.


From mark.rutland at arm.com  Wed Jul 31 09:07:16 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 31 Jul 2013 14:07:16 +0100
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <1375195354.32691.55.camel@kazak.uk.xensource.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
 <51F7B4C9.2060500@gmail.com>
 <20130730125650.GD28716@e106331-lin.cambridge.arm.com>
 <20130730134427.GE28716@e106331-lin.cambridge.arm.com>
 <alpine.DEB.2.02.1307301528540.4893@kaball.uk.xensource.com>
 <1375195354.32691.55.camel@kazak.uk.xensource.com>
Message-ID: <20130731130716.GM29859@e106331-lin.cambridge.arm.com>

On Tue, Jul 30, 2013 at 03:42:34PM +0100, Ian Campbell wrote:
> On Tue, 2013-07-30 at 15:33 +0100, Stefano Stabellini wrote:
> > On Tue, 30 Jul 2013, Mark Rutland wrote:
> > > On Tue, Jul 30, 2013 at 01:56:50PM +0100, Mark Rutland wrote:
> > > > On Tue, Jul 30, 2013 at 01:42:49PM +0100, Rob Herring wrote:
> > > > > On 07/30/2013 04:49 AM, Mark Rutland wrote:
> > > > > > On Mon, Jul 29, 2013 at 09:18:43PM +0100, Rob Herring wrote:
> > > > > >> On 07/29/2013 05:13 AM, Mark Rutland wrote:
> > > > > >>> Hi Rob,
> > > > > >>>
> > > > > >>> On Sun, Jul 28, 2013 at 10:56:32PM +0100, Rob Herring wrote:
> > > > > >>>> From: Rob Herring <rob.herring at calxeda.com>
> > > > > 
> > > > > [snip]
> > > > > 
> > > > > >>> One of the things changed in PSCI 0.2 was the SMC calling convention,
> > > > > >>> though this isn't clear in the PSCI document. The function IDs for 32bit
> > > > > >>> and 64bit callers may differ, and we need to support describing an
> > > > > >>> arbitrary configuration of the two (same ID for both, different across
> > > > > >>> 32-bit/64-bit, only supported for 64-bit, only supported for 32-bit).
> > > > > >>>
> > > > > >>> I'd like to ensure the binding can deal with that from the start. We
> > > > > >>> could do this by having -32 and -64 variants of each function id (e.g.
> > > > > >>> cpu_off-64) , if the IDs actually differ, and use the regular combined
> > > > > >>> ID if they don't.
> > > > > >>
> > > > > >> Uggg. I guess I should have read the SMC calling convention doc... I was
> > > > > >> simply documenting what is already in the PSCI doc, but obviously that
> > > > > >> is not fully flushed out.
> > > > > >>
> > > > > >> How about something like this (for the complicated case of both 32 and
> > > > > >> 64 bit):
> > > > > >>
> > > > > >> 	method		= "smc", "smc64";
> > > > > >> 	psci_version	= <0x84000000 0xc4000000>;
> > > > > >> 	cpu_suspend	= <0x84000001 0xc4000001>;
> > > > > >> 	cpu_off		= <0x84000002 0xc4000002>;
> > > > > >> 	cpu_on		= <0x84000003 0xc4000003>;
> > > > > >>
> > > > > >> "smc" is a synonym for smc32 for compatibility. The number and order of
> > > > > >> methods determines the number and order of function IDs.
> > > > > > 
> > > > > > While this may be compatible with the arm implementation, it won't be
> > > > > > compatible with the arm64 implementation, which assumes smc64 by
> > > > > > default.
> > > > > > 
> > > > > > As far as I am aware, the implementations currently in use (KVM and Xen)
> > > > > > use the same ID for both, so I think "smc" should cover an ID valid for
> > > > > > a native register width calling convention, and "smc64" and "smc32"
> > > > > > describing values only valid for 64-bit wide and 32-bit wide calling
> > > > > > conventions respectively.
> > > > > 
> > > > > The problem is that does not work for a 32-bit kernel on 64-bit h/w as
> > > > > native from the dts perspective is smc64. Just like the cpu bindings,
> > > > > the binding cannot change based on 32 or 64 bit OS. I don't think we
> > > > > really have to deal with that here. We can simply say "smc" is only for
> > > > > "arm,psci" and deprecated for "arm,psci-0.2".
> > > > 
> > > > Agreed. I'd be happy with only having "smc32" and "smc64" for
> > > > "arm,psci-0.2".
> > 
> > I would be happy with that too (Xen only uses HVC as "method").
> 
> Presumably we have the same issues with hvc vs hvc32 vs hvc64 though?

Yes. I'd not considered this with my original reply, but we have the
exact same issue for hvc.

> 
> And does smcX imply hvcX or does that also need to be documented here?

The two are mutually exclusive, neither implies the other (KVM will barf
if you use an SMC iirc).

Thanks,
Mark.


From balajitk at ti.com  Wed Jul 31 09:08:42 2013
From: balajitk at ti.com (Balaji T K)
Date: Wed, 31 Jul 2013 18:38:42 +0530
Subject: [PATCH v2 1/4] ARM: dts: omap4-panda: add MMC5 (WiLink WLAN)
 configuration
In-Reply-To: <1375218923-29876-2-git-send-email-coelho@ti.com>
References: <1375218923-29876-1-git-send-email-coelho@ti.com>
 <1375218923-29876-2-git-send-email-coelho@ti.com>
Message-ID: <51F90C5A.2000807@ti.com>

On Wednesday 31 July 2013 02:45 AM, Luciano Coelho wrote:
> Add regulator, pin muxing and MMC5 configuration to be used by the
> on-board WiLink6 module.
>
> Signed-off-by: Luciano Coelho <coelho at ti.com>
> ---
>   arch/arm/boot/dts/omap4-panda-common.dtsi | 31 ++++++++++++++++++++++++++++++-
>   1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index faa95b5..b3f6e1f 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -107,6 +107,16 @@
>   	 */
>   		clock-frequency = <19200000>;
>   	};
> +
> +	wilink_wl_en: fixedregulator at 1 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "wilink_wl_en";
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		gpio = <&gpio2 11 0>; /* gpio line 43 */
> +		startup-delay-us = <70000>;
> +		enable-active-high;
> +	};
>   };
>
>   &omap4_pmx_wkup {
> @@ -132,6 +142,7 @@
>   			&dss_hdmi_pins
>   			&tpd12s015_pins
>   			&hsusbb1_pins
> +			&wilink_pins
>   	>;
>
>   	twl6030_pins: pinmux_twl6030_pins {
> @@ -235,6 +246,19 @@
>   			0x1c (PIN_OUTPUT | MUX_MODE3)	/* gpio_wk8 */
>   		>;
>   	};
> +
> +	wilink_pins: pinmux_wilink_pins {
> +		pinctrl-single,pins = <
> +			0x7a 0x103      /* gpio_53  INPUT | MODE3 */
> +			0x66 0x3	/* gpio_43  OUTPUT | MODE3 */
> +			0x148 0x118     /* clk	    INPUT PULLUP | MODE0 */
> +			0x14a 0x118     /* cmd	    INPUT PULLUP | MODE0 */
> +			0x14c 0x118     /* dat0	    INPUT PULLUP | MODE0 */
> +			0x14e 0x118     /* dat1	    INPUT PULLUP | MODE0 */
> +			0x150 0x118     /* dat2	    INPUT PULLUP | MODE0 */
> +			0x152 0x118     /* dat3	    INPUT PULLUP | MODE0 */
Hi,

Since the base for omap4_pmx_core is 0x4a100040, you need to offset 0x40 from
pad address :-)
and can you please use INPUT_EN / PIN_INPUT_PULLUP / MUX_MODEx macros
(from dt-bindings/pinctrl/omap.h)




From broonie at kernel.org  Wed Jul 31 09:27:08 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 31 Jul 2013 14:27:08 +0100
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731115527.GR2810@htj.dyndns.org>
References: <20130731073306.GZ1754@pengutronix.de>
 <20130731082054.GF8540@nchen-desktop>
 <20130731084645.GB1754@pengutronix.de>
 <20130731090512.GD9858@sirena.org.uk>
 <20130731094434.GC1754@pengutronix.de>
 <20130731095411.GA2810@htj.dyndns.org>
 <20130731111853.GJ9858@sirena.org.uk>
 <20130731113244.GI2810@htj.dyndns.org>
 <20130731115027.GN9858@sirena.org.uk>
 <20130731115527.GR2810@htj.dyndns.org>
Message-ID: <20130731132708.GQ9858@sirena.org.uk>

On Wed, Jul 31, 2013 at 07:55:27AM -0400, Tejun Heo wrote:

> If you have DMA / IRQ / command engine deactivations in devm path
> which often is the case with full conversions, freeing any resources
> including DMA areas and host private data in the wrong order is a
> horrible idea.  It's worse as it won't really be noticeable in most
> cases.

It's really only interrupts that affect most devices - if there's DMA or
anything going on after the remove() then as you said earlier the driver
is probably doing something wrong.
-------------- 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/20130731/cd025781/attachment.sig>

From htejun at gmail.com  Wed Jul 31 09:42:15 2013
From: htejun at gmail.com (Tejun Heo)
Date: Wed, 31 Jul 2013 09:42:15 -0400
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731132708.GQ9858@sirena.org.uk>
References: <20130731082054.GF8540@nchen-desktop>
 <20130731084645.GB1754@pengutronix.de>
 <20130731090512.GD9858@sirena.org.uk>
 <20130731094434.GC1754@pengutronix.de>
 <20130731095411.GA2810@htj.dyndns.org>
 <20130731111853.GJ9858@sirena.org.uk>
 <20130731113244.GI2810@htj.dyndns.org>
 <20130731115027.GN9858@sirena.org.uk>
 <20130731115527.GR2810@htj.dyndns.org>
 <20130731132708.GQ9858@sirena.org.uk>
Message-ID: <20130731134215.GS2810@htj.dyndns.org>

Hello,

On Wed, Jul 31, 2013 at 02:27:08PM +0100, Mark Brown wrote:
> It's really only interrupts that affect most devices - if there's DMA or
> anything going on after the remove() then as you said earlier the driver
> is probably doing something wrong.

Hmmm... it depends on the specific driver is converted but if the
deactivation sequence - shutting down of command engine - is also
handled by devm as in libata and if you have non-devres resource free
in the exit path, you have the same problem.  Again, in general,
tearing things down in the order which isn't the reverse of allocation
is a bad idea.  Adhering to the order isn't that hard and will result
in far less craziness in the long term.

Thanks.

-- 
tejun


From mark.rutland at arm.com  Wed Jul 31 09:49:17 2013
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 31 Jul 2013 14:49:17 +0100
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <CAHCPf3vUA1bD+1xPch-KZX6fdDzxsWjnVpUD39AKC=ds+EKeHQ@mail.gmail.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
 <51F7B4C9.2060500@gmail.com>
 <20130730125650.GD28716@e106331-lin.cambridge.arm.com>
 <20130730134427.GE28716@e106331-lin.cambridge.arm.com>
 <alpine.DEB.2.02.1307301528540.4893@kaball.uk.xensource.com>
 <1375195354.32691.55.camel@kazak.uk.xensource.com>
 <CAHCPf3vUA1bD+1xPch-KZX6fdDzxsWjnVpUD39AKC=ds+EKeHQ@mail.gmail.com>
Message-ID: <20130731134917.GN29859@e106331-lin.cambridge.arm.com>

On Tue, Jul 30, 2013 at 06:48:59PM +0100, Matt Sealey wrote:
> Isn't this being overthought?
> 
> "method" (I would have re-used model, but that's by-the-by) should
> just determine which call interface to use. Only one should end up in
> a device tree - it doesn't make a lot of sense to specify more than
> one, to me, given my read of the specs and the SMC calling convention.
> 
> For AArch64 chips they should implement 64-bit SMC interface or 32-bit
> SMC interface. Either way you get there, the function number is
> encoded with the type of call anyway so AArch64 secure monitors or
> hypervisors will know which one was intended, given the SMC calling
> convention defines this "64-bit" bit pretty clearly. The "method" is
> an instruction to the "guest OS" in how to fill it's registers more
> than it is in function names.

Implementations may not follow the recommended ID allocations, and thus
we cannot rely on the function ID to provide us with any useful
information. We certainly cannot rely on it for hvcs, where for an
existing implementation (KVM) uses the same IDs for 32-bit and 64-bit
guests.

If we force the use of said bit, then new kernels cannot necessarily
work on existing PSCI implementations (which may not handle the use of
said bit as you expect). If we make the binding for psci-0.2 explicitly
require the use of this bit, then future firmware/virtualisation code
cannot provide new functionality withoot breaking backwards compatiblity
with existing kernels, as an "arm,psci-0.2" node would be incompatible
with an "arm,psci" node (which is all an existing kernel can handle).

> 
> * An AArch64 guest under an AArch32 hypervisor/sm seems pretty weird
> and in any case, the device tree would use the 32-bit convention (any
> SMC64 call in 32-bit state should return "Unknown SMC Function
> Identifier" if that bit is set)

This is not allowed by the architecture.

> * An AArch32 guest under an AArch32  hypervisor/sm would use the
> 32-bit convention
> * An AArch32 guest under an AArch64 hypervisor/sm would use the 32-bit
> convention

Both of these cases are trivially mandated by the architecture.

> * An AArch64 guest under an AArch64 hypervisor/sm would use the 64-bit
> convention or the 32-bit convention depending on how the sm is
> written, but it doesn't matter which is used if both can be
> supported.. but you'd only want to use one of them.

Not all implementation will implement both, so there needs to be a way
to describe that. Which is actually used is up to the OS.

> 
> TLDR; Supply your (EL1) guests with the preferred method, not a list
> of all possible methods, as above. If you're the vendor and you
> defined any part of EL3 or EL2 you're in complete control of which
> method you want subordinate levels to use by way of implementation,
> right?

As far as I can tell, no-one was arguing against this strategy. However,
for those cases where functionality is implemented for only one
register-width, or requires a different ID per register-width, this
needs to be described somehow.

Thanks,
Mark.


From jason at lakedaemon.net  Wed Jul 31 09:53:46 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 31 Jul 2013 09:53:46 -0400
Subject: [Ksummit-2013-discuss] [ATTEND] [ARM ATTEND] kernel data bloat
 and how to avoid it
In-Reply-To: <20130731123351.GA30474@kroah.com>
References: <20130731073802.GT7656@atomide.com>
 <20130731123351.GA30474@kroah.com>
Message-ID: <20130731135346.GN5882@titan.lakedaemon.net>

On Wed, Jul 31, 2013 at 05:33:51AM -0700, Greg KH wrote:
> On Wed, Jul 31, 2013 at 12:38:03AM -0700, Tony Lindgren wrote:
> > Hi all,
> > 
> > Probably the biggest kernel data bloat issue is in the ARM land, but
> > it also seems that it's becoming a Linux generic issue too, so I
> > guess it could be discussed in either context.
> 
> Why is it specific to ARM?  What is so unique to ARM that causes it to
> "bloat"?
> 
> And what exactly do you mean by "bloat"?

Perhaps he's referring to the multiplatform effort?  You'd get a lot of
board code that wouldn't be used at each boot.  This should be declining
though...

thx,

Jason.


From hzpeterchen at gmail.com  Wed Jul 31 09:55:26 2013
From: hzpeterchen at gmail.com (Peter Chen)
Date: Wed, 31 Jul 2013 21:55:26 +0800
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731132708.GQ9858@sirena.org.uk>
References: <20130731073306.GZ1754@pengutronix.de>
 <20130731082054.GF8540@nchen-desktop>
 <20130731084645.GB1754@pengutronix.de> <20130731090512.GD9858@sirena.org.uk>
 <20130731094434.GC1754@pengutronix.de> <20130731095411.GA2810@htj.dyndns.org>
 <20130731111853.GJ9858@sirena.org.uk> <20130731113244.GI2810@htj.dyndns.org>
 <20130731115027.GN9858@sirena.org.uk> <20130731115527.GR2810@htj.dyndns.org>
 <20130731132708.GQ9858@sirena.org.uk>
Message-ID: <CAL411-qQm9vgDHswEM6PEvFKAaqd=e3qm-zViUbNztv0tJYa8Q@mail.gmail.com>

On Wed, Jul 31, 2013 at 9:27 PM, Mark Brown <broonie at kernel.org> wrote:
> On Wed, Jul 31, 2013 at 07:55:27AM -0400, Tejun Heo wrote:
>
>> If you have DMA / IRQ / command engine deactivations in devm path
>> which often is the case with full conversions, freeing any resources
>> including DMA areas and host private data in the wrong order is a
>> horrible idea.  It's worse as it won't really be noticeable in most
>> cases.
>
> It's really only interrupts that affect most devices - if there's DMA or
> anything going on after the remove() then as you said earlier the driver
> is probably doing something wrong.

I think the main point is we should allocate managed resource which is used
at interrupt handler before devm_request_irq, and all resources used
at interrupt
handler should be managed.

If we use non-managed resource at interrupt handler, but using managed interrupt
handler, things still will go wrong if there is an odd (unexpected)
interrupt after
we finish deactivation at removal.

-- 
BR,
Peter Chen


From jason at lakedaemon.net  Wed Jul 31 09:55:52 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 31 Jul 2013 09:55:52 -0400
Subject: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit
 mitigations
In-Reply-To: <51F83E2B.7040808@zytor.com>
References: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
 <20130730221435.GA22240@redhat.com> <51F83E2B.7040808@zytor.com>
Message-ID: <20130731135552.GO5882@titan.lakedaemon.net>

On Tue, Jul 30, 2013 at 03:28:59PM -0700, H. Peter Anvin wrote:
> On 07/30/2013 03:14 PM, Dave Jones wrote:
> > 
> > On the subject of trinity, I've been hesitant about proposing a slot
> > at k-s this year, though if there's interest I'm always happy to talk
> > about it, and get feedback for new places it could go..
> > 
> 
> I'd certainly be interested, no matter which forum.

I would be as well.

thx,

Jason.


From broonie at kernel.org  Wed Jul 31 09:57:51 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 31 Jul 2013 14:57:51 +0100
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731134215.GS2810@htj.dyndns.org>
References: <20130731084645.GB1754@pengutronix.de>
 <20130731090512.GD9858@sirena.org.uk>
 <20130731094434.GC1754@pengutronix.de>
 <20130731095411.GA2810@htj.dyndns.org>
 <20130731111853.GJ9858@sirena.org.uk>
 <20130731113244.GI2810@htj.dyndns.org>
 <20130731115027.GN9858@sirena.org.uk>
 <20130731115527.GR2810@htj.dyndns.org>
 <20130731132708.GQ9858@sirena.org.uk>
 <20130731134215.GS2810@htj.dyndns.org>
Message-ID: <20130731135751.GT9858@sirena.org.uk>

On Wed, Jul 31, 2013 at 09:42:15AM -0400, Tejun Heo wrote:
> On Wed, Jul 31, 2013 at 02:27:08PM +0100, Mark Brown wrote:

> > It's really only interrupts that affect most devices - if there's DMA or
> > anything going on after the remove() then as you said earlier the driver
> > is probably doing something wrong.

> Hmmm... it depends on the specific driver is converted but if the
> deactivation sequence - shutting down of command engine - is also
> handled by devm as in libata and if you have non-devres resource free
> in the exit path, you have the same problem.  Again, in general,

That's the only API I've ever heard of doing that.  Everything else is
just using it to do deallocation.
-------------- 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/20130731/052b3772/attachment.sig>

From htejun at gmail.com  Wed Jul 31 10:07:58 2013
From: htejun at gmail.com (Tejun Heo)
Date: Wed, 31 Jul 2013 10:07:58 -0400
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731135751.GT9858@sirena.org.uk>
References: <20130731090512.GD9858@sirena.org.uk>
 <20130731094434.GC1754@pengutronix.de>
 <20130731095411.GA2810@htj.dyndns.org>
 <20130731111853.GJ9858@sirena.org.uk>
 <20130731113244.GI2810@htj.dyndns.org>
 <20130731115027.GN9858@sirena.org.uk>
 <20130731115527.GR2810@htj.dyndns.org>
 <20130731132708.GQ9858@sirena.org.uk>
 <20130731134215.GS2810@htj.dyndns.org>
 <20130731135751.GT9858@sirena.org.uk>
Message-ID: <20130731140758.GT2810@htj.dyndns.org>

On Wed, Jul 31, 2013 at 02:57:51PM +0100, Mark Brown wrote:
> That's the only API I've ever heard of doing that.  Everything else is
> just using it to do deallocation.

I'm not sure why or what you're trying to argue here but take a look
at devm_pwm_release() for example.  It calls back into low level
driver free routine.  Are you arguing that it'd be a good idea to
release pci regions before this is complete?  It's just stupid to do
any differently.  There's nothing to argue about.

-- 
tejun


From B29397 at freescale.com  Wed Jul 31 10:14:41 2013
From: B29397 at freescale.com (Chen Peter-B29397)
Date: Wed, 31 Jul 2013 14:14:41 +0000
Subject: [PATCH v13 00/14] Add tested id switch and vbus connect detect
 support for Chipidea
In-Reply-To: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
References: <1374830310-21765-1-git-send-email-peter.chen@freescale.com>
Message-ID: <F281D0F91ED19E4D8E63A7504E8A649803F691C8@039-SN2MPN1-021.039d.mgd.msft.net>


Hi Alex, any comments, now it finished 3.11-rc4, I don't want this patchset missed at 3.11.

Please tell me which one is OK, and which one needs to be refined, thanks.

Best regards,
Peter
________________________________________
From: linux-usb-owner at vger.kernel.org [linux-usb-owner at vger.kernel.org] on behalf of Peter Chen [peter.chen at freescale.com]
Sent: Friday, July 26, 2013 5:18 PM
To: alexander.shishkin at linux.intel.com
Cc: linux-usb at vger.kernel.org; linux-arm-kernel at lists.infradead.org; festevam at gmail.com; marex at denx.de; maxime.ripard at free-electrons.com; shawn.guo at linaro.org; kernel at pengutronix.de; mkl at pengutronix.de; m.grzeschik at pengutronix.de; gregkh at linuxfoundation.org; Li Frank-B20596
Subject: [PATCH v13 00/14] Add tested id switch and vbus connect detect support for Chipidea

This patchset adds tested otg id switch function and vbus connect
and disconnect detection for chipidea driver. And fix kinds of
bugs found at chipidea drivers after enabling id and vbus detection.

This patch are fully tested at imx6 sabresd and imx28evk platform by me.
Besides, marek tested it on two STMP3780-based boards (not yet mainline)
and two MX28-based boards.

My chipidea repo: https://github.com/hzpeterchen/linux-usb.git

Chagnes for v13:
- Add Tested-by: Marek Vasut <marex at denx.de>
- [Sascha's comments]: Add return value check for devm_regulator_get. [3/14]
- [Marc's comments]: Change timeout usage at hw_wait_reg. [11/14]
- [Alex's comments]: Using platdata flag to indicate dual role but not
OTG controller. [7/14]

Changes for v12:
- Rebased greg's usb-next tree (3.10.0-rc7+)
- Split more small patches for single function and fix.

Changes for v11:
- mark ci_handle_vbus_change as static as it is only used at core.c
[3/9]
- Move the vbus operation for platform code to host code, as vbus
operation is common operation, and host is the only user for vbus.
When it is host mode, we need to open vbus, when it is out of host
mode, we need to close vbus. [6/9] [8/9]
- Delete the delayed work at core.c as it is not needed. [7/9]

Changes for v10:
- Delete [8/9] at v9, ci core's drvdata must be set for further operation.
[8/8]

Changes for v9:
- Some small comments from Alex like: variable comment for otg event
additional newline. [3/9]
- Import function tell show if the controller has otg capable, if
the controller supports both host and device, we think it is otg
capable, and can read OTGSC. [3/9]
- Merge two otg patches [v8 3/8] and [v8 4/8] to one [v9 3/9]. [3/9]
- Add inline to ci_hdrc_gadget_destroy if CONFIG_USB_CHIPIDEA_UDC
is not defined, it can fix one build warning "defined but not used"
[3/9]
- One comment from Felipe about changing calling gadget disconnect
API at chipidea's udc driver. I move calling ci->driver->disconnect
from _gadget_stop_activity to which calls _gadget_stop_activity except
ci13xxx_stop, as udc core will call disconnect when do rmmod gadget. [7/9]
- Add ci core probe's return value to ci's platform_data, we do this
for getting core's probe's result at platform layer, and quit it
if the core's probe fails. [8/9] [9/9]

Changes for v8:
- Add ci_supports_gadget helper to know if the controller
supports gadget, if the controller supports gadget, it
needs to read otgsc to know the vbus value, basically,
if the controller supports gadget, it will support host
as well [3/8]
- At ci_hdrc_probe, it needs to add free memory at error path
[3/8]
- Cosolidate ci->driver = NULL at ci13xxx_stop
[8/8]

Changes for v7:
For Patch 8/8, we only need to set ci->driver to NULL when usb cable
is not connected, for other changes, it will case some runtime pm
unmatch and un-align with udc-core & composite driver problems.

Changes for v6:
- Add Alex comments for init/destroy function [3/8] [4/8]
- Remove memset(&ci->gadget, 0, sizeof(ci->gadget)) at destory function [4/8]
- Add Kishon's comment: Change the format of struct usb_otg otg at drivers/usb/chipidea/ci.h
[1/8]
- Add comments for CI_VBUS_STABLE_TIMEOUT [3/8]
- Change the otg_set_peripheral return value check as the fully
chipidea driver users don't need it. [4/8]
- Fix one bug that the oops when re-plug in usb cable after
rmmod gadget [8/8]

Peter Chen (14):
  usb: chipidea: add vbus regulator control
  usb: chipidea: imx: remove vbus regulator operation
  usb: chipidea: imx: add return value check for devm_regulator_get
  usb: chipidea: udc: otg_set_peripheral is useless for some chipidea
    users
  usb: chipidea: otg: Add otg file used to access otgsc
  usb: chipidea: Add role init and destory APIs
  usb: chipidea: add flag CI_HDRC_DUAL_ROLE_NOT_OTG
  usb: chipidea: disable all interrupts and clear all interrupts status
  usb: chipidea: move otg relate things to otg file
  usb: chipidea: add vbus interrupt handler
  usb: chipidea: add wait vbus lower than OTGSC_BSV before role starts
  usb: chipidea: udc: misuse flag CI_HDRC_REGS_SHARED and
    CI_HDRC_PULLUP_ON_VBUS
  usb: chipidea: udc: .pullup is valid when vbus is on at
    CI_HDRC_PULLUP_ON_VBUS
  usb: chipidea: udc: fix the oops when plugs in usb cable after rmmod
    gadget

 drivers/usb/chipidea/Makefile      |    2 +-
 drivers/usb/chipidea/bits.h        |   10 ++
 drivers/usb/chipidea/ci.h          |    8 ++
 drivers/usb/chipidea/ci_hdrc_imx.c |   40 ++++-----
 drivers/usb/chipidea/core.c        |  161 ++++++++++++++++++++++++------------
 drivers/usb/chipidea/host.c        |   30 +++++++-
 drivers/usb/chipidea/host.h        |    6 ++
 drivers/usb/chipidea/otg.c         |  135 ++++++++++++++++++++++++++++++
 drivers/usb/chipidea/otg.h         |   22 +++++
 drivers/usb/chipidea/udc.c         |   72 ++++++++++++----
 drivers/usb/chipidea/udc.h         |    6 ++
 include/linux/usb/chipidea.h       |    6 ++
 12 files changed, 402 insertions(+), 96 deletions(-)
 create mode 100644 drivers/usb/chipidea/otg.c
 create mode 100644 drivers/usb/chipidea/otg.h


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html




From htejun at gmail.com  Wed Jul 31 10:15:12 2013
From: htejun at gmail.com (Tejun Heo)
Date: Wed, 31 Jul 2013 10:15:12 -0400
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <CAL411-qQm9vgDHswEM6PEvFKAaqd=e3qm-zViUbNztv0tJYa8Q@mail.gmail.com>
References: <20130731084645.GB1754@pengutronix.de>
 <20130731090512.GD9858@sirena.org.uk>
 <20130731094434.GC1754@pengutronix.de>
 <20130731095411.GA2810@htj.dyndns.org>
 <20130731111853.GJ9858@sirena.org.uk>
 <20130731113244.GI2810@htj.dyndns.org>
 <20130731115027.GN9858@sirena.org.uk>
 <20130731115527.GR2810@htj.dyndns.org>
 <20130731132708.GQ9858@sirena.org.uk>
 <CAL411-qQm9vgDHswEM6PEvFKAaqd=e3qm-zViUbNztv0tJYa8Q@mail.gmail.com>
Message-ID: <20130731141512.GU2810@htj.dyndns.org>

hello,

On Wed, Jul 31, 2013 at 09:55:26PM +0800, Peter Chen wrote:
> I think the main point is we should allocate managed resource which is used
> at interrupt handler before devm_request_irq, and all resources used
> at interrupt
> handler should be managed.
> 
> If we use non-managed resource at interrupt handler, but using managed interrupt
> handler, things still will go wrong if there is an odd (unexpected)
> interrupt after
> we finish deactivation at removal.

In general, applying devm partially isn't a good idea.  It's very easy
to get into trouble thanks to release order dependency which isn't
immediately noticeable and there have been actual bugs caused by that.
The strategies which seem to work are either

* Convert everything over to devm by wrapping deactivation in a devres
  callback too.  As long as your init sequence is sane (ie. irq
  shouldn't be request before things used by irq are ready).

* Allocate all resources using devres but shut down the execution
  engine in the remove_one().  Again, as all releases are controlled
  by devres, you won't have to worry about messing up the release
  sequencing.

Thanks.

-- 
tejun


From jason at lakedaemon.net  Wed Jul 31 10:18:41 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 31 Jul 2013 10:18:41 -0400
Subject: [ARM ATTEND] arch/arm SoC organization
Message-ID: <20130731141841.GP5882@titan.lakedaemon.net>

All,

I'd like to take the opportunity to discuss the layout/config of the arm
SoCs.  By the time the KS rolls around, we should have at least two or more
use-cases to present and discuss (mvebu, bcm).

Between devicetree and multiplatform the concept of board-specific code
is really disappearing in arm-land.  eg mach-kirkwood/ is almost fully
converted, within the next window or two, we'll be moving all of the DT
capable boards from kirkwood, orion5x, and dove over to mvebu.
mach-mvebu will then hold 5 different SoCs (it already has Armada 370
and Armada XP).

mach-bcm is in a similar situation (multi-SoC).  I'm sure there are
others (nvidia, ti, etc).

So, I'd like to propose we discuss some lessons learned and maybe arrive
at some best practices.  eg, should we just go with mach-$COMPANY/?  How
best to handle config symbols for efficient building?  Deprecation path
for legacy (unconverted) boards?

Also, to head off the demons, I am *not* proposing reorganizing
everything.  Merely to find some consensus and good ideas so that as
things merge together, we are mostly on the same page.

I'm sure we all have different ideas and I think it'd be good to hear
what everyone else is thinking.

thx,

Jason.


From jonas.jensen at gmail.com  Wed Jul 31 10:20:01 2013
From: jonas.jensen at gmail.com (Jonas Jensen)
Date: Wed, 31 Jul 2013 16:20:01 +0200
Subject: [PATCH v3] net: Add MOXA ART SoCs ethernet driver
In-Reply-To: <1374842890-20735-1-git-send-email-jonas.jensen@gmail.com>
References: <1374842890-20735-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1375280401-5564-1-git-send-email-jonas.jensen@gmail.com>

The MOXA UC-711X hardware(s) has an ethernet controller that seem to be
developed internally. The IC used is "RTL8201CP".

Since there is no public documentation, this driver is mostly the one
published by MOXA that has been heavily cleaned up / ported from linux 2.6.9.

Signed-off-by: Jonas Jensen <jonas.jensen at gmail.com>
---

Notes:
    Changes since v2:
    
    1. Makefile: remove debug flag
    
    Applies to next-20130731

 .../devicetree/bindings/net/moxa,moxart-mac.txt    |  25 +
 drivers/net/ethernet/Kconfig                       |   1 +
 drivers/net/ethernet/Makefile                      |   1 +
 drivers/net/ethernet/moxa/Kconfig                  |  30 ++
 drivers/net/ethernet/moxa/Makefile                 |   5 +
 drivers/net/ethernet/moxa/moxart_ether.c           | 586 +++++++++++++++++++++
 drivers/net/ethernet/moxa/moxart_ether.h           | 513 ++++++++++++++++++
 7 files changed, 1161 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
 create mode 100644 drivers/net/ethernet/moxa/Kconfig
 create mode 100644 drivers/net/ethernet/moxa/Makefile
 create mode 100644 drivers/net/ethernet/moxa/moxart_ether.c
 create mode 100644 drivers/net/ethernet/moxa/moxart_ether.h

diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
new file mode 100644
index 0000000..1fc44ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
@@ -0,0 +1,25 @@
+MOXA ART Ethernet Controller
+
+Required properties:
+
+- compatible : Must be "moxa,moxart-mac"
+- reg : Should contain registers location and length
+  index 0 : main register
+  index 1 : mac address (stored on flash)
+- interrupts : Should contain the mac interrupt number
+
+Example:
+
+	mac0: mac at 90900000 {
+		compatible = "moxa,moxart-mac";
+		reg =	<0x90900000 0x100>,
+			<0x80000050 0x6>;
+		interrupts = <25 0>;
+	};
+
+	mac1: mac at 92000000 {
+		compatible = "moxa,moxart-mac";
+		reg =	<0x92000000 0x100>,
+			<0x80000056 0x6>;
+		interrupts = <27 0>;
+	};
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 2037080..506b024 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -90,6 +90,7 @@ source "drivers/net/ethernet/marvell/Kconfig"
 source "drivers/net/ethernet/mellanox/Kconfig"
 source "drivers/net/ethernet/micrel/Kconfig"
 source "drivers/net/ethernet/microchip/Kconfig"
+source "drivers/net/ethernet/moxa/Kconfig"
 source "drivers/net/ethernet/myricom/Kconfig"
 
 config FEALNX
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 390bd0b..c0b8789 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_NET_VENDOR_MARVELL) += marvell/
 obj-$(CONFIG_NET_VENDOR_MELLANOX) += mellanox/
 obj-$(CONFIG_NET_VENDOR_MICREL) += micrel/
 obj-$(CONFIG_NET_VENDOR_MICROCHIP) += microchip/
+obj-$(CONFIG_NET_VENDOR_MOXART) += moxa/
 obj-$(CONFIG_NET_VENDOR_MYRI) += myricom/
 obj-$(CONFIG_FEALNX) += fealnx.o
 obj-$(CONFIG_NET_VENDOR_NATSEMI) += natsemi/
diff --git a/drivers/net/ethernet/moxa/Kconfig b/drivers/net/ethernet/moxa/Kconfig
new file mode 100644
index 0000000..1731e05
--- /dev/null
+++ b/drivers/net/ethernet/moxa/Kconfig
@@ -0,0 +1,30 @@
+#
+# MOXART device configuration
+#
+
+config NET_VENDOR_MOXART
+	bool "MOXA ART devices"
+	default y
+	depends on (ARM && ARCH_MOXART)
+	---help---
+	  If you have a network (Ethernet) card belonging to this class, say Y
+	  and read the Ethernet-HOWTO, available from
+	  <http://www.tldp.org/docs.html#howto>.
+
+	  Note that the answer to this question doesn't directly affect the
+	  kernel: saying N will just cause the configurator to skip all
+	  the questions about MOXA ART devices. If you say Y, you will be asked
+	  for your specific card in the following questions.
+
+if NET_VENDOR_MOXART
+
+config ARM_MOXART_ETHER
+	tristate "MOXART Ethernet support"
+	depends on ARM && ARCH_MOXART
+	select NET_CORE
+	---help---
+	  If you wish to compile a kernel for a hardware with MOXA ART SoC and
+	  want to use the internal ethernet then you should answer Y to this.
+
+
+endif # NET_VENDOR_MOXART
diff --git a/drivers/net/ethernet/moxa/Makefile b/drivers/net/ethernet/moxa/Makefile
new file mode 100644
index 0000000..aa3c73e9
--- /dev/null
+++ b/drivers/net/ethernet/moxa/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the MOXART network device drivers.
+#
+
+obj-$(CONFIG_ARM_MOXART_ETHER) += moxart_ether.o
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
new file mode 100644
index 0000000..af73c9c
--- /dev/null
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -0,0 +1,586 @@
+/* MOXA ART Ethernet (RTL8201CP) driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/skbuff.h>
+#include <linux/dma-mapping.h>
+#include <linux/ethtool.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/crc32.h>
+#include <linux/crc32c.h>
+#include <linux/dma-mapping.h>
+
+#include "moxart_ether.h"
+
+static inline unsigned long moxart_emac_read(struct net_device *ndev,
+					     unsigned int reg)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	return readl(priv->base + reg);
+}
+
+static inline void moxart_emac_write(struct net_device *ndev,
+				     unsigned int reg, unsigned long value)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	writel(value, priv->base + reg);
+}
+
+static void moxart_update_mac_address(struct net_device *ndev)
+{
+	moxart_emac_write(ndev, MAC_MADR_REG_OFFSET,
+			  ((ndev->dev_addr[0] << 8) | (ndev->dev_addr[1])));
+	moxart_emac_write(ndev, MAC_MADR_REG_OFFSET + 4,
+			  ((ndev->dev_addr[2] << 24) |
+			   (ndev->dev_addr[3] << 16) |
+			   (ndev->dev_addr[4] << 8) |
+			   (ndev->dev_addr[5])));
+}
+
+static int moxart_set_mac_address(struct net_device *ndev, void *addr)
+{
+	struct sockaddr *address = addr;
+
+	if (!is_valid_ether_addr(address->sa_data))
+		return -EADDRNOTAVAIL;
+
+	memcpy(ndev->dev_addr, address->sa_data, ndev->addr_len);
+	moxart_update_mac_address(ndev);
+
+	return 0;
+}
+
+static void moxart_mac_free_memory(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	int i;
+
+	for (i = 0; i < RX_DESC_NUM; i++)
+		dma_unmap_single(&ndev->dev, priv->rx_mapping[i],
+				 priv->rx_buf_size, DMA_FROM_DEVICE);
+
+	if (priv->tx_desc_base)
+		dma_free_coherent(NULL, sizeof(struct tx_desc_t)*TX_DESC_NUM,
+				  priv->tx_desc_base, priv->tx_base);
+	if (priv->rx_desc_base)
+		dma_free_coherent(NULL, sizeof(struct rx_desc_t)*RX_DESC_NUM,
+				  priv->rx_desc_base, priv->rx_base);
+
+	kfree(priv->tx_buf_base);
+	kfree(priv->rx_buf_base);
+}
+
+static void moxart_mac_reset(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	writel(SW_RST, priv->base + MACCR_REG_OFFSET);
+	while (readl(priv->base + MACCR_REG_OFFSET) & SW_RST)
+		mdelay(10);
+
+	writel(0, priv->base + IMR_REG_OFFSET);
+
+	priv->reg_maccr = RX_BROADPKT | FULLDUP | CRC_APD | RX_FTL;
+}
+
+static void moxart_mac_enable(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	writel(0x00001010, priv->base + ITC_REG_OFFSET);
+	writel(0x00000001, priv->base + APTC_REG_OFFSET);
+	writel(0x00000390, priv->base + DBLAC_REG_OFFSET);
+
+	priv->reg_imr |= (RPKT_FINISH_M | XPKT_FINISH_M);
+	writel(priv->reg_imr, priv->base + IMR_REG_OFFSET);
+
+	priv->reg_maccr |= (RCV_EN | XMT_EN | RDMA_EN | XDMA_EN);
+	writel(priv->reg_maccr, priv->base + MACCR_REG_OFFSET);
+}
+
+static void moxart_mac_setup_desc_ring(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	struct tx_desc_t *txdesc;
+	struct rx_desc_t *rxdesc;
+	int i;
+
+	for (i = 0; i < TX_DESC_NUM; i++) {
+		txdesc = &priv->tx_desc_base[i];
+		memset(txdesc, 0, sizeof(struct tx_desc_t));
+
+		priv->tx_buf[i] = priv->tx_buf_base + priv->tx_buf_size * i;
+	}
+	priv->tx_desc_base[TX_DESC_NUM - 1].txdes1.ubit.edotr = 1;
+	priv->tx_head = 0;
+	priv->tx_tail = 0;
+
+	for (i = 0; i < RX_DESC_NUM; i++) {
+		rxdesc = &priv->rx_desc_base[i];
+		memset(rxdesc, 0, sizeof(struct rx_desc_t));
+		rxdesc->rxdes0.ubit.rx_dma_own = 1;
+		rxdesc->rxdes1.ubit.rx_buf_size = RX_BUF_SIZE;
+
+		priv->rx_buf[i] = priv->rx_buf_base + priv->rx_buf_size * i;
+		priv->rx_mapping[i] = dma_map_single(&ndev->dev,
+						     priv->rx_buf[i],
+						     priv->rx_buf_size,
+						     DMA_FROM_DEVICE);
+		if (dma_mapping_error(&ndev->dev, priv->rx_mapping[i]))
+			netdev_err(ndev, "DMA mapping error\n");
+
+		rxdesc->rxdes2.addr_phys = priv->rx_mapping[i];
+		rxdesc->rxdes2.addr_virt = priv->rx_buf[i];
+	}
+	priv->rx_desc_base[RX_DESC_NUM - 1].rxdes1.ubit.edorr = 1;
+	priv->rx_head = 0;
+
+	/* reset the MAC controler TX/RX desciptor base address */
+	writel(priv->tx_base, priv->base + TXR_BADR_REG_OFFSET);
+	writel(priv->rx_base, priv->base + RXR_BADR_REG_OFFSET);
+}
+
+static int moxart_mac_open(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	if (!is_valid_ether_addr(ndev->dev_addr))
+		return -EADDRNOTAVAIL;
+
+	napi_enable(&priv->napi);
+
+	moxart_mac_reset(ndev);
+	moxart_update_mac_address(ndev);
+	moxart_mac_setup_desc_ring(ndev);
+	moxart_mac_enable(ndev);
+	netif_start_queue(ndev);
+
+	netdev_dbg(ndev, "%s: IMR=0x%x, MACCR=0x%x\n",
+		   __func__, readl(priv->base + IMR_REG_OFFSET),
+		   readl(priv->base + MACCR_REG_OFFSET));
+
+	return 0;
+}
+
+static int moxart_mac_stop(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	napi_disable(&priv->napi);
+
+	netif_stop_queue(ndev);
+
+	/* disable all interrupts */
+	writel(0, priv->base + IMR_REG_OFFSET);
+
+	/* disable all functions */
+	writel(0, priv->base + MACCR_REG_OFFSET);
+
+	return 0;
+}
+
+static int moxart_rx_poll(struct napi_struct *napi, int budget)
+{
+	struct moxart_mac_priv_t *priv = container_of(napi,
+						      struct moxart_mac_priv_t,
+						      napi);
+	struct net_device *ndev = priv->ndev;
+	struct rx_desc_t *rxdesc;
+	struct sk_buff *skb;
+	unsigned int ui, len;
+	int rx_head = priv->rx_head;
+	int rx = 0;
+
+	while (1) {
+		rxdesc = &priv->rx_desc_base[rx_head];
+		ui = rxdesc->rxdes0.ui;
+
+		if (ui & RXDMA_OWN)
+			break;
+
+		if (ui & (RX_ERR | CRC_ERR | FTL | RUNT | RX_ODD_NB)) {
+			netdev_err(ndev, "packet error\n");
+			priv->stats.rx_dropped++;
+			priv->stats.rx_errors++;
+			continue;
+		}
+
+		len = ui & RFL_MASK;
+
+		if (len > RX_BUF_SIZE)
+			len = RX_BUF_SIZE;
+
+		skb = build_skb(priv->rx_buf[rx_head], priv->rx_buf_size);
+		if (unlikely(!skb)) {
+			netdev_err(ndev, "build_skb failed\n");
+			priv->stats.rx_dropped++;
+		}
+
+		skb_put(skb, len);
+		skb->protocol = eth_type_trans(skb, ndev);
+		napi_gro_receive(&priv->napi, skb);
+		rx++;
+
+		ndev->last_rx = jiffies;
+		priv->stats.rx_packets++;
+		priv->stats.rx_bytes += len;
+		if (ui & MULTICAST_RXDES0)
+			priv->stats.multicast++;
+
+		rxdesc->rxdes0.ui = RXDMA_OWN;
+
+		rx_head = RX_NEXT(rx_head);
+		priv->rx_head = rx_head;
+
+		if (rx >= budget)
+			break;
+	}
+
+	if (rx < budget) {
+		napi_gro_flush(napi, false);
+		__napi_complete(napi);
+	}
+
+	priv->reg_imr |= RPKT_FINISH_M;
+	writel(priv->reg_imr, priv->base + IMR_REG_OFFSET);
+
+	return rx;
+}
+
+static void moxart_tx_finished(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	unsigned tx_head = priv->tx_head;
+	unsigned tx_tail = priv->tx_tail;
+
+	while (tx_tail != tx_head) {
+		dma_unmap_single(&ndev->dev, priv->tx_mapping[tx_tail],
+				 priv->tx_len[tx_tail], DMA_TO_DEVICE);
+		dev_kfree_skb_irq(priv->tx_skb[tx_tail]);
+
+		priv->stats.tx_packets++;
+		priv->stats.tx_bytes += priv->tx_skb[tx_tail]->len;
+
+		priv->tx_skb[tx_tail] = NULL;
+
+		tx_tail = TX_NEXT(tx_tail);
+	}
+	priv->tx_tail = tx_tail;
+}
+
+static irqreturn_t moxart_mac_interrupt(int irq, void *dev_id)
+{
+	struct net_device *ndev = (struct net_device *) dev_id;
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	unsigned int ists = readl(priv->base + ISR_REG_OFFSET);
+
+	if (ists & XPKT_OK_INT_STS)
+		moxart_tx_finished(ndev);
+
+	if (ists & RPKT_FINISH) {
+		if (napi_schedule_prep(&priv->napi)) {
+			priv->reg_imr &= ~RPKT_FINISH_M;
+			writel(priv->reg_imr, priv->base + IMR_REG_OFFSET);
+			__napi_schedule(&priv->napi);
+		}
+	}
+
+	return IRQ_HANDLED;
+}
+
+static int moxart_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	struct tx_desc_t *txdesc;
+	unsigned int len;
+	unsigned int tx_head = priv->tx_head;
+
+	spin_lock_irq(&priv->txlock);
+
+	txdesc = &priv->tx_desc_base[tx_head];
+
+	if (txdesc->txdes0.ubit.tx_dma_own) {
+		netdev_err(ndev, "no TX space for packet\n");
+		priv->stats.tx_dropped++;
+		return NETDEV_TX_BUSY;
+	}
+
+	len = skb->len > TX_BUF_SIZE ? TX_BUF_SIZE : skb->len;
+
+	priv->tx_mapping[tx_head] = dma_map_single(&ndev->dev, skb->data,
+						   len, DMA_TO_DEVICE);
+	if (dma_mapping_error(&ndev->dev, priv->tx_mapping[tx_head])) {
+		netdev_err(ndev, "DMA mapping error\n");
+		return NETDEV_TX_BUSY;
+	}
+
+	priv->tx_len[tx_head] = len;
+	priv->tx_skb[tx_head] = skb;
+
+	txdesc->txdes2.addr_phys = priv->tx_mapping[tx_head];
+	txdesc->txdes2.addr_virt = skb->data;
+
+	if (skb->len < ETH_ZLEN) {
+		memset(&txdesc->txdes2.addr_virt[skb->len],
+		       0, ETH_ZLEN - skb->len);
+		len = ETH_ZLEN;
+	}
+
+	txdesc->txdes1.ubit.lts = 1;
+	txdesc->txdes1.ubit.fts = 1;
+	txdesc->txdes1.ubit.tx2_fic = 0;
+	txdesc->txdes1.ubit.tx_ic = 0;
+	txdesc->txdes1.ubit.tx_buf_size = len;
+	txdesc->txdes0.ui = TXDMA_OWN;
+
+	/* start to send packet */
+	writel(0xffffffff, priv->base + TXPD_REG_OFFSET);
+
+	priv->tx_head = TX_NEXT(tx_head);
+
+	ndev->trans_start = jiffies;
+
+	spin_unlock_irq(&priv->txlock);
+
+	return NETDEV_TX_OK;
+}
+
+static struct net_device_stats *moxart_mac_get_stats(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	return &priv->stats;
+}
+
+static void moxart_mac_setmulticast(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	struct netdev_hw_addr *ha;
+	int crc_val;
+
+	netdev_for_each_mc_addr(ha, ndev) {
+		crc_val = crc32_le(~0, ha->addr, ETH_ALEN);
+		crc_val = (crc_val >> 26) & 0x3f;
+		if (crc_val >= 32) {
+			writel(readl(priv->base + MATH1_REG_OFFSET) |
+			       (1UL << (crc_val - 32)),
+			       priv->base + MATH1_REG_OFFSET);
+		} else {
+			writel(readl(priv->base + MATH0_REG_OFFSET) |
+			       (1UL << crc_val),
+			       priv->base + MATH0_REG_OFFSET);
+		}
+	}
+}
+
+static void moxart_mac_set_rx_mode(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+
+	spin_lock_irq(&priv->txlock);
+
+	(ndev->flags & IFF_PROMISC) ? (priv->reg_maccr |= RCV_ALL) :
+				      (priv->reg_maccr &= ~RCV_ALL);
+
+	(ndev->flags & IFF_ALLMULTI) ? (priv->reg_maccr |= RX_MULTIPKT) :
+				       (priv->reg_maccr &= ~RX_MULTIPKT);
+
+	if ((ndev->flags & IFF_MULTICAST) && netdev_mc_count(ndev)) {
+		priv->reg_maccr |= HT_MULTI_EN;
+		moxart_mac_setmulticast(ndev);
+	} else {
+		priv->reg_maccr &= ~HT_MULTI_EN;
+	}
+
+	writel(priv->reg_maccr, priv->base + MACCR_REG_OFFSET);
+
+	spin_unlock_irq(&priv->txlock);
+}
+
+static struct net_device_ops moxart_netdev_ops = {
+	.ndo_open		= moxart_mac_open,
+	.ndo_stop		= moxart_mac_stop,
+	.ndo_start_xmit		= moxart_mac_start_xmit,
+	.ndo_get_stats		= moxart_mac_get_stats,
+	.ndo_set_rx_mode	= moxart_mac_set_rx_mode,
+	.ndo_set_mac_address	= moxart_set_mac_address,
+	.ndo_validate_addr	= eth_validate_addr,
+	.ndo_change_mtu		= eth_change_mtu,
+};
+
+static void moxart_get_mac_address(struct net_device *ndev)
+{
+	struct moxart_mac_priv_t *priv = netdev_priv(ndev);
+	int i;
+
+	for (i = 0; i <= 5; i++)
+		ndev->dev_addr[i] = readb(priv->flash_base + i);
+}
+
+static int moxart_mac_probe(struct platform_device *pdev)
+{
+	struct device *p_dev = &pdev->dev;
+	struct device_node *node = p_dev->of_node;
+	struct net_device *ndev;
+	struct moxart_mac_priv_t *priv;
+	struct resource *res;
+	unsigned int irq;
+	void *tmp;
+
+	ndev = alloc_etherdev(sizeof(struct moxart_mac_priv_t));
+	if (!ndev)
+		return -ENOMEM;
+
+	irq = irq_of_parse_and_map(node, 0);
+
+	priv = netdev_priv(ndev);
+	priv->ndev = ndev;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	ndev->base_addr = res->start;
+	priv->base = devm_ioremap_resource(p_dev, res);
+	if (IS_ERR(priv->base)) {
+		dev_err(p_dev, "devm_ioremap_resource failed\n");
+		goto init_fail;
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+
+	/* the flash driver (physmap_of) requests the same region
+	 * so use ioremap instead of devm_ioremap_resource
+	 */
+	priv->flash_base = ioremap(res->start, resource_size(res));
+	if (IS_ERR(priv->flash_base)) {
+		dev_err(p_dev, "devm_ioremap_resource failed\n");
+		goto init_fail;
+	}
+
+	spin_lock_init(&priv->txlock);
+
+	priv->tx_buf_size = TX_BUF_SIZE;
+	priv->rx_buf_size = RX_BUF_SIZE +
+			    SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+
+	tmp = dma_alloc_coherent(NULL, sizeof(struct tx_desc_t) * TX_DESC_NUM,
+				 &priv->tx_base, GFP_DMA | GFP_KERNEL);
+	priv->tx_desc_base = (struct tx_desc_t *) tmp;
+	if (priv->tx_desc_base == NULL) {
+		netdev_err(ndev, "TX descriptor alloc failed\n");
+		goto init_fail;
+	}
+
+	tmp = dma_alloc_coherent(NULL, sizeof(struct rx_desc_t) * RX_DESC_NUM,
+				 &priv->rx_base, GFP_DMA | GFP_KERNEL);
+	priv->rx_desc_base = (struct rx_desc_t *) tmp;
+	if (priv->rx_desc_base == NULL) {
+		netdev_err(ndev, "RX descriptor alloc failed\n");
+		goto init_fail;
+	}
+
+	priv->tx_buf_base = kmalloc(priv->tx_buf_size * TX_DESC_NUM,
+				    GFP_ATOMIC);
+	if (!priv->tx_buf_base) {
+		netdev_err(ndev, "TX buffer alloc failed\n");
+		goto init_fail;
+	}
+
+	priv->rx_buf_base = kmalloc(priv->rx_buf_size * RX_DESC_NUM,
+				    GFP_ATOMIC);
+	if (!priv->rx_buf_base) {
+		netdev_err(ndev, "RX buffer alloc failed\n");
+		goto init_fail;
+	}
+
+	platform_set_drvdata(pdev, ndev);
+
+	ether_setup(ndev);
+	ndev->netdev_ops = &moxart_netdev_ops;
+	netif_napi_add(ndev, &priv->napi, moxart_rx_poll, RX_DESC_NUM);
+	ndev->priv_flags |= IFF_UNICAST_FLT;
+
+	SET_NETDEV_DEV(ndev, &pdev->dev);
+
+	moxart_get_mac_address(ndev);
+	moxart_update_mac_address(ndev);
+
+	if (register_netdev(ndev)) {
+		free_netdev(ndev);
+		goto init_fail;
+	}
+
+	ndev->irq = irq;
+
+	if (devm_request_irq(p_dev, irq, moxart_mac_interrupt, 0,
+			     pdev->name, ndev)) {
+		netdev_err(ndev, "devm_request_irq failed\n");
+		free_netdev(ndev);
+		return -EBUSY;
+	}
+
+	netdev_dbg(ndev, "%s: IRQ=%d address=%02x:%02x:%02x:%02x:%02x:%02x\n",
+		   __func__, ndev->irq,
+		   ndev->dev_addr[0], ndev->dev_addr[1], ndev->dev_addr[2],
+		   ndev->dev_addr[3], ndev->dev_addr[4], ndev->dev_addr[5]);
+
+	return 0;
+
+init_fail:
+	netdev_err(ndev, "%s: init failed\n", __func__);
+	moxart_mac_free_memory(ndev);
+
+	return -ENOMEM;
+}
+
+static int moxart_remove(struct platform_device *pdev)
+{
+	struct net_device *ndev = platform_get_drvdata(pdev);
+
+	unregister_netdev(ndev);
+	free_irq(ndev->irq, ndev);
+	moxart_mac_free_memory(ndev);
+	platform_set_drvdata(pdev, NULL);
+	free_netdev(ndev);
+
+	return 0;
+}
+
+static const struct of_device_id moxart_mac_match[] = {
+	{ .compatible = "moxa,moxart-mac" },
+	{ }
+};
+
+struct __initdata platform_driver moxart_mac_driver = {
+	.probe	= moxart_mac_probe,
+	.remove	= moxart_remove,
+	.driver	= {
+		.name		= "moxart-ethernet",
+		.owner		= THIS_MODULE,
+		.of_match_table	= moxart_mac_match,
+	},
+};
+module_platform_driver(moxart_mac_driver);
+
+MODULE_DESCRIPTION("MOXART RTL8201CP Ethernet driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen at gmail.com>");
+
diff --git a/drivers/net/ethernet/moxa/moxart_ether.h b/drivers/net/ethernet/moxa/moxart_ether.h
new file mode 100644
index 0000000..790b6a9
--- /dev/null
+++ b/drivers/net/ethernet/moxa/moxart_ether.h
@@ -0,0 +1,513 @@
+/* MOXA ART Ethernet (RTL8201CP) driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen at gmail.com>
+ *
+ * Based on code from
+ * Moxa Technology Co., Ltd. <www.moxa.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _MOXART_ETHERNET_H
+#define _MOXART_ETHERNET_H
+
+#define TX_DESC_NUM		64
+#define TX_DESC_NUM_MASK	(TX_DESC_NUM-1)
+#define TX_NEXT(N)		(((N) + 1) & (TX_DESC_NUM_MASK))
+#define TX_BUF_SIZE		1600
+
+#define RX_DESC_NUM		64
+#define RX_DESC_NUM_MASK	(RX_DESC_NUM-1)
+#define RX_NEXT(N)		(((N) + 1) & (RX_DESC_NUM_MASK))
+#define RX_BUF_SIZE		1600
+
+struct tx_desc_t {
+	union {
+#define TXDMA_OWN		BIT(31)
+#define TXPKT_EXSCOL		BIT(1)
+#define TXPKT_LATECOL		BIT(0)
+		unsigned int ui;
+
+		struct {
+			/* is aborted due to late collision */
+			unsigned int tx_pkt_late_col:1;
+
+			/* is aborted after 16 collisions */
+			unsigned int rx_pkt_exs_col:1;
+
+			unsigned int reserved1:29;
+
+			/* is owned by the MAC controller */
+			unsigned int tx_dma_own:1;
+		} ubit;
+	} txdes0;
+
+	union {
+#define EDOTR			BIT(31)
+#define TXIC			BIT(30)
+#define TX2FIC			BIT(29)
+#define FTS			BIT(28)
+#define LTS			BIT(27)
+#define TXBUF_SIZE_MASK		0x7ff
+#define TXBUF_SIZE_MAX		(TXBUF_SIZE_MASK+1)
+		unsigned int ui;
+
+		struct {
+			/* transmit buffer size in byte */
+			unsigned int tx_buf_size:11;
+
+			unsigned int reserved2:16;
+
+			/* is the last descriptor of a Tx packet */
+			unsigned int lts:1;
+
+			/* is the first descriptor of a Tx packet */
+			unsigned int fts:1;
+
+			/* transmit to FIFO interrupt on completion */
+			unsigned int tx2_fic:1;
+
+			/* transmit interrupt on completion */
+			unsigned int tx_ic:1;
+
+			/* end descriptor of transmit ring */
+			unsigned int edotr:1;
+		} ubit;
+	} txdes1;
+
+	struct {
+		/* transmit buffer physical base address */
+		unsigned int addr_phys;
+
+		/* transmit buffer virtual base address */
+		unsigned char *addr_virt;
+	} txdes2;
+};
+
+struct rx_desc_t {
+	union {
+#define RXDMA_OWN		BIT(31)
+#define FRS			BIT(29)
+#define LRS			BIT(28)
+#define RX_ODD_NB		BIT(22)
+#define RUNT			BIT(21)
+#define FTL			BIT(20)
+#define CRC_ERR			BIT(19)
+#define RX_ERR			BIT(18)
+#define BROADCAST_RXDES0	BIT(17)
+#define MULTICAST_RXDES0	BIT(16)
+#define RFL_MASK		0x7ff
+#define RFL_MAX			(RFL_MASK+1)
+		unsigned int ui;
+
+		struct {
+			/* receive frame length */
+			unsigned int recv_frame_len:11;
+			unsigned int reserved1:5;
+
+			/* multicast frame */
+			unsigned int multicast:1;
+
+			/* broadcast frame */
+			unsigned int broadcast:1;
+			unsigned int rx_err:1;		/* receive error */
+			unsigned int crc_err:1;		/* CRC error */
+			unsigned int ftl:1;		/* frame too long */
+
+			/* runt packet, less than 64 bytes */
+			unsigned int runt:1;
+
+			/* receive odd nibbles */
+			unsigned int rx_odd_nb:1;
+			unsigned int reserved2:5;
+
+			/* last receive segment descriptor */
+			unsigned int lrs:1;
+
+			/* first receive segment descriptor */
+			unsigned int frs:1;
+
+			unsigned int reserved3:1;
+			unsigned int rx_dma_own:1;	/* RXDMA onwership */
+		} ubit;
+	} rxdes0;
+
+	union {
+#define EDORR			BIT(31)
+#define RXBUF_SIZE_MASK		0x7ff
+#define RXBUF_SIZE_MAX		(RXBUF_SIZE_MASK+1)
+		unsigned int ui;
+
+		struct {
+			/* receive buffer size */
+			unsigned int rx_buf_size:11;
+
+			unsigned int reserved4:20;
+
+			/* end descriptor of receive ring */
+			unsigned int edorr:1;
+		} ubit;
+	} rxdes1;
+
+	struct {
+		/* receive buffer physical base address */
+		unsigned int addr_phys;
+
+		/* receive buffer virtual base address */
+		unsigned char *addr_virt;
+	} rxdes2;
+};
+
+struct mac_control_reg_t {
+
+/* RXDMA has received packets into RX buffer successfully */
+#define RPKT_FINISH		BIT(0)
+/* receive buffer unavailable */
+#define NORXBUF			BIT(1)
+/* TXDMA has moved data into the TX FIFO */
+#define XPKT_FINISH		BIT(2)
+/* transmit buffer unavailable */
+#define NOTXBUF			BIT(3)
+/* packets transmitted to ethernet successfully */
+#define XPKT_OK_INT_STS		BIT(4)
+/* packets transmitted to ethernet lost due to late
+ * collision or excessive collision
+ */
+#define XPKT_LOST_INT_STS	BIT(5)
+/* packets received into RX FIFO successfully */
+#define RPKT_SAV		BIT(6)
+/* received packet lost due to RX FIFO full */
+#define RPKT_LOST_INT_STS	BIT(7)
+#define AHB_ERR			BIT(8)		/* AHB error */
+#define PHYSTS_CHG		BIT(9)		/* PHY link status change */
+	unsigned int isr;			/* interrupt status, 0x0 */
+
+#define RPKT_FINISH_M		BIT(0)		/* interrupt mask of ISR[0] */
+#define NORXBUF_M		BIT(1)		/* interrupt mask of ISR[1] */
+#define XPKT_FINISH_M		BIT(2)		/* interrupt mask of ISR[2] */
+#define NOTXBUF_M		BIT(3)		/* interrupt mask of ISR[3] */
+#define XPKT_OK_M		BIT(4)		/* interrupt mask of ISR[4] */
+#define XPKT_LOST_M		BIT(5)		/* interrupt mask of ISR[5] */
+#define RPKT_SAV_M		BIT(6)		/* interrupt mask of ISR[6] */
+#define RPKT_LOST_M		BIT(7)		/* interrupt mask of ISR[7] */
+#define AHB_ERR_M		BIT(8)		/* interrupt mask of ISR[8] */
+#define PHYSTS_CHG_M		BIT(9)		/* interrupt mask of ISR[9] */
+	unsigned int imr;			/* interrupt mask, 0x4 */
+
+/* the most significant 2 bytes of MAC address */
+#define MAC_MADR_MASK		0xffff
+	/* MAC most significant address, 0x8 */
+	unsigned int mac_madr;
+
+	/* MAC least significant address, 0xc */
+	unsigned int mac_ldar;
+
+	/* multicast address hash table 0, 0x10 */
+	unsigned int matht0;
+
+	/* multicast address hash table 1, 0x14 */
+	unsigned int matht1;
+
+	/* transmit poll demand, 0x18 */
+	unsigned int txpd;
+
+	/* receive poll demand, 0x1c */
+	unsigned int rxpd;
+
+	/* transmit ring base address, 0x20 */
+	unsigned int txr_badr;
+
+	/* receive ring base address, 0x24 */
+	unsigned int rxr_badr;
+
+/* defines the period of TX cycle time */
+#define TXINT_TIME_SEL		BIT(15)
+#define TXINT_THR_MASK		0x7000
+#define TXINT_CNT_MASK		0xf00
+/* defines the period of RX cycle time */
+#define RXINT_TIME_SEL		BIT(7)
+#define RXINT_THR_MASK		0x70
+#define RXINT_CNT_MASK		0xF
+	/* interrupt timer control, 0x28 */
+	unsigned int itc;
+
+/* defines the period of TX poll time */
+#define TXPOLL_TIME_SEL		BIT(12)
+#define TXPOLL_CNT_MASK		0xf00
+#define TXPOLL_CNT_SHIFT_BIT	8
+/* defines the period of RX poll time */
+#define RXPOLL_TIME_SEL		BIT(4)
+#define RXPOLL_CNT_MASK		0xF
+#define RXPOLL_CNT_SHIFT_BIT	0
+	/* automatic polling timer control, 0x2c */
+	unsigned int aptc;
+
+/* enable RX FIFO threshold arbitration */
+#define RX_THR_EN		BIT(9)
+#define RXFIFO_HTHR_MASK	0x1c0
+#define RXFIFO_LTHR_MASK	0x38
+/* use INCR16 burst command in AHB bus */
+#define INCR16_EN		BIT(2)
+/* use INCR8 burst command in AHB bus */
+#define INCR8_EN		BIT(1)
+/* use INCR4 burst command in AHB bus */
+#define INCR4_EN		BIT(0)
+	/* DMA burst length and arbitration control, 0x30 */
+	unsigned int dblac;
+
+	unsigned int reserved1[21];		/* 0x34 - 0x84 */
+
+#define RX_BROADPKT		BIT(17)		/* receive boradcast packet */
+/* receive all multicast packet */
+#define RX_MULTIPKT		BIT(16)
+#define FULLDUP			BIT(15)		/* full duplex */
+/* append CRC to transmitted packet */
+#define CRC_APD			BIT(14)
+/* do not check incoming packet's destination address */
+#define RCV_ALL			BIT(12)
+/* store incoming packet even if its length is great than 1518 bytes */
+#define RX_FTL			BIT(11)
+/* store incoming packet even if its length is less than 64 bytes */
+#define RX_RUNT			BIT(10)
+/* enable storing incoming packet if the packet passes hash table
+ * address filtering and is a multicast packet
+ */
+#define HT_MULTI_EN		BIT(9)
+#define RCV_EN			BIT(8)		/* receiver enable */
+/* enable packet reception when transmitting packet in half duplex mode */
+#define ENRX_IN_HALFTX		BIT(6)
+#define XMT_EN			BIT(5)		/* transmitter enable */
+/* disable CRC check when receiving packets */
+#define CRC_DIS			BIT(4)
+#define LOOP_EN			BIT(3)		/* internal loop-back */
+/* software reset, last 64 AHB bus clocks */
+#define SW_RST			BIT(2)
+#define RDMA_EN			BIT(1)		/* enable receive DMA chan */
+#define XDMA_EN			BIT(0)		/* enable transmit DMA chan */
+	unsigned int maccr;			/* MAC control, 0x88 */
+
+#define COL_EXCEED		BIT(11)		/* collisions exceeds 16 */
+/* transmitter detects late collision */
+#define LATE_COL		BIT(10)
+/* packet transmitted to ethernet lost due to late collision
+ * or excessive collision
+ */
+#define XPKT_LOST		BIT(9)
+/* packets transmitted to ethernet successfully */
+#define XPKT_OK			BIT(8)
+/* receiver detects a runt packet */
+#define RUNT_MAC_STS		BIT(7)
+/* receiver detects a frame that is too long */
+#define FTL_MAC_STS		BIT(6)
+#define CRC_ERR_MAC_STS		BIT(5)
+/* received packets list due to RX FIFO full */
+#define RPKT_LOST		BIT(4)
+/* packets received into RX FIFO successfully */
+#define RPKT_SAVE		BIT(3)
+/* incoming packet dropped due to collision */
+#define COL			BIT(2)
+#define MCPU_BROADCAST		BIT(1)
+#define MCPU_MULTICAST		BIT(0)
+	unsigned int macsr;			/* MAC status, 0x8c */
+
+/* initialize a write sequence to PHY by setting this bit to 1
+ * this bit would be auto cleared after the write operation is finished.
+ */
+#define MIIWR			BIT(27)
+#define MIIRD			BIT(26)
+#define REGAD_MASK		0x3e00000
+#define PHYAD_MASK		0x1f0000
+#define MIIRDATA_MASK		0xffff
+	unsigned int phycr;			/* PHY control, 0x90 */
+
+#define MIIWDATA_MASK		0xffff
+	unsigned int phywdata;			/* PHY write data, 0x94 */
+
+#define PAUSE_TIME_MASK		0xffff0000
+#define FC_HIGH_MASK		0xf000
+#define FC_LOW_MASK		0xf00
+#define RX_PAUSE		BIT(4)		/* receive pause frame */
+/* packet transmission is paused due to receive */
+#define TXPAUSED		BIT(3)
+	/* pause frame */
+/* enable flow control threshold mode. */
+#define FCTHR_EN		BIT(2)
+#define TX_PAUSE		BIT(1)		/* transmit pause frame */
+#define FC_EN			BIT(0)		/* flow control mode enable */
+	unsigned int fcr;			/* flow control, 0x98 */
+
+#define BK_LOW_MASK		0xf00
+#define BKJAM_LEN_MASK		0xf0
+#define BK_MODE			BIT(1)		/* back pressure address mode */
+#define BK_EN			BIT(0)		/* back pressure mode enable */
+	unsigned int bpr;			/* back pressure, 0x9c */
+
+	unsigned int reserved2[9];		/* 0xa0 - 0xc0 */
+
+#define TEST_SEED_MASK      0x3fff
+	unsigned int ts;			/* test seed, 0xc4 */
+
+#define TXD_REQ			BIT(31)		/* TXDMA request */
+#define RXD_REQ			BIT(30)		/* RXDMA request */
+#define DARB_TXGNT		BIT(29)		/* TXDMA grant */
+#define DARB_RXGNT		BIT(28)		/* RXDMA grant */
+#define TXFIFO_EMPTY		BIT(27)		/* TX FIFO is empty */
+#define RXFIFO_EMPTY		BIT(26)		/* RX FIFO is empty */
+#define TXDMA2_SM_MASK		0x7000
+#define TXDMA1_SM_MASK		0xf00
+#define RXDMA2_SM_MASK		0x70
+#define RXDMA1_SM_MASK		0xF
+	unsigned int dmafifos;			/* DMA/FIFO state, 0xc8 */
+
+#define SINGLE_PKT		BIT(26)		/* single packet mode */
+/* automatic polling timer test mode */
+#define PTIMER_TEST		BIT(25)
+#define ITIMER_TEST		BIT(24)		/* interrupt timer test mode */
+#define TEST_SEED_SEL		BIT(22)		/* test seed select */
+#define SEED_SEL		BIT(21)		/* seed select */
+#define TEST_MODE		BIT(20)		/* transmission test mode */
+#define TEST_TIME_MASK		0xffc00
+#define TEST_EXCEL_MASK		0x3e0
+	unsigned int tm;			/* test mode, 0xcc */
+
+	unsigned int reserved3;			/* 0xd0 */
+
+#define TX_MCOL_MASK		0xffff0000
+#define TX_MCOL_SHIFT_BIT	16
+#define TX_SCOL_MASK		0xffff
+#define TX_SCOL_SHIFT_BIT	0
+	/* TX_MCOL and TX_SCOL counter, 0xd4 */
+	unsigned int txmcol_xscol;
+
+#define RPF_MASK		0xffff0000
+#define RPF_SHIFT_BIT		16
+#define AEP_MASK		0xffff
+#define AEP_SHIFT_BIT		0
+	unsigned int rpf_aep;			/* RPF and AEP counter, 0xd8 */
+
+#define XM_MASK			0xffff0000
+#define XM_SHIFT_BIT		16
+#define PG_MASK			0xffff
+#define PG_SHIFT_BIT		0
+	unsigned int xm_pg;			/* XM and PG counter, 0xdc */
+
+#define RUNT_CNT_MASK		0xffff0000
+#define RUNT_CNT_SHIFT_BIT	16
+#define TLCC_MASK		0xffff
+#define TLCC_SHIFT_BIT		0
+	/* RUNT_CNT and TLCC counter, 0xe0 */
+	unsigned int runtcnt_tlcc;
+
+#define CRCER_CNT_MASK		0xffff0000
+#define CRCER_CNT_SHIFT_BIT	16
+#define FTL_CNT_MASK		0xffff
+#define FTL_CNT_SHIFT_BIT	0
+	/* CRCER_CNT and FTL_CNT counter, 0xe4 */
+	unsigned int crcercnt_ftlcnt;
+
+#define RLC_MASK		0xffff0000
+#define RLC_SHIFT_BIT		16
+#define RCC_MASK		0xffff
+#define RCC_SHIFT_BIT		0
+	unsigned int rlc_rcc;		/* RLC and RCC counter, 0xe8 */
+
+	unsigned int broc;		/* BROC counter, 0xec */
+	unsigned int mulca;		/* MULCA counter, 0xf0 */
+	unsigned int rp;		/* RP counter, 0xf4 */
+	unsigned int xp;		/* XP counter, 0xf8 */
+};
+
+#define ISR_REG_OFFSET			0x0
+#define IMR_REG_OFFSET			0x4
+#define MAC_MADR_REG_OFFSET		0x8
+#define MAC_LADR_REG_OFFSET		0xC
+#define MATH0_REG_OFFSET		0x10
+#define MATH1_REG_OFFSET		0x14
+#define TXPD_REG_OFFSET			0x18
+#define RXPD_REG_OFFSET			0x1C
+#define TXR_BADR_REG_OFFSET		0x20
+#define RXR_BADR_REG_OFFSET		0x24
+#define ITC_REG_OFFSET			0x28
+#define APTC_REG_OFFSET			0x2C
+#define DBLAC_REG_OFFSET		0x30
+#define MACCR_REG_OFFSET		0x88
+#define MACSR_REG_OFFSET		0x8C
+#define PHYCR_REG_OFFSET		0x90
+#define PHYWDATA_REG_OFFSET		0x94
+#define FCR_REG_OFFSET			0x98
+#define BPR_REG_OFFSET			0x9C
+#define TS_REG_OFFSET			0xC4
+#define DMAFIFOS_REG_OFFSET		0xC8
+#define TM_REG_OFFSET			0xCC
+#define TX_MCOL_TX_SCOL_REG_OFFSET	0xD4
+#define RPF_AEP_REG_OFFSET		0xD8
+#define XM_PG_REG_OFFSET		0xDC
+#define RUNT_CNT_TLCC_REG_OFFSET	0xE0
+#define CRCER_CNT_FTL_CNT_REG_OFFSET	0xE4
+#define RLC_RCC_REG_OFFSET		0xE8
+#define BROC_REG_OFFSET			0xEC
+#define MULCA_REG_OFFSET		0xF0
+#define RP_REG_OFFSET			0xF4
+#define XP_REG_OFFSET			0xF8
+#define PHY_CNTL_REG			0x0
+#define PHY_STATUS_REG			0x1
+#define PHY_ID_REG1			0x2
+#define PHY_ID_REG2			0x3
+#define PHY_ANA_REG			0x4
+#define PHY_ANLPAR_REG			0x5
+#define PHY_ANE_REG			0x6
+#define PHY_ECNTL_REG1			0x10
+#define PHY_QPDS_REG			0x11
+#define PHY_10BOP_REG			0x12
+#define PHY_ECNTL_REG2			0x13
+#define FTMAC100_REG_PHY_WRITE		0x8000000
+#define FTMAC100_REG_PHY_READ		0x4000000
+
+/* PHY Status register */
+#define AN_COMPLETE			0x20
+
+#define LINK_STATUS			0x4
+
+struct moxart_mac_priv_t {
+	void __iomem *base;
+	void __iomem *flash_base;
+	struct net_device_stats stats;
+	unsigned int reg_maccr;
+	unsigned int reg_imr;
+	struct napi_struct napi;
+	struct net_device *ndev;
+
+	dma_addr_t rx_base;
+	dma_addr_t rx_mapping[RX_DESC_NUM];
+	struct rx_desc_t *rx_desc_base;
+	unsigned char *rx_buf_base;
+	unsigned char *rx_buf[RX_DESC_NUM];
+	unsigned int rx_head;
+	unsigned int rx_buf_size;
+
+	dma_addr_t tx_base;
+	dma_addr_t tx_mapping[TX_DESC_NUM];
+	struct tx_desc_t *tx_desc_base;
+	unsigned char *tx_buf_base;
+	unsigned char *tx_buf[RX_DESC_NUM];
+	unsigned int tx_head;
+	unsigned int tx_buf_size;
+
+	spinlock_t txlock;
+	unsigned int tx_len[TX_DESC_NUM];
+	struct sk_buff *tx_skb[TX_DESC_NUM];
+	unsigned int tx_tail;
+};
+
+#if TX_BUF_SIZE >= TXBUF_SIZE_MAX
+#error MOXA ART Ethernet device driver Tx buffer size too large !
+#endif
+#if RX_BUF_SIZE >= RXBUF_SIZE_MAX
+#error MOXA ART Ethernet device driver Rx buffer size too large !
+#endif
+
+#endif
-- 
1.8.2.1



From davej at redhat.com  Wed Jul 31 10:24:30 2013
From: davej at redhat.com (Dave Jones)
Date: Wed, 31 Jul 2013 10:24:30 -0400
Subject: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit
 mitigations
In-Reply-To: <20130731094012.GU24642@n2100.arm.linux.org.uk>
References: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
 <20130730221435.GA22240@redhat.com>
 <20130730231120.GC30725@blackmetal.musicnaut.iki.fi>
 <20130730231533.GA26824@redhat.com>
 <20130730235834.GD30725@blackmetal.musicnaut.iki.fi>
 <20130731000444.GC1281@redhat.com>
 <20130731094012.GU24642@n2100.arm.linux.org.uk>
Message-ID: <20130731142430.GA4545@redhat.com>

On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
 > On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
 > > To use ARM as an example, the bugs I've seen have mostly been in arch specific
 > > code that does things like page-table manipulation.  The chromebook bugs I
 > > was hitting for eg were various kinds of PTE corruption warnings. 
 > 
 > Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
 > having any changes related to bug reports on PTEs on ARM.

I wasn't sure if it was a googleism, or happens on mainline, so no.

	Dave



From stern at rowland.harvard.edu  Wed Jul 31 10:32:36 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Wed, 31 Jul 2013 10:32:36 -0400 (EDT)
Subject: [PATCH v2 26/42] USB: ohci-at91: add usb_clk for transition to
 common clk framework
In-Reply-To: <51F8C31B.1020305@overkiz.com>
Message-ID: <Pine.LNX.4.44L0.1307311030260.1546-100000@iolanthe.rowland.org>

On Wed, 31 Jul 2013, boris brezillon wrote:

> Hello Alan,
> 
> I don't know if you remember but a few days back I sent a series which
> included this patch ("ARM: at91: prepare transition to common clk 
> framework").
> 
> It was decided to move this patch out of the "prepare" series to avoid 
> backward
> compatility handling.
> 
> Things have changed a little bit.
> 
> I was asked to split the "ARM: at91: move to common clk framework" 
> series into
> several smaller series (one for each SoC).
> This means at91 will have some SoCs supporting using common clk framework
> (and thus will define the usb_clk) and other SoCs using the old at91 clk 
> implementation
> (which does not define usb_clk).
> 
> I was also requested to drop common clk framework support for non dt 
> boards, which
> means, as long as at91 keep non dt boards the at91 old clk implem will 
> remain active.
> 
> For all these reasons I will have to reintroduce the backward 
> compatibility hack.
> 
> Should I get this patch (and patch 27) out of the this series and back 
> to the "prepare" series ?

I don't care too much how the two patch series are organized, although
some of the other maintainers involved in this project might.  So long
as everything remains compatible with all the hardware variations and
bisectable at each stage, I'll be happy.

Alan Stern



From nm at ti.com  Wed Jul 31 10:36:57 2013
From: nm at ti.com (Nishanth Menon)
Date: Wed, 31 Jul 2013 09:36:57 -0500
Subject: [PATCH RFC 2/3] clk: cpufreq helper for voltage scaling
In-Reply-To: <1373247868-21444-3-git-send-email-mturquette@linaro.org>
References: <1373247868-21444-1-git-send-email-mturquette@linaro.org>
 <1373247868-21444-3-git-send-email-mturquette@linaro.org>
Message-ID: <51F92109.2060707@ti.com>

On 07/07/2013 08:44 PM, Mike Turquette wrote:
> This patch builds on "clk: notifier handler for dynamic voltage scaling"
> by adding a CPUfreq-specific helper function for registering a clock
> rate-change notifier to scale regulator voltage as a function of clock
> rate.
>
> In particular this patch creates an instance of struct
> cpufreq_frequency_table and also calculate the voltage scaling latency,
> both of which are returned to the caller for use in the CPUfreq driver.
>
> Signed-off-by: Mike Turquette <mturquette at linaro.org>
> ---
>   drivers/clk/clk-voltage-notifier.c | 71 ++++++++++++++++++++++++++++++++++++++
>   include/linux/clk.h                |  6 ++++
>   2 files changed, 77 insertions(+)

As stage 1 of the transition, I dont have any complaints, but for SoC 
level, at least on OMAP, it is not just regulator and clock, we have 
additional tweaks to do - like ABB, AVS etc.

What would you suggest as the strategy to introduce SoC specific 
handlers for voltage notifiers that can co-exist with this?

>
> diff --git a/drivers/clk/clk-voltage-notifier.c b/drivers/clk/clk-voltage-notifier.c
> index cb6b85f..8e1707f 100644
> --- a/drivers/clk/clk-voltage-notifier.c
> +++ b/drivers/clk/clk-voltage-notifier.c
> @@ -10,6 +10,7 @@
>    */
>
>   #include <linux/clk.h>
> +#include <linux/cpufreq.h>

for example - we should not depend on cpufreq in a generic clock based 
dvfs approach. we would like to allow devfreq also to transition to this.

>   #include <linux/device.h>
>   #include <linux/module.h>
>   #include <linux/notifier.h>
> @@ -133,3 +134,73 @@ void of_clk_volt_notifier_unregister(struct notifier_block *nb)
>   	kfree(vsd);
>   }
>   EXPORT_SYMBOL_GPL(of_clk_volt_notifier_unregister);
> +
> +void of_clk_cpufreq_notifier_unregister(struct notifier_block *nb,
> +		struct cpufreq_frequency_table *freq_table)
> +{
> +	struct volt_scale_data *data = to_volt_scale_data(nb);
> +	struct device *dev = data->dev;
> +
> +	opp_free_cpufreq_table(dev, &freq_table);
> +	of_clk_volt_notifier_unregister(nb);
> +}
> +EXPORT_SYMBOL_GPL(of_clk_cpufreq_notifier_unregister);
> +
> +/**
> + * of_clk_cpufreq_notifer_register - register clock notifier to scale voltage
> + * @dev: device that owns this scaling operation
> + * @np: pointer to device's DT node
> + * @clk: clock whose rate-change notifier triggers voltage scaling
> + * @supply: regulator id string
> + * @freq_table: pointer to uninitialized CPUfreq frequency scaling table
> + * @voltage_latency: worst case voltage scaling latency
> + */
> +struct notifier_block *of_clk_cpufreq_notifier_register(struct device *dev,
> +		struct device_node *np, struct clk *clk, const char *supply,
> +		struct cpufreq_frequency_table **table,
> +		unsigned int *voltage_latency)
> +{
> +	struct notifier_block *nb;
> +	struct volt_scale_data *vsd;
> +	struct opp *opp;
> +	unsigned long min, max;
> +	int ret, i;
> +
> +	nb = of_clk_volt_notifier_register(dev, np, clk, supply,
> +			voltage_latency);
> +	if (IS_ERR(nb))
> +		return nb;
> +
> +	vsd = to_volt_scale_data(nb);
> +
> +	ret = opp_init_cpufreq_table(dev, table);
> +	if (ret) {
> +		pr_err("failed to init cpufreq table: %d\n", ret);
> +		goto err_unregister;
> +	}
> +
> +	/* find the min and max voltages and compute worst-case latency */
> +	for (i = 0; table[0][i].frequency != CPUFREQ_TABLE_END; i++)
> +		;
> +
> +	rcu_read_lock();
> +	opp = opp_find_freq_exact(dev,
> +			table[0][0].frequency * 1000, true);
> +	min = opp_get_voltage(opp);
> +	opp = opp_find_freq_exact(dev,
> +			table[0][i-1].frequency * 1000, true);
> +	max = opp_get_voltage(opp);
> +	rcu_read_unlock();
> +
> +	*voltage_latency = regulator_set_voltage_time(vsd->reg, min, max);
> +	if (*voltage_latency < 0)
> +		pr_warn("%s: failed to calculate voltage latency, %d\n",
> +				__func__, ret);
> +
> +	return nb;
> +
> +err_unregister:
> +	of_clk_volt_notifier_unregister(nb);
> +	return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(of_clk_cpufreq_notifier_register);
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 85ea520..3104883 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -86,6 +86,12 @@ struct notifier_block *of_clk_volt_notifier_register(struct device *dev,
>   		struct device_node *np, struct clk *clk, const char *supply,
>   		int *voltage_latency);
>   void of_clk_volt_notifier_unregister(struct notifier_block *nb);
> +struct notifier_block *of_clk_cpufreq_notifier_register(struct device *dev,
> +		struct device_node *np, struct clk *clk, const char *supply,
> +		struct cpufreq_frequency_table **table,
> +		unsigned int *voltage_latency);
> +void of_clk_cpufreq_notifier_unregister(struct notifier_block *nb,
> +		struct cpufreq_frequency_table *freq_table);
>
>   #endif
>
>


-- 
Regards,
Nishanth Menon


From LW at KARO-electronics.de  Wed Jul 31 10:37:58 2013
From: LW at KARO-electronics.de (=?UTF-8?q?Lothar=20Wa=C3=9Fmann?=)
Date: Wed, 31 Jul 2013 16:37:58 +0200
Subject: [PATCH 8/10] ARM: dts: mxs: add 'phy_type' property to usbphy nodes
In-Reply-To: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
References: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <1375281480-25775-8-git-send-email-LW@KARO-electronics.de>


Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
---
 arch/arm/boot/dts/imx28.dtsi |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 2387d46..d9bf387 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -1044,6 +1044,7 @@
 				compatible = "fsl,imx28-usbphy", "fsl,imx23-usbphy";
 				reg = <0x8007c000 0x2000>;
 				clocks = <&clks 62>;
+				phy_type = "utmi";
 				status = "disabled";
 			};
 
@@ -1051,6 +1052,7 @@
 				compatible = "fsl,imx28-usbphy", "fsl,imx23-usbphy";
 				reg = <0x8007e000 0x2000>;
 				clocks = <&clks 63>;
+				phy_type = "utmi";
 				status = "disabled";
 			};
 		};
-- 
1.7.2.5



From LW at KARO-electronics.de  Wed Jul 31 10:37:54 2013
From: LW at KARO-electronics.de (=?UTF-8?q?Lothar=20Wa=C3=9Fmann?=)
Date: Wed, 31 Jul 2013 16:37:54 +0200
Subject: [PATCH 4/10] ARM: dts: mxs: add another set of saif0_pins (without
 MCLK)
In-Reply-To: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
References: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <1375281480-25775-4-git-send-email-LW@KARO-electronics.de>


Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
---
 arch/arm/boot/dts/imx28.dtsi |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index acfb8ac..3ec9a68 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -518,6 +518,18 @@
 					fsl,pull-up = <1>;
 				};
 
+				saif0_pins_b: saif0 at 1 {
+					reg = <1>;
+					fsl,pinmux-ids = <
+						0x3150 /* MX28_PAD_SAIF0_LRCLK__SAIF0_LRCLK */
+						0x3160 /* MX28_PAD_SAIF0_BITCLK__SAIF0_BITCLK */
+						0x3170 /* MX28_PAD_SAIF0_SDATA0__SAIF0_SDATA0 */
+					>;
+					fsl,drive-strength = <2>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <1>;
+				};
+
 				saif1_pins_a: saif1 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-- 
1.7.2.5



From LW at KARO-electronics.de  Wed Jul 31 10:37:51 2013
From: LW at KARO-electronics.de (=?UTF-8?q?Lothar=20Wa=C3=9Fmann?=)
Date: Wed, 31 Jul 2013 16:37:51 +0200
Subject: [PATCH 1/10] ARM: dts: mxs: move 'compatible' property to beginning
 of node and do some whitespace cleanups
Message-ID: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>


Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
---
 arch/arm/boot/dts/imx28.dtsi |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 47fc5ef..0360acc 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -731,9 +731,9 @@
 			};
 
 			dcp at 80028000 {
+				compatible = "fsl-dcp";
 				reg = <0x80028000 0x2000>;
 				interrupts = <52 53 54>;
-				compatible = "fsl-dcp";
 			};
 
 			pxp at 8002a000 {
@@ -815,7 +815,7 @@
 				reg = <0x8003c800 0x100>;
 				status = "disabled";
 			};
-                };
+		};
 
 		apbx at 80040000 {
 			compatible = "simple-bus";
@@ -1045,6 +1045,5 @@
 			reg = <0x800f8000 0x8000>;
 			status = "disabled";
 		};
-
 	};
 };
-- 
1.7.2.5



From LW at KARO-electronics.de  Wed Jul 31 10:37:53 2013
From: LW at KARO-electronics.de (=?UTF-8?q?Lothar=20Wa=C3=9Fmann?=)
Date: Wed, 31 Jul 2013 16:37:53 +0200
Subject: [PATCH 3/10] ARM: dts: mxs: set dcp to "disabled" by default
In-Reply-To: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
References: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <1375281480-25775-3-git-send-email-LW@KARO-electronics.de>

Reintroduce 'status = "disabled"' for the dcp node that was dropped by
commit 519d8b1a "Added support for Freescale's DCP co-processor".

Explicitly enable it in imx28-evk which is referenced in the commit
message of that commit.

Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
---
 arch/arm/boot/dts/imx28-evk.dts |    4 ++++
 arch/arm/boot/dts/imx28.dtsi    |    1 +
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index e035f46..6556197 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -360,3 +360,7 @@
 		default-brightness-level = <6>;
 	};
 };
+
+&dcp {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index d077958..acfb8ac 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -734,6 +734,7 @@
 				compatible = "fsl-dcp";
 				reg = <0x80028000 0x2000>;
 				interrupts = <52 53 54>;
+				status = "disabled";
 			};
 
 			pxp: pxp at 8002a000 {
-- 
1.7.2.5



From LW at KARO-electronics.de  Wed Jul 31 10:37:57 2013
From: LW at KARO-electronics.de (=?UTF-8?q?Lothar=20Wa=C3=9Fmann?=)
Date: Wed, 31 Jul 2013 16:37:57 +0200
Subject: [PATCH 7/10] ARM: dts: mxs: add pin config options for usbphy pins
In-Reply-To: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
References: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <1375281480-25775-7-git-send-email-LW@KARO-electronics.de>


Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
---
 arch/arm/boot/dts/imx28.dtsi |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 284166a9..2387d46 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -731,6 +731,17 @@
 					fsl,pull-up = <0>;
 				};
 
+				usbphy0_pins_c: usbphy0 at 2 {
+					reg = <2>;
+					fsl,pinmux-ids = <
+						0x0123 /* MX28_PAD_GPMI_CE2N__GPIO_0_18 - USBOTG_VBUSEN */
+						0x0133 /* MX28_PAD_GPMI_CE3N__GPIO_0_19 - USBOTH_OC */
+					>;
+					fsl,drive-strength = <2>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+
 				usbphy1_pins_a: usbphy1 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
@@ -740,6 +751,17 @@
 					fsl,voltage = <1>;
 					fsl,pull-up = <0>;
 				};
+
+				usbphy1_pins_b: usbphy1 at 1 {
+					reg = <1>;
+					fsl,pinmux-ids = <
+						0x31b3 /* MX28_PAD_SPDIF__GPIO_3_27 - USBH_VBUSEN */
+						0x4143 /* MX28_PAD_JTAG_RTCK__GPIO_4_20 - USBH_OC */
+					>;
+					fsl,drive-strength = <2>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
 			};
 
 			digctl: digctl at 8001c000 {
-- 
1.7.2.5



From LW at KARO-electronics.de  Wed Jul 31 10:38:00 2013
From: LW at KARO-electronics.de (=?UTF-8?q?Lothar=20Wa=C3=9Fmann?=)
Date: Wed, 31 Jul 2013 16:38:00 +0200
Subject: [PATCH 10/10] ARM: dts: mxs: add pinctrl header files to be able to
 use symbolic names in dts files
In-Reply-To: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
References: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <1375281480-25775-10-git-send-email-LW@KARO-electronics.de>


Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
---
 arch/arm/boot/dts/imx28-apf28.dts      |    2 +-
 arch/arm/boot/dts/imx28-apf28dev.dts   |    2 +-
 arch/arm/boot/dts/imx28-apx4devkit.dts |    2 +-
 arch/arm/boot/dts/imx28-cfa10036.dts   |    2 +-
 arch/arm/boot/dts/imx28-cfa10037.dts   |    2 +-
 arch/arm/boot/dts/imx28-cfa10049.dts   |    2 +-
 arch/arm/boot/dts/imx28-cfa10055.dts   |    2 +-
 arch/arm/boot/dts/imx28-cfa10056.dts   |    2 +-
 arch/arm/boot/dts/imx28-cfa10057.dts   |    2 +-
 arch/arm/boot/dts/imx28-cfa10058.dts   |    2 +-
 arch/arm/boot/dts/imx28-evk.dts        |    2 +-
 arch/arm/boot/dts/imx28-m28evk.dts     |    2 +-
 arch/arm/boot/dts/imx28-sps1.dts       |    2 +-
 arch/arm/boot/dts/imx28-tx28.dts       |   94 +++---
 arch/arm/boot/dts/imx28.dtsi           |  179 ++++++------
 include/dt-bindings/pinctrl/mx23.h     |  333 +++++++++++++++++++++
 include/dt-bindings/pinctrl/mx28.h     |  506 ++++++++++++++++++++++++++++++++
 include/dt-bindings/pinctrl/mxs.h      |   31 ++
 18 files changed, 1020 insertions(+), 149 deletions(-)
 create mode 100644 include/dt-bindings/pinctrl/mx23.h
 create mode 100644 include/dt-bindings/pinctrl/mx28.h
 create mode 100644 include/dt-bindings/pinctrl/mxs.h

diff --git a/arch/arm/boot/dts/imx28-apf28.dts b/arch/arm/boot/dts/imx28-apf28.dts
index 7eb0758..7198fe3 100644
--- a/arch/arm/boot/dts/imx28-apf28.dts
+++ b/arch/arm/boot/dts/imx28-apf28.dts
@@ -10,7 +10,7 @@
  */
 
 /dts-v1/;
-/include/ "imx28.dtsi"
+#include "imx28.dtsi"
 
 / {
 	model = "Armadeus Systems APF28 module";
diff --git a/arch/arm/boot/dts/imx28-apf28dev.dts b/arch/arm/boot/dts/imx28-apf28dev.dts
index b602494..a71d38a 100644
--- a/arch/arm/boot/dts/imx28-apf28dev.dts
+++ b/arch/arm/boot/dts/imx28-apf28dev.dts
@@ -10,7 +10,7 @@
  */
 
 /* APF28Dev is a docking board for the APF28 SOM */
-/include/ "imx28-apf28.dts"
+#include "imx28-apf28.dts"
 
 / {
 	model = "Armadeus Systems APF28Dev docking/development board";
diff --git a/arch/arm/boot/dts/imx28-apx4devkit.dts b/arch/arm/boot/dts/imx28-apx4devkit.dts
index 0e7fed4..11befa0 100644
--- a/arch/arm/boot/dts/imx28-apx4devkit.dts
+++ b/arch/arm/boot/dts/imx28-apx4devkit.dts
@@ -1,5 +1,5 @@
 /dts-v1/;
-/include/ "imx28.dtsi"
+#include "imx28.dtsi"
 
 / {
 	model = "Bluegiga APX4 Development Kit";
diff --git a/arch/arm/boot/dts/imx28-cfa10036.dts b/arch/arm/boot/dts/imx28-cfa10036.dts
index 1ec8c94..db3edb8 100644
--- a/arch/arm/boot/dts/imx28-cfa10036.dts
+++ b/arch/arm/boot/dts/imx28-cfa10036.dts
@@ -10,7 +10,7 @@
  */
 
 /dts-v1/;
-/include/ "imx28.dtsi"
+#include "imx28.dtsi"
 
 / {
 	model = "Crystalfontz CFA-10036 Board";
diff --git a/arch/arm/boot/dts/imx28-cfa10037.dts b/arch/arm/boot/dts/imx28-cfa10037.dts
index 182b99f..2935fa9 100644
--- a/arch/arm/boot/dts/imx28-cfa10037.dts
+++ b/arch/arm/boot/dts/imx28-cfa10037.dts
@@ -13,7 +13,7 @@
  * The CFA-10049 is an expansion board for the CFA-10036 module, thus we
  * need to include the CFA-10036 DTS.
  */
-/include/ "imx28-cfa10036.dts"
+#include "imx28-cfa10036.dts"
 
 / {
 	model = "Crystalfontz CFA-10037 Board";
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index 06e4cfa..4132bdd 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -13,7 +13,7 @@
  * The CFA-10049 is an expansion board for the CFA-10036 module, thus we
  * need to include the CFA-10036 DTS.
  */
-/include/ "imx28-cfa10036.dts"
+#include "imx28-cfa10036.dts"
 
 / {
 	model = "Crystalfontz CFA-10049 Board";
diff --git a/arch/arm/boot/dts/imx28-cfa10055.dts b/arch/arm/boot/dts/imx28-cfa10055.dts
index 171bcbe..dabc1d5 100644
--- a/arch/arm/boot/dts/imx28-cfa10055.dts
+++ b/arch/arm/boot/dts/imx28-cfa10055.dts
@@ -14,7 +14,7 @@
  * The CFA-10055 is an expansion board for the CFA-10036 module and
  * CFA-10037, thus we need to include the CFA-10037 DTS.
  */
-/include/ "imx28-cfa10037.dts"
+#include "imx28-cfa10037.dts"
 
 / {
 	model = "Crystalfontz CFA-10055 Board";
diff --git a/arch/arm/boot/dts/imx28-cfa10056.dts b/arch/arm/boot/dts/imx28-cfa10056.dts
index b45dd0e..8938744 100644
--- a/arch/arm/boot/dts/imx28-cfa10056.dts
+++ b/arch/arm/boot/dts/imx28-cfa10056.dts
@@ -13,7 +13,7 @@
  * The CFA-10055 is an expansion board for the CFA-10036 module and
  * CFA-10037, thus we need to include the CFA-10037 DTS.
  */
-/include/ "imx28-cfa10037.dts"
+#include "imx28-cfa10037.dts"
 
 / {
 	model = "Crystalfontz CFA-10056 Board";
diff --git a/arch/arm/boot/dts/imx28-cfa10057.dts b/arch/arm/boot/dts/imx28-cfa10057.dts
index 0333c05..d01eac9 100644
--- a/arch/arm/boot/dts/imx28-cfa10057.dts
+++ b/arch/arm/boot/dts/imx28-cfa10057.dts
@@ -14,7 +14,7 @@
  * The CFA-10057 is an expansion board for the CFA-10036 module, thus we
  * need to include the CFA-10036 DTS.
  */
-/include/ "imx28-cfa10036.dts"
+#include "imx28-cfa10036.dts"
 
 / {
 	model = "Crystalfontz CFA-10057 Board";
diff --git a/arch/arm/boot/dts/imx28-cfa10058.dts b/arch/arm/boot/dts/imx28-cfa10058.dts
index 64c64c5..3066188 100644
--- a/arch/arm/boot/dts/imx28-cfa10058.dts
+++ b/arch/arm/boot/dts/imx28-cfa10058.dts
@@ -14,7 +14,7 @@
  * The CFA-10058 is an expansion board for the CFA-10036 module, thus we
  * need to include the CFA-10036 DTS.
  */
-/include/ "imx28-cfa10036.dts"
+#include "imx28-cfa10036.dts"
 
 / {
 	model = "Crystalfontz CFA-10058 Board";
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 6556197..0b10f61 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -10,7 +10,7 @@
  */
 
 /dts-v1/;
-/include/ "imx28.dtsi"
+#include "imx28.dtsi"
 
 / {
 	model = "Freescale i.MX28 Evaluation Kit";
diff --git a/arch/arm/boot/dts/imx28-m28evk.dts b/arch/arm/boot/dts/imx28-m28evk.dts
index 0d322a2..b371b2a 100644
--- a/arch/arm/boot/dts/imx28-m28evk.dts
+++ b/arch/arm/boot/dts/imx28-m28evk.dts
@@ -10,7 +10,7 @@
  */
 
 /dts-v1/;
-/include/ "imx28.dtsi"
+#include "imx28.dtsi"
 
 / {
 	model = "DENX M28EVK";
diff --git a/arch/arm/boot/dts/imx28-sps1.dts b/arch/arm/boot/dts/imx28-sps1.dts
index 6c6a544..1171676 100644
--- a/arch/arm/boot/dts/imx28-sps1.dts
+++ b/arch/arm/boot/dts/imx28-sps1.dts
@@ -10,7 +10,7 @@
  */
 
 /dts-v1/;
-/include/ "imx28.dtsi"
+#include "imx28.dtsi"
 
 / {
 	model = "SchulerControl GmbH, SC SPS 1";
diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts
index 7b2e6ce..49db94e 100644
--- a/arch/arm/boot/dts/imx28-tx28.dts
+++ b/arch/arm/boot/dts/imx28-tx28.dts
@@ -499,9 +499,9 @@
 	edt_ft5x06_pins: edt-ft5x06-pins at 0 {
 		reg = <0>;
 		fsl,pinmux-ids = <
-			0x2063 /* MX28_PAD_SSP0_DATA6__GPIO_2_6	RESET */
-			0x2053 /* MX28_PAD_SSP0_DATA5__GPIO_2_5 IRQ */
-			0x4093 /* MX28_PAD_ENET0_RXD2__GPIO_4_9 WAKE */
+			MX28_PAD_SSP0_DATA6__GPIO_2_6 /* RESET */
+			MX28_PAD_SSP0_DATA5__GPIO_2_5 /* IRQ */
+			MX28_PAD_ENET0_RXD2__GPIO_4_9 /* WAKE */
 		>;
 		fsl,drive-strength = <0>;
 		fsl,voltage = <1>;
@@ -511,7 +511,7 @@
 	flexcan_xcvr_pins_a: flexcan-xcvr {
 		reg = <0>;
 		fsl,pinmux-ids = <
-			0x1003 /* MX28_PAD_LCD_D00__GPIO_1_0 */
+			MX28_PAD_LCD_D00__GPIO_1_0
 		>;
 		fsl,drive-strength = <0>;
 		fsl,voltage = <1>;
@@ -521,7 +521,7 @@
 	hog_pins_a: hog at 0 {
 		reg = <0>;
 		fsl,pinmux-ids = <
-			0x40a3 /* MX28_PAD_ENET0_RXD3__GPIO_4_10 - module LED */
+			MX28_PAD_ENET0_RXD3__GPIO_4_10 /* module LED */
 		>;
 		fsl,drive-strength = <0>;
 		fsl,voltage = <1>;
@@ -532,29 +532,29 @@
 		reg = <0>;
 		fsl,pinmux-ids = <
 			/* LCD_D00 may be used as Flexcan Transceiver Enable on STK5-V5 */
-			0x1010 /* MX28_PAD_LCD_D01__LCD_D1 */
-			0x1020 /* MX28_PAD_LCD_D02__LCD_D2 */
-			0x1030 /* MX28_PAD_LCD_D03__LCD_D3 */
-			0x1040 /* MX28_PAD_LCD_D04__LCD_D4 */
-			0x1050 /* MX28_PAD_LCD_D05__LCD_D5 */
-			0x1060 /* MX28_PAD_LCD_D06__LCD_D6 */
-			0x1070 /* MX28_PAD_LCD_D07__LCD_D7 */
-			0x1080 /* MX28_PAD_LCD_D08__LCD_D8 */
-			0x1090 /* MX28_PAD_LCD_D09__LCD_D9 */
-			0x10a0 /* MX28_PAD_LCD_D10__LCD_D10 */
-			0x10b0 /* MX28_PAD_LCD_D11__LCD_D11 */
-			0x10c0 /* MX28_PAD_LCD_D12__LCD_D12 */
-			0x10d0 /* MX28_PAD_LCD_D13__LCD_D13 */
-			0x10e0 /* MX28_PAD_LCD_D14__LCD_D14 */
-			0x10f0 /* MX28_PAD_LCD_D15__LCD_D15 */
-			0x1100 /* MX28_PAD_LCD_D16__LCD_D16 */
-			0x1110 /* MX28_PAD_LCD_D17__LCD_D17 */
-			0x1120 /* MX28_PAD_LCD_D18__LCD_D18 */
-			0x1130 /* MX28_PAD_LCD_D19__LCD_D19 */
-			0x1140 /* MX28_PAD_LCD_D20__LCD_D20 */
-			0x1150 /* MX28_PAD_LCD_D21__LCD_D21 */
-			0x1160 /* MX28_PAD_LCD_D22__LCD_D22 */
-			0x1170 /* MX28_PAD_LCD_D23__LCD_D23 */
+			MX28_PAD_LCD_D01__LCD_D1
+			MX28_PAD_LCD_D02__LCD_D2
+			MX28_PAD_LCD_D03__LCD_D3
+			MX28_PAD_LCD_D04__LCD_D4
+			MX28_PAD_LCD_D05__LCD_D5
+			MX28_PAD_LCD_D06__LCD_D6
+			MX28_PAD_LCD_D07__LCD_D7
+			MX28_PAD_LCD_D08__LCD_D8
+			MX28_PAD_LCD_D09__LCD_D9
+			MX28_PAD_LCD_D10__LCD_D10
+			MX28_PAD_LCD_D11__LCD_D11
+			MX28_PAD_LCD_D12__LCD_D12
+			MX28_PAD_LCD_D13__LCD_D13
+			MX28_PAD_LCD_D14__LCD_D14
+			MX28_PAD_LCD_D15__LCD_D15
+			MX28_PAD_LCD_D16__LCD_D16
+			MX28_PAD_LCD_D17__LCD_D17
+			MX28_PAD_LCD_D18__LCD_D18
+			MX28_PAD_LCD_D19__LCD_D19
+			MX28_PAD_LCD_D20__LCD_D20
+			MX28_PAD_LCD_D21__LCD_D21
+			MX28_PAD_LCD_D22__LCD_D22
+			MX28_PAD_LCD_D23__LCD_D23
 		>;
 		fsl,drive-strength = <0>;
 		fsl,voltage = <1>;
@@ -564,8 +564,8 @@
 	lcdif_ctrl_pins_a: lcdif-ctrl at 0 {
 		reg = <0>;
 		fsl,pinmux-ids = <
-			0x11f3	/* MX28_PAD_LCD_ENABLE__GPIO_1_31 - Enable */
-			0x31e3	/* MX28_PAD_LCD_RESET__GPIO_3_30 - Reset */
+			MX28_PAD_LCD_ENABLE__GPIO_1_31 /* Enable */
+			MX28_PAD_LCD_RESET__GPIO_3_30  /* Reset */
 		>;
 		fsl,drive-strength = <0>;
 		fsl,voltage = <1>;
@@ -575,15 +575,15 @@
 	mac0_pins_gpio: mac0-gpio-mode at 0 {
 		reg = <0>;
 		fsl,pinmux-ids = <
-			0x4003 /* MX28_PAD_ENET0_MDC__GPIO_4_0 */
-			0x4013 /* MX28_PAD_ENET0_MDIO__GPIO_4_1 */
-			0x4023 /* MX28_PAD_ENET0_RX_EN__GPIO_4_2 */
-			0x4033 /* MX28_PAD_ENET0_RXD0__GPIO_4_3 */
-			0x4043 /* MX28_PAD_ENET0_RXD1__GPIO_4_4 */
-			0x4063 /* MX28_PAD_ENET0_TX_EN__GPIO_4_6 */
-			0x4073 /* MX28_PAD_ENET0_TXD0__GPIO_4_7 */
-			0x4083 /* MX28_PAD_ENET0_TXD1__GPIO_4_8 */
-			0x4103 /* MX28_PAD_ENET_CLK__GPIO_4_16 */
+			MX28_PAD_ENET0_MDC__GPIO_4_0
+			MX28_PAD_ENET0_MDIO__GPIO_4_1
+			MX28_PAD_ENET0_RX_EN__GPIO_4_2
+			MX28_PAD_ENET0_RXD0__GPIO_4_3
+			MX28_PAD_ENET0_RXD1__GPIO_4_4
+			MX28_PAD_ENET0_TX_EN__GPIO_4_6
+			MX28_PAD_ENET0_TXD0__GPIO_4_7
+			MX28_PAD_ENET0_TXD1__GPIO_4_8
+			MX28_PAD_ENET_CLK__GPIO_4_16
 		>;
 		fsl,drive-strength = <0>;
 		fsl,voltage = <1>;
@@ -593,7 +593,7 @@
 	pca9554_pins: pca9554-pins at 0 {
 		reg = <0>;
 		fsl,pinmux-ids = <
-			0x31c3 /* MX28_PAD_PWM3__GPIO_3_28 IRQ */
+			MX28_PAD_PWM3__GPIO_3_28
 		>;
 		fsl,drive-strength = <0>;
 		fsl,voltage = <1>;
@@ -603,12 +603,12 @@
 	spi_pins_gpio: spi at 0 {
 		reg = <0>;
 		fsl,pinmux-ids = <
-			0x3083	/* MX28_PAD_AUART2_RX__GPIO_3_8 SS0 */
-			0x3093	/* MX28_PAD_AUART2_TX__GPIO_3_9 SS1 */
-			0x2183	/* MX28_PAD_SSP3_SCK__GPIO_2_24 SCK */
-			0x2193	/* MX28_PAD_SSP3_MOSI__GPIO_2_25 MOSI */
-			0x21A3	/* MX28_PAD_SSP3_MISO__GPIO_2_26 MISO */
-			0x21B3	/* MX28_PAD_SSP3_SS0__GPIO_2_27 SS2 */
+			MX28_PAD_AUART2_RX__GPIO_3_8  /* SS0 */
+			MX28_PAD_AUART2_TX__GPIO_3_9  /* SS1 */
+			MX28_PAD_SSP3_SCK__GPIO_2_24  /* SCK */
+			MX28_PAD_SSP3_MOSI__GPIO_2_25 /* MOSI */
+			MX28_PAD_SSP3_MISO__GPIO_2_26 /* MISO */
+			MX28_PAD_SSP3_SS0__GPIO_2_27  /* SS2 */
 		>;
 		fsl,drive-strength = <1>;
 		fsl,voltage = <1>;
@@ -618,7 +618,7 @@
 	tsc2007_pins: tsc2007-pins at 0 {
 		reg = <0>;
 		fsl,pinmux-ids = <
-			0x3143 /* MX28_PAD_SAIF0_MCLK__GPIO_3_20 - TSC2007 IRQ */
+			MX28_PAD_SAIF0_MCLK__GPIO_3_20 /* TSC2007 IRQ */
 		>;
 		fsl,drive-strength = <0>;
 		fsl,voltage = <1>;
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index d9bf387..89c5e08 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -9,7 +9,8 @@
  * http://www.gnu.org/copyleft/gpl.html
  */
 
-/include/ "skeleton.dtsi"
+#include "skeleton.dtsi"
+#include <dt-bindings/pinctrl/mx28.h>
 
 / {
 	interrupt-parent = <&icoll>;
@@ -207,8 +208,8 @@
 				duart_pins_a: duart at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-						0x3102 /* MX28_PAD_PWM0__DUART_RX */
-						0x3112 /* MX28_PAD_PWM1__DUART_TX */
+						MX28_PAD_PWM0__DUART_RX
+						MX28_PAD_PWM1__DUART_TX
 					>;
 					fsl,drive-strength = <0>;
 					fsl,voltage = <1>;
@@ -218,8 +219,8 @@
 				duart_pins_b: duart at 1 {
 					reg = <1>;
 					fsl,pinmux-ids = <
-						0x3022 /* MX28_PAD_AUART0_CTS__DUART_RX */
-						0x3032 /* MX28_PAD_AUART0_RTS__DUART_TX */
+						MX28_PAD_AUART0_CTS__DUART_RX
+						MX28_PAD_AUART0_RTS__DUART_TX
 					>;
 					fsl,drive-strength = <0>;
 					fsl,voltage = <1>;
@@ -229,10 +230,10 @@
 				duart_4pins_a: duart-4pins at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-						0x3022 /* MX28_PAD_AUART0_CTS__DUART_RX */
-						0x3032 /* MX28_PAD_AUART0_RTS__DUART_TX */
-						0x3002 /* MX28_PAD_AUART0_RX__DUART_CTS */
-						0x3012 /* MX28_PAD_AUART0_TX__DUART_RTS */
+						MX28_PAD_AUART0_CTS__DUART_RX
+						MX28_PAD_AUART0_RTS__DUART_TX
+						MX28_PAD_AUART0_RX__DUART_CTS
+						MX28_PAD_AUART0_TX__DUART_RTS
 					>;
 					fsl,drive-strength = <0>;
 					fsl,voltage = <1>;
@@ -242,21 +243,21 @@
 				gpmi_pins_a: gpmi-nand at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-						0x0000 /* MX28_PAD_GPMI_D00__GPMI_D0 */
-						0x0010 /* MX28_PAD_GPMI_D01__GPMI_D1 */
-						0x0020 /* MX28_PAD_GPMI_D02__GPMI_D2 */
-						0x0030 /* MX28_PAD_GPMI_D03__GPMI_D3 */
-						0x0040 /* MX28_PAD_GPMI_D04__GPMI_D4 */
-						0x0050 /* MX28_PAD_GPMI_D05__GPMI_D5 */
-						0x0060 /* MX28_PAD_GPMI_D06__GPMI_D6 */
-						0x0070 /* MX28_PAD_GPMI_D07__GPMI_D7 */
-						0x0100 /* MX28_PAD_GPMI_CE0N__GPMI_CE0N */
-						0x0140 /* MX28_PAD_GPMI_RDY0__GPMI_READY0 */
-						0x0180 /* MX28_PAD_GPMI_RDN__GPMI_RDN */
-						0x0190 /* MX28_PAD_GPMI_WRN__GPMI_WRN */
-						0x01a0 /* MX28_PAD_GPMI_ALE__GPMI_ALE */
-						0x01b0 /* MX28_PAD_GPMI_CLE__GPMI_CLE */
-						0x01c0 /* MX28_PAD_GPMI_RESETN__GPMI_RESETN */
+						MX28_PAD_GPMI_D00__GPMI_D0
+						MX28_PAD_GPMI_D01__GPMI_D1
+						MX28_PAD_GPMI_D02__GPMI_D2
+						MX28_PAD_GPMI_D03__GPMI_D3
+						MX28_PAD_GPMI_D04__GPMI_D4
+						MX28_PAD_GPMI_D05__GPMI_D5
+						MX28_PAD_GPMI_D06__GPMI_D6
+						MX28_PAD_GPMI_D07__GPMI_D7
+						MX28_PAD_GPMI_CE0N__GPMI_CE0N
+						MX28_PAD_GPMI_RDY0__GPMI_READY0
+						MX28_PAD_GPMI_RDN__GPMI_RDN
+						MX28_PAD_GPMI_WRN__GPMI_WRN
+						MX28_PAD_GPMI_ALE__GPMI_ALE
+						MX28_PAD_GPMI_CLE__GPMI_CLE
+						MX28_PAD_GPMI_RESETN__GPMI_RESETN
 					>;
 					fsl,drive-strength = <0>;
 					fsl,voltage = <1>;
@@ -593,30 +594,30 @@
 				lcdif_24bit_pins_a: lcdif-24bit at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-						0x1000 /* MX28_PAD_LCD_D00__LCD_D0 */
-						0x1010 /* MX28_PAD_LCD_D01__LCD_D1 */
-						0x1020 /* MX28_PAD_LCD_D02__LCD_D2 */
-						0x1030 /* MX28_PAD_LCD_D03__LCD_D3 */
-						0x1040 /* MX28_PAD_LCD_D04__LCD_D4 */
-						0x1050 /* MX28_PAD_LCD_D05__LCD_D5 */
-						0x1060 /* MX28_PAD_LCD_D06__LCD_D6 */
-						0x1070 /* MX28_PAD_LCD_D07__LCD_D7 */
-						0x1080 /* MX28_PAD_LCD_D08__LCD_D8 */
-						0x1090 /* MX28_PAD_LCD_D09__LCD_D9 */
-						0x10a0 /* MX28_PAD_LCD_D10__LCD_D10 */
-						0x10b0 /* MX28_PAD_LCD_D11__LCD_D11 */
-						0x10c0 /* MX28_PAD_LCD_D12__LCD_D12 */
-						0x10d0 /* MX28_PAD_LCD_D13__LCD_D13 */
-						0x10e0 /* MX28_PAD_LCD_D14__LCD_D14 */
-						0x10f0 /* MX28_PAD_LCD_D15__LCD_D15 */
-						0x1100 /* MX28_PAD_LCD_D16__LCD_D16 */
-						0x1110 /* MX28_PAD_LCD_D17__LCD_D17 */
-						0x1120 /* MX28_PAD_LCD_D18__LCD_D18 */
-						0x1130 /* MX28_PAD_LCD_D19__LCD_D19 */
-						0x1140 /* MX28_PAD_LCD_D20__LCD_D20 */
-						0x1150 /* MX28_PAD_LCD_D21__LCD_D21 */
-						0x1160 /* MX28_PAD_LCD_D22__LCD_D22 */
-						0x1170 /* MX28_PAD_LCD_D23__LCD_D23 */
+						MX28_PAD_LCD_D00__LCD_D0
+						MX28_PAD_LCD_D01__LCD_D1
+						MX28_PAD_LCD_D02__LCD_D2
+						MX28_PAD_LCD_D03__LCD_D3
+						MX28_PAD_LCD_D04__LCD_D4
+						MX28_PAD_LCD_D05__LCD_D5
+						MX28_PAD_LCD_D06__LCD_D6
+						MX28_PAD_LCD_D07__LCD_D7
+						MX28_PAD_LCD_D08__LCD_D8
+						MX28_PAD_LCD_D09__LCD_D9
+						MX28_PAD_LCD_D10__LCD_D10
+						MX28_PAD_LCD_D11__LCD_D11
+						MX28_PAD_LCD_D12__LCD_D12
+						MX28_PAD_LCD_D13__LCD_D13
+						MX28_PAD_LCD_D14__LCD_D14
+						MX28_PAD_LCD_D15__LCD_D15
+						MX28_PAD_LCD_D16__LCD_D16
+						MX28_PAD_LCD_D17__LCD_D17
+						MX28_PAD_LCD_D18__LCD_D18
+						MX28_PAD_LCD_D19__LCD_D19
+						MX28_PAD_LCD_D20__LCD_D20
+						MX28_PAD_LCD_D21__LCD_D21
+						MX28_PAD_LCD_D22__LCD_D22
+						MX28_PAD_LCD_D23__LCD_D23
 					>;
 					fsl,drive-strength = <0>;
 					fsl,voltage = <1>;
@@ -626,22 +627,22 @@
 				lcdif_16bit_pins_a: lcdif-16bit at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-						0x1000 /* MX28_PAD_LCD_D00__LCD_D0 */
-						0x1010 /* MX28_PAD_LCD_D01__LCD_D1 */
-						0x1020 /* MX28_PAD_LCD_D02__LCD_D2 */
-						0x1030 /* MX28_PAD_LCD_D03__LCD_D3 */
-						0x1040 /* MX28_PAD_LCD_D04__LCD_D4 */
-						0x1050 /* MX28_PAD_LCD_D05__LCD_D5 */
-						0x1060 /* MX28_PAD_LCD_D06__LCD_D6 */
-						0x1070 /* MX28_PAD_LCD_D07__LCD_D7 */
-						0x1080 /* MX28_PAD_LCD_D08__LCD_D8 */
-						0x1090 /* MX28_PAD_LCD_D09__LCD_D9 */
-						0x10a0 /* MX28_PAD_LCD_D10__LCD_D10 */
-						0x10b0 /* MX28_PAD_LCD_D11__LCD_D11 */
-						0x10c0 /* MX28_PAD_LCD_D12__LCD_D12 */
-						0x10d0 /* MX28_PAD_LCD_D13__LCD_D13 */
-						0x10e0 /* MX28_PAD_LCD_D14__LCD_D14 */
-						0x10f0 /* MX28_PAD_LCD_D15__LCD_D15 */
+						MX28_PAD_LCD_D00__LCD_D0
+						MX28_PAD_LCD_D01__LCD_D1
+						MX28_PAD_LCD_D02__LCD_D2
+						MX28_PAD_LCD_D03__LCD_D3
+						MX28_PAD_LCD_D04__LCD_D4
+						MX28_PAD_LCD_D05__LCD_D5
+						MX28_PAD_LCD_D06__LCD_D6
+						MX28_PAD_LCD_D07__LCD_D7
+						MX28_PAD_LCD_D08__LCD_D8
+						MX28_PAD_LCD_D09__LCD_D9
+						MX28_PAD_LCD_D10__LCD_D10
+						MX28_PAD_LCD_D11__LCD_D11
+						MX28_PAD_LCD_D12__LCD_D12
+						MX28_PAD_LCD_D13__LCD_D13
+						MX28_PAD_LCD_D14__LCD_D14
+						MX28_PAD_LCD_D15__LCD_D15
 					>;
 					fsl,drive-strength = <0>;
 					fsl,voltage = <1>;
@@ -651,10 +652,10 @@
 				lcdif_sync_pins_a: lcdif-sync at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-						0x11a1 /* MX28_PAD_LCD_RS__LCD_DOTCLK */
-						0x11b1 /* MX28_PAD_LCD_CS__LCD_ENABLE */
-						0x1181 /* MX28_PAD_LCD_RD_E__LCD_VSYNC */
-						0x1191 /* MX28_PAD_LCD_WR_RWN__LCD_HSYNC */
+						MX28_PAD_LCD_RS__LCD_DOTCLK
+						MX28_PAD_LCD_CS__LCD_ENABLE
+						MX28_PAD_LCD_RD_E__LCD_VSYNC
+						MX28_PAD_LCD_WR_RWN__LCD_HSYNC
 					>;
 					fsl,drive-strength = <0>;
 					fsl,voltage = <1>;
@@ -664,8 +665,8 @@
 				can0_pins_a: can0 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-						0x0161 /* MX28_PAD_GPMI_RDY2__CAN0_TX */
-						0x0171 /* MX28_PAD_GPMI_RDY3__CAN0_RX */
+						MX28_PAD_GPMI_RDY2__CAN0_TX
+						MX28_PAD_GPMI_RDY3__CAN0_RX
 					>;
 					fsl,drive-strength = <0>;
 					fsl,voltage = <1>;
@@ -675,8 +676,8 @@
 				can1_pins_a: can1 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-						0x0121 /* MX28_PAD_GPMI_CE2N__CAN1_TX */
-						0x0131 /* MX28_PAD_GPMI_CE3N__CAN1_RX */
+						MX28_PAD_GPMI_CE2N__CAN1_TX
+						MX28_PAD_GPMI_CE3N__CAN1_RX
 					>;
 					fsl,drive-strength = <0>;
 					fsl,voltage = <1>;
@@ -686,10 +687,10 @@
 				spi2_pins_a: spi2 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-						0x2100 /* MX28_PAD_SSP2_SCK__SSP2_SCK */
-						0x2110 /* MX28_PAD_SSP2_MOSI__SSP2_CMD */
-						0x2120 /* MX28_PAD_SSP2_MISO__SSP2_D0 */
-						0x2130 /* MX28_PAD_SSP2_SS0__SSP2_D3 */
+						MX28_PAD_SSP2_SCK__SSP2_SCK
+						MX28_PAD_SSP2_MOSI__SSP2_CMD
+						MX28_PAD_SSP2_MISO__SSP2_D0
+						MX28_PAD_SSP2_SS0__SSP2_D3
 					>;
 					fsl,drive-strength = <1>;
 					fsl,voltage = <1>;
@@ -699,12 +700,12 @@
 				spi3_pins_a: spi3 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-						0x3082 /* MX28_PAD_AUART2_RX__SSP3_D4 */
-						0x3092 /* MX28_PAD_AUART2_TX__SSP3_D5 */
-						0x2180 /* MX28_PAD_SSP3_SCK__SSP3_SCK */
-						0x2190 /* MX28_PAD_SSP3_MOSI__SSP3_CMD */
-						0x21A0 /* MX28_PAD_SSP3_MISO__SSP3_D0 */
-						0x21B0 /* MX28_PAD_SSP3_SS0__SSP3_D3 */
+						MX28_PAD_AUART2_RX__SSP3_D4
+						MX28_PAD_AUART2_TX__SSP3_D5
+						MX28_PAD_SSP3_SCK__SSP3_SCK
+						MX28_PAD_SSP3_MOSI__SSP3_CMD
+						MX28_PAD_SSP3_MISO__SSP3_D0
+						MX28_PAD_SSP3_SS0__SSP3_D3
 					>;
 					fsl,drive-strength = <1>;
 					fsl,voltage = <1>;
@@ -714,7 +715,7 @@
 				usbphy0_pins_a: usbphy0 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-						0x2152 /* MX28_PAD_SSP2_SS2__USB0_OVERCURRENT */
+						MX28_PAD_SSP2_SS2__USB0_OVERCURRENT
 					>;
 					fsl,drive-strength = <2>;
 					fsl,voltage = <1>;
@@ -724,7 +725,7 @@
 				usbphy0_pins_b: usbphy0 at 1 {
 					reg = <1>;
 					fsl,pinmux-ids = <
-						0x3061 /* MX28_PAD_AUART1_CTS__USB0_OVERCURRENT */
+						MX28_PAD_AUART1_CTS__USB0_OVERCURRENT
 					>;
 					fsl,drive-strength = <2>;
 					fsl,voltage = <1>;
@@ -734,8 +735,8 @@
 				usbphy0_pins_c: usbphy0 at 2 {
 					reg = <2>;
 					fsl,pinmux-ids = <
-						0x0123 /* MX28_PAD_GPMI_CE2N__GPIO_0_18 - USBOTG_VBUSEN */
-						0x0133 /* MX28_PAD_GPMI_CE3N__GPIO_0_19 - USBOTH_OC */
+						MX28_PAD_GPMI_CE2N__GPIO_0_18 /* USBOTG_VBUSEN */
+						MX28_PAD_GPMI_CE3N__GPIO_0_19 /* USBOTH_OC */
 					>;
 					fsl,drive-strength = <2>;
 					fsl,voltage = <1>;
@@ -745,7 +746,7 @@
 				usbphy1_pins_a: usbphy1 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-						0x2142 /* MX28_PAD_SSP2_SS1__USB1_OVERCURRENT */
+						MX28_PAD_SSP2_SS1__USB1_OVERCURRENT
 					>;
 					fsl,drive-strength = <2>;
 					fsl,voltage = <1>;
@@ -755,8 +756,8 @@
 				usbphy1_pins_b: usbphy1 at 1 {
 					reg = <1>;
 					fsl,pinmux-ids = <
-						0x31b3 /* MX28_PAD_SPDIF__GPIO_3_27 - USBH_VBUSEN */
-						0x4143 /* MX28_PAD_JTAG_RTCK__GPIO_4_20 - USBH_OC */
+						MX28_PAD_SPDIF__GPIO_3_27 /* USBH_VBUSEN */
+						MX28_PAD_JTAG_RTCK__GPIO_4_20 /* USBH_OC */
 					>;
 					fsl,drive-strength = <2>;
 					fsl,voltage = <1>;
diff --git a/include/dt-bindings/pinctrl/mx23.h b/include/dt-bindings/pinctrl/mx23.h
new file mode 100644
index 0000000..a31c969
--- /dev/null
+++ b/include/dt-bindings/pinctrl/mx23.h
@@ -0,0 +1,333 @@
+/*
+ * Header providing constants for i.MX23 pinctrl bindings.
+ *
+ * Copyright (C) 2013 Lothar Wa?mann <LW at KARO-electronics.de>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#ifndef __DT_BINDINGS_MX23_PINCTRL_H__
+#define __DT_BINDINGS_MX23_PINCTRL_H__
+
+#include "mxs.h"
+
+#define MX23_PAD_GPMI_D00__GPMI_D00			0x0000
+#define MX23_PAD_GPMI_D01__GPMI_D01			0x0010
+#define MX23_PAD_GPMI_D02__GPMI_D02			0x0020
+#define MX23_PAD_GPMI_D03__GPMI_D03			0x0030
+#define MX23_PAD_GPMI_D04__GPMI_D04			0x0040
+#define MX23_PAD_GPMI_D05__GPMI_D05			0x0050
+#define MX23_PAD_GPMI_D06__GPMI_D06			0x0060
+#define MX23_PAD_GPMI_D07__GPMI_D07			0x0070
+#define MX23_PAD_GPMI_D08__GPMI_D08			0x0080
+#define MX23_PAD_GPMI_D09__GPMI_D09			0x0090
+#define MX23_PAD_GPMI_D10__GPMI_D10			0x00a0
+#define MX23_PAD_GPMI_D11__GPMI_D11			0x00b0
+#define MX23_PAD_GPMI_D12__GPMI_D12			0x00c0
+#define MX23_PAD_GPMI_D13__GPMI_D13			0x00d0
+#define MX23_PAD_GPMI_D14__GPMI_D14			0x00e0
+#define MX23_PAD_GPMI_D15__GPMI_D15			0x00f0
+#define MX23_PAD_GPMI_CLE__GPMI_CLE			0x0100
+#define MX23_PAD_GPMI_ALE__GPMI_ALE			0x0110
+#define MX23_PAD_GPMI_CE2N__GPMI_CE2N			0x0120
+#define MX23_PAD_GPMI_RDY0__GPMI_RDY0			0x0130
+#define MX23_PAD_GPMI_RDY1__GPMI_RDY1			0x0140
+#define MX23_PAD_GPMI_RDY2__GPMI_RDY2			0x0150
+#define MX23_PAD_GPMI_RDY3__GPMI_RDY3			0x0160
+#define MX23_PAD_GPMI_WPN__GPMI_WPN			0x0170
+#define MX23_PAD_GPMI_WRN__GPMI_WRN			0x0180
+#define MX23_PAD_GPMI_RDN__GPMI_RDN			0x0190
+#define MX23_PAD_AUART1_CTS__AUART1_CTS			0x01a0
+#define MX23_PAD_AUART1_RTS__AUART1_RTS			0x01b0
+#define MX23_PAD_AUART1_RX__AUART1_RX			0x01c0
+#define MX23_PAD_AUART1_TX__AUART1_TX			0x01d0
+#define MX23_PAD_I2C_SCL__I2C_SCL			0x01e0
+#define MX23_PAD_I2C_SDA__I2C_SDA			0x01f0
+#define MX23_PAD_LCD_D00__LCD_D00			0x1000
+#define MX23_PAD_LCD_D01__LCD_D01			0x1010
+#define MX23_PAD_LCD_D02__LCD_D02			0x1020
+#define MX23_PAD_LCD_D03__LCD_D03			0x1030
+#define MX23_PAD_LCD_D04__LCD_D04			0x1040
+#define MX23_PAD_LCD_D05__LCD_D05			0x1050
+#define MX23_PAD_LCD_D06__LCD_D06			0x1060
+#define MX23_PAD_LCD_D07__LCD_D07			0x1070
+#define MX23_PAD_LCD_D08__LCD_D08			0x1080
+#define MX23_PAD_LCD_D09__LCD_D09			0x1090
+#define MX23_PAD_LCD_D10__LCD_D10			0x10a0
+#define MX23_PAD_LCD_D11__LCD_D11			0x10b0
+#define MX23_PAD_LCD_D12__LCD_D12			0x10c0
+#define MX23_PAD_LCD_D13__LCD_D13			0x10d0
+#define MX23_PAD_LCD_D14__LCD_D14			0x10e0
+#define MX23_PAD_LCD_D15__LCD_D15			0x10f0
+#define MX23_PAD_LCD_D16__LCD_D16			0x1100
+#define MX23_PAD_LCD_D17__LCD_D17			0x1110
+#define MX23_PAD_LCD_RESET__LCD_RESET			0x1120
+#define MX23_PAD_LCD_RS__LCD_RS				0x1130
+#define MX23_PAD_LCD_WR__LCD_WR				0x1140
+#define MX23_PAD_LCD_CS__LCD_CS				0x1150
+#define MX23_PAD_LCD_DOTCK__LCD_DOTCK			0x1160
+#define MX23_PAD_LCD_ENABLE__LCD_ENABLE			0x1170
+#define MX23_PAD_LCD_HSYNC__LCD_HSYNC			0x1180
+#define MX23_PAD_LCD_VSYNC__LCD_VSYNC			0x1190
+#define MX23_PAD_PWM0__PWM0				0x11a0
+#define MX23_PAD_PWM1__PWM1				0x11b0
+#define MX23_PAD_PWM2__PWM2				0x11c0
+#define MX23_PAD_PWM3__PWM3				0x11d0
+#define MX23_PAD_PWM4__PWM4				0x11e0
+#define MX23_PAD_SSP1_CMD__SSP1_CMD			0x2000
+#define MX23_PAD_SSP1_DETECT__SSP1_DETECT		0x2010
+#define MX23_PAD_SSP1_DATA0__SSP1_DATA0			0x2020
+#define MX23_PAD_SSP1_DATA1__SSP1_DATA1			0x2030
+#define MX23_PAD_SSP1_DATA2__SSP1_DATA2			0x2040
+#define MX23_PAD_SSP1_DATA3__SSP1_DATA3			0x2050
+#define MX23_PAD_SSP1_SCK__SSP1_SCK			0x2060
+#define MX23_PAD_ROTARYA__ROTARYA			0x2070
+#define MX23_PAD_ROTARYB__ROTARYB			0x2080
+#define MX23_PAD_EMI_A00__EMI_A00			0x2090
+#define MX23_PAD_EMI_A01__EMI_A01			0x20a0
+#define MX23_PAD_EMI_A02__EMI_A02			0x20b0
+#define MX23_PAD_EMI_A03__EMI_A03			0x20c0
+#define MX23_PAD_EMI_A04__EMI_A04			0x20d0
+#define MX23_PAD_EMI_A05__EMI_A05			0x20e0
+#define MX23_PAD_EMI_A06__EMI_A06			0x20f0
+#define MX23_PAD_EMI_A07__EMI_A07			0x2100
+#define MX23_PAD_EMI_A08__EMI_A08			0x2110
+#define MX23_PAD_EMI_A09__EMI_A09			0x2120
+#define MX23_PAD_EMI_A10__EMI_A10			0x2130
+#define MX23_PAD_EMI_A11__EMI_A11			0x2140
+#define MX23_PAD_EMI_A12__EMI_A12			0x2150
+#define MX23_PAD_EMI_BA0__EMI_BA0			0x2160
+#define MX23_PAD_EMI_BA1__EMI_BA1			0x2170
+#define MX23_PAD_EMI_CASN__EMI_CASN			0x2180
+#define MX23_PAD_EMI_CE0N__EMI_CE0N			0x2190
+#define MX23_PAD_EMI_CE1N__EMI_CE1N			0x21a0
+#define MX23_PAD_GPMI_CE1N__GPMI_CE1N			0x21b0
+#define MX23_PAD_GPMI_CE0N__GPMI_CE0N			0x21c0
+#define MX23_PAD_EMI_CKE__EMI_CKE			0x21d0
+#define MX23_PAD_EMI_RASN__EMI_RASN			0x21e0
+#define MX23_PAD_EMI_WEN__EMI_WEN			0x21f0
+#define MX23_PAD_EMI_D00__EMI_D00			0x3000
+#define MX23_PAD_EMI_D01__EMI_D01			0x3010
+#define MX23_PAD_EMI_D02__EMI_D02			0x3020
+#define MX23_PAD_EMI_D03__EMI_D03			0x3030
+#define MX23_PAD_EMI_D04__EMI_D04			0x3040
+#define MX23_PAD_EMI_D05__EMI_D05			0x3050
+#define MX23_PAD_EMI_D06__EMI_D06			0x3060
+#define MX23_PAD_EMI_D07__EMI_D07			0x3070
+#define MX23_PAD_EMI_D08__EMI_D08			0x3080
+#define MX23_PAD_EMI_D09__EMI_D09			0x3090
+#define MX23_PAD_EMI_D10__EMI_D10			0x30a0
+#define MX23_PAD_EMI_D11__EMI_D11			0x30b0
+#define MX23_PAD_EMI_D12__EMI_D12			0x30c0
+#define MX23_PAD_EMI_D13__EMI_D13			0x30d0
+#define MX23_PAD_EMI_D14__EMI_D14			0x30e0
+#define MX23_PAD_EMI_D15__EMI_D15			0x30f0
+#define MX23_PAD_EMI_DQM0__EMI_DQM0			0x3100
+#define MX23_PAD_EMI_DQM1__EMI_DQM1			0x3110
+#define MX23_PAD_EMI_DQS0__EMI_DQS0			0x3120
+#define MX23_PAD_EMI_DQS1__EMI_DQS1			0x3130
+#define MX23_PAD_EMI_CLK__EMI_CLK			0x3140
+#define MX23_PAD_EMI_CLKN__EMI_CLKN			0x3150
+#define MX23_PAD_GPMI_D00__LCD_D8			0x0001
+#define MX23_PAD_GPMI_D01__LCD_D9			0x0011
+#define MX23_PAD_GPMI_D02__LCD_D10			0x0021
+#define MX23_PAD_GPMI_D03__LCD_D11			0x0031
+#define MX23_PAD_GPMI_D04__LCD_D12			0x0041
+#define MX23_PAD_GPMI_D05__LCD_D13			0x0051
+#define MX23_PAD_GPMI_D06__LCD_D14			0x0061
+#define MX23_PAD_GPMI_D07__LCD_D15			0x0071
+#define MX23_PAD_GPMI_D08__LCD_D18			0x0081
+#define MX23_PAD_GPMI_D09__LCD_D19			0x0091
+#define MX23_PAD_GPMI_D10__LCD_D20			0x00a1
+#define MX23_PAD_GPMI_D11__LCD_D21			0x00b1
+#define MX23_PAD_GPMI_D12__LCD_D22			0x00c1
+#define MX23_PAD_GPMI_D13__LCD_D23			0x00d1
+#define MX23_PAD_GPMI_D14__AUART2_RX			0x00e1
+#define MX23_PAD_GPMI_D15__AUART2_TX			0x00f1
+#define MX23_PAD_GPMI_CLE__LCD_D16			0x0101
+#define MX23_PAD_GPMI_ALE__LCD_D17			0x0111
+#define MX23_PAD_GPMI_CE2N__ATA_A2			0x0121
+#define MX23_PAD_AUART1_RTS__IR_CLK			0x01b1
+#define MX23_PAD_AUART1_RX__IR_RX			0x01c1
+#define MX23_PAD_AUART1_TX__IR_TX			0x01d1
+#define MX23_PAD_I2C_SCL__GPMI_RDY2			0x01e1
+#define MX23_PAD_I2C_SDA__GPMI_CE2N			0x01f1
+#define MX23_PAD_LCD_D00__ETM_DA8			0x1001
+#define MX23_PAD_LCD_D01__ETM_DA9			0x1011
+#define MX23_PAD_LCD_D02__ETM_DA10			0x1021
+#define MX23_PAD_LCD_D03__ETM_DA11			0x1031
+#define MX23_PAD_LCD_D04__ETM_DA12			0x1041
+#define MX23_PAD_LCD_D05__ETM_DA13			0x1051
+#define MX23_PAD_LCD_D06__ETM_DA14			0x1061
+#define MX23_PAD_LCD_D07__ETM_DA15			0x1071
+#define MX23_PAD_LCD_D08__ETM_DA0			0x1081
+#define MX23_PAD_LCD_D09__ETM_DA1			0x1091
+#define MX23_PAD_LCD_D10__ETM_DA2			0x10a1
+#define MX23_PAD_LCD_D11__ETM_DA3			0x10b1
+#define MX23_PAD_LCD_D12__ETM_DA4			0x10c1
+#define MX23_PAD_LCD_D13__ETM_DA5			0x10d1
+#define MX23_PAD_LCD_D14__ETM_DA6			0x10e1
+#define MX23_PAD_LCD_D15__ETM_DA7			0x10f1
+#define MX23_PAD_LCD_RESET__ETM_TCTL			0x1121
+#define MX23_PAD_LCD_RS__ETM_TCLK			0x1131
+#define MX23_PAD_LCD_DOTCK__GPMI_RDY3			0x1161
+#define MX23_PAD_LCD_ENABLE__I2C_SCL			0x1171
+#define MX23_PAD_LCD_HSYNC__I2C_SDA			0x1181
+#define MX23_PAD_LCD_VSYNC__LCD_BUSY			0x1191
+#define MX23_PAD_PWM0__ROTARYA				0x11a1
+#define MX23_PAD_PWM1__ROTARYB				0x11b1
+#define MX23_PAD_PWM2__GPMI_RDY3			0x11c1
+#define MX23_PAD_PWM3__ETM_TCTL				0x11d1
+#define MX23_PAD_PWM4__ETM_TCLK				0x11e1
+#define MX23_PAD_SSP1_DETECT__GPMI_CE3N			0x2011
+#define MX23_PAD_SSP1_DATA1__I2C_SCL			0x2031
+#define MX23_PAD_SSP1_DATA2__I2C_SDA			0x2041
+#define MX23_PAD_ROTARYA__AUART2_RTS			0x2071
+#define MX23_PAD_ROTARYB__AUART2_CTS			0x2081
+#define MX23_PAD_GPMI_D00__SSP2_DATA0			0x0002
+#define MX23_PAD_GPMI_D01__SSP2_DATA1			0x0012
+#define MX23_PAD_GPMI_D02__SSP2_DATA2			0x0022
+#define MX23_PAD_GPMI_D03__SSP2_DATA3			0x0032
+#define MX23_PAD_GPMI_D04__SSP2_DATA4			0x0042
+#define MX23_PAD_GPMI_D05__SSP2_DATA5			0x0052
+#define MX23_PAD_GPMI_D06__SSP2_DATA6			0x0062
+#define MX23_PAD_GPMI_D07__SSP2_DATA7			0x0072
+#define MX23_PAD_GPMI_D08__SSP1_DATA4			0x0082
+#define MX23_PAD_GPMI_D09__SSP1_DATA5			0x0092
+#define MX23_PAD_GPMI_D10__SSP1_DATA6			0x00a2
+#define MX23_PAD_GPMI_D11__SSP1_DATA7			0x00b2
+#define MX23_PAD_GPMI_D15__GPMI_CE3N			0x00f2
+#define MX23_PAD_GPMI_RDY0__SSP2_DETECT			0x0132
+#define MX23_PAD_GPMI_RDY1__SSP2_CMD			0x0142
+#define MX23_PAD_GPMI_WRN__SSP2_SCK			0x0182
+#define MX23_PAD_AUART1_CTS__SSP1_DATA4			0x01a2
+#define MX23_PAD_AUART1_RTS__SSP1_DATA5			0x01b2
+#define MX23_PAD_AUART1_RX__SSP1_DATA6			0x01c2
+#define MX23_PAD_AUART1_TX__SSP1_DATA7			0x01d2
+#define MX23_PAD_I2C_SCL__AUART1_TX			0x01e2
+#define MX23_PAD_I2C_SDA__AUART1_RX			0x01f2
+#define MX23_PAD_LCD_D08__SAIF2_SDATA0			0x1082
+#define MX23_PAD_LCD_D09__SAIF1_SDATA0			0x1092
+#define MX23_PAD_LCD_D10__SAIF_MCLK_BITCLK		0x10a2
+#define MX23_PAD_LCD_D11__SAIF_LRCLK			0x10b2
+#define MX23_PAD_LCD_D12__SAIF2_SDATA1			0x10c2
+#define MX23_PAD_LCD_D13__SAIF2_SDATA2			0x10d2
+#define MX23_PAD_LCD_D14__SAIF1_SDATA2			0x10e2
+#define MX23_PAD_LCD_D15__SAIF1_SDATA1			0x10f2
+#define MX23_PAD_LCD_D16__SAIF_ALT_BITCLK		0x1102
+#define MX23_PAD_LCD_RESET__GPMI_CE3N			0x1122
+#define MX23_PAD_PWM0__DUART_RX				0x11a2
+#define MX23_PAD_PWM1__DUART_TX				0x11b2
+#define MX23_PAD_PWM3__AUART1_CTS			0x11d2
+#define MX23_PAD_PWM4__AUART1_RTS			0x11e2
+#define MX23_PAD_SSP1_CMD__JTAG_TDO			0x2002
+#define MX23_PAD_SSP1_DETECT__USB_OTG_ID		0x2012
+#define MX23_PAD_SSP1_DATA0__JTAG_TDI			0x2022
+#define MX23_PAD_SSP1_DATA1__JTAG_TCLK			0x2032
+#define MX23_PAD_SSP1_DATA2__JTAG_RTCK			0x2042
+#define MX23_PAD_SSP1_DATA3__JTAG_TMS			0x2052
+#define MX23_PAD_SSP1_SCK__JTAG_TRST			0x2062
+#define MX23_PAD_ROTARYA__SPDIF				0x2072
+#define MX23_PAD_ROTARYB__GPMI_CE3N			0x2082
+#define MX23_PAD_GPMI_D00__GPIO_0_0			0x0003
+#define MX23_PAD_GPMI_D01__GPIO_0_1			0x0013
+#define MX23_PAD_GPMI_D02__GPIO_0_2			0x0023
+#define MX23_PAD_GPMI_D03__GPIO_0_3			0x0033
+#define MX23_PAD_GPMI_D04__GPIO_0_4			0x0043
+#define MX23_PAD_GPMI_D05__GPIO_0_5			0x0053
+#define MX23_PAD_GPMI_D06__GPIO_0_6			0x0063
+#define MX23_PAD_GPMI_D07__GPIO_0_7			0x0073
+#define MX23_PAD_GPMI_D08__GPIO_0_8			0x0083
+#define MX23_PAD_GPMI_D09__GPIO_0_9			0x0093
+#define MX23_PAD_GPMI_D10__GPIO_0_10			0x00a3
+#define MX23_PAD_GPMI_D11__GPIO_0_11			0x00b3
+#define MX23_PAD_GPMI_D12__GPIO_0_12			0x00c3
+#define MX23_PAD_GPMI_D13__GPIO_0_13			0x00d3
+#define MX23_PAD_GPMI_D14__GPIO_0_14			0x00e3
+#define MX23_PAD_GPMI_D15__GPIO_0_15			0x00f3
+#define MX23_PAD_GPMI_CLE__GPIO_0_16			0x0103
+#define MX23_PAD_GPMI_ALE__GPIO_0_17			0x0113
+#define MX23_PAD_GPMI_CE2N__GPIO_0_18			0x0123
+#define MX23_PAD_GPMI_RDY0__GPIO_0_19			0x0133
+#define MX23_PAD_GPMI_RDY1__GPIO_0_20			0x0143
+#define MX23_PAD_GPMI_RDY2__GPIO_0_21			0x0153
+#define MX23_PAD_GPMI_RDY3__GPIO_0_22			0x0163
+#define MX23_PAD_GPMI_WPN__GPIO_0_23			0x0173
+#define MX23_PAD_GPMI_WRN__GPIO_0_24			0x0183
+#define MX23_PAD_GPMI_RDN__GPIO_0_25			0x0193
+#define MX23_PAD_AUART1_CTS__GPIO_0_26			0x01a3
+#define MX23_PAD_AUART1_RTS__GPIO_0_27			0x01b3
+#define MX23_PAD_AUART1_RX__GPIO_0_28			0x01c3
+#define MX23_PAD_AUART1_TX__GPIO_0_29			0x01d3
+#define MX23_PAD_I2C_SCL__GPIO_0_30			0x01e3
+#define MX23_PAD_I2C_SDA__GPIO_0_31			0x01f3
+#define MX23_PAD_LCD_D00__GPIO_1_0			0x1003
+#define MX23_PAD_LCD_D01__GPIO_1_1			0x1013
+#define MX23_PAD_LCD_D02__GPIO_1_2			0x1023
+#define MX23_PAD_LCD_D03__GPIO_1_3			0x1033
+#define MX23_PAD_LCD_D04__GPIO_1_4			0x1043
+#define MX23_PAD_LCD_D05__GPIO_1_5			0x1053
+#define MX23_PAD_LCD_D06__GPIO_1_6			0x1063
+#define MX23_PAD_LCD_D07__GPIO_1_7			0x1073
+#define MX23_PAD_LCD_D08__GPIO_1_8			0x1083
+#define MX23_PAD_LCD_D09__GPIO_1_9			0x1093
+#define MX23_PAD_LCD_D10__GPIO_1_10			0x10a3
+#define MX23_PAD_LCD_D11__GPIO_1_11			0x10b3
+#define MX23_PAD_LCD_D12__GPIO_1_12			0x10c3
+#define MX23_PAD_LCD_D13__GPIO_1_13			0x10d3
+#define MX23_PAD_LCD_D14__GPIO_1_14			0x10e3
+#define MX23_PAD_LCD_D15__GPIO_1_15			0x10f3
+#define MX23_PAD_LCD_D16__GPIO_1_16			0x1103
+#define MX23_PAD_LCD_D17__GPIO_1_17			0x1113
+#define MX23_PAD_LCD_RESET__GPIO_1_18			0x1123
+#define MX23_PAD_LCD_RS__GPIO_1_19			0x1133
+#define MX23_PAD_LCD_WR__GPIO_1_20			0x1143
+#define MX23_PAD_LCD_CS__GPIO_1_21			0x1153
+#define MX23_PAD_LCD_DOTCK__GPIO_1_22			0x1163
+#define MX23_PAD_LCD_ENABLE__GPIO_1_23			0x1173
+#define MX23_PAD_LCD_HSYNC__GPIO_1_24			0x1183
+#define MX23_PAD_LCD_VSYNC__GPIO_1_25			0x1193
+#define MX23_PAD_PWM0__GPIO_1_26			0x11a3
+#define MX23_PAD_PWM1__GPIO_1_27			0x11b3
+#define MX23_PAD_PWM2__GPIO_1_28			0x11c3
+#define MX23_PAD_PWM3__GPIO_1_29			0x11d3
+#define MX23_PAD_PWM4__GPIO_1_30			0x11e3
+#define MX23_PAD_SSP1_CMD__GPIO_2_0			0x2003
+#define MX23_PAD_SSP1_DETECT__GPIO_2_1			0x2013
+#define MX23_PAD_SSP1_DATA0__GPIO_2_2			0x2023
+#define MX23_PAD_SSP1_DATA1__GPIO_2_3			0x2033
+#define MX23_PAD_SSP1_DATA2__GPIO_2_4			0x2043
+#define MX23_PAD_SSP1_DATA3__GPIO_2_5			0x2053
+#define MX23_PAD_SSP1_SCK__GPIO_2_6			0x2063
+#define MX23_PAD_ROTARYA__GPIO_2_7			0x2073
+#define MX23_PAD_ROTARYB__GPIO_2_8			0x2083
+#define MX23_PAD_EMI_A00__GPIO_2_9			0x2093
+#define MX23_PAD_EMI_A01__GPIO_2_10			0x20a3
+#define MX23_PAD_EMI_A02__GPIO_2_11			0x20b3
+#define MX23_PAD_EMI_A03__GPIO_2_12			0x20c3
+#define MX23_PAD_EMI_A04__GPIO_2_13			0x20d3
+#define MX23_PAD_EMI_A05__GPIO_2_14			0x20e3
+#define MX23_PAD_EMI_A06__GPIO_2_15			0x20f3
+#define MX23_PAD_EMI_A07__GPIO_2_16			0x2103
+#define MX23_PAD_EMI_A08__GPIO_2_17			0x2113
+#define MX23_PAD_EMI_A09__GPIO_2_18			0x2123
+#define MX23_PAD_EMI_A10__GPIO_2_19			0x2133
+#define MX23_PAD_EMI_A11__GPIO_2_20			0x2143
+#define MX23_PAD_EMI_A12__GPIO_2_21			0x2153
+#define MX23_PAD_EMI_BA0__GPIO_2_22			0x2163
+#define MX23_PAD_EMI_BA1__GPIO_2_23			0x2173
+#define MX23_PAD_EMI_CASN__GPIO_2_24			0x2183
+#define MX23_PAD_EMI_CE0N__GPIO_2_25			0x2193
+#define MX23_PAD_EMI_CE1N__GPIO_2_26			0x21a3
+#define MX23_PAD_GPMI_CE1N__GPIO_2_27			0x21b3
+#define MX23_PAD_GPMI_CE0N__GPIO_2_28			0x21c3
+#define MX23_PAD_EMI_CKE__GPIO_2_29			0x21d3
+#define MX23_PAD_EMI_RASN__GPIO_2_30			0x21e3
+#define MX23_PAD_EMI_WEN__GPIO_2_31			0x21f3
+
+#endif /* __DT_BINDINGS_MX23_PINCTRL_H__ */
diff --git a/include/dt-bindings/pinctrl/mx28.h b/include/dt-bindings/pinctrl/mx28.h
new file mode 100644
index 0000000..d491f49
--- /dev/null
+++ b/include/dt-bindings/pinctrl/mx28.h
@@ -0,0 +1,506 @@
+/*
+ * Header providing constants for i.MX28 pinctrl bindings.
+ *
+ * Copyright (C) 2013 Lothar Wa?mann <LW at KARO-electronics.de>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#ifndef __DT_BINDINGS_MX28_PINCTRL_H__
+#define __DT_BINDINGS_MX28_PINCTRL_H__
+
+#include "mxs.h"
+
+#define MX28_PAD_GPMI_D00__GPMI_D0			0x0000
+#define MX28_PAD_GPMI_D01__GPMI_D1			0x0010
+#define MX28_PAD_GPMI_D02__GPMI_D2			0x0020
+#define MX28_PAD_GPMI_D03__GPMI_D3			0x0030
+#define MX28_PAD_GPMI_D04__GPMI_D4			0x0040
+#define MX28_PAD_GPMI_D05__GPMI_D5			0x0050
+#define MX28_PAD_GPMI_D06__GPMI_D6			0x0060
+#define MX28_PAD_GPMI_D07__GPMI_D7			0x0070
+#define MX28_PAD_GPMI_CE0N__GPMI_CE0N			0x0100
+#define MX28_PAD_GPMI_CE1N__GPMI_CE1N			0x0110
+#define MX28_PAD_GPMI_CE2N__GPMI_CE2N			0x0120
+#define MX28_PAD_GPMI_CE3N__GPMI_CE3N			0x0130
+#define MX28_PAD_GPMI_RDY0__GPMI_READY0			0x0140
+#define MX28_PAD_GPMI_RDY1__GPMI_READY1			0x0150
+#define MX28_PAD_GPMI_RDY2__GPMI_READY2			0x0160
+#define MX28_PAD_GPMI_RDY3__GPMI_READY3			0x0170
+#define MX28_PAD_GPMI_RDN__GPMI_RDN			0x0180
+#define MX28_PAD_GPMI_WRN__GPMI_WRN			0x0190
+#define MX28_PAD_GPMI_ALE__GPMI_ALE			0x01a0
+#define MX28_PAD_GPMI_CLE__GPMI_CLE			0x01b0
+#define MX28_PAD_GPMI_RESETN__GPMI_RESETN		0x01c0
+#define MX28_PAD_LCD_D00__LCD_D0			0x1000
+#define MX28_PAD_LCD_D01__LCD_D1			0x1010
+#define MX28_PAD_LCD_D02__LCD_D2			0x1020
+#define MX28_PAD_LCD_D03__LCD_D3			0x1030
+#define MX28_PAD_LCD_D04__LCD_D4			0x1040
+#define MX28_PAD_LCD_D05__LCD_D5			0x1050
+#define MX28_PAD_LCD_D06__LCD_D6			0x1060
+#define MX28_PAD_LCD_D07__LCD_D7			0x1070
+#define MX28_PAD_LCD_D08__LCD_D8			0x1080
+#define MX28_PAD_LCD_D09__LCD_D9			0x1090
+#define MX28_PAD_LCD_D10__LCD_D10			0x10a0
+#define MX28_PAD_LCD_D11__LCD_D11			0x10b0
+#define MX28_PAD_LCD_D12__LCD_D12			0x10c0
+#define MX28_PAD_LCD_D13__LCD_D13			0x10d0
+#define MX28_PAD_LCD_D14__LCD_D14			0x10e0
+#define MX28_PAD_LCD_D15__LCD_D15			0x10f0
+#define MX28_PAD_LCD_D16__LCD_D16			0x1100
+#define MX28_PAD_LCD_D17__LCD_D17			0x1110
+#define MX28_PAD_LCD_D18__LCD_D18			0x1120
+#define MX28_PAD_LCD_D19__LCD_D19			0x1130
+#define MX28_PAD_LCD_D20__LCD_D20			0x1140
+#define MX28_PAD_LCD_D21__LCD_D21			0x1150
+#define MX28_PAD_LCD_D22__LCD_D22			0x1160
+#define MX28_PAD_LCD_D23__LCD_D23			0x1170
+#define MX28_PAD_LCD_RD_E__LCD_RD_E			0x1180
+#define MX28_PAD_LCD_WR_RWN__LCD_WR_RWN			0x1190
+#define MX28_PAD_LCD_RS__LCD_RS				0x11a0
+#define MX28_PAD_LCD_CS__LCD_CS				0x11b0
+#define MX28_PAD_LCD_VSYNC__LCD_VSYNC			0x11c0
+#define MX28_PAD_LCD_HSYNC__LCD_HSYNC			0x11d0
+#define MX28_PAD_LCD_DOTCLK__LCD_DOTCLK			0x11e0
+#define MX28_PAD_LCD_ENABLE__LCD_ENABLE			0x11f0
+#define MX28_PAD_SSP0_DATA0__SSP0_D0			0x2000
+#define MX28_PAD_SSP0_DATA1__SSP0_D1			0x2010
+#define MX28_PAD_SSP0_DATA2__SSP0_D2			0x2020
+#define MX28_PAD_SSP0_DATA3__SSP0_D3			0x2030
+#define MX28_PAD_SSP0_DATA4__SSP0_D4			0x2040
+#define MX28_PAD_SSP0_DATA5__SSP0_D5			0x2050
+#define MX28_PAD_SSP0_DATA6__SSP0_D6			0x2060
+#define MX28_PAD_SSP0_DATA7__SSP0_D7			0x2070
+#define MX28_PAD_SSP0_CMD__SSP0_CMD			0x2080
+#define MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT		0x2090
+#define MX28_PAD_SSP0_SCK__SSP0_SCK			0x20a0
+#define MX28_PAD_SSP1_SCK__SSP1_SCK			0x20c0
+#define MX28_PAD_SSP1_CMD__SSP1_CMD			0x20d0
+#define MX28_PAD_SSP1_DATA0__SSP1_D0			0x20e0
+#define MX28_PAD_SSP1_DATA3__SSP1_D3			0x20f0
+#define MX28_PAD_SSP2_SCK__SSP2_SCK			0x2100
+#define MX28_PAD_SSP2_MOSI__SSP2_CMD			0x2110
+#define MX28_PAD_SSP2_MISO__SSP2_D0			0x2120
+#define MX28_PAD_SSP2_SS0__SSP2_D3			0x2130
+#define MX28_PAD_SSP2_SS1__SSP2_D4			0x2140
+#define MX28_PAD_SSP2_SS2__SSP2_D5			0x2150
+#define MX28_PAD_SSP3_SCK__SSP3_SCK			0x2180
+#define MX28_PAD_SSP3_MOSI__SSP3_CMD			0x2190
+#define MX28_PAD_SSP3_MISO__SSP3_D0			0x21a0
+#define MX28_PAD_SSP3_SS0__SSP3_D3			0x21b0
+#define MX28_PAD_AUART0_RX__AUART0_RX			0x3000
+#define MX28_PAD_AUART0_TX__AUART0_TX			0x3010
+#define MX28_PAD_AUART0_CTS__AUART0_CTS			0x3020
+#define MX28_PAD_AUART0_RTS__AUART0_RTS			0x3030
+#define MX28_PAD_AUART1_RX__AUART1_RX			0x3040
+#define MX28_PAD_AUART1_TX__AUART1_TX			0x3050
+#define MX28_PAD_AUART1_CTS__AUART1_CTS			0x3060
+#define MX28_PAD_AUART1_RTS__AUART1_RTS			0x3070
+#define MX28_PAD_AUART2_RX__AUART2_RX			0x3080
+#define MX28_PAD_AUART2_TX__AUART2_TX			0x3090
+#define MX28_PAD_AUART2_CTS__AUART2_CTS			0x30a0
+#define MX28_PAD_AUART2_RTS__AUART2_RTS			0x30b0
+#define MX28_PAD_AUART3_RX__AUART3_RX			0x30c0
+#define MX28_PAD_AUART3_TX__AUART3_TX			0x30d0
+#define MX28_PAD_AUART3_CTS__AUART3_CTS			0x30e0
+#define MX28_PAD_AUART3_RTS__AUART3_RTS			0x30f0
+#define MX28_PAD_PWM0__PWM_0				0x3100
+#define MX28_PAD_PWM1__PWM_1				0x3110
+#define MX28_PAD_PWM2__PWM_2				0x3120
+#define MX28_PAD_SAIF0_MCLK__SAIF0_MCLK			0x3140
+#define MX28_PAD_SAIF0_LRCLK__SAIF0_LRCLK		0x3150
+#define MX28_PAD_SAIF0_BITCLK__SAIF0_BITCLK		0x3160
+#define MX28_PAD_SAIF0_SDATA0__SAIF0_SDATA0		0x3170
+#define MX28_PAD_I2C0_SCL__I2C0_SCL			0x3180
+#define MX28_PAD_I2C0_SDA__I2C0_SDA			0x3190
+#define MX28_PAD_SAIF1_SDATA0__SAIF1_SDATA0		0x31a0
+#define MX28_PAD_SPDIF__SPDIF_TX			0x31b0
+#define MX28_PAD_PWM3__PWM_3				0x31c0
+#define MX28_PAD_PWM4__PWM_4				0x31d0
+#define MX28_PAD_LCD_RESET__LCD_RESET			0x31e0
+#define MX28_PAD_ENET0_MDC__ENET0_MDC			0x4000
+#define MX28_PAD_ENET0_MDIO__ENET0_MDIO			0x4010
+#define MX28_PAD_ENET0_RX_EN__ENET0_RX_EN		0x4020
+#define MX28_PAD_ENET0_RXD0__ENET0_RXD0			0x4030
+#define MX28_PAD_ENET0_RXD1__ENET0_RXD1			0x4040
+#define MX28_PAD_ENET0_TX_CLK__ENET0_TX_CLK		0x4050
+#define MX28_PAD_ENET0_TX_EN__ENET0_TX_EN		0x4060
+#define MX28_PAD_ENET0_TXD0__ENET0_TXD0			0x4070
+#define MX28_PAD_ENET0_TXD1__ENET0_TXD1			0x4080
+#define MX28_PAD_ENET0_RXD2__ENET0_RXD2			0x4090
+#define MX28_PAD_ENET0_RXD3__ENET0_RXD3			0x40a0
+#define MX28_PAD_ENET0_TXD2__ENET0_TXD2			0x40b0
+#define MX28_PAD_ENET0_TXD3__ENET0_TXD3			0x40c0
+#define MX28_PAD_ENET0_RX_CLK__ENET0_RX_CLK		0x40d0
+#define MX28_PAD_ENET0_COL__ENET0_COL			0x40e0
+#define MX28_PAD_ENET0_CRS__ENET0_CRS			0x40f0
+#define MX28_PAD_ENET_CLK__CLKCTRL_ENET			0x4100
+#define MX28_PAD_JTAG_RTCK__JTAG_RTCK			0x4140
+#define MX28_PAD_EMI_D00__EMI_DATA0			0x5000
+#define MX28_PAD_EMI_D01__EMI_DATA1			0x5010
+#define MX28_PAD_EMI_D02__EMI_DATA2			0x5020
+#define MX28_PAD_EMI_D03__EMI_DATA3			0x5030
+#define MX28_PAD_EMI_D04__EMI_DATA4			0x5040
+#define MX28_PAD_EMI_D05__EMI_DATA5			0x5050
+#define MX28_PAD_EMI_D06__EMI_DATA6			0x5060
+#define MX28_PAD_EMI_D07__EMI_DATA7			0x5070
+#define MX28_PAD_EMI_D08__EMI_DATA8			0x5080
+#define MX28_PAD_EMI_D09__EMI_DATA9			0x5090
+#define MX28_PAD_EMI_D10__EMI_DATA10			0x50a0
+#define MX28_PAD_EMI_D11__EMI_DATA11			0x50b0
+#define MX28_PAD_EMI_D12__EMI_DATA12			0x50c0
+#define MX28_PAD_EMI_D13__EMI_DATA13			0x50d0
+#define MX28_PAD_EMI_D14__EMI_DATA14			0x50e0
+#define MX28_PAD_EMI_D15__EMI_DATA15			0x50f0
+#define MX28_PAD_EMI_ODT0__EMI_ODT0			0x5100
+#define MX28_PAD_EMI_DQM0__EMI_DQM0			0x5110
+#define MX28_PAD_EMI_ODT1__EMI_ODT1			0x5120
+#define MX28_PAD_EMI_DQM1__EMI_DQM1			0x5130
+#define MX28_PAD_EMI_DDR_OPEN_FB__EMI_DDR_OPEN_FEEDBACK	0x5140
+#define MX28_PAD_EMI_CLK__EMI_CLK			0x5150
+#define MX28_PAD_EMI_DQS0__EMI_DQS0			0x5160
+#define MX28_PAD_EMI_DQS1__EMI_DQS1			0x5170
+#define MX28_PAD_EMI_DDR_OPEN__EMI_DDR_OPEN		0x51a0
+#define MX28_PAD_EMI_A00__EMI_ADDR0			0x6000
+#define MX28_PAD_EMI_A01__EMI_ADDR1			0x6010
+#define MX28_PAD_EMI_A02__EMI_ADDR2			0x6020
+#define MX28_PAD_EMI_A03__EMI_ADDR3			0x6030
+#define MX28_PAD_EMI_A04__EMI_ADDR4			0x6040
+#define MX28_PAD_EMI_A05__EMI_ADDR5			0x6050
+#define MX28_PAD_EMI_A06__EMI_ADDR6			0x6060
+#define MX28_PAD_EMI_A07__EMI_ADDR7			0x6070
+#define MX28_PAD_EMI_A08__EMI_ADDR8			0x6080
+#define MX28_PAD_EMI_A09__EMI_ADDR9			0x6090
+#define MX28_PAD_EMI_A10__EMI_ADDR10			0x60a0
+#define MX28_PAD_EMI_A11__EMI_ADDR11			0x60b0
+#define MX28_PAD_EMI_A12__EMI_ADDR12			0x60c0
+#define MX28_PAD_EMI_A13__EMI_ADDR13			0x60d0
+#define MX28_PAD_EMI_A14__EMI_ADDR14			0x60e0
+#define MX28_PAD_EMI_BA0__EMI_BA0			0x6100
+#define MX28_PAD_EMI_BA1__EMI_BA1			0x6110
+#define MX28_PAD_EMI_BA2__EMI_BA2			0x6120
+#define MX28_PAD_EMI_CASN__EMI_CASN			0x6130
+#define MX28_PAD_EMI_RASN__EMI_RASN			0x6140
+#define MX28_PAD_EMI_WEN__EMI_WEN			0x6150
+#define MX28_PAD_EMI_CE0N__EMI_CE0N			0x6160
+#define MX28_PAD_EMI_CE1N__EMI_CE1N			0x6170
+#define MX28_PAD_EMI_CKE__EMI_CKE			0x6180
+#define MX28_PAD_GPMI_D00__SSP1_D0			0x0001
+#define MX28_PAD_GPMI_D01__SSP1_D1			0x0011
+#define MX28_PAD_GPMI_D02__SSP1_D2			0x0021
+#define MX28_PAD_GPMI_D03__SSP1_D3			0x0031
+#define MX28_PAD_GPMI_D04__SSP1_D4			0x0041
+#define MX28_PAD_GPMI_D05__SSP1_D5			0x0051
+#define MX28_PAD_GPMI_D06__SSP1_D6			0x0061
+#define MX28_PAD_GPMI_D07__SSP1_D7			0x0071
+#define MX28_PAD_GPMI_CE0N__SSP3_D0			0x0101
+#define MX28_PAD_GPMI_CE1N__SSP3_D3			0x0111
+#define MX28_PAD_GPMI_CE2N__CAN1_TX			0x0121
+#define MX28_PAD_GPMI_CE3N__CAN1_RX			0x0131
+#define MX28_PAD_GPMI_RDY0__SSP1_CARD_DETECT		0x0141
+#define MX28_PAD_GPMI_RDY1__SSP1_CMD			0x0151
+#define MX28_PAD_GPMI_RDY2__CAN0_TX			0x0161
+#define MX28_PAD_GPMI_RDY3__CAN0_RX			0x0171
+#define MX28_PAD_GPMI_RDN__SSP3_SCK			0x0181
+#define MX28_PAD_GPMI_WRN__SSP1_SCK			0x0191
+#define MX28_PAD_GPMI_ALE__SSP3_D1			0x01a1
+#define MX28_PAD_GPMI_CLE__SSP3_D2			0x01b1
+#define MX28_PAD_GPMI_RESETN__SSP3_CMD			0x01c1
+#define MX28_PAD_LCD_D03__ETM_DA8			0x1031
+#define MX28_PAD_LCD_D04__ETM_DA9			0x1041
+#define MX28_PAD_LCD_D08__ETM_DA3			0x1081
+#define MX28_PAD_LCD_D09__ETM_DA4			0x1091
+#define MX28_PAD_LCD_D20__ENET1_1588_EVENT2_OUT		0x1141
+#define MX28_PAD_LCD_D21__ENET1_1588_EVENT2_IN		0x1151
+#define MX28_PAD_LCD_D22__ENET1_1588_EVENT3_OUT		0x1161
+#define MX28_PAD_LCD_D23__ENET1_1588_EVENT3_IN		0x1171
+#define MX28_PAD_LCD_RD_E__LCD_VSYNC			0x1181
+#define MX28_PAD_LCD_WR_RWN__LCD_HSYNC			0x1191
+#define MX28_PAD_LCD_RS__LCD_DOTCLK			0x11a1
+#define MX28_PAD_LCD_CS__LCD_ENABLE			0x11b1
+#define MX28_PAD_LCD_VSYNC__SAIF1_SDATA0		0x11c1
+#define MX28_PAD_LCD_HSYNC__SAIF1_SDATA1		0x11d1
+#define MX28_PAD_LCD_DOTCLK__SAIF1_MCLK			0x11e1
+#define MX28_PAD_SSP0_DATA4__SSP2_D0			0x2041
+#define MX28_PAD_SSP0_DATA5__SSP2_D3			0x2051
+#define MX28_PAD_SSP0_DATA6__SSP2_CMD			0x2061
+#define MX28_PAD_SSP0_DATA7__SSP2_SCK			0x2071
+#define MX28_PAD_SSP1_SCK__SSP2_D1			0x20c1
+#define MX28_PAD_SSP1_CMD__SSP2_D2			0x20d1
+#define MX28_PAD_SSP1_DATA0__SSP2_D6			0x20e1
+#define MX28_PAD_SSP1_DATA3__SSP2_D7			0x20f1
+#define MX28_PAD_SSP2_SCK__AUART2_RX			0x2101
+#define MX28_PAD_SSP2_MOSI__AUART2_TX			0x2111
+#define MX28_PAD_SSP2_MISO__AUART3_RX			0x2121
+#define MX28_PAD_SSP2_SS0__AUART3_TX			0x2131
+#define MX28_PAD_SSP2_SS1__SSP2_D1			0x2141
+#define MX28_PAD_SSP2_SS2__SSP2_D2			0x2151
+#define MX28_PAD_SSP3_SCK__AUART4_TX			0x2181
+#define MX28_PAD_SSP3_MOSI__AUART4_RX			0x2191
+#define MX28_PAD_SSP3_MISO__AUART4_RTS			0x21a1
+#define MX28_PAD_SSP3_SS0__AUART4_CTS			0x21b1
+#define MX28_PAD_AUART0_RX__I2C0_SCL			0x3001
+#define MX28_PAD_AUART0_TX__I2C0_SDA			0x3011
+#define MX28_PAD_AUART0_CTS__AUART4_RX			0x3021
+#define MX28_PAD_AUART0_RTS__AUART4_TX			0x3031
+#define MX28_PAD_AUART1_RX__SSP2_CARD_DETECT		0x3041
+#define MX28_PAD_AUART1_TX__SSP3_CARD_DETECT		0x3051
+#define MX28_PAD_AUART1_CTS__USB0_OVERCURRENT		0x3061
+#define MX28_PAD_AUART1_RTS__USB0_ID			0x3071
+#define MX28_PAD_AUART2_RX__SSP3_D1			0x3081
+#define MX28_PAD_AUART2_TX__SSP3_D2			0x3091
+#define MX28_PAD_AUART2_CTS__I2C1_SCL			0x30a1
+#define MX28_PAD_AUART2_RTS__I2C1_SDA			0x30b1
+#define MX28_PAD_AUART3_RX__CAN0_TX			0x30c1
+#define MX28_PAD_AUART3_TX__CAN0_RX			0x30d1
+#define MX28_PAD_AUART3_CTS__CAN1_TX			0x30e1
+#define MX28_PAD_AUART3_RTS__CAN1_RX			0x30f1
+#define MX28_PAD_PWM0__I2C1_SCL				0x3101
+#define MX28_PAD_PWM1__I2C1_SDA				0x3111
+#define MX28_PAD_PWM2__USB0_ID				0x3121
+#define MX28_PAD_SAIF0_MCLK__PWM_3			0x3141
+#define MX28_PAD_SAIF0_LRCLK__PWM_4			0x3151
+#define MX28_PAD_SAIF0_BITCLK__PWM_5			0x3161
+#define MX28_PAD_SAIF0_SDATA0__PWM_6			0x3171
+#define MX28_PAD_I2C0_SCL__TIMROT_ROTARYA		0x3181
+#define MX28_PAD_I2C0_SDA__TIMROT_ROTARYB		0x3191
+#define MX28_PAD_SAIF1_SDATA0__PWM_7			0x31a1
+#define MX28_PAD_LCD_RESET__LCD_VSYNC			0x31e1
+#define MX28_PAD_ENET0_MDC__GPMI_CE4N			0x4001
+#define MX28_PAD_ENET0_MDIO__GPMI_CE5N			0x4011
+#define MX28_PAD_ENET0_RX_EN__GPMI_CE6N			0x4021
+#define MX28_PAD_ENET0_RXD0__GPMI_CE7N			0x4031
+#define MX28_PAD_ENET0_RXD1__GPMI_READY4		0x4041
+#define MX28_PAD_ENET0_TX_CLK__HSADC_TRIGGER		0x4051
+#define MX28_PAD_ENET0_TX_EN__GPMI_READY5		0x4061
+#define MX28_PAD_ENET0_TXD0__GPMI_READY6		0x4071
+#define MX28_PAD_ENET0_TXD1__GPMI_READY7		0x4081
+#define MX28_PAD_ENET0_RXD2__ENET1_RXD0			0x4091
+#define MX28_PAD_ENET0_RXD3__ENET1_RXD1			0x40a1
+#define MX28_PAD_ENET0_TXD2__ENET1_TXD0			0x40b1
+#define MX28_PAD_ENET0_TXD3__ENET1_TXD1			0x40c1
+#define MX28_PAD_ENET0_RX_CLK__ENET0_RX_ER		0x40d1
+#define MX28_PAD_ENET0_COL__ENET1_TX_EN			0x40e1
+#define MX28_PAD_ENET0_CRS__ENET1_RX_EN			0x40f1
+#define MX28_PAD_GPMI_CE2N__ENET0_RX_ER			0x0122
+#define MX28_PAD_GPMI_CE3N__SAIF1_MCLK			0x0132
+#define MX28_PAD_GPMI_RDY0__USB0_ID			0x0142
+#define MX28_PAD_GPMI_RDY2__ENET0_TX_ER			0x0162
+#define MX28_PAD_GPMI_RDY3__HSADC_TRIGGER		0x0172
+#define MX28_PAD_GPMI_ALE__SSP3_D4			0x01a2
+#define MX28_PAD_GPMI_CLE__SSP3_D5			0x01b2
+#define MX28_PAD_LCD_D00__ETM_DA0			0x1002
+#define MX28_PAD_LCD_D01__ETM_DA1			0x1012
+#define MX28_PAD_LCD_D02__ETM_DA2			0x1022
+#define MX28_PAD_LCD_D03__ETM_DA3			0x1032
+#define MX28_PAD_LCD_D04__ETM_DA4			0x1042
+#define MX28_PAD_LCD_D05__ETM_DA5			0x1052
+#define MX28_PAD_LCD_D06__ETM_DA6			0x1062
+#define MX28_PAD_LCD_D07__ETM_DA7			0x1072
+#define MX28_PAD_LCD_D08__ETM_DA8			0x1082
+#define MX28_PAD_LCD_D09__ETM_DA9			0x1092
+#define MX28_PAD_LCD_D10__ETM_DA10			0x10a2
+#define MX28_PAD_LCD_D11__ETM_DA11			0x10b2
+#define MX28_PAD_LCD_D12__ETM_DA12			0x10c2
+#define MX28_PAD_LCD_D13__ETM_DA13			0x10d2
+#define MX28_PAD_LCD_D14__ETM_DA14			0x10e2
+#define MX28_PAD_LCD_D15__ETM_DA15			0x10f2
+#define MX28_PAD_LCD_D16__ETM_DA7			0x1102
+#define MX28_PAD_LCD_D17__ETM_DA6			0x1112
+#define MX28_PAD_LCD_D18__ETM_DA5			0x1122
+#define MX28_PAD_LCD_D19__ETM_DA4			0x1132
+#define MX28_PAD_LCD_D20__ETM_DA3			0x1142
+#define MX28_PAD_LCD_D21__ETM_DA2			0x1152
+#define MX28_PAD_LCD_D22__ETM_DA1			0x1162
+#define MX28_PAD_LCD_D23__ETM_DA0			0x1172
+#define MX28_PAD_LCD_RD_E__ETM_TCTL			0x1182
+#define MX28_PAD_LCD_WR_RWN__ETM_TCLK			0x1192
+#define MX28_PAD_LCD_HSYNC__ETM_TCTL			0x11d2
+#define MX28_PAD_LCD_DOTCLK__ETM_TCLK			0x11e2
+#define MX28_PAD_SSP1_SCK__ENET0_1588_EVENT2_OUT	0x20c2
+#define MX28_PAD_SSP1_CMD__ENET0_1588_EVENT2_IN		0x20d2
+#define MX28_PAD_SSP1_DATA0__ENET0_1588_EVENT3_OUT	0x20e2
+#define MX28_PAD_SSP1_DATA3__ENET0_1588_EVENT3_IN	0x20f2
+#define MX28_PAD_SSP2_SCK__SAIF0_SDATA1			0x2102
+#define MX28_PAD_SSP2_MOSI__SAIF0_SDATA2		0x2112
+#define MX28_PAD_SSP2_MISO__SAIF1_SDATA1		0x2122
+#define MX28_PAD_SSP2_SS0__SAIF1_SDATA2			0x2132
+#define MX28_PAD_SSP2_SS1__USB1_OVERCURRENT		0x2142
+#define MX28_PAD_SSP2_SS2__USB0_OVERCURRENT		0x2152
+#define MX28_PAD_SSP3_SCK__ENET1_1588_EVENT0_OUT	0x2182
+#define MX28_PAD_SSP3_MOSI__ENET1_1588_EVENT0_IN	0x2192
+#define MX28_PAD_SSP3_MISO__ENET1_1588_EVENT1_OUT	0x21a2
+#define MX28_PAD_SSP3_SS0__ENET1_1588_EVENT1_IN		0x21b2
+#define MX28_PAD_AUART0_RX__DUART_CTS			0x3002
+#define MX28_PAD_AUART0_TX__DUART_RTS			0x3012
+#define MX28_PAD_AUART0_CTS__DUART_RX			0x3022
+#define MX28_PAD_AUART0_RTS__DUART_TX			0x3032
+#define MX28_PAD_AUART1_RX__PWM_0			0x3042
+#define MX28_PAD_AUART1_TX__PWM_1			0x3052
+#define MX28_PAD_AUART1_CTS__TIMROT_ROTARYA		0x3062
+#define MX28_PAD_AUART1_RTS__TIMROT_ROTARYB		0x3072
+#define MX28_PAD_AUART2_RX__SSP3_D4			0x3082
+#define MX28_PAD_AUART2_TX__SSP3_D5			0x3092
+#define MX28_PAD_AUART2_CTS__SAIF1_BITCLK		0x30a2
+#define MX28_PAD_AUART2_RTS__SAIF1_LRCLK		0x30b2
+#define MX28_PAD_AUART3_RX__ENET0_1588_EVENT0_OUT	0x30c2
+#define MX28_PAD_AUART3_TX__ENET0_1588_EVENT0_IN	0x30d2
+#define MX28_PAD_AUART3_CTS__ENET0_1588_EVENT1_OUT	0x30e2
+#define MX28_PAD_AUART3_RTS__ENET0_1588_EVENT1_IN	0x30f2
+#define MX28_PAD_PWM0__DUART_RX				0x3102
+#define MX28_PAD_PWM1__DUART_TX				0x3112
+#define MX28_PAD_PWM2__USB1_OVERCURRENT			0x3122
+#define MX28_PAD_SAIF0_MCLK__AUART4_CTS			0x3142
+#define MX28_PAD_SAIF0_LRCLK__AUART4_RTS		0x3152
+#define MX28_PAD_SAIF0_BITCLK__AUART4_RX		0x3162
+#define MX28_PAD_SAIF0_SDATA0__AUART4_TX		0x3172
+#define MX28_PAD_I2C0_SCL__DUART_RX			0x3182
+#define MX28_PAD_I2C0_SDA__DUART_TX			0x3192
+#define MX28_PAD_SAIF1_SDATA0__SAIF0_SDATA1		0x31a2
+#define MX28_PAD_SPDIF__ENET1_RX_ER			0x31b2
+#define MX28_PAD_ENET0_MDC__SAIF0_SDATA1		0x4002
+#define MX28_PAD_ENET0_MDIO__SAIF0_SDATA2		0x4012
+#define MX28_PAD_ENET0_RX_EN__SAIF1_SDATA1		0x4022
+#define MX28_PAD_ENET0_RXD0__SAIF1_SDATA2		0x4032
+#define MX28_PAD_ENET0_TX_CLK__ENET0_1588_EVENT2_OUT	0x4052
+#define MX28_PAD_ENET0_RXD2__ENET0_1588_EVENT0_OUT	0x4092
+#define MX28_PAD_ENET0_RXD3__ENET0_1588_EVENT0_IN	0x40a2
+#define MX28_PAD_ENET0_TXD2__ENET0_1588_EVENT1_OUT	0x40b2
+#define MX28_PAD_ENET0_TXD3__ENET0_1588_EVENT1_IN	0x40c2
+#define MX28_PAD_ENET0_RX_CLK__ENET0_1588_EVENT2_IN	0x40d2
+#define MX28_PAD_ENET0_COL__ENET0_1588_EVENT3_OUT	0x40e2
+#define MX28_PAD_ENET0_CRS__ENET0_1588_EVENT3_IN	0x40f2
+#define MX28_PAD_GPMI_D00__GPIO_0_0			0x0003
+#define MX28_PAD_GPMI_D01__GPIO_0_1			0x0013
+#define MX28_PAD_GPMI_D02__GPIO_0_2			0x0023
+#define MX28_PAD_GPMI_D03__GPIO_0_3			0x0033
+#define MX28_PAD_GPMI_D04__GPIO_0_4			0x0043
+#define MX28_PAD_GPMI_D05__GPIO_0_5			0x0053
+#define MX28_PAD_GPMI_D06__GPIO_0_6			0x0063
+#define MX28_PAD_GPMI_D07__GPIO_0_7			0x0073
+#define MX28_PAD_GPMI_CE0N__GPIO_0_16			0x0103
+#define MX28_PAD_GPMI_CE1N__GPIO_0_17			0x0113
+#define MX28_PAD_GPMI_CE2N__GPIO_0_18			0x0123
+#define MX28_PAD_GPMI_CE3N__GPIO_0_19			0x0133
+#define MX28_PAD_GPMI_RDY0__GPIO_0_20			0x0143
+#define MX28_PAD_GPMI_RDY1__GPIO_0_21			0x0153
+#define MX28_PAD_GPMI_RDY2__GPIO_0_22			0x0163
+#define MX28_PAD_GPMI_RDY3__GPIO_0_23			0x0173
+#define MX28_PAD_GPMI_RDN__GPIO_0_24			0x0183
+#define MX28_PAD_GPMI_WRN__GPIO_0_25			0x0193
+#define MX28_PAD_GPMI_ALE__GPIO_0_26			0x01a3
+#define MX28_PAD_GPMI_CLE__GPIO_0_27			0x01b3
+#define MX28_PAD_GPMI_RESETN__GPIO_0_28			0x01c3
+#define MX28_PAD_LCD_D00__GPIO_1_0			0x1003
+#define MX28_PAD_LCD_D01__GPIO_1_1			0x1013
+#define MX28_PAD_LCD_D02__GPIO_1_2			0x1023
+#define MX28_PAD_LCD_D03__GPIO_1_3			0x1033
+#define MX28_PAD_LCD_D04__GPIO_1_4			0x1043
+#define MX28_PAD_LCD_D05__GPIO_1_5			0x1053
+#define MX28_PAD_LCD_D06__GPIO_1_6			0x1063
+#define MX28_PAD_LCD_D07__GPIO_1_7			0x1073
+#define MX28_PAD_LCD_D08__GPIO_1_8			0x1083
+#define MX28_PAD_LCD_D09__GPIO_1_9			0x1093
+#define MX28_PAD_LCD_D10__GPIO_1_10			0x10a3
+#define MX28_PAD_LCD_D11__GPIO_1_11			0x10b3
+#define MX28_PAD_LCD_D12__GPIO_1_12			0x10c3
+#define MX28_PAD_LCD_D13__GPIO_1_13			0x10d3
+#define MX28_PAD_LCD_D14__GPIO_1_14			0x10e3
+#define MX28_PAD_LCD_D15__GPIO_1_15			0x10f3
+#define MX28_PAD_LCD_D16__GPIO_1_16			0x1103
+#define MX28_PAD_LCD_D17__GPIO_1_17			0x1113
+#define MX28_PAD_LCD_D18__GPIO_1_18			0x1123
+#define MX28_PAD_LCD_D19__GPIO_1_19			0x1133
+#define MX28_PAD_LCD_D20__GPIO_1_20			0x1143
+#define MX28_PAD_LCD_D21__GPIO_1_21			0x1153
+#define MX28_PAD_LCD_D22__GPIO_1_22			0x1163
+#define MX28_PAD_LCD_D23__GPIO_1_23			0x1173
+#define MX28_PAD_LCD_RD_E__GPIO_1_24			0x1183
+#define MX28_PAD_LCD_WR_RWN__GPIO_1_25			0x1193
+#define MX28_PAD_LCD_RS__GPIO_1_26			0x11a3
+#define MX28_PAD_LCD_CS__GPIO_1_27			0x11b3
+#define MX28_PAD_LCD_VSYNC__GPIO_1_28			0x11c3
+#define MX28_PAD_LCD_HSYNC__GPIO_1_29			0x11d3
+#define MX28_PAD_LCD_DOTCLK__GPIO_1_30			0x11e3
+#define MX28_PAD_LCD_ENABLE__GPIO_1_31			0x11f3
+#define MX28_PAD_SSP0_DATA0__GPIO_2_0			0x2003
+#define MX28_PAD_SSP0_DATA1__GPIO_2_1			0x2013
+#define MX28_PAD_SSP0_DATA2__GPIO_2_2			0x2023
+#define MX28_PAD_SSP0_DATA3__GPIO_2_3			0x2033
+#define MX28_PAD_SSP0_DATA4__GPIO_2_4			0x2043
+#define MX28_PAD_SSP0_DATA5__GPIO_2_5			0x2053
+#define MX28_PAD_SSP0_DATA6__GPIO_2_6			0x2063
+#define MX28_PAD_SSP0_DATA7__GPIO_2_7			0x2073
+#define MX28_PAD_SSP0_CMD__GPIO_2_8			0x2083
+#define MX28_PAD_SSP0_DETECT__GPIO_2_9			0x2093
+#define MX28_PAD_SSP0_SCK__GPIO_2_10			0x20a3
+#define MX28_PAD_SSP1_SCK__GPIO_2_12			0x20c3
+#define MX28_PAD_SSP1_CMD__GPIO_2_13			0x20d3
+#define MX28_PAD_SSP1_DATA0__GPIO_2_14			0x20e3
+#define MX28_PAD_SSP1_DATA3__GPIO_2_15			0x20f3
+#define MX28_PAD_SSP2_SCK__GPIO_2_16			0x2103
+#define MX28_PAD_SSP2_MOSI__GPIO_2_17			0x2113
+#define MX28_PAD_SSP2_MISO__GPIO_2_18			0x2123
+#define MX28_PAD_SSP2_SS0__GPIO_2_19			0x2133
+#define MX28_PAD_SSP2_SS1__GPIO_2_20			0x2143
+#define MX28_PAD_SSP2_SS2__GPIO_2_21			0x2153
+#define MX28_PAD_SSP3_SCK__GPIO_2_24			0x2183
+#define MX28_PAD_SSP3_MOSI__GPIO_2_25			0x2193
+#define MX28_PAD_SSP3_MISO__GPIO_2_26			0x21a3
+#define MX28_PAD_SSP3_SS0__GPIO_2_27			0x21b3
+#define MX28_PAD_AUART0_RX__GPIO_3_0			0x3003
+#define MX28_PAD_AUART0_TX__GPIO_3_1			0x3013
+#define MX28_PAD_AUART0_CTS__GPIO_3_2			0x3023
+#define MX28_PAD_AUART0_RTS__GPIO_3_3			0x3033
+#define MX28_PAD_AUART1_RX__GPIO_3_4			0x3043
+#define MX28_PAD_AUART1_TX__GPIO_3_5			0x3053
+#define MX28_PAD_AUART1_CTS__GPIO_3_6			0x3063
+#define MX28_PAD_AUART1_RTS__GPIO_3_7			0x3073
+#define MX28_PAD_AUART2_RX__GPIO_3_8			0x3083
+#define MX28_PAD_AUART2_TX__GPIO_3_9			0x3093
+#define MX28_PAD_AUART2_CTS__GPIO_3_10			0x30a3
+#define MX28_PAD_AUART2_RTS__GPIO_3_11			0x30b3
+#define MX28_PAD_AUART3_RX__GPIO_3_12			0x30c3
+#define MX28_PAD_AUART3_TX__GPIO_3_13			0x30d3
+#define MX28_PAD_AUART3_CTS__GPIO_3_14			0x30e3
+#define MX28_PAD_AUART3_RTS__GPIO_3_15			0x30f3
+#define MX28_PAD_PWM0__GPIO_3_16			0x3103
+#define MX28_PAD_PWM1__GPIO_3_17			0x3113
+#define MX28_PAD_PWM2__GPIO_3_18			0x3123
+#define MX28_PAD_SAIF0_MCLK__GPIO_3_20			0x3143
+#define MX28_PAD_SAIF0_LRCLK__GPIO_3_21			0x3153
+#define MX28_PAD_SAIF0_BITCLK__GPIO_3_22		0x3163
+#define MX28_PAD_SAIF0_SDATA0__GPIO_3_23		0x3173
+#define MX28_PAD_I2C0_SCL__GPIO_3_24			0x3183
+#define MX28_PAD_I2C0_SDA__GPIO_3_25			0x3193
+#define MX28_PAD_SAIF1_SDATA0__GPIO_3_26		0x31a3
+#define MX28_PAD_SPDIF__GPIO_3_27			0x31b3
+#define MX28_PAD_PWM3__GPIO_3_28			0x31c3
+#define MX28_PAD_PWM4__GPIO_3_29			0x31d3
+#define MX28_PAD_LCD_RESET__GPIO_3_30			0x31e3
+#define MX28_PAD_ENET0_MDC__GPIO_4_0			0x4003
+#define MX28_PAD_ENET0_MDIO__GPIO_4_1			0x4013
+#define MX28_PAD_ENET0_RX_EN__GPIO_4_2			0x4023
+#define MX28_PAD_ENET0_RXD0__GPIO_4_3			0x4033
+#define MX28_PAD_ENET0_RXD1__GPIO_4_4			0x4043
+#define MX28_PAD_ENET0_TX_CLK__GPIO_4_5			0x4053
+#define MX28_PAD_ENET0_TX_EN__GPIO_4_6			0x4063
+#define MX28_PAD_ENET0_TXD0__GPIO_4_7			0x4073
+#define MX28_PAD_ENET0_TXD1__GPIO_4_8			0x4083
+#define MX28_PAD_ENET0_RXD2__GPIO_4_9			0x4093
+#define MX28_PAD_ENET0_RXD3__GPIO_4_10			0x40a3
+#define MX28_PAD_ENET0_TXD2__GPIO_4_11			0x40b3
+#define MX28_PAD_ENET0_TXD3__GPIO_4_12			0x40c3
+#define MX28_PAD_ENET0_RX_CLK__GPIO_4_13		0x40d3
+#define MX28_PAD_ENET0_COL__GPIO_4_14			0x40e3
+#define MX28_PAD_ENET0_CRS__GPIO_4_15			0x40f3
+#define MX28_PAD_ENET_CLK__GPIO_4_16			0x4103
+#define MX28_PAD_JTAG_RTCK__GPIO_4_20			0x4143
+
+#endif /* __DT_BINDINGS_MX28_PINCTRL_H__ */
diff --git a/include/dt-bindings/pinctrl/mxs.h b/include/dt-bindings/pinctrl/mxs.h
new file mode 100644
index 0000000..c6da987
--- /dev/null
+++ b/include/dt-bindings/pinctrl/mxs.h
@@ -0,0 +1,31 @@
+/*
+ * Header providing constants for i.MX28 pinctrl bindings.
+ *
+ * Copyright (C) 2013 Lothar Wa?mann <LW at KARO-electronics.de>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#ifndef __DT_BINDINGS_MXS_PINCTRL_H__
+#define __DT_BINDINGS_MXS_PINCTRL_H__
+
+/* fsl,drive-strength property */
+#define MXS_DRIVE_4mA		0
+#define MXS_DRIVE_8mA		1
+#define MXS_DRIVE_12mA		2
+#define MXS_DRIVE_16mA		3
+
+/* fsl,voltage property */
+#define MXS_VOLTAGE_LOW		0
+#define MXS_VOLTAGE_HIGH	1
+
+/* fsl,pull-up property */
+#define MXS_PULL_DISABLE	0
+#define MXS_PULL_ENABLE		1
+
+#endif /* __DT_BINDINGS_MXS_PINCTRL_H__ */
-- 
1.7.2.5



From LW at KARO-electronics.de  Wed Jul 31 10:37:55 2013
From: LW at KARO-electronics.de (=?UTF-8?q?Lothar=20Wa=C3=9Fmann?=)
Date: Wed, 31 Jul 2013 16:37:55 +0200
Subject: [PATCH 5/10] ARM: dts: mxs: add pin config for SSP3 interface
In-Reply-To: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
References: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <1375281480-25775-5-git-send-email-LW@KARO-electronics.de>


Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
---
 arch/arm/boot/dts/imx28.dtsi |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 3ec9a68..f597c0f 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -683,6 +683,21 @@
 					fsl,pull-up = <1>;
 				};
 
+				spi3_pins_a: spi3 at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x3082 /* MX28_PAD_AUART2_RX__SSP3_D4 */
+						0x3092 /* MX28_PAD_AUART2_TX__SSP3_D5 */
+						0x2180 /* MX28_PAD_SSP3_SCK__SSP3_SCK */
+						0x2190 /* MX28_PAD_SSP3_MOSI__SSP3_CMD */
+						0x21A0 /* MX28_PAD_SSP3_MISO__SSP3_D0 */
+						0x21B0 /* MX28_PAD_SSP3_SS0__SSP3_D3 */
+					>;
+					fsl,drive-strength = <1>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+
 				usbphy0_pins_a: usbphy0 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-- 
1.7.2.5



From LW at KARO-electronics.de  Wed Jul 31 10:37:52 2013
From: LW at KARO-electronics.de (=?UTF-8?q?Lothar=20Wa=C3=9Fmann?=)
Date: Wed, 31 Jul 2013 16:37:52 +0200
Subject: [PATCH 2/10] ARM: dts: mxs: add labels to most nodes for easier
 reference
In-Reply-To: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
References: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <1375281480-25775-2-git-send-email-LW@KARO-electronics.de>


Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
---
 arch/arm/boot/dts/imx28.dtsi |   48 +++++++++++++++++++++---------------------
 1 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 0360acc..d077958 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -64,7 +64,7 @@
 				reg = <0x80000000 0x2000>;
 			};
 
-			hsadc at 80002000 {
+			hsadc: hsadc at 80002000 {
 				reg = <0x80002000 0x2000>;
 				interrupts = <13>;
 				dmas = <&dma_apbh 12>;
@@ -88,13 +88,13 @@
 				clocks = <&clks 25>;
 			};
 
-			perfmon at 80006000 {
+			perfmon: perfmon at 80006000 {
 				reg = <0x80006000 0x800>;
 				interrupts = <27>;
 				status = "disabled";
 			};
 
-			gpmi-nand at 8000c000 {
+			gpmi: gpmi-nand at 8000c000 {
 				compatible = "fsl,imx28-gpmi-nand";
 				#address-cells = <1>;
 				#size-cells = <1>;
@@ -153,7 +153,7 @@
 				status = "disabled";
 			};
 
-			pinctrl at 80018000 {
+			pinctrl: pinctrl at 80018000 {
 				#address-cells = <1>;
 				#size-cells = <0>;
 				compatible = "fsl,imx28-pinctrl", "simple-bus";
@@ -702,14 +702,14 @@
 				};
 			};
 
-			digctl at 8001c000 {
+			digctl: digctl at 8001c000 {
 				compatible = "fsl,imx28-digctl", "fsl,imx23-digctl";
 				reg = <0x8001c000 0x2000>;
 				interrupts = <89>;
 				status = "disabled";
 			};
 
-			etm at 80022000 {
+			etm: etm at 80022000 {
 				reg = <0x80022000 0x2000>;
 				status = "disabled";
 			};
@@ -730,19 +730,19 @@
 				clocks = <&clks 26>;
 			};
 
-			dcp at 80028000 {
+			dcp: dcp at 80028000 {
 				compatible = "fsl-dcp";
 				reg = <0x80028000 0x2000>;
 				interrupts = <52 53 54>;
 			};
 
-			pxp at 8002a000 {
+			pxp: pxp at 8002a000 {
 				reg = <0x8002a000 0x2000>;
 				interrupts = <39>;
 				status = "disabled";
 			};
 
-			ocotp at 8002c000 {
+			ocotp: ocotp at 8002c000 {
 				compatible = "fsl,ocotp";
 				reg = <0x8002c000 0x2000>;
 				status = "disabled";
@@ -753,7 +753,7 @@
 				status = "disabled";
 			};
 
-			lcdif at 80030000 {
+			lcdif: lcdif at 80030000 {
 				compatible = "fsl,imx28-lcdif";
 				reg = <0x80030000 0x2000>;
 				interrupts = <38>;
@@ -781,37 +781,37 @@
 				status = "disabled";
 			};
 
-			simdbg at 8003c000 {
+			simdbg: simdbg at 8003c000 {
 				reg = <0x8003c000 0x200>;
 				status = "disabled";
 			};
 
-			simgpmisel at 8003c200 {
+			simgpmisel: simgpmisel at 8003c200 {
 				reg = <0x8003c200 0x100>;
 				status = "disabled";
 			};
 
-			simsspsel at 8003c300 {
+			simsspsel: simsspsel at 8003c300 {
 				reg = <0x8003c300 0x100>;
 				status = "disabled";
 			};
 
-			simmemsel at 8003c400 {
+			simmemsel: simmemsel at 8003c400 {
 				reg = <0x8003c400 0x100>;
 				status = "disabled";
 			};
 
-			gpiomon at 8003c500 {
+			gpiomon: gpiomon at 8003c500 {
 				reg = <0x8003c500 0x100>;
 				status = "disabled";
 			};
 
-			simenet at 8003c700 {
+			simenet: simenet at 8003c700 {
 				reg = <0x8003c700 0x100>;
 				status = "disabled";
 			};
 
-			armjtag at 8003c800 {
+			armjtag: armjtag at 8003c800 {
 				reg = <0x8003c800 0x100>;
 				status = "disabled";
 			};
@@ -841,7 +841,7 @@
 				status = "disabled";
 			};
 
-			power at 80044000 {
+			power: power at 80044000 {
 				reg = <0x80044000 0x2000>;
 				status = "disabled";
 			};
@@ -856,7 +856,7 @@
 				status = "disabled";
 			};
 
-			lradc at 80050000 {
+			lradc: lradc at 80050000 {
 				compatible = "fsl,imx28-lradc";
 				reg = <0x80050000 0x2000>;
 				interrupts = <10 14 15 16 17 18 19
@@ -864,7 +864,7 @@
 				status = "disabled";
 			};
 
-			spdif at 80054000 {
+			spdif: spdif at 80054000 {
 				reg = <0x80054000 0x2000>;
 				interrupts = <45>;
 				dmas = <&dma_apbx 2>;
@@ -872,7 +872,7 @@
 				status = "disabled";
 			};
 
-			rtc at 80056000 {
+			mxs_rtc: rtc at 80056000 {
 				compatible = "fsl,imx28-rtc", "fsl,stmp3xxx-rtc";
 				reg = <0x80056000 0x2000>;
 				interrupts = <29>;
@@ -911,7 +911,7 @@
 				status = "disabled";
 			};
 
-			timrot at 80068000 {
+			timer: timrot at 80068000 {
 				compatible = "fsl,imx28-timrot", "fsl,timrot";
 				reg = <0x80068000 0x2000>;
 				interrupts = <48 49 50 51>;
@@ -1018,7 +1018,7 @@
 			status = "disabled";
 		};
 
-		dflpt at 800c0000 {
+		dflpt: dflpt at 800c0000 {
 			reg = <0x800c0000 0x10000>;
 			status = "disabled";
 		};
@@ -1041,7 +1041,7 @@
 			status = "disabled";
 		};
 
-		switch at 800f8000 {
+		etn_switch: switch at 800f8000 {
 			reg = <0x800f8000 0x8000>;
 			status = "disabled";
 		};
-- 
1.7.2.5



From LW at KARO-electronics.de  Wed Jul 31 10:37:59 2013
From: LW at KARO-electronics.de (=?UTF-8?q?Lothar=20Wa=C3=9Fmann?=)
Date: Wed, 31 Jul 2013 16:37:59 +0200
Subject: [PATCH 9/10] ARM: dts: tx28: restructure and update DTS file
In-Reply-To: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
References: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <1375281480-25775-9-git-send-email-LW@KARO-electronics.de>


Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
---
 arch/arm/boot/dts/imx28-tx28.dts |  750 +++++++++++++++++++++++++++++++++-----
 1 files changed, 667 insertions(+), 83 deletions(-)

diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts
index 37be532..7b2e6ce 100644
--- a/arch/arm/boot/dts/imx28-tx28.dts
+++ b/arch/arm/boot/dts/imx28-tx28.dts
@@ -1,106 +1,144 @@
+/*
+ * Copyright 2013 Lothar Wa?mann <LW at KARO-electronics.de>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
 /dts-v1/;
-/include/ "imx28.dtsi"
+#include "imx28.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+#define USE_SPI_GPIO
 
 / {
 	model = "Ka-Ro electronics TX28 module";
 	compatible = "karo,tx28", "fsl,imx28";
 
+	aliases {
+		can0 = &can0;
+		can1 = &can1;
+		display = &display;
+		ds1339 = &ds1339;
+		gpio5 = &gpio5;
+		stk5led = &user_led;
+		usbotg = &usb0;
+		lcdif = &lcdif;
+		lcdif_24bit_pins_a = &lcdif_24bit_pins_a;
+		lcdif_23bit_pins_a = &lcdif_23bit_pins_a;
+	};
+
+	chosen {
+		bootargs = "init=/linuxrc console=ttyAMA0,115200 root=/dev/mtdblock3 rootfstype=jffs2 ro debug panic=1";
+	};
+
 	memory {
-		reg = <0x40000000 0x08000000>;
-	};
-
-	apb at 80000000 {
-		apbh at 80000000 {
-			ssp0: ssp at 80010000 {
-				compatible = "fsl,imx28-mmc";
-				pinctrl-names = "default";
-				pinctrl-0 = <&mmc0_4bit_pins_a
-					     &mmc0_cd_cfg
-					     &mmc0_sck_cfg>;
-				bus-width = <4>;
-				status = "okay";
-			};
+		reg = <0 0>; /* will be filled in by U-Boot */
+	};
 
-			pinctrl at 80018000 {
-				pinctrl-names = "default";
-				pinctrl-0 = <&hog_pins_a>;
-
-				hog_pins_a: hog at 0 {
-					reg = <0>;
-					fsl,pinmux-ids = <
-						0x40a3 /* MX28_PAD_ENET0_RXD3__GPIO_4_10 */
-					>;
-					fsl,drive-strength = <0>;
-					fsl,voltage = <1>;
-					fsl,pull-up = <0>;
-				};
-
-				mac0_pins_gpio: mac0-gpio-mode at 0 {
-					reg = <0>;
-					fsl,pinmux-ids = <
-						0x4003 /* MX28_PAD_ENET0_MDC__GPIO_4_0 */
-						0x4013 /* MX28_PAD_ENET0_MDIO__GPIO_4_1 */
-						0x4023 /* MX28_PAD_ENET0_RX_EN__GPIO_4_2 */
-						0x4033 /* MX28_PAD_ENET0_RXD0__GPIO_4_3 */
-						0x4043 /* MX28_PAD_ENET0_RXD1__GPIO_4_4 */
-						0x4063 /* MX28_PAD_ENET0_TX_EN__GPIO_4_6 */
-						0x4073 /* MX28_PAD_ENET0_TXD0__GPIO_4_7 */
-						0x4083 /* MX28_PAD_ENET0_TXD1__GPIO_4_8 */
-						0x4103 /* MX28_PAD_ENET_CLK__GPIO_4_16 */
-					>;
-					fsl,drive-strength = <0>;
-					fsl,voltage = <1>;
-					fsl,pull-up = <0>;
-				};
-			};
+	onewire at 0 {
+		compatible = "w1-gpio";
+		gpios = <&gpio2 7 0>;
+		status = "disabled";
+	};
+
+	regulators {
+		compatible = "simple-bus";
+
+		reg_usb0_vbus: usb0_vbus {
+			compatible = "regulator-fixed";
+			regulator-name = "usb0_vbus";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			gpio = <&gpio0 18 0>;
+			enable-active-high;
 		};
 
-		apbx at 80040000 {
-			i2c0: i2c at 80058000 {
-				pinctrl-names = "default";
-				pinctrl-0 = <&i2c0_pins_a>;
-				status = "okay";
+		reg_usb1_vbus: usb1_vbus {
+			compatible = "regulator-fixed";
+			regulator-name = "usb1_vbus";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			gpio = <&gpio3 27 0>;
+			enable-active-high;
+		};
 
-				ds1339: rtc at 68 {
-					compatible = "mxim,ds1339";
-					reg = <0x68>;
-				};
-			};
+		reg_2p5v: 2p5v {
+			compatible = "regulator-fixed";
+			regulator-name = "2P5V";
+			regulator-min-microvolt = <2500000>;
+			regulator-max-microvolt = <2500000>;
+			regulator-always-on;
+		};
 
-			pwm: pwm at 80064000 {
-				pinctrl-names = "default";
-				pinctrl-0 = <&pwm0_pins_a>;
-				status = "okay";
-			};
+		reg_3p3v: 3p3v {
+			compatible = "regulator-fixed";
+			regulator-name = "3P3V";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
 
-			duart: serial at 80074000 {
-				pinctrl-names = "default";
-				pinctrl-0 = <&duart_4pins_a>;
-				status = "okay";
-			};
+		reg_can_xcvr: can-xcvr {
+			compatible = "regulator-fixed";
+			regulator-name = "CAN XCVR";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&gpio1 0 0>;
+			enable-active-low;
+			pinctrl-names = "default";
+			pinctrl-0 = <&flexcan_xcvr_pins_a>;
+		};
 
-			auart1: serial at 8006c000 {
-				pinctrl-names = "default";
-				pinctrl-0 = <&auart1_pins_a>;
-				status = "okay";
-			};
+		reg_lcd: lcd-power {
+			compatible = "regulator-fixed";
+			regulator-name = "LCD POWER";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&gpio1 31 0>;
+			enable-active-high;
+		};
+
+		reg_lcd_reset: lcd-reset {
+			compatible = "regulator-fixed";
+			regulator-name = "LCD RESET";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&gpio3 30 0>;
+			startup-delay-us = <300000>;
+			enable-active-high;
+			regulator-always-on;
+			regulator-boot-on;
 		};
 	};
 
-	ahb at 80080000 {
-		mac0: ethernet at 800f0000 {
-			phy-mode = "rmii";
-			pinctrl-names = "default", "gpio_mode";
-			pinctrl-0 = <&mac0_pins_a>;
-			pinctrl-1 = <&mac0_pins_gpio>;
-			status = "okay";
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		mclk: codec_clock {
+			compatible = "fixed-clock";
+			reg = <0>;
+			#clock-cells = <0>;
+			clock-frequency = <27000000>;
 		};
 	};
 
+	sound {
+		compatible = "fsl,imx28-tx28-sgtl5000",
+			     "fsl,mxs-audio-sgtl5000";
+		model = "imx28-tx28-sgtl5000";
+		saif-controllers = <&saif0 &saif1>;
+		audio-codec = <&sgtl5000>;
+	};
+
 	leds {
 		compatible = "gpio-leds";
 
-		user {
+		user_led: user {
 			label = "Heartbeat";
 			gpios = <&gpio4 10 0>;
 			linux,default-trigger = "heartbeat";
@@ -109,8 +147,554 @@
 
 	backlight {
 		compatible = "pwm-backlight";
-		pwms = <&pwm 0 5000000>;
-		brightness-levels = <0 4 8 16 32 64 128 255>;
-		default-brightness-level = <6>;
+		pwms = <&pwm 0 500000>;
+		/*
+		 * a silly way to create a 1:1 relationship between the
+		 * PWM value and the actual duty cycle
+		 */
+		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
+				     10 11 12 13 14 15 16 17 18 19
+				     20 21 22 23 24 25 26 27 28 29
+				     30 31 32 33 34 35 36 37 38 39
+				     40 41 42 43 44 45 46 47 48 49
+				     50 51 52 53 54 55 56 57 58 59
+				     60 61 62 63 64 65 66 67 68 69
+				     70 71 72 73 74 75 76 77 78 79
+				     80 81 82 83 84 85 86 87 88 89
+				     90 91 92 93 94 95 96 97 98 99
+				    100>;
+		default-brightness-level = <50>;
+	};
+#ifdef USE_SPI_GPIO
+	spi {
+		compatible = "spi-gpio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi_pins_gpio>;
+
+		gpio-sck = <&gpio2 24 0>;
+		gpio-mosi = <&gpio2 25 0>;
+		gpio-miso = <&gpio2 26 0>;
+		num-chipselects = <3>;
+		cs-gpios = <
+			&gpio3 8 1
+			&gpio3 9 1
+			&gpio2 27 1
+		>;
+
+		spidev0: spi at 0 {
+			compatible = "spidev";
+			reg = <0>;
+			spi-max-frequency = <57600000>;
+		};
+
+		spidev1: spi at 1 {
+			compatible = "spidev";
+			reg = <1>;
+			spi-max-frequency = <57600000>;
+		};
+
+		spidev2: spi at 2 {
+			compatible = "spidev";
+			reg = <2>;
+			spi-max-frequency = <57600000>;
+		};
 	};
+#endif
+	matrix_keypad: matrix-keypad at 0 {
+		compatible = "gpio-matrix-keypad";
+		col-gpios = <
+			&gpio5 0 0
+			&gpio5 1 0
+			&gpio5 2 0
+			&gpio5 3 0
+		>;
+
+		row-gpios = <
+			&gpio5 4 0
+			&gpio5 5 0
+			&gpio5 6 0
+			&gpio5 7 0
+		>;
+
+		/* sample keymap */
+		linux,keymap = <
+			0x00000074 /* row 0, col 0, KEY_POWER */
+			0x00010052 /* row 0, col 1, KEY_KP0 */
+			0x0002004f /* row 0, col 2, KEY_KP1 */
+			0x00030050 /* row 0, col 3, KEY_KP2 */
+			0x01000051 /* row 1, col 0, KEY_KP3 */
+			0x0101004b /* row 1, col 1, KEY_KP4 */
+			0x0102004c /* row 1, col 2, KEY_KP5 */
+			0x0103004d /* row 1, col 3, KEY_KP6 */
+			0x02000047 /* row 2, col 0, KEY_KP7 */
+			0x02010048 /* row 2, col 1, KEY_KP8 */
+			0x02020049 /* row 2, col 2, KEY_KP9 */
+		>;
+		gpio-activelow;
+		linux,wakeup;
+
+		debounce-delay-ms = <100>;
+		col-scan-delay-us = <5000>;
+		linux,no-autorepeat;
+	};
+};
+
+/* 2nd TX-Std UART - (A)UART1  */
+&auart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&auart1_pins_a>;
+	status = "okay";
+};
+
+/* 3rd TX-Std UART - (A)UART3  */
+&auart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&auart3_pins_a>;
+	status = "okay";
+};
+
+&can0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&can0_pins_a>;
+	xceiver-supply = <&reg_can_xcvr>;
+	status = "okay";
+};
+
+&can1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&can1_pins_a>;
+	xceiver-supply = <&reg_can_xcvr>;
+	status = "okay";
+};
+
+&digctl {
+	status = "okay";
+};
+
+/* 1st TX-Std UART - (D)UART */
+&duart {
+	pinctrl-names = "default";
+	pinctrl-0 = <&duart_4pins_a>;
+	status = "okay";
+};
+
+&gpmi {
+	pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg>;
+	nand-on-flash-bbt;
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins_a>;
+	clock-frequency = <400000>;
+	status = "okay";
+
+	ds1339: rtc at 68 {
+		compatible = "mxim,ds1339";
+		reg = <0x68>;
+	};
+
+	gpio5: pca953x at 20 {
+		compatible = "nxp,pca9554";
+		reg = <0x20>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pca9554_pins>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <28 0>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	touchscreen: tsc2007 at 48 {
+		compatible = "ti,tsc2007";
+		reg = <0x48>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&tsc2007_pins>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <20 0>;
+		pendown-gpio = <&gpio3 20 1>;
+		ti,x-plate-ohms = <660>;
+	};
+
+	polytouch: edt-ft5x06 at 38 {
+		compatible = "edt,edt-ft5x06";
+		reg = <0x38>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&edt_ft5x06_pins>;
+		interrupt-parent = <&gpio2>;
+		interrupts = <5 0>;
+		reset-gpios = <&gpio2 6 1>;
+		wake-gpios = <&gpio4 9 0>;
+	};
+
+	sgtl5000: sgtl5000 at 0a {
+		compatible = "fsl,sgtl5000";
+		reg = <0x0a>;
+		VDDA-supply = <&reg_2p5v>;
+		VDDIO-supply = <&reg_3p3v>;
+		clocks = <&mclk>;
+	};
+};
+
+&lcdif {
+	pinctrl-names = "default";
+	pinctrl-0 = <&lcdif_24bit_pins_a &lcdif_sync_pins_a &lcdif_ctrl_pins_a>;
+	lcd-supply = <&reg_lcd>;
+	display = <&display>;
+	status = "okay";
+
+	display: display at 0 {
+		bits-per-pixel = <32>;
+		bus-width = <24>;
+
+		display-timings {
+			native-mode = <&timing5>;
+			timing0: timing0 {
+				panel-name = "VGA";
+				clock-frequency = <25175000>;
+				hactive = <640>;
+				vactive = <480>;
+				hback-porch = <48>;
+				hsync-len = <96>;
+				hfront-porch = <16>;
+				vback-porch = <33>;
+				vsync-len = <2>;
+				vfront-porch = <10>;
+				hsync-active = <0>;
+				vsync-active = <0>;
+				de-active = <1>;
+				pixelclk-active = <1>;
+			};
+
+			timing1: timing1 {
+				panel-name = "ETV570";
+				clock-frequency = <25175000>;
+				hactive = <640>;
+				vactive = <480>;
+				hback-porch = <114>;
+				hsync-len = <30>;
+				hfront-porch = <16>;
+				vback-porch = <32>;
+				vsync-len = <3>;
+				vfront-porch = <10>;
+				hsync-active = <0>;
+				vsync-active = <0>;
+				de-active = <1>;
+				pixelclk-active = <1>;
+			};
+
+			timing2: timing2 {
+				panel-name = "ET0350";
+				clock-frequency = <6500000>;
+				hactive = <320>;
+				vactive = <240>;
+				hback-porch = <34>;
+				hsync-len = <34>;
+				hfront-porch = <20>;
+				vback-porch = <15>;
+				vsync-len = <3>;
+				vfront-porch = <4>;
+				hsync-active = <0>;
+				vsync-active = <0>;
+				de-active = <1>;
+				pixelclk-active = <1>;
+			};
+
+			timing3: timing3 {
+				panel-name = "ET0430";
+				clock-frequency = <9000000>;
+				hactive = <480>;
+				vactive = <272>;
+				hback-porch = <2>;
+				hsync-len = <41>;
+				hfront-porch = <2>;
+				vback-porch = <2>;
+				vsync-len = <10>;
+				vfront-porch = <2>;
+				hsync-active = <0>;
+				vsync-active = <0>;
+				de-active = <1>;
+				pixelclk-active = <1>;
+			};
+
+			timing4: timing4 {
+				panel-name = "ET0500", "ET0700";
+				clock-frequency = <33260000>;
+				hactive = <800>;
+				vactive = <480>;
+				hback-porch = <88>;
+				hsync-len = <128>;
+				hfront-porch = <40>;
+				vback-porch = <33>;
+				vsync-len = <2>;
+				vfront-porch = <10>;
+				hsync-active = <0>;
+				vsync-active = <0>;
+				de-active = <1>;
+				pixelclk-active = <1>;
+			};
+
+			timing5: timing5 {
+				panel-name = "ETQ570";
+				clock-frequency = <6400000>;
+				hactive = <320>;
+				vactive = <240>;
+				hback-porch = <38>;
+				hsync-len = <30>;
+				hfront-porch = <30>;
+				vback-porch = <16>;
+				vsync-len = <3>;
+				vfront-porch = <4>;
+				hsync-active = <0>;
+				vsync-active = <0>;
+				de-active = <1>;
+				pixelclk-active = <1>;
+			};
+        	};
+	};
+};
+
+&lradc {
+	fsl,lradc-touchscreen-wires = <4>;
+	status = "okay";
+};
+
+&mac0 {
+	phy-mode = "rmii";
+	pinctrl-names = "default", "gpio_mode";
+	pinctrl-0 = <&mac0_pins_a>;
+	pinctrl-1 = <&mac0_pins_gpio>;
+	status = "okay";
+};
+
+&mac1 {
+	phy-mode = "rmii";
+	pinctrl-names = "default";
+	pinctrl-0 = <&mac1_pins_a>;
+	/* not enabled by default */
+};
+
+&mxs_rtc {
+	status = "okay";
+};
+
+&ocotp {
+	status = "okay";
+};
+
+&pwm {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm0_pins_a>;
+	status = "okay";
+};
+
+&pinctrl {
+	pinctrl-names = "default";
+	pinctrl-0 = <&hog_pins_a>;
+	edt_ft5x06_pins: edt-ft5x06-pins at 0 {
+		reg = <0>;
+		fsl,pinmux-ids = <
+			0x2063 /* MX28_PAD_SSP0_DATA6__GPIO_2_6	RESET */
+			0x2053 /* MX28_PAD_SSP0_DATA5__GPIO_2_5 IRQ */
+			0x4093 /* MX28_PAD_ENET0_RXD2__GPIO_4_9 WAKE */
+		>;
+		fsl,drive-strength = <0>;
+		fsl,voltage = <1>;
+		fsl,pull-up = <0>;
+	};
+
+	flexcan_xcvr_pins_a: flexcan-xcvr {
+		reg = <0>;
+		fsl,pinmux-ids = <
+			0x1003 /* MX28_PAD_LCD_D00__GPIO_1_0 */
+		>;
+		fsl,drive-strength = <0>;
+		fsl,voltage = <1>;
+		fsl,pull-up = <0>;
+	};
+
+	hog_pins_a: hog at 0 {
+		reg = <0>;
+		fsl,pinmux-ids = <
+			0x40a3 /* MX28_PAD_ENET0_RXD3__GPIO_4_10 - module LED */
+		>;
+		fsl,drive-strength = <0>;
+		fsl,voltage = <1>;
+		fsl,pull-up = <0>;
+	};
+
+	lcdif_23bit_pins_a: lcdif-23bit at 0 {
+		reg = <0>;
+		fsl,pinmux-ids = <
+			/* LCD_D00 may be used as Flexcan Transceiver Enable on STK5-V5 */
+			0x1010 /* MX28_PAD_LCD_D01__LCD_D1 */
+			0x1020 /* MX28_PAD_LCD_D02__LCD_D2 */
+			0x1030 /* MX28_PAD_LCD_D03__LCD_D3 */
+			0x1040 /* MX28_PAD_LCD_D04__LCD_D4 */
+			0x1050 /* MX28_PAD_LCD_D05__LCD_D5 */
+			0x1060 /* MX28_PAD_LCD_D06__LCD_D6 */
+			0x1070 /* MX28_PAD_LCD_D07__LCD_D7 */
+			0x1080 /* MX28_PAD_LCD_D08__LCD_D8 */
+			0x1090 /* MX28_PAD_LCD_D09__LCD_D9 */
+			0x10a0 /* MX28_PAD_LCD_D10__LCD_D10 */
+			0x10b0 /* MX28_PAD_LCD_D11__LCD_D11 */
+			0x10c0 /* MX28_PAD_LCD_D12__LCD_D12 */
+			0x10d0 /* MX28_PAD_LCD_D13__LCD_D13 */
+			0x10e0 /* MX28_PAD_LCD_D14__LCD_D14 */
+			0x10f0 /* MX28_PAD_LCD_D15__LCD_D15 */
+			0x1100 /* MX28_PAD_LCD_D16__LCD_D16 */
+			0x1110 /* MX28_PAD_LCD_D17__LCD_D17 */
+			0x1120 /* MX28_PAD_LCD_D18__LCD_D18 */
+			0x1130 /* MX28_PAD_LCD_D19__LCD_D19 */
+			0x1140 /* MX28_PAD_LCD_D20__LCD_D20 */
+			0x1150 /* MX28_PAD_LCD_D21__LCD_D21 */
+			0x1160 /* MX28_PAD_LCD_D22__LCD_D22 */
+			0x1170 /* MX28_PAD_LCD_D23__LCD_D23 */
+		>;
+		fsl,drive-strength = <0>;
+		fsl,voltage = <1>;
+		fsl,pull-up = <0>;
+	};
+
+	lcdif_ctrl_pins_a: lcdif-ctrl at 0 {
+		reg = <0>;
+		fsl,pinmux-ids = <
+			0x11f3	/* MX28_PAD_LCD_ENABLE__GPIO_1_31 - Enable */
+			0x31e3	/* MX28_PAD_LCD_RESET__GPIO_3_30 - Reset */
+		>;
+		fsl,drive-strength = <0>;
+		fsl,voltage = <1>;
+		fsl,pull-up = <0>;
+	};
+
+	mac0_pins_gpio: mac0-gpio-mode at 0 {
+		reg = <0>;
+		fsl,pinmux-ids = <
+			0x4003 /* MX28_PAD_ENET0_MDC__GPIO_4_0 */
+			0x4013 /* MX28_PAD_ENET0_MDIO__GPIO_4_1 */
+			0x4023 /* MX28_PAD_ENET0_RX_EN__GPIO_4_2 */
+			0x4033 /* MX28_PAD_ENET0_RXD0__GPIO_4_3 */
+			0x4043 /* MX28_PAD_ENET0_RXD1__GPIO_4_4 */
+			0x4063 /* MX28_PAD_ENET0_TX_EN__GPIO_4_6 */
+			0x4073 /* MX28_PAD_ENET0_TXD0__GPIO_4_7 */
+			0x4083 /* MX28_PAD_ENET0_TXD1__GPIO_4_8 */
+			0x4103 /* MX28_PAD_ENET_CLK__GPIO_4_16 */
+		>;
+		fsl,drive-strength = <0>;
+		fsl,voltage = <1>;
+		fsl,pull-up = <0>;
+	};
+
+	pca9554_pins: pca9554-pins at 0 {
+		reg = <0>;
+		fsl,pinmux-ids = <
+			0x31c3 /* MX28_PAD_PWM3__GPIO_3_28 IRQ */
+		>;
+		fsl,drive-strength = <0>;
+		fsl,voltage = <1>;
+		fsl,pull-up = <0>;
+	};
+
+	spi_pins_gpio: spi at 0 {
+		reg = <0>;
+		fsl,pinmux-ids = <
+			0x3083	/* MX28_PAD_AUART2_RX__GPIO_3_8 SS0 */
+			0x3093	/* MX28_PAD_AUART2_TX__GPIO_3_9 SS1 */
+			0x2183	/* MX28_PAD_SSP3_SCK__GPIO_2_24 SCK */
+			0x2193	/* MX28_PAD_SSP3_MOSI__GPIO_2_25 MOSI */
+			0x21A3	/* MX28_PAD_SSP3_MISO__GPIO_2_26 MISO */
+			0x21B3	/* MX28_PAD_SSP3_SS0__GPIO_2_27 SS2 */
+		>;
+		fsl,drive-strength = <1>;
+		fsl,voltage = <1>;
+		fsl,pull-up = <0>;
+	};
+
+	tsc2007_pins: tsc2007-pins at 0 {
+		reg = <0>;
+		fsl,pinmux-ids = <
+			0x3143 /* MX28_PAD_SAIF0_MCLK__GPIO_3_20 - TSC2007 IRQ */
+		>;
+		fsl,drive-strength = <0>;
+		fsl,voltage = <1>;
+		fsl,pull-up = <0>;
+	};
+};
+
+&saif0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&saif0_pins_b>;
+	fsl,saif-master;
+	status = "okay";
+};
+
+&saif1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&saif1_pins_a>;
+	status = "okay";
+};
+
+&ssp0 {
+	compatible = "fsl,imx28-mmc";
+	pinctrl-names = "default", "special";
+	pinctrl-0 = <&mmc0_4bit_pins_a
+		     &mmc0_cd_cfg
+		     &mmc0_sck_cfg>;
+	bus-width = <4>;
+	status = "okay";
+};
+#ifndef USE_SPI_GPIO
+&ssp3 {
+	compatible = "fsl,imx28-spi";
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi3_pins_a>;
+	clock-frequency = <57600000>;
+	status = "okay";
+
+	spidev0: spi at 0 {
+		compatible = "spidev";
+		reg = <0>;
+		spi-max-frequency = <57600000>;
+	};
+
+	spidev1: spi at 1 {
+		compatible = "spidev";
+		reg = <1>;
+		spi-max-frequency = <57600000>;
+	};
+};
+#endif
+&timer {
+	status = "okay";
+};
+
+&usb0 {
+	vbus-supply = <&reg_usb0_vbus>;
+	disable-over-current;
+	dr_mode = "peripheral";
+	status = "okay";
+};
+
+&usb1 {
+	vbus-supply = <&reg_usb1_vbus>;
+	disable-over-current;
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usbphy0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usbphy0_pins_c>;
+	status = "okay";
+};
+
+&usbphy1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usbphy1_pins_b>;
+	status = "okay";
 };
-- 
1.7.2.5



From LW at KARO-electronics.de  Wed Jul 31 10:37:56 2013
From: LW at KARO-electronics.de (=?UTF-8?q?Lothar=20Wa=C3=9Fmann?=)
Date: Wed, 31 Jul 2013 16:37:56 +0200
Subject: [PATCH 6/10] ARM: dts: mxs: add pin config for LCD sync and clock pins
In-Reply-To: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
References: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <1375281480-25775-6-git-send-email-LW@KARO-electronics.de>


Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
---
 arch/arm/boot/dts/imx28.dtsi |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index f597c0f..284166a9 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -648,6 +648,19 @@
 					fsl,pull-up = <0>;
 				};
 
+				lcdif_sync_pins_a: lcdif-sync at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x11a1 /* MX28_PAD_LCD_RS__LCD_DOTCLK */
+						0x11b1 /* MX28_PAD_LCD_CS__LCD_ENABLE */
+						0x1181 /* MX28_PAD_LCD_RD_E__LCD_VSYNC */
+						0x1191 /* MX28_PAD_LCD_WR_RWN__LCD_HSYNC */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+
 				can0_pins_a: can0 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-- 
1.7.2.5



From t-kristo at ti.com  Wed Jul 31 10:45:33 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 17:45:33 +0300
Subject: [PATCHv4 07/33] CLK: omap: add support for OMAP gate clock
In-Reply-To: <51F81148.4080203@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-8-git-send-email-t-kristo@ti.com> <51F81148.4080203@ti.com>
Message-ID: <51F9230D.4020708@ti.com>

On 07/30/2013 10:17 PM, Nishanth Menon wrote:
> On 07/23/2013 02:20 AM, Tero Kristo wrote:
>> This node adds support for a clock node which allows control to the
>> clockdomain enable / disable.
>
> Dont we have clkdm_enable/disable for the same? should we model
> clockdomain as a clock node?

There was some discussion about having clockdomain code under 
drivers/clk while back, but Mike turned this idea down.

>
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> ---
>>   drivers/clk/omap/Makefile |    2 +-
>>   drivers/clk/omap/clk.c    |    1 +
>>   drivers/clk/omap/gate.c   |   88
>> +++++++++++++++++++++++++++++++++++++++++++++
>>   include/linux/clk/omap.h  |    1 +
>>   4 files changed, 91 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/clk/omap/gate.c
>>
>
> my usual crib: device tree binding documentation is missing
>
>> diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
>> index ca56700..3d3ca30f 100644
>> --- a/drivers/clk/omap/Makefile
>> +++ b/drivers/clk/omap/Makefile
>> @@ -1 +1 @@
>> -obj-y                    += clk.o dpll.o autoidle.o
>> +obj-y                    += clk.o dpll.o autoidle.o gate.o
>> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
>> index c149097..8c89714 100644
>> --- a/drivers/clk/omap/clk.c
>> +++ b/drivers/clk/omap/clk.c
>> @@ -29,6 +29,7 @@ static const struct of_device_id clk_match[] = {
>>       {.compatible = "divider-clock", .data = of_omap_divider_setup, },
>>       {.compatible = "gate-clock", .data = of_gate_clk_setup, },
>>       {.compatible = "ti,omap4-dpll-clock", .data =
>> of_omap4_dpll_setup, },
>> +    {.compatible = "ti,gate-clock", .data = of_omap_gate_clk_setup, },
>
> I am a little lost - is there any SoC dts that actually uses this? at
> least this series does not seem to introduce any node that uses this
> compatibility as per git grep :(

There is, see patch 08/33 or 28/33.

>
> might as well drop the patch?
>
>>       {},
>>   };
>>
>> diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
>> new file mode 100644
>> index 0000000..7186bb2
>> --- /dev/null
>> +++ b/drivers/clk/omap/gate.c
>> @@ -0,0 +1,88 @@
>> +/*
>> + * OMAP gate clock support
>> + *
>> + * Copyright (C) 2013 Texas Instruments, Inc.
>> + *
>> + * Tero Kristo <t-kristo at ti.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/clk-provider.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/io.h>
>> +#include <linux/err.h>
>> +#include <linux/string.h>
>> +#include <linux/log2.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/clk/omap.h>
>> +
>> +#ifdef CONFIG_OF
>> +
>> +static const struct clk_ops omap_gate_clk_ops = {
>> +    .init        = &omap2_init_clk_clkdm,
>> +    .enable        = &omap2_clkops_enable_clkdm,
>> +    .disable    = &omap2_clkops_disable_clkdm,
>> +};
>> +
>> +void __init of_omap_gate_clk_setup(struct device_node *node)
>> +{
>> +    struct clk *clk;
>> +    struct clk_init_data init;
> init = { 0 };

Will add.

>> +    struct clk_hw_omap *clk_hw;
>> +    const char *clk_name = node->name;
>> +    int num_parents;
>> +    const char **parent_names;
>> +    int i;
>> +
>> +    clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
> kzalloc(sizeof(*clk_hw)...) over kzalloc(sizeof(struct clk_hw_omap)...)
>
>> +    if (!clk_hw) {
>> +        pr_err("%s: could not allocate clk_hw_omap\n", __func__);
>> +        return;
>> +    }
>> +
>> +    clk_hw->hw.init = &init;
>> +
>> +    of_property_read_string(node, "clock-output-names", &clk_name);
>> +    of_property_read_string(node, "ti,clkdm-name", &clk_hw->clkdm_name);
>> +
>> +    init.name = clk_name;
>> +    init.ops = &omap_gate_clk_ops;
>> +
>> +    num_parents = of_clk_get_parent_count(node);
>> +    if (num_parents < 1) {
>> +        pr_err("%s: omap trace_clk %s must have parent(s)\n",
>> +            __func__, node->name);
> CHECK: Alignment should match open parenthesis

I still wonder which version of checkpatch you are using.

>
>> +        goto cleanup;
>> +    }
>> +
>> +    parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
>> +
>> +    for (i = 0; i < num_parents; i++)
>> +        parent_names[i] = of_clk_get_parent_name(node, i);
>> +
>> +    init.num_parents = num_parents;
>> +    init.parent_names = parent_names;
>> +
>> +    clk = clk_register(NULL, &clk_hw->hw);
>> +
>> +    if (!IS_ERR(clk)) {
>> +        of_clk_add_provider(node, of_clk_src_simple_get, clk);
>> +        return;
>> +    }
>> +
>> +cleanup:
> kfree(parent_names)?

Yea, will add.

>> +    kfree(clk_hw);
>> +}
>> +EXPORT_SYMBOL(of_omap_gate_clk_setup);
>> +CLK_OF_DECLARE(omap_gate_clk, "ti,omap-gate-clock",
>> of_omap_gate_clk_setup);
>> +#endif
>> diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
>> index 904bdad..58ebb80 100644
>> --- a/include/linux/clk/omap.h
>> +++ b/include/linux/clk/omap.h
>> @@ -194,6 +194,7 @@ extern void omap_dt_clocks_register(struct
>> omap_dt_clk *oclks, int cnt);
>>   void of_omap4_dpll_setup(struct device_node *node);
>>   void of_omap_fixed_factor_setup(struct device_node *node);
>>   void of_omap_divider_setup(struct device_node *node);
>> +void of_omap_gate_clk_setup(struct device_node *node);
> dont need to export I think if we use strategy mentioned previously.

So, we actually had an offline chat with Nishanth, and I will modify the 
init setup like previously suggested by him.

>
>>   void of_omap_clk_allow_autoidle_all(void);
>>   void of_omap_clk_deny_autoidle_all(void);
>>
>>
>
>



From t-kristo at ti.com  Wed Jul 31 10:49:28 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 17:49:28 +0300
Subject: [PATCHv4 08/33] ARM: dts: omap4 clock data
In-Reply-To: <51F813B3.7020000@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-9-git-send-email-t-kristo@ti.com> <51F813B3.7020000@ti.com>
Message-ID: <51F923F8.6080700@ti.com>

On 07/30/2013 10:27 PM, Nishanth Menon wrote:
> On 07/23/2013 02:20 AM, Tero Kristo wrote:
>> This patch creates a unique node for each clock in the OMAP4 power,
>> reset and clock manager (PRCM). OMAP443x and OMAP446x have slightly
>> different clock tree which is taken into account in the data.
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> ---
>>   arch/arm/boot/dts/omap443x-clocks.dtsi |   17 +
>>   arch/arm/boot/dts/omap443x.dtsi        |    8 +
>>   arch/arm/boot/dts/omap4460.dtsi        |    8 +
>>   arch/arm/boot/dts/omap446x-clocks.dtsi |   27 +
>>   arch/arm/boot/dts/omap44xx-clocks.dtsi | 1654
>> ++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/omap44xx-common-clocks.dtsi ?
>>   5 files changed, 1714 insertions(+)
>>   create mode 100644 arch/arm/boot/dts/omap443x-clocks.dtsi
>>   create mode 100644 arch/arm/boot/dts/omap446x-clocks.dtsi
>>   create mode 100644 arch/arm/boot/dts/omap44xx-clocks.dtsi
>>
>> diff --git a/arch/arm/boot/dts/omap443x-clocks.dtsi
>> b/arch/arm/boot/dts/omap443x-clocks.dtsi
>> new file mode 100644
>> index 0000000..2bd82b2
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/omap443x-clocks.dtsi
>> @@ -0,0 +1,17 @@
>> +/*
>> + * Device Tree Source for OMAP443x clock data
>> + *
>> + * Copyright (C) 2013 Texas Instruments, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
> Doing
> /include/ "omap44xx-clocks.dtsi" might avoid including that header in
> corresponding SoC dtsi,
> OR:
>> +bandgap_fclk: bandgap_fclk at 4a307888 {
>> +    #clock-cells = <0>;
>> +    compatible = "gate-clock";
>> +    clocks = <&sys_32k_ck>;
>> +    bit-shift = <8>;
>> +    reg = <0x4a307888 0x4>;
>> +};
>
> Since we already have omap443x.dtsi and omap446x.dtsi, do we need
> clock.dtsi containing just a few entries?
> instead we could define the delta clocks in the clocks section, and save
> on two additional files, no?

Yea, thats also possible. I didn't want to put clock nodes there though, 
just for clarity. I think this is for whoever is maintaining the DTS 
files to answer.

>
> [...]
>
>> diff --git a/arch/arm/boot/dts/omap44xx-clocks.dtsi
>> b/arch/arm/boot/dts/omap44xx-clocks.dtsi
>> new file mode 100644
>> index 0000000..ed6bc9b
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/omap44xx-clocks.dtsi
> [...]
>
>> +dpll_abe_m2x2_ck: dpll_abe_m2x2_ck at 4a0041f0 {
>> +    #clock-cells = <0>;
>> +    compatible = "divider-clock";
>> +    clocks = <&dpll_abe_x2_ck>;
>> +    ti,autoidle-shift = <8>;
>> +    reg = <0x4a0041f0 0x4>;
>> +    bit-mask = <0x1f>;
>> +    index-starts-at-one;
>> +    ti,autoidle-low;
>> +};
>> +
>> +abe_24m_fclk: abe_24m_fclk {
>> +    #clock-cells = <0>;
>> +    compatible = "fixed-factor-clock";
>> +    clocks = <&dpll_abe_m2x2_ck>;
>> +    clock-mult = <1>;
>> +    clock-div = <8>;
>> +};
>> +
>> +abe_clk: abe_clk at 4a004108 {
>> +    #clock-cells = <0>;
>> +    compatible = "divider-clock";
>> +    clocks = <&dpll_abe_m2x2_ck>;
>> +    reg = <0x4a004108 0x4>;
>> +    bit-mask = <0x3>;
>> +    index-power-of-two;
>> +};
>> +
>> +aess_fclk: aess_fclk at 4a004528 {
> is there a naming convention used here? abe_clk, fclk etc?

The clock names are directly converted from existing data, so whatever 
currently is there, will be in the DT also.

>
>> +    #clock-cells = <0>;
>> +    compatible = "divider-clock";
>> +    clocks = <&abe_clk>;
>> +    bit-shift = <24>;
>> +    reg = <0x4a004528 0x4>;
>> +    bit-mask = <0x1>;
>> +};
>
> [...]
>
>> +
>> +ocp2scp_usb_phy_phy_48m: ocp2scp_usb_phy_phy_48m at 4a0093e0 {
> _ck?
>
> [...]
>
>



From t-kristo at ti.com  Wed Jul 31 10:52:58 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 17:52:58 +0300
Subject: [PATCHv4 09/33] CLK: omap: add omap4 clock init file
In-Reply-To: <51F81516.3050302@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-10-git-send-email-t-kristo@ti.com>
 <51F81516.3050302@ti.com>
Message-ID: <51F924CA.6000803@ti.com>

On 07/30/2013 10:33 PM, Nishanth Menon wrote:
> On 07/23/2013 02:20 AM, Tero Kristo wrote:
>> clk-44xx.c now contains the clock init functionality for omap4, including
>> DT clock registration and adding of static clkdev entries.
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> ---
>>   drivers/clk/omap/clk-44xx.c |  118
>> +++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 118 insertions(+)
>>   create mode 100644 drivers/clk/omap/clk-44xx.c
>>
>> diff --git a/drivers/clk/omap/clk-44xx.c b/drivers/clk/omap/clk-44xx.c
>> new file mode 100644
>> index 0000000..cc12134
>> --- /dev/null
>> +++ b/drivers/clk/omap/clk-44xx.c
>> @@ -0,0 +1,118 @@
>> +/*
>> + * OMAP4 Clock data
>> + *
>> + * Copyright (C) 2009-2012 Texas Instruments, Inc.
>> + * Copyright (C) 2009-2010 Nokia Corporation
>> + *
>> + * Paul Walmsley (paul at pwsan.com)
>> + * Rajendra Nayak (rnayak at ti.com)
>> + * Benoit Cousson (b-cousson at ti.com)
>> + * Mike Turquette (mturquette at ti.com)
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * XXX Some of the ES1 clocks have been removed/changed; once support
>> + * is added for discriminating clocks by ES level, these should be
>> added back
>> + * in.
>> + *
>> + * XXX All of the remaining MODULEMODE clock nodes should be removed
>> + * once the drivers are updated to use pm_runtime or to use the
>> appropriate
>> + * upstream clock node for rate/parent selection.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/list.h>
>> +#include <linux/clk-private.h>
>> +#include <linux/clkdev.h>
>> +#include <linux/io.h>
>> +#include <linux/clk/omap.h>
>> +
>> +/*
>> + * OMAP4 ABE DPLL default frequency. In OMAP4460 TRM version V, section
>> + * "3.6.3.2.3 CM1_ABE Clock Generator" states that the "DPLL_ABE_X2_CLK
>> + * must be set to 196.608 MHz" and hence, the DPLL locked frequency is
>> + * half of this value.
>> + */
>> +#define OMAP4_DPLL_ABE_DEFFREQ                98304000
>> +
>> +/*
>> + * OMAP4 USB DPLL default frequency. In OMAP4430 TRM version V, section
>> + * "3.6.3.9.5 DPLL_USB Preferred Settings" shows that the preferred
>> + * locked frequency for the USB DPLL is 960MHz.
>> + */
>> +#define OMAP4_DPLL_USB_DEFFREQ                960000000
>> +
>> +static struct omap_dt_clk omap44xx_clks[] = {
>> +    DT_CLK("smp_twd",    NULL,            "mpu_periphclk"),
>> +    DT_CLK("omapdss_dss", "ick", "dss_fck"),
>> +    DT_CLK("usbhs_omap", "fs_fck", "usb_host_fs_fck"),
>> +    DT_CLK("usbhs_omap", "hs_fck", "usb_host_hs_fck"),
>> +    DT_CLK("usbhs_omap", "usbtll_ick", "usb_tll_hs_ick"),
>> +    DT_CLK("usbhs_tll", "usbtll_ick", "usb_tll_hs_ick"),
>> +    DT_CLK(NULL,    "timer_32k_ck",    "sys_32k_ck"),
>> +    /* TODO: Remove "omap_timer.X" aliases once DT migration is
>> complete */
>> +    DT_CLK("omap_timer.1",    "timer_sys_ck",    "sys_clkin_ck"),
>> +    DT_CLK("omap_timer.2",    "timer_sys_ck",    "sys_clkin_ck"),
>> +    DT_CLK("omap_timer.3",    "timer_sys_ck",    "sys_clkin_ck"),
>> +    DT_CLK("omap_timer.4",    "timer_sys_ck",    "sys_clkin_ck"),
>> +    DT_CLK("omap_timer.9",    "timer_sys_ck",    "sys_clkin_ck"),
>> +    DT_CLK("omap_timer.10",    "timer_sys_ck",    "sys_clkin_ck"),
>> +    DT_CLK("omap_timer.11",    "timer_sys_ck",    "sys_clkin_ck"),
>> +    DT_CLK("omap_timer.5",    "timer_sys_ck",    "syc_clk_div_ck"),
>> +    DT_CLK("omap_timer.6",    "timer_sys_ck",    "syc_clk_div_ck"),
>> +    DT_CLK("omap_timer.7",    "timer_sys_ck",    "syc_clk_div_ck"),
>> +    DT_CLK("omap_timer.8",    "timer_sys_ck",    "syc_clk_div_ck"),
>> +    DT_CLK("4a318000.timer",    "timer_sys_ck",    "sys_clkin_ck"),
>> +    DT_CLK("48032000.timer",    "timer_sys_ck",    "sys_clkin_ck"),
>> +    DT_CLK("48034000.timer",    "timer_sys_ck",    "sys_clkin_ck"),
>> +    DT_CLK("48036000.timer",    "timer_sys_ck",    "sys_clkin_ck"),
>> +    DT_CLK("4803e000.timer",    "timer_sys_ck",    "sys_clkin_ck"),
>> +    DT_CLK("48086000.timer",    "timer_sys_ck",    "sys_clkin_ck"),
>> +    DT_CLK("48088000.timer",    "timer_sys_ck",    "sys_clkin_ck"),
>> +    DT_CLK("40138000.timer",    "timer_sys_ck",    "syc_clk_div_ck"),
>> +    DT_CLK("4013a000.timer",    "timer_sys_ck",    "syc_clk_div_ck"),
>> +    DT_CLK("4013c000.timer",    "timer_sys_ck",    "syc_clk_div_ck"),
>> +    DT_CLK("4013e000.timer",    "timer_sys_ck",    "syc_clk_div_ck"),
>
>> +    DT_CLK(NULL,    "cpufreq_ck",    "dpll_mpu_ck"),
> please remove cpufreq.

Hmm why?

Because cpufreq is completely broken now and your current work on it? :)

>
>> +};
>> +
>> +int __init omap4xxx_clk_init(void)
>> +{
>> +    int rc;
>> +    struct clk *abe_dpll_ref, *abe_dpll, *sys_32k_ck, *usb_dpll;
>> +
>> +    /* FIXME register clocks from DT first */
>> +    dt_omap_clk_init();
>> +
>> +    omap_dt_clocks_register(omap44xx_clks, ARRAY_SIZE(omap44xx_clks));
>> +
>> +    omap2_clk_disable_autoidle_all();
>> +
>> +    /*
>> +     * On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
>> +     * state when turning the ABE clock domain. Workaround this by
>> +     * locking the ABE DPLL on boot.
>> +     * Lock the ABE DPLL in any case to avoid issues with audio.
>> +     */
>
> But this code will be called for 4430 and 4460. if the requirement is
> only for 4460, then we are not adhering to the spec?

This is copy pasted from existing cclock44xx_data.c file init function.

>
>> +    abe_dpll_ref = clk_get_sys(NULL, "abe_dpll_refclk_mux_ck");
>> +    sys_32k_ck = clk_get_sys(NULL, "sys_32k_ck");
>> +    rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
>> +    abe_dpll = clk_get_sys(NULL, "dpll_abe_ck");
>> +    if (!rc)
>> +        rc = clk_set_rate(abe_dpll, OMAP4_DPLL_ABE_DEFFREQ);
>> +    if (rc)
>> +        pr_err("%s: failed to configure ABE DPLL!\n", __func__);
>> +
>> +    /*
>> +     * Lock USB DPLL on OMAP4 devices so that the L3INIT power
>> +     * domain can transition to retention state when not in use.
>> +     */
>> +    usb_dpll = clk_get_sys(NULL, "dpll_usb_ck");
>> +    rc = clk_set_rate(usb_dpll, OMAP4_DPLL_USB_DEFFREQ);
>> +    if (rc)
>> +        pr_err("%s: failed to configure USB DPLL!\n", __func__);
>
> ^^^^ why cant we have a generic property that does this "automagically"
> from dts property to the node?
> a) be able to select a parent
> b) be able to set a frequency.
> c) how do we ensure that CLK_SET_RATE_PARENT are setup for the clock
> nodes defined by dt?

This is probably for Mike to answer, currently such mechanism does not 
exist.

>
>> +
>> +    return 0;
>> +}
>>
>
>



From t-kristo at ti.com  Wed Jul 31 10:55:47 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 17:55:47 +0300
Subject: [PATCHv4 10/33] ARM: OMAP4: remove old clock data and link in
 new clock init code
In-Reply-To: <51F81729.5010406@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-11-git-send-email-t-kristo@ti.com>
 <51F81729.5010406@ti.com>
Message-ID: <51F92573.7070109@ti.com>

On 07/30/2013 10:42 PM, Nishanth Menon wrote:
> On 07/23/2013 02:20 AM, Tero Kristo wrote:
>
>> diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
>> b/arch/arm/mach-omap2/cclock44xx_data.c
>> deleted file mode 100644
>> index 88e37a4..0000000
>> --- a/arch/arm/mach-omap2/cclock44xx_data.c
>> +++ /dev/null
> [...]
>> -
>> -int __init omap4xxx_clk_init(void)
>> -{
> arch/arm/mach-omap2/clock44xx.h:int omap4xxx_clk_init(void);
> arch/arm/mach-omap2/io.c:       omap_clk_init = omap4xxx_clk_init;
> code in drivers/clk/omap/clk-44xx.c
>
> Seems goofy to me a little.
> entire purpose of having a clk-44xx.c is:
> a) doing a clk alias for device nodes

I am not quite sure we have mechanisms for doing this (yet).

> b) set_parent, rate

I think this is maybe an idea for future dev and Mike to consider if he 
wants generic clock nodes to have such properties.


> both of these seem to be an old style carry forward and should instead
> be fixes with generic properties IMHO voiding the need for SoC specific
> inits.
>
> instead all we should be doing is call of_clk_init(NULL); at appropriate
> init sequence.



From t-kristo at ti.com  Wed Jul 31 10:56:44 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 17:56:44 +0300
Subject: [PATCHv4 15/33] CLK: OMAP: DPLL: add support for DT property
 ti,dpll-no-gate
In-Reply-To: <51F8118F.3000104@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-16-git-send-email-t-kristo@ti.com>
 <51F8118F.3000104@ti.com>
Message-ID: <51F925AC.7010806@ti.com>

On 07/30/2013 10:18 PM, Nishanth Menon wrote:
> On 07/23/2013 02:20 AM, Tero Kristo wrote:
>> AM335x has DPLL clocks that should never be attempted to be gated. Adding
>> ti,dpll-no-gate property for them handles this situation.
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> ---
>>   drivers/clk/omap/dpll.c |   10 ++++++++++
>>   1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
>> index 66e82be..1d24feada 100644
>> --- a/drivers/clk/omap/dpll.c
>> +++ b/drivers/clk/omap/dpll.c
>> @@ -54,6 +54,13 @@ static const struct clk_ops dpll_x2_ck_ops = {
>>       .recalc_rate    = &omap3_clkoutx2_recalc,
>>   };
>>
>> +static const struct clk_ops dpll_no_gate_ck_ops = {
>> +    .recalc_rate    = &omap3_dpll_recalc,
>> +    .get_parent    = &omap2_init_dpll_parent,
>> +    .round_rate    = &omap2_dpll_round_rate,
>> +    .set_rate    = &omap3_noncore_dpll_set_rate,
>> +};
>> +
>>   struct clk *omap_clk_register_dpll(struct device *dev, const char
>> *name,
>>           const char **parent_names, int num_parents, unsigned long
>> flags,
>>           struct dpll_data *dpll_data, const char *clkdm_name,
>> @@ -288,6 +295,9 @@ __init void of_omap4_dpll_setup(struct device_node
>> *node)
>>           return;
>>       }
>>
>> +    if (of_property_read_bool(node, "ti,dpll-no-gate"))
>> +        ops = &dpll_no_gate_ck_ops;
>> +
>>       of_omap_dpll_setup(node, ops);
>>   }
>>   EXPORT_SYMBOL_GPL(of_omap4_dpll_setup);
>>
> squash this to dpll patch?
>

Can do it. Was kept separate just to avoid confusion with previous rev 
of the code.

-Tero



From t-kristo at ti.com  Wed Jul 31 10:57:56 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 17:57:56 +0300
Subject: [PATCHv4 16/33] CLK: OMAP: DPLL: do not of_iomap NULL autoidle
 register
In-Reply-To: <51F818CB.4060007@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-17-git-send-email-t-kristo@ti.com>
 <51F818CB.4060007@ti.com>
Message-ID: <51F925F4.2000308@ti.com>

On 07/30/2013 10:49 PM, Nishanth Menon wrote:
> On 07/23/2013 02:20 AM, Tero Kristo wrote:
>> AM33xx series SoCs do not have autoidle support, and for these the
>> autoidle register is marked as NULL. Check against a NULL pointer and
>> do not attempt to of_iomap in this case, as this just creates a bogus
>> pointer and causes a kernel crash during boot.
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> ---
>>   drivers/clk/omap/dpll.c |   10 +++++++++-
>>   1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
>> index 1d24feada..d8a958a 100644
>> --- a/drivers/clk/omap/dpll.c
>> +++ b/drivers/clk/omap/dpll.c
>> @@ -162,6 +162,7 @@ static void __init of_omap_dpll_setup(struct
>> device_node *node,
>>       u32 max_multiplier = 2047;
>>       u32 max_divider = 128;
>>       u32 min_divider = 1;
>> +    u32 val;
>>       int i;
>>
>>       dd = kzalloc(sizeof(struct dpll_data), GFP_KERNEL);
>> @@ -210,7 +211,14 @@ static void __init of_omap_dpll_setup(struct
>> device_node *node,
>>
>>       dd->control_reg = of_iomap(node, 0);
>>       dd->idlest_reg = of_iomap(node, 1);
>> -    dd->autoidle_reg = of_iomap(node, 2);
>> +    /*
>> +     * AM33xx DPLLs have no autoidle support, and the autoidle reg
>> +     * for these is NULL. Do not attempt to of_iomap in this case,
>> +     * as this just creates a bogus pointer and crashes the kernel.
>> +     */
>> +    of_property_read_u32_index(node, "reg", 2 * 2, &val);
>> +    if (val)
>> +        dd->autoidle_reg = of_iomap(node, 2);
> should we not do that for all the parameters?

Maybe do the check for all.

> OR:
> move this as index 3 which is optional and is not defined for am33xx?
>
>>       dd->mult_div1_reg = of_iomap(node, 3);
>
>>
>>       dd->idlest_mask = idlest_mask;
>>
> we could probably squash this in original dpll.c as a result?
>

Yea, can do that also.



From t-kristo at ti.com  Wed Jul 31 10:59:12 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 17:59:12 +0300
Subject: [PATCHv4 19/33] CLK: omap: add am33xx clock init file
In-Reply-To: <51F81B68.2020708@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-20-git-send-email-t-kristo@ti.com>
 <51F81B68.2020708@ti.com>
Message-ID: <51F92640.70305@ti.com>

On 07/30/2013 11:00 PM, Nishanth Menon wrote:
> On 07/23/2013 02:20 AM, Tero Kristo wrote:
>> clk-33xx.c now contains the clock init functionality for am33xx,
>> including
>> DT clock registration and adding of static clkdev entries.
>>
>> This patch also moves the omap2_clk_enable_init_clocks declaration to
>> the driver include, as this is needed by the am33xx clock init code.
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> ---
>>   arch/arm/mach-omap2/clock.h |    1 -
>>   drivers/clk/omap/clk-33xx.c |   85
>> +++++++++++++++++++++++++++++++++++++++++++
>>   include/linux/clk/omap.h    |    1 +
>>   3 files changed, 86 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/clk/omap/clk-33xx.c
>>
>> diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
>> index d1a3125..6273f14 100644
>> --- a/arch/arm/mach-omap2/clock.h
>> +++ b/arch/arm/mach-omap2/clock.h
>> @@ -267,7 +267,6 @@ void omap2_clk_dflt_find_idlest(struct clk_hw_omap
>> *clk,
>>                   void __iomem **idlest_reg,
>>                   u8 *idlest_bit, u8 *idlest_val);
>>   int omap2_clk_enable_autoidle_all(void);
>> -void omap2_clk_enable_init_clocks(const char **clk_names, u8
>> num_clocks);
>>   int omap2_clk_switch_mpurate_at_boot(const char *mpurate_ck_name);
>>   void omap2_clk_print_new_rates(const char *hfclkin_ck_name,
>>                      const char *core_ck_name,
>> diff --git a/drivers/clk/omap/clk-33xx.c b/drivers/clk/omap/clk-33xx.c
>> new file mode 100644
>> index 0000000..3ada30e
>> --- /dev/null
>> +++ b/drivers/clk/omap/clk-33xx.c
> [...]
>> +static const char *enable_init_clks[] = {
>> +    "dpll_ddr_m2_ck",
>> +    "dpll_mpu_m2_ck",
>> +    "l3_gclk",
>> +    "l4hs_gclk",
>> +    "l4fw_gclk",
>> +    "l4ls_gclk",
>> +    /* Required for external peripherals like, Audio codecs */
>> +    "clkout2_ck",
>> +};
>
> should be a sort of dt property?
>

Future dev maybe?

I try to avoid adding too many new props with this set....

-Tero



From t-kristo at ti.com  Wed Jul 31 11:03:52 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 18:03:52 +0300
Subject: [PATCHv4 21/33] CLK: OMAP: DPLL: add omap3 dpll support
In-Reply-To: <51F81D3A.7080007@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-22-git-send-email-t-kristo@ti.com>
 <51F81D3A.7080007@ti.com>
Message-ID: <51F92758.20405@ti.com>

On 07/30/2013 11:08 PM, Nishanth Menon wrote:
> On 07/23/2013 02:20 AM, Tero Kristo wrote:
>> OMAP3 has slightly different DPLLs from those compared to OMAP4. Modified
>> code for the same.
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> ---
>>   drivers/clk/omap/dpll.c |   96
>> +++++++++++++++++++++++++++++++++++++++++------
>>   1 file changed, 85 insertions(+), 11 deletions(-)
>>
> :) wont repeat the binding crib again..
>
>> diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
>> index d8a958a..ecb1fbd 100644
>> --- a/drivers/clk/omap/dpll.c
>> +++ b/drivers/clk/omap/dpll.c
>> @@ -26,6 +26,11 @@
>>   #include <linux/of_address.h>
>>   #include <linux/clk/omap.h>
>>
>> +enum {
>> +    SUBTYPE_OMAP3_DPLL,
>> +    SUBTYPE_OMAP4_DPLL,
>> +};
>> +
>>   static const struct clk_ops dpll_m4xen_ck_ops = {
>>       .enable        = &omap3_noncore_dpll_enable,
>>       .disable    = &omap3_noncore_dpll_disable,
>> @@ -40,6 +45,13 @@ static const struct clk_ops dpll_core_ck_ops = {
>>       .get_parent    = &omap2_init_dpll_parent,
>>   };
>>
>> +static const struct clk_ops omap3_dpll_core_ck_ops = {
>> +    .init        = &omap2_init_clk_clkdm,
>> +    .get_parent    = &omap2_init_dpll_parent,
>> +    .recalc_rate    = &omap3_dpll_recalc,
>> +    .round_rate    = &omap2_dpll_round_rate,
>> +};
>> +
>>   static const struct clk_ops dpll_ck_ops = {
>>       .enable        = &omap3_noncore_dpll_enable,
>>       .disable    = &omap3_noncore_dpll_disable,
>> @@ -50,6 +62,26 @@ static const struct clk_ops dpll_ck_ops = {
>>       .init        = &omap2_init_clk_clkdm,
>>   };
>>
>> +static const struct clk_ops omap3_dpll_ck_ops = {
>> +    .init        = &omap2_init_clk_clkdm,
>> +    .enable        = &omap3_noncore_dpll_enable,
>> +    .disable    = &omap3_noncore_dpll_disable,
>> +    .get_parent    = &omap2_init_dpll_parent,
>> +    .recalc_rate    = &omap3_dpll_recalc,
>> +    .set_rate    = &omap3_noncore_dpll_set_rate,
>> +    .round_rate    = &omap2_dpll_round_rate,
>> +};
>> +
>> +static const struct clk_ops omap3_dpll_per_ck_ops = {
>> +    .init        = &omap2_init_clk_clkdm,
>> +    .enable        = &omap3_noncore_dpll_enable,
>> +    .disable    = &omap3_noncore_dpll_disable,
>> +    .get_parent    = &omap2_init_dpll_parent,
>> +    .recalc_rate    = &omap3_dpll_recalc,
>> +    .set_rate    = &omap3_dpll4_set_rate,
>> +    .round_rate    = &omap2_dpll_round_rate,
>> +};
>> +
>>   static const struct clk_ops dpll_x2_ck_ops = {
>>       .recalc_rate    = &omap3_clkoutx2_recalc,
>>   };
>> @@ -144,7 +176,9 @@ struct clk *omap_clk_register_dpll_x2(struct
>> device *dev, const char *name,
>>    * of_omap_dpll_setup() - Setup function for OMAP DPLL clocks
>>    */
>>   static void __init of_omap_dpll_setup(struct device_node *node,
>> -                    const struct clk_ops *ops)
>> +                    const struct clk_ops *ops, u32 freqsel,
>> +                    u32 modes, u8 mul_div_shift,
>> +                    int subtype)
>>   {
>>       struct clk *clk;
>>       const char *clk_name = node->name;
>> @@ -157,8 +191,8 @@ static void __init of_omap_dpll_setup(struct
>> device_node *node,
>>       u32 idlest_mask = 0x1;
>>       u32 enable_mask = 0x7;
>>       u32 autoidle_mask = 0x7;
>> -    u32 mult_mask = 0x7ff << 8;
>> -    u32 div1_mask = 0x7f;
>> +    u32 mult_mask = 0x7ff << (8 + mul_div_shift);
>> +    u32 div1_mask = 0x7f << mul_div_shift;
>>       u32 max_multiplier = 2047;
>>       u32 max_divider = 128;
>>       u32 min_divider = 1;
>> @@ -193,7 +227,7 @@ static void __init of_omap_dpll_setup(struct
>> device_node *node,
>>
>>       clkspec.np = of_parse_phandle(node, "ti,clk-ref", 0);
>>       dd->clk_ref = of_clk_get_from_provider(&clkspec);
>> -    if (!dd->clk_ref) {
>> +    if (IS_ERR(dd->clk_ref)) {
>
> belongs to original patch.

Agree.

>
>>           pr_err("%s: ti,clk-ref for %s not found\n", __func__,
>>               clk_name);
>>           goto cleanup;
>> @@ -201,7 +235,7 @@ static void __init of_omap_dpll_setup(struct
>> device_node *node,
>>
>>       clkspec.np = of_parse_phandle(node, "ti,clk-bypass", 0);
>>       dd->clk_bypass = of_clk_get_from_provider(&clkspec);
>> -    if (!dd->clk_bypass) {
>> +    if (IS_ERR(dd->clk_bypass)) {
>
> same

Ditto.

>
>>           pr_err("%s: ti,clk-bypass for %s not found\n", __func__,
>>               clk_name);
>>           goto cleanup;
>> @@ -225,14 +259,31 @@ static void __init of_omap_dpll_setup(struct
>> device_node *node,
>>       dd->enable_mask = enable_mask;
>>       dd->autoidle_mask = autoidle_mask;
>>
>> -    dd->modes = 0xa0;
>> +    if (!of_property_read_u32(node, "ti,recal-en-bit", &val))
>> +        dd->recal_en_bit = val;
>> +
>> +    if (!of_property_read_u32(node, "ti,recal-st-bit", &val))
>> +        dd->recal_st_bit = val;
>> +
>> +    if (!of_property_read_u32(node, "ti,auto-recal-bit", &val))
>> +        dd->auto_recal_bit = val;
>
> now I understand what it means.

I am not quite sure you do, as I don't quite get your comment here. :) 
You referring to that dd->modes part?

>
>> +
>> +    of_property_read_u32(node, "ti,modes", &modes);
> i see we pass in modes, and read ti,modes to &modes. it is a bit sketchy
> without bindings documentation.

ti,modes can be used to override the default modes.

>
>> +
>> +    dd->modes = modes;
>
> Should have belonged to original patch.

If I squash this then we are fine.

>
>> +
>> +    dd->freqsel_mask = freqsel;
>>
>>       if (of_property_read_bool(node, "ti,dpll-j-type")) {
>>           dd->sddiv_mask = 0xff000000;
>> -        mult_mask = 0xfff << 8;
>> -        div1_mask = 0xff;
>> +        mult_mask = 0xfff << (8 + mul_div_shift);
>>           max_multiplier = 4095;
>> -        max_divider = 256;
>> +        if (subtype == SUBTYPE_OMAP3_DPLL) {
>> +            dd->dco_mask = 0xe00000;
>> +        } else {
>> +            div1_mask = 0xff << mul_div_shift;
>> +            max_divider = 256;
>> +        }
>>       }
>>
>>       if (of_property_read_bool(node, "ti,dpll-regm4xen")) {
>> @@ -281,7 +332,30 @@ static void __init of_omap_dpll_x2_setup(struct
>> device_node *node)
>>
>>   __init void of_omap3_dpll_setup(struct device_node *node)
>>   {
>> -    /* XXX: to be done */
>> +    const struct clk_ops *ops;
>> +    u32 freqsel = 0xf0;
>> +    u32 modes = 0xa0;
>> +    u8 mul_div_shift = 0;
>> +
>> +    ops = &omap3_dpll_ck_ops;
>> +
>> +    if (of_property_read_bool(node, "ti,dpll-core")) {
>> +        ops = &omap3_dpll_core_ck_ops;
>> +        mul_div_shift = 8;
>> +        modes = 0x0;
>> +    }
>> +
>> +    if (of_property_read_bool(node, "ti,dpll-peripheral")) {
>> +        ops = &omap3_dpll_per_ck_ops;
>> +        freqsel = 0xf00000;
>> +    }
>> +
>> +    if (of_property_read_bool(node, "ti,dpll-j-type"))
>> +        freqsel = 0x0;
>> +
>> +    of_omap_dpll_setup(node, ops, freqsel, modes, mul_div_shift,
>> +        SUBTYPE_OMAP3_DPLL);
>> +
>>   }
>>   EXPORT_SYMBOL_GPL(of_omap3_dpll_setup);
>>   CLK_OF_DECLARE(omap3_dpll_clock, "ti,omap3-dpll-clock",
>> of_omap3_dpll_setup);
>> @@ -306,7 +380,7 @@ __init void of_omap4_dpll_setup(struct device_node
>> *node)
>>       if (of_property_read_bool(node, "ti,dpll-no-gate"))
>>           ops = &dpll_no_gate_ck_ops;
>>
>> -    of_omap_dpll_setup(node, ops);
>> +    of_omap_dpll_setup(node, ops, 0, 0xa0, 0, SUBTYPE_OMAP4_DPLL);
> what is 0xa0?

Magic modes for DPLL. I'll copy over the macro def as mentioned in one 
of the previous patches.

>
>>   }
>>   EXPORT_SYMBOL_GPL(of_omap4_dpll_setup);
>>   CLK_OF_DECLARE(omap4_dpll_clock, "ti,omap4-dpll-clock",
>> of_omap4_dpll_setup);
>>
>
> I think this should be squashed and a single dpll.c introduction to be
> done.

Ok.

>
>



From t-kristo at ti.com  Wed Jul 31 11:05:56 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 18:05:56 +0300
Subject: [PATCHv4 22/33] CLK: OMAP: update gate clock setup for OMAP3
In-Reply-To: <51F81E74.9070609@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-23-git-send-email-t-kristo@ti.com>
 <51F81E74.9070609@ti.com>
Message-ID: <51F927D4.9080603@ti.com>

On 07/30/2013 11:13 PM, Nishanth Menon wrote:
> On 07/23/2013 02:20 AM, Tero Kristo wrote:
>> OMAP3 gate clocks are handled through the clk driver now. Basic gate
>> clock can't be used as the OMAP3 gate clocks have some special features,
>> namely the idle status linkage which is on separate register.
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> ---
>>   drivers/clk/omap/gate.c |   27 +++++++++++++++++++++++++--
>>   1 file changed, 25 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
>> index 7186bb2..b560ff4 100644
>> --- a/drivers/clk/omap/gate.c
>> +++ b/drivers/clk/omap/gate.c
>> @@ -28,12 +28,19 @@
>>
>>   #ifdef CONFIG_OF
>>
>> -static const struct clk_ops omap_gate_clk_ops = {
>> +static const struct clk_ops omap_gate_clkdm_clk_ops = {
>>       .init        = &omap2_init_clk_clkdm,
>>       .enable        = &omap2_clkops_enable_clkdm,
>>       .disable    = &omap2_clkops_disable_clkdm,
>>   };
>>
>> +static const struct clk_ops omap_gate_clk_ops = {
>> +    .init        = &omap2_init_clk_clkdm,
>> +    .enable        = &omap2_dflt_clk_enable,
>> +    .disable    = &omap2_dflt_clk_disable,
>> +    .is_enabled    = &omap2_dflt_clk_is_enabled,
>> +};
>> +
>>   void __init of_omap_gate_clk_setup(struct device_node *node)
>>   {
>>       struct clk *clk;
>> @@ -43,6 +50,7 @@ void __init of_omap_gate_clk_setup(struct
>> device_node *node)
>>       int num_parents;
>>       const char **parent_names;
>>       int i;
>> +    u32 val;
>>
>>       clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
>>       if (!clk_hw) {
>> @@ -56,7 +64,22 @@ void __init of_omap_gate_clk_setup(struct
>> device_node *node)
>>       of_property_read_string(node, "ti,clkdm-name",
>> &clk_hw->clkdm_name);
>>
>>       init.name = clk_name;
>> -    init.ops = &omap_gate_clk_ops;
>> +    init.flags = 0;
>> +
>> +    if (of_property_read_u32_index(node, "reg", 0, &val)) {
>> +        /* No register, clkdm control only */
>> +        init.ops = &omap_gate_clkdm_clk_ops;
>> +    } else {
>> +        init.ops = &omap_gate_clk_ops;
>> +        clk_hw->enable_reg = of_iomap(node, 0);
>> +        of_property_read_u32(node, "ti,enable-bit", &val);
>> +        clk_hw->enable_bit = val;
>> +
>> +        if (of_property_read_bool(node, "ti,dss-clk"))
>> +            clk_hw->ops = &clkhwops_omap3430es2_dss_usbhost_wait;
>
> umm, it was going relatively ok so far, till i hit this :( it is
> probably a quirk... but still..

Some of the clocks need special hwops for them to work properly it 
seems... It looks nasty yea but the best I could think of.

>
>> +        else
>> +            clk_hw->ops = &clkhwops_wait;
>> +    }
>>
>>       num_parents = of_clk_get_parent_count(node);
>>       if (num_parents < 1) {
>>
>
> but still no usage of "ti,omap-gate-clock" makes me question the need
> for this file.
>

Yea, no ti,omap-gate-clock, but there is ti,gate-clock. Just look harder.




From richardcochran at gmail.com  Wed Jul 31 11:07:19 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Wed, 31 Jul 2013 17:07:19 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <1479410.BSGDrOcRvP@thinkpad>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1441731.8CGUI1tUxh@flatron>
 <1375267057.20042.52.camel@sakura.staff.proxad.net>
 <1479410.BSGDrOcRvP@thinkpad>
Message-ID: <20130731150717.GD4904@netboy>

On Wed, Jul 31, 2013 at 12:59:59PM +0200, Tomasz Figa wrote:
> On Wednesday 31 of July 2013 12:37:37 Maxime Bizon wrote:
> > 
> > Board files are C code anyone has the skill to edit/understand/refactor.
> > Moving to DT and keep them in tree tightly coupled with the kernel
> > version just adds another layer of indirection for *no purpose*.

+1

That is exactly what I tried to say.

> > Linus started the whole thing some years ago by refusing to pull ARM
> > tree [1]. Reread his post, what he wants is clearly b).
> > 
> > Going a) does not solve any problem. You are just moving churn to
> > somewhere else. We had board files churn, then defconfigs churn, DTS
> > files (and associated drivers) will be next.

And at this rate, we are headed for another Linus ultimatum, sooner or
later.

> > DT is self inflicted pain. It has to be for the greater good.
> 
> It has several benefits over board files that I mentioned above, possible 
> without fully separating them from kernel tree.

Every time a criticism is voiced about DT, the DT people stick their
fingers in their ears and say, "NAH, NAH, NAH, I CAN'T HEAR YOU!"

WRT to DT-as-platform-device, we would rather stick with the C code,
please. Just pushing the configuration tables into an external form
does not simplify the problem. In fact, it creates new problems by
inviting the possibility of a bootloader/DT/kernel mismatch.

Thanks,
Richard



From t-kristo at ti.com  Wed Jul 31 11:09:12 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 18:09:12 +0300
Subject: [PATCHv4 23/33] CLK: OMAP: add interface clock support for OMAP3
In-Reply-To: <51F820DF.1080306@ti.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-24-git-send-email-t-kristo@ti.com>
 <51F820DF.1080306@ti.com>
Message-ID: <51F92898.3090206@ti.com>

On 07/30/2013 11:23 PM, Nishanth Menon wrote:
> On 07/23/2013 02:20 AM, Tero Kristo wrote:
>> OMAP3 has interface clocks in addition to functional clocks, which
> is it just OMAP3?

Yea, only omap3 is using this code. Basically because there is control 
for the module specific interface clocks which is absent from omap4+. 
Personally I think modelling the interface clocks in the first place in 
kernel side was a bad idea, and should have just enabled all of them and 
enable autoidles for them at the same point.

>
>> require special handling for the autoidle and idle status register
>> offsets mainly.
>
>>
>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>> ---
>>   drivers/clk/omap/Makefile    |    2 +-
>>   drivers/clk/omap/clk.c       |    3 ++
>>   drivers/clk/omap/interface.c |  110
>> ++++++++++++++++++++++++++++++++++++++++++
> should this be isolated off for omap3?

You mean within makefile or?

>
>>   3 files changed, 114 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/clk/omap/interface.c
>>
>> diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
>> index c4e8825..faaeb62 100644
>> --- a/drivers/clk/omap/Makefile
>> +++ b/drivers/clk/omap/Makefile
>> @@ -1,3 +1,3 @@
>>   obj-y                    += clk.o dpll.o autoidle.o gate.o \
>>                          clk-44xx.o clk-54xx.o clk-7xx.o \
>> -                       clk-33xx.o
>> +                       clk-33xx.o interface.o
>> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
>> index 8c89714..5cbefde 100644
>> --- a/drivers/clk/omap/clk.c
>> +++ b/drivers/clk/omap/clk.c
>> @@ -30,6 +30,9 @@ static const struct of_device_id clk_match[] = {
>>       {.compatible = "gate-clock", .data = of_gate_clk_setup, },
>>       {.compatible = "ti,omap4-dpll-clock", .data =
>> of_omap4_dpll_setup, },
>>       {.compatible = "ti,gate-clock", .data = of_omap_gate_clk_setup, },
>> +    {.compatible = "ti,interface-clock",
>> +        .data = of_omap_interface_clk_setup, },
>
>> +    {.compatible = "ti,omap3-dpll-clock", .data =
>> of_omap3_dpll_setup, },
> I dont see how this line has anything to do with the patch.

Yea, seems it should have been part of the omap3 dpll introduction one.

>>       {},
>>   };
>>
>> diff --git a/drivers/clk/omap/interface.c b/drivers/clk/omap/interface.c
>> new file mode 100644
>> index 0000000..f1f1a1a
>> --- /dev/null
>> +++ b/drivers/clk/omap/interface.c
>> @@ -0,0 +1,110 @@
>> +/*
>> + * OMAP interface clock support
>> + *
>> + * Copyright (C) 2013 Texas Instruments, Inc.
>> + *
>> + * Tero Kristo <t-kristo at ti.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/clk-provider.h>
>> +#include <linux/module.h>
>> +#include <linux/slab.h>
>> +#include <linux/io.h>
>> +#include <linux/err.h>
>> +#include <linux/string.h>
>> +#include <linux/log2.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/clk/omap.h>
>> +
>> +#ifdef CONFIG_OF
>> +
>> +static const struct clk_ops omap_interface_clk_ops = {
>> +    .init        = &omap2_init_clk_clkdm,
>> +    .enable        = &omap2_dflt_clk_enable,
>> +    .disable    = &omap2_dflt_clk_disable,
>> +    .is_enabled    = &omap2_dflt_clk_is_enabled,
>> +};
>> +
>> +void __init of_omap_interface_clk_setup(struct device_node *node)
>> +{
>> +    struct clk *clk;
>> +    struct clk_init_data init;
>> +    struct clk_hw_omap *clk_hw;
>> +    const char *clk_name = node->name;
>> +    int num_parents;
>> +    const char **parent_names;
>> +    int i;
>> +    u32 val;
>> +
>> +    clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
>> +    if (!clk_hw) {
>> +        pr_err("%s: could not allocate clk_hw_omap\n", __func__);
>> +        return;
>> +    }
>> +
>> +    clk_hw->hw.init = &init;
>> +    clk_hw->ops = &clkhwops_iclk_wait;
>> +    clk_hw->enable_reg = of_iomap(node, 0);
>> +
>> +    if (!of_property_read_u32(node, "ti,enable-bit", &val))
>> +        clk_hw->enable_bit = val;
>> +
>> +    if (of_property_read_bool(node, "ti,iclk-no-wait"))
>> +        clk_hw->ops = &clkhwops_iclk;
>> +
>> +    if (of_property_read_bool(node, "ti,iclk-hsotgusb"))
>> +        clk_hw->ops = &clkhwops_omap3430es2_iclk_hsotgusb_wait;
>> +
>> +    if (of_property_read_bool(node, "ti,iclk-dss"))
>> +        clk_hw->ops = &clkhwops_omap3430es2_iclk_dss_usbhost_wait;
>> +
>> +    if (of_property_read_bool(node, "ti,iclk-ssi"))
>> +        clk_hw->ops = &clkhwops_omap3430es2_iclk_ssi_wait;
>> +
>> +    of_property_read_string(node, "clock-output-names", &clk_name);
>> +    of_property_read_string(node, "ti,clkdm-name", &clk_hw->clkdm_name);
>> +
>> +    init.name = clk_name;
>> +    init.ops = &omap_interface_clk_ops;
>> +    init.flags = 0;
>> +
>> +    num_parents = of_clk_get_parent_count(node);
>> +    if (num_parents < 1) {
>> +        pr_err("%s: omap interface_clk %s must have parent(s)\n",
>> +            __func__, node->name);
>> +        goto cleanup;
>> +    }
>> +
>> +    parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
>> +
>> +    for (i = 0; i < num_parents; i++)
>> +        parent_names[i] = of_clk_get_parent_name(node, i);
>> +
>> +    init.num_parents = num_parents;
>> +    init.parent_names = parent_names;
>> +
>> +    clk = clk_register(NULL, &clk_hw->hw);
>> +
>> +    if (!IS_ERR(clk)) {
>> +        of_clk_add_provider(node, of_clk_src_simple_get, clk);
>> +        omap2_init_clk_hw_omap_clocks(clk);
>> +        return;
>> +    }
>> +
>> +cleanup:
> the usual stuff about parent name, error checks init = { 0 } etc..

Yea, will add those.

>
>> +    kfree(clk_hw);
>> +}
>> +EXPORT_SYMBOL(of_omap_interface_clk_setup);
>> +CLK_OF_DECLARE(omap_interface_clk, "ti,omap-interface-clock",
>> +        of_omap_interface_clk_setup);
>> +#endif
>>
>
>



From t-kristo at ti.com  Wed Jul 31 11:10:32 2013
From: t-kristo at ti.com (Tero Kristo)
Date: Wed, 31 Jul 2013 18:10:32 +0300
Subject: [PATCHv4 29/33] CLK: omap: add omap3 clock init file
In-Reply-To: <20130731063512.GP7656@atomide.com>
References: <1374564028-11352-1-git-send-email-t-kristo@ti.com>
 <1374564028-11352-30-git-send-email-t-kristo@ti.com>
 <51F81FD7.2060707@ti.com> <20130731063512.GP7656@atomide.com>
Message-ID: <51F928E8.9020806@ti.com>

On 07/31/2013 09:35 AM, Tony Lindgren wrote:
> * Nishanth Menon <nm at ti.com> [130730 13:26]:
>> On 07/23/2013 02:20 AM, Tero Kristo wrote:
>>> clk-3xxx.c now contains the clock init functionality for omap3, including
>>> DT clock registration and adding of static clkdev entries.
>>>
>>> This patch also splits the OMAP3 clock registration code under mach-omap2
>>> to use OMAP3 subtype specific clk init functions.
>>>
>>> Signed-off-by: Tero Kristo <t-kristo at ti.com>
>>> ---
>>>   arch/arm/mach-omap2/Makefile          |    2 +-
>>>   arch/arm/mach-omap2/cclock3xxx_data.c | 3641 ---------------------------------
>>
>> Tony and a lot of people is not going to like removing support for
>> non-dt boot for OMAP3 before "it's time is due" ;)
>
> I think the only showstopper for that is that we need the
> pending pinctrl changes merged first to keep off-idle working.
> So the omap3 legacy code removal probably needs to wait until
> v3.13 merge window. For omap4 and am33xx we can do it now.
>
> Regards,
>
> Tony
>

I'll modify the series in such way that OMAP3 retains the legacy clock 
data within the kernel for now, and will use either DT or kernel data 
based on init type. Kernel data can then be removed when time is ripe 
for it.

-Tero


From gdjakov at mm-sol.com  Wed Jul 31 11:14:06 2013
From: gdjakov at mm-sol.com (Georgi Djakov)
Date: Wed, 31 Jul 2013 18:14:06 +0300
Subject: [PATCH] mmc: sdhci-msm: Add support for MSM chipsets
In-Reply-To: <CAJAp7OgOT82G=W8RpDvaogskUmAN26CWq4gKUs45RwOeU8pXvQ@mail.gmail.com>
References: <1375201355-26906-1-git-send-email-gdjakov@mm-sol.com>
 <CAJAp7OgOT82G=W8RpDvaogskUmAN26CWq4gKUs45RwOeU8pXvQ@mail.gmail.com>
Message-ID: <51F929BE.1050505@mm-sol.com>

On 07/31/2013 03:19 AM, Bjorn Andersson wrote:
> On Tue, Jul 30, 2013 at 8:22 AM, Georgi Djakov <gdjakov at mm-sol.com> wrote:
>> This platform driver adds the support of Secure Digital Host
>> Controller Interface compliant controller in MSM chipsets.
>>
>> [snip]
>> +
>> +       sdhc_1: qcom,sdhc at f9824900 {
>> +               compatible = "qcom,sdhci-msm";
>> +                       reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
>> +                       reg-names = "hc_mem", "core_mem";
>> +                       interrupts = <0 123 0>, <0 138 0>;
>> +                       interrupt-names = "hc_irq", "pwr_irq";
>> +
>> +               vdd-supply = <&pm8941_l21>;
>> +               vdd-io-supply = <&pm8941_l13>;
>> +               qcom,vdd-voltage-level = <2950000 2950000>;
>> +               qcom,vdd-current-level = <9000 800000>;
>> +
>> +               qcom,vdd-io-always-on;
>> +               qcom,vdd-io-lpm-sup;
>> +               qcom,vdd-io-voltage-level = <1800000 2950000>;
>> +               qcom,vdd-io-current-level = <6 22000>;
>> +
>> +               bus-width = <4>;
>> +               non-removable;
>> +               qcom,bus-speed-mode = "HS200_1p8v", "DDR_1p8v";
>> +
>> +               gpios = <&msmgpio 40 0>, /* CLK */
>> +                       <&msmgpio 39 0>, /* CMD */
>> +                       <&msmgpio 38 0>, /* DATA0 */
>> +                       <&msmgpio 37 0>, /* DATA1 */
>> +                       <&msmgpio 36 0>, /* DATA2 */
>> +                       <&msmgpio 35 0>; /* DATA3 */
>> +               qcom,gpio-names = "CLK", "CMD", "DAT0", "DAT1", "DAT2", "DAT3";
>
> I believe these gpio references (and in the rest of the patch) should
> be replaced by pinctrl. As far as I can see it provides what you want
> and gives you configurability and potential sleep states of those pins
> nicely integrated.
>

Thanks! I'll make it use the pinctrl driver that is coming too.

BR,
Georgi


From thomas.petazzoni at free-electrons.com  Wed Jul 31 11:14:22 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 31 Jul 2013 17:14:22 +0200
Subject: [PATCHv5 05/11] of: pci: add registry of MSI chips
In-Reply-To: <20130729142600.63eeab50@skate>
References: <1373889167-27878-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1373889167-27878-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <51E41F7A.4010502@gmail.com> <20130728043310.6CF1D3E08FE@localhost>
 <20130728162711.32a9a21e@skate> <20130729065431.GA1115@manwe>
 <20130729142600.63eeab50@skate>
Message-ID: <20130731171422.628af1fd@skate>

Grant,

Would it be possible to get your opinion on the patch below?

You're the one who disagreed about the "of: pci: add registry of MSI
chips", so I implemented something that hopefully is more in line with
what you expected, so it'd be great if you could take some time to
review it.

This MSI stuff has been around for quite some time, the specific patch
you NAKed had originally been posted on June, 6th, and was thought to
be ready for merging thanks to the ACK of Rob Herring. While I
certainly understand that patches can continue to be discussed by other
maintainers, it'd be nice to have quick feedback from you after this NAK
so that we can converge towards an accepted solution to be merged in
3.12.

Thanks a lot,

Thomas

On Mon, 29 Jul 2013 14:26:00 +0200, Thomas Petazzoni wrote:
> Dear Thierry Reding,
> 
> On Mon, 29 Jul 2013 08:54:31 +0200, Thierry Reding wrote:
> 
> > > So what is your suggestion to allow the PCIe controller to retrieve the
> > > correct irq_domain if we have only one DT node for the IRQ controller
> > > that registers two irq_domains ?
> > 
> > If I understand correctly, Grant isn't objecting to the introduction of
> > the lookup function, but rather its implementation. You could add a
> > pointer to a struct msi_chip within struct irq_domain and then iterate
> > over all irq_domain instances (see irq_find_host()) and find one which
> > has the correct device_node pointer and the msi_chip pointer set.
> 
> Ah ok. The only trick is that we have to change irq_find_host() to
> *not* match on MSI domains. Can you check the below patch to see if it
> matches what Grant suggested? It works for me, and it allows to completely
> remove the registry of msi_chip in drivers/of, as well as the of_node
> pointer in struct msi_chip.
> 
> Thanks!
> 
> Thomas
> 
> From c2c0137cb110270f96e1e0fa298a5d585b8d829e Mon Sep 17 00:00:00 2001
> From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Date: Mon, 29 Jul 2013 14:12:31 +0200
> Subject: [PATCHv6 05/11] irqdomain: add support to associate an irq_domain
>  with a msi_chip
> 
> Message Signaled Interrupts are a PCI-specific mechanism that allows
> PCI devices to notify interrupts to the CPU using in-band
> messages. The PCI subsystem represents an MSI-capable interrupt
> controller as an msi_chip structure, and this patch improves the
> irqdomain subsystem with a new pointer associating an irq_domain with
> the corresponding msi_chip.
> 
> The __irq_domain_add() function is augmented with an additional
> argument, the 'msi_chip' pointer, and all callers of this function are
> updated.
> 
> A new function irq_domain_add_msi() function is added to allow the
> registration of an MSI-type irq domain.
> 
> The irq_find_host() function is modified to not match on MSI-type irq
> domains: a given DT device node may represent both a normal interrupt
> controller and a MSI interrupt controller. irq_find_host() should
> return the irq_domain that corresponds to the normal interupt
> controller.
> 
> An irq_find_msi() function is added to get the MSI_type irq domain
> given a DT device node.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  include/linux/irqdomain.h | 20 +++++++++++++++++---
>  kernel/irq/irqdomain.c    | 35 +++++++++++++++++++++++++++++++++--
>  2 files changed, 50 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index 1ffa336..f1b11c8 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -38,6 +38,7 @@
>  struct device_node;
>  struct irq_domain;
>  struct of_device_id;
> +struct msi_chip;
>  
>  /* Number of irqs reserved for a legacy isa controller */
>  #define NUM_ISA_INTERRUPTS	16
> @@ -101,6 +102,7 @@ struct irq_domain {
>  	/* Optional data */
>  	struct device_node *of_node;
>  	struct irq_domain_chip_generic *gc;
> +	struct msi_chip *msi_chip;
>  
>  	/* reverse map data. The linear map gets appended to the irq_domain */
>  	irq_hw_number_t hwirq_max;
> @@ -114,6 +116,7 @@ struct irq_domain {
>  struct irq_domain *__irq_domain_add(struct device_node *of_node, int size,
>  				    irq_hw_number_t hwirq_max, int direct_max,
>  				    const struct irq_domain_ops *ops,
> +				    struct msi_chip *msi_chip,
>  				    void *host_data);
>  struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
>  					 unsigned int size,
> @@ -127,6 +130,7 @@ struct irq_domain *irq_domain_add_legacy(struct device_node *of_node,
>  					 const struct irq_domain_ops *ops,
>  					 void *host_data);
>  extern struct irq_domain *irq_find_host(struct device_node *node);
> +extern struct irq_domain *irq_find_msi(struct device_node *node);
>  extern void irq_set_default_host(struct irq_domain *host);
>  
>  /**
> @@ -141,14 +145,15 @@ static inline struct irq_domain *irq_domain_add_linear(struct device_node *of_no
>  					 const struct irq_domain_ops *ops,
>  					 void *host_data)
>  {
> -	return __irq_domain_add(of_node, size, size, 0, ops, host_data);
> +	return __irq_domain_add(of_node, size, size, 0, ops, NULL, host_data);
>  }
>  static inline struct irq_domain *irq_domain_add_nomap(struct device_node *of_node,
>  					 unsigned int max_irq,
>  					 const struct irq_domain_ops *ops,
>  					 void *host_data)
>  {
> -	return __irq_domain_add(of_node, 0, max_irq, max_irq, ops, host_data);
> +	return __irq_domain_add(of_node, 0, max_irq, max_irq, ops, NULL,
> +				host_data);
>  }
>  static inline struct irq_domain *irq_domain_add_legacy_isa(
>  				struct device_node *of_node,
> @@ -162,7 +167,16 @@ static inline struct irq_domain *irq_domain_add_tree(struct device_node *of_node
>  					 const struct irq_domain_ops *ops,
>  					 void *host_data)
>  {
> -	return __irq_domain_add(of_node, 0, ~0, 0, ops, host_data);
> +	return __irq_domain_add(of_node, 0, ~0, 0, ops, NULL, host_data);
> +}
> +static inline struct irq_domain *irq_domain_add_msi(struct device_node *of_node,
> +						    unsigned int size,
> +						    const struct irq_domain_ops *ops,
> +						    struct msi_chip *msi_chip,
> +						    void *host_data)
> +{
> +	return __irq_domain_add(of_node, size, size, 0, ops,
> +				msi_chip, host_data);
>  }
>  
>  extern void irq_domain_remove(struct irq_domain *host);
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index b9ddb94..80dc1ca 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -29,6 +29,7 @@ static struct irq_domain *irq_default_domain;
>   * @direct_max: Maximum value of direct maps; Use ~0 for no limit; 0 for no
>   *              direct mapping
>   * @ops: map/unmap domain callbacks
> + * @msi_chip: pointer to MSI chip structure, for MSI domains
>   * @host_data: Controller private data pointer
>   *
>   * Allocates and initialize and irq_domain structure.  Caller is expected to
> @@ -38,6 +39,7 @@ static struct irq_domain *irq_default_domain;
>  struct irq_domain *__irq_domain_add(struct device_node *of_node, int size,
>  				    irq_hw_number_t hwirq_max, int direct_max,
>  				    const struct irq_domain_ops *ops,
> +				    struct msi_chip *msi_chip,
>  				    void *host_data)
>  {
>  	struct irq_domain *domain;
> @@ -52,6 +54,7 @@ struct irq_domain *__irq_domain_add(struct device_node *of_node, int size,
>  	domain->ops = ops;
>  	domain->host_data = host_data;
>  	domain->of_node = of_node_get(of_node);
> +	domain->msi_chip = msi_chip;
>  	domain->hwirq_max = hwirq_max;
>  	domain->revmap_size = size;
>  	domain->revmap_direct_max_irq = direct_max;
> @@ -127,7 +130,7 @@ struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
>  {
>  	struct irq_domain *domain;
>  
> -	domain = __irq_domain_add(of_node, size, size, 0, ops, host_data);
> +	domain = __irq_domain_add(of_node, size, size, 0, ops, NULL, host_data);
>  	if (!domain)
>  		return NULL;
>  
> @@ -172,7 +175,7 @@ struct irq_domain *irq_domain_add_legacy(struct device_node *of_node,
>  	struct irq_domain *domain;
>  
>  	domain = __irq_domain_add(of_node, first_hwirq + size,
> -				  first_hwirq + size, 0, ops, host_data);
> +				  first_hwirq + size, 0, ops, NULL, host_data);
>  	if (!domain)
>  		return NULL;
>  
> @@ -198,6 +201,12 @@ struct irq_domain *irq_find_host(struct device_node *node)
>  	 */
>  	mutex_lock(&irq_domain_mutex);
>  	list_for_each_entry(h, &irq_domain_list, link) {
> +		/*
> +		 * We only want to match normal interrupt domains, not
> +		 * MSI domains
> +		 */
> +		if (h->msi_chip)
> +			continue;
>  		if (h->ops->match)
>  			rc = h->ops->match(h, node);
>  		else
> @@ -214,6 +223,28 @@ struct irq_domain *irq_find_host(struct device_node *node)
>  EXPORT_SYMBOL_GPL(irq_find_host);
>  
>  /**
> + * irq_find_msi() - Locates a MSI domain for a given device node
> + * @node: device-tree node of the interrupt controller
> + */
> +struct irq_domain *irq_find_msi(struct device_node *node)
> +{
> +	struct irq_domain *h, *found = NULL;
> +
> +	mutex_lock(&irq_domain_mutex);
> +	list_for_each_entry(h, &irq_domain_list, link) {
> +		if (!h->msi_chip)
> +			continue;
> +		if (h->of_node && h->of_node == node) {
> +			found = h;
> +			break;
> +		}
> +	}
> +	mutex_unlock(&irq_domain_mutex);
> +	return found;
> +}
> +EXPORT_SYMBOL_GPL(irq_find_msi);
> +
> +/**
>   * irq_set_default_host() - Set a "default" irq domain
>   * @domain: default domain pointer
>   *



-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From mgorman at suse.de  Wed Jul 31 11:21:31 2013
From: mgorman at suse.de (Mel Gorman)
Date: Wed, 31 Jul 2013 16:21:31 +0100
Subject: [Ksummit-2013-discuss] [ATTEND] [ARM ATTEND] kernel data bloat
 and how to avoid it
In-Reply-To: <20130731073802.GT7656@atomide.com>
References: <20130731073802.GT7656@atomide.com>
Message-ID: <20130731152131.GW2296@suse.de>

On Wed, Jul 31, 2013 at 12:38:03AM -0700, Tony Lindgren wrote:
> Hi all,
> 
> Probably the biggest kernel data bloat issue is in the ARM land, but
> it also seems that it's becoming a Linux generic issue too, so I
> guess it could be discussed in either context.
> 

Would scripts/bloat-o-meter highlight where the growth problems are?

-- 
Mel Gorman
SUSE Labs


From tomasz.figa at gmail.com  Wed Jul 31 11:23:35 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 31 Jul 2013 17:23:35 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130731150717.GD4904@netboy>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1479410.BSGDrOcRvP@thinkpad> <20130731150717.GD4904@netboy>
Message-ID: <1999586.84BnWE5EUh@thinkpad>

On Wednesday 31 of July 2013 17:07:19 Richard Cochran wrote:
> On Wed, Jul 31, 2013 at 12:59:59PM +0200, Tomasz Figa wrote:
> > On Wednesday 31 of July 2013 12:37:37 Maxime Bizon wrote:
> > > Board files are C code anyone has the skill to edit/understand/refactor.
> > > Moving to DT and keep them in tree tightly coupled with the kernel
> > > version just adds another layer of indirection for *no purpose*.
> 
> +1
> 
> That is exactly what I tried to say.

I agree with you to some extent. Don't be so extreme though. As I already 
said, this is not entirely "no purpose", as there are more benefits of having 
device tree than just separation from kernel tree.

> > > Linus started the whole thing some years ago by refusing to pull ARM
> > > tree [1]. Reread his post, what he wants is clearly b).
> > > 
> > > Going a) does not solve any problem. You are just moving churn to
> > > somewhere else. We had board files churn, then defconfigs churn, DTS
> > > files (and associated drivers) will be next.
> 
> And at this rate, we are headed for another Linus ultimatum, sooner or
> later.

(see end of the message)

> > > DT is self inflicted pain. It has to be for the greater good.
> > 
> > It has several benefits over board files that I mentioned above, possible
> > without fully separating them from kernel tree.
> 
> Every time a criticism is voiced about DT, the DT people stick their
> fingers in their ears and say, "NAH, NAH, NAH, I CAN'T HEAR YOU!"

I won't comment this...

> WRT to DT-as-platform-device, we would rather stick with the C code,
> please. Just pushing the configuration tables into an external form
> does not simplify the problem. In fact, it creates new problems by
> inviting the possibility of a bootloader/DT/kernel mismatch.

Care to stop ignoring my points other than those defending ideas (nowhere 
stated as good or bad) from extreme opinions?

I said it many, many times, that a) and b) I proposed are just two extremes. 
It is unlikely that an extreme solution will be the best option to choose. I 
am strongly for something in the middle, just like I wrote in several of my 
previous replies.

This is something that should be commented, not those extreme options.

Best regards,
Tomasz



From broonie at kernel.org  Wed Jul 31 11:25:23 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 31 Jul 2013 16:25:23 +0100
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731140758.GT2810@htj.dyndns.org>
References: <20130731094434.GC1754@pengutronix.de>
 <20130731095411.GA2810@htj.dyndns.org>
 <20130731111853.GJ9858@sirena.org.uk>
 <20130731113244.GI2810@htj.dyndns.org>
 <20130731115027.GN9858@sirena.org.uk>
 <20130731115527.GR2810@htj.dyndns.org>
 <20130731132708.GQ9858@sirena.org.uk>
 <20130731134215.GS2810@htj.dyndns.org>
 <20130731135751.GT9858@sirena.org.uk>
 <20130731140758.GT2810@htj.dyndns.org>
Message-ID: <20130731152523.GW9858@sirena.org.uk>

On Wed, Jul 31, 2013 at 10:07:58AM -0400, Tejun Heo wrote:
> On Wed, Jul 31, 2013 at 02:57:51PM +0100, Mark Brown wrote:

> > That's the only API I've ever heard of doing that.  Everything else is
> > just using it to do deallocation.

> I'm not sure why or what you're trying to argue here but take a look
> at devm_pwm_release() for example.  It calls back into low level
> driver free routine.  Are you arguing that it'd be a good idea to

That the callback is into the driver providing the PWM, not into the
driver that's using the PWM and is releasing it.

> release pci regions before this is complete?  It's just stupid to do
> any differently.  There's nothing to argue about.

What I'm saying is that in essentially all the users I've seen devm is
only being used for things like kfree() or clk_put() which aren't really
connected in any way and can happen in any order.  This (coupled with
the lack of documentation that this is supported) is why people are
nervous about anything that relies on ordering with this stuff - aside
from ATA everything is just using this for straight frees.
-------------- 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/20130731/5bc05f02/attachment.sig>

From htejun at gmail.com  Wed Jul 31 11:29:32 2013
From: htejun at gmail.com (Tejun Heo)
Date: Wed, 31 Jul 2013 11:29:32 -0400
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731152523.GW9858@sirena.org.uk>
References: <20130731095411.GA2810@htj.dyndns.org>
 <20130731111853.GJ9858@sirena.org.uk>
 <20130731113244.GI2810@htj.dyndns.org>
 <20130731115027.GN9858@sirena.org.uk>
 <20130731115527.GR2810@htj.dyndns.org>
 <20130731132708.GQ9858@sirena.org.uk>
 <20130731134215.GS2810@htj.dyndns.org>
 <20130731135751.GT9858@sirena.org.uk>
 <20130731140758.GT2810@htj.dyndns.org>
 <20130731152523.GW9858@sirena.org.uk>
Message-ID: <20130731152932.GV2810@htj.dyndns.org>

On Wed, Jul 31, 2013 at 04:25:23PM +0100, Mark Brown wrote:
> What I'm saying is that in essentially all the users I've seen devm is
> only being used for things like kfree() or clk_put() which aren't really
> connected in any way and can happen in any order.  This (coupled with
> the lack of documentation that this is supported) is why people are
> nervous about anything that relies on ordering with this stuff - aside
> from ATA everything is just using this for straight frees.

Yeah, sure, thank you very much for your input.  It is of course
strictly ordered and the documentation needs to be updated.

-- 
tejun


From maxime.ripard at free-electrons.com  Wed Jul 31 11:49:53 2013
From: maxime.ripard at free-electrons.com (maxime.ripard)
Date: Wed, 31 Jul 2013 17:49:53 +0200
Subject: [PATCH 4/4] ARM: sun6i: Enable clock support in the DTSI
In-Reply-To: <2013073120102496855035@gmail.com>
References: <1375195462-19566-1-git-send-email-maxime.ripard@free-electrons.com>
 <1375195462-19566-5-git-send-email-maxime.ripard@free-electrons.com>
 <51F86A2E.10505@elopez.com.ar> <20130731073724.GA24439@lukather>
 <2013073116110750016327@gmail.com> <20130731114957.GD2911@lukather>
 <2013073120102496855035@gmail.com>
Message-ID: <20130731154953.GG2911@lukather>



On Wed, Jul 31, 2013 at 08:10:32PM +0800, kevin.z.m wrote:
> > How does one select either the internal or the external 32kHz
> > oscillator? Is this done in software (I can't find any reference to that
> > in the user manuals) or in hardware?
> For A20, it should be in the Timer module, and there is a register named "LOSC_CTRL_REG".
> For A31, it is in the RTC module, same name of "LOSC_CTRL_REG".

Ok, just so that we're on the same page, we have two oscillators running
at 32kHz, the internal being always there, and the external that could
or could not be there, and it's each different hardware block that can
be wired to one, the other or both?

There's no global mux that could use either one of the two 32k to
provide the only 32kHz source in the system, right?

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20130731/0bb8be73/attachment.sig>

From festevam at gmail.com  Wed Jul 31 12:15:04 2013
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 31 Jul 2013 13:15:04 -0300
Subject: [PATCH] ARM: imx_v6_v7_defconfig: Enable wireless support
Message-ID: <1375287304-3896-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at freescale.com>

Wandboard has a Broadcom 4329 chipset connected to SDHC, so turn on the wireless 
related options.

Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
---
 arch/arm/configs/imx_v6_v7_defconfig | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index d3e044a..577f054 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -61,7 +61,10 @@ CONFIG_IP_PNP_DHCP=y
 # CONFIG_INET_LRO is not set
 CONFIG_IPV6=y
 CONFIG_NETFILTER=y
-# CONFIG_WIRELESS is not set
+CONFIG_CFG80211=y
+CONFIG_MAC80211=y
+CONFIG_RFKILL=y
+CONFIG_RFKILL_INPUT=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_STANDALONE is not set
@@ -115,7 +118,7 @@ CONFIG_SMC91X=y
 CONFIG_SMC911X=y
 CONFIG_SMSC911X=y
 # CONFIG_NET_VENDOR_STMICRO is not set
-# CONFIG_WLAN is not set
+CONFIG_BRCMFMAC=m
 # CONFIG_INPUT_MOUSEDEV_PSAUX is not set
 CONFIG_INPUT_EVDEV=y
 CONFIG_INPUT_EVBUG=m
-- 
1.8.1.2



From dianders at chromium.org  Wed Jul 31 12:18:23 2013
From: dianders at chromium.org (Doug Anderson)
Date: Wed, 31 Jul 2013 09:18:23 -0700
Subject: [PATCH v2 3/5] mmc: dw_mmc: Add exynos resume_noirq callback to
 clear WAKEUP_INT
In-Reply-To: <003f01ce8154$2f5ea1d0$8e1be570$%jun@samsung.com>
References: <1373391071-6312-1-git-send-email-dianders@chromium.org>
 <1373411961-23812-1-git-send-email-dianders@chromium.org>
 <1373411961-23812-4-git-send-email-dianders@chromium.org>
 <002a01ce7d7d$6bd9e870$438db950$%jun@samsung.com>
 <CAD=FV=UtX0Z1ABdi5h270ks8Py2o1iPK4DonOHJH3N0Q1YShTQ@mail.gmail.com>
 <003f01ce8154$2f5ea1d0$8e1be570$%jun@samsung.com>
Message-ID: <CAD=FV=XZcf8xWWxrCoe9KqjnQs4p4y7ENnuUYsVKU+yrE09GeQ@mail.gmail.com>

Seungwon,

On Mon, Jul 15, 2013 at 5:09 AM, Seungwon Jeon <tgih.jun at samsung.com> wrote:
> Sorry for late response.
> Yes, it's not clear.
> If you get the confirmation, could you share this problem?
> Possibly, auto-clear may not be implemented.
> Then, manual should be correct.

I just got an update from my contacts.  They confirm that bit 11 is
not automatically cleared and that writing to it will clear it.
Hopefully this information will make it into the next version of any
documentation that you receive as well.

It is still unclear exactly why the WAKEUP_INT was being asserted on
our board despite the fact that all of the wakeup control signals
(bits 10:8) were 0.  That is still being investigated.

-Doug


From soren.brinkmann at xilinx.com  Wed Jul 31 12:26:55 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Wed, 31 Jul 2013 09:26:55 -0700
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <51F8BC5D.80605@linaro.org>
References: <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
 <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
 <51F77D93.4030505@linaro.org> <51F8BC5D.80605@linaro.org>
Message-ID: <2ebbb5cd-2755-4082-b434-d276e7225de5@CO1EHSMHS024.ehs.local>

On Wed, Jul 31, 2013 at 09:27:25AM +0200, Daniel Lezcano wrote:
> On 07/31/2013 12:34 AM, S?ren Brinkmann wrote:
> > On Tue, Jul 30, 2013 at 10:47:15AM +0200, Daniel Lezcano wrote:
> >> On 07/30/2013 02:03 AM, S?ren Brinkmann wrote:
> >>> Hi Daniel,
> >>>
> >>> On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
> >>> (snip)
> >>>>
> >>>> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
> >>>> timer will be stopped when entering to the idle state. In this case, the
> >>>> cpuidle framework will call clockevents_notify(ENTER) and switches to a
> >>>> broadcast timer and will call clockevents_notify(EXIT) when exiting the
> >>>> idle state, switching the local timer back in use.
> >>>
> >>> I've been thinking about this, trying to understand how this makes my
> >>> boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
> >>> would make the timer core switch to a broadcast device even though it
> >>> wouldn't be necessary. But shouldn't it still work? It sounds like we do
> >>> something useless, but nothing wrong in a sense that it should result in
> >>> breakage. I guess I'm missing something obvious. This timer system will
> >>> always remain a mystery to me.
> >>>
> >>> Actually this more or less leads to the question: What is this
> >>> 'broadcast timer'. I guess that is some clockevent device which is
> >>> common to all cores? (that would be the cadence_ttc for Zynq). Is the
> >>> hang pointing to some issue with that driver?
> >>
> >> If you look at the /proc/timer_list, which timer is used for broadcasting ?
> > 
> > So, the correct run results (full output attached).
> > 
> > The vanilla kernel uses the twd timers as local timers and the TTC as
> > broadcast device:
> > 	Tick Device: mode:     1                                                         
> > 	Broadcast device  
> > 	Clock Event Device: ttc_clockevent
> > 
> > When I remove the offending CPUIDLE flag and add the DT fragment to
> > enable the global timer, the twd timers are still used as local timers
> > and the broadcast device is the global timer:
> > 	Tick Device: mode:     1                                                         
> > 	Broadcast device                                                                 
> > 	Clock Event Device: arm_global_timer
> > 
> > Again, since boot hangs in the actually broken case, I don't see way to
> > obtain this information for that case.
> 
> Hmm, interesting. Can you give the ouput of /proc/interrupts also with
> the global timer ?
Sure:

	# cat /proc/interrupts 
	           CPU0       CPU1       
	 27:         14          1       GIC  27  gt
	 29:        841        843       GIC  29  twd
	 43:          0          0       GIC  43  ttc_clockevent
	 82:        563          0       GIC  82  xuartps
	IPI0:          0          0  CPU wakeup interrupts
	IPI1:          0          0  Timer broadcast interrupts
	IPI2:       1266       1330  Rescheduling interrupts
	IPI3:          0          0  Function call interrupts
	IPI4:         34         59  Single function call interrupts
	IPI5:          0          0  CPU stop interrupts
	Err:          0

	S?ren




From thomas.petazzoni at free-electrons.com  Wed Jul 31 12:29:19 2013
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 31 Jul 2013 18:29:19 +0200
Subject: [Ksummit-2013-discuss] Defining schemas for Device Tree
In-Reply-To: <2300415.ZNNddtVGav@thinkpad>
References: <1706112.Xn49tiCSKF@thinkpad> <20130731113401.GM9858@sirena.org.uk>
 <CAKON4OyQUcqw1RFcWj3uy0i2i+3UBB8fG1rPw6tcrMGDZ40y6g@mail.gmail.com>
 <2300415.ZNNddtVGav@thinkpad>
Message-ID: <20130731182919.1168b88e@skate>

Dear Tomasz Figa,

On Wed, 31 Jul 2013 14:21:49 +0200, Tomasz Figa wrote:

> u-boot still does not have generic driver model or at least did not have when 
> I last checked it not so long ago, so it seems like there is still long way to 
> go for using FDT as source of information about hardware in u-boot.
> 
> barebox [1], aka u-boot-v2, might be closer to this approach (it might be 
> already using it, but this needs to be checked) as it already has generic 
> driver model and support for DT.

There are already some platforms in Barebox that are using the Device
Tree. For example, the basic Marvell platforms support in Barebox now
uses the Device Tree.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From shuahkhan at gmail.com  Wed Jul 31 12:35:05 2013
From: shuahkhan at gmail.com (Shuah Khan)
Date: Wed, 31 Jul 2013 10:35:05 -0600
Subject: [Announcement] Linux Plumbers ACPI/PM, PCI Microconference
In-Reply-To: <1755363.sGc8nLIQOW@vostro.rjw.lan>
References: <CAL-B5D03ki8NHsM6EuESTH2K-Eh+XyFHNXPDYwgDq+oagDjtMQ@mail.gmail.com>
 <1755363.sGc8nLIQOW@vostro.rjw.lan>
Message-ID: <CAKocOOPOqqS80D23z6xTVSNYYYWZ7ACg9MtSMz_hTqVA3Duo0w@mail.gmail.com>

On Wed, Jul 31, 2013 at 5:40 AM, Rafael J. Wysocki <rjw at sisk.pl> wrote:
> Hi All,
>
> The original announcement didn't go to linux-pm, so again:
>
> On Tuesday, July 16, 2013 08:21:26 PM Myron Stowe wrote:
>> Linux Plumbers has approved an ACPI/PM, PCI microconference. The
>> overview page is here:
>>
>> http://wiki.linuxplumbersconf.org/2013:pci_subsystem
>>
>> We would like to start receiving volunteers for presenting topics of
>> interest.  There is a lot of activity in these subsystems so please
>> respond by submitting presentation or discussion proposals that you
>> would be willing to cover for consideration.  You should also feel
>> free to submit ideas as proposals that others could cover.  The
>> instructions for submitting ideas should be at:
>>
>> http://www.linuxplumbersconf.org/2013/submitting-topic/
>
> If anyone who's going to attend the Linux Plumbers Conf this year is interested
> in any particular topic for discussion during the ACPI/PM+PCI uconf, please
> submit a formal topic proposal at:
>
> http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/proposals/new
>
> If you submit a topic, that doesn't mean you'll be expected to present anything
> (if accepted).  In fact, we are mostly interested in discussion topics and we'd
> like to know what is important to people.
>
> That said if you have a (short) presentation to make, please submit it too.
>
> We'll appreciate all submissions very much.
>

What I have mind is a discussion topic for the Mini-conference, which
in-line with what you are asking for.
I will add it to the web. Thanks for pinging me on this.

-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research
America (Silicon Valley) shuah.kh at samsung.com | (970) 672-0658


From heiko at sntech.de  Wed Jul 31 12:35:49 2013
From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=)
Date: Wed, 31 Jul 2013 18:35:49 +0200
Subject: [ARM ATTEND] no own topic / general invite request
Message-ID: <201307311835.50219.heiko@sntech.de>

Hi,

last year I got invited to the arm summit but couldn't attend due to timing / 
distance problems, but I will be in Edinburgh this year.

I don't have a topic of my own to discuss currently, but due to my meddling 
with the older Samsung SoCs and now the Rockchip work, it would be cool to be 
able to stay on top of current discussions.

So if there is space available, I'd like to attend.


Thanks
Heiko


From s.hauer at pengutronix.de  Wed Jul 31 12:41:36 2013
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 31 Jul 2013 18:41:36 +0200
Subject: Defining schemas for Device Tree
In-Reply-To: <2300415.ZNNddtVGav@thinkpad>
References: <1706112.Xn49tiCSKF@thinkpad> <20130731113401.GM9858@sirena.org.uk>
 <CAKON4OyQUcqw1RFcWj3uy0i2i+3UBB8fG1rPw6tcrMGDZ40y6g@mail.gmail.com>
 <2300415.ZNNddtVGav@thinkpad>
Message-ID: <20130731164136.GA5230@pengutronix.de>

On Wed, Jul 31, 2013 at 02:21:49PM +0200, Tomasz Figa wrote:
> On Wednesday 31 of July 2013 08:01:54 jonsmirl at gmail.com wrote:
> > On Wed, Jul 31, 2013 at 7:34 AM, Mark Brown <broonie at kernel.org> wrote:
> > > On Tue, Jul 30, 2013 at 07:23:36PM -0400, jonsmirl at gmail.com wrote:
> > >> Uboot could be an issue but I don't think they are actually doing
> > >> anything with FDTs yet, they are just talking about doing it.
> > > 
> > > Right, plus any other bootloaders that handle the DT in some way.  Those
> > > that just copy the file through without looking at it aren't an issue
> > > but I thought people were doing things like adding in properties for
> > > serial numbers but perhaps that's less widespread than I'd thought and
> > > it's not an issue.
> > 
> > uboot patches up the amount of RAM it finds into the FDT. It might
> > patch up clock speed too, I don't remember. I haven't seen it add
> > serial numbers but it might, not sure which serial numbers.
> > 
> > There has been talk for several years about turning uboot into a bunch
> > of device drivers and using FDT to control it. Allwinner has done that
> > with the fex implementation. The uboot work is still in the talking
> > about it phase.
> 
> u-boot still does not have generic driver model or at least did not have when 
> I last checked it not so long ago, so it seems like there is still long way to 
> go for using FDT as source of information about hardware in u-boot.
> 
> barebox [1], aka u-boot-v2, might be closer to this approach (it might be 
> already using it, but this needs to be checked) as it already has generic 
> driver model and support for DT.

Besides mvebu several newer i.MX platforms are probed from the
devicetree in barebox, so in order to reuse the devicetrees it would be
very good to have the devicetree bindings stable.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From soren.brinkmann at xilinx.com  Wed Jul 31 12:43:15 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Wed, 31 Jul 2013 09:43:15 -0700
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <51F8DA38.2060508@linaro.org>
References: <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
 <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
 <51F77D93.4030505@linaro.org> <51F8DA38.2060508@linaro.org>
Message-ID: <49221951-8912-4afa-bf83-54b1c3e9bde4@CO1EHSMHS007.ehs.local>

On Wed, Jul 31, 2013 at 11:34:48AM +0200, Daniel Lezcano wrote:
> On 07/31/2013 12:34 AM, S?ren Brinkmann wrote:
> > On Tue, Jul 30, 2013 at 10:47:15AM +0200, Daniel Lezcano wrote:
> >> On 07/30/2013 02:03 AM, S?ren Brinkmann wrote:
> >>> Hi Daniel,
> >>>
> >>> On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
> >>> (snip)
> >>>>
> >>>> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
> >>>> timer will be stopped when entering to the idle state. In this case, the
> >>>> cpuidle framework will call clockevents_notify(ENTER) and switches to a
> >>>> broadcast timer and will call clockevents_notify(EXIT) when exiting the
> >>>> idle state, switching the local timer back in use.
> >>>
> >>> I've been thinking about this, trying to understand how this makes my
> >>> boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
> >>> would make the timer core switch to a broadcast device even though it
> >>> wouldn't be necessary. But shouldn't it still work? It sounds like we do
> >>> something useless, but nothing wrong in a sense that it should result in
> >>> breakage. I guess I'm missing something obvious. This timer system will
> >>> always remain a mystery to me.
> >>>
> >>> Actually this more or less leads to the question: What is this
> >>> 'broadcast timer'. I guess that is some clockevent device which is
> >>> common to all cores? (that would be the cadence_ttc for Zynq). Is the
> >>> hang pointing to some issue with that driver?
> >>
> >> If you look at the /proc/timer_list, which timer is used for broadcasting ?
> > 
> > So, the correct run results (full output attached).
> > 
> > The vanilla kernel uses the twd timers as local timers and the TTC as
> > broadcast device:
> > 	Tick Device: mode:     1                                                         
> > 	Broadcast device  
> > 	Clock Event Device: ttc_clockevent
> > 
> > When I remove the offending CPUIDLE flag and add the DT fragment to
> > enable the global timer, the twd timers are still used as local timers
> > and the broadcast device is the global timer:
> > 	Tick Device: mode:     1                                                         
> > 	Broadcast device                                                                 
> > 	Clock Event Device: arm_global_timer
> > 
> > Again, since boot hangs in the actually broken case, I don't see way to
> > obtain this information for that case.
> 
> Is it possible the global timer driver simply does not work ? So when
> the cpuidle driver switches to it, the system stays stuck with no interrupt.
> 
> Removing the CPUIDLE_FLAG_TIMER_STOP prevents to use the broadcast timer
> (aka arm global timer), so the problem does not appear.
> 
> And when the C3STOP feature flag is added to the global timer, this one
> can't be a broadcast timer, so another clock is selected for that (I
> guess cadence_ttc). So again the problem does not appear.
> 
> I am more and more convinced the problem is not coming from the cpuidle
> driver. The cpuidle flag has just spotted a problem somewhere else and I
> suspect the arm_global_timer is not working for zynq.

I made the following experiment:
I removed all TTC and twd nodes from my dts, leaving the gt as only
timer source and the system boots. Interestingly, in this case no
broadcast device is available.

/proc/timer_list (shortended):
	Tick Device: mode:     1
	Broadcast device
	Clock Event Device: <NULL>
	tick_broadcast_mask: 00000000
	tick_broadcast_oneshot_mask: 00000000
	
	Tick Device: mode:     1
	Per CPU device: 0
	Clock Event Device: arm_global_timer
	 max_delta_ns:   12884902005
	 min_delta_ns:   1000
	 mult:           715827876
	 shift:          31
	 mode:           3
	 next_event:     25654916518 nsecs
	 set_next_event: gt_clockevent_set_next_event
	 set_mode:       gt_clockevent_set_mode
	 event_handler:  hrtimer_interrupt
	 retries:        0
	
	Tick Device: mode:     1
	Per CPU device: 1
	Clock Event Device: arm_global_timer
	 max_delta_ns:   12884902005
	 min_delta_ns:   1000
	 mult:           715827876
	 shift:          31
	 mode:           3
	 next_event:     25660000000 nsecs
	 set_next_event: gt_clockevent_set_next_event
	 set_mode:       gt_clockevent_set_mode
	 event_handler:  hrtimer_interrupt
	 retries:        0

/proc/interrupts:
	# cat /proc/interrupts 
	           CPU0       CPU1       
	 27:       1483       1623       GIC  27  gt
	 82:        507          0       GIC  82  xuartps
	IPI0:          0          0  CPU wakeup interrupts
	IPI1:          0          0  Timer broadcast interrupts
	IPI2:       1211       1238  Rescheduling interrupts
	IPI3:          0          0  Function call interrupts
	IPI4:         42         51  Single function call interrupts
	IPI5:          0          0  CPU stop interrupts
	Err:          0


	S?ren




From santosh.shilimkar at ti.com  Wed Jul 31 12:44:41 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 31 Jul 2013 12:44:41 -0400
Subject: [PATCH v2 1/6] ARM: mm: LPAE: use phys_addr_t appropriately in p2v
 and v2p conversions
In-Reply-To: <1375289086-5315-1-git-send-email-santosh.shilimkar@ti.com>
References: <1375289086-5315-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1375289086-5315-2-git-send-email-santosh.shilimkar@ti.com>

Fix remainder types used when converting back and forth between
physical and virtual addresses.

Cc: Will Deacon <will.deacon at arm.com>
Cc: Russell King <linux at arm.linux.org.uk>

Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/include/asm/memory.h |   22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index e750a93..c133bd9 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -185,22 +185,32 @@ extern unsigned long __pv_phys_offset;
 	: "=r" (to)					\
 	: "r" (from), "I" (type))
 
-static inline unsigned long __virt_to_phys(unsigned long x)
+static inline phys_addr_t __virt_to_phys(unsigned long x)
 {
 	unsigned long t;
 	__pv_stub(x, t, "add", __PV_BITS_31_24);
 	return t;
 }
 
-static inline unsigned long __phys_to_virt(unsigned long x)
+static inline unsigned long __phys_to_virt(phys_addr_t x)
 {
 	unsigned long t;
 	__pv_stub(x, t, "sub", __PV_BITS_31_24);
 	return t;
 }
+
 #else
-#define __virt_to_phys(x)	((x) - PAGE_OFFSET + PHYS_OFFSET)
-#define __phys_to_virt(x)	((x) - PHYS_OFFSET + PAGE_OFFSET)
+
+static inline phys_addr_t __virt_to_phys(unsigned long x)
+{
+	return (phys_addr_t)x - PAGE_OFFSET + PHYS_OFFSET;
+}
+
+static inline unsigned long __phys_to_virt(phys_addr_t x)
+{
+	return x - PHYS_OFFSET + PAGE_OFFSET;
+}
+
 #endif
 #endif
 #endif /* __ASSEMBLY__ */
@@ -238,14 +248,14 @@ static inline phys_addr_t virt_to_phys(const volatile void *x)
 
 static inline void *phys_to_virt(phys_addr_t x)
 {
-	return (void *)(__phys_to_virt((unsigned long)(x)));
+	return (void *)__phys_to_virt(x);
 }
 
 /*
  * Drivers should NOT use these either.
  */
 #define __pa(x)			__virt_to_phys((unsigned long)(x))
-#define __va(x)			((void *)__phys_to_virt((unsigned long)(x)))
+#define __va(x)			((void *)__phys_to_virt((phys_addr_t)(x)))
 #define pfn_to_kaddr(pfn)	__va((pfn) << PAGE_SHIFT)
 
 /*
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Wed Jul 31 12:44:40 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 31 Jul 2013 12:44:40 -0400
Subject: [PATCH v2 0/6] ARM: mm: Extend the runtime patch stub for PAE systems
Message-ID: <1375289086-5315-1-git-send-email-santosh.shilimkar@ti.com>

This is version 2 of the series which addresses the comments/suggestions
we received on earlier version. The series trying to extend the existing
v2p runtime patching for LPAE machines which can have physical memory
beyond 4 GB. Keystone is one such ARM machine.

In testing various modes(LPAE/non-LPAE, ARM/THMUB), we found an issue
with the patching code for THUMB2 build. So there is a patch added in
the series to address it. I was planning to squash it in the parent
64 bit patch but thought of keeping it separate for ease of review.
We can squash it while merging the patches. 

Special thanks to Nicolas for his valuable feedback on the earlier
version.

Cc: Nicolas Pitre <nico at linaro.org>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>

Santosh Shilimkar (4):
  ARM: mm: LPAE: use phys_addr_t appropriately in p2v and v2p
    conversions
  ARM: mm: Introduce virt_to_idmap() with an arch hook
  ARM: mm: Move the idmap print to appropriate place in the code
  ARM: mm: Recreate kernel mappings in early_paging_init()

Sricharan R (2):
  ARM: mm: LPAE: Correct virt_to_phys patching for 64 bit physical
    addresses
  ARM: mm: Update runtime patching code to THUMB2 mode

 arch/arm/include/asm/mach/arch.h |    1 +
 arch/arm/include/asm/memory.h    |   73 +++++++++++++++++++++---
 arch/arm/kernel/armksyms.c       |    1 +
 arch/arm/kernel/head.S           |  115 +++++++++++++++++++++++++++-----------
 arch/arm/kernel/setup.c          |    3 +
 arch/arm/kernel/smp.c            |    2 +-
 arch/arm/mm/idmap.c              |    8 +--
 arch/arm/mm/mmu.c                |   82 +++++++++++++++++++++++++++
 8 files changed, 237 insertions(+), 48 deletions(-)

-- 
1.7.9.5



From santosh.shilimkar at ti.com  Wed Jul 31 12:44:45 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 31 Jul 2013 12:44:45 -0400
Subject: [PATCH v2 5/6] ARM: mm: Update runtime patching code to THUMB2 mode
In-Reply-To: <1375289086-5315-1-git-send-email-santosh.shilimkar@ti.com>
References: <1375289086-5315-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1375289086-5315-6-git-send-email-santosh.shilimkar@ti.com>

From: Sricharan R <r.sricharan at ti.com>

Update the runtime patching  code to support Thumb2. In testing the
64 bit patching code, the issue was uncovered.

For better review, the patch is kept separate. If needed it can be
merged into "ARM: LPAE: Correct virt_to_phys patching for 64 bit
physical addresses"

Cc: Nicolas Pitre <nico at linaro.org>
Cc: Russell King <linux at arm.linux.org.uk>

Signed-off-by: Sricharan R <r.sricharan at ti.com>
[santosh.shilimkar at ti.com: reduced #ifdef, updated commit log]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/kernel/head.S |   69 ++++++++++++++++++++++++++++--------------------
 1 file changed, 40 insertions(+), 29 deletions(-)

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index aa3b0f7..a70d330 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -573,62 +573,73 @@ ENDPROC(__fixup_pv_table)
 
 	.text
 __fixup_a_pv_table:
-#ifdef CONFIG_THUMB2_KERNEL
-	lsls	r6, #24
-	beq	2f
-	clz	r7, r6
-	lsr	r6, #24
-	lsl	r6, r7
-	bic	r6, #0x0080
-	lsrs	r7, #1
-	orrcs	r6, #0x0080
-	orr	r6, r6, r7, lsl #12
-	orr	r6, #0x4000
-	b	2f
-1:	add     r7, r3
-	ldrh	ip, [r7, #2]
-	and	ip, 0x8f00
-	orr	ip, r6	@ mask in offset bits 31-24
-	strh	ip, [r7, #2]
-2:	cmp	r4, r5
-	ldrcc	r7, [r4], #4	@ use branch for delay slot
-	bcc	1b
-	bx	lr
-#else
 	adr	r0, 5f
 	b	4f
 1:	ldr	ip, [r7, r3]
+ THUMB(	1:	add	r7, r3)
+ THUMB(	ldrh	ip, [r7])
+ THUMB(	ldrh	r6, [r7, #2])
+ THUMB(	orr	ip, r6, ip, lsl #16)
+ ARM( 1: ldr	ip, [r7, r3])
 	lsr	r6, ip, #20		@ extract opcode
 	and	r6, r6, #0x3e
-	cmp	r6, #0x28		@ check for 'add' instruction
+ THUMB(	cmp	r6, #0x10)
+ ARM(	cmp	r6, #0x28)		@ check for 'add' instruction
 	beq	2f
-	cmp	r6, #0x24		@ check for 'sub' instruction
+ THUMB( cmp	r6, #0x1a)
+ ARM(	cmp	r6, #0x24)		@ check for 'sub' instruction
 	beq	2f
-	cmp	r6, #0x2a		@ check for 'adc' instruction
+ THUMB( cmp	r6, #0x14)
+ ARM(	cmp	r6, #0x2a)		@ check for 'adc' instruction
 	beq	4f
 	ldr	r6, [r0]
 	add	r6, r6, r3
 	ldr	r6, [r6, #4]
 	mvn	r11, #0
 	cmp	r11, r6
-	and	ip, ip, #0xf000		@ Register encoded in inst
+ THUMB( and	ip, ip, #0xf00)
+ ARM(	and	ip, ip, #0xf000)	@ Register encoded in inst
 	orrne	ip, ip, r6
 	ldreq	r6, [r0, #0x4]		@ mvn if _pv_offset high bits is 0xffffffff
 	ldrne	r6, [r0, #0x8]		@ mov otherwise
-	bic	r6, r6, #0xff
-	bic	r6, r6, #0xf00
+ THUMB(	mov	r11, r6, lsr #16)
+ THUMB(	mov	r6, r6, lsl #16)
+ THUMB(	orr	r6, r11, r6)
+ THUMB(	bic	r6, r6, #0x7000)
+ THUMB(	bic	r6, r6, #0xff)
+ ARM(	bic	r6, r6, #0xff)
+ ARM(	bic	r6, r6, #0xf00)
 	orr	ip, ip, r6
 	b	3f
 2:	ldr	r6, [r0]
 	ldr	r6, [r6, r3]
+#ifdef CONFIG_THUMB2_KERNEL
+	cmp	r6, #0
+	beq	6f
+	clz	r11, r6
+	lsr	r6, #24
+	lsl	r6, r11
+	bic	r6, #0x0080
+	lsrs	r11, #1
+	orrcs	r6, #0x0080
+	orr	r6, r6, r11, lsl #12
+	orr	r6, #0x4000
+6:	bic	ip, ip, #0x7000
+	bic	ip, ip, #0xff
+	orr	ip, ip, r6		@ mask in offset bits 31-24
+3:	strh	ip, [r7, #2]
+	mov	r6, ip, lsr #16
+	strh	r6, [r7]
+#else
+
 	bic	ip, ip, #0xff
 	orr	ip, ip, r6, lsr #24	@ mask in offset bits 31-24
 3:	str	ip, [r7, r3]
+#endif
 4:	cmp	r4, r5
 	ldrcc	r7, [r4], #4	@ use branch for delay slot
 	bcc	1b
 	mov	pc, lr
-#endif
 ENDPROC(__fixup_a_pv_table)
 
 5:	.long __pv_offset
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Wed Jul 31 12:44:44 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 31 Jul 2013 12:44:44 -0400
Subject: [PATCH v2 4/6] ARM: mm: LPAE: Correct virt_to_phys patching for 64
 bit physical addresses
In-Reply-To: <1375289086-5315-1-git-send-email-santosh.shilimkar@ti.com>
References: <1375289086-5315-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1375289086-5315-5-git-send-email-santosh.shilimkar@ti.com>

From: Sricharan R <r.sricharan at ti.com>

The current phys_to_virt patching mechanism does not work
for 64 bit physical addressesp. Note that constant used in add/sub
instructions is encoded in to the last 8 bits of the opcode. So shift
the _pv_offset constant by 24 to get it in to the correct place.

The v2p patching mechanism patches the higher 32bits of physical
address with a constant. While this is correct, in those platforms
where the lowmem addressable physical memory spawns across 4GB boundary,
a carry bit can be produced as a result of addition of lower 32bits.
This has to be taken in to account and added in to the upper. The patched
__pv_offset and va are added in lower 32bits, where __pv_offset can be
in two's complement form when PA_START < VA_START and that can result
in a false carry bit.

e.g PA = 0x80000000 VA = 0xC0000000
__pv_offset = PA - VA = 0xC0000000 (2's complement)

So adding __pv_offset + VA should never result in a true overflow. So in
order to differentiate between a true carry, a __pv_offset is extended
to 64bit and the upper 32bits will have 0xffffffff if __pv_offset is
2's complement. We are using the same to insert 'mvn #0' instead of
'mov' while patching.

The above idea was suggested by Nicolas Pitre <nico at linaro.org> as
part of the review of first version of the subject patch.

There is no corresponding change on the phys_to_virt() side, because
computations on the upper 32-bits would be discarded anyway.

Cc: Nicolas Pitre <nico at linaro.org>
Cc: Russell King <linux at arm.linux.org.uk>

Signed-off-by: Sricharan R <r.sricharan at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/include/asm/memory.h |   35 +++++++++++++++++++--
 arch/arm/kernel/armksyms.c    |    1 +
 arch/arm/kernel/head.S        |   68 +++++++++++++++++++++++++++++++----------
 3 files changed, 85 insertions(+), 19 deletions(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index d9b96c65..abe879d 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -174,7 +174,9 @@
 #define __PV_BITS_31_24	0x81000000
 
 extern phys_addr_t (*arch_virt_to_idmap) (unsigned long x);
-extern unsigned long __pv_phys_offset;
+extern phys_addr_t __pv_phys_offset;
+extern phys_addr_t __pv_offset;
+
 #define PHYS_OFFSET __pv_phys_offset
 
 #define __pv_stub(from,to,instr,type)			\
@@ -186,10 +188,37 @@ extern unsigned long __pv_phys_offset;
 	: "=r" (to)					\
 	: "r" (from), "I" (type))
 
+#define __pv_stub_mov_hi(t)				\
+	__asm__ volatile("@ __pv_stub_mov\n"		\
+	"1:	mov	%R0, %1\n"			\
+	"	.pushsection .pv_table,\"a\"\n"		\
+	"	.long	1b\n"				\
+	"	.popsection\n"				\
+	: "=r" (t)					\
+	: "I" (__PV_BITS_31_24))
+
+#define __pv_add_carry_stub(x, y)			\
+	__asm__ volatile("@ __pv_add_carry_stub\n"	\
+	"1:	adds	%Q0, %1, %2\n"			\
+	"2:	adc	%R0, %R0, #0\n"			\
+	"	.pushsection .pv_table,\"a\"\n"		\
+	"	.long	1b\n"				\
+	"	.long	2b\n"				\
+	"	.popsection\n"				\
+	: "+r" (y)					\
+	: "r" (x), "I" (__PV_BITS_31_24)		\
+	: "cc")
+
 static inline phys_addr_t __virt_to_phys(unsigned long x)
 {
-	unsigned long t;
-	__pv_stub(x, t, "add", __PV_BITS_31_24);
+	phys_addr_t t = 0;
+
+	if (sizeof(phys_addr_t) == 4) {
+		__pv_stub(x, t, "add", __PV_BITS_31_24);
+	} else {
+		__pv_stub_mov_hi(t);
+		__pv_add_carry_stub(x, t);
+	}
 	return t;
 }
 
diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
index 60d3b73..1f031dd 100644
--- a/arch/arm/kernel/armksyms.c
+++ b/arch/arm/kernel/armksyms.c
@@ -155,4 +155,5 @@ EXPORT_SYMBOL(__gnu_mcount_nc);
 
 #ifdef CONFIG_ARM_PATCH_PHYS_VIRT
 EXPORT_SYMBOL(__pv_phys_offset);
+EXPORT_SYMBOL(__pv_offset);
 #endif
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 9cf6063..aa3b0f7 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -545,17 +545,22 @@ ENDPROC(fixup_smp)
 	__HEAD
 __fixup_pv_table:
 	adr	r0, 1f
-	ldmia	r0, {r3-r5, r7}
+	ldmia	r0, {r3-r7}
+	cmp	r0, r3
+	mvn	ip, #0
 	sub	r3, r0, r3	@ PHYS_OFFSET - PAGE_OFFSET
 	add	r4, r4, r3	@ adjust table start address
 	add	r5, r5, r3	@ adjust table end address
-	add	r7, r7, r3	@ adjust __pv_phys_offset address
-	str	r8, [r7]	@ save computed PHYS_OFFSET to __pv_phys_offset
+	add	r6, r6, r3	@ adjust __pv_phys_offset address
+	add	r7, r7, r3	@ adjust __pv_offset address
+	str	r8, [r6]	@ save computed PHYS_OFFSET to __pv_phys_offset
+	strcc	ip, [r7, #4]	@ save to __pv_offset high bits
 	mov	r6, r3, lsr #24	@ constant for add/sub instructions
 	teq	r3, r6, lsl #24 @ must be 16MiB aligned
 THUMB(	it	ne		@ cross section branch )
 	bne	__error
-	str	r6, [r7, #4]	@ save to __pv_offset
+	lsl	r6, r6, #24
+	str	r6, [r7]	@ save to __pv_offset low bits
 	b	__fixup_a_pv_table
 ENDPROC(__fixup_pv_table)
 
@@ -564,6 +569,7 @@ ENDPROC(__fixup_pv_table)
 	.long	__pv_table_begin
 	.long	__pv_table_end
 2:	.long	__pv_phys_offset
+	.long	__pv_offset
 
 	.text
 __fixup_a_pv_table:
@@ -589,27 +595,53 @@ __fixup_a_pv_table:
 	bcc	1b
 	bx	lr
 #else
-	b	2f
+	adr	r0, 5f
+	b	4f
 1:	ldr	ip, [r7, r3]
-	bic	ip, ip, #0x000000ff
-	orr	ip, ip, r6	@ mask in offset bits 31-24
-	str	ip, [r7, r3]
-2:	cmp	r4, r5
+	lsr	r6, ip, #20		@ extract opcode
+	and	r6, r6, #0x3e
+	cmp	r6, #0x28		@ check for 'add' instruction
+	beq	2f
+	cmp	r6, #0x24		@ check for 'sub' instruction
+	beq	2f
+	cmp	r6, #0x2a		@ check for 'adc' instruction
+	beq	4f
+	ldr	r6, [r0]
+	add	r6, r6, r3
+	ldr	r6, [r6, #4]
+	mvn	r11, #0
+	cmp	r11, r6
+	and	ip, ip, #0xf000		@ Register encoded in inst
+	orrne	ip, ip, r6
+	ldreq	r6, [r0, #0x4]		@ mvn if _pv_offset high bits is 0xffffffff
+	ldrne	r6, [r0, #0x8]		@ mov otherwise
+	bic	r6, r6, #0xff
+	bic	r6, r6, #0xf00
+	orr	ip, ip, r6
+	b	3f
+2:	ldr	r6, [r0]
+	ldr	r6, [r6, r3]
+	bic	ip, ip, #0xff
+	orr	ip, ip, r6, lsr #24	@ mask in offset bits 31-24
+3:	str	ip, [r7, r3]
+4:	cmp	r4, r5
 	ldrcc	r7, [r4], #4	@ use branch for delay slot
 	bcc	1b
 	mov	pc, lr
 #endif
 ENDPROC(__fixup_a_pv_table)
 
+5:	.long __pv_offset
+	mvn	r0, #0
+	mov	r0, #0x81000000 @ For getting the correct 4 byte encoding
+
 ENTRY(fixup_pv_table)
-	stmfd	sp!, {r4 - r7, lr}
-	ldr	r2, 2f			@ get address of __pv_phys_offset
+	stmfd	sp!, {r0, r3 - r7, r11 - r12, lr}
 	mov	r3, #0			@ no offset
 	mov	r4, r0			@ r0 = table start
 	add	r5, r0, r1		@ r1 = table size
-	ldr	r6, [r2, #4]		@ get __pv_offset
 	bl	__fixup_a_pv_table
-	ldmfd	sp!, {r4 - r7, pc}
+	ldmfd	sp!, {r0, r3 - r7, r11 - r12, pc}
 ENDPROC(fixup_pv_table)
 
 	.align
@@ -619,10 +651,14 @@ ENDPROC(fixup_pv_table)
 	.globl	__pv_phys_offset
 	.type	__pv_phys_offset, %object
 __pv_phys_offset:
-	.long	0
-	.size	__pv_phys_offset, . - __pv_phys_offset
+	.quad	0
+
+	.data
+	.globl __pv_offset
+	.type __pv_offset, %object
 __pv_offset:
-	.long	0
+	.quad   0
+
 #endif
 
 #include "head-common.S"
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Wed Jul 31 12:44:43 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 31 Jul 2013 12:44:43 -0400
Subject: [PATCH v2 3/6] ARM: mm: Move the idmap print to appropriate place in
 the code
In-Reply-To: <1375289086-5315-1-git-send-email-santosh.shilimkar@ti.com>
References: <1375289086-5315-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1375289086-5315-4-git-send-email-santosh.shilimkar@ti.com>

Commit 9e9a367c29cebd2 {ARM: Section based HYP idmap} moved
the address conversion inside identity_mapping_add() without
respective print which carries useful idmap information.

Move the print as well inside identity_mapping_add() to
fix the same.

Cc: Will Deacon <will.deacon at arm.com>
Cc: Nicolas Pitre <nico at linaro.org>
Cc: Russell King <linux at arm.linux.org.uk>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/mm/idmap.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index c0a1e48..8e0e52e 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -70,6 +70,7 @@ static void identity_mapping_add(pgd_t *pgd, const char *text_start,
 
 	addr = virt_to_idmap(text_start);
 	end = virt_to_idmap(text_end);
+	pr_info("Setting up static identity map for 0x%lx - 0x%lx\n", addr, end);
 
 	prot |= PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AF;
 
@@ -91,8 +92,6 @@ static int __init init_static_idmap(void)
 	if (!idmap_pgd)
 		return -ENOMEM;
 
-	pr_info("Setting up static identity map for 0x%p - 0x%p\n",
-		__idmap_text_start, __idmap_text_end);
 	identity_mapping_add(idmap_pgd, __idmap_text_start,
 			     __idmap_text_end, 0);
 
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Wed Jul 31 12:44:42 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 31 Jul 2013 12:44:42 -0400
Subject: [PATCH v2 2/6] ARM: mm: Introduce virt_to_idmap() with an arch hook
In-Reply-To: <1375289086-5315-1-git-send-email-santosh.shilimkar@ti.com>
References: <1375289086-5315-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1375289086-5315-3-git-send-email-santosh.shilimkar@ti.com>

On some PAE systems (e.g. TI Keystone), memory is above the
32-bit addressable limit, and the interconnect provides an
aliased view of parts of physical memory in the 32-bit addressable
space.  This alias is strictly for boot time usage, and is not
otherwise usable because of coherency limitations. On such systems,
the idmap mechanism needs to take this aliased mapping into account.

This patch introduces virt_to_idmap() and a arch function pointer which
can be populated by platform which needs it. Also populate necessary
idmap spots with now available virt_to_idmap(). Avoided #ifdef approach
to be compatible with multi-platform builds.

Most architecture won't touch it and in that case virt_to_idmap()
fall-back to existing virt_to_phys() macro.

Cc: Nicolas Pitre <nico at linaro.org>
Cc: Russell King <linux at arm.linux.org.uk>

Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/include/asm/memory.h |   16 ++++++++++++++++
 arch/arm/kernel/smp.c         |    2 +-
 arch/arm/mm/idmap.c           |    5 +++--
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index c133bd9..d9b96c65 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -173,6 +173,7 @@
  */
 #define __PV_BITS_31_24	0x81000000
 
+extern phys_addr_t (*arch_virt_to_idmap) (unsigned long x);
 extern unsigned long __pv_phys_offset;
 #define PHYS_OFFSET __pv_phys_offset
 
@@ -259,6 +260,21 @@ static inline void *phys_to_virt(phys_addr_t x)
 #define pfn_to_kaddr(pfn)	__va((pfn) << PAGE_SHIFT)
 
 /*
+ * These are for systems that have a hardware interconnect supported alias of
+ * physical memory for idmap purposes.  Most cases should leave these
+ * untouched.
+ */
+static inline phys_addr_t __virt_to_idmap(unsigned long x)
+{
+	if (arch_virt_to_idmap)
+		return arch_virt_to_idmap(x);
+	else
+		return __virt_to_phys(x);
+}
+
+#define virt_to_idmap(x)	__virt_to_idmap((unsigned long)(x))
+
+/*
  * Virtual <-> DMA view memory address translations
  * Again, these are *only* valid on the kernel direct mapped RAM
  * memory.  Use of these is *deprecated* (and that doesn't mean
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index c2b4f8f..d36523d 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -81,7 +81,7 @@ void __init smp_set_ops(struct smp_operations *ops)
 
 static unsigned long get_arch_pgd(pgd_t *pgd)
 {
-	phys_addr_t pgdir = virt_to_phys(pgd);
+	phys_addr_t pgdir = virt_to_idmap(pgd);
 	BUG_ON(pgdir & ARCH_PGD_MASK);
 	return pgdir >> ARCH_PGD_SHIFT;
 }
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index 83cb3ac..c0a1e48 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -10,6 +10,7 @@
 #include <asm/system_info.h>
 
 pgd_t *idmap_pgd;
+phys_addr_t (*arch_virt_to_idmap) (unsigned long x);
 
 #ifdef CONFIG_ARM_LPAE
 static void idmap_add_pmd(pud_t *pud, unsigned long addr, unsigned long end,
@@ -67,8 +68,8 @@ static void identity_mapping_add(pgd_t *pgd, const char *text_start,
 	unsigned long addr, end;
 	unsigned long next;
 
-	addr = virt_to_phys(text_start);
-	end = virt_to_phys(text_end);
+	addr = virt_to_idmap(text_start);
+	end = virt_to_idmap(text_end);
 
 	prot |= PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AF;
 
-- 
1.7.9.5



From santosh.shilimkar at ti.com  Wed Jul 31 12:44:46 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 31 Jul 2013 12:44:46 -0400
Subject: [PATCH v2 6/6] ARM: mm: Recreate kernel mappings in
 early_paging_init()
In-Reply-To: <1375289086-5315-1-git-send-email-santosh.shilimkar@ti.com>
References: <1375289086-5315-1-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <1375289086-5315-7-git-send-email-santosh.shilimkar@ti.com>

This patch adds a step in the init sequence, in order to recreate
the kernel code/data page table mappings prior to full paging
initialization.  This is necessary on LPAE systems that run out of
a physical address space outside the 4G limit.  On these systems,
this implementation provides a machine descriptor hook that allows
the PHYS_OFFSET to be overridden in a machine specific fashion.

Based on Cyril's initial patch. The pv_table needs to be patched
again after switching to higher address space.

Cc: Nicolas Pitre <nico at linaro.org>
Cc: Russell King <linux at arm.linux.org.uk>

Signed-off-by: R Sricharan <r.sricharan at ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
---
 arch/arm/include/asm/mach/arch.h |    1 +
 arch/arm/kernel/setup.c          |    3 ++
 arch/arm/mm/mmu.c                |   82 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 86 insertions(+)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 441efc4..8fa734f 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -49,6 +49,7 @@ struct machine_desc {
 	bool			(*smp_init)(void);
 	void			(*fixup)(struct tag *, char **,
 					 struct meminfo *);
+	void			(*init_meminfo)(void);
 	void			(*reserve)(void);/* reserve mem blocks	*/
 	void			(*map_io)(void);/* IO mapping function	*/
 	void			(*init_early)(void);
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 63af9a7..a554d7e 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -72,6 +72,7 @@ static int __init fpe_setup(char *line)
 __setup("fpe=", fpe_setup);
 #endif
 
+extern void early_paging_init(struct machine_desc *, struct proc_info_list *);
 extern void paging_init(struct machine_desc *desc);
 extern void sanity_check_meminfo(void);
 extern enum reboot_mode reboot_mode;
@@ -876,6 +877,8 @@ void __init setup_arch(char **cmdline_p)
 	parse_early_param();
 
 	sort(&meminfo.bank, meminfo.nr_banks, sizeof(meminfo.bank[0]), meminfo_cmp, NULL);
+
+	early_paging_init(mdesc, lookup_processor_type(read_cpuid_id()));
 	sanity_check_meminfo();
 	arm_memblock_init(&meminfo, mdesc);
 
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 4f56617..7910656 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -28,6 +28,7 @@
 #include <asm/highmem.h>
 #include <asm/system_info.h>
 #include <asm/traps.h>
+#include <asm/procinfo.h>
 
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
@@ -1268,6 +1269,87 @@ static void __init map_lowmem(void)
 	}
 }
 
+#ifdef CONFIG_ARM_LPAE
+extern void fixup_pv_table(const void *, unsigned long);
+extern const void *__pv_table_begin, *__pv_table_end;
+
+/*
+ * early_paging_init() recreates boot time page table setup, allowing machines
+ * to switch over to a high (>4G) address space on LPAE systems
+ */
+void __init early_paging_init(struct machine_desc *mdesc,
+			      struct proc_info_list *procinfo)
+{
+	pmdval_t pmdprot = procinfo->__cpu_mm_mmu_flags;
+	unsigned long map_start, map_end;
+	pgd_t *pgd0, *pgdk;
+	pud_t *pud0, *pudk;
+	pmd_t *pmd0, *pmdk;
+	phys_addr_t phys;
+	int i;
+
+	/* remap kernel code and data */
+	map_start = init_mm.start_code;
+	map_end   = init_mm.brk;
+
+	/* get a handle on things... */
+	pgd0 = pgd_offset_k(0);
+	pud0 = pud_offset(pgd0, 0);
+	pmd0 = pmd_offset(pud0, 0);
+
+	pgdk = pgd_offset_k(map_start);
+	pudk = pud_offset(pgdk, map_start);
+	pmdk = pmd_offset(pudk, map_start);
+
+	phys = PHYS_OFFSET;
+
+	if (mdesc->init_meminfo) {
+		mdesc->init_meminfo();
+		/* Run the patch stub to update the constants */
+		fixup_pv_table(&__pv_table_begin,
+			(&__pv_table_end - &__pv_table_begin) << 2);
+
+		/*
+		 * Cache cleaning operations for self-modifying code
+		 * We should clean the entries by MVA but running a
+		 * for loop over every pv_table entry pointer would
+		 * just complicate the code.
+		 */
+		flush_cache_louis();
+		dsb();
+		isb();
+	}
+
+	/* remap level 1 table */
+	for (i = 0; i < PTRS_PER_PGD; i++) {
+		*pud0++ = __pud(__pa(pmd0) | PMD_TYPE_TABLE | L_PGD_SWAPPER);
+		pmd0 += PTRS_PER_PMD;
+	}
+
+	/* remap pmds for kernel mapping */
+	phys = __pa(map_start) & PMD_MASK;
+	do {
+		*pmdk++ = __pmd(phys | pmdprot);
+		phys += PMD_SIZE;
+	} while (phys < map_end);
+
+	flush_cache_all();
+	cpu_set_ttbr(0, __pa(pgd0));
+	cpu_set_ttbr(1, __pa(pgd0) + TTBR1_OFFSET);
+	local_flush_tlb_all();
+}
+
+#else
+
+void __init early_paging_init(struct machine_desc *mdesc,
+			      struct proc_info_list *procinfo)
+{
+	if (mdesc->init_meminfo)
+		mdesc->init_meminfo();
+}
+
+#endif
+
 /*
  * paging_init() sets up the page tables, initialises the zone memory
  * maps, and sets up the zero page, bad page and bad page tables.
-- 
1.7.9.5



From andrew at lunn.ch  Wed Jul 31 12:45:12 2013
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 31 Jul 2013 18:45:12 +0200
Subject: NSA310 + DT
In-Reply-To: <51F8F7E3.9090404@uni-bremen.de>
References: <20130730172407.3aab15c6@skate> <51F7EBB9.7000504@uni-bremen.de>
 <20130730191943.49f8070c@skate> <20130730183610.GT24782@lunn.ch>
 <51F814A0.2050403@uni-bremen.de> <20130730232316.10dc7019@skate>
 <20130731111414.47e7670b@skate> <51F8DC3A.6010007@uni-bremen.de>
 <20130731115108.21c043fd@skate> <51F8F7E3.9090404@uni-bremen.de>
Message-ID: <20130731164512.GB19725@lunn.ch>

> I came across one curious thing: With Andrews kernel I had:
> $ sensors
> adt7476-i2c-0-2e
> Adapter: mv64xxx_i2c adapter
> in0: +1.82 V (min = +0.00 V, max = +3.31 V)
> in1: +1.09 V (min = +0.00 V, max = +2.99 V)
> in2: +3.27 V (min = +2.98 V, max = +3.63 V)
> in3: +5.12 V (min = +4.53 V, max = +5.52 V)
> in4: +11.98 V (min = +0.00 V, max = +15.69 V)
> fan1: 4330 RPM (min = 0 RPM)
> fan2: 0 RPM (min = 0 RPM)
> fan3: 0 RPM (min = 0 RPM)
> fan4: 0 RPM (min = 0 RPM)
> temp1: +32.2??C (low = -127.0??C, high = +127.0??C)
> (crit = +100.0??C, hyst = +96.0??C)
> temp2: +32.5??C (low = -127.0??C, high = +127.0??C)
> (crit = +100.0??C, hyst = +96.0??C)
> temp3: +41.0??C (low = -127.0??C, high = +127.0??C)
> (crit = +100.0??C, hyst = +96.0??C)
> cpu0_vid: +0.000 V
> 
> normally I have:
> # sensors
> lm85-i2c-0-2e
> Adapter: mv64xxx_i2c adapter
> in0: +1.82 V (min = +0.00 V, max = +3.32 V)
> Vcore: +1.07 V (min = +0.00 V, max = +2.99 V)
> +3.3V: +3.25 V (min = +2.97 V, max = +3.63 V)
> +5V: +5.05 V (min = +4.50 V, max = +5.50 V)
> +12V: +12.12 V (min = +0.00 V, max = +15.94 V)
> fan1: 2480 RPM (min = 0 RPM)
> temp1: +35.0?C (low = -127.0?C, high = +127.0?C)
> temp2: +34.0?C (low = -127.0?C, high = +127.0?C)
> temp3: +47.0?C (low = -127.0?C, high = +127.0?C)

Note that the first above is an adt7476 and the other lm85.

There are multiple, slightly different NSA310 designs. Some have an
lm85, others have a adt7476. Which do you have? If you are using:

https://github.com/lunn/linux.git branch v3.11-rc1-nsa310-tdc you will
find two different DT descriptions for NSA310. See which works best
for you, kirkwood-nsa310.dtb or kirkwood-nsa310a.dtb.

    Andrew


From broonie at kernel.org  Wed Jul 31 12:52:43 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 31 Jul 2013 17:52:43 +0100
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731152932.GV2810@htj.dyndns.org>
References: <20130731111853.GJ9858@sirena.org.uk>
 <20130731113244.GI2810@htj.dyndns.org>
 <20130731115027.GN9858@sirena.org.uk>
 <20130731115527.GR2810@htj.dyndns.org>
 <20130731132708.GQ9858@sirena.org.uk>
 <20130731134215.GS2810@htj.dyndns.org>
 <20130731135751.GT9858@sirena.org.uk>
 <20130731140758.GT2810@htj.dyndns.org>
 <20130731152523.GW9858@sirena.org.uk>
 <20130731152932.GV2810@htj.dyndns.org>
Message-ID: <20130731165243.GX9858@sirena.org.uk>

On Wed, Jul 31, 2013 at 11:29:32AM -0400, Tejun Heo wrote:

> Yeah, sure, thank you very much for your input.  It is of course
> strictly ordered and the documentation needs to be updated.

While I note the way you're saying this given the widespread adoption I
think there's a bit more effort needed on making sure people are aware
of this model and that it's possible to do it - most of the APIs with
devres support really ought to have things like a devm_clk_get_enable()
(an example discussed further up the thread) added to them.

devres has been quite widely adopted but not in a way that supports this
usage model.
-------------- 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/20130731/7ff5a400/attachment-0001.sig>

From swarren at wwwdotorg.org  Wed Jul 31 12:57:36 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 Jul 2013 10:57:36 -0600
Subject: [PATCH] ARM: allow DEBUG_UNCOMPRESS for omap2plus
In-Reply-To: <20130731064634.GR7656@atomide.com>
References: <1375224558-8170-1-git-send-email-swarren@wwwdotorg.org>
 <20130730225233.GF21614@n2100.arm.linux.org.uk>
 <51F845C7.8020106@wwwdotorg.org> <20130731064634.GR7656@atomide.com>
Message-ID: <51F94200.2060202@wwwdotorg.org>

On 07/31/2013 12:46 AM, Tony Lindgren wrote:
> * Stephen Warren <swarren at wwwdotorg.org> [130730 16:08]:
>> On 07/30/2013 04:52 PM, Russell King - ARM Linux wrote:
>>> On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote:
>>>> From: Stephen Warren <swarren at nvidia.com>
>>>>
>>>> DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to
>>>> omap2plus.S's use of .data, which is not allowed in the decompressor.
>>>> Solve this by placing that data into .text when building the file into
>>>> the decompressor. This relies on .text actually being writable in the
>>>> decompressor, which it is in practice.
>>>
>>> Unless you decide to use ZBOOT and flash the zImage.
>>
>> I knew there had to be a catch:-)
>>
>> I have no idea if ZBOOT is a use-case that's relevant to OMAP?
>>
>> On Tegra at least (the same issue applies to the other patch I just
>> sent), that use-case is almost impossible; even if the boot ROM directly
>> booted a kernel, the boot ROM is hard-coded to copy whatever it's
>> booting to SDRAM first, although I suppose if that was a boot-loader it
>> could just jump back to a ROM location. That said, NOR flash is
>> extremely rare on Tegra. So, I don't know if we care about this issue.
>>
>> Is it reasonable to just say "If you use ZBOOT, don't enable
>> DEBUG_UNCOMPRESS"? Perhaps these patches should not completely remove
>> the !DEBUG_TEGRA_UART from config DEBUG_UNCOMPRESS, but instead say:
>>
>> default y if DEBUG_LL && (!DEBUG_TEGRA_UART || !ZBOOT)?
> 
> I think we're best off removing the remaining uncompress code
> configured port detection features as the port properties are now
> defined in kconfig anyways. That simplifies the code quite a bit.

If you want to do that with OMAP, I'm happy to drop this patch.

For Tegra, automatic determination of the DEBUG_LL UART is rather
useful, so I'm not going to give that up:-)


From Dave.Martin at arm.com  Wed Jul 31 12:59:10 2013
From: Dave.Martin at arm.com (Dave Martin)
Date: Wed, 31 Jul 2013 17:59:10 +0100
Subject: Defining schemas for Device Tree
In-Reply-To: <20130731113401.GM9858@sirena.org.uk>
References: <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <20130730205716.GZ9858@sirena.org.uk>
 <CAKON4Ox7-6Jf0ce64Wqr5E49KS+9E135mqc_iG-PWQ7r8bzWHA@mail.gmail.com>
 <20130730230331.GC9858@sirena.org.uk>
 <CAKON4OzFdZhX0Kzu_6KiimD=KxDr6EM13zUH3GGE=hHaYx=m=Q@mail.gmail.com>
 <20130731113401.GM9858@sirena.org.uk>
Message-ID: <20130731165902.GA3329@localhost.localdomain>

On Tue, Jul 30, 2013 at 09:57:16PM +0100, Mark Brown wrote:
> On Tue, Jul 30, 2013 at 01:29:56PM -0400, jonsmirl at gmail.com wrote:
> > On Tue, Jul 30, 2013 at 1:19 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> > > On 07/30/2013 07:14 AM, jonsmirl at gmail.com wrote:
> 
> > > > Is something similar to this possible in device tree syntax?
> > > > dmas =  <"tx" &pdma0 7>,  <"rx"  &pdma0 6>;
> 
> > > I /think/ you can physically write that in *.dts, or something very
> > > similar; with the strings outside the <>:
> 
> > > dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
> 
> > Can we turn the strings into string phandles? Then they'd be fixed sized.
> 
> > That might provide a way to internationalize the strings too.
> 
> I don't know how viable or sane this actually is but one suggestion I
> just made elsewhere which might help is to fix this at the dtc level by
> having syntatic sugar which will do the parallel arrays trick that
> people are currently using to write things out.  The user writes one
> array with multiple types of data in it and the actual output is two or
> more matched arrays each with a single type of data.
> 
> It would help legibility and wouldn't impact the parsers.

There may often be a conflict between making _good_ bindings, and making
bindings which are convenient for maintainers to edit in .dts syntax.

I think good bindings (in the sense of good ABI) must take precedence:
good bindings need to interoperate well over a long period of time, and
should be robust against future evolution of hardware platforms OSes.  If
they look nice in the .dts file, that's a bonus -- but I don't think it
should be viewed as a requirement.

A pair of properties like dma-names/dmas may be a bit cumbersome, but
it can be precise, unambiguous, and simple and easy to parse and check.
The semantics can be extended in the future if necessary, by adding
additional companion properties.  From my perspective, this can work as
a template for good bindings.


We could add syntactic sugar to make those property pairs easier to
maintain... but I worry that haphazard extensions to dtc may leave us
with an unmanageable syntax which we will regret later.   This seems to
be a common failure mode of domain-specific languages.

Someone trying to maintain a complex .dts can always make their own life
easier with a bit of scripting.  After all, in a future of stable
bindings, a DT really shouldn't be changing much once it is complete.
I don't see a clear reason why these issues must be solved by dtc
itself.

Cheers
---Dave


From paul.gortmaker at windriver.com  Wed Jul 31 13:06:58 2013
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Wed, 31 Jul 2013 13:06:58 -0400
Subject: [PATCH] arm: add .text at __CPUINIT places to prevent section
 grandfathering
In-Reply-To: <20130731094352.GV24642@n2100.arm.linux.org.uk>
References: <20130731094352.GV24642@n2100.arm.linux.org.uk>
Message-ID: <1375290418-1848-1-git-send-email-paul.gortmaker@windriver.com>

In commit 22f0a27367742f65130c0fb25ef00f7297e032c1
("init.h: remove __cpuinit sections from the kernel") the macros
like __CPUINIT were converted from .section commands to no-ops.

This caused CPU hotplug regressions because the code following
the __CPUINIT lines was now grandfathered into whatever the
previous section happened to be.  In most files, __CPUINIT was
at the top of the file, so there was no previous section.

However in the files changed here, there was a previous section,
and so we'd inadvertently garbage collect CPU hotplug related
code.  This changeset inserts ".text" into the exact same spot
that the __CPUINIT section markers were found prior to commit
8bd26e3a7e49af2697449bbcb7187a39dc85d672 ("arm: delete
__cpuinit/__CPUINIT usage from all ARM users:) in the three affected
files, as suggested by Russell.

Bisected-by: Simon Horman <horms at verge.net.au>
Reported-by: Magnus Damm <magnus.damm at gmail.com>
Reported-by: Russell King <rmk+kernel at arm.linux.org.uk>
Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
---

[NB: Untested - I've not got an SMP ARM handy at the moment]

 arch/arm/kernel/head-common.S | 1 +
 arch/arm/kernel/head-nommu.S  | 1 +
 arch/arm/kernel/head.S        | 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
index 47cd974..def853e 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -149,6 +149,7 @@ ENDPROC(lookup_processor_type)
  *	r5 = proc_info pointer in physical address space
  *	r9 = cpuid (preserved)
  */
+	.text
 __lookup_processor_type:
 	adr	r3, __lookup_processor_type_data
 	ldmia	r3, {r4 - r6}
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index b361de1..14235ba 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -87,6 +87,7 @@ ENTRY(stext)
 ENDPROC(stext)
 
 #ifdef CONFIG_SMP
+	.text
 ENTRY(secondary_startup)
 	/*
 	 * Common entry point for secondary CPUs.
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 9cf6063..2c7cc1e 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -343,6 +343,7 @@ __turn_mmu_on_loc:
 	.long	__turn_mmu_on_end
 
 #if defined(CONFIG_SMP)
+	.text
 ENTRY(secondary_startup)
 	/*
 	 * Common entry point for secondary CPUs.
-- 
1.8.1.2



From swarren at wwwdotorg.org  Wed Jul 31 13:08:10 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 Jul 2013 11:08:10 -0600
Subject: [PATCH V2] ARM: dts: tegra114: dalmore: fix the irq trigger type
 of Palmas MFD device
In-Reply-To: <1375261841.1231.166.camel@jlo-ubuntu-64.nvidia.com>
References: <1374663272-9937-1-git-send-email-josephl@nvidia.com>
 <51F292D4.9030208@wwwdotorg.org>
 <1375177568.1239.16.camel@jlo-ubuntu-64.nvidia.com>
 <51F7E8B5.6030009@wwwdotorg.org>
 <1375261841.1231.166.camel@jlo-ubuntu-64.nvidia.com>
Message-ID: <51F9447A.3090008@wwwdotorg.org>

On 07/31/2013 03:10 AM, Joseph Lo wrote:
> On Wed, 2013-07-31 at 00:24 +0800, Stephen Warren wrote:
>> On 07/30/2013 03:46 AM, Joseph Lo wrote:
>>> On Fri, 2013-07-26 at 23:16 +0800, Stephen Warren wrote:
>>>> On 07/24/2013 04:54 AM, Joseph Lo wrote:
>>>>> The IRQ trigger type of Palmas MFD device (tps65913) is edge trigger. The
>>>>> wrong configuration would cause an interrupt storm when booting the
>>>>> system. Fixing it in DT with appropriate interrupt type.
>>>>
>>>>> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
>>>>
>>>>>  		palmas: tps65913 {
>>>>>  			compatible = "ti,palmas";
>>>>>  			reg = <0x58>;
>>>>> -			interrupts = <0 86 0x4>;
>>>>> +			interrupts = <0 86 0x0>;
>>>>
>>>> The legal values for that final cell are:
>>>>
>>>>     - bits[3:0] trigger type and level flags
>>>>         1 = low-to-high edge triggered
>>>>         2 = high-to-low edge triggered
>>>>         4 = active high level-sensitive
>>>>         8 = active low level-sensitive
>>>>
>>>> 0 isn't one of those values. This patch can't be correct.
>>>>
>>>> BTW, this cell should use the constants from
>>>> <dt-bindings/interrupt-controller/irq.h>.
>>>
>>> Oops. I made a wrong description in the commit message.
>>>
>>> Update my test result again.
>>>
>>>> 1 = low-to-high edge triggered
>>> No IRQ storm, but the system always auto wake up by Palmas RTC.
>>>> 2 = high-to-low edge triggered
>>> No IRQ storm, but the GIC didn't support this trigger type. The flag
>>> would be re-configured as 0x0.
>>>> 4 = active high level-sensitive
>>> There is a IRQ storm when system booting.
>>>> 8 = active low level-sensitive
>>> No IRQ strom, but the GIC didn't support this trigger type. The flag
>>> would be re-configured as 0x0.
>>>
>>>> nvidia, invert-interrupt
>>> Removing this can fix IRQ storm too, but the system always auto wake up
>>> by Palmas RTC.
>>>
>>> So we can only three trigger type here.
>>> IRQ_TYPE_NONE 0
>>
>> That's not a valid value; it just means that the GIC driver doesn't
>> explicitly set the type, and the HW probably defaults to active high?
>>
> oh,yes. May be.
> 
>>> IRQ_TYPE_EDGE_FALLING 2
>>> IRQ_TYPE_LEVEL_LOW 8
>>>
>>> But using IRQ_TYPE_EDGE_FALLING or IRQ_TYPE_LEVEL_LOW, it would
>>> configure to IRQ_TYPE_NONE. Because the PMIC is low level trigger to PMC
>>> on Dalmore, I would prefer to use IRQ_TYPE_LEVEL_LOW just like the v1.
>>> Any comments?
>>
>> Comments no, I just have confusion!
>>
>> We should simply set this flag to the correct value. Does the PMIC
>> output an edge-sensitive or level-sensitive signal? Is the signal
>> active-high/rising or active-low/falling? Those are the only things that
>> should be considered when selecting the correct value for the IRQ flags.
>> This information can be determined by reading the data sheet for the
>> PMIC; while the test results you mention above are interesting, the HW
>> documentation should drive the value we select here, unless the
>> documentation has a known bug.
>>
> OK, the PMIC(Palmas here) only support level-sensitive and default is
> active low.
> 
> But it was being configured as active high in the Dalmore's DT. And yes,
> it can work fine with the configuration you mentioned below. The suspend
> mode of LP1/LP2 that could be woken up by IRQ is OK in this case.
> 
> But if checking the PMU_INT signal in the schematic of Dalmore, it only
> supports active low. It was connected to !PWR_INT of Tegra114 that will
> cause the system wake up automatically when syspended to LP0 if active
> high.
> 
> That's why my change is setting the IRQ type of PMIC to active low and
> keep the "nvidia,invert-interrupt". And it can make the LP0/1/2 work
> proper.

OK, the explanation all basically makes sense. We do clearly need to fix
the DT so that the Palmas IRQ signal polarity matches what we've
configured the Tegra PMC/GIC to expect.

However, your patch was:

		palmas:?tps65913?{
			compatible?=?"ti,palmas";
			reg?=?<0x58>;
-			interrupts?=?<0?86?0x4>;
+			interrupts?=?<0?86?0x0>;

0 isn't valid. The replacement shouldn't be 0, but instead should be
IRQ_TYPE_LEVEL_LOW.

Alternatively, it sounds fine to leave that interrupts property as-is,
and remove the pmc's nvidia,invert-interrupt. Either sound like they
should work fine, although perhaps one polarity might cause glitches
before the inversion/... is programmed in the PMIC and/or based on
whatever pull-ups/downs are on the board?

>> If there is an IRQ storm, then that sounds like a bug in the code. That
>> needs to be fixed too, not worked around by setting an incorrect IRQ
>> flags value.
>>
> By the way, don't you see IRQ storm like below(You use "if" here)?
> 
> [   87.054085] irq 118: nobody cared (try booting with the "irqpoll" option)
> [   87.060862] CPU: 0 PID: 41 Comm: irq/118-palmas Not tainted 3.11.0-rc2-next-20130722-00011-gadb202a-dirty #11
> [   87.070811] [<c0012161>] (unwind_backtrace+0x1/0x98) from [<c000f07b>] (show_stack+0xb/0xc)
> [   87.079134] [<c000f07b>] (show_stack+0xb/0xc) from [<c038af89>] (dump_stack+0x59/0x8c)
> [   87.087035] [<c038af89>] (dump_stack+0x59/0x8c) from [<c005eef9>] (__report_bad_irq+0x15/0x80)
> [   87.095676] [<c005eef9>] (__report_bad_irq+0x15/0x80) from [<c005f22d>] (note_interrupt+0x139/0x17c)
> [   87.104782] [<c005f22d>] (note_interrupt+0x139/0x17c) from [<c005e4d7>] (irq_thread+0xc3/0xd4)
> [   87.113424] [<c005e4d7>] (irq_thread+0xc3/0xd4) from [<c002f87b>] (kthread+0x6b/0x74)
> [   87.121237] [<c002f87b>] (kthread+0x6b/0x74) from [<c000ccfd>] (ret_from_fork+0x11/0x34)
> [   87.121325] vdd-sensor-2v85: disabling
> [   87.133064] handlers:
> [   87.135335] [<c005dd85>] irq_default_primary_handler threaded [<c01dbd99>] regmap_irq_thread
> [   87.143762] Disabling IRQ #118

I don't recall seeing that.

>            CPU0       CPU1       CPU2       CPU3       
> ...
>  85:     804308          0          0          0       GIC  85  i2c
> 118:     100001          0          0          0       GIC 118  palmas
> 122:        152          0          0          0       GIC 122  serial
> ...

I didn't check that.


From swarren at wwwdotorg.org  Wed Jul 31 13:14:33 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 Jul 2013 11:14:33 -0600
Subject: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
In-Reply-To: <CALicx6tJFkGbvKO+-XZixj+8RSh1awFnXK91Pdew1+5Oa+dDqg@mail.gmail.com>
References: <1374817287-27952-1-git-send-email-vijay.kilari@gmail.com>
 <20130726104908.GC17886@mudshark.cambridge.arm.com>
 <51F2ACF7.9000008@wwwdotorg.org>
 <CALicx6ugumPG__rSAsTS95SH=6fTGqhpPFsQ8bLG-u-fbk0=pQ@mail.gmail.com>
 <51F7F0E1.5030200@wwwdotorg.org>
 <CALicx6tJFkGbvKO+-XZixj+8RSh1awFnXK91Pdew1+5Oa+dDqg@mail.gmail.com>
Message-ID: <51F945F9.3050906@wwwdotorg.org>

On 07/31/2013 05:37 AM, Vijay Kilari wrote:
> On Tue, Jul 30, 2013 at 10:29 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 07/30/2013 04:37 AM, Vijay Kilari wrote:
>>> On Fri, Jul 26, 2013 at 10:38 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> ...
>>>> Does a kernel that's used as the crash kernel guarantee:
>>>>
>>>> * Never to re-use the memory that was used by the previous kernel, so
>>>> that the spin loop code/data won't be corrupted, ever, no matter how
>>>> long the crash recovery kernel runs.
>>>>
>>>> * Not use SMP, so there's never a need to re-activate the non-boot CPUs,
>>>> which might not work if they aren't truly disabled but rather just
>>>> running a pin loop?
>>>
>>> From cat /proc/iomem, normal kernel is executed from (0x80xxxxxx) with crash
>>> kernel reserved 64M at 0xa0000000
>>>
>>> 80000000-bfffffff : System RAM
>>>   80008000-805aeddf : Kernel code
>>>   805e2000-8063e427 : Kernel data
>>>   a0000000-a3ffffff : Crash kernel
>>>
>>> crash kernel is loaded to reserved memory location and is executed from there.
>>> I could confirm this from /proc/iomem when crash kernel is running
>>>
>>> a0000000-a3efffff : System RAM
>>>   a0008000-a05aeddf : Kernel code
>>>   a05e2000-a063e427 : Kernel data
>>
>> OK, but in the crash dump kernel, is 80008000..8063e427 reserved as
>> well, which would guarantee that the spin loop being executed by the
>> non-crash CPUs won't be corrupted?
> 
> The crash dump kernel runs from reserved memory area (0xa0000000 - 0xa3effffff).
>  So it should not corrupt the memory area of original kernel that was running
>  at 0x80000000,where other CPU's are in spin loop.

What about dynamic allocations?



From linux at arm.linux.org.uk  Wed Jul 31 13:16:09 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 31 Jul 2013 18:16:09 +0100
Subject: [PATCH] arm: add .text at __CPUINIT places to prevent section
 grandfathering
In-Reply-To: <1375290418-1848-1-git-send-email-paul.gortmaker@windriver.com>
References: <20130731094352.GV24642@n2100.arm.linux.org.uk>
 <1375290418-1848-1-git-send-email-paul.gortmaker@windriver.com>
Message-ID: <20130731171609.GX24642@n2100.arm.linux.org.uk>

On Wed, Jul 31, 2013 at 01:06:58PM -0400, Paul Gortmaker wrote:
> In commit 22f0a27367742f65130c0fb25ef00f7297e032c1
> ("init.h: remove __cpuinit sections from the kernel") the macros
> like __CPUINIT were converted from .section commands to no-ops.
> 
> This caused CPU hotplug regressions because the code following
> the __CPUINIT lines was now grandfathered into whatever the
> previous section happened to be.  In most files, __CPUINIT was
> at the top of the file, so there was no previous section.
> 
> However in the files changed here, there was a previous section,
> and so we'd inadvertently garbage collect CPU hotplug related
> code.  This changeset inserts ".text" into the exact same spot
> that the __CPUINIT section markers were found prior to commit
> 8bd26e3a7e49af2697449bbcb7187a39dc85d672 ("arm: delete
> __cpuinit/__CPUINIT usage from all ARM users:) in the three affected
> files, as suggested by Russell.
> 
> Bisected-by: Simon Horman <horms at verge.net.au>
> Reported-by: Magnus Damm <magnus.damm at gmail.com>
> Reported-by: Russell King <rmk+kernel at arm.linux.org.uk>
> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>

I already have this in my git tree as of this morning, thanks anyway.


From neko at bakuhatsu.net  Wed Jul 31 13:24:20 2013
From: neko at bakuhatsu.net (Matt Sealey)
Date: Wed, 31 Jul 2013 12:24:20 -0500
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <20130731134917.GN29859@e106331-lin.cambridge.arm.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
 <51F7B4C9.2060500@gmail.com>
 <20130730125650.GD28716@e106331-lin.cambridge.arm.com>
 <20130730134427.GE28716@e106331-lin.cambridge.arm.com>
 <alpine.DEB.2.02.1307301528540.4893@kaball.uk.xensource.com>
 <1375195354.32691.55.camel@kazak.uk.xensource.com>
 <CAHCPf3vUA1bD+1xPch-KZX6fdDzxsWjnVpUD39AKC=ds+EKeHQ@mail.gmail.com>
 <20130731134917.GN29859@e106331-lin.cambridge.arm.com>
Message-ID: <CAHCPf3svo2q3oCJFzGvU_EKrtvUgAzEgObaXc6aZw7AhuumePg@mail.gmail.com>

On Wed, Jul 31, 2013 at 8:49 AM, Mark Rutland <mark.rutland at arm.com> wrote:
>
> If we force the use of said bit, then new kernels cannot necessarily
> work on existing PSCI implementations (which may not handle the use of
> said bit as you expect). If we make the binding for psci-0.2 explicitly
> require the use of this bit, then future firmware/virtualisation code
> cannot provide new functionality withoot breaking backwards compatiblity
> with existing kernels, as an "arm,psci-0.2" node would be incompatible
> with an "arm,psci" node (which is all an existing kernel can handle).

Okay so fighting backwards compatibility.. what I wasn''t suggesting
was just giving bits and then knowing what the function type was from
the bit - the SMC ABI in play calls that shot. But you don't need to
(Rob's suggestion) supply two function ids for each in one property or
provide two properties for each function variant in the same node.
Doesn't that complicate parsing a little too much?

>> * An AArch64 guest under an AArch32 hypervisor/sm seems pretty weird
>> and in any case, the device tree would use the 32-bit convention (any
>> SMC64 call in 32-bit state should return "Unknown SMC Function
>> Identifier" if that bit is set)
>
> This is not allowed by the architecture.

Understood..

>> * An AArch32 guest under an AArch32  hypervisor/sm would use the
>> 32-bit convention
>> * An AArch32 guest under an AArch64 hypervisor/sm would use the 32-bit
>> convention
>
> Both of these cases are trivially mandated by the architecture.
>
>> * An AArch64 guest under an AArch64 hypervisor/sm would use the 64-bit
>> convention or the 32-bit convention depending on how the sm is
>> written, but it doesn't matter which is used if both can be
>> supported.. but you'd only want to use one of them.
>
> Not all implementation will implement both, so there needs to be a way
> to describe that. Which is actually used is up to the OS.

Okay but putting both ways in a single node, and describing two
function ids (per property or with two properties) is what I was
getting at.. for the one case where you can use both at once, the
device tree description is king here.

I am a little concerned that the support for this is going down the
route of telling the OS all possible ways to do the same thing instead
of trying to get into using a single, preferred way in the common
cases.

Putting both call methods in the same node, doubling the function id
property lengths, or suffixing function id properties to do it seems
like putting information in the tree purely for the sake of it. In
what cases would it (uncommon cases only being existing, pre-PCSI
pre-SMC-conventions potentially for other things). In the case of PSCI
there's an opportunity to be strict about it.. why would it be sane to
allow a mixed implementation? Dictate that either support all the
64-bit versions or all the 32-bit versions or both? And if both are
supported, dictate in the device tree which the OS should be using.

What about having two nodes? There is nothing in device trees that
says you can't have two psci { compatible="arm,psci-0.2" } nodes, one
with method=smc and one with method=smc64 or hvc64 or what have you.
Parsing and setup of the PSCI code can be quit early if it's not the
"desirable" method for the OS (i.e. 64-bit on a 32-bit kernel). Then
each node follows the exact same definition, and the differentiator is
the call method and not the property names or complicating their
contents.

> As far as I can tell, no-one was arguing against this strategy. However,
> for those cases where functionality is implemented for only one
> register-width, or requires a different ID per register-width, this
> needs to be described somehow.

Do implementations like this really exist and who do we need to
waterboard to make them stop doing it? :)

-- 
Matt


From sboyd at codeaurora.org  Wed Jul 31 13:32:37 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 10:32:37 -0700
Subject: [PATCH] clocksource: em_sti: Adjust clock event rating to fix
 SMP broadcast
In-Reply-To: <1375251940-7809-1-git-send-email-horms+renesas@verge.net.au>
References: <1375251940-7809-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <51F94A35.2020907@codeaurora.org>

On 07/30/13 23:25, Simon Horman wrote:
> From: Magnus Damm <damm at opensource.se>
>
> Update the STI rating from 200 to 80 to fix SMP operation with
> the ARM broadcast timer. This breakage was introduced by:
>
> f7db706 ARM: 7674/1: smp: Avoid dummy clockevent being preferred over real hardware clock-event
>
> Without this fix SMP operation is broken on EMEV2 since no
> broadcast timer interrupts trigger on the secondary CPU cores.
>
> Signed-off-by: Magnus Damm <damm at opensource.se>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> ---

This looks suspicious. Are you're purposefully deflating the rating so
that the STI timer fills in the broadcast position? Why not make the STI
cpumask be all possible CPUs? Presumably the interrupt can target all
CPUs since it isn't a per-cpu interrupt and doing this would cause the
STI to fill in the broadcast slot, leaving the per-cpu dummys in the
tick position.

>  drivers/clocksource/em_sti.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/em_sti.c b/drivers/clocksource/em_sti.c
> index b9c81b7..37b87c0 100644
> --- a/drivers/clocksource/em_sti.c
> +++ b/drivers/clocksource/em_sti.c
> @@ -300,7 +300,7 @@ static void em_sti_register_clockevent(struct em_sti_priv *p)
>  	memset(ced, 0, sizeof(*ced));
>  	ced->name = dev_name(&p->pdev->dev);
>  	ced->features = CLOCK_EVT_FEAT_ONESHOT;
> -	ced->rating = 200;
> +	ced->rating = 80;
>  	ced->cpumask = cpumask_of(0);
>  	ced->set_next_event = em_sti_clock_event_next;
>  	ced->set_mode = em_sti_clock_event_mode;


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From stefano.stabellini at eu.citrix.com  Wed Jul 31 13:44:59 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 18:44:59 +0100
Subject: [PATCH RFC 0/8] enable swiotlb-xen on arm and arm64
Message-ID: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>

Hi all,
this patch series enables xen-swiotlb on arm and arm64.

Considering that all guests, including dom0, run on xen on arm with
second stage translation enabled, it follows that without an IOMMU no
guests could actually drive the hardware.

The solution for platforms without an IOMMU is to use swiotlb-xen,
adapted to autotranslate guests. swiotlb-xen provides a set of dma_ops
that can be used by Linux to setup a contiguous buffer in stage-2
addresses and use it for dma operations.
Basically Linux asks Xen to make a buffer contiguous and gets the
machine address for it. This buffer is going to be used by lib/swiotlb.c
to allocate bounce buffers.


The first 3 patches lay the groundwork on arm and arm64 to have
alternative dma_ops and swiotlb.

The forth patch moves Xen initialization earlier so that we already know
whether we are running on Xen at the time of initializing dma_ops on the
platform.

The following patches adapt swiotlb-xen to autotranslate guests (guest
with second stage translation in hardware) and provide an arm
implementation of xen_create_contiguous_region.


Feedback is very welcome.
Cheers,

Stefano


Stefano Stabellini (8):
      arm: make SWIOTLB available
      arm: introduce a global dma_ops pointer
      arm64: do not initialize arm64_swiotlb if dma_ops is already set
      xen/arm,arm64: move Xen initialization earlier
      xen: introduce XENMEM_get_dma_buf and xen_put_dma_buf
      xen: make xen_create_contiguous_region return the dma address
      swiotlb-xen: support autotranslate guests
      xen/arm,arm64: enable SWIOTLB_XEN

 arch/arm/Kconfig                      |    8 ++
 arch/arm/common/dmabounce.c           |   10 +-
 arch/arm/include/asm/dma-mapping.h    |   27 ++++++-
 arch/arm/include/asm/xen/hypervisor.h |    6 ++
 arch/arm/include/asm/xen/page.h       |    2 +
 arch/arm/kernel/setup.c               |    2 +
 arch/arm/mm/dma-mapping.c             |    3 +
 arch/arm/xen/Makefile                 |    2 +-
 arch/arm/xen/enlighten.c              |   24 ++++--
 arch/arm/xen/mm.c                     |  118 ++++++++++++++++++++++++++
 arch/arm64/Kconfig                    |    1 +
 arch/arm64/kernel/setup.c             |    2 +
 arch/arm64/mm/dma-mapping.c           |    2 +
 arch/arm64/xen/Makefile               |    2 +-
 arch/x86/xen/mmu.c                    |    4 +-
 drivers/xen/Kconfig                   |    1 -
 drivers/xen/swiotlb-xen.c             |  147 +++++++++++++++++++++++++++++----
 include/xen/interface/memory.h        |   62 ++++++++++++++
 include/xen/xen-ops.h                 |    3 +-
 19 files changed, 391 insertions(+), 35 deletions(-)
 create mode 100644 arch/arm/xen/mm.c


From stefano.stabellini at eu.citrix.com  Wed Jul 31 13:45:27 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 18:45:27 +0100
Subject: [PATCH RFC 3/8] arm64: do not initialize arm64_swiotlb if dma_ops is
 already set
In-Reply-To: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
Message-ID: <1375292732-7627-3-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: catalin.marinas at arm.com
CC: will.deacon at arm.com
---
 arch/arm64/mm/dma-mapping.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 4bd7579..a006e84 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -63,6 +63,8 @@ static struct dma_map_ops arm64_swiotlb_dma_ops = {
 
 void __init arm64_swiotlb_init(void)
 {
+	if (dma_ops != NULL)
+		return;
 	dma_ops = &arm64_swiotlb_dma_ops;
 	swiotlb_init(1);
 }
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Jul 31 13:45:25 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 18:45:25 +0100
Subject: [PATCH RFC 1/8] arm: make SWIOTLB available
In-Reply-To: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
Message-ID: <1375292732-7627-1-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: will.deacon at arm.com
CC: linux at arm.linux.org.uk
---
 arch/arm/Kconfig                   |    7 +++++++
 arch/arm/include/asm/dma-mapping.h |   24 ++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..05125ab 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1832,6 +1832,13 @@ config CC_STACKPROTECTOR
 	  neutralized via a kernel panic.
 	  This feature requires gcc version 4.2 or above.
 
+config SWIOTLB
+	def_bool y
+	select NEED_SG_DMA_LENGTH
+
+config IOMMU_HELPER
+	def_bool SWIOTLB
+
 config XEN_DOM0
 	def_bool y
 	depends on XEN
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 5b579b9..ad89e0f 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -86,6 +86,30 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
 }
 #endif
 
+static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
+{
+	unsigned int offset = paddr & ~PAGE_MASK;
+	return pfn_to_dma(dev, paddr >> PAGE_SHIFT) + offset;
+}
+
+static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dev_addr)
+{
+	unsigned int offset = dev_addr & ~PAGE_MASK;
+	return (dma_to_pfn(dev, dev_addr) << PAGE_SHIFT) + offset;
+}
+
+static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
+{
+	if (!dev->dma_mask)
+		return 0;
+
+	return addr + size - 1 <= *dev->dma_mask;
+}
+
+static inline void dma_mark_clean(void *addr, size_t size)
+{
+}
+
 /*
  * DMA errors are defined by all-bits-set in the DMA address.
  */
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Jul 31 13:45:30 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 18:45:30 +0100
Subject: [PATCH RFC 6/8] xen: make xen_create_contiguous_region return the dma
 address
In-Reply-To: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
Message-ID: <1375292732-7627-6-git-send-email-stefano.stabellini@eu.citrix.com>

Modify xen_create_contiguous_region to return the dma address of the
newly contiguous buffer.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: david.vrabel at citrix.com
---
 arch/x86/xen/mmu.c        |    4 +++-
 drivers/xen/swiotlb-xen.c |    6 +++---
 include/xen/xen-ops.h     |    3 ++-
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index fdc3ba2..df9ab44 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2329,7 +2329,8 @@ static int xen_exchange_memory(unsigned long extents_in, unsigned int order_in,
 }
 
 int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
-				 unsigned int address_bits)
+				 unsigned int address_bits,
+				 dma_addr_t *dma_handle)
 {
 	unsigned long *in_frames = discontig_frames, out_frame;
 	unsigned long  flags;
@@ -2368,6 +2369,7 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
 
 	spin_unlock_irqrestore(&xen_reservation_lock, flags);
 
+	*dma_handle = xen_virt_to_bus(vstart);
 	return success ? 0 : -ENOMEM;
 }
 EXPORT_SYMBOL_GPL(xen_create_contiguous_region);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index aadffcf..353f013 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -126,6 +126,7 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 {
 	int i, rc;
 	int dma_bits;
+	dma_addr_t dma_handle;
 
 	dma_bits = get_order(IO_TLB_SEGSIZE << IO_TLB_SHIFT) + PAGE_SHIFT;
 
@@ -137,7 +138,7 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 			rc = xen_create_contiguous_region(
 				(unsigned long)buf + (i << IO_TLB_SHIFT),
 				get_order(slabs << IO_TLB_SHIFT),
-				dma_bits);
+				dma_bits, &dma_handle);
 		} while (rc && dma_bits++ < max_dma_bits);
 		if (rc)
 			return rc;
@@ -294,11 +295,10 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 		*dma_handle = dev_addr;
 	else {
 		if (xen_create_contiguous_region(vstart, order,
-						 fls64(dma_mask)) != 0) {
+						 fls64(dma_mask), dma_handle) != 0) {
 			free_pages(vstart, order);
 			return NULL;
 		}
-		*dma_handle = virt_to_machine(ret).maddr;
 	}
 	memset(ret, 0, size);
 	return ret;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index d6fe062..9ef704d 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -20,7 +20,8 @@ int xen_setup_shutdown_event(void);
 
 extern unsigned long *xen_contiguous_bitmap;
 int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
-				unsigned int address_bits);
+				unsigned int address_bits,
+				dma_addr_t *dma_handle);
 
 void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order);
 
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Jul 31 13:45:26 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 18:45:26 +0100
Subject: [PATCH RFC 2/8] arm: introduce a global dma_ops pointer
In-Reply-To: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
Message-ID: <1375292732-7627-2-git-send-email-stefano.stabellini@eu.citrix.com>

Initially set dma_ops to arm_dma_ops.
Use dma_ops instead of arm_dma_ops in dmabounce.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: will.deacon at arm.com
CC: linux at arm.linux.org.uk
---
 arch/arm/common/dmabounce.c        |   10 +++++-----
 arch/arm/include/asm/dma-mapping.h |    3 ++-
 arch/arm/mm/dma-mapping.c          |    3 +++
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
index 1143c4d..b626122 100644
--- a/arch/arm/common/dmabounce.c
+++ b/arch/arm/common/dmabounce.c
@@ -325,7 +325,7 @@ static dma_addr_t dmabounce_map_page(struct device *dev, struct page *page,
 		return DMA_ERROR_CODE;
 
 	if (ret == 0) {
-		arm_dma_ops.sync_single_for_device(dev, dma_addr, size, dir);
+		dma_ops->sync_single_for_device(dev, dma_addr, size, dir);
 		return dma_addr;
 	}
 
@@ -353,7 +353,7 @@ static void dmabounce_unmap_page(struct device *dev, dma_addr_t dma_addr, size_t
 
 	buf = find_safe_buffer_dev(dev, dma_addr, __func__);
 	if (!buf) {
-		arm_dma_ops.sync_single_for_cpu(dev, dma_addr, size, dir);
+		dma_ops->sync_single_for_cpu(dev, dma_addr, size, dir);
 		return;
 	}
 
@@ -397,7 +397,7 @@ static void dmabounce_sync_for_cpu(struct device *dev,
 	if (!__dmabounce_sync_for_cpu(dev, handle, size, dir))
 		return;
 
-	arm_dma_ops.sync_single_for_cpu(dev, handle, size, dir);
+	dma_ops->sync_single_for_cpu(dev, handle, size, dir);
 }
 
 static int __dmabounce_sync_for_device(struct device *dev, dma_addr_t addr,
@@ -437,7 +437,7 @@ static void dmabounce_sync_for_device(struct device *dev,
 	if (!__dmabounce_sync_for_device(dev, handle, size, dir))
 		return;
 
-	arm_dma_ops.sync_single_for_device(dev, handle, size, dir);
+	dma_ops->sync_single_for_device(dev, handle, size, dir);
 }
 
 static int dmabounce_set_mask(struct device *dev, u64 dma_mask)
@@ -445,7 +445,7 @@ static int dmabounce_set_mask(struct device *dev, u64 dma_mask)
 	if (dev->archdata.dmabounce)
 		return 0;
 
-	return arm_dma_ops.set_dma_mask(dev, dma_mask);
+	return dma_ops->set_dma_mask(dev, dma_mask);
 }
 
 static struct dma_map_ops dmabounce_ops = {
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index ad89e0f..f907f65 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -12,6 +12,7 @@
 #include <asm/memory.h>
 
 #define DMA_ERROR_CODE	(~0)
+extern struct dma_map_ops *dma_ops;
 extern struct dma_map_ops arm_dma_ops;
 extern struct dma_map_ops arm_coherent_dma_ops;
 
@@ -19,7 +20,7 @@ static inline struct dma_map_ops *get_dma_ops(struct device *dev)
 {
 	if (dev && dev->archdata.dma_ops)
 		return dev->archdata.dma_ops;
-	return &arm_dma_ops;
+	return dma_ops;
 }
 
 static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 7f9b179..870b12c 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -141,6 +141,9 @@ struct dma_map_ops arm_dma_ops = {
 };
 EXPORT_SYMBOL(arm_dma_ops);
 
+struct dma_map_ops *dma_ops = &arm_dma_ops;
+EXPORT_SYMBOL(dma_ops);
+
 static void *arm_coherent_dma_alloc(struct device *dev, size_t size,
 	dma_addr_t *handle, gfp_t gfp, struct dma_attrs *attrs);
 static void arm_coherent_dma_free(struct device *dev, size_t size, void *cpu_addr,
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Jul 31 13:45:28 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 18:45:28 +0100
Subject: [PATCH RFC 4/8] xen/arm,arm64: move Xen initialization earlier
In-Reply-To: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
Message-ID: <1375292732-7627-4-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/include/asm/xen/hypervisor.h |    6 ++++++
 arch/arm/kernel/setup.c               |    2 ++
 arch/arm/xen/enlighten.c              |   21 ++++++++++++++-------
 arch/arm64/kernel/setup.c             |    2 ++
 4 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypervisor.h b/arch/arm/include/asm/xen/hypervisor.h
index d7ab99a..17b3ea2 100644
--- a/arch/arm/include/asm/xen/hypervisor.h
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -16,4 +16,10 @@ static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
 	return PARAVIRT_LAZY_NONE;
 }
 
+#ifdef CONFIG_XEN
+void xen_early_init(void);
+#else
+static inline void xen_early_init(void) { return; }
+#endif
+
 #endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 63af9a7..cb7b8e2 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -45,6 +45,7 @@
 #include <asm/cacheflush.h>
 #include <asm/cachetype.h>
 #include <asm/tlbflush.h>
+#include <asm/xen/hypervisor.h>
 
 #include <asm/prom.h>
 #include <asm/mach/arch.h>
@@ -889,6 +890,7 @@ void __init setup_arch(char **cmdline_p)
 
 	arm_dt_init_cpu_maps();
 	psci_init();
+	xen_early_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
 		if (!mdesc->smp_init || !mdesc->smp_init()) {
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c9770ba..14d17ab 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -195,21 +195,19 @@ static void xen_power_off(void)
  * documentation of the Xen Device Tree format.
  */
 #define GRANT_TABLE_PHYSADDR 0
-static int __init xen_guest_init(void)
+void __init xen_early_init(void)
 {
-	struct xen_add_to_physmap xatp;
-	static struct shared_info *shared_info_page = 0;
+	struct resource res;
 	struct device_node *node;
 	int len;
 	const char *s = NULL;
 	const char *version = NULL;
 	const char *xen_prefix = "xen,xen-";
-	struct resource res;
 
 	node = of_find_compatible_node(NULL, NULL, "xen,xen");
 	if (!node) {
 		pr_debug("No Xen support\n");
-		return 0;
+		return;
 	}
 	s = of_get_property(node, "compatible", &len);
 	if (strlen(xen_prefix) + 3  < len &&
@@ -217,10 +215,10 @@ static int __init xen_guest_init(void)
 		version = s + strlen(xen_prefix);
 	if (version == NULL) {
 		pr_debug("Xen version not found\n");
-		return 0;
+		return;
 	}
 	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
-		return 0;
+		return;
 	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
 	xen_events_irq = irq_of_parse_and_map(node, 0);
 	pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
@@ -232,6 +230,15 @@ static int __init xen_guest_init(void)
 		xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
 	else
 		xen_start_info->flags &= ~(SIF_INITDOMAIN|SIF_PRIVILEGED);
+}
+
+static int __init xen_guest_init(void)
+{
+	struct xen_add_to_physmap xatp;
+	static struct shared_info *shared_info_page = 0;
+
+	if (!xen_domain())
+		return 0;
 
 	if (!shared_info_page)
 		shared_info_page = (struct shared_info *)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index add6ea6..e0d438a 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -53,6 +53,7 @@
 #include <asm/traps.h>
 #include <asm/memblock.h>
 #include <asm/psci.h>
+#include <asm/xen/hypervisor.h>
 
 unsigned int processor_id;
 EXPORT_SYMBOL(processor_id);
@@ -267,6 +268,7 @@ void __init setup_arch(char **cmdline_p)
 	unflatten_device_tree();
 
 	psci_init();
+	xen_early_init();
 
 	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
 #ifdef CONFIG_SMP
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Jul 31 13:45:31 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 18:45:31 +0100
Subject: [PATCH RFC 7/8] swiotlb-xen: support autotranslate guests
In-Reply-To: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
Message-ID: <1375292732-7627-7-git-send-email-stefano.stabellini@eu.citrix.com>

Support autotranslate guests in swiotlb-xen by keeping track of the
phys-to-bus and bus-to-phys mappings of the swiotlb buffer
(xen_io_tlb_start-xen_io_tlb_end).

Use a simple direct access on a pre-allocated array for phys-to-bus
queries. Use a red-black tree for bus-to-phys queries.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: david.vrabel at citrix.com
---
 drivers/xen/swiotlb-xen.c |  127 +++++++++++++++++++++++++++++++++++++++------
 1 files changed, 111 insertions(+), 16 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 353f013..c79ac88 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -38,32 +38,116 @@
 #include <linux/bootmem.h>
 #include <linux/dma-mapping.h>
 #include <linux/export.h>
+#include <linux/slab.h>
+#include <linux/spinlock_types.h>
+#include <linux/rbtree.h>
 #include <xen/swiotlb-xen.h>
 #include <xen/page.h>
 #include <xen/xen-ops.h>
 #include <xen/hvc-console.h>
+#include <xen/features.h>
 /*
  * Used to do a quick range check in swiotlb_tbl_unmap_single and
  * swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by this
  * API.
  */
 
+#define NR_DMA_SEGS  ((xen_io_tlb_nslabs + IO_TLB_SEGSIZE - 1) / IO_TLB_SEGSIZE)
 static char *xen_io_tlb_start, *xen_io_tlb_end;
 static unsigned long xen_io_tlb_nslabs;
 /*
  * Quick lookup value of the bus address of the IOTLB.
  */
 
-static u64 start_dma_addr;
+struct xen_dma{
+	dma_addr_t dma_addr;
+	phys_addr_t phys_addr;
+	size_t size;
+	struct rb_node rbnode;
+};
+
+static struct xen_dma *xen_dma_seg;
+static struct rb_root bus_to_phys = RB_ROOT;
+static DEFINE_SPINLOCK(xen_dma_lock);
+
+static void xen_dma_insert(struct xen_dma *entry)
+{
+	struct rb_node **link = &bus_to_phys.rb_node;
+	struct rb_node *parent = NULL;
+	struct xen_dma *e;
+
+	spin_lock(&xen_dma_lock);
+
+	while (*link) {
+		parent = *link;
+		e = rb_entry(parent, struct xen_dma, rbnode);
+
+		WARN_ON(entry->dma_addr == e->dma_addr);
+
+		if (entry->dma_addr < e->dma_addr)
+			link = &(*link)->rb_left;
+		else
+			link = &(*link)->rb_right;
+	}
+	rb_link_node(&entry->rbnode, parent, link);
+	rb_insert_color(&entry->rbnode, &bus_to_phys);
+
+	spin_unlock(&xen_dma_lock);
+}
+
+static struct xen_dma *xen_dma_retrieve(dma_addr_t dma_addr)
+{
+	struct rb_node *n = bus_to_phys.rb_node;
+	struct xen_dma *e;
+	
+	spin_lock(&xen_dma_lock);
+
+	while (n) {
+		e = rb_entry(n, struct xen_dma, rbnode);
+		if (e->dma_addr <= dma_addr && e->dma_addr + e->size > dma_addr) {
+			spin_unlock(&xen_dma_lock);
+			return e;
+		}
+		if (dma_addr < e->dma_addr)
+			n = n->rb_left;
+		else
+			n = n->rb_right;
+	}
+
+	spin_unlock(&xen_dma_lock);
+	return NULL;
+}
 
 static dma_addr_t xen_phys_to_bus(phys_addr_t paddr)
 {
-	return phys_to_machine(XPADDR(paddr)).maddr;
+	int nr_seg;
+	unsigned long offset;
+	char* vaddr;
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		return phys_to_machine(XPADDR(paddr)).maddr;
+
+	vaddr = (char *) phys_to_virt(paddr);
+	if (vaddr >= xen_io_tlb_end || vaddr < xen_io_tlb_start)
+		return ~0;
+
+	offset = vaddr - xen_io_tlb_start;
+	nr_seg = offset / (IO_TLB_SEGSIZE << IO_TLB_SHIFT);
+
+	return xen_dma_seg[nr_seg].dma_addr + (paddr & ((IO_TLB_SEGSIZE << IO_TLB_SHIFT) - 1));
 }
 
 static phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
 {
-	return machine_to_phys(XMADDR(baddr)).paddr;
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+	{
+		struct xen_dma *dma = xen_dma_retrieve(baddr);
+		if (dma == NULL)
+			return ~0;
+		else
+			return dma->phys_addr + (baddr & ((IO_TLB_SEGSIZE << IO_TLB_SHIFT) - 1));
+	} else
+		return machine_to_phys(XMADDR(baddr)).paddr;
 }
 
 static dma_addr_t xen_virt_to_bus(void *address)
@@ -107,6 +191,9 @@ static int is_xen_swiotlb_buffer(dma_addr_t dma_addr)
 	unsigned long pfn = mfn_to_local_pfn(mfn);
 	phys_addr_t paddr;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return 1;
+
 	/* If the address is outside our domain, it CAN
 	 * have the same virtual address as another address
 	 * in our domain. Therefore _only_ check address within our domain.
@@ -124,13 +211,12 @@ static int max_dma_bits = 32;
 static int
 xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 {
-	int i, rc;
+	int i, j, rc;
 	int dma_bits;
-	dma_addr_t dma_handle;
 
 	dma_bits = get_order(IO_TLB_SEGSIZE << IO_TLB_SHIFT) + PAGE_SHIFT;
 
-	i = 0;
+	i = j = 0;
 	do {
 		int slabs = min(nslabs - i, (unsigned long)IO_TLB_SEGSIZE);
 
@@ -138,12 +224,16 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 			rc = xen_create_contiguous_region(
 				(unsigned long)buf + (i << IO_TLB_SHIFT),
 				get_order(slabs << IO_TLB_SHIFT),
-				dma_bits, &dma_handle);
+				dma_bits, &xen_dma_seg[j].dma_addr);
+			xen_dma_seg[j].phys_addr = virt_to_phys(buf + (i << IO_TLB_SHIFT));
+			xen_dma_seg[j].size = slabs << IO_TLB_SHIFT;
+			xen_dma_insert(&xen_dma_seg[j]);
 		} while (rc && dma_bits++ < max_dma_bits);
 		if (rc)
 			return rc;
 
 		i += slabs;
+		j++;
 	} while (i < nslabs);
 	return 0;
 }
@@ -193,9 +283,10 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	if (early)
+	if (early) {
 		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
-	else {
+		xen_dma_seg = alloc_bootmem(sizeof(struct xen_dma) * NR_DMA_SEGS);
+	} else {
 #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
 #define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
 		while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
@@ -210,6 +301,7 @@ retry:
 			xen_io_tlb_nslabs = SLABS_PER_PAGE << order;
 			bytes = xen_io_tlb_nslabs << IO_TLB_SHIFT;
 		}
+		xen_dma_seg = kzalloc(sizeof(struct xen_dma) * NR_DMA_SEGS, GFP_KERNEL);
 	}
 	if (!xen_io_tlb_start) {
 		m_ret = XEN_SWIOTLB_ENOMEM;
@@ -232,7 +324,6 @@ retry:
 		m_ret = XEN_SWIOTLB_EFIXUP;
 		goto error;
 	}
-	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
 	if (early) {
 		if (swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs,
 			 verbose))
@@ -290,7 +381,8 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 
 	phys = virt_to_phys(ret);
 	dev_addr = xen_phys_to_bus(phys);
-	if (((dev_addr + size - 1 <= dma_mask)) &&
+	if (!xen_feature(XENFEAT_auto_translated_physmap) &&
+	    ((dev_addr + size - 1 <= dma_mask)) &&
 	    !range_straddles_page_boundary(phys, size))
 		*dma_handle = dev_addr;
 	else {
@@ -321,8 +413,9 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
 
 	phys = virt_to_phys(vaddr);
 
-	if (((dev_addr + size - 1 > dma_mask)) ||
-	    range_straddles_page_boundary(phys, size))
+	if (xen_feature(XENFEAT_auto_translated_physmap) ||
+		(((dev_addr + size - 1 > dma_mask)) ||
+		 range_straddles_page_boundary(phys, size)))
 		xen_destroy_contiguous_region((unsigned long)vaddr, order);
 
 	free_pages((unsigned long)vaddr, order);
@@ -351,14 +444,15 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 	 * we can safely return the device addr and not worry about bounce
 	 * buffering it.
 	 */
-	if (dma_capable(dev, dev_addr, size) &&
+	if (!xen_feature(XENFEAT_auto_translated_physmap) &&
+	    dma_capable(dev, dev_addr, size) &&
 	    !range_straddles_page_boundary(phys, size) && !swiotlb_force)
 		return dev_addr;
 
 	/*
 	 * Oh well, have to allocate and map a bounce buffer.
 	 */
-	map = swiotlb_tbl_map_single(dev, start_dma_addr, phys, size, dir);
+	map = swiotlb_tbl_map_single(dev, xen_dma_seg[0].dma_addr, phys, size, dir);
 	if (map == SWIOTLB_MAP_ERROR)
 		return DMA_ERROR_CODE;
 
@@ -494,10 +588,11 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
 
 		if (swiotlb_force ||
+		    xen_feature(XENFEAT_auto_translated_physmap) ||
 		    !dma_capable(hwdev, dev_addr, sg->length) ||
 		    range_straddles_page_boundary(paddr, sg->length)) {
 			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
-								 start_dma_addr,
+								 xen_dma_seg[0].dma_addr,
 								 sg_phys(sg),
 								 sg->length,
 								 dir);
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Jul 31 13:45:29 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 18:45:29 +0100
Subject: [PATCH RFC 5/8] xen: introduce XENMEM_get_dma_buf and xen_put_dma_buf
In-Reply-To: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
Message-ID: <1375292732-7627-5-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 include/xen/interface/memory.h |   62 ++++++++++++++++++++++++++++++++++++++++
 1 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 2ecfe4f..ffd7f4e 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -263,4 +263,66 @@ struct xen_remove_from_physmap {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
 
+#define XENMEM_get_dma_buf             26
+/*
+ * This hypercall is similar to XENMEM_exchange: it exchanges the pages
+ * passed in with a new set of pages, contiguous and under 4G if so
+ * requested. The new pages are going to be "pinned": it's guaranteed
+ * that their p2m mapping won't be changed until explicitly "unpinned".
+ * If return code is zero then @out.extent_list provides the MFNs of the
+ * newly-allocated memory.  Returns zero on complete success, otherwise
+ * a negative error code.
+ * On complete success then always @nr_exchanged == @in.nr_extents.  On
+ * partial success @nr_exchanged indicates how much work was done.
+ */
+struct xen_get_dma_buf {
+    /*
+     * [IN] Details of memory extents to be exchanged (GMFN bases).
+     * Note that @in.address_bits is ignored and unused.
+     */
+    struct xen_memory_reservation in;
+
+    /*
+     * [IN/OUT] Details of new memory extents.
+     * We require that:
+     *  1. @in.domid == @out.domid
+     *  2. @in.nr_extents  << @in.extent_order == 
+     *     @out.nr_extents << @out.extent_order
+     *  3. @in.extent_start and @out.extent_start lists must not overlap
+     *  4. @out.extent_start lists GPFN bases to be populated
+     *  5. @out.extent_start is overwritten with allocated GMFN bases
+     */
+    struct xen_memory_reservation out;
+
+    /*
+     * [OUT] Number of input extents that were successfully exchanged:
+     *  1. The first @nr_exchanged input extents were successfully
+     *     deallocated.
+     *  2. The corresponding first entries in the output extent list correctly
+     *     indicate the GMFNs that were successfully exchanged.
+     *  3. All other input and output extents are untouched.
+     *  4. If not all input exents are exchanged then the return code of this
+     *     command will be non-zero.
+     *  5. THIS FIELD MUST BE INITIALISED TO ZERO BY THE CALLER!
+     */
+    xen_ulong_t nr_exchanged;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_get_dma_buf);
+
+#define XENMEM_put_dma_buf             27
+/*
+ * XENMEM_put_dma_buf unpins a set of pages, previously pinned by
+ * XENMEM_get_dma_buf. After this call the p2m mapping of the pages can
+ * be transparently changed by the hypervisor, as usual. The pages are
+ * still accessible from the guest.
+ */
+struct xen_put_dma_buf {
+    /*
+     * [IN] Details of memory extents to be exchanged (GMFN bases).
+     * Note that @in.address_bits is ignored and unused.
+     */
+    struct xen_memory_reservation in;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_put_dma_buf);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Jul 31 13:45:32 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 18:45:32 +0100
Subject: [PATCH RFC 8/8] xen/arm,arm64: enable SWIOTLB_XEN
In-Reply-To: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
Message-ID: <1375292732-7627-8-git-send-email-stefano.stabellini@eu.citrix.com>

Xen on arm and arm64 needs SWIOTLB_XEN: when running on Xen we need to
program the hardware with mfns rather than pfns for dma addresses.
Remove SWIOTLB_XEN dependency on X86 and PCI and make XEN select
SWIOTLB_XEN on arm and arm64.

Implement xen_create_contiguous_region on arm and arm64 by using
XENMEM_get_dma_buf.

Initialize the xen-swiotlb from xen_early_init (before the native
dma_ops are initialized), set dma_ops to &xen_swiotlb_dma_ops if we are
running on Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/Kconfig                |    1 +
 arch/arm/include/asm/xen/page.h |    2 +
 arch/arm/xen/Makefile           |    2 +-
 arch/arm/xen/enlighten.c        |    3 +
 arch/arm/xen/mm.c               |  118 +++++++++++++++++++++++++++++++++++++++
 arch/arm64/Kconfig              |    1 +
 arch/arm64/xen/Makefile         |    2 +-
 drivers/xen/Kconfig             |    1 -
 drivers/xen/swiotlb-xen.c       |   18 ++++++
 9 files changed, 145 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/xen/mm.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 05125ab..72b53b9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1849,6 +1849,7 @@ config XEN
 	depends on CPU_V7 && !CPU_V6
 	depends on !GENERIC_ATOMIC64
 	select ARM_PSCI
+	select SWIOTLB_XEN
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 359a7b5..b0f7150 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -6,12 +6,14 @@
 
 #include <linux/pfn.h>
 #include <linux/types.h>
+#include <linux/dma-mapping.h>
 
 #include <xen/interface/grant_table.h>
 
 #define pfn_to_mfn(pfn)			(pfn)
 #define phys_to_machine_mapping_valid(pfn) (1)
 #define mfn_to_pfn(mfn)			(mfn)
+#define mfn_to_local_pfn(m)             (mfn_to_pfn(m))
 #define mfn_to_virt(m)			(__va(mfn_to_pfn(m) << PAGE_SHIFT))
 
 #define pte_mfn	    pte_pfn
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 4384103..66fc35d 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o hypercall.o grant-table.o
+obj-y		:= enlighten.o hypercall.o grant-table.o mm.o
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 14d17ab..06a6953 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -195,6 +195,7 @@ static void xen_power_off(void)
  * documentation of the Xen Device Tree format.
  */
 #define GRANT_TABLE_PHYSADDR 0
+extern int xen_mm_init(void);
 void __init xen_early_init(void)
 {
 	struct resource res;
@@ -230,6 +231,8 @@ void __init xen_early_init(void)
 		xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
 	else
 		xen_start_info->flags &= ~(SIF_INITDOMAIN|SIF_PRIVILEGED);
+
+	xen_mm_init();
 }
 
 static int __init xen_guest_init(void)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
new file mode 100644
index 0000000..4ba1add
--- /dev/null
+++ b/arch/arm/xen/mm.c
@@ -0,0 +1,118 @@
+#include <linux/bootmem.h>
+#include <linux/gfp.h>
+#include <linux/export.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/dma-mapping.h>
+#include <linux/vmalloc.h>
+#include <linux/swiotlb.h>
+
+#include <xen/xen.h>
+#include <xen/interface/memory.h>
+#include <xen/swiotlb-xen.h>
+
+#include <asm/cacheflush.h>
+#include <asm/xen/page.h>
+#include <asm/xen/hypercall.h>
+#include <asm/xen/interface.h>
+
+static int xen_exchange_memory(xen_ulong_t extents_in,
+			       unsigned int order_in,
+			       xen_pfn_t *pfns_in,
+			       xen_ulong_t extents_out,
+			       unsigned int order_out,
+			       xen_pfn_t *mfns_out,
+			       unsigned int address_bits)
+{
+	long rc;
+	int success;
+
+	struct xen_memory_exchange exchange = {
+		.in = {
+			.nr_extents   = extents_in,
+			.extent_order = order_in,
+			.domid        = DOMID_SELF
+		},
+		.out = {
+			.nr_extents   = extents_out,
+			.extent_order = order_out,
+			.address_bits = address_bits,
+			.domid        = DOMID_SELF
+		}
+	};
+	set_xen_guest_handle(exchange.in.extent_start, pfns_in);
+	set_xen_guest_handle(exchange.out.extent_start, mfns_out);
+
+	BUG_ON(extents_in << order_in != extents_out << order_out);
+
+
+	rc = HYPERVISOR_memory_op(XENMEM_get_dma_buf, &exchange);
+	success = (exchange.nr_exchanged == extents_in);
+
+	BUG_ON(!success && ((exchange.nr_exchanged != 0) || (rc == 0)));
+	BUG_ON(success && (rc != 0));
+
+	return success;
+}
+
+int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
+				 unsigned int address_bits,
+				 dma_addr_t *dma_handle)
+{
+	phys_addr_t pstart = __pa(vstart);
+	xen_pfn_t in_frame, out_frame;
+	int success, i;
+
+	/* 2. Get a new contiguous memory extent. */
+	in_frame = out_frame = pstart >> PAGE_SHIFT;
+	success = xen_exchange_memory(1, order, &in_frame,
+				      1, order, &out_frame,
+				      address_bits);
+
+	if (!success)
+		return -ENOMEM;
+
+	*dma_handle = out_frame << PAGE_SHIFT;
+	
+	return success ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(xen_create_contiguous_region);
+
+void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order)
+{
+	int i;
+	xen_pfn_t in_frame = __pa(vstart) >> PAGE_SHIFT;
+	struct xen_put_dma_buf buf = {
+		.in = {
+			.nr_extents   = 1,
+			.extent_order = order,
+			.domid        = DOMID_SELF
+		},
+	};
+	set_xen_guest_handle(buf.in.extent_start, &in_frame);
+
+	HYPERVISOR_memory_op(XENMEM_put_dma_buf, &buf);
+}
+EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
+
+static struct dma_map_ops xen_swiotlb_dma_ops = {
+	.mapping_error = xen_swiotlb_dma_mapping_error,
+	.alloc = xen_swiotlb_alloc_coherent,
+	.free = xen_swiotlb_free_coherent,
+	.sync_single_for_cpu = xen_swiotlb_sync_single_for_cpu,
+	.sync_single_for_device = xen_swiotlb_sync_single_for_device,
+	.sync_sg_for_cpu = xen_swiotlb_sync_sg_for_cpu,
+	.sync_sg_for_device = xen_swiotlb_sync_sg_for_device,
+	.map_sg = xen_swiotlb_map_sg_attrs,
+	.unmap_sg = xen_swiotlb_unmap_sg_attrs,
+	.map_page = xen_swiotlb_map_page,
+	.unmap_page = xen_swiotlb_unmap_page,
+	.dma_supported = xen_swiotlb_dma_supported,
+};
+
+int __init xen_mm_init(void)
+{
+	xen_swiotlb_init(1, true);
+	dma_ops = &xen_swiotlb_dma_ops;
+	return 0;
+}
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9737e97..aa1f6fb 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -209,6 +209,7 @@ config XEN_DOM0
 config XEN
 	bool "Xen guest support on ARM64 (EXPERIMENTAL)"
 	depends on ARM64 && OF
+	select SWIOTLB_XEN
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM64.
 
diff --git a/arch/arm64/xen/Makefile b/arch/arm64/xen/Makefile
index be24040..0ef9637 100644
--- a/arch/arm64/xen/Makefile
+++ b/arch/arm64/xen/Makefile
@@ -1,2 +1,2 @@
-xen-arm-y	+= $(addprefix ../../arm/xen/, enlighten.o grant-table.o)
+xen-arm-y	+= $(addprefix ../../arm/xen/, enlighten.o grant-table.o mm.o)
 obj-y		:= xen-arm.o hypercall.o
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 9e02d60..7e83688 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -140,7 +140,6 @@ config XEN_GRANT_DEV_ALLOC
 
 config SWIOTLB_XEN
 	def_bool y
-	depends on PCI && X86
 	select SWIOTLB
 
 config XEN_TMEM
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index c79ac88..4ae6cf6 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -59,6 +59,24 @@ static unsigned long xen_io_tlb_nslabs;
  * Quick lookup value of the bus address of the IOTLB.
  */
 
+#ifndef DMA_ERROR_CODE
+#define DMA_ERROR_CODE	(~0)
+#endif
+
+#ifndef CONFIG_X86
+static unsigned long dma_alloc_coherent_mask(struct device *dev,
+					    gfp_t gfp)
+{
+	unsigned long dma_mask = 0;
+
+	dma_mask = dev->coherent_dma_mask;
+	if (!dma_mask)
+		dma_mask = (gfp & GFP_DMA) ? DMA_BIT_MASK(24) : DMA_BIT_MASK(32);
+
+	return dma_mask;
+}
+#endif
+
 struct xen_dma{
 	dma_addr_t dma_addr;
 	phys_addr_t phys_addr;
-- 
1.7.2.5



From robherring2 at gmail.com  Wed Jul 31 13:49:20 2013
From: robherring2 at gmail.com (Rob Herring)
Date: Wed, 31 Jul 2013 12:49:20 -0500
Subject: [PATCH 1/7] dt: update PSCI binding documentation for v0.2
In-Reply-To: <CAHCPf3svo2q3oCJFzGvU_EKrtvUgAzEgObaXc6aZw7AhuumePg@mail.gmail.com>
References: <20130730094920.GC28716@e106331-lin.cambridge.arm.com>
 <51F7B4C9.2060500@gmail.com>
 <20130730125650.GD28716@e106331-lin.cambridge.arm.com>
 <20130730134427.GE28716@e106331-lin.cambridge.arm.com>
 <alpine.DEB.2.02.1307301528540.4893@kaball.uk.xensource.com>
 <1375195354.32691.55.camel@kazak.uk.xensource.com>
 <CAHCPf3vUA1bD+1xPch-KZX6fdDzxsWjnVpUD39AKC=ds+EKeHQ@mail.gmail.com>
 <20130731134917.GN29859@e106331-lin.cambridge.arm.com>
 <CAHCPf3svo2q3oCJFzGvU_EKrtvUgAzEgObaXc6aZw7AhuumePg@mail.gmail.com>
Message-ID: <51F94E20.7020904@gmail.com>

On 07/31/2013 12:24 PM, Matt Sealey wrote:
> On Wed, Jul 31, 2013 at 8:49 AM, Mark Rutland <mark.rutland at arm.com> wrote:

[snip]

>>> * An AArch64 guest under an AArch64 hypervisor/sm would use the 64-bit
>>> convention or the 32-bit convention depending on how the sm is
>>> written, but it doesn't matter which is used if both can be
>>> supported.. but you'd only want to use one of them.
>>
>> Not all implementation will implement both, so there needs to be a way
>> to describe that. Which is actually used is up to the OS.
> 
> Okay but putting both ways in a single node, and describing two
> function ids (per property or with two properties) is what I was
> getting at.. for the one case where you can use both at once, the
> device tree description is king here.
> 
> I am a little concerned that the support for this is going down the
> route of telling the OS all possible ways to do the same thing instead
> of trying to get into using a single, preferred way in the common
> cases.
> 
> Putting both call methods in the same node, doubling the function id
> property lengths, or suffixing function id properties to do it seems
> like putting information in the tree purely for the sake of it. In
> what cases would it (uncommon cases only being existing, pre-PCSI
> pre-SMC-conventions potentially for other things). In the case of PSCI
> there's an opportunity to be strict about it.. why would it be sane to
> allow a mixed implementation? Dictate that either support all the
> 64-bit versions or all the 32-bit versions or both? And if both are
> supported, dictate in the device tree which the OS should be using.
> 
> What about having two nodes? There is nothing in device trees that
> says you can't have two psci { compatible="arm,psci-0.2" } nodes, one
> with method=smc and one with method=smc64 or hvc64 or what have you.
> Parsing and setup of the PSCI code can be quit early if it's not the
> "desirable" method for the OS (i.e. 64-bit on a 32-bit kernel). Then
> each node follows the exact same definition, and the differentiator is
> the call method and not the property names or complicating their
> contents.

+1

This would certainly be easier for things like a hypervisor to parse and
update.

Rob



From mturquette at linaro.org  Wed Jul 31 14:08:02 2013
From: mturquette at linaro.org (Mike Turquette)
Date: Wed, 31 Jul 2013 11:08:02 -0700
Subject: [PATCH RFC 2/3] clk: cpufreq helper for voltage scaling
In-Reply-To: <51F92109.2060707@ti.com>
References: <1373247868-21444-1-git-send-email-mturquette@linaro.org>
 <1373247868-21444-3-git-send-email-mturquette@linaro.org>
 <51F92109.2060707@ti.com>
Message-ID: <20130731180802.6450.96509@quantum>

Quoting Nishanth Menon (2013-07-31 07:36:57)
> On 07/07/2013 08:44 PM, Mike Turquette wrote:
> > This patch builds on "clk: notifier handler for dynamic voltage scaling"
> > by adding a CPUfreq-specific helper function for registering a clock
> > rate-change notifier to scale regulator voltage as a function of clock
> > rate.
> >
> > In particular this patch creates an instance of struct
> > cpufreq_frequency_table and also calculate the voltage scaling latency,
> > both of which are returned to the caller for use in the CPUfreq driver.
> >
> > Signed-off-by: Mike Turquette <mturquette at linaro.org>
> > ---
> >   drivers/clk/clk-voltage-notifier.c | 71 ++++++++++++++++++++++++++++++++++++++
> >   include/linux/clk.h                |  6 ++++
> >   2 files changed, 77 insertions(+)
> 
> As stage 1 of the transition, I dont have any complaints, but for SoC 
> level, at least on OMAP, it is not just regulator and clock, we have 
> additional tweaks to do - like ABB, AVS etc.
> 
> What would you suggest as the strategy to introduce SoC specific 
> handlers for voltage notifiers that can co-exist with this?

I would suggest to use the clock rate-change notifier handlers. Every
version of these "helper" functions that I have posted are simply that:
helper functions.

There is nothing stopping you today from using the rate-change notifiers
that were merged back in v3.4 and scaling multiple regulators in a
specific order.

This patch is solving the simple case of one clock, one regulator. You
may construct your own notifier handler as needed and I have said this
many times in the past.

I would also point out that if a DT binding existed to properly express
operating points as tuples of clock/clock-rate and support for multiple
regulator/voltage pairs then I would have implemented that in this
patch. As it stands the OPP library today doesn't go into that
complexity nor does the operating-points DT binding. This patch chooses
the path of least resistance.

> 
> >
> > diff --git a/drivers/clk/clk-voltage-notifier.c b/drivers/clk/clk-voltage-notifier.c
> > index cb6b85f..8e1707f 100644
> > --- a/drivers/clk/clk-voltage-notifier.c
> > +++ b/drivers/clk/clk-voltage-notifier.c
> > @@ -10,6 +10,7 @@
> >    */
> >
> >   #include <linux/clk.h>
> > +#include <linux/cpufreq.h>
> 
> for example - we should not depend on cpufreq in a generic clock based 
> dvfs approach. we would like to allow devfreq also to transition to this.

See patch #1 in this series.

Patch #2 builds on patch #1 to handle the very common case of CPUfreq.
It is purely a helper and the goal is to reduce the duplicated
boilerplate that would go into every CPUfreq driver if this patch did
not exist.

I would also like to see devfreq drivers use this mechanism and they can
do exactly that with the stuff made available in patch #1.

There is clearly no dependency on CPUfreq for you to scale voltage from
a clock rate-change notifier.

Regards,
Mike

> 
> >   #include <linux/device.h>
> >   #include <linux/module.h>
> >   #include <linux/notifier.h>
> > @@ -133,3 +134,73 @@ void of_clk_volt_notifier_unregister(struct notifier_block *nb)
> >       kfree(vsd);
> >   }
> >   EXPORT_SYMBOL_GPL(of_clk_volt_notifier_unregister);
> > +
> > +void of_clk_cpufreq_notifier_unregister(struct notifier_block *nb,
> > +             struct cpufreq_frequency_table *freq_table)
> > +{
> > +     struct volt_scale_data *data = to_volt_scale_data(nb);
> > +     struct device *dev = data->dev;
> > +
> > +     opp_free_cpufreq_table(dev, &freq_table);
> > +     of_clk_volt_notifier_unregister(nb);
> > +}
> > +EXPORT_SYMBOL_GPL(of_clk_cpufreq_notifier_unregister);
> > +
> > +/**
> > + * of_clk_cpufreq_notifer_register - register clock notifier to scale voltage
> > + * @dev: device that owns this scaling operation
> > + * @np: pointer to device's DT node
> > + * @clk: clock whose rate-change notifier triggers voltage scaling
> > + * @supply: regulator id string
> > + * @freq_table: pointer to uninitialized CPUfreq frequency scaling table
> > + * @voltage_latency: worst case voltage scaling latency
> > + */
> > +struct notifier_block *of_clk_cpufreq_notifier_register(struct device *dev,
> > +             struct device_node *np, struct clk *clk, const char *supply,
> > +             struct cpufreq_frequency_table **table,
> > +             unsigned int *voltage_latency)
> > +{
> > +     struct notifier_block *nb;
> > +     struct volt_scale_data *vsd;
> > +     struct opp *opp;
> > +     unsigned long min, max;
> > +     int ret, i;
> > +
> > +     nb = of_clk_volt_notifier_register(dev, np, clk, supply,
> > +                     voltage_latency);
> > +     if (IS_ERR(nb))
> > +             return nb;
> > +
> > +     vsd = to_volt_scale_data(nb);
> > +
> > +     ret = opp_init_cpufreq_table(dev, table);
> > +     if (ret) {
> > +             pr_err("failed to init cpufreq table: %d\n", ret);
> > +             goto err_unregister;
> > +     }
> > +
> > +     /* find the min and max voltages and compute worst-case latency */
> > +     for (i = 0; table[0][i].frequency != CPUFREQ_TABLE_END; i++)
> > +             ;
> > +
> > +     rcu_read_lock();
> > +     opp = opp_find_freq_exact(dev,
> > +                     table[0][0].frequency * 1000, true);
> > +     min = opp_get_voltage(opp);
> > +     opp = opp_find_freq_exact(dev,
> > +                     table[0][i-1].frequency * 1000, true);
> > +     max = opp_get_voltage(opp);
> > +     rcu_read_unlock();
> > +
> > +     *voltage_latency = regulator_set_voltage_time(vsd->reg, min, max);
> > +     if (*voltage_latency < 0)
> > +             pr_warn("%s: failed to calculate voltage latency, %d\n",
> > +                             __func__, ret);
> > +
> > +     return nb;
> > +
> > +err_unregister:
> > +     of_clk_volt_notifier_unregister(nb);
> > +     return ERR_PTR(ret);
> > +}
> > +EXPORT_SYMBOL_GPL(of_clk_cpufreq_notifier_register);
> > diff --git a/include/linux/clk.h b/include/linux/clk.h
> > index 85ea520..3104883 100644
> > --- a/include/linux/clk.h
> > +++ b/include/linux/clk.h
> > @@ -86,6 +86,12 @@ struct notifier_block *of_clk_volt_notifier_register(struct device *dev,
> >               struct device_node *np, struct clk *clk, const char *supply,
> >               int *voltage_latency);
> >   void of_clk_volt_notifier_unregister(struct notifier_block *nb);
> > +struct notifier_block *of_clk_cpufreq_notifier_register(struct device *dev,
> > +             struct device_node *np, struct clk *clk, const char *supply,
> > +             struct cpufreq_frequency_table **table,
> > +             unsigned int *voltage_latency);
> > +void of_clk_cpufreq_notifier_unregister(struct notifier_block *nb,
> > +             struct cpufreq_frequency_table *freq_table);
> >
> >   #endif
> >
> >
> 
> 
> -- 
> Regards,
> Nishanth Menon


From alexandre.belloni at free-electrons.com  Wed Jul 31 14:14:07 2013
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Wed, 31 Jul 2013 20:14:07 +0200
Subject: [PATCHv2 3/3] fb: backlight: HX8357: Add HX8369 support
In-Reply-To: <002301ce8991$f9b82060$ed286120$@samsung.com>
References: <1374757513-2253-1-git-send-email-maxime.ripard@free-electrons.com>
 <1374757513-2253-4-git-send-email-maxime.ripard@free-electrons.com>
 <002301ce8991$f9b82060$ed286120$@samsung.com>
Message-ID: <51F953EF.5060107@free-electrons.com>

Hi,

On 26/07/2013 01:52, Jingoo Han wrote:
> On Thursday, July 25, 2013 10:05 PM, Maxime Ripard wrote:
>> From: Alexandre Belloni <alexandre.belloni at free-electrons.com>
>>
>> Add support for the Himax HX8369 controller as it is quite similar to the
>> hx8357.
>>
>> Signed-off-by: Alexandre Belloni <alexandre.belloni at free-electrons.com>
>> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
>> Acked-by: Jingoo Han <jg1.han at samsung.com>
>> ---
>>  drivers/video/backlight/hx8357.c | 221 ++++++++++++++++++++++++++++++++++++---
>>  1 file changed, 206 insertions(+), 15 deletions(-)
>>
> [....]
>
>> +	ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_ON);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	msleep(100);
> Hi Maxime Ripard,
>
> Could you add comment on this huge delay, too?

That one can actually be removed.

Regards,

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com



From will.deacon at arm.com  Wed Jul 31 14:21:24 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 31 Jul 2013 19:21:24 +0100
Subject: [PATCH 0/4] iommu: arm smmu: driver updates for 3.12
Message-ID: <1375294888-10826-1-git-send-email-will.deacon@arm.com>

Hi all,

Here's a set of small drivers updates to the ARM SMMU driver that went
in during the merge window. The main changes are:

 - Removal of a broken big-endian special case when setting the pgd
 - Better error reporting when running with a single, combined IRQ line
 - Removing the dynamic use of VMIDs for stage-1 mappings. This is basically
   to make life easier for hypervisors, who apparently have a hard life
   if guest OSs allocate their own VMIDs
 - Simplification of the VMID/ASID allocation scheme based on the fact
   that we're just trying to assign one ID per context-bank.

I've tested these patches with an AArch32 MMU-500 model and not seen any
problems running stage-1 DMA transactions through the SMMU.

All feedback welcome,

Will


Will Deacon (4):
  iommu: arm smmu: remove broken big-endian check
  iommu: arm smmu: tighten up global fault reporting
  iommu: arm smmu: don't use VMIDs for stage-1 translations
  iommu: arm smmu: simplify VMID and ASID allocation

 drivers/iommu/arm-smmu.c | 93 +++++++++++++++++++++++++++++-------------------
 1 file changed, 56 insertions(+), 37 deletions(-)

-- 
1.8.2.2



From will.deacon at arm.com  Wed Jul 31 14:21:27 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 31 Jul 2013 19:21:27 +0100
Subject: [PATCH 3/4] iommu: arm smmu: don't use VMIDs for stage-1 translations
In-Reply-To: <1375294888-10826-1-git-send-email-will.deacon@arm.com>
References: <1375294888-10826-1-git-send-email-will.deacon@arm.com>
Message-ID: <1375294888-10826-4-git-send-email-will.deacon@arm.com>

Although permitted by the architecture, using VMIDs for stage-1
translations causes a complete nightmare for hypervisors, who end up
having to virtualise the VMID space across VMs, which may be using
multiple VMIDs each.

To make life easier for hypervisors (which might just decide not to
support this VMID virtualisation), this patch reworks the stage-1
context-bank TLB invalidation so that:

	- Stage-1 mappings are marked non-global in the ptes
	- Each Stage-1 context-bank is assigned an ASID in TTBR0
	- VMID 0 is reserved for Stage-1 context-banks

This allows the hypervisor to overwrite the Stage-1 VMID in the CBAR
when trapping the write from the guest.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 drivers/iommu/arm-smmu.c | 59 +++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 46 insertions(+), 13 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 3a595bb..07a0308 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -87,6 +87,7 @@
 #define ARM_SMMU_PTE_AP_UNPRIV		(((pteval_t)1) << 6)
 #define ARM_SMMU_PTE_AP_RDONLY		(((pteval_t)2) << 6)
 #define ARM_SMMU_PTE_ATTRINDX_SHIFT	2
+#define ARM_SMMU_PTE_nG			(((pteval_t)1) << 11)
 
 /* Stage-2 PTE */
 #define ARM_SMMU_PTE_HAP_FAULT		(((pteval_t)0) << 6)
@@ -223,6 +224,7 @@
 #define ARM_SMMU_CB_FAR_LO		0x60
 #define ARM_SMMU_CB_FAR_HI		0x64
 #define ARM_SMMU_CB_FSYNR0		0x68
+#define ARM_SMMU_CB_S1_TLBIASID		0x610
 
 #define SCTLR_S1_ASIDPNE		(1 << 12)
 #define SCTLR_CFCFG			(1 << 7)
@@ -282,6 +284,8 @@
 #define TTBCR2_ADDR_44			4
 #define TTBCR2_ADDR_48			5
 
+#define TTBRn_HI_ASID_SHIFT		16
+
 #define MAIR_ATTR_SHIFT(n)		((n) << 3)
 #define MAIR_ATTR_MASK			0xff
 #define MAIR_ATTR_DEVICE		0x04
@@ -533,6 +537,23 @@ static void arm_smmu_tlb_sync(struct arm_smmu_device *smmu)
 	}
 }
 
+static void arm_smmu_tlb_inv_context(struct arm_smmu_cfg *cfg)
+{
+	struct arm_smmu_device *smmu = cfg->smmu;
+	void __iomem *base = ARM_SMMU_GR0(smmu);
+	bool stage1 = cfg->cbar != CBAR_TYPE_S2_TRANS;
+
+	if (stage1) {
+		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
+		writel_relaxed(cfg->vmid, base + ARM_SMMU_CB_S1_TLBIASID);
+	} else {
+		base = ARM_SMMU_GR0(smmu);
+		writel_relaxed(cfg->vmid, base + ARM_SMMU_GR0_TLBIVMID);
+	}
+
+	arm_smmu_tlb_sync(smmu);
+}
+
 static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
 {
 	int flags, ret;
@@ -621,14 +642,15 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 	cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, root_cfg->cbndx);
 
 	/* CBAR */
-	reg = root_cfg->cbar |
-	      (root_cfg->vmid << CBAR_VMID_SHIFT);
+	reg = root_cfg->cbar;
 	if (smmu->version == 1)
 	      reg |= root_cfg->irptndx << CBAR_IRPTNDX_SHIFT;
 
 	/* Use the weakest memory type, so it is overridden by the pte */
 	if (stage1)
 		reg |= (CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
+	else
+		reg |= root_cfg->vmid << CBAR_VMID_SHIFT;
 	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(root_cfg->cbndx));
 
 	if (smmu->version > 1) {
@@ -692,6 +714,8 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 	reg = __pa(root_cfg->pgd);
 	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
 	reg = (phys_addr_t)__pa(root_cfg->pgd) >> 32;
+	if (stage1)
+		reg |= root_cfg->vmid << TTBRn_HI_ASID_SHIFT;
 	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_HI);
 
 	/*
@@ -747,10 +771,6 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 		writel_relaxed(reg, cb_base + ARM_SMMU_CB_S1_MAIR0);
 	}
 
-	/* Nuke the TLB */
-	writel_relaxed(root_cfg->vmid, gr0_base + ARM_SMMU_GR0_TLBIVMID);
-	arm_smmu_tlb_sync(smmu);
-
 	/* SCTLR */
 	reg = SCTLR_CFCFG | SCTLR_CFIE | SCTLR_CFRE | SCTLR_M | SCTLR_EAE_SBOP;
 	if (stage1)
@@ -787,7 +807,8 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
 		return -ENODEV;
 	}
 
-	ret = __arm_smmu_alloc_bitmap(smmu->vmid_map, 0, ARM_SMMU_NUM_VMIDS);
+	/* VMID zero is reserved for stage-1 mappings */
+	ret = __arm_smmu_alloc_bitmap(smmu->vmid_map, 1, ARM_SMMU_NUM_VMIDS);
 	if (IS_ERR_VALUE(ret))
 		return ret;
 
@@ -847,11 +868,17 @@ static void arm_smmu_destroy_domain_context(struct iommu_domain *domain)
 	struct arm_smmu_domain *smmu_domain = domain->priv;
 	struct arm_smmu_cfg *root_cfg = &smmu_domain->root_cfg;
 	struct arm_smmu_device *smmu = root_cfg->smmu;
+	void __iomem *cb_base;
 	int irq;
 
 	if (!smmu)
 		return;
 
+	/* Disable the context bank and nuke the TLB before freeing it. */
+	cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, root_cfg->cbndx);
+	writel_relaxed(0, cb_base + ARM_SMMU_CB_SCTLR);
+	arm_smmu_tlb_inv_context(root_cfg);
+
 	if (root_cfg->irptndx != -1) {
 		irq = smmu->irqs[smmu->num_global_irqs + root_cfg->irptndx];
 		free_irq(irq, domain);
@@ -956,6 +983,11 @@ static void arm_smmu_free_pgtables(struct arm_smmu_domain *smmu_domain)
 static void arm_smmu_domain_destroy(struct iommu_domain *domain)
 {
 	struct arm_smmu_domain *smmu_domain = domain->priv;
+
+	/*
+	 * Free the domain resources. We assume that all devices have
+	 * already been detached.
+	 */
 	arm_smmu_destroy_domain_context(domain);
 	arm_smmu_free_pgtables(smmu_domain);
 	kfree(smmu_domain);
@@ -1196,7 +1228,7 @@ static int arm_smmu_alloc_init_pte(struct arm_smmu_device *smmu, pmd_t *pmd,
 	}
 
 	if (stage == 1) {
-		pteval |= ARM_SMMU_PTE_AP_UNPRIV;
+		pteval |= ARM_SMMU_PTE_AP_UNPRIV | ARM_SMMU_PTE_nG;
 		if (!(flags & IOMMU_WRITE) && (flags & IOMMU_READ))
 			pteval |= ARM_SMMU_PTE_AP_RDONLY;
 
@@ -1412,13 +1444,9 @@ static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova,
 {
 	int ret;
 	struct arm_smmu_domain *smmu_domain = domain->priv;
-	struct arm_smmu_cfg *root_cfg = &smmu_domain->root_cfg;
-	struct arm_smmu_device *smmu = root_cfg->smmu;
-	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
 
 	ret = arm_smmu_handle_mapping(smmu_domain, iova, 0, size, 0);
-	writel_relaxed(root_cfg->vmid, gr0_base + ARM_SMMU_GR0_TLBIVMID);
-	arm_smmu_tlb_sync(smmu);
+	arm_smmu_tlb_inv_context(&smmu_domain->root_cfg);
 	return ret ? ret : size;
 }
 
@@ -1541,6 +1569,7 @@ static struct iommu_ops arm_smmu_ops = {
 static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
 {
 	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+	void __iomem *sctlr_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB_SCTLR;
 	int i = 0;
 	u32 scr0 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sCR0);
 
@@ -1550,6 +1579,10 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
 		writel_relaxed(S2CR_TYPE_BYPASS, gr0_base + ARM_SMMU_GR0_S2CR(i));
 	}
 
+	/* Make sure all context banks are disabled */
+	for (i = 0; i < smmu->num_context_banks; ++i)
+		writel_relaxed(0, sctlr_base + ARM_SMMU_CB(smmu, i));
+
 	/* Invalidate the TLB, just in case */
 	writel_relaxed(0, gr0_base + ARM_SMMU_GR0_STLBIALL);
 	writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLH);
-- 
1.8.2.2



From will.deacon at arm.com  Wed Jul 31 14:21:25 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 31 Jul 2013 19:21:25 +0100
Subject: [PATCH 1/4] iommu: arm smmu: remove broken big-endian check
In-Reply-To: <1375294888-10826-1-git-send-email-will.deacon@arm.com>
References: <1375294888-10826-1-git-send-email-will.deacon@arm.com>
Message-ID: <1375294888-10826-2-git-send-email-will.deacon@arm.com>

The bottom word of the pgd should always be written to the low half of
the TTBR, so we don't need to swap anything for big-endian.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 drivers/iommu/arm-smmu.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index ebd0a4c..da8af45 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -687,15 +687,9 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 
 	/* TTBR0 */
 	reg = __pa(root_cfg->pgd);
-#ifndef __BIG_ENDIAN
 	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
 	reg = (phys_addr_t)__pa(root_cfg->pgd) >> 32;
 	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_HI);
-#else
-	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_HI);
-	reg = (phys_addr_t)__pa(root_cfg->pgd) >> 32;
-	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
-#endif
 
 	/*
 	 * TTBCR
-- 
1.8.2.2



From will.deacon at arm.com  Wed Jul 31 14:21:26 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 31 Jul 2013 19:21:26 +0100
Subject: [PATCH 2/4] iommu: arm smmu: tighten up global fault reporting
In-Reply-To: <1375294888-10826-1-git-send-email-will.deacon@arm.com>
References: <1375294888-10826-1-git-send-email-will.deacon@arm.com>
Message-ID: <1375294888-10826-3-git-send-email-will.deacon@arm.com>

On systems which use a single, combined irq line for the SMMU, context
faults may result in us spuriously reporting global faults with zero
status registers.

This patch fixes up the fsr checks in both the context and global fault
interrupt handlers, so that we only report the fault if the fsr
indicates something did indeed go awry.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 drivers/iommu/arm-smmu.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index da8af45..3a595bb 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -305,7 +305,7 @@
 #define FSR_IGN				(FSR_AFF | FSR_ASF | FSR_TLBMCF |	\
 					 FSR_TLBLKF)
 #define FSR_FAULT			(FSR_MULTI | FSR_SS | FSR_UUT |		\
-					 FSR_EF | FSR_PF | FSR_TF)
+					 FSR_EF | FSR_PF | FSR_TF | FSR_IGN)
 
 #define FSYNR0_WNR			(1 << 4)
 
@@ -590,6 +590,9 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
 	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
 
 	gfsr = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSR);
+	if (!gfsr)
+		return IRQ_NONE;
+
 	gfsynr0 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR0);
 	gfsynr1 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR1);
 	gfsynr2 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR2);
@@ -601,7 +604,7 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
 		gfsr, gfsynr0, gfsynr1, gfsynr2);
 
 	writel(gfsr, gr0_base + ARM_SMMU_GR0_sGFSR);
-	return IRQ_NONE;
+	return IRQ_HANDLED;
 }
 
 static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
-- 
1.8.2.2



From will.deacon at arm.com  Wed Jul 31 14:21:28 2013
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 31 Jul 2013 19:21:28 +0100
Subject: [PATCH 4/4] iommu: arm smmu: simplify VMID and ASID allocation
In-Reply-To: <1375294888-10826-1-git-send-email-will.deacon@arm.com>
References: <1375294888-10826-1-git-send-email-will.deacon@arm.com>
Message-ID: <1375294888-10826-5-git-send-email-will.deacon@arm.com>

We only use ASIDs and VMIDs to identify individual stage-1 and stage-2
context-banks respectively, so rather than allocate these separately
from the context-banks, just calculate them based on the context bank
index.

Note that VMIDs are offset by 1, since VMID 0 is reserved for stage-1.
This doesn't cause us any issues with the numberspaces, since the
maximum number of context banks is half the minimum number of VMIDs.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 drivers/iommu/arm-smmu.c | 33 +++++++++++----------------------
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 07a0308..f417e89 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -56,9 +56,6 @@
 /* Maximum number of mapping groups per SMMU */
 #define ARM_SMMU_MAX_SMRS		128
 
-/* Number of VMIDs per SMMU */
-#define ARM_SMMU_NUM_VMIDS		256
-
 /* SMMU global address space */
 #define ARM_SMMU_GR0(smmu)		((smmu)->base)
 #define ARM_SMMU_GR1(smmu)		((smmu)->base + (smmu)->pagesize)
@@ -369,21 +366,21 @@ struct arm_smmu_device {
 	u32				num_context_irqs;
 	unsigned int			*irqs;
 
-	DECLARE_BITMAP(vmid_map, ARM_SMMU_NUM_VMIDS);
-
 	struct list_head		list;
 	struct rb_root			masters;
 };
 
 struct arm_smmu_cfg {
 	struct arm_smmu_device		*smmu;
-	u8				vmid;
 	u8				cbndx;
 	u8				irptndx;
 	u32				cbar;
 	pgd_t				*pgd;
 };
 
+#define ARM_SMMU_CB_ASID(cfg)		((cfg)->cbndx)
+#define ARM_SMMU_CB_VMID(cfg)		((cfg)->cbndx + 1)
+
 struct arm_smmu_domain {
 	/*
 	 * A domain can span across multiple, chained SMMUs and requires
@@ -545,10 +542,12 @@ static void arm_smmu_tlb_inv_context(struct arm_smmu_cfg *cfg)
 
 	if (stage1) {
 		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
-		writel_relaxed(cfg->vmid, base + ARM_SMMU_CB_S1_TLBIASID);
+		writel_relaxed(ARM_SMMU_CB_ASID(cfg),
+			       base + ARM_SMMU_CB_S1_TLBIASID);
 	} else {
 		base = ARM_SMMU_GR0(smmu);
-		writel_relaxed(cfg->vmid, base + ARM_SMMU_GR0_TLBIVMID);
+		writel_relaxed(ARM_SMMU_CB_VMID(cfg),
+			       base + ARM_SMMU_GR0_TLBIVMID);
 	}
 
 	arm_smmu_tlb_sync(smmu);
@@ -650,7 +649,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 	if (stage1)
 		reg |= (CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
 	else
-		reg |= root_cfg->vmid << CBAR_VMID_SHIFT;
+		reg |= ARM_SMMU_CB_VMID(root_cfg) << CBAR_VMID_SHIFT;
 	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(root_cfg->cbndx));
 
 	if (smmu->version > 1) {
@@ -715,7 +714,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain)
 	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_LO);
 	reg = (phys_addr_t)__pa(root_cfg->pgd) >> 32;
 	if (stage1)
-		reg |= root_cfg->vmid << TTBRn_HI_ASID_SHIFT;
+		reg |= ARM_SMMU_CB_ASID(root_cfg) << TTBRn_HI_ASID_SHIFT;
 	writel_relaxed(reg, cb_base + ARM_SMMU_CB_TTBR0_HI);
 
 	/*
@@ -807,12 +806,6 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
 		return -ENODEV;
 	}
 
-	/* VMID zero is reserved for stage-1 mappings */
-	ret = __arm_smmu_alloc_bitmap(smmu->vmid_map, 1, ARM_SMMU_NUM_VMIDS);
-	if (IS_ERR_VALUE(ret))
-		return ret;
-
-	root_cfg->vmid = ret;
 	if (smmu->features & ARM_SMMU_FEAT_TRANS_NESTED) {
 		/*
 		 * We will likely want to change this if/when KVM gets
@@ -831,10 +824,9 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
 	ret = __arm_smmu_alloc_bitmap(smmu->context_map, start,
 				      smmu->num_context_banks);
 	if (IS_ERR_VALUE(ret))
-		goto out_free_vmid;
+		return ret;
 
 	root_cfg->cbndx = ret;
-
 	if (smmu->version == 1) {
 		root_cfg->irptndx = atomic_inc_return(&smmu->irptndx);
 		root_cfg->irptndx %= smmu->num_context_irqs;
@@ -858,8 +850,6 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
 
 out_free_context:
 	__arm_smmu_free_bitmap(smmu->context_map, root_cfg->cbndx);
-out_free_vmid:
-	__arm_smmu_free_bitmap(smmu->vmid_map, root_cfg->vmid);
 	return ret;
 }
 
@@ -884,7 +874,6 @@ static void arm_smmu_destroy_domain_context(struct iommu_domain *domain)
 		free_irq(irq, domain);
 	}
 
-	__arm_smmu_free_bitmap(smmu->vmid_map, root_cfg->vmid);
 	__arm_smmu_free_bitmap(smmu->context_map, root_cfg->cbndx);
 }
 
@@ -1936,7 +1925,7 @@ static int arm_smmu_device_remove(struct platform_device *pdev)
 		of_node_put(master->of_node);
 	}
 
-	if (!bitmap_empty(smmu->vmid_map, ARM_SMMU_NUM_VMIDS))
+	if (!bitmap_empty(smmu->context_map, ARM_SMMU_MAX_CBS))
 		dev_err(dev, "removing device with active domains!\n");
 
 	for (i = 0; i < smmu->num_global_irqs; ++i)
-- 
1.8.2.2



From r.sricharan at ti.com  Wed Jul 31 14:31:47 2013
From: r.sricharan at ti.com (Sricharan R)
Date: Thu, 1 Aug 2013 00:01:47 +0530
Subject: [PATCH v2 4/6] ARM: mm: LPAE: Correct virt_to_phys patching for
 64 bit physical addresses
In-Reply-To: <1375289086-5315-5-git-send-email-santosh.shilimkar@ti.com>
References: <1375289086-5315-1-git-send-email-santosh.shilimkar@ti.com>
 <1375289086-5315-5-git-send-email-santosh.shilimkar@ti.com>
Message-ID: <51F95813.2060508@ti.com>

Hi,
On Wednesday 31 July 2013 10:14 PM, Santosh Shilimkar wrote:
> From: Sricharan R <r.sricharan at ti.com>
>
> The current phys_to_virt patching mechanism does not work
> for 64 bit physical addressesp. Note that constant used in add/sub
> instructions is encoded in to the last 8 bits of the opcode. So shift
> the _pv_offset constant by 24 to get it in to the correct place.
>
> The v2p patching mechanism patches the higher 32bits of physical
> address with a constant. While this is correct, in those platforms
> where the lowmem addressable physical memory spawns across 4GB boundary,
> a carry bit can be produced as a result of addition of lower 32bits.
> This has to be taken in to account and added in to the upper. The patched
> __pv_offset and va are added in lower 32bits, where __pv_offset can be
> in two's complement form when PA_START < VA_START and that can result
> in a false carry bit.
>
> e.g PA = 0x80000000 VA = 0xC0000000
> __pv_offset = PA - VA = 0xC0000000 (2's complement)
>
> So adding __pv_offset + VA should never result in a true overflow. So in
> order to differentiate between a true carry, a __pv_offset is extended
> to 64bit and the upper 32bits will have 0xffffffff if __pv_offset is
> 2's complement. We are using the same to insert 'mvn #0' instead of
> 'mov' while patching.
>
> The above idea was suggested by Nicolas Pitre <nico at linaro.org> as
> part of the review of first version of the subject patch.
>
> There is no corresponding change on the phys_to_virt() side, because
> computations on the upper 32-bits would be discarded anyway.
>
> Cc: Nicolas Pitre <nico at linaro.org>
> Cc: Russell King <linux at arm.linux.org.uk>
>
> Signed-off-by: Sricharan R <r.sricharan at ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
> ---
>  arch/arm/include/asm/memory.h |   35 +++++++++++++++++++--
>  arch/arm/kernel/armksyms.c    |    1 +
>  arch/arm/kernel/head.S        |   68 +++++++++++++++++++++++++++++++----------
>  3 files changed, 85 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index d9b96c65..abe879d 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -174,7 +174,9 @@
>  #define __PV_BITS_31_24	0x81000000
>  
>  extern phys_addr_t (*arch_virt_to_idmap) (unsigned long x);
> -extern unsigned long __pv_phys_offset;
> +extern phys_addr_t __pv_phys_offset;
> +extern phys_addr_t __pv_offset;
> +
>  #define PHYS_OFFSET __pv_phys_offset
>  
>  #define __pv_stub(from,to,instr,type)			\
> @@ -186,10 +188,37 @@ extern unsigned long __pv_phys_offset;
>  	: "=r" (to)					\
>  	: "r" (from), "I" (type))
>  
> +#define __pv_stub_mov_hi(t)				\
> +	__asm__ volatile("@ __pv_stub_mov\n"		\
> +	"1:	mov	%R0, %1\n"			\
> +	"	.pushsection .pv_table,\"a\"\n"		\
> +	"	.long	1b\n"				\
> +	"	.popsection\n"				\
> +	: "=r" (t)					\
> +	: "I" (__PV_BITS_31_24))
> +
> +#define __pv_add_carry_stub(x, y)			\
> +	__asm__ volatile("@ __pv_add_carry_stub\n"	\
> +	"1:	adds	%Q0, %1, %2\n"			\
> +	"2:	adc	%R0, %R0, #0\n"			\
> +	"	.pushsection .pv_table,\"a\"\n"		\
> +	"	.long	1b\n"				\
> +	"	.long	2b\n"				\
> +	"	.popsection\n"				\
> +	: "+r" (y)					\
> +	: "r" (x), "I" (__PV_BITS_31_24)		\
> +	: "cc")
> +
>  static inline phys_addr_t __virt_to_phys(unsigned long x)
>  {
> -	unsigned long t;
> -	__pv_stub(x, t, "add", __PV_BITS_31_24);
> +	phys_addr_t t = 0;
> +
> +	if (sizeof(phys_addr_t) == 4) {
> +		__pv_stub(x, t, "add", __PV_BITS_31_24);
> +	} else {
> +		__pv_stub_mov_hi(t);
> +		__pv_add_carry_stub(x, t);
> +	}
>  	return t;
>  }
>  
> diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
> index 60d3b73..1f031dd 100644
> --- a/arch/arm/kernel/armksyms.c
> +++ b/arch/arm/kernel/armksyms.c
> @@ -155,4 +155,5 @@ EXPORT_SYMBOL(__gnu_mcount_nc);
>  
>  #ifdef CONFIG_ARM_PATCH_PHYS_VIRT
>  EXPORT_SYMBOL(__pv_phys_offset);
> +EXPORT_SYMBOL(__pv_offset);
>  #endif
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 9cf6063..aa3b0f7 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -545,17 +545,22 @@ ENDPROC(fixup_smp)
>  	__HEAD
>  __fixup_pv_table:
>  	adr	r0, 1f
> -	ldmia	r0, {r3-r5, r7}
> +	ldmia	r0, {r3-r7}
> +	cmp	r0, r3
> +	mvn	ip, #0
>  	sub	r3, r0, r3	@ PHYS_OFFSET - PAGE_OFFSET
>  	add	r4, r4, r3	@ adjust table start address
>  	add	r5, r5, r3	@ adjust table end address
> -	add	r7, r7, r3	@ adjust __pv_phys_offset address
> -	str	r8, [r7]	@ save computed PHYS_OFFSET to __pv_phys_offset
> +	add	r6, r6, r3	@ adjust __pv_phys_offset address
> +	add	r7, r7, r3	@ adjust __pv_offset address
> +	str	r8, [r6]	@ save computed PHYS_OFFSET to __pv_phys_offset
> +	strcc	ip, [r7, #4]	@ save to __pv_offset high bits
>  	mov	r6, r3, lsr #24	@ constant for add/sub instructions
>  	teq	r3, r6, lsl #24 @ must be 16MiB aligned
>  THUMB(	it	ne		@ cross section branch )
>  	bne	__error
> -	str	r6, [r7, #4]	@ save to __pv_offset
> +	lsl	r6, r6, #24
> +	str	r6, [r7]	@ save to __pv_offset low bits
>  	b	__fixup_a_pv_table
>  ENDPROC(__fixup_pv_table)
>  
> @@ -564,6 +569,7 @@ ENDPROC(__fixup_pv_table)
>  	.long	__pv_table_begin
>  	.long	__pv_table_end
>  2:	.long	__pv_phys_offset
> +	.long	__pv_offset
>  
>  	.text
>  __fixup_a_pv_table:
> @@ -589,27 +595,53 @@ __fixup_a_pv_table:
>  	bcc	1b
>  	bx	lr
>  #else
> -	b	2f
> +	adr	r0, 5f
> +	b	4f
>  1:	ldr	ip, [r7, r3]
> -	bic	ip, ip, #0x000000ff
> -	orr	ip, ip, r6	@ mask in offset bits 31-24
> -	str	ip, [r7, r3]
> -2:	cmp	r4, r5
> +	lsr	r6, ip, #20		@ extract opcode
> +	and	r6, r6, #0x3e
> +	cmp	r6, #0x28		@ check for 'add' instruction
> +	beq	2f
> +	cmp	r6, #0x24		@ check for 'sub' instruction
> +	beq	2f
> +	cmp	r6, #0x2a		@ check for 'adc' instruction
> +	beq	4f
> +	ldr	r6, [r0]
> +	add	r6, r6, r3
> +	ldr	r6, [r6, #4]
> +	mvn	r11, #0
> +	cmp	r11, r6
> +	and	ip, ip, #0xf000		@ Register encoded in inst
> +	orrne	ip, ip, r6
> +	ldreq	r6, [r0, #0x4]		@ mvn if _pv_offset high bits is 0xffffffff
> +	ldrne	r6, [r0, #0x8]		@ mov otherwise
> +	bic	r6, r6, #0xff
> +	bic	r6, r6, #0xf00
> +	orr	ip, ip, r6
> +	b	3f
> +2:	ldr	r6, [r0]
> +	ldr	r6, [r6, r3]
> +	bic	ip, ip, #0xff
> +	orr	ip, ip, r6, lsr #24	@ mask in offset bits 31-24
> +3:	str	ip, [r7, r3]
> +4:	cmp	r4, r5
>  	ldrcc	r7, [r4], #4	@ use branch for delay slot
>  	bcc	1b
>  	mov	pc, lr
>  #endif
>  ENDPROC(__fixup_a_pv_table)
>  
> +5:	.long __pv_offset
> +	mvn	r0, #0
> +	mov	r0, #0x81000000 @ For getting the correct 4 byte encoding
> +
>  ENTRY(fixup_pv_table)
> -	stmfd	sp!, {r4 - r7, lr}
> -	ldr	r2, 2f			@ get address of __pv_phys_offset
> +	stmfd	sp!, {r0, r3 - r7, r11 - r12, lr}
>  	mov	r3, #0			@ no offset
>  	mov	r4, r0			@ r0 = table start
>  	add	r5, r0, r1		@ r1 = table size
> -	ldr	r6, [r2, #4]		@ get __pv_offset
>  	bl	__fixup_a_pv_table
> -	ldmfd	sp!, {r4 - r7, pc}
> +	ldmfd	sp!, {r0, r3 - r7, r11 - r12, pc}
>  ENDPROC(fixup_pv_table)
>  
>  	.align
> @@ -619,10 +651,14 @@ ENDPROC(fixup_pv_table)
>  	.globl	__pv_phys_offset
>  	.type	__pv_phys_offset, %object
>  __pv_phys_offset:
> -	.long	0
> -	.size	__pv_phys_offset, . - __pv_phys_offset
> +	.quad	0
> +
> +	.data
> +	.globl __pv_offset
> +	.type __pv_offset, %object
>  __pv_offset:
> -	.long	0
> +	.quad   0
> +
>  #endif
>  
>  #include "head-common.S"

Just, had another way of implementing this without using the
'opcodes'. By adding a additional data in the stub which would identify
the previous instruction instead of using opcodes. This can make the
patching code little simpler.
Incase, if using opcodes is not good. Like this,

#define PATCH_ADDS      0
#define PATCH_ADDC      1

#define __pv_add_carry_stub(x, y)			\
	__asm__ volatile("@ __pv_add_carry_stub\n"	\
	"1:	adds	%Q0, %1, %2\n"			\
	"2:	adc	%R0, %R0, #0\n"			\
	"	.pushsection .pv_table,\"a\"\n"		\
	"	.long	1b\n"				\
	"       .long (" __stringify(PATCH_ADDS) ")\n"  \  
	"	.long	2b\n"				\   
	"       .long (" __stringify(PATCH_ADDC) ")\n"  \  
	"	.popsection\n"				\
	: "+r" (y)					\
	: "r" (x), "I" (__PV_BITS_31_24)		\
	: "cc")


Regards,
 Sricharan


From magnus.damm at gmail.com  Wed Jul 31 14:38:08 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 03:38:08 +0900
Subject: [PATCH 00/02] ARM: shmobile: Per-CPU SMP boot / sleep code
Message-ID: <20130731183808.31551.47235.sendpatchset@w520>

ARM: shmobile: Per-CPU SMP boot / sleep code

[PATCH 01/02] ARM: shmobile: Introduce per-CPU SMP boot / sleep code
[PATCH 02/02] ARM: shmobile: Per-CPU SMP boot / sleep code for SCU SoCs

This series adds per-CPU SMP boot / sleep code to mach-shmobile and ties
it in with the Cortex-A9 SoCs using the shared SCU code. With this code
in place mach-shmobile has a common per-CPU demuxer that CPUs to start
from and a place where CPUs also go to sleep (perhaps forever).

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Written against renesas.git renesas-devel-20130731 and
 [PATCH 00/07] ARM: shmobile: sh73a0, r8a7779 and emev2 SMP SCU rework
 
 Requires "[PATCH] ARM: Fix memblock_reserve() to include stext" during
 run time to allow test of CPU Hotplug with v3.11-rc kernels.

 arch/arm/mach-shmobile/headsmp.S             |   50 ++++++++++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/common.h |    4 ++
 arch/arm/mach-shmobile/platsmp-scu.c         |   17 +++++---
 arch/arm/mach-shmobile/platsmp.c             |   18 +++++++++
 4 files changed, 83 insertions(+), 6 deletions(-)


From magnus.damm at gmail.com  Wed Jul 31 14:38:18 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 03:38:18 +0900
Subject: [PATCH 01/02] ARM: shmobile: Introduce per-CPU SMP boot / sleep code
In-Reply-To: <20130731183808.31551.47235.sendpatchset@w520>
References: <20130731183808.31551.47235.sendpatchset@w520>
Message-ID: <20130731183818.31551.51694.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Add per-CPU SMP boot / sleep code that can be used by all
SoCs included in mach-shmobile.

The boot code reads out the per-CPU MPIDR id value and
matches it with the value stored for any CPU number, and
if there is a match and the boot function is set as well
then the boot function will be executed.

The sleep code simply uses WFI and then jumps back to the
boot code to see if anyone has asked to wake up that CPU,
if not it will sleep again.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/headsmp.S             |   50 ++++++++++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/common.h |    4 ++
 arch/arm/mach-shmobile/platsmp.c             |   18 +++++++++
 3 files changed, 72 insertions(+)

--- 0001/arch/arm/mach-shmobile/headsmp.S
+++ work/arch/arm/mach-shmobile/headsmp.S	2013-07-31 12:23:20.000000000 +0900
@@ -40,3 +40,53 @@ shmobile_boot_fn:
 	.globl	shmobile_boot_arg
 shmobile_boot_arg:
 2:	.space	4
+
+/*
+ * Per-CPU SMP boot function/argument selection code based on MPIDR
+ */
+
+ENTRY(shmobile_smp_boot)
+						@ r0 = MPIDR_HWID_BITMASK
+	mrc	p15, 0, r1, c0, c0, 5		@ r1 = MPIDR
+	and	r0, r1, r0			@ r0 = cpu_logical_map() value
+	mov	r1, #0				@ r1 = CPU index
+	adr	r5, 1f				@ array of per-cpu mpidr values
+	adr	r6, 2f				@ array of per-cpu functions
+	adr	r7, 3f				@ array of per-cpu arguments
+	
+shmobile_smp_boot_find_mpidr:
+	ldr	r8, [r5, r1, lsl #2]
+	cmp	r8, r0
+	bne	shmobile_smp_boot_next
+
+	ldr	r9, [r6, r1, lsl #2]
+	cmp	r9, #0
+	bne	shmobile_smp_boot_found
+	
+shmobile_smp_boot_next:
+	add	r1, r1, #1
+	cmp	r1, #CONFIG_NR_CPUS
+	blo	shmobile_smp_boot_find_mpidr
+
+	b	shmobile_smp_sleep
+	
+shmobile_smp_boot_found:
+	ldr	r0, [r7, r1, lsl #2]
+	mov	pc, r9
+ENDPROC(shmobile_smp_boot)
+
+ENTRY(shmobile_smp_sleep)
+	wfi
+	b	shmobile_smp_boot
+ENDPROC(shmobile_smp_sleep)
+
+	.globl	shmobile_smp_mpidr
+shmobile_smp_mpidr:
+1:	.space	CONFIG_NR_CPUS * 4
+	.globl	shmobile_smp_fn
+shmobile_smp_fn:
+2:	.space	CONFIG_NR_CPUS * 4
+	.globl	shmobile_smp_arg
+shmobile_smp_arg:
+3:	.space	CONFIG_NR_CPUS * 4
+
--- 0006/arch/arm/mach-shmobile/include/mach/common.h
+++ work/arch/arm/mach-shmobile/include/mach/common.h	2013-07-31 12:18:01.000000000 +0900
@@ -10,6 +10,10 @@ extern void shmobile_setup_console(void)
 extern void shmobile_boot_vector(void);
 extern unsigned long shmobile_boot_fn;
 extern unsigned long shmobile_boot_arg;
+extern void shmobile_smp_boot(void);
+extern void shmobile_smp_sleep(void);
+extern void shmobile_smp_hook(unsigned int cpu, unsigned long fn,
+			      unsigned long arg);
 extern void shmobile_boot_scu(void);
 extern void shmobile_smp_scu_prepare_cpus(unsigned int max_cpus);
 extern int shmobile_smp_scu_boot_secondary(unsigned int cpu,
--- 0001/arch/arm/mach-shmobile/platsmp.c
+++ work/arch/arm/mach-shmobile/platsmp.c	2013-07-31 12:18:01.000000000 +0900
@@ -12,6 +12,9 @@
  */
 #include <linux/init.h>
 #include <linux/smp.h>
+#include <asm/cacheflush.h>
+#include <asm/smp_plat.h>
+#include <mach/common.h>
 
 void __init shmobile_smp_init_cpus(unsigned int ncores)
 {
@@ -26,3 +29,18 @@ void __init shmobile_smp_init_cpus(unsig
 	for (i = 0; i < ncores; i++)
 		set_cpu_possible(i, true);
 }
+
+extern unsigned long shmobile_smp_fn[];
+extern unsigned long shmobile_smp_arg[];
+extern unsigned long shmobile_smp_mpidr[];
+
+void shmobile_smp_hook(unsigned int cpu, unsigned long fn, unsigned long arg)
+{
+	shmobile_smp_fn[cpu] = 0;
+	flush_cache_all();
+
+	shmobile_smp_mpidr[cpu] = cpu_logical_map(cpu);
+	shmobile_smp_fn[cpu] = fn;
+	shmobile_smp_arg[cpu] = arg;
+	flush_cache_all();
+}


From magnus.damm at gmail.com  Wed Jul 31 14:38:27 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 03:38:27 +0900
Subject: [PATCH 02/02] ARM: shmobile: Per-CPU SMP boot / sleep code for SCU
 SoCs
In-Reply-To: <20130731183808.31551.47235.sendpatchset@w520>
References: <20130731183808.31551.47235.sendpatchset@w520>
Message-ID: <20130731183827.31551.83583.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Hook in the per-CPU boot and sleep code in the shared
mach-shmobile SCU code. CPUs may be kept in the asm
routine until ->boot_secondary() when the per-CPU
boot vector is installed. At the end of ->die() the
asm sleep routine is invoked.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/platsmp-scu.c |   17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

--- 0006/arch/arm/mach-shmobile/platsmp-scu.c
+++ work/arch/arm/mach-shmobile/platsmp-scu.c	2013-07-31 12:18:32.000000000 +0900
@@ -18,8 +18,9 @@
 
 void __init shmobile_smp_scu_prepare_cpus(unsigned int max_cpus)
 {
-	shmobile_boot_fn = virt_to_phys(shmobile_boot_scu);
-	shmobile_boot_arg = (unsigned long)shmobile_scu_base;
+	/* install boot code shared by all CPUs */
+	shmobile_boot_fn = virt_to_phys(shmobile_smp_boot);
+	shmobile_boot_arg = MPIDR_HWID_BITMASK;
 
 	/* enable SCU and cache coherency on booting CPU */
 	scu_enable(shmobile_scu_base);
@@ -28,22 +29,26 @@ void __init shmobile_smp_scu_prepare_cpu
 
 int shmobile_smp_scu_boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
-	/* do nothing for now */
+	/* For this particular CPU register SCU boot vector */
+	shmobile_smp_hook(cpu, virt_to_phys(shmobile_boot_scu),
+			  (unsigned long)shmobile_scu_base);
 	return 0;
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
 void shmobile_smp_scu_cpu_die(unsigned int cpu)
 {
+	/* For this particular CPU deregister boot vector */
+	shmobile_smp_hook(cpu, 0, 0);
+
 	dsb();
 	flush_cache_all();
 
 	/* disable cache coherency */
 	scu_power_mode(shmobile_scu_base, SCU_PM_POWEROFF);
 
-	/* Endless loop until reset */
-	while (1)
-		cpu_do_idle();
+	/* jump to shared mach-shmobile sleep / reset code */
+	shmobile_smp_sleep();
 }
 
 static int shmobile_smp_scu_psr_core_disabled(int cpu)


From joe at perches.com  Wed Jul 31 14:56:38 2013
From: joe at perches.com (Joe Perches)
Date: Wed, 31 Jul 2013 11:56:38 -0700
Subject: [PATCH v3] net: Add MOXA ART SoCs ethernet driver
In-Reply-To: <1375280401-5564-1-git-send-email-jonas.jensen@gmail.com>
References: <1374842890-20735-1-git-send-email-jonas.jensen@gmail.com>
 <1375280401-5564-1-git-send-email-jonas.jensen@gmail.com>
Message-ID: <1375296998.5729.8.camel@joe-AO722>

On Wed, 2013-07-31 at 16:20 +0200, Jonas Jensen wrote:
> The MOXA UC-711X hardware(s) has an ethernet controller that seem to be
> developed internally. The IC used is "RTL8201CP".

Just some simple comments...

> diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
[]
> +static int moxart_rx_poll(struct napi_struct *napi, int budget)
[]
> +	while (1) {
[]
> +		if (ui & (RX_ERR | CRC_ERR | FTL | RUNT | RX_ODD_NB)) {
> +			netdev_err(ndev, "packet error\n");

This is generally a bad idea as it can flood
the log.  It's probably better to remove it.
If you really want logging, then at least use
net_ratelimit().  Generally, the stats are
enough.

> +			priv->stats.rx_dropped++;
> +			priv->stats.rx_errors++;
[]
> +static int moxart_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
[]
> +	if (txdesc->txdes0.ubit.tx_dma_own) {
> +		netdev_err(ndev, "no TX space for packet\n");
> +		priv->stats.tx_dropped++;

here too.

> +static int moxart_mac_probe(struct platform_device *pdev)
[]
> +	priv->tx_buf_base = kmalloc(priv->tx_buf_size * TX_DESC_NUM,
> +				    GFP_ATOMIC);
> +	if (!priv->tx_buf_base) {
> +		netdev_err(ndev, "TX buffer alloc failed\n");
> +		goto init_fail;
> +	}
> +
> +	priv->rx_buf_base = kmalloc(priv->rx_buf_size * RX_DESC_NUM,
> +				    GFP_ATOMIC);
> +	if (!priv->rx_buf_base) {
> +		netdev_err(ndev, "RX buffer alloc failed\n");
> +		goto init_fail;
> +	}

Extra OOM messages aren't useful, there's a generic
OOM and a dump_stack from the kernel.

> +	netdev_dbg(ndev, "%s: IRQ=%d address=%02x:%02x:%02x:%02x:%02x:%02x\n",
> +		   __func__, ndev->irq,
> +		   ndev->dev_addr[0], ndev->dev_addr[1], ndev->dev_addr[2],
> +		   ndev->dev_addr[3], ndev->dev_addr[4], ndev->dev_addr[5]);

There's a mac address helper you can use:

	netdev_dbg(ndev, "%s: IRQ=%d address=%pM\n"
		   __func__, ndev->irq, ndev->dev_addr);




From tomasz.figa at gmail.com  Wed Jul 31 14:58:48 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 31 Jul 2013 20:58:48 +0200
Subject: [PATCH v2 6/8] usb: host: ohci-s3c2410 Use
 clk_prepare_enable/clk_disable_unprepare
In-Reply-To: <1374536965-3545-7-git-send-email-tomasz.figa@gmail.com>
References: <1374536965-3545-1-git-send-email-tomasz.figa@gmail.com>
 <1374536965-3545-7-git-send-email-tomasz.figa@gmail.com>
Message-ID: <6370497.apKG6kIlfT@flatron>

Alan, Greg,

On Tuesday 23 of July 2013 01:49:23 Tomasz Figa wrote:
> This patch modifies the ohci-s3c2410 driver to prepare and unprepare
> clocks in addition to enabling and disabling, since it is required
> by common clock framework.
> 
> Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> ---
>  drivers/usb/host/ohci-s3c2410.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/host/ohci-s3c2410.c
> b/drivers/usb/host/ohci-s3c2410.c index e125770..db096bf 100644
> --- a/drivers/usb/host/ohci-s3c2410.c
> +++ b/drivers/usb/host/ohci-s3c2410.c
> @@ -47,10 +47,10 @@ static void s3c2410_start_hc(struct platform_device
> *dev, struct usb_hcd *hcd)
> 
>  	dev_dbg(&dev->dev, "s3c2410_start_hc:\n");
> 
> -	clk_enable(usb_clk);
> +	clk_prepare_enable(usb_clk);
>  	mdelay(2);			/* let the bus clock stabilise */
> 
> -	clk_enable(clk);
> +	clk_prepare_enable(clk);
> 
>  	if (info != NULL) {
>  		info->hcd	= hcd;
> @@ -75,8 +75,8 @@ static void s3c2410_stop_hc(struct platform_device
> *dev) (info->enable_oc)(info, 0);
>  	}
> 
> -	clk_disable(clk);
> -	clk_disable(usb_clk);
> +	clk_disable_unprepare(clk);
> +	clk_disable_unprepare(usb_clk);
>  }
> 
>  /* ohci_s3c2410_hub_status_data

Any chance to get your ack on this?

Best regards,
Tomasz



From broonie at kernel.org  Wed Jul 31 14:59:47 2013
From: broonie at kernel.org (Mark Brown)
Date: Wed, 31 Jul 2013 19:59:47 +0100
Subject: Defining schemas for Device Tree
In-Reply-To: <20130731165902.GA3329@localhost.localdomain>
References: <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <20130730205716.GZ9858@sirena.org.uk>
 <CAKON4Ox7-6Jf0ce64Wqr5E49KS+9E135mqc_iG-PWQ7r8bzWHA@mail.gmail.com>
 <20130730230331.GC9858@sirena.org.uk>
 <CAKON4OzFdZhX0Kzu_6KiimD=KxDr6EM13zUH3GGE=hHaYx=m=Q@mail.gmail.com>
 <20130731113401.GM9858@sirena.org.uk>
 <20130731165902.GA3329@localhost.localdomain>
Message-ID: <20130731185947.GB9858@sirena.org.uk>

On Wed, Jul 31, 2013 at 05:59:10PM +0100, Dave Martin wrote:

> There may often be a conflict between making _good_ bindings, and making
> bindings which are convenient for maintainers to edit in .dts syntax.

> I think good bindings (in the sense of good ABI) must take precedence:
> good bindings need to interoperate well over a long period of time, and
> should be robust against future evolution of hardware platforms OSes.  If
> they look nice in the .dts file, that's a bonus -- but I don't think it
> should be viewed as a requirement.

While I take your point that we need to have a sane ABI I think you're
understating the importance of the human factors here - the harder it is
to reliably understand and edit the device trees the more likely it is
that people will end up shipping mistakes which undermines the work on
defining stable ABIs.

> A pair of properties like dma-names/dmas may be a bit cumbersome, but
> it can be precise, unambiguous, and simple and easy to parse and check.
> The semantics can be extended in the future if necessary, by adding
> additional companion properties.  From my perspective, this can work as
> a template for good bindings.

I think this is fine for bindings but it's just not really legible for
humans once the lists start growing.  We need a human interaction format
which is suitable for humans to work with, it's not good when people
start finding that it's a set backwards in terms of their ability to
work with their systems.

> Someone trying to maintain a complex .dts can always make their own life
> easier with a bit of scripting.  After all, in a future of stable
> bindings, a DT really shouldn't be changing much once it is complete.
> I don't see a clear reason why these issues must be solved by dtc
> itself.

I don't think it's terribly important if they're solved in dtc itself so
long as it's part of the standard tooling that everyone has access to.
There's a reasonable number of new SoCs get made which tend to be the
things that suffer most.
-------------- 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/20130731/5edf5c3d/attachment.sig>

From magnus.damm at gmail.com  Wed Jul 31 15:01:10 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 04:01:10 +0900
Subject: [PATCH 00/13] ARM: shmobile: Rework ->init_time() /
 shmobile_timer_init()
Message-ID: <20130731190110.31796.96552.sendpatchset@w520>

ARM: shmobile: Rework ->init_time() / shmobile_timer_init()

[PATCH 01/13] ARM: shmobile: Use default ->init_time() on r8a73a4
[PATCH 02/13] ARM: shmobile: Use default ->init_time() on r8a7740
[PATCH 03/13] ARM: shmobile: Use default ->init_time() on r8a7778
[PATCH 04/13] ARM: shmobile: Use default ->init_time() on r8a7779
[PATCH 05/13] ARM: shmobile: Use default ->init_time() on Bockw
[PATCH 06/13] ARM: shmobile: Use default ->init_time() on Bockw DT ref
[PATCH 07/13] ARM: shmobile: Use default ->init_time() on Armadillo DT ref
[PATCH 08/13] ARM: shmobile: Use default ->init_time() on APE6EVM
[PATCH 09/13] ARM: shmobile: Use default ->init_time() on APE6EVM DT ref
[PATCH 10/13] ARM: shmobile: Use default ->init_time() on Marzen DT ref
[PATCH 11/13] ARM: shmobile: Use default ->init_time() on KZM9G DT ref
[PATCH 12/13] ARM: shmobile: Use clocksource_of_init() on r8a7790
[PATCH 13/13] ARM: shmobile: Remove unused shmobile_init_time()

Set ->init_time() to NULL to use the default ARM behaviour which
happens to be clocksource_of_init(). Also, replace the call to
shmobile_time_init() with clocksource_of_init(). Finally, remove
shmobile_init_time() that now is unused.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 Written against renesas.git renesas-devel-20130731 and
 [PATCH 00/07] ARM: shmobile: sh73a0, r8a7779 and emev2 SMP SCU rework
 [PATCH 00/02] ARM: shmobile: Per-CPU SMP boot / sleep code

 arch/arm/mach-shmobile/board-ape6evm-reference.c         |    1 -
 arch/arm/mach-shmobile/board-ape6evm.c                   |    1 -
 arch/arm/mach-shmobile/board-armadillo800eva-reference.c |    1 -
 arch/arm/mach-shmobile/board-bockw-reference.c           |    1 -
 arch/arm/mach-shmobile/board-bockw.c                     |    1 -
 arch/arm/mach-shmobile/board-kzm9g-reference.c           |    1 -
 arch/arm/mach-shmobile/board-marzen-reference.c          |    1 -
 arch/arm/mach-shmobile/include/mach/common.h             |    1 -
 arch/arm/mach-shmobile/setup-r8a73a4.c                   |    1 -
 arch/arm/mach-shmobile/setup-r8a7740.c                   |    1 -
 arch/arm/mach-shmobile/setup-r8a7778.c                   |    1 -
 arch/arm/mach-shmobile/setup-r8a7779.c                   |    1 -
 arch/arm/mach-shmobile/setup-r8a7790.c                   |    2 +-
 arch/arm/mach-shmobile/timer.c                           |    4 ----
 14 files changed, 1 insertion(+), 17 deletions(-)


From magnus.damm at gmail.com  Wed Jul 31 15:01:19 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 04:01:19 +0900
Subject: [PATCH 01/13] ARM: shmobile: Use default ->init_time() on r8a73a4
In-Reply-To: <20130731190110.31796.96552.sendpatchset@w520>
References: <20130731190110.31796.96552.sendpatchset@w520>
Message-ID: <20130731190119.31796.56612.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Leave ->init_time() set to NULL to use the default ARM behaviour.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-r8a73a4.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/setup-r8a73a4.c
+++ work/arch/arm/mach-shmobile/setup-r8a73a4.c	2013-08-01 02:58:37.000000000 +0900
@@ -223,7 +223,6 @@ static const char *r8a73a4_boards_compat
 
 DT_MACHINE_START(R8A73A4_DT, "Generic R8A73A4 (Flattened Device Tree)")
 	.init_early	= r8a73a4_init_delay,
-	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a73a4_boards_compat_dt,
 MACHINE_END
 #endif /* CONFIG_USE_OF */


From magnus.damm at gmail.com  Wed Jul 31 15:01:28 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 04:01:28 +0900
Subject: [PATCH 02/13] ARM: shmobile: Use default ->init_time() on r8a7740
In-Reply-To: <20130731190110.31796.96552.sendpatchset@w520>
References: <20130731190110.31796.96552.sendpatchset@w520>
Message-ID: <20130731190128.31796.59440.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Leave ->init_time() set to NULL to use the default ARM behaviour.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-r8a7740.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/setup-r8a7740.c
+++ work/arch/arm/mach-shmobile/setup-r8a7740.c	2013-08-01 03:00:48.000000000 +0900
@@ -1035,7 +1035,6 @@ DT_MACHINE_START(R8A7740_DT, "Generic R8
 	.init_early	= r8a7740_init_delay,
 	.init_irq	= r8a7740_init_irq_of,
 	.init_machine	= r8a7740_generic_init,
-	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a7740_boards_compat_dt,
 MACHINE_END
 


From magnus.damm at gmail.com  Wed Jul 31 15:01:37 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 04:01:37 +0900
Subject: [PATCH 03/13] ARM: shmobile: Use default ->init_time() on r8a7778
In-Reply-To: <20130731190110.31796.96552.sendpatchset@w520>
References: <20130731190110.31796.96552.sendpatchset@w520>
Message-ID: <20130731190137.31796.78683.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Leave ->init_time() set to NULL to use the default ARM behaviour.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-r8a7778.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/setup-r8a7778.c
+++ work/arch/arm/mach-shmobile/setup-r8a7778.c	2013-08-01 03:02:21.000000000 +0900
@@ -406,7 +406,6 @@ static const char *r8a7778_compat_dt[] _
 DT_MACHINE_START(R8A7778_DT, "Generic R8A7778 (Flattened Device Tree)")
 	.init_early	= r8a7778_init_delay,
 	.init_irq	= r8a7778_init_irq_dt,
-	.init_time	= shmobile_timer_init,
 	.dt_compat	= r8a7778_compat_dt,
 	.init_late      = r8a7778_init_late,
 MACHINE_END


From magnus.damm at gmail.com  Wed Jul 31 15:01:46 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 04:01:46 +0900
Subject: [PATCH 04/13] ARM: shmobile: Use default ->init_time() on r8a7779
In-Reply-To: <20130731190110.31796.96552.sendpatchset@w520>
References: <20130731190110.31796.96552.sendpatchset@w520>
Message-ID: <20130731190146.31796.53837.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Leave ->init_time() set to NULL to use the default ARM behaviour.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-r8a7779.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/setup-r8a7779.c
+++ work/arch/arm/mach-shmobile/setup-r8a7779.c	2013-08-01 03:03:30.000000000 +0900
@@ -667,7 +667,6 @@ DT_MACHINE_START(R8A7779_DT, "Generic R8
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= r8a7779_init_irq_dt,
 	.init_machine	= r8a7779_add_standard_devices_dt,
-	.init_time	= shmobile_timer_init,
 	.init_late	= r8a7779_init_late,
 	.dt_compat	= r8a7779_compat_dt,
 MACHINE_END


From magnus.damm at gmail.com  Wed Jul 31 15:01:55 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 04:01:55 +0900
Subject: [PATCH 05/13] ARM: shmobile: Use default ->init_time() on Bockw
In-Reply-To: <20130731190110.31796.96552.sendpatchset@w520>
References: <20130731190110.31796.96552.sendpatchset@w520>
Message-ID: <20130731190155.31796.59580.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Leave ->init_time() set to NULL to use the default ARM behaviour.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-bockw.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/board-bockw.c
+++ work/arch/arm/mach-shmobile/board-bockw.c	2013-08-01 03:06:01.000000000 +0900
@@ -279,7 +279,6 @@ DT_MACHINE_START(BOCKW_DT, "bockw")
 	.init_early	= r8a7778_init_delay,
 	.init_irq	= r8a7778_init_irq_dt,
 	.init_machine	= bockw_init,
-	.init_time	= shmobile_timer_init,
 	.dt_compat	= bockw_boards_compat_dt,
 	.init_late      = r8a7778_init_late,
 MACHINE_END


From magnus.damm at gmail.com  Wed Jul 31 15:02:14 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 04:02:14 +0900
Subject: [PATCH 07/13] ARM: shmobile: Use default ->init_time() on Armadillo
 DT ref
In-Reply-To: <20130731190110.31796.96552.sendpatchset@w520>
References: <20130731190110.31796.96552.sendpatchset@w520>
Message-ID: <20130731190214.31796.97852.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Leave ->init_time() set to NULL to use the default ARM behaviour.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-armadillo800eva-reference.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
+++ work/arch/arm/mach-shmobile/board-armadillo800eva-reference.c	2013-08-01 03:09:22.000000000 +0900
@@ -190,7 +190,6 @@ DT_MACHINE_START(ARMADILLO800EVA_DT, "ar
 	.init_early	= r8a7740_init_delay,
 	.init_irq	= r8a7740_init_irq_of,
 	.init_machine	= eva_init,
-	.init_time	= shmobile_timer_init,
 	.init_late	= shmobile_init_late,
 	.dt_compat	= eva_boards_compat_dt,
 	.restart	= eva_restart,


From magnus.damm at gmail.com  Wed Jul 31 15:02:05 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 04:02:05 +0900
Subject: [PATCH 06/13] ARM: shmobile: Use default ->init_time() on Bockw DT ref
In-Reply-To: <20130731190110.31796.96552.sendpatchset@w520>
References: <20130731190110.31796.96552.sendpatchset@w520>
Message-ID: <20130731190205.31796.84731.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Leave ->init_time() set to NULL to use the default ARM behaviour.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-bockw-reference.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/board-bockw-reference.c
+++ work/arch/arm/mach-shmobile/board-bockw-reference.c	2013-08-01 03:07:13.000000000 +0900
@@ -57,6 +57,5 @@ DT_MACHINE_START(BOCKW_DT, "bockw")
 	.init_early	= r8a7778_init_delay,
 	.init_irq	= r8a7778_init_irq_dt,
 	.init_machine	= bockw_init,
-	.init_time	= shmobile_timer_init,
 	.dt_compat	= bockw_boards_compat_dt,
 MACHINE_END


From magnus.damm at gmail.com  Wed Jul 31 15:02:24 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 04:02:24 +0900
Subject: [PATCH 08/13] ARM: shmobile: Use default ->init_time() on APE6EVM
In-Reply-To: <20130731190110.31796.96552.sendpatchset@w520>
References: <20130731190110.31796.96552.sendpatchset@w520>
Message-ID: <20130731190224.31796.18362.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Leave ->init_time() set to NULL to use the default ARM behaviour.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-ape6evm.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/board-ape6evm.c
+++ work/arch/arm/mach-shmobile/board-ape6evm.c	2013-08-01 03:11:13.000000000 +0900
@@ -181,7 +181,6 @@ static const char *ape6evm_boards_compat
 
 DT_MACHINE_START(APE6EVM_DT, "ape6evm")
 	.init_early	= r8a73a4_init_delay,
-	.init_time	= shmobile_timer_init,
 	.init_machine	= ape6evm_add_standard_devices,
 	.dt_compat	= ape6evm_boards_compat_dt,
 MACHINE_END


From magnus.damm at gmail.com  Wed Jul 31 15:02:33 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 04:02:33 +0900
Subject: [PATCH 09/13] ARM: shmobile: Use default ->init_time() on APE6EVM DT
 ref
In-Reply-To: <20130731190110.31796.96552.sendpatchset@w520>
References: <20130731190110.31796.96552.sendpatchset@w520>
Message-ID: <20130731190233.31796.29635.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Leave ->init_time() set to NULL to use the default ARM behaviour.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-ape6evm-reference.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/board-ape6evm-reference.c
+++ work/arch/arm/mach-shmobile/board-ape6evm-reference.c	2013-08-01 03:12:18.000000000 +0900
@@ -58,7 +58,6 @@ static const char *ape6evm_boards_compat
 
 DT_MACHINE_START(APE6EVM_DT, "ape6evm")
 	.init_early	= r8a73a4_init_delay,
-	.init_time	= shmobile_timer_init,
 	.init_machine	= ape6evm_add_standard_devices,
 	.dt_compat	= ape6evm_boards_compat_dt,
 MACHINE_END


From magnus.damm at gmail.com  Wed Jul 31 15:02:42 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 04:02:42 +0900
Subject: [PATCH 10/13] ARM: shmobile: Use default ->init_time() on Marzen DT
 ref
In-Reply-To: <20130731190110.31796.96552.sendpatchset@w520>
References: <20130731190110.31796.96552.sendpatchset@w520>
Message-ID: <20130731190242.31796.98376.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Leave ->init_time() set to NULL to use the default ARM behaviour.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-marzen-reference.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/board-marzen-reference.c
+++ work/arch/arm/mach-shmobile/board-marzen-reference.c	2013-08-01 03:13:42.000000000 +0900
@@ -42,6 +42,5 @@ DT_MACHINE_START(MARZEN, "marzen")
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= r8a7779_init_irq_dt,
 	.init_machine	= marzen_init,
-	.init_time	= shmobile_timer_init,
 	.dt_compat	= marzen_boards_compat_dt,
 MACHINE_END


From magnus.damm at gmail.com  Wed Jul 31 15:02:51 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 04:02:51 +0900
Subject: [PATCH 11/13] ARM: shmobile: Use default ->init_time() on KZM9G DT ref
In-Reply-To: <20130731190110.31796.96552.sendpatchset@w520>
References: <20130731190110.31796.96552.sendpatchset@w520>
Message-ID: <20130731190251.31796.67349.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Leave ->init_time() set to NULL to use the default ARM behaviour.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/board-kzm9g-reference.c |    1 -
 1 file changed, 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/board-kzm9g-reference.c
+++ work/arch/arm/mach-shmobile/board-kzm9g-reference.c	2013-08-01 03:16:17.000000000 +0900
@@ -52,6 +52,5 @@ DT_MACHINE_START(KZM9G_DT, "kzm9g-refere
 	.init_early	= sh73a0_init_delay,
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_machine	= kzm_init,
-	.init_time	= shmobile_timer_init,
 	.dt_compat	= kzm9g_boards_compat_dt,
 MACHINE_END


From magnus.damm at gmail.com  Wed Jul 31 15:03:00 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 04:03:00 +0900
Subject: [PATCH 12/13] ARM: shmobile: Use clocksource_of_init() on r8a7790
In-Reply-To: <20130731190110.31796.96552.sendpatchset@w520>
References: <20130731190110.31796.96552.sendpatchset@w520>
Message-ID: <20130731190300.31796.23926.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Replace the call to shmobile_timer_init() with
clocksource_of_init(). This will allow us to
get rid of shmobile_timer_init().

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/setup-r8a7790.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 0001/arch/arm/mach-shmobile/setup-r8a7790.c
+++ work/arch/arm/mach-shmobile/setup-r8a7790.c	2013-08-01 03:17:48.000000000 +0900
@@ -263,7 +263,7 @@ void __init r8a7790_timer_init(void)
 	iounmap(base);
 #endif /* CONFIG_ARM_ARCH_TIMER */
 
-	shmobile_timer_init();
+	clocksource_of_init();
 }
 
 void __init r8a7790_init_delay(void)


From magnus.damm at gmail.com  Wed Jul 31 15:03:09 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 01 Aug 2013 04:03:09 +0900
Subject: [PATCH 13/13] ARM: shmobile: Remove unused shmobile_init_time()
In-Reply-To: <20130731190110.31796.96552.sendpatchset@w520>
References: <20130731190110.31796.96552.sendpatchset@w520>
Message-ID: <20130731190309.31796.78310.sendpatchset@w520>

From: Magnus Damm <damm at opensource.se>

Remove shmobile_timer_init() since it now is unused.

Signed-off-by: Magnus Damm <damm at opensource.se>
---

 arch/arm/mach-shmobile/include/mach/common.h |    1 -
 arch/arm/mach-shmobile/timer.c               |    4 ----
 2 files changed, 5 deletions(-)

--- 0009/arch/arm/mach-shmobile/include/mach/common.h
+++ work/arch/arm/mach-shmobile/include/mach/common.h	2013-08-01 03:19:38.000000000 +0900
@@ -2,7 +2,6 @@
 #define __ARCH_MACH_COMMON_H
 
 extern void shmobile_earlytimer_init(void);
-extern void shmobile_timer_init(void);
 extern void shmobile_setup_delay(unsigned int max_cpu_core_mhz,
 			 unsigned int mult, unsigned int div);
 struct twd_local_timer;
--- 0001/arch/arm/mach-shmobile/timer.c
+++ work/arch/arm/mach-shmobile/timer.c	2013-08-01 03:19:19.000000000 +0900
@@ -59,7 +59,3 @@ void __init shmobile_earlytimer_init(voi
 	late_time_init = shmobile_late_time_init;
 }
 
-void __init shmobile_timer_init(void)
-{
-	clocksource_of_init();
-}


From tomasz.figa at gmail.com  Wed Jul 31 15:03:03 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 31 Jul 2013 21:03:03 +0200
Subject: [PATCH v4 00/20] Samsung PWM support cleanup
In-Reply-To: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
References: <1374278673-25615-1-git-send-email-tomasz.figa@gmail.com>
Message-ID: <6035387.7ekicDUVuU@flatron>

Hi Kukjin,

Since I think we already got all the necessary Acks, do you want me to 
send you a pull request or you already have this series applied (I can't 
see it in your tree on kernel.org)?

Best regards,
Tomasz

On Saturday 20 of July 2013 02:04:12 Tomasz Figa wrote:
> Since we now have a proper Samsung PWM clocksource driver in place,
> we can proceed with further cleanup of PWM timers support on Samsung
> SoCs.
> 
> This series attempts to achieve this goal by:
>  1) fixing up few things in samsung_pwm_timer clocksource driver,
>  2) moving remaining Samsung platforms to the new clocksource driver,
>  3) removing old clocksource driver,
>  4) adding new multiplatform- and DT-aware PWM driver,
>  5) moving all Samsung platforms to use the new PWM driver,
>  6) removing old PWM driver,
>  7) removing all PWM-related code that is not used anymore.
> 
> Cleaning up the PWM driver is a bit tricky, because the design of
> current driver makes it completely unsuitable for DT and multiplatform
> and would require a heavy rework to make it usable, breaking any
> existing Samsung PWM users by the way. To avoid any breakage this
> series first renames the old driver, then adds new one using original
> name, migrates all platforms to use it and then finally removes the old
> driver.
> 
> See particular patches for more detailed descriptions.
> 
> [On S3C6410-based Tiny6410 (Mini6410-compatible) with pwm-beeper,
> SMDK6410 with PWM backlight and Exynos4210-based Origen board (with
> PWM0 attached to a scope)]
> Tested-by: Tomasz Figa <tomasz.figa at gmail.com>
> 
> [On S3C2440-based Mini2440 board]
> Tested-by: Sylwester Nawrocki <sylvester.nawrocki at gmail.com>
> 
> [On a s3c2416 based machine]
> Tested-by: Heiko Stuebner <heiko at sntech.de>
> 
> [Also not sure on what boards, but still]
> Tested-by: Mark Brown <broonie at linaro.org>
> 
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Acked-by: Thierry Reding <thierry.reding at gmail.com>
> Acked-by: Heiko Stuebner <heiko at sntech.de>
> 
> Changes since v3:
>  - added two extra clocksource driver fixes to the series (patches 1,
> 2), - added comment explaining why only a simple synchronization is
> needed between clocksource and PWM drivers,
>  - some stylistic fixes,
>  - rebased to 3.11-rc1.
> Changes since v2:
>  - replaced __raw_{readl,writel} with {readl,writel},
>  - corrected some commit messages,
>  - used git format-patch -M to detect rename.
> Changes since v1:
>  - made sure that suspend/resume is handled correctly in both
>    clocksource and PWM drivers,
>  - fixed incorrect definition of AUTORELOAD bit for channel 4,
>  - fixed order of registering PWM device and calling samsung_bl_set(),
>    which assumes that PWM device has been already registered,
>  - corrected commit messages of several patches,
>  - addressed all the valid comments from reviewers, including cleanup
>    of most code originally copied from previous PWM driver,
>  - rebased on top of current Kgene's for-next,
>  - tested on Exynos4210, verifying correct PWM output with a scope.
> 
> Tomasz Figa (20):
>   clocksource: samsung_pwm_timer: Do not request PWM mem region
>   clocksource: samsung_pwm_timer: Correct definition of AUTORELOAD bit
>   clocksource: samsung_pwm_timer: Cache clocksource register address
>   clocksource: samsung_pwm_timer: Do not use clocksource_mmio
>   clocksource: samsung_pwm_timer: Handle suspend/resume correctly
>   ARM: SAMSUNG: Unify base address definitions of timer block
>   ARM: SAMSUNG: Add new PWM platform device
>   ARM: SAMSUNG: Set PWM platform data
>   ARM: SAMSUNG: Move all platforms to new clocksource driver
>   ARM: SAMSUNG: Remove old samsung-time driver
>   ARM: SAMSUNG: Remove unused PWM timer IRQ chip code
>   pwm: samsung: Rename to pwm-samsung-legacy
>   pwm: Add new pwm-samsung driver
>   ARM: SAMSUNG: Rework private data handling in dev-backlight
>   ARM: SAMSUNG: Modify board files to use new PWM platform device
>   pwm: Remove superseded pwm-samsung-legacy driver
>   ARM: SAMSUNG: Remove old PWM timer platform devices
>   ARM: SAMSUNG: Remove pwm-clock infrastructure
>   ARM: SAMSUNG: Remove remaining uses of plat/regs-timer.h header
>   ARM: SAMSUNG: Remove plat/regs-timer.h header
> 
>  arch/arm/Kconfig                                   |  11 +-
>  arch/arm/mach-s3c24xx/Kconfig                      |   6 -
>  arch/arm/mach-s3c24xx/clock-s3c2410.c              |   1 -
>  arch/arm/mach-s3c24xx/clock-s3c2412.c              |   1 -
>  arch/arm/mach-s3c24xx/clock-s3c2416.c              |   2 -
>  arch/arm/mach-s3c24xx/clock-s3c2443.c              |   2 -
>  arch/arm/mach-s3c24xx/common.c                     |  27 +
>  arch/arm/mach-s3c24xx/include/mach/map.h           |   2 +
>  arch/arm/mach-s3c24xx/mach-h1940.c                 |   4 +-
>  arch/arm/mach-s3c24xx/mach-rx1950.c                |   5 +-
>  arch/arm/mach-s3c64xx/Kconfig                      |   2 -
>  arch/arm/mach-s3c64xx/clock.c                      |   2 -
>  arch/arm/mach-s3c64xx/common.c                     |  32 +-
>  arch/arm/mach-s3c64xx/include/mach/irqs.h          |   8 -
>  arch/arm/mach-s3c64xx/include/mach/map.h           |   1 +
>  arch/arm/mach-s3c64xx/irq-pm.c                     |   2 -
>  arch/arm/mach-s3c64xx/mach-crag6410.c              |   4 +-
>  arch/arm/mach-s3c64xx/mach-hmt.c                   |   4 +-
>  arch/arm/mach-s3c64xx/mach-smartq.c                |   4 +-
>  arch/arm/mach-s3c64xx/mach-smdk6410.c              |   5 +-
>  arch/arm/mach-s5p64x0/Kconfig                      |   2 -
>  arch/arm/mach-s5p64x0/clock-s5p6440.c              |   2 -
>  arch/arm/mach-s5p64x0/clock-s5p6450.c              |   2 -
>  arch/arm/mach-s5p64x0/common.c                     |  27 +
>  arch/arm/mach-s5p64x0/include/mach/irqs.h          |   2 -
>  arch/arm/mach-s5p64x0/include/mach/map.h           |   1 +
>  arch/arm/mach-s5p64x0/mach-smdk6440.c              |   5 +-
>  arch/arm/mach-s5p64x0/mach-smdk6450.c              |   5 +-
>  arch/arm/mach-s5p64x0/pm.c                         |   3 -
>  arch/arm/mach-s5pc100/Kconfig                      |   1 -
>  arch/arm/mach-s5pc100/clock.c                      |   2 -
>  arch/arm/mach-s5pc100/common.c                     |  28 +
>  arch/arm/mach-s5pc100/include/mach/irqs.h          |   2 -
>  arch/arm/mach-s5pc100/include/mach/map.h           |   1 +
>  arch/arm/mach-s5pc100/mach-smdkc100.c              |   5 +-
>  arch/arm/mach-s5pv210/Kconfig                      |   1 -
>  arch/arm/mach-s5pv210/clock.c                      |   1 -
>  arch/arm/mach-s5pv210/common.c                     |  28 +
>  arch/arm/mach-s5pv210/include/mach/irqs.h          |   2 -
>  arch/arm/mach-s5pv210/include/mach/map.h           |   1 +
>  arch/arm/mach-s5pv210/mach-smdkv210.c              |   5 +-
>  arch/arm/mach-s5pv210/pm.c                         |  10 -
>  arch/arm/plat-samsung/Kconfig                      |  14 -
>  arch/arm/plat-samsung/Makefile                     |   3 -
>  arch/arm/plat-samsung/dev-backlight.c              |  61 +-
>  arch/arm/plat-samsung/devs.c                       |  42 +-
>  arch/arm/plat-samsung/include/plat/clock.h         |   4 -
>  arch/arm/plat-samsung/include/plat/devs.h          |   1 +
>  arch/arm/plat-samsung/include/plat/irq-vic-timer.h |  13 -
>  arch/arm/plat-samsung/include/plat/irqs.h          |   9 -
>  arch/arm/plat-samsung/include/plat/pwm-clock.h     |  81 ---
>  arch/arm/plat-samsung/include/plat/pwm-core.h      |  24 +
>  arch/arm/plat-samsung/include/plat/regs-timer.h    | 124 ----
>  arch/arm/plat-samsung/include/plat/samsung-time.h  |  23 -
>  arch/arm/plat-samsung/irq-vic-timer.c              |  98 ---
>  arch/arm/plat-samsung/pwm-clock.c                  | 474 --------------
> arch/arm/plat-samsung/s5p-irq.c                    |   4 -
>  arch/arm/plat-samsung/samsung-time.c               | 394 ------------
>  drivers/clocksource/Kconfig                        |   1 -
>  drivers/clocksource/samsung_pwm_timer.c            |  98 +--
>  drivers/pwm/pwm-samsung.c                          | 701
> ++++++++++++++------- 61 files changed, 768 insertions(+), 1662
> deletions(-)
>  delete mode 100644 arch/arm/plat-samsung/include/plat/irq-vic-timer.h
>  delete mode 100644 arch/arm/plat-samsung/include/plat/pwm-clock.h
>  create mode 100644 arch/arm/plat-samsung/include/plat/pwm-core.h
>  delete mode 100644 arch/arm/plat-samsung/include/plat/regs-timer.h
>  delete mode 100644 arch/arm/plat-samsung/irq-vic-timer.c
>  delete mode 100644 arch/arm/plat-samsung/pwm-clock.c
>  delete mode 100644 arch/arm/plat-samsung/samsung-time.c


From stefano.stabellini at eu.citrix.com  Wed Jul 31 15:03:46 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 20:03:46 +0100
Subject: [PATCH RFC 7/8] swiotlb-xen: support autotranslate guests
In-Reply-To: <1375292732-7627-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
 <1375292732-7627-7-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <alpine.DEB.2.02.1307312001450.4893@kaball.uk.xensource.com>

On Wed, 31 Jul 2013, Stefano Stabellini wrote:
> Support autotranslate guests in swiotlb-xen by keeping track of the
> phys-to-bus and bus-to-phys mappings of the swiotlb buffer
> (xen_io_tlb_start-xen_io_tlb_end).
> 
> Use a simple direct access on a pre-allocated array for phys-to-bus
> queries. Use a red-black tree for bus-to-phys queries.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> CC: david.vrabel at citrix.com
> ---
>  drivers/xen/swiotlb-xen.c |  127 +++++++++++++++++++++++++++++++++++++++------
>  1 files changed, 111 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 353f013..c79ac88 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -38,32 +38,116 @@
>  #include <linux/bootmem.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/export.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock_types.h>
> +#include <linux/rbtree.h>
>  #include <xen/swiotlb-xen.h>
>  #include <xen/page.h>
>  #include <xen/xen-ops.h>
>  #include <xen/hvc-console.h>
> +#include <xen/features.h>
>  /*
>   * Used to do a quick range check in swiotlb_tbl_unmap_single and
>   * swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by this
>   * API.
>   */
>  
> +#define NR_DMA_SEGS  ((xen_io_tlb_nslabs + IO_TLB_SEGSIZE - 1) / IO_TLB_SEGSIZE)
>  static char *xen_io_tlb_start, *xen_io_tlb_end;
>  static unsigned long xen_io_tlb_nslabs;
>  /*
>   * Quick lookup value of the bus address of the IOTLB.
>   */
>  
> -static u64 start_dma_addr;
> +struct xen_dma{
> +	dma_addr_t dma_addr;
> +	phys_addr_t phys_addr;
> +	size_t size;
> +	struct rb_node rbnode;
> +};
> +
> +static struct xen_dma *xen_dma_seg;
> +static struct rb_root bus_to_phys = RB_ROOT;
> +static DEFINE_SPINLOCK(xen_dma_lock);
> +
> +static void xen_dma_insert(struct xen_dma *entry)
> +{
> +	struct rb_node **link = &bus_to_phys.rb_node;
> +	struct rb_node *parent = NULL;
> +	struct xen_dma *e;
> +
> +	spin_lock(&xen_dma_lock);
> +
> +	while (*link) {
> +		parent = *link;
> +		e = rb_entry(parent, struct xen_dma, rbnode);
> +
> +		WARN_ON(entry->dma_addr == e->dma_addr);
> +
> +		if (entry->dma_addr < e->dma_addr)
> +			link = &(*link)->rb_left;
> +		else
> +			link = &(*link)->rb_right;
> +	}
> +	rb_link_node(&entry->rbnode, parent, link);
> +	rb_insert_color(&entry->rbnode, &bus_to_phys);
> +
> +	spin_unlock(&xen_dma_lock);
> +}
> +
> +static struct xen_dma *xen_dma_retrieve(dma_addr_t dma_addr)
> +{
> +	struct rb_node *n = bus_to_phys.rb_node;
> +	struct xen_dma *e;
> +	
> +	spin_lock(&xen_dma_lock);
> +
> +	while (n) {
> +		e = rb_entry(n, struct xen_dma, rbnode);
> +		if (e->dma_addr <= dma_addr && e->dma_addr + e->size > dma_addr) {
> +			spin_unlock(&xen_dma_lock);
> +			return e;
> +		}
> +		if (dma_addr < e->dma_addr)
> +			n = n->rb_left;
> +		else
> +			n = n->rb_right;
> +	}
> +
> +	spin_unlock(&xen_dma_lock);
> +	return NULL;
> +}
>  
>  static dma_addr_t xen_phys_to_bus(phys_addr_t paddr)
>  {
> -	return phys_to_machine(XPADDR(paddr)).maddr;
> +	int nr_seg;
> +	unsigned long offset;
> +	char* vaddr;
> +
> +	if (!xen_feature(XENFEAT_auto_translated_physmap))
> +		return phys_to_machine(XPADDR(paddr)).maddr;
> +
> +	vaddr = (char *) phys_to_virt(paddr);
> +	if (vaddr >= xen_io_tlb_end || vaddr < xen_io_tlb_start)
> +		return ~0;
> +
> +	offset = vaddr - xen_io_tlb_start;
> +	nr_seg = offset / (IO_TLB_SEGSIZE << IO_TLB_SHIFT);
> +
> +	return xen_dma_seg[nr_seg].dma_addr + (paddr & ((IO_TLB_SEGSIZE << IO_TLB_SHIFT) - 1));

I have just realized that there is a much better way of doing this:

return xen_dma_seg[nr_seg].dma_addr + (paddr - xen_dma_seg[nr_seg].phys_addr);


>  }
>  
>  static phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
>  {
> -	return machine_to_phys(XMADDR(baddr)).paddr;
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +	{
> +		struct xen_dma *dma = xen_dma_retrieve(baddr);
> +		if (dma == NULL)
> +			return ~0;
> +		else
> +			return dma->phys_addr + (baddr & ((IO_TLB_SEGSIZE << IO_TLB_SHIFT) - 1));

same here:

return dma->phys_addr + (baddr - dma->dma_addr);


From swarren at wwwdotorg.org  Wed Jul 31 15:09:55 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 Jul 2013 13:09:55 -0600
Subject: New dapm panic on beaver with next-20130730
In-Reply-To: <20130731103610.GH9858@sirena.org.uk>
References: <CAOesGMig6jry1GJLoTnOqxom1KjtBTUtZz-_-SiZLpGTc3VkqA@mail.gmail.com>
 <51F8A933.4080708@metafoo.de>
 <CAOesGMjqyF7zPoGsW6oBRFey7Bc_umnoGob7oQ=_c3n7oevuaQ@mail.gmail.com>
 <51F8B045.8030303@metafoo.de> <20130731103610.GH9858@sirena.org.uk>
Message-ID: <51F96103.6000603@wwwdotorg.org>

On 07/31/2013 04:36 AM, Mark Brown wrote:
> On Wed, Jul 31, 2013 at 08:35:49AM +0200, Lars-Peter Clausen
> wrote:
> 
>> 0x6b6b6b6b is poisoned freed memory. According to the source
>> neither the INR Mux nor the INL Mux widget should have any sinks.
>> Can you add a couple more printks:
> 
> Dan Carpenter sent a patch which is probably the issue - I'm trying
> to figure out how to boot my Beaver board so hopefully I can test,
> it'll be in -next tomorrow anyway.

I assume that is "[patch] ASoC: dapm: using freed pointer in
dapm_kcontrol_add_widget()". That doesn't fix the issue. Do you need
me to debug any further?



From richardcochran at gmail.com  Wed Jul 31 15:12:09 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Wed, 31 Jul 2013 21:12:09 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <1999586.84BnWE5EUh@thinkpad>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1479410.BSGDrOcRvP@thinkpad> <20130731150717.GD4904@netboy>
 <1999586.84BnWE5EUh@thinkpad>
Message-ID: <20130731191209.GA8027@netboy>

On Wed, Jul 31, 2013 at 05:23:35PM +0200, Tomasz Figa wrote:
> 
> I said it many, many times, that a) and b) I proposed are just two extremes. 
> It is unlikely that an extreme solution will be the best option to choose. I 
> am strongly for something in the middle, just like I wrote in several of my 
> previous replies.
> 
> This is something that should be commented, not those extreme options.

We are saying that pursuing a) is useless because it adds pain and
complexity without adding benefit. I simply don't buy your argument
that DT makes a better platform data, but that is besides the point.

I had said, think about the users.  You said, what users?  I wrote a
clear and concise use case.  You said, lets think about a) and b) and
all the shades of gray in between.

In order to support the use case, you will have to provide a stable
ABI. You can't have a compromise solution. At the end of the day,
either you have a stable ABI, or you don't.

It was apparent to me that the arm/dt thing has been meandering around
since its inception, but what was surprising is that people were doing
this on purpose, and now they are defending this. Why can't we get a
firm commitment on having a stable ABI?

Thanks,
Richard




From magnus.damm at gmail.com  Wed Jul 31 15:17:39 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 1 Aug 2013 04:17:39 +0900
Subject: [PATCH] clocksource: em_sti: Adjust clock event rating to fix SMP
 broadcast
In-Reply-To: <51F94A35.2020907@codeaurora.org>
References: <1375251940-7809-1-git-send-email-horms+renesas@verge.net.au>
 <51F94A35.2020907@codeaurora.org>
Message-ID: <CANqRtoR0Wwctor1mpM+8nuC0_pZsPHUSShPuZFX4FVtoVKEuNw@mail.gmail.com>

Hi Stephen,

On Thu, Aug 1, 2013 at 2:32 AM, Stephen Boyd <sboyd at codeaurora.org> wrote:
> On 07/30/13 23:25, Simon Horman wrote:
>> From: Magnus Damm <damm at opensource.se>
>>
>> Update the STI rating from 200 to 80 to fix SMP operation with
>> the ARM broadcast timer. This breakage was introduced by:
>>
>> f7db706 ARM: 7674/1: smp: Avoid dummy clockevent being preferred over real hardware clock-event
>>
>> Without this fix SMP operation is broken on EMEV2 since no
>> broadcast timer interrupts trigger on the secondary CPU cores.
>>
>> Signed-off-by: Magnus Damm <damm at opensource.se>
>> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
>> ---
>
> This looks suspicious. Are you're purposefully deflating the rating so
> that the STI timer fills in the broadcast position? Why not make the STI
> cpumask be all possible CPUs? Presumably the interrupt can target all
> CPUs since it isn't a per-cpu interrupt and doing this would cause the
> STI to fill in the broadcast slot, leaving the per-cpu dummys in the
> tick position.

While letting the timer broadcast to all CPUs sounds interesting the
STI driver has so far only been used to drive a single CPU core. This
used to work well for us but has since some time unfortunately been
broken. I agree that it may be suboptimal with a single timer like STI
and using IPI for broadcast, but for more efficient SMP we already
have TWD or arch timer.

This particular patch just does what should have been done during
development of the following commit:

f7db706 ARM: 7674/1: smp: Avoid dummy clockevent being preferred over
real hardware clock-event

Basically, the f7db706 commit changes the dummy clockevent rating from
400 to 100. Our timers in drivers/clocksource all had a rating higher
than 100 so the commit basically broke everything. I can understand
that the CMT, TMU and MTU2 timers were overlooked due to clock event
rating in platform data, but a simple grep would have saved this
driver..

Anyway, this patch adjusts the STI rating from 200 down to 80 so we
now once again are below the dummy clock event rating. So now SMP is
working again, yay!

Thanks for your comments!

/ magnus


From tomasz.figa at gmail.com  Wed Jul 31 15:29:35 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Wed, 31 Jul 2013 21:29:35 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130731191209.GA8027@netboy>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1999586.84BnWE5EUh@thinkpad> <20130731191209.GA8027@netboy>
Message-ID: <1409617.9untvfnOTJ@flatron>

On Wednesday 31 of July 2013 21:12:09 Richard Cochran wrote:
> On Wed, Jul 31, 2013 at 05:23:35PM +0200, Tomasz Figa wrote:
> > I said it many, many times, that a) and b) I proposed are just two
> > extremes. It is unlikely that an extreme solution will be the best
> > option to choose. I am strongly for something in the middle, just
> > like I wrote in several of my previous replies.
> > 
> > This is something that should be commented, not those extreme options.
> 
> We are saying that pursuing a) is useless because it adds pain and
> complexity without adding benefit. I simply don't buy your argument
> that DT makes a better platform data, but that is besides the point.
> 
> I had said, think about the users.  You said, what users?  I wrote a
> clear and concise use case.  You said, lets think about a) and b) and
> all the shades of gray in between.

I showed you two example solutions that could handle this use case without 
stable binding ABI, just to prove that b) is not the only option (even if 
it's the best one, which I continue to agree on, don't get me wrong).

I also added that the use case is not fully valid, because you can't 
magically define bindings for all future hardware, which means you can't 
support the hardware using a DTB made before stable bindings for that 
hardware have ever been introduced.

With all of this, I agreed that a DTB made for kernel 3.x, when used with 
kernel 3.y (y > x) should provide the same or greater feature set than 
used with kernel 3.x, in other words, this should cause no regressions. 
Still, for new features, you will likely need to update the DTB.

> In order to support the use case, you will have to provide a stable
> ABI. You can't have a compromise solution. At the end of the day,
> either you have a stable ABI, or you don't.
> 
> It was apparent to me that the arm/dt thing has been meandering around
> since its inception, but what was surprising is that people were doing
> this on purpose, and now they are defending this. Why can't we get a
> firm commitment on having a stable ABI?

This is exactly what are we trying to do right now. But you don't get 
stable things right away. You need some kind of process, for design, 
review, staging, stabilization, etc. Without all of this we will again 
surely end up with something pretending to be good and stable, while being 
completely useless and only a burden to support in new code.

So, again, to summarize, my view on this is as follows:
 - there is a list of best practices for binding design and existing 
   stable bindings that can be used to help for designing new bindings,
 - new bindings go through review process,
 - after positive review, such bindings gets staging status, i.e. they are 
   marked as something that could change,
 - after some period of time (we need to define this precisely) they get 
   frozen and can't be changed in a way that breaks compatibility any
   more. In other words, they become ABI.

What do you think?

Best regards,
Tomasz



From magnus.damm at gmail.com  Wed Jul 31 15:34:03 2013
From: magnus.damm at gmail.com (Magnus Damm)
Date: Thu, 1 Aug 2013 04:34:03 +0900
Subject: [PATCH] ARM: Fix memblock_reserve() to include stext
In-Reply-To: <20130731094352.GV24642@n2100.arm.linux.org.uk>
References: <20130731055807.14054.70106.sendpatchset@w520>
 <20130731094352.GV24642@n2100.arm.linux.org.uk>
Message-ID: <CANqRtoR5j2VyRwf0suABfVLxzU30pZndEcCj7uZ2sSrzfGmx_A@mail.gmail.com>

On Wed, Jul 31, 2013 at 6:43 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Wed, Jul 31, 2013 at 02:58:07PM +0900, Magnus Damm wrote:
>> From: Magnus Damm <damm at opensource.se>
>>
>> This fix for the ARM architecture will include stext
>> in the memblock_reserve() call to make sure that the
>> following symbols are not overwritten (from System.map):
>>
>> c0008000 T _text
>> c0008000 T stext
>> ...
>> c0008138 T secondary_startup
>> ...
>> c0009000 T _stext
>>
>> With this patch applied CPU Hotplug starts working
>> again. Without this patch code in secondary_startup
>> never gets reached as expected.
>>
>> This issue started triggering on kernels later than
>> v3.10 - perhaps a side effect of the CPU Hotplug init
>> section rework - so this is a fix for v3.11-rc.
>
> This is not the right fix.  The commit you previously pointed out (removal
> of CPU hotplug) probably means there's a missing annotation somewhere in
> the code.
>
> And yes - the __CPUINIT just before ENTRY(secondary_startup) was removed
> rather than being replaced with a .text (in both head.S and head-nommu.S).
> Same goes for ENTRY(lookup_processor_type) in head-common.S.  All these
> need to be replaced with .text to stop them falling into the head section.

Thanks for your guidance, Russell. The right way to fix this now seems
pretty clear to me.

Are you aware of any existing fix for this or anyone working on
solving this issue? If not then I don't mind stepping up. I can
however think of quite a few other things to do if this has been
solved already though, so please let me know if you think I should
focus on fixing this.

Cheers,

/ magnus


From ben.dooks at codethink.co.uk  Wed Jul 31 15:38:54 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 31 Jul 2013 20:38:54 +0100
Subject: [PATCH 3/4] ARM: kprobes-test: use <asm/opcodes.h>
In-Reply-To: <1375085237.3521.7.camel@linaro1.home>
References: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374786537-10726-4-git-send-email-ben.dooks@codethink.co.uk>
 <1375085237.3521.7.camel@linaro1.home>
Message-ID: <51F967CE.4030704@codethink.co.uk>

On 29/07/13 09:07, Jon Medhurst (Tixy) wrote:
> On Thu, 2013-07-25 at 22:08 +0100, Ben Dooks wrote:
>> Ensure we read instructions in the correct endian-ness by using
>> the<asm/opcodes.h>  helper to transform them as necessary.
>>
>> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>
>> ---
>>   arch/arm/kernel/kprobes-test.c |    9 ++++-----
>>   1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/kernel/kprobes-test.c b/arch/arm/kernel/kprobes-test.c
>> index 0cd63d0..6cfa04d 100644
>> --- a/arch/arm/kernel/kprobes-test.c
>> +++ b/arch/arm/kernel/kprobes-test.c
>> @@ -1374,13 +1374,13 @@ static uintptr_t __used kprobes_test_case_start(const char *title, void *stack)
>>
>>   	if (test_case_is_thumb) {
>>   		u16 *p = (u16 *)(test_code&  ~1);
>> -		current_instruction = p[0];
>> +		current_instruction = __mem_to_opcode_thumb16(p[0]);
>>   		if (is_wide_instruction(current_instruction)) {
>> -			current_instruction<<= 16;
>> -			current_instruction |= p[1];
>> +			u16 instr2 = __mem_to_opcode_thumb16(p[1]);
>> +			current_instruction = ___asm_opcode_thumb32_compose(current_instruction, instr2);
>
> Should it not be __opcode_thumb32_compose instead of
> ___asm_opcode_thumb32_compose ?

Ok, will change for the next version.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From linux at arm.linux.org.uk  Wed Jul 31 15:39:30 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 31 Jul 2013 20:39:30 +0100
Subject: [PATCH] ARM: Fix memblock_reserve() to include stext
In-Reply-To: <CANqRtoR5j2VyRwf0suABfVLxzU30pZndEcCj7uZ2sSrzfGmx_A@mail.gmail.com>
References: <20130731055807.14054.70106.sendpatchset@w520>
 <20130731094352.GV24642@n2100.arm.linux.org.uk>
 <CANqRtoR5j2VyRwf0suABfVLxzU30pZndEcCj7uZ2sSrzfGmx_A@mail.gmail.com>
Message-ID: <20130731193930.GY24642@n2100.arm.linux.org.uk>

On Thu, Aug 01, 2013 at 04:34:03AM +0900, Magnus Damm wrote:
> Are you aware of any existing fix for this or anyone working on
> solving this issue? If not then I don't mind stepping up. I can
> however think of quite a few other things to do if this has been
> solved already though, so please let me know if you think I should
> focus on fixing this.

I committed a fix for it this morning, so it should be in linux-next by
tomorrow.



From ben.dooks at codethink.co.uk  Wed Jul 31 15:43:07 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 31 Jul 2013 20:43:07 +0100
Subject: [PATCH 1/4] ARM: kprobes: fix instruction fetch order with
 <asm/opcodes.h>
In-Reply-To: <1375084901.3521.3.camel@linaro1.home>
References: <1374786537-10726-1-git-send-email-ben.dooks@codethink.co.uk>
 <1374786537-10726-2-git-send-email-ben.dooks@codethink.co.uk>
 <1375084901.3521.3.camel@linaro1.home>
Message-ID: <51F968CB.8060605@codethink.co.uk>

On 29/07/13 09:01, Jon Medhurst (Tixy) wrote:
> On Thu, 2013-07-25 at 22:08 +0100, Ben Dooks wrote:
>> If we are running BE8, the data and instruction endian-ness do not
>> match, so use<asm/opcodes.h>  to correctly translate memory accesses
>> into ARM instructions.
>>
>> Signed-off-by: Ben Dooks<ben.dooks at codethink.co.uk>y
>> ---
>>   arch/arm/kernel/kprobes-common.c |   14 ++++++++------
>>   arch/arm/kernel/kprobes.c        |    9 +++++----
>>   2 files changed, 13 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm/kernel/kprobes-common.c b/arch/arm/kernel/kprobes-common.c
>> index 18a7628..c0b202e 100644
>> --- a/arch/arm/kernel/kprobes-common.c
>> +++ b/arch/arm/kernel/kprobes-common.c
>> @@ -14,6 +14,7 @@
>>   #include<linux/kernel.h>
>>   #include<linux/kprobes.h>
>>   #include<asm/system_info.h>
>> +#include<asm/opcodes.h>
>>
>>   #include "kprobes.h"
>>
>> @@ -305,7 +306,8 @@ kprobe_decode_ldmstm(kprobe_opcode_t insn, struct arch_specific_insn *asi)
>>
>>   	if (handler) {
>>   		/* We can emulate the instruction in (possibly) modified form */
>> -		asi->insn[0] = (insn&  0xfff00000) | (rn<<  16) | reglist;
>> +		asi->insn[0] = __opcode_to_mem_arm((insn&  0xfff00000) |
>> +						   (rn<<  16) | reglist);
>>   		asi->insn_handler = handler;
>>   		return INSN_GOOD;
>>   	}
>> @@ -338,9 +340,9 @@ prepare_emulated_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi,
>>   		thumb_insn[2] = 0x4770; /* Thumb bx lr */
>
> The line above and the one before it not in this diff also need fixing
> by changing to __opcode_to_mem_thumb16(0x4770).

IIRC, these are then fixed by the set_emulated instruction, which is
also why the insn return is not swapped.

>>   		return insn;
>>   	}
>> -	asi->insn[1] = 0xe12fff1e; /* ARM bx lr */
>> +	asi->insn[1] = __opcode_to_mem_arm(0xe12fff1e); /* ARM bx lr */
>>   #else
>> -	asi->insn[1] = 0xe1a0f00e; /* mov pc, lr */
>> +	asi->insn[1] = __opcode_to_mem_arm(0xe1a0f00e); /* mov pc, lr */
>>   #endif
>>   	/* Make an ARM instruction unconditional */
>>   	if (insn<  0xe0000000)
>> @@ -360,12 +362,12 @@ set_emulated_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi,
>>   	if (thumb) {
>>   		u16 *ip = (u16 *)asi->insn;
>>   		if (is_wide_instruction(insn))
>> -			*ip++ = insn>>  16;
>> -		*ip++ = insn;
>> +			*ip++ = ___asm_opcode_to_mem_thumb16(insn>>  16);
>> +		*ip++ = ___asm_opcode_to_mem_thumb16(insn);
>
>
> Should these two ___asm_opcode_thumb32_compose() not be
> __opcode_thumb32_compose() ?

I decided to leave this as is.

>>   		return;
>>   	}
>>   #endif
>> -	asi->insn[0] = insn;
>> +	asi->insn[0] = __opcode_to_mem_arm(insn);
>>   }
>>
>>   /*
>> diff --git a/arch/arm/kernel/kprobes.c b/arch/arm/kernel/kprobes.c
>> index 170e9f3..3775af1 100644
>> --- a/arch/arm/kernel/kprobes.c
>> +++ b/arch/arm/kernel/kprobes.c
>> @@ -26,6 +26,7 @@
>>   #include<linux/stop_machine.h>
>>   #include<linux/stringify.h>
>>   #include<asm/traps.h>
>> +#include<asm/opcodes.h>
>>   #include<asm/cacheflush.h>
>>
>>   #include "kprobes.h"
>> @@ -62,10 +63,10 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
>>   #ifdef CONFIG_THUMB2_KERNEL
>>   	thumb = true;
>>   	addr&= ~1; /* Bit 0 would normally be set to indicate Thumb code */
>> -	insn = ((u16 *)addr)[0];
>> +	insn = __mem_to_opcode_thumb16(((u16 *)addr)[0]);
>>   	if (is_wide_instruction(insn)) {
>> -		insn<<= 16;
>> -		insn |= ((u16 *)addr)[1];
>> +		u16 inst2 = __mem_to_opcode_thumb16(((u16 *)addr)[1]);
>> +		insn = ___asm_opcode_thumb32_compose(insn, inst2);
>
> Again, __opcode_thumb32_compose instead of
> ___asm_opcode_thumb32_compose
>
>>   		decode_insn = thumb32_kprobe_decode_insn;
>>   	} else
>>   		decode_insn = thumb16_kprobe_decode_insn;
>> @@ -73,7 +74,7 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
>>   	thumb = false;
>>   	if (addr&  0x3)
>>   		return -EINVAL;
>> -	insn = *p->addr;
>> +	insn = __mem_to_opcode_arm(*p->addr);
>>   	decode_insn = arm_kprobe_decode_insn;
>>   #endif
>>
>


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From stefano.stabellini at eu.citrix.com  Wed Jul 31 15:44:01 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 20:44:01 +0100
Subject: [PATCH RFC 0/8] enable swiotlb-xen on arm and arm64
In-Reply-To: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1307312041510.4893@kaball.uk.xensource.com>

Although the series should be enough to demonstrate the concept, it
contains a couple of errors. I'll send an update.

On Wed, 31 Jul 2013, Stefano Stabellini wrote:
> Hi all,
> this patch series enables xen-swiotlb on arm and arm64.
> 
> Considering that all guests, including dom0, run on xen on arm with
> second stage translation enabled, it follows that without an IOMMU no
> guests could actually drive the hardware.
> 
> The solution for platforms without an IOMMU is to use swiotlb-xen,
> adapted to autotranslate guests. swiotlb-xen provides a set of dma_ops
> that can be used by Linux to setup a contiguous buffer in stage-2
> addresses and use it for dma operations.
> Basically Linux asks Xen to make a buffer contiguous and gets the
> machine address for it. This buffer is going to be used by lib/swiotlb.c
> to allocate bounce buffers.
> 
> 
> The first 3 patches lay the groundwork on arm and arm64 to have
> alternative dma_ops and swiotlb.
> 
> The forth patch moves Xen initialization earlier so that we already know
> whether we are running on Xen at the time of initializing dma_ops on the
> platform.
> 
> The following patches adapt swiotlb-xen to autotranslate guests (guest
> with second stage translation in hardware) and provide an arm
> implementation of xen_create_contiguous_region.
> 
> 
> Feedback is very welcome.
> Cheers,
> 
> Stefano
> 
> 
> Stefano Stabellini (8):
>       arm: make SWIOTLB available
>       arm: introduce a global dma_ops pointer
>       arm64: do not initialize arm64_swiotlb if dma_ops is already set
>       xen/arm,arm64: move Xen initialization earlier
>       xen: introduce XENMEM_get_dma_buf and xen_put_dma_buf
>       xen: make xen_create_contiguous_region return the dma address
>       swiotlb-xen: support autotranslate guests
>       xen/arm,arm64: enable SWIOTLB_XEN
> 
>  arch/arm/Kconfig                      |    8 ++
>  arch/arm/common/dmabounce.c           |   10 +-
>  arch/arm/include/asm/dma-mapping.h    |   27 ++++++-
>  arch/arm/include/asm/xen/hypervisor.h |    6 ++
>  arch/arm/include/asm/xen/page.h       |    2 +
>  arch/arm/kernel/setup.c               |    2 +
>  arch/arm/mm/dma-mapping.c             |    3 +
>  arch/arm/xen/Makefile                 |    2 +-
>  arch/arm/xen/enlighten.c              |   24 ++++--
>  arch/arm/xen/mm.c                     |  118 ++++++++++++++++++++++++++
>  arch/arm64/Kconfig                    |    1 +
>  arch/arm64/kernel/setup.c             |    2 +
>  arch/arm64/mm/dma-mapping.c           |    2 +
>  arch/arm64/xen/Makefile               |    2 +-
>  arch/x86/xen/mmu.c                    |    4 +-
>  drivers/xen/Kconfig                   |    1 -
>  drivers/xen/swiotlb-xen.c             |  147 +++++++++++++++++++++++++++++----
>  include/xen/interface/memory.h        |   62 ++++++++++++++
>  include/xen/xen-ops.h                 |    3 +-
>  19 files changed, 391 insertions(+), 35 deletions(-)
>  create mode 100644 arch/arm/xen/mm.c
> 


From swarren at wwwdotorg.org  Wed Jul 31 15:46:18 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 Jul 2013 13:46:18 -0600
Subject: [PATCH 1/10] ARM: dts: mxs: move 'compatible' property to
 beginning of node and do some whitespace cleanups
In-Reply-To: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
References: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <51F9698A.7080100@wwwdotorg.org>

On 07/31/2013 08:37 AM, Lothar Wa?mann wrote:

These really need patch descriptions.

I'm not sure if doing multiple things at once in a patch is a good idea,
although admittedly otherwise it'd mean a lot of trivial patches.


From swarren at wwwdotorg.org  Wed Jul 31 15:46:41 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 Jul 2013 13:46:41 -0600
Subject: [PATCH 2/10] ARM: dts: mxs: add labels to most nodes for easier
 reference
In-Reply-To: <1375281480-25775-2-git-send-email-LW@KARO-electronics.de>
References: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
 <1375281480-25775-2-git-send-email-LW@KARO-electronics.de>
Message-ID: <51F969A1.8070509@wwwdotorg.org>

On 07/31/2013 08:37 AM, Lothar Wa?mann wrote:

Are the labels needed? Adding them when they're used might be a better
approach.


From swarren at wwwdotorg.org  Wed Jul 31 15:49:14 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 Jul 2013 13:49:14 -0600
Subject: [PATCH 9/10] ARM: dts: tx28: restructure and update DTS file
In-Reply-To: <1375281480-25775-9-git-send-email-LW@KARO-electronics.de>
References: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
 <1375281480-25775-9-git-send-email-LW@KARO-electronics.de>
Message-ID: <51F96A3A.30409@wwwdotorg.org>

On 07/31/2013 08:37 AM, Lothar Wa?mann wrote:

This patch is definitely too invasive not to have a description.

> diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts

> + * Copyright 2013 Lothar Wa?mann <LW at KARO-electronics.de>

I don't think you're the only person who wrote these. Perhaps other
people should be listed here too?

> +#define USE_SPI_GPIO

What's that?

> +	chosen {
> +		bootargs = "init=/linuxrc console=ttyAMA0,115200 root=/dev/mtdblock3 rootfstype=jffs2 ro debug panic=1";
> +	};

I think this should be set by the bootloader, not hard-coded.



From stefano.stabellini at eu.citrix.com  Wed Jul 31 15:52:50 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 20:52:50 +0100
Subject: [PATCH v2 RFC 0/8] enable swiotlb-xen on arm and arm64
Message-ID: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>

Hi all,
this patch series enables xen-swiotlb on arm and arm64.

Considering that all guests, including dom0, run on xen on arm with
second stage translation enabled, it follows that without an IOMMU no
guests could actually drive the hardware.

The solution for platforms without an IOMMU is to use swiotlb-xen,
adapted to autotranslate guests. swiotlb-xen provides a set of dma_ops
that can be used by Linux to setup a contiguous buffer in stage-2
addresses and use it for dma operations.
Basically Linux asks Xen to make a buffer contiguous and gets the
machine address for it. This buffer is going to be used by lib/swiotlb.c
to allocate bounce buffers.


The first 3 patches lay the groundwork on arm and arm64 to have
alternative dma_ops and swiotlb.

The forth patch moves Xen initialization earlier so that we already know
whether we are running on Xen at the time of initializing dma_ops on the
platform.

The following patches adapt swiotlb-xen to autotranslate guests (guest
with second stage translation in hardware) and provide an arm
implementation of xen_create_contiguous_region.


Feedback is very welcome.
Cheers,

Stefano



Changes in v2:
- fixed a couple of errors in xen_bus_to_phys, xen_phys_to_bus and
xen_swiotlb_fixup.



Stefano Stabellini (8):
      arm: make SWIOTLB available
      arm: introduce a global dma_ops pointer
      arm64: do not initialize arm64_swiotlb if dma_ops is already set
      xen/arm,arm64: move Xen initialization earlier
      xen: introduce XENMEM_get_dma_buf and xen_put_dma_buf
      xen: make xen_create_contiguous_region return the dma address
      swiotlb-xen: support autotranslate guests
      xen/arm,arm64: enable SWIOTLB_XEN

 arch/arm/Kconfig                      |    8 ++
 arch/arm/common/dmabounce.c           |   10 +-
 arch/arm/include/asm/dma-mapping.h    |   27 ++++++-
 arch/arm/include/asm/xen/hypervisor.h |    6 ++
 arch/arm/include/asm/xen/page.h       |    2 +
 arch/arm/kernel/setup.c               |    2 +
 arch/arm/mm/dma-mapping.c             |    3 +
 arch/arm/xen/Makefile                 |    2 +-
 arch/arm/xen/enlighten.c              |   24 ++++--
 arch/arm/xen/mm.c                     |  117 ++++++++++++++++++++++++++
 arch/arm64/Kconfig                    |    1 +
 arch/arm64/kernel/setup.c             |    2 +
 arch/arm64/mm/dma-mapping.c           |    2 +
 arch/arm64/xen/Makefile               |    2 +-
 arch/x86/xen/mmu.c                    |    4 +-
 drivers/xen/Kconfig                   |    1 -
 drivers/xen/swiotlb-xen.c             |  147 +++++++++++++++++++++++++++++----
 include/xen/interface/memory.h        |   62 ++++++++++++++
 include/xen/xen-ops.h                 |    3 +-
 19 files changed, 390 insertions(+), 35 deletions(-)
 create mode 100644 arch/arm/xen/mm.c

git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git swiotlb-xen-2


From stefano.stabellini at eu.citrix.com  Wed Jul 31 15:54:05 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 20:54:05 +0100
Subject: [PATCH v2 RFC 1/8] arm: make SWIOTLB available
In-Reply-To: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
Message-ID: <1375300452-12545-1-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: will.deacon at arm.com
CC: linux at arm.linux.org.uk
---
 arch/arm/Kconfig                   |    7 +++++++
 arch/arm/include/asm/dma-mapping.h |   24 ++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ba412e0..05125ab 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1832,6 +1832,13 @@ config CC_STACKPROTECTOR
 	  neutralized via a kernel panic.
 	  This feature requires gcc version 4.2 or above.
 
+config SWIOTLB
+	def_bool y
+	select NEED_SG_DMA_LENGTH
+
+config IOMMU_HELPER
+	def_bool SWIOTLB
+
 config XEN_DOM0
 	def_bool y
 	depends on XEN
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 5b579b9..ad89e0f 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -86,6 +86,30 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
 }
 #endif
 
+static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
+{
+	unsigned int offset = paddr & ~PAGE_MASK;
+	return pfn_to_dma(dev, paddr >> PAGE_SHIFT) + offset;
+}
+
+static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dev_addr)
+{
+	unsigned int offset = dev_addr & ~PAGE_MASK;
+	return (dma_to_pfn(dev, dev_addr) << PAGE_SHIFT) + offset;
+}
+
+static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
+{
+	if (!dev->dma_mask)
+		return 0;
+
+	return addr + size - 1 <= *dev->dma_mask;
+}
+
+static inline void dma_mark_clean(void *addr, size_t size)
+{
+}
+
 /*
  * DMA errors are defined by all-bits-set in the DMA address.
  */
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Jul 31 15:54:07 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 20:54:07 +0100
Subject: [PATCH v2 RFC 3/8] arm64: do not initialize arm64_swiotlb if dma_ops
 is already set
In-Reply-To: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
Message-ID: <1375300452-12545-3-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: catalin.marinas at arm.com
CC: will.deacon at arm.com
---
 arch/arm64/mm/dma-mapping.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 4bd7579..a006e84 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -63,6 +63,8 @@ static struct dma_map_ops arm64_swiotlb_dma_ops = {
 
 void __init arm64_swiotlb_init(void)
 {
+	if (dma_ops != NULL)
+		return;
 	dma_ops = &arm64_swiotlb_dma_ops;
 	swiotlb_init(1);
 }
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Jul 31 15:54:08 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 20:54:08 +0100
Subject: [PATCH v2 RFC 4/8] xen/arm,arm64: move Xen initialization earlier
In-Reply-To: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
Message-ID: <1375300452-12545-4-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/include/asm/xen/hypervisor.h |    6 ++++++
 arch/arm/kernel/setup.c               |    2 ++
 arch/arm/xen/enlighten.c              |   21 ++++++++++++++-------
 arch/arm64/kernel/setup.c             |    2 ++
 4 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypervisor.h b/arch/arm/include/asm/xen/hypervisor.h
index d7ab99a..17b3ea2 100644
--- a/arch/arm/include/asm/xen/hypervisor.h
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -16,4 +16,10 @@ static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
 	return PARAVIRT_LAZY_NONE;
 }
 
+#ifdef CONFIG_XEN
+void xen_early_init(void);
+#else
+static inline void xen_early_init(void) { return; }
+#endif
+
 #endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 63af9a7..cb7b8e2 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -45,6 +45,7 @@
 #include <asm/cacheflush.h>
 #include <asm/cachetype.h>
 #include <asm/tlbflush.h>
+#include <asm/xen/hypervisor.h>
 
 #include <asm/prom.h>
 #include <asm/mach/arch.h>
@@ -889,6 +890,7 @@ void __init setup_arch(char **cmdline_p)
 
 	arm_dt_init_cpu_maps();
 	psci_init();
+	xen_early_init();
 #ifdef CONFIG_SMP
 	if (is_smp()) {
 		if (!mdesc->smp_init || !mdesc->smp_init()) {
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c9770ba..14d17ab 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -195,21 +195,19 @@ static void xen_power_off(void)
  * documentation of the Xen Device Tree format.
  */
 #define GRANT_TABLE_PHYSADDR 0
-static int __init xen_guest_init(void)
+void __init xen_early_init(void)
 {
-	struct xen_add_to_physmap xatp;
-	static struct shared_info *shared_info_page = 0;
+	struct resource res;
 	struct device_node *node;
 	int len;
 	const char *s = NULL;
 	const char *version = NULL;
 	const char *xen_prefix = "xen,xen-";
-	struct resource res;
 
 	node = of_find_compatible_node(NULL, NULL, "xen,xen");
 	if (!node) {
 		pr_debug("No Xen support\n");
-		return 0;
+		return;
 	}
 	s = of_get_property(node, "compatible", &len);
 	if (strlen(xen_prefix) + 3  < len &&
@@ -217,10 +215,10 @@ static int __init xen_guest_init(void)
 		version = s + strlen(xen_prefix);
 	if (version == NULL) {
 		pr_debug("Xen version not found\n");
-		return 0;
+		return;
 	}
 	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
-		return 0;
+		return;
 	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
 	xen_events_irq = irq_of_parse_and_map(node, 0);
 	pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
@@ -232,6 +230,15 @@ static int __init xen_guest_init(void)
 		xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
 	else
 		xen_start_info->flags &= ~(SIF_INITDOMAIN|SIF_PRIVILEGED);
+}
+
+static int __init xen_guest_init(void)
+{
+	struct xen_add_to_physmap xatp;
+	static struct shared_info *shared_info_page = 0;
+
+	if (!xen_domain())
+		return 0;
 
 	if (!shared_info_page)
 		shared_info_page = (struct shared_info *)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index add6ea6..e0d438a 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -53,6 +53,7 @@
 #include <asm/traps.h>
 #include <asm/memblock.h>
 #include <asm/psci.h>
+#include <asm/xen/hypervisor.h>
 
 unsigned int processor_id;
 EXPORT_SYMBOL(processor_id);
@@ -267,6 +268,7 @@ void __init setup_arch(char **cmdline_p)
 	unflatten_device_tree();
 
 	psci_init();
+	xen_early_init();
 
 	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
 #ifdef CONFIG_SMP
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Jul 31 15:54:09 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 20:54:09 +0100
Subject: [PATCH v2 RFC 5/8] xen: introduce XENMEM_get_dma_buf and
 xen_put_dma_buf
In-Reply-To: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
Message-ID: <1375300452-12545-5-git-send-email-stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 include/xen/interface/memory.h |   62 ++++++++++++++++++++++++++++++++++++++++
 1 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 2ecfe4f..ffd7f4e 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -263,4 +263,66 @@ struct xen_remove_from_physmap {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
 
+#define XENMEM_get_dma_buf             26
+/*
+ * This hypercall is similar to XENMEM_exchange: it exchanges the pages
+ * passed in with a new set of pages, contiguous and under 4G if so
+ * requested. The new pages are going to be "pinned": it's guaranteed
+ * that their p2m mapping won't be changed until explicitly "unpinned".
+ * If return code is zero then @out.extent_list provides the MFNs of the
+ * newly-allocated memory.  Returns zero on complete success, otherwise
+ * a negative error code.
+ * On complete success then always @nr_exchanged == @in.nr_extents.  On
+ * partial success @nr_exchanged indicates how much work was done.
+ */
+struct xen_get_dma_buf {
+    /*
+     * [IN] Details of memory extents to be exchanged (GMFN bases).
+     * Note that @in.address_bits is ignored and unused.
+     */
+    struct xen_memory_reservation in;
+
+    /*
+     * [IN/OUT] Details of new memory extents.
+     * We require that:
+     *  1. @in.domid == @out.domid
+     *  2. @in.nr_extents  << @in.extent_order == 
+     *     @out.nr_extents << @out.extent_order
+     *  3. @in.extent_start and @out.extent_start lists must not overlap
+     *  4. @out.extent_start lists GPFN bases to be populated
+     *  5. @out.extent_start is overwritten with allocated GMFN bases
+     */
+    struct xen_memory_reservation out;
+
+    /*
+     * [OUT] Number of input extents that were successfully exchanged:
+     *  1. The first @nr_exchanged input extents were successfully
+     *     deallocated.
+     *  2. The corresponding first entries in the output extent list correctly
+     *     indicate the GMFNs that were successfully exchanged.
+     *  3. All other input and output extents are untouched.
+     *  4. If not all input exents are exchanged then the return code of this
+     *     command will be non-zero.
+     *  5. THIS FIELD MUST BE INITIALISED TO ZERO BY THE CALLER!
+     */
+    xen_ulong_t nr_exchanged;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_get_dma_buf);
+
+#define XENMEM_put_dma_buf             27
+/*
+ * XENMEM_put_dma_buf unpins a set of pages, previously pinned by
+ * XENMEM_get_dma_buf. After this call the p2m mapping of the pages can
+ * be transparently changed by the hypervisor, as usual. The pages are
+ * still accessible from the guest.
+ */
+struct xen_put_dma_buf {
+    /*
+     * [IN] Details of memory extents to be exchanged (GMFN bases).
+     * Note that @in.address_bits is ignored and unused.
+     */
+    struct xen_memory_reservation in;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_put_dma_buf);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Jul 31 15:54:12 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 20:54:12 +0100
Subject: [PATCH v2 RFC 8/8] xen/arm,arm64: enable SWIOTLB_XEN
In-Reply-To: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
Message-ID: <1375300452-12545-8-git-send-email-stefano.stabellini@eu.citrix.com>

Xen on arm and arm64 needs SWIOTLB_XEN: when running on Xen we need to
program the hardware with mfns rather than pfns for dma addresses.
Remove SWIOTLB_XEN dependency on X86 and PCI and make XEN select
SWIOTLB_XEN on arm and arm64.

Implement xen_create_contiguous_region on arm and arm64 by using
XENMEM_get_dma_buf.

Initialize the xen-swiotlb from xen_early_init (before the native
dma_ops are initialized), set dma_ops to &xen_swiotlb_dma_ops if we are
running on Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/Kconfig                |    1 +
 arch/arm/include/asm/xen/page.h |    2 +
 arch/arm/xen/Makefile           |    2 +-
 arch/arm/xen/enlighten.c        |    3 +
 arch/arm/xen/mm.c               |  117 +++++++++++++++++++++++++++++++++++++++
 arch/arm64/Kconfig              |    1 +
 arch/arm64/xen/Makefile         |    2 +-
 drivers/xen/Kconfig             |    1 -
 drivers/xen/swiotlb-xen.c       |   18 ++++++
 9 files changed, 144 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/xen/mm.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 05125ab..72b53b9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1849,6 +1849,7 @@ config XEN
 	depends on CPU_V7 && !CPU_V6
 	depends on !GENERIC_ATOMIC64
 	select ARM_PSCI
+	select SWIOTLB_XEN
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
 
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 359a7b5..b0f7150 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -6,12 +6,14 @@
 
 #include <linux/pfn.h>
 #include <linux/types.h>
+#include <linux/dma-mapping.h>
 
 #include <xen/interface/grant_table.h>
 
 #define pfn_to_mfn(pfn)			(pfn)
 #define phys_to_machine_mapping_valid(pfn) (1)
 #define mfn_to_pfn(mfn)			(mfn)
+#define mfn_to_local_pfn(m)             (mfn_to_pfn(m))
 #define mfn_to_virt(m)			(__va(mfn_to_pfn(m) << PAGE_SHIFT))
 
 #define pte_mfn	    pte_pfn
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 4384103..66fc35d 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o hypercall.o grant-table.o
+obj-y		:= enlighten.o hypercall.o grant-table.o mm.o
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 14d17ab..06a6953 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -195,6 +195,7 @@ static void xen_power_off(void)
  * documentation of the Xen Device Tree format.
  */
 #define GRANT_TABLE_PHYSADDR 0
+extern int xen_mm_init(void);
 void __init xen_early_init(void)
 {
 	struct resource res;
@@ -230,6 +231,8 @@ void __init xen_early_init(void)
 		xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
 	else
 		xen_start_info->flags &= ~(SIF_INITDOMAIN|SIF_PRIVILEGED);
+
+	xen_mm_init();
 }
 
 static int __init xen_guest_init(void)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
new file mode 100644
index 0000000..22dbf7c
--- /dev/null
+++ b/arch/arm/xen/mm.c
@@ -0,0 +1,117 @@
+#include <linux/bootmem.h>
+#include <linux/gfp.h>
+#include <linux/export.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/dma-mapping.h>
+#include <linux/vmalloc.h>
+#include <linux/swiotlb.h>
+
+#include <xen/xen.h>
+#include <xen/interface/memory.h>
+#include <xen/swiotlb-xen.h>
+
+#include <asm/cacheflush.h>
+#include <asm/xen/page.h>
+#include <asm/xen/hypercall.h>
+#include <asm/xen/interface.h>
+
+static int xen_exchange_memory(xen_ulong_t extents_in,
+			       unsigned int order_in,
+			       xen_pfn_t *pfns_in,
+			       xen_ulong_t extents_out,
+			       unsigned int order_out,
+			       xen_pfn_t *mfns_out,
+			       unsigned int address_bits)
+{
+	long rc;
+	int success;
+
+	struct xen_memory_exchange exchange = {
+		.in = {
+			.nr_extents   = extents_in,
+			.extent_order = order_in,
+			.domid        = DOMID_SELF
+		},
+		.out = {
+			.nr_extents   = extents_out,
+			.extent_order = order_out,
+			.address_bits = address_bits,
+			.domid        = DOMID_SELF
+		}
+	};
+	set_xen_guest_handle(exchange.in.extent_start, pfns_in);
+	set_xen_guest_handle(exchange.out.extent_start, mfns_out);
+
+	BUG_ON(extents_in << order_in != extents_out << order_out);
+
+
+	rc = HYPERVISOR_memory_op(XENMEM_get_dma_buf, &exchange);
+	success = (exchange.nr_exchanged == extents_in);
+
+	BUG_ON(!success && ((exchange.nr_exchanged != 0) || (rc == 0)));
+	BUG_ON(success && (rc != 0));
+
+	return success;
+}
+
+int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
+				 unsigned int address_bits,
+				 dma_addr_t *dma_handle)
+{
+	phys_addr_t pstart = __pa(vstart);
+	xen_pfn_t in_frame, out_frame;
+	int success;
+
+	/* 2. Get a new contiguous memory extent. */
+	in_frame = out_frame = pstart >> PAGE_SHIFT;
+	success = xen_exchange_memory(1, order, &in_frame,
+				      1, order, &out_frame,
+				      address_bits);
+
+	if (!success)
+		return -ENOMEM;
+
+	*dma_handle = out_frame << PAGE_SHIFT;
+	
+	return success ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL_GPL(xen_create_contiguous_region);
+
+void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order)
+{
+	xen_pfn_t in_frame = __pa(vstart) >> PAGE_SHIFT;
+	struct xen_put_dma_buf buf = {
+		.in = {
+			.nr_extents   = 1,
+			.extent_order = order,
+			.domid        = DOMID_SELF
+		},
+	};
+	set_xen_guest_handle(buf.in.extent_start, &in_frame);
+
+	HYPERVISOR_memory_op(XENMEM_put_dma_buf, &buf);
+}
+EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
+
+static struct dma_map_ops xen_swiotlb_dma_ops = {
+	.mapping_error = xen_swiotlb_dma_mapping_error,
+	.alloc = xen_swiotlb_alloc_coherent,
+	.free = xen_swiotlb_free_coherent,
+	.sync_single_for_cpu = xen_swiotlb_sync_single_for_cpu,
+	.sync_single_for_device = xen_swiotlb_sync_single_for_device,
+	.sync_sg_for_cpu = xen_swiotlb_sync_sg_for_cpu,
+	.sync_sg_for_device = xen_swiotlb_sync_sg_for_device,
+	.map_sg = xen_swiotlb_map_sg_attrs,
+	.unmap_sg = xen_swiotlb_unmap_sg_attrs,
+	.map_page = xen_swiotlb_map_page,
+	.unmap_page = xen_swiotlb_unmap_page,
+	.dma_supported = xen_swiotlb_dma_supported,
+};
+
+int __init xen_mm_init(void)
+{
+	xen_swiotlb_init(1, true);
+	dma_ops = &xen_swiotlb_dma_ops;
+	return 0;
+}
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9737e97..aa1f6fb 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -209,6 +209,7 @@ config XEN_DOM0
 config XEN
 	bool "Xen guest support on ARM64 (EXPERIMENTAL)"
 	depends on ARM64 && OF
+	select SWIOTLB_XEN
 	help
 	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM64.
 
diff --git a/arch/arm64/xen/Makefile b/arch/arm64/xen/Makefile
index be24040..0ef9637 100644
--- a/arch/arm64/xen/Makefile
+++ b/arch/arm64/xen/Makefile
@@ -1,2 +1,2 @@
-xen-arm-y	+= $(addprefix ../../arm/xen/, enlighten.o grant-table.o)
+xen-arm-y	+= $(addprefix ../../arm/xen/, enlighten.o grant-table.o mm.o)
 obj-y		:= xen-arm.o hypercall.o
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 9e02d60..7e83688 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -140,7 +140,6 @@ config XEN_GRANT_DEV_ALLOC
 
 config SWIOTLB_XEN
 	def_bool y
-	depends on PCI && X86
 	select SWIOTLB
 
 config XEN_TMEM
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 3fadb6b..d19c240 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -59,6 +59,24 @@ static unsigned long xen_io_tlb_nslabs;
  * Quick lookup value of the bus address of the IOTLB.
  */
 
+#ifndef DMA_ERROR_CODE
+#define DMA_ERROR_CODE	(~0)
+#endif
+
+#ifndef CONFIG_X86
+static unsigned long dma_alloc_coherent_mask(struct device *dev,
+					    gfp_t gfp)
+{
+	unsigned long dma_mask = 0;
+
+	dma_mask = dev->coherent_dma_mask;
+	if (!dma_mask)
+		dma_mask = (gfp & GFP_DMA) ? DMA_BIT_MASK(24) : DMA_BIT_MASK(32);
+
+	return dma_mask;
+}
+#endif
+
 struct xen_dma{
 	dma_addr_t dma_addr;
 	phys_addr_t phys_addr;
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Jul 31 15:54:11 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 20:54:11 +0100
Subject: [PATCH v2 RFC 7/8] swiotlb-xen: support autotranslate guests
In-Reply-To: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
Message-ID: <1375300452-12545-7-git-send-email-stefano.stabellini@eu.citrix.com>

Support autotranslate guests in swiotlb-xen by keeping track of the
phys-to-bus and bus-to-phys mappings of the swiotlb buffer
(xen_io_tlb_start-xen_io_tlb_end).

Use a simple direct access on a pre-allocated array for phys-to-bus
queries. Use a red-black tree for bus-to-phys queries.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: david.vrabel at citrix.com
---
 drivers/xen/swiotlb-xen.c |  127 +++++++++++++++++++++++++++++++++++++++------
 1 files changed, 111 insertions(+), 16 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 353f013..3fadb6b 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -38,32 +38,116 @@
 #include <linux/bootmem.h>
 #include <linux/dma-mapping.h>
 #include <linux/export.h>
+#include <linux/slab.h>
+#include <linux/spinlock_types.h>
+#include <linux/rbtree.h>
 #include <xen/swiotlb-xen.h>
 #include <xen/page.h>
 #include <xen/xen-ops.h>
 #include <xen/hvc-console.h>
+#include <xen/features.h>
 /*
  * Used to do a quick range check in swiotlb_tbl_unmap_single and
  * swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by this
  * API.
  */
 
+#define NR_DMA_SEGS  ((xen_io_tlb_nslabs + IO_TLB_SEGSIZE - 1) / IO_TLB_SEGSIZE)
 static char *xen_io_tlb_start, *xen_io_tlb_end;
 static unsigned long xen_io_tlb_nslabs;
 /*
  * Quick lookup value of the bus address of the IOTLB.
  */
 
-static u64 start_dma_addr;
+struct xen_dma{
+	dma_addr_t dma_addr;
+	phys_addr_t phys_addr;
+	size_t size;
+	struct rb_node rbnode;
+};
+
+static struct xen_dma *xen_dma_seg;
+static struct rb_root bus_to_phys = RB_ROOT;
+static DEFINE_SPINLOCK(xen_dma_lock);
+
+static void xen_dma_insert(struct xen_dma *entry)
+{
+	struct rb_node **link = &bus_to_phys.rb_node;
+	struct rb_node *parent = NULL;
+	struct xen_dma *e;
+
+	spin_lock(&xen_dma_lock);
+
+	while (*link) {
+		parent = *link;
+		e = rb_entry(parent, struct xen_dma, rbnode);
+
+		WARN_ON(entry->dma_addr == e->dma_addr);
+
+		if (entry->dma_addr < e->dma_addr)
+			link = &(*link)->rb_left;
+		else
+			link = &(*link)->rb_right;
+	}
+	rb_link_node(&entry->rbnode, parent, link);
+	rb_insert_color(&entry->rbnode, &bus_to_phys);
+
+	spin_unlock(&xen_dma_lock);
+}
+
+static struct xen_dma *xen_dma_retrieve(dma_addr_t dma_addr)
+{
+	struct rb_node *n = bus_to_phys.rb_node;
+	struct xen_dma *e;
+	
+	spin_lock(&xen_dma_lock);
+
+	while (n) {
+		e = rb_entry(n, struct xen_dma, rbnode);
+		if (e->dma_addr <= dma_addr && e->dma_addr + e->size > dma_addr) {
+			spin_unlock(&xen_dma_lock);
+			return e;
+		}
+		if (dma_addr < e->dma_addr)
+			n = n->rb_left;
+		else
+			n = n->rb_right;
+	}
+
+	spin_unlock(&xen_dma_lock);
+	return NULL;
+}
 
 static dma_addr_t xen_phys_to_bus(phys_addr_t paddr)
 {
-	return phys_to_machine(XPADDR(paddr)).maddr;
+	int nr_seg;
+	unsigned long offset;
+	char* vaddr;
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		return phys_to_machine(XPADDR(paddr)).maddr;
+
+	vaddr = (char *) phys_to_virt(paddr);
+	if (vaddr >= xen_io_tlb_end || vaddr < xen_io_tlb_start)
+		return ~0;
+
+	offset = vaddr - xen_io_tlb_start;
+	nr_seg = offset / (IO_TLB_SEGSIZE << IO_TLB_SHIFT);
+
+	return xen_dma_seg[nr_seg].dma_addr + (paddr - xen_dma_seg[nr_seg].phys_addr);
 }
 
 static phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
 {
-	return machine_to_phys(XMADDR(baddr)).paddr;
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+	{
+		struct xen_dma *dma = xen_dma_retrieve(baddr);
+		if (dma == NULL)
+			return ~0;
+		else
+			return dma->phys_addr + (baddr - dma->dma_addr);
+	} else
+		return machine_to_phys(XMADDR(baddr)).paddr;
 }
 
 static dma_addr_t xen_virt_to_bus(void *address)
@@ -107,6 +191,9 @@ static int is_xen_swiotlb_buffer(dma_addr_t dma_addr)
 	unsigned long pfn = mfn_to_local_pfn(mfn);
 	phys_addr_t paddr;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return 1;
+
 	/* If the address is outside our domain, it CAN
 	 * have the same virtual address as another address
 	 * in our domain. Therefore _only_ check address within our domain.
@@ -124,13 +211,12 @@ static int max_dma_bits = 32;
 static int
 xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 {
-	int i, rc;
+	int i, j, rc;
 	int dma_bits;
-	dma_addr_t dma_handle;
 
 	dma_bits = get_order(IO_TLB_SEGSIZE << IO_TLB_SHIFT) + PAGE_SHIFT;
 
-	i = 0;
+	i = j = 0;
 	do {
 		int slabs = min(nslabs - i, (unsigned long)IO_TLB_SEGSIZE);
 
@@ -138,12 +224,16 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 			rc = xen_create_contiguous_region(
 				(unsigned long)buf + (i << IO_TLB_SHIFT),
 				get_order(slabs << IO_TLB_SHIFT),
-				dma_bits, &dma_handle);
+				dma_bits, &xen_dma_seg[j].dma_addr);
 		} while (rc && dma_bits++ < max_dma_bits);
 		if (rc)
 			return rc;
 
+		xen_dma_seg[j].phys_addr = virt_to_phys(buf + (i << IO_TLB_SHIFT));
+		xen_dma_seg[j].size = slabs << IO_TLB_SHIFT;
+		xen_dma_insert(&xen_dma_seg[j]);
 		i += slabs;
+		j++;
 	} while (i < nslabs);
 	return 0;
 }
@@ -193,9 +283,10 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	if (early)
+	if (early) {
 		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
-	else {
+		xen_dma_seg = alloc_bootmem(sizeof(struct xen_dma) * NR_DMA_SEGS);
+	} else {
 #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
 #define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
 		while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
@@ -210,6 +301,7 @@ retry:
 			xen_io_tlb_nslabs = SLABS_PER_PAGE << order;
 			bytes = xen_io_tlb_nslabs << IO_TLB_SHIFT;
 		}
+		xen_dma_seg = kzalloc(sizeof(struct xen_dma) * NR_DMA_SEGS, GFP_KERNEL);
 	}
 	if (!xen_io_tlb_start) {
 		m_ret = XEN_SWIOTLB_ENOMEM;
@@ -232,7 +324,6 @@ retry:
 		m_ret = XEN_SWIOTLB_EFIXUP;
 		goto error;
 	}
-	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
 	if (early) {
 		if (swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs,
 			 verbose))
@@ -290,7 +381,8 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 
 	phys = virt_to_phys(ret);
 	dev_addr = xen_phys_to_bus(phys);
-	if (((dev_addr + size - 1 <= dma_mask)) &&
+	if (!xen_feature(XENFEAT_auto_translated_physmap) &&
+	    ((dev_addr + size - 1 <= dma_mask)) &&
 	    !range_straddles_page_boundary(phys, size))
 		*dma_handle = dev_addr;
 	else {
@@ -321,8 +413,9 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr,
 
 	phys = virt_to_phys(vaddr);
 
-	if (((dev_addr + size - 1 > dma_mask)) ||
-	    range_straddles_page_boundary(phys, size))
+	if (xen_feature(XENFEAT_auto_translated_physmap) ||
+		(((dev_addr + size - 1 > dma_mask)) ||
+		 range_straddles_page_boundary(phys, size)))
 		xen_destroy_contiguous_region((unsigned long)vaddr, order);
 
 	free_pages((unsigned long)vaddr, order);
@@ -351,14 +444,15 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 	 * we can safely return the device addr and not worry about bounce
 	 * buffering it.
 	 */
-	if (dma_capable(dev, dev_addr, size) &&
+	if (!xen_feature(XENFEAT_auto_translated_physmap) &&
+	    dma_capable(dev, dev_addr, size) &&
 	    !range_straddles_page_boundary(phys, size) && !swiotlb_force)
 		return dev_addr;
 
 	/*
 	 * Oh well, have to allocate and map a bounce buffer.
 	 */
-	map = swiotlb_tbl_map_single(dev, start_dma_addr, phys, size, dir);
+	map = swiotlb_tbl_map_single(dev, xen_dma_seg[0].dma_addr, phys, size, dir);
 	if (map == SWIOTLB_MAP_ERROR)
 		return DMA_ERROR_CODE;
 
@@ -494,10 +588,11 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
 
 		if (swiotlb_force ||
+		    xen_feature(XENFEAT_auto_translated_physmap) ||
 		    !dma_capable(hwdev, dev_addr, sg->length) ||
 		    range_straddles_page_boundary(paddr, sg->length)) {
 			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
-								 start_dma_addr,
+								 xen_dma_seg[0].dma_addr,
 								 sg_phys(sg),
 								 sg->length,
 								 dir);
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Jul 31 15:54:06 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 20:54:06 +0100
Subject: [PATCH v2 RFC 2/8] arm: introduce a global dma_ops pointer
In-Reply-To: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
Message-ID: <1375300452-12545-2-git-send-email-stefano.stabellini@eu.citrix.com>

Initially set dma_ops to arm_dma_ops.
Use dma_ops instead of arm_dma_ops in dmabounce.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: will.deacon at arm.com
CC: linux at arm.linux.org.uk
---
 arch/arm/common/dmabounce.c        |   10 +++++-----
 arch/arm/include/asm/dma-mapping.h |    3 ++-
 arch/arm/mm/dma-mapping.c          |    3 +++
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
index 1143c4d..b626122 100644
--- a/arch/arm/common/dmabounce.c
+++ b/arch/arm/common/dmabounce.c
@@ -325,7 +325,7 @@ static dma_addr_t dmabounce_map_page(struct device *dev, struct page *page,
 		return DMA_ERROR_CODE;
 
 	if (ret == 0) {
-		arm_dma_ops.sync_single_for_device(dev, dma_addr, size, dir);
+		dma_ops->sync_single_for_device(dev, dma_addr, size, dir);
 		return dma_addr;
 	}
 
@@ -353,7 +353,7 @@ static void dmabounce_unmap_page(struct device *dev, dma_addr_t dma_addr, size_t
 
 	buf = find_safe_buffer_dev(dev, dma_addr, __func__);
 	if (!buf) {
-		arm_dma_ops.sync_single_for_cpu(dev, dma_addr, size, dir);
+		dma_ops->sync_single_for_cpu(dev, dma_addr, size, dir);
 		return;
 	}
 
@@ -397,7 +397,7 @@ static void dmabounce_sync_for_cpu(struct device *dev,
 	if (!__dmabounce_sync_for_cpu(dev, handle, size, dir))
 		return;
 
-	arm_dma_ops.sync_single_for_cpu(dev, handle, size, dir);
+	dma_ops->sync_single_for_cpu(dev, handle, size, dir);
 }
 
 static int __dmabounce_sync_for_device(struct device *dev, dma_addr_t addr,
@@ -437,7 +437,7 @@ static void dmabounce_sync_for_device(struct device *dev,
 	if (!__dmabounce_sync_for_device(dev, handle, size, dir))
 		return;
 
-	arm_dma_ops.sync_single_for_device(dev, handle, size, dir);
+	dma_ops->sync_single_for_device(dev, handle, size, dir);
 }
 
 static int dmabounce_set_mask(struct device *dev, u64 dma_mask)
@@ -445,7 +445,7 @@ static int dmabounce_set_mask(struct device *dev, u64 dma_mask)
 	if (dev->archdata.dmabounce)
 		return 0;
 
-	return arm_dma_ops.set_dma_mask(dev, dma_mask);
+	return dma_ops->set_dma_mask(dev, dma_mask);
 }
 
 static struct dma_map_ops dmabounce_ops = {
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index ad89e0f..f907f65 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -12,6 +12,7 @@
 #include <asm/memory.h>
 
 #define DMA_ERROR_CODE	(~0)
+extern struct dma_map_ops *dma_ops;
 extern struct dma_map_ops arm_dma_ops;
 extern struct dma_map_ops arm_coherent_dma_ops;
 
@@ -19,7 +20,7 @@ static inline struct dma_map_ops *get_dma_ops(struct device *dev)
 {
 	if (dev && dev->archdata.dma_ops)
 		return dev->archdata.dma_ops;
-	return &arm_dma_ops;
+	return dma_ops;
 }
 
 static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 7f9b179..870b12c 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -141,6 +141,9 @@ struct dma_map_ops arm_dma_ops = {
 };
 EXPORT_SYMBOL(arm_dma_ops);
 
+struct dma_map_ops *dma_ops = &arm_dma_ops;
+EXPORT_SYMBOL(dma_ops);
+
 static void *arm_coherent_dma_alloc(struct device *dev, size_t size,
 	dma_addr_t *handle, gfp_t gfp, struct dma_attrs *attrs);
 static void arm_coherent_dma_free(struct device *dev, size_t size, void *cpu_addr,
-- 
1.7.2.5



From stefano.stabellini at eu.citrix.com  Wed Jul 31 15:54:10 2013
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Wed, 31 Jul 2013 20:54:10 +0100
Subject: [PATCH v2 RFC 6/8] xen: make xen_create_contiguous_region return the
 dma address
In-Reply-To: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
Message-ID: <1375300452-12545-6-git-send-email-stefano.stabellini@eu.citrix.com>

Modify xen_create_contiguous_region to return the dma address of the
newly contiguous buffer.

Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
CC: david.vrabel at citrix.com
---
 arch/x86/xen/mmu.c        |    4 +++-
 drivers/xen/swiotlb-xen.c |    6 +++---
 include/xen/xen-ops.h     |    3 ++-
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index fdc3ba2..df9ab44 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2329,7 +2329,8 @@ static int xen_exchange_memory(unsigned long extents_in, unsigned int order_in,
 }
 
 int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
-				 unsigned int address_bits)
+				 unsigned int address_bits,
+				 dma_addr_t *dma_handle)
 {
 	unsigned long *in_frames = discontig_frames, out_frame;
 	unsigned long  flags;
@@ -2368,6 +2369,7 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
 
 	spin_unlock_irqrestore(&xen_reservation_lock, flags);
 
+	*dma_handle = xen_virt_to_bus(vstart);
 	return success ? 0 : -ENOMEM;
 }
 EXPORT_SYMBOL_GPL(xen_create_contiguous_region);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index aadffcf..353f013 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -126,6 +126,7 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 {
 	int i, rc;
 	int dma_bits;
+	dma_addr_t dma_handle;
 
 	dma_bits = get_order(IO_TLB_SEGSIZE << IO_TLB_SHIFT) + PAGE_SHIFT;
 
@@ -137,7 +138,7 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 			rc = xen_create_contiguous_region(
 				(unsigned long)buf + (i << IO_TLB_SHIFT),
 				get_order(slabs << IO_TLB_SHIFT),
-				dma_bits);
+				dma_bits, &dma_handle);
 		} while (rc && dma_bits++ < max_dma_bits);
 		if (rc)
 			return rc;
@@ -294,11 +295,10 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 		*dma_handle = dev_addr;
 	else {
 		if (xen_create_contiguous_region(vstart, order,
-						 fls64(dma_mask)) != 0) {
+						 fls64(dma_mask), dma_handle) != 0) {
 			free_pages(vstart, order);
 			return NULL;
 		}
-		*dma_handle = virt_to_machine(ret).maddr;
 	}
 	memset(ret, 0, size);
 	return ret;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index d6fe062..9ef704d 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -20,7 +20,8 @@ int xen_setup_shutdown_event(void);
 
 extern unsigned long *xen_contiguous_bitmap;
 int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
-				unsigned int address_bits);
+				unsigned int address_bits,
+				dma_addr_t *dma_handle);
 
 void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order);
 
-- 
1.7.2.5



From swarren at wwwdotorg.org  Wed Jul 31 15:57:37 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 Jul 2013 13:57:37 -0600
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4OzFdZhX0Kzu_6KiimD=KxDr6EM13zUH3GGE=hHaYx=m=Q@mail.gmail.com>
References: <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <20130730205716.GZ9858@sirena.org.uk>
 <CAKON4Ox7-6Jf0ce64Wqr5E49KS+9E135mqc_iG-PWQ7r8bzWHA@mail.gmail.com>
 <20130730230331.GC9858@sirena.org.uk>
 <CAKON4OzFdZhX0Kzu_6KiimD=KxDr6EM13zUH3GGE=hHaYx=m=Q@mail.gmail.com>
Message-ID: <51F96C31.8030305@wwwdotorg.org>

On 07/30/2013 05:23 PM, jonsmirl at gmail.com wrote:
...
> Uboot could be an issue but I don't think they are actually doing
> anything with FDTs yet, they are just talking about doing it.

A couple U-Boot platforms (Tegra, Exynos) actually use DT to
parameterize U-Boot itself, just like the kernel uses it, although:

* often the bindings used there are not the "real" bindings defined in
the kernel:-(

* They use a DTB embedded into the U-Boot binary, which is a different
DTB to that passed to the kernel, which at least in the Tegra case is
always loaded from disk e.g. from /boot, just like zImage is.

U-Boot certainly passes DTs to the kernel, and performs some limited
modification on it such as setting the kernel cmdline, memory size, etc.


From richardcochran at gmail.com  Wed Jul 31 16:00:17 2013
From: richardcochran at gmail.com (Richard Cochran)
Date: Wed, 31 Jul 2013 22:00:17 +0200
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <1409617.9untvfnOTJ@flatron>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1999586.84BnWE5EUh@thinkpad> <20130731191209.GA8027@netboy>
 <1409617.9untvfnOTJ@flatron>
Message-ID: <20130731200017.GC8027@netboy>

On Wed, Jul 31, 2013 at 09:29:35PM +0200, Tomasz Figa wrote:
> 
> I showed you two example solutions that could handle this use case without 
> stable binding ABI, just to prove that b) is not the only option (even if 
> it's the best one, which I continue to agree on, don't get me wrong).

You only showed *one* solution (b) that satisfies the use case. The
use case was:

   User acquires a machine running ARM Linux version 3.x, with u-boot
   and dtb in a read only flash partition. The board boots and works just
                ^^^^^^^^^^^^^^^^^^^^^^^^^
   fine. However, for his application, the user requires a new kernel
   feature that appeared in version 3.y where y > x. He compiles the new
   kernel, and it also works.

But you suggested:

 a) using DT as direct replacement for board files - this means that you
    are free to say that DTSes are strictly coupled with kernel version
    and you are free to modify the bindings - see the analogy to board
    files, where you could modify the platform data structures and could
    not directly copy board file from one kernel version to another,

In the use case, the kernel is upgraded, but not the DTB. So this
solution makes no sense.

> I also added that the use case is not fully valid,

The use case *is* valid.  I am not inventing this just to be a pain.
There are plenty of people unable or unwilling to upgrade their boot
loader or DTB.  You can say that you won't support it, but it is a use
case from actual real life.

> because you can't 
> magically define bindings for all future hardware, which means you can't 
> support the hardware using a DTB made before stable bindings for that 
> hardware have ever been introduced.

Surely it is possible to develop and release a stable kernel and DT
ABI for a given hardware? Once this is present, it is reasonable for
users to expect forward compatibility from the DT system.
 
> With all of this, I agreed that a DTB made for kernel 3.x, when used with 
> kernel 3.y (y > x) should provide the same or greater feature set than 
> used with kernel 3.x, in other words, this should cause no regressions. 
> Still, for new features, you will likely need to update the DTB.

Yes, that is the idea.

> So, again, to summarize, my view on this is as follows:
>  - there is a list of best practices for binding design and existing 
>    stable bindings that can be used to help for designing new bindings,
>  - new bindings go through review process,
>  - after positive review, such bindings gets staging status, i.e. they are 
>    marked as something that could change,
>  - after some period of time (we need to define this precisely) they get 
>    frozen and can't be changed in a way that breaks compatibility any
>    more. In other words, they become ABI.
> 
> What do you think?

Sounds okay to me, but why bother with this marking business? Why not
just have staging or development trees like every other subsystem?

Thanks,
Richard



From linux at arm.linux.org.uk  Wed Jul 31 16:01:35 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 31 Jul 2013 21:01:35 +0100
Subject: [PATCH v2 RFC 2/8] arm: introduce a global dma_ops pointer
In-Reply-To: <1375300452-12545-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1307312048511.4893@kaball.uk.xensource.com>
 <1375300452-12545-2-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <20130731200135.GZ24642@n2100.arm.linux.org.uk>

On Wed, Jul 31, 2013 at 08:54:06PM +0100, Stefano Stabellini wrote:
> Initially set dma_ops to arm_dma_ops.
> Use dma_ops instead of arm_dma_ops in dmabounce.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> CC: will.deacon at arm.com
> CC: linux at arm.linux.org.uk

If you're using swiotlb, there's little point in converting dmabounce
to be able to use it, because it's basically providing the same
functionality - dmabounce is there to do software buffer bouncing within
the DMA to move streaming buffers from DMA-inaccessible memory into
DMA-accessible memory.

It's original use is with older SoCs with buggy DMA (eg, those which
can only address alternate 1MB chunks of memory for example) but also
got used in situations where alternative solutions would've been better
(like using swiotlb.)  I've been discouraging its use as it's suffered
from memory exhaustion problems (there's a number of threads and bug
reports which were never solved about IXP4xx(?) platforms suffering
this due to this bouncing.)


From ben.dooks at codethink.co.uk  Wed Jul 31 16:05:16 2013
From: ben.dooks at codethink.co.uk (Ben Dooks)
Date: Wed, 31 Jul 2013 21:05:16 +0100
Subject: [repost] ARM big-endian support
In-Reply-To: <20130729152637.204c2622@skate>
References: <1374661682-9349-1-git-send-email-ben.dooks@codethink.co.uk>
 <51EFFB53.5060003@codethink.co.uk> <20130729152637.204c2622@skate>
Message-ID: <51F96DFC.9090309@codethink.co.uk>

On 29/07/13 14:26, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Wed, 24 Jul 2013 17:05:39 +0100, Ben Dooks wrote:
>> On 24/07/13 11:27, Ben Dooks wrote:
>>> A repost (as requested) of the current big-endian core work for review.
>>
>> New branches at git.baserock.org/delta/linux.git
>> 	311/be/atags-v4
>>    	311/be/core-v4
>
> Thanks. Can you post a patch set based on top of 3.11-rc, so that it
> can hopefully be merged? Posting something based on 3.10 has no chance
> of being merged. Again, if you need any help on this, do not hesitate
> to ask.
>
> Also, would it be possible to get cover letters that include a proper
> changelog, as well as version number for each posting of the patch
> series?

I've lost quite a bit of the change information, so sorry about that.

The 3.11-rc series I will try and get done as soon as I've gone through
and sorted out the last round of review comments. Unfortunately I am
not in the office for the next three weeks.


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius


From linux at arm.linux.org.uk  Wed Jul 31 16:14:57 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 31 Jul 2013 21:14:57 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <20130731200017.GC8027@netboy>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1999586.84BnWE5EUh@thinkpad> <20130731191209.GA8027@netboy>
 <1409617.9untvfnOTJ@flatron> <20130731200017.GC8027@netboy>
Message-ID: <20130731201457.GA24642@n2100.arm.linux.org.uk>

On Wed, Jul 31, 2013 at 10:00:17PM +0200, Richard Cochran wrote:
> On Wed, Jul 31, 2013 at 09:29:35PM +0200, Tomasz Figa wrote:
> > 
> > I showed you two example solutions that could handle this use case without 
> > stable binding ABI, just to prove that b) is not the only option (even if 
> > it's the best one, which I continue to agree on, don't get me wrong).
> 
> You only showed *one* solution (b) that satisfies the use case. The
> use case was:
> 
>    User acquires a machine running ARM Linux version 3.x, with u-boot
>    and dtb in a read only flash partition. The board boots and works just
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^
>    fine. However, for his application, the user requires a new kernel
>    feature that appeared in version 3.y where y > x. He compiles the new
>    kernel, and it also works.
> 
> But you suggested:
> 
>  a) using DT as direct replacement for board files - this means that you
>     are free to say that DTSes are strictly coupled with kernel version
>     and you are free to modify the bindings - see the analogy to board
>     files, where you could modify the platform data structures and could
>     not directly copy board file from one kernel version to another,
> 
> In the use case, the kernel is upgraded, but not the DTB. So this
> solution makes no sense.

That's also crap for another reason.  DT on the whole is _supposed_ to
describe what the hardware is, and how it is wired up in a WELL DEFINED
and STABLE manner.  Unfortunately, there's a *BIG* mistake that was made
- having this /chosen node in DT which gets used for "software"
configuration - eg, the command line and so forth.

That was a mistake because it means that the DT isn't purely a
description of the hardware.  Such stuff should have been left in ATAGs,
and DT should have been placed into its own ATAG entry.  There would
not have been any conflict between ATAGs and DT, because ATAGs generally
don't deal with hardware configuration - the only real bit of hardware
configuration conveyed via ATAGs is the location of memory and size of
memory.

However, if we go back to the idea that DT is supposed to describe the
hardware, _and_ that the way to describe that hardware is well defined
and _stable_ (as it should be) then there should be no reason what so
ever that your old DT blob should not continue working in later kernels.
If it doesn't, then the contract that DT promised when we first moved
over to using DT has been _broken_.

Quite frankly, the fact that this discussion has gone on soo far, and
everyone is saying that the existing DT descriptions to date (for what,
two years) are all unstable is really extremely sad.

I've stated in my previous postings what I think very clearly - and it
comes down to the fact that every DT binding which is in existence in
a released kernel _is_ by that very nature a stable binding.  If it
wasn't a stable binding, it should have been clearly marked as such
and been subject to CONFIG_EXPERIMENTAL (when it existed) or
CONFIG_STAGING or similar.

We even went as far as creating documentation for the bindings - directly
along side the documentation for PPC bindings, with no distinction.

Given all that, it's down right insulting to those who have been using
ARM kernels to now start off a discussion about making these things
stable.  Those people who think that these bindings are not stable need
to wake up to reality - we have USERS of this stuff over the last two
years.  It's found its way into products.  If we're going to keep this
stuff "unstable" then we are actively _hurting_ our users.

I'll say it again: if a binding has been in a final kernel, it is by
definition a *stable* binding, and compatibility with that binding
*must* be maintained.

If we're not going to do that, then we owe all the users of the ARM
kernel a VERY BIG apology.


From andrey.warkentin at gmail.com  Wed Jul 31 16:19:13 2013
From: andrey.warkentin at gmail.com (Andrei E. Warkentin)
Date: Wed, 31 Jul 2013 16:19:13 -0400
Subject: AArch64 arch_spin_unlock not signaling global event?
Message-ID: <CANz0V+6-yk9jWZ1y9zidKFJAhDof9qQR1uAHzsvhwswApMbxUA@mail.gmail.com>

Hiya,

I've noticed the AArch64 arch_spin_unlock is implemented with the
'stlr' instruction.

Shouldn't that be followed by a 'sev'?

The AArch64 ISA doc says this about 'sev' - "A memory transaction
which clears a processor?s global exclusive monitor also implicitly
generates an event for that processor, as held in the Event register
and used by the WFE instruction."

...but 'stlr' is not an exclusive function. So an 'stlr' would not
generate the event. This means that a arch_spin_lock sitting inside
the 'wfe' would not unblock.

I ran into this doing some kernel-less SMP experiments with the
Foundation Model, where two cpus would play 'ping-pong' acquiring the
same lock and releasing it after a delay, letting the other CPU
acquire it. In the case of the Linux kernel, the core running
arch_spin_unlock likely manipulates a dozen other locks afterwards or
performs other activities which result in a global event (clrex, wfe),
or the other core gets an event because of an interrupt (or timer used
as wfe source). This is why I'm guessing no one has run into this yet.

Cheers,
-- 
A


From sergei.shtylyov at cogentembedded.com  Wed Jul 31 16:21:08 2013
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 01 Aug 2013 00:21:08 +0400
Subject: [PATCH 1/10] ARM: dts: mxs: move 'compatible' property to
 beginning of node and do some whitespace cleanups
In-Reply-To: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
References: <1375281480-25775-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <51F971B4.1050605@cogentembedded.com>

Hello.

On 07/31/2013 06:37 PM, Lothar Wa?mann wrote:

> Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
> ---
>   arch/arm/boot/dts/imx28.dtsi |    5 ++---
>   1 files changed, 2 insertions(+), 3 deletions(-)

> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 47fc5ef..0360acc 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -731,9 +731,9 @@
>   			};
>
>   			dcp at 80028000 {
> +				compatible = "fsl-dcp";

    Hm, why not the usual "fsl,dcp", where "fsl" is Freescale's stock ticker?

>   				reg = <0x80028000 0x2000>;
>   				interrupts = <52 53 54>;
> -				compatible = "fsl-dcp";
>   			};

WBR, Sergei




From jonsmirl at gmail.com  Wed Jul 31 16:37:36 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Wed, 31 Jul 2013 16:37:36 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130731201457.GA24642@n2100.arm.linux.org.uk>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1999586.84BnWE5EUh@thinkpad> <20130731191209.GA8027@netboy>
 <1409617.9untvfnOTJ@flatron> <20130731200017.GC8027@netboy>
 <20130731201457.GA24642@n2100.arm.linux.org.uk>
Message-ID: <CAKON4Ow7rE9cDj_tS7kmYN4incM+ay=BK96q-ph2JxYH3xiQzg@mail.gmail.com>

On Wed, Jul 31, 2013 at 4:14 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Wed, Jul 31, 2013 at 10:00:17PM +0200, Richard Cochran wrote:
>> On Wed, Jul 31, 2013 at 09:29:35PM +0200, Tomasz Figa wrote:
>> >
>> > I showed you two example solutions that could handle this use case without
>> > stable binding ABI, just to prove that b) is not the only option (even if
>> > it's the best one, which I continue to agree on, don't get me wrong).
>>
>> You only showed *one* solution (b) that satisfies the use case. The
>> use case was:
>>
>>    User acquires a machine running ARM Linux version 3.x, with u-boot
>>    and dtb in a read only flash partition. The board boots and works just
>>                 ^^^^^^^^^^^^^^^^^^^^^^^^^
>>    fine. However, for his application, the user requires a new kernel
>>    feature that appeared in version 3.y where y > x. He compiles the new
>>    kernel, and it also works.
>>
>> But you suggested:
>>
>>  a) using DT as direct replacement for board files - this means that you
>>     are free to say that DTSes are strictly coupled with kernel version
>>     and you are free to modify the bindings - see the analogy to board
>>     files, where you could modify the platform data structures and could
>>     not directly copy board file from one kernel version to another,
>>
>> In the use case, the kernel is upgraded, but not the DTB. So this
>> solution makes no sense.
>
> That's also crap for another reason.  DT on the whole is _supposed_ to
> describe what the hardware is, and how it is wired up in a WELL DEFINED
> and STABLE manner.  Unfortunately, there's a *BIG* mistake that was made
> - having this /chosen node in DT which gets used for "software"
> configuration - eg, the command line and so forth.
>
> That was a mistake because it means that the DT isn't purely a
> description of the hardware.  Such stuff should have been left in ATAGs,
> and DT should have been placed into its own ATAG entry.  There would
> not have been any conflict between ATAGs and DT, because ATAGs generally
> don't deal with hardware configuration - the only real bit of hardware
> configuration conveyed via ATAGs is the location of memory and size of
> memory.
>
> However, if we go back to the idea that DT is supposed to describe the
> hardware, _and_ that the way to describe that hardware is well defined
> and _stable_ (as it should be) then there should be no reason what so
> ever that your old DT blob should not continue working in later kernels.
> If it doesn't, then the contract that DT promised when we first moved
> over to using DT has been _broken_.

Suppose your DT predates PINCTRL and the CPU needs the pins set to
function.  But setting the pins up is a board specific function. How
is this going to get implemented in a generic kernel that doesn't have
any board specific code in it?

I would propose that we only need to worry about DTs that got put into
boot loaders and not worry about ones that were only used when
appended to a kernel.

For those deployed bootloader based DTs we'd use a quirk system to
catch them at early boot time and add in the missing PINCTRL
information.  The function of this quirk system is to update deployed
DTs with the needed information to allow a completely generic kernel
to run.

Now we can have a very clean generic kernel with all of the board
specific fixups localized to a single spot - the quirk for those
deployed DTs. And hopefully new boards won't need any quirks.

>
> Quite frankly, the fact that this discussion has gone on soo far, and
> everyone is saying that the existing DT descriptions to date (for what,
> two years) are all unstable is really extremely sad.
>
> I've stated in my previous postings what I think very clearly - and it
> comes down to the fact that every DT binding which is in existence in
> a released kernel _is_ by that very nature a stable binding.  If it
> wasn't a stable binding, it should have been clearly marked as such
> and been subject to CONFIG_EXPERIMENTAL (when it existed) or
> CONFIG_STAGING or similar.
>
> We even went as far as creating documentation for the bindings - directly
> along side the documentation for PPC bindings, with no distinction.
>
> Given all that, it's down right insulting to those who have been using
> ARM kernels to now start off a discussion about making these things
> stable.  Those people who think that these bindings are not stable need
> to wake up to reality - we have USERS of this stuff over the last two
> years.  It's found its way into products.  If we're going to keep this
> stuff "unstable" then we are actively _hurting_ our users.
>
> I'll say it again: if a binding has been in a final kernel, it is by
> definition a *stable* binding, and compatibility with that binding
> *must* be maintained.
>
> If we're not going to do that, then we owe all the users of the ARM
> kernel a VERY BIG apology.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Jon Smirl
jonsmirl at gmail.com


From stern at rowland.harvard.edu  Wed Jul 31 16:44:43 2013
From: stern at rowland.harvard.edu (Alan Stern)
Date: Wed, 31 Jul 2013 16:44:43 -0400 (EDT)
Subject: [PATCH v2 6/8] usb: host: ohci-s3c2410 Use
 clk_prepare_enable/clk_disable_unprepare
In-Reply-To: <6370497.apKG6kIlfT@flatron>
Message-ID: <Pine.LNX.4.44L0.1307311643110.1546-100000@iolanthe.rowland.org>

On Wed, 31 Jul 2013, Tomasz Figa wrote:

> Alan, Greg,
> 
> On Tuesday 23 of July 2013 01:49:23 Tomasz Figa wrote:
> > This patch modifies the ohci-s3c2410 driver to prepare and unprepare
> > clocks in addition to enabling and disabling, since it is required
> > by common clock framework.
> > 
> > Signed-off-by: Tomasz Figa <tomasz.figa at gmail.com>
> > ---
> >  drivers/usb/host/ohci-s3c2410.c | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/usb/host/ohci-s3c2410.c
> > b/drivers/usb/host/ohci-s3c2410.c index e125770..db096bf 100644
> > --- a/drivers/usb/host/ohci-s3c2410.c
> > +++ b/drivers/usb/host/ohci-s3c2410.c
> > @@ -47,10 +47,10 @@ static void s3c2410_start_hc(struct platform_device
> > *dev, struct usb_hcd *hcd)
> > 
> >  	dev_dbg(&dev->dev, "s3c2410_start_hc:\n");
> > 
> > -	clk_enable(usb_clk);
> > +	clk_prepare_enable(usb_clk);
> >  	mdelay(2);			/* let the bus clock stabilise */
> > 
> > -	clk_enable(clk);
> > +	clk_prepare_enable(clk);
> > 
> >  	if (info != NULL) {
> >  		info->hcd	= hcd;
> > @@ -75,8 +75,8 @@ static void s3c2410_stop_hc(struct platform_device
> > *dev) (info->enable_oc)(info, 0);
> >  	}
> > 
> > -	clk_disable(clk);
> > -	clk_disable(usb_clk);
> > +	clk_disable_unprepare(clk);
> > +	clk_disable_unprepare(usb_clk);
> >  }
> > 
> >  /* ohci_s3c2410_hub_status_data
> 
> Any chance to get your ack on this?

Sorry, this must have slipped past.  It's fine with me.

Alan Stern



From sboyd at codeaurora.org  Wed Jul 31 16:45:47 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 13:45:47 -0700
Subject: [PATCH] clocksource: em_sti: Adjust clock event rating to fix
 SMP broadcast
In-Reply-To: <CANqRtoR0Wwctor1mpM+8nuC0_pZsPHUSShPuZFX4FVtoVKEuNw@mail.gmail.com>
References: <1375251940-7809-1-git-send-email-horms+renesas@verge.net.au>
 <51F94A35.2020907@codeaurora.org>
 <CANqRtoR0Wwctor1mpM+8nuC0_pZsPHUSShPuZFX4FVtoVKEuNw@mail.gmail.com>
Message-ID: <51F9777B.2080500@codeaurora.org>

On 07/31/13 12:17, Magnus Damm wrote:
> Hi Stephen,
>
> On Thu, Aug 1, 2013 at 2:32 AM, Stephen Boyd <sboyd at codeaurora.org> wrote:
>> On 07/30/13 23:25, Simon Horman wrote:
>>> From: Magnus Damm <damm at opensource.se>
>>>
>>> Update the STI rating from 200 to 80 to fix SMP operation with
>>> the ARM broadcast timer. This breakage was introduced by:
>>>
>>> f7db706 ARM: 7674/1: smp: Avoid dummy clockevent being preferred over real hardware clock-event
>>>
>>> Without this fix SMP operation is broken on EMEV2 since no
>>> broadcast timer interrupts trigger on the secondary CPU cores.
>>>
>>> Signed-off-by: Magnus Damm <damm at opensource.se>
>>> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
>>> ---
>> This looks suspicious. Are you're purposefully deflating the rating so
>> that the STI timer fills in the broadcast position? Why not make the STI
>> cpumask be all possible CPUs? Presumably the interrupt can target all
>> CPUs since it isn't a per-cpu interrupt and doing this would cause the
>> STI to fill in the broadcast slot, leaving the per-cpu dummys in the
>> tick position.
> While letting the timer broadcast to all CPUs sounds interesting the
> STI driver has so far only been used to drive a single CPU core. This
> used to work well for us but has since some time unfortunately been
> broken. I agree that it may be suboptimal with a single timer like STI
> and using IPI for broadcast, but for more efficient SMP we already
> have TWD or arch timer.

I think there is some confusion. The mask field says what CPUs the timer
can possibly interrupt and for non-percpu interrupts this should be all
possible CPUs (unless we're talking clusters, etc. but I don't think we
are). Can you please give the output of /proc/timer_list or confirm that
the STI is your broadcast source? If so you should probably be marking
the cpumask for all possible CPUs so that the clockevent core knows to
prefer this clockevent for the broadcast source and not a per-cpu
source. Then you can leave the rating as is.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From swarren at wwwdotorg.org  Wed Jul 31 16:47:12 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 Jul 2013 14:47:12 -0600
Subject: Defining schemas for Device Tree
In-Reply-To: <CAKON4OzFdZhX0Kzu_6KiimD=KxDr6EM13zUH3GGE=hHaYx=m=Q@mail.gmail.com>
References: <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4Oy6+7ZpAG5emAm_c62t=o_LXM7PcbK-z5YL_qx=r0AKqQ@mail.gmail.com>
 <1706112.Xn49tiCSKF@thinkpad>
 <CAKON4OwNrhmvnznyeD-igtZ5nsm7atUZoa0RJttN5kmwKubaDg@mail.gmail.com>
 <20130730102511.GM9858@sirena.org.uk>
 <CAKON4OxSr13VPJkwkvuF91BwFXfQ6fkAuVeEsiA=JK3cuzmavQ@mail.gmail.com>
 <51F7F596.6020503@wwwdotorg.org>
 <CAKON4OykPqYA8+ZGxjiX00Ut+iM9hqiXr5D9KEZF3PVxoqiM1g@mail.gmail.com>
 <20130730205716.GZ9858@sirena.org.uk>
 <CAKON4Ox7-6Jf0ce64Wqr5E49KS+9E135mqc_iG-PWQ7r8bzWHA@mail.gmail.com>
 <20130730230331.GC9858@sirena.org.uk>
 <CAKON4OzFdZhX0Kzu_6KiimD=KxDr6EM13zUH3GGE=hHaYx=m=Q@mail.gmail.com>
Message-ID: <51F977D0.7050200@wwwdotorg.org>

On 07/30/2013 05:23 PM, jonsmirl at gmail.com wrote:
> On Tue, Jul 30, 2013 at 7:03 PM, Mark Brown <broonie at kernel.org> wrote:
>> On Tue, Jul 30, 2013 at 06:19:08PM -0400, jonsmirl at gmail.com wrote:
>>
>>> FDT is versioned and PowerPC docs say that multiple versions have been
>>> released.  If we find enough flaws we could do a new release then use
>>> the quirks scheme to read the older versions.
>>
>> That does involve updating everything that wants to understand FDTs in
>> the new FDT format version though.  I'm not sure that's going to be
>> greeted with universal enthusiasm.
> 
> Shipped hardware containing FDTs would keep the version they shipped
> with. That's the point of making this  a stable ABI. The Linux quirk
> code would convert the older format to the new format at boot time.
> 
> So to change this you need to:
> 1) change dtc to produce the new version
> 2) adjust the kernel code to understand the new version
> 3) adjust the quirk code to convert the known set of older firmware
> based FDTs into the new format. For the simple string case the strings
> would be turned into indirect pointers instead of being in-line.

There's one issue issue with the quirk/conversion layer in the kernel.

Various combinations are supposed to work:

1) The "current" kernel with the "current" DTB. I think everyone agrees
on that much:-)

2) Using an old DTB with a new kernel. This could be handled by having
stable DT bindings, and/or by having a quirk/conversion layer in the
kernel to convert old DTBs into whatever format the new kernel expects.

3) Using a new DTB with a old kernel. Rob Herring raised the point that
a firmware update (which might include updating the DTB the firmware
passes to the kernel) should not make the kernel you have installed in
the filesystem fail to boot.

I'm assuming that if the quirk/conversion layer you're championing were
the solution chosen for (2), then at least some of the time, people
would start using the new DT binding when writing new DTs, or modifying
existing DTs. That would break point (3) above, since the new DT would
no longer work with the old kernel.

I think the only way to satisfy all three points above is to have truly
stable backwards-compatible bindings, without relying on any in-kernel
conversion layer.


From daniel.lezcano at linaro.org  Wed Jul 31 16:49:06 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 31 Jul 2013 22:49:06 +0200
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <829dbb20-0f14-4a3b-8da9-1f7b1b5b8b59@DB8EHSMHS005.ehs.local>
References: <51E72DCA.9070500@codeaurora.org>
 <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
 <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
 <51F77D93.4030505@linaro.org>
 <829dbb20-0f14-4a3b-8da9-1f7b1b5b8b59@DB8EHSMHS005.ehs.local>
Message-ID: <51F97842.6050200@linaro.org>

On 07/31/2013 12:34 AM, S?ren Brinkmann wrote:
> On Tue, Jul 30, 2013 at 10:47:15AM +0200, Daniel Lezcano wrote:
>> On 07/30/2013 02:03 AM, S?ren Brinkmann wrote:
>>> Hi Daniel,
>>>
>>> On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
>>> (snip)
>>>>
>>>> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
>>>> timer will be stopped when entering to the idle state. In this case, the
>>>> cpuidle framework will call clockevents_notify(ENTER) and switches to a
>>>> broadcast timer and will call clockevents_notify(EXIT) when exiting the
>>>> idle state, switching the local timer back in use.
>>>
>>> I've been thinking about this, trying to understand how this makes my
>>> boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
>>> would make the timer core switch to a broadcast device even though it
>>> wouldn't be necessary. But shouldn't it still work? It sounds like we do
>>> something useless, but nothing wrong in a sense that it should result in
>>> breakage. I guess I'm missing something obvious. This timer system will
>>> always remain a mystery to me.
>>>
>>> Actually this more or less leads to the question: What is this
>>> 'broadcast timer'. I guess that is some clockevent device which is
>>> common to all cores? (that would be the cadence_ttc for Zynq). Is the
>>> hang pointing to some issue with that driver?
>>
>> If you look at the /proc/timer_list, which timer is used for broadcasting ?
> 
> So, the correct run results (full output attached).
> 
> The vanilla kernel uses the twd timers as local timers and the TTC as
> broadcast device:
> 	Tick Device: mode:     1                                                         
> 	Broadcast device  
> 	Clock Event Device: ttc_clockevent
> 
> When I remove the offending CPUIDLE flag and add the DT fragment to
> enable the global timer, the twd timers are still used as local timers
> and the broadcast device is the global timer:
> 	Tick Device: mode:     1                                                         
> 	Broadcast device                                                                 
> 	Clock Event Device: arm_global_timer
> 
> Again, since boot hangs in the actually broken case, I don't see way to
> obtain this information for that case.

Can't you use the maxcpus=1 option to ensure the system to boot up ?


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From linux at arm.linux.org.uk  Wed Jul 31 16:48:18 2013
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 31 Jul 2013 21:48:18 +0100
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have
 people interested in device tree janitoring / cleanup?]
In-Reply-To: <CAKON4Ow7rE9cDj_tS7kmYN4incM+ay=BK96q-ph2JxYH3xiQzg@mail.gmail.com>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1999586.84BnWE5EUh@thinkpad> <20130731191209.GA8027@netboy>
 <1409617.9untvfnOTJ@flatron> <20130731200017.GC8027@netboy>
 <20130731201457.GA24642@n2100.arm.linux.org.uk>
 <CAKON4Ow7rE9cDj_tS7kmYN4incM+ay=BK96q-ph2JxYH3xiQzg@mail.gmail.com>
Message-ID: <20130731204817.GC24642@n2100.arm.linux.org.uk>

On Wed, Jul 31, 2013 at 04:37:36PM -0400, jonsmirl at gmail.com wrote:
> On Wed, Jul 31, 2013 at 4:14 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > However, if we go back to the idea that DT is supposed to describe the
> > hardware, _and_ that the way to describe that hardware is well defined
> > and _stable_ (as it should be) then there should be no reason what so
> > ever that your old DT blob should not continue working in later kernels.
> > If it doesn't, then the contract that DT promised when we first moved
> > over to using DT has been _broken_.
> 
> Suppose your DT predates PINCTRL and the CPU needs the pins set to
> function.  But setting the pins up is a board specific function. How
> is this going to get implemented in a generic kernel that doesn't have
> any board specific code in it?
> 
> I would propose that we only need to worry about DTs that got put into
> boot loaders and not worry about ones that were only used when
> appended to a kernel.

That is - again - our mistake.  We should have made it clear from the
start that the use of an _appended_ DT, or a DT provided with the kernel
being booted was more or less mandatory for the time being.  We actually
did exactly the opposite - we advertised the appended DT as a stop-gap
measure just to allow a DT kernel to be booted with a boot loader which
didn't support DT.

That in itself _encouraged_ boot loader support for DT on ARM (which in
itself is not a bad thing) but also leads people down the path of
potentially separating the DT from the kernel.

Had we encouraged the use of an appended DT instead, but still encouraged
boot loaders to update, and also made a clear statement that DT is
unstable (which everyone can see - for example by making our DT stuff
depend on CONFIG_EXPERIMENTAL when it existed) then everyone would have
been clear about its status.

The fact that we did not - the fact that we ignored this process means
that it is _our_ problem that people like Richard are blowing up such a
storm over this.  We need to admit that we got it wrong, and commit to
doing it the right way in future.  What that means is starting off today
with a commitment to keep as much of the stuff which works today working
_tomorrow_, and the day after, and so forth.


From jgunthorpe at obsidianresearch.com  Wed Jul 31 16:50:34 2013
From: jgunthorpe at obsidianresearch.com (Jason Gunthorpe)
Date: Wed, 31 Jul 2013 14:50:34 -0600
Subject: pci-mvebu driver on km_kirkwood
In-Reply-To: <20130731110045.2dc84981@skate>
References: <51DD88A4.1030506@keymile.com> <20130731100359.3e789236@skate>
 <51F8CA44.4080802@keymile.com> <20130731110045.2dc84981@skate>
Message-ID: <20130731205034.GA17615@obsidianresearch.com>

On Wed, Jul 31, 2013 at 11:00:45AM +0200, Thomas Petazzoni wrote:

> > Actually, the main reason for trying to use this driver was because I 
> > wanted to model a PCIe *device* within the device tree, so to expose its 
> > GPIOs and IRQs to be referenced (through phandles) from other device 
> > tree nodes. The way I understand it, turns out this is not the way to 
> > go, as PCI/PCIe are essentially enumerated busses, so you're not 
> > supposed to -and it's not a trivial task to- put any information about 
> > real devices within the device tree.
> > Do you have any suggestion about that?
> 
> Indeed, PCI/PCIe devices are enumerated dynamically, so they are not
> listed in the Device Tree, so there's no way to "attach" more
> information to them.
> 
> Device Tree people, any suggestion about the above question?

No, that isn't true.

Device tree can include the discovered PCI devices, you have to use
the special reg encoding and all that weirdness, but it does work. The
of_node will be attached to the struct pci device automatically.

On server/etc DT platforms the firmware will do PCI discovery and
resource assignment then dump all those results into DT for the OS to
reference.

This is a major reason why we wanted to see the standard PCI DT be
used for Marvell/etc, the existing infrastructure for this is
valuable.

AFAIK, Thierry has tested this on tegra, and I am doing it on Kirkwood
(though not yet with the new driver).

It is useful for exactly the reason stated - you can describe GPIOs,
I2C busses, etc, etc in DT and then upon load of the PCI driver engage
the DT code to populate and connect all that downstream
infrastructure.

I understand someday DT overlays might be a better alternative for
this, but AFAIK today in mainline this is what we have..

That said, the guideline to not include discoverable information in DT
is a good guideline for upstream DTs..

Jason


From vivien.didelot at savoirfairelinux.com  Wed Jul 31 16:57:11 2013
From: vivien.didelot at savoirfairelinux.com (Vivien Didelot)
Date: Wed, 31 Jul 2013 16:57:11 -0400
Subject: [PATCH] gpio: (gpio-pca953x) move header to linux/platform_data/
Message-ID: <1375304231-27281-1-git-send-email-vivien.didelot@savoirfairelinux.com>

This patch moves the pca953x.h header from include/linux/i2c to
include/linux/platform_data and updates existing support accordingly.

Signed-off-by: Vivien Didelot <vivien.didelot at savoirfairelinux.com>
---
 arch/arm/mach-at91/board-snapper9260.c      |  2 +-
 arch/arm/mach-davinci/board-da850-evm.c     |  2 +-
 arch/arm/mach-ep93xx/vision_ep9307.c        |  2 +-
 arch/arm/mach-imx/mach-imx27_visstrim_m10.c |  2 +-
 arch/arm/mach-imx/mach-mxt_td60.c           |  2 +-
 arch/arm/mach-ks8695/board-acs5k.c          |  2 +-
 arch/arm/mach-mmp/ttc_dkb.c                 |  2 +-
 arch/arm/mach-omap2/board-am3517evm.c       |  2 +-
 arch/arm/mach-pxa/cm-x300.c                 |  2 +-
 arch/arm/mach-pxa/em-x270.c                 |  2 +-
 arch/arm/mach-pxa/pcm990-baseboard.c        |  2 +-
 arch/arm/mach-pxa/spitz.c                   |  2 +-
 arch/arm/mach-pxa/zeus.c                    |  2 +-
 arch/arm/mach-pxa/zylonite_pxa300.c         |  2 +-
 arch/arm/mach-s3c64xx/mach-crag6410.c       |  2 +-
 arch/x86/platform/mrst/mrst.c               |  2 +-
 drivers/gpio/gpio-pca953x.c                 |  2 +-
 include/linux/i2c/pca953x.h                 | 30 -----------------------------
 include/linux/platform_data/pca953x.h       | 30 +++++++++++++++++++++++++++++
 19 files changed, 47 insertions(+), 47 deletions(-)
 delete mode 100644 include/linux/i2c/pca953x.h
 create mode 100644 include/linux/platform_data/pca953x.h

diff --git a/arch/arm/mach-at91/board-snapper9260.c b/arch/arm/mach-at91/board-snapper9260.c
index 3aaa978..f1d49e9 100644
--- a/arch/arm/mach-at91/board-snapper9260.c
+++ b/arch/arm/mach-at91/board-snapper9260.c
@@ -26,7 +26,7 @@
 #include <linux/gpio.h>
 #include <linux/platform_device.h>
 #include <linux/spi/spi.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index bea6793..af6dafb 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -19,7 +19,7 @@
 #include <linux/kernel.h>
 #include <linux/i2c.h>
 #include <linux/i2c/at24.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 #include <linux/input.h>
 #include <linux/input/tps6507x-ts.h>
 #include <linux/mfd/tps6507x.h>
diff --git a/arch/arm/mach-ep93xx/vision_ep9307.c b/arch/arm/mach-ep93xx/vision_ep9307.c
index 605956f..64f2e50 100644
--- a/arch/arm/mach-ep93xx/vision_ep9307.c
+++ b/arch/arm/mach-ep93xx/vision_ep9307.c
@@ -23,7 +23,7 @@
 #include <linux/mtd/partitions.h>
 #include <linux/i2c.h>
 #include <linux/i2c-gpio.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/flash.h>
 #include <linux/spi/mmc_spi.h>
diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index 29ac8ee6..97f9c62 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -26,7 +26,7 @@
 #include <linux/platform_device.h>
 #include <linux/mtd/physmap.h>
 #include <linux/i2c.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 #include <linux/input.h>
 #include <linux/gpio.h>
 #include <linux/delay.h>
diff --git a/arch/arm/mach-imx/mach-mxt_td60.c b/arch/arm/mach-imx/mach-mxt_td60.c
index a27faab..c918940 100644
--- a/arch/arm/mach-imx/mach-mxt_td60.c
+++ b/arch/arm/mach-imx/mach-mxt_td60.c
@@ -26,7 +26,7 @@
 #include <asm/mach/time.h>
 #include <asm/mach/map.h>
 #include <linux/gpio.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 
 #include "common.h"
 #include "devices-imx27.h"
diff --git a/arch/arm/mach-ks8695/board-acs5k.c b/arch/arm/mach-ks8695/board-acs5k.c
index 456d638..9f9c044 100644
--- a/arch/arm/mach-ks8695/board-acs5k.c
+++ b/arch/arm/mach-ks8695/board-acs5k.c
@@ -20,7 +20,7 @@
 #include <linux/i2c.h>
 #include <linux/i2c-algo-bit.h>
 #include <linux/i2c-gpio.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/map.h>
diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
index 8483906..7022329 100644
--- a/arch/arm/mach-mmp/ttc_dkb.c
+++ b/arch/arm/mach-mmp/ttc_dkb.c
@@ -15,7 +15,7 @@
 #include <linux/mtd/partitions.h>
 #include <linux/mtd/onenand.h>
 #include <linux/interrupt.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 #include <linux/gpio.h>
 #include <linux/gpio-pxa.h>
 #include <linux/mfd/88pm860x.h>
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index d63f14b..c7196a6 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -21,7 +21,7 @@
 #include <linux/clk.h>
 #include <linux/platform_device.h>
 #include <linux/gpio.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 #include <linux/can/platform/ti_hecc.h>
 #include <linux/davinci_emac.h>
 #include <linux/mmc/host.h>
diff --git a/arch/arm/mach-pxa/cm-x300.c b/arch/arm/mach-pxa/cm-x300.c
index 8091aac..f942349 100644
--- a/arch/arm/mach-pxa/cm-x300.c
+++ b/arch/arm/mach-pxa/cm-x300.c
@@ -29,7 +29,7 @@
 #include <linux/pwm_backlight.h>
 
 #include <linux/i2c.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 #include <linux/i2c/pxa-i2c.h>
 
 #include <linux/mfd/da903x.h>
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index 3a3362f..8eb4e23 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -30,7 +30,7 @@
 #include <linux/power_supply.h>
 #include <linux/apm-emulation.h>
 #include <linux/i2c.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 #include <linux/i2c/pxa-i2c.h>
 #include <linux/regulator/userspace-consumer.h>
 
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c b/arch/arm/mach-pxa/pcm990-baseboard.c
index 13e5b00..3133ba8 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -408,7 +408,7 @@ struct pxacamera_platform_data pcm990_pxacamera_platform_data = {
 	.mclk_10khz = 1000,
 };
 
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 
 static struct pca953x_platform_data pca9536_data = {
 	.gpio_base	= PXA_NR_BUILTIN_GPIO,
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 4c29173..0b11c1a 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -20,7 +20,7 @@
 #include <linux/leds.h>
 #include <linux/i2c.h>
 #include <linux/i2c/pxa-i2c.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/ads7846.h>
 #include <linux/spi/corgi_lcd.h>
diff --git a/arch/arm/mach-pxa/zeus.c b/arch/arm/mach-pxa/zeus.c
index f5d4364..126e4a8 100644
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -26,7 +26,7 @@
 #include <linux/mtd/physmap.h>
 #include <linux/i2c.h>
 #include <linux/i2c/pxa-i2c.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 #include <linux/apm-emulation.h>
 #include <linux/can/platform/mcp251x.h>
 
diff --git a/arch/arm/mach-pxa/zylonite_pxa300.c b/arch/arm/mach-pxa/zylonite_pxa300.c
index 86e59c0..869bce7 100644
--- a/arch/arm/mach-pxa/zylonite_pxa300.c
+++ b/arch/arm/mach-pxa/zylonite_pxa300.c
@@ -18,7 +18,7 @@
 #include <linux/init.h>
 #include <linux/i2c.h>
 #include <linux/i2c/pxa-i2c.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 #include <linux/gpio.h>
 
 #include <mach/pxa300.h>
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 8ad88ac..007fc53 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -30,7 +30,7 @@
 #include <linux/basic_mmio_gpio.h>
 #include <linux/spi/spi.h>
 
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 #include <linux/platform_data/s3c-hsotg.h>
 
 #include <video/platform_lcd.h>
diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index 47fe66f..3ca5957 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -20,7 +20,7 @@
 #include <linux/intel_pmic_gpio.h>
 #include <linux/spi/spi.h>
 #include <linux/i2c.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 #include <linux/gpio_keys.h>
 #include <linux/input.h>
 #include <linux/platform_device.h>
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 426c51d..8804aec 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -18,7 +18,7 @@
 #include <linux/irq.h>
 #include <linux/irqdomain.h>
 #include <linux/i2c.h>
-#include <linux/i2c/pca953x.h>
+#include <linux/platform_data/pca953x.h>
 #include <linux/slab.h>
 #ifdef CONFIG_OF_GPIO
 #include <linux/of_platform.h>
diff --git a/include/linux/i2c/pca953x.h b/include/linux/i2c/pca953x.h
deleted file mode 100644
index 3c98dd4..0000000
--- a/include/linux/i2c/pca953x.h
+++ /dev/null
@@ -1,30 +0,0 @@
-#ifndef _LINUX_PCA953X_H
-#define _LINUX_PCA953X_H
-
-#include <linux/types.h>
-#include <linux/i2c.h>
-
-/* platform data for the PCA9539 16-bit I/O expander driver */
-
-struct pca953x_platform_data {
-	/* number of the first GPIO */
-	unsigned	gpio_base;
-
-	/* initial polarity inversion setting */
-	u32		invert;
-
-	/* interrupt base */
-	int		irq_base;
-
-	void		*context;	/* param to setup/teardown */
-
-	int		(*setup)(struct i2c_client *client,
-				unsigned gpio, unsigned ngpio,
-				void *context);
-	int		(*teardown)(struct i2c_client *client,
-				unsigned gpio, unsigned ngpio,
-				void *context);
-	const char	*const *names;
-};
-
-#endif /* _LINUX_PCA953X_H */
diff --git a/include/linux/platform_data/pca953x.h b/include/linux/platform_data/pca953x.h
new file mode 100644
index 0000000..3c98dd4
--- /dev/null
+++ b/include/linux/platform_data/pca953x.h
@@ -0,0 +1,30 @@
+#ifndef _LINUX_PCA953X_H
+#define _LINUX_PCA953X_H
+
+#include <linux/types.h>
+#include <linux/i2c.h>
+
+/* platform data for the PCA9539 16-bit I/O expander driver */
+
+struct pca953x_platform_data {
+	/* number of the first GPIO */
+	unsigned	gpio_base;
+
+	/* initial polarity inversion setting */
+	u32		invert;
+
+	/* interrupt base */
+	int		irq_base;
+
+	void		*context;	/* param to setup/teardown */
+
+	int		(*setup)(struct i2c_client *client,
+				unsigned gpio, unsigned ngpio,
+				void *context);
+	int		(*teardown)(struct i2c_client *client,
+				unsigned gpio, unsigned ngpio,
+				void *context);
+	const char	*const *names;
+};
+
+#endif /* _LINUX_PCA953X_H */
-- 
1.8.3.4



From soren.brinkmann at xilinx.com  Wed Jul 31 16:58:52 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Wed, 31 Jul 2013 13:58:52 -0700
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <51F97842.6050200@linaro.org>
References: <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
 <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
 <51F77D93.4030505@linaro.org> <51F97842.6050200@linaro.org>
Message-ID: <068436c6-ff98-428f-8875-bb1c6f86466b@TX2EHSMHS008.ehs.local>

On Wed, Jul 31, 2013 at 10:49:06PM +0200, Daniel Lezcano wrote:
> On 07/31/2013 12:34 AM, S?ren Brinkmann wrote:
> > On Tue, Jul 30, 2013 at 10:47:15AM +0200, Daniel Lezcano wrote:
> >> On 07/30/2013 02:03 AM, S?ren Brinkmann wrote:
> >>> Hi Daniel,
> >>>
> >>> On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
> >>> (snip)
> >>>>
> >>>> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
> >>>> timer will be stopped when entering to the idle state. In this case, the
> >>>> cpuidle framework will call clockevents_notify(ENTER) and switches to a
> >>>> broadcast timer and will call clockevents_notify(EXIT) when exiting the
> >>>> idle state, switching the local timer back in use.
> >>>
> >>> I've been thinking about this, trying to understand how this makes my
> >>> boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
> >>> would make the timer core switch to a broadcast device even though it
> >>> wouldn't be necessary. But shouldn't it still work? It sounds like we do
> >>> something useless, but nothing wrong in a sense that it should result in
> >>> breakage. I guess I'm missing something obvious. This timer system will
> >>> always remain a mystery to me.
> >>>
> >>> Actually this more or less leads to the question: What is this
> >>> 'broadcast timer'. I guess that is some clockevent device which is
> >>> common to all cores? (that would be the cadence_ttc for Zynq). Is the
> >>> hang pointing to some issue with that driver?
> >>
> >> If you look at the /proc/timer_list, which timer is used for broadcasting ?
> > 
> > So, the correct run results (full output attached).
> > 
> > The vanilla kernel uses the twd timers as local timers and the TTC as
> > broadcast device:
> > 	Tick Device: mode:     1                                                         
> > 	Broadcast device  
> > 	Clock Event Device: ttc_clockevent
> > 
> > When I remove the offending CPUIDLE flag and add the DT fragment to
> > enable the global timer, the twd timers are still used as local timers
> > and the broadcast device is the global timer:
> > 	Tick Device: mode:     1                                                         
> > 	Broadcast device                                                                 
> > 	Clock Event Device: arm_global_timer
> > 
> > Again, since boot hangs in the actually broken case, I don't see way to
> > obtain this information for that case.
> 
> Can't you use the maxcpus=1 option to ensure the system to boot up ?

Right, that works. I forgot about that option after you mentioned, that
it is most likely not that useful.

Anyway, this are those sysfs files with an unmodified cpuidle driver and
the gt enabled and having maxcpus=1 set.

/proc/timer_list:
	Tick Device: mode:     1
	Broadcast device
	Clock Event Device: arm_global_timer
	 max_delta_ns:   12884902005
	 min_delta_ns:   1000
	 mult:           715827876
	 shift:          31
	 mode:           3
	 next_event:     108080000000 nsecs
	 set_next_event: gt_clockevent_set_next_event
	 set_mode:       gt_clockevent_set_mode
	 event_handler:  tick_handle_oneshot_broadcast
	 retries:        0
	
	tick_broadcast_mask: 00000001
	tick_broadcast_oneshot_mask: 00000000
	
	Tick Device: mode:     1
	Per CPU device: 0
	Clock Event Device: local_timer
	 max_delta_ns:   12884902005
	 min_delta_ns:   1000
	 mult:           715827876
	 shift:          31
	 mode:           3
	 next_event:     106900000000 nsecs
	 set_next_event: twd_set_next_event
	 set_mode:       twd_set_mode
	 event_handler:  hrtimer_interrupt
	 retries:        0

# cat /proc/interrupts 
	           CPU0       
	 27:        252       GIC  27  gt
	 29:        626       GIC  29  twd
	 43:          0       GIC  43  ttc_clockevent
	 82:        410       GIC  82  xuartps
	IPI0:          0  CPU wakeup interrupts
	IPI1:          0  Timer broadcast interrupts
	IPI2:          0  Rescheduling interrupts
	IPI3:          0  Function call interrupts
	IPI4:          0  Single function call interrupts
	IPI5:          0  CPU stop interrupts
	Err:          0


	S?ren




From hartleys at visionengravers.com  Wed Jul 31 17:03:23 2013
From: hartleys at visionengravers.com (H Hartley Sweeten)
Date: Wed, 31 Jul 2013 16:03:23 -0500
Subject: [PATCH] gpio: (gpio-pca953x) move header to linux/platform_data/
In-Reply-To: <1375304231-27281-1-git-send-email-vivien.didelot@savoirfairelinux.com>
References: <1375304231-27281-1-git-send-email-vivien.didelot@savoirfairelinux.com>
Message-ID: <ADE657CA350FB648AAC2C43247A983F0021DAC5C27C5@AUSP01VMBX24.collaborationhost.net>

On Wednesday, July 31, 2013 1:57 PM, Vivien Didelot wrote:
>
> This patch moves the pca953x.h header from include/linux/i2c to
> include/linux/platform_data and updates existing support accordingly.
>
> Signed-off-by: Vivien Didelot <vivien.didelot at savoirfairelinux.com>
> ---

<snip>

arch/arm/mach-ep93xx/vision_ep9307.c        |  2 +-

For the ep93xx change:

Acked-by: H Hartley Sweeten <hsweeten at visionengravers.com>

Thanks


From rjw at sisk.pl  Wed Jul 31 17:17:36 2013
From: rjw at sisk.pl (Rafael J. Wysocki)
Date: Wed, 31 Jul 2013 23:17:36 +0200
Subject: [Announcement] Linux Plumbers ACPI/PM, PCI Microconference
In-Reply-To: <CAKocOOPOqqS80D23z6xTVSNYYYWZ7ACg9MtSMz_hTqVA3Duo0w@mail.gmail.com>
References: <CAL-B5D03ki8NHsM6EuESTH2K-Eh+XyFHNXPDYwgDq+oagDjtMQ@mail.gmail.com>
 <1755363.sGc8nLIQOW@vostro.rjw.lan>
 <CAKocOOPOqqS80D23z6xTVSNYYYWZ7ACg9MtSMz_hTqVA3Duo0w@mail.gmail.com>
Message-ID: <7183196.Ov6Qetq3lO@vostro.rjw.lan>

On Wednesday, July 31, 2013 10:35:05 AM Shuah Khan wrote:
> On Wed, Jul 31, 2013 at 5:40 AM, Rafael J. Wysocki <rjw at sisk.pl> wrote:
> > Hi All,
> >
> > The original announcement didn't go to linux-pm, so again:
> >
> > On Tuesday, July 16, 2013 08:21:26 PM Myron Stowe wrote:
> >> Linux Plumbers has approved an ACPI/PM, PCI microconference. The
> >> overview page is here:
> >>
> >> http://wiki.linuxplumbersconf.org/2013:pci_subsystem
> >>
> >> We would like to start receiving volunteers for presenting topics of
> >> interest.  There is a lot of activity in these subsystems so please
> >> respond by submitting presentation or discussion proposals that you
> >> would be willing to cover for consideration.  You should also feel
> >> free to submit ideas as proposals that others could cover.  The
> >> instructions for submitting ideas should be at:
> >>
> >> http://www.linuxplumbersconf.org/2013/submitting-topic/
> >
> > If anyone who's going to attend the Linux Plumbers Conf this year is interested
> > in any particular topic for discussion during the ACPI/PM+PCI uconf, please
> > submit a formal topic proposal at:
> >
> > http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/proposals/new
> >
> > If you submit a topic, that doesn't mean you'll be expected to present anything
> > (if accepted).  In fact, we are mostly interested in discussion topics and we'd
> > like to know what is important to people.
> >
> > That said if you have a (short) presentation to make, please submit it too.
> >
> > We'll appreciate all submissions very much.
> >
> 
> What I have mind is a discussion topic for the Mini-conference, which
> in-line with what you are asking for.
> I will add it to the web.

Thank you!



From daniel.lezcano at linaro.org  Wed Jul 31 17:08:51 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 31 Jul 2013 23:08:51 +0200
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <068436c6-ff98-428f-8875-bb1c6f86466b@TX2EHSMHS008.ehs.local>
References: <f5b76049-7e5b-4dd0-9863-19cfd1d599b9@TX2EHSMHS006.ehs.local>
 <51E7435B.3060605@codeaurora.org>
 <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
 <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
 <51F77D93.4030505@linaro.org> <51F97842.6050200@linaro.org>
 <068436c6-ff98-428f-8875-bb1c6f86466b@TX2EHSMHS008.ehs.local>
Message-ID: <51F97CE3.9030306@linaro.org>

On 07/31/2013 10:58 PM, S?ren Brinkmann wrote:
> On Wed, Jul 31, 2013 at 10:49:06PM +0200, Daniel Lezcano wrote:
>> On 07/31/2013 12:34 AM, S?ren Brinkmann wrote:
>>> On Tue, Jul 30, 2013 at 10:47:15AM +0200, Daniel Lezcano wrote:
>>>> On 07/30/2013 02:03 AM, S?ren Brinkmann wrote:
>>>>> Hi Daniel,
>>>>>
>>>>> On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
>>>>> (snip)
>>>>>>
>>>>>> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
>>>>>> timer will be stopped when entering to the idle state. In this case, the
>>>>>> cpuidle framework will call clockevents_notify(ENTER) and switches to a
>>>>>> broadcast timer and will call clockevents_notify(EXIT) when exiting the
>>>>>> idle state, switching the local timer back in use.
>>>>>
>>>>> I've been thinking about this, trying to understand how this makes my
>>>>> boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
>>>>> would make the timer core switch to a broadcast device even though it
>>>>> wouldn't be necessary. But shouldn't it still work? It sounds like we do
>>>>> something useless, but nothing wrong in a sense that it should result in
>>>>> breakage. I guess I'm missing something obvious. This timer system will
>>>>> always remain a mystery to me.
>>>>>
>>>>> Actually this more or less leads to the question: What is this
>>>>> 'broadcast timer'. I guess that is some clockevent device which is
>>>>> common to all cores? (that would be the cadence_ttc for Zynq). Is the
>>>>> hang pointing to some issue with that driver?
>>>>
>>>> If you look at the /proc/timer_list, which timer is used for broadcasting ?
>>>
>>> So, the correct run results (full output attached).
>>>
>>> The vanilla kernel uses the twd timers as local timers and the TTC as
>>> broadcast device:
>>> 	Tick Device: mode:     1                                                         
>>> 	Broadcast device  
>>> 	Clock Event Device: ttc_clockevent
>>>
>>> When I remove the offending CPUIDLE flag and add the DT fragment to
>>> enable the global timer, the twd timers are still used as local timers
>>> and the broadcast device is the global timer:
>>> 	Tick Device: mode:     1                                                         
>>> 	Broadcast device                                                                 
>>> 	Clock Event Device: arm_global_timer
>>>
>>> Again, since boot hangs in the actually broken case, I don't see way to
>>> obtain this information for that case.
>>
>> Can't you use the maxcpus=1 option to ensure the system to boot up ?
> 
> Right, that works. I forgot about that option after you mentioned, that
> it is most likely not that useful.
> 
> Anyway, this are those sysfs files with an unmodified cpuidle driver and
> the gt enabled and having maxcpus=1 set.
> 
> /proc/timer_list:
> 	Tick Device: mode:     1
> 	Broadcast device
> 	Clock Event Device: arm_global_timer
> 	 max_delta_ns:   12884902005
> 	 min_delta_ns:   1000
> 	 mult:           715827876
> 	 shift:          31
> 	 mode:           3

Here the mode is 3 (CLOCK_EVT_MODE_ONESHOT)

The previous timer_list output you gave me when removing the offending
cpuidle flag, it was 1 (CLOCK_EVT_MODE_SHUTDOWN).

Is it possible you try to get this output again right after onlining the
cpu1 in order to check if the broadcast device switches to SHUTDOWN ?

> 	 next_event:     108080000000 nsecs
> 	 set_next_event: gt_clockevent_set_next_event
> 	 set_mode:       gt_clockevent_set_mode
> 	 event_handler:  tick_handle_oneshot_broadcast
> 	 retries:        0
> 	
> 	tick_broadcast_mask: 00000001
> 	tick_broadcast_oneshot_mask: 00000000
> 	
> 	Tick Device: mode:     1
> 	Per CPU device: 0
> 	Clock Event Device: local_timer
> 	 max_delta_ns:   12884902005
> 	 min_delta_ns:   1000
> 	 mult:           715827876
> 	 shift:          31
> 	 mode:           3
> 	 next_event:     106900000000 nsecs
> 	 set_next_event: twd_set_next_event
> 	 set_mode:       twd_set_mode
> 	 event_handler:  hrtimer_interrupt
> 	 retries:        0
> 
> # cat /proc/interrupts 
> 	           CPU0       
> 	 27:        252       GIC  27  gt
> 	 29:        626       GIC  29  twd
> 	 43:          0       GIC  43  ttc_clockevent
> 	 82:        410       GIC  82  xuartps
> 	IPI0:          0  CPU wakeup interrupts
> 	IPI1:          0  Timer broadcast interrupts
> 	IPI2:          0  Rescheduling interrupts
> 	IPI3:          0  Function call interrupts
> 	IPI4:          0  Single function call interrupts
> 	IPI5:          0  CPU stop interrupts
> 	Err:          0
> 
> 
> 	S?ren
> 
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From cov at codeaurora.org  Wed Jul 31 17:25:17 2013
From: cov at codeaurora.org (Christopher Covington)
Date: Wed, 31 Jul 2013 17:25:17 -0400
Subject: AArch64 arch_spin_unlock not signaling global event?
In-Reply-To: <CANz0V+6-yk9jWZ1y9zidKFJAhDof9qQR1uAHzsvhwswApMbxUA@mail.gmail.com>
References: <CANz0V+6-yk9jWZ1y9zidKFJAhDof9qQR1uAHzsvhwswApMbxUA@mail.gmail.com>
Message-ID: <51F980BD.2050904@codeaurora.org>

Hi Andrei,

On 07/31/2013 04:19 PM, Andrei E. Warkentin wrote:
> Hiya,
> 
> I've noticed the AArch64 arch_spin_unlock is implemented with the
> 'stlr' instruction.
> 
> Shouldn't that be followed by a 'sev'?

Check the git log and go through silver to make sure you're looking at the
latest documentation. I believe the link from infocenter is stale.

Regards,
Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.


From jonsmirl at gmail.com  Wed Jul 31 17:26:47 2013
From: jonsmirl at gmail.com (jonsmirl at gmail.com)
Date: Wed, 31 Jul 2013 17:26:47 -0400
Subject: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people
 interested in device tree janitoring / cleanup?]
In-Reply-To: <20130731204817.GC24642@n2100.arm.linux.org.uk>
References: <20130725175702.GC22291@e106331-lin.cambridge.arm.com>
 <1999586.84BnWE5EUh@thinkpad> <20130731191209.GA8027@netboy>
 <1409617.9untvfnOTJ@flatron> <20130731200017.GC8027@netboy>
 <20130731201457.GA24642@n2100.arm.linux.org.uk>
 <CAKON4Ow7rE9cDj_tS7kmYN4incM+ay=BK96q-ph2JxYH3xiQzg@mail.gmail.com>
 <20130731204817.GC24642@n2100.arm.linux.org.uk>
Message-ID: <CAKON4Ozfe=endqnXWkcWR2HuJ489Otpcu2QsjB0DNg6jpRgG+Q@mail.gmail.com>

On Wed, Jul 31, 2013 at 4:48 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Wed, Jul 31, 2013 at 04:37:36PM -0400, jonsmirl at gmail.com wrote:
>> On Wed, Jul 31, 2013 at 4:14 PM, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>> > However, if we go back to the idea that DT is supposed to describe the
>> > hardware, _and_ that the way to describe that hardware is well defined
>> > and _stable_ (as it should be) then there should be no reason what so
>> > ever that your old DT blob should not continue working in later kernels.
>> > If it doesn't, then the contract that DT promised when we first moved
>> > over to using DT has been _broken_.
>>
>> Suppose your DT predates PINCTRL and the CPU needs the pins set to
>> function.  But setting the pins up is a board specific function. How
>> is this going to get implemented in a generic kernel that doesn't have
>> any board specific code in it?
>>
>> I would propose that we only need to worry about DTs that got put into
>> boot loaders and not worry about ones that were only used when
>> appended to a kernel.
>
> That is - again - our mistake.  We should have made it clear from the
> start that the use of an _appended_ DT, or a DT provided with the kernel
> being booted was more or less mandatory for the time being.  We actually
> did exactly the opposite - we advertised the appended DT as a stop-gap
> measure just to allow a DT kernel to be booted with a boot loader which
> didn't support DT.
>
> That in itself _encouraged_ boot loader support for DT on ARM (which in
> itself is not a bad thing) but also leads people down the path of
> potentially separating the DT from the kernel.
>
> Had we encouraged the use of an appended DT instead, but still encouraged
> boot loaders to update, and also made a clear statement that DT is
> unstable (which everyone can see - for example by making our DT stuff
> depend on CONFIG_EXPERIMENTAL when it existed) then everyone would have
> been clear about its status.
>
> The fact that we did not - the fact that we ignored this process means
> that it is _our_ problem that people like Richard are blowing up such a
> storm over this.  We need to admit that we got it wrong, and commit to
> doing it the right way in future.  What that means is starting off today
> with a commitment to keep as much of the stuff which works today working
> _tomorrow_, and the day after, and so forth.

What do you think about using a quirk layer to decouple deployed DTs
from whatever is implemented in the kernel? I still think there is
going to be volatility in the the kernel DT usage simply because we
haven't figured out all of the issues with it yet.  For example
defining a global schema system is going to expose a lot of irregular
DT syntax when you line up all of the platform DTs in a system where
it is easy to compare them. One the plus side the kernel is certainly
evolving to a point where this volatility will stop in the future, we
just aren't there yet.  If we don't use a quirk fixup system, then
board specific code is going to continue to exist scattered around in
the arch directories.

My preference would be to contain the board specific DT fixup code
inside a quirk system and have the goal of making the arch directories
free of board specific code. Any new board would have a good enough DT
that they don't need any board specific DT fixup code. Of course
there's quite a ways to go before reaching that goal.

Alternatively you may be of the belief that it is impossible to get
rid of the board specific code. But x86 doesn't have any of it, why
should ARM?

-- 
Jon Smirl
jonsmirl at gmail.com


From swarren at wwwdotorg.org  Wed Jul 31 17:32:37 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 Jul 2013 15:32:37 -0600
Subject: [PATCH 6/9] serial: tegra: move to generic dma DT binding
In-Reply-To: <20130731034541.GQ15855@rizhao-lap>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-7-git-send-email-rizhao@nvidia.com>
 <51F2D063.5010505@wwwdotorg.org> <20130730033134.GM15855@rizhao-lap>
 <51F7EDF2.60700@wwwdotorg.org> <20130731034541.GQ15855@rizhao-lap>
Message-ID: <51F98275.6020906@wwwdotorg.org>

On 07/30/2013 09:45 PM, Richard Zhao wrote:
> On Wed, Jul 31, 2013 at 12:46:42AM +0800, Stephen Warren wrote:
>> On 07/29/2013 09:31 PM, Richard Zhao wrote:
>>> On Sat, Jul 27, 2013 at 03:39:15AM +0800, Stephen Warren wrote:
>>>> On 07/23/2013 10:09 PM, Richard Zhao wrote:
>>>>> - driver: remove use of nvidia,dma-request-selector
>>>>> 	  use dma_request_slave_channel to request channel
>>>>> - update binding doc
>>>>
>>>> This patch needs to be amended so that the DMA channel is looked up
>>>> during probe() rather than open(), to guarantee that deferred probe
>>>> works. It's possible to hold off probe, but not possible AFAIK to hold
>>>> off opening the port.
>>>
>>> How about avoid return -EPROBE_DEFER at open() time? It can be in
>>> another patch.
>>
>> I don't really understand what you mean. -EPROBE_DEFER is something that
>> only makes sense for probe() to return (or functions used by probe()).
>> It doesn't make sense to return it anywhere else, since probe deferral
>> is something that can only happen for probe().
>
> What I meant is, it might not worth to move request channel to probe
> only because we need to check error and return -EPROBE_DEFER.

If probe() doesn't attempt to validate that the/a DMA channel provider
exists, then there's no guarantee that the DMA provider has probed
before the DMA client driver either probes or executes any later code.
So, you could quite easily end up with a situation where the serial
driver's open fails because the DMA provider has not yet probed. This is
exactly what deferred probe was intended to avoid. This reason alone is
enough to make it worth fixing this.

> dma_request_slave_channel is better to be called as late as possible to
> make better dynamic use of dma channels.

probe() could validate that the provider exists in a way that doesn't
permanently hold ownership of the DMA channel. For example, request it
then immediately release it, in the absence of a dedicated "validate my
DMA providers exist" API.

> Actually, I searched the kernel code, most drivers don't return EPROBE_DEFER
> when dma_request_slave_channel failed. dma_request_slave_channel can
> fail in many cases, and dma device not probed is only one case.

That sounds like a bug. If a DMA channel /is/ specified, it should be
possible to acquire it. If no DMA channel is specified, and if the
device can do PIO, then it's reasonable to continue.


From swarren at wwwdotorg.org  Wed Jul 31 17:33:12 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 Jul 2013 15:33:12 -0600
Subject: [PATCH 2/9] dma: tegra20-apbdma: move to generic device tree
 bindings
In-Reply-To: <20130731035256.GR15855@rizhao-lap>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-3-git-send-email-rizhao@nvidia.com>
 <51F2CDBE.40802@wwwdotorg.org> <20130730030644.GJ15855@rizhao-lap>
 <51F7ED62.4060404@wwwdotorg.org> <20130731035256.GR15855@rizhao-lap>
Message-ID: <51F98298.7000002@wwwdotorg.org>

On 07/30/2013 09:52 PM, Richard Zhao wrote:
> On Wed, Jul 31, 2013 at 12:44:18AM +0800, Stephen Warren wrote:
>> On 07/29/2013 09:06 PM, Richard Zhao wrote:
>>> On Sat, Jul 27, 2013 at 03:27:58AM +0800, Stephen Warren wrote:
>>>> (Stripping the Cc list a lot)
>>>>
>>>> On 07/23/2013 10:09 PM, Richard Zhao wrote:
>>>>> Update tegra20-apbdma driver to adopt generic DMA device tree bindings.
>>>>> It calls of_dma_controller_register() with of_dma_simple_xlate to get
>>>>> the generic DMA device tree helper support. The #dma-cells for apbdma
>>>>> must be 1, which is slave ID.
...
>>>> Why does this driver need to define a filter function? I thought the
>>>> dmaengine's DT support would already match DMA clients/engines based on
>>>> the phandle in DT? Isn't the need to pass the slave channel ID into
>>>> drivers something pretty fundamental to dmaengine, and hence something
>>>> it already supports?
>>>
>>> of_dma_simple_xlate only pass slave id to filter function. It needs
>>> change to pass dt node too. I didn't start work on the common code
>>> change yet. Do you think we need to hold it until common code change?
>>
>> Oh dear, I can't see how the core DT DMA support can work for anyone
>> without the ability to limit DMA clients to the specific DMA controller
>> that's specified in DT. If that functionality truly is missing, then it
>> certainly needs to be added first.
> 
> omap-dma uses the same way. 

The fact that some other driver does the same wrong thing isn't really a
good excuse not to fix it now.


From panetta.mike at gmail.com  Wed Jul 31 17:40:46 2013
From: panetta.mike at gmail.com (Michael Panetta)
Date: Wed, 31 Jul 2013 17:40:46 -0400
Subject: [PATCH] ARM: dts: imx6qdl-wandboard: add gpio lines to wandboard
 shared dtsi. 
Message-ID: <1375306847-14340-1-git-send-email-panetta.mike@gmail.com>

This patch adds support to the wandboard shared dts file for the 10 GPIO lines that are exposed on the EDM connector.

Michael Panetta (1):
  Add dts info for wandboard GPIO lines.

 arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

-- 
1.7.11.7



From panetta.mike at gmail.com  Wed Jul 31 17:40:47 2013
From: panetta.mike at gmail.com (Michael Panetta)
Date: Wed, 31 Jul 2013 17:40:47 -0400
Subject: [PATCH] Add dts info for wandboard GPIO lines.
In-Reply-To: <1375306847-14340-1-git-send-email-panetta.mike@gmail.com>
References: <1375306847-14340-1-git-send-email-panetta.mike@gmail.com>
Message-ID: <1375306847-14340-2-git-send-email-panetta.mike@gmail.com>

---
 arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
index a55113e..b40bbe1 100644
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -84,6 +84,23 @@
 			>;
 		};
 	};
+
+	gpio {
+		pinctrl_gpio: gpiogrp {
+			fsl,pins = <
+				MX6QDL_PAD_EIM_DA12__GPIO3_IO12   0x80000000 /* GPIO3_12 EDM pin 255 */
+				MX6QDL_PAD_EIM_DA11__GPIO3_IO11   0x80000000 /* GPIO3_11 EDM pin 256 */
+				MX6QDL_PAD_EIM_DA10__GPIO3_IO10   0x80000000 /* GPIO3_10 EDM pin 257 */
+				MX6QDL_PAD_EIM_D27__GPIO3_IO27    0x80000000 /* GPIO3_27 EDM pin 258 */
+				MX6QDL_PAD_EIM_D26__GPIO3_IO26    0x80000000 /* GPIO3_26 EDM pin 259 */
+				MX6QDL_PAD_EIM_BCLK__GPIO6_IO31   0x80000000 /* GPIO6_31 EDM pin 260 */
+				MX6QDL_PAD_EIM_DA8__GPIO3_IO08    0x80000000 /* GPIO3_8  EDM pin 261 */
+				MX6QDL_PAD_ENET_RX_ER__GPIO1_IO24 0x80000000 /* GPIO1_24 EDM pin 262 */
+				MX6QDL_PAD_GPIO_19__GPIO4_IO05    0x80000000 /* GPIO4_5  EDM pin 263 */
+				MX6QDL_PAD_SD3_RST__GPIO7_IO08    0x80000000 /* GPIO7_8  EDM pin 264 */
+			>;
+		};
+	};
 };
 
 &fec {
-- 
1.7.11.7



From swarren at wwwdotorg.org  Wed Jul 31 18:16:28 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 Jul 2013 16:16:28 -0600
Subject: [PATCH v6 2/8] ASoC: atmel: machine driver for at91sam9x5-wm8731
 boards
In-Reply-To: <20130730225845.GB9858@sirena.org.uk>
References: <1375180329-4860-1-git-send-email-richard.genoud@gmail.com>
 <1375180329-4860-3-git-send-email-richard.genoud@gmail.com>
 <51F7FBA8.6080400@wwwdotorg.org> <20130730204511.GX9858@sirena.org.uk>
 <51F8302D.406@wwwdotorg.org> <20130730225845.GB9858@sirena.org.uk>
Message-ID: <51F98CBC.6000302@wwwdotorg.org>

On 07/30/2013 04:58 PM, Mark Brown wrote:
> On Tue, Jul 30, 2013 at 03:29:17PM -0600, Stephen Warren wrote:
>> On 07/30/2013 02:45 PM, Mark Brown wrote:
> 
>>> You really shouldn't do this, it's not accomplishing much.
> 
>> What it accomplishes is not polluting the CODEC's binding with a
>> set of strings that must always be supported since DT is an ABI.
>> The strings are isolated into the specific audio complex binding,
>> which might possibly become deprecated and replaced with
>> something better and more generic.
> 
> You seem to be assuming that the strings are a bad thing.  I'm not
> sure that this is the case modulo the tooling issues...

I do tend to think that using strings is pretty evil...

> We could start adding the integers right now - something like:
> 
> The X CODEC has the following numbered input and output pins:
> 
> 1. HPOUTL 2. HPOUTR ...
> 
> (see datasheet for details), a header file is provided with 
> constants X_PIN_foo for convenience.
> 
> would work with either approach to identifying the pins or if
> we're being less verbose and just reference the header file for
> the definitions that becomes something like:
> 
> The X CODEC has input and output pins listed with numerical 
> identifiers in the form the X_PIN_foo defined in the X.h header 
> file where foo is the name of the pin.
> 
> (that's not good boilerplate wording but you get my drift) which
> still ends up defining a set of known strings for pins.
> 
> In fact now that I think about this why don't we just go ahead and
> do all this, starting by putting the numbers into the bindings for
> the CODECs since that's the simplest thing and doesn't involve
> writing code? I even have several boards on my desk that run DT
> ASoC...

I'm certainly fine with that compromise.


From soren.brinkmann at xilinx.com  Wed Jul 31 18:18:00 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Wed, 31 Jul 2013 15:18:00 -0700
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <51F97CE3.9030306@linaro.org>
References: <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
 <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
 <51F77D93.4030505@linaro.org> <51F97842.6050200@linaro.org>
 <068436c6-ff98-428f-8875-bb1c6f86466b@TX2EHSMHS008.ehs.local>
 <51F97CE3.9030306@linaro.org>
Message-ID: <15e19315-ce88-4d3c-bad9-0a37d9e52f6b@CO1EHSMHS007.ehs.local>

On Wed, Jul 31, 2013 at 11:08:51PM +0200, Daniel Lezcano wrote:
> On 07/31/2013 10:58 PM, S?ren Brinkmann wrote:
> > On Wed, Jul 31, 2013 at 10:49:06PM +0200, Daniel Lezcano wrote:
> >> On 07/31/2013 12:34 AM, S?ren Brinkmann wrote:
> >>> On Tue, Jul 30, 2013 at 10:47:15AM +0200, Daniel Lezcano wrote:
> >>>> On 07/30/2013 02:03 AM, S?ren Brinkmann wrote:
> >>>>> Hi Daniel,
> >>>>>
> >>>>> On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
> >>>>> (snip)
> >>>>>>
> >>>>>> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
> >>>>>> timer will be stopped when entering to the idle state. In this case, the
> >>>>>> cpuidle framework will call clockevents_notify(ENTER) and switches to a
> >>>>>> broadcast timer and will call clockevents_notify(EXIT) when exiting the
> >>>>>> idle state, switching the local timer back in use.
> >>>>>
> >>>>> I've been thinking about this, trying to understand how this makes my
> >>>>> boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
> >>>>> would make the timer core switch to a broadcast device even though it
> >>>>> wouldn't be necessary. But shouldn't it still work? It sounds like we do
> >>>>> something useless, but nothing wrong in a sense that it should result in
> >>>>> breakage. I guess I'm missing something obvious. This timer system will
> >>>>> always remain a mystery to me.
> >>>>>
> >>>>> Actually this more or less leads to the question: What is this
> >>>>> 'broadcast timer'. I guess that is some clockevent device which is
> >>>>> common to all cores? (that would be the cadence_ttc for Zynq). Is the
> >>>>> hang pointing to some issue with that driver?
> >>>>
> >>>> If you look at the /proc/timer_list, which timer is used for broadcasting ?
> >>>
> >>> So, the correct run results (full output attached).
> >>>
> >>> The vanilla kernel uses the twd timers as local timers and the TTC as
> >>> broadcast device:
> >>> 	Tick Device: mode:     1                                                         
> >>> 	Broadcast device  
> >>> 	Clock Event Device: ttc_clockevent
> >>>
> >>> When I remove the offending CPUIDLE flag and add the DT fragment to
> >>> enable the global timer, the twd timers are still used as local timers
> >>> and the broadcast device is the global timer:
> >>> 	Tick Device: mode:     1                                                         
> >>> 	Broadcast device                                                                 
> >>> 	Clock Event Device: arm_global_timer
> >>>
> >>> Again, since boot hangs in the actually broken case, I don't see way to
> >>> obtain this information for that case.
> >>
> >> Can't you use the maxcpus=1 option to ensure the system to boot up ?
> > 
> > Right, that works. I forgot about that option after you mentioned, that
> > it is most likely not that useful.
> > 
> > Anyway, this are those sysfs files with an unmodified cpuidle driver and
> > the gt enabled and having maxcpus=1 set.
> > 
> > /proc/timer_list:
> > 	Tick Device: mode:     1
> > 	Broadcast device
> > 	Clock Event Device: arm_global_timer
> > 	 max_delta_ns:   12884902005
> > 	 min_delta_ns:   1000
> > 	 mult:           715827876
> > 	 shift:          31
> > 	 mode:           3
> 
> Here the mode is 3 (CLOCK_EVT_MODE_ONESHOT)
> 
> The previous timer_list output you gave me when removing the offending
> cpuidle flag, it was 1 (CLOCK_EVT_MODE_SHUTDOWN).
> 
> Is it possible you try to get this output again right after onlining the
> cpu1 in order to check if the broadcast device switches to SHUTDOWN ?

How do I do that? I tried to online CPU1 after booting with maxcpus=1
and that didn't end well:
	# echo 1 > online && cat /proc/timer_list 
	[ 4689.992658] CPU1: Booted secondary processor
	[ 4690.986295] CPU1: failed to come online
	sh: write error: Input/output error
	# [ 4691.045945] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
	[ 4691.045986] 
	[ 4691.052972] ===============================
	[ 4691.057349] [ INFO: suspicious RCU usage. ]
	[ 4691.061413] 3.11.0-rc3-00001-gc14f576-dirty #139 Not tainted
	[ 4691.067026] -------------------------------
	[ 4691.071129] kernel/sched/fair.c:5477 suspicious rcu_dereference_check() usage!
	[ 4691.078292] 
	[ 4691.078292] other info that might help us debug this:
	[ 4691.078292] 
	[ 4691.086209] 
	[ 4691.086209] RCU used illegally from offline CPU!
	[ 4691.086209] rcu_scheduler_active = 1, debug_locks = 0
	[ 4691.097216] 1 lock held by swapper/1/0:
	[ 4691.100968]  #0:  (rcu_read_lock){.+.+..}, at: [<c00679b4>] set_cpu_sd_state_idle+0x0/0x1e4
	[ 4691.109250] 
	[ 4691.109250] stack backtrace:
	[ 4691.113531] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.0-rc3-00001-gc14f576-dirty #139
	[ 4691.121755] [<c0016a88>] (unwind_backtrace+0x0/0x128) from [<c0012d58>] (show_stack+0x20/0x24)
	[ 4691.130263] [<c0012d58>] (show_stack+0x20/0x24) from [<c045bd50>] (dump_stack+0x80/0xc4)
	[ 4691.138264] [<c045bd50>] (dump_stack+0x80/0xc4) from [<c007ad78>] (lockdep_rcu_suspicious+0xdc/0x118)
	[ 4691.147371] [<c007ad78>] (lockdep_rcu_suspicious+0xdc/0x118) from [<c0067ac0>] (set_cpu_sd_state_idle+0x10c/0x1e4)
	[ 4691.157605] [<c0067ac0>] (set_cpu_sd_state_idle+0x10c/0x1e4) from [<c0078238>] (tick_nohz_idle_enter+0x48/0x80)
	[ 4691.167583] [<c0078238>] (tick_nohz_idle_enter+0x48/0x80) from [<c006dc5c>] (cpu_startup_entry+0x28/0x388)
	[ 4691.177127] [<c006dc5c>] (cpu_startup_entry+0x28/0x388) from [<c0014acc>] (secondary_start_kernel+0x12c/0x144)
	[ 4691.187013] [<c0014acc>] (secondary_start_kernel+0x12c/0x144) from [<000081ec>] (0x81ec)


	S?ren




From sboyd at codeaurora.org  Wed Jul 31 18:31:00 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:00 -0700
Subject: [PATCH 01/18] ARM: timer-sp: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-2-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface. Also mark the read function notrace since we're here
and failure to do so would cause ftrace to break.

Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/common/timer-sp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/common/timer-sp.c b/arch/arm/common/timer-sp.c
index 023ee63..766e317 100644
--- a/arch/arm/common/timer-sp.c
+++ b/arch/arm/common/timer-sp.c
@@ -66,7 +66,7 @@ static long __init sp804_get_clock_rate(struct clk *clk)
 
 static void __iomem *sched_clock_base;
 
-static u32 sp804_read(void)
+static u64 notrace sp804_read(void)
 {
 	return ~readl_relaxed(sched_clock_base + TIMER_VALUE);
 }
@@ -104,7 +104,7 @@ void __init __sp804_clocksource_and_sched_clock_init(void __iomem *base,
 
 	if (use_sched_clock) {
 		sched_clock_base = base;
-		setup_sched_clock(sp804_read, 32, rate);
+		sched_clock_register(sp804_read, 32, rate);
 	}
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:01 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:01 -0700
Subject: [PATCH 02/18] ARM: clps711x: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-3-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Alexander Shiyan <shc_work at mail.ru>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-clps711x/common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-clps711x/common.c b/arch/arm/mach-clps711x/common.c
index 4ca2f3c..5e5a6ac 100644
--- a/arch/arm/mach-clps711x/common.c
+++ b/arch/arm/mach-clps711x/common.c
@@ -259,7 +259,7 @@ asmlinkage void __exception_irq_entry clps711x_handle_irq(struct pt_regs *regs)
 	} while (1);
 }
 
-static u32 notrace clps711x_sched_clock_read(void)
+static u64 notrace clps711x_sched_clock_read(void)
 {
 	return ~readw_relaxed(CLPS711X_VIRT_BASE + TC1D);
 }
@@ -366,7 +366,7 @@ void __init clps711x_timer_init(void)
 	tmp = clps_readl(SYSCON1) & ~(SYSCON1_TC1S | SYSCON1_TC1M);
 	clps_writel(tmp, SYSCON1);
 
-	setup_sched_clock(clps711x_sched_clock_read, 16, timl);
+	sched_clock_register(clps711x_sched_clock_read, 16, timl);
 
 	clocksource_mmio_init(CLPS711X_VIRT_BASE + TC1D,
 			      "clps711x_clocksource", timl, 300, 16,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:03 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:03 -0700
Subject: [PATCH 04/18] ARM: imx: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-5-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Sascha Hauer <kernel at pengutronix.de>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-imx/time.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/time.c b/arch/arm/mach-imx/time.c
index cd46529..7ab3b9c6 100644
--- a/arch/arm/mach-imx/time.c
+++ b/arch/arm/mach-imx/time.c
@@ -111,7 +111,7 @@ static void gpt_irq_acknowledge(void)
 
 static void __iomem *sched_clock_reg;
 
-static u32 notrace mxc_read_sched_clock(void)
+static u64 notrace mxc_read_sched_clock(void)
 {
 	return sched_clock_reg ? __raw_readl(sched_clock_reg) : 0;
 }
@@ -123,7 +123,7 @@ static int __init mxc_clocksource_init(struct clk *timer_clk)
 
 	sched_clock_reg = reg;
 
-	setup_sched_clock(mxc_read_sched_clock, 32, c);
+	sched_clock_register(mxc_read_sched_clock, 32, c);
 	return clocksource_mmio_init(reg, "mxc_timer1", c, 200, 32,
 			clocksource_mmio_readl_up);
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:02 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:02 -0700
Subject: [PATCH 03/18] ARM: davinci: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-4-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Kevin Hilman <khilman at deeprootsystems.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-davinci/time.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index 7a55b5c..6d5440a 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -285,7 +285,7 @@ static struct clocksource clocksource_davinci = {
 /*
  * Overwrite weak default sched_clock with something more precise
  */
-static u32 notrace davinci_read_sched_clock(void)
+static u64 notrace davinci_read_sched_clock(void)
 {
 	return timer32_read(&timers[TID_CLOCKSOURCE]);
 }
@@ -392,7 +392,7 @@ void __init davinci_timer_init(void)
 				    davinci_clock_tick_rate))
 		printk(err, clocksource_davinci.name);
 
-	setup_sched_clock(davinci_read_sched_clock, 32,
+	sched_clock_register(davinci_read_sched_clock, 32,
 			  davinci_clock_tick_rate);
 
 	/* setup clockevent */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:30:59 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:30:59 -0700
Subject: [PATCH 00/18] Convert arm sched_clock users to sched_clock_register()
In-Reply-To: <51F80B09.8060509@linaro.org>
Message-ID: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>

This patchset converts all the arm users to sched_clock_register(). It
is based on the pull request that this is in reply to. Platform
maintainers, please ack/review.

Cc: Alexander Shiyan <shc_work at mail.ru>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Ben Dooks <ben-linux at fluff.org>
Cc: David Brown <davidb at codeaurora.org>
Cc: Eric Miao <eric.y.miao at gmail.com>
Cc: Haojian Zhuang <haojian.zhuang at gmail.com>
Cc: Imre Kaloz <kaloz at openwrt.org>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Kevin Hilman <khilman at deeprootsystems.com>
Cc: Krzysztof Halasa <khc at pm.waw.pl>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Sascha Hauer <kernel at pengutronix.de>
Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Tony Lindgren <tony at atomide.com>

Stephen Boyd (18):
  ARM: timer-sp: Switch to sched_clock_register()
  ARM: clps711x: Switch to sched_clock_register()
  ARM: davinci: Switch to sched_clock_register()
  ARM: imx: Switch to sched_clock_register()
  ARM: integrator: Switch to sched_clock_register()
  ARM: IXP4xx: Switch to sched_clock_register()
  ARM: mmp: Switch to sched_clock_register()
  ARM: msm: Switch to sched_clock_register()
  ARM: OMAP1: Switch to sched_clock_register()
  ARM: OMAP2+: Switch to sched_clock_register()
  ARM: pxa: Switch to sched_clock_register()
  ARM: sa1100: Switch to sched_clock_register()
  ARM: u300: Switch to sched_clock_register()
  ARM: iop: Switch to sched_clock_register()
  ARM: OMAP: Switch to sched_clock_register()
  ARM: orion: Switch to sched_clock_register()
  ARM: SAMSUNG: Switch to sched_clock_register()
  ARM: versatile: Switch to sched_clock_register()

 arch/arm/common/timer-sp.c               | 4 ++--
 arch/arm/mach-clps711x/common.c          | 4 ++--
 arch/arm/mach-davinci/time.c             | 4 ++--
 arch/arm/mach-imx/time.c                 | 4 ++--
 arch/arm/mach-integrator/integrator_ap.c | 4 ++--
 arch/arm/mach-ixp4xx/common.c            | 4 ++--
 arch/arm/mach-mmp/time.c                 | 4 ++--
 arch/arm/mach-msm/timer.c                | 4 ++--
 arch/arm/mach-omap1/time.c               | 4 ++--
 arch/arm/mach-omap2/timer.c              | 4 ++--
 arch/arm/mach-pxa/time.c                 | 4 ++--
 arch/arm/mach-sa1100/time.c              | 4 ++--
 arch/arm/mach-u300/timer.c               | 4 ++--
 arch/arm/plat-iop/time.c                 | 4 ++--
 arch/arm/plat-omap/counter_32k.c         | 4 ++--
 arch/arm/plat-orion/time.c               | 4 ++--
 arch/arm/plat-samsung/samsung-time.c     | 4 ++--
 arch/arm/plat-versatile/sched-clock.c    | 4 ++--
 18 files changed, 36 insertions(+), 36 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:08 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:08 -0700
Subject: [PATCH 09/18] ARM: OMAP1: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-10-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Tony Lindgren <tony at atomide.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-omap1/time.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index 80603d2..6ded515 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -181,7 +181,7 @@ static __init void omap_init_mpu_timer(unsigned long rate)
  * ---------------------------------------------------------------------------
  */
 
-static u32 notrace omap_mpu_read_sched_clock(void)
+static u64 notrace omap_mpu_read_sched_clock(void)
 {
 	return ~omap_mpu_timer_read(1);
 }
@@ -193,7 +193,7 @@ static void __init omap_init_clocksource(unsigned long rate)
 			"%s: can't register clocksource!\n";
 
 	omap_mpu_timer_start(1, ~0, 1);
-	setup_sched_clock(omap_mpu_read_sched_clock, 32, rate);
+	sched_clock_register(omap_mpu_read_sched_clock, 32, rate);
 
 	if (clocksource_mmio_init(&timer->read_tim, "mpu_timer2", rate,
 			300, 32, clocksource_mmio_readl_down))
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:11 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:11 -0700
Subject: [PATCH 12/18] ARM: sa1100: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-13-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-sa1100/time.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-sa1100/time.c b/arch/arm/mach-sa1100/time.c
index 713c86c..6fd4acb 100644
--- a/arch/arm/mach-sa1100/time.c
+++ b/arch/arm/mach-sa1100/time.c
@@ -20,7 +20,7 @@
 #include <mach/hardware.h>
 #include <mach/irqs.h>
 
-static u32 notrace sa1100_read_sched_clock(void)
+static u64 notrace sa1100_read_sched_clock(void)
 {
 	return readl_relaxed(OSCR);
 }
@@ -122,7 +122,7 @@ void __init sa1100_timer_init(void)
 	writel_relaxed(0, OIER);
 	writel_relaxed(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);
 
-	setup_sched_clock(sa1100_read_sched_clock, 32, 3686400);
+	sched_clock_register(sa1100_read_sched_clock, 32, 3686400);
 
 	ckevt_sa1100_osmr0.cpumask = cpumask_of(0);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:13 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:13 -0700
Subject: [PATCH 14/18] ARM: iop: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-15-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/plat-iop/time.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-iop/time.c b/arch/arm/plat-iop/time.c
index 29606bd7..d70b733 100644
--- a/arch/arm/plat-iop/time.c
+++ b/arch/arm/plat-iop/time.c
@@ -54,7 +54,7 @@ static struct clocksource iop_clocksource = {
 /*
  * IOP sched_clock() implementation via its clocksource.
  */
-static u32 notrace iop_read_sched_clock(void)
+static u64 notrace iop_read_sched_clock(void)
 {
 	return 0xffffffffu - read_tcr1();
 }
@@ -142,7 +142,7 @@ void __init iop_init_time(unsigned long tick_rate)
 {
 	u32 timer_ctl;
 
-	setup_sched_clock(iop_read_sched_clock, 32, tick_rate);
+	sched_clock_register(iop_read_sched_clock, 32, tick_rate);
 
 	ticks_per_jiffy = DIV_ROUND_CLOSEST(tick_rate, HZ);
 	iop_tick_rate = tick_rate;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:04 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:04 -0700
Subject: [PATCH 05/18] ARM: integrator: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-6-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-integrator/integrator_ap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index d9e95e6..1489f5c 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -277,7 +277,7 @@ struct amba_pl010_data ap_uart_data = {
 
 static unsigned long timer_reload;
 
-static u32 notrace integrator_read_sched_clock(void)
+static u64 notrace integrator_read_sched_clock(void)
 {
 	return -readl((void __iomem *) TIMER2_VA_BASE + TIMER_VALUE);
 }
@@ -298,7 +298,7 @@ static void integrator_clocksource_init(unsigned long inrate,
 
 	clocksource_mmio_init(base + TIMER_VALUE, "timer2",
 			rate, 200, 16, clocksource_mmio_readl_down);
-	setup_sched_clock(integrator_read_sched_clock, 16, rate);
+	sched_clock_register(integrator_read_sched_clock, 16, rate);
 }
 
 static void __iomem * clkevt_base;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:06 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:06 -0700
Subject: [PATCH 07/18] ARM: mmp: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-8-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Eric Miao <eric.y.miao at gmail.com>
Cc: Haojian Zhuang <haojian.zhuang at gmail.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-mmp/time.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-mmp/time.c b/arch/arm/mach-mmp/time.c
index 7ac41e8..024022d 100644
--- a/arch/arm/mach-mmp/time.c
+++ b/arch/arm/mach-mmp/time.c
@@ -61,7 +61,7 @@ static inline uint32_t timer_read(void)
 	return __raw_readl(mmp_timer_base + TMR_CVWR(1));
 }
 
-static u32 notrace mmp_read_sched_clock(void)
+static u64 notrace mmp_read_sched_clock(void)
 {
 	return timer_read();
 }
@@ -195,7 +195,7 @@ void __init timer_init(int irq)
 {
 	timer_config();
 
-	setup_sched_clock(mmp_read_sched_clock, 32, CLOCK_TICK_RATE);
+	sched_clock_register(mmp_read_sched_clock, 32, CLOCK_TICK_RATE);
 
 	ckevt.cpumask = cpumask_of(0);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:10 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:10 -0700
Subject: [PATCH 11/18] ARM: pxa: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-12-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Eric Miao <eric.y.miao at gmail.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang at gmail.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-pxa/time.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-pxa/time.c b/arch/arm/mach-pxa/time.c
index 9aa852a..d1bfaa7 100644
--- a/arch/arm/mach-pxa/time.c
+++ b/arch/arm/mach-pxa/time.c
@@ -33,7 +33,7 @@
  * calls to sched_clock() which should always be the case in practice.
  */
 
-static u32 notrace pxa_read_sched_clock(void)
+static u64 notrace pxa_read_sched_clock(void)
 {
 	return readl_relaxed(OSCR);
 }
@@ -149,7 +149,7 @@ void __init pxa_timer_init(void)
 	writel_relaxed(0, OIER);
 	writel_relaxed(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);
 
-	setup_sched_clock(pxa_read_sched_clock, 32, clock_tick_rate);
+	sched_clock_register(pxa_read_sched_clock, 32, clock_tick_rate);
 
 	ckevt_pxa_osmr0.cpumask = cpumask_of(0);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:09 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:09 -0700
Subject: [PATCH 10/18] ARM: OMAP2+: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-11-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Tony Lindgren <tony at atomide.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-omap2/timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b37e1fc..54b3cbe 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -369,7 +369,7 @@ static struct clocksource clocksource_gpt = {
 	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
-static u32 notrace dmtimer_read_sched_clock(void)
+static u64 notrace dmtimer_read_sched_clock(void)
 {
 	if (clksrc.reserved)
 		return __omap_dm_timer_read_counter(&clksrc,
@@ -461,7 +461,7 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
 	__omap_dm_timer_load_start(&clksrc,
 				   OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0,
 				   OMAP_TIMER_NONPOSTED);
-	setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate);
+	sched_clock_register(dmtimer_read_sched_clock, 32, clksrc.rate);
 
 	if (clocksource_register_hz(&clocksource_gpt, clksrc.rate))
 		pr_err("Could not register clocksource %s\n",
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:07 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:07 -0700
Subject: [PATCH 08/18] ARM: msm: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-9-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: David Brown <davidb at codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-msm/timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index b6418fd..3c9b4da 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -170,7 +170,7 @@ static struct local_timer_ops msm_local_timer_ops __cpuinitdata = {
 };
 #endif /* CONFIG_LOCAL_TIMERS */
 
-static notrace u32 msm_sched_clock_read(void)
+static u64 notrace msm_sched_clock_read(void)
 {
 	return msm_clocksource.read(&msm_clocksource);
 }
@@ -215,7 +215,7 @@ err:
 	res = clocksource_register_hz(cs, dgt_hz);
 	if (res)
 		pr_err("clocksource_register failed\n");
-	setup_sched_clock(msm_sched_clock_read, sched_bits, dgt_hz);
+	sched_clock_register(msm_sched_clock_read, sched_bits, dgt_hz);
 }
 
 #ifdef CONFIG_OF
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:12 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:12 -0700
Subject: [PATCH 13/18] ARM: u300: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-14-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-u300/timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-u300/timer.c b/arch/arm/mach-u300/timer.c
index b5db207..d23a1f0 100644
--- a/arch/arm/mach-u300/timer.c
+++ b/arch/arm/mach-u300/timer.c
@@ -341,7 +341,7 @@ static struct irqaction u300_timer_irq = {
  * stamp. (Inspired by OMAP implementation.)
  */
 
-static u32 notrace u300_read_sched_clock(void)
+static u64 notrace u300_read_sched_clock(void)
 {
 	return readl(u300_timer_base + U300_TIMER_APP_GPT2CC);
 }
@@ -380,7 +380,7 @@ static void __init u300_timer_init_of(struct device_node *np)
 	clk_prepare_enable(clk);
 	rate = clk_get_rate(clk);
 
-	setup_sched_clock(u300_read_sched_clock, 32, rate);
+	sched_clock_register(u300_read_sched_clock, 32, rate);
 
 	u300_delay_timer.read_current_timer = &u300_read_current_timer;
 	u300_delay_timer.freq = rate;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:05 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:05 -0700
Subject: [PATCH 06/18] ARM: IXP4xx: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-7-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Imre Kaloz <kaloz at openwrt.org>
Cc: Krzysztof Halasa <khc at pm.waw.pl>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/mach-ixp4xx/common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index 5327dec..124631e 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -448,7 +448,7 @@ void __init ixp4xx_sys_init(void)
 /*
  * sched_clock()
  */
-static u32 notrace ixp4xx_read_sched_clock(void)
+static u64 notrace ixp4xx_read_sched_clock(void)
 {
 	return *IXP4XX_OSTS;
 }
@@ -466,7 +466,7 @@ unsigned long ixp4xx_timer_freq = IXP4XX_TIMER_FREQ;
 EXPORT_SYMBOL(ixp4xx_timer_freq);
 static void __init ixp4xx_clocksource_init(void)
 {
-	setup_sched_clock(ixp4xx_read_sched_clock, 32, ixp4xx_timer_freq);
+	sched_clock_register(ixp4xx_read_sched_clock, 32, ixp4xx_timer_freq);
 
 	clocksource_mmio_init(NULL, "OSTS", ixp4xx_timer_freq, 200, 32,
 			ixp4xx_clocksource_read);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:14 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:14 -0700
Subject: [PATCH 15/18] ARM: OMAP: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-16-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Tony Lindgren <tony at atomide.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/plat-omap/counter_32k.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index d9bc98e..384a776d 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -38,7 +38,7 @@
  */
 static void __iomem *sync32k_cnt_reg;
 
-static u32 notrace omap_32k_read_sched_clock(void)
+static u64 notrace omap_32k_read_sched_clock(void)
 {
 	return sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
 }
@@ -115,7 +115,7 @@ int __init omap_init_clocksource_32k(void __iomem *vbase)
 		return ret;
 	}
 
-	setup_sched_clock(omap_32k_read_sched_clock, 32, 32768);
+	sched_clock_register(omap_32k_read_sched_clock, 32, 32768);
 	register_persistent_clock(NULL, omap_read_persistent_clock);
 	pr_info("OMAP clocksource: 32k_counter at 32768 Hz\n");
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:17 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:17 -0700
Subject: [PATCH 18/18] ARM: versatile: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-19-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/plat-versatile/sched-clock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-versatile/sched-clock.c b/arch/arm/plat-versatile/sched-clock.c
index 51b109e..c966ae9 100644
--- a/arch/arm/plat-versatile/sched-clock.c
+++ b/arch/arm/plat-versatile/sched-clock.c
@@ -26,7 +26,7 @@
 
 static void __iomem *ctr;
 
-static u32 notrace versatile_read_sched_clock(void)
+static u64 notrace versatile_read_sched_clock(void)
 {
 	if (ctr)
 		return readl(ctr);
@@ -37,5 +37,5 @@ static u32 notrace versatile_read_sched_clock(void)
 void __init versatile_sched_clock_init(void __iomem *reg, unsigned long rate)
 {
 	ctr = reg;
-	setup_sched_clock(versatile_read_sched_clock, 32, rate);
+	sched_clock_register(versatile_read_sched_clock, 32, rate);
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:15 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:15 -0700
Subject: [PATCH 16/18] ARM: orion: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-17-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Andrew Lunn <andrew at lunn.ch>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/plat-orion/time.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-orion/time.c b/arch/arm/plat-orion/time.c
index 9d2b2ac..dade292 100644
--- a/arch/arm/plat-orion/time.c
+++ b/arch/arm/plat-orion/time.c
@@ -60,7 +60,7 @@ static u32 ticks_per_jiffy;
  * at least 7.5ns (133MHz TCLK).
  */
 
-static u32 notrace orion_read_sched_clock(void)
+static u64 notrace orion_read_sched_clock(void)
 {
 	return ~readl(timer_base + TIMER0_VAL_OFF);
 }
@@ -201,7 +201,7 @@ orion_time_init(void __iomem *_bridge_base, u32 _bridge_timer1_clr_mask,
 	/*
 	 * Set scale and timer for sched_clock.
 	 */
-	setup_sched_clock(orion_read_sched_clock, 32, tclk);
+	sched_clock_register(orion_read_sched_clock, 32, tclk);
 
 	/*
 	 * Setup free-running clocksource timer (interrupts
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:31:16 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:31:16 -0700
Subject: [PATCH 17/18] ARM: SAMSUNG: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1375309877-16617-18-git-send-email-sboyd@codeaurora.org>

The 32 bit sched_clock interface now supports 64 bits. Upgrade to
the 64 bit function to allow us to remove the 32 bit registration
interface.

Cc: Ben Dooks <ben-linux at fluff.org>
Cc: Kukjin Kim <kgene.kim at samsung.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 arch/arm/plat-samsung/samsung-time.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-samsung/samsung-time.c b/arch/arm/plat-samsung/samsung-time.c
index 2957075..1e2119b 100644
--- a/arch/arm/plat-samsung/samsung-time.c
+++ b/arch/arm/plat-samsung/samsung-time.c
@@ -312,7 +312,7 @@ static void __iomem *samsung_timer_reg(void)
  * this wraps around for now, since it is just a relative time
  * stamp. (Inspired by U300 implementation.)
  */
-static u32 notrace samsung_read_sched_clock(void)
+static u64 notrace samsung_read_sched_clock(void)
 {
 	void __iomem *reg = samsung_timer_reg();
 
@@ -337,7 +337,7 @@ static void __init samsung_clocksource_init(void)
 	samsung_time_setup(timer_source.source_id, TCNT_MAX);
 	samsung_time_start(timer_source.source_id, PERIODIC);
 
-	setup_sched_clock(samsung_read_sched_clock, TSIZE, clock_rate);
+	sched_clock_register(samsung_read_sched_clock, TSIZE, clock_rate);
 
 	if (clocksource_mmio_init(samsung_timer_reg(), "samsung_clocksource_timer",
 			clock_rate, 250, TSIZE, clocksource_mmio_readl_down))
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation



From sboyd at codeaurora.org  Wed Jul 31 18:38:33 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 15:38:33 -0700
Subject: [PATCH v4 0/5] Memory mapped architected timers
In-Reply-To: <20130724203253.GE27761@codeaurora.org>
References: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
 <20130722170817.GB4833@e106331-lin.cambridge.arm.com>
 <20130724203253.GE27761@codeaurora.org>
Message-ID: <20130731223833.GJ8868@codeaurora.org>

On 07/24, Stephen Boyd wrote:
> On 07/22, Mark Rutland wrote:
> > Hi Stephen,
> > 
> > On Fri, Jul 19, 2013 at 12:59:27AM +0100, Stephen Boyd wrote:
> > > This patchset adds support for memory mapped architected timers. We
> > > don't have any other global broadcast timer in our system, so we use the
> > > mmio timer during low power modes. The first patch changes the register
> > > accessor to an enum per Thomas' request. The second patch is the binding.
> > > The next two patches lay some groundwork so that the last patch is simpler.
> > > The final patch adds support for mmio timers.
> > > 
> > > Patches are based on v3.11-rc1.
> > 
> > Be aware that as of v3.11-rc2 this doesn't cleanly apply, as the
> > __cpuinit removal broke the final patch's context in a couple of places.
> > It would be nice to get rid of the new cpuinit additions too...
> > 
> > With that cleaned up locally, I've gave this a spin on tc2 and a
> > Foundation model to test the cp15/system timers, hotplugging CPUs and
> > running a basic test (`time sleep 5`). That all seems to work.
> > 
> > Unfortunately I have no way of testing the memory-mapped timer support,
> > but I trust you've tested that locally.
> > 
> > For the series:
> > 
> > Acked-by: Mark Rutland <mark.rutland at arm.com>
> > 
> 
> Thanks Mark.
> 
> Daniel, can you pick up these patches please?
> 

Ping Daniel?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


From daniel.lezcano at linaro.org  Wed Jul 31 18:49:14 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 01 Aug 2013 00:49:14 +0200
Subject: [PATCH v4 0/5] Memory mapped architected timers
In-Reply-To: <20130731223833.GJ8868@codeaurora.org>
References: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
 <20130722170817.GB4833@e106331-lin.cambridge.arm.com>
 <20130724203253.GE27761@codeaurora.org>
 <20130731223833.GJ8868@codeaurora.org>
Message-ID: <51F9946A.50107@linaro.org>

On 08/01/2013 12:38 AM, Stephen Boyd wrote:
> On 07/24, Stephen Boyd wrote:
>> On 07/22, Mark Rutland wrote:
>>> Hi Stephen,
>>>
>>> On Fri, Jul 19, 2013 at 12:59:27AM +0100, Stephen Boyd wrote:
>>>> This patchset adds support for memory mapped architected timers. We
>>>> don't have any other global broadcast timer in our system, so we use the
>>>> mmio timer during low power modes. The first patch changes the register
>>>> accessor to an enum per Thomas' request. The second patch is the binding.
>>>> The next two patches lay some groundwork so that the last patch is simpler.
>>>> The final patch adds support for mmio timers.
>>>>
>>>> Patches are based on v3.11-rc1.
>>>
>>> Be aware that as of v3.11-rc2 this doesn't cleanly apply, as the
>>> __cpuinit removal broke the final patch's context in a couple of places.
>>> It would be nice to get rid of the new cpuinit additions too...
>>>
>>> With that cleaned up locally, I've gave this a spin on tc2 and a
>>> Foundation model to test the cp15/system timers, hotplugging CPUs and
>>> running a basic test (`time sleep 5`). That all seems to work.
>>>
>>> Unfortunately I have no way of testing the memory-mapped timer support,
>>> but I trust you've tested that locally.
>>>
>>> For the series:
>>>
>>> Acked-by: Mark Rutland <mark.rutland at arm.com>
>>>
>>
>> Thanks Mark.
>>
>> Daniel, can you pick up these patches please?
>>
> 
> Ping Daniel?

Yes, thanks for the head up.

I will look at them and pick the patches.

  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From daniel.lezcano at linaro.org  Wed Jul 31 19:01:27 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 01 Aug 2013 01:01:27 +0200
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <15e19315-ce88-4d3c-bad9-0a37d9e52f6b@CO1EHSMHS007.ehs.local>
References: <ff4d40be-7177-4a55-ab2f-dff11fa18642@DB9EHSMHS009.ehs.local>
 <51ED8DF2.60600@codeaurora.org> <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
 <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
 <51F77D93.4030505@linaro.org> <51F97842.6050200@linaro.org>
 <068436c6-ff98-428f-8875-bb1c6f86466b@TX2EHSMHS008.ehs.local>
 <51F97CE3.9030306@linaro.org>
 <15e19315-ce88-4d3c-bad9-0a37d9e52f6b@CO1EHSMHS007.ehs.local>
Message-ID: <51F99747.4060901@linaro.org>

On 08/01/2013 12:18 AM, S?ren Brinkmann wrote:
> On Wed, Jul 31, 2013 at 11:08:51PM +0200, Daniel Lezcano wrote:
>> On 07/31/2013 10:58 PM, S?ren Brinkmann wrote:
>>> On Wed, Jul 31, 2013 at 10:49:06PM +0200, Daniel Lezcano wrote:
>>>> On 07/31/2013 12:34 AM, S?ren Brinkmann wrote:
>>>>> On Tue, Jul 30, 2013 at 10:47:15AM +0200, Daniel Lezcano wrote:
>>>>>> On 07/30/2013 02:03 AM, S?ren Brinkmann wrote:
>>>>>>> Hi Daniel,
>>>>>>>
>>>>>>> On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
>>>>>>> (snip)
>>>>>>>>
>>>>>>>> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
>>>>>>>> timer will be stopped when entering to the idle state. In this case, the
>>>>>>>> cpuidle framework will call clockevents_notify(ENTER) and switches to a
>>>>>>>> broadcast timer and will call clockevents_notify(EXIT) when exiting the
>>>>>>>> idle state, switching the local timer back in use.
>>>>>>>
>>>>>>> I've been thinking about this, trying to understand how this makes my
>>>>>>> boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
>>>>>>> would make the timer core switch to a broadcast device even though it
>>>>>>> wouldn't be necessary. But shouldn't it still work? It sounds like we do
>>>>>>> something useless, but nothing wrong in a sense that it should result in
>>>>>>> breakage. I guess I'm missing something obvious. This timer system will
>>>>>>> always remain a mystery to me.
>>>>>>>
>>>>>>> Actually this more or less leads to the question: What is this
>>>>>>> 'broadcast timer'. I guess that is some clockevent device which is
>>>>>>> common to all cores? (that would be the cadence_ttc for Zynq). Is the
>>>>>>> hang pointing to some issue with that driver?
>>>>>>
>>>>>> If you look at the /proc/timer_list, which timer is used for broadcasting ?
>>>>>
>>>>> So, the correct run results (full output attached).
>>>>>
>>>>> The vanilla kernel uses the twd timers as local timers and the TTC as
>>>>> broadcast device:
>>>>> 	Tick Device: mode:     1                                                         
>>>>> 	Broadcast device  
>>>>> 	Clock Event Device: ttc_clockevent
>>>>>
>>>>> When I remove the offending CPUIDLE flag and add the DT fragment to
>>>>> enable the global timer, the twd timers are still used as local timers
>>>>> and the broadcast device is the global timer:
>>>>> 	Tick Device: mode:     1                                                         
>>>>> 	Broadcast device                                                                 
>>>>> 	Clock Event Device: arm_global_timer
>>>>>
>>>>> Again, since boot hangs in the actually broken case, I don't see way to
>>>>> obtain this information for that case.
>>>>
>>>> Can't you use the maxcpus=1 option to ensure the system to boot up ?
>>>
>>> Right, that works. I forgot about that option after you mentioned, that
>>> it is most likely not that useful.
>>>
>>> Anyway, this are those sysfs files with an unmodified cpuidle driver and
>>> the gt enabled and having maxcpus=1 set.
>>>
>>> /proc/timer_list:
>>> 	Tick Device: mode:     1
>>> 	Broadcast device
>>> 	Clock Event Device: arm_global_timer
>>> 	 max_delta_ns:   12884902005
>>> 	 min_delta_ns:   1000
>>> 	 mult:           715827876
>>> 	 shift:          31
>>> 	 mode:           3
>>
>> Here the mode is 3 (CLOCK_EVT_MODE_ONESHOT)
>>
>> The previous timer_list output you gave me when removing the offending
>> cpuidle flag, it was 1 (CLOCK_EVT_MODE_SHUTDOWN).
>>
>> Is it possible you try to get this output again right after onlining the
>> cpu1 in order to check if the broadcast device switches to SHUTDOWN ?
> 
> How do I do that? I tried to online CPU1 after booting with maxcpus=1
> and that didn't end well:
> 	# echo 1 > online && cat /proc/timer_list 

Hmm, I was hoping to have a small delay before the kernel hangs but
apparently this is not the case... :(

I suspect the global timer is shutdown at one moment but I don't
understand why and when.

Can you add a stack trace in the "clockevents_shutdown" function with
the clockevent device name ? Perhaps, we may see at boot time an
interesting trace when it hangs.



> 	[ 4689.992658] CPU1: Booted secondary processor
> 	[ 4690.986295] CPU1: failed to come online
> 	sh: write error: Input/output error
> 	# [ 4691.045945] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
> 	[ 4691.045986] 
> 	[ 4691.052972] ===============================
> 	[ 4691.057349] [ INFO: suspicious RCU usage. ]
> 	[ 4691.061413] 3.11.0-rc3-00001-gc14f576-dirty #139 Not tainted
> 	[ 4691.067026] -------------------------------
> 	[ 4691.071129] kernel/sched/fair.c:5477 suspicious rcu_dereference_check() usage!
> 	[ 4691.078292] 
> 	[ 4691.078292] other info that might help us debug this:
> 	[ 4691.078292] 
> 	[ 4691.086209] 
> 	[ 4691.086209] RCU used illegally from offline CPU!
> 	[ 4691.086209] rcu_scheduler_active = 1, debug_locks = 0
> 	[ 4691.097216] 1 lock held by swapper/1/0:
> 	[ 4691.100968]  #0:  (rcu_read_lock){.+.+..}, at: [<c00679b4>] set_cpu_sd_state_idle+0x0/0x1e4
> 	[ 4691.109250] 
> 	[ 4691.109250] stack backtrace:
> 	[ 4691.113531] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.0-rc3-00001-gc14f576-dirty #139
> 	[ 4691.121755] [<c0016a88>] (unwind_backtrace+0x0/0x128) from [<c0012d58>] (show_stack+0x20/0x24)
> 	[ 4691.130263] [<c0012d58>] (show_stack+0x20/0x24) from [<c045bd50>] (dump_stack+0x80/0xc4)
> 	[ 4691.138264] [<c045bd50>] (dump_stack+0x80/0xc4) from [<c007ad78>] (lockdep_rcu_suspicious+0xdc/0x118)
> 	[ 4691.147371] [<c007ad78>] (lockdep_rcu_suspicious+0xdc/0x118) from [<c0067ac0>] (set_cpu_sd_state_idle+0x10c/0x1e4)
> 	[ 4691.157605] [<c0067ac0>] (set_cpu_sd_state_idle+0x10c/0x1e4) from [<c0078238>] (tick_nohz_idle_enter+0x48/0x80)
> 	[ 4691.167583] [<c0078238>] (tick_nohz_idle_enter+0x48/0x80) from [<c006dc5c>] (cpu_startup_entry+0x28/0x388)
> 	[ 4691.177127] [<c006dc5c>] (cpu_startup_entry+0x28/0x388) from [<c0014acc>] (secondary_start_kernel+0x12c/0x144)
> 	[ 4691.187013] [<c0014acc>] (secondary_start_kernel+0x12c/0x144) from [<000081ec>] (0x81ec)
> 
> 
> 	S?ren
> 
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From tomasz.figa at gmail.com  Wed Jul 31 19:04:05 2013
From: tomasz.figa at gmail.com (Tomasz Figa)
Date: Thu, 01 Aug 2013 01:04:05 +0200
Subject: Defining schemas for Device Tree
In-Reply-To: <51F977D0.7050200@wwwdotorg.org>
References: <51F6E30B.7060106@wwwdotorg.org>
 <CAKON4OzFdZhX0Kzu_6KiimD=KxDr6EM13zUH3GGE=hHaYx=m=Q@mail.gmail.com>
 <51F977D0.7050200@wwwdotorg.org>
Message-ID: <1940278.JgeAG48RRV@flatron>

On Wednesday 31 of July 2013 14:47:12 Stephen Warren wrote:
> On 07/30/2013 05:23 PM, jonsmirl at gmail.com wrote:
> > On Tue, Jul 30, 2013 at 7:03 PM, Mark Brown <broonie at kernel.org> 
wrote:
> >> On Tue, Jul 30, 2013 at 06:19:08PM -0400, jonsmirl at gmail.com wrote:
> >>> FDT is versioned and PowerPC docs say that multiple versions have
> >>> been
> >>> released.  If we find enough flaws we could do a new release then
> >>> use
> >>> the quirks scheme to read the older versions.
> >> 
> >> That does involve updating everything that wants to understand FDTs
> >> in
> >> the new FDT format version though.  I'm not sure that's going to be
> >> greeted with universal enthusiasm.
> > 
> > Shipped hardware containing FDTs would keep the version they shipped
> > with. That's the point of making this  a stable ABI. The Linux quirk
> > code would convert the older format to the new format at boot time.
> > 
> > So to change this you need to:
> > 1) change dtc to produce the new version
> > 2) adjust the kernel code to understand the new version
> > 3) adjust the quirk code to convert the known set of older firmware
> > based FDTs into the new format. For the simple string case the strings
> > would be turned into indirect pointers instead of being in-line.
> 
> There's one issue issue with the quirk/conversion layer in the kernel.
> 
> Various combinations are supposed to work:
> 
> 1) The "current" kernel with the "current" DTB. I think everyone agrees
> on that much:-)
> 
> 2) Using an old DTB with a new kernel. This could be handled by having
> stable DT bindings, and/or by having a quirk/conversion layer in the
> kernel to convert old DTBs into whatever format the new kernel expects.
> 
> 3) Using a new DTB with a old kernel. Rob Herring raised the point that
> a firmware update (which might include updating the DTB the firmware
> passes to the kernel) should not make the kernel you have installed in
> the filesystem fail to boot.
>
> I'm assuming that if the quirk/conversion layer you're championing were
> the solution chosen for (2), then at least some of the time, people
> would start using the new DT binding when writing new DTs, or modifying
> existing DTs. That would break point (3) above, since the new DT would
> no longer work with the old kernel.
> 
> I think the only way to satisfy all three points above is to have truly
> stable backwards-compatible bindings, without relying on any in-kernel
> conversion layer.

IMHO stable bindings is the way to go. We already managed to keep lot of 
existing bindings stable, see most of the generic bindings. Those got much 
more thought at design stage, much more review and ended up being 
something that could be stabilized.

If we define the process of bindings introduction correctly, we should be 
able to filter out those that won't work as stable thing and stabilize 
those that will. This is why we may need a staging tree for bindings and a 
way to develop such bindings to make them stable at some point of time.

I'm not really sure how Greg's staging tree works, but we might be able to 
get some hints for creating our staging process from him (now on Cc).

Best regards,
Tomasz



From daniel.lezcano at linaro.org  Wed Jul 31 19:16:36 2013
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 01 Aug 2013 01:16:36 +0200
Subject: [PATCH v4 0/5] Memory mapped architected timers
In-Reply-To: <20130731223833.GJ8868@codeaurora.org>
References: <1374191972-18015-1-git-send-email-sboyd@codeaurora.org>
 <20130722170817.GB4833@e106331-lin.cambridge.arm.com>
 <20130724203253.GE27761@codeaurora.org>
 <20130731223833.GJ8868@codeaurora.org>
Message-ID: <51F99AD4.1070009@linaro.org>

On 08/01/2013 12:38 AM, Stephen Boyd wrote:
> On 07/24, Stephen Boyd wrote:
>> On 07/22, Mark Rutland wrote:
>>> Hi Stephen,
>>>
>>> On Fri, Jul 19, 2013 at 12:59:27AM +0100, Stephen Boyd wrote:
>>>> This patchset adds support for memory mapped architected timers. We
>>>> don't have any other global broadcast timer in our system, so we use the
>>>> mmio timer during low power modes. The first patch changes the register
>>>> accessor to an enum per Thomas' request. The second patch is the binding.
>>>> The next two patches lay some groundwork so that the last patch is simpler.
>>>> The final patch adds support for mmio timers.
>>>>
>>>> Patches are based on v3.11-rc1.
>>>
>>> Be aware that as of v3.11-rc2 this doesn't cleanly apply, as the
>>> __cpuinit removal broke the final patch's context in a couple of places.
>>> It would be nice to get rid of the new cpuinit additions too...
>>>
>>> With that cleaned up locally, I've gave this a spin on tc2 and a
>>> Foundation model to test the cp15/system timers, hotplugging CPUs and
>>> running a basic test (`time sleep 5`). That all seems to work.
>>>
>>> Unfortunately I have no way of testing the memory-mapped timer support,
>>> but I trust you've tested that locally.
>>>
>>> For the series:
>>>
>>> Acked-by: Mark Rutland <mark.rutland at arm.com>
>>>
>>
>> Thanks Mark.
>>
>> Daniel, can you pick up these patches please?
>>
> 
> Ping Daniel?

Applied to my tree as 3.12 material

Thanks
  -- Daniel


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From soren.brinkmann at xilinx.com  Wed Jul 31 19:24:59 2013
From: soren.brinkmann at xilinx.com (Soren Brinkmann)
Date: Wed, 31 Jul 2013 16:24:59 -0700
Subject: [PATCH] arm: zynq: dt: Set correct L2 ram latencies
Message-ID: <1375313099-8402-1-git-send-email-soren.brinkmann@xilinx.com>

Signed-off-by: Soren Brinkmann <soren.brinkmann at xilinx.com>
---
 arch/arm/boot/dts/zynq-7000.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 6f54a64..e32b92b 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -41,8 +41,8 @@
 		L2: cache-controller {
 			compatible = "arm,pl310-cache";
 			reg = <0xF8F02000 0x1000>;
-			arm,data-latency = <2 3 2>;
-			arm,tag-latency = <2 3 2>;
+			arm,data-latency = <3 2 2>;
+			arm,tag-latency = <2 2 2>;
 			cache-unified;
 			cache-level = <2>;
 		};
-- 
1.8.3.4



From soren.brinkmann at xilinx.com  Wed Jul 31 19:38:09 2013
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Wed, 31 Jul 2013 16:38:09 -0700
Subject: Enable arm_global_timer for Zynq brakes boot
In-Reply-To: <51F99747.4060901@linaro.org>
References: <20130722201348.GI453@xsjandreislx>
 <0735ab8c-0f80-4b64-b2b2-8d4553482c2a@CO9EHSMHS013.ehs.local>
 <51F66565.7010600@linaro.org>
 <8d56935e-2a20-46c7-b80a-f779572dd839@CO1EHSMHS014.ehs.local>
 <51F77D93.4030505@linaro.org> <51F97842.6050200@linaro.org>
 <068436c6-ff98-428f-8875-bb1c6f86466b@TX2EHSMHS008.ehs.local>
 <51F97CE3.9030306@linaro.org>
 <15e19315-ce88-4d3c-bad9-0a37d9e52f6b@CO1EHSMHS007.ehs.local>
 <51F99747.4060901@linaro.org>
Message-ID: <a48f159a-e88c-42fa-b76b-662302d3a585@AM1EHSMHS003.ehs.local>

On Thu, Aug 01, 2013 at 01:01:27AM +0200, Daniel Lezcano wrote:
> On 08/01/2013 12:18 AM, S??ren Brinkmann wrote:
> > On Wed, Jul 31, 2013 at 11:08:51PM +0200, Daniel Lezcano wrote:
> >> On 07/31/2013 10:58 PM, S??ren Brinkmann wrote:
> >>> On Wed, Jul 31, 2013 at 10:49:06PM +0200, Daniel Lezcano wrote:
> >>>> On 07/31/2013 12:34 AM, S??ren Brinkmann wrote:
> >>>>> On Tue, Jul 30, 2013 at 10:47:15AM +0200, Daniel Lezcano wrote:
> >>>>>> On 07/30/2013 02:03 AM, S??ren Brinkmann wrote:
> >>>>>>> Hi Daniel,
> >>>>>>>
> >>>>>>> On Mon, Jul 29, 2013 at 02:51:49PM +0200, Daniel Lezcano wrote:
> >>>>>>> (snip)
> >>>>>>>>
> >>>>>>>> the CPUIDLE_FLAG_TIMER_STOP flag tells the cpuidle framework the local
> >>>>>>>> timer will be stopped when entering to the idle state. In this case, the
> >>>>>>>> cpuidle framework will call clockevents_notify(ENTER) and switches to a
> >>>>>>>> broadcast timer and will call clockevents_notify(EXIT) when exiting the
> >>>>>>>> idle state, switching the local timer back in use.
> >>>>>>>
> >>>>>>> I've been thinking about this, trying to understand how this makes my
> >>>>>>> boot attempts on Zynq hang. IIUC, the wrongly provided TIMER_STOP flag
> >>>>>>> would make the timer core switch to a broadcast device even though it
> >>>>>>> wouldn't be necessary. But shouldn't it still work? It sounds like we do
> >>>>>>> something useless, but nothing wrong in a sense that it should result in
> >>>>>>> breakage. I guess I'm missing something obvious. This timer system will
> >>>>>>> always remain a mystery to me.
> >>>>>>>
> >>>>>>> Actually this more or less leads to the question: What is this
> >>>>>>> 'broadcast timer'. I guess that is some clockevent device which is
> >>>>>>> common to all cores? (that would be the cadence_ttc for Zynq). Is the
> >>>>>>> hang pointing to some issue with that driver?
> >>>>>>
> >>>>>> If you look at the /proc/timer_list, which timer is used for broadcasting ?
> >>>>>
> >>>>> So, the correct run results (full output attached).
> >>>>>
> >>>>> The vanilla kernel uses the twd timers as local timers and the TTC as
> >>>>> broadcast device:
> >>>>> 	Tick Device: mode:     1                                                         
> >>>>> 	Broadcast device  
> >>>>> 	Clock Event Device: ttc_clockevent
> >>>>>
> >>>>> When I remove the offending CPUIDLE flag and add the DT fragment to
> >>>>> enable the global timer, the twd timers are still used as local timers
> >>>>> and the broadcast device is the global timer:
> >>>>> 	Tick Device: mode:     1                                                         
> >>>>> 	Broadcast device                                                                 
> >>>>> 	Clock Event Device: arm_global_timer
> >>>>>
> >>>>> Again, since boot hangs in the actually broken case, I don't see way to
> >>>>> obtain this information for that case.
> >>>>
> >>>> Can't you use the maxcpus=1 option to ensure the system to boot up ?
> >>>
> >>> Right, that works. I forgot about that option after you mentioned, that
> >>> it is most likely not that useful.
> >>>
> >>> Anyway, this are those sysfs files with an unmodified cpuidle driver and
> >>> the gt enabled and having maxcpus=1 set.
> >>>
> >>> /proc/timer_list:
> >>> 	Tick Device: mode:     1
> >>> 	Broadcast device
> >>> 	Clock Event Device: arm_global_timer
> >>> 	 max_delta_ns:   12884902005
> >>> 	 min_delta_ns:   1000
> >>> 	 mult:           715827876
> >>> 	 shift:          31
> >>> 	 mode:           3
> >>
> >> Here the mode is 3 (CLOCK_EVT_MODE_ONESHOT)
> >>
> >> The previous timer_list output you gave me when removing the offending
> >> cpuidle flag, it was 1 (CLOCK_EVT_MODE_SHUTDOWN).
> >>
> >> Is it possible you try to get this output again right after onlining the
> >> cpu1 in order to check if the broadcast device switches to SHUTDOWN ?
> > 
> > How do I do that? I tried to online CPU1 after booting with maxcpus=1
> > and that didn't end well:
> > 	# echo 1 > online && cat /proc/timer_list 
> 
> Hmm, I was hoping to have a small delay before the kernel hangs but
> apparently this is not the case... :(
> 
> I suspect the global timer is shutdown at one moment but I don't
> understand why and when.
> 
> Can you add a stack trace in the "clockevents_shutdown" function with
> the clockevent device name ? Perhaps, we may see at boot time an
> interesting trace when it hangs.

I did this change:
	diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
	index 38959c8..3ab11c1 100644
	--- a/kernel/time/clockevents.c
	+++ b/kernel/time/clockevents.c
	@@ -92,6 +92,8 @@ void clockevents_set_mode(struct clock_event_device *dev,
	  */
	 void clockevents_shutdown(struct clock_event_device *dev)
	 {
	+       pr_info("ce->name:%s\n", dev->name);
	+       dump_stack();
	        clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN);
	        dev->next_event.tv64 = KTIME_MAX;
	 }

It is hit a few times during boot, so I attach a full boot log. I really
don't know what to look for, but I hope you can spot something in it. I
really appreciate you taking the time.

	Thanks,
	S??ren

-------------- next part --------------


U-Boot 2013.04 (Jun 19 2013 - 08:17:40)

I2C:   ready
Memory: ECC disabled
DRAM:  1 GiB
WARNING: Caches not enabled
MMC:   zynq_sdhci: 0
SF: Detected S25FL129P_64K with page size 128 KiB, total 32 MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   Gem.e000b000
Hit any key to stop autoboot:  3  2  1  0 
TFTPing Linux to RAM...
Gem.e000b000 Waiting for PHY auto negotiation to complete..... done
Using Gem.e000b000 device
TFTP from server 10.10.70.101; our IP address is 10.10.70.102
Filename 'uImage'.
Load address: 0x3000000
Loading: *#################################################################
	 #################################################################
	 ####################################
	 4.2 MiB/s
done
Bytes transferred = 2427120 (2508f0 hex)
Gem.e000b000:7 is connected to Gem.e000b000.  Reconnecting to Gem.e000b000
Gem.e000b000 Waiting for PHY auto negotiation to complete..... done
Using Gem.e000b000 device
TFTP from server 10.10.70.101; our IP address is 10.10.70.102
Filename 'devicetree.dtb'.
Load address: 0x2a00000
Loading: *#
	 672.9 KiB/s
done
Bytes transferred = 2759 (ac7 hex)
Gem.e000b000:7 is connected to Gem.e000b000.  Reconnecting to Gem.e000b000
Gem.e000b000 Waiting for PHY auto negotiation to complete..... done
Using Gem.e000b000 device
TFTP from server 10.10.70.101; our IP address is 10.10.70.102
Filename 'uramdisk.image.gz'.
Load address: 0x2000000
Loading: *#################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 ###################################
	 4.4 MiB/s
done
Bytes transferred = 5284624 (50a310 hex)
## Booting kernel from Legacy Image at 03000000 ...
   Image Name:   Linux-3.11.0-rc3-00001-gc14f576-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2427056 Bytes = 2.3 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 02000000 ...
   Image Name:   
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    5284560 Bytes = 5 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02a00000
   Booting using the fdt blob at 0x02a00000
   Loading Kernel Image ... OK
OK
   Loading Ramdisk to 1faf5000, end 1ffff2d0 ... OK
   Loading Device Tree to 1faf1000, end 1faf4ac6 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0

[    0.000000] Linux version 3.11.0-rc3-00001-gc14f576-dirty (sorenb at xsjandreislx) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-104) ) #144 SMP PREEMPT Wed Jul 31 16:31:16 PDT 2013

[    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d

[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

[    0.000000] Machine: Xilinx Zynq Platform, model: Zynq ZC706 Development Board

[    0.000000] bootconsole [earlycon0] enabled

[    0.000000] cma: CMA: reserved 16 MiB at 2e800000

[    0.000000] Memory policy: ECC disabled, Data cache writealloc

[    0.000000] PERCPU: Embedded 9 pages/cpu @c148e000 s14720 r8192 d13952 u36864

[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260624

[    0.000000] Kernel command line: console=ttyPS0,115200 earlyprintk

[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)

[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)

[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)

[    0.000000] Memory: 1005068K/1048576K available (4849K kernel code, 305K rwdata, 1556K rodata, 334K init, 5699K bss, 43508K reserved, 270336K highmem)

[    0.000000] Virtual kernel memory layout:

[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)

[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)

[    0.000000]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)

[    0.000000]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)

[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)

[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)

[    0.000000]       .text : 0xc0008000 - 0xc0649930   (6407 kB)

[    0.000000]       .init : 0xc064a000 - 0xc069d980   ( 335 kB)

[    0.000000]       .data : 0xc069e000 - 0xc06ea4d8   ( 306 kB)

[    0.000000]        .bss : 0xc06ea4d8 - 0xc0c7b2e4   (5700 kB)

[    0.000000] Preemptible hierarchical RCU implementation.

[    0.000000] 	RCU lockdep checking is enabled.

[    0.000000] 	Additional per-CPU info printed with stalls.

[    0.000000] 	RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.

[    0.000000] NR_IRQS:16 nr_irqs:16 16

[    0.000000] slcr mapped to f0004000

[    0.000000] Zynq clock init

[    0.000000] sched_clock: 32 bits at 333MHz, resolution 3ns, wraps every 12884ms

[    0.000000] ce->name:arm_global_timer

[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.11.0-rc3-00001-gc14f576-dirty #144

[    0.000000] [<c0016a88>] (unwind_backtrace+0x0/0x128) from [<c0012d58>] (show_stack+0x20/0x24)

[    0.000000] [<c0012d58>] (show_stack+0x20/0x24) from [<c045bd70>] (dump_stack+0x80/0xc4)

[    0.000000] [<c045bd70>] (dump_stack+0x80/0xc4) from [<c00754e4>] (clockevents_shutdown+0x28/0x48)

[    0.000000] [<c00754e4>] (clockevents_shutdown+0x28/0x48) from [<c0075840>] (clockevents_exchange_device+0x94/0xb8)

[    0.000000] [<c0075840>] (clockevents_exchange_device+0x94/0xb8) from [<c0075fa0>] (tick_check_new_device+0xc8/0x11c)

[    0.000000] [<c0075fa0>] (tick_check_new_device+0xc8/0x11c) from [<c007510c>] (clockevents_register_device+0xc0/0x134)

[    0.000000] [<c007510c>] (clockevents_register_device+0xc0/0x134) from [<c0075748>] (clockevents_config_and_register+0x2c/0x30)

[    0.000000] [<c0075748>] (clockevents_config_and_register+0x2c/0x30) from [<c0370764>] (gt_clockevents_init+0x8c/0xb4)

[    0.000000] [<c0370764>] (gt_clockevents_init+0x8c/0xb4) from [<c0675d64>] (global_timer_of_register+0x1e4/0x294)

[    0.000000] [<c0675d64>] (global_timer_of_register+0x1e4/0x294) from [<c0675724>] (clocksource_of_init+0x2c/0x54)

[    0.000000] [<c0675724>] (clocksource_of_init+0x2c/0x54) from [<c0652b98>] (zynq_timer_init+0x14/0x18)

[    0.000000] [<c0652b98>] (zynq_timer_init+0x14/0x18) from [<c064dec8>] (time_init+0x24/0x34)

[    0.000000] [<c064dec8>] (time_init+0x24/0x34) from [<c064a774>] (start_kernel+0x1cc/0x32c)

[    0.000000] [<c064a774>] (start_kernel+0x1cc/0x32c) from [<00008074>] (0x8074)

[    0.000000] ce->name:ttc_clockevent

[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.11.0-rc3-00001-gc14f576-dirty #144

[    0.000000] [<c0016a88>] (unwind_backtrace+0x0/0x128) from [<c0012d58>] (show_stack+0x20/0x24)

[    0.000000] [<c0012d58>] (show_stack+0x20/0x24) from [<c045bd70>] (dump_stack+0x80/0xc4)

[    0.000000] [<c045bd70>] (dump_stack+0x80/0xc4) from [<c00754e4>] (clockevents_shutdown+0x28/0x48)

[    0.000000] [<c00754e4>] (clockevents_shutdown+0x28/0x48) from [<c0075840>] (clockevents_exchange_device+0x94/0xb8)

[    0.000000] [<c0075840>] (clockevents_exchange_device+0x94/0xb8) from [<c00766c4>] (tick_install_broadcast_device+0x88/0xcc)

[    0.000000] [<c00766c4>] (tick_install_broadcast_device+0x88/0xcc) from [<c0075fe4>] (tick_check_new_device+0x10c/0x11c)

[    0.000000] [<c0075fe4>] (tick_check_new_device+0x10c/0x11c) from [<c007510c>] (clockevents_register_device+0xc0/0x134)

[    0.000000] [<c007510c>] (clockevents_register_device+0xc0/0x134) from [<c0075748>] (clockevents_config_and_register+0x2c/0x30)

[    0.000000] [<c0075748>] (clockevents_config_and_register+0x2c/0x30) from [<c0675acc>] (ttc_timer_init+0x2d4/0x388)

[    0.000000] [<c0675acc>] (ttc_timer_init+0x2d4/0x388) from [<c0675724>] (clocksource_of_init+0x2c/0x54)

[    0.000000] [<c0675724>] (clocksource_of_init+0x2c/0x54) from [<c0652b98>] (zynq_timer_init+0x14/0x18)

[    0.000000] [<c0652b98>] (zynq_timer_init+0x14/0x18) from [<c064dec8>] (time_init+0x24/0x34)

[    0.000000] [<c064dec8>] (time_init+0x24/0x34) from [<c064a774>] (start_kernel+0x1cc/0x32c)

[    0.000000] [<c064a774>] (start_kernel+0x1cc/0x32c) from [<00008074>] (0x8074)

[    0.000000] ttc0 #0 at f0006000, irq=43

[    0.000000] Console: colour dummy device 80x30

[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar

[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8

[    0.000000] ... MAX_LOCK_DEPTH:          48

[    0.000000] ... MAX_LOCKDEP_KEYS:        8191

[    0.000000] ... CLASSHASH_SIZE:          4096

[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384

[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768

[    0.000000] ... CHAINHASH_SIZE:          16384

[    0.000000]  memory used by lock dependency info: 3695 kB

[    0.000000]  per task-struct memory footprint: 1152 bytes

[    0.347737] Calibrating delay loop... 1325.46 BogoMIPS (lpj=6627328)

[    0.385250] pid_max: default: 32768 minimum: 301

[    0.388286] Mount-cache hash table entries: 512

[    0.399390] CPU: Testing write buffer coherency: ok

[    0.399540] ftrace: allocating 16043 entries in 48 pages

[    0.439854] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000

[    0.440069] ce->name:local_timer

[    0.443330] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc3-00001-gc14f576-dirty #144

[    0.451622] [<c0016a88>] (unwind_backtrace+0x0/0x128) from [<c0012d58>] (show_stack+0x20/0x24)

[    0.460207] [<c0012d58>] (show_stack+0x20/0x24) from [<c045bd70>] (dump_stack+0x80/0xc4)

[    0.468285] [<c045bd70>] (dump_stack+0x80/0xc4) from [<c00754e4>] (clockevents_shutdown+0x28/0x48)

[    0.477224] [<c00754e4>] (clockevents_shutdown+0x28/0x48) from [<c0075840>] (clockevents_exchange_device+0x94/0xb8)

[    0.487628] [<c0075840>] (clockevents_exchange_device+0x94/0xb8) from [<c0075fa0>] (tick_check_new_device+0xc8/0x11c)

[    0.498206] [<c0075fa0>] (tick_check_new_device+0xc8/0x11c) from [<c007510c>] (clockevents_register_device+0xc0/0x134)

[    0.508870] [<c007510c>] (clockevents_register_device+0xc0/0x134) from [<c0075748>] (clockevents_config_and_register+0x2c/0x30)

[    0.520307] [<c0075748>] (clockevents_config_and_register+0x2c/0x30) from [<c001585c>] (twd_timer_setup+0x1bc/0x1fc)

[    0.530798] [<c001585c>] (twd_timer_setup+0x1bc/0x1fc) from [<c00146a0>] (percpu_timer_setup+0xa4/0xc8)

[    0.540184] [<c00146a0>] (percpu_timer_setup+0xa4/0xc8) from [<c064e804>] (smp_prepare_cpus+0x58/0x84)

[    0.549464] [<c064e804>] (smp_prepare_cpus+0x58/0x84) from [<c064a934>] (kernel_init_freeable+0x60/0x1d0)

[    0.559008] [<c064a934>] (kernel_init_freeable+0x60/0x1d0) from [<c04562d4>] (kernel_init+0x1c/0xf4)

[    0.568124] [<c04562d4>] (kernel_init+0x1c/0xf4) from [<c000efc8>] (ret_from_fork+0x14/0x20)

[    0.576545] ce->name:ttc_clockevent

[    0.580068] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc3-00001-gc14f576-dirty #144

[    0.588341] [<c0016a88>] (unwind_backtrace+0x0/0x128) from [<c0012d58>] (show_stack+0x20/0x24)

[    0.596937] [<c0012d58>] (show_stack+0x20/0x24) from [<c045bd70>] (dump_stack+0x80/0xc4)

[    0.605019] [<c045bd70>] (dump_stack+0x80/0xc4) from [<c00754e4>] (clockevents_shutdown+0x28/0x48)

[    0.613964] [<c00754e4>] (clockevents_shutdown+0x28/0x48) from [<c00770dc>] (tick_device_uses_broadcast+0x198/0x1e4)

[    0.624453] [<c00770dc>] (tick_device_uses_broadcast+0x198/0x1e4) from [<c0075db8>] (tick_setup_device+0xb8/0x100)

[    0.634773] [<c0075db8>] (tick_setup_device+0xb8/0x100) from [<c0075fc8>] (tick_check_new_device+0xf0/0x11c)

[    0.644577] [<c0075fc8>] (tick_check_new_device+0xf0/0x11c) from [<c007510c>] (clockevents_register_device+0xc0/0x134)

[    0.655241] [<c007510c>] (clockevents_register_device+0xc0/0x134) from [<c0075748>] (clockevents_config_and_register+0x2c/0x30)

[    0.666679] [<c0075748>] (clockevents_config_and_register+0x2c/0x30) from [<c001585c>] (twd_timer_setup+0x1bc/0x1fc)

[    0.677169] [<c001585c>] (twd_timer_setup+0x1bc/0x1fc) from [<c00146a0>] (percpu_timer_setup+0xa4/0xc8)

[    0.686549] [<c00146a0>] (percpu_timer_setup+0xa4/0xc8) from [<c064e804>] (smp_prepare_cpus+0x58/0x84)

[    0.695833] [<c064e804>] (smp_prepare_cpus+0x58/0x84) from [<c064a934>] (kernel_init_freeable+0x60/0x1d0)

[    0.705377] [<c064a934>] (kernel_init_freeable+0x60/0x1d0) from [<c04562d4>] (kernel_init+0x1c/0xf4)

[    0.714495] [<c04562d4>] (kernel_init+0x1c/0xf4) from [<c000efc8>] (ret_from_fork+0x14/0x20)

[    0.722917] ce->name:arm_global_timer

[    0.726612] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc3-00001-gc14f576-dirty #144

[    0.734881] [<c0016a88>] (unwind_backtrace+0x0/0x128) from [<c0012d58>] (show_stack+0x20/0x24)

[    0.743479] [<c0012d58>] (show_stack+0x20/0x24) from [<c045bd70>] (dump_stack+0x80/0xc4)

[    0.751563] [<c045bd70>] (dump_stack+0x80/0xc4) from [<c00754e4>] (clockevents_shutdown+0x28/0x48)

[    0.760503] [<c00754e4>] (clockevents_shutdown+0x28/0x48) from [<c0075840>] (clockevents_exchange_device+0x94/0xb8)

[    0.770912] [<c0075840>] (clockevents_exchange_device+0x94/0xb8) from [<c00766c4>] (tick_install_broadcast_device+0x88/0xcc)

[    0.782091] [<c00766c4>] (tick_install_broadcast_device+0x88/0xcc) from [<c0075fe4>] (tick_check_new_device+0x10c/0x11c)

[    0.792926] [<c0075fe4>] (tick_check_new_device+0x10c/0x11c) from [<c007514c>] (clockevents_register_device+0x100/0x134)

[    0.803762] [<c007514c>] (clockevents_register_device+0x100/0x134) from [<c0075748>] (clockevents_config_and_register+0x2c/0x30)

[    0.815286] [<c0075748>] (clockevents_config_and_register+0x2c/0x30) from [<c001585c>] (twd_timer_setup+0x1bc/0x1fc)

[    0.825777] [<c001585c>] (twd_timer_setup+0x1bc/0x1fc) from [<c00146a0>] (percpu_timer_setup+0xa4/0xc8)

[    0.835156] [<c00146a0>] (percpu_timer_setup+0xa4/0xc8) from [<c064e804>] (smp_prepare_cpus+0x58/0x84)

[    0.844441] [<c064e804>] (smp_prepare_cpus+0x58/0x84) from [<c064a934>] (kernel_init_freeable+0x60/0x1d0)

[    0.853986] [<c064a934>] (kernel_init_freeable+0x60/0x1d0) from [<c04562d4>] (kernel_init+0x1c/0xf4)

[    0.863102] [<c04562d4>] (kernel_init+0x1c/0xf4) from [<c000efc8>] (ret_from_fork+0x14/0x20)

[    0.871662] Setting up static identity map for 0xc0462780 - 0xc04627d8

[    0.935967] CPU1: Booted secondary processor

[    0.936001] ce->name:arm_global_timer

[    0.936015] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.0-rc3-00001-gc14f576-dirty #144

[    0.936063] [<c0016a88>] (unwind_backtrace+0x0/0x128) from [<c0012d58>] (show_stack+0x20/0x24)

[    0.936093] [<c0012d58>] (show_stack+0x20/0x24) from [<c045bd70>] (dump_stack+0x80/0xc4)

[    0.936120] [<c045bd70>] (dump_stack+0x80/0xc4) from [<c00754e4>] (clockevents_shutdown+0x28/0x48)

[    0.936140] [<c00754e4>] (clockevents_shutdown+0x28/0x48) from [<c0075840>] (clockevents_exchange_device+0x94/0xb8)

[    0.936160] [<c0075840>] (clockevents_exchange_device+0x94/0xb8) from [<c0075fa0>] (tick_check_new_device+0xc8/0x11c)

[    0.936180] [<c0075fa0>] (tick_check_new_device+0xc8/0x11c) from [<c007510c>] (clockevents_register_device+0xc0/0x134)

[    0.936199] [<c007510c>] (clockevents_register_device+0xc0/0x134) from [<c0075748>] (clockevents_config_and_register+0x2c/0x30)

[    0.936227] [<c0075748>] (clockevents_config_and_register+0x2c/0x30) from [<c0370764>] (gt_clockevents_init+0x8c/0xb4)

[    0.936247] [<c0370764>] (gt_clockevents_init+0x8c/0xb4) from [<c03708e8>] (gt_cpu_notify+0x3c/0x68)

[    0.936278] [<c03708e8>] (gt_cpu_notify+0x3c/0x68) from [<c00552e4>] (notifier_call_chain+0xd8/0x110)

[    0.936301] [<c00552e4>] (notifier_call_chain+0xd8/0x110) from [<c0055340>] (__raw_notifier_call_chain+0x24/0x2c)

[    0.936321] [<c0055340>] (__raw_notifier_call_chain+0x24/0x2c) from [<c002758c>] (__cpu_notify+0x3c/0x58)

[    0.936337] [<c002758c>] (__cpu_notify+0x3c/0x58) from [<c00275c8>] (cpu_notify+0x20/0x24)

[    0.936354] [<c00275c8>] (cpu_notify+0x20/0x24) from [<c0027dd0>] (notify_cpu_starting+0x58/0x60)

[    0.936373] [<c0027dd0>] (notify_cpu_starting+0x58/0x60) from [<c0014a94>] (secondary_start_kernel+0xf4/0x144)

[    0.936390] [<c0014a94>] (secondary_start_kernel+0xf4/0x144) from [<000081ec>] (0x81ec)

[    0.936404] ce->name:arm_global_timer

[    0.936415] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.0-rc3-00001-gc14f576-dirty #144

[    0.936441] [<c0016a88>] (unwind_backtrace+0x0/0x128) from [<c0012d58>] (show_stack+0x20/0x24)

[    0.936464] [<c0012d58>] (show_stack+0x20/0x24) from [<c045bd70>] (dump_stack+0x80/0xc4)

[    0.936486] [<c045bd70>] (dump_stack+0x80/0xc4) from [<c00754e4>] (clockevents_shutdown+0x28/0x48)

[    0.936507] [<c00754e4>] (clockevents_shutdown+0x28/0x48) from [<c00770dc>] (tick_device_uses_broadcast+0x198/0x1e4)

[    0.936526] [<c00770dc>] (tick_device_uses_broadcast+0x198/0x1e4) from [<c0075db8>] (tick_setup_device+0xb8/0x100)

[    0.936545] [<c0075db8>] (tick_setup_device+0xb8/0x100) from [<c0075fc8>] (tick_check_new_device+0xf0/0x11c)

[    0.936564] [<c0075fc8>] (tick_check_new_device+0xf0/0x11c) from [<c007510c>] (clockevents_register_device+0xc0/0x134)

[    0.936584] [<c007510c>] (clockevents_register_device+0xc0/0x134) from [<c0075748>] (clockevents_config_and_register+0x2c/0x30)

[    0.936608] [<c0075748>] (clockevents_config_and_register+0x2c/0x30) from [<c0370764>] (gt_clockevents_init+0x8c/0xb4)

[    0.936627] [<c0370764>] (gt_clockevents_init+0x8c/0xb4) from [<c03708e8>] (gt_cpu_notify+0x3c/0x68)

[    0.936652] [<c03708e8>] (gt_cpu_notify+0x3c/0x68) from [<c00552e4>] (notifier_call_chain+0xd8/0x110)

[    0.936673] [<c00552e4>] (notifier_call_chain+0xd8/0x110) from [<c0055340>] (__raw_notifier_call_chain+0x24/0x2c)

[    0.936692] [<c0055340>] (__raw_notifier_call_chain+0x24/0x2c) from [<c002758c>] (__cpu_notify+0x3c/0x58)

[    0.936708] [<c002758c>] (__cpu_notify+0x3c/0x58) from [<c00275c8>] (cpu_notify+0x20/0x24)

[    0.936725] [<c00275c8>] (cpu_notify+0x20/0x24) from [<c0027dd0>] (notify_cpu_starting+0x58/0x60)

[    0.936744] [<c0027dd0>] (notify_cpu_starting+0x58/0x60) from [<c0014a94>] (secondary_start_kernel+0xf4/0x144)

[    0.936760] [<c0014a94>] (secondary_start_kernel+0xf4/0x144) from [<000081ec>] (0x81ec)

[    1.022967] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001

[    1.023071] ce->name:local_timer

[    1.024254] Brought up 2 CPUs

[    1.024267] SMP: Total of 2 processors activated (2657.48 BogoMIPS).

[    1.024272] CPU: All CPU(s) started in SVC mode.

[    1.383534] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.0-rc3-00001-gc14f576-dirty #144

[    1.391814] [<c0016a88>] (unwind_backtrace+0x0/0x128) from [<c0012d58>] (show_stack+0x20/0x24)

[    1.400405] [<c0012d58>] (show_stack+0x20/0x24) from [<c045bd70>] (dump_stack+0x80/0xc4)

[    1.408485] [<c045bd70>] (dump_stack+0x80/0xc4) from [<c00754e4>] (clockevents_shutdown+0x28/0x48)

[    1.417425] [<c00754e4>] (clockevents_shutdown+0x28/0x48) from [<c0075840>] (clockevents_exchange_device+0x94/0xb8)

[    1.427831] [<c0075840>] (clockevents_exchange_device+0x94/0xb8) from [<c0075fa0>] (tick_check_new_device+0xc8/0x11c)

[    1.438410] [<c0075fa0>] (tick_check_new_device+0xc8/0x11c) from [<c007510c>] (clockevents_register_device+0xc0/0x134)

[    1.449073] [<c007510c>] (clockevents_register_device+0xc0/0x134) from [<c0075748>] (clockevents_config_and_register+0x2c/0x30)

[    1.460511] [<c0075748>] (clockevents_config_and_register+0x2c/0x30) from [<c001585c>] (twd_timer_setup+0x1bc/0x1fc)

[    1.471003] [<c001585c>] (twd_timer_setup+0x1bc/0x1fc) from [<c00146a0>] (percpu_timer_setup+0xa4/0xc8)

[    1.480375] [<c00146a0>] (percpu_timer_setup+0xa4/0xc8) from [<c0014ab8>] (secondary_start_kernel+0x118/0x144)

[    1.490350] [<c0014ab8>] (secondary_start_kernel+0x118/0x144) from [<000081ec>] (0x81ec)

[    1.498430] ce->name:arm_global_timer

[    1.502125] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.0-rc3-00001-gc14f576-dirty #144

[    1.510397] [<c0016a88>] (unwind_backtrace+0x0/0x128) from [<c0012d58>] (show_stack+0x20/0x24)

[    1.518993] [<c0012d58>] (show_stack+0x20/0x24) from [<c045bd70>] (dump_stack+0x80/0xc4)

[    1.527077] [<c045bd70>] (dump_stack+0x80/0xc4) from [<c00754e4>] (clockevents_shutdown+0x28/0x48)

[    1.536020] [<c00754e4>] (clockevents_shutdown+0x28/0x48) from [<c00770dc>] (tick_device_uses_broadcast+0x198/0x1e4)

[    1.546511] [<c00770dc>] (tick_device_uses_broadcast+0x198/0x1e4) from [<c0075db8>] (tick_setup_device+0xb8/0x100)

[    1.556829] [<c0075db8>] (tick_setup_device+0xb8/0x100) from [<c0075fc8>] (tick_check_new_device+0xf0/0x11c)

[    1.566634] [<c0075fc8>] (tick_check_new_device+0xf0/0x11c) from [<c007510c>] (clockevents_register_device+0xc0/0x134)

[    1.577299] [<c007510c>] (clockevents_register_device+0xc0/0x134) from [<c0075748>] (clockevents_config_and_register+0x2c/0x30)

[    1.588737] [<c0075748>] (clockevents_config_and_register+0x2c/0x30) from [<c001585c>] (twd_timer_setup+0x1bc/0x1fc)

[    1.599227] [<c001585c>] (twd_timer_setup+0x1bc/0x1fc) from [<c00146a0>] (percpu_timer_setup+0xa4/0xc8)

[    1.608600] [<c00146a0>] (percpu_timer_setup+0xa4/0xc8) from [<c0014ab8>] (secondary_start_kernel+0x118/0x144)

[    1.618576] [<c0014ab8>] (secondary_start_kernel+0x118/0x144) from [<000081ec>] (0x81ec)

[    1.630233] devtmpfs: initialized

[    1.648505] NET: Registered protocol family 16

[    1.654412] DMA: preallocated 256 KiB pool for atomic coherent allocations

[    1.667327] L310 cache controller enabled

[    1.667364] l2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72360000, Cache size: 524288 B

[    1.681910] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.

[    1.684424] hw-breakpoint: maximum watchpoint size is 4 bytes.

[    1.763691] bio: create slab <bio-0> at 0

[    1.768952] SCSI subsystem initialized

[    1.771737] usbcore: registered new interface driver usbfs

[    1.773326] usbcore: registered new interface driver hub

[    1.778916] usbcore: registered new device driver usb

[    1.793685] Switched to clocksource arm_global_timer

[    1.968760] NET: Registered protocol family 2

[    1.974238] TCP established hash table entries: 8192 (order: 4, 65536 bytes)

[    1.976164] TCP bind hash table entries: 8192 (order: 6, 294912 bytes)

[    1.986656] TCP: Hash tables configured (established 8192 bind 8192)

[    1.989016] TCP: reno registered

[    1.992002] UDP hash table entries: 512 (order: 3, 40960 bytes)

[    1.998476] UDP-Lite hash table entries: 512 (order: 3, 40960 bytes)

[    2.006030] NET: Registered protocol family 1

[    2.010481] RPC: Registered named UNIX socket transport module.

[    2.014689] RPC: Registered udp transport module.

[    2.019326] RPC: Registered tcp transport module.

[    2.024133] RPC: Registered tcp NFSv4.1 backchannel transport module.

[    2.031730] Trying to unpack rootfs image as initramfs...

[    2.854186] Freeing initrd memory: 5160K (dfaf5000 - dffff000)

[    2.867362] bounce pool size: 64 pages

[    2.871434] jffs2: version 2.2. (NAND) (SUMMARY)  ?? 2001-2006 Red Hat, Inc.

[    2.873772] msgmni has been set to 1477

[    2.897430] io scheduler noop registered

[    2.897463] io scheduler deadline registered

[    2.900325] io scheduler cfq registered (default)

[    2.915035] e000?[    2.917021] console [ttyPS0] enabled, bootconsole disabled
[    2.917021] console [ttyPS0] enabled, bootconsole disabled

[    2.961088] brd: module loaded
[    2.985608] loop: module loaded
[    3.007560] usbcore: registered new interface driver usb-storage
[    3.015956] mousedev: PS/2 mouse device common for all mice
[    3.024029] i2c /dev entries driver
[    3.031288] cpuidle: using governor ladder
[    3.035357] cpuidle: using governor menu
[    3.039170] Xilinx Zynq CpuIdle Driver started
[    3.044929] sdhci: Secure Digital Host Controller Interface driver
[    3.050969] sdhci: Copyright(c) Pierre Ossman
[    3.055475] sdhci-pltfm: SDHCI platform and OF driver helper
[    3.063301] usbcore: registered new interface driver usbhid
[    3.068990] usbhid: USB HID core driver
[    3.073385] TCP: cubic registered
[    3.076686] NET: Registered protocol family 17
[    3.081129] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[    3.088817] Registering SWP/SWPB emulation handler
[    3.098336] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    3.138029] Freeing unused kernel memory: 332K (c064a000 - c069d000)

Welcome to [1mBuildroot 2013.08-git[0m!



From timur at tabi.org  Wed Jul 31 19:44:58 2013
From: timur at tabi.org (Timur Tabi)
Date: Wed, 31 Jul 2013 18:44:58 -0500
Subject: [PATCH 2/2] Convert PowerPC macro spin_event_timeout() to
 architecture independent macro
In-Reply-To: <20130731071630.GI8868@codeaurora.org>
References: <1375187900-17582-1-git-send-email-B44344@freescale.com>
 <1375187900-17582-3-git-send-email-B44344@freescale.com>
 <20130731071630.GI8868@codeaurora.org>
Message-ID: <CAOZdJXVvNBR-qf7LXNOHZVstH_Rebxwn-wAkSaBS53Wn55mYCw@mail.gmail.com>

On Wed, Jul 31, 2013 at 2:16 AM, Stephen Boyd <sboyd at codeaurora.org> wrote:
>
> What do you do here if jiffies aren't incrementing (i.e
> interrupts are disabled). The time_before() check won't work
> there and it would be nice if we were able to use this in such
> situations. I think powerpc gets around this by reading the
> hardware timer directly?

I believe that jiffies is always a global variable.  It should behave
the same on PowerPC as on other architectures.

The answer to your question is that you should not use
spin_event_timeout() in interrupt context, because it yields.

(FYI, I'm the author of spin_event_timeout(), so please CC: me on all
changes to it)


From timur at tabi.org  Wed Jul 31 20:02:12 2013
From: timur at tabi.org (Timur Tabi)
Date: Wed, 31 Jul 2013 19:02:12 -0500
Subject: [PATCH 2/2] Convert PowerPC macro spin_event_timeout() to
 architecture independent macro
In-Reply-To: <1375187900-17582-3-git-send-email-B44344@freescale.com>
References: <1375187900-17582-1-git-send-email-B44344@freescale.com>
 <1375187900-17582-3-git-send-email-B44344@freescale.com>
Message-ID: <CAOZdJXW8uF_e2nQr3gAiMf4E5pvsH_S-ztAXvx9R7-nXyaZGag@mail.gmail.com>

On Tue, Jul 30, 2013 at 7:38 AM, Arpit Goel <B44344 at freescale.com> wrote:
>
> +#ifndef spin_event_timeout
> +/**


Why don't you make PowerPC also use this generic version?  It seems
silly to have two virtually identical implementations of this macro?


From sboyd at codeaurora.org  Wed Jul 31 20:04:14 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 17:04:14 -0700
Subject: [PATCH 2/2] Convert PowerPC macro spin_event_timeout() to
 architecture independent macro
In-Reply-To: <CAOZdJXVvNBR-qf7LXNOHZVstH_Rebxwn-wAkSaBS53Wn55mYCw@mail.gmail.com>
References: <1375187900-17582-1-git-send-email-B44344@freescale.com>
 <1375187900-17582-3-git-send-email-B44344@freescale.com>
 <20130731071630.GI8868@codeaurora.org>
 <CAOZdJXVvNBR-qf7LXNOHZVstH_Rebxwn-wAkSaBS53Wn55mYCw@mail.gmail.com>
Message-ID: <51F9A5FE.8030608@codeaurora.org>

On 07/31/13 16:44, Timur Tabi wrote:
> On Wed, Jul 31, 2013 at 2:16 AM, Stephen Boyd <sboyd at codeaurora.org> wrote:
>> What do you do here if jiffies aren't incrementing (i.e
>> interrupts are disabled). The time_before() check won't work
>> there and it would be nice if we were able to use this in such
>> situations. I think powerpc gets around this by reading the
>> hardware timer directly?
> I believe that jiffies is always a global variable.  It should behave
> the same on PowerPC as on other architectures.

Yes it's global but it doesn't increment while interrupts are off.

>
> The answer to your question is that you should not use
> spin_event_timeout() in interrupt context, because it yields.
>

If it yields why are we using udelay? Why not usleep_range()? It would
be useful to have a variant that worked in interrupt context and it
looked like that was almost possible.

BTW, couldn't we skip the first patch and just use usecs_to_jiffies()?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From davem at davemloft.net  Wed Jul 31 20:04:46 2013
From: davem at davemloft.net (David Miller)
Date: Wed, 31 Jul 2013 17:04:46 -0700 (PDT)
Subject: [PATCH v3] net: Add MOXA ART SoCs ethernet driver
In-Reply-To: <1375296998.5729.8.camel@joe-AO722>
References: <1374842890-20735-1-git-send-email-jonas.jensen@gmail.com>
 <1375280401-5564-1-git-send-email-jonas.jensen@gmail.com>
 <1375296998.5729.8.camel@joe-AO722>
Message-ID: <20130731.170446.1534643901297918794.davem@davemloft.net>

From: Joe Perches <joe at perches.com>
Date: Wed, 31 Jul 2013 11:56:38 -0700

>> +		if (ui & (RX_ERR | CRC_ERR | FTL | RUNT | RX_ODD_NB)) {
>> +			netdev_err(ndev, "packet error\n");
> 
> This is generally a bad idea as it can flood
> the log.  It's probably better to remove it.
> If you really want logging, then at least use
> net_ratelimit().  Generally, the stats are
> enough.
 ...
>> +			priv->stats.rx_dropped++;
>> +			priv->stats.rx_errors++;
> []
>> +static int moxart_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> []
>> +	if (txdesc->txdes0.ubit.tx_dma_own) {
>> +		netdev_err(ndev, "no TX space for packet\n");
>> +		priv->stats.tx_dropped++;
> 
> here too.

Agreed, these should not be logged, the statistics are sufficient.


From timur at tabi.org  Wed Jul 31 20:13:02 2013
From: timur at tabi.org (Timur Tabi)
Date: Wed, 31 Jul 2013 19:13:02 -0500
Subject: [PATCH 2/2] Convert PowerPC macro spin_event_timeout() to
 architecture independent macro
In-Reply-To: <51F9A5FE.8030608@codeaurora.org>
References: <1375187900-17582-1-git-send-email-B44344@freescale.com>
 <1375187900-17582-3-git-send-email-B44344@freescale.com>
 <20130731071630.GI8868@codeaurora.org>
 <CAOZdJXVvNBR-qf7LXNOHZVstH_Rebxwn-wAkSaBS53Wn55mYCw@mail.gmail.com>
 <51F9A5FE.8030608@codeaurora.org>
Message-ID: <51F9A80E.5010307@tabi.org>

On 07/31/2013 07:04 PM, Stephen Boyd wrote:
> If it yields why are we using udelay? Why not usleep_range()? It would
> be useful to have a variant that worked in interrupt context and it
> looked like that was almost possible.

I've never heard of usleep_range() before, so I don't know if it
applies.  Apparently, udelay() includes its own call to cpu_relax().  Is
it possible that cpu_relax() is a "lightweight" yield, compared to sleeping?

FYI, you might want to look at the code reviews for spin_event_timeout()
on the linuxppc-dev mailing list, back in March 2009.

-- 
-- 
Timur Tabi


From sboyd at codeaurora.org  Wed Jul 31 20:16:49 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 17:16:49 -0700
Subject: [PATCH 2/2] Convert PowerPC macro spin_event_timeout() to
 architecture independent macro
In-Reply-To: <51F9A80E.5010307@tabi.org>
References: <1375187900-17582-1-git-send-email-B44344@freescale.com>
 <1375187900-17582-3-git-send-email-B44344@freescale.com>
 <20130731071630.GI8868@codeaurora.org>
 <CAOZdJXVvNBR-qf7LXNOHZVstH_Rebxwn-wAkSaBS53Wn55mYCw@mail.gmail.com>
 <51F9A5FE.8030608@codeaurora.org> <51F9A80E.5010307@tabi.org>
Message-ID: <51F9A8F1.9020704@codeaurora.org>

On 07/31/13 17:13, Timur Tabi wrote:
> On 07/31/2013 07:04 PM, Stephen Boyd wrote:
>> If it yields why are we using udelay? Why not usleep_range()? It would
>> be useful to have a variant that worked in interrupt context and it
>> looked like that was almost possible.
> I've never heard of usleep_range() before, so I don't know if it
> applies.  Apparently, udelay() includes its own call to cpu_relax().  Is
> it possible that cpu_relax() is a "lightweight" yield, compared to sleeping?

cpu_relax() is usually just a compiler barrier or an instruction hint to
the cpu that it should cool down because we're spinning in a tight loop.
It certainly shouldn't be calling into the  scheduler.

>
> FYI, you might want to look at the code reviews for spin_event_timeout()
> on the linuxppc-dev mailing list, back in March 2009.
>

Sure. Any pointers? Otherwise I'll go digging around the archives.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From timur at tabi.org  Wed Jul 31 20:20:29 2013
From: timur at tabi.org (Timur Tabi)
Date: Wed, 31 Jul 2013 19:20:29 -0500
Subject: [PATCH 2/2] Convert PowerPC macro spin_event_timeout() to
 architecture independent macro
In-Reply-To: <51F9A8F1.9020704@codeaurora.org>
References: <1375187900-17582-1-git-send-email-B44344@freescale.com>
 <1375187900-17582-3-git-send-email-B44344@freescale.com>
 <20130731071630.GI8868@codeaurora.org>
 <CAOZdJXVvNBR-qf7LXNOHZVstH_Rebxwn-wAkSaBS53Wn55mYCw@mail.gmail.com>
 <51F9A5FE.8030608@codeaurora.org> <51F9A80E.5010307@tabi.org>
 <51F9A8F1.9020704@codeaurora.org>
Message-ID: <51F9A9CD.1040804@tabi.org>

On 07/31/2013 07:16 PM, Stephen Boyd wrote:
> cpu_relax() is usually just a compiler barrier or an instruction hint to
> the cpu that it should cool down because we're spinning in a tight loop.
> It certainly shouldn't be calling into the  scheduler.

Ah yes, I remember now.  So it does seem that if we can fix the problem
of non-incrementing 'jiffies', then this macro can be used in interrupts.

Of course, that assumes that spinning in interrupt context is a good
idea to begin with.  Maybe we shouldn't be encouraging it?

>> > FYI, you might want to look at the code reviews for spin_event_timeout()
>> > on the linuxppc-dev mailing list, back in March 2009.
>> >
> Sure. Any pointers? Otherwise I'll go digging around the archives.

https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-March/thread.html

-- 
Timur Tabi


From jason at lakedaemon.net  Wed Jul 31 20:31:05 2013
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 31 Jul 2013 20:31:05 -0400
Subject: [PATCH 16/18] ARM: orion: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-17-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
 <1375309877-16617-17-git-send-email-sboyd@codeaurora.org>
Message-ID: <20130801003105.GU5882@titan.lakedaemon.net>

On Wed, Jul 31, 2013 at 03:31:15PM -0700, Stephen Boyd wrote:
> The 32 bit sched_clock interface now supports 64 bits. Upgrade to
> the 64 bit function to allow us to remove the 32 bit registration
> interface.
> 
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Andrew Lunn <andrew at lunn.ch>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  arch/arm/plat-orion/time.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Acked-by: Jason Cooper <jason at lakedaemon.net>

thx,

Jason.


From konrad.wilk at oracle.com  Wed Jul 31 20:32:54 2013
From: konrad.wilk at oracle.com (Konrad Rzeszutek Wilk)
Date: Wed, 31 Jul 2013 20:32:54 -0400
Subject: [PATCH RFC 1/8] arm: make SWIOTLB available
In-Reply-To: <1375292732-7627-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
 <1375292732-7627-1-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <334c4fe7-e40c-489c-84db-9bb58c705d44@email.android.com>

Stefano Stabellini <stefano.stabellini at eu.citrix.com> wrote:
>Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
>CC: will.deacon at arm.com
>CC: linux at arm.linux.org.uk
>---
> arch/arm/Kconfig                   |    7 +++++++
> arch/arm/include/asm/dma-mapping.h |   24 ++++++++++++++++++++++++
> 2 files changed, 31 insertions(+), 0 deletions(-)
>
>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>index ba412e0..05125ab 100644
>--- a/arch/arm/Kconfig
>+++ b/arch/arm/Kconfig
>@@ -1832,6 +1832,13 @@ config CC_STACKPROTECTOR
> 	  neutralized via a kernel panic.
> 	  This feature requires gcc version 4.2 or above.
> 
>+config SWIOTLB
>+	def_bool y
>+	select NEED_SG_DMA_LENGTH
>+
>+config IOMMU_HELPER
>+	def_bool SWIOTLB
>+

Could you explain the purpose of these two a bit more please? 

> config XEN_DOM0
> 	def_bool y
> 	depends on XEN
>diff --git a/arch/arm/include/asm/dma-mapping.h
>b/arch/arm/include/asm/dma-mapping.h
>index 5b579b9..ad89e0f 100644
>--- a/arch/arm/include/asm/dma-mapping.h
>+++ b/arch/arm/include/asm/dma-mapping.h
>@@ -86,6 +86,30 @@ static inline dma_addr_t virt_to_dma(struct device
>*dev, void *addr)
> }
> #endif
> 
>+static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t
>paddr)
>+{
>+	unsigned int offset = paddr & ~PAGE_MASK;
>+	return pfn_to_dma(dev, paddr >> PAGE_SHIFT) + offset;
>+}
>+
>+static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t
>dev_addr)
>+{
>+	unsigned int offset = dev_addr & ~PAGE_MASK;
>+	return (dma_to_pfn(dev, dev_addr) << PAGE_SHIFT) + offset;
>+}
>+
>+static inline bool dma_capable(struct device *dev, dma_addr_t addr,
>size_t size)
>+{
>+	if (!dev->dma_mask)
>+		return 0;
>+
>+	return addr + size - 1 <= *dev->dma_mask;
>+}
>+
>+static inline void dma_mark_clean(void *addr, size_t size)
>+{
>+}
>+
> /*
>  * DMA errors are defined by all-bits-set in the DMA address.
>  */




From konrad.wilk at oracle.com  Wed Jul 31 20:35:32 2013
From: konrad.wilk at oracle.com (Konrad Rzeszutek Wilk)
Date: Wed, 31 Jul 2013 20:35:32 -0400
Subject: [PATCH RFC 4/8] xen/arm,arm64: move Xen initialization earlier
In-Reply-To: <1375292732-7627-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
 <1375292732-7627-4-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <dc5fc8ce-2248-443c-87c5-6bd3c0c259b2@email.android.com>

Stefano Stabellini <stefano.stabellini at eu.citrix.com> wrote:
>Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
>---
> arch/arm/include/asm/xen/hypervisor.h |    6 ++++++
> arch/arm/kernel/setup.c               |    2 ++
> arch/arm/xen/enlighten.c              |   21 ++++++++++++++-------
> arch/arm64/kernel/setup.c             |    2 ++
> 4 files changed, 24 insertions(+), 7 deletions(-)
>
>diff --git a/arch/arm/include/asm/xen/hypervisor.h
>b/arch/arm/include/asm/xen/hypervisor.h
>index d7ab99a..17b3ea2 100644
>--- a/arch/arm/include/asm/xen/hypervisor.h
>+++ b/arch/arm/include/asm/xen/hypervisor.h
>@@ -16,4 +16,10 @@ static inline enum paravirt_lazy_mode
>paravirt_get_lazy_mode(void)
> 	return PARAVIRT_LAZY_NONE;
> }
> 
>+#ifdef CONFIG_XEN
>+void xen_early_init(void);

You look to be missing an __init here
>+#else
>+static inline void xen_early_init(void) { return; }
>+#endif
>+
> #endif /* _ASM_ARM_XEN_HYPERVISOR_H */
>diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>index 63af9a7..cb7b8e2 100644
>--- a/arch/arm/kernel/setup.c
>+++ b/arch/arm/kernel/setup.c
>@@ -45,6 +45,7 @@
> #include <asm/cacheflush.h>
> #include <asm/cachetype.h>
> #include <asm/tlbflush.h>
>+#include <asm/xen/hypervisor.h>
> 
> #include <asm/prom.h>
> #include <asm/mach/arch.h>
>@@ -889,6 +890,7 @@ void __init setup_arch(char **cmdline_p)
> 
> 	arm_dt_init_cpu_maps();
> 	psci_init();
>+	xen_early_init();
> #ifdef CONFIG_SMP
> 	if (is_smp()) {
> 		if (!mdesc->smp_init || !mdesc->smp_init()) {
>diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>index c9770ba..14d17ab 100644
>--- a/arch/arm/xen/enlighten.c
>+++ b/arch/arm/xen/enlighten.c
>@@ -195,21 +195,19 @@ static void xen_power_off(void)
>  * documentation of the Xen Device Tree format.
>  */
> #define GRANT_TABLE_PHYSADDR 0
>-static int __init xen_guest_init(void)
>+void __init xen_early_init(void)
> {
>-	struct xen_add_to_physmap xatp;
>-	static struct shared_info *shared_info_page = 0;
>+	struct resource res;
> 	struct device_node *node;
> 	int len;
> 	const char *s = NULL;
> 	const char *version = NULL;
> 	const char *xen_prefix = "xen,xen-";
>-	struct resource res;
> 
> 	node = of_find_compatible_node(NULL, NULL, "xen,xen");
> 	if (!node) {
> 		pr_debug("No Xen support\n");
>-		return 0;
>+		return;
> 	}
> 	s = of_get_property(node, "compatible", &len);
> 	if (strlen(xen_prefix) + 3  < len &&
>@@ -217,10 +215,10 @@ static int __init xen_guest_init(void)
> 		version = s + strlen(xen_prefix);
> 	if (version == NULL) {
> 		pr_debug("Xen version not found\n");
>-		return 0;
>+		return;
> 	}
> 	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
>-		return 0;
>+		return;
> 	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
> 	xen_events_irq = irq_of_parse_and_map(node, 0);
> 	pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
>@@ -232,6 +230,15 @@ static int __init xen_guest_init(void)
> 		xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED;
> 	else
> 		xen_start_info->flags &= ~(SIF_INITDOMAIN|SIF_PRIVILEGED);
>+}
>+
>+static int __init xen_guest_init(void)
>+{
>+	struct xen_add_to_physmap xatp;
>+	static struct shared_info *shared_info_page = 0;
>+
>+	if (!xen_domain())
>+		return 0;
> 
> 	if (!shared_info_page)
> 		shared_info_page = (struct shared_info *)
>diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>index add6ea6..e0d438a 100644
>--- a/arch/arm64/kernel/setup.c
>+++ b/arch/arm64/kernel/setup.c
>@@ -53,6 +53,7 @@
> #include <asm/traps.h>
> #include <asm/memblock.h>
> #include <asm/psci.h>
>+#include <asm/xen/hypervisor.h>
> 
> unsigned int processor_id;
> EXPORT_SYMBOL(processor_id);
>@@ -267,6 +268,7 @@ void __init setup_arch(char **cmdline_p)
> 	unflatten_device_tree();
> 
> 	psci_init();
>+	xen_early_init();
> 
> 	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> #ifdef CONFIG_SMP




From konrad.wilk at oracle.com  Wed Jul 31 20:36:03 2013
From: konrad.wilk at oracle.com (Konrad Rzeszutek Wilk)
Date: Wed, 31 Jul 2013 20:36:03 -0400
Subject: [PATCH RFC 5/8] xen: introduce XENMEM_get_dma_buf and
 xen_put_dma_buf
In-Reply-To: <1375292732-7627-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1307311833040.4893@kaball.uk.xensource.com>
 <1375292732-7627-5-git-send-email-stefano.stabellini@eu.citrix.com>
Message-ID: <22032fc7-81f5-4271-81b6-cd2bee277fb5@email.android.com>

Stefano Stabellini <stefano.stabellini at eu.citrix.com> wrote:
>Signed-off-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
>---
>include/xen/interface/memory.h |   62
>++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 62 insertions(+), 0 deletions(-)
>
>diff --git a/include/xen/interface/memory.h
>b/include/xen/interface/memory.h
>index 2ecfe4f..ffd7f4e 100644
>--- a/include/xen/interface/memory.h
>+++ b/include/xen/interface/memory.h
>@@ -263,4 +263,66 @@ struct xen_remove_from_physmap {
> };
> DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
> 
>+#define XENMEM_get_dma_buf             26
>+/*
>+ * This hypercall is similar to XENMEM_exchange: it exchanges the
>pages

Could you elaborate why the existing hyper call won't work? 

>+ * passed in with a new set of pages, contiguous and under 4G if so
>+ * requested. The new pages are going to be "pinned": it's guaranteed
>+ * that their p2m mapping won't be changed until explicitly
>"unpinned".
>+ * If return code is zero then @out.extent_list provides the MFNs of
>the
>+ * newly-allocated memory.  Returns zero on complete success,
>otherwise
>+ * a negative error code.
>+ * On complete success then always @nr_exchanged == @in.nr_extents. 
>On
>+ * partial success @nr_exchanged indicates how much work was done.
>+ */
>+struct xen_get_dma_buf {
>+    /*
>+     * [IN] Details of memory extents to be exchanged (GMFN bases).
>+     * Note that @in.address_bits is ignored and unused.
>+     */
>+    struct xen_memory_reservation in;
>+
>+    /*
>+     * [IN/OUT] Details of new memory extents.
>+     * We require that:
>+     *  1. @in.domid == @out.domid
>+     *  2. @in.nr_extents  << @in.extent_order == 
>+     *     @out.nr_extents << @out.extent_order
>+     *  3. @in.extent_start and @out.extent_start lists must not
>overlap
>+     *  4. @out.extent_start lists GPFN bases to be populated
>+     *  5. @out.extent_start is overwritten with allocated GMFN bases
>+     */
>+    struct xen_memory_reservation out;
>+
>+    /*
>+     * [OUT] Number of input extents that were successfully exchanged:
>+     *  1. The first @nr_exchanged input extents were successfully
>+     *     deallocated.
>+     *  2. The corresponding first entries in the output extent list
>correctly
>+     *     indicate the GMFNs that were successfully exchanged.
>+     *  3. All other input and output extents are untouched.
>+     *  4. If not all input exents are exchanged then the return code
>of this
>+     *     command will be non-zero.
>+     *  5. THIS FIELD MUST BE INITIALISED TO ZERO BY THE CALLER!
>+     */
>+    xen_ulong_t nr_exchanged;
>+};
>+DEFINE_GUEST_HANDLE_STRUCT(xen_get_dma_buf);
>+
>+#define XENMEM_put_dma_buf             27
>+/*
>+ * XENMEM_put_dma_buf unpins a set of pages, previously pinned by
>+ * XENMEM_get_dma_buf. After this call the p2m mapping of the pages
>can
>+ * be transparently changed by the hypervisor, as usual. The pages are
>+ * still accessible from the guest.
>+ */
>+struct xen_put_dma_buf {
>+    /*
>+     * [IN] Details of memory extents to be exchanged (GMFN bases).
>+     * Note that @in.address_bits is ignored and unused.
>+     */
>+    struct xen_memory_reservation in;
>+};
>+DEFINE_GUEST_HANDLE_STRUCT(xen_put_dma_buf);
>+
> #endif /* __XEN_PUBLIC_MEMORY_H__ */




From davidb at codeaurora.org  Wed Jul 31 20:42:17 2013
From: davidb at codeaurora.org (David Brown)
Date: Wed, 31 Jul 2013 17:42:17 -0700
Subject: [ARM ATTEND] DT binding and support and general SOC
Message-ID: <20130801004217.GA12730@codeaurora.org>

Qualcomm is starting to ramp up actually contributing support for MSM
to the mainline kernel.  There are at least a couple of areas where I
see direct discussion involvement would be useful:

  - DT binding.  The Qualcomm out-of-tree code has roughly 37k lines
    of dts/dtsi files.  There has been a lot of effort here to try an
    manage/organize these bindings, but for the most part, this work
    has happened entirely internally.  As more MSM code is
    contributed, there will be a lot more bindings coming in.  I can
    bring experience with what we've done/learned with our current
    internal bindings, as well as bring feedback to more align our
    work with how the ARM bindings in general are moving.

  - SoC code structure and layout.  As ARM increases in variants (new
    CPU types, lots of SoCs, 64-bit etc), I think we should have some
    discussion of how to best organize the code.

David Brown

-- 
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


From santosh.shilimkar at ti.com  Wed Jul 31 20:43:11 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 31 Jul 2013 20:43:11 -0400
Subject: [PATCH 10/18] ARM: OMAP2+: Switch to sched_clock_register()
In-Reply-To: <1375309877-16617-11-git-send-email-sboyd@codeaurora.org>
References: <1375309877-16617-1-git-send-email-sboyd@codeaurora.org>
 <1375309877-16617-11-git-send-email-sboyd@codeaurora.org>
Message-ID: <51F9AF1F.1060902@ti.com>

On Wednesday 31 July 2013 06:31 PM, Stephen Boyd wrote:
> The 32 bit sched_clock interface now supports 64 bits. Upgrade to
> the 64 bit function to allow us to remove the 32 bit registration
> interface.
> 
> Cc: Tony Lindgren <tony at atomide.com>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  arch/arm/mach-omap2/timer.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
Acked-by: Santosh Shilimkar<santosh.shilimkar at ti.com>



From kuninori.morimoto.gx at renesas.com  Wed Jul 31 20:55:05 2013
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Wed, 31 Jul 2013 17:55:05 -0700 (PDT)
Subject: [PATCH 00/13] ARM: shmobile: Rework ->init_time() /
 shmobile_timer_init()
In-Reply-To: <20130731190110.31796.96552.sendpatchset@w520>
References: <20130731190110.31796.96552.sendpatchset@w520>
Message-ID: <87hafa2psq.wl%kuninori.morimoto.gx@renesas.com>


Hi

> [PATCH 01/13] ARM: shmobile: Use default ->init_time() on r8a73a4
> [PATCH 02/13] ARM: shmobile: Use default ->init_time() on r8a7740
> [PATCH 03/13] ARM: shmobile: Use default ->init_time() on r8a7778
> [PATCH 04/13] ARM: shmobile: Use default ->init_time() on r8a7779
> [PATCH 05/13] ARM: shmobile: Use default ->init_time() on Bockw
> [PATCH 06/13] ARM: shmobile: Use default ->init_time() on Bockw DT ref
> [PATCH 07/13] ARM: shmobile: Use default ->init_time() on Armadillo DT ref
> [PATCH 08/13] ARM: shmobile: Use default ->init_time() on APE6EVM
> [PATCH 09/13] ARM: shmobile: Use default ->init_time() on APE6EVM DT ref
> [PATCH 10/13] ARM: shmobile: Use default ->init_time() on Marzen DT ref
> [PATCH 11/13] ARM: shmobile: Use default ->init_time() on KZM9G DT ref
> [PATCH 12/13] ARM: shmobile: Use clocksource_of_init() on r8a7790
> [PATCH 13/13] ARM: shmobile: Remove unused shmobile_init_time()

For all patches

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>



From peter.chen at freescale.com  Wed Jul 31 21:33:12 2013
From: peter.chen at freescale.com (Peter Chen)
Date: Thu, 1 Aug 2013 09:33:12 +0800
Subject: [PATCH 2/2] chipidea: Use devm_request_irq()
In-Reply-To: <20130731141512.GU2810@htj.dyndns.org>
References: <20130731090512.GD9858@sirena.org.uk>
 <20130731094434.GC1754@pengutronix.de>
 <20130731095411.GA2810@htj.dyndns.org>
 <20130731111853.GJ9858@sirena.org.uk>
 <20130731113244.GI2810@htj.dyndns.org>
 <20130731115027.GN9858@sirena.org.uk>
 <20130731115527.GR2810@htj.dyndns.org>
 <20130731132708.GQ9858@sirena.org.uk>
 <CAL411-qQm9vgDHswEM6PEvFKAaqd=e3qm-zViUbNztv0tJYa8Q@mail.gmail.com>
 <20130731141512.GU2810@htj.dyndns.org>
Message-ID: <20130801013311.GH8540@nchen-desktop>

On Wed, Jul 31, 2013 at 10:15:12AM -0400, Tejun Heo wrote:
> hello,
> 
> On Wed, Jul 31, 2013 at 09:55:26PM +0800, Peter Chen wrote:
> > I think the main point is we should allocate managed resource which is used
> > at interrupt handler before devm_request_irq, and all resources used
> > at interrupt
> > handler should be managed.
> > 
> > If we use non-managed resource at interrupt handler, but using managed interrupt
> > handler, things still will go wrong if there is an odd (unexpected)
> > interrupt after
> > we finish deactivation at removal.
> 
> In general, applying devm partially isn't a good idea.  It's very easy
> to get into trouble thanks to release order dependency which isn't
> immediately noticeable and there have been actual bugs caused by that.
> The strategies which seem to work are either
> 
> * Convert everything over to devm by wrapping deactivation in a devres
>   callback too.  As long as your init sequence is sane (ie. irq
>   shouldn't be request before things used by irq are ready).
> 
> * Allocate all resources using devres but shut down the execution
>   engine in the remove_one().  Again, as all releases are controlled
>   by devres, you won't have to worry about messing up the release
>   sequencing.
> 

thanks, Tejun. So, Alex and Fabio, this patch may not be suitable currently,
since many resources at both EHCI and device side are non-managed.
-- 

Best Regards,
Peter Chen



From sboyd at codeaurora.org  Wed Jul 31 21:36:13 2013
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 Jul 2013 18:36:13 -0700
Subject: [PATCH 2/2] Convert PowerPC macro spin_event_timeout() to
 architecture independent macro
In-Reply-To: <51F9A9CD.1040804@tabi.org>
References: <1375187900-17582-1-git-send-email-B44344@freescale.com>
 <1375187900-17582-3-git-send-email-B44344@freescale.com>
 <20130731071630.GI8868@codeaurora.org>
 <CAOZdJXVvNBR-qf7LXNOHZVstH_Rebxwn-wAkSaBS53Wn55mYCw@mail.gmail.com>
 <51F9A5FE.8030608@codeaurora.org> <51F9A80E.5010307@tabi.org>
 <51F9A8F1.9020704@codeaurora.org> <51F9A9CD.1040804@tabi.org>
Message-ID: <51F9BB8D.6060907@codeaurora.org>

On 07/31/13 17:20, Timur Tabi wrote:
> On 07/31/2013 07:16 PM, Stephen Boyd wrote:
>> cpu_relax() is usually just a compiler barrier or an instruction hint to
>> the cpu that it should cool down because we're spinning in a tight loop.
>> It certainly shouldn't be calling into the  scheduler.
> Ah yes, I remember now.  So it does seem that if we can fix the problem
> of non-incrementing 'jiffies', then this macro can be used in interrupts.

That's encouraging. It looks like you introduced it to use in interrupt
context but then it got shot down[1]? I lost track in all the versions.

>
> Of course, that assumes that spinning in interrupt context is a good
> idea to begin with.  Maybe we shouldn't be encouraging it?

I read through the v5 discussion and it seems I'm about to walk through
some tall grass on the way to Cerulean City.

Andrew Morton, I choose you! Use your mind-power move to convince
everyone that having a macro for spinning on a register in interrupt
context is a good thing. At least it will be more obvious.

>
>>>> FYI, you might want to look at the code reviews for spin_event_timeout()
>>>> on the linuxppc-dev mailing list, back in March 2009.
>>>>
>> Sure. Any pointers? Otherwise I'll go digging around the archives.
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-March/thread.html
>

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-May/072521.html

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



From herbert at gondor.apana.org.au  Wed Jul 31 21:47:41 2013
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Thu, 1 Aug 2013 11:47:41 +1000
Subject: [PATCH 0/4] crypto: omap-sham: Add support for SHA384/SHA512 for
 OMAP5/AM43xx Soc's
In-Reply-To: <1374821957-30141-1-git-send-email-lokeshvutla@ti.com>
References: <1374821957-30141-1-git-send-email-lokeshvutla@ti.com>
Message-ID: <20130801014741.GE24286@gondor.apana.org.au>

On Fri, Jul 26, 2013 at 12:29:13PM +0530, Lokesh Vutla wrote:
> This patch series adds support for SHA348 and SHA512 in addition to MD5,
> SHA1, SHA224 SHA256 that the omap sha module supports. Also adding the pdata
> for OMAP5 and AM43xx Soc's.
> And using devm_* calls to make cleanup paths simpler.

All applied.  Thanks!
-- 
Email: Herbert Xu <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From joelf at ti.com  Wed Jul 31 21:59:27 2013
From: joelf at ti.com (Joel Fernandes)
Date: Wed, 31 Jul 2013 20:59:27 -0500
Subject: [PATCH 7/9] ARM: edma: Don't clear EMR of channel in edma_stop
In-Reply-To: <51F8DA5C.9060503@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
 <1375104595-16018-8-git-send-email-joelf@ti.com> <51F77982.7030601@ti.com>
 <51F89B0B.4080803@ti.com> <51F8DA5C.9060503@ti.com>
Message-ID: <51F9C0FF.7030703@ti.com>

On 07/31/2013 04:35 AM, Sekhar Nori wrote:
> On Wednesday 31 July 2013 10:35 AM, Joel Fernandes wrote:
>> On 07/30/2013 03:29 AM, Sekhar Nori wrote:
>>> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>>>> We certainly don't want error conditions to be cleared anywhere
>>>
>>> 'anywhere' is a really loaded term.
>>>
>>>> as this will make us 'forget' about missed events. We depend on
>>>> knowing which events were missed in order to be able to reissue them.
>>>
>>>> This fixes a race condition where the EMR was being cleared
>>>> by the transfer completion interrupt handler.
>>>>
>>>> Basically, what was happening was:
>>>>
>>>>             Missed event
>>>>              |
>>>>              |
>>>>              V
>>>> SG1-SG2-SG3-Null
>>>>          \
>>>>           \__TC Interrupt (Almost same time as ARM is executing
>>>> TC interrupt handler, an event got missed and also forgotten
>>>> by clearing the EMR).
>>>
>>> Sorry, but I dont see how edma_stop() is coming into picture in the race
>>> you describe?
>>
>> In edma_callback function, for the case of DMA_COMPLETE (Transfer
>> completion interrupt), edma_stop() is called when all sets have been
>> processed. This had the effect of clearing the EMR.
> 
> Ah, thanks. I was missing the fact that the race comes into picture only
> when using the DMA engine driver. I guess that should be mentioned
> somewhere since it is not immediately obvious.
> 
> The patch looks good to me. So if you respin just this one with some
> updated explanation based on what you wrote below, I will take it.

Sure I'll do that. Also the trigger_channel patch, will you be taking
that one too? I can send these 2 in a series as they touch
arch/arm/common/edma.c

Thanks,

-Joel



> 
> Thanks,
> Sekhar
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



From santosh.shilimkar at ti.com  Wed Jul 31 22:14:41 2013
From: santosh.shilimkar at ti.com (Santosh Shilimkar)
Date: Wed, 31 Jul 2013 22:14:41 -0400
Subject: [RFC/RFT PATCH 4/5] ARM: mm: change max*pfn to include the
 physical offset of memory
In-Reply-To: <20130731105643.GW24642@n2100.arm.linux.org.uk>
References: <1373665694-7580-1-git-send-email-santosh.shilimkar@ti.com>
 <1373665694-7580-5-git-send-email-santosh.shilimkar@ti.com>
 <20130731105643.GW24642@n2100.arm.linux.org.uk>
Message-ID: <51F9C491.8070808@ti.com>

On Wednesday 31 July 2013 06:56 AM, Russell King - ARM Linux wrote:
> On Fri, Jul 12, 2013 at 05:48:13PM -0400, Santosh Shilimkar wrote:
>> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
>> index 5b579b9..b2d5937 100644
>> --- a/arch/arm/include/asm/dma-mapping.h
>> +++ b/arch/arm/include/asm/dma-mapping.h
>> @@ -47,12 +47,12 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
>>  #ifndef __arch_pfn_to_dma
>>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>>  {
>> -	return (dma_addr_t)__pfn_to_bus(pfn);
>> +	return (dma_addr_t)__pfn_to_bus(pfn + PHYS_PFN_OFFSET);
>>  }
>>  
>>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>>  {
>> -	return __bus_to_pfn(addr);
>> +	return __bus_to_pfn(addr) - PHYS_PFN_OFFSET;
>>  }
>>  
>>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
>> @@ -64,15 +64,16 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>>  {
>>  	return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
>>  }
>> +
>>  #else
>>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>>  {
>> -	return __arch_pfn_to_dma(dev, pfn);
>> +	return __arch_pfn_to_dma(dev, pfn + PHYS_PFN_OFFSET);
>>  }
>>  
>>  static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>>  {
>> -	return __arch_dma_to_pfn(dev, addr);
>> +	return __arch_dma_to_pfn(dev, addr) - PHYS_PFN_OFFSET;
>>  }
>>  
>>  static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
>> @@ -86,6 +87,13 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
>>  }
>>  #endif
> 
> Note that I don't think the above are correct - the 'pfn' argument to the
> above functions already includes the PFN offset of physical memory -
> they're all physical_address >> PAGE_SHIFT values.
> 
Right.
Updated patch pushed into the patch system. (patch 7805/1)

Regards,
Santosh


From joelf at ti.com  Wed Jul 31 22:27:31 2013
From: joelf at ti.com (Joel Fernandes)
Date: Wed, 31 Jul 2013 21:27:31 -0500
Subject: [PATCH 4/9] dma: edma: Find missed events and issue them
In-Reply-To: <51F8D667.2040406@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
 <1375104595-16018-5-git-send-email-joelf@ti.com> <51F7659E.3040302@ti.com>
 <51F89763.1010102@ti.com> <51F8D667.2040406@ti.com>
Message-ID: <51F9C793.2000001@ti.com>

On 07/31/2013 04:18 AM, Sekhar Nori wrote:
> On Wednesday 31 July 2013 10:19 AM, Joel Fernandes wrote:
>> Hi Sekhar,
>>
>> On 07/30/2013 02:05 AM, Sekhar Nori wrote:
>>> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>>>> In an effort to move to using Scatter gather lists of any size with
>>>> EDMA as discussed at [1] instead of placing limitations on the driver,
>>>> we work through the limitations of the EDMAC hardware to find missed
>>>> events and issue them.
>>>>
>>>> The sequence of events that require this are:
>>>>
>>>> For the scenario where MAX slots for an EDMA channel is 3:
>>>>
>>>> SG1 -> SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> Null
>>>>
>>>> The above SG list will have to be DMA'd in 2 sets:
>>>>
>>>> (1) SG1 -> SG2 -> SG3 -> Null
>>>> (2) SG4 -> SG5 -> SG6 -> Null
>>>>
>>>> After (1) is succesfully transferred, the events from the MMC controller
>>>> donot stop coming and are missed by the time we have setup the transfer
>>>> for (2). So here, we catch the events missed as an error condition and
>>>> issue them manually.
>>>
>>> Are you sure there wont be any effect of these missed events on the
>>> peripheral side. For example, wont McASP get into an underrun condition
>>> when it encounters a null PaRAM set? Even UART has to transmit to a
>>
>> But it will not encounter null PaRAM set because McASP uses contiguous
>> buffers for transfer which are not scattered across physical memory.
>> This can be accomplished with an SG of size 1. For such SGs, this patch
>> series leaves it linked Dummy and does not link to Null set. Null set is
>> only used for SG lists that are > MAX_NR_SG in size such as those
>> created for example by MMC and Crypto.
>>
>>> particular baud so I guess it cannot wait like the way MMC/SD can.
>>
>> Existing driver have to wait anyway if they hit MAX SG limit today. If
>> they don't want to wait, they would have allocated a contiguous block of
>> memory and DMA that in one stretch so they don't lose any events, and in
>> such cases we are not linking to Null.
> 
> As long as DMA driver can advertize its MAX SG limit, peripherals can
> always work around that by limiting the number of sync events they
> generate so as to not having any of the events getting missed. With this
> series, I am worried that EDMA drivers is advertizing that it can handle
> any length SG list while not taking care of missing any events while
> doing so. This will break the assumptions that driver writers make.

This is already being done by some other DMA engine drivers ;). We can
advertise more than we can handle at a time, that's the basis of this
whole idea.

I understand what you're saying but events are not something that have
be serviced immediately, they can be queued etc and the actually
transfer from the DMA controller can be delayed. As long as we don't
miss the event we are fine which my series takes care off.

So far I have tested this series on following modules in various
configurations and have seen no issues:
- Crypto AES
- MMC/SD
- SPI (128x160 display)

>>> Also, wont this lead to under-utilization of the peripheral bandwith?
>>> Meaning, MMC/SD is ready with data but cannot transfer because the DMA
>>> is waiting to be set-up.
>>
>> But it is waiting anyway even today. Currently based on MAX segs, MMC
>> driver/subsystem will make SG list of size max_segs. Between these
>> sessions of creating such smaller SG-lists, if for some reason the MMC
>> controller is sending events, these will be lost anyway.
> 
> But if MMC/SD driver knows how many events it should generate if it
> knows the MAX SG limit. So there should not be any missed events in
> current code. And I am not claiming that your solution is making matters
> worse. But its not making it much better as well.

This is not true for crypto, the events are not deasserted and crypto
continues to send events. This is what led to the "don't trigger in
Null" patch where I'm setting the missed flag to avoid recursion.

>> This can be used only for buffers that are contiguous in memory, not
>> those that are scattered across memory.
> 
> I was hinting at using the linking facility of EDMA to achieve this.
> Each PaRAM set has full 32-bit source and destination pointers so I see
> no reason why non-contiguous case cannot be handled.
> 
> Lets say you need to transfer SG[0..6] on channel C. Now, PaRAM sets are
> typically 4 times the number of channels. In this case we use one DMA
> PaRAM set and two Link PaRAM sets per channel. P0 is the DMA PaRAM set
> and P1 and P2 are the Link sets.
> 
> Initial setup:
> 
> SG0 -> SG1 -> SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> NULL
>  ^      ^      ^
>  |      |      |
> P0  -> P1  -> P2  -> NULL
> 
> P[0..2].TCINTEN = 1, so get an interrupt after each SG element
> completion. On each completion interrupt, hardware automatically copies
> the linked PaRAM set into the DMA PaRAM set so after SG0 is transferred
> out, the state of hardware is:
> 
> SG1  -> SG2 -> SG3 -> SG3 -> SG6 -> NULL
>  ^       ^
>  |       |
> P0,1    P2  -> NULL
>  |       ^
>  |       |
>  ---------
> 
> SG1 transfer has already started by the time the TC interrupt is
> handled. As you can see P1 is now redundant and ready to be recycled. So
> in the interrupt handler, software recycles P1. Thus:
> 
> SG1 -> SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> NULL
>  ^      ^      ^
>  |      |      |
> P0  -> P2  -> P1  -> NULL
> 
> Now, on next interrupt, P2 gets copied and thus can get recycled.
> Hardware state:
> 
> SG2  -> SG3 -> SG4 -> SG5 -> SG6 -> NULL
>  ^       ^
>  |       |
> P0,2    P1  -> NULL
>  |       ^
>  |       |
>  ---------
> 
> As part of TC completion interrupt handling:
> 
> SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> NULL
>  ^      ^      ^
>  |      |      |
> P0  -> P1  -> P2  -> NULL
> 
> This goes on until the SG list in exhausted. If you use more PaRAM sets,
> interrupt handler gets more time to recycle the PaRAM set. At no point
> we touch P0 as it is always under active transfer. Thus the peripheral
> is always kept busy.
> 
> Do you see any reason why such a mechanism cannot be implemented?

This is possible and looks like another way to do it, but there are 2
problems I can see with it.

1. Its inefficient because of too many interrupts:

Imagine case where we have an SG list of size 30 and MAX_NR_SG size is
10. This method will trigger 30 interrupts always, where as with my
patch series, you'd get only 3 interrupts. If you increase MAX_SG_NR ,
you'd get even fewer interrupts.

2. If the interrupt handler for some reason doesn't complete or get
service in time, we will end up DMA'ing incorrect data as events
wouldn't stop coming in even if interrupt is not yet handled (in your
example linked sets P1 or P2 would be old ones being repeated). Where as
with my method, we are not doing any DMA once we finish the current
MAX_NR_SG set even if events continue to come.

I feel my patch series efficient, has less LOC because of code reuse and
has passed all possible tests I've performed on it.

Thanks,

-Joel

> 
> Thanks,
> Sekhar
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



From olof at lixom.net  Wed Jul 31 22:47:30 2013
From: olof at lixom.net (Olof Johansson)
Date: Wed, 31 Jul 2013 19:47:30 -0700
Subject: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit
 mitigations
In-Reply-To: <20130731142430.GA4545@redhat.com>
References: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
 <20130730221435.GA22240@redhat.com>
 <20130730231120.GC30725@blackmetal.musicnaut.iki.fi>
 <20130730231533.GA26824@redhat.com>
 <20130730235834.GD30725@blackmetal.musicnaut.iki.fi>
 <20130731000444.GC1281@redhat.com>
 <20130731094012.GU24642@n2100.arm.linux.org.uk>
 <20130731142430.GA4545@redhat.com>
Message-ID: <CAOesGMiBa7fT+HZquNrwV=3P=Z-F9c8L7YQr7=D2BO_6pJXQ0w@mail.gmail.com>

On Wed, Jul 31, 2013 at 7:24 AM, Dave Jones <davej at redhat.com> wrote:
> On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
>  > On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
>  > > To use ARM as an example, the bugs I've seen have mostly been in arch specific
>  > > code that does things like page-table manipulation.  The chromebook bugs I
>  > > was hitting for eg were various kinds of PTE corruption warnings.
>  >
>  > Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
>  > having any changes related to bug reports on PTEs on ARM.
>
> I wasn't sure if it was a googleism, or happens on mainline, so no.

We'd definitely be interested in hearing about what you've found. The
3.4 kernel has a lot of out-of-tree code for exynos, we've reduced it
quite a bit on the upcoming 3.8 one but it needs a bit more baking.

As of 3.10, it's not actually hard to run a mainline kernel on the
chromebook, but you have limited functionality (no wifi, no USB3, no
accellerated graphics). Easiest is to do it by booting from SD card.
See instructions at
http://www.chromium.org/chromium-os/u-boot-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook.


How long would a useful run of trinity take? I've got an
autobuilder/autobooter setup here with a cross-section of current ARM
hardware (7 platforms and counting) that I mostly do boot testing on,
and I should add a smallish suite of testcases to the same. Trinity
would be a good candidate for that.


-Olof


From rizhao at nvidia.com  Wed Jul 31 22:49:29 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Thu, 1 Aug 2013 10:49:29 +0800
Subject: [PATCH 1/9] ARM: dts: add generic DMA DT binding for tegra apbdma
In-Reply-To: <51F7EE81.1060105@wwwdotorg.org>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-2-git-send-email-rizhao@nvidia.com>
 <51F2CC30.5090200@wwwdotorg.org>
 <20130730025448.GI15855@rizhao-lap>
 <51F7EE81.1060105@wwwdotorg.org>
Message-ID: <20130801024929.GA31469@rizhao-lap>

On Wed, Jul 31, 2013 at 12:49:05AM +0800, Stephen Warren wrote:
> On 07/29/2013 08:54 PM, Richard Zhao wrote:
> > On Sat, Jul 27, 2013 at 03:21:20AM +0800, Stephen Warren wrote:
> >> (Stripping the Cc list a lot, but adding in the DT binding maintainers)
> >>
> >> On 07/23/2013 10:09 PM, Richard Zhao wrote:
> >>> All Tegra device drivers will soon move to generic DMA device tree bindings.
> >>> Add the required properties to the Tegra DT files to support that. The legacy
> >>> property nvidia,dma-request-selector will be removed after all drivers have
> >>> been converted, in order to maintain bisectability.
> >>>
> >>> Changes:
> >>>  - Add '#dma-cells' for apbdma nodes
> >>>  - And properties 'dmas' and 'dma-names' for apbdma client nodes
> >>>  - update apbdma DT binding doc
> >>>
> >>> Signed-off-by: Richard Zhao <rizhao at nvidia.com>
> >>> ---
> >>>  .../devicetree/bindings/dma/tegra20-apbdma.txt     |  1 +
> >>>  arch/arm/boot/dts/tegra114.dtsi                    | 27 ++++++++++++++++++++++
> >>>  arch/arm/boot/dts/tegra20.dtsi                     | 27 ++++++++++++++++++++++
> >>>  arch/arm/boot/dts/tegra30.dtsi                     | 25 ++++++++++++++++++++
> >>
> >> This patch should be split differently.
> >>
> >> Patch 1 in the series should include the binding document change and the
> >> associated DMA driver change, which will support both the old and new
> >> bindings.

Binding doc is used to define the way dts describe hw. I still think it
is better to squash into this patch. But it's not such a big deal. I'll
move it to dma patch  since you like it.

Thanks
Richard

> >>
> >> Patch 2 should contain the *.dtsi changes.
> >
> > The reason I update apbdma binding doc here is to make it consistent
> > with the mass properties added in dtsi files.
> > apbdma has less places of changes than dtsi files.
> 
> It'll still be consistent if you update the binding documentation first,
> then update the *.dtsi to conform to the new binding docs. It won't
> affect the number of changes.


From davej at redhat.com  Wed Jul 31 22:59:11 2013
From: davej at redhat.com (Dave Jones)
Date: Wed, 31 Jul 2013 22:59:11 -0400
Subject: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit
 mitigations
In-Reply-To: <CAOesGMiBa7fT+HZquNrwV=3P=Z-F9c8L7YQr7=D2BO_6pJXQ0w@mail.gmail.com>
References: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
 <20130730221435.GA22240@redhat.com>
 <20130730231120.GC30725@blackmetal.musicnaut.iki.fi>
 <20130730231533.GA26824@redhat.com>
 <20130730235834.GD30725@blackmetal.musicnaut.iki.fi>
 <20130731000444.GC1281@redhat.com>
 <20130731094012.GU24642@n2100.arm.linux.org.uk>
 <20130731142430.GA4545@redhat.com>
 <CAOesGMiBa7fT+HZquNrwV=3P=Z-F9c8L7YQr7=D2BO_6pJXQ0w@mail.gmail.com>
Message-ID: <20130801025911.GA20166@redhat.com>

On Wed, Jul 31, 2013 at 07:47:30PM -0700, Olof Johansson wrote:

 > >  > Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
 > >  > having any changes related to bug reports on PTEs on ARM.
 > >
 > > I wasn't sure if it was a googleism, or happens on mainline, so no.
 > 
 > As of 3.10, it's not actually hard to run a mainline kernel on the
 > chromebook, but you have limited functionality (no wifi, no USB3, no
 > accellerated graphics). Easiest is to do it by booting from SD card.
 > See instructions at
 > http://www.chromium.org/chromium-os/u-boot-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook.
 
Yeah, that's how I got Fedora running on it (I think the people who did the
Fedora spin for the chromebook chose the google kernel for exactly
the reasons you mention above).  It felt a little sluggish for a native
kernel build though, and I'm not setup for cross-building so I stuck with
the 3.4 build.
 
 > How long would a useful run of trinity take?

It blew up in a minute or so of runtime when I tried last week.

 > I've got an autobuilder/autobooter setup here with a cross-section of current ARM
 > hardware (7 platforms and counting) that I mostly do boot testing on,
 > and I should add a smallish suite of testcases to the same. Trinity
 > would be a good candidate for that.

Feel free to mail me off-list if I can do anything to help out, though
hopefully things should build & run 'out of the box'.  You shouldn't
need any special command line args (though you might get inspiration
for ideas from the scripts/test-* harnesses)

	Dave



From rizhao at nvidia.com  Wed Jul 31 23:30:33 2013
From: rizhao at nvidia.com (Richard Zhao)
Date: Thu, 1 Aug 2013 11:30:33 +0800
Subject: [PATCH 6/9] serial: tegra: move to generic dma DT binding
In-Reply-To: <51F98275.6020906@wwwdotorg.org>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-7-git-send-email-rizhao@nvidia.com>
 <51F2D063.5010505@wwwdotorg.org>
 <20130730033134.GM15855@rizhao-lap> <51F7EDF2.60700@wwwdotorg.org>
 <20130731034541.GQ15855@rizhao-lap>
 <51F98275.6020906@wwwdotorg.org>
Message-ID: <20130801033033.GB31469@rizhao-lap>

On Thu, Aug 01, 2013 at 05:32:37AM +0800, Stephen Warren wrote:
> On 07/30/2013 09:45 PM, Richard Zhao wrote:
> > On Wed, Jul 31, 2013 at 12:46:42AM +0800, Stephen Warren wrote:
> >> On 07/29/2013 09:31 PM, Richard Zhao wrote:
> >>> On Sat, Jul 27, 2013 at 03:39:15AM +0800, Stephen Warren wrote:
> >>>> On 07/23/2013 10:09 PM, Richard Zhao wrote:
> >>>>> - driver: remove use of nvidia,dma-request-selector
> >>>>> 	  use dma_request_slave_channel to request channel
> >>>>> - update binding doc
> >>>>
> >>>> This patch needs to be amended so that the DMA channel is looked up
> >>>> during probe() rather than open(), to guarantee that deferred probe
> >>>> works. It's possible to hold off probe, but not possible AFAIK to hold
> >>>> off opening the port.
> >>>
> >>> How about avoid return -EPROBE_DEFER at open() time? It can be in
> >>> another patch.
> >>
> >> I don't really understand what you mean. -EPROBE_DEFER is something that
> >> only makes sense for probe() to return (or functions used by probe()).
> >> It doesn't make sense to return it anywhere else, since probe deferral
> >> is something that can only happen for probe().
> >
> > What I meant is, it might not worth to move request channel to probe
> > only because we need to check error and return -EPROBE_DEFER.
> 
> If probe() doesn't attempt to validate that the/a DMA channel provider
> exists, then there's no guarantee that the DMA provider has probed
> before the DMA client driver either probes or executes any later code.

I'm not against defer probe, but dma_request_slave_channel might not be
the right function. Ideally dma channels are allocated at open() time
and dma controller loaded checking is at probe() time. So there's
better some function called check_dma_controller_loaded(), or we could
also use initcalls to let dma driver probe earlier.

This patch intend to be simple to only change the binding.

> So, you could quite easily end up with a situation where the serial
> driver's open fails because the DMA provider has not yet probed. This is
> exactly what deferred probe was intended to avoid. This reason alone is
> enough to make it worth fixing this.
> 
> > dma_request_slave_channel is better to be called as late as possible to
> > make better dynamic use of dma channels.
> 
> probe() could validate that the provider exists in a way that doesn't
> permanently hold ownership of the DMA channel. For example, request it
> then immediately release it, in the absence of a dedicated "validate my
> DMA providers exist" API.

It's ugly but may work. The current driver didn't check dma controller
loaded at probe time. Let's leave the task to another patch?

> 
> > Actually, I searched the kernel code, most drivers don't return EPROBE_DEFER
> > when dma_request_slave_channel failed. dma_request_slave_channel can
> > fail in many cases, and dma device not probed is only one case.
> 
> That sounds like a bug. If a DMA channel /is/ specified, it should be
> possible to acquire it. If no DMA channel is specified, and if the
> device can do PIO, then it's reasonable to continue.
Idealy when dma_request_slave_channel failed at open time, it can also
move to PIO.

Thanks
Richard


From joelf at ti.com  Wed Jul 31 23:43:09 2013
From: joelf at ti.com (Joel Fernandes)
Date: Wed, 31 Jul 2013 22:43:09 -0500
Subject: [PATCH 4/9] dma: edma: Find missed events and issue them
In-Reply-To: <51F9C793.2000001@ti.com>
References: <1375104595-16018-1-git-send-email-joelf@ti.com>
 <1375104595-16018-5-git-send-email-joelf@ti.com> <51F7659E.3040302@ti.com>
 <51F89763.1010102@ti.com> <51F8D667.2040406@ti.com> <51F9C793.2000001@ti.com>
Message-ID: <51F9D94D.5060702@ti.com>

On 07/31/2013 09:27 PM, Joel Fernandes wrote:
> On 07/31/2013 04:18 AM, Sekhar Nori wrote:
>> On Wednesday 31 July 2013 10:19 AM, Joel Fernandes wrote:
>>> Hi Sekhar,
>>>
>>> On 07/30/2013 02:05 AM, Sekhar Nori wrote:
>>>> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>>>>> In an effort to move to using Scatter gather lists of any size with
>>>>> EDMA as discussed at [1] instead of placing limitations on the driver,
>>>>> we work through the limitations of the EDMAC hardware to find missed
>>>>> events and issue them.
>>>>>
>>>>> The sequence of events that require this are:
>>>>>
>>>>> For the scenario where MAX slots for an EDMA channel is 3:
>>>>>
>>>>> SG1 -> SG2 -> SG3 -> SG4 -> SG5 -> SG6 -> Null
>>>>>
>>>>> The above SG list will have to be DMA'd in 2 sets:
>>>>>
>>>>> (1) SG1 -> SG2 -> SG3 -> Null
>>>>> (2) SG4 -> SG5 -> SG6 -> Null
>>>>>
>>>>> After (1) is succesfully transferred, the events from the MMC controller
>>>>> donot stop coming and are missed by the time we have setup the transfer
>>>>> for (2). So here, we catch the events missed as an error condition and
>>>>> issue them manually.
>>>>
>>>> Are you sure there wont be any effect of these missed events on the
>>>> peripheral side. For example, wont McASP get into an underrun condition
>>>> when it encounters a null PaRAM set? Even UART has to transmit to a
>>>
>>> But it will not encounter null PaRAM set because McASP uses contiguous
>>> buffers for transfer which are not scattered across physical memory.
>>> This can be accomplished with an SG of size 1. For such SGs, this patch
>>> series leaves it linked Dummy and does not link to Null set. Null set is
>>> only used for SG lists that are > MAX_NR_SG in size such as those
>>> created for example by MMC and Crypto.
>>>
>>>> particular baud so I guess it cannot wait like the way MMC/SD can.
>>>
>>> Existing driver have to wait anyway if they hit MAX SG limit today. If
>>> they don't want to wait, they would have allocated a contiguous block of
>>> memory and DMA that in one stretch so they don't lose any events, and in
>>> such cases we are not linking to Null.
>>
>> As long as DMA driver can advertize its MAX SG limit, peripherals can
>> always work around that by limiting the number of sync events they
>> generate so as to not having any of the events getting missed. With this
>> series, I am worried that EDMA drivers is advertizing that it can handle
>> any length SG list while not taking care of missing any events while
>> doing so. This will break the assumptions that driver writers make.

Sorry, just forgot to respond to "not taking care of missing any events
while doing so". Can you clarify this? DMA engine driver is taking care
of missed events.

Also- missing of events doesn't result in feedback to the peripheral.
Peripheral sends even to DMA controller, event is missed. Peripheral
doesn't know anything about what happened and is waiting for transfer
from the DMA controller.

Thanks,

-Joel



From swarren at wwwdotorg.org  Wed Jul 31 23:45:01 2013
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 Jul 2013 21:45:01 -0600
Subject: [PATCH 6/9] serial: tegra: move to generic dma DT binding
In-Reply-To: <20130801033033.GB31469@rizhao-lap>
References: <1374639002-16753-1-git-send-email-rizhao@nvidia.com>
 <1374639002-16753-7-git-send-email-rizhao@nvidia.com>
 <51F2D063.5010505@wwwdotorg.org> <20130730033134.GM15855@rizhao-lap>
 <51F7EDF2.60700@wwwdotorg.org> <20130731034541.GQ15855@rizhao-lap>
 <51F98275.6020906@wwwdotorg.org> <20130801033033.GB31469@rizhao-lap>
Message-ID: <51F9D9BD.4080901@wwwdotorg.org>

On 07/31/2013 09:30 PM, Richard Zhao wrote:
> On Thu, Aug 01, 2013 at 05:32:37AM +0800, Stephen Warren wrote:
>> On 07/30/2013 09:45 PM, Richard Zhao wrote:
>>> On Wed, Jul 31, 2013 at 12:46:42AM +0800, Stephen Warren wrote:
>>>> On 07/29/2013 09:31 PM, Richard Zhao wrote:
>>>>> On Sat, Jul 27, 2013 at 03:39:15AM +0800, Stephen Warren wrote:
>>>>>> On 07/23/2013 10:09 PM, Richard Zhao wrote:
>>>>>>> - driver: remove use of nvidia,dma-request-selector
>>>>>>> 	  use dma_request_slave_channel to request channel
>>>>>>> - update binding doc
>>>>>>
>>>>>> This patch needs to be amended so that the DMA channel is looked up
>>>>>> during probe() rather than open(), to guarantee that deferred probe
>>>>>> works. It's possible to hold off probe, but not possible AFAIK to hold
>>>>>> off opening the port.
>>>>>
>>>>> How about avoid return -EPROBE_DEFER at open() time? It can be in
>>>>> another patch.
>>>>
>>>> I don't really understand what you mean. -EPROBE_DEFER is something that
>>>> only makes sense for probe() to return (or functions used by probe()).
>>>> It doesn't make sense to return it anywhere else, since probe deferral
>>>> is something that can only happen for probe().
>>>
>>> What I meant is, it might not worth to move request channel to probe
>>> only because we need to check error and return -EPROBE_DEFER.
>>
>> If probe() doesn't attempt to validate that the/a DMA channel provider
>> exists, then there's no guarantee that the DMA provider has probed
>> before the DMA client driver either probes or executes any later code.
> 
> I'm not against defer probe, but dma_request_slave_channel might not be
> the right function. Ideally dma channels are allocated at open() time
> and dma controller loaded checking is at probe() time. So there's
> better some function called check_dma_controller_loaded(), or we could
> also use initcalls to let dma driver probe earlier.
> 
> This patch intend to be simple to only change the binding.
> 
>> So, you could quite easily end up with a situation where the serial
>> driver's open fails because the DMA provider has not yet probed. This is
>> exactly what deferred probe was intended to avoid. This reason alone is
>> enough to make it worth fixing this.
>>
>>> dma_request_slave_channel is better to be called as late as possible to
>>> make better dynamic use of dma channels.
>>
>> probe() could validate that the provider exists in a way that doesn't
>> permanently hold ownership of the DMA channel. For example, request it
>> then immediately release it, in the absence of a dedicated "validate my
>> DMA providers exist" API.
> 
> It's ugly but may work. The current driver didn't check dma controller
> loaded at probe time. Let's leave the task to another patch?

I suppose it's fine to solve this later, although it seems quite
dangerous. You'd need to undo all the changes that alter where the DMA
channels are acquired in order to satisfy your argument though.


From gregkh at linuxfoundation.org  Wed Jul 31 21:40:24 2013
From: gregkh at linuxfoundation.org (Greg KH)
Date: Wed, 31 Jul 2013 18:40:24 -0700
Subject: [RESEND PATCH v10 1/8] drivers: phy: add generic PHY framework
In-Reply-To: <1374842963-13545-2-git-send-email-kishon@ti.com>
References: <1374842963-13545-1-git-send-email-kishon@ti.com>
 <1374842963-13545-2-git-send-email-kishon@ti.com>
Message-ID: <20130801014024.GA6941@kroah.com>

On Fri, Jul 26, 2013 at 06:19:16PM +0530, Kishon Vijay Abraham I wrote:
> +static int phy_get_id(void)
> +{
> +	int ret;
> +	int id;
> +
> +	ret = ida_pre_get(&phy_ida, GFP_KERNEL);
> +	if (!ret)
> +		return -ENOMEM;
> +
> +	ret = ida_get_new(&phy_ida, &id);
> +	if (ret < 0)
> +		return ret;
> +
> +	return id;
> +}

ida_simple_get() instead?  And if you do that, you can get rid of this
function entirely.

thanks,

greg k-h


